From nobody Mon Jan 8 07:00:51 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4T7lMn5C6tz578f0 for ; Mon, 8 Jan 2024 07:01:09 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic310-20.consmr.mail.gq1.yahoo.com (sonic310-20.consmr.mail.gq1.yahoo.com [98.137.69.146]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4T7lMn1kd2z4TXp for ; Mon, 8 Jan 2024 07:01:09 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1704697267; bh=4aJvHEX0QDWoo2DAQJWz9urS9kNekFNE6yY7KmNQfMU=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=n/raPYRWrEQJJ7kvW77cZ89yFG3sm/c4dOr1me6TlerN2nSCFRwJPNo/ndyajIfPPPAjb/VOBPAs/gLFtZJMvOnaOdjrXq1qMe7WhsH/g6CA7qHHrN1oj2zakWT5CFAfwEvfsXhQdFg7Ws5yNi4YwtKL1q/IAGXsoVHljgTePX/WpL0FsYeEOFsuBEcVW331CmuZx2SKarV+pi60gio+f+f4YovFgPqT2gxTEFLkkZYNz3mhX4eF6o99IvHIa+cA1bTNZ1N1yoEhWhIUob1jxhkzzCzw1u/41XqbXye5pVpEua0ZZkhH9V9hMlYIlhbeMZ5XXcvimXjICAqBRniLMg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1704697267; bh=cgIOw0j66ar8a+G80G4kCkBnYp5iIz9iklP+xyg0bxI=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=IR2v6D+Vmc0qNj6C6U/vkCwaWR3aXlmrNpMnwKi4vpOS11gdnVXcOGqwzdUv8v3cwHaz71GZXab59cQ1D3MNFu6p4V/DSk32iHmNxO00qHLpdxQzuDta9t1KoDVlUyfn9pqfrrh42DKb9kyQeVoHWCGe7UhUSgB3fMHoewg/+8aenacaIf1r5L7SbSRg//cJwoHms+77uj9LgeuqIr0gYT3kcHBw+wQDrVVVCswqSkmPQGyBUfRZjy7RqIt0zlSeW4WMpl69e8JDCNk1nEIPOcyIXSfLMFJvYp+0gfjNbCa6iQzbqlHz9mgbG+grsW5JTcB0nF6dNVG2zBtq74X/lQ== X-YMail-OSG: cXjqZR4VM1mOc37QtKwm3LkKjKPDs0soo63FpSmVpCQDBV2b2Q71Y8CLQa6LPcN 2ERCZj.iCpt7PICLLZqF438VJ0rtl4doSHHZhaHCU86NL5NfhvJRgp_dvdF2sK280JjPAUkbc5UB lqIk_yqrjLJOTZn21Dic1_YhV3w.4wh0LLbFazSf5..FqMTZV1SUhBcVB.p7zYYq9j6hU59j8qMw Pj73HyAPo5AfxpMExLnLzn8i0eEjaEtiRJKVjW8shWTJRon2G.SCkO3jEFH63mP8MoUygOv.j.CP jFCMZ6yebpNjcL1dWZjxWC_cKGatiJcwNbNNJJIbBtWaXnN_6JBaVIIOBMstlhEqZcDfs06rdCgh RR07ZdLNO.UAqt8S3MGYIIZcMHldnUpyizj1CUy81Chj5g4e5KzVXIOC9c9cETlOXkgIDAU63hkA VbWsuxIUJAViiHjHjB.n44y48V2dEjJTX8KTJkAYJkIqCBBg0AoKXzyMHyeLX4RvstamIw7uNMPn 5_P3gFQ1ta62wD1pFTzvG9VSO9iRC7_7bbx1.iu0NXIORpoHSoSvO3e6gjKFbtB0wzysfQ3KuyB8 oRGbNaom_lcAmGaxe4IFFGBrjLxqPP2zwNiw4Ok26g3w5Z8N8TE1Q_1g6mNuSzUPSNAXgyaHzclW cEQiGOstMJKZHstHWtMtC.O5.orO.gNbRIxPy2557TNV3hYRZnnaiPJbUEMtsYbzqciHL4gO1nPA TJGgIrIdJmrKn_jr7aajJAc1PwyX8atBtCjM4tDJcRd1EAtYk_APXSqiOz2uGaXZHFJ5UrpSxnhY VtVwUdIiYu_gZz0VUSLg55smKbffKPWqgVJ2rtXrrjAuRKiyt6QlTRmlMGflgvVFueMbfxc7TdyE tmaTX.m4q34DQfOpS11bPdHa_gEAHsLV7cT6.qHGzcPEMH0B9_Y0UTXkuzF3w1t1D7VqxvAKqToH mFNDLkyEDQ4YTuYZXOnw8.BYWAs4EyYiSfMpDAthSc1hk_haPKeWXENq8aS3eFbidxmtzSty9kOJ Y.crxEl7i7xy7w1RLw9IwhtGlVvDdKgoIVo_QpSTH_TPbbipBZYzcu0ZwhIxUqmxIUGZTjUmEUbm 1c8BN8_Wk3mNFfccgrRJ4QojUWHsgv0LWIQn1wazE65fFRP7zq4fdnt2LCvYJFd18Bhz6aSHcPIP rmv0MmIz_P8HAYeUFAhHboZ7iaZqbKqZOasOksITBvrPzP0d5iIXdv1yEExMPBdjZgCkj9SeRJA3 nY2QvwVCihXYJEVy9yxu5rwpp58Oe8HHzp8SZ8gmQ_eolOiwcDX39neRuk3o1E8OlrPC0Nxupbms X.gbuGh1GVqsEksKrO_8SUmf2NtpKWAZm_Q7hbslxPma0vFWp1DUtMfoUOaj_zr983ZTPBMDRyQY M5j5WX39_crDslZPAI77a5dQRdTVtJq1PGMVslkiPKSUPl0FYDx7TYOZr6Sg6.pd4EgJuf8Io7fB dyzxKOMl2ET0UhxGfB0Xkw8iLcDb3AfTLsaYwVYNoBQmYd5LFtd6Y6zafBRGt1h1APJ5JiSWA8ri Dxn8nc.JISYSqInQ9s3EAyERJ08RM3NmmmAfPFEa.b0jl7kUoNh_i3I8GxzZxcyOBww98pVYbjYI 8ng2xhr9.yQuUI35qkpn4OBRTUEP8QCIBaE9.Ft05liW5Cr1UmWfH798RdHF90SnhcwCa.tIddbQ Ky_J4KvLMJAxFuVn7LWgZjnEtcrut8caMeJExrFXaLEA1bpz.PkewavvbSGotH1mZZQbpEO4IUvo HSmIAV9H_wclkRxPpLRfeje2JkBcj4ji4cIUZLl7prBgutznVSiphI9RNCU02Mg_GOdwhnJucgqY 56vjSyayc6IzBfWCxu9G7ljpLpHW70Dcr_3OyDbunLzHSKmQm6ZD4ux6om1vRoUWNhoS3O_CMAx_ 4rgybDEshGN0yQhhrXs.5otUfITdP5E43mS45LgA7tX5ilV15a1T2doYhWpl35nDGPQY97VDcPJu 8cTuVt_uOfxO.VhAQ7WjnQjHuYStsqEvLEEsS6uvZrcckSr3_nv1oR35Nyo5yg5grg2LSz5gUrJX 7C.vPh5Wor0bCWUGHzIT1KTtXMFYjaWx0vA62hMkVy7e4mOKUA3iudpHGDmm_NqBQL2yFCpTR3cI RdiDvML3qG7J1Y7LxEI.9TIDvtFwBTnPoaPBxYywzKD1bQPVsvOvomCu9e8m4Jh9tGCRfqL_Rlu1 scl1QimqyO1IfPVzFja9wFEgTHagbAYzrVL7LkEA53V34B5RfG5Qi1vxdknvjxdFAT6YX_aGiZw- - X-Sonic-MF: X-Sonic-ID: 159038ed-1e1e-4a6d-a8e8-641e69eaea99 Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Mon, 8 Jan 2024 07:01:07 +0000 Received: by hermes--production-gq1-6949d6d8f9-ghhkt (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 663a2f14ea290315e662933ae0950131; Mon, 08 Jan 2024 07:01:02 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.300.61.1.2\)) Subject: Re: enabling powerd on RPi From: Mark Millard In-Reply-To: Date: Sun, 7 Jan 2024 23:00:51 -0800 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: References: <136EA428-CC30-4CF4-BE65-30B0CC8656AF@karels.net> To: void X-Mailer: Apple Mail (2.3774.300.61.1.2) X-Rspamd-Queue-Id: 4T7lMn1kd2z4TXp X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] On Jan 7, 2024, at 09:26, void wrote: > On Thu, Jan 04, 2024 at 07:53:12AM -0600, Mike Karels wrote: >> On 28 Dec 2023, at 13:11, Mike Karels wrote: >>=20 >>> I am looking at enabling powerd by default on the Raspberry Pi 4 and = maybe >>> others. There is a bug from 2021 on the subject which has gotten = some recent >>> discussion, = https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D256836. Also, >>> problems come up from time to time about performance problems = because people >>> don't know to enable powerd. It makes FreeBSD look much slower than = Linux. >>>=20 >>> The simplest action is to enable powerd by default on the = arm64-aarch64-RPI >>> images. This would affect RPi 4 and variants, also RPI 3* and later = RPi 2. >>> I enabled powerd on an RPi 3B+, and it seems to have no issues; it = seems >>> to work. Does anyone know of a disadvantage of enabling powerd on = RPI >>> images for all targets? The alternative would be to configure at = the first >>> boot, although I'm not positive of a definitive way to identify the = RPi >>> variants. Maybe just looking for a dev.cpu.0.freq sysctl node would >>> suffice. >>>=20 >>> If no one objects, I will make changes to enable powerd on RPI = snapshots >>> for 15-current, and we can see what happens. >>=20 >> My change to enable powerd for all 64-bit Raspberry Pi systems using = the >> arm64-aarch64-RPI image is in https://reviews.freebsd.org/D43296. = There is >> also a review that splits RPi4 from RPi3 (etc); it is >> https://reviews.freebsd.org/D43141. Comments welcome. >=20 > I think powerd by default would be advantageous in most use cases. It = would be particularly useful in a battery-powered context. Yep. But it may be worth a note mentioning the subject area with the issue once it is isolated: avoiding unnecessary surprises that are messy to track down to a specific type of context. > I used to use powerd a lot, but it's not needed for my own uses right = now, so it's disabled and i overclock by firstly having really efficient = cooling and then setting config.txt like this >=20 > hdmi_safe=3D0 > armstub=3Darmstub8-gic.bin > gpu_mem=3D16 > over_voltage=3D6 > arm_freq=3D2147 > gpu_freq=3D750 > force_turbo=3D1 I do somewhat similarly for RPi4B's but use 2000, not 2147: 2000 works reliably on all the RPi4B's I've access to, Rev 1.1, 1.4, and 1.5 examples involved. 2147 or 2100 does not work on all of them. I also use a power supply that has a little more curremnt margin than the official ones and that contributed to my being able to use 2000 uniformly, given what I plug into the USB3 port as types of boot media. I also control the memory speed to be fixed at the fastest, no matter if the RPi* firmware vintage in use does so automatically or not. Various vintages definitely do not. > # sysctl dev.cpu.0 > dev.cpu.0.temperature: 51.0C > dev.cpu.0.freq_levels: 2147/-1 > dev.cpu.0.freq: 2147 > dev.cpu.0.%parent: cpulist0 > dev.cpu.0.%pnpinfo: name=3Dcpu@0 compat=3Darm,cortex-a72 = dev.cpu.0.%location: dev.cpu.0.%driver: cpu > dev.cpu.0.%desc: Open Firmware CPU >=20 > My context here is permanently connected to the recommended PSU, = headless with serial console > and UPS, and it needs to be responsive, which it is with this = overclock. > If I were to use powerd in this context, it would never realise the = full overclock > and shows dev.cpu.0.freq_levels: 2100/600. >=20 > Connected to it is a usb<>ttl serial cable on the rpi4's pins which is = connected to a rpi2b+ > running 12.2-RELEASE which is used as a "console server". There is no = console scrambling. > Console is invoked on the rpi2b+ with 'cu -l cuaU1 -s 115200' =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Mon Jan 8 10:55:23 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4T7rZP2NvQz55MDR for ; Mon, 8 Jan 2024 10:55:41 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic301-21.consmr.mail.gq1.yahoo.com (sonic301-21.consmr.mail.gq1.yahoo.com [98.137.64.147]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4T7rZM5tTxz4xkv for ; Mon, 8 Jan 2024 10:55:39 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=nhvZ1ASd; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.147 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1704711337; bh=cZCMkkZxItMW54aXBjHsEC83Wz2EtJ20kdNuA4flY5A=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=nhvZ1ASd48qkHHSd7jw5fDCPkkq/JjQfO4YKbgQBWj5wnyWl48e/CJixbiZDo3eWLsLSgdyMcZBfJSxFz1GmLTnwXPOWiIdrtMGyQuTWSYxpkOJrWA9//FzKDJz+bQ6H09FGkn3gvtsEfbax94DWiMe3R183B+XPA5tz9iE6STVU5bcecKIMHS0R91X4sxgMeSWVp8s4+1Mc9q42ipKB1u2SqAZ/zPevXi5TZl1n9eTcyGPNgV2t85+cIRrq4luruQlXdY5j4K2nuk9k0wE8oCbjsfvIW3FoO4pwfI0XRIPt+Lkj9juPi3Q8TeGzXfEaFWi6d/+uMFgMuEKMWPuI8g== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1704711337; bh=wUwtj9fUUxfOJHgvJhKg+oTKPV9CuQ+DQ4Ic3LFGdix=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=FYGJMu/P+fdAzGjIXjtLr5W0Zig4ACyHAPI4TZzgluBY84ZjgYMmdh2bMS6j3loN/UjTH0AdfSnEwHnraTjfNS2UnUm+KM6cLJif3CNKXAFC1fhGrP9iYZw0I1+nz//v65FOIq1AaaQBJpRNX8mU2oFq1j8Wsqg3xYuCvX1nTJzvuAOd3lw4fjeC3licd83VB+E4LyXLJ0cv74iz4ybdFztqmK1JKtFNfAEJk6rpnauwYak+KwtX0VKIS0af70NPT6K1lSfv6/+w5ctJwDTctxeKALNhk5uuAWABkYorLDTOr0ySCr2Xj1hDGvZREnnkT0JFv2XC7bI7S4LxSTMI9A== X-YMail-OSG: WjBGKjoVM1l70zPXkHAGya7stTklJ6f8cyNMfQOwjWazk33wDDibTa77KJaszgy f.talAdlVlaLT4Jv0cZIkmzCT.XkgSpk4cZaBZIL6PfAROUI.VDIvTR4_2vh4A7LxtQJJuSOb8tk 9Dn4vE5xYxOppo7fjxxzYem26stoP6calLIwyPOeDYzzsWRVogNPmodeA2yKOpJk_KXXumqnj4B7 ER1NW2HkQ.LIrSS.aK.o3KBAfcv49ZXeGwiEArSLeOtwnxCob01FdKyOKfSeNpjpX3LMYXh6Non2 doXQkkfr1UazQ30c0z9bNsY6ZR4G45eB328AtCMIlqvsn2A902r2nJqca03I8iF6XaA1n6IfaIDx LDmeQ4jn6ep1W2kyf34ut_S05tpU1yhtOD1XAf1VoBkSkl0AG3ToPQWEVkdePQx_LtmCciexV4vM 75jnbg8Jtoy08kGaqgK.0k2KsEjtsuMWK8AvlbqWUsXNtR_y8S4JAmxLGz22HuuCYfiWgjGXyNq3 MPWuuhuuj310pWr9Wym.qeXTEdjT4yDoUzBHDSvikhJWNhZoti8ZZwD0cEfyK8r58EUKle2POiiD tJxBnO0fQaiFe1w4w1R6h_9WJPM8PcGGEtDE1N3E8MSsItSw.MD0UYnRNoGo727K34UUgliXobNk Rthk_CMCLnw63ah5llAyuJMKKvJAThIj0VK.WBMeMTXp9pRfjtTDvdzEZl.qWTlcAk04trxkooEp DkBMNKoCU6qag2rGQ4q_wW_NGoDrC1rEA8MrJfsfjIuHOcRCkpN7IjIDe6ppc378shKKY_vrFoxo C937JqyFRStWyEb2ld5NWAIBBtFVuFHk3LZL__b6vz.6Llmc5kvqApQWAxTucpAIG3XvHiG_hCxy R4FQ6EHBiGI0sxRnmrRh.sQzUux8rfXNF5lWSXmmuoE8.Z4FPcV5Egyeln81qhNGMtX4r3WBTwnH H.YFUwVmU49BCwLMxrbiUS4tgD8LQjt7Ood0V2rLVD.159zVDsBkmBgUpRNpz3_2ozQ_FgKqcYdR mrtvRb95qC2FKIodIXdoOr5PAwQo.m7.Z9EwBRIncUPiiCGsEmi0wnL4AdLyryPl6VMq15VuYNMi es6dpFZfzn_29eG99vaVVejSAoksZxcAUet6q5iCEFRaUTOInnzIq.fcWX3hooo44zEUGTO0CeoW xXG6Be1Kg4wQAJseQEMXm4z2pYqBH0hLL71FLWrM54OqkfZe6mVLSULLxsoJiIBSPGclazLf5dA1 k8K_TVB161A4NI8hulkU_2etoIa77yzea_8zQ97BbpKEBElQ0JcSllvsONuP43gTI0JmjU3gZ0zA gJCmlFln6t8piDmvBNMmcBRfbjMfN9dbKPH28B4jGdcn5VPQeWUBPsVTvKiFKlxNJYR2R2QVgW8E mjUgqbGQP.PVIQ.bwaNU27nZ_LAQjR4xRjZFBqiN1peNST5qzsm50mnY0.Bp7PhD88S6.h0Ydohn Ml1onm3Agr6LuwpBmNvkmNILdrQYdc_4LMG3fcORw5k9oJh3.3bCkQGg9dLAYyz0d2fdSSYo0M.4 dybgPknvvs._jwDqcQWpMsMFMtmLpkyQJtFuUMNG6J8TBpnqhJGUinaJ7jH2JiwCTl9nLyHY65JN yvSwmzF7OQFEyWUinuiNC_pKyQB213jLOwXHeZsaU7_CF.e1UMRK7TYAclwC0P2iUkzzkhkM6PFF twipQvxj31rXB2UYrZpxQ_bcNsc3dQUg9mNNDEXn5vUDwo33wzk0dL.wqX6Av8LCrnyPYUOquWoN AxXCvKJyd_esUILaj4iYTWokT338GcXDnvGNITGE2NEORsgSTbhcZlAZI4h5TNkCxWYAAiQfFJXE pjIIPMJk0SiH0zzYjYn77_daQzz5vRKMe_2cP7h3pHDpughsi1l44MapqTd2C9yhAsTdH_LyCCjb iLg426yZNBRgJkfgtPOOPQT4ssMiEvLWRVIidiTaWya_6ceKM0ZgG7X4Ck9XdRnAgmWifCKBZoFI 1j3bGxQmPY_Ikt_zkuTu0uZKO5AOFVh0n__Kn7YbOB01XT.l6.fz3nKyYNgreREsk.WdS3Br8syj pciFCmNvVBfTiBJJamoUkpPTpbVouFNyL2.2SKMgj1pGbb_gjncZLkGMZlzghUaTDOgAqtyBjc.4 SHexv5X2B_pCJXQn3HYrd7aQ9FOvIRUupHBChsQ8GPt7IHIPw3l9KiyCEIADyHCbcZcl0pKoK.Pb ucthiAXlsGf_WoJEI1K9C.uI9_VJGoOMFdYM22Nl9Mb4SUhUDgXFY8KYVpRkyCLssoxFUU0rFdSY - X-Sonic-MF: X-Sonic-ID: 287d06c3-0e61-4b69-a31e-a5a0097794e6 Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Mon, 8 Jan 2024 10:55:37 +0000 Received: by hermes--production-gq1-6949d6d8f9-q7525 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 3db1670b673f0fea75a7ea313b500d3b; Mon, 08 Jan 2024 10:55:34 +0000 (UTC) Content-Type: text/plain; charset=utf-8 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.300.61.1.2\)) Subject: Re: USB-serial adapter suggestions needed From: Mark Millard In-Reply-To: Date: Mon, 8 Jan 2024 02:55:23 -0800 Cc: Marcin Cieslak , freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <7D27DF9F-AA9A-4D44-BC28-8CC637D0F550@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3774.300.61.1.2) X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.66 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; NEURAL_HAM_SHORT(-0.16)[-0.158]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; MIME_TRACE(0.00)[0:+]; TO_DN_SOME(0.00)[]; ARC_NA(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; FREEMAIL_FROM(0.00)[yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.147:from]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.147:from] X-Rspamd-Queue-Id: 4T7rZM5tTxz4xkv On Jan 7, 2024, at 08:48, Mark Millard wrote: > On Jan 6, 2024, at 19:00, Mark Millard wrote: >>=20 >>> On Jan 6, 2024, at 18:36, bob prohaska wrote: >>>=20 >>> =EF=BB=BFOn Sat, Jan 06, 2024 at 11:44:49PM +0000, Marcin Cieslak = wrote: >>>>> On Fri, 5 Jan 2024, Mark Millard wrote: >>>>>=20 >>>>> I also request to again list the exact content of the two >>>>> config.txt files --and again every time they are changed during >>>>> this investigation. >>>>=20 >>>> I second this. There is way too much text in this conversation >>>> and not enough data. It also does not help if every system is = somewhat >>>> different. >>>=20 >>> Unfortunately, the systems simply are different. Four Pi2 >>=20 >> Please differentiate RPi2B v1.1 (armv7) from v1.2 (aarch64). >=20 > I meant that to be a general request to never reference just > RPi2B. The v1.1 vs. v1.2 was an unfortunate marketing naming > for the armv7 vs. aarch64 change that ends up needing such > extra text to give the proper context. >=20 >> I suggest armv7 use the snapshot armv7=E2=80=99s config.txt as its >> config.txt prefix. Now that I have my normal internet access back, FYI: # dd = if=3DFreeBSD-15.0-CURRENT-arm-armv7-GENERICSD-20240104-8bf0882e186e-267378= .img of=3D/dev/da0 bs=3D1m conv=3Dfsync,sync status=3Dprogress 5205131264 bytes (5205 MB, 4964 MiB) transferred 18.064s, 288 MB/s 5120+0 records in 5120+0 records out 5368709120 bytes transferred in 18.680162 secs (287401640 bytes/sec) # mount -onoatime -tmsdosfs /dev/da0s1 /mnt # more /mnt/config.txt init_uart_clock=3D3000000 enable_uart=3D1 kernel=3Du-boot.bin kernel7=3Du-boot.bin dtoverlay=3Dmmc >>> , two Pi3, >>> one Pi4. I'll try to make the config.txt files on the Pi3s match >>> better when the present experiment is complete. The interconnection >>> of hosts is unique and, apparently, unusual. Not all of that is >>> relevant, but exatctly what part isn't yet obvious. >>>=20 >>>>=20 >>>> I have skimmed the peripherial documentation for one of the = Broadcom >>>> chips (I think the one from Raspberry Pi 3) and it says that >>>> the speed of the mini uart depends on the CPU clock frequency. >>>>=20 >>>> I could imagine a situation when mini uart speed changes during >>>> downlocking the CPU. There was suggestion to not use mini uart. >>>> Use the port where the frequency is not changing with the weather. >>>>=20 >>>=20 >>> Agreed, and I changed config.txt to set >>> dtoverly=3Ddisable-bt >>> on www.zefox.org (the console host) to force use of the PL011. >>> It didn't help detectably. >>>=20 >>>> I don't know how smart is the power management with powerd, but >>>> I could also imagine shutting down peripherials or stopping the = UART >>>> clock as a potential power saving feature, so here you are. >>>=20 >>> No sign of that, but Mark posited that powerd might be causing >>> trouble with the terminal server (pelorus in this test). That >>> looks like a possibility. At the moment pelorus is without >>> powerd and it's holding a serial connection to www.zefox.org. >>>=20 >>> Meanwhile www.zefox.org is running powerd and buildworld >>> while being a terminal server to a Pi4 named nemesis.zefox.com >>> That connection has dropped twice so far today. >>=20 >> Interesting. You have not reported on nemesis.zefox.com =E2=80=98s = config.txt >> content or powerd status. Also, which type of RPi* ? >=20 > If the chart you referenced is right for the issue: RPi4B. (Other > details about turned out to be in accurate at the time as I > remember, so the cross check seems appropriate.) If so, that > still leaves the status of powerd and the config.txt content > to publicly document. >=20 > Also, as I understand the reports, a system running both tip and > powerd ends up dropping the serial console connection at times. > A system running tip but not powerd does not drop the connection. >=20 > However, it might be that some form of test of a RPi* running > powerd and just tip and not ssh might be useful. Similarly for > a RPi* running powerd and just ssh, not tip. I'd expect that > the tip+powerd-ssh case (so no ssh) to fail and the > ssh+powerd-tip case (so: no tip) to not fail. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Mon Jan 8 17:04:19 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4T80lw5tcQz566dp for ; Mon, 8 Jan 2024 17:04:28 +0000 (UTC) (envelope-from Thomas.Sparrevohn@me.com) Received: from mr85p00im-ztdg06021701.me.com (mr85p00im-ztdg06021701.me.com [17.58.23.196]) (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 4T80lv6lhdz4hY2 for ; Mon, 8 Jan 2024 17:04:27 +0000 (UTC) (envelope-from Thomas.Sparrevohn@me.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=me.com header.s=1a1hai header.b=ZR4bptcF; dmarc=pass (policy=quarantine) header.from=me.com; spf=pass (mx1.freebsd.org: domain of Thomas.Sparrevohn@me.com designates 17.58.23.196 as permitted sender) smtp.mailfrom=Thomas.Sparrevohn@me.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=1a1hai; t=1704733466; bh=fsfBMZcWUxusMSXZN7jbFgZm3kKXykNDXk4BLVfX9yI=; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; b=ZR4bptcFENUukbTSyhLD/7O1tvnjseJjQXKtrRpyiow2xlw5R5BAYiMBQlffKVLad rNwNmxi3siCU6ScCmQsKJcqIcDXgC+DDMRD3Rry4n7jBWv7qNv3eRNjREQdpkzHzjV Tpg5YGU7ISMp/TaIIHa+Vt9tWMxrbniNVEKlvUTz3sV4lJ4nwnOAPC3KKnAbnlk30h VPLPxXYE8KACFnG1W5lXPUZ+r/45ysV3N8fjXpUADHZ8a9CjlAmWl7jxtfAHj6Hj/u S5qbzR9t0h4oiS6ROK7LHVZ9mCX7gtG/65bDHABB01U8hsm/s0FAGLrsXr+23rR4P3 EsjJUYc3AYyrA== Received: from [192.168.0.97] (mr38p00im-dlb-asmtp-mailmevip.me.com [17.57.152.18]) by mr85p00im-ztdg06021701.me.com (Postfix) with ESMTPSA id 6F798263354B; Mon, 8 Jan 2024 17:04:25 +0000 (UTC) User-Agent: Microsoft-MacOutlook/16.80.23121017 Date: Mon, 08 Jan 2024 17:04:19 +0000 Subject: Re: Freebsd on M1 Macs From: Thomas Sparrevohn To: Joe B , Message-ID: Thread-Topic: Freebsd on M1 Macs References: <7a13c63d-a50b-429c-a481-0693e9faaf6b@gmail.com> In-Reply-To: <7a13c63d-a50b-429c-a481-0693e9faaf6b@gmail.com> List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3787578265_705725899" X-Proofpoint-GUID: X7xaeNfbRiktT6EPfi9lI3xvyF390sz3 X-Proofpoint-ORIG-GUID: X7xaeNfbRiktT6EPfi9lI3xvyF390sz3 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.272,Aquarius:18.0.997,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2024-01-08_06,2024-01-08_01,2023-05-22_02 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 clxscore=1011 adultscore=0 malwarescore=0 bulkscore=0 mlxscore=0 phishscore=0 mlxlogscore=962 spamscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.19.0-2308100000 definitions=main-2401080144 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.10 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[me.com,quarantine]; R_DKIM_ALLOW(-0.20)[me.com:s=1a1hai]; R_SPF_ALLOW(-0.20)[+ip4:17.58.0.0/16]; RWL_MAILSPIKE_GOOD(-0.10)[17.58.23.196:from]; ONCE_RECEIVED(0.10)[]; RCVD_IN_DNSWL_LOW(-0.10)[17.58.23.196:from]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; FREEMAIL_FROM(0.00)[me.com]; RCPT_COUNT_TWO(0.00)[2]; ARC_NA(0.00)[]; FREEMAIL_TO(0.00)[gmail.com,freebsd.org]; MIME_TRACE(0.00)[0:+,1:+,2:~]; TO_DN_SOME(0.00)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; FREEMAIL_ENVFROM(0.00)[me.com]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[me.com:+]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:714, ipnet:17.58.16.0/20, country:US]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; DWL_DNSWL_NONE(0.00)[me.com:dkim] X-Rspamd-Queue-Id: 4T80lv6lhdz4hY2 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3787578265_705725899 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable It runs pretty well under Parallels as long as you stick to 8 cores =E2=80=93 I a= m really ol=E2=80=99school 386BSD/Intel32/AMD64 man =E2=80=93 but I recently wanted to u= nderstand the difference between FreeBSD approach to asymmetrical cores so I= downloaded Parallels and tried it =E2=80=93 I am quite impressed=20 =20 From: on behalf of Joe B Date: Sunday, 26 November 2023 at 19:22 To: Subject: Freebsd on M1 Macs =20 I know this is a longshot but I'm going to ask I know MacOS is a BSD but we= all know it's very sugarcoated and doesn't look like a BSD.=20 Question will real freeBSD ever come to the m1 Mac's. I got a 16 inch mbp w= ith good specs just taking up space right now=20 Thanks=20 ~ Joe B=20 --B_3787578265_705725899 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

It runs pretty well under Parallels as long as y= ou stick to 8 cores =E2=80=93 I am really ol=E2=80=99school 386BSD/Intel32/AMD64 man =E2=80=93= but I recently wanted to understand the difference between FreeBSD approach= to asymmetrical cores so I downloaded Parallels and tried it =E2=80=93 I am quite= impressed

 

From: <owner-freebsd-arm@freebsd.org> on behalf of J= oe B <jcb2023az@gmail.com>
Date: Sunday, 26 November 2023 at= 19:22
To: <freebsd-arm@freebsd.org>
Subject: Free= bsd on M1 Macs

 = ;


I know this is a longshot but I'm go= ing to ask I know MacOS is a BSD but we all know it's very sugarcoated and d= oesn't look like a BSD.

Question will real freeBSD ever come to the = m1 Mac's. I got a 16 inch mbp with good specs just taking up space right now=

Thanks

~ Joe B

--B_3787578265_705725899-- From nobody Mon Jan 8 17:06:57 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4T80qK6PZlz5678J for ; Mon, 8 Jan 2024 17:07:25 +0000 (UTC) (envelope-from Thomas.Sparrevohn@me.com) Received: from mr85p00im-zteg06021601.me.com (mr85p00im-zteg06021601.me.com [17.58.23.187]) (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 4T80qJ62Zqz4j32 for ; Mon, 8 Jan 2024 17:07:24 +0000 (UTC) (envelope-from Thomas.Sparrevohn@me.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=me.com header.s=1a1hai header.b=obVlSM3K; dmarc=pass (policy=quarantine) header.from=me.com; spf=pass (mx1.freebsd.org: domain of Thomas.Sparrevohn@me.com designates 17.58.23.187 as permitted sender) smtp.mailfrom=Thomas.Sparrevohn@me.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=1a1hai; t=1704733643; bh=WSXJ4rceVTs74uDFmBUC/x7UMDF6yiPJjzREOVGGYhI=; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; b=obVlSM3Kv83YbB0JY1WmKXGaWr7IoSEBUuLxI551JHJxi9CU3vRzgvnw9KXy3GzJn FuFaHXSQVRdyzjp6HxYXsF3Ct/zcRdYknUvNFFvVbB0eUQouxCIwgVaV7PTEWr3KrH 2NI10ky89stJPiqZ0+bmusTdolezWvK6gkirxOqg7kwdGwciJd8JTsga3WmLmooObH 8uHUIq8xs/RVqUTYs2Z6bC9QP7+Ii50QA8j6pMyShOYNo/1oZzIfDBdSVsO1gvXKPJ R7+HTA0nfXrkeLjZcPPmDAjbbdFt7NH0QMoU6EycEbcmUUlByOOGAgplH9CKmQhTiZ xGoFfMeM1awoA== Received: from [192.168.0.97] (mr38p00im-dlb-asmtp-mailmevip.me.com [17.57.152.18]) by mr85p00im-zteg06021601.me.com (Postfix) with ESMTPSA id 375E130587DA; Mon, 8 Jan 2024 17:07:22 +0000 (UTC) User-Agent: Microsoft-MacOutlook/16.80.23121017 Date: Mon, 08 Jan 2024 17:06:57 +0000 Subject: Re: Freebsd on M1 Macs From: Thomas Sparrevohn To: Joe B , Message-ID: <70D6C9DD-5A2C-4A5A-AF04-566A9C44290E@me.com> Thread-Topic: Freebsd on M1 Macs References: <7a13c63d-a50b-429c-a481-0693e9faaf6b@gmail.com> In-Reply-To: <7a13c63d-a50b-429c-a481-0693e9faaf6b@gmail.com> List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3787578442_3822341749" X-Proofpoint-GUID: QxZQN856AVVVz1-vv2UfoWI3DRlco8Mv X-Proofpoint-ORIG-GUID: QxZQN856AVVVz1-vv2UfoWI3DRlco8Mv X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.272,Aquarius:18.0.997,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2024-01-08_07,2024-01-08_01,2023-05-22_02 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 clxscore=1015 adultscore=0 malwarescore=0 bulkscore=0 mlxscore=0 phishscore=0 mlxlogscore=739 spamscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.19.0-2308100000 definitions=main-2401080144 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.20 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[me.com,quarantine]; RWL_MAILSPIKE_VERYGOOD(-0.20)[17.58.23.187:from]; R_DKIM_ALLOW(-0.20)[me.com:s=1a1hai]; R_SPF_ALLOW(-0.20)[+ip4:17.58.0.0/16:c]; ONCE_RECEIVED(0.10)[]; RCVD_IN_DNSWL_LOW(-0.10)[17.58.23.187:from]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCPT_COUNT_TWO(0.00)[2]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; FREEMAIL_FROM(0.00)[me.com]; FREEMAIL_TO(0.00)[gmail.com,freebsd.org]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; FREEMAIL_ENVFROM(0.00)[me.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[me.com:+]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:714, ipnet:17.58.16.0/20, country:US]; DWL_DNSWL_NONE(0.00)[me.com:dkim] X-Rspamd-Queue-Id: 4T80qJ62Zqz4j32 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3787578442_3822341749 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable As to running it on bare metal =E2=80=93 I think is WIP both for Linux and FreeBS= D =E2=80=93 for very good reasons =E2=80=93 It seems that UTM works as well =E2=80=93 but I ha= ve not tried it=20 =20 From: on behalf of Joe B Date: Sunday, 26 November 2023 at 19:22 To: Subject: Freebsd on M1 Macs =20 I know this is a longshot but I'm going to ask I know MacOS is a BSD but we= all know it's very sugarcoated and doesn't look like a BSD.=20 Question will real freeBSD ever come to the m1 Mac's. I got a 16 inch mbp w= ith good specs just taking up space right now=20 Thanks=20 ~ Joe B=20 --B_3787578442_3822341749 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

As to running it on bare metal =E2=80=93 I think is WI= P both for Linux and FreeBSD =E2=80=93 for very good reasons =E2=80=93 It seems that UTM= works as well =E2=80=93 but I have not tried it

 

From= : <owner-freebsd-ar= m@freebsd.org> on behalf of Joe B <jcb2023az@gmail.com>
Date:= Sunday, 26 November 2023 at 19:22
To: <freebsd-arm@freebsd= .org>
Subject: Freebsd on M1 Macs

 


I kn= ow this is a longshot but I'm going to ask I know MacOS is a BSD but we all = know it's very sugarcoated and doesn't look like a BSD.

Question wil= l real freeBSD ever come to the m1 Mac's. I got a 16 inch mbp with good spec= s just taking up space right now

Thanks

~ Joe B

--B_3787578442_3822341749-- From nobody Mon Jan 8 17:36:56 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4T81TW3fxSz56CvY for ; Mon, 8 Jan 2024 17:37:03 +0000 (UTC) (envelope-from Thomas.Sparrevohn@me.com) Received: from st43p00im-ztfb10071701.me.com (st43p00im-ztfb10071701.me.com [17.58.63.173]) (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 4T81TV1vCqz4srp for ; Mon, 8 Jan 2024 17:37:02 +0000 (UTC) (envelope-from Thomas.Sparrevohn@me.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=me.com header.s=1a1hai header.b=zjm69t6H; dmarc=pass (policy=quarantine) header.from=me.com; spf=pass (mx1.freebsd.org: domain of Thomas.Sparrevohn@me.com designates 17.58.63.173 as permitted sender) smtp.mailfrom=Thomas.Sparrevohn@me.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=1a1hai; t=1704735421; bh=7ItTBbDj5b1Ws8jXHynxJMYsfPGt1IBN6bR0YtqzhXs=; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; b=zjm69t6HGv3hwxrG0ZLYtUIGU+YrmcRWAdwFTAgdEG6btnozm7YAIzCdAQDz8m1Qi v9vxH+nXEH/5sGZyCEpumYuTp1La4qAOq4owXQeScFB4fUZ9Okh5X+p9mQDaTSqMJJ VC+stDHxcyWR/rzIrwzkeQnMqHVQkVb8hI9ArhLCkoJQ5KBysEGWdoPwMyk+kLUkcZ 6qS6NgTaBtdStZVtDbBUofm88IYaUn74o9GjQFagRUq5fqLD2kNC5VhllcTZ+NFPA0 fCIjfhHAoSgju83yzBLtC3/D1TGznbNkUWIztBq8RD9rq0W9PcxZEisnTYAxVNPT6t Q699V0tRJzFUg== Received: from [192.168.0.97] (st43p00im-dlb-asmtp-mailmevip.me.com [17.42.251.41]) by st43p00im-ztfb10071701.me.com (Postfix) with ESMTPSA id A9183A02EB; Mon, 8 Jan 2024 17:37:00 +0000 (UTC) User-Agent: Microsoft-MacOutlook/16.80.23121017 Date: Mon, 08 Jan 2024 17:36:56 +0000 Subject: Re: Freebsd on M1 Macs From: Thomas Sparrevohn To: Kyle Evans , Message-ID: Thread-Topic: Freebsd on M1 Macs References: <7a13c63d-a50b-429c-a481-0693e9faaf6b@gmail.com> <1536d845-9073-4f9b-96f6-fa9647536c00@gmail.com> <3651f45a-a96a-4816-b8fe-5e239e08af22@FreeBSD.org> In-Reply-To: <3651f45a-a96a-4816-b8fe-5e239e08af22@FreeBSD.org> List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable X-Proofpoint-GUID: 7A71EiSVBMh2bkbL5Z2efoU0glrFfjaE X-Proofpoint-ORIG-GUID: 7A71EiSVBMh2bkbL5Z2efoU0glrFfjaE X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.272,Aquarius:18.0.997,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2024-01-08_07,2024-01-08_01,2023-05-22_02 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 spamscore=0 mlxlogscore=959 malwarescore=0 mlxscore=0 clxscore=1011 adultscore=0 suspectscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.19.0-2308100000 definitions=main-2401080149 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.20 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[me.com,quarantine]; RWL_MAILSPIKE_VERYGOOD(-0.20)[17.58.63.173:from]; R_SPF_ALLOW(-0.20)[+ip4:17.58.0.0/16]; R_DKIM_ALLOW(-0.20)[me.com:s=1a1hai]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[17.58.63.173:from]; ONCE_RECEIVED(0.10)[]; RCPT_COUNT_TWO(0.00)[2]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; ARC_NA(0.00)[]; FREEMAIL_FROM(0.00)[me.com]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; FREEMAIL_ENVFROM(0.00)[me.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[me.com:+]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:714, ipnet:17.58.63.0/24, country:US]; DWL_DNSWL_NONE(0.00)[me.com:dkim] X-Rspamd-Queue-Id: 4T81TV1vCqz4srp As I said to Joe in a previous post - I am personally quite impressed of ho= w easy it was go get up and running - granted it crashes with >8 Cores - but= Under parallels it ran well - making a very long term BSD user very very ha= ppy - Looking at both Linux and NetBSD - (NetBSD randomly freezes with >8 Co= res) but both seems doggy when it comes to how it handles efficiency cores. = What got me to go back to FreeBSD - was=20 A) I really miss it but since I got rid of my PC's there seems to be no opt= ion B) I do understand the codebase=20 C) Nobody seems to have a consistent approach to scheduling=20 E.g. Mac OS X uses QoS to control affinity, everybody else uses "affinity" = - but "setaffinity" seems like taking a hammer to the schedular - So I wante= d to understand. ARM as such is a bit of a mess in as much there are a very = varied number of CPU and designs - but at the same time this is why ARM is s= uch an interesting design. But Personally I am still a bit unsure what acron= ym or branding covers platform. Looking at two different - if somewhat exot= ic applications - E.g. A mainframe emulator and GNU APL who both hard relies= on the assumption that binding to a specific CPU will give you the best per= formance, personally I think that assumption is the intellectually the same = as running everything under rtprio - it seems that assumptions are being = made in the wild that will break once you have asymmetric CPU's - So I think= we - I mean the FreeBSD camp - has some work to do - If POSIX or others co= dify the state of "Now" we end up with the same mess as pthreads ended up be= ing.=20 After all that I really wanted to thank everybody who has worked on ARM for= allowing me to get back to having FreeBSD running on my daily workhorse - i= t's really a work well done Regards Thomas =20 =EF=BB=BFOn 26/11/2023, 23:52, "Kyle Evans" on behalf of kevans@FreeBSD.org > wrote: On 11/26/23 16:04, Jason Bacon wrote: > On 11/26/23 13:22, Joe B wrote: >> >> I know this is a longshot but I'm going to ask I know MacOS is a BSD=20 >> but we all know it's very sugarcoated and doesn't look like a BSD. >> >> Question will real freeBSD ever come to the m1 Mac's. I got a 16 inch=20 >> mbp with good specs just taking up space right now >> >> Thanks >> >> ~ Joe B >=20 > I assume you've seen https://wiki.freebsd.org/AppleSilicon . Not sure=20 > how up-to-date it is. The wikis tend to lag behind reality in my=20 > experience. >=20 Yeah, this is a bit out of date. SMP and watchdog bits are good, along=20 with some subset of the USB ports (IOMMU is a WIP). With the branch I'm=20 working on right now, we can go full multi-user on a USB root. Work stalled for a bit because there was a general disagreement with how we=20 integrated parts of the interrupt control into the interrupt framework,=20 but I've been given a vision recently of a clear path forward, so=20 hopefully we can move forward with that and unblock upstreaming some of=20 the other bits. Thanks, Kyle Evans From nobody Tue Jan 9 02:57:25 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4T8FwC2ptZz55n8Y for ; Tue, 9 Jan 2024 02:57:31 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (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 "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4T8Fw95TzZz4Zkl for ; Tue, 9 Jan 2024 02:57:29 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of fbsd@www.zefox.net has no SPF policy when checking 50.1.20.27) smtp.mailfrom=fbsd@www.zefox.net Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.17.1/8.15.2) with ESMTPS id 4092vPBH098477 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 8 Jan 2024 18:57:25 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.17.1/8.15.2/Submit) id 4092vPFY098476; Mon, 8 Jan 2024 18:57:25 -0800 (PST) (envelope-from fbsd) Date: Mon, 8 Jan 2024 18:57:25 -0800 From: bob prohaska To: Mark Millard Cc: Marcin Cieslak , freebsd-arm@freebsd.org Subject: Re: USB-serial adapter suggestions needed Message-ID: References: <7D27DF9F-AA9A-4D44-BC28-8CC637D0F550@yahoo.com> List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spamd-Bar: - X-Spamd-Result: default: False [-1.10 / 15.00]; AUTH_NA(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; WWW_DOT_DOMAIN(0.50)[]; MID_RHS_WWW(0.50)[]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; TO_DN_SOME(0.00)[]; MISSING_XM_UA(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; R_SPF_NA(0.00)[no SPF record]; R_DKIM_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; FREEMAIL_TO(0.00)[yahoo.com]; RCVD_COUNT_TWO(0.00)[2]; DMARC_NA(0.00)[zefox.net]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; RCPT_COUNT_THREE(0.00)[3] X-Rspamd-Queue-Id: 4T8Fw95TzZz4Zkl On Sun, Jan 07, 2024 at 08:48:36AM -0800, Mark Millard wrote: > > I meant that to be a general request to never reference just > RPi2B. The v1.1 vs. v1.2 was an unfortunate marketing naming > for the armv7 vs. aarch64 change that ends up needing such > extra text to give the proper context. Understood, since all Pi2's are v1.1 I'm more oblivious. I've added the config.txt files to the netmap at http://www.zefox.net/~fbsd/netmap In principle both /etc/rc.conf and /boot/loader.conf might be relevant, but adding them will increase clutter. Please indicate if it's more help than harm. I'm trying to hew to a policy of copy and paste intact, against the chance an errant typo or dropped # is the culprit. At this point powerd is not enabled in /etc/rc.conf on any host. Thanks for reading, and I hope the netmap makes the conversation easier to follow. If not, please say so. bob prohaska From nobody Tue Jan 9 04:27:19 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4T8Hw80hdBz564bs for ; Tue, 9 Jan 2024 04:27:36 +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.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4T8Hw73MWQz4mJl for ; Tue, 9 Jan 2024 04:27:35 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1704774453; bh=Igmub7Fzr8PbIuiOTEd4xqGpFzX1evk3ZEhSZwuVbvY=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=KSK5E/ZP4Qgl89fqNH5tKWYhLLOgqizoEkY54b6daqQVnI6eg+1cF/R8UD1R3MGc7+iO6kMzwRaNvLTocWQM05wWg8KET6ADfkE+uG9dqXofkzUCAfaHHCDYU9Q/DesmmugcGpFnDvTetFrkY8Y5+IBPvi/GnkFt7WuCxG+MrHGPt91bsLPtvyBoCUW4j9DHQBnOmLkv/WMwuKPLEHVX06k1sXVrOvZ0tOF1LW/mB4DfAL3AplZ3RvzhyPioIgIGY4I64a1f7sizcvp56yv4yS4ol01MJe1g6nUrH5fpimviRr7+HqGngcdpZs8vM5fV8npB3PCukpfr/Vbs0UPIQA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1704774453; bh=IuHs3DdVwCEYUlFfVqGkLK7zXvP9kFGOqqEPJ8kmHQo=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=TsQRaaHbdbNiwp8Qr/kMjsnB6zf71MUo+GmE3KyvvcKco8wKIUX0IVzva4r3aTem21BdCruqc5NIwKJkzzacisOFGzq43RR3xGjNmn9Ia3BILE7LH0IbZSxi8NMTdAXJNkQvgCcFqs50T9/GQD559hA85GJQZXe+H7GMFCYXBAj/zpfTZzgf+UzGR4ZPcZbyeB1snzkeIiKdVkBQ6pcPuSoAxJ6sKHN+X2m+8lU6BY0Zg68to0n3B2rHg6btUhpaM2CHABLMWbypvifwCte2kZMocy81f0AEpIAMk7Y8NlmdSvhmKql+YlYiPJGekHPqsXs3b4vPZoV+D4I8FsL5Eg== X-YMail-OSG: P8wE_JoVM1nLx7lMs_jgV1vSwbBuyS4Of4D.hcZ88L3nEksXJxXOhGuKgRGaz3H 6zSgHohfvDkxn5aRaTgftHRi1fWTIxwrh1ZS6DWDzCJudhtVeUsZRcrBrNhVxOt9Qvxs5Tcb3Gzd vFcoEqZQqTlq7lqdf46kdj5H5oIBkYzNOrx1V8y__uulrmgqpsokSG4G1U_vfetUqoLpjol51Wr4 MFd_gUIgByExmTsr8Sk6N4RTcgDWcCCKPrWK2yOiCyh5YtrYRvYdwt0mSPPp0y_3hWraI1z3Yz_p 3aj2.7HvJRx3GEjzCip8IvwyFJgek58Xhc57TqwMmXVvM7oQDxHwBjw3Pq9umE6vig1ZxPjs6Uhe wkGAdWiAxMpt4s1jmPQ36FaF8q0QwTRln8sB16lh_e_ZHHMVa1cr5bvwlINIEdml4WqJlsCAA9rt mECW_807H9Mmzp_h4mtRPSZ6ut2zgnoPbh9ckc3cjclJuWlrV7g5uf4Bu6I4I3INOZGnXVUCsZFI DuRhKAjd1j7iwfU53RVi69zLBo8Q.LcSVfhViYZGoc5KD2Uqk2YCIf.yTBkOp.oBz0.bpgNP_3cF P.tc_zXiLJawgqahag9qTQbIOhdvKfLh.0dVBnCJsAQ.yR5z6IiD6QL399zX4CGzpd5wU_0ysLuS Orye85Jz_AKEplTwLi86WT0LAfSw16EdyqFsVP9FozW.aPNRSCMa4uqF96Z73e19HfGRQNxZI..7 1jpvCzEIbmBfMipc9vEmeOsJiOBL_9qkeftF2JGGTHeJq6fPUnyF_BdILlCs9k0XpwdpMku9XEFG 0d3Sfp8sYlLxzk5pEZDIBjwGPXd0Nx3jOdwXAn7EKz6Nl75EStq7SlpvcCk4qU.vGFFzKepCS.UL ITJWdMQBUQFIIkbJFU91gk7ClOpT3Tm49X0MCbKRnjNuwmzWrJ7fG8TrBd7sK58aolCIK5AOHGkp IMJNvrZLbNzABpSEqhRD8nIZUP5k6c1pCzGU08S07thJLCPxEFv9BTZXrTwleTvYpU_lOcnGDQdQ P1EZkYwVQpoSRjRK03hwJDKz.aPmi6Qnmjt6cG2hswz1TDeA.NZ7RRuVUyW2eNx7z0Bv7Fx7EzUY TnAkjyG7aQYgW00QMgVz6yiU0.1YSB83FWtngcI63bvHvO8Oe_bCMCxkbZJBr6WxHN72JU0uw5Ge TnIhw0pXmuK877EiWpBJB9Z0JOie8_nvaofB.30LNUG8l7ZhUnXtYOosfW1VyqPQ_M7GdcVHD0ng oVD9msjTKJu9kDZlfneLpY2iGO1S19JM4wddcYXUmYTdJ_2SKQi_2LE0QTUhbz0wNNtAAXcHmLlL wNuxIS_pFzC82HrjNf4GwN.ud5MO6nAhSa0OJ0HZxNYt4C4iYAVW7paV5CXfJoWkbG._asQ5f9uR 2S0auQwYDzJOg55TJtZGq4sqmZ.CL.vEkDm_cFcfIfl2JXZ6l8IivAYZKQCAWCn0INBY_eAfoHMd 7riXvt0y_0Ku7LOjACxp6e_BMkVOyXUvy18KvUcSyZvx.32dnI00xVDoymi5w7FafKDXFxHoB7Zw trFQaw4Hx27JKgyF6JBSRrQ6DjGFCkf8HRqG2AS1lih90_QrjKnUMB0xc6zJOrm3sT81sTYMOOq2 Jr2ssaV0YJsnx5vwBXY6KisMyZwPR4R8q5OylqGc6Dx0EJKR3v3fmZOq0WAgHj.y8HYMLJu6rcJ0 QNwZGjhimeTkUc3htKXmSYb4M4v3TjyoskcWd1xJ6GuNdjgsLN1bB7I5QsOxaxl8qboRCLHoZj4L ezO5LMJMfR0jdXLs9pLfVqa_ycbhWIlU6U6YhrrIcadK9M4g4USOJNb3crXVVtPS942QQ9c9fSCt TvVdUtVs9dseSNuB_BMAB_KqFh6ZnXF.kkTV2Tmo8we7shLFVNrKEVxQsUGgfa2zi2fkOHbZYryH uppFBUxrEfQ.nxhYLY6TSoVxhrxYbHwsR8bmw1nkQcnVXvOKuSQNRVTjy5Wi3DQ9BPDohzKTmLXK 8UP.tp6B4_9pkZ72I2Pxd_R50ceKp42Ef4VXvaw5HFpK_MofOeg8peemyn15IK8oOBDwVqbLUNCw aSnpjj1741D0fqd2_OnJxak8tsnGfIRltuhUbBeErlCSeBsywm_MZThaDTRQ9PoPLCWtibwb6cJ4 COLgprzD3nOBGuS87_NUMiVATBVpja9sPCO17pN5_51DM8sFUVWY_byVWwI3eUAAfgYcEyG26rPw 1zie9UZZZrZNhUxfvqOL3FG3ulXO0uZX6kE9xrGTJD2Z_MzKSINSNVjsf2q4NGTd3GW9yTsY.fjk - X-Sonic-MF: X-Sonic-ID: bd54d662-b148-4889-9385-0f79bf49d2fd Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Tue, 9 Jan 2024 04:27:33 +0000 Received: by hermes--production-gq1-6949d6d8f9-c9pk7 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 90743029b20c22805477390769c21e3e; Tue, 09 Jan 2024 04:27:30 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.300.61.1.2\)) Subject: Re: USB-serial adapter suggestions needed From: Mark Millard In-Reply-To: Date: Mon, 8 Jan 2024 20:27:19 -0800 Cc: Marcin Cieslak , freebsd-arm@freebsd.org Content-Transfer-Encoding: 7bit Message-Id: References: <7D27DF9F-AA9A-4D44-BC28-8CC637D0F550@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3774.300.61.1.2) X-Rspamd-Queue-Id: 4T8Hw73MWQz4mJl X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] On Jan 8, 2024, at 18:57, bob prohaska wrote: > On Sun, Jan 07, 2024 at 08:48:36AM -0800, Mark Millard wrote: >> >> I meant that to be a general request to never reference just >> RPi2B. The v1.1 vs. v1.2 was an unfortunate marketing naming >> for the armv7 vs. aarch64 change that ends up needing such >> extra text to give the proper context. > > Understood, since all Pi2's are v1.1 I'm more oblivious. So all your RPi2B's are v1.1 and so must be used as armv7. Good to know. (Note FreeBSD's armv7 snapshots do not provide the .dtb for v1.2 or for RPi3B* 's . So booting as armv7 is not supported as the snapshots are configured.) > I've added the config.txt files to the netmap at > http://www.zefox.net/~fbsd/netmap Thanks much. If/when an experiment uses any adjusted/replaced config.txt , please be specific about the variation at the time. That includes if/when you make www.zefox.org (an aarch64) use the standard config.txt for aarch64 with force_mac_address added, instead of it being partially based on the armv7 config.txt . One thing still missing for the reporting of the specific recent experiment is: what was the powerd status of nemesis.zefox.com ? Always indicate the powerd status for the RPi*'s at both ends of the serial line involved in the failure (GIO end and tip end, making clear the exact association). > In principle both /etc/rc.conf and /boot/loader.conf might > be relevant, but adding them will increase clutter. As stands, I'm depending on your judgment about those files' full content being relevant or not. One thing that is relevant is the various powerd status's for each specific experimental variation's serial line(s) with a failure. One or more such files are likely involved in control of that status on each of the 2 RPi*'s involved. > Please > indicate if it's more help than harm. I'm trying to hew to > a policy of copy and paste intact, against the chance an > errant typo or dropped # is the culprit. > > At this point powerd is not enabled in /etc/rc.conf on > any host. But you earlier reported a failure involving the serial line between nemesis.zefox.com and www.zefox.org and reported that, for that experiment, www.zefox.org had powerd in use. You never indicated the powerd status for nemesis.zefox.com in that experiment that produced the failure. I still want to know what it was. > Thanks for reading, and I hope the netmap makes the > conversation easier to follow. Sure does avoid me having to guess at things. Thanks. > If not, please say so. I like the explicit extra information that you provided. === Mark Millard marklmi at yahoo.com From nobody Tue Jan 9 10:36:32 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4T8S671Bylz57413 for ; Tue, 9 Jan 2024 10:36:47 +0000 (UTC) (envelope-from soren.schmidt@gmail.com) Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (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 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4T8S66240Fz4Yhv for ; Tue, 9 Jan 2024 10:36:46 +0000 (UTC) (envelope-from soren.schmidt@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=UgEhN25N; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of soren.schmidt@gmail.com designates 2a00:1450:4864:20::12e as permitted sender) smtp.mailfrom=soren.schmidt@gmail.com Received: by mail-lf1-x12e.google.com with SMTP id 2adb3069b0e04-50eabbc3dccso2802040e87.2 for ; Tue, 09 Jan 2024 02:36:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704796604; x=1705401404; darn=freebsd.org; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=SygKvWvzEjLljys5EXVoC9J5fxVrmtCOq2Jl1uNMb2g=; b=UgEhN25NnKXLA3ByRqGfhKtfwl8IQ2trk3OrxgEuhhVL7chtbLCx4IG1J9HnvvD9dg igvJhvxUK81p/rTMg1sBLubiBFyfd5siH+aW10k5ShqoBgFDFjvdtP66SAk5/kpfem8O 5pODl5g/M6a3N6UGw6U3gQwST+TfK4n7p8fUFYESB2LobSgRvGW5hx0vKuxkz1n1Z5EB L3i9vjCofbfg3jvf7mrsVNSnJUkaE4mt42mg+Mv+Djh3GU+kNU0cG5iJi9eL1z2a492+ hOgk9RGH35iKeclhthB5PxroNqE1TXeoRat65Vu6NyVb7YYqyvJ06S7Otk0P3BlfHW6/ 3VHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704796604; x=1705401404; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=SygKvWvzEjLljys5EXVoC9J5fxVrmtCOq2Jl1uNMb2g=; b=xTGEJ7zw+2Ft2GdHNEHBoMm48M2OsWVx+eFah02YAMFPNM/nK4UjVZoKhAtqAzw3Kc 2xCj2abqHH1t807ig2whE/URFNAivtnQIb3hUquWyN2F1XV23/icPLH9Ox/8c7YvGJfU hii7tkoBaKqhWjAIdjxQXufZ/CcP7BsbKca6C0lADlND9WGkvwzqLoMJ65rHSf4ib0vC Rl/5C5OmMqjVdHFfs7rpddrjK0eVyGBFJ0MfXkX+sN21rfALzQKu/e2EGEkoyAjaoGPZ Vb/Uc1MrNYDzZWK0gpdQ675WD8fDPl4hrtQyUItMVIOdLTJL8yynIrdu/0I1Pzi1L1CH wQnw== X-Gm-Message-State: AOJu0YzUzH1kBqm6Y2RxdMk5RZzqS4Y2tUeAXohoC21InTanaornuRTT JMd9/Emafc6+rlaGiRzDsu6/mKXEK7c= X-Google-Smtp-Source: AGHT+IHFjZYlWefabFkZ1wCCluSW3TgNfFJeOHZpDHg1syOXhfp2es569hgX3LA4VMv0giuH98OosQ== X-Received: by 2002:a05:6512:b14:b0:50e:6f89:a149 with SMTP id w20-20020a0565120b1400b0050e6f89a149mr1418734lfu.11.1704796603390; Tue, 09 Jan 2024 02:36:43 -0800 (PST) Received: from smtpclient.apple ([85.27.186.9]) by smtp.gmail.com with ESMTPSA id dc9-20020a170906c7c900b00a2a4bd50588sm894062ejb.147.2024.01.09.02.36.42 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 Jan 2024 02:36:42 -0800 (PST) From: =?utf-8?Q?S=C3=B8ren_Schmidt?= Message-Id: <49DE81A1-7DF5-48BF-A334-961A73B91E53@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_F8AECE7F-C308-49AB-AE34-8F2C3C2992E6" List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\)) Subject: Re: MMCCAM hang Date: Tue, 9 Jan 2024 11:36:32 +0100 In-Reply-To: Cc: "Bjoern A. Zeeb" , Warner Losh To: "freebsd-arm@freebsd.org" References: X-Mailer: Apple Mail (2.3731.700.6) X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.16 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.997]; R_MIXED_CHARSET(0.83)[subject]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCVD_TLS_LAST(0.00)[]; TAGGED_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; TO_DN_EQ_ADDR_SOME(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_SOME(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::12e:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; APPLE_MAILER_COMMON(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-Rspamd-Queue-Id: 4T8S66240Fz4Yhv --Apple-Mail=_F8AECE7F-C308-49AB-AE34-8F2C3C2992E6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 28 Dec 2023, at 02.08, Warner Losh wrote: > On Wed, Dec 27, 2023, 4:55=E2=80=AFPM Bjoern A. Zeeb = > = wrote: >> Hi, >>=20 >> sdhci_fsl_fdt0: Desired SD/MMC freq: 50000000, actual: 50000000; base = 700000000 prescale 1 divisor 14 >> GEOM: new disk sdda0 >> sdda0 at sdhci_slot0 bus 0 scbus0 target 0 lun 0 >> sdda0: Relative addr: 00000002 >> Card features: >> Card random: unblocking device. >> GEOM: new disk sdda0boot0 >> memory OCR: 00ff8080 >> sdda0: Serial Number ....... >> sdda0: MMCHC .................................. by 17 0x0000 >> GEOM: new disk sdda0boot1 >> uhub0: 2 ports with 2 removable, self powered >>=20 >> at which point basically anything hangs. In auto-boot it is >> before/during file-system checks. >> In single user mode camcontrol devlist will show sdda0 >> but >>=20 >> root@:/ # gpart show sdda0 >> load: 6.06 cmd: gpart 24 [g_waitfor_event] 1.28r 0.00u 0.00s 0% = 2088k >> {forever} >>=20 >>=20 >> Unclear at which point I broke to debugger and this is where it seems = to >> hang: >>=20 >> db> trace 100088 >> Tracing pid 4 tid 100088 td 0xffff0000dc527000 >> ipi_stop() at ipi_stop+0x34 >> arm_gic_v3_intr() at arm_gic_v3_intr+0xe4 >> intr_irq_handler() at intr_irq_handler+0x80 >> handle_el1h_irq() at handle_el1h_irq+0x14 >> --- interrupt >> spinlock_exit() at spinlock_exit+0x44 >> callout_reset_sbt_on() at callout_reset_sbt_on+0x210 >> sdhci_cam_action() at sdhci_cam_action+0x284 >> xpt_run_devq() at xpt_run_devq+0x4c8 >> xpt_action_default() at xpt_action_default+0x470 >> sddastart() at sddastart+0x1bc >> xpt_run_allocq() at xpt_run_allocq+0xa8 >> xpt_done_process() at xpt_done_process+0x610 >> xpt_done_td() at xpt_done_td+0x1a8 >> fork_exit() at fork_exit+0x8c >> fork_trampoline() at fork_trampoline+0x18 >>=20 >>=20 >> Anyone an idea? >=20 >=20 >=20 > Looks like deadlock with another thread. Anybody else in the time = keeping / callout code? I think this is related to the MMC driver having issues (MMCCAM or not). If I try to use a MMC sdcard on any of my rk35X8 boards as the disk = device it will eventually hang on first access to the MMC controlled = media. I thought I had an issue here with my dev setup but clealy I'm not alone = :) -- S=C3=B8ren Schmidt sos@deepcore.dk / sos@freebsd.org "So much code to hack, so little time" --Apple-Mail=_F8AECE7F-C308-49AB-AE34-8F2C3C2992E6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 28 Dec 2023, = at 02.08, Warner Losh <imp@bsdimp.com> wrote:
On Wed, Dec 27, 2023, 4:55=E2=80=AFPM Bjoern A. = Zeeb <bzeeb-lists@lists.zabbadoz.= net> wrote:
Hi,

sdhci_fsl_fdt0: Desired SD/MMC freq: = 50000000, actual: 50000000; base 700000000 prescale 1 divisor = 14
GEOM: new disk sdda0
sdda0 at sdhci_slot0 bus 0 scbus0 target 0 = lun 0
sdda0: Relative addr: 00000002
Card features: <MMC Memory = High-Capacity>
Card random: unblocking device.
GEOM: new disk = sdda0boot0
memory OCR: 00ff8080
sdda0: Serial Number = .......
sdda0: MMCHC .................................. by 17 = 0x0000
GEOM: new disk sdda0boot1
uhub0: 2 ports with 2 removable, = self powered

at which point basically anything hangs.  In = auto-boot it is
before/during file-system checks.
In single user = mode camcontrol devlist will show sdda0
but

root@:/ # gpart = show sdda0
load: 6.06  cmd: gpart 24 [g_waitfor_event] 1.28r = 0.00u 0.00s 0% 2088k
{forever}


Unclear at which point I = broke to debugger and this is where it seems to
hang:

db> = trace 100088
Tracing pid 4 tid 100088 td = 0xffff0000dc527000
ipi_stop() at ipi_stop+0x34
arm_gic_v3_intr() = at arm_gic_v3_intr+0xe4
intr_irq_handler() at = intr_irq_handler+0x80
handle_el1h_irq() at = handle_el1h_irq+0x14
--- interrupt
spinlock_exit() at = spinlock_exit+0x44
callout_reset_sbt_on() at = callout_reset_sbt_on+0x210
sdhci_cam_action() at = sdhci_cam_action+0x284
xpt_run_devq() at = xpt_run_devq+0x4c8
xpt_action_default() at = xpt_action_default+0x470
sddastart() at = sddastart+0x1bc
xpt_run_allocq() at = xpt_run_allocq+0xa8
xpt_done_process() at = xpt_done_process+0x610
xpt_done_td() at = xpt_done_td+0x1a8
fork_exit() at fork_exit+0x8c
fork_trampoline() = at fork_trampoline+0x18


Anyone an = idea?


Looks like deadlock with = another thread. Anybody else in the time keeping / callout = code?

I think this is = related to the MMC driver having issues (MMCCAM or not).
If I = try to use a MMC sdcard on any of my rk35X8 boards as the disk device it = will eventually hang on first access to the MMC controlled = media.
I thought I had an issue here with my dev setup but = clealy I'm not alone :)

--
S=C3=B8ren = Schmidt
sos@deepcore.dk / sos@freebsd.org
"So much code to hack, so little = time"

= --Apple-Mail=_F8AECE7F-C308-49AB-AE34-8F2C3C2992E6-- From nobody Tue Jan 9 10:48:22 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4T8SMk5f2Yz575bT for ; Tue, 9 Jan 2024 10:48:34 +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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4T8SMj4DJvz4btv for ; Tue, 9 Jan 2024 10:48:33 +0000 (UTC) (envelope-from manu@bidouilliste.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bidouilliste.com header.s=mx header.b=ejIS2mL9; 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 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bidouilliste.com; s=mx; t=1704797306; 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=ZjqnPNveXPNohhbd8fOHP9skfXwRVIsC9gAPxHjVbuw=; b=ejIS2mL9Eao425sDRxAzwDv6qo936Ad7RiqkiqyewvQjyIFMKVtx9C260XRhBjFQPKLp5J gjuTWjVw+elOTmRcCBXPyarHIXzF3csipg9NiPY2Z5LhsdmecY1uON5+mU9rtEjoW/Wp2g w4C9FclvoKAAXZDZE10iB3G3BjgCU/E= Received: from skull.home.blih.net (lfbn-lyo-1-2174-135.w90-66.abo.wanadoo.fr [90.66.97.135]) by mx.blih.net (OpenSMTPD) with ESMTPSA id b5e76d5c (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Tue, 9 Jan 2024 10:48:26 +0000 (UTC) Date: Tue, 9 Jan 2024 11:48:22 +0100 From: Emmanuel Vadot To: =?ISO-8859-1?Q?S=F8ren?= Schmidt Cc: "freebsd-arm@freebsd.org" , "Bjoern A. Zeeb" , Warner Losh Subject: Re: MMCCAM hang Message-Id: <20240109114822.522d91fea8cf170af4d895b7@bidouilliste.com> In-Reply-To: <49DE81A1-7DF5-48BF-A334-961A73B91E53@gmail.com> References: <49DE81A1-7DF5-48BF-A334-961A73B91E53@gmail.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd15.0) List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: - X-Spamd-Result: default: False [-1.90 / 15.00]; SUSPICIOUS_RECIPS(1.50)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[bidouilliste.com,none]; MV_CASE(0.50)[]; R_DKIM_ALLOW(-0.20)[bidouilliste.com:s=mx]; R_SPF_ALLOW(-0.20)[+ip4:212.83.155.74/32]; ONCE_RECEIVED(0.10)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_EQ_ADDR_SOME(0.00)[]; DKIM_TRACE(0.00)[bidouilliste.com:+]; ARC_NA(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; FREEMAIL_TO(0.00)[gmail.com]; FROM_HAS_DN(0.00)[]; ASN(0.00)[asn:12876, ipnet:212.83.128.0/19, country:FR]; FREEFALL_USER(0.00)[manu]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TAGGED_RCPT(0.00)[]; MIME_TRACE(0.00)[0:+]; TO_DN_SOME(0.00)[] X-Rspamd-Queue-Id: 4T8SMj4DJvz4btv On Tue, 9 Jan 2024 11:36:32 +0100 S=F8ren Schmidt wrote: > > On 28 Dec 2023, at 02.08, Warner Losh wrote: > > On Wed, Dec 27, 2023, 4:55?PM Bjoern A. Zeeb > wrote: > >> Hi, > >>=20 > >> sdhci_fsl_fdt0: Desired SD/MMC freq: 50000000, actual: 50000000; base = 700000000 prescale 1 divisor 14 > >> GEOM: new disk sdda0 > >> sdda0 at sdhci_slot0 bus 0 scbus0 target 0 lun 0 > >> sdda0: Relative addr: 00000002 > >> Card features: > >> Card random: unblocking device. > >> GEOM: new disk sdda0boot0 > >> memory OCR: 00ff8080 > >> sdda0: Serial Number ....... > >> sdda0: MMCHC .................................. by 17 0x0000 > >> GEOM: new disk sdda0boot1 > >> uhub0: 2 ports with 2 removable, self powered > >>=20 > >> at which point basically anything hangs. In auto-boot it is > >> before/during file-system checks. > >> In single user mode camcontrol devlist will show sdda0 > >> but > >>=20 > >> root@:/ # gpart show sdda0 > >> load: 6.06 cmd: gpart 24 [g_waitfor_event] 1.28r 0.00u 0.00s 0% 2088k > >> {forever} > >>=20 > >>=20 > >> Unclear at which point I broke to debugger and this is where it seems = to > >> hang: > >>=20 > >> db> trace 100088 > >> Tracing pid 4 tid 100088 td 0xffff0000dc527000 > >> ipi_stop() at ipi_stop+0x34 > >> arm_gic_v3_intr() at arm_gic_v3_intr+0xe4 > >> intr_irq_handler() at intr_irq_handler+0x80 > >> handle_el1h_irq() at handle_el1h_irq+0x14 > >> --- interrupt > >> spinlock_exit() at spinlock_exit+0x44 > >> callout_reset_sbt_on() at callout_reset_sbt_on+0x210 > >> sdhci_cam_action() at sdhci_cam_action+0x284 > >> xpt_run_devq() at xpt_run_devq+0x4c8 > >> xpt_action_default() at xpt_action_default+0x470 > >> sddastart() at sddastart+0x1bc > >> xpt_run_allocq() at xpt_run_allocq+0xa8 > >> xpt_done_process() at xpt_done_process+0x610 > >> xpt_done_td() at xpt_done_td+0x1a8 > >> fork_exit() at fork_exit+0x8c > >> fork_trampoline() at fork_trampoline+0x18 > >>=20 > >>=20 > >> Anyone an idea? > >=20 > >=20 > >=20 > > Looks like deadlock with another thread. Anybody else in the time keepi= ng / callout code? >=20 > I think this is related to the MMC driver having issues (MMCCAM or not). > If I try to use a MMC sdcard on any of my rk35X8 boards as the disk devic= e it will eventually hang on first access to the MMC controlled media. > I thought I had an issue here with my dev setup but clealy I'm not alone = :) SDCard on RK356X don't use sdhci but dwmmc so it's not related to what bz@ is seeing. That being said I have no problem using dwmmc as the root device on my nanopi r5s or quartz64. --=20 Emmanuel Vadot From nobody Tue Jan 9 16:12:09 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4T8bYN0wv5z55lM5 for ; Tue, 9 Jan 2024 16:12:24 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (cross.sbone.de [195.201.62.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE Root Certificate Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4T8bYM4sZcz45m3 for ; Tue, 9 Jan 2024 16:12:23 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Authentication-Results: mx1.freebsd.org; none Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:1025]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id B5FD98D4A162; Tue, 9 Jan 2024 16:12:13 +0000 (UTC) Received: from content-filter.t4-02.sbone.de (content-filter.t4-02.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:2742]) (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) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 0EA5D2D029D8; Tue, 9 Jan 2024 16:12:13 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:4902:0:7404:2:1025]) by content-filter.t4-02.sbone.de (content-filter.t4-02.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:2742]) (amavisd-new, port 10024) with ESMTP id xPjWUGVFP7YD; Tue, 9 Jan 2024 16:12:11 +0000 (UTC) Received: from strong-aiccu0.sbone.de (strong-aiccu0.sbone.de [IPv6:fde9:577b:c1a9:f491::2]) (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) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 193332D029D7; Tue, 9 Jan 2024 16:12:10 +0000 (UTC) Date: Tue, 9 Jan 2024 16:12:09 +0000 (UTC) From: "Bjoern A. Zeeb" To: Emmanuel Vadot cc: =?UTF-8?Q?S=C3=B8ren_Schmidt?= , "freebsd-arm@freebsd.org" , Warner Losh Subject: Re: MMCCAM hang In-Reply-To: <20240109114822.522d91fea8cf170af4d895b7@bidouilliste.com> Message-ID: <5299p2p7-4r17-7o65-3569-o4pn3pq8r597@yvfgf.mnoonqbm.arg> References: <49DE81A1-7DF5-48BF-A334-961A73B91E53@gmail.com> <20240109114822.522d91fea8cf170af4d895b7@bidouilliste.com> X-OpenPGP-Key-Id: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="1098556516-622069581-1704816731=:2837" X-Rspamd-Queue-Id: 4T8bYM4sZcz45m3 X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_RCPT(0.00)[]; ASN(0.00)[asn:24940, ipnet:195.201.0.0/16, country:DE] This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1098556516-622069581-1704816731=:2837 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT On Tue, 9 Jan 2024, Emmanuel Vadot wrote: > On Tue, 9 Jan 2024 11:36:32 +0100 > Søren Schmidt wrote: > >>> On 28 Dec 2023, at 02.08, Warner Losh wrote: >>> On Wed, Dec 27, 2023, 4:55?PM Bjoern A. Zeeb > wrote: >>>> Hi, >>>> >>>> sdhci_fsl_fdt0: Desired SD/MMC freq: 50000000, actual: 50000000; base 700000000 prescale 1 divisor 14 >>>> GEOM: new disk sdda0 >>>> sdda0 at sdhci_slot0 bus 0 scbus0 target 0 lun 0 >>>> sdda0: Relative addr: 00000002 >>>> Card features: >>>> Card random: unblocking device. >>>> GEOM: new disk sdda0boot0 >>>> memory OCR: 00ff8080 >>>> sdda0: Serial Number ....... >>>> sdda0: MMCHC .................................. by 17 0x0000 >>>> GEOM: new disk sdda0boot1 >>>> uhub0: 2 ports with 2 removable, self powered >>>> >>>> at which point basically anything hangs. In auto-boot it is >>>> before/during file-system checks. >>>> In single user mode camcontrol devlist will show sdda0 >>>> but >>>> >>>> root@:/ # gpart show sdda0 >>>> load: 6.06 cmd: gpart 24 [g_waitfor_event] 1.28r 0.00u 0.00s 0% 2088k >>>> {forever} >>>> >>>> >>>> Unclear at which point I broke to debugger and this is where it seems to >>>> hang: >>>> >>>> db> trace 100088 >>>> Tracing pid 4 tid 100088 td 0xffff0000dc527000 >>>> ipi_stop() at ipi_stop+0x34 >>>> arm_gic_v3_intr() at arm_gic_v3_intr+0xe4 >>>> intr_irq_handler() at intr_irq_handler+0x80 >>>> handle_el1h_irq() at handle_el1h_irq+0x14 >>>> --- interrupt >>>> spinlock_exit() at spinlock_exit+0x44 >>>> callout_reset_sbt_on() at callout_reset_sbt_on+0x210 >>>> sdhci_cam_action() at sdhci_cam_action+0x284 >>>> xpt_run_devq() at xpt_run_devq+0x4c8 >>>> xpt_action_default() at xpt_action_default+0x470 >>>> sddastart() at sddastart+0x1bc >>>> xpt_run_allocq() at xpt_run_allocq+0xa8 >>>> xpt_done_process() at xpt_done_process+0x610 >>>> xpt_done_td() at xpt_done_td+0x1a8 >>>> fork_exit() at fork_exit+0x8c >>>> fork_trampoline() at fork_trampoline+0x18 >>>> >>>> >>>> Anyone an idea? >>> >>> >>> >>> Looks like deadlock with another thread. Anybody else in the time keeping / callout code? >> >> I think this is related to the MMC driver having issues (MMCCAM or not). >> If I try to use a MMC sdcard on any of my rk35X8 boards as the disk device it will eventually hang on first access to the MMC controlled media. >> I thought I had an issue here with my dev setup but clealy I'm not alone :) > > SDCard on RK356X don't use sdhci but dwmmc so it's not related to what > bz@ is seeing. > That being said I have no problem using dwmmc as the root device on my > nanopi r5s or quartz64. For what is worth my current feeling seems to be it is related to the boot[01] disks on the eMMC. I see geom tasting on boot0 but the consumer for boot1 never shows up in ddb> show geom I disabled the graid and then the same observation moved on to gpart. Also once the error starts the fsl is never ecovering; eventually the ccb and curcmd stay the same pointers even. It seems to just roto-tile, which makes me wonder if some error propagation is missing/gone. If I enable kern.cam.boot_delay="30000" and have my root on an md(4) I get to Login: -- strangely but then the nda and the sdda show up and then typing gpart show or whatever else geom-ish a few commands go through and then we are in the error again. I haven't been able to dig much further; no other locks held in debug kernels (just a malloc WAITOK complaint early on during "attach"). I'd still be happy to hear for more possible cases; especially if other sdhci devices are working with MMCCAM? It kept me from doing the actual work I wanted to do with mmccam over the holidays sadly. Feature request: somehow I wished we could enable/disable FDT/OFW based devices like we do for PCI with devctl ... can we? Like have it disabled in FDT at boot but later enable/probe/attach... With SD cards and dwmmc I had mostly mixed results in the past; they worked for quite a while but after 600 days of uptime they were gone (problem probably long fixed but I am at 900 days now for the last running RK device and then won't bother for a long while I hope). -- Bjoern A. Zeeb r15:7 --1098556516-622069581-1704816731=:2837-- From nobody Tue Jan 9 16:48:53 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4T8cMb6JcSz55rvC for ; Tue, 9 Jan 2024 16:48:59 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (cross.sbone.de [195.201.62.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE Root Certificate Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4T8cMZ6T8Zz4DJF for ; Tue, 9 Jan 2024 16:48:58 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of bzeeb-lists@lists.zabbadoz.net designates 195.201.62.131 as permitted sender) smtp.mailfrom=bzeeb-lists@lists.zabbadoz.net Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:1025]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 120488D4A162; Tue, 9 Jan 2024 16:48:57 +0000 (UTC) Received: from content-filter.t4-02.sbone.de (content-filter.t4-02.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:2742]) (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) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 6B1E42D029D8; Tue, 9 Jan 2024 16:48:56 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:4902:0:7404:2:1025]) by content-filter.t4-02.sbone.de (content-filter.t4-02.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:2742]) (amavisd-new, port 10024) with ESMTP id EjB6XUo2L_p7; Tue, 9 Jan 2024 16:48:55 +0000 (UTC) Received: from strong-aiccu0.sbone.de (strong-aiccu0.sbone.de [IPv6:fde9:577b:c1a9:f491::2]) (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) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 9C4A02D029D7; Tue, 9 Jan 2024 16:48:54 +0000 (UTC) Date: Tue, 9 Jan 2024 16:48:53 +0000 (UTC) From: "Bjoern A. Zeeb" To: Emmanuel Vadot cc: =?UTF-8?Q?S=C3=B8ren_Schmidt?= , "freebsd-arm@freebsd.org" , Warner Losh Subject: Re: MMCCAM hang In-Reply-To: <5299p2p7-4r17-7o65-3569-o4pn3pq8r597@yvfgf.mnoonqbm.arg> Message-ID: <084r150q-076r-9rpn-89p2-87osq1p82orp@yvfgf.mnoonqbm.arg> References: <49DE81A1-7DF5-48BF-A334-961A73B91E53@gmail.com> <20240109114822.522d91fea8cf170af4d895b7@bidouilliste.com> <5299p2p7-4r17-7o65-3569-o4pn3pq8r597@yvfgf.mnoonqbm.arg> X-OpenPGP-Key-Id: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="1098556516-899724204-1704818935=:2837" X-Spamd-Bar: / X-Spamd-Result: default: False [-0.80 / 15.00]; SUSPICIOUS_RECIPS(1.50)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; CTYPE_MIXED_BOGUS(1.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_SPF_ALLOW(-0.20)[+ip4:195.201.62.131]; MIME_GOOD(-0.10)[multipart/mixed,text/plain]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; ARC_NA(0.00)[]; MISSING_XM_UA(0.00)[]; ASN(0.00)[asn:24940, ipnet:195.201.0.0/16, country:DE]; MIME_TRACE(0.00)[0:+,1:+]; FROM_HAS_DN(0.00)[]; R_DKIM_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_CC(0.00)[gmail.com,freebsd.org,bsdimp.com]; TAGGED_RCPT(0.00)[]; RCVD_TLS_LAST(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; DMARC_NA(0.00)[zabbadoz.net]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; RCPT_COUNT_THREE(0.00)[4] X-Rspamd-Queue-Id: 4T8cMZ6T8Zz4DJF This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1098556516-899724204-1704818935=:2837 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT On Tue, 9 Jan 2024, Bjoern A. Zeeb wrote: > On Tue, 9 Jan 2024, Emmanuel Vadot wrote: > >> On Tue, 9 Jan 2024 11:36:32 +0100 >> Søren Schmidt wrote: >> >>>> On 28 Dec 2023, at 02.08, Warner Losh wrote: >>>> On Wed, Dec 27, 2023, 4:55?PM Bjoern A. Zeeb >>>> > >>>> wrote: >>>>> Hi, >>>>> >>>>> sdhci_fsl_fdt0: Desired SD/MMC freq: 50000000, actual: 50000000; base >>>>> 700000000 prescale 1 divisor 14 >>>>> GEOM: new disk sdda0 >>>>> sdda0 at sdhci_slot0 bus 0 scbus0 target 0 lun 0 >>>>> sdda0: Relative addr: 00000002 >>>>> Card features: >>>>> Card random: unblocking device. >>>>> GEOM: new disk sdda0boot0 >>>>> memory OCR: 00ff8080 >>>>> sdda0: Serial Number ....... >>>>> sdda0: MMCHC .................................. by 17 0x0000 >>>>> GEOM: new disk sdda0boot1 >>>>> uhub0: 2 ports with 2 removable, self powered >>>>> >>>>> at which point basically anything hangs. In auto-boot it is >>>>> before/during file-system checks. >>>>> In single user mode camcontrol devlist will show sdda0 >>>>> but >>>>> >>>>> root@:/ # gpart show sdda0 >>>>> load: 6.06 cmd: gpart 24 [g_waitfor_event] 1.28r 0.00u 0.00s 0% 2088k >>>>> {forever} >>>>> >>>>> >>>>> Unclear at which point I broke to debugger and this is where it seems to >>>>> hang: >>>>> >>>>> db> trace 100088 >>>>> Tracing pid 4 tid 100088 td 0xffff0000dc527000 >>>>> ipi_stop() at ipi_stop+0x34 >>>>> arm_gic_v3_intr() at arm_gic_v3_intr+0xe4 >>>>> intr_irq_handler() at intr_irq_handler+0x80 >>>>> handle_el1h_irq() at handle_el1h_irq+0x14 >>>>> --- interrupt >>>>> spinlock_exit() at spinlock_exit+0x44 >>>>> callout_reset_sbt_on() at callout_reset_sbt_on+0x210 >>>>> sdhci_cam_action() at sdhci_cam_action+0x284 >>>>> xpt_run_devq() at xpt_run_devq+0x4c8 >>>>> xpt_action_default() at xpt_action_default+0x470 >>>>> sddastart() at sddastart+0x1bc >>>>> xpt_run_allocq() at xpt_run_allocq+0xa8 >>>>> xpt_done_process() at xpt_done_process+0x610 >>>>> xpt_done_td() at xpt_done_td+0x1a8 >>>>> fork_exit() at fork_exit+0x8c >>>>> fork_trampoline() at fork_trampoline+0x18 >>>>> >>>>> >>>>> Anyone an idea? >>>> >>>> >>>> >>>> Looks like deadlock with another thread. Anybody else in the time keeping >>>> / callout code? >>> >>> I think this is related to the MMC driver having issues (MMCCAM or not). >>> If I try to use a MMC sdcard on any of my rk35X8 boards as the disk device >>> it will eventually hang on first access to the MMC controlled media. >>> I thought I had an issue here with my dev setup but clealy I'm not alone >>> :) >> >> SDCard on RK356X don't use sdhci but dwmmc so it's not related to what >> bz@ is seeing. >> That being said I have no problem using dwmmc as the root device on my >> nanopi r5s or quartz64. > > For what is worth my current feeling seems to be it is related to the > boot[01] disks on the eMMC. okay, I quickly tried the funny bit to skip them (no disk created). Th errors from the sdda stopped after about 25-ish times. I didn't check the commands if they were the same. But now it looks like this: # ls -l /dev/*da* crw-r----- 1 root operator 0x50 Dec 19 10:32 /dev/nda0 crw-r----- 1 root operator 0x55 Dec 19 10:32 /dev/sdda0 # gpart show sdda0 gpart: No such geom: sdda0. # gpart show nda0 gpart: No such geom: nda0. # gpart create -s GPT -l 67108864 sdda0 # -l is from D33168 and not the issue here sdhci_fsl_fdt0-slot0: sdhci_cam_request: ccb 0 ccb 0xffffa0000e440800 curcmd 0 req 0 sdhci_fsl_fdt0-slot0: sdhci_start_command: curcmd 0 cmd 0xffffa0000e4408d0 cmd_done 1 flags 0x000035 sdhci_fsl_fdt0-slot0: sdhci_req_done: curcmd 0xffffa0000e4408d0 ccb 0xffffa0000e440800 cmd_done 1 cmd.flags 0x000035 cmd.error 1 gpart: Input/output error # gpart create -s GPT sdda0 gpart: geom 'sdda0': File exists # gpart show sdda0 => 131104 122011576 sdda0 GPT (58G) 131104 122011576 - free - (58G) # shutdown -r now ... Login: ... # gpart show sdda0 gpart: No such geom: sdda0. Something obviously non-obvious must be strange here. I should try another device though I know this works under Linux. Should I try legacy mmc again? > I see geom tasting on boot0 but the consumer for boot1 never shows up in > ddb> show geom > I disabled the graid and then the same observation moved on to gpart. > > Also once the error starts the fsl is never ecovering; eventually the > ccb and curcmd stay the same pointers even. It seems to just roto-tile, > which makes me wonder if some error propagation is missing/gone. > > If I enable kern.cam.boot_delay="30000" and have my root on an md(4) > I get to Login: -- strangely but then the nda and the sdda show up and > then typing gpart show or whatever else geom-ish a few commands go > through and then we are in the error again. > > I haven't been able to dig much further; no other locks held in debug > kernels (just a malloc WAITOK complaint early on during "attach"). > > I'd still be happy to hear for more possible cases; especially if other > sdhci devices are working with MMCCAM? It kept me from doing the actual > work I wanted to do with mmccam over the holidays sadly. > > > Feature request: somehow I wished we could enable/disable FDT/OFW based > devices like we do for PCI with devctl ... can we? Like have it > disabled in FDT at boot but later enable/probe/attach... > > > With SD cards and dwmmc I had mostly mixed results in the past; they > worked for quite a while but after 600 days of uptime they were gone > (problem probably long fixed but I am at 900 days now for the last > running RK device and then won't bother for a long while I hope). > > -- Bjoern A. Zeeb r15:7 --1098556516-899724204-1704818935=:2837-- From nobody Tue Jan 9 17:40:00 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4T8dVR3J3bz561p3 for ; Tue, 9 Jan 2024 17:39:59 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (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 "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4T8dVR0Hmyz4M3b for ; Tue, 9 Jan 2024 17:39:58 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Authentication-Results: mx1.freebsd.org; none Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.17.1/8.15.2) with ESMTPS id 409He08i001189 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 9 Jan 2024 09:40:00 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.17.1/8.15.2/Submit) id 409He0xf001188; Tue, 9 Jan 2024 09:40:00 -0800 (PST) (envelope-from fbsd) Date: Tue, 9 Jan 2024 09:40:00 -0800 From: bob prohaska To: Mark Millard Cc: freebsd-arm@freebsd.org Subject: Re: USB-serial adapter suggestions needed Message-ID: References: <7D27DF9F-AA9A-4D44-BC28-8CC637D0F550@yahoo.com> List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4T8dVR0Hmyz4M3b X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US] On Mon, Jan 08, 2024 at 08:27:19PM -0800, Mark Millard wrote: > > So all your RPi2B's are v1.1 and so must be used as armv7. > Good to know. > > > > I've added the config.txt files to the netmap at > > http://www.zefox.net/~fbsd/netmap > > Thanks much. > > If/when an experiment uses any adjusted/replaced config.txt , > please be specific about the variation at the time. That > includes if/when you make www.zefox.org (an aarch64) use > the standard config.txt for aarch64 with force_mac_address > added, instead of it being partially based on the armv7 > config.txt . > > One thing still missing for the reporting of the specific > recent experiment is: what was the powerd status of > nemesis.zefox.com ? Always indicate the powerd status for > the RPi*'s at both ends of the serial line involved in the > failure (GIO end and tip end, making clear the exact > association). > At that time nemesis.zefox.com was running powerd, enabled in /etc/rc.conf. Now that line is commented out on all hosts. It might be relevant that on www.zefox.org, the terminal server to nemesis, powerd was run manually using powerd -a adp, not via an entry in /etc/rc.conf . The two appear similar, but perhaps not identical for the Pi . For now all hosts run with powerd off in an attempt to re-establish baseline behavior. Could Apache or something like it be configured to allow live, remote examination of the hosts in the tests? Making config or static log files accessible seems fairly easy, dynamic status looks more difficult. At this point my own reporting errors/omissions are a significant hazard to any investigation. Thanks for all your help! bob prohaska From nobody Tue Jan 9 20:56:59 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4T8jsw0KKGz56MJx for ; Tue, 9 Jan 2024 20:57:08 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (cross.sbone.de [195.201.62.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE Root Certificate Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4T8jst6mr3z3x3b for ; Tue, 9 Jan 2024 20:57:06 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of bzeeb-lists@lists.zabbadoz.net designates 195.201.62.131 as permitted sender) smtp.mailfrom=bzeeb-lists@lists.zabbadoz.net Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:1025]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 935428D4A162; Tue, 9 Jan 2024 20:57:02 +0000 (UTC) Received: from content-filter.t4-02.sbone.de (content-filter.t4-02.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:2742]) (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) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 3857F2D029D8; Tue, 9 Jan 2024 20:57:02 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:4902:0:7404:2:1025]) by content-filter.t4-02.sbone.de (content-filter.t4-02.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:2742]) (amavisd-new, port 10024) with ESMTP id ZQey9bmJuUWi; Tue, 9 Jan 2024 20:57:01 +0000 (UTC) Received: from strong-aiccu0.sbone.de (strong-aiccu0.sbone.de [IPv6:fde9:577b:c1a9:f491::2]) (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) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id F3C3F2D029D7; Tue, 9 Jan 2024 20:57:00 +0000 (UTC) Date: Tue, 9 Jan 2024 20:56:59 +0000 (UTC) From: "Bjoern A. Zeeb" To: Emmanuel Vadot cc: =?UTF-8?Q?S=C3=B8ren_Schmidt?= , "freebsd-arm@freebsd.org" , Warner Losh Subject: Re: MMCCAM hang In-Reply-To: <084r150q-076r-9rpn-89p2-87osq1p82orp@yvfgf.mnoonqbm.arg> Message-ID: <4759s3r7-4no5-777q-8r01-4192909p2sp4@yvfgf.mnoonqbm.arg> References: <49DE81A1-7DF5-48BF-A334-961A73B91E53@gmail.com> <20240109114822.522d91fea8cf170af4d895b7@bidouilliste.com> <5299p2p7-4r17-7o65-3569-o4pn3pq8r597@yvfgf.mnoonqbm.arg> <084r150q-076r-9rpn-89p2-87osq1p82orp@yvfgf.mnoonqbm.arg> X-OpenPGP-Key-Id: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Spamd-Bar: - X-Spamd-Result: default: False [-1.80 / 15.00]; SUSPICIOUS_RECIPS(1.50)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_SPF_ALLOW(-0.20)[+ip4:195.201.62.131]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; MISSING_XM_UA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:195.201.0.0/16, country:DE]; TO_DN_SOME(0.00)[]; TAGGED_RCPT(0.00)[]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_CC(0.00)[gmail.com,freebsd.org,bsdimp.com]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DMARC_NA(0.00)[zabbadoz.net]; RCVD_TLS_LAST(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; RCPT_COUNT_THREE(0.00)[4] X-Rspamd-Queue-Id: 4T8jst6mr3z3x3b On Tue, 9 Jan 2024, Bjoern A. Zeeb wrote: Problem was in sdhci for the specific chipset; wrong quirk/errata information. I'll put a patch up in Phab the next days. -- Bjoern A. Zeeb r15:7 From nobody Tue Jan 9 21:26:39 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4T8kXK08yhz56Rrk for ; Tue, 9 Jan 2024 21:26:57 +0000 (UTC) (envelope-from titus@edc.ro) Received: from eatlas.ro (eatlas.ro [86.126.82.18]) (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 "eatlas.ro", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4T8kXJ4Pvhz46QW for ; Tue, 9 Jan 2024 21:26:56 +0000 (UTC) (envelope-from titus@edc.ro) Authentication-Results: mx1.freebsd.org; none Received: from mail.edc.ro ([10.1.4.58]) by eatlas.ro (8.16.1/8.16.1) with ESMTPS id 409LQf4O067192 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Tue, 9 Jan 2024 23:26:41 +0200 (EET) (envelope-from titus@edc.ro) Received: from [192.168.1.7] (79-114-28-188.rdsnet.ro [79.114.28.188] (may be forged)) (authenticated bits=0) by mail.edc.ro (8.16.1/8.16.1) with ESMTPSA id 409LQbbn016788 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 9 Jan 2024 23:26:38 +0200 (EET) (envelope-from titus@edc.ro) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=edc.ro; s=mail; t=1704835599; bh=pQwMPeCzV4e0/4hFbIufIvhD+y8FSCAcUwL6ePvsroI=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=GeoINezdwjODWFBKwJ7A3wNhgb1pBOj0kGGAuw8apvtsfvono3KHg2KTuayqY+TWC RseQNX35+0/oju5QO/Oin1DFcmQqNB2UayfdCvFbgks4OHO0ntKcaLBnzJSiUgfQlO Y2gyHD5+S+jwJCXlSKc1lqVwJ3Cp1IGKwMwF4xvA= Content-Type: text/plain; charset=us-ascii List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) Subject: Re: MMCCAM hang From: titus In-Reply-To: <4759s3r7-4no5-777q-8r01-4192909p2sp4@yvfgf.mnoonqbm.arg> Date: Tue, 9 Jan 2024 23:26:39 +0200 Cc: Emmanuel Vadot , =?utf-8?Q?S=C3=B8ren_Schmidt?= , "freebsd-arm@freebsd.org" , Warner Losh Content-Transfer-Encoding: quoted-printable Message-Id: References: <49DE81A1-7DF5-48BF-A334-961A73B91E53@gmail.com> <20240109114822.522d91fea8cf170af4d895b7@bidouilliste.com> <5299p2p7-4r17-7o65-3569-o4pn3pq8r597@yvfgf.mnoonqbm.arg> <084r150q-076r-9rpn-89p2-87osq1p82orp@yvfgf.mnoonqbm.arg> <4759s3r7-4no5-777q-8r01-4192909p2sp4@yvfgf.mnoonqbm.arg> To: "Bjoern A. Zeeb" X-Mailer: Apple Mail (2.3608.120.23.2.7) X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-14) on ns.edc.ro X-Rspamd-Queue-Id: 4T8kXJ4Pvhz46QW X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_RCPT(0.00)[]; ASN(0.00)[asn:8708, ipnet:86.120.0.0/13, country:RO] i have a working mmc on rk3566 (opi3b) never used it much but now i rsynced a ports tree to it an it worked = fine=20 transferred 14 gb and 730k files, no locks this is without CAM > On 9 Jan 2024, at 22:56, Bjoern A. Zeeb = wrote: >=20 > On Tue, 9 Jan 2024, Bjoern A. Zeeb wrote: >=20 > Problem was in sdhci for the specific chipset; wrong quirk/errata = information. >=20 > I'll put a patch up in Phab the next days. >=20 > --=20 > Bjoern A. Zeeb = r15:7 >=20 From nobody Tue Jan 9 22:47:53 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4T8mKj62RXz56ghS for ; Tue, 9 Jan 2024 22:47:53 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (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 "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4T8mKj1mkZz4KTm for ; Tue, 9 Jan 2024 22:47:53 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Authentication-Results: mx1.freebsd.org; none Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.17.1/8.15.2) with ESMTPS id 409MlsF4001954 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 9 Jan 2024 14:47:54 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.17.1/8.15.2/Submit) id 409MlsII001953; Tue, 9 Jan 2024 14:47:54 -0800 (PST) (envelope-from fbsd) Date: Tue, 9 Jan 2024 14:47:53 -0800 From: bob prohaska To: freebsd-arm@freebsd.org Cc: bob prohaska Subject: Re: USB-serial adapter suggestions needed Message-ID: References: <7D27DF9F-AA9A-4D44-BC28-8CC637D0F550@yahoo.com> List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4T8mKj1mkZz4KTm X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US] > > For now all hosts run with powerd off in an attempt to > re-establish baseline behavior. > The baseline is proving somewhat bumpy. The ssh connection from workstation to terminal server pelorus.zefox.org (running tip to www.zefox.org) reported: .... FreeBSD/arm64 (www.zefox.org) (ttyu0) login: Jan 9 11:51:49 www sshd[24536]: error: PAM: Authentication error for illegal user scott from 85.209.11.226 Jan 9 11:56:47 www sshd[24587]: error: PAM: Authentication error for root from 185.11.61.234 Jan 9 12:32:28 www sshd[24748]: error: Fssh_kex_protocol_error: type 20 seq 2 [preauth] Jan 9 12:32:28 www sshd[24748]: error: Fssh_kex_protocol_error: type 30 seq 3 [preauth] Jan 9 12:32:52 www sshd[24752]: error: PAM: Authentication error for root from ool-2f104b1f.dyn.optonline.net Jan 9 12:32:54 www syslogd: last message repeated 4 times client_loop: send disconnect: Broken pipe bob@raspberrypi:~ $ ssh 50.1.20.24 Password for bob@pelorus.zefox.org: Last login: Tue Jan 9 09:46:03 2024 FreeBSD 14.0-RELEASE-p4 (GENERIC) #0 releng/14.0-n265400-4edf3b80733e: Wed Dec 27 20:21:26 PST 2023 [rest of MOTD snipped] .... bob@pelorus:~ % su Password: # tip ucom Stale lock on cuaU0 PID=1142... overriding. connected [typed Enter] FreeBSD/arm64 (www.zefox.org) (ttyu0) .... Pelorus.zefox.org was idle at the time, www.zefox.org was running a -j4 buildworld and busy. Nothing was running powerd. The Pi4 workstation showed no other upset on any of the dozen ssh connections open at the time. I'll keep watching. bob prohaska From nobody Wed Jan 10 01:03:42 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4T8qLk5Tznz57464 for ; Wed, 10 Jan 2024 01:03:58 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic311-25.consmr.mail.gq1.yahoo.com (sonic311-25.consmr.mail.gq1.yahoo.com [98.137.65.206]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4T8qLk1wj8z4dbQ for ; Wed, 10 Jan 2024 01:03:57 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1704848635; bh=ec6Gmpe9R8VF3uBdnachx9IvynbTKSbYxgiL4t0sS9s=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=FE7fRIoA4UISdeayLfMo6iZRUiAw/+CwhU+jbl6NsJuShzn11xi1+nw2c7BqwhzBi2pZjQ7cl54DCeW/Zq/JT60kfdAKMOtZofzUY0zJhxrmePstvxwzPIyksfUTQSATL6ImiDfMDRsveHDkLwT5NFdMDcLmrzagk4gNM0Jr25jpezDy5AeFX7VNxJ0x/U1Rcb3dftTaPfsWnqQ6azMip+VBnJADm60T5XxlCkjMrCfSPM6RivjtO9GCxseu11kXMydZBqlV1yslcJmDfeY51ETrmUenroK1vHqGhoe2KEEy3PdJRLsvEbFYEdoIQIYlEY002ySuLwijX95CuN6oHw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1704848635; bh=C2qB1pA6pqPf/plPVuaVRqKFdDRdZF13x8TufN3o8AB=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=r0mjn9lbuu6Cza79dExQh500rrhEXD+z81i8kPjedHbg+asoVKBJBawwePHcqKO03whosKsO4daoFlKYw4HHhOf7Yeg519NFpp+VKdUTsLDHdsPqFXfl1MInIxnwJ7CCRATSJxbIraG/NAs0Uc8BKpVEgCT/R0s+k/uQx4MecvqTEiHxrg06zOewKXxtES/aD+UV7Is07nbGoW4Yl/msfO3HfzhQbyxQ2kV+BFxrtdTj2jy3EswZlQFt4TqTpO98rPihWFzrqmkpJmYjRXyW6WhAHfFVNHYu/IBGBVLHPeGhcuSVnpOofP2J8FdB9yBaTx4wRH9wRHZ70bQ3Diwb/w== X-YMail-OSG: cumzrnsVM1m6gjNSh7EvASS1x47pBEs3RWof9qApFq47XZV15WIgumpks6X7khN 0Y3CXRBzuxofAC.7XUE0u_QMlGcXPfdru7VJWt5y07m6howiRQmPub_4w.c_VF3eQ.zRxWfxPnpu aQpre4uZA53X6kwkn2jV29uwcK9hDSYGwnlhHFN4fPhJpuJ98pzLch.V9FfVbJov46a2zxetF6C7 LWCi9XozsWp2Xm3dva59eNN1CqLzu74Eyd6ZcDa.wsn77NIMgpo317jf356MhBScfvWa7g059JeH Zfmuz2syB15i.h7ivCZ_6oM37DyTsFjIrMnujRUUOgiSa.MUIZjo0Vegdn7GVunxrQTyHRmPq_Ca nsMYOR6s.7WJ_wK5Qqmr4O45G3lpM7PBKAq4LcIVNgYjLr586j0rwNuk_cQ6cHjUbnzhQ8NL6a6f QFr_5mPwM.GoMRsN_wYoc8.aEQSDG17eNUL9L3mRoskWYspFWZT.NkkiDhDG_s0j8R_SK3wUBgJl HPWvNCXPWcD2IIlnIps_YZb.36VtX3VMn05r00WPCwFLz1YN4WSRnsF69tc3Svqq0Zu6bsKoY8j. KYzjRWFN1Dy_LPHhCdbwGSCnPdyTHodToBHqTpErRAATGpCkPwb4ZltrHu4UiJzE9fOkofFRWYtI XKrnr3ksLzNt4xt9ibzOkOXbHnfgsvhF2iO31xAb8kjhWqyN7uf6rEqxkzZaq4NLqUsMj4AVhl_D UTLG0dJIpPtTCsk6NDCDL38.Q8GSt5.bX9txK4CiqdpZ36rzFhljbbykXP3JMD870I_G0Y1vALfH ls675YaFqqoQIfXdLHqNknz5hahmHVkgvgBn1lX7Ttk3JV0RQ1bigujMQUpK7VFwhF0ykSx1_WVL DL61lyarBA_25xJDRmTTkqk1XqZjHFFem_noTEZZFUp9wnApc.6cy_pIybtGFL.GQ7sxy8sI_5st 07PlUKlrAp2cHRG49zxb660XWQO0YDqdNJ0zV5DbRuA0JGeDDVcaauQcbEQSBRqsJd35LRON5MT7 4vrbiihc1bUrcAeSkYN2s.wSj3Hhyf1VEMD.MsjPW6c65.pPP6ud4Y0cxLfAcCojBOLRde5YTHW2 T8rZivqLaJhYdGcIDEbbSJPlRM.q8nWv1FPj.ZR0UCyFIerKjEc5u6wFN8zYgx_wsSHco6V13AdZ Js1KUyZIRXR8ue6moKxO_MXzreaeXv3AwUYbu6kbBiqDEsq_Eek9PjzxtibyrCA1MwsrY3VydmUO KAEB7TbmVlPTBR0BCXDsqnWmkAlcT3qq0cGFJNuROnC2UDzl3dSwT79SLWwFSnoxa4G6UBmrCPwp vVhHSnZjF5kV1XEl2hdjgdpeC2CbqT.D7CFXZKTj4RGJfvFNyq3LIsQp0mB1hWRGB1rzxsdhPF3H 7Lu_qmlZt27jLvjd0UMU6B4HRiiAQHnQbeOC_NB83yQ6Kl77NgiBam.NiA1eWlQ0pk1NUqZoHZZy zN3wQ_AsXH_B3ENNa0OpZKEYg9f_dq_gRZIeDJvRS8mmaqJ1JLaLQfWKPbb3karoX2KhxSCkueXU FR2pK_CYVGRxhI7MaemWeonmg.po9Vn.n3WCcBB4dLEcy3P2PoZ9QcnR2JUwvADo.XUIUd2BuLR4 0Mz8pBxblN0UZsa.SezAvJfVrNhqvHhnv4h6D369cPMgdzftDF4tzuKCA_ox1ls4493MFnYBvPDf DO1n1At8iVks9p18P8Iarsl.EyL23UH7.rNpD.AWHxMtvkEJQQD..ndrp4Jndjt7TwCjNx1uUqkw HvCyJoTaM6slA9Ffae0sNB3hr04gSXm4.VbSIU6yuVdeIn23pS.jG07Xqbcnk_XnURDeHXBhOCvW z24cqNSDx4oFF8sSf6gVmJkwo9zvbsYKCPqlTJZtE.rAzjVfbXky1PE0hQD2TxvjPxghtzJZRsOm ux6TQAZZjnfBoy3H1wrd52Fr.q6i8Q_jFBYO3OeA_6GQfO92HjDtW4jMFBavKmzA3MkFlKWNKU0. GbIgrh5UUM_TAaDS3MEpc06eMpwlFYASrDYgGh4UreBx8fgWb7OoMEgZyXqRS0Pl76uG140ZneY7 UOO6CGIK3xu0.10I44DcHAFma367E9fi8fZmLpFdskHj0Lo5MUvJTqBclsesGsdwra0x3hCru8Xw Qd18pzlm2Gas3ZdxR_QqRdKiTebkanYjhbGzUoLZ.QdUWlyHqUrm5CElcfcEWFgUFwL7eLsI8C1d GRIgq0dgnaE2e151K3Ojkg5EUogwS9Iij741SD84zrCJEtZv23pAoJSnr66nHHHcLNanssZKXWg- - X-Sonic-MF: X-Sonic-ID: d4eab6b8-adf6-4ab4-8b78-89ba3403b87b Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Wed, 10 Jan 2024 01:03:55 +0000 Received: by hermes--production-gq1-6949d6d8f9-8snlg (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 1f66bed7275092dd24c38dc21119e44e; Wed, 10 Jan 2024 01:03:53 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.300.61.1.2\)) Subject: Re: USB-serial adapter suggestions needed From: Mark Millard In-Reply-To: Date: Tue, 9 Jan 2024 17:03:42 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <3012A549-9482-4D69-9DF4-7987E650DFFA@yahoo.com> References: <7D27DF9F-AA9A-4D44-BC28-8CC637D0F550@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3774.300.61.1.2) X-Rspamd-Queue-Id: 4T8qLk1wj8z4dbQ X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] On Jan 9, 2024, at 14:47, bob prohaska wrote: >>=20 >> For now all hosts run with powerd off in an attempt to=20 >> re-establish baseline behavior.=20 >>=20 >=20 > The baseline is proving somewhat bumpy. The ssh connection > from workstation to terminal server pelorus.zefox.org (running tip to > www.zefox.org) reported: >=20 > ... > FreeBSD/arm64 (www.zefox.org) (ttyu0) >=20 > login: Jan 9 11:51:49 www sshd[24536]: error: PAM: Authentication = error for illegal user scott from 85.209.11.226 > Jan 9 11:56:47 www sshd[24587]: error: PAM: Authentication error for = root from 185.11.61.234 > Jan 9 12:32:28 www sshd[24748]: error: Fssh_kex_protocol_error: type = 20 seq 2 [preauth] > Jan 9 12:32:28 www sshd[24748]: error: Fssh_kex_protocol_error: type = 30 seq 3 [preauth] > Jan 9 12:32:52 www sshd[24752]: error: PAM: Authentication error for = root from ool-2f104b1f.dyn.optonline.net > Jan 9 12:32:54 www syslogd: last message repeated 4 times > client_loop: send disconnect: Broken pipe > bob@raspberrypi:~ $ ssh 50.1.20.24 > Password for bob@pelorus.zefox.org: > Last login: Tue Jan 9 09:46:03 2024 > FreeBSD 14.0-RELEASE-p4 (GENERIC) #0 releng/14.0-n265400-4edf3b80733e: = Wed Dec 27 20:21:26 PST 2023 >=20 > [rest of MOTD snipped] > ... > bob@pelorus:~ % su > Password: > # tip ucom > Stale lock on cuaU0 PID=3D1142... overriding. > connected > [typed Enter] >=20 > FreeBSD/arm64 (www.zefox.org) (ttyu0) >=20 > ... >=20 > Pelorus.zefox.org was idle at the time, www.zefox.org was running > a -j4 buildworld and busy. Nothing was running powerd. The Pi4=20 > workstation showed no other upset on any of the dozen ssh connections > open at the time. Interesting. www.zefox.org is the aarch64 that is not configured in config.txt in the normal aarch64 manor. As I've requested before, please test using a config.txt that instead has: QUOTE [all] arm_64bit=3D1 dtparam=3Daudio=3Don,i2c_arm=3Don,spi=3Don dtoverlay=3Dmmc dtoverlay=3Ddisable-bt device_tree_address=3D0x4000 kernel=3Du-boot.bin [pi4] hdmi_safe=3D1 armstub=3Darmstub8-gic.bin # Local addition: [all] force_mac_address=3Db8:27:eb:71:46:4f END QUOTE Please do not use a configuration based in part on armv7 FreeBSD config.txt material any more for the testing activity: Just use the FreeBSD normal aarch64 configuration with the force_mac_address related material added at the end. I want to know if this also fails when powerd is not in use anywhere. [I assume that the "The Pi4 workstation" is the "pi4 RasPiOS workstation". True? Presuming yes: Is the RasPiOS the 64 bit variation? (Just my curiosity.)] Do you run the buildworld on www.zefox.org and such via the tip session on pelorus.zefox.org ? Via an ssh session from the "pi4 RasPiOS workstation" to www.zefox.org ? More generally: A) What runs (if anything) via the tip session started from pelorus.zefox.org ? B) What runs (if anything) via the ssh session connected to www.zefox.org ? A useful test would be to not have the tip command running on polaris.zefox.org and to just use the ssh to www.zfox.org instead to start the buildworld/buildkernel. So: No use of the serial connection when the buildworld is started or during the build(s). Using tip before that but quitting tip before starting to load the RPi4B would be okay for this type of test. The question would be if the: client_loop: send disconnect: Broken pipe still happens. (I'm not claiming that recovery if it fails would be nice. But finding out if it fails looks to be important.) The contrasting useful test would be to start the buildworld from the tip session on polaris.zefox.org and to not have any ssh session to www.zefox.org . The question would be if a failure of some kind still happens. (The tip session does not have a pipe in use as far as I know so the detail for identifying faulure would likely be different.) Another question would be: do both such tests fail? Just one (which)? None? So trying both tests eventually would be important. It is important to have only one of the 2 types of connections in use during the buildworld/buildkernel and such activity for this type of test --and only the one instance of which ever type the active test is for. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Wed Jan 10 01:30:00 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4T8qxW207Lz578Rk for ; Wed, 10 Jan 2024 01:30:39 +0000 (UTC) (envelope-from karl@denninger.net) Received: from colo1.denninger.net (colo1.denninger.net [104.236.120.189]) (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 4T8qxV2b6hz4h5Y for ; Wed, 10 Jan 2024 01:30:38 +0000 (UTC) (envelope-from karl@denninger.net) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=denninger.net; spf=pass (mx1.freebsd.org: domain of karl@denninger.net designates 104.236.120.189 as permitted sender) smtp.mailfrom=karl@denninger.net Received: from denninger.net (096-033-195-197.res.spectrum.com [96.33.195.197]) by colo1.denninger.net (Postfix) with ESMTP id B845D2110D5 for ; Tue, 9 Jan 2024 20:30:14 -0500 (EST) Received: from [192.168.10.25] (D15.Denninger.Net [192.168.10.25]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by denninger.net (Postfix) with ESMTPSA id 488123C8B42 for ; Tue, 9 Jan 2024 20:30:01 -0500 (EST) Message-ID: Date: Tue, 9 Jan 2024 20:30:00 -0500 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: "freebsd-arm@freebsd.org" From: Karl Denninger Subject: Nanobsd builds for rpi3 out of embedded blow up during build Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms020508020002010605090205" X-Spamd-Bar: ----- X-Spamd-Result: default: False [-5.89 / 15.00]; SIGNED_SMIME(-2.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[denninger.net,none]; MIME_GOOD(-0.20)[multipart/signed,multipart/alternative,text/plain]; R_SPF_ALLOW(-0.20)[+mx]; XM_UA_NO_VERSION(0.01)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~,4:~]; RCVD_TLS_LAST(0.00)[]; FREEFALL_USER(0.00)[karl]; ASN(0.00)[asn:14061, ipnet:104.236.64.0/18, country:US]; ARC_NA(0.00)[]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_EQ_ADDR_ALL(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; HAS_ATTACHMENT(0.00)[] X-Rspamd-Queue-Id: 4T8qxV2b6hz4h5Y This is a cryptographically signed message in MIME format. --------------ms020508020002010605090205 Content-Type: multipart/alternative; boundary="------------Pb20Iwj008biAWj54Xf0reDY" --------------Pb20Iwj008biAWj54Xf0reDY Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Is this supposed to work? root@NewFS:/usr/src/tools/tools/nanobsd/embedded # sh ../nanobsd.sh -b -c rpi3.cfg It doesn't.  I do have: root@NewFS:/usr/ports # pkg info|grep rpi3 u-boot-rpi3-2023.10_1          Cross-build das u-boot for model rpi3 Which ought to be current. I get errors missing ubldr (which from my Crochet builds does not appear to be required) and also the dtb files are either somewhere other than expected because the firmware package is there, but I get this when commenting out the ubldr copy: root@NewFS:/usr/embedded/rpi3 # tail _.cust.dos_boot_part + local 'd=/usr/local/share/u-boot/u-boot-rpi3' + local 'f=/usr/embedded/rpi3/_.fat' + rm -rf /usr/embedded/rpi3/_.fat + mkdir /usr/embedded/rpi3/_.fat + chdir /usr/embedded/rpi3/_.fat + cp /usr/local/share/u-boot/u-boot-rpi3/README /usr/local/share/u-boot/u-boot-rpi3/metadata /usr/local/share/u-boot/u-boot-rpi3/u-boot-working-previous.bin /usr/local/share/u-boot/u-boot-rpi3/u-boot.bin /usr/local/share/u-boot/u-boot-rpi3/u-boot.bin.broken . + [ -f /usr/embedded/rpi3/_.w/boot/ubldr ] + touch uEnv.txt + cp '/usr/embedded/rpi3/_.w/boot/dtb/*.dtb' . cp: /usr/embedded/rpi3/_.w/boot/dtb/*.dtb: No such file or directory Which of course implies they're not in the world's "boot" directory, and indeed they're not. I can keep working around this but I assuming I'm missing something obvious..... or is this just broken/deprecated? -- Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------Pb20Iwj008biAWj54Xf0reDY Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

Is this supposed to work?

root@NewFS:/usr/src/tools/tools/nanobsd/embedded # sh ../nanobsd.sh -b -c rpi3.cfg

It doesn't.  I do have:

root@NewFS:/usr/ports # pkg info|grep rpi3
u-boot-rpi3-2023.10_1          Cross-build das u-boot for model rpi3

Which ought to be current.

I get errors missing ubldr (which from my Crochet builds does not appear to be required) and also the dtb files are either somewhere other than expected because the firmware package is there, but I get this when commenting out the ubldr copy:

root@NewFS:/usr/embedded/rpi3 # tail _.cust.dos_boot_part
+ local 'd=/usr/local/share/u-boot/u-boot-rpi3'
+ local 'f=/usr/embedded/rpi3/_.fat'
+ rm -rf /usr/embedded/rpi3/_.fat
+ mkdir /usr/embedded/rpi3/_.fat
+ chdir /usr/embedded/rpi3/_.fat
+ cp /usr/local/share/u-boot/u-boot-rpi3/README /usr/local/share/u-boot/u-boot-rpi3/metadata /usr/local/share/u-boot/u-boot-rpi3/u-boot-working-previous.bin /usr/local/share/u-boot/u-boot-rpi3/u-boot.bin /usr/local/share/u-boot/u-boot-rpi3/u-boot.bin.broken .
+ [ -f /usr/embedded/rpi3/_.w/boot/ubldr ]
+ touch uEnv.txt
+ cp '/usr/embedded/rpi3/_.w/boot/dtb/*.dtb' .
cp: /usr/embedded/rpi3/_.w/boot/dtb/*.dtb: No such file or directory

Which of course implies they're not in the world's "boot" directory, and indeed they're not.

I can keep working around this but I assuming I'm missing something obvious..... or is this just broken/deprecated?

--
Karl Denninger
karl@denninger.net
The Market Ticker
[S/MIME encrypted email preferred]
--------------Pb20Iwj008biAWj54Xf0reDY-- --------------ms020508020002010605090205 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC DbowggagMIIEiKADAgECAhMA5EiKghDOXrvfxYxjITXYDdhIMA0GCSqGSIb3DQEBCwUAMIGL MQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJTmljZXZpbGxlMRkw FwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExITAf BgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQTAeFw0xNzA4MTcxNjQyMTdaFw0yNzA4 MTUxNjQyMTdaMHsxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMRkwFwYDVQQKDBBD dWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExJTAjBgNVBAMMHEN1 ZGEgU3lzdGVtcyBMTEMgMjAxNyBJbnQgQ0EwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK AoICAQC1aJotNUI+W4jP7xQDO8L/b4XiF4Rss9O0B+3vMH7Njk85fZ052QhZpMVlpaaO+sCI KqG3oNEbuOHzJB/NDJFnqh7ijBwhdWutdsq23Ux6TvxgakyMPpT6TRNEJzcBVQA0kpby1DVD 0EKSK/FrWWBiFmSxg7qUfmIq/mMzgE6epHktyRM3OGq3dbRdOUgfumWrqHXOrdJz06xE9NzY vc9toqZnd79FUtE/nSZVm1VS3Grq7RKV65onvX3QOW4W1ldEHwggaZxgWGNiR/D4eosAGFxn uYeWlKEC70c99Mp1giWux+7ur6hc2E+AaTGh+fGeijO5q40OGd+dNMgK8Es0nDRw81lRcl24 SWUEky9y8DArgIFlRd6d3ZYwgc1DMTWkTavx3ZpASp5TWih6yI8ACwboTvlUYeooMsPtNa9E 6UQ1nt7VEi5syjxnDltbEFoLYcXBcqhRhFETJe9CdenItAHAtOya3w5+fmC2j/xJz29og1KH YqWHlo3Kswi9G77an+zh6nWkMuHs+03DU8DaOEWzZEav3lVD4u76bKRDTbhh0bMAk4eXriGL h4MUoX3Imfcr6JoyheVrAdHDL/BixbMH1UUspeRuqQMQ5b2T6pabXP0oOB4FqldWiDgJBGRd zWLgCYG8wPGJGYgHibl5rFiI5Ix3FQncipc6SdUzOQIDAQABo4IBCjCCAQYwHQYDVR0OBBYE FF3AXsKnjdPND5+bxVECGKtc047PMIHABgNVHSMEgbgwgbWAFBu1oRhUMNEzjODolDka5k4Q EDBioYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJ TmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5 c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQYIJAKxAy1WBo2kY MBIGA1UdEwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgGGMA0GCSqGSIb3DQEBCwUAA4IC AQCB5686UCBVIT52jO3sz9pKuhxuC2npi8ZvoBwt/IH9piPA15/CGF1XeXUdu2qmhOjHkVLN gO7XB1G8CuluxofOIUce0aZGyB+vZ1ylHXlMeB0R82f5dz3/T7RQso55Y2Vog2Zb7PYTC5B9 oNy3ylsnNLzanYlcW3AAfzZcbxYuAdnuq0Im3EpGm8DoItUcf1pDezugKm/yKtNtY6sDyENj tExZ377cYA3IdIwqn1Mh4OAT/Rmh8au2rZAo0+bMYBy9C11Ex0hQ8zWcvPZBDn4v4RtO8g+K uQZQcJnO09LJNtw94W3d2mj4a7XrsKMnZKvm6W9BJIQ4Nmht4wXAtPQ1xA+QpxPTmsGAU0Cv HmqVC7XC3qxFhaOrD2dsvOAK6Sn3MEpH/YrfYCX7a7cz5zW3DsJQ6o3pYfnnQz+hnwLlz4MK 17NIA0WOdAF9IbtQqarf44+PEyUbKtz1r0KGeGLs+VGdd2FLA0e7yuzxJDYcaBTVwqaHhU2/ Fna/jGU7BhrKHtJbb/XlLeFJ24yvuiYKpYWQSSyZu1R/gvZjHeGb344jGBsZdCDrdxtQQcVA 6OxsMAPSUPMrlg9LWELEEYnVulQJerWxpUecGH92O06wwmPgykkz//UmmgjVSh7ErNvL0lUY UMfunYVO/O5hwhW+P4gviCXzBFeTtDZH259O7TCCBxIwggT6oAMCAQICEgLG8yH4PQFdbd9x Ugmpzl1jXzANBgkqhkiG9w0BAQsFADB7MQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlk YTEZMBcGA1UECgwQQ3VkYSBTeXN0ZW1zIExMQzEYMBYGA1UECwwPQ3VkYSBTeXN0ZW1zIENB MSUwIwYDVQQDDBxDdWRhIFN5c3RlbXMgTExDIDIwMTcgSW50IENBMB4XDTIyMDYyOTE2MTYz NloXDTI3MDYyODE2MTYzNlowOjELMAkGA1UEBhMCVVMxEjAQBgNVBAgMCVRlbm5lc3NlZTEX MBUGA1UEAwwOS2FybCBEZW5uaW5nZXIwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoIC AQC+HVSyxVtJhy3Ohs+PAGRuO//Dha9A16l5FPATr6wude9zjX5f2lrkRyU8vhCXTZW7WbvW ZKpcZ8r0dtZmiK9uF58Ec6hhvfkxJzbg96WHBw5Fumd5ahZzuCJDtCAWW8R7/KN+zwzQf1+B 3MVLmbaXAFBuKzySKhKMcHbK3/wjUYTgy+3UK6v2SBrowvkUBC+jxNg3Wy12GsTXcUS/8FYI XgVVPgfZZrbJJb5HWOQpvvhILpPCD3xsYJFNKEPltXKWHT7Qtc2HNqikgNwj8oqOb+PeZGMi WapsatKm8mxuOOGOEBhAoTVTwUHlMNTg6QUCJtuWFCK38qOCyk9Haj+86lUU8RG6FkRXWgMb NQm1mWREQhw3axgGLSntjjnznJr5vsvXSYR6c+XKLd5KQZcS6LL8FHYNjqVKHBYM+hDnrTZM qa20JLAF1YagutDiMRURU23iWS7bA9tMcXcqkclTSDtFtxahRifXRI7Epq2GSKuEXe/1Tfb5 CE8QsbCpGsfSwv2tZ/SpqVG08MdRiXxN5tmZiQWo15IyWoeKOXl/hKxA9KPuDHngXX022b1l y+5ZOZbxBAZZMod4y4b4FiRUhRI97r9lCxsP/EPHuuTIZ82BYhrhbtab8HuRo2ofne2TfAWY 2BlA7ExM8XShMd9bRPZrNTokPQPUCWCgCdIATQIDAQABo4IBzzCCAcswPAYIKwYBBQUHAQEE MDAuMCwGCCsGAQUFBzABhiBodHRwOi8vb2NzcC5jdWRhc3lzdGVtcy5uZXQ6ODg4ODAJBgNV HRMEAjAAMBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYI KwYBBQUHAwIGCCsGAQUFBwMEMDMGCWCGSAGG+EIBDQQmFiRPcGVuU1NMIEdlbmVyYXRlZCBD bGllbnQgQ2VydGlmaWNhdGUwHQYDVR0OBBYEFLElmNWeVgsBPe7O8NiBzjvjYnpRMIHKBgNV HSMEgcIwgb+AFF3AXsKnjdPND5+bxVECGKtc047PoYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQ MA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJTmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5 c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lz dGVtcyBMTEMgMjAxNyBDQYITAORIioIQzl6738WMYyE12A3YSDAdBgNVHREEFjAUgRJrYXJs QGRlbm5pbmdlci5uZXQwDQYJKoZIhvcNAQELBQADggIBAKquc7cu0xc8FNtAQauZvocDzWQj 7HG9YvMbWnMi+ckhiA3rdW5NwWg0HBhBho1YlnqV+ntCVE2L8ezohHWm+KAdfXgpraL86Vsn 3ywNlZu/3COMpo2ALuHln8YQtH3Y8ebvzKMdlf2b5WB+7mOFIxXIr4AnNOLKCkq5ZhzC6JW6 Jvw3P0csiGa3UrfatYID5NvPgkaQvEgimEjG3psZqwQTL2Wxohvw783PrDt3wS0XeNhvQ61g 3QJFZKuv+bmGH3YBSPo1t6NUGAr+JozX5lDihB8JGkBt/NwdYec49a08uL0BbPaAJ7NjuIPG 7Y0Ak7PXZT37yx/Zla9PzLMJFgbelOkaatdzbblMZPDEVZ27l4lGMmV83Lm3YP17sdAyS/Wp mav7WmJUkQ9iuIKzSpdc82i9Mfujl1vbBtwtkHNPPtKuulIFM4ZwrPKjlVdLqTSqD8m9yHEi Y0PuAooq63OpJWF6hvMaiIPBWEAVIaDW9uG0MshLl9DnHnMyrJTfuC33Z9mOGMz7dRBjJd5Y W02xAzYnUuEBOpj+LQv5R8XIFMHFXktqEKvQrXeM2RU+PcZqKOBkTktxBLn3NI5VfA15Jk0c 5V5XcOqo3p2hvrwvXrinrb2pEREnoqmfrkXT3zOq5Y6ryRH8u734lGEF0dILXzoV4PM7XFit oTePoEjmMYIFBDCCBQACAQEwgZEwezELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGEx GTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBMTEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTEl MCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExMQyAyMDE3IEludCBDQQISAsbzIfg9AV1t33FSCanO XWNfMA0GCWCGSAFlAwQCAwUAoIICQzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0yNDAxMTAwMTMwMDBaME8GCSqGSIb3DQEJBDFCBEDM2BGU9qlBAuG0x7QB 8eC3KMW0v6SNhSE6rQzqY9BU6L62vJduXbnGziesufR5gRrxnFCBSdRnb+b+SP/nooxjMGwG CSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAO BggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgw gaIGCSsGAQQBgjcQBDGBlDCBkTB7MQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTEZ MBcGA1UECgwQQ3VkYSBTeXN0ZW1zIExMQzEYMBYGA1UECwwPQ3VkYSBTeXN0ZW1zIENBMSUw IwYDVQQDDBxDdWRhIFN5c3RlbXMgTExDIDIwMTcgSW50IENBAhICxvMh+D0BXW3fcVIJqc5d Y18wgaQGCyqGSIb3DQEJEAILMYGUoIGRMHsxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9y aWRhMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMg Q0ExJTAjBgNVBAMMHEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBJbnQgQ0ECEgLG8yH4PQFdbd9x Ugmpzl1jXzANBgkqhkiG9w0BAQEFAASCAgCSnYHO4KbhfwPpM/5WMipzgqYFd8BeRf4NoQlE g+yxrcSZUfMA3B7uDVgqFM7xsZI+DI/JCAHL0ATlbp6dEvrufRCtbSdlsZwRAGqwrw58716y k3MBDSACPZ+XdMddw8H1TKbJZ+QJemvYipiqLt+b9ZIFJ+rs5x3y+V/h4uqLjAYvrY2HZC7i rv7+GUqBkQRloz41xAJyKfmFsGzrq/Txxbyg73w4chdyCvrcCwXt0YadH5iWi6/i/5fACMVL hKK7ar7Z46whV/YPqX/vXVWPyCRolbs6C7vUpMNsm3t9I533ufjbHiP1nMGsSMdvr9F635y6 uIRpcyumGoylf7wCvPsEk7qsNKbVKHkJlPR4J8gStkYKw7mQzv0QX0kF5/iwm2u9lotcVGn4 HBBkZ43myyDkCxm5uK4z88AlXBUasmTrBkyeR2Aa43NpzFJ7qdCofy3yFhCkQECt8P5kp6My pE5h3JWojWO14xpBV3LloKNhYVDu+t3BBLU42cEN8Bbw2wPnqh3R2VZf3W2XVlL55nm/iu0d 9II9SPlshzkoKBDNccOOtihDE4QsFnIj5V/qv5oUQq1jHeXtUVLUnSthtcQJKkRyvw8rYuy9 FBSJoJiIK37BCGvt4BNdmJK98Z+RQS0LEOFlGk0YjtUsSqs8SD1xqn7c8szZYbtYbg9gPwAA AAAAAA== --------------ms020508020002010605090205-- From nobody Wed Jan 10 02:16:03 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4T8ryC04bXz57GL4 for ; Wed, 10 Jan 2024 02:16:19 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com [IPv6:2a00:1450:4864:20::629]) (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 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4T8ryB4s2Kz4mn8 for ; Wed, 10 Jan 2024 02:16:18 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ej1-x629.google.com with SMTP id a640c23a62f3a-a298accc440so418204266b.1 for ; Tue, 09 Jan 2024 18:16:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1704852976; x=1705457776; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=QMd4qR/uKbMaTtAwMFLAAuQe24NS9TULqNiOhBb0yD0=; b=CsIAmOqZDc0I6duKPAknSrlzWkDZt2aemBzqTqb5tPDhz3NgvruG7Z/1+k9LajgLJ8 VQ1XDACjTLELwLBKgmOZ6obosiV8k+3ESTQZdPQ/+DaLLdnEjx6GV85Nw+YQ/TjugPwX RkZqeRUKYajhOR9KT21kYN2EMw+h1fRoxEkZmmfz4CeLIIhBAmzXFFpsrXMuJPHExU3q gwhkg1jVeVYkIRAnhjQHnPUiT9tTJPVeW7PYz0ayWbMpgIsuSYmq9qOjjGHoq4RYI0Uz D2VwqtXoCAa27c/tU8D2DuZU/MQ7KEX/ZqES75qGuBJQh5hZPSCrevi/KNib4wFxLeco hNmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704852976; x=1705457776; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=QMd4qR/uKbMaTtAwMFLAAuQe24NS9TULqNiOhBb0yD0=; b=EHQKmmcKiH0TimCZczLS4nPoCEcwcNRHZOvnHj8v91sT9WklCYpppLCsL3PY5ev3iM /j4zK4keRNpdvTam19O6lSFAfRVem9r5/VL3jI+XyVgUuVKTC0AJZ6pj04LN1vIhRx/F UaBVeo37pSc7FVNwPPfvq/Z6prJxgUkXMQuLP9kCny7lCDC+4OqBGo4z01eOY9V0OTpg N22hNd5B1UMZUjBwrgq8t7ITYhuexkc4uLAciAEdN84wZc8bPSro9kHxpGM/NTlej3aY c9zR5QL1ea9CSFQr8FW5thBW0b6mN1k266c1IFY0hq/1KMo+tZF3bko5pVnGRtmbwSDr Eibw== X-Gm-Message-State: AOJu0YzOWMPnut9jeJWwzFLY9DYXwGw2qH/eyR+ni0HZbfHTLfMuFdXh 3tyX9+92vHe5X1r5+xRJkwEqF7XvdeNCkDTiRQyRmgUX2AE8AJa9ruAIBjZt9Gg= X-Google-Smtp-Source: AGHT+IGFHhjBO3oJW6e1S3oBqPijpSd+V0ESeAyWvqYXzS9CI7MxeESwtNwCF5ZogcOmRsqv3WyBhIpruSEWDcu/uNM= X-Received: by 2002:a17:906:bc86:b0:a28:f771:ba67 with SMTP id lv6-20020a170906bc8600b00a28f771ba67mr214276ejb.131.1704852975623; Tue, 09 Jan 2024 18:16:15 -0800 (PST) List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Tue, 9 Jan 2024 19:16:03 -0700 Message-ID: Subject: Re: Nanobsd builds for rpi3 out of embedded blow up during build To: Karl Denninger Cc: "freebsd-arm@freebsd.org" Content-Type: multipart/alternative; boundary="00000000000001aeaf060e8e041c" X-Rspamd-Queue-Id: 4T8ryB4s2Kz4mn8 X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] --00000000000001aeaf060e8e041c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jan 9, 2024, 6:30=E2=80=AFPM Karl Denninger wr= ote: > Is this supposed to work? > > root@NewFS:/usr/src/tools/tools/nanobsd/embedded # sh ../nanobsd.sh -b -c > rpi3.cfg > > It doesn't. I do have: > > root@NewFS:/usr/ports # pkg info|grep rpi3 > u-boot-rpi3-2023.10_1 Cross-build das u-boot for model rpi3 > > Which ought to be current. > > I get errors missing ubldr (which from my Crochet builds does not appear > to be required) and also the dtb files are either somewhere other than > expected because the firmware package is there, but I get this when > commenting out the ubldr copy: > > root@NewFS:/usr/embedded/rpi3 # tail _.cust.dos_boot_part > + local 'd=3D/usr/local/share/u-boot/u-boot-rpi3' > + local 'f=3D/usr/embedded/rpi3/_.fat' > + rm -rf /usr/embedded/rpi3/_.fat > + mkdir /usr/embedded/rpi3/_.fat > + chdir /usr/embedded/rpi3/_.fat > + cp /usr/local/share/u-boot/u-boot-rpi3/README > /usr/local/share/u-boot/u-boot-rpi3/metadata > /usr/local/share/u-boot/u-boot-rpi3/u-boot-working-previous.bin > /usr/local/share/u-boot/u-boot-rpi3/u-boot.bin > /usr/local/share/u-boot/u-boot-rpi3/u-boot.bin.broken . > + [ -f /usr/embedded/rpi3/_.w/boot/ubldr ] > + touch uEnv.txt > + cp '/usr/embedded/rpi3/_.w/boot/dtb/*.dtb' . > cp: /usr/embedded/rpi3/_.w/boot/dtb/*.dtb: No such file or directory > > Which of course implies they're not in the world's "boot" directory, and > indeed they're not. > > I can keep working around this but I assuming I'm missing something > obvious..... or is this just broken/deprecated? > I think just broken. It's been a while since i tested everything. Warner > -- > Karl Denninger > karl@denninger.net > *The Market Ticker* > *[S/MIME encrypted email preferred]* > --00000000000001aeaf060e8e041c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Jan 9, 2024, 6:30=E2=80=AFPM Karl Denninger &l= t;karl@denninger.net> wrote:
=20 =20 =20

Is this supposed to work?

root@NewFS:/usr/src/tools/tools/nanobsd/embedded # sh ../nanobsd.sh -b -c rpi3.cfg

It doesn't.=C2=A0 I do have:

root@NewFS:/usr/ports # pkg info|grep rpi3
u-boot-rpi3-2023.10_1=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 Cross-build das u-boot for model rpi3

Which ought to be current.

I get errors missing ubldr (which from my Crochet builds does not appear to be required) and also the dtb files are either somewhere other than expected because the firmware package is there, but I get this when commenting out the ubldr copy:

root@NewFS:/usr/embedded/rpi3 # tail _.cust.dos_boot_part
+ local 'd=3D/usr/local/share/u-boot/u-boot-rpi3'
+ local 'f=3D/usr/embedded/rpi3/_.fat'
+ rm -rf /usr/embedded/rpi3/_.fat
+ mkdir /usr/embedded/rpi3/_.fat
+ chdir /usr/embedded/rpi3/_.fat
+ cp /usr/local/share/u-boot/u-boot-rpi3/README /usr/local/share/u-boot/u-boot-rpi3/metadata /usr/local/share/u-boot/u-boot-rpi3/u-boot-working-previous.bin /usr/local/share/u-boot/u-boot-rpi3/u-boot.bin /usr/local/share/u-boot/u-boot-rpi3/u-boot.bin.broken .
+ [ -f /usr/embedded/rpi3/_.w/boot/ubldr ]
+ touch uEnv.txt
+ cp '/usr/embedded/rpi3/_.w/boot/dtb/*.dtb' .
cp: /usr/embedded/rpi3/_.w/boot/dtb/*.dtb: No such file or directory

Which of course implies they're not in the world's "boo= t" directory, and indeed they're not.

I can keep working around this but I assuming I'm missing something obvious..... or is this just broken/deprecated?


I = think just broken. It's been a while since i tested everything.=C2=A0

Warner

--
Karl Denninger
karl@denninger.net
The Market Ticker
[S/MIME encrypted email preferred]
--00000000000001aeaf060e8e041c-- From nobody Wed Jan 10 03:38:17 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4T8tn36zgyz55WsR for ; Wed, 10 Jan 2024 03:38:31 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com [IPv6:2a00:1450:4864:20::635]) (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 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4T8tn35DbPz42F7 for ; Wed, 10 Jan 2024 03:38:31 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ej1-x635.google.com with SMTP id a640c23a62f3a-a2a17f3217aso398025266b.2 for ; Tue, 09 Jan 2024 19:38:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1704857909; x=1705462709; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=WaVB/wzB9Mxfj0KTLlYVmFZm7kW2gJqpLwDqpXanY2k=; b=frQASToArjm7rhRMkSueitSEqHpuez9kEoDfOAbvQrN5qv/qo7PdWVdcwGWIwJ1idY VtZ7wYxvRJHcxsU1YS7+aKEMj//qX/pS7MEodL1sBkCulEMXcc9eIwkv9fRdzQvA6vCI FqO0iXUY0+1++ud2yZIFFNXzCjiIfRK4GUylp3WtTZ3YROszLP453UrKbU6gJXP65jM2 Clag0qj7StX9mwpYqwMyv0wI6/0e/FOspaPyJXSLZ2G5nsc5t87wARj6+JdPQOCW/Ta/ fxpWvAbcOnWN5UMzcsKbIs5CWWwe6yI4TKK8d7JkgJ+v7dTn8nvRL6EGUFRe9a3LpWff AM/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704857909; x=1705462709; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=WaVB/wzB9Mxfj0KTLlYVmFZm7kW2gJqpLwDqpXanY2k=; b=oAym4RTZI3ZG+Ij1kzfehG7IkkHZ2qfktEXxSYoPMV1l3liH6HFOUnN5pU4Wr4aDN+ bkTFsGMLst1xWx/vSGoK0hwpAsaBMrRUiYQGGMFb24A2Qwlq3BiBvL+ArJvg+BM69VRG PQUpq0Nuqi02ZaNH/ZpM9Vy7aUQbBZrlXuZAHybXqDvniu2ctE8nJvHRj2727WPd5pp/ /by9j6bG3Fkdi0TN466hZ9oMwma7i9ixdlVcH2i+Kgai2LDY34deQ8Hw2x42Wv7+0Qnf vu8aEy7u697PN5JnKsOthG5Z6MUor20LXiZ+xO/zXQFDxMvfEo7GFPi85spZFkwLJ65l SHsg== X-Gm-Message-State: AOJu0YwPf+WKZs566LksiJ8zrV+dqWmHgVZa74/Wpkrs8MsPXi3sqJPx cw7Hln9NNQ3mQeihTO1HfIartPQ8Xepp/GZfTQ10cRwt+YB15A== X-Google-Smtp-Source: AGHT+IHN4hKKK0NtBkE8gTlii0c8/PWMLaHFGdVHTglqLVKophEZ930/wPIEDAhLz3qdyVxESH2V1ccNMA99Z6STRPA= X-Received: by 2002:a17:906:a99:b0:a28:220f:4271 with SMTP id y25-20020a1709060a9900b00a28220f4271mr255859ejf.29.1704857908741; Tue, 09 Jan 2024 19:38:28 -0800 (PST) List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 References: <49DE81A1-7DF5-48BF-A334-961A73B91E53@gmail.com> <20240109114822.522d91fea8cf170af4d895b7@bidouilliste.com> <5299p2p7-4r17-7o65-3569-o4pn3pq8r597@yvfgf.mnoonqbm.arg> <084r150q-076r-9rpn-89p2-87osq1p82orp@yvfgf.mnoonqbm.arg> <4759s3r7-4no5-777q-8r01-4192909p2sp4@yvfgf.mnoonqbm.arg> In-Reply-To: <4759s3r7-4no5-777q-8r01-4192909p2sp4@yvfgf.mnoonqbm.arg> From: Warner Losh Date: Tue, 9 Jan 2024 20:38:17 -0700 Message-ID: Subject: Re: MMCCAM hang To: "Bjoern A. Zeeb" Cc: Emmanuel Vadot , =?UTF-8?Q?S=C3=B8ren_Schmidt?= , "freebsd-arm@freebsd.org" Content-Type: multipart/alternative; boundary="0000000000000b1825060e8f2a10" X-Rspamd-Queue-Id: 4T8tn35DbPz42F7 X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_RCPT(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] --0000000000000b1825060e8f2a10 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable That makes sense. The threads you posted showed several blocked on IO while sdhci was resetting. That's going to keep any I/O from happening. I guess I'm not surprised it's the wrong quirks... Many years ago when I was playing with a new, somewhat buggy SDHCI PCIe add-in card having the wrong quirks would cause super weird behavior. In my case, it was an infinite stream of interrupts... You should be able to disable the FreeBSD device like any other FreeBSD device hint.sdhci.0.disabled=3D1 we'll probe the device (which for FDT checks the compat settings) and then never call attach, but instead print a message saying it is disabled. One can also create an overlay that sets its status to something other than okay, but that's quite a bit trickier and can't be done on the fly from the boot loader. Warner On Tue, Jan 9, 2024, 1:57=E2=80=AFPM Bjoern A. Zeeb wrote: > On Tue, 9 Jan 2024, Bjoern A. Zeeb wrote: > > Problem was in sdhci for the specific chipset; wrong quirk/errata > information. > > I'll put a patch up in Phab the next days. > > -- > Bjoern A. Zeeb r15:7 > --0000000000000b1825060e8f2a10 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
That makes sense. The threads you posted= showed several blocked on IO while sdhci was resetting. That's going t= o keep any I/O from happening. I guess I'm not surprised it's the w= rong quirks... Many years ago when I was playing with a new, somewhat buggy= SDHCI PCIe add-in card having the wrong quirks would cause super weird beh= avior. In my case, it was an infinite stream of interrupts...

You should be able to disable the Fre= eBSD device like any other FreeBSD device

=
hint.sdhci.0.disabled=3D1

we'll probe the= device (which for FDT checks the compat settings) and then never call atta= ch, but instead print a message saying it is disabled.

=
One can also create an overlay that sets its status to something other= than okay, but that's quite a bit trickier and can't be done on th= e fly from the boot loader.

Warner
=

= On Tue, Jan 9, 2024, 1:57=E2=80=AFPM Bjoern A. Zeeb <bzeeb-lists@lists.zabbadoz= .net> wrote:
On Tue, 9 Jan 2024, Bjoern A. Zeeb wrote:

Problem was in sdhci for the specific chipset; wrong quirk/errata informati= on.

I'll put a patch up in Phab the next days.

--
Bjoern A. Zeeb=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0r15:7
--0000000000000b1825060e8f2a10-- From nobody Wed Jan 10 05:18:12 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4T8x044N5Lz55rXZ for ; Wed, 10 Jan 2024 05:18:12 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4T8x042FbWz4TXy for ; Wed, 10 Jan 2024 05:18:12 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1704863892; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=SmO40EdKaaZJMvEVXG72utKY7ZNOnvDNdbkHXkFWPEA=; b=je5Vf39aQLkVzDgOeyvwYOi+edgMtsYrv0oF8BJIfGRCEoa6Pa3PbWBkj4WpS3zwnup6a0 Pj9pJqCVXqgqfcn92KZ0Nz7uFrHCIytE4RB4Y6QihUvGKnITu6RBsqqS4kgiHPLCmKov11 dzJ9p3MAk7xaDeaf9blPRE2pqlgZ7xyH4lywzF6HvrQnSZK0Tfkj4XpooF5DSoVlGFt63g 3SHAEoqQWdSuGo/waFf9xx68Tod9SvbmPDVBAnPyR5eZ3iMzBhkTEYxRZV8b3QHaFSPNxi e1xrAglAQ6UyfdOHcGG/Za3hzLiky3bNG3Cqdf3KqZNDMR+WDWTqngzQo3Ac4A== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1704863892; a=rsa-sha256; cv=none; b=p6rRekDMyel3C/IWb4qN/XFjN3B7++WUUx644DoPCO7VIvkn4ccu4odt2PzTVcQ6CK7qup FG6sMulagzgTQbf5K1J0BcZLGWui8BCovmMoTa/8ExlyLws8ZjF2Dfe5QqmHcwzZRKQ/XS eQvdPn8WcO30pANuuewkXP6tb+KUZ3ki6KQTwx83taQlY2f9m9TEkc+vH6Ipk9DjIXhGlr rcJhSQu3AXahsKT1QIqFvQWzG/UPM2nfTkHn0MBOWHvT731/vNMttaGrwllQ1OzBswwtnu kC719xBUo4aZcJOTZ6rv1qWHiRsSU6TuKRmawpcKwdoQf54eKrUi7I06jHcUgg== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4T8x041JWFzM8h for ; Wed, 10 Jan 2024 05:18:12 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 40A5IC91042218 for ; Wed, 10 Jan 2024 05:18:12 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 40A5ICWv042217 for freebsd-arm@FreeBSD.org; Wed, 10 Jan 2024 05:18:12 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 222139] iovctl can not create virtual function on thunderx platform Date: Wed, 10 Jan 2024 05:18:12 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 11.1-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: Overcome By Events X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: resolution bug_status Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D222139 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |Overcome By Events Status|New |Closed --- Comment #1 from Mark Linimon --- ^Triage: FreeBSD 11 is long out of support. --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Wed Jan 10 05:37:54 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4T8xR935Ytz55vkp for ; Wed, 10 Jan 2024 05:38:13 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic311-25.consmr.mail.gq1.yahoo.com (sonic311-25.consmr.mail.gq1.yahoo.com [98.137.65.206]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4T8xR818tvz4X6s for ; Wed, 10 Jan 2024 05:38:11 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=jJFFoUxZ; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.206 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1704865089; bh=ALSGUHNe2ifHG7ge3BjT4U2cmhPzGLm60AN00WqN04w=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=jJFFoUxZS5Al7J5LiRHpQuPTtTMup904Okwf3uqHwHElPjvtrP1EP6H98+wK41+v8dwf2AJo7HMF2S5XpGqpNS0Zm8kVO3hO26ZMzNA/y/Zj5IhVaR6paz+l5aum7jxO8+LlcDkOPnqG0GM2GBBrB9dT94sec6FNAOmcW5DpntpLanaYgOcByvw3zwAHTDUZAcD9qTPLA/SdRg8cKi5CRyamfHdW+n0KfnTu8M1HzfTauTMri4pZ0FrWU/rHWvNCEJZhsZg4z9Br//FXvLQiM7Hc4gPbZwmOxnIrVfBPGf8RgjwfNlntOM8JNQpHEKyJpjA34r8WbkoWMdcBLos2AQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1704865089; bh=usFoQmxQ4TzmoTUY1tvquJXVp3Z9fHiswTuQa+G1KrF=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=UWQH49RRaFE/u0fP2I5o0YlOTNYilzLyN8NVhGPi22c/HnHfmHI6EY+zoFfHeXHPXjOQtK7F54rSWSrJIyw16qU0NzkEbBHUEXSmva2IsIE8jw/XnSO5FuKfULuJZWTpG8dMT9XQnApNf61EPJPYyYAeZ8Mgb3nBwbcdOvgQe02Vp9mBmxds2vE1a4WkBZmpZoGLZhihbbHwhNoyj7XX6mseOniOrVfkCbqmFlGPDOffXCsXqWDxdCA7QeXObZ3mBGuGYqz5UH76fjjz5KRaVBfDJa7YM73AAHgAyxTq881v1PW8k31vtIEbLohSSS1062LQmyyNNeBrSV0DmV26XA== X-YMail-OSG: ByOuvjYVM1k4m71RsHEF7FM9znVuOXCV85uuDqHYkuKlgE0FJIUgv9q.lRYrqlF QECNvYiZWwfjJIckhByXqkLHazTSOgGr4X8RvSWxcVZAr3ZGwHJFaAKqYqrrap25oayCl_hknjnv 1SIGDrlrHeLWKcUSm1KlZdhidiIAefcS6fvkcWaqsLCixUTVZGDKYEyR8aBDEI42S4vWLfNFRyHx iX88AJDwiMT09K6hIFGtUiMMk8YWLuYiVyTIstO_50JwMMLi5zQHwQyjfMSQI9VulYPvtQG2w18s _o6JL_O2ILBqMs_skDm0QC170zPZfahz4An3EoUSPBvGAPezGr42KKOoEde4nsICINFJ0ui1CHuB t1VFU09irv.7jayw1CFxpBIjE2odjrLhTehvTTIY82Owj.ai0AgiKSCBexdHxRZ.NimtZ1Ll7_Df IPfXgDYZjUNLb_i_ScB8av2b1_N56dTO5JlUsuE9nvGse7glUj6i6V01JskSL5SAlvjP8bfbnc4A U0Xizdcr79yjz3f_Zf.V4Jz69hBwRHxUfgY4KzpiqaxJ6g6xmVdJuP16AEbeFv23XILiYGw2Ghsm n7rRuQSi79zpseJTPNCwSTlQA3uNHFZ2ETqfNGJUqXFn5zsOa0DVHGCXKweoVsHw04TPG9ySrNgF r9j.722v0Qs7qq7PGIo6D.VpX2aV0cgbjgv1QvvBWoQtvn9RV5b21d8znei7DxQJMBjcN2I5ubUt 15po8.nvyrFpGnR9CmbU78AFJszEFrWaiZnNrE.RHDEqIect.vPF.1kN5TWKQo4Tu.Ck7Xv2nT.9 Gk5RXUFr8ITc4Famr1Wq2g9i_nsXpd_O3eQk5YjJ2fXtw9OzCu6Uojg2WBmeKKD12X3ireFN4alq edapV3bAILaMVtQkrnQUcJV_ntQz9BhuBjzB7sU5Es6lFJWGIxCRjoEsabdTNSyqK3zYNaQcdT7x 7JtFYruNHi51IlYX.wx9tlMcTSUTYIMHSuva6vZEajrHYTMtGeq5Jb.qx8i.HGNX4l1AaSp950JF wD.WO.C45EFuvp_pXGA2tyYNeiZYTd8_9pPyG8KSasPTKIhorgPd.TIDT7bapsGT.YhyuDa9eXUL EwJJM8lFe01EKT59lhdWyS8lcrDFbt7One.yeYQmDDK0s_SqgWcgkVlzVwVANRXyCx1kinQAi8Il ZIrpFRUruoWW3toJfmU4PIowTKDW2DTUow2ca94yHTn867WVvGbCj1_qFJ9usROb0UVWkXg.TO2d YUDGV7OjhxXISuxJLUlCGGzHf37fPQsW6ZfkOOa4RKo.CZP2JWs_HI7ENgKHTqEHDTYeCuonAz5o bWJuaE0MeBMbjza3uVKFGj9U0Nv4LT496BeY4YCWRbkuyMvBcKhAeq4gsHLVS3mOvstxXpqky5NZ tb68p7KfsxwMLnzUIlY6mcfD6eljWp2W9k30J_mTmQk9rEQFTSPo6CllLhdUlYtU5nFMcitnz2Ij 36dx9OYVg5Gk4yGnk6FnxkQETLQoonFoleL09SQwIVgC2rhtA5FV1K8fkhGRQiF5dfIhI7fA0uQk Ype4q6cEnMHmmCLZn7kYhqBP0DdumBHEOjraDIvA7tx24oC77MldlkR6Fhl1gZ0YceDW0bz.CxCZ 6u2.rv8TjpzWnZhHUlo6l49LXA_YSj5Fc6qddayk9I8EN_2iwo5E.IpRU6Brrh_TjBMJfDqK1HLG D86Cs0zCsVe0fUNhlAY_eoDX5rGEdQEuq0V6ph1WgGUJ8v6VbF_kAyY_T3pKQsezaOS_Ey3AzRuk rVTTlL03POj_u4NIfAbN7ztJYwu5psZFXRP5g4m9lwEkbAI5S3F8Gjk9MXvzelRgb.KHdWj9l7YP 6i7gTO85VliJ.H7.LpbG9aggWgi6wfSL80hUVGr.A7p4devpYsqkeIK43WQxI1CLiT9A6pEi.U3t EGYF9b8iMhrmhdoLztopARxHRWR4KG7T9nP1xjhMfBYsQOF7ZpG0cD.zXop9He88vX6XA1nlTr1J ek41_AbZVNWG41dD1Cr4lJOGPBoxZNk.Vb7Zz8uxQ9RIrnH5NQdWSK1eUevpUrYIQ9cV3kkTMAZT 6QG8QwuSBxTzSWsvtzAv_cegpvBBd1Rqx3HILdjxuA6hxP8mh66741SfjfnskIKNeW9nS9vjGJgn 3cNc7vY9jyZeAEfXXg7.Sikj9l.M640BEAEcKB0g5fyNEyhm4E1YoCqcmIP3h5DggpYMu9Czh2jn hfmkH8CzUL2fvYgerBnfGFzKtiiIuKZfmDPsJNY3BC_7b2GkBS.FGOckpSpT74UG7sCbe9V0- X-Sonic-MF: X-Sonic-ID: d294cd82-89dc-4172-83d5-7a366aba8e16 Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Wed, 10 Jan 2024 05:38:09 +0000 Received: by hermes--production-gq1-6949d6d8f9-2kvdk (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID d53e3cbb6e57c20e3c29c3c851f183ec; Wed, 10 Jan 2024 05:38:05 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.300.61.1.2\)) Subject: Re: current for arm64 tries tftp first for some reason From: Mark Millard In-Reply-To: Date: Tue, 9 Jan 2024 21:37:54 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: To: void X-Mailer: Apple Mail (2.3774.300.61.1.2) X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.50 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_TO(0.00)[f-m.fm]; RCPT_COUNT_TWO(0.00)[2]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; TO_DN_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.206:from]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.206:from] X-Rspamd-Queue-Id: 4T8xR818tvz4X6s On Jan 7, 2024, at 05:02, void wrote: > In = FreeBSD-15.0-CURRENT-arm64-aarch64-RPI-20240104-8bf0882e186e-267378.img = of > 2024-01-04, when booting, the u-boot stage firstly looks for tftp. How = can this be turned off? is it an issue that I need to raise > directly with u-boot? I've only seen this behaviour before > when there's been no bootable (microsd or usb3) media available. > Now it seems tftp is tried first then usb3 and not the other > way around. >=20 > If I'm not available at the console to ctrl-c multiple times, it would > take ages to eventually(?) boot to usb3. Each line where it says > 'Abort' is there I've had to manually ctrl-c For the RPi4B context I'm dealing with I let the first time boot go through all its TFTP failures. It produced a: -rwxr-xr-x 1 root wheel uarch 88 Dec 30 00:00:00 1979 = /boot/efi/ubootefi.var that was not there originally. I wonder if it gives a means of control over such things that would be remembered? > ########### >=20 > U-Boot 2023.10 (Jan 04 2024 - 05:11:11 +0000) >=20 > DRAM: 998 MiB (effective 7.9 GiB) > RPI 4 Model B (0xd03114) > Core: 210 devices, 16 uclasses, devicetree: board > MMC: mmc@7e300000: 3, mmc@7e340000: 0 > Loading Environment from FAT... ** Bad device specification mmc 1 ** > In: serial,usbkbd > Out: serial,vidconsole > Err: serial,vidconsole > Net: eth0: ethernet@7d580000 > PCIe BRCM: link up, 5.0 Gbps x1 (SSC) > starting USB... > Bus xhci_pci: Register 5000420 NbrPorts 5 > Starting the controller > USB XHCI 1.00 > scanning bus xhci_pci for devices... 4 USB Device(s) found > scanning usb for storage devices... 1 Storage Device(s) found > Hit any key to stop autoboot: 0 sdhci_set_clock: Timeout = to wait cmd & data inhibit > sdhci_set_clock: Timeout to wait cmd & data inhibit > sdhci_set_clock: Timeout to wait cmd & data inhibit > sdhci_send_command: MMC: 3 busy timeout increasing to: 200 ms. > sdhci_send_command: MMC: 3 busy timeout increasing to: 400 ms. > sdhci_send_command: MMC: 3 busy timeout increasing to: 800 ms. > sdhci_send_command: MMC: 3 busy timeout increasing to: 1600 ms. > sdhci_send_command: MMC: 3 busy timeout increasing to: 3200 ms. > sdhci_send_command: MMC: 3 busy timeout. > sdhci_set_clock: Timeout to wait cmd & data inhibit > sdhci_set_clock: Timeout to wait cmd & data inhibit > sdhci_set_clock: Timeout to wait cmd & data inhibit > sdhci_send_command: MMC: 3 busy timeout. > sdhci_set_clock: Timeout to wait cmd & data inhibit > sdhci_set_clock: Timeout to wait cmd & data inhibit > sdhci_set_clock: Timeout to wait cmd & data inhibit > sdhci_send_command: MMC: 3 busy timeout. > sdhci_set_clock: Timeout to wait cmd & data inhibit > sdhci_set_clock: Timeout to wait cmd & data inhibit > sdhci_set_clock: Timeout to wait cmd & data inhibit > sdhci_send_command: MMC: 3 busy timeout. > Card did not respond to voltage select! : -110 > BOOTP broadcast 1 > DHCP client bound to address 192.168.1.81 (3 ms) > *** Warning: no boot file name; using 'C0A80151.img' > Using ethernet@7d580000 device > TFTP from server 192.168.1.1; our IP address is 192.168.1.81 > Filename 'C0A80151.img'. > Load address: 0x80000 > Loading: T Abort > missing environment variable: pxeuuid > Retrieving file: pxelinux.cfg/01-dc-a6-32-e2-48-fc > Using ethernet@7d580000 device > TFTP from server 192.168.1.1; our IP address is 192.168.1.81 > Filename 'pxelinux.cfg/01-dc-a6-32-e2-48-fc'. > Load address: 0x2500000 > Loading: * > Abort > Retrieving file: pxelinux.cfg/C0A80151 > Using ethernet@7d580000 device > TFTP from server 192.168.1.1; our IP address is 192.168.1.81 > Filename 'pxelinux.cfg/C0A80151'. > Load address: 0x2500000 > Loading: * > Abort > Retrieving file: pxelinux.cfg/C0A8015 > Using ethernet@7d580000 device > TFTP from server 192.168.1.1; our IP address is 192.168.1.81 > Filename 'pxelinux.cfg/C0A8015'. > Load address: 0x2500000 > Loading: * > Abort > Retrieving file: pxelinux.cfg/C0A801 > Using ethernet@7d580000 device > TFTP from server 192.168.1.1; our IP address is 192.168.1.81 > Filename 'pxelinux.cfg/C0A801'. > Load address: 0x2500000 > Loading: * > Abort > Retrieving file: pxelinux.cfg/C0A80 > Using ethernet@7d580000 device > TFTP from server 192.168.1.1; our IP address is 192.168.1.81 > Filename 'pxelinux.cfg/C0A80'. > Load address: 0x2500000 > Loading: * > Abort > Retrieving file: pxelinux.cfg/C0A8 > Using ethernet@7d580000 device > TFTP from server 192.168.1.1; our IP address is 192.168.1.81 > Filename 'pxelinux.cfg/C0A8'. > Load address: 0x2500000 > Loading: * > Abort > Retrieving file: pxelinux.cfg/C0A > Using ethernet@7d580000 device > TFTP from server 192.168.1.1; our IP address is 192.168.1.81 > Filename 'pxelinux.cfg/C0A'. > Load address: 0x2500000 > Loading: * > Abort > Retrieving file: pxelinux.cfg/C0 > Using ethernet@7d580000 device > TFTP from server 192.168.1.1; our IP address is 192.168.1.81 > Filename 'pxelinux.cfg/C0'. > Load address: 0x2500000 > Loading: * > Abort > Retrieving file: pxelinux.cfg/C > Using ethernet@7d580000 device > TFTP from server 192.168.1.1; our IP address is 192.168.1.81 > Filename 'pxelinux.cfg/C'. > Load address: 0x2500000 > Loading: * > Abort > Retrieving file: pxelinux.cfg/default-arm-bcm283x-rpi > Using ethernet@7d580000 device > TFTP from server 192.168.1.1; our IP address is 192.168.1.81 > Filename 'pxelinux.cfg/default-arm-bcm283x-rpi'. > Load address: 0x2500000 > Loading: * > Abort > Retrieving file: pxelinux.cfg/default-arm-bcm283x > Using ethernet@7d580000 device > TFTP from server 192.168.1.1; our IP address is 192.168.1.81 > Filename 'pxelinux.cfg/default-arm-bcm283x'. > Load address: 0x2500000 > Loading: * > Abort > Retrieving file: pxelinux.cfg/default-arm > Using ethernet@7d580000 device > TFTP from server 192.168.1.1; our IP address is 192.168.1.81 > Filename 'pxelinux.cfg/default-arm'. > Load address: 0x2500000 > Loading: * > Abort > Retrieving file: pxelinux.cfg/default > Using ethernet@7d580000 device > TFTP from server 192.168.1.1; our IP address is 192.168.1.81 > Filename 'pxelinux.cfg/default'. > Load address: 0x2500000 > Loading: * > Abort > ** Booting bootflow 'usb_mass_storage.lun0.bootdev.part_1' with = efi > sdhci_set_clock: Timeout to wait cmd & data inhibit > sdhci_set_clock: Timeout to wait cmd & data inhibit > sdhci_set_clock: Timeout to wait cmd & data inhibit > sdhci_send_command: MMC: 3 busy timeout. > Card did not respond to voltage select! : -110 > No EFI system partition > No EFI system partition > Failed to persist EFI variables > Booting /efi\boot\bootaa64.efi =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Wed Jan 10 11:17:04 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4T94yN4tT3z56hT2 for ; Wed, 10 Jan 2024 11:17:16 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:13b:39f::9f:25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE Root Certificate Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4T94yN1nCqz4NN6 for ; Wed, 10 Jan 2024 11:17:15 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Authentication-Results: mx1.freebsd.org; none Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:1025]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 7B4C18D4A228; Wed, 10 Jan 2024 11:17:07 +0000 (UTC) Received: from content-filter.t4-02.sbone.de (content-filter.t4-02.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:2742]) (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) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id B94DC2D029D8; Wed, 10 Jan 2024 11:17:06 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:4902:0:7404:2:1025]) by content-filter.t4-02.sbone.de (content-filter.t4-02.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:2742]) (amavisd-new, port 10024) with ESMTP id 9QvzIpB05luo; Wed, 10 Jan 2024 11:17:05 +0000 (UTC) Received: from strong-aiccu0.sbone.de (strong-aiccu0.sbone.de [IPv6:fde9:577b:c1a9:f491::2]) (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) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 923C12D029D7; Wed, 10 Jan 2024 11:17:05 +0000 (UTC) Date: Wed, 10 Jan 2024 11:17:04 +0000 (UTC) From: "Bjoern A. Zeeb" To: Warner Losh cc: "freebsd-arm@freebsd.org" Subject: Re: MMCCAM hang In-Reply-To: Message-ID: References: <49DE81A1-7DF5-48BF-A334-961A73B91E53@gmail.com> <20240109114822.522d91fea8cf170af4d895b7@bidouilliste.com> <5299p2p7-4r17-7o65-3569-o4pn3pq8r597@yvfgf.mnoonqbm.arg> <084r150q-076r-9rpn-89p2-87osq1p82orp@yvfgf.mnoonqbm.arg> <4759s3r7-4no5-777q-8r01-4192909p2sp4@yvfgf.mnoonqbm.arg> X-OpenPGP-Key-Id: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="1098556516-66325157-1704885425=:2837" X-Rspamd-Queue-Id: 4T94yN1nCqz4NN6 X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE] This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1098556516-66325157-1704885425=:2837 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT On Tue, 9 Jan 2024, Warner Losh wrote: > That makes sense. The threads you posted showed several blocked on IO while > sdhci was resetting. That's going to keep any I/O from happening. I guess > I'm not surprised it's the wrong quirks... Many years ago when I was > playing with a new, somewhat buggy SDHCI PCIe add-in card having the wrong > quirks would cause super weird behavior. In my case, it was an infinite > stream of interrupts... > > You should be able to disable the FreeBSD device like any other FreeBSD > device > > hint.sdhci.0.disabled=1 > > we'll probe the device (which for FDT checks the compat settings) and then > never call attach, but instead print a message saying it is disabled. Ah, hadn't thought so far; one too many steps. > One can also create an overlay that sets its status to something other than > okay, but that's quite a bit trickier and can't be done on the fly from the > boot loader. fdt rm fdt mkprop can do that to toggle state from okay to disabled. But once it is disabled at run-time how can you enable it again (that was kind-of my original question) because fdt disabled the device is not created. > Warner > > On Tue, Jan 9, 2024, 1:57 PM Bjoern A. Zeeb > wrote: > >> On Tue, 9 Jan 2024, Bjoern A. Zeeb wrote: >> >> Problem was in sdhci for the specific chipset; wrong quirk/errata >> information. >> >> I'll put a patch up in Phab the next days. >> >> -- >> Bjoern A. Zeeb r15:7 >> > -- Bjoern A. Zeeb r15:7 --1098556516-66325157-1704885425=:2837-- From nobody Wed Jan 10 11:35:44 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4T95My0qNkz56kFd for ; Wed, 10 Jan 2024 11:35:58 +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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4T95Mx4gh6z4Pyx for ; Wed, 10 Jan 2024 11:35:57 +0000 (UTC) (envelope-from manu@bidouilliste.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bidouilliste.com; s=mx; t=1704886550; 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=9V6JeJKXXSK/uZUc2o4/d0hyH1DWXu2L0KsaO+Ln9ZA=; b=md9PgzqgojIHcj44FGPNzUpeoXWbsEh5iUKJXVzdb1OuRJvwuH8EYGrRHY+Uk1PGVrSudc L09g+4uFdaOEiPHLwGvEV5Q5moMPQpfoef/QDrZcdnTuBIFQr/zJ+IrtKFUrnkBBdcqFHO Wd4oNbjYMnoQrYmPSopyYIg4S5+mYJU= Received: from skull.home.blih.net (lfbn-lyo-1-2174-135.w90-66.abo.wanadoo.fr [90.66.97.135]) by mx.blih.net (OpenSMTPD) with ESMTPSA id 84d5690b (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Wed, 10 Jan 2024 11:35:50 +0000 (UTC) Date: Wed, 10 Jan 2024 12:35:44 +0100 From: Emmanuel Vadot To: "Bjoern A. Zeeb" Cc: Warner Losh , "freebsd-arm@freebsd.org" Subject: Re: MMCCAM hang Message-Id: <20240110123544.af40b71f72a512c61fddf1f2@bidouilliste.com> In-Reply-To: References: <49DE81A1-7DF5-48BF-A334-961A73B91E53@gmail.com> <20240109114822.522d91fea8cf170af4d895b7@bidouilliste.com> <5299p2p7-4r17-7o65-3569-o4pn3pq8r597@yvfgf.mnoonqbm.arg> <084r150q-076r-9rpn-89p2-87osq1p82orp@yvfgf.mnoonqbm.arg> <4759s3r7-4no5-777q-8r01-4192909p2sp4@yvfgf.mnoonqbm.arg> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd15.0) List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4T95Mx4gh6z4Pyx X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:12876, ipnet:212.83.128.0/19, country:FR] On Wed, 10 Jan 2024 11:17:04 +0000 (UTC) "Bjoern A. Zeeb" wrote: > On Tue, 9 Jan 2024, Warner Losh wrote: >=20 > > That makes sense. The threads you posted showed several blocked on IO w= hile > > sdhci was resetting. That's going to keep any I/O from happening. I gue= ss > > I'm not surprised it's the wrong quirks... Many years ago when I was > > playing with a new, somewhat buggy SDHCI PCIe add-in card having the wr= ong > > quirks would cause super weird behavior. In my case, it was an infinite > > stream of interrupts... > > > > You should be able to disable the FreeBSD device like any other FreeBSD > > device > > > > hint.sdhci.0.disabled=3D1 > > > > we'll probe the device (which for FDT checks the compat settings) and t= hen > > never call attach, but instead print a message saying it is disabled. >=20 > Ah, hadn't thought so far; one too many steps. >=20 > > One can also create an overlay that sets its status to something other = than > > okay, but that's quite a bit trickier and can't be done on the fly from= the > > boot loader. >=20 > fdt rm > fdt mkprop >=20 > can do that to toggle state from okay to disabled. But once it is > disabled at run-time how can you enable it again (that was kind-of my > original question) because fdt disabled the device is not created. You can't :) >=20 > > Warner > > > > On Tue, Jan 9, 2024, 1:57?PM Bjoern A. Zeeb > > wrote: > > > >> On Tue, 9 Jan 2024, Bjoern A. Zeeb wrote: > >> > >> Problem was in sdhci for the specific chipset; wrong quirk/errata > >> information. > >> > >> I'll put a patch up in Phab the next days. > >> > >> -- > >> Bjoern A. Zeeb r15= :7 > >> > > >=20 > --=20 > Bjoern A. Zeeb r15:7 --=20 Emmanuel Vadot From nobody Wed Jan 10 11:42:10 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4T95WD0zDYz56ksF for ; Wed, 10 Jan 2024 11:42:16 +0000 (UTC) (envelope-from void@f-m.fm) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4T95WC2TmCz4RBw for ; Wed, 10 Jan 2024 11:42:15 +0000 (UTC) (envelope-from void@f-m.fm) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=f-m.fm header.s=fm2 header.b=em85p89d; dkim=pass header.d=messagingengine.com header.s=fm2 header.b=j921AUPB; dmarc=pass (policy=none) header.from=f-m.fm; spf=pass (mx1.freebsd.org: domain of void@f-m.fm designates 64.147.123.20 as permitted sender) smtp.mailfrom=void@f-m.fm Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 5784F3200B31 for ; Wed, 10 Jan 2024 06:42:13 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Wed, 10 Jan 2024 06:42:13 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=f-m.fm; h=cc :content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm2; t=1704886932; x=1704973332; bh=oPXSN7dGsX atKmrfIZVwbtOlHJOaZQRkJ3yUigGdEvE=; b=em85p89d+5Al2VzciP6I5CsQgI D3mPEghGBya8PQomgGL+YLHs4o5GA+Tbn8nPhcWh0Uog7s4+aw4XfPTfZkOmkS2l NUmIKPSuSSefDQ8IZYGiEz9fCLJa8jQVu8nAfJ4PuVxkCcsoKGG+pYUoi9uC9R+n KjjZSTcKFxxt6ZsmJgZnTVkjH76tayyQE64EH3v4rHMiXhBZXRNkObPyxJYwsHSt eaLrgVD2rM8lFdrMNT3KDmAtK1PTHK3GJr/OPcCqEYg/wnFDR/vIz4OrNof60sRY ROVatz9uceDRokDPsv/RmYEUV+JmvB4nkP1AfonwXdbCRxZMG4C9zT8Uq/IQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; t=1704886932; x=1704973332; bh=oPXSN7dGsXatKmrfIZVwbtOlHJOa ZQRkJ3yUigGdEvE=; b=j921AUPB2Zl2K2iNgLQ9pMcSnN1vk1f0GbE6CUOVcLtG iQFObN79cY4kaLx6BVreWoawzMlR1zHb7KcEwAtYau1ANJCcmMImDn6R2nOgy9vo hiaWUYl4YLk0D6jyvKgIXrj46DRmRyuFpO7aaa4vfXvfIordA2Nh6eYi25jEYPtO dS+/Kgc06Og7ROBw88JOga1d++uFlOBMgn2OlljYg74NAhnMxfjfFk/HmIUeix8C fudMR0CWY0Aj34q73n+aQ4+G1kHTS34P42ZwonjKcCB8P1aMeM+KljT+WG7VeWMu zRAQJiRKou1zAHrwwY9xQgBuQ+FiR/DAC9XFvjP6WA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrvdeiuddgfedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggujgesthdtre dttddtvdenucfhrhhomhepvhhoihguuceovhhoihgusehfqdhmrdhfmheqnecuggftrfgr thhtvghrnhepkeeluddvlefhieelfefggffhffektdehleelgfdugfdvgeekjeejuddthe ehgfeunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhep vhhoihgusehfqdhmrdhfmh X-ME-Proxy: Feedback-ID: i2541463c:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Wed, 10 Jan 2024 06:42:12 -0500 (EST) Date: Wed, 10 Jan 2024 11:42:10 +0000 From: void To: freebsd-arm@freebsd.org Subject: Re: current for arm64 tries tftp first for some reason Message-ID: Mail-Followup-To: freebsd-arm@freebsd.org References: List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.98 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; NEURAL_HAM_SHORT(-0.98)[-0.982]; MID_RHS_NOT_FQDN(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[f-m.fm,none]; RWL_MAILSPIKE_EXCELLENT(-0.40)[64.147.123.20:from]; R_DKIM_ALLOW(-0.20)[f-m.fm:s=fm2,messagingengine.com:s=fm2]; R_SPF_ALLOW(-0.20)[+ip4:64.147.123.20]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[64.147.123.20:from]; FROM_HAS_DN(0.00)[]; RCVD_TLS_LAST(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; RCVD_COUNT_THREE(0.00)[3]; RCPT_COUNT_ONE(0.00)[1]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; TO_DN_NONE(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; DKIM_TRACE(0.00)[f-m.fm:+,messagingengine.com:+]; ASN(0.00)[asn:29838, ipnet:64.147.123.0/24, country:US]; FREEMAIL_FROM(0.00)[f-m.fm]; MISSING_XM_UA(0.00)[]; FREEMAIL_ENVFROM(0.00)[f-m.fm] X-Rspamd-Queue-Id: 4T95WC2TmCz4RBw On Tue, Jan 09, 2024 at 09:37:54PM -0800, Mark Millard wrote: > >For the RPi4B context I'm dealing with I let the first >time boot go through all its TFTP failures. It produced >a: > >-rwxr-xr-x 1 root wheel uarch 88 Dec 30 00:00:00 1979 /boot/efi/ubootefi.var > >that was not there originally. I wonder if it gives a >means of control over such things that would be >remembered? Did it subsequently boot quickly? Or did you have to edit the file? -- From nobody Wed Jan 10 13:07:14 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4T97Pd6dnfz56vv4 for ; Wed, 10 Jan 2024 13:07:33 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic306-20.consmr.mail.gq1.yahoo.com (sonic306-20.consmr.mail.gq1.yahoo.com [98.137.68.83]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4T97Pd4653z4fbB for ; Wed, 10 Jan 2024 13:07:33 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1704892050; bh=xehxpjFJ2fHPgapCNqqnf7QIHX30YlTcV54SMwBxupg=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=Mm1C9mrzC5mAsClsbGpgI+fVp4WAOy9pqIgcOxsy7WQabBjZwminfJRS59PG3+sBp1m0N+s2u3wikfIyqXh1BEgLKnHLG+NWY8f+a2J2LERdFT6SK5B9dECwq6upeybFpotBpVyyrosjNX4E3Z6BBcvu5mMoUQuPEdIQmdD+E/HKt37olR9LsyP6qgxdDrg6bLwLfvUYK09P+NNb1+kDJyDdYXbNzadBb4WPK+MCNiMW1OzFcn+0SOUDP1cWl34Cb+ScP0EVanzWXGTWv5zDGcv2sqJFSNFysPHWj4FOEa6JpP86Qxsv28XmAsr9ajVsPKbz4omegdpfZg5p84ssfA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1704892050; bh=On0d4G9bhurl9Cw2SpA1772+234yLqS3l0cmTohiW36=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=bdg1yO9T+drP19RtyjkmMcNplzW3Ovi/btFdUGCnmH+KgNjLClab/aQg1wL+LQ/D2oUNGmSScuQHKiGOJ/3XRULSTx7lasxoYmb9Q96m2eedMvcMztocdAtDIi1cJYIixKhYghP21RYgoywSAxMg5N576afx75ZdxaD3fz2skA+MCGJKnC/ZzP5PaE0QaDOMp5HnjcWMDTG8TZzTh1Pxip2YxmcxJvd6AQgPF6QWU4ocjsRJzvvNc9fQg6JZRNk7eq2tTGi48w45yIBtPhC9ALp+jqNjT0H8qzl2+Z7Dn4vNIPRIP9w9ZbBqKS6y/aJ+CcSKWiqudKTIEbTX1vyNyQ== X-YMail-OSG: 5a_EzWoVM1kCOgABTGyIgX5HdT2ccW8ioo57GMk69uPEpOdwu7x8IMQ.ngDhff9 .TN09dBUI4tXH7xJluDfWAqnfT0pGatVxc6F8x1lWzSL8BVJIcK3P9FJMFb4oUr9aHcPLepS5KqB edSOQgCikgquMkqgVWm2jGVOq6Y26V6QbfI6irBYtIFpuatIbeuEqh_QtUj8qA2shoe.P2xukagh lLDON1bWsPHTm7muu5imZyojaNSkak7lV0ED9taXtQYbp9BAtFcMCpInr0Bdb2X6ZmTWMcaYPPtU 3Z9jWJNUE87cxi9WAGfYWv89ETUsp0RaadQQTmhJyLDHTqXrhnwjoNW82z9sZugbCZanfCcN6scP UiXE8zzbhLsGLvYkLr2tYAFj.e5hM1WIjRGVNHve6LEbQrh_ax_m6cGbkHvNT7ZUvgmKl5vpMpxn svYc_mGgpf1Ep3_CeK2V0g4J6UcOlKuQVovGUYIyFG.jtPSDlagpfNAl4ebDCo8HppA3tAGgo89V 4YYcouAYRlldVF2as2oeWXbZwlm5hj_qjXd.lhVCwNT6Ib4m18Ft9PAJ6rn00ZimzhetTlWoUA4E zVDqj1hRX0RZF..dLKH2.qttUQglxDX.aFLAE_XsXpNc4UtX_I_fv9oiHK0ZNtD.tEQXQ_phF1IF 140q.yswGPstRRYC4I0HTXMznpAZ4gCTW3RO7FjyYG8NFv33GsMdBdxrM9RI.VAPuf225gRjIuO0 a4g6gzQEEywq1bgQWM5ZiEe0fDXSLTLlr77vNMg6epvf0jycoP.mqaO4PIyO.5VrvWwFf.GOJFLn b66HhBsWS0GU04GOYbCe9Tj_4csv9usN_kL_NSz2owt_O3sXZ5crcu.1O637Ty_Kq4fKAz0z56rW jQgySN5Go.SMyDg5jXKcsDs7cim6Tq.Ft1Sh0t5t4VyHA9PQ1ciCgdd.hEfwEqZHSJ7ZR1R.XNLW Hg8pmA0R99S4jTV2eqdr49YwRBbhRn63pXbULETtbUdppH1wPnigiUyRQnfHhh7aCR.Zsrme2zxg FD_L7M.TEOOZ.7kROxY.Wxb1JxulUV3Yw8ls7rPtr8Z1DzJtcr9oNm0tDzTgWnZ5g9KZ.2._3R.N f62NARva4qT_HbBkDhMzvzGkn0pjDON_Lzso7V_90b2Bxgp7qhyRWWpJgDpmDaLznphj3k8NVlMd uCfwMzrshkKPBrVpiFJEXsfufy0F99V_wpB.o_qUAg9sZpEGzB__kI4jTTsSZSn0932BqIHHNnSG PUCBz4_eYRJ2J28Rz0M2LVnAe_Fi5FqFiJD9FB5.zLVpnNjAdGUQ7CSSz1.y.07XO_1biPDD7blK NimrXZVLThSKDKokfp20w1b7gC.xxaNz3kf6kuwgRXIAbpikqVD9YFR8jH7zjNaTaGkQfO.7wqLP ygDvUnkL4_knujr3aRI6N46qf1JpXLcLUsiu7E125yp42lEmKAHc47bPox9liJtYRFWSr8tIco.J 5ax3nmWzKbAn_oWDa5BWS8_RtpZ7iAj9QV8FiJN73nN1eiFOCV0SftJXl0dz1_xAGtZQJgbsGcag ULl8zdDWtdxfwnPKtle58GpyBMgDiM0g2xv4UdIzkUzcIw9_avh8kkbvHlqPjVxWNkwdqF7VHJvT mfJ2L5XjT7jhhbm2j93RR.C8oDfrfSGy8i_tru5m6UtIKXOx6RP6dMJjACybRtIJNPx9XBHIFIO2 0TtM_RW7xWvreZFUcDY1Z25_2WKKAn6.oYO96ftVZBC9natdoLA8jgQcAL42oI0cpYIjclIZQtBY N9iBuv0Pu1sqYgNCHUC7yvQrpxBlLDI7fP73U8v_nsWy0_yfZTh73YYo1BFsT5eRWQDxRMzafNyg elLyRjG2TCZy1scADV.WYjMb23IJUasOZKIPYRBek.fI8DlFXqwZnX5st29Iod1apW9Kr87R4dpH rGJPDXUNKMOfYyjsD4rHsBg5l.yRdt8YYlhQSixd0icOIGUEUM7AXEag0iJQDmtXQeDj18Oz9ynK Cg5aXUZpIel.L6JP3eTCeQtrrcy7jbf0AvA5ETWs0kQpcOTZEtQdflPbNPfQGp.9xY4rARLSZiOS 6Args3m5.KGQxKcGRYqGOj.2zGAJCozmzEy0dPPkOjq5uP.vhkRqnT2Yb6kmYGWs_85J3egjVGtz YsbHyv9kdTWz.I3dUJ7rUVRLE7P_h0QEs3HDAaQukc4JXFiqcUzebkHT3oj0LGrvA9JKdiktD413 IgPoekEEf3rzA8F0BRcM7s7tU89OSMpEzero5Jf.83YafL1WvrRAXPVCu0IBYcg6X1VgZryE- X-Sonic-MF: X-Sonic-ID: af14291b-650c-4bda-be7f-e789d86d67bb Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Wed, 10 Jan 2024 13:07:30 +0000 Received: by hermes--production-gq1-6949d6d8f9-vrqtp (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID ec6d051b8a22f2d9f02d4973385cc925; Wed, 10 Jan 2024 13:07:25 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.300.61.1.2\)) Subject: Re: current for arm64 tries tftp first for some reason From: Mark Millard In-Reply-To: Date: Wed, 10 Jan 2024 05:07:14 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <856D59CC-E55C-4667-97EE-458104C8DFEE@yahoo.com> References: To: void X-Mailer: Apple Mail (2.3774.300.61.1.2) X-Rspamd-Queue-Id: 4T97Pd4653z4fbB X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] On Jan 10, 2024, at 03:42, void wrote: > On Tue, Jan 09, 2024 at 09:37:54PM -0800, Mark Millard wrote: >>=20 >> For the RPi4B context I'm dealing with I let the first >> time boot go through all its TFTP failures. It produced >> a: >>=20 >> -rwxr-xr-x 1 root wheel uarch 88 Dec 30 00:00:00 1979 = /boot/efi/ubootefi.var >>=20 >> that was not there originally. I wonder if it gives a >> means of control over such things that would be >> remembered? >=20 > Did it subsequently boot quickly? Or did you have to edit the file? The file is not a text file and I've no clue if any EFI variables happen to be related. The HoneyComb automatically booted faster after the first time. The RPi4B and RPi3B have not. More to figure out someday. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Wed Jan 10 13:14:49 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4T97ZM2P0nz56wcS for ; Wed, 10 Jan 2024 13:15:07 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic316-54.consmr.mail.gq1.yahoo.com (sonic316-54.consmr.mail.gq1.yahoo.com [98.137.69.30]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4T97ZL2XmFz4gtP for ; Wed, 10 Jan 2024 13:15:06 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b="mdm/zZmO"; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.30 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1704892503; bh=KWmLnMnjFg+9Rj7VEEDzw0GQDfoilwXHumfAKMbg57g=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=mdm/zZmONTqTQ5VI+DTumyqPE8UBREsKQKMDZLTkFdzXagtOBd9Ng2RDJfbswskKYRrTm4wmplzIa9lhICdqFgw7pakPCmh1y2ht9Siltlj+d10PWAzYGgHxdzXjQZHbPNm+u2BcuKD4KJ226V3IfbrX458V330ZhIZP13oOokFxsnXLHteQca+epwsTMeOoFoZHnpDOG2yvip/2PNKgbwNkLAUNmDQIFc69m9tDyfHJ4CdOFpSESAJhHxmh1ySjoSp8BzaoJA7PlLtta8hFwdruBBoiqxAhmVBl5GXHKU5wcD62wU0cd5e2eTn/t62CzbfbtlwwT7TpevF+3uSV5w== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1704892503; bh=ooVSKXFB9AMgX7NCbgfmCFGyNm1E1C2PTUQYFrLaqo4=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=mhvUYGyUYur090KL1WzEkwRkbjtU4+Rat7yEv2DdlVKq2VpHGqIgSEQBHwPOHO7jfrcYBBsr63FX3P1vMCFRjiJg/M+i3VdA0XYbzKgV+iXJ+FgZesVuJDW+4DWlR35JJ1wjDFSUCKNmQ1LYUzTAj+HpoR2V7OyVkxYUmOx6p6M2EQbstCovH3yBW5MSwTlQcjHbxGDIOCJGZsqO0KrK5ag1MxtVL+/C6deZFxgqVOTAqZpMHNoXz7XZWhCVS1ggTFkjJz+fiTWov534zNtwhlrAFQeq1DBgraNtKlBtr5Ncuyl5OiOzE1VHCtokKdUlFKNZK391ZDnM01pOzJl9XQ== X-YMail-OSG: z1t26oQVM1moQ1gaJk9FrO_6dKuetpgkuR7yRoTc0O2cuqIWil7NUbrnRCohMlT s.nD95QtK7bp.vGoUXxng31W9KDtGvN_kPiDd36U.2AuwExmb3YtB.BOEUf5V5odgrLduPlu6YOZ tZ.hwvG1Fe_NNmViOb_AV0JrlexzdO.rIqpJpQmLvHQrd5ffJeNVHd9ZL4dr6fMnqiM9wLB1S9R7 UL4P_lr1wAbJp5ordV8pX8HLIRbKIzNH0WFx7qxzdClZGecbC48DX.eLaAECpsx7EgSCWd3JHQYh 3EV4jlGpqrkmtPs01ObUQZbiiCGg3FcC2yIX_UUZyOXBsHEDhSELUc0jAfIIJEfGJZ13HbpuNMuR lCvLsoAilDD10f9AmUJkXfcaHi_ssNy2YyQ3tZXocJcyQY0QXhpT3_PcevcgUsrDRjJp_KcAkN3p 9Yavoq68uXJol00bTj1Ef5Q1xm_QuLkWQCxyv9advyoht5RDhWcCYSoSo.IlOtI3wc55ZfPNw.Dg lgyuZanPiQ61UKhkZRPL0it0lEqNURBoZuWoiwf4VyuBys6atKdM5_ifKmF6vslIENnoOEjiJQ6w sV2TDHs54Vhq1GUjLQCPTGorYflMrl8f90jhz0_4YHH_81OBPZVMXSBrFWjHTJUoH8TKIhBXIMqk UVNziuxvqIYPr23aLn14c8ZCDjReqFRbWkK7Fg8fSpTwVefGYKuD0PeULuPlz7x1qwlu5nkXYAks qzHuufjChTo8mr0LZyhwpK0BcuRUi.EethTohWoNfh7UgkU97iTGmKHG3nh.X7PJpeN3jnlL.DWi LtYkMvUqXr_GjlX3trphgT0BhrxZnfQjSx2zw92g_nDkH7qEYmbjWoIzquHLmaWwHvuwuBwX7OAX ocyNtbaZDmQLOnu11zEnPp2suuiudLc9SQIKNv3KWZeWGXa2weTAEDIhIeALXSu7jUu7DyKvzrk5 k.CvkTv2PjfmsPUZLmkjhUf7Ke2rDYj_d4NnAfPcerlQ_H2E.RDDqCRcu6M_BU9LHgWPMoKp8WXP T5nCXYIFUnFe2x.Xl1uon6xu4v.f8fsVduYHuQSD4u8sG_0ZN1ls3m7fAQljVsKBf2rIzO7A.e99 c6kRkmranRihgU2uz7dnorTg9Stqcq7BakOP9nPBq5t.Uv6iL8T3YZtdAqiZfUp4PNOJlY0hB5vj ESIi8Ib_PzVdMdc8vu912BvKFZXGsWLdSMPMxns5el1b90AOP_Vp.i4Y1VYJnjb0Kfglt.vgE7K5 F72eOkP3VGBGjh568qDiSRSkiqXKhzg1j.i6UvduJqiI1bVwOUHyuncRRiW8KwhTKOTnSw7uJhvt _vCtF6UPVYPTEqD1Gx93OYVUqmUynbmmpY3geFi0phBV4yC5o1Cb2DL_FOH8c73fXqsNdv67eXkU gt9Msgl0XwT7LAPRG5kLskr0OiDRTM2PS.Q1irUwM4W__dj4cYcth08H_RhK9nNNL1.b11ofXbOr 9P9zkUbns9xpBPYUHytlx4ns_e5KEQhufCmLAuY3G.saOK5oOlEFYBBFE7oBud9kTOmQsFLtgBpo vo9COg02Cw1Lg8t1j492VoeRte6_39AYWQuWgMFiao30yQPrqbnYnr03MUT4kwnCeFWdXbssgu4J Xm55s3XclOgwqxnCT0Aj715jmz_nZxU47UGx9VgzTyupBjEu8IHAZutxjtRc8Vb2ae8i.ZPxj2Fx TRAwH24Ef5p1JOiiKDK2LJWLJAhr9sai8MywraybG6kwyQtQhTlOTWrg95KsCkHv48vdhv0rrw70 .ggQTjfzhzaoIO9J11ALTJbZK4LCViG7Iyda7WsgeUFGaz69.K8o4txJOdEFtJWp0pkoNP1KtUTy 0s6kEwUvEGYwHx1waq5Qm4zk4Rdj1OHwyarGEQZc4FR0MqwCYTEqrzFRfGaX0Wzr5K_mP.UQbWdl ThfeNZM3lQwKHt42_b0drBMKqQ2THxyDVZS1N_I3DsgDit71dJXHelQZHqvWlLI9ibOO_p4S1bhr lH1AaP8VZJ.OSVR9xfdbqT.ppWpUXu9iRA_mf6_5VfVezEi_cN1aCfw7FYbhbRcz4fnurHN4eHlN 4Albus25ljCXlpoX_HhT4Yo5HhC_Jvj.c8DMguvILn3EcvcB76dC16uiHNuX3wZCClwOUGqW5PAS 0uE4ZFYDIsLnPsrf8sfw5I2X72lJxyorOaRoyLKAqDzFKLaMPBP3mKHN5XJDGipsE2P7hzu9pZEM HruvhzgWiIN6tjFsfqShEdb9OqhHmHiizHCe7G7c087MTTHPw_DNel7jH1XLoQ2wtEsrwPw-- X-Sonic-MF: X-Sonic-ID: 61a01b70-9dfb-42b5-8a37-a1d64a30b493 Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Wed, 10 Jan 2024 13:15:03 +0000 Received: by hermes--production-gq1-6949d6d8f9-d8p82 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 0b0923d0c96dcf3953192408f2f91b3c; Wed, 10 Jan 2024 13:15:00 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.300.61.1.2\)) Subject: Re: current for arm64 tries tftp first for some reason From: Mark Millard In-Reply-To: <856D59CC-E55C-4667-97EE-458104C8DFEE@yahoo.com> Date: Wed, 10 Jan 2024 05:14:49 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <1E55A7B4-1AC0-47F6-9418-4310268632D0@yahoo.com> References: <856D59CC-E55C-4667-97EE-458104C8DFEE@yahoo.com> To: void X-Mailer: Apple Mail (2.3774.300.61.1.2) X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.50 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.996]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_TO(0.00)[f-m.fm]; RCPT_COUNT_TWO(0.00)[2]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; TO_DN_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.30:from]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.30:from] X-Rspamd-Queue-Id: 4T97ZL2XmFz4gtP On Jan 10, 2024, at 05:07, Mark Millard wrote: > On Jan 10, 2024, at 03:42, void wrote: >=20 >> On Tue, Jan 09, 2024 at 09:37:54PM -0800, Mark Millard wrote: >>>=20 >>> For the RPi4B context I'm dealing with I let the first >>> time boot go through all its TFTP failures. It produced >>> a: >>>=20 >>> -rwxr-xr-x 1 root wheel uarch 88 Dec 30 00:00:00 1979 = /boot/efi/ubootefi.var >>>=20 >>> that was not there originally. I wonder if it gives a >>> means of control over such things that would be >>> remembered? >>=20 >> Did it subsequently boot quickly? Or did you have to edit the file? >=20 > The file is not a text file and I've no clue if any > EFI variables happen to be related. >=20 > The HoneyComb automatically booted faster after the > first time. The RPi4B and RPi3B have not. The reference to the HoneyComb was incoherent. Ignore it: not a U-Boot context at all. Sorry. > More to figure out someday. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Wed Jan 10 15:45:11 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4T9Bvl5NtGz57CTZ for ; Wed, 10 Jan 2024 15:45:23 +0000 (UTC) (envelope-from dfr@rabson.org) Received: from mail-yw1-x1132.google.com (mail-yw1-x1132.google.com [IPv6:2607:f8b0:4864:20::1132]) (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 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4T9Bvk3t8Sz52pZ for ; Wed, 10 Jan 2024 15:45:22 +0000 (UTC) (envelope-from dfr@rabson.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=rabson-org.20230601.gappssmtp.com header.s=20230601 header.b=VZgpacr5; dmarc=none; spf=pass (mx1.freebsd.org: domain of dfr@rabson.org designates 2607:f8b0:4864:20::1132 as permitted sender) smtp.mailfrom=dfr@rabson.org Received: by mail-yw1-x1132.google.com with SMTP id 00721157ae682-5f07f9d57b9so40664137b3.1 for ; Wed, 10 Jan 2024 07:45:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rabson-org.20230601.gappssmtp.com; s=20230601; t=1704901521; x=1705506321; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=t3tpLxv0tNCbnosVuAHf1mkIbN/DOy7n3x8uB4xxhWk=; b=VZgpacr5D2v278cVWZ7oR1bNR7yOCgji+R6aD38ekUNznJhEV0/YEIufsI2v0cfNha wxxMuUzLvnI8TpuqiSefwaqqLlvErtzvL/vIKA4TPxAufKvWmg2DR09acMsG+iVkm2Bo 0MIQJx08ZRDFTKdx4BVTtfmZiM3cS1T/RuMWnvgG3bk8npvCYpO+ZDxDdSb4qhDk4Jnf htT5IMIvOtMij1NOkOM6LcCo212vKYjDAk/Pr+gXlPcfrvhQMcqGJYZjVuQllb0vfuBr MF9w4BgtJteKSGSooLZxUOHzC8JVPCwol2B2XB/rGkscrQXH8J7Io50ElXtMppabWAEd LYIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704901521; x=1705506321; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=t3tpLxv0tNCbnosVuAHf1mkIbN/DOy7n3x8uB4xxhWk=; b=o0jGhwuYozoIBhBz88MLCyRNjR7ZUwAKPmJJT5Rp3UJe4cuwXhrfrWc83I23A6PJpf S//KDV8+y7iJH+IF3hZP0gUzEYB/J8Vo/chbCMCtyj3JCaQ5rQGINnry1l8C10x7tBlx zw3SaQ2Vi84vgI+XIvFXlsZ0uKRVLLqq3F5JPy20EMkhtCJnwYE/a9OdaSGYjl1/Pls4 aHExoIcdqcoyOWErHdo6fPdNBlo8FUF7fHozI/9LHTAr31xXCQp+jBW14NZw127vv4Mk TVh1BzvqrJdremk+i+KTB6Y8TZyLVsJJdKXR5vEvwTjp7qaUlJ5Cma3EAj+2F3Doc4sV 3Rbg== X-Gm-Message-State: AOJu0Yx1TBxI2zAG9Ba3pA7mggjSXLSQgLeqLFbZ3+Q2YlA4ifeWplqY lJWGwKVmgV7QRMxRfuETSnjxAAUL1It59tp2bcbCH83Sn5Mjlg== X-Google-Smtp-Source: AGHT+IGt68d9fMvjokbwwSd+bYDElVIercI5OGyqJN83ORAolAP4rPB+wDYFCuMzSZtJJxQTzVjZpDXPvKfiwP0eIW8= X-Received: by 2002:a0d:f743:0:b0:5de:a261:9074 with SMTP id h64-20020a0df743000000b005dea2619074mr1287359ywf.7.1704901521325; Wed, 10 Jan 2024 07:45:21 -0800 (PST) List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 References: <5a39810c-5fd8-4969-a222-2561b050b035@FreeBSD.org> In-Reply-To: <5a39810c-5fd8-4969-a222-2561b050b035@FreeBSD.org> From: Doug Rabson Date: Wed, 10 Jan 2024 15:45:11 +0000 Message-ID: Subject: Re: When will FreeBSD support RPI5? To: Jesper Schmitz Mouridsen Cc: John Kennedy , ykla , FreeBSD ARM List Content-Type: multipart/alternative; boundary="0000000000008e522c060e995121" X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.50 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[rabson-org.20230601.gappssmtp.com:s=20230601]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[dfr]; RCVD_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MISSING_XM_UA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::1132:from]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; FREEMAIL_CC(0.00)[phouka.net,gmail.com,freebsd.org]; DMARC_NA(0.00)[rabson.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; DKIM_TRACE(0.00)[rabson-org.20230601.gappssmtp.com:+] X-Rspamd-Queue-Id: 4T9Bvk3t8Sz52pZ --0000000000008e522c060e995121 Content-Type: text/plain; charset="UTF-8" I was able to boot FreeBSD-14.0 on an rpi5 using EDK2 from https://github.com/worproject/rpi5-uefi. I put the EDK2 firmware on an SD card and an aarch64 memstick image on a USB thumb drive and was able to boot all the way into the installer. PCI express is missing as well as ethernet but it's a really promising start. Doug. On Wed, 3 Jan 2024 at 15:10, Jesper Schmitz Mouridsen wrote: > > On 31.12.2023 20.37, John Kennedy wrote: > > On Fri, Dec 29, 2023 at 06:05:25PM +0100, Jesper Schmitz Mouridsen wrote: > >> On 29.12.2023 05.55, ykla wrote: > >>> Hi, When will FreeBSD support RPI5 > >> https://forums.freebsd.org/threads/raspberry-pi-5-status.91406/ > > Having ordered my RPI5 ~11/28, I think it has a shipping guesstimate > in late > > Jan/early Feb. It looks like someone is working on uboot, which FreeBSD > seems > > to favor (I think the argument I retained was "it works for lots of > things, > > piggyback on those efforts rather than have some RPI-unique thing). > Then once > > you start getting things properly enumerated to where you can load the > kernel, > > then you work on the kernel drivers. > > > > RPI seems to favor linux support first, and I suspect that there is a > fair > > amount of GPL issues that you might have to worry about creeping into > the BSD > > kernel. So not as simple as reimplement from what you see in linux. I > know > > there are a lot of strong opinions on video drivers, for example, but > for that > > to even ben an option it'd have to be something that could be a module > that > > could be packaged outside of the BSD base. I only bring that up because > I've > > had garbage luck trying to get serial consoles to work properly on RPIs > when > > they're competing for things like cooling fans and such, so graphics > console > > is nice, even if it is just very basic. > > > > How have people been chicken-n-egging the initial setup? I know > there have > > been uboot issues in the past. Seems like you basically have to build > memstick > > style images and see if they boot. Is there a bhyve/QEMU setup that is a > > generic test setup that is used? > > I just built a patched u-boot and uses a stock rpi img snapshot, then > cross build and move the kernel to the rpi sd card.. > > no qemu emulates all the phys. hw in the rpi5.. > > > --0000000000008e522c060e995121 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I was able to boot FreeBSD-14.0 on an rpi5 using EDK2 from= =C2=A0https://github.co= m/worproject/rpi5-uefi. I put the EDK2 firmware on an SD card and an aa= rch64 memstick image on a USB thumb drive and was able to boot all the way = into the installer. PCI express is missing as well as ethernet but it's= a really promising start.

Doug.


On = Wed, 3 Jan 2024 at 15:10, Jesper Schmitz Mouridsen <jsm@freebsd.org> wrote:
On 31.12.2023 20.37, John Kennedy wrote:
> On Fri, Dec 29, 2023 at 06:05:25PM +0100, Jesper Schmitz Mouridsen wro= te:
>> On 29.12.2023 05.55, ykla wrote:
>>> Hi, When will FreeBSD support RPI5
>> https://forums.freebsd.org/t= hreads/raspberry-pi-5-status.91406/
>=C2=A0 =C2=A0 Having ordered my RPI5 ~11/28, I think it has a shipping = guesstimate in late
> Jan/early Feb.=C2=A0 It looks like someone is working on uboot, which = FreeBSD seems
> to favor (I think the argument I retained was "it works for lots = of things,
> piggyback on those efforts rather than have some RPI-unique thing).=C2= =A0 Then once
> you start getting things properly enumerated to where you can load the= kernel,
> then you work on the kernel drivers.
>
>=C2=A0 =C2=A0 RPI seems to favor linux support first, and I suspect tha= t there is a fair
> amount of GPL issues that you might have to worry about creeping into = the BSD
> kernel.=C2=A0 So not as simple as reimplement from what you see in lin= ux.=C2=A0 I know
> there are a lot of strong opinions on video drivers, for example, but = for that
> to even ben an option it'd have to be something that could be a mo= dule that
> could be packaged outside of the BSD base.=C2=A0 I only bring that up = because I've
> had garbage luck trying to get serial consoles to work properly on RPI= s when
> they're competing for things like cooling fans and such, so graphi= cs console
> is nice, even if it is just very basic.
>
>=C2=A0 =C2=A0 How have people been chicken-n-egging the initial setup?= =C2=A0 I know there have
> been uboot issues in the past.=C2=A0 Seems like you basically have to = build memstick
> style images and see if they boot.=C2=A0 Is there a bhyve/QEMU setup t= hat is a
> generic test setup that is used?

I just built a patched u-boot and uses a stock rpi img snapshot, then
cross build and move the kernel to the rpi sd card..

no qemu emulates all the phys. hw in the rpi5..


--0000000000008e522c060e995121-- From nobody Wed Jan 10 16:10:51 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4T9CT74Rthz57G5F for ; Wed, 10 Jan 2024 16:10:51 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4T9CT72VmMz556r for ; Wed, 10 Jan 2024 16:10:51 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1704903051; 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; bh=o6307DxX016UsdgCJO7EiIBkSQADpgfzCAWstCB/vck=; b=ieATA6BuUmLi7SepWsRtInVSBi3/zJjJiCIxWmUNF7BlyAjDj8oIcCOe52YXW8eL8V4+Ag 0a6FLWsINgEGMoB5YBn21/TPRF+D1R4sNdbnOxTmz9KKqss6Ca5WpLXWj7fsa1DlvUOyUK f6JYODerw5Uqdk4dSoXWHjyQ3NcOfiBzIlshXHFYkwpRTsJPzqys9FVzRHenmpHOZLM/Go RslCo3aDZ1JCI3elJ1h3h58dON/tj7xUDzmk9z9Wa155OjuKrIW6ymew53BS4nCWdXyLjN yM9oG7O56ZaAWz15fA9LnXEB/YLDw3W26dDHF6tcvHF5Jdu3b3D/At5ICZiqwA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1704903051; a=rsa-sha256; cv=none; b=f/7MPPjOOwt/wWmW08g5G7+Zy6y0waNJGbUP4nVPAJ1/FbcB7qz1DIXBzOa/eWNRvlm6M3 gs3FdPkLBlaWDJAAnBXo/gQLIYo7pPhZEZ3YhnFsP/DCrnBv+oYaL2pJdHXJFMSLc+rXPK 083jmLB/wMqyBtqfbb/ZlXo4/Uk8GZ9Av/PukXzD4zkpa2AsjhSuYrSuEgsY4Mh5HQB3Yx yH6q8q8AfS/QSCFiKCKooOeZDvyMTd8DRAPo8R+gPjWTDFShUf8qFKPEh8vebabWkPUQBT Vgw+6vNgrQVYPmjST6NVaFunWh/KEDpwyDbVgCs9Z9hsy/Eur5Rj9/cSgW7WXQ== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4T9CT71ZtbzhxK for ; Wed, 10 Jan 2024 16:10:51 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 40AGApP9098166 for ; Wed, 10 Jan 2024 16:10:51 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 40AGApwh098159 for freebsd-arm@FreeBSD.org; Wed, 10 Jan 2024 16:10:51 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 276242] Attaching e1000e NIC to aarch64 ancauses ifconfig to hang Date: Wed, 10 Jan 2024 16:10:51 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 14.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: mxb1143@student.bham.ac.uk X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D276242 Bug ID: 276242 Summary: Attaching e1000e NIC to aarch64 ancauses ifconfig to hang Product: Base System Version: 14.0-RELEASE Hardware: arm64 OS: Any Status: New Severity: Affects Only Me Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: mxb1143@student.bham.ac.uk Attaching an e1000e NIC to an aarch64 machine in QEMU causes ifconfig to ha= ng upon trying to bring the interface up during boot, causing boot to hang indefinitely. Booting into single-user mode allows the system to boot fine,= but running "ifconfig em0 up" causes the same behaviour. From my understanding ifconfig gets stuck in a syscall(?), rendering it impossible to kill. Other= wise FreeBSD seems to recognise the device fine, assigning it "em0" and chatting about it during boot. It also shows up as an adapter in ifconfig fine before any attempt is made to bring it up. uname -a: FreeBSD freebsd 14.0-RELEASE FreeBSD 14.0-RELEASE #0 releng/14.0-n265380-f9716eee8ab4: Fri Nov 10 05:54:07 UTC 2023=20=20=20=20 root@releng1.nyi.freebsd.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC arm= 64 freebsd-version -kur: 14.0-RELEASE 14.0-RELEASE 14.0-RELEASE To reproduce: 1) Download an aarch64 release from https://download.freebsd.org/releases/VM-IMAGES/14.0-RELEASE/aarch64/Latest/ 2) Run with: qemu-system-aarch64 -m 4096M -cpu cortex-a57 -M virt -bios edk2-aarch64-cod= e.fd -nographic -drive if=3Dnone,file=3D/path/to/fbsd.qcow2,id=3Dhd0 -device virtio-blk-device,drive=3Dhd0 -device e1000e,netdev=3Dnet0 -netdev user,id= =3Dnet0 --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Wed Jan 10 16:31:08 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4T9CwX2J40z57J4P for ; Wed, 10 Jan 2024 16:31:08 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4T9CwX0W7cz57s9 for ; Wed, 10 Jan 2024 16:31:08 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1704904268; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=P6wSUU4fFHr8aCKXzG9NAd0i51w85eI9CDqst51A//4=; b=tAXOpP17s3xpQKVdRHCwmwa7HTEOo0MsMZlZJ4PUIijEBljrcQryykA4u/N/tyLhat7oYj hfLSIx9G60xMe0TeqJU2ASAQ9ryHxukUdQY09RU1iZu56LpwdmCT+K04vQTkyuK9KfGHM1 r9womzidu6HsdzaWCm1wICEF014LjlppJ4gXLNsNS9lW8ZHLUxX47Iopgx4lsDk7+uYxj0 JPj9SzGbGVo3ieZte4ElCDi9yie8//SjLKqrjLCyEp/v0w0xANEVw4bTUW0IKntZCGyXjQ eo5gd3yCnYeoT5vFgYn5jOvXgajVty0za4IaRkTxyTja3qiOCy+ISqQIfVq8dw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1704904268; a=rsa-sha256; cv=none; b=U3qs8r/j2vvA/4Mw+nIJfXZu+irzJDW2h3hpnuxjZEMDsAmlK/E6lREB9lV4SZKf7I3UuX n7K/UO+Kbpo14DxO0zcJBaZ5m950qX8Pe7Z1fK3pD2tIJwg0jQxI4cPkCjuz9z3aU0M+zO yXROL83OLlp8bJokMa7/An7nBKJGtVWF0YwgeesBz4Jr+K4/g0bX6mrqFL9asl4kWjJUWo CwqdQaX5LlYxGFDo3bmO0CSqMbab+6f+aTW3dJksumntZMba3Lv/9p+myV+dcBKeyj+d2r GoDVsWpDfqAUQ2422Oi1WXPevLg9xH+bBW2u8XuDDg5nOsnXQR0nIo9Hylv5LQ== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4T9CwW6h4SzjWT for ; Wed, 10 Jan 2024 16:31:07 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 40AGV71d014206 for ; Wed, 10 Jan 2024 16:31:07 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 40AGV7Rw014201 for freebsd-arm@FreeBSD.org; Wed, 10 Jan 2024 16:31:07 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 276242] Attaching e1000e NIC to aarch64 causes ifconfig to hang Date: Wed, 10 Jan 2024 16:31:08 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 14.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: mxb1143@student.bham.ac.uk X-Bugzilla-Status: Closed X-Bugzilla-Resolution: Unable to Reproduce X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: resolution bug_status Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D276242 mxb1143@student.bham.ac.uk changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |Unable to Reproduce Status|New |Closed --- Comment #1 from mxb1143@student.bham.ac.uk --- (In reply to mxb1143 from comment #0) On further testing this is not reproducible using a different version of QE= MU, so this is likely a QEMU bug. I'll go ahead and close this. --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Wed Jan 10 16:57:08 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4T9DVq25vYz55N4G for ; Wed, 10 Jan 2024 16:57:23 +0000 (UTC) (envelope-from stanislav.silnicki@mailgate.us) Received: from mailgate.us (mailgate.us [185.72.246.236]) by mx1.freebsd.org (Postfix) with ESMTP id 4T9DVn3zd9z40fr for ; Wed, 10 Jan 2024 16:57:21 +0000 (UTC) (envelope-from stanislav.silnicki@mailgate.us) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=mailgate.us header.s=mail header.b=pBgMbuwB; dmarc=none; spf=pass (mx1.freebsd.org: domain of stanislav.silnicki@mailgate.us designates 185.72.246.236 as permitted sender) smtp.mailfrom=stanislav.silnicki@mailgate.us Received: from localhost (api.telegram.org [192.168.2.1]) by mailgate.us (Postfix) with ESMTPSA id 7C8AA3AD95 for ; Wed, 10 Jan 2024 19:57:11 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailgate.us; s=mail; t=1704905833; bh=UOAuRf8RNB3h2BdK3TfzIARlIV/W+JsVPIb+A/dpj4A=; h=From:Subject:To:References:Date; b=pBgMbuwB5iAuFOQHrPj1wS4w4fRoyrMuCjlnM3xX5v9LN4rLUx3g8aIm0qNUaiLxU vxbQ6SGcVAZLYyXFbCnBfx5spdlMziQTc78Q1ADj9jUZHY0GLJRtWEvVvPhogWr7ow r61/9ifpI1aoxlUmsOJfd1kz0zsWNTzTSmDhAAm0= Content-Type: multipart/alternative; boundary="----sinikael-?=_1-17049058292700.7558567376711265" From: Stanislav Silnicki Subject: Re: STM32MP157 X-Type: reply To: FreeBSD ARM List User-Agent: Desktop Message-Id: <686297325f0d8.847517e9afdee@mailgate.us> References: <4d6bf0126f4fb.c24cc5f2fa47c@mailgate.us> <00cab7929791c.8af55c0bd1d5f@mailgate.us> <5d65957f4c04a4bec7ae6ef5469b149c@ohdata.se> <0dab0fc75864.77e1118ea80bb@mailgate.us> <5aa7e3eff95c.2102a80bb1a3b@mailgate.us> <0926803a4f0a.17799edcfe428@mailgate.us> <19de1a006e313.760d63ffe37aa@mailgate.us> <41EBB5DE-EB46-435A-98FC-9017A2CE3B10@mit.edu> <689d44174e0f9.1733c7a78ebda@mailgate.us> Content-Transfer-Encoding: quoted-printable Date: Wed, 10 Jan 2024 16:57:08 +0000 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.64 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; SUBJ_ALL_CAPS(0.75)[10]; R_DKIM_ALLOW(-0.20)[mailgate.us:s=mail]; R_SPF_ALLOW(-0.20)[+ip4:185.72.246.236/32]; RCVD_NO_TLS_LAST(0.10)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; XM_UA_NO_VERSION(0.01)[]; ASN(0.00)[asn:47447, ipnet:185.72.246.0/24, country:DE]; RCVD_COUNT_ONE(0.00)[1]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+,1:+,2:~]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; DMARC_NA(0.00)[mailgate.us]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[mailgate.us:+] X-Rspamd-Queue-Id: 4T9DVn3zd9z40fr ------sinikael-?=_1-17049058292700.7558567376711265 Content-Type: text/plain; format=flowed Content-Transfer-Encoding: 7bit WIP status: So far implemented: - u-boot config + DTS with SPL (only secure mode). A port is prepared and compiled, while pending dev. testing. - uart: EARLY_PRINTF, low-level driver interface (full console). high level methods are pending implementation, though seem trivial. - SMP: second core is started Pending: - sd/mmc (a must) - rtc (seems trivial) - net if driver (optional?) Couple questions to community: 1. Shall I consider any other parts to port to be able to pass phabricator & review? 2. My current board with STM32MP1 (Karo's Qbase4 + QSMP1570 module) does not have sd card connector soldered. May I consider a description in port's README of how to solder an SD Card to be able to boot from one? There is also an option to describe how to flash onboard 4Gb emmc chip. A special question about 32bit systems discontinuty: is it mainly a warning for i386 or there is a real plan to abandon armv7? Stan Stanislav Silnicki wrote: Reading TCMTR shows 0x0, so is looks like TCM is not implemented in my case... Stanislav Silnicki wrote: if you mean SRAM, stm32mp1 has some @ 0x20000000. In my current setup with ftfp boot, it is used to load SPL+uboot, then, kernel is loaded into default kernel space @ 0xc0000000, where DRAM starts. At the _start kernel's entry sp is something about 0xdd....., so it uses DRMA as well. Where can I find traces of TCM usage? John F Carr wrote: Are you using a chip where some memory can be mapped as TCM or cache? Trying to use the memory both ways could cause problems. On Nov 18, 2023, at 19:46, Stanislav Silnicki wrote: The root cause of zeroed stack in my setup with STM32MP157 seems to be in the TEX remapping registers values, calculated by pmap_set_tex(void). It can be a wrong assumption, as I'm not sure of any hardware (OTP/Security) tunings, that might be in effect.... Blindly copied values for PRRR & NMRR registers from Linux kernel (6.1.28), supplied by STM in their distribution I could avoid the trouble with zeroed stack memory. The hardcoded values are: rg ".equ\s+(PR|NM)RR" arch/arm/mm/* arch/arm/mm/proc-v7-3level.S 110:.equ PRRR, 0xeeaa4400 @ MAIR0 111:.equ NMRR, 0xff000004 @ MAIR1 arch/arm/mm/proc-v7-2level.S 137:.equ PRRR, 0xff0a81a8 138:.equ NMRR, 0x40e040e0 I (wrongly?) assume, 2level is related to the ones, calculated by pmap_set_tex. Narrowing down the inconsistency among values found in Linux kernel and calculated here, I came to the result that the type of inner cache, tuned for first value of tex_classes lut ruins memory: TEX(PRRR_MEM, NMRR_WB_WA, NMRR_WB_WA, 0), /* 0 - ATTR_WB_WA */ - zeroes stack mem on TLB flush TEX(PRRR_MEM, NMRR_WB, NMRR_WB_WA, 0), /* 0 - ATTR_WB_WA */ - zeroes stack mem on TLB flush TEX(PRRR_MEM, NMRR_WT, NMRR_WB_WA, 0), /* 0 - ATTR_WB_WA */ - DOES NOT zeroes stack mem on TLB flush TEX(PRRR_MEM, NMRR_NC, NMRR_WB_WA, 0), /* 0 - ATTR_WB_WA */ - DOES NOT zeroes stack mem on TLB flush Need further investigation.... Any clues? Stan Stanislav Silnicki wrote: STM32MP15x port current progress: ... it took some time to solder down the probe and establish conveniences with remote kernel debug... So far, I need to understand, whither or not I face an expected behavior? It looks like tlb_flush_all_local() (https://github.com/freebsd/freebsd-src/blob/525ecfdad597980ea4cd59238e24c8530dbcd31d/sys/arm/arm/pmap-v6.c#L512C14-L512C14) destroys stack memory, where return address is stored, so when stored lr is poped into pc, it is 0x0.... here is a dump of my debug session around that code: 508 cp15_prrr_set(prrr); (kgdb) i f Stack level 0, frame at 0xc0784598: pc = 0xc0557b44 in pmap_set_tex (/usr/src/sys/arm/arm/pmap-v6.c:508); saved pc = 0xc055254c called by frame at 0xc07847e0 source language c. Arglist at 0xc0784590, args: Locals at 0xc0784590, Previous frame's sp is 0xc0784598 Saved registers: r4 at 0xc0784580, r5 at 0xc0784584, r6 at 0xc0784588, r10 at 0xc078458c, r11 at 0xc0784590, lr at 0xc0784594 (kgdb) x 0xc0784594 0xc0784594: 0xc055254c (kgdb) n stm32mp15x.cpu0 rev 5, partnum c07, arch f, variant 0, implementor 41 stm32mp15x.cpu1 rev 5, partnum c07, arch f, variant 0, implementor 41 target halted in Thumb state due to debug-request, current mode: Supervisor cpsr: 0x600001f3 pc: 0x0000060e MMU: disabled, D-Cache: disabled, I-Cache: enabled 509 cp15_nmrr_set(nmrr); (kgdb) x 0xc0784594 0xc0784594: 0xc055254c (kgdb) n stm32mp15x.cpu0 rev 5, partnum c07, arch f, variant 0, implementor 41 stm32mp15x.cpu1 rev 5, partnum c07, arch f, variant 0, implementor 41 target halted in Thumb state due to debug-request, current mode: Supervisor cpsr: 0x600001f3 pc: 0x0000060e MMU: disabled, D-Cache: disabled, I-Cache: enabled 512 tlb_flush_all_local(); (kgdb) x 0xc0784594 0xc0784594: 0xc055254c (kgdb) si stm32mp15x.cpu0 rev 5, partnum c07, arch f, variant 0, implementor 41 stm32mp15x.cpu1 rev 5, partnum c07, arch f, variant 0, implementor 41 target halted in Thumb state due to debug-request, current mode: Supervisor cpsr: 0x600001f3 pc: 0x0000060e MMU: disabled, D-Cache: disabled, I-Cache: enabled _CP15_TLBIALL () at /usr/src/sys/arm/include/cpu-v6.h:147 147 _WF0(_CP15_TLBIALL, CP15_TLBIALL) /* Invalidate entire unified TLB */ (kgdb) si stm32mp15x.cpu0 rev 5, partnum c07, arch f, variant 0, implementor 41 stm32mp15x.cpu1 rev 5, partnum c07, arch f, variant 0, implementor 41 target halted in Thumb state due to debug-request, current mode: Supervisor cpsr: 0x600001f3 pc: 0x0000060e MMU: disabled, D-Cache: disabled, I-Cache: enabled tlb_flush_all_local () at /usr/src/sys/arm/include/cpu-v6.h:340 340 dsb(); (kgdb) x 0xc0784594 0xc0784594: 0x00000000 (kgdb) si stm32mp15x.cpu0 rev 5, partnum c07, arch f, variant 0, implementor 41 stm32mp15x.cpu1 rev 5, partnum c07, arch f, variant 0, implementor 41 target halted in Thumb state due to debug-request, current mode: Supervisor cpsr: 0x600001f3 pc: 0x0000060e MMU: disabled, D-Cache: disabled, I-Cache: enabled pmap_set_tex () at /usr/src/sys/arm/arm/pmap-v6.c:513 513 } (kgdb) si Polling target stm32mp15x.cm4 failed, trying to reexamine Failed to read memory at 0xe000ed00 Examination failed, GDB will be halted. Polling again in 100ms Program stopped. pmap_set_tex () at /usr/src/sys/arm/arm/pmap-v6.c:513 513 } (kgdb) The address, referenced from error message (0xe000ed00) is mapped by STM's address space to "DDR extension (CA7 only) or Debug" with debug assigned to Cortex-M4 coprocessor. I'm not sure, that it is an unexpected behav. (it is my first attempt to port to armv7), so need an advice. Any? Stan Stanislav Silnicki wrote: my current progress of STM32MP1xx port attempt: Basically, both options to boot ubldr and then kernel in SPL & TF-A modes of u-boot are supported. Initially, when I stated from TF-A options (security supervision from arm's trusted firmware os) I stuck with this line: https://github.com/freebsd/freebsd-src/blob/501bdf3001190686bf55d9d333cb533858c2cf2f/sys/arm/arm/locore-v6.S#L371 control does not seem to reach beyond that point. I tried to enable the led with this assembly, which works anywhere else: /* prepare to use LED @ GPIOA 13*/ ldr r0, =0x50002014 ldr r1, =0xFFFFDFFF ldr r2, [r0] and r2, r1, r2 /* Enable caches. */ mrc CP15_SCTLR(r7) orr r7, #CPU_CONTROL_DC_ENABLE orr r7, #CPU_CONTROL_IC_ENABLE orr r7, #CPU_CONTROL_BPRD_ENABLE mcr CP15_SCTLR(r7) DSB /* turn on GPIO LED */ str r2, [r0] Control passes if I disable data cache ORing instruction, but then hangs on setting of new TTB couple lines below... I thought it was due to security access control from TF-A, but it behaves the same w/o. Any clues or expertise from other platforms are highly appreciated. Stan Stanislav Silnicki wrote: Hello, I need an advice on the intial addresses layout when booting the kernel. As I understand, ubldr is the proper way to boot the kernel. What is the correct address to load it, given that I wand to keep default KERNVIRTADDR (=0xc0000000) intact? The u-boot loads ubldr this way in my current setup: // FreeBSD version of environment env_set("baudrate", "115200"); env_set("console", "ttyS0,115200"); env_set("stderr", "serial"); env_set("stdin", "serial"); env_set("stdout", "serial"); env_set("autostart", "yes"); env_set("loaderdev", "mmc 1"); // fbsd's ubldr treats our second mmc at index 1 env_set("bootcmd", "fatload mmc 2 0xc0000000 ubldr && bootelf"); then ubldr leads the kernel from mmc and passes it the control: Loading kernel... /boot/kernel/kernel text=0x1b4 text=0x5b8530 text=0x17d91c data=0xa4a60 data=0x0+0x20c000 0x4+0x88810+0x4+0xe9d98| Loading configured modules... can't find '/boot/entropy' can't find '/etc/hostid' Using DTB compiled into kernel. Kernel entry at 0xc0400200... Kernel args: (null) Then I could correctly pass the init of MMU and get into translated mode only with setting KERNVIRTADDR = 0xc4000000. It looks like kernel and loader clash somehow. So, just need to understand what is best option to load ubldr to? Will it affect further routines? Stan Stanislav Silnicki wrote: OK, I got the idea! As I realize, there is a minor bug in dtc, which affects compilation of stm's originated DTBs. I think it is best to make a PR into https://github.com/davidchisnall/dtc, which I'm discussing with repo owner already. Please tell me, that I need to post PR into FBSD source tree if it is a shorter way for my fix. My current setup is based upon QBASE1 from Karo-Electronics, but there is no goal to support/debug all peripherals, only a subset, including USB, I2C, SDMMC, DSI (and GPU, if lucky). https://www.karo-electronics.com/fileadmin/download/Datasheets/QSMP-QSBASE1-Evalkit.pdf The vendor (Karo) supports only their Yocto based Linux distro. I spent some time to prepare TF-A & Uboot, capable with booting from SD card (that is more robust approach, as I think). STM does not promote/support non-secure boot approach with SPL, they insist to use TF-A or OPTEE, so it is pretty cumbersome path, I had to pass. I think, it will be easier for me to prepare some sort of README to support customization of uboot for STM's port and dig it somewhere in SRC rather than ; ; ; ; ;try to post PR's in those repos... Not sure, anyway. So far I'm struggling with uart and early_printf... I'm mixing this activity with my current occupation, so I don't expect rapid progress. Thank you for clarifications! I'll try to do my best! Stan Oskar Holmlund wrote: Hi Stanislav, Please resend your message and CC the arm mailing list. It might be interesting for someone in the future ( https://lists.freebsd.org/archives/freebsd-arm/ ) otherwise they all think you stopped working on the STM32 port. You should always keep one terminal up n running % man 9 style :) https://wiki.freebsd.org/Phabricator will give you some information. Its good if you get to know the people active in the ARM area, just keep an eye on the mailinglist and you will notice some names. If you have the opportunity to join any of the conference (eurobsdcon.org, asiabsdcon.org, bsdcan.org) to get to know even more people. Join the IRC, for example on efnet #bsdmips is a good channel for ARM stuff. Start with small changes and you will get feedback. From there the experience will grow and you will get into it all. Correct, the device-tree import is from the Linux kernel and there is no prior work for the STM32MP15 SoCs. I cant find anything about the STM32MP15x in Net or OpenBSD either. Probably because the STM32MP15 is the first(?) application SoC from ST? 1) hum? Do you need that for the reviews? It should be in SRC 2) Target branch is probably main. 3) It depends, if your custom board is opensource and availble around the globe through mouser/farnell/.. I dont see any problem. Otherwise pick the board from ST that you used as a reference when you developed the custom board. For example in my day job we have a custom board built around the octavosystems OSD3358 that can be found in pocketbeagle/beaglebone black wifi. So the code thats goes into the FreeBSD project are all tested on the beaglebone boards. The stuff we need for our custom board like the device tree is keept as local patches in our inhouse build process. //Oskar 2023-10-28 14:25 skrev Stanislav Silnicki: Hi Oskar! > can you point me some guidelines to help myself to fit development process? I'm sure, there is mature dev. culture around FBSD and I'd be happy to make my contribution coherently from the beginning. > So far I'm done with setup of my account at reviews (keys, 2FA, etc.) > As I understand, there is no considerable progress with STM32, although I have noticed, there are some DTS imported into the project. > > Indeed, several major questions: 1. repo url? 2. tagret branch for patches for stm32 hw? 3. is it possible to target custom board from our project, or I have to ensure support for all dev. boards, provided by STM? > Thank you,Stan > Oskar Holmlund wrote: >> 2023-10-27 22:33 skrev Stanislav Silnicki: quote class="gmail_quote" type="cite" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> >>> Hello! I'm porting onto the subject hardware. So far the progress is modest, while the system boots (without console although...) One of major issues is hardcoded value inside locore-v6.S. Here is my relevant post: >> > https://community.st.com/t5/stm32-mpus-embedded-software/freebsd-port-for-mp157c/td-p/601438 [1] What is the best way to proceed? Patch, vendor kernel build, something else? Stan > Links: ------ >> [1] > > https://community.st.com/t5/stm32-mpus-embedded-software/freebsd-port-for-mp157c/td-p/601438 >> Hi Stan, >> Upload your patch to reviews.freebsd.org >> Love to see your other patches for the STM32MP15x. kquote> >> //Oskar < < >
WIP status:

So far implemented:
- u-boot config + DTS with SPL (only secure mode). A port is prepared and compiled, while pending dev. testing.
- uart: EARLY_PRINTF, low-level driver interface (full console). high level methods are pending implementation, though seem trivial.
- SMP: second core is started

Pending:
- sd/mmc (a must)
- rtc (seems trivial)
- net if driver (optional?)

Couple questions to community:
1. Shall I consider any other parts to port to be able to pass phabricator & review?
2. My current board with STM32MP1 (Karo's Qbase4 + QSMP1570 module) does not have sd card connector soldered.
May I consider a description in port's README of how to solder an SD Card to be able to boot from one? There is also an option to describe how to flash onboard 4Gb emmc chip.

A special question about 32bit systems discontinuty: is it mainly a warning for i386 or there is a real plan to abandon armv7?

Stan

Stanislav Silnicki wrote:


Reading TCMTR shows 0x0, so is looks like TCM is not implemented in my case...

Stanislav Silnicki wrote:


if you mean SRAM, stm32mp1 has some @ 0x20000000. In my current setup with  ftfp boot, it is used to load SPL+uboot, then, kernel is loaded into default kernel space @ 0xc0000000, where DRAM starts. At the _start kernel's entry sp is something about 0xdd....., so it uses DRMA as well. Where can I find traces of TCM usage?

John F Carr wrote:


Are you using a chip where some memory can be mapped as TCM or cache?
Trying to use the memory both ways could cause problems.


quote class="gmail_quote" type="cite" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Nov 18, 2023, at 19:46, Stanislav Silnicki <stanislav.silnicki@mailgate.us> wrote:
The root cause of zeroed stack in my setup with STM32MP157 seems to be in the TEX remapping registers values, calculated by  pmap_set_tex(void). It can be a wrong assumption, as I'm not sure of any hardware (OTP/Security) tunings, that might be in effect....
Blindly copied values for PRRR & NMRR registers from Linux kernel (6.1.28), supplied by STM in their distribution I could avoid the trouble with zeroed stack memory. The hardcoded values are:
rg ".equ\s+(PR|NM)RR" arch/arm/mm/*
arch/arm/mm/proc-v7-3level.S
110:.equ PRRR, 0xeeaa4400 @ MAIR0
111:.equ NMRR, 0xff000004 @ MAIR1
arch/arm/mm/proc-v7-2level.S
137:.equ PRRR, 0xff0a81a8
138:.equ NMRR, 0x40e040e0
I (wrongly?) assume, 2level is related to the ones, calculated by pmap_set_tex.
Narrowing down the inconsistency among values found in Linux kernel and calculated here, I came to the result that the type of inner cache, tuned for first value of tex_classes lut ruins memory:
TEX(PRRR_MEM, NMRR_WB_WA,    NMRR_WB_WA, 0),  /* 0 - ATTR_WB_WA */ - zeroes stack mem on TLB flush
TEX(PRRR_MEM, NMRR_WB,    NMRR_WB_WA, 0),  /* 0 - ATTR_WB_WA */ - zeroes stack mem on TLB flush
TEX(PRRR_MEM, NMRR_WT,    NMRR_WB_WA, 0),  /* 0 - ATTR_WB_WA */ - DOES NOT zeroes stack mem on TLB flush
TEX(PRRR_MEM, NMRR_NC,    NMRR_WB_WA, 0),  /* 0 - ATTR_WB_WA */ - DOES NOT zeroes stack mem on TLB flush
Need further investigation....
Any clues?
Stan
Stanislav Silnicki wrote:

STM32MP15x port current progress:
... it took some time to solder down the probe and establish conveniences with remote kernel debug...
So far, I need to understand, whither or not I face an expected behavior?
It looks like tlb_flush_all_local() (https://github.com/freebsd/freebsd-src/blob/525ecfdad597980ea4cd59238e24c8530dbcd31d/sys/arm/arm/pmap-v6.c#L512C14-L512C14)
destroys stack memory, where return address is stored, so when stored lr is poped into pc, it is 0x0....
here is a dump of my debug session around that code:
508 cp15_prrr_set(prrr);
(kgdb) i f
Stack level 0, frame at 0xc0784598:
pc = 0xc0557b44 in pmap_set_tex (/usr/src/sys/arm/arm/pmap-v6.c:508); saved pc = 0xc055254c
called by frame at 0xc07847e0
source language c.
Arglist at 0xc0784590, args:
Locals at 0xc0784590, Previous frame's sp is 0xc0784598
Saved registers:
r4 at 0xc0784580, r5 at 0xc0784584, r6 at 0xc0784588, r10 at 0xc078458c, r11 at 0xc0784590, lr at 0xc0784594
(kgdb) x 0xc0784594
0xc0784594: 0xc055254c
(kgdb) n
stm32mp15x.cpu0 rev 5, partnum c07, arch f, variant 0, implementor 41
stm32mp15x.cpu1 rev 5, partnum c07, arch f, variant 0, implementor 41
target halted in Thumb state due to debug-request, current mode: Supervisor
cpsr: 0x600001f3 pc: 0x0000060e
MMU: disabled, D-Cache: disabled, I-Cache: enabled
509 cp15_nmrr_set(nmrr);
(kgdb) x 0xc0784594
0xc0784594: 0xc055254c
(kgdb) n
stm32mp15x.cpu0 rev 5, partnum c07, arch f, variant 0, implementor 41
stm32mp15x.cpu1 rev 5, partnum c07, arch f, variant 0, implementor 41
target halted in Thumb state due to debug-request, current mode: Supervisor
cpsr: 0x600001f3 pc: 0x0000060e
MMU: disabled, D-Cache: disabled, I-Cache: enabled
512 tlb_flush_all_local();
(kgdb) x 0xc0784594
0xc0784594: 0xc055254c
(kgdb) si
stm32mp15x.cpu0 rev 5, partnum c07, arch f, variant 0, implementor 41
stm32mp15x.cpu1 rev 5, partnum c07, arch f, variant 0, implementor 41
target halted in Thumb state due to debug-request, current mode: Supervisor
cpsr: 0x600001f3 pc: 0x0000060e
MMU: disabled, D-Cache: disabled, I-Cache: enabled
_CP15_TLBIALL () at /usr/src/sys/arm/include/cpu-v6.h:147
147 _WF0(_CP15_TLBIALL, CP15_TLBIALL) /* Invalidate entire unified TLB */
(kgdb) si
stm32mp15x.cpu0 rev 5, partnum c07, arch f, variant 0, implementor 41
stm32mp15x.cpu1 rev 5, partnum c07, arch f, variant 0, implementor 41
target halted in Thumb state due to debug-request, current mode: Supervisor
cpsr: 0x600001f3 pc: 0x0000060e
MMU: disabled, D-Cache: disabled, I-Cache: enabled
tlb_flush_all_local () at /usr/src/sys/arm/include/cpu-v6.h:340
340 dsb();
(kgdb) x 0xc0784594
0xc0784594: 0x00000000
(kgdb) si
stm32mp15x.cpu0 rev 5, partnum c07, arch f, variant 0, implementor 41
stm32mp15x.cpu1 rev 5, partnum c07, arch f, variant 0, implementor 41
target halted in Thumb state due to debug-request, current mode: Supervisor
cpsr: 0x600001f3 pc: 0x0000060e
MMU: disabled, D-Cache: disabled, I-Cache: enabled
pmap_set_tex () at /usr/src/sys/arm/arm/pmap-v6.c:513
513 }
(kgdb) si
Polling target stm32mp15x.cm4 failed, trying to reexamine
Failed to read memory at 0xe000ed00
Examination failed, GDB will be halted. Polling again in 100ms
Program stopped.
pmap_set_tex () at /usr/src/sys/arm/arm/pmap-v6.c:513
513 }
(kgdb)
The address, referenced from error message (0xe000ed00) is mapped by STM's address space to "DDR extension (CA7 only) or Debug" with debug assigned to Cortex-M4 coprocessor.
I'm not sure, that it is an unexpected behav. (it is my first attempt to port to armv7), so need an advice.
Any?
Stan
Stanislav Silnicki wrote:

my current progress of STM32MP1xx port attempt:
Basically, both options to boot ubldr and then kernel in SPL & TF-A modes of u-boot are supported.
Initially, when I stated from TF-A options (security supervision from arm's trusted firmware os) I stuck with
this line: https://github.com/freebsd/freebsd-src/blob/501bdf3001190686bf55d9d333cb533858c2cf2f/sys/arm/arm/locore-v6.S#L371
control does not seem to reach beyond that point. I tried to enable the led with this assembly, which works anywhere else:
  /* prepare to use LED @ GPIOA 13*/
  ldr r0, =0x50002014
  ldr r1, =0xFFFFDFFF
  ldr r2, [r0]
  and r2, r1, r2
/* Enable caches. */
mrc CP15_SCTLR(r7)
orr r7, #CPU_CONTROL_DC_ENABLE
orr r7, #CPU_CONTROL_IC_ENABLE
orr r7, #CPU_CONTROL_BPRD_ENABLE
mcr CP15_SCTLR(r7)
DSB
  /* turn on GPIO LED */
  str r2, [r0]
Control passes if I disable data cache ORing instruction, but then hangs on setting of new TTB couple lines below...
I thought it was due to security access control from TF-A, but it behaves the same w/o.
Any clues or expertise from other platforms are highly appreciated.
Stan
Stanislav Silnicki wrote:

Hello, I need an advice on the intial addresses layout when booting the kernel.
As I understand, ubldr is the proper way to boot the kernel.
What is the correct address to load it, given that I wand to keep default KERNVIRTADDR (=0xc0000000) intact?
The u-boot loads ubldr this way in my current setup:
// FreeBSD version of environment
env_set("baudrate", "115200");
env_set("console", "ttyS0,115200");
env_set("stderr", "serial");
env_set("stdin", "serial");
env_set("stdout", "serial");
env_set("autostart", "yes");
env_set("loaderdev", "mmc 1"); // fbsd's ubldr treats our second mmc at index 1
env_set("bootcmd", "fatload mmc 2 0xc0000000 ubldr && bootelf");
then ubldr leads the kernel from mmc and passes it the control:
Loading kernel...
/boot/kernel/kernel text=0x1b4 text=0x5b8530 text=0x17d91c data=0xa4a60 data=0x0+0x20c000 0x4+0x88810+0x4+0xe9d98|
Loading configured modules...
can't find '/boot/entropy'
can't find '/etc/hostid'
Using DTB compiled into kernel.
Kernel entry at 0xc0400200...
Kernel args: (null)
Then I could correctly pass the init of MMU and get into translated mode only with setting KERNVIRTADDR = 0xc4000000. It looks like kernel and loader clash somehow.
So, just need to understand what is best option to load ubldr to? Will it affect further routines?
Stan
Stanislav Silnicki wrote:

OK, I got the idea!
As I realize, there is a minor bug in dtc, which affects compilation of stm's originated DTBs. I think it is best to make a PR into https://github.com/davidchisnall/dtc, which I'm discussing with repo owner already. Please tell me, that I need to post PR into FBSD source tree if it is a shorter way for my fix.
My current setup is based upon QBASE1 from Karo-Electronics, but there is no goal to support/debug all peripherals, only a subset, including USB, I2C, SDMMC, DSI (and GPU, if lucky).
https://www.karo-electronics.com/fileadmin/download/Datasheets/QSMP-QSBASE1-Evalkit.pdf
The vendor (Karo) supports only their Yocto based Linux distro. I spent some time to prepare TF-A & Uboot, capable with booting from SD card (that is more robust approach, as I think). STM does not promote/support non-secure boot approach with SPL, they insist to use TF-A or OPTEE, so it is pretty cumbersome path, I had to pass. I think, it will be easier for me to prepare some sort of README to support customization of uboot for STM's port and dig it somewhere in SRC rather than  ; ; ; ; ;try to post PR's in those repos... Not sure, anyway.
So far I'm struggling with uart and early_printf...
I'm mixing this activity with my current occupation, so I don't expect rapid progress.
Thank you for clarifications! I'll try to do my best!
Stan
Oskar Holmlund wrote:

Hi Stanislav,
Please resend your message and CC the arm mailing list. It might be interesting for someone in the future ( https://lists.freebsd.org/archives/freebsd-arm/ ) otherwise they all think you stopped working on the STM32 port.
You should always keep one terminal up n running % man 9 style :)
https://wiki.freebsd.org/Phabricator will give you some information.
Its good if you get to know the people active in the ARM area, just keep an eye on the mailinglist and you will notice some names. If you have the opportunity to join any of the conference (eurobsdcon.org, asiabsdcon.org, bsdcan.org) to get to know even more people.
Join the IRC, for example on efnet #bsdmips is a good channel for ARM stuff.
Start with small changes and you will get feedback. From there the experience will grow and you will get into it all.
Correct, the device-tree import is from the Linux kernel and there is no prior work for the STM32MP15 SoCs. I cant find anything about the STM32MP15x in Net or OpenBSD either.
Probably because the STM32MP15 is the first(?) application SoC from ST?
1) hum? Do you need that for the reviews? It should be in SRC
2) Target branch is probably main.
3) It depends, if your custom board is opensource and availble around the globe through mouser/farnell/.. I dont see any problem. Otherwise pick the board from ST that you used as a reference when you developed the custom board.
For example in my day job we have a custom board built around the octavosystems OSD3358 that can be found in pocketbeagle/beaglebone black wifi. So the code thats goes into the FreeBSD project are all tested on the beaglebone boards. The stuff we need for our custom board like the device tree is keept as local patches in our inhouse build process.
//Oskar
2023-10-28 14:25 skrev Stanislav Silnicki:

Hi Oskar!
> can you point me some guidelines to help myself to fit development
process? I'm sure, there is mature dev. culture around FBSD and I'd be
happy to make my contribution coherently from the beginning.
> So far I'm done with setup of my account at reviews (keys, 2FA, etc.)
> As I understand, there is no considerable progress with STM32,
although I have noticed, there are some DTS imported into the project.
> > Indeed, several major questions:
1. repo url?
2. tagret branch for patches for stm32 hw?
3. is it possible to target custom board from our project, or I have
to ensure support for all dev. boards, provided by STM?
> Thank you,Stan
> Oskar Holmlund wrote:
>> 2023-10-27 22:33 skrev Stanislav Silnicki:
quote class="gmail_quote" type="cite" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
>>> Hello!


I'm porting onto the subject hardware. So far the progress is
modest,
while the system boots (without console although...)
One of major issues is hardcoded value inside locore-v6.S. Here
is my
relevant post:
>> > https://community.st.com/t5/stm32-mpus-embedded-software/freebsd-port-for-mp157c/td-p/601438
[1]
What is the best way to proceed? Patch, vendor kernel build,
something
else?
Stan

> Links:

------
>> [1] >
> https://community.st.com/t5/stm32-mpus-embedded-software/freebsd-port-for-mp157c/td-p/601438
>> Hi Stan,
>> Upload your patch to reviews.freebsd.org
>> Love to see your other patches for the STM32MP15x.
kquote>


>> //Oskar







<

<
>

------sinikael-?=_1-17049058292700.7558567376711265-- From nobody Wed Jan 10 18:16:36 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4T9GGK4zWGz55Xmq for ; Wed, 10 Jan 2024 18:16:41 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (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 "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4T9GGK0P3qz4Fs9 for ; Wed, 10 Jan 2024 18:16:40 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Authentication-Results: mx1.freebsd.org; none Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.17.1/8.15.2) with ESMTPS id 40AIGbiu005284 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 10 Jan 2024 10:16:37 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.17.1/8.15.2/Submit) id 40AIGbef005283; Wed, 10 Jan 2024 10:16:37 -0800 (PST) (envelope-from fbsd) Date: Wed, 10 Jan 2024 10:16:36 -0800 From: bob prohaska To: Mark Millard Cc: freebsd-arm@freebsd.org Subject: Re: USB-serial adapter suggestions needed Message-ID: References: <7D27DF9F-AA9A-4D44-BC28-8CC637D0F550@yahoo.com> <3012A549-9482-4D69-9DF4-7987E650DFFA@yahoo.com> List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3012A549-9482-4D69-9DF4-7987E650DFFA@yahoo.com> X-Rspamd-Queue-Id: 4T9GGK0P3qz4Fs9 X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US] On Tue, Jan 09, 2024 at 05:03:42PM -0800, Mark Millard wrote: > On Jan 9, 2024, at 14:47, bob prohaska wrote: > [transcript of ssh-tip disconnect omitted] > > Interesting. > > www.zefox.org is the aarch64 that is not configured in config.txt > in the normal aarch64 manor. As I've requested before, please test > using a config.txt that instead has: > > QUOTE > [all] > arm_64bit=1 > dtparam=audio=on,i2c_arm=on,spi=on > dtoverlay=mmc > dtoverlay=disable-bt > device_tree_address=0x4000 > kernel=u-boot.bin > > [pi4] > hdmi_safe=1 > armstub=armstub8-gic.bin > > # Local addition: > [all] > force_mac_address=b8:27:eb:71:46:4f > END QUOTE > > Please do not use a configuration based in part on armv7 FreeBSD > config.txt material any more for the testing activity: Just use > the FreeBSD normal aarch64 configuration with the force_mac_address > related material added at the end. > > I want to know if this also fails when powerd is not in > use anywhere. > I'd like to let the the present OS build/install cycle complete. Then I'll replace config.txt on www.zefox.org and reboot. That should be done in another day or two. The remote console disconnect reported above hasn't happened again, all consoles have stayed connected and responsive. > [I assume that the "The Pi4 workstation" is the "pi4 RasPiOS > workstation". True? Presuming yes: Is the RasPiOS the 64 bit > variation? (Just my curiosity.)] > Yes. Uname -a reports Linux raspberrypi 6.1.21-v8+ #1642 SMP PREEMPT Mon Apr 3 17:24:16 BST 2023 aarch64 GNU/Linux > Do you run the buildworld on www.zefox.org and such via the > tip session on pelorus.zefox.org ? Via an ssh session from the > "pi4 RasPiOS workstation" to www.zefox.org ? More generally: > > A) What runs (if anything) via the tip session started from > pelorus.zefox.org ? > > B) What runs (if anything) via the ssh session connected to > www.zefox.org ? > In general the tip session is used only for observation or troubleshooting. Ssh connections are used for other activity, including OS build/install cycles, poudriere, etc. They are usually placed in the background, writing to log files so that accidental disconnects from the workstation don't stop them. > A useful test would be to not have the tip command running > on polaris.zefox.org and to just use the ssh to www.zfox.org > instead to start the buildworld/buildkernel. So: No use > of the serial connection when the buildworld is started or > during the build(s). Using tip before that but quitting tip > before starting to load the RPi4B would be okay for this type > of test. The question would be if the: > > client_loop: send disconnect: Broken pipe > > still happens. > > (I'm not claiming that recovery if it fails would be nice. But > finding out if it fails looks to be important.) > > The contrasting useful test would be to start the buildworld > from the tip session on polaris.zefox.org and to not have any > ssh session to www.zefox.org . The question would be if a > failure of some kind still happens. (The tip session does not > have a pipe in use as far as I know so the detail for > identifying faulure would likely be different.) > Normal practice is to leave the tip sessions displaying the console host's login prompt. So long as the console login is responsive I can assume that host isn't hung. > Another question would be: do both such tests fail? Just one > (which)? None? So trying both tests eventually would be > important. In general, ssh sessions behave completely independently. Ssh connections to tip sessions commonly fail but no other ssh connection to that terminal server is disturbed visibly. > > It is important to have only one of the 2 types of connections > in use during the buildworld/buildkernel and such activity for > this type of test --and only the one instance of which ever > type the active test is for. > > Apologies if I didn't answer your question; I'm missing the gist. It remains unclear where the disconnects to tip originate. If the tip session is stopped by typing ~~. from the originating ssh instance I'm returned to the shell on the terminal server. Ssh isn't disturbed. If I type ~. the ssh session terminates and I'm back to the workstation's shell. Would it be informative to start a tip session, then ssh in separately and try to kill tip? I'd expect the ssh part of the link to remain up. If not, would it be significant? Occastionally warnings like Jan 10 00:23:30 ns1 sshd[925]: error: beginning MaxStartups throttling show up in console messages. Might those be relevant in some way? Thanks for writing! bob prohaska From nobody Wed Jan 10 19:21:39 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4T9Hjf1jYTz55h4t for ; Wed, 10 Jan 2024 19:21:58 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic308-55.consmr.mail.gq1.yahoo.com (sonic308-55.consmr.mail.gq1.yahoo.com [98.137.68.31]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4T9Hjd53Q5z4VGW for ; Wed, 10 Jan 2024 19:21:57 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1704914514; bh=q+6vrdiX9o/19nwr2fh3N34PmiqHGOx39rv0hkcebX4=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=G3FLH3OSyUgTBdjVvIagBQfP7+q8M299AMovIPQW0xF2yevixl4tlBWUtaVq8gLvk1qAOVWk8zypqDeT18gagXtm7goh2v4EXV9+Wnr3JF3hgFqCCKUOuInG1a1DDM216/qOF6jPpNsPUTZo5tDbPA6u8acIYtKrWeZfZrmJsZ6JjNiChmgom20NX/X4TnSU6T4ZKhKXBsZJggN8Ss9asSf4MD/DB6vZHySsmQlALkhkW5P+RCV4Qn2m+hLJ0jBexVDBwq1NWAAJXsHgIiOei6AtxFO/1ttIw9KqdVLXRrnNQ6TEAK459LQvEX0RZUeQGB7zgCjGMOct7jsQloaHFw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1704914514; bh=ARdflYsO00Xka56WRctzLn3+n9W9JbpLj9xfsdU/QUL=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=KtLAjdIyXaQvf3/huHXUR8ohqQ04JDDUr9jYS5e1nYTLD1j5vuPz7FJHkY9BdWHwfbum9awMEzehrU+IYKs5jpJhCXu3YfxpcgtCRprLd/pAEFBXi2ovpQzqCYrhtcEdy9VLEopTp/bcPK9W9cEu2+fpYMuCh7gjfLBZW7OeHNrxjl9GJQYgO2PHSdcwZdkeEqbOi+FMuxBteDSNs4d+YaLvCK2DkJLPerFUKvDDBiKuHionJ/WRvbIBBoOB5D2t8VJwJEkCCLsAIKuKsXQ9far12b2y7ZntBAOYhStZN1h0Nc+Zil2JNasP+FiaIQp2uS9R4NzqOAot5icDdd6nvw== X-YMail-OSG: 22MzCwQVM1mpCUnouNa1vt4boVH9ijhkw6y79F.uV0skT8o6m5hnKJaim04ksA3 oGhufYPQHmZKipf5nbPUIgJC4P_a9VyrlWEPUI1IXFfftrHiby5xAkMfQDTtnWKRzZ4tBjXOgH.I JEjFCo0DzK9kVNUyv7ERwAw6fhKgpNAp0oH0M4Nb9JPn2MV22NnDAoUQFJ6IlOj9Q2xanuiB4gTZ 5350xA_Mz.ZXHNsTJIkZ5L_5XvZAkzCj2qpD_mfJtJF6PV5PA5bOnF1qLOFwQmUyDVOCSOpLBJWo lNX2AzH28ZLLOhCs1tfb3zlTLZir6oaIP0Cpxqlw4sZxNy3OajIqk64uklMu8Nx_kvvmeiOiiSgv VC7cdmq9hauUn.Kk5jvwyIATbKD4WuYSpNDaKKO2pwDtgM1UKykzkThjqzDGbZxSbuCIBR26DxCO ySmvZa9NMbHNXzRE5sOPFmnn8ZsAx0zcT81AghF1uGRlNGJqEVpjpS2zHFt9f11rbzS374LRZUpo P1vaZKDZSTQoJR3SXp9pMMEZ0M6weLYr.tAQSGd5mL3AHhjnGesoHOo4TuZIQ4YOG11UkRWwrkeQ rFAkKmWrL6h_pfhcbMs3f35ueoLPm_amGqHMp4uaHXZJdhkHcph7huvwpCZ8XWkyZbP50l13TWlu 5dwpn2SlkFM3ZG6eYERbUn16QOfII4OJj8wF3SOhJ9PlQyhKCkM7P4KwUG502079PSB332uTONeS E6iZJNpFMFKvU07ALhg1ZDVi7XO6DUJQj2WDgM_D.ZfOqyxX8Wvmva82FLJMKfvXYOVOvFvPjNuM ExekdTwgzEFHLrm3IsTUumu4y819_PjW_09kOxQuonYJQwL.A5xIq4jjlsOMbNRjxDJv2yhMAPk3 cgARYtK3uHfH3Dk._9tLwi44eOPJUEbPj6xcFggyY16G_u._GKOcHPAlITCz.BKE3ZPqAwsBH4lG pnyRaQhCC8U_38Hc7QJR_zzDlAb48drsGpT.JOxtfCXqOr8UkE0bvsp_NBv23uPyhD7XBmzeMTkN k7FFzo5.a7H7EFuQuvf4cCqCwnIZzuHCVxDRoka2WMZjp.szCjOEJo6Sb8zhppq0vRtcBcHDzaEM 3Ty5SA5MnX46_MvcL4Ea1ko9DSXaYO7Ls46eXroMbV3R0He2VqceE9oOs8X5_4Yil29T6Ly4p.ox KLzBQQ6v.gnw4qeg_NJpKA05vjrtds_Lss7A6kWon548gnUIP.kWKSTbHgYriWi2Hy94HMR782V9 0mkiogOth0XbH6JSjvXOah8x70AuYNRF1W38RMhXrHWjSen83DsMC84iHDca5NGmJQ9zTm8GYUcn HEjZ.fzzNhIXUccWBR34UlCslKmkepYhcL_qUrVPnXTrXxTky8vTHGTG9caf6d5_oLOAFBT6BKwh FigrKKLndn7eR2j8kkkIyNg7MCv5lI7ZkTVpFmfAx4MXHvLZh48Wu.DEJGyGJkvAQSH4PxQDoq4U N0i2VTUCM_.h4WeiS_5a8T5Dc4u_jyJ_HdrL4eBRUSBKWhevIeNvkWwauLiIqHB0ta6hvd51DWSF 2MrUv7LrPNPl223czXpzRVUPGYFgNVfj9Gr3UrUF4JWqSls1j1G42PjDpPXXJmS5abfm3sxx9p92 qaYEW1QdGmfnWIn35.K9d6RcsYhAKfPKsjvpAWlvXSWfaGEH6lKD2XP0p7OgrfVTCPtnjy608j5X fwezMkVTxtclcvPofaEufwAb.ucosmeAu1jSsUzE4ij7xE4L5T4MCefThK0l7yIKNSlvgPyo9eop yAKoDOJKfTmCRABOxgH0zm9IbprbIOsNE.BxOBHhlcmqia26kHpjdIzJJUz2z0OlIBLoFMayOPwp AGsDk4D.1JS7vRZf7AClW7eoYyw3Fc2ui8AMAKZwleaoPmvdxYBSCt6rwj9MW1k2ixpeSp4eVHTJ Lyb8ONA6WFShMuj.OY_gw9DakfvqQk5bJQiZVu9UjxRlsxVQXdbb4X4WAas81THXftpLbXH803LS RrrHMIvN1c3vDdmJB9sV8cfpJJx.meZ8wO4p0TEH4ygVF5dNFIDf9PWKi8OEZbE1I4VNF7_glrcd gNr544YC4zM1jU6A1L_Fr4cJjxgx.f1RRlnxKOUr0Vcd1Vr1wCIrG0xYUcQvNKMz5ZP3MISztwiN HRR8QkZUsxozQSPzHtimxN.UYc_sU8fwFbO3gfYf3JhcOtnBLnwFiFvzEqiHRm1cYbM.oKe20uws 9BrluhKmIrCBOzK2S0_IPhZsyP22Yi6vySmEsP5urEFV1hNc0MRfxA2yumh8lnfhvhsxQe03E X-Sonic-MF: X-Sonic-ID: b7e5793f-8050-43d1-89a8-f7a9aebff942 Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.gq1.yahoo.com with HTTP; Wed, 10 Jan 2024 19:21:54 +0000 Received: by hermes--production-gq1-78d49cd6df-szbbq (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID f3c76bab60cda1d9049cb4d123eff51c; Wed, 10 Jan 2024 19:21:50 +0000 (UTC) Content-Type: text/plain; charset=utf-8 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.300.61.1.2\)) Subject: Re: USB-serial adapter suggestions needed From: Mark Millard In-Reply-To: Date: Wed, 10 Jan 2024 11:21:39 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <7D27DF9F-AA9A-4D44-BC28-8CC637D0F550@yahoo.com> <3012A549-9482-4D69-9DF4-7987E650DFFA@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3774.300.61.1.2) X-Rspamd-Queue-Id: 4T9Hjd53Q5z4VGW X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] On Jan 10, 2024, at 10:16, bob prohaska wrote: > On Tue, Jan 09, 2024 at 05:03:42PM -0800, Mark Millard wrote: >> On Jan 9, 2024, at 14:47, bob prohaska wrote: >>=20 > [transcript of ssh-tip disconnect omitted] >>=20 >> Interesting. >>=20 >> www.zefox.org is the aarch64 that is not configured in config.txt >> in the normal aarch64 manor. As I've requested before, please test >> using a config.txt that instead has: >>=20 >> QUOTE >> [all] >> arm_64bit=3D1 >> dtparam=3Daudio=3Don,i2c_arm=3Don,spi=3Don >> dtoverlay=3Dmmc >> dtoverlay=3Ddisable-bt >> device_tree_address=3D0x4000 >> kernel=3Du-boot.bin >>=20 >> [pi4] >> hdmi_safe=3D1 >> armstub=3Darmstub8-gic.bin >>=20 >> # Local addition: >> [all] >> force_mac_address=3Db8:27:eb:71:46:4f >> END QUOTE >>=20 >> Please do not use a configuration based in part on armv7 FreeBSD >> config.txt material any more for the testing activity: Just use >> the FreeBSD normal aarch64 configuration with the force_mac_address >> related material added at the end. >>=20 >> I want to know if this also fails when powerd is not in >> use anywhere. >>=20 >=20 > I'd like to let the the present OS build/install cycle complete. > Then I'll replace config.txt on www.zefox.org and reboot. > That should be done in another day or two. The remote console > disconnect reported above hasn't happened again, all consoles > have stayed connected and responsive. >=20 >=20 >> [I assume that the "The Pi4 workstation" is the "pi4 RasPiOS >> workstation". True? Presuming yes: Is the RasPiOS the 64 bit >> variation? (Just my curiosity.)] >>=20 > Yes. Uname -a reports=20 > Linux raspberrypi 6.1.21-v8+ #1642 SMP PREEMPT Mon Apr 3 17:24:16=20 > BST 2023 aarch64 GNU/Linux >=20 >> Do you run the buildworld on www.zefox.org and such via the >> tip session on pelorus.zefox.org ? Via an ssh session from the >> "pi4 RasPiOS workstation" to www.zefox.org ? More generally: >>=20 >> A) What runs (if anything) via the tip session started from >> pelorus.zefox.org ? >>=20 >> B) What runs (if anything) via the ssh session connected to >> www.zefox.org ? >>=20 >=20 > In general the tip session is used only for observation or > troubleshooting. Ssh connections are used for other activity,=20 > including OS build/install cycles, poudriere, etc. They are > usually placed in the background, writing to log files so that > accidental disconnects from the workstation don't stop them. Are you using: NAME nohup =E2=80=93 invoke a utility immune to hangups SYNOPSIS nohup [--] utility [arguments] DESCRIPTION The nohup utility invokes utility with its arguments and at this = time sets the signal SIGHUP to be ignored. If the standard output is a terminal, the standard output is appended to the file nohup.out in = the current directory. If standard error is a terminal, it is directed = to the same place as the standard output. Some shells may provide a builtin nohup command which is similar or identical to this utility. Consult the builtin(1) manual page. ? >> A useful test would be to not have the tip command running >> on polaris.zefox.org and to just use the ssh to www.zfox.org >> instead to start the buildworld/buildkernel. So: No use >> of the serial connection when the buildworld is started or >> during the build(s). Using tip before that but quitting tip >> before starting to load the RPi4B would be okay for this type >> of test. The question would be if the: >>=20 >> client_loop: send disconnect: Broken pipe >>=20 >> still happens. >>=20 >> (I'm not claiming that recovery if it fails would be nice. But >> finding out if it fails looks to be important.) >>=20 >> The contrasting useful test would be to start the buildworld >> from the tip session on polaris.zefox.org and to not have any >> ssh session to www.zefox.org . The question would be if a >> failure of some kind still happens. (The tip session does not >> have a pipe in use as far as I know so the detail for >> identifying faulure would likely be different.) >>=20 >=20 > Normal practice is to leave the tip sessions displaying the=20 > console host's login prompt. So long as the console login is=20 > responsive I can assume that host isn't hung. >=20 >> Another question would be: do both such tests fail? Just one >> (which)? None? So trying both tests eventually would be >> important. >=20 > In general, ssh sessions behave completely independently.=20 > Ssh connections to tip sessions commonly fail but no other=20 > ssh connection to that terminal server is disturbed visibly. >>=20 >> It is important to have only one of the 2 types of connections >> in use during the buildworld/buildkernel and such activity for >> this type of test --and only the one instance of which ever >> type the active test is for. >>=20 >>=20 >=20 > Apologies if I didn't answer your question; I'm missing the gist. I only want one source of hangups/failure, no worries about which one (network vs. serial) lead to the activity if a failure happens. That only ssh sessions that in turn run tip fail suggests that the tip session gets the initial problem and then things propagate. I want more than a suggestion. For example: direct tip runs that are not in any ssh session: still get some form of failures? For another: no tip use, just ssh: still get failures? Do both ways still get failures? Yes, the implication is that some experiments that do not have your normal structure are involved and there may be risk of not being able to use a tip session as a responsiveness test during such an experiment. I'm not suggesting any such thing for normal operation once such experiments are finished. > It remains unclear where the disconnects to tip originate. That is part of what I'm requesting exploration of via different techniques than past attempts that did not provide the information. > If the tip > session is stopped by typing ~~. from the originating ssh instance I'm=20= > returned to the shell on the terminal server. Ssh isn't disturbed. If=20= > I type ~. the ssh session terminates and I'm back to the workstation's=20= > shell. Would it be informative to start a tip session, then ssh in=20 > separately and try to kill tip? A question is of SIGHUP is happening. If it is, then the kill that would simulate the issue would be via sending SIGHUP. But this may be only one of however many alternatives there may be. I prefer to explore what is actually happening than attempted simulations via guesses at what is happening. > I'd expect the ssh part of the link > to remain up. If not, would it be significant?=20 >=20 > Occastionally warnings like > Jan 10 00:23:30 ns1 sshd[925]: error: beginning MaxStartups throttling > show up in console messages. Might those be relevant in some way? =20 Hmm. Intersting. Looking around I see notation like: MaxStartups 10:30:100 where (mostly copy/pasted wording from an example, other than detailed = formatting): 10: concurrent unauthenticated sessions before it begins rejecting some = subsequent connections 30: The percent of subsequent connections that are rejected [but see = below] 100: At this many concurrent unauthenticated sessions, sshd rejects all = subsequent connections Looking, "man sshd_config" reports: MaxStartups Specifies the maximum number of concurrent unauthenticated connections to the SSH daemon. Additional connections will = be dropped until authentication succeeds or the LoginGraceTime expires for a connection. The default is 10:30:100. Alternatively, random early drop can be enabled by = specifying the three colon separated values start:rate:full (e.g. = "10:30:60"). sshd(8) will refuse connection attempts with a probability = of rate/100 (30%) if there are currently start (10) = unauthenticated connections. The probability increases linearly and all connection attempts are refused if the number of = unauthenticated connections reaches full (60). It does suggest that testing isolated from the source(s) of unauthenticated sessions could be worth while in case handling the load from such sessions when already heavily loaded with buildworld/builkernel or the like leads to other problems (and denial of service consequences?). I do not expect that this issue is all that likely but expectations are not evidence of their own accuracy/inaccuracy. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Wed Jan 10 19:30:28 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4T9Hvm3B10z55j1t for ; Wed, 10 Jan 2024 19:30:44 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic304-25.consmr.mail.gq1.yahoo.com (sonic304-25.consmr.mail.gq1.yahoo.com [98.137.68.206]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4T9Hvk5tNWz4W5b for ; Wed, 10 Jan 2024 19:30:42 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=na0dLWSN; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.206 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1704915041; bh=GT77XT+mkupWaLyhr1bw/0CJHwT/LuzZC+HdU6I0zH8=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=na0dLWSNBgTIY4dgmpyrHGIYTvXfU5j17TVY9/utBJGIItau2RUsfj7v7KkgC2APHiFquFRzlbIHR+YD5RAAA0OlQB6kX9TLxrxliAozwNUJiTOCgiBNo+cUPIypPdu6+gewfRqjxJEjK654kEenP1I2qMas6bzIxHG7Nn7P+LyZfKP9ImdQAIZJb1R184zV7EJqcxb5Xn6zsBhB25Zr3/Md2Y3x0soRctFJhYDao5c+6zLRcMuMB+P5FQEsyfIeVD8u7nIkJVM8sJ6BDNOoRf3p+L6zYDIp1E/GrGxQ5G3E7VpzK2Tu3inQPK4nMRTlJtjSr6Iw4w+r3dXEnahfAg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1704915041; bh=8Zch1r3ojW3ydySiS4QholkbnxhHz+5Cp9pZN6kxr+e=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=JAzIoO2lfjo3q9ibDgk76KWNTycO5mrow+GzVZwfxBUmtrqdaxqQK4qQioBkEo03b1TiWAlWaSEDBvGO3MxL4hk5yY8IEvGDUUVEAHjD6o6XNtN7qi0OhKTLZTisGawQc4Zb2vO3FLkvbfHYB3FLSD6OQDROBbk58pdVgAM5qtvvjtLM21Iv/tbaFShGsDvUh80Ipqb6jaerWvpFk7tQdcIRW6OjepUJ15iet/V/0uD4lUsINZAWF9Q/3wJNyM1gQGbijh0ZljrQyCqxn0/Cd2UsEq0nlS976IDU6PCjI5WGVDgLNjcbMgf5Y6bfhw3gIW8ITVG3Sc2GeMRXCLpINA== X-YMail-OSG: PmzVidEVM1nPf0ZqEAxRm.h_Wc8lTEv_7nhI6AKl3xKJo9UdSlB5FzudyyCJgKP 4rmkT7MmjaSSaJ4sfYk91F5Nv2wcKOV6PpJeHcOAHFQVOSJ8kXw4IAkD48F1kq3utnzLlOsF10zS FgZHuAGPk.YBzcAwNIrBqzOX6A222OJIFfP.9oFwllICgezBAdaT7fpHllssmpDX3Gp77AnA7HxL G_CGeU.aTA6L.X19vrsiQEwvAtu3NxVCRbiuLj5kECnnE4IKVWcm7GqtOvfnOsGqh6iYzBH46CC6 xuKpLbydd0WakjU9ikTAHByXPw5IIOIKMRq7OPR0k88Y9uqiaJlRxQ8uEcmvtnV7pmqNoEwaTPaz UGMhYzEYruks0NoMCm_1kd7m6IFIp8uex4rf807JrqSXKc32YbIDRBpVyipk6DtoLeASzWxZhPKG 0V7MN_hgTLfMMPQTOQmLaXH8dTyFN_jwDexax5FBZjC71gVJK84vg4JSJKo.F2bwFwWs0O_.cWUG meMo.7S_kuvfFjIUk3OmQFY8osoGVDrxuMsC9Q4jwgx68Op882pRLU6iVNm33i5QPSoKCM5csR3q LaoGLFFU028r4G5d8E3YdxXuK.hbLAA7k8ly38Ga95fB56857cr.JJw4eNsfh1kR6prKOpMv61ni _p0SpXEPLlPUxHSuX7OkcLnS7qMUamD3b5YFQlNttZCmv.UzSaOmmPx1u7E3UO3EoxuSqWVCsHUs uqCxEX.kNSXyNnDQCSfu6xk5Hbn0Hofb3miTnIHJM9xBBQHR8PIQlTz0W0GA4h6qBTFnVFgbGx_E x._qtFNiXd9LZj_5mYkCaBit6JgyWMSUYsiRZCIRGeNREy_AgZI9ESTETkMBuit.ZoNPMOdZZPyb 2gaonFnZlQAiO8S1.5bEHh1pZoLw_uoeBexl9hMeVfLl.8UV4gWMwsDN2QzT15Cipp5LBjn534.Y G33OR8tTUmR3BX05eu9x7oF_s08WmqzmZu_3.j7RsfZs3I4U2mogy3KBu7rbGU5F8DMtTHOydRRT eCpRKShc0IvhBH4h3b9sZn08nYwa_RbCH8pChW45QxdYQqjlXFzOhg.IEpxJwdObg06xohzoza8X 50N2zAC5qeo7TRmKhYh8dJyCHCmSBls.EATup6tUW7e2ZllsTpZmN0RUAabR.gEJYPm49rKqeYDz aG_WZaFbIyxfw_FxuzY1PkcPK6v5tI.W0keRxeOuQ9CuNXwO2uTERZAm2Rbr7tAnBwn0Z7zMxexh gWvw1EE7nf6Hie.pDugtLB8obVe4.X8E265TTb4Wn_ZB5SiOCJbbv1NJZCBVjnW7zFEZ.oeymNw7 MmkE2HswiH.aQZzbmf_Rw_v.2hsbB4sqwuxa6rU1EvWNBvXm8YB95Nq.K7eJ6jfjwikJHGGnb0zT zKX9pEpiRQeCKmYCwMYtW7EhifoO0F2ZsQ.T6f9gwk1PI5spiskZFzgsXLYcReiAuZHZtshwkUyx frYZl9rt_MCq7eo31GFSgCaRRg9pVnp4qlxnwQpCcFksQl5CoEzTt.Jde_OXGEJIwddEmhfzopdN riFDTMryLGSPqjrO4mhack0B8K0nDNImsNvU54gkSEwUm5P4ElChbLYvX9SgkXSx11Da1LqtLjBY Jukvnt818QfGVYXjoQuR4VHYn5m53OIV787gjMW6Png0LaKxMZ1V.PW38wA0zPbdGyPM9Djrfpv8 dyMGbUcbjEbDvB0nlWhgfZ9d.wPBfbCQt5.umLmRviL3fPVZZ9wJrYqZrUP0d7K2AOiDAnWGv9ch q3Wa4U_tKAsyTC9CY55VnT1WxpFAiPLL.JnhFI0k2uO6kL_ZCuT39Lf_CxsCzigixJc5kBKIcV8y TcuYqr2CzXp7Uxy1aPa8_5FaL2T5U_HSWafKBZgHT7c.UTUd3GZOV_mW_WRqumtBjYLTN6szMtFO tSw8.VJaSSf.G06TcVfmKcu3W5Jw1qExDQkys5pa_ggGN44R9Ffok1s.br_JyFQtAQPcTAdek7iQ sBfGRf_UEc_nNXSwLa1lNfr9TZ7sOJ8ZV3CM44hREJOR3npWQbCUYpBWcCQrTMkqU35_ICptGYK5 FCW.18Xrwlk3VjgkCsA1kU3_9CDhgXhTumN0CNdJVQ_FcAmfJ60KzoBLO6XxLUBdbYovjADlTegp sEMF5FmDzXCbgbIpwGWjoeD0od9GEIL5_zWRwogKkVw_mEOhQwKH2ckaxodixOnD5Nw_S.dB0leI 7BpHATukIi5gXPbHcytXTPDHotatT9dsEIVeqJGL3UKPUxCFJ4dmfamEV5yKzoOAo_hO4LzkC0g- - X-Sonic-MF: X-Sonic-ID: 466b9ecb-e3d5-4b50-9e64-9eb63904bf1f Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Wed, 10 Jan 2024 19:30:41 +0000 Received: by hermes--production-gq1-78d49cd6df-hlpbq (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 4540a0106e9a961ba0bb06249ff512a3; Wed, 10 Jan 2024 19:30:39 +0000 (UTC) Content-Type: text/plain; charset=utf-8 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.300.61.1.2\)) Subject: Re: USB-serial adapter suggestions needed From: Mark Millard In-Reply-To: Date: Wed, 10 Jan 2024 11:30:28 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <55AC6824-587D-4C67-B64B-2045A1112F69@yahoo.com> References: <7D27DF9F-AA9A-4D44-BC28-8CC637D0F550@yahoo.com> <3012A549-9482-4D69-9DF4-7987E650DFFA@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3774.300.61.1.2) X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.50 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_TWO(0.00)[2]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; TO_DN_SOME(0.00)[]; ARC_NA(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; FREEMAIL_FROM(0.00)[yahoo.com]; FROM_HAS_DN(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.206:from]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.206:from] X-Rspamd-Queue-Id: 4T9Hvk5tNWz4W5b On Jan 10, 2024, at 11:21, Mark Millard wrote: > On Jan 10, 2024, at 10:16, bob prohaska wrote: >=20 >> On Tue, Jan 09, 2024 at 05:03:42PM -0800, Mark Millard wrote: >>> On Jan 9, 2024, at 14:47, bob prohaska wrote: >>>=20 >> [transcript of ssh-tip disconnect omitted] >>>=20 >>> Interesting. >>>=20 >>> www.zefox.org is the aarch64 that is not configured in config.txt >>> in the normal aarch64 manor. As I've requested before, please test >>> using a config.txt that instead has: >>>=20 >>> QUOTE >>> [all] >>> arm_64bit=3D1 >>> dtparam=3Daudio=3Don,i2c_arm=3Don,spi=3Don >>> dtoverlay=3Dmmc >>> dtoverlay=3Ddisable-bt >>> device_tree_address=3D0x4000 >>> kernel=3Du-boot.bin >>>=20 >>> [pi4] >>> hdmi_safe=3D1 >>> armstub=3Darmstub8-gic.bin >>>=20 >>> # Local addition: >>> [all] >>> force_mac_address=3Db8:27:eb:71:46:4f >>> END QUOTE >>>=20 >>> Please do not use a configuration based in part on armv7 FreeBSD >>> config.txt material any more for the testing activity: Just use >>> the FreeBSD normal aarch64 configuration with the force_mac_address >>> related material added at the end. >>>=20 >>> I want to know if this also fails when powerd is not in >>> use anywhere. >>>=20 >>=20 >> I'd like to let the the present OS build/install cycle complete. >> Then I'll replace config.txt on www.zefox.org and reboot. >> That should be done in another day or two. The remote console >> disconnect reported above hasn't happened again, all consoles >> have stayed connected and responsive. >>=20 >>=20 >>> [I assume that the "The Pi4 workstation" is the "pi4 RasPiOS >>> workstation". True? Presuming yes: Is the RasPiOS the 64 bit >>> variation? (Just my curiosity.)] >>>=20 >> Yes. Uname -a reports=20 >> Linux raspberrypi 6.1.21-v8+ #1642 SMP PREEMPT Mon Apr 3 17:24:16=20 >> BST 2023 aarch64 GNU/Linux >>=20 >>> Do you run the buildworld on www.zefox.org and such via the >>> tip session on pelorus.zefox.org ? Via an ssh session from the >>> "pi4 RasPiOS workstation" to www.zefox.org ? More generally: >>>=20 >>> A) What runs (if anything) via the tip session started from >>> pelorus.zefox.org ? >>>=20 >>> B) What runs (if anything) via the ssh session connected to >>> www.zefox.org ? >>>=20 >>=20 >> In general the tip session is used only for observation or >> troubleshooting. Ssh connections are used for other activity,=20 >> including OS build/install cycles, poudriere, etc. They are >> usually placed in the background, writing to log files so that >> accidental disconnects from the workstation don't stop them. >=20 > Are you using: >=20 > NAME > nohup =E2=80=93 invoke a utility immune to hangups >=20 > SYNOPSIS > nohup [--] utility [arguments] >=20 > DESCRIPTION > The nohup utility invokes utility with its arguments and at this = time > sets the signal SIGHUP to be ignored. If the standard output is a > terminal, the standard output is appended to the file nohup.out in = the > current directory. If standard error is a terminal, it is = directed to > the same place as the standard output. >=20 > Some shells may provide a builtin nohup command which is similar = or > identical to this utility. Consult the builtin(1) manual page. >=20 > ? >=20 >>> A useful test would be to not have the tip command running >>> on polaris.zefox.org and to just use the ssh to www.zfox.org >>> instead to start the buildworld/buildkernel. So: No use >>> of the serial connection when the buildworld is started or >>> during the build(s). Using tip before that but quitting tip >>> before starting to load the RPi4B would be okay for this type >>> of test. The question would be if the: >>>=20 >>> client_loop: send disconnect: Broken pipe >>>=20 >>> still happens. >>>=20 >>> (I'm not claiming that recovery if it fails would be nice. But >>> finding out if it fails looks to be important.) >>>=20 >>> The contrasting useful test would be to start the buildworld >>> from the tip session on polaris.zefox.org and to not have any >>> ssh session to www.zefox.org . The question would be if a >>> failure of some kind still happens. (The tip session does not >>> have a pipe in use as far as I know so the detail for >>> identifying faulure would likely be different.) >>>=20 >>=20 >> Normal practice is to leave the tip sessions displaying the=20 >> console host's login prompt. So long as the console login is=20 >> responsive I can assume that host isn't hung. >>=20 >>> Another question would be: do both such tests fail? Just one >>> (which)? None? So trying both tests eventually would be >>> important. >>=20 >> In general, ssh sessions behave completely independently.=20 >> Ssh connections to tip sessions commonly fail but no other=20 >> ssh connection to that terminal server is disturbed visibly. Silly me: The above is already the "ssh without tip" case and so is already covered. That just leaves the "tip not inside an ssh session" case to expirment with. >>> It is important to have only one of the 2 types of connections >>> in use during the buildworld/buildkernel and such activity for >>> this type of test --and only the one instance of which ever >>> type the active test is for. >>>=20 >>>=20 >>=20 >> Apologies if I didn't answer your question; I'm missing the gist. >=20 > I only want one source of hangups/failure, no worries about which > one (network vs. serial) lead to the activity if a failure happens. >=20 > That only ssh sessions that in turn run tip fail suggests that the > tip session gets the initial problem and then things propagate. I > want more than a suggestion. For example: direct tip runs that > are not in any ssh session: still get some form of failures? Only the above needs a new experiment. > For > another: no tip use, just ssh: still get failures? The just above is already covered. > Do both ways > still get failures? Already known: no. > Yes, the implication is that some experiments that do not have > your normal structure are involved and there may be risk of not > being able to use a tip session as a responsiveness test during > such an experiment. I'm not suggesting any such thing for normal > operation once such experiments are finished. =20 Actually the no-tip case is already covered so the responsiveness testing is not an issue. >> It remains unclear where the disconnects to tip originate. >=20 > That is part of what I'm requesting exploration of via > different techniques than past attempts that did not provide > the information. >=20 >> If the tip >> session is stopped by typing ~~. from the originating ssh instance = I'm=20 >> returned to the shell on the terminal server. Ssh isn't disturbed. If=20= >> I type ~. the ssh session terminates and I'm back to the = workstation's=20 >> shell. Would it be informative to start a tip session, then ssh in=20 >> separately and try to kill tip? >=20 > A question is of SIGHUP is happening. If it is, then the kill that = would > simulate the issue would be via sending SIGHUP. But this may be only = one > of however many alternatives there may be. I prefer to explore what > is actually happening than attempted simulations via guesses at what = is > happening. >=20 >> I'd expect the ssh part of the link >> to remain up. If not, would it be significant?=20 >>=20 >> Occastionally warnings like >> Jan 10 00:23:30 ns1 sshd[925]: error: beginning MaxStartups = throttling >> show up in console messages. Might those be relevant in some way? =20 >=20 > Hmm. Intersting. Looking around I see notation like: >=20 > MaxStartups 10:30:100 >=20 > where (mostly copy/pasted wording from an example, other than detailed = formatting): >=20 > 10: concurrent unauthenticated sessions before it begins rejecting = some subsequent connections > 30: The percent of subsequent connections that are rejected [but see = below] > 100: At this many concurrent unauthenticated sessions, sshd rejects = all subsequent connections >=20 > Looking, "man sshd_config" reports: >=20 > MaxStartups > Specifies the maximum number of concurrent unauthenticated > connections to the SSH daemon. Additional connections = will be > dropped until authentication succeeds or the = LoginGraceTime > expires for a connection. The default is 10:30:100. >=20 > Alternatively, random early drop can be enabled by = specifying the > three colon separated values start:rate:full (e.g. = "10:30:60"). > sshd(8) will refuse connection attempts with a probability = of > rate/100 (30%) if there are currently start (10) = unauthenticated > connections. The probability increases linearly and all > connection attempts are refused if the number of = unauthenticated > connections reaches full (60). >=20 >=20 > It does suggest that testing isolated from the source(s) of > unauthenticated sessions could be worth while in case handling > the load from such sessions when already heavily loaded with > buildworld/builkernel or the like leads to other problems (and > denial of service consequences?). >=20 > I do not expect that this issue is all that likely but > expectations are not evidence of their own accuracy/inaccuracy. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Wed Jan 10 22:26:07 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4T9MpG24YRz56KtP for ; Wed, 10 Jan 2024 22:26:14 +0000 (UTC) (envelope-from void@f-m.fm) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (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 4T9MpD5MT4z3wx2 for ; Wed, 10 Jan 2024 22:26:12 +0000 (UTC) (envelope-from void@f-m.fm) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=f-m.fm header.s=fm2 header.b=eYTXjBSo; dkim=pass header.d=messagingengine.com header.s=fm2 header.b=PBi8CSll; dmarc=pass (policy=none) header.from=f-m.fm; spf=pass (mx1.freebsd.org: domain of void@f-m.fm designates 64.147.123.21 as permitted sender) smtp.mailfrom=void@f-m.fm Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id B6F513200AC1 for ; Wed, 10 Jan 2024 17:26:10 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute6.internal (MEProxy); Wed, 10 Jan 2024 17:26:10 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=f-m.fm; h=cc :content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm2; t=1704925570; x=1705011970; bh=Z7KRdUG8ot vy5e2a/UYvymbaVD821yA5Tm4EusxFzpM=; b=eYTXjBSo9mH1v6AT717RRAM4+l 6MWHkZPzNZxvRHMu0GvFXY7X05q2leV2Tml0PqUsIwLMevJVRHnei/tpZUQ1J+yO V/lac9jUg1kuITrcuKMIAYPkcoR6n+jDKqb21spzzrHVVMtrrmjSi3sgCdGuqy9W m5tYALEZKWCNfXz4epVG7vKiSys3qsB9BViOO9+wkTlEMQijjK3Y7XpyLYRi4oWk y0cWfl7CBmk4i1gAT4jvdRzOZ3Sm/OREtIbPaLCzbXcd6yLPBAY5zPwE+fRzosXy 1j5TJsTBYGKfO6xi9X/fU5tgw214Epf7jbznma3v/DPEoHBqxqeVMUnJwIVQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; t=1704925570; x=1705011970; bh=Z7KRdUG8otvy5e2a/UYvymbaVD82 1yA5Tm4EusxFzpM=; b=PBi8CSlllwsJke8u6oJVoS2kHyAvlu7ddvHM2ZDEBM7J 1ZPbvgYUQ0otNl1fdYZfCAb1UtJeXmiyo8R9bsSKO7Ag5ww1ib4gph4OqoIAdhtt Hvgxxhm00VbtjrqpLahH1vtziucuD2DXlCaER7YosdiIRxFTOYaGoN6jBHPOle9M 8t+4Af7Iqr7BAsxnqqv8Ve9KcEmBi0ow5NI14Gs6nPH12pW8555HHMyzD1YhPh+P LjuAvV6SFSwdvGFNenaBFaIqRzQJBqbHyz0RTPzPDvBHisioN5R3h8PeIh8m47yv jr0mhnxerJyp0UaPgcBjJsqas3+gPhTtVo1OKha+PA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrvdeiuddgudehkecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepfffhvffukfhfgggtuggjsehttd ertddttddvnecuhfhrohhmpehvohhiugcuoehvohhiugesfhdqmhdrfhhmqeenucggtffr rghtthgvrhhnpeekleduvdelhfeileefgffghfffkedtheellefgudfgvdegkeejjedutd ehhefgueenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhm pehvohhiugesfhdqmhdrfhhm X-ME-Proxy: Feedback-ID: i2541463c:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Wed, 10 Jan 2024 17:26:09 -0500 (EST) Date: Wed, 10 Jan 2024 22:26:07 +0000 From: void To: freebsd-arm@freebsd.org Subject: Re: current for arm64 tries tftp first for some reason Message-ID: Mail-Followup-To: freebsd-arm@freebsd.org References: List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: X-Spamd-Bar: --- X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MID_RHS_NOT_FQDN(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[f-m.fm,none]; RWL_MAILSPIKE_EXCELLENT(-0.40)[64.147.123.21:from]; R_DKIM_ALLOW(-0.20)[f-m.fm:s=fm2,messagingengine.com:s=fm2]; R_SPF_ALLOW(-0.20)[+ip4:64.147.123.21]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[64.147.123.21:from]; FROM_HAS_DN(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_FROM(0.00)[f-m.fm]; MIME_TRACE(0.00)[0:+]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[f-m.fm:+,messagingengine.com:+]; TO_DN_NONE(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; MISSING_XM_UA(0.00)[]; ASN(0.00)[asn:29838, ipnet:64.147.123.0/24, country:US]; FREEMAIL_ENVFROM(0.00)[f-m.fm]; DWL_DNSWL_NONE(0.00)[messagingengine.com:dkim] X-Rspamd-Queue-Id: 4T9MpD5MT4z3wx2 On Tue, Jan 09, 2024 at 09:37:54PM -0800, Mark Millard wrote: >For the RPi4B context I'm dealing with I let the first >time boot go through all its TFTP failures. It produced >a: > >-rwxr-xr-x 1 root wheel uarch 88 Dec 30 00:00:00 1979 /boot/efi/ubootefi.var > >that was not there originally. I wonder if it gives a >means of control over such things that would be >remembered? Unfortunately not. It still goes through tftp 10 or so cycles then boots the usb3 device. This makes boot time take 10 mins or so rather than the usual 20 or so seconds. There is a TUI uefi shell at the uboot stage one can invoke if quick enough (within 3s) the only selectable thing to boot (and it was already selected) is usb 0:1. Not sure what to do now - maybe compare whats in the efi partition to the latest github versions. Also unsure whether it's a uboot issue or a freebsd one, or if it can be fixed with one of the u-boot ports. -- From nobody Wed Jan 10 23:02:20 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4T9Nc10jVWz56Pgp for ; Wed, 10 Jan 2024 23:02:25 +0000 (UTC) (envelope-from void@f-m.fm) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4T9Nc036xkz42Z0 for ; Wed, 10 Jan 2024 23:02:24 +0000 (UTC) (envelope-from void@f-m.fm) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=f-m.fm header.s=fm2 header.b=I2P7F6Lt; dkim=pass header.d=messagingengine.com header.s=fm2 header.b=BuB6gjGG; dmarc=pass (policy=none) header.from=f-m.fm; spf=pass (mx1.freebsd.org: domain of void@f-m.fm designates 64.147.123.21 as permitted sender) smtp.mailfrom=void@f-m.fm Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id 3CA8A3200A68 for ; Wed, 10 Jan 2024 18:02:23 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute6.internal (MEProxy); Wed, 10 Jan 2024 18:02:23 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=f-m.fm; h=cc :content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm2; t=1704927742; x=1705014142; bh=+hMhDUd5vY xroOgInH+ldwbSKImVO8845o1LoG6iYfA=; b=I2P7F6Lt3XlQkonRHXHnmunFjF DbARRIbFF/jp0qaPsEMPpfEmgB318Li9MakqruWkvIauZldMES4nOLoak+j/XczU SoqVeB21EH3xMfDZ8bEwCZol7fes8vtm88QyPm043P96eBD7KTIp1+600DGQuoR/ WMZ0cZdOmVtgOBtKj+IHiXc3vTACmuj9EPS7z2b4aLZN19dI3INAPLfvKQ6jxWeb 3tPS8vSOK1qJSQUoWgJ5zaOIdnbjYvW3U/WPdAMv9HtQbzchSynEuZTSNjN2O7Tq pizvN5XJC3fZoMCoxS/kHIxelkR8BuUc7LWPbx85atdoGofkxbUpQohJpnmQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; t=1704927742; x=1705014142; bh=+hMhDUd5vYxroOgInH+ldwbSKImV O8845o1LoG6iYfA=; b=BuB6gjGGfd4ICQOKaz8Rm0tunAPzGvWjpIn11xc5EH4A nGXdxhBrhetuxEzvroskaK8J0oz1LYclIUVCMZYYqekKHLIX+LovdpRQy03uWlnc Eff6DRn54F+6BaMyvf3CzvsAHsSKxSx7mGPfwgs/8IobyuOCWsxStB9mT9TzwCvH +iR6scSPUpn35zM1l7Uq4I8UGSNdmlWXuTXBSWJRgO7A6lNMRZuDjxohURbdvE8p eEyDX7rhduVxDKxB/CmAquQ2BVG6bWPxscHTOaBUQuwbRo/tzTvd9bJ5/Ibl/eb8 7e4oo3mwC+iLUKldZfprZQM3otFgn47tx33wJ0OAkg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrvdeivddgtdefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggujgesthdtre dttddtvdenucfhrhhomhepvhhoihguuceovhhoihgusehfqdhmrdhfmheqnecuggftrfgr thhtvghrnhepkeeluddvlefhieelfefggffhffektdehleelgfdugfdvgeekjeejuddthe ehgfeunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhep vhhoihgusehfqdhmrdhfmh X-ME-Proxy: Feedback-ID: i2541463c:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Wed, 10 Jan 2024 18:02:22 -0500 (EST) Date: Wed, 10 Jan 2024 23:02:20 +0000 From: void To: freebsd-arm@freebsd.org Subject: Re: current for arm64 tries tftp first for some reason Message-ID: Mail-Followup-To: freebsd-arm@freebsd.org References: <856D59CC-E55C-4667-97EE-458104C8DFEE@yahoo.com> List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <856D59CC-E55C-4667-97EE-458104C8DFEE@yahoo.com> X-Spamd-Bar: --- X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MID_RHS_NOT_FQDN(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[f-m.fm,none]; RWL_MAILSPIKE_EXCELLENT(-0.40)[64.147.123.21:from]; R_DKIM_ALLOW(-0.20)[f-m.fm:s=fm2,messagingengine.com:s=fm2]; R_SPF_ALLOW(-0.20)[+ip4:64.147.123.21:c]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[64.147.123.21:from]; FROM_HAS_DN(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; RCPT_COUNT_ONE(0.00)[1]; ARC_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_FROM(0.00)[f-m.fm]; MIME_TRACE(0.00)[0:+]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[f-m.fm:+,messagingengine.com:+]; TO_DN_NONE(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; MISSING_XM_UA(0.00)[]; ASN(0.00)[asn:29838, ipnet:64.147.123.0/24, country:US]; FREEMAIL_ENVFROM(0.00)[f-m.fm]; DWL_DNSWL_NONE(0.00)[messagingengine.com:dkim] X-Rspamd-Queue-Id: 4T9Nc036xkz42Z0 On Wed, Jan 10, 2024 at 05:07:14AM -0800, Mark Millard wrote: > >The file is not a text file and I've no clue if any >EFI variables happen to be related. My rpi4b context doesn't create /boot/efi/ubootefi.var if the tftp part is allowed to complete. The OS was installed with dd to spinning rust and the ufs2 filesystem as one partition auto-expanded to fill the disk. Maybe this installation method doesn't create it. Previously I've booted to mmcsd, plugged in the usb3 disk, created a 256MB msdos partition, copied all of the msdos part of the mmcsd into that partition, ran bsdinstall with the plugged in disk as the target. -- From nobody Wed Jan 10 23:15:11 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4T9Ntr3D4cz56RCD for ; Wed, 10 Jan 2024 23:15:16 +0000 (UTC) (envelope-from void@f-m.fm) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (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 4T9Ntq5RWXz43Xm for ; Wed, 10 Jan 2024 23:15:15 +0000 (UTC) (envelope-from void@f-m.fm) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=f-m.fm header.s=fm2 header.b=hWSjxfiD; dkim=pass header.d=messagingengine.com header.s=fm2 header.b=gEnxU5Uk; dmarc=pass (policy=none) header.from=f-m.fm; spf=pass (mx1.freebsd.org: domain of void@f-m.fm designates 64.147.123.21 as permitted sender) smtp.mailfrom=void@f-m.fm Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id 759C73200A90 for ; Wed, 10 Jan 2024 18:15:14 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Wed, 10 Jan 2024 18:15:14 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=f-m.fm; h=cc :content-type:content-type:date:date:from:from:in-reply-to :message-id:mime-version:reply-to:subject:subject:to:to; s=fm2; t=1704928513; x=1705014913; bh=LAsW2hWl5BY8AWCeqHBI8glo1zgf/mZN ngIMTd81l9o=; b=hWSjxfiDs63OwhkZDq5m/LfG6jNN9N1dKKTEi5L8ekwxyOMu jH4VPcwa7t2dB1TPFBrJfTmQWYERkjdBlETp0O+9Yh/XRtORLON/9yHB3yPPQoQX MIW5oTrTxa9WbaBFIhreg7JC8KQYi7zsM7b2h++MSQF+x/UmsK/O8gH4lLKEN2Bd Tr23ANvm0lNcWFTfUVDeQSw/bbTAm1ORkEXAybzYohQ5DnSgp2vT2QcSSEGc1xwr ZC1vIzxYp4FZIaO0RPLwaVHIPzcWAql7lMVXjb+KeBXILcS1WFhcuci8DP9IQRCf tVDoqHIWLghNLOdZ0TmM1a2/2HFEU6kH0ocLPA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:message-id :mime-version:reply-to:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t= 1704928513; x=1705014913; bh=LAsW2hWl5BY8AWCeqHBI8glo1zgf/mZNngI MTd81l9o=; b=gEnxU5Ukm8m7/EcqNu+1jMAT42RvEQ3I5hdorFIthBjidJVeD0p BDwLH0nB1pO6JEJjJVnqbBwjTZ5joJPtdaem/AgJQ3CzNj14XA7vI0Py3U89e6Vx hXIkVEk10ge9dtu5ArVu7kdYw4diOWXQwM+I6GgymrzITR8iTlKinQstnraq/w9W 2E8G1YBliQwurgobMQa57/BZC9QWP9ELAp1T3JiHy11Q/Uu9tjKOA2IUQFw1gQUN 1eR9UsBUiotvQbqkBP4InAK9gtcSAIxerRQVTGVExffvOzgTS+trNXfqhkghiSee MhrTGtJ25XGvrgfoRLSKBMEr7l1ZPQcYdJg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrvdeivddgtdeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkgggtugesthdtredttd dtvdenucfhrhhomhepvhhoihguuceovhhoihgusehfqdhmrdhfmheqnecuggftrfgrthht vghrnhepveduffeivdfffffghfegfeejfefftdeiteehteekfefhvdefgfettdeuheegff eunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepvhho ihgusehfqdhmrdhfmh X-ME-Proxy: Feedback-ID: i2541463c:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Wed, 10 Jan 2024 18:15:13 -0500 (EST) Date: Wed, 10 Jan 2024 23:15:11 +0000 From: void To: freebsd-arm@freebsd.org Subject: dev/label/growfs_swap Message-ID: Mail-Followup-To: freebsd-arm@freebsd.org List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline X-Spamd-Bar: --- X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; MID_RHS_NOT_FQDN(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[f-m.fm,none]; RWL_MAILSPIKE_EXCELLENT(-0.40)[64.147.123.21:from]; R_DKIM_ALLOW(-0.20)[f-m.fm:s=fm2,messagingengine.com:s=fm2]; R_SPF_ALLOW(-0.20)[+ip4:64.147.123.21:c]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[64.147.123.21:from]; FROM_HAS_DN(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; RCPT_COUNT_ONE(0.00)[1]; ARC_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_FROM(0.00)[f-m.fm]; MIME_TRACE(0.00)[0:+]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[f-m.fm:+,messagingengine.com:+]; TO_DN_NONE(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; MISSING_XM_UA(0.00)[]; ASN(0.00)[asn:29838, ipnet:64.147.123.0/24, country:US]; FREEMAIL_ENVFROM(0.00)[f-m.fm]; DWL_DNSWL_NONE(0.00)[messagingengine.com:dkim] X-Rspamd-Queue-Id: 4T9Ntq5RWXz43Xm Hi, The swap "utility" /dev/label/growfs_swap is new. The system was installed by writing FreeBSD-15.0-CURRENT-arm64-aarch64-RPI-20240104-8bf0882e186e-267378.img to the hd from another freebsd system then plugging it into the usb3 port of the rpi4. Where can I read about it? it's not in the man page for growfs. # man growfs_swap No manual entry for "growfs_swap" # gpart show = 63 1953525105 da0 MBR (932G) 63 1985 - free - (993K) 2048 102400 1 fat32lba [active] (50M) 104448 1953420720 2 freebsd (931G) => 0 1953420720 da0s2 BSD (931G) 0 128 - free - (64K) 128 1936637824 1 freebsd-ufs (923G) 1936637952 16777216 2 freebsd-swap (8.0G) 1953415168 5552 - free - (2.7M) # cat /etc/fstab # Custom /etc/fstab for FreeBSD embedded images /dev/ufs/rootfs / ufs rw,noatime,async 1 1 /dev/msdosfs/EFI /boot/efi msdosfs rw,noatime 0 0 tmpfs /tmp tmpfs rw,mode=1777 0 0 /dev/label/growfs_swap none swap sw 0 0 -- From nobody Wed Jan 10 23:16:49 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4T9Nwz28bjz56RTm for ; Wed, 10 Jan 2024 23:17:07 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic314-20.consmr.mail.gq1.yahoo.com (sonic314-20.consmr.mail.gq1.yahoo.com [98.137.69.83]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4T9Nwy6mBnz44JC for ; Wed, 10 Jan 2024 23:17:06 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1704928624; bh=P5b8Oc3ONLtQ8UwuNTvLRM5matkDqSsqYlwORsPTMCo=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=CMX1eCI8CKbmi6gNkNoQ8jwBnZdJsAaEKSgFJW8LB9jIFUPh7Hb5pwvhfVrIeLOVDoBe1860QOVqWwIhNIvFK3tbPsZzZ0oG3h1lJUWmNSQMjm696mrJczGV4r7rnv4psaarf2WYsLjpYS5LDAPnPasotdQaW1yMN50Xq0mk51emtv+oaC9gvmLgBySMaf1/23BYZ1zPIkiTE8AIoeMgM/lZXregIvSuQEfnjVeq3gazX0GUIhHvlQdHQoR7FZ+Mot1d8w+PIUyPCnNYaZ6MadGwzO0fnVLFlIzitqBRIW7XxLKsWe/Vh4pVW7tDA/YAT6+bonYm7L+oC1TiE4k3oQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1704928624; bh=NGpahnBW5f2N2ZBqQ/V9Zsrm0lK9bViLEPgfo+nWaFb=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=lLq7xUOUu1JscxKGrvkckqJ4Lw0SFzKcuacrabQejRJc/IldWP2JXpODIUh53FCjTE0DdB7kPbLNNyCbq0eUnmHFiy3mX6pEEzcNOxFoTguNXj+nLk5pdPmR8yz677gJPwUAHIpn+GeDjqxNSUaJOwiKkE3uzWKjC0lKt8yiTENlJlUjlbr0ymp76hBZMfA5IJbFrooo9fpH2l7OkESwzdvJ9QJt6ExhHuw4pwXVP/+Xsyy3+Nksee1zujULEpbFKRPMNf82IWMYXxBJyNu46H1Gxt+SiNJGOpbYeYLsgu0ny5DKfMSgFdC56QZdXWg42Y2q3DYNA3OooEzPOgsTRw== X-YMail-OSG: aK9L91oVM1nKhUsUnYzyZHUXgO2EfZhcNVLpNF1ukJ8U2eLzZkE5hylmB_wIZe5 3A7ZigPlNEBHzGtcSt6osN5X6LjOSG6OAsi4v38i8Yr35Bl0WKfmrB_NZ05b3KJxLgwanIKr_nfr BXG4qsF5D3mwIXqKQKK9DjTw3yV0_WrWhCS7bXTg6W1wOzb2gwg8IJvopMrxf9LFjR5kwpsDgPWC KTGuoiWBGZ3PGTge7EYfpOiBlJfbG7HZObUeL1FlDDR19lHH1RQg68WssEPuC2QpTG29vuQU1ObE FbidHyFyno4fyNZ7955nuhzRMHh1gJSn_MModxeu4XkGlNT1eniLoZkKWTN6bdP_r9SItxbQjPtJ Y.ddT76iygtRw7MK.0vrWIRQFIIOuVcfXzy0YwB3O2XJhmEXOYTwyc9k_vMoF7.u31h29f1C60FB z6rlCUVz9fXM9GhD09c5GKwSlokfYBbYEt_Rcz7Zry0JOT7yKxx33uk_9y3aZ5TwxK0uH_KWmMll lJFR9lVo.OAKcHB.IRjSXZnIV.oAnKaCr86cxQc79CJZJ.lpnANpMUGYPNl_JVOENavqiYAl4lLb jpukqNCLx0OMVMh2KOeU4bs7Ysv525CB8ar_QE5mMEQ.ZpJU9BM.xkQmEw_4Bw2XeA640SBNraI9 en6lK_I5_G9S7SzOe_EbqKSNevGQEKPbU4iibe7..MM2RloHwmUANRt5TdVw2w6HlEh3c6PqVOZj kbjLuB.Sd20sq5z7Ly4vXWCzw0TITdUX8MH3tHLO8qTcJwUqpvqTXgsJZ5sF4U2zcTUlXVSOnLwF U3R62OyfZ7cUA8xeRFKvnzoHMnQXzQLsjuKO8oV5Znu3KcCbO1Jg3WIymvP70eiHLq8bR40sfaPt fv5Zw_hs0ga876HmNYYL3MAu8kNtsZt7IHpnKCHdKPUJBxgJViI_xu.pkXBGsXN2RBcqQqKl5sEC jxKgMFordjS.nSE4KaHs_A0dO9at4EPXY1zX5nPyYY7r9OpUQrRi0y5P_zMWs9B9sZMdt1iX0YfU v7C0WwyTxh3aKVjSe2CzHDsA40NIHV7y6352iJm4ZV2siaSakg.EvdlWVx0T1_mcY1QYZTkmHd7x 4yo9nC82HWG7SdWNNeedKDOSevW2ldeKGHPL10SvSmPjsxqlTdOEs1b8GgT9zPkHmXhBy3fxZKOI ybRMMFGwCDahm2bHk0VMXXkeo4ezA3duecIC62FCG_s__nYOQU.PenIHeeLogtIk8lXdM23Fq.Yu 7L0Wt91Pig48T6lxpOGcVge_KiKoG3hJKeDBj_9L85hWlg7MtW2w6zmziiq10kfeVvD8D2jEX1OV PMEi7sBeUYY5fQG74lTNVaWSK4ZeR365QolM9oYkvQwsj1wLCm.1SZV3oBa.erYCumIpNZTBHoQ3 tnxmXuAyVxSRV7c9zEKAW5rQc.M8lphQcnhNX0P4GJDxnPqvmzFc7x.gRNBuygLI4R0REpu_cfHd S5NuXUx.0R6vmVO4xigj5OB7c8_EaYv_aWdBNBggamvCr.1XGHPW0yAmJdPu5IBlzHR7Ew.zMv3x yo4OeQA50OjtPJiN.MQKHotzIAFZvVhamKQ3TFhZbwOZcpHQa9Gk2OamwbR0MGV0jCPPZ85oUDyi _0a86Vrr6i_WmTyOnGKIdJdB0_EKF8qChWAuw5NrR3PH294iHxpAHbCQ8OIe10fAm4Nb0n36F1XI sPevVOGeZvm.kEaAIXNN7oXGTJJxK7Z.rGL1rDQgysXyVL3HEpbMd2Qm8hr8XQy1TswQ_U4c.3uk t.xu2Z0UNzSiZDuk7MRBGvSOcM04c6pkaf_YmU1ThnonFi.S3BM3HoK9x0ifAp8liLp8EFdbGGpe 3GYDeiThLfQWdCEQkuLDrVS0Ovdzfk4kYP0_Q5v8N8oh1N_ZMbIdFenXCzIFjfHkddsem0OuV4Sq KNY7nghzoAqKipTM73y9FHv2sntg.gxCN7k9JPfzbEIFHYT1jfuTKchPuikLWW5EMm_IBehT1Xds BKYVgkLquRWW02XxWonfLZe7Oofbij9dNXBJV4OFGxF7u9yhWjaD6q2v7tGPhFSGuAht_lBW2V2L SiHLqlKM2gRWLzHcFDHE7DFLp9bvNZ.bkC2qsv0NYSypLy81xZYMxoSXtp9HbDYAvjgUV22w3dCs FyaMBYcoJWLuhy9g7JP04tdqH9KDM0Ko4Aq295PYwuIYWN.AtCrSUwidCx070ALvbuNhYlFYw2hH Cc4qjxZthI_ZVl7._YQoL7bY6xmY3OUsErnHCmOrE72_EkBsR4vq0WfL9OaZ1QcJt9.96TSXWiA- - X-Sonic-MF: X-Sonic-ID: fb6cccf9-c041-4302-aa96-b0ac46e0a498 Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Wed, 10 Jan 2024 23:17:04 +0000 Received: by hermes--production-gq1-78d49cd6df-mvdth (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID e1938f14c8d41deb116c2a59107bdb5e; Wed, 10 Jan 2024 23:16:59 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.300.61.1.2\)) Subject: Re: current for arm64 tries tftp first for some reason From: Mark Millard In-Reply-To: Date: Wed, 10 Jan 2024 15:16:49 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <0DB5FDFB-184F-4260-A060-ED6A6CAFE546@yahoo.com> References: To: void X-Mailer: Apple Mail (2.3774.300.61.1.2) X-Rspamd-Queue-Id: 4T9Nwy6mBnz44JC X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] On Jan 10, 2024, at 14:26, void wrote: > On Tue, Jan 09, 2024 at 09:37:54PM -0800, Mark Millard wrote: >=20 >> For the RPi4B context I'm dealing with I let the first >> time boot go through all its TFTP failures. It produced >> a: >>=20 >> -rwxr-xr-x 1 root wheel uarch 88 Dec 30 00:00:00 1979 = /boot/efi/ubootefi.var >>=20 >> that was not there originally. I wonder if it gives a >> means of control over such things that would be >> remembered? >=20 > Unfortunately not. It still goes through tftp 10 or so cycles then = boots > the usb3 device. This makes boot time take 10 mins or so rather than > the usual 20 or so seconds. >=20 > There is a TUI uefi shell at the uboot stage one can invoke if > quick enough (within 3s) the only selectable thing to boot (and it was = already selected) is usb 0:1. >=20 > Not sure what to do now - maybe compare whats in the efi partition to > the latest github versions. Also unsure whether it's a uboot issue or = a freebsd one, U-Boot is doing tftp activity before the FreeBSD UEFI loader has been found to be loaded. So either the sysutils/u-boot* port's choices for how/what to build or U-Boot itself if building can not control the issue. > or if it can be fixed with one of the u-boot ports. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Wed Jan 10 23:25:21 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4T9P7F4xHQz56SNr for ; Wed, 10 Jan 2024 23:26:01 +0000 (UTC) (envelope-from marietto2008@gmail.com) Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [IPv6:2a00:1450:4864:20::631]) (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 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4T9P7D5295z45FB for ; Wed, 10 Jan 2024 23:26:00 +0000 (UTC) (envelope-from marietto2008@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=G15LrjOy; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of marietto2008@gmail.com designates 2a00:1450:4864:20::631 as permitted sender) smtp.mailfrom=marietto2008@gmail.com Received: by mail-ej1-x631.google.com with SMTP id a640c23a62f3a-a2c179aa5c4so84190966b.0 for ; Wed, 10 Jan 2024 15:26:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704929158; x=1705533958; darn=freebsd.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=B/fQfOTSnAufInRRWatE4A3GVNi3arCudtxIfRWCYuI=; b=G15LrjOyJcEML0itBy7O2GCg+5xIFvQsYtjhHSq4SWYH2O+dDmrnBADtEl6Y2x4eeR ca4/UxHM6qE1j+nIsshjDZ9IJgbk55FS+HyVPP3MYGI33JRZheHkF37mfsiMBu210OTI HnatP0PcJ8snht8xBLS6qv54CGWOyAqQKE1Bb7iTjUeRZypwGOrsdET1KvwoTCEdMcED AU8U1X6IhiTGrESgqORXaHRT/J+njqfisB9mDciTVFf+4eQQ5POt7Dg5vKRzPBV7VSNW 1iNa+i/uVtIDo9rEOMkeXNShpOeF47B5KKgMoYmLBr5FIZfRqEjH19uP/fN2kCkUkOdl nXcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704929158; x=1705533958; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=B/fQfOTSnAufInRRWatE4A3GVNi3arCudtxIfRWCYuI=; b=I3FuIIOBzsf9ZJBkpqxQOk/SSYdC6fn5pFvz6Rt/cpaHfjJPgGV1F/69qKUpNkYQvP NZ4PlNDo8fXh5cNdheWKOtq8N+VyJX33Qr/i6xF1QCGbXNUoaplmDh+iR4uMoyWfNTot 6KMQFPyd1IvfpWf6O85Il3P8/HQe1EfiDSvZgpjQr7s9Sg0BthynZ/KyLd7MXmH9jd6p V/E96T4U1f1HgFy42QRZIY23PBROR1XiV7784PDQrHo5UEbY2Kt0r4kDO5xZnFCpyf6C L342uAKQlsY5U2nSVeHv94Mu40guXC8dMFlomglP1jVqATJJ+jPRLe5uWPIRjZSwrANB YjrQ== X-Gm-Message-State: AOJu0YzzG3w3NchaNyyjNeEAqwjygxOlZqrN74x6keZZv2JQiamP4q9C g2LoOGLAPM2ZtPfmlomKqilRD/NfLhcEsdyakIviH/vsVIY= X-Google-Smtp-Source: AGHT+IFeFfxA6sGN9P4X3fXH9+kzWMBzsfjlp5C1qdneFwbUKqo9PnXVW5OhCxQ6AR6+bvR6Ruv1fB01qw4PtDP71qg= X-Received: by 2002:a17:906:16d6:b0:a2b:63ca:cee7 with SMTP id t22-20020a17090616d600b00a2b63cacee7mr105385ejd.130.1704929158235; Wed, 10 Jan 2024 15:25:58 -0800 (PST) List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 From: Mario Marietto Date: Thu, 11 Jan 2024 00:25:21 +0100 Message-ID: Subject: unknown option "XENHVM" for Arm 32 ; missing code detected. To: freebsd-arm Content-Type: multipart/alternative; boundary="000000000000d80951060e9fc0bd" X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.83 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.991]; NEURAL_HAM_LONG(-0.84)[-0.836]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TO_DN_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCPT_COUNT_ONE(0.00)[1]; FREEMAIL_ENVFROM(0.00)[gmail.com]; FREEMAIL_FROM(0.00)[gmail.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MISSING_XM_UA(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MID_RHS_MATCH_FROMTLD(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; RCVD_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::631:from] X-Rspamd-Queue-Id: 4T9P7D5295z45FB --000000000000d80951060e9fc0bd Content-Type: text/plain; charset="UTF-8" Hello. I'm trying to boot FreeBSD for arm32 bit as DomU on my ARM Chromebook. Basically,with the help of the xen developers I have patched the FreeBSD kernel and I've been able to boot it as if it was a zImage format file. I've enabled all the xen options inside the Linux kernel file used for the domU and this is what happened when I tried to boot the FreeBSD kernel file : mario@devuan-bunsen:/mnt/zroot2/zroot2/OS/Chromebook/freebsd-xen/domU-freebsd# ./start-freebsd Parsing config from freebsd.cfg libxl: debug: libxl_create.c:2081:do_domain_create: ao 0x442780: create: how=(nil) callback=(nil) poller=0x43cc50 libxl: detail: libxl_create.c:662:libxl__domain_make: passthrough: disabled libxl: debug: libxl_arm.c:148:libxl__arch_domain_prepare_config: Configure the domain libxl: debug: libxl_arm.c:151:libxl__arch_domain_prepare_config: - Allocate 0 SPIs libxl: debug: libxl_device.c:415:libxl__device_disk_set_backend: Disk vdev=xvda spec.backend=unknown specification=xen libxl: debug: libxl_device.c:452:libxl__device_disk_set_backend: Disk vdev=xvda, using backend phy libxl: debug: libxl_create.c:1342:initiate_domain_create: Domain 1:running bootloader libxl: debug: libxl_bootloader.c:417:libxl__bootloader_run: Domain 1:no bootloader configured, using user supplied kernel libxl: debug: libxl_event.c:863:libxl__ev_xswatch_deregister: watch w=0x43d8f0: deregister unregistered domainbuilder: detail: xc_dom_allocate: cmdline="console=hvc0", features="" domainbuilder: detail: xc_dom_build_image: called domainbuilder: detail: xc_dom_pfn_to_ptr_retcount: domU mapping: pfn 0x40008+0x966 at 0xb5972000 domainbuilder: detail: xc_dom_alloc_segment: kernel : 0x40008000 -> 0x4096e000 (pfn 0x40008 + 0x966 pages) domainbuilder: detail: xc_dom_load_zimage_kernel: called domainbuilder: detail: xc_dom_load_zimage_kernel: kernel seg 0x40008000-0x4096e000 domainbuilder: detail: xc_dom_load_zimage_kernel: copy 9851212 bytes from blob 0xb62d8000 to dst 0xb5972000 domainbuilder: detail: xc_dom_pfn_to_ptr_retcount: domU mapping: pfn 0x48000+0x1 at 0xb6f0a000 domainbuilder: detail: xc_dom_alloc_segment: devicetree : 0x48000000 -> 0x48001000 (pfn 0x48000 + 0x1 pages) domainbuilder: detail: alloc_magic_pages: called domainbuilder: detail: xc_dom_build_image : virt_alloc_end : 0x48001000 domainbuilder: detail: xc_dom_build_image : virt_pgtab_end : 0x0 domainbuilder: detail: xc_dom_boot_image: called domainbuilder: detail: bootearly: doing nothing domainbuilder: detail: start_info_arm: called domainbuilder: detail: domain builder memory footprint domainbuilder: detail: allocated domainbuilder: detail: malloc : 58 kB domainbuilder: detail: anon mmap : 0 bytes domainbuilder: detail: mapped domainbuilder: detail: file mmap : 9620 kB domainbuilder: detail: domU mmap : 9628 kB domainbuilder: detail: vcpu_arm32: called domainbuilder: detail: Initial state CPSR 0x400001d3 PC 0x40008000 domainbuilder: detail: xc_dom_set_gnttab_entry: d1 gnt[0] -> d0 0x39000 domainbuilder: detail: xc_dom_set_gnttab_entry: d1 gnt[1] -> d0 0x39001 domainbuilder: detail: xc_dom_release: called libxl: debug: libxl_device.c:415:libxl__device_disk_set_backend: Disk vdev=xvda spec.backend=phy specification=xen libxl: debug: libxl_event.c:812:libxl__ev_xswatch_register: watch w=0x4410e4 wpath=/local/domain/0/backend/vbd/1/51712/state token=3/0: register slotnum=3 libxl: debug: libxl_create.c:2120:do_domain_create: ao 0x442780: inprogress: poller=0x43cc50, flags=i libxl: debug: libxl_event.c:750:watchfd_callback: watch w=0x4410e4 wpath=/local/domain/0/backend/vbd/1/51712/state token=3/0: event epath=/local/domain/0/backend/vbd/1/51712/state libxl: debug: libxl_event.c:1054:devstate_callback: backend /local/domain/0/backend/vbd/1/51712/state wanted state 2 still waiting state 1 libxl: debug: libxl_event.c:750:watchfd_callback: watch w=0x4410e4 wpath=/local/domain/0/backend/vbd/1/51712/state token=3/0: event epath=/local/domain/0/backend/vbd/1/51712/state libxl: debug: libxl_event.c:1051:devstate_callback: backend /local/domain/0/backend/vbd/1/51712/state wanted state 2 ok libxl: debug: libxl_event.c:849:libxl__ev_xswatch_deregister: watch w=0x4410e4 wpath=/local/domain/0/backend/vbd/1/51712/state token=3/0: deregister slotnum=3 libxl: debug: libxl_device.c:1150:device_backend_callback: Domain 1:calling device_backend_cleanup libxl: debug: libxl_event.c:863:libxl__ev_xswatch_deregister: watch w=0x4410e4: deregister unregistered libxl: debug: libxl_linux.c:194:libxl__hotplug_disk: Domain 1:Args and environment ready libxl: debug: libxl_device.c:1251:device_hotplug: Domain 1:calling hotplug script: /etc/xen/scripts/block add libxl: debug: libxl_device.c:1252:device_hotplug: Domain 1:extra args: libxl: debug: libxl_device.c:1260:device_hotplug: Domain 1:env: libxl: debug: libxl_device.c:1267:device_hotplug: Domain 1: script: /etc/xen/scripts/block libxl: debug: libxl_device.c:1267:device_hotplug: Domain 1: XENBUS_TYPE: vbd libxl: debug: libxl_device.c:1267:device_hotplug: Domain 1: XENBUS_PATH: backend/vbd/1/51712 libxl: debug: libxl_device.c:1267:device_hotplug: Domain 1: XENBUS_BASE_PATH: backend libxl: debug: libxl_aoutils.c:593:libxl__async_exec_start: forking to execute: /etc/xen/scripts/block add libxl: debug: libxl_event.c:863:libxl__ev_xswatch_deregister: watch w=0x441168: deregister unregistered libxl: debug: libxl_linux.c:211:libxl__get_hotplug_script_info: Domain 1:num_exec 1, not running hotplug scripts libxl: debug: libxl_device.c:1236:device_hotplug: Domain 1:No hotplug script to execute libxl: debug: libxl_event.c:863:libxl__ev_xswatch_deregister: watch w=0x441168: deregister unregistered libxl: debug: libxl_event.c:812:libxl__ev_xswatch_register: watch w=0x43e7cc wpath=/local/domain/1/console/tty token=3/1: register slotnum=3 libxl: debug: libxl_event.c:750:watchfd_callback: watch w=0x43e7cc wpath=/local/domain/1/console/tty token=3/1: event epath=/local/domain/1/console/tty libxl: debug: libxl_event.c:750:watchfd_callback: watch w=0x43e7cc wpath=/local/domain/1/console/tty token=3/1: event epath=/local/domain/1/console/tty libxl: debug: libxl_event.c:2403:libxl__ao_progress_report: ao 0x442780: progress report: ignored libxl: debug: libxl_event.c:849:libxl__ev_xswatch_deregister: watch w=0x43e7cc wpath=/local/domain/1/console/tty token=3/1: deregister slotnum=3 libxl: debug: libxl_event.c:863:libxl__ev_xswatch_deregister: watch w=0x43e7cc: deregister unregistered libxl: debug: libxl_event.c:2067:libxl__ao_complete: ao 0x442780: complete, rc=0 libxl: debug: libxl_event.c:2036:libxl__ao__destroy: ao 0x442780: destroy libxl: debug: libxl_domain.c:704:libxl_domain_unpause: Domain 1:ao 0x442780: create: how=(nil) callback=(nil) poller=0x43cc50 libxl: debug: libxl_event.c:2067:libxl__ao_complete: ao 0x442780: complete, rc=0 libxl: debug: libxl_domain.c:712:libxl_domain_unpause: Domain 1:ao 0x442780: inprogress: poller=0x43cc50, flags=ic libxl: debug: libxl_event.c:2036:libxl__ao__destroy: ao 0x442780: destroy xencall:buffer: debug: total allocations:98 total releases:98 xencall:buffer: debug: current allocations:0 maximum allocations:3 xencall:buffer: debug: cache current size:3 xencall:buffer: debug: cache hits:86 misses:3 toobig:9 xencall:buffer: debug: total allocations:0 total releases:0 xencall:buffer: debug: current allocations:0 maximum allocations:0 xencall:buffer: debug: cache current size:0 xencall:buffer: debug: cache hits:0 misses:0 toobig:0 FROZEN. I see these two processes enabled...but I don't know how to use FreeBSD... # ps ax 2606 ? Ssl 0:00 xl -vvvv create freebsd.cfg 2607 pts/0 Sl+ 0:00 /usr/lib/xen-4.17/bin/xenconsole 1 --num 0 --type pv now the fun begins...because,based on what say the xen developers : ... the ps output, it seems that ``xl create`` completed and you have the console open. So the freeze you mention is just because your FreeBSD guest is not outputting anything. As mentioned earlier, I don't think a lot of testing has been done for 32-bit Arm FreeBSD. So it is quite possible that there are some pieces of code missing. The first step is to check if the FreeBSD kernel was built with Xen options. If they are, then you will need to find out where FreeBSD is stuck (or why the console is not enabled). Unfortunately, we don't have any support to use GDB on the guest kernel. So you will have to modify FreeBSD a bit to check where it freezes. Assuming you have a debug build of the hypervisor, then you can sprinkle the FreeBSD boot code with the assembly instruction 'hvc 0xfffc'. When this is reached, this will issue an hypercall that will print on the Xen console that the given instruction has reached (the PC will be printed). There are other useful 'hvc' calls implemented by Xen for low level debugging. You can look at do_debug_trap() in Xen code. I've added this to GENERIC kernel of FreeBSD guest : # Xen HVM Guest Optimizations # NOTE: XENHVM depends on xenpci. They must be added or removed together. options XENHVM # Xen HVM kernel infrastructure device xenpci # Xen HVM Hypervisor services driver Unfortunately,it is not accepted : unknown option "XENHVM" I've found these parameters ONLY on the file /usr/src/sys/conf/files.amd64 : x86/xen/pv.c optional xenhvm x86/xen/pvcpu_enum.c optional xenhvm x86/xen/xen_pci_bus.c optional xenhvm Look at the prefix x86. It is not for arm. It seems there is a piece of code that hasn't been written. Is there a chance to add it ? Does anyone want to help ? No arch/arm64 does not contain Xen in KERNCONF either. Surprisingly files.x86 invokes a different set of files. I don't know what build it is. x86/xen/hvm.c optional xenhvm x86/xen/xen_intr.c optional xenhvm x86/xen/xen_apic.c optional xenhvm x86/xen/xenpv.c optional xenhvm x86/xen/xen_msi.c optional xenhvm x86/xen/xen_nexus.c optional xenhvm -- Mario. --000000000000d80951060e9fc0bd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello.

I'm trying to boot FreeBSD for arm32 bit as DomU on my ARM Chromebook. = Basically,with the help of the xen developers I have patched the FreeBSD ke= rnel and I've been able to boot it as if it was a zImage format file. <= br>

I've enabled all the xen options inside th= e Linux kernel file used for the domU and this is what happened when I trie= d to boot the FreeBSD kernel file :


mario@devuan-bunsen:/mn=
t/zroot2/zroot2/OS/Chromebook/freebsd-xen/domU-freebsd# ./start-freebsd

Parsing config from freebsd.cfg

libxl: debug: libxl_create.c:2081:do_domain_create: ao 0x442780: create: ho=
w=3D(nil) callback=3D(nil) poller=3D0x43cc50

libxl: detail: libxl_create.c:662:libxl__domain_make: passthrough: disabled
libxl: debug: libxl_arm.c:148:libxl__arch_domain_prepare_config: Configure =
the domain
libxl: debug: libxl_arm.c:151:libxl__arch_domain_prepare_config: - Allocate=
 0 SPIs

libxl: debug: libxl_device.c:415:libxl__device_disk_set_backend: Disk vdev=
=3Dxvda spec.backend=3Dunknown specification=3Dxen

libxl: debug: libxl_device.c:452:libxl__device_disk_set_backend: Disk vdev=
=3Dxvda, using backend phy
libxl: debug: libxl_create.c:1342:initiate_domain_create: Domain 1:running =
bootloader
libxl: debug: libxl_bootloader.c:417:libxl__bootloader_run: Domain 1:no boo=
tloader configured, using user supplied kernel

libxl: debug: libxl_event.c:863:libxl__ev_xswatch_deregister: watch w=3D0x4=
3d8f0: deregister unregistered domainbuilder: detail: xc_dom_allocate: cmdl=
ine=3D"console=3Dhvc0", features=3D""

domainbuilder: detail: xc_dom_build_image: called
domainbuilder: detail: xc_dom_pfn_to_ptr_retcount: domU mapping: pfn 0x4000=
8+0x966 at 0xb5972000
domainbuilder: detail: xc_dom_alloc_segment:   kernel       : 0x40008000 -&=
gt; 0x4096e000  (pfn 0x40008 + 0x966 pages)
domainbuilder: detail: xc_dom_load_zimage_kernel: called
domainbuilder: detail: xc_dom_load_zimage_kernel: kernel seg 0x40008000-0x4=
096e000
domainbuilder: detail: xc_dom_load_zimage_kernel: copy 9851212 bytes from b=
lob 0xb62d8000 to dst 0xb5972000
domainbuilder: detail: xc_dom_pfn_to_ptr_retcount: domU mapping: pfn 0x4800=
0+0x1 at 0xb6f0a000
domainbuilder: detail: xc_dom_alloc_segment:   devicetree   : 0x48000000 -&=
gt; 0x48001000  (pfn 0x48000 + 0x1 pages)
domainbuilder: detail: alloc_magic_pages: called
domainbuilder: detail: xc_dom_build_image  : virt_alloc_end : 0x48001000
domainbuilder: detail: xc_dom_build_image  : virt_pgtab_end : 0x0
domainbuilder: detail: xc_dom_boot_image: called
domainbuilder: detail: bootearly: doing nothing
domainbuilder: detail: start_info_arm: called
domainbuilder: detail: domain builder memory footprint
domainbuilder: detail:    allocated
domainbuilder: detail:       malloc             : 58 kB
domainbuilder: detail:       anon mmap          : 0 bytes
domainbuilder: detail:    mapped
domainbuilder: detail:       file mmap          : 9620 kB
domainbuilder: detail:       domU mmap          : 9628 kB
domainbuilder: detail: vcpu_arm32: called
domainbuilder: detail: Initial state CPSR 0x400001d3 PC 0x40008000
domainbuilder: detail: xc_dom_set_gnttab_entry: d1 gnt[0] -> d0 0x39000
domainbuilder: detail: xc_dom_set_gnttab_entry: d1 gnt[1] -> d0 0x39001
domainbuilder: detail: xc_dom_release: called

libxl: debug: libxl_device.c:415:libxl__device_disk_set_backend: Disk vdev=
=3Dxvda spec.backend=3Dphy specification=3Dxen

libxl: debug: libxl_event.c:812:libxl__ev_xswatch_register: watch w=3D0x441=
0e4 wpath=3D/local/domain/0/backend/vbd/1/51712/state token=3D3/0: register=
 slotnum=3D3

libxl: debug: libxl_create.c:2120:do_domain_create: ao 0x442780: inprogress=
: poller=3D0x43cc50, flags=3Di

libxl: debug: libxl_event.c:750:watchfd_callback: watch w=3D0x4410e4 wpath=
=3D/local/domain/0/backend/vbd/1/51712/state token=3D3/0: event epath=3D/lo=
cal/domain/0/backend/vbd/1/51712/state

libxl: debug: libxl_event.c:1054:devstate_callback: backend /local/domain/0=
/backend/vbd/1/51712/state wanted state 2 still waiting state 1

libxl: debug: libxl_event.c:750:watchfd_callback: watch w=3D0x4410e4 wpath=
=3D/local/domain/0/backend/vbd/1/51712/state token=3D3/0: event epath=3D/lo=
cal/domain/0/backend/vbd/1/51712/state

libxl: debug: libxl_event.c:1051:devstate_callback: backend /local/domain/0=
/backend/vbd/1/51712/state wanted state 2 ok

libxl: debug: libxl_event.c:849:libxl__ev_xswatch_deregister: watch w=3D0x4=
410e4 wpath=3D/local/domain/0/backend/vbd/1/51712/state token=3D3/0: deregi=
ster slotnum=3D3

libxl: debug: libxl_device.c:1150:device_backend_callback: Domain 1:calling=
 device_backend_cleanup
libxl: debug: libxl_event.c:863:libxl__ev_xswatch_deregister: watch w=3D0x4=
410e4: deregister unregistered
libxl: debug: libxl_linux.c:194:libxl__hotplug_disk: Domain 1:Args and envi=
ronment ready
libxl: debug: libxl_device.c:1251:device_hotplug: Domain 1:calling hotplug =
script: /etc/xen/scripts/block add
libxl: debug: libxl_device.c:1252:device_hotplug: Domain 1:extra args:
libxl: debug: libxl_device.c:1260:device_hotplug: Domain 1:env:
libxl: debug: libxl_device.c:1267:device_hotplug: Domain 1: script: /etc/xe=
n/scripts/block
libxl: debug: libxl_device.c:1267:device_hotplug: Domain 1: XENBUS_TYPE: vb=
d
libxl: debug: libxl_device.c:1267:device_hotplug: Domain 1: XENBUS_PATH: ba=
ckend/vbd/1/51712
libxl: debug: libxl_device.c:1267:device_hotplug: Domain 1: XENBUS_BASE_PAT=
H: backend
libxl: debug: libxl_aoutils.c:593:libxl__async_exec_start: forking to execu=
te: /etc/xen/scripts/block add
libxl: debug: libxl_event.c:863:libxl__ev_xswatch_deregister: watch w=3D0x4=
41168: deregister unregistered
libxl: debug: libxl_linux.c:211:libxl__get_hotplug_script_info: Domain 1:nu=
m_exec 1, not running hotplug scripts
libxl: debug: libxl_device.c:1236:device_hotplug: Domain 1:No hotplug scrip=
t to execute
libxl: debug: libxl_event.c:863:libxl__ev_xswatch_deregister: watch w=3D0x4=
41168: deregister unregistered

libxl: debug: libxl_event.c:812:libxl__ev_xswatch_register: watch w=3D0x43e=
7cc wpath=3D/local/domain/1/console/tty token=3D3/1: register slotnum=3D3

libxl: debug: libxl_event.c:750:watchfd_callback: watch w=3D0x43e7cc wpath=
=3D/local/domain/1/console/tty token=3D3/1: event epath=3D/local/domain/1/c=
onsole/tty

libxl: debug: libxl_event.c:750:watchfd_callback: watch w=3D0x43e7cc wpath=
=3D/local/domain/1/console/tty token=3D3/1: event epath=3D/local/domain/1/c=
onsole/tty

libxl: debug: libxl_event.c:2403:libxl__ao_progress_report: ao 0x442780: pr=
ogress report: ignored

libxl: debug: libxl_event.c:849:libxl__ev_xswatch_deregister: watch w=3D0x4=
3e7cc wpath=3D/local/domain/1/console/tty token=3D3/1: deregister slotnum=
=3D3

libxl: debug: libxl_event.c:863:libxl__ev_xswatch_deregister: watch w=3D0x4=
3e7cc: deregister unregistered
libxl: debug: libxl_event.c:2067:libxl__ao_complete: ao 0x442780: complete,=
 rc=3D0
libxl: debug: libxl_event.c:2036:libxl__ao__destroy: ao 0x442780: destroy

libxl: debug: libxl_domain.c:704:libxl_domain_unpause: Domain 1:ao 0x442780=
: create: how=3D(nil) callback=3D(nil) poller=3D0x43cc50

libxl: debug: libxl_event.c:2067:libxl__ao_complete: ao 0x442780: complete,=
 rc=3D0

libxl: debug: libxl_domain.c:712:libxl_domain_unpause: Domain 1:ao 0x442780=
: inprogress: poller=3D0x43cc50, flags=3Dic

libxl: debug: libxl_event.c:2036:libxl__ao__destroy: ao 0x442780: destroy

xencall:buffer: debug: total allocations:98 total releases:98
xencall:buffer: debug: current allocations:0 maximum allocations:3
xencall:buffer: debug: cache current size:3
xencall:buffer: debug: cache hits:86 misses:3 toobig:9
xencall:buffer: debug: total allocations:0 total releases:0
xencall:buffer: debug: current allocations:0 maximum allocations:0
xencall:buffer: debug: cache current size:0
xencall:buffer: debug: cache hits:0 misses:0 toobig:0

FROZEN.

I see these two processes enabled...but I don't know how to use FreeBSD= ...

=09 =09 
# ps ax
2606 ?        Ssl    0:00 xl -vvvv create freebsd.cfg
2607 pts/0    Sl+    0:00 /usr/lib/xen-4.17/bin/xenconsole 1 --num 0 --type=
 pv

now the fun begins...because,based on what say the xen developers :

=09
=09
... the ps output, it seems that ``xl create`` completed and you have the console open. So the freeze you mention is just because your=20 FreeBSD guest is not outputting anything. As mentioned earlier, I don't= =20 think a lot of testing has been done for 32-bit Arm FreeBSD. So it is=20 quite possible that there are some pieces of code missing. The first=20 step is to check if the FreeBSD kernel was built with Xen=20 options. If they are, then you will need to find out where FreeBSD is=20 stuck (or why the console is not enabled). Unfortunately, we don't have= =20 any support to use GDB on the guest kernel. So you will have to modify=20 FreeBSD a bit to check where it freezes. Assuming you have a debug=20 build of the hypervisor, then you can sprinkle the FreeBSD boot code=20 with the assembly instruction 'hvc 0xfffc'. When this is reached, t= his=20 will issue an hypercall that will print on the Xen console that the given= =20 instruction has reached (the PC will be printed). There are other useful=20 'hvc' calls implemented by Xen for low level debugging. You can loo= k at=20 do_debug_trap() in Xen code.
=09

I've added this to GENERIC kernel of FreeBS= D guest :

=09 =09 
# Xen HVM Guest Optimizations

# NOTE: XENHVM depends on xenpci.  They must be added or removed togeth=
er.

options     XENHVM            # Xen HVM kernel infrastructure
device      xenpci            # Xen HVM Hypervisor services driver

<=
/code>
Unfortunately,it is not accepted :

unknown option "XENHVM"


I've found these parameters ONLY on the file /usr/src/sys/conf/files.amd64 :

<=
/code>

		
x86/xen/pv.c           =
 optional    xenhvm
x86/xen/pvcpu_enum.c    optional    xenhvm
x86/xen/xen_pci_bus.c   optional    xenhvm

Look at the prefix x86. It is not for arm. It seems th= ere is a piece of code that hasn't been written. Is there a chance to a= dd it ? Does anyone want to help ?

No arch/arm64 d= oes not contain Xen in KERNCONF either.

Surprisingly files.x86 invokes a diff= erent set of files. I don't know what build it is.

=09 =09 
x86/xen/hvm.c          =
  optional    xenhvm
x86/xen/xen_intr.c       optional    xenhvm
x86/xen/xen_apic.c       optional    xenhvm
x86/xen/xenpv.c          optional    xenhvm
x86/xen/xen_msi.c        optional    xenhvm
x86/xen/xen_nexus.c      optional    xenhvm

--
=
Mario.
--000000000000d80951060e9fc0bd-- From nobody Wed Jan 10 23:39:44 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4T9PR85SkYz56TZh for ; Wed, 10 Jan 2024 23:39:48 +0000 (UTC) (envelope-from mike@karels.net) Received: from mail2.karels.net (mail2.karels.net [3.19.118.201]) (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 "freebsd", Issuer "freebsd" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4T9PR83Q7Lz47mx for ; Wed, 10 Jan 2024 23:39:48 +0000 (UTC) (envelope-from mike@karels.net) Authentication-Results: mx1.freebsd.org; none Received: from mail2.karels.net (localhost [IPv6:0:0:0:0:0:0:0:1]) by mail2.karels.net (8.17.1/8.17.1) with ESMTP id 40ANdivh049321; Wed, 10 Jan 2024 17:39:45 -0600 (CST) (envelope-from mike@karels.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=karels.net; s=mail2; t=1704929985; bh=2jjwfwKSnuYIr41aoGApyjSMdRzsufDv9VYz4nkMweE=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=aRY12hA3cwN/PQgrwKl06APz9/lASCea+CowMXnmZAOo278FhDvAYSz+Dq3Fi83tv 9O1xp0sIyrALPzU9AknVIU3SA7nNL13yP8SuIHMEp95Jf7b2AD1EszHPbdGAGi70Qc sR/qkMLPjg5Y0pwifYQmXg5/FmKpbuh5/KNbkXL/+5z5gwjAwjR1eVBKMUlBh3z8I0 CLmwvby7cLgrW32IBS3bDkMSlm2wUQHQgOc6a450xCAwqbuLnvYu8z+RZYYWcn4i+P K5hiiS9DQBZGVz4RCjeSBdw9Syn/hpwNig7ng3BhWxhxOr2fVaLR3J7WcxxGdPvY30 KmKsQ+wPss2eg== Received: from [10.0.2.130] ([73.62.165.147]) by mail2.karels.net with ESMTPSA id a/vWN8Aqn2WnwAAAs/W3XQ (envelope-from ); Wed, 10 Jan 2024 17:39:44 -0600 From: Mike Karels To: void Cc: freebsd-arm@freebsd.org Subject: Re: dev/label/growfs_swap Date: Wed, 10 Jan 2024 17:39:44 -0600 X-Mailer: MailMate (1.14r6015) Message-ID: In-Reply-To: References: List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4T9PR83Q7Lz47mx X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:16509, ipnet:3.16.0.0/14, country:US] On 10 Jan 2024, at 17:15, void wrote: > Hi, > > The swap "utility" /dev/label/growfs_swap is new. > > The system was installed by writing FreeBSD-15.0-CURRENT-arm64-aarch64-= RPI-20240104-8bf0882e186e-267378.img > to the hd from another freebsd system then plugging it into the usb3 > port of the rpi4. > > Where can I read about it? it's not in the man page for > growfs. > > # man growfs_swap > No manual entry for "growfs_swap" > > # gpart show > =3D 63 1953525105 da0 MBR (932G) > 63 1985 - free - (993K) > 2048 102400 1 fat32lba [active] (50M) > 104448 1953420720 2 freebsd (931G) > > =3D> 0 1953420720 da0s2 BSD (931G) > 0 128 - free - (64K) > 128 1936637824 1 freebsd-ufs (923G) > 1936637952 16777216 2 freebsd-swap (8.0G) > 1953415168 5552 - free - (2.7M) > > # cat /etc/fstab > # Custom /etc/fstab for FreeBSD embedded images > /dev/ufs/rootfs / ufs rw,noatime,async = 1 1 > /dev/msdosfs/EFI /boot/efi msdosfs rw,noatime = 0 0 > tmpfs /tmp tmpfs rw,mode=3D1777 0 = 0 > /dev/label/growfs_swap none swap sw 0 = 0 > > -- See growfs(7) (man 7 growfs). Mike From nobody Wed Jan 10 23:41:40 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4T9PTg483Kz56V7X for ; Wed, 10 Jan 2024 23:41:59 +0000 (UTC) (envelope-from pmh@hausen.com) Received: from mail2.pluspunkthosting.de (mail2.pluspunkthosting.de [217.29.33.228]) (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 4T9PTg0wLBz49T9 for ; Wed, 10 Jan 2024 23:41:58 +0000 (UTC) (envelope-from pmh@hausen.com) Authentication-Results: mx1.freebsd.org; none Received: from smtpclient.apple (87.138.185.145) by mail2.pluspunkthosting.de (Axigen) with (ECDHE-RSA-AES256-GCM-SHA384 encrypted) ESMTPSA id 270632; Thu, 11 Jan 2024 00:41:50 +0100 Content-Type: multipart/alternative; boundary=Apple-Mail-A1AE1BD4-4863-4B1C-99F0-FD5C82D62183 Content-Transfer-Encoding: 7bit From: "Patrick M. Hausen" List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (1.0) Subject: Re: dev/label/growfs_swap Date: Thu, 11 Jan 2024 00:41:40 +0100 Message-Id: <93442EFA-8521-4CC4-B613-15E1EA31BEEC@hausen.com> References: Cc: freebsd-arm@freebsd.org In-Reply-To: To: void X-Mailer: iPad Mail (21C62) X-Rspamd-Queue-Id: 4T9PTg0wLBz49T9 X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:16188, ipnet:217.29.32.0/20, country:DE] --Apple-Mail-A1AE1BD4-4863-4B1C-99F0-FD5C82D62183 Content-Type: multipart/related; type="text/html"; boundary=Apple-Mail-6DA3E728-E493-4977-A102-760431E01515 Content-Transfer-Encoding: 7bit --Apple-Mail-6DA3E728-E493-4977-A102-760431E01515 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable
Hi all,

Am 11.01.2024 um 00:15 schrieb void <void@f-m.fm>:
The swa= p "utility" /dev/label/growfs_swap is new.

That's just a geom label. It's created by this script since this c= ommit:
Kind regards,
Patrick
= --Apple-Mail-6DA3E728-E493-4977-A102-760431E01515 Content-Type: image/x-icon; name=freebsd.ico; x-apple-part-url=22170A4D-C7B1-49E3-B0FF-483B989C222E Content-Disposition: inline; filename=freebsd.ico Content-Transfer-Encoding: base64 Content-Id: <22170A4D-C7B1-49E3-B0FF-483B989C222E> AAABAAIAEBAAAAEAIABoBAAAJgAAACAgAAABACAAqBAAAI4EAAAoAAAAEAAAACAAAAABACAAAAAA AEAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAADwMCACMDAQAk AAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANDAYyKyxGlykrgdMn LJrpJkKo6SBjmdQiS1ebDAoHNgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAvLy5uQEKY7xYc z/8EEdz/AhnX/wIl6v8HQPf/G3P+/1eIxfMyMjZ3AAAAAgAAAAAAAAAAAAAAAAAAAAA5OTNrUlOs /gADwf8ADMj/ARvM/wIozf8DM9v/Azrj/wBA7v8UX/7/d5fm/zc2OHYAAAAAAAAAAAAAAAAQEAks c3Oa5wcKuP8AD8//Ah3T/wIn1P8CH7r/ARO9/wEStv8BHsT/ATHS/yhV5/+Kk8XuDw0INQAAAAAA AAAAWlpXikVHtf8ACMj/Ah7b/wIl3f8ADMT/AACS/wAAsf8AALD/AACo/wAAk/8EFan/jMn//2Fq Y5YAAAAAAAAACW9uh8USH8T/ABzd/wIp5f8BDtb/AADG/wAAoP8AAKP/AAC7/wAAuP8AAJT/AAB1 /0Z11f+PrazPAAAADgcGABdqbJ/cAh7e/wAn6f8CJOf/AADa/wAA1/8AALb/AACm/wAAof8AAK7/ AACr/wAAd/8KEpf/gpm75QgGACEEAwAXc3mo3DBn7/84dvT/AB/p/wAA5f8AAOX/AADJ/wAAuP8A AKX/AACR/wAAj/8BAX3/CAt3/258peQKCQMfAAAAB3+AlsGcv/7/2PH+/0579f8AEvL/AADy/wAA 2v8AAML/AACt/wAAmf8MC4P/JSRx/0dOiP9yeozMAAAADQAAAABWVVeB1t///+bv/v/c7f7/h6H8 /z5f/P8hNez/JiXP/ykpvv8/P7H/Jiil/xwdl/+Eh8H/XV5ajwAAAAAAAAAAFBMiU8vM5f/2+/// +fz+/+Pl/P/I2vz/ttL7/7jJ9f/Oz+//p63l/0pY9v8AAL7/Skqv/yUlL10AAAAAAAAAAAsLV6U5 PL//5OX9//7////z9v7/6PP9//Dy/P/y+v7/x8/v/7bD7v/6/P//XWfv/wcJsf8eHmGrAAAAAQAA BCQAAILnJi3V/6ay///m6+77///9/////////////////8TE8v+RmeP/4uvy++Xr//9ZX+D/AAGI 7AAABigAAAMiDQ921GRpt987RWqOJCcuTIKCgYzAwMDH2NjX39PT1+C/wMPJk5KPjC0xNkpGTWWK bHC43AsNedkAAAQmAAAAAQEBAxoBAQIWAAAAAAAAAAAFBQUAFhYWCiMjIxslJSQbGxsaCwwMCwAB AQEAAAAAAAAAARQAAAMbAAAAAvw////wD///4AP//8AD//+AAf//gAH//wAA//8AAP//AAD//wAA //+AAf//gAH//4AA//8AAP//AAD//xw4//8oAAAAIAAAAEAAAAABACAAAAAAAIAQAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAACAAAAAwAAAAMAAAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAgAAAAcAAAASAAAAIQAAADAAAAA7AAAAOwAAADMAAAAiAAAAEgAAAAcAAAACAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAABAAAABEAAAAvCgkDZycmKJwwMVHAMjRo3Dc8deQ9QnjlNEpx3iFJXsUZ MjegCwoIbQAAADIAAAARAAAABQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAAAqFRUNeFNUYtJUWKb8SE7P/zA23P8nMNz/KTTf /ytB7P8faPj/JJb+/zOw9/87osv+PGd32BoVFIIAAAAwAAAADgAAAAEAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAQAgIAS1FRTr11eLn+MDbS/wcNzf8A Bcv/AAjS/wAPzv8AFMn/ABjg/wAc5P8CKOj/CUDu/xx7+/87u///bKzZ/1FRXcsHBQJYAAAAEwAA AAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAFQ0NCGOIiZLmW1/L /wUHtf8AALz/AAjK/wAQ0f8CFtX/AhzP/wIhzv8CJd//Airh/wIt5P8CMOj/ADHr/wRG8P8sjP3/ kbj//3+Kpe8UEg9xAAAAGAAAAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAA4L CwhhoaGm61JVwv8AAJ3/AAW8/wEMyP8BEcj/AhbK/wIbzv8CIcj/AibO/wIq2v8DMN3/AzTh/wM6 5f8DP+r/AkDt/wBC8P8tbPL/lbj//4+Zs/QWFRFxAAAAEwAAAAEAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAJAAAAR6KioeFsbsL/AACT/wEHv/8BDMb/ARHH/wIWyf8CHMz/AiDQ/wIlw/8CLM7/ AzLY/wM43P8DPuH/A0Pm/wRI6v8ETO3/BE/w/wBH5v8pYOj/orr//5CWquwIBwRWAAAADAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAwAAACVnZ2CyqKnW/wAAg/8AB8H/AQ3J/wESy/8CF87/AhzQ/wIh 0v8CJ9b/Ai7J/wMw0f8DK9L/AifK/wIjxP8CKMn/AzXX/wND4/8IT+z/DU3g/wc/2v9DZ+X/ucX+ /2Zma8UAAAAuAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAOFRUTatPT1vozM5H/AACq/wEOz/8BEs7/ AhfR/wId1P8CIdb/Aina/wIq2v8CHKv/AAil/wAAs/8AAKz/AACn/wAApP8AAKb/AAKw/wMVw/8L MsL/FULR/xI30/91h+3/wcrg/yQjIX4AAAARAAAAAAAAAAAAAAAAAAAAAQAAACWFhX/AoKDP/wAA iv8ADsj/ARPT/wIY1f8CHdj/AiPb/wIq3v8CItj/AAe+/wAAh/8AAJP/AAC5/wAAtP8AALH/AACt /wAAqP8AAKb/AACp/wAAiP8HEZ//HDvY/0h87f/N8f//hoyL0QAAADAAAAACAAAAAAAAAAAAAAAF BwcFUcfHx/I3OKL/AAWk/wETzP8CGNn/Ah3a/wIi3f8CK+H/AiDa/wACxv8AALn/AACT/wAAj/8A ALH/AAC9/wAAtv8AALP/AACu/wAAqv8AAKX/AAB//wAAgf8KErH/Uanz/7D////H2tr+FRMTZwAA AAcAAAAAAAAAAAAAAAtERD+GxMPf/wUNnP8AErn/AhnU/wIe3v8CI+D/Airk/wIl4f8AA8z/AADL /wAAwf8AAJ3/AACY/wAAm/8AALn/AAC//wAAuP8AALP/AACv/wAAqf8AAHr/AAB5/wAAh/8dPrn/ iPT//9r9//9LSUmZAAAAEQAAAAAAAAAAAAAAFnJya6iXmNX/AAes/wIZ1v8CHuD/AiPi/wIp5f8D Lef/AQvV/wAAz/8AANP/AADI/wAAp/8AAKT/AACd/wAAnv8AALn/AADA/wAAuf8AALP/AACw/wAA h/8AAG3/AACC/wAAjf9Ad9f/zf///3Z1d7wAAAAeAAAAAAAAAAAAAAAhj46Iv36B0f8ADMT/Ah7h /wIj4/8CKOb/AzDq/wIj5f8AANX/AADY/wAA2f8AAND/AACx/wAArf8AAKj/AACg/wAAnP8AAK// AAC8/wAAuv8AALT/AACg/wAAbP8AAHn/AACG/wgTpv+u4v//mp+e1wAAACwAAAABAAAAAQAAACec m5fLbXTU/wAY1v8AJ+T/ACrm/wIv6v8DNu7/ARPh/wAA3P8AAN7/AADf/wAA1/8AALz/AAC3/wAA sf8AAKr/AACh/wAAl/8AAJr/AACq/wAAtf8AALT/AACD/wAAbf8AAHz/AACJ/4Ge7f+ss6/hAAAA NgAAAAIAAAABAAAAJpqYlst5gt3/AC3d/xBM6f8VT+z/Aj3u/wI27/8ABeH/AADi/wAA5P8AAOX/ AADf/wAAxv8AAL//AAC5/wAAsP8AAKj/AACf/wAAlP8AAIr/AACO/wAAnv8AAKH/AQFw/wICbv8A AHX/aoXY/660r98AAAA0AAAAAgAAAAAAAAAfgoGBvKar7P8dX+T/X570/4u2+P9EhPb/AEPx/wAI 5v8AAOj/AADq/wAA6v8AAOj/AADS/wAAx/8AAMD/AAC3/wAArv8AAKT/AACa/wAAkf8AAIX/AAB8 /wIDfv8GB3H/DQxj/wcJcf9yjdH/oaKe0gAAACkAAAABAAAAAAAAABRnZmajzs32/1qF5/9/vvf/ 6/f+/8Xh/v88gfb/AB3s/wAI7v8AAvD/AADw/wAA7v8AAN3/AADO/wAAxv8AALz/AACy/wAAqP8A AJ7/AACU/wEBi/8EBIL/Cwt1/x0dav85OG//LzmB/5On0/95d3S2AAAAHAAAAAAAAAAAAAAACj8/ PX7Y1/H/lqju/5S19P/q9v7/8vv//6PN/P9OevX/FDr1/wAS9v8AB/b/AAL0/wEB5/8BAdT/AQHL /wAAwP8AALX/AQGr/wEBof8EBJj/CgqP/xkYhf8xMH3/QEBz/0NCbP9QW5H/usDX/09OTJQAAAAP AAAAAAAAAAAAAAADCgoISLa1xOrY3///qb31/9jj/P/r9v7/1e3+/6jI+/+Cnfr/Rm78/xU4/P8A GPf/AAvw/wgJ2/8ICM7/BwfE/wcHuf8JCa//DQ2m/xkZoP82Npj/OjqP/x0dhP88PJ//S0ui/29+ p//Cw8b4HR0cXwAAAAUAAAAAAAAAAAAAAAAAAAAie3t/t/Pz///J2Pr/09/7//b5/v/9////2ev+ /8LJ+/+nt/3/hKr+/2mN+/89Y/f/L0bq/z482P84OM//ODjH/0FBwv9YWMH/fHu+/0lMsv8HDLr/ AACe/x8flf+BgtP/rbDY/5CPicsDAwMvAAAAAQAAAAAAAAAAAAAAAAMDAhIhISF31NPi+/P4///X 4/z/8fT+///////1+///3uT9/9LP/P/AzPz/sc/8/6vM/P+jw/r/q730/7m57v+6uev/v7/q/8PC 4/9rcMn/P070/w4a6v8ABcP/AACY/zs6ov+ZmNr/Li4yjQYGBRgAAAAAAAAAAAAAAAAAAAAAAAAA GB8fSpZ/f9D/+Pj7//D1///n7f3/9ff+//H5/v/q7v3/4+H7/9Hf/P/S3/z/zt77/8Xg+//D4Pz/ zd/5/9rc9f/m5fb/oqXf/4OW7P+aq///QlH9/wAL4f8AA7r/AgOS/2Bgv/8sLF2kAAAAGwAAAAAA AAAAAAAAAAAAAAQBAQI/MzOa4A0OmP+foNj///////L1/v/v8v3/8fb+//L0/f/r7fz/2+/9/+Lt /P/s6vv/5+v7/+Ds/P/c7fz/3/D8/9vg9f+hs+//9Pr///n7///L0v//V2L4/wAH0/8AAKn/HByY /1BQqegAAAlJAAAABQAAAAAAAAAAAAAADxMTRYkXF6f/AACQ/xQbw/+2ufT///////j5/v/19/3/ +Pr+//f5/v/u+P7/7vf+//X1/f/29Pz/9vT8//b2/P//////jY7W/2B51/////////////L2///N 0///Y2vw/wQLxP8AAJP/LS2t/xwcUZYAAAASAAAAAAAAAAEAAAAmBwdzxgEClP8AA6T/BA/T/0BN 9//V2/3////+///////8/v///f////r+///4/f//+vz+//v7/v/8/P7/+/v9//Pz+v92dc3/AAes /5yt6f/7/////////+To//+wtf7/Tlbi/wEGrP8FBZP/FRV/0QAAAC0AAAABAAAABAAAB0IAAIfq AACR/woSu/9rcuz/tLv//8DR//+4yuv65OTl+P////////////////7////9//////7///39/v/g 4fb/1tf1/9DS9P+urer/xMf1/7zR6/nB0uv59vz///b3//+zt/f/MjnK/wABlf8DA4nwAAALSwAA AAMAAAAEAAAKRwABhe8SFqv/dnvn/9XY//+Rn/L7P1WXwxchNHhHR0V8oaGgxNzc3fD+/v7///// //////////////////v8///8/f///////+zs5vK3trDFWVhWfBwlNHROYI2+oq7u+djc//+QlfD/ Exew/wAAhvUAAAxOAAAAAwAAAAIAAAAjBARIqiYqmOlKT6XYJixvpwEFJGYAAAAnCAcGESMjIhYw MDAzRUVFW3R0dIiWlparqampwLe4uM25ubnNrq6swZycmq59fXyMVFRTWkNDQy4zMzMTDAwLEAAA ACUCBR5gIylpoUBFo9QaHpfpAABMswAAACoAAAACAAAAAAAAAAcAAAAcAAAANQAAAC4AAAAXAAAA CAAAAAIAAAAAAwMDABQUFAEeHh4HKioqDjMzMxk0NDQlNjY2Lzg3Ny83NzcmNjY2GjExMQ4oKCgG ISEhAAgICAAAAAAAAAAAAQAAAAcAAAAUAAAAKwAAADYAAAAgAAAACgAAAAEAAAAAAAAAAAAAAAEA AAACAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEBAQADQ0NABEREQAQEBAAERERABIS EgAQEBAABgYGAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAgAAAAEAAAAAAAAA AP/8P///wAP//wAA//4AAD/4AAAf8AAAD+AAAAfgAAAHwAAAA8AAAAOAAAABgAAAAYAAAAGAAAAB gAAAAAAAAAAAAAAAgAAAAIAAAAGAAAABgAAAAcAAAAHAAAADwAAAA4AAAAGAAAABAAAAAAAAAAAA AAAAAAAAAIDABwDH///j --Apple-Mail-6DA3E728-E493-4977-A102-760431E01515-- --Apple-Mail-A1AE1BD4-4863-4B1C-99F0-FD5C82D62183-- From nobody Wed Jan 10 23:49:46 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4T9Pfw5gFzz56Vvk for ; Wed, 10 Jan 2024 23:50:00 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic307-8.consmr.mail.gq1.yahoo.com (sonic307-8.consmr.mail.gq1.yahoo.com [98.137.64.32]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4T9Pfw2Hwdz4D2L for ; Wed, 10 Jan 2024 23:50:00 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1704930598; bh=g/NGeR277yVs8cusO9F6bUz/0IYPdoTJx118/y+X2nM=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=gQ7y1041xefbE0WaWW/7mMhLFlk4kE047xwydRWGB1ENevkI5lMB0CIV/SE9K5t/FZxRos3wiFUB4F46KlWFKjjZcCoRr/2E2v4Pjcenxeeeb2EMQcU0LcoFA8m2BOYFSjzizN8rwyop6VVjfmnEwL1/1ehJFSR3GTBBsPs/KJpTqSSKt1UqS8ski1H8qQmwopnkw6aNOI4Sdnoy8OjpflmV6zIEy8NLTYCRhLjQ2EJt1Dn4Y6Aq7JKlpLx4Npz5sGYW+8RU+VZZc3sNVm3hx9eyPec1BqkhXqrff1+wpbObcuF6zF4AGpTZmgnvGux/tbyudyC7NUXFHbVJLmxfKg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1704930598; bh=Kfi4RDN3YpY8ZZZMenA0ekw9LMe0odaaRvMIFOwBhyU=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=M80yOPNJ+yysfWjDkepRvHOKLFPkQsW8SFrAG2Tp5JNdVfHLla85bolR6oh11e5Ta2wxbey/TpiBw+VaojaEQajo7OlDumTTuQQhSXQGx5q6X7p51+36IvdzNFDeia/+SV7a2SL9uipS0vqm4V3CuHVHHTu7BaAeuCRNl27NvYlHfeDrPZ9qKJXw5Xw9pE0tvo+k4rk18CgLIknx4LWNy0fx2yX3navB1Ve8oW7zpHdv5AVeJEjYBb8iv+p+SIMIdITqvh/BcW/hm690wyYsTek7dkwHJJ7i5hZUIrXRz5BvZhMsPfRKyX8IExeSCOeZCHViHycLMpQNPBtEPNYSjA== X-YMail-OSG: tk_iqr0VM1mccNEJSzBMihF.nwuFd28Fy746E3_nmFRjtcdpFnhtHSmD2Pe8ncF M9afvQfxCBL2hLRA2A1fl9hd7tRnr2J9hR86lL0YbcRTi9kbFV1swS6sbE73vKTXzThmzewDffOx fwSpjSY8E7dqmgaQd7uhaX9fVnzZGju7MgSZNv7qHAcC9pU46YoTuAzXAI9CAWoXVb56WaZbbS1u JuZ8JWqLqZwbP8afO1mHt.jR8L2fAn3gb1DhHij52wjgYIXC9T_vV0PFy2lSarqwWPaDYbq8PnSw S8sRZyoP.r45Ksc5JVN43fvVxl.MA4F8E6c.9EYokNOa75DidF4fmm8f_mrhtDYIRatOW54MldHK 9pbmuZFxi62lt2BTfVX9musRxn1oZr52mC1UteD3woRxyTLISgoxOswwOdPgvCHoU2DBAun608ay _pE6NWdn9y3A.0i.4bxx3F03.A9bIR_eCw8fChpnFVrg4kYXfnsd49B1wLUxp1gHjiu64Iq_a7fX BiwcPH9n5S_N2F2Etu2KLAsfhxE3bHozu7ZtqIsySlAcwv8r.pkGokizSPJra40dac4sqL.1q1n5 cY1EtVVYve3mUtAZvzRy3YWAk0OwjEBsvXWUYXZ3sqEjyzJYi4Qu90TmzcvfGicgMWR7tWpSFsy9 vWC3P8UOY_7GXmNl.yYFl1ELt2s0NSUtjibcasYpVf7nbLyPPwmfuCI0YgAeTElD0hbXwT2k7seB M7CNo2Pf252ZMuyJHSELdIXgOOS0.r6P_QKVQkMcmHrMig.uoSF3XAwyAjYcSYUffGjIuZKHNOLY _mRjG5wbsEmV7IFUF7GcTrxYOdnRLJDv9_TMAyYFD9HNAbsOsh2ItMrYjX8DPto0cwP.IiTo5YyW hhQNbLsgLXuY5pFhoL1zN05OPpo.GVX44V5n.AT3dopqaG2dWtheGigfRkAwJOSm7Df144IQ9c2X DTqzAlJ8HaTWuhle3f7qP2lNN3RJ5tX9dOLoCJnwT_oVvzDneIUHpDu5KhKDOHsXBd_Q3fcjLbVF oRYAjtdAAzAsStohP9DGRRn7NywR_PMXHE9q45et959LfdcEBttWK0OypLwIc35dB7XBAefiLM5T wBxt7hjmkqeCIppM.W.0gWldktsq8WLm6qSK6c9XeZziB6H0W7vNOk_dzOZbZgQQug1bDpRLpueb hdk1ouS5a0xnNrwxLN0fqoC7wz7aeBGOFexBPB6tfPzOEfz_5E_vXuuVKylagdrah49fnCDmjxRU XY0tg5lnvIiF.YABSaHuRKrum3u941zBwK16l03OB67HSe9gRW_LUwhMefzgeLFmPWV5L_osziEa 1tMip7Qi2hAPA3WseHhhRiWcTBESbBwtbzK_fWWl7uwkqTE7gpuPMZSxchk3XbYr_D2.IqBg1J9j FlzETYy921VId1kTkTEV_Y6urvYEOmhA8epw52Ayxs5v6fHCqEk3rN7ycSlvU9ldk5DVqiNsFDs4 LhyyhNDbYVIUOnBRf07Py4gTEqIbErPlZOMqrPIbXGqJtPZIZymPAGQmi3zmzM8vFMmucCG2wz62 LeRQwyhP2wCvG8w2Kw3CwSfWJTty7emFOpkItgQLMSDyKny12l6Xc_.XurrWZForamNNUHTrlRtj A4M4Q5ekgR4zl8Uci0eqiTUJEnkA5rOM.X_tTP31k4h1YDyCELi3b_wksvMqJhIiNbeYW9Iwon3l Jf0jBzEOfaAjInhFlXBt7aVhpFiuzycA9XyPTMv9T7l9Fq9P061SVz5gaP.9AtrnfdGPr3uX8r1c Eh0Xm.Mt932UPX9Xq9Jb8nEDcrr1SHc6n7U2tJpaWdIpLL9JeZsWhlN5S6geiaeBBJk7uN3dUngX 79ahffUMqC4xXJIw37bsf0DXHqgpnr9nKFbq2iUFtcdzRuPowAN1d58Fb3.FZd4hye1vJSxZ_tc4 aQNcVPzyYTNfVYQ5sSZkxvJX0lvwaji5sZcy2a5U97esaLrmPCqFvftwZ7GsrUSOGkmeTqTgmtHv 1GhO0P9fscsibhx4mJFTMZxldbSrkjYC.zlyDkAzj0zX3Lp2b8nLkGBVX0xSKk_pd2XD9KE8P8tA _YhewrP24nT68iFZ7wb8FqIb.uOkNblQCm8WShPREhzl_NM7wAGRfhuir_KL5nBEkUPuaSEBEGxU w2X5YpEH7OGpNl.hEcin1ZlrliFZQuEnq5gE8Q17ymj6an0knH2Gyup6FnqsL4Utc0veLRlDkCKN 0FKlJEHzd7bvlaAq67NnO_ypKrDismFj4eRqjpIhyFCU_0U5sooUg5pFX8DDSFzxWCo4CKuBJWg- - X-Sonic-MF: X-Sonic-ID: 8c3f87b4-5189-493a-b434-158c88a807bd Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.gq1.yahoo.com with HTTP; Wed, 10 Jan 2024 23:49:58 +0000 Received: by hermes--production-gq1-78d49cd6df-t49qq (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 7699169bacc875f5783725a1e9950f73; Wed, 10 Jan 2024 23:49:57 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.300.61.1.2\)) Subject: Re: current for arm64 tries tftp first for some reason From: Mark Millard In-Reply-To: Date: Wed, 10 Jan 2024 15:49:46 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <5800841F-E8D7-4C82-8B93-FA61E5E37D69@yahoo.com> References: <856D59CC-E55C-4667-97EE-458104C8DFEE@yahoo.com> To: void X-Mailer: Apple Mail (2.3774.300.61.1.2) X-Rspamd-Queue-Id: 4T9Pfw2Hwdz4D2L X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] On Jan 10, 2024, at 15:02, void wrote: > On Wed, Jan 10, 2024 at 05:07:14AM -0800, Mark Millard wrote: >>=20 >> The file is not a text file and I've no clue if any >> EFI variables happen to be related. >=20 > My rpi4b context doesn't create /boot/efi/ubootefi.var > if the tftp part is allowed to complete. This might be because I have a GPT partitioning. I tend to do things like use a Rock64 snapshot dd'd ot media and copy over the msdosfs materials from a rpi-arm64 snapshot. Similarly, what I partition and set up for myself is normally GPT based. The file was not present until after the first boot, which I did not interrupt. Evidence is the lack of a reasonable timestamp. I've just stopped it to get to a U-Boot> prompt and used the eficonfig command. It displays a menu that includes "Change Boot Order", for example. But, so far, I've not found a way to change from "Add Boot Option". > The OS was installed with dd to spinning rust and the ufs2 filesystem = as one partition auto-expanded to fill the disk. I actually set up my USB3 media to boot most of the aarch64 systems that I have access to. I move the media around between the systems. No spinning rust. This means that when I updated pre-existing media with the newer U-Boot is when I got the new behavior on teh first boot with the newer U-Boot. > Maybe this installation method doesn't create it. >=20 > Previously I've booted to mmcsd, plugged in the usb3 disk, > created a 256MB msdos partition, copied all of the msdos part of the > mmcsd into that partition, ran bsdinstall with the plugged in disk > as the target. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Wed Jan 10 23:55:45 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4T9PnY1SHNz56WRr for ; Wed, 10 Jan 2024 23:55:45 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (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 "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4T9PnX4249z4DZn for ; Wed, 10 Jan 2024 23:55:44 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Authentication-Results: mx1.freebsd.org; none Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.17.1/8.15.2) with ESMTPS id 40ANtjM3006039 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 10 Jan 2024 15:55:46 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.17.1/8.15.2/Submit) id 40ANtjuK006038; Wed, 10 Jan 2024 15:55:45 -0800 (PST) (envelope-from fbsd) Date: Wed, 10 Jan 2024 15:55:45 -0800 From: bob prohaska To: Mark Millard Cc: freebsd-arm@freebsd.org Subject: Re: USB-serial adapter suggestions needed Message-ID: References: <7D27DF9F-AA9A-4D44-BC28-8CC637D0F550@yahoo.com> <3012A549-9482-4D69-9DF4-7987E650DFFA@yahoo.com> <55AC6824-587D-4C67-B64B-2045A1112F69@yahoo.com> List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55AC6824-587D-4C67-B64B-2045A1112F69@yahoo.com> X-Rspamd-Queue-Id: 4T9PnX4249z4DZn X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US] On Wed, Jan 10, 2024 at 11:30:28AM -0800, Mark Millard wrote: > On Jan 10, 2024, at 11:21, Mark Millard wrote: > > > On Jan 10, 2024, at 10:16, bob prohaska wrote: > > > >> On Tue, Jan 09, 2024 at 05:03:42PM -0800, Mark Millard wrote: > >>> On Jan 9, 2024, at 14:47, bob prohaska wrote: > >>> > >> [transcript of ssh-tip disconnect omitted] > >>> > >>> Interesting. > >>> > >>> www.zefox.org is the aarch64 that is not configured in config.txt > >>> in the normal aarch64 manor. As I've requested before, please test > >>> using a config.txt that instead has: > >>> > >>> QUOTE > >>> [all] > >>> arm_64bit=1 > >>> dtparam=audio=on,i2c_arm=on,spi=on > >>> dtoverlay=mmc > >>> dtoverlay=disable-bt > >>> device_tree_address=0x4000 > >>> kernel=u-boot.bin > >>> > >>> [pi4] > >>> hdmi_safe=1 > >>> armstub=armstub8-gic.bin > >>> > >>> # Local addition: > >>> [all] > >>> force_mac_address=b8:27:eb:71:46:4f > >>> END QUOTE > >>> > >>> Please do not use a configuration based in part on armv7 FreeBSD > >>> config.txt material any more for the testing activity: Just use > >>> the FreeBSD normal aarch64 configuration with the force_mac_address > >>> related material added at the end. > >>> > >>> I want to know if this also fails when powerd is not in > >>> use anywhere. > >>> > >> > >> I'd like to let the the present OS build/install cycle complete. > >> Then I'll replace config.txt on www.zefox.org and reboot. > >> That should be done in another day or two. The remote console > >> disconnect reported above hasn't happened again, all consoles > >> have stayed connected and responsive. > >> > >> > >>> [I assume that the "The Pi4 workstation" is the "pi4 RasPiOS > >>> workstation". True? Presuming yes: Is the RasPiOS the 64 bit > >>> variation? (Just my curiosity.)] > >>> > >> Yes. Uname -a reports > >> Linux raspberrypi 6.1.21-v8+ #1642 SMP PREEMPT Mon Apr 3 17:24:16 > >> BST 2023 aarch64 GNU/Linux > >> > >>> Do you run the buildworld on www.zefox.org and such via the > >>> tip session on pelorus.zefox.org ? Via an ssh session from the > >>> "pi4 RasPiOS workstation" to www.zefox.org ? More generally: > >>> > >>> A) What runs (if anything) via the tip session started from > >>> pelorus.zefox.org ? > >>> > >>> B) What runs (if anything) via the ssh session connected to > >>> www.zefox.org ? > >>> > >> > >> In general the tip session is used only for observation or > >> troubleshooting. Ssh connections are used for other activity, > >> including OS build/install cycles, poudriere, etc. They are > >> usually placed in the background, writing to log files so that > >> accidental disconnects from the workstation don't stop them. > > > > Are you using: > > > > NAME > > nohup ??? invoke a utility immune to hangups > > The OS build commands end with &, which I gather does nohup among other things (not sure what). > > That only ssh sessions that in turn run tip fail suggests that the > > tip session gets the initial problem and then things propagate. I > > want more than a suggestion. For example: direct tip runs that > > are not in any ssh session: still get some form of failures? > As it happens, the tip connection between nemesis.zefox.com (terminal server) and ns2.zefox.net (console host) dropped. The display reported: login: Jan 10 09:42:46 ns2 sshd[48003]: error: Fssh_kex_exchange_identification: Connection closed by remote host Jan 10 10:51:54 ns2 sshd[48135]: error: PAM: Authentication error for illegal user shell from 185.11.61.234 Jan 10 10:53:03 ns2 sshd[48138]: error: Fssh_kex_exchange_identification: Connection closed by remote host Jan 10 10:55:47 ns2 sshd[48152]: error: Fssh_kex_exchange_identification: Connection closed by remote host Jan 10 11:22:26 ns2 sshd[48203]: error: PAM: Authentication error for illegal user test from 85.209.11.226 Jan 10 12:24:21 ns2 sshd[48300]: error: Fssh_kex_exchange_identification: Connection closed by remote host Jan 10 13:12:06 ns2 sshd[48380]: error: Fssh_kex_exchange_identification: Connection closed by remote host Jan 10 13:14:06 ns2 sshd[48381]: fatal: Timeout before authentication for 59.56.110.106 port 50300 Jan 10 13:34:34 ns2 sshd[926]: error: beginning MaxStartups throttling Jan 10 14:12:41 ns2 sshd[48506]: error: PAM: Authentication error for illegal user shutdown from 185.11.61.234 FreeBSD/arm (ns2.zefox.net) (ttyu0) login: client_loop: send disconnect: Broken pipe bob@raspberrypi:~ $ Interestingly, there's a MaxStartups warning. I discovered the failure somewhat before 15:17 hours. The link had been up for a couple of days IIRC. I logged in on nemsis.zefox.com's hdmi console and usb keyboard (the only Pi in my collection set up for video console logins), opened x11, started an xterm, su'd to root and ran tip to connect to ns2.zefox.net. The connection was normal, no problem with needing to power-cycle the usb-serial adapter using usbconfig; tip connected and displayed a brief string of mixed printable and non-printing characters, ending with a login prompt on the same line. Next came two reports from ns2 of "... kex protocol error...." > > Specifies the maximum number of concurrent unauthenticated > > connections to the SSH daemon. Additional connections will be > > dropped until authentication succeeds or the LoginGraceTime > > expires for a connection. The default is 10:30:100. > > > > Alternatively, random early drop can be enabled by specifying the > > three colon separated values start:rate:full (e.g. "10:30:60"). > > sshd(8) will refuse connection attempts with a probability of > > rate/100 (30%) if there are currently start (10) unauthenticated > > connections. The probability increases linearly and all > > connection attempts are refused if the number of unauthenticated > > connections reaches full (60). If sshd mixed up new with existing sessions it might kill one running tip, but it'd likely kill others from time to time. So far that hasn't happend, at least not often. > > > > It does suggest that testing isolated from the source(s) of > > unauthenticated sessions could be worth while in case handling > > the load from such sessions when already heavily loaded with > > buildworld/builkernel or the like leads to other problems (and > > denial of service consequences?). > > > > I do not expect that this issue is all that likely but > > expectations are not evidence of their own accuracy/inaccuracy. It's my (very) subjective impression the ssh/tip problems are more frequent when ssh attacks are more abundant. Nemesis.zefox.com is public and sees a certain amount of doorknocking but for some reason considerably less than www.zefox.org. As an aside, during some stages of testing with pelorus.zefox.org the host was on the LAN and so not subject to attack. It certainly didn't prevent failure of tip sessions. Now pelorus.zefox.org is on a public IP and seeing at least sporadic doorknocking. Thanks for reading! bob prohaska From nobody Thu Jan 11 00:06:54 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4T9Q2l0wJkz56Xqt for ; Thu, 11 Jan 2024 00:07:11 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic307-8.consmr.mail.gq1.yahoo.com (sonic307-8.consmr.mail.gq1.yahoo.com [98.137.64.32]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4T9Q2k35Hkz4FxX for ; Thu, 11 Jan 2024 00:07:10 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=haz6nANq; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.32 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1704931628; bh=3FQJgP2uYUsGuEqVswnGqNiq2p6ItiYrdnVE0Mk864g=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=haz6nANqAJUr16Wy2MZ0/nF0CLrBdVtW+Ozpcj0XMiQu1bF8CfQg96sXLSiA4RQ13KrRS7UiObCgdHrmu5ZUUtcARhiIvvAGhyq1qnNCEvQDi+lhMGb6VcXwfMeFXhhK5OvdyY878MQj5LDeejHFzH0pfeoRjFHCrHj18PueKbB+D5XCYv0R4kP6/rDf2/QoiZS5j1TC+gr785SFV4zaTKUzLL1QalVG5MGJdhuAYb1mKpOMci0EECWvAj1+gxeXzBTE+ScQdWn1eTLf6NaNuwOCAvme5Efxv2m2FPAVN1Uy8H60UNQ7wu7QDGPZgfmkWUaqSwZfFVYiNJ4NZghK6g== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1704931628; bh=KBSP4fP8ys1GVr+tJIo40rXHld3ZM2JAGdOdalckn/A=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=sI0XHkcNgbSKzwIUugr2cUeC1tMmuVaYePC+1aX+PnyWuhzq2tLyBUcFBpNQVpP86D0IxfezOIv7Vx2x4QF5TmSloiy227Udp0XqBmmw+k5g0sOHYBLLsi/gM3CsCGAJcqa3yOESQ+x1AaOqWTWOqxaCwEse9bNN77ygGR1/vUS0IPdCAYcJERajqvEoGE7hsuv9EF7sCQxQBNU2n3M1dHc9YVpHF6sLqg4cwqf2pt6fPpYma7/W+C5eusBDnGlP6v/QxPiywnBrHu04s8HojplHz1xCThOLeXikpGrsX15sxMH1s4cxW2q4t+0tl4wOGVsFTAJO64LA6Q8IInVNLw== X-YMail-OSG: 1F2D7gIVM1n4xejDG7_nE0xq1hWlg1hnCb5f.Z3GGge7.ysEmnt6T11xLqdHXrg lzmG39GjpanBnoK4jo184hpIddTs.2NwEKT5NQJiOc3l5LA_4CyGwxXL77mJFRR78CQEjGgVbKlZ G7EExN2l9WzOqtzuC59gr6Vxxz8atnYbf0TQPKIZhuOSG.j8ZbFKvvq.LlLj00O_qSvA.NTVGvOt 0NBAPRxm.IkIINj4J6SiUMi6zFv5OkxaygD3.5IeQ8S1tUuc.7EJEeyKfHfMevz2xYkyoqLBWHkh CsXXePW7sVQCMpgUC4AwYHJysX_M0HdKtMTi1XtnToT.yjTCO1Z4hPe.reWvugMJDasuX2Fl1hjh ZNjs0F.Mwl1IdifqFNv0aNCtuM4C96Ngl2htwVI5qnQM7Wr63rvhi_5e4kJROCYeABpQd2eqqI3t 0O0Ym90Pe4bCrdHjSfbGpJ5Y3ZCPaolehci9JrT47bEspK4dvqjMml9EaKCW3.QEv_hnC81QPrds 55f6D.S9xxAnh5N6cIpcb1sRTtTClfhdV0sdSHxyvAK42a0rRZAYmS_L3s6dP2syr6nZkXQxJV0K HkD4qLdc7JT78pu7YUYZh5ingcm2zMZc4sTl6kotrtuJzLDfXnMUsxQb6Z7RCo0RwZ48k7rGgnCB qPqySUTW0gbqQoDeQE1r1qSi8q7mjfG.cv4d4.i8arR._XAUwS1K_hFMGz0glJmn4PlOrZUd01Bv k_V_X4laDx2HCgmW0mJhxx8vaYyXWet.yvuYiWBLjAtlDeP2QdKyL.b2ny3HmOvmPVehkddcLwmk pAA.Etf9mZI2ZmiDaV7cm61Rg9BnQzhOQuih1B0Qw6ugnhKm_9.SJzVNAIu36dRl0XJ9P7G2FqBx p5FN32LxY5gzUEAFiM6vtX6tGXioKcn7XxRNnNIFKIDKFcB9iYhBR3CqJRTId4Y3SxyllqzJb85_ pSDVM5h3I3aLbAnAZXvTRuxns_SPImxfskNPd2CkIt5jv9VwJC5Mc33sQlwfMbukzl2bOkPz0XJ2 nacg8lZYY3EKoJ.UITBQrSkMeUoDlZG0NCVRTrLZhvznxNZNllIC5C78Mi_TqUATGTuW28n7wepM H2zdMllRkvTuaIErGgZWQkQNvwqRx8WtP7gC70Zyo8cQj9oUHwzePQ_Fj2sf4S7M8E2yCTiiku00 WYe08Zu2ZEqnbBDAUALufKOPJIgoc1ZfcxJXo_V_LCLsQgiIkq1VbWWJ9ufRpxlzKuA0Lwt95Fs0 4EV1lpQ76KyZixSSPHSB3D1WYb1o6vx66f9_.f0ok6ZgrKP1a3DtRsi4sv5s7U.AdRBVRFnjV5pY EhFYTVtf3i4yc34DApdLJKmP5E.TSYdUArkDJ.rml1K3vbd8DvRTl1V7HeFfPgKaq_XVlZvNphLP 1uBJtM93N6VYN1X0fhvfi6sxVIPb46XlKU69XeHCalkxApa0xyFKfGp7k1kmLO4MfDsn.DPHHobZ nrt0tAbCtU0.jI2WYZIxmgTmfZjVJ2B7Qr2Y7piy0qIjGYlBCLU39TSNCHKbCyeqSZfdo6L5YuF0 ewhz1kr21AtTtqh33PU2221M3NsYHq3D04_t.k5kiMVe9u9z216gfAD_aRzle4W0AEPk.N9c9qa4 UiuN.Ceb6KDvBh47Zz45SZ9m3_y47D8IVSbn.WwNIC8UGlFuwGMwlhzTtwSWoC4jy0QDs2K2vkqB RXsiv8890U1WHkxJVARpwrMjD4NMrAweF.hSrWOe8S3YIQ1m59.I_RK6d8cOlJk.JuFJ_c.qXHBb uUponjg7x82Nvvwdko2eBQe8ne_UdnhOtgbEeQ1UUYS81w4Wr9JaaXJ8cVdr6rZRiV2qXdxhepOM 9qkVNQsb.g7yD0846tG4CAiwGZjyV8jP4Ag3IPjuneMssbtpSiYtkYzXZPpPxfmkpqvL_hUl2joF n4Ssv1W5UOaiaiqmI4JkOAZDCkmM6zrCNoP0Of5X_LY1rcJjSPa_XrmXQ63EeJqwgX2dHxyC_U7A g0L5VPW9oYRRWXNOTscpiJTlbXVfDh19Ymgc7SkmkIfzMNVorNvynrNKKxXzosIlzVPyNzr595rl QqR4jiHEwccZdg6srTnFMVzANYN.waFRUdc5V9rJvuoTehLUQxj9Uzd37WDRiquPHX4PnGAvBO4B QrDp9wS.x6KlMmMrUJlONgME.W5RP_AXUFW2KcDwko_Lj0_UeqDh7oLNbcQDsxMd.YThwSCl2oSX VXVfypr3Osn0BST2Ixx3kTiXZYe5wKmNU7y45HCODBAfdJyAQ1vq2TcKDFKMx4.mVValP5QyBNA- - X-Sonic-MF: X-Sonic-ID: 0afee61b-45fa-4874-8ee5-08bfb2292197 Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.gq1.yahoo.com with HTTP; Thu, 11 Jan 2024 00:07:08 +0000 Received: by hermes--production-gq1-78d49cd6df-7zwgw (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 639aa4f45207c0025431f11e9bf25742; Thu, 11 Jan 2024 00:07:05 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.300.61.1.2\)) Subject: Re: current for arm64 tries tftp first for some reason From: Mark Millard In-Reply-To: <5800841F-E8D7-4C82-8B93-FA61E5E37D69@yahoo.com> Date: Wed, 10 Jan 2024 16:06:54 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <856D59CC-E55C-4667-97EE-458104C8DFEE@yahoo.com> <5800841F-E8D7-4C82-8B93-FA61E5E37D69@yahoo.com> To: void X-Mailer: Apple Mail (2.3774.300.61.1.2) X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.50 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_TO(0.00)[f-m.fm]; RCPT_COUNT_TWO(0.00)[2]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; TO_DN_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.32:from]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.32:from] X-Rspamd-Queue-Id: 4T9Q2k35Hkz4FxX On Jan 10, 2024, at 15:49, Mark Millard wrote: > On Jan 10, 2024, at 15:02, void wrote: >=20 >> On Wed, Jan 10, 2024 at 05:07:14AM -0800, Mark Millard wrote: >>>=20 >>> The file is not a text file and I've no clue if any >>> EFI variables happen to be related. >>=20 >> My rpi4b context doesn't create /boot/efi/ubootefi.var >> if the tftp part is allowed to complete. >=20 > This might be because I have a GPT partitioning. I tend > to do things like use a Rock64 snapshot dd'd ot media > and copy over the msdosfs materials from a rpi-arm64 > snapshot. Similarly, what I partition and set up for > myself is normally GPT based. >=20 > The file was not present until after the first boot, > which I did not interrupt. Evidence is the lack of a > reasonable timestamp. >=20 > I've just stopped it to get to a U-Boot> prompt and > used the eficonfig command. It displays a menu > that includes "Change Boot Order", for example. >=20 > But, so far, I've not found a way to change from > "Add Boot Option". Well, using the following command at the command prompt: U-Boot> bootefi bootmgr avoided the tftp sequence. FYI: I've still not managed to select "Change Boot Order" in the eficonfig menu. >> The OS was installed with dd to spinning rust and the ufs2 filesystem = as one partition auto-expanded to fill the disk. >=20 > I actually set up my USB3 media to boot most of the > aarch64 systems that I have access to. I move the > media around between the systems. No spinning rust. >=20 > This means that when I updated pre-existing media > with the newer U-Boot is when I got the new behavior > on teh first boot with the newer U-Boot. >=20 >> Maybe this installation method doesn't create it. >>=20 >> Previously I've booted to mmcsd, plugged in the usb3 disk, >> created a 256MB msdos partition, copied all of the msdos part of the >> mmcsd into that partition, ran bsdinstall with the plugged in disk >> as the target. =3D=3D=3D Mark Millard marklmi at yahoo.com =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Thu Jan 11 01:30:08 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4T9Rtn0dc2z56hvV for ; Thu, 11 Jan 2024 01:30:25 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic309-22.consmr.mail.gq1.yahoo.com (sonic309-22.consmr.mail.gq1.yahoo.com [98.137.65.148]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4T9Rtm4q2Bz4VMl for ; Thu, 11 Jan 2024 01:30:24 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1704936622; bh=xHweX6xs9/fPo7B6PLYAkkTQEBj/KxPZbVpnmT7N0XA=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=M84exFc5XvRdTaoEioHwxHk1VSKSdKf0IwSa3el/zQzQXDgqfPljqWqfk6XZpnkYnIkRGknsmhFwWxj8yVUfk8OItK/4iMcdT1j2dNnzgpas6znkG82LZ/9n6fG1zf4pjBsPnCFv2RVfCI4VAaF0FgBUeWzUiz3tF2j8SA0pXxTOnp9TxRKFmaHrCyynaLUPvQGTt5iN8QpJVbzl9Ti3qJkLUTRHoYaR9GxDVv58n2tm9xNkyGchI2td27+LFFfCsqFFiFtNDIEQ0TOn4UYZ+/EVqR0J/xOdFErRuGcC8b4lujomAd7yy9GI0oef0PiQgLSilLqvEZpIAu/Ck+zrdQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1704936622; bh=0EFKEuVhvNscgoqjeDgYMxYVFpPFzHyRCaDP7w9ADch=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=nm3y7cMBGMCqrk6dg77IdBaiupLolFHrWbEZi46+wRjHzRHlP8PVSY979l0wJSQyhIa7wy6UQfjaMQAZdc0JG5Yy9KtediabKxY5cHi1yjBzhqbGaemzyHZZ8MijnEYYK1Jso7GxUDwWO8lgkPpxwB/EqEkOql3xK5K09ptD+y6gLL3CgMh8u1Odr4+yjepZB4OfJkaXqh9ZGRCaO4MMYQTM/a981YmeQ6t7kgo7mSzabRSlSAgnHPwDbjEkkx8Mw48Ii34r1uhkfTrZlslXF+5IB0dMK0pYOcQ8MPgvofGwMIh5Pys0ZoIPetD0PSkeGQJaHAFHQXOSUfnZsOsi+A== X-YMail-OSG: 2.gIONgVM1m8f9ymRmzxCpGeXwQS2.96CAKAYyuLqKfxYZlvhKFjcFWYtRp3ZuU ZqtAHqwkIHY98qu5L5t6DFo63HOx75hwZlRFKFw04F7kmEDCtn96Gm64elqpxIdp32Ri3nj37Ar5 lqGCUB707Q.z75srL5kOeHs.h4RgDnTb4UgjZS6DPR.Hr1dVXpeR4GdpKMk8wf4CMTLj3G_XhrWo UAygMoTJBW4yeAHVB1yWgBTP9gzI.tMlsnUrfu0DQD_Cc5.UBRn5I1mOl.3IPWlqdK0.JTdzDTt4 dIAnVx7Lwp0nK0ku9mDyAbaLMruChbeJmBzFZ25YbuvlCRyPkUom3Ar5.jHowy2bZhsr_LP4f94O WiNkJ0LkbVYqBJi0ZMz3RgnZDpVlBpC8f9qyDOD5aphNvyUw.VKhGZstmUU_5z0qfujRQ767Nc46 oVIMIBhl8.zio.he5HgP_tqKO3uHsIZ6y7Oeyd.Bs.1NDG3BNEuc29OtOD_ekmMLOys5ox5WfuRz L6OoUUS6PsZv6k9W.6_8hLp6YIXc8tr_aq9ynnUHReRE8AtF8H8zDjC__Q7c38XUFEXOwR0Se2nI 130rUv2JPUscLHPe.UapG_0lyFSzQOBN9d5AsdTBUu1nmLIutX0pvWYQs701zYVxJIjvoo3rR89y 55GHTyKTQAVUC5E.I2g9If_S.u1zzU.7ys1ZMlF6x1SKYD23ADsoJPzaIaXMPx2giQa96sPqUSjf 2lNNqSmT9p0Vg45a1_RXpxewhjTNbIvgVF44sQkkmoUGdBW8SguS4AMmSGCCt4mb8yFxCWsSuYOg i3ZgNcBfG9wCuI1iXAW3ANNx.czCjdkFMgLWdiAm95RVEKGrp8bDzPO_aE8W03gnGNWF.h6UStOn hKnf6xuQV4RKZFDbqD8LP3bO2mYyYUD6uqPAfCDEppATGMSGKera0Z2TnMywnYprZWJQ9Pst_rQ6 w49hnVmNwbw3KMgMQYHVAo4ghOJo61pwkPExxy_H8BOcgheFKAjTWxGoZRTCg1ozZ44V8E4HE5ta fSvVozKTNl2p8R9T2sCi0iLNOZx5_XUevEU14YIi_P.ko9Z8cDjImIJCzZGI2KGXrIts7jWpleKW 1r9gTw.BNIV.evb0xqdQ0R87hagyL.CYKfNuQkyH3RFaLc3_OhJAzH1GHd96K1GLgk5tdGwsP6I7 k1EB6WUBbbJMzP53S3SgfG32TUd_mdBDPyNySBDsAGjrsqlG0z7PJuyIwYBuT.Arg76xLrpS.UOG OKYssNStakbgoDD.e_ywMC9sKjEKPpkYnoMHKN9IdGHDZuLx82GCNkm7A62ZhsGcsNOmm.3uMTNd 3lwlPjPZOE.NNk5qFjz4p0i.BfOeYjJS6YtJeiFsMaviquNuyhU31DFLRU.AJ61tCXoAD5jTgtN5 bcFtUReaHz3z7utQ1.tRD5WVGGJbrC9FA1T0HUr3pEzTKltdqTKW9z8neb9p2XlcPlZDywvQxpXk T6YuF7ddSVB.yTZA5.J0GaGBVvB7KVI0X1x5HBJFcqtupV8MBunWdbTT3zhEaJ6N6Dal9pyqjaim UP8Rz2P6sUJm4FKsdZT3HwmSc9tlCEpdk.sKH9oiwF9pWMCIVGkzwWalRQk5iyihYEBe2xac9mLg Bt.MnrvbpdK5bXbhd7JJDWo9Oz5X76WS3coSuWW_OyELgoYnlJsdSJ05xxJ.yqMfpgCIcRlPfTnR HNtVBuUHVQiNbz5nkqm5Xr58kkYdvculBJqp6fQ7BzbMEEQzwKCKKvJ9PyLfrEWGAmjlcus6R2YK hN29iZmJGkJkxT93jv0ZnLI8EvdB2Wvq.PTNxBGj_Gs5Zv.elZX0DhPc54Gnl9s3VWp_w3_QmuUK F4X75mhEEFL8XNTxHtneYW7E6GqE86JaVjU7RZwE3W7gqca.rLE5vbQfWZRfgMPqtVswyftaZlqy 5k_VspnRUpeCcqWE6RyYedvMDBxcvEcs9Y561aTKWxnMIhR_qz.wiiL_wMnGbB8yDCeqX1Pd5fao duptwkyUvPR0QaTKKVazHmtFgFlyLUw6sO0TgmvwdHI2YJ27iE1OWzaG3RllJnJjs.o9kzYjuzg4 Pf7ijViwfWCPAqJejSUdEZ8xbuKNRMdZHxmbtgCvdpGfKsiCrgKulB4iVw1WeJal07LzIdZMgnd2 bdw.mJdjwcd.Joi9tH7KJpthH_SNKVA_bpNzk5ryTlk_H634ll8ikadrBkFVnViriAh7wHs9I0R5 6uTLdGepaGUQqzg809k0omjulHQUJH0fS0C2y0w4KhMlGcPl5DvsNlfeu5kmobbcEcAEALx9A_B4 9YQ-- X-Sonic-MF: X-Sonic-ID: 8f623dc7-ea07-468d-900e-95122854ab1e Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Thu, 11 Jan 2024 01:30:22 +0000 Received: by hermes--production-gq1-78d49cd6df-hlpbq (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID de56ffec38b6ac5d4e70bdb42e99f1fa; Thu, 11 Jan 2024 01:30:19 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.300.61.1.2\)) Subject: Re: When will FreeBSD support RPI5? From: Mark Millard In-Reply-To: Date: Wed, 10 Jan 2024 17:30:08 -0800 Cc: Jesper Schmitz Mouridsen , John Kennedy , ykla , FreeBSD ARM List Content-Transfer-Encoding: quoted-printable Message-Id: References: <5a39810c-5fd8-4969-a222-2561b050b035@FreeBSD.org> To: Doug Rabson X-Mailer: Apple Mail (2.3774.300.61.1.2) X-Rspamd-Queue-Id: 4T9Rtm4q2Bz4VMl X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] On Jan 10, 2024, at 07:45, Doug Rabson wrote: > I was able to boot FreeBSD-14.0 on an rpi5 using EDK2 from = https://github.com/worproject/rpi5-uefi. I put the EDK2 firmware on an = SD card and an aarch64 memstick image on a USB thumb drive and was able = to boot all the way into the installer. PCI express is missing as well = as ethernet but it's a really promising start. Same sort of thing here . . . I normally use USB3 media set up to boot nearly all the aarch64 systems that I have access to, including the RPi* ones. So I did (da3 for the microsd card was already in present for this): # fetch = https://github.com/worproject/rpi5-uefi/releases/download/v0.2/RPi5_UEFI_R= elease_v0.2.zip # mkdir RPi5_UEFI_materials # cd RPi5_UEFI_materials/ # unzip ../RPi5_UEFI_Release_v0.2.zip # gpart destroy -F da3 # gpart create -s gpt /dev/da3 # gpart add -t efi -a1m -lRPi5-edk2 /dev/da3 # newfs_msdos /dev/da3p1 # mount -onoatime -tmsdosfs /dev/da3p1 /mnt # cp -aRx ./ /mnt/ # umount /mnt I put the microsd card in the RPi5's slot, connected an example boot media, connected the serial console cabling and connected that to a system, connected a USB3 Ethernet dongle and Ethernet connection to it, and tried to boot. It worked just fine, logging in on the serial console and over ssh. The other example USB3 media that I've tried also work. These are main [so: 15] personal builds. I've not done any testing, yet, for problems FreeBSD has for RPi4B UEFI/ACPI (EDK2) based use to see if they happen with FreeBSD snapshot builds for the RPi5. (While I normally use FreeBSD's U-Boot type of context, My builds do have patches to allow RPi4B EDK2 use to avoid the problems that I know to test for.) I do not normally use the video and I've not tested it, but it is documented as having support. FYI: # mount -onoatime -tmsdosfs /dev/mmcsd0p1 /mnt # ls -Tloa /mnt/ total 2148 drwxr-xr-x 1 root wheel - 32768 Dec 31 16:00:00 1979 . drwxr-xr-x 49 root wheel uarch 1536 Jan 5 10:29:46 2024 .. -rwxr-xr-x 1 root wheel uarch 2031616 Jan 5 10:29:34 2024 RPI_EFI.fd -rwxr-xr-x 1 root wheel uarch 76038 Jan 5 10:21:50 2024 = bcm2712-rpi-5-b.dtb -rwxr-xr-x 1 root wheel uarch 388 Jan 5 10:18:24 2024 config.txt # more /mnt/config.txt armstub=3DRPI_EFI.fd device_tree_address=3D0x1f0000 device_tree_end=3D0x210000 # Leave RP1 PCIe configured on hand-off. pciex4_reset=3D0 # Force 32 bpp framebuffer allocation. framebuffer_depth=3D32 # Disable compensation for displays with overscan. disable_overscan=3D1 # Force maximum USB power regardless of the power supply. usb_max_current_enable=3D1 # Force maximum CPU speed. force_turbo=3D1 (No adjustments made.) =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Thu Jan 11 05:34:00 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4T9YJ80Jlzz56Vk3 for ; Thu, 11 Jan 2024 05:34:16 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic315-8.consmr.mail.gq1.yahoo.com (sonic315-8.consmr.mail.gq1.yahoo.com [98.137.65.32]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4T9YJ72gVqz47Yn for ; Thu, 11 Jan 2024 05:34:15 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1704951253; bh=TGeK0jGvK+KQXQfIO2IBxRtIWjA4mN8BhaUafIMYRyw=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=ia+xrw9lu13u2aR7cLdbPBZAeF/WYm51vBmV3I5wd8ag8Vpc0e/1GSju4QHF1gdOSQz7l4GoSFfjuQ+97M+fzP0WGQdZUm15a3sSiT5hzcmu2lcCrwbAp0NlzsslOirUwOAPZJ3Rzi9cRFH3x4dACdJoSmO6HBkizBhVPBktnJo58N/SMaPVuGgZiJHeYdVk6j0yBIMYDXw0YW9HS4lk2LKB6x83XDxjq+oojkmw8nSleW8P7UEx+MbL9ZjLgycG0PBOhssht/4xSZoNjCVsGOEAZvyGaZXfz2M3PEGfRNUdtSP0OEHC7YEoQPwBtLmKflXwjabCH2M23qNx74ySFg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1704951253; bh=qmWgWhcNfRBsL+eH5AzuDQpHz4+Tkz28/2RBAkcQKcZ=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=fsurxg7axoL7OqnKDn026jNpuyh7r0z05PPpGUyM9RuHvsmo8+dPviSMFSslyUs8N0sogdKqUxVXMkqzGMxoJIEF+M3XWjwL9bix8t6RnCiCjeJYL6/vi92n8B/BclZz51tV/280OM3zZnVGmhQoz172U5Oh+cc9GPpsGDvEEv5AFtLXq4QWHTVmhFJpVVC/f/k7bdc7PcM9sjQ0DXD9mc3DURDzzFzzbN1lcrTbXYOdQ8L4QczCXMaLwyL07n2OqpPCKPR8Qql2Nh4hE6j7x+1/9aO6f56Sb26f9+vER2k91tXNrIN/PgKf/BYvATuWxWU+oA77xriEOZ2XKSNaJg== X-YMail-OSG: BQSTQXsVM1kFmhtmdO9sijwYEDP1b4BPAG7nZJvCyHua4OrRpt8u2gBzrQChVQ2 a7W8lFwpzZVbpBbVeC6rn.5KqBRzCUSxXlRSlZ.ViBSXMaOtcB9tsZNVe46pPJDSngIUvmeHlNPf bF1gYwk2WzIQabCKfghVEKxhKjgK1Whvdz1AOAH2ZtcFnZtJuU9ADFa13IcOdFFn2BTJBF1WlxWs AJCrUWzlHpXDegJ.i0ogCXQFn0rMk6jz.WVVQIIW.kUn0nrMFJJS1NR.io_WpwqbWqoYsz4FIylN jLPyuUQw5zFCIVEo4AZz.4o96eyzWxK6vXLf34KQULewDxW9QT1YtsYBqPBGRlVr1819h80NtkXx eYmIyXwgEY8tG3lYXgD1cnRWVHjvvSsMrGGBsJGtkVcOxAzsam.IbSm61vxtOrbQ5FNOs9wed3kr D9v_BLr.bHcEUnbP3ehLh5Vucx5tiBrV1V9qX2BTGTlQdEQUfFu_HQoP5mu6AjMIHuYNzp7dv98Z _4nvcs9UQ9cj6G6RVlIJDVrMMh2MOBafCXG2viJezq1e4SuQllhzQxkvnjCPGye2Bs8MeIAKHPMn VrZreY6DdJXJW23o_tLwYYhEL35CfHhtN0z5LliKSQ6mUuvsZL09ccukLGbsB.TUi0H7LFgx.n8U VC74_tGedyJTsIFEeqZumg5btYpPaqPEhKOv980lQEXsS2.jBHPmLSC7whX5gBYhqJvOUNXqzdUs FwaTxpVE7wlwtGVwm1dKlumUFsmpmQoO195TKOHA_EcQ2Bt08kugQvB71swvtszmjbUJxNUPbEH6 eBmrvKlwtnOa5jzU0gf6SZI1jsxCW6g8KeK0UmPvCSPO1xhEAkQ7arZkpQGiTfVhU2EjQnFyizMY 6Mi.dUXi3n0pmo2qfcbrTT8wgtXTQT1CYqtb8wCf4NizQkDLe6RfSfRW6r6qfuenh.ufKAMlqivz 4QZdeqRVuLgQyqxuWB_hq.NcTavHOsrgO962FYQz6_MGl8UHcPZ088bZfno7TdELTsEiiplNNvbo oq0IzKQKJsE7oSyR.nvWa9Cl9RvwkUL9ym2.rU6zZyjMROsFNiFzmnuCtwXGWgY1LktsnSKRSCxP InoP63tF8DJlTuL2Evy03rTY.kho_yrmHZDBqiWjEHfifqCz3in.5hEYfLtptMeelqOkgF3ac6eS Ln4jr2NYiI84fcJOTRVhjpgkZLOzjiDlwnfHOAlsxou9Pmt5ZajVLtGluM1ApfBnYHdfQ6.XwwWk .oU5Tp95AXk9wFqWX20oOiVIyBm3trNZZLjzhdziuHlhOE40Q0cUcA.VV.yPhub8GVGIvhj74m2F KMOeqaGi06cPsuMyqdMujt4fsfG3F4LVKkvk6.37QnInPkoiBgrcXKM3DX3ZF5es_XNSC8VEx38e FZVtYaxGeaB2JKA9mzTkMzDD574hwUHImngR5N0ZwWWA.JLTvdYsm8A1XB9TDuewLuSftyXllslg oDT5Lv8mmVFB3Y8jTtjGvAR0k0MoWZi2JAaezHNxASZYRsLBFJ4QzsCKziB0rwTfdtHWMImuHLXc no4sh6amNGHPpZPGlQfLdlo3a40Yx4Wg0FsQDq6b7sF3XBWe4m005Tv_mNIF7fZxEu8ur6uAp7uD 6HgfxGfoDVfpaxrAdsShaHTU_OWQD0FB7stowh6wNLVkoI3McC6VK9P3dTfTu_hGhVQC66Yz4LEm qiEVqGF2h7nFMXB46J502j7nPMeIwUNsb9HGuyufxdDuj0kuGmfwse6sGsFtEeCIAgKiB0BrxAha 4PAt9qJvnuTjvXNd1y56jPJYACZvckVuThy9RwuytGcwTX.Y83Zw5I8gMhg9XrF2E2At99wpi6Wu Bfh4ZlPjqIsmQna04AZmtA8uUWOERmnJe5GXdF8ymD5urkdZJGBX.Ggdibrl1xL5UPgF_sgqLZZr 47GHGaqn0OY7VoNuHCliY3wUan0oROeo8czkSMZO6pnsWb4ObpwYdzxx2JcsvqVsh7nYQawNt0SE R1rqhNKuwgAsNmGta.a.hQXWhdPFcci0WZXyUVXe2YfWYPL_WL3pXAEx9Yc633v90vi.1uOOFLKK 4c7ltRhRwHtdlUwdfkfBOXQjuHEm59h8stVgbrffp_bK_CknJ47KlePNpfxtovR2SZoHW0lkupUK io8MU5zmAXZdkfJoBAeCtO4K1ORFt7BVvxGVm5_BexOruVHVATLt8KOTigsDphL_DjvGMEL4LNTb H_Xh6Cngo5PnoxPj75xwk3DxpasewYvUGSWCK2gp_vPcaoYZfaOIMJBCzyR1Br.YP.uQAuxW7EQ- - X-Sonic-MF: X-Sonic-ID: 1c8e9025-4a02-4452-ac8b-132969021058 Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Thu, 11 Jan 2024 05:34:13 +0000 Received: by hermes--production-gq1-78d49cd6df-vkd75 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID a506b8a9e0ad6acce669c50d2820a71f; Thu, 11 Jan 2024 05:34:10 +0000 (UTC) Content-Type: text/plain; charset=utf-8 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.300.61.1.2\)) Subject: Re: USB-serial adapter suggestions needed From: Mark Millard In-Reply-To: Date: Wed, 10 Jan 2024 21:34:00 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <041F74B4-3D44-4364-9EBD-9F21A4F3B313@yahoo.com> References: <7D27DF9F-AA9A-4D44-BC28-8CC637D0F550@yahoo.com> <3012A549-9482-4D69-9DF4-7987E650DFFA@yahoo.com> <55AC6824-587D-4C67-B64B-2045A1112F69@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3774.300.61.1.2) X-Rspamd-Queue-Id: 4T9YJ72gVqz47Yn X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] On Jan 10, 2024, at 15:55, bob prohaska wrote: >=20 > On Wed, Jan 10, 2024 at 11:30:28AM -0800, Mark Millard wrote: >> On Jan 10, 2024, at 11:21, Mark Millard wrote: >>=20 >>> On Jan 10, 2024, at 10:16, bob prohaska wrote: >>>=20 >>>> On Tue, Jan 09, 2024 at 05:03:42PM -0800, Mark Millard wrote: >>>>> . . . >>>>=20 >>>> In general the tip session is used only for observation or >>>> troubleshooting. Ssh connections are used for other activity,=20 >>>> including OS build/install cycles, poudriere, etc. They are >>>> usually placed in the background, writing to log files so that >>>> accidental disconnects from the workstation don't stop them. >>>=20 >>> Are you using: >>>=20 >>> NAME >>> nohup ??? invoke a utility immune to hangups >>>=20 >=20 > The OS build commands end with &, which I gather does nohup=20 > among other things (not sure what). =20 "&" creates background processes that are still killed when their parent tty or controlling process goes away. nohup avoids that kill. man signal reports: Num Name Default Action Description 1 SIGHUP terminate process terminal line hangup https://en.wikipedia.org/wiki/SIGHUP describes it via: QUOTE With the decline of access via serial line, the meaning of SIGHUP has = changed somewhat on modern systems, often meaning a controlling pseudo = or virtual terminal has been closed. If a command is executed inside a = terminal window and the terminal window is closed while the command = process is still running, it receives SIGHUP.[1] If the process receiving SIGHUP is a Unix shell, then as part of job = control it will often intercept the signal and ensure that all stopped = processes are continued before sending the signal to child processes = (more precisely, process groups, represented internally by the shell as = a "job"), which by default terminates them.[2] . . . Firstly, the Single UNIX Specification describes a shell utility = called nohup, which can be used as a wrapper to start a program and make = it ignore SIGHUP by default. . . . END QUOTE (I omitted an alternate way that does not apply to FreeBSD.) nohup avoids using that "which by default terminates them" status. But I'll also note that: = https://www.gnu.org/software/libc/manual/html_node/Operation-Error-Signals= .html reprots: QUOTE Macro: int SIGPIPE Broken pipe. If you use pipes or FIFOs, you have to design your = application so that one process opens the pipe for reading before = another starts writing. If the reading process never starts, or = terminates unexpectedly, writing to the pipe or FIFO raises a SIGPIPE = signal. If SIGPIPE is blocked, handled or ignored, the offending call = fails with EPIPE instead. Pipes and FIFO special files are discussed in more detail in Pipes and = FIFOs. Another cause of SIGPIPE is when you try to output to a socket that = isn=E2=80=99t connected. See Sending Data. END QUOTE >>> That only ssh sessions that in turn run tip fail suggests that the >>> tip session gets the initial problem and then things propagate. I >>> want more than a suggestion. For example: direct tip runs that >>> are not in any ssh session: still get some form of failures? >>=20 >=20 > As it happens, the tip connection between nemesis.zefox.com (terminal > server) and ns2.zefox.net (console host) dropped. The display = reported: >=20 > login: Jan 10 09:42:46 ns2 sshd[48003]: error: = Fssh_kex_exchange_identification: Connection closed by remote host > Jan 10 10:51:54 ns2 sshd[48135]: error: PAM: Authentication error for = illegal user shell from 185.11.61.234 > Jan 10 10:53:03 ns2 sshd[48138]: error: = Fssh_kex_exchange_identification: Connection closed by remote host > Jan 10 10:55:47 ns2 sshd[48152]: error: = Fssh_kex_exchange_identification: Connection closed by remote host > Jan 10 11:22:26 ns2 sshd[48203]: error: PAM: Authentication error for = illegal user test from 85.209.11.226 > Jan 10 12:24:21 ns2 sshd[48300]: error: = Fssh_kex_exchange_identification: Connection closed by remote host > Jan 10 13:12:06 ns2 sshd[48380]: error: = Fssh_kex_exchange_identification: Connection closed by remote host > Jan 10 13:14:06 ns2 sshd[48381]: fatal: Timeout before authentication = for 59.56.110.106 port 50300 > Jan 10 13:34:34 ns2 sshd[926]: error: beginning MaxStartups throttling > Jan 10 14:12:41 ns2 sshd[48506]: error: PAM: Authentication error for = illegal user shutdown from 185.11.61.234 >=20 >=20 > FreeBSD/arm (ns2.zefox.net) (ttyu0) >=20 > login: client_loop: send disconnect: Broken pipe Note: "client_loop" is a function in: /usr/main-src/crypto/openssh/clientloop.c "send disconnect" is reported after a signal stops the looping: /* Terminate the session. */ =20 /* Stop watching for window change. */ ssh_signal(SIGWINCH, SIG_DFL); =20 if ((r =3D sshpkt_start(ssh, SSH2_MSG_DISCONNECT)) !=3D 0 || (r =3D sshpkt_put_u32(ssh, SSH2_DISCONNECT_BY_APPLICATION)) = !=3D 0 || (r =3D sshpkt_put_cstring(ssh, "disconnected by user")) !=3D = 0 || (r =3D sshpkt_put_cstring(ssh, "")) !=3D 0 || /* language = tag */ (r =3D sshpkt_send(ssh)) !=3D 0 || (r =3D ssh_packet_write_wait(ssh)) !=3D 0) fatal_fr(r, "send disconnect"); Note that the code just above is executing on "pi4 RasPiOS workstation" trying to write to the pipe involved --but it ends up reporting the "send disconnect". fatal_fr uses ssh_err(...), which in turn can use strerror(...) that can get the text "Broken pipe" (SIGPIPE). The "Broken pipe" indicates the type of signal that stopped client_loop, indicating that on nemesis.zefox.com there was no longer any process around set up to read the data from the pipe. What was running on nemesis.zefox.com was its side of the ssh that in turn was attached to the shell that in turn was running tip --until those exited/were-killed on nemesis.zefox.com . But there is no information here about which of those was the one to start the failure on nemesis.zefox.com : A) Was it the tip process? B) Was it the shell process? C) Was it the nemesis.zefox.com side of the ssh? We only know that the end result was lack of anything reading the pipe on nemesis.zefox.com : by then the ssh side on nemesis.zefox.com had stopped being set up to read the pipe. > bob@raspberrypi:~ $=20 >=20 > Interestingly, there's a MaxStartups warning. I discovered the failure > somewhat before 15:17 hours. The link had been up for a couple of > days IIRC. >=20 > I logged in on nemsis.zefox.com's hdmi console and usb keyboard (the = only Pi > in my collection set up for video console logins), opened x11, started = an > xterm, su'd to root and ran tip to connect to ns2.zefox.net. Did you then look at /var/logs/messages on ns2.zefox.net ? What, if anything, did such have from around the failure time frame? Did you look at /var/logs/messages on nemsis.zefox.com ? What, if anything, did such have from around the failure time frame? Did you look at /var/logs/messages [or the analogous linux place(s)] on "pi4 RasPiOS workstation"? What, if anything, did such have from around the failure time frame? I'll note that /var/logs/messages (or the like) need not be an exact match to what the console reports. > The connection was normal, no problem with needing to power-cycle the=20= > usb-serial adapter using usbconfig; tip connected and displayed a = brief > string of mixed printable and non-printing characters, ending with a > login prompt on the same line. Next came two reports from ns2 of=20 > "... kex protocol error...." =20 >=20 >=20 >=20 >=20 >=20 >>> Specifies the maximum number of concurrent = unauthenticated >>> connections to the SSH daemon. Additional connections = will be >>> dropped until authentication succeeds or the = LoginGraceTime >>> expires for a connection. The default is 10:30:100. >>>=20 >>> Alternatively, random early drop can be enabled by = specifying the >>> three colon separated values start:rate:full (e.g. = "10:30:60"). >>> sshd(8) will refuse connection attempts with a = probability of >>> rate/100 (30%) if there are currently start (10) = unauthenticated >>> connections. The probability increases linearly and all >>> connection attempts are refused if the number of = unauthenticated >>> connections reaches full (60). >=20 > If sshd mixed up new with existing sessions it might kill one running = tip, > but it'd likely kill others from time to time. So far that hasn't = happend, > at least not often. >=20 >>>=20 >>> It does suggest that testing isolated from the source(s) of >>> unauthenticated sessions could be worth while in case handling >>> the load from such sessions when already heavily loaded with >>> buildworld/builkernel or the like leads to other problems (and >>> denial of service consequences?). >>>=20 >>> I do not expect that this issue is all that likely but >>> expectations are not evidence of their own accuracy/inaccuracy. >=20 > It's my (very) subjective impression the ssh/tip problems are more > frequent when ssh attacks are more abundant. Nemesis.zefox.com is > public and sees a certain amount of doorknocking but for some=20 > reason considerably less than www.zefox.org. =20 >=20 > As an aside, during some stages of testing with pelorus.zefox.org > the host was on the LAN and so not subject to attack. It certainly > didn't prevent failure of tip sessions. Now pelorus.zefox.org is > on a public IP and seeing at least sporadic doorknocking. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Thu Jan 11 08:23:15 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4T9d3800k1z56rGq for ; Thu, 11 Jan 2024 08:23:16 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4T9d374ccZz4Vb5 for ; Thu, 11 Jan 2024 08:23:15 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1704961395; 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; bh=mMpvJn6dT3hKKFi1ofCIlFMKT17380mBk69Gc8k+b5I=; b=R6EQ4K2cEvvSdXmvexhpFnPLkIx2oK6mfSmLhxfFn6ukFrDz7rEorCqGtA1pWBjGHj6G9f XzZxzf2biWUZeaIU/1Rjis97A8CWepaRFSIJje5HaaMdG5QJAt60NwpfOHONxaTZOtXZ1h Msr2v2ECagb5a1rtye01GiPHJ9W6zvH3DveiaiEwfMzzZquiGOdHwX5PEdHLPNZNMx4LI0 Wq60R+94yp1Ty2at2l+A7cVQxmiehKwcSKeNg4eNKWpXexMIVI5ky5TRX9NcACD36gdn3+ aWY07MZ92RZvGN2DeYiD0fOrEHJPpg+Qmb6zT0Lkb+1mIqOCInhWvCsG1nItQQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1704961395; a=rsa-sha256; cv=none; b=aOCorlxg+jb5gUgwTTg9qisw+7m/7ZI1CbADUb8uAUWxIUIyyaAmpGFY3yWTF2GTxrZ7UN btKT40/m+k5s2wNtuYNkIhuqeNOGm9QLzV1EhmfFKQP698rfDt1vkCqyWmNFPuogzYQluo j5KzPOGicccocpAkoBQjnnGoWLyi7hBqOqdnfJ6P10ruKD3xcHCUucrWlyrelguLCTa3b8 4u3wTBbPF91tvZOzgx5PNnzJuySc/fDlj9Y4S75bBngPuJIP2JOizMpnhiPPv8yKklYOy8 id4kyo3Bm0WUOQMnml23bI2Zj1p9fYugAfNzPfOHMdUAKdAsAbILavttTPF0Zg== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4T9d373gztz19tH for ; Thu, 11 Jan 2024 08:23:15 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 40B8NFEQ057415 for ; Thu, 11 Jan 2024 08:23:15 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 40B8NFrU057414 for freebsd-arm@FreeBSD.org; Thu, 11 Jan 2024 08:23:15 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 276254] VIP BANGALORE ESCORTS Date: Thu, 11 Jan 2024 08:23:15 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: Unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: selectyourgirls@gmail.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D276254 Bug ID: 276254 Summary: VIP BANGALORE ESCORTS Product: Base System Version: Unspecified Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: selectyourgirls@gmail.com The world of Bangalore escorts is largely mysterious and unknown to many. W= hat happens behind the polished facades? Who are these individuals who choose to work in this industry? This blog post aims to shed some light on this intriguing subject and give you a peek into the world of escorts in Bangalo= re. --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Thu Jan 11 08:36:03 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4T9dKw4ypcz56t9H for ; Thu, 11 Jan 2024 08:36:04 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4T9dKw1Wzpz4XJH for ; Thu, 11 Jan 2024 08:36:04 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1704962164; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ed5HVhXi9pzwXzSqlD4EKu/E408a52oDlNftBFx87Ds=; b=vYMcTWsWo1MsrHtF9KtNvnoE/nV+vGTHFpNeGBO/XKHoEq5pUCOECqTGiK/o+1wwIWcd4B ckCxI1ZHJuYogSaHjet+4I3MDE50YjMnyU0XgCkPkXsoR3+PuiF+mA/U6DUKXz+wwfhmvD b6YguClifw65mtFnU6o2KFV7TaHv0yrUQ5MoMZFH6vXbOUGeFLqwgnUPteRd7YSxzIG2+S Rg6QR3otJ3TN8Ekj+jN1SHQtvmX9H7DhWoNCrHJetCFVA8w2993UzY8thcyWhcckoPRihi I1eVRaSGoLJ1FHdGUeFSbOzy0Zm0rT+EduhZTCqWQxkUnUyLuLKOcrePIhxYZw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1704962164; a=rsa-sha256; cv=none; b=jrnQGNixPhIrzNnuU/GWiyV8vPTICPaG2hkd1ew3otXMxewevGAE13xBPENee9du6aUGuj 32vM+kvprZRstkPjDnpi4pjPk4mtSx0YVWaP8wQbSBq63Es9yLY3aHimSD/5gop1GVEonA 76Zk9NTfiuDr26rgJmLntIjhzbiQu1o4WKl9GRE/OfE1vHrHdjtFDNrUnMuGmM31od2Ffa cA2V3TaQjgTsJkjTJiFdxkGV686qmaiXQj6LGO4eOZUl5cvPDcqw6uN/PNMPXOV/iQXRJ/ q2lBOEv9CrcmOiBwLzfGAvKD8ICvpe3Mg1GTULRL09QI7ApE7P/ZV4gxcYON8w== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4T9dKv6jmFz1Bdx for ; Thu, 11 Jan 2024 08:36:03 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 40B8a3kb021796 for ; Thu, 11 Jan 2024 08:36:03 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 40B8a3es021793 for freebsd-arm@FreeBSD.org; Thu, 11 Jan 2024 08:36:03 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 276254] VIP BANGALORE ESCORTS Date: Thu, 11 Jan 2024 08:36:03 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Other X-Bugzilla-Component: Spam X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: Not A Bug X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: bugmeister@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: component resolution version bug_status assigned_to product Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D276254 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Component|arm |Spam Resolution|--- |Not A Bug Version|Unspecified |unspecified Status|New |Closed Assignee|freebsd-arm@FreeBSD.org |bugmeister@FreeBSD.org Product|Base System |Other --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Thu Jan 11 12:00:23 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4T9jsn37NGz57H2X for ; Thu, 11 Jan 2024 12:00:29 +0000 (UTC) (envelope-from infoomatic@gmx.at) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mout.gmx.net", Issuer "Telekom Security ServerID OV Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4T9jsm1tqsz3wnR for ; Thu, 11 Jan 2024 12:00:27 +0000 (UTC) (envelope-from infoomatic@gmx.at) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmx.at header.s=s31663417 header.b=FZRVmyem; dmarc=pass (policy=quarantine) header.from=gmx.at; spf=pass (mx1.freebsd.org: domain of infoomatic@gmx.at designates 212.227.17.20 as permitted sender) smtp.mailfrom=infoomatic@gmx.at DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.at; s=s31663417; t=1704974424; x=1705579224; i=infoomatic@gmx.at; bh=PscM5yqKlWbo+HgO9XKKT7XXii63etVUwziXEBEiymE=; h=X-UI-Sender-Class:Date:To:From:Subject; b=FZRVmyem7kdmdXOhX8TICHikFEnvWv5ihEYQX+ofFHgEbZ8iwB0vcY92oPwSRJkP T4Q7gkj0EirEbeHufO/ZYHYkBcAoQu6guzXH/o1YhTcBSy1YJGhWmSRdDFo4npyyp IHDSKm0+lfRUoGVlXcrqKAY9kj1ybTAEZm0dnbAnOaUh5HeSq2/+CpEY9l/hdWtSn YM4zZZAuoCS3pSOQJiPXrftrogHDoLZAcg4adUBawdtYNvEb53jrk2BDcEo/pTB3X a54ERe7HTq9BuRFAnaZ7ZaP0nKfJ7NavUX8bykyM42PRV/CPxPUdcY0QPwGct/S0N dJJcQThXaj+Uij2Kzw== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from [10.0.1.209] ([178.114.186.210]) by mail.gmx.net (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1McH5Q-1qlG7w0EDk-00clhG for ; Thu, 11 Jan 2024 13:00:24 +0100 Message-ID: <3a9870c3-e29c-4782-a148-57684d1f917d@gmx.at> Date: Thu, 11 Jan 2024 13:00:23 +0100 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: freebsd-arm@freebsd.org From: infoomatic Subject: free ARM VPS Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:GjAzMhXBD0V/nSvpqsSnWhIyWHsAutwUc9EjkMJ2YU6Oew2VAth 3Ja/Y4YfG3zIoEZvbLzRdyLAZNi7sIsBd1woikoHArgauNQl6c+DxrmN33DKWqVej4tJqss GwOdbccHqjkbBvf9/OqT8ciZw+YBGNGWowAiLKzfBTRdDW0tuqnATDZZTgEvRJ3kkQ6nqIm IPfh9cNxBAWWMyz36V/6w== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:gf15OWgQA8c=;F1tqPA9QMJhutHjgIulWC+Z26Jk hTVgypOXnf9Nwm9Xq1ANwPHL3y8unV2/5xSr45eM0Ocp0ptaa3nKWtfYdM7HgA4R7tJ0qP4OV G1+TtSFR5xjKllcBhmB6t3uLHeAHZqkPSWXUZtT/EvhcfIAkRDlUKQTOa6wFeyU3WsHZPl3Uz DUbpDXAw2yEM1KmLiVq2jI87m17aZLIIdiF5NY49YbZgfhJ+Ia3HIIN3Ik62Oe2XwpapqGEM4 M6AjFCeV5xzLAnL+4j/2xjAHsTeHH+dd1I+M5Yv/IK9dzPkcdNDr0+hqR3A4W+nbxT7hCcG3L TMOcSXv83unt0Eca9SmkXfZz4xno24U2U8LhPloVlsVhUBBqUvfWO1xo9Y28ZClXq5iRVdYhJ WWfZYILDlWV4dBMihU5xLJG08glqOQFNC3fLqA/RoRQg2Im4jDE1v0Vw72eN/10ZxcEU02el/ suF8n+IrDjMbv5Hmu+16lg/0KFcvSzdNl22WwciDsAsJCu72u+ugXsEJfU3w2mWTPEZlZLLZq IEwrTvBizr5Eymsz08GSN8Z8N+rdKnf1I4+YxylG0Nw+2blK4fVmCwMmkkKQuLiRn0958Oxsb 1DVNYOPgVTWPcmwwoMOgiFDGuxmrRzxeJAiqh4xWAvPU6BqSSwblutoAw1et5WMtp0uhYeQYN gwO/kRawz0QDMLR7uRdYYFOW15zHiEIwuDWm2Ov+miP+MLE7281K3+apSOQ4uXIC9vqjSuSmO RhlWHzWwTkSwqvWPY0Yw6LvzlyF4OFqvYUsH81mN2Zx2Wp5x66vEQc+ejsu5f6zDPYHWbxTQD /SAz3VEUBoBqKwQhBjQCR9JTr0/Kg4H1cOWrNn4ip58rBzIMQowfr6oP1jBnBb5hoc3KLHidK pwke7eURpSPem7nsyl/raWP5FZTaNCDeAPzAocprRwc48BnANyQcKs5lcdDeSSvgymxCvBWUW 15EvNA== X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.19 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[gmx.at,quarantine]; R_DKIM_ALLOW(-0.20)[gmx.at:s=s31663417]; RWL_MAILSPIKE_VERYGOOD(-0.20)[212.227.17.20:from]; R_SPF_ALLOW(-0.20)[+ip4:212.227.17.0/27]; MIME_GOOD(-0.10)[text/plain]; ONCE_RECEIVED(0.10)[]; RCVD_IN_DNSWL_LOW(-0.10)[212.227.17.20:from]; XM_UA_NO_VERSION(0.01)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_TRACE(0.00)[0:+]; RCPT_COUNT_ONE(0.00)[1]; DKIM_TRACE(0.00)[gmx.at:+]; RCVD_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:8560, ipnet:212.227.0.0/16, country:DE]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_FROM(0.00)[gmx.at]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmx.at] X-Rspamd-Queue-Id: 4T9jsm1tqsz3wnR Hi list, While I am not afiliated with the vendor, I just want to give a little hint to you, just in case it is not known: Oracle has a "always free" tier with some services which are free to use. With the ARM Compute Instance you can have Ampere A1 cores and up to 24GB RAM (in total), so up to 4 free ARM VPS. I have used it for my small personal projects, and it works great with FreeBSD, also the upgrade to FreeBSD 14 without problems. Regards, Robert From nobody Thu Jan 11 14:18:11 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4T9mwl3Q7Kz566VP for ; Thu, 11 Jan 2024 14:18:15 +0000 (UTC) (envelope-from void@f-m.fm) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (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 4T9mwk4cZ2z4QcY for ; Thu, 11 Jan 2024 14:18:14 +0000 (UTC) (envelope-from void@f-m.fm) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=f-m.fm header.s=fm2 header.b=A1NlG2EY; dkim=pass header.d=messagingengine.com header.s=fm2 header.b=T43XYJqE; dmarc=pass (policy=none) header.from=f-m.fm; spf=pass (mx1.freebsd.org: domain of void@f-m.fm designates 66.111.4.29 as permitted sender) smtp.mailfrom=void@f-m.fm Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id A36C65C017D for ; Thu, 11 Jan 2024 09:18:13 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Thu, 11 Jan 2024 09:18:13 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=f-m.fm; h=cc :content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm2; t=1704982693; x=1705069093; bh=c3a3TM5gSe Rlzlwp+dJMDetInNxZxX6IdIDYN2U6DsA=; b=A1NlG2EYM6f9PYtIApuMn9k3Au 1ZmweEKx/YhNh2xTgDbAudAfUleSRZ0BXC0LpTbX9Rw0iAfUe0s1oqHDuRtEJdZp B5Jt6KRPxBg49D8XOqQ/aw7p+FUGEGaLCksHRQ/2/90qIPMxDUpns1xGAdl6YTex 1PsBy8J/mdkCpsgn8n/Vf7t2B9JDtajGAKem8sXS8jDEx9HI5nJctPhD31jwjZoK XJ1kkRYSK32DuvQWNPkpFsoAvKcst1JvCZ8w3MlVWhwF+u810SySiHpwHcCj/L1L SmmdMm7jCgM+8Z5R5WLH5UONca8CDqud4qHOBEML9v+cQDhW6s7XWCfJFcqA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; t=1704982693; x=1705069093; bh=c3a3TM5gSeRlzlwp+dJMDetInNxZ xX6IdIDYN2U6DsA=; b=T43XYJqE6lyJoMLXaRpnoYzkvgi8ErRUNgIaoLu8YkXP XhF43jaCQKFnvx6+JiK1vsqWnJtd0MuRcl4DSuV9dHkYWlYtDDAtXDmItZCj1rIS DnNcbRBnFLqiXwuNixI62T+iWSlOfB1G32IGza3BOAT/XxCYUedvTysSgkBpXLu3 LTX2N2fGmeHIsPZkdhYwduv3OomuSVo8zBd4CVWUplTCXKhfgRd2fJ3IDfZvh8bS uoEeep2FIPWvgL+thCXVRkzlQTmKIu5y3gxcW5/B/RnDnudmC/6NgTIOzAO9cKfp IXJqpTPkObOxsrZ3lBtCUoZKkGJNBd28s3VXzfd2fw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrvdeifedgiedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggujgesthdtre dttddtvdenucfhrhhomhepvhhoihguuceovhhoihgusehfqdhmrdhfmheqnecuggftrfgr thhtvghrnhepkeeluddvlefhieelfefggffhffektdehleelgfdugfdvgeekjeejuddthe ehgfeunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhep vhhoihgusehfqdhmrdhfmh X-ME-Proxy: Feedback-ID: i2541463c:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Thu, 11 Jan 2024 09:18:13 -0500 (EST) Date: Thu, 11 Jan 2024 14:18:11 +0000 From: void To: freebsd-arm@freebsd.org Subject: Re: dev/label/growfs_swap Message-ID: Mail-Followup-To: freebsd-arm@freebsd.org References: List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.99 / 15.00]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.989]; MID_RHS_NOT_FQDN(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[f-m.fm,none]; RWL_MAILSPIKE_EXCELLENT(-0.40)[66.111.4.29:from]; R_DKIM_ALLOW(-0.20)[f-m.fm:s=fm2,messagingengine.com:s=fm2]; R_SPF_ALLOW(-0.20)[+ip4:66.111.4.29]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[66.111.4.29:from]; FROM_HAS_DN(0.00)[]; RCVD_TLS_LAST(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; RCVD_COUNT_THREE(0.00)[3]; RCPT_COUNT_ONE(0.00)[1]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; TO_DN_NONE(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; DKIM_TRACE(0.00)[f-m.fm:+,messagingengine.com:+]; ASN(0.00)[asn:19151, ipnet:66.111.4.0/24, country:US]; FREEMAIL_FROM(0.00)[f-m.fm]; MISSING_XM_UA(0.00)[]; FREEMAIL_ENVFROM(0.00)[f-m.fm] X-Rspamd-Queue-Id: 4T9mwk4cZ2z4QcY On Wed, Jan 10, 2024 at 05:39:44PM -0600, Mike Karels wrote: > >See growfs(7) (man 7 growfs). > > Mike aha! man 7 ok, got it TYVM :D -- From nobody Thu Jan 11 16:20:28 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4T9qdy5SCfz56NP1 for ; Thu, 11 Jan 2024 16:20:38 +0000 (UTC) (envelope-from dfr@rabson.org) Received: from mail-yw1-x1130.google.com (mail-yw1-x1130.google.com [IPv6:2607:f8b0:4864:20::1130]) (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 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4T9qdy3qjxz4nqB for ; Thu, 11 Jan 2024 16:20:38 +0000 (UTC) (envelope-from dfr@rabson.org) Authentication-Results: mx1.freebsd.org; none Received: by mail-yw1-x1130.google.com with SMTP id 00721157ae682-5e76948cda7so53479757b3.3 for ; Thu, 11 Jan 2024 08:20:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rabson-org.20230601.gappssmtp.com; s=20230601; t=1704990037; x=1705594837; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=hBsAOA6v7zI6TkEl10yjNdVQLlnYYcB2UvaCpmfFmuA=; b=aaPX4zxTgt6uBD6EgJ33Af9KzD1TCTA7Iw4IcjFb2ayIfDpvA+r6S4R2cVoPWTMI49 4pN7GoWyr7l2FGGA1kRJskJt/z8mpJkSSU4bSo2gaYKTqaVcpKq2a2jlSBuHPPEaxT5S YSdjsQeS7JUSkL0UNRWSotKWL0cV72SPJ7kxyZ97z7dNQY8soo5FrfkqZGoJnjTlr+eY 4eYt4C9xdeDk1uucVtTmWQi8dS55J4OcMpuxCNeyKBSg7+jzUpYz3JOj4/MUGKP9w+0K y7Pb0TLSEi1gYRBY0XkgrohFij9bhrfN3UYsC9yw9Z2a6hXQYlQfFEfPLbJpsjH/jyvF CDNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704990037; x=1705594837; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=hBsAOA6v7zI6TkEl10yjNdVQLlnYYcB2UvaCpmfFmuA=; b=AhQtlt10vtvZoo6oxFYFIj09LDT2mqOU1IU4ILzy3SolyZRtZAsouqpc8gbeNwKOIX faGdi3xovm9QP18W0a9qhAAj1rQiSoSxOd2monsxYfmHL/5wTtWZCN8f3u5i7+or/KN8 F3Wftw7QojkV7ba74/KLpft5C0Fi7NnVndkkMH4MTOsrFglDLyi3W9+6hcNIrv/wrFFC 8Pcz4v2jFFEFSkoUCe8Hbvw3U2ct1AQxT/bf5jk6r5F38eMQ3zat9GRfA7clghGkwezk buTu4SyUi3krKkWUZlqHrm7IOLhkHsYnD41mq3TOkobPdUd+WU28KCJsU9zo1uBAPZIx /ISg== X-Gm-Message-State: AOJu0Yz33xQC73DaP6oLEtMDq9IDxbyDXjXdLQNQRqG7Mp6tJUqGDDng kvesYA6Nn5Xsb/C3W4jyvgq7oDkM0mIk+ZIkqphMVHRg80DgVg== X-Google-Smtp-Source: AGHT+IGY9EYUaiAceDHwUv5b3mixicDERnpKnXlESkHsPfJj0gT2JYOxVDi7lDywaIA3HJxR2xgBhw0mRzLhjpYb8Go= X-Received: by 2002:a81:4917:0:b0:5e7:ed6f:c63b with SMTP id w23-20020a814917000000b005e7ed6fc63bmr9911ywa.95.1704990037422; Thu, 11 Jan 2024 08:20:37 -0800 (PST) List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 References: <5a39810c-5fd8-4969-a222-2561b050b035@FreeBSD.org> In-Reply-To: From: Doug Rabson Date: Thu, 11 Jan 2024 16:20:28 +0000 Message-ID: Subject: Re: When will FreeBSD support RPI5? To: Mark Millard Cc: Jesper Schmitz Mouridsen , John Kennedy , ykla , FreeBSD ARM List Content-Type: multipart/alternative; boundary="00000000000086c7c0060eaded9a" X-Rspamd-Queue-Id: 4T9qdy3qjxz4nqB X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] --00000000000086c7c0060eaded9a Content-Type: text/plain; charset="UTF-8" On Thu, 11 Jan 2024 at 01:30, Mark Millard wrote: > (While I normally use FreeBSD's U-Boot type of context, > My builds do have patches to allow RPi4B EDK2 use to > avoid the problems that I know to test for.) > I'm curious how you were able to boot FreeBSD on rpi4 with EDK2 - I tried with both the FreeBSD package as well as the latest release from github. FreeBSD-14.0 stalled trying to initialise xhci while FreeBSD-15 gets a little further but also hangs before reaching single user mode. I'm wondering if perhaps I should use the dtbs from sysutils/rpi-firmware rather than the ones from sysutils/edk2@rpi4. --00000000000086c7c0060eaded9a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, 11 Jan 2024 at 01:30, Mark Mi= llard <marklmi@yahoo.com> wr= ote:
(While I normally use FreeBSD's U-Boot t= ype of context,
My builds do have patches to allow RPi4B EDK2 use to
avoid the problems that I know to test for.)

I'm curious how you were able to boot FreeBSD on rpi4 with EDK2 -= I tried with both the FreeBSD package as well as the latest release from g= ithub. FreeBSD-14.0 stalled trying to initialise xhci while FreeBSD-15 gets= a little further but also hangs before reaching single user mode. I'm = wondering if perhaps I should use the dtbs from sysutils/rpi-firmware rathe= r than the ones from sysutils/edk2@rpi4.

--00000000000086c7c0060eaded9a-- From nobody Thu Jan 11 16:56:28 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4T9rRb4zDtz56SRZ for ; Thu, 11 Jan 2024 16:56:43 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic308-55.consmr.mail.gq1.yahoo.com (sonic308-55.consmr.mail.gq1.yahoo.com [98.137.68.31]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4T9rRb2Jpzz4xDp for ; Thu, 11 Jan 2024 16:56:43 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1704992201; bh=a0/z+ZhJP5uI/SOUNjuV9Y6G2tKXqAPH0jj1i0+HW1U=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=biAQjjT3gmk4DMkn17hnh+VOJ2bz9DY37Zdnd9egMnht8fQvz07va57+zW3scA1EiJSzU1FlawvTP9XhguKybvY7BUVT+QW1zkrNABOvPCYeVT+QMa8Ftv3NgBZWYrWLy6Iku6rrAnfPBe4gM2RWCwzt3DXlmr6Rh7YdU4lrk0eNRyx1oTyiR9P0ZrXldOeRIhwYCttrrEzTMm7dhPaS/sLayruvIX0K63Pp4sNTcJDmu/WJGbS0qFDgsUDK6DuTPUYmzS//QpJo5IJCBRd9f+1F0P9DPhEUAcw7nDojW9nYflJoIw5/p+e9D25fqF5Ph8fg5Ac32oDdmaWJGMqP4w== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1704992201; bh=lfRP/Xy4ichq3lZqR0uPfwFH/0xJNsw38tFWhc5yeeC=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=tOVzNlM5PLXfaINrVSI4vHo+twEFhviWfoyenaBUBcXroEgEND01WTe2o+PwV5d/PRPi3KQsk0wGifGWM2TdnHE+3m7aHg62Fj+pXZnwpdJBiYsfLAIQFTiCmw0uHw6GJbJs2Us+F7XGGa+b2bG+r+QCEDncds1P/XtS+6K1vTmvp4ave95tjpf9OYg0rujROtctjX6zwkiG4gjfRKwD9VikKbipw3Qk2Wxaxl+2gylY2xI9NY50+y7cK8aNZKIhxjrFPyloI8mXsvzh7M6fh4D9jPMMpXVE/ku2Qx8bAYD7Hsk7Z6SMKAxzQzMPxXTPEjqQRn5LJTU7twUsfBanjg== X-YMail-OSG: AyaAvFMVM1lU4a2mmRQw6CBZqTQYRbNc.obmSiCufXhPcAT2NvUhmKbIBDS_zLw .6fx99HG.w99MF6NlDUMXlgfypQo2Fz0I4MXejiyHItb455RRrarqSSg.qOqScr8eG54Pj9jmd9L jcGy.FJiIV0_9xyOG7t710DGsRpY50YUN5DiTbM6wLq0kG8.fpQc3w8JRqWxN13eTYIX5oPHwy1w wsyLq6p402UD37saShwlU2sru6a8v12kAj5pLLUWbDHB2zEl4qGKmlsX6umcCDcdxOv2NBbSq1wE lp32ZgcHJraluOtF4LNIEEFYaqj96.nj93iiz0TyHiXg3eCYwxmLC94oPegoHUKhtSs57SGuTpQg ochSVLUTTm8b9Fhy0oaJCvLq2YonGKUX_rundrsBGnhjpodcnF2UqY4rI84FotuurB4QqOdxJx6P UEvrFxtLC0d63vUtikFml1lEAllUjjDLbiFAsQ8u.L0VhmRgcOas8HbeIpVkPWvatvXmuitv5KDq b_9UMgZ7yaXe61e0wMSuSkXu1fyY9mqLfApWRfSaB7GazvY5LWa4YfsG7w.wZTznHLUSCcnDVj.U rje_5LZOW7XQP5I.ETyW0tAl1pXA34CHsg6_LBXNGYFdU4jiKuGci1CCsdftJ3h3Rv7KJ3fTMUCg DfsVDm12UOBgDcYgsRM9PNZGiFligrBHel0GULmWLwhnCgR47rN2YEoJa7FYvZe62JHwbSt1apfY HrnMbResuIrmEGPfCQ4w.Q..Lq4C.AY3d9U5WKeMSVPXD8FXmIfXFW4ZFmydEaMAdDUMGcPxTdKz psYokBc0IARS0fEruDnDG8bIRzEsvCdxeoXV1RQyabhK01WN3JLix0soFDQxNXDyox7kOKhu2rwp w_2cpahDTD6WRuvo31F7HRurpH7sOmNoTCW7Qbk.I7uE_fDR9zbSdyNDbr3VekLs_KWT_diaDe0r 8EJrQpZZCvlYwOH7RbRc7rfUhY_qtVX3ImOMZXt1Csa_IM43Srij0EBkxzp_VuU3Hei1_Icriajv 0kZMpXGLRgcgGWMqGYwFKDQj_i1UVItqS6hg0h6W6uQkVAytElYSyLTc677n.7AbMQAlSnCYaNMa 2fymA4tBpMO_i0p41vzJLAifKgfihblXze8Q84.yC3kv72qCAQWc0l2EVFAbcrb_NczUvzgAPGdB xfDlBn7DPM4vv31LWFNskXIezkscvVeq8810Hr5sPiHZE8iFYbqRKGUsmQOlcmDRE9AxY7lzpW4Z EDwct4t5ROji0Tp3.3nsSiJ2QP.S9s4omPB27JPEE4b4.HZxdkpXRF44B_OZVd3D.9SIZPXuJVTI HLW1e5vTskw9by67aZ5NeX_yWNPUtmQ4aq44ztMz4Gt4PMqDz12gBHfw9jkWkngs7uhWM5wKWefj Kz4haw1QDdUACHtO.II0aDKLLVFwK0Qp6djhcIDVkTZvSU6otTXmh3jX8lI7s5lnr2W7osBsNYBs XBvaZ6zUH8_iGeiAddMYPRbP4YfMadpVGknTilt3S8tw2l.mxHpDdWc0paMK34zbD6fu_NiZD0o_ Nh1MswBr.I.9Tzn9u7AhsQBSctctJxMEtqcmTGJ60wh7zZQ9KPSmt_fClj5P8pww48zaymaRqZUB uSO7z5v_xjIRuoDAYLh1ndBHWXDJ7VlN9jvWHeVvdmvx6ObUqZ1b6dO3htahY3I79d2cbgJ43Ve4 XKoLe4teX7O5f9npQb_t8tYwFjuBQnh.xlvoWH5dcvG23YV0rknUxb.32lUu4UY9G41mlnyPpGvi fOOAyOgGRTMZp6HOBhynrIh9v3spozVZgEzXI0gmqRvIlpG1IM4uKUC4xzt4_vDPfjxvFFLxZAe6 HV0LcIDyd7QgAggTgmgQW4ePClYADnnpmnie9Hc7cTd8yCl4JJfWRRWuEuSCDcAnGWH8Sg08NWIi kumtGT_qWfZzHlgroJIf3Rdme8BUBYKnWJjtxytdxc93yMuAmarqHJ6FC1XePdiLzpHl8rroik4q s33mF9Rc0iSzQ.CUlneZH.UoABybpoQyU3F2ij1RCkja..k7tQZvU25nUKDFb7Sa1nL7C8IkSwAr G9GBHumuogXiSfcyBk_X6Nl5XQnVKRSShqJqyva9WTQrYXjoItJKlPZfFrWhpfhL2kz3nWcAFyM3 IemvcY60Q2V2mFo8Kl3bNv_KU4tDDj3PNxMqMYjSyYHb7NVdUi8aR6kr_QWzQ.8ycmpGrPgZIDe8 Sw2CQYRmdNwaAenY256Z_qZBQddIZ2i07SZawTnCj6Y8LYT31d3VdoldaCTyNlfPvVMDCwpQAlQ- - X-Sonic-MF: X-Sonic-ID: 85d56f6b-a88f-4876-9b3a-b8d8129fc10b Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.gq1.yahoo.com with HTTP; Thu, 11 Jan 2024 16:56:41 +0000 Received: by hermes--production-gq1-78d49cd6df-xzd4p (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 64258a18beda810145708262861cd0b3; Thu, 11 Jan 2024 16:56:39 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.300.61.1.2\)) Subject: Re: When will FreeBSD support RPI5? From: Mark Millard In-Reply-To: Date: Thu, 11 Jan 2024 08:56:28 -0800 Cc: Jesper Schmitz Mouridsen , John Kennedy , ykla , FreeBSD ARM List Content-Transfer-Encoding: quoted-printable Message-Id: References: <5a39810c-5fd8-4969-a222-2561b050b035@FreeBSD.org> To: Doug Rabson X-Mailer: Apple Mail (2.3774.300.61.1.2) X-Rspamd-Queue-Id: 4T9rRb2Jpzz4xDp X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] On Jan 11, 2024, at 08:20, Doug Rabson wrote: >> On Thu, 11 Jan 2024 at 01:30, Mark Millard wrote: >> (While I normally use FreeBSD's U-Boot type of context, >> My builds do have patches to allow RPi4B EDK2 use to >> avoid the problems that I know to test for.) >=20 > I'm curious how you were able to boot FreeBSD on rpi4 with EDK2 - I = tried with both the FreeBSD package as well as the latest release from = github. FreeBSD-14.0 stalled trying to initialise xhci while FreeBSD-15 = gets a little further but also hangs before reaching single user mode. = I'm wondering if perhaps I should use the dtbs from = sysutils/rpi-firmware rather than the ones from sysutils/edk2@rpi4. It has been a while since I last tested booting based on a EDK2-based release from https://github.com/pftf/RPi4/ . It looks like v1.35 is from 2023-Jun-05. At some point I'll (re?-)try it. I used the same style of having EDK2 on a microsd card and booting my normal USB3 media. The RPi4B is configured to first try the microsd card slot (usually empty for me) and then to try USB. I do set things up in EDK2 for serial console use as primary. (I only rarely connect video to the RPi*'s that I have access to. Mostly I ssh to them over ethernet and otherwise use the serial console.) I've access to RPi4B Rev 1.1, 1.4, and 1.5 examples, a mix of 4 GiByte and 8 GiByte. I've never used sysutils/edk2@rpi4 to boot as far as I remember. My EDK2 activity started long before that existed and I did not switch. The RPPi4B EDK2-based releases that I've used were from: https://github.com/pftf/RPi4/releases/ But there are many releases that I've never tried. I do use patches to avoid some reliability problems with USB file I/O . The reliability problems never interfered with booting and were only systematically reproducible via generating huge files. But the problems were originally notice via buildworld/buildkernel oddities that involved randomly corrupted files, but not many. The problems are FreeBSD bugs/incompletenesses in an area not used with most UEFI/ACPI contexts that FreeBSD supports. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Thu Jan 11 17:05:38 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4T9rf95BpDz56Tt8 for ; Thu, 11 Jan 2024 17:05:53 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (pdx.rh.CN85.dnsmgr.net [65.75.216.6]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4T9rf91NPQz4yGG for ; Thu, 11 Jan 2024 17:05:53 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Authentication-Results: mx1.freebsd.org; none Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id 40BH5c9R049569; Thu, 11 Jan 2024 09:05:38 -0800 (PST) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id 40BH5chO049568; Thu, 11 Jan 2024 09:05:38 -0800 (PST) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <202401111705.40BH5chO049568@gndrsh.dnsmgr.net> Subject: Re: dev/label/growfs_swap In-Reply-To: To: void Date: Thu, 11 Jan 2024 09:05:38 -0800 (PST) CC: freebsd-arm@FreeBSD.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 4T9rf91NPQz4yGG X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:10494, ipnet:65.75.216.0/23, country:US] > On Wed, Jan 10, 2024 at 05:39:44PM -0600, Mike Karels wrote: > > > >See growfs(7) (man 7 growfs). > > > > Mike > > aha! man 7 ok, got it TYVM :D Which you would find by running: man -k growfs -- Rod Grimes rgrimes@freebsd.org From nobody Thu Jan 11 18:09:11 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4T9t3b4dctz56cXc for ; Thu, 11 Jan 2024 18:09:31 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic307-55.consmr.mail.gq1.yahoo.com (sonic307-55.consmr.mail.gq1.yahoo.com [98.137.64.31]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4T9t3Z0bp6z58DW for ; Thu, 11 Jan 2024 18:09:30 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=uNW5E58Z; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.31 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1704996568; bh=1Jw0IwQ5n5hnyMpWZeQ2PLs1RAUPJt2LVlmCGhelHfA=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=uNW5E58ZIxTO7L6Gl79VlNQTVBdV9XzYbI0iptlpP2pkQfqO1Hh5Y9mWEMFHtXDGgZTe5pqrJYbvq8BG/5CeF6dv+GnFlWVCnoB0lOZSCKbi9/HRc6rzRinYaV5Gyq5Q1eARhWT5ZRJh6FgOXr/NzmLhyqFG5avoyZ/mIZtRE/AYtn8/XdS6fWF332bz+ZVimZCDIsZ/Bqbg7OyvbcbCs7QKnPaCODW/pxIKH5QFOhAt//GlyVPcCn+VIzDXI4AAAu4DfiJNpcyVh8aP+SxOIHSerRxYeDd60sACSotM+7AnwLtHWyzoANyx8CPUbNK4zUgcunq2nfCmGcwANfZAJw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1704996568; bh=S6HeURayjJ3VvmUGs+VduO2yuSQOrCWaEoGK00dypWe=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=IIiVhQckLcNfUL42OqjEAmFQyIIUNQOgud6djcTiIvejVwy3SUVDIf6IrdwrcHPMAHeMDrc7nwW8boI0lqa81m60nmGEWk0oDPyZQDw/awXgVMMsipW/z3dp8Hsm/Vsesu57ZcuC6LD+rdyP9iZdRTvxPcBRmWkxCe37IbsC/OdI6bRhX8Ch3XFqpxCYO6lsjTZ2SyW2YeG3oHHHf//RG5qS69welvIoS06p7uxNLllngr10NoQGXPLszAVoBIflafwdrQC5facCYn3JrqxsnMOp2q//mxntwoqH0zhC4nV46l/JKAtp0hulp7wYZYYmWIPAh/z/xAGRB1u8nn2Ohw== X-YMail-OSG: ODvSj8gVM1l2UTdaeoJyXAVn3m2cK6ZKE4.pOTA5rYNX2yjkzm8g8kHYbfEQQUa jcnabx717AEKr2U_LvkhInK23k3AZmZTQ60u0C8_Ss7jbXcke1ulw2qx.InLdx_P_KvyM39skn4A iqgvP.UI2aHC.EyMmKl1dQazd6EWMd5W0moinYXNpQZjmCPJL3g26xNRSNsTOCp7YqQ32Cnfs8uB FdO3hXD8zH_cI17lIdyh8YQ_X1DCZicaVwGRTTdlu6Zrj0Z30XzYhS1oAok9pnXkNhT93bLSxiSd zCf4VYVMXArCdABMTjkwLofMu1EeohA__HdZETgVqj8iKYQDbxfPNASB_e3vVlnTPaI3i_vDibrW 3Rv5BdIsesUnjtOhUVC7x5ZO1kjUveXlR0d1bI1vFvK9m9gdCpMpXXseFFOAOQajviPi61bfPBXZ JG.1q1o9Oo.O1.Wle8Yy6jxnvEZ7cQ_YqEB1A9vs4LIubnoJWoT7eCYwCnF8szXapYtfbg866XA2 nqDMaIDgWRsjEIJy9zxxiRd.t9VFqO6Nm_Tb6Mb6YMYtRTsvOHgwpjX3Uri8f2o.jPrej_e9mqaq sTONx2TX8qX2njGFlJz6Ilf7zAOQHqv3ObPPYBNuI5h10C209lg4jxzG370stvGN6U7dO4qUR89q PzM4WTme3QddCeni7PhE2LeCh_wKwTEamTMAQTrvIwRS78HnMCUh1tof1ZXLmNrvKkjsZXK29jDq ZkVvedkp9RV1Iepauhbk9uRa380kB2tdYMTV57r0Sn3XMB2vaJKxNoceNcquMUFxbCNwKmRf3Ywk p.rO8.qexpuIDNXIxXYmgfcOYLoqrIAXNhMkSrTU6JTaAhDUkVizZYKA7QtKUh5kf1605_uOim5F 7DcxA5u.w.gDi.5mD2.QbrM.Qbk9._EfgFwaMq5RC1dNGZ_vyqDVV6ji0UT5oQ0Fwx.1fJZ9bPmf h6OA.Alfee7LXCYnnzTw5UrgNg_Jth_Vhy4ZAsktUPILIx58CkoskPCQZFGzzt_1ese7BGKj0bCE e.eKsqYQ_7hYUTfAQmY6M9r8AkjHmdENC_C77OSn4WrcE2Jq8OvucjfjrO.rXufxCD9AFAo1pYKd 81uSxVTnoztO8NRb1Y_DtZryMk1sY4V9S2l177pXD4flyj9hf0nlRsuhCxosOgDBCDqDAXngiK0P DmTBj0ND58OsMabHaGmPclEcW8N6W8pzfsIaJWkm4ZsgbeB.6Im.I1UXI1Ce.1nO8nb8btA.8auF nmUQx_KP7ifF14Kj81l6dq09JbItz8o0ADSEPUB3FnIAvEw9rY6Sr7CSFwcTV5UgHwEaCD6joA3L oXgyMnAlh2YgIFny_etRF31J55agbXXQrbFCQZrkpAKlZuU.kmQ4sP9yB3GAFq6GaWmtVr6aLH7Z QJrURIsOWstBvfk4wPFuOsiwFwGRi5CJBT8zHXctAhH.EJhlLA5xewVlUB7I9dxXbCs7K4tJ7j4m SE6_HGljIYLSV4mbQxW_t6r.MJaKIJGSXNbiphKRteE.Y5ZkQlJuoYy2R5ctgjtaub889W0VkTN_ 9J9SyAk_tOksFy8jD_Acp70cVX41B.psCsvAMECMJbDs8ng3j9.QDd41N7B7IOVeQYFvt2mX8GYv h.KrHShP.Qdm508pS94cWZsurmj8FDCQ5mnnnPYd8D.AroBCQIQztscqLUEEnfV7XqvkT.wMTiQB 1hFs.F5Ugd4or.Zs5QOeqSbM9D2HyVKftxfPUAbeS4kwGFPw9k6_mvqNEFp0Y801uSHGYwIgZZGI RKqIMZ66.oXPEJGjYBkbgyb89I0OPAoL35asS44uUSBf9P1YSOTc1UYmRQLgTQglm7RJKwt7e5xW S4Erb.CZizPZWGaz_uRqrBjtl3wH1ZJXxLo1dMALXSJzAwm_Mt.AX4z_JcQVHKSeVHfh_mmFfguG No_1BrPji3KikCFTDkXKbptJeFuvsgaUVtSzLfuzDnrGPtkZY.iYE7QXTELclzMUTQwFL56Eutak mJOm_MwLCrdDgijlap3c0vblvVcU0matLvbvFsOfrb03.cYQAOQRHWaSP4OVLI_wgaBGt3.YTEpB 9YbRi9nQWLzzE5ONmdEe38L_LsBpVXljrknL4qpUHrTSKXHklP7uumOqIFKhgd1gH_hQfTSQdURk 1XULweKU3a.WPLLSc7vBm1M3XA2me7s2V0GSHVSrvVDwTXTonudRj0PZLSfBU9Kp5YnsRtrJaBsa tearVBUqtqVOwWfYbcEdAE4SO75JMUqhymylXF1g6llnz7OG1yKjx4pJdoaxPosJ0Eu_EfsH3Zdo - X-Sonic-MF: X-Sonic-ID: 9c2c31e0-d5e2-41d2-9924-034c8b0b07d7 Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.gq1.yahoo.com with HTTP; Thu, 11 Jan 2024 18:09:28 +0000 Received: by hermes--production-gq1-78d49cd6df-7zwgw (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID ef1e86d96e62f0eb9c40eb1f23ed2ca1; Thu, 11 Jan 2024 18:09:22 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.300.61.1.2\)) Subject: Re: When will FreeBSD support RPI5? From: Mark Millard In-Reply-To: Date: Thu, 11 Jan 2024 10:09:11 -0800 Cc: Jesper Schmitz Mouridsen , John Kennedy , ykla , FreeBSD ARM List Content-Transfer-Encoding: quoted-printable Message-Id: <347FE009-A470-4765-A9B9-7C9AB5E954DA@yahoo.com> References: <5a39810c-5fd8-4969-a222-2561b050b035@FreeBSD.org> To: Doug Rabson X-Mailer: Apple Mail (2.3774.300.61.1.2) X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.50 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.998]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; MV_CASE(0.50)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; TO_DN_ALL(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; FREEMAIL_CC(0.00)[freebsd.org,phouka.net,gmail.com]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; MIME_TRACE(0.00)[0:+]; FROM_HAS_DN(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.31:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.31:from]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_FIVE(0.00)[5] X-Rspamd-Queue-Id: 4T9t3Z0bp6z58DW On Jan 11, 2024, at 08:56, Mark Millard wrote: > On Jan 11, 2024, at 08:20, Doug Rabson wrote: >=20 >>> On Thu, 11 Jan 2024 at 01:30, Mark Millard = wrote: >>> (While I normally use FreeBSD's U-Boot type of context, >>> My builds do have patches to allow RPi4B EDK2 use to >>> avoid the problems that I know to test for.) >>=20 >> I'm curious how you were able to boot FreeBSD on rpi4 with EDK2 - I = tried with both the FreeBSD package as well as the latest release from = github. FreeBSD-14.0 stalled trying to initialise xhci while FreeBSD-15 = gets a little further but also hangs before reaching single user mode. = I'm wondering if perhaps I should use the dtbs from = sysutils/rpi-firmware rather than the ones from sysutils/edk2@rpi4. >=20 > It has been a while since I last tested booting based on > a EDK2-based release from https://github.com/pftf/RPi4/ . > It looks like v1.35 is from 2023-Jun-05. At some point > I'll (re?-)try it. >=20 > I used the same style of having EDK2 on a microsd card and > booting my normal USB3 media. The RPi4B is configured to > first try the microsd card slot (usually empty for me) and > then to try USB. I do set things up in EDK2 for serial > console use as primary. (I only rarely connect video to > the RPi*'s that I have access to. Mostly I ssh to them over > ethernet and otherwise use the serial console.) >=20 > I've access to RPi4B Rev 1.1, 1.4, and 1.5 examples, > a mix of 4 GiByte and 8 GiByte. >=20 > I've never used sysutils/edk2@rpi4 to boot as far as I > remember. My EDK2 activity started long before that > existed and I did not switch. >=20 > The RPPi4B EDK2-based releases that I've used were from: >=20 > https://github.com/pftf/RPi4/releases/ >=20 > But there are many releases that I've never tried. >=20 > I do use patches to avoid some reliability > problems with USB file I/O . The reliability > problems never interfered with booting and were > only systematically reproducible via generating huge > files. But the problems were originally notice via > buildworld/buildkernel oddities that involved > randomly corrupted files, but not many. The problems > are FreeBSD bugs/incompletenesses in an area not used > with most UEFI/ACPI contexts that FreeBSD supports. >=20 I found my v1.35 microsd card from the last time I tried. I had forgotten that the boot attempts now get a FreeBSD panic (seen via serial console use): panic: ram_attach: resource 5 failed to attach cpuid =3D 0 time =3D 1 KDB: stack backtrace: #0 0xffff00000050f450 at kdb_backtrace+0x58 #1 0xffff0000004ba930 at vpanic+0x19c #2 0xffff0000004ba790 at panic+0x44 #3 0xffff00000086e7c0 at ram_attach+0x1ac #4 0xffff0000004fba88 at device_attach+0x3f8 #5 0xffff0000004fdce8 at bus_generic_new_pass+0x120 #6 0xffff0000004fdc78 at bus_generic_new_pass+0xb0 #7 0xffff000000500450 at root_bus_configure+0x40 #8 0xffff00000042b600 at mi_startup+0xdc #9 0xffff0000000008ac at virtdone+0x70 It is a FreeBSD problem, not an EDK2 problem. My old notes on the lists about the FreeBSD problem are at: = https://lists.freebsd.org/archives/freebsd-current/2023-September/004775.h= tml I do not know if v1.34 might sidestep the mishandling in FreeBSD or not. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Thu Jan 11 19:09:04 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4T9vNN4nMwz56krQ for ; Thu, 11 Jan 2024 19:09:08 +0000 (UTC) (envelope-from quelrond@gmail.com) Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) (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 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4T9vNM6qJrz42H3 for ; Thu, 11 Jan 2024 19:09:07 +0000 (UTC) (envelope-from quelrond@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=LgCB+QFv; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of quelrond@gmail.com designates 2a00:1450:4864:20::334 as permitted sender) smtp.mailfrom=quelrond@gmail.com Received: by mail-wm1-x334.google.com with SMTP id 5b1f17b1804b1-40e5521dab6so23523115e9.1 for ; Thu, 11 Jan 2024 11:09:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1705000146; x=1705604946; darn=freebsd.org; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=4RIFzDKSg5BVM8QVVvtWymkgspl5i/Rinp8YhGs6lkU=; b=LgCB+QFvwqFY8s8w0RTncaq4IPQF083/ckEZLvHqn5R2nXX8VxJ9buWP4DOMoV1Tf2 3Mo+nWWcb47REqRQfZlEBWUGFcKkFRl46VxO44w+5fB3EJGxzhbVoWLScg1J/UR0/J4X oCyrLjHr4SZqFYaGWyEqbGPOVHGWTGYv/+Zx73bSxFv+cfJzY+HMOuCaGwKv4OAUoolG E/rBtYQYvd7p19gUEonPOoP1VhSHO+fpjl0W4K0L+Oq+7rfUnvM7gfqoYKbGShkr5+C1 0FosRZ3wrkue5yIk6QSYY3G1AV/DidTGWc3mlYBb4eBunkWINpJe2DanrkJlh/eR285t VheQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705000146; x=1705604946; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=4RIFzDKSg5BVM8QVVvtWymkgspl5i/Rinp8YhGs6lkU=; b=PoA6PnFVD67jtyA6dfmh1tflwGpegzkcV4nw2uAWredBba3UUV1ZbNtwqqOs9qiwMx t1mqF2J0bLwfmANAaMRgo8UxfvDMl7vYbJH+yY6C7bh8RY1WQTZrUntyeZxySmlBVeyh oAZdKxD66VvFT2e4dEAcmuP686iqeKURkL0OnsU8ezHew7j4jE33itouVAlYijOIUS6L qGjxbg1T925kT6/NwNtqd+yR+h2pZJz+R7IQyAkt5DfoWv7EpvF5VwN58CX2zMs8vXly Brvn81uEt9W9WKpxWglnp13I+nh1P3jgUzTDyh9ogWGSjewOXpVvSvK/vSyYZMSUF5wv MzQg== X-Gm-Message-State: AOJu0YyBuvKC+2Nz3ZFn9RiFDLVycSSqCGNuq1KJ6mxP5sSxAwSIJTKz WUUGtP38iPL8ezFq2WK/MFyRCTtM88U= X-Google-Smtp-Source: AGHT+IE4Bn7Pi0hIKSYDiqQv7ztzo/AHxndiqXRBbp2rDFAXqksxWLdgJ+AhyzFZWBDt5DOab50VRg== X-Received: by 2002:a05:600c:198c:b0:40e:623f:7701 with SMTP id t12-20020a05600c198c00b0040e623f7701mr191702wmq.35.1705000146134; Thu, 11 Jan 2024 11:09:06 -0800 (PST) Received: from [192.168.211.66] (85-31-109-70.netw.fr. [85.31.109.70]) by smtp.googlemail.com with ESMTPSA id je6-20020a05600c1f8600b0040d8d11bf63sm2975783wmb.41.2024.01.11.11.09.05 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 11 Jan 2024 11:09:05 -0800 (PST) Message-ID: <4a896a4e-cdb5-4351-ad29-8e014321f776@gmail.com> Date: Thu, 11 Jan 2024 20:09:04 +0100 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: free ARM VPS Content-Language: en-US To: freebsd-arm@freebsd.org References: <3a9870c3-e29c-4782-a148-57684d1f917d@gmx.at> From: Quelrond In-Reply-To: <3a9870c3-e29c-4782-a148-57684d1f917d@gmx.at> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.99 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; MIME_GOOD(-0.10)[text/plain]; XM_UA_NO_VERSION(0.01)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; RCPT_COUNT_ONE(0.00)[1]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; TO_DN_NONE(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::334:from] X-Rspamd-Queue-Id: 4T9vNM6qJrz42H3 Hello Robert , Thanks a lot for the hint! I've created an account at this cloud, I'm exploring the options they provide. But I cannot find any traces of FreeBSD here, only different versions of Linux. How did you deploy FreeBSD? Best regards, Peter On 11/01/2024 13:00, infoomatic wrote: > Hi list, > > While I am not afiliated with the vendor, I just want to give a little > hint to you, just in case it is not known: Oracle has a "always free" > tier with some services which are free to use. With the ARM Compute > Instance you can have Ampere A1 cores and up to 24GB RAM (in total), so > up to 4 free ARM VPS. > > I have used it for my small personal projects, and it works great with > FreeBSD, also the upgrade to FreeBSD 14 without problems. > > > Regards, > Robert > From nobody Thu Jan 11 20:12:15 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4T9wnJ19XNz56sDG for ; Thu, 11 Jan 2024 20:12:20 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (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 "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4T9wnH4f79z47lZ for ; Thu, 11 Jan 2024 20:12:19 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Authentication-Results: mx1.freebsd.org; none Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.17.1/8.15.2) with ESMTPS id 40BKCFg0010269 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 11 Jan 2024 12:12:16 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.17.1/8.15.2/Submit) id 40BKCFix010268; Thu, 11 Jan 2024 12:12:15 -0800 (PST) (envelope-from fbsd) Date: Thu, 11 Jan 2024 12:12:15 -0800 From: bob prohaska To: Mark Millard Cc: freebsd-arm@freebsd.org Subject: Re: USB-serial adapter suggestions needed Message-ID: References: <3012A549-9482-4D69-9DF4-7987E650DFFA@yahoo.com> <55AC6824-587D-4C67-B64B-2045A1112F69@yahoo.com> <041F74B4-3D44-4364-9EBD-9F21A4F3B313@yahoo.com> List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <041F74B4-3D44-4364-9EBD-9F21A4F3B313@yahoo.com> X-Rspamd-Queue-Id: 4T9wnH4f79z47lZ X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US] On Wed, Jan 10, 2024 at 09:34:00PM -0800, Mark Millard wrote: > > "&" creates background processes that are still killed when > their parent tty or controlling process goes away. nohup > avoids that kill. Not sure what's going on, but if I use make buildworld & on one of my RPi* hosts and log out or otherwise drop the connection, the job keeps going. Maybe use of tcsh? > > What was running on nemesis.zefox.com was its side of the > ssh that in turn was attached to the shell that in turn > was running tip --until those exited/were-killed on > nemesis.zefox.com . > > But there is no information here about which of those was the > one to start the failure on nemesis.zefox.com : > > A) Was it the tip process? > B) Was it the shell process? > C) Was it the nemesis.zefox.com side of the ssh? > I've put relevant excerpts from /var/log/messages from ns2.zefox.net (the console host) and nemesis.zefox.com (the terminal server) at http://www.zefox.net/~fbsd/tiptrouble/ They've been trimmed to the tip failure timeframe. There is a link to a copy of nemesis's sshd_debug.log file at http://nemesis.zefox.com/~bob/fbsd/sshd_debug.log The file seems too big to search interactively via a browser, but it might be possible to download it in one pass and then grep locally. For some reason it isn't timestamped in any way I recognize. > We only know that the end result was lack of anything > reading the pipe on nemesis.zefox.com : by then > the ssh side on nemesis.zefox.com had stopped being > set up to read the pipe. > > > Did you look at /var/logs/messages [or the analogous linux > place(s)] on "pi4 RasPiOS workstation"? What, if anything, did > such have from around the failure time frame? > > I tried, but the naming is very different from FreeBSD and I didn't recognize any obvious candidates. I'll look more later. Meanwhile, the non-ssh-mediated tip session from nemesis.zefox.com to ns2.zefox.net's console gpio pins remains up. Thanks for reading, and apologies for the cumbersome log file presentation. bob prohaska From nobody Thu Jan 11 20:24:37 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4T9x3z25wXz56tPT for ; Thu, 11 Jan 2024 20:25:03 +0000 (UTC) (envelope-from joseph@josephholsten.com) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (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 4T9x3y0Bmdz49cq for ; Thu, 11 Jan 2024 20:25:02 +0000 (UTC) (envelope-from joseph@josephholsten.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=pobox.com header.s=fm1 header.b=JnOHBtk0; dkim=pass header.d=messagingengine.com header.s=fm2 header.b="z fJq5p/"; dmarc=none; spf=pass (mx1.freebsd.org: domain of joseph@josephholsten.com designates 66.111.4.25 as permitted sender) smtp.mailfrom=joseph@josephholsten.com Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id C03605C0182 for ; Thu, 11 Jan 2024 15:24:59 -0500 (EST) Received: from imap49 ([10.202.2.99]) by compute4.internal (MEProxy); Thu, 11 Jan 2024 15:24:59 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pobox.com; h=cc :content-transfer-encoding:content-type:content-type:date:date :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1705004699; x=1705091099; bh=sSmYzVJ7hpSKQhGsS/4sFnIdYy0r6Hm31iTDB8Buaow=; b= JnOHBtk0DkigF4OurI45VDZzRJq0lQe8Etg/+pBO9hM1664EQZsYDIp63tgyRQX9 2E32PAgkfRruej88z1r9Je2GGxbpBRzsyEjxx50dlXDfetOfUF+AO0zjEZEFhjM4 yzBolahu/V2sp+vqz7vz6BQzAru19naBbEP7IT7GbL3FqJGTxZ52ZQurGGk7wWbs kTFqpt0Z+WSc9+9V/NLBp8T6/x1JGeOXutRF2MFkUhzc5ZYaGuSYMfo8iOtm1P7k g5xsjYvsQvbTxjq1OxvV7s1rebVdzhbxOoQTbronmcxI8qIbYKdQ9hhLfW3Ydvrr y8W4Gzt2nbhumRGJtt0Pnw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1705004699; x= 1705091099; bh=sSmYzVJ7hpSKQhGsS/4sFnIdYy0r6Hm31iTDB8Buaow=; b=z fJq5p/CnoHLNqDsxjuVFzd3YFuBHsRj3OGinms7HxPkvOlIJUMljgPcBAch1irfE 3i4W07e13ouU/eo7iBGv4cSjBL5cq0woXkLp6/3Ma7luZfQMMpuq2k18qrWt/mCE 6S/i2rGbdHkSLdz9HQ24hRQDGMDspCxjRZd7t4AdCVSUYfzpKNL2JZ7eAUqBXPvY wgTR4gazXz70T2Jip3Phb5kHw8P4EjSTHjkIbVdiBh1t9g5N9QgjWSi/yd4ASNfJ P+XgGhQdKTKr06aK72v77tYm1ESPzk1fluDfdhyCdc+pfIpSuyo/69Zov1aJEiJZ wiSrWfJ71WUYLpDTZrIvg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrvdeifedgudefgecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgfgse htqhertderreejnecuhfhrohhmpedflfhoshgvphhhucfjohhlshhtvghnfdcuoehjohhs vghphhesjhhoshgvphhhhhholhhsthgvnhdrtghomheqnecuggftrfgrthhtvghrnhephe fgveduheekleeiteegueetjedvkeevfeffieefgfevveejfefhgeeugfevieevnecuffho mhgrihhnpehjohhsvghphhhhohhlshhtvghnrdgtohhmnecuvehluhhsthgvrhfuihiivg eptdenucfrrghrrghmpehmrghilhhfrhhomhepjhhoshgvphhhsehjohhsvghphhhhohhl shhtvghnrdgtohhm X-ME-Proxy: Feedback-ID: i49d34368:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 6C1A415A0092; Thu, 11 Jan 2024 15:24:59 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.9.0-alpha0-1374-gc37f3abe3d-fm-20240102.001-gc37f3abe List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Message-Id: <876b9d58-6aba-460b-b972-0bd373936ca9@app.fastmail.com> In-Reply-To: <4a896a4e-cdb5-4351-ad29-8e014321f776@gmail.com> References: <3a9870c3-e29c-4782-a148-57684d1f917d@gmx.at> <4a896a4e-cdb5-4351-ad29-8e014321f776@gmail.com> Date: Thu, 11 Jan 2024 12:24:37 -0800 From: "Joseph Holsten" To: freebsd-arm@freebsd.org Subject: Re: free ARM VPS Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.69 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; DWL_DNSWL_LOW(-1.00)[pobox.com:dkim]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[pobox.com:s=fm1,messagingengine.com:s=fm2]; R_SPF_ALLOW(-0.20)[+ip4:66.111.4.25]; MIME_GOOD(-0.10)[text/plain]; RWL_MAILSPIKE_GOOD(-0.10)[66.111.4.25:from]; RCVD_IN_DNSWL_LOW(-0.10)[66.111.4.25:from]; XM_UA_NO_VERSION(0.01)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:19151, ipnet:66.111.4.0/24, country:US]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[messagingengine.com:dkim]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DMARC_NA(0.00)[josephholsten.com]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; RCVD_COUNT_THREE(0.00)[3]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[pobox.com:+,messagingengine.com:+] X-Rspamd-Queue-Id: 4T9x3y0Bmdz49cq There is a FreeBSD image in the =E2=80=9CMarketplace=E2=80=9D. There was= a mixup last fall and 14 isn=E2=80=99t up yet, but some foundation folk= s are actively working on it. If you use the official one, it=E2=80=99s = just a quick freebsd-update to get you there. If you have trouble with the service, feel free to yell at me. Juggling = support tickets and ops projects for Oracle Cloud Compute is my day job.= I use FreeBSD daily outside work, I want it not to suck. -- Joseph Holsten http://josephholsten.com mailto:joseph@josephholsten.com tel:+1-360-927-7234 On Thu, Jan 11, 2024, at 11:09, Quelrond wrote: > Hello Robert , > > Thanks a lot for the hint! > > I've created an account at this cloud, I'm exploring the options they=20 > provide. > > But I cannot find any traces of FreeBSD here, only different versions = of=20 > Linux. How did you deploy FreeBSD? > > Best regards, > > Peter > > > On 11/01/2024 13:00, infoomatic wrote: >> Hi list, >> >> While I am not afiliated with the vendor, I just want to give a little >> hint to you, just in case it is not known: Oracle has a "always free" >> tier with some services which are free to use. With the ARM Compute >> Instance you can have Ampere A1 cores and up to 24GB RAM (in total), = so >> up to 4 free ARM VPS. >> >> I have used it for my small personal projects, and it works great with >> FreeBSD, also the upgrade to FreeBSD 14 without problems. >> >> >> Regards, >> Robert >> From nobody Thu Jan 11 20:32:05 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4T9xDT3DFgz56v4q for ; Thu, 11 Jan 2024 20:32:25 +0000 (UTC) (envelope-from 4250.82.1d52500070a5b5a.e985dbda7992039dc7adae991cca3368@email-od.com) Received: from s1-b0c6.socketlabs.email-od.com (s1-b0c6.socketlabs.email-od.com [142.0.176.198]) (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 4T9xDS4hGKz4CbC for ; Thu, 11 Jan 2024 20:32:24 +0000 (UTC) (envelope-from 4250.82.1d52500070a5b5a.e985dbda7992039dc7adae991cca3368@email-od.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=email-od.com header.s=dkim header.b=vPVSIEOH; dmarc=none; spf=pass (mx1.freebsd.org: domain of 4250.82.1d52500070a5b5a.e985dbda7992039dc7adae991cca3368@email-od.com designates 142.0.176.198 as permitted sender) smtp.mailfrom=4250.82.1d52500070a5b5a.e985dbda7992039dc7adae991cca3368@email-od.com DKIM-Signature: v=1; a=rsa-sha256; d=email-od.com;i=@email-od.com;s=dkim; c=relaxed/relaxed; q=dns/txt; t=1705005145; x=1707597145; h=content-transfer-encoding:content-type:mime-version:references:in-reply-to:message-id:subject:to:from:date:x-thread-info:subject:to:from:cc:reply-to; bh=tQYvImkWyCeXlHRcuoBh0foNE9Qsghpz9aT5o36uQX8=; b=vPVSIEOHUm7uJ+cjbldY12PtcBQKeozwATKXmfgv4ClHzOA9zmelut3Dt9AXzXBmKqM10AIWUG+aixUlwt3Ih7Rg0XwbXx4Is3CAATLbQ+pF2vg8piDNWJSs6S8XQyFofVf3Nq7qNm37klvdKee/JRRPF69JY/Pq96plj/jglq8= X-Thread-Info: NDI1MC4xMi4xZDUyNTAwMDcwYTViNWEuZnJlZWJzZC1hcm09ZnJlZWJzZC5vcmc= Received: from r3.h.in.socketlabs.com (r3.h.in.socketlabs.com [142.0.180.13]) by mxsg2.email-od.com with ESMTP(version=Tls12 cipher=Aes256 bits=256); Thu, 11 Jan 2024 15:32:13 -0500 Received: from smtp.lan.sohara.org (EMTPY [185.202.17.215]) by r3.h.in.socketlabs.com with ESMTP(version=Tls12 cipher=Aes256 bits=256); Thu, 11 Jan 2024 15:32:10 -0500 Received: from [192.168.63.1] (helo=steve.lan.sohara.org) by smtp.lan.sohara.org with smtp (Exim 4.95 (FreeBSD)) (envelope-from ) id 1rO1if-0002l5-Pg for freebsd-arm@freebsd.org; Thu, 11 Jan 2024 20:32:05 +0000 Date: Thu, 11 Jan 2024 20:32:05 +0000 From: Steve O'Hara-Smith To: freebsd-arm@freebsd.org Subject: Re: USB-serial adapter suggestions needed Message-Id: <20240111203205.6d19a3d36c6c5c78e09e99d5@sohara.org> In-Reply-To: References: <3012A549-9482-4D69-9DF4-7987E650DFFA@yahoo.com> <55AC6824-587D-4C67-B64B-2045A1112F69@yahoo.com> <041F74B4-3D44-4364-9EBD-9F21A4F3B313@yahoo.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.1) X-Clacks-Overhead: "GNU Terry Pratchett" List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.68 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.98)[-0.983]; MV_CASE(0.50)[]; FORGED_SENDER(0.30)[steve@sohara.org,4250.82.1d52500070a5b5a.e985dbda7992039dc7adae991cca3368@email-od.com]; R_SPF_ALLOW(-0.20)[+ip4:142.0.176.0/20]; R_DKIM_ALLOW(-0.20)[email-od.com:s=dkim]; MIME_GOOD(-0.10)[text/plain]; RWL_MAILSPIKE_POSSIBLE(0.00)[142.0.176.198:from]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7381, ipnet:142.0.176.0/22, country:US]; DMARC_NA(0.00)[sohara.org]; RCVD_COUNT_THREE(0.00)[3]; DWL_DNSWL_NONE(0.00)[email-od.com:dkim]; FROM_NEQ_ENVFROM(0.00)[steve@sohara.org,4250.82.1d52500070a5b5a.e985dbda7992039dc7adae991cca3368@email-od.com]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; TO_DN_NONE(0.00)[]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; DKIM_TRACE(0.00)[email-od.com:+] X-Rspamd-Queue-Id: 4T9xDS4hGKz4CbC On Thu, 11 Jan 2024 12:12:15 -0800 bob prohaska wrote: > On Wed, Jan 10, 2024 at 09:34:00PM -0800, Mark Millard wrote: > > > > "&" creates background processes that are still killed when > > their parent tty or controlling process goes away. nohup > > avoids that kill. > > Not sure what's going on, but if I use > make buildworld & > on one of my RPi* hosts and log out or otherwise drop > the connection, the job keeps going. Maybe use of tcsh? It all depends on how the background process responds to receiving SIGHUP which is sent when the terminal session closes. The default action for SIGHUP is to exit but like most signals it can be trapped and a different action supplied. It seems that make ignores SIGHUP (I've never had cause to check), many daemon programs reload their configuration on receiving it. The nohup program catches the SIGHUP signals and ignores them shielding the child process it creates to run the command it's been given as arguments. It also redirects terminal output to nohup.out. -- Steve O'Hara-Smith From nobody Thu Jan 11 21:28:15 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4T9yTG0lGCz571n9 for ; Thu, 11 Jan 2024 21:28:34 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic305-21.consmr.mail.gq1.yahoo.com (sonic305-21.consmr.mail.gq1.yahoo.com [98.137.64.84]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4T9yTF5J2Gz4H7r for ; Thu, 11 Jan 2024 21:28:33 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1705008510; bh=CuChMBq6gAqH9wek0qGvUDKwT9m4zUVPgDIFNl6YkqY=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=ISq3+gFGhIX2NjVPXvg81RDmtyCcnEoyos5kI/9t8zPDx/fJ2mZMuQoSXynTDOSFhwjh3aYB+UX3/LjD5YIsxOK3uznbmBcNzO5fnwBWoFGDqoEk6PUWPpL3YzgnNKFgJAssD9FwwKzbhC6c16vm3UGD/u1m7rD4pPLTdcXxBcfnnjFqo2OrYNSgdhkWkjjxKIerM8zGrl43oknoJHu25zQvmVbuIykUgCxUKJ8ICA0rh4sx+ErVcx0dDKLb4ZtywenWnwL6tXV0ioGOkn/4G/DKgUhsqvXBDrR2dGsGUdWQMhklOSB7ygrHNk5Gor8vIHLAH6or3qZqvx8OYXzLfw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1705008510; bh=W6nU8lD+1vimwmnojPrgNuUM9IlmFUQvEU5eA1ZOWRa=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=H3ok6JPukEjsEI/zR0DhM7hn8/I97l23ebIdGsScvYI0a9HbqLvvHYdm9/W+2js6j4JMRG7YPBu3jE2VOREP/R1v/XxzUvTI+V6mztdueBeAOw40xTd/kTx/cszsmGISd1nf+lxUZeL4y8qId2DxsiwrZzCSkz4jR3g54S2LWaOjLmDBGKjXtPN6Z2Xa0F/i49He2r0ozHw505FNwmoAiTA/eM2hCVYB+8Qsyd9MxIKXPxuHgizjjCPGnTTBk58Yrg1xJrc8ocLsO2Bpp+SSkFdQpERV7Al0qU5i3o7Nmuz0scaReIK+QzfdshQIk6h06xmyXHSqiLZUDv2rhRMJDA== X-YMail-OSG: 59JvHP4VM1l6mso8XGBdd47VwLT8nnz.lNGok72Z7i2aHF7jy.XJLJVboADc8tz xrh4sllmhs0o.AFEkGM9xREEtUScgL9uM3Jh9XcwE1f0F8xajCN5KIOh.92wBONkYza7Gy2I6bFx DU2B7Okp.kBgIUdp_DZdhg.GJ7E82cJOBhywZZKJI5kfAC2y3EbMFj0EgkoKn6A2ATjuzNzE0hAd OLcNJn1jGH5IAwP0ycDMDqBanZb8y06t90Vz4RsU2EnsmnUJUgWfw7CMnvnSsL5ejGeTfGz5.GV9 g2sgLc6I.KbUu1eEGoydGARTThUfO7CHcgUKs7nePxAWpWgGBcTTJmMXRMLGA2d3CLHYmJUk7Kae Pe.fimsFLbf_J0QQVJD7NVc9iaIO2_vCfAxl0arOIGITWfHN2lFEU9PNcK5gLCDIHG4YTe6tQptt 0n.O.eAmPCICNfKJ_BrFqN8.OGNkMVvPXPIUcRLq07WUnoLAkAT9K0DKnnlYVitjbDao.0RjBO2f kI8mWUkG2IRQCep9u8ztZSWzkj9drazytZkKVunQaj8MGsKiZKgXbzb3tYKJAueD3g7.WqKeU95d Mo1ZmFW_UTc7QAnQM6WL19nrQM9IlS0f2Th868out27hOaBmSXp2TDVFTm69umJy36C9gkFZ2eBH S18MtMht37z0lS9O5JEdcQrchJFHFoPc8CSKcABUr7tVIejzpijU2VzhBVCrhdKV1QTo_vUsFQGV zA9QZVXlPnGdFAuPJs7SioQWv.EPhuCRamHvTA_RzmRPk4hmw9arJz5V7UJZaNzBc2mYZkfCfPXz GjpwBqrojtJ5bsWolmdgjnMzqix9yY1yR.E5ayQNPm4IwhIQgQUWJtz267HlUZnnKiwiHvqYXoZ3 hjAaGRS9wdPsqUq5aHfKDlBw.LxpkghhabvwRyeL..PSCp6tfGtUD2GiZ.0gtdnYLRHYNEIRm6_V OFVjVacdVbjh8wHmOk01iYXP8YO3EyBHyDyC4E1SMqmlUkNMvawvnMpdOnD3Bkm8GFQWu1qgAzWJ sTW0Rl23UUf5PaBLPddLwHh6vLE2Z8VF1L0L6jlr8OCJI5jEve.zcS.c6RLnehyuVNFara.16Zqd eZ3tVWaW6f3W.16j5S8pMn8Hd2pubf27a8CFfgAihn16Y5nGANbXbZMsPe5KMS06KY39j.W2N_bM sTRygEYes4qJpUyd3UGu8sA1iK6YtM.7Xi8ipVXD4WoBdRb7sNZQG576PtSBq_a57Z44b.NFL2Q. wRNA1bShNafiz5uVUD.O0IGLtLHyvli6GYJ0tp1i19LOcciLi.Itqi06LnsAdcLlkzDRQH8T3RBg poHlo.PhAD.mz32rnh1VlPTtmy_FYEjEs2FepvSWjUTREnvVoNZY_UBM1e6fiqqKch0zQQ2PEXSf QcpYBgBJjMj1YFY98VRaawCdoQikRur1fqoMgOR7fpLUL6CbP3np3hB997BaLaSNlojuQM2ppVtH vXHzzlz.TQjvHvFJjYU1cVKDPcv.Ut17khnrFuxEwHcs6Fyo6SjApUIYoAMxID9OqLRlKGD6ocbW nzpO2nGxz3ORnON1nUaXOBA.5ZJaAkZpxHI58Kt5PupuSlV4PFLCdLzpgF0BxnCuZSvhPU5z4B7d ajdm13sLT7y0kAmdCj_eTpdOz17u9zi78blLUQW42dS3n7ONPIWgCj_LOim5OdHFH6pyW._KXVdy xty8R90wUXBH9FsLNDEzWKsYV4mjmyzQtuDgYobok3UN4BCW6GDbo6QtnYAiAIjpXN4CJE1ezqIF 5PUgOr5dndbtl5UXAM.zhNWDvMNdM6dixnBwZu7SgGitHZsJ6ixRhvFT0iZP_LWXAdSbY5uDmv4r FTx4RFqSwWHS0743fB6e3ZM6kKjECp1WRub.2bGq4pmOQBgAvd7wP0Mk3kINPBXA8p5gE_ZUmjO0 naR5x85g43.wu4bxeoyaKCzve.qxhCHw5ijAG2.nS5DwjY6vfDHM44mHHhnRu2i8qwewNBAHhXSt QWOL2UHv9MdBMevN6BeanNlIvRV4KWKzcBtztivUanYLXFd_Xjx3ypeKVdSQqXX75S5gR77eP6Bi ITog9m6fFLN7TN1nBB7sqeia3F3ZJfj6VsP6UnRaIWj2KpXzXqgbzYDETTfPjd0UyeAqzQQu8BdR R9HjfVaHFbnq4FwT9aX1kkb4aBbNOW7fCYAKeIn0wP6d2Nd_igaDblBM5ebSqbdrKzFlvei5PvV6 PZIHadMo2_xOfEsOZzq38mrq3xfc7WRirxsLkfDNPHpHWWXIqd9BdWECJQQ98GJCJXOGRIjs5rWp 1 X-Sonic-MF: X-Sonic-ID: 3214cd37-0d47-416f-8a8b-88e5215a9d9e Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Thu, 11 Jan 2024 21:28:30 +0000 Received: by hermes--production-gq1-78d49cd6df-szbbq (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID de0f82d7810bc1e83359c9b5dcbff53d; Thu, 11 Jan 2024 21:28:26 +0000 (UTC) Content-Type: text/plain; charset=utf-8 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.300.61.1.2\)) Subject: Re: USB-serial adapter suggestions needed From: Mark Millard In-Reply-To: Date: Thu, 11 Jan 2024 13:28:15 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <902798B1-2B66-4ECD-BDAC-195C85066FE6@yahoo.com> References: <3012A549-9482-4D69-9DF4-7987E650DFFA@yahoo.com> <55AC6824-587D-4C67-B64B-2045A1112F69@yahoo.com> <041F74B4-3D44-4364-9EBD-9F21A4F3B313@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3774.300.61.1.2) X-Rspamd-Queue-Id: 4T9yTF5J2Gz4H7r X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] On Jan 11, 2024, at 12:12, bob prohaska wrote: > On Wed, Jan 10, 2024 at 09:34:00PM -0800, Mark Millard wrote: >>=20 >> "&" creates background processes that are still killed when >> their parent tty or controlling process goes away. nohup >> avoids that kill. >=20 > Not sure what's going on, but if I use=20 > make buildworld & > on one of my RPi* hosts and log out or otherwise drop > the connection, the job keeps going. Maybe use of tcsh? >=20 >>=20 >> What was running on nemesis.zefox.com was its side of the >> ssh that in turn was attached to the shell that in turn >> was running tip --until those exited/were-killed on >> nemesis.zefox.com . >>=20 >> But there is no information here about which of those was the >> one to start the failure on nemesis.zefox.com : >>=20 >> A) Was it the tip process? >> B) Was it the shell process? >> C) Was it the nemesis.zefox.com side of the ssh? >>=20 >=20 >=20 > I've put relevant excerpts from /var/log/messages from > ns2.zefox.net (the console host) and nemesis.zefox.com > (the terminal server) at > http://www.zefox.net/~fbsd/tiptrouble/ > They've been trimmed to the tip failure timeframe. Note the "ucom_close" and "ucom_shutdown" and "ucom_cfg_close" in: Jan 10 14:12:54 nemesis syslogd: last message repeated 1 times Jan 10 14:16:35 nemesis kernel: ucom_outwakeup: sc =3D = 0xffffa00002466088 Jan 10 14:16:35 nemesis kernel: ucom_get_data: cnt=3D1 Jan 10 14:16:35 nemesis kernel: ucom_get_data: cnt=3D0 Jan 10 14:16:35 nemesis kernel: ucom_inwakeup: tp=3D0xffffa00001979800 Jan 10 14:16:35 nemesis syslogd: last message repeated 1 times Jan 10 14:26:40 nemesis syslogd: last message repeated 1 times Jan 10 14:29:48 nemesis syslogd: last message repeated 3 times Jan 10 14:29:48 nemesis kernel: ucom_close: tp=3D0xffffa00001979800 Jan 10 14:29:48 nemesis kernel: ucom_shutdown:=20 Jan 10 14:29:48 nemesis kernel: ucom_dtr: onoff =3D 0 Jan 10 14:29:48 nemesis kernel: ucom_line_state: on=3D0x00, off=3D0x01 Jan 10 14:29:48 nemesis kernel: ucom_rts: onoff =3D 1 Jan 10 14:29:48 nemesis kernel: ucom_line_state: on=3D0x02, off=3D0x00 Jan 10 14:29:48 nemesis kernel: ucom_cfg_close:=20 Jan 10 15:04:07 nemesis su[35181]: bob to root on /dev/pts/4 Note the time frame vs. your reported: QUOTE Jan 10 13:14:06 ns2 sshd[48381]: fatal: Timeout before authentication = for 59.56.110.106 port 50300 Jan 10 13:34:34 ns2 sshd[926]: error: beginning MaxStartups throttling Jan 10 14:12:41 ns2 sshd[48506]: error: PAM: Authentication error for = illegal user shutdown from 185.11.61.234 FreeBSD/arm (ns2.zefox.net) (ttyu0) login: client_loop: send disconnect: Broken pipe bob@raspberrypi:~ $=20 END QUOTE Looks to me like something lead to ucom stopping on nemesis.zefox.com . The ns2.zefox.net shows: QUOTE Jan 10 14:12:41 ns2 sshd[48506]: error: PAM: Authentication error for = illegal user shutdown from 185.11.61.234 Jan 10 14:26:28 ns2 sshd[48524]: error: = Fssh_kex_exchange_identification: Connection closed by remote host Jan 10 14:43:28 ns2 sshd[48546]: error: PAM: Authentication error for = illegal user test from 85.209.11.226 Jan 10 15:14:29 ns2 sshd[48603]: error: kex protocol error: type 20 seq = 2 [preauth] Jan 10 15:14:29 ns2 sshd[48603]: error: kex protocol error: type 30 seq = 3 [preauth] END QUOTE It does not suggest ns2.zefox.net as starting the sequence. > There is a link to a copy of nemesis's sshd_debug.log file at > http://nemesis.zefox.com/~bob/fbsd/sshd_debug.log > The file seems too big to search interactively via a > browser, but it might be possible to download it in > one pass and then grep locally. For some reason it > isn't timestamped in any way I recognize.=20 >=20 >> We only know that the end result was lack of anything >> reading the pipe on nemesis.zefox.com : by then >> the ssh side on nemesis.zefox.com had stopped being >> set up to read the pipe. >>=20 >>=20 >> Did you look at /var/logs/messages [or the analogous linux >> place(s)] on "pi4 RasPiOS workstation"? What, if anything, did >> such have from around the failure time frame? >>=20 >>=20 > I tried, but the naming is very different from FreeBSD and I > didn't recognize any obvious candidates. I'll look more later. Looking around I found in: = https://askubuntu.com/questions/26237/difference-between-var-log-messages-= var-log-syslog-and-var-log-kern-log QUOTE 2020 update You may still stumble upon syslog; but the defaults have changed. journald has replaced syslog, in quite a big portion of systems, = including Ubuntu. This is relevant because you won't be finding /var/log/messages that = often anymore. journald doesn't write plaintext logs =E2=80=94 it uses = its own, compressed and partially authenticated format. Search online for e.g. journalctl cheatsheet, or just study man 8 = systemd-journald, man 1 journalctl yourself. Syslog and journald are, to a degree, cross-compatible; you can = transport logs between them in either direction. However, you won't get = plaintext logs a-la /var/log/messages with journald; and you won't get = structured (journalctl -o json-pretty) and authenticated logging with = syslog. END QUOTE > Meanwhile, the non-ssh-mediated tip session from=20 > nemesis.zefox.com to ns2.zefox.net's console gpio pins > remains up. >=20 Looks like the 110 MiByte or so file will take an hour or so to transfer from when I started it. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Thu Jan 11 22:51:47 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TB0Kd0sclz56j40 for ; Thu, 11 Jan 2024 22:52:05 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic307-8.consmr.mail.gq1.yahoo.com (sonic307-8.consmr.mail.gq1.yahoo.com [98.137.64.32]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4TB0Kc06FJz4Qcm for ; Thu, 11 Jan 2024 22:52:03 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=MvdZ43Fy; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.32 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1705013520; bh=YYI6cKFFATsaPe4vk874ayZDWukjpqTkqjczT3f8wxI=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=MvdZ43Fy6v4csf1VWQ5N8ABvFii/+kNlQbR3xB9tDn5Ty5nRl+dtEfWCLtt014RDdsF2u+3Od6rAVF5i5M8vXoFnS0C4Ou32huAaAUPbzBs1wWLuG+OY8KMmLpfLTJlTtWx1Az7wyxB9En9USyToU9r/SVi7EpjnwHWIno3aeF7oBa1z45EJwGnV4V4ZnFfEHTF2lBhSwxYNdHHvwbRuVsaxXzQjsupbTRDDQrCWLtF79lEWhpDjIbYj8sdfL+Mti4ej+WitI4ksTNOlk6Azg65xQWWp7fypccTcm0VKUI/u/hkYc58lypRRJi34f8bGcQK3ZJZneJgpAzDDRbyRFA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1705013520; bh=198UO23JNlqiiXuMsd1LUKvFySoxpN56LMnTX7vtJgX=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=ZGPgYUxHtCgXCrtEguUJsuiCoUQTxNbzP8C3lBXn+puTdsJwjAWlXff8dWDwpxQ3TndtJhiuFNx8CeYDCfS2XDy5kyanVZjK2YLqPwc/9MN9KbPZSAIATDeIy5VyA8iXnvy5+TiwZpVPyMD4owwPzA1ELZsw+HspsO/6MO3YGVu0OC/y93VS4hYlhqDnni1H0AH+thx9gXec3RrUkTZWY3kAHhvWNkJWspsAOpjA4dnC0UReFiJnnMsHflVOrqAH4F4s3ObsvomWY/AXvVh4Ii/nWQtfghVIsyVKQV/T12hJ1e+fuDBxHfCrGfx3ICYiOSNapI1RNCjbWRRQi1iQ9g== X-YMail-OSG: JVmCqckVM1nVH4VsMGuhN46e3Eiwqs9zVoyQgHDmAHuqwZ_OYq3UG2p4UUSHGwp _6n2YT1Ppi7MV2u_kN_tfqeTgLNEyhdENk4BDgWMeBDoN4_OSYeDcO2iomP0lR16Ix0wrcBYSH9G vS1D75G1vmGvrGGnzUsmH1reqP86JDOA18MrKARmpORbnwzUKU7i_eoB_hyfBFW2y0bd3QmEWQSu SUqGOsuHOg_ikAydSQkxDVxa08Nnc7F2w_A7dTlwPyTG2PO0zzctQZCpFkOxwl3qVRX3EUsO78K0 tesClJ8BtNAM6vj0xnwRfdv4Haek8hqQKMZwUvd_VC2OseS8xgpRCCo15MwftEAcOGNjoJfVzJDE 48Ag_smxfMKFo4Fkfs5w_Z1JNTHm_QPLG2oVVLnPMP.mYs.Yx78y8lc5OrOA3hOUDzFdplYpwCnE MdS.x6CRkbISu51PTVhKSRwY4IqNBVwkzyGuo2n5kNBsZ78KK1K3Wqe2C2a7EeGytqImT_gVdoJC jv4V6x083k7oyMaK5uRAqWBL6xGlq20Muq.YDhPRPJOiOk.Q2QjHl0n84so_djp91cHI6DdA2mXB n8Wzlfv_hV_uQomjuhivrWEBPiw3QL2j8lsdgfI9wkxk2HjaEWU3OY4WaAVBIRTppbMq_PpcTD.F SsbRckhWbgWeILgcCADkh.dEHSDGBIBOeOOb6edXdUQ07w81gsRmPQ15w6r7NNayGM4Tw9QUVouB e_nVjZYAec8TvelSr2TYfmvBhUJDeAxFRpk3z6_rz_wuMFtTelQDmyZ5flL_XIY3JbOMJdfMuthk h_3ZOvGkCC89bU7KI2rpsuOzlj.kZSJ10MQErhSQjNcnIx3D_MdNoQpFLeh41Xrd3gPDwk7qvM_u zSEMv4QpW2VZgsym3y30nmi1WYx3WmkG7gi7Fbh2sfu993uGBZFb.47v4PEt46H2WBH5MOuJD.26 p6kZKjeTzakoBxscEyAJd2TuQZorsnTSz0fC0Vuv2OEj5s36iTn1WGdtII1zht7qPLZ9qDYd2QIg 1HQn.iqk8b.4yV0xLqjYsm9uAtt4spN.AoYnut3oWGvCNdJiN5SXhkFfcCgDZ8m1NeZ.aqn2EwgT t27lfr7UMp6UYdKX6fvXjMAMUyLoEjTiwJcprnO1_f.lgnK_0ySAFtII1wZR.NwrrJDeDTstQ54c Z2TMULgUAyBFbzqKY97e.NTheMws6mtaIA_DGC8eM.Yw7ZdM1H1EEDOBUE7u4SCPMO6SsLhPejEl hwBsAenRU0i0i.tsWlGgQaCcD2_VJ0RPJlOmqAElX.lQbRWcTseOCvO_W_1z3AMofdeGmpjxRhgS 0evf7v72tzoHMdPQ9mop124Geqb1uRLvA8qw68p7B2AhVkG4wXm4PHpS_MQHvJLD1WggWhlGR9A. WvKK1dgcc62EB0C1fChAlMzbHNGmdzaaezcYB2fM0NIIHr8MFdpJbLGVzC_OPX73vLGIlT7XYhS4 CItFpzzh3waUTE_c_RI_s6Q63sY4Sn2.aOaIts.B4G7OCCE2kFjTSIkil5wrsDxjcQRfWT0kXrXe 8cV_sngdGdmhkzn_6bAB01NcEx1UHowzdRillq5jrNpwb064c2ozPTFbu4KM3rLc8MoWDKlx600_ WCrvKIH98ZzzlRQpMT0YGrXEWTBdUbkjcYk1NLFDxOS8TPrv1gHie4z.EyKclOp530vL5EKGJQLn yJkgwngz17RMO7ciehzNAwkdiDZbKMoTdnUkO5LD8NDXpT_6dizXpNi.7EKliMujd6oVANMPoBy6 0J0ujxZU3mGnUU11krFn5BUIc9Em4amM5BpmOuiONOp1JglgRDGJHA674twRPRAgrkvpG5yaXHc7 k9sfKo1arq83Dx3BNiDUzF7uZfxP3hjA3yBTvWs3k6COiO9IHWvNyla3VekqXdWnDtVR9sfp_ka2 2icNNjDkwkUzRUnEWk8_z_2g1CZYgBY5teI_fr5kgxmArcqhU5RcC_4FebDKq9WbHXu3XL84Wi1z tAgBWpLZ7t2503afG7ntMakPxeChC6vwH_NjZknQ3rqwnPtwX_2Yrj_AvDFnn.oPr13bazpMhFgx iDD4VImfVAckDb.DbZZwGx.uTMyzhFf__hy2jIj98jwXQWAGtNr3X9AdaDhQJObjqPjwpAO6.q6z 2QiEMX5B5jcP5SaX02T_fs.ncXUzo3ikiaSP1cj8YnGgJG0C6oIjQAcjfy20rtgGVpY6p6t2L9Wm 7nX4gO0bL4AFP.LjDaeZR_Kz5s3a_SwDctYN6V7aqeIak4VqRf3igQgCo_rfZosTlo0anmbnBmiy EdQ-- X-Sonic-MF: X-Sonic-ID: e754feef-7281-4775-ae95-425069f72ca6 Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.gq1.yahoo.com with HTTP; Thu, 11 Jan 2024 22:52:00 +0000 Received: by hermes--production-gq1-78d49cd6df-5s2z2 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID f4d5e941ee0c35d7f7ee8ccf6d820bec; Thu, 11 Jan 2024 22:51:57 +0000 (UTC) Content-Type: text/plain; charset=utf-8 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.300.61.1.2\)) Subject: Re: USB-serial adapter suggestions needed From: Mark Millard In-Reply-To: <902798B1-2B66-4ECD-BDAC-195C85066FE6@yahoo.com> Date: Thu, 11 Jan 2024 14:51:47 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <8B4C76B2-707E-4978-9CB3-5D547303A7E5@yahoo.com> References: <3012A549-9482-4D69-9DF4-7987E650DFFA@yahoo.com> <55AC6824-587D-4C67-B64B-2045A1112F69@yahoo.com> <041F74B4-3D44-4364-9EBD-9F21A4F3B313@yahoo.com> <902798B1-2B66-4ECD-BDAC-195C85066FE6@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3774.300.61.1.2) X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.49 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.986]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_TWO(0.00)[2]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; TO_DN_SOME(0.00)[]; ARC_NA(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; FREEMAIL_FROM(0.00)[yahoo.com]; FROM_HAS_DN(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.32:from]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.32:from] X-Rspamd-Queue-Id: 4TB0Kc06FJz4Qcm On Jan 11, 2024, at 13:28, Mark Millard wrote: > On Jan 11, 2024, at 12:12, bob prohaska wrote: >=20 >> On Wed, Jan 10, 2024 at 09:34:00PM -0800, Mark Millard wrote: >>>=20 >>> "&" creates background processes that are still killed when >>> their parent tty or controlling process goes away. nohup >>> avoids that kill. >>=20 >> Not sure what's going on, but if I use=20 >> make buildworld & >> on one of my RPi* hosts and log out or otherwise drop >> the connection, the job keeps going. Maybe use of tcsh? >>=20 >>>=20 >>> What was running on nemesis.zefox.com was its side of the >>> ssh that in turn was attached to the shell that in turn >>> was running tip --until those exited/were-killed on >>> nemesis.zefox.com . >>>=20 >>> But there is no information here about which of those was the >>> one to start the failure on nemesis.zefox.com : >>>=20 >>> A) Was it the tip process? >>> B) Was it the shell process? >>> C) Was it the nemesis.zefox.com side of the ssh? >>>=20 >>=20 >>=20 >> I've put relevant excerpts from /var/log/messages from >> ns2.zefox.net (the console host) and nemesis.zefox.com >> (the terminal server) at >> http://www.zefox.net/~fbsd/tiptrouble/ >> They've been trimmed to the tip failure timeframe. >=20 > Note the "ucom_close" and "ucom_shutdown" and "ucom_cfg_close" > in: >=20 > Jan 10 14:12:54 nemesis syslogd: last message repeated 1 times > Jan 10 14:16:35 nemesis kernel: ucom_outwakeup: sc =3D = 0xffffa00002466088 > Jan 10 14:16:35 nemesis kernel: ucom_get_data: cnt=3D1 > Jan 10 14:16:35 nemesis kernel: ucom_get_data: cnt=3D0 > Jan 10 14:16:35 nemesis kernel: ucom_inwakeup: tp=3D0xffffa00001979800 > Jan 10 14:16:35 nemesis syslogd: last message repeated 1 times > Jan 10 14:26:40 nemesis syslogd: last message repeated 1 times > Jan 10 14:29:48 nemesis syslogd: last message repeated 3 times > Jan 10 14:29:48 nemesis kernel: ucom_close: tp=3D0xffffa00001979800 > Jan 10 14:29:48 nemesis kernel: ucom_shutdown:=20 > Jan 10 14:29:48 nemesis kernel: ucom_dtr: onoff =3D 0 > Jan 10 14:29:48 nemesis kernel: ucom_line_state: on=3D0x00, off=3D0x01 > Jan 10 14:29:48 nemesis kernel: ucom_rts: onoff =3D 1 > Jan 10 14:29:48 nemesis kernel: ucom_line_state: on=3D0x02, off=3D0x00 > Jan 10 14:29:48 nemesis kernel: ucom_cfg_close:=20 > Jan 10 15:04:07 nemesis su[35181]: bob to root on /dev/pts/4 >=20 > Note the time frame vs. your reported: >=20 > QUOTE > Jan 10 13:14:06 ns2 sshd[48381]: fatal: Timeout before authentication = for 59.56.110.106 port 50300 > Jan 10 13:34:34 ns2 sshd[926]: error: beginning MaxStartups throttling > Jan 10 14:12:41 ns2 sshd[48506]: error: PAM: Authentication error for = illegal user shutdown from 185.11.61.234 >=20 >=20 > FreeBSD/arm (ns2.zefox.net) (ttyu0) >=20 > login: client_loop: send disconnect: Broken pipe > bob@raspberrypi:~ $=20 > END QUOTE >=20 > Looks to me like something lead to ucom stopping on > nemesis.zefox.com . >=20 > The ns2.zefox.net shows: >=20 > QUOTE > Jan 10 14:12:41 ns2 sshd[48506]: error: PAM: Authentication error for = illegal user shutdown from 185.11.61.234 > Jan 10 14:26:28 ns2 sshd[48524]: error: = Fssh_kex_exchange_identification: Connection closed by remote host > Jan 10 14:43:28 ns2 sshd[48546]: error: PAM: Authentication error for = illegal user test from 85.209.11.226 > Jan 10 15:14:29 ns2 sshd[48603]: error: kex protocol error: type 20 = seq 2 [preauth] > Jan 10 15:14:29 ns2 sshd[48603]: error: kex protocol error: type 30 = seq 3 [preauth] > END QUOTE >=20 > It does not suggest ns2.zefox.net as starting the sequence. >=20 >=20 >> There is a link to a copy of nemesis's sshd_debug.log file at >> http://nemesis.zefox.com/~bob/fbsd/sshd_debug.log >> The file seems too big to search interactively via a >> browser, but it might be possible to download it in >> one pass and then grep locally. For some reason it >> isn't timestamped in any way I recognize.=20 >>=20 >>> We only know that the end result was lack of anything >>> reading the pipe on nemesis.zefox.com : by then >>> the ssh side on nemesis.zefox.com had stopped being >>> set up to read the pipe. >>>=20 >>>=20 >>> Did you look at /var/logs/messages [or the analogous linux >>> place(s)] on "pi4 RasPiOS workstation"? What, if anything, did >>> such have from around the failure time frame? >>>=20 >>>=20 >> I tried, but the naming is very different from FreeBSD and I >> didn't recognize any obvious candidates. I'll look more later. >=20 > Looking around I found in: >=20 > = https://askubuntu.com/questions/26237/difference-between-var-log-messages-= var-log-syslog-and-var-log-kern-log >=20 > QUOTE > 2020 update >=20 > You may still stumble upon syslog; but the defaults have changed. > journald has replaced syslog, in quite a big portion of systems, = including Ubuntu. >=20 > This is relevant because you won't be finding /var/log/messages that = often anymore. journald doesn't write plaintext logs =E2=80=94 it uses = its own, compressed and partially authenticated format. >=20 > Search online for e.g. journalctl cheatsheet, or just study man 8 = systemd-journald, man 1 journalctl yourself. >=20 > Syslog and journald are, to a degree, cross-compatible; you can = transport logs between them in either direction. However, you won't get = plaintext logs a-la /var/log/messages with journald; and you won't get = structured (journalctl -o json-pretty) and authenticated logging with = syslog. > END QUOTE >=20 >> Meanwhile, the non-ssh-mediated tip session from=20 >> nemesis.zefox.com to ns2.zefox.net's console gpio pins >> remains up. >>=20 >=20 > Looks like the 110 MiByte or so file will take an hour > or so to transfer from when I started it. >=20 The big file does have exactly one example of: Fssh_send_error: write: Broken pipe (This ignores "Connection from " lines that report "Broken pipe".) =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Fri Jan 12 16:27:15 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TBRl60sH1z576xT for ; Fri, 12 Jan 2024 16:27:14 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (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 "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TBRl550NQz4Stw for ; Fri, 12 Jan 2024 16:27:13 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Authentication-Results: mx1.freebsd.org; none Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.17.1/8.15.2) with ESMTPS id 40CGRFYr016550 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 12 Jan 2024 08:27:15 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.17.1/8.15.2/Submit) id 40CGRFnA016549; Fri, 12 Jan 2024 08:27:15 -0800 (PST) (envelope-from fbsd) Date: Fri, 12 Jan 2024 08:27:15 -0800 From: bob prohaska To: Mark Millard Cc: freebsd-arm@freebsd.org Subject: Re: USB-serial adapter suggestions needed Message-ID: References: <3012A549-9482-4D69-9DF4-7987E650DFFA@yahoo.com> <55AC6824-587D-4C67-B64B-2045A1112F69@yahoo.com> <041F74B4-3D44-4364-9EBD-9F21A4F3B313@yahoo.com> <902798B1-2B66-4ECD-BDAC-195C85066FE6@yahoo.com> <8B4C76B2-707E-4978-9CB3-5D547303A7E5@yahoo.com> List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8B4C76B2-707E-4978-9CB3-5D547303A7E5@yahoo.com> X-Rspamd-Queue-Id: 4TBRl550NQz4Stw X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US] On Thu, Jan 11, 2024 at 02:51:47PM -0800, Mark Millard wrote: > >>> > >>> But there is no information here about which of those was the > >>> one to start the failure on nemesis.zefox.com : > >>> > >>> A) Was it the tip process? > >>> B) Was it the shell process? > >>> C) Was it the nemesis.zefox.com side of the ssh? It turns out that killing tip (using killall on the terminal server) does not disturb the ssh session. Both the ssh connection from workstation to terminal server and the su to root needed to run tip survive. I should apologize for not testing this sooner, it was a very easy experiment. If you think of useful variations please indicate them. The "invalid characters in banner" message still intrigue me. Might it be possible for output from tip to ssh inadvertently contain a ~. sequence in a direction that makes ssh or sshd disconnect? It does appear that what looks like console-to-terminal-server traffic is sometimes reflected back to the console as input, but only when tip is being started and not every time at that. Some help from the comp.sys.raspberry-pi newsgroup suggested trying journalctl -u ssh on the RPiOS workstation. It reports ssh server activity, essentially sshd startups at boot, but not client activity. I'll keep looking. Thanks for reading, and all your help! bob prohaska From nobody Fri Jan 12 17:25:52 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TBT2l67V2z57ClJ for ; Fri, 12 Jan 2024 17:25:51 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (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 "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TBT2k5NvWz4fH7 for ; Fri, 12 Jan 2024 17:25:50 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of fbsd@www.zefox.net has no SPF policy when checking 50.1.20.27) smtp.mailfrom=fbsd@www.zefox.net Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.17.1/8.15.2) with ESMTPS id 40CHPrkV016687 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 12 Jan 2024 09:25:53 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.17.1/8.15.2/Submit) id 40CHPrUk016686; Fri, 12 Jan 2024 09:25:53 -0800 (PST) (envelope-from fbsd) Date: Fri, 12 Jan 2024 09:25:52 -0800 From: bob prohaska To: Mark Millard Cc: freebsd-arm@freebsd.org Subject: Re: USB-serial adapter suggestions needed Message-ID: References: <7D27DF9F-AA9A-4D44-BC28-8CC637D0F550@yahoo.com> <3012A549-9482-4D69-9DF4-7987E650DFFA@yahoo.com> List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3012A549-9482-4D69-9DF4-7987E650DFFA@yahoo.com> X-Spamd-Bar: / X-Spamd-Result: default: False [-0.99 / 15.00]; AUTH_NA(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-0.98)[-0.977]; NEURAL_HAM_SHORT(-0.91)[-0.914]; MID_RHS_WWW(0.50)[]; WWW_DOT_DOMAIN(0.50)[]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_TWO(0.00)[2]; MISSING_XM_UA(0.00)[]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; RCVD_TLS_LAST(0.00)[]; TO_DN_SOME(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; FREEMAIL_TO(0.00)[yahoo.com]; RCVD_COUNT_TWO(0.00)[2]; DMARC_NA(0.00)[zefox.net]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; R_SPF_NA(0.00)[no SPF record] X-Rspamd-Queue-Id: 4TBT2k5NvWz4fH7 On Tue, Jan 09, 2024 at 05:03:42PM -0800, Mark Millard wrote: > > www.zefox.org is the aarch64 that is not configured in config.txt > in the normal aarch64 manor. As I've requested before, please test > using a config.txt that instead has: > > QUOTE > [all] > arm_64bit=1 > dtparam=audio=on,i2c_arm=on,spi=on > dtoverlay=mmc > dtoverlay=disable-bt > device_tree_address=0x4000 > kernel=u-boot.bin > > [pi4] > hdmi_safe=1 > armstub=armstub8-gic.bin > > # Local addition: > [all] > force_mac_address=b8:27:eb:71:46:4f > END QUOTE > > Please do not use a configuration based in part on armv7 FreeBSD > config.txt material any more for the testing activity: Just use > the FreeBSD normal aarch64 configuration with the force_mac_address > related material added at the end. > Just tried it now. The boot seems _extremely_ slow and invited at least some intervention (manually typing run bootcmd_usb0 at the u-boot prompt) but it did come up multi-user. It is able to function as a terminal server to nemesis.zefox.com, so I'll just watch it for a while. The netmap has been updated to reflect the change to config.txt. An aside, none of the seven hosts has dropped a tip session over the past day or so, except when taken down intentionally. > I want to know if this also fails when powerd is not in > use anywhere. > For now powerd is off on all FreeBSD hosts, the Pi4 workstation is running something called upowerd as always. I'm thinking to eventualy re-start powerd on only a subset of hosts in hope that will make behavioral differences more obvious. Thanks for your help! bob prohaska From nobody Fri Jan 12 18:34:11 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TBVYv51N7z565S2 for ; Fri, 12 Jan 2024 18:34:27 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic308-55.consmr.mail.gq1.yahoo.com (sonic308-55.consmr.mail.gq1.yahoo.com [98.137.68.31]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4TBVYv1Q8Tz40Kv for ; Fri, 12 Jan 2024 18:34:27 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1705084464; bh=EJZ3APOtgq64YqiU0nx0PardBtFKZwB3I5vgO2bKnR8=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=QFn4LE8knCfxMSXDco61FPKj1Zx9+CiXBv/CUGz6cAKkSpQRBPQkSeWMboS5SCyi8jWzhkhYtDTeCVY5KYZ4ApkqqHMrlDpvLCrM9uXkWCYcpkAgBK+OzzFHKIMSEX9fkxMLX8tyvLpXWzPvPFSMwqqYqbD/Mv7KJPUtvOs8QkTKZU3Ssah47FtASnicV422utwyAYDC8gd32b1xShBX3G5xXZsaVNesBtFGBIRO6QZmoXf9Sl6WB01HXaqMN2958VykOIjugrUjLK8GukjcY77MK11JRacH3AslOLmRxrY/ApL+v6lXizO830j6DwP8ZTUs2G8TwmU1w65AyLIqTQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1705084464; bh=QzghMcyCapTMTCLO8Up3k26NcR4izLKMCbbqlQrWsBZ=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=Czt+wYpyuEbRCcQxGX3qWem/f8BokcvDpbot9KLqyYiWQeYCoD9WBvjIHWoaJhcuCrzAa4GyO/N8AHPLP43dg40mSrDudNpoSEbGYkPbxW0eZv2OE4ShBnsTZX3o76OslkAvDXNnGRQAr/6uOjiMHVd2ufm3wOtJ889Zv2OouZT88Gz5HCdi8nL/hGcInL81jwsi+spSWFh3yO61GyMsk5JeIhMiipsFsA4/SowlT92qpDQjLOrOlWf7SmZmMcnbo5pYZtxtffUmKHNfxcRUnDLII9hr0Dmh0HKxJf7eU+oRC8MJhveL3ezKsrh244lGlkfpsFlsiFK5I5bMn35nGA== X-YMail-OSG: oIiLsRwVM1muZ9465Y3FBhEWSZvQeyx7kE67jTRvqs7y5ZVc6VFKeYeIDrsP5fD C4iDwcZFsY5qz1lirJjftOwvfCNjSoSmrLOSMNbYGG1LFpZpQXfMGQri2LkEhG_lybIEbkE1TVyw BYjSApUgE9Mf9lbt02Hwd0mC1tIE7hqvhZKzMSu7ptiL2TyA66gmjTv_9.xBKf4doL2X8BVzxrFK qc6rVsu_fuRFnfqx1qQcjeosxxc18mbodISYN9T9o9FOjS5usfJWOcu1AR1t8YVD3aqd4t.ZMDt7 YVcsY1NdVXdPYTQ3qEPdrCBlgQ11oVHxxjNGunB__7_yuF4WfWFXe585_IotqLxB5T3RcQ.FKtoQ cryLIgwQlJwa8vzZ7s8U7MCN8QDw24tql1jSHEM0SSb1FYq2RfWHsm7BNl1tWT0vtlojZRE27yEb gMXq8Gs_hwi5HEeQf7aUCWcugt4KT8eApgna.9dNnJnIlW1QKrF4b_h4_T3JkYBvTtVZRU_n9e3Y AaB0FHFkzmWrR0hXv6grC4Ojsu6uHZum9WGR6RvYeR7go.lpVVwxsJQHIEmv9tScRPfC7uGAflIZ 4mX9lGPcdV.4Zb3X80MjpoF27wd8z8tMNCs7h8506OflWRPib98P00J28jmNOJdoNzUNwfBDVHy0 AHTpYPG4QBis.5TFuHOXAzF63nWGB.3hmMhas9BCfM7TdrgiIzszzJrdRerNn2jmi6PMiP0f74Rg AUW8q5Y_NwtYoXO_0P8x3e.IvL1n2dwoR7az6iG2WEje2lHz_vx0xtgTW7_ENTFB5pu.gJssNiYK A.YiQiCi_jtMI8ZVBqOfKqCiUvPIxxc7ZSlcCVWxJc46KOQozwhiqk_Cmg7LCVPIYav66VvjDePJ VX8ueZfqq1HbFkGTPZWvU_A6H3B0_FNbpGyTvRBMXBLcqaQPawR4gZMF.GNhLNyrUC2CSlIp6M6t v53Ek6wKVpjU47IfCO1PN9LUoWbYc6MDNXhmf_pbPM9HVX.K9Q3HzZaVKqwbIC4PtCEvwlSShXzf 5rx8Dd7NxtNBO9ikHTLiG3yXtPmR1rY5jr8WVmJrpxB1iqdL15IANQKKYAMevcW0KbYQAS1uE3B1 bu9cqraaHwZKgzT5niNt6Kcm2BBej6JjDzIOood2nBiYwHFgpY0hBs71ot8JWXwbCAyBDQpP7Zco HywYXBE.u9TOncJOR70ab6rMBA2s8OlKPoSdUzLGJ1bb6qXwF.grjMzXjeAXyygBHaIU2IP_xQ3X oLpbxuPaZVdiwkBQIX.3C2ijKBnqwCFn.S2MOeMKPzAn0GadlU42RshoWjnpgX6D5MaC1WND41_V F.vha5w0CXvaQyiBct7WjYmajASZjrK8JPAxyjRvzvXm23vd0iLIjF42aZwOCVspw5hjMpY9ealn SPV3aMXrljE5oWMMYokqiBerQGaB_XufgZvczgO8Bgs4shPiKhUT4y4Cqv8Jw9zl7ImC1k8G6SXH _RZZw2K54YoYiMM6WXaXLVIWt3wWlBTEZtOxnj29i1Yyf8pAaBjG97i9n9WJz0GqFQqrP4AmESXe 3AwQQf.ouG2PGNJj6pvXkPR0x6RwvtwDDaUks69yJN0Klw9gRMrG2UZeyhdKcP6YL2Hk_wHSEfCo 1AtU101SI1j.PN_DIlxG8o7eObL1GEvUuAd4Y2EuBg85G6YYalSvfc2WzM4.VRyK1QPhkF.vHf6J a4AH8ZHVmuIihlWf__aOKP8myJq6CB90XlOFDOl2utV1Ck49FtX8_3Hjy.Aq.XHzzVEsS4gKUnw6 jaknlkH1A9p8YXQ.j2nNA5olUJTadrqJZzBjKF05KNmLFf.CQJog4KVWZfSAb7fGlKRWNpXu1jJm DaUJak7COmk5mMdej79PV37ek_RFba1vZTuvjZz2yIRjqE3HzSUlFok_gvC1MNaHTW45bfYxkoUJ Sp29m1vcUTj8YRqHGJRnmRWsoHtw9_.nk52fFJVLFsgQkTWGdF7ng5vylz9t.8OIME3f9RjTtLv8 msuREL0AIlkvodCVOF0H2NDQnIWzVSRIBag9Ii0M3Kevn.s0hav.so4DmVz8Nz5peq5G_j_6swlZ 2G7PdxcBVvf58fqzq3L8Jflg3o6nFvOfoA_402.ZhNwyG8vU7C_3ZaX93qSUCSP8o3Q8S0sXMjRf tcZlXwCJYBj8BWWvnzz6CyPPXSctnbLnmNtEBzCTGJ3bqhR9lP9Nk3wu2P0RQnwW.uEiQLVbE6Zu zAmzar.tKZ1TE4PgOZ3F82oO3bYBOF3cRCTO0v.Br5_7vMC3TNIJgdpnlS2zY_6B6g0SvM_118A- - X-Sonic-MF: X-Sonic-ID: e1b1a2d2-7251-45c1-97ae-ec5293464d45 Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.gq1.yahoo.com with HTTP; Fri, 12 Jan 2024 18:34:24 +0000 Received: by hermes--production-gq1-78d49cd6df-k96gh (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID ff6b35e08b8820fb2b2ddbf8e795112b; Fri, 12 Jan 2024 18:34:22 +0000 (UTC) Content-Type: text/plain; charset=utf-8 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.300.61.1.2\)) Subject: Re: USB-serial adapter suggestions needed From: Mark Millard In-Reply-To: Date: Fri, 12 Jan 2024 10:34:11 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <3012A549-9482-4D69-9DF4-7987E650DFFA@yahoo.com> <55AC6824-587D-4C67-B64B-2045A1112F69@yahoo.com> <041F74B4-3D44-4364-9EBD-9F21A4F3B313@yahoo.com> <902798B1-2B66-4ECD-BDAC-195C85066FE6@yahoo.com> <8B4C76B2-707E-4978-9CB3-5D547303A7E5@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3774.300.61.1.2) X-Rspamd-Queue-Id: 4TBVYv1Q8Tz40Kv X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] On Jan 12, 2024, at 08:27, bob prohaska wrote: > On Thu, Jan 11, 2024 at 02:51:47PM -0800, Mark Millard wrote: >>>>>=20 >>>>> But there is no information here about which of those was the >>>>> one to start the failure on nemesis.zefox.com : >>>>>=20 >>>>> A) Was it the tip process? >>>>> B) Was it the shell process? >>>>> C) Was it the nemesis.zefox.com side of the ssh? >=20 > It turns out that killing tip (using killall on the > terminal server) does not disturb the ssh session. DESCRIPTION The killall utility kills processes selected by name, as opposed to = the selection by PID as done by kill(1). By default, it will send a = TERM signal to all processes with a real UID identical to the caller of killall that match the name procname. The super-user is allowed to = kill any process. . . . -SIGNAL Send a different signal instead of the default TERM. = The signal may be specified either as a name (with or = without a leading =E2=80=9CSIG=E2=80=9D), or numerically. Which SIGNAL values did you try? Did you try -SIGHUP ? There are a bunch of signals that terminate the process(es) involved. The handling of each can be distinct: separate signal handlers are possible. =46rom man signal: Num Name Default Action Description 1 SIGHUP terminate process terminal line hangup 2 SIGINT terminate process interrupt program . . . 9 SIGKILL terminate process kill program . . . 13 SIGPIPE terminate process write on a pipe with no reader 14 SIGALRM terminate process real-time timer expired 15 SIGTERM terminate process software termination = signal . . . 24 SIGXCPU terminate process cpu time limit exceeded = (see setrlimit(2)) 25 SIGXFSZ terminate process file size limit = exceeded (see setrlimit(2)) 26 SIGVTALRM terminate process virtual time alarm (see setitimer(2)) 27 SIGPROF terminate process profiling timer alarm = (see setitimer(2)) . . . 30 SIGUSR1 terminate process User defined signal 1 31 SIGUSR2 terminate process User defined signal 2 32 SIGTHR terminate process thread interrupt 33 SIGLIBRT terminate process real-time library = interrupt If you did not specify the signal explicitly, you tried: 15 SIGTERM terminate process software termination = signal (I'm not claiming all those "terminate process" signals are likely to be involved. But SIGTERM is need not be involved at all.) > Both the ssh connection from workstation to terminal > server and the su to root needed to run tip survive. >=20 > I should apologize for not testing this sooner, it > was a very easy experiment. If you think of useful > variations please indicate them. See above, in particular SIGHUP . > The "invalid characters in banner" message still > intrigue me. Might it be possible for output from > tip to ssh inadvertently contain a ~. sequence in a > direction that makes ssh or sshd disconnect? I doubt ssh can be confused about where characters are coming from. > It does appear that what looks like console-to-terminal-server=20 > traffic is sometimes reflected back to the console as input,=20 > but only when tip is being started and not every time at that. =20 >=20 > Some help from the comp.sys.raspberry-pi newsgroup > suggested trying > journalctl -u ssh > on the RPiOS workstation. It reports ssh server activity, > essentially sshd startups at boot, but not client activity.=20 > I'll keep looking. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Fri Jan 12 18:44:41 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TBVnt3098z566kJ for ; Fri, 12 Jan 2024 18:44:50 +0000 (UTC) (envelope-from mike@karels.net) Received: from mail2.karels.net (mail2.karels.net [3.19.118.201]) (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 "freebsd", Issuer "freebsd" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TBVnr4mb2z444X for ; Fri, 12 Jan 2024 18:44:48 +0000 (UTC) (envelope-from mike@karels.net) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=karels.net header.s=mail2 header.b=jm8URKE9; dmarc=none; spf=pass (mx1.freebsd.org: domain of mike@karels.net designates 3.19.118.201 as permitted sender) smtp.mailfrom=mike@karels.net Received: from mail2.karels.net (localhost [IPv6:0:0:0:0:0:0:0:1]) by mail2.karels.net (8.17.1/8.17.1) with ESMTP id 40CIigt2065590 for ; Fri, 12 Jan 2024 12:44:42 -0600 (CST) (envelope-from mike@karels.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=karels.net; s=mail2; t=1705085082; bh=eC8jD0ceFRDbY9Lcwmtbro75ml4xEYsFRJfoOPDDa3s=; h=From:To:Subject:Date; b=jm8URKE92oPHFsfrOLlbIaGMmqnNCs84hCzwAtX1HM7iV9viGGfc9rQ139UCoAA3J FPypcZtBmHEfadqHT6JtzkIObrMitXpxO/N84IfgMR7ylTBii4QLRVYRjK/n5LcYFJ H3hR4hDp1QU+HE8lF/79GjsNoswdhKvI/3FE2vHsTAJ5YT4zGmS6BNlmoVdSTY8RId 8MtN/piDNPHejENhqrx3yTT1hd+RSHQtF/u1/2e8vhHkql+GxAme64LyWxcNjM8+D+ Ke1EQM8Bv438pcOZWSgaFluZh6xYqG5Lu8Z+6ljmyEaiGHC+x57ODgAvkXKiaHSkr9 rZ0xamxP/gDiw== Received: from [10.0.2.130] ([73.62.165.147]) by mail2.karels.net with ESMTPSA id GpS4HpqIoWU0AAEAs/W3XQ (envelope-from ) for ; Fri, 12 Jan 2024 12:44:42 -0600 From: Mike Karels To: freebsd-arm Subject: powerd enabled on RPI 15-current snapshots Date: Fri, 12 Jan 2024 12:44:41 -0600 X-Mailer: MailMate (1.14r6015) Message-ID: <277DAF5D-0CA7-4EBE-8018-91FBC0550FB1@karels.net> List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.50 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[karels.net:s=mail2]; R_SPF_ALLOW(-0.20)[+ip4:3.19.118.201]; MIME_GOOD(-0.10)[text/plain]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; FREEFALL_USER(0.00)[mike]; ASN(0.00)[asn:16509, ipnet:3.16.0.0/14, country:US]; MIME_TRACE(0.00)[0:+]; DMARC_NA(0.00)[karels.net]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_ALL(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; DKIM_TRACE(0.00)[karels.net:+] X-Rspamd-Queue-Id: 4TBVnr4mb2z444X powerd is now enabled by default on the 15-current RPI snapshot for this week, FreeBSD-15.0-CURRENT-arm64-aarch64-RPI-20240111-a61d2c7fbd3c-267507.img.xz. I encourage people to try it, and/or try enabling powerd on existing systems if it isn't yet (unless running full speed all the time, which is not the default). The change is simply to add powerd_enable="YES" to /etc/rc.conf, then run "service powerd start". The addition can be done with "sysrc powerd_enable=YES". I'm interested to hear about any problems in particular. I will add a RELNOTES entry about this, and any recommendations are welcomed. I plan to MFC this in about a month if experience is generally good. Mike From nobody Fri Jan 12 18:48:01 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TBVsv4YWwz566kX for ; Fri, 12 Jan 2024 18:48:19 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic317-20.consmr.mail.gq1.yahoo.com (sonic317-20.consmr.mail.gq1.yahoo.com [98.137.66.146]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4TBVsv0Ylsz44NY for ; Fri, 12 Jan 2024 18:48:19 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1705085297; bh=6Ojt+iGKdQJJM+Jc2w1l8E00RlaLh1A/n6f97uWl5Yg=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=dHyvwLozpmylXzQFYXn3SO8gs7yx8asY8QYDHjxzLZIniMTyJ0xu4cfWXNZStcb5Ib6EHeoxUSZApiOkvF2ly+4bAMV3+6FLN+mVpL8uQioHfUX2yHK9tqRNEe//JBjchgLS8U/HFmNflrboZTDniU4J2r4FgQ7Gu4vCuJGXQaAGqF7ptgFxNRZIHkAEepaM7eTdGN+PHireiV8ztSYiaJe3otClN44J4XHea/RLdiVW4mxLER0AwTAzvc8Lbz/WHqWaQiiw49Y6aINO8qCUnl7WqGMHAkaue+VxSbu7ndFNCI5VXUzdFqmVMXOjeaq9wa6t5+mn1vVBgDpev3FOJA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1705085297; bh=/ANOtd5c+GBAvD5CmeyK4EozPR5XMpIeEzqBJ1w2DEz=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=pzweK/mHFGREqLY9yxuYn3ZX8jhSD45UIOnQfkgfzhTABukObLmbK1FSPvbFKt3wUhs8OazKPBlwhuxbiy/RlupSVxhQwywq2F1es24GFGmmxfyS+KvMkHAf1z5UIR90Vkb2CSUHI1M+2WX+XFa9FXovHpDlZdV6YWhQxHa0bL9oQFnzl96Ayg6QHbPSnwSWFuoudrzzLc8BA+Da7vle3xXegmzuGeZoVqEcW0p0g4GeprQlyE0AgRMsUgWzlKn/MCKdandkVyzEYaqCPIuboYtrmGJEpVOq9RTHB8azhR6yWeqg5GN4Y9xn7/RJpQ0a9qYDrFA7/3VtTYbtWaU4eQ== X-YMail-OSG: TWHJ0RYVM1lPVkXgAbx8l7bZ1xBqJOdtmbuMkza9hHygOuebEN2qIvbpscagzv2 ga2P.CCwK6F0vibkoUXQSXOoDi2D4RB0Y03YAvoZbxbVh3j0Jd6_aMmZXMsALyMDmD9a.1HxBCMC HqxTO2ZoE75.y3jkrgZWi.va0.LkVKZEAWfnY3xf6xX339goIjOXaIMH0k.SbRqEPZtNQXa75t4T NN.2S48pzsDPU2J4LrGM_qSsqGCG4Z6CfYOZP1c8Vd1hvWfsUEJuzuJN7wDnjMtxI954sgrCKs6V KCnuVtI5JTHCTsIMYM03uBtRcHggX0U9Zzq2ILqvmtMysq1TlygnLk1ZpAlCsgM2emS7x4KPR_gh ABMThdHhwZOG2m9dVWBiIQhxF2SjuGOwMmqqQJdhckmg7X5ugQCtsNQTPVQ8boj9U5unqMAcFsl3 yr9INhO8Mc76YelYI8JNOqtczkc12zDS.mrM9VcXkLv0ijcBXw2qMnn4uudBri.h.fQboFtsgf3s 5SSNItH5P_juP_2lMyQobclJ9k66rx63Yvr.d_SzoaZWVT0ZmDaE22SiZj8WXJTOuAp8Itgecaw0 CXg_0CXtzNQZnd16M8eIu72LP1UB19nEZrvE.au_dQdEpuXni22BZzhyhOH9E_aucj0BU4Esk0KA 18bShzN2LNwOdOW6YbD5ath_3KevsnK.uH_jZAhi0ZdcmrDaVtKRIqU3.Izb0UepTJcz3fKEdfsm MHfWQoKO1gz.3Fy7RnZMKXDWuZSs6Wf6OhMVmMFa2YGS0vBlXmj9TnwwVk3RrWvq9ajZV8Dl1q5p X4B68VffWWYj6eoKhzm6EumEgecw0HT1A7OIaLh_UU1Wz7SHZkErhWdh4LB.5XOsFazd4.htK3iZ Oz1TJ3mFmArJi5T._tr.ybLVh25dCiHmFxoivxVKTLvytxpfyzcqV6Txp2BcXzpTVQ0FPoOTq5nw iqzdTb4E6AuO64isU0nBQzx5Rg435Cq6BHdRKQEDA4Qdemu7Nq7AWgsHnbusbxZQWFWJ_kvtHjOn NDQ.REbF.EO7avZFIVbLVJOVP1Ee42mbEJhC38zolU0XWx4Yfz9km.jf9GysfUcjx3j83rO1OsIi ygnB2nIbViYMFRV.MIkjV_3lxdzry3t9uNPWnDoia3ukxC9XSQxRNn1VtyfavhZ4eli0jCXjIdkZ AsI.T1zoyBPEG6Ie8puqBIHDHRoe8TmfX2a8OA5oE_QQIJH99libZ_SNWUDFuF23bNKGjaFl5IpV f4LF3opTDac.MAA2DsXvlE.uk2QDAB8y2rCEwoWD.NSidDufhF_WXrHn3KFcAQSSy6iU7pk0.nc9 uxRey9i7u0vhc3eJirN14.Zu.IBqK.1Xd2i8o2wnNhSrOBHEquV.mJkLkk73e39cdqFdw5wYchGs ES2OiJatORel_XDrfXBSWEoTXoUoBNO53PowuUrM5bJftb04ojizZ_7lnwbQMsiIpcBF_fuyO2uO mBr6feKAfrhb_980lKgikr9whqkmtLWSqNleCPfdJZyFd82.325.kA.OCpOMyxBFTUnmXm_bgkvC 3VcDxSQbpCeDtO.poO3o4EACnIjBVY97_KGZ0I8d0ngfYWDfvN6Tk5kHrgECVe1YWtQ6Lzlbzfbg 3tLHhAWqBpKmqPon3MTjwQmudVu51CldligaQ.c0f9F9ZjoH0qSNXt_JzqAqKQklbbTrqjZFgbvQ qymfjbJ3CwlLRmFB7DMqnd_Yla8kIhKpVbpfCnFCPtid9AtjaDcxMZv.e7CC7JssbM47g6YqIBsa NtTrsP5V8nXcqRIDTeDlhiDpB_rlILmUoPitI66klPFehlIGHPChA4j71g1F6ohCISeiBn9xPoWq JH0vRnHddpBsYK_gc67u1HTme.i_mswDObddOPCsNT4x567bvgsBih4YYTkXlSkExfOTxkqAGfTk AWlJyF3JR6uynlnY7URD1PXDemrrjDP36QpKj.cHxFAxYEyYeLiIEk8CQDMEqxwPBq.36uJbWAaH UlIWmjTkUxP2suOjVRc3PFDZY3R54N9fUs4YJJzSzPL.uz_SmeDSZvpw.OAzmmFz2d99nvOzTt2k gI1NeMwhBMuV4xkLHYio4laK3eviWjWyV35sS1tGKreYg9JLbU6KZraRRILO8yX6I53msVytOfID A4oRejcrbBVdoth65dqLMiubNU.R4j_CVYW4EK_G0e.TdBbAATI0yixNXQcjsVUqrMXUACF_8zQz qq2ua3XZc9e6b851GK5VdbT5uy2YRXTUbc2lCQGBIB59hBnnljS.flmQ8a3ZmBIrLk7mSi_r6 X-Sonic-MF: X-Sonic-ID: d074175c-59f0-4a06-a97e-5ba4708d86be Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Fri, 12 Jan 2024 18:48:17 +0000 Received: by hermes--production-gq1-78d49cd6df-mnx8f (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 731d5cbdaa2b0f2119f8378949550f80; Fri, 12 Jan 2024 18:48:12 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.300.61.1.2\)) Subject: Re: USB-serial adapter suggestions needed From: Mark Millard In-Reply-To: Date: Fri, 12 Jan 2024 10:48:01 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: 7bit Message-Id: References: <7D27DF9F-AA9A-4D44-BC28-8CC637D0F550@yahoo.com> <3012A549-9482-4D69-9DF4-7987E650DFFA@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3774.300.61.1.2) X-Rspamd-Queue-Id: 4TBVsv0Ylsz44NY X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] On Jan 12, 2024, at 09:25, bob prohaska wrote: > On Tue, Jan 09, 2024 at 05:03:42PM -0800, Mark Millard wrote: >> >> www.zefox.org is the aarch64 that is not configured in config.txt >> in the normal aarch64 manor. As I've requested before, please test >> using a config.txt that instead has: >> >> QUOTE >> [all] >> arm_64bit=1 >> dtparam=audio=on,i2c_arm=on,spi=on >> dtoverlay=mmc >> dtoverlay=disable-bt >> device_tree_address=0x4000 >> kernel=u-boot.bin >> >> [pi4] >> hdmi_safe=1 >> armstub=armstub8-gic.bin >> >> # Local addition: >> [all] >> force_mac_address=b8:27:eb:71:46:4f >> END QUOTE >> >> Please do not use a configuration based in part on armv7 FreeBSD >> config.txt material any more for the testing activity: Just use >> the FreeBSD normal aarch64 configuration with the force_mac_address >> related material added at the end. >> > > Just tried it now. The boot seems _extremely_ slow and invited > at least some intervention (manually typing run bootcmd_usb0 > at the u-boot prompt) but it did come up multi-user. The above seems odd to me. What version of U-Boot is in use? 2023.10 tries TFTP before USB in U-Boot and the timeout sequence totals to minutes. One can escape to the U-Boot> prompt early on and: U-Boot> bootefi bootmgr in order to avoid the TFTP attempt if you are using 2023.10 . I've not yet figured out how to have TFTP be tried only after USB by default. 2023.10 does this for both forms of config.txt . > It is able > to function as a terminal server to nemesis.zefox.com, so I'll > just watch it for a while. The netmap has been updated to reflect > the change to config.txt. > > An aside, none of the seven hosts has dropped a tip session over > the past day or so, except when taken down intentionally. > >> I want to know if this also fails when powerd is not in >> use anywhere. >> > > For now powerd is off on all FreeBSD hosts, the Pi4 workstation > is running something called upowerd as always. I'm thinking to > eventualy re-start powerd on only a subset of hosts in hope that > will make behavioral differences more obvious. === Mark Millard marklmi at yahoo.com From nobody Fri Jan 12 19:18:23 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TBWXZ2V6Sz569N3 for ; Fri, 12 Jan 2024 19:18:22 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (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 "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TBWXZ0r1wz49bc for ; Fri, 12 Jan 2024 19:18:21 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Authentication-Results: mx1.freebsd.org; none Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.17.1/8.15.2) with ESMTPS id 40CJIObC016968 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 12 Jan 2024 11:18:24 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.17.1/8.15.2/Submit) id 40CJIOZk016967; Fri, 12 Jan 2024 11:18:24 -0800 (PST) (envelope-from fbsd) Date: Fri, 12 Jan 2024 11:18:23 -0800 From: bob prohaska To: Mark Millard Cc: freebsd-arm@freebsd.org Subject: Re: USB-serial adapter suggestions needed Message-ID: References: <55AC6824-587D-4C67-B64B-2045A1112F69@yahoo.com> <041F74B4-3D44-4364-9EBD-9F21A4F3B313@yahoo.com> <902798B1-2B66-4ECD-BDAC-195C85066FE6@yahoo.com> <8B4C76B2-707E-4978-9CB3-5D547303A7E5@yahoo.com> List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4TBWXZ0r1wz49bc X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US] On Fri, Jan 12, 2024 at 10:34:11AM -0800, Mark Millard wrote: > > If you did not specify the signal explicitly, you tried: > > 15 SIGTERM terminate process software termination signal > > (I'm not claiming all those "terminate process" signals are > likely to be involved. But SIGTERM is need not be involved > at all.) > > > Both the ssh connection from workstation to terminal > > server and the su to root needed to run tip survive. > > > > I should apologize for not testing this sooner, it > > was a very easy experiment. If you think of useful > > variations please indicate them. > > See above, in particular SIGHUP . > Just tried SIGHUP several times. The ssh connection didn't disconnect. There were also no reports about overriding stale locks. Using SIGKILL reported: login: Killed root@nemesis:/home/bob # root@nemesis:/home/bob # tip ucom Stale lock on cuaU0 PID=45604... overriding. connected FreeBSD/arm (ns2.zefox.net) (ttyu0) but the ssh session and su survived. Finally, I tried SIGSTOP. Again, ssh and su stayed up, but restarting tip reported: all ports busy Power-cycling the usb-serial adpter with usbconfig isn't able to free the port. That's new-to-me behavior. Deleting the /dev/cuaU0-related files didn't help. Not sure what to make of this, except that ssh survives exit of tip, graceful or not. Thanks for reading! bob prohaska From nobody Fri Jan 12 20:03:53 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TBXY41vVgz56FJQ for ; Fri, 12 Jan 2024 20:03:52 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (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 "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TBXY35VyPz4GDF for ; Fri, 12 Jan 2024 20:03:51 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Authentication-Results: mx1.freebsd.org; none Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.17.1/8.15.2) with ESMTPS id 40CK3rKN017071 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 12 Jan 2024 12:03:54 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.17.1/8.15.2/Submit) id 40CK3rnf017070; Fri, 12 Jan 2024 12:03:53 -0800 (PST) (envelope-from fbsd) Date: Fri, 12 Jan 2024 12:03:53 -0800 From: bob prohaska To: Mark Millard Cc: freebsd-arm@freebsd.org Subject: Re: USB-serial adapter suggestions needed Message-ID: References: <7D27DF9F-AA9A-4D44-BC28-8CC637D0F550@yahoo.com> <3012A549-9482-4D69-9DF4-7987E650DFFA@yahoo.com> List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4TBXY35VyPz4GDF X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US] On Fri, Jan 12, 2024 at 10:48:01AM -0800, Mark Millard wrote: > On Jan 12, 2024, at 09:25, bob prohaska wrote: > > >> > >> Please do not use a configuration based in part on armv7 FreeBSD > >> config.txt material any more for the testing activity: Just use > >> the FreeBSD normal aarch64 configuration with the force_mac_address > >> related material added at the end. > >> > > > > Just tried it now. The boot seems _extremely_ slow and invited > > at least some intervention (manually typing run bootcmd_usb0 > > at the u-boot prompt) but it did come up multi-user. > > The above seems odd to me. What version of U-Boot is in use? Older, U-Boot 2022.04 (Oct 02 2022 - 23:00:31 +0000) It's possible the boot would have completed on its own had I kept my mitts off the keyboard. The loader boot delay countdown ticks seems slow by about 10X. That might explain the init_uart_clock=3000000 in the old config.txt. I should have said earlier that this particular Pi3 was configured to boot direct from USB, without a microSD card, but never would. I ended up using a bootcode.bin file alone on the DOS partition. I should probably pull the microSD card to see if the new config.txt changes that behavior. Thanks for writing! bob prohaska From nobody Fri Jan 12 20:32:45 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TBYBn1JXsz56JFm for ; Fri, 12 Jan 2024 20:33:05 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic305-21.consmr.mail.gq1.yahoo.com (sonic305-21.consmr.mail.gq1.yahoo.com [98.137.64.84]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4TBYBm5vD0z4MX9 for ; Fri, 12 Jan 2024 20:33:04 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1705091582; bh=tWpSGPovM8hZdGhRDcUuza29BhcccfPgC4Me2kL8SNU=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=Kv3DrAvtzp2bWrCr9fDfLxnho2hgIHFYIfsprqCyejGo1gjj+/nb6tyOVuzjLgFmy/sS7mFhkfsE8TdAR9SnOMEaxdid8xxuULAJmzpySyj0G2KZbl4x2aTF9MP7/v1mec4Ho8/bSuQFYXh42J4RnZr9ihZhqQoWMvkr/fRyB+9wPWkhdnuxke93aWt2zdgN7fikC9h6zmPHqnFJAQnJryjpb6H7UVsAgWZE/DIH2cpF4Yx7xiWbA1hqwSZAB+1d/2LR+ECUC1ZsXKD+uz9+sA8IhpHNr53i8jeR5tkVDU3S1LkslpVc8Z517h/IV04xIeIzp4dLQ/Uql6l2/5BuFw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1705091582; bh=A+oRXkxt2tjuN3j+ZRuRm8eevad7Yd6M2qme6vqsThG=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=a34ZjZsnGU0FqMMfgUH8u6DI/oRD0dVs8nJOAkHK6Yan9QEMpsq3GrEOWWhJfcBr0mpUPk/hyXiZg3w5k9d7gsINhGOibKEcOxkzZri311sz7r4Zd9x2C5Rqm1UdxVTKlLXFErdq0OMao17jgIf7+vdXB5opH2nFfgQRm9lQ1Pi7gkjWX2VaoBENwiZiONLflZxVg1nQFcklN5EcPuqBANCmo2SItkLbsXC7ER1VY1J90sJKbEq8dAc//cQOAAPeNo9+6r8ei6zZDtPmor6Aaqa0tqMsxQXRsx8kjNys0BKdNHXroOJEPvDd20eg8fPGF2Ndg5S4eDinEuDEzDiN1A== X-YMail-OSG: w1Zzm3wVM1nB6XMfP8juQfbjpqZFgY7oi7uRuLacL3S0CGjr1wy5k0VBHmo7MjD 3zEKsZq8IsCeJjSYmYLXOBRVWPuijPkqZvgHRakIKB_dkq.jjH.okiV1KWPJfR5Gj7iRdHujDzs2 HlV8DdmLa_ri49ZNnqhIR88Yk0bLyBZuVH3g3R7UV.8hBFFFcx1gPzqbsc4OxJ4s1DxURxHGxpxj 5EqpAnyTmRuc2UNJTNNMGrHwuP60fTQFwVHltk_V5IvkF_JQn61pDsH8AaUyfRB5PsCrgHFK899p MRpcBN_YJre8gPhzZNYrQTfXy0IV0Jsy25uOdtbdOisR.WRYk5wR3jfUuvpGmi3JKk0kMj.LZU48 _p2lQR78HLQjhKqLmV1VxoCAmTaz0_E2jsZpPR_U1UDtH9WHWCWQk7lB3fkr2MYHwziNQ2TsbRBG HCg6tSs9vOO2sDTsK5Rgpeki8Os1qTrLYDLdhNivphar5ZnjpB_oqGBvf2vfESe1hD2Srmze6jBJ ddMmgBcLavakVTRMrVsPAQ7ouQXOg3z7Wy5U4Z5zDWeA7jPKN8bh1xDvrPOwtK3Ff8XVokO87mnZ B4eioi2stCRnGQLqRsw1QxxWjoydn_D8GdaT6Dp5Sf08Bk7.ELkJsszaaKhHmfLnXhp_0e25ng.x 7fdkd_lz3dbMPmR7AiQuyrEQAqOpc709BC24vkXcyj0B7DVwabHVn3O5HZVuo8BaqazwyzywHHpx v5WEaheKRTbxdxTGBiEB5IkxoH6_um9.LZggzX_Ez4EQS.1EqUxwZWrLb1O_O2lwlgfxwngSqY3g tJwjcqLQahQ.iu.FSHyo5vUB5oRCgYoGEzm_t5o1D1vdv23uW54oMrxQKHZcIcuCY_YyBB_Wuqbp p81xs8OqfwQpIwc50wEjrdipBwDKG9bcd_AhK6S2tHjpHQnjrQ6lLAupRECbMENI7LdbOzkE0SLu WS8wvlJZlS01Ht6QjG2yXd34zN11rgkOmjNcVTuIXpFI8Mve2Lcy1xllh9GyPEa6fr6FcqKUjo5h fLicqQVECIfvB4VAINw1Q0St11B.MnB0PrFvKVcuCAkbl.7RNogLF6mdJZSkLKF8blByc3zYt9U0 yxOSOkxJZnR1KRywJ4HZ5QN.rpqr1Xl_.Z_qFfjpQLy8bxeLKJ8DlQgFwJONZd9flINCMxQxYBnH W0FO.l2yfSdXrxVuzRGXbq2UUhUoCmsOrsI_wfHqI7p4exsi4bsFqi5RJIy80p.ZtHE24ETTpUuq dqVMoi8cRK_xsV2P9CPLrzaRwrw1LbS2Ew.2gHK2eUQqPSTgtX8kE572xQhiNUcAxY1ZNTmQWw.r fZXCLJVlLQfKsifa63BSh4ZkQHVoxI_uC4lee7sJgok88X140TjpI3H_NlXSharu1o3eaL7zeXp9 6g1.CmDCz1kGraOMRYeb14JO.NFn99d38amdg0UVG6HNQ5cJQu8N1kSucwKCcO8NRyzXEAxBuNH_ .MjIe7EPTmPSJni6C21_qEAHMKqvN5eBWLKPgT2KXy.5zVQJDm14fIHRqq0Dvl5FUAYxJBf5F47C NQNAP68xchuzLQILZ8IInSZ7FDzVObtvx71xjQ9_SVZj5cyeX0LnSI9XE4weXpiVmrc7EG.FHMkZ KSaFbbLtbEbdOAvj.TsPoAL2GtLspicDMjqhyMgMcV9BGbJqALwXUB4W_ShGyqlgUI6FDyUQ1Vy2 kWqO_8JkufRbPMJG2jRBB4oVJXk_S9PXzYMLLyfokRsUcMhcjGWzyuWHaYa2ZvhayEaredygpqOD 9hAPrFmGaeT2gJUwdkELfSCjPT0n_HRlCVuPBcaNX4yh6raw9N4E_JJQH5qjtYgKV.GxwEn0SIfq TwiIgVVFj7BwjItJcAuIbwi3RNOm5QXOUV6PtfQN8g4XsyVGY7g1Hn1CR9mFe_d.TPUk2OLVuDAJ zY5UGtkmFJgMaEt4Fmxk57_EyVrD5GtClwqOLZrz0dWvXeuPjZWNPSMqq6Fcg2KPMWf4ViY_2cAc Uie4mTlhpSxXn5yw.VHnNIg7MYd672rRUfyVWePa4PiVGMze77vaIx30MzbqAagKp6.zKv4xXmgq KAj0zNd2T5q0YpINKhAB89Z1tGHFxt52UBmSW1Ev_j_N0.qnkqR45cAjAWo9.4u7wnF2h8zDIdM7 gnyUQdwsXJK0sRSZEXRjYyMYv48b5fEgqYw3580S0FJY_U6DXx3pE8.gmEOtw47Cv_InE2pnGuki 6iyelt4vitGPi7TG2ldKu3En0PQG.1Nf32x2nnnpXaW6WjVe3tcd69nZqvyDEdsAUaFdWiWcGFw- - X-Sonic-MF: X-Sonic-ID: 510a1958-4815-4a01-baf8-d1a8c7e9e6a2 Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Fri, 12 Jan 2024 20:33:02 +0000 Received: by hermes--production-gq1-78d49cd6df-hlpbq (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 0f7c658edb5e4e20cf22bb61e151521d; Fri, 12 Jan 2024 20:32:56 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.300.61.1.2\)) Subject: Re: USB-serial adapter suggestions needed From: Mark Millard In-Reply-To: Date: Fri, 12 Jan 2024 12:32:45 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: 7bit Message-Id: References: <7D27DF9F-AA9A-4D44-BC28-8CC637D0F550@yahoo.com> <3012A549-9482-4D69-9DF4-7987E650DFFA@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3774.300.61.1.2) X-Rspamd-Queue-Id: 4TBYBm5vD0z4MX9 X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] On Jan 12, 2024, at 12:03, bob prohaska wrote: > On Fri, Jan 12, 2024 at 10:48:01AM -0800, Mark Millard wrote: >> On Jan 12, 2024, at 09:25, bob prohaska wrote: >> >>>> >>>> Please do not use a configuration based in part on armv7 FreeBSD >>>> config.txt material any more for the testing activity: Just use >>>> the FreeBSD normal aarch64 configuration with the force_mac_address >>>> related material added at the end. >>>> >>> >>> Just tried it now. The boot seems _extremely_ slow and invited >>> at least some intervention (manually typing run bootcmd_usb0 >>> at the u-boot prompt) but it did come up multi-user. >> >> The above seems odd to me. What version of U-Boot is in use? > > Older, U-Boot 2022.04 (Oct 02 2022 - 23:00:31 +0000) Do all your aarch64 RPi*'s use that aarch64 U-Boot vintage? If not, it is another undocumented source of context variability. What vintage of EFI/BOOT/bootaa64.efi (in other words: what vintage of the FreeBSD loader for aarch64 contexts)? Are they all the same vintage? If not, it is another undocumented source of context variability. For armv7 systems: EFI/BOOT/bootarm.efi ? Going the other direction (earlier in the boot sequence): what vintage(s) of RPi* firmware? Are they all the same? If not, . . . > It's possible the boot would have completed on its own had > I kept my mitts off the keyboard. The loader boot delay > countdown ticks seems slow by about 10X. The FreeBSD loader starts after U-Boot is done. You wrote of forcing U-Boot to speed things up. I'm confused. There used to be notes around about the countdown rate being slow and what contributed to that, if I remember right. But I'm not sure I could find them any more and I do not remember any detail. > That might > explain the > init_uart_clock=3000000 > in the old config.txt. I doubt it. > I should have said earlier that this particular Pi3 was > configured to boot direct from USB, without a microSD > card, but never would. I ended up using a bootcode.bin > file alone on the DOS partition. On a microsd card, I presume. For the RPi3B, RPi2B v1.2, and RPi2B v1.1 I always use a microsd card with a modern bootcode.bin and a timeout file but otherwise boot from USB. That bootcode.bin handles more of the modern config.txt notation than what is built into the RPi3B, RPi2B v1.2, and RPi2B v1.1 does. There is other additional functionality as well, as I understand. (The RPi3B, RPi2B v1.2, and RPi2B v1.1 internal bootcode can not be updated, just avoided via the bootcode.bin on a microsd card.) > I should probably pull > the microSD card to see if the new config.txt changes > that behavior. For RPi3B, RPi2B v1.2, and RPi2B v1.1 (not RPi4B): I recommend using a microsd card with a modern bootcode.bin and, possibly, the timeout file. Using the older, internal bootcode is more likely to have problems vs. modern documentation/operation. === Mark Millard marklmi at yahoo.com From nobody Fri Jan 12 20:38:30 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TBYKN2ZPGz56J7j for ; Fri, 12 Jan 2024 20:38:48 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic304-25.consmr.mail.gq1.yahoo.com (sonic304-25.consmr.mail.gq1.yahoo.com [98.137.68.206]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4TBYKN09jJz4N2m for ; Fri, 12 Jan 2024 20:38:47 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1705091926; bh=nfg2Ve8x8DXtg101Vu0GSD9y9/TCUjgEx3E+eD729FQ=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=pVWIt4aL61ltzRuYhkezZJLG0gpqd5q6ybXPwq+DU0TGxJAw0uKAufO84YNNb7TX8/ppKtcYN34gT9snXIOBE+wfzU2pnfXq/lJJu0S77YK+VqwB3aSHIM5Rsny7+tc4lBsdf8YzDo7GvwVfwEmiAEeN2ZurQXhmCHitOvv/qne/llFW0tgGYCGc3zIpguP7gpDxXj1mK4HMDTURK10H08Ts8ummi2S6l8Ze7i8WwW6GJPi1KZBA5GSfoHPLOfEQlfoCyT2QUqvxx3NkJojnR62HjzAddZhDJndb40muyu2b/bjNP4jZioeArMOO2JDfKcsRiyLxcRizeAzdIG+Zew== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1705091926; bh=pvJhx+9O8mwNfUbU9tf8RWcXwlKQy92gSpLj7vHsj25=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=X0Qza7CUXm49ApJ6NDe6XrdQ9yJpJJRPOtlFmNteqQPxJuRYFVjW8RH8Tn6LNtrfeCk5/Hy3WGJ+XlQc05VUL4ArCYS80HhxDf7KMgOpUurYbMwlp+qcQT4UTqXKR35ETt49tCVn0gy0GSUMb9dNDX7isakJvq0L0M8QmZoPcFH1anU33Uei31OU9Dyhyp0O2xiNUmwbE5+vGei8Ct3ahFVQJ5ucDHwTCxhiCajMML8q0QWlyZ3WYThYxg9ZBKcZY+DP9ERcYymPSu4lJkuL1SvIODPwny9xd9F3uCWzBsgh93wkXJYpT+LY5XoWSQshauLWiPnnSqy+gAEMFreteg== X-YMail-OSG: 2gtTKXwVM1kstuZVXp9BhbeGLkqBGxN_ervJidrHi4vhudUbqHhU65j2Og47NUF NCwPeAHn4i05LTNgnfO_AB4SUOdc607zQnqk8M8d5OUccaXjlG5EtW0B_82p.1h127j0VSKWPMXw ZZ5n9dc0_zANFO6wIzP3CaDB9RZov1spAPmKS5bnRFe4P.BtdEkkIUr8b3aveHM61I7JodhFdhqh j6kSkzm8aK4VAhEDImHGNcEH1hjpZUyjiaNcJxdH7PcrjOkj4E9Qv3QrNASDCcEKR6zI7pGseYzV Hi8pAg3fjsdZVXcar59uuFS.i3l0afzrP4OQTF0o5DZG5Mr0EAu_uKeO3jGJFcQKJiWSw0abpCXi JXB97WHGcuTQV1PbB6lDZoHCo7ZVkT.FTlMRbvupq6oFwD8NqzF65Xqz8qKld4V86Z.kz0ZR9isb iHQ5ArriADlmeqFhR1l9aj2EUD05CJmKo7n9PEBFu4A8wLQPWoWCXvO.BNGuWWQ6HJhuKZOPGLbZ K4fCZoZhl2JsPURA8xqHIJljbQyGlZKTfltSh4wXVbTGPSgWpZw2Uq5AK5bBrdCAuZzYECdYP5MF 5p2zWuOwhOEmyKg2pyDV2JVjrKS9ody9a4LaQjoa.b_z0RfMOR7xDlUfIy2P6q37HkcOcO79M0BP d_5Mqjao4ryxh5rPmE6t1UI0khz7jxcddc1Eh7H4G.gAt7_EruUOeFABlvDtou.rf1EIJv0VAPKi RhVacS6qC1YX6oNqFPXLqT.JMVrMvY9ZJH14emXqxuN1HWNIFgAqNzKAChH8.DZc9JVT7VgiVWV7 GgbwmCMhhF_mxZ2E8K_X3mCnfG_gs5SRM1GT9xqqYbLmlL4Iow5EVpeAk6hNeYpiGIa0hT_EAvlJ 9nnwjAGqa.vR6ZcrPT2pT5Xw9QozLDTefat1ZSGtc5JqdelVPgs8Mpsgl61fCwTA6LWF4hH0DJAW suEqKhXN3H6Lvk5F.8afP4R.ZDMv_NrAel3tZdQGubeaIHjAm5e9CSnp5MhG0DXwAXGR5IwsHXoW XK2UlkV2g8wBrs3hlvmRKArjD.tIOF7htMEa70hwj.PyUVr0XWGXmwaFRlLbcMwrLDok.p5EnPXC nWsf.vKMnZKEoFfDsc6Hz0zXr1SzJX4NzoTMpGipGqjwwYnH6aE7XCqET_q8E2GyP25urtuURnNV ZnTj7A4wO2aMd8tgWh568LHD5h_fGzTnntM3M00fF6PIyLoojFI_d0n8S6G6yqV4ziEsTSjKYlTM 7c44y.a3BqXferghAe2o9pahhbCOfto1ZVQGP4Ivdvt7WFpoznRCsHuJjElHTlyfuWlVMYJW8bEf CEoXKruCopmSuyz.cYb5evBJD6TWRviC4kpRqomCOvfaN4nGwIRHPLtB99wWuQnzvfJ4Rgy6KJlv 7E6SW2iw4Rv5p_92eX5ncR8a0d0vw9ZFBRSoJssSJBQamElDcD244VODXIeGo.MVlzgJN3PHN9r6 T8ngKDEGd51JUmkPFswKAwhTGEJtDss2btToBEZGMcQylkoJqeQCQ4AxcXtmFNuBmEFnXQYGx356 elNf8pIG7e_pwn6MPI2xcNGv1OvSEp4UT69Cwfb6C1Nq01Ggiu_usSD0g37F6Gx.FF9.CPklBc39 1fycM.C5244h3nYufxJKk6H2KrE1aT2JRVIMCPehKre3yIttJpsvwnFjxf7Si3ZBFiWSQN1p1JAQ 1AF_Lm3x9ZK1h9zOTZwdlsXKAykylPelvW0GM.be.IMpbjDAhT.NrTAHQ9kgJv_VSSXS_FatfTqd nHyxDhGO30.Z_IUd6r4WLyn_u8oUJmGjk.SNmO.L.I86qyvHY98LEnq5YnmDaFwFnj1SR61ckg6h 05kngmCocvJCHeLRDhOZqHA8O9L7k5qxAqJgydwVFFUETTwjlZpTSBt.v1U2RBw0fRqt4LGembHN Rv9AS6Ab_4dGBJEEoUuP2SUR8fN_WvrmNHJTaYi5RTuz7gYX0REjqsqrjL.1Du029EMFV9pbSZRz ilJHT.SM.q_D9ycUaiPpUCwTIPay7Ie4f6rahRoZXswRhndDsdaJfXrswMvP8AV749IlZ69PKZqE bvNfaIHcMHOwUDc7zZidE4aCbkFS3OATeM3a5Ghn9VsTpmUh6FY3_25BRI_Z6zCteWMUgVN.uk.w ChoeOFxfD_rXjfxeozd0wZsRT9OOouFQaHfYjMd3YPdNf4E9AxUmtEKdPKBdOWDR9yg3PycRwSi6 u4OLYNobjzj9pY9TUOkzUTUb12mh.koPDidZvoB8_fcs.RdbsP9edPw.WLFn6DeWlAYGCHYkGlZA - X-Sonic-MF: X-Sonic-ID: b8cc48c6-8fa2-496b-b975-9c82a1f5046e Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Fri, 12 Jan 2024 20:38:46 +0000 Received: by hermes--production-gq1-78d49cd6df-vkd75 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 26219c72f027a4ab6d7c79e0b02260ce; Fri, 12 Jan 2024 20:38:41 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.300.61.1.2\)) Subject: Re: USB-serial adapter suggestions needed From: Mark Millard In-Reply-To: Date: Fri, 12 Jan 2024 12:38:30 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <482FA770-89E8-42E8-945E-B662AD564AFE@yahoo.com> References: <55AC6824-587D-4C67-B64B-2045A1112F69@yahoo.com> <041F74B4-3D44-4364-9EBD-9F21A4F3B313@yahoo.com> <902798B1-2B66-4ECD-BDAC-195C85066FE6@yahoo.com> <8B4C76B2-707E-4978-9CB3-5D547303A7E5@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3774.300.61.1.2) X-Rspamd-Queue-Id: 4TBYKN09jJz4N2m X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] On Jan 12, 2024, at 11:18, bob prohaska wrote: > On Fri, Jan 12, 2024 at 10:34:11AM -0800, Mark Millard wrote: >>=20 >> If you did not specify the signal explicitly, you tried: >>=20 >> 15 SIGTERM terminate process software termination = signal >>=20 >> (I'm not claiming all those "terminate process" signals are >> likely to be involved. But SIGTERM is need not be involved >> at all.) >>=20 >>> Both the ssh connection from workstation to terminal >>> server and the su to root needed to run tip survive. >>>=20 >>> I should apologize for not testing this sooner, it >>> was a very easy experiment. If you think of useful >>> variations please indicate them. >>=20 >> See above, in particular SIGHUP . >>=20 >=20 > Just tried SIGHUP several times. The ssh connection didn't > disconnect. There were also no reports about overriding stale > locks.=20 >=20 > Using SIGKILL reported: >=20 > login: Killed > root@nemesis:/home/bob #=20 > root@nemesis:/home/bob # tip ucom > Stale lock on cuaU0 PID=3D45604... overriding. > connected >=20 >=20 > FreeBSD/arm (ns2.zefox.net) (ttyu0) > but the ssh session and su survived. >=20 > Finally, I tried SIGSTOP. Again, ssh and su stayed up, but > restarting tip reported: > all ports busy > Power-cycling the usb-serial adpter with usbconfig > isn't able to free the port. That's new-to-me behavior. > Deleting the /dev/cuaU0-related files didn't help. >=20 > Not sure what to make of this, except that ssh survives > exit of tip, graceful or not. =20 Remember: Jan 10 14:29:48 nemesis kernel: ucom_close: tp=3D0xffffa00001979800 Jan 10 14:29:48 nemesis kernel: ucom_shutdown:=20 Jan 10 14:29:48 nemesis kernel: ucom_dtr: onoff =3D 0 Jan 10 14:29:48 nemesis kernel: ucom_line_state: on=3D0x00, off=3D0x01 Jan 10 14:29:48 nemesis kernel: ucom_rts: onoff =3D 1 Jan 10 14:29:48 nemesis kernel: ucom_line_state: on=3D0x02, off=3D0x00 Jan 10 14:29:48 nemesis kernel: ucom_cfg_close:=20 Jan 10 15:04:07 nemesis su[35181]: bob to root on /dev/pts/4 (and what was somewhat before and somewhat after)? What were those messages like (if any) for each of the types of kills? =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Fri Jan 12 21:37:52 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TBZdd15Cpz56QPB for ; Fri, 12 Jan 2024 21:37:57 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (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 "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TBZdc6BBkz4bBT for ; Fri, 12 Jan 2024 21:37:56 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Authentication-Results: mx1.freebsd.org; none Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.17.1/8.15.2) with ESMTPS id 40CLbrn0017326 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 12 Jan 2024 13:37:53 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.17.1/8.15.2/Submit) id 40CLbrk2017325; Fri, 12 Jan 2024 13:37:53 -0800 (PST) (envelope-from fbsd) Date: Fri, 12 Jan 2024 13:37:52 -0800 From: bob prohaska To: Mark Millard Cc: freebsd-arm@freebsd.org Subject: Re: USB-serial adapter suggestions needed Message-ID: References: <55AC6824-587D-4C67-B64B-2045A1112F69@yahoo.com> <041F74B4-3D44-4364-9EBD-9F21A4F3B313@yahoo.com> <902798B1-2B66-4ECD-BDAC-195C85066FE6@yahoo.com> <8B4C76B2-707E-4978-9CB3-5D547303A7E5@yahoo.com> <482FA770-89E8-42E8-945E-B662AD564AFE@yahoo.com> List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <482FA770-89E8-42E8-945E-B662AD564AFE@yahoo.com> X-Rspamd-Queue-Id: 4TBZdc6BBkz4bBT X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US] On Fri, Jan 12, 2024 at 12:38:30PM -0800, Mark Millard wrote: > On Jan 12, 2024, at 11:18, bob prohaska wrote: > > > On Fri, Jan 12, 2024 at 10:34:11AM -0800, Mark Millard wrote: > >> > >> If you did not specify the signal explicitly, you tried: > >> > >> 15 SIGTERM terminate process software termination signal > >> > >> (I'm not claiming all those "terminate process" signals are > >> likely to be involved. But SIGTERM is need not be involved > >> at all.) > >> > >>> Both the ssh connection from workstation to terminal > >>> server and the su to root needed to run tip survive. > >>> > >>> I should apologize for not testing this sooner, it > >>> was a very easy experiment. If you think of useful > >>> variations please indicate them. > >> > >> See above, in particular SIGHUP . > >> > > > > Just tried SIGHUP several times. The ssh connection didn't > > disconnect. There were also no reports about overriding stale > > locks. > > > > Using SIGKILL reported: > > > > login: Killed > > root@nemesis:/home/bob # > > root@nemesis:/home/bob # tip ucom > > Stale lock on cuaU0 PID=45604... overriding. > > connected > > > > > > FreeBSD/arm (ns2.zefox.net) (ttyu0) > > but the ssh session and su survived. > > > > Finally, I tried SIGSTOP. Again, ssh and su stayed up, but > > restarting tip reported: > > all ports busy > > Power-cycling the usb-serial adpter with usbconfig > > isn't able to free the port. That's new-to-me behavior. > > Deleting the /dev/cuaU0-related files didn't help. > > > > Not sure what to make of this, except that ssh survives > > exit of tip, graceful or not. > > Remember: > > Jan 10 14:29:48 nemesis kernel: ucom_close: tp=0xffffa00001979800 > Jan 10 14:29:48 nemesis kernel: ucom_shutdown: > Jan 10 14:29:48 nemesis kernel: ucom_dtr: onoff = 0 > Jan 10 14:29:48 nemesis kernel: ucom_line_state: on=0x00, off=0x01 > Jan 10 14:29:48 nemesis kernel: ucom_rts: onoff = 1 > Jan 10 14:29:48 nemesis kernel: ucom_line_state: on=0x02, off=0x00 > Jan 10 14:29:48 nemesis kernel: ucom_cfg_close: > Jan 10 15:04:07 nemesis su[35181]: bob to root on /dev/pts/4 > > (and what was somewhat before and somewhat after)? > > What were those messages like (if any) for each of the types of kills? Far as I can tell they're the same following ucom_shutdown. Preceeding ucom_shutdown it looks like the sequence of messages varies a little, but obvious things like the big hex numbers are clearly indentical. If you've got something in mind please tell me what it is and I'll be able to look more intelligently. Thanks for writing, bob prohaska From nobody Fri Jan 12 21:45:04 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TBZp90frWz56R0K for ; Fri, 12 Jan 2024 21:45:21 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic313-20.consmr.mail.gq1.yahoo.com (sonic313-20.consmr.mail.gq1.yahoo.com [98.137.65.83]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4TBZp85B5Gz4c3t for ; Fri, 12 Jan 2024 21:45:20 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1705095918; bh=WF36VVWLsU9+6CatS8Skq9uYCauQqQlocRTWZ0qT2Xo=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=jL6qQ2/8XurpOcCdpeeR3KOx96F/svoj0at/L2rB88kY7kX/eZOQI7iiyz7XyCgKW9XUXsS5ymAJKGKuhHYGGVovK4k+Q3nkhGjUsEafwlc/mUoRlDe5lXEhPTRElQ6UX8h8GS0TTDVRoMLeAP4nMhIhEWzHt6ECOm2AmV1QCf3jFXnhx54WdL+iyvAOiZ7m6KqduftyxR7SfupT3fprqL4m+lRQX/312GImmooNZCoR06tY6Wy1vCNmOaojlgy1F67Znb1nkQ4EyOPi8wyiyBTHc9qxmMo57+Z2fNyOZstngCZcMpAoecffaelmNurBesSxTsy0MaOiW8zzJGepWQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1705095918; bh=/zzoVB15v53sFq4CB1jkSjQDQA6E1qCr/MKyE5KPrvX=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=GOn0WZsV2LutEk6yhe+nr2iryZ10j0KAXku171pgNX+NgmL6f3EK7hLYNLNOAmfk4BHS6VxuHMOUdJn2fA4O9HYIs7lzGjssmSlmN6XqhmDVof9XLaQ2roDAJhK4hfI4cT+n8n+q/fZPF77dk8A7+bRp8PQAhDQeDwI44TykmM8Ukign4t0afYTZu3s9ae8WQ/+9x91NrRONwAIy5tae9HzYPxeE/SuuAU2+IBTonRCLAlh/8ttYEuky/FnubA+GkjvWcnC5W2vLWDZXrhPWVJ6BWqrO1Sgqb+qLQYiRhH53gE9HpsRMamZzZFEN3n1Qf2Y+GcvHIwtLWSzMG81/Ew== X-YMail-OSG: Hl6g50AVM1lK6MHzeCW6FTb1CdgMyBoAmWRjpWJhjVKIic.Q_.UprNXOdxD2UzJ 3JAZ.xULLIkj4IgF6gk64BqDObamHhNrWgopffnNafEx5oNrnaQTpO.RZxSt5X_pjZqb2m2BImNi k11cgxviVchzyov4KVDEtLkgk2vrpNfj7FKUqvLZG9eGWGNB4ePbEEChLrjL7W2srrSy8LIFBrVv h1nL6HLWRlSbsLXRZWiDUhS2PH.ok.CD9lghGjqB.XEcNBxmDagSZ1AZgMsQcYmYDXAzvOIHT7WS vYzLciblxgEjroApGE7lQz7oxHrwxVyQ7jre6tOGLN_xi_U_0TNSzblm6hsyjo6TWeto9JIFIep2 8laYhLp5deNuH.6VjkJ9t2O9qEpBANm6JP4eH74voHtcDD053bnkAYyfl_asuD7abauuJDxZ14in c_WVKh8VvsgnF8WuG0XZhC6xb077FjH.S5ddJb80jUkHBtylbCz6mrTrr_4P3bGZONPJJ2JcvPgj 2PnOy2mKsrEQUCjmGT9BP9Qw_X70.4JjmwPvI5QAMfaNOIjOv4Iof15Q05b6q1mXw8Hpdv7MV8Qj MsLxKHZmYzWmPrcwTyy2.yPEiT.KkAPFaWUrW65QHrizKu8jZ_zs3CTUGYtNoYWQGHUKAkBtum9R ZiabXesktCuTSU.ECyAE3EUDzanOokLJYQHRRIfngZ72n7wHPehOFJazCZCi4DBaQOEcKE8gtaFB 1xqVigiTT0Ywr9gb2Ja7Mc93MqDQbllZhNrfgI3oVVo_XOLm2W_Djr1toRdxXDFN248vSOCqoBFR lj8B5ioEENI9qgBiX.ofV0QHsqN0Ufc1DIs.SKHGPccTsuQL4HpBnRXP3kjCIb.mYn.TOys3d3NV 1_aTbI1h3aUT_GE2JRrrZw.16R.w4wz0ZME381tIrd9CWGQxjGWDFaKi3ZuqAcMrm.hWlhiQkJjo NBz8TuKdXIahbL5W9EcacoctogbI7Tfy1wa.PzCzQ2c386km6TYPaujmMy3in57ro2qncfw8C0jX EHws35337nnqUUxqbblZuwN.6MM4ITchqBOziqPRQRDAKyWzDCLW3oUcL1JY57wb0o8BBYayTuhf 8J_DTNe2A9mEeRk_ub25llffotJ.qCffqUrsFRF1z430MgUnOIbxfDmyw5dlOntrMGNz9Ei6yVEE AiWTfOkOm7sJxEVLkOC_6PAwvILfM8UGBIUYFhVpHWgAvJz47cW.C0orYSrzVnlxHXjoc5.kpF7I R0QHFOoMOKlonetsY8B8GJVhVxMRN73Zbmgp9uaP9KlTmyad_218Mw.QX3kEsK9h3DGgmQ99v3rb 1ldj7QifdM_br9h7V..iKdwAPLCItNqeqRUxbi6uxcYFHDHfvIL1AlaqMKynQul0JuyASs57uxZJ rzjYdRYAuAKLcpPvjiCFfpkGAsdUhv8fxGCFNKtz83K2o0.4OzvGERCJVNJmsx01sY1LJ2niIM0T CTC9.HAEOvFIUpPJTG.l3ntCH6yvJ3GJDQE7hV5E0b.SHtt9nq0vEKpf5B3Xui.3ZyVLXstAJvFE BBJV.0ldTTCaWrW.fidalO6p9Nc1lmQ6LiLt0ecIRppPwo0l0VL2DIAmO0FL01QG5cB.cKViUfTn sGJSY1w8Hb3mqYApitHoecR5gXHcdzH5_ZPQ5c3oAeDLPTFBF38EWX5Q.Xd8psg6zXdX0EaSFmes krDK51k1HHv8numT5CdMtaTNzxDcVMbrS9g6MgnNegYXe8.fCMWXqyTfZlWOYj9Ms3rk74qcDpnV AaNwMBMYGKMf0DzWiSGzScTcVB_3gcp.ksFL5UbUsB4bawto2wVFarqFoIBzGYwxp1SJhhQ3SGgt d0XLBucq9k.gOM7Vn78w1YWwX2hcSFGre_Vsqkxnd6BP6l2qvkHKsa4TWKrWzRqxQghczz89mhGP aFndGKcrdksHCFx0EGlCelpOQcEzuWpRqs4Ql5LVWWD2W9iq9mT9xwPjdCcv2sUJ22DV_kAC7clg P528XPhoDUBorEhWcJYGpM4gVHV_hfrItzeTvrAmvBPiEbPOjp4_XEIBTKm2EDSM6YDiOsXrV1ZK SWOdtX0wgYWQ7BAI39ZH3ckg1VpQ5PPtDm5eFzqXzkriIr5c8.CXRtTDa3Vnorm97TNr.vVQDJb8 72Lu0srGbay.TYAUGFlbzBJU_IDR9loGa7L9ZJuR6.09eCez1aX31b5W7UhVbCj8o.L_kEFToRt6 AEKaljMEKx.OjFjuV.AUjtQAN.CQBQme1bwRfDMKohPQmBXNRlzYkc50d4EH.jGVj1S1LO9g.LQa 5 X-Sonic-MF: X-Sonic-ID: de50ffcb-8469-421b-b6e3-f1b2a1927212 Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.gq1.yahoo.com with HTTP; Fri, 12 Jan 2024 21:45:18 +0000 Received: by hermes--production-gq1-78d49cd6df-c978w (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 098538181d25a4ff7fe4efa540757e2f; Fri, 12 Jan 2024 21:45:14 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.300.61.1.2\)) Subject: Re: USB-serial adapter suggestions needed From: Mark Millard In-Reply-To: Date: Fri, 12 Jan 2024 13:45:04 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <55AC6824-587D-4C67-B64B-2045A1112F69@yahoo.com> <041F74B4-3D44-4364-9EBD-9F21A4F3B313@yahoo.com> <902798B1-2B66-4ECD-BDAC-195C85066FE6@yahoo.com> <8B4C76B2-707E-4978-9CB3-5D547303A7E5@yahoo.com> <482FA770-89E8-42E8-945E-B662AD564AFE@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3774.300.61.1.2) X-Rspamd-Queue-Id: 4TBZp85B5Gz4c3t X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] On Jan 12, 2024, at 13:37, bob prohaska wrote: >=20 > On Fri, Jan 12, 2024 at 12:38:30PM -0800, Mark Millard wrote: >> On Jan 12, 2024, at 11:18, bob prohaska wrote: >>=20 >>> On Fri, Jan 12, 2024 at 10:34:11AM -0800, Mark Millard wrote: >>>>=20 >>>> If you did not specify the signal explicitly, you tried: >>>>=20 >>>> 15 SIGTERM terminate process software termination = signal >>>>=20 >>>> (I'm not claiming all those "terminate process" signals are >>>> likely to be involved. But SIGTERM is need not be involved >>>> at all.) >>>>=20 >>>>> Both the ssh connection from workstation to terminal >>>>> server and the su to root needed to run tip survive. >>>>>=20 >>>>> I should apologize for not testing this sooner, it >>>>> was a very easy experiment. If you think of useful >>>>> variations please indicate them. >>>>=20 >>>> See above, in particular SIGHUP . >>>>=20 >>>=20 >>> Just tried SIGHUP several times. The ssh connection didn't >>> disconnect. There were also no reports about overriding stale >>> locks.=20 >>>=20 >>> Using SIGKILL reported: >>>=20 >>> login: Killed >>> root@nemesis:/home/bob #=20 >>> root@nemesis:/home/bob # tip ucom >>> Stale lock on cuaU0 PID=3D45604... overriding. >>> connected >>>=20 >>>=20 >>> FreeBSD/arm (ns2.zefox.net) (ttyu0) >>> but the ssh session and su survived. >>>=20 >>> Finally, I tried SIGSTOP. Again, ssh and su stayed up, but >>> restarting tip reported: >>> all ports busy >>> Power-cycling the usb-serial adpter with usbconfig >>> isn't able to free the port. That's new-to-me behavior. >>> Deleting the /dev/cuaU0-related files didn't help. >>>=20 >>> Not sure what to make of this, except that ssh survives >>> exit of tip, graceful or not. =20 >>=20 >> Remember: >>=20 >> Jan 10 14:29:48 nemesis kernel: ucom_close: tp=3D0xffffa00001979800 >> Jan 10 14:29:48 nemesis kernel: ucom_shutdown:=20 >> Jan 10 14:29:48 nemesis kernel: ucom_dtr: onoff =3D 0 >> Jan 10 14:29:48 nemesis kernel: ucom_line_state: on=3D0x00, off=3D0x01 >> Jan 10 14:29:48 nemesis kernel: ucom_rts: onoff =3D 1 >> Jan 10 14:29:48 nemesis kernel: ucom_line_state: on=3D0x02, off=3D0x00 >> Jan 10 14:29:48 nemesis kernel: ucom_cfg_close:=20 >> Jan 10 15:04:07 nemesis su[35181]: bob to root on /dev/pts/4 >>=20 >> (and what was somewhat before and somewhat after)? >>=20 >> What were those messages like (if any) for each of the types of = kills? >=20 > Far as I can tell they're the same following ucom_shutdown.=20 > Preceeding ucom_shutdown it looks like the sequence of messages > varies a little, but obvious things like the big hex numbers > are clearly indentical.=20 >=20 > If you've got something in mind please tell me what it is and I'll=20 > be able to look more intelligently. So each of the signals result in a full ucom_close: tp=3D. . . . . . ucom_cfg_close: sequence? If yes, that answers my question. Otherwise I'd like to=20 see the variations. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Fri Jan 12 22:14:43 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TBbS14hrBz56W4g for ; Fri, 12 Jan 2024 22:14:41 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (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 "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TBbS11LMVz4lBK for ; Fri, 12 Jan 2024 22:14:41 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Authentication-Results: mx1.freebsd.org; none Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.17.1/8.15.2) with ESMTPS id 40CMEhAO017420 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 12 Jan 2024 14:14:44 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.17.1/8.15.2/Submit) id 40CMEhQN017419; Fri, 12 Jan 2024 14:14:43 -0800 (PST) (envelope-from fbsd) Date: Fri, 12 Jan 2024 14:14:43 -0800 From: bob prohaska To: Mark Millard Cc: freebsd-arm@freebsd.org Subject: Re: USB-serial adapter suggestions needed Message-ID: References: <041F74B4-3D44-4364-9EBD-9F21A4F3B313@yahoo.com> <902798B1-2B66-4ECD-BDAC-195C85066FE6@yahoo.com> <8B4C76B2-707E-4978-9CB3-5D547303A7E5@yahoo.com> <482FA770-89E8-42E8-945E-B662AD564AFE@yahoo.com> List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4TBbS11LMVz4lBK X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US] On Fri, Jan 12, 2024 at 01:45:04PM -0800, Mark Millard wrote: > > So each of the signals result in a full > > ucom_close: tp=. . . > . . . > ucom_cfg_close: > > sequence? Yes, that part seemed quite consistent. Here's an example Jan 12 10:47:43 nemesis kernel: ucom_param: sc = 0xffffa00002466088 Jan 12 10:47:43 nemesis kernel: ucom_ioctl: cmd = 0x8004667e Jan 12 10:47:43 nemesis kernel: ucom_ioctl: cmd = 0x8004667d Jan 12 10:47:43 nemesis kernel: ucom_get_data: cnt=0 Jan 12 10:47:44 nemesis kernel: ucom_outwakeup: sc = 0xffffa00002466088 Jan 12 10:47:44 nemesis kernel: ucom_get_data: cnt=1 Jan 12 10:47:44 nemesis kernel: ucom_get_data: cnt=0 Jan 12 10:47:44 nemesis kernel: ucom_inwakeup: tp=0xffffa00001979800 Jan 12 10:57:36 nemesis kernel: ucom_close: tp=0xffffa00001979800 Jan 12 10:57:36 nemesis kernel: ucom_shutdown: Jan 12 10:57:36 nemesis kernel: ucom_dtr: onoff = 0 Jan 12 10:57:36 nemesis kernel: ucom_line_state: on=0x00, off=0x01 Jan 12 10:57:36 nemesis kernel: ucom_rts: onoff = 1 Jan 12 10:57:36 nemesis kernel: ucom_line_state: on=0x02, off=0x00 Jan 12 10:57:36 nemesis kernel: ucom_cfg_close: Jan 12 10:57:44 nemesis kernel: ucom_open: tp = 0xffffa00001979800 Jan 12 10:57:44 nemesis kernel: ucom_cfg_open: Jan 12 10:57:44 nemesis kernel: ucom_dtr: onoff = 1 Jan 12 10:57:44 nemesis kernel: ucom_line_state: on=0x01, off=0x00 The lines before ucom_close... seemed to vary slightly in order but not content. My method was crude, to say the least, however. I just used vi to search a version of messages with all but lines containing ucom_ stripped out. There was nary a twitch in the lines following ucom_shutdown, some ordering changes in the lines above. Thanks for writing, bob prohaska > If yes, that answers my question. Otherwise I'd like to > see the variations. > > === > Mark Millard > marklmi at yahoo.com > > From nobody Fri Jan 12 22:34:45 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TBbvT2wX7z56XrS for ; Fri, 12 Jan 2024 22:35:01 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic307-8.consmr.mail.gq1.yahoo.com (sonic307-8.consmr.mail.gq1.yahoo.com [98.137.64.32]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4TBbvS31lnz4nZp for ; Fri, 12 Jan 2024 22:35:00 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=grlJJ5Wz; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.32 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1705098898; bh=T9S1mwR4sEA8juy5wEftKtXNAYeM4errrKRruCExBxQ=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=grlJJ5WzAcvPryp9t47ooXAfY7/aMinMoqmibJ13/bnfNe4MMkEczFGQoJu4R7k11ssq4WoW5hDDnsKCdqum8qo5Ot2jDUeiVczVrCokFW5HPUy4dUS4YvsE1wrlxvjJHwSxiTzLiGZJfCNlTsKpvLnwzsE9I1Te7RpJZbEf7pv7ctnkpAJJigZJdngrec7jApstWJR7oXS3bigKYv1lO4p6X7DUkZZsLRcbV/sPjkeJp2zHzZB8sbihQQq7oT9ORH6S0qExnpUCFkhd0y8FOnUGU7gbCdWlAJOtsOH2eeRe0m2muPkLVLm3QeaAmIAo9KRymC6s//NFIGI7XxsvZg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1705098898; bh=bkBsPupIPxiXnuSXtcOyhI3VUIs5+eKiUrQkAP/9HXO=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=NUbHFGMSChPv6LN6I+XYdID/V+G8gQlgacV83mTFVClNwr8/65yrHIWsB0QWJL7V+XZ0S9qrC+YPIZbXdjSr4Zi1mnfJFvhhvOqZMS1kjimt5N4gcTr4miJ3tNRDEPcS9c5GKM52JFp8Yfq71qw58dZWbu8XllHU61ZAk4SSpg6CuXdbRm142X3tg/0MGC4aebJcFddYyCbNf27cdInlDr4uqtid01Ou04xBc23WJzgJyadq5ow7F0DgWp2brENqRG87C8T+LNpLrzpFJZagHIK1sdu/+1RZhphPxK5Ss1xI3UrNSDM8WmGXk1RucOKQF12vVnzRxgFQ+/rqQyvMyA== X-YMail-OSG: eruMKBgVM1laA_B2k7q35av4LgDo24bVIU5SWJxdO20WnHu6C1f7F0XCsnShy3k UmaaZXOeuvi2SMAkXeodudR8eQEFuWv_bK1ZlEwUB_9aclJo7XvuBaIdFdEkjXRly4sRPLqJvbUP zjfy5srbKbsvpn6XojHw.r8Fshz7n8HfZVYtIFWoyaV9__pYP3RjjBiuBBMwFEcz5_Gni9UOiNm4 w0cq9q_afdrLK64UpgAuY6XpOAk79w1_4dCcYDGFF.KtvBSG1U7bKn6iaPDSJ4iBy9SXxrFBjB5S _pOB3EBH_SQp581m9oX6v4qyF3Epvxp8kQRKX0owocmRqiwpYqsSBIcH3paSAmElwmGJyXpWnLUs POVsUn1_bV59rnzaheHhfYRa4mvKk570kWWOM_hzdI8P9Ew0zGzSBnyf66pKithNugYFeIP32nKj x0g9fxIzVaVukaweMOw9eXo6Wwtc2hcW_7O99UxWr5oPtixi.QLMow5arkKLat7.QpofCYLxoprF HWIMWcHujWJ7mUQ6li8vxJECOkbiUs4Ez5CKmJDKemYJJVZUvS1Tv4_3PJicYFP_nlv18FyM5R3m 6lkbFenG97dUuynPpjK8JIFofTvj5bpDVn_ySdxtrFsub9wHMC1mZZXnErRU9GNrdRjKGqQrkAXI 3meo5r_QKHVMWQ6mpKcNIY1Jk6FcqKwFQe4ICXVGYyOS7x11mufHEtY..jpR179eSUndZ1Uic6I4 asiihzt7XSoCmAjaVYH2kkK0LPLzCYU7whq7uxk.IuxgHHXur8zeTWjwwmBnvmOTBcFJoJMYgJ3b aXaov.5dZPvfUjwT8y.F8DQJ2xE4Xj_CaPuZXAVvGNxLKR8yWT7Uot76mIhXbmSNwqtsRK4AstsU ELBVIwqWRCEVAhB2jhmMaf6Q8Vi2Vshn0D2nvW8JMI4.CpjKFOnWvREh9sx.NPqspOKIbgZgJiZX 7KeeZ6KjiUDbNi1iFDZWRA6qAVfzczJmuey0OykRjOupeAui1bL5HE6b0wyNChcE0Fl9G0qf2see ZrxKjN.eGvDec4KfFsyId3PhZGJfIAwgvAl32P3s8i7NYngHq9RfZ88doTabUXa5x9UxuWPVV6al fdh72F91M3X8LDS9_Y_pvphdc8zuWOOJhGpNXhg5ceNcN3sdBIq4IMZzMcR8IodaQtgkBEL9EBOg fM2s3xBa9xzdCFUTMR51Ae9KQtOf3rqK3tDeRmJFGosHJXft4Ztsjwo8smJhyFvtQdSy5iEdlmzi ujGNPdrOQOGQ5jbzNPbmTorvmwjSER88eRtHNbMrh8VSxk59_jdWgf7We945cIh22us_G6ep0dyo amYAul5JnMQv3BgbqPEMH9BF6EFQysoX0XKkv7R0Csd9VZ.x4HXWRXuJV0bwSfEA0yawIGf11dJF vGq6v3ONPNxcjGuGbdsKbxevwkJjngSb4c_SpjKdWLox.qybbqw0jW_ghcM7K6mjui8LvrrQtJ4H aXFd329DAIiQigRH_cmxgZuWrcl.lhCusvv5Exdm58faGBwccf2WmQWLJ5E9lPTusc8KYC4v4dww cCpHva..tp7bdmdBNwJHaAX_Q3bPpzvPOJbI.w1yQKadSi96ojT1MOpzFLFnd2YJp2.WRWQrTOi_ udF09yBuz8_TvB7XOkp047ecMHVESkX1qfME0sJKUrbVeMK.4VND_QB55GpTt_voxKRZDYBU7YZn sMtEtLUA_H51Tc1c7gYWbz63wGtCL7IKodz0vxr_7hl27qXNAFJcAdRA34mK2s6mOdptcSAihv05 egWhQIf0sDS_5OXnff6j9uSWqYCKKUJcuUsN5iNncfiM0iKWmb6By0u8F5Bb83M96DM4UKgZypwI EjpUIBCqLfvDCfGmdRowIi6ihpYxCa9OGS_CgCaH85s_YdrbF6.3Ee4qObTo4gGEfre3O7VD6bhz TXxw3gqzN1AHhKaj5Fwhv4hTL2.TpiscXM.tLUPqdPgXeFGVkKn2kcMpvBoXi6QZ6odIn1Hr8iIH LRtEh0cZ9Va.f.J6vXVUW1WARr0dCWLr8FQdb8p.jlY.BJUQtJ7cI7byAriU2ea1lG5SMz1CTCOr 7WmFGYc2SIvEwt.4zNT1dvV8XuMbkWGn6CTsrPvkEFiQuNTf2VmWiQVcL0qHUzvsG1sFaEDPe_bD IKMHOZxvaeFSDu4.kZzsC3aQsDjMGOWpEibBCWu96MqlWLm0F7t.Xmu_atif85nXRaWl.dlwNd9F phrMPC2CBIC1eOtmoVMwcVg6.ovvFQvCXIvofsHgEK25BaOBGuyRTdzPPVR6OPWwpL40M4e.h6BT TdA-- X-Sonic-MF: X-Sonic-ID: c539aad7-95b8-4ae3-8232-6b24b2799c54 Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.gq1.yahoo.com with HTTP; Fri, 12 Jan 2024 22:34:58 +0000 Received: by hermes--production-gq1-78d49cd6df-vkd75 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID cec106f0f66b8ae7d008c002a6ae7a6a; Fri, 12 Jan 2024 22:34:55 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.300.61.1.2\)) Subject: Re: USB-serial adapter suggestions needed Date: Fri, 12 Jan 2024 14:34:45 -0800 References: <55AC6824-587D-4C67-B64B-2045A1112F69@yahoo.com> <041F74B4-3D44-4364-9EBD-9F21A4F3B313@yahoo.com> <902798B1-2B66-4ECD-BDAC-195C85066FE6@yahoo.com> <8B4C76B2-707E-4978-9CB3-5D547303A7E5@yahoo.com> <482FA770-89E8-42E8-945E-B662AD564AFE@yahoo.com> To: bob prohaska , FreeBSD ARM List In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3774.300.61.1.2) X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.50 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; TO_DN_ALL(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCPT_COUNT_TWO(0.00)[2]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; FREEMAIL_FROM(0.00)[yahoo.com]; FROM_HAS_DN(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.32:from]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.32:from] X-Rspamd-Queue-Id: 4TBbvS31lnz4nZp On Jan 12, 2024, at 13:45, Mark Millard wrote: > On Jan 12, 2024, at 13:37, bob prohaska wrote: >>=20 >> On Fri, Jan 12, 2024 at 12:38:30PM -0800, Mark Millard wrote: >>> On Jan 12, 2024, at 11:18, bob prohaska wrote: >>>=20 >>>> On Fri, Jan 12, 2024 at 10:34:11AM -0800, Mark Millard wrote: >>>>>=20 >>>>> If you did not specify the signal explicitly, you tried: >>>>>=20 >>>>> 15 SIGTERM terminate process software termination = signal >>>>>=20 >>>>> (I'm not claiming all those "terminate process" signals are >>>>> likely to be involved. But SIGTERM is need not be involved >>>>> at all.) >>>>>=20 >>>>>> Both the ssh connection from workstation to terminal >>>>>> server and the su to root needed to run tip survive. >>>>>>=20 >>>>>> I should apologize for not testing this sooner, it >>>>>> was a very easy experiment. If you think of useful >>>>>> variations please indicate them. >>>>>=20 >>>>> See above, in particular SIGHUP . >>>>>=20 >>>>=20 >>>> Just tried SIGHUP several times. The ssh connection didn't >>>> disconnect. There were also no reports about overriding stale >>>> locks.=20 >>>>=20 >>>> Using SIGKILL reported: >>>>=20 >>>> login: Killed >>>> root@nemesis:/home/bob #=20 >>>> root@nemesis:/home/bob # tip ucom >>>> Stale lock on cuaU0 PID=3D45604... overriding. >>>> connected >>>>=20 >>>>=20 >>>> FreeBSD/arm (ns2.zefox.net) (ttyu0) >>>> but the ssh session and su survived. >>>>=20 >>>> Finally, I tried SIGSTOP. Again, ssh and su stayed up, but >>>> restarting tip reported: >>>> all ports busy >>>> Power-cycling the usb-serial adpter with usbconfig >>>> isn't able to free the port. That's new-to-me behavior. >>>> Deleting the /dev/cuaU0-related files didn't help. >>>>=20 >>>> Not sure what to make of this, except that ssh survives >>>> exit of tip, graceful or not. =20 >>>=20 >>> Remember: >>>=20 >>> Jan 10 14:29:48 nemesis kernel: ucom_close: tp=3D0xffffa00001979800 >>> Jan 10 14:29:48 nemesis kernel: ucom_shutdown:=20 >>> Jan 10 14:29:48 nemesis kernel: ucom_dtr: onoff =3D 0 >>> Jan 10 14:29:48 nemesis kernel: ucom_line_state: on=3D0x00, off=3D0x01= >>> Jan 10 14:29:48 nemesis kernel: ucom_rts: onoff =3D 1 >>> Jan 10 14:29:48 nemesis kernel: ucom_line_state: on=3D0x02, off=3D0x00= >>> Jan 10 14:29:48 nemesis kernel: ucom_cfg_close:=20 >>> Jan 10 15:04:07 nemesis su[35181]: bob to root on /dev/pts/4 >>>=20 >>> (and what was somewhat before and somewhat after)? >>>=20 >>> What were those messages like (if any) for each of the types of = kills? >>=20 >> Far as I can tell they're the same following ucom_shutdown.=20 >> Preceeding ucom_shutdown it looks like the sequence of messages >> varies a little, but obvious things like the big hex numbers >> are clearly indentical.=20 >>=20 >> If you've got something in mind please tell me what it is and I'll=20 >> be able to look more intelligently. > . . . >=20 Going in a different direction of kill signal testing . . . Showing what ssh running shells looks like, with a little context as well: # ps -xd . . . 1527 - Is 0:00.01 |-- nfsd: master (nfsd) 1529 - S 0:00.15 | `-- nfsd: server (nfsd) 1546 - Is 0:00.00 |-- sshd: /usr/sbin/sshd [listener] 0 of = 10-100 startups (sshd) 1628 - Ss 0:00.10 | |-- sshd: root@pts/1 (sshd) 1642 1 Ss 0:00.04 | | `-- -sh (sh) 9531 1 R+ 0:00.00 | | `-- ps -xd 7512 - Is 0:00.02 | `-- sshd: root@pts/0 (sshd) 7515 0 Is+ 0:00.01 | `-- -sh (sh) 1560 - Is 0:00.69 |-- /usr/sbin/cron -s . . . In that, the: 9531 1 R+ 0:00.00 | | `-- ps -xd is like where a tip command would show up as I understand. Also, you indicated tcsh use instead of sh use. And you are not likely using root@ as your context. You have tried killing tip. You could try killing the parent tcsh for the tip the various ways instead. Same sort of results information for each signal type. Be careful to do the kill from a distinct ssh session. One more level of parent process could be of interest: the equivalent of my "sshd: root@pts/" that indirectly contains your tip command in your context. Be careful to do the kill from a distinct ssh session. -SIGPIPE might be a relevant test here. Do not testing killing "sshd: /usr/sbin/sshd . . .". =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sat Jan 13 01:18:25 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TBgXK4pj0z56ptb for ; Sat, 13 Jan 2024 01:18:41 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic313-21.consmr.mail.gq1.yahoo.com (sonic313-21.consmr.mail.gq1.yahoo.com [98.137.65.84]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4TBgXJ5BJNz577n for ; Sat, 13 Jan 2024 01:18:40 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=fpT1XVmX; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.84 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1705108718; bh=5MrKTqJG2W8zDvjyAwR2OJwNc7UYwHrL96gem1ZSHds=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=fpT1XVmXaVAhJ9BG0Dc10MN5hewVX+00zdpevnHp0ZFN6OUV6/mSOn/T/VJFdtZ+5jqPXHcp1lHJ6kofDbY7L60Myy/q8QHYfyYBFoUcVO3gqyBqDBkpRuP3CfkbNfrOC39hcpMDnNq1odtiDTuTY/msm2IPOxkcggONe9sTv0utxUlZ9ttGtJJCOxjGEoS9W5ti9qKaz4YNbAaw96U9Xvwq/zIkSVCc76mS5cTHzyb36vL/HuiNWFOeaiw4PAMJfOoYYOLXv2FdvZ6lv+9uMU4ALqAy7VI6BC/+HPYQYjkRNxNSspfXpyuYsieOedxv6P1QO+98X1lgn3OPfPydrQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1705108718; bh=UCokiCOWKuTTlJC1vPx4wpL0zGSuz1PPjrTwyu4SMhV=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=pY3/3jeZaW7whCnONsR/K9LVxQgkBmNXfYB/CMXuCztGp5h9O25o23ieARtNO9e1GUD4WpJWKPVs7QdJ6EBaqNVLvZ/koUa2GewOIVdYLslGie4oCuxVc/e/vB7kdsfECNA/6lLtqo53q0MXNXtGfZcmYDsQtq1nJYXZ6VUFR9U+KhNJGgKTiZ8rvI9mwhG65uTtogokZfeyyqEi2wUjJUIvbjzwJex7F2N5WAY+03lI6+C2dRE88wNH1YVhO+WXQM4oUUgcA9Y4Hiaamqo0i6M/zDCaa692i5gc+PbzyG4izDR6rjc50rkkx372kS6kw2h1DKRWWXZ5rc4kFxYMew== X-YMail-OSG: RSAs9akVM1k7pHhrUPEs8s_ZHmKM3qCUXSkK_l0zGQDQlVFgp65Mxr88_g.HxiO DAvy.DB04MhAiglW3.CcXxIpeRm6LHUn5s.AggOkvHtUaVKWCnp1CuKCY12eINq2uZbYdKeyuiCa S1Ex3mmgtt6XqDbQHDedH_ONqyFzCSzl8.4BQv0qGEOBWHoheuJ._isJUs.5rTCa7.PND6rSEXNZ FF8V2qzQ_CWhUT2.w5kE9171YS9dIStIIh3A1u1.iG0LsD.LUsF4SYEDpmimHNNTlrulmvvFSQhY X33zqia5kK.NaLxd7ZKPAMdGnuAm9uAIgJ8fFjqO2lHynUCm9BQATrk8YWRMDFFAxOJdcOkU5_yJ NOX_W96My6PWMTxeeKhfdlQO.5OM1FPI.SdOOhCCnKmyRsMhQf37AEbxjtwpFoj6.uC0MQWs7820 BNQvIDTcBzn_WPDmqPgAQ.PNqxBiSqrmwfH5FOH.UP5hR4gUMHftQ49YoLpDk7deQ8H.5AJSJJns Zl3OXgQXjgoM8mRF2pYKGoof9q7CSOx5d754gygu1RrziwDQ.TUD0qzOO7fhMKprtISg.ZRoBshb nlMeb7nt348eC1_WZSrkn7s_796UvtEB.J4airgRm86Mzu06CGuj0UvzC_WETCaJnHdQsm8_phb4 QvIu0wSUcIBD11H5xKj9Cs2w_tFucU9dZg2YfW5xJKvuyCd.TXujPn6bmw97CPr65yIrybaSNrtd Vg9ebwIdhOqUX_d8b1mnxf8uQJZ4gQ3IPZyvZwbRydLQaomS6EKqSycNEFECHDiyqrEDopOL3XHt LA0p2ctgYuUvU9wLzJyXvldozTmjretWRnyvcQdFS9rPbRUASG39nxe79foxZ9NlzKmGuW7KblFp zKnTRWv7CP7WFq.hdjGd_dd6rVcbTd37OwKY8pbuptoXsmO4owxN.3WP9bjSoUCua6trjf6Jysmp ayRrgf16J6tbJFNpbxz0VyTJEUfIN_8xGp.46mzkcViBNCg.u8ih3aRx2aUhQuia3a1joEWqMSdK Vf7JI63oZqIcLi4NF75m.GaF9pl.HU1pe.tiKBdD0tzXfOlyfxChikg3ZYWRFGauTitvhffE251Q Q7jxiKW3RjMVVHgy0KNcicPmY1Z9zTPftUEiGaEDZGRd9qhxyho4CURYkWy.OTZ2ITh_qaOT6ttr fA4JHbywvDrdpM6PuC_.2CgGeRKq7dxtgassoRdq09mRBerAxqY7CZNAjE2u8Xi4Dkh9MggvtU1C wllc7jatd9H_radktbbrcgLG1IFpVAEJgvMyoCg0uIS00c3XwmJt0VrHShqcZLZwcKJY0p951Gek pWsvrntC4yHcg9Zf8hohqJHCQSYkEvkclXo7t_GAx4VKpGi1CdomxCQPPGaUKXcoRNh_xLvR3xOO mw2aqvcYpDry1HQs2UT6FyxPBsPllmZtgqBh5CXl91eOz.hpTFA5WT3aHgOiAuPPcRJlnxoth0z8 QY1b_.E64ufQxNTsHOIScyIwcuQFO261YCzDni_Gz_iYaEWbBp7dL69tFjdGTwn4H.PA9RwaHAkH PpUBQb6EvsSRHwjfsQxlLeI4MpbkVJAlHWO7ApiaDzREB3Dm5eyQAx_JQ6CB_9ytVa.syY4H0NYp kGyQN_Rb3EUIybpC2Kj4xOfnaakJgULGeIy5BLgrXWwJV9EqZsF2M_kLmY7YBXVnBRc_y9ICs4YC P0auImfS3D4Zvz0GQ31AdZ1HT4TIJQlo9U5E1xjwpOPGz0jXjt7kHBu9fRJOM54Q9ctkzUf5nMbs 3PTFups.UwI0comLKLGhYK5uSkGlgGCY2CVZQrxBi91OFn.Wl.XtjoBzJHEjtwKDURyL_pewTHlc VkxODCl1eoLn7_q8tgTFwTNiP4znvCVnrQBiEO_oLXeW1XEz_w9t3vhZjXw9WjZ.sxkSPrOK.pKC swOGrcmajDgu8aHvBD6k8_CYn.ecDdJJxw6zOy.iBSJMnkbXq6U6Dxc_tRWT5eT7Ck.2nT6Puk3o 0UVW6QLlH04Xs5G_IPCV6AdqzJthlZgFtf5QShQcFD8afD2l19Q1H7cLaMnUZqHaidwYZ8idbbuD dR_O5EtpqkXQfANWHQMSNrS131M9hnlcKrVVUHTW7jtb7VGpmBnwxAz1bUMQEHv2PhiNPLuWGKBo GSzte0k4zMNawi_FMSVthqHKnI4iZvGzNN8r5UPqcbh_LQRFBhPU7NUQaRQJSnGRnZkK5rylMyXz w44pfa.LEByxSpbbg36tWUQWdQyYmOegRc97zXNWkzWaT9DrW4SbLa2G6ttsgLdSfsp5Mprs4i2a Kfw-- X-Sonic-MF: X-Sonic-ID: e1f487a0-2755-495c-9956-75a641f4e12b Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.gq1.yahoo.com with HTTP; Sat, 13 Jan 2024 01:18:38 +0000 Received: by hermes--production-gq1-78d49cd6df-4xktb (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 0d33beb0bfff43668f2dd7132cb8f6d5; Sat, 13 Jan 2024 01:18:36 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.300.61.1.2\)) Subject: Re: USB-serial adapter suggestions needed Date: Fri, 12 Jan 2024 17:18:25 -0800 References: <55AC6824-587D-4C67-B64B-2045A1112F69@yahoo.com> <041F74B4-3D44-4364-9EBD-9F21A4F3B313@yahoo.com> <902798B1-2B66-4ECD-BDAC-195C85066FE6@yahoo.com> <8B4C76B2-707E-4978-9CB3-5D547303A7E5@yahoo.com> <482FA770-89E8-42E8-945E-B662AD564AFE@yahoo.com> To: bob prohaska , FreeBSD ARM List In-Reply-To: Message-Id: <9F0BEC32-93CB-4DEB-98C4-D0FF2284B9DE@yahoo.com> X-Mailer: Apple Mail (2.3774.300.61.1.2) X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.48 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.98)[-0.983]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; TO_DN_ALL(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCPT_COUNT_TWO(0.00)[2]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; FREEMAIL_FROM(0.00)[yahoo.com]; FROM_HAS_DN(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.84:from]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.84:from] X-Rspamd-Queue-Id: 4TBgXJ5BJNz577n Do you have the following sort of thing in each /etc/sysctl.conf ? # # Together this pair avoids swapping out the process kernel stacks. # This avoids processes for interacting with the system from being # hung-up by such swapping out of process kernel stacks (and other # types of processes as well). vm.swap_enabled=0 vm.swap_idle_enabled=0 === Mark Millard marklmi at yahoo.com From nobody Sat Jan 13 01:52:55 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TBhHp6cRvz56sfd for ; Sat, 13 Jan 2024 01:52:54 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (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 "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TBhHp3pm2z3x2p for ; Sat, 13 Jan 2024 01:52:54 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Authentication-Results: mx1.freebsd.org; none Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.17.1/8.15.2) with ESMTPS id 40D1qu65017970 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 12 Jan 2024 17:52:56 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.17.1/8.15.2/Submit) id 40D1quhJ017969; Fri, 12 Jan 2024 17:52:56 -0800 (PST) (envelope-from fbsd) Date: Fri, 12 Jan 2024 17:52:55 -0800 From: bob prohaska To: Mark Millard Cc: FreeBSD ARM List Subject: Re: USB-serial adapter suggestions needed Message-ID: References: <902798B1-2B66-4ECD-BDAC-195C85066FE6@yahoo.com> <8B4C76B2-707E-4978-9CB3-5D547303A7E5@yahoo.com> <482FA770-89E8-42E8-945E-B662AD564AFE@yahoo.com> <9F0BEC32-93CB-4DEB-98C4-D0FF2284B9DE@yahoo.com> List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9F0BEC32-93CB-4DEB-98C4-D0FF2284B9DE@yahoo.com> X-Rspamd-Queue-Id: 4TBhHp3pm2z3x2p X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US] On Fri, Jan 12, 2024 at 05:18:25PM -0800, Mark Millard wrote: > Do you have the following sort of thing in each /etc/sysctl.conf ? > > # > # Together this pair avoids swapping out the process kernel stacks. > # This avoids processes for interacting with the system from being > # hung-up by such swapping out of process kernel stacks (and other > # types of processes as well). > vm.swap_enabled=0 > vm.swap_idle_enabled=0 Not on pelorus.zefox.org, www.zefox.com, nemesis.zefox.com, fixed now. The rest already had the setting. While checking, I logged in as root on the serial consoles of each host. When I tried to log in to www.zefox.net the response was FreeBSD/arm (www.zefox.net) (ttyu0) login: root Password: Corrupted MAC on input. ssh_dispatch_run_fatal: I've seen this only once before, I think logging in to pelorus.zefox.org. Re-running ssh to the terminal server and tip to www.zefox.net connected directly to a running console root shell. Apparently the login attempt started a root session on the console and detached the tip connection. For some reason I find that rather sinister. Am I being unreasonable? Thanks for writing! bob prohaska From nobody Sat Jan 13 02:31:17 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TBj856qfJz56xR3 for ; Sat, 13 Jan 2024 02:31:17 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TBj8551Wtz449y for ; Sat, 13 Jan 2024 02:31:17 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1705113077; 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; bh=f+DPQCJUdUgtDFDRTPodZErz63aHWsdmbgjKPV0WtFI=; b=MY7pQ9uktUfwGtqsVCiRUgHSlkLLJwysVTQ8mpruwn5dh2og2dLPyQGUFhv6TU+gi544oj cfrTKjyWqPVFmPyDUMVwXJDaGT9Q1KqnhzJDGyWLyXmynbevELlyxOmAGhyxDm6EHgZdoJ aS9KatNTBAKXDvDtf9N+7PstPhmcsHBDkQtGW3iPf0vJ8HpkiWqy2fSzgMBV3aTgVLOgZP Ea0TZ5DtjKoTCtGVCNUQPt2sx0YZq0FZ7y4qPIDk9GauOZD7/Nry1wMiHJ7xt9VsWBbl0d xhkJvfzZTW1ChTTN228weBZJ0z+KYvwtgYmK/T9yQlkmF58ApKKC8kRxc7K/Lw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1705113077; a=rsa-sha256; cv=none; b=FS+HqnZ9GWa8KMCSLjTR12ye46QOj+AY8xlBdDXGjjA47qXT4VZMDtnTGLusyesOVEGixF TbWst1tj4Ibs6lAHpqCftut9LcknhdHlk6j11IAZguqar1h/U5U6o/1sW2bMEzY3ReX5dA lo7H78VThKKFtqiydLmJZQWcx/K4oM2BkR+IHIOqG8JDt4ttYJuHjRds5wKFQIbM+3cdGh WVOS45RkrGmEYLovwxwTzSMgJyGiDfnkRpRgo4QxSOZaEu/YquCt4w/pITg+zHu+X+DpKZ jc2P9H+30X/4c+BnQ+92/EKK42FI0vV2eUWCL+aB+3x44hqCYjSpzJcmvspRpw== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4TBj8546Krz1RSG for ; Sat, 13 Jan 2024 02:31:17 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 40D2VHxd078660 for ; Sat, 13 Jan 2024 02:31:17 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 40D2VHqp078640 for freebsd-arm@FreeBSD.org; Sat, 13 Jan 2024 02:31:17 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 276284] serial console login reports corrupted MAC Date: Sat, 13 Jan 2024 02:31:17 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: Unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: fbsd@www.zefox.net X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D276284 Bug ID: 276284 Summary: serial console login reports corrupted MAC Product: Base System Version: Unspecified Hardware: arm OS: Any Status: New Severity: Affects Only Me Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: fbsd@www.zefox.net While logging in as root on the serial console of a Pi2 running 12.4 Release the login attempt reported Corrupted MAC on input. ssh_dispatch_run_fatal: Connection to 50.1.20.29 port 22: message authentication code incorrect The ssh connection to the terminal server (also a Pi2 running R12.4 dropped Re-connecting to the terminal server and restoring the tip connection to the serial console attached to a running root shell echoing meaningless but not garbage characters. Something similar has also been seen on an aarch64 14-stable system. Neither host seems impaired, but the scenario is disturbing.=20 A more complete transcript is at: http://www.zefox.net/~fbsd/tiptrouble/corrupt_mac This is a descendant of bug 273566, but the corrupted MAC is a new=20 feature, if not an evolution. --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Sat Jan 13 05:49:47 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TBnYR752Lz56nxn for ; Sat, 13 Jan 2024 05:50:03 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic315-8.consmr.mail.gq1.yahoo.com (sonic315-8.consmr.mail.gq1.yahoo.com [98.137.65.32]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4TBnYR4V3Kz4PxN for ; Sat, 13 Jan 2024 05:50:03 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1705125001; bh=UwW4c9skSwJDuT8b4zwfBrxbzACupBQfpeiy/mTYLIU=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=DO/iRZYOobpakOL+SWvuD3VYjoEL5QmudEqW3FRXof21iT9CaSf79dqaW93B7OtDNHCMbWBpWsZf8nQom/yicLd9V0YgDq92xrcgcnu+9CXr0lcfO/A2zxTexNF/2Gwu3pxEmtjzkF9hTUX+/V6InD6BtrNOIZBJsCftMnYK6vxLL2X6UPuVKi/2NY6HgFd9ySooN29XMcfPgIod+CnZWbXbYKDd+Navb/teS3u1E+KkgdOxdM7sEeFSkevsvB6ogGdtH77qGt7ebCkdQSGFzqjRpDWPbIY3JcIYFJMCxgqUpubis4zpl4x8x1Yce2zIkYLXPkJOSjI3U3svJ4i+1g== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1705125001; bh=oWhONxHUgqb9zzjAdsq42zUVuj/QCd7AjyrYFRELC0l=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=iAM4dS4lVEeKqQn6Odgjn1qnppHnBxu6cskzjNbQZpuOo51cQMsfhd7qmJX7iJexWzZDUQ24S/EZv+IlLB6uUnPqj9ZT2bnYY55Mss3uN2flHpeAgz479WUacjrCItVHzvAvJvlDMdDgK/nCdLoUaRwcdDGW5IABcOlTatj+3cWjPdGuGm5Yyxp5/7jDddrilIECofM9nXEDT0odOVdB3VdPxw16cQbajwEuDYAoQb4ZuX9TIYXRsVkyq9Zzi1WPR2vAT3WY6KLWVG6j5Ybxa8AjyIVkCb2L30w2m62GUDzva3TBKMeSiDBPVTATBj7d7+3ZpbU7zFGX10Zs3/kt/g== X-YMail-OSG: djFrFqcVM1l96CHdgZwbAwHbqB3RohCXwPpOfsaZTu_wIotX_xoVj0hR.4GJaej 15ZZW6.4wiqf0qBXwraURFCTgLaqUNmyOJ5JRR0w8e4dgk5bE_3AimfZJV82T34a2Sd3qgna.q3h 1u2nW8OzJ9xJqAxwccU1ax3CRBYB_rjhRuNWsGK_5rcll8MYksFSUy5PW9tfQNxDYgsAQJlHCv9G uVlV198yl8YkqLX9i2TVTQUs8wVaB4yM29WfHTynzPaMSZzovjZRmPkwchRmG2gkR0O_qVpbdFfB j0__bpSjBiw9bMolH.cYrDsCr7Kj_h7WO4a.JdHRzhYJ6kXcEl8WV.vqvkwttfpZK4CDRbdiwYs3 f77qNxnp3q2X9oSEwFLuwRHIrxGF87pW_U8nS_KxZ3f.mPT3c62MJ.47X88WNAMCZJf9z9B_U5tM GhsGSMWdYp9IYHBtZHjF6QQMeODs6YaWfCaH4HmE.3e.zr0yqDE2mctGTXaeFSM1DE6R_brZ7VGB cUbGYAo.TmI6CtGtvcNH5U6NDsU8wWvoWeJ8b8b4EqTLnhYr5sK7nB0j_RK0MSnSCFUXsREUM1Ri fVcWP5rq6lMZQvh9Dr_WmR_GcgRT3WnkTSY9sQ9grrviT9bgo21g.dU.fbWgTy5jG.v6uwIWymyv wl0mbSY2rs569p_kngRBOnh5Oa40XnoN75L_w8D3sur4l2jQyEXIym3RpJx3NQoZFO9SAAmlZr08 G6EYxwkgx6Uo.O24rE424QMxE2Nk57HlJqs9.xnJLt34.qIu7_W7Eb.mt2wv.7AZO31AlISz2mmC b6tyHLvDsO6BDkIrORvGqsQ_fd5ry4eEK1_f5UX39axJl3SIsg3_rVmtFN7IPX048RZRnHkU9m_G cinPjlbraK1z2s8IJDpVqPw9U0JTzhvkYJrKqK450ezI0YoHgjh8UPEnG.aQMKwS4CEzQbqcidwX Hnri6tsx0MjXLscmEQKMbk9hIzoNVIAGxbYokCsTiNFUVYNwwtSolH69.b2OmRlBSyWvqc0Fa19X RhnxsVu_x919zwM2ps3tegZ17qy6CWtpXzYnp1VdxQkw_ZC3lmmgIxI97aiTekeO6dRle0ebCKSq 4utUpUBrD_ZhkR6r.JOt6KrgW1jVkEOO32MV59cHZoh8wDo_n2d1sbsef1_tNcMO5KgkMOwwt_p_ DEH3fHKE2A1pvKrrmSrFHgIyamFxm_wxz63b5vmmAchDwuGV89fhQPoa6P_odxzKueVrB.jIxfiI IWtJvLBIifBmOTog15y6GdJ7nSfCikWKprtYN4IrZ0xGi3ei3L9kJ7li1PjOsFDYVhLUUFUz0kxj HzRG7c650SyJGt.EIlRWHYY_1gNmkjBz_TzEJ5h1Pha2xh9nJMPa__wgLGTXe4YgFIwblb2up.PJ ax2Trd9JrB7asYDQ0AfqcD_qRJvSuzQsrFFMPXC4Bo2ALfZLEBmmBj_aDnoqc6shn3jDRD.IMYmH kFlY5ExazoM.n58oXfvZPuL_NJPc5k7MCfxaCcB.J3LhxirGLywgf4UchigpbNiedtBm7TCDqko4 o5d70Uw.DFUQOaF7fab_e7kB.FIC0Jd.YxzGkuY_O4auvVKNvahMHZO1OMnyjHCL2BLySYp7n_Wj 1Ycq_BlxPcVu4jX5pAXEQjS67Mj7Rgylowki9NwgmwY69phwRT2QZYkXSiF1w9Dvby7.QT3C9z5m eD3ZZIC9BUKzN7XMUFi4Cz3ER6jDDWBR3PjC.OH8Z0LFTeR9ruM6ZgBIk8NECMbgfF6FQDTO42h3 cbgR4.pKdumo6EcjKM4l_gt7a82bas7nZ36lb5N7q8JEqVGphz_eLHtJlelO5v4cfnPgFjFbgnl7 PX48zqmbGlGquJ1RfVmPYZhLs4QOuiS.Ka5qo1egdh3GVOUZTCLEN3vbDpRLU_.dWHZnoW.hZQGk 3vGvRKIDpPM5ylNKCVPMPkPYt8ToOwlb0UB8WDy9nOI7ENBkpnoPQZkU9wleDv6EpNge7lEqkS01 h6vLm0owPD5vU.7YLf_.CSETWEsQN2KGv_HAXNUBIcVIU126BH5t0Fot0tMaAlaSK2.xssTy1Hwl nHf5CFSCD6Pk46G76TbNP._A2055okiL0v2fPdDuAJOdkRIusiwt4k_IUhUEmN3hETlLmCISxaHl Z7tKk.TphG5YUopXpiuyiS.EGE2mKNOjUjjD1t9dfhwV9.2h3HKxgg6nTThVS1oonxYuFKnF4i7X udmdOmqoYVseyBWqn3CQrpE7woCQ5ZeeS9t8dEbJwiy8WFAuiVhxui6cXkx6IaytZjQ5VwhO5i.8 3 X-Sonic-MF: X-Sonic-ID: c0200031-18ed-4195-bcc4-00dd10fcdea4 Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Sat, 13 Jan 2024 05:50:01 +0000 Received: by hermes--production-gq1-78d49cd6df-szbbq (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID b4635fc5e04822b83cf3e7eec6adb30e; Sat, 13 Jan 2024 05:49:57 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.300.61.1.2\)) Subject: Re: USB-serial adapter suggestions needed From: Mark Millard In-Reply-To: Date: Fri, 12 Jan 2024 21:49:47 -0800 Cc: FreeBSD ARM List Content-Transfer-Encoding: quoted-printable Message-Id: <85102B46-CC5E-4FDA-8736-F562512FADEC@yahoo.com> References: <902798B1-2B66-4ECD-BDAC-195C85066FE6@yahoo.com> <8B4C76B2-707E-4978-9CB3-5D547303A7E5@yahoo.com> <482FA770-89E8-42E8-945E-B662AD564AFE@yahoo.com> <9F0BEC32-93CB-4DEB-98C4-D0FF2284B9DE@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3774.300.61.1.2) X-Rspamd-Queue-Id: 4TBnYR4V3Kz4PxN X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] On Jan 12, 2024, at 17:52, bob prohaska wrote: > On Fri, Jan 12, 2024 at 05:18:25PM -0800, Mark Millard wrote: >> Do you have the following sort of thing in each /etc/sysctl.conf ? >>=20 >> # >> # Together this pair avoids swapping out the process kernel stacks. >> # This avoids processes for interacting with the system from being >> # hung-up by such swapping out of process kernel stacks (and other >> # types of processes as well). >> vm.swap_enabled=3D0 >> vm.swap_idle_enabled=3D0 >=20 > Not on pelorus.zefox.org, www.zefox.com, nemesis.zefox.com, fixed now. > The rest already had the setting. >=20 > While checking, I logged in as root on the serial consoles of each = host. > When I tried to log in to www.zefox.net the response was This and http://www.zefox.net/~fbsd/tiptrouble/corrupt_mac do not make clear the full chain of connections. In fact the presentation seems inconsistent with other information so various things may have changed. Some context based on prior (out of date?) information: |-50.1.20.30 ns1.zefox.net Pi2 12.3 armv7 ftdi = usb-serial----50.1.20.27 |-50.1.20.29 ns2.zefox.net Pi2 12.3 armv7 2303 = usb-serial----50.1.20.30 |-50.1.20.27 www.zefox.net Pi2 12.3 armv7 2303 = usb-serial----50.1.20.26 Was "pi4 RasPiOS workstation" involved as a starting place? If so, what sequence gets to www.zefox.net from there? If not, where is the starting direct login and what is the sequence to get to www.zefox.net the same way you did? Starting with what you showed via: http://www.zefox.net/~fbsd/tiptrouble/corrupt_mac (not knowing how you got there) . . . QUOTE FreeBSD/arm (www.zefox.net) (ttyu0) login: root Password: Corrupted MAC on input. ssh_dispatch_run_fatal: Connection to 50.1.20.29 port 22: message = authentication code incorrect END QUOTE 50.1.20.29 is supposedly ns2.zefox.net instead of www.zefox.net or ns1.zefox.net according to http://www.zefox.net/~fbsd/netmap . But . . . QUOTE [back to shell prompt on workstation, try to reconnect to terminal = server] bob@raspberrypi:~ $ ssh 50.1.20.29 Password for bob@ns1.zefox.net: END QUOTE That looks to also indicate that 50.1.20.29 got to ns1.zefox.net instead of ns2.zefox.net . Then there is a name referenced that not referenced at http://www.zefox.net/~fbsd/netmap at all : QUOTE Last login: Thu Jan 11 11:02:27 2024 from gateway.zefox.net END QUOTE Then there is more text indicating ns1.zefox.net is what 50.1.20.29 got to: QUOTE FreeBSD 12.4-STABLE r373269 GENERIC=20 Welcome to FreeBSD! [MOTD snipped] bob@ns1:~ % su Password: root@ns1:/home/bob # tip ucom END QUOTE If ns1.zefox.net is connected to the serial port of 50.1.20.27 and if 50.1.20.27 is actually www.zefox.net then you got back to www.zefox.net again at this point, via access to the serial console as the last stage of getting there. QUOTE Stale lock on cuaU0 PID=3D1460... overriding. connected ) Too many )'s. END QUOTE I'll not quote the other odd text. There were numerous reference to "root@www:~ #" and to "Too many )'s." mixed with other odd text. For all I know, the text may be exposing the contents of arbitrary memory. Whatever text directly followed is not shown. It might have been a normal looking login to www.zefox.net for all I know. > . . . >=20 > I've seen this only once before, I think logging in to = pelorus.zefox.org. > Re-running ssh to the terminal server ns1.zefox.net as 50.1.20.29 ? > and tip to www.zefox.net That suggests that 50.1.20.29 got to ns1.zefox.net which is connected to the serial console port of www.zefox.net (as 50.1.20.27 ?). > connected directly to a running console root shell. Apparently the > login attempt started a root session on the console and detached > the tip connection. Not shown in http://www.zefox.net/~fbsd/tiptrouble/corrupt_mac . Good to know. > For some reason I find that rather sinister. You may be suffering occasional hardware or software corruptions of material that end up going over Ethernet. When it happens in the right kind of place (possibly more rarely than corruptions actually happen), you end up with the ssh session crashing. The "Stale lock on cuaU0 PID=3D1460... overriding" sort of notice may well explain the garbage text: the memory involved may well only be known to be good when the lock status is reliable at the time, instead of being overridden. Figuring out the hardware vs. software contribution to corruptions is likely much harder to do than getting to this point has been. But now you at least have evidence of an example of the type of thing that is sometimes going on. The bugzilla material eventually needs to be updated with something that can be followed and noting the possible occasional hardware or software corruptions of material that end up going over Ethernet that are now demonstrated to be able to cause the symptoms that you have been seeing on occasion for so long. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sat Jan 13 15:38:06 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TC2c95xp2z57ldN for ; Sat, 13 Jan 2024 15:38:17 +0000 (UTC) (envelope-from dfr@rabson.org) Received: from mail-yb1-xb34.google.com (mail-yb1-xb34.google.com [IPv6:2607:f8b0:4864:20::b34]) (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 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TC2c85KpXz4Sh5 for ; Sat, 13 Jan 2024 15:38:16 +0000 (UTC) (envelope-from dfr@rabson.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=rabson-org.20230601.gappssmtp.com header.s=20230601 header.b=t22gYM02; dmarc=none; spf=pass (mx1.freebsd.org: domain of dfr@rabson.org designates 2607:f8b0:4864:20::b34 as permitted sender) smtp.mailfrom=dfr@rabson.org Received: by mail-yb1-xb34.google.com with SMTP id 3f1490d57ef6-dbed729a51eso6404999276.0 for ; Sat, 13 Jan 2024 07:38:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rabson-org.20230601.gappssmtp.com; s=20230601; t=1705160296; x=1705765096; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=gTKN+W8CIKF+1z3rRrOsbGxVbiOw/oOhw4+scY4pW7E=; b=t22gYM02leAlVe2kMhVYXAwLzRurOtEFnxg/2nl9Y2yEbwypl0zBSqbRLa4ZFf67Go qywgUXIGPoRfig4MEEi98KL0lc6Cw/AG5NEChar18RGgMB/Ch7d/cIgvZvakJQ8klzBM eg5dv0KpXF3Uscgj8Jl/7suQMkHjKf9w0q7Gh2bbDCxen4mbubkxZ+ZnMLrNMSPb/Wot k1aCqD4VBVDpDoQI+Pxrqnhx6usJr0X1DjGFdsLNTgvTnYNn8lKO19q3inTgUesvnPg/ DaseTEszR5IBqK3nXVQLez3/oIwtnI98fl9pdgp1Y1Vi+jLGqKq6SHoBWJ310pFoNcUC 4Yew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705160296; x=1705765096; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=gTKN+W8CIKF+1z3rRrOsbGxVbiOw/oOhw4+scY4pW7E=; b=JSxjS6ciHkmuuMrF/gkmcNkc8Y7Upifid8JbgqHOHFQ075f5tm/JXsVzAXKcwPMUX1 I6jaLY1PUPoyZzHQR7As/aD5cy+X/b0U6LxUqR3HOm+rvwPNgsmUN4fQWd84do3fLDLh X2kjjtEhIc5OxaHO/XYpnIDFnY0lBPSFr1fZcNABnnSEIZtHpzO9ZKYSszodg8+oJazF 2U28fKWZET9yPWaFWyhOMkarFVlwGLLSy3RhMeaWFjpejMiGm5V0tyV9U1XcnsyU4G6s mjiUhUul5oVcT/CDrKi1ANydQq4cmn9LBf5TjtWENBJ6Jvu+z9s/8IEpZKgZXUyn9yZL h7Fw== X-Gm-Message-State: AOJu0YzGCu9YJtOl3wNYibqKMHKQ9k7xeMId4Y5jg0183q+J4k7kV2Nd f6sV8yCDghD+3rT4JzZa1aKow5WC6+vRjOy1y/Uu0bwZqTf5oA== X-Google-Smtp-Source: AGHT+IGZYy+XrzTiZHnvf7lyIIknsLewXNc/Vtuf1uvgWPUWEFJV1qFQeWSz1hwl6iw3ZqKjuqzPGzM9Bnhv0QkBjwI= X-Received: by 2002:a25:9085:0:b0:db9:5b19:4852 with SMTP id t5-20020a259085000000b00db95b194852mr1419824ybl.50.1705160295706; Sat, 13 Jan 2024 07:38:15 -0800 (PST) List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 References: <5a39810c-5fd8-4969-a222-2561b050b035@FreeBSD.org> <347FE009-A470-4765-A9B9-7C9AB5E954DA@yahoo.com> In-Reply-To: <347FE009-A470-4765-A9B9-7C9AB5E954DA@yahoo.com> From: Doug Rabson Date: Sat, 13 Jan 2024 15:38:06 +0000 Message-ID: Subject: Re: When will FreeBSD support RPI5? To: Mark Millard Cc: Jesper Schmitz Mouridsen , John Kennedy , ykla , FreeBSD ARM List Content-Type: multipart/alternative; boundary="000000000000b6018c060ed59102" X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.50 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; R_DKIM_ALLOW(-0.20)[rabson-org.20230601.gappssmtp.com:s=20230601]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_CC(0.00)[freebsd.org,phouka.net,gmail.com]; TO_DN_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; DMARC_NA(0.00)[rabson.org]; ARC_NA(0.00)[]; FREEMAIL_TO(0.00)[yahoo.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; DKIM_TRACE(0.00)[rabson-org.20230601.gappssmtp.com:+]; RCVD_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::b34:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MISSING_XM_UA(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; FREEFALL_USER(0.00)[dfr]; RCPT_COUNT_FIVE(0.00)[5] X-Rspamd-Queue-Id: 4TC2c85KpXz4Sh5 --000000000000b6018c060ed59102 Content-Type: text/plain; charset="UTF-8" Getting back to the RPI 5, with a tweak to arm/broadcom/bcm2835bcm2835_vcbus.c to treat the memory config the same as RPI 4 and to dev/sdhci/sdhci_fdt.c to treat the RPI 5 sdhci controllers as generic, I can boot to multiuser mode using the EDK2 firmware from https://github.com/worproject/rpi5-uefi with ACPI/Device Tree mode set to Both. This does not have working PCIe or ethernet yet - I think ethernet ought to work since we seem to have a matching driver in the tree in dev/cadence. Doug. On Thu, 11 Jan 2024 at 18:09, Mark Millard wrote: > On Jan 11, 2024, at 08:56, Mark Millard wrote: > > > On Jan 11, 2024, at 08:20, Doug Rabson wrote: > > > >>> On Thu, 11 Jan 2024 at 01:30, Mark Millard wrote: > >>> (While I normally use FreeBSD's U-Boot type of context, > >>> My builds do have patches to allow RPi4B EDK2 use to > >>> avoid the problems that I know to test for.) > >> > >> I'm curious how you were able to boot FreeBSD on rpi4 with EDK2 - I > tried with both the FreeBSD package as well as the latest release from > github. FreeBSD-14.0 stalled trying to initialise xhci while FreeBSD-15 > gets a little further but also hangs before reaching single user mode. I'm > wondering if perhaps I should use the dtbs from sysutils/rpi-firmware > rather than the ones from sysutils/edk2@rpi4. > > > > It has been a while since I last tested booting based on > > a EDK2-based release from https://github.com/pftf/RPi4/ . > > It looks like v1.35 is from 2023-Jun-05. At some point > > I'll (re?-)try it. > > > > I used the same style of having EDK2 on a microsd card and > > booting my normal USB3 media. The RPi4B is configured to > > first try the microsd card slot (usually empty for me) and > > then to try USB. I do set things up in EDK2 for serial > > console use as primary. (I only rarely connect video to > > the RPi*'s that I have access to. Mostly I ssh to them over > > ethernet and otherwise use the serial console.) > > > > I've access to RPi4B Rev 1.1, 1.4, and 1.5 examples, > > a mix of 4 GiByte and 8 GiByte. > > > > I've never used sysutils/edk2@rpi4 to boot as far as I > > remember. My EDK2 activity started long before that > > existed and I did not switch. > > > > The RPPi4B EDK2-based releases that I've used were from: > > > > https://github.com/pftf/RPi4/releases/ > > > > But there are many releases that I've never tried. > > > > I do use patches to avoid some reliability > > problems with USB file I/O . The reliability > > problems never interfered with booting and were > > only systematically reproducible via generating huge > > files. But the problems were originally notice via > > buildworld/buildkernel oddities that involved > > randomly corrupted files, but not many. The problems > > are FreeBSD bugs/incompletenesses in an area not used > > with most UEFI/ACPI contexts that FreeBSD supports. > > > > I found my v1.35 microsd card from the last time I tried. > > I had forgotten that the boot attempts now get a FreeBSD > panic (seen via serial console use): > > panic: ram_attach: resource 5 failed to attach > cpuid = 0 > time = 1 > KDB: stack backtrace: > #0 0xffff00000050f450 at kdb_backtrace+0x58 > #1 0xffff0000004ba930 at vpanic+0x19c > #2 0xffff0000004ba790 at panic+0x44 > #3 0xffff00000086e7c0 at ram_attach+0x1ac > #4 0xffff0000004fba88 at device_attach+0x3f8 > #5 0xffff0000004fdce8 at bus_generic_new_pass+0x120 > #6 0xffff0000004fdc78 at bus_generic_new_pass+0xb0 > #7 0xffff000000500450 at root_bus_configure+0x40 > #8 0xffff00000042b600 at mi_startup+0xdc > #9 0xffff0000000008ac at virtdone+0x70 > > It is a FreeBSD problem, not an EDK2 problem. My old > notes on the lists about the FreeBSD problem are at: > > > https://lists.freebsd.org/archives/freebsd-current/2023-September/004775.html > > I do not know if v1.34 might sidestep the mishandling > in FreeBSD or not. > > === > Mark Millard > marklmi at yahoo.com > > --000000000000b6018c060ed59102 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Getting back to the RPI 5, with a tweak to arm/broadcom/bc= m2835bcm2835_vcbus.c to treat the memory config the same as RPI 4 and to=C2= =A0dev/sdhci/sdhci_fdt.c to treat the RPI 5 sdhci controllers as generic, I= can boot to multiuser mode using the EDK2 firmware from=C2=A0https://github.com/worproject/rpi5-u= efi with ACPI/Device Tree mode set to Both. This does not have working = PCIe or ethernet yet - I think ethernet ought to work since we seem to have= a matching driver in the tree in=C2=A0dev/cadence.

Doug= .

On Thu, 11 Jan 2024 at 18:09, Mark Millard <marklmi@yahoo.com> wrote:
= On Jan 11, 2024, at 08:56, Mark Millard <marklmi@yahoo.com> wrote:

> On Jan 11, 2024, at 08:20, Doug Rabson <dfr@rabson.org> wrote:
>
>>> On Thu, 11 Jan 2024 at 01:30, Mark Millard <marklmi@yahoo.com> wrote: >>> (While I normally use FreeBSD's U-Boot type of context, >>> My builds do have patches to allow RPi4B EDK2 use to
>>> avoid the problems that I know to test for.)
>>
>> I'm curious how you were able to boot FreeBSD on rpi4 with EDK= 2 - I tried with both the FreeBSD package as well as the latest release fro= m github. FreeBSD-14.0 stalled trying to initialise xhci while FreeBSD-15 g= ets a little further but also hangs before reaching single user mode. I'= ;m wondering if perhaps I should use the dtbs from sysutils/rpi-firmware ra= ther than the ones from sysutils/edk2@rpi4.
>
> It has been a while since I last tested booting based on
> a EDK2-based release from https://github.com/pftf/RPi4/ .
> It looks like v1.35 is from 2023-Jun-05. At some point
> I'll (re?-)try it.
>
> I used the same style of having EDK2 on a microsd card and
> booting my normal USB3 media. The RPi4B is configured to
> first try the microsd card slot (usually empty for me) and
> then to try USB. I do set things up in EDK2 for serial
> console use as primary. (I only rarely connect video to
> the RPi*'s that I have access to. Mostly I ssh to them over
> ethernet and otherwise use the serial console.)
>
> I've access to RPi4B Rev 1.1, 1.4, and 1.5 examples,
> a mix of 4 GiByte and 8 GiByte.
>
> I've never used sysutils/edk2@rpi4 to boot as far as I
> remember. My EDK2 activity started long before that
> existed and I did not switch.
>
> The RPPi4B EDK2-based releases that I've used were from:
>
> https://github.com/pftf/RPi4/releases/
>
> But there are many releases that I've never tried.
>
> I do use patches to avoid some reliability
> problems with USB file I/O . The reliability
> problems never interfered with booting and were
> only systematically reproducible via generating huge
> files. But the problems were originally notice via
> buildworld/buildkernel oddities that involved
> randomly corrupted files, but not many. The problems
> are FreeBSD bugs/incompletenesses in an area not used
> with most UEFI/ACPI contexts that FreeBSD supports.
>

I found my v1.35 microsd card from the last time I tried.

I had forgotten that the boot attempts now get a FreeBSD
panic (seen via serial console use):

panic: ram_attach: resource 5 failed to attach
cpuid =3D 0
time =3D 1
KDB: stack backtrace:
#0 0xffff00000050f450 at kdb_backtrace+0x58
#1 0xffff0000004ba930 at vpanic+0x19c
#2 0xffff0000004ba790 at panic+0x44
#3 0xffff00000086e7c0 at ram_attach+0x1ac
#4 0xffff0000004fba88 at device_attach+0x3f8
#5 0xffff0000004fdce8 at bus_generic_new_pass+0x120
#6 0xffff0000004fdc78 at bus_generic_new_pass+0xb0
#7 0xffff000000500450 at root_bus_configure+0x40
#8 0xffff00000042b600 at mi_startup+0xdc
#9 0xffff0000000008ac at virtdone+0x70

It is a FreeBSD problem, not an EDK2 problem. My old
notes on the lists about the FreeBSD problem are at:

https://lists.freebsd.o= rg/archives/freebsd-current/2023-September/004775.html

I do not know if v1.34 might sidestep the mishandling
in FreeBSD or not.

=3D=3D=3D
Mark Millard
marklmi at yahoo.com

--000000000000b6018c060ed59102-- From nobody Sat Jan 13 16:24:13 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TC3d861Gkz5669y; Sat, 13 Jan 2024 16:24:12 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (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 "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TC3d76gXKz4Zxx; Sat, 13 Jan 2024 16:24:11 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of fbsd@www.zefox.net has no SPF policy when checking 50.1.20.27) smtp.mailfrom=fbsd@www.zefox.net Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.17.1/8.15.2) with ESMTPS id 40DGOE0h021021 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 13 Jan 2024 08:24:14 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.17.1/8.15.2/Submit) id 40DGOEL8021020; Sat, 13 Jan 2024 08:24:14 -0800 (PST) (envelope-from fbsd) Date: Sat, 13 Jan 2024 08:24:13 -0800 From: bob prohaska To: freebsd-current@freebsd.org Cc: freebsd-arm@freebsd.org Subject: Re: bsdinstall use on rpi4 Message-ID: References: List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spamd-Bar: - X-Spamd-Result: default: False [-1.10 / 15.00]; AUTH_NA(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.997]; WWW_DOT_DOMAIN(0.50)[]; MID_RHS_WWW(0.50)[]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCPT_COUNT_TWO(0.00)[2]; MISSING_XM_UA(0.00)[]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org,freebsd-arm@freebsd.org]; DMARC_NA(0.00)[zefox.net]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; R_DKIM_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; R_SPF_NA(0.00)[no SPF record] X-Rspamd-Queue-Id: 4TC3d76gXKz4Zxx On Sat, Jan 13, 2024 at 03:26:19PM +0000, void wrote: > Hi, > > I'm trying to use bsdinstall on > FreeBSD-15.0-CURRENT-arm64-aarch64-RPI-20240111-a61d2c7fbd3c-267507.img > to install to usb3-connected HD, using the 'expert mode' for UFS, > after having initially booted from mmcsd. > > The goal is to boot to usb3 with freebsd on UFS filesystem, and to have > that filesystem split into partitions, and the partitions having various > properties. IOW not to have it all on /. I'd like to use GPT instead of MBR. > > Is this (bsdinstall) method 'correct' or should I use some other method? > > I've tried this method but get errors after the fetching phase. > > 1. "manifest not found on local disk and will be fetched from an > unverified source..." http://void.f-m.fm.user.fm/error1.png > > 2. "error while extracting base.txz: can't create > /usr/share/untrusted/Sonera_Class_2_Root_CA.pem" > http://void.f-m.fm.user.fm/error2.png > > 3. "could not set root password. An installation step has been > aborted. Would you like to restart the installation or exit the > installer?" > http://void.f-m.fm.user.fm/error3.png > I tried this using 14-release on a Pi3 with a usb mechanical hard disk. I don't recall seeing the errors reported above, but found that the msdos partition wasn't populated. I copied files manually. The resulting host is finicky about booting, sometimes requiring intervention at the serial console to prod u-boot to find the usb disk. This particular Pi is booting without a microSD, it's possible the usb-sata adapter contributes to the problem. It might be worth trying the "bootcode.bin-only" method to see if that helps. Perhaps others can say more. Once FreeBSD is up there have been no obvious problems. Thanks for reading, hth bob prohaska From nobody Sat Jan 13 17:03:41 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TC4Vn44Qbz56C7C; Sat, 13 Jan 2024 17:03:45 +0000 (UTC) (envelope-from void@f-m.fm) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (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 4TC4Vm6hlCz4j29; Sat, 13 Jan 2024 17:03:44 +0000 (UTC) (envelope-from void@f-m.fm) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=f-m.fm header.s=fm2 header.b=YtHfL4OQ; dkim=pass header.d=messagingengine.com header.s=fm2 header.b=9XmHSYSa; dmarc=pass (policy=none) header.from=f-m.fm; spf=pass (mx1.freebsd.org: domain of void@f-m.fm designates 66.111.4.27 as permitted sender) smtp.mailfrom=void@f-m.fm Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id D14B35C0172; Sat, 13 Jan 2024 12:03:43 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Sat, 13 Jan 2024 12:03:43 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=f-m.fm; h=cc :content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm2; t=1705165423; x=1705251823; bh=qLTjQ2vWWs dA1LvdP8jG4injCGDoHqoCg0OP8MRPkAo=; b=YtHfL4OQbnr7n1wb8lNtY7uAXJ jnjV/+yRiTPIp/1nfiXwDBEimHfmWvMEELwEDlPJCVTX+5wFdzN8i+UZVmlGK+kx l/y0NHobgblAhe/qldI/HQY6uXsHqtkovrUwJwqsXEcUQfZb9ftYghZdkIcbunUy o9d/ZT6iv+QNlgvPE7N/4Bq4DiC1jI8kzWHUyRdqj840Js8Y6OvQyBuGGkqjx8Jk CHXd/ycyqzT5J46kOqw71TAYJzqnP0D16045gXtXPLxYxEFy1lBzzQDOKPKL4xRI yUxMQcn/cX9vSxLM+C8u9AbqPYGPKw0ZUKuBCJUWZ8X3sgofgPiQuSQnd5jw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; t=1705165423; x=1705251823; bh=qLTjQ2vWWsdA1LvdP8jG4injCGDo HqoCg0OP8MRPkAo=; b=9XmHSYSa4x8FYu+2VcCHT4esyg82FAJrgEdQKQcevKSm 3oxZjV6NEVrR8a73XZSsAwdBQ0jVRyaeQae0wwTgoEPNj5xebex6mdpDWMI0b0T2 XTR83sPaLh6RzMHBhsk+lBDQgwAtMhyz9JmB7tgCsmVGr3/+vB77lxMpGrpWF6C+ qahE/cPArb6JNuMMpae0bLzuf9cXJA0bLzo6HFOyumIt8Vna98x4prneCKYZi7+O PnukB73JaW9CwikswQIuqa2gmqO6DIaCEONF5exBlYPiXwHNrxBI8ZzUMpoFkE6I CJs9H+AgzSg3Iqk4XfmkVCTRj0XekZZdfji2b2jyNw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrvdeijedgleejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggujgesthdtre dttddtvdenucfhrhhomhepvhhoihguuceovhhoihgusehfqdhmrdhfmheqnecuggftrfgr thhtvghrnhepleevvefhheeffeffheefffekvedvfffgtdffjefhfedvgeelveevudejje ejleehnecuffhomhgrihhnpehushgvrhdrfhhmnecuvehluhhsthgvrhfuihiivgeptden ucfrrghrrghmpehmrghilhhfrhhomhepvhhoihgusehfqdhmrdhfmh X-ME-Proxy: Feedback-ID: i2541463c:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 13 Jan 2024 12:03:43 -0500 (EST) Date: Sat, 13 Jan 2024 17:03:41 +0000 From: void To: freebsd-current@freebsd.org, freebsd-arm@freebsd.org Subject: Re: bsdinstall use on rpi4 Message-ID: Mail-Followup-To: freebsd-current@freebsd.org, freebsd-arm@freebsd.org References: List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.99 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.989]; MID_RHS_NOT_FQDN(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[f-m.fm,none]; RWL_MAILSPIKE_EXCELLENT(-0.40)[66.111.4.27:from]; R_DKIM_ALLOW(-0.20)[f-m.fm:s=fm2,messagingengine.com:s=fm2]; R_SPF_ALLOW(-0.20)[+ip4:66.111.4.27]; RCVD_IN_DNSWL_LOW(-0.10)[66.111.4.27:from]; MIME_GOOD(-0.10)[text/plain]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; RCVD_COUNT_THREE(0.00)[3]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; FREEMAIL_FROM(0.00)[f-m.fm]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MISSING_XM_UA(0.00)[]; ASN(0.00)[asn:19151, ipnet:66.111.4.0/24, country:US]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org,freebsd-current@freebsd.org]; FREEMAIL_ENVFROM(0.00)[f-m.fm]; TO_DN_NONE(0.00)[]; DKIM_TRACE(0.00)[f-m.fm:+,messagingengine.com:+]; DWL_DNSWL_NONE(0.00)[messagingengine.com:dkim] X-Rspamd-Queue-Id: 4TC4Vm6hlCz4j29 On Sat, Jan 13, 2024 at 08:24:13AM -0800, bob prohaska wrote: >On Sat, Jan 13, 2024 at 03:26:19PM +0000, void wrote: >> Hi, >> >> I'm trying to use bsdinstall on >> FreeBSD-15.0-CURRENT-arm64-aarch64-RPI-20240111-a61d2c7fbd3c-267507.img >> to install to usb3-connected HD, using the 'expert mode' for UFS, >> after having initially booted from mmcsd. >> >> The goal is to boot to usb3 with freebsd on UFS filesystem, and to have >> that filesystem split into partitions, and the partitions having various >> properties. IOW not to have it all on /. I'd like to use GPT instead of MBR. >> >> Is this (bsdinstall) method 'correct' or should I use some other method? >> >> I've tried this method but get errors after the fetching phase. >> >> 1. "manifest not found on local disk and will be fetched from an >> unverified source..." http://void.f-m.fm.user.fm/error1.png >> >> 2. "error while extracting base.txz: can't create >> /usr/share/untrusted/Sonera_Class_2_Root_CA.pem" >> http://void.f-m.fm.user.fm/error2.png >> >> 3. "could not set root password. An installation step has been >> aborted. Would you like to restart the installation or exit the >> installer?" >> http://void.f-m.fm.user.fm/error3.png >> > >I tried this using 14-release on a Pi3 with a usb mechanical >hard disk. I don't recall seeing the errors reported above, >but found that the msdos partition wasn't populated. I copied >files manually. > >The resulting host is finicky about booting, sometimes requiring >intervention at the serial console to prod u-boot to find the >usb disk. This particular Pi is booting without a microSD, it's >possible the usb-sata adapter contributes to the problem. It >might be worth trying the "bootcode.bin-only" method to see >if that helps. Perhaps others can say more. > >Once FreeBSD is up there have been no obvious problems. I've used this method with 13-stable and 14-stable, but wondered if maybe it was depreciated in 15-current. The showstopper is the error marked [2] which is within seconds followed by [3]. If it was just [1] then I could work around it. -- From nobody Sat Jan 13 17:31:07 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TC56Q2w81z56FVq for ; Sat, 13 Jan 2024 17:31:10 +0000 (UTC) (envelope-from void@f-m.fm) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4TC56P5rtFz4mjF for ; Sat, 13 Jan 2024 17:31:09 +0000 (UTC) (envelope-from void@f-m.fm) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=f-m.fm header.s=fm2 header.b=XJWq50RF; dkim=pass header.d=messagingengine.com header.s=fm2 header.b=Sm1PKIev; dmarc=pass (policy=none) header.from=f-m.fm; spf=pass (mx1.freebsd.org: domain of void@f-m.fm designates 66.111.4.27 as permitted sender) smtp.mailfrom=void@f-m.fm Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 8A7775C00A7 for ; Sat, 13 Jan 2024 12:31:09 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Sat, 13 Jan 2024 12:31:09 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=f-m.fm; h=cc :content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm2; t=1705167069; x=1705253469; bh=75fyVJZ5ht 0tcH3tPA037wapr8/ZBZwOBxovuS3w974=; b=XJWq50RFQpyZsWCcpmaYz7MX8u VTpwmg9pbwpKN4NEfp4BijG+uksPV+KLX0/E9sihopJt6+wCokL95CDs4qxCNR/w Ee/bEU4FcQ1C1kLtWUdd/pWvmhyAhwnuSZ9gCKNdxOQOyydXskzhrzsdpMnaEtAR RvVOvY92/L1mXSQ6GbFq/r5pyfVDtYSzm7mSA92ZWMAbeBR8gx7jx7ZydwoRspoa ecLKO6Xxr6HRlHQ5Lya3SROu+HHiJIZWuL18NcG2nOo6lLgvwl2ko3c+pQh2Ffc6 wGBZGQTtJPzN9H6hWhfGgNmd/8A5Hp/KFr9b85foT8HtKDgSZO3sZdBwjVCQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; t=1705167069; x=1705253469; bh=75fyVJZ5ht0tcH3tPA037wapr8/Z BZwOBxovuS3w974=; b=Sm1PKIevY6E0RzFqLi61uEdUznu9r2/AU0qTj/nngX8c XiYCtlxvzu8F4GHOsq65MN0hcmwlqA+AtPSkaQ/UnIy0FyOReu37s5RbgouR6GYb OG4EEXxMgXCugtFAoUgAx+qoZPkM6p5kihX4DDiSxWgj9HJBzuiy4ayupZnHbWEU HiJvJWOGuNEqjwGpes/EqHoVn+64r8mdxwtDRlMKu3aGhhngtlemoOoyrd0AbXbz IAUH0KWEHUJUuODmMpBvIP2K71LbdmzS7VUXWyrVUvTnGoYYzGVHcSm4Z/cmcL2D 1sFK/aJtn6RSEqQa7p4wzlyRxpkHvFWuNh5VRUQQ5w== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrvdeijedguddtvdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepfffhvffukfhfgggtuggjsehttd ertddttddvnecuhfhrohhmpehvohhiugcuoehvohhiugesfhdqmhdrfhhmqeenucggtffr rghtthgvrhhnpeekleduvdelhfeileefgffghfffkedtheellefgudfgvdegkeejjedutd ehhefgueenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhm pehvohhiugesfhdqmhdrfhhm X-ME-Proxy: Feedback-ID: i2541463c:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Sat, 13 Jan 2024 12:31:08 -0500 (EST) Date: Sat, 13 Jan 2024 17:31:07 +0000 From: void To: freebsd-arm@freebsd.org Subject: Re: current for arm64 tries tftp first for some reason Message-ID: Mail-Followup-To: freebsd-arm@freebsd.org References: <0DB5FDFB-184F-4260-A060-ED6A6CAFE546@yahoo.com> List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <0DB5FDFB-184F-4260-A060-ED6A6CAFE546@yahoo.com> X-Spamd-Bar: --- X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MID_RHS_NOT_FQDN(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[f-m.fm,none]; RWL_MAILSPIKE_EXCELLENT(-0.40)[66.111.4.27:from]; R_DKIM_ALLOW(-0.20)[f-m.fm:s=fm2,messagingengine.com:s=fm2]; R_SPF_ALLOW(-0.20)[+ip4:66.111.4.27:c]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[66.111.4.27:from]; FROM_HAS_DN(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_FROM(0.00)[f-m.fm]; MIME_TRACE(0.00)[0:+]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[f-m.fm:+,messagingengine.com:+]; TO_DN_NONE(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; MISSING_XM_UA(0.00)[]; ASN(0.00)[asn:19151, ipnet:66.111.4.0/24, country:US]; FREEMAIL_ENVFROM(0.00)[f-m.fm]; DWL_DNSWL_NONE(0.00)[messagingengine.com:dkim] X-Rspamd-Queue-Id: 4TC56P5rtFz4mjF On Wed, Jan 10, 2024 at 03:16:49PM -0800, Mark Millard wrote: >U-Boot is doing tftp activity before the FreeBSD UEFI >loader has been found to be loaded. So either the >sysutils/u-boot* port's choices for how/what to build >or U-Boot itself if building can not control the issue. The issue is no longer present in the latest snapshot main-n267507-a61d2c7fbd3c thanks -- From nobody Sat Jan 13 18:00:31 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TC5mG3XkZz56JQ2; Sat, 13 Jan 2024 18:00:30 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (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 "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TC5mF3RKFz4sJP; Sat, 13 Jan 2024 18:00:29 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of fbsd@www.zefox.net has no SPF policy when checking 50.1.20.27) smtp.mailfrom=fbsd@www.zefox.net Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.17.1/8.15.2) with ESMTPS id 40DI0Ve6021238 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 13 Jan 2024 10:00:32 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.17.1/8.15.2/Submit) id 40DI0VqD021237; Sat, 13 Jan 2024 10:00:31 -0800 (PST) (envelope-from fbsd) Date: Sat, 13 Jan 2024 10:00:31 -0800 From: bob prohaska To: freebsd-current@freebsd.org, freebsd-arm@freebsd.org Subject: Re: bsdinstall use on rpi4 Message-ID: References: List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spamd-Bar: - X-Spamd-Result: default: False [-1.10 / 15.00]; AUTH_NA(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; WWW_DOT_DOMAIN(0.50)[]; MID_RHS_WWW(0.50)[]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCPT_COUNT_TWO(0.00)[2]; MISSING_XM_UA(0.00)[]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org,freebsd-arm@freebsd.org]; DMARC_NA(0.00)[zefox.net]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; R_DKIM_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; R_SPF_NA(0.00)[no SPF record] X-Rspamd-Queue-Id: 4TC5mF3RKFz4sJP On Sat, Jan 13, 2024 at 05:03:41PM +0000, void wrote: > > I've used this method with 13-stable and 14-stable, but wondered if > maybe it was depreciated in 15-current. The showstopper is the error marked > [2] which is within seconds followed by [3]. If it was just [1] > then I could work around it. IIRC I didn't use the automatic setup, but rather the manual one. Perhaps that changed something. Also, I was using the snapshot for 14-stable on Pi3, that might be quite different, intentionally or otherwise. "Can't create..." a file looks like a permissions or sequence error, with one of the intermediate directories not created yet. ISTR a thread on this general topic saying to my eye that bsdinstall either didn't or couldn't deal with partitions outside the UFS filesystem. If you got a working msdos partition then I'm badly mistaken. Can't find that thread now. Thanks for reading, bob prohaska From nobody Sat Jan 13 18:32:05 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TC6T33fMbz56N9R for ; Sat, 13 Jan 2024 18:32:23 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic314-20.consmr.mail.gq1.yahoo.com (sonic314-20.consmr.mail.gq1.yahoo.com [98.137.69.83]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4TC6T24M7Xz3xtR for ; Sat, 13 Jan 2024 18:32:22 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1705170739; bh=9Jp1lJIlYWA96yCKOX4k8+VeyTwpA8BOhGASC3RMXJM=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=NmIiSn9WmMk9IpDXIMBT26qpOYwNcmAftPoiWVlEwvzeIGemuWBkzg7dVH7wWaB0EnYIyUyr7y93D9kjLEpXUMX0MVy+KKOUwpi27EaBHcOTQuxsj5bOsaKbtw+ipSzHXVSXjZc/kz2tR+JG6AOR5zzBtsYYTRSLEYDwBheggpY9BEQO+wzwTRy4gkO4cq/x1wIPr7s8hFH5Oie/BfNO6WX3IHzI2AP+2uuvR7AXmHS/kkk3VExcyOyRQ5+R5rjwaFKiJEItW4ffGyVO7Al/VCWDJuhCFlQ4ru++0TBXoP4TH99oRSHsY1rRmE1PSZZA1+eaJg9jhVKQ3wwkRhUvsw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1705170739; bh=nurXbxV9DOzWKjqjqCTWi4IYEhePhq81YHpn/g8V+FE=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=k8csR0FVxz24CwzzSgie90YOKEVVVfw1pIVESohFZVyQ4Kct4gSl9RfmSyDIrN6sV5WzFzRGZ2a36O7s1TDGAqU5ppRQrRrVBY+st90FVwB7yLBQussnnBmB4l67JmBMDmY7Rli+zprr4rZATHxysuEQpQElGUgY7Nu6o9hyuSvumOhMMwbl+wjKSL5ptZT2XR9GoMlDEjbJFSHWiFEfHbzE6jIfrsWgxYVIpE4NfOZAEXLz6SAdAln8bcTEC2pr7+/hcTvx3uuBBh5dQqyW4+3BmzPcNoaqr3YaEF9eB86MiJK4op44UF3wSKZVE2rSp7xPlnKq4B/KX+CMLNNbfg== X-YMail-OSG: h03aN4QVM1mVNclED9OAyGsAbQuXIQmvtcL799GhNAupUNUzwogaJ28O4YYo0Ta ZvAl9tXAihjolED31.qU3uWyUv7cGiOzcF28s3_8mYIh3TfltIwKgkny95NBiMkw95tQuZ9T8hNI lWyU.Tdgh7LHwHmYn.dNHlTtHdwYGKDf5qaaIPrvT9L08Uu7c8c0T6YEEPYnv7l1IeqEGAUKCG_h _K0rSZwewbSsgHr6RwpdaFYaUsBryNJkCToebYRlcYZzp5jgygvH8tXXR45nl6oIw01FvS.b5RTz 5.6ALtyfiCs64GFoEm28l0w2IUSJnfPi9PiWb49oMJqsVW7I_bHY74B6LcpZYMHy4kRaESPI3jud R9CsYHHOL78bN7U6wa5UlRQMOVgjbWG4jPL79HEDIcy27T3nujguAPMyazerOSIeI.mfD6fXJrKc DJLK9R.7dVK6dItjUjO0l36WnYc7..JcYJyoIxmAA.30QCeYaX5edWetsBDjj6dmCkVyjCe15KrH 8nFZq0opryIQA.eVn.b0A92DaalmcfD9flRUadkpas7skAFI.Zw_qtjEmfpVjxh6.IqD.LWZJfJP R_0J0BoSvG4T8xgNGL1TSjREt5.wP7mDTsxUgFp8kVmGKkLSjfJjCTJ753p7.iN2wQs2XzA8UbQ3 GVRsgWvUZiSj7teklQNXZnuptq5LVtYwz5.JEuD4.kP4OhwkJm.MuHfVDOvzI6ltSm9XCAPD458I cJILd8UqJDoZZb7MSIw6wLzXOn7bo9P1zz2Ub63H0hZY7OQ2MUa06cmDmSIL72STBKGHTIqNHAPU kHHtgpXvyU8lUGWPDgta7I5BNcx_bDdeyg1paa2BhtqQm5tl8PgwzaF_JEdMbp3U.O7xwPgRf.oE qgNdbCA8ZZs3YQIv79Hr5eZGp3iQzGn_0VUT6kZgr3nsAkVnb0mn2Zyc6JejhWRAvAYLxPLuHRgD .Mwf2ZHlBwzCB_9I0.eImnHJtvc8kH5NwO0PeqkK_H2zLaLCWrphxkYTGW02s9AmUyfAIsihJAnc HqrP_Z7wxiI1YLLkJFfSU2dKenr.kSKJH7HOAPfno83UrJjQl.OjJQxy5Nzyu.xjlN6Gi5_N_LxT F2EJBvVVJIPBVJ6oj8NDMKi2emDqvU.6cvHjYKGNr2w9ezCPXT5GGQ732WzJDohxs8mklNKtsHUk w5S3a_7k8XZuFIsX2eKHaoraNsAxJa6FaG5pw.50VFOhdl4D.Qu0MwTK3oWZ5lt5FobnVVMRICry gNR7GbPHxvmWaxHITtLWOISVOTw1EEdwVYZVZ7TjqgSRbCiN1vioDMQVBIZKRGFBkeXQ9hSrfpPe K2IPWtDXaAvUd5zZNcrL.sFkDHaccgRRT3dBzclWh1LcBFTOEVxGLcnYldV7QnU7RYcRmjEhJeTk gR00Yte2BQqy5wH72EwkwO11mu_b.yTZ0q2vtVEz_.BpG47bsiH9Gkc8xzkhFth4leRVTcxwzOcA L2wR258VVyp9naH3pIPkCCp8lWnE3ZHp2EoHiUq.XzTKe2lkOw13bcMPm.deJ1IH8aUgd1T7US_X ng0keA.vmylUcbtjtc8D0noXcgMsBpRJbCyKpKGXVDUIYGt_cq1_oQ5blqlFvfw0N2hKnSZ7BSoQ jOlaFiXV1_VAneURrYILh7fqvbXJmWHThP1mQOqs05aexnHBLKGkRfg3JiDrnXXpIRarFfTnRryy XrPPFtQ8RHld.WwSS2G9mqolNALuE9qIJ6ACnTW5xkxIzp_Igb8qhDxK5p8Fzd5vcf93sNB7r_N4 eeCk5T_JQGmeMrRSlB5XZLR.TcHP.ivJaJbNIuICNU5rV.QCxPSSvv.FFhTlb34oXTbS9EwGpFS4 qnHHnTY4hyMUp1RSass9W67wwyUuu29SO8UlAHkPx19Pex5ihCCIr9BlVWyUz4i4gbkZVXtrucYH f5bGlysuut9_n7nHZOU272QRb9dihxuPo9E4HLqbtiPMJo4IBnFSgkGCohLGEf21kegD.BFWLiAz R.T9bNCU.Nrw5j7aL_Uy6rzjH8SlOhMYNCxXouyQM6pN0rhX9YDcj5JfPIO.YYP0.HoSOE1MIopH R1zkKcl842utfUW8onMHjh1w2oIzElqIKtJexY8ctxN2FimpIdMommcud83U9wAVchwT6LGQyNSh ANIXe63yUZJ0aT7HZYvK5lQBYXp3V.qHqqiZY6N_mvI_nA3dquH_DbFLCBBc6inArX05A6AZzKJ4 L.DIwx6vJ9s8hdRtmM8rG.O3JEQDZRiampfmStWrTHdcvYccWZRcVg7c2TDlsKaoP9jGUUCiL7Q8 xxbU- X-Sonic-MF: X-Sonic-ID: 72dab01f-8198-4637-90c1-071f8e98e4a1 Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Sat, 13 Jan 2024 18:32:19 +0000 Received: by hermes--production-gq1-78d49cd6df-mvdth (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID fd2b0ac24579877c9c30850d7f7b8ba9; Sat, 13 Jan 2024 18:32:17 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.300.61.1.2\)) Subject: Re: When will FreeBSD support RPI5? From: Mark Millard In-Reply-To: Date: Sat, 13 Jan 2024 10:32:05 -0800 Cc: Jesper Schmitz Mouridsen , John Kennedy , ykla , FreeBSD ARM List Content-Transfer-Encoding: quoted-printable Message-Id: <76FA010A-338F-4E32-B381-37C7BA63CAFC@yahoo.com> References: <5a39810c-5fd8-4969-a222-2561b050b035@FreeBSD.org> <347FE009-A470-4765-A9B9-7C9AB5E954DA@yahoo.com> To: Doug Rabson X-Mailer: Apple Mail (2.3774.300.61.1.2) X-Rspamd-Queue-Id: 4TC6T24M7Xz3xtR X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] On Jan 13, 2024, at 07:38, Doug Rabson wrote: > Getting back to the RPI 5, with a tweak to = arm/broadcom/bcm2835bcm2835_vcbus.c to treat the memory config the same = as RPI 4 and to dev/sdhci/sdhci_fdt.c to treat the RPI 5 sdhci = controllers as generic, I can boot to multiuser mode using the EDK2 = firmware from https://github.com/worproject/rpi5-uefi with ACPI/Device = Tree mode set to Both. What does FreeBSD do with "Both"? Does it actually use some ACPI and some Device Tree? Or does it just use ACPI? Does your combination do anything different than just using ACPI? > This does not have working PCIe or ethernet yet - I think ethernet = ought to work since we seem to have a matching driver in the tree in = dev/cadence. Sounds like the same status as booting just ACPI with no such adjustments too bcm2835bcm2835_vcbus.c or sdhci_fdt.c ? I think Mike Karels plans on investigating getting Ethernet going based on cgem . I've no clue if this is ACPI, DeviceTree, or both. My usage has been pure ACPI, no software adjustments specific to getting the RPi5 operational. Use of a USB3 Ethernet dongle. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sat Jan 13 19:04:55 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TC7Bm0ZMcz56RZd for ; Sat, 13 Jan 2024 19:05:04 +0000 (UTC) (envelope-from mike@karels.net) Received: from mail2.karels.net (mail2.karels.net [3.19.118.201]) (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 "freebsd", Issuer "freebsd" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TC7Bl5skTz444G for ; Sat, 13 Jan 2024 19:05:03 +0000 (UTC) (envelope-from mike@karels.net) Authentication-Results: mx1.freebsd.org; none Received: from mail2.karels.net (localhost [IPv6:0:0:0:0:0:0:0:1]) by mail2.karels.net (8.17.1/8.17.1) with ESMTP id 40DJ4u4J074423; Sat, 13 Jan 2024 13:04:57 -0600 (CST) (envelope-from mike@karels.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=karels.net; s=mail2; t=1705172697; bh=ZDZrmh+Iv8pQy/wAD7vk0hdpCQVP9TYKm7S4tlVApno=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=G8YOHaceeeoLigfjCQlI7WIseDqWFwev2cFP0ElcBGq4Ct7HT17rnEFvMiKPbo4gv 8tvr04Y5fvd3kFIxjni5YHxTB5ECXq2IBvqOGZ3QAoALulZXn54i1L3Dquo/ms1VyV 1c5UHSrgGYr8xGN10rq/Su8NmNs+lvUDbPdtbZ8TpkszoH2kzysLSpuoGEw1NVqhSG BPWoUR/Bsqkh0B4V9t3EtxUzsVe7NaEQaaYVjnVLDziNT+1FmMJLTtPE+DZokCdbQW phPUMa+LhZuqQHm2ZM0zZ4dNpXaXKRqHvPO7F3xdBL5BVHq7AXPyWAv8X/uyNUVaRP rAlwQdR/2ckAg== Received: from [10.0.2.130] ([73.62.165.147]) by mail2.karels.net with ESMTPSA id aFuuMtjeomW1IgEAs/W3XQ (envelope-from ); Sat, 13 Jan 2024 13:04:57 -0600 From: Mike Karels To: Mark Millard Cc: Doug Rabson , FreeBSD ARM List Subject: Re: When will FreeBSD support RPI5? Date: Sat, 13 Jan 2024 13:04:55 -0600 X-Mailer: MailMate (1.14r6015) Message-ID: <1C02D1FA-5BF0-4C82-AD0E-6F9E5EB8A0B9@karels.net> In-Reply-To: <76FA010A-338F-4E32-B381-37C7BA63CAFC@yahoo.com> References: <5a39810c-5fd8-4969-a222-2561b050b035@FreeBSD.org> <347FE009-A470-4765-A9B9-7C9AB5E954DA@yahoo.com> <76FA010A-338F-4E32-B381-37C7BA63CAFC@yahoo.com> List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4TC7Bl5skTz444G X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:16509, ipnet:3.16.0.0/14, country:US] On 13 Jan 2024, at 12:32, Mark Millard wrote: > On Jan 13, 2024, at 07:38, Doug Rabson wrote: > >> Getting back to the RPI 5, with a tweak to arm/broadcom/bcm2835bcm2835= _vcbus.c to treat the memory config the same as RPI 4 and to dev/sdhci/sd= hci_fdt.c to treat the RPI 5 sdhci controllers as generic, I can boot to = multiuser mode using the EDK2 firmware from https://github.com/worproject= /rpi5-uefi with ACPI/Device Tree mode set to Both. > > What does FreeBSD do with "Both"? Does it actually use some ACPI > and some Device Tree? Or does it just use ACPI? Does your > combination do anything different than just using ACPI? > >> This does not have working PCIe or ethernet yet - I think ethernet oug= ht to work since we seem to have a matching driver in the tree in dev/cad= ence. > > Sounds like the same status as booting just ACPI with no such > adjustments too bcm2835bcm2835_vcbus.c or sdhci_fdt.c ? > > I think Mike Karels plans on investigating getting Ethernet > going based on cgem . I've no clue if this is ACPI, DeviceTree, > or both. The cadence/cgem driver uses FDT. I haven't looked at details yet. The = addition might be as simple as adding a compat string. Hopefully it doesn't requi= re major surgery. I just ordered an RPi 5 (8 GB); it will take a while to be deli= vered. Mike > > My usage has been pure ACPI, no software adjustments specific > to getting the RPi5 operational. Use of a USB3 Ethernet dongle. > > =3D=3D=3D > Mark Millard > marklmi at yahoo.com From nobody Sat Jan 13 19:22:07 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TC7ZT5qGkz56TFt for ; Sat, 13 Jan 2024 19:22:09 +0000 (UTC) (envelope-from jsm@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TC7ZT5KJ7z46Ll; Sat, 13 Jan 2024 19:22:09 +0000 (UTC) (envelope-from jsm@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1705173729; 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=VOqXgyBbawo4hCTb9GC0Lak2nVyMItPWnRSs17IQpsU=; b=Wu68pMJOwM3I/B6qsjUPCpCFyggv8LLBqcumoEj3R2mWpGGY4Y79ZFclJK/VY+jWt6YyVR AXSSpX+P+ivr01mahGHa+eNEg5pK7Cn4BrvBSXlOyiU4qY11DJ41c0WpW93yP5MzD7uFX+ x5oh/JGNR/BMgiacYLwcJM5zs3oJ+XtMKWW/ihPJpur/OFoBVoUY/dLhWZgP4yl6NbYhkN rvdjbL5LY1Tp5TsCFby1pAbgyr3ww4CVHL/BJTSzIOnbpq8pdH80VlxHZGxhiFFd0DdOB4 1DShppRw1ciXJ/vSHlVVeM2WhS0ITca6N1/bOvQHSbmvMO4EBcsV+zr8Kuarpw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1705173729; 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=VOqXgyBbawo4hCTb9GC0Lak2nVyMItPWnRSs17IQpsU=; b=g9sRYhf04ZN0dnPqss/fu0ozuUCMYJMMQRBe2pi39wXcc2zBVV9vZoC8XgW7zMpesvvWje DsJySL+p/YyvyzU6mFcQUTcafS56zUb1sNwIBaVeILrg1rRlm+claNvn1i+vKVZQovayAI FriLebjOkqH6VT+gnte2UrkH5aG8VZJe5QHB1Z5U4FB2gg5RkjfISwYzU+AXlZeanQ6pZB KWRMbskzDKgBgWRl12bdi13G5aksuQryl+S0IsWzlHI9ghMy/I3UiRbHCCbWtWlbhpJew2 Z1k2ih+CYLYuhls/krgsL/MebfW1OY2pNWydmf6cDaGx1/OBOkqVlhH3miTldA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1705173729; a=rsa-sha256; cv=none; b=jvC34+MZCbvOM1EWTciVrz2DdQmIV/8soLF7Ssghi1LuxQPLGJjVbSDmmH6GHkdLyayyR0 qJQVTWikymQd+eqp/MZOlLt3JQwk7n6TX/I6Q3eK9mSe5yEwwirvPxosvRW4mZcQJEbfj0 xlrNawR85b6yUqdeTd2yJ/0Vj+c6YZIuDuqka5wYK+Nwx4ASHJ0bl4AvL1m7wqwlX9qse0 axIFO1q8B0btnOD1BYzjw5r6RutvHZ0pt69xzrWjbZQraoBbT8K6gC/UQQVFtZ3Z5UCMYo qgiAMPS67vdD3wJpcMwKfyxWdFWjkF4mYGE8I3afAJIm5rjAc8FdUE1U2sOGwQ== Received: from [192.168.1.5] (mail.northatlanticmusicsupplies.com [212.237.182.202]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: jsm) by smtp.freebsd.org (Postfix) with ESMTPSA id 4TC7ZS6yqkzQfj; Sat, 13 Jan 2024 19:22:08 +0000 (UTC) (envelope-from jsm@FreeBSD.org) Message-ID: <9e45c7d7-450c-48e5-8101-c6ea5cb3a023@FreeBSD.org> Date: Sat, 13 Jan 2024 20:22:07 +0100 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: When will FreeBSD support RPI5? Content-Language: en-US To: Mark Millard , Doug Rabson Cc: John Kennedy , ykla , FreeBSD ARM List References: <5a39810c-5fd8-4969-a222-2561b050b035@FreeBSD.org> <347FE009-A470-4765-A9B9-7C9AB5E954DA@yahoo.com> <76FA010A-338F-4E32-B381-37C7BA63CAFC@yahoo.com> From: Jesper Schmitz Mouridsen In-Reply-To: <76FA010A-338F-4E32-B381-37C7BA63CAFC@yahoo.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 13.01.2024 19.32, Mark Millard wrote: > On Jan 13, 2024, at 07:38, Doug Rabson wrote: > >> Getting back to the RPI 5, with a tweak to arm/broadcom/bcm2835bcm2835_vcbus.c to treat the memory config the same as RPI 4 and to dev/sdhci/sdhci_fdt.c to treat the RPI 5 sdhci controllers as generic, I can boot to multiuser mode using the EDK2 firmware from https://github.com/worproject/rpi5-uefi with ACPI/Device Tree mode set to Both. > What does FreeBSD do with "Both"? Does it actually use some ACPI > and some Device Tree? Or does it just use ACPI? Does your > combination do anything different than just using ACPI? How does the sd card show up? BTW i did put some stuff here [1] I could not get bcm_dma to work anyone planning on getting that to work? it should be similar to 2711 documented in [2] >> This does not have working PCIe or ethernet yet - I think ethernet ought to work since we seem to have a matching driver in the tree in dev/cadence. > Sounds like the same status as booting just ACPI with no such > adjustments too bcm2835bcm2835_vcbus.c or sdhci_fdt.c ? > > I think Mike Karels plans on investigating getting Ethernet > going based on cgem . I've no clue if this is ACPI, DeviceTree, > or both. > > My usage has been pure ACPI, no software adjustments specific > to getting the RPi5 operational. Use of a USB3 Ethernet dongle. > > === > Mark Millard > marklmi at yahoo.com > > [1] https://github.com/jsm222/rpi5-stuff [2] https://datasheets.raspberrypi.com/bcm2711/bcm2711-peripherals.pdf From nobody Sat Jan 13 19:43:30 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TC83P01kNz56W6V for ; Sat, 13 Jan 2024 19:43:45 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic317-20.consmr.mail.gq1.yahoo.com (sonic317-20.consmr.mail.gq1.yahoo.com [98.137.66.146]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4TC83M3hBbz49td for ; Sat, 13 Jan 2024 19:43:43 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=GwdUeq6E; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.66.146 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1705175021; bh=ajjUcnsFHOGozqZL6LLe40vejXYzFTVLTSl4O21fNMg=; h=From:Subject:Date:Cc:To:References:From:Subject:Reply-To; b=GwdUeq6E3GZbs11bJshkFlLOpfVECUVTgYAhcYlh4DpKFHt3ktwzYMKkwu3MSbS2SvAaRcHxnDVIc+A9lxAMj/gfHgQsljBaAwJXgArhZtfZHzN/YLJIpa8T8YzWORu7+9TjmhgnN5HIomTfxka3f0nu4cp/lsjHsD5O61ZlSjSV6hwQzF56z5c3tN5f3qaNK/1T3q2oR9FFF00l4tnwv8PDvDkUGtGkplP7Egg0gdB+75hfAUa76NmMlSCNFEDZ2NKGM76U1J4irtXrgdu15L15zIeq/VHH7wuPWgHffNli5qpprVw9cobWdx+5UnuCMr4qomFDDtvED9I49pER8w== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1705175021; bh=C5XsoUIXTfpS8VpmzeVu3rVNwu6x9qvA90Pi/cTTFv1=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=Qg7i8KiB7fbuOrCWFhFzc4xrWoczTN2vU+30Oc7C4dEnKwNDucCRXsf0FeFtMXkMxXfM5nDT9Q98WOueTe0VDFo7/aVd/6UZH5FSFKvk4MT9XP4/ogAcF4QuTz+qVc6DGRM2U2ZlBxlbP7y7u78qhCn8Qz8v77Rp48eze1ip1G7nYv+7A3AIZ97o2r+tcTKoZ9+rZyBVDKH/Wf/AA1qAGUTyJjePXWPeFwYyGbFxuhb2X/odUIQJzxNZNxbFer0XeIAYc6G728jsKqcWbHHP02x16d+4ECMA8VQX/xgo0ioAxnf+ZtAvxKF1+0FFieqZmYbZnQCXBNKfQBFm0ArDQg== X-YMail-OSG: VHw4_WcVM1nGR7IaqrudEQoz.7ja9CYaNognMdifSHp96QemHK2NdpGrrdeO3qb xTjmLoiAgpMDCx0ugHXGKYZteNnWQmdzgTC73OtMadFxaTOoZ0BXX07hktI0QhJu5gHZxn.A8esg 1cNGMHKMPwybaotrhq6qkWsDV_u1aDl_8bWyXqbrSy74nMQoGGfGoWQZ467BuYLbkt3osDR9qNR_ vsBv0ook5p4KuxcR.8Nx5nbiteITnLnseeZGn8ycTPQPjclqVArj3il_pXXEn_jEHuoOeUjeLI8u ybmuIh2ilSQqgVP6yWe9o7weolCXsyBvcHfax81LCLB_va4f.BA2gSowXNTPH9Xvl2dstncuvS1J plKyxsvCBVuK1Iy2hO8K8hQTqwk_klYmF_N_FVHfD_SpbY02BIKV3_gPVZQzZX2x9kmmi_71Fjc_ spMIEHoIT3fW9ChQcZ_Sklp5xO7ZVbET2it4BegHDjPIf9.I4Vwzr_GC.ntr7IgjyV7qYUfDVbp6 mxsOqA2LTfsLP33GplHkjVuV8WfAH1P9WAD49LXPBVYQfiP3lttMVt5J7NXDo9QJZ.5.UVxAe6g3 KnexCnw7mT4u2.3is7i7IJuQ14FAomQRU_ftwzECVjaF.e5nnwceUbyHYxbvWC0PcYEKx15CBJHF PZB7QRFgNR.zSdCW.uMsLPathW1_qCfeMM4og6rM5vpOQcfaTocZ8GVE41_ueoBGSfj9u1LWaCxU WoiFQuFZivYGt9rUcK8_1TGOg5oBsBYUubjIqmd9.sY5Ub5I4TRORCTb5IUATuKRHsqG4v4lu0Or 3fu7U8ISNDcW3x4O0NmQqTOW2zFsEdg78gJlI0uoYXES5UMioNtUTZGb10dTA_bHio0apg7mRaBC yvCYZQfQeGhMiskcnus36LMhpXbTDAZZR8vJoGyPsyhRmOpnh8ylbhpmym5AZmpQ0Y0ccZ176umd NkDXW_t6_VvBYjQShO8.v7_VXtk5C7YOSolJyb9Wcm91_L9mhfRy5254Fws0t.gijbaoeEdg3N5t 7UAIAMEJ7bSgqNMSwr7QV3i9syA12tLxt2suxsdeX11.apyDFZBPHe0fspinphs09y5HCLf2vy9Y FWIYmVfw5Y6.DG7P0Gowyt6WddebWkrxHFubKpArqJatWEzzl9Omz6wfBtaltR1JPbEWC4W.D9OP ZQzc4DMwlfPFLI8hsgZ740UBec0qB0RcjftJ6a6MlIneFRVYuOdnGaMjs.3GMBAFU6tZGfhevz_7 8CVKeQIDCBahq.N0ZpC.el.JDJj3FT0L8.f2SV9Ij.xutksMVEyJM5fiTnXvN2a95DXli8S6rAFG Xmw9eRjUEPhcjxwuPBojVM9yLo.BncVfmoAIYoR9OAfQVgPrAYaFFx1yrq5s.wtnIOPWzk_fU4ar 1Oiaz56mkPBCjsw1zG0Ao3GRAZAUytk6l6z9xL7pUlVBOreSDfexb8YFVcC6CjS477FfAsPlyylH s0K2.kWIL3AY3Mgwy0OAnE3DnsTniSinQGIIK.2QTPldD81eCiAmKXSFvKcY_2jdUddwnSzasX1s .Jqwu.OP7dqSIEVegQIV47wDwT1zBiDESFWk0DlnPi3A.40kwpwtdzHHUMbrOTKiDUNJ.mJH9J1B yXkXfbghg12zuaRsnFgbPiTbFL4wDPigTRHN5HG3ytzQq6e8eCG_xOLmkolHw7Uj_KOSmeBRT98h _NGrRqhpE.M4wiW0864O4JH3xpZLQRZg4zlLUU1b12qr9tqEighdZqL3eCDd5SxoHwlHcGrVZx7J 2gVQly5sGyGR3O_Zo7rNZmtfR.2BSuwBLrwgKwZh2e4o3udLrAck4W1Qaa5Dlxe1S8dFIr6Z7I0J JDVZHd9iC3mpIH5gCF9Kzn5qwYuWG_cQjxiijXwr9aVvoOrsI9AOo8XtW4OvSkgaD_glgxZzvDpQ QQY7XU6uwnf74zIcyLTMmZowjPs.DCA9haI0y.uKEzGd8wuC6dqhR6OFeOIIpf9yfchf.LUfBjfM 8nF5b5cJLbm8zTybwgiYDVapnu4koT1U4rYQ8alF62M2xbELvdsP.BFz__XQgdxMGl1LYXeDjCug kkXQOubAmiOGtET2iIMc7Pdi.J53CEP.UTrLi4wuJ0fSqHJC_DZ0ieGXmUv17tRdMqa4JZI0CSsc eVBrQnOIi6DjvfnEv5K2m.OrI0aGuGdLJST9ABI0kE_VQcohNkmx9e4sfoA79ej.gnD773jy995K VVh8RVa1iOEodbQRcp.PSeWdXxanYiyRkb9Cvx9zwGCKDdNNgxBU_yrIS.JZ5RcuQ7CM63FgLIex yUg-- X-Sonic-MF: X-Sonic-ID: 39423c8f-7349-42f8-9b0c-010c44c8fa99 Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Sat, 13 Jan 2024 19:43:41 +0000 Received: by hermes--production-gq1-78d49cd6df-xzd4p (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 7ac2dff26dfb6abb56475faead637915; Sat, 13 Jan 2024 19:43:41 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.300.61.1.2\)) Subject: RPi5 via EDK2 sitting idle: eventually got various "/: inode ???: check-hash failed" and . . . Message-Id: <00474FCE-E6FA-4112-B7C3-D4FA83410474@yahoo.com> Date: Sat, 13 Jan 2024 11:43:30 -0800 Cc: Mike Karels , Doug Rabson To: FreeBSD ARM List X-Mailer: Apple Mail (2.3774.300.61.1.2) References: <00474FCE-E6FA-4112-B7C3-D4FA83410474.ref@yahoo.com> X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.50 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; TO_DN_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; DKIM_TRACE(0.00)[yahoo.com:+]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_IN_DNSWL_NONE(0.00)[98.137.66.146:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.66.146:from]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; SUBJECT_HAS_QUESTION(0.00)[] X-Rspamd-Queue-Id: 4TC83M3hBbz49td I left the RPi5 booted but idle and had not looked at it since. Well, I just looked and /var/log/messages shows: . . . Jan 11 05:11:32 R64-RPi-4-3-2v1p2 dhclient[2256]: New IP Address (ue0): = 192.168.1.153 Jan 11 05:11:32 R64-RPi-4-3-2v1p2 dhclient[2260]: New Subnet Mask (ue0): = 255.255.255.0 Jan 11 05:11:32 R64-RPi-4-3-2v1p2 dhclient[2264]: New Broadcast Address = (ue0): 192.168.1.255 Jan 11 05:11:32 R64-RPi-4-3-2v1p2 dhclient[2268]: New Routers (ue0): = 192.168.1.1 Jan 12 03:01:43 R64-RPi-4-3-2v1p2 kernel: /: inode 901792: check-hash = failed Jan 12 03:01:43 R64-RPi-4-3-2v1p2 syslogd: last message repeated 1 times Jan 12 03:01:43 R64-RPi-4-3-2v1p2 kernel: /: inode 901812: check-hash = failed Jan 12 03:01:43 R64-RPi-4-3-2v1p2 syslogd: last message repeated 1 times Jan 12 03:01:43 R64-RPi-4-3-2v1p2 kernel: /: inode 901796: check-hash = failed Jan 12 03:01:43 R64-RPi-4-3-2v1p2 syslogd: last message repeated 1 times Jan 12 03:01:43 R64-RPi-4-3-2v1p2 kernel: /: inode 901808: check-hash = failed Jan 12 03:01:43 R64-RPi-4-3-2v1p2 syslogd: last message repeated 1 times Jan 12 03:01:43 R64-RPi-4-3-2v1p2 kernel: /: inode 901821: check-hash = failed Jan 12 03:01:43 R64-RPi-4-3-2v1p2 syslogd: last message repeated 1 times . . . Jan 12 03:03:16 R64-RPi-4-3-2v1p2 kernel: /: inode 85979160: check-hash = failed Jan 12 03:03:16 R64-RPi-4-3-2v1p2 syslogd: last message repeated 1 times Jan 12 03:03:16 R64-RPi-4-3-2v1p2 kernel: /: inode 85979164: check-hash = failed Jan 12 03:03:16 R64-RPi-4-3-2v1p2 syslogd: last message repeated 1 times Jan 12 03:03:16 R64-RPi-4-3-2v1p2 kernel: /: inode 85979163: check-hash = failed Jan 12 03:03:16 R64-RPi-4-3-2v1p2 syslogd: last message repeated 1 times Jan 12 03:03:16 R64-RPi-4-3-2v1p2 kernel: /: inode 85979154: check-hash = failed Jan 12 03:03:16 R64-RPi-4-3-2v1p2 syslogd: last message repeated 1 times Jan 12 03:03:16 R64-RPi-4-3-2v1p2 kernel: /: inode 85979159: check-hash = failed Jan 12 03:03:16 R64-RPi-4-3-2v1p2 syslogd: last message repeated 1 times Jan 13 03:01:42 R64-RPi-4-3-2v1p2 kernel: /: inode 901792: check-hash = failed Jan 13 03:01:42 R64-RPi-4-3-2v1p2 syslogd: last message repeated 1 times Jan 13 03:01:42 R64-RPi-4-3-2v1p2 kernel: /: inode 901793: check-hash = failed Jan 13 03:01:42 R64-RPi-4-3-2v1p2 syslogd: last message repeated 1 times Jan 13 03:01:42 R64-RPi-4-3-2v1p2 kernel: /: inode 901809: check-hash = failed Jan 13 03:01:42 R64-RPi-4-3-2v1p2 syslogd: last message repeated 1 times Jan 13 03:01:42 R64-RPi-4-3-2v1p2 kernel: /: inode 901812: check-hash = failed Jan 13 03:01:42 R64-RPi-4-3-2v1p2 syslogd: last message repeated 1 times Jan 13 03:01:42 R64-RPi-4-3-2v1p2 kernel: /: inode 901794: check-hash = failed Jan 13 03:01:42 R64-RPi-4-3-2v1p2 syslogd: last message repeated 1 times Jan 13 03:01:42 R64-RPi-4-3-2v1p2 kernel: /: inode 901795: check-hash = failed Jan 13 03:01:42 R64-RPi-4-3-2v1p2 syslogd: last message repeated 1 times Jan 13 03:01:42 R64-RPi-4-3-2v1p2 kernel: /: inode 901796: check-hash = failed Jan 13 03:01:42 R64-RPi-4-3-2v1p2 syslogd: last message repeated 1 times Jan 13 03:01:42 R64-RPi-4-3-2v1p2 kernel: /: inode 901797: check-hash = failed Jan 13 03:01:42 R64-RPi-4-3-2v1p2 syslogd: last message repeated 1 times Jan 13 03:01:42 R64-RPi-4-3-2v1p2 kernel: /: inode 901798: check-hash = failed Jan 13 03:01:42 R64-RPi-4-3-2v1p2 syslogd: last message repeated 1 times . . . Jan 13 03:03:18 R64-RPi-4-3-2v1p2 kernel: /: inode 85979163: check-hash = failed Jan 13 03:03:18 R64-RPi-4-3-2v1p2 syslogd: last message repeated 1 times Jan 13 03:03:18 R64-RPi-4-3-2v1p2 kernel: /: inode 85979154: check-hash = failed Jan 13 03:03:18 R64-RPi-4-3-2v1p2 syslogd: last message repeated 1 times Jan 13 03:03:18 R64-RPi-4-3-2v1p2 kernel: /: inode 85979155: check-hash = failed Jan 13 03:03:18 R64-RPi-4-3-2v1p2 syslogd: last message repeated 1 times Jan 13 03:03:18 R64-RPi-4-3-2v1p2 kernel: /: inode 85979158: check-hash = failed Jan 13 03:03:18 R64-RPi-4-3-2v1p2 syslogd: last message repeated 1 times Jan 13 03:03:18 R64-RPi-4-3-2v1p2 kernel: /: inode 85979159: check-hash = failed Jan 13 03:03:18 R64-RPi-4-3-2v1p2 syslogd: last message repeated 1 times Jan 13 03:05:19 R64-RPi-4-3-2v1p2 kernel: /: bad dir ino 67307605 at = offset 0: mangled entry Jan 13 03:05:19 R64-RPi-4-3-2v1p2 syslogd: last message repeated 1 = timesJan 13 03:05:19 R64-RPi-4-3-2v1p2 kernel: /: bad dir ino 71554318 = at offset 512: mangled entry Jan 13 03:05:19 R64-RPi-4-3-2v1p2 kernel: /: bad dir ino 71554318 at = offset 512: mangled entry Jan 13 03:05:19 R64-RPi-4-3-2v1p2 kernel: /: bad dir ino 71554318 at = offset 8: mangled entry Jan 13 03:05:19 R64-RPi-4-3-2v1p2 kernel: /: bad dir ino 71554318 at = offset 512: mangled entry Jan 13 03:05:19 R64-RPi-4-3-2v1p2 kernel: /: bad dir ino 71554318 at = offset 8: mangled entry Jan 13 03:05:19 R64-RPi-4-3-2v1p2 kernel: /: bad dir ino 71554318 at = offset 512: mangled entry Jan 13 03:05:19 R64-RPi-4-3-2v1p2 kernel: /: bad dir ino 71554318 at = offset 8: mangled entry Jan 13 03:05:19 R64-RPi-4-3-2v1p2 kernel: /: bad dir ino 71554318 at = offset 512: mangled entry Jan 13 03:05:19 R64-RPi-4-3-2v1p2 kernel: /: bad dir ino 71554318 at = offset 8: mangled entry Jan 13 03:05:19 R64-RPi-4-3-2v1p2 kernel: /: bad dir ino 71554318 at = offset 512: mangled entry Jan 13 03:05:19 R64-RPi-4-3-2v1p2 kernel: /: bad dir ino 71554318 at = offset 8: mangled entry Jan 13 03:05:19 R64-RPi-4-3-2v1p2 kernel: /: bad dir ino 71554318 at = offset 512: mangled entry Jan 13 03:05:19 R64-RPi-4-3-2v1p2 kernel: /: bad dir ino 71554318 at = offset 8: mangled entry Jan 13 03:05:19 R64-RPi-4-3-2v1p2 kernel: /: bad dir ino 71554318 at = offset 512: mangled entry Jan 13 03:05:19 R64-RPi-4-3-2v1p2 kernel: /: bad dir ino 71554318 at = offset 8: mangled entry Jan 13 03:05:19 R64-RPi-4-3-2v1p2 kernel: /: bad dir ino 71554318 at = offset 512: mangled entry Jan 13 03:05:19 R64-RPi-4-3-2v1p2 kernel: /: bad dir ino 71554318 at = offset 8: mangled entry Jan 13 03:05:19 R64-RPi-4-3-2v1p2 kernel: /: bad dir ino 71554318 at = offset 512: mangled entry Jan 13 03:05:19 R64-RPi-4-3-2v1p2 kernel: /: bad dir ino 71554318 at = offset 8: mangled entry Jan 13 03:05:19 R64-RPi-4-3-2v1p2 kernel: /: bad dir ino 71554318 at = offset 512: mangled entry Jan 13 03:05:19 R64-RPi-4-3-2v1p2 kernel: /: bad dir ino 71554318 at = offset 8: mangled entry Jan 13 03:05:19 R64-RPi-4-3-2v1p2 kernel: /: bad dir ino 71554318 at = offset 512: mangled entry Jan 13 03:05:19 R64-RPi-4-3-2v1p2 kernel: /: bad dir ino 71554318 at = offset 8: mangled entry Jan 13 03:05:19 R64-RPi-4-3-2v1p2 kernel: /: bad dir ino 71554318 at = offset 512: mangled entry Jan 13 03:05:19 R64-RPi-4-3-2v1p2 kernel: /: bad dir ino 71554318 at = offset 8: mangled entry Jan 13 03:05:19 R64-RPi-4-3-2v1p2 kernel: /: bad dir ino 71554318 at = offset 512: mangled entry Jan 13 03:05:20 R64-RPi-4-3-2v1p2 kernel: /: bad dir ino 71554318 at = offset 8: mangled entry Jan 13 03:05:20 R64-RPi-4-3-2v1p2 kernel: /: bad dir ino 71554318 at = offset 512: mangled entry Jan 13 03:05:20 R64-RPi-4-3-2v1p2 kernel: /: bad dir ino 71554318 at = offset 8: mangled entry Jan 13 03:05:20 R64-RPi-4-3-2v1p2 kernel: /: bad dir ino 71554318 at = offset 512: mangled entry Jan 13 03:05:20 R64-RPi-4-3-2v1p2 kernel: /: bad dir ino 71554318 at = offset 8: mangled entry Jan 13 03:05:20 R64-RPi-4-3-2v1p2 kernel: /: bad dir ino 71554318 at = offset 512: mangled entry Jan 13 03:05:20 R64-RPi-4-3-2v1p2 kernel: /: bad dir ino 71554318 at = offset 8: mangled entry Jan 13 03:05:20 R64-RPi-4-3-2v1p2 kernel: /: bad dir ino 71554318 at = offset 512: mangled entry Jan 13 03:05:20 R64-RPi-4-3-2v1p2 kernel: /: bad dir ino 71554318 at = offset 8: mangled entry Jan 13 04:15:42 R64-RPi-4-3-2v1p2 kernel: /: inode 901792: check-hash = failed Jan 13 04:15:42 R64-RPi-4-3-2v1p2 syslogd: last message repeated 1 times Jan 13 04:15:42 R64-RPi-4-3-2v1p2 kernel: /: inode 901793: check-hash = failed Jan 13 04:15:42 R64-RPi-4-3-2v1p2 syslogd: last message repeated 1 times Jan 13 04:15:42 R64-RPi-4-3-2v1p2 kernel: /: inode 901809: check-hash = failed Jan 13 04:15:42 R64-RPi-4-3-2v1p2 syslogd: last message repeated 1 times Jan 13 04:15:42 R64-RPi-4-3-2v1p2 kernel: /: inode 901812: check-hash = failed Jan 13 04:15:42 R64-RPi-4-3-2v1p2 syslogd: last message repeated 1 times Jan 13 04:15:42 R64-RPi-4-3-2v1p2 kernel: /: inode 901794: check-hash = failed Jan 13 04:15:42 R64-RPi-4-3-2v1p2 syslogd: last message repeated 1 times . . . Jan 13 04:15:45 R64-RPi-4-3-2v1p2 syslogd: last message repeated 1 times Jan 13 04:15:45 R64-RPi-4-3-2v1p2 kernel: /: inode 85979159: check-hash = failed Jan 13 04:15:45 R64-RPi-4-3-2v1p2 syslogd: last message repeated 1 times Jan 13 04:16:04 R64-RPi-4-3-2v1p2 kernel: /: inode 91271591: check-hash = failed Jan 13 04:16:04 R64-RPi-4-3-2v1p2 syslogd: last message repeated 1 times Jan 13 04:16:04 R64-RPi-4-3-2v1p2 kernel: /: inode 91271627: check-hash = failed Jan 13 04:16:04 R64-RPi-4-3-2v1p2 syslogd: last message repeated 1 times # uptime 10:53AM up 2 days, 17:42, 2 users, load averages: 0.22, 0.23, 0.18 Unfortunately, this is my build, not an official snapshot test: # uname -apKU FreeBSD R64-RPi-4-3-2v1p2 15.0-CURRENT FreeBSD 15.0-CURRENT #100 = main-n266876-e183039f0882-dirty: Sat Dec 9 08:18:38 UTC 2023 = root@CA72-16Gp-ZFS:/usr/obj/BUILDs/main-CA53-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA53 arm64 aarch64 1500006 1500006 . . . So I've since rebooted the RPi5 with: # uname -apKU FreeBSD generic 15.0-CURRENT FreeBSD 15.0-CURRENT #0 = main-n267507-a61d2c7fbd3c: Thu Jan 11 06:26:30 UTC 2024 = root@releng3.nyi.freebsd.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC = arm64 aarch64 1500008 1500008 to see how it does. Technically the USB3 media has the Rock64 snapshot with the msdosfs material copied over from the rpi-arm64 snapshot. But the microsd card has the EDK2 that is used. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sat Jan 13 19:54:09 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TC8Hg0kKzz56Xkd for ; Sat, 13 Jan 2024 19:54:23 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic312-24.consmr.mail.gq1.yahoo.com (sonic312-24.consmr.mail.gq1.yahoo.com [98.137.69.205]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4TC8Hf5Kpzz4DPY for ; Sat, 13 Jan 2024 19:54:22 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1705175660; bh=XgSHwO2vm4pEr6oRH1tW9aOTlQKhyIYgo8R04/3+RBM=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=U24q6PLZeQPAezM9zi5UhctjTmBlXqXTDpDxBSzTGYKO4tAQtx7EliYCb+JKpXTpp8MKtQMg02zmZNfFcKcDbpE09HNp0ky0Jh59XYoRk6oVW/rZZP6id5jkLVGspgV6jLUomR5hcbfQ73B+tndBO5vsQ/dA3Ad14ym86Uh1+osbur6ogMaPqTOhRsF8hZCBXd2c5ZbIhBDirHgLBHp5JA6GjwZUAOeKzZYt1r4nxsVnDOkltL2ylwYBM62YhpkzKsonbVsEbgbHHLUiriPkAK0EtsSTwQjpUGmoKgewLqGsNp3MLKv8nsO9EFrUDlVEa2SmO+Vyv84by/RNeYOGpg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1705175660; bh=E++qs4l/z3MbZDtc+HMVEHiLmtyvpzzem9n2kDWGNmg=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=PePLDq6k5QcqFmzKp8sXGQz5VwKnhWIaXeDWzevjjnoRHKog4zPZ8hwM0Hz7p7ljnEeDlvBpxB+8rGQokRTsup0Nwbl6QyfIV07Fi9wIjuC409z8+O8LMnaeaufyKWcC9sFZvMB3xhGKSkHb7WlQGkpdYiIMP2nFKzUZWGLzSGLeP+hror6KPgVJWUT+M4H+RGDVNQ7yvm5M18XJj4UTOlIF4zHD+FCm8/DJUrNLNz7RyttuRbq+iTzm+wk9oZzNts5mk6Fk6/XmLZRzKU1zDz2W+xEEqu39k5EJo02yrc6n2qu3A6sMiub9PhPaB/ch5lI/WROiYtbgU/iM9n7JhQ== X-YMail-OSG: 0yCmFNYVM1nrRdda_6m6m6cMXiUegW4u1c9LWSXfuoCHbCeAsRBHksKK5LsAU_X sUqAdZh_R1erCRDu9dluFjiBVxq76eQfAUKSQ6tK6jRM5ykyTX0J6eaUJ6r0fhnUnlmkL0aIqEyX WD06u99vFFck85BQtk84TqZvL50CtXr_ko6XtTkxy4xsGliOjgL4OyuCLxyLJRtYz3xeLHQrW9.A V_WqcgjVbo3u86FayBKlXspoPVQmwgyg11wuDaJcWKuUmVNTqooyfyGd4Y8anXpBmpL9gkg.Y7OH 5rPFOs5dfSAY1HqzSxTuRyQhsaXFzJXGjpytCP9u3wuA5gr.TPslBkidZHl1Pe56FWi5dM1038KH _Sbwe.WoqUwjQwCB5n52E8nybHI_4kz7s9ofXxqYAOsaeot3ApXs0hXusS7fDi5p.PpsXBGYdEur 7yuiY4IBa6mx3vMbqwpLpecWK7cymQtdY90Km8H4V86K.NZ.MggoAs6H6vjUIesAAn0ixv7Zn8qC c2.EacxO4opcIkBvpbn73bXdOHUnotN3UkQ7FJqlJr9vXETphPvVj8CwfzFLt00L66mNMkuEMJ4P kI_PKHfp6kFNRYfurGlUX8ONHr5gfxX8RKbOCXyHTN6PdUWVBVkaeaVO346UiLZ3DSs.NO5570M_ CoMgEgOiAJ3iliuv6MCxaCdAVC9H2ArcfH5yYR3S2bl.8wBEeR9ZkoJZpOkoQ0iyWz12T6iB5rlz 0uAndthognwkfe5edOavuskbK4T56NeB.PXeKBV3_mkwHe7VmfPKcEBFmyVOnccT5TToQiLaUfST RwcpQbXi0xylgcCkYKOyt.DzM1.sQjBwsoK3hvjLkr57ahk751FOIAIgNA3dSxN_0_zCfEdkDU.7 QnMJmXC7sDxtbSPM2.mESqdwUaoRNXFVrxEdFE.MtHw2dxzXeMNib9X8zjMx3SkXlIPsOTn74Bw2 mjV8XXS2MhlHc1dw.6yL.6qQZgxehngzufTzga7iKYeiDid_P32zSJP93UoQoqR2eFQgUki69hSi ZNRROd5y0u_xNFnkH4Wx5ZvWIXOYvRWVR.W1d8D2NQ_0yPhHwzrP5shKYEfLZl.SGrU2X1UymIeH KbpoXQCHYKes3jpE..E.RJRQJfc9bkY.HpwsOa6BnnUINkg27R1GYFdMXnct_Ml2_uggtrbrAejL MLmloTtg1YKR497yS3d4xNo1ffmUlGmNSkQa1h1CovSCqd7oevZjo48g7MnrWJyN6x9ck_VDjncA XB5xoNwfCXyln56ZyoR9Ev.ufl86yyQAaKEDlIZyisQDDWFq5FEzAlVhQdapBKli_jnFKAYrjYpj czB2GKd5ag7WxQMwltLf96OCY3Tz1UmvEs9OjS._qdaQmNy84sKWdKUsECdbnzeXfbr1ruZhEZHb gSNo7QogafsLZef7zrtHfjo1jytt.qkNu3.p0JRN.jnpIvnHwCkLze38aoemZRZ1Ex2YFrwtd9nt 4TzgFshAtseG5XpPmXv8vHt5.hWeDOJwi2Ug_M5Bl7bfbohHc_AQnRiP4SRqV.CZ_u3Lhf0MceBS .Ftj7.xspyg5tvsk7CRC8iyK3jaKpu3.K30M9zooNwzeVPxlHsKs6IVZAmBO1g6mxXchhX0hGDA1 IIS5FssFB70ybouJC2b3YTeiVlrX91oUv5Wf8Khz42wLpcB_9q7Pee5zyPtpwWRb.U0h5Le7f35I CN_QmzqJv8KNpLKC5nTx_aOK0xJL5a1tFQBK0_zc74PEd3_5_BEZIYeB7tO5p4zeDV.NPAbJ2Wsl TL6GmtvikeUomHRgJg4tLBRisHkDeZHBZ8reETRSwlJy.uuqE7AdYdA0prFjoUFL1E7zglclEra5 XSNRBS3CdoSQ8wXJXpW1WzxlXslSW3Dd61FKvYkAsSSpQVOvrYjcXWhmiRp6BylYzXh_.BcA6kYU e91KUjtPILWiePpCnOohIOezRao6wI0ssUZGiS.o3okwbfyiojA4agrGBWpRQ5nqssCtra2HkpZK Ej65JjeG8rhcKKZzeHRVtxaZQIWo0qkeFp41u6INpxlPDyHbj1akMK9zrRNslvqQ4i2wcqx56E2d Qv4TVuhIRkriRl7P3dQFZAcqR0n2YQogQHHA4BMZoMXY7KJZmMAQmDnZAVncC3FNGEaAjD4M7NqI yiOEwzvRiV.IDySSInyoZcxEUqEyKfH.VhVuYxFkA1cbs3wLUaZ1qY5KGX.xur9z7H6kZB.hsL4q JdUk.a8_xub45KFC04jgGBr6ZTKoiWcrVBjYJoHPzh30rQXcM8PrqkEUisoAW6k_4Vzl_Ro.rFQ- - X-Sonic-MF: X-Sonic-ID: b88414b0-dbe4-4e5c-9f81-e90688863f18 Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Sat, 13 Jan 2024 19:54:20 +0000 Received: by hermes--production-gq1-78d49cd6df-xzd4p (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 43a2e2a0f015ec60fc043c218b01b6be; Sat, 13 Jan 2024 19:54:19 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.300.61.1.2\)) Subject: Re: When will FreeBSD support RPI5? From: Mark Millard In-Reply-To: <9e45c7d7-450c-48e5-8101-c6ea5cb3a023@FreeBSD.org> Date: Sat, 13 Jan 2024 11:54:09 -0800 Cc: Doug Rabson , John Kennedy , ykla , FreeBSD ARM List Content-Transfer-Encoding: quoted-printable Message-Id: References: <5a39810c-5fd8-4969-a222-2561b050b035@FreeBSD.org> <347FE009-A470-4765-A9B9-7C9AB5E954DA@yahoo.com> <76FA010A-338F-4E32-B381-37C7BA63CAFC@yahoo.com> <9e45c7d7-450c-48e5-8101-c6ea5cb3a023@FreeBSD.org> To: Jesper Schmitz Mouridsen X-Mailer: Apple Mail (2.3774.300.61.1.2) X-Rspamd-Queue-Id: 4TC8Hf5Kpzz4DPY X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] On Jan 13, 2024, at 11:22, Jesper Schmitz Mouridsen = wrote: >=20 > On 13.01.2024 19.32, Mark Millard wrote: >> On Jan 13, 2024, at 07:38, Doug Rabson wrote: >>=20 >>> Getting back to the RPI 5, with a tweak to = arm/broadcom/bcm2835bcm2835_vcbus.c to treat the memory config the same = as RPI 4 and to dev/sdhci/sdhci_fdt.c to treat the RPI 5 sdhci = controllers as generic, I can boot to multiuser mode using the EDK2 = firmware from https://github.com/worproject/rpi5-uefi with ACPI/Device = Tree mode set to Both. >> What does FreeBSD do with "Both"? Does it actually use some ACPI >> and some Device Tree? Or does it just use ACPI? Does your >> combination do anything different than just using ACPI? >=20 > How does the sd card show up? Context below is via use of a aarch64 snapshot image dd'd to USB3 media and use of a microsd card to hold the EDK2: # uname -apKU FreeBSD generic 15.0-CURRENT FreeBSD 15.0-CURRENT #0 = main-n267507-a61d2c7fbd3c: Thu Jan 11 06:26:30 UTC 2024 = root@releng3.nyi.freebsd.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC = arm64 aarch64 1500008 1500008 # gpart show =3D> 40 249737136 mmcsd0 GPT (119G) 40 2008 - free - (1.0M) 2048 249733120 1 efi (119G) 249735168 2008 - free - (1.0M) # mount -onoatime -tmsdosfs /dev/mmcsd0p1 /mnt # ls -Tlod /mnt/* -rwxr-xr-x 1 root wheel uarch 2031616 Jan 5 18:20:18 2024 = /mnt/RPI_EFI.fd -rwxr-xr-x 1 root wheel uarch 76038 Jan 5 18:21:50 2024 = /mnt/bcm2712-rpi-5-b.dtb -rwxr-xr-x 1 root wheel uarch 388 Jan 5 18:18:24 2024 = /mnt/config.txt # dmesg -a | grep -E "(sdhci|mmc)" sdhci_acpi0: iomem = 0x1000fff000-0x1000fff25f irq 3 on acpi0 mmc0: on sdhci_acpi0 sdhci_acpi1: iomem = 0x1001100000-0x100110025f irq 4 on acpi0 mmc1: on sdhci_acpi1 mmcsd0: 128GB at mmc0 = 50.0MHz/4bit/65535-block mmc1: No compatible cards found on bus # more /mnt/config.txt=20 armstub=3DRPI_EFI.fd device_tree_address=3D0x1f0000 device_tree_end=3D0x210000 # Leave RP1 PCIe configured on hand-off. pciex4_reset=3D0 # Force 32 bpp framebuffer allocation. framebuffer_depth=3D32 # Disable compensation for displays with overscan. disable_overscan=3D1 # Force maximum USB power regardless of the power supply. usb_max_current_enable=3D1 # Force maximum CPU speed. force_turbo=3D1 > BTW i did put some stuff here [1] > I could not get bcm_dma to work anyone planning on getting that to = work? it should be similar to 2711 documented in [2] >=20 >>> This does not have working PCIe or ethernet yet - I think ethernet = ought to work since we seem to have a matching driver in the tree in = dev/cadence. >> Sounds like the same status as booting just ACPI with no such >> adjustments too bcm2835bcm2835_vcbus.c or sdhci_fdt.c ? >>=20 >> I think Mike Karels plans on investigating getting Ethernet >> going based on cgem . I've no clue if this is ACPI, DeviceTree, >> or both. >>=20 >> My usage has been pure ACPI, no software adjustments specific >> to getting the RPi5 operational. Use of a USB3 Ethernet dongle. >>=20 >> =3D=3D=3D >> Mark Millard >> marklmi at yahoo.com >>=20 >>=20 > [1] https://github.com/jsm222/rpi5-stuff >=20 > [2] https://datasheets.raspberrypi.com/bcm2711/bcm2711-peripherals.pdf =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sat Jan 13 20:01:06 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TC8Rj14Wcz56XwF for ; Sat, 13 Jan 2024 20:01:21 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic304-25.consmr.mail.gq1.yahoo.com (sonic304-25.consmr.mail.gq1.yahoo.com [98.137.68.206]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4TC8Rh5kzdz4FPs for ; Sat, 13 Jan 2024 20:01:20 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1705176078; bh=Ht31rDY55Jl50AeWSOSBSu5gSwp8mVkEK5jdUXcTrFE=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=qP+Z43HFN/o3BypMPLb+hdPrvh+IfBCbjcvzPg4AdEZlHmPUU1JXF07ha+nQCjgFpOse00Ojw/9+6GiVUPjnADxk/hku9Fo6L/MyUZoHvHI30u5bAchtyk8d+jaOtykgPaa2q4wW1VgmCSFDr5Tbkt4wSZv9SjcBKhvTifH8XEZNzuLHSbYmQ0T0bYVymutAz1Dp8vmOFho3j4lSI2Pz5Rds7XlryYnY78pI4yF4pnj7U86qAxIyNeWjzooC+kEpaa64vQD8nqTf18FJNOpQluX32Sc5l3FOy0lOomMkw1J+oWxZrFY/g7ITjA3RMoPXj4YKMOP+Np6xrcn07fwyjA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1705176078; bh=Ooxj0lLJO+9O1IAp6Hd7dAi3IGT/pmNT95+IebgYSNS=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=iVUfOZDzybqv2bKOqapBbnyelfuDHSdWbhszV1/8Bfr5Y4SgTeaPZ97CXLEgLKzRmQZHqdguax/Ar2PzfOOQJrYHnsvpsufx7FY3bom5oZc7r1/MPioHCt56ZgZwnKArJufaD/hUTFmwoCipcC7yKaRsLsXxctzn9cxsI/Kk2AeZ1JuVXuy4SNlvj9yQzDS7bpvATs7COm5uXQmqhGfzf3wmGdwJfiI/Fk1BTFz4mLgMOj/Mb3XaJUoEZXXIpAhuzjwzphtr4WCXBUAydZMPWv+fuzODs66JWDAozv4ku8BR3qulqlbXePw4ek/gdN/4PyrYy+s+NaaTxYU+Uny39Q== X-YMail-OSG: CMaUQfUVM1kuBsyUFuMNshomNtQ3wEtbI8RAPY4_hlDm7fsLe6T3.42bx_zC0cx 3T_9G28SQ8k_5W9_oTEWT7_csA6TeI926qO4XVjRH88w_Gy6dVP8M4EbOK5s4kmfP6RY3LTv1jP. SfnIZ9l5cbNIGdLnLUGXWKrikfTMsppa7v4Fwr0css.ibGuQVPCVri5HQ7c5TVG9j0n4TSl3DrsW jd3P6n_dm65V2MMqAeoXto24CAUu9A36UlEz6aDpwNLHW3ha1H9qZ2DfHZ.X0TIleHMi.01sjYp3 FeuNttF0B_pJ.uOokxC1bVWz_Ep6nhOxna1ME_vBd2hDZCWDjy8yWS3MMgWrJg1EgGs0XGCAwyR3 VDh2OWehDCJvtNjGq1KRp9ciagPPht.fN25cMHm2o4SbV4arafQOKO2f_hP7bbyUFSrZx7eQ8h5H V9XLB1eOvbnSQcSEi35_VKckMV8FfTHQ46FVVt_LplNTDt37HkJ26DvYavqzE2TUt4i3zLJcNqMj Jswok6fIHmAubrSdxs_TfU3tobfKga60vt0hS0leJli6Ep8UHIkrsgnpZs0DqqraihVhLPVlrekr cV2DLm4SU27eya47Rkk4.1nmJj34f.89_hdYsTGOnV0QOO2P42mN3YzqYEmw0O0SPxrzx9Gg1H_5 rNQCXNmWzFU8pZGu2urW1UoDRQDBGjesYjgrUpjUXa4rP_kmwSFsaAGJ6zPjUlu9353ODMzlGRHh HBHrYpWSc2A1w3QK7QpJxB68cpldQUNk1OSbWun0HWClDnccWCMII7zly3mfkFNvMFzGQ_E9B2qy NIa86sXfegd2cklqWszJKQjlvMGG7cAUmV8VT_aQHBRez.EwsjIYoKVBaMny0aaudDyTYZXveRSd y.LIdTPgESidDgiBpaKM_Hg5toQL1k3AvyzwE8eKA_eZaddExUdlhphEzO8MmnHuCQMNLYYBHMv9 HUJgxxcaPAPNDG5tjvKYT8J4TtTF0v9CPEcylhznJEIhCKy.jXXDpLHy9_cWkAufE8Xvyiv7IaZl lpCeSwy7dKN_wVKNjF4tCFOOsVLf_zZlQhwgwSU7Fp9a0uPuw0b3jZM0B5Ke23OVfQLbHhFlN6zv 8IRt.Pa7HGPeahFxLZzKq5PGMaWCdkDtYKVIg4PjILM4kQR.GH0rFTNBpPXUEYcFMy2BEWomrDC9 TxDUVRDBa4c9.rZ8S4y5VyIgtxkMkAuzYPjNN2m7hqul7pdNkRmWQmrk9LIXetV_5Nw_0mbjhGk4 LwHdfNEW1FO8CxXg.7qLu_dGXWfzA6QELYlFx6m91kWZmijxBK8NuGBaVuTMmehcTczrzJLNS1cT rxpIbthRe4NQdVRRVjIay5ExjZnEWhIUg6zXXgMsyGnqV90fKAxIcuLrAejGDBQeHELTlwNxdBIL LA.QYvDyMocbRYj.wm3mEK2XI44xXmX8kgDEUlFYoMSW0xw0.iSXhtMMY5EpWR6vyk9_jUVih938 9AFcujmt7zFyQq_al_VV0O821JLtW_WdOUY7T5ybvsNIhxwLfJAQ2hrQlI0vHbfeTBwybZZqQ2hY RwCq2PeydVi2dQyM70ZSfG9LS0vqjbn9_ZQ5WeXNtydI95Lit9CTs8kU1aTvVmAK1E_qfLC3s0GR PA60Yd8GyxUTmUlR1nzWjjWJGZ2hbkhgguWvq5ZJrwArkdar0P65KV67ji7KWiGPhDucSTktnuEg Gkoja5y3qdLXZrwOsfusD0DcN9FwSn7.B67FpfsH6X.w0qdT11S3s5rCe_47SDNsFF9mw1LaShof O6_ZCHodVgp7yu3jPS1xdYvI8akTz7RiG4vTLnmONUtg4ebRzpDYA1C4bRJnoYm92FeVGorASC4O 8W_aLEdNGIbdsrNT5xu5QX52L43Mo8LguwRz_xAvgev0.EDI.XMOMGvOYsJ1CnsPPkXguirOEX8. BqDcfn2nqwhya34YBymqGDwwkdVv4ZSbgxFQwQ.TQcljEkwTqnyP3NedBWY9csdEZM6hacNXJV89 ulMUGAg.oPgs98fhag7gZvLJu5ty0KBG4UtgGL14bdHeiCtzKkkzro._GqlIOf4wYI2Qoh5z5HVm 242CV99xd7G4tqAn00Rulnpol1UyiwozgY9Oj_8toDrAbzEmomVLoEDidBgPx4MWFdCzOMtmHo01 Js4uhSwQBBQf3xx.XCk8Z8xmTLc8hth2ubUcYo3O_pvxmdjqo8zAMPi2X69fpfZPPQfZKp1.xzF7 co2O3jRkzRs_5zGb98RgbregD1ZIbISo1LZ_hpuk5E47XNaJd70CTtkVoK5EpV9hhNfUdpZeCnta i0VA- X-Sonic-MF: X-Sonic-ID: e2155ea4-d769-4281-b500-d8deb8bd7597 Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Sat, 13 Jan 2024 20:01:18 +0000 Received: by hermes--production-gq1-78d49cd6df-mnx8f (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID f792519c76e4dfc16d5542e2489b9a4b; Sat, 13 Jan 2024 20:01:17 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.300.61.1.2\)) Subject: Re: current for arm64 tries tftp first for some reason From: Mark Millard In-Reply-To: Date: Sat, 13 Jan 2024 12:01:06 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: 7bit Message-Id: References: <0DB5FDFB-184F-4260-A060-ED6A6CAFE546@yahoo.com> To: void X-Mailer: Apple Mail (2.3774.300.61.1.2) X-Rspamd-Queue-Id: 4TC8Rh5kzdz4FPs X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] On Jan 13, 2024, at 09:31, void wrote: > On Wed, Jan 10, 2024 at 03:16:49PM -0800, Mark Millard wrote: >> U-Boot is doing tftp activity before the FreeBSD UEFI >> loader has been found to be loaded. So either the >> sysutils/u-boot* port's choices for how/what to build >> or U-Boot itself if building can not control the issue. > > The issue is no longer present in the latest snapshot > main-n267507-a61d2c7fbd3c thanks I still have the problem in that context with the RPi4B. But since I've moved that media to the RPi5 for an experiment with EDK2 based booting of the RPi5. === Mark Millard marklmi at yahoo.com From nobody Sat Jan 13 21:36:33 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TCBYX2Pkrz56jRZ for ; Sat, 13 Jan 2024 21:36:32 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (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 "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TCBYW5HyXz4RTS for ; Sat, 13 Jan 2024 21:36:31 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Authentication-Results: mx1.freebsd.org; none Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.17.1/8.15.2) with ESMTPS id 40DLaXME021835 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 13 Jan 2024 13:36:34 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.17.1/8.15.2/Submit) id 40DLaXSI021834; Sat, 13 Jan 2024 13:36:33 -0800 (PST) (envelope-from fbsd) Date: Sat, 13 Jan 2024 13:36:33 -0800 From: bob prohaska To: Mark Millard Cc: FreeBSD ARM List Subject: Re: USB-serial adapter suggestions needed Message-ID: References: <482FA770-89E8-42E8-945E-B662AD564AFE@yahoo.com> <9F0BEC32-93CB-4DEB-98C4-D0FF2284B9DE@yahoo.com> <85102B46-CC5E-4FDA-8736-F562512FADEC@yahoo.com> List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <85102B46-CC5E-4FDA-8736-F562512FADEC@yahoo.com> X-Rspamd-Queue-Id: 4TCBYW5HyXz4RTS X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US] On Fri, Jan 12, 2024 at 09:49:47PM -0800, Mark Millard wrote: > On Jan 12, 2024, at 17:52, bob prohaska wrote: > > > > While checking, I logged in as root on the serial consoles of each host. > > When I tried to log in to www.zefox.net the response was > > This and http://www.zefox.net/~fbsd/tiptrouble/corrupt_mac do not > make clear the full chain of connections. In fact the presentation > seems inconsistent with other information so various things may > have changed. > > Some context based on prior (out of date?) information: > > |-50.1.20.30 ns1.zefox.net Pi2 12.3 armv7 ftdi usb-serial----50.1.20.27 > |-50.1.20.29 ns2.zefox.net Pi2 12.3 armv7 2303 usb-serial----50.1.20.30 > |-50.1.20.27 www.zefox.net Pi2 12.3 armv7 2303 usb-serial----50.1.20.26 > > Was "pi4 RasPiOS workstation" involved as a starting place? If so, what > sequence gets to www.zefox.net from there? Yes, the login sequence starts from a shell on pi4 RapiOS workstation, via ssh to the terminal server where tip is run to access the usb-serial adapter plugged into it. > > Starting with what you showed via: > > http://www.zefox.net/~fbsd/tiptrouble/corrupt_mac > > (not knowing how you got there) . . . > > QUOTE > FreeBSD/arm (www.zefox.net) (ttyu0) > > login: root > Password: > Corrupted MAC on input. > ssh_dispatch_run_fatal: Connection to 50.1.20.29 port 22: message authentication code incorrect > END QUOTE > > 50.1.20.29 is supposedly ns2.zefox.net instead of www.zefox.net > or ns1.zefox.net according to http://www.zefox.net/~fbsd/netmap . The netmap was wrong. ns1 and ns2 were swapped....8-( > > The bugzilla material eventually needs to be updated with something > that can be followed and noting the possible occasional hardware or > software corruptions of material that end up going over Ethernet > that are now demonstrated to be able to cause the symptoms that > you have been seeing on occasion for so long. The netmap is corrected, with a description of the login sequence used to watch the serial consoles added. I _think_ it's a bit clearer than before, if not please say so. A readable (and correct) description of this setup is quite difficult to write. Thanks very much for close reading and taking the trouble to point out my error(s)! bob prohaska From nobody Sun Jan 14 01:06:33 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TCHDD2J19z56c2b for ; Sun, 14 Jan 2024 01:06:52 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic307-8.consmr.mail.gq1.yahoo.com (sonic307-8.consmr.mail.gq1.yahoo.com [98.137.64.32]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4TCHDC41G0z4q1K for ; Sun, 14 Jan 2024 01:06:51 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1705194409; bh=izEqE1m1VMfoZRPo91vpRFZflNEX5wuaigi2GcKMv/s=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=ITjsrph87T0vesay78jY0jaqSyqZyN/LXNFtO8YrCgrRha3+NPBlIojPR1X7+M6feFONcbu+i9CU4eptWOC+en5D0QOZAN+W9ZCcrQu+ipRW8YqX3NmfKinwxyyt62tXkfVb0LjNwucy9UPk/mm78cwwtnDGTD7Gl5ZiAe26rDp/GE9snYVyvi21TIjWzjm6ifn6fWyq8FNpBufMqgyiPV2QU8kDFP6Xc+CmX2t41+15b3T+Dt200AZ0hHabMKbHprmDe7Z0tms9kS251YPySITPNBTB3Nnjnk2+PMEXrPo6n249P3lomr0k2zCxGfJyzJXwsMjJsuyQJu+4ivfCBw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1705194409; bh=4ds/v7G+jMCKCE2WnBAbMNFSQDHITlwrPhMNPg74Nt6=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=MMr9CE2miZfuVzXiiy6ujuGqWhR3jSpnlIGH0J56D68tIAznjIashFrvDn1X6JxkkhjvBG4O9flbCqd4IxsJubpjjrTPoyrK/v7OHQh25bSOmXR+cHZcNAeWgBZGjwGdK0i5JZmaQGpdsb8FPKMtx6fetd1LBhK90ic6weCUafLL+vAQ9aJw+tQJ6wrgK0OqNO37ey4EE6RhDCXosJ1oBw7S9upQx9lJMf4BfdazwpWpg1W1nKgAFY5oHQgV6wiSOzKyH/9vCuweaT2lybcZj5WupPZ+n69x6Weo/jLbBwJisKeEUZAVdA7CyF4YrYqL+Ed0Qlvxk2dqoN67DzfCCQ== X-YMail-OSG: 7_rX1uwVM1li4PbOqMa9bG8Mhc32tOW4oxRb7JIjd0J3sYrqbH378xNW3ESyoJV jZ39X5taljXOAYAXZ8O75pR4e.Vn1bHPzR1zT3xloGDGrNnvqFIvIyqfgptNLzGXEp_w6jSkplGr jUCgEtUET9ilzJIyEWbxnVt8TNVUqTj2oKpQ_WzhoOLTIfWeU_IPAPVFD4kg5txve8WxkWXmjYAn cYGXdWb5YUx5x02gEykZlYBT4zGfciGwpEXW9G9BBkLfloKSx2rh6zgrZWtHK7AvjKGsAlwJlT_B 9.uIBlREvafmAlMbsI3PMecRoTyuFqj9qCShHhRHBV.1A4ms2heO.EX6awEkKG.dvQSzKqPDtDZS 1nHwJcbcY7ABjvvb72tkNCpYsZYCNl9R5xoN0hW0i4Lkp1SE4O6E_Ns6C4CtLQoipBu9n_RODrS5 XsccIPWM_SByopCQpKCZ6Mfxa_RWut3FkutuJovmbSpPdwC14cqKybCuZe4r9utXR_OwmEwFNbZJ .sV4W.hhGMxwsio6ekO91KcYgvK5NGjC7whWOkrGAalGE3F4PuProzXqO8C3fz3tGTwRujZRBc_W Nbo4XypILJTrxVkfdDWdkovQGfkIAb.p4zoXpmohroFDhzFL1iSrb4I.OrQT_pEYa5L8F5_GC0Yk NBWRMelRR4whSO15xn2s1gIZXSc6uVtXw.cPYEQElyk0mGnKOMzLe.he1gpl3bZ.RezQpi9E_uCs 44BrW2eiTxDe_6hDtDDeTBt2qV0PyBHxqGBAjvTdJbEOg1pBn7jCc3zqrWQTGxDkLgkdKt2Xe2Xr kR88cO86TAWSOy5lztVyjAdEYWnhxMxskR.5UDf1HVqmY.JLo7L6n06h7ZL.7uLFvxkI0VzRxcn7 dGCZk4rOzOIGRvYhdvXxMoVscltpyubI0PgCLaMLAut5DgOYmn4NFPtXPIqOp_jrrGpvCs7Ddf0z wiUOzlT4eW0A7PqzqxI48lLs_jnhrhDYiYhtNepG.wlE8MiGgjGABnNqGotTQ3VkTsw0iI2tTOsk aOzlO1FyVnx7teLvd4cgWXO4AqBH5YOhoq2lwGMw7I3FyJoaN8962oQ8ecYoSTwedzT53h8mVFrW V9P9KfPjfDT_qPOdOdaozBDH8Y8lHYuGYKjsOXJhID6MMUmQxmb9fENLTBYNGBaix9GKZogztR3d 8XUGAmwhOXrisMA3Up4n8eNl4dpWhI8XE8iQFFmKyYSyeo053zCXYQWEi7hAunlnTeCl80GUR53a 9BHEDgfQsxvUy18NAXA1Hgfqnp25h1oZVx..SqZGX8McCTDTA9hVyi7oHY1rkVv8v__6KSz4alXa 5MxH7dvnu8ZF92x5xunmSSUhKGcWLPQduiXK1BlkLppih6bTELpNZkNsAgRmOU6VHiR586xzKeIy xaRgRrLIclbC29y8wTm4uc3UgPsLtMxCiW4mrX8emr.hItNG1HCE2mEH94DO4hSjuIpJgKYAE8Vc pUBsCVeeuIyfofAOZZzMIKY.y2p2zOigTm7DomN7sQxAhKL21TDVbzB9e2NDAMj5z7QW9zDEHkEd .whMud3re6ebpHr.cq30SzwKng7HLUwVqS4_BeNvrYrqs79knr__tXlwve01KawQ_Asr9ld0HtSI i6iBaoKv.pe.6Py.v9ydBefqhbHTpeQWUcu4Xr1wOAAmdrqcArCJsI1ou7tlCczwngDSuDKJ0I4S SlA6Xlfoxa7Em3SucOcpV8rL7EI2nRN60pbcze1QKQnzDNJ5flkr..IZD0og62YFP5pC_7Mrwf0d uwURSaC_EUK70OhXmTz7DX1A4CTFA7FhqpxgTFKtTjUBjH0evwD22O26RbvaHiPbfGPTda_JSC0x .MdhqF1womzH9imlC.ecPHRQt7YGZJYmlbqVdUR.5Pdrhn5hnmPWjCgBa.EYU8eZ.68DL3VxQPD3 RXKc0zsG7ghi2QdqTMqGINvrmoxUUarHK60Eo8t0ZgK_vI_jPepllt1VJzjQDuuIi0L7uHwuxeei mrrag6xsCOaYuDuV1YMZ.sKbfo950n8YBtoyaGUiRKc55u1oVp1VUwKzIq.8q5jpPmMKZ_.tYMDl zCdEAS.NYXsYaYLENLGT_qWDpPMaQRwKHCP5dcXdGPzGDVqj4bWVLEyxK7nc6Hsy9ht4ejB8S3wI xtS5s3cffgljFq8vLjLUdckw94e3PEq3pel6iSpNzgvsOi.Aveffciz4AVuQWXO.OMdina6CEAm8 zvyKdPkd1oiyrf7_METzgOyjwbYO.TcWZKzw_sgOS.4G1fpA_C4_N4v8bCkG.AtXk8FYiLDz8cV0 GKGsB7A-- X-Sonic-MF: X-Sonic-ID: 66f32791-3d28-4b08-b7bf-01b09e3440aa Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.gq1.yahoo.com with HTTP; Sun, 14 Jan 2024 01:06:49 +0000 Received: by hermes--production-gq1-78d49cd6df-ml6vl (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 587f1d2609b116db1551a44a1e1eb9fc; Sun, 14 Jan 2024 01:06:44 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.300.61.1.2\)) Subject: Re: USB-serial adapter suggestions needed From: Mark Millard In-Reply-To: Date: Sat, 13 Jan 2024 17:06:33 -0800 Cc: FreeBSD ARM List Content-Transfer-Encoding: quoted-printable Message-Id: <847F0A8B-AE85-409E-AE65-3608930A4A90@yahoo.com> References: <482FA770-89E8-42E8-945E-B662AD564AFE@yahoo.com> <9F0BEC32-93CB-4DEB-98C4-D0FF2284B9DE@yahoo.com> <85102B46-CC5E-4FDA-8736-F562512FADEC@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3774.300.61.1.2) X-Rspamd-Queue-Id: 4TCHDC41G0z4q1K X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] On Jan 13, 2024, at 13:36, bob prohaska wrote: > On Fri, Jan 12, 2024 at 09:49:47PM -0800, Mark Millard wrote: >> On Jan 12, 2024, at 17:52, bob prohaska wrote: >>>=20 >>> While checking, I logged in as root on the serial consoles of each = host. >>> When I tried to log in to www.zefox.net the response was >>=20 >> This and http://www.zefox.net/~fbsd/tiptrouble/corrupt_mac do not >> make clear the full chain of connections. In fact the presentation >> seems inconsistent with other information so various things may >> have changed. >>=20 >> Some context based on prior (out of date?) information: >>=20 >> |-50.1.20.30 ns1.zefox.net Pi2 12.3 armv7 ftdi = usb-serial----50.1.20.27 >> |-50.1.20.29 ns2.zefox.net Pi2 12.3 armv7 2303 = usb-serial----50.1.20.30 >> |-50.1.20.27 www.zefox.net Pi2 12.3 armv7 2303 = usb-serial----50.1.20.26 >>=20 >> Was "pi4 RasPiOS workstation" involved as a starting place? If so, = what >> sequence gets to www.zefox.net from there? >=20 > Yes, the login sequence starts from a shell on pi4 RapiOS=20 > workstation, via ssh to the terminal server where tip is run=20 > to access the usb-serial adapter plugged into it. Okay. There was 1 reference to a login from "gateway.zefox.net" as a "Last login", as reported by a ns1.zefox.net login sequence. >> Starting with what you showed via: >>=20 >> http://www.zefox.net/~fbsd/tiptrouble/corrupt_mac >>=20 >> (not knowing how you got there) . . . >>=20 >> QUOTE >> FreeBSD/arm (www.zefox.net) (ttyu0) >>=20 >> login: root >> Password: >> Corrupted MAC on input. >> ssh_dispatch_run_fatal: Connection to 50.1.20.29 port 22: message = authentication code incorrect >> END QUOTE >>=20 >> 50.1.20.29 is supposedly ns2.zefox.net instead of www.zefox.net >> or ns1.zefox.net according to http://www.zefox.net/~fbsd/netmap . >=20 > The netmap was wrong. ns1 and ns2 were swapped....8-( =20 It now shows: |-50.1.20.29 ns1.zefox.net Pi2 12.3 armv7 ftdi usb-serial----50.1.20.27 |-50.1.20.30 ns2.zefox.net Pi2 12.3 armv7 2303 usb-serial----50.1.20.29 |-50.1.20.27 www.zefox.net Pi2 12.3 armv7 2303 usb-serial----50.1.20.26 But it later lists the older/inaccurate numbering as well: 50.1.20.30 ns1.zefox.net Pi2 v1.1 . . . 50.1.20.29 ns2.zefox.net Pi2 v1.1 . . . 50.1.20.27 www.zefox.net Pi2 v1.1 >> The bugzilla material eventually needs to be updated with something >> that can be followed and noting the possible occasional hardware or >> software corruptions of material that end up going over Ethernet >> that are now demonstrated to be able to cause the symptoms that >> you have been seeing on occasion for so long. >=20 > The netmap is corrected, with a description of the login sequence > used to watch the serial consoles added. I _think_ it's > a bit clearer than before, if not please say so. Definitely improved description of the context, thanks. > A readable (and correct) description of this setup is quite=20 > difficult to write. Thanks very much for close reading and=20 > taking the trouble to point out my error(s)! =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sun Jan 14 02:16:35 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TCJmd0fC4z56lb1 for ; Sun, 14 Jan 2024 02:16:33 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (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 "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TCJmc5xx3z3xTV for ; Sun, 14 Jan 2024 02:16:32 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Authentication-Results: mx1.freebsd.org; none Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.17.1/8.15.2) with ESMTPS id 40E2GZRv023281 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 13 Jan 2024 18:16:35 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.17.1/8.15.2/Submit) id 40E2GZ47023280; Sat, 13 Jan 2024 18:16:35 -0800 (PST) (envelope-from fbsd) Date: Sat, 13 Jan 2024 18:16:35 -0800 From: bob prohaska To: Mark Millard Cc: FreeBSD ARM List Subject: Re: USB-serial adapter suggestions needed Message-ID: References: <482FA770-89E8-42E8-945E-B662AD564AFE@yahoo.com> <9F0BEC32-93CB-4DEB-98C4-D0FF2284B9DE@yahoo.com> <85102B46-CC5E-4FDA-8736-F562512FADEC@yahoo.com> <847F0A8B-AE85-409E-AE65-3608930A4A90@yahoo.com> List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <847F0A8B-AE85-409E-AE65-3608930A4A90@yahoo.com> X-Rspamd-Queue-Id: 4TCJmc5xx3z3xTV X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US] On Sat, Jan 13, 2024 at 05:06:33PM -0800, Mark Millard wrote: > On Jan 13, 2024, at 13:36, bob prohaska wrote: > > > On Fri, Jan 12, 2024 at 09:49:47PM -0800, Mark Millard wrote: > >> On Jan 12, 2024, at 17:52, bob prohaska wrote: > >>> > >>> While checking, I logged in as root on the serial consoles of each host. > >>> When I tried to log in to www.zefox.net the response was > >> > >> This and http://www.zefox.net/~fbsd/tiptrouble/corrupt_mac do not > >> make clear the full chain of connections. In fact the presentation > >> seems inconsistent with other information so various things may > >> have changed. > >> > >> Some context based on prior (out of date?) information: > >> > >> |-50.1.20.30 ns1.zefox.net Pi2 12.3 armv7 ftdi usb-serial----50.1.20.27 > >> |-50.1.20.29 ns2.zefox.net Pi2 12.3 armv7 2303 usb-serial----50.1.20.30 > >> |-50.1.20.27 www.zefox.net Pi2 12.3 armv7 2303 usb-serial----50.1.20.26 > >> > >> Was "pi4 RasPiOS workstation" involved as a starting place? If so, what > >> sequence gets to www.zefox.net from there? > > > > Yes, the login sequence starts from a shell on pi4 RapiOS > > workstation, via ssh to the terminal server where tip is run > > to access the usb-serial adapter plugged into it. > > Okay. There was 1 reference to a login from "gateway.zefox.net" > as a "Last login", as reported by a ns1.zefox.net login sequence. > > >> Starting with what you showed via: > >> > >> http://www.zefox.net/~fbsd/tiptrouble/corrupt_mac > >> > >> (not knowing how you got there) . . . > >> > >> QUOTE > >> FreeBSD/arm (www.zefox.net) (ttyu0) > >> > >> login: root > >> Password: > >> Corrupted MAC on input. > >> ssh_dispatch_run_fatal: Connection to 50.1.20.29 port 22: message authentication code incorrect > >> END QUOTE > >> > >> 50.1.20.29 is supposedly ns2.zefox.net instead of www.zefox.net > >> or ns1.zefox.net according to http://www.zefox.net/~fbsd/netmap . > > > > The netmap was wrong. ns1 and ns2 were swapped....8-( > > It now shows: > > |-50.1.20.29 ns1.zefox.net Pi2 12.3 armv7 ftdi usb-serial----50.1.20.27 > |-50.1.20.30 ns2.zefox.net Pi2 12.3 armv7 2303 usb-serial----50.1.20.29 > |-50.1.20.27 www.zefox.net Pi2 12.3 armv7 2303 usb-serial----50.1.20.26 > > But it later lists the older/inaccurate numbering as well: > > 50.1.20.30 ns1.zefox.net Pi2 v1.1 Fixed > . . . > 50.1.20.29 ns2.zefox.net Pi2 v1.1 Fixed > . . . > 50.1.20.27 www.zefox.net Pi2 v1.1 That's the right IP number for www.zefox.net. 50.1.20.26 is the IP number of the host for which www.zefox.net is the console terminal server. The "usb-serial----------" notation was meant to suggest wires on the right with the USB port (and its host) on the left. Sorry for the confusion! > >> The bugzilla material eventually needs to be updated with something > >> that can be followed and noting the possible occasional hardware or > >> software corruptions of material that end up going over Ethernet > >> that are now demonstrated to be able to cause the symptoms that > >> you have been seeing on occasion for so long. > > > > The netmap is corrected, with a description of the login sequence > > used to watch the serial consoles added. I _think_ it's > > a bit clearer than before, if not please say so. > > Definitely improved description of the context, thanks. Thank you. Clearly my notion of intuitive isn't widespread. bob prohaska > > > From nobody Sun Jan 14 02:45:54 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TCKQW1k4Qz56pHr for ; Sun, 14 Jan 2024 02:45:55 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TCKQV50zNz41fk for ; Sun, 14 Jan 2024 02:45:54 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1705200354; 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; bh=nJ+mWz4NIboK3L81VaNRGE5fU1Yz0hryY8bap77QhxU=; b=OopGgLrZrxBkNSxo1do0VOJI6zemNa3pUbAdx0Eqmjy+xa6v2GAGNYq5+B5R2AXgwMQyNV KQczNnGXbgH2CV6uprEVc1kxTjyYxMg5hVFrt9U7fSKB5xObZ8Gp3SIIWESzP7V1U2UnbX 8WHFZ6g6USqJHGFWlQJNC1g4rSR1zcJ/Tq5hwBqpf/agky2A9aF5rR8FO7d5TQXdrSzKsN iorGfhBCWB+fsgMSF72YawxRX7/1Uwv+rFMymu/V068XQqptg8WSQ5iurt8Xki147gmJrD SB1qyQInqtpbcGML7uieBxtq0bTmHLYqGwBABRtcH57bqaTCzME6XLLXKP2PSA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1705200354; a=rsa-sha256; cv=none; b=Y1n2GY1f35HKsBg37jw213uyOA+LDZXMRHLOhtWKGXpCei+Rc4bF1QURvTz+dqv0Y2aEQG iPcXSCH2DSldplRkmUDaST6xvYLvvkBLFFP2qSTHMn6omCHFDp0TkBaudP8OfhRvyVx845 TFVqfnoMh42PTpwMIn6ZvAdRBVQBScMuLTWbC3pTp0tRgGStKwPlnGrN/Firy4SMl56QZx Zwc63w9xT0Up2N10Otkb53X34Ee8MUeKteiELH8NwclQD6MJYDNLwhwpVzxTyWzOIDu1+M RoYFhu1BjZky1cvvfNP6oJ7EuzCS/wzn+fFW9lESaZcHoMt2/qLKHf56XItYNg== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4TCKQV44R0zwP1 for ; Sun, 14 Jan 2024 02:45:54 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 40E2jseN075035 for ; Sun, 14 Jan 2024 02:45:54 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 40E2jsjr075025 for freebsd-arm@FreeBSD.org; Sun, 14 Jan 2024 02:45:54 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 276309] OS craching [sic] on USB connection Date: Sun, 14 Jan 2024 02:45:54 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 14.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: fbsd@www.zefox.net X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D276309 Bug ID: 276309 Summary: OS craching [sic] on USB connection Product: Base System Version: 14.0-RELEASE Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: fbsd@www.zefox.net This is in response to Warner's closure of bug 205166 The test host I used was a Pi3 booted from a usb mechanical hard drive connected via a powered hub running FreeBSD pelorus.zefox.org 14.0-RELEASE-p4 FreeBSD 14.0-RELEASE-p4 #0 releng/14.0-n265400-4edf3b80733e: Wed Dec 27 20:21:26 PST 2023=20=20=20=20 bob@pelorus:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC arm64 The first test was to connect a former boot disk similar to the one the machine was currently running from. No problem, normal device discovery chatter on the console. Next experiment was to connect a usb-serial adapter with an old Raspian microSD already plugged into it. Response was an immediate reboot, from the Raspian microSD Las experiment was to plug in an FTDI usb-serial adapter, resulting in=20 login: ugen1.4: at usbus1 (disconnected) (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 27 e0 b0 28 00 00 18 00 uhub2: at uhub1, port 2, addr 4 (disconnected) (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error (da0:umass-sim0:0:0:0): Retrying command, 3 more tries remain ugen1.5: at usbus1 (disconnected) (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 27 e0 b0 28 00 00 18 00 umass0: at uhub2, port 2, addr 5 (disconnected) (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error (da0:umass-sim0:0:0:0): Retrying command, 2 more tries remain da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 da0: s/n 000000000000A detached g_vfs_done(): da0p2 converting all errors to ENXIO g_vfs_done():da0p2[WRITE(offset=3D342274080768, length=3D12288)]error =3D 6 supressing further ENXIO panic: UFS: root fs would be forcibly unmounted cpuid =3D 0 time =3D 1705223363 KDB: stack backtrace: #0 0xffff00000050d52c at kdb_backtrace+0x58 #1 0xffff0000004b9044 at vpanic+0x19c #2 0xffff0000004b8ea4 at panic+0x44 #3 0xffff0000007fd290 at ffs_fsfail_cleanup+0x178 #4 0xffff0000007d1748 at ffs_update+0x300 #5 0xffff00000080534c at ffs_syncvnode+0x62c #6 0xffff000000803ce4 at ffs_fsync+0x28 #7 0xffff0000005cdd84 at kern_fsync+0x1b0 #8 0xffff000000896628 at do_el0_sync+0x5b0 #9 0xffff000000874110 at handle_el0_sync+0x44 Uptime: 6m28s Resetting system ...had to pull the plug. All three tests were done via the powered usb hub. I'll add that even Pi4 RasPiOS isn't immune to such mischief. Plugging in the same usb-microSD adapter with a card inserted stops the mouse and keyboard working, with power cycling the easiest recovery. Plugging in the adapter without a card and then inserting the card allows normal recognition. Haven't tried that with FreeBSD recently, it used to work also. The FT232 also crashed RasPiOS, disabling keyboard and mouse. The RasPiOS experiments didn't use a powered hub, but neither device draws much power. USB still seems a work in progress. --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Sun Jan 14 10:52:34 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TCXD85TzYz57f2W for ; Sun, 14 Jan 2024 10:52:40 +0000 (UTC) (envelope-from void@f-m.fm) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4TCXD75pgPz4qVq for ; Sun, 14 Jan 2024 10:52:39 +0000 (UTC) (envelope-from void@f-m.fm) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=f-m.fm header.s=fm2 header.b=utWXw90V; dkim=pass header.d=messagingengine.com header.s=fm2 header.b=9YesXRk4; dmarc=pass (policy=none) header.from=f-m.fm; spf=pass (mx1.freebsd.org: domain of void@f-m.fm designates 64.147.123.20 as permitted sender) smtp.mailfrom=void@f-m.fm Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id 6B783320090C for ; Sun, 14 Jan 2024 05:52:37 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute6.internal (MEProxy); Sun, 14 Jan 2024 05:52:37 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=f-m.fm; h=cc :content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm2; t=1705229556; x=1705315956; bh=XZ40k9GXWa JW2h9f7b1QzYm8k33+woDqLUeYMZ3Y2a4=; b=utWXw90VNQuww9VzCy2uJgfLg3 opOO1TmI2iIRT5KF0UPRhiIJS3MbuiQs2WWEb+Gig0DrwVI7oIgHIycutJI5dqXj jfEKe0mSXMcKac1RXFW2cvNDgvICrqiU1fuP1/NcJJf4chyqcWpmgIoqoZ2pc6Vp D2wQbWn9OKyYRIU1zt3m3TJwMo7RQVULpbVzc9YdR1ooxM3LUE0lMLpGCte0KpI2 FFvUoG1mlP4O4ZhsnU1CmvjKt8tnp/D/lt4Hlcp4/b9YIGHnLd3AbDRZDilrs9sV aK437Xdclkh4UB23qade8JL40oDfLUZXTiN5Mg4Ymb/MslitcR0gVBGCkrwQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; t=1705229556; x=1705315956; bh=XZ40k9GXWaJW2h9f7b1QzYm8k33+ woDqLUeYMZ3Y2a4=; b=9YesXRk4ciZ1UQ6OeJbfmWxXo+EXPHy5qUx35KsWuDUe wvvh/too5zeFdpHC0eRx7eIOxKKaLkVTlmalqNluNtSruOh/JU6NzWPcAbBJc//B qREn7EmpkijPZPcPpXyNtgJQzpgnPpglTpKVaaiDwyXObxwnyWORPlTBF0JXHVqb V1F3eLuxNXZLy5fPMLl06Le6NnaWtpHYwC5Y5W+P284NCOzfH9XS4hE8If554m4r X9H0FY1RxGPiZykQbAjShL9+GdTQhoQHgl7oK4KaJKZtgiB3RR7kJM7EepkBS24y CzEHU4svDof2sUQoVxVYomWaMaDlmTtNka1Zmg9Syg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrvdeiledgvdduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggujgesthdtre dttddtvdenucfhrhhomhepvhhoihguuceovhhoihgusehfqdhmrdhfmheqnecuggftrfgr thhtvghrnhepkeeluddvlefhieelfefggffhffektdehleelgfdugfdvgeekjeejuddthe ehgfeunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhep vhhoihgusehfqdhmrdhfmh X-ME-Proxy: Feedback-ID: i2541463c:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Sun, 14 Jan 2024 05:52:36 -0500 (EST) Date: Sun, 14 Jan 2024 10:52:34 +0000 From: void To: freebsd-arm@freebsd.org Subject: Re: USB-serial adapter suggestions needed Message-ID: Mail-Followup-To: freebsd-arm@freebsd.org References: <7D27DF9F-AA9A-4D44-BC28-8CC637D0F550@yahoo.com> List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: X-Spamd-Bar: ---- X-Spamd-Result: default: False [-5.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MID_RHS_NOT_FQDN(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[f-m.fm,none]; RWL_MAILSPIKE_EXCELLENT(-0.40)[64.147.123.20:from]; R_DKIM_ALLOW(-0.20)[f-m.fm:s=fm2,messagingengine.com:s=fm2]; R_SPF_ALLOW(-0.20)[+ip4:64.147.123.20]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[64.147.123.20:from]; FROM_HAS_DN(0.00)[]; RCVD_TLS_LAST(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; RCVD_COUNT_THREE(0.00)[3]; RCPT_COUNT_ONE(0.00)[1]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; TO_DN_NONE(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; DKIM_TRACE(0.00)[f-m.fm:+,messagingengine.com:+]; ASN(0.00)[asn:29838, ipnet:64.147.123.0/24, country:US]; FREEMAIL_FROM(0.00)[f-m.fm]; MISSING_XM_UA(0.00)[]; FREEMAIL_ENVFROM(0.00)[f-m.fm] X-Rspamd-Queue-Id: 4TCXD75pgPz4qVq Hi Bob, The following *may* be useful to you.. (rpi4 context) I've noticed, both on 13-stable and 14-stable, that, if both onboard usb2 ports are utilised (eg keyboard & mouse) that signals keyboard<>mouse interfere with each other. It's easy to reproduce this problem. It's been a while since testing that exact context, though. When running headless, I needed to make sure the ups cable (serial) was plugged into the remaining usb3 port (and not usb2 where a wifi dongle was plugged in) because communication from the ups would make the wifi page down if both were plugged into the usb2 side. The wifi would make the usb serial misbehave (caused 'no signal coming from ups' type of error) too. I've had to press the hardware into service so cannot produce detailed error output for now. -- From nobody Sun Jan 14 13:41:34 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TCbzF4XyNz56C1b for ; Sun, 14 Jan 2024 13:41:45 +0000 (UTC) (envelope-from dfr@rabson.org) Received: from mail-yw1-x112a.google.com (mail-yw1-x112a.google.com [IPv6:2607:f8b0:4864:20::112a]) (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 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TCbzD3yvXz57V2 for ; Sun, 14 Jan 2024 13:41:44 +0000 (UTC) (envelope-from dfr@rabson.org) Authentication-Results: mx1.freebsd.org; none Received: by mail-yw1-x112a.google.com with SMTP id 00721157ae682-5ed10316e22so72235997b3.3 for ; Sun, 14 Jan 2024 05:41:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rabson-org.20230601.gappssmtp.com; s=20230601; t=1705239703; x=1705844503; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=EcN47z5hI3HnJ8G11xdMw7TU3MWB3QVbrr5z5OXohyE=; b=WN9ILPNFV8Gp59ohBoukOt/lZfPTn/GW38NMPUPOK6ksnq/oNp7rwLqmkgUYAHFVXC earSNvRl1uCesBc6x7OZBCERfeOLmbfpgWXSpwd9DjX5NrHSeD1fX65YBy6aMGfaV/1L dbGgtGDeFBSprT6UH7g/1FcHqKPLucE+9iobEoBCjWc6FkosGY6devr0WL8biyA4Gae4 M8biiSmCnMjJpVIo6Uf2QCpFAQ7EcwGUXHgIXNIw6vQu4G0JbQ+nPmM5l17brkQEt1/V lzn3Ifm/cB/dxk/Xn7lqdYtL8jSjF0uiD5fVirQlbGrih2up6t2h7RiGy141CM1/CenC l40Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705239703; x=1705844503; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=EcN47z5hI3HnJ8G11xdMw7TU3MWB3QVbrr5z5OXohyE=; b=F31DGISjCr+USAK0eQDeIz8KOP4jbZJVqoesu17d2Sm0R9CFbNAqGJojG+QMqmZ8zS Hj9uwFM+ZQbQN9EHdJFR66/tMorcSp/mRnZbCJqNmTN2MnHJga9gtVmVZV2A/++iQfcF Wu9tTI9N214QVdpaA83aYiOr+H+BpIGiZGppU1W2quNcwAvZlgpuuTyFpJb3QDwCwwcH XNeWAHHwGydNZMw7JMVdhjf8zGmBGXyipkidqgesYYzUPCYx/fBBjxcNGuoXid4gK9EX 1LHdmlY7cZY2Q9b8lJDJJ7lWoJcdJpRu2g+GHVYCNR0fuuqEe6RHol/wepQkbh3pNSFp 2png== X-Gm-Message-State: AOJu0YwmfVWaE0eZjPkpO/FZDeD+hLhzQra43d3+RXYbm8cPBXrxD7WW V9AbYeSnFAZnmudbc1KWiBxUl3rLcAg2ldK4QbuHDwQPAeEwdw== X-Google-Smtp-Source: AGHT+IEybvnc0MovAS70OEwflzYXWkwHZyDCXpDKrXGfokKZ1UForPmihpmccUqp/fwrLpb0Sa6pfWqOf5o+lXan9zk= X-Received: by 2002:a81:a9ca:0:b0:5f5:aba8:7c3f with SMTP id g193-20020a81a9ca000000b005f5aba87c3fmr2786059ywh.53.1705239703591; Sun, 14 Jan 2024 05:41:43 -0800 (PST) List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 References: <5a39810c-5fd8-4969-a222-2561b050b035@FreeBSD.org> <347FE009-A470-4765-A9B9-7C9AB5E954DA@yahoo.com> <76FA010A-338F-4E32-B381-37C7BA63CAFC@yahoo.com> <9e45c7d7-450c-48e5-8101-c6ea5cb3a023@FreeBSD.org> In-Reply-To: <9e45c7d7-450c-48e5-8101-c6ea5cb3a023@FreeBSD.org> From: Doug Rabson Date: Sun, 14 Jan 2024 13:41:34 +0000 Message-ID: Subject: Re: When will FreeBSD support RPI5? To: Jesper Schmitz Mouridsen Cc: Mark Millard , John Kennedy , ykla , FreeBSD ARM List Content-Type: multipart/alternative; boundary="000000000000ca324c060ee80e74" X-Rspamd-Queue-Id: 4TCbzD3yvXz57V2 X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] --000000000000ca324c060ee80e74 Content-Type: text/plain; charset="UTF-8" On Sat, 13 Jan 2024 at 19:22, Jesper Schmitz Mouridsen wrote: > > On 13.01.2024 19.32, Mark Millard wrote: > > On Jan 13, 2024, at 07:38, Doug Rabson wrote: > > > >> Getting back to the RPI 5, with a tweak to > arm/broadcom/bcm2835bcm2835_vcbus.c to treat the memory config the same as > RPI 4 and to dev/sdhci/sdhci_fdt.c to treat the RPI 5 sdhci controllers as > generic, I can boot to multiuser mode using the EDK2 firmware from > https://github.com/worproject/rpi5-uefi with ACPI/Device Tree mode set to > Both. > > What does FreeBSD do with "Both"? Does it actually use some ACPI > > and some Device Tree? Or does it just use ACPI? Does your > > combination do anything different than just using ACPI? > > How does the sd card show up? BTW i did put some stuff here [1] > > I could not get bcm_dma to work anyone planning on getting that to work? > it should be similar to 2711 documented in [2] > I haven't tried to do anything with bcm_dma - this is my diff (against 14.0 but I'll probably move over to 15-current soon). I used the generic SDHCI driver in sys/dev/sdhci and it seems to work very well with the RPI 5: diff --git a/sys/arm/broadcom/bcm2835/bcm2835_vcbus.c b/sys/arm/broadcom/bcm2835/bcm2835_vcbus.c index 88b54467e0c8..d996831816a6 100644 --- a/sys/arm/broadcom/bcm2835/bcm2835_vcbus.c +++ b/sys/arm/broadcom/bcm2835/bcm2835_vcbus.c @@ -174,6 +174,11 @@ static struct bcm283x_memory_soc_cfg { .soc_compat = "brcm,bcm2838", .busdma_lowaddr = BCM2838_PERIPH_MAXADDR, }, + { + .memmap = bcm2838_memmap, + .soc_compat = "brcm,bcm2712", + .busdma_lowaddr = BCM2838_PERIPH_MAXADDR, + }, }; static struct bcm283x_memory_soc_cfg *booted_soc_memcfg; diff --git a/sys/dev/sdhci/sdhci_fdt.c b/sys/dev/sdhci/sdhci_fdt.c index 4a355d6514ad..8f2ccfc98859 100644 --- a/sys/dev/sdhci/sdhci_fdt.c +++ b/sys/dev/sdhci/sdhci_fdt.c @@ -124,6 +124,7 @@ static struct ofw_compat_data compat_data[] = { { "xlnx,zy7_sdhci", SDHCI_FDT_XLNX_ZY7 }, { "rockchip,rk3568-dwcmshc", SDHCI_FDT_RK3568 }, { "xlnx,zynqmp-8.9a", SDHCI_FDT_XLNX_ZMP }, + { "brcm,bcm2712-sdhci", SDHCI_FDT_GENERIC }, { NULL, 0 } }; > > --000000000000ca324c060ee80e74 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sat, 13 Jan 2024 at 19:22, Jesper = Schmitz Mouridsen <jsm@freebsd.org> wrote:

On 13.01.2024 19.32, Mark Millard wrote:
> On Jan 13, 2024, at 07:38, Doug Rabson <dfr@rabson.org> wrote:
>
>> Getting back to the RPI 5, with a tweak to arm/broadcom/bcm2835bcm= 2835_vcbus.c to treat the memory config the same as RPI 4 and to dev/sdhci/= sdhci_fdt.c to treat the RPI 5 sdhci controllers as generic, I can boot to = multiuser mode using the EDK2 firmware from https://github.co= m/worproject/rpi5-uefi with ACPI/Device Tree mode set to Both.
> What does FreeBSD do with "Both"? Does it actually use some = ACPI
> and some Device Tree? Or does it just use ACPI? Does your
> combination do anything different than just using ACPI?

How does the sd card show up? BTW i did put some stuff here [1]

I could not get bcm_dma to work anyone planning on getting that to work? it should be similar to 2711 documented in [2]

I haven't tried to do anything with bcm_dma - this is my diff (= against=C2=A014.0 but I'll probably move over to 15-current soon). I us= ed the generic SDHCI driver in sys/dev/sdhci and it seems to work very well= with the RPI 5:

diff --git = a/sys/arm/broadcom/bcm2835/bcm2835_vcbus.c b/sys/arm/broadcom/bcm2835/bcm28= 35_vcbus.c
index 88b54467e0c8..d996831816a6 100644
--- a/sys/arm/broa= dcom/bcm2835/bcm2835_vcbus.c
+++ b/sys/arm/broadcom/bcm2835/bcm2835_vcbu= s.c
@@ -174,6 +174,11 @@ static struct bcm283x_memory_soc_cfg {
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 .soc_compat =3D "= brcm,bcm2838",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 .busdma_lowaddr =3D BCM2838_PERIPH_MAXADDR,
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 },
+ =C2=A0 =C2=A0 =C2=A0 {
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 .memmap =3D bcm2838_memmap,
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 .soc_compat =3D "brcm,bcm2712",
+ =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 .busdma_lowaddr =3D BCM2838_PERIP= H_MAXADDR,
+ =C2=A0 =C2=A0 =C2=A0 },
=C2=A0};

=C2=A0static str= uct bcm283x_memory_soc_cfg *booted_soc_memcfg;
diff --git a/sys/dev/sdhc= i/sdhci_fdt.c b/sys/dev/sdhci/sdhci_fdt.c
index 4a355d6514ad..8f2ccfc988= 59 100644
--- a/sys/dev/sdhci/sdhci_fdt.c
+++ b/sys/dev/sdhci/sdhci_f= dt.c
@@ -124,6 +124,7 @@ static struct ofw_compat_data compat_data[] =3D= {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 { "xlnx,zy7_sdhci", =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 SDHCI_FDT_XLNX_ZY7 },
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 { "rockchip,rk3568-dwcmshc", =C2=A0 =C2=A0SDHCI_FDT_RK= 3568 },
=C2=A0 =C2=A0 =C2=A0 =C2=A0 { "xlnx,zynqmp-8.9a", =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 SDHCI_FDT_XLNX_ZMP },
+ =C2=A0 =C2=A0 = =C2=A0 { "brcm,bcm2712-sdhci", =C2=A0 =C2=A0 =C2=A0 =C2=A0 SDHCI_= FDT_GENERIC },
=C2=A0 =C2=A0 =C2=A0 =C2=A0 { NULL, 0 }
=C2=A0};
=C2=A0

--000000000000ca324c060ee80e74-- From nobody Sun Jan 14 13:52:51 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TCcDH09S7z56D77 for ; Sun, 14 Jan 2024 13:53:03 +0000 (UTC) (envelope-from dfr@rabson.org) Received: from mail-yw1-x1131.google.com (mail-yw1-x1131.google.com [IPv6:2607:f8b0:4864:20::1131]) (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 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TCcDG4VHMz591R for ; Sun, 14 Jan 2024 13:53:02 +0000 (UTC) (envelope-from dfr@rabson.org) Authentication-Results: mx1.freebsd.org; none Received: by mail-yw1-x1131.google.com with SMTP id 00721157ae682-5e778e484dbso71529547b3.0 for ; Sun, 14 Jan 2024 05:53:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rabson-org.20230601.gappssmtp.com; s=20230601; t=1705240380; x=1705845180; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=xPkIYjLkgB891csuesD6+1k7pM3OpOajxPbi+K+jOr0=; b=1ak1fVrx9qg4YpCkmSfotj6GcJkNiBR6i7qOmxS6TZHFTX8SBlK9UfjkRZJKFbSekZ OGG0rAwCz0yve+5JuUlWmGvKu9hZ70tX6yay81siR2vmq+jnn05hx9GFgfl/v8waZHZq PWw5Oe6urazGMtyNZEhLZzGk3PWom4GLR/dZlCTgHcTXudY8UXfDzVNU5+zLU0BVGi/A KvWNtZpN/KcAa9v7Om65o1CYxTMzlUtPWYPfLov187IZLeI2CHKxboEVQxTCUFoS2jbU QowaV2qmnd/MrbN70lwNDJ68YLfWsJLAyi/O64Ptx1j+6xKPt9C2vAKX6urzSp4W1g+2 ldVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705240380; x=1705845180; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=xPkIYjLkgB891csuesD6+1k7pM3OpOajxPbi+K+jOr0=; b=Gj3AvDJBLf3+VY+8hsi9dBpeRRQQ0FrL3wUmvEWYcTgAjAOS9WJQeVssUeUkW7b/cK pmRLUoiQCXRaC/iJqOklUgBsTkmp3Ym8G0Mg/4Si6x/2afExv6RFWf4Vd9A/Dlk0cOH9 yZt47hPor2hPwbK6J80M6nwtSvujOX5YR3d9XRyaCfsplvVLeDIJixBHpzbOqVIXFLo+ AeIImzgc/+HgzahTd6jeHuvDIadDI6dYJWsWTdzt/6eBJXzP1xnWUp/u0vEXDrl6rE98 GPHXydoQACNMB+r5IfzJQRF9HRDYDoEWy5a6rx5+U+y9uA4zuKXmirsvH5dh2w4zAJ9T beDA== X-Gm-Message-State: AOJu0Yzc0ZHbzy20P3qx2No5XjWkUMXxrgV1plUwe6R1l+z5tfRDwDzX rAiwJcJHvGVU7jtmGklFpg9ZbMVD276Yb0gJAk7NFfFdR9M+F0JfvLzoDersM4+do8bk X-Google-Smtp-Source: AGHT+IEpT5BZYY7nTkkX6ejGQA0u9WyNPsGnkkyfnSfLaQ4fq2EpcL4X1uWKQ8nUWaGmQRq4nYpX4H9zN6GbCobGn+g= X-Received: by 2002:a81:ae28:0:b0:5e8:8053:70d1 with SMTP id m40-20020a81ae28000000b005e8805370d1mr2674633ywh.50.1705240380134; Sun, 14 Jan 2024 05:53:00 -0800 (PST) List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 References: <5a39810c-5fd8-4969-a222-2561b050b035@FreeBSD.org> <347FE009-A470-4765-A9B9-7C9AB5E954DA@yahoo.com> <76FA010A-338F-4E32-B381-37C7BA63CAFC@yahoo.com> In-Reply-To: <76FA010A-338F-4E32-B381-37C7BA63CAFC@yahoo.com> From: Doug Rabson Date: Sun, 14 Jan 2024 13:52:51 +0000 Message-ID: Subject: Re: When will FreeBSD support RPI5? To: Mark Millard Cc: Jesper Schmitz Mouridsen , John Kennedy , ykla , FreeBSD ARM List Content-Type: multipart/mixed; boundary="0000000000001e2b12060ee8371c" X-Rspamd-Queue-Id: 4TCcDG4VHMz591R X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] --0000000000001e2b12060ee8371c Content-Type: multipart/alternative; boundary="0000000000001e2b0f060ee8371a" --0000000000001e2b0f060ee8371a Content-Type: text/plain; charset="UTF-8" On Sat, 13 Jan 2024 at 18:32, Mark Millard wrote: > On Jan 13, 2024, at 07:38, Doug Rabson wrote: > > > Getting back to the RPI 5, with a tweak to > arm/broadcom/bcm2835bcm2835_vcbus.c to treat the memory config the same as > RPI 4 and to dev/sdhci/sdhci_fdt.c to treat the RPI 5 sdhci controllers as > generic, I can boot to multiuser mode using the EDK2 firmware from > https://github.com/worproject/rpi5-uefi with ACPI/Device Tree mode set to > Both. > > What does FreeBSD do with "Both"? Does it actually use some ACPI > and some Device Tree? Or does it just use ACPI? Does your > combination do anything different than just using ACPI? > > > This does not have working PCIe or ethernet yet - I think ethernet ought > to work since we seem to have a matching driver in the tree in dev/cadence. > > Sounds like the same status as booting just ACPI with no such > adjustments too bcm2835bcm2835_vcbus.c or sdhci_fdt.c ? > > I think Mike Karels plans on investigating getting Ethernet > going based on cgem . I've no clue if this is ACPI, DeviceTree, > or both. > > My usage has been pure ACPI, no software adjustments specific > to getting the RPi5 operational. Use of a USB3 Ethernet dongle. > As far as I can tell, 'Both' works almost exactly the same as 'Devicetree' - I don't think the acpi device is attached to nexus at all. Ethernet should be supported by cgem(4). This device is on the rp1 southbridge. In the DTB, rp1 is a simplebus under pcie@120000 and ethernet@100000 is a child of rp1. I think it doesn't match for me because there is no driver matching pcie@ yet. The existing bcm2838 pci driver could be adapted for RPI 5 - reading the linux driver shows some smallish differences in device initialisation. I have attached verbose dmesg dumps for all three EDK2 acpi modes. > --0000000000001e2b0f060ee8371a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sat, 13 Jan 2024 at 18:32, Mark Mi= llard <marklmi@yahoo.com> wr= ote:
On Jan 13, 2024, at 07:38, Doug Rabson <<= a href=3D"mailto:dfr@rabson.org" target=3D"_blank">dfr@rabson.org> w= rote:

> Getting back to the RPI 5, with a tweak to arm/broadcom/bcm2835bcm2835= _vcbus.c to treat the memory config the same as RPI 4 and to dev/sdhci/sdhc= i_fdt.c to treat the RPI 5 sdhci controllers as generic, I can boot to mult= iuser mode using the EDK2 firmware from https://github.com/wo= rproject/rpi5-uefi with ACPI/Device Tree mode set to Both.

What does FreeBSD do with "Both"? Does it actually use some ACPI<= br> and some Device Tree? Or does it just use ACPI? Does your
combination do anything different than just using ACPI?

> This does not have working PCIe or ethernet yet - I think ethernet oug= ht to work since we seem to have a matching driver in the tree in dev/caden= ce.

Sounds like the same status as booting just ACPI with no such
adjustments too bcm2835bcm2835_vcbus.c or sdhci_fdt.c ?

I think Mike Karels plans on investigating getting Ethernet
going based on cgem . I've no clue if this is ACPI, DeviceTree,
or both.

My usage has been pure ACPI, no software adjustments specific
to getting the RPi5 operational. Use of a USB3 Ethernet dongle.

As far as I can tell, 'Both' works almost = exactly the same as 'Devicetree' - I don't think the acpi devic= e is attached to nexus at all.

Ethernet should be = supported by cgem(4). This device is on the rp1 southbridge. In the DTB, rp= 1 is a simplebus under=C2=A0pcie@120000 and=C2=A0ethernet@100000 is a child= of rp1. I think it doesn't match for me because there is no driver mat= ching pcie@ yet. The existing bcm2838 pci driver could be adapted for RPI 5= - reading the linux driver shows some smallish differences in device initi= alisation.

I have attached verbose dmesg dumps for= all three EDK2 acpi modes.


--0000000000001e2b0f060ee8371a-- --0000000000001e2b12060ee8371c Content-Type: application/octet-stream; name=dmesg-acpi-only Content-Disposition: attachment; filename=dmesg-acpi-only Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_lrdk2xhp0 LS0tPDxCT09UPj4tLS0KICAgICAgICAgICAgICAgICAgIFR5cGUgICAgIFBoeXNpY2FsICAgICAg VmlydHVhbCAgICNQYWdlcyBBdHRyCiAgICAgICAgICAgICAgIFJlc2VydmVkIDAwMDAwMDAwMDAw MCAwMDAwMDAwMDAwMDAgMDAwMDAxZDAgV0MgV1QgV0IgCiAgICBSdW50aW1lU2VydmljZXNEYXRh IDAwMDAwMDFkMDAwMCAwMDAwMDAxZDAwMDAgMDAwMDAwMjAgV0MgV1QgV0IgUlVOVElNRQogICAg ICAgICAgICAgICBSZXNlcnZlZCAwMDAwMDAxZjAwMDAgMDAwMDAwMDAwMDAwIDAwMDAwMDIwIFdD IFdUIFdCIAogICAgIENvbnZlbnRpb25hbE1lbW9yeSAwMDAwMDAyMTAwMDAgMDAwMDAwMDAwMDAw IDAwMDMwMTRlIFdDIFdUIFdCIAogICAgICAgICAgICAgTG9hZGVyQ29kZSAwMDAwMzAzNWUwMDAg MDAwMDAwMDAwMDAwIDAwMDA0MDAwIFdDIFdUIFdCIAogICAgICAgICAgICAgTG9hZGVyRGF0YSAw MDAwMzQzNWUwMDAgMDAwMDAwMDAwMDAwIDAwMDA0MDAwIFdDIFdUIFdCIAogICAgICAgICAgICAg TG9hZGVyQ29kZSAwMDAwMzgzNWUwMDAgMDAwMDAwMDAwMDAwIDAwMDAwMGQyIFdDIFdUIFdCIAog ICAgUnVudGltZVNlcnZpY2VzRGF0YSAwMDAwMzg0MzAwMDAgMDAwMDM4NDMwMDAwIDAwMDAwMDUw IFdDIFdUIFdCIFJVTlRJTUUKICAgICBDb252ZW50aW9uYWxNZW1vcnkgMDAwMDM4NDgwMDAwIDAw MDAwMDAwMDAwMCAwMDAwMDAwMiBXQyBXVCBXQiAKICAgICAgICAgICAgICAgUmVzZXJ2ZWQgMDAw MDM4NDgyMDAwIDAwMDAwMDAwMDAwMCAwMDAwMDA0ZSBXQyBXVCBXQiAKICAgIFJ1bnRpbWVTZXJ2 aWNlc0RhdGEgMDAwMDM4NGQwMDAwIDAwMDAzODRkMDAwMCAwMDAwMDA0MCBXQyBXVCBXQiBSVU5U SU1FCiAgICBSdW50aW1lU2VydmljZXNDb2RlIDAwMDAzODUxMDAwMCAwMDAwMzg1MTAwMDAgMDAw MDAwNDAgV0MgV1QgV0IgUlVOVElNRQogICAgUnVudGltZVNlcnZpY2VzRGF0YSAwMDAwMzg1NTAw MDAgMDAwMDM4NTUwMDAwIDAwMDAwMDUwIFdDIFdUIFdCIFJVTlRJTUUKICAgIFJ1bnRpbWVTZXJ2 aWNlc0NvZGUgMDAwMDM4NWEwMDAwIDAwMDAzODVhMDAwMCAwMDAwMDBkMCBXQyBXVCBXQiBSVU5U SU1FCiAgICAgIEFDUElSZWNsYWltTWVtb3J5IDAwMDAzODY3MDAwMCAwMDAwMDAwMDAwMDAgMDAw MDAwMTAgV0MgV1QgV0IgCiAgICBSdW50aW1lU2VydmljZXNEYXRhIDAwMDAzODY4MDAwMCAwMDAw Mzg2ODAwMDAgMDAwMDAwMjAgV0MgV1QgV0IgUlVOVElNRQogICAgUnVudGltZVNlcnZpY2VzQ29k ZSAwMDAwMzg2YTAwMDAgMDAwMDM4NmEwMDAwIDAwMDAwMGEwIFdDIFdUIFdCIFJVTlRJTUUKICAg ICBDb252ZW50aW9uYWxNZW1vcnkgMDAwMDM4NzQwMDAwIDAwMDAwMDAwMDAwMCAwMDAwMDAwMyBX QyBXVCBXQiAKICAgICAgICAgICAgIExvYWRlckRhdGEgMDAwMDM4NzQzMDAwIDAwMDAwMDAwMDAw MCAwMDAwMDAwMSBXQyBXVCBXQiAKICAgICBDb252ZW50aW9uYWxNZW1vcnkgMDAwMDM4NzQ0MDAw IDAwMDAwMDAwMDAwMCAwMDAwMWM1MCBXQyBXVCBXQiAKICAgICAgIEJvb3RTZXJ2aWNlc0RhdGEg MDAwMDNhMzk0MDAwIDAwMDAwMDAwMDAwMCAwMDAwMDAwOSBXQyBXVCBXQiAKICAgICBDb252ZW50 aW9uYWxNZW1vcnkgMDAwMDNhMzlkMDAwIDAwMDAwMDAwMDAwMCAwMDAwMDAwNCBXQyBXVCBXQiAK ICAgICAgIEJvb3RTZXJ2aWNlc0RhdGEgMDAwMDNhM2ExMDAwIDAwMDAwMDAwMDAwMCAwMDAwMDAw MyBXQyBXVCBXQiAKICAgICBDb252ZW50aW9uYWxNZW1vcnkgMDAwMDNhM2E0MDAwIDAwMDAwMDAw MDAwMCAwMDAwMDAwMSBXQyBXVCBXQiAKICAgICAgIEJvb3RTZXJ2aWNlc0RhdGEgMDAwMDNhM2E1 MDAwIDAwMDAwMDAwMDAwMCAwMDAwMDAwNSBXQyBXVCBXQiAKICAgICBDb252ZW50aW9uYWxNZW1v cnkgMDAwMDNhM2FhMDAwIDAwMDAwMDAwMDAwMCAwMDAwMDAwMyBXQyBXVCBXQiAKICAgICAgIEJv b3RTZXJ2aWNlc0RhdGEgMDAwMDNhM2FkMDAwIDAwMDAwMDAwMDAwMCAwMDAwMDAwNCBXQyBXVCBX QiAKICAgICBDb252ZW50aW9uYWxNZW1vcnkgMDAwMDNhM2IxMDAwIDAwMDAwMDAwMDAwMCAwMDAw MDAwMSBXQyBXVCBXQiAKICAgICAgIEJvb3RTZXJ2aWNlc0RhdGEgMDAwMDNhM2IyMDAwIDAwMDAw MDAwMDAwMCAwMDAwMDAwNyBXQyBXVCBXQiAKICAgICBDb252ZW50aW9uYWxNZW1vcnkgMDAwMDNh M2I5MDAwIDAwMDAwMDAwMDAwMCAwMDAwMDAwMSBXQyBXVCBXQiAKICAgICAgIEJvb3RTZXJ2aWNl c0RhdGEgMDAwMDNhM2JhMDAwIDAwMDAwMDAwMDAwMCAwMDAwMTI3ZSBXQyBXVCBXQiAKICAgICBD b252ZW50aW9uYWxNZW1vcnkgMDAwMDNiNjM4MDAwIDAwMDAwMDAwMDAwMCAwMDAwMDA1MCBXQyBX VCBXQiAKICAgICAgIEJvb3RTZXJ2aWNlc0NvZGUgMDAwMDNiNjg4MDAwIDAwMDAwMDAwMDAwMCAw MDAwMDM5OCBXQyBXVCBXQiAKICAgIFJ1bnRpbWVTZXJ2aWNlc0NvZGUgMDAwMDNiYTIwMDAwIDAw MDAzYmEyMDAwMCAwMDAwMDA5MCBXQyBXVCBXQiBSVU5USU1FCiAgICAgQ29udmVudGlvbmFsTWVt b3J5IDAwMDAzYmFiMDAwMCAwMDAwMDAwMDAwMDAgMDAwMDAwMTAgV0MgV1QgV0IgCiAgICBSdW50 aW1lU2VydmljZXNEYXRhIDAwMDAzYmFjMDAwMCAwMDAwM2JhYzAwMDAgMDAwMDAxMjAgV0MgV1Qg V0IgUlVOVElNRQogICAgIENvbnZlbnRpb25hbE1lbW9yeSAwMDAwM2JiZTAwMDAgMDAwMDAwMDAw MDAwIDAwMDAwMDFmIFdDIFdUIFdCIAogICAgICAgQm9vdFNlcnZpY2VzRGF0YSAwMDAwM2JiZmYw MDAgMDAwMDAwMDAwMDAwIDAwMDAwMDAxIFdDIFdUIFdCIAogICAgIENvbnZlbnRpb25hbE1lbW9y eSAwMDAwM2JjMDAwMDAgMDAwMDAwMDAwMDAwIDAwMDAzMjUwIFdDIFdUIFdCIAogICAgICAgQm9v dFNlcnZpY2VzQ29kZSAwMDAwM2VlNTAwMDAgMDAwMDAwMDAwMDAwIDAwMDAwMDM4IFdDIFdUIFdC IAogICAgICAgQm9vdFNlcnZpY2VzRGF0YSAwMDAwM2VlODgwMDAgMDAwMDAwMDAwMDAwIDAwMDAw ZDc4IFdDIFdUIFdCIAogICAgIENvbnZlbnRpb25hbE1lbW9yeSAwMDAwNDAwMDAwMDAgMDAwMDAw MDAwMDAwIDAwMWMwMDAwIFdDIFdUIFdCIAogICAgICAgICBNZW1vcnlNYXBwZWRJTyAwMDEwN2Mw MTMwMDAgMDAxMDdjMDEzMDAwIDAwMDAwMDAxIFVDIFJVTlRJTUUKUGh5c2ljYWwgbWVtb3J5IGNo dW5rKHMpOgogIDB4MDAxZDAwMDAgLSAweDAwMWVmZmZmLCAgICAgMCBNQiAoICAgICAzMiBwYWdl cykKICAweDAwMjEwMDAwIC0gMHgzODQ4MWZmZiwgICA4OTggTUIgKCAyMzAwMDIgcGFnZXMpCiAg MHgzODRkMDAwMCAtIDB4M2ZiZmZmZmYsICAgMTE5IE1CICggIDMwNTEyIHBhZ2VzKQogIDB4NDAw MDAwMDAgLSAweDFmZmZmZmZmZiwgIDcxNjggTUIgKDE4MzUwMDggcGFnZXMpCkV4Y2x1ZGVkIG1l bW9yeSByZWdpb25zOgogIDB4MDAxZDAwMDAgLSAweDAwMWVmZmZmLCAgICAgMCBNQiAoICAgICAz MiBwYWdlcykgTm9BbGxvYyAKICAweDMwNDAwMDAwIC0gMHgzMWU1ZWZmZiwgICAgMjYgTUIgKCAg IDY3NTEgcGFnZXMpIE5vQWxsb2MgCiAgMHgzODQzMDAwMCAtIDB4Mzg0N2ZmZmYsICAgICAwIE1C ICggICAgIDgwIHBhZ2VzKSBOb0FsbG9jIAogIDB4Mzg0ZDAwMDAgLSAweDM4NzNmZmZmLCAgICAg MiBNQiAoICAgIDYyNCBwYWdlcykgTm9BbGxvYyAKICAweDNiYTIwMDAwIC0gMHgzYmFhZmZmZiwg ICAgIDAgTUIgKCAgICAxNDQgcGFnZXMpIE5vQWxsb2MgCiAgMHgzYmFjMDAwMCAtIDB4M2JiZGZm ZmYsICAgICAxIE1CICggICAgMjg4IHBhZ2VzKSBOb0FsbG9jIApGb3VuZCA0IENQVXMgaW4gdGhl IEFDUEkgdGFibGVzCkNvcHlyaWdodCAoYykgMTk5Mi0yMDIzIFRoZSBGcmVlQlNEIFByb2plY3Qu CkNvcHlyaWdodCAoYykgMTk3OSwgMTk4MCwgMTk4MywgMTk4NiwgMTk4OCwgMTk4OSwgMTk5MSwg MTk5MiwgMTk5MywgMTk5NAoJVGhlIFJlZ2VudHMgb2YgdGhlIFVuaXZlcnNpdHkgb2YgQ2FsaWZv cm5pYS4gQWxsIHJpZ2h0cyByZXNlcnZlZC4KRnJlZUJTRCBpcyBhIHJlZ2lzdGVyZWQgdHJhZGVt YXJrIG9mIFRoZSBGcmVlQlNEIEZvdW5kYXRpb24uCkZyZWVCU0QgMTQuMC1SRUxFQVNFICM0OiBT YXQgSmFuIDEzIDE1OjU0OjQwIEdNVCAyMDI0CiAgICByb290QGZyZWVic2QxNC1ycGk1Oi91c3Iv b2JqL3Vzci9zcmMvYXJtNjQuYWFyY2g2NC9zeXMvR0VORVJJQyBhcm02NApGcmVlQlNEIGNsYW5n IHZlcnNpb24gMTYuMC42IChodHRwczovL2dpdGh1Yi5jb20vbGx2bS9sbHZtLXByb2plY3QuZ2l0 IGxsdm1vcmctMTYuMC42LTAtZzdjYmYxYTI1OTE1MikKVlQ6IGluaXQgd2l0aG91dCBkcml2ZXIu ClByZWxvYWRlZCBlbGYga2VybmVsICIvYm9vdC9rZXJuZWwva2VybmVsIiBhdCAweGZmZmYwMDAw MDE4MjkwMDAuClByZWxvYWRlZCBlbGYgbW9kdWxlICIvYm9vdC9rZXJuZWwvemZzLmtvIiBhdCAw eGZmZmYwMDAwMDE4MzI2ZjAuClByZWxvYWRlZCBlbGYgbW9kdWxlICIvYm9vdC9rZXJuZWwvY3J5 cHRvZGV2LmtvIiBhdCAweGZmZmYwMDAwMDE4MzJmNDguClByZWxvYWRlZCBib290X2VudHJvcHlf Y2FjaGUgIi9ib290L2VudHJvcHkiIGF0IDB4ZmZmZjAwMDAwMTgzMzcyOC4KUHJlbG9hZGVkIGhv c3R1dWlkICIvZXRjL2hvc3RpZCIgYXQgMHhmZmZmMDAwMDAxODMzNzgwLgpQcmVsb2FkZWQgYm9v dF9lbnRyb3B5X3BsYXRmb3JtICJlZmlfcm5nX3NlZWQiIGF0IDB4ZmZmZjAwMDAwMTgzMzdkMC4K UHJlbG9hZGVkIFRTTE9HIGRhdGEgIlRTTE9HIiBhdCAweGZmZmYwMDAwMDE4MzM4MjguCm1vZHVs ZSBzY21pIGFscmVhZHkgcHJlc2VudCEKcmVhbCBtZW1vcnkgID0gODU4MzM4OTE4NCAoODE4NSBN QikKUGh5c2ljYWwgbWVtb3J5IGNodW5rKHMpOgoweDAwMDAwMDAwMjEwMDAwIC0gMHgwMDAwMDAz MDNmZmZmZiwgODA3MzM3OTg0IGJ5dGVzICgxOTcxMDQgcGFnZXMpCjB4MDAwMDAwMzFlNWYwMDAg LSAweDAwMDAwMDM4NDJmZmZmLCAxMDY3NjIyNDAgYnl0ZXMgKDI2MDY1IHBhZ2VzKQoweDAwMDAw MDM4NDgwMDAwIC0gMHgwMDAwMDAzODQ4MWZmZiwgODE5MiBieXRlcyAoMiBwYWdlcykKMHgwMDAw MDAzODc0MDAwMCAtIDB4MDAwMDAwM2JhMWZmZmYsIDUzMzQ2MzA0IGJ5dGVzICgxMzAyNCBwYWdl cykKMHgwMDAwMDAzYmFiMDAwMCAtIDB4MDAwMDAwM2JhYmZmZmYsIDY1NTM2IGJ5dGVzICgxNiBw YWdlcykKMHgwMDAwMDAzYmJlMDAwMCAtIDB4MDAwMDAwM2ZiZmZmZmYsIDY3MjM5OTM2IGJ5dGVz ICgxNjQxNiBwYWdlcykKMHgwMDAwMDA0MDAwMDAwMCAtIDB4MDAwMDAxZjM1MzJmZmYsIDczMDM1 NDA3MzYgYnl0ZXMgKDE3ODMwOTEgcGFnZXMpCmF2YWlsIG1lbW9yeSA9IDgzMzY2MDUxODQgKDc5 NTAgTUIpClN0YXJ0aW5nIENQVSAxICgxMDApClN0YXJ0aW5nIENQVSAyICgyMDApClN0YXJ0aW5n IENQVSAzICgzMDApCkZyZWVCU0QvU01QOiBNdWx0aXByb2Nlc3NvciBTeXN0ZW0gRGV0ZWN0ZWQ6 IDQgQ1BVcwpFbmFibGluZyBJREMgSUNhY2hlIHN5bmMKRW5hYmxpbmcgTFNFIGF0b21pY3MgaW4g dGhlIGtlcm5lbApyYW5kb206IHJlYWQgNDA5NiBieXRlcyBmcm9tIHByZWxvYWRlZCBjYWNoZQpy YW5kb206IHJlYWQgMjA0OCBieXRlcyBmcm9tIHBsYXRmb3JtIGJvb3Rsb2FkZXIKcmFuZG9tOiB1 bmJsb2NraW5nIGRldmljZS4KVklNQUdFICh2aXJ0dWFsaXplZCBuZXR3b3JrIHN0YWNrKSBlbmFi bGVkCmhvc3R1dWlkOiB1c2luZyAwMGQwNDE3MC0wMDAwLTAwMDAtNDE2ZC03N2I3YWExOTg4MzkK VUxFOiBzZXR1cCBjcHUgMApVTEU6IHNldHVwIGNwdSAxClVMRTogc2V0dXAgY3B1IDIKVUxFOiBz ZXR1cCBjcHUgMwpyYW5kb206IGVudHJvcHkgZGV2aWNlIGV4dGVybmFsIGludGVyZmFjZQpzbmRf dW5pdF9pbml0KCkgdT0weDAwZmY4MDAwIFs1MTJdIGQ9MHgwMDAwN2MwMCBbMzJdIGM9MHgwMDAw MDNmZiBbMTAyNF0KZmVlZGVyX3JlZ2lzdGVyOiBzbmRfdW5pdD0tMSBzbmRfbWF4YXV0b3ZjaGFu cz0xNiBsYXRlbmN5PTIgZmVlZGVyX3JhdGVfbWluPTEgZmVlZGVyX3JhdGVfbWF4PTIwMTYwMDAg ZmVlZGVyX3JhdGVfcm91bmQ9MjUKZmlybXdhcmU6ICd0ZWdyYTIxMF94dXNiX2Z3JyB2ZXJzaW9u IDA6IDEzMjYwOCBieXRlcyBsb2FkZWQgYXQgMHhmZmZmMDAwMDAwYWY5NTE4Ck1BUCAxZDAwMDAg bW9kZSAyIHBhZ2VzIDMyCk1BUCAzODQzMDAwMCBtb2RlIDIgcGFnZXMgODAKTUFQIDM4NGQwMDAw IG1vZGUgMiBwYWdlcyA2NApNQVAgMzg1MTAwMDAgbW9kZSAyIHBhZ2VzIDY0Ck1BUCAzODU1MDAw MCBtb2RlIDIgcGFnZXMgODAKTUFQIDM4NWEwMDAwIG1vZGUgMiBwYWdlcyAyMDgKTUFQIDM4Njgw MDAwIG1vZGUgMiBwYWdlcyAzMgpNQVAgMzg2YTAwMDAgbW9kZSAyIHBhZ2VzIDE2MApNQVAgM2Jh MjAwMDAgbW9kZSAyIHBhZ2VzIDE0NApNQVAgM2JhYzAwMDAgbW9kZSAyIHBhZ2VzIDI4OApNQVAg MTA3YzAxMzAwMCBtb2RlIDQgcGFnZXMgMQprYmQwIGF0IGtiZG11eDAKbWVtOiA8bWVtb3J5Pgpu dWxsOiA8ZnVsbCBkZXZpY2UsIG51bGwgZGV2aWNlLCB6ZXJvIGRldmljZT4Kb3BlbmZpcm06IDxP cGVuIEZpcm13YXJlIGNvbnRyb2wgZGV2aWNlPgp0Y3BfbG9nOiB0Y3BfbG9nIGRldmljZQpjcnlw dG86IDxjcnlwdG8gY29yZT4KQUNQSTogUlNEUCAweDAwMDAwMDAwMzg2NzAwMTggMDAwMDI0ICh2 MDIgUlBJRkROKQpBQ1BJOiBYU0RUIDB4MDAwMDAwMDAzODY3RkU5OCAwMDAwNTQgKHYwMSBSUElG RE4gUlBJNSAgICAgMDAwMDAyMDAgICAgICAwMTAwMDAxMykKQUNQSTogRkFDUCAweDAwMDAwMDAw Mzg2N0ZCOTggMDAwMTE0ICh2MDYgUlBJRkROIFJQSTUgICAgIDAwMDAwMjAwIEVESzIgMDAwMDAz MDApCkFDUEk6IERTRFQgMHgwMDAwMDAwMDM4NjdFQzE4IDAwMDg3NSAodjAyIFJQSUZETiBSUEk1 ICAgICAwMDAwMDAwMiBJTlRMIDIwMjAwOTI1KQpBQ1BJOiBEQkcyIDB4MDAwMDAwMDAzODY3RkE5 OCAwMDAwNjEgKHYwMCBSUElGRE4gUlBJNSAgICAgMDAwMDAyMDAgRURLMiAwMDAwMDMwMCkKQUNQ STogR1REVCAweDAwMDAwMDAwMzg2N0ZEMTggMDAwMDY4ICh2MDMgUlBJRkROIFJQSTUgICAgIDAw MDAwMjAwIEVESzIgMDAwMDAzMDApCkFDUEk6IEFQSUMgMHgwMDAwMDAwMDM4NjdFOTk4IDAwMDE4 NCAodjA1IFJQSUZETiBSUEk1ICAgICAwMDAwMDIwMCBFREsyIDAwMDAwMzAwKQpBQ1BJOiBQUFRU IDB4MDAwMDAwMDAzODY3RjY5OCAwMDAxMzAgKHYwMiBSUElGRE4gUlBJNSAgICAgMDAwMDAyMDAg RURLMiAwMDAwMDMwMCkKQUNQSTogU1BDUiAweDAwMDAwMDAwMzg2N0ZFMTggMDAwMDUwICh2MDIg UlBJRkROIFJQSTUgICAgIDAwMDAwMjAwIEVESzIgMDAwMDAzMDApCmFjcGkwOiA8UlBJRkROIFJQ STU+CkFDUEk6IDEgQUNQSSBBTUwgdGFibGVzIHN1Y2Nlc3NmdWxseSBhY3F1aXJlZCBhbmQgbG9h ZGVkCmFjcGkwOiBQb3dlciBCdXR0b24gKGZpeGVkKQphY3BpMDogQ291bGQgbm90IHVwZGF0ZSBh bGwgR1BFczogQUVfTk9UX0NPTkZJR1VSRUQKcHNjaTA6IDxBUk0gUG93ZXIgU3RhdGUgQ28tb3Jk aW5hdGlvbiBJbnRlcmZhY2UgRHJpdmVyPiBvbiBhY3BpMApwc2NpMDogUFNDSSB2ZXJzaW9uIDAu MiBjb21wYXRpYmxlCkZvdW5kIFNNQ0NDIHZlcnNpb24gMS4wCmdpYzA6IDxBUk0gR2VuZXJpYyBJ bnRlcnJ1cHQgQ29udHJvbGxlcj4gaW9tZW0gMHgxMDdmZmY5MDAwLTB4MTA3ZmZmOWZmZiwweDEw N2ZmZmEwMDAtMHgxMDdmZmZhZmZmIG9uIGFjcGkwCmdpYzA6IHBuIDB4MiwgYXJjaCAweDIsIHJl diAweDEsIGltcGxlbWVudGVyIDB4NDNiIGlycXMgMzIwCmdlbmVyaWNfdGltZXIwOiA8QVJNIEdl bmVyaWMgVGltZXI+IGlycSA1LDYsNyBvbiBhY3BpMApnZW5lcmljX3RpbWVyMDogYWxsb2NhdGVk IGlycSBmb3IgJ3NlYy1waHlzJwpnZW5lcmljX3RpbWVyMDogYWxsb2NhdGVkIGlycSBmb3IgJ3Bo eXMnCmdlbmVyaWNfdGltZXIwOiBhbGxvY2F0ZWQgaXJxIGZvciAndmlydCcKZ2VuZXJpY190aW1l cjA6IGNvdWxkIG5vdCBhbGxvY2F0ZSBpcnEgZm9yIG9wdGlvbmFsIGludGVycnVwdCAnaHlwLXBo eXMnCmdlbmVyaWNfdGltZXIwOiBjb3VsZCBub3QgYWxsb2NhdGUgaXJxIGZvciBvcHRpb25hbCBp bnRlcnJ1cHQgJ2h5cC12aXJ0JwpUaW1lY291bnRlciAiQVJNIE1QQ29yZSBUaW1lY291bnRlciIg ZnJlcXVlbmN5IDU0MDAwMDAwIEh6IHF1YWxpdHkgMTAwMApFdmVudCB0aW1lciAiQVJNIE1QQ29y ZSBFdmVudHRpbWVyIiBmcmVxdWVuY3kgNTQwMDAwMDAgSHogcXVhbGl0eSAxMDAwCmVmaXJ0YzA6 IDxFRkkgUmVhbHRpbWUgQ2xvY2s+CmVmaXJ0YzA6IHJlZ2lzdGVyZWQgYXMgYSB0aW1lLW9mLWRh eSBjbG9jaywgcmVzb2x1dGlvbiAxLjAwMDAwMHMKcmFtMDogcmVzZXJ2aW5nIG1lbW9yeSByZWdp b246ICAgMjEwMDAwLTMwNDAwMDAwCnJhbTA6IHJlc2VydmluZyBtZW1vcnkgcmVnaW9uOiAgIDMx ZTVmMDAwLTM4NDMwMDAwCnJhbTA6IHJlc2VydmluZyBtZW1vcnkgcmVnaW9uOiAgIDM4NDgwMDAw LTM4NDgyMDAwCnJhbTA6IHJlc2VydmluZyBtZW1vcnkgcmVnaW9uOiAgIDM4NzQwMDAwLTNiYTIw MDAwCnJhbTA6IHJlc2VydmluZyBtZW1vcnkgcmVnaW9uOiAgIDNiYWIwMDAwLTNiYWMwMDAwCnJh bTA6IHJlc2VydmluZyBtZW1vcnkgcmVnaW9uOiAgIDNiYmUwMDAwLTNmYzAwMDAwCnJhbTA6IHJl c2VydmluZyBtZW1vcnkgcmVnaW9uOiAgIDQwMDAwMDAwLTIwMDAwMDAwMApyYW0wOiByZXNlcnZp bmcgZXhjbHVkZWQgcmVnaW9uOiAxZDAwMDAtMWVmZmZmCnJhbTA6IHJlc2VydmluZyBleGNsdWRl ZCByZWdpb246IDMwNDAwMDAwLTMxZTVlZmZmCnJhbTA6IHJlc2VydmluZyBleGNsdWRlZCByZWdp b246IDM4NDMwMDAwLTM4NDdmZmZmCnJhbTA6IHJlc2VydmluZyBleGNsdWRlZCByZWdpb246IDM4 NGQwMDAwLTM4NzNmZmZmCnJhbTA6IHJlc2VydmluZyBleGNsdWRlZCByZWdpb246IDNiYTIwMDAw LTNiYWFmZmZmCnJhbTA6IHJlc2VydmluZyBleGNsdWRlZCByZWdpb246IDNiYWMwMDAwLTNiYmRm ZmZmCnBtdTA6IDxQZXJmb3JtYW5jZSBNb25pdG9yaW5nIFVuaXQ+IG9uIGFjcGkwCnBtdTA6IE1B RFQ6IGNwdSAwIChtcGlkciAwKSBpcnEgNDggbGV2ZWwtdHJpZ2dlcmVkCnBtdTA6IE1BRFQ6IGNw dSAxIChtcGlkciAyNTYpIGlycSA0OSBsZXZlbC10cmlnZ2VyZWQKcG11MDogTUFEVDogY3B1IDIg KG1waWRyIDUxMikgaXJxIDUwIGxldmVsLXRyaWdnZXJlZApwbXUwOiBNQURUOiBjcHUgMyAobXBp ZHIgNzY4KSBpcnEgNTEgbGV2ZWwtdHJpZ2dlcmVkCmNwdTA6IDxBQ1BJIENQVT4gb24gYWNwaTAK Y3B1MDogc3dpdGNoaW5nIHRvIGdlbmVyaWMgQ3ggbW9kZQpjcHUxOiA8QUNQSSBDUFU+IG9uIGFj cGkwCmNwdTI6IDxBQ1BJIENQVT4gb24gYWNwaTAKY3B1MzogPEFDUEkgQ1BVPiBvbiBhY3BpMAph Y3BpX3N5c2NvbnRhaW5lcjA6IDxTeXN0ZW0gQ29udGFpbmVyPiBvbiBhY3BpMAphY3BpX3N5c2Nv bnRhaW5lcjE6IDxTeXN0ZW0gQ29udGFpbmVyPiBvbiBhY3BpMApzZGhjaV9hY3BpMDogPEludGVs IEJheSBUcmFpbC9CcmFzd2VsbCBTRFhDIENvbnRyb2xsZXI+IGlvbWVtIDB4MTAwMGZmZjAwMC0w eDEwMDBmZmYyNWYgaXJxIDMgb24gYWNwaTAKc2RoY2lfYWNwaTAtc2xvdDA6IDIwME1IeiA0Yml0 cyBWREQ6IFZDQ1E6IDMuM1YgMS44ViBEUlY6IEJBQ0QgRE1BIHJlbW92YWJsZQpzZGhjaV9hY3Bp MC1zbG90MDogZU1NQzogSFMyMDAKc2RoY2lfYWNwaTAtc2xvdDA6IFVIUy1JOiBTRFIxMiBTRFIy NSBTRFI1MCBTRFIxMDQgRERSNTAKc2RoY2lfYWNwaTAtc2xvdDA6IFJlLXR1bmluZyBjb3VudCAw IHNlY3MsIG1vZGUgMwpzZGhjaV9hY3BpMC1zbG90MDogPT09PT09PT09PT09PT0gUkVHSVNURVIg RFVNUCA9PT09PT09PT09PT09PQpzZGhjaV9hY3BpMC1zbG90MDogU3lzIGFkZHI6IDB4MDAwMDAw MDAgfCBWZXJzaW9uOiAgMHgwMDAwMTAwMgpzZGhjaV9hY3BpMC1zbG90MDogQmxrIHNpemU6IDB4 MDAwMDAyMDAgfCBCbGsgY250OiAgMHgwMDAwMDAwMQpzZGhjaV9hY3BpMC1zbG90MDogQXJndW1l bnQ6IDB4MDQ0ODRiNTggfCBUcm4gbW9kZTogMHgwMDAwMDAxMQpzZGhjaV9hY3BpMC1zbG90MDog UHJlc2VudDogIDB4MWZmZjAwMDAgfCBIb3N0IGN0bDogMHgwMDAwMDAxYQpzZGhjaV9hY3BpMC1z bG90MDogUG93ZXI6ICAgIDB4MDAwMDAwMGYgfCBCbGsgZ2FwOiAgMHgwMDAwMDA4MApzZGhjaV9h Y3BpMC1zbG90MDogV2FrZS11cDogIDB4MDAwMDAwMDAgfCBDbG9jazogICAgMHgwMDAwMDAwNwpz ZGhjaV9hY3BpMC1zbG90MDogVGltZW91dDogIDB4MDAwMDAwMGUgfCBJbnQgc3RhdDogMHgwMDAw MDAwMApzZGhjaV9hY3BpMC1zbG90MDogSW50IGVuYWI6IDB4NzdmZjdmZmYgfCBTaWcgZW5hYjog MHgwMDAwMDAwMApzZGhjaV9hY3BpMC1zbG90MDogQUMxMiBlcnI6IDB4MDAwMDAwMDAgfCBIb3N0 IGN0bDI6MHgwMDAwMDA4YgpzZGhjaV9hY3BpMC1zbG90MDogQ2FwczogICAgIDB4MTVlYWM4MzIg fCBDYXBzMjogICAgMHg4MDAwYTU3NwpzZGhjaV9hY3BpMC1zbG90MDogTWF4IGN1cnI6IDB4MDAw ODAwMDggfCBBRE1BIGVycjogMHgwMDAwMDAwMApzZGhjaV9hY3BpMC1zbG90MDogQURNQSBhZGRy OjB4M2EzYjEwMGMgfCBTbG90IGludDogMHgwMDAwMDAwMApzZGhjaV9hY3BpMC1zbG90MDogPT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQpzZGhjaV9hY3BpMC1zbG90 MDogQ2FyZCBpbnNlcnRlZAptbWMwOiA8TU1DL1NEIGJ1cz4gb24gc2RoY2lfYWNwaTAKc2RoY2lf YWNwaTE6IDxJbnRlbCBCYXkgVHJhaWwvQnJhc3dlbGwgU0RYQyBDb250cm9sbGVyPiBpb21lbSAw eDEwMDExMDAwMDAtMHgxMDAxMTAwMjVmIGlycSA0IG9uIGFjcGkwCnNkaGNpX2FjcGkxLXNsb3Qw OiAyMDBNSHogOGJpdHMgVkREOiBWQ0NROiAzLjNWIDEuOFYgRFJWOiBCQyBETUEgZW1iZWRkZWQK c2RoY2lfYWNwaTEtc2xvdDA6IGVNTUM6IEhTMjAwCnNkaGNpX2FjcGkxLXNsb3QwOiBVSFMtSTog U0RSMTIgU0RSMjUgU0RSNTAgU0RSMTA0IEREUjUwCnNkaGNpX2FjcGkxLXNsb3QwOiBSZS10dW5p bmcgY291bnQgMCBzZWNzLCBtb2RlIDMKc2RoY2lfYWNwaTEtc2xvdDA6ID09PT09PT09PT09PT09 IFJFR0lTVEVSIERVTVAgPT09PT09PT09PT09PT0Kc2RoY2lfYWNwaTEtc2xvdDA6IFN5cyBhZGRy OiAweDAwMDAwMDAwIHwgVmVyc2lvbjogIDB4MDAwMDEwMDIKc2RoY2lfYWNwaTEtc2xvdDA6IEJs ayBzaXplOiAweDAwMDAwMDAwIHwgQmxrIGNudDogIDB4MDAwMDAwMDAKc2RoY2lfYWNwaTEtc2xv dDA6IEFyZ3VtZW50OiAweDAwMDAwMDAwIHwgVHJuIG1vZGU6IDB4MDAwMDAwMDAKc2RoY2lfYWNw aTEtc2xvdDA6IFByZXNlbnQ6ICAweDAxZmYwMDAwIHwgSG9zdCBjdGw6IDB4MDAwMDAwMDAKc2Ro Y2lfYWNwaTEtc2xvdDA6IFBvd2VyOiAgICAweDAwMDAwMDAwIHwgQmxrIGdhcDogIDB4MDAwMDAw ODAKc2RoY2lfYWNwaTEtc2xvdDA6IFdha2UtdXA6ICAweDAwMDAwMDAwIHwgQ2xvY2s6ICAgIDB4 MDAwMDAwMDAKc2RoY2lfYWNwaTEtc2xvdDA6IFRpbWVvdXQ6ICAweDAwMDAwMDAwIHwgSW50IHN0 YXQ6IDB4MDAwMDAwMDAKc2RoY2lfYWNwaTEtc2xvdDA6IEludCBlbmFiOiAweDAwMDAwMDAwIHwg U2lnIGVuYWI6IDB4MDAwMDAwMDAKc2RoY2lfYWNwaTEtc2xvdDA6IEFDMTIgZXJyOiAweDAwMDAw MDAwIHwgSG9zdCBjdGwyOjB4MDAwMDAwMDAKc2RoY2lfYWNwaTEtc2xvdDA6IENhcHM6ICAgICAw eDU1ZWVjODMyIHwgQ2FwczI6ICAgIDB4ODAwMGE1MjcKc2RoY2lfYWNwaTEtc2xvdDA6IE1heCBj dXJyOiAweDAwMDgwMDA4IHwgQURNQSBlcnI6IDB4MDAwMDAwMDAKc2RoY2lfYWNwaTEtc2xvdDA6 IEFETUEgYWRkcjoweDAwMDAwMDAwIHwgU2xvdCBpbnQ6IDB4MDAwMDAwMDAKc2RoY2lfYWNwaTEt c2xvdDA6ID09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0Kc2RoY2lf YWNwaTEtc2xvdDA6IENhcmQgaW5zZXJ0ZWQKbW1jMTogPE1NQy9TRCBidXM+IG9uIHNkaGNpX2Fj cGkxCnVhcnQwOiA8UHJpbWVDZWxsIFVBUlQgKFBMMDExKT4gaW9tZW0gMHgxMDdkMDAxMDAwLTB4 MTA3ZDAwMTFmZiBpcnEgMCBvbiBhY3BpMAp1YXJ0MDogY29uc29sZSAoMTE1MjAwLG4sOCwxKQp1 YXJ0MDogZmFzdCBpbnRlcnJ1cHQKdWFydDA6IFBQUyBjYXB0dXJlIG1vZGU6IERDRAp4aGNpMDog PEdlbmVyaWMgVVNCIDMuMCBjb250cm9sbGVyPiBpb21lbSAweDFmMDAyMDAwMDAtMHgxZjAwMmZm ZmZmIGlycSAxIG9uIGFjcGkwCnhoY2kwOiA2NCBieXRlcyBjb250ZXh0IHNpemUsIDY0LWJpdCBE TUEKdXNidXMwIG9uIHhoY2kwCnhoY2kwOiB1c2JwZjogQXR0YWNoZWQKeGhjaTE6IDxHZW5lcmlj IFVTQiAzLjAgY29udHJvbGxlcj4gaW9tZW0gMHgxZjAwMzAwMDAwLTB4MWYwMDNmZmZmZiBpcnEg MiBvbiBhY3BpMAp4aGNpMTogNjQgYnl0ZXMgY29udGV4dCBzaXplLCA2NC1iaXQgRE1BCnVzYnVz MSBvbiB4aGNpMQp4aGNpMTogdXNicGY6IEF0dGFjaGVkCmNyeXB0bzogYXNzaWduIGNyeXB0b3Nv ZnQwIGRyaXZlciBpZCAwLCBmbGFncyAweDYwMDAwMDAKYXJtdjhjcnlwdG8wOiA8QUVTLUNCQyxB RVMtWFRTLEFFUy1HQ00+CmNyeXB0bzogYXNzaWduIGFybXY4Y3J5cHRvMCBkcml2ZXIgaWQgMSwg ZmxhZ3MgMHhlMDAwMDAwCkFjcGlPc0V4ZWN1dGU6IHRhc2sgcXVldWUgbm90IHN0YXJ0ZWQKRGV2 aWNlIGNvbmZpZ3VyYXRpb24gZmluaXNoZWQuCnByb2NmcyByZWdpc3RlcmVkClRpbWVjb3VudGVy cyB0aWNrIGV2ZXJ5IDEuMDAwIG1zZWMKWkZTIGZpbGVzeXN0ZW0gdmVyc2lvbjogNQpaRlMgc3Rv cmFnZSBwb29sIHZlcnNpb246IGZlYXR1cmVzIHN1cHBvcnQgKDUwMDApCmxvMDogYnBmIGF0dGFj aGVkCnZsYW46IGluaXRpYWxpemVkLCB1c2luZyBoYXNoIHRhYmxlcyB3aXRoIGNoYWluaW5nCmNy eXB0bzogPGNyeXB0byBkZXZpY2U+CklQc2VjOiBJbml0aWFsaXplZCBTZWN1cml0eSBBc3NvY2lh dGlvbiBQcm9jZXNzaW5nLgp0Y3BfaW5pdDogbmV0LmluZXQudGNwLnRjYmhhc2hzaXplIGF1dG8g dHVuZWQgdG8gNjU1MzYKQWNwaU9zRXhlY3V0ZTogZW5xdWV1ZSAxIHBlbmRpbmcgdGFza3MKc2Ro Y2lfYWNwaTAtc2xvdDA6IERpdmlkZXIgMjUwIGZvciBmcmVxIDQwMDAwMCAoYmFzZSAyMDAwMDAw MDApCnNkaGNpX2FjcGkwLXNsb3QwOiBEaXZpZGVyIDI1MCBmb3IgZnJlcSA0MDAwMDAgKGJhc2Ug MjAwMDAwMDAwKQptbWMwOiBQcm9iaW5nIGJ1cwpzZGhjaV9hY3BpMC1zbG90MDogRGl2aWRlciAy NTAgZm9yIGZyZXEgNDAwMDAwIChiYXNlIDIwMDAwMDAwMCkKdXNidXMwOiA1LjBHYnBzIFN1cGVy IFNwZWVkIFVTQiB2My4wCnVzYnVzMTogNS4wR2JwcyBTdXBlciBTcGVlZCBVU0IgdjMuMApzZGhj aV9hY3BpMC1zbG90MDogRGl2aWRlciAyNTAgZm9yIGZyZXEgNDAwMDAwIChiYXNlIDIwMDAwMDAw MCkKdWdlbjAuMTogPEdlbmVyaWMgWEhDSSByb290IEhVQj4gYXQgdXNidXMwCnVodWIwIG9uIHVz YnVzMAp1aHViMDogPEdlbmVyaWMgWEhDSSByb290IEhVQiwgY2xhc3MgOS8wLCByZXYgMy4wMC8x LjAwLCBhZGRyIDE+IG9uIHVzYnVzMAp1Z2VuMS4xOiA8R2VuZXJpYyBYSENJIHJvb3QgSFVCPiBh dCB1c2J1czEKdWh1YjEgb24gdXNidXMxCnVodWIxOiA8R2VuZXJpYyBYSENJIHJvb3QgSFVCLCBj bGFzcyA5LzAsIHJldiAzLjAwLzEuMDAsIGFkZHIgMT4gb24gdXNidXMxCm1tYzA6IFNEIDIuMCBp bnRlcmZhY2UgY29uZGl0aW9uczogT0sKbW1jMDogU0QgcHJvYmU6IE9LIChPQ1I6IDB4MDBmZjgw MDApCnNkaGNpX2FjcGkwLXNsb3QwOiBEaXZpZGVyIDI1MCBmb3IgZnJlcSA0MDAwMDAgKGJhc2Ug MjAwMDAwMDAwKQpzZGhjaV9hY3BpMC1zbG90MDogRGl2aWRlciAyNTAgZm9yIGZyZXEgNDAwMDAw IChiYXNlIDIwMDAwMDAwMCkKbW1jMDogQ3VycmVudCBPQ1I6IDB4MDBmZjgwMDAKbW1jMDogUHJv YmluZyBjYXJkcwptbWMwOiBOZXcgY2FyZCBkZXRlY3RlZCAoQ0lEIFhYWFhYWFhYWFhYWFhYWFhY WFhYWFhYWFhYWFhYWFhYKQptbWMwOiBOZXcgY2FyZCBkZXRlY3RlZCAoQ1NEIFlZWVlZWVlZWVlZ WVlZWVlZWVlZWVlZWVlZWVlZWVlZKQptbWMwOiBDYXJkIGF0IHJlbGF0aXZlIGFkZHJlc3MgMHg1 MDQ4IGFkZGVkOgptbWMwOiAgY2FyZDogU0RIQyBTRDEyOCA4LjUgU04gWlpaWlpaWlogTUZHIDEw LzIwMjMgYnkgMyBTRAptbWMwOiAgcXVpcmtzOiAwCm1tYzA6ICBidXM6IDRiaXQsIDUwTUh6ICho aWdoIHNwZWVkIHRpbWluZykKbW1jMDogIG1lbW9yeTogMjQ5ODcyMzg0IGJsb2NrcywgZXJhc2Ug c2VjdG9yIDgxOTIgYmxvY2tzCnNkaGNpX2FjcGkwLXNsb3QwOiBEaXZpZGVyIDI1MCBmb3IgZnJl cSA0MDAwMDAgKGJhc2UgMjAwMDAwMDAwKQptbWMwOiBzZXR0aW5nIHRyYW5zZmVyIHJhdGUgdG8g NTAuMDAwTUh6IChoaWdoIHNwZWVkIHRpbWluZykKc2RoY2lfYWNwaTAtc2xvdDA6IERpdmlkZXIg MjUwIGZvciBmcmVxIDQwMDAwMCAoYmFzZSAyMDAwMDAwMDApCnNkaGNpX2FjcGkwLXNsb3QwOiBE aXZpZGVyIDIgZm9yIGZyZXEgNTAwMDAwMDAgKGJhc2UgMjAwMDAwMDAwKQpzZGhjaV9hY3BpMC1z bG90MDogRGl2aWRlciAyIGZvciBmcmVxIDUwMDAwMDAwIChiYXNlIDIwMDAwMDAwMCkKbW1jc2Qw OiAxMjhHQiA8U0RIQyBTRDEyOCA4LjUgU04gWlpaWlpaWlogTUZHIDEwLzIwMjMgYnkgMyBTRD4g YXQgbW1jMCA1MC4wTUh6LzRiaXQvNjU1MzUtYmxvY2sKc2RoY2lfYWNwaTEtc2xvdDA6IERpdmlk ZXIgMjUwIGZvciBmcmVxIDQwMDAwMCAoYmFzZSAyMDAwMDAwMDApCnNkaGNpX2FjcGkxLXNsb3Qw OiBEaXZpZGVyIDI1MCBmb3IgZnJlcSA0MDAwMDAgKGJhc2UgMjAwMDAwMDAwKQptbWMxOiBQcm9i aW5nIGJ1cwpzZGhjaV9hY3BpMS1zbG90MDogRGl2aWRlciAyNTAgZm9yIGZyZXEgNDAwMDAwIChi YXNlIDIwMDAwMDAwMCkKR0VPTTogbmV3IGRpc2sgbW1jc2QwCm1tYzA6IHNldHRpbmcgYnVzIHdp ZHRoIHRvIDQgYml0cyBoaWdoIHNwZWVkIHRpbWluZwpzZGhjaV9hY3BpMS1zbG90MDogRGl2aWRl ciAyNTAgZm9yIGZyZXEgNDAwMDAwIChiYXNlIDIwMDAwMDAwMCkKc2RoY2lfYWNwaTAtc2xvdDA6 IERpdmlkZXIgMiBmb3IgZnJlcSA1MDAwMDAwMCAoYmFzZSAyMDAwMDAwMDApCnNkaGNpX2FjcGkw LXNsb3QwOiBEaXZpZGVyIDIgZm9yIGZyZXEgNTAwMDAwMDAgKGJhc2UgMjAwMDAwMDAwKQptbWMx OiBTRCBwcm9iZTogZmFpbGVkCm1tYzE6IE1NQyBwcm9iZTogZmFpbGVkCm1tYzE6IEN1cnJlbnQg T0NSOiAweDAwMDAwMDAwCm1tYzE6IE5vIGNvbXBhdGlibGUgY2FyZHMgZm91bmQgb24gYnVzCkNQ VSAgMDogQVJNIENvcnRleC1BNzYgcjRwMSBhZmZpbml0eTogIDAgIDAKICAgICAgICAgICAgICAg ICAgIENhY2hlIFR5cGUgPSA8NjQgYnl0ZSBELWNhY2hlbGluZSw2NCBieXRlIEktY2FjaGVsaW5l LFBJUFQgSUNhY2hlLDY0IGJ5dGUgRVJHLDY0IGJ5dGUgQ1dHLElEQz4KIEluc3RydWN0aW9uIFNl dCBBdHRyaWJ1dGVzIDAgPSA8RFAsUkRNLEF0b21pYyxDUkMzMixTSEEyLFNIQTEsQUVTK1BNVUxM PgogSW5zdHJ1Y3Rpb24gU2V0IEF0dHJpYnV0ZXMgMSA9IDxSQ1BDLTguMyxEQ1BvUD4KIEluc3Ry dWN0aW9uIFNldCBBdHRyaWJ1dGVzIDIgPSA8PgogICAgICAgICBQcm9jZXNzb3IgRmVhdHVyZXMg MCA9IDxDU1YzLENTVjIsUkFTLEFkdlNJTUQrSFAsRlArSFAsRUwzLEVMMixFTDEsRUwwIDMyPgog ICAgICAgICBQcm9jZXNzb3IgRmVhdHVyZXMgMSA9IDxQU1RBVEUuU1NCUz4KICAgICAgTWVtb3J5 IE1vZGVsIEZlYXR1cmVzIDAgPSA8VEdyYW40LFRHcmFuNjQsVEdyYW4xNixTTlNNZW0sQmlnRW5k LDE2Yml0IEFTSUQsMVRCIFBBPgogICAgICBNZW1vcnkgTW9kZWwgRmVhdHVyZXMgMSA9IDxYTlgs UEFOK0FUUzFFMSxMTyxIUEQrVFRQQkhBLFZILDE2Yml0IFZNSUQsSEFGK0RTPgogICAgICBNZW1v cnkgTW9kZWwgRmVhdHVyZXMgMiA9IDwzMmJpdCBDQ0lEWCw0OGJpdCBWQSxJRVNCLFVBTyxDblA+ CiAgICAgICAgICAgICBEZWJ1ZyBGZWF0dXJlcyAwID0gPERvdWJsZUxvY2ssMiBDVFggQktQVHMs NCBXYXRjaHBvaW50cyw2IEJyZWFrcG9pbnRzLFBNVXYzcDEsRGVidWd2OHAyPgogICAgICAgICAg ICAgRGVidWcgRmVhdHVyZXMgMSA9IDw+CiAgICAgICAgIEF1eGlsaWFyeSBGZWF0dXJlcyAwID0g PD4KICAgICAgICAgQXV4aWxpYXJ5IEZlYXR1cmVzIDEgPSA8PgpBQXJjaDMyIEluc3RydWN0aW9u IFNldCBBdHRyaWJ1dGVzIDUgPSA8UkRNLENSQzMyLFNIQTIsU0hBMSxBRVMrVk1VTEwsU0VWTD4K QUFyY2gzMiBNZWRpYSBhbmQgVkZQIEZlYXR1cmVzIDAgPSA8RlBSb3VuZCxGUFNxcnQsRlBEaXZp ZGUsRFAgVkZQdjMrdjQsU1AgVkZQdjMrdjQsQWR2U0lNRD4KQUFyY2gzMiBNZWRpYSBhbmQgVkZQ IEZlYXR1cmVzIDEgPSA8U0lNREZNQUMsRlBIUCBBcml0aCxTSU1ESFAgQXJpdGgsU0lNRFNQLFNJ TURJbnQsU0lNRExTLEZQRE5hTixGUEZ0Wj4KIEwxIGNhY2hlOiA2NEtCIChpbnN0cnVjdGlvbiks IDY0S0IgKGRhdGEpCiBMMiBjYWNoZTogNTEyS0IgKHVuaWZpZWQpCiBMMyBjYWNoZTogMjA0OEtC ICh1bmlmaWVkKQpDUFUgIDE6IEFSTSBDb3J0ZXgtQTc2IHI0cDEgYWZmaW5pdHk6ICAxICAwCiBM MSBjYWNoZTogNjRLQiAoaW5zdHJ1Y3Rpb24pLCA2NEtCIChkYXRhKQogTDIgY2FjaGU6IDUxMktC ICh1bmlmaWVkKQogTDMgY2FjaGU6IDIwNDhLQiAodW5pZmllZCkKQ1BVICAyOiBBUk0gQ29ydGV4 LUE3NiByNHAxIGFmZmluaXR5OiAgMiAgMAogTDEgY2FjaGU6IDY0S0IgKGluc3RydWN0aW9uKSwg NjRLQiAoZGF0YSkKIEwyIGNhY2hlOiA1MTJLQiAodW5pZmllZCkKIEwzIGNhY2hlOiAyMDQ4S0Ig KHVuaWZpZWQpCkNQVSAgMzogQVJNIENvcnRleC1BNzYgcjRwMSBhZmZpbml0eTogIDMgIDAKIEwx IGNhY2hlOiA2NEtCIChpbnN0cnVjdGlvbiksIDY0S0IgKGRhdGEpCiBMMiBjYWNoZTogNTEyS0Ig KHVuaWZpZWQpCiBMMyBjYWNoZTogMjA0OEtCICh1bmlmaWVkKQpSZWxlYXNlIEFQcy4uLmRvbmUK RW5hYmxpbmcgQ25QClRDUF9yYXRlbGltaXQ6IElzIG5vdyBpbml0aWFsaXplZApUcnlpbmcgdG8g bW91bnQgcm9vdCBmcm9tIHpmczp6cm9vdC9ST09UL2RlZmF1bHQgW10uLi4KcmVndWxhdG9yOiBz aHV0dGluZyBkb3duIHVudXNlZCByZWd1bGF0b3JzCkdFT01fUEFSVDogcGFydGl0aW9uIDEgb24g KG1tY3NkMCwgR1BUKSBpcyBub3QgYWxpZ25lZCBvbiA0MTk0MzA0IGJ5dGVzCkdFT01fUEFSVDog cGFydGl0aW9uIDIgb24gKG1tY3NkMCwgR1BUKSBpcyBub3QgYWxpZ25lZCBvbiA0MTk0MzA0IGJ5 dGVzCkdFT01fUEFSVDogcGFydGl0aW9uIDMgb24gKG1tY3NkMCwgR1BUKSBpcyBub3QgYWxpZ25l ZCBvbiA0MTk0MzA0IGJ5dGVzCnVodWIwOiAzIHBvcnRzIHdpdGggMyByZW1vdmFibGUsIHNlbGYg cG93ZXJlZAp1aHViMTogMyBwb3J0cyB3aXRoIDMgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKZWZp cnRjMDogcHJvdmlkaW5nIGluaXRpYWwgc3lzdGVtIHRpbWUKc3RhcnRfaW5pdDogdHJ5aW5nIC9z YmluL2luaXQKbG8wOiBsaW5rIHN0YXRlIGNoYW5nZWQgdG8gVVAK --0000000000001e2b12060ee8371c Content-Type: application/octet-stream; name=dmesg-devicetree-only Content-Disposition: attachment; filename=dmesg-devicetree-only Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_lrdk2xii1 LS0tPDxCT09UPj4tLS0KV0FSTklORzogQ2Fubm90IGZpbmQgZnJlZWJzZCxkdHMtdmVyc2lvbiBw cm9wZXJ0eSwgY2Fubm90IGNoZWNrIERUQiBjb21wbGlhbmNlCiAgICAgICAgICAgICAgICAgICBU eXBlICAgICBQaHlzaWNhbCAgICAgIFZpcnR1YWwgICAjUGFnZXMgQXR0cgogICAgICAgICAgICAg ICBSZXNlcnZlZCAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwIDAwMDAwMWQwIFdDIFdUIFdCIAog ICAgUnVudGltZVNlcnZpY2VzRGF0YSAwMDAwMDAxZDAwMDAgMDAwMDAwMWQwMDAwIDAwMDAwMDIw IFdDIFdUIFdCIFJVTlRJTUUKICAgICAgICAgICAgICAgUmVzZXJ2ZWQgMDAwMDAwMWYwMDAwIDAw MDAwMDAwMDAwMCAwMDAwMDAyMCBXQyBXVCBXQiAKICAgICBDb252ZW50aW9uYWxNZW1vcnkgMDAw MDAwMjEwMDAwIDAwMDAwMDAwMDAwMCAwMDAzMDE0ZSBXQyBXVCBXQiAKICAgICAgICAgICAgIExv YWRlckNvZGUgMDAwMDMwMzVlMDAwIDAwMDAwMDAwMDAwMCAwMDAwNDAwMCBXQyBXVCBXQiAKICAg ICAgICAgICAgIExvYWRlckRhdGEgMDAwMDM0MzVlMDAwIDAwMDAwMDAwMDAwMCAwMDAwNDAwMCBX QyBXVCBXQiAKICAgICAgICAgICAgIExvYWRlckNvZGUgMDAwMDM4MzVlMDAwIDAwMDAwMDAwMDAw MCAwMDAwMDBkMiBXQyBXVCBXQiAKICAgIFJ1bnRpbWVTZXJ2aWNlc0RhdGEgMDAwMDM4NDMwMDAw IDAwMDAzODQzMDAwMCAwMDAwMDA1MCBXQyBXVCBXQiBSVU5USU1FCiAgICAgQ29udmVudGlvbmFs TWVtb3J5IDAwMDAzODQ4MDAwMCAwMDAwMDAwMDAwMDAgMDAwMDAwMDIgV0MgV1QgV0IgCiAgICAg ICAgICAgICAgIFJlc2VydmVkIDAwMDAzODQ4MjAwMCAwMDAwMDAwMDAwMDAgMDAwMDAwNGUgV0Mg V1QgV0IgCiAgICBSdW50aW1lU2VydmljZXNEYXRhIDAwMDAzODRkMDAwMCAwMDAwMzg0ZDAwMDAg MDAwMDAwNDAgV0MgV1QgV0IgUlVOVElNRQogICAgUnVudGltZVNlcnZpY2VzQ29kZSAwMDAwMzg1 MTAwMDAgMDAwMDM4NTEwMDAwIDAwMDAwMDQwIFdDIFdUIFdCIFJVTlRJTUUKICAgIFJ1bnRpbWVT ZXJ2aWNlc0RhdGEgMDAwMDM4NTUwMDAwIDAwMDAzODU1MDAwMCAwMDAwMDA1MCBXQyBXVCBXQiBS VU5USU1FCiAgICBSdW50aW1lU2VydmljZXNDb2RlIDAwMDAzODVhMDAwMCAwMDAwMzg1YTAwMDAg MDAwMDAwZDAgV0MgV1QgV0IgUlVOVElNRQogICAgICBBQ1BJUmVjbGFpbU1lbW9yeSAwMDAwMzg2 NzAwMDAgMDAwMDAwMDAwMDAwIDAwMDAwMDEwIFdDIFdUIFdCIAogICAgUnVudGltZVNlcnZpY2Vz RGF0YSAwMDAwMzg2ODAwMDAgMDAwMDM4NjgwMDAwIDAwMDAwMDIwIFdDIFdUIFdCIFJVTlRJTUUK ICAgIFJ1bnRpbWVTZXJ2aWNlc0NvZGUgMDAwMDM4NmEwMDAwIDAwMDAzODZhMDAwMCAwMDAwMDBh MCBXQyBXVCBXQiBSVU5USU1FCiAgICAgQ29udmVudGlvbmFsTWVtb3J5IDAwMDAzODc0MDAwMCAw MDAwMDAwMDAwMDAgMDAwMDAwMDMgV0MgV1QgV0IgCiAgICAgICAgICAgICBMb2FkZXJEYXRhIDAw MDAzODc0MzAwMCAwMDAwMDAwMDAwMDAgMDAwMDAwMDEgV0MgV1QgV0IgCiAgICAgQ29udmVudGlv bmFsTWVtb3J5IDAwMDAzODc0NDAwMCAwMDAwMDAwMDAwMDAgMDAwMDFjNzkgV0MgV1QgV0IgCiAg ICAgICBCb290U2VydmljZXNEYXRhIDAwMDAzYTNiZDAwMCAwMDAwMDAwMDAwMDAgMDAwMDAwMGIg V0MgV1QgV0IgCiAgICAgQ29udmVudGlvbmFsTWVtb3J5IDAwMDAzYTNjODAwMCAwMDAwMDAwMDAw MDAgMDAwMDAwMDEgV0MgV1QgV0IgCiAgICAgICBCb290U2VydmljZXNEYXRhIDAwMDAzYTNjOTAw MCAwMDAwMDAwMDAwMDAgMDAwMDEyNmYgV0MgV1QgV0IgCiAgICAgQ29udmVudGlvbmFsTWVtb3J5 IDAwMDAzYjYzODAwMCAwMDAwMDAwMDAwMDAgMDAwMDAwNTAgV0MgV1QgV0IgCiAgICAgICBCb290 U2VydmljZXNDb2RlIDAwMDAzYjY4ODAwMCAwMDAwMDAwMDAwMDAgMDAwMDAzOTggV0MgV1QgV0Ig CiAgICBSdW50aW1lU2VydmljZXNDb2RlIDAwMDAzYmEyMDAwMCAwMDAwM2JhMjAwMDAgMDAwMDAw OTAgV0MgV1QgV0IgUlVOVElNRQogICAgIENvbnZlbnRpb25hbE1lbW9yeSAwMDAwM2JhYjAwMDAg MDAwMDAwMDAwMDAwIDAwMDAwMDEwIFdDIFdUIFdCIAogICAgUnVudGltZVNlcnZpY2VzRGF0YSAw MDAwM2JhYzAwMDAgMDAwMDNiYWMwMDAwIDAwMDAwMTIwIFdDIFdUIFdCIFJVTlRJTUUKICAgICBD b252ZW50aW9uYWxNZW1vcnkgMDAwMDNiYmUwMDAwIDAwMDAwMDAwMDAwMCAwMDAwMDAxZiBXQyBX VCBXQiAKICAgICAgIEJvb3RTZXJ2aWNlc0RhdGEgMDAwMDNiYmZmMDAwIDAwMDAwMDAwMDAwMCAw MDAwMDAwMSBXQyBXVCBXQiAKICAgICBDb252ZW50aW9uYWxNZW1vcnkgMDAwMDNiYzAwMDAwIDAw MDAwMDAwMDAwMCAwMDAwMzI1MCBXQyBXVCBXQiAKICAgICAgIEJvb3RTZXJ2aWNlc0NvZGUgMDAw MDNlZTUwMDAwIDAwMDAwMDAwMDAwMCAwMDAwMDAzOCBXQyBXVCBXQiAKICAgICAgIEJvb3RTZXJ2 aWNlc0RhdGEgMDAwMDNlZTg4MDAwIDAwMDAwMDAwMDAwMCAwMDAwMGQ3OCBXQyBXVCBXQiAKICAg ICBDb252ZW50aW9uYWxNZW1vcnkgMDAwMDQwMDAwMDAwIDAwMDAwMDAwMDAwMCAwMDFjMDAwMCBX QyBXVCBXQiAKICAgICAgICAgTWVtb3J5TWFwcGVkSU8gMDAxMDdjMDEzMDAwIDAwMTA3YzAxMzAw MCAwMDAwMDAwMSBVQyBSVU5USU1FClBoeXNpY2FsIG1lbW9yeSBjaHVuayhzKToKICAweDAwMWQw MDAwIC0gMHgwMDFlZmZmZiwgICAgIDAgTUIgKCAgICAgMzIgcGFnZXMpCiAgMHgwMDIxMDAwMCAt IDB4Mzg0ODFmZmYsICAgODk4IE1CICggMjMwMDAyIHBhZ2VzKQogIDB4Mzg0ZDAwMDAgLSAweDNm YmZmZmZmLCAgIDExOSBNQiAoICAzMDUxMiBwYWdlcykKICAweDQwMDAwMDAwIC0gMHgxZmZmZmZm ZmYsICA3MTY4IE1CICgxODM1MDA4IHBhZ2VzKQpFeGNsdWRlZCBtZW1vcnkgcmVnaW9uczoKICAw eDAwMDAwMDAwIC0gMHgwMDA3ZmZmZiwgICAgIDAgTUIgKCAgICAxMjggcGFnZXMpIE5vQWxsb2Mg Tm9EdW1wCiAgMHgwMDFkMDAwMCAtIDB4MDAxZWZmZmYsICAgICAwIE1CICggICAgIDMyIHBhZ2Vz KSBOb0FsbG9jIAogIDB4MzA0MDAwMDAgLSAweDMxZTczZmZmLCAgICAyNiBNQiAoICAgNjc3MiBw YWdlcykgTm9BbGxvYyAKICAweDM4NDMwMDAwIC0gMHgzODQ3ZmZmZiwgICAgIDAgTUIgKCAgICAg ODAgcGFnZXMpIE5vQWxsb2MgCiAgMHgzODRkMDAwMCAtIDB4Mzg3M2ZmZmYsICAgICAyIE1CICgg ICAgNjI0IHBhZ2VzKSBOb0FsbG9jIAogIDB4M2JhMjAwMDAgLSAweDNiYWFmZmZmLCAgICAgMCBN QiAoICAgIDE0NCBwYWdlcykgTm9BbGxvYyAKICAweDNiYWMwMDAwIC0gMHgzYmJkZmZmZiwgICAg IDEgTUIgKCAgICAyODggcGFnZXMpIE5vQWxsb2MgCiAgMHgzZmQxNjAwMCAtIDB4M2ZkMTZmZmYs ICAgICAwIE1CICggICAgICAxIHBhZ2VzKSBOb0FsbG9jIE5vRHVtcApGb3VuZCA0IENQVXMgaW4g dGhlIGRldmljZSB0cmVlCkNvcHlyaWdodCAoYykgMTk5Mi0yMDIzIFRoZSBGcmVlQlNEIFByb2pl Y3QuCkNvcHlyaWdodCAoYykgMTk3OSwgMTk4MCwgMTk4MywgMTk4NiwgMTk4OCwgMTk4OSwgMTk5 MSwgMTk5MiwgMTk5MywgMTk5NAoJVGhlIFJlZ2VudHMgb2YgdGhlIFVuaXZlcnNpdHkgb2YgQ2Fs aWZvcm5pYS4gQWxsIHJpZ2h0cyByZXNlcnZlZC4KRnJlZUJTRCBpcyBhIHJlZ2lzdGVyZWQgdHJh ZGVtYXJrIG9mIFRoZSBGcmVlQlNEIEZvdW5kYXRpb24uCkZyZWVCU0QgMTQuMC1SRUxFQVNFICM0 OiBTYXQgSmFuIDEzIDE1OjU0OjQwIEdNVCAyMDI0CiAgICByb290QGZyZWVic2QxNC1ycGk1Oi91 c3Ivb2JqL3Vzci9zcmMvYXJtNjQuYWFyY2g2NC9zeXMvR0VORVJJQyBhcm02NApGcmVlQlNEIGNs YW5nIHZlcnNpb24gMTYuMC42IChodHRwczovL2dpdGh1Yi5jb20vbGx2bS9sbHZtLXByb2plY3Qu Z2l0IGxsdm1vcmctMTYuMC42LTAtZzdjYmYxYTI1OTE1MikKVlQ6IGluaXQgd2l0aG91dCBkcml2 ZXIuClByZWxvYWRlZCBlbGYga2VybmVsICIvYm9vdC9rZXJuZWwva2VybmVsIiBhdCAweGZmZmYw MDAwMDE4M2UwMDAuClByZWxvYWRlZCBlbGYgbW9kdWxlICIvYm9vdC9rZXJuZWwvemZzLmtvIiBh dCAweGZmZmYwMDAwMDE4NDc1ODAuClByZWxvYWRlZCBib290X2VudHJvcHlfY2FjaGUgIi9ib290 L2VudHJvcHkiIGF0IDB4ZmZmZjAwMDAwMTg0N2RkOC4KUHJlbG9hZGVkIGVsZiBtb2R1bGUgIi9i b290L2tlcm5lbC9jcnlwdG9kZXYua28iIGF0IDB4ZmZmZjAwMDAwMTg0N2UzMC4KUHJlbG9hZGVk IGhvc3R1dWlkICIvZXRjL2hvc3RpZCIgYXQgMHhmZmZmMDAwMDAxODQ4NjEwLgpQcmVsb2FkZWQg Ym9vdF9lbnRyb3B5X3BsYXRmb3JtICJlZmlfcm5nX3NlZWQiIGF0IDB4ZmZmZjAwMDAwMTg0ODY2 MC4KUHJlbG9hZGVkIFRTTE9HIGRhdGEgIlRTTE9HIiBhdCAweGZmZmYwMDAwMDE4NDg2YjguCm1v ZHVsZSBzY21pIGFscmVhZHkgcHJlc2VudCEKcmVhbCBtZW1vcnkgID0gODU4MzM4OTE4NCAoODE4 NSBNQikKUGh5c2ljYWwgbWVtb3J5IGNodW5rKHMpOgoweDAwMDAwMDAwMjEwMDAwIC0gMHgwMDAw MDAzMDNmZmZmZiwgODA3MzM3OTg0IGJ5dGVzICgxOTcxMDQgcGFnZXMpCjB4MDAwMDAwMzFlNzQw MDAgLSAweDAwMDAwMDM4NDJmZmZmLCAxMDY2NzYyMjQgYnl0ZXMgKDI2MDQ0IHBhZ2VzKQoweDAw MDAwMDM4NDgwMDAwIC0gMHgwMDAwMDAzODQ4MWZmZiwgODE5MiBieXRlcyAoMiBwYWdlcykKMHgw MDAwMDAzODc0MDAwMCAtIDB4MDAwMDAwM2JhMWZmZmYsIDUzMzQ2MzA0IGJ5dGVzICgxMzAyNCBw YWdlcykKMHgwMDAwMDAzYmFiMDAwMCAtIDB4MDAwMDAwM2JhYmZmZmYsIDY1NTM2IGJ5dGVzICgx NiBwYWdlcykKMHgwMDAwMDAzYmJlMDAwMCAtIDB4MDAwMDAwM2ZiZmZmZmYsIDY3MjM5OTM2IGJ5 dGVzICgxNjQxNiBwYWdlcykKMHgwMDAwMDA0MDAwMDAwMCAtIDB4MDAwMDAxZjM1MzNmZmYsIDcz MDM1NDQ4MzIgYnl0ZXMgKDE3ODMwOTIgcGFnZXMpCmF2YWlsIG1lbW9yeSA9IDgzMzY1MTUwNzIg KDc5NTAgTUIpClN0YXJ0aW5nIENQVSAxICgxMDApClN0YXJ0aW5nIENQVSAyICgyMDApClN0YXJ0 aW5nIENQVSAzICgzMDApCkZyZWVCU0QvU01QOiBNdWx0aXByb2Nlc3NvciBTeXN0ZW0gRGV0ZWN0 ZWQ6IDQgQ1BVcwpFbmFibGluZyBJREMgSUNhY2hlIHN5bmMKRW5hYmxpbmcgTFNFIGF0b21pY3Mg aW4gdGhlIGtlcm5lbApyYW5kb206IHJlYWQgNDA5NiBieXRlcyBmcm9tIHByZWxvYWRlZCBjYWNo ZQpyYW5kb206IHJlYWQgMjA0OCBieXRlcyBmcm9tIHBsYXRmb3JtIGJvb3Rsb2FkZXIKcmFuZG9t OiB1bmJsb2NraW5nIGRldmljZS4KVklNQUdFICh2aXJ0dWFsaXplZCBuZXR3b3JrIHN0YWNrKSBl bmFibGVkCmhvc3R1dWlkOiB1c2luZyAwMGQwNDE3MC0wMDAwLTAwMDAtNDE2ZC03N2I3YWExOTg4 MzkKVUxFOiBzZXR1cCBjcHUgMApVTEU6IHNldHVwIGNwdSAxClVMRTogc2V0dXAgY3B1IDIKVUxF OiBzZXR1cCBjcHUgMwpyYW5kb206IGVudHJvcHkgZGV2aWNlIGV4dGVybmFsIGludGVyZmFjZQpz bmRfdW5pdF9pbml0KCkgdT0weDAwZmY4MDAwIFs1MTJdIGQ9MHgwMDAwN2MwMCBbMzJdIGM9MHgw MDAwMDNmZiBbMTAyNF0KZmVlZGVyX3JlZ2lzdGVyOiBzbmRfdW5pdD0tMSBzbmRfbWF4YXV0b3Zj aGFucz0xNiBsYXRlbmN5PTIgZmVlZGVyX3JhdGVfbWluPTEgZmVlZGVyX3JhdGVfbWF4PTIwMTYw MDAgZmVlZGVyX3JhdGVfcm91bmQ9MjUKZmlybXdhcmU6ICd0ZWdyYTIxMF94dXNiX2Z3JyB2ZXJz aW9uIDA6IDEzMjYwOCBieXRlcyBsb2FkZWQgYXQgMHhmZmZmMDAwMDAwYWY5NTE4Ck1BUCAxZDAw MDAgbW9kZSAyIHBhZ2VzIDMyCk1BUCAzODQzMDAwMCBtb2RlIDIgcGFnZXMgODAKTUFQIDM4NGQw MDAwIG1vZGUgMiBwYWdlcyA2NApNQVAgMzg1MTAwMDAgbW9kZSAyIHBhZ2VzIDY0Ck1BUCAzODU1 MDAwMCBtb2RlIDIgcGFnZXMgODAKTUFQIDM4NWEwMDAwIG1vZGUgMiBwYWdlcyAyMDgKTUFQIDM4 NjgwMDAwIG1vZGUgMiBwYWdlcyAzMgpNQVAgMzg2YTAwMDAgbW9kZSAyIHBhZ2VzIDE2MApNQVAg M2JhMjAwMDAgbW9kZSAyIHBhZ2VzIDE0NApNQVAgM2JhYzAwMDAgbW9kZSAyIHBhZ2VzIDI4OApN QVAgMTA3YzAxMzAwMCBtb2RlIDQgcGFnZXMgMQprYmQwIGF0IGtiZG11eDAKbWVtOiA8bWVtb3J5 PgpudWxsOiA8ZnVsbCBkZXZpY2UsIG51bGwgZGV2aWNlLCB6ZXJvIGRldmljZT4Kb3BlbmZpcm06 IDxPcGVuIEZpcm13YXJlIGNvbnRyb2wgZGV2aWNlPgp0Y3BfbG9nOiB0Y3BfbG9nIGRldmljZQpj cnlwdG86IDxjcnlwdG8gY29yZT4Kb2Z3YnVzMDogPE9wZW4gRmlybXdhcmUgRGV2aWNlIFRyZWU+ CmNsa19maXhlZDA6IDxGaXhlZCBjbG9jaz4gb24gb2Z3YnVzMApjbGtfZml4ZWQxOiA8Rml4ZWQg Y2xvY2s+IG9uIG9md2J1czAKc2ltcGxlYnVzMDogPEZsYXR0ZW5lZCBkZXZpY2UgdHJlZSBzaW1w bGUgYnVzPiBvbiBvZndidXMwCnJlZ2ZpeDA6IDxGaXhlZCBSZWd1bGF0b3I+IG9uIHNpbXBsZWJ1 czAKcmVnZml4MTogPEZpeGVkIFJlZ3VsYXRvcj4gb24gc2ltcGxlYnVzMApzaW1wbGVidXMxOiA8 RmxhdHRlbmVkIGRldmljZSB0cmVlIHNpbXBsZSBidXM+IG9uIG9md2J1czAKc2ltcGxlYnVzMTog TWFsZm9ybWVkIHJlZyBwcm9wZXJ0eSBvbiA8dmNfbWVtPgpvZndfY2xrYnVzMDogPE9GVyBjbG9j a3MgYnVzPiBvbiBvZndidXMwCmNsa19maXhlZDI6IDxGaXhlZCBjbG9jaz4gb24gb2Z3X2Nsa2J1 czAKY2xrX2ZpeGVkMzogPEZpeGVkIGNsb2NrPiBvbiBvZndfY2xrYnVzMApjbGtfZml4ZWQ0OiA8 Rml4ZWQgY2xvY2s+IG9uIG9md19jbGtidXMwCmNsa19maXhlZDU6IDxGaXhlZCBjbG9jaz4gb24g b2Z3X2Nsa2J1czAKY2xrX2ZpeGVkNjogPEZpeGVkIGNsb2NrPiBvbiBvZndfY2xrYnVzMApjbGtf Zml4ZWQ3OiA8Rml4ZWQgY2xvY2s+IG9uIG9md19jbGtidXMwCmNsa19maXhlZDg6IDxGaXhlZCBj bG9jaz4gb24gb2Z3X2Nsa2J1czAKY2xrX2ZpeGVkOTogPEZpeGVkIGNsb2NrPiBvbiBvZndfY2xr YnVzMApjbGtfZml4ZWQxMDogPEZpeGVkIGNsb2NrPiBvbiBvZndfY2xrYnVzMApjbGtfZml4ZWQx MTogPEZpeGVkIGNsb2NrPiBvbiBvZndfY2xrYnVzMApjbGtfZml4ZWQxMjogPEZpeGVkIGNsb2Nr PiBvbiBvZndfY2xrYnVzMApjbGtfZml4ZWQxMzogPEZpeGVkIGNsb2NrPiBvbiBvZndfY2xrYnVz MApyZWdmaXgyOiA8Rml4ZWQgUmVndWxhdG9yPiBvbiBvZndidXMwCnJlZ2ZpeDM6IDxGaXhlZCBS ZWd1bGF0b3I+IG9uIG9md2J1czAKY2xrX2ZpeGVkMTQ6IGNsb2NrLWZpeGVkIGhhcyBubyBjbG9j ay1mcmVxdWVuY3kKY2xrX2ZpeGVkMTQ6IGNsb2NrLWZpeGVkIGhhcyBubyBjbG9jay1mcmVxdWVu Y3kKcmVnZml4NDogPEZpeGVkIFJlZ3VsYXRvcj4gb24gb2Z3YnVzMApyZWdmaXg1OiA8Rml4ZWQg UmVndWxhdG9yPiBvbiBvZndidXMwCnJlZ2ZpeDY6IDxGaXhlZCBSZWd1bGF0b3I+IG9uIG9md2J1 czAKcmVnZml4NzogPEZpeGVkIFJlZ3VsYXRvcj4gb24gb2Z3YnVzMApzaW1wbGVfbWZkMDogPFNp bXBsZSBNRkQgKE11bHRpLUZ1bmN0aW9ucyBEZXZpY2UpPiBtZW0gMHg3ZDU0MjAwMC0weDdkNTQy ZWZmIG9uIHNpbXBsZWJ1czAKYmNtMjgzNV9maXJtd2FyZTA6IDxCQ00yODM1IEZpcm13YXJlPiBv biBzaW1wbGVidXMwCm9md19jbGtidXMxOiA8T0ZXIGNsb2NrcyBidXM+IG9uIGJjbTI4MzVfZmly bXdhcmUwCnNpbXBsZV9tZmQxOiA8U2ltcGxlIE1GRCAoTXVsdGktRnVuY3Rpb25zIERldmljZSk+ IG1lbSAweDEwMDA0MDAwMTgtMHgxMDAwNDAwMDJmIG9uIHNpbXBsZWJ1czEKY2xrX2ZpeGVkMTQ6 IGNsb2NrLWZpeGVkIGhhcyBubyBjbG9jay1mcmVxdWVuY3kKY2xrX2ZpeGVkMTQ6IGNsb2NrLWZp eGVkIGhhcyBubyBjbG9jay1mcmVxdWVuY3kKcHNjaTA6IDxBUk0gUG93ZXIgU3RhdGUgQ28tb3Jk aW5hdGlvbiBJbnRlcmZhY2UgRHJpdmVyPiBvbiBvZndidXMwCnBzY2kwOiBQU0NJIHZlcnNpb24g MC4yIGNvbXBhdGlibGUKRm91bmQgU01DQ0MgdmVyc2lvbiAxLjAKY2xrX2ZpeGVkMTQ6IGNsb2Nr LWZpeGVkIGhhcyBubyBjbG9jay1mcmVxdWVuY3kKY2xrX2ZpeGVkMTQ6IGNsb2NrLWZpeGVkIGhh cyBubyBjbG9jay1mcmVxdWVuY3kKY2xrX2ZpeGVkMTQ6IGNsb2NrLWZpeGVkIGhhcyBubyBjbG9j ay1mcmVxdWVuY3kKY2xrX2ZpeGVkMTQ6IGNsb2NrLWZpeGVkIGhhcyBubyBjbG9jay1mcmVxdWVu Y3kKY2xrX2ZpeGVkMTQ6IGNsb2NrLWZpeGVkIGhhcyBubyBjbG9jay1mcmVxdWVuY3kKY2xrX2Zp eGVkMTQ6IGNsb2NrLWZpeGVkIGhhcyBubyBjbG9jay1mcmVxdWVuY3kKY2xrX2ZpeGVkMTQ6IGNs b2NrLWZpeGVkIGhhcyBubyBjbG9jay1mcmVxdWVuY3kKY2xrX2ZpeGVkMTQ6IGNsb2NrLWZpeGVk IGhhcyBubyBjbG9jay1mcmVxdWVuY3kKY2xrX2ZpeGVkMTQ6IGNsb2NrLWZpeGVkIGhhcyBubyBj bG9jay1mcmVxdWVuY3kKY2xrX2ZpeGVkMTQ6IGNsb2NrLWZpeGVkIGhhcyBubyBjbG9jay1mcmVx dWVuY3kKY2xrX2ZpeGVkMTQ6IGNsb2NrLWZpeGVkIGhhcyBubyBjbG9jay1mcmVxdWVuY3kKY2xr X2ZpeGVkMTQ6IGNsb2NrLWZpeGVkIGhhcyBubyBjbG9jay1mcmVxdWVuY3kKY2xrX2ZpeGVkMTQ6 IGNsb2NrLWZpeGVkIGhhcyBubyBjbG9jay1mcmVxdWVuY3kKY2xrX2ZpeGVkMTQ6IGNsb2NrLWZp eGVkIGhhcyBubyBjbG9jay1mcmVxdWVuY3kKY2xrX2ZpeGVkMTQ6IGNsb2NrLWZpeGVkIGhhcyBu byBjbG9jay1mcmVxdWVuY3kKY2xrX2ZpeGVkMTQ6IGNsb2NrLWZpeGVkIGhhcyBubyBjbG9jay1m cmVxdWVuY3kKZ2ljMDogPEFSTSBHZW5lcmljIEludGVycnVwdCBDb250cm9sbGVyPiBtZW0gMHgx MDdmZmY5MDAwLTB4MTA3ZmZmOWZmZiwweDEwN2ZmZmEwMDAtMHgxMDdmZmZiZmZmLDB4MTA3ZmZm YzAwMC0weDEwN2ZmZmRmZmYsMHgxMDdmZmZlMDAwLTB4MTA3ZmZmZmZmZiBpcnEgOTIgb24gc2lt cGxlYnVzMQpnaWMwOiBwbiAweDIsIGFyY2ggMHgyLCByZXYgMHgxLCBpbXBsZW1lbnRlciAweDQz YiBpcnFzIDMyMApjbGtfZml4ZWQxNDogY2xvY2stZml4ZWQgaGFzIG5vIGNsb2NrLWZyZXF1ZW5j eQpjbGtfZml4ZWQxNDogY2xvY2stZml4ZWQgaGFzIG5vIGNsb2NrLWZyZXF1ZW5jeQpjbGtfZml4 ZWQxNDogY2xvY2stZml4ZWQgaGFzIG5vIGNsb2NrLWZyZXF1ZW5jeQpjbGtfZml4ZWQxNDogY2xv Y2stZml4ZWQgaGFzIG5vIGNsb2NrLWZyZXF1ZW5jeQpjbGtfZml4ZWQxNDogY2xvY2stZml4ZWQg aGFzIG5vIGNsb2NrLWZyZXF1ZW5jeQpjbGtfZml4ZWQxNDogY2xvY2stZml4ZWQgaGFzIG5vIGNs b2NrLWZyZXF1ZW5jeQptYm94MDogPEJDTTI4MzUgVmlkZW9Db3JlIE1haWxib3g+IG1lbSAweDdj MDEzODgwLTB4N2MwMTM4YmYgaXJxIDE2IG9uIHNpbXBsZWJ1czAKZ3Bpb3JlZ3VsYXRvcjA6IDxH UElPIGNvbnRyb2xsZWQgcmVndWxhdG9yPiBvbiBvZndidXMwCmdwaW9yZWd1bGF0b3IwOiBjYW5u b3QgZ2V0IHBpbiAwCmdwaW9yZWd1bGF0b3IwOiBjYW5ub3QgcGFyc2UgcGFyYW1ldGVycwpkZXZp Y2VfYXR0YWNoOiBncGlvcmVndWxhdG9yMCBhdHRhY2ggcmV0dXJuZWQgNgpjbGtfZml4ZWQxNDog Y2xvY2stZml4ZWQgaGFzIG5vIGNsb2NrLWZyZXF1ZW5jeQpjbGtfZml4ZWQxNDogY2xvY2stZml4 ZWQgaGFzIG5vIGNsb2NrLWZyZXF1ZW5jeQpncGlvcmVndWxhdG9yMDogPEdQSU8gY29udHJvbGxl ZCByZWd1bGF0b3I+IG9uIG9md2J1czAKZ3Bpb3JlZ3VsYXRvcjA6IGNhbm5vdCBnZXQgcGluIDAK Z3Bpb3JlZ3VsYXRvcjA6IGNhbm5vdCBwYXJzZSBwYXJhbWV0ZXJzCmRldmljZV9hdHRhY2g6IGdw aW9yZWd1bGF0b3IwIGF0dGFjaCByZXR1cm5lZCA2CmNsa19maXhlZDE0OiBjbG9jay1maXhlZCBo YXMgbm8gY2xvY2stZnJlcXVlbmN5CmNsa19maXhlZDE0OiBjbG9jay1maXhlZCBoYXMgbm8gY2xv Y2stZnJlcXVlbmN5CmdwaW9yZWd1bGF0b3IwOiA8R1BJTyBjb250cm9sbGVkIHJlZ3VsYXRvcj4g b24gb2Z3YnVzMApncGlvcmVndWxhdG9yMDogY2Fubm90IGdldCBwaW4gMApncGlvcmVndWxhdG9y MDogY2Fubm90IHBhcnNlIHBhcmFtZXRlcnMKZGV2aWNlX2F0dGFjaDogZ3Bpb3JlZ3VsYXRvcjAg YXR0YWNoIHJldHVybmVkIDYKY2xrX2ZpeGVkMTQ6IGNsb2NrLWZpeGVkIGhhcyBubyBjbG9jay1m cmVxdWVuY3kKY2xrX2ZpeGVkMTQ6IGNsb2NrLWZpeGVkIGhhcyBubyBjbG9jay1mcmVxdWVuY3kK Z2VuZXJpY190aW1lcjA6IDxBUk12OCBHZW5lcmljIFRpbWVyPiBpcnEgNyw4LDksMTAgb24gb2Z3 YnVzMApnZW5lcmljX3RpbWVyMDogYWxsb2NhdGVkIGlycSBmb3IgJ3NlYy1waHlzJwpnZW5lcmlj X3RpbWVyMDogYWxsb2NhdGVkIGlycSBmb3IgJ3BoeXMnCmdlbmVyaWNfdGltZXIwOiBhbGxvY2F0 ZWQgaXJxIGZvciAndmlydCcKZ2VuZXJpY190aW1lcjA6IGFsbG9jYXRlZCBpcnEgZm9yICdoeXAt cGh5cycKb2Z3YnVzMDogbm8gZGVmYXVsdCByZXNvdXJjZXMgZm9yIHJpZCA9IDQsIHR5cGUgPSAx CmdlbmVyaWNfdGltZXIwOiBjb3VsZCBub3QgYWxsb2NhdGUgaXJxIGZvciBvcHRpb25hbCBpbnRl cnJ1cHQgJ2h5cC12aXJ0JwpUaW1lY291bnRlciAiQVJNIE1QQ29yZSBUaW1lY291bnRlciIgZnJl cXVlbmN5IDU0MDAwMDAwIEh6IHF1YWxpdHkgMTAwMApFdmVudCB0aW1lciAiQVJNIE1QQ29yZSBF dmVudHRpbWVyIiBmcmVxdWVuY3kgNTQwMDAwMDAgSHogcXVhbGl0eSAxMDAwCmdwaW9yZWd1bGF0 b3IwOiA8R1BJTyBjb250cm9sbGVkIHJlZ3VsYXRvcj4gb24gb2Z3YnVzMApncGlvcmVndWxhdG9y MDogY2Fubm90IGdldCBwaW4gMApncGlvcmVndWxhdG9yMDogY2Fubm90IHBhcnNlIHBhcmFtZXRl cnMKZGV2aWNlX2F0dGFjaDogZ3Bpb3JlZ3VsYXRvcjAgYXR0YWNoIHJldHVybmVkIDYKY2xrX2Zp eGVkMTQ6IGNsb2NrLWZpeGVkIGhhcyBubyBjbG9jay1mcmVxdWVuY3kKY2xrX2ZpeGVkMTQ6IGNs b2NrLWZpeGVkIGhhcyBubyBjbG9jay1mcmVxdWVuY3kKZ3Bpb3JlZ3VsYXRvcjA6IDxHUElPIGNv bnRyb2xsZWQgcmVndWxhdG9yPiBvbiBvZndidXMwCmdwaW9yZWd1bGF0b3IwOiBjYW5ub3QgZ2V0 IHBpbiAwCmdwaW9yZWd1bGF0b3IwOiBjYW5ub3QgcGFyc2UgcGFyYW1ldGVycwpkZXZpY2VfYXR0 YWNoOiBncGlvcmVndWxhdG9yMCBhdHRhY2ggcmV0dXJuZWQgNgpjbGtfZml4ZWQxNDogY2xvY2st Zml4ZWQgaGFzIG5vIGNsb2NrLWZyZXF1ZW5jeQpjbGtfZml4ZWQxNDogY2xvY2stZml4ZWQgaGFz IG5vIGNsb2NrLWZyZXF1ZW5jeQpncGlvcmVndWxhdG9yMDogPEdQSU8gY29udHJvbGxlZCByZWd1 bGF0b3I+IG9uIG9md2J1czAKZ3Bpb3JlZ3VsYXRvcjA6IGNhbm5vdCBnZXQgcGluIDAKZ3Bpb3Jl Z3VsYXRvcjA6IGNhbm5vdCBwYXJzZSBwYXJhbWV0ZXJzCmRldmljZV9hdHRhY2g6IGdwaW9yZWd1 bGF0b3IwIGF0dGFjaCByZXR1cm5lZCA2CmNsa19maXhlZDE0OiBjbG9jay1maXhlZCBoYXMgbm8g Y2xvY2stZnJlcXVlbmN5CmNsa19maXhlZDE0OiBjbG9jay1maXhlZCBoYXMgbm8gY2xvY2stZnJl cXVlbmN5CmdwaW9yZWd1bGF0b3IwOiA8R1BJTyBjb250cm9sbGVkIHJlZ3VsYXRvcj4gb24gb2Z3 YnVzMApncGlvcmVndWxhdG9yMDogY2Fubm90IGdldCBwaW4gMApncGlvcmVndWxhdG9yMDogY2Fu bm90IHBhcnNlIHBhcmFtZXRlcnMKZGV2aWNlX2F0dGFjaDogZ3Bpb3JlZ3VsYXRvcjAgYXR0YWNo IHJldHVybmVkIDYKY2xrX2ZpeGVkMTQ6IGNsb2NrLWZpeGVkIGhhcyBubyBjbG9jay1mcmVxdWVu Y3kKY2xrX2ZpeGVkMTQ6IGNsb2NrLWZpeGVkIGhhcyBubyBjbG9jay1mcmVxdWVuY3kKZ3Bpb3Jl Z3VsYXRvcjA6IDxHUElPIGNvbnRyb2xsZWQgcmVndWxhdG9yPiBvbiBvZndidXMwCmdwaW9yZWd1 bGF0b3IwOiBjYW5ub3QgZ2V0IHBpbiAwCmdwaW9yZWd1bGF0b3IwOiBjYW5ub3QgcGFyc2UgcGFy YW1ldGVycwpkZXZpY2VfYXR0YWNoOiBncGlvcmVndWxhdG9yMCBhdHRhY2ggcmV0dXJuZWQgNgpj bGtfZml4ZWQxNDogY2xvY2stZml4ZWQgaGFzIG5vIGNsb2NrLWZyZXF1ZW5jeQpjbGtfZml4ZWQx NDogY2xvY2stZml4ZWQgaGFzIG5vIGNsb2NrLWZyZXF1ZW5jeQpncGlvcmVndWxhdG9yMDogPEdQ SU8gY29udHJvbGxlZCByZWd1bGF0b3I+IG9uIG9md2J1czAKZ3Bpb3JlZ3VsYXRvcjA6IGNhbm5v dCBnZXQgcGluIDAKZ3Bpb3JlZ3VsYXRvcjA6IGNhbm5vdCBwYXJzZSBwYXJhbWV0ZXJzCmRldmlj ZV9hdHRhY2g6IGdwaW9yZWd1bGF0b3IwIGF0dGFjaCByZXR1cm5lZCA2CmNsa19maXhlZDE0OiBj bG9jay1maXhlZCBoYXMgbm8gY2xvY2stZnJlcXVlbmN5CmNsa19maXhlZDE0OiBjbG9jay1maXhl ZCBoYXMgbm8gY2xvY2stZnJlcXVlbmN5CmdwaW9yZWd1bGF0b3IwOiA8R1BJTyBjb250cm9sbGVk IHJlZ3VsYXRvcj4gb24gb2Z3YnVzMApncGlvcmVndWxhdG9yMDogY2Fubm90IGdldCBwaW4gMApn cGlvcmVndWxhdG9yMDogY2Fubm90IHBhcnNlIHBhcmFtZXRlcnMKZGV2aWNlX2F0dGFjaDogZ3Bp b3JlZ3VsYXRvcjAgYXR0YWNoIHJldHVybmVkIDYKY2xrX2ZpeGVkMTQ6IGNsb2NrLWZpeGVkIGhh cyBubyBjbG9jay1mcmVxdWVuY3kKY2xrX2ZpeGVkMTQ6IGNsb2NrLWZpeGVkIGhhcyBubyBjbG9j ay1mcmVxdWVuY3kKZ3Bpb3JlZ3VsYXRvcjA6IDxHUElPIGNvbnRyb2xsZWQgcmVndWxhdG9yPiBv biBvZndidXMwCmdwaW9yZWd1bGF0b3IwOiBjYW5ub3QgZ2V0IHBpbiAwCmdwaW9yZWd1bGF0b3Iw OiBjYW5ub3QgcGFyc2UgcGFyYW1ldGVycwpkZXZpY2VfYXR0YWNoOiBncGlvcmVndWxhdG9yMCBh dHRhY2ggcmV0dXJuZWQgNgpjbGtfZml4ZWQxNDogY2xvY2stZml4ZWQgaGFzIG5vIGNsb2NrLWZy ZXF1ZW5jeQpjbGtfZml4ZWQxNDogY2xvY2stZml4ZWQgaGFzIG5vIGNsb2NrLWZyZXF1ZW5jeQpn cGlvcmVndWxhdG9yMDogPEdQSU8gY29udHJvbGxlZCByZWd1bGF0b3I+IG9uIG9md2J1czAKZ3Bp b3JlZ3VsYXRvcjA6IGNhbm5vdCBnZXQgcGluIDAKZ3Bpb3JlZ3VsYXRvcjA6IGNhbm5vdCBwYXJz ZSBwYXJhbWV0ZXJzCmRldmljZV9hdHRhY2g6IGdwaW9yZWd1bGF0b3IwIGF0dGFjaCByZXR1cm5l ZCA2CmNsa19maXhlZDE0OiBjbG9jay1maXhlZCBoYXMgbm8gY2xvY2stZnJlcXVlbmN5CmNsa19m aXhlZDE0OiBjbG9jay1maXhlZCBoYXMgbm8gY2xvY2stZnJlcXVlbmN5CmdwaW9yZWd1bGF0b3Iw OiA8R1BJTyBjb250cm9sbGVkIHJlZ3VsYXRvcj4gb24gb2Z3YnVzMApncGlvcmVndWxhdG9yMDog Y2Fubm90IGdldCBwaW4gMApncGlvcmVndWxhdG9yMDogY2Fubm90IHBhcnNlIHBhcmFtZXRlcnMK ZGV2aWNlX2F0dGFjaDogZ3Bpb3JlZ3VsYXRvcjAgYXR0YWNoIHJldHVybmVkIDYKY2xrX2ZpeGVk MTQ6IGNsb2NrLWZpeGVkIGhhcyBubyBjbG9jay1mcmVxdWVuY3kKY2xrX2ZpeGVkMTQ6IGNsb2Nr LWZpeGVkIGhhcyBubyBjbG9jay1mcmVxdWVuY3kKdXNiX25vcF94Y2VpdjA6IDxVU0IgTk9QIFBI WT4gb24gb2Z3YnVzMApncGlvcmVndWxhdG9yMDogPEdQSU8gY29udHJvbGxlZCByZWd1bGF0b3I+ IG9uIG9md2J1czAKZ3Bpb3JlZ3VsYXRvcjA6IGNhbm5vdCBnZXQgcGluIDAKZ3Bpb3JlZ3VsYXRv cjA6IGNhbm5vdCBwYXJzZSBwYXJhbWV0ZXJzCmRldmljZV9hdHRhY2g6IGdwaW9yZWd1bGF0b3Iw IGF0dGFjaCByZXR1cm5lZCA2CmNsa19maXhlZDE0OiBjbG9jay1maXhlZCBoYXMgbm8gY2xvY2st ZnJlcXVlbmN5CmNsa19maXhlZDE0OiBjbG9jay1maXhlZCBoYXMgbm8gY2xvY2stZnJlcXVlbmN5 CmdwaW9yZWd1bGF0b3IwOiA8R1BJTyBjb250cm9sbGVkIHJlZ3VsYXRvcj4gb24gb2Z3YnVzMApn cGlvcmVndWxhdG9yMDogY2Fubm90IGdldCBwaW4gMApncGlvcmVndWxhdG9yMDogY2Fubm90IHBh cnNlIHBhcmFtZXRlcnMKZGV2aWNlX2F0dGFjaDogZ3Bpb3JlZ3VsYXRvcjAgYXR0YWNoIHJldHVy bmVkIDYKY2xrX2ZpeGVkMTQ6IGNsb2NrLWZpeGVkIGhhcyBubyBjbG9jay1mcmVxdWVuY3kKY2xr X2ZpeGVkMTQ6IGNsb2NrLWZpeGVkIGhhcyBubyBjbG9jay1mcmVxdWVuY3kKZWZpcnRjMDogPEVG SSBSZWFsdGltZSBDbG9jaz4KZWZpcnRjMDogcmVnaXN0ZXJlZCBhcyBhIHRpbWUtb2YtZGF5IGNs b2NrLCByZXNvbHV0aW9uIDEuMDAwMDAwcwpyYW0wOiByZXNlcnZpbmcgbWVtb3J5IHJlZ2lvbjog ICAyMTAwMDAtMzA0MDAwMDAKcmFtMDogcmVzZXJ2aW5nIG1lbW9yeSByZWdpb246ICAgMzFlNzQw MDAtMzg0MzAwMDAKcmFtMDogcmVzZXJ2aW5nIG1lbW9yeSByZWdpb246ICAgMzg0ODAwMDAtMzg0 ODIwMDAKcmFtMDogcmVzZXJ2aW5nIG1lbW9yeSByZWdpb246ICAgMzg3NDAwMDAtM2JhMjAwMDAK cmFtMDogcmVzZXJ2aW5nIG1lbW9yeSByZWdpb246ICAgM2JhYjAwMDAtM2JhYzAwMDAKcmFtMDog cmVzZXJ2aW5nIG1lbW9yeSByZWdpb246ICAgM2JiZTAwMDAtM2ZjMDAwMDAKcmFtMDogcmVzZXJ2 aW5nIG1lbW9yeSByZWdpb246ICAgNDAwMDAwMDAtMjAwMDAwMDAwCnJhbTA6IHJlc2VydmluZyBl eGNsdWRlZCByZWdpb246IDAtN2ZmZmYKcmFtMDogcmVzZXJ2aW5nIGV4Y2x1ZGVkIHJlZ2lvbjog MWQwMDAwLTFlZmZmZgpyYW0wOiByZXNlcnZpbmcgZXhjbHVkZWQgcmVnaW9uOiAzMDQwMDAwMC0z MWU3M2ZmZgpyYW0wOiByZXNlcnZpbmcgZXhjbHVkZWQgcmVnaW9uOiAzODQzMDAwMC0zODQ3ZmZm ZgpyYW0wOiByZXNlcnZpbmcgZXhjbHVkZWQgcmVnaW9uOiAzODRkMDAwMC0zODczZmZmZgpyYW0w OiByZXNlcnZpbmcgZXhjbHVkZWQgcmVnaW9uOiAzYmEyMDAwMC0zYmFhZmZmZgpyYW0wOiByZXNl cnZpbmcgZXhjbHVkZWQgcmVnaW9uOiAzYmFjMDAwMC0zYmJkZmZmZgpyYW0wOiByZXNlcnZpbmcg ZXhjbHVkZWQgcmVnaW9uOiAzZmQxNjAwMC0zZmQxNmZmZgpvZndidXMwOiA8aHZzQDEwN2M1ODAw MDA+IG1lbSAweDEwN2M1ODAwMDAtMHgxMDdjNTk5ZmZmIGlycSAwLDEsMiBkaXNhYmxlZCBjb21w YXQgYnJjbSxiY20yNzEyLWh2cyAobm8gZHJpdmVyIGF0dGFjaGVkKQpzaW1wbGVidXMwOiA8dGlt ZXJAN2MwMDMwMDA+IG1lbSAweDdjMDAzMDAwLTB4N2MwMDNmZmYgaXJxIDExLDEyLDEzLDE0IGNv bXBhdCBicmNtLGJjbTI4MzUtc3lzdGVtLXRpbWVyIChubyBkcml2ZXIgYXR0YWNoZWQpCnNpbXBs ZWJ1czA6IDxmaXJtd2FyZWttc0A3ZDUwMzAwMD4gbWVtIDB4N2Q1MDMwMDAtMHg3ZDUwMzAxNyBp cnEgMTUgZGlzYWJsZWQgY29tcGF0IHJhc3BiZXJyeXBpLHJwaS1maXJtd2FyZS1rbXMtMjcxMiAo bm8gZHJpdmVyIGF0dGFjaGVkKQpzaW1wbGVidXMwOiA8cGl4ZWx2YWx2ZUA3YzQxMDAwMD4gbWVt IDB4N2M0MTAwMDAtMHg3YzQxMDBmZiBpcnEgMTcgZGlzYWJsZWQgY29tcGF0IGJyY20sYmNtMjcx Mi1waXhlbHZhbHZlMCAobm8gZHJpdmVyIGF0dGFjaGVkKQpzaW1wbGVidXMwOiA8cGl4ZWx2YWx2 ZUA3YzQxMTAwMD4gbWVtIDB4N2M0MTEwMDAtMHg3YzQxMTBmZiBpcnEgMTggZGlzYWJsZWQgY29t cGF0IGJyY20sYmNtMjcxMi1waXhlbHZhbHZlMSAobm8gZHJpdmVyIGF0dGFjaGVkKQpzaW1wbGVi dXMwOiA8bW9wQDdjNTAwMDAwPiBtZW0gMHg3YzUwMDAwMC0weDdjNTAwMDI3IGlycSAxOSBkaXNh YmxlZCBjb21wYXQgYnJjbSxiY20yNzEyLW1vcCAobm8gZHJpdmVyIGF0dGFjaGVkKQpzaW1wbGVi dXMwOiA8bW9wbGV0QDdjNTAxMDAwPiBtZW0gMHg3YzUwMTAwMC0weDdjNTAxMDFmIGlycSAyMCBk aXNhYmxlZCBjb21wYXQgYnJjbSxiY20yNzEyLW1vcGxldCAobm8gZHJpdmVyIGF0dGFjaGVkKQpz aW1wbGVidXMwOiA8aW50ZXJydXB0LWNvbnRyb2xsZXJAN2M1MDIwMDA+IG1lbSAweDdjNTAyMDAw LTB4N2M1MDIwMmYgaXJxIDIxIGRpc2FibGVkIGNvbXBhdCBicmNtLGJjbTI3MTEtbDItaW50YyAo bm8gZHJpdmVyIGF0dGFjaGVkKQpzaW1wbGVidXMwOiA8Y2xvY2tAN2M3MDAwMDA+IG1lbSAweDdj NzAwMDAwLTB4N2M3MDAwMGYgY29tcGF0IGJyY20sYnJjbTI3MTEtZHZwIChubyBkcml2ZXIgYXR0 YWNoZWQpCnNpbXBsZWJ1czA6IDxsb2NhbF9pbnRjQDdjZDAwMDAwPiBtZW0gMHg3Y2QwMDAwMC0w eDdjZDAwMGZmIGNvbXBhdCBicmNtLGJjbTI4MzYtbDEtaW50YyAobm8gZHJpdmVyIGF0dGFjaGVk KQp1YXJ0MDogPFByaW1lQ2VsbCBVQVJUIChQTDAxMSk+IG1lbSAweDdkMDAxMDAwLTB4N2QwMDEx ZmYgaXJxIDIyIG9uIHNpbXBsZWJ1czAKdWFydDA6IGNvbnNvbGUgKDExNTIwMCxuLDgsMSkKdWFy dDA6IGZhc3QgaW50ZXJydXB0CnVhcnQwOiBQUFMgY2FwdHVyZSBtb2RlOiBEQ0QKc2ltcGxlYnVz MDogPHNlcmlhbEA3ZDAwMTQwMD4gbWVtIDB4N2QwMDE0MDAtMHg3ZDAwMTVmZiBpcnEgMjMgZGlz YWJsZWQgY29tcGF0IGFybSxwbDAxMSAobm8gZHJpdmVyIGF0dGFjaGVkKQpzaW1wbGVidXMwOiA8 c2VyaWFsQDdkMDAxNjAwPiBtZW0gMHg3ZDAwMTYwMC0weDdkMDAxN2ZmIGlycSAyNCBkaXNhYmxl ZCBjb21wYXQgYXJtLHBsMDExIChubyBkcml2ZXIgYXR0YWNoZWQpCnNpbXBsZWJ1czA6IDxzZXJp YWxAN2QwMDE4MDA+IG1lbSAweDdkMDAxODAwLTB4N2QwMDE5ZmYgaXJxIDI1IGRpc2FibGVkIGNv bXBhdCBhcm0scGwwMTEgKG5vIGRyaXZlciBhdHRhY2hlZCkKc2ltcGxlYnVzMDogPHNlcmlhbEA3 ZDAwMWEwMD4gbWVtIDB4N2QwMDFhMDAtMHg3ZDAwMWJmZiBpcnEgMjYgZGlzYWJsZWQgY29tcGF0 IGFybSxwbDAxMSAobm8gZHJpdmVyIGF0dGFjaGVkKQpzaW1wbGVidXMwOiA8bW1jQDdkMDAyMDAw PiBtZW0gMHg3ZDAwMjAwMC0weDdkMDAyMGZmIGRpc2FibGVkIGNvbXBhdCBicmNtLGJjbTI4MzUt c2Rob3N0IChubyBkcml2ZXIgYXR0YWNoZWQpCnNpbXBsZWJ1czA6IDxfaTJzQDdkMDAzMDAwPiBt ZW0gMHg3ZDAwMzAwMC0weDdkMDAzMDIzIGRpc2FibGVkIGNvbXBhdCBicmNtLGJjbTI4MzUtaTJz IChubyBkcml2ZXIgYXR0YWNoZWQpCnNwaTA6IDxCQ00yNzA4LzI4MzUgU1BJIGNvbnRyb2xsZXI+ IG1lbSAweDdkMDA0MDAwLTB4N2QwMDQxZmYgaXJxIDI3IG9uIHNpbXBsZWJ1czAKc3BpYnVzMDog PE9GVyBTUEkgYnVzPiBvbiBzcGkwCnNwaWJ1czA6IDx1bmtub3duIGNhcmQ+IGF0IGNzIDAgbW9k ZSAwCnNpbXBsZWJ1czA6IDxzcGlAN2QwMDQ2MDA+IG1lbSAweDdkMDA0NjAwLTB4N2QwMDQ3ZmYg aXJxIDI4IGRpc2FibGVkIGNvbXBhdCBicmNtLGJjbTI4MzUtc3BpIChubyBkcml2ZXIgYXR0YWNo ZWQpCnNpbXBsZWJ1czA6IDxzcGlAN2QwMDQ4MDA+IG1lbSAweDdkMDA0ODAwLTB4N2QwMDQ5ZmYg aXJxIDI5IGRpc2FibGVkIGNvbXBhdCBicmNtLGJjbTI4MzUtc3BpIChubyBkcml2ZXIgYXR0YWNo ZWQpCnNpbXBsZWJ1czA6IDxzcGlAN2QwMDRhMDA+IG1lbSAweDdkMDA0YTAwLTB4N2QwMDRiZmYg aXJxIDMwIGRpc2FibGVkIGNvbXBhdCBicmNtLGJjbTI4MzUtc3BpIChubyBkcml2ZXIgYXR0YWNo ZWQpCnNpbXBsZWJ1czA6IDxzcGlAN2QwMDRjMDA+IG1lbSAweDdkMDA0YzAwLTB4N2QwMDRkZmYg aXJxIDMxIGRpc2FibGVkIGNvbXBhdCBicmNtLGJjbTI4MzUtc3BpIChubyBkcml2ZXIgYXR0YWNo ZWQpCnNpbXBsZWJ1czA6IDxpMmNAN2QwMDUwMDA+IG1lbSAweDdkMDA1MDAwLTB4N2QwMDUwMWYg aXJxIDMyIGRpc2FibGVkIGNvbXBhdCBicmNtLGJjbTI3MTEtaTJjIChubyBkcml2ZXIgYXR0YWNo ZWQpCnNpbXBsZWJ1czA6IDxpMmNAN2QwMDU2MDA+IG1lbSAweDdkMDA1NjAwLTB4N2QwMDU2MWYg aXJxIDMzIGRpc2FibGVkIGNvbXBhdCBicmNtLGJjbTI3MTEtaTJjIChubyBkcml2ZXIgYXR0YWNo ZWQpCnNpbXBsZWJ1czA6IDxpMmNAN2QwMDU4MDA+IG1lbSAweDdkMDA1ODAwLTB4N2QwMDU4MWYg aXJxIDM0IGRpc2FibGVkIGNvbXBhdCBicmNtLGJjbTI3MTEtaTJjIChubyBkcml2ZXIgYXR0YWNo ZWQpCnNpbXBsZWJ1czA6IDxpMmNAN2QwMDVhMDA+IG1lbSAweDdkMDA1YTAwLTB4N2QwMDVhMWYg aXJxIDM1IGRpc2FibGVkIGNvbXBhdCBicmNtLGJjbTI3MTEtaTJjIChubyBkcml2ZXIgYXR0YWNo ZWQpCnNpbXBsZWJ1czA6IDxpMmNAN2QwMDVjMDA+IG1lbSAweDdkMDA1YzAwLTB4N2QwMDVjMWYg aXJxIDM2IGRpc2FibGVkIGNvbXBhdCBicmNtLGJjbTI3MTEtaTJjIChubyBkcml2ZXIgYXR0YWNo ZWQpCnNpbXBsZWJ1czA6IDxpMmNAN2QwMDVlMDA+IG1lbSAweDdkMDA1ZTAwLTB4N2QwMDVlMWYg aXJxIDM3IGRpc2FibGVkIGNvbXBhdCBicmNtLGJjbTI3MTEtaTJjIChubyBkcml2ZXIgYXR0YWNo ZWQpCnNpbXBsZWJ1czA6IDxwd21AN2QwMGMwMDA+IG1lbSAweDdkMDBjMDAwLTB4N2QwMGMwMjcg ZGlzYWJsZWQgY29tcGF0IGJyY20sYmNtMjgzNS1wd20gKG5vIGRyaXZlciBhdHRhY2hlZCkKc2lt cGxlYnVzMDogPHB3bUA3ZDAwYzgwMD4gbWVtIDB4N2QwMGM4MDAtMHg3ZDAwYzgyNyBkaXNhYmxl ZCBjb21wYXQgYnJjbSxiY20yODM1LXB3bSAobm8gZHJpdmVyIGF0dGFjaGVkKQpzaW1wbGVidXMw OiA8d2F0Y2hkb2dAN2QyMDAwMDA+IG1lbSAweDdkMjAwMDAwLTB4N2QyMDAzMDcgY29tcGF0IGJy Y20sYmNtMjcxMi1wbSAobm8gZHJpdmVyIGF0dGFjaGVkKQpzaW1wbGVidXMwOiA8Y3BybWFuQDdk MjAyMDAwPiBtZW0gMHg3ZDIwMjAwMC0weDdkMjAzZmZmIGRpc2FibGVkIGNvbXBhdCBicmNtLGJj bTI3MTEtY3BybWFuIChubyBkcml2ZXIgYXR0YWNoZWQpCmJjbXJuZzA6IDxCcm9hZGNvbSBCQ00y ODM1L0JDTTI4MzggUk5HPiBtZW0gMHg3ZDIwODAwMC0weDdkMjA4MDI3IG9uIHNpbXBsZWJ1czAK YmNtcm5nMDogc2ltcGxlYnVzMDogPGludGNAN2Q1MDMwMDA+IG1lbSAweDdkNTAzMDAwLTB4N2Q1 MDMwMTcgaXJxIDM4IGNvbXBhdCBicmNtLGwyLWludGMgKG5vIGRyaXZlciBhdHRhY2hlZCkKc2lt cGxlYnVzMDogPHBpbmN0cmxAN2Q1MDQxMDA+IG1lbSAweDdkNTA0MTAwLTB4N2Q1MDQxMmYgY29t cGF0IGJyY20sYmNtMjcxMi1waW5jdHJsIChubyBkcml2ZXIgYXR0YWNoZWQpCnNpbXBsZWJ1czA6 IDxpMmNAN2Q1MDgyMDA+IG1lbSAweDdkNTA4MjAwLTB4N2Q1MDgyNTcgaXJxIDM5IGRpc2FibGVk IGNvbXBhdCBicmNtLGJyY21zdGItaTJjIChubyBkcml2ZXIgYXR0YWNoZWQpCnNpbXBsZWJ1czA6 IDxpMmNAN2Q1MDgyODA+IG1lbSAweDdkNTA4MjgwLTB4N2Q1MDgyZDcgaXJxIDQwIGRpc2FibGVk IGNvbXBhdCBicmNtLGJyY21zdGItaTJjIChubyBkcml2ZXIgYXR0YWNoZWQpCnNpbXBsZWJ1czA6 IDxpMmNAN2Q1MDgzMDA+IG1lbSAweDdkNTA4MzAwLTB4N2Q1MDgzNTcgaXJxIDQxIGRpc2FibGVk IGNvbXBhdCBicmNtLGJyY21zdGItaTJjIChubyBkcml2ZXIgYXR0YWNoZWQpCnNpbXBsZWJ1czA6 IDxpbnRjQDdkNTA4MzgwPiBtZW0gMHg3ZDUwODM4MC0weDdkNTA4MzhmIGlycSA0MiBjb21wYXQg YnJjbSxiY203MjcxLWwyLWludGMgKG5vIGRyaXZlciBhdHRhY2hlZCkKc2ltcGxlYnVzMDogPGlu dGNAN2Q1MDg0MDA+IG1lbSAweDdkNTA4NDAwLTB4N2Q1MDg0MGYgaXJxIDQzIGNvbXBhdCBicmNt LGJjbTcyNzEtbDItaW50YyAobm8gZHJpdmVyIGF0dGFjaGVkKQpzaW1wbGVidXMwOiA8Z3Bpb0A3 ZDUwODUwMD4gbWVtIDB4N2Q1MDg1MDAtMHg3ZDUwODUzZiBpcnEgNDQgY29tcGF0IGJyY20sYnJj bXN0Yi1ncGlvIChubyBkcml2ZXIgYXR0YWNoZWQpCnNpbXBsZWJ1czA6IDxzZXJpYWxAN2Q1MGMw MDA+IG1lbSAweDdkNTBjMDAwLTB4N2Q1MGMwMWYgaXJxIDQ1IGNvbXBhdCBicmNtLGJjbTcyNzEt dWFydCAobm8gZHJpdmVyIGF0dGFjaGVkKQpzaW1wbGVidXMwOiA8c2VyaWFsQDdkNTBkMDAwPiBt ZW0gMHg3ZDUwZDAwMC0weDdkNTBkMDFmIGlycSA0NiBkaXNhYmxlZCBjb21wYXQgYnJjbSxiY203 MjcxLXVhcnQgKG5vIGRyaXZlciBhdHRhY2hlZCkKc2ltcGxlYnVzMDogPHNlcmlhbEA3ZDUwZTAw MD4gbWVtIDB4N2Q1MGUwMDAtMHg3ZDUwZTAxZiBpcnEgNDcgZGlzYWJsZWQgY29tcGF0IGJyY20s YmNtNzI3MS11YXJ0IChubyBkcml2ZXIgYXR0YWNoZWQpCnNpbXBsZWJ1czA6IDxpbnRlcnJ1cHQt Y29udHJvbGxlckA3ZDUxMDYwMD4gbWVtIDB4N2Q1MTA2MDAtMHg3ZDUxMDYyZiBpcnEgNDggZGlz YWJsZWQgY29tcGF0IGJyY20sYmNtMjcxMS1sMi1pbnRjIChubyBkcml2ZXIgYXR0YWNoZWQpCnNp bXBsZWJ1czA6IDxwaW5jdHJsQDdkNTEwNzAwPiBtZW0gMHg3ZDUxMDcwMC0weDdkNTEwNzFmIGNv bXBhdCBicmNtLGJjbTI3MTItYW9uLXBpbmN0cmwgKG5vIGRyaXZlciBhdHRhY2hlZCkKc2ltcGxl YnVzMDogPGludGNAN2Q1MTcwMDA+IG1lbSAweDdkNTE3MDAwLTB4N2Q1MTcwMGYgaXJxIDQ5IGRp c2FibGVkIGNvbXBhdCBicmNtLGJjbTcyNzEtbDItaW50YyAobm8gZHJpdmVyIGF0dGFjaGVkKQpz aW1wbGVidXMwOiA8aTJjQDdkNTE3YTAwPiBtZW0gMHg3ZDUxN2EwMC0weDdkNTE3YTU3IGlycSA1 MCBkaXNhYmxlZCBjb21wYXQgYnJjbSxicmNtc3RiLWkyYyAobm8gZHJpdmVyIGF0dGFjaGVkKQpz aW1wbGVidXMwOiA8cHdtQDdkNTE3YTgwPiBtZW0gMHg3ZDUxN2E4MC0weDdkNTE3YWE3IGNvbXBh dCBicmNtLGJjbTcwMzgtcHdtIChubyBkcml2ZXIgYXR0YWNoZWQpCnNpbXBsZWJ1czA6IDxpbnRj QDdkNTE3YWMwPiBtZW0gMHg3ZDUxN2FjMC0weDdkNTE3YWNmIGlycSA1MSBkaXNhYmxlZCBjb21w YXQgYnJjbSxiY203MjcxLWwyLWludGMgKG5vIGRyaXZlciBhdHRhY2hlZCkKc2ltcGxlYnVzMDog PGludGNAN2Q1MTdiMDA+IG1lbSAweDdkNTE3YjAwLTB4N2Q1MTdiMGYgaXJxIDUyIGNvbXBhdCBi cmNtLGJjbTcyNzEtbDItaW50YyAobm8gZHJpdmVyIGF0dGFjaGVkKQpzaW1wbGVidXMwOiA8Z3Bp b0A3ZDUxN2MwMD4gbWVtIDB4N2Q1MTdjMDAtMHg3ZDUxN2MzZiBpcnEgNTMgY29tcGF0IGJyY20s YnJjbXN0Yi1ncGlvIChubyBkcml2ZXIgYXR0YWNoZWQpCnNpbXBsZV9tZmQwOiA8dGhlcm1hbD4g bWVtIDB4N2Q1NDIwMDAtMHg3ZDU0MmVmZiBjb21wYXQgYnJjbSxiY20yNzExLXRoZXJtYWwgKG5v IGRyaXZlciBhdHRhY2hlZCkKc2ltcGxlYnVzMDogPGkyY0A3ZDU0NDAwMD4gbWVtIDB4N2Q1NDQw MDAtMHg3ZDU0NDA1NyBpcnEgNTQgZGlzYWJsZWQgY29tcGF0IGJyY20sYnJjbXN0Yi1pMmMgKG5v IGRyaXZlciBhdHRhY2hlZCkKc2ltcGxlYnVzMDogPGhkbWlAN2VmMDA3MDA+IG1lbSAweDdjNzAx NDAwLTB4N2M3MDE2ZmYsMHg3YzcwMTAwMC0weDdjNzAxMWZmLDB4N2M3MDFkMDAtMHg3YzcwMWZm ZiwweDdjNzAyMDAwLTB4N2M3MDIwN2YsMHg3YzcwMzgwMC0weDdjNzAzOWZmLDB4N2M3MDQwMDAt MHg3YzcwNDdmZiwweDdjNzAwMTAwLTB4N2M3MDAxN2YsMHg3ZDUxMDgwMC0weDdkNTEwOGZmLDB4 N2M3MjAwMDAtMHg3YzcyMDBmZiBpcnEgNTUsNTYsNTcsNTgsNTkgZGlzYWJsZWQgY29tcGF0IGJy Y20sYmNtMjcxMi1oZG1pMCAobm8gZHJpdmVyIGF0dGFjaGVkKQpzaW1wbGVidXMwOiA8aGRtaUA3 ZWYwNTcwMD4gbWVtIDB4N2M3MDY0MDAtMHg3YzcwNjZmZiwweDdjNzA2MDAwLTB4N2M3MDYxZmYs MHg3YzcwNmQwMC0weDdjNzA2ZmZmLDB4N2M3MDcwMDAtMHg3YzcwNzA3ZiwweDdjNzA4ODAwLTB4 N2M3MDg5ZmYsMHg3YzcwOTAwMC0weDdjNzA5N2ZmLDB4N2M3MDAxODAtMHg3YzcwMDFmZiwweDdk NTExMDAwLTB4N2Q1MTEwZmYsMHg3YzcyMDAwMC0weDdjNzIwMGZmIGlycSA2MCw2MSw2Miw2Myw2 NCBkaXNhYmxlZCBjb21wYXQgYnJjbSxiY20yNzEyLWhkbWkxIChubyBkcml2ZXIgYXR0YWNoZWQp CmJjbTI4MzVfZmlybXdhcmUwOiA8cmVzZXQ+IGNvbXBhdCByYXNwYmVycnlwaSxmaXJtd2FyZS1y ZXNldCAobm8gZHJpdmVyIGF0dGFjaGVkKQpiY20yODM1X2Zpcm13YXJlMDogPHZjaW8+IGNvbXBh dCByYXNwYmVycnlwaSx2Y2lvIChubyBkcml2ZXIgYXR0YWNoZWQpCnNpbXBsZWJ1czA6IDxwb3dl cj4gY29tcGF0IHJhc3BiZXJyeXBpLGJjbTI4MzUtcG93ZXIgKG5vIGRyaXZlciBhdHRhY2hlZCkK ZmIwOiA8QkNNMjgzNSBWVCBmcmFtZWJ1ZmZlciBkcml2ZXI+IG9uIHNpbXBsZWJ1czAKQ2hlY2tp bmcgcm9vdCBhZ2FpbnN0IHJhc3BiZXJyeXBpLG1vZGVsLWIKQ2hlY2tpbmcgcm9vdCBhZ2FpbnN0 IGJyY20sYmNtMjgzNQpDaGVja2luZyByb290IGFnYWluc3QgYnJjbSxiY20yNzA5CkNoZWNraW5n IHJvb3QgYWdhaW5zdCBicmNtLGJjbTI4MzYKQ2hlY2tpbmcgcm9vdCBhZ2FpbnN0IGJyY20sYmNt MjgzNwpDaGVja2luZyByb290IGFnYWluc3QgYnJjbSxiY20yNzExCkNoZWNraW5nIHJvb3QgYWdh aW5zdCBicmNtLGJjbTI4MzgKQ2hlY2tpbmcgcm9vdCBhZ2FpbnN0IGJyY20sYmNtMjcxMgpmYjA6 IGNoYW5naW5nIGZiIGJwcCBmcm9tIDAgdG8gMjQKbWJveDA6IG1ib3ggcmVzcG9uc2UgZXJyb3IK ZmIwOiBiY20yODM1X21ib3hfZmJfaW5pdCBmYWlsZWQsIGVycj01CmRldmljZV9hdHRhY2g6IGZi MCBhdHRhY2ggcmV0dXJuZWQgNgpzaW1wbGVidXMwOiA8cnBpX3J0Yz4gY29tcGF0IHJhc3BiZXJy eXBpLHJwaS1ydGMgKG5vIGRyaXZlciBhdHRhY2hlZCkKc2ltcGxlYnVzMDogPGdwaW9tZW1AN2Q1 MDg1MDA+IG1lbSAweDdkNTA4NTAwLTB4N2Q1MDg1M2YgY29tcGF0IHJhc3BiZXJyeXBpLGdwaW9t ZW0gKG5vIGRyaXZlciBhdHRhY2hlZCkKc2ltcGxlYnVzMDogPGdwaW9tZW1AN2Q1MTdjMDA+IG1l bSAweDdkNTE3YzAwLTB4N2Q1MTdjM2YgY29tcGF0IHJhc3BiZXJyeXBpLGdwaW9tZW0gKG5vIGRy aXZlciBhdHRhY2hlZCkKc2ltcGxlYnVzMDogPGdwaW9tZW1AN2Q1MDQxMDA+IG1lbSAweDdkNTA0 MTAwLTB4N2Q1MDQxMWYgY29tcGF0IHJhc3BiZXJyeXBpLGdwaW9tZW0gKG5vIGRyaXZlciBhdHRh Y2hlZCkKc2ltcGxlYnVzMDogPGdwaW9tZW1AN2Q1MTA3MDA+IG1lbSAweDdkNTEwNzAwLTB4N2Q1 MTA3MWYgY29tcGF0IHJhc3BiZXJyeXBpLGdwaW9tZW0gKG5vIGRyaXZlciBhdHRhY2hlZCkKcG11 MDogPFBlcmZvcm1hbmNlIE1vbml0b3JpbmcgVW5pdD4gaXJxIDMsNCw1LDYgb24gb2Z3YnVzMApv ZndidXMwOiBubyBkZWZhdWx0IHJlc291cmNlcyBmb3IgcmlkID0gNCwgdHlwZSA9IDEKY3B1bGlz dDA6IDxPcGVuIEZpcm13YXJlIENQVSBHcm91cD4gb24gb2Z3YnVzMApjcHUwOiA8T3BlbiBGaXJt d2FyZSBDUFU+IG9uIGNwdWxpc3QwCmNwdTA6IG1pc3NpbmcgJ2Nsb2NrLWZyZXF1ZW5jeScgcHJv cGVydHkKY3B1MTogPE9wZW4gRmlybXdhcmUgQ1BVPiBvbiBjcHVsaXN0MApjcHUxOiBtaXNzaW5n ICdjbG9jay1mcmVxdWVuY3knIHByb3BlcnR5CmNwdTI6IDxPcGVuIEZpcm13YXJlIENQVT4gb24g Y3B1bGlzdDAKY3B1MjogbWlzc2luZyAnY2xvY2stZnJlcXVlbmN5JyBwcm9wZXJ0eQpjcHUzOiA8 T3BlbiBGaXJtd2FyZSBDUFU+IG9uIGNwdWxpc3QwCmNwdTM6IG1pc3NpbmcgJ2Nsb2NrLWZyZXF1 ZW5jeScgcHJvcGVydHkKc2ltcGxlYnVzMTogPGdwdT4gY29tcGF0IGJyY20sYmNtMjcxMi12YzYg KG5vIGRyaXZlciBhdHRhY2hlZCkKc2ltcGxlYnVzMTogPGlvbW11QDUxMDA+IG1lbSAweDEwMDAw MDUxMDAtMHgxMDAwMDA1MTdmIGNvbXBhdCBicmNtLGJjbTI3MTItaW9tbXUgKG5vIGRyaXZlciBh dHRhY2hlZCkKc2ltcGxlYnVzMTogPGlvbW11QDUyMDA+IG1lbSAweDEwMDAwMDUyMDAtMHgxMDAw MDA1MjdmIGNvbXBhdCBicmNtLGJjbTI3MTItaW9tbXUgKG5vIGRyaXZlciBhdHRhY2hlZCkKc2lt cGxlYnVzMTogPGlvbW11QDUyODA+IG1lbSAweDEwMDAwMDUyODAtMHgxMDAwMDA1MmZmIGNvbXBh dCBicmNtLGJjbTI3MTItaW9tbXUgKG5vIGRyaXZlciBhdHRhY2hlZCkKc2ltcGxlYnVzMTogPGlv bW11Y0A1YjAwPiBtZW0gMHgxMDAwMDA1YjAwLTB4MTAwMDAwNWI3ZiBjb21wYXQgYnJjbSxiY20y NzEyLWlvbW11YyAobm8gZHJpdmVyIGF0dGFjaGVkKQpzaW1wbGVidXMxOiA8ZG1hQDEwMDAwPiBt ZW0gMHgxMDAwMDEwMDAwLTB4MTAwMDAxMDVmZiBpcnEgNjUsNjYsNjcsNjgsNjksNzAgY29tcGF0 IGJyY20sYmNtMjcxMi1kbWEgKG5vIGRyaXZlciBhdHRhY2hlZCkKc2ltcGxlYnVzMTogPGRtYUAx MDYwMD4gbWVtIDB4MTAwMDAxMDYwMC0weDEwMDAwMTBiZmYgaXJxIDcxLDcyLDczLDc0LDc1LDc2 IGNvbXBhdCBicmNtLGJjbTI3MTItZG1hIChubyBkcml2ZXIgYXR0YWNoZWQpCnNpbXBsZWJ1czE6 IDxwY2llQDEwMDAwMD4gbWVtIDB4MTAwMDEwMDAwMC0weDEwMDAxMDkzMGYgaXJxIDc3LDc4IGRp c2FibGVkIHR5cGUgcGNpIGNvbXBhdCBicmNtLGJjbTI3MTItcGNpZSAobm8gZHJpdmVyIGF0dGFj aGVkKQpzaW1wbGVidXMxOiA8cGNpZUAxMTAwMDA+IG1lbSAweDEwMDAxMTAwMDAtMHgxMDAwMTE5 MzBmIGlycSA3OSw4MCBkaXNhYmxlZCB0eXBlIHBjaSBjb21wYXQgYnJjbSxiY20yNzEyLXBjaWUg KG5vIGRyaXZlciBhdHRhY2hlZCkKc2ltcGxlYnVzMTogPHJlc2V0LWNvbnRyb2xsZXJAMTE5NTAw PiBtZW0gMHgxMDAwMTE5NTAwLTB4MTAwMDExOTUwZiBjb21wYXQgYnJjbSxiY203MjE2LXBjaWUt c2F0YS1yZXNjYWwgKG5vIGRyaXZlciBhdHRhY2hlZCkKc2ltcGxlYnVzMTogPHBjaWVAMTIwMDAw PiBtZW0gMHgxMDAwMTIwMDAwLTB4MTAwMDEyOTMwZiBpcnEgODEsODIgdHlwZSBwY2kgY29tcGF0 IGJyY20sYmNtMjcxMi1wY2llIChubyBkcml2ZXIgYXR0YWNoZWQpCnNpbXBsZWJ1czE6IDxtc2kt Y29udHJvbGxlckAxMzAwMDA+IG1lbSAweDEwMDAxMzAwMDAtMHgxMDAwMTMwMGJmIGNvbXBhdCBi cmNtLGJjbTI3MTItbWlwLWludGMgKG5vIGRyaXZlciBhdHRhY2hlZCkKc2ltcGxlYnVzMTogPG1z aS1jb250cm9sbGVyQDEzMTAwMD4gbWVtIDB4MTAwMDEzMTAwMC0weDEwMDAxMzEwYmYgY29tcGF0 IGJyY20sYmNtMjcxMi1taXAtaW50YyAobm8gZHJpdmVyIGF0dGFjaGVkKQpzaW1wbGVidXMxOiA8 ZXRoZXJuZXRAMTMwMDAwMD4gbWVtIDB4MTAwMTMwMDAwMC0weDEwMDEzMjAwMGYgaXJxIDgzLDg0 IGRpc2FibGVkIHR5cGUgbmV0d29yayBjb21wYXQgYnJjbSxiY20yNzExLWdlbmV0LXY1IChubyBk cml2ZXIgYXR0YWNoZWQpCnNpbXBsZWJ1czE6IDx1c2JANDgwMDAwPiBtZW0gMHgxMDAwNDgwMDAw LTB4MTAwMDQ4ZmZmZiBpcnEgODUgZGlzYWJsZWQgY29tcGF0IGJyY20sYmNtMjgzNS11c2IgKG5v IGRyaXZlciBhdHRhY2hlZCkKc2ltcGxlYnVzMTogPGNvZGVjQDgwMDAwMD4gbWVtIDB4MTAwMDgw MDAwMC0weDEwMDA4MGZmZmYsMHgxMDAwODQwMDAwLTB4MTAwMDg0MGZmZiBpcnEgODYgY29tcGF0 IHJhc3BiZXJyeXBpLHJwaXZpZC12aWQtZGVjb2RlciAobm8gZHJpdmVyIGF0dGFjaGVkKQpzZGhj aV9mZHQwOiA8Z2VuZXJpYyBmZHQgU0RIQ0kgY29udHJvbGxlcj4gbWVtIDB4MTAwMGZmZjAwMC0w eDEwMDBmZmYyNWYsMHgxMDAwZmZmNDAwLTB4MTAwMGZmZjVmZiwweDEwMDE1MDQwYjAtMHgxMDAx NTA0MGIzLDB4MTAwMTUyMDBmMC0weDEwMDE1MjAxMTMgaXJxIDg3IG9uIHNpbXBsZWJ1czEKc2Ro Y2lfZmR0MC1zbG90MDogMjAwTUh6IDRiaXRzIFZERDogVkNDUTogMy4zViBEUlY6IEJBQ0QgRE1B IHJlbW92YWJsZQpzZGhjaV9mZHQwLXNsb3QwOiA9PT09PT09PT09PT09PSBSRUdJU1RFUiBEVU1Q ID09PT09PT09PT09PT09CnNkaGNpX2ZkdDAtc2xvdDA6IFN5cyBhZGRyOiAweDAwMDAwMDAwIHwg VmVyc2lvbjogIDB4MDAwMDEwMDIKc2RoY2lfZmR0MC1zbG90MDogQmxrIHNpemU6IDB4MDAwMDAy MDAgfCBCbGsgY250OiAgMHgwMDAwMDAwMQpzZGhjaV9mZHQwLXNsb3QwOiBBcmd1bWVudDogMHgw NDQ4NGI1OCB8IFRybiBtb2RlOiAweDAwMDAwMDExCnNkaGNpX2ZkdDAtc2xvdDA6IFByZXNlbnQ6 ICAweDFmZmYwMDAwIHwgSG9zdCBjdGw6IDB4MDAwMDAwMWEKc2RoY2lfZmR0MC1zbG90MDogUG93 ZXI6ICAgIDB4MDAwMDAwMGYgfCBCbGsgZ2FwOiAgMHgwMDAwMDA4MApzZGhjaV9mZHQwLXNsb3Qw OiBXYWtlLXVwOiAgMHgwMDAwMDAwMCB8IENsb2NrOiAgICAweDAwMDAwMDA3CnNkaGNpX2ZkdDAt c2xvdDA6IFRpbWVvdXQ6ICAweDAwMDAwMDBlIHwgSW50IHN0YXQ6IDB4MDAwMDAwMDAKc2RoY2lf ZmR0MC1zbG90MDogSW50IGVuYWI6IDB4NzdmZjdmZmYgfCBTaWcgZW5hYjogMHgwMDAwMDAwMApz ZGhjaV9mZHQwLXNsb3QwOiBBQzEyIGVycjogMHgwMDAwMDAwMCB8IEhvc3QgY3RsMjoweDAwMDAw MDhiCnNkaGNpX2ZkdDAtc2xvdDA6IENhcHM6ICAgICAweDE1ZWFjODMyIHwgQ2FwczI6ICAgIDB4 ODAwMGE1NzcKc2RoY2lfZmR0MC1zbG90MDogTWF4IGN1cnI6IDB4MDAwODAwMDggfCBBRE1BIGVy cjogMHgwMDAwMDAwMApzZGhjaV9mZHQwLXNsb3QwOiBBRE1BIGFkZHI6MHgzYTNiYzAwYyB8IFNs b3QgaW50OiAweDAwMDAwMDAwCnNkaGNpX2ZkdDAtc2xvdDA6ID09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT0Kc2RoY2lfZmR0MDogMSBzbG90KHMpIGFsbG9jYXRlZApz ZGhjaV9mZHQwLXNsb3QwOiBDYXJkIGluc2VydGVkCm1tYzA6IDxNTUMvU0QgYnVzPiBvbiBzZGhj aV9mZHQwCnNkaGNpX2ZkdDE6IDxnZW5lcmljIGZkdCBTREhDSSBjb250cm9sbGVyPiBtZW0gMHgx MDAxMTAwMDAwLTB4MTAwMTEwMDI1ZiwweDEwMDExMDA0MDAtMHgxMDAxMTAwNWZmIGlycSA4OCBv biBzaW1wbGVidXMxCnNkaGNpX2ZkdDEtc2xvdDA6IDIwME1IeiA4Yml0cyBWREQ6IFZDQ1E6IDMu M1YgRFJWOiBCQyBETUEgZW1iZWRkZWQKc2RoY2lfZmR0MS1zbG90MDogPT09PT09PT09PT09PT0g UkVHSVNURVIgRFVNUCA9PT09PT09PT09PT09PQpzZGhjaV9mZHQxLXNsb3QwOiBTeXMgYWRkcjog MHgwMDAwMDAwMCB8IFZlcnNpb246ICAweDAwMDAxMDAyCnNkaGNpX2ZkdDEtc2xvdDA6IEJsayBz aXplOiAweDAwMDAwMDAwIHwgQmxrIGNudDogIDB4MDAwMDAwMDAKc2RoY2lfZmR0MS1zbG90MDog QXJndW1lbnQ6IDB4MDAwMDAwMDAgfCBUcm4gbW9kZTogMHgwMDAwMDAwMApzZGhjaV9mZHQxLXNs b3QwOiBQcmVzZW50OiAgMHgwMWZmMDAwMCB8IEhvc3QgY3RsOiAweDAwMDAwMDAwCnNkaGNpX2Zk dDEtc2xvdDA6IFBvd2VyOiAgICAweDAwMDAwMDAwIHwgQmxrIGdhcDogIDB4MDAwMDAwODAKc2Ro Y2lfZmR0MS1zbG90MDogV2FrZS11cDogIDB4MDAwMDAwMDAgfCBDbG9jazogICAgMHgwMDAwMDAw MApzZGhjaV9mZHQxLXNsb3QwOiBUaW1lb3V0OiAgMHgwMDAwMDAwMCB8IEludCBzdGF0OiAweDAw MDAwMDAwCnNkaGNpX2ZkdDEtc2xvdDA6IEludCBlbmFiOiAweDAwMDAwMDAwIHwgU2lnIGVuYWI6 IDB4MDAwMDAwMDAKc2RoY2lfZmR0MS1zbG90MDogQUMxMiBlcnI6IDB4MDAwMDAwMDAgfCBIb3N0 IGN0bDI6MHgwMDAwMDAwMApzZGhjaV9mZHQxLXNsb3QwOiBDYXBzOiAgICAgMHg1NWVlYzgzMiB8 IENhcHMyOiAgICAweDgwMDBhNTI3CnNkaGNpX2ZkdDEtc2xvdDA6IE1heCBjdXJyOiAweDAwMDgw MDA4IHwgQURNQSBlcnI6IDB4MDAwMDAwMDAKc2RoY2lfZmR0MS1zbG90MDogQURNQSBhZGRyOjB4 MDAwMDAwMDAgfCBTbG90IGludDogMHgwMDAwMDAwMApzZGhjaV9mZHQxLXNsb3QwOiA9PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09CnNkaGNpX2ZkdDE6IDEgc2xvdChz KSBhbGxvY2F0ZWQKc2RoY2lfZmR0MS1zbG90MDogQ2FyZCBpbnNlcnRlZAptbWMxOiA8TU1DL1NE IGJ1cz4gb24gc2RoY2lfZmR0MQpzaW1wbGVidXMxOiA8bW1jQDExMDgwMDA+IG1lbSAweDEwMDEx MDgwMDAtMHgxMDAxMTA4MGZmIGlycSA4OSBkaXNhYmxlZCBjb21wYXQgYnJjbSxiY20yNzExLWVt bWMyIChubyBkcml2ZXIgYXR0YWNoZWQpCnNpbXBsZWJ1czE6IDxyZXNldC1jb250cm9sbGVyQDE1 MDQzMTg+IG1lbSAweDEwMDE1MDQzMTgtMHgxMDAxNTA0MzQ3IGNvbXBhdCBicmNtLGJyY21zdGIt cmVzZXQgKG5vIGRyaXZlciBhdHRhY2hlZCkKc2ltcGxlYnVzMTogPHYzZEAyMDAwMDAwPiBtZW0g MHgxMDAyMDAwMDAwLTB4MTAwMjAwM2ZmZiwweDEwMDIwMDgwMDAtMHgxMDAyMDBkZmZmIGlycSA5 MCw5MSBkaXNhYmxlZCBjb21wYXQgYnJjbSwyNzEyLXYzZCAobm8gZHJpdmVyIGF0dGFjaGVkKQpz aW1wbGVidXMxOiA8cGlzcF9iZUA4ODAwMDA+IG1lbSAweDEwMDA4ODAwMDAtMHgxMDAwODgzZmZm IGlycSA5MyBjb21wYXQgcmFzcGJlcnJ5cGkscGlzcGJlIChubyBkcml2ZXIgYXR0YWNoZWQpCmdw aW9sZWQwOiA8R1BJTyBMRURzPiBvbiBvZndidXMwCmdwaW9sZWQwOiA8UFdSPiBmYWlsZWQgdG8g bWFwIHBpbgpncGlvbGVkMDogPEFDVD4gZmFpbGVkIHRvIG1hcCBwaW4KZ3Bpb3JlZ3VsYXRvcjA6 IDxHUElPIGNvbnRyb2xsZWQgcmVndWxhdG9yPiBvbiBvZndidXMwCmdwaW9yZWd1bGF0b3IwOiBj YW5ub3QgZ2V0IHBpbiAwCmdwaW9yZWd1bGF0b3IwOiBjYW5ub3QgcGFyc2UgcGFyYW1ldGVycwpk ZXZpY2VfYXR0YWNoOiBncGlvcmVndWxhdG9yMCBhdHRhY2ggcmV0dXJuZWQgNgpjbGtfZml4ZWQx NDogY2xvY2stZml4ZWQgaGFzIG5vIGNsb2NrLWZyZXF1ZW5jeQpvZndidXMwOiA8Y2FtMV9jbGs+ IGRpc2FibGVkIGNvbXBhdCBmaXhlZC1jbG9jayAobm8gZHJpdmVyIGF0dGFjaGVkKQpjbGtfZml4 ZWQxNDogY2xvY2stZml4ZWQgaGFzIG5vIGNsb2NrLWZyZXF1ZW5jeQpvZndidXMwOiA8Y2FtMF9j bGs+IGRpc2FibGVkIGNvbXBhdCBmaXhlZC1jbG9jayAobm8gZHJpdmVyIGF0dGFjaGVkKQpvZndi dXMwOiA8Y29vbGluZ19mYW4+IGNvbXBhdCBwd20tZmFuIChubyBkcml2ZXIgYXR0YWNoZWQpCm9m d2J1czA6IDxwd3JfYnV0dG9uPiBjb21wYXQgZ3Bpby1rZXlzIChubyBkcml2ZXIgYXR0YWNoZWQp CmNyeXB0bzogYXNzaWduIGNyeXB0b3NvZnQwIGRyaXZlciBpZCAwLCBmbGFncyAweDYwMDAwMDAK YXJtdjhjcnlwdG8wOiA8QUVTLUNCQyxBRVMtWFRTLEFFUy1HQ00+CmNyeXB0bzogYXNzaWduIGFy bXY4Y3J5cHRvMCBkcml2ZXIgaWQgMSwgZmxhZ3MgMHhlMDAwMDAwCkRldmljZSBjb25maWd1cmF0 aW9uIGZpbmlzaGVkLgpwcm9jZnMgcmVnaXN0ZXJlZApUaW1lY291bnRlcnMgdGljayBldmVyeSAx LjAwMCBtc2VjClpGUyBmaWxlc3lzdGVtIHZlcnNpb246IDUKWkZTIHN0b3JhZ2UgcG9vbCB2ZXJz aW9uOiBmZWF0dXJlcyBzdXBwb3J0ICg1MDAwKQpsbzA6IGJwZiBhdHRhY2hlZAp2bGFuOiBpbml0 aWFsaXplZCwgdXNpbmcgaGFzaCB0YWJsZXMgd2l0aCBjaGFpbmluZwpjcnlwdG86IDxjcnlwdG8g ZGV2aWNlPgpJUHNlYzogSW5pdGlhbGl6ZWQgU2VjdXJpdHkgQXNzb2NpYXRpb24gUHJvY2Vzc2lu Zy4KdGNwX2luaXQ6IG5ldC5pbmV0LnRjcC50Y2JoYXNoc2l6ZSBhdXRvIHR1bmVkIHRvIDY1NTM2 CnVzYl9uZWVkc19leHBsb3JlX2FsbDogbm8gZGV2Y2xhc3MKc2RoY2lfZmR0MC1zbG90MDogRGl2 aWRlciAyNTAgZm9yIGZyZXEgNDAwMDAwIChiYXNlIDIwMDAwMDAwMCkKbW1jMDogUHJvYmluZyBi dXMKbW1jMDogU0QgMi4wIGludGVyZmFjZSBjb25kaXRpb25zOiBPSwptbWMwOiBTRCBwcm9iZTog T0sgKE9DUjogMHgwMGZmODAwMCkKbW1jMDogQ3VycmVudCBPQ1I6IDB4MDBmZjgwMDAKbW1jMDog UHJvYmluZyBjYXJkcwptbWMwOiBOZXcgY2FyZCBkZXRlY3RlZCAoQ0lEIFhYWFhYWFhYWFhYWFhY WFhYWFhYWFhYWFhYWFhYWFhYKQptbWMwOiBOZXcgY2FyZCBkZXRlY3RlZCAoQ1NEIFlZWVlZWVlZ WVlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZKQptbWMwOiBDYXJkIGF0IHJlbGF0aXZlIGFkZHJlc3Mg MHg1MDQ4IGFkZGVkOgptbWMwOiAgY2FyZDogU0RIQyBTRDEyOCA4LjUgU04gWlpaWlpaWlogTUZH IDEwLzIwMjMgYnkgMyBTRAptbWMwOiAgcXVpcmtzOiAwCm1tYzA6ICBidXM6IDRiaXQsIDUwTUh6 IChoaWdoIHNwZWVkIHRpbWluZykKbW1jMDogIG1lbW9yeTogMjQ5ODcyMzg0IGJsb2NrcywgZXJh c2Ugc2VjdG9yIDgxOTIgYmxvY2tzCm1tYzA6IHNldHRpbmcgdHJhbnNmZXIgcmF0ZSB0byA1MC4w MDBNSHogKGhpZ2ggc3BlZWQgdGltaW5nKQpzZGhjaV9mZHQwLXNsb3QwOiBEaXZpZGVyIDIgZm9y IGZyZXEgNTAwMDAwMDAgKGJhc2UgMjAwMDAwMDAwKQptbWNzZDA6IDEyOEdCIDxTREhDIFNEMTI4 IDguNSBTTiBaWlpaWlpaWiBNRkcgMTAvMjAyMyBieSAzIFNEPiBhdCBtbWMwIDUwLjBNSHovNGJp dC82NTUzNS1ibG9jawpzZGhjaV9mZHQxLXNsb3QwOiBEaXZpZGVyIDI1MCBmb3IgZnJlcSA0MDAw MDAgKGJhc2UgMjAwMDAwMDAwKQptbWMxOiBQcm9iaW5nIGJ1cwpHRU9NOiBuZXcgZGlzayBtbWNz ZDAKbW1jMDogc2V0dGluZyBidXMgd2lkdGggdG8gNCBiaXRzIGhpZ2ggc3BlZWQgdGltaW5nCm1t YzE6IFNEIHByb2JlOiBmYWlsZWQKbW1jMTogTU1DIHByb2JlOiBmYWlsZWQKbW1jMTogQ3VycmVu dCBPQ1I6IDB4MDAwMDAwMDAKbW1jMTogTm8gY29tcGF0aWJsZSBjYXJkcyBmb3VuZCBvbiBidXMK VHJ5aW5nIHRvIG1vdW50IHJvb3QgZnJvbSB6ZnM6enJvb3QvUk9PVC9kZWZhdWx0IFtdLi4uCkNQ VSAgMDogQVJNIENvcnRleC1BNzYgcjRwMSBhZmZpbml0eTogIDAgIDAKICAgICAgICAgICAgICAg ICAgIENhY2hlIFR5cGUgPSA8NjQgYnl0ZSBELWNhY2hlbGluZSw2NCBieXRlIEktY2FjaGVsaW5l LFBJUFQgSUNhY2hlLDY0IGJ5dGUgRVJHLDY0IGJ5dGUgQ1dHLElEQz4KIEluc3RydWN0aW9uIFNl dCBBdHRyaWJ1dGVzIDAgPSA8RFAsUkRNLEF0b21pYyxDUkMzMixTSEEyLFNIQTEsQUVTK1BNVUxM PgogSW5zdHJ1Y3Rpb24gU2V0IEF0dHJpYnV0ZXMgMSA9IDxSQ1BDLTguMyxEQ1BvUD4KIEluc3Ry dWN0aW9uIFNldCBBdHRyaWJ1dGVzIDIgPSA8PgogICAgICAgICBQcm9jZXNzb3IgRmVhdHVyZXMg MCA9IDxDU1YzLENTVjIsUkFTLEFkdlNJTUQrSFAsRlArSFAsRUwzLEVMMixFTDEsRUwwIDMyPgog ICAgICAgICBQcm9jZXNzb3IgRmVhdHVyZXMgMSA9IDxQU1RBVEUuU1NCUz4KICAgICAgTWVtb3J5 IE1vZGVsIEZlYXR1cmVzIDAgPSA8VEdyYW40LFRHcmFuNjQsVEdyYW4xNixTTlNNZW0sQmlnRW5k LDE2Yml0IEFTSUQsMVRCIFBBPgogICAgICBNZW1vcnkgTW9kZWwgRmVhdHVyZXMgMSA9IDxYTlgs UEFOK0FUUzFFMSxMTyxIUEQrVFRQQkhBLFZILDE2Yml0IFZNSUQsSEFGK0RTPgogICAgICBNZW1v cnkgTW9kZWwgRmVhdHVyZXMgMiA9IDwzMmJpdCBDQ0lEWCw0OGJpdCBWQSxJRVNCLFVBTyxDblA+ CiAgICAgICAgICAgICBEZWJ1ZyBGZWF0dXJlcyAwID0gPERvdWJsZUxvY2ssMiBDVFggQktQVHMs NCBXYXRjaHBvaW50cyw2IEJyZWFrcG9pbnRzLFBNVXYzcDEsRGVidWd2OHAyPgogICAgICAgICAg ICAgRGVidWcgRmVhdHVyZXMgMSA9IDw+CiAgICAgICAgIEF1eGlsaWFyeSBGZWF0dXJlcyAwID0g PD4KICAgICAgICAgQXV4aWxpYXJ5IEZlYXR1cmVzIDEgPSA8PgpBQXJjaDMyIEluc3RydWN0aW9u IFNldCBBdHRyaWJ1dGVzIDUgPSA8UkRNLENSQzMyLFNIQTIsU0hBMSxBRVMrVk1VTEwsU0VWTD4K QUFyY2gzMiBNZWRpYSBhbmQgVkZQIEZlYXR1cmVzIDAgPSA8RlBSb3VuZCxGUFNxcnQsRlBEaXZp ZGUsRFAgVkZQdjMrdjQsU1AgVkZQdjMrdjQsQWR2U0lNRD4KQUFyY2gzMiBNZWRpYSBhbmQgVkZQ IEZlYXR1cmVzIDEgPSA8U0lNREZNQUMsRlBIUCBBcml0aCxTSU1ESFAgQXJpdGgsU0lNRFNQLFNJ TURJbnQsU0lNRExTLEZQRE5hTixGUEZ0Wj4KIEwxIGNhY2hlOiA2NEtCIChpbnN0cnVjdGlvbiks IDY0S0IgKGRhdGEpCiBMMiBjYWNoZTogNTEyS0IgKHVuaWZpZWQpCiBMMyBjYWNoZTogMjA0OEtC ICh1bmlmaWVkKQpDUFUgIDE6IEFSTSBDb3J0ZXgtQTc2IHI0cDEgYWZmaW5pdHk6ICAxICAwCiBM MSBjYWNoZTogNjRLQiAoaW5zdHJ1Y3Rpb24pLCA2NEtCIChkYXRhKQogTDIgY2FjaGU6IDUxMktC ICh1bmlmaWVkKQogTDMgY2FjaGU6IDIwNDhLQiAodW5pZmllZCkKQ1BVICAyOiBBUk0gQ29ydGV4 LUE3NiByNHAxIGFmZmluaXR5OiAgMiAgMAogTDEgY2FjaGU6IDY0S0IgKGluc3RydWN0aW9uKSwg NjRLQiAoZGF0YSkKIEwyIGNhY2hlOiA1MTJLQiAodW5pZmllZCkKIEwzIGNhY2hlOiAyMDQ4S0Ig KHVuaWZpZWQpCkNQVSAgMzogQVJNIENvcnRleC1BNzYgcjRwMSBhZmZpbml0eTogIDMgIDAKIEwx IGNhY2hlOiA2NEtCIChpbnN0cnVjdGlvbiksIDY0S0IgKGRhdGEpCiBMMiBjYWNoZTogNTEyS0Ig KHVuaWZpZWQpCiBMMyBjYWNoZTogMjA0OEtCICh1bmlmaWVkKQpSZWxlYXNlIEFQcy4uLmRvbmUK RW5hYmxpbmcgQ25QClRDUF9yYXRlbGltaXQ6IElzIG5vdyBpbml0aWFsaXplZApyZWd1bGF0b3I6 IHNodXR0aW5nIGRvd24gdW51c2VkIHJlZ3VsYXRvcnMKcmVndWxhdG9yOiBzaHV0dGluZyBkb3du IHZjYy1zZC4uLiBHRU9NX1BBUlQ6IHBhcnRpdGlvbiAxIG9uIChtbWNzZDAsIEdQVCkgaXMgbm90 IGFsaWduZWQgb24gNDE5NDMwNCBieXRlcwpvawpHRU9NX1BBUlQ6IHBhcnRpdGlvbiAyIG9uICht bWNzZDAsIEdQVCkgaXMgbm90IGFsaWduZWQgb24gNDE5NDMwNCBieXRlcwpyZWd1bGF0b3I6IHNo dXR0aW5nIGRvd24gY2FtLWR1bW15LXJlZy4uLiBHRU9NX1BBUlQ6IHBhcnRpdGlvbiAzIG9uICht bWNzZDAsIEdQVCkgaXMgbm90IGFsaWduZWQgb24gNDE5NDMwNCBieXRlcwpvawplZmlydGMwOiBw cm92aWRpbmcgaW5pdGlhbCBzeXN0ZW0gdGltZQpzdGFydF9pbml0OiB0cnlpbmcgL3NiaW4vaW5p dApsbzA6IGxpbmsgc3RhdGUgY2hhbmdlZCB0byBVUAo= --0000000000001e2b12060ee8371c Content-Type: application/octet-stream; name=dmesg-acpi-plus-devicetree Content-Disposition: attachment; filename=dmesg-acpi-plus-devicetree Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_lrdk2xil2 LS0tPDxCT09UPj4tLS0KV0FSTklORzogQ2Fubm90IGZpbmQgZnJlZWJzZCxkdHMtdmVyc2lvbiBw cm9wZXJ0eSwgY2Fubm90IGNoZWNrIERUQiBjb21wbGlhbmNlCiAgICAgICAgICAgICAgICAgICBU eXBlICAgICBQaHlzaWNhbCAgICAgIFZpcnR1YWwgICAjUGFnZXMgQXR0cgogICAgICAgICAgICAg ICBSZXNlcnZlZCAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwIDAwMDAwMWQwIFdDIFdUIFdCIAog ICAgUnVudGltZVNlcnZpY2VzRGF0YSAwMDAwMDAxZDAwMDAgMDAwMDAwMWQwMDAwIDAwMDAwMDIw IFdDIFdUIFdCIFJVTlRJTUUKICAgICAgICAgICAgICAgUmVzZXJ2ZWQgMDAwMDAwMWYwMDAwIDAw MDAwMDAwMDAwMCAwMDAwMDAyMCBXQyBXVCBXQiAKICAgICBDb252ZW50aW9uYWxNZW1vcnkgMDAw MDAwMjEwMDAwIDAwMDAwMDAwMDAwMCAwMDAzMDE0ZSBXQyBXVCBXQiAKICAgICAgICAgICAgIExv YWRlckNvZGUgMDAwMDMwMzVlMDAwIDAwMDAwMDAwMDAwMCAwMDAwNDAwMCBXQyBXVCBXQiAKICAg ICAgICAgICAgIExvYWRlckRhdGEgMDAwMDM0MzVlMDAwIDAwMDAwMDAwMDAwMCAwMDAwNDAwMCBX QyBXVCBXQiAKICAgICAgICAgICAgIExvYWRlckNvZGUgMDAwMDM4MzVlMDAwIDAwMDAwMDAwMDAw MCAwMDAwMDBkMiBXQyBXVCBXQiAKICAgIFJ1bnRpbWVTZXJ2aWNlc0RhdGEgMDAwMDM4NDMwMDAw IDAwMDAzODQzMDAwMCAwMDAwMDA1MCBXQyBXVCBXQiBSVU5USU1FCiAgICAgQ29udmVudGlvbmFs TWVtb3J5IDAwMDAzODQ4MDAwMCAwMDAwMDAwMDAwMDAgMDAwMDAwMDIgV0MgV1QgV0IgCiAgICAg ICAgICAgICAgIFJlc2VydmVkIDAwMDAzODQ4MjAwMCAwMDAwMDAwMDAwMDAgMDAwMDAwNGUgV0Mg V1QgV0IgCiAgICBSdW50aW1lU2VydmljZXNEYXRhIDAwMDAzODRkMDAwMCAwMDAwMzg0ZDAwMDAg MDAwMDAwNDAgV0MgV1QgV0IgUlVOVElNRQogICAgUnVudGltZVNlcnZpY2VzQ29kZSAwMDAwMzg1 MTAwMDAgMDAwMDM4NTEwMDAwIDAwMDAwMDQwIFdDIFdUIFdCIFJVTlRJTUUKICAgIFJ1bnRpbWVT ZXJ2aWNlc0RhdGEgMDAwMDM4NTUwMDAwIDAwMDAzODU1MDAwMCAwMDAwMDA1MCBXQyBXVCBXQiBS VU5USU1FCiAgICBSdW50aW1lU2VydmljZXNDb2RlIDAwMDAzODVhMDAwMCAwMDAwMzg1YTAwMDAg MDAwMDAwZDAgV0MgV1QgV0IgUlVOVElNRQogICAgICBBQ1BJUmVjbGFpbU1lbW9yeSAwMDAwMzg2 NzAwMDAgMDAwMDAwMDAwMDAwIDAwMDAwMDEwIFdDIFdUIFdCIAogICAgUnVudGltZVNlcnZpY2Vz RGF0YSAwMDAwMzg2ODAwMDAgMDAwMDM4NjgwMDAwIDAwMDAwMDIwIFdDIFdUIFdCIFJVTlRJTUUK ICAgIFJ1bnRpbWVTZXJ2aWNlc0NvZGUgMDAwMDM4NmEwMDAwIDAwMDAzODZhMDAwMCAwMDAwMDBh MCBXQyBXVCBXQiBSVU5USU1FCiAgICAgQ29udmVudGlvbmFsTWVtb3J5IDAwMDAzODc0MDAwMCAw MDAwMDAwMDAwMDAgMDAwMDAwMDMgV0MgV1QgV0IgCiAgICAgICAgICAgICBMb2FkZXJEYXRhIDAw MDAzODc0MzAwMCAwMDAwMDAwMDAwMDAgMDAwMDAwMDEgV0MgV1QgV0IgCiAgICAgQ29udmVudGlv bmFsTWVtb3J5IDAwMDAzODc0NDAwMCAwMDAwMDAwMDAwMDAgMDAwMDFjN2EgV0MgV1QgV0IgCiAg ICAgICBCb290U2VydmljZXNEYXRhIDAwMDAzYTNiZTAwMCAwMDAwMDAwMDAwMDAgMDAwMDEyN2Eg V0MgV1QgV0IgCiAgICAgQ29udmVudGlvbmFsTWVtb3J5IDAwMDAzYjYzODAwMCAwMDAwMDAwMDAw MDAgMDAwMDAwNTAgV0MgV1QgV0IgCiAgICAgICBCb290U2VydmljZXNDb2RlIDAwMDAzYjY4ODAw MCAwMDAwMDAwMDAwMDAgMDAwMDAzOTggV0MgV1QgV0IgCiAgICBSdW50aW1lU2VydmljZXNDb2Rl IDAwMDAzYmEyMDAwMCAwMDAwM2JhMjAwMDAgMDAwMDAwOTAgV0MgV1QgV0IgUlVOVElNRQogICAg IENvbnZlbnRpb25hbE1lbW9yeSAwMDAwM2JhYjAwMDAgMDAwMDAwMDAwMDAwIDAwMDAwMDEwIFdD IFdUIFdCIAogICAgUnVudGltZVNlcnZpY2VzRGF0YSAwMDAwM2JhYzAwMDAgMDAwMDNiYWMwMDAw IDAwMDAwMTIwIFdDIFdUIFdCIFJVTlRJTUUKICAgICBDb252ZW50aW9uYWxNZW1vcnkgMDAwMDNi YmUwMDAwIDAwMDAwMDAwMDAwMCAwMDAwMDAxZiBXQyBXVCBXQiAKICAgICAgIEJvb3RTZXJ2aWNl c0RhdGEgMDAwMDNiYmZmMDAwIDAwMDAwMDAwMDAwMCAwMDAwMDAwMSBXQyBXVCBXQiAKICAgICBD b252ZW50aW9uYWxNZW1vcnkgMDAwMDNiYzAwMDAwIDAwMDAwMDAwMDAwMCAwMDAwMzI1MCBXQyBX VCBXQiAKICAgICAgIEJvb3RTZXJ2aWNlc0NvZGUgMDAwMDNlZTUwMDAwIDAwMDAwMDAwMDAwMCAw MDAwMDAzOCBXQyBXVCBXQiAKICAgICAgIEJvb3RTZXJ2aWNlc0RhdGEgMDAwMDNlZTg4MDAwIDAw MDAwMDAwMDAwMCAwMDAwMGQ3OCBXQyBXVCBXQiAKICAgICBDb252ZW50aW9uYWxNZW1vcnkgMDAw MDQwMDAwMDAwIDAwMDAwMDAwMDAwMCAwMDFjMDAwMCBXQyBXVCBXQiAKICAgICAgICAgTWVtb3J5 TWFwcGVkSU8gMDAxMDdjMDEzMDAwIDAwMTA3YzAxMzAwMCAwMDAwMDAwMSBVQyBSVU5USU1FClBo eXNpY2FsIG1lbW9yeSBjaHVuayhzKToKICAweDAwMWQwMDAwIC0gMHgwMDFlZmZmZiwgICAgIDAg TUIgKCAgICAgMzIgcGFnZXMpCiAgMHgwMDIxMDAwMCAtIDB4Mzg0ODFmZmYsICAgODk4IE1CICgg MjMwMDAyIHBhZ2VzKQogIDB4Mzg0ZDAwMDAgLSAweDNmYmZmZmZmLCAgIDExOSBNQiAoICAzMDUx MiBwYWdlcykKICAweDQwMDAwMDAwIC0gMHgxZmZmZmZmZmYsICA3MTY4IE1CICgxODM1MDA4IHBh Z2VzKQpFeGNsdWRlZCBtZW1vcnkgcmVnaW9uczoKICAweDAwMDAwMDAwIC0gMHgwMDA3ZmZmZiwg ICAgIDAgTUIgKCAgICAxMjggcGFnZXMpIE5vQWxsb2MgTm9EdW1wCiAgMHgwMDFkMDAwMCAtIDB4 MDAxZWZmZmYsICAgICAwIE1CICggICAgIDMyIHBhZ2VzKSBOb0FsbG9jIAogIDB4MzA0MDAwMDAg LSAweDMxZTczZmZmLCAgICAyNiBNQiAoICAgNjc3MiBwYWdlcykgTm9BbGxvYyAKICAweDM4NDMw MDAwIC0gMHgzODQ3ZmZmZiwgICAgIDAgTUIgKCAgICAgODAgcGFnZXMpIE5vQWxsb2MgCiAgMHgz ODRkMDAwMCAtIDB4Mzg3M2ZmZmYsICAgICAyIE1CICggICAgNjI0IHBhZ2VzKSBOb0FsbG9jIAog IDB4M2JhMjAwMDAgLSAweDNiYWFmZmZmLCAgICAgMCBNQiAoICAgIDE0NCBwYWdlcykgTm9BbGxv YyAKICAweDNiYWMwMDAwIC0gMHgzYmJkZmZmZiwgICAgIDEgTUIgKCAgICAyODggcGFnZXMpIE5v QWxsb2MgCiAgMHgzZmQxNjAwMCAtIDB4M2ZkMTZmZmYsICAgICAwIE1CICggICAgICAxIHBhZ2Vz KSBOb0FsbG9jIE5vRHVtcApGb3VuZCA0IENQVXMgaW4gdGhlIGRldmljZSB0cmVlCkNvcHlyaWdo dCAoYykgMTk5Mi0yMDIzIFRoZSBGcmVlQlNEIFByb2plY3QuCkNvcHlyaWdodCAoYykgMTk3OSwg MTk4MCwgMTk4MywgMTk4NiwgMTk4OCwgMTk4OSwgMTk5MSwgMTk5MiwgMTk5MywgMTk5NAoJVGhl IFJlZ2VudHMgb2YgdGhlIFVuaXZlcnNpdHkgb2YgQ2FsaWZvcm5pYS4gQWxsIHJpZ2h0cyByZXNl cnZlZC4KRnJlZUJTRCBpcyBhIHJlZ2lzdGVyZWQgdHJhZGVtYXJrIG9mIFRoZSBGcmVlQlNEIEZv dW5kYXRpb24uCkZyZWVCU0QgMTQuMC1SRUxFQVNFICM0OiBTYXQgSmFuIDEzIDE1OjU0OjQwIEdN VCAyMDI0CiAgICByb290QGZyZWVic2QxNC1ycGk1Oi91c3Ivb2JqL3Vzci9zcmMvYXJtNjQuYWFy Y2g2NC9zeXMvR0VORVJJQyBhcm02NApGcmVlQlNEIGNsYW5nIHZlcnNpb24gMTYuMC42IChodHRw czovL2dpdGh1Yi5jb20vbGx2bS9sbHZtLXByb2plY3QuZ2l0IGxsdm1vcmctMTYuMC42LTAtZzdj YmYxYTI1OTE1MikKVlQ6IGluaXQgd2l0aG91dCBkcml2ZXIuClByZWxvYWRlZCBlbGYga2VybmVs ICIvYm9vdC9rZXJuZWwva2VybmVsIiBhdCAweGZmZmYwMDAwMDE4M2UwMDAuClByZWxvYWRlZCBl bGYgbW9kdWxlICIvYm9vdC9rZXJuZWwvemZzLmtvIiBhdCAweGZmZmYwMDAwMDE4NDc1MjAuClBy ZWxvYWRlZCBlbGYgbW9kdWxlICIvYm9vdC9rZXJuZWwvY3J5cHRvZGV2LmtvIiBhdCAweGZmZmYw MDAwMDE4NDdkNzguClByZWxvYWRlZCBib290X2VudHJvcHlfY2FjaGUgIi9ib290L2VudHJvcHki IGF0IDB4ZmZmZjAwMDAwMTg0ODU1OC4KUHJlbG9hZGVkIGhvc3R1dWlkICIvZXRjL2hvc3RpZCIg YXQgMHhmZmZmMDAwMDAxODQ4NWIwLgpQcmVsb2FkZWQgYm9vdF9lbnRyb3B5X3BsYXRmb3JtICJl Zmlfcm5nX3NlZWQiIGF0IDB4ZmZmZjAwMDAwMTg0ODYwMC4KUHJlbG9hZGVkIFRTTE9HIGRhdGEg IlRTTE9HIiBhdCAweGZmZmYwMDAwMDE4NDg2NTguCm1vZHVsZSBzY21pIGFscmVhZHkgcHJlc2Vu dCEKcmVhbCBtZW1vcnkgID0gODU4MzM4OTE4NCAoODE4NSBNQikKUGh5c2ljYWwgbWVtb3J5IGNo dW5rKHMpOgoweDAwMDAwMDAwMjEwMDAwIC0gMHgwMDAwMDAzMDNmZmZmZiwgODA3MzM3OTg0IGJ5 dGVzICgxOTcxMDQgcGFnZXMpCjB4MDAwMDAwMzFlNzQwMDAgLSAweDAwMDAwMDM4NDJmZmZmLCAx MDY2NzYyMjQgYnl0ZXMgKDI2MDQ0IHBhZ2VzKQoweDAwMDAwMDM4NDgwMDAwIC0gMHgwMDAwMDAz ODQ4MWZmZiwgODE5MiBieXRlcyAoMiBwYWdlcykKMHgwMDAwMDAzODc0MDAwMCAtIDB4MDAwMDAw M2JhMWZmZmYsIDUzMzQ2MzA0IGJ5dGVzICgxMzAyNCBwYWdlcykKMHgwMDAwMDAzYmFiMDAwMCAt IDB4MDAwMDAwM2JhYmZmZmYsIDY1NTM2IGJ5dGVzICgxNiBwYWdlcykKMHgwMDAwMDAzYmJlMDAw MCAtIDB4MDAwMDAwM2ZiZmZmZmYsIDY3MjM5OTM2IGJ5dGVzICgxNjQxNiBwYWdlcykKMHgwMDAw MDA0MDAwMDAwMCAtIDB4MDAwMDAxZjM1MzNmZmYsIDczMDM1NDQ4MzIgYnl0ZXMgKDE3ODMwOTIg cGFnZXMpCmF2YWlsIG1lbW9yeSA9IDgzMzY1MTUwNzIgKDc5NTAgTUIpClN0YXJ0aW5nIENQVSAx ICgxMDApClN0YXJ0aW5nIENQVSAyICgyMDApClN0YXJ0aW5nIENQVSAzICgzMDApCkZyZWVCU0Qv U01QOiBNdWx0aXByb2Nlc3NvciBTeXN0ZW0gRGV0ZWN0ZWQ6IDQgQ1BVcwpFbmFibGluZyBJREMg SUNhY2hlIHN5bmMKRW5hYmxpbmcgTFNFIGF0b21pY3MgaW4gdGhlIGtlcm5lbApyYW5kb206IHJl YWQgNDA5NiBieXRlcyBmcm9tIHByZWxvYWRlZCBjYWNoZQpyYW5kb206IHJlYWQgMjA0OCBieXRl cyBmcm9tIHBsYXRmb3JtIGJvb3Rsb2FkZXIKcmFuZG9tOiB1bmJsb2NraW5nIGRldmljZS4KVklN QUdFICh2aXJ0dWFsaXplZCBuZXR3b3JrIHN0YWNrKSBlbmFibGVkCmhvc3R1dWlkOiB1c2luZyAw MGQwNDE3MC0wMDAwLTAwMDAtNDE2ZC03N2I3YWExOTg4MzkKVUxFOiBzZXR1cCBjcHUgMApVTEU6 IHNldHVwIGNwdSAxClVMRTogc2V0dXAgY3B1IDIKVUxFOiBzZXR1cCBjcHUgMwpyYW5kb206IGVu dHJvcHkgZGV2aWNlIGV4dGVybmFsIGludGVyZmFjZQpzbmRfdW5pdF9pbml0KCkgdT0weDAwZmY4 MDAwIFs1MTJdIGQ9MHgwMDAwN2MwMCBbMzJdIGM9MHgwMDAwMDNmZiBbMTAyNF0KZmVlZGVyX3Jl Z2lzdGVyOiBzbmRfdW5pdD0tMSBzbmRfbWF4YXV0b3ZjaGFucz0xNiBsYXRlbmN5PTIgZmVlZGVy X3JhdGVfbWluPTEgZmVlZGVyX3JhdGVfbWF4PTIwMTYwMDAgZmVlZGVyX3JhdGVfcm91bmQ9MjUK ZmlybXdhcmU6ICd0ZWdyYTIxMF94dXNiX2Z3JyB2ZXJzaW9uIDA6IDEzMjYwOCBieXRlcyBsb2Fk ZWQgYXQgMHhmZmZmMDAwMDAwYWY5NTE4Ck1BUCAxZDAwMDAgbW9kZSAyIHBhZ2VzIDMyCk1BUCAz ODQzMDAwMCBtb2RlIDIgcGFnZXMgODAKTUFQIDM4NGQwMDAwIG1vZGUgMiBwYWdlcyA2NApNQVAg Mzg1MTAwMDAgbW9kZSAyIHBhZ2VzIDY0Ck1BUCAzODU1MDAwMCBtb2RlIDIgcGFnZXMgODAKTUFQ IDM4NWEwMDAwIG1vZGUgMiBwYWdlcyAyMDgKTUFQIDM4NjgwMDAwIG1vZGUgMiBwYWdlcyAzMgpN QVAgMzg2YTAwMDAgbW9kZSAyIHBhZ2VzIDE2MApNQVAgM2JhMjAwMDAgbW9kZSAyIHBhZ2VzIDE0 NApNQVAgM2JhYzAwMDAgbW9kZSAyIHBhZ2VzIDI4OApNQVAgMTA3YzAxMzAwMCBtb2RlIDQgcGFn ZXMgMQprYmQwIGF0IGtiZG11eDAKbWVtOiA8bWVtb3J5PgpudWxsOiA8ZnVsbCBkZXZpY2UsIG51 bGwgZGV2aWNlLCB6ZXJvIGRldmljZT4Kb3BlbmZpcm06IDxPcGVuIEZpcm13YXJlIGNvbnRyb2wg ZGV2aWNlPgp0Y3BfbG9nOiB0Y3BfbG9nIGRldmljZQpjcnlwdG86IDxjcnlwdG8gY29yZT4Kb2Z3 YnVzMDogPE9wZW4gRmlybXdhcmUgRGV2aWNlIFRyZWU+CmNsa19maXhlZDA6IDxGaXhlZCBjbG9j az4gb24gb2Z3YnVzMApjbGtfZml4ZWQxOiA8Rml4ZWQgY2xvY2s+IG9uIG9md2J1czAKc2ltcGxl YnVzMDogPEZsYXR0ZW5lZCBkZXZpY2UgdHJlZSBzaW1wbGUgYnVzPiBvbiBvZndidXMwCnJlZ2Zp eDA6IDxGaXhlZCBSZWd1bGF0b3I+IG9uIHNpbXBsZWJ1czAKcmVnZml4MTogPEZpeGVkIFJlZ3Vs YXRvcj4gb24gc2ltcGxlYnVzMApzaW1wbGVidXMxOiA8RmxhdHRlbmVkIGRldmljZSB0cmVlIHNp bXBsZSBidXM+IG9uIG9md2J1czAKc2ltcGxlYnVzMTogTWFsZm9ybWVkIHJlZyBwcm9wZXJ0eSBv biA8dmNfbWVtPgpvZndfY2xrYnVzMDogPE9GVyBjbG9ja3MgYnVzPiBvbiBvZndidXMwCmNsa19m aXhlZDI6IDxGaXhlZCBjbG9jaz4gb24gb2Z3X2Nsa2J1czAKY2xrX2ZpeGVkMzogPEZpeGVkIGNs b2NrPiBvbiBvZndfY2xrYnVzMApjbGtfZml4ZWQ0OiA8Rml4ZWQgY2xvY2s+IG9uIG9md19jbGti dXMwCmNsa19maXhlZDU6IDxGaXhlZCBjbG9jaz4gb24gb2Z3X2Nsa2J1czAKY2xrX2ZpeGVkNjog PEZpeGVkIGNsb2NrPiBvbiBvZndfY2xrYnVzMApjbGtfZml4ZWQ3OiA8Rml4ZWQgY2xvY2s+IG9u IG9md19jbGtidXMwCmNsa19maXhlZDg6IDxGaXhlZCBjbG9jaz4gb24gb2Z3X2Nsa2J1czAKY2xr X2ZpeGVkOTogPEZpeGVkIGNsb2NrPiBvbiBvZndfY2xrYnVzMApjbGtfZml4ZWQxMDogPEZpeGVk IGNsb2NrPiBvbiBvZndfY2xrYnVzMApjbGtfZml4ZWQxMTogPEZpeGVkIGNsb2NrPiBvbiBvZndf Y2xrYnVzMApjbGtfZml4ZWQxMjogPEZpeGVkIGNsb2NrPiBvbiBvZndfY2xrYnVzMApjbGtfZml4 ZWQxMzogPEZpeGVkIGNsb2NrPiBvbiBvZndfY2xrYnVzMApyZWdmaXgyOiA8Rml4ZWQgUmVndWxh dG9yPiBvbiBvZndidXMwCnJlZ2ZpeDM6IDxGaXhlZCBSZWd1bGF0b3I+IG9uIG9md2J1czAKY2xr X2ZpeGVkMTQ6IGNsb2NrLWZpeGVkIGhhcyBubyBjbG9jay1mcmVxdWVuY3kKY2xrX2ZpeGVkMTQ6 IGNsb2NrLWZpeGVkIGhhcyBubyBjbG9jay1mcmVxdWVuY3kKcmVnZml4NDogPEZpeGVkIFJlZ3Vs YXRvcj4gb24gb2Z3YnVzMApyZWdmaXg1OiA8Rml4ZWQgUmVndWxhdG9yPiBvbiBvZndidXMwCnJl Z2ZpeDY6IDxGaXhlZCBSZWd1bGF0b3I+IG9uIG9md2J1czAKcmVnZml4NzogPEZpeGVkIFJlZ3Vs YXRvcj4gb24gb2Z3YnVzMApzaW1wbGVfbWZkMDogPFNpbXBsZSBNRkQgKE11bHRpLUZ1bmN0aW9u cyBEZXZpY2UpPiBtZW0gMHg3ZDU0MjAwMC0weDdkNTQyZWZmIG9uIHNpbXBsZWJ1czAKYmNtMjgz NV9maXJtd2FyZTA6IDxCQ00yODM1IEZpcm13YXJlPiBvbiBzaW1wbGVidXMwCm9md19jbGtidXMx OiA8T0ZXIGNsb2NrcyBidXM+IG9uIGJjbTI4MzVfZmlybXdhcmUwCnNpbXBsZV9tZmQxOiA8U2lt cGxlIE1GRCAoTXVsdGktRnVuY3Rpb25zIERldmljZSk+IG1lbSAweDEwMDA0MDAwMTgtMHgxMDAw NDAwMDJmIG9uIHNpbXBsZWJ1czEKY2xrX2ZpeGVkMTQ6IGNsb2NrLWZpeGVkIGhhcyBubyBjbG9j ay1mcmVxdWVuY3kKY2xrX2ZpeGVkMTQ6IGNsb2NrLWZpeGVkIGhhcyBubyBjbG9jay1mcmVxdWVu Y3kKcHNjaTA6IDxBUk0gUG93ZXIgU3RhdGUgQ28tb3JkaW5hdGlvbiBJbnRlcmZhY2UgRHJpdmVy PiBvbiBvZndidXMwCnBzY2kwOiBQU0NJIHZlcnNpb24gMC4yIGNvbXBhdGlibGUKRm91bmQgU01D Q0MgdmVyc2lvbiAxLjAKY2xrX2ZpeGVkMTQ6IGNsb2NrLWZpeGVkIGhhcyBubyBjbG9jay1mcmVx dWVuY3kKY2xrX2ZpeGVkMTQ6IGNsb2NrLWZpeGVkIGhhcyBubyBjbG9jay1mcmVxdWVuY3kKY2xr X2ZpeGVkMTQ6IGNsb2NrLWZpeGVkIGhhcyBubyBjbG9jay1mcmVxdWVuY3kKY2xrX2ZpeGVkMTQ6 IGNsb2NrLWZpeGVkIGhhcyBubyBjbG9jay1mcmVxdWVuY3kKY2xrX2ZpeGVkMTQ6IGNsb2NrLWZp eGVkIGhhcyBubyBjbG9jay1mcmVxdWVuY3kKY2xrX2ZpeGVkMTQ6IGNsb2NrLWZpeGVkIGhhcyBu byBjbG9jay1mcmVxdWVuY3kKY2xrX2ZpeGVkMTQ6IGNsb2NrLWZpeGVkIGhhcyBubyBjbG9jay1m cmVxdWVuY3kKY2xrX2ZpeGVkMTQ6IGNsb2NrLWZpeGVkIGhhcyBubyBjbG9jay1mcmVxdWVuY3kK Y2xrX2ZpeGVkMTQ6IGNsb2NrLWZpeGVkIGhhcyBubyBjbG9jay1mcmVxdWVuY3kKY2xrX2ZpeGVk MTQ6IGNsb2NrLWZpeGVkIGhhcyBubyBjbG9jay1mcmVxdWVuY3kKY2xrX2ZpeGVkMTQ6IGNsb2Nr LWZpeGVkIGhhcyBubyBjbG9jay1mcmVxdWVuY3kKY2xrX2ZpeGVkMTQ6IGNsb2NrLWZpeGVkIGhh cyBubyBjbG9jay1mcmVxdWVuY3kKY2xrX2ZpeGVkMTQ6IGNsb2NrLWZpeGVkIGhhcyBubyBjbG9j ay1mcmVxdWVuY3kKY2xrX2ZpeGVkMTQ6IGNsb2NrLWZpeGVkIGhhcyBubyBjbG9jay1mcmVxdWVu Y3kKY2xrX2ZpeGVkMTQ6IGNsb2NrLWZpeGVkIGhhcyBubyBjbG9jay1mcmVxdWVuY3kKY2xrX2Zp eGVkMTQ6IGNsb2NrLWZpeGVkIGhhcyBubyBjbG9jay1mcmVxdWVuY3kKZ2ljMDogPEFSTSBHZW5l cmljIEludGVycnVwdCBDb250cm9sbGVyPiBtZW0gMHgxMDdmZmY5MDAwLTB4MTA3ZmZmOWZmZiww eDEwN2ZmZmEwMDAtMHgxMDdmZmZiZmZmLDB4MTA3ZmZmYzAwMC0weDEwN2ZmZmRmZmYsMHgxMDdm ZmZlMDAwLTB4MTA3ZmZmZmZmZiBpcnEgOTIgb24gc2ltcGxlYnVzMQpnaWMwOiBwbiAweDIsIGFy Y2ggMHgyLCByZXYgMHgxLCBpbXBsZW1lbnRlciAweDQzYiBpcnFzIDMyMApjbGtfZml4ZWQxNDog Y2xvY2stZml4ZWQgaGFzIG5vIGNsb2NrLWZyZXF1ZW5jeQpjbGtfZml4ZWQxNDogY2xvY2stZml4 ZWQgaGFzIG5vIGNsb2NrLWZyZXF1ZW5jeQpjbGtfZml4ZWQxNDogY2xvY2stZml4ZWQgaGFzIG5v IGNsb2NrLWZyZXF1ZW5jeQpjbGtfZml4ZWQxNDogY2xvY2stZml4ZWQgaGFzIG5vIGNsb2NrLWZy ZXF1ZW5jeQpjbGtfZml4ZWQxNDogY2xvY2stZml4ZWQgaGFzIG5vIGNsb2NrLWZyZXF1ZW5jeQpj bGtfZml4ZWQxNDogY2xvY2stZml4ZWQgaGFzIG5vIGNsb2NrLWZyZXF1ZW5jeQptYm94MDogPEJD TTI4MzUgVmlkZW9Db3JlIE1haWxib3g+IG1lbSAweDdjMDEzODgwLTB4N2MwMTM4YmYgaXJxIDE2 IG9uIHNpbXBsZWJ1czAKZ3Bpb3JlZ3VsYXRvcjA6IDxHUElPIGNvbnRyb2xsZWQgcmVndWxhdG9y PiBvbiBvZndidXMwCmdwaW9yZWd1bGF0b3IwOiBjYW5ub3QgZ2V0IHBpbiAwCmdwaW9yZWd1bGF0 b3IwOiBjYW5ub3QgcGFyc2UgcGFyYW1ldGVycwpkZXZpY2VfYXR0YWNoOiBncGlvcmVndWxhdG9y MCBhdHRhY2ggcmV0dXJuZWQgNgpjbGtfZml4ZWQxNDogY2xvY2stZml4ZWQgaGFzIG5vIGNsb2Nr LWZyZXF1ZW5jeQpjbGtfZml4ZWQxNDogY2xvY2stZml4ZWQgaGFzIG5vIGNsb2NrLWZyZXF1ZW5j eQpncGlvcmVndWxhdG9yMDogPEdQSU8gY29udHJvbGxlZCByZWd1bGF0b3I+IG9uIG9md2J1czAK Z3Bpb3JlZ3VsYXRvcjA6IGNhbm5vdCBnZXQgcGluIDAKZ3Bpb3JlZ3VsYXRvcjA6IGNhbm5vdCBw YXJzZSBwYXJhbWV0ZXJzCmRldmljZV9hdHRhY2g6IGdwaW9yZWd1bGF0b3IwIGF0dGFjaCByZXR1 cm5lZCA2CmNsa19maXhlZDE0OiBjbG9jay1maXhlZCBoYXMgbm8gY2xvY2stZnJlcXVlbmN5CmNs a19maXhlZDE0OiBjbG9jay1maXhlZCBoYXMgbm8gY2xvY2stZnJlcXVlbmN5CmdwaW9yZWd1bGF0 b3IwOiA8R1BJTyBjb250cm9sbGVkIHJlZ3VsYXRvcj4gb24gb2Z3YnVzMApncGlvcmVndWxhdG9y MDogY2Fubm90IGdldCBwaW4gMApncGlvcmVndWxhdG9yMDogY2Fubm90IHBhcnNlIHBhcmFtZXRl cnMKZGV2aWNlX2F0dGFjaDogZ3Bpb3JlZ3VsYXRvcjAgYXR0YWNoIHJldHVybmVkIDYKY2xrX2Zp eGVkMTQ6IGNsb2NrLWZpeGVkIGhhcyBubyBjbG9jay1mcmVxdWVuY3kKY2xrX2ZpeGVkMTQ6IGNs b2NrLWZpeGVkIGhhcyBubyBjbG9jay1mcmVxdWVuY3kKZ2VuZXJpY190aW1lcjA6IDxBUk12OCBH ZW5lcmljIFRpbWVyPiBpcnEgNyw4LDksMTAgb24gb2Z3YnVzMApnZW5lcmljX3RpbWVyMDogYWxs b2NhdGVkIGlycSBmb3IgJ3NlYy1waHlzJwpnZW5lcmljX3RpbWVyMDogYWxsb2NhdGVkIGlycSBm b3IgJ3BoeXMnCmdlbmVyaWNfdGltZXIwOiBhbGxvY2F0ZWQgaXJxIGZvciAndmlydCcKZ2VuZXJp Y190aW1lcjA6IGFsbG9jYXRlZCBpcnEgZm9yICdoeXAtcGh5cycKb2Z3YnVzMDogbm8gZGVmYXVs dCByZXNvdXJjZXMgZm9yIHJpZCA9IDQsIHR5cGUgPSAxCmdlbmVyaWNfdGltZXIwOiBjb3VsZCBu b3QgYWxsb2NhdGUgaXJxIGZvciBvcHRpb25hbCBpbnRlcnJ1cHQgJ2h5cC12aXJ0JwpUaW1lY291 bnRlciAiQVJNIE1QQ29yZSBUaW1lY291bnRlciIgZnJlcXVlbmN5IDU0MDAwMDAwIEh6IHF1YWxp dHkgMTAwMApFdmVudCB0aW1lciAiQVJNIE1QQ29yZSBFdmVudHRpbWVyIiBmcmVxdWVuY3kgNTQw MDAwMDAgSHogcXVhbGl0eSAxMDAwCmdwaW9yZWd1bGF0b3IwOiA8R1BJTyBjb250cm9sbGVkIHJl Z3VsYXRvcj4gb24gb2Z3YnVzMApncGlvcmVndWxhdG9yMDogY2Fubm90IGdldCBwaW4gMApncGlv cmVndWxhdG9yMDogY2Fubm90IHBhcnNlIHBhcmFtZXRlcnMKZGV2aWNlX2F0dGFjaDogZ3Bpb3Jl Z3VsYXRvcjAgYXR0YWNoIHJldHVybmVkIDYKY2xrX2ZpeGVkMTQ6IGNsb2NrLWZpeGVkIGhhcyBu byBjbG9jay1mcmVxdWVuY3kKY2xrX2ZpeGVkMTQ6IGNsb2NrLWZpeGVkIGhhcyBubyBjbG9jay1m cmVxdWVuY3kKZ3Bpb3JlZ3VsYXRvcjA6IDxHUElPIGNvbnRyb2xsZWQgcmVndWxhdG9yPiBvbiBv ZndidXMwCmdwaW9yZWd1bGF0b3IwOiBjYW5ub3QgZ2V0IHBpbiAwCmdwaW9yZWd1bGF0b3IwOiBj YW5ub3QgcGFyc2UgcGFyYW1ldGVycwpkZXZpY2VfYXR0YWNoOiBncGlvcmVndWxhdG9yMCBhdHRh Y2ggcmV0dXJuZWQgNgpjbGtfZml4ZWQxNDogY2xvY2stZml4ZWQgaGFzIG5vIGNsb2NrLWZyZXF1 ZW5jeQpjbGtfZml4ZWQxNDogY2xvY2stZml4ZWQgaGFzIG5vIGNsb2NrLWZyZXF1ZW5jeQpncGlv cmVndWxhdG9yMDogPEdQSU8gY29udHJvbGxlZCByZWd1bGF0b3I+IG9uIG9md2J1czAKZ3Bpb3Jl Z3VsYXRvcjA6IGNhbm5vdCBnZXQgcGluIDAKZ3Bpb3JlZ3VsYXRvcjA6IGNhbm5vdCBwYXJzZSBw YXJhbWV0ZXJzCmRldmljZV9hdHRhY2g6IGdwaW9yZWd1bGF0b3IwIGF0dGFjaCByZXR1cm5lZCA2 CmNsa19maXhlZDE0OiBjbG9jay1maXhlZCBoYXMgbm8gY2xvY2stZnJlcXVlbmN5CmNsa19maXhl ZDE0OiBjbG9jay1maXhlZCBoYXMgbm8gY2xvY2stZnJlcXVlbmN5CmdwaW9yZWd1bGF0b3IwOiA8 R1BJTyBjb250cm9sbGVkIHJlZ3VsYXRvcj4gb24gb2Z3YnVzMApncGlvcmVndWxhdG9yMDogY2Fu bm90IGdldCBwaW4gMApncGlvcmVndWxhdG9yMDogY2Fubm90IHBhcnNlIHBhcmFtZXRlcnMKZGV2 aWNlX2F0dGFjaDogZ3Bpb3JlZ3VsYXRvcjAgYXR0YWNoIHJldHVybmVkIDYKY2xrX2ZpeGVkMTQ6 IGNsb2NrLWZpeGVkIGhhcyBubyBjbG9jay1mcmVxdWVuY3kKY2xrX2ZpeGVkMTQ6IGNsb2NrLWZp eGVkIGhhcyBubyBjbG9jay1mcmVxdWVuY3kKZ3Bpb3JlZ3VsYXRvcjA6IDxHUElPIGNvbnRyb2xs ZWQgcmVndWxhdG9yPiBvbiBvZndidXMwCmdwaW9yZWd1bGF0b3IwOiBjYW5ub3QgZ2V0IHBpbiAw CmdwaW9yZWd1bGF0b3IwOiBjYW5ub3QgcGFyc2UgcGFyYW1ldGVycwpkZXZpY2VfYXR0YWNoOiBn cGlvcmVndWxhdG9yMCBhdHRhY2ggcmV0dXJuZWQgNgpjbGtfZml4ZWQxNDogY2xvY2stZml4ZWQg aGFzIG5vIGNsb2NrLWZyZXF1ZW5jeQpjbGtfZml4ZWQxNDogY2xvY2stZml4ZWQgaGFzIG5vIGNs b2NrLWZyZXF1ZW5jeQpncGlvcmVndWxhdG9yMDogPEdQSU8gY29udHJvbGxlZCByZWd1bGF0b3I+ IG9uIG9md2J1czAKZ3Bpb3JlZ3VsYXRvcjA6IGNhbm5vdCBnZXQgcGluIDAKZ3Bpb3JlZ3VsYXRv cjA6IGNhbm5vdCBwYXJzZSBwYXJhbWV0ZXJzCmRldmljZV9hdHRhY2g6IGdwaW9yZWd1bGF0b3Iw IGF0dGFjaCByZXR1cm5lZCA2CmNsa19maXhlZDE0OiBjbG9jay1maXhlZCBoYXMgbm8gY2xvY2st ZnJlcXVlbmN5CmNsa19maXhlZDE0OiBjbG9jay1maXhlZCBoYXMgbm8gY2xvY2stZnJlcXVlbmN5 CmdwaW9yZWd1bGF0b3IwOiA8R1BJTyBjb250cm9sbGVkIHJlZ3VsYXRvcj4gb24gb2Z3YnVzMApn cGlvcmVndWxhdG9yMDogY2Fubm90IGdldCBwaW4gMApncGlvcmVndWxhdG9yMDogY2Fubm90IHBh cnNlIHBhcmFtZXRlcnMKZGV2aWNlX2F0dGFjaDogZ3Bpb3JlZ3VsYXRvcjAgYXR0YWNoIHJldHVy bmVkIDYKY2xrX2ZpeGVkMTQ6IGNsb2NrLWZpeGVkIGhhcyBubyBjbG9jay1mcmVxdWVuY3kKY2xr X2ZpeGVkMTQ6IGNsb2NrLWZpeGVkIGhhcyBubyBjbG9jay1mcmVxdWVuY3kKZ3Bpb3JlZ3VsYXRv cjA6IDxHUElPIGNvbnRyb2xsZWQgcmVndWxhdG9yPiBvbiBvZndidXMwCmdwaW9yZWd1bGF0b3Iw OiBjYW5ub3QgZ2V0IHBpbiAwCmdwaW9yZWd1bGF0b3IwOiBjYW5ub3QgcGFyc2UgcGFyYW1ldGVy cwpkZXZpY2VfYXR0YWNoOiBncGlvcmVndWxhdG9yMCBhdHRhY2ggcmV0dXJuZWQgNgpjbGtfZml4 ZWQxNDogY2xvY2stZml4ZWQgaGFzIG5vIGNsb2NrLWZyZXF1ZW5jeQpjbGtfZml4ZWQxNDogY2xv Y2stZml4ZWQgaGFzIG5vIGNsb2NrLWZyZXF1ZW5jeQpncGlvcmVndWxhdG9yMDogPEdQSU8gY29u dHJvbGxlZCByZWd1bGF0b3I+IG9uIG9md2J1czAKZ3Bpb3JlZ3VsYXRvcjA6IGNhbm5vdCBnZXQg cGluIDAKZ3Bpb3JlZ3VsYXRvcjA6IGNhbm5vdCBwYXJzZSBwYXJhbWV0ZXJzCmRldmljZV9hdHRh Y2g6IGdwaW9yZWd1bGF0b3IwIGF0dGFjaCByZXR1cm5lZCA2CmNsa19maXhlZDE0OiBjbG9jay1m aXhlZCBoYXMgbm8gY2xvY2stZnJlcXVlbmN5CmNsa19maXhlZDE0OiBjbG9jay1maXhlZCBoYXMg bm8gY2xvY2stZnJlcXVlbmN5CmdwaW9yZWd1bGF0b3IwOiA8R1BJTyBjb250cm9sbGVkIHJlZ3Vs YXRvcj4gb24gb2Z3YnVzMApncGlvcmVndWxhdG9yMDogY2Fubm90IGdldCBwaW4gMApncGlvcmVn dWxhdG9yMDogY2Fubm90IHBhcnNlIHBhcmFtZXRlcnMKZGV2aWNlX2F0dGFjaDogZ3Bpb3JlZ3Vs YXRvcjAgYXR0YWNoIHJldHVybmVkIDYKY2xrX2ZpeGVkMTQ6IGNsb2NrLWZpeGVkIGhhcyBubyBj bG9jay1mcmVxdWVuY3kKY2xrX2ZpeGVkMTQ6IGNsb2NrLWZpeGVkIGhhcyBubyBjbG9jay1mcmVx dWVuY3kKdXNiX25vcF94Y2VpdjA6IDxVU0IgTk9QIFBIWT4gb24gb2Z3YnVzMApncGlvcmVndWxh dG9yMDogPEdQSU8gY29udHJvbGxlZCByZWd1bGF0b3I+IG9uIG9md2J1czAKZ3Bpb3JlZ3VsYXRv cjA6IGNhbm5vdCBnZXQgcGluIDAKZ3Bpb3JlZ3VsYXRvcjA6IGNhbm5vdCBwYXJzZSBwYXJhbWV0 ZXJzCmRldmljZV9hdHRhY2g6IGdwaW9yZWd1bGF0b3IwIGF0dGFjaCByZXR1cm5lZCA2CmNsa19m aXhlZDE0OiBjbG9jay1maXhlZCBoYXMgbm8gY2xvY2stZnJlcXVlbmN5CmNsa19maXhlZDE0OiBj bG9jay1maXhlZCBoYXMgbm8gY2xvY2stZnJlcXVlbmN5CmdwaW9yZWd1bGF0b3IwOiA8R1BJTyBj b250cm9sbGVkIHJlZ3VsYXRvcj4gb24gb2Z3YnVzMApncGlvcmVndWxhdG9yMDogY2Fubm90IGdl dCBwaW4gMApncGlvcmVndWxhdG9yMDogY2Fubm90IHBhcnNlIHBhcmFtZXRlcnMKZGV2aWNlX2F0 dGFjaDogZ3Bpb3JlZ3VsYXRvcjAgYXR0YWNoIHJldHVybmVkIDYKY2xrX2ZpeGVkMTQ6IGNsb2Nr LWZpeGVkIGhhcyBubyBjbG9jay1mcmVxdWVuY3kKY2xrX2ZpeGVkMTQ6IGNsb2NrLWZpeGVkIGhh cyBubyBjbG9jay1mcmVxdWVuY3kKZWZpcnRjMDogPEVGSSBSZWFsdGltZSBDbG9jaz4KZWZpcnRj MDogcmVnaXN0ZXJlZCBhcyBhIHRpbWUtb2YtZGF5IGNsb2NrLCByZXNvbHV0aW9uIDEuMDAwMDAw cwpyYW0wOiByZXNlcnZpbmcgbWVtb3J5IHJlZ2lvbjogICAyMTAwMDAtMzA0MDAwMDAKcmFtMDog cmVzZXJ2aW5nIG1lbW9yeSByZWdpb246ICAgMzFlNzQwMDAtMzg0MzAwMDAKcmFtMDogcmVzZXJ2 aW5nIG1lbW9yeSByZWdpb246ICAgMzg0ODAwMDAtMzg0ODIwMDAKcmFtMDogcmVzZXJ2aW5nIG1l bW9yeSByZWdpb246ICAgMzg3NDAwMDAtM2JhMjAwMDAKcmFtMDogcmVzZXJ2aW5nIG1lbW9yeSBy ZWdpb246ICAgM2JhYjAwMDAtM2JhYzAwMDAKcmFtMDogcmVzZXJ2aW5nIG1lbW9yeSByZWdpb246 ICAgM2JiZTAwMDAtM2ZjMDAwMDAKcmFtMDogcmVzZXJ2aW5nIG1lbW9yeSByZWdpb246ICAgNDAw MDAwMDAtMjAwMDAwMDAwCnJhbTA6IHJlc2VydmluZyBleGNsdWRlZCByZWdpb246IDAtN2ZmZmYK cmFtMDogcmVzZXJ2aW5nIGV4Y2x1ZGVkIHJlZ2lvbjogMWQwMDAwLTFlZmZmZgpyYW0wOiByZXNl cnZpbmcgZXhjbHVkZWQgcmVnaW9uOiAzMDQwMDAwMC0zMWU3M2ZmZgpyYW0wOiByZXNlcnZpbmcg ZXhjbHVkZWQgcmVnaW9uOiAzODQzMDAwMC0zODQ3ZmZmZgpyYW0wOiByZXNlcnZpbmcgZXhjbHVk ZWQgcmVnaW9uOiAzODRkMDAwMC0zODczZmZmZgpyYW0wOiByZXNlcnZpbmcgZXhjbHVkZWQgcmVn aW9uOiAzYmEyMDAwMC0zYmFhZmZmZgpyYW0wOiByZXNlcnZpbmcgZXhjbHVkZWQgcmVnaW9uOiAz YmFjMDAwMC0zYmJkZmZmZgpyYW0wOiByZXNlcnZpbmcgZXhjbHVkZWQgcmVnaW9uOiAzZmQxNjAw MC0zZmQxNmZmZgpvZndidXMwOiA8aHZzQDEwN2M1ODAwMDA+IG1lbSAweDEwN2M1ODAwMDAtMHgx MDdjNTk5ZmZmIGlycSAwLDEsMiBkaXNhYmxlZCBjb21wYXQgYnJjbSxiY20yNzEyLWh2cyAobm8g ZHJpdmVyIGF0dGFjaGVkKQpzaW1wbGVidXMwOiA8dGltZXJAN2MwMDMwMDA+IG1lbSAweDdjMDAz MDAwLTB4N2MwMDNmZmYgaXJxIDExLDEyLDEzLDE0IGNvbXBhdCBicmNtLGJjbTI4MzUtc3lzdGVt LXRpbWVyIChubyBkcml2ZXIgYXR0YWNoZWQpCnNpbXBsZWJ1czA6IDxmaXJtd2FyZWttc0A3ZDUw MzAwMD4gbWVtIDB4N2Q1MDMwMDAtMHg3ZDUwMzAxNyBpcnEgMTUgZGlzYWJsZWQgY29tcGF0IHJh c3BiZXJyeXBpLHJwaS1maXJtd2FyZS1rbXMtMjcxMiAobm8gZHJpdmVyIGF0dGFjaGVkKQpzaW1w bGVidXMwOiA8cGl4ZWx2YWx2ZUA3YzQxMDAwMD4gbWVtIDB4N2M0MTAwMDAtMHg3YzQxMDBmZiBp cnEgMTcgZGlzYWJsZWQgY29tcGF0IGJyY20sYmNtMjcxMi1waXhlbHZhbHZlMCAobm8gZHJpdmVy IGF0dGFjaGVkKQpzaW1wbGVidXMwOiA8cGl4ZWx2YWx2ZUA3YzQxMTAwMD4gbWVtIDB4N2M0MTEw MDAtMHg3YzQxMTBmZiBpcnEgMTggZGlzYWJsZWQgY29tcGF0IGJyY20sYmNtMjcxMi1waXhlbHZh bHZlMSAobm8gZHJpdmVyIGF0dGFjaGVkKQpzaW1wbGVidXMwOiA8bW9wQDdjNTAwMDAwPiBtZW0g MHg3YzUwMDAwMC0weDdjNTAwMDI3IGlycSAxOSBkaXNhYmxlZCBjb21wYXQgYnJjbSxiY20yNzEy LW1vcCAobm8gZHJpdmVyIGF0dGFjaGVkKQpzaW1wbGVidXMwOiA8bW9wbGV0QDdjNTAxMDAwPiBt ZW0gMHg3YzUwMTAwMC0weDdjNTAxMDFmIGlycSAyMCBkaXNhYmxlZCBjb21wYXQgYnJjbSxiY20y NzEyLW1vcGxldCAobm8gZHJpdmVyIGF0dGFjaGVkKQpzaW1wbGVidXMwOiA8aW50ZXJydXB0LWNv bnRyb2xsZXJAN2M1MDIwMDA+IG1lbSAweDdjNTAyMDAwLTB4N2M1MDIwMmYgaXJxIDIxIGRpc2Fi bGVkIGNvbXBhdCBicmNtLGJjbTI3MTEtbDItaW50YyAobm8gZHJpdmVyIGF0dGFjaGVkKQpzaW1w bGVidXMwOiA8Y2xvY2tAN2M3MDAwMDA+IG1lbSAweDdjNzAwMDAwLTB4N2M3MDAwMGYgY29tcGF0 IGJyY20sYnJjbTI3MTEtZHZwIChubyBkcml2ZXIgYXR0YWNoZWQpCnNpbXBsZWJ1czA6IDxsb2Nh bF9pbnRjQDdjZDAwMDAwPiBtZW0gMHg3Y2QwMDAwMC0weDdjZDAwMGZmIGNvbXBhdCBicmNtLGJj bTI4MzYtbDEtaW50YyAobm8gZHJpdmVyIGF0dGFjaGVkKQp1YXJ0MDogPFByaW1lQ2VsbCBVQVJU IChQTDAxMSk+IG1lbSAweDdkMDAxMDAwLTB4N2QwMDExZmYgaXJxIDIyIG9uIHNpbXBsZWJ1czAK dWFydDA6IGNvbnNvbGUgKDExNTIwMCxuLDgsMSkKdWFydDA6IGZhc3QgaW50ZXJydXB0CnVhcnQw OiBQUFMgY2FwdHVyZSBtb2RlOiBEQ0QKc2ltcGxlYnVzMDogPHNlcmlhbEA3ZDAwMTQwMD4gbWVt IDB4N2QwMDE0MDAtMHg3ZDAwMTVmZiBpcnEgMjMgZGlzYWJsZWQgY29tcGF0IGFybSxwbDAxMSAo bm8gZHJpdmVyIGF0dGFjaGVkKQpzaW1wbGVidXMwOiA8c2VyaWFsQDdkMDAxNjAwPiBtZW0gMHg3 ZDAwMTYwMC0weDdkMDAxN2ZmIGlycSAyNCBkaXNhYmxlZCBjb21wYXQgYXJtLHBsMDExIChubyBk cml2ZXIgYXR0YWNoZWQpCnNpbXBsZWJ1czA6IDxzZXJpYWxAN2QwMDE4MDA+IG1lbSAweDdkMDAx ODAwLTB4N2QwMDE5ZmYgaXJxIDI1IGRpc2FibGVkIGNvbXBhdCBhcm0scGwwMTEgKG5vIGRyaXZl ciBhdHRhY2hlZCkKc2ltcGxlYnVzMDogPHNlcmlhbEA3ZDAwMWEwMD4gbWVtIDB4N2QwMDFhMDAt MHg3ZDAwMWJmZiBpcnEgMjYgZGlzYWJsZWQgY29tcGF0IGFybSxwbDAxMSAobm8gZHJpdmVyIGF0 dGFjaGVkKQpzaW1wbGVidXMwOiA8bW1jQDdkMDAyMDAwPiBtZW0gMHg3ZDAwMjAwMC0weDdkMDAy MGZmIGRpc2FibGVkIGNvbXBhdCBicmNtLGJjbTI4MzUtc2Rob3N0IChubyBkcml2ZXIgYXR0YWNo ZWQpCnNpbXBsZWJ1czA6IDxfaTJzQDdkMDAzMDAwPiBtZW0gMHg3ZDAwMzAwMC0weDdkMDAzMDIz IGRpc2FibGVkIGNvbXBhdCBicmNtLGJjbTI4MzUtaTJzIChubyBkcml2ZXIgYXR0YWNoZWQpCnNw aTA6IDxCQ00yNzA4LzI4MzUgU1BJIGNvbnRyb2xsZXI+IG1lbSAweDdkMDA0MDAwLTB4N2QwMDQx ZmYgaXJxIDI3IG9uIHNpbXBsZWJ1czAKc3BpYnVzMDogPE9GVyBTUEkgYnVzPiBvbiBzcGkwCnNw aWJ1czA6IDx1bmtub3duIGNhcmQ+IGF0IGNzIDAgbW9kZSAwCnNpbXBsZWJ1czA6IDxzcGlAN2Qw MDQ2MDA+IG1lbSAweDdkMDA0NjAwLTB4N2QwMDQ3ZmYgaXJxIDI4IGRpc2FibGVkIGNvbXBhdCBi cmNtLGJjbTI4MzUtc3BpIChubyBkcml2ZXIgYXR0YWNoZWQpCnNpbXBsZWJ1czA6IDxzcGlAN2Qw MDQ4MDA+IG1lbSAweDdkMDA0ODAwLTB4N2QwMDQ5ZmYgaXJxIDI5IGRpc2FibGVkIGNvbXBhdCBi cmNtLGJjbTI4MzUtc3BpIChubyBkcml2ZXIgYXR0YWNoZWQpCnNpbXBsZWJ1czA6IDxzcGlAN2Qw MDRhMDA+IG1lbSAweDdkMDA0YTAwLTB4N2QwMDRiZmYgaXJxIDMwIGRpc2FibGVkIGNvbXBhdCBi cmNtLGJjbTI4MzUtc3BpIChubyBkcml2ZXIgYXR0YWNoZWQpCnNpbXBsZWJ1czA6IDxzcGlAN2Qw MDRjMDA+IG1lbSAweDdkMDA0YzAwLTB4N2QwMDRkZmYgaXJxIDMxIGRpc2FibGVkIGNvbXBhdCBi cmNtLGJjbTI4MzUtc3BpIChubyBkcml2ZXIgYXR0YWNoZWQpCnNpbXBsZWJ1czA6IDxpMmNAN2Qw MDUwMDA+IG1lbSAweDdkMDA1MDAwLTB4N2QwMDUwMWYgaXJxIDMyIGRpc2FibGVkIGNvbXBhdCBi cmNtLGJjbTI3MTEtaTJjIChubyBkcml2ZXIgYXR0YWNoZWQpCnNpbXBsZWJ1czA6IDxpMmNAN2Qw MDU2MDA+IG1lbSAweDdkMDA1NjAwLTB4N2QwMDU2MWYgaXJxIDMzIGRpc2FibGVkIGNvbXBhdCBi cmNtLGJjbTI3MTEtaTJjIChubyBkcml2ZXIgYXR0YWNoZWQpCnNpbXBsZWJ1czA6IDxpMmNAN2Qw MDU4MDA+IG1lbSAweDdkMDA1ODAwLTB4N2QwMDU4MWYgaXJxIDM0IGRpc2FibGVkIGNvbXBhdCBi cmNtLGJjbTI3MTEtaTJjIChubyBkcml2ZXIgYXR0YWNoZWQpCnNpbXBsZWJ1czA6IDxpMmNAN2Qw MDVhMDA+IG1lbSAweDdkMDA1YTAwLTB4N2QwMDVhMWYgaXJxIDM1IGRpc2FibGVkIGNvbXBhdCBi cmNtLGJjbTI3MTEtaTJjIChubyBkcml2ZXIgYXR0YWNoZWQpCnNpbXBsZWJ1czA6IDxpMmNAN2Qw MDVjMDA+IG1lbSAweDdkMDA1YzAwLTB4N2QwMDVjMWYgaXJxIDM2IGRpc2FibGVkIGNvbXBhdCBi cmNtLGJjbTI3MTEtaTJjIChubyBkcml2ZXIgYXR0YWNoZWQpCnNpbXBsZWJ1czA6IDxpMmNAN2Qw MDVlMDA+IG1lbSAweDdkMDA1ZTAwLTB4N2QwMDVlMWYgaXJxIDM3IGRpc2FibGVkIGNvbXBhdCBi cmNtLGJjbTI3MTEtaTJjIChubyBkcml2ZXIgYXR0YWNoZWQpCnNpbXBsZWJ1czA6IDxwd21AN2Qw MGMwMDA+IG1lbSAweDdkMDBjMDAwLTB4N2QwMGMwMjcgZGlzYWJsZWQgY29tcGF0IGJyY20sYmNt MjgzNS1wd20gKG5vIGRyaXZlciBhdHRhY2hlZCkKc2ltcGxlYnVzMDogPHB3bUA3ZDAwYzgwMD4g bWVtIDB4N2QwMGM4MDAtMHg3ZDAwYzgyNyBkaXNhYmxlZCBjb21wYXQgYnJjbSxiY20yODM1LXB3 bSAobm8gZHJpdmVyIGF0dGFjaGVkKQpzaW1wbGVidXMwOiA8d2F0Y2hkb2dAN2QyMDAwMDA+IG1l bSAweDdkMjAwMDAwLTB4N2QyMDAzMDcgY29tcGF0IGJyY20sYmNtMjcxMi1wbSAobm8gZHJpdmVy IGF0dGFjaGVkKQpzaW1wbGVidXMwOiA8Y3BybWFuQDdkMjAyMDAwPiBtZW0gMHg3ZDIwMjAwMC0w eDdkMjAzZmZmIGRpc2FibGVkIGNvbXBhdCBicmNtLGJjbTI3MTEtY3BybWFuIChubyBkcml2ZXIg YXR0YWNoZWQpCmJjbXJuZzA6IDxCcm9hZGNvbSBCQ00yODM1L0JDTTI4MzggUk5HPiBtZW0gMHg3 ZDIwODAwMC0weDdkMjA4MDI3IG9uIHNpbXBsZWJ1czAKYmNtcm5nMDogc2ltcGxlYnVzMDogPGlu dGNAN2Q1MDMwMDA+IG1lbSAweDdkNTAzMDAwLTB4N2Q1MDMwMTcgaXJxIDM4IGNvbXBhdCBicmNt LGwyLWludGMgKG5vIGRyaXZlciBhdHRhY2hlZCkKc2ltcGxlYnVzMDogPHBpbmN0cmxAN2Q1MDQx MDA+IG1lbSAweDdkNTA0MTAwLTB4N2Q1MDQxMmYgY29tcGF0IGJyY20sYmNtMjcxMi1waW5jdHJs IChubyBkcml2ZXIgYXR0YWNoZWQpCnNpbXBsZWJ1czA6IDxpMmNAN2Q1MDgyMDA+IG1lbSAweDdk NTA4MjAwLTB4N2Q1MDgyNTcgaXJxIDM5IGRpc2FibGVkIGNvbXBhdCBicmNtLGJyY21zdGItaTJj IChubyBkcml2ZXIgYXR0YWNoZWQpCnNpbXBsZWJ1czA6IDxpMmNAN2Q1MDgyODA+IG1lbSAweDdk NTA4MjgwLTB4N2Q1MDgyZDcgaXJxIDQwIGRpc2FibGVkIGNvbXBhdCBicmNtLGJyY21zdGItaTJj IChubyBkcml2ZXIgYXR0YWNoZWQpCnNpbXBsZWJ1czA6IDxpMmNAN2Q1MDgzMDA+IG1lbSAweDdk NTA4MzAwLTB4N2Q1MDgzNTcgaXJxIDQxIGRpc2FibGVkIGNvbXBhdCBicmNtLGJyY21zdGItaTJj IChubyBkcml2ZXIgYXR0YWNoZWQpCnNpbXBsZWJ1czA6IDxpbnRjQDdkNTA4MzgwPiBtZW0gMHg3 ZDUwODM4MC0weDdkNTA4MzhmIGlycSA0MiBjb21wYXQgYnJjbSxiY203MjcxLWwyLWludGMgKG5v IGRyaXZlciBhdHRhY2hlZCkKc2ltcGxlYnVzMDogPGludGNAN2Q1MDg0MDA+IG1lbSAweDdkNTA4 NDAwLTB4N2Q1MDg0MGYgaXJxIDQzIGNvbXBhdCBicmNtLGJjbTcyNzEtbDItaW50YyAobm8gZHJp dmVyIGF0dGFjaGVkKQpzaW1wbGVidXMwOiA8Z3Bpb0A3ZDUwODUwMD4gbWVtIDB4N2Q1MDg1MDAt MHg3ZDUwODUzZiBpcnEgNDQgY29tcGF0IGJyY20sYnJjbXN0Yi1ncGlvIChubyBkcml2ZXIgYXR0 YWNoZWQpCnNpbXBsZWJ1czA6IDxzZXJpYWxAN2Q1MGMwMDA+IG1lbSAweDdkNTBjMDAwLTB4N2Q1 MGMwMWYgaXJxIDQ1IGNvbXBhdCBicmNtLGJjbTcyNzEtdWFydCAobm8gZHJpdmVyIGF0dGFjaGVk KQpzaW1wbGVidXMwOiA8c2VyaWFsQDdkNTBkMDAwPiBtZW0gMHg3ZDUwZDAwMC0weDdkNTBkMDFm IGlycSA0NiBkaXNhYmxlZCBjb21wYXQgYnJjbSxiY203MjcxLXVhcnQgKG5vIGRyaXZlciBhdHRh Y2hlZCkKc2ltcGxlYnVzMDogPHNlcmlhbEA3ZDUwZTAwMD4gbWVtIDB4N2Q1MGUwMDAtMHg3ZDUw ZTAxZiBpcnEgNDcgZGlzYWJsZWQgY29tcGF0IGJyY20sYmNtNzI3MS11YXJ0IChubyBkcml2ZXIg YXR0YWNoZWQpCnNpbXBsZWJ1czA6IDxpbnRlcnJ1cHQtY29udHJvbGxlckA3ZDUxMDYwMD4gbWVt IDB4N2Q1MTA2MDAtMHg3ZDUxMDYyZiBpcnEgNDggZGlzYWJsZWQgY29tcGF0IGJyY20sYmNtMjcx MS1sMi1pbnRjIChubyBkcml2ZXIgYXR0YWNoZWQpCnNpbXBsZWJ1czA6IDxwaW5jdHJsQDdkNTEw NzAwPiBtZW0gMHg3ZDUxMDcwMC0weDdkNTEwNzFmIGNvbXBhdCBicmNtLGJjbTI3MTItYW9uLXBp bmN0cmwgKG5vIGRyaXZlciBhdHRhY2hlZCkKc2ltcGxlYnVzMDogPGludGNAN2Q1MTcwMDA+IG1l bSAweDdkNTE3MDAwLTB4N2Q1MTcwMGYgaXJxIDQ5IGRpc2FibGVkIGNvbXBhdCBicmNtLGJjbTcy NzEtbDItaW50YyAobm8gZHJpdmVyIGF0dGFjaGVkKQpzaW1wbGVidXMwOiA8aTJjQDdkNTE3YTAw PiBtZW0gMHg3ZDUxN2EwMC0weDdkNTE3YTU3IGlycSA1MCBkaXNhYmxlZCBjb21wYXQgYnJjbSxi cmNtc3RiLWkyYyAobm8gZHJpdmVyIGF0dGFjaGVkKQpzaW1wbGVidXMwOiA8cHdtQDdkNTE3YTgw PiBtZW0gMHg3ZDUxN2E4MC0weDdkNTE3YWE3IGNvbXBhdCBicmNtLGJjbTcwMzgtcHdtIChubyBk cml2ZXIgYXR0YWNoZWQpCnNpbXBsZWJ1czA6IDxpbnRjQDdkNTE3YWMwPiBtZW0gMHg3ZDUxN2Fj MC0weDdkNTE3YWNmIGlycSA1MSBkaXNhYmxlZCBjb21wYXQgYnJjbSxiY203MjcxLWwyLWludGMg KG5vIGRyaXZlciBhdHRhY2hlZCkKc2ltcGxlYnVzMDogPGludGNAN2Q1MTdiMDA+IG1lbSAweDdk NTE3YjAwLTB4N2Q1MTdiMGYgaXJxIDUyIGNvbXBhdCBicmNtLGJjbTcyNzEtbDItaW50YyAobm8g ZHJpdmVyIGF0dGFjaGVkKQpzaW1wbGVidXMwOiA8Z3Bpb0A3ZDUxN2MwMD4gbWVtIDB4N2Q1MTdj MDAtMHg3ZDUxN2MzZiBpcnEgNTMgY29tcGF0IGJyY20sYnJjbXN0Yi1ncGlvIChubyBkcml2ZXIg YXR0YWNoZWQpCnNpbXBsZV9tZmQwOiA8dGhlcm1hbD4gbWVtIDB4N2Q1NDIwMDAtMHg3ZDU0MmVm ZiBjb21wYXQgYnJjbSxiY20yNzExLXRoZXJtYWwgKG5vIGRyaXZlciBhdHRhY2hlZCkKc2ltcGxl YnVzMDogPGkyY0A3ZDU0NDAwMD4gbWVtIDB4N2Q1NDQwMDAtMHg3ZDU0NDA1NyBpcnEgNTQgZGlz YWJsZWQgY29tcGF0IGJyY20sYnJjbXN0Yi1pMmMgKG5vIGRyaXZlciBhdHRhY2hlZCkKc2ltcGxl YnVzMDogPGhkbWlAN2VmMDA3MDA+IG1lbSAweDdjNzAxNDAwLTB4N2M3MDE2ZmYsMHg3YzcwMTAw MC0weDdjNzAxMWZmLDB4N2M3MDFkMDAtMHg3YzcwMWZmZiwweDdjNzAyMDAwLTB4N2M3MDIwN2Ys MHg3YzcwMzgwMC0weDdjNzAzOWZmLDB4N2M3MDQwMDAtMHg3YzcwNDdmZiwweDdjNzAwMTAwLTB4 N2M3MDAxN2YsMHg3ZDUxMDgwMC0weDdkNTEwOGZmLDB4N2M3MjAwMDAtMHg3YzcyMDBmZiBpcnEg NTUsNTYsNTcsNTgsNTkgZGlzYWJsZWQgY29tcGF0IGJyY20sYmNtMjcxMi1oZG1pMCAobm8gZHJp dmVyIGF0dGFjaGVkKQpzaW1wbGVidXMwOiA8aGRtaUA3ZWYwNTcwMD4gbWVtIDB4N2M3MDY0MDAt MHg3YzcwNjZmZiwweDdjNzA2MDAwLTB4N2M3MDYxZmYsMHg3YzcwNmQwMC0weDdjNzA2ZmZmLDB4 N2M3MDcwMDAtMHg3YzcwNzA3ZiwweDdjNzA4ODAwLTB4N2M3MDg5ZmYsMHg3YzcwOTAwMC0weDdj NzA5N2ZmLDB4N2M3MDAxODAtMHg3YzcwMDFmZiwweDdkNTExMDAwLTB4N2Q1MTEwZmYsMHg3Yzcy MDAwMC0weDdjNzIwMGZmIGlycSA2MCw2MSw2Miw2Myw2NCBkaXNhYmxlZCBjb21wYXQgYnJjbSxi Y20yNzEyLWhkbWkxIChubyBkcml2ZXIgYXR0YWNoZWQpCmJjbTI4MzVfZmlybXdhcmUwOiA8cmVz ZXQ+IGNvbXBhdCByYXNwYmVycnlwaSxmaXJtd2FyZS1yZXNldCAobm8gZHJpdmVyIGF0dGFjaGVk KQpiY20yODM1X2Zpcm13YXJlMDogPHZjaW8+IGNvbXBhdCByYXNwYmVycnlwaSx2Y2lvIChubyBk cml2ZXIgYXR0YWNoZWQpCnNpbXBsZWJ1czA6IDxwb3dlcj4gY29tcGF0IHJhc3BiZXJyeXBpLGJj bTI4MzUtcG93ZXIgKG5vIGRyaXZlciBhdHRhY2hlZCkKZmIwOiA8QkNNMjgzNSBWVCBmcmFtZWJ1 ZmZlciBkcml2ZXI+IG9uIHNpbXBsZWJ1czAKQ2hlY2tpbmcgcm9vdCBhZ2FpbnN0IHJhc3BiZXJy eXBpLG1vZGVsLWIKQ2hlY2tpbmcgcm9vdCBhZ2FpbnN0IGJyY20sYmNtMjgzNQpDaGVja2luZyBy b290IGFnYWluc3QgYnJjbSxiY20yNzA5CkNoZWNraW5nIHJvb3QgYWdhaW5zdCBicmNtLGJjbTI4 MzYKQ2hlY2tpbmcgcm9vdCBhZ2FpbnN0IGJyY20sYmNtMjgzNwpDaGVja2luZyByb290IGFnYWlu c3QgYnJjbSxiY20yNzExCkNoZWNraW5nIHJvb3QgYWdhaW5zdCBicmNtLGJjbTI4MzgKQ2hlY2tp bmcgcm9vdCBhZ2FpbnN0IGJyY20sYmNtMjcxMgpmYjA6IGNoYW5naW5nIGZiIGJwcCBmcm9tIDAg dG8gMjQKbWJveDA6IG1ib3ggcmVzcG9uc2UgZXJyb3IKZmIwOiBiY20yODM1X21ib3hfZmJfaW5p dCBmYWlsZWQsIGVycj01CmRldmljZV9hdHRhY2g6IGZiMCBhdHRhY2ggcmV0dXJuZWQgNgpzaW1w bGVidXMwOiA8cnBpX3J0Yz4gY29tcGF0IHJhc3BiZXJyeXBpLHJwaS1ydGMgKG5vIGRyaXZlciBh dHRhY2hlZCkKc2ltcGxlYnVzMDogPGdwaW9tZW1AN2Q1MDg1MDA+IG1lbSAweDdkNTA4NTAwLTB4 N2Q1MDg1M2YgY29tcGF0IHJhc3BiZXJyeXBpLGdwaW9tZW0gKG5vIGRyaXZlciBhdHRhY2hlZCkK c2ltcGxlYnVzMDogPGdwaW9tZW1AN2Q1MTdjMDA+IG1lbSAweDdkNTE3YzAwLTB4N2Q1MTdjM2Yg Y29tcGF0IHJhc3BiZXJyeXBpLGdwaW9tZW0gKG5vIGRyaXZlciBhdHRhY2hlZCkKc2ltcGxlYnVz MDogPGdwaW9tZW1AN2Q1MDQxMDA+IG1lbSAweDdkNTA0MTAwLTB4N2Q1MDQxMWYgY29tcGF0IHJh c3BiZXJyeXBpLGdwaW9tZW0gKG5vIGRyaXZlciBhdHRhY2hlZCkKc2ltcGxlYnVzMDogPGdwaW9t ZW1AN2Q1MTA3MDA+IG1lbSAweDdkNTEwNzAwLTB4N2Q1MTA3MWYgY29tcGF0IHJhc3BiZXJyeXBp LGdwaW9tZW0gKG5vIGRyaXZlciBhdHRhY2hlZCkKcG11MDogPFBlcmZvcm1hbmNlIE1vbml0b3Jp bmcgVW5pdD4gaXJxIDMsNCw1LDYgb24gb2Z3YnVzMApvZndidXMwOiBubyBkZWZhdWx0IHJlc291 cmNlcyBmb3IgcmlkID0gNCwgdHlwZSA9IDEKY3B1bGlzdDA6IDxPcGVuIEZpcm13YXJlIENQVSBH cm91cD4gb24gb2Z3YnVzMApjcHUwOiA8T3BlbiBGaXJtd2FyZSBDUFU+IG9uIGNwdWxpc3QwCmNw dTA6IG1pc3NpbmcgJ2Nsb2NrLWZyZXF1ZW5jeScgcHJvcGVydHkKY3B1MTogPE9wZW4gRmlybXdh cmUgQ1BVPiBvbiBjcHVsaXN0MApjcHUxOiBtaXNzaW5nICdjbG9jay1mcmVxdWVuY3knIHByb3Bl cnR5CmNwdTI6IDxPcGVuIEZpcm13YXJlIENQVT4gb24gY3B1bGlzdDAKY3B1MjogbWlzc2luZyAn Y2xvY2stZnJlcXVlbmN5JyBwcm9wZXJ0eQpjcHUzOiA8T3BlbiBGaXJtd2FyZSBDUFU+IG9uIGNw dWxpc3QwCmNwdTM6IG1pc3NpbmcgJ2Nsb2NrLWZyZXF1ZW5jeScgcHJvcGVydHkKc2ltcGxlYnVz MTogPGdwdT4gY29tcGF0IGJyY20sYmNtMjcxMi12YzYgKG5vIGRyaXZlciBhdHRhY2hlZCkKc2lt cGxlYnVzMTogPGlvbW11QDUxMDA+IG1lbSAweDEwMDAwMDUxMDAtMHgxMDAwMDA1MTdmIGNvbXBh dCBicmNtLGJjbTI3MTItaW9tbXUgKG5vIGRyaXZlciBhdHRhY2hlZCkKc2ltcGxlYnVzMTogPGlv bW11QDUyMDA+IG1lbSAweDEwMDAwMDUyMDAtMHgxMDAwMDA1MjdmIGNvbXBhdCBicmNtLGJjbTI3 MTItaW9tbXUgKG5vIGRyaXZlciBhdHRhY2hlZCkKc2ltcGxlYnVzMTogPGlvbW11QDUyODA+IG1l bSAweDEwMDAwMDUyODAtMHgxMDAwMDA1MmZmIGNvbXBhdCBicmNtLGJjbTI3MTItaW9tbXUgKG5v IGRyaXZlciBhdHRhY2hlZCkKc2ltcGxlYnVzMTogPGlvbW11Y0A1YjAwPiBtZW0gMHgxMDAwMDA1 YjAwLTB4MTAwMDAwNWI3ZiBjb21wYXQgYnJjbSxiY20yNzEyLWlvbW11YyAobm8gZHJpdmVyIGF0 dGFjaGVkKQpzaW1wbGVidXMxOiA8ZG1hQDEwMDAwPiBtZW0gMHgxMDAwMDEwMDAwLTB4MTAwMDAx MDVmZiBpcnEgNjUsNjYsNjcsNjgsNjksNzAgY29tcGF0IGJyY20sYmNtMjcxMi1kbWEgKG5vIGRy aXZlciBhdHRhY2hlZCkKc2ltcGxlYnVzMTogPGRtYUAxMDYwMD4gbWVtIDB4MTAwMDAxMDYwMC0w eDEwMDAwMTBiZmYgaXJxIDcxLDcyLDczLDc0LDc1LDc2IGNvbXBhdCBicmNtLGJjbTI3MTItZG1h IChubyBkcml2ZXIgYXR0YWNoZWQpCnNpbXBsZWJ1czE6IDxwY2llQDEwMDAwMD4gbWVtIDB4MTAw MDEwMDAwMC0weDEwMDAxMDkzMGYgaXJxIDc3LDc4IGRpc2FibGVkIHR5cGUgcGNpIGNvbXBhdCBi cmNtLGJjbTI3MTItcGNpZSAobm8gZHJpdmVyIGF0dGFjaGVkKQpzaW1wbGVidXMxOiA8cGNpZUAx MTAwMDA+IG1lbSAweDEwMDAxMTAwMDAtMHgxMDAwMTE5MzBmIGlycSA3OSw4MCBkaXNhYmxlZCB0 eXBlIHBjaSBjb21wYXQgYnJjbSxiY20yNzEyLXBjaWUgKG5vIGRyaXZlciBhdHRhY2hlZCkKc2lt cGxlYnVzMTogPHJlc2V0LWNvbnRyb2xsZXJAMTE5NTAwPiBtZW0gMHgxMDAwMTE5NTAwLTB4MTAw MDExOTUwZiBjb21wYXQgYnJjbSxiY203MjE2LXBjaWUtc2F0YS1yZXNjYWwgKG5vIGRyaXZlciBh dHRhY2hlZCkKc2ltcGxlYnVzMTogPHBjaWVAMTIwMDAwPiBtZW0gMHgxMDAwMTIwMDAwLTB4MTAw MDEyOTMwZiBpcnEgODEsODIgdHlwZSBwY2kgY29tcGF0IGJyY20sYmNtMjcxMi1wY2llIChubyBk cml2ZXIgYXR0YWNoZWQpCnNpbXBsZWJ1czE6IDxtc2ktY29udHJvbGxlckAxMzAwMDA+IG1lbSAw eDEwMDAxMzAwMDAtMHgxMDAwMTMwMGJmIGNvbXBhdCBicmNtLGJjbTI3MTItbWlwLWludGMgKG5v IGRyaXZlciBhdHRhY2hlZCkKc2ltcGxlYnVzMTogPG1zaS1jb250cm9sbGVyQDEzMTAwMD4gbWVt IDB4MTAwMDEzMTAwMC0weDEwMDAxMzEwYmYgY29tcGF0IGJyY20sYmNtMjcxMi1taXAtaW50YyAo bm8gZHJpdmVyIGF0dGFjaGVkKQpzaW1wbGVidXMxOiA8ZXRoZXJuZXRAMTMwMDAwMD4gbWVtIDB4 MTAwMTMwMDAwMC0weDEwMDEzMjAwMGYgaXJxIDgzLDg0IGRpc2FibGVkIHR5cGUgbmV0d29yayBj b21wYXQgYnJjbSxiY20yNzExLWdlbmV0LXY1IChubyBkcml2ZXIgYXR0YWNoZWQpCnNpbXBsZWJ1 czE6IDx1c2JANDgwMDAwPiBtZW0gMHgxMDAwNDgwMDAwLTB4MTAwMDQ4ZmZmZiBpcnEgODUgZGlz YWJsZWQgY29tcGF0IGJyY20sYmNtMjgzNS11c2IgKG5vIGRyaXZlciBhdHRhY2hlZCkKc2ltcGxl YnVzMTogPGNvZGVjQDgwMDAwMD4gbWVtIDB4MTAwMDgwMDAwMC0weDEwMDA4MGZmZmYsMHgxMDAw ODQwMDAwLTB4MTAwMDg0MGZmZiBpcnEgODYgY29tcGF0IHJhc3BiZXJyeXBpLHJwaXZpZC12aWQt ZGVjb2RlciAobm8gZHJpdmVyIGF0dGFjaGVkKQpzZGhjaV9mZHQwOiA8Z2VuZXJpYyBmZHQgU0RI Q0kgY29udHJvbGxlcj4gbWVtIDB4MTAwMGZmZjAwMC0weDEwMDBmZmYyNWYsMHgxMDAwZmZmNDAw LTB4MTAwMGZmZjVmZiwweDEwMDE1MDQwYjAtMHgxMDAxNTA0MGIzLDB4MTAwMTUyMDBmMC0weDEw MDE1MjAxMTMgaXJxIDg3IG9uIHNpbXBsZWJ1czEKc2RoY2lfZmR0MC1zbG90MDogMjAwTUh6IDRi aXRzIFZERDogVkNDUTogMy4zViBEUlY6IEJBQ0QgRE1BIHJlbW92YWJsZQpzZGhjaV9mZHQwLXNs b3QwOiA9PT09PT09PT09PT09PSBSRUdJU1RFUiBEVU1QID09PT09PT09PT09PT09CnNkaGNpX2Zk dDAtc2xvdDA6IFN5cyBhZGRyOiAweDAwMDAwMDAwIHwgVmVyc2lvbjogIDB4MDAwMDEwMDIKc2Ro Y2lfZmR0MC1zbG90MDogQmxrIHNpemU6IDB4MDAwMDAyMDAgfCBCbGsgY250OiAgMHgwMDAwMDAw MQpzZGhjaV9mZHQwLXNsb3QwOiBBcmd1bWVudDogMHgwNDQ4NGI1OCB8IFRybiBtb2RlOiAweDAw MDAwMDExCnNkaGNpX2ZkdDAtc2xvdDA6IFByZXNlbnQ6ICAweDFmZmYwMDAwIHwgSG9zdCBjdGw6 IDB4MDAwMDAwMWEKc2RoY2lfZmR0MC1zbG90MDogUG93ZXI6ICAgIDB4MDAwMDAwMGYgfCBCbGsg Z2FwOiAgMHgwMDAwMDA4MApzZGhjaV9mZHQwLXNsb3QwOiBXYWtlLXVwOiAgMHgwMDAwMDAwMCB8 IENsb2NrOiAgICAweDAwMDAwMDA3CnNkaGNpX2ZkdDAtc2xvdDA6IFRpbWVvdXQ6ICAweDAwMDAw MDBlIHwgSW50IHN0YXQ6IDB4MDAwMDAwMDAKc2RoY2lfZmR0MC1zbG90MDogSW50IGVuYWI6IDB4 NzdmZjdmZmYgfCBTaWcgZW5hYjogMHgwMDAwMDAwMApzZGhjaV9mZHQwLXNsb3QwOiBBQzEyIGVy cjogMHgwMDAwMDAwMCB8IEhvc3QgY3RsMjoweDAwMDAwMDhiCnNkaGNpX2ZkdDAtc2xvdDA6IENh cHM6ICAgICAweDE1ZWFjODMyIHwgQ2FwczI6ICAgIDB4ODAwMGE1NzcKc2RoY2lfZmR0MC1zbG90 MDogTWF4IGN1cnI6IDB4MDAwODAwMDggfCBBRE1BIGVycjogMHgwMDAwMDAwMApzZGhjaV9mZHQw LXNsb3QwOiBBRE1BIGFkZHI6MHgzYTNiYzAwYyB8IFNsb3QgaW50OiAweDAwMDAwMDAwCnNkaGNp X2ZkdDAtc2xvdDA6ID09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0K c2RoY2lfZmR0MDogMSBzbG90KHMpIGFsbG9jYXRlZApzZGhjaV9mZHQwLXNsb3QwOiBDYXJkIGlu c2VydGVkCm1tYzA6IDxNTUMvU0QgYnVzPiBvbiBzZGhjaV9mZHQwCnNkaGNpX2ZkdDE6IDxnZW5l cmljIGZkdCBTREhDSSBjb250cm9sbGVyPiBtZW0gMHgxMDAxMTAwMDAwLTB4MTAwMTEwMDI1Ziww eDEwMDExMDA0MDAtMHgxMDAxMTAwNWZmIGlycSA4OCBvbiBzaW1wbGVidXMxCnNkaGNpX2ZkdDEt c2xvdDA6IDIwME1IeiA4Yml0cyBWREQ6IFZDQ1E6IDMuM1YgRFJWOiBCQyBETUEgZW1iZWRkZWQK c2RoY2lfZmR0MS1zbG90MDogPT09PT09PT09PT09PT0gUkVHSVNURVIgRFVNUCA9PT09PT09PT09 PT09PQpzZGhjaV9mZHQxLXNsb3QwOiBTeXMgYWRkcjogMHgwMDAwMDAwMCB8IFZlcnNpb246ICAw eDAwMDAxMDAyCnNkaGNpX2ZkdDEtc2xvdDA6IEJsayBzaXplOiAweDAwMDAwMDAwIHwgQmxrIGNu dDogIDB4MDAwMDAwMDAKc2RoY2lfZmR0MS1zbG90MDogQXJndW1lbnQ6IDB4MDAwMDAwMDAgfCBU cm4gbW9kZTogMHgwMDAwMDAwMApzZGhjaV9mZHQxLXNsb3QwOiBQcmVzZW50OiAgMHgwMWZmMDAw MCB8IEhvc3QgY3RsOiAweDAwMDAwMDAwCnNkaGNpX2ZkdDEtc2xvdDA6IFBvd2VyOiAgICAweDAw MDAwMDAwIHwgQmxrIGdhcDogIDB4MDAwMDAwODAKc2RoY2lfZmR0MS1zbG90MDogV2FrZS11cDog IDB4MDAwMDAwMDAgfCBDbG9jazogICAgMHgwMDAwMDAwMApzZGhjaV9mZHQxLXNsb3QwOiBUaW1l b3V0OiAgMHgwMDAwMDAwMCB8IEludCBzdGF0OiAweDAwMDAwMDAwCnNkaGNpX2ZkdDEtc2xvdDA6 IEludCBlbmFiOiAweDAwMDAwMDAwIHwgU2lnIGVuYWI6IDB4MDAwMDAwMDAKc2RoY2lfZmR0MS1z bG90MDogQUMxMiBlcnI6IDB4MDAwMDAwMDAgfCBIb3N0IGN0bDI6MHgwMDAwMDAwMApzZGhjaV9m ZHQxLXNsb3QwOiBDYXBzOiAgICAgMHg1NWVlYzgzMiB8IENhcHMyOiAgICAweDgwMDBhNTI3CnNk aGNpX2ZkdDEtc2xvdDA6IE1heCBjdXJyOiAweDAwMDgwMDA4IHwgQURNQSBlcnI6IDB4MDAwMDAw MDAKc2RoY2lfZmR0MS1zbG90MDogQURNQSBhZGRyOjB4MDAwMDAwMDAgfCBTbG90IGludDogMHgw MDAwMDAwMApzZGhjaV9mZHQxLXNsb3QwOiA9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09CnNkaGNpX2ZkdDE6IDEgc2xvdChzKSBhbGxvY2F0ZWQKc2RoY2lfZmR0MS1z bG90MDogQ2FyZCBpbnNlcnRlZAptbWMxOiA8TU1DL1NEIGJ1cz4gb24gc2RoY2lfZmR0MQpzaW1w bGVidXMxOiA8bW1jQDExMDgwMDA+IG1lbSAweDEwMDExMDgwMDAtMHgxMDAxMTA4MGZmIGlycSA4 OSBkaXNhYmxlZCBjb21wYXQgYnJjbSxiY20yNzExLWVtbWMyIChubyBkcml2ZXIgYXR0YWNoZWQp CnNpbXBsZWJ1czE6IDxyZXNldC1jb250cm9sbGVyQDE1MDQzMTg+IG1lbSAweDEwMDE1MDQzMTgt MHgxMDAxNTA0MzQ3IGNvbXBhdCBicmNtLGJyY21zdGItcmVzZXQgKG5vIGRyaXZlciBhdHRhY2hl ZCkKc2ltcGxlYnVzMTogPHYzZEAyMDAwMDAwPiBtZW0gMHgxMDAyMDAwMDAwLTB4MTAwMjAwM2Zm ZiwweDEwMDIwMDgwMDAtMHgxMDAyMDBkZmZmIGlycSA5MCw5MSBkaXNhYmxlZCBjb21wYXQgYnJj bSwyNzEyLXYzZCAobm8gZHJpdmVyIGF0dGFjaGVkKQpzaW1wbGVidXMxOiA8cGlzcF9iZUA4ODAw MDA+IG1lbSAweDEwMDA4ODAwMDAtMHgxMDAwODgzZmZmIGlycSA5MyBjb21wYXQgcmFzcGJlcnJ5 cGkscGlzcGJlIChubyBkcml2ZXIgYXR0YWNoZWQpCmdwaW9sZWQwOiA8R1BJTyBMRURzPiBvbiBv ZndidXMwCmdwaW9sZWQwOiA8UFdSPiBmYWlsZWQgdG8gbWFwIHBpbgpncGlvbGVkMDogPEFDVD4g ZmFpbGVkIHRvIG1hcCBwaW4KZ3Bpb3JlZ3VsYXRvcjA6IDxHUElPIGNvbnRyb2xsZWQgcmVndWxh dG9yPiBvbiBvZndidXMwCmdwaW9yZWd1bGF0b3IwOiBjYW5ub3QgZ2V0IHBpbiAwCmdwaW9yZWd1 bGF0b3IwOiBjYW5ub3QgcGFyc2UgcGFyYW1ldGVycwpkZXZpY2VfYXR0YWNoOiBncGlvcmVndWxh dG9yMCBhdHRhY2ggcmV0dXJuZWQgNgpjbGtfZml4ZWQxNDogY2xvY2stZml4ZWQgaGFzIG5vIGNs b2NrLWZyZXF1ZW5jeQpvZndidXMwOiA8Y2FtMV9jbGs+IGRpc2FibGVkIGNvbXBhdCBmaXhlZC1j bG9jayAobm8gZHJpdmVyIGF0dGFjaGVkKQpjbGtfZml4ZWQxNDogY2xvY2stZml4ZWQgaGFzIG5v IGNsb2NrLWZyZXF1ZW5jeQpvZndidXMwOiA8Y2FtMF9jbGs+IGRpc2FibGVkIGNvbXBhdCBmaXhl ZC1jbG9jayAobm8gZHJpdmVyIGF0dGFjaGVkKQpvZndidXMwOiA8Y29vbGluZ19mYW4+IGNvbXBh dCBwd20tZmFuIChubyBkcml2ZXIgYXR0YWNoZWQpCm9md2J1czA6IDxwd3JfYnV0dG9uPiBjb21w YXQgZ3Bpby1rZXlzIChubyBkcml2ZXIgYXR0YWNoZWQpCmNyeXB0bzogYXNzaWduIGNyeXB0b3Nv ZnQwIGRyaXZlciBpZCAwLCBmbGFncyAweDYwMDAwMDAKYXJtdjhjcnlwdG8wOiA8QUVTLUNCQyxB RVMtWFRTLEFFUy1HQ00+CmNyeXB0bzogYXNzaWduIGFybXY4Y3J5cHRvMCBkcml2ZXIgaWQgMSwg ZmxhZ3MgMHhlMDAwMDAwCkRldmljZSBjb25maWd1cmF0aW9uIGZpbmlzaGVkLgpwcm9jZnMgcmVn aXN0ZXJlZApUaW1lY291bnRlcnMgdGljayBldmVyeSAxLjAwMCBtc2VjClpGUyBmaWxlc3lzdGVt IHZlcnNpb246IDUKWkZTIHN0b3JhZ2UgcG9vbCB2ZXJzaW9uOiBmZWF0dXJlcyBzdXBwb3J0ICg1 MDAwKQpsbzA6IGJwZiBhdHRhY2hlZAp2bGFuOiBpbml0aWFsaXplZCwgdXNpbmcgaGFzaCB0YWJs ZXMgd2l0aCBjaGFpbmluZwpjcnlwdG86IDxjcnlwdG8gZGV2aWNlPgpJUHNlYzogSW5pdGlhbGl6 ZWQgU2VjdXJpdHkgQXNzb2NpYXRpb24gUHJvY2Vzc2luZy4KdGNwX2luaXQ6IG5ldC5pbmV0LnRj cC50Y2JoYXNoc2l6ZSBhdXRvIHR1bmVkIHRvIDY1NTM2CnVzYl9uZWVkc19leHBsb3JlX2FsbDog bm8gZGV2Y2xhc3MKc2RoY2lfZmR0MC1zbG90MDogRGl2aWRlciAyNTAgZm9yIGZyZXEgNDAwMDAw IChiYXNlIDIwMDAwMDAwMCkKbW1jMDogUHJvYmluZyBidXMKbW1jMDogU0QgMi4wIGludGVyZmFj ZSBjb25kaXRpb25zOiBPSwptbWMwOiBTRCBwcm9iZTogT0sgKE9DUjogMHgwMGZmODAwMCkKbW1j MDogQ3VycmVudCBPQ1I6IDB4MDBmZjgwMDAKbW1jMDogUHJvYmluZyBjYXJkcwptbWMwOiBOZXcg Y2FyZCBkZXRlY3RlZCAoQ0lEIFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYKQptbWMw OiBOZXcgY2FyZCBkZXRlY3RlZCAoQ1NEIFlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZ KQptbWMwOiBDYXJkIGF0IHJlbGF0aXZlIGFkZHJlc3MgMHg1MDQ4IGFkZGVkOgptbWMwOiAgY2Fy ZDogU0RIQyBTRDEyOCA4LjUgU04gWlpaWlpaWlogTUZHIDEwLzIwMjMgYnkgMyBTRAptbWMwOiAg cXVpcmtzOiAwCm1tYzA6ICBidXM6IDRiaXQsIDUwTUh6IChoaWdoIHNwZWVkIHRpbWluZykKbW1j MDogIG1lbW9yeTogMjQ5ODcyMzg0IGJsb2NrcywgZXJhc2Ugc2VjdG9yIDgxOTIgYmxvY2tzCm1t YzA6IHNldHRpbmcgdHJhbnNmZXIgcmF0ZSB0byA1MC4wMDBNSHogKGhpZ2ggc3BlZWQgdGltaW5n KQpzZGhjaV9mZHQwLXNsb3QwOiBEaXZpZGVyIDIgZm9yIGZyZXEgNTAwMDAwMDAgKGJhc2UgMjAw MDAwMDAwKQptbWNzZDA6IDEyOEdCIDxTREhDIFNEMTI4IDguNSBTTiBaWlpaWlpaWiBNRkcgMTAv MjAyMyBieSAzIFNEPiBhdCBtbWMwIDUwLjBNSHovNGJpdC82NTUzNS1ibG9jawpzZGhjaV9mZHQx LXNsb3QwOiBEaXZpZGVyIDI1MCBmb3IgZnJlcSA0MDAwMDAgKGJhc2UgMjAwMDAwMDAwKQptbWMx OiBQcm9iaW5nIGJ1cwpHRU9NOiBuZXcgZGlzayBtbWNzZDAKbW1jMDogc2V0dGluZyBidXMgd2lk dGggdG8gNCBiaXRzIGhpZ2ggc3BlZWQgdGltaW5nCm1tYzE6IFNEIHByb2JlOiBmYWlsZWQKbW1j MTogTU1DIHByb2JlOiBmYWlsZWQKbW1jMTogQ3VycmVudCBPQ1I6IDB4MDAwMDAwMDAKbW1jMTog Tm8gY29tcGF0aWJsZSBjYXJkcyBmb3VuZCBvbiBidXMKVHJ5aW5nIHRvIG1vdW50IHJvb3QgZnJv bSB6ZnM6enJvb3QvUk9PVC9kZWZhdWx0IFtdLi4uCkNQVSAgMDogQVJNIENvcnRleC1BNzYgcjRw MSBhZmZpbml0eTogIDAgIDAKICAgICAgICAgICAgICAgICAgIENhY2hlIFR5cGUgPSA8NjQgYnl0 ZSBELWNhY2hlbGluZSw2NCBieXRlIEktY2FjaGVsaW5lLFBJUFQgSUNhY2hlLDY0IGJ5dGUgRVJH LDY0IGJ5dGUgQ1dHLElEQz4KIEluc3RydWN0aW9uIFNldCBBdHRyaWJ1dGVzIDAgPSA8RFAsUkRN LEF0b21pYyxDUkMzMixTSEEyLFNIQTEsQUVTK1BNVUxMPgogSW5zdHJ1Y3Rpb24gU2V0IEF0dHJp YnV0ZXMgMSA9IDxSQ1BDLTguMyxEQ1BvUD4KIEluc3RydWN0aW9uIFNldCBBdHRyaWJ1dGVzIDIg PSA8PgogICAgICAgICBQcm9jZXNzb3IgRmVhdHVyZXMgMCA9IDxDU1YzLENTVjIsUkFTLEFkdlNJ TUQrSFAsRlArSFAsRUwzLEVMMixFTDEsRUwwIDMyPgogICAgICAgICBQcm9jZXNzb3IgRmVhdHVy ZXMgMSA9IDxQU1RBVEUuU1NCUz4KICAgICAgTWVtb3J5IE1vZGVsIEZlYXR1cmVzIDAgPSA8VEdy YW40LFRHcmFuNjQsVEdyYW4xNixTTlNNZW0sQmlnRW5kLDE2Yml0IEFTSUQsMVRCIFBBPgogICAg ICBNZW1vcnkgTW9kZWwgRmVhdHVyZXMgMSA9IDxYTlgsUEFOK0FUUzFFMSxMTyxIUEQrVFRQQkhB LFZILDE2Yml0IFZNSUQsSEFGK0RTPgogICAgICBNZW1vcnkgTW9kZWwgRmVhdHVyZXMgMiA9IDwz MmJpdCBDQ0lEWCw0OGJpdCBWQSxJRVNCLFVBTyxDblA+CiAgICAgICAgICAgICBEZWJ1ZyBGZWF0 dXJlcyAwID0gPERvdWJsZUxvY2ssMiBDVFggQktQVHMsNCBXYXRjaHBvaW50cyw2IEJyZWFrcG9p bnRzLFBNVXYzcDEsRGVidWd2OHAyPgogICAgICAgICAgICAgRGVidWcgRmVhdHVyZXMgMSA9IDw+ CiAgICAgICAgIEF1eGlsaWFyeSBGZWF0dXJlcyAwID0gPD4KICAgICAgICAgQXV4aWxpYXJ5IEZl YXR1cmVzIDEgPSA8PgpBQXJjaDMyIEluc3RydWN0aW9uIFNldCBBdHRyaWJ1dGVzIDUgPSA8UkRN LENSQzMyLFNIQTIsU0hBMSxBRVMrVk1VTEwsU0VWTD4KQUFyY2gzMiBNZWRpYSBhbmQgVkZQIEZl YXR1cmVzIDAgPSA8RlBSb3VuZCxGUFNxcnQsRlBEaXZpZGUsRFAgVkZQdjMrdjQsU1AgVkZQdjMr djQsQWR2U0lNRD4KQUFyY2gzMiBNZWRpYSBhbmQgVkZQIEZlYXR1cmVzIDEgPSA8U0lNREZNQUMs RlBIUCBBcml0aCxTSU1ESFAgQXJpdGgsU0lNRFNQLFNJTURJbnQsU0lNRExTLEZQRE5hTixGUEZ0 Wj4KIEwxIGNhY2hlOiA2NEtCIChpbnN0cnVjdGlvbiksIDY0S0IgKGRhdGEpCiBMMiBjYWNoZTog NTEyS0IgKHVuaWZpZWQpCiBMMyBjYWNoZTogMjA0OEtCICh1bmlmaWVkKQpDUFUgIDE6IEFSTSBD b3J0ZXgtQTc2IHI0cDEgYWZmaW5pdHk6ICAxICAwCiBMMSBjYWNoZTogNjRLQiAoaW5zdHJ1Y3Rp b24pLCA2NEtCIChkYXRhKQogTDIgY2FjaGU6IDUxMktCICh1bmlmaWVkKQogTDMgY2FjaGU6IDIw NDhLQiAodW5pZmllZCkKQ1BVICAyOiBBUk0gQ29ydGV4LUE3NiByNHAxIGFmZmluaXR5OiAgMiAg MAogTDEgY2FjaGU6IDY0S0IgKGluc3RydWN0aW9uKSwgNjRLQiAoZGF0YSkKIEwyIGNhY2hlOiA1 MTJLQiAodW5pZmllZCkKIEwzIGNhY2hlOiAyMDQ4S0IgKHVuaWZpZWQpCkNQVSAgMzogQVJNIENv cnRleC1BNzYgcjRwMSBhZmZpbml0eTogIDMgIDAKIEwxIGNhY2hlOiA2NEtCIChpbnN0cnVjdGlv biksIDY0S0IgKGRhdGEpCiBMMiBjYWNoZTogNTEyS0IgKHVuaWZpZWQpCiBMMyBjYWNoZTogMjA0 OEtCICh1bmlmaWVkKQpSZWxlYXNlIEFQcy4uLmRvbmUKRW5hYmxpbmcgQ25QClRDUF9yYXRlbGlt aXQ6IElzIG5vdyBpbml0aWFsaXplZApyZWd1bGF0b3I6IHNodXR0aW5nIGRvd24gdW51c2VkIHJl Z3VsYXRvcnMKcmVndWxhdG9yOiBzaHV0dGluZyBkb3duIHZjYy1zZC4uLiBHRU9NX1BBUlQ6IHBh cnRpdGlvbiAxIG9uIChtbWNzZDAsIEdQVCkgaXMgbm90IGFsaWduZWQgb24gNDE5NDMwNCBieXRl cwpvawpHRU9NX1BBUlQ6IHBhcnRpdGlvbiAyIG9uIChtbWNzZDAsIEdQVCkgaXMgbm90IGFsaWdu ZWQgb24gNDE5NDMwNCBieXRlcwpyZWd1bGF0b3I6IHNodXR0aW5nIGRvd24gY2FtLWR1bW15LXJl Zy4uLiBHRU9NX1BBUlQ6IHBhcnRpdGlvbiAzIG9uIChtbWNzZDAsIEdQVCkgaXMgbm90IGFsaWdu ZWQgb24gNDE5NDMwNCBieXRlcwpvawplZmlydGMwOiBwcm92aWRpbmcgaW5pdGlhbCBzeXN0ZW0g dGltZQpzdGFydF9pbml0OiB0cnlpbmcgL3NiaW4vaW5pdApMTzA6IGxpbmsgc3RhdGUgY2hhbmdl ZCB0byBVUAo= --0000000000001e2b12060ee8371c-- From nobody Sun Jan 14 13:58:20 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TCcLZ2cjBz56DX1 for ; Sun, 14 Jan 2024 13:58:30 +0000 (UTC) (envelope-from dfr@rabson.org) Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) (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 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TCcLZ0NSlz59H2 for ; Sun, 14 Jan 2024 13:58:30 +0000 (UTC) (envelope-from dfr@rabson.org) Authentication-Results: mx1.freebsd.org; none Received: by mail-qk1-x72f.google.com with SMTP id af79cd13be357-7833b6bb41bso334332585a.3 for ; Sun, 14 Jan 2024 05:58:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rabson-org.20230601.gappssmtp.com; s=20230601; t=1705240709; x=1705845509; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=d/FCc9mRqKJd4KiR5cIvzLAPx9zDZI4sj0C/5ffyRuU=; b=vY0aZELOpWzSB8msxIHqEthSH0S0faVSpt+sOwtFBXa4M8DBZCpGGwnqZQ5kX5rt8v /Ou0Z6nHZUJnvus3qTbnoFQSSPIa5MmohTQWzVvfAN/ffXEoADANMbUyK3HH7jFZOHoQ o86i8CXJknc2KM4kVRCBHpVDoaMFwAkRR9mUhE6Ykzr+VDuAmTr8cieaV5s1rw3BgQKh UET4uR7HMbYpb+NvNKQHz3HEi5w833GvYJcCBXex/girWozAbdLlfd7afbk7MeCbnVsW Pk0Pa/ec9MP75l61qCTdSFuf/VIe0bwtYMWO30No/k5iVy6Il0++jvj+Ckbg7y8RdKvr RumA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705240709; x=1705845509; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=d/FCc9mRqKJd4KiR5cIvzLAPx9zDZI4sj0C/5ffyRuU=; b=YjeqD3UUhyGRzuHzZ78lYfVrGMYrT/FE+m3ppJalhuef3A40c5wH0Xhyg+z2i4kKR7 JJZHKy2GNfcpgwB429FA+AAcF5zHI0YfawOTNiKxvYgSCtRCE8GFkQvsCDE4n14qpY/9 P9PPW6aaAAUtT1H06cDP29dA6/dbEgkYk62LoPltWexAytzEUcHw8uDBm1dr2I7jj2qh 1a5UlUzWrGbxp6UbVCr40cpuexAMgrcKITHXNSLWRfFAROb6Z82y0HScf/7fUDcgSwUu AVwflyEEZSXrPvlGIPvo0eD69GZoK0tLgF3iOX2yR12DCn3ZMyPaXI8IbNtWl24D/tlx 35JA== X-Gm-Message-State: AOJu0YxSEjejcdzm6iWujqyIAADbSOBgnHMrrJ09yw84K3iZrHm0ik69 /mxruNr/toKnTUiQK1RUwboIxv8e0fWUOg4EPWPXXouiJwUYSA== X-Google-Smtp-Source: AGHT+IFkBEyqLQ0z/wD2RNVX191wd5XdMBXSo2GpXmbaZxylVxnE38Hczz6Fn5g6+I3Lk1UYyrzpkO57xXc3E3/bMWc= X-Received: by 2002:ae9:e915:0:b0:783:47b:b1d1 with SMTP id x21-20020ae9e915000000b00783047bb1d1mr4943298qkf.115.1705240708974; Sun, 14 Jan 2024 05:58:28 -0800 (PST) List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 References: <00474FCE-E6FA-4112-B7C3-D4FA83410474.ref@yahoo.com> <00474FCE-E6FA-4112-B7C3-D4FA83410474@yahoo.com> In-Reply-To: <00474FCE-E6FA-4112-B7C3-D4FA83410474@yahoo.com> From: Doug Rabson Date: Sun, 14 Jan 2024 13:58:20 +0000 Message-ID: Subject: Re: RPi5 via EDK2 sitting idle: eventually got various "/: inode ???: check-hash failed" and . . . To: Mark Millard Cc: FreeBSD ARM List , Mike Karels Content-Type: multipart/alternative; boundary="000000000000b72340060ee84a68" X-Rspamd-Queue-Id: 4TCcLZ0NSlz59H2 X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] --000000000000b72340060ee84a68 Content-Type: text/plain; charset="UTF-8" On Sat, 13 Jan 2024 at 19:43, Mark Millard wrote: > I left the RPi5 booted but idle and had not looked at it > since. Well, I just looked and /var/log/messages shows: > > . . . > Jan 11 05:11:32 R64-RPi-4-3-2v1p2 dhclient[2256]: New IP Address (ue0): > 192.168.1.153 > Jan 11 05:11:32 R64-RPi-4-3-2v1p2 dhclient[2260]: New Subnet Mask (ue0): > 255.255.255.0 > Jan 11 05:11:32 R64-RPi-4-3-2v1p2 dhclient[2264]: New Broadcast Address > (ue0): 192.168.1.255 > Jan 11 05:11:32 R64-RPi-4-3-2v1p2 dhclient[2268]: New Routers (ue0): > 192.168.1.1 > Jan 12 03:01:43 R64-RPi-4-3-2v1p2 kernel: /: inode 901792: check-hash > failed > Jan 12 03:01:43 R64-RPi-4-3-2v1p2 syslogd: last message repeated 1 times > Jan 12 03:01:43 R64-RPi-4-3-2v1p2 kernel: /: inode 901812: check-hash > failed > Jan 12 03:01:43 R64-RPi-4-3-2v1p2 syslogd: last message repeated 1 times > Jan 12 03:01:43 R64-RPi-4-3-2v1p2 kernel: /: inode 901796: check-hash > failed > Jan 12 03:01:43 R64-RPi-4-3-2v1p2 syslogd: last message repeated 1 times > Jan 12 03:01:43 R64-RPi-4-3-2v1p2 kernel: /: inode 901808: check-hash > failed > Jan 12 03:01:43 R64-RPi-4-3-2v1p2 syslogd: last message repeated 1 times > Jan 12 03:01:43 R64-RPi-4-3-2v1p2 kernel: /: inode 901821: check-hash > failed > Jan 12 03:01:43 R64-RPi-4-3-2v1p2 syslogd: last message repeated 1 times > . . . > Jan 12 03:03:16 R64-RPi-4-3-2v1p2 kernel: /: inode 85979160: check-hash > failed > Jan 12 03:03:16 R64-RPi-4-3-2v1p2 syslogd: last message repeated 1 times > Jan 12 03:03:16 R64-RPi-4-3-2v1p2 kernel: /: inode 85979164: check-hash > failed > Jan 12 03:03:16 R64-RPi-4-3-2v1p2 syslogd: last message repeated 1 times > Jan 12 03:03:16 R64-RPi-4-3-2v1p2 kernel: /: inode 85979163: check-hash > failed > Jan 12 03:03:16 R64-RPi-4-3-2v1p2 syslogd: last message repeated 1 times > Jan 12 03:03:16 R64-RPi-4-3-2v1p2 kernel: /: inode 85979154: check-hash > failed > Jan 12 03:03:16 R64-RPi-4-3-2v1p2 syslogd: last message repeated 1 times > Jan 12 03:03:16 R64-RPi-4-3-2v1p2 kernel: /: inode 85979159: check-hash > failed > Jan 12 03:03:16 R64-RPi-4-3-2v1p2 syslogd: last message repeated 1 times > Jan 13 03:01:42 R64-RPi-4-3-2v1p2 kernel: /: inode 901792: check-hash > failed > Jan 13 03:01:42 R64-RPi-4-3-2v1p2 syslogd: last message repeated 1 times > Jan 13 03:01:42 R64-RPi-4-3-2v1p2 kernel: /: inode 901793: check-hash > failed > Jan 13 03:01:42 R64-RPi-4-3-2v1p2 syslogd: last message repeated 1 times > Jan 13 03:01:42 R64-RPi-4-3-2v1p2 kernel: /: inode 901809: check-hash > failed > Jan 13 03:01:42 R64-RPi-4-3-2v1p2 syslogd: last message repeated 1 times > Jan 13 03:01:42 R64-RPi-4-3-2v1p2 kernel: /: inode 901812: check-hash > failed > Jan 13 03:01:42 R64-RPi-4-3-2v1p2 syslogd: last message repeated 1 times > Jan 13 03:01:42 R64-RPi-4-3-2v1p2 kernel: /: inode 901794: check-hash > failed > Jan 13 03:01:42 R64-RPi-4-3-2v1p2 syslogd: last message repeated 1 times > Jan 13 03:01:42 R64-RPi-4-3-2v1p2 kernel: /: inode 901795: check-hash > failed > Jan 13 03:01:42 R64-RPi-4-3-2v1p2 syslogd: last message repeated 1 times > Jan 13 03:01:42 R64-RPi-4-3-2v1p2 kernel: /: inode 901796: check-hash > failed > Jan 13 03:01:42 R64-RPi-4-3-2v1p2 syslogd: last message repeated 1 times > Jan 13 03:01:42 R64-RPi-4-3-2v1p2 kernel: /: inode 901797: check-hash > failed > Jan 13 03:01:42 R64-RPi-4-3-2v1p2 syslogd: last message repeated 1 times > Jan 13 03:01:42 R64-RPi-4-3-2v1p2 kernel: /: inode 901798: check-hash > failed > Jan 13 03:01:42 R64-RPi-4-3-2v1p2 syslogd: last message repeated 1 times > . . . > Jan 13 03:03:18 R64-RPi-4-3-2v1p2 kernel: /: inode 85979163: check-hash > failed > Jan 13 03:03:18 R64-RPi-4-3-2v1p2 syslogd: last message repeated 1 times > Jan 13 03:03:18 R64-RPi-4-3-2v1p2 kernel: /: inode 85979154: check-hash > failed > Jan 13 03:03:18 R64-RPi-4-3-2v1p2 syslogd: last message repeated 1 times > Jan 13 03:03:18 R64-RPi-4-3-2v1p2 kernel: /: inode 85979155: check-hash > failed > Jan 13 03:03:18 R64-RPi-4-3-2v1p2 syslogd: last message repeated 1 times > Jan 13 03:03:18 R64-RPi-4-3-2v1p2 kernel: /: inode 85979158: check-hash > failed > Jan 13 03:03:18 R64-RPi-4-3-2v1p2 syslogd: last message repeated 1 times > Jan 13 03:03:18 R64-RPi-4-3-2v1p2 kernel: /: inode 85979159: check-hash > failed > Jan 13 03:03:18 R64-RPi-4-3-2v1p2 syslogd: last message repeated 1 times > Jan 13 03:05:19 R64-RPi-4-3-2v1p2 kernel: /: bad dir ino 67307605 at > offset 0: mangled entry > Jan 13 03:05:19 R64-RPi-4-3-2v1p2 syslogd: last message repeated 1 > timesJan 13 03:05:19 R64-RPi-4-3-2v1p2 kernel: /: bad dir ino 71554318 at > offset 512: mangled entry > Jan 13 03:05:19 R64-RPi-4-3-2v1p2 kernel: /: bad dir ino 71554318 at > offset 512: mangled entry > Jan 13 03:05:19 R64-RPi-4-3-2v1p2 kernel: /: bad dir ino 71554318 at > offset 8: mangled entry > Jan 13 03:05:19 R64-RPi-4-3-2v1p2 kernel: /: bad dir ino 71554318 at > offset 512: mangled entry > Jan 13 03:05:19 R64-RPi-4-3-2v1p2 kernel: /: bad dir ino 71554318 at > offset 8: mangled entry > Jan 13 03:05:19 R64-RPi-4-3-2v1p2 kernel: /: bad dir ino 71554318 at > offset 512: mangled entry > Jan 13 03:05:19 R64-RPi-4-3-2v1p2 kernel: /: bad dir ino 71554318 at > offset 8: mangled entry > Jan 13 03:05:19 R64-RPi-4-3-2v1p2 kernel: /: bad dir ino 71554318 at > offset 512: mangled entry > Jan 13 03:05:19 R64-RPi-4-3-2v1p2 kernel: /: bad dir ino 71554318 at > offset 8: mangled entry > Jan 13 03:05:19 R64-RPi-4-3-2v1p2 kernel: /: bad dir ino 71554318 at > offset 512: mangled entry > Jan 13 03:05:19 R64-RPi-4-3-2v1p2 kernel: /: bad dir ino 71554318 at > offset 8: mangled entry > Jan 13 03:05:19 R64-RPi-4-3-2v1p2 kernel: /: bad dir ino 71554318 at > offset 512: mangled entry > Jan 13 03:05:19 R64-RPi-4-3-2v1p2 kernel: /: bad dir ino 71554318 at > offset 8: mangled entry > Jan 13 03:05:19 R64-RPi-4-3-2v1p2 kernel: /: bad dir ino 71554318 at > offset 512: mangled entry > Jan 13 03:05:19 R64-RPi-4-3-2v1p2 kernel: /: bad dir ino 71554318 at > offset 8: mangled entry > Jan 13 03:05:19 R64-RPi-4-3-2v1p2 kernel: /: bad dir ino 71554318 at > offset 512: mangled entry > Jan 13 03:05:19 R64-RPi-4-3-2v1p2 kernel: /: bad dir ino 71554318 at > offset 8: mangled entry > Jan 13 03:05:19 R64-RPi-4-3-2v1p2 kernel: /: bad dir ino 71554318 at > offset 512: mangled entry > Jan 13 03:05:19 R64-RPi-4-3-2v1p2 kernel: /: bad dir ino 71554318 at > offset 8: mangled entry > Jan 13 03:05:19 R64-RPi-4-3-2v1p2 kernel: /: bad dir ino 71554318 at > offset 512: mangled entry > Jan 13 03:05:19 R64-RPi-4-3-2v1p2 kernel: /: bad dir ino 71554318 at > offset 8: mangled entry > Jan 13 03:05:19 R64-RPi-4-3-2v1p2 kernel: /: bad dir ino 71554318 at > offset 512: mangled entry > Jan 13 03:05:19 R64-RPi-4-3-2v1p2 kernel: /: bad dir ino 71554318 at > offset 8: mangled entry > Jan 13 03:05:19 R64-RPi-4-3-2v1p2 kernel: /: bad dir ino 71554318 at > offset 512: mangled entry > Jan 13 03:05:19 R64-RPi-4-3-2v1p2 kernel: /: bad dir ino 71554318 at > offset 8: mangled entry > Jan 13 03:05:19 R64-RPi-4-3-2v1p2 kernel: /: bad dir ino 71554318 at > offset 512: mangled entry > Jan 13 03:05:20 R64-RPi-4-3-2v1p2 kernel: /: bad dir ino 71554318 at > offset 8: mangled entry > Jan 13 03:05:20 R64-RPi-4-3-2v1p2 kernel: /: bad dir ino 71554318 at > offset 512: mangled entry > Jan 13 03:05:20 R64-RPi-4-3-2v1p2 kernel: /: bad dir ino 71554318 at > offset 8: mangled entry > Jan 13 03:05:20 R64-RPi-4-3-2v1p2 kernel: /: bad dir ino 71554318 at > offset 512: mangled entry > Jan 13 03:05:20 R64-RPi-4-3-2v1p2 kernel: /: bad dir ino 71554318 at > offset 8: mangled entry > Jan 13 03:05:20 R64-RPi-4-3-2v1p2 kernel: /: bad dir ino 71554318 at > offset 512: mangled entry > Jan 13 03:05:20 R64-RPi-4-3-2v1p2 kernel: /: bad dir ino 71554318 at > offset 8: mangled entry > Jan 13 03:05:20 R64-RPi-4-3-2v1p2 kernel: /: bad dir ino 71554318 at > offset 512: mangled entry > Jan 13 03:05:20 R64-RPi-4-3-2v1p2 kernel: /: bad dir ino 71554318 at > offset 8: mangled entry > Jan 13 04:15:42 R64-RPi-4-3-2v1p2 kernel: /: inode 901792: check-hash > failed > Jan 13 04:15:42 R64-RPi-4-3-2v1p2 syslogd: last message repeated 1 times > Jan 13 04:15:42 R64-RPi-4-3-2v1p2 kernel: /: inode 901793: check-hash > failed > Jan 13 04:15:42 R64-RPi-4-3-2v1p2 syslogd: last message repeated 1 times > Jan 13 04:15:42 R64-RPi-4-3-2v1p2 kernel: /: inode 901809: check-hash > failed > Jan 13 04:15:42 R64-RPi-4-3-2v1p2 syslogd: last message repeated 1 times > Jan 13 04:15:42 R64-RPi-4-3-2v1p2 kernel: /: inode 901812: check-hash > failed > Jan 13 04:15:42 R64-RPi-4-3-2v1p2 syslogd: last message repeated 1 times > Jan 13 04:15:42 R64-RPi-4-3-2v1p2 kernel: /: inode 901794: check-hash > failed > Jan 13 04:15:42 R64-RPi-4-3-2v1p2 syslogd: last message repeated 1 times > . . . > Jan 13 04:15:45 R64-RPi-4-3-2v1p2 syslogd: last message repeated 1 times > Jan 13 04:15:45 R64-RPi-4-3-2v1p2 kernel: /: inode 85979159: check-hash > failed > Jan 13 04:15:45 R64-RPi-4-3-2v1p2 syslogd: last message repeated 1 times > Jan 13 04:16:04 R64-RPi-4-3-2v1p2 kernel: /: inode 91271591: check-hash > failed > Jan 13 04:16:04 R64-RPi-4-3-2v1p2 syslogd: last message repeated 1 times > Jan 13 04:16:04 R64-RPi-4-3-2v1p2 kernel: /: inode 91271627: check-hash > failed > Jan 13 04:16:04 R64-RPi-4-3-2v1p2 syslogd: last message repeated 1 times > > # uptime > 10:53AM up 2 days, 17:42, 2 users, load averages: 0.22, 0.23, 0.18 > > Unfortunately, this is my build, not an official snapshot test: > > # uname -apKU > FreeBSD R64-RPi-4-3-2v1p2 15.0-CURRENT FreeBSD 15.0-CURRENT #100 > main-n266876-e183039f0882-dirty: Sat Dec 9 08:18:38 UTC 2023 > root@CA72-16Gp-ZFS:/usr/obj/BUILDs/main-CA53-nodbg-clang/usr/main-src/arm64.aarch64/sys/GENERIC-NODBG-CA53 > arm64 aarch64 1500006 1500006 > > . . . > So I've since rebooted the RPi5 with: > > # uname -apKU > FreeBSD generic 15.0-CURRENT FreeBSD 15.0-CURRENT #0 > main-n267507-a61d2c7fbd3c: Thu Jan 11 06:26:30 UTC 2024 > root@releng3.nyi.freebsd.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC > arm64 aarch64 1500008 1500008 > > to see how it does. Technically the USB3 media has the Rock64 > snapshot with the msdosfs material copied over from the rpi-arm64 > snapshot. But the microsd card has the EDK2 that is used. > I'm not sure if its related to your USB storage problem but I did notice that at least one USB device in my setup disconnects and reconnects every couple of minutes: Jan 14 13:54:32 freebsd14-rpi5 kernel: ugen0.4: at usbus0 (disconnected) Jan 14 13:54:32 freebsd14-rpi5 kernel: ums0: at uhub2, port 4, addr 3 (disconnected) Jan 14 13:54:32 freebsd14-rpi5 kernel: ums0: detached Jan 14 13:54:34 freebsd14-rpi5 kernel: ugen0.4: at usbus0 Jan 14 13:54:34 freebsd14-rpi5 kernel: ums0 on uhub2 Jan 14 13:54:34 freebsd14-rpi5 kernel: ums0: on usbus0 Jan 14 13:54:34 freebsd14-rpi5 kernel: ums0: 3 buttons and [XYZ] coordinates ID=0 Jan 14 13:55:34 freebsd14-rpi5 kernel: ugen0.4: at usbus0 (disconnected) Jan 14 13:55:34 freebsd14-rpi5 kernel: ums0: at uhub2, port 4, addr 3 (disconnected) Jan 14 13:55:34 freebsd14-rpi5 kernel: ums0: detached Jan 14 13:55:36 freebsd14-rpi5 kernel: ugen0.4: at usbus0 Jan 14 13:55:36 freebsd14-rpi5 kernel: ums0 on uhub2 Jan 14 13:55:36 freebsd14-rpi5 kernel: ums0: on usbus0 Jan 14 13:55:36 freebsd14-rpi5 kernel: ums0: 3 buttons and [XYZ] coordinates ID=0 --000000000000b72340060ee84a68 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sat, 13 Jan 2024 at 19:43, Mark Mi= llard <marklmi@yahoo.com> wr= ote:
I left the=C2=A0 RPi5 booted but idle and ha= d not looked at it
since. Well, I just looked and /var/log/messages shows:

. . .
Jan 11 05:11:32 R64-RPi-4-3-2v1p2 dhclient[2256]: New IP Address (ue0): 192= .168.1.153
Jan 11 05:11:32 R64-RPi-4-3-2v1p2 dhclient[2260]: New Subnet Mask (ue0): 25= 5.255.255.0
Jan 11 05:11:32 R64-RPi-4-3-2v1p2 dhclient[2264]: New Broadcast Address (ue= 0): 192.168.1.255
Jan 11 05:11:32 R64-RPi-4-3-2v1p2 dhclient[2268]: New Routers (ue0): 192.16= 8.1.1
Jan 12 03:01:43 R64-RPi-4-3-2v1p2 kernel: /: inode 901792: check-hash faile= d
Jan 12 03:01:43 R64-RPi-4-3-2v1p2 syslogd: last message repeated 1 times Jan 12 03:01:43 R64-RPi-4-3-2v1p2 kernel: /: inode 901812: check-hash faile= d
Jan 12 03:01:43 R64-RPi-4-3-2v1p2 syslogd: last message repeated 1 times Jan 12 03:01:43 R64-RPi-4-3-2v1p2 kernel: /: inode 901796: check-hash faile= d
Jan 12 03:01:43 R64-RPi-4-3-2v1p2 syslogd: last message repeated 1 times Jan 12 03:01:43 R64-RPi-4-3-2v1p2 kernel: /: inode 901808: check-hash faile= d
Jan 12 03:01:43 R64-RPi-4-3-2v1p2 syslogd: last message repeated 1 times Jan 12 03:01:43 R64-RPi-4-3-2v1p2 kernel: /: inode 901821: check-hash faile= d
Jan 12 03:01:43 R64-RPi-4-3-2v1p2 syslogd: last message repeated 1 times . . .
Jan 12 03:03:16 R64-RPi-4-3-2v1p2 kernel: /: inode 85979160: check-hash fai= led
Jan 12 03:03:16 R64-RPi-4-3-2v1p2 syslogd: last message repeated 1 times Jan 12 03:03:16 R64-RPi-4-3-2v1p2 kernel: /: inode 85979164: check-hash fai= led
Jan 12 03:03:16 R64-RPi-4-3-2v1p2 syslogd: last message repeated 1 times Jan 12 03:03:16 R64-RPi-4-3-2v1p2 kernel: /: inode 85979163: check-hash fai= led
Jan 12 03:03:16 R64-RPi-4-3-2v1p2 syslogd: last message repeated 1 times Jan 12 03:03:16 R64-RPi-4-3-2v1p2 kernel: /: inode 85979154: check-hash fai= led
Jan 12 03:03:16 R64-RPi-4-3-2v1p2 syslogd: last message repeated 1 times Jan 12 03:03:16 R64-RPi-4-3-2v1p2 kernel: /: inode 85979159: check-hash fai= led
Jan 12 03:03:16 R64-RPi-4-3-2v1p2 syslogd: last message repeated 1 times Jan 13 03:01:42 R64-RPi-4-3-2v1p2 kernel: /: inode 901792: check-hash faile= d
Jan 13 03:01:42 R64-RPi-4-3-2v1p2 syslogd: last message repeated 1 times Jan 13 03:01:42 R64-RPi-4-3-2v1p2 kernel: /: inode 901793: check-hash faile= d
Jan 13 03:01:42 R64-RPi-4-3-2v1p2 syslogd: last message repeated 1 times Jan 13 03:01:42 R64-RPi-4-3-2v1p2 kernel: /: inode 901809: check-hash faile= d
Jan 13 03:01:42 R64-RPi-4-3-2v1p2 syslogd: last message repeated 1 times Jan 13 03:01:42 R64-RPi-4-3-2v1p2 kernel: /: inode 901812: check-hash faile= d
Jan 13 03:01:42 R64-RPi-4-3-2v1p2 syslogd: last message repeated 1 times Jan 13 03:01:42 R64-RPi-4-3-2v1p2 kernel: /: inode 901794: check-hash faile= d
Jan 13 03:01:42 R64-RPi-4-3-2v1p2 syslogd: last message repeated 1 times Jan 13 03:01:42 R64-RPi-4-3-2v1p2 kernel: /: inode 901795: check-hash faile= d
Jan 13 03:01:42 R64-RPi-4-3-2v1p2 syslogd: last message repeated 1 times Jan 13 03:01:42 R64-RPi-4-3-2v1p2 kernel: /: inode 901796: check-hash faile= d
Jan 13 03:01:42 R64-RPi-4-3-2v1p2 syslogd: last message repeated 1 times Jan 13 03:01:42 R64-RPi-4-3-2v1p2 kernel: /: inode 901797: check-hash faile= d
Jan 13 03:01:42 R64-RPi-4-3-2v1p2 syslogd: last message repeated 1 times Jan 13 03:01:42 R64-RPi-4-3-2v1p2 kernel: /: inode 901798: check-hash faile= d
Jan 13 03:01:42 R64-RPi-4-3-2v1p2 syslogd: last message repeated 1 times . . .
Jan 13 03:03:18 R64-RPi-4-3-2v1p2 kernel: /: inode 85979163: check-hash fai= led
Jan 13 03:03:18 R64-RPi-4-3-2v1p2 syslogd: last message repeated 1 times Jan 13 03:03:18 R64-RPi-4-3-2v1p2 kernel: /: inode 85979154: check-hash fai= led
Jan 13 03:03:18 R64-RPi-4-3-2v1p2 syslogd: last message repeated 1 times Jan 13 03:03:18 R64-RPi-4-3-2v1p2 kernel: /: inode 85979155: check-hash fai= led
Jan 13 03:03:18 R64-RPi-4-3-2v1p2 syslogd: last message repeated 1 times Jan 13 03:03:18 R64-RPi-4-3-2v1p2 kernel: /: inode 85979158: check-hash fai= led
Jan 13 03:03:18 R64-RPi-4-3-2v1p2 syslogd: last message repeated 1 times Jan 13 03:03:18 R64-RPi-4-3-2v1p2 kernel: /: inode 85979159: check-hash fai= led
Jan 13 03:03:18 R64-RPi-4-3-2v1p2 syslogd: last message repeated 1 times Jan 13 03:05:19 R64-RPi-4-3-2v1p2 kernel: /: bad dir ino 67307605 at offset= 0: mangled entry
Jan 13 03:05:19 R64-RPi-4-3-2v1p2 syslogd: last message repeated 1 timesJan= 13 03:05:19 R64-RPi-4-3-2v1p2 kernel: /: bad dir ino 71554318 at offset 51= 2: mangled entry
Jan 13 03:05:19 R64-RPi-4-3-2v1p2 kernel: /: bad dir ino 71554318 at offset= 512: mangled entry
Jan 13 03:05:19 R64-RPi-4-3-2v1p2 kernel: /: bad dir ino 71554318 at offset= 8: mangled entry
Jan 13 03:05:19 R64-RPi-4-3-2v1p2 kernel: /: bad dir ino 71554318 at offset= 512: mangled entry
Jan 13 03:05:19 R64-RPi-4-3-2v1p2 kernel: /: bad dir ino 71554318 at offset= 8: mangled entry
Jan 13 03:05:19 R64-RPi-4-3-2v1p2 kernel: /: bad dir ino 71554318 at offset= 512: mangled entry
Jan 13 03:05:19 R64-RPi-4-3-2v1p2 kernel: /: bad dir ino 71554318 at offset= 8: mangled entry
Jan 13 03:05:19 R64-RPi-4-3-2v1p2 kernel: /: bad dir ino 71554318 at offset= 512: mangled entry
Jan 13 03:05:19 R64-RPi-4-3-2v1p2 kernel: /: bad dir ino 71554318 at offset= 8: mangled entry
Jan 13 03:05:19 R64-RPi-4-3-2v1p2 kernel: /: bad dir ino 71554318 at offset= 512: mangled entry
Jan 13 03:05:19 R64-RPi-4-3-2v1p2 kernel: /: bad dir ino 71554318 at offset= 8: mangled entry
Jan 13 03:05:19 R64-RPi-4-3-2v1p2 kernel: /: bad dir ino 71554318 at offset= 512: mangled entry
Jan 13 03:05:19 R64-RPi-4-3-2v1p2 kernel: /: bad dir ino 71554318 at offset= 8: mangled entry
Jan 13 03:05:19 R64-RPi-4-3-2v1p2 kernel: /: bad dir ino 71554318 at offset= 512: mangled entry
Jan 13 03:05:19 R64-RPi-4-3-2v1p2 kernel: /: bad dir ino 71554318 at offset= 8: mangled entry
Jan 13 03:05:19 R64-RPi-4-3-2v1p2 kernel: /: bad dir ino 71554318 at offset= 512: mangled entry
Jan 13 03:05:19 R64-RPi-4-3-2v1p2 kernel: /: bad dir ino 71554318 at offset= 8: mangled entry
Jan 13 03:05:19 R64-RPi-4-3-2v1p2 kernel: /: bad dir ino 71554318 at offset= 512: mangled entry
Jan 13 03:05:19 R64-RPi-4-3-2v1p2 kernel: /: bad dir ino 71554318 at offset= 8: mangled entry
Jan 13 03:05:19 R64-RPi-4-3-2v1p2 kernel: /: bad dir ino 71554318 at offset= 512: mangled entry
Jan 13 03:05:19 R64-RPi-4-3-2v1p2 kernel: /: bad dir ino 71554318 at offset= 8: mangled entry
Jan 13 03:05:19 R64-RPi-4-3-2v1p2 kernel: /: bad dir ino 71554318 at offset= 512: mangled entry
Jan 13 03:05:19 R64-RPi-4-3-2v1p2 kernel: /: bad dir ino 71554318 at offset= 8: mangled entry
Jan 13 03:05:19 R64-RPi-4-3-2v1p2 kernel: /: bad dir ino 71554318 at offset= 512: mangled entry
Jan 13 03:05:19 R64-RPi-4-3-2v1p2 kernel: /: bad dir ino 71554318 at offset= 8: mangled entry
Jan 13 03:05:19 R64-RPi-4-3-2v1p2 kernel: /: bad dir ino 71554318 at offset= 512: mangled entry
Jan 13 03:05:20 R64-RPi-4-3-2v1p2 kernel: /: bad dir ino 71554318 at offset= 8: mangled entry
Jan 13 03:05:20 R64-RPi-4-3-2v1p2 kernel: /: bad dir ino 71554318 at offset= 512: mangled entry
Jan 13 03:05:20 R64-RPi-4-3-2v1p2 kernel: /: bad dir ino 71554318 at offset= 8: mangled entry
Jan 13 03:05:20 R64-RPi-4-3-2v1p2 kernel: /: bad dir ino 71554318 at offset= 512: mangled entry
Jan 13 03:05:20 R64-RPi-4-3-2v1p2 kernel: /: bad dir ino 71554318 at offset= 8: mangled entry
Jan 13 03:05:20 R64-RPi-4-3-2v1p2 kernel: /: bad dir ino 71554318 at offset= 512: mangled entry
Jan 13 03:05:20 R64-RPi-4-3-2v1p2 kernel: /: bad dir ino 71554318 at offset= 8: mangled entry
Jan 13 03:05:20 R64-RPi-4-3-2v1p2 kernel: /: bad dir ino 71554318 at offset= 512: mangled entry
Jan 13 03:05:20 R64-RPi-4-3-2v1p2 kernel: /: bad dir ino 71554318 at offset= 8: mangled entry
Jan 13 04:15:42 R64-RPi-4-3-2v1p2 kernel: /: inode 901792: check-hash faile= d
Jan 13 04:15:42 R64-RPi-4-3-2v1p2 syslogd: last message repeated 1 times Jan 13 04:15:42 R64-RPi-4-3-2v1p2 kernel: /: inode 901793: check-hash faile= d
Jan 13 04:15:42 R64-RPi-4-3-2v1p2 syslogd: last message repeated 1 times Jan 13 04:15:42 R64-RPi-4-3-2v1p2 kernel: /: inode 901809: check-hash faile= d
Jan 13 04:15:42 R64-RPi-4-3-2v1p2 syslogd: last message repeated 1 times Jan 13 04:15:42 R64-RPi-4-3-2v1p2 kernel: /: inode 901812: check-hash faile= d
Jan 13 04:15:42 R64-RPi-4-3-2v1p2 syslogd: last message repeated 1 times Jan 13 04:15:42 R64-RPi-4-3-2v1p2 kernel: /: inode 901794: check-hash faile= d
Jan 13 04:15:42 R64-RPi-4-3-2v1p2 syslogd: last message repeated 1 times . . .
Jan 13 04:15:45 R64-RPi-4-3-2v1p2 syslogd: last message repeated 1 times Jan 13 04:15:45 R64-RPi-4-3-2v1p2 kernel: /: inode 85979159: check-hash fai= led
Jan 13 04:15:45 R64-RPi-4-3-2v1p2 syslogd: last message repeated 1 times Jan 13 04:16:04 R64-RPi-4-3-2v1p2 kernel: /: inode 91271591: check-hash fai= led
Jan 13 04:16:04 R64-RPi-4-3-2v1p2 syslogd: last message repeated 1 times Jan 13 04:16:04 R64-RPi-4-3-2v1p2 kernel: /: inode 91271627: check-hash fai= led
Jan 13 04:16:04 R64-RPi-4-3-2v1p2 syslogd: last message repeated 1 times
# uptime
10:53AM=C2=A0 up 2 days, 17:42, 2 users, load averages: 0.22, 0.23, 0.18
Unfortunately, this is my build, not an official snapshot test:

# uname -apKU
FreeBSD R64-RPi-4-3-2v1p2 15.0-CURRENT FreeBSD 15.0-CURRENT #100 main-n2668= 76-e183039f0882-dirty: Sat Dec=C2=A0 9 08:18:38 UTC 2023=C2=A0 =C2=A0 =C2= =A0root@CA72-16Gp-ZFS:/usr/obj/BUILDs/main-CA53-nodbg-clang/usr/main-src/ar= m64.aarch64/sys/GENERIC-NODBG-CA53 arm64 aarch64 1500006 1500006

. . .
So I've since rebooted the RPi5 with:

# uname -apKU
FreeBSD generic 15.0-CURRENT FreeBSD 15.0-CURRENT #0 main-n267507-a61d2c7fb= d3c: Thu Jan 11 06:26:30 UTC 2024=C2=A0 =C2=A0 =C2=A0root@releng3.nyi.freeb= sd.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC arm64 aarch64 1500008 150= 0008

to see how it does. Technically the=C2=A0 USB3 media has the Rock64
snapshot with the msdosfs material copied over from the rpi-arm64
snapshot. But the microsd card has the EDK2 that is used.
<= div>
I'm not sure if its related to your USB storage prob= lem but I did notice that at least one USB device in my setup disconnects a= nd reconnects every couple of minutes:

Jan 14 13:5= 4:32 freebsd14-rpi5 kernel: ugen0.4: <PixArt USB Optical Mouse> at us= bus0 (disconnected)
Jan 14 13:54:32 freebsd14-rpi5 kernel: ums0: at uhub= 2, port 4, addr 3 (disconnected)
Jan 14 13:54:32 freebsd14-rpi5 kernel: = ums0: detached
Jan 14 13:54:34 freebsd14-rpi5 kernel: ugen0.4: <PixAr= t USB Optical Mouse> at usbus0
Jan 14 13:54:34 freebsd14-rpi5 kernel:= ums0 on uhub2
Jan 14 13:54:34 freebsd14-rpi5 kernel: ums0: <PixArt U= SB Optical Mouse, class 0/0, rev 1.10/1.00, addr 3> on usbus0
Jan 14 = 13:54:34 freebsd14-rpi5 kernel: ums0: 3 buttons and [XYZ] coordinates ID=3D= 0
Jan 14 13:55:34 freebsd14-rpi5 kernel: ugen0.4: <PixArt USB Optical= Mouse> at usbus0 (disconnected)
Jan 14 13:55:34 freebsd14-rpi5 kerne= l: ums0: at uhub2, port 4, addr 3 (disconnected)
Jan 14 13:55:34 freebsd= 14-rpi5 kernel: ums0: detached
Jan 14 13:55:36 freebsd14-rpi5 kernel: ug= en0.4: <PixArt USB Optical Mouse> at usbus0
Jan 14 13:55:36 freebs= d14-rpi5 kernel: ums0 on uhub2
Jan 14 13:55:36 freebsd14-rpi5 kernel: um= s0: <PixArt USB Optical Mouse, class 0/0, rev 1.10/1.00, addr 3> on u= sbus0
Jan 14 13:55:36 freebsd14-rpi5 kernel: ums0: 3 buttons and [XYZ] c= oordinates ID=3D0

=C2=A0
--000000000000b72340060ee84a68-- From nobody Sun Jan 14 15:11:55 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TCdzX0vx2z56Nyx for ; Sun, 14 Jan 2024 15:12:08 +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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4TCdzW3xSZz44V3; Sun, 14 Jan 2024 15:12:07 +0000 (UTC) (envelope-from manu@bidouilliste.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bidouilliste.com; s=mx; t=1705245119; 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=6YinCkRpW6HP8qJpIf25LpnHJcCwN0Mc5Vw7H5BKNgk=; b=LdGkQkYQvrLhOG9pTwAnsvSDmlyJv0OPpp2WX+vb7s4whc7fBjfjEmuX5V55zg5vNvvfQt w6OMNrN9R6aHVdD7qp/I1UQuZnCgFbYixwKD1A+XO16/Yj+ghLNXnTmAJfNFq0uIYL+10H Xl2OeRWVTHV+d0QudboA2UuRLAfoHyc= Received: from skull.home.blih.net (lfbn-lyo-1-2174-135.w90-66.abo.wanadoo.fr [90.66.97.135]) by mx.blih.net (OpenSMTPD) with ESMTPSA id 34e1e58b (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Sun, 14 Jan 2024 15:11:59 +0000 (UTC) Date: Sun, 14 Jan 2024 16:11:55 +0100 From: Emmanuel Vadot To: Doug Rabson Cc: Mark Millard , Jesper Schmitz Mouridsen , John Kennedy , ykla , FreeBSD ARM List Subject: Re: When will FreeBSD support RPI5? Message-Id: <20240114161155.e82b64f2b0cf82fea0e606e4@bidouilliste.com> In-Reply-To: References: <5a39810c-5fd8-4969-a222-2561b050b035@FreeBSD.org> <347FE009-A470-4765-A9B9-7C9AB5E954DA@yahoo.com> <76FA010A-338F-4E32-B381-37C7BA63CAFC@yahoo.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd15.0) List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4TCdzW3xSZz44V3 X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:12876, ipnet:212.83.128.0/19, country:FR] On Sun, 14 Jan 2024 13:52:51 +0000 Doug Rabson wrote: > On Sat, 13 Jan 2024 at 18:32, Mark Millard wrote: > > > On Jan 13, 2024, at 07:38, Doug Rabson wrote: > > > > > Getting back to the RPI 5, with a tweak to > > arm/broadcom/bcm2835bcm2835_vcbus.c to treat the memory config the same as > > RPI 4 and to dev/sdhci/sdhci_fdt.c to treat the RPI 5 sdhci controllers as > > generic, I can boot to multiuser mode using the EDK2 firmware from > > https://github.com/worproject/rpi5-uefi with ACPI/Device Tree mode set to > > Both. > > > > What does FreeBSD do with "Both"? Does it actually use some ACPI > > and some Device Tree? Or does it just use ACPI? Does your > > combination do anything different than just using ACPI? > > > > > This does not have working PCIe or ethernet yet - I think ethernet ought > > to work since we seem to have a matching driver in the tree in dev/cadence. > > > > Sounds like the same status as booting just ACPI with no such > > adjustments too bcm2835bcm2835_vcbus.c or sdhci_fdt.c ? > > > > I think Mike Karels plans on investigating getting Ethernet > > going based on cgem . I've no clue if this is ACPI, DeviceTree, > > or both. > > > > My usage has been pure ACPI, no software adjustments specific > > to getting the RPi5 operational. Use of a USB3 Ethernet dongle. > > > > As far as I can tell, 'Both' works almost exactly the same as 'Devicetree' > - I don't think the acpi device is attached to nexus at all. 'Both' for EDK2 mean that dt and acpi table are exposed, and by default on FreeBSD we use dt and only fallback to acpi if dt wasn't found. > Ethernet should be supported by cgem(4). This device is on the rp1 > southbridge. In the DTB, rp1 is a simplebus under pcie@120000 > and ethernet@100000 is a child of rp1. I think it doesn't match for me > because there is no driver matching pcie@ yet. The existing bcm2838 pci > driver could be adapted for RPI 5 - reading the linux driver shows some > smallish differences in device initialisation. > > I have attached verbose dmesg dumps for all three EDK2 acpi modes. > > > > -- Emmanuel Vadot From nobody Sun Jan 14 16:36:04 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TCgrM40Sfz56bhV for ; Sun, 14 Jan 2024 16:36:03 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (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 "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TCgrL319jz4HwF for ; Sun, 14 Jan 2024 16:36:02 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of fbsd@www.zefox.net has no SPF policy when checking 50.1.20.27) smtp.mailfrom=fbsd@www.zefox.net Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.17.1/8.15.2) with ESMTPS id 40EGa4VC026537 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Sun, 14 Jan 2024 08:36:05 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.17.1/8.15.2/Submit) id 40EGa48C026536 for freebsd-arm@freebsd.org; Sun, 14 Jan 2024 08:36:04 -0800 (PST) (envelope-from fbsd) Date: Sun, 14 Jan 2024 08:36:04 -0800 From: bob prohaska To: freebsd-arm@freebsd.org Subject: Re: USB-serial adapter suggestions needed Message-ID: References: <7D27DF9F-AA9A-4D44-BC28-8CC637D0F550@yahoo.com> List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spamd-Bar: - X-Spamd-Result: default: False [-1.10 / 15.00]; AUTH_NA(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.998]; MID_RHS_WWW(0.50)[]; WWW_DOT_DOMAIN(0.50)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; RCPT_COUNT_ONE(0.00)[1]; RCVD_TLS_LAST(0.00)[]; MISSING_XM_UA(0.00)[]; FROM_HAS_DN(0.00)[]; MIME_TRACE(0.00)[0:+]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; DMARC_NA(0.00)[zefox.net]; TO_DN_NONE(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; ARC_NA(0.00)[]; R_SPF_NA(0.00)[no SPF record] X-Rspamd-Queue-Id: 4TCgrL319jz4HwF On Sun, Jan 14, 2024 at 10:52:34AM +0000, void wrote: > Hi Bob, > > The following *may* be useful to you.. > > (rpi4 context) > > I've noticed, both on 13-stable and 14-stable, that, if both > onboard usb2 ports are utilised (eg keyboard & mouse) that > signals keyboard<>mouse interfere with each other. > It's easy to reproduce this problem. It's been a while > since testing that exact context, though. > > When running headless, I needed to make sure the ups cable > (serial) was plugged into the remaining usb3 port (and not usb2 > where a wifi dongle was plugged in) because communication from > the ups would make the wifi page down if both were plugged into the usb2 > side. The wifi would make the usb serial misbehave (caused 'no signal coming > from ups' type of error) too. > > I've had to press the hardware into service so cannot produce detailed error > output for now. At the moment I have two Pi4's, one running FreeBSD-current. That machine has a USB hard disk (boot device) in one USB 3 port, an ft232 usb-serial adapter (probably USB 2) in the other USB 3 port, with a keyboard and mouse pulugged into the two USB 2 ports. I've not noticed any problems with either keyboard or mouse. Of course, all are plugged in all the time, so there's only one enumeration happening, at boot. The Pi4 that I reported the problem with runs 64 bit RasPiOS. It has a single USB 3 hard disk (boot device) and a usb 2 keyboard with an internal hub, the mouse being plugged into the hub. It boots fine with that combo, I haven't tried moving the mouse to the other usb 2 port. When it's convenient to provoke a crash I'll try. I intended the mention of RasPiOS trouble with USB as recognition that USB is imperfect. I didn't mean to suggest that if Linux can't do something FreeBSD shouldn't try. Thanks for writing, bob prohaska From nobody Sun Jan 14 18:37:05 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TCkXF6hWHz56r1y for ; Sun, 14 Jan 2024 18:37:17 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com [IPv6:2a00:1450:4864:20::635]) (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 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TCkXF6CVmz4hmh for ; Sun, 14 Jan 2024 18:37:17 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ej1-x635.google.com with SMTP id a640c23a62f3a-a2cea0563cbso279767566b.3 for ; Sun, 14 Jan 2024 10:37:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1705257436; x=1705862236; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Cu2MAQJP935RpsB+xL1fsYCtZRn6tW5JBpGsT3pqnD0=; b=InpgC+7VmPql/dQZ4dP1T6zsq3N7pT5Xi312uLujnLAqRTV8CcZrHK6vP5z8hbTh4A 0WB63+mEpDEtIfua3zM/jT7sZsBfCt05mCF+v2VP7RWZgi/MaLmTyTimZawkk+qtUV8h 0LB3f0K0+RXlkft3UbLu5POP7Lb+CwwYVrMkFLaqpEkeIS/XihLzh6MhQS5AqVwII2K3 4X8UJWlnuMOay7/EAtIGPFVi9vhTODi11IyWHNEhS9REllAfvD2A7XKJlsY98n/nzANP LyvwvxSm8/dNA0mbcNgAEuMrsPQUwRS9u1g6/mYnN4bu8phsdmUiG3B9jBEhn6rzJHdQ EL/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705257436; x=1705862236; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Cu2MAQJP935RpsB+xL1fsYCtZRn6tW5JBpGsT3pqnD0=; b=N8wpVsFa7LNeqA7Qv+Bn73E7OJjWG+9rZQHdTg6TYi9h2DHNjfy1VNaabxmROrhzNL udl2D9xuzocsjzmFA0chx/N6Yh9Sc8MAfgBZiRYzYvyqPEsYojXe4p8GxEAl2jobZKM9 EkxUEABNQlwAkAVaNHh1S2djus1/+Tc040pKBM6qbCz5G1zueu+6jx59qoXE4PRDqZjM 9rrdAR+YiRqXrRw1xSDaojzQEsRORY7Uk6Nok6oHEAU0Dw+dDZAvUCK29iGQhwpsEK0A csbiywPy2j+Cd5UOSVeiM48gtdM4MvF0iB+AS8bsuUKPXaB8giqi6W6WJfYStT3QnfZd pE7A== X-Gm-Message-State: AOJu0YwYyHWTGLkEJYvJlAjSCmaYjdTM/ciwHMzE6X081tBLKQteHe84 JRAHzoZZy9x+s2v+RthYJZPnGEKdWR8wdiAAC+8lH+t4bUh5ELi8GqMPq5ISseg= X-Google-Smtp-Source: AGHT+IHrQxox7cbAehu3UeiNfttgu0iGvdDaQwhABKy0l86xpiaAHg2FSpHu8mj3XR3/HPjNhH0kkyNBLngLar+aKbA= X-Received: by 2002:a17:907:7204:b0:a28:fdc2:7f11 with SMTP id dr4-20020a170907720400b00a28fdc27f11mr2594972ejc.83.1705257436491; Sun, 14 Jan 2024 10:37:16 -0800 (PST) List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 References: <5a39810c-5fd8-4969-a222-2561b050b035@FreeBSD.org> <347FE009-A470-4765-A9B9-7C9AB5E954DA@yahoo.com> <76FA010A-338F-4E32-B381-37C7BA63CAFC@yahoo.com> <20240114161155.e82b64f2b0cf82fea0e606e4@bidouilliste.com> In-Reply-To: <20240114161155.e82b64f2b0cf82fea0e606e4@bidouilliste.com> From: Warner Losh Date: Sun, 14 Jan 2024 11:37:05 -0700 Message-ID: Subject: Re: When will FreeBSD support RPI5? To: Emmanuel Vadot Cc: Doug Rabson , Mark Millard , Jesper Schmitz Mouridsen , John Kennedy , ykla , FreeBSD ARM List Content-Type: multipart/alternative; boundary="000000000000c0c50b060eec2f35" X-Rspamd-Queue-Id: 4TCkXF6CVmz4hmh X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] --000000000000c0c50b060eec2f35 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Jan 14, 2024 at 8:12=E2=80=AFAM Emmanuel Vadot wrote: > On Sun, 14 Jan 2024 13:52:51 +0000 > Doug Rabson wrote: > > > On Sat, 13 Jan 2024 at 18:32, Mark Millard wrote: > > > > > On Jan 13, 2024, at 07:38, Doug Rabson wrote: > > > > > > > Getting back to the RPI 5, with a tweak to > > > arm/broadcom/bcm2835bcm2835_vcbus.c to treat the memory config the > same as > > > RPI 4 and to dev/sdhci/sdhci_fdt.c to treat the RPI 5 sdhci > controllers as > > > generic, I can boot to multiuser mode using the EDK2 firmware from > > > https://github.com/worproject/rpi5-uefi with ACPI/Device Tree mode > set to > > > Both. > > > > > > What does FreeBSD do with "Both"? Does it actually use some ACPI > > > and some Device Tree? Or does it just use ACPI? Does your > > > combination do anything different than just using ACPI? > > > > > > > This does not have working PCIe or ethernet yet - I think ethernet > ought > > > to work since we seem to have a matching driver in the tree in > dev/cadence. > > > > > > Sounds like the same status as booting just ACPI with no such > > > adjustments too bcm2835bcm2835_vcbus.c or sdhci_fdt.c ? > > > > > > I think Mike Karels plans on investigating getting Ethernet > > > going based on cgem . I've no clue if this is ACPI, DeviceTree, > > > or both. > > > > > > My usage has been pure ACPI, no software adjustments specific > > > to getting the RPi5 operational. Use of a USB3 Ethernet dongle. > > > > > > > As far as I can tell, 'Both' works almost exactly the same as > 'Devicetree' > > - I don't think the acpi device is attached to nexus at all. > > 'Both' for EDK2 mean that dt and acpi table are exposed, and by > default on FreeBSD we use dt and only fallback to acpi if dt wasn't > found. > I think we should check dt and if it has a simplebus use it, otherwise fallback to acpi if dt wasn't there or if it didn't have a simple bus. That would fix issues I have with LinuxBoot where some data still lingers in dt, but no devices are published there anymore. I work around this right now by preferring ACPI manually... Warner --000000000000c0c50b060eec2f35 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Jan 14, 2024 at 8:12=E2=80=AF= AM Emmanuel Vadot <manu@bidouil= liste.com> wrote:
On Sun, 14 Jan 2024 13:52:51 +0000
Doug Rabson <dfr@rab= son.org> wrote:

> On Sat, 13 Jan 2024 at 18:32, Mark Millard <marklmi@yahoo.com> wrote:
>
> > On Jan 13, 2024, at 07:38, Doug Rabson <dfr@rabson.org> wrote:
> >
> > > Getting back to the RPI 5, with a tweak to
> > arm/broadcom/bcm2835bcm2835_vcbus.c to treat the memory config th= e same as
> > RPI 4 and to dev/sdhci/sdhci_fdt.c to treat the RPI 5 sdhci contr= ollers as
> > generic, I can boot to multiuser mode using the EDK2 firmware fro= m
> > https://github.com/worproject/rpi5-uefi with AC= PI/Device Tree mode set to
> > Both.
> >
> > What does FreeBSD do with "Both"? Does it actually use = some ACPI
> > and some Device Tree? Or does it just use ACPI? Does your
> > combination do anything different than just using ACPI?
> >
> > > This does not have working PCIe or ethernet yet - I think et= hernet ought
> > to work since we seem to have a matching driver in the tree in de= v/cadence.
> >
> > Sounds like the same status as booting just ACPI with no such
> > adjustments too bcm2835bcm2835_vcbus.c or sdhci_fdt.c ?
> >
> > I think Mike Karels plans on investigating getting Ethernet
> > going based on cgem . I've no clue if this is ACPI, DeviceTre= e,
> > or both.
> >
> > My usage has been pure ACPI, no software adjustments specific
> > to getting the RPi5 operational. Use of a USB3 Ethernet dongle. > >
>
> As far as I can tell, 'Both' works almost exactly the same as = 'Devicetree'
> - I don't think the acpi device is attached to nexus at all.

=C2=A0'Both' for EDK2 mean that dt and acpi table are exposed, and = by
default on FreeBSD we use dt and only fallback to acpi if dt wasn't
found.

I think we should check dt and i= f it has a simplebus use it, otherwise
fallback to acpi if dt was= n't there or if it didn't have a simple bus. That
would f= ix issues I have with LinuxBoot where some data still lingers
in = dt, but no devices are published there anymore. I work around this right
now by preferring ACPI manually...

Warner<= /div>
--000000000000c0c50b060eec2f35-- From nobody Sun Jan 14 21:00:53 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TCnjx68MFz576F2 for ; Sun, 14 Jan 2024 21:00:53 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TCnjx444mz41vg for ; Sun, 14 Jan 2024 21:00:53 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1705266053; 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; bh=toWPnvoci4LLolPQCwIA4qbd3HZ1kJRLsFSlQm23P70=; b=dbOdPTjxpITMzjTCMwwk7xs9QT4z/MV/9TROfWF+lZB4nZ7UMJJimE7DbKIGGii18peZAv jz2D0WaTI97Abo27M7t6K5kIGhZ2ttqt5Xz2CUDlIDY2kfGM25QJjS/ddEpG4F7VF687A2 M/S+KlWkt7EZrNIPcl0OyrGaWiumd1/KNocmFc+f+bIROEN03TsB1OAmRSOTO22KCfizgb i8bqkUsJTod57ZoquH3SG4CAvurdMCAKXZKMSes5f6N1s0HivYWp0cTBkzglEzyfLtMLa9 Kqjq8rE3mLctdJ+u1tz/XHkbNuKzgrg9gA9SVVUROCzRSZ/hHAW8Vvglwzgseg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1705266053; a=rsa-sha256; cv=none; b=WIDzsu4aB+rzQeZljAI6zuSLUVggns0H1ahh1nQ3HCGFbvtQIKYgUE+fVuc1VxHcThdFOM 13qY2jyB0bK25pgeqlgxJjLesSxu2BK5prNzPLY+vkj95mOaqy8d+ytOXCI69ZJyZhHFX+ fwifKtxEMAu7Gobn26QhkJN7JngKE8dtwINOHZGAKMBnQJobnmsEng4U2XqDPo+umd5AZd v86rOGw8nlF1okrdGJCM+3NWQ7Uf4cSIdUMBt07dMRpZYGG7l9I8UrWoRYA/V3fgQX26O2 8ZtbpCaC4CSMeJu/QPokTsGjLCXf9UIytY+CC4qgirAs4JL99xFMwSbWY/KnkQ== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4TCnjx35qWzTC4 for ; Sun, 14 Jan 2024 21:00:53 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 40EL0rON082058 for ; Sun, 14 Jan 2024 21:00:53 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 40EL0rjt082051 for freebsd-arm@FreeBSD.org; Sun, 14 Jan 2024 21:00:53 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <202401142100.40EL0rjt082051@kenobi.freebsd.org> X-Authentication-Warning: kenobi.freebsd.org: bugzilla set sender to bugzilla-noreply@FreeBSD.org using -f From: bugzilla-noreply@FreeBSD.org To: freebsd-arm@FreeBSD.org Subject: Problem reports for freebsd-arm@FreeBSD.org that need special attention Date: Sun, 14 Jan 2024 21:00:53 +0000 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="17052660530.FfeF.76732" Content-Transfer-Encoding: 7bit --17052660530.FfeF.76732 Date: Sun, 14 Jan 2024 21:00:53 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status | Bug Id | Description ------------+-----------+--------------------------------------------------- Open | 257670 | mpr(4): SAS3008 PCI-Express Fusion-MPT SAS-3: Fat Open | 264574 | sdhci(4): Support ACPI attachment in BCM2835_sdhc 2 problems total for which you should take action. --17052660530.FfeF.76732 Date: Sun, 14 Jan 2024 21:00:53 +0000 MIME-Version: 1.0 Content-Type: text/html; charset="UTF-8" 
The following is a listing of current problems submitted by FreeBSD users,
which need special attention. These represent problem reports covering
all versions including experimental development code and obsolete releases.

Status      |    Bug Id | Description
------------+-----------+---------------------------------------------------
Open        |    257670 | mpr(4): SAS3008 PCI-Express Fusion-MPT SAS-3: Fat
Open        |    264574 | sdhci(4): Support ACPI attachment in BCM2835_sdhc

2 problems total for which you should take action.
--17052660530.FfeF.76732--