From owner-freebsd-arm@freebsd.org Sun Aug 16 04:34:26 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id D2B743B0E3B for ; Sun, 16 Aug 2020 04:34:26 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic305-19.consmr.mail.gq1.yahoo.com (sonic305-19.consmr.mail.gq1.yahoo.com [98.137.64.82]) (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 4BTkpm6f8Dz3dFh for ; Sun, 16 Aug 2020 04:34:24 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: 4D_R7fkVM1nOo26VlEJqfJG_AeSJgpaIAce3bE02kDXa7QonPY5PZTgxFaYyVVx TDfAGEVr8U1m8Rbpo5EVAtAYfptTnXtwSfaPqOUvYXsfxDKSjWXhDaLdYDZpzaMtv_ibrBKWQ94Y R5kZMHIoNBsBl5dnzbSBcVaLuO9cMoNy0JFq6HEjl2eDBxun0yWCIx3lvSE.pdANnI_wWfwU6WDV JYQvCUf1X5bTJMJyFNABJKCvFfpohrezlMXiCmntTdBj3qzGEcA3dsJlsEPBOCAITPeatxTPtFol mZlMFm0ksJlZlVLtr9j6GM9By3LueejcZzd70uvvH_vzeRI5fNfFtmU9UOmen4NRgyUisnkEvMVd xe8e8px6UxNqDh1tqP1SdscsH8TwYwwaPNEXzJqsV23Fw3Yp31URnb6XhOyVdsbqoiCDv35UUfFE a.qwA_hrVrctvYLRoSZl4PLnXhloqHj2HPwG_kUzPqDYQ1ByVDn6sOX_Ka.xL9BTG_C503.X3Kjb WOASgMVHOIGDtGKkPe4By55F9dkQR0P6V7.vFHLVaMYtTFl1aWGZ_aTkIon4aThTQ_87htFxqTrg f.fdaMjH4pMViAJoNaBA.W1Ww__4fdbpMbPn1Qs5Ehs7_nowA5YZZTw133oAiI7iRfmxotlTXoop k2YngROkN0bnG8hUXReWx7UlpS8cneMRp..N9HQk5.6rIpqDtHNh_DWFN9rUBks6qJUvWGpCTG0H WxKN7nupkjLO6vbzUdkIiNnrZOhDceGgzfIAz_nOnZObSjnbogR6ZxSXr3Lljy2PwUSbewjMHtle KoRhjEgTICDzHoJ7jIuS_KuHixzCO1JlNFWWhf4dq1BNgDmr288PgszRNPYXO1U3aopshU4LEubx 1gQ3RNvWqiC4BUqVnVgxKX29gA9fQLfaqS97Sl6Ku1g4npGAuHw69S4W2QVtHwEmJVxv9fB6Ep_d XqCb69uNdkKpCHsTCiSLBA.g.FH3mhptfF_x.IaMjj0Q1BVbuZoVBPFRuTSwILKt_zg05Hcm9GGk _TmERAfWnKB6mgZGm4_nxfy9EhhEbRwJW2PKmMzlv7RAPbnsfufVgzJztrux3EeygYxQkl3QxuPG B6j7z4giuuulwuciBGoHqGebAY2Kxu7PHJOuwYNAEg.5ZbXhAkFU7VByrdoqOEQW7cclD7_LgZDW REBT0xamRzw6SU0BXtP71PYUP7uV0XENRlR9JURN63vbC35gQkNlJ9k4iFQz.Z1jxBiahNLiNkAS kit50SNAP32khQwU58YWLiHcTn4v0CHutKdkYQRWUjM5vNt0b6mTiQA7S5fuYxhPHonpuKsrbK3q Qw4C0tu66qbI66DfNcC7KeIYrpSLAH5DnNCri3IbzJVfaOVbqK3a8s6AxHkSX5OM0c0i.XJWkPZJ Jy8r5vLVAmQ7n.o353V2Cjek3LTbkJABkyLwsjSKCSF7Oz1Uo5oy2Aquyyj4uPLfJ290xalJ7mA- - Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Sun, 16 Aug 2020 04:34:22 +0000 Received: by smtp423.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 282f16aa66af914ebf976b39b48f51f9; Sun, 16 Aug 2020 04:34:18 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Subject: Re: How to build sysutils/edk2@rpi4 (for example) that matches https://github.com/pftf/RPi4/releases/tag/v1.18 (for example) Date: Sat, 15 Aug 2020 21:34:17 -0700 References: <0AFFAC3B-2298-497E-9AAE-C3AFB7466106@yahoo.com> To: freebsd-arm , FreeBSD ports In-Reply-To: <0AFFAC3B-2298-497E-9AAE-C3AFB7466106@yahoo.com> Message-Id: <47751E85-0496-43BD-A10B-5724E7AA8466@yahoo.com> X-Mailer: Apple Mail (2.3608.120.23.2.1) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1597552465; 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:dkim-signature; bh=U8bh3X+0Uk0BMvrTvfr1uUd6LdxjAZbUM4GBiol+o7I=; b=UD0hgpXfolanF/zMOtQYpgFBEo0K51BZScqWSw7oCy2pY6mN/Qyi2XMRQXyJZHMvu/uvZv c3iXwmxrHOL50r9b+ivsy2beVDSvnqBNyt1lVWWpXrb0/J1l8Rd+ea4l379e7IN3i74j9K WkdA7AlW1nUeN3+C23a+s7j+tO1t342CpOXn/Nb7qKVGrDiyqGfnBz1wFUaJKKr+kF8jBH NqkPoPCPwwtFJKJG7lVoiLr/1YTTJCKQ7OdoxGC4A9I2JMVpsG+YfjNSWNsj7unMSc1RbD WPDhAs96oS4lDr+LAyteFmRsjOdctNvZKKiv5z960b9csycYwsZBzF7ZARN5ww== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1597552465; a=rsa-sha256; cv=none; b=ndEwa9Yc5q2jdJqwF8PVce61TlnG0I2Gmx0Vr0o6rNuHIahnFSTAcqIetvkxKLWlO4Bevc NxFO4ZVxJQ2UC7jJnXcsvF3Jtehz+JXvFNYoxGLqOFcolCmns3S2oxLdeCDz+z/KyVONw+ il8uwcwAPAnApoUPedr82P8kFg4J3GhdlQQMbWNUWbxqqHbBfZ4Ry2FycXFWHqSe0Vv8VH eOjxQlWIm6E4NA+h9UvH5CP1spQ5fm6WQqngyiqnhQcdb9r6LKzYwNywtPR3w3LonIOHf2 9HrvMj+WdKVfdGECM9H86QxrSHqUCf4UtlU7oBdvr4xOwkroT6Ny7HP7MO/owQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=hz9eT9wK; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.82 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Rspamd-Queue-Id: 4BTkpm6f8Dz3dFh X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.63 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; ARC_SIGNED(0.00)[i=1]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-0.52)[-0.517]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.04)[-1.044]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; URL_IN_SUBJECT(0.40)[github.com]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-0.97)[-0.970]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.82:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.82:from]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Aug 2020 04:34:26 -0000 On 2020-Aug-10, at 23:44, Mark Millard wrote: > I noticed the sysutils/edk2 addition. So I've tried to figure > out how to use it to reproduce the pftf RPi4 V1.18 release > (as an example), by, say, adjusting the distinfo file to pick > up the matching source. >=20 > Looking at https://github.com/pftf/RPi4/releases/ > there is a 4dd0f24 listed for the most recent release > (v1.18) that is a link to: >=20 > = https://github.com/pftf/RPi4/commit/4dd0f24d03cf73ed8e7bd29f88d8e86779410e= 69 >=20 > That in turn lists the release's changes for Submodules: >=20 > edk2 > edk2-non-osi > edk2-platforms >=20 > that are references to the > https://github.com/tianocore/ material. >=20 > edk2 has an updated "222 files" link which takes one to > a page that shows the commit history ending at > aa211bb . >=20 > edk2-non-osi has an updated "4 files" link which takes > one to a page that shows the commit history ending at > 4f88718 . >=20 > edk2-platforms has an updated "55 files" link which takes > one to a page that shows the commit history ending at > b2eebc1 . >=20 > These appear to be what to use to try to reproduce > the V1.18 pftf RPi4 release based on > https://github.com/tianocore/ materials. >=20 >=20 >=20 > Doing the same sort of thing for > https://github.com/pftf/RPi3/releases/ there is a > ab5895d listed for the most recent release (v1.29) > that is a link to: >=20 > = https://github.com/pftf/RPi3/commit/ab5895ddee99b0dd9030ec052fd67b838116c3= 77 >=20 > Again the 3 Submodules are listed on the page that > takes one to: >=20 > edk2 > edk2-non-osi > edk2-platforms >=20 > Looking at each shows that they match the RPi4 example: >=20 > edk2: aa211bb > edk2-non-osi: 4f88718 > edk2-platforms: b2eebc1 >=20 > (This may be normal when they release the pair together.) >=20 >=20 > Unfortunately, I'm not aware of anything for macchiatobin > that is analogous to https://github.com/pftf/RPi3 and > https://github.com/pftf/RPi4 off which to derive what > source would reproduce some known release that might > have been put to use with FreeBSD (a tested combination). >=20 >=20 > Also I found nothing referencing: >=20 > openssl-openssl > ucb-bar-berkeley-softfloat > kkos-oniguruma > google-brotli >=20 > but I've not checked if these are only used for the > macchiatobin flavor vs. being more widely used. >=20 >=20 >=20 > It will be some time before I try to update from > pftf RPi4 v1.17 to v1.18 via an adjusted sysutils/edk2 > built in poudriere. So I'm unsure if the above is > sufficient or not. >=20 > (Note: pftf RPi4 v1.18 in part was a work around for > a problematical start4.elf / fixup4.dat update, > reverting to "a version published before 2020.07.14" > for the .elf and .dat returned to things working. > bd816db is what broke them and 46e2c3e included > the fix to them. The same applies to RPI3's v1.29, > but for start.elf and fixup.dat instead.) >=20 >=20 > I have access to a MACCHITObin Double Shot --but it is > based on using a personal uefi/acpi build that I was > given access to. I've no clue how to reproduce it > from what source. I've no clue what would be good to > build for @macchiatobin use. (It need not match what > is good for the RPi3 and RPi4 as far as I can tell, > although such might work currently(?).) >=20 Looks like pftf/RPi4 gave up on getting edk2 to follow the standard on something that have some users dependent on older behavior later specified to be incorrect behavior. (Backwards compatibility won over forward standards conformance.) So there is now (as part of v1.19): QUOTE =E2=80=A2 This firmware was built from the official EDK2 = repository, with = 0001-MdeModulePkg-UefiBootManagerLib-Signal-ReadyToBoot-o.patch applied = to the edk2 submodule. If you need more information, please refer to = that repository. END QUOTE https://github.com/pftf/RPi4/ has the patch listed. v1.19 includes more than that. But edk2-non-osi is as it was for v1.18 . That points that that exploring a specific: https://github.com/pftf/RPi4/commit/[OMITTED] need not show all the relevant "what to use" information for the 3 modules from: https://github.com/tianocore/ I had not mentioned such issues previously. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Sun Aug 16 06:04:04 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 83FD13B1FFA for ; Sun, 16 Aug 2020 06:04:04 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gate2.funkthat.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BTmpB1Q5kz3gmf for ; Sun, 16 Aug 2020 06:04:01 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.15.2/8.15.2) with ESMTPS id 07G63rGU066540 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 15 Aug 2020 23:03:53 -0700 (PDT) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.15.2/8.15.2/Submit) id 07G63rkM066539; Sat, 15 Aug 2020 23:03:53 -0700 (PDT) (envelope-from jmg) Date: Sat, 15 Aug 2020 23:03:53 -0700 From: John-Mark Gurney To: "Steve O'Hara-Smith" Cc: freebsd-arm@freebsd.org Subject: Re: RPi4B and self-hosted buildworld buildkernel times: using more than -j3 is a waste in my tests. Message-ID: <20200816060353.GB4213@funkthat.com> Mail-Followup-To: Steve O'Hara-Smith , freebsd-arm@freebsd.org References: <20200815100051.10b1d9442c2c739e36f8c7e5@sohara.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200815100051.10b1d9442c2c739e36f8c7e5@sohara.org> X-Operating-System: FreeBSD 11.3-STABLE amd64 X-PGP-Fingerprint: D87A 235F FB71 1F3F 55B7 ED9B D5FF 5A51 C0AC 3D65 X-Files: The truth is out there X-URL: https://www.funkthat.com/ X-Resume: https://www.funkthat.com/~jmg/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.6.1 (2016-04-27) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (gold.funkthat.com [127.0.0.1]); Sat, 15 Aug 2020 23:03:53 -0700 (PDT) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1597557842; 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: in-reply-to:in-reply-to:references:references; bh=KEqZvGeY7OZdbInw9qbzAR7+gyi/f07SBdXLQvnR5EQ=; b=Tv9kOBCLJvlabmUUyfgsB9qxcscHt4HWWENC4n91AiBddS3tQFGO6SgbOezq8hgftqq/EU PKGcZY4FyntHkggR3mnzeSYyZ4jaLABMQL9Fceh9uOMmJEkHTiJJ4Ffd+sxwHld3ejRA4J 89RYCBRxpIrKV+ZQYjIKWPFe4ETxUE8yTi+u2xGthfoL36sn7vsm5cG/P+zX58qs+AJ2jE rj31eU6wZ7vtyGXfuCJ4KR6NLlbIWT0yOmoBejr3N9ULmbe0DqBWmgpKMGm0B4xAzXKJ8P UITktihhpKqo0QoRN406IM1mAqF9pcDP53zsWeDO57LH8RroPQFblNZNAIgc6A== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1597557842; a=rsa-sha256; cv=none; b=JVuntQcOPnhT2tvPl08/sC5q1pUpN9dD+3M5C1OtCPJaUJu3oUKkW6cyiu2jNCf2WLFfta KfgJhzPMNA5bXLt+NoyucLgYE+sifIEz1OicAtZ7nTrN74hpfTQ1l1i3VykxxvgP5zw9/T 3TWT0CVDfnzAPd/y5NzagOEwrvXox1U/RnOWYsZjmvVjHOLzBIkxS88mxb9dBwkzaP7hoJ 8txpuWqWvuJ4cm19jXcxNEPmzQpkhdrOWCQmYbgKS0gGfiuT5pfnXRFuFX6IGkz2gAxAKf k9QOErNAd7XguoK6DiWc8I6Dwiv4kl4Cj5TjkiRaLr6OhV4o4XyxWLkBW2O7ew== ARC-Authentication-Results: i=1; mx1.freebsd.org; dkim=none; spf=none (mx1.freebsd.org: domain of jmg@gold.funkthat.com has no SPF policy when checking 208.87.223.18) smtp.mailfrom=jmg@gold.funkthat.com X-Rspamd-Queue-Id: 4BTmpB1Q5kz3gmf X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of jmg@gold.funkthat.com has no SPF policy when checking 208.87.223.18) smtp.mailfrom=jmg@gold.funkthat.com X-Spamd-Result: default: False [2.47 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; MIME_GOOD(-0.10)[text/plain]; ARC_SIGNED(0.00)[i=1]; DMARC_NA(0.00)[funkthat.com]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.85)[0.851]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.02)[-0.015]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_SPAM_LONG(0.43)[0.434]; R_SPF_NA(0.00)[no SPF record]; FORGED_SENDER(0.30)[jmg@funkthat.com,jmg@gold.funkthat.com]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; FROM_NEQ_ENVFROM(0.00)[jmg@funkthat.com,jmg@gold.funkthat.com]; ASN(0.00)[asn:32354, ipnet:208.87.216.0/21, country:US] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Aug 2020 06:04:04 -0000 Steve O'Hara-Smith wrote this message on Sat, Aug 15, 2020 at 10:00 +0100: > On Sat, 15 Aug 2020 00:23:58 -0700 > Mark Millard via freebsd-arm wrote: > > > So: much less time required compared to the RPi4B at the > > same clock rate. (The MACCHIATObin has a SATA SSD but > > buildworld buildkernel is not I/O bound.) > > Still given the difference in price the Rpi4B doesn't come off too > badly in the comparison. And if you distribute the build accross multiple RPi4B's, w/ three or four, which is still cheaper than even the single shot, you could possible get a comparable build time. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@freebsd.org Sun Aug 16 12:59:04 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id CF61B3BB238 for ; Sun, 16 Aug 2020 12:59:04 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 4BTy1450Gkz4Kkm for ; Sun, 16 Aug 2020 12:59:04 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: by mailman.nyi.freebsd.org (Postfix) id A94ED3BB237; Sun, 16 Aug 2020 12:59:04 +0000 (UTC) Delivered-To: arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id A91103BB137 for ; Sun, 16 Aug 2020 12:59:04 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mx.blih.net (mx.blih.net [212.83.155.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mx.blih.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BTy104NpXz4KWV for ; Sun, 16 Aug 2020 12:58:59 +0000 (UTC) (envelope-from manu@bidouilliste.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bidouilliste.com; s=mx; t=1597582726; 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=6+R0YwopzTBnoOPy+QZ/1XuNjlRzV+BVxxUozkv0uVg=; b=sLQVq/8epGlprds3YfgSz0xa0UBblWNm7phHQTciM4OFsgQYQCPUnLuHVsmMtw+FCHQRyh VTN/JoRtXs+11OhqTuREpMF6uSbt2Xp8zO89/YZ3jLobCdZa08kjSycP8kLVKg9Pp5VZvP UJZQ4weVjZaENi8EdADUZWMBYKx+YzM= Received: from amy (feu30-1-82-242-59-241.fbx.proxad.net [82.242.59.241]) by mx.blih.net (OpenSMTPD) with ESMTPSA id c2a4f260 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Sun, 16 Aug 2020 12:58:46 +0000 (UTC) Date: Sun, 16 Aug 2020 14:58:45 +0200 From: Emmanuel Vadot To: ticso@cicely.de Cc: Bernd Walter , =?ISO-8859-1?Q?S=F8ren?= Schmidt , "freebsd-arm@freebsd.org" Subject: Re: Pinebook Pro battery fuel-gauge driver.. Message-Id: <20200816145845.4586b7003e4ad1e885c0199d@bidouilliste.com> In-Reply-To: <20200815113239.GC14057@cicely7.cicely.de> References: <20200815113239.GC14057@cicely7.cicely.de> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; amd64-portbld-freebsd13.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1597582743; 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:dkim-signature; bh=6+R0YwopzTBnoOPy+QZ/1XuNjlRzV+BVxxUozkv0uVg=; b=YYPAGTMSy/CZRuxICpZ1MCjdHy/e1/T/MoOSsLBj0NsoLesPnzxwFh4GR4xfjBd2+9XTbd CTXZoFa8Zk4X3vkrqfcylqoQVeXRD1jh8Wn9wJsy6PhdUIAyAtMwtBV+AWVdfibx5jgV58 IJJVTUfACrr5HCs2BZwCs8O7PWPo6UtZ1BCg9vKdSzugZu7ffqsgB465bBsGO09y6xw/a7 qamncjvE/AqJ/fEqvbD74eKFd2KZP9G5pErTQGm0PZAm51HOrH9bW9AcGqZDGzEBDUdH/g QIbaceOSHXe+OkOqUW2PYZ+e29ulY2NmyoaZMUn7zw1tMqWymXsKLp+Y9d9r3Q== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1597582743; a=rsa-sha256; cv=none; b=rcgGBIFKBWOOd8mHm4hmPUTYWVkJYx2wz+1OD0tT/eYLoWTqvj5Oq7/drQpFXPLANk6nK+ bumWaUiVb6vW9DW6WVqu7FsaSyFLjnNg+nNy7KkUYpBO8mwh6hsy3+EHWty56+Zxy9Jvg8 Hluom7+ls/sn842Rc7uoPMhcfjE2tvn3NaidMRA4sKRiWjZ6aA89Z2X6cdxcZxORsriQZz 8V7wXV1L+xe0gFJVjxDqFmBeqc7uDJhfm4/y4718YZ0guhaOuA+mmMOa2ZYRM3Ydyw7AyF LXtzz04vLyFfhbtx0mrnQHinLntlEVoYtvmexLoRABFugdarBWt8bmq7AVIN/g== ARC-Authentication-Results: i=1; mx1.freebsd.org; dkim=pass header.d=bidouilliste.com header.s=mx header.b=sLQVq/8e; spf=pass (mx1.freebsd.org: domain of manu@bidouilliste.com designates 212.83.155.74 as permitted sender) smtp.mailfrom=manu@bidouilliste.com X-Rspamd-Queue-Id: 4BTy104NpXz4KWV X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bidouilliste.com header.s=mx header.b=sLQVq/8e; 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.14 / 15.00]; RCVD_TLS_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[bidouilliste.com:s=mx]; MID_RHS_MATCH_FROM(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; FROM_HAS_DN(0.00)[]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-0.98)[-0.984]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bidouilliste.com:+]; DMARC_POLICY_ALLOW(-0.50)[bidouilliste.com,none]; ARC_SIGNED(0.00)[i=1]; NEURAL_HAM_SHORT(-1.12)[-1.125]; NEURAL_HAM_MEDIUM(-1.03)[-1.027]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:12876, ipnet:212.83.128.0/19, country:FR]; FREEMAIL_CC(0.00)[cicely7.cicely.de,gmail.com,freebsd.org]; SUSPICIOUS_RECIPS(1.50)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Aug 2020 12:59:04 -0000 On Sat, 15 Aug 2020 13:32:39 +0200 Bernd Walter wrote: > On Fri, Aug 14, 2020 at 06:23:33PM +0200, S=F8ren Schmidt wrote: > > Hi > >=20 > > Now that we have display and all working I hacked up a driver for the c= w2015 chip that can tell how much battery is left so I know when to seek an= outlet :) >=20 > Cool - too bad this is different hardware to my older Allwinner based > Pinebook. axp81x driver supports battery status. > > It consists of a patch to the dts (from linux) where all I need is the = chiplocation but for compats sake, and the driver. > >=20 > > Access is via sysctl, as we have no real way of handling this info on A= RM (no acpi, apm etc) AFAIK. > >=20 > > Enjoy! >=20 > --=20 > B.Walter http://www.bwct.de > Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" --=20 Emmanuel Vadot From owner-freebsd-arm@freebsd.org Sun Aug 16 13:02:27 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 1F6253BB1FF for ; Sun, 16 Aug 2020 13:02:27 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 4BTy4y6zXFz4KvL for ; Sun, 16 Aug 2020 13:02:26 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: by mailman.nyi.freebsd.org (Postfix) id EF8833BB1FE; Sun, 16 Aug 2020 13:02:26 +0000 (UTC) Delivered-To: arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id EF5283BB462 for ; Sun, 16 Aug 2020 13:02:26 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mx.blih.net (mx.blih.net [212.83.155.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mx.blih.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BTy4w5SYhz4LDJ for ; Sun, 16 Aug 2020 13:02:24 +0000 (UTC) (envelope-from manu@bidouilliste.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bidouilliste.com; s=mx; t=1597582937; 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=yQlXk31XPyxyDmNc+4YYhH4+MGi+QHtKq9d71vl3RnI=; b=B7cT1ww3uSIxDARH6saYfL1KAbP1je3WprK8Jf8St2FM5gh8h0dEyKxDDcppdd2gHvPZPn 60Sg9+kpOePkPhoJ50f78gUxXLZJF+Etya4iLaGzAZFDlrih6sN2sU0+77Gjnilkfv5c0c Xd2WVLM34+Z3MMFD7b31HBUtlVffDrU= Received: from amy (feu30-1-82-242-59-241.fbx.proxad.net [82.242.59.241]) by mx.blih.net (OpenSMTPD) with ESMTPSA id a102d2c8 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Sun, 16 Aug 2020 13:02:17 +0000 (UTC) Date: Sun, 16 Aug 2020 15:02:17 +0200 From: Emmanuel Vadot To: =?ISO-8859-1?Q?S=F8ren?= Schmidt Cc: "freebsd-arm@freebsd.org" Subject: Re: Pinebook Pro battery fuel-gauge driver.. Message-Id: <20200816150217.b976cb1f516f7f09b7f35c10@bidouilliste.com> In-Reply-To: References: X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; amd64-portbld-freebsd13.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1597582946; 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:dkim-signature; bh=yQlXk31XPyxyDmNc+4YYhH4+MGi+QHtKq9d71vl3RnI=; b=qfYH6NHEcTbpdB9b3TdEzuOPfkW9rmBrDyOSPqUMlgsWNvfugPsBFqGZd585tZDDH6DytC z/XhYewQ49JZkC0eZIjc/6BcJy5Wk0VHVSgBECXSOil38tlVC2WdEGVRlSdxFjGTdN7hNP TszMDrDnVEN7fZrFkOWttLOJKeA4FezyHXnCgg6HuFBQAOip5FlvPaR/TJ7jBpWJ2+RNrB ddBnqSVdUSQmV1LLq1gxRH9fkPHnSd1drBbuJMcARJavzBXeQW8uoCgKLrMM99sTHmqUOp h0BX5vwIUlSbV6a+sw9FRXB73xPGozHGynonftuKkXLhqqsoYE7QGGUQc3sRlA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1597582946; a=rsa-sha256; cv=none; b=ULn/ENtU5/6R3m+9OvUE2jhXCqbjxbQIDSpEDeZmwHgHbn57nF+cExS9g8qLCWvUVupszc j3VIMeTuYXdBe0lQCV7G3NAhisgTMT4wVONOxBBvFaUSbzvONpc8yG4jeUh8RSrjwqYTxm 1G6NyaOK+BsSovVqkei2TYw2evvjfBn9sSlRZukeOK9OqlO897BPyKbi+LZXmPnVxha8Gh d6lmtcV5Ux5A+DDhU6Qz+bbV2tPwy4A4iNkuYKyK3TPWUZ0K9BGZlO7uGojzxAt5jO7xgh CpmGyAPDUVI2e0ZhPCQyjSznJ1WBweJrSl6mfjSkrjO07qT4NcsEgTjvLlAycg== ARC-Authentication-Results: i=1; mx1.freebsd.org; dkim=pass header.d=bidouilliste.com header.s=mx header.b=B7cT1ww3; 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-Rspamd-Queue-Id: 4BTy4w5SYhz4LDJ X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bidouilliste.com header.s=mx header.b=B7cT1ww3; dmarc=pass (policy=none) header.from=bidouilliste.com; spf=pass (mx1.freebsd.org: domain of manu@bidouilliste.com designates 212.83.155.74 as permitted sender) smtp.mailfrom=manu@bidouilliste.com X-Spamd-Result: default: False [-3.55 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[bidouilliste.com:s=mx]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx:c]; MV_CASE(0.50)[]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[text/plain]; ARC_SIGNED(0.00)[i=1]; NEURAL_HAM_LONG(-0.99)[-0.985]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(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(-1.04)[-1.036]; NEURAL_HAM_MEDIUM(-1.03)[-1.033]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:12876, ipnet:212.83.128.0/19, country:FR]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Aug 2020 13:02:27 -0000 On Fri, 14 Aug 2020 18:23:33 +0200 S=F8ren Schmidt wrote: > Hi >=20 > Now that we have display and all working=20 I wouldn't say that, what you have is an hack that will probably cause other problem. > I hacked up a driver for the cw2015 chip that can tell how much battery i= s left so I know when to seek an outlet :) >=20 > It consists of a patch to the dts (from linux) where all I need is the ch= iplocation but for compats sake, and the driver. Cool, got any link for your code ? Mind to open a review ? > Access is via sysctl, as we have no real way of handling this info on ARM= (no acpi, apm etc) AFAIK. thj@ started to split battery subsystem from ACPI a while ago iirc. > Enjoy! >=20 >=20 >=20 > -- > S=F8ren Schmidt > sos@deepcore.dk / sos@freebsd.org > "So much code to hack, so little time" >=20 >=20 >=20 > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" --=20 Emmanuel Vadot From owner-freebsd-arm@freebsd.org Sun Aug 16 18:19:48 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id E93DF3C2E92 for ; Sun, 16 Aug 2020 18:19:48 +0000 (UTC) (envelope-from soren.schmidt@gmail.com) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4BV5784sk5z4dVg for ; Sun, 16 Aug 2020 18:19:48 +0000 (UTC) (envelope-from soren.schmidt@gmail.com) Received: by mailman.nyi.freebsd.org (Postfix) id A551B3C2BE2; Sun, 16 Aug 2020 18:19:48 +0000 (UTC) Delivered-To: arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id A40613C2CC3 for ; Sun, 16 Aug 2020 18:19:48 +0000 (UTC) (envelope-from soren.schmidt@gmail.com) Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com [IPv6:2a00:1450:4864:20::62c]) (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 4BV5773pXJz4dgv for ; Sun, 16 Aug 2020 18:19:47 +0000 (UTC) (envelope-from soren.schmidt@gmail.com) Received: by mail-ej1-x62c.google.com with SMTP id t10so15198323ejs.8 for ; Sun, 16 Aug 2020 11:19:47 -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=C8Ppgj8w/NPwk45422S9plIMnD/gczivGcQFtjrMRyM=; b=P9DPl/AZMAjnCmu5PFWfyd2YCjZrRkCn+Lr0cDchZElc67HZXkuuYH7xGMWHOGyI4N rsAoEP1qA6jv3MnQAuikmnbn41kIJdg7yxWPfwHI6S+hx8TU08CmGHKDgb4sCQVmCzSe bDAVPcgfio2BjSUq13nHThWHZuUlyRAWF7M9RKlwD5Z1Uyurv0SjtNvCpeUl+aqbNdFT RhVn9pJEM2bCzeam8MV38z6yFhs4jveZdDbcAHszbBfLYn6hcVyv2g+by8UReVBY94Pk MknbAiKrSZi7ArUO+6/9Dysos1digTdXymSrmPWXkxb+n4XATXlwnJnV+GLbpUOQH8Nj sI+Q== 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=C8Ppgj8w/NPwk45422S9plIMnD/gczivGcQFtjrMRyM=; b=qLbbpZkh4slrHBLe/NSUX9xqn6zI8D2is97QR9Cd71ugT3NdMDIJ0AriwW1VJgVoO8 v2BocXk23JeNmfs3EbsbxpbiZYddHG46sIC3Mi0u5YL7QcSujQKrSLnmekIdRHLKw1jK VA35pJnw1zB+wkaMrEYQFvfOp42r6+AZrunNNfSUyXTjJeP/qpMg/lFFOsWHQZH6fmr/ TUsfOAAnVhyK0BCSL2B1bBpN52bsdSMTJ9XeyVayVSYFfsZlEM5p4wOfAM6/tuJZ5/c+ P3NTFYuozj5XDVJu7804MaWw+N5MSqG6io1TYazMTxJfWJ7UELiscozI9xKpdaksyuvZ MSgw== X-Gm-Message-State: AOAM532Vh9IN4lWoqHtVXYYb80U44Cto47TwHulFpt8d/edzcxi5Togy 6kOnspzd24c29MV4Lvd2dnEWk4JCHNI= X-Google-Smtp-Source: ABdhPJyBp85l0JRCyZ7Xfjtq8sk8zFGEzKlARsoPlqshzCYC8ZvCgTXEOcZeiGu7PX3+mcjalvNL5g== X-Received: by 2002:a17:906:a0c5:: with SMTP id bh5mr11549625ejb.120.1597601985539; Sun, 16 Aug 2020 11:19:45 -0700 (PDT) Received: from mac.deepcore.dk ([85.27.186.9]) by smtp.gmail.com with ESMTPSA id pv28sm12328679ejb.71.2020.08.16.11.19.44 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 16 Aug 2020 11:19:44 -0700 (PDT) From: =?utf-8?Q?S=C3=B8ren_Schmidt?= Message-Id: <5E285422-EA34-4A8C-9BE2-6B3AEED6AD2F@gmail.com> Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: Pinebook Pro battery fuel-gauge driver.. Date: Sun, 16 Aug 2020 20:19:44 +0200 In-Reply-To: <20200816150217.b976cb1f516f7f09b7f35c10@bidouilliste.com> Cc: "freebsd-arm@freebsd.org" To: Emmanuel Vadot References: <20200816150217.b976cb1f516f7f09b7f35c10@bidouilliste.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1597601987; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=C8Ppgj8w/NPwk45422S9plIMnD/gczivGcQFtjrMRyM=; b=cuRZjgyvooBOT9njNDCUj+2hnCtT9yd/PLeltYLVPHYNn+8oTVNoz7XFTZ7PgyEB4fED/1 fJ7BI13gogX6skSiZ/TyM2ebfMw8XZfWEDq80YnQ842kZ24FlDOg1f4fJFsJdqFPyxcANM vX2BvZ77Sg9tO2CTSoDqapBoA5qvjohqRVuVh7Zzf8UYDqV4t2U2pGIbSuUzjsA1CiINej RIuF2SEJhbjuwwnyV9H82VFl4y4Gi1U4Et7jsfdPPJJyn7eo1nzTm58ZLu/vir/r/OrekA RearRfZK/jYmfQJsg8o2Fe/ZzB4w8SHQ3bv+VyQdh1KVVOZqA/sN1UE0bPV/uw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1597601987; a=rsa-sha256; cv=none; b=hmjD+gswWNpDQM4zdlitcQyDQPgV+ifs9vI0VCwKImlzgX/LKXOMFRnBqNdx/l1K9snB39 SSZDUdzX4zcFWW/jlpy2BvAHkNM7GhhiWy/uwYrGexaB3rAKQi6Al6LSVt0GfAdDkRbb4S hSxt8S0akpaZyfE+I/IwYB3ziYuD8qP+e7LD7doJh9RA6QNQbPldkAZirxnftJTGSf1BK0 p34yWdIdI9Ja5WqMcxEcnQFXOJ63Jwq5alEejzNakYs8bWizRju+W9f3CaHoBalSp99YMM +BFaNrmNR6p4pJDuF8fAG/x2zEvLB21I+Zi1a+LoPqE1vyv0lQ/owZXsebFMDw== ARC-Authentication-Results: i=1; mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=P9DPl/AZ; spf=pass (mx1.freebsd.org: domain of sorenschmidt@gmail.com designates 2a00:1450:4864:20::62c as permitted sender) smtp.mailfrom=sorenschmidt@gmail.com X-Rspamd-Queue-Id: 4BV5773pXJz4dgv X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=P9DPl/AZ; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of sorenschmidt@gmail.com designates 2a00:1450:4864:20::62c as permitted sender) smtp.mailfrom=sorenschmidt@gmail.com X-Spamd-Result: default: False [-3.19 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; ARC_SIGNED(0.00)[i=1]; 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]; NEURAL_HAM_SHORT(-1.19)[-1.188]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; R_MIXED_CHARSET(0.56)[subject]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MID_RHS_MATCH_FROM(0.00)[]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; NEURAL_HAM_MEDIUM(-1.05)[-1.053]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.001]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[arm@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::62c:from]; RCVD_TLS_ALL(0.00)[] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Aug 2020 18:19:49 -0000 On 16 Aug 2020, at 15.02, Emmanuel Vadot wrote: >=20 > On Fri, 14 Aug 2020 18:23:33 +0200 > S=C3=B8ren Schmidt wrote: >=20 >> Hi >>=20 >> Now that we have display and all working=20 >=20 > I wouldn't say that, what you have is an hack that will probably cause > other problem. Sure, but havn=E2=80=99t found any ill effects yet, I=E2=80=99ll look = into getting it done correctly, but for now it makes the pinebookpro = useful and self-contained. >> I hacked up a driver for the cw2015 chip that can tell how much = battery is left so I know when to seek an outlet :) >>=20 >> It consists of a patch to the dts (from linux) where all I need is = the chiplocation but for compats sake, and the driver. >=20 > Cool, got any link for your code ? Mind to open a review ? Code was attached to the original mail, I=E2=80=99ll look into getting a = review setup, need to figure out how that works on fabricator though. >> Access is via sysctl, as we have no real way of handling this info on = ARM (no acpi, apm etc) AFAIK. >=20 > thj@ started to split battery subsystem from ACPI a while ago iirc. Any pointers to that ? I admit I didn=E2=80=99t look around too much, = considered emulating APM but went with simple sysctl=E2=80=99s. -- S=C3=B8ren Schmidt sos@deepcore.dk / sos@freebsd.org "So much code to hack, so little time" From owner-freebsd-arm@freebsd.org Mon Aug 17 02:18:35 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 8639337C82C for ; Mon, 17 Aug 2020 02:18:35 +0000 (UTC) (envelope-from ganbold@gmail.com) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 4BVHlb2djjz44SW for ; Mon, 17 Aug 2020 02:18:35 +0000 (UTC) (envelope-from ganbold@gmail.com) Received: by mailman.nyi.freebsd.org (Postfix) id 5A18937C82B; Mon, 17 Aug 2020 02:18:35 +0000 (UTC) Delivered-To: arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 59DDB37C544 for ; Mon, 17 Aug 2020 02:18:35 +0000 (UTC) (envelope-from ganbold@gmail.com) Received: from mail-ot1-x32a.google.com (mail-ot1-x32a.google.com [IPv6:2607:f8b0:4864:20::32a]) (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 4BVHlZ41bRz44dx for ; Mon, 17 Aug 2020 02:18:34 +0000 (UTC) (envelope-from ganbold@gmail.com) Received: by mail-ot1-x32a.google.com with SMTP id v21so12235193otj.9 for ; Sun, 16 Aug 2020 19:18:34 -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=/jsUM66BJJFAx5S33iiLhJto/u8AX8fBF64EBd0yu1A=; b=jwa0v7WA8U0eeZCEc8VF3I2pIPaA+c9pESPHhSCq5pQmaqZ/W6cqLTG9k/waY2ev2p 4CvObFPMug3PvNZzFU9Ys6wnUed3e59FTxnoBGIZWgkIxpizwUQpCph26pLGUc8wy3zj YJ7TRkaZPNL0BKpCbPahSqCW2Gd24qO+tJIye6oY4ug7sjaGUNhEnNO/d3TpSw9tg8pZ MZe0Ay/vmbe6B0tqpCvIfrdrsj+A+X2muJXiYW52Ownhw1wMeT0z8Ed7+edBDXNCS99J X/uz3fyrRM8Tw7Ej7F8F53vmMEELpz/ebnKJBJRX5jMA+BkrSDswnbRIlVUcgK7tCoRI jp1A== 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=/jsUM66BJJFAx5S33iiLhJto/u8AX8fBF64EBd0yu1A=; b=f5Ck8f6UbZcfK0CD2DnSelBUOkalxBZda4O+RC+JR75008rKYf5EBkE02vauYeuSTD L29hzC5NTiIGzSBx0ExC7PUZ1RXPYhlRio2dJtLQuWpHtibQN4QrA3KIYbaKZS+68QTZ UGrWByDlBFjnEQX9SfSkmy/g5Q9KSJmMw7XeFq0dHEmzWab7OhuaaoqOEBRtSMFajZOd r4vhT7jtQ2YBhZTcVUt3+69nuMFCLp8GX6LcQV/tvbpP1qwZ0rsSymtM8kOkSckyA/QF o4gXCGy85eksc4txscgoB1rAvDfdB1oo0xyB4nkbt8VVa7C3VpbN5KY4O1evUOIbn5Tk zyCQ== X-Gm-Message-State: AOAM530wjn4orVpQWM6+UdWJKb1ItEdskvP3DVZaRmUckr0TC64RZ8Ik 07OmXSF+WCZrU5lvRpAYuXW9fw0MiymBNp5XB6Q= X-Google-Smtp-Source: ABdhPJyZIoUjrDqG22kSXjeHBoqP1SjvM3FAn1OQandCBj4ybSH+B8+cK3kolVhQ/Lker/+/SSN/K3kMCDDOWFtlF1Y= X-Received: by 2002:a9d:639a:: with SMTP id w26mr9678919otk.140.1597630712739; Sun, 16 Aug 2020 19:18:32 -0700 (PDT) MIME-Version: 1.0 References: <20200816150217.b976cb1f516f7f09b7f35c10@bidouilliste.com> <5E285422-EA34-4A8C-9BE2-6B3AEED6AD2F@gmail.com> In-Reply-To: <5E285422-EA34-4A8C-9BE2-6B3AEED6AD2F@gmail.com> From: Ganbold Tsagaankhuu Date: Mon, 17 Aug 2020 10:18:20 +0800 Message-ID: Subject: Re: Pinebook Pro battery fuel-gauge driver.. To: =?UTF-8?Q?S=C3=B8ren_Schmidt?= Cc: Emmanuel Vadot , "freebsd-arm@freebsd.org" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1597630714; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=/jsUM66BJJFAx5S33iiLhJto/u8AX8fBF64EBd0yu1A=; b=cxVNdidGrprW03yThzFAw/gPJJ/8OU7N9+S4WbUEMv0Ppp8AfJ+RDOhunYN6gEyQxYQrvq XGL5RQ7fMh2i+6b+lTb+JliNrw8/KUDktSeRk106M47X76wlRfWw21bB7XHxJdYyA3wR/s 833Kt3iqPbMxz1OnIurhvRGLpbJ1URdjdI7Qgd1qbVj9mx36kptfIvVMM29mNum2X1BuBY vNFeUygoJDcWYlJrz3mtak/8HF9YhZDmP6U8Oij5zLnWZj0TSmQyYmYioqOEobN4rt2nNl VcUD2Q9BJEA9blVx0p1ZRNl1rXSR7vJKHQ+WIlDJcxzepA83fPiAjZCLsk7YOQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1597630714; a=rsa-sha256; cv=none; b=Njik3HIp6wyvhokp++0cUbdgnfwVZpzF0R0jLqfB4cunLGUiB+/UkgKJSaxuj6SI6aJ1l+ LkJ5683wEqfLotmoJ+UEexlh5YpO0vknEjVCEnZoKQExwEENGHWc07uwgdNK9CxmezYmdV +xYOnx50b3zNnR9cciedvZIe6HT/7zkpiMIWbV5YtWdc2E5kMfLE5SY7f4elH0L9Cqvs/i gWSEoCAoCl3QCwpQ0SHkl0EsrXlKG9BB9I9p7unOieJ6wyfyLvJLvrgcjK5NMSxH+MDabY MIR8UVymMgg1C7S/X5BBw8fHmcI6nLn9vDtbOvtgVX8A2i5bLY+fYxUWWv9chg== ARC-Authentication-Results: i=1; mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=jwa0v7WA; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of ganbold@gmail.com designates 2607:f8b0:4864:20::32a as permitted sender) smtp.mailfrom=ganbold@gmail.com X-Rspamd-Queue-Id: 4BVHlZ41bRz44dx X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=jwa0v7WA; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of ganbold@gmail.com designates 2607:f8b0:4864:20::32a as permitted sender) smtp.mailfrom=ganbold@gmail.com X-Spamd-Result: default: False [-4.24 / 15.00]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; ARC_SIGNED(0.00)[i=1]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.19)[-1.185]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.03)[-1.030]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.02)[-1.024]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[arm@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::32a:from]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2020 02:18:35 -0000 On Mon, Aug 17, 2020 at 2:19 AM S=C3=B8ren Schmidt wrote: > On 16 Aug 2020, at 15.02, Emmanuel Vadot wrote: > > > > On Fri, 14 Aug 2020 18:23:33 +0200 > > S=C3=B8ren Schmidt wrote: > > > >> Hi > >> > >> Now that we have display and all working > > > > I wouldn't say that, what you have is an hack that will probably cause > > other problem. > > Sure, but havn=E2=80=99t found any ill effects yet, I=E2=80=99ll look int= o getting it done > correctly, but for now it makes the pinebookpro useful and self-contained= . > > >> I hacked up a driver for the cw2015 chip that can tell how much batter= y > is left so I know when to seek an outlet :) > >> > >> It consists of a patch to the dts (from linux) where all I need is the > chiplocation but for compats sake, and the driver. > > > > Cool, got any link for your code ? Mind to open a review ? > > Code was attached to the original mail, I=E2=80=99ll look into getting a = review > setup, need to figure out how that works on fabricator though. > I don't see any attachment in your original mail. Ganbold > > >> Access is via sysctl, as we have no real way of handling this info on > ARM (no acpi, apm etc) AFAIK. > > > > thj@ started to split battery subsystem from ACPI a while ago iirc. > > Any pointers to that ? I admit I didn=E2=80=99t look around too much, con= sidered > emulating APM but went with simple sysctl=E2=80=99s. > > -- > S=C3=B8ren Schmidt > sos@deepcore.dk / sos@freebsd.org > "So much code to hack, so little time" > > > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > From owner-freebsd-arm@freebsd.org Mon Aug 17 09:06:09 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 266373ACA20 for ; Mon, 17 Aug 2020 09:06:09 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 4BVSnr6yxHz4QkY for ; Mon, 17 Aug 2020 09:06:08 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: by mailman.nyi.freebsd.org (Postfix) id ED4063ACA1F; Mon, 17 Aug 2020 09:06:08 +0000 (UTC) Delivered-To: arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id ED0373ACA1E for ; Mon, 17 Aug 2020 09:06:08 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [IPv6:2a02:21e0:16e0:fe::101:1]) (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 "raven.bwct.de", Issuer "raven.bwct.de" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BVSnq3kCxz4Qvs for ; Mon, 17 Aug 2020 09:06:06 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from mail.cicely.de (mail.cicely.de [IPv6:2a02:21e0:16e0:20fe:0:0:101:c]) by raven.bwct.de (8.15.2/8.15.2) with ESMTPS id 07H95qPi026406 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=FAIL); Mon, 17 Aug 2020 11:05:53 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cicely.de; s=default; t=1597655153; bh=VNo73XtTMSlFNA0b+6zDDHzOa0EU9Bbe411C6jfdR74=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To; b=ig/vqomvxVCgCXlLPrPO8gv/UARX08RNjhHDsfpH68OeUJXHF9FHB3CBc0QhLIHe3 JMVpK5MwLQylNalsU7ImBPuwR5kRB174U0ae6kWQePdnXgOLv4UM8h4B59trKzaboz /af8bldbAm+sc4/krHSpALN0K66SYrn8Rjpm3yNY= Received: from cicely7.cicely.de (nuttx-devel.cicely.de [IPv6:2a02:21e0:16e0:20fe:0:0:101:b]) by mail.cicely.de (8.15.2/8.15.2) with ESMTPS id 07H95mGi087280 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 17 Aug 2020 11:05:49 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.15.2/8.15.2) with ESMTP id 07H95mO4059935; Mon, 17 Aug 2020 11:05:48 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.15.2/8.15.2/Submit) id 07H95mZh059934; Mon, 17 Aug 2020 11:05:48 +0200 (CEST) (envelope-from ticso) Date: Mon, 17 Aug 2020 11:05:48 +0200 From: Bernd Walter To: Emmanuel Vadot Cc: ticso@cicely.de, "freebsd-arm@freebsd.org" , Bernd Walter Subject: Re: Pinebook Pro battery fuel-gauge driver.. Message-ID: <20200817090548.GA59918@cicely7.cicely.de> Reply-To: ticso@cicely.de References: <20200815113239.GC14057@cicely7.cicely.de> <20200816145845.4586b7003e4ad1e885c0199d@bidouilliste.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20200816145845.4586b7003e4ad1e885c0199d@bidouilliste.com> X-Operating-System: FreeBSD cicely7.cicely.de 12.0-STABLE amd64 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-1.9 required=4.5 tests=BAYES_00=-1.9 autolearn=ham version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1597655168; h=from:from:reply-to: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:dkim-signature; bh=D2lIg+iGKaZYoGEu3vqWpgWWosTEvNhIjNaIWb3vdmQ=; b=aP8R8yA0M9V24SoHC6mBrrVOKCFn8tIaMIbCFaZmMtfDWyhUM+yq+cxNO0LTGJbmqVqwwb G7SQDogYKK5xbhIBozHAhYk1nbqFHPmWgJVSdSSAo15ekeY0rSAc/J4lMl4xetEQsWiZJP pZ0tTDLE27IOlrfRgGCtrCm5q+1M/vIqZmQ6DJ/SUQhGfdz0CJAq2SMGkEm6NNxkMbEJVe kJGbGvoYuiOhRFXQqKR4zekt7xIxZYuUCig6tDV9t7Jeju3M2lu61JHEwVfpdB7BMeKVOv Zv7SZiA1cVrs+9aJVNO3aT5EOYJ/M6iPdlMTskQ81ZHFdbBUFtqHPYcXQA0NkA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1597655168; a=rsa-sha256; cv=none; b=Uk0wVoVMXKAgraoJjrMQl1IjAxp/YOvX8oh2415tnfczL5pWf2wkGbm7cyS1wWAJUHCjKt wPkUV9OVF8rOMtQesCCYR7GMNoMAZzL8NId6CBCCUDVe7tf8QlC056RPvbfojE+VOijZ1I uqQg8JF+AeLQjzrcFDzhl7DekQX9xSP2MG95lGCfMJDZn41gW1n+BqT0hKtuDvqRsoavJn EGZ32ga5ipGhcz8iudzLRt5pMrUIS1RXVuJJqjL40Tfgeb8FEwb1H6FnQ+vm1kCn2n900a l5nUFKHI82Yl5trxn0xhbbOgfY04GsqddYOIMdI4pMG7C2xUWFw2D5CSQHaWQA== ARC-Authentication-Results: i=1; mx1.freebsd.org; dkim=pass header.d=cicely.de header.s=default header.b=ig/vqomv; spf=none (mx1.freebsd.org: domain of ticso@cicely7.cicely.de has no SPF policy when checking 2a02:21e0:16e0:fe::101:1) smtp.mailfrom=ticso@cicely7.cicely.de X-Rspamd-Queue-Id: 4BVSnq3kCxz4Qvs X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=cicely.de header.s=default header.b=ig/vqomv; dmarc=none; spf=none (mx1.freebsd.org: domain of ticso@cicely7.cicely.de has no SPF policy when checking 2a02:21e0:16e0:fe::101:1) smtp.mailfrom=ticso@cicely7.cicely.de X-Spamd-Result: default: False [-2.32 / 15.00]; HAS_REPLYTO(0.00)[ticso@cicely.de]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[cicely.de:s=default]; NEURAL_HAM_MEDIUM(-1.01)[-1.006]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; FROM_HAS_DN(0.00)[]; MIME_GOOD(-0.10)[text/plain]; REPLYTO_DOM_NEQ_FROM_DOM(0.00)[]; ARC_SIGNED(0.00)[i=1]; DMARC_NA(0.00)[cicely.de]; NEURAL_HAM_LONG(-1.00)[-0.996]; RCVD_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[cicely.de:+]; NEURAL_HAM_SHORT(-0.52)[-0.517]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:44700, ipnet:2a02:21e0::/32, country:DE]; MID_RHS_MATCH_FROM(0.00)[] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2020 09:06:09 -0000 On Sun, Aug 16, 2020 at 02:58:45PM +0200, Emmanuel Vadot wrote: > On Sat, 15 Aug 2020 13:32:39 +0200 > Bernd Walter wrote: > > > On Fri, Aug 14, 2020 at 06:23:33PM +0200, Søren Schmidt wrote: > > > Hi > > > > > > Now that we have display and all working I hacked up a driver for the cw2015 chip that can tell how much battery is left so I know when to seek an outlet :) > > > > Cool - too bad this is different hardware to my older Allwinner based > > Pinebook. > > axp81x driver supports battery status. Yes - found it after changing a few Mails with Søren Schmidt. [52]pinebook# sysctl dev.axp8xx_pmu dev.axp8xx_pmu.0.batchargecurrentstep: 5 dev.axp8xx_pmu.0.batcurrentcapacity: 0 dev.axp8xx_pmu.0.batmaxcapacity: 0 dev.axp8xx_pmu.0.batcapacitypercent: 100 dev.axp8xx_pmu.0.batdischargecurrent: 1862 dev.axp8xx_pmu.0.batchargecurrent: 1000 dev.axp8xx_pmu.0.batvolt: 4191000 dev.axp8xx_pmu.0.batchargestate: 1 dev.axp8xx_pmu.0.batcharging: 0 dev.axp8xx_pmu.0.bat: 1 dev.axp8xx_pmu.0.vbus: 0 dev.axp8xx_pmu.0.acin: 1 dev.axp8xx_pmu.0.%parent: iicbus1 dev.axp8xx_pmu.0.%pnpinfo: name=pmic@3a3 compat=x-powers,axp803 dev.axp8xx_pmu.0.%location: addr=0x746 dev.axp8xx_pmu.0.%driver: axp8xx_pmu dev.axp8xx_pmu.0.%desc: X-Powers AXP803 Power Management Unit dev.axp8xx_pmu.%parent: [55]pinebook# sysctl -d dev.axp8xx_pmu dev.axp8xx_pmu: dev.axp8xx_pmu.0.batchargecurrentstep: Battery Charging Current Step, 0: 200mA, 1: 400mA, 2: 600mA, 3: 800mA, 4: 1000mA, 5: 1200mA, 6: 1400mA, 7: 1600mA, 8: 1800mA, 9: 2000mA, 10: 2200mA, 11: 2400mA, 12: 2600mA, 13: 2800mA dev.axp8xx_pmu.0.batcurrentcapacity: Battery Current Capacity dev.axp8xx_pmu.0.batmaxcapacity: Battery Maximum Capacity dev.axp8xx_pmu.0.batcapacitypercent: Battery Capacity Percentage dev.axp8xx_pmu.0.batdischargecurrent: Average Battery Discharging Current dev.axp8xx_pmu.0.batchargecurrent: Average Battery Charging Current dev.axp8xx_pmu.0.batvolt: Battery Voltage dev.axp8xx_pmu.0.batchargestate: Battery Charge State dev.axp8xx_pmu.0.batcharging: Battery Charging dev.axp8xx_pmu.0.bat: Battery Present dev.axp8xx_pmu.0.vbus: VBUS Present dev.axp8xx_pmu.0.acin: ACIN Present dev.axp8xx_pmu.0.%parent: parent device dev.axp8xx_pmu.0.%pnpinfo: device identification dev.axp8xx_pmu.0.%location: device location relative to parent dev.axp8xx_pmu.0.%driver: device driver name dev.axp8xx_pmu.0.%desc: device description dev.axp8xx_pmu.%parent: parent class I wasn't aware of this. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@freebsd.org Mon Aug 17 18:43:25 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 0363E3B9597 for ; Mon, 17 Aug 2020 18:43:25 +0000 (UTC) (envelope-from soren.schmidt@gmail.com) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4BVjbw5CLXz44gm for ; Mon, 17 Aug 2020 18:43:24 +0000 (UTC) (envelope-from soren.schmidt@gmail.com) Received: by mailman.nyi.freebsd.org (Postfix) id B0D2F3B9596; Mon, 17 Aug 2020 18:43:24 +0000 (UTC) Delivered-To: arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id B094B3B9711 for ; Mon, 17 Aug 2020 18:43:24 +0000 (UTC) (envelope-from soren.schmidt@gmail.com) Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) (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 4BVjbv62m8z44hY for ; Mon, 17 Aug 2020 18:43:23 +0000 (UTC) (envelope-from soren.schmidt@gmail.com) Received: by mail-wr1-x42a.google.com with SMTP id p20so15986155wrf.0 for ; Mon, 17 Aug 2020 11:43:23 -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=6GtTQ2XaKBoqTEPes8s8lcygr9F9akbD52L97Yw/kf0=; b=SCNoSfkFCUjmkTxhTwZOdYa+keadBd5zOUJK39vsq0pSSaC4BrnvTPO1BmG4iROIAd bTTygeQ+AipTZEkxqK768c5BlUcYwqaJu4y5494mq5f7XEi5GaQSTknZHjXLqNs3Ftxo bdymtaDEDPj73ZdMByxT6I9dqeNxhFejMN5/wafsGp7b61FurZfg8ENhPGURhWj+YGNR g6ggNx3usfVTDy3nkMxD6suUD3q5wDiGsfnSQQFM3MpHBrvDBSX1TzSN3QKUFBP+9qy0 XfLZ+Sf0N/15+szuOy39eCJqa+2FsE3yrx/kvAbyjrSM/3GGAc5zC53JgBYYOxYJXRm7 NruQ== 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=6GtTQ2XaKBoqTEPes8s8lcygr9F9akbD52L97Yw/kf0=; b=So+ZUnRLVL1fyCHWdbgSFU98pJrHysla192/YofBM3ee4odGHqUbfX/5Y86OHz8Rcz pjo21kLOsbOlpsaWPVISSCsladUynT2y1h94OscmZa0Wv7KcGerl2AFqEVY5vtaQU7aZ MdbRfgxjvdFL0TfSVV8hfcut4DeGJxiVriqNtYhABUnS2P57Y3mk0a14VwfUqhm85CXq xiQXkJM4LWFdhfTXY0xbjIy11vEvGsXuo4UW/HdxVDKCrsGgsxi//x8FG3CK5hGN7XoG DgdkuZZI1A9uLxMlAAvcw+oJaqkOJ8xeKY/PhPY/gLq+21dqTZvhkR61sP94LDEG0bom sb0g== X-Gm-Message-State: AOAM532O1mf/BmL4QQ+7qaTC5r49yFFGKM9QtqC77P4LJ7TjHiUGKJSB uYAdbkZgRVwidrwdSXg9N94= X-Google-Smtp-Source: ABdhPJwT2Kr+0ppkS7OZkSlVkqum5hE/lnKboDJ+KvCJ+7Cmu4itgbdOTdkPmspNmX6QvpvGjIi3eA== X-Received: by 2002:a5d:6692:: with SMTP id l18mr16455367wru.211.1597689801274; Mon, 17 Aug 2020 11:43:21 -0700 (PDT) Received: from mac.deepcore.dk ([85.27.186.9]) by smtp.gmail.com with ESMTPSA id q6sm31651017wma.22.2020.08.17.11.43.20 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Aug 2020 11:43:20 -0700 (PDT) From: =?utf-8?Q?S=C3=B8ren_Schmidt?= Message-Id: Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: Pinebook Pro battery fuel-gauge driver.. Date: Mon, 17 Aug 2020 20:43:19 +0200 In-Reply-To: Cc: Emmanuel Vadot , "freebsd-arm@freebsd.org" To: Ganbold Tsagaankhuu References: <20200816150217.b976cb1f516f7f09b7f35c10@bidouilliste.com> <5E285422-EA34-4A8C-9BE2-6B3AEED6AD2F@gmail.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1597689804; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=6GtTQ2XaKBoqTEPes8s8lcygr9F9akbD52L97Yw/kf0=; b=DJcRwdEBwvm1whqyib1fUsPT5L2EDepLEASZghzoNl2hBgSb6aer21Tbd+A2fhh+LAr5ML SOhCX73SyI1l+oGG2oU4srTNWW0V5IIxEz5peoU6c0DQ8F/c/6VN5K96CENEJWZARJ6I83 QEbtkggPYDMTFBNFao1U0gn7rV9/W8SrzE2fsTyCFiyn2mp6MM8hgh4IOlVD1vA43Qj/VO kCbprHRUR3ryrm6SIOJQWEY4Z0qgBG9JGHBbaB768Z3WZ9BR7phP1frh63PT4ZO/EBAv2U /zEGSbCcg6ZSxADZSkXXDe1TCL7St2YtRoy++5V/9bxFRohIfrk30hpk08WQeQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1597689804; a=rsa-sha256; cv=none; b=oEfNojGBjL9/qR6yCCEL3DrChWF8SUl6Hvvzi9EYumRc+LLfkyv5/sKHMgj/uhvI7i6hmB tSi2qsTPuH+DcQ89vOauYFQ2LN6oUGFTsopFjl62lzxjKb9Vf3YPzX7HtE7onDe7ArIMdc eNglIzspTiab2nOhFfHTE9g8yH2G/Fyc+u2+31ls2dhMrjcguhs3ayTrI/G3ldLVeKCSx9 GE8B1xPjujwt+f6LEKRmGqWmtJYQwvJ8BoCUY1L9c7izVVXBtHBqOYyL/86OI2+V5s0Lft lOcFGqfCOrm/awfShqxRtlkxxKP8nt48BX1aqQcW+cNJHGCn4mlngyRhX8M1Rw== ARC-Authentication-Results: i=1; mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=SCNoSfkF; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of sorenschmidt@gmail.com designates 2a00:1450:4864:20::42a as permitted sender) smtp.mailfrom=sorenschmidt@gmail.com X-Rspamd-Queue-Id: 4BVjbv62m8z44hY X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=SCNoSfkF; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of sorenschmidt@gmail.com designates 2a00:1450:4864:20::42a as permitted sender) smtp.mailfrom=sorenschmidt@gmail.com X-Spamd-Result: default: False [-3.23 / 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)[]; ARC_SIGNED(0.00)[i=1]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.27)[-1.269]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; R_MIXED_CHARSET(0.56)[subject]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MID_RHS_MATCH_FROM(0.00)[]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.02)[-1.017]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.003]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[arm@freebsd.org]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::42a:from]; RCVD_TLS_ALL(0.00)[] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2020 18:43:25 -0000 > On 17 Aug 2020, at 04.18, Ganbold Tsagaankhuu = wrote: >=20 > Code was attached to the original mail, I=E2=80=99ll look into getting = a review setup, need to figure out how that works on fabricator though. >=20 >=20 > I don't see any attachment in your original mail. Strange, the maillist SW must have removed them as they are in the mail = I sent=E2=80=A6 Anyhow they are now at https://people.freebsd.org/~sos/PBP/ = -- S=C3=B8ren Schmidt sos@deepcore.dk / sos@freebsd.org "So much code to hack, so little time" From owner-freebsd-arm@freebsd.org Tue Aug 18 03:01:24 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 6E1013AB516 for ; Tue, 18 Aug 2020 03:01:24 +0000 (UTC) (envelope-from furkan@fkardame.com) Received: from sender4-of-o53.zoho.com (sender4-of-o53.zoho.com [136.143.188.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4BVwfT6tl1z4bmS for ; Tue, 18 Aug 2020 03:01:21 +0000 (UTC) (envelope-from furkan@fkardame.com) ARC-Seal: i=1; a=rsa-sha256; t=1597719677; cv=none; d=zohomail.com; s=zohoarc; b=dq8PE5ZvjK1fTdVU4ko9A5h1kEvu1EYick6tCPs6t2ERWc6iUX6PFURBM5U25urKkmtmxZbZmI5JWyLEjhC5FvQtuXSVK3HaPsx/mp4I5QC1p4OJEBPwn6uKxplw+74ReKs0iAIsD+A+sjUwgK25r+phgkpUCRwDZWbFia3Meo4= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1597719677; h=Content-Type:Date:From:MIME-Version:Message-ID:Subject:To; bh=kc0X8kgVyX/udv30WhG6hUuKkB0cm3ZCsy4QXu7Hq3M=; b=M44JAxW9h/Ew1RFrBsxewPw7aPXuJ1/2BQ0p/h+pfeoHKkzQXxyFcIfGKMut0AW2KhnsiyTbxXQHZgztXFMfg4AggIif7ASqJvrBZlQvsbpPV+iwkgMuZSZRjY2Mx527rFUAirN38xP2C+ZPStAnqblYr8NqcI/kyJg5mzNBpvc= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=fkardame.com; spf=pass smtp.mailfrom=furkan@fkardame.com; dmarc=pass header.from= header.from= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1597719677; s=fktech; d=fkardame.com; i=furkan@fkardame.com; h=Date:From:To:Message-Id:In-Reply-To:Subject:MIME-Version:Content-Type; bh=kc0X8kgVyX/udv30WhG6hUuKkB0cm3ZCsy4QXu7Hq3M=; b=RXCcm7x73n7t53tPBQAGujCIirKGVRzACqjD0XOaHeY5LP7bKx+Yjpr/WDBJRDrv HY8dhXOKqYvG3yZD8I+KX53X8/CX1i//wU3JcLLG15nNAZmWI+oDuE1PRKURdA/a62s DonknWngsAbt5+vukXz5Wn5Ftm7sdKj2DwwQJypM= Received: from mail.zoho.com by mx.zohomail.com with SMTP id 1597719675856792.6112728057443; Mon, 17 Aug 2020 20:01:15 -0700 (PDT) Date: Tue, 18 Aug 2020 06:01:15 +0300 From: Furkan Salman To: "Freebsd Arm" Message-Id: <173ff8383c3.114ced33f588171.4981943076988851854@fkardame.com> In-Reply-To: Subject: NanoPi R1 Sample image test MIME-Version: 1.0 Importance: Medium User-Agent: Zoho Mail X-Mailer: Zoho Mail ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1597719684; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:dkim-signature; bh=kc0X8kgVyX/udv30WhG6hUuKkB0cm3ZCsy4QXu7Hq3M=; b=uWlFqKcocw9lYICMMB4algnqb0vJSk21AbtQ3eC7ke1RIYdd+j/IXlJuynRq6ViBP4MQoB YlbUO6bKTHxXpB9bcql4iqXeKudD0YcuLtrvxpFu09FNliiMvit9HD6f2cB/t3xO85PZHe WwjE3SlZmCQrksUO6Csv0ZSHE4eEM0SiK4lQ/Fhwo3YOfUP/ztebuxbwJtCCL9ZZM9y74A LoU/S44epef/teJmepplM31a31an6sehJ0ShG+Jc78kE4I4it5dC/XohljlTawppJ+Jl4e pVji58Huy5bjMHT/pZOWku14jj7v8x/nkAE1V9y+4N5cM3kNrzaqvLGnttX8gQ== ARC-Seal: i=2; s=dkim; d=freebsd.org; t=1597719684; a=rsa-sha256; cv=pass; b=EQQ+E0khGdGhDwD5mhfHpFcn6ur8/sNtb8XRsTvsgVEnvgB81fwcA8baWmD1q5hpw3Vl6u s3QrJzLqf5PMD5lR+5rL8bmjcwi9aiaYgMPttuPQJswh7kqjfL1OTCo5Y0uYqMCexL6JZ7 Dy+Sg5CzCOJFhZxCbBiA8is6QU9twp+nhgUWljB+w605jr+BQNV6QzhAsSao3gUVVjifDv jB5+v1vgfy3agp3StpzsVWdaDs1u5Q6V0ilg6++8QtR+AQ3tfAQL3dO4a7WUo41q1IgbPu E2ZUtSa52aqsmdZGs79ppVIsYaNm+MfN7dfV73A0hezG3+cCl8Ge/OHA8oIJaA== ARC-Authentication-Results: i=2; mx1.freebsd.org; dkim=none (invalid DKIM record) header.d=fkardame.com header.s=fktech header.b=RXCcm7x7; arc=pass (zohomail.com:s=zohoarc:i=1); dmarc=pass (policy=none) header.from=fkardame.com; spf=pass (mx1.freebsd.org: domain of furkan@fkardame.com designates 136.143.188.53 as permitted sender) smtp.mailfrom=furkan@fkardame.com X-Rspamd-Queue-Id: 4BVwfT6tl1z4bmS X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none (invalid DKIM record) header.d=fkardame.com header.s=fktech header.b=RXCcm7x7; dmarc=pass (policy=none) header.from=fkardame.com; spf=pass (mx1.freebsd.org: domain of furkan@fkardame.com designates 136.143.188.53 as permitted sender) smtp.mailfrom=furkan@fkardame.com X-Spamd-Result: default: False [-4.29 / 15.00]; NEURAL_HAM_MEDIUM(-0.98)[-0.985]; RWL_MAILSPIKE_VERYGOOD(0.00)[136.143.188.53:from]; XM_UA_NO_VERSION(0.01)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:136.143.188.0/24]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; ARC_SIGNED(0.00)[i=2]; NEURAL_HAM_LONG(-0.97)[-0.973]; RCPT_COUNT_ONE(0.00)[1]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[fkardame.com:~]; DMARC_POLICY_ALLOW(-0.50)[fkardame.com,none]; RCVD_IN_DNSWL_NONE(0.00)[136.143.188.53:from]; NEURAL_HAM_SHORT(-0.54)[-0.539]; R_DKIM_PERMFAIL(0.00)[fkardame.com:s=fktech]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:2639, ipnet:136.143.188.0/23, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; ARC_ALLOW(-1.00)[zohomail.com:s=zohoarc:i=1] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2020 03:01:24 -0000 Hello, I received my NanoPi R1 and NanoPi R2s of which R2s doesn't work I guess so= was only able to test R1 images from Mr. Ganbold links which are quite old= . Here is the boot log which is getting stuck at mountpoint as it fails to mo= unt opnsense partition with rw access. U-Boot SPL 2019.01 (Mar 19 2019 - 16:56:16 +0800) = =20 DRAM: 1024 MiB = =20 Trying to boot from MMC1 = =20 = =20 = =20 U-Boot 2019.01 (Mar 19 2019 - 16:56:16 +0800) Allwinner Technology = =20 = =20 CPU: Allwinner H3 (SUN8I 1680) = =20 Model: FriendlyArm NanoPi M1 Plus = =20 DRAM: 1 GiB = =20 MMC: SUNXI SD/MMC: 0, SUNXI SD/MMC: 1 = =20 Loading Environment from FAT... *** Warning - bad CRC, using default enviro= nment =20 = =20 In: serial = =20 Out: serial = =20 Err: serial = =20 Net: No ethernet found. = =20 starting USB... = =20 USB0: USB EHCI 1.00 = =20 USB1: USB OHCI 1.0 = =20 USB2: USB EHCI 1.00 = =20 USB3: USB OHCI 1.0 = =20 USB4: USB EHCI 1.00 = =20 USB5: USB OHCI 1.0 = =20 scanning bus 0 for devices... 2 USB Device(s) found = =20 scanning bus 2 for devices... 1 USB Device(s) found = =20 scanning bus 4 for devices... 1 USB Device(s) found = =20 scanning usb for storage devices... 0 Storage Device(s) found = =20 Hit any key to stop autoboot: 0 = =20 switch to partitions #0, OK = =20 mmc0(part 0) is current device = =20 Scanning mmc 0:1... = =20 26950 bytes read in 2 ms (12.9 MiB/s) = =20 Found EFI removable media binary efi/boot/bootarm.efi = =20 Scanning disks on usb... = =20 Disk usb0 not ready = =20 Disk usb1 not ready = =20 Disk usb2 not ready = =20 Disk usb3 not ready = =20 Scanning disks on mmc... = =20 - ______ ____ _____ _____ =20 | ____| | _ \ / ____| __ \=20 | |___ _ __ ___ ___ | |_) | (___ | | | | | ___| '__/ _ \/ _ \| _ < \___ \| | | | | | | | | __/ __/| |_) |____) | |__| | | | | | | | || | | | |_| |_| \___|\___||____/|_____/|_____/=20 ``` = ` =EF=BF=BD=EF=BF=BD=E2=95=90=EF=BF=BD=EF=BF=BD=E2=95=90=EF=BF=BD=E2=95=90= =EF=BF=BD=E2=95=90=EF=BF=BD=E2=95=90=EF=BF=BD=E2=95=90=EF=BF=BD=E2=95=90=EF= =BF=BD=E2=95=90=EF=BF=BD=E2=95=90=EF=BF=BD=E2=95=90=EF=BF=BD=E2=95=90=EF=BF= =BD=E2=95=90=EF=BF=BD=E2=95=90=EF=BF=BD=E2=95=90=EF=BF=BD=E2=95=90=EF=BF=BD= =E2=95=90=EF=BF=BD=E2=95=90=EF=BF=BD=E2=95=90=EF=BF=BD=E2=95=90=EF=BF=BD=E2= =95=90=EF=BF=BD=E2=95=90=EF=BF=BD=EF=BF=BD=E2=95=90=EF=BF=BD=E2=95=90=EF=BF= =BD=E2=95=90=EF=BF=BD=E2=95=90=EF=BF=BD=E2=95=90=EF=BF=BD=E2=95=90=EF=BF=BD= =E2=95=90=EF=BF=BD=E2=95=90=EF=BF=BD=E2=95=90=EF=BF=BD=E2=95=90=EF=BF=BD=E2= =95=90=EF=BF=BD=E2=95=90=EF=BF=BD=E2=95=90=EF=BF=BD=E2=95=90=EF=BF=BD=EF=BF= =BD-/ =E2=95=90 =EF=BF=BD=E2=95=91 =EF=BF=BD=E2=95= =91 +o .--` /y:` +. =EF=BF=BD=E2=95=91 1. Boot Multi user [Enter] =EF=BF=BD=E2=95= =91 yo`:. :o `+- =EF=BF=BD=E2=95=91 2. Boot Single user =EF=BF=BD=E2=95= =91 y/ -/` -o/ =EF=BF=BD=E2=95=91 3. Escape to loader prompt =EF=BF=BD=E2=95= =91 .- ::/sy+:. =EF=BF=BD=E2=95=91 4. Reboot =EF=BF=BD=E2=95= =91 / `-- / =EF=BF=BD=E2=95=91 =EF=BF=BD=E2=95= =91 `: :` =EF=BF=BD=EF=BF=BD=E2=95=91Options: =EF=BF= =BD=E2=95=91 `: :` =EF=BF=BD=E2=95=91 5. Kernel: default/kernel (1 of 1) =EF=BF=BD=E2=95= =91 / / =EF=BF=BD=E2=95=91 6. Boot Options =EF=BF=BD=E2=95= =91 .- -. =EF=BF=BD=E2=95=91 =EF=BF=BD=E2=95= =91 -- -. =EF=BF=BD=E2=95=91 =EF=BF=BD=E2=95= =91 `:` `:` =EF=BF=BD=E2=95=91 =EF=BF=BD=E2=95= =91 .-- `--. =EF=BF=BD=EF=BF=BD=E2=95=90=EF=BF=BD=E2=95=90=EF=BF=BD=E2=95=90=EF=BF=BD= =E2=95=90=EF=BF=BD=E2=95=90=EF=BF=BD=E2=95=90=EF=BF=BD=E2=95=90=EF=BF=BD=E2= =95=90=EF=BF=BD=E2=95=90=EF=BF=BD=E2=95=90=EF=BF=BD=E2=95=90=EF=BF=BD=E2=95= =90=EF=BF=BD=E2=95=90=EF=BF=BD=E2=95=90=EF=BF=BD=EF=BF=BD=E2=95=90=EF=BF=BD= =E2=95=90=EF=BF=BD=E2=95=90=EF=BF=BD=E2=95=90=EF=BF=BD=E2=95=90=EF=BF=BD=E2= =95=90=EF=BF=BD=E2=95=90=EF=BF=BD=EF=BF=BD=E2=95=90=EF=BF=BD=EF=BF=BD=E2=95= =90=EF=BF=BD=E2=95=90=EF=BF=BD=E2=95=90=EF=BF=BD=E2=95=90=EF=BF=BD=E2=95=90= =EF=BF=BD=E2=95=90=EF=BF=BD=E2=95=90=EF=BF=BD=E2=95=90=EF=BF=BD=E2=95=90=EF= =BF=BD=E2=95=90=EF=BF=BD=E2=95=90=EF=BF=BD=E2=95=90=EF=BF=BD=E2=95=90=EF=BF= =BD=EF=BF=BD =E2=95=90 Autoboot in 3 seconds, hit [Enter] to boot or any other key to stop = =20 Autoboot in 2 seconds, hit [Enter] to boot or any other key to stop = =20 Loading kernel... = =20 /boot/kernel/kernel text=3D0x853bb0 data=3D0xb5cc8+0x25d778 syms=3D[0x4+0xa= 8e50+0x4+0x10cbbc] =20 Loading configured modules... = =20 /boot/kernel/if_lagg.ko text=3D0x3f20 text=3D0x7a00 data=3D0x1088+0xf7c sym= s=3D[0x4+0x23e0+0x4+0x1535] =20 /boot/kernel/ng_pppoe.ko text=3D0x1b20 text=3D0x3f20 data=3D0x1088 syms=3D[= 0x4+0xf70+0x4+0x8b9] =20 loading required module 'netgraph' = =20 /boot/kernel/netgraph.ko text=3D0x3f54 text=3D0x8f40 data=3D0x1088+0xfec sy= ms=3D[0x4+0x2550+0x4+0x1de8] =20 /boot/kernel/ng_ppp.ko text=3D0x1df0 text=3D0x4350 data=3D0x1088 syms=3D[0x= 4+0xff0+0x4+0xa59] =20 /boot/kernel/pflog.ko text=3D0xb33 text=3D0x820 data=3D0x1088 syms=3D[0x4+0= x9e0+0x4+0x748] =20 loading required module 'pf' = =20 /boot/kernel/pf.ko text=3D0x8108 text=3D0x30c30 data=3D0x3088+0x1074 syms= =3D[0x4+0x5bf0+0x4+0x3608] =20 /boot/kernel/ng_tcpmss.ko text=3D0xa38 text=3D0x6a0 data=3D0x1088 syms=3D[0= x4+0x690+0x4+0x48c] =20 /boot/kernel/ng_bpf.ko text=3D0x1580 text=3D0x1320 data=3D0x1088 syms=3D[0x= 4+0x9c0+0x4+0x6c8] =20 /boot/kernel/ng_eiface.ko text=3D0x13e0 text=3D0x1200 data=3D0x1088 syms=3D= [0x4+0xf10+0x4+0x964] =20 /boot/kernel/ng_ksocket.ko text=3D0x1974 text=3D0x1d10 data=3D0x1088 syms= =3D[0x4+0x1020+0x4+0x9c7] =20 /boot/kernel/if_gif.ko text=3D0x1e64 text=3D0x3d60 data=3D0x1088+0xfa4 syms= =3D[0x4+0x1b70+0x4+0xff9] =20 /boot/kernel/if_enc.ko text=3D0xf64 text=3D0x9b0 data=3D0x1088 syms=3D[0x4+= 0xba0+0x4+0xbca] =20 /boot/kernel/ng_tty.ko text=3D0xe1d text=3D0xf50 data=3D0x1088 syms=3D[0x4+= 0xb60+0x4+0x58c] =20 /boot/kernel/ng_tee.ko text=3D0xa98 text=3D0x7c0 data=3D0x1088 syms=3D[0x4+= 0x760+0x4+0x46c] =20 /boot/kernel/ng_car.ko text=3D0xe60 text=3D0x1110 data=3D0x1088 syms=3D[0x4= +0x970+0x4+0x59d] =20 /boot/kernel/ng_pred1.ko text=3D0xf64 text=3D0xe40 data=3D0x1088 syms=3D[0x= 4+0x8f0+0x4+0x5e1] =20 /boot/kernel/ng_rfc1490.ko text=3D0xa4c text=3D0xbf0 data=3D0x1088 syms=3D[= 0x4+0x810+0x4+0x486] =20 /boot/kernel/ng_socket.ko text=3D0x178f text=3D0x1730 data=3D0x1088+0xf90 s= yms=3D[0x4+0x12c0+0x4+0xe42] =20 /boot/kernel/ng_pptpgre.ko text=3D0x1c98 text=3D0x2380 data=3D0x1088 syms= =3D[0x4+0xdc0+0x4+0x8d0] =20 /boot/kernel/ng_deflate.ko text=3D0x1008 text=3D0xe90 data=3D0x1088 syms=3D= [0x4+0xb10+0x4+0x71f] =20 /boot/kernel/ng_iface.ko text=3D0x177c text=3D0x10a0 data=3D0x1088 syms=3D[= 0x4+0xfa0+0x4+0xae6] =20 /boot/entropy size=3D0x1000 = =20 /boot/kernel/ng_ether.ko text=3D0x1554 text=3D0x1350 data=3D0x1088+0xf7c sy= ms=3D[0x4+0xeb0+0x4+0x94b] =20 /boot/kernel/ng_mppc.ko text=3D0xf70 text=3D0x2cc0 data=3D0x1088+0xf7c syms= =3D[0x4+0xc10+0x4+0x8c1] =20 loading required module 'rc4' = =20 /boot/kernel/rc4.ko text=3D0x3d7 text=3D0xf8 data=3D0x1068 syms=3D[0x4+0x2a= 0+0x4+0x229] =20 /boot/kernel/ng_pipe.ko text=3D0x14d4 text=3D0x1e40 data=3D0x1088+0xf90 sym= s=3D[0x4+0xc30+0x4+0x766] =20 /boot/kernel/ng_one2many.ko text=3D0xe4c text=3D0xbc0 data=3D0x1088 syms=3D= [0x4+0x950+0x4+0x608] =20 /boot/kernel/ng_echo.ko text=3D0x57d text=3D0x160 data=3D0x1088 syms=3D[0x4= +0x430+0x4+0x302] =20 /boot/kernel/if_tap.ko text=3D0x1d38 text=3D0x2490 data=3D0x1088+0xfac syms= =3D[0x4+0x15c0+0x4+0xb08] =20 /boot/kernel/ng_lmi.ko text=3D0x111f text=3D0x16e0 data=3D0x1088 syms=3D[0x= 4+0x900+0x4+0x48f] =20 /boot/kernel/ng_l2tp.ko text=3D0x21b8 text=3D0x2990 data=3D0x1088 syms=3D[0= x4+0xde0+0x4+0x8ce] =20 /boot/kernel/ng_vlan.ko text=3D0xe90 text=3D0xd20 data=3D0x1088 syms=3D[0x4= +0x8b0+0x4+0x55b] =20 /boot/kernel/if_ure.ko text=3D0x1a20 text=3D0x50f0 data=3D0x1088+0xf80 syms= =3D[0x4+0x13d0+0x4+0xd26] =20 /boot/kernel/ng_frame_relay.ko text=3D0x857 text=3D0x8d0 data=3D0x1088 syms= =3D[0x4+0x740+0x4+0x3f2] =20 /boot/kernel/ng_hole.ko text=3D0x850 text=3D0x350 data=3D0x1088 syms=3D[0x4= +0x5d0+0x4+0x3db] =20 /boot/kernel/if_bridge.ko text=3D0x2cc0 text=3D0x6580 data=3D0x1088+0xf7c s= yms=3D[0x4+0x2220+0x4+0x16a5] =20 loading required module 'bridgestp' = =20 /boot/kernel/bridgestp.ko text=3D0x1138 text=3D0x4550 data=3D0x1088+0xf90 s= yms=3D[0x4+0xf20+0x4+0x870] =20 /boot/kernel/ng_async.ko text=3D0x10d0 text=3D0xe80 data=3D0x1088 syms=3D[0= x4+0x9d0+0x4+0x64c] =20 /boot/kernel/pfsync.ko text=3D0x2cb4 text=3D0x7b70 data=3D0x1088+0xf7c syms= =3D[0x4+0x1cb0+0x4+0x12b3] =20 /boot/kernel/carp.ko text=3D0x2dac text=3D0x6110 data=3D0x1088+0xfa4 syms= =3D[0x4+0x1e40+0x4+0x1333] =20 /boot/kernel/ng_bridge.ko text=3D0x15dc text=3D0x1550 data=3D0x1088+0xf98 s= yms=3D[0x4+0xb80+0x4+0x7f5] =20 /boot/kernel/if_tun.ko text=3D0x235e text=3D0x2960 data=3D0x1088+0xf9c syms= =3D[0x4+0x1aa0+0x4+0xdf1] =20 /boot/kernel/ng_UI.ko text=3D0x78f text=3D0x4a0 data=3D0x1088 syms=3D[0x4+0= x690+0x4+0x396] =20 /boot/kernel/ng_cisco.ko text=3D0xee4 text=3D0xfe0 data=3D0x1088 syms=3D[0x= 4+0xa30+0x4+0x5ad] =20 /boot/kernel/if_gre.ko text=3D0x1e4c text=3D0x3790 data=3D0x1088+0xf9c syms= =3D[0x4+0x19c0+0x4+0xf24] =20 /boot/kernel/ng_vjc.ko text=3D0x1154 text=3D0x1910 data=3D0x1088 syms=3D[0x= 4+0x9d0+0x4+0x61b] =20 Using DTB provided by EFI at 0x47ef6000. = =20 Loading DTB overlays: 'sun8i-h3-sid.dtbo,sun8i-h3-ths.dtbo' = =20 /boot/dtb/overlays/sun8i-h3-sid.dtbo size=3D0x210 = =20 /boot/dtb/overlays/sun8i-h3-ths.dtbo size=3D0x3ba = =20 Kernel entry at 0x71000180... = =20 Kernel args: (null) = =20 applying DTB overlay '/boot/dtb/overlays/sun8i-h3-sid.dtbo' = =20 applying DTB overlay '/boot/dtb/overlays/sun8i-h3-ths.dtbo' = =20 EHCI failed to shut down host controller. = =20 EHCI failed to shut down host controller. = =20 EHCI failed to shut down host controller. = =20 ---<>--- = =20 KDB: debugger backends: ddb = =20 KDB: current backend: ddb = =20 Copyright (c) 1992-2019 The FreeBSD Project. = =20 Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 = =20 The Regents of the University of California. All rights reserved. = =20 FreeBSD is a registered trademark of The FreeBSD Foundation. = =20 FreeBSD 13.0-CURRENT #37 r345944M: Tue Apr 23 18:10:40 +08 2019 = =20 tsgan@beastie:/usr/obj/usr/src/arm.armv7/sys/GENERIC arm = =20 FreeBSD clang version 8.0.0 (tags/RELEASE_800/final 356365) (based on LLVM = 8.0.0) =20 WARNING: WITNESS option enabled, expect reduced performance. = =20 VT: init without driver. = =20 module_register: cannot register ofwbus/pcib from kernel; already loaded fr= om kernel =20 Module ofwbus/pcib failed to register: 17 = =20 module_register: cannot register simplebus/pcib from kernel; already loaded= from kernel =20 Module simplebus/pcib failed to register: 17 = =20 CPU: ARM Cortex-A7 r0p5 (ECO: 0x00000000) = =20 CPU Features: = =20 Multiprocessing, Thumb2, Security, Virtualization, Generic Timer, VMSAv7,= =20 PXN, LPAE, Coherent Walk = =20 Optional instructions: = =20 SDIV/UDIV, UMULL, SMULL, SIMD(ext) = =20 LoUU:2 LoC:3 LoUIS:2 = =20 Cache level 1: = =20 32KB/64B 4-way data cache WB Read-Alloc Write-Alloc = =20 32KB/32B 2-way instruction cache Read-Alloc = =20 Cache level 2: = =20 512KB/64B 8-way unified cache WB Read-Alloc Write-Alloc = =20 real memory =3D 1039556608 (991 MB) = =20 avail memory =3D 997736448 (951 MB) = =20 No PSCI/SMCCC call function found = =20 FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs = =20 random: unblocking device. = =20 random: entropy device external interface = =20 kbd0 at kbdmux0 = =20 ofwbus0: = =20 aw_ccu0: on ofwbus0 = =20 clk_fixed0: on aw_ccu0 = =20 clk_fixed1: on aw_ccu0 = =20 clk_fixed2: on aw_ccu0 = =20 simplebus0: on ofwbus0 = =20 ccu_h3ng0: mem 0x1c20000-0x1c203ff = on simplebus0 =20 regfix0: on ofwbus0 = =20 regfix1: on ofwbus0 = =20 regfix2: on ofwbus0 = =20 regfix3: on ofwbus0 = =20 ccu_sun8i_r0: mem 0x1f01400-0x1f0= 14ff on simplebus0 =20 aw_sid0: mem 0x1c14000-0x1c143ff on simple= bus0 =20 gic0: mem 0x1c81000-0x1c81fff,0x1c82000-= 0x1c83fff,0x1c84000-0x1c85fff,0x10 gic0: pn 0x1, arch 0x2, rev 0x1, implementer 0x43b irqs 160 = =20 gpio0: mem 0x1c20800-0x1c20bff irq 19,20= on simplebus0 =20 gpiobus0: on gpio0 = =20 gpio1: mem 0x1f02c00-0x1f02fff irq 44 on= simplebus0 =20 gpiobus1: on gpio1 = =20 rtc0: mem 0x1f00000-0x1f00053 irq 40,41 on simplebus0 = =20 rtc0: registered as a time-of-day clock, resolution 1.000000s = =20 generic_timer0: irq 0,1,2,3 on ofwbus0 = =20 Timecounter "ARM MPCore Timecounter" frequency 24000000 Hz quality 1000 = =20 Event timer "ARM MPCore Eventtimer" frequency 24000000 Hz quality 1000 = =20 aw_syscon0: mem 0x1c00000-0x1c00fff on simplebus0 = =20 awusbphy0: mem 0x1c19400-0x1c1942b,0x1c1a800-0x1c1a803,= 0x1c1b800-0x1c1b803,0x1c1c800-0x10 aw_thermal0: mem 0x1c25000-0x1c250ff = irq 4 on simplebus0 =20 a31dmac0: mem 0x1c02000-0x1c02fff irq 5 on simpl= ebus0 =20 aw_mmc0: mem 0x1c0f000-0x1c0ffff i= rq 7 on simplebus0 =20 mmc0: on aw_mmc0 = =20 aw_mmc1: mem 0x1c10000-0x1c10fff i= rq 8 on simplebus0 =20 mmc1: on aw_mmc1 = =20 aw_mmc2: mem 0x1c11000-0x1c11fff i= rq 9 on simplebus0 =20 mmc2: on aw_mmc2 = =20 ehci0: mem 0x1c1b000-0x1c1b0ff ir= q 13 on simplebus0 =20 usbus0: EHCI version 1.0 = =20 usbus0 on ehci0 = =20 ohci0: mem 0x1c1b400-0x1c1b4ff irq 14 on simplebu= s0 =20 usbus1 on ohci0 = =20 ehci1: mem 0x1c1c000-0x1c1c0ff ir= q 15 on simplebus0 =20 usbus2: EHCI version 1.0 = =20 usbus2 on ehci1 = =20 ohci1: mem 0x1c1c400-0x1c1c4ff irq 16 on simplebu= s0 =20 usbus3 on ohci1 = =20 ehci2: mem 0x1c1d000-0x1c1d0ff ir= q 17 on simplebus0 =20 usbus4: EHCI version 1.0 = =20 usbus4 on ehci2 = =20 ohci2: mem 0x1c1d400-0x1c1d4ff irq 18 on simplebu= s0 =20 usbus5 on ohci2 = =20 gpioc0: on gpio0 = =20 awg0: mem 0x1c30000-0x1c3ffff irq 23 on simple= bus0 =20 miibus0: on awg0 = =20 rgephy0: PHY 0 on miibus0 = =20 rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseT= X-FDX, 100baseTX-FDX-flow, 1000baw rgephy1: PHY 7 on miibus0 = =20 rgephy1: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseT= X-FDX, 100baseTX-FDX-flow, 1000baw awg0: Ethernet address: 02:02:53:04:22:5c = =20 aw_wdog0: mem 0x1c20ca0-0x1c20cbf irq 26 on simple= bus0 =20 uart0: console (115384,n,8,1)mem 0x1c28000-0x1c283ff irq 31 on simplebus0 = =20 uart1: <16750 or compatible> mem 0x1c28c00-0x1c28fff irq 34 on simplebus0 = =20 aw_ir0: mem 0x1f02000-0x1f023ff irq 42 on simple= bus0 =20 aw_ir0: hwreset_get_by_ofw_idx =3D 0 = =20 gpioc1: on gpio1 = =20 cpulist0: on ofwbus0 = =20 cpu0: on cpulist0 = =20 cpu1: on cpulist0 = =20 cpu2: on cpulist0 = =20 cpu3: on cpulist0 = =20 gpioled0: on ofwbus0 = =20 cryptosoft0: = =20 Timecounters tick every 1.000 msec = =20 usbus0: 480Mbps High Speed USB v2.0 = =20 usbus1: 12Mbps Full Speed USB v1.0 = =20 usbus2: 480Mbps High Speed USB v2.0 = =20 usbus3: 12Mbps Full Speed USB v1.0 = =20 usbus4: 480Mbps High Speed USB v2.0 = =20 ugen1.1: at usbus1 = =20 uhub0: on usbus1 = =20 ugen2.1: at usbus2 = =20 uhub1: on usbus= 2 =20 ugen3.1: at usbus3 = =20 uhub2: on usbus3 = =20 ugen4.1: at usbus4 = =20 uhub3: on usbus= 4 =20 ugen0.1: at usbus0 = =20 uhub4: on usbus= 0 =20 usbus5: 12Mbps Full Speed USB v1.0 = =20 AW_MMC_INT_RESP_TIMEOUT = =20 AW_MMC_INT_RESP_TIMEOUT = =20 AW_MMC_INT_RESP_TIMEOUT = =20 ugen5.1: at usbus5 = =20 uhub5: on usbus5 = =20 AW_MMC_INT_RESP_TIMEOUT = =20 AW_MMC_INT_RESP_TIMEOUT = =20 AW_MMC_INT_RESP_TIMEOUT = =20 AW_MMC_INT_RESP_TIMEOUT = =20 AW_MMC_INT_RESP_TIMEOUT = =20 AW_MMC_INT_RESP_ERR AW_MMC_INT_RESP_CRC_ERR = =20 AW_MMC_INT_RESP_TIMEOUT = =20 AW_MMC_INT_RESP_TIMEOUT = =20 AW_MMC_INT_RESP_TIMEOUT = =20 mmc0: CMD3 failed, RESULT: 1 = =20 mmc0: Error setting RCA 1 = =20 AW_MMC_INT_RESP_TIMEOUT = =20 AW_MMC_INT_RESP_TIMEOUT = =20 AW_MMC_INT_RESP_TIMEOUT = =20 AW_MMC_INT_RESP_TIMEOUT = =20 AW_MMC_INT_RESP_TIMEOUT = =20 AW_MMC_INT_RESP_TIMEOUT = =20 AW_MMC_INT_RESP_TIMEOUT = =20 AW_MMC_INT_RESP_TIMEOUT = =20 AW_MMC_INT_RESP_TIMEOUT = =20 AW_MMC_INT_RESP_TIMEOUT = =20 AW_MMC_INT_RESP_TIMEOUT = =20 AW_MMC_INT_RESP_TIMEOUT = =20 mmc1: No compatible cards found on bus = =20 aw_mmc1: Spurious interrupt - no active request, rint: 0x00000004 = =20 = =20 AW_MMC_INT_RESP_TIMEOUT = =20 AW_MMC_INT_RESP_TIMEOUT = =20 AW_MMC_INT_RESP_TIMEOUT = =20 AW_MMC_INT_RESP_TIMEOUT = =20 AW_MMC_INT_RESP_TIMEOUT = =20 AW_MMC_INT_RESP_TIMEOUT = =20 AW_MMC_INT_RESP_TIMEOUT = =20 AW_MMC_INT_RESP_TIMEOUT = =20 uhub0: 1 port with 1 removable, self powered = =20 uhub2: 1 port with 1 removable, self powered = =20 AW_MMC_INT_DATA_END_BIT_ERR = =20 AW_MMC_INT_RESP_TIMEOUT = =20 AW_MMC_INT_RESP_TIMEOUT = =20 AW_MMC_INT_RESP_TIMEOUT = =20 AW_MMC_INT_RESP_TIMEOUT = =20 mmcsd0: 8GB at mmc2= 52.0MHz/8bit/32768-block =20 mmcsd0boot0: 4MB partion 1 at mmcsd0 = =20 mmcsd0boot1: 4MB partion 2 at mmcsd0 = =20 mmcsd0rpmb: 524kB partion 3 at mmcsd0 = =20 Release APs = =20 WARNING: WITNESS option enabled, expect reduced performance. = =20 uhub5: 1 port with 1 removable, self powered = =20 Trying to mount root from ufs:/dev/ufs/OPNsense [rw]... = =20 Root mount waiting for: usbus4 usbus2 usbus0 = =20 uhub3: 1 port with 1 removable, self powered = =20 uhub1: 1 port with 1 removable, self powered = =20 uhub4: 1 port with 1 removable, self powered = =20 ugen0.2: at usbus0 = =20 ure0 on uhub4 = =20 ure0: on usbus0= =20 mountroot: waiting for device /dev/ufs/OPNsense... = =20 ure0: MAC assigned randomly = =20 miibus1: on ure0 = =20 rlphy0: PHY 0 on miibus1 = =20 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto = =20 ue0: on ure0 = =20 ue0: Ethernet address: aa:45:b5:64:b1:70 = =20 Mounting from ufs:/dev/ufs/OPNsense failed with error 19. = =20 = =20 Loader variables: = =20 vfs.root.mountfrom=3Dufs:/dev/ufs/OPNsense = =20 vfs.root.mountfrom.options=3Drw = =20 = =20 Manual root filesystem specification: = =20 : [options] = =20 Mount using filesystem = =20 and with the specified (optional) option list. = =20 = =20 eg. ufs:/dev/da0s1a = =20 zfs:zroot/ROOT/default = =20 cd9660:/dev/cd0 ro = =20 (which is equivalent to: mount -t cd9660 -o ro /dev/cd0 /) = =20 = =20 ? List valid disk boot devices = =20 . Yield 1 second (for background tasks) = =20 Abort manual input = =20 = =20 mountroot> ls = =20 Invalid file system specification. = =20 = =20 mountroot>=20 >From the above logs I see that both the ethernet cards were detected. I then tried the FreeBSD image from the same link and it have the same issu= e. Link:=C2=A0https://people.freebsd.org/~ganbold/ Is anyone else working on armv7 NanoPi R1? From owner-freebsd-arm@freebsd.org Tue Aug 18 04:18:15 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 18B563AD071 for ; Tue, 18 Aug 2020 04:18:15 +0000 (UTC) (envelope-from ganbold@gmail.com) Received: from mail-ot1-x32f.google.com (mail-ot1-x32f.google.com [IPv6:2607:f8b0:4864:20::32f]) (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 4BVyM94xmkz4gmx for ; Tue, 18 Aug 2020 04:18:13 +0000 (UTC) (envelope-from ganbold@gmail.com) Received: by mail-ot1-x32f.google.com with SMTP id 93so15266577otx.2 for ; Mon, 17 Aug 2020 21:18:13 -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=oH9MJq8culAZ3j5Pdr2C3JiLb5J6ver+nybvzmFoZI8=; b=G4eMDewrQgBuszKcUE4LLRlwbGGgdHOVmhIkJEZXRMSpneoMKjXeD0MJmjlwLHX2IW iTfkxK6JsDl2pgaKTq0S4OU5WntuO+xW+XilrOkRzPVv+6vV8NXVgM3Al+p0ypsPaTaY +GiD/a42DzJrNXU6oTaZXtqAlPe8IR2n1yWgZa1gwrG8hkH010W5EfA+p+Sn6R040432 RUnXEcSGS4RahS/XKEDMVtoG3mngWtrt5Pv9+uyGVC/jCNeYWvWW1wJUA0Icp0ZyqqsX 5+b9aUDWaFfAr411B9gRIZTH//eXuwSOuDK2fnSlT8IZJ9DkUUh9BxTUD31k47uQKJQ9 cZjg== 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=oH9MJq8culAZ3j5Pdr2C3JiLb5J6ver+nybvzmFoZI8=; b=QcEpBe4rsz0kcQBjx73wU+HFXrBP5Lfs7raRghmGif5nSQwKxw21WvYhz39jQ8LPL3 u8xOozLTSlqTnDeM2TzCJ+7xfi1LZoJAEAMAxrqVOJaP0Huyuv5/Ztqt38/4AjGYjQ7V xd2wPJtjvZF7ezLcVaNTQyywd8wvn3eSOcs3RX1OZLbTStXBhxLBJsgeuwjN92re0BMl bX5SVAUj7feOY5S6z3kjRCxhIf2SLscA5MBqQ2J0SkZDj0SQWo0/eDDcjS4iroDcFFe8 2FSLp+3UUu/5YW9XignmwMRPOF72+uDVVcS4vG0YXuwp8JniuipjQL2yHRdBAqgt2rGM IkWg== X-Gm-Message-State: AOAM530M+HT0SrgwKMrV8CMhh+A4pPXDClSJyyVYMVgU7/L7JvRYOdbA rt7bGopuoDJt5fMgSS6uBKnU8c9bvXj8D2CaHIcIVcGMSvs= X-Google-Smtp-Source: ABdhPJzZ+P8TtTXMmzByXeqsqI4+UsjQpMSbGZJsQ4Q4VxdFg4ERS7GG53pvMsOUv5wp/5eqYI0D8VfL2f+4mNLm14I= X-Received: by 2002:a9d:639a:: with SMTP id w26mr13700288otk.140.1597724292044; Mon, 17 Aug 2020 21:18:12 -0700 (PDT) MIME-Version: 1.0 References: <173ff8383c3.114ced33f588171.4981943076988851854@fkardame.com> In-Reply-To: <173ff8383c3.114ced33f588171.4981943076988851854@fkardame.com> From: Ganbold Tsagaankhuu Date: Tue, 18 Aug 2020 12:18:00 +0800 Message-ID: Subject: Re: NanoPi R1 Sample image test To: Furkan Salman Cc: Freebsd Arm ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1597724294; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=oH9MJq8culAZ3j5Pdr2C3JiLb5J6ver+nybvzmFoZI8=; b=uAc+tzGk0+/ptjpu2pmwdOe/8wCeK3UwWo2MgsoEWqGGs6svQ40J2HvObG6GAekod2efqB Dp2EF4pP0Hnp6mRrw6vANC7qxoIqSCz8hLpC/oI9qsOWvcHFNfVfqE9uRQkIOsYNB+41AC fY64M8cenqh6UqcUftJKiabyQWGoRLuctclgoBm7NgVZoXInXPMjSPCBVtRvsRP2KVvUpx zQu8sIHmjaMKDoi1spo3k6Uwh0dduy+Ooirq5MbmY4ZBn5EooKX6BuUr88lBRoEVfJIL5N WR8o0T4OwmBr6bAQEqLnzZbq1dXP74DLF7uIHEouGZ1P/dwY5k7OlPz5nTKRQQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1597724294; a=rsa-sha256; cv=none; b=W/jsao8J67LXU/FTI87Tn26h5mlQTgpPdB3Sjdsa/LSfmSsCF+HfXM48/9SDkzJQLpxT9G aVk6+ApFln2Tte/8w+5rwdoq2gmVKlIsNlRXR3UyPlIgLwW92rPjrAmP89rgQska+NYY9l qbSWJJXQXQqVlBaTmR8zcg6eJE7QSorVU3TgnpF43hsry6FqqBL28EHMMGh68dZEBly5Zw k9ZAoUANO85YntipkBbJBd7lyUibcLvGtdE8qWtBEpvN/pt1Zua3mAtzDa/rL7PvZ18knR g5I8391iMM7lSyZmVztmUcMOAHZPowjQ8lbSpSvfvykkZ95dzK55aBA1/tlFKQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=G4eMDewr; spf=pass (mx1.freebsd.org: domain of ganbold@gmail.com designates 2607:f8b0:4864:20::32f as permitted sender) smtp.mailfrom=ganbold@gmail.com X-Rspamd-Queue-Id: 4BVyM94xmkz4gmx X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=G4eMDewr; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of ganbold@gmail.com designates 2607:f8b0:4864:20::32f as permitted sender) smtp.mailfrom=ganbold@gmail.com X-Spamd-Result: default: False [-3.34 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.97)[-0.974]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; ARC_SIGNED(0.00)[i=1]; NEURAL_HAM_LONG(-1.00)[-0.997]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MIME_BASE64_TEXT(0.10)[]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::32f:from]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.47)[-0.474]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2020 04:18:15 -0000 On Tue, Aug 18, 2020 at 11:01 AM Furkan Salman wrote: > Hello, > > > > I received my NanoPi R1 and NanoPi R2s of which R2s doesn't work I guess > so was only able to test R1 images from Mr. Ganbold links which are quite > old. > > > > Here is the boot log which is getting stuck at mountpoint as it fails to > mount opnsense partition with rw access. > > > > U-Boot SPL 2019.01 (Mar 19 2019 - 16:56:16 +0800) > > DRAM: 1024 MiB > > Trying to boot from MMC1 > > > > U-Boot 2019.01 (Mar 19 2019 - 16:56:16 +0800) Allwinner Technology > > > CPU: Allwinner H3 (SUN8I 1680) > > Model: FriendlyArm NanoPi M1 Plus > > DRAM: 1 GiB > > MMC: SUNXI SD/MMC: 0, SUNXI SD/MMC: 1 > > Loading Environment from FAT... *** Warning - bad CRC, using default > environment > > In: serial > > Out: serial > > Err: serial > > Net: No ethernet found. > > starting USB... > > USB0: USB EHCI 1.00 > > USB1: USB OHCI 1.0 > > USB2: USB EHCI 1.00 > > USB3: USB OHCI 1.0 > > USB4: USB EHCI 1.00 > > USB5: USB OHCI 1.0 > > scanning bus 0 for devices... 2 USB Device(s) found > > scanning bus 2 for devices... 1 USB Device(s) found > > scanning bus 4 for devices... 1 USB Device(s) found > > scanning usb for storage devices... 0 Storage Device(s) found > > Hit any key to stop autoboot: 0 > > switch to partitions #0, OK > > mmc0(part 0) is current device > > Scanning mmc 0:1... > > 26950 bytes read in 2 ms (12.9 MiB/s) > > Found EFI removable media binary efi/boot/bootarm.efi > > Scanning disks on usb... > > Disk usb0 not ready > > Disk usb1 not ready > > Disk usb2 not ready > > Disk usb3 not ready > > Scanning disks on mmc... > > - ______ ____ _____ _____ > | ____| | _ \ / ____| __ \ > | |___ _ __ ___ ___ | |_) | (___ | | | | > | ___| '__/ _ \/ _ \| _ < \___ \| | | | > | | | | | __/ __/| |_) |____) | |__| | > | | | | | | || | | | > |_| |_| \___|\___||____/|_____/|_____/ > ``` > ` > =EF=BF=BD=EF=BF=BD=E2=95=90=EF=BF=BD=EF=BF=BD=E2=95=90=EF=BF=BD=E2=95=90= =EF=BF=BD=E2=95=90=EF=BF=BD=E2=95=90=EF=BF=BD=E2=95=90=EF=BF=BD=E2=95=90=EF= =BF=BD=E2=95=90=EF=BF=BD=E2=95=90=EF=BF=BD=E2=95=90=EF=BF=BD=E2=95=90=EF=BF= =BD=E2=95=90=EF=BF=BD=E2=95=90=EF=BF=BD=E2=95=90=EF=BF=BD=E2=95=90=EF=BF=BD= =E2=95=90=EF=BF=BD=E2=95=90=EF=BF=BD=E2=95=90=EF=BF=BD=E2=95=90=EF=BF=BD=E2= =95=90=EF=BF=BD=E2=95=90=EF=BF=BD=EF=BF=BD=E2=95=90=EF=BF=BD=E2=95=90=EF=BF= =BD=E2=95=90=EF=BF=BD=E2=95=90=EF=BF=BD=E2=95=90=EF=BF=BD=E2=95=90=EF=BF=BD= =E2=95=90=EF=BF=BD=E2=95=90=EF=BF=BD=E2=95=90=EF=BF=BD=E2=95=90=EF=BF=BD=E2= =95=90=EF=BF=BD=E2=95=90=EF=BF=BD=E2=95=90=EF=BF=BD=E2=95=90=EF=BF=BD=EF=BF= =BD-/ > =E2=95=90 > =EF=BF=BD=E2=95=91 =EF=BF=BD=E2= =95=91 +o .--` /y:` > +. > =EF=BF=BD=E2=95=91 1. Boot Multi user [Enter] =EF=BF=BD=E2= =95=91 yo`:. :o > `+- > =EF=BF=BD=E2=95=91 2. Boot Single user =EF=BF=BD=E2= =95=91 y/ -/` > -o/ > =EF=BF=BD=E2=95=91 3. Escape to loader prompt =EF=BF=BD=E2= =95=91 .- > ::/sy+:. > =EF=BF=BD=E2=95=91 4. Reboot =EF=BF=BD=E2= =95=91 / > `-- / > =EF=BF=BD=E2=95=91 =EF=BF=BD=E2= =95=91 `: > :` > =EF=BF=BD=EF=BF=BD=E2=95=91Options: =EF=BF= =BD=E2=95=91 `: > :` > =EF=BF=BD=E2=95=91 5. Kernel: default/kernel (1 of 1) =EF=BF=BD=E2= =95=91 / > / > =EF=BF=BD=E2=95=91 6. Boot Options =EF=BF=BD=E2= =95=91 .- > -. > =EF=BF=BD=E2=95=91 =EF=BF=BD=E2= =95=91 -- > -. > =EF=BF=BD=E2=95=91 =EF=BF=BD=E2= =95=91 `:` `:` > =EF=BF=BD=E2=95=91 =EF=BF=BD=E2= =95=91 .-- `--. > =EF=BF=BD=EF=BF=BD=E2=95=90=EF=BF=BD=E2=95=90=EF=BF=BD=E2=95=90=EF=BF=BD= =E2=95=90=EF=BF=BD=E2=95=90=EF=BF=BD=E2=95=90=EF=BF=BD=E2=95=90=EF=BF=BD=E2= =95=90=EF=BF=BD=E2=95=90=EF=BF=BD=E2=95=90=EF=BF=BD=E2=95=90=EF=BF=BD=E2=95= =90=EF=BF=BD=E2=95=90=EF=BF=BD=E2=95=90=EF=BF=BD=EF=BF=BD=E2=95=90=EF=BF=BD= =E2=95=90=EF=BF=BD=E2=95=90=EF=BF=BD=E2=95=90=EF=BF=BD=E2=95=90=EF=BF=BD=E2= =95=90=EF=BF=BD=E2=95=90=EF=BF=BD=EF=BF=BD=E2=95=90=EF=BF=BD=EF=BF=BD=E2=95= =90=EF=BF=BD=E2=95=90=EF=BF=BD=E2=95=90=EF=BF=BD=E2=95=90=EF=BF=BD=E2=95=90= =EF=BF=BD=E2=95=90=EF=BF=BD=E2=95=90=EF=BF=BD=E2=95=90=EF=BF=BD=E2=95=90=EF= =BF=BD=E2=95=90=EF=BF=BD=E2=95=90=EF=BF=BD=E2=95=90=EF=BF=BD=E2=95=90=EF=BF= =BD=EF=BF=BD > =E2=95=90 > Autoboot in 3 seconds, hit [Enter] to boot or any other key to stop > > Autoboot in 2 seconds, hit [Enter] to boot or any other key to stop > > Loading kernel... > > /boot/kernel/kernel text=3D0x853bb0 data=3D0xb5cc8+0x25d778 > syms=3D[0x4+0xa8e50+0x4+0x10cbbc] > Loading configured modules... > > /boot/kernel/if_lagg.ko text=3D0x3f20 text=3D0x7a00 data=3D0x1088+0xf7c > syms=3D[0x4+0x23e0+0x4+0x1535] > /boot/kernel/ng_pppoe.ko text=3D0x1b20 text=3D0x3f20 data=3D0x1088 > syms=3D[0x4+0xf70+0x4+0x8b9] > loading required module 'netgraph' > > /boot/kernel/netgraph.ko text=3D0x3f54 text=3D0x8f40 data=3D0x1088+0xfec > syms=3D[0x4+0x2550+0x4+0x1de8] > /boot/kernel/ng_ppp.ko text=3D0x1df0 text=3D0x4350 data=3D0x1088 > syms=3D[0x4+0xff0+0x4+0xa59] > /boot/kernel/pflog.ko text=3D0xb33 text=3D0x820 data=3D0x1088 > syms=3D[0x4+0x9e0+0x4+0x748] > loading required module 'pf' > > /boot/kernel/pf.ko text=3D0x8108 text=3D0x30c30 data=3D0x3088+0x1074 > syms=3D[0x4+0x5bf0+0x4+0x3608] > /boot/kernel/ng_tcpmss.ko text=3D0xa38 text=3D0x6a0 data=3D0x1088 > syms=3D[0x4+0x690+0x4+0x48c] > /boot/kernel/ng_bpf.ko text=3D0x1580 text=3D0x1320 data=3D0x1088 > syms=3D[0x4+0x9c0+0x4+0x6c8] > /boot/kernel/ng_eiface.ko text=3D0x13e0 text=3D0x1200 data=3D0x1088 > syms=3D[0x4+0xf10+0x4+0x964] > /boot/kernel/ng_ksocket.ko text=3D0x1974 text=3D0x1d10 data=3D0x1088 > syms=3D[0x4+0x1020+0x4+0x9c7] > /boot/kernel/if_gif.ko text=3D0x1e64 text=3D0x3d60 data=3D0x1088+0xfa4 > syms=3D[0x4+0x1b70+0x4+0xff9] > /boot/kernel/if_enc.ko text=3D0xf64 text=3D0x9b0 data=3D0x1088 > syms=3D[0x4+0xba0+0x4+0xbca] > /boot/kernel/ng_tty.ko text=3D0xe1d text=3D0xf50 data=3D0x1088 > syms=3D[0x4+0xb60+0x4+0x58c] > /boot/kernel/ng_tee.ko text=3D0xa98 text=3D0x7c0 data=3D0x1088 > syms=3D[0x4+0x760+0x4+0x46c] > /boot/kernel/ng_car.ko text=3D0xe60 text=3D0x1110 data=3D0x1088 > syms=3D[0x4+0x970+0x4+0x59d] > /boot/kernel/ng_pred1.ko text=3D0xf64 text=3D0xe40 data=3D0x1088 > syms=3D[0x4+0x8f0+0x4+0x5e1] > /boot/kernel/ng_rfc1490.ko text=3D0xa4c text=3D0xbf0 data=3D0x1088 > syms=3D[0x4+0x810+0x4+0x486] > /boot/kernel/ng_socket.ko text=3D0x178f text=3D0x1730 data=3D0x1088+0xf90 > syms=3D[0x4+0x12c0+0x4+0xe42] > /boot/kernel/ng_pptpgre.ko text=3D0x1c98 text=3D0x2380 data=3D0x1088 > syms=3D[0x4+0xdc0+0x4+0x8d0] > /boot/kernel/ng_deflate.ko text=3D0x1008 text=3D0xe90 data=3D0x1088 > syms=3D[0x4+0xb10+0x4+0x71f] > /boot/kernel/ng_iface.ko text=3D0x177c text=3D0x10a0 data=3D0x1088 > syms=3D[0x4+0xfa0+0x4+0xae6] > /boot/entropy size=3D0x1000 > > /boot/kernel/ng_ether.ko text=3D0x1554 text=3D0x1350 data=3D0x1088+0xf7c > syms=3D[0x4+0xeb0+0x4+0x94b] > /boot/kernel/ng_mppc.ko text=3D0xf70 text=3D0x2cc0 data=3D0x1088+0xf7c > syms=3D[0x4+0xc10+0x4+0x8c1] > loading required module 'rc4' > > /boot/kernel/rc4.ko text=3D0x3d7 text=3D0xf8 data=3D0x1068 > syms=3D[0x4+0x2a0+0x4+0x229] > /boot/kernel/ng_pipe.ko text=3D0x14d4 text=3D0x1e40 data=3D0x1088+0xf90 > syms=3D[0x4+0xc30+0x4+0x766] > /boot/kernel/ng_one2many.ko text=3D0xe4c text=3D0xbc0 data=3D0x1088 > syms=3D[0x4+0x950+0x4+0x608] > /boot/kernel/ng_echo.ko text=3D0x57d text=3D0x160 data=3D0x1088 > syms=3D[0x4+0x430+0x4+0x302] > /boot/kernel/if_tap.ko text=3D0x1d38 text=3D0x2490 data=3D0x1088+0xfac > syms=3D[0x4+0x15c0+0x4+0xb08] > /boot/kernel/ng_lmi.ko text=3D0x111f text=3D0x16e0 data=3D0x1088 > syms=3D[0x4+0x900+0x4+0x48f] > /boot/kernel/ng_l2tp.ko text=3D0x21b8 text=3D0x2990 data=3D0x1088 > syms=3D[0x4+0xde0+0x4+0x8ce] > /boot/kernel/ng_vlan.ko text=3D0xe90 text=3D0xd20 data=3D0x1088 > syms=3D[0x4+0x8b0+0x4+0x55b] > /boot/kernel/if_ure.ko text=3D0x1a20 text=3D0x50f0 data=3D0x1088+0xf80 > syms=3D[0x4+0x13d0+0x4+0xd26] > /boot/kernel/ng_frame_relay.ko text=3D0x857 text=3D0x8d0 data=3D0x1088 > syms=3D[0x4+0x740+0x4+0x3f2] > /boot/kernel/ng_hole.ko text=3D0x850 text=3D0x350 data=3D0x1088 > syms=3D[0x4+0x5d0+0x4+0x3db] > /boot/kernel/if_bridge.ko text=3D0x2cc0 text=3D0x6580 data=3D0x1088+0xf7c > syms=3D[0x4+0x2220+0x4+0x16a5] > loading required module 'bridgestp' > > /boot/kernel/bridgestp.ko text=3D0x1138 text=3D0x4550 data=3D0x1088+0xf90 > syms=3D[0x4+0xf20+0x4+0x870] > /boot/kernel/ng_async.ko text=3D0x10d0 text=3D0xe80 data=3D0x1088 > syms=3D[0x4+0x9d0+0x4+0x64c] > /boot/kernel/pfsync.ko text=3D0x2cb4 text=3D0x7b70 data=3D0x1088+0xf7c > syms=3D[0x4+0x1cb0+0x4+0x12b3] > /boot/kernel/carp.ko text=3D0x2dac text=3D0x6110 data=3D0x1088+0xfa4 > syms=3D[0x4+0x1e40+0x4+0x1333] > /boot/kernel/ng_bridge.ko text=3D0x15dc text=3D0x1550 data=3D0x1088+0xf98 > syms=3D[0x4+0xb80+0x4+0x7f5] > /boot/kernel/if_tun.ko text=3D0x235e text=3D0x2960 data=3D0x1088+0xf9c > syms=3D[0x4+0x1aa0+0x4+0xdf1] > /boot/kernel/ng_UI.ko text=3D0x78f text=3D0x4a0 data=3D0x1088 > syms=3D[0x4+0x690+0x4+0x396] > /boot/kernel/ng_cisco.ko text=3D0xee4 text=3D0xfe0 data=3D0x1088 > syms=3D[0x4+0xa30+0x4+0x5ad] > /boot/kernel/if_gre.ko text=3D0x1e4c text=3D0x3790 data=3D0x1088+0xf9c > syms=3D[0x4+0x19c0+0x4+0xf24] > /boot/kernel/ng_vjc.ko text=3D0x1154 text=3D0x1910 data=3D0x1088 > syms=3D[0x4+0x9d0+0x4+0x61b] > Using DTB provided by EFI at 0x47ef6000. > > Loading DTB overlays: 'sun8i-h3-sid.dtbo,sun8i-h3-ths.dtbo' > > /boot/dtb/overlays/sun8i-h3-sid.dtbo size=3D0x210 > > /boot/dtb/overlays/sun8i-h3-ths.dtbo size=3D0x3ba > > Kernel entry at 0x71000180... > > Kernel args: (null) > > applying DTB overlay '/boot/dtb/overlays/sun8i-h3-sid.dtbo' > > applying DTB overlay '/boot/dtb/overlays/sun8i-h3-ths.dtbo' > > EHCI failed to shut down host controller. > > EHCI failed to shut down host controller. > > EHCI failed to shut down host controller. > > ---<>--- > > KDB: debugger backends: ddb > > KDB: current backend: ddb > > Copyright (c) 1992-2019 The FreeBSD Project. > > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > > The Regents of the University of California. All rights reserved. > > FreeBSD is a registered trademark of The FreeBSD Foundation. > > FreeBSD 13.0-CURRENT #37 r345944M: Tue Apr 23 18:10:40 +08 2019 > > tsgan@beastie:/usr/obj/usr/src/arm.armv7/sys/GENERIC arm > > FreeBSD clang version 8.0.0 (tags/RELEASE_800/final 356365) (based on LLV= M > 8.0.0) > WARNING: WITNESS option enabled, expect reduced performance. > > VT: init without driver. > > module_register: cannot register ofwbus/pcib from kernel; already loaded > from kernel > Module ofwbus/pcib failed to register: 17 > > module_register: cannot register simplebus/pcib from kernel; already > loaded from kernel > Module simplebus/pcib failed to register: 17 > > CPU: ARM Cortex-A7 r0p5 (ECO: 0x00000000) > > CPU Features: > > Multiprocessing, Thumb2, Security, Virtualization, Generic Timer, > VMSAv7, > PXN, LPAE, Coherent Walk > > Optional instructions: > > SDIV/UDIV, UMULL, SMULL, SIMD(ext) > > LoUU:2 LoC:3 LoUIS:2 > > Cache level 1: > > 32KB/64B 4-way data cache WB Read-Alloc Write-Alloc > > 32KB/32B 2-way instruction cache Read-Alloc > > Cache level 2: > > 512KB/64B 8-way unified cache WB Read-Alloc Write-Alloc > > real memory =3D 1039556608 (991 MB) > > avail memory =3D 997736448 (951 MB) > > No PSCI/SMCCC call function found > > FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs > > random: unblocking device. > > random: entropy device external interface > > kbd0 at kbdmux0 > > ofwbus0: > > aw_ccu0: on ofwbus0 > > clk_fixed0: on aw_ccu0 > > clk_fixed1: on aw_ccu0 > > clk_fixed2: on aw_ccu0 > > simplebus0: on ofwbus0 > > ccu_h3ng0: mem 0x1c20000-0x1c203f= f > on simplebus0 > regfix0: on ofwbus0 > > regfix1: on ofwbus0 > > regfix2: on ofwbus0 > > regfix3: on ofwbus0 > > ccu_sun8i_r0: mem > 0x1f01400-0x1f014ff on simplebus0 > aw_sid0: mem 0x1c14000-0x1c143ff on > simplebus0 > gic0: mem > 0x1c81000-0x1c81fff,0x1c82000-0x1c83fff,0x1c84000-0x1c85fff,0x10 > gic0: pn 0x1, arch 0x2, rev 0x1, implementer 0x43b irqs 160 > > gpio0: mem 0x1c20800-0x1c20bff irq > 19,20 on simplebus0 > gpiobus0: on gpio0 > > gpio1: mem 0x1f02c00-0x1f02fff irq 44 > on simplebus0 > gpiobus1: on gpio1 > > rtc0: mem 0x1f00000-0x1f00053 irq 40,41 on simplebus0 > > rtc0: registered as a time-of-day clock, resolution 1.000000s > > generic_timer0: irq 0,1,2,3 on ofwbus0 > > Timecounter "ARM MPCore Timecounter" frequency 24000000 Hz quality 1000 > > Event timer "ARM MPCore Eventtimer" frequency 24000000 Hz quality 1000 > > aw_syscon0: mem 0x1c00000-0x1c00fff on simplebus0 > > awusbphy0: mem > 0x1c19400-0x1c1942b,0x1c1a800-0x1c1a803,0x1c1b800-0x1c1b803,0x1c1c800-0x1= 0 > aw_thermal0: mem 0x1c25000-0x1c250f= f > irq 4 on simplebus0 > a31dmac0: mem 0x1c02000-0x1c02fff irq 5 on > simplebus0 > aw_mmc0: mem 0x1c0f000-0x1c0ffff > irq 7 on simplebus0 > mmc0: on aw_mmc0 > > aw_mmc1: mem 0x1c10000-0x1c10fff > irq 8 on simplebus0 > mmc1: on aw_mmc1 > > aw_mmc2: mem 0x1c11000-0x1c11fff > irq 9 on simplebus0 > mmc2: on aw_mmc2 > > ehci0: mem 0x1c1b000-0x1c1b0ff > irq 13 on simplebus0 > usbus0: EHCI version 1.0 > > usbus0 on ehci0 > > ohci0: mem 0x1c1b400-0x1c1b4ff irq 14 on > simplebus0 > usbus1 on ohci0 > > ehci1: mem 0x1c1c000-0x1c1c0ff > irq 15 on simplebus0 > usbus2: EHCI version 1.0 > > usbus2 on ehci1 > > ohci1: mem 0x1c1c400-0x1c1c4ff irq 16 on > simplebus0 > usbus3 on ohci1 > > ehci2: mem 0x1c1d000-0x1c1d0ff > irq 17 on simplebus0 > usbus4: EHCI version 1.0 > > usbus4 on ehci2 > > ohci2: mem 0x1c1d400-0x1c1d4ff irq 18 on > simplebus0 > usbus5 on ohci2 > > gpioc0: on gpio0 > > awg0: mem 0x1c30000-0x1c3ffff irq 23 on > simplebus0 > miibus0: on awg0 > > rgephy0: PHY 0 on > miibus0 > rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, > 100baseTX-FDX, 100baseTX-FDX-flow, 1000baw > rgephy1: PHY 7 on > miibus0 > rgephy1: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, > 100baseTX-FDX, 100baseTX-FDX-flow, 1000baw > awg0: Ethernet address: 02:02:53:04:22:5c > > aw_wdog0: mem 0x1c20ca0-0x1c20cbf irq 26 on > simplebus0 > uart0: console (115384,n,8,1)mem 0x1c28000-0x1c283ff irq 31 on simplebus0 > > uart1: <16750 or compatible> mem 0x1c28c00-0x1c28fff irq 34 on simplebus0 > > aw_ir0: mem 0x1f02000-0x1f023ff irq 42 on > simplebus0 > aw_ir0: hwreset_get_by_ofw_idx =3D 0 > > gpioc1: on gpio1 > > cpulist0: on ofwbus0 > > cpu0: on cpulist0 > > cpu1: on cpulist0 > > cpu2: on cpulist0 > > cpu3: on cpulist0 > > gpioled0: on ofwbus0 > > cryptosoft0: > > Timecounters tick every 1.000 msec > > 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 > > usbus4: 480Mbps High Speed USB v2.0 > > ugen1.1: at usbus1 > > uhub0: on > usbus1 > ugen2.1: at usbus2 > > uhub1: on > usbus2 > ugen3.1: at usbus3 > > uhub2: on > usbus3 > ugen4.1: at usbus4 > > uhub3: on > usbus4 > ugen0.1: at usbus0 > > uhub4: on > usbus0 > usbus5: 12Mbps Full Speed USB v1.0 > > AW_MMC_INT_RESP_TIMEOUT > > AW_MMC_INT_RESP_TIMEOUT > > AW_MMC_INT_RESP_TIMEOUT > > ugen5.1: at usbus5 > > uhub5: on > usbus5 > AW_MMC_INT_RESP_TIMEOUT > > AW_MMC_INT_RESP_TIMEOUT > > AW_MMC_INT_RESP_TIMEOUT > > AW_MMC_INT_RESP_TIMEOUT > > AW_MMC_INT_RESP_TIMEOUT > > AW_MMC_INT_RESP_ERR AW_MMC_INT_RESP_CRC_ERR > > AW_MMC_INT_RESP_TIMEOUT > > AW_MMC_INT_RESP_TIMEOUT > > AW_MMC_INT_RESP_TIMEOUT > > mmc0: CMD3 failed, RESULT: 1 > > mmc0: Error setting RCA 1 > > AW_MMC_INT_RESP_TIMEOUT > > AW_MMC_INT_RESP_TIMEOUT > > AW_MMC_INT_RESP_TIMEOUT > > AW_MMC_INT_RESP_TIMEOUT > > AW_MMC_INT_RESP_TIMEOUT > > AW_MMC_INT_RESP_TIMEOUT > > AW_MMC_INT_RESP_TIMEOUT > > AW_MMC_INT_RESP_TIMEOUT > > AW_MMC_INT_RESP_TIMEOUT > > AW_MMC_INT_RESP_TIMEOUT > > AW_MMC_INT_RESP_TIMEOUT > > AW_MMC_INT_RESP_TIMEOUT > > mmc1: No compatible cards found on bus > > aw_mmc1: Spurious interrupt - no active request, rint: 0x00000004 > > > AW_MMC_INT_RESP_TIMEOUT > > AW_MMC_INT_RESP_TIMEOUT > > AW_MMC_INT_RESP_TIMEOUT > > AW_MMC_INT_RESP_TIMEOUT > > AW_MMC_INT_RESP_TIMEOUT > > AW_MMC_INT_RESP_TIMEOUT > > AW_MMC_INT_RESP_TIMEOUT > > AW_MMC_INT_RESP_TIMEOUT > > uhub0: 1 port with 1 removable, self powered > > uhub2: 1 port with 1 removable, self powered > > AW_MMC_INT_DATA_END_BIT_ERR > > AW_MMC_INT_RESP_TIMEOUT > > AW_MMC_INT_RESP_TIMEOUT > > AW_MMC_INT_RESP_TIMEOUT > > AW_MMC_INT_RESP_TIMEOUT > > mmcsd0: 8GB at > mmc2 52.0MHz/8bit/32768-block > mmcsd0boot0: 4MB partion 1 at mmcsd0 > > mmcsd0boot1: 4MB partion 2 at mmcsd0 > > mmcsd0rpmb: 524kB partion 3 at mmcsd0 > > Release APs > > WARNING: WITNESS option enabled, expect reduced performance. > > uhub5: 1 port with 1 removable, self powered > > Trying to mount root from ufs:/dev/ufs/OPNsense [rw]... > > Root mount waiting for: usbus4 usbus2 usbus0 > > uhub3: 1 port with 1 removable, self powered > > uhub1: 1 port with 1 removable, self powered > > uhub4: 1 port with 1 removable, self powered > > ugen0.2: at usbus0 > > ure0 on uhub4 > > ure0: on > usbus0 > mountroot: waiting for device /dev/ufs/OPNsense... > > ure0: MAC assigned randomly > > miibus1: on ure0 > > rlphy0: PHY 0 on miibus1 > > rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > > ue0: on ure0 > > ue0: Ethernet address: aa:45:b5:64:b1:70 > > Mounting from ufs:/dev/ufs/OPNsense failed with error 19. > > > Loader variables: > > vfs.root.mountfrom=3Dufs:/dev/ufs/OPNsense > > vfs.root.mountfrom.options=3Drw > > > Manual root filesystem specification: > > : [options] > > Mount using filesystem > > and with the specified (optional) option list. > > > eg. ufs:/dev/da0s1a > > zfs:zroot/ROOT/default > > cd9660:/dev/cd0 ro > > (which is equivalent to: mount -t cd9660 -o ro /dev/cd0 /) > > > ? List valid disk boot devices > What does it show if you type ? in mountroot prompt? thanks, Ganbold > > . Yield 1 second (for background tasks) > > Abort manual input > > > mountroot> ls > > Invalid file system specification. > > > mountroot> > > > > From the above logs I see that both the ethernet cards were detected. > > I then tried the FreeBSD image from the same link and it have the same > issue. > > Link: https://people.freebsd.org/~ganbold/ > > > Is anyone else working on armv7 NanoPi R1? > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > From owner-freebsd-arm@freebsd.org Tue Aug 18 19:05:34 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 86FC83C413E for ; Tue, 18 Aug 2020 19:05:34 +0000 (UTC) (envelope-from mishin@mh.net.ru) Received: from frog.mh.net.ru (mh.balakovo.san.ru [88.147.158.22]) (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 4BWL3110DDz4Vjv for ; Tue, 18 Aug 2020 19:05:31 +0000 (UTC) (envelope-from mishin@mh.net.ru) Received: from webmail.mh.net.ru (mouse.home [192.168.5.6]) by frog.mh.net.ru (Postfix) with ESMTPSA id 3B16FABA83 for ; Tue, 18 Aug 2020 23:05:21 +0400 (+04) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 18 Aug 2020 23:05:20 +0400 From: Alexander Mishin To: freebsd-arm@freebsd.org Subject: Kmod driver at iicbus. attach() and config_intrhook(9) User-Agent: Roundcube Webmail/1.4.2 Message-ID: <7fabb65d99aaa74775c1daa91bffb873@mh.net.ru> X-Sender: mishin@mh.net.ru X-Rspamd-Queue-Id: 4BWL3110DDz4Vjv X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=mh.net.ru (policy=none); spf=fail (mx1.freebsd.org: domain of mishin@mh.net.ru does not designate 88.147.158.22 as permitted sender) smtp.mailfrom=mishin@mh.net.ru X-Spamd-Result: default: False [1.53 / 15.00]; RCVD_TLS_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_FAIL(1.00)[-all]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_SPAM_SHORT(0.53)[0.528]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; ARC_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:12389, ipnet:88.147.128.0/17, country:RU]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arm]; DMARC_POLICY_SOFTFAIL(0.10)[mh.net.ru : No valid SPF, No valid DKIM,none] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2020 19:05:34 -0000 Hi I write a kmod driver for bh1750 light sensor with iic (almost wrote). As usual, probe(), attach() and detach(). On attach() it runs TIMEOUT_TASK_INIT for periodically write opecode, read result and place it to sysctl dev.bh1750.N variables. It is all. But I see that some other devices (from /usr/src/sys/dev) uses CONFIG_INTRHOOK(9) on attach() for initialize themselfs. I wonder if I need this too? ...or maybe... when I might need it? Thanks --- There is the source if it needed: https://gitlab.com/alexandermishin13/bh1750-kmod/ From owner-freebsd-arm@freebsd.org Wed Aug 19 03:48:42 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 9F55E3B05D4 for ; Wed, 19 Aug 2020 03:48:42 +0000 (UTC) (envelope-from shigeru@os-hackers.jp) Received: from mailssl04.asahi-net.or.jp (mailssl04.asahi-net.or.jp [202.224.55.63]) by mx1.freebsd.org (Postfix) with ESMTP id 4BWYfd5LPTz46Zj for ; Wed, 19 Aug 2020 03:48:41 +0000 (UTC) (envelope-from shigeru@os-hackers.jp) Received: from localhost (w142149.ppp.asahi-net.or.jp [121.1.142.149]) (Authenticated sender: WJ8S-YMMT) by mailssl04.asahi-net.or.jp (Postfix) with ESMTPSA id 6D5DD40079 for ; Wed, 19 Aug 2020 12:41:32 +0900 (JST) Date: Wed, 19 Aug 2020 12:41:28 +0900 (JST) Message-Id: <20200819.124128.149359658994284808.shigeru@os-hackers.jp> To: freebsd-arm@freebsd.org Subject: current best practice to start FreeBSD / Raspberry Pi 4 From: YAMAMOTO Shigeru X-Mailer: Mew version 6.8 on Emacs 26.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4BWYfd5LPTz46Zj X-Spamd-Bar: +++++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=softfail (mx1.freebsd.org: 202.224.55.63 is neither permitted nor denied by domain of shigeru@os-hackers.jp) smtp.mailfrom=shigeru@os-hackers.jp X-Spamd-Result: default: False [5.44 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; GREYLIST(0.00)[pass,body]; FROM_HAS_DN(0.00)[]; MV_CASE(0.50)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; TO_DN_NONE(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all:c]; RCPT_COUNT_ONE(0.00)[1]; DMARC_NA(0.00)[os-hackers.jp]; VIOLATED_DIRECT_SPF(3.50)[]; MID_CONTAINS_FROM(1.00)[]; NEURAL_SPAM_SHORT(0.44)[0.437]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:4685, ipnet:202.224.32.0/19, country:JP]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arm] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2020 03:48:42 -0000 Hi, all I have Raspberry PI 4, 4GB model and 8GB model. I make SD image and I can boot 4GB model and 8GB model. 1. install u-boot-rpi4 pkg install -y u-boot-rpi4 2. download SD card image for Raspberry Pi 3 fetch https://download.freebsd.org/ftp/snapshots/ISO-IMAGES/13.0/FreeBSD-13.0-CURRENT-arm64-aarch64-RPI3-20200813-r364182.img.xz 3. write image to SD card xzcat FreeBSD-13.0-CURRENT-arm64-aarch64-RPI3-20200806-r363935.img.xz | dd of=/dev/da0 bs=8k 4. mount FAT partition at SD card mount_msdosfs /dev/da0s1 /mnt 5. replace files - 4GB model - replace u-boot.bin - cp /usr/local/share/u-boot/u-boot-rpi4/u-boot.bin /mnt/. - 8GB model - replace u-boot.bin, fixup4.dat, start4.elf - https://sourceforge.net/projects/rpi4-8gbram-boot-fbsdonly/files/u-boot.bin/download - https://github.com/raspberrypi/firmware/raw/1.20200717/boot/fixup4.dat - https://github.com/raspberrypi/firmware/raw/1.20200717/boot/start4.elf 6. unmount FAT partiion umount /mnt dmesgs are: - https://github.com/bsd-hacker/freebsd/wiki/How-to-start-FreeBSD---Raspberry-Pi-4 It is my current best practice. I hope to know other best practice to start FreeBSD / Raspberry Pi 4. and I hope to know best practice of rpi4-uefi version. Thanks, --- YAMAMOTO Shigeru From owner-freebsd-arm@freebsd.org Wed Aug 19 07:03:50 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 8BE5E3B3FE2 for ; Wed, 19 Aug 2020 07:03:50 +0000 (UTC) (envelope-from agapon@gmail.com) Received: from mail-lf1-f53.google.com (mail-lf1-f53.google.com [209.85.167.53]) (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 4BWdzn2xzKz4Jbw for ; Wed, 19 Aug 2020 07:03:49 +0000 (UTC) (envelope-from agapon@gmail.com) Received: by mail-lf1-f53.google.com with SMTP id i19so11515051lfj.8 for ; Wed, 19 Aug 2020 00:03:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=ndvWvSKrOqnpKi/A4hLDsYSDNkIK2XeL5DPIUdzAxHk=; b=PEpCRiMQ6+8iWAXrYTKRJ/Djaeff2oEjf6sGOZLzzothdIWsXz1XQQPgFBYZMcO0LG doMpmeswZWj0h5bbDuPF+rdP0ycK0ChUsyDqGAGKQHZPhhRUgvLcCTXBT288RTNXsHm+ 3aGEfZ1oSKZCPT8eTzalgYQICnS5vHoEdkR2/0hT1QyWil7XPEECb2/k1vDjbz7HIWTi oZ2j4Tgj61Ypw/zt89X99/KuR6kssstEIxGMyUI2NzO8JJN6tFcSYTAKPkNffUvKdLbH DUbg+jrhVfosaRWmrQJ7fJ+Sab6bRwhRNL1Gnlp5iH+kPWBcPjfUR1psufFlnT3NbUXw 3kxA== X-Gm-Message-State: AOAM531Kol3rl8HesuRmLQJHP2Cir7p1EjPUX62v5AEH9yBzF4d/fa2Y rvdTxJvhkTSJGvIHpuQdjv4bBouYfGE= X-Google-Smtp-Source: ABdhPJwFxWzf19i0B7c0yRuWMIAFQu8aCyeSlRMj22YuFAjzujSv3l0FM49h3RCGAabUISfGdyIfTA== X-Received: by 2002:a19:c197:: with SMTP id r145mr11446445lff.41.1597820626708; Wed, 19 Aug 2020 00:03:46 -0700 (PDT) Received: from [192.168.0.88] (east.meadow.volia.net. [93.72.151.96]) by smtp.googlemail.com with ESMTPSA id s4sm6444483lja.124.2020.08.19.00.03.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 19 Aug 2020 00:03:45 -0700 (PDT) Subject: Re: Kmod driver at iicbus. attach() and config_intrhook(9) To: Alexander Mishin , freebsd-arm@freebsd.org References: <7fabb65d99aaa74775c1daa91bffb873@mh.net.ru> From: Andriy Gapon Openpgp: preference=signencrypt Autocrypt: addr=avg@FreeBSD.org; prefer-encrypt=mutual; keydata= mQINBFm4LIgBEADNB/3lT7f15UKeQ52xCFQx/GqHkSxEdVyLFZTmY3KyNPQGBtyvVyBfprJ7 mAeXZWfhat6cKNRAGZcL5EmewdQuUfQfBdYmKjbw3a9GFDsDNuhDA2QwFt8BmkiVMRYyvI7l N0eVzszWCUgdc3qqM6qqcgBaqsVmJluwpvwp4ZBXmch5BgDDDb1MPO8AZ2QZfIQmplkj8Y6Z AiNMknkmgaekIINSJX8IzRzKD5WwMsin70psE8dpL/iBsA2cpJGzWMObVTtCxeDKlBCNqM1i gTXta1ukdUT7JgLEFZk9ceYQQMJJtUwzWu1UHfZn0Fs29HTqawfWPSZVbulbrnu5q55R4PlQ /xURkWQUTyDpqUvb4JK371zhepXiXDwrrpnyyZABm3SFLkk2bHlheeKU6Yql4pcmSVym1AS4 dV8y0oHAfdlSCF6tpOPf2+K9nW1CFA8b/tw4oJBTtfZ1kxXOMdyZU5fiG7xb1qDgpQKgHUX8 7Rd2T1UVLVeuhYlXNw2F+a2ucY+cMoqz3LtpksUiBppJhw099gEXehcN2JbUZ2TueJdt1FdS ztnZmsHUXLxrRBtGwqnFL7GSd6snpGIKuuL305iaOGODbb9c7ne1JqBbkw1wh8ci6vvwGlzx rexzimRaBzJxlkjNfMx8WpCvYebGMydNoeEtkWldtjTNVsUAtQARAQABtB5BbmRyaXkgR2Fw b24gPGF2Z0BGcmVlQlNELm9yZz6JAlQEEwEIAD4WIQS+LEO7ngQnXA4Bjr538m7TUc1yjwUC WbgsiAIbIwUJBaOagAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRB38m7TUc1yj+JAEACV l9AK/nOWAt/9cufV2fRj0hdOqB1aCshtSrwHk/exXsDa4/FkmegxXQGY+3GWX3deIyesbVRL rYdtdK0dqJyT1SBqXK1h3/at9rxr9GQA6KWOxTjUFURsU7ok/6SIlm8uLRPNKO+yq0GDjgaO LzN+xykuBA0FlhQAXJnpZLcVfPJdWv7sSHGedL5ln8P8rxR+XnmsA5TUaaPcbhTB+mG+iKFj GghASDSfGqLWFPBlX/fpXikBDZ1gvOr8nyMY9nXhgfXpq3B6QCRYKPy58ChrZ5weeJZ29b7/ QdEO8NFNWHjSD9meiLdWQaqo9Y7uUxN3wySc/YUZxtS0bhAd8zJdNPsJYG8sXgKjeBQMVGuT eCAJFEYJqbwWvIXMfVWop4+O4xB+z2YE3jAbG/9tB/GSnQdVSj3G8MS80iLS58frnt+RSEw/ psahrfh0dh6SFHttE049xYiC+cM8J27Aaf0i9RflyITq57NuJm+AHJoU9SQUkIF0nc6lfA+o JRiyRlHZHKoRQkIg4aiKaZSWjQYRl5Txl0IZUP1dSWMX4s3XTMurC/pnja45dge/4ESOtJ9R 8XuIWg45Oq6MeIWdjKddGhRj3OohsltKgkEU3eLKYtB6qRTQypHHUawCXz88uYt5e3w4V16H lCpSTZV/EVHnNe45FVBlvK7k7HFfDDkryLkCDQRZuCyIARAAlq0slcsVboY/+IUJdcbEiJRW be9HKVz4SUchq0z9MZPX/0dcnvz/gkyYA+OuM78dNS7Mbby5dTvOqfpLJfCuhaNYOhlE0wY+ 1T6Tf1f4c/uA3U/YiadukQ3+6TJuYGAdRZD5EqYFIkreARTVWg87N9g0fT9BEqLw9lJtEGDY EWUE7L++B8o4uu3LQFEYxcrb4K/WKmgtmFcm77s0IKDrfcX4doV92QTIpLiRxcOmCC/OCYuO jB1oaaqXQzZrCutXRK0L5XN1Y1PYjIrEzHMIXmCDlLYnpFkK+itlXwlE2ZQxkfMruCWdQXye syl2fynAe8hvp7Mms9qU2r2K9EcJiR5N1t1C2/kTKNUhcRv7Yd/vwusK7BqJbhlng5ZgRx0m WxdntU/JLEntz3QBsBsWM9Y9wf2V4tLv6/DuDBta781RsCB/UrU2zNuOEkSixlUiHxw1dccI 6CVlaWkkJBxmHX22GdDFrcjvwMNIbbyfQLuBq6IOh8nvu9vuItup7qemDG3Ms6TVwA7BD3j+ 3fGprtyW8Fd/RR2bW2+LWkMrqHffAr6Y6V3h5kd2G9Q8ZWpEJk+LG6Mk3fhZhmCnHhDu6CwN MeUvxXDVO+fqc3JjFm5OxhmfVeJKrbCEUJyM8ESWLoNHLqjywdZga4Q7P12g8DUQ1mRxYg/L HgZY3zfKOqcAEQEAAYkCPAQYAQgAJhYhBL4sQ7ueBCdcDgGOvnfybtNRzXKPBQJZuCyIAhsM BQkFo5qAAAoJEHfybtNRzXKPBVwQAKfFy9P7N3OsLDMB56A4Kf+ZT+d5cIx0Yiaf4n6w7m3i ImHHHk9FIetI4Xe54a2IXh4Bq5UkAGY0667eIs+Z1Ea6I2i27Sdo7DxGwq09Qnm/Y65ADvXs 3aBvokCcm7FsM1wky395m8xUos1681oV5oxgqeRI8/76qy0hD9WR65UW+HQgZRIcIjSel9vR XDaD2HLGPTTGr7u4v00UeTMs6qvPsa2PJagogrKY8RXdFtXvweQFz78NbXhluwix2Tb9ETPk LIpDrtzV73CaE2aqBG/KrboXT2C67BgFtnk7T7Y7iKq4/XvEdDWscz2wws91BOXuMMd4c/c4 OmGW9m3RBLufFrOag1q5yUS9QbFfyqL6dftJP3Zq/xe+mr7sbWbhPVCQFrH3r26mpmy841ym dwQnNcsbIGiBASBSKksOvIDYKa2Wy8htPmWFTEOPRpFXdGQ27awcjjnB42nngyCK5ukZDHi6 w0qK5DNQQCkiweevCIC6wc3p67jl1EMFY5+z+zdTPb3h7LeVnGqW0qBQl99vVFgzLxchKcl0 R/paSFgwqXCZhAKMuUHncJuynDOP7z5LirUeFI8qsBAJi1rXpQoLJTVcW72swZ42IdPiboqx NbTMiNOiE36GqMcTPfKylCbF45JNX4nF9ElM0E+Y8gi4cizJYBRr2FBJgay0b9Cp Message-ID: <3249fa7e-554a-83ef-57b2-7c38aa0b4591@FreeBSD.org> Date: Wed, 19 Aug 2020 10:03:44 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Firefox/60.0 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <7fabb65d99aaa74775c1daa91bffb873@mh.net.ru> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4BWdzn2xzKz4Jbw X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of agapon@gmail.com designates 209.85.167.53 as permitted sender) smtp.mailfrom=agapon@gmail.com X-Spamd-Result: default: False [-0.57 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; DMARC_NA(0.00)[FreeBSD.org]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.57)[-0.567]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[209.85.167.53:from]; RECEIVED_SPAMHAUS_PBL(0.00)[93.72.151.96:received]; FORGED_SENDER(0.30)[avg@FreeBSD.org,agapon@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.167.53:from]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; MIME_TRACE(0.00)[0:+]; FROM_NEQ_ENVFROM(0.00)[avg@FreeBSD.org,agapon@gmail.com]; MAILMAN_DEST(0.00)[freebsd-arm] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2020 07:03:50 -0000 On 18/08/2020 22:05, Alexander Mishin wrote: > Hi > > I write a kmod driver for bh1750 light sensor with iic (almost wrote). > As usual, probe(), attach() and detach(). On attach() it runs TIMEOUT_TASK_INIT > for periodically write opecode, read result and place it to sysctl dev.bh1750.N > variables. It is all. > > But I see that some other devices (from /usr/src/sys/dev) uses CONFIG_INTRHOOK(9) > on attach() for initialize themselfs. > I wonder if I need this too? ...or maybe... when I might need it? This is usually needed when a driver needs to talk to its device while attaching. E.g., to set some initial configuration or to confirm device's identity, etc. -- Andriy Gapon From owner-freebsd-arm@freebsd.org Wed Aug 19 07:24:19 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 2F19F3B46E7 for ; Wed, 19 Aug 2020 07:24:19 +0000 (UTC) (envelope-from gonzo@bluezbox.com) Received: from id.bluezbox.com (id.bluezbox.com [45.55.20.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4BWfRQ37xFz4KRx; Wed, 19 Aug 2020 07:24:18 +0000 (UTC) (envelope-from gonzo@bluezbox.com) Received: from localhost ([127.0.0.1] helo=id.bluezbox.com) by id.bluezbox.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94 (FreeBSD)) (envelope-from ) id 1k8ISA-000FcC-3V; Wed, 19 Aug 2020 00:24:10 -0700 Received: (from gonzo@localhost) by id.bluezbox.com (8.15.2/8.15.2/Submit) id 07J7O9Jn060027; Wed, 19 Aug 2020 00:24:09 -0700 (PDT) (envelope-from gonzo@bluezbox.com) X-Authentication-Warning: id.bluezbox.com: gonzo set sender to gonzo@bluezbox.com using -f Date: Wed, 19 Aug 2020 00:24:09 -0700 From: Oleksandr Tymoshenko To: Andriy Gapon Cc: Alexander Mishin , freebsd-arm@freebsd.org Subject: Re: Kmod driver at iicbus. attach() and config_intrhook(9) Message-ID: <20200819072409.GA59949@bluezbox.com> References: <7fabb65d99aaa74775c1daa91bffb873@mh.net.ru> <3249fa7e-554a-83ef-57b2-7c38aa0b4591@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3249fa7e-554a-83ef-57b2-7c38aa0b4591@FreeBSD.org> X-Operating-System: FreeBSD/11.2-RELEASE-p10 (amd64) X-Spam-Level: -- X-Spam-Report: Spam detection software, running on the system "id.bluezbox.com", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: Andriy Gapon (avg@FreeBSD.org) wrote: > On 18/08/2020 22:05, Alexander Mishin wrote: > > Hi > > > > I write a kmod driver for bh1750 light sensor with iic (almost wrote). > > As usual, probe(), attach [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Rspamd-Queue-Id: 4BWfRQ37xFz4KRx X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of gonzo@bluezbox.com designates 45.55.20.155 as permitted sender) smtp.mailfrom=gonzo@bluezbox.com X-Spamd-Result: default: False [-0.43 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; DMARC_NA(0.00)[bluezbox.com]; FREEFALL_USER(0.00)[gonzo]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.13)[-0.130]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:14061, ipnet:45.55.0.0/19, country:US]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arm] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2020 07:24:19 -0000 Andriy Gapon (avg@FreeBSD.org) wrote: > On 18/08/2020 22:05, Alexander Mishin wrote: > > Hi > > > > I write a kmod driver for bh1750 light sensor with iic (almost wrote). > > As usual, probe(), attach() and detach(). On attach() it runs TIMEOUT_TASK_INIT > > for periodically write opecode, read result and place it to sysctl dev.bh1750.N > > variables. It is all. > > > > But I see that some other devices (from /usr/src/sys/dev) uses CONFIG_INTRHOOK(9) > > on attach() for initialize themselfs. > > I wonder if I need this too? ...or maybe... when I might need it? > > This is usually needed when a driver needs to talk to its device while > attaching. E.g., to set some initial configuration or to confirm device's > identity, etc. To extend Andriy's explanation a bit: all these operations may perform I2C transfers and most I2C controllers use interrupts to get notified about tranfer status change (finished, error, etc...). There is no guarantee that when driver's attach method is called interrupts are globally enabled. What would happen in this case is: I2C controller is going to initiate I2C operation and wait for an interrupt that's never going to be delivered. CONFIG_INTRHOOK is a solution for this problem, if your attach method requires interrupts - just split it in two parts and postpone running interrupt-dependent part until after interrupts are globally enabled. -- gonzo From owner-freebsd-arm@freebsd.org Wed Aug 19 08:14:23 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id F092F3B6891 for ; Wed, 19 Aug 2020 08:14:23 +0000 (UTC) (envelope-from jsorocil@gmail.com) Received: from mail-ot1-x336.google.com (mail-ot1-x336.google.com [IPv6:2607:f8b0:4864:20::336]) (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 4BWgYB6FwRz4PKg for ; Wed, 19 Aug 2020 08:14:22 +0000 (UTC) (envelope-from jsorocil@gmail.com) Received: by mail-ot1-x336.google.com with SMTP id v21so18385598otj.9 for ; Wed, 19 Aug 2020 01:14: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; bh=etPgc5Q7oqjbNlHNyGKihrw2MmCI4V0+6eITtmpeeok=; b=spizVghTh7YlLONyr7MAEhVfLUTiwG5PryzgucuXwndsWzLTsiBHElqi4F9UUS23SB DzrJIzxWFRDNVXipt2tRJWz1JylaQK1O7zyivzr/eBEZfxBsSJAEmA3T9OZS7v5j4qGr M7LgJmT+enkA8BIlBHzNVhpb19ut1opbFpegQAL4qu/4kq9CnrtkES6WHWXtcPyZsLCp 4ununf04HckJdRPEn8sdMbsQBaql15FVv+oIMwkVKhdTOqyyK79s/qW/2cxlGryHR1RW T0s6gt2FZI+9cILOnGLoVlUc1JOEhCsCZBo7t8MMBmcmP7UlGrUMor3i9jbkf6uZ2Sfv AEsA== 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; bh=etPgc5Q7oqjbNlHNyGKihrw2MmCI4V0+6eITtmpeeok=; b=tu0UqgWio5MEYjuOM8h2rLqqRdE6wW7qIkaRunxBsIsK4FNQKcu4sMGAE3M8RW+Udm TdFvrKiD2JTa5jdgHzfetshVanxabTC5U3/ZZ7vPi0SE8nR5fwG9wY1AdbKPHLtnndKI Kgg7FtbeR+fk5uBtEsuMrGCv5XWqZk1V8UkCLYSd9k99YL+Lg7iAcWBbRfHPsVlbgBcc 39hUKYR0EUiIRLGY9Ez2eD06T42thyveuGGHMVbQcqPxNhpz7URXEQt/1O53So7/vlNC dFGptqcBVlm/Hg3EhvWyOLutreTMhc222d20B0lLgBt6y8fd7bIoOW85u55tUa/1SOta zN+Q== X-Gm-Message-State: AOAM533yIngoyjC43VYo3jxYZHNGuf6dqg+nIjD6yKGZtCdaIbMbnkaX xoZoJgfQD/1MHUZxF9mKIlTM8yopqzB/QuX8UNil1Iqo X-Google-Smtp-Source: ABdhPJw4drDHt1CxK0Bqheakhs3EWcCCrEjRjKAhKRYN+ijHmfcX+o0md8EMJL+Jfgj828xajjTIl05BsCH2Gk3+r8Q= X-Received: by 2002:a05:6830:1db1:: with SMTP id z17mr18546348oti.170.1597824860862; Wed, 19 Aug 2020 01:14:20 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Johnny Sorocil Date: Wed, 19 Aug 2020 10:13:23 +0200 Message-ID: Subject: Disabling internal RTC ends up in hang To: freebsd-arm@freebsd.org X-Rspamd-Queue-Id: 4BWgYB6FwRz4PKg X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=spizVghT; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of jsorocil@gmail.com designates 2607:f8b0:4864:20::336 as permitted sender) smtp.mailfrom=jsorocil@gmail.com X-Spamd-Result: default: False [-0.92 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; SH_EMAIL_DBL_DONT_QUERY_IPS(0.00)[0.0.0.68:email]; FREEMAIL_FROM(0.00)[gmail.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; DBL_PROHIBIT(0.00)[0.0.0.68:email]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::336:from]; NEURAL_SPAM_SHORT(0.08)[0.084]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arm]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2020 08:14:24 -0000 I wan't to have the correct date on my ARM SBC (armv7 Orange Pi Zero board which doesn't have an RTC battery socket). Got an external I2C RTC module (DS3231) which is recognized and works (after adding device tree overlay): root@arm2:~ # sysctl dev.ds3231 dev.ds3231.0.32khz_enable: 1 dev.ds3231.0.sqw_mode: interrupt dev.ds3231.0.sqw_freq: 1024 dev.ds3231.0.bbsqw: 0 dev.ds3231.0.temp_conv: 0 dev.ds3231.0.temperature: 30.0C dev.ds3231.0.%parent: iicbus0 dev.ds3231.0.%pnpinfo: name=ds3231@68 compat=maxim,ds3231 dev.ds3231.0.%location: addr=0xd0 dev.ds3231.0.%driver: ds3231 dev.ds3231.0.%desc: Maxim DS3231 RTC dev.ds3231.%parent: Setting a date works - the system will have the correct date until power is disconnected. After power is connected again, system time is not read from RTC. After powercycle: root@arm2:~ # date Fri Jan 1 00:22:25 UTC 2010 root@arm2:~ # ./ds1307 -a 0x68 -r 09:37:59 12/08/2020 NTP is not used. ds1307 program is used to directly read registers from the I2C module. Disabling internal rtc (via device tree overlay) results in kernel panic & hang: ---<>--- Copyright (c) 1992-2019 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 12.1-RELEASE r354233 GENERIC arm FreeBSD clang version 8.0.1 (tags/RELEASE_801/final 366581) (based on LLVM 8.0.1) VT: init without driver. module_register: cannot register ofwbus/pcib from kernel; already loaded from kernel Module ofwbus/pcib failed to register: 17 module_register: cannot register simplebus/pcib from kernel; already loaded from kernel Module simplebus/pcib failed to register: 17 CPU: ARM Cortex-A7 r0p5 (ECO: 0x00000000) CPU Features: Multiprocessing, Thumb2, Security, Virtualization, Generic Timer, VMSAv7, PXN, LPAE, Coherent Walk Optional instructions: SDIV/UDIV, UMULL, SMULL, SIMD(ext) LoUU:2 LoC:3 LoUIS:2 Cache level 1: 32KB/64B 4-way data cache WB Read-Alloc Write-Alloc 32KB/32B 2-way instruction cache Read-Alloc Cache level 2: 512KB/64B 8-way unified cache WB Read-Alloc Write-Alloc real memory = 536289280 (511 MB) avail memory = 509890560 (486 MB) No PSCI/SMCCC call function found FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs random: unblocking device. random: entropy device external interface kbd0 at kbdmux0 ofwbus0: ofw_clkbus0: on ofwbus0 clk_fixed0: on ofw_clkbus0 clk_fixed1: on ofw_clkbus0 simplebus0: on ofwbus0 regfix0: on ofwbus0 regfix1: on ofwbus0 regfix2: on ofwbus0 regfix3: on ofwbus0 ccu_h3ng0: mem 0x1c20000-0x1c203ff on simplebus0 ccu_h3ng0: Clock apb2 have unknown parent: osc32k ccu_h3ng0: Clock ahb1 have unknown parent: osc32k ccu_h3ng0: Clock cpux have unknown parent: osc32k panic: cannot finalize clkdom initialization cpuid = 0 time = 1 Uptime: 1s Automatic reboot in 15 seconds - press a key on the console to abort Rebooting... Reset: watchdog device has not been initialized Reset failed! The same happens with -CURRENT with custom kernel compiled without aw_rtc device: % cat usr/src/sys/arm/conf/MYKERNEL include GENERIC ident MYKERNEL nodevice aw_rtc # Allwinner On-chip RTC Device tree overlay for disabling internal RTC is not enabled and after connecting serial console and booting that kernel: ... simplebus0: on ofwbus0 regfix0: on ofwbus0 regfix1: on ofwbus0 regfix2: on ofwbus0 regfix3: on ofwbus0 ccu_h3ng0: mem 0x1c20000-0x1c203ff on simplebus0 ccu_h3ng0: Clock apb2 have unknown parent: osc32k ccu_h3ng0: Clock ahb1 have unknown parent: osc32k ccu_h3ng0: Clock cpux have unknown parent: osc32k panic: cannot finalize clkdom initialization cpuid = 0 time = 1 KDB: stack backtrace: db_trace_self() at db_trace_self pc = 0xc0578934 lr = 0xc0079eb0 (db_trace_self_wrapper+0x30) sp = 0xc0d14b98 fp = 0xc0d14cb0 db_trace_self_wrapper() at db_trace_self_wrapper+0x30 pc = 0xc0079eb0 lr = 0xc02bf54c (vpanic+0x174) sp = 0xc0d14cb8 fp = 0xc0d14cd8 r4 = 0x00000100 r5 = 0xc0a42b20 r6 = 0xc06a0af6 r7 = 0x00000000 vpanic() at vpanic+0x174 pc = 0xc02bf54c lr = 0xc02bf308 (doadump) sp = 0xc0d14ce0 fp = 0xc0d14ce4 r4 = 0x000008c0 r5 = 0xd02f9800 r6 = 0x00000071 r7 = 0xc0d14d18 r8 = 0xc0d14d08 r9 = 0x00000001 r10 = 0x00000000 doadump() at doadump pc = 0xc02bf308 lr = 0xc05be870 (aw_ccung_write_4) sp = 0xc0d14cec fp = 0xc0d14d50 r4 = 0x00000000 r5 = 0xc0d14ce4 r6 = 0xc02bf308 r10 = 0xc0d14cec aw_ccung_write_4() at aw_ccung_write_4 pc = 0xc05be870 lr = 0xc02fc1b8 (device_attach+0x50c) sp = 0xc0d14d58 fp = 0xc0d14da0 r4 = 0x00000000 r5 = 0xc0ae30a4 r6 = 0x80040001 r10 = 0x80000803 device_attach() at device_attach+0x50c pc = 0xc02fc1b8 lr = 0xc02fbc10 (device_probe_and_attach+0x8c) sp = 0xc0d14da8 fp = 0xc0d14dc0 r4 = 0xd00de400 r5 = 0xc2471f80 r6 = 0x5e4a6f28 r7 = 0x00000000 r8 = 0xc0a615a8 r9 = 0xc0a615ac r10 = 0xc0a4278c device_probe_and_attach() at device_probe_and_attach+0x8c pc = 0xc02fbc10 lr = 0xc02fdf5c (bus_generic_new_pass+0xb0) sp = 0xc0d14dc8 fp = 0xc0d14de0 r4 = 0xd00de400 r5 = 0xc0848ef8 r6 = 0xc088cba0 r10 = 0xc0a4278c bus_generic_new_pass() at bus_generic_new_pass+0xb0 pc = 0xc02fdf5c lr = 0xc02fdfa8 (bus_generic_new_pass+0xfc) sp = 0xc0d14de8 fp = 0xc0d14e00 r4 = 0xd00df980 r5 = 0xc0848ef8 r6 = 0xd00e0000 r7 = 0x00000000 r8 = 0xc0a615a8 r10 = 0xc0a4278c bus_generic_new_pass() at bus_generic_new_pass+0xfc pc = 0xc02fdfa8 lr = 0xc02fdfa8 (bus_generic_new_pass+0xfc) sp = 0xc0d14e08 fp = 0xc0d14e20 r4 = 0xd00dfc00 r5 = 0xc0848ef8 r6 = 0xd00e0000 r7 = 0x00000000 r8 = 0xc0a615a8 r10 = 0xc0a4278c bus_generic_new_pass() at bus_generic_new_pass+0xfc pc = 0xc02fdfa8 lr = 0xc02fdfa8 (bus_generic_new_pass+0xfc) sp = 0xc0d14e28 fp = 0xc0d14e40 r4 = 0xd00dfc80 r5 = 0xc0848ef8 r6 = 0xd00e0000 r7 = 0x00000000 r8 = 0xc0a615a8 r10 = 0xc0a4278c bus_generic_new_pass() at bus_generic_new_pass+0xfc pc = 0xc02fdfa8 lr = 0xc02f9490 (bus_set_pass+0x54) sp = 0xc0d14e48 fp = 0xc0d14e60 r4 = 0xd00e78a0 r5 = 0xc0848ef8 r6 = 0xd00e0000 r7 = 0xc0a615a8 r8 = 0x7fffffff r10 = 0xc0a4278c bus_set_pass() at bus_set_pass+0x54 pc = 0xc02f9490 lr = 0xc0255904 (mi_startup+0x2a4) sp = 0xc0d14e68 fp = 0xc0d14e90 r4 = 0xc08a48b4 r5 = 0xc0a42788 r6 = 0x00800001 r7 = 0x00000000 r8 = 0x03800000 r9 = 0xc0a42794 mi_startup() at mi_startup+0x2a4 pc = 0xc0255904 lr = 0xc00002c4 (_start+0x144) sp = 0xc0d14e98 fp = 0x00000000 r4 = 0xc00003f8 r5 = 0xc0b1c000 r6 = 0x00000000 r7 = 0x00c52078 r8 = 0xc0cdd000 r9 = 0x5af1e780 r10 = 0x00000000 _start() at _start+0x144 pc = 0xc00002c4 lr = 0xc00002c4 (_start+0x144) sp = 0xc0d14e98 fp = 0x00000000 KDB: enter: panic [ thread pid 0 tid 100000 ] Stopped at kdb_enter+0x58: ldrb r15, [r15, r15, ror r15]! It is possible to run at boot script which will fetch time from an external module and set system clock, but I am wondering if that can be done automatically (disabling internal rtc and using external)? Should it be possible to boot an ARM SBC without an internal RTC device? From owner-freebsd-arm@freebsd.org Wed Aug 19 10:15:57 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id DD4E43B97F9 for ; Wed, 19 Aug 2020 10:15:57 +0000 (UTC) (envelope-from mishin@mh.net.ru) Received: from frog.mh.net.ru (mh.balakovo.san.ru [88.147.158.22]) (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 4BWkFR5XcWz4XVB for ; Wed, 19 Aug 2020 10:15:54 +0000 (UTC) (envelope-from mishin@mh.net.ru) Received: from webmail.mh.net.ru (mouse.home [192.168.5.6]) by frog.mh.net.ru (Postfix) with ESMTPSA id A71A3ABFC9; Wed, 19 Aug 2020 14:15:51 +0400 (+04) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Wed, 19 Aug 2020 14:15:51 +0400 From: Alexander Mishin To: Oleksandr Tymoshenko Subject: Re: Kmod driver at iicbus. attach() and config_intrhook(9) In-Reply-To: <20200819072409.GA59949@bluezbox.com> References: <7fabb65d99aaa74775c1daa91bffb873@mh.net.ru> <3249fa7e-554a-83ef-57b2-7c38aa0b4591@FreeBSD.org> <20200819072409.GA59949@bluezbox.com> User-Agent: Roundcube Webmail/1.4.2 Message-ID: X-Sender: mishin@mh.net.ru X-Rspamd-Queue-Id: 4BWkFR5XcWz4XVB X-Spamd-Bar: +++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=mh.net.ru (policy=none); spf=fail (mx1.freebsd.org: domain of mishin@mh.net.ru does not designate 88.147.158.22 as permitted sender) smtp.mailfrom=mishin@mh.net.ru X-Spamd-Result: default: False [3.48 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_FAIL(1.00)[-all]; FORGED_RECIPIENTS(2.00)[gonzo@bluezbox.com,freebsd-arm@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; DMARC_POLICY_SOFTFAIL(0.10)[mh.net.ru : No valid SPF, No valid DKIM,none]; ARC_NA(0.00)[]; NEURAL_SPAM_SHORT(0.48)[0.482]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_ONE(0.00)[1]; TO_DN_ALL(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:12389, ipnet:88.147.128.0/17, country:RU]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-arm]; RCVD_COUNT_TWO(0.00)[2] X-Mailman-Approved-At: Wed, 19 Aug 2020 13:46:57 +0000 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2020 10:15:57 -0000 Thanks for your answers, especially for "...controllers use interrupts to get notified about...". It helped to understand. Yes, I need it as I check on attach() if the device connected. Everything was fine while I was loading the driver into an already running system, but as soon as I loaded the driver at boot time, I saw that its sysctl variables was only half filled (no result nor calculated values). config_intrhook_oneshot() solved this issue. Thanks once more Oleksandr Tymoshenko пиÑал 2020-08-19 11:24: > Andriy Gapon (avg@FreeBSD.org) wrote: >> On 18/08/2020 22:05, Alexander Mishin wrote: >> > Hi >> > .... >> > But I see that some other devices (from /usr/src/sys/dev) uses CONFIG_INTRHOOK(9) >> > on attach() for initialize themselfs. >> > I wonder if I need this too?... >> >> This is usually needed when a driver needs to talk to its device while >> attaching. E.g., to set some initial configuration or to confirm >> device's >> identity, etc. > > To extend Andriy's explanation a bit: all these operations may perform > I2C transfers and most I2C controllers use interrupts to get notified > about tranfer status change (finished, error, etc...). There is no > guarantee that when driver's attach method is called interrupts are > globally enabled. What would happen in this case is: I2C controller > is going to initiate I2C operation and wait for an interrupt that's > never going to be delivered. CONFIG_INTRHOOK is a solution for this > problem, if your attach method requires interrupts - just split it > in two parts and postpone running interrupt-dependent part until after > interrupts are globally enabled. From owner-freebsd-arm@freebsd.org Wed Aug 19 15:40:05 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id D76373C1A67 for ; Wed, 19 Aug 2020 15:40:05 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound5a.ore.mailhop.org (outbound5a.ore.mailhop.org [44.233.67.66]) (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 4BWsRT3Kmvz40wB for ; Wed, 19 Aug 2020 15:40:05 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1597851597; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=CLJX1u/Ezh86x2aAzFH5Ey3SiBbeQSgvfX4I9jywmpd/NyRdzg7xBS7X/ucgSW9XXfD7+dIk10aLQ onAX/FQtZwSDqqXG89bed47jPw/iT2CthRmCe3HgbSEtsO0YQLdyMFrfgG2Mlf9V/iYhGX60+SiJ0c m8koSis+yJJPehui/MoxNLZvkSRMuk5naz1QzD4ogqz0HxJ28sBRApagyxgPK9Tlnc2QRu4tgfe0Qm X6UL4iGGTRv+mhYYQW3e0Zsojnyz4hCws2dR6rttGDFe9JOMGikj44rQWVSrcdcqjeL5UyVkUwSa56 HK64WfpcXfJrnkHrREdTMH9PCwfwlZQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:dkim-signature:from; bh=0iZkNmjs55mse4Hv35Hf2xZSfPMx1O27I6+HIifkdx8=; b=vaEeA8xMyChD6zORSmiK7vyN7oF4QQoecx9JfzxFXSGdTKi7wnOqQhi391xZ/QT4N+Ng0GALv+G8C v2GaIeSOwXe/gqyN7SnVT7h5S4iAKtcLdGGqHtRvwgvygsO1kv2xRi3vrYQFlZdrEHU8+3TJ13AHQ7 hwQJ98XT56ftHeco0eHbEKioVOIxe3Hq28/B8SxxjOgbRdOqz0UHGBJjiRbPxxHJR3Ec9sEUqUtKDY TqLe0Gl/aXEThiVPcU3imXsr8eCWz5t9qN7JwTK+gOF0n0E2i7szWd7Wdpg2G27ZL3wI9mKy/5zAiY m3FKehMULWGosJdiWnvjOCMMwXS8B3w== ARC-Authentication-Results: i=1; outbound3.ore.mailhop.org; spf=softfail smtp.mailfrom=freebsd.org smtp.remote-ip=67.177.211.60; dmarc=none header.from=freebsd.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:from; bh=0iZkNmjs55mse4Hv35Hf2xZSfPMx1O27I6+HIifkdx8=; b=rNKaZKC2zbDwUqOEfMUGkspSutON7S+F+aPnmB0/CWpbTEqq4XhOMgMxRuTeND4mvRqbO55fuka/N fcx2k+n/VMtbZLHX9YC1sXeFfS1u7QsVaIkgKuIm01DbHXVP7Z9pg979yGiypxZPRnDFYzjvq46JDJ rhnCAAijyc4/6nZseHirA9+kRSNzUrOwUcxWjy7kaIC1GKWoRQuo1uKvYVPYt7IGdk+oppYAAO1JkX TI7A/jfGtr6CkGbIVdUDNoWsA77ssf0pg4HHFECclO8/WvOoLRe/dKgypGQ/UFeTsNLT4rZrVLK7U9 bOGBcM31QhBC2VI2DzLR8plPP9iW2OA== X-MHO-RoutePath: aGlwcGll X-MHO-User: 3aa43223-e232-11ea-a2bb-9f0c275c2f69 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (c-67-177-211-60.hsd1.co.comcast.net [67.177.211.60]) by outbound3.ore.mailhop.org (Halon) with ESMTPSA id 3aa43223-e232-11ea-a2bb-9f0c275c2f69; Wed, 19 Aug 2020 15:39:56 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id 07JFdstp089262; Wed, 19 Aug 2020 09:39:54 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <05145b71692af74b103bb226a2e93a15e1e851cb.camel@freebsd.org> Subject: Re: Kmod driver at iicbus. attach() and config_intrhook(9) From: Ian Lepore To: Oleksandr Tymoshenko , Andriy Gapon Cc: freebsd-arm@freebsd.org Date: Wed, 19 Aug 2020 09:39:54 -0600 In-Reply-To: <20200819072409.GA59949@bluezbox.com> References: <7fabb65d99aaa74775c1daa91bffb873@mh.net.ru> <3249fa7e-554a-83ef-57b2-7c38aa0b4591@FreeBSD.org> <20200819072409.GA59949@bluezbox.com> Content-Type: text/plain; charset="ASCII" X-Mailer: Evolution 3.28.5 FreeBSD GNOME Team Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4BWsRT3Kmvz40wB X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [0.00 / 15.00]; local_wl_from(0.00)[freebsd.org]; ASN(0.00)[asn:16509, ipnet:44.224.0.0/11, country:US] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2020 15:40:05 -0000 On Wed, 2020-08-19 at 00:24 -0700, Oleksandr Tymoshenko wrote: > Andriy Gapon (avg@FreeBSD.org) wrote: > > On 18/08/2020 22:05, Alexander Mishin wrote: > > > Hi > > > > > > I write a kmod driver for bh1750 light sensor with iic (almost > > > wrote). > > > As usual, probe(), attach() and detach(). On attach() it runs > > > TIMEOUT_TASK_INIT > > > for periodically write opecode, read result and place it to > > > sysctl dev.bh1750.N > > > variables. It is all. > > > > > > But I see that some other devices (from /usr/src/sys/dev) uses > > > CONFIG_INTRHOOK(9) > > > on attach() for initialize themselfs. > > > I wonder if I need this too? ...or maybe... when I might need it? > > > > This is usually needed when a driver needs to talk to its device > > while > > attaching. E.g., to set some initial configuration or to confirm > > device's > > identity, etc. > > To extend Andriy's explanation a bit: all these operations may > perform > I2C transfers and most I2C controllers use interrupts to get notified > about tranfer status change (finished, error, etc...). There is no > guarantee that when driver's attach method is called interrupts are > globally enabled. What would happen in this case is: I2C controller > is going to initiate I2C operation and wait for an interrupt that's > never going to be delivered. CONFIG_INTRHOOK is a solution for this > problem, if your attach method requires interrupts - just split it > in two parts and postpone running interrupt-dependent part until > after > interrupts are globally enabled. > A note about all this: It should never be necessary for an i2c slave device driver to do this. The reason it's needed is because many i2c controller drivers attach the iicbus from their attach() routine even though they can't actually do i2c IO until interrupts are available. It is these controller drivers that should have the intrhook logic to not call bus_generic_attach() until interrupts are available if they can't do IO until interrupts are available. It has long been my goal to fix all our i2c controller drivers to behave correctly, so that i2c slave device drivers don't all need the intrhook logic. But somehow I never get around to it. -- Ian From owner-freebsd-arm@freebsd.org Wed Aug 19 17:55:18 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 18CEB3C6002 for ; Wed, 19 Aug 2020 17:55:18 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound5a.ore.mailhop.org (outbound5a.ore.mailhop.org [44.233.67.66]) (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 4BWwRT383Nz4Mk7 for ; Wed, 19 Aug 2020 17:55:17 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1597859716; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=FzTivaLgcSFlprEcF4cGY8KBKUlltd+S270+svJ9paAhmJLQmVEiAYguc3io9ajerdFyeM6MAVz+u 9eH+zUGqRdniQGA7ha1aQ3mTth9wmLyxJC3KHDfTb2ejg4YiKULsctt09eLANfSQHhJOTsMNiYULXw Xp/Z+6OYV3U44hzSK5w/bSIUNa6cQyIxcN8ceuVVtJhCFAVaGwAzSEONXI+T5e5oF/3kqZSe+FP2eI o1GinqBJOKKDHO5ZpTvB+7qB2nwietN0rzujKkm3qa0cKHb5IdQlPaKCepxeI8YsEXajb+VO/L4pVF OKBd4k4wDHYE5tT5DI4qLRAWZ85Ap4g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:to:from:subject:message-id:dkim-signature:from; bh=L/zt5+MqXyRWXG/MTpb9iqONHkQMNdSqpmsI1y4YHcE=; b=ojBE4xHVLhStLtI9kWJnoVLw9YftQeR4mvBJ9b8R7y+LvGJ1rMD9aSOuk23qIEBazXr2kihsTW59F Vahy9ws5kr9GJap5JFR5aeFuv0d2buDUbbJibNjvAE/lSfUaz0pvNAPi6kB3vMHuswHqguy1c+ZYZ7 33VFzwTlVG38JE+/uz2+mye5W/Fq8VA6rZkwQhj5WHuq6QwXGAPcCiP9BuXjiFyBpI98upLadOPUrq DDwRtvm81y9Xvo3jEskfVID+TKwHBiOysfUv1pTia1cDAHAC1Xj9YPX1OD+5b4IvVUxorQ25CXZXkY fte/P+gwaKUZEWhfzjOidLU5Cg3pehw== ARC-Authentication-Results: i=1; outbound3.ore.mailhop.org; spf=softfail smtp.mailfrom=freebsd.org smtp.remote-ip=67.177.211.60; dmarc=none header.from=freebsd.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:to:from:subject:message-id:from; bh=L/zt5+MqXyRWXG/MTpb9iqONHkQMNdSqpmsI1y4YHcE=; b=lvOPThlxodsOTHqqG2+3FaL0dCCM8yPLgEP6HZftK+GX/+WpJntgd9Li2XAkJ7lBY1ldP/RSF8T/5 t4xw/7Trxhad9un79c2B/xOKDNO6LTLVraHR6sVYAF2fxl5dYfqSw4hc0wBJu22YKVNkszXXkuAv6+ dQ3GC5DasptWTzhKWDtR+z4++XpOH2dkkdA3ICqmh4BOSVKK3wOx6rK+wyUSYQ40je8QPc1bq0PcMT ROeq5dbdsyJc290mM6UpSkzJWqyE/hyhUoI7oJYOR3sRuswf5+LGO5b8RGgIqmGp1zSmrunyV0ZXx8 4Lw6u/wdA3fXly+zWyBIRXsKGQoOw+w== X-MHO-RoutePath: aGlwcGll X-MHO-User: 21de259d-e245-11ea-a2bb-9f0c275c2f69 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (c-67-177-211-60.hsd1.co.comcast.net [67.177.211.60]) by outbound3.ore.mailhop.org (Halon) with ESMTPSA id 21de259d-e245-11ea-a2bb-9f0c275c2f69; Wed, 19 Aug 2020 17:55:14 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id 07JHtD1p089603; Wed, 19 Aug 2020 11:55:13 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <6d88bd5659b854d9af73cb9a325c719c3d7d9da9.camel@freebsd.org> Subject: Re: Disabling internal RTC ends up in hang From: Ian Lepore To: Johnny Sorocil , freebsd-arm@freebsd.org Date: Wed, 19 Aug 2020 11:55:13 -0600 In-Reply-To: References: Content-Type: text/plain; charset="ASCII" X-Mailer: Evolution 3.28.5 FreeBSD GNOME Team Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4BWwRT383Nz4Mk7 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [0.00 / 15.00]; local_wl_from(0.00)[freebsd.org]; ASN(0.00)[asn:16509, ipnet:44.224.0.0/11, country:US] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2020 17:55:18 -0000 On Wed, 2020-08-19 at 10:13 +0200, Johnny Sorocil wrote: > I wan't to have the correct date on my ARM SBC (armv7 Orange Pi Zero > board > which doesn't have an RTC battery socket). Got an external I2C RTC > module > (DS3231) which is recognized and works (after adding device tree > overlay): > > root@arm2:~ # sysctl dev.ds3231 > dev.ds3231.0.32khz_enable: 1 > dev.ds3231.0.sqw_mode: interrupt > dev.ds3231.0.sqw_freq: 1024 > dev.ds3231.0.bbsqw: 0 > dev.ds3231.0.temp_conv: 0 > dev.ds3231.0.temperature: 30.0C > dev.ds3231.0.%parent: iicbus0 > dev.ds3231.0.%pnpinfo: name=ds3231@68 compat=maxim,ds3231 > dev.ds3231.0.%location: addr=0xd0 > dev.ds3231.0.%driver: ds3231 > dev.ds3231.0.%desc: Maxim DS3231 RTC > dev.ds3231.%parent: > > > Setting a date works - the system will have the correct date until > power is > disconnected. After power is connected again, system time is not read > from > RTC. > > After powercycle: > > root@arm2:~ # date > Fri Jan 1 00:22:25 UTC 2010 > root@arm2:~ # ./ds1307 -a 0x68 -r > 09:37:59 12/08/2020 > > NTP is not used. ds1307 > > program > is used to directly read registers from the I2C module. > > Disabling internal rtc (via device tree overlay) results in kernel > panic & > hang: > > ---<>--- > Copyright (c) 1992-2019 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 12.1-RELEASE r354233 GENERIC arm > FreeBSD clang version 8.0.1 (tags/RELEASE_801/final 366581) (based on > LLVM 8.0.1) > VT: init without driver. > module_register: cannot register ofwbus/pcib from kernel; already > loaded from kernel > Module ofwbus/pcib failed to register: 17 > module_register: cannot register simplebus/pcib from kernel; already > loaded from kernel > Module simplebus/pcib failed to register: 17 > CPU: ARM Cortex-A7 r0p5 (ECO: 0x00000000) > CPU Features: > Multiprocessing, Thumb2, Security, Virtualization, Generic Timer, > VMSAv7, > PXN, LPAE, Coherent Walk > Optional instructions: > SDIV/UDIV, UMULL, SMULL, SIMD(ext) > LoUU:2 LoC:3 LoUIS:2 > Cache level 1: > 32KB/64B 4-way data cache WB Read-Alloc Write-Alloc > 32KB/32B 2-way instruction cache Read-Alloc > Cache level 2: > 512KB/64B 8-way unified cache WB Read-Alloc Write-Alloc > real memory = 536289280 (511 MB) > avail memory = 509890560 (486 MB) > No PSCI/SMCCC call function found > FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs > random: unblocking device. > random: entropy device external interface > kbd0 at kbdmux0 > ofwbus0: > ofw_clkbus0: on ofwbus0 > clk_fixed0: on ofw_clkbus0 > clk_fixed1: on ofw_clkbus0 > simplebus0: on ofwbus0 > regfix0: on ofwbus0 > regfix1: on ofwbus0 > regfix2: on ofwbus0 > regfix3: on ofwbus0 > ccu_h3ng0: mem > 0x1c20000-0x1c203ff on simplebus0 > ccu_h3ng0: Clock apb2 have unknown parent: osc32k > ccu_h3ng0: Clock ahb1 have unknown parent: osc32k > ccu_h3ng0: Clock cpux have unknown parent: osc32k > panic: cannot finalize clkdom initialization > > cpuid = 0 > time = 1 > Uptime: 1s > Automatic reboot in 15 seconds - press a key on the console to abort > Rebooting... > Reset: watchdog device has not been initialized > Reset failed! > > > The same happens with -CURRENT with custom kernel compiled without > aw_rtc > device: > > % cat usr/src/sys/arm/conf/MYKERNEL > include GENERIC > ident MYKERNEL > > nodevice aw_rtc # Allwinner On-chip RTC > > Device tree overlay for disabling internal RTC is not enabled and > after > connecting serial console and booting that kernel: > > ... > simplebus0: on ofwbus0 > regfix0: on ofwbus0 > regfix1: on ofwbus0 > regfix2: on ofwbus0 > regfix3: on ofwbus0 > ccu_h3ng0: mem > 0x1c20000-0x1c203ff on simplebus0 > ccu_h3ng0: Clock apb2 have unknown parent: osc32k > ccu_h3ng0: Clock ahb1 have unknown parent: osc32k > ccu_h3ng0: Clock cpux have unknown parent: osc32k > panic: cannot finalize clkdom initialization > > cpuid = 0 > time = 1 > KDB: stack backtrace: > db_trace_self() at db_trace_self > pc = 0xc0578934 lr = 0xc0079eb0 > (db_trace_self_wrapper+0x30) > sp = 0xc0d14b98 fp = 0xc0d14cb0 > db_trace_self_wrapper() at db_trace_self_wrapper+0x30 > pc = 0xc0079eb0 lr = 0xc02bf54c (vpanic+0x174) > sp = 0xc0d14cb8 fp = 0xc0d14cd8 > r4 = 0x00000100 r5 = 0xc0a42b20 > r6 = 0xc06a0af6 r7 = 0x00000000 > vpanic() at vpanic+0x174 > pc = 0xc02bf54c lr = 0xc02bf308 (doadump) > sp = 0xc0d14ce0 fp = 0xc0d14ce4 > r4 = 0x000008c0 r5 = 0xd02f9800 > r6 = 0x00000071 r7 = 0xc0d14d18 > r8 = 0xc0d14d08 r9 = 0x00000001 > r10 = 0x00000000 > doadump() at doadump > pc = 0xc02bf308 lr = 0xc05be870 (aw_ccung_write_4) > sp = 0xc0d14cec fp = 0xc0d14d50 > r4 = 0x00000000 r5 = 0xc0d14ce4 > r6 = 0xc02bf308 r10 = 0xc0d14cec > aw_ccung_write_4() at aw_ccung_write_4 > pc = 0xc05be870 lr = 0xc02fc1b8 (device_attach+0x50c) > sp = 0xc0d14d58 fp = 0xc0d14da0 > r4 = 0x00000000 r5 = 0xc0ae30a4 > r6 = 0x80040001 r10 = 0x80000803 > device_attach() at device_attach+0x50c > pc = 0xc02fc1b8 lr = 0xc02fbc10 > (device_probe_and_attach+0x8c) > sp = 0xc0d14da8 fp = 0xc0d14dc0 > r4 = 0xd00de400 r5 = 0xc2471f80 > r6 = 0x5e4a6f28 r7 = 0x00000000 > r8 = 0xc0a615a8 r9 = 0xc0a615ac > r10 = 0xc0a4278c > device_probe_and_attach() at device_probe_and_attach+0x8c > pc = 0xc02fbc10 lr = 0xc02fdf5c (bus_generic_new_pass+0xb0) > sp = 0xc0d14dc8 fp = 0xc0d14de0 > r4 = 0xd00de400 r5 = 0xc0848ef8 > r6 = 0xc088cba0 r10 = 0xc0a4278c > bus_generic_new_pass() at bus_generic_new_pass+0xb0 > pc = 0xc02fdf5c lr = 0xc02fdfa8 (bus_generic_new_pass+0xfc) > sp = 0xc0d14de8 fp = 0xc0d14e00 > r4 = 0xd00df980 r5 = 0xc0848ef8 > r6 = 0xd00e0000 r7 = 0x00000000 > r8 = 0xc0a615a8 r10 = 0xc0a4278c > bus_generic_new_pass() at bus_generic_new_pass+0xfc > pc = 0xc02fdfa8 lr = 0xc02fdfa8 (bus_generic_new_pass+0xfc) > sp = 0xc0d14e08 fp = 0xc0d14e20 > r4 = 0xd00dfc00 r5 = 0xc0848ef8 > r6 = 0xd00e0000 r7 = 0x00000000 > r8 = 0xc0a615a8 r10 = 0xc0a4278c > bus_generic_new_pass() at bus_generic_new_pass+0xfc > pc = 0xc02fdfa8 lr = 0xc02fdfa8 (bus_generic_new_pass+0xfc) > sp = 0xc0d14e28 fp = 0xc0d14e40 > r4 = 0xd00dfc80 r5 = 0xc0848ef8 > r6 = 0xd00e0000 r7 = 0x00000000 > r8 = 0xc0a615a8 r10 = 0xc0a4278c > bus_generic_new_pass() at bus_generic_new_pass+0xfc > pc = 0xc02fdfa8 lr = 0xc02f9490 (bus_set_pass+0x54) > sp = 0xc0d14e48 fp = 0xc0d14e60 > r4 = 0xd00e78a0 r5 = 0xc0848ef8 > r6 = 0xd00e0000 r7 = 0xc0a615a8 > r8 = 0x7fffffff r10 = 0xc0a4278c > bus_set_pass() at bus_set_pass+0x54 > pc = 0xc02f9490 lr = 0xc0255904 (mi_startup+0x2a4) > sp = 0xc0d14e68 fp = 0xc0d14e90 > r4 = 0xc08a48b4 r5 = 0xc0a42788 > r6 = 0x00800001 r7 = 0x00000000 > r8 = 0x03800000 r9 = 0xc0a42794 > mi_startup() at mi_startup+0x2a4 > pc = 0xc0255904 lr = 0xc00002c4 (_start+0x144) > sp = 0xc0d14e98 fp = 0x00000000 > r4 = 0xc00003f8 r5 = 0xc0b1c000 > r6 = 0x00000000 r7 = 0x00c52078 > r8 = 0xc0cdd000 r9 = 0x5af1e780 > r10 = 0x00000000 > _start() at _start+0x144 > pc = 0xc00002c4 lr = 0xc00002c4 (_start+0x144) > sp = 0xc0d14e98 fp = 0x00000000 > KDB: enter: panic > [ thread pid 0 tid 100000 ] > Stopped at kdb_enter+0x58: ldrb r15, [r15, r15, ror r15]! > > It is possible to run at boot script which will fetch time from an > external > module and set system clock, but I am wondering if that can be done > automatically (disabling internal rtc and using external)? > Should it be possible to boot an ARM SBC without an internal RTC > device? > I think you may be running into a problem Andriy (avg@) described on irc the other day: the allwinner RTC hardware has no way to detect whether it lost power, so it always supplies the time, even if it's incorrect. When there are multiple RTCs in the system, the kernel asks them in the order they registered until one provides the time. I suspect the panic is happening because the internal RTC also provides the system 32khz clock, which is needed by other devices. He cooked up this patch: http://paste.ubuntu.com/p/6hhtQbJC85/ With that patch in place, the 32khz clock would be available, but the RTC would not supply the time unless it was correct. -- Ian From owner-freebsd-arm@freebsd.org Thu Aug 20 06:07:52 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 7A2703B17FA for ; Thu, 20 Aug 2020 06:07:52 +0000 (UTC) (envelope-from mishin@mh.net.ru) Received: from frog.mh.net.ru (mh.balakovo.san.ru [88.147.158.22]) (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 4BXDhk3Wh9z3fCm for ; Thu, 20 Aug 2020 06:07:48 +0000 (UTC) (envelope-from mishin@mh.net.ru) Received: from webmail.mh.net.ru (mouse.home [192.168.5.6]) by frog.mh.net.ru (Postfix) with ESMTPSA id 61351AC6F9 for ; Thu, 20 Aug 2020 10:07:39 +0400 (+04) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Thu, 20 Aug 2020 10:07:38 +0400 From: Alexander Mishin To: freebsd-arm@freebsd.org Subject: Re: Kmod driver at iicbus. attach() and config_intrhook(9) In-Reply-To: <05145b71692af74b103bb226a2e93a15e1e851cb.camel@freebsd.org> References: <7fabb65d99aaa74775c1daa91bffb873@mh.net.ru> <3249fa7e-554a-83ef-57b2-7c38aa0b4591@FreeBSD.org> <20200819072409.GA59949@bluezbox.com> <05145b71692af74b103bb226a2e93a15e1e851cb.camel@freebsd.org> User-Agent: Roundcube Webmail/1.4.2 Message-ID: X-Sender: mishin@mh.net.ru X-Rspamd-Queue-Id: 4BXDhk3Wh9z3fCm X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=mh.net.ru (policy=none); spf=fail (mx1.freebsd.org: domain of mishin@mh.net.ru does not designate 88.147.158.22 as permitted sender) smtp.mailfrom=mishin@mh.net.ru X-Spamd-Result: default: False [2.18 / 15.00]; RCVD_TLS_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_FAIL(1.00)[-all]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_SPAM_SHORT(0.56)[0.563]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; NEURAL_SPAM_MEDIUM(0.61)[0.613]; RCPT_COUNT_ONE(0.00)[1]; ARC_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:12389, ipnet:88.147.128.0/17, country:RU]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arm]; DMARC_POLICY_SOFTFAIL(0.10)[mh.net.ru : No valid SPF, No valid DKIM,none] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2020 06:07:52 -0000 Ian Lepore пиÑал 2020-08-19 19:39: > On Wed, 2020-08-19 at 00:24 -0700, Oleksandr Tymoshenko wrote: >> Andriy Gapon (avg@FreeBSD.org) wrote: >> > On 18/08/2020 22:05, Alexander Mishin wrote: >> > > Hi >> > > ... >> > > But I see that some other devices (from /usr/src/sys/dev) uses >> > > CONFIG_INTRHOOK(9) >> > > on attach() for initialize themselfs. >> > > I wonder if I need this too? ... >> > >> > This is usually needed when a driver needs to talk to its device >> > while >> > attaching. E.g., to set some initial configuration or to confirm >> > device's >> > identity, etc. >> >> To extend Andriy's explanation a bit: all these operations may >> perform >> I2C transfers and most I2C controllers use interrupts to get notified >> about tranfer status change (finished, error, etc...). There is no >> guarantee that when driver's attach method is called interrupts are >> globally enabled. What would happen in this case is: I2C controller >> is going to initiate I2C operation and wait for an interrupt that's >> never going to be delivered. CONFIG_INTRHOOK is a solution for this >> problem, if your attach method requires interrupts - just split it >> in two parts and postpone running interrupt-dependent part until >> after >> interrupts are globally enabled. >> > > A note about all this: It should never be necessary for an i2c slave > device driver to do this. The reason it's needed is because many i2c > controller drivers attach the iicbus from their attach() routine even > though they can't actually do i2c IO until interrupts are available. > It is these controller drivers that should have the intrhook logic to > not call bus_generic_attach() until interrupts are available if they > can't do IO until interrupts are available. > > It has long been my goal to fix all our i2c controller drivers to > behave correctly, so that i2c slave device drivers don't all need the > intrhook logic. But somehow I never get around to it. > > -- Ian I think, it would be helpful, as it would be possible to return an error on early stage, from attach(), if there is no connection with the configured device. From owner-freebsd-arm@freebsd.org Thu Aug 20 22:39:29 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 407193AB156 for ; Thu, 20 Aug 2020 22:39:29 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gate2.funkthat.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BXfhw23lpz466Y for ; Thu, 20 Aug 2020 22:39:27 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.15.2/8.15.2) with ESMTPS id 07KMdJxL021343 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 20 Aug 2020 15:39:19 -0700 (PDT) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.15.2/8.15.2/Submit) id 07KMdIRI021342; Thu, 20 Aug 2020 15:39:18 -0700 (PDT) (envelope-from jmg) Date: Thu, 20 Aug 2020 15:39:18 -0700 From: John-Mark Gurney To: Alexander Mishin Cc: freebsd-arm@freebsd.org Subject: Re: Kmod driver at iicbus. attach() and config_intrhook(9) Message-ID: <20200820223918.GC4213@funkthat.com> Mail-Followup-To: Alexander Mishin , freebsd-arm@freebsd.org References: <7fabb65d99aaa74775c1daa91bffb873@mh.net.ru> <3249fa7e-554a-83ef-57b2-7c38aa0b4591@FreeBSD.org> <20200819072409.GA59949@bluezbox.com> <05145b71692af74b103bb226a2e93a15e1e851cb.camel@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 11.3-STABLE amd64 X-PGP-Fingerprint: D87A 235F FB71 1F3F 55B7 ED9B D5FF 5A51 C0AC 3D65 X-Files: The truth is out there X-URL: https://www.funkthat.com/ X-Resume: https://www.funkthat.com/~jmg/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.6.1 (2016-04-27) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (gold.funkthat.com [127.0.0.1]); Thu, 20 Aug 2020 15:39:19 -0700 (PDT) X-Rspamd-Queue-Id: 4BXfhw23lpz466Y X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of jmg@gold.funkthat.com has no SPF policy when checking 208.87.223.18) smtp.mailfrom=jmg@gold.funkthat.com X-Spamd-Result: default: False [2.03 / 15.00]; MID_RHS_MATCH_FROM(0.00)[]; MAILMAN_DEST(0.00)[freebsd-arm]; FREEFALL_USER(0.00)[jmg]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; ARC_NA(0.00)[]; NEURAL_SPAM_SHORT(0.06)[0.064]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[funkthat.com]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.76)[0.764]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; R_SPF_NA(0.00)[no SPF record]; FORGED_SENDER(0.30)[jmg@funkthat.com,jmg@gold.funkthat.com]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; FROM_NEQ_ENVFROM(0.00)[jmg@funkthat.com,jmg@gold.funkthat.com]; ASN(0.00)[asn:32354, ipnet:208.87.216.0/21, country:US] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2020 22:39:29 -0000 Alexander Mishin wrote this message on Thu, Aug 20, 2020 at 10:07 +0400: > Ian Lepore ?????????? 2020-08-19 19:39: > > On Wed, 2020-08-19 at 00:24 -0700, Oleksandr Tymoshenko wrote: > >> Andriy Gapon (avg@FreeBSD.org) wrote: > >> > On 18/08/2020 22:05, Alexander Mishin wrote: > >> > > Hi > >> > > ... > >> > > But I see that some other devices (from /usr/src/sys/dev) uses > >> > > CONFIG_INTRHOOK(9) > >> > > on attach() for initialize themselfs. > >> > > I wonder if I need this too? ... > >> > > >> > This is usually needed when a driver needs to talk to its device > >> > while > >> > attaching. E.g., to set some initial configuration or to confirm > >> > device's > >> > identity, etc. > >> > >> To extend Andriy's explanation a bit: all these operations may > >> perform > >> I2C transfers and most I2C controllers use interrupts to get notified > >> about tranfer status change (finished, error, etc...). There is no > >> guarantee that when driver's attach method is called interrupts are > >> globally enabled. What would happen in this case is: I2C controller > >> is going to initiate I2C operation and wait for an interrupt that's > >> never going to be delivered. CONFIG_INTRHOOK is a solution for this > >> problem, if your attach method requires interrupts - just split it > >> in two parts and postpone running interrupt-dependent part until > >> after > >> interrupts are globally enabled. > >> > > > > A note about all this: It should never be necessary for an i2c slave > > device driver to do this. The reason it's needed is because many i2c > > controller drivers attach the iicbus from their attach() routine even > > though they can't actually do i2c IO until interrupts are available. > > It is these controller drivers that should have the intrhook logic to > > not call bus_generic_attach() until interrupts are available if they > > can't do IO until interrupts are available. > > > > It has long been my goal to fix all our i2c controller drivers to > > behave correctly, so that i2c slave device drivers don't all need the > > intrhook logic. But somehow I never get around to it. > > I think, it would be helpful, as it would be possible to return an error > on early stage, from attach(), if there is no connection with the > configured device. Looks like there's a function bus_delayed_attach_children designed exactly for this: * Many buses can't run transactions on the bus which children need to probe and * attach until after interrupts and/or timers are running. This function * delays their attach until interrupts and timers are enabled. and it looks like a couple controllers are already using it, imx_i2c and ti_i2c... It looks like maybe a simple replace of bus_generic_attach w/ bus_delayed_attach_children should be enough on those w/ interrupts... Is there any argument for doing it for ALL controllers instead of just some? Poking around some, and it looks like some (one) drivers "pretend" to use interrupts, but just busy wait instead, e.g. exynos5... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@freebsd.org Thu Aug 20 22:51:41 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id B75573AB439 for ; Thu, 20 Aug 2020 22:51:41 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound2k.ore.mailhop.org (outbound2k.ore.mailhop.org [54.148.219.64]) (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 4BXfz11mZdz46ss for ; Thu, 20 Aug 2020 22:51:40 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1597963899; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=Jbi0jmM+rpql1MVHfBeccLeWmRqMHpGvY7x/8nMjFkUzsq9h6c/Y7CRGQQT5wdseecuGdZsIStCuX rkH4hkUeptMmWrgDIUX7iDfWv7N+qSjv8lpfTVI/1Ey7pXXUqOHPgVIHuIFpIr0YmvQTMSwGYW72Gb fAG8I5T/n47SjUdXj5Ow8x5Tl2zhPOr+6WDc/t6yh7p30m/VbAKcESdvhWbAE9kHoz/AbWLthaJbJ8 x3wbHJSWxF3MOVWyoCJDmdFIElVT0M6r2Leq1q2z7sG0P/qyYaklQ+bbWXiMJ1wqsd67nZgdY+Scuu ar2YM8jjF1C7MhVzcUawrDBEoyAFBAg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:dkim-signature:from; bh=9x1eIqhHeX+oNg7aQNH6AECjJIz2fepwaXJPAdClg34=; b=r9GrSr+4w8jEmbjknqW8Z1yI4F8WFXKIphxRbS0Uxgs3GUR5etwwmYWWtie9rwOR1aV48YLVUXGJg 01xmRS6lIleZ4VnVxAPzUh9v3TQ2pZ53/sdlVO3Iu8ffjq54FQbf38HcURzLjjkRNbnCC4TxHCSNYe iQZnfvii+sN+hqySlPi7NzkwtKewlfB+t85y10EyYFe3kK9T60XdxAuEdIBtDwUNtacKhWOI+NGBtr xRnIXEi7i9g96+J3J+pO6TFkrUf4A6K3FQcf65q1lkxVvQxvQ6tyQiJoxR8v/w5tN2Hb8482BInO2I E/4X9SswZyRFbndSvKAfwYqMelD4FHg== ARC-Authentication-Results: i=1; outbound4.ore.mailhop.org; spf=softfail smtp.mailfrom=freebsd.org smtp.remote-ip=67.177.211.60; dmarc=none header.from=freebsd.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:from; bh=9x1eIqhHeX+oNg7aQNH6AECjJIz2fepwaXJPAdClg34=; b=pP6m+f5OiDTyokrF3Ej9/W0FbkkQIiEMxzyHzu3sRXrPeYGBCHWCSxIR08vUhn11sA8zRu+s2jotg 0f4Gv/uVDjFM74hYXUKv7bNSXP1Hbg1J3RlfwqtsHu4j7/Qochjvb0aPmSbvNsNEoHWMABVFDb0AR8 bwxpml1ISfhn10B7uon0TiATz3WV5oJL6/DuIc7sDZrKpmPb1J4Be1PEmQtvYby+CVNwHwVTPkgK46 CEK4ra0763JcjYTqS2HUXoOaa1nM+7L/CrFbXMJoPVW3DQyJIWNsoFDjJ5RNpoPf9l3C/T5G0xHZR5 Ht/M5bWYAii5554VMpid4/t8q6oBwjQ== X-MHO-RoutePath: aGlwcGll X-MHO-User: b073419d-e337-11ea-b630-6b8aa7872eb8 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (c-67-177-211-60.hsd1.co.comcast.net [67.177.211.60]) by outbound4.ore.mailhop.org (Halon) with ESMTPSA id b073419d-e337-11ea-b630-6b8aa7872eb8; Thu, 20 Aug 2020 22:51:38 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id 07KMpUgP094345; Thu, 20 Aug 2020 16:51:30 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: Subject: Re: Kmod driver at iicbus. attach() and config_intrhook(9) From: Ian Lepore To: John-Mark Gurney , Alexander Mishin Cc: freebsd-arm@freebsd.org Date: Thu, 20 Aug 2020 16:51:30 -0600 In-Reply-To: <20200820223918.GC4213@funkthat.com> References: <7fabb65d99aaa74775c1daa91bffb873@mh.net.ru> <3249fa7e-554a-83ef-57b2-7c38aa0b4591@FreeBSD.org> <20200819072409.GA59949@bluezbox.com> <05145b71692af74b103bb226a2e93a15e1e851cb.camel@freebsd.org> <20200820223918.GC4213@funkthat.com> Content-Type: text/plain; charset="ASCII" X-Mailer: Evolution 3.28.5 FreeBSD GNOME Team Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4BXfz11mZdz46ss X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [0.00 / 15.00]; ASN(0.00)[asn:16509, ipnet:54.148.0.0/15, country:US]; local_wl_from(0.00)[freebsd.org] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2020 22:51:41 -0000 On Thu, 2020-08-20 at 15:39 -0700, John-Mark Gurney wrote: > Alexander Mishin wrote this message on Thu, Aug 20, 2020 at 10:07 > +0400: > > Ian Lepore ?????????? 2020-08-19 19:39: > > > On Wed, 2020-08-19 at 00:24 -0700, Oleksandr Tymoshenko wrote: > > > > Andriy Gapon (avg@FreeBSD.org) wrote: > > > > > On 18/08/2020 22:05, Alexander Mishin wrote: > > > > > > Hi > > > > > > ... > > > > > > But I see that some other devices (from /usr/src/sys/dev) > > > > > > uses > > > > > > CONFIG_INTRHOOK(9) > > > > > > on attach() for initialize themselfs. > > > > > > I wonder if I need this too? ... > > > > > > > > > > This is usually needed when a driver needs to talk to its > > > > > device > > > > > while > > > > > attaching. E.g., to set some initial configuration or to > > > > > confirm > > > > > device's > > > > > identity, etc. > > > > > > > > To extend Andriy's explanation a bit: all these operations may > > > > perform > > > > I2C transfers and most I2C controllers use interrupts to get > > > > notified > > > > about tranfer status change (finished, error, etc...). There is > > > > no > > > > guarantee that when driver's attach method is called interrupts > > > > are > > > > globally enabled. What would happen in this case is: I2C > > > > controller > > > > is going to initiate I2C operation and wait for an interrupt > > > > that's > > > > never going to be delivered. CONFIG_INTRHOOK is a solution for > > > > this > > > > problem, if your attach method requires interrupts - just split > > > > it > > > > in two parts and postpone running interrupt-dependent part > > > > until > > > > after > > > > interrupts are globally enabled. > > > > > > > > > > A note about all this: It should never be necessary for an i2c > > > slave > > > device driver to do this. The reason it's needed is because many > > > i2c > > > controller drivers attach the iicbus from their attach() routine > > > even > > > though they can't actually do i2c IO until interrupts are > > > available. > > > It is these controller drivers that should have the intrhook > > > logic to > > > not call bus_generic_attach() until interrupts are available if > > > they > > > can't do IO until interrupts are available. > > > > > > It has long been my goal to fix all our i2c controller drivers to > > > behave correctly, so that i2c slave device drivers don't all need > > > the > > > intrhook logic. But somehow I never get around to it. > > > > I think, it would be helpful, as it would be possible to return an > > error > > on early stage, from attach(), if there is no connection with the > > configured device. > > Looks like there's a function bus_delayed_attach_children designed > exactly for this: > * Many buses can't run transactions on the bus which children need > to probe and > * attach until after interrupts and/or timers are running. This > function > * delays their attach until interrupts and timers are enabled. > > and it looks like a couple controllers are already using it, imx_i2c > and ti_i2c... > > It looks like maybe a simple replace of bus_generic_attach w/ > bus_delayed_attach_children should be enough on those w/ > interrupts... > > Is there any argument for doing it for ALL controllers instead of > just > some? > > Poking around some, and it looks like some (one) drivers "pretend" to > use interrupts, but just busy wait instead, e.g. exynos5... > Hmm, yeah, it looks like more has been done along these lines than I remembered. In fact, the work may be done. Some i2c controllers have to work properly before interrupts are available, to control things like PMIC chips that are required very early in device configuration. Typically they have some sort of polling mechanism that's used early, and revert to using interrupts once they're available. The allwinner and rockchip drivers work that way. -- Ian From owner-freebsd-arm@freebsd.org Thu Aug 20 23:53:06 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 9ED5E3AD1D9 for ; Thu, 20 Aug 2020 23:53:06 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gate2.funkthat.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BXhKs2rk9z4D4f; Thu, 20 Aug 2020 23:53:04 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.15.2/8.15.2) with ESMTPS id 07KNr2Ar026754 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 20 Aug 2020 16:53:02 -0700 (PDT) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.15.2/8.15.2/Submit) id 07KNr1RT026753; Thu, 20 Aug 2020 16:53:01 -0700 (PDT) (envelope-from jmg) Date: Thu, 20 Aug 2020 16:53:01 -0700 From: John-Mark Gurney To: Ian Lepore Cc: Alexander Mishin , freebsd-arm@freebsd.org Subject: Re: Kmod driver at iicbus. attach() and config_intrhook(9) Message-ID: <20200820235301.GE4213@funkthat.com> Mail-Followup-To: Ian Lepore , Alexander Mishin , freebsd-arm@freebsd.org References: <7fabb65d99aaa74775c1daa91bffb873@mh.net.ru> <3249fa7e-554a-83ef-57b2-7c38aa0b4591@FreeBSD.org> <20200819072409.GA59949@bluezbox.com> <05145b71692af74b103bb226a2e93a15e1e851cb.camel@freebsd.org> <20200820223918.GC4213@funkthat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 11.3-STABLE amd64 X-PGP-Fingerprint: D87A 235F FB71 1F3F 55B7 ED9B D5FF 5A51 C0AC 3D65 X-Files: The truth is out there X-URL: https://www.funkthat.com/ X-Resume: https://www.funkthat.com/~jmg/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.6.1 (2016-04-27) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (gold.funkthat.com [127.0.0.1]); Thu, 20 Aug 2020 16:53:03 -0700 (PDT) X-Rspamd-Queue-Id: 4BXhKs2rk9z4D4f X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of jmg@gold.funkthat.com has no SPF policy when checking 208.87.223.18) smtp.mailfrom=jmg@gold.funkthat.com X-Spamd-Result: default: False [2.37 / 15.00]; MID_RHS_MATCH_FROM(0.00)[]; MAILMAN_DEST(0.00)[freebsd-arm]; FREEFALL_USER(0.00)[jmg]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_SPAM_SHORT(0.39)[0.393]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[funkthat.com]; ARC_NA(0.00)[]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.77)[0.775]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_NA(0.00)[no SPF record]; FORGED_SENDER(0.30)[jmg@funkthat.com,jmg@gold.funkthat.com]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; FROM_NEQ_ENVFROM(0.00)[jmg@funkthat.com,jmg@gold.funkthat.com]; ASN(0.00)[asn:32354, ipnet:208.87.216.0/21, country:US] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2020 23:53:06 -0000 Ian Lepore wrote this message on Thu, Aug 20, 2020 at 16:51 -0600: > On Thu, 2020-08-20 at 15:39 -0700, John-Mark Gurney wrote: > > Alexander Mishin wrote this message on Thu, Aug 20, 2020 at 10:07 > > +0400: > > > Ian Lepore ?????????? 2020-08-19 19:39: > > > > On Wed, 2020-08-19 at 00:24 -0700, Oleksandr Tymoshenko wrote: > > > > > Andriy Gapon (avg@FreeBSD.org) wrote: > > > > > > On 18/08/2020 22:05, Alexander Mishin wrote: > > > > > > > Hi > > > > > > > ... > > > > > > > But I see that some other devices (from /usr/src/sys/dev) > > > > > > > uses > > > > > > > CONFIG_INTRHOOK(9) > > > > > > > on attach() for initialize themselfs. > > > > > > > I wonder if I need this too? ... > > > > > > > > > > > > This is usually needed when a driver needs to talk to its > > > > > > device > > > > > > while > > > > > > attaching. E.g., to set some initial configuration or to > > > > > > confirm > > > > > > device's > > > > > > identity, etc. > > > > > > > > > > To extend Andriy's explanation a bit: all these operations may > > > > > perform > > > > > I2C transfers and most I2C controllers use interrupts to get > > > > > notified > > > > > about tranfer status change (finished, error, etc...). There is > > > > > no > > > > > guarantee that when driver's attach method is called interrupts > > > > > are > > > > > globally enabled. What would happen in this case is: I2C > > > > > controller > > > > > is going to initiate I2C operation and wait for an interrupt > > > > > that's > > > > > never going to be delivered. CONFIG_INTRHOOK is a solution for > > > > > this > > > > > problem, if your attach method requires interrupts - just split > > > > > it > > > > > in two parts and postpone running interrupt-dependent part > > > > > until > > > > > after > > > > > interrupts are globally enabled. > > > > > > > > > > > > > A note about all this: It should never be necessary for an i2c > > > > slave > > > > device driver to do this. The reason it's needed is because many > > > > i2c > > > > controller drivers attach the iicbus from their attach() routine > > > > even > > > > though they can't actually do i2c IO until interrupts are > > > > available. > > > > It is these controller drivers that should have the intrhook > > > > logic to > > > > not call bus_generic_attach() until interrupts are available if > > > > they > > > > can't do IO until interrupts are available. > > > > > > > > It has long been my goal to fix all our i2c controller drivers to > > > > behave correctly, so that i2c slave device drivers don't all need > > > > the > > > > intrhook logic. But somehow I never get around to it. > > > > > > I think, it would be helpful, as it would be possible to return an > > > error > > > on early stage, from attach(), if there is no connection with the > > > configured device. > > > > Looks like there's a function bus_delayed_attach_children designed > > exactly for this: > > * Many buses can't run transactions on the bus which children need > > to probe and > > * attach until after interrupts and/or timers are running. This > > function > > * delays their attach until interrupts and timers are enabled. > > > > and it looks like a couple controllers are already using it, imx_i2c > > and ti_i2c... > > > > It looks like maybe a simple replace of bus_generic_attach w/ > > bus_delayed_attach_children should be enough on those w/ > > interrupts... > > > > Is there any argument for doing it for ALL controllers instead of > > just > > some? > > > > Poking around some, and it looks like some (one) drivers "pretend" to > > use interrupts, but just busy wait instead, e.g. exynos5... > > > > Hmm, yeah, it looks like more has been done along these lines than I > remembered. In fact, the work may be done. > > Some i2c controllers have to work properly before interrupts are > available, to control things like PMIC chips that are required very > early in device configuration. Typically they have some sort of Ahh, yeah, forgot about PMICs... > polling mechanism that's used early, and revert to using interrupts > once they're available. The allwinner and rockchip drivers work that > way. So, sounds like any controller that is found to not be doing this, needs to be fixed to use the above function, and then the remaining ones that either poll, or use the hybrid approach can keep using bus_generic_attach... Back to original question, no, that additional logic should not be needed, and any controller that requires it needs to be fixed instead... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@freebsd.org Fri Aug 21 00:41:10 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 54CF53AE4B1 for ; Fri, 21 Aug 2020 00:41:10 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound5a.ore.mailhop.org (outbound5a.ore.mailhop.org [44.233.67.66]) (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 4BXjPK49xtz4G8F for ; Fri, 21 Aug 2020 00:41:09 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1597970462; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=o8icZe1uPfZsVccQ8gQYbOyOXdOTHfEXXkGRJblL5jCRtwE1YZP1sYmLCZUl6PXjJM7HW9xHMyQeK oadcFPRht2i7KJIJKlZ2eXMN4QtV7uo+hOgNsKn2PEPmG5nXf+MZDDnuD9kygMluoGwePTJcdas/fZ z72vq4ksq9f9vSaSyJYjgpIOyn4v9xmrvuqBSzid+4kZGVd2E9rGpan1YZpX1+ZC4bJ78kXKtVIGrQ hG7wYSvcHDGVFIYIWJJSPpyoiA/b/YNtCB4Ca/2EeUH5T5BE6kGLM4yFAsyERb4y+KKIRgvQ4FQG+I JW1ooqDpHf2l4pqirND5G4fQZVvwqFw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:dkim-signature:from; bh=GIMmSM2gwguhD+9WfQz+OUKouLFQwhz4D854Ezd4nCc=; b=TqVLpOapZD1fOk5mkEuKkZ5e0LgWcddu6tOnrGvTKzLI2RuzGlFueOJwSMdxYMwI20gC8uv8kfW+o XvOvX2DX3Trfx6L3T9wsYuVbZvBYuICr1PJNdE0h7JQJW++IEq+TpnCYUeHpe62w2sgm6zZfsCHlEw Iih7xwUj9gITxkonbHvNXedVCK3OUDUVGsBHNQLRyPeCFVdJ/xoDjcvZhU1DGDoMop9znQkitFBU2K GH+in0E9ryAiBsxZ8emYMCBPoJUJTir3uSNGzOqyJ8HNApQ8MyvOUtZGAWf3ed3xI2pd/bHtZepdBi YiYqqvhh4OuRkDYMLFoZyOTGAQil/kA== ARC-Authentication-Results: i=1; outbound3.ore.mailhop.org; spf=softfail smtp.mailfrom=freebsd.org smtp.remote-ip=67.177.211.60; dmarc=none header.from=freebsd.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:from; bh=GIMmSM2gwguhD+9WfQz+OUKouLFQwhz4D854Ezd4nCc=; b=suai45tgondLALqw18Vc1DDK+VupfiN6sESI2elh+BAntSA7rb7JSpBIVk42UZK+yi6vUXSQEYf2O VTApdbYtXrn8e7VTH+M2GgxsbXBeEJrY72YIu5q7Y9THs6g642uot8//VNYwcy0s/vEhGaAZFl3Oxi 42anFXZRHaroSSh4xZQ0enQwTtHZOBa2vY5rE6ZQIOYcUQp0UUhZBCxqrewtumy7WrdQ3P2e7R+Bak iaAcIf5nlqx+5iDwU2x9oxVqbhVfQ6Em/6xQWDZKrFoihTbEOlPacvTNssTm8nEruvwkUnFZ9gaKq1 w/2wJp6ak++5LEDVdCb+pavqyr9JcSw== X-MHO-RoutePath: aGlwcGll X-MHO-User: f8f3431f-e346-11ea-a2bb-9f0c275c2f69 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (c-67-177-211-60.hsd1.co.comcast.net [67.177.211.60]) by outbound3.ore.mailhop.org (Halon) with ESMTPSA id f8f3431f-e346-11ea-a2bb-9f0c275c2f69; Fri, 21 Aug 2020 00:41:00 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id 07L0etCs094655; Thu, 20 Aug 2020 18:40:55 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: Subject: Re: Kmod driver at iicbus. attach() and config_intrhook(9) From: Ian Lepore To: John-Mark Gurney Cc: Alexander Mishin , freebsd-arm@freebsd.org Date: Thu, 20 Aug 2020 18:40:54 -0600 In-Reply-To: <20200820235301.GE4213@funkthat.com> References: <7fabb65d99aaa74775c1daa91bffb873@mh.net.ru> <3249fa7e-554a-83ef-57b2-7c38aa0b4591@FreeBSD.org> <20200819072409.GA59949@bluezbox.com> <05145b71692af74b103bb226a2e93a15e1e851cb.camel@freebsd.org> <20200820223918.GC4213@funkthat.com> <20200820235301.GE4213@funkthat.com> Content-Type: text/plain; charset="ASCII" X-Mailer: Evolution 3.28.5 FreeBSD GNOME Team Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4BXjPK49xtz4G8F X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [0.00 / 15.00]; ASN(0.00)[asn:16509, ipnet:44.224.0.0/11, country:US]; local_wl_from(0.00)[freebsd.org] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2020 00:41:10 -0000 On Thu, 2020-08-20 at 16:53 -0700, John-Mark Gurney wrote: > > Hmm, yeah, it looks like more has been done along these lines than I > > remembered. In fact, the work may be done. > > > > Some i2c controllers have to work properly before interrupts are > > available, to control things like PMIC chips that are required very > > early in device configuration. Typically they have some sort of > > Ahh, yeah, forgot about PMICs... > > > polling mechanism that's used early, and revert to using interrupts > > once they're available. The allwinner and rockchip drivers work that > > way. > > So, sounds like any controller that is found to not be doing this, needs > to be fixed to use the above function, and then the remaining ones that > either poll, or use the hybrid approach can keep using > bus_generic_attach... > > Back to original question, no, that additional logic should not be > needed, and any controller that requires it needs to be fixed > instead... Yeah, it was always my plan that after all controller drivers were updated, the intrhook stuff could be removed from slave drivers that still have it. I'd like to see the controllers that can do xfers without interrupts have a comment that says so. Something like /* no need for bus_delayed_attach(), we xfer without interrupts */ Then you can grep -l for add_child.*iicbus and grep for bus_delayed_attach and compare the two file lists to find drivers that may not be doing the right thing. Using that technique now shows that we may still have a dozen or so controller drivers to fix (or at least examine for correctness). BTW, all of this tends to apply to SPI controller and slave drivers too, but the problem is likely smaller there because we have fewer SPI controller drivers. -- Ian From owner-freebsd-arm@freebsd.org Fri Aug 21 10:25:19 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 959653B99CD for ; Fri, 21 Aug 2020 10:25:19 +0000 (UTC) (envelope-from jsorocil@gmail.com) Received: from mail-ot1-x341.google.com (mail-ot1-x341.google.com [IPv6:2607:f8b0:4864:20::341]) (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 4BXyML2yPrz3VF2; Fri, 21 Aug 2020 10:25:18 +0000 (UTC) (envelope-from jsorocil@gmail.com) Received: by mail-ot1-x341.google.com with SMTP id r21so1168905ota.10; Fri, 21 Aug 2020 03:25:18 -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=5UrcOCFlkrXQEtUEraaysxksCYPIAjDttcu8eqDuqHw=; b=WBVXSWHwsy08DluWYIHxY9uVCqELdgIYguPQk85LsW/mEYdcXSBSJb9ZnDzLtoph7w FgJscHM8WIYiu9H5ksxAbNR7brf4z6zGzlYDjoKza82sYHHzvZHuojmOpCF/8exLtr2O BdFm13nf1w/dE42Mq9WiXJgqSNhNKf/S4ySLR+lRToSHb1610zqvT5a22EG1fMQD1tVB psTIsPOuu9tXe6ZSfpa8WJLPDpFtXshvUK2JBAjKyLv/UqqUEJhlCPDd6+y3k8wf6vxM XRCZk3lebHIVncqIhv0JKdn9MS3kLXsNHodDQw7Emz0kje7MLOULripP51YmPy4ehnMs JLTA== 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=5UrcOCFlkrXQEtUEraaysxksCYPIAjDttcu8eqDuqHw=; b=HanzoDK73+QmgSFMXZM8g8hrmKZg+A0IM+z/eojJATt5qM2JfZ+HUDsDIT/iTekIIO Lz9r5vEHSDiDs0CCXWydJAUTSpYqXY7LS9m4KMj33YXlgigv6FTxJDQD48vfqGJw8CwQ NkwmvBSo6P7oQCnHR9X66z1mEwpc2809d5GAZkIeoe2EKz178g/IyxrVMZaoeZmRnyYS XxSdwRyAEfUThD42Jlvpluzd8WzAjd0wMFMgumgEGw3ToMpDuukzgmgMqxKKm/sQsL50 nlPj214/B/ThcshFCFlFGTXWPsrETTF6Z2Q9YvLtEbyTo8wOLFgjUKlse1fabD/miLm+ GfRg== X-Gm-Message-State: AOAM53157v58mcCkPdgfQ7R/NtJrWZ6bR8sryviRKQVq9n/kKrKqHlMn WmTaFhCaZhIimfd8QGXamMkjDzWgT7bZBHaSO8QLWZLF8tc= X-Google-Smtp-Source: ABdhPJxpXwaWDcnr4tFQTowg4eubwGq78cvGqbkIBCU3cHb13x/YuJAwKrjRQRgoOfnPDG+mubVnDG9TvfBsBK3eEwM= X-Received: by 2002:a05:6830:1db1:: with SMTP id z17mr1518320oti.170.1598005517242; Fri, 21 Aug 2020 03:25:17 -0700 (PDT) MIME-Version: 1.0 References: <6d88bd5659b854d9af73cb9a325c719c3d7d9da9.camel@freebsd.org> In-Reply-To: <6d88bd5659b854d9af73cb9a325c719c3d7d9da9.camel@freebsd.org> From: Johnny Sorocil Date: Fri, 21 Aug 2020 12:24:17 +0200 Message-ID: Subject: Re: Disabling internal RTC ends up in hang To: Ian Lepore Cc: freebsd-arm@freebsd.org X-Rspamd-Queue-Id: 4BXyML2yPrz3VF2 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=WBVXSWHw; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of jsorocil@gmail.com designates 2607:f8b0:4864:20::341 as permitted sender) smtp.mailfrom=jsorocil@gmail.com X-Spamd-Result: default: False [-1.84 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; NEURAL_HAM_MEDIUM(-0.90)[-0.902]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; NEURAL_SPAM_SHORT(0.07)[0.066]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::341:from]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arm]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2020 10:25:19 -0000 On Wed, Aug 19, 2020 at 7:55 PM Ian Lepore wrote: > I think you may be running into a problem Andriy (avg@) described on > irc the other day: the allwinner RTC hardware has no way to detect > whether it lost power, so it always supplies the time, even if it's > incorrect. When there are multiple RTCs in the system, the kernel asks > them in the order they registered until one provides the time. > > I suspect the panic is happening because the internal RTC also provides > the system 32khz clock, which is needed by other devices. > > He cooked up this patch: http://paste.ubuntu.com/p/6hhtQbJC85/ > > With that patch in place, the 32khz clock would be available, but the > RTC would not supply the time unless it was correct. > Attempt #1: Booting GENERIC kernel and loading patched "aw_rtc.ko" - already present in kernel - system date not correct Attempt #2: Booting custom kernel with option "nodevice aw_rtc" and loading patched "aw_rtc.ko" - same panic & hang as in previous message Attempt #3: Booting GENERIC kernel which has builtin patched "aw_rtc": mmc0: No compatible cards found on bus aw_mmc1: Spurious interrupt - no active request, rint: 0x00000004 mmc1: on aw_mmc0 Cannot set frequency for clk: mmc0, error: 34 aw_mmc0: failed to set frequency to 50000000 Hz: 34 uhub2: 1 port with 1 removable, self powered uhub0: 1 port with 1 removable, self powered ugen2.2: at usbus2 mountroot: waiting for device /dev/ufs/rootfs... Mounting from ufs:/dev/ufs/rootfs failed with error 19. Loader variables: vfs.root.mountfrom=ufs:/dev/ufs/rootfs vfs.root.mountfrom.options=rw Manual root filesystem specification: : [options] Mount using filesystem and with the specified (optional) option list. eg. ufs:/dev/da0s1a zfs:zroot/ROOT/default cd9660:/dev/cd0 ro (which is equivalent to: mount -t cd9660 -o ro /dev/cd0 /) ? List valid disk boot devices . Yield 1 second (for background tasks) Abort manual input mountroot> aw_mmc0: controller timeout aw_mmc0: timeout resetting DMA/FIFO aw_mmc0: timeout updating clock aw_mmc0: controller timeout aw_mmc0: timeout resetting DMA/FIFO aw_mmc0: timeout updating clock aw_mmc0: controller timeout aw_mmc0: timeout resetting DMA/FIFO From owner-freebsd-arm@freebsd.org Fri Aug 21 14:58:16 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id A9FD43BF6D9 for ; Fri, 21 Aug 2020 14:58:16 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mx.blih.net (mx.blih.net [212.83.155.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mx.blih.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BY4QG6jsXz42Fl; Fri, 21 Aug 2020 14:58:14 +0000 (UTC) (envelope-from manu@bidouilliste.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bidouilliste.com; s=mx; t=1598021886; 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=9Df5fM42n2Qn9mEwGO5gkqNn/fPPfP31xkuoMvgqu+I=; b=W4cSrVooclXEf/fHiADSswTw+NI6wnWWZgkNybMhFUUiWW9qebx7sNKkWMfzKdOLugnBu2 jUigd+QrkmzX2q8kSEAj0cmCsF0AusJgoXjuNkxXk+GN4sEzIDd+6FOUcWlAAboSMc5zVw S/N+aj9ARsO9oEwJCLB/H2VLywVXlek= Received: from skull.home.blih.net (lfbn-idf2-1-1138-237.w90-92.abo.wanadoo.fr [90.92.20.237]) by mx.blih.net (OpenSMTPD) with ESMTPSA id 10c5ae4a (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Fri, 21 Aug 2020 14:58:06 +0000 (UTC) Date: Fri, 21 Aug 2020 16:58:05 +0200 From: Emmanuel Vadot To: Johnny Sorocil Cc: Ian Lepore , freebsd-arm@freebsd.org Subject: Re: Disabling internal RTC ends up in hang Message-Id: <20200821165805.f36090fee5afac8a3ad1d570@bidouilliste.com> In-Reply-To: References: <6d88bd5659b854d9af73cb9a325c719c3d7d9da9.camel@freebsd.org> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; amd64-portbld-freebsd13.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4BY4QG6jsXz42Fl X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bidouilliste.com header.s=mx header.b=W4cSrVoo; 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.67 / 15.00]; RCVD_TLS_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[bidouilliste.com:s=mx]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; FREEFALL_USER(0.00)[manu]; ARC_NA(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bidouilliste.com:+]; DMARC_POLICY_ALLOW(-0.50)[bidouilliste.com,none]; NEURAL_HAM_SHORT(-0.22)[-0.224]; NEURAL_HAM_MEDIUM(-0.95)[-0.950]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:12876, ipnet:212.83.128.0/19, country:FR]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arm] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2020 14:58:16 -0000 On Fri, 21 Aug 2020 12:24:17 +0200 Johnny Sorocil wrote: > On Wed, Aug 19, 2020 at 7:55 PM Ian Lepore wrote: > > > I think you may be running into a problem Andriy (avg@) described on > > irc the other day: the allwinner RTC hardware has no way to detect > > whether it lost power, so it always supplies the time, even if it's > > incorrect. When there are multiple RTCs in the system, the kernel asks > > them in the order they registered until one provides the time. > > > > I suspect the panic is happening because the internal RTC also provides > > the system 32khz clock, which is needed by other devices. > > > > He cooked up this patch: http://paste.ubuntu.com/p/6hhtQbJC85/ > > > > With that patch in place, the 32khz clock would be available, but the > > RTC would not supply the time unless it was correct. > > > > Attempt #1: > Booting GENERIC kernel and loading patched "aw_rtc.ko" > - already present in kernel > - system date not correct > > Attempt #2: > Booting custom kernel with option "nodevice aw_rtc" and loading patched > "aw_rtc.ko" > - same panic & hang as in previous message Both #1 and #2 are expected, aw_rtc is present in GENERIC and needs to be for the 32khz clock to be created. > Attempt #3: > Booting GENERIC kernel which has builtin patched "aw_rtc": > > mmc0: No compatible cards found on bus > aw_mmc1: Spurious interrupt - no active request, rint: 0x00000004 > > mmc1: on aw_mmc0 > Cannot set frequency for clk: mmc0, error: 34 > aw_mmc0: failed to set frequency to 50000000 Hz: 34 > uhub2: 1 port with 1 removable, self powered > uhub0: 1 port with 1 removable, self powered > ugen2.2: at usbus2 > mountroot: waiting for device /dev/ufs/rootfs... > Mounting from ufs:/dev/ufs/rootfs failed with error 19. > > Loader variables: > vfs.root.mountfrom=ufs:/dev/ufs/rootfs > vfs.root.mountfrom.options=rw > > Manual root filesystem specification: > : [options] > Mount using filesystem > and with the specified (optional) option list. > > eg. ufs:/dev/da0s1a > zfs:zroot/ROOT/default > cd9660:/dev/cd0 ro > (which is equivalent to: mount -t cd9660 -o ro /dev/cd0 /) > > ? List valid disk boot devices > . Yield 1 second (for background tasks) > Abort manual input > > mountroot> aw_mmc0: controller timeout > aw_mmc0: timeout resetting DMA/FIFO > aw_mmc0: timeout updating clock > aw_mmc0: controller timeout > aw_mmc0: timeout resetting DMA/FIFO > aw_mmc0: timeout updating clock > aw_mmc0: controller timeout > aw_mmc0: timeout resetting DMA/FIFO That doesn't seems related at all, do you have any other modification ? > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" -- Emmanuel Vadot From owner-freebsd-arm@freebsd.org Fri Aug 21 18:52:31 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 55CD83C5CCD for ; Fri, 21 Aug 2020 18:52:31 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic303-25.consmr.mail.gq1.yahoo.com (sonic303-25.consmr.mail.gq1.yahoo.com [98.137.64.206]) (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 4BY9cZ4HXqz4M4n for ; Fri, 21 Aug 2020 18:52:30 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: m2NweIUVM1l3iplc_QmD7rNw5kH72tPWpCG.DqIQ_IRcfNKuj4y2WQmEQZDfF3G 84fZ1DlzCHGWrU6oe5u21My2pI4gSQvNEWiPfmmqQfQgOiBJ.dtVNHVAS7kWcJ0G2OG8Ntbihb7o mAUi8xDlZDio2uqO7uoEiE7Uc99QmSb.__Uyzwd_T1PmQo89LTZ_L7NeUwT2OQsL8b2xbC25mxw9 f11bZ42YxFm0JmmJiz5Tj8iLnZOrwrDFvVWqct9S6XQArBEswsLrXK87VZanafQYIOXad0Us0hHr zH7527M1PqC1jRbf6rZGtLOP0qlQkzRz1PoVzhNObizieQRM1YQjRraUo6v8o42h34WAImJVHseE W.W2Z4ZVhy0WsHvJr3Zx02fSxtaVvmvPqZiRTBExjR.AhH8JJPjn4L68mBx0Rfybf9OxJ9wPrQkY vYpqyhETvi5IozptupVXl6eHyoC5sCHyxs_bPKjRhc9FTxmKBt92HgzqwlFR7hzDDyRMh_T7KFkO kzzV8oyPnAGXioNRRGsaHE_p4MxOW5GcgFWuKDcATMW3gEo4fNxBWgRQTXeCOvvPyBe6lmBFGUiJ re7_GPBWG5PqkSjqPwBVMJCWZmvka5ySu2B5_8AHDAsYxp1IXogH.562a.L2Gxa4VIr0cOqG2xLr Cf.8IzBP1ZJl1Dm6fPYrdLfbWbLgQahkHhJ2yZv4H3XeRAO1FpzZQkGXpn11y_ezwhqlL1YLG0eL uiKnTq0ORwWAO4qWJvYOKO7DO3Az838JStd3RoOmssTNL9Zq40JegMIRY1emmB6SiHoSywWunhcZ QsUNisajJe6TA_yHiyOKqQIb4nUTH.YjALPEOo9LjQV58VCnD6xPjNIsbbLYyOfB8Qpm5FhDWjRI ABySX6hWy9acwcvwF6vV2E.9JrPM5Sf9hnuU1w5s70RRP3KTdVWlQkmfxIdMiW_eOeflxRlm3AVS kJp6I_pNn6zu1bRbQVjzAdJYkZDi4D7NYQVIP_2dQOR9yq5gy7VAmiIZT9xz55Gbrs6BgzpXTJ1t AZ63WiqqCkBQqJyL7FKC2rNBoMaqjlwHwcyHzMBc49phvpFMSIhfbw2HajcoplCwJEx.oYzcb.0S UlChLO_vR4NBB00lnabFQDTVc6h9S6GdzAWz0Cm3xnUfPpzDPr6dmT.FLb9EIxPAbTkSnO8RtpKP uAdo0t9Bf0bytxiFF8jKYyQAQEueaZHK_e9dFxPFScS5TeeGO_a.o4SkYZCq8tegQqdnDECuBh_j 2yBK.kQnt_zEjhmm4Fa83EWJFdvnJDuEAeCUSsJbxA91iLULhQ48lwKG5XCXecIMFa7XTel1WaJ0 7go01cHLZjBieulKlzOH2IhxvaSF6uOsOKShsH3bmvzzeJ1wLmrpflY0yc78Gp4X_OWTLe09WEPr Pf1sIkMEmwjYJXFck1UvKG9prrwbpp7ENb2nET8GiYI9yLu8wj7rL9js_0loZYJ8KixxCfkxQ1EY JnmzgqjqxcERWYC_FFznoKyfB9PSL.JNdyTzT9a.n_umoi7oWjtys7BVV7tl2hbrmJ2Ad_UNy4At u1g-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.gq1.yahoo.com with HTTP; Fri, 21 Aug 2020 18:52:29 +0000 Received: by smtp405.mail.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 041dde3f83bda0f19f2ce808289ca7c9; Fri, 21 Aug 2020 18:52:24 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Subject: /usr/lib/libomp.so : is there a reason that aarch64 does not have such by default? Message-Id: <2E4E8340-E4C1-4ED4-9E3D-F249D85D10FF@yahoo.com> Date: Fri, 21 Aug 2020 11:52:23 -0700 Cc: freebsd-arm To: FreeBSD Current , FreeBSD Toolchain X-Mailer: Apple Mail (2.3608.120.23.2.1) References: <2E4E8340-E4C1-4ED4-9E3D-F249D85D10FF.ref@yahoo.com> X-Rspamd-Queue-Id: 4BY9cZ4HXqz4M4n X-Spamd-Bar: - X-Spamd-Result: default: False [-1.89 / 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(-0.41)[-0.407]; 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]; SUBJECT_ENDS_QUESTION(1.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-0.98)[-0.975]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.01)[-1.012]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.206:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.206:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arm] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2020 18:52:31 -0000 My context: head ( currently at -r363590 ) man src.conf is explicit that WITHOUT_OPENMP is the default for aarch64 (for example). But I note that https://openmp.llvm.org/README.txt says: (it has the more detailed breakdown of OS/compiler combinations for architectures where it matters) QUOTE Architectures Supported ======================= * IA-32 architecture * Intel(R) 64 architecture * Intel(R) Many Integrated Core Architecture * ARM* architecture * Aarch64 (64-bit ARM) architecture * IBM(R) Power architecture (big endian) * IBM(R) Power architecture (little endian) * MIPS and MIPS64 architectures * RISC-V 64 bit architecture Supported RTL Build Configurations ================================== Supported Architectures: IA-32 architecture, Intel(R) 64, and Intel(R) Many Integrated Core Architecture ---------------------------------------------- | icc/icl | gcc | clang | --------------|---------------|----------------------------| | Linux* OS | Yes(1,5) | Yes(2,4) | Yes(4,6,7) | | FreeBSD* | No | No | Yes(4,6,7,8) | | OS X* | Yes(1,3,4) | No | Yes(4,6,7) | | Windows* OS | Yes(1,4) | No | No | ------------------------------------------------------------ . . . (7) Clang* currently does not offer a software-implemented 128 bit extended precision type. Thus, all entry points reliant on this type are removed from the library and cannot be called in the user program. The following functions are not available: __kmpc_atomic_cmplx16_* __kmpc_atomic_float16_* __kmpc_atomic_*_fp . . . Supported Architectures: IBM(R) Power 7 and Power 8 ----------------------------- | gcc | clang | --------------|------------|--------------| | Linux* OS | Yes(1,2) | Yes(3,4) | ------------------------------------------- . . . ENDQUOTE Nothing stands out for why WITH_OPENMP is in use by default only for amd64, i386, and powerpc64. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Fri Aug 21 20:59:38 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 549DA3C8CED for ; Fri, 21 Aug 2020 20:59:38 +0000 (UTC) (envelope-from mishin@mh.net.ru) Received: from frog.mh.net.ru (mh.balakovo.san.ru [88.147.158.22]) (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 4BYDRD5vywz4T7r for ; Fri, 21 Aug 2020 20:59:35 +0000 (UTC) (envelope-from mishin@mh.net.ru) Received: from webmail.mh.net.ru (mouse.home [192.168.5.6]) by frog.mh.net.ru (Postfix) with ESMTPSA id CF509AD679 for ; Sat, 22 Aug 2020 00:59:25 +0400 (+04) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Sat, 22 Aug 2020 00:59:25 +0400 From: Alexander Mishin To: freebsd-arm@freebsd.org Subject: Re: Kmod driver at iicbus. attach() and config_intrhook(9) In-Reply-To: References: <7fabb65d99aaa74775c1daa91bffb873@mh.net.ru> <3249fa7e-554a-83ef-57b2-7c38aa0b4591@FreeBSD.org> <20200819072409.GA59949@bluezbox.com> <05145b71692af74b103bb226a2e93a15e1e851cb.camel@freebsd.org> <20200820223918.GC4213@funkthat.com> User-Agent: Roundcube Webmail/1.4.2 Message-ID: <496ed13afb2327d6416664b4dacfc346@mh.net.ru> X-Sender: mishin@mh.net.ru X-Rspamd-Queue-Id: 4BYDRD5vywz4T7r X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=mh.net.ru (policy=none); spf=fail (mx1.freebsd.org: domain of mishin@mh.net.ru does not designate 88.147.158.22 as permitted sender) smtp.mailfrom=mishin@mh.net.ru X-Spamd-Result: default: False [1.00 / 15.00]; RCVD_TLS_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_FAIL(1.00)[-all]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; ARC_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:12389, ipnet:88.147.128.0/17, country:RU]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arm]; DMARC_POLICY_SOFTFAIL(0.10)[mh.net.ru : No valid SPF, No valid DKIM,none] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2020 20:59:38 -0000 Ian Lepore пиÑал 2020-08-21 02:51: > On Thu, 2020-08-20 at 15:39 -0700, John-Mark Gurney wrote: >> Alexander Mishin wrote this message on Thu, Aug 20, 2020 at 10:07 >> +0400: >> > Ian Lepore ?????????? 2020-08-19 19:39: >> > > On Wed, 2020-08-19 at 00:24 -0700, Oleksandr Tymoshenko wrote: >> > > > Andriy Gapon (avg@FreeBSD.org) wrote: >> > > > > On 18/08/2020 22:05, Alexander Mishin wrote: >> > > > > > Hi >> > > > > > ... >> > > > > > But I see that some other devices (from /usr/src/sys/dev) >> > > > > > uses >> > > > > > CONFIG_INTRHOOK(9) >> > > > > > on attach() for initialize themselfs. >> > > > > > I wonder if I need this too? ... >> > > > > >> > > > > This is usually needed when a driver needs to talk to its >> > > > > device >> > > > > while >> > > > > attaching. E.g., to set some initial configuration or to >> > > > > confirm >> > > > > device's >> > > > > identity, etc. >> > > > >> > > > To extend Andriy's explanation a bit: all these operations may >> > > > perform >> > > > I2C transfers and most I2C controllers use interrupts to get >> > > > notified >> > > > about tranfer status change (finished, error, etc...). There is >> > > > no >> > > > guarantee that when driver's attach method is called interrupts >> > > > are >> > > > globally enabled. What would happen in this case is: I2C >> > > > controller >> > > > is going to initiate I2C operation and wait for an interrupt >> > > > that's >> > > > never going to be delivered. CONFIG_INTRHOOK is a solution for >> > > > this >> > > > problem, if your attach method requires interrupts - just split >> > > > it >> > > > in two parts and postpone running interrupt-dependent part >> > > > until >> > > > after >> > > > interrupts are globally enabled. >> > > > >> > > >> > > A note about all this: It should never be necessary for an i2c >> > > slave >> > > device driver to do this. The reason it's needed is because many >> > > i2c >> > > controller drivers attach the iicbus from their attach() routine >> > > even >> > > though they can't actually do i2c IO until interrupts are >> > > available. >> > > It is these controller drivers that should have the intrhook >> > > logic to >> > > not call bus_generic_attach() until interrupts are available if >> > > they >> > > can't do IO until interrupts are available. >> > > >> > > It has long been my goal to fix all our i2c controller drivers to >> > > behave correctly, so that i2c slave device drivers don't all need >> > > the >> > > intrhook logic. But somehow I never get around to it. >> > >> > I think, it would be helpful, as it would be possible to return an >> > error >> > on early stage, from attach(), if there is no connection with the >> > configured device. >> >> Looks like there's a function bus_delayed_attach_children designed >> exactly for this: >> * Many buses can't run transactions on the bus which children need >> to probe and >> * attach until after interrupts and/or timers are running. This >> function >> * delays their attach until interrupts and timers are enabled. >> >> and it looks like a couple controllers are already using it, imx_i2c >> and ti_i2c... >> >> It looks like maybe a simple replace of bus_generic_attach w/ >> bus_delayed_attach_children should be enough on those w/ >> interrupts... >> >> Is there any argument for doing it for ALL controllers instead of >> just >> some? >> >> Poking around some, and it looks like some (one) drivers "pretend" to >> use interrupts, but just busy wait instead, e.g. exynos5... >> > > Hmm, yeah, it looks like more has been done along these lines than I > remembered. In fact, the work may be done. > > Some i2c controllers have to work properly before interrupts are > available, to control things like PMIC chips that are required very > early in device configuration. Typically they have some sort of > polling mechanism that's used early, and revert to using interrupts > once they're available. The allwinner and rockchip drivers work that > way. > > -- Ian Just to dot the i's, my SoC is allwinner (Orange PI PC). And the issue at boot time really showed itself up until config_intrhook was used. FreeBSD myhost.mh.net.ru 13.0-CURRENT FreeBSD 13.0-CURRENT #3 r364004 From owner-freebsd-arm@freebsd.org Sat Aug 22 09:08:05 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 2A76E3B350B; Sat, 22 Aug 2020 09:08:05 +0000 (UTC) (envelope-from greg@unrelenting.technology) Received: from out1.migadu.com (out1.migadu.com [IPv6:2001:41d0:2:863f::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4BYXbl5Kphz4MZK; Sat, 22 Aug 2020 09:08:03 +0000 (UTC) (envelope-from greg@unrelenting.technology) Date: Sat, 22 Aug 2020 09:07:55 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=unrelenting.technology; s=default; t=1598087275; 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=mqPwZmjSASNp9BN2RtRE47tg20eHCkWN6l59h3ueu9U=; b=EmH2pao9yyfBZCFT72rHH1sA7mSuxj2ruR/Na/3gEfpcIFJeipCzPpU+jcH+E7ZcK5Pdr+ yFpfrcWMtH+r53mFAyvwp8o20Eni4xiw2kzzCWpTtHW2zguk5kABkIJc5tja8lfnYwMMkR OMJFMxoYNo5/gDgPd2GccET8DBchrDo= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: myfreeweb To: Mark Millard , FreeBSD Current , FreeBSD Toolchain CC: freebsd-arm Subject: Re: /usr/lib/libomp.so : is there a reason that aarch64 does not have such by default? In-Reply-To: <2E4E8340-E4C1-4ED4-9E3D-F249D85D10FF@yahoo.com> References: <2E4E8340-E4C1-4ED4-9E3D-F249D85D10FF.ref@yahoo.com> <2E4E8340-E4C1-4ED4-9E3D-F249D85D10FF@yahoo.com> Message-ID: <90091F80-717F-4405-952B-B6B955AE6E1F@unrelenting.technology> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.90 X-Rspamd-Queue-Id: 4BYXbl5Kphz4MZK X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=unrelenting.technology header.s=default header.b=EmH2pao9; dmarc=pass (policy=none) header.from=unrelenting.technology; spf=pass (mx1.freebsd.org: domain of greg@unrelenting.technology designates 2001:41d0:2:863f:: as permitted sender) smtp.mailfrom=greg@unrelenting.technology X-Spamd-Result: default: False [-0.48 / 15.00]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[unrelenting.technology:s=default]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; R_SPF_ALLOW(-0.20)[+ip6:2001:41d0:2:863f::]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[unrelenting.technology:+]; DMARC_POLICY_ALLOW(-0.50)[unrelenting.technology,none]; NEURAL_HAM_SHORT(-0.48)[-0.480]; FREEMAIL_TO(0.00)[yahoo.com,freebsd.org]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:16276, ipnet:2001:41d0::/32, country:FR]; MID_RHS_MATCH_FROM(0.00)[]; MAILMAN_DEST(0.00)[freebsd-arm,freebsd-current,freebsd-toolchain] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Aug 2020 09:08:05 -0000 On August 21, 2020 6:52:23 PM UTC, Mark Millard via freebsd-arm wrote: >My context: head ( currently at -r363590 ) > >man src=2Econf is explicit that WITHOUT_OPENMP is the default for >aarch64 (for example)=2E [=2E=2E=2E] >Nothing stands out for why WITH_OPENMP is in use by default only >for amd64, i386, and powerpc64=2E Because nobody has bothered to merge https://reviews=2Efreebsd=2Eorg/D2116= 7 From owner-freebsd-arm@freebsd.org Sat Aug 22 13:19:59 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 7D88A3BA65F for ; Sat, 22 Aug 2020 13:19:59 +0000 (UTC) (envelope-from peo@nethead.se) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 4BYfBR220dz4bnG for ; Sat, 22 Aug 2020 13:19:59 +0000 (UTC) (envelope-from peo@nethead.se) Received: by mailman.nyi.freebsd.org (Postfix) id 457E13BA92B; Sat, 22 Aug 2020 13:19:59 +0000 (UTC) Delivered-To: arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 4544C3BA65E for ; Sat, 22 Aug 2020 13:19:59 +0000 (UTC) (envelope-from peo@nethead.se) Received: from ns1.nethead.se (ns1.nethead.se [5.150.237.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ns1.nethead.se", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BYfBQ209kz4bbk for ; Sat, 22 Aug 2020 13:19:57 +0000 (UTC) (envelope-from peo@nethead.se) X-Virus-Scanned: amavisd-new at Nethead AB DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nethead.se; s=NETHEADSE; t=1598102390; bh=knCUsUxWgjtp+I3QufVmY4yLZ8gpiHkAE6mTNpweKBY=; h=To:From:Subject:Date; b=YZcvprhBsuhbTzyDh6oLRIs5vqgLn+uj10wWEXoaCTepyPLjxyPw9uQdKNmL0ged1 yGfwRXAVBgPInO1WS6twAhL02+bQsrmkSYsCy+aJHE39L0qIHOOYuh6cNFYOrlghhy eav8IYhD+5hgay5K1SRKOWkX+b6ENVSZC20nSB40= To: "freebsd-arm@freebsd.org" From: Per olof Ljungmark Subject: rpi serial port and GPS hat Message-ID: Date: Sat, 22 Aug 2020 15:19:48 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4BYfBQ209kz4bbk X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=nethead.se header.s=NETHEADSE header.b=YZcvprhB; dmarc=pass (policy=none) header.from=nethead.se; spf=pass (mx1.freebsd.org: domain of peo@nethead.se designates 5.150.237.139 as permitted sender) smtp.mailfrom=peo@nethead.se X-Spamd-Result: default: False [-1.46 / 15.00]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[nethead.se:s=NETHEADSE]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:5.150.237.139]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_ONE(0.00)[1]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[nethead.se:+]; DMARC_POLICY_ALLOW(-0.50)[nethead.se,none]; NEURAL_HAM_SHORT(-0.46)[-0.459]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:8473, ipnet:5.150.192.0/18, country:SE]; MID_RHS_MATCH_FROM(0.00)[]; MAILMAN_DEST(0.00)[arm] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Aug 2020 13:19:59 -0000 A couple of years ago with the help of this list I built a NTP server based on a RPI3B and 12-current and an Adafruit GPS hat. Now the SD card in the Pi decided it was time to give up so I thought I'd just replace it and rebuild it based on my notes from that time. So far I have accomplished, Build an image with a PPS kernel and the pps-gpio.dtbo Silence the serial console so that the Pi boots with the hat on What remains is to have the NMEA sequences to show up on uart0, currently they are at uart1 as I would like to try gpsd as well. Assuming I need to recompile a .dtb file, which one should I look into? The board is marked "Pi 3 Model B v1.2" Any help appriciated, especially if someone could post the patch needed as my notes are insufficient. Thanks, Per From owner-freebsd-arm@freebsd.org Sat Aug 22 14:02:21 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 71A863BC12B for ; Sat, 22 Aug 2020 14:02:21 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 4BYg7K0Vjzz4fZS for ; Sat, 22 Aug 2020 14:02:21 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: by mailman.nyi.freebsd.org (Postfix) id 112DA3BC129; Sat, 22 Aug 2020 14:02:21 +0000 (UTC) Delivered-To: arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 10F633BBDE9 for ; Sat, 22 Aug 2020 14:02:21 +0000 (UTC) (envelope-from ronald-lists@klop.ws) 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 4BYg7H41JSz4fVs for ; Sat, 22 Aug 2020 14:02:19 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Date: Sat, 22 Aug 2020 16:02:15 +0200 (CEST) From: Ronald Klop To: "freebsd-arm@freebsd.org" , Per olof Ljungmark Message-ID: <71719672.12579.1598104935440@localhost> In-Reply-To: Subject: Re: rpi serial port and GPS hat MIME-Version: 1.0 X-Mailer: Realworks (520.19.94cd10459f2) Importance: Normal X-Priority: 3 (Normal) X-Rspamd-Queue-Id: 4BYg7H41JSz4fVs X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of ronald-lists@klop.ws designates 194.109.157.24 as permitted sender) smtp.mailfrom=ronald-lists@klop.ws X-Spamd-Result: default: False [-0.25 / 15.00]; ARC_NA(0.00)[]; RWL_MAILSPIKE_VERYGOOD(0.00)[194.109.157.24:from]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:194.109.157.0/24]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; DMARC_NA(0.00)[klop.ws]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.45)[-0.454]; RCPT_COUNT_TWO(0.00)[2]; HAS_X_PRIO_THREE(0.00)[3]; RCVD_IN_DNSWL_NONE(0.00)[194.109.157.24:from]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:3265, ipnet:194.109.0.0/16, country:NL]; MID_RHS_NOT_FQDN(0.50)[]; MAILMAN_DEST(0.00)[arm] Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Aug 2020 14:02:21 -0000 An addition to the notes. - Make a backup. =F0=9F=98=89=F0=9F=98=80 Regards, Ronald. Van: Per olof Ljungmark Datum: 22 augustus 2020 15:20 Aan: "freebsd-arm@freebsd.org" Onderwerp: rpi serial port and GPS hat >=20 >=20 > A couple of years ago with the help of this list I built a NTP server bas= ed on a RPI3B and 12-current and an Adafruit GPS hat. >=20 > Now the SD card in the Pi decided it was time to give up so I thought I'd= just replace it and rebuild it based on my notes from that time. >=20 > So far I have accomplished, >=20 > Build an image with a PPS kernel and the pps-gpio.dtbo > Silence the serial console so that the Pi boots with the hat on >=20 > What remains is to have the NMEA sequences to show up on uart0, currently= they are at uart1 as I would like to try gpsd as well. >=20 > Assuming I need to recompile a .dtb file, which one should I look into? T= he board is marked "Pi 3 Model B v1.2" >=20 > Any help appriciated, especially if someone could post the patch needed a= s my notes are insufficient. >=20 > Thanks, >=20 > Per >=20 > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" >=20 >=20 >=20 >=20 From owner-freebsd-arm@freebsd.org Sat Aug 22 16:38:24 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 3E0C23C00FC for ; Sat, 22 Aug 2020 16:38:24 +0000 (UTC) (envelope-from jsorocil@gmail.com) Received: from mail-oi1-x241.google.com (mail-oi1-x241.google.com [IPv6:2607:f8b0:4864:20::241]) (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 4BYkbM42Msz4q3h; Sat, 22 Aug 2020 16:38:23 +0000 (UTC) (envelope-from jsorocil@gmail.com) Received: by mail-oi1-x241.google.com with SMTP id b9so923004oiy.3; Sat, 22 Aug 2020 09:38:23 -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=MoakF5Dt4Tz9BHbYHRI33n6IRRgyvahtKpZ1E3hcQAc=; b=jD6bwr4/u/1eJh/wYZeWnwDgfy3Zb79cZZNtuzed+FLSMn4cbNZ/NWK4VQnr9gM/Fq FEe4F61Bsz0VXcYpBWzR5NoUrDDQqhoB0lJpRSFrW+TMeB0imQUI8fj7mYaAtd1n6LHo 5YzT3GCThSfZNGX7RD5MiFh+u9M2I1O1c6znLVQGNCEZfTh9crp0PQxLzYGeAXU2G6SL kF31RZ4JdjNcopI5FiqtWjD0pUDE3SCSwn+9euYlUnukUJbLojKVncoeDbAw9h4wDPgj nP5JoKkfMxSgTq2QtdKQUL/p7QvRAhagUNtKCrc/RhYy0ofpXtI5PR7XcvAmnmK0R9VO gpyQ== 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=MoakF5Dt4Tz9BHbYHRI33n6IRRgyvahtKpZ1E3hcQAc=; b=bKLrPwU+SpEdsfZDPyGL3Gd5XtHtLNNjoLi/XQoX31FR6VPsKBnOf+2o2/eyW8kp1A YeomTFFxHf+qfZCPisMJHr6rCcLR7lNIlDxsshcdbZ2FALMdsBt4WY2oH7f0myyoIIcf j/fD3YPEKIrlrAnIDCZHJN3UQRza1UkAlJtfCdmwO2tCVKbu3O2S1UkNLiLnGuCvsi+n HgbuWS4dEYmAoGE5bL323ZS2x1vVvJA8DUtFu5WyX4eqXWWEjXgDAZilDa4RMH83sO+L 4yoewQFoz/uLyIGQs7gffMF7b8/t1Wx3sUC6TtgjdkLO/u90k2Yq5/zlL0/ZB3IDAyCW NLJw== X-Gm-Message-State: AOAM5311zCDgugX9mv/QiGXFG+XLJfr1DCRyONwmaHWKmZzXF/wR4y/x yHxfpYOYGBYqYN9IzGSmII1+pXTUuQw/MqWaO+bJw0q08Rg= X-Google-Smtp-Source: ABdhPJw4hOkA7jKu7pd9QWDfCtwbInNSIwX9FGO1f0Aafy0RBvD7El7TPIUeuotY+gP/sEMYTxplkpdP45ZxZpT/EXg= X-Received: by 2002:aca:4088:: with SMTP id n130mr5197706oia.65.1598114302465; Sat, 22 Aug 2020 09:38:22 -0700 (PDT) MIME-Version: 1.0 References: <6d88bd5659b854d9af73cb9a325c719c3d7d9da9.camel@freebsd.org> <20200821165805.f36090fee5afac8a3ad1d570@bidouilliste.com> In-Reply-To: <20200821165805.f36090fee5afac8a3ad1d570@bidouilliste.com> From: Johnny Sorocil Date: Sat, 22 Aug 2020 18:37:19 +0200 Message-ID: Subject: Re: Disabling internal RTC ends up in hang To: Emmanuel Vadot Cc: Ian Lepore , freebsd-arm@freebsd.org X-Rspamd-Queue-Id: 4BYkbM42Msz4q3h X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=jD6bwr4/; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of jsorocil@gmail.com designates 2607:f8b0:4864:20::241 as permitted sender) smtp.mailfrom=jsorocil@gmail.com X-Spamd-Result: default: False [-1.23 / 15.00]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MIME_BASE64_TEXT(0.10)[]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::241:from]; NEURAL_HAM_SHORT(-0.33)[-0.327]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arm]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Aug 2020 16:38:24 -0000 On Fri, Aug 21, 2020 at 4:58 PM Emmanuel Vadot wrote: > On Fri, 21 Aug 2020 12:24:17 +0200 > Johnny Sorocil wrote: > > > Attempt #3: > > Booting GENERIC kernel which has builtin patched "aw_rtc": > > > > mmc0: No compatible cards found on bus > > aw_mmc1: Spurious interrupt - no active request, rint: 0x00000004 > > > > mmc1: on aw_mmc0 > > Cannot set frequency for clk: mmc0, error: 34 > > aw_mmc0: failed to set frequency to 50000000 Hz: 34 > > uhub2: 1 port with 1 removable, self powered > > uhub0: 1 port with 1 removable, self powered > > ugen2.2: at usbus2 > > mountroot: waiting for device /dev/ufs/rootfs... > > Mounting from ufs:/dev/ufs/rootfs failed with error 19. > > > > Loader variables: > > vfs.root.mountfrom=ufs:/dev/ufs/rootfs > > vfs.root.mountfrom.options=rw > > > > Manual root filesystem specification: > > : [options] > > Mount using filesystem > > and with the specified (optional) option list. > > > > eg. ufs:/dev/da0s1a > > zfs:zroot/ROOT/default > > cd9660:/dev/cd0 ro > > (which is equivalent to: mount -t cd9660 -o ro /dev/cd0 /) > > > > ? List valid disk boot devices > > . Yield 1 second (for background tasks) > > Abort manual input > > > > mountroot> aw_mmc0: controller timeout > > aw_mmc0: timeout resetting DMA/FIFO > > aw_mmc0: timeout updating clock > > aw_mmc0: controller timeout > > aw_mmc0: timeout resetting DMA/FIFO > > aw_mmc0: timeout updating clock > > aw_mmc0: controller timeout > > aw_mmc0: timeout resetting DMA/FIFO > > That doesn't seems related at all, do you have any other modification ? > No, only that patch applied against -CURRENT (git commit 13a3f44675f633f7d8ca5bd736b1ce0e50e7771a from Aug 19). Cross compiled kernel and world again on my amd64 board, installed it on microSD card, put it in OrangePi, booted it and the result is same: FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 13.0-CURRENT #3 13a3f44675f-c270720(master)-dirty: Sat Aug 22 11:20:09 CEST 2020 johnny@innovator:/usr/obj/user/build-13.0/usr/src/current/arm.armv7/sys/GENERIC arm FreeBSD clang version 11.0.0 (git@github.com:llvm/llvm-project.git llvmorg-11.0.0-rc1-47-gff47911ddfc) WARNING: WITNESS option enabled, expect reduced performance. VT: init without driver. CPU: ARM Cortex-A7 r0p5 (ECO: 0x00000000) ... Mounting from ufs:/dev/ufs/rootfs failed with error 19. ... But after waiting a few seconds, mmcsd0 device appears but system can not mount rootfs from it: aw_mmc0: timeout resetting DMA/FIFO List of GEOM managed disk devices: mountroot> aw_mmc0: timeout updating clock aw_mmc0: controller timeout aw_mmc0: timeout resetting DMA/FIFO aw_mmc0: timeout updating clock aw_mmc0: controller timeout aw_mmc0: timeout resetting DMA/FIFO aw_mmc0: timeout updating clock mmc1: CMD7 failed, RESULT: 1 mmcsd0: 64GB at mmc1 50.0MHz/4bit/32768-block ? List of GEOM managed disk devices: mmcsd0 mountroot> ufs:/dev/ufs/rootfs Trying to mount root from ufs:/dev/ufs/rootfs []... aw_mmc0: controller timeout aw_mmc0: timeout resetting DMA/FIFO aw_mmc0: timeout updating clock aw_mmc0: controller timeout aw_mmc0: timeout resetting DMA/FIFO aw_mmc0: timeout updating clock aw_mmc0: controller timeout aw_mmc0: timeout resetting DMA/FIFO aw_mmc0: timeout updating clock aw_mmc0: controller timeout aw_mmc0: timeout resetting DMA/FIFO aw_mmc0: timeout updating clock mmc1: CMD7 failed, RESULT: 1 mmc1: Card at relative address 58916 failed to select aw_mmc0: controller timeout aw_mmc0: timeout resetting DMA/FIFO aw_mmc0: timeout updating clock