From nobody Sun May 14 15:36:16 2023 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 4QK66Q2tglz4BpgP for ; Sun, 14 May 2023 15:36: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 4QK66N32lGz4LpR for ; Sun, 14 May 2023 15:36:12 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Authentication-Results: mx1.freebsd.org; dkim=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; dmarc=none Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.17.1/8.15.2) with ESMTPS id 34EFaHow068815 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sun, 14 May 2023 08:36:17 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.17.1/8.15.2/Submit) id 34EFaGX3068814; Sun, 14 May 2023 08:36:16 -0700 (PDT) (envelope-from fbsd) Date: Sun, 14 May 2023 08:36:16 -0700 From: bob prohaska To: freebsd-arm@freebsd.org Cc: bob prohaska Subject: Armv7 (rpi2) getting stuck in buildworld for -current Message-ID: 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 X-Spamd-Result: default: False [-1.08 / 15.00]; AUTH_NA(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-0.999]; NEURAL_HAM_SHORT(-0.98)[-0.981]; MID_RHS_WWW(0.50)[]; WWW_DOT_DOMAIN(0.50)[]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; R_DKIM_NA(0.00)[]; R_SPF_NA(0.00)[no SPF record]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_COUNT_THREE(0.00)[3]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; DMARC_NA(0.00)[zefox.net]; TO_DN_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Queue-Id: 4QK66N32lGz4LpR X-Spamd-Bar: - X-ThisMailContainsUnwantedMimeParts: N Lately a Pi2 running -current has gotten stuck while buildworld is running. There's no escape to debugger, no obvious errors on the console and only modest swap use (tens of MB). So far the stoppages have been when building clang. One possible culprit is /boot/loader.conf, which has accumulated some baggage over the years: bob@www:/usr/src % more /boot/loader.conf # Configure USB OTG; see usb_template(4). hw.usb.template=3 umodem_load="YES" # Disable the beastie menu and color beastie_disable="YES" loader_color="NO" vm.pageout_oom_seq="4096" #vm.pfault_oom_attempts="3" vm.pfault_oom_attempts="120" vm.pfault_oom_wait="20" kern.cam.boot_delay="20000" vfs.ffs.dotrimcons="1" vfs.root_mount_always_wait="1" filemon_load="YES" net.inet.tcp.tolerate_missing_ts="1" vm.swap_enabled=0 vm.swap_idle_enabled=0 --More--(END) However, the problem emerged well after the changes above were made. A running diary of experiments is at http://www.zefox.net/~fbsd/rpi2/crashes/20230514/armv7hang Thanks for reading, bob prohaska From nobody Sun May 14 19:31:29 2023 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 4QKCLC2VGPz4C2pL for ; Sun, 14 May 2023 19:31:47 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic311-24.consmr.mail.gq1.yahoo.com (sonic311-24.consmr.mail.gq1.yahoo.com [98.137.65.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 4QKCLB6x5Wz3hKr for ; Sun, 14 May 2023 19:31:46 +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=1684092705; bh=KPbRTu8t/kb8WTg1Sp/Zraf4VcUPU69VvXHmbQx8Rqs=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=Oqjv8AiM65iWmvBrm4lRUgygcIjgjmt9lqBRLbDgO2vHqEQ8t1mOcmxyd3V/de/5juP7rnqTFwuFsMvIl6zRSxlKY7S7QejlAKXaCT/w5n/oQHwvZ2qgApwk0ZdLEx+3C4RmaOZ6bPA+oPRCOIiI9KPTayvyMTpuXhl6G2cdsqovAPGU3kNWKMS9prOi40GmjcNktEB+uypxWGJLIUHR9UsbopG8E5uvD3X/2/scXNtzF9+8KfOpBiOvnOC9Q9JQ86uRtol4uuy7m4lf5gEAXz+FbwGmuzcaVEdRTQyoqeFvyjg7C4tNGgjst945L9NHoKmqS0idXBk9SFZ9Rp2BKg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1684092705; bh=zBa9cGaWrXNKFjdQoAqv3fMEWqeZFb/XHKUhpqTda+1=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=qOI2kOWKcwBGCHRVSXL/AQXdqksgFeX5sgb8ERlB1gyb3fCO6mbFxp4RnBHQS9Wrk1lzxgJpUWg5FNTc1yHy9KzURV1QRPMKOxkQ9EwzlDXhXgL+t9LthrnWxH1Zecsw5vOc32x3B/S22/bi93m23SuPU8PNaxGnbXdAsgdlevtTsJxDeV3jt4LFAU2wgMIhx3c8L7K+bvIFsxiA0Tje7WbFpirjg2b3P5QoZJ4zE/t9K+qYohGkCx+otFX7HFqyEbQtaQpUPzL3USwo2xBpGYtj+OX0PrHBduyqU17XFwCC/FgaY+i4e6L2+ibTWRttwlep8uAlzIKFaqA/jDtOOg== X-YMail-OSG: hGZx5T4VM1nPUOcB74j5CB0LVtO.GHG59S7ifJUtkttoGiiccyNtJRnuCIRuBuE g2ssMYfd46y4DXrSV7X2WwAmm0ZCF4a1wKZsFVo8OaaqdFIz7b9Udi1KAMSjqmCDvW6nOZRZxF6o 9nX26YI2_xoYl5dcSQlGkXHG8KxB8BntBmxmEDrXSJDaequ5ZslhTuVz0fliluODT7tFehcbv9tC nyCPsspu5lwYoajYhbUlEwKoFc.Yv_rWmAunzQHFKlk9IV83dFytNjigzGC_dXzK8MK.lvJ1.lt2 WdD.OqmxScSyfSZ76umBtUGpQ.S79wTXuhxmZD4DvO6mpHi1.3kRe5FgtZHD2FE3sB6rGQg5J_Lm rVlSPcqUtAU1MXnuKO07A_voJAmsI8AHP_LP62.4JkDa5nUpn4.C_KgTJpQ1v9K7tiGORgu.apLR FN.plv4y99C_HUw.ey.gZw2bE7bhzgpvjt3hbOEkfx8re_1ytPaaD_UGuHkdSY5YWv_nfbcIteJZ OjCgFv_PmPaaV6rpDrpB_tFsEvUbEGBobdTOcGj2R4eF8ZI7_Nyp98KphMAnYJq.sTHgrYYk6Paz mZPIrObBwaO5uYnAOVL14OpNbTUn.skDSBs8qdP3Nz83kdCQHpid5TR4vfTe3VnBqPzl4waQSBKJ RDyxapWfNKzm1LugIc5V6_FPePk_vVP2cqeXtUSNmauV95la0YCdyS9cVoc6EhYgZRe6Y7mfiO_S koupIdlX4NiGB.VSoSOt4J8CfnCLvbnJq6kd8WUkXp935qFTtPDtPZwWTicHmqhVK5xZ08il.oxL jhQRmpx27EDpJrVGLzhfPyb.zVtJkZogOFs5qgyh9RNft1o3TJBzUYLiDxDdc.q_fGi5EY9iJz21 osK8uTp2lh31C.zwHCewf3G7PsP.wmHSvqBpJ_fJeESncAGJmA3nlkb6MPRn0XQdHNf3pEPDHBTc NL8X4trflrvHcS_hQp_h2yys.UJE3qRA33xVvxzXsJliSgWbp.pDD7iWzphHZIuBIhG7jzXkoCNl K6.fuoj.2DL9x0Ee4ys8Tp5.RuAAt1XGDlNG1v1DTDqkNNwacZlXFrFlh.I6XeieLYzgSUFKvQIR lJN7UL6zXgTktUYn4dRw5ktEEi4FxHBp0RwnYFry2Z_T9Q4e7WTwEapE3OUCEImu79TAvy4SgRaK vOzLIkaSDqTsU6B9x9GUcEA7S77sSmCXtDbOBup.gwRopK0SWL3.Q5N02mApsH9NxT_WW8nQYaHS FNyROgKcg4VK.vfkydOsQv8ZpWnSFw2QvFNAMzqK9kokoExTFb0MLMpSB79khOLtKZFjID4keWXj F0ELYgobRz91ZYh3Z3ytKeWDD9F5ZtiO.xlvALmpFp5EzAB5khOjKgZ1uNDImlaAU6bT3BHto3C1 8s2qWeGdlbpsm7mznj4QoE8pET5EJzHOoORIL1dPI.ZqgJOEecuoRou2bdoB64h.VGUSM1HrbEAu KlQrmJ4JXJmUrjFusRQ_.1rPtuhzbGtQk.UstewFz7FIs40WFqYVKCAWVf3I7rct9_uPb5Oxrnjp Zq05ntbwLKkU5HuRYbOyTdLTLYz8OckI0wtICkat3WsrCTf6McWl0_HFBvFVMCadYih74S5WSfVr SQO.fMEAYFkx5TiY6agZbBKdEDu4vYGvXDL6Prn4yFLDrzSKlqEz7xs38BHc5Om5Macs9nIepSsv W8K522hyHCwNNQriIW8dZ7mLLf3u_nE0k6n7UEz2nxPFTsYP6WoCWyIjesJ36PizqSppaTCWaGqX G0GGA983ZIce0zm4_qvv6tq2O1xlGrQZijqznuAMRPI4_ZdWKUquVjGSzgr9Jb1_5Ypt09xhX8fc TimfOyAg1tc5GlKU8zyWA0EAL74hcnEEo8UOENThrsdk0lBtI2_WyHWp5fpHTjZ6bpusChoP3CpL zyn3Rz4l2vu4L7T7L0tYGRtsVE0GBawnjcBn8axX3SVcbnZHDvBSCykj_0faSAczFWfF40aos2Wt 8AX3s6UV8EYyzz_8fnnuDWYVklJVVZSLVIA.2SsyGLjD.kdgn__1HKqiJGWiz5BaF1.GkOjZsH3j atDnyzrIqVkwiTwR3aoTmlFG4akQl38uVlr1ya6vVqyETZrkZNhu.xsDfOM.SoYFPcIOPHHzRQlw xpPJBAik5ohovZpwdfcOfcimVMkjQTurGMkbxhcaM8.c99E2zsOG.czUoEgJVq46oWIK7qZBzujT A.nbaffA4_phTh1wDWa8wgB8YEJ4lA.M7RlRP_xAoSNHXyUCggF5jvfSOA3A_gJac.wl.ovWjQvc n0w-- X-Sonic-MF: X-Sonic-ID: cce792f0-da2b-49a4-aa10-314b1d5b1cd4 Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Sun, 14 May 2023 19:31:45 +0000 Received: by hermes--production-gq1-6db989bfb-ppvpv (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 6439c6f27407af951b0a5fb589b351b8; Sun, 14 May 2023 19:31:40 +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 \(3731.400.51.1.1\)) Subject: Re: Armv7 (rpi2) getting stuck in buildworld for -current From: Mark Millard In-Reply-To: Date: Sun, 14 May 2023 12:31:29 -0700 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <7758885B-3115-47F0-A453-1C010313D4B8@yahoo.com> References: To: bob prohaska X-Mailer: Apple Mail (2.3731.400.51.1.1) X-Rspamd-Queue-Id: 4QKCLB6x5Wz3hKr X-Spamd-Bar: ---- 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] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On May 14, 2023, at 08:36, bob prohaska wrote: > Lately a Pi2 running -current has gotten stuck while buildworld is = running. > There's no escape to debugger, no obvious errors on the console and = only > modest swap use (tens of MB). So far the stoppages have been when = building > clang. >=20 > One possible culprit is /boot/loader.conf, which has accumulated some = baggage > over the years: >=20 > bob@www:/usr/src % more /boot/loader.conf > # Configure USB OTG; see usb_template(4). > hw.usb.template=3D3 > umodem_load=3D"YES" > # Disable the beastie menu and color > beastie_disable=3D"YES" > loader_color=3D"NO" > vm.pageout_oom_seq=3D"4096" > #vm.pfault_oom_attempts=3D"3" > vm.pfault_oom_attempts=3D"120" > vm.pfault_oom_wait=3D"20" (I oroginally had a note here but I think it would just confuse things and not be tied to your problem.) . . . However, I expect that your user process had its kernel stack swapped out. See below. > kern.cam.boot_delay=3D"20000" > vfs.ffs.dotrimcons=3D"1" > vfs.root_mount_always_wait=3D"1" > filemon_load=3D"YES" > net.inet.tcp.tolerate_missing_ts=3D"1" > vm.swap_enabled=3D0 > vm.swap_idle_enabled=3D0 Those last two lines are for avoiding having interactive sessions (sshd, serial console) processes end up with their kernel stacks swapped out. (But it does so by preventing such for all kernel stacks, not just the ones of interest.) When a kernel stack is swapped out for a process/thread, the process/thread can not run at all until the kernel stack is is read back into the kernel. Those last two lines you have in a file for tunables --but are not tunables: # sysctl -T vm.swap_enabled # sysctl -T vm.swap_idle_enabled #=20 Compared that to the check for the writable category: # sysctl -W vm.swap_enabled vm.swap_enabled: 0 # sysctl -W vm.swap_idle_enabled vm.swap_idle_enabled: 0 #=20 In my environment, I use /etc/sysctl.conf , which is a place appropriate for non-tunable but writable sysctl values: # grep vm.swap_ /etc/sysctl.conf=20 vm.swap_enabled=3D0 vm.swap_idle_enabled=3D0 I suggest moving the assignments to /etc/sysctl.conf . I expect that this will get rid of your problem once you reboot with them in a right place. (You can also interactively set them via sysctl use.) I suggest avoiding confusions by not having copies of those 2 lines in /boot/loader.conf (where they will not work). > --More--(END) >=20 > However, the problem emerged well after the changes above were made. >=20 >=20 > A running diary of experiments is at > http://www.zefox.net/~fbsd/rpi2/crashes/20230514/armv7hang There you report reducing the swap space partition size. Were you getting the message about the swap possibly being mistuned prior to that? For 1 GiByte of RAM 3647M looks to me to likely be a little below where that message about mistuning shows up. If you were not getting the message, the size should have been fine. In other words, I expect it is appropriate to put back the original size (or some approximation of it that avoids the message about possibly being mistuned). Everything that you reported looks to me to be consistent with some kernel stacks having been swapped out for some processes/threads that would otherwise be involved in interactive I/O activity. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sun May 14 20:00:46 2023 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 4QKCzz1wHWz4C4FB for ; Sun, 14 May 2023 20:01:03 +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 4QKCzy1Sdvz3l6X for ; Sun, 14 May 2023 20:01:02 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=KP6ZZyRX; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.83 as permitted sender) smtp.mailfrom=marklmi@yahoo.com; dmarc=pass (policy=reject) header.from=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1684094460; bh=juiosNCkuc4fraPLKnWWkZZdg9KR4UqzbAgoMV4iraI=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=KP6ZZyRXansnYD5o3nDCH3VfHYjzTW97R11OkO94YE243QtVSQtUmuTjNi7kwHpAA4jwJtDdNLmDnOB1bpQGNbIQ+rAQ4uc1hWR4vnhC8Ki8ErSiZSSbnJ/UWFtSc4ahXfvLCxcMaZbM+egVDqag2890c2cNKCAyvEml9c036NFwS7E1++fhPeBUb0sNkNSlG9h0tZ6PALRfei7XbMC8v3LkUwA/oOCh66I0IgRcv8BNimjQVCezY1HnTYzKSuWl5jlK2kI2ur74bRNxQq8n1Np7xwF0euJbWC/hmE5LTbrt6bwzloNgk0ZJTfZ+AA1T+RYCyL3Bg+BlTsRa4KjlBA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1684094460; bh=/U1UlJeomYjiG4IxPzWVSRJuiCfgxNL7gSZtjHaHeKI=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=r1MF4YJtOyqrDM1M3dT07TXlbsFBz7SQajiDylZR4IPw+ZO54l4xkP86DQ9DrCE9JrpqsoL3p5R+zOfMnAV5CQEOVCyYJa3kxhyKhOyMcF3escB/qKYDK0ArOIp6ZJ6ER3DwehVxXImLvy8MPi1TY+LkGVboDcYrxDFAYOkX9fYbW4+PTKZDnMuxEAFJAUWZxjJRRIP4lXjTaOljrQyi2+KSQNU9QMBMi/0aYqyXrnmDevcay0yE9qhjrS4AEk6NY7dyQV80CHGzpwav7tYlS4xR9v67ObF3ma/7iwpCJh4469+8ZnQKnjf/wQn9TggS+MsR21PKhKaINju2bDDBZw== X-YMail-OSG: 12E.YFkVM1n28JUbIVv9Ja8SEeB61MDZnfUP8RgdTlqbAOE9WfKFt3YNv74NMpG dkdiAR0oxqf0gjOrjsgFNY4a3aFolL8Zh9CbWfUdxGS7MUXqkyjgb75rDOQzZ37QILuazfxS0sBY zw9SDuOTplCMlVJd0vMimfWNRp_DcC1NTilMNOrSzrdt8hnm96_d75dp0DGXNHLZh6gffSMjQpG8 lLOixe7rdgHqU5G0S0.pgMk3JwcvHFBN5ond2473.V53Qmyq86areZVE3EpMGlIOIe4Qoair3AvU 6dn4wJki_tvcIoFGVOgvfra5GK9B_sOAyyNm_6dEgoK.eGC.iphZxVeZ9UF5A4DEaIstTJRxM_8f hFgeFf144qHgKvDpMMQXJlerpvEpFL.sijn7c_N3.NTY_BAtHapeUb5DSvsbWa4nabu7XdMlHNDq gqpdZ41qVRTL2w592qX9WMgPb2WSeB_N7jIgl12zW22ZeNNBHfmgmqZdVWy8JtjUYg9hUGf6v6jA _yyrokIuVLYAwH0W_bqKxU0uSmwJdEVCNn5E0392owNolKCiA0o3KcZzeBPF2HkJB55dtdHEyRIr N0uUK1vikrPheYX7vBMdIctqWPFA8NDA3IwEnDx5FVHI_tARY32ZReR7gzxebqPS900onFF0P3Tr d_1niNQq1ME2Q_NbEgtFZadMllKj6mcTK8FMZ6vPQIIiBKH5D_hVJlYzGb1WH2TlY55HOGEBg8r4 Bz_6ixrk_.kwUSUV1dp6lkbdEgI.iqyIoU0zLDl5QaVxZGbU3oKs0UtQtBocgMoz8JuUq493.rrz WTXBA92N8pStMpUzf7W126uyMKrG7EJeEZqGo89lFzDRWsMaq51TvIHZxcdrDEJ78Pfl1jrImZRU mhL_eu_JOc2ldxGygXdK7hgL9x0Jh3K0.sT7JhVFh3aiE5xMN1bo38SaqCElcgwnmLnTGLbCqyb3 W7Zt4pWxprzg5myOG7.QeKAdQ6GWw2pUOV44MgusbFUKZ_2HOHOMnlqGxZHqcsJqZ_9a4qFT4yp7 tMX5zEEdy.eku9RrL56R7JTTIj_WELWzjDDidWmHjUp6YX_K_hrtUUcSS6hdYwAZ6UPi0HYA1IPc bpRrUueYntoaefxeKlpJ191pUOtEbW8R_LjrIHhe1MkUFPiFyGZtTJPR4mrnlcDt1G.83JFzGz0j V5UAZbRzlYr.1FwbzEqB2friqQp_olcz4psUrxNzKEx3k91n6RV85HsM3VMRS1UFyQiodEy97DLD UjLXZjHZBk2vX3nXP4Vsq2vu.G6pk.La42YDM1VQCE9HcfP.eMURyWDXrNHuUq1A1Wwf6iWN1ON9 k6Gs_HXkOwdrAaF9Z1dsVO5.udMY1I8OE.9HYqw0hJuph5Fk0QdC2U8QMgx7hgkckTUFHHzr20_U KhIqo__FW5ux7ESjMh4BqFbvgxtljZQ1by4f1UIkF54Z3xqL.P67WCtVXVBJxCkjd6.AfvvwwDqH IsanKDCaHR.6Io9B.lp.57YPYTsYX3wh1Tw3tpSZxa6IeJ1DV_5x9OAQ0NKWvaAJErgs.CN3rk2I oCQ6QNr8k2cxPgxI2zkz4to5hBep4wpZCvKCrEip9J9GA.f.FJOCnbRE45QeBdJv8AAOWNmS3kjk v4qCvjsvE5NYIFkyANbi7v0tENGBgACcE8gW0nOj84Uu3UWkevrkgYVF.jkSkGRXJd8uD7is0MEJ bsqTd3UBeRG5W6vYPmYYMBaHN0tUg.HA3fHAXGdxwE7qTUwvAcVWW9RGDPXvgFCWu8LIBuI031e6 oYoO.sguTNZDYqK84AAemSbvubnxSfiEZqfrnuiVgcB__HD1LcNvmFftDC9B_S6d608djZEjuFVn JPmtuZEARds8V4FzwXk936O9uapnq2H3JgKsxIKcYruxlCPbAgMKKfylFURjXlx5KlrYrhuLlPco 62hNSSHA3061BVp14Lr2cCuljWmxmeOV7hvhXJXe7Q6iMWXW6ySagh2S.W3K9E9k2nDUkiwZsPfq puI6Qgl5WQmPmeJUcY9R9EkHraIUDZQQuX1Dnk0ZFMvIVW5uNRW30pWBE_XCkBlOMvfYJBt2DktW b6Xa2kZ7nru.hkP6RoL1xdTeh9sHuL2q_lcIr0GRTbUcdCqsSsfSL2zwbYpWNTOL006kYcPc_.m1 LxQ3L2y8XVJsMZ5d1ZRCbOKXhJGjJ9q1vUWsP0Sho4DFbOq.2LpDRDoQVCe.iVXpMlA7KVrx.Be7 OqGMwUw2TNx7WzQ4yxtMaW6W_xqaMWesdUtAJKDlIf9m1Wgl9mPe7rxwUysmgimdRa1PqoI2BYZr 9 X-Sonic-MF: X-Sonic-ID: 10ef458e-3114-4bcb-b30d-93c05309464c Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.gq1.yahoo.com with HTTP; Sun, 14 May 2023 20:01:00 +0000 Received: by hermes--production-gq1-6db989bfb-js4gb (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID ef7f8a54bbff0ae6b991f6ebab42db92; Sun, 14 May 2023 20:00: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 \(3731.400.51.1.1\)) Subject: Re: Armv7 (rpi2) getting stuck in buildworld for -current From: Mark Millard In-Reply-To: <7758885B-3115-47F0-A453-1C010313D4B8@yahoo.com> Date: Sun, 14 May 2023 13:00:46 -0700 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <7758885B-3115-47F0-A453-1C010313D4B8@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3731.400.51.1.1) X-Spamd-Result: default: False [-3.45 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.95)[-0.947]; 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]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.83:from]; BLOCKLISTDE_FAIL(0.00)[98.137.65.83:server fail]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; RCVD_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[yahoo.com]; TO_DN_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; MIME_TRACE(0.00)[0:+]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.83:from] X-Rspamd-Queue-Id: 4QKCzy1Sdvz3l6X X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N On May 14, 2023, at 12:31, Mark Millard wrote: > On May 14, 2023, at 08:36, bob prohaska wrote: >=20 >> Lately a Pi2 running -current has gotten stuck while buildworld is = running. >> There's no escape to debugger, no obvious errors on the console and = only >> modest swap use (tens of MB). So far the stoppages have been when = building >> clang. >>=20 >> One possible culprit is /boot/loader.conf, which has accumulated some = baggage >> over the years: >>=20 >> bob@www:/usr/src % more /boot/loader.conf >> # Configure USB OTG; see usb_template(4). >> hw.usb.template=3D3 >> umodem_load=3D"YES" >> # Disable the beastie menu and color >> beastie_disable=3D"YES" >> loader_color=3D"NO" >> vm.pageout_oom_seq=3D"4096" >> #vm.pfault_oom_attempts=3D"3" >> vm.pfault_oom_attempts=3D"120" >> vm.pfault_oom_wait=3D"20" >=20 > (I oroginally had a note here but I think it > would just confuse things and not be tied to > your problem.) . . . >=20 > However, I expect that your user process had > its kernel stack swapped out. See below. >=20 >> kern.cam.boot_delay=3D"20000" >> vfs.ffs.dotrimcons=3D"1" >> vfs.root_mount_always_wait=3D"1" >> filemon_load=3D"YES" >> net.inet.tcp.tolerate_missing_ts=3D"1" >> vm.swap_enabled=3D0 >> vm.swap_idle_enabled=3D0 >=20 > Those last two lines are for avoiding having > interactive sessions (sshd, serial console) > processes end up with their kernel stacks swapped > out. (But it does so by preventing such for all > kernel stacks, not just the ones of interest.) >=20 > When a kernel stack is swapped out for a > process/thread, the process/thread can not run > at all until the kernel stack is is read back > into the kernel. >=20 > Those last two lines you have in a file for > tunables --but are not tunables: >=20 > # sysctl -T vm.swap_enabled > # sysctl -T vm.swap_idle_enabled > #=20 >=20 > Compared that to the check for the writable > category: >=20 > # sysctl -W vm.swap_enabled > vm.swap_enabled: 0 > # sysctl -W vm.swap_idle_enabled > vm.swap_idle_enabled: 0 > #=20 >=20 > In my environment, I use /etc/sysctl.conf , which > is a place appropriate for non-tunable but writable > sysctl values: >=20 > # grep vm.swap_ /etc/sysctl.conf=20 > vm.swap_enabled=3D0 > vm.swap_idle_enabled=3D0 >=20 > I suggest moving the assignments to /etc/sysctl.conf . > I expect that this will get rid of your problem once > you reboot with them in a right place. (You can also > interactively set them via sysctl use.) >=20 > I suggest avoiding confusions by not having copies of > those 2 lines in /boot/loader.conf (where they will > not work). >=20 >> --More--(END) >>=20 >> However, the problem emerged well after the changes above were made. >>=20 >>=20 >> A running diary of experiments is at >> http://www.zefox.net/~fbsd/rpi2/crashes/20230514/armv7hang >=20 > There you report reducing the swap space partition size. > Were you getting the message about the swap possibly being > mistuned prior to that? >=20 > For 1 GiByte of RAM 3647M looks to me to likely be a little > below where that message about mistuning shows up. If you > were not getting the message, the size should have been > fine. >=20 > In other words, I expect it is appropriate to put back > the original size (or some approximation of it that > avoids the message about possibly being mistuned). >=20 >=20 > Everything that you reported looks to me to be consistent > with some kernel stacks having been swapped out for some > processes/threads that would otherwise be involved in > interactive I/O activity. >=20 Just adding an FYI about: load-time-Tunable and Writable vs. load-time-Tunable (spanning both writable and read-only ones) vs. Writable (spanning both tunable and not) and loader.conf vs. sysctl.conf appropriateness: # sysctl -aTW | wc # ( all: either loader.conf or sysctl.conf ) 431 860 12410 # sysctl -aT | wc # ( 617-431: just loader.conf ) 617 1231 17343 # sysctl -aW | wc # ( 1415-431: just sysctl.conf ) 1415 2821 42158 =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sun May 14 21:00:32 2023 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 4QKFJd2c3Dz4C73s for ; Sun, 14 May 2023 21:00:33 +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 4QKFJc6VdYz3q7F for ; Sun, 14 May 2023 21:00:32 +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=1684098032; 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=2C+mVBVphxSKXdxLy/BgCgXn28q/oFAv43S2SD+4GVk=; b=IDngQPUQjCgaaSUI1QY6LmAAxz6Or3lpkMfHRUNG/ifqiMi+pS8BZ2V2aMkjoA0goIR0cZ e2+USpuOzqO0cQLhZ4cwlxkPmup2KkQrgRCxYm5EHW3Yh5siDFy941fgk/4SLTAzXDvs1I KflnNeXu9ePRLE9VYKuVmigugMObr2TrEkmJblkPJ6AhOi99okBSJxl5m9bVkwkVUj8TtB BWBWL4vUy7B+OrMBGE58EhqtAZ9eCIYlCBKJxRg6t3myAmu4ebd0OKbVNrG+D22uM9jrWW zC57y29zv3MPU98dvETGdCBqXBl/fnzivUf9eNxVHt7bnWg5tCpHoKMbuCGHhA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1684098032; a=rsa-sha256; cv=none; b=HdeEAIRpT0C3SVjXJpjWKt2cadiLphqwvcYYI0HVSxhHuqL2H7UjYkXcJUAcjGVzdeZamO zkfdNoyIKPl5z/xW5DlMut6d5U4iKxl8BoJkCyXNTP5eo3DI+9aywjlohSHW9Mr7rtAN7t 7Myv7DtvEECVvycQ9HniB8b8St90m5sA7LXV0AnslAe0gonhj6l8azy/39Vkv7xIZ9Bx+z 7KjeiGlLBw/J7ssa1D7/IQGdFO1ZCgxYGXHSes5SePOhTieSesMZC00Nb7JXhhjvLj3oR7 R8nlHBmibkB1LXGtVxTMofTsdWxarMY7NCipGZQ2O0ko6jP35Oj/ZtDXsiSVCQ== 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 4QKFJc5bcpz1ChY for ; Sun, 14 May 2023 21:00:32 +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 34EL0WhE087736 for ; Sun, 14 May 2023 21:00:32 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 34EL0WHR087735 for freebsd-arm@FreeBSD.org; Sun, 14 May 2023 21:00:32 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <202305142100.34EL0WHR087735@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 May 2023 21:00:32 +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="16840980321.0e7c7fE2.85873" Content-Transfer-Encoding: 7bit X-ThisMailContainsUnwantedMimeParts: N --16840980321.0e7c7fE2.85873 Date: Sun, 14 May 2023 21:00:32 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status | Bug Id | Description ------------+-----------+--------------------------------------------------- Open | 238576 | Raspberry Pi 3B+ "shutdown -p" does not shut off Open | 257670 | mpr(4): SAS3008 PCI-Express Fusion-MPT SAS-3: Fat 2 problems total for which you should take action. --16840980321.0e7c7fE2.85873 Date: Sun, 14 May 2023 21:00:32 +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        |    238576 | Raspberry Pi 3B+ "shutdown -p" does not shut off 
Open        |    257670 | mpr(4): SAS3008 PCI-Express Fusion-MPT SAS-3: Fat

2 problems total for which you should take action.
--16840980321.0e7c7fE2.85873-- From nobody Sun May 14 23:58:16 2023 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 4QKKFW0KK8z49Kdy for ; Sun, 14 May 2023 23:58:07 +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 4QKKFV3BNTz47FW for ; Sun, 14 May 2023 23:58:06 +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 34ENwGk9070521 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sun, 14 May 2023 16:58:17 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.17.1/8.15.2/Submit) id 34ENwGcJ070520; Sun, 14 May 2023 16:58:16 -0700 (PDT) (envelope-from fbsd) Date: Sun, 14 May 2023 16:58:16 -0700 From: bob prohaska To: Mark Millard Cc: freebsd-arm@freebsd.org Subject: Re: Armv7 (rpi2) getting stuck in buildworld for -current Message-ID: References: <7758885B-3115-47F0-A453-1C010313D4B8@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: <7758885B-3115-47F0-A453-1C010313D4B8@yahoo.com> X-Rspamd-Queue-Id: 4QKKFV3BNTz47FW X-Spamd-Bar: ---- 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] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Sun, May 14, 2023 at 12:31:29PM -0700, Mark Millard wrote: > > > In my environment, I use /etc/sysctl.conf , which > is a place appropriate for non-tunable but writable > sysctl values: > > # grep vm.swap_ /etc/sysctl.conf > vm.swap_enabled=0 > vm.swap_idle_enabled=0 > > I suggest moving the assignments to /etc/sysctl.conf . > I expect that this will get rid of your problem once > you reboot with them in a right place. (You can also > interactively set them via sysctl use.) > At some point in the past I did that and failed to clean up /boot/loader.conf . > I suggest avoiding confusions by not having copies of > those 2 lines in /boot/loader.conf (where they will > not work). > I elected to comment the incorrect lines out with a note indicating why. If I got confused once it may happen again. IIRC the lines were added because ssh connections tend to drop when the system gets busy. That's still happening, so they're not the cure, or at least not the whole cure. > > A running diary of experiments is at > > http://www.zefox.net/~fbsd/rpi2/crashes/20230514/armv7hang > > There you report reducing the swap space partition size. > Were you getting the message about the swap possibly being > mistuned prior to that? > > For 1 GiByte of RAM 3647M looks to me to likely be a little > below where that message about mistuning shows up. If you > were not getting the message, the size should have been > fine. > The last "too much swap" message I can find was: warning: total configured swap (1048576 pages) exceeds maximum recommended amount (922200 pages). Space was reserved for 4GB of swap, suggesting that only about 1.6 GB is recommended if I did the arithmetic right. Resizing the swap partition is easy and 1 GB should have been more than enough, but the machine stalled again with 30-odd MB in use. In the distant past armv7 seemed to use little or no swap with a -j4 buildworld, now it seems to require at least some when building llvm. So far having too much swap hasn't caused visible problems, but that may have been an artifact of it not being used. > In other words, I expect it is appropriate to put back > the original size (or some approximation of it that > avoids the message about possibly being mistuned). > > > Everything that you reported looks to me to be consistent > with some kernel stacks having been swapped out for some > processes/threads that would otherwise be involved in > interactive I/O activity. > For the moment I've updated /usr/src, set buildworld to -j4 and am expecting it to hang sometime overnight if the problem is repeatable. As I write this swap use is pushing 600MB with ~60% idle time, which is far more than I recall seeing for armv7 in the past. It's still running, and the scheduler does seem to find threads to favor. The behavior starts to resemble aarch64 on a Pi3 but less extreme. For some reason the ssh session controlling buildworld tends to live longer than an ssh session running a tip connection to an adjacent Pi's serial console. Since the problem of dropped ssh connections hasn't been cured by use of vm.swap_enabled=0 vm.swap_idle_enabled=0 perhaps it's best to remove them, for sake of simplicity. Thanks for reading and all your help! bob prohaska From nobody Mon May 15 03:12:23 2023 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 4QKPZ03CPVz4B2fr for ; Mon, 15 May 2023 03:12:40 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic317-21.consmr.mail.gq1.yahoo.com (sonic317-21.consmr.mail.gq1.yahoo.com [98.137.66.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 4QKPYz74b9z4KXy for ; Mon, 15 May 2023 03:12:39 +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=1684120358; bh=CWN9ovSmaqM9MGi0EyYFhRF8s/X7bIhEBBI5UaujYdo=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=j766NwtnjOZibyn0C/1rQ5ELhiKktWeodwRSk9JeC1QPJ6Z9MKfDY8HG8vqeWpRWUgMJ46uzW3Z+0Q6/ByvKSGTz46qm+iwg5HL9yMuWFad7Gu3m0hSp3pjDdOCRNiUOaoUbQL5ez3HYD9u2Ow0BHP5/BRVMMILAucSbb9zO6L76gGi0RMq9MUaWMHhMqBkTX5nXotvEeHL9F3iPT3zBnqQjxI2pjYFM3RbgT6SvX/JGfxB7OGjgF5qECo0x0dWt1XiU32+/ujQae+evWXRwXDR3LE8j4x+7mmCEYx+cpF9IfFpVdeRcSmP5j/zaiWuyVRD7JEnHJVov6tFxwiU/PQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1684120358; bh=NMvwyKkeh7p6Cig2/laB65rz1QyA4WCRDMsXpwOttvX=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=hyIS56nzYDtDD1S+Ub6lErR6iXo5zxqd6iwLYu8n4EFwoc29iJJVZY9uSFcx/PPeEGqaJwpfT7WNkiMRQXuUlvGibh8k/fyq/TFlJQvo9ZKN0nLW+t7hGZOBBiqDKkO9jEU5TPD1IBkjvTRvoivBNNj5xBBDKpomd7PGEabX9L52XSixj5IaImTSY9riDYcy7oWMIqPq37STdfpZAfDrBq7Qxv8+rhgETpV+mI02txFdASrBSQk8eYQqvWpO5QJ0Rwy81ELyfc/eKl/pRSdt2X5fhszUphkuDuI7WcsKx2VoJSp8SKqbF+B7MTfbCCL3/q8TSqNf3dPq7qNo2xj3Zw== X-YMail-OSG: sYap_UcVM1n8qzvrn1tLD8LiLLUPzUIQ0PQBOiVvHU3SKXv19y7wc2NcrMDCugT Sv4nhdcBzJTnEuP_sroxHDd4NIyXRAhL6HH5Mi5g7ITJLqv_ujhDZf_YWqiWLuJRADJo8vD4WQo9 oz1hOVTnefC2.jxhbOn7DKQFbN1e6Gb9RT7FU071jiDD9I_KW7ewzqAVs9ejm_hoSOf95sCt0a0Z a44pIlm5xt3ttYuBraes462D6tHP8.wSYtX5icYLw6AuQMnfg_BPQaqy2PcIgGkgnMver20PWEWn ZUJzni4zOMZR_LC39YFGgSZvdL4dbeLqXH3qK3vi1RNeOjnNouuif3reOYPtP8bn1mvSij5s2tNS W6Ko1IZjqzHsOnkJLjECCKcxf_AYj7I4aJEzUFuOHz.U4Cw4UD3_EriPIYtyyn64FxZvVt9Ay_bv zdtsR8AYG88AUyOFboztfAIpn3XTPoMMq52ASlfVdkE04O5XA00m1m74WeaPNOPHWh6hBggTdXNb zTbo5HujXtEFpxvJeGX4Dj0P4irQ6d_iWpt87kBsXb9eExS.c7xg0Im1tBkxGE5RMrmdAagYv.Az Cbt.QRLydehSVPgUxVCoe5ARbqM7NM6YJ5Lhn73naTH0jnVkDigzVtvYvwrhcYtsr8t6KJ7EPhl_ Csri5M.b9WRfPIDKZAvBo449P7UT_J.7zz8tjCt_H2rnREc9TtMj6Zlj8CKIHSo2ipFkKEyzf5WB n4tE6InABrVYTI_Nj1mLTtgEWUN6G3lyDugQZIvyQGE6JvpDt5cQcRqzPG3QyELXj0rL0zF0M7NB .hLWYP8O0o3FGU4AIHBduALR6XsQ6nrV_QU3WVtNX8gKikjbLQL5xqnXDFmcJoo7I0QFXrJJIz.z nW7Xlkzdox_PDTSe57dq1W1J62N_Z.5dYEXlIO0_MrhAjR9n.mAcOf8ByFPfanBZ7VxjjthRnOF4 U7TbRle0Eg9bHpxwi6lJGEDfKAGvnYXC7tnZGNHUk3u4_ZTrZBa1so0K2lJlV6UmnkpbdLZ3vbPq Ds8puCmGj_XjY7.QG.F_99Rp29smqITXdV6sOxHLcC6I4K4xcy7xQmJ87tO274nbXPP101XzTJDt v7x.9H_r1a_RylSYjvDrH2Qo8VunTei.2KQ2MPB5o_xw16Wlt963pWYV7OVI564sAx9SDNDG4FmL QA1PqjzDEZGOW0KnKy6Vwhgn_1u.cqF0ZCkSsgPVsXPX04fW_OT0ibI5s37Tq5hdjlTndSwIKTje LinMEzNbex4Wh5K3PaXJ4NMgRny_SrgIFet_SP38FgD2BbIntjtnJd19C_o8Jajon6KoBleVQ8LL d7TYjAfnicFLu.2f3f4u11ZiCsh5fGXoXPLXHiTRdmHNzQoDsDI82lf_nkJuC8hZF4ExCF.HAccb OH1V_mwkstFos_5fpRnEhI.PAij5xBRMhPtxFEBbW8AtVLRTEYKhAq_oqRpRnuZA5UfTgeT75Fy3 DoDPCa2drg2perxAoZv8Ct0YiDBkSakdMXK0qMM88_1Ebm52ARQSOAUWXay8FSgCnsw9Bw4eAS.c yn4jbPQMf8sj8a6Ju5NwB.MSItiu09oNol93M7iMstVibuf5UOzUYxSTk.5zBEGl8R6V2KTE9cx_ ZvfxX5CBDJTeP2su1bHlOOILK0eSGhSaz0r5lb77y5iVzc8lG5.j3_o0ZHMFVKNYYv9SQi4Q.8qE NGcQNFApmCGoISZPZIIzNQG_8fbepR5Q2PgOIXN9r4HAB9mnWu1ycNYBWlduQJMG8QEQeNrhchzl VsxT87_45UIXLi71e_6_qi1fEgM_HDRfNy4tFB9TgPliY6V..z3vo9_lQ2HCA5V8UtfQhlXBbMRP xqxmtrkKyibMr2VWCJP4WvyuOMtOyKYfqaAWP6wXRcPt5.1d.eJe5ucYvYM1HvJc6LeDZ5oXx459 5LCuNM12ro0EbR1_XF8uPYsNOHqfqC2IS6tSTb.qInxLplx1hi0nUdVmViiXbbOfzTa7avTnblb1 AdZVbhDnxenTfkE9P_jsjwADiD1v7AAhM1AlGBSvkRcsJRms6Xwi4hAU_K1N5WMiBt3bVidGGl.q trhpop8A.uSnrtgMzMYbQtS07.4VsS.Ml07l6vtZ5S8thqr0TZ9UnEXsC18uoG10UCyyDSE3Ol5i wmv8XsPFip16xB8c5U22IF1NNi8Nohck1SqNbwjJ8MbaH2t1W6tK1GRob9H63ND6iZB8Q4XJDAjS 6IUaS2TOBpFwZ.ImYioVfFdag9.rzCeYLFOpO7zGWNVoZUQMLxbg.xNY5JirQAIPeokQNMM.RHfb g8w-- X-Sonic-MF: X-Sonic-ID: 24c8c4b8-d6dd-4b22-8eed-f3dcb4b601b9 Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Mon, 15 May 2023 03:12:38 +0000 Received: by hermes--production-bf1-54475bbfff-xzdff (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 665d70e0029b1916ece20d4fe77961f0; Mon, 15 May 2023 03:12:36 +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 \(3731.400.51.1.1\)) Subject: Re: Armv7 (rpi2) getting stuck in buildworld for -current From: Mark Millard In-Reply-To: Date: Sun, 14 May 2023 20:12:23 -0700 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <7758885B-3115-47F0-A453-1C010313D4B8@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3731.400.51.1.1) X-Rspamd-Queue-Id: 4QKPYz74b9z4KXy X-Spamd-Bar: ---- 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] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On May 14, 2023, at 16:58, bob prohaska wrote: > On Sun, May 14, 2023 at 12:31:29PM -0700, Mark Millard wrote: >>=20 >>=20 >> In my environment, I use /etc/sysctl.conf , which >> is a place appropriate for non-tunable but writable >> sysctl values: >>=20 >> # grep vm.swap_ /etc/sysctl.conf=20 >> vm.swap_enabled=3D0 >> vm.swap_idle_enabled=3D0 >>=20 >> I suggest moving the assignments to /etc/sysctl.conf . >> I expect that this will get rid of your problem once >> you reboot with them in a right place. (You can also >> interactively set them via sysctl use.) >>=20 >=20 > At some point in the past I did that and failed to clean > up /boot/loader.conf . >=20 >> I suggest avoiding confusions by not having copies of >> those 2 lines in /boot/loader.conf (where they will >> not work). >>=20 > I elected to comment the incorrect lines out with a note > indicating why. If I got confused once it may happen again. >=20 > IIRC the lines were added because ssh connections tend to > drop when the system gets busy. That's still happening, so > they're not the cure, or at least not the whole cure. >=20 >>> A running diary of experiments is at >>> http://www.zefox.net/~fbsd/rpi2/crashes/20230514/armv7hang >>=20 >> There you report reducing the swap space partition size. >> Were you getting the message about the swap possibly being >> mistuned prior to that? >>=20 >> For 1 GiByte of RAM 3647M looks to me to likely be a little >> below where that message about mistuning shows up. If you >> were not getting the message, the size should have been >> fine. >>=20 >=20 > The last "too much swap" message I can find was: > warning: total configured swap (1048576 pages) exceeds maximum = recommended amount (922200 pages). > Space was reserved for 4GB of swap, suggesting that only about 1.6 GB = is recommended > if I did the arithmetic right. Resizing the swap partition is easy and = 1 GB should > have been more than enough, but the machine stalled again with 30-odd = MB in use. My screwup: about 3.6*RAM_SIZE is for aarch64, not armv7. armv7 is more like 1.7*RAM_SIZE. For armv7 I've used: # gpart show -pl . . . 534528 3563520 da0p2 BPIM3swap (1.7G) # For 1 GiByte of RAM = RAM . . . 4311040 6291456 da0p3 BPIM3swp2 (3.0G) # For 2 GiByte of RAM = RAM Going in another direction: Note that when top displays something it is showing a point in the past by the time you get to see it. "32M Used" need not be even approximately true at the point of failure. And your first top output shows "358M Used", indicating that it staying small like 32M is not likely over the whole build. > In the distant past armv7 seemed to use little or no swap with a=20 > -j4 buildworld, Not just armv7. > now it seems to require at least some when building=20 > llvm. So far having too much swap hasn't caused visible problems,=20 > but that may have been an artifact of it not being used.=20 >=20 >> In other words, I expect it is appropriate to put back >> the original size (or some approximation of it that >> avoids the message about possibly being mistuned). So much for that claim. Sorry. >> Everything that you reported looks to me to be consistent >> with some kernel stacks having been swapped out for some >> processes/threads that would otherwise be involved in >> interactive I/O activity. >>=20 >=20 > For the moment I've updated /usr/src, set buildworld to -j4 and > am expecting it to hang sometime overnight if the problem is=20 > repeatable. As I write this swap use is pushing 600MB Like the "358M Used", there is plenty of evidence around that expecting a -j4 build to use little swap space for 1 GiByte of RAM is not reasonable for FreeBSD and its use of LLVM (even on/for armv7, as well as the other architectures), going back a fair ways: the status is not a recent change. I'm unsure if you have well avoided having any tmpfs based space or the like that would compete for RAM and use some of the RAM+SWAP. In the low RAM environments, I avoid such competition and use UFS to exclusion. I'll note that causing swap space thrashing can make builds take longer. "Thrashing" is not directly the space used but the frequency/backlog of swap space I/O. I always avoided configurations that thrashed for notable periods of time, via using -j given that I'd already avoied RAM+SWAP competition. But thrashing is also tied to the likes of spinning rust vs. various, for example, NVMe USB media. It is probably generally easier to make spinning rust thrash for notable periods. I'd also avoided spinning rust. > with ~60% > idle time, which is far more than I recall seeing for armv7 in > the past. It's still running, and the scheduler does seem to > find threads to favor. >=20 > The behavior starts to resemble aarch64 on a Pi3 but less extreme. >=20 > For some reason the ssh session controlling buildworld > tends to live longer than an ssh session running a tip connection > to an adjacent Pi's serial console. Since the problem of dropped > ssh connections hasn't been cured by use of > vm.swap_enabled=3D0 > vm.swap_idle_enabled=3D0=20 > perhaps it's best to remove them, for sake of simplicity.=20 >=20 No. Removing them would just mean there would be more ways for you to lose interactive control, including over a serial console without ssh involved if you had such at the time, not just over ssh sessions. I never claimed there was only one cause of control loss. I have claimed that these lines have been used by various folks to avoid one mode of failure. (Some times one is lucky enough to have one access path fail but another still working, such that one can inspect to find out the cause for the failure path was. Such has shown examples of kernel stacks swapped out. Such folks that added the lines cut down the frequency and conditions would lead to lack of access/control.) Separately . . . Your online file report says: QUOTE The disk activity light pulsed steadily, the the time display in top stopped updating and the = system was unresponsive to the enter-tilda-control-B debugger escape.=20 END QUOTE The disk activity light suggests that the system was still doing the build and what you lost was just interactive control and interactive monitoring. If you could tolerate waiting for it without access beyond the activity light, you might have ended up with a completed build. I'll also remind that having one or more logs with an overall high frequency of updates being written to the media adds to the I/O issues. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Mon May 15 04:43:32 2023 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 4QKRZw2Gz5z4B71b for ; Mon, 15 May 2023 04:43:36 +0000 (UTC) (envelope-from t_uemura@macome.co.jp) Received: from mail.macome.co.jp (mail.v4000-114.mailsecure.jp [203.138.86.114]) by mx1.freebsd.org (Postfix) with ESMTP id 4QKRZv0QgNz4QCq for ; Mon, 15 May 2023 04:43:34 +0000 (UTC) (envelope-from t_uemura@macome.co.jp) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of t_uemura@macome.co.jp designates 203.138.86.114 as permitted sender) smtp.mailfrom=t_uemura@macome.co.jp; dmarc=none Received: from towerrecords.dyndns.org (unknown [111.90.40.59]) (Authenticated sender: t_uemura@macome.co.jp) by macome.co.jp (Postfix) with ESMTPA id 27E6024D81 for ; Mon, 15 May 2023 13:43:33 +0900 (JST) Received: by towerrecords.dyndns.org (Postfix, from userid 58) id E2F1D9B8773; Mon, 15 May 2023 13:43:32 +0900 (JST) X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on towerrecords.dyndns.org Received: from [192.168.1.21] (p8585038-ipngn39001marunouchi.tokyo.ocn.ne.jp [180.39.37.38]) by towerrecords.dyndns.org (Postfix) with ESMTPSA id AC6419B8771 for ; Mon, 15 May 2023 13:43:29 +0900 (JST) From: UEMURA Tetsuya To: freebsd-arm@FreeBSD.org Subject: [patch][RPi4] Add support for BCM2711 GPIO pull configuration. 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-Mailer: Becky! ver. 2.81.04 [ja] Message-Id: <20230515044332.E2F1D9B8773@towerrecords.dyndns.org> Date: Mon, 15 May 2023 13:43:32 +0900 (JST) X-Spamd-Result: default: False [-3.15 / 15.00]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-0.99)[-0.993]; NEURAL_HAM_LONG(-0.96)[-0.961]; R_SPF_ALLOW(-0.20)[+ip4:203.138.86.114/32:c]; RCVD_NO_TLS_LAST(0.10)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[macome.co.jp]; MLMMJ_DEST(0.00)[freebsd-arm@FreeBSD.org]; ARC_NA(0.00)[]; R_DKIM_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; RCPT_COUNT_ONE(0.00)[1]; TO_DN_NONE(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MIME_TRACE(0.00)[0:+]; FROM_HAS_DN(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; ASN(0.00)[asn:2514, ipnet:203.138.0.0/16, country:JP] X-Rspamd-Queue-Id: 4QKRZv0QgNz4QCq X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N Hi. As I've commented on the bug 256372, the current FreBSD's BCM2835 GPIO driver can't handle internal pull up/down configuration of BCM2711 (the SoC on RPI4 family) GPIO. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256372 Fortunately NetBSD has support for the newer method and it's fairly trivial to port it on FreeBSD, so I've written a patch. Please someone test and commit it, or if necessary, I'll create a review on Phabricator. Thanks in advance for help. -- Tetsuya Uemura From nobody Mon May 15 19:14:06 2023 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 4QKpvg6dn8z49ySt for ; Mon, 15 May 2023 19:14:23 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic310-21.consmr.mail.gq1.yahoo.com (sonic310-21.consmr.mail.gq1.yahoo.com [98.137.69.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 4QKpvd41vYz40mk for ; Mon, 15 May 2023 19:14:21 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=ELKOKY6Z; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.147 as permitted sender) smtp.mailfrom=marklmi@yahoo.com; dmarc=pass (policy=reject) header.from=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1684178059; bh=0aJTkavWviQNntnKJNEnyMq8uAy9GuJit0F6/GZ1rw0=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=ELKOKY6ZMB3PrhGVEFTHQtDaQwlla8X12UF4D9IrNlKWk4xLHH/Z1yWaymO8Cfu2lV/Sfq5uGABwk9jEtL+nJi9ldMFCKpoiAmrDBBCO+4BkkKHpTDS/Ucownd6YVdtMtlBttlwvtchqS9n5Xu+zjFm4pwF5R/WNmuZ843V8o9c2XYIX13ygMZhe8nDPTe6fCHCG+liIChBd2Egb5zuoc5k1RJJEm1KwTh1O/ev4cWnw3a0OgZIXwspEg/XmSgPiNvQy98Tcj3HN2T4mf4I1AfXJBz94PY0Tn8NaYz+6G7tT+XURwH1LqpeFXUr5+fM9vpqGyHpP7RPFAaUvzsMHTg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1684178059; bh=fFN7KHaZtwkyU+rcIocszw2wslTHjST9/TaOx2T2oOD=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=DOfZgwsGdWirhHfEIRRV1vAvnZRNjIqKmzbBk0Cve1WBGAdaTwj4EfgDIKcOPvKpquSZFyI0soupnuwXTNsYQm/iyb+Z6ZsstPkLc4pMsmA5vfUkfN7IvCbAgAwS1/LbfZoTuEgruj+QSSsdUP1YhM9ZkFZD5V9uq1/zZHRxAy0hr1pCYLRSe+gm8j+cnMLN7Scr53p23Mj6SidAAEwLgAj6tk7s/HyoJ3wGnjl5qoWt7HhRXvFZzodlhHr9IjzdHJzNcZT12yZxbSc1d6+DM2+J5AOk6lFZDGBPdBezYlaH9WUN2J+lrpPBoIfw40XZYPDXjWjnInfqnh9oqep/qw== X-YMail-OSG: rZzDOwQVM1m.aPAJnWHh18C4eZdTGOdu7UDMFM5IV69h1p_X.qLz1dk1JqP.jvT ry1ESGcEJmWf3curJJ.WEcEaQocay34X6NYTeydokwBHLzOZQIG1VjypzpAwvt63Z58p38NBd_2B sUc0.2A5RfUuy4wXW0McJYRdiC7njkuEPWeTyD_MWjJqerbviN.jZREgbxVtrCFWFMzvQ4cwju4Z dsJal0AMF1cGVxVZ.Y.ZSkNcOEXR4g5pnPE452uuc..Qdf7ImXRmUQ5KvxfK_.WNF2HHeQZqid8A rNErh13Fmxww9DuMtvb74sN3zCulx94gUTbX1FIw7jjxOs.oPwWVPXV6R.Xro_XtQDJAiqbvbc80 Y3_9Zp1RO6JDZx5qHcXZ4jX9jNUmryLdH1i2M7dXDleW7jLeCI0Z6tdNzeKzcfqEuQOGJ_gEwHO2 6lDfbfZLfwEgUl5Zyr5U3x8RADSscESlZ3pcu0fUZl4EVlq3S2yG93FOqwiI3l.oEAlMe1uhMRdv 5WUe.WpQeYMBtfrxRPJNG4sfWVPAsq1Y1e36DcEeKPh3WA9X4VqROz68R196E3g2RN2Bh.BAsaC8 BWwair99x80hM7WRGSP4MB0e9oryU.kA1jGCMI_xX4P7VjAhlNndfKAoTxXbMnMhviNGgzg8yH2m 1FxYCvwvg3LtJXdCx9mm91DMVztJmU6uh5DKKfOUXntlbCh.RzeSVAafDu63kmw41W1n5BayHEOW 1SRlDhtEbJc5xa_VD88_KsHQYCQ3c94xso1sBaSwvYOAB2yS6faxaJNKanO7YUSWbSnssa7.1dp4 t4J6ktJKPFLiWkT3R._zqZY.o85vSUEX2_2mM99Z8OnXgeEsdhAjY0QqMyIkvegDO7GKm8pwT8vA uCwPOVTI3cQsHbmT.KTMDVi4CG7D7rkIkM0iQqQKRWwacR66VUFs.UfXsGhUMB5GD3JiJzwHmoJw 0O2kspLaDByfwcJYd9JpGYzRdIYdxJKj9NvJC7ScZFJpk4vJbnMXr4hNr5tPCRDzAi3HB1smJPDK YDEA3JlOV7TJEe8YYXyMhDpwySC.m2ukTR9UcTNSzOzviu6LZBGj4d93aIn9lPLONzdPQZQ7p8JC aO6UQJYfmYumrM4zQqROd.a45N_OucovPpC47vXVoDDsNw9P9VVT.0M5f50QCjb2u_zeZP2B3TH0 PKbFTFidrqJtUIHWWhTpx9OrgcDhyPHQT61WZxwnxU8XhOAepKtb1i1iPxzqryzW6ZwMjHf.pvoK 1doo0FllQl8SKJu7QV01y6ylSMyqduTnWyy8NavBx5mZhIAbeY6.zunAjQtCLGa84C5x0n.s2USu v6zgASaKK.pYI9mfnz8obgU.WDnWXwmMizBUeUT3p10KNoooyu0edp9qxjjv0mi7yolYp2iSY8c0 UAxHa1xxRCdRA1B0i_pcwYAazGhKawWj.cAluAyMDLL5Co1utwugWlbelqN.U6cPyQSK3QaHX5M. _6vdHt.w8EtviQnOVP6oUWYznQaY4YOzcShZDQg2wNYF2UIm7iz8HgzvPbtUI6aBuLmvJIXfBkl7 PX5aRkFJndYOWs.RUx1tBb1cwX7YqAMO1WhvCE1GE9cLyE_ixE.Zix7AFnRi2gQ_tKHET5kzRw6w WCNy87Jlg3y9Awod3BoHa2FQvULVzZf9YSfuYJC5y6VA30tAB1mpH4OW3CtrgxXg3et.S0nRtRvp 9_aRWrKKKExQIsWIp8Z3qEqUy7YYdhGlLHDC.v0jyqY_UZXF7_YLQD0muAeIyflYT3OpDo8SxJ85 BnBtW8tKyW__zdDG4WEDBKrb_r2.NpmEUgkUbh220AqMZEY.1SnEWrK9T4AQgN_hrj4VL.VEMQpr udo_7K4CZry7t763FWn.wdHwihPf_RSdu_mv7tEOZxN6phe4pMHL35qsGtC4wyKi5q8Vzw34c5QW AVvPiSw80aPdlCSz8KbZW_mibmoZ8xdTwlIqJA0EWSB.qUvRdgYv5rGbetWROgSpNfzNQ1jFcwDM wfCihDnvny345x5.xptmLrjmRKn3k.zqjLdPsNRz3rHO0iqJIWFNMfJa_7aXiSXNoIroVTjm3oOH z7G3Q5tRdg_n0sY.WX1.CqKibnpsMTRnUthqj.lwSgtdD9j_eH16ZK20CBPq4JWiJz3Ubpc5cRoA WgUsmOK.i3vafH0JOcBo5XahqNjNXkgiAWmesGgByOYC2sRQdbFDc6znPaDzdhaqf7tY.p4d0Gio waa1Q8l9UAbn.RCacIQWcDqbFZviKg0jZkifV_Brgv7g3Th79A.1dYpK2960jfM7eUMKNd1c2pMg - X-Sonic-MF: X-Sonic-ID: 5332199f-a968-42e0-9abd-8aaee810364f Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Mon, 15 May 2023 19:14:19 +0000 Received: by hermes--production-gq1-6db989bfb-hz24p (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID b58914027e833400d5ed5ce1870fd9e6; Mon, 15 May 2023 19:14: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 \(3731.400.51.1.1\)) Subject: Re: Cores of different performance vs. time spent creating threads: Windows Dev Kit 2023 example From: Mark Millard In-Reply-To: <11EBAA22-6E0F-4B27-9799-7786E149D9B1@yahoo.com> Date: Mon, 15 May 2023 12:14:06 -0700 Cc: freebsd-arm Content-Transfer-Encoding: 7bit Message-Id: <47DE0BF6-3A16-4F87-AEEF-6D320BBC90E5@yahoo.com> References: <11EBAA22-6E0F-4B27-9799-7786E149D9B1@yahoo.com> To: FreeBSD Hackers X-Mailer: Apple Mail (2.3731.400.51.1.1) X-Spamd-Result: default: False [-3.38 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.88)[-0.884]; 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]; MIME_GOOD(-0.10)[text/plain]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.147:from]; TO_DN_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; DKIM_TRACE(0.00)[yahoo.com:+]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org] X-Rspamd-Queue-Id: 4QKpvd41vYz40mk X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N On May 9, 2023, at 19:19, Mark Millard wrote: > First some context that reaches an oddity that seems to > be involved in the time to create threads . . . > > The Windows Dev Kit 2023 (WDK23 abbrevation here) boot reports: > > CPUs (cores) 0..3: cortex-a78c (the slower cores) > CPUs (cores) 4..7: cortex-x1c (the faster cores) > > Building a kernel explicitly via involving -mcpu= use > gets the following oddity relative to cpu numbering > when the kernel is used: > > -mcpu=cortex-x1c or -mcpu=cortex-a78c: > Benchmarking tracks that number/performance pairing. > > -mcpu=cortex-a72: > The slower vs. faster gets swapped number blocks. > > So, for -mcpu=cortex-a72 , 0..3 are the faster cores. > > This sets up for the following . . . > > But I also observe (a relative comparison of contexts > via some benchmark-like activity): > > -mcpu=cortex-x1c or -mcpu=cortex-a78c based kernel: > threads take more time to create > > -mcpu=cortex-a72 based kernel: > threads take less time to create > > The difference is not trivial for the activity involved > for this WDK23 context. > > If there is a bias as to which core(s) are involved in part > of thread creation generally, it would appear to be important > that the bias to be to the more performant cores (for what the > activity involves). The above suggests that such is possibly > not necessarily the case for FreeBSD as is. BIG/little (and > analogous?) cause this to become more relevant. > > Does this hypothesis about what type of thing is going on > fit with how FreeBSD actually works? > > As stands, I'm going to experiment with the WDK23 using > a cortex-a72 targeted kernel but a cortex-x1c/cortex-a78c > targeted world for my general operation of the WDK23. > > > Note: While the benchmark results allow seeing in plots > what traces back to thread creation time contributions, > the benchmark itself does not directly measure that time. > It is more like, the average work rate for a time changes > based on the fraction of the time involved in the thread > creations for each given problem size. The actual definition > of work here involves a mathematical quantity for a > mathematical problem (that need not be limited to computers > doing the work). > > The benchmark results are more useful for discovering that > there is something to potentially investigate than to > actually do an investigation with. > Never mind: Starting over did not reproduce the oddity. So: operator oddity/error, though I've no clue of how to reproduce the odd swap of which cpu number ranges took more vs. less time for each given size problem. (Or any other aspect that might be considered also odd, such as specific performance figures.) Retry details: I booted the WDK23 via UFS media set up for cortex-a72, media that I use for UFS activities on the HoneyComb (for example). I built the benchmark and ran it. As stands, I've only done the "cpu lock down" case. It produces less messy data by avoiding cpu migration once the lockdown completes (singleton cpuset for the thread). I'll also run the variant that does not have the cpu lock downs (standard C++ code without FreeBSD specifics added). === Mark Millard marklmi at yahoo.com From nobody Mon May 15 19:39:32 2023 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 4QKqSs2gz1z4B1N8 for ; Mon, 15 May 2023 19:39:41 +0000 (UTC) (envelope-from jfc@mit.edu) Received: from outgoing-exchange-5.mit.edu (outgoing-exchange-5.mit.edu [18.9.28.59]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.outgoing-exchange.mit.edu", Issuer "InCommon RSA Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QKqSq67dFz48JN for ; Mon, 15 May 2023 19:39:39 +0000 (UTC) (envelope-from jfc@mit.edu) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=mit.edu header.s=outgoing header.b=HTUQjgS7; spf=pass (mx1.freebsd.org: domain of jfc@mit.edu designates 18.9.28.59 as permitted sender) smtp.mailfrom=jfc@mit.edu; dmarc=pass (policy=none) header.from=mit.edu; arc=pass ("microsoft.com:s=arcselector9901:i=1") Received: from w92exedge4.exchange.mit.edu (W92EXEDGE4.EXCHANGE.MIT.EDU [18.7.73.16]) by outgoing-exchange-5.mit.edu (8.14.7/8.12.4) with ESMTP id 34FJdYwi031228 for ; Mon, 15 May 2023 15:39:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=outgoing; t=1684179577; bh=yXsAahNz+d1JKV48uc15dwBrQ4DQZU/OuMYwG4PMBGM=; h=From:To:Subject:Date; b=HTUQjgS7xAJwGDC9b2mbZTokfMQYLZGk6gZdghSQIVCH6drlc7U8U8HSOA7KyQmBU ss4Nyp5LxCwwzoTsqczGvdULDv+lcvPT3n/Ojw/e+jukDQnKhJ1N2XYyR8k+8arX4v 4jaqokdJqVfvMqWoVGEyk9fgwSnAmX3YpmvTipJ+4k238y7gLAsPxQTDjnBXPwPiN3 +0OFu7XxDOsPPrKbRur1VxdbLm8WCPff3uLit3gxv8FfuAn1y/8SxXB055ttPQ3rB5 UIPmbYVwREk/nULWlZC4M2tJ7e+1nvRpMgXBxzawYbrJhOZsLqtO7rzd5CIr9hJBj7 g5BPR8oplyb/g== Received: from w92expo18.exchange.mit.edu (18.7.74.72) by w92exedge4.exchange.mit.edu (18.7.73.16) with Microsoft SMTP Server (TLS) id 15.0.1497.48; Mon, 15 May 2023 15:39:31 -0400 Received: from oc11exhyb4.exchange.mit.edu (18.9.1.100) by w92expo18.exchange.mit.edu (18.7.74.72) with Microsoft SMTP Server (TLS) id 15.0.1497.42; Mon, 15 May 2023 15:39:35 -0400 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (104.47.56.169) by oc11exhyb4.exchange.mit.edu (18.9.1.100) with Microsoft SMTP Server (TLS) id 15.0.1497.48 via Frontend Transport; Mon, 15 May 2023 15:39:34 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=iyMON54iZlL3n73DW62yECVwi0dBE018le70EIkGoJJ2RzjwUFRrtm1Psc+SbhYttEhrmLvjanTPcOJpR5iDO95BD2oIWN7sWMjOCp7oo4L2DRpWlXbjSqztS96B5ONGQJ4uBu+b4JsxLX96Qgn30AomlGu6tnj7RqrUBf4vcTxPOtjld+D3Gimtha1utVevUFH1rWj9mwab1biGSYWlJmo8w3ODltxIVLSJNnA8dojVgiFlAgMgBOWxX3Iqyh+HLDiU0HuyyV+lvjD0jlXu6aU83Xa6wKy48P4fVPeMTlOdQMcRICyGNpxBWW3W/gZNZBGSBq0BoD21wJJgIw7DlA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=yXsAahNz+d1JKV48uc15dwBrQ4DQZU/OuMYwG4PMBGM=; b=jRkqIq932kA7tPYC/d7xGDDiM1pe0nJ2+9AHOIZ9tDiGquoW8DGw8vwRqmD6oUZNxVmnH0zM6UiJaWTJ/1JsibqPNrKl1JmT4OdcF12NaZYK+Q1cFz1k7L9GixRlku0MbZeBu7e0rfit3yV4m29tyPw/4RATSV7aqvVsa/Wwj8ZjKRG+Oyi2C9oxQrVr1Z5lwuL5m6erd2J+BajhqaVGGorX+B0nokmiaL/2D4kajnPdSfvRF2q1BFtT/8qFZMgRFlJqrnyXd5NYlx2w1A1nnh2XNyuQ2OSbFq1ykCb8yvScnRZawjE+j1SVchsRjXCh+M87s/VQst8NCaUcYos94w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=mit.edu; dmarc=pass action=none header.from=mit.edu; dkim=pass header.d=mit.edu; arc=none Received: from DS7PR01MB7712.prod.exchangelabs.com (2603:10b6:8:7b::17) by BYAPR01MB4072.prod.exchangelabs.com (2603:10b6:a03:5a::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6387.30; Mon, 15 May 2023 19:39:32 +0000 Received: from DS7PR01MB7712.prod.exchangelabs.com ([fe80::5d78:4464:66e8:94a9]) by DS7PR01MB7712.prod.exchangelabs.com ([fe80::5d78:4464:66e8:94a9%6]) with mapi id 15.20.6387.030; Mon, 15 May 2023 19:39:32 +0000 From: John F Carr To: "freebsd-arm@freebsd.org" Subject: ARM64 virtualization? Thread-Topic: ARM64 virtualization? Thread-Index: AQHZh2T4nGnH5YTU/EmJR4rkd+5o0A== Date: Mon, 15 May 2023 19:39:32 +0000 Message-ID: <7CCEC16E-41A1-4318-B953-EF61D17EEE3C@mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-traffictypediagnostic: DS7PR01MB7712:EE_|BYAPR01MB4072:EE_ x-ms-office365-filtering-correlation-id: 9135d02b-6c0d-4149-ccd3-08db557c1b21 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: O9RysZeJVaDhKCN7DPAE3E9VdbMq//vIpB99rUJcu7/SrAYMdPe/OAQmNPIMomA//wGQ8Ge/bpPqd696ldUpyVBLpVZ55I3CITV07IADax65+TJazvf4mfETfpeWKgA84smgPmBDxsWyWzaj4+z7uaLFBa61Qhfo8be4NZXJTelQ+jNe97TzVXH8NPG+0/qh7B12GeLhkO17gltvZD6n+tTi73RDi70A50pEFQHU6awBpubjagfam/9ym7raC8ANJk00TgGd2GvRrIeVu0ZnMK6y+KH4N6NdtAvongp3aDFzvkhrmXENvFI+7DFIQUIszBGDkVponP2PpND8MmkBpplODk6oG1satWEepOSPhD+7GptEL0qHZOwVLaPu29hgTQa8PTTPFOUv/b1LLf+zB9zZFQs/G7x/s+OstX1QOeKUeDITENApHZBYNoTLYfktQPpKjZs/yWVHwKmsHBv9SvGvP5Z7wIRiHh2QyZJlMxFTphH+x1955qBjGpzsnp9OThugrk0ywQX/oYeFSpYbVIvsw4er9IIUrTSMQY8JDo+fGkRUQp9zMx4lrKQMdyWGDWO5UD4vgKBFy0Cf267dJa7S6onCUUVtjqv7SRVLaHM= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DS7PR01MB7712.prod.exchangelabs.com;PTR:;CAT:NONE;SFS:(13230028)(4636009)(136003)(376002)(346002)(39860400002)(396003)(366004)(451199021)(75432002)(2616005)(2906002)(76116006)(66476007)(6486002)(66446008)(64756008)(66556008)(91956017)(966005)(66946007)(4744005)(478600001)(8936002)(8676002)(7116003)(26005)(6512007)(71200400001)(186003)(5660300002)(41300700001)(6916009)(786003)(6506007)(316002)(86362001)(38070700005)(122000001)(38100700002)(33656002)(36756003);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?FYEZcLS2/0D0r8Rob6aDIUisKNm836pYQQc+i7LPWjPYccP5KW2vQjFEYazs?= =?us-ascii?Q?dmLbLWdYsUuItCKe32caR/JxCZo1R6ENAD0yDRvh07fK8NFvws3BoBhCrcji?= =?us-ascii?Q?rBiH45SIxkfwvEtLRdPyA055vDdPG3ZDnSVPRhTAg4CrvbJhzxJp2zkaIzX7?= =?us-ascii?Q?3bSWQ/TcBgtctDRvSE3G0YP67mNcQWg9yvSbzLPLn0yvUfebocAK2Jnc01Xv?= =?us-ascii?Q?ZOS0fbOy9omlTvKcUisX3o9WZte+m7pAcvjachUJZFg2/dtcB2LMwjAxc4L6?= =?us-ascii?Q?rhnA10XAylCfUw9MJPqIA5SUJZdmfZX84vXw0Attd4FpM0cpiLs+vsgEupoX?= =?us-ascii?Q?erOuKXIOdiVyMM1D8oLFDaW5ZviPuAFN8OXeMx/yUIcOx4kI6jlEfycEI+Kj?= =?us-ascii?Q?bA2Cgs5rj53Vc2PAnu2i4ZMjZp4JX1sn/M6ceL2bT0+uQb31RaYXPze8Ubxv?= =?us-ascii?Q?rxUvIrG9IffA5PvE9VXxZwc0vlD3hvz4k5ui3DC3kpoEpq+PX57PgWGj3Umg?= =?us-ascii?Q?qSfJXhB4X4IFw4TMxAhf5iypxItJk/Cz3C70stNwYwNEjU3JW8d/1DNb8VfW?= =?us-ascii?Q?jMl3V6ONrhZLPLazS4O+IaR5onFEIdUFKDpMFjKhTfFQnxv3x03nnobrHdvs?= =?us-ascii?Q?aX1vQcrskX4yN6Hx+KB9iL2ey5Xb1S0exiTMsr/gn2FLqmcq/3bDGcvWrjtQ?= =?us-ascii?Q?GP0tV7eZpMo5iU3egzvsN6qiqwshdJpdXeC5pD5j880YjmzpVQ8M7Am6H8nz?= =?us-ascii?Q?+1jCkaUTPe+R62HWWBXJSIxciNuQP7EW5iqDYJ7BAVVX2WJGT30h3i0Qn0Wq?= =?us-ascii?Q?U2ZUSiau//wmKHStrnRiDRpVQB5tp2mHrDiQrmxns0614ha1rCM4ambFZYoC?= =?us-ascii?Q?EbsE2cDJT74MRUz4UhfT/7pFYrd/862uHuuFBCnOJNVL989mjm8/B2CoaSEx?= =?us-ascii?Q?roRNmgORWY4CQPVnBhEKWzOGX5vyMaV+ZnlL3pEq/3QKt21HurROg2iUM7rH?= =?us-ascii?Q?VcbuY9Pm8NXzxbZ1UwPlzy9MsMptwB7mK+UhmCkurJIvusKJEpTxuNzOU+f2?= =?us-ascii?Q?HO4mVZHoc0/Y41uhoY9N3PPJYQTtVpYEFCQZPmr7/sgsxL9AYYoVhufPmiZL?= =?us-ascii?Q?iKL5JdMQLTS8/TOePcW4x2pgTXbG6c7nEhBonzEVDuyWYr9AS6tRHc7v9Uk5?= =?us-ascii?Q?pThPA1wy9MJyWF+LQcYrkMe9WV2H9foj40DFCag3vx6qDgOsQLA+OwDQYO1N?= =?us-ascii?Q?7XCKj2EK1MKzie3VwSmBNM0gZP7kD2eM3JpbjtexCPgs3UI20kCnN3Sv1iMj?= =?us-ascii?Q?pGbTh0qZGS2rZ1ZZJ3tS+g6o0uxcLM4arayGu3INqEXmqbLZG7pTl+jWHz0x?= =?us-ascii?Q?UB7CmR305+pWXkUtGIPV6guMA/bh89XNwpohUlUG7wFU59AJESGU2wANJSVj?= =?us-ascii?Q?60+DqGuJGAqJQukED/8qdfSPeJRmCOti3/LEDcPHQ8+6sPm1I98AvKa3e2p9?= =?us-ascii?Q?a/dwGbVJTuqeSkjMikjOgeyiy2Bi7CGUtiWZKPFMFN0OXNlxX2sqrJQ7eHSn?= =?us-ascii?Q?OcOiYoM3dIDI8FSaosE=3D?= Content-Type: text/plain; charset="us-ascii" Content-ID: <70890F5033FC0846B7E07D6F3A8AA7CE@prod.exchangelabs.com> 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 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DS7PR01MB7712.prod.exchangelabs.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9135d02b-6c0d-4149-ccd3-08db557c1b21 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 May 2023 19:39:32.1961 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: m9RKnO5ip0kLjoIqHHkrDHo3s8aIBQDbipbZd/bly7nU92kThuZ+SWvQei3+3Xxa X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR01MB4072 X-OriginatorOrg: mit.edu X-Spamd-Result: default: False [-5.70 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; DWL_DNSWL_LOW(-1.00)[mit.edu:dkim]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCVD_DKIM_ARC_DNSWL_MED(-0.50)[]; DMARC_POLICY_ALLOW(-0.50)[mit.edu,none]; R_DKIM_ALLOW(-0.20)[mit.edu:s=outgoing]; R_SPF_ALLOW(-0.20)[+ip4:18.9.28.0/24]; RCVD_IN_DNSWL_MED(-0.20)[18.9.28.59:from]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_ONE(0.00)[1]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; BLOCKLISTDE_FAIL(0.00)[18.7.73.16:server fail,2603:10b6:8:7b::17:server fail,104.47.56.169:server fail,18.7.74.72:server fail,18.9.1.100:server fail]; TO_DN_EQ_ADDR_ALL(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[104.47.56.169:received]; ASN(0.00)[asn:3, ipnet:18.9.0.0/16, country:US]; MIME_TRACE(0.00)[0:+]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; DKIM_TRACE(0.00)[mit.edu:+]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; FROM_HAS_DN(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCVD_COUNT_SEVEN(0.00)[7] X-Rspamd-Queue-Id: 4QKqSq67dFz48JN X-Spamd-Bar: ----- X-ThisMailContainsUnwantedMimeParts: N Is there any active work on getting bhyve virtualization working on 64 bit = ARM? I see some work was started a few years ago (e.g. https://reviews.fre= ebsd.org/D26976, https://bhyvecon.org/bhyvecon2016-Mihai.pdf). It seems to= have been abandoned or at least stalled. I may be able to help. It's not a project I can take on myself. John Carr From nobody Mon May 15 19:58:38 2023 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 4QKqv12QRLz4B2HY for ; Mon, 15 May 2023 19:58:53 +0000 (UTC) (envelope-from mgrooms@shrew.net) Received: from mx1.shrew.net (mx1.shrew.net [38.97.5.131]) (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 4QKqtz6Sr7z4DB4 for ; Mon, 15 May 2023 19:58:51 +0000 (UTC) (envelope-from mgrooms@shrew.net) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of mgrooms@shrew.net designates 38.97.5.131 as permitted sender) smtp.mailfrom=mgrooms@shrew.net; dmarc=none Received: from mail.shrew.net (mail.shrew.prv [10.24.10.20]) by mx1.shrew.net (8.15.2/8.15.2) with ESMTP id 34FJwjfj069097; Mon, 15 May 2023 14:58:45 -0500 (CDT) (envelope-from mgrooms@shrew.net) Received: from [10.16.32.201] (unknown [63.151.186.58]) by mail.shrew.net (Postfix) with ESMTPSA id 32FBD193F86; Mon, 15 May 2023 14:58:40 -0500 (CDT) Message-ID: <2f69f9a1-e976-65d6-c0be-74404640d1c1@shrew.net> Date: Mon, 15 May 2023 14:58:38 -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/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.10.1 Subject: Re: ARM64 virtualization? Content-Language: en-US To: freebsd-arm@freebsd.org References: <7CCEC16E-41A1-4318-B953-EF61D17EEE3C@mit.edu> From: Matthew Grooms Cc: Elena Mihailescu , Mihai Carabas In-Reply-To: <7CCEC16E-41A1-4318-B953-EF61D17EEE3C@mit.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (mx1.shrew.net [10.24.10.10]); Mon, 15 May 2023 14:58:45 -0500 (CDT) X-Spamd-Result: default: False [-1.74 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_SHORT(-0.97)[-0.967]; NEURAL_HAM_LONG(-0.86)[-0.855]; NEURAL_HAM_MEDIUM(-0.62)[-0.616]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; ASN(0.00)[asn:174, ipnet:38.0.0.0/8, country:US]; R_DKIM_NA(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; MIME_TRACE(0.00)[0:+]; DMARC_NA(0.00)[shrew.net]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_CC(0.00)[gmail.com]; RCPT_COUNT_THREE(0.00)[3]; TAGGED_RCPT(0.00)[]; TO_DN_SOME(0.00)[]; ARC_NA(0.00)[]; RCVD_TLS_LAST(0.00)[] X-Rspamd-Queue-Id: 4QKqtz6Sr7z4DB4 X-Spamd-Bar: - X-ThisMailContainsUnwantedMimeParts: N On 5/15/2023 2:39 PM, John F Carr wrote: > Is there any active work on getting bhyve virtualization working on 64 bit ARM? I see some work was started a few years ago (e.g. https://reviews.freebsd.org/D26976, https://bhyvecon.org/bhyvecon2016-Mihai.pdf). It seems to have been abandoned or at least stalled. > > I may be able to help. It's not a project I can take on myself. Porting bhyve to arm has been one of the longest running UPB projects. You can find more info on the history here ... https://wiki.freebsd.org/DevSummit/202303?action=AttachFile&do=view&target=Presentation+-+bhyvecon.pdf Your best bet is probably to take a look a the following review opened by Andrew Turner late last year. His work is based on the original port by the UPB team ... https://reviews.freebsd.org/D37428 I can't speak to the current state of this work. From what I recall, there were several attempts made by UPB to collaborate, but they failed to get a response. Perhaps he/they can chime in here with more detail. -Matthew From nobody Tue May 16 09:03:50 2023 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 4QL9K32QYcz4Bn5B for ; Tue, 16 May 2023 09:04:07 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic307-54.consmr.mail.gq1.yahoo.com (sonic307-54.consmr.mail.gq1.yahoo.com [98.137.64.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 4QL9K16GPLz4LLK for ; Tue, 16 May 2023 09:04:05 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=B8aTa6Xe; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.30 as permitted sender) smtp.mailfrom=marklmi@yahoo.com; dmarc=pass (policy=reject) header.from=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1684227843; bh=uHAm/Id2CiAHOzt0dBbycNC8tIqrvrpr5tlPoU65UJs=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=B8aTa6Xe3dJjd6tPEETZ+foI8Wbguxbbj6kvl5ySN/+TM+IxRpHhzB8bYlgAoPO3RZ+XgQ+SgzX3nXh5ho5HtYJZlxPN2Jl0EqFmQ0pEKVqRaz2ONnghaQsSorTH4tNCflgTysFGxa1mic9pvRLnD4Nid2ef3W5xLBLPqU9e27cmUrcWbqFqoQznEJt+7kW+ZygVTzlJAlJaJ81AtWe3AOVjjlEApbgi/lwtb6wtDb2e5Hcr2NsiHfyiYwZXLejd8ut7gk8CWozXr9DFwwLcdMRK9dZDZFe3FcEVjiaYbnsbxwj5y55TGxjDwHDPKXZLF1pFFY/ZgPSOypbiDf2taA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1684227843; bh=sq6I+q2uLd+pRzGDtTqWbtNVf67Cc7NvM/IolWPAYeD=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=REMYnE0XLb8MQIR6S5Q+OKqNAUTY0FJTV1pYGPnCeUafoWuuB3kdL6sHAnhRz1HuErjKj3nmJrI+oEc8TkagVhW2KWqH9FB3ltLfvGYbWStIZnmSMDFLyPJAOQqmN8kYrwUdgZSyPOVhz2ZMnuybzFxzyAWenGLMxlTTuNvI5FhTtpb5qLA+kcSsrSyqYggcyaK6E+Y0zqnSyJxVjZryq0pHXbWq38YUO3PbU8RlatzKfL3z/IYKD4bC7lWJrNeYnMOw6BIsjInY02R53gP5sxvlUm5IX4P9Xh+Qcy5t1Dr4pXPLIyFOrRbq1o1fCTH62T/r8KS/wfcuNcAeYA6wEQ== X-YMail-OSG: Wsgz6dQVM1nFzJdoAKEmSNG1znuEg8HWQ5sf8UOMC6NIC2uJiXL.JrP9y.5RXF6 2D02jSBCEVUVw3f7fTz2nYYkxp6NDstXW54JOMVny9BT0laLYS48krHKRVFSVgE32Y96akiNE432 hFXwoyBJIO.x86Xh4_mA9CVwSMa.cdKBhs.ZwesXKfR4LEaurBPsw36phPd7rAgYqFylZZ4Qfern g6sVptiBBYuNlRH26mC5qbqWgSIretL6FLIpZ3gl4sCmzlkkTC1DQX1eIzQVJSKM5F23TvZA2DYu RPXxeUSgQdsgoFH35ZBnmZXUP7v3Q3GUTLYhiKqX.6d8OH5insjmuqW4.S7S0J5AAowI1M17KTDP ec9S44GbE9RMopBzrmW93LVF6d6ta3O9O4rgqG7.hI9IH1aI0ljJL73EpQvkYXJ6weYL7XPRE4M5 8Ury2kFYAZxewHGfN5epq.Yp3XY4c2Vtr_BtlC5XyVd1HmnQrraDrsewfU3C2bQN4nT4EHRhlZ8m fdDph60ai4TzKrYVzWWmA5tnYRqMtS8vXRwqusGQtuJgQXm9fVyUkWKSwGqk3_dv406nlZRoFZRs Sh2KVdpUm7LY2EfT6gR7NBvnKHTUaga7Xr6whp4eMkYQnMacys1SwmmiyZur5.5hraPOpxnjYEyx 1zEMVN6WCgMhVjmkirDKMyoADyQHodFUIzwijW9kLOFgazWsBQIs.9Bo.3.eCnmWp0RcqpCmQtBA _JBnByEM4YKbaWVUtEK1slOsnz0TxH.u26OjWW14H5mD51a1m9C4reuKO3qiQHn8fy9mswOKgS.K CdEBpXyPkv49ehvPcrK5hTKA8zeiC4s23h2OsJTFC1rSHVMiteoA25td5ZuGp_owv_foNsLUsQy6 lzmclo5LTKgZJGlGs.94Jw5DhzraO7kX61cEPyKp_Y2kuarFzOLfvc7BCklUGNNT8RcbQWixhQgz a7T_4_PSrdAzuo7sFXa_XFh2a2IwU.U_2dilaht_4W6vfrCIHrMlWUQrQeq244Dej60fUx88I4r1 MRjNOihuo1qUnGCSDXj9eOUL1yU6LUEsT.Eavt.wrfAQcN5v6m_r5SeSX0_C9nv3__QOkIh3A9XS 1tcmluZ9DsR6T7uZvxgfhMV5R3muhNB700M2PlZkcW.g.piRjiXrN4Mlh0nnEQnasl5NJMTHMu2S KulcjvBzOatBvUhJJkd753zfBQZyiTBdN6ky9jZrO0znNd1dOKIEeMeqCFconSz7xU.D82SyKAJz cyhql9rfLF8Whtv2dRNTMpIwvscZEXYzIrZCFEOQr3VGY8TrfOB_952TrBv5OjsxZo8nNnPvNHs1 VIsHbp1wwI2.fcCysRS.ZuagOvkxwi15MT6bGfYMQ_hu8kXBXMRb0QH756LyJIEQACVargqAgrXb G.45JLlhC8tAk1FHXoQivsvFIgJ2R_UBsl0WMgO4yJP_87mL3O5STJmyoA8RdvVokpqEmW.VHzoM XjuNxWa699NFGBCrqc47fQLrmNyCA7uvqq_FjCtdN8rY8BA5FT0s_E_y2EezNHiKblMlvEPWRhhB VrBkSBcI.ZKZGIo3D6T0tPJ_1myQjT7AL6axvcENs2AlO8LwqH8buv4Lm9W4pMUgBvspllpIeJC1 scaluikVf.0qz5ng8TuYWpbyE5x9gD_GwKmlxyTPGRnpRRJcJLFFwXoi.VfJZNloeQ9V51QXSt_8 G_Oe.3W54oWzNcEuB_BoDMknf8Urqn5D1UjWGqsll4Ucyayrkp7EmrpnDRDR3fopV6L8rhq3Zxrj LgXEPxZn_fLmo4NuJsKhv557rFz0b_4MXvtNi0UnWtPhTsOtZUJag2aPZDxy8g9sz28pntbvQ0BJ b7B4qsrkvZiUBZemfUKR6lA8rI9Wu.uJ_1Nj3Cpi6Qv_.FqTixE5ly7E0JgCCPN6uK.k8x0DbqRz bwsd4NO13FeLQ.VzWkJQ2oEqouWKuG_3R.jVjFuztwW5ukDintoaFyQP.UebPJ9CrQS34h5xv0YD 7eZuGxGchRH0kjO7D.PhI_1eOj_PoWI8clYVmsqGKDiGWdqCqmdDt7xHZfPElWlFh1661t1KFRan mfPJiCNUaXqDGE5liyfZ9myqaDdsQIo3l6yVRyY13IuX_h.R7uZ8XgyYpIZcs0vSU.bpA9vh2fo. GNMBswukjWGx3bVbhHKM_jwJzxG_PrZyB7zFw03.E92rsfTvhKYLBZ1U9qqiYVW83LIuozijU.eL G8hJuWjeBJTpi.6qqvvI_ouzgyCsHFKHrYlXAo95VLOYHF0QAy2xkcGZVI4USRN0.CA2HOyMOtL3 ZEw-- X-Sonic-MF: X-Sonic-ID: 7c9b72b1-7fb1-49e3-bf91-8a98be359ae6 Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.gq1.yahoo.com with HTTP; Tue, 16 May 2023 09:04:03 +0000 Received: by hermes--production-gq1-6db989bfb-hz24p (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 3ef801103db473dfff557383acd5d8e8; Tue, 16 May 2023 09:04:01 +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 \(3731.400.51.1.1\)) Subject: Re: Cores of different performance vs. time spent creating threads: Windows Dev Kit 2023 example [Oddity is back!] From: Mark Millard In-Reply-To: <47DE0BF6-3A16-4F87-AEEF-6D320BBC90E5@yahoo.com> Date: Tue, 16 May 2023 02:03:50 -0700 Cc: freebsd-arm Content-Transfer-Encoding: 7bit Message-Id: <91F3816A-EFF5-462A-8580-EE5C73A0FBEB@yahoo.com> References: <11EBAA22-6E0F-4B27-9799-7786E149D9B1@yahoo.com> <47DE0BF6-3A16-4F87-AEEF-6D320BBC90E5@yahoo.com> To: FreeBSD Hackers X-Mailer: Apple Mail (2.3731.400.51.1.1) 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.999]; 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]; MIME_GOOD(-0.10)[text/plain]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.30:from]; TO_DN_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; SUBJECT_HAS_EXCLAIM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; DKIM_TRACE(0.00)[yahoo.com:+]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org] X-Rspamd-Queue-Id: 4QL9K16GPLz4LLK X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N On May 15, 2023, at 12:14, Mark Millard wrote: > On May 9, 2023, at 19:19, Mark Millard wrote: > >> First some context that reaches an oddity that seems to >> be involved in the time to create threads . . . >> >> The Windows Dev Kit 2023 (WDK23 abbrevation here) boot reports: >> >> CPUs (cores) 0..3: cortex-a78c (the slower cores) >> CPUs (cores) 4..7: cortex-x1c (the faster cores) >> >> Building a kernel explicitly via involving -mcpu= use >> gets the following oddity relative to cpu numbering >> when the kernel is used: >> >> -mcpu=cortex-x1c or -mcpu=cortex-a78c: >> Benchmarking tracks that number/performance pairing. >> >> -mcpu=cortex-a72: >> The slower vs. faster gets swapped number blocks. >> >> So, for -mcpu=cortex-a72 , 0..3 are the faster cores. >> >> This sets up for the following . . . >> >> But I also observe (a relative comparison of contexts >> via some benchmark-like activity): >> >> -mcpu=cortex-x1c or -mcpu=cortex-a78c based kernel: >> threads take more time to create >> >> -mcpu=cortex-a72 based kernel: >> threads take less time to create >> >> The difference is not trivial for the activity involved >> for this WDK23 context. >> >> If there is a bias as to which core(s) are involved in part >> of thread creation generally, it would appear to be important >> that the bias to be to the more performant cores (for what the >> activity involves). The above suggests that such is possibly >> not necessarily the case for FreeBSD as is. BIG/little (and >> analogous?) cause this to become more relevant. >> >> Does this hypothesis about what type of thing is going on >> fit with how FreeBSD actually works? >> >> As stands, I'm going to experiment with the WDK23 using >> a cortex-a72 targeted kernel but a cortex-x1c/cortex-a78c >> targeted world for my general operation of the WDK23. >> >> >> Note: While the benchmark results allow seeing in plots >> what traces back to thread creation time contributions, >> the benchmark itself does not directly measure that time. >> It is more like, the average work rate for a time changes >> based on the fraction of the time involved in the thread >> creations for each given problem size. The actual definition >> of work here involves a mathematical quantity for a >> mathematical problem (that need not be limited to computers >> doing the work). >> >> The benchmark results are more useful for discovering that >> there is something to potentially investigate than to >> actually do an investigation with. >> > > Never mind: I was wrong about that . . . its back. (See later below.) > Starting over did not reproduce the oddity. So: > operator oddity/error, though I've no clue of how > to reproduce the odd swap of which cpu number ranges > took more vs. less time for each given size problem. > (Or any other aspect that might be considered also > odd, such as specific performance figures.) > > Retry details: > > I booted the WDK23 via UFS media set up for > cortex-a72, media that I use for UFS activities on > the HoneyComb (for example). I built the benchmark > and ran it. > > As stands, I've only done the "cpu lock down" case. > It produces less messy data by avoiding cpu > migration once the lockdown completes (singleton > cpuset for the thread). I'll also run the variant > that does not have the cpu lock downs (standard > C++ code without FreeBSD specifics added). I got the swapped number blocks vs. performance again, but not for cortext-a72 tailored FreeBSD, but for cortex-x1c/cortex-a78c +nolse tailored FreeBSD. Not rebooting for now, the oddity exists for the benchmark built with each of: clang 16 plus libc++ g++ 13 plus libc++ g++ 13 plus libstdc++ As before, top shows the name CPU's for STATE that the benchmark does for the cpuset based cpu id (bit numbering). As before, the measured performance for "faster" is also higher than normal. As a cross check: Avoiding use of my benchmark program . . . # cpuset -l0-3 openssl speed Doing mdc2 for 3s on 16 size blocks: 1705580 mdc2's in 3.10s . . . vs. # cpuset -l4-7 openssl speed Doing mdc2 for 3s on 16 size blocks: 1079870 mdc2's in 3.03s . . . So, openssl speed also shows the oddity: 0-3 usage being faster than 4-7 usage. The 1705580 is also somewhat large compared to a normal "4-7 is faster" context: 1705580/3.1 approx= 550187/sec . Compare to the similar calculation results in the below. For example: Shutting down, powering off, powering on, booting, and doing the openssl speed type of examples: # cpuset -l0-3 openssl speed Doing mdc2 for 3s on 16 size blocks: 997679 mdc2's in 3.09s . . . # cpuset -l4-7 openssl speed Doing mdc2 for 3s on 16 size blocks: 1360400 mdc2's in 3.02s . . . # cpuset -l0-3 openssl speed Doing mdc2 for 3s on 16 size blocks: 967253 mdc2's in 3.00s . . . # cpuset -l4-7 openssl speed Doing mdc2 for 3s on 16 size blocks: 1406978 mdc2's in 3.08s . . . So (2 similar calculations to earlier above): About 550187/sec vs. about 450463/sec and 456811/sec That is about 1.2 times faster. I've no clue about the cause or what stage(s) lead to the odd context happening. === Mark Millard marklmi at yahoo.com From nobody Tue May 16 15:41:46 2023 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 4QLL7w4BdGz4B9Jm for ; Tue, 16 May 2023 15:41:48 +0000 (UTC) (envelope-from rebecca@bsdio.com) 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 4QLL7w2KZpz3rfy for ; Tue, 16 May 2023 15:41:48 +0000 (UTC) (envelope-from rebecca@bsdio.com) Authentication-Results: mx1.freebsd.org; none Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 3CC205C01F8; Tue, 16 May 2023 11:41:48 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Tue, 16 May 2023 11:41:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdio.com; h=cc :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:sender:subject:subject:to:to; s=fm2; t= 1684251708; x=1684338108; bh=iEwvA+JUhj+/TDdp0mnEiiTPQvyQBj8lPtR TIBfsW1s=; b=QI4vapwrH/QpR2mP8LX4zsGp0YKMvBhn7aYLPuo6tSZXbTtov58 m6kJje1i4GfeCo6Myyfe/oOUjd0DN6nPS6TEvIJgJ1O8789RFLCR/ekZqynlR2Bf 3q7oc+XExrVzgLGXtEqYs/pc3oiQvuyk3vHh261fgWLAHL8oR+jw7WvG79FPgsPE hcwGU6hiAryUVqVaCYec1XViz10t69biXhQgOhIJFMsudw/ONaZbh7W3apY42fmq YzxDcBuSFIS2tOK+KEDCldLPXK32JKm+A9zdM6/P3U0hAvpnsTlhrjhnPMmHXbHw DMU55PHi5yrB9dP+vDmhsLpZXpOoSkPpJVA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc: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:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t= 1684251708; x=1684338108; bh=iEwvA+JUhj+/TDdp0mnEiiTPQvyQBj8lPtR TIBfsW1s=; b=Eo9RbmkPPJhyMqKJuOAqPqfKShaYXsObpL1fpM6Ep4n+v704uMc 8rAki8z3pSCAzuynJU1JqMGO7I73uka+adRTCM+YJEZIV4RIPJ+TqdBSGIpICMsK v4YI3slEhKPF1ZjVG+BeF9hh3VRG0GEoKeLhJKYtfNnm4AsK2Wb9urOyRbWkcRRO gaObHlI2iM8MANzvBSn4/uZSBp6wrDIdMI7rfQOmt1iLZ+dibtS3G419pn6GqWwc 3+qqtfousbiuQ9pRyAKCb/+mVKw+2ty3ZhibYw36LRg5PdESQjSK3j7nwTUmA6j+ 9NNFCKvvgKiz2zMSjQcZbzYsJ8ywWTemhow== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrfeehledgledtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfhffuvfevfhgjtgfgsehtkeertddtfeejnecuhfhrohhmpeftvggs vggttggrucevrhgrnhcuoehrvggsvggttggrsegsshguihhordgtohhmqeenucggtffrrg htthgvrhhnpeetlefhfedtieehkeevhfeukeeftdekvddufedvledtffeuvdffleeuheeg veehfeenucffohhmrghinhepfhhrvggvsghsugdrohhrghdpsghhhihvvggtohhnrdhorh hgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprhgv sggvtggtrgessghsughiohdrtghomh X-ME-Proxy: Feedback-ID: i5b994698:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 16 May 2023 11:41:47 -0400 (EDT) Message-ID: <08360ee6-6829-5362-8188-cdbd2c20e59b@bsdio.com> Date: Tue, 16 May 2023 09:41:46 -0600 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/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 From: Rebecca Cran Subject: Re: ARM64 virtualization? To: Matthew Grooms , freebsd-arm@freebsd.org Cc: Elena Mihailescu , Mihai Carabas References: <7CCEC16E-41A1-4318-B953-EF61D17EEE3C@mit.edu> <2f69f9a1-e976-65d6-c0be-74404640d1c1@shrew.net> Content-Language: en-US In-Reply-To: <2f69f9a1-e976-65d6-c0be-74404640d1c1@shrew.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4QLL7w2KZpz3rfy X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:19151, ipnet:66.111.4.0/24, country:US]; TAGGED_RCPT(0.00)[] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On 5/15/23 13:58, Matthew Grooms wrote: > On 5/15/2023 2:39 PM, John F Carr wrote: >> Is there any active work on getting bhyve virtualization working on >> 64 bit ARM?  I see some work was started a few years ago (e.g. >> https://reviews.freebsd.org/D26976, >> https://bhyvecon.org/bhyvecon2016-Mihai.pdf).  It seems to have been >> abandoned or at least stalled. >> >> I may be able to help.  It's not a project I can take on myself. > > Porting bhyve to arm has been one of the longest running UPB projects. > You can find more info on the history here ... > > https://wiki.freebsd.org/DevSummit/202303?action=AttachFile&do=view&target=Presentation+-+bhyvecon.pdf > > > Your best bet is probably to take a look a the following review opened > by Andrew Turner late last year. His work is based on the original > port by the UPB team ... > > https://reviews.freebsd.org/D37428 > > I can't speak to the current state of this work. From what I recall, > there were several attempts made by UPB to collaborate, but they > failed to get a response. Perhaps he/they can chime in here with more > detail. I'll be getting an Ampere system in the next few weeks and hope to be able to work on the Aarch64 bhyve code. -- Rebecca Cran From nobody Tue May 16 16:14:11 2023 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 4QLLsY0gNlz4BBlg for ; Tue, 16 May 2023 16:14:25 +0000 (UTC) (envelope-from marietto2008@gmail.com) Received: from mail-yw1-x1134.google.com (mail-yw1-x1134.google.com [IPv6:2607:f8b0:4864:20::1134]) (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 4QLLsX5sDxz3vGn for ; Tue, 16 May 2023 16:14:24 +0000 (UTC) (envelope-from marietto2008@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-yw1-x1134.google.com with SMTP id 00721157ae682-55a2cb9788dso202044827b3.2 for ; Tue, 16 May 2023 09:14:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1684253664; x=1686845664; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=2nNVemr3t1LAw5g5E3H5SL0OcS8NCn+TOGbvs5VmGu4=; b=QGmlj73ZvbYQx/e6gUV78FN7Jr6acwFd9eyvh1wmi07kafeV70W2ac+1zlJ8YeStWh 4XMe3KS2MoPR86YNirDwwcpKTgfwHHrHLCVLCv4CwIqApP5k1E8JEnPGEVHmR2bblQE2 Ci1x+cNMEgT83evb7+ju/A6Adick43JmkxNgx3pS8Au50N4KQCgLa+uhoQZaKZ+ha/3Y XRADYMb6UhV1IBOB79WZoGYKGazJO3bZWf/+r+GvuTi8Y5aiVgY3in7F0i/jf+Wi1S7r eiHQEwC8w3KaIEP7q2HLLLdfJjUTOoHYIknh6u90D3B5W8cI42U5evQFL+avBWXtA76L R5DQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684253664; x=1686845664; 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=2nNVemr3t1LAw5g5E3H5SL0OcS8NCn+TOGbvs5VmGu4=; b=ZuCEQ1zdlITwxcHS6qADXcwPPMXdCEZRQCfF+uO5Qd/dmwdMkQekBqE/Ylg8CrfIXS 34N4DoZgF2qJqBWjm7uARCytT4F8dpo6g8WJ5rlOBUputTocpGsTjxQf467hfok0WRvW L6+igUuCJ3HJRKKUIAzdhCPowJjAGGWsKA0yPC1Nye9P9nNtvInPv6hRlxUoUl+ht+so CmuRAM+jkPuNyzJSkMT+tCEXxp0L+6AWcaK9rlW32sf7VvDQOEoc5jHv6XrVHGpJ6+/F t7kiCC9nZ8QFoQFKjOS9iuqn69J/VbJ3XINtA/SgYzyIo2mreAEBRK3pMZGF3mdqeAq/ vwIQ== X-Gm-Message-State: AC+VfDw5XC33ilOb3grvVu6HKq914aYuyspVAQeYbsJXKVVokPCTRLrP lFaHIPQGUAvmWEPSe/Be4ZegrkKV05l+tEihbO0= X-Google-Smtp-Source: ACHHUZ7AQVoKUr4F8S4k7HRNpxEvrU+LnsrAZ9iBER/wNvWIeeVx3bC0ingbu31vxYOCwzKJRXu0krB3CUf197oi8MU= X-Received: by 2002:a0d:dac2:0:b0:552:96e0:ccd0 with SMTP id c185-20020a0ddac2000000b0055296e0ccd0mr40206672ywe.16.1684253663684; Tue, 16 May 2023 09:14:23 -0700 (PDT) List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 References: <7CCEC16E-41A1-4318-B953-EF61D17EEE3C@mit.edu> <2f69f9a1-e976-65d6-c0be-74404640d1c1@shrew.net> <08360ee6-6829-5362-8188-cdbd2c20e59b@bsdio.com> In-Reply-To: <08360ee6-6829-5362-8188-cdbd2c20e59b@bsdio.com> From: Mario Marietto Date: Tue, 16 May 2023 18:14:11 +0200 Message-ID: Subject: Re: ARM64 virtualization? To: Rebecca Cran Cc: Matthew Grooms , freebsd-arm@freebsd.org, Elena Mihailescu , Mihai Carabas Content-Type: multipart/alternative; boundary="00000000000055ebcd05fbd1dd38" X-Rspamd-Queue-Id: 4QLLsX5sDxz3vGn X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_RCPT(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --00000000000055ebcd05fbd1dd38 Content-Type: text/plain; charset="UTF-8" Hello Rebecca, i will be happy to help you. what system you will buy ? i want to evaluate the cost. If it is affordable for me I will also buy the same and i could test your code or something else task that you need. i ve been always interested in the bhyve development. Il mar 16 mag 2023, 17:41 Rebecca Cran ha scritto: > On 5/15/23 13:58, Matthew Grooms wrote: > > > On 5/15/2023 2:39 PM, John F Carr wrote: > >> Is there any active work on getting bhyve virtualization working on > >> 64 bit ARM? I see some work was started a few years ago (e.g. > >> https://reviews.freebsd.org/D26976, > >> https://bhyvecon.org/bhyvecon2016-Mihai.pdf). It seems to have been > >> abandoned or at least stalled. > >> > >> I may be able to help. It's not a project I can take on myself. > > > > Porting bhyve to arm has been one of the longest running UPB projects. > > You can find more info on the history here ... > > > > > https://wiki.freebsd.org/DevSummit/202303?action=AttachFile&do=view&target=Presentation+-+bhyvecon.pdf > > > > > > Your best bet is probably to take a look a the following review opened > > by Andrew Turner late last year. His work is based on the original > > port by the UPB team ... > > > > https://reviews.freebsd.org/D37428 > > > > I can't speak to the current state of this work. From what I recall, > > there were several attempts made by UPB to collaborate, but they > > failed to get a response. Perhaps he/they can chime in here with more > > detail. > > I'll be getting an Ampere system in the next few weeks and hope to be > able to work on the Aarch64 bhyve code. > > > -- > > Rebecca Cran > > > --00000000000055ebcd05fbd1dd38 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Rebecca,

i will be happy to help you. what system you will buy ? i want to evalua= te the cost. If it is affordable for me I will also buy the same and i coul= d test your code or something else task that you need. i ve been always int= erested in the bhyve development.

Il mar 16 mag 2023, 17:41 Rebecca Cr= an <rebecca@bsdio.com> ha sc= ritto:
On 5/15/23 13:58, Matthew Gr= ooms wrote:

> On 5/15/2023 2:39 PM, John F Carr wrote:
>> Is there any active work on getting bhyve virtualization working o= n
>> 64 bit ARM?=C2=A0 I see some work was started a few years ago (e.g= .
>> https://reviews.freebsd.org/D26976,
>> https://bhyvecon.org/bhyvecon2016-Mih= ai.pdf).=C2=A0 It seems to have been
>> abandoned or at least stalled.
>>
>> I may be able to help.=C2=A0 It's not a project I can take on = myself.
>
> Porting bhyve to arm has been one of the longest running UPB projects.=
> You can find more info on the history here ...
>
> https://wiki.freebsd.org/DevSummit/202303?a= ction=3DAttachFile&do=3Dview&target=3DPresentation+-+bhyvecon.pdf
>
>
> Your best bet is probably to take a look a the following review opened=
> by Andrew Turner late last year. His work is based on the original > port by the UPB team ...
>
> https://reviews.freebsd.org/D37428
>
> I can't speak to the current state of this work. From what I recal= l,
> there were several attempts made by UPB to collaborate, but they
> failed to get a response. Perhaps he/they can chime in here with more =
> detail.

I'll be getting an Ampere system in the next few weeks and hope to be <= br> able to work on the Aarch64 bhyve code.


--

Rebecca Cran


--00000000000055ebcd05fbd1dd38-- From nobody Tue May 16 16:19:27 2023 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 4QLLzc2zGyz4BBv6 for ; Tue, 16 May 2023 16:19:40 +0000 (UTC) (envelope-from dfr@rabson.org) Received: from mail-yw1-x1135.google.com (mail-yw1-x1135.google.com [IPv6:2607:f8b0:4864:20::1135]) (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 4QLLzb493bz3vwp for ; Tue, 16 May 2023 16:19:39 +0000 (UTC) (envelope-from dfr@rabson.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=rabson-org.20221208.gappssmtp.com header.s=20221208 header.b=uFuc3f8H; spf=pass (mx1.freebsd.org: domain of dfr@rabson.org designates 2607:f8b0:4864:20::1135 as permitted sender) smtp.mailfrom=dfr@rabson.org; dmarc=none Received: by mail-yw1-x1135.google.com with SMTP id 00721157ae682-561a33b6d63so8548597b3.1 for ; Tue, 16 May 2023 09:19:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rabson-org.20221208.gappssmtp.com; s=20221208; t=1684253979; x=1686845979; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=8qpbQpLTL1OhUGbAnsqnhONNVH8Ln0wHbfpy4emJteY=; b=uFuc3f8HilnxqfMUiOfNUY3AdarV4qbDcLebJRlXprqTvNpY6MIRyPMidWnPufiykp nW5G7cd0j4QKvNbnBQ+HS/mK1pdnyrTK5mABWHFIuFPROuHqrdmKW6MnBcN34BmEgYZv BbSr6UD3SCxF53MAp4qhTKdiDb4ZetFx+0+ZqlrspTKR8PRtFASvnQKkWSl2LbnMtMae rdO4VlXkDPum7UJ9rAAO8HMTCgjIkw+L3HlV+Fm3/fOdmd19U2PWXPvd8z4y1h1q0ay+ E1aJIDC6+E/s62yBcmfeejai0pu+XneO/ORJnxz8Z7S11fQvtAaIYPzIQ56Mx2JYaZAT WANw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684253979; x=1686845979; 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=8qpbQpLTL1OhUGbAnsqnhONNVH8Ln0wHbfpy4emJteY=; b=Kf1r/f9PAbbsi2WrzDl2mC+sVuFBU37SPy0IRIKLU4fbEG+K9IR15QNru0/1dUH22C sVRAG16ouSDv8tImTi9XQDNkNS2HnIF6uPvjcIPauwvoa4q1Ah1+aRhivUmZaYPrhdU0 liKccXjPsNB2a0NN8UGdNM93cjmze7dw9+YwqsCjALGAjuJPIH+YCmyu6wNwQvhP1ZmF 4WecinUxFDryhmYcTUBq1+nDyiRtY0ZTfQYVV7EeRFmJwEwlJ5nKmUC6WKsO3wgNV/OZ Ca37O7rMa6lfFrdZ/5946UGw/iUWmxMLjcU1Mutg3+Qgs5ujnQZASflKvmmSrRmPrK0f z0qg== X-Gm-Message-State: AC+VfDzsH6bC5CLp0E/u+GdbYWkNW5jk/ndLY1O3jtE3Qbrp49hHOoQF fitq8Wt2iYSwRJajJlU13ayTyneIZxRE8so5j7RKpCtIt8g0Ma0TO2CmNA== X-Google-Smtp-Source: ACHHUZ4vQ1oq7I1lCXffym4nPzYKmqOxE1yUBHiWEklwA9JQ8sTUJjmGD4raaIv/SFZ45Za9UlDSfFZa+Zx1D9VqUQk= X-Received: by 2002:a81:490b:0:b0:55d:6dd4:e635 with SMTP id w11-20020a81490b000000b0055d6dd4e635mr30018564ywa.30.1684253978881; Tue, 16 May 2023 09:19:38 -0700 (PDT) List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 References: <77CD0716-3BC8-47EB-8743-F2BD9CA43D31@yahoo.com> <432A1A16-9FE5-4339-AB38-8F3E03A5D4EF@yahoo.com> In-Reply-To: From: Doug Rabson Date: Tue, 16 May 2023 17:19:27 +0100 Message-ID: Subject: Re: Raspberry Pi POE+ hat overlay To: Mark Millard Cc: freebsd-arm@freebsd.org Content-Type: multipart/alternative; boundary="0000000000001f89a605fbd1f07e" 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)[-0.998]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; R_DKIM_ALLOW(-0.20)[rabson-org.20221208.gappssmtp.com:s=20221208]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; FREEMAIL_TO(0.00)[yahoo.com]; ARC_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::1135:from]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCPT_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_SOME(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_HAS_DN(0.00)[]; FREEFALL_USER(0.00)[dfr]; DKIM_TRACE(0.00)[rabson-org.20221208.gappssmtp.com:+]; TO_DN_SOME(0.00)[]; DMARC_NA(0.00)[rabson.org]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4QLLzb493bz3vwp X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N --0000000000001f89a605fbd1f07e Content-Type: text/plain; charset="UTF-8" On Sat, 13 May 2023 at 13:45, Doug Rabson wrote: > I was able to build an updated rpi-firmware port based on 1.20210805 and > this boots successfully on pi400 as well as rpi4. With this, I can load the > rpi-poe-plus overlay and I just need to try and reverse engineer the > undocumented mailbox API by reading the Linux code. > I have a first approximation of a fan driver which works with the 1.20210805 firmware (actually, I substituted rpi-poe-plus.dtbo from 1.20210831 which just changes the fan levels for the POE+). I'm testing with an rpi4B rev 1.5 with 'make -j4 buildworld' and the fan is keeping the cpu temperature below 65 degrees which is nice, especially since I set arm_boost=1 in config.txt which boosts the cpu frequency up to 1800 for this board. Does anyone have a pointer to the problem with firmware later than 20210805? Would it make any kind of sense to try to get the fix into releng/13.2 as an errata? --0000000000001f89a605fbd1f07e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Sat, 13 May 2023 at 13:45, Doug Rabson= <dfr@rabson.org> wrote:
I was able to build an updated rpi-fir= mware port based on 1.20210805 and this boots successfully on pi400 as well= as rpi4. With this, I can load the rpi-poe-plus overlay and I just need to= try and reverse engineer the undocumented mailbox API by reading the Linux= code.

I have a first approximation o= f a fan driver which works with the 1.20210805 firmware (actually, I substi= tuted rpi-poe-plus.dtbo from 1.20210831 which just changes the fan levels f= or the POE+). I'm testing with an rpi4B rev 1.5 with 'make -j4 buil= dworld' and the fan is keeping the cpu temperature below 65 degrees whi= ch is nice, especially since I set arm_boost=3D1 in config.txt which boosts= the cpu frequency up to 1800 for this board.

Does= anyone have a pointer to the problem with firmware later than 20210805? Wo= uld it make any kind of sense to try to get the fix into releng/13.2 as an = errata?

--0000000000001f89a605fbd1f07e-- From nobody Tue May 16 17:11:58 2023 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 4QLN8F0RDqz4BFsb for ; Tue, 16 May 2023 17:12:13 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic304-24.consmr.mail.gq1.yahoo.com (sonic304-24.consmr.mail.gq1.yahoo.com [98.137.68.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 4QLN8D0BB5z417B for ; Tue, 16 May 2023 17:12:11 +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=1684257130; bh=aKcudontywxoRGiw7pAE6vE532NrCjr1uAQjJAJHhw0=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=gGINHQlSIfSR73ePWF9VD/Oxm7YoQ172DEv4CdjMiOGbwQ+IZckiuhCGjeM2fcbG+mSFUQfiVD3GsbVCVhqY7UwSduiNalrkN98dEwIJANNCB4J7JB8igrXgbXeg+h+DsnTernCOHXQJjF1yzhdwin9g+/9qs0ki5xon8yjY+uAvbBZvDicMQtYrkPB+jJJaY42kaG3T3CFk4aHhYLkkfc6QNuYSMwaVh9dvRhaFDMgh21SCU/ib4H3fukCvBE489tUeO/m4q/yIrUT7v+0e4Y/Z0QJVVNDr1HLI5W5CBN5P1xYuxvZSmNbatDAp7UwJCOrO/37gQLwMAfBQweXwdw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1684257130; bh=A9aDG3qTFW0wRF2OK2ee1noku1MMDiibf3Mgltf71+C=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=TUucJ+XTs1Td/srCkTIuDrSAuMnQxU6wkATbxbSbmGdwGaF+DlrdHHqGRvijIeudVXFR4K4bQYFKlabh0q8MpP7E23rAblHQLNxEwR7I/ZYm6j5G9ua/QoNx8Ia84RY9Sxz8i1D+f3i5Je2DOuQ9E77/+3FBOunWsJNF/PbIWa3apm1/4wzS2zjfkuZ4NAwpw1gDPZQ5uTgTVSdz+tuE6MKHdToTshvhbNsrmtO65C5XrZi8+txsprkX67pSl0El1xFR5/JrvBnTuL4BZFa+IrPFdB90WSyavUIZOSjji5EtxEkOFLExRMS5un16D4XIlHPOGyWC0sTFZfCquEya2w== X-YMail-OSG: 1f02_UQVM1mDCj6_VXeZFxH6AO3Wm3o1HG7BUwCmMcYiCMHNEX4t65Y9gP7JDKi jY7II.RLl5XzKYbRgAJCZLEJBB4.il1Eb1nqGYT6szbtIFjX_DHKSlCFI0YYm8YBeDynCYSlhzYA 8kGPYTSU12Ug2GfkfS6.2ODlHqtBKmmQWl.qVrwJkqHBqk7OaesKBvmqZBV54IOPO.v3DNpcMYv0 Tudf0P9IWWqwOsoMzPtfhlNKNnVH0x9b6_M1xsiZWPPXXCx4s.j4lcJ_7Wx3m4sqMqN3paMfnfGx UM5pRsF5KDHmQwfoNca9kEOOdj6FkX4hpk2x6jlF4v655qazgEY1l3rAt4rDC5aK4wq81iITzUjP 522PwIJ4R4MoR_zReFwGoXE25eaQ_UCge00embMTC9tWLzsOZQyGqnmggMRdfWOvrFY_89.LsBAi JzlwH1D4cdL3kPAeNvy5dD5WsbJmxBRrL_DDE8EbNhaROC95rrB3_ZK10fBNxZLHktXAMNs9R49e 2nV852WuvFBlvid4A9rYbH2Ni96K7V.XxfiG.LwAUMVrprDhaUzU4Iqy4WZVGxoWXahS44iwKNJW 8EygmpNzl1f_lGxp4PX.rsMeEnqhGReVyj1qX9tf7L9Wis5o7tGkSRWfYytsQZXjlacuBK3OAC6w spu4AYK5uIH5w1FEkU6qkPrCwaIYg9QoBwx6Ksi8eERFlfOYW_jmL2hrcjkqXq0fayfg_waSC1Ow sZngbiQeo6LKBdsgjGYcSHA7qa.LvYq4wIDfD45HA5JNClMs0VUyEizuhDg94xUqws8z0aoeE82f DgI7DPI_U4mtYgfqiOH7MRtJow3QYC7Mx.Qn6U1bB8Zz4Nq4W9_a.Ev7teondy610.PmTjH1eC4Q Zuw4gwWWKHexHpFFMGDb8qXsOGNHIOa_65R8Ps34yjLYss_X.lUKRKISy5WSiVqeTf0dOqbxy.tV YPRbfDhSNYnK8Kf2VO8FZXiZ.AmeMKEFChKtIQYnY4hh.aeRUp4bLBX2X4HVIsT3CtmElKvNOmtQ x.nXbHVL7ITmFqtKgdgXxF_Nc0IF5dqVVGaD0C6ZsDQjnLlwIeUNY1qRCWAGh91qtRIz0.uswEFG DBWPsacU3qQLveLF7xr3Enh2IIumstYWuVwiLFwNWGZzY5MbbnSKuOvGAqrWXvGNgepeUWM9WYrO PpLPLddcRcUGjiANLtde5EE91VP5hMm0JL9YgBZ4q5g.7QHyWTqn1kXl5E3Da5pTJAsWpiWdDbOc 2cZXJx.RZ41SXTs6HjYxecjALCkvWYv5ErlWIBEKNl3mBnGVe8EY4ehy9MiarkV.cFHnthPZBRSK MYZGx8NYkQy7vzN7wEcNCMm7gFIjSSF6wQhzBuNRz9vj0aO9zG4e4Z0KPDQhsZ9528rOhfBLwnrP sLGAYxWxLYT._x0Y.ralpwTh8UF.79QVb4zlgEwyvT6qbO58T65RSkLLLB72BnSOOHFU.v71IqeP CfctHkV.43ZtBzcLPu_5dYltGntTmL98u8XMb1pTSXKrrloKtqaoh.OgQ.4uWdf.NjR5h3yTHkob OXPTf8GggT.Qqd21s6zNCEGzhy7Ya3IZOThmtYyFwVnhbJDQ0DCzNIccEqQkPgUW0PEc94bmI5LC zZ9Kx_bZfBl04IHfEoceagvYFEB3wqU2LFWol4sLzeAFdYyh3aVLf3XLmu4AC7Q3WNFWDIQLH.d3 HtciJN_pyDsMbL6eTbmR_QDL0kmUMTk4RhYWLjOG7WTcFsLVdc1.Gzzwh5tpqpU1TVsIrv4TAMcs _62nAm7eo.C0cQsSJXXptUborkKkxnh3HSXAh4Gg6cbDBQxsUN8Cur6VYEBhqzF5mpCKv1DFhOJh 7xjIURzzQs2X5UeWOhY5Gi3LyxhTaZtQUEN4xYpUyR1HBsosi1DJ7sz_DjL8rH89c7PGS_HJc9Sf YfSDglW3jVIZIfeJA_Cdc6T.8KvXQdjprVcN3NT6dE7g34MXzgVK_eX9s54fh1AohWQL0WeNxNBJ m1M2OtGieDk2E9_Tbox3LRJGJAVGKqiLQyYdMsO9BT.1YggAjnuR6KK8egf25wACl9lXjh.0HLny 65WYKkoI9NC0ZujAljyRYuqR7UwWwVYAXxBoMW6ApPWTvjcj3gwdbhL1DATga2WfEPTZHKj5Wer. mPDvX2B0NvpEc_pLMEl1VuZU9GnlnuztqXEn185lMFJMW1J4V8FiiaatWkrMEW7EePlESWuaNKDg nJPqwx4a0y3ZBz8uSU6eTKNZnexNMrwRvrxuirzZs9UFrRxeZgX_cvVW_5uqhm2cL0.QOxrxy1fU oLg-- X-Sonic-MF: X-Sonic-ID: e002a373-8dcd-41ed-8327-ec4ff30cb3e9 Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Tue, 16 May 2023 17:12:10 +0000 Received: by hermes--production-gq1-6db989bfb-7p67n (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 13c4f4784403a462569b35873f54ad04; Tue, 16 May 2023 17:12:09 +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 \(3731.400.51.1.1\)) Subject: Re: Raspberry Pi POE+ hat overlay From: Mark Millard In-Reply-To: Date: Tue, 16 May 2023 10:11:58 -0700 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <77CD0716-3BC8-47EB-8743-F2BD9CA43D31@yahoo.com> <432A1A16-9FE5-4339-AB38-8F3E03A5D4EF@yahoo.com> To: Doug Rabson X-Mailer: Apple Mail (2.3731.400.51.1.1) X-Rspamd-Queue-Id: 4QLN8D0BB5z417B X-Spamd-Bar: ---- 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] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On May 16, 2023, at 09:19, Doug Rabson wrote: >> On Sat, 13 May 2023 at 13:45, Doug Rabson wrote: >> I was able to build an updated rpi-firmware port based on 1.20210805 = and this boots successfully on pi400 as well as rpi4. With this, I can = load the rpi-poe-plus overlay and I just need to try and reverse = engineer the undocumented mailbox API by reading the Linux code. >>=20 > I have a first approximation of a fan driver which works with the = 1.20210805 firmware (actually, I substituted rpi-poe-plus.dtbo from = 1.20210831 which just changes the fan levels for the POE+). I'm testing = with an rpi4B rev 1.5 with 'make -j4 buildworld' and the fan is keeping = the cpu temperature below 65 degrees which is nice, especially since I = set arm_boost=3D1 in config.txt which boosts the cpu frequency up to = 1800 for this board. >=20 > Does anyone have a pointer to the problem with firmware later than = 20210805? Would it make any kind of sense to try to get the fix into = releng/13.2 as an errata? I doubt that FreeBSD would do a 13.2-RELEASE errata for a bug that is RPi* specific. But that should not block checking my assumptions. It might be more likely as an extra errata if another one was deemed essential so that an update would be happening anyway. (But I do not know if they do such things for fixes with narrower applicability.) Relevant from stable/13 are: = https://cgit.freebsd.org/src/commit/?h=3Dstable/13&id=3D5b6edfc577fbb4e970= 3c112713c7fb472e144346 ( https://bugs.freebsd.org/268835 ) and = https://cgit.freebsd.org/src/commit/?h=3Dstable/13&id=3Daa399ad3e554223b8b= f741c3933c38dec92eaf20 ( https://reviews.freebsd.org/D38756 ) The 1st of the 2 is the actual fix (essential), quoting: bcm_dma: attach at an earlier bus pass The sdhci_bcm driver attach routine relies on bcm_dma already being attached, in order to allocate a DMA channel. However, both drivers attached at the default pass so this is not guaranteed. Newer RPI firmware exposes this assumption, and the result is a NULL-dereference in bcm_dma_allocate(). To fix this, use BUS_PASS_SUPPORTDEV for bcm_dma. . . . diff --git a/sys/arm/broadcom/bcm2835/bcm2835_dma.c = b/sys/arm/broadcom/bcm2835/bcm2835_dma.c index cab8639bb607..af86647704f6 100644 --- a/sys/arm/broadcom/bcm2835/bcm2835_dma.c +++ b/sys/arm/broadcom/bcm2835/bcm2835_dma.c @@ -766,5 +766,6 @@ static driver_t bcm_dma_driver =3D { =20 static devclass_t bcm_dma_devclass; =20 -DRIVER_MODULE(bcm_dma, simplebus, bcm_dma_driver, bcm_dma_devclass, 0, = 0); +EARLY_DRIVER_MODULE(bcm_dma, simplebus, bcm_dma_driver, = bcm_dma_devclass, 0, 0, + BUS_PASS_SUPPORTDEV + BUS_PASS_ORDER_MIDDLE); MODULE_VERSION(bcm_dma, 1); The 2nd deals with improving error handling to avoid "NULL softc"s leading to crashes. But that is not essential to allowing more recent firmware. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Wed May 17 10:10:55 2023 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 4QLplx0Sngz49wCB for ; Wed, 17 May 2023 10:11:09 +0000 (UTC) (envelope-from eduardo@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 4QLplx02T0z45TM for ; Wed, 17 May 2023 10:11:09 +0000 (UTC) (envelope-from eduardo@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1684318269; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=qvzOvO2FqryHMbkC9pLkulOAxiyuQHHOR7vHMnhVdBM=; b=ZNrrLlw1t2tIdimlGnMbOAwYzLDHo6MTJckbOlMtBh4WBb1PyjB5lG0Y8IjM4RV1ccPSuc AADcGJvOPhCwaIj61guw1AmVmb26SBv9YOyZjUD6w068nzi0pqPcFgKSmF/LniKXU/zcv5 av+jS+SE7pPcKYDR3KMnFp+fXiNlkY6UKbiHJIRh+Bj/pefcTL96PuGDkN8LgX0/Q1k+jX CLCMgKDDcVMlWHqpKifyOLuUEBrcHk3JcWOJChrH2yp8BXuoUiqV+cWqnMBPzK8OarK3RE N4jlMJFmb24n3vOiV6sMONdtpIb7YgdKoef+uRFwtIbUkxKE5RMXuqAV2FVo0A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1684318269; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=qvzOvO2FqryHMbkC9pLkulOAxiyuQHHOR7vHMnhVdBM=; b=YCi3cOr/zhHdG3mYhXgWx8qFWRLHY0H/E+Ko64g2eu3PAeV6RzSQo1uYWx4cTfLWb/lTRY 7Y2f2pKZ+jbh9B63SLFLpDtcEFSkD2THoSEMnctYf/lPFmUFkeSQFnB0xDO2wVmqAqGsMz b9rJrmxKLYb4N8o4v10L7wZUJSFshL70jl9+iCQBXqMNqsEMTF2NGgDM2Xf727w3I8lp5H Cr8DgpnvMVRH6+9/gsIruKvxg6kBVkhRHLGjAzNDy0LbykPoRu2AULLJur1xImDOOcXMaO GPKXrEty6wBwNcHFyYU7c/2KDLXEG4QxtQxcLf2FTl+SffWf0vjskcrjgEgUlg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1684318269; a=rsa-sha256; cv=none; b=vXpFUxCzm4MGSRKj35JmaZwhq969ZPhPZ+/CAFQni0r5saRF+C3QoifKDkjeAJj+fPD9Vc XQVnLhCXwYucxpy1SbTxZANbOnKeq75iU4ZxN7K+x9J0ubD0rlUnlV+Mw6VD9l4+/cqrJ4 XE9KmBH04e7poGosu0jWjjvvrX2QUs4JvkfdMx3u39WkNwJQvE7NiImFTEfRE1JPzh9mSp 2qsyRoYzxNYarTfo61f0HGFmiQ61imI9h32LULAlXWnNMjCixOJLFGRpVkfPY2P+a3nZOw RPC1wN8Gk3kRI4kzMsoCYH9JBHUl0Xk1L12Sqwmd/3H//0AFQ2C9Df6vud2Pmg== Received: from mail-pl1-f170.google.com (mail-pl1-f170.google.com [209.85.214.170]) (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)) (Authenticated sender: eduardo) by smtp.freebsd.org (Postfix) with ESMTPSA id 4QLplw5jv2zstb for ; Wed, 17 May 2023 10:11:08 +0000 (UTC) (envelope-from eduardo@freebsd.org) Received: by mail-pl1-f170.google.com with SMTP id d9443c01a7336-1ab01bf474aso5426375ad.1 for ; Wed, 17 May 2023 03:11:08 -0700 (PDT) X-Gm-Message-State: AC+VfDxwlQf1ySaS45g/8gM1FvQjkidJ2suPRCnXploccRCG9MIJKyNr L5teAGfnxE7U1NvtjO3SZ+6IN/ZYTJl4zdf2ZqM= X-Google-Smtp-Source: ACHHUZ5hD3f/wOUSuu6IXbFvJmPxu0wC1XFQsppL+Bn6lDHsGoMGTKvtM7m+NNlCY1JjUcxq/9wYznNfBJhKQUos7wY= X-Received: by 2002:a17:903:1247:b0:1ab:afd:903a with SMTP id u7-20020a170903124700b001ab0afd903amr52868990plh.24.1684318267403; Wed, 17 May 2023 03:11:07 -0700 (PDT) List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 References: <77CD0716-3BC8-47EB-8743-F2BD9CA43D31@yahoo.com> <432A1A16-9FE5-4339-AB38-8F3E03A5D4EF@yahoo.com> In-Reply-To: From: Nuno Teixeira Date: Wed, 17 May 2023 11:10:55 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Raspberry Pi POE+ hat overlay To: Doug Rabson , freebsd-arm@freebsd.org Content-Type: multipart/mixed; boundary="0000000000000531e805fbe0e835" X-ThisMailContainsUnwantedMimeParts: N --0000000000000531e805fbe0e835 Content-Type: multipart/alternative; boundary="0000000000000531e605fbe0e833" --0000000000000531e605fbe0e833 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Doug, I have too a 1.5 rpi but arm_boost=3D1 isn't doing anything, htop shows 1500Mhz when doing something intensive. I'm running 13.2 stable Do I missing something? Could you take a look at my setup? Thanks, Doug Rabson escreveu no dia ter=C3=A7a, 16/05/2023 =C3=A0(= s) 17:19: > > On Sat, 13 May 2023 at 13:45, Doug Rabson wrote: > >> I was able to build an updated rpi-firmware port based on 1.20210805 and >> this boots successfully on pi400 as well as rpi4. With this, I can load = the >> rpi-poe-plus overlay and I just need to try and reverse engineer the >> undocumented mailbox API by reading the Linux code. >> > > I have a first approximation of a fan driver which works with the > 1.20210805 firmware (actually, I substituted rpi-poe-plus.dtbo from > 1.20210831 which just changes the fan levels for the POE+). I'm testing > with an rpi4B rev 1.5 with 'make -j4 buildworld' and the fan is keeping t= he > cpu temperature below 65 degrees which is nice, especially since I set > arm_boost=3D1 in config.txt which boosts the cpu frequency up to 1800 for > this board. > > Does anyone have a pointer to the problem with firmware later than > 20210805? Would it make any kind of sense to try to get the fix into > releng/13.2 as an errata? > > --=20 Nuno Teixeira FreeBSD Committer (ports) --0000000000000531e605fbe0e833 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Doug,

I have too a 1.5= rpi but arm_boost=3D1 isn't doing anything, htop shows 1500Mhz when do= ing something intensive.
I'm running 13.2 stable
Do I missing something?

Could you tak= e a look at my setup?

Thanks,

<= div class=3D"gmail_quote">
Doug Rabson= <dfr@rabson.org> escreveu no d= ia ter=C3=A7a, 16/05/2023 =C3=A0(s) 17:19:

On Sat, 13 May= 2023 at 13:45, Doug Rabson <dfr@rabson.org> wrote:
I was able to build an updated rpi-= firmware port based on 1.20210805 and this boots successfully on pi400 as w= ell as rpi4. With this, I can load the rpi-poe-plus overlay and I just need= to try and reverse engineer the undocumented mailbox API by reading the Li= nux code.

I have a first approximatio= n of a fan driver which works with the 1.20210805 firmware (actually, I sub= stituted rpi-poe-plus.dtbo from 1.20210831 which just changes the fan level= s for the POE+). I'm testing with an rpi4B rev 1.5 with 'make -j4 b= uildworld' and the fan is keeping the cpu temperature below 65 degrees = which is nice, especially since I set arm_boost=3D1 in config.txt which boo= sts the cpu frequency up to 1800 for this board.

D= oes anyone have a pointer to the problem with firmware later than 20210805?= Would it make any kind of sense to try to get the fix into releng/13.2 as = an errata?



--
Nuno Teixeira
FreeBSD Committ= er (ports)
--0000000000000531e605fbe0e833-- --0000000000000531e805fbe0e835 Content-Type: text/plain; charset="US-ASCII"; name="cpuinfo.txt" Content-Disposition: attachment; filename="cpuinfo.txt" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_lhrjllk11 cHJvY2Vzc29yCTogMApCb2dvTUlQUwk6IDEwOC4wMApGZWF0dXJlcwk6IGZwIGFzaW1kIGV2dHN0 cm0gY3JjMzIgY3B1aWQKQ1BVIGltcGxlbWVudGVyCTogMHg0MQpDUFUgYXJjaGl0ZWN0dXJlOiA4 CkNQVSB2YXJpYW50CTogMHgwCkNQVSBwYXJ0CTogMHhkMDgKQ1BVIHJldmlzaW9uCTogMwoKcHJv Y2Vzc29yCTogMQpCb2dvTUlQUwk6IDEwOC4wMApGZWF0dXJlcwk6IGZwIGFzaW1kIGV2dHN0cm0g Y3JjMzIgY3B1aWQKQ1BVIGltcGxlbWVudGVyCTogMHg0MQpDUFUgYXJjaGl0ZWN0dXJlOiA4CkNQ VSB2YXJpYW50CTogMHgwCkNQVSBwYXJ0CTogMHhkMDgKQ1BVIHJldmlzaW9uCTogMwoKcHJvY2Vz c29yCTogMgpCb2dvTUlQUwk6IDEwOC4wMApGZWF0dXJlcwk6IGZwIGFzaW1kIGV2dHN0cm0gY3Jj MzIgY3B1aWQKQ1BVIGltcGxlbWVudGVyCTogMHg0MQpDUFUgYXJjaGl0ZWN0dXJlOiA4CkNQVSB2 YXJpYW50CTogMHgwCkNQVSBwYXJ0CTogMHhkMDgKQ1BVIHJldmlzaW9uCTogMwoKcHJvY2Vzc29y CTogMwpCb2dvTUlQUwk6IDEwOC4wMApGZWF0dXJlcwk6IGZwIGFzaW1kIGV2dHN0cm0gY3JjMzIg Y3B1aWQKQ1BVIGltcGxlbWVudGVyCTogMHg0MQpDUFUgYXJjaGl0ZWN0dXJlOiA4CkNQVSB2YXJp YW50CTogMHgwCkNQVSBwYXJ0CTogMHhkMDgKQ1BVIHJldmlzaW9uCTogMwoKSGFyZHdhcmUJOiBC Q00yODM1ClJldmlzaW9uCTogZDAzMTE1ClNlcmlhbAkJOiAxMDAwMDAwMDI3NzlkNTQwCk1vZGVs CQk6IFJhc3BiZXJyeSBQaSA0IE1vZGVsIEIgUmV2IDEuNQo= --0000000000000531e805fbe0e835 Content-Type: text/plain; charset="US-ASCII"; name="config.txt" Content-Disposition: attachment; filename="config.txt" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_lhrjllj80 W2FsbF0KYXJtXzY0Yml0PTEKI2R0cGFyYW09YXVkaW89b24saTJjX2FybT1vbixzcGk9b24KZHRv dmVybGF5PW1tYwpkdG92ZXJsYXk9ZGlzYWJsZS1idApkZXZpY2VfdHJlZV9hZGRyZXNzPTB4NDAw MAprZXJuZWw9dS1ib290LmJpbgphcm1fYm9vc3Q9MQoKW3BpNF0KaGRtaV9zYWZlPTAKYXJtc3R1 Yj1hcm1zdHViOC1naWMuYmluCm1heF9mcmFtZWJ1ZmZlcnM9MgpoZG1pX2ZvcmNlX2hvdHBsdWc9 MQpoZG1pX2dyb3VwPTIKaGRtaV9kcml2ZT0yCmhkbWlfbW9kZT04MgpkaXNhYmxlX292ZXJzY2Fu PTEK --0000000000000531e805fbe0e835 Content-Type: text/plain; charset="US-ASCII"; name="eeprom.txt" Content-Disposition: attachment; filename="eeprom.txt" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_lhrjllk32 Qk9PVExPQURFUjogdXAgdG8gZGF0ZQogICBDVVJSRU5UOiBxdWEgMTEgamFuIDIwMjMgMTc6NDA6 NTIgVVRDICgxNjczNDU4ODUyKQogICAgTEFURVNUOiBxdWEgMTEgamFuIDIwMjMgMTc6NDA6NTIg VVRDICgxNjczNDU4ODUyKQogICBSRUxFQVNFOiBkZWZhdWx0ICgvbGliL2Zpcm13YXJlL3Jhc3Bi ZXJyeXBpL2Jvb3Rsb2FkZXIvZGVmYXVsdCkKICAgICAgICAgICAgVXNlIHJhc3BpLWNvbmZpZyB0 byBjaGFuZ2UgdGhlIHJlbGVhc2UuCgogIFZMODA1X0ZXOiBVc2luZyBib290bG9hZGVyIEVFUFJP TQogICAgIFZMODA1OiB1cCB0byBkYXRlCiAgIENVUlJFTlQ6IDAwMDEzOGMwCiAgICBMQVRFU1Q6 IDAwMDEzOGMwCg== --0000000000000531e805fbe0e835-- From nobody Wed May 17 12:11:18 2023 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 4QLsQq0kKtz4B3WZ for ; Wed, 17 May 2023 12:11:31 +0000 (UTC) (envelope-from dfr@rabson.org) Received: from mail-yw1-x112b.google.com (mail-yw1-x112b.google.com [IPv6:2607:f8b0:4864:20::112b]) (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 4QLsQp5L0Mz4HWW for ; Wed, 17 May 2023 12:11:30 +0000 (UTC) (envelope-from dfr@rabson.org) Authentication-Results: mx1.freebsd.org; none Received: by mail-yw1-x112b.google.com with SMTP id 00721157ae682-559f1819c5dso7204407b3.0 for ; Wed, 17 May 2023 05:11:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rabson-org.20221208.gappssmtp.com; s=20221208; t=1684325489; x=1686917489; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=EkOTP4rfzzqZ86hM5YQbnl90r2PHKVxeBndMnkrrJFs=; b=ycWuoI5tP9FLsKXWAu6fOs7MaT7bJTaO/xMrontINGHVAZUqZiF+8+3wxP55BIsB2P jLHoNTXA4V1qVeQT5WwTpm2wchpmFM06Pp1hd1X0ttJdsWVgWgqcAeM9qxaKZrEZYbmS kz/TgL7ZrI2IX/AL9SjkRDgkOf/XKN5rgx28n8SJ7/1LlNjmlrI/86P7eu/HIQ/YAsKM +85X8fM2WwU7Oj4xVcl0Ge5Vpu/CgR3Kjpi5KoXHYVtaAhbPtcCEDp8sORhNszCw5FG1 GBFWH+GiTeaPtSo31IoFJS3oahEu1FGOMKjSdNBwj77y95/MQOK8Qax3FvBsI3k0KtdJ gLXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684325489; x=1686917489; 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=EkOTP4rfzzqZ86hM5YQbnl90r2PHKVxeBndMnkrrJFs=; b=c3rGyLZYWAjw2Ylpfm3KMEHy1wnZ4PeHr/w8vFFNB9R7eCKVl2buyjn7/oOPaz/LVa pWiaRKXZziIfTCyCS/yRs5NdY2au0NO2fxSfakOreLprUpOf1SYMOYhVRAsvzfin0/WJ 2HUAlLasmEYizQ3lSWSJ6tkFNq5sQOyScy0yLljmzjFkFU4T4c9o6XsXfGChS4o2kSxE 2GZ28n0YA5egExfxA79MrCjs24blBV+KSm2xcJcBCMhmSnEos/+cw/5EDbw3vkSbJypv vyav2OeCaws/cJCYgPcf+K8nj0h8acHpw3f5yOVdlW5E14dgeFo7XAVILV47vib5r2lX ju1w== X-Gm-Message-State: AC+VfDxPQzJgaZiGtG760PdZ9znZfoxibO5EkayKwB67hE1gy/JPO337 7m6iPxxMDQ3SvS2NQxYZ4ocr2UaWlv7FRQ/BfrnLsP4qhacOG+7BXv6IWw== X-Google-Smtp-Source: ACHHUZ56XoCSdDIXk2vtY8gua0gfbG5fUBEIHvQBN1BrsmpxxJDEL7ttbkJOemoOnjfotSZ3G5D3Jg/VDjlf3f65Rmc= X-Received: by 2002:a0d:de45:0:b0:561:8894:1e0e with SMTP id h66-20020a0dde45000000b0056188941e0emr4536729ywe.50.1684325489547; Wed, 17 May 2023 05:11:29 -0700 (PDT) List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 References: <77CD0716-3BC8-47EB-8743-F2BD9CA43D31@yahoo.com> <432A1A16-9FE5-4339-AB38-8F3E03A5D4EF@yahoo.com> In-Reply-To: From: Doug Rabson Date: Wed, 17 May 2023 13:11:18 +0100 Message-ID: Subject: Re: Raspberry Pi POE+ hat overlay To: Nuno Teixeira Cc: freebsd-arm@freebsd.org Content-Type: multipart/alternative; boundary="0000000000007db46105fbe29676" X-Rspamd-Queue-Id: 4QLsQp5L0Mz4HWW X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --0000000000007db46105fbe29676 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Nuno, I'm not sure where to start - I just happened to notice in the documentation here: https://www.raspberrypi.com/documentation/computers/config_txt.html that the cpu frequency Pi4B R1.4 was listed as 1800 if arm_boot=3D1 so I tried i= t. Doug. On Wed, 17 May 2023 at 11:11, Nuno Teixeira wrote: > Hello Doug, > > I have too a 1.5 rpi but arm_boost=3D1 isn't doing anything, htop shows > 1500Mhz when doing something intensive. > I'm running 13.2 stable > > Do I missing something? > > Could you take a look at my setup? > > Thanks, > > Doug Rabson escreveu no dia ter=C3=A7a, 16/05/2023 =C3= =A0(s) 17:19: > >> >> On Sat, 13 May 2023 at 13:45, Doug Rabson wrote: >> >>> I was able to build an updated rpi-firmware port based on 1.20210805 an= d >>> this boots successfully on pi400 as well as rpi4. With this, I can load= the >>> rpi-poe-plus overlay and I just need to try and reverse engineer the >>> undocumented mailbox API by reading the Linux code. >>> >> >> I have a first approximation of a fan driver which works with the >> 1.20210805 firmware (actually, I substituted rpi-poe-plus.dtbo from >> 1.20210831 which just changes the fan levels for the POE+). I'm testing >> with an rpi4B rev 1.5 with 'make -j4 buildworld' and the fan is keeping = the >> cpu temperature below 65 degrees which is nice, especially since I set >> arm_boost=3D1 in config.txt which boosts the cpu frequency up to 1800 fo= r >> this board. >> >> Does anyone have a pointer to the problem with firmware later than >> 20210805? Would it make any kind of sense to try to get the fix into >> releng/13.2 as an errata? >> >> > > -- > Nuno Teixeira > FreeBSD Committer (ports) > --0000000000007db46105fbe29676 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Nuno,

I'm not sure where to star= t - I just happened to notice in the documentation here:=C2=A0https://= www.raspberrypi.com/documentation/computers/config_txt.html that the cp= u frequency Pi4B R1.4 was listed as 1800 if arm_boot=3D1 so I tried it.

Doug.



On Wed, 17 M= ay 2023 at 11:11, Nuno Teixeira <= eduardo@freebsd.org> wrote:
Hello Doug,

I have too a 1.5 rpi but arm_b= oost=3D1 isn't doing anything, htop shows 1500Mhz when doing something = intensive.
I'm running 13.2 stable

D= o I missing something?

Could you take a look at my= setup?

Thanks,

Doug Rabson <dfr@rabson.org> escreve= u no dia ter=C3=A7a, 16/05/2023 =C3=A0(s) 17:19:
=

On Sat, 13 May 2023 at 13:45, Doug Rabson= <dfr@rabson.org= > wrote:
I was able to build = an updated rpi-firmware port based on 1.20210805 and this boots successfull= y on pi400 as well as rpi4. With this, I can load the rpi-poe-plus overlay = and I just need to try and reverse engineer the undocumented mailbox API by= reading the Linux code.

I have a fir= st approximation of a fan driver which works with the 1.20210805 firmware (= actually, I substituted rpi-poe-plus.dtbo from 1.20210831 which just change= s the fan levels for the POE+). I'm testing with an rpi4B rev 1.5 with = 'make -j4 buildworld' and the fan is keeping the cpu temperature be= low 65 degrees which is nice, especially since I set arm_boost=3D1 in confi= g.txt which boosts the cpu frequency up to 1800 for this board.
<= br>
Does anyone have a pointer to the problem with firmware later= than 20210805? Would it make any kind of sense to try to get the fix into = releng/13.2 as an errata?



--
Nuno TeixeiraFreeBSD Committer (ports)
--0000000000007db46105fbe29676-- From nobody Wed May 17 12:11:42 2023 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 4QLsR430xyz4B3pH for ; Wed, 17 May 2023 12:11:44 +0000 (UTC) (envelope-from rebecca@bsdio.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 4QLsR40Ncqz4Hjn for ; Wed, 17 May 2023 12:11:44 +0000 (UTC) (envelope-from rebecca@bsdio.com) Authentication-Results: mx1.freebsd.org; none Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 67A425C00A8; Wed, 17 May 2023 08:11:43 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Wed, 17 May 2023 08:11:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdio.com; h=cc :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:sender:subject:subject:to:to; s=fm2; t= 1684325503; x=1684411903; bh=K8/4SZOnuVo/OqTzsWys/ZR5ZPvHSYNc3c1 CdvurP3o=; b=y16dUuU1GbXiqLEMoFyg3OCfYaL1P3Gjabw/KsjAotuSBzYFxa9 VX0CALfXL7OiKMM1sjvcsKbFmDEviIAmCph75vvpGtF04idP380DldZIn5xitIyv 1dy74HQJHgBHXjNEfF7ryjfyxNimdqkfsbyI66CnwH1WMNTvQ6Uvmh0wnDWaZ9nM apxwuVM52lSvjdJyetEWPop+NMcl+C+Gjp91SxqfpXMardAB3oDk1Mfdqy6ZcsXI pEUgIpBBhaE3T46wRQIMHTcNyW2cTrAmHHJKa9rFaTNt5zXyW+wWtLy1AaqltV6R TqU06gBw72d74Nx9vfccCJK1IxNPpMFE9RQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc: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:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t= 1684325503; x=1684411903; bh=K8/4SZOnuVo/OqTzsWys/ZR5ZPvHSYNc3c1 CdvurP3o=; b=fOFStpWqJsP4Mua9drRcuBVV4LHL6H36XhmtNEkY+lowuANc1jt JQ2xYCJzDmFWvfIDxeh1X0AIO8qdrP+jwHy0bssBV6qA2iPFCYcypys4/ogYWhgX hBfzhlzjab8bv/34bVEihUwxGWzm8QUC1PseN/VTgDrfDR964K4wsljMcqgT5qOe bCFTM/FdexrGLBuEdmIWbhsN78M6sQMA63g/j2OMitZcBXyt0EnH6BxXL1FilWP/ PQsi+IT3mpHsvMuehd8qWjEkbS2LmRu/LmeWm+M2F/Nz5UIo658IelZeWw/SOq6X f9N/SrR1Ru1rMpeCCmwS7F5hzRah5v304lg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrfeeiuddggeelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtkeertddtfeejnecuhfhrohhmpeftvggs vggttggrucevrhgrnhcuoehrvggsvggttggrsegsshguihhordgtohhmqeenucggtffrrg htthgvrhhnpedtueejtdevfffghfekgfevtdfhheettdfghfeiledtueegfeeuhfeglefg ueefueenucffohhmrghinhepihhpihdrfihikhhipdhfrhgvvggsshgurdhorhhgpdgshh ihvhgvtghonhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgr ihhlfhhrohhmpehrvggsvggttggrsegsshguihhordgtohhm X-ME-Proxy: Feedback-ID: i5b994698:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 17 May 2023 08:11:42 -0400 (EDT) Message-ID: <9aacad10-01c1-a0b5-a2de-32abf670feec@bsdio.com> Date: Wed, 17 May 2023 06:11:42 -0600 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/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Subject: Re: ARM64 virtualization? Content-Language: en-US To: Mario Marietto Cc: Matthew Grooms , freebsd-arm@freebsd.org, Elena Mihailescu , Mihai Carabas References: <7CCEC16E-41A1-4318-B953-EF61D17EEE3C@mit.edu> <2f69f9a1-e976-65d6-c0be-74404640d1c1@shrew.net> <08360ee6-6829-5362-8188-cdbd2c20e59b@bsdio.com> From: Rebecca Cran In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4QLsR40Ncqz4Hjn X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:19151, ipnet:66.111.4.0/24, country:US]; TAGGED_RCPT(0.00)[] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N I'm getting the Ampere Developer Kit from https://www.ipi.wiki/products/com-hpc-ampere-altra . -- Rebecca Cran On 5/16/23 10:14, Mario Marietto wrote: > Hello Rebecca, > > i will be happy to help you. what system you will buy ? i want to > evaluate the cost. If it is affordable for me I will also buy the same > and i could test your code or something else task that you need. i ve > been always interested in the bhyve development. > > Il mar 16 mag 2023, 17:41 Rebecca Cran ha scritto: > > On 5/15/23 13:58, Matthew Grooms wrote: > > > On 5/15/2023 2:39 PM, John F Carr wrote: > >> Is there any active work on getting bhyve virtualization > working on > >> 64 bit ARM?  I see some work was started a few years ago (e.g. > >> https://reviews.freebsd.org/D26976, > >> https://bhyvecon.org/bhyvecon2016-Mihai.pdf). It seems to have > been > >> abandoned or at least stalled. > >> > >> I may be able to help.  It's not a project I can take on myself. > > > > Porting bhyve to arm has been one of the longest running UPB > projects. > > You can find more info on the history here ... > > > > > https://wiki.freebsd.org/DevSummit/202303?action=AttachFile&do=view&target=Presentation+-+bhyvecon.pdf > > > > > > > > Your best bet is probably to take a look a the following review > opened > > by Andrew Turner late last year. His work is based on the original > > port by the UPB team ... > > > > https://reviews.freebsd.org/D37428 > > > > I can't speak to the current state of this work. From what I > recall, > > there were several attempts made by UPB to collaborate, but they > > failed to get a response. Perhaps he/they can chime in here with > more > > detail. > > I'll be getting an Ampere system in the next few weeks and hope to be > able to work on the Aarch64 bhyve code. > > > -- > > Rebecca Cran > > From nobody Wed May 17 12:15:56 2023 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 4QLsX76fl8z4B431 for ; Wed, 17 May 2023 12:16:07 +0000 (UTC) (envelope-from dfr@rabson.org) Received: from mail-yw1-x112b.google.com (mail-yw1-x112b.google.com [IPv6:2607:f8b0:4864:20::112b]) (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 4QLsX7659Dz4J4q for ; Wed, 17 May 2023 12:16:07 +0000 (UTC) (envelope-from dfr@rabson.org) Authentication-Results: mx1.freebsd.org; none Received: by mail-yw1-x112b.google.com with SMTP id 00721157ae682-561bb2be5f8so6897597b3.0 for ; Wed, 17 May 2023 05:16:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rabson-org.20221208.gappssmtp.com; s=20221208; t=1684325767; x=1686917767; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Tjsgdt1YfZF91nMJqhVvD4tn98WNvlit34OWaaKKQBY=; b=JKY1BeZTeHHbla6KUAezwDTndXNfFB2qxtRFPGdKKTnu+/njXRjz9tdJi6ckAlnLBm UYTsr9CtQ8rqKpKy9hrMF+yY8x/AejnAUza/UnPZBf1LtYOO6NvRoj9AdtOddIlScZ2S 1TrQ2ohz2imoDRQrv8tdUQw9NJXucQ6Cj+wj0VKZLLBE8l9GyFfr2LhL6/lzIE+03o9i fTeXCpxgkpdvDTOYJI1ADjoQJ5fXGF8MJM5fM0cX0516k/po+ux3GkaP0jfYZOMvwUtZ +nGmkTq8V0POJeqg3T4c5gGfqcc1ZGGY2MkPCRard2IF5rY9oO/Dg/vObwLMlo1EeQJ5 36XQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684325767; x=1686917767; 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=Tjsgdt1YfZF91nMJqhVvD4tn98WNvlit34OWaaKKQBY=; b=lVrsqry2GxOImWTtCQ00xhPpVLwr52JVdkWpcUBntwDS+Beu7Cp9Wk6ttqlkpfP3J8 aik3m9tJW7OFoWL1Pi99il6u2tIMvXDwTZhbauG1uy4yj+pP/QXIqToNma4zwmOKPwSX LYVI9lY2ayLvmVY3GUpUl4B2kWImuCZflBsqabF6/PCjAHkBzkejxrTGgvC4ROHtrEUs xObHi/BxntoW2FXymnk61Ctw/NIfOPjDjNMYQWPIpxr3qQg6j5+STrBX1v3CSRH2yx68 uJ7QWJ3VcnaWR2j14Pje4PDsC6NwvPpBxkW3Cl3mSIAlTtRSSrgYavuX6A4yCwwJHYed 8IWQ== X-Gm-Message-State: AC+VfDwy/MFJgrYjlSfKg4YR4EwX9lmts5tuwbtkjhCi7gyq+OnmuOzs 5p9PFkdq7AQ/BG6QXz5ARdmF9QktDVE9wgU6SWKbDA== X-Google-Smtp-Source: ACHHUZ5flCGvZbpnxCOWFq+HMdXkNF3a0rb+j2VPs3CaIe60oYTLKBiD2CMHQglvu13urbwBC8YCpJ0qB3j4LFu81Wg= X-Received: by 2002:a0d:cad2:0:b0:55a:6430:e8fb with SMTP id m201-20020a0dcad2000000b0055a6430e8fbmr38636018ywd.8.1684325767052; Wed, 17 May 2023 05:16:07 -0700 (PDT) List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 References: <7CCEC16E-41A1-4318-B953-EF61D17EEE3C@mit.edu> <2f69f9a1-e976-65d6-c0be-74404640d1c1@shrew.net> <08360ee6-6829-5362-8188-cdbd2c20e59b@bsdio.com> <9aacad10-01c1-a0b5-a2de-32abf670feec@bsdio.com> In-Reply-To: <9aacad10-01c1-a0b5-a2de-32abf670feec@bsdio.com> From: Doug Rabson Date: Wed, 17 May 2023 13:15:56 +0100 Message-ID: Subject: Re: ARM64 virtualization? To: Rebecca Cran Cc: Mario Marietto , Matthew Grooms , freebsd-arm@freebsd.org, Elena Mihailescu , Mihai Carabas Content-Type: multipart/alternative; boundary="0000000000000816f705fbe2a73b" X-Rspamd-Queue-Id: 4QLsX7659Dz4J4q X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_RCPT(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --0000000000000816f705fbe2a73b Content-Type: text/plain; charset="UTF-8" Hi Rebecca, I would be very interested in hearing about your experience with it, particularly how noisy it is. $2621 for an 80 core workstation seems like a really good deal :) DOug. On Wed, 17 May 2023 at 13:11, Rebecca Cran wrote: > I'm getting the Ampere Developer Kit from > https://www.ipi.wiki/products/com-hpc-ampere-altra . > > > -- > > Rebecca Cran > > > On 5/16/23 10:14, Mario Marietto wrote: > > Hello Rebecca, > > > > i will be happy to help you. what system you will buy ? i want to > > evaluate the cost. If it is affordable for me I will also buy the same > > and i could test your code or something else task that you need. i ve > > been always interested in the bhyve development. > > > > Il mar 16 mag 2023, 17:41 Rebecca Cran ha scritto: > > > > On 5/15/23 13:58, Matthew Grooms wrote: > > > > > On 5/15/2023 2:39 PM, John F Carr wrote: > > >> Is there any active work on getting bhyve virtualization > > working on > > >> 64 bit ARM? I see some work was started a few years ago (e.g. > > >> https://reviews.freebsd.org/D26976, > > >> https://bhyvecon.org/bhyvecon2016-Mihai.pdf). It seems to have > > been > > >> abandoned or at least stalled. > > >> > > >> I may be able to help. It's not a project I can take on myself. > > > > > > Porting bhyve to arm has been one of the longest running UPB > > projects. > > > You can find more info on the history here ... > > > > > > > > > https://wiki.freebsd.org/DevSummit/202303?action=AttachFile&do=view&target=Presentation+-+bhyvecon.pdf > > < > https://wiki.freebsd.org/DevSummit/202303?action=AttachFile&do=view&target=Presentation+-+bhyvecon.pdf > > > > > > > > > > > > > Your best bet is probably to take a look a the following review > > opened > > > by Andrew Turner late last year. His work is based on the original > > > port by the UPB team ... > > > > > > https://reviews.freebsd.org/D37428 > > > > > > I can't speak to the current state of this work. From what I > > recall, > > > there were several attempts made by UPB to collaborate, but they > > > failed to get a response. Perhaps he/they can chime in here with > > more > > > detail. > > > > I'll be getting an Ampere system in the next few weeks and hope to be > > able to work on the Aarch64 bhyve code. > > > > > > -- > > > > Rebecca Cran > > > > > > --0000000000000816f705fbe2a73b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Rebecca,

I would be very interested = in hearing about your experience with it, particularly how noisy it is. $26= 21 for an 80 core workstation seems like a really good deal :)
DOug.


On Wed, 17 May 2023 at 13:11, Rebecc= a Cran <rebecca@bsdio.com> w= rote:
I'm getting the Ampere Developer Kit fr= om
https://www.ipi.wiki/products/com-hpc-ampere-altra= .


--

Rebecca Cran


On 5/16/23 10:14, Mario Marietto wrote:
> Hello Rebecca,
>
> i will be happy to help you. what system you will buy ? i want to
> evaluate the cost. If it is affordable for me I will also buy the same=
> and i could test your code or something else task that you need. i ve =
> been always interested in the bhyve development.
>
> Il mar 16 mag 2023, 17:41 Rebecca Cran <rebecca@bsdio.com> ha scritto:
>
>=C2=A0 =C2=A0 =C2=A0On 5/15/23 13:58, Matthew Grooms wrote:
>
>=C2=A0 =C2=A0 =C2=A0> On 5/15/2023 2:39 PM, John F Carr wrote:
>=C2=A0 =C2=A0 =C2=A0>> Is there any active work on getting bhyve = virtualization
>=C2=A0 =C2=A0 =C2=A0working on
>=C2=A0 =C2=A0 =C2=A0>> 64 bit ARM?=C2=A0 I see some work was star= ted a few years ago (e.g.
>=C2=A0 =C2=A0 =C2=A0>> https://reviews.freebsd.org/D2697= 6,
>=C2=A0 =C2=A0 =C2=A0>> https://bhyvecon.org/bhy= vecon2016-Mihai.pdf). It seems to have
>=C2=A0 =C2=A0 =C2=A0been
>=C2=A0 =C2=A0 =C2=A0>> abandoned or at least stalled.
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> I may be able to help.=C2=A0 It's not = a project I can take on myself.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> Porting bhyve to arm has been one of the longe= st running UPB
>=C2=A0 =C2=A0 =C2=A0projects.
>=C2=A0 =C2=A0 =C2=A0> You can find more info on the history here ...=
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0https://wiki.freebsd.org/DevSummit/= 202303?action=3DAttachFile&do=3Dview&target=3DPresentation+-+bhyvec= on.pdf
>=C2=A0 =C2=A0 =C2=A0<https://wiki.freebsd.org/DevSum= mit/202303?action=3DAttachFile&do=3Dview&target=3DPresentation+-+bh= yvecon.pdf>
>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> Your best bet is probably to take a look a the= following review
>=C2=A0 =C2=A0 =C2=A0opened
>=C2=A0 =C2=A0 =C2=A0> by Andrew Turner late last year. His work is b= ased on the original
>=C2=A0 =C2=A0 =C2=A0> port by the UPB team ...
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> https://reviews.freebsd.org/D37428
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> I can't speak to the current state of this= work. From what I
>=C2=A0 =C2=A0 =C2=A0recall,
>=C2=A0 =C2=A0 =C2=A0> there were several attempts made by UPB to col= laborate, but they
>=C2=A0 =C2=A0 =C2=A0> failed to get a response. Perhaps he/they can = chime in here with
>=C2=A0 =C2=A0 =C2=A0more
>=C2=A0 =C2=A0 =C2=A0> detail.
>
>=C2=A0 =C2=A0 =C2=A0I'll be getting an Ampere system in the next fe= w weeks and hope to be
>=C2=A0 =C2=A0 =C2=A0able to work on the Aarch64 bhyve code.
>
>
>=C2=A0 =C2=A0 =C2=A0--
>
>=C2=A0 =C2=A0 =C2=A0Rebecca Cran
>
>

--0000000000000816f705fbe2a73b-- From nobody Wed May 17 12:44:48 2023 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 4QLt9T5QNMz4B5L7 for ; Wed, 17 May 2023 12:45:01 +0000 (UTC) (envelope-from eduardo@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (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 4QLt9T4yjsz4LkG for ; Wed, 17 May 2023 12:45:01 +0000 (UTC) (envelope-from eduardo@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1684327501; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=YeGSUMW+lncc0O66BH3ba6W2BTcQNE8JiYziu4LCgD8=; b=nlYb9Jhn3y/86txlVClt/AkPySBI/4FBhagg7v35mUVN5lwnSfoF+iXizdI7Z28f+F7Tl1 hhGDhkz8lCMH7fB9oFvNiZuOofBt2qAScAj2Du3pbD4IY4rrw5IQMfjbGV+gTtM56/Cmbs RjkDHuWK6jhL3q4n/GvnnG0WQSCOyadB99VMtwxdSB/DHxBkQwu2IQKxzXbk/fu4oH9PMd YGmvJH7tdnmXnlU34KNyw0oXDelFIMUXJTXlHAAJJSwuZtf4i870YvHHNHDM7UgG/yqF55 q4T1MamJzDEKXZBgqVDzqo7vj3daNW/j+pLOvzujmU/8jVUSYUsyhXVEiEHqaA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1684327501; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=YeGSUMW+lncc0O66BH3ba6W2BTcQNE8JiYziu4LCgD8=; b=tMQGV0ZqZa12z+Rfs7EKA0lZ3sc1VBwTdZvYtRLI3GOnSeWfKBa5f5bIBv5123IWZXJptJ DeMzXnAs1O3QqeZm7j6texHDLx7CgZU1L98OAW6Hj7/YdEgP8S/AaO/xy5TCN4fA5cpR4M 22/lxUljvNXEv3ijCKYzFLeeVBKY4n7gNA8FuQBB2N+2LbJdoO6mZl2uM2MCPM0yRZQGYO 15+UvrYWfDo6ovxrdDlG6Nm8d7Wo6MfwAQTgSjKKKG7xXP9m6H7AxT10ainp8q7QLARGK4 JQD4fDSMMKu84/20C6BKQFCsNLBtHkxzRLf9TvoJdvIpI+GsQhZKi8woLf+KDw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1684327501; a=rsa-sha256; cv=none; b=X6NChJfkKozPiNq1Guls3GeaCWpLFnDDiChENmQCg+Sx3xwtgjEZs/hrA2hm0NWR6VI4lS 53UFGfYF0xWm81ye0xAVZs2rwMIJ4s2sBoQKM3HP3NkRtk+SilYfUGnkPoAhvK/HhTQZyX Qk1utuYuPB52Rp5Lf7MFKL41tguie79cfoSEejRI3HfuAmR7dQi6v076xFt/Cx9oEBDWxe 5xMAK5ywDddNeugcCVjM9UT/wH+O7aDVpUiMf2Tmz/WYw447oGp5lOs9sXaKMLfmr5EXtp HJ3Evvp//WgInSoJWtIDFHT7KuRVjOrJzAhTSD+4pl6CeAUqZ9Qh0FjUxgLikw== Received: from mail-pf1-f172.google.com (mail-pf1-f172.google.com [209.85.210.172]) (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)) (Authenticated sender: eduardo) by smtp.freebsd.org (Postfix) with ESMTPSA id 4QLt9T3yhLzwHy for ; Wed, 17 May 2023 12:45:01 +0000 (UTC) (envelope-from eduardo@freebsd.org) Received: by mail-pf1-f172.google.com with SMTP id d2e1a72fcca58-643846c006fso666346b3a.0 for ; Wed, 17 May 2023 05:45:01 -0700 (PDT) X-Gm-Message-State: AC+VfDxcBb0l1Eli7dQkrJjHTDVQk2KPvf8mF2nmkCS5Oa+7U4glS80S XELMSn5Mw21NVZ6/z8elq2VJHRTVx+6j1P9W5bs= X-Google-Smtp-Source: ACHHUZ707R5xyE79jkFE2hQsXaWsHNH9s4vcm6KFUuo9WMDN1EjilzwmDKV17zOFk5GE/L/yUI4jF8g19UM0bcYS0J4= X-Received: by 2002:a05:6a20:8e1d:b0:101:47d8:ff86 with SMTP id y29-20020a056a208e1d00b0010147d8ff86mr35562329pzj.34.1684327500027; Wed, 17 May 2023 05:45:00 -0700 (PDT) List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 References: <77CD0716-3BC8-47EB-8743-F2BD9CA43D31@yahoo.com> <432A1A16-9FE5-4339-AB38-8F3E03A5D4EF@yahoo.com> In-Reply-To: From: Nuno Teixeira Date: Wed, 17 May 2023 13:44:48 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Raspberry Pi POE+ hat overlay To: Doug Rabson Cc: freebsd-arm@freebsd.org Content-Type: multipart/alternative; boundary="000000000000531deb05fbe30ea5" X-ThisMailContainsUnwantedMimeParts: N --000000000000531deb05fbe30ea5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hey, Ok. I'm new to rpi4 and arm in general but tomorrow I will force 'arm_freq=3D1800' again just to see it it crashes again. I will check too what values linux shows. I don't know if firmware/uboot version included in 12.3 supports this feature. Cheers, Doug Rabson escreveu no dia quarta, 17/05/2023 =C3=A0(s) 1= 3:11: > Hi Nuno, > > I'm not sure where to start - I just happened to notice in the > documentation here: > https://www.raspberrypi.com/documentation/computers/config_txt.html that > the cpu frequency Pi4B R1.4 was listed as 1800 if arm_boot=3D1 so I tried= it. > > Doug. > > > > On Wed, 17 May 2023 at 11:11, Nuno Teixeira wrote: > >> Hello Doug, >> >> I have too a 1.5 rpi but arm_boost=3D1 isn't doing anything, htop shows >> 1500Mhz when doing something intensive. >> I'm running 13.2 stable >> >> Do I missing something? >> >> Could you take a look at my setup? >> >> Thanks, >> >> Doug Rabson escreveu no dia ter=C3=A7a, 16/05/2023 =C3= =A0(s) >> 17:19: >> >>> >>> On Sat, 13 May 2023 at 13:45, Doug Rabson wrote: >>> >>>> I was able to build an updated rpi-firmware port based on 1.20210805 >>>> and this boots successfully on pi400 as well as rpi4. With this, I can= load >>>> the rpi-poe-plus overlay and I just need to try and reverse engineer t= he >>>> undocumented mailbox API by reading the Linux code. >>>> >>> >>> I have a first approximation of a fan driver which works with the >>> 1.20210805 firmware (actually, I substituted rpi-poe-plus.dtbo from >>> 1.20210831 which just changes the fan levels for the POE+). I'm testing >>> with an rpi4B rev 1.5 with 'make -j4 buildworld' and the fan is keeping= the >>> cpu temperature below 65 degrees which is nice, especially since I set >>> arm_boost=3D1 in config.txt which boosts the cpu frequency up to 1800 f= or >>> this board. >>> >>> Does anyone have a pointer to the problem with firmware later than >>> 20210805? Would it make any kind of sense to try to get the fix into >>> releng/13.2 as an errata? >>> >>> >> >> -- >> Nuno Teixeira >> FreeBSD Committer (ports) >> > --=20 Nuno Teixeira FreeBSD Committer (ports) --000000000000531deb05fbe30ea5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey,

Ok. I'm new to rpi4= and arm in general but tomorrow I will force 'arm_freq=3D1800' aga= in just to see it it crashes again.
I will check too what values = linux shows.

I don't know if firmware/uboot ve= rsion included in 12.3 supports this feature.

Chee= rs,

Doug Rabson <dfr@rabson.o= rg> escreveu no dia quarta, 17/05/2023 =C3=A0(s) 13:11:
Hi Nuno,
I'm not sure where to start - I just happened to notic= e in the documentation here:=C2=A0https://www.raspbe= rrypi.com/documentation/computers/config_txt.html that the cpu frequenc= y Pi4B R1.4 was listed as 1800 if arm_boot=3D1 so I tried it.
Doug.



On Wed, 17 May 2023 = at 11:11, Nuno Teixeira <eduardo@freebsd.org> wrote:
Hello Doug,

I have too a 1.5 rpi but arm_boost=3D1 isn't doing any= thing, htop shows 1500Mhz when doing something intensive.
I'm= running 13.2 stable

Do I missing something?
=

Could you take a look at my setup?

=
Thanks,

Doug Rabson <dfr@rabson.org> escreveu no dia ter=C3=A7a, 16/05/202= 3 =C3=A0(s) 17:19:




--
Nuno TeixeiraFreeBSD Committer (ports)


--
Nuno Teixeira
FreeBSD Committ= er (ports)
--000000000000531deb05fbe30ea5-- From nobody Wed May 17 12:47:02 2023 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 4QLtD30vQ6z4B5Hw for ; Wed, 17 May 2023 12:47:15 +0000 (UTC) (envelope-from dfr@rabson.org) Received: from mail-yw1-x112e.google.com (mail-yw1-x112e.google.com [IPv6:2607:f8b0:4864:20::112e]) (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 4QLtD265N2z4M0K for ; Wed, 17 May 2023 12:47:14 +0000 (UTC) (envelope-from dfr@rabson.org) Authentication-Results: mx1.freebsd.org; none Received: by mail-yw1-x112e.google.com with SMTP id 00721157ae682-561a41db2c0so7942877b3.3 for ; Wed, 17 May 2023 05:47:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rabson-org.20221208.gappssmtp.com; s=20221208; t=1684327634; x=1686919634; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=1oR2dLnoVZnLv9ZsGQNRwSF3GxNDj8i0OfF5hRnPf28=; b=JaJ5CZEpEoJSmLO79UYTWDzG5sX/BEqA7O/eSd/W4MAWHW4srPWZw2E99COp56Jt5L xcZRtnWFeO/gVttxhsg72AjStuht/zHWmvbgoTZjHLGfOgxMby/aJDA8tQziSkxd7ifb MvMDPdTCH+WmbWv83U9P++m9vL+LKi5ZvxzEApR1J008Awg+wpbhp+bswXCOom4C+laf laPDSuWa4MaqYpRPFjQu3Ayqv8S1vhPfm1j9be9ZYNo64WKM91cKcBLXf663AWXq7CUH C74QYsz7BEIpy/smeEMXfsfipjtkOd0FicNR0GdPN0ZhwJbltQ/oiQK5XVW93yp+8T1F TpBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684327634; x=1686919634; 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=1oR2dLnoVZnLv9ZsGQNRwSF3GxNDj8i0OfF5hRnPf28=; b=dAOfXSZL7WZV/jGa9rtlUDptYllFtfTO6oNLxVrkXawJuOG9MgYQ5Ihez9YH77AC8/ iq307QGQyEqfLwqRF9RPVU8g09ClAV80Uj/gLe3aW6Ik0lGmocMlRjLQKlBMp2nTLbYu FLRVOFuqJrQIMSgqNrq8h/CIvBrr4npxVo47Vb32zOSpSJOLyZP2UDhoOJS5LmYdhxh/ 5+RpiuSudcvKJZv+XQGVKnLUgNj0EQcrk1Cby4axsukOp6PO8cmglANP5lOfDxyVZIQL k8Sl2tDO5BeQFtFNUhLexPYdfIETpxicPm6vct7Gm5f9GgbB+zdi7lZj9KE0HOr23nk+ NjOg== X-Gm-Message-State: AC+VfDxWC8PNt3P7wWY0kCbsCrT4//h2Ftm7uGDJhX8lGTXh9ffzqqgv rWRbQNehYWRtpnD36FwOcqOxE/Ct5Wh0prtvlxQ/ng== X-Google-Smtp-Source: ACHHUZ7vVtHeraUXT/fPsL4nXMz+KEQZapZKaH819O01jQQkap6BMzX9ZaJSURqmd2km92aqJxXwqbnyuCd2GFHLlw4= X-Received: by 2002:a81:834b:0:b0:561:afe7:40bf with SMTP id t72-20020a81834b000000b00561afe740bfmr3529274ywf.5.1684327633778; Wed, 17 May 2023 05:47:13 -0700 (PDT) List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 References: <77CD0716-3BC8-47EB-8743-F2BD9CA43D31@yahoo.com> <432A1A16-9FE5-4339-AB38-8F3E03A5D4EF@yahoo.com> In-Reply-To: From: Doug Rabson Date: Wed, 17 May 2023 13:47:02 +0100 Message-ID: Subject: Re: Raspberry Pi POE+ hat overlay To: Nuno Teixeira Cc: freebsd-arm@freebsd.org Content-Type: multipart/alternative; boundary="0000000000004c0d7e05fbe316c0" X-Rspamd-Queue-Id: 4QLtD265N2z4M0K X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --0000000000004c0d7e05fbe316c0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I'm not sure about 12.3 either - you could try with 13.2 and see if that makes a difference. On Wed, 17 May 2023 at 13:45, Nuno Teixeira wrote: > Hey, > > Ok. I'm new to rpi4 and arm in general but tomorrow I will force > 'arm_freq=3D1800' again just to see it it crashes again. > I will check too what values linux shows. > > I don't know if firmware/uboot version included in 12.3 supports this > feature. > > Cheers, > > Doug Rabson escreveu no dia quarta, 17/05/2023 =C3=A0(s) > 13:11: > >> Hi Nuno, >> >> I'm not sure where to start - I just happened to notice in the >> documentation here: >> https://www.raspberrypi.com/documentation/computers/config_txt.html that >> the cpu frequency Pi4B R1.4 was listed as 1800 if arm_boot=3D1 so I trie= d it. >> >> Doug. >> >> >> >> On Wed, 17 May 2023 at 11:11, Nuno Teixeira wrote: >> >>> Hello Doug, >>> >>> I have too a 1.5 rpi but arm_boost=3D1 isn't doing anything, htop shows >>> 1500Mhz when doing something intensive. >>> I'm running 13.2 stable >>> >>> Do I missing something? >>> >>> Could you take a look at my setup? >>> >>> Thanks, >>> >>> Doug Rabson escreveu no dia ter=C3=A7a, 16/05/2023 =C3= =A0(s) >>> 17:19: >>> >>>> >>>> On Sat, 13 May 2023 at 13:45, Doug Rabson wrote: >>>> >>>>> I was able to build an updated rpi-firmware port based on 1.20210805 >>>>> and this boots successfully on pi400 as well as rpi4. With this, I ca= n load >>>>> the rpi-poe-plus overlay and I just need to try and reverse engineer = the >>>>> undocumented mailbox API by reading the Linux code. >>>>> >>>> >>>> I have a first approximation of a fan driver which works with the >>>> 1.20210805 firmware (actually, I substituted rpi-poe-plus.dtbo from >>>> 1.20210831 which just changes the fan levels for the POE+). I'm testin= g >>>> with an rpi4B rev 1.5 with 'make -j4 buildworld' and the fan is keepin= g the >>>> cpu temperature below 65 degrees which is nice, especially since I set >>>> arm_boost=3D1 in config.txt which boosts the cpu frequency up to 1800 = for >>>> this board. >>>> >>>> Does anyone have a pointer to the problem with firmware later than >>>> 20210805? Would it make any kind of sense to try to get the fix into >>>> releng/13.2 as an errata? >>>> >>>> >>> >>> -- >>> Nuno Teixeira >>> FreeBSD Committer (ports) >>> >> > > -- > Nuno Teixeira > FreeBSD Committer (ports) > --0000000000004c0d7e05fbe316c0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm not sure about 12.3 either - you could try with 13= .2 and see if that makes a difference.

=
On Wed, 17 May 2023 at 13:45, Nuno Te= ixeira <eduardo@freebsd.org&g= t; wrote:
Hey,
Ok. I'm new to rpi4 and arm in general but tomorrow I will= force 'arm_freq=3D1800' again just to see it it crashes again.
I will check too what values linux shows.

I= don't know if firmware/uboot version included in 12.3 supports this fe= ature.

Cheers,

Doug Rabson <dfr@rabson.org> escreveu n= o dia quarta, 17/05/2023 =C3=A0(s) 13:11:
Hi Nuno,

I'm not sure where to start - I j= ust happened to notice in the documentation here:=C2=A0https://www.raspberrypi.com/documentation/computers/config_txt.html = that the cpu frequency Pi4B R1.4 was listed as 1800 if arm_boot=3D1 so I tr= ied it.

Doug.


<= /div>
O= n Wed, 17 May 2023 at 11:11, Nuno Teixeira <eduardo@freebsd.org> wrote:
Hello Doug,

I= have too a 1.5 rpi but arm_boost=3D1 isn't doing anything, htop shows = 1500Mhz when doing something intensive.
I'm running 13.2 stab= le

Do I missing something?

Could you take a look at my setup?

Thanks,

Doug Rabson <dfr= @rabson.org> escreveu no dia ter=C3=A7a, 16/05/2023 =C3=A0(s) 17:19:=

On Sat, 13 May= 2023 at 13:45, Doug Rabson <dfr@rabson.org> wrote:
I was able to build an updated rpi-firmware port based on 1.202108= 05 and this boots successfully on pi400 as well as rpi4. With this, I can l= oad the rpi-poe-plus overlay and I just need to try and reverse engineer th= e undocumented mailbox API by reading the Linux code.

I have a first approximation of a fan driver which works w= ith the 1.20210805 firmware (actually, I substituted rpi-poe-plus.dtbo from= 1.20210831 which just changes the fan levels for the POE+). I'm testin= g with an rpi4B rev 1.5 with 'make -j4 buildworld' and the fan is k= eeping the cpu temperature below 65 degrees which is nice, especially since= I set arm_boost=3D1 in config.txt which boosts the cpu frequency up to 180= 0 for this board.

Does anyone have a pointer to th= e problem with firmware later than 20210805? Would it make any kind of sens= e to try to get the fix into releng/13.2 as an errata?

=


--
Nuno TeixeiraFreeBSD Committer (ports)


--
Nuno TeixeiraFreeBSD Committer (ports)
--0000000000004c0d7e05fbe316c0-- From nobody Wed May 17 13:08:11 2023 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 4QLthS6zGGz4B701 for ; Wed, 17 May 2023 13:08:24 +0000 (UTC) (envelope-from eduardo@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 4QLthS6QtMz3CgV for ; Wed, 17 May 2023 13:08:24 +0000 (UTC) (envelope-from eduardo@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1684328904; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=pdwSK5oG0GmiQdIy3+RN3VIfT/9l7SNf1CR52+MyTKw=; b=HFO02iQFbOqgQonz3zQV1uc9myMKe4mFVLUAmPNTJQt0GoZ4vCyU3Xk94RRmppHvfjqf+4 M1hsqT45yLvUW7TtzC4QUzFrU/ZNqxx6hfZYME9RZyXmv08NhdJpjuCQBAy/rYQexdRWNw 8LUEbveHOnvwlRHMME0nV5AdNQn8BFOvQY9fzJ9F4t+73631q0RwiVr7tgQgfNlxr3FC15 EQb2QdRo/b+KZ5RS2L7yc+GFZ+7NfyhBKKKTtyJDIMzVhCSPXE7I8rfyJVpegwLYWQxmvf be/FWwJrL7n8F9hOt9OTYDrTfhhuWFa7UUkejvJhb8L6UmtwbZlLpq3GFYgQ3A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1684328904; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=pdwSK5oG0GmiQdIy3+RN3VIfT/9l7SNf1CR52+MyTKw=; b=x5xq3ts8qS1WDR9Cj3fVnq40K1iZB87Houw6C7J4HJ7T74mBImPL0CyC+tqWCJLfHAOW4q UqddMBDFYMmOToT5KTMiOO8cllZQITnafRIdT1rCd0mYO9oID6E8cJCifIlNeUbs/8efi4 /bzS1spTFeKK0KfhC3uNd1KkJA765jm7Z8pmH1lsg7fFc/Xm99ENz9LprWl7v51vaTGxJB kC8kwvK6nL1zZrw1EHWfW/uZNCdr7wLb9XP/I5BD/xM8j1aE5yaxfJI3/TsDnR9agRQxUp PSzv2L12YUbAR4BvfCXAa1YCIdKPsponiPtSy7MCwZB7okjPs2PdiCtUeCx4JA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1684328904; a=rsa-sha256; cv=none; b=uy8zNTpVIDordwBqtMjXAFt7Ue2sD8b+8eZkYLQa1VMkiF+2Etisc/V8Uqw5Jo5ua4WoVm ESzb9yA2OVSbwWnYQo/KpDozwLJHMFQqIIM5daXGjnv02KhadHIt/qfkXsq4alWCvtcTx9 vSJ2GJaN3p5xM+5oVdwfUwMi/cZZZ/HMEL3NxzpQpECv7qo+yZewyK182KaW1GeHWWrkQx 7iOM6k2tvUW7s49SOYJrxu/fQ9m8ENz+ZB8w2qG6COU0nGWoP6stGBzaHCIGnFf1PbCYdH amKCKxc+McK6+2KflpmZGQ1Z7nbHul/GkXJVam3ztFpf3xmZDh57jKRuuc0fHQ== Received: from mail-pj1-f42.google.com (mail-pj1-f42.google.com [209.85.216.42]) (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)) (Authenticated sender: eduardo) by smtp.freebsd.org (Postfix) with ESMTPSA id 4QLthS5MHczwrN for ; Wed, 17 May 2023 13:08:24 +0000 (UTC) (envelope-from eduardo@freebsd.org) Received: by mail-pj1-f42.google.com with SMTP id 98e67ed59e1d1-24df4ecdb87so595488a91.0 for ; Wed, 17 May 2023 06:08:24 -0700 (PDT) X-Gm-Message-State: AC+VfDyBab6iNbbs7m8rYjvoR+t6en2CoS/3MeqXCu27bd8zOAKLpGZB DeeCd+7SwmyCZBlr1qVLLWt/uIlbIxApf/vY1VU= X-Google-Smtp-Source: ACHHUZ6AB8xh1YvnaXDdNGm5e7mQNUP5fzTQZbWU4gE8peK4xD8pCOs6xU4s1Tgnz0ZlAdaN/FOgfWwgsX5GuH18pRk= X-Received: by 2002:a17:90a:4d8f:b0:253:3662:9825 with SMTP id m15-20020a17090a4d8f00b0025336629825mr4157826pjh.8.1684328903617; Wed, 17 May 2023 06:08:23 -0700 (PDT) List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 References: <77CD0716-3BC8-47EB-8743-F2BD9CA43D31@yahoo.com> <432A1A16-9FE5-4339-AB38-8F3E03A5D4EF@yahoo.com> In-Reply-To: From: Nuno Teixeira Date: Wed, 17 May 2023 14:08:11 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Raspberry Pi POE+ hat overlay To: Doug Rabson Cc: freebsd-arm@freebsd.org Content-Type: multipart/alternative; boundary="000000000000fc356d05fbe3614b" X-ThisMailContainsUnwantedMimeParts: N --000000000000fc356d05fbe3614b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable (...) I was meant using 13.2 not 12.3 :) Doug Rabson escreveu no dia quarta, 17/05/2023 =C3=A0(s) 1= 3:47: > I'm not sure about 12.3 either - you could try with 13.2 and see if that > makes a difference. > > On Wed, 17 May 2023 at 13:45, Nuno Teixeira wrote: > >> Hey, >> >> Ok. I'm new to rpi4 and arm in general but tomorrow I will force >> 'arm_freq=3D1800' again just to see it it crashes again. >> I will check too what values linux shows. >> >> I don't know if firmware/uboot version included in 12.3 supports this >> feature. >> >> Cheers, >> >> Doug Rabson escreveu no dia quarta, 17/05/2023 =C3=A0(s= ) >> 13:11: >> >>> Hi Nuno, >>> >>> I'm not sure where to start - I just happened to notice in the >>> documentation here: >>> https://www.raspberrypi.com/documentation/computers/config_txt.html >>> that the cpu frequency Pi4B R1.4 was listed as 1800 if arm_boot=3D1 so = I >>> tried it. >>> >>> Doug. >>> >>> >>> >>> On Wed, 17 May 2023 at 11:11, Nuno Teixeira wrote= : >>> >>>> Hello Doug, >>>> >>>> I have too a 1.5 rpi but arm_boost=3D1 isn't doing anything, htop show= s >>>> 1500Mhz when doing something intensive. >>>> I'm running 13.2 stable >>>> >>>> Do I missing something? >>>> >>>> Could you take a look at my setup? >>>> >>>> Thanks, >>>> >>>> Doug Rabson escreveu no dia ter=C3=A7a, 16/05/2023 = =C3=A0(s) >>>> 17:19: >>>> >>>>> >>>>> On Sat, 13 May 2023 at 13:45, Doug Rabson wrote: >>>>> >>>>>> I was able to build an updated rpi-firmware port based on 1.20210805 >>>>>> and this boots successfully on pi400 as well as rpi4. With this, I c= an load >>>>>> the rpi-poe-plus overlay and I just need to try and reverse engineer= the >>>>>> undocumented mailbox API by reading the Linux code. >>>>>> >>>>> >>>>> I have a first approximation of a fan driver which works with the >>>>> 1.20210805 firmware (actually, I substituted rpi-poe-plus.dtbo from >>>>> 1.20210831 which just changes the fan levels for the POE+). I'm testi= ng >>>>> with an rpi4B rev 1.5 with 'make -j4 buildworld' and the fan is keepi= ng the >>>>> cpu temperature below 65 degrees which is nice, especially since I se= t >>>>> arm_boost=3D1 in config.txt which boosts the cpu frequency up to 1800= for >>>>> this board. >>>>> >>>>> Does anyone have a pointer to the problem with firmware later than >>>>> 20210805? Would it make any kind of sense to try to get the fix into >>>>> releng/13.2 as an errata? >>>>> >>>>> >>>> >>>> -- >>>> Nuno Teixeira >>>> FreeBSD Committer (ports) >>>> >>> >> >> -- >> Nuno Teixeira >> FreeBSD Committer (ports) >> > --=20 Nuno Teixeira FreeBSD Committer (ports) --000000000000fc356d05fbe3614b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
(...)

I was meant using 13.2= not 12.3 :)

Doug Rabson <dfr= @rabson.org> escreveu no dia quarta, 17/05/2023 =C3=A0(s) 13:47:
=
I&= #39;m not sure about 12.3 either - you could try with 13.2 and see if that = makes a difference.

On Wed, 17 May 2023 at 13:45, Nuno Teixeira <eduardo@freebsd.org&g= t; wrote:
Hey,

Ok. I'm new to rpi4 and a= rm in general but tomorrow I will force 'arm_freq=3D1800' again jus= t to see it it crashes again.
I will check too what values linux = shows.

I don't know if firmware/uboot version = included in 12.3 supports this feature.

Cheers,

Doug Rabson <= dfr@rabson.org> escreveu no dia quarta, 17/05/2023 =C3=A0(s) 13:11:<= br>
Hi Nuno,

I'm not sure where to start - I just happe= ned to notice in the documentation here:=C2=A0https:= //www.raspberrypi.com/documentation/computers/config_txt.html that the = cpu frequency Pi4B R1.4 was listed as 1800 if arm_boot=3D1 so I tried it.

Doug.



=
On Wed, 17= May 2023 at 11:11, Nuno Teixeira <eduardo@freebsd.org> wrote:
Hello Doug,

I have too a 1.5 rpi but arm_boost=3D1 isn't doi= ng anything, htop shows 1500Mhz when doing something intensive.
I= 'm running 13.2 stable

Do I missing something?=

Could you take a look at my setup?

=
Thanks,

Doug Rabson <dfr@rabson.org> escreveu no dia ter=C3=A7a, 1= 6/05/2023 =C3=A0(s) 17:19:

On Sat, 13 May 2023 at 13:45, = Doug Rabson <dfr@rab= son.org> wrote:
I was able to build an updated rpi-firmware port ba= sed on 1.20210805 and this boots successfully on pi400 as well as rpi4. Wit= h this, I can load the rpi-poe-plus overlay and I just need to try and reve= rse engineer the undocumented mailbox API by reading the Linux code.
<= /blockquote>

I have a first approximation of a fan drive= r which works with the 1.20210805 firmware (actually, I substituted rpi-poe= -plus.dtbo from 1.20210831 which just changes the fan levels for the POE+).= I'm testing with an rpi4B rev 1.5 with 'make -j4 buildworld' a= nd the fan is keeping the cpu temperature below 65 degrees which is nice, e= specially since I set arm_boost=3D1 in config.txt which boosts the cpu freq= uency up to 1800 for this board.

Does anyone have = a pointer to the problem with firmware later than 20210805? Would it make a= ny kind of sense to try to get the fix into releng/13.2 as an errata?
=



--
Nuno TeixeiraFreeBSD Committer (ports)


--
Nuno TeixeiraFreeBSD Committer (ports)


--
Nuno Teixeira
FreeBSD Committ= er (ports)
--000000000000fc356d05fbe3614b-- From nobody Wed May 17 11:33:22 2023 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 4QLvG05LvCz4B8FH for ; Wed, 17 May 2023 13:34:00 +0000 (UTC) (envelope-from marietto2008@gmail.com) Received: from mail-yw1-x112d.google.com (mail-yw1-x112d.google.com [IPv6:2607:f8b0:4864:20::112d]) (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 4QLvG00n2Nz3JmP for ; Wed, 17 May 2023 13:34:00 +0000 (UTC) (envelope-from marietto2008@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-yw1-x112d.google.com with SMTP id 00721157ae682-559f1819c5dso8365837b3.0 for ; Wed, 17 May 2023 06:34:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1684330438; x=1686922438; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=f8ERuI2ww7octb5o3Vv7n3RblmF2OQvIcOcxKknxFpA=; b=QOK4QkNIG9JDJebyzulXXxNFQZVKDJ3OrOsJYv5V5BFhA/fEj17xtbhlfTdxjYrFJz 0XxMUgyCOif9WKunf07WpcRnvofwR4L0VHF9J4UdGDV0ZLIvhTK1VRDihvhdxXYJ55sE Rq0DjJfwdyKWXxoMYKzrO22iBBXamhYNhZFLUeO7hVUfg9yLacEA3jfCxNVxJ0iEE3is R7U26NC8uEUaKBkAZIWfuy5CsRbc24B33Mh4pCFSZZHqACdi3EpFiQJKu/eKJbi5Vkac qo6u9b8g7jvMUc+KDjKwYgZYYAKhcreDTf0M+tqWcCR/GVOOJuwmaRfo4YNZmgIkkHkY wK8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684330438; x=1686922438; 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=f8ERuI2ww7octb5o3Vv7n3RblmF2OQvIcOcxKknxFpA=; b=kxg6pYdS83yY+DZJxNK0jkIx0b6FvB/bdzclM1sES5FRgmNcbpMG2KN7dAd8/oewB7 Y2GhWSF21qyDepf+EPD5XN6YqPLyRgC4Zk1l/vnR3482fHa8LoxaC/LoANA0wdtHSxWC PbeVtEdis06uzEzwV0b22Rm/AwAy+hSO0t8Iev/pgL1pQCJzoPKoNSLbnDDGZ4N+mozP mrWkbhhuUW6eUKmuOhn0p6OBXEscKSyGLIyzktN0aDdueGATkf3/hE3QU6AX7/DxcsdN sjzbbQQhilDJqg5XDo2O/4mpejhbzq0dsT4EdyxZItU5SZT2LFK+8FOlHwmsuyT22Es4 GnDg== X-Gm-Message-State: AC+VfDxRkdnW0iP6T1hLQiGuzZD7YFdwpdGW/G/KohX+rVkkeJKlDLeJ gTaWcQ8HoKwXwP3v3xBmZNZ4hIgcDM/SFHM5oui++RoZ0wI= X-Google-Smtp-Source: ACHHUZ7zNr7uIpV7v1w2uZEpIr6TxGOZbRTZO/YGqTV1zV9AfHv7ZP2UPTbaAF029wOQGy7vl521jsSEFlxNzGxmWII= X-Received: by 2002:a0d:ccd8:0:b0:55a:9b5a:1d9f with SMTP id o207-20020a0dccd8000000b0055a9b5a1d9fmr38656001ywd.11.1684330438448; Wed, 17 May 2023 06:33:58 -0700 (PDT) List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 References: <7CCEC16E-41A1-4318-B953-EF61D17EEE3C@mit.edu> <2f69f9a1-e976-65d6-c0be-74404640d1c1@shrew.net> <08360ee6-6829-5362-8188-cdbd2c20e59b@bsdio.com> <9aacad10-01c1-a0b5-a2de-32abf670feec@bsdio.com> In-Reply-To: <9aacad10-01c1-a0b5-a2de-32abf670feec@bsdio.com> From: Mario Marietto Date: Wed, 17 May 2023 13:33:22 +0200 Message-ID: Subject: Re: ARM64 virtualization? To: Rebecca Cran Cc: Matthew Grooms , freebsd-arm@freebsd.org, Elena Mihailescu , Mihai Carabas Content-Type: multipart/alternative; boundary="00000000000077da2b05fbe3bd4d" X-Rspamd-Queue-Id: 4QLvG00n2Nz3JmP X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_RCPT(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --00000000000077da2b05fbe3bd4d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable oh my god. That's such a nice toy to play with. Too much expensive for my pockets. I'm making experiences with cheaper socs like the tegra ones,jetson nano and maybe in the next future,the jetson orin. Do you think that if I buy the jetson orin,I could be able to help you,anyway ? On Wed, May 17, 2023 at 2:11=E2=80=AFPM Rebecca Cran wr= ote: > I'm getting the Ampere Developer Kit from > https://www.ipi.wiki/products/com-hpc-ampere-altra . > > > -- > > Rebecca Cran > > > On 5/16/23 10:14, Mario Marietto wrote: > > Hello Rebecca, > > > > i will be happy to help you. what system you will buy ? i want to > > evaluate the cost. If it is affordable for me I will also buy the same > > and i could test your code or something else task that you need. i ve > > been always interested in the bhyve development. > > > > Il mar 16 mag 2023, 17:41 Rebecca Cran ha scritto: > > > > On 5/15/23 13:58, Matthew Grooms wrote: > > > > > On 5/15/2023 2:39 PM, John F Carr wrote: > > >> Is there any active work on getting bhyve virtualization > > working on > > >> 64 bit ARM? I see some work was started a few years ago (e.g. > > >> https://reviews.freebsd.org/D26976, > > >> https://bhyvecon.org/bhyvecon2016-Mihai.pdf). It seems to have > > been > > >> abandoned or at least stalled. > > >> > > >> I may be able to help. It's not a project I can take on myself. > > > > > > Porting bhyve to arm has been one of the longest running UPB > > projects. > > > You can find more info on the history here ... > > > > > > > > > https://wiki.freebsd.org/DevSummit/202303?action=3DAttachFile&do=3Dview&t= arget=3DPresentation+-+bhyvecon.pdf > > < > https://wiki.freebsd.org/DevSummit/202303?action=3DAttachFile&do=3Dview&t= arget=3DPresentation+-+bhyvecon.pdf > > > > > > > > > > > > > Your best bet is probably to take a look a the following review > > opened > > > by Andrew Turner late last year. His work is based on the origina= l > > > port by the UPB team ... > > > > > > https://reviews.freebsd.org/D37428 > > > > > > I can't speak to the current state of this work. From what I > > recall, > > > there were several attempts made by UPB to collaborate, but they > > > failed to get a response. Perhaps he/they can chime in here with > > more > > > detail. > > > > I'll be getting an Ampere system in the next few weeks and hope to = be > > able to work on the Aarch64 bhyve code. > > > > > > -- > > > > Rebecca Cran > > > > > --=20 Mario. --00000000000077da2b05fbe3bd4d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
oh my god. That's such a nice toy to play with. Too mu= ch expensive for my pockets. I'm making experiences with cheaper socs l= ike the tegra ones,jetson nano and maybe in the next future,the jetson orin= . Do you think that if I buy the jetson orin,I could be able to help you,an= yway ?

On Wed, May 17, 2023 at 2:11=E2=80=AFPM Rebecca Cran <rebecca@bsdio.com> wrote:
I'm getting the Ampere D= eveloper Kit from
https://www.ipi.wiki/products/com-hpc-ampere-altra= .


--

Rebecca Cran


On 5/16/23 10:14, Mario Marietto wrote:
> Hello Rebecca,
>
> i will be happy to help you. what system you will buy ? i want to
> evaluate the cost. If it is affordable for me I will also buy the same=
> and i could test your code or something else task that you need. i ve =
> been always interested in the bhyve development.
>
> Il mar 16 mag 2023, 17:41 Rebecca Cran <rebecca@bsdio.com> ha scritto:
>
>=C2=A0 =C2=A0 =C2=A0On 5/15/23 13:58, Matthew Grooms wrote:
>
>=C2=A0 =C2=A0 =C2=A0> On 5/15/2023 2:39 PM, John F Carr wrote:
>=C2=A0 =C2=A0 =C2=A0>> Is there any active work on getting bhyve = virtualization
>=C2=A0 =C2=A0 =C2=A0working on
>=C2=A0 =C2=A0 =C2=A0>> 64 bit ARM?=C2=A0 I see some work was star= ted a few years ago (e.g.
>=C2=A0 =C2=A0 =C2=A0>> https://reviews.freebsd.org/D2697= 6,
>=C2=A0 =C2=A0 =C2=A0>> https://bhyvecon.org/bhy= vecon2016-Mihai.pdf). It seems to have
>=C2=A0 =C2=A0 =C2=A0been
>=C2=A0 =C2=A0 =C2=A0>> abandoned or at least stalled.
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> I may be able to help.=C2=A0 It's not = a project I can take on myself.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> Porting bhyve to arm has been one of the longe= st running UPB
>=C2=A0 =C2=A0 =C2=A0projects.
>=C2=A0 =C2=A0 =C2=A0> You can find more info on the history here ...=
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0https://wiki.freebsd.org/DevSummit/= 202303?action=3DAttachFile&do=3Dview&target=3DPresentation+-+bhyvec= on.pdf
>=C2=A0 =C2=A0 =C2=A0<https://wiki.freebsd.org/DevSum= mit/202303?action=3DAttachFile&do=3Dview&target=3DPresentation+-+bh= yvecon.pdf>
>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> Your best bet is probably to take a look a the= following review
>=C2=A0 =C2=A0 =C2=A0opened
>=C2=A0 =C2=A0 =C2=A0> by Andrew Turner late last year. His work is b= ased on the original
>=C2=A0 =C2=A0 =C2=A0> port by the UPB team ...
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> https://reviews.freebsd.org/D37428
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> I can't speak to the current state of this= work. From what I
>=C2=A0 =C2=A0 =C2=A0recall,
>=C2=A0 =C2=A0 =C2=A0> there were several attempts made by UPB to col= laborate, but they
>=C2=A0 =C2=A0 =C2=A0> failed to get a response. Perhaps he/they can = chime in here with
>=C2=A0 =C2=A0 =C2=A0more
>=C2=A0 =C2=A0 =C2=A0> detail.
>
>=C2=A0 =C2=A0 =C2=A0I'll be getting an Ampere system in the next fe= w weeks and hope to be
>=C2=A0 =C2=A0 =C2=A0able to work on the Aarch64 bhyve code.
>
>
>=C2=A0 =C2=A0 =C2=A0--
>
>=C2=A0 =C2=A0 =C2=A0Rebecca Cran
>
>


--
Mario.
--00000000000077da2b05fbe3bd4d-- From nobody Wed May 17 14:20:59 2023 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 4QLwJF6Cr8z4BBmH for ; Wed, 17 May 2023 14:21:01 +0000 (UTC) (envelope-from rebecca@bsdio.com) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (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 4QLwJF4YdCz3Qd3 for ; Wed, 17 May 2023 14:21:01 +0000 (UTC) (envelope-from rebecca@bsdio.com) Authentication-Results: mx1.freebsd.org; none Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id A5FBE5C00BF; Wed, 17 May 2023 10:21:00 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Wed, 17 May 2023 10:21:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdio.com; h=cc :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:sender:subject:subject:to:to; s=fm2; t= 1684333260; x=1684419660; bh=B218UBYh7+OIIZSs/lBkfagogbBxZiObpSh NcY6r6TY=; b=Tp4/Iai+C33m6a27qK7X04mhIRGsd39xn2S+TNdD7PynGUbH6Nb Rl0Slm+njaqy+jr9iF/DT3Gj2GB4E9CY6I6kYe1AMEFl4Xf811FSnK/UXo7ZrKyW 7Q5lScBe7ynRdGMpEvSy/1FMvGqEIBucPP//a8fhakWmzzRPDcPFqvpFyDeSEAlu F53Hxd7YGNEO+nQIiQ9KHHduvrkA494wl6Rw2bRdQUuNWBFg216z3U6NxY2FYbs+ PME3yuz0OgjEZfnj4K2pNiQEaBrnvKMSBjNQk4ggz0FezOQVjTIGUqEPqIGewbHZ Q49t06nFTY7vm3Pxw3ZRO36nJhYnC05igFA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc: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:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t= 1684333260; x=1684419660; bh=B218UBYh7+OIIZSs/lBkfagogbBxZiObpSh NcY6r6TY=; b=Hc7O7ut09iuGHuh/kAn89cPlTSXfM4zkqHyu2Z5lXVyVXKZ0LA0 PnccMEtn+s3HrvWP4Fh8VqysNU3woWQcqPZ7U3IA7M7aMKy9TTlcODiSQXB4zdZe NES+Yzvxp36yfFztUPI4LZmj8i3GALQKjuil6zqDkMUi61pg7mAU7gPCeABEAn8n /cihKu7i0Lg4HBONpH731HBqYlk0ikxqLWrgVw5yc/Rh/+OQhR4AE9LgeMjwNtNL kccEfHgRHUHt5ApDE8h/0Z4Eoh+qyuYTgt9Qpj0KqvxLDbm3H4OFnv7fFQ4HcqNt cgFe1a5e1F9BPojlSBEPBcIfUc6+Hlan1BA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrfeeiuddgjeeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtkeertddtfeejnecuhfhrohhmpeftvggs vggttggrucevrhgrnhcuoehrvggsvggttggrsegsshguihhordgtohhmqeenucggtffrrg htthgvrhhnpedtueejtdevfffghfekgfevtdfhheettdfghfeiledtueegfeeuhfeglefg ueefueenucffohhmrghinhepihhpihdrfihikhhipdhfrhgvvggsshgurdhorhhgpdgshh ihvhgvtghonhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgr ihhlfhhrohhmpehrvggsvggttggrsegsshguihhordgtohhm X-ME-Proxy: Feedback-ID: i5b994698:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 17 May 2023 10:20:59 -0400 (EDT) Message-ID: <59668841-6006-51e4-dcfa-efe75542e064@bsdio.com> Date: Wed, 17 May 2023 08:20:59 -0600 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/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Subject: Re: ARM64 virtualization? Content-Language: en-US To: Mario Marietto Cc: Matthew Grooms , freebsd-arm@freebsd.org, Elena Mihailescu , Mihai Carabas References: <7CCEC16E-41A1-4318-B953-EF61D17EEE3C@mit.edu> <2f69f9a1-e976-65d6-c0be-74404640d1c1@shrew.net> <08360ee6-6829-5362-8188-cdbd2c20e59b@bsdio.com> <9aacad10-01c1-a0b5-a2de-32abf670feec@bsdio.com> From: Rebecca Cran In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4QLwJF4YdCz3Qd3 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:19151, ipnet:66.111.4.0/24, country:US]; TAGGED_RCPT(0.00)[] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N Hmm, the Jetson Orin does appear to support virtualization and apparently people have had success with KVM under Linux. I'm wondering how well-supported FreeBSD would be on it since it still uses FDT, and trying to boot Linux using ACPI instead didn't go well. I have an Orin Development Kit here I could try. If FreeBSD boots on it, then I can start working on bhyve before my Ampere system gets here. -- Rebecca Cran On 5/17/23 05:33, Mario Marietto wrote: > oh my god. That's such a nice toy to play with. Too much expensive for > my pockets. I'm making experiences with cheaper socs like the tegra > ones,jetson nano and maybe in the next future,the jetson orin. Do you > think that if I buy the jetson orin,I could be able to help you,anyway ? > > On Wed, May 17, 2023 at 2:11 PM Rebecca Cran wrote: > > I'm getting the Ampere Developer Kit from > https://www.ipi.wiki/products/com-hpc-ampere-altra . > > > -- > > Rebecca Cran > > > On 5/16/23 10:14, Mario Marietto wrote: > > Hello Rebecca, > > > > i will be happy to help you. what system you will buy ? i want to > > evaluate the cost. If it is affordable for me I will also buy > the same > > and i could test your code or something else task that you need. > i ve > > been always interested in the bhyve development. > > > > Il mar 16 mag 2023, 17:41 Rebecca Cran ha > scritto: > > > >     On 5/15/23 13:58, Matthew Grooms wrote: > > > >     > On 5/15/2023 2:39 PM, John F Carr wrote: > >     >> Is there any active work on getting bhyve virtualization > >     working on > >     >> 64 bit ARM?  I see some work was started a few years ago > (e.g. > >     >> https://reviews.freebsd.org/D26976, > >     >> https://bhyvecon.org/bhyvecon2016-Mihai.pdf). It seems to > have > >     been > >     >> abandoned or at least stalled. > >     >> > >     >> I may be able to help.  It's not a project I can take on > myself. > >     > > >     > Porting bhyve to arm has been one of the longest running UPB > >     projects. > >     > You can find more info on the history here ... > >     > > >     > > > > https://wiki.freebsd.org/DevSummit/202303?action=AttachFile&do=view&target=Presentation+-+bhyvecon.pdf > > >    >   > > > > >     > > >     > > >     > Your best bet is probably to take a look a the following > review > >     opened > >     > by Andrew Turner late last year. His work is based on the > original > >     > port by the UPB team ... > >     > > >     > https://reviews.freebsd.org/D37428 > >     > > >     > I can't speak to the current state of this work. From what I > >     recall, > >     > there were several attempts made by UPB to collaborate, > but they > >     > failed to get a response. Perhaps he/they can chime in > here with > >     more > >     > detail. > > > >     I'll be getting an Ampere system in the next few weeks and > hope to be > >     able to work on the Aarch64 bhyve code. > > > > > >     -- > > > >     Rebecca Cran > > > > > > > > -- > Mario. From nobody Wed May 17 14:45:03 2023 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 4QLwrP625Lz4BD40 for ; Wed, 17 May 2023 14:45:25 +0000 (UTC) (envelope-from bT.i32rlwwd30=ewam9ng5obn5=jcculqb5ry@em790814.fubar.geek.nz) Received: from e2i580.smtp2go.com (e2i580.smtp2go.com [103.2.142.68]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4QLwrM0mjDz3kdN for ; Wed, 17 May 2023 14:45:22 +0000 (UTC) (envelope-from bT.i32rlwwd30=ewam9ng5obn5=jcculqb5ry@em790814.fubar.geek.nz) Authentication-Results: mx1.freebsd.org; dkim=none ("invalid DKIM record") header.d=smtpservice.net header.s=mgy720.a1-4.dyn header.b=bP6V4sMw; dkim=pass header.d=fubar.geek.nz header.s=s790814 header.b=KLTF18xk; spf=pass (mx1.freebsd.org: domain of "bT.i32rlwwd30=ewam9ng5obn5=jcculqb5ry@em790814.fubar.geek.nz" designates 103.2.142.68 as permitted sender) smtp.mailfrom="bT.i32rlwwd30=ewam9ng5obn5=jcculqb5ry@em790814.fubar.geek.nz"; dmarc=pass (policy=none) header.from=fubar.geek.nz DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=smtpservice.net; s=mgy720.a1-4.dyn; x=1684335622; h=Feedback-ID: X-Smtpcorp-Track:To:Message-Id:Date:From:Subject:Reply-To:Sender: List-Unsubscribe; bh=ysShbE7GfEFKIyxZNI3K5miAAtS56GgtRbqUE+AAdvg=; b=bP6V4sMw q4qdNKFRs9WgxWqDkeHekQjJwICzzhOsOFZ+CXQfdnvUZ3K4T9cZr8jP1Zzg1h0XdROzAb6aVV+8o 4TVDUfFUYgjr7hRHUw5eHwf7XgizYZYG3ZONsIXpFHUVd4VskX5lSIObmIqRwkjhhDvkFPVvk7Twn 1s/333fo54lg0yMyIxRiiEEnIFjlbl+yZuOB0bNpfDoulNmSzuHOZbbYyZgfBbKxGZsKRYoa3iSdk FOac94RlHM1ymPod+ZQgUrhCc5uQnSfYqpV0xn34RLpNxjPzFhhPXrt5yBI+d/myc3yEGGXk6FnwP 55i8mZgqRN2mmxcCDEtsY7Os8Q==; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fubar.geek.nz; i=@fubar.geek.nz; q=dns/txt; s=s790814; t=1684334722; h=from : subject : to : message-id : date; bh=ysShbE7GfEFKIyxZNI3K5miAAtS56GgtRbqUE+AAdvg=; b=KLTF18xkO1lH4oiKX8CyCTmvZfTcsOmczq7QZ7cZzszC4DMdgjZ314nlrccuF6bmqtWs9 OOkY27ukMqUwwtR0V+YmLUyOZXoR0RGDimuDPd9T1JNnrQGq9PEXEPRKd0x/kqN7wnACF4X FO6HSY0asOeECFfA6BHRdyPrUq32nG0uXxlV+7zseD7VI0CzC3C8yVeho/obfMzxqwTTGez f433iDJF4WA6EVehDgs4LNh/wxtvj/zyAaXyE3BNJCbF1cKayA+1WZNQAIE50zdXDnJiwEI 39tin8/S6TiJydSGm9D98dNB4RyKpb8EBRHcpcWM7lf+6X/LodcakKMCJ14w== Received: from [10.176.58.103] (helo=SmtpCorp) by smtpcorp.com with esmtpsa (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.94.2-S2G) (envelope-from ) id 1pzIP1-qt4GQU-Ki; Wed, 17 May 2023 14:45:20 +0000 Received: from [10.162.55.164] (helo=morbo.fubar.geek.nz) by smtpcorp.com with esmtpsa (TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.96-S2G) (envelope-from ) id 1pzIP1-9ERtMG-2j; Wed, 17 May 2023 14:45:19 +0000 Received: from smtpclient.apple (cpc91210-cmbg18-2-0-cust37.5-4.cable.virginm.net [81.102.44.38]) by morbo.fubar.geek.nz (Postfix) with ESMTPSA id 98692241C4; Wed, 17 May 2023 14:45:16 +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 \(3731.500.231\)) Subject: Re: ARM64 virtualization? From: Andrew Turner In-Reply-To: <7CCEC16E-41A1-4318-B953-EF61D17EEE3C@mit.edu> Date: Wed, 17 May 2023 15:45:03 +0100 Cc: "freebsd-arm@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <2985B4BD-EA24-40AD-950D-AF7BB6AE453B@fubar.geek.nz> References: <7CCEC16E-41A1-4318-B953-EF61D17EEE3C@mit.edu> To: John F Carr X-Mailer: Apple Mail (2.3731.500.231) X-Smtpcorp-Track: 1pzme19ERtuG2M.ZDhAae_hngiYb Feedback-ID: 790814m:790814amQcrys:790814ssh6YZy8C0 X-Report-Abuse: Please forward a copy of this message, including all headers, to X-Spamd-Result: default: False [-2.90 / 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.999]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[fubar.geek.nz,none]; RCVD_DKIM_ARC_DNSWL_MED(-0.50)[]; FORGED_SENDER(0.30)[andrew@fubar.geek.nz,bT.i32rlwwd30=ewam9ng5obn5=jcculqb5ry@em790814.fubar.geek.nz]; R_SPF_ALLOW(-0.20)[+ip4:103.2.140.0/22]; R_DKIM_ALLOW(-0.20)[fubar.geek.nz:s=s790814]; RCVD_IN_DNSWL_MED(-0.20)[103.2.142.68:from]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; R_DKIM_PERMFAIL(0.00)[smtpservice.net:s=mgy720.a1-4.dyn]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; MID_RHS_MATCH_FROM(0.00)[]; DKIM_MIXED(0.00)[]; TO_DN_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_NEQ_ENVFROM(0.00)[andrew@fubar.geek.nz,bT.i32rlwwd30=ewam9ng5obn5=jcculqb5ry@em790814.fubar.geek.nz]; RCVD_COUNT_THREE(0.00)[4]; DKIM_TRACE(0.00)[smtpservice.net:~,fubar.geek.nz:+]; RCPT_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:23352, ipnet:103.2.140.0/22, country:US]; RWL_MAILSPIKE_POSSIBLE(0.00)[103.2.142.68:from]; RCVD_TLS_ALL(0.00)[] X-Rspamd-Queue-Id: 4QLwrM0mjDz3kdN X-Spamd-Bar: -- X-ThisMailContainsUnwantedMimeParts: N > On 15 May 2023, at 20:39, John F Carr wrote: >=20 > Is there any active work on getting bhyve virtualization working on 64 = bit ARM? I see some work was started a few years ago (e.g. = https://reviews.freebsd.org/D26976, = https://bhyvecon.org/bhyvecon2016-Mihai.pdf). It seems to have been = abandoned or at least stalled. >=20 > I may be able to help. It's not a project I can take on myself. I=E2=80=99ve pushed the latest version of my updates to the Bhyve port = to [1]. This is an updated version of [2], along with the userspace = changes. This is all based on the work by UBP. Note that I may force push to this branch to keep up with FreeBSD main. Andrew [1] https://github.com/zxombie/freebsd/tree/bhyvearm64-main-rebasing [2] https://reviews.freebsd.org/D37428= From nobody Wed May 17 15:31:38 2023 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 4QLxtR3tMfz4BGQQ for ; Wed, 17 May 2023 15:32:15 +0000 (UTC) (envelope-from marietto2008@gmail.com) Received: from mail-yb1-xb36.google.com (mail-yb1-xb36.google.com [IPv6:2607:f8b0:4864:20::b36]) (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 4QLxtR1rY8z3pCP for ; Wed, 17 May 2023 15:32:15 +0000 (UTC) (envelope-from marietto2008@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-yb1-xb36.google.com with SMTP id 3f1490d57ef6-ba82059ef0bso754629276.1 for ; Wed, 17 May 2023 08:32:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1684337534; x=1686929534; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=wkoHzQkWKkDVmrYBwXANxR3DxdDvTK5PRsK+ibn8Kg0=; b=gA57DSfEyNJ7DqoGpgnFK42C0mquDbq1hXf7cZM8/h+jmERyEmpkJJNyaw/k9RdOHY wjl0QPmYUX2Bd1R5i89N3Z78/3Jmj1jdoudQsf87FvBiLzTLSPYzy/rbMKKVGl3EKC0q v4fDo3iOloNyhlXwqkOtOIUzqo1Zc1yddZbfguelmSywJJ3wJZcbHh66eeGhglnwZ0pX SUg1kKDziQvrhWOAC6V23jwjf1TiCgr8Guj0HA5uzN0nMKQDk7On5wC8+iD3axg0VyNG RGcgVavOr3l3DALNWO1GRMCv7zR7zBymlwk7RuC6QKiCwn17pVVVDkVfrQxhr14wmhr+ NFPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684337534; x=1686929534; 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=wkoHzQkWKkDVmrYBwXANxR3DxdDvTK5PRsK+ibn8Kg0=; b=OYZWD8oo67nRCU2+N8GV82lLTQT0jY/gNYLc+5nbBupp3o1zUhMjHQWdebeb0VQJyU 55kJL/6DriAQp4NdNQ7YSwexUzjlayfRi2xwFixBRQZORQgtEHZB9l/MHtIUBHQBGgIL IBBAqrXUeZW0pZrj271707YgjOxY1JPeQ1uttu4+AIPh5u5bpDTOhi0vpwrqpD86RVPP 61g6/0IqYWrJbW/9tMrdSCETizHFbugFq4uc0Fe4cSPEgm3UyP8e6642xz6uuAqsPOCb O9Tf6zX60/wcVGHtA3TU9e3UI01KoLnh9uZ9FOwZSyXwoKY7Obu9Pdq7UumHjrRIQOzb Weow== X-Gm-Message-State: AC+VfDy8arm1YX/IwmX/99MpiS8qnxssz4re3Jt0pLtaXCPDo2oaOAzA Njpxz2Gb1jbZ9px2KG0CFoq4hn67iBU8dVUcTJo= X-Google-Smtp-Source: ACHHUZ7PAvFphfFoKb+P0O+UDh75Y8HpDXF6MWz1MV6/N1ssRfe8uIVuSIrEo+tGGl3QK/x+1GUOClxtOUP0E0aeFoI= X-Received: by 2002:a25:aaef:0:b0:b9e:6d2c:ce2 with SMTP id t102-20020a25aaef000000b00b9e6d2c0ce2mr37072020ybi.46.1684337534137; Wed, 17 May 2023 08:32:14 -0700 (PDT) List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 References: <7CCEC16E-41A1-4318-B953-EF61D17EEE3C@mit.edu> <2f69f9a1-e976-65d6-c0be-74404640d1c1@shrew.net> <08360ee6-6829-5362-8188-cdbd2c20e59b@bsdio.com> <9aacad10-01c1-a0b5-a2de-32abf670feec@bsdio.com> <59668841-6006-51e4-dcfa-efe75542e064@bsdio.com> In-Reply-To: <59668841-6006-51e4-dcfa-efe75542e064@bsdio.com> From: Mario Marietto Date: Wed, 17 May 2023 17:31:38 +0200 Message-ID: Subject: Re: ARM64 virtualization? To: Rebecca Cran Cc: Matthew Grooms , freebsd-arm@freebsd.org, Elena Mihailescu , Mihai Carabas Content-Type: multipart/alternative; boundary="0000000000006781e705fbe564c5" X-Rspamd-Queue-Id: 4QLxtR1rY8z3pCP X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_RCPT(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --0000000000006781e705fbe564c5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sure. I've been (and I'm) one the most active users of the Jetson nano in the last years. I've enabled kvm again recently on my Jetson nano. I don't live without virtualization. I play every day with qemu,kvm,bhyve and every tool that can be used to virtualize an os. If kvm can be enabled on the jetson nano,why should it not work on the jetson orin ? I'm also very interested to install FreeBSD on the nano and on the orin. Unfortunately I haven't found someone who wants to help me. I can't handle this project alone. I'm not experienced enough. On Wed, May 17, 2023 at 4:21=E2=80=AFPM Rebecca Cran wr= ote: > Hmm, the Jetson Orin does appear to support virtualization and > apparently people have had success with KVM under Linux. > > I'm wondering how well-supported FreeBSD would be on it since it still > uses FDT, and trying to boot Linux using ACPI instead didn't go well. > > I have an Orin Development Kit here I could try. If FreeBSD boots on it, > then I can start working on bhyve before my Ampere system gets here. > > > -- > Rebecca Cran > > > On 5/17/23 05:33, Mario Marietto wrote: > > oh my god. That's such a nice toy to play with. Too much expensive for > > my pockets. I'm making experiences with cheaper socs like the tegra > > ones,jetson nano and maybe in the next future,the jetson orin. Do you > > think that if I buy the jetson orin,I could be able to help you,anyway = ? > > > > On Wed, May 17, 2023 at 2:11=E2=80=AFPM Rebecca Cran wrote: > > > > I'm getting the Ampere Developer Kit from > > https://www.ipi.wiki/products/com-hpc-ampere-altra . > > > > > > -- > > > > Rebecca Cran > > > > > > On 5/16/23 10:14, Mario Marietto wrote: > > > Hello Rebecca, > > > > > > i will be happy to help you. what system you will buy ? i want to > > > evaluate the cost. If it is affordable for me I will also buy > > the same > > > and i could test your code or something else task that you need. > > i ve > > > been always interested in the bhyve development. > > > > > > Il mar 16 mag 2023, 17:41 Rebecca Cran ha > > scritto: > > > > > > On 5/15/23 13:58, Matthew Grooms wrote: > > > > > > > On 5/15/2023 2:39 PM, John F Carr wrote: > > > >> Is there any active work on getting bhyve virtualization > > > working on > > > >> 64 bit ARM? I see some work was started a few years ago > > (e.g. > > > >> https://reviews.freebsd.org/D26976, > > > >> https://bhyvecon.org/bhyvecon2016-Mihai.pdf). It seems to > > have > > > been > > > >> abandoned or at least stalled. > > > >> > > > >> I may be able to help. It's not a project I can take on > > myself. > > > > > > > > Porting bhyve to arm has been one of the longest running UP= B > > > projects. > > > > You can find more info on the history here ... > > > > > > > > > > > > > > https://wiki.freebsd.org/DevSummit/202303?action=3DAttachFile&do=3Dview&t= arget=3DPresentation+-+bhyvecon.pdf > > < > https://wiki.freebsd.org/DevSummit/202303?action=3DAttachFile&do=3Dview&t= arget=3DPresentation+-+bhyvecon.pdf > > > > > > > < > https://wiki.freebsd.org/DevSummit/202303?action=3DAttachFile&do=3Dview&t= arget=3DPresentation+-+bhyvecon.pdf > > < > https://wiki.freebsd.org/DevSummit/202303?action=3DAttachFile&do=3Dview&t= arget=3DPresentation+-+bhyvecon.pdf > >> > > > > > > > > > > > > > > > Your best bet is probably to take a look a the following > > review > > > opened > > > > by Andrew Turner late last year. His work is based on the > > original > > > > port by the UPB team ... > > > > > > > > https://reviews.freebsd.org/D37428 > > > > > > > > I can't speak to the current state of this work. From what = I > > > recall, > > > > there were several attempts made by UPB to collaborate, > > but they > > > > failed to get a response. Perhaps he/they can chime in > > here with > > > more > > > > detail. > > > > > > I'll be getting an Ampere system in the next few weeks and > > hope to be > > > able to work on the Aarch64 bhyve code. > > > > > > > > > -- > > > > > > Rebecca Cran > > > > > > > > > > > > > > -- > > Mario. > --=20 Mario. --0000000000006781e705fbe564c5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sure. I've been (and I'm) one the most active user= s of the Jetson nano in the last years. I've enabled kvm again recently= on my Jetson nano. I don't live without virtualization. I play every d= ay with qemu,kvm,bhyve and every tool that can be used to virtualize an os.= If kvm can be enabled on the jetson nano,why should it not work on the jet= son orin ? I'm also very interested to install FreeBSD on the nano and = on the orin. Unfortunately I haven't found someone who wants to help me= . I can't handle this project alone. I'm not experienced enough.

On Wed, May 17, 2023 at 4:21=E2=80=AFPM Rebecca Cran <rebecca@bsdio.com> wrote:
Hmm, the Jetson Orin does appear to su= pport virtualization and
apparently people have had success with KVM under Linux.

I'm wondering how well-supported FreeBSD would be on it since it still =
uses FDT, and trying to boot Linux using ACPI instead didn't go well.
I have an Orin Development Kit here I could try. If FreeBSD boots on it, then I can start working on bhyve before my Ampere system gets here.


--
Rebecca Cran


On 5/17/23 05:33, Mario Marietto wrote:
> oh my god. That's such a nice toy to play with. Too much expensive= for
> my pockets. I'm making experiences with cheaper socs like the tegr= a
> ones,jetson nano and maybe in the next future,the jetson orin. Do you =
> think that if I buy the jetson orin,I could be able to help you,anyway= ?
>
> On Wed, May 17, 2023 at 2:11=E2=80=AFPM Rebecca Cran <rebecca@bsdio.com> wrote:<= br> >
>=C2=A0 =C2=A0 =C2=A0I'm getting the Ampere Developer Kit from
>=C2=A0 =C2=A0 =C2=A0https://www.ipi.wiki/produ= cts/com-hpc-ampere-altra .
>
>
>=C2=A0 =C2=A0 =C2=A0--
>
>=C2=A0 =C2=A0 =C2=A0Rebecca Cran
>
>
>=C2=A0 =C2=A0 =C2=A0On 5/16/23 10:14, Mario Marietto wrote:
>=C2=A0 =C2=A0 =C2=A0> Hello Rebecca,
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> i will be happy to help you. what system you w= ill buy ? i want to
>=C2=A0 =C2=A0 =C2=A0> evaluate the cost. If it is affordable for me = I will also buy
>=C2=A0 =C2=A0 =C2=A0the same
>=C2=A0 =C2=A0 =C2=A0> and i could test your code or something else t= ask that you need.
>=C2=A0 =C2=A0 =C2=A0i ve
>=C2=A0 =C2=A0 =C2=A0> been always interested in the bhyve developmen= t.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> Il mar 16 mag 2023, 17:41 Rebecca Cran <rebecca@bsdio.com&g= t; ha
>=C2=A0 =C2=A0 =C2=A0scritto:
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0On 5/15/23 13:58, Matthew G= rooms wrote:
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> On 5/15/2023 2:39 PM, = John F Carr wrote:
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>> Is there any activ= e work on getting bhyve virtualization
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0working on
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>> 64 bit ARM?=C2=A0 = I see some work was started a few years ago
>=C2=A0 =C2=A0 =C2=A0(e.g.
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>> https://r= eviews.freebsd.org/D26976,
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>> = https://bhyvecon.org/bhyvecon2016-Mihai.pdf). It seems to
>=C2=A0 =C2=A0 =C2=A0have
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0been
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>> abandoned or at le= ast stalled.
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>> I may be able to h= elp.=C2=A0 It's not a project I can take on
>=C2=A0 =C2=A0 =C2=A0myself.
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> Porting bhyve to arm h= as been one of the longest running UPB
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0projects.
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> You can find more info= on the history here ...
>=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=A0https://wiki.freebsd.org/DevSummit/= 202303?action=3DAttachFile&do=3Dview&target=3DPresentation+-+bhyvec= on.pdf
>=C2=A0 =C2=A0 =C2=A0<https://wiki.freebsd.org/DevSum= mit/202303?action=3DAttachFile&do=3Dview&target=3DPresentation+-+bh= yvecon.pdf>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0=C2=A0<https://wiki.freebsd.org/= DevSummit/202303?action=3DAttachFile&do=3Dview&target=3DPresentatio= n+-+bhyvecon.pdf
>=C2=A0 =C2=A0 =C2=A0<https://wiki.freebsd.org/DevSum= mit/202303?action=3DAttachFile&do=3Dview&target=3DPresentation+-+bh= yvecon.pdf>>
>=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> Your best bet is proba= bly to take a look a the following
>=C2=A0 =C2=A0 =C2=A0review
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0opened
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> by Andrew Turner late = last year. His work is based on the
>=C2=A0 =C2=A0 =C2=A0original
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> port by the UPB team .= ..
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> https://revie= ws.freebsd.org/D37428
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> I can't speak to t= he current state of this work. From what I
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0recall,
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> there were several att= empts made by UPB to collaborate,
>=C2=A0 =C2=A0 =C2=A0but they
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> failed to get a respon= se. Perhaps he/they can chime in
>=C2=A0 =C2=A0 =C2=A0here with
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0more
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> detail.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0I'll be getting an Ampe= re system in the next few weeks and
>=C2=A0 =C2=A0 =C2=A0hope to be
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0able to work on the Aarch64= bhyve code.
>=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=A0Rebecca Cran
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>
>
>
>
> --
> Mario.


--
Mario.
--0000000000006781e705fbe564c5-- From nobody Wed May 17 16:00:35 2023 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 4QLyW05TgTz4BJ5G for ; Wed, 17 May 2023 16:00:28 +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 4QLyVz3rQdz3sv1 for ; Wed, 17 May 2023 16:00:27 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Authentication-Results: mx1.freebsd.org; dkim=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; dmarc=none Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.17.1/8.15.2) with ESMTPS id 34HG0anO084618 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 17 May 2023 09:00:36 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.17.1/8.15.2/Submit) id 34HG0ax5084617; Wed, 17 May 2023 09:00:36 -0700 (PDT) (envelope-from fbsd) Date: Wed, 17 May 2023 09:00:35 -0700 From: bob prohaska To: Mark Millard Cc: freebsd-arm@freebsd.org Subject: Re: Armv7 (rpi2) getting stuck in buildworld for -current Message-ID: References: <7758885B-3115-47F0-A453-1C010313D4B8@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-Result: default: False [-0.81 / 15.00]; AUTH_NA(1.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.994]; NEURAL_HAM_SHORT(-0.96)[-0.957]; NEURAL_HAM_LONG(-0.76)[-0.761]; MID_RHS_WWW(0.50)[]; WWW_DOT_DOMAIN(0.50)[]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; R_DKIM_NA(0.00)[]; FREEMAIL_TO(0.00)[yahoo.com]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; BLOCKLISTDE_FAIL(0.00)[50.1.20.27:server fail]; TO_DN_SOME(0.00)[]; R_SPF_NA(0.00)[no SPF record]; DMARC_NA(0.00)[zefox.net]; RCVD_TLS_LAST(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Queue-Id: 4QLyVz3rQdz3sv1 X-Spamd-Bar: / X-ThisMailContainsUnwantedMimeParts: N On Sun, May 14, 2023 at 08:12:23PM -0700, Mark Millard wrote: > > I'm unsure if you have well avoided having any tmpfs based > space or the like that would compete for RAM and use some > of the RAM+SWAP. In the low RAM environments, I avoid such > competition and use UFS to exclusion. > No use of tmpfs, the line in /etc/fstab is commented out I've commented out the changes to /boot/loader.conf related to virtual memory as well. All were introduced in response to slow flash storage, it looks like they're not needed with mechanical disks and at least sometimes counterproductive. Since these changes there have been no communications losses. > I'll note that causing swap space thrashing can make builds > take longer. "Thrashing" is not directly the space used but > the frequency/backlog of swap space I/O. I always avoided > configurations that thrashed for notable periods of time, > via using -j given that I'd already avoied RAM+SWAP > competition. But thrashing is also tied to the likes of > spinning rust vs. various, for example, NVMe USB media. It > is probably generally easier to make spinning rust thrash > for notable periods. I'd also avoided spinning rust. I can't help but wonder if the dominant I/O bottleneck on a Pi2 or Pi3 isn't the usb subsystem. With none-too-fast 5400 rpm mechanical disks there are no console warnings about swap, despite obvious memory pressure (high swap use, high idle percentage). Most of the time one thread is eventually given elevated priority and the overload is worked through. This morning a Pi3 was found seemingly jammed. All four threads were about 500MB in size, all had priority 20 with about 1% WCPU. No console messages warned of swap pressure, but the system was stalled. Occasionally one thread would get priority 21, but quickly reverted to 20 so the jam didn't clear. After poking around interactively reading man pages one thread got priority 135 and progress resumed. For the moment it appears that, at least when using mechanical disks, no adjustments to the VM configuration are needed on either Pi2 or Pi3. Random user interaction via keyboard seems helful to break priority ties when swap use becomes intense. Might it be possible for a script to detect thrashing and stimulate similar behavior? Thanks for reading! bob prohaska From nobody Wed May 17 17:04:16 2023 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 4QLzx018TPz4BMsg for ; Wed, 17 May 2023 17:04:36 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic304-24.consmr.mail.gq1.yahoo.com (sonic304-24.consmr.mail.gq1.yahoo.com [98.137.68.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 4QLzwz5xbyz44Cs for ; Wed, 17 May 2023 17:04: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=1684343073; bh=F1y0vyDXl47fqjOu8YqIASgHjNw1/2l5GHBCp7B9nwQ=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=I11R+5vQNzIdYujc0ElMBQehLFrkQaSDicL6ZIHXbmc9Uq6DwaJNgAD6iddP8srJDmsZR1KjU9zODPHiKlblKC+nl0+3sgosCiem+e8OmYYtitP7ODMBPRQSb9VrNBsbpf9zdH+iUj4CboVmiZiL1n+2IjDpoBoesJGH5HPWWI9aCeSbA5rsx4Ra5FWyMuK13Ngyc27gPPo84FQ3lAgPp84Pzmk8lSPDicwmXMSDRvADsPhmhCKplbqtn17jkklbqU5TeunARvhnlxQwW5LUYoynojtVEMGnCd4e4HHuXm8Oz16rmOuTPTGWT6iYOp5laqKyfsCwouphZ++siLJJ/w== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1684343073; bh=hPlKGw0kocdgRX7BilcohBYlM6z6PJJpiNqczcSHz3A=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=THMBcwyzIKHXwoz5qlulw0Vu+rM4GHFYdeYkanZVl8mraJYoKxQM180n6UhkPnevk3VPqEAFSE/Cl91mxO7s9pfJfqg3zH0wRhLGTci9KbdMG9zqZuncRFh66lNisirU6j7Rl0gfBHj4sHIVKKvmB105vA0FEnMl6irrlgL2wmAdZ7CWD9FL79M6Fp68EPajgZjROCjA7QOkijCHOHkfFcDG7IPnxfneZHFPzpkWEH8BYtIJcmFaLhOkg95JIhsk/EZ3ptWeWOj5paFOwk2vTw4/DTLwsGDNUPG4B7rNH3cvmiQlRgN4uhhNKTSIuRK+3O2rh4nnJL9nES+HGW6MwQ== X-YMail-OSG: oDYVv74VM1mf_OkgguCzuYuaa7ot8C1V.cBij6OZc93vP9yNY8yLx0zC2QQuSLS _CIZ20VtVg1ZqMdxn7ZO7MNV9Vn7ss1hMNXQLYfU6pltBy3zYhI_nkG.FXhj84_9iqSryNhc8DbW CrhBcnL7rpFlzlF9TyX8M_BA0obrSUROO42hjQnvFuEZXwK6pFJyiWK21_.8pi7YMCXajzr.APWy hwa.U3h_uheSKe0fRwkqGH1IMra6sR3PV2TahDKK_21Mwtug66d8TBt_jsK0tTCvb7W_S8fA5nr8 DMBikKHubt8pI2qHlkQ4DFNv5cN6t4rtYKzG.GkzWE4XIpK4nnzvRgeV_2DPb2u8gRc0fYxTmWyF MCv8UE7DuATnI9YdUBQ_.btMBzsgu_5xqIsysMwhJ0cFNKfMxGR_bivrLUZ11gAAZR9iZ5md8_CS 1HGnmyVNEAGLtLEFCb1H2_0.6.4w769DZSgSpRd4F.ZFyrYNs.7QWZnF3VXgehhbfWtJOIeS8Ihp JTiYRQmZldU3SuWu3Mcxb3penXglPiNDUjzBkoEUT.pim24WIvgM6BDHXR.uZnHXKiRMkwV_Mgw0 q90YC24Iula0VTR3URK67aYeIzXyJHwZCObfoWoIU5k8.kWj0cjARoWYAPtPRjjQc3WSu2aeBHBS shOqs_r1Ff2x00BXFnwdgeN4H3vdRRa1EfCHXFIAiEDtuBlOSzOZ0CRafmPL_EKHro0quu49it6h RenEFBRTH6g3t0kspQgJcNG8oMeLPVR4a4S6VA3EovI7MA8ROZQc9irY_mqRWj3paBVnlO_m6roy g1mCX7ks_LqpPLWy1uvFCIR3lBPYBBbcI0zYceZr1BDchxed3BqVhVcWVrNUX5TT8gufuAlmw_w9 1bbx9iDsuPgJKZhoCq77ySIsyLbP7iTvbOT2Nx_5FAdoi_AwCaZtkjRUHyoVIZkiPF5SbyXVJd8t yHnAE7CahisHgq.B2rOqSHMifwrDi4q7lw3Ka_ftyx_R4RGEWLLJgkkRfQaoMJdzxnUsIIecZgQX 8jNxfZyaGmijtrnFeiMhTqjtMBRyD9xO3jnagaUZC2jS_5rgDcAJjuC2JP2E1r_RRXqQeMpjucBH Ok7D4ygtnVJbaiKpi5NJY_rvZUMZ51dRV9bMbkq_KNLhjQlsSj0nJ.pdI.wk8D80jU.MnfeqvmoD ICLRYJBJbtZkW0bF9IqTooWFnXNpVFXuiBJJf0LTZf9KyBngjNLPYI_UZ_3O2okJNhncaihcsBwe 7DlprLc.Bo5RmP_0HlOuIJ187FNCAG3Norf8bQVoslsLlPU3h8DTKZHLPW3FVYOOTgRuYuycbRCf mqyOxkSLA0tmmYwL4nsUyDQ6TqRIBPKJEJtNnj7uzGvn_IhaQ5q6Gdu.Dxjlk8CHbHtxwhHBZEjV bgJ21FujPDKb20WKyP0zspMyG7jHLd.mJoO3VoLEuUg4fPqG6jaWwPTfG4G7RnlXHhV1c8ss81F6 L.unbn3gEspi0Btmk2qZcHp98a3tbN_oZSkQUsAtctPuu28Cm4kMfCcMFR16.yvc8cx4rwJDf057 Tau5byJKflBb7reUNLGiaXHHiitPoqY.UvkqPvryp3OU.32S6SZVSDbcU8jn0LeTVeOuVdmbauAw In39zFexYHUHdqNbOSH4YDbz6aqAYzS4EFDqxTBGq2SaE93iBI1tMaU6hw21u5Ey6phgDvEBBFYD BilIzgPJW9sx0BmFCvK4ObZVO.CCVKLc7kYcjZiWpQLBXyGTZNtpVLoKJi9bEt66K32jpuWmztzS ZUvsGR5fRDKJjOlKW3UXpxFxk6xHBHviiiSDvpPFJM2fTs0Pb3CPgWcvm7pgRDnGFRZDE6MchYfh JDA5StObYgiQhZ3d8rD.QBD_73baZOhKigomyVIAMXNvH_UtbcwJSAEDPAODbLOT4CaSu9gSiqRE c3jxrUFaBXWn0J.UNSTFUMNNPl0c1rtc_chOsKYDD4.YucYvyJ2TlaKQKYo4ntDAgEjyRbQLR3Y8 zOpYIV2IXF97EAwr6WB1Sde5z7oHq4Z.dPaXucMsV3N6YycflMWJaF503W76b_0yTzhshLLtMlP1 xqrELmQNaTB5UZrBam9Cr2t61u5LGFBFsiWl2nYfLo0lyi6KSDcdt7rejxBoM4_aXqgEy3iODsy9 0P6_WEXOnLEqAbDMlHEvTtneFLk.IV6tVTGLEixAFP.j17Ef5WAxLcHDcNxT6wWhcnuRPt_rtRcI 0sf0wnxPANgVz9bTn082yc_.snissTCPvfCa64qKX50pI6JJodVESHtvSwoqkuohq6G6TmQmiVhh w X-Sonic-MF: X-Sonic-ID: 66ecbc69-6598-4e2e-919d-d66d563e4dd4 Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Wed, 17 May 2023 17:04:33 +0000 Received: by hermes--production-ne1-574d4b7954-6wwdb (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 4f0f2da37bb73d54220110d5d781a2c9; Wed, 17 May 2023 17:04:28 +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 \(3731.400.51.1.1\)) Subject: Re: Armv7 (rpi2) getting stuck in buildworld for -current From: Mark Millard In-Reply-To: Date: Wed, 17 May 2023 10:04:16 -0700 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: 7bit Message-Id: <03F330A1-35E4-40D4-B9C6-407041BBEC58@yahoo.com> References: <7758885B-3115-47F0-A453-1C010313D4B8@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3731.400.51.1.1) X-Rspamd-Queue-Id: 4QLzwz5xbyz44Cs X-Spamd-Bar: ---- 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] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On May 17, 2023, at 09:00, bob prohaska wrote: > On Sun, May 14, 2023 at 08:12:23PM -0700, Mark Millard wrote: >> >> I'm unsure if you have well avoided having any tmpfs based >> space or the like that would compete for RAM and use some >> of the RAM+SWAP. In the low RAM environments, I avoid such >> competition and use UFS to exclusion. >> > > No use of tmpfs, the line in /etc/fstab is commented out > I've commented out the changes to /boot/loader.conf related > to virtual memory as well. You mean all the names that start with "vm." that are assigned in loader.conf ? : #vm.pageout_oom_seq="4096" #vm.pfault_oom_attempts="120" #vm.pfault_oom_wait="20" I'd recommend at least: vm.pageout_oom_seq=120 just to make sure that kills are less likely than with the default value (12). The assignment only contributes to the choice of when to do kills, no other aspect of of the virtual/RAM memory handling. You might also consider: vm.pfault_oom_attempts=-1 I'll note that vm.pageout_oom_seq is both a tunable and writable. So, if you have assignments in multiple places, the most recent to execute is active. The same applies to vm.pfault_oom_wait and vm.pfault_oom_attempts . You do not mention /etc/sysctl.conf and its: vm.swap_enabled=0 vm.swap_idle_enabled=0 I'd keep those as well. > All were introduced in response > to slow flash storage, it looks like they're not needed with > mechanical disks and at least sometimes counterproductive. > Since these changes there have been no communications losses. Intersting. As far as I can tell the only two that might have contributed to that are/were: vm.pfault_oom_attempts="120" vm.pfault_oom_wait="20" >> I'll note that causing swap space thrashing can make builds >> take longer. "Thrashing" is not directly the space used but >> the frequency/backlog of swap space I/O. I always avoided >> configurations that thrashed for notable periods of time, >> via using -j given that I'd already avoied RAM+SWAP >> competition. But thrashing is also tied to the likes of >> spinning rust vs. various, for example, NVMe USB media. It >> is probably generally easier to make spinning rust thrash >> for notable periods. I'd also avoided spinning rust. > > I can't help but wonder if the dominant I/O bottleneck > on a Pi2 or Pi3 isn't the usb subsystem. There is not just one bottleneck. Spinning rust introduces latency on a scale large compared to USB2-bus latency contributions. For example, seek time for spinning rust. (More about this later.) The USB2 on the RPi[23]'s may well keep your spinning rust below its maximum bandwidth. But that is a separate type of bottleneck. > With none-too-fast > 5400 rpm mechanical disks there are no console warnings about > swap, despite obvious memory pressure (high swap use, high > idle percentage). Most of the time one thread is eventually > given elevated priority and the overload is worked through. > > This morning a Pi3 was found seemingly jammed. All four threads > were about 500MB in size, all had priority 20 with about 1% WCPU. > No console messages warned of swap pressure, but the system was stalled. > Occasionally one thread would get priority 21, but quickly reverted > to 20 so the jam didn't clear. After poking around interactively > reading man pages one thread got priority 135 and progress resumed. Just sounds to me like it was I/O bound thrashing, something that could make builds take longer than using a smaller -jN would do, depending on the details. Paging tends to be small transfers with random positioning, leading to lots of seek time for spinning rust. When thrashing the system can spend notably more elapsed time seeking than transferring data. A single paging transfer need not give enough context for a core to spend any notable time computing: it likely has to wait for more transfers to establish a big enough working set. Multiple thrashers tend to block each other from reaching the desired status. > For the moment it appears that, at least when using mechanical > disks, no adjustments to the VM configuration are needed on > either Pi2 or Pi3. Random user interaction via keyboard seems > helful to break priority ties when swap use becomes intense. I'd call the evidence for the "random user interaction via keyboard" inference weak. It is a kind of context in which it is difficult to have good evidence about what would have been different without the manual activity. I expect that if you had waited, the result would have been similar. But the evidence for that is weak as well. > Might it be possible for a script to detect thrashing and stimulate > similar behavior? I doubt that the utility vs. just using a smaller -jN for the build, leading to less time spent thrashing the spinning rust. === Mark Millard marklmi at yahoo.com From nobody Wed May 17 20:35:06 2023 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 4QM4bx4GbQz4BYbn for ; Wed, 17 May 2023 20:35:09 +0000 (UTC) (envelope-from bacon4000@gmail.com) Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (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 4QM4bw6Svxz4Nvk for ; Wed, 17 May 2023 20:35:08 +0000 (UTC) (envelope-from bacon4000@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20221208 header.b=KvLnQv2i; spf=pass (mx1.freebsd.org: domain of bacon4000@gmail.com designates 2607:f8b0:4864:20::733 as permitted sender) smtp.mailfrom=bacon4000@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-qk1-x733.google.com with SMTP id af79cd13be357-75764d20db3so119782585a.2 for ; Wed, 17 May 2023 13:35:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1684355707; x=1686947707; h=content-transfer-encoding:subject:from:to:content-language :user-agent:mime-version:date:message-id:from:to:cc:subject:date :message-id:reply-to; bh=X6RNtdCGnqcE39ekxE+vsjbjULzZy0br/o8V1v9greo=; b=KvLnQv2iABoEti/gBST5eKvrI+8ogcXJJRxidFKvh/zkbExpgMv7jlVOtRfdaXGifH 4Jm7bPJmbFSoHH566FbVa8hoxycC7bDiCol5Yr+KSUWDKwMZaO1EpxFSMzTdyYJc0P0Z d9sX7T8PHWK+jcNBp/gEfNaPCOl+mHqdoy2Q7M7G4r2P/Ukh59UkybjIYvZ5Mvak1AvX WSGYpJgeQU2uq+xyISC2qwR07xYNOyxZ6WKjo5j9iKyFtHTG6tazNqI8UOs9msU13GGw wcJ6AZY77FAhPIdQaviWJTPtUK0KdrC7Ygb3KxOhDl212iL/wDtanVs4lzFjwcgSjJmy 523g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684355707; x=1686947707; h=content-transfer-encoding:subject:from:to:content-language :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=X6RNtdCGnqcE39ekxE+vsjbjULzZy0br/o8V1v9greo=; b=Tp76rSVFXmqsA4xYyn7Ay9Nmh2DCFHZD47XAThzDCAY+Z/5nmBX79zez4jyhOuzw1Q l5Bw82NLv6ssOTRcF6wAFG8j+xMdcS6g1v1OxnRp6X414Sk1E+x4thhC5W2ov1NjqDri P+M8k2B5YLo1d3zWPsHG/0klBHeLDdGMt5Ao86onXSz+ZLM6LcMChUwcJ1ptmKXDZ0pz H5mhqIXKgk7jTp7grOZz9WCcxscOmjSZTQx5NmLlniE9NQZfpJ6yjpB79JR9ZPNZR+WN OBlWvs4BueLmmG1tFLy1ezntWC5zkecr8OsKkRsJHJZtefhi1Y86GbyK1VCDqF05mkxi 0h5g== X-Gm-Message-State: AC+VfDzPRx744n4Y6IESYQTo7nui0VbDiCAyYjCmo2kWUlQOn4pFk662 jWhw8XPSHqf3wrIPR02YsHPEWKPeWv8= X-Google-Smtp-Source: ACHHUZ7bHb4AfYa8nkXpS/9/fC/DGI7v14Iwfku0hBo81546q5hX//dPO5pVZwIbvxNkHz4ipJWO7w== X-Received: by 2002:a05:6214:dce:b0:621:45b2:3368 with SMTP id 14-20020a0562140dce00b0062145b23368mr1836146qvt.40.1684355707640; Wed, 17 May 2023 13:35:07 -0700 (PDT) Received: from [192.168.0.59] (cpe-184-58-230-200.wi.res.rr.com. [184.58.230.200]) by smtp.gmail.com with ESMTPSA id y11-20020a0ceacb000000b0060f5a75b750sm6607242qvp.99.2023.05.17.13.35.06 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 17 May 2023 13:35:07 -0700 (PDT) Message-ID: Date: Wed, 17 May 2023 15:35:06 -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/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Content-Language: en-US To: freebsd-arm@freebsd.org From: Jason Bacon Subject: VirtualBox Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Result: default: False [-3.92 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.92)[-0.923]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20221208]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; ARC_NA(0.00)[]; BLOCKLISTDE_FAIL(0.00)[2607:f8b0:4864:20::733:server fail,184.58.230.200:server fail]; RCPT_COUNT_ONE(0.00)[1]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_NONE(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::733:from]; DKIM_TRACE(0.00)[gmail.com:+]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org] X-Rspamd-Queue-Id: 4QM4bw6Svxz4Nvk X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N Is anyone working on running under VirtualBox on Apple silicon? I just got a Mac Mini M1 and would be interested in contributing if possible. Not something I could take the lead on, though. Best, Jason -- Life is a game. Play hard. Play fair. Have fun. From nobody Wed May 17 23:03:23 2023 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 4QM7v91Wz3z4Bhpd for ; Wed, 17 May 2023 23:03:33 +0000 (UTC) (envelope-from samm@freebsd.org) Received: from reindeer.net-art.cz (reindeer.net-art.cz [IPv6:2001:15e8:110:513c::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "reindeer.net-art.cz", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QM7v85djMz3NSw for ; Wed, 17 May 2023 23:03:32 +0000 (UTC) (envelope-from samm@freebsd.org) Authentication-Results: mx1.freebsd.org; none Received: by reindeer.net-art.cz (Postfix, from userid 65534) id D0BF15F432; Thu, 18 May 2023 00:03:22 +0100 (BST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on reindeer X-Spam-Level: X-Spam-Status: No, score=-6.2 required=10.0 tests=BAYES_00,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_SOFTFAIL,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.2 Received: from owl.net-art.cz (unknown [IPv6:2a03:6920:0:10::101]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "owl.net-art.cz", Issuer "R3" (not verified)) by reindeer.net-art.cz (Postfix) with ESMTPS id 5BB855F188; Thu, 18 May 2023 00:03:22 +0100 (BST) Received: from [::1] (account samm@net-art.cz HELO webmail.net-art.cz) by owl.net-art.cz (CommuniGate Pro SMTP 6.1.20) with ESMTPA id 1809256; Thu, 18 May 2023 01:03:23 +0200 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Date: Thu, 18 May 2023 01:03:23 +0200 From: Alex Samorukov To: Jason Bacon Cc: freebsd-arm@freebsd.org Subject: Re: VirtualBox In-Reply-To: References: Message-ID: X-Sender: samm@freebsd.org Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4QM7v85djMz3NSw X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:24806, ipnet:2001:15e8::/32, country:CZ] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N VirtualBox is x86 emu. FreeBSD itself works very good in qemu for macos, including GUI frontend UTM. On 2023/05/17 22:35, Jason Bacon wrote: > Is anyone working on running under VirtualBox on Apple silicon? > > I just got a Mac Mini M1 and would be interested in contributing if > possible. Not something I could take the lead on, though. From nobody Thu May 18 08:29:11 2023 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 4QMNS42D12z3bN2Q for ; Thu, 18 May 2023 08:29:24 +0000 (UTC) (envelope-from eduardo@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 4QMNS41mymz3Nxh for ; Thu, 18 May 2023 08:29:24 +0000 (UTC) (envelope-from eduardo@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1684398564; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=NHvzPX/1kop++Gu1PJfRekg2jeLuX7x9hVQqnwtn+1A=; b=CwNfVacldWonYXP0Uynkq8amoXcPgT1DBME+c7PBQE3yDjleJQS9/dcHgVumcP7p8ydGG2 qgXg+S2HIAV8kbIBDvNHX1zHICvy3o752d/iTjXRFO9IFAxzTIFCF3GnQKjXMqkAdteAKB 7bqgCBw9O5YxflzL6clZmUS1X06PZ6kuAVQTiWasX6Srtc63Q8Ut3NYNvVCeLE/DVeiPNw POicn15gfd44vL5dADphxNji6tPhAC7zd9z9bkDYsQ2/VMpCC62MJeXXozJDrv2xd9RPal PNsGh9u+VPopnJ9ACNl+pwVEFeR+FNaU+YPLfvbS+ZP+JG2HMuleLiM7XiF16w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1684398564; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=NHvzPX/1kop++Gu1PJfRekg2jeLuX7x9hVQqnwtn+1A=; b=LJsCzVFfG3MEKfn3/kWYz5qAXjaFD+G/3uMyMZ9+zkHUSqb+SiHIBcgYOh/2ZceeiV3xbG MHwrOY0GoddXhOe5UTQFCejRZBKpuUPjjUmGODtbzrSgrqMZaQ13DJeGf2WhbEAvNrfxhd qQ3dUKY7HjprTKITiZqFVtDO6iSFRPujXHT3hd2OnJZxgm9WzjWGmVaSwvosnAFtkpblbQ AsI/gAuHvk94hmeBJE3DfqzNdoC1G0tE16tSmdr7tJKBJdUj6hg+dsMmyJzxv6HmrnuMc9 8tyRhwhf8qEkw+BpSea7a7kAtlkwLsz/i8g3VHV9rU1dTBS+u5S+oVTrhrcZvw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1684398564; a=rsa-sha256; cv=none; b=Nx3j7w5v09m3eBOYPD2Ebvk97Uwr6n+0mngdLOz9rPy3C3oGdKD7FJbhhYkGBsL37rsCH8 pIdw1OjfZugx6ANgsSUvdrDRwLPnVKes+kZcOvwQFo8FFm/VLZ+IBVtXisjG8BAbVkUmbK cBvWqRMlmbv7juEh6z8hn0UVbW7dncYwusg0SDWTIDJ52f6JBiHoQZKi4TDutptN7vsrll SydrrWfPLfi4sponVjM2s48YS801NG4RtPwhn/AOzzZefwZAHv2gi4bSaRt19mKGOHUp8V N4C0IU+qm0n3v+gWfh2X43ptOKMpiu7kBXXGyXGA/RXCw+7bkfMIfxatKC8ESA== Received: from mail-pj1-f43.google.com (mail-pj1-f43.google.com [209.85.216.43]) (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)) (Authenticated sender: eduardo) by smtp.freebsd.org (Postfix) with ESMTPSA id 4QMNS40cfQzK5P for ; Thu, 18 May 2023 08:29:24 +0000 (UTC) (envelope-from eduardo@freebsd.org) Received: by mail-pj1-f43.google.com with SMTP id 98e67ed59e1d1-24e16918323so1335295a91.2 for ; Thu, 18 May 2023 01:29:24 -0700 (PDT) X-Gm-Message-State: AC+VfDwegZC9N9ooS3EeGj8P7xXEFiymaEzyaIgGuqbay/yPe1Ctjj4c vm+F1AGkyQTEyxuxpIccZ+Bif0We660blnlPB6c= X-Google-Smtp-Source: ACHHUZ4KVaw0OjgVRp1iOzXAPI4JOyUNQbr1GZbjwcyDjgeMj9U0tZhmf3wg7hZ6yfak4gEHNbDKuAsbkER/liTO8P4= X-Received: by 2002:a17:90a:9318:b0:253:61f3:d675 with SMTP id p24-20020a17090a931800b0025361f3d675mr1187531pjo.30.1684398563048; Thu, 18 May 2023 01:29:23 -0700 (PDT) List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 References: <77CD0716-3BC8-47EB-8743-F2BD9CA43D31@yahoo.com> <432A1A16-9FE5-4339-AB38-8F3E03A5D4EF@yahoo.com> In-Reply-To: From: Nuno Teixeira Date: Thu, 18 May 2023 09:29:11 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Raspberry Pi POE+ hat overlay To: Doug Rabson Cc: freebsd-arm@freebsd.org Content-Type: multipart/alternative; boundary="00000000000002c58905fbf39a76" X-ThisMailContainsUnwantedMimeParts: N --00000000000002c58905fbf39a76 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Confirmed that arm_boost is enable by default on rpi4 rev >=3D 1.4 as I checked with htop. Also, tested arm_freq=3D1800 and it crashes FreeBSD around initializing console/video and detecting mouse. As linux config.txt says: --- [pi4] # Run as fast as firmware / board allows arm_boost=3D1 --- firmware must be updated to support this feature for sure. Cheers, Nuno Teixeira escreveu no dia quarta, 17/05/2023 =C3= =A0(s) 14:08: > (...) > > I was meant using 13.2 not 12.3 :) > > Doug Rabson escreveu no dia quarta, 17/05/2023 =C3=A0(s) > 13:47: > >> I'm not sure about 12.3 either - you could try with 13.2 and see if that >> makes a difference. >> >> On Wed, 17 May 2023 at 13:45, Nuno Teixeira wrote: >> >>> Hey, >>> >>> Ok. I'm new to rpi4 and arm in general but tomorrow I will force >>> 'arm_freq=3D1800' again just to see it it crashes again. >>> I will check too what values linux shows. >>> >>> I don't know if firmware/uboot version included in 12.3 supports this >>> feature. >>> >>> Cheers, >>> >>> Doug Rabson escreveu no dia quarta, 17/05/2023 =C3=A0(= s) >>> 13:11: >>> >>>> Hi Nuno, >>>> >>>> I'm not sure where to start - I just happened to notice in the >>>> documentation here: >>>> https://www.raspberrypi.com/documentation/computers/config_txt.html >>>> that the cpu frequency Pi4B R1.4 was listed as 1800 if arm_boot=3D1 so= I >>>> tried it. >>>> >>>> Doug. >>>> >>>> >>>> >>>> On Wed, 17 May 2023 at 11:11, Nuno Teixeira >>>> wrote: >>>> >>>>> Hello Doug, >>>>> >>>>> I have too a 1.5 rpi but arm_boost=3D1 isn't doing anything, htop sho= ws >>>>> 1500Mhz when doing something intensive. >>>>> I'm running 13.2 stable >>>>> >>>>> Do I missing something? >>>>> >>>>> Could you take a look at my setup? >>>>> >>>>> Thanks, >>>>> >>>>> Doug Rabson escreveu no dia ter=C3=A7a, 16/05/2023 = =C3=A0(s) >>>>> 17:19: >>>>> >>>>>> >>>>>> On Sat, 13 May 2023 at 13:45, Doug Rabson wrote: >>>>>> >>>>>>> I was able to build an updated rpi-firmware port based on 1.2021080= 5 >>>>>>> and this boots successfully on pi400 as well as rpi4. With this, I = can load >>>>>>> the rpi-poe-plus overlay and I just need to try and reverse enginee= r the >>>>>>> undocumented mailbox API by reading the Linux code. >>>>>>> >>>>>> >>>>>> I have a first approximation of a fan driver which works with the >>>>>> 1.20210805 firmware (actually, I substituted rpi-poe-plus.dtbo from >>>>>> 1.20210831 which just changes the fan levels for the POE+). I'm test= ing >>>>>> with an rpi4B rev 1.5 with 'make -j4 buildworld' and the fan is keep= ing the >>>>>> cpu temperature below 65 degrees which is nice, especially since I s= et >>>>>> arm_boost=3D1 in config.txt which boosts the cpu frequency up to 180= 0 for >>>>>> this board. >>>>>> >>>>>> Does anyone have a pointer to the problem with firmware later than >>>>>> 20210805? Would it make any kind of sense to try to get the fix into >>>>>> releng/13.2 as an errata? >>>>>> >>>>>> >>>>> >>>>> -- >>>>> Nuno Teixeira >>>>> FreeBSD Committer (ports) >>>>> >>>> >>> >>> -- >>> Nuno Teixeira >>> FreeBSD Committer (ports) >>> >> > > -- > Nuno Teixeira > FreeBSD Committer (ports) > --=20 Nuno Teixeira FreeBSD Committer (ports) --00000000000002c58905fbf39a76 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Confirmed that arm_boost is enable by default on rpi4= rev >=3D 1.4 as I checked with htop.

Also, tes= ted arm_freq=3D1800 and it crashes FreeBSD around initializing console/vide= o and detecting mouse.

As linux config.txt says:
---
[pi4]
# Run as fast as firmware / board allow= s
arm_boost=3D1
---
firmware must be updated to supp= ort this feature for sure.

Cheers,
=
Nuno T= eixeira <eduardo@freebsd.org&= gt; escreveu no dia quarta, 17/05/2023 =C3=A0(s) 14:08:
(...)

I was meant using 13.2 not 12.3 :)

Doug Rabson &= lt;dfr@rabson.org&g= t; escreveu no dia quarta, 17/05/2023 =C3=A0(s) 13:47:
I'm not sure ab= out 12.3 either - you could try with 13.2 and see if that makes a differenc= e.

On Wed, 17 May 2023 at 13:45, Nuno Teixeira <eduardo@freebsd.org> wrote:
He= y,

Ok. I'm new to rpi4 and arm in general but = tomorrow I will force 'arm_freq=3D1800' again just to see it it cra= shes again.
I will check too what values linux shows.
<= br>
I don't know if firmware/uboot version included in 12.3 s= upports this feature.

Cheers,

<= div class=3D"gmail_quote">
Doug Rabson= <dfr@rabson.org= > escreveu no dia quarta, 17/05/2023 =C3=A0(s) 13:11:
Hi Nuno,

=
I'm not sure where to start - I just happened to notice in t= he documentation here:=C2=A0https://www.raspberrypi.= com/documentation/computers/config_txt.html that the cpu frequency Pi4B= R1.4 was listed as 1800 if arm_boot=3D1 so I tried it.

Doug.



On Wed, 17 May 2023 at 11:11= , Nuno Teixeira <eduardo@freebsd.org> wrote:
Hello Doug,

=
I have too a 1.5 rpi but arm_boost=3D1 isn't doing anything, htop = shows 1500Mhz when doing something intensive.
I'm running 13.= 2 stable

Do I missing something?

Could you take a look at my setup?

Thanks,=

Doug Rabson <dfr@rabson.org> escreveu no dia ter=C3=A7a, 16/05/2023 =C3=A0(s) = 17:19:

On Sat, 13 May 2023 at 13:45, Doug Rabson <dfr@rabson.org> wro= te:
I was able to build an updated rpi-firmware port based on 1.20210805 a= nd this boots successfully on pi400 as well as rpi4. With this, I can load = the rpi-poe-plus overlay and I just need to try and reverse engineer the un= documented mailbox API by reading the Linux code.
I have a first approximation of a fan driver which works with = the 1.20210805 firmware (actually, I substituted rpi-poe-plus.dtbo from 1.2= 0210831 which just changes the fan levels for the POE+). I'm testing wi= th an rpi4B rev 1.5 with 'make -j4 buildworld' and the fan is keepi= ng the cpu temperature below 65 degrees which is nice, especially since I s= et arm_boost=3D1 in config.txt which boosts the cpu frequency up to 1800 fo= r this board.

Does anyone have a pointer to the pr= oblem with firmware later than 20210805? Would it make any kind of sense to= try to get the fix into releng/13.2 as an errata?



--
Nuno TeixeiraFreeBSD Committer (ports)


--
Nuno TeixeiraFreeBSD Committer (ports)


--
Nuno TeixeiraFreeBSD Committer (ports)


--
Nuno Teixeira
FreeBSD Committ= er (ports)
--00000000000002c58905fbf39a76-- From nobody Thu May 18 08:29:36 2023 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 4QMNSJ42h3z3bNP3 for ; Thu, 18 May 2023 08:29:36 +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 4QMNSJ1L4wz3PJc for ; Thu, 18 May 2023 08:29:36 +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=1684398576; 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=votraQ1LXGCe60KFbUxu7askaP6veM3Ugm/5lbQGikY=; b=bFzq359AS9nHHRqNLxm795TDVt/LjVThtG+YfoVAvFuNBWo2nYRyiORHjr7e91MAw8x4Kk eA8/URNrZMo27M3pKta4lsGxn/UlIh4ioLmjcahser4d8+fREJZqiEP3Ax+SEzXsxOtzQH q5bo6xSU+s0IjaWlfoSUER7wrRUmvbw4rYr+vSzpGOU7EHNPGx7OFEnWZJ8EpGZc9z7ueE YjlLZ38ZotvLPjAHoUmmq4Ee/9xPwCa9mbnRLebg+L6nTuOCiLySCR52cvpS8S3smqbyFi vu3yq6EIZXPifpWlcMJuEjRD5GAXx9ODU2RtP0/2W/LoPJ+yRcQYiJSnbtH+WA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1684398576; a=rsa-sha256; cv=none; b=rsnQJ/qftDPmc3jMiSsyMk3E6ptQi9JzKPxfDBzsxaTEx4YyeRvO7xlVH4RnXU9UHZHPWd ISLdfcN+IRy31uIShWoCDj+93GN2aKFGuJJ2N0fOZhfGd07vUiQc5tdzf0ueauwKCBjfe3 PIMsFVNDmD+u/Xhse03EQGUYlJ+Z9LGx8A/YTE8leAxVXTvxANlg2YMPe5/VLcAmM4NcXs hOZtbGJhJRpZLJ3Y2sQOEW8NPRcd9yDBmJFJ7FBYZI/J3N4s3xizHNTdClQ1xlfovUZ+j5 LmmvZnKi/D0TX/paCjrxtEX5KHmTt91z+mcU/EuCHcwbxga2sdk8HNoFpVRLuQ== 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 4QMNSJ0QC1zfDW for ; Thu, 18 May 2023 08:29:36 +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 34I8Ta3w053462 for ; Thu, 18 May 2023 08:29:36 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 34I8TanN053461 for freebsd-arm@FreeBSD.org; Thu, 18 May 2023 08:29:36 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 271482] Raspberry Compute Module 4 IO does not boot Date: Thu, 18 May 2023 08:29:36 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 13.2-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: berkovski@dilyan.be 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 attachments.created Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D271482 Bug ID: 271482 Summary: Raspberry Compute Module 4 IO does not boot Product: Base System Version: 13.2-RELEASE Hardware: arm64 OS: Any Status: New Severity: Affects Only Me Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: berkovski@dilyan.be Created attachment 242245 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D242245&action= =3Dedit FreeBSD dmesg for Compute Module 4 IO board RPI 4 Compute Module 4 (https://www.raspberrypi.com/products/compute-module-4/?variant=3Draspberry= -pi-cm4001000) and its IO official board (https://www.raspberrypi.com/products/compute-module-4-io-board/) are unabl= e to boot 13.2, 13.1 and 14.0-current. 13.1 and 13.2 keep rebooting constantly, 14.0 does not even start booting. Tested with serial console and monitor. appears that the devmatch issue is not solved for this platform, and the on= ly way to make the system boot is adding devmatch_enable=3D"NO" to rc.conf. In addition, the PCI slot is not loading the drivers, and could not make any PCI to SATA cards (that work on FreeBSD) - ASMedia ASM1061, Marvell 88SE9215 (both covered by AHCI). attaching the dmesg. --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Thu May 18 10:08:04 2023 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 4QMQff49fyz3bTcL for ; Thu, 18 May 2023 10:08:42 +0000 (UTC) (envelope-from marietto2008@gmail.com) Received: from mail-yb1-xb2b.google.com (mail-yb1-xb2b.google.com [IPv6:2607:f8b0:4864:20::b2b]) (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 4QMQfd70Pzz3mpX for ; Thu, 18 May 2023 10:08:41 +0000 (UTC) (envelope-from marietto2008@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20221208 header.b=aILKFLgQ; spf=pass (mx1.freebsd.org: domain of marietto2008@gmail.com designates 2607:f8b0:4864:20::b2b as permitted sender) smtp.mailfrom=marietto2008@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-yb1-xb2b.google.com with SMTP id 3f1490d57ef6-ba865ac594bso2350574276.0 for ; Thu, 18 May 2023 03:08:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1684404521; x=1686996521; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=SlIAuX5KLwV+k3u9XhuywhIppD1WyTAlWVxuJEmZQmU=; b=aILKFLgQktBZQf/llCawaTCHauiAOeGZuvACSvnVWDj/1jJEaagTrJouflcOf4qPqj WPoPgLTfeUDZ38b4/oPm66wUJjd6+1Xlt4DDhf89dhtx6lUoA7Br2mh7UjdIMG2aV+lR RaTls48ocw9JapeUzAQvc/D7MK1pn6bkGbx5E3bbPQaMAEbjuKb0ON2/GXTpEzK5l2/J B0MXxdTy00AYT4AQOOpNbsMx0TLU5nzqiqCs7Tv40pCxFi8Yv1DGR4FSW2wavKZndulK BlLbIPesOZb8U3NW0Uc9FTo6drFGJSfHXqPxQoLIo7Rw9JYuTEzaxH1v5rJOJetnrwTF FErw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684404521; x=1686996521; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=SlIAuX5KLwV+k3u9XhuywhIppD1WyTAlWVxuJEmZQmU=; b=JfhqNxE0zPZTpbZpLRU5mjca4zWwNtvYL0BY2zyudsfpqgSwe8Og123TtI+HpCzBI/ 6u65WDFTiuk+Q44kjJTvyl9ulXXuFFTGRX/i4VJNzw0oT10f5rhucBssReVXGRXBrM3u zGaPA2GaEOCTaI2GJBqFrerZDnMaM2q3z9xIQWd/HM6q8upzEB4pCohmXDnOR1i5OWOE O6kDRCFazmQbO78UbdAohtC4iq5LUbRufTRj0JBOXOq0RlhNUQF3yF3IJSsx/dqv/p05 Jkox198QIEDgBi0xQQN+NezatTTaYet0LJneO7iW+vPHuhBI/FTlEOD+QaBUPm78SVYg YS0A== X-Gm-Message-State: AC+VfDyGsqhDsIejRDcczknrPJiRct+kyQkp77lDQb0xkoZiFLKbaw1e cmUCLrNDTvJSAYOZWwbiIJha45g8IRaAuGpVXnVu/JVPKEx7kg== X-Google-Smtp-Source: ACHHUZ6+MQK5nTAMXofayZDMJEgnnyB64B04T1bLNAV70Kt/D3kMAVvbB7gGEAjQ2AIAk/2pqQcsnsWBh1OEOTKKesY= X-Received: by 2002:a25:b298:0:b0:b9e:8a8b:b073 with SMTP id k24-20020a25b298000000b00b9e8a8bb073mr902436ybj.39.1684404520807; Thu, 18 May 2023 03:08:40 -0700 (PDT) List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 From: Mario Marietto Date: Thu, 18 May 2023 12:08:04 +0200 Message-ID: Subject: FreeBSD on the pinephone : considerations To: freebsd-arm@freebsd.org Content-Type: multipart/alternative; boundary="0000000000001ef13105fbf4fdc8" X-Spamd-Result: default: False [-3.96 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.96)[-0.959]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20221208]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; ARC_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::b2b:from]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FREEMAIL_FROM(0.00)[gmail.com]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; TO_DN_NONE(0.00)[]; RCVD_TLS_LAST(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-Rspamd-Queue-Id: 4QMQfd70Pzz3mpX X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N --0000000000001ef13105fbf4fdc8 Content-Type: text/plain; charset="UTF-8" Hello. some days ago on the FreeBSD forum someone posted this tutorial : https://research.exoticsilicon.com/series/pinephone_openbsd/part_1 A lot of work has been done to port NetBSD on the pinephone,even if the battery will not work as stated. I would like to know if this tutorial can be taken as a solid base to port FreeBSD instead of NetBSD. In other words,is FreeBSD so different from NetBSD that the whole procedure can't be useful at all or some part of it can be re-adapted easily ? How much efforts and work is needed to adapt it ? -- Mario. --0000000000001ef13105fbf4fdc8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello.

some days ago on the = FreeBSD forum someone posted this tutorial :

=

A lot of work has been done to port NetBSD o= n the pinephone,even if the battery will not work as stated. I would like t= o know if this tutorial can be taken as a solid base to port FreeBSD instea= d of NetBSD. In other words,is FreeBSD so different from NetBSD that the wh= ole procedure can't be useful at all or some part of it can be re-adapt= ed easily ? How much efforts and work is needed to adapt it ?

--
Mario.
--0000000000001ef13105fbf4fdc8-- From nobody Thu May 18 10:32:59 2023 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 UTF8SMTP id 4QMRBt1mtvz4BPtZ for ; Thu, 18 May 2023 10:33:10 +0000 (UTC) (envelope-from freebsd-arm@dino.sk) Received: from cm0.netlabit.sk (mailhost.netlabit.sk [84.245.65.72]) (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 UTF8SMTPS id 4QMRBs1Cc8z3pcX for ; Thu, 18 May 2023 10:33:08 +0000 (UTC) (envelope-from freebsd-arm@dino.sk) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of freebsd-arm@dino.sk designates 84.245.65.72 as permitted sender) smtp.mailfrom=freebsd-arm@dino.sk; dmarc=none Received: from zeta.dino.sk ([84.245.95.254]) (AUTH: LOGIN milan, TLS: TLSv1.3,256bits,TLS_AES_256_GCM_SHA384) by cm0.netlabit.sk with ESMTPSA id 00000000009567EB.000000006465FEDC.000106C0; Thu, 18 May 2023 12:33:00 +0200 Date: Thu, 18 May 2023 12:32:59 +0200 From: Milan Obuch To: freebsd-arm@freebsd.org Subject: Re: FreeBSD on the pinephone : considerations Message-ID: <20230518123259.55acf1fc@zeta.dino.sk> In-Reply-To: References: X-Mailer: Claws Mail 3.19.1 (GTK+ 2.24.33; amd64-portbld-freebsd13.1) 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-Result: default: False [-3.25 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.98)[-0.976]; NEURAL_HAM_MEDIUM(-0.98)[-0.975]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:5578, ipnet:84.245.64.0/18, country:SK]; MID_RHS_MATCH_FROMTLD(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; DMARC_NA(0.00)[dino.sk]; ARC_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_HAS_DN(0.00)[]; TO_DN_NONE(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_ALL(0.00)[] X-Rspamd-Queue-Id: 4QMRBs1Cc8z3pcX X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N On Thu, 18 May 2023 12:08:04 +0200 Mario Marietto wrote: > Hello. > > some days ago on the FreeBSD forum someone posted this tutorial: > > https://research.exoticsilicon.com/series/pinephone_openbsd/part_1 > > A lot of work has been done to port NetBSD on the pinephone, even if > the battery will not work as stated. I would like to know if this > tutorial can be taken as a solid base to port FreeBSD instead of > NetBSD. In other words, is FreeBSD so different from NetBSD that the > whole procedure can't be useful at all or some part of it can be > re-adapted easily? How much efforts and work is needed to adapt it? > Hi, at a glance, this tutorial is worth reading as it contains good overview of the whole process. The basics are there. Note it is using *OpenBSD*, not *NetBSD* as you wrote, but this is just oversight I think. For FreeBSD, you should probably try first running from microSD card, not installing to internal eMMC (SD card image for arm64/aarch64 architecture should be a good start, needs just adding correct U-Boot binary). Regards, Milan From nobody Thu May 18 10:41:56 2023 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 4QMRPk188jz4BQGL for ; Thu, 18 May 2023 10:42:34 +0000 (UTC) (envelope-from marietto2008@gmail.com) Received: from mail-yb1-xb35.google.com (mail-yb1-xb35.google.com [IPv6:2607:f8b0:4864:20::b35]) (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 4QMRPj6N4Fz3qNW for ; Thu, 18 May 2023 10:42:33 +0000 (UTC) (envelope-from marietto2008@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-yb1-xb35.google.com with SMTP id 3f1490d57ef6-ba6d024a196so1550186276.2 for ; Thu, 18 May 2023 03:42:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1684406552; x=1686998552; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=hN20Ct7a1DCumt4ZVfoKvMqHyIl8uSzipPsTdBICb+8=; b=gNfK8JHqrlHgYcwpmz8aApd1tD3DdAAsHfUKGgukdXtY4vqWBuJKL23I5s0/mGuAUX tB7AQEWb5QgOGJlbdWUcmmMPHCZ7WcMiZzf2I9z1c+Wn7wUO1iqSei82GJe4qrTnOINT 788frfCBxXmcQscSkiooWScAT3JR9LoG72D4l+rjg9oRkGZyB2UvsrevmnwlKPQkUnfP +x+rP8KUB6TzTeQ0tAUv97Kh3/IrQ6kTecxGQaZLxHyYxw+dQAwbP1IU93TSK3hYBeuT gESvdd6+HlwKUAIvV32WiqSs1x24msCy4iH+v4qK9Da1yIHTwoFpibm5iu3xXBj5BU/P zTZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684406552; x=1686998552; 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=hN20Ct7a1DCumt4ZVfoKvMqHyIl8uSzipPsTdBICb+8=; b=M0WTkuior6RIaDcyvpXz7P7clyZGQcRt+7ZSQL+x1FENi/N9IP92ukI88sUqT5xIqZ IyQOK2LXXf3VwUarFM4K6SoVnwvuqFyWOdvp+5zCzlLhYDd0Yd7+XfM9T/4s8JiFtnoC pEnMmbeUmvJ5cnuZ+i5VHLRe3a+lHa/bLRlkqM4oP2GC4hGe4NNBPfMTMIwCQnxElzQx lE7nnDp8L7IVHPc8n38PeGtsLJ3nNUJc5ClEbzwQA/9xgYNBVNbHfShhdU3zsYogUIc8 E/3x1leigdTjZ6br0lQLEPNioGcpkiUoD3Lh0Y+g1YdhhQ0tw5BC9RpHKf0aaUWdotug gk2w== X-Gm-Message-State: AC+VfDzGbDVaCbgtTSQPx2a9BsLuxkIgaSsscl2u51FyhIR55MLfknzW dKVfzHDkr/R5ecuN2BtsZkcD7EsqFMg86rJww98ExlReo3w= X-Google-Smtp-Source: ACHHUZ43LXwcA9yVx9z+IGvTNixVcJdDVludluXNQ0QNvzwzbk/KBrvF8L0HCzGjOVRlSrJbs8sY1JEShBsWNkMuOb0= X-Received: by 2002:a81:6c08:0:b0:561:a7fd:4fe4 with SMTP id h8-20020a816c08000000b00561a7fd4fe4mr856170ywc.28.1684406552461; Thu, 18 May 2023 03:42:32 -0700 (PDT) List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 References: <20230518123259.55acf1fc@zeta.dino.sk> In-Reply-To: <20230518123259.55acf1fc@zeta.dino.sk> From: Mario Marietto Date: Thu, 18 May 2023 12:41:56 +0200 Message-ID: Subject: Re: FreeBSD on the pinephone : considerations To: Milan Obuch Cc: freebsd-arm@freebsd.org Content-Type: multipart/alternative; boundary="00000000000037872005fbf57600" X-Rspamd-Queue-Id: 4QMRPj6N4Fz3qNW X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --00000000000037872005fbf57600 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Milan,why did you stop collaborating with me ? Suddenly you stopped replying. What happened ? On Thu, May 18, 2023 at 12:33=E2=80=AFPM Milan Obuch = wrote: > On Thu, 18 May 2023 12:08:04 +0200 > Mario Marietto wrote: > > > Hello. > > > > some days ago on the FreeBSD forum someone posted this tutorial: > > > > https://research.exoticsilicon.com/series/pinephone_openbsd/part_1 > > > > A lot of work has been done to port NetBSD on the pinephone, even if > > the battery will not work as stated. I would like to know if this > > tutorial can be taken as a solid base to port FreeBSD instead of > > NetBSD. In other words, is FreeBSD so different from NetBSD that the > > whole procedure can't be useful at all or some part of it can be > > re-adapted easily? How much efforts and work is needed to adapt it? > > > > Hi, > > at a glance, this tutorial is worth reading as it contains good > overview of the whole process. The basics are there. Note it is using > *OpenBSD*, not *NetBSD* as you wrote, but this is just oversight I > think. For FreeBSD, you should probably try first running from microSD > card, not installing to internal eMMC (SD card image for arm64/aarch64 > architecture should be a good start, needs just adding correct U-Boot > binary). > > Regards, > Milan > > --=20 Mario. --00000000000037872005fbf57600 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Milan,why did you stop collaborating with me ? Suddenly yo= u stopped replying. What happened ?

On Thu, May 18, 2023 at 12:33=E2=80= =AFPM Milan Obuch <freebsd-arm@di= no.sk> wrote:
On Thu, 18 May 2023 12:08:04 +0200
Mario Marietto <marietto2008@gmail.com> wrote:

> Hello.
>
> some days ago on the FreeBSD forum someone posted this tutorial:
>
> https://research.exoticsilico= n.com/series/pinephone_openbsd/part_1
>
> A lot of work has been done to port NetBSD on the pinephone, even if > the battery will not work as stated. I would like to know if this
> tutorial can be taken as a solid base to port FreeBSD instead of
> NetBSD. In other words, is FreeBSD so different from NetBSD that the > whole procedure can't be useful at all or some part of it can be > re-adapted easily? How much efforts and work is needed to adapt it? >

Hi,

at a glance, this tutorial is worth reading as it contains good
overview of the whole process. The basics are there. Note it is using
*OpenBSD*, not *NetBSD* as you wrote, but this is just oversight I
think. For FreeBSD, you should probably try first running from microSD
card, not installing to internal eMMC (SD card image for arm64/aarch64
architecture should be a good start, needs just adding correct U-Boot
binary).

Regards,
Milan



--
Mario.
--00000000000037872005fbf57600-- From nobody Thu May 18 10:57:22 2023 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 4QMRl55XNpz4BQVh for ; Thu, 18 May 2023 10:57:37 +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 4QMRl52NpZz3rqs for ; Thu, 18 May 2023 10:57:37 +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=1684407455; bh=3gYPCrnkSiR4tKjyeqeOQkdmwgVcF8BEzweeotuNnX0=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=pOorb+YE8XHMP+u237x8A9Hb3ssFc2827Tp4AGZ2ASVLgfxVT+YiRxCbv1L5oJ+KcCobEuR46fEOhUgVdh7TkGN1F+Ob447NcGpT4GJWiEV51u1RXP35JVm4tH8O0hRVEAfCiI3PzbscuVNUvMb9lGyJ7zmtHhJ1RIUImNYZdcdFqVouRgfxPbE+ReDFuakTdtFI/7jEvHZSjfIAvEvZKeUeIyxBtADo1f2XkFOa40VJ8ksqg0pUc8sERqXPGp9DXWi4we/G1il/1NGRtAgw0MdJEgrwazVIgTGRzSRcnfZ3laeOfNCwBdXwiGfuQjfg6XBDq1nRmC73PotMCy+WXw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1684407455; bh=ISmPxmFaIKg6Z6FJtdyuXWV4HqYl0R16OzxCwWEj1o7=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=FstqIbfnZO+6daDiUh8zcOzzXfVuQpis514PNlMb/DPLhsFiOFRUaqJ9TTZ8+acu1s10JGOsjnWUunaI+uG7o2/erH0jk1/hEOIl2CvX7/d5q+hq28YgwS2/L/au4TlPJKJEK0Mtn4xOtNOoKHbQI+oluQfZj3BxVsTA8O57EOP2BJp1swYeBKLt0IFd0nWPc3orCTMnMED8cehwOUOFtuRJVdvy0x/MICDzWXNPmLtoAHL4LGKAPUoGLL765ZjNCHsH59y/doJ8DOChrMyeb3kqbSxxmL5J5+cMu0mmUxJJghuj9+euRp7ibdATcdcNcL31qxcrQxUeVg11J32Zxw== X-YMail-OSG: ZSCpPJMVM1lrG7waDZBGbf0E4SntNqr7O4SUEmuWluOIKujKTWtTkGlNQNOySS5 28QvQUpd6KoyLKvjpf7ie2xAlf4Zqy1quC9ZR3fXmyeOzAkkBr_C8oG6NXOoZs2730dJDH9AKElw YdhG242zh.o8cDO2.DxQl5y8.XbO6nB5Zu53yc7cQBD8AatuEt76tc_9TSZV6bepG39v0.6dJ0NX uSZF6afDfZOd40He9vHTtHRNezQ0yCGXXDzm69sthafy4ZeOoY3ox2VeeigC2wbP6byDVNhTgUAq HHiLA5Gwg4E1gld0gAOajMRuglbCJMEkKAU.p_bxrSSbMeuIN97yExsrE_xCwP9H_VFWGmUKJcbO j9q.GD2QJjZwWiHMV8jHUy_Wd60AWC.IKHSqmfypTikxahmFfD58zhK4WF92SrEj_UADxrTJdtKT 2XRuNWfrN4PxA766Q6fmaqJye.cZlX3DTIY2j_HzDDkw1J2y4nHkqfnsqAMgy3yJnuUogTqlq6Jx qFTHYqhoYOJQk.fF8klLYCJRKn6YCpGn4kLyOQgJTyTycvvriNLUsiMwmgC0jInr1j31bCEljeAC b6Yjc9dIuznkotzAQtGkZLGx9RdinBE1Q5E4JwVbCxAxZROlbFjlhJg.l5luBX8j2XjjY7nawUH. DipJvvW0K_EJzxQREXwvUD5nqglF.zzSgHYlHQVHZSoa0YTmEO1NKequrEpymQezVVU_XHNwi9w4 qUjso.9BOx.vDz6Tfl88GbIRkhS3Csc6n.duzfOd531fP3z_OPpOndP3pk8PRh2bHU1Z94o4XgbL _lixtgQBQy5eBsAjRfUoWe9NX9t5lxBq1g5pSRR5KsmGZ0JKJswUJVRVVec2n5doEAT5oDLSqt04 jh2UeJCWySRrm0SAohjYJrPEMNS5un2Jd9ygJQwZwHU3fwS5.xLtyUmWhAAF7CkvTc7_pbq2qol1 ZluiCgOrrRoq6mQApR0g0EkQLJtpUWrC_G1bCSmpA03a_mTx8H1wnn5_MPa9FJnqQK72GsC8V4qO vI.GAK_DSF.QSK9gSh.i1NX7gcUbYai4.CKtmzIw0xoHhZn1tMMn6Yzf9QOZ7lLI4NoXfqeDl2Pq csGBlRqoeXkbpXpUs_iPuBFbZE8fO6Q_gZV3bjRu3d0xTaeH7Xi.CDi3gr.vR_xEndQ_kUuzdCEP WAGT6MLSH98mtuFFiVpu33W_qygooAi_EERSzUlFzC9DT8rbhoeRPeM3B_qMfIiVOnKAQDE0d_LR az0nnEBDFDjaSGefvFTKyTtAOXyScwEL4VkpMrefqCoEs5vlSm_Igk2hL16IfwSgTsUp1PApJZhd eTb8p55q71w8uRyZOD7pvKqEahN_1vXDviqf5m9400E1fn4_9fcXwkJ5mPtcqUYX6z9vlrZ9PDoB YgriJbc7nsGW8DKK9UwgpJ393..t8sRHbllt0cZE9EkPgoY.vlwHioDJvnz9A9F0fs2zb.Wj4BKW zNTuWUzDASbESIgZ2RZ9nsf1n5FoNMWfu.TTaYFZeLcKkzSvjHmjVNHF7GQ_o1PffhnCFrcEaL43 gxqL5JxA5AXWn9H6cLzKOzu43UgzXg6X_E3wcZaE0hWJwzCF_lZ0aLWTA1cgXd0..NWyrXdQ1WO3 cD5XSV._nlANY5dRPre812vtrqXrTemcWPJ.k0CXwZe.a.Z8b4.zVthxEDl4GEOap80OHRxuf3DE pH4xG3YKIOLIVmchxB9OZ.jr62YKeJms6J35seAUzPHLv7bY5oHBVYL1bClMj7FPFVbdSPwrOxJe NxHl.mFZKn_8ZWFyVvua1Bl76slgGRJsdJNP2WYMzo3E81BYZlNtxElCgHbQUU4VTy6Vr2NcEm4C P_uv804NKrJAFyZLnGLWOf1xwh2rXgimJFl1ZIDhHja6Fr4E56IfThPzlr52.zz1GuZ_mER7cUHg 5JF6qwFu17uP1wkLt7g_54cXLnmhbdp.CsfHXlqlIptjpy2vKt7ahuC_OYmOnaRgXkq_3Tc10EBY 0FL9iUL1tc6S96hI1z8vmp7Iz5ewUaEYGSDOWzz_qaSOTXfLZjLf0odZlKcJrYiMUjka1d4rGlIu a9GFTl.YbcDlM4.31cM3mCl94pUbdTngI_Q4IfEU6i4TWTxdpvzEyyas3lXjDGPeJ_vBJukpBk9x Kaj4rgAfzFwURK32cMJ9r9UrEjZFQRSrTylTW6H9Wejd9CM8_DrHx.4mCRV1jVDo2Fr_Z0E_3dXD rivcYJPxda0OqedfsOfT_gKEWnetvbG.7Vfyb9GagQpR0_2m0g6xgp9jFkzZeXXZu5Csn6ADQQVE k X-Sonic-MF: X-Sonic-ID: f291fa85-c0d3-4bf8-9887-595f547fd293 Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Thu, 18 May 2023 10:57:35 +0000 Received: by hermes--production-ne1-574d4b7954-j2pvq (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 154606a66ecdecdbbc97aa4854fd7698; Thu, 18 May 2023 10:57: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 \(3731.400.51.1.1\)) Subject: Re: Raspberry Pi POE+ hat overlay From: Mark Millard In-Reply-To: Date: Thu, 18 May 2023 03:57:22 -0700 Cc: Doug Rabson , freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <77CD0716-3BC8-47EB-8743-F2BD9CA43D31@yahoo.com> <432A1A16-9FE5-4339-AB38-8F3E03A5D4EF@yahoo.com> To: Nuno Teixeira X-Mailer: Apple Mail (2.3731.400.51.1.1) X-Rspamd-Queue-Id: 4QMRl52NpZz3rqs X-Spamd-Bar: ---- 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] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On May 18, 2023, at 01:29, Nuno Teixeira wrote: > Confirmed that arm_boost is enable by default on rpi4 rev >=3D 1.4 as = I checked with htop. >=20 > Also, tested arm_freq=3D1800 and it crashes FreeBSD around = initializing console/video and detecting mouse. Overclocking by setting the arm_freq directly involves also managing over_voltage explicitly, such as: over_voltage=3D6 A sequence I use (and have used for a long time) is: [pi4] over_voltage=3D6 arm_freq=3D2000 sdram_freq_min=3D3200 force_turbo=3D1 But each RPi4B has heatsinks, a case with a fan, and a power supply rated for 5.1V 3.5A (so: has some extra margin). But the range of RPi4B's span Rev 1.1, Rev 1.4, and Rev 1.5, a mix of 4 GiByte RAM and 8 GiByte RAM models. All use those settings. As I understand, arm_boost implicitly does the extra things required for its implicit frequency, unlike assigning arm_freq or the like. If force_turbo is not used, it can be that: # # Local addition that avoids USB3 SSD boot failures that look like: # uhub_reattach_port: port ? reset failed, error=3DUSB_ERR_TIMEOUT # uhub_reattach_port: device problem (USB_ERR_TIMEOUT), disabling port = ? initial_turbo=3D60 is required for USB based booting. But this also gets into if the notation is supported or not for the firmware vintage used. The initial_turbo use happens to avoid frequency variability during boot and it appears that FreeBSD does not necessarily tolerate such variability in that time frame. Also: I happen to have USB3 boot media for which use of usb_pgood_delay=3D2000 is sufficient but without some such in/for U-Boot, U-Boot has problems recognizing the device (before FreeBSD is even involved). I build the U-Boot port with the assignment built in. > As linux config.txt says: > --- > [pi4] > # Run as fast as firmware / board allows > arm_boost=3D1 > --- > firmware must be updated to support this feature for sure. I'm not aware of a dated list of when the various config.txt notations were first supported (firmware version). This makes it messier to use the web's published information, if one is using the firmware vintage that FreeBSD has in its port for the firmware. The notation that I use has been around for a long time. > Cheers, >=20 > Nuno Teixeira escreveu no dia quarta, 17/05/2023 = =C3=A0(s) 14:08: > (...) >=20 > I was meant using 13.2 not 12.3 :) >=20 > Doug Rabson escreveu no dia quarta, 17/05/2023 =C3=A0(s= ) 13:47: > I'm not sure about 12.3 either - you could try with 13.2 and see if = that makes a difference. >=20 > On Wed, 17 May 2023 at 13:45, Nuno Teixeira = wrote: > Hey, >=20 > Ok. I'm new to rpi4 and arm in general but tomorrow I will force = 'arm_freq=3D1800' again just to see it it crashes again. > I will check too what values linux shows. >=20 > I don't know if firmware/uboot version included in 12.3 supports this = feature. >=20 > Cheers, >=20 > Doug Rabson escreveu no dia quarta, 17/05/2023 =C3=A0(s= ) 13:11: > Hi Nuno, >=20 > I'm not sure where to start - I just happened to notice in the = documentation here: = https://www.raspberrypi.com/documentation/computers/config_txt.html that = the cpu frequency Pi4B R1.4 was listed as 1800 if arm_boot=3D1 so I = tried it. >=20 > Doug. >=20 >=20 >=20 > On Wed, 17 May 2023 at 11:11, Nuno Teixeira = wrote: > Hello Doug, >=20 > I have too a 1.5 rpi but arm_boost=3D1 isn't doing anything, htop = shows 1500Mhz when doing something intensive. > I'm running 13.2 stable >=20 > Do I missing something? >=20 > Could you take a look at my setup? >=20 > Thanks, >=20 > Doug Rabson escreveu no dia ter=C3=A7a, 16/05/2023 = =C3=A0(s) 17:19: >=20 > On Sat, 13 May 2023 at 13:45, Doug Rabson wrote: > I was able to build an updated rpi-firmware port based on 1.20210805 = and this boots successfully on pi400 as well as rpi4. With this, I can = load the rpi-poe-plus overlay and I just need to try and reverse = engineer the undocumented mailbox API by reading the Linux code. >=20 > I have a first approximation of a fan driver which works with the = 1.20210805 firmware (actually, I substituted rpi-poe-plus.dtbo from = 1.20210831 which just changes the fan levels for the POE+). I'm testing = with an rpi4B rev 1.5 with 'make -j4 buildworld' and the fan is keeping = the cpu temperature below 65 degrees which is nice, especially since I = set arm_boost=3D1 in config.txt which boosts the cpu frequency up to = 1800 for this board. >=20 > Does anyone have a pointer to the problem with firmware later than = 20210805? Would it make any kind of sense to try to get the fix into = releng/13.2 as an errata? >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Thu May 18 12:48:18 2023 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 4QMVC36NkYz4BWyP for ; Thu, 18 May 2023 12:48:31 +0000 (UTC) (envelope-from eduardo@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 4QMVC368jZz44Ls for ; Thu, 18 May 2023 12:48:31 +0000 (UTC) (envelope-from eduardo@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1684414111; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=cEY9vX6Zu4OXucQog1n8+TSzSmpDVV45NvrYwhAdx2U=; b=SH0Ml4MfHWXxuhFmJEWJTJok/QcydNejAJvCElsME4Ng2P5nUFc4OIYon1NF9wisWNqvC8 RRZNjmc2QgBGM74T/ivdwMa1sXRZDKWRJgDYj5wBSsxwj77Fe2YpEFKGMY92QiCVsJLTRI G3yZf4KVG4hMdMcDQviIO9U89O2RE5T5FCc2JeqP1eNch6Hxcwju6Tu+ED+QGuo0ng/HSF 3S0BxTLE4HXrBJDsv0Oupcqqm1/obMsvuqlhay0b3UxPXzQLMHDyVg+n05ugSmyNYkzCvY O6PJztA2VMqRR4a6AMHRoenx5xkSNGhnNVshSLFSTDBbHKy0Zl0fZmHXkG+mwA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1684414111; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=cEY9vX6Zu4OXucQog1n8+TSzSmpDVV45NvrYwhAdx2U=; b=IfMxxxvP9pDoYKetZL/ecJ5d+LyG8K3BGxdEdBeEgxLQlKhGeJ7uoJRU1euU+DeX9GKCIs 6OxYm/oi7awGUuWUblOSMWASfWei4KVwkUvnX77nF/1eiOB5jnmnrmecrNouOeMRNoTgs6 g/TjUAr4SmZx1yd6UtFbuTgtyI+6MbB7v9YZc+Pt+4mvKd1U6dQoE08wwgMdxwtDe9NpT/ 3XErztILmOttx6EjbxQked6xsz8YUDin3bmjQnP3WMozncucIB6n2r/gSsWkZ17wiaz514 foGoHl2wOsx9rTSFPhB3uQ66XBDdpxLXPfL7AekHXIAOQ8NVAsiFot3Z4/ZH4w== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1684414111; a=rsa-sha256; cv=none; b=RYyKDdPqO20rXr+QVmed/xIGEOc/AdjvuHQCYV8bBZvxccGIXe/mIBbzukGIct6SYOm+eT aMwQTwTwqwdVsy/OrM//uZgHV/DyYHpv6FclhEzdkPXxiHmM6gUBJwptbIUbSmk2HjjBFm So8fdtyU16EYw8daV0kCoaFiL9GE4kXOnKGpdQLpCE3W79icDks0X7Vo27h+CaDKiZehyf snZn4FmXZVDufu9qwhc7lQNFQfM8BIedoKUjar933BA/D1DZVhk9JBQB216yDVarVyIOz+ KuoeIiEWe5BVM69QEQDLMg6E3Jkck+dJK3XO1s7T3DEm506PPvyOUB6Wu71Izw== Received: from mail-pl1-f174.google.com (mail-pl1-f174.google.com [209.85.214.174]) (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)) (Authenticated sender: eduardo) by smtp.freebsd.org (Postfix) with ESMTPSA id 4QMVC34z8hzPdw for ; Thu, 18 May 2023 12:48:31 +0000 (UTC) (envelope-from eduardo@freebsd.org) Received: by mail-pl1-f174.google.com with SMTP id d9443c01a7336-1ae454844edso15031255ad.1 for ; Thu, 18 May 2023 05:48:31 -0700 (PDT) X-Gm-Message-State: AC+VfDyncJNbuGUVMzvTsTVYzJB5+/gamb/FrKueRbyozQmKgx2XvpsT C9eKgahzE64UC0BOrJ1bbGqtkhd60YCH4cQNwlQ= X-Google-Smtp-Source: ACHHUZ5b6mxlP5C1D4mClBJtNuDjabS25Is/bA88ekP2o077c+bLc8CgEZkts36dka0c3/mLSdFaS4Cef92z/9uGo0U= X-Received: by 2002:a17:902:e549:b0:1ac:a661:a4b0 with SMTP id n9-20020a170902e54900b001aca661a4b0mr2634536plf.57.1684414110761; Thu, 18 May 2023 05:48:30 -0700 (PDT) List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 References: <77CD0716-3BC8-47EB-8743-F2BD9CA43D31@yahoo.com> <432A1A16-9FE5-4339-AB38-8F3E03A5D4EF@yahoo.com> In-Reply-To: From: Nuno Teixeira Date: Thu, 18 May 2023 13:48:18 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Raspberry Pi POE+ hat overlay To: Mark Millard Cc: Doug Rabson , freebsd-arm@freebsd.org Content-Type: multipart/alternative; boundary="000000000000ba09be05fbf7383e" X-ThisMailContainsUnwantedMimeParts: N --000000000000ba09be05fbf7383e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Mark! Indeed, voltage was the missing bit! I'm trying to setup 1800 as default now for revs >=3D 1.4 following https://www.raspberrypi.com/news/bullseye-bonus-1-8ghz-raspberry-pi-4/ that only talk about setting arm_freq=3D1800 but doesn't mention to adjust volta= ge. It was nice that raspberry tell us what voltage exacly value they use for new default 1800. What I've got now is: [pi4] over_voltage=3D6 arm_freq=3D2000 sdram_freq_min=3D3200 ### force_turbo=3D1 My tests shows that we don't need force_turbo=3D1 for a normal running and system do an auto 600 -> 2000 change when needed. Thats nice. Also, arm_boost=3D1 with force_turbo or not, is ignored. sdram_freq and sdram_freq_min are set to 3200 by default, so I think I will not need sdram_freq_min=3D3200 here. The only thing that I can't understand is how to calculate voltage: over_voltage: 0 (1.35V, 1.2V on Raspberry Pi 1) ??? ( https://www.raspberrypi.com/documentation/computers/config_txt.html ) Also, "7. Take it to the max" ( https://magpi.raspberrypi.com/articles/how-to-overclock-raspberry-pi-4 ): over_voltage=3D6 (?) arm_freq=3D2147 gpu_freq=3D750 Thanks, Mark Millard escreveu no dia quinta, 18/05/2023 =C3=A0(= s) 11:57: > On May 18, 2023, at 01:29, Nuno Teixeira wrote: > > > Confirmed that arm_boost is enable by default on rpi4 rev >=3D 1.4 as I > checked with htop. > > > > Also, tested arm_freq=3D1800 and it crashes FreeBSD around initializing > console/video and detecting mouse. > > Overclocking by setting the arm_freq directly involves also > managing over_voltage explicitly, such as: > > over_voltage=3D6 > > A sequence I use (and have used for a long time) is: > > [pi4] > over_voltage=3D6 > arm_freq=3D2000 > sdram_freq_min=3D3200 > force_turbo=3D1 > > But each RPi4B has heatsinks, a case with a fan, > and a power supply rated for 5.1V 3.5A (so: has > some extra margin). > > But the range of RPi4B's span Rev 1.1, Rev 1.4, > and Rev 1.5, a mix of 4 GiByte RAM and 8 GiByte > RAM models. All use those settings. > > As I understand, arm_boost implicitly does the > extra things required for its implicit frequency, > unlike assigning arm_freq or the like. > > If force_turbo is not used, it can be that: > > # > # Local addition that avoids USB3 SSD boot failures that look like: > # uhub_reattach_port: port ? reset failed, error=3DUSB_ERR_TIMEOUT > # uhub_reattach_port: device problem (USB_ERR_TIMEOUT), disabling port = ? > initial_turbo=3D60 > > is required for USB based booting. But this also > gets into if the notation is supported or not for > the firmware vintage used. > > The initial_turbo use happens to avoid frequency > variability during boot and it appears that FreeBSD > does not necessarily tolerate such variability in > that time frame. > > Also: I happen to have USB3 boot media for which use > of usb_pgood_delay=3D2000 is sufficient but without > some such in/for U-Boot, U-Boot has problems > recognizing the device (before FreeBSD is even > involved). I build the U-Boot port with the > assignment built in. > > > As linux config.txt says: > > --- > > [pi4] > > # Run as fast as firmware / board allows > > arm_boost=3D1 > > --- > > firmware must be updated to support this feature for sure. > > I'm not aware of a dated list of when the various > config.txt notations were first supported (firmware > version). This makes it messier to use the web's > published information, if one is using the firmware > vintage that FreeBSD has in its port for the > firmware. > > The notation that I use has been around for a long > time. > > > Cheers, > > > > Nuno Teixeira escreveu no dia quarta, 17/05/2023 > =C3=A0(s) 14:08: > > (...) > > > > I was meant using 13.2 not 12.3 :) > > > > Doug Rabson escreveu no dia quarta, 17/05/2023 =C3=A0(= s) > 13:47: > > I'm not sure about 12.3 either - you could try with 13.2 and see if tha= t > makes a difference. > > > > On Wed, 17 May 2023 at 13:45, Nuno Teixeira wrote= : > > Hey, > > > > Ok. I'm new to rpi4 and arm in general but tomorrow I will force > 'arm_freq=3D1800' again just to see it it crashes again. > > I will check too what values linux shows. > > > > I don't know if firmware/uboot version included in 12.3 supports this > feature. > > > > Cheers, > > > > Doug Rabson escreveu no dia quarta, 17/05/2023 =C3=A0(= s) > 13:11: > > Hi Nuno, > > > > I'm not sure where to start - I just happened to notice in the > documentation here: > https://www.raspberrypi.com/documentation/computers/config_txt.html that > the cpu frequency Pi4B R1.4 was listed as 1800 if arm_boot=3D1 so I tried= it. > > > > Doug. > > > > > > > > On Wed, 17 May 2023 at 11:11, Nuno Teixeira wrote= : > > Hello Doug, > > > > I have too a 1.5 rpi but arm_boost=3D1 isn't doing anything, htop shows > 1500Mhz when doing something intensive. > > I'm running 13.2 stable > > > > Do I missing something? > > > > Could you take a look at my setup? > > > > Thanks, > > > > Doug Rabson escreveu no dia ter=C3=A7a, 16/05/2023 =C3= =A0(s) > 17:19: > > > > On Sat, 13 May 2023 at 13:45, Doug Rabson wrote: > > I was able to build an updated rpi-firmware port based on 1.20210805 an= d > this boots successfully on pi400 as well as rpi4. With this, I can load t= he > rpi-poe-plus overlay and I just need to try and reverse engineer the > undocumented mailbox API by reading the Linux code. > > > > I have a first approximation of a fan driver which works with the > 1.20210805 firmware (actually, I substituted rpi-poe-plus.dtbo from > 1.20210831 which just changes the fan levels for the POE+). I'm testing > with an rpi4B rev 1.5 with 'make -j4 buildworld' and the fan is keeping t= he > cpu temperature below 65 degrees which is nice, especially since I set > arm_boost=3D1 in config.txt which boosts the cpu frequency up to 1800 for > this board. > > > > Does anyone have a pointer to the problem with firmware later than > 20210805? Would it make any kind of sense to try to get the fix into > releng/13.2 as an errata? > > > > > =3D=3D=3D > Mark Millard > marklmi at yahoo.com > > --=20 Nuno Teixeira FreeBSD Committer (ports) --000000000000ba09be05fbf7383e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Mark!

Indeed, voltage = was the missing bit!

I'm trying to setup 1800 = as default now for revs >=3D 1.4 following https://www.raspberry= pi.com/news/bullseye-bonus-1-8ghz-raspberry-pi-4/ that only talk about = setting arm_freq=3D1800 but doesn't mention to adjust voltage.
It was nice that raspberry tell us what voltage exacly value they use for= new default 1800.

What I've got now is:

[pi4]
over_voltage=3D6
arm_freq=3D2000
sdram_freq_min=3D3200
### force_turbo=3D1

My tests shows that we don'= ;t need force_turbo=3D1 for a normal running and system do an auto 600 ->= ; 2000 change when needed. Thats nice.
Also, arm_boost=3D1 wi= th force_turbo or not, is ignored.

sdram_freq and = sdram_freq_min are set to 3200 by default, so I think I will not need sdram= _freq_min=3D3200 here.

The only thing that I can&#= 39;t understand is how to calculate voltage:

over_= voltage: 0 (1.35V, 1.2V on Raspberry Pi 1) ???

=
over_voltage=3D6 (?)
arm_freq=3D2147
gpu_freq=3D750

Thanks,


=
Mark Millard <marklmi@yahoo.com> escreveu no dia quinta, 18/05/20= 23 =C3=A0(s) 11:57:
On May 18, 2023, at 01:29, Nuno Teixeira <eduardo@freebsd.org> wrote:

> Confirmed that arm_boost is enable by default on rpi4 rev >=3D 1.4 = as I checked with htop.
>
> Also, tested arm_freq=3D1800 and it crashes FreeBSD around initializin= g console/video and detecting mouse.

Overclocking by setting the arm_freq directly involves also
managing over_voltage explicitly, such as:

over_voltage=3D6

A sequence I use (and have used for a long time) is:

[pi4]
over_voltage=3D6
arm_freq=3D2000
sdram_freq_min=3D3200
force_turbo=3D1

But each RPi4B has heatsinks, a case with a fan,
and a power supply rated for 5.1V 3.5A (so: has
some extra margin).

But the range of RPi4B's span Rev 1.1, Rev 1.4,
and Rev 1.5, a mix of 4 GiByte RAM and 8 GiByte
RAM models. All use those settings.

As I understand, arm_boost implicitly does the
extra things required for its implicit frequency,
unlike assigning arm_freq or the like.

If force_turbo is not used, it can be that:

#
# Local addition that avoids USB3 SSD boot failures that look like:
#=C2=A0 =C2=A0uhub_reattach_port: port ? reset failed, error=3DUSB_ERR_TIME= OUT
#=C2=A0 =C2=A0uhub_reattach_port: device problem (USB_ERR_TIMEOUT), disabli= ng port ?
initial_turbo=3D60

is required for USB based booting. But this also
gets into if the notation is supported or not for
the firmware vintage used.

The initial_turbo use happens to avoid frequency
variability during boot and it appears that FreeBSD
does not necessarily tolerate such variability in
that time frame.

Also: I happen to have USB3 boot media for which use
of usb_pgood_delay=3D2000 is sufficient but without
some such in/for U-Boot, U-Boot has problems
recognizing the device (before FreeBSD is even
involved). I build the U-Boot port with the
assignment built in.

> As linux config.txt says:
> ---
> [pi4]
> # Run as fast as firmware / board allows
> arm_boost=3D1
> ---
> firmware must be updated to support this feature for sure.

I'm not aware of a dated list of when the various
config.txt notations were first supported (firmware
version). This makes it messier to use the web's
published information, if one is using the firmware
vintage that FreeBSD has in its port for the
firmware.

The notation that I use has been around for a long
time.

> Cheers,
>
> Nuno Teixeira <eduardo@freebsd.org> escreveu no dia quarta, 17/05/2023 =C3=A0(= s) 14:08:
> (...)
>
> I was meant using 13.2 not 12.3 :)
>
> Doug Rabson <df= r@rabson.org> escreveu no dia quarta, 17/05/2023 =C3=A0(s) 13:47: > I'm not sure about 12.3 either - you could try with 13.2 and see i= f that makes a difference.
>
> On Wed, 17 May 2023 at 13:45, Nuno Teixeira <eduardo@freebsd.org> wrote:
> Hey,
>
> Ok. I'm new to rpi4 and arm in general but tomorrow I will force &= #39;arm_freq=3D1800' again just to see it it crashes again.
> I will check too what values linux shows.
>
> I don't know if firmware/uboot version included in 12.3 supports t= his feature.
>
> Cheers,
>
> Doug Rabson <df= r@rabson.org> escreveu no dia quarta, 17/05/2023 =C3=A0(s) 13:11: > Hi Nuno,
>
> I'm not sure where to start - I just happened to notice in the doc= umentation here: https://www.rasp= berrypi.com/documentation/computers/config_txt.html that the cpu freque= ncy Pi4B R1.4 was listed as 1800 if arm_boot=3D1 so I tried it.
>
> Doug.
>
>
>
> On Wed, 17 May 2023 at 11:11, Nuno Teixeira <eduardo@freebsd.org> wrote:
> Hello Doug,
>
> I have too a 1.5 rpi but arm_boost=3D1 isn't doing anything, htop = shows 1500Mhz when doing something intensive.
> I'm running 13.2 stable
>
> Do I missing something?
>
> Could you take a look at my setup?
>
> Thanks,
>
> Doug Rabson <df= r@rabson.org> escreveu no dia ter=C3=A7a, 16/05/2023 =C3=A0(s) 17:19= :
>
> On Sat, 13 May 2023 at 13:45, Doug Rabson <dfr@rabson.org> wrote:
> I was able to build an updated rpi-firmware port based on 1.20210805 a= nd this boots successfully on pi400 as well as rpi4. With this, I can load = the rpi-poe-plus overlay and I just need to try and reverse engineer the un= documented mailbox API by reading the Linux code.
>
> I have a first approximation of a fan driver which works with the 1.20= 210805 firmware (actually, I substituted rpi-poe-plus.dtbo from 1.20210831 = which just changes the fan levels for the POE+). I'm testing with an rp= i4B rev 1.5 with 'make -j4 buildworld' and the fan is keeping the c= pu temperature below 65 degrees which is nice, especially since I set arm_b= oost=3D1 in config.txt which boosts the cpu frequency up to 1800 for this b= oard.
>
> Does anyone have a pointer to the problem with firmware later than 202= 10805? Would it make any kind of sense to try to get the fix into releng/13= .2 as an errata?
>


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



--
Nuno Teixeira
FreeBSD Committ= er (ports)
--000000000000ba09be05fbf7383e-- From nobody Thu May 18 12:53:44 2023 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 4QMVQ340Y5z4BXcQ for ; Thu, 18 May 2023 12:58:03 +0000 (UTC) (envelope-from dsl@mcusim.org) Received: from mcusim.org (mcusim.org [IPv6:2a00:dd80:3c::e63]) (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 4QMVQ319Zlz455R for ; Thu, 18 May 2023 12:58:03 +0000 (UTC) (envelope-from dsl@mcusim.org) Authentication-Results: mx1.freebsd.org; none Received: from localhost (unknown [91.226.51.235]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mcusim.org (Postfix) with ESMTPSA id 61F896BF51; Thu, 18 May 2023 14:57:55 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mcusim.org; s=default; t=1684414675; bh=z/5BzoNoH4kUYEJ4rE43JbWRTOsWGKK/q8SKg0yi0lQ=; h=References:From:To:Cc:Subject:Date:In-reply-to; b=obwMwB2ZCWIXgGde2VmWPqGL/xQKa1LCrFHCbZH/bzQ4AS3LYuAnXRT8fR2k/oaEs DaC4xRGDTsNfx0J6Lqz3BPLGxtyMeTybvGnp9Np3N+Udk82Vmebhsm702vdJuUrk7U y/7S2HjPADZNj/X889vAy2OSsx5dvGg86e3XhwRw= References: <20230518123259.55acf1fc@zeta.dino.sk> User-agent: mu4e 1.6.10; emacs 28.2 From: Dmitry Salychev To: Mario Marietto Cc: Milan Obuch , freebsd-arm@freebsd.org Subject: Re: FreeBSD on the pinephone : considerations Date: Thu, 18 May 2023 14:53:44 +0200 In-reply-to: Message-ID: <86o7mh6bl9.fsf@peasant.tower.home> 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-Rspamd-Queue-Id: 4QMVQ319Zlz455R X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36236, ipnet:2a00:dd80:3c::/48, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N Mario Marietto writes: > Milan,why did you stop collaborating with me ? Suddenly you stopped > replying. What happened ? It's a little known fact that people on freebsd-arm are busy from time to time :) Applicable to the other FreeBSD lists though. > > On Thu, May 18, 2023 at 12:33=E2=80=AFPM Milan Obuch wrote: > > On Thu, 18 May 2023 12:08:04 +0200 > Mario Marietto wrote: > > > Hello. > >=20 > > some days ago on the FreeBSD forum someone posted this tutorial: > >=20 > > https://research.exoticsilicon.com/series/pinephone_openbsd/part_1 > >=20 > > A lot of work has been done to port NetBSD on the pinephone, even if > > the battery will not work as stated. I would like to know if this > > tutorial can be taken as a solid base to port FreeBSD instead of > > NetBSD. In other words, is FreeBSD so different from NetBSD that the > > whole procedure can't be useful at all or some part of it can be > > re-adapted easily? How much efforts and work is needed to adapt it? > >=20 > > Hi, > > at a glance, this tutorial is worth reading as it contains good > overview of the whole process. The basics are there. Note it is using > *OpenBSD*, not *NetBSD* as you wrote, but this is just oversight I > think. For FreeBSD, you should probably try first running from microSD > card, not installing to internal eMMC (SD card image for arm64/aarch64 > architecture should be a good start, needs just adding correct U-Boot > binary). > > Regards, > Milan --=20 Open source software/hardware enthusiast hackaday.io/dsl | github.com/mcusim | patreon.com/salychev From nobody Thu May 18 13:11:50 2023 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 4QMVkC0wdPz4BYVN for ; Thu, 18 May 2023 13:12:03 +0000 (UTC) (envelope-from eduardo@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 4QMVkC0ltxz45rV for ; Thu, 18 May 2023 13:12:03 +0000 (UTC) (envelope-from eduardo@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1684415523; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Ysbx0A+5eWXUoTUsQEXU/y9hoOkP2NVJ4zfEDEQw/Is=; b=APOhfKDvhZGXEhTBk4t2XKKDEYyl/l4BnIb2KqRssQPxLdg04ODoo0S/e+pk5KPgV7F0oJ Ipr0ej5qUIFO2s+f4UlE+sLxxy5XvT8ESl5razOv4/dwtGNry8w3TQFlusPiEx9e29jY6Q 7ZY8fsJf0QzLXe3ZheD/hZZyAbp9DyZJ1vdhArUNI9EJdFqFIpzUWbsazjnis4ZXAway03 TKU+uQUbciAsQBOyIoxY7hxdlSe4kE3zIFzw9jCL+mGFDIdbiRs4YlWlez3Ny+M4GoNhjD Q0DyzvlZzQHSlRdzxPiQXuEOpxIbEII4Bbdg3RCpz3LxQRxlY7oBrHbn7wIyig== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1684415523; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Ysbx0A+5eWXUoTUsQEXU/y9hoOkP2NVJ4zfEDEQw/Is=; b=bacBCpZiKXMCpIc9B/UVGX6jr0iI2dcQz4kErRWDT/DF3+w5o7Xm3CqcoV0rV0VhDwNSYc SS82GrSQ2P6NbvLlxoJg+QwSkuZSCpZPgZ399Ia1s4DkcJStV9abMAH8tISn5M1sO1Zive rAwwUqH1M16INGttSUZ+IeUXjm+Qu8eh0D03uXvSWWqKy5jdnIqoDG7hhe34mP1aGXislu COrZ6z36v05KYAULPbOfES7q7GEesf+EtZzrjimtHluqHhYGkkOVMmtSM9q31VNov/Si3s 92EPHikU/9k6bFk8iOTlyg3KO1QaCj4f8AQBxgEayge9a59T/wyKCrE6mONv5w== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1684415523; a=rsa-sha256; cv=none; b=rAPplGfbwgG3KEbH5CXfHgBxlPNX2/Q2+PxTRrKOdutOF1RPZiKXvEWy+qmkjF/TvTTHtw B+gbbxdbzBH2acR6EUDRamYgqurlFAhuGaQfHCYtbB79WLpJL7Ix8m3dTHr0J5Z/pZgBYJ gXII6sBlbs12ePAyVohRByJQK6JGFUxJNgPUYW8Ih6AMrOe5MCHrl1Nlp7lrc4j0t+/rVg M22fDiQAN7R70dqu9LJqwytxq0FivO0WmuoXGXKZG18LZBo6KNEU4bLyLoxsK20Onba6Xt OtukfmI1rTDXjDrkFNydwv9EhmgDzBFGa6hEfG6i+P2y8WoDtFpBD0/ZUFN6tg== Received: from mail-pg1-f179.google.com (mail-pg1-f179.google.com [209.85.215.179]) (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)) (Authenticated sender: eduardo) by smtp.freebsd.org (Postfix) with ESMTPSA id 4QMVkB6g4DzPWj for ; Thu, 18 May 2023 13:12:02 +0000 (UTC) (envelope-from eduardo@freebsd.org) Received: by mail-pg1-f179.google.com with SMTP id 41be03b00d2f7-53033a0b473so1369379a12.0 for ; Thu, 18 May 2023 06:12:02 -0700 (PDT) X-Gm-Message-State: AC+VfDzBc/G18mWQDPDeAZjTy5B1IqAt0nQ2qg0sfVuD9L/3a5MxEmf1 Vmmft3FFfIDlQSCfhJnpvjeDdHDFMsu09o9HIlg= X-Google-Smtp-Source: ACHHUZ4JkUOpps9a50ztAha82B1F8Iqwm6OSEt01gzzNEf/+DHqyt5SE6AJG30WarrfhKMgWz2CqsILg8zJjcPdyXfM= X-Received: by 2002:a17:902:7fc9:b0:1ac:8062:4f31 with SMTP id t9-20020a1709027fc900b001ac80624f31mr2146019plb.37.1684415521921; Thu, 18 May 2023 06:12:01 -0700 (PDT) List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 References: <77CD0716-3BC8-47EB-8743-F2BD9CA43D31@yahoo.com> <432A1A16-9FE5-4339-AB38-8F3E03A5D4EF@yahoo.com> In-Reply-To: From: Nuno Teixeira Date: Thu, 18 May 2023 14:11:50 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Raspberry Pi POE+ hat overlay To: Mark Millard Cc: Doug Rabson , freebsd-arm@freebsd.org Content-Type: multipart/alternative; boundary="000000000000d6a20e05fbf78c04" X-ThisMailContainsUnwantedMimeParts: N --000000000000d6a20e05fbf78c04 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable (...) Found a nice table of overvoltage at https://www.qengineering.eu/overclocking-the-raspberry-pi-4.html (also, I found too some advices that over_voltage not needed to be set in newer firmwares. Later I will test it on raspberry linux without setting it). I'm at poudriere building www/node18 with with -J4 cores and freq from 1500->2000 temperature changes from ~46C->~57C 4 heatsinks and a case fan. I'm so happy! Thanks! Nuno Teixeira escreveu no dia quinta, 18/05/2023 =C3= =A0(s) 13:48: > Hello Mark! > > Indeed, voltage was the missing bit! > > I'm trying to setup 1800 as default now for revs >=3D 1.4 following > https://www.raspberrypi.com/news/bullseye-bonus-1-8ghz-raspberry-pi-4/ > that only talk about setting arm_freq=3D1800 but doesn't mention to adjus= t > voltage. > It was nice that raspberry tell us what voltage exacly value they use for > new default 1800. > > What I've got now is: > > [pi4] > over_voltage=3D6 > arm_freq=3D2000 > sdram_freq_min=3D3200 > ### force_turbo=3D1 > > My tests shows that we don't need force_turbo=3D1 for a normal running an= d > system do an auto 600 -> 2000 change when needed. Thats nice. > Also, arm_boost=3D1 with force_turbo or not, is ignored. > > sdram_freq and sdram_freq_min are set to 3200 by default, so I think I > will not need sdram_freq_min=3D3200 here. > > The only thing that I can't understand is how to calculate voltage: > > over_voltage: 0 (1.35V, 1.2V on Raspberry Pi 1) ??? > ( https://www.raspberrypi.com/documentation/computers/config_txt.html ) > > Also, "7. Take it to the max" ( > https://magpi.raspberrypi.com/articles/how-to-overclock-raspberry-pi-4 ): > > over_voltage=3D6 (?) > arm_freq=3D2147 > gpu_freq=3D750 > > Thanks, > > > Mark Millard escreveu no dia quinta, 18/05/2023 =C3= =A0(s) > 11:57: > >> On May 18, 2023, at 01:29, Nuno Teixeira wrote: >> >> > Confirmed that arm_boost is enable by default on rpi4 rev >=3D 1.4 as = I >> checked with htop. >> > >> > Also, tested arm_freq=3D1800 and it crashes FreeBSD around initializin= g >> console/video and detecting mouse. >> >> Overclocking by setting the arm_freq directly involves also >> managing over_voltage explicitly, such as: >> >> over_voltage=3D6 >> >> A sequence I use (and have used for a long time) is: >> >> [pi4] >> over_voltage=3D6 >> arm_freq=3D2000 >> sdram_freq_min=3D3200 >> force_turbo=3D1 >> >> But each RPi4B has heatsinks, a case with a fan, >> and a power supply rated for 5.1V 3.5A (so: has >> some extra margin). >> >> But the range of RPi4B's span Rev 1.1, Rev 1.4, >> and Rev 1.5, a mix of 4 GiByte RAM and 8 GiByte >> RAM models. All use those settings. >> >> As I understand, arm_boost implicitly does the >> extra things required for its implicit frequency, >> unlike assigning arm_freq or the like. >> >> If force_turbo is not used, it can be that: >> >> # >> # Local addition that avoids USB3 SSD boot failures that look like: >> # uhub_reattach_port: port ? reset failed, error=3DUSB_ERR_TIMEOUT >> # uhub_reattach_port: device problem (USB_ERR_TIMEOUT), disabling port= ? >> initial_turbo=3D60 >> >> is required for USB based booting. But this also >> gets into if the notation is supported or not for >> the firmware vintage used. >> >> The initial_turbo use happens to avoid frequency >> variability during boot and it appears that FreeBSD >> does not necessarily tolerate such variability in >> that time frame. >> >> Also: I happen to have USB3 boot media for which use >> of usb_pgood_delay=3D2000 is sufficient but without >> some such in/for U-Boot, U-Boot has problems >> recognizing the device (before FreeBSD is even >> involved). I build the U-Boot port with the >> assignment built in. >> >> > As linux config.txt says: >> > --- >> > [pi4] >> > # Run as fast as firmware / board allows >> > arm_boost=3D1 >> > --- >> > firmware must be updated to support this feature for sure. >> >> I'm not aware of a dated list of when the various >> config.txt notations were first supported (firmware >> version). This makes it messier to use the web's >> published information, if one is using the firmware >> vintage that FreeBSD has in its port for the >> firmware. >> >> The notation that I use has been around for a long >> time. >> >> > Cheers, >> > >> > Nuno Teixeira escreveu no dia quarta, 17/05/2023 >> =C3=A0(s) 14:08: >> > (...) >> > >> > I was meant using 13.2 not 12.3 :) >> > >> > Doug Rabson escreveu no dia quarta, 17/05/2023 =C3=A0= (s) >> 13:47: >> > I'm not sure about 12.3 either - you could try with 13.2 and see if >> that makes a difference. >> > >> > On Wed, 17 May 2023 at 13:45, Nuno Teixeira >> wrote: >> > Hey, >> > >> > Ok. I'm new to rpi4 and arm in general but tomorrow I will force >> 'arm_freq=3D1800' again just to see it it crashes again. >> > I will check too what values linux shows. >> > >> > I don't know if firmware/uboot version included in 12.3 supports this >> feature. >> > >> > Cheers, >> > >> > Doug Rabson escreveu no dia quarta, 17/05/2023 =C3=A0= (s) >> 13:11: >> > Hi Nuno, >> > >> > I'm not sure where to start - I just happened to notice in the >> documentation here: >> https://www.raspberrypi.com/documentation/computers/config_txt.html that >> the cpu frequency Pi4B R1.4 was listed as 1800 if arm_boot=3D1 so I trie= d it. >> > >> > Doug. >> > >> > >> > >> > On Wed, 17 May 2023 at 11:11, Nuno Teixeira >> wrote: >> > Hello Doug, >> > >> > I have too a 1.5 rpi but arm_boost=3D1 isn't doing anything, htop show= s >> 1500Mhz when doing something intensive. >> > I'm running 13.2 stable >> > >> > Do I missing something? >> > >> > Could you take a look at my setup? >> > >> > Thanks, >> > >> > Doug Rabson escreveu no dia ter=C3=A7a, 16/05/2023 = =C3=A0(s) >> 17:19: >> > >> > On Sat, 13 May 2023 at 13:45, Doug Rabson wrote: >> > I was able to build an updated rpi-firmware port based on 1.20210805 >> and this boots successfully on pi400 as well as rpi4. With this, I can l= oad >> the rpi-poe-plus overlay and I just need to try and reverse engineer the >> undocumented mailbox API by reading the Linux code. >> > >> > I have a first approximation of a fan driver which works with the >> 1.20210805 firmware (actually, I substituted rpi-poe-plus.dtbo from >> 1.20210831 which just changes the fan levels for the POE+). I'm testing >> with an rpi4B rev 1.5 with 'make -j4 buildworld' and the fan is keeping = the >> cpu temperature below 65 degrees which is nice, especially since I set >> arm_boost=3D1 in config.txt which boosts the cpu frequency up to 1800 fo= r >> this board. >> > >> > Does anyone have a pointer to the problem with firmware later than >> 20210805? Would it make any kind of sense to try to get the fix into >> releng/13.2 as an errata? >> > >> >> >> =3D=3D=3D >> Mark Millard >> marklmi at yahoo.com >> >> > > -- > Nuno Teixeira > FreeBSD Committer (ports) > --=20 Nuno Teixeira FreeBSD Committer (ports) --000000000000d6a20e05fbf78c04 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
(...)


(also, I found too some advices that ov= er_voltage not needed to be set in newer firmwares. Later I will test it on= raspberry linux without setting it).

I'm at p= oudriere building www/node18 with with -J4 cores and freq from 1500->200= 0 temperature changes from ~46C->~57C
4 heatsinks and a case f= an.

I'm so happy!

Tha= nks!

Nuno Teixeira <ed= uardo@freebsd.org> escreveu no dia quinta, 18/05/2023 =C3=A0(s) 13:4= 8:
Hello Mark!

Indeed, voltage was the missi= ng bit!

I'm trying to setup 1800 as default no= w for revs >=3D 1.4 following https://www.rasp= berrypi.com/news/bullseye-bonus-1-8ghz-raspberry-pi-4/ that only talk a= bout setting arm_freq=3D1800 but doesn't mention to adjust voltage.
It was nice that raspberry tell us what voltage exacly value they us= e for new default 1800.

What I've got now = is:

[pi4]
over_voltage=3D6
arm_freq=3D2000
sdram_freq_min=3D3200
### force_turbo=3D1

My tests shows that we don'= ;t need force_turbo=3D1 for a normal running and system do an auto 600 ->= ; 2000 change when needed. Thats nice.
Also, arm_boost=3D1 wi= th force_turbo or not, is ignored.

sdram_freq and = sdram_freq_min are set to 3200 by default, so I think I will not need sdram= _freq_min=3D3200 here.

The only thing that I can&#= 39;t understand is how to calculate voltage:

over_= voltage: 0 (1.35V, 1.2V on Raspberry Pi 1) ???


over_voltage=3D6 (?)
arm_freq= =3D2147
gpu_freq=3D750

Thanks,


Mark Millard <m= arklmi@yahoo.com> escreveu no dia quinta, 18/05/2023 =C3=A0(s) 11:57= :
On May 18, 202= 3, at 01:29, Nuno Teixeira <eduardo@freebsd.org> wrote:

> Confirmed that arm_boost is enable by default on rpi4 rev >=3D 1.4 = as I checked with htop.
>
> Also, tested arm_freq=3D1800 and it crashes FreeBSD around initializin= g console/video and detecting mouse.

Overclocking by setting the arm_freq directly involves also
managing over_voltage explicitly, such as:

over_voltage=3D6

A sequence I use (and have used for a long time) is:

[pi4]
over_voltage=3D6
arm_freq=3D2000
sdram_freq_min=3D3200
force_turbo=3D1

But each RPi4B has heatsinks, a case with a fan,
and a power supply rated for 5.1V 3.5A (so: has
some extra margin).

But the range of RPi4B's span Rev 1.1, Rev 1.4,
and Rev 1.5, a mix of 4 GiByte RAM and 8 GiByte
RAM models. All use those settings.

As I understand, arm_boost implicitly does the
extra things required for its implicit frequency,
unlike assigning arm_freq or the like.

If force_turbo is not used, it can be that:

#
# Local addition that avoids USB3 SSD boot failures that look like:
#=C2=A0 =C2=A0uhub_reattach_port: port ? reset failed, error=3DUSB_ERR_TIME= OUT
#=C2=A0 =C2=A0uhub_reattach_port: device problem (USB_ERR_TIMEOUT), disabli= ng port ?
initial_turbo=3D60

is required for USB based booting. But this also
gets into if the notation is supported or not for
the firmware vintage used.

The initial_turbo use happens to avoid frequency
variability during boot and it appears that FreeBSD
does not necessarily tolerate such variability in
that time frame.

Also: I happen to have USB3 boot media for which use
of usb_pgood_delay=3D2000 is sufficient but without
some such in/for U-Boot, U-Boot has problems
recognizing the device (before FreeBSD is even
involved). I build the U-Boot port with the
assignment built in.

> As linux config.txt says:
> ---
> [pi4]
> # Run as fast as firmware / board allows
> arm_boost=3D1
> ---
> firmware must be updated to support this feature for sure.

I'm not aware of a dated list of when the various
config.txt notations were first supported (firmware
version). This makes it messier to use the web's
published information, if one is using the firmware
vintage that FreeBSD has in its port for the
firmware.

The notation that I use has been around for a long
time.

> Cheers,
>
> Nuno Teixeira <eduardo@freebsd.org> escreveu no dia quarta, 17/05/2023 =C3=A0(= s) 14:08:
> (...)
>
> I was meant using 13.2 not 12.3 :)
>
> Doug Rabson <df= r@rabson.org> escreveu no dia quarta, 17/05/2023 =C3=A0(s) 13:47: > I'm not sure about 12.3 either - you could try with 13.2 and see i= f that makes a difference.
>
> On Wed, 17 May 2023 at 13:45, Nuno Teixeira <eduardo@freebsd.org> wrote:
> Hey,
>
> Ok. I'm new to rpi4 and arm in general but tomorrow I will force &= #39;arm_freq=3D1800' again just to see it it crashes again.
> I will check too what values linux shows.
>
> I don't know if firmware/uboot version included in 12.3 supports t= his feature.
>
> Cheers,
>
> Doug Rabson <df= r@rabson.org> escreveu no dia quarta, 17/05/2023 =C3=A0(s) 13:11: > Hi Nuno,
>
> I'm not sure where to start - I just happened to notice in the doc= umentation here: https://www.rasp= berrypi.com/documentation/computers/config_txt.html that the cpu freque= ncy Pi4B R1.4 was listed as 1800 if arm_boot=3D1 so I tried it.
>
> Doug.
>
>
>
> On Wed, 17 May 2023 at 11:11, Nuno Teixeira <eduardo@freebsd.org> wrote:
> Hello Doug,
>
> I have too a 1.5 rpi but arm_boost=3D1 isn't doing anything, htop = shows 1500Mhz when doing something intensive.
> I'm running 13.2 stable
>
> Do I missing something?
>
> Could you take a look at my setup?
>
> Thanks,
>
> Doug Rabson <df= r@rabson.org> escreveu no dia ter=C3=A7a, 16/05/2023 =C3=A0(s) 17:19= :
>
> On Sat, 13 May 2023 at 13:45, Doug Rabson <dfr@rabson.org> wrote:
> I was able to build an updated rpi-firmware port based on 1.20210805 a= nd this boots successfully on pi400 as well as rpi4. With this, I can load = the rpi-poe-plus overlay and I just need to try and reverse engineer the un= documented mailbox API by reading the Linux code.
>
> I have a first approximation of a fan driver which works with the 1.20= 210805 firmware (actually, I substituted rpi-poe-plus.dtbo from 1.20210831 = which just changes the fan levels for the POE+). I'm testing with an rp= i4B rev 1.5 with 'make -j4 buildworld' and the fan is keeping the c= pu temperature below 65 degrees which is nice, especially since I set arm_b= oost=3D1 in config.txt which boosts the cpu frequency up to 1800 for this b= oard.
>
> Does anyone have a pointer to the problem with firmware later than 202= 10805? Would it make any kind of sense to try to get the fix into releng/13= .2 as an errata?
>


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



--
Nuno TeixeiraFreeBSD Committer (ports)


--
Nuno Teixeira
FreeBSD Committ= er (ports)
--000000000000d6a20e05fbf78c04-- From nobody Thu May 18 13:21:29 2023 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 4QMVxL4g29z4BYYT for ; Thu, 18 May 2023 13:21:42 +0000 (UTC) (envelope-from eduardo@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 4QMVxL2v00z46x2 for ; Thu, 18 May 2023 13:21:42 +0000 (UTC) (envelope-from eduardo@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1684416102; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=oz0QA6GZMbvTCzEO5sMsxz5VQIrOw4Y6cvepa5UayIE=; b=Q+DK88swdQS75GfFYwExoYbdNUdN4NJwn2+VQmQtN2Kjz77k3yjfKz2vgIIhJEtjztKpR8 NNdyQ21T3UjITI6viRiGaUes9etlW4lhxuX2/A/6dhMxuvtlbBo/JKyICY/NHxpK0dM7HV EUfda5+B5pSJWdbLQW4gKwRPTnSw8slQddI0Tz6ziqyb1hC/BGGhX8pv/bFiFVKAGjfTrp crXFfjHpJUhWvVknKQWHncvR54jLhH7BI6yPBt0e7W831mFCdzo+nytIkVM9IqhfjdWt6K UmldoAYnfEaogQ/vnWYRyCmf6ZCnizFI9/+N7IWX1Lq6N6KMeaUkoxMzi7Nxsw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1684416102; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=oz0QA6GZMbvTCzEO5sMsxz5VQIrOw4Y6cvepa5UayIE=; b=Zp6aZhRWDl21XIQeQft0K6Dtl5eESf6qJJ7Z6OIJKT1EpmvgVEQLde58ubUQzcDAqkNv2F ZNQnWbOIqnvXUETMvq3JJBAx58kXpl09YTAcQzJfWiTzRGYEqCRzwdqpSWFU5dRBqPKNis XNoD9tHbg6u1ieQXzxOeNiKH3ZlBfT6+KH9ZwEyDK1RPy/O6BdGt3yOp5/IPyLHVjkZ/o6 Ax2WSaFLsg/usB1Lc+xOTPrj9csmubjqYwYi0bXw28LFGtGk1H3L4B+3i5jWQ0+zexErTK dEUOcHRTyq3ire/ASD5kIdNFmpdU9SwL6Ix8e7BgZPRfVis7Cu4jHW4Xnt2d3g== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1684416102; a=rsa-sha256; cv=none; b=GhK7tJ7ZgELi2///w5pQjoKFrrfpywRjwYT45xCbA/lAg4GDmItnrCVefBbAgYsiVDb5Dr iXwCsVnK1qbQZcz/AEJJUfIiNjCF0a9cnY7+zsReF3sHQnzYEzetIvGFerzCJHfHugxHqU 6qepH2CpaupOSITYKNnVtfOVR80165bwasaXhBrOO2RXSGGI4orwHpvmx5qASC514dOBoP AUQREew1l5zdi91HdPrJJi3BUmCLi/CnY7y4MQQK9ulLYwRV1Z3olFJGk3GroOgmhJyltO sPt4gh4/jqaldTeXoC+F3z8m7/fZ3Ut8sf5sxMi+1tYyRBkAI8eqDtlhWdiVZg== Received: from mail-pl1-f179.google.com (mail-pl1-f179.google.com [209.85.214.179]) (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)) (Authenticated sender: eduardo) by smtp.freebsd.org (Postfix) with ESMTPSA id 4QMVxK6zhHzQ68 for ; Thu, 18 May 2023 13:21:41 +0000 (UTC) (envelope-from eduardo@freebsd.org) Received: by mail-pl1-f179.google.com with SMTP id d9443c01a7336-1aaf21bb427so15059265ad.1 for ; Thu, 18 May 2023 06:21:41 -0700 (PDT) X-Gm-Message-State: AC+VfDw4MryVeCZ9zlzL+r0ih+6N0mWjCjp5DaT/mMuKQUCtKziijjD0 iyKRItuSjAxRQKYPG8WwQclbvoZgMdzD1k7W9EI= X-Google-Smtp-Source: ACHHUZ7c1Tfgj0ksuJAE+513ta46BmnlKlG04Skt4FXVhlD1ND1QQqgCni5erHNJKy1v/zmYGEcmq46JMD/ghZoJf08= X-Received: by 2002:a17:903:492:b0:1ae:7421:82b5 with SMTP id jj18-20020a170903049200b001ae742182b5mr752565plb.45.1684416100982; Thu, 18 May 2023 06:21:40 -0700 (PDT) List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 References: <77CD0716-3BC8-47EB-8743-F2BD9CA43D31@yahoo.com> <432A1A16-9FE5-4339-AB38-8F3E03A5D4EF@yahoo.com> In-Reply-To: From: Nuno Teixeira Date: Thu, 18 May 2023 14:21:29 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Raspberry Pi POE+ hat overlay To: Mark Millard Cc: Doug Rabson , freebsd-arm@freebsd.org Content-Type: multipart/alternative; boundary="0000000000005a6a4d05fbf7af32" X-ThisMailContainsUnwantedMimeParts: N --0000000000005a6a4d05fbf7af32 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable (...) Tomorrow I will take it to the max: over_voltage=3D6 arm_freq=3D2147 gpu_freq=3D750 :) Nuno Teixeira escreveu no dia quinta, 18/05/2023 =C3= =A0(s) 14:11: > (...) > > Found a nice table of overvoltage at > https://www.qengineering.eu/overclocking-the-raspberry-pi-4.html > > (also, I found too some advices that over_voltage not needed to be set in > newer firmwares. Later I will test it on raspberry linux without setting > it). > > I'm at poudriere building www/node18 with with -J4 cores and freq from > 1500->2000 temperature changes from ~46C->~57C > 4 heatsinks and a case fan. > > I'm so happy! > > Thanks! > > Nuno Teixeira escreveu no dia quinta, 18/05/2023 > =C3=A0(s) 13:48: > >> Hello Mark! >> >> Indeed, voltage was the missing bit! >> >> I'm trying to setup 1800 as default now for revs >=3D 1.4 following >> https://www.raspberrypi.com/news/bullseye-bonus-1-8ghz-raspberry-pi-4/ >> that only talk about setting arm_freq=3D1800 but doesn't mention to adju= st >> voltage. >> It was nice that raspberry tell us what voltage exacly value they use fo= r >> new default 1800. >> >> What I've got now is: >> >> [pi4] >> over_voltage=3D6 >> arm_freq=3D2000 >> sdram_freq_min=3D3200 >> ### force_turbo=3D1 >> >> My tests shows that we don't need force_turbo=3D1 for a normal running a= nd >> system do an auto 600 -> 2000 change when needed. Thats nice. >> Also, arm_boost=3D1 with force_turbo or not, is ignored. >> >> sdram_freq and sdram_freq_min are set to 3200 by default, so I think I >> will not need sdram_freq_min=3D3200 here. >> >> The only thing that I can't understand is how to calculate voltage: >> >> over_voltage: 0 (1.35V, 1.2V on Raspberry Pi 1) ??? >> ( https://www.raspberrypi.com/documentation/computers/config_txt.html ) >> >> Also, "7. Take it to the max" ( >> https://magpi.raspberrypi.com/articles/how-to-overclock-raspberry-pi-4 )= : >> >> over_voltage=3D6 (?) >> arm_freq=3D2147 >> gpu_freq=3D750 >> >> Thanks, >> >> >> Mark Millard escreveu no dia quinta, 18/05/2023 =C3= =A0(s) >> 11:57: >> >>> On May 18, 2023, at 01:29, Nuno Teixeira wrote: >>> >>> > Confirmed that arm_boost is enable by default on rpi4 rev >=3D 1.4 as= I >>> checked with htop. >>> > >>> > Also, tested arm_freq=3D1800 and it crashes FreeBSD around initializi= ng >>> console/video and detecting mouse. >>> >>> Overclocking by setting the arm_freq directly involves also >>> managing over_voltage explicitly, such as: >>> >>> over_voltage=3D6 >>> >>> A sequence I use (and have used for a long time) is: >>> >>> [pi4] >>> over_voltage=3D6 >>> arm_freq=3D2000 >>> sdram_freq_min=3D3200 >>> force_turbo=3D1 >>> >>> But each RPi4B has heatsinks, a case with a fan, >>> and a power supply rated for 5.1V 3.5A (so: has >>> some extra margin). >>> >>> But the range of RPi4B's span Rev 1.1, Rev 1.4, >>> and Rev 1.5, a mix of 4 GiByte RAM and 8 GiByte >>> RAM models. All use those settings. >>> >>> As I understand, arm_boost implicitly does the >>> extra things required for its implicit frequency, >>> unlike assigning arm_freq or the like. >>> >>> If force_turbo is not used, it can be that: >>> >>> # >>> # Local addition that avoids USB3 SSD boot failures that look like: >>> # uhub_reattach_port: port ? reset failed, error=3DUSB_ERR_TIMEOUT >>> # uhub_reattach_port: device problem (USB_ERR_TIMEOUT), disabling por= t >>> ? >>> initial_turbo=3D60 >>> >>> is required for USB based booting. But this also >>> gets into if the notation is supported or not for >>> the firmware vintage used. >>> >>> The initial_turbo use happens to avoid frequency >>> variability during boot and it appears that FreeBSD >>> does not necessarily tolerate such variability in >>> that time frame. >>> >>> Also: I happen to have USB3 boot media for which use >>> of usb_pgood_delay=3D2000 is sufficient but without >>> some such in/for U-Boot, U-Boot has problems >>> recognizing the device (before FreeBSD is even >>> involved). I build the U-Boot port with the >>> assignment built in. >>> >>> > As linux config.txt says: >>> > --- >>> > [pi4] >>> > # Run as fast as firmware / board allows >>> > arm_boost=3D1 >>> > --- >>> > firmware must be updated to support this feature for sure. >>> >>> I'm not aware of a dated list of when the various >>> config.txt notations were first supported (firmware >>> version). This makes it messier to use the web's >>> published information, if one is using the firmware >>> vintage that FreeBSD has in its port for the >>> firmware. >>> >>> The notation that I use has been around for a long >>> time. >>> >>> > Cheers, >>> > >>> > Nuno Teixeira escreveu no dia quarta, >>> 17/05/2023 =C3=A0(s) 14:08: >>> > (...) >>> > >>> > I was meant using 13.2 not 12.3 :) >>> > >>> > Doug Rabson escreveu no dia quarta, 17/05/2023 =C3= =A0(s) >>> 13:47: >>> > I'm not sure about 12.3 either - you could try with 13.2 and see if >>> that makes a difference. >>> > >>> > On Wed, 17 May 2023 at 13:45, Nuno Teixeira >>> wrote: >>> > Hey, >>> > >>> > Ok. I'm new to rpi4 and arm in general but tomorrow I will force >>> 'arm_freq=3D1800' again just to see it it crashes again. >>> > I will check too what values linux shows. >>> > >>> > I don't know if firmware/uboot version included in 12.3 supports this >>> feature. >>> > >>> > Cheers, >>> > >>> > Doug Rabson escreveu no dia quarta, 17/05/2023 =C3= =A0(s) >>> 13:11: >>> > Hi Nuno, >>> > >>> > I'm not sure where to start - I just happened to notice in the >>> documentation here: >>> https://www.raspberrypi.com/documentation/computers/config_txt.html >>> that the cpu frequency Pi4B R1.4 was listed as 1800 if arm_boot=3D1 so = I >>> tried it. >>> > >>> > Doug. >>> > >>> > >>> > >>> > On Wed, 17 May 2023 at 11:11, Nuno Teixeira >>> wrote: >>> > Hello Doug, >>> > >>> > I have too a 1.5 rpi but arm_boost=3D1 isn't doing anything, htop sho= ws >>> 1500Mhz when doing something intensive. >>> > I'm running 13.2 stable >>> > >>> > Do I missing something? >>> > >>> > Could you take a look at my setup? >>> > >>> > Thanks, >>> > >>> > Doug Rabson escreveu no dia ter=C3=A7a, 16/05/2023 = =C3=A0(s) >>> 17:19: >>> > >>> > On Sat, 13 May 2023 at 13:45, Doug Rabson wrote: >>> > I was able to build an updated rpi-firmware port based on 1.20210805 >>> and this boots successfully on pi400 as well as rpi4. With this, I can = load >>> the rpi-poe-plus overlay and I just need to try and reverse engineer th= e >>> undocumented mailbox API by reading the Linux code. >>> > >>> > I have a first approximation of a fan driver which works with the >>> 1.20210805 firmware (actually, I substituted rpi-poe-plus.dtbo from >>> 1.20210831 which just changes the fan levels for the POE+). I'm testing >>> with an rpi4B rev 1.5 with 'make -j4 buildworld' and the fan is keeping= the >>> cpu temperature below 65 degrees which is nice, especially since I set >>> arm_boost=3D1 in config.txt which boosts the cpu frequency up to 1800 f= or >>> this board. >>> > >>> > Does anyone have a pointer to the problem with firmware later than >>> 20210805? Would it make any kind of sense to try to get the fix into >>> releng/13.2 as an errata? >>> > >>> >>> >>> =3D=3D=3D >>> Mark Millard >>> marklmi at yahoo.com >>> >>> >> >> -- >> Nuno Teixeira >> FreeBSD Committer (ports) >> > > > -- > Nuno Teixeira > FreeBSD Committer (ports) > --=20 Nuno Teixeira FreeBSD Committer (ports) --0000000000005a6a4d05fbf7af32 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
(...)

Tomorrow I will take i= t to the max:

over_voltage=3D6
arm_freq=3D2147<= br>gpu_freq=3D750

:)

Nuno Teixeira <eduardo@freebsd.org> escreveu n= o dia quinta, 18/05/2023 =C3=A0(s) 14:11:
(...)

<= div>Found a nice table of overvoltage at https://www.qe= ngineering.eu/overclocking-the-raspberry-pi-4.html

=
(also, I found too some advices that over_voltage not needed to be set= in newer firmwares. Later I will test it on raspberry linux without settin= g it).

I'm at poudriere building www/node18 wi= th with -J4 cores and freq from 1500->2000 temperature changes from ~46C= ->~57C
4 heatsinks and a case fan.

I&= #39;m so happy!

Thanks!

Nuno Teixeira &l= t;eduardo@freebsd.= org> escreveu no dia quinta, 18/05/2023 =C3=A0(s) 13:48:
Hello= Mark!

Indeed, voltage was the missing bit!
<= div>
I'm trying to setup 1800 as default now for revs >= ;=3D 1.4 following https://www.raspberrypi.com/ne= ws/bullseye-bonus-1-8ghz-raspberry-pi-4/ that only talk about setting a= rm_freq=3D1800 but doesn't mention to adjust voltage.
It was = nice that raspberry tell us what voltage exacly value they use for new defa= ult 1800.

What I've got now is:
=
[pi4]
over_voltage=3D6
arm_freq=3D2000
sdram_freq_min=3D3200
### force_turbo=3D1

My tests shows that we don'= ;t need force_turbo=3D1 for a normal running and system do an auto 600 ->= ; 2000 change when needed. Thats nice.
Also, arm_boost=3D1 wi= th force_turbo or not, is ignored.

sdram_freq and = sdram_freq_min are set to 3200 by default, so I think I will not need sdram= _freq_min=3D3200 here.

The only thing that I can&#= 39;t understand is how to calculate voltage:

over_= voltage: 0 (1.35V, 1.2V on Raspberry Pi 1) ???


over_voltage=3D6 (?)
arm_freq= =3D2147
gpu_freq=3D750

Thanks,


Mark Millard <m= arklmi@yahoo.com> escreveu no dia quinta, 18/05/2023 =C3=A0(s) 11:57= :
On May 18, 202= 3, at 01:29, Nuno Teixeira <eduardo@freebsd.org> wrote:

> Confirmed that arm_boost is enable by default on rpi4 rev >=3D 1.4 = as I checked with htop.
>
> Also, tested arm_freq=3D1800 and it crashes FreeBSD around initializin= g console/video and detecting mouse.

Overclocking by setting the arm_freq directly involves also
managing over_voltage explicitly, such as:

over_voltage=3D6

A sequence I use (and have used for a long time) is:

[pi4]
over_voltage=3D6
arm_freq=3D2000
sdram_freq_min=3D3200
force_turbo=3D1

But each RPi4B has heatsinks, a case with a fan,
and a power supply rated for 5.1V 3.5A (so: has
some extra margin).

But the range of RPi4B's span Rev 1.1, Rev 1.4,
and Rev 1.5, a mix of 4 GiByte RAM and 8 GiByte
RAM models. All use those settings.

As I understand, arm_boost implicitly does the
extra things required for its implicit frequency,
unlike assigning arm_freq or the like.

If force_turbo is not used, it can be that:

#
# Local addition that avoids USB3 SSD boot failures that look like:
#=C2=A0 =C2=A0uhub_reattach_port: port ? reset failed, error=3DUSB_ERR_TIME= OUT
#=C2=A0 =C2=A0uhub_reattach_port: device problem (USB_ERR_TIMEOUT), disabli= ng port ?
initial_turbo=3D60

is required for USB based booting. But this also
gets into if the notation is supported or not for
the firmware vintage used.

The initial_turbo use happens to avoid frequency
variability during boot and it appears that FreeBSD
does not necessarily tolerate such variability in
that time frame.

Also: I happen to have USB3 boot media for which use
of usb_pgood_delay=3D2000 is sufficient but without
some such in/for U-Boot, U-Boot has problems
recognizing the device (before FreeBSD is even
involved). I build the U-Boot port with the
assignment built in.

> As linux config.txt says:
> ---
> [pi4]
> # Run as fast as firmware / board allows
> arm_boost=3D1
> ---
> firmware must be updated to support this feature for sure.

I'm not aware of a dated list of when the various
config.txt notations were first supported (firmware
version). This makes it messier to use the web's
published information, if one is using the firmware
vintage that FreeBSD has in its port for the
firmware.

The notation that I use has been around for a long
time.

> Cheers,
>
> Nuno Teixeira <eduardo@freebsd.org> escreveu no dia quarta, 17/05/2023 =C3=A0(= s) 14:08:
> (...)
>
> I was meant using 13.2 not 12.3 :)
>
> Doug Rabson <df= r@rabson.org> escreveu no dia quarta, 17/05/2023 =C3=A0(s) 13:47: > I'm not sure about 12.3 either - you could try with 13.2 and see i= f that makes a difference.
>
> On Wed, 17 May 2023 at 13:45, Nuno Teixeira <eduardo@freebsd.org> wrote:
> Hey,
>
> Ok. I'm new to rpi4 and arm in general but tomorrow I will force &= #39;arm_freq=3D1800' again just to see it it crashes again.
> I will check too what values linux shows.
>
> I don't know if firmware/uboot version included in 12.3 supports t= his feature.
>
> Cheers,
>
> Doug Rabson <df= r@rabson.org> escreveu no dia quarta, 17/05/2023 =C3=A0(s) 13:11: > Hi Nuno,
>
> I'm not sure where to start - I just happened to notice in the doc= umentation here: https://www.rasp= berrypi.com/documentation/computers/config_txt.html that the cpu freque= ncy Pi4B R1.4 was listed as 1800 if arm_boot=3D1 so I tried it.
>
> Doug.
>
>
>
> On Wed, 17 May 2023 at 11:11, Nuno Teixeira <eduardo@freebsd.org> wrote:
> Hello Doug,
>
> I have too a 1.5 rpi but arm_boost=3D1 isn't doing anything, htop = shows 1500Mhz when doing something intensive.
> I'm running 13.2 stable
>
> Do I missing something?
>
> Could you take a look at my setup?
>
> Thanks,
>
> Doug Rabson <df= r@rabson.org> escreveu no dia ter=C3=A7a, 16/05/2023 =C3=A0(s) 17:19= :
>
> On Sat, 13 May 2023 at 13:45, Doug Rabson <dfr@rabson.org> wrote:
> I was able to build an updated rpi-firmware port based on 1.20210805 a= nd this boots successfully on pi400 as well as rpi4. With this, I can load = the rpi-poe-plus overlay and I just need to try and reverse engineer the un= documented mailbox API by reading the Linux code.
>
> I have a first approximation of a fan driver which works with the 1.20= 210805 firmware (actually, I substituted rpi-poe-plus.dtbo from 1.20210831 = which just changes the fan levels for the POE+). I'm testing with an rp= i4B rev 1.5 with 'make -j4 buildworld' and the fan is keeping the c= pu temperature below 65 degrees which is nice, especially since I set arm_b= oost=3D1 in config.txt which boosts the cpu frequency up to 1800 for this b= oard.
>
> Does anyone have a pointer to the problem with firmware later than 202= 10805? Would it make any kind of sense to try to get the fix into releng/13= .2 as an errata?
>


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



--
Nuno TeixeiraFreeBSD Committer (ports)


--
Nuno TeixeiraFreeBSD Committer (ports)


--
Nuno Teixeira
FreeBSD Committ= er (ports)
--0000000000005a6a4d05fbf7af32-- From nobody Thu May 18 13:58:33 2023 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 4QMX9b3q7rz4Bd6S for ; Thu, 18 May 2023 14:17:23 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (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 4QMX9Z5jprz4Dsb; Thu, 18 May 2023 14:17:22 +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 34IDwXLm088857; Thu, 18 May 2023 06:58:34 -0700 (PDT) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id 34IDwX6o088856; Thu, 18 May 2023 06:58:33 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <202305181358.34IDwX6o088856@gndrsh.dnsmgr.net> Subject: Re: VirtualBox In-Reply-To: To: Alex Samorukov Date: Thu, 18 May 2023 06:58:33 -0700 (PDT) CC: Jason Bacon , 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: 4QMX9Z5jprz4Dsb X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:13868, ipnet:69.59.192.0/19, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N > VirtualBox is x86 emu. Yes, and it now runs on Mac/Arm64 as of version 7, but it is known to of shakey alpha quality. > > FreeBSD itself works very good in qemu for macos, including GUI frontend > UTM. > > On 2023/05/17 22:35, Jason Bacon wrote: > > Is anyone working on running under VirtualBox on Apple silicon? > > > > I just got a Mac Mini M1 and would be interested in contributing if > > possible. Not something I could take the lead on, though. > > -- Rod Grimes rgrimes@freebsd.org From nobody Thu May 18 15:33:24 2023 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 4QMYsQ0m8vz4BhC5 for ; Thu, 18 May 2023 15:33:30 +0000 (UTC) (envelope-from samm@freebsd.org) Received: from reindeer.net-art.cz (reindeer.net-art.cz [IPv6:2001:15e8:110:513c::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "reindeer.net-art.cz", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QMYsP5dvzz4MBt for ; Thu, 18 May 2023 15:33:29 +0000 (UTC) (envelope-from samm@freebsd.org) Authentication-Results: mx1.freebsd.org; none Received: by reindeer.net-art.cz (Postfix, from userid 65534) id 198855F188; Thu, 18 May 2023 16:33:24 +0100 (BST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on reindeer X-Spam-Level: X-Spam-Status: No, score=-1.2 required=10.0 tests=BAYES_00, RCVD_IN_DNSWL_BLOCKED,SPF_HELO_NONE,SPF_SOFTFAIL,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.2 Received: from owl.net-art.cz (unknown [IPv6:2a03:6920:0:10::101]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "owl.net-art.cz", Issuer "R3" (not verified)) by reindeer.net-art.cz (Postfix) with ESMTPS id BA2D35EEB7; Thu, 18 May 2023 16:33:23 +0100 (BST) Received: from [::1] (account samm@net-art.cz HELO webmail.net-art.cz) by owl.net-art.cz (CommuniGate Pro SMTP 6.1.20) with ESMTPA id 1809640; Thu, 18 May 2023 17:33:24 +0200 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Date: Thu, 18 May 2023 17:33:24 +0200 From: Alex Samorukov To: "Rodney W. Grimes" Cc: Jason Bacon , freebsd-arm@freebsd.org Subject: Re: VirtualBox In-Reply-To: <202305181358.34IDwX6o088856@gndrsh.dnsmgr.net> References: <202305181358.34IDwX6o088856@gndrsh.dnsmgr.net> Message-ID: <8677136eca659468ec4690727ef9cf53@freebsd.org> X-Sender: samm@freebsd.org Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4QMYsP5dvzz4MBt X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:24806, ipnet:2001:15e8::/32, country:CZ] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On 2023/05/18 15:58, Rodney W. Grimes wrote: >> VirtualBox is x86 emu. > Yes, and it now runs on Mac/Arm64 as of version 7, but it > is known to of shakey alpha quality. > But i think it still emulates x86, so probably will be damned slow. I think on MacOS using qemu is a best way to run FreeBSD, of course aarch64. I found performance very good, as well as stability. From nobody Thu May 18 17:06:59 2023 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 4QMbxd2Vtjz4BnRP for ; Thu, 18 May 2023 17:07:17 +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 4QMbxc5zQRz4X7Y for ; Thu, 18 May 2023 17:07:16 +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=1684429634; bh=pOzucLZO17FQ1tx0471f9WW9/FNII6sHTaYBwKDRJBI=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=ldXRJSO/sM68TrgJSnhJyWKIElH4gr+beWV18zxmrh3PefQXZkDc2s6HBbWH0bu8VMwZ8hkBKdnWooRlnICRMpRsKIM0H6dF5XYpg31EuT8lcQxLq+32HjPv2Ncv+/tN8yj+Py46lst+ulrYmgGVxqKgs1C2CLnt+HXKAnGZ0IwGP/FQwq4NfBejlVoPdE2/RE6An6HO0gafonp0Meel7+kD3Kz9IJno40Hk78jxkHmi7fNYMFkQBQfEaQz2lshPs2LRmhRmsKBRPS27uBJsPxmwUIUcwhZsUB2U5PweTOYM+GcAdxObGKhdC6Zfu/nVKFxK/aT5r1kLB2fzaf6/mw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1684429634; bh=rkP3acvz3Hlsbmc0+JTVpf5fvyb9SocAtSmFXkA9LjM=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=Jfgujm+7DGD9dUhVYT73LZXmC8TSP2BlAmvHVMieb3QOZ9S2lnDI0FujF+XK0K79GwfAV55Z8f75bb21Hs2MKwtGl4fE4rmGPeUdJYfE5gfLqpbpXLy8q3EnqZASWtXhJqfW3kremqBMQ9ur2bl3ApWziF7cUMIVByZl9S+T6QQ8AgFl+8ZMDw0941z9+N4SLnTUKtX4h6WY805D8k7eiz2CY1MpKTO2e45egjW0jGTnA+lVXXy0RDJgPUIfAAQmBNHHeR5VZ4dxhiG1uj3k7+gO5Lua6FX96sNAcmJQuL6/aisQD1heiavQOt5iw/IHl9MqUydATu6abu/tsmseoQ== X-YMail-OSG: WZFs4XEVM1n1HrqGpkh6BmKYOx1Mwdi9XXoOgKIrnuS5cS2e.Q7tV0yRBhXSq3S Z588SGdii6wukR0N9CkayYso21nntO218wus4yoFf9ewwIPsD_odSFwN58aGHfVqk7bEV7fkscEu wWj23H3Ktrdsx7qEMxJzc99zXpxNUnKFIxA9Z5qyClKfLjA9Py4lMuwEiI.z5PYrsgT0kzzcTkBt oHuaG8Sfj8tu12uwxOvyeu1P0_Lfh0s5fZfMdgbmX_e_MNCuLlEHFz2J_U6SQOyYY8BA3bK_CLyb HmmDMLpnaiAETsYAhdA.4nTiVXkrLP7A2yv_D83XxxBfgbK6Op_0s4L0NS2_kCJLnYG3UmFVeWkZ pZHhBbXkPlQ36sHSz6_bmJR.LNYZUHqiwXpTcY1pDRGhOva2lobfTPQu.AP6SV5RVQiqIWQ7gR4Q hKxwsjDyK1u5Lwkk2xPfb55wosdK806Bs6DaUP4AlsQFBsvuAthYpPkjZw8.wqjPLQJtzqyfQhpa pDzFG4Ec537Mv2Mx_IaSLZ8dRKVPmp1XOMIGhsMRz0NLBBRaJCd7iYg16GP2ldxjVBFTc0GzKHLE VEa91uEtbi4lbdUm1B8uYXf8Wcak2usGAB06q9EBPJNnIN4VZac94SGiEZr.qIrCwZe9GHNCLgNg vDeKA5rkF4QKT26E_sKVZQW2q6rwwiPOpRfoY8rJw2ysxTOsc.yA6_qSYViLEBlPiwb5tkrs1oA3 A.YyoMkcoUB0S3CM_gRFu5RWFXE1P8J6g6tJly6tjLvZtFo1383XsBpc7sbOA2szsEOr4KxKyHJX UTFmUjFtOjzS1YCBeWR_88gfN0RwafB9wHz2zmsaBCFtHafN2kOFn_f.kWyQZz9o0A4GMc0VQMmx 3Ha7xRl36J_dYcTIv17jrWZqgQco7FMS1EQ8_033n2PTPLMoeoIbKeXkJdb45EW8RswoO7zHhYX6 rioM9.hPa.Y_Qt2h.xe_PCxsiR7ilSuMH6Cs2TKk4QI_9DYCipS9YmaDbHHrGTBkuOBL2H0wp5cz gjmc_DcX30B88ubid1Ur2sdk7Bn8YTf3Q3pS.sx9IiZKT3wAU7m1tt8P0qN1378QbFTlQXLeNf58 Bfw8_Oy1IJ3f4dV.NnFIROHVUVVt6oqBqSAlLDUu0ZGkrH5U1_jYUQnRNAPLo6vx60G_PLdTf21I fsbrZdeVWx0NkXdntT9V5gZESkrYHnkAlX46BxIJJfG_kx1k8TyZOz60BT5slCjUBD9YUb5uFrzZ KFOgs9TCm3HJhckdooOAjoY6fe5WUBsv0IitovSFk5X2RukDzYFKNxEQwjMQ9unBRKKzUbL6GB5E ZTaCdlFm2ApzNhaDjAtFYLcKp7_LxT52mzekznrZoeX4MEIwRgYtR8zTGGHtWN5IOmkFq438mfzD dca6pDy09ZqH2n.c8J1Jh7iUD6vIUpGxt0Z9rz6ulzeA_LmGHX4tkRXJEXNb0c041WmxOmdnVAPX _DQXymNYkPx3Z6bG_BxxXG9icF_lqUgIzycUtJXfl7vbiLEJG807i4nIWXEz23IoNmQlkwcgcA3K 0_aToTgb0tVuZHPnlMe_ROrcRWstwfoafrGX97oZsymoY5iwAVcxcmuL_e8lsMPbv3qHigl8.nLh 7fnzNBz9QoqpFCNduWsOUx5GaPx.wUhokOf5OxHiDHDTLgR1jskJSlLSdOx7r0cM8RLYpLIg9lh7 u7_id24rL56UIIkgyUnns7t0p5I_p11.EEjJDEDMGhqS71rH87.GAgExPvN85VtLWRH9UAMK_miJ UsxCsbrlucDPQvHZKNyf0Dy2_p7e.Y_c1qUGv8.BPHhcQds_0ithFYubg3Pe5mbAo9trldCx2wGf P2WCO31i4BkIbDUO1FEDmt21VgLG2rGm0EgUwxE88FQ55XBZ4r2Tcb.BZLKdI62psyX2gCawHzpm UflUVepKfToEHOOehKTR.Ll3HNlwQUhKaCD0IH5LpBC4n35lZa6kEhpkylOLpYeeAdUtrGay08XT r3BRERIXYzIaZDhlGTJZBI4239dvRPqoy997hVWGliUXk.AY9l2q2VjQ36_gxJ6_0QleW08jm9.u P8.kfXHUZ21tEGeKvbHq1xAtJWQ6E74l3Dkz.tnggGzPs7CVTbFgjt.62WBERHj7DcNUx7DXvDgz 2sapKHY4nCv4PciDgdbNpgVbr9wzI3vlT90wwRoRNhLKouJTiUcnfMy358pNBQiq82UPi_Y5XdVu dNDe6SO14re6nyzcWml7yzorcJvtVponF1dPV_yIwKF3VZEtV28sUn0Pk5rjbJgzRz94db5970iI 8nQ-- X-Sonic-MF: X-Sonic-ID: 23d42eb7-cddb-41c9-94fb-bc2972494b0c Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Thu, 18 May 2023 17:07:14 +0000 Received: by hermes--production-gq1-6db989bfb-7mxxf (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID f432744de593e951bcf5b0f68bcbf5bd; Thu, 18 May 2023 17:07: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 \(3731.400.51.1.1\)) Subject: Re: Raspberry Pi POE+ hat overlay From: Mark Millard In-Reply-To: Date: Thu, 18 May 2023 10:06:59 -0700 Cc: Doug Rabson , freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <77CD0716-3BC8-47EB-8743-F2BD9CA43D31@yahoo.com> <432A1A16-9FE5-4339-AB38-8F3E03A5D4EF@yahoo.com> To: Nuno Teixeira X-Mailer: Apple Mail (2.3731.400.51.1.1) X-Rspamd-Queue-Id: 4QMbxc5zQRz4X7Y X-Spamd-Bar: ---- 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] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On May 18, 2023, at 05:48, Nuno Teixeira wrote: > Indeed, voltage was the missing bit! >=20 > I'm trying to setup 1800 as default now for revs >=3D 1.4 following = https://www.raspberrypi.com/news/bullseye-bonus-1-8ghz-raspberry-pi-4/ = that only talk about setting arm_freq=3D1800 but doesn't mention to = adjust voltage. > It was nice that raspberry tell us what voltage exacly value they use = for new default 1800. >=20 > What I've got now is: >=20 > [pi4] > over_voltage=3D6 > arm_freq=3D2000 > sdram_freq_min=3D3200 > ### force_turbo=3D1 >=20 > My tests shows that we don't need force_turbo=3D1 for a normal running = and system do an auto 600 -> 2000 change when needed. Thats nice. I will note that the RPi* firmware itself varies the frequency and voltages by default --but the way of disabling that also disables powerd from being effective as I understand. (As I understand the firmware's policy details have changed over time but I do not know the details or when.) This makes use of powerd on the RPi*, with the firmware's adjustments also enabled, involve 2 competing mechanisms, if I understand right. I'm not aware of any horrible consequences in actual ooperation but I found force_turbo to lead to less time being taken in build activities back when I last measured it. It is true that I've not looked into this area in a long time. > Also, arm_boost=3D1 with force_turbo or not, is ignored. = https://github.com/raspberrypi/documentation/blob/8b096a52e394c10360549afd= 0a620755df467446/documentation/asciidoc/computers/config_txt/overclocking.= adoc (from 2021-Nov-04) did not have arm_boost documented yet. = https://github.com/raspberrypi/documentation/blob/da45bd8c982e91e11c609991= ba2fc8783872ef67/documentation/asciidoc/computers/config_txt/overclocking.= adoc (from 2021-Nov-11) has arm_boost documented. These give a clue about the vintage of RPi* firmware needed to have the arm_boost notation implemented. > sdram_freq and sdram_freq_min are set to 3200 by default, so I think I = will not need sdram_freq_min=3D3200 here. = https://github.com/raspberrypi/documentation/blob/2cbcd18fc155044f20ae6305= fa0e62629b56893c/configuration/config-txt/overclocking.md (from 2021-Mar-31) shows the Pi4 sdram_freq_min as 400. The defaults have changed with firmware updates. Note that the official RPi* port has 2021-Mar-03 firmware, so before 2021-Mar-31. = https://github.com/raspberrypi/documentation/blob/75e6050edd9e1b0c47c58623= 133dc05a02c16351/documentation/asciidoc/computers/config_txt/overclocking.= adoc (from 2021-Aug-09) shows the Pi4/CM4 sdram_freq_min as 3200. These give a clue about the vintage of RPi* firmware needed to have the sdram_freq_min be 3200 by default. My settings are for a wide range of firmware vintages, not just modern ones. Each item was shown (at the time added) was shown to cut the times for the likes of buildworld, buildkernel, or poudriere bulk activities that I did. Also, I tend to leave in place what has worked and still does work, rather than to track the changes in defaults over time in even more detail. I'd likely have different settings listed if I'd started at a later point that had newer defaults. > The only thing that I can't understand is how to calculate voltage: >=20 > over_voltage: 0 (1.35V, 1.2V on Raspberry Pi 1) ??? > ( https://www.raspberrypi.com/documentation/computers/config_txt.html = ) >=20 > Also, "7. Take it to the max" ( = https://magpi.raspberrypi.com/articles/how-to-overclock-raspberry-pi-4 = ): >=20 > over_voltage=3D6 (?) > arm_freq=3D2147 > gpu_freq=3D750 I'll note that I never attempted to take each RPi4B to its maximum for normal operation. I targeted having a setting combination that was reliable (had some margin) on all the example RPi4B's. I did have to explore were failures occured to do that. I did have access to RPi4B's that were unreliable with arm_freq=3D2100 for any over_voltage that I tried. Backing off to 2000 gave me reliable results on all the RPi4B's. I never had trouble with sdram_freq_min=3D3200 but it did help in contexts with the default being 400. > Thanks, >=20 >=20 > Mark Millard escreveu no dia quinta, 18/05/2023 = =C3=A0(s) 11:57: > On May 18, 2023, at 01:29, Nuno Teixeira wrote: >=20 > > Confirmed that arm_boost is enable by default on rpi4 rev >=3D 1.4 = as I checked with htop. > >=20 > > Also, tested arm_freq=3D1800 and it crashes FreeBSD around = initializing console/video and detecting mouse. >=20 > Overclocking by setting the arm_freq directly involves also > managing over_voltage explicitly, such as: >=20 > over_voltage=3D6 >=20 > A sequence I use (and have used for a long time) is: >=20 > [pi4] > over_voltage=3D6 > arm_freq=3D2000 > sdram_freq_min=3D3200 > force_turbo=3D1 >=20 > But each RPi4B has heatsinks, a case with a fan, > and a power supply rated for 5.1V 3.5A (so: has > some extra margin). >=20 > But the range of RPi4B's span Rev 1.1, Rev 1.4, > and Rev 1.5, a mix of 4 GiByte RAM and 8 GiByte > RAM models. All use those settings. >=20 > As I understand, arm_boost implicitly does the > extra things required for its implicit frequency, > unlike assigning arm_freq or the like. >=20 > If force_turbo is not used, it can be that: >=20 > # > # Local addition that avoids USB3 SSD boot failures that look like: > # uhub_reattach_port: port ? reset failed, error=3DUSB_ERR_TIMEOUT > # uhub_reattach_port: device problem (USB_ERR_TIMEOUT), disabling = port ? > initial_turbo=3D60 >=20 > is required for USB based booting. But this also > gets into if the notation is supported or not for > the firmware vintage used. >=20 > The initial_turbo use happens to avoid frequency > variability during boot and it appears that FreeBSD > does not necessarily tolerate such variability in > that time frame. >=20 > Also: I happen to have USB3 boot media for which use > of usb_pgood_delay=3D2000 is sufficient but without > some such in/for U-Boot, U-Boot has problems > recognizing the device (before FreeBSD is even > involved). I build the U-Boot port with the > assignment built in. >=20 > > As linux config.txt says: > > --- > > [pi4] > > # Run as fast as firmware / board allows > > arm_boost=3D1 > > --- > > firmware must be updated to support this feature for sure. >=20 > I'm not aware of a dated list of when the various > config.txt notations were first supported (firmware > version). This makes it messier to use the web's > published information, if one is using the firmware > vintage that FreeBSD has in its port for the > firmware. >=20 > The notation that I use has been around for a long > time. >=20 > > Cheers, > >=20 > > Nuno Teixeira escreveu no dia quarta, = 17/05/2023 =C3=A0(s) 14:08: > > (...) > >=20 > > I was meant using 13.2 not 12.3 :) > >=20 > > Doug Rabson escreveu no dia quarta, 17/05/2023 = =C3=A0(s) 13:47: > > I'm not sure about 12.3 either - you could try with 13.2 and see if = that makes a difference. > >=20 > > On Wed, 17 May 2023 at 13:45, Nuno Teixeira = wrote: > > Hey, > >=20 > > Ok. I'm new to rpi4 and arm in general but tomorrow I will force = 'arm_freq=3D1800' again just to see it it crashes again. > > I will check too what values linux shows. > >=20 > > I don't know if firmware/uboot version included in 12.3 supports = this feature. > >=20 > > Cheers, > >=20 > > Doug Rabson escreveu no dia quarta, 17/05/2023 = =C3=A0(s) 13:11: > > Hi Nuno, > >=20 > > I'm not sure where to start - I just happened to notice in the = documentation here: = https://www.raspberrypi.com/documentation/computers/config_txt.html that = the cpu frequency Pi4B R1.4 was listed as 1800 if arm_boot=3D1 so I = tried it. > >=20 > > Doug. > >=20 > >=20 > >=20 > > On Wed, 17 May 2023 at 11:11, Nuno Teixeira = wrote: > > Hello Doug, > >=20 > > I have too a 1.5 rpi but arm_boost=3D1 isn't doing anything, htop = shows 1500Mhz when doing something intensive. > > I'm running 13.2 stable > >=20 > > Do I missing something? > >=20 > > Could you take a look at my setup? > >=20 > > Thanks, > >=20 > > Doug Rabson escreveu no dia ter=C3=A7a, 16/05/2023 = =C3=A0(s) 17:19: > >=20 > > On Sat, 13 May 2023 at 13:45, Doug Rabson wrote: > > I was able to build an updated rpi-firmware port based on 1.20210805 = and this boots successfully on pi400 as well as rpi4. With this, I can = load the rpi-poe-plus overlay and I just need to try and reverse = engineer the undocumented mailbox API by reading the Linux code. > >=20 > > I have a first approximation of a fan driver which works with the = 1.20210805 firmware (actually, I substituted rpi-poe-plus.dtbo from = 1.20210831 which just changes the fan levels for the POE+). I'm testing = with an rpi4B rev 1.5 with 'make -j4 buildworld' and the fan is keeping = the cpu temperature below 65 degrees which is nice, especially since I = set arm_boost=3D1 in config.txt which boosts the cpu frequency up to = 1800 for this board. > >=20 > > Does anyone have a pointer to the problem with firmware later than = 20210805? Would it make any kind of sense to try to get the fix into = releng/13.2 as an errata? > >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Thu May 18 17:20:16 2023 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 4QMcDv6T24z4Bp27 for ; Thu, 18 May 2023 17:20:31 +0000 (UTC) (envelope-from tomek@cedro.info) 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 4QMcDv2pDgz4YdK for ; Thu, 18 May 2023 17:20:31 +0000 (UTC) (envelope-from tomek@cedro.info) Authentication-Results: mx1.freebsd.org; none Received: by mail-yw1-x1132.google.com with SMTP id 00721157ae682-561b65b34c4so29675547b3.1 for ; Thu, 18 May 2023 10:20:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cedro.info; s=google; t=1684430430; x=1687022430; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Rxut9MwA9rG4c4p+NzXhfFkKWLw9kJ/t0NQbcqSZpKA=; b=I4YqwMSoXdHlcLT1tA9L6rZtBwQOBto0D5J2Jjx6Y3HY7i3vyudvpLOiyYQlaFmnZF ixUqZ/rvBT7g9kUJUDpQASLwiVYVypZzEMMzpKFGzZbiLoEPM0K5uCINp0NeG4ZfoL7o Fx504Q1NUAiTJAcXRb+DFHivppzh8rCz1d98rdIFveKL9RocBGym6YeXTf0/cKXQ7Ef4 P7wuyKl9KWvu1UdD9DRVicFMFMG1pIAzvKx26zoQLBh+Walh2osSkngOb35+dP+lyD+/ O8g7RSMpkbgFU0bMReEerR9OwcbPslCze1LGK/3oVMNQ/ekDmmG9SSU6uZQD+7CxfyvY gAhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684430430; x=1687022430; 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=Rxut9MwA9rG4c4p+NzXhfFkKWLw9kJ/t0NQbcqSZpKA=; b=a6A5buzBzT6xrJCl/dfNKGeIaitlDiuXEkGRGr9LwkuoDm+In0gje5RbVePqAVkUNa BRujknKdmlHKplWxeNA4cCBVhVyRoiYv6+mNP+FHmH3Q2sGxMQ2AmF4SgUZXN87VabWm cbQr90iUoHHxZCRMAvazQIOB34NwaTJaINtLc1RWcd2NvaY7L60J3gyN/WP+oIvqr2Ax kp759jX2t+YU8V/st/huGJSzb8RHzXtkQL6UsqyeQwai3QTnJTaphTkpy/lUaGLR45B/ fKAUl04R2hxVU9EcUh3ApHsAYxqc/o9R30J0jzNqZeOOD8zKZ1MhYFM1I1V6CKiZPpEW FGKg== X-Gm-Message-State: AC+VfDw8hYCf3g2AB+bNlBaeIJL7bZFl6aTXC2J8pXIQn5IeuLFELO56 FW/j4qPWn9Fq71PNXGGaTDa75SzUvIgLhPPzvP4= X-Google-Smtp-Source: ACHHUZ45a95jPRAwXN9mamR89l0nSrQEuVcAXFAsiLxbFZ+kOz3Bcc5DoLsIXRfC9o8bC7SnQFCRIA== X-Received: by 2002:a25:37d1:0:b0:ba1:6bad:41a4 with SMTP id e200-20020a2537d1000000b00ba16bad41a4mr2113062yba.14.1684430430230; Thu, 18 May 2023 10:20:30 -0700 (PDT) Received: from mail-yw1-f180.google.com (mail-yw1-f180.google.com. [209.85.128.180]) by smtp.gmail.com with ESMTPSA id e72-20020a25374b000000b00b9dff5bf482sm471145yba.26.2023.05.18.10.20.29 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 18 May 2023 10:20:29 -0700 (PDT) Received: by mail-yw1-f180.google.com with SMTP id 00721157ae682-561c46e07d7so29632787b3.2 for ; Thu, 18 May 2023 10:20:29 -0700 (PDT) X-Received: by 2002:a25:ae1b:0:b0:ba7:e8e:a51f with SMTP id a27-20020a25ae1b000000b00ba70e8ea51fmr1803700ybj.42.1684430429430; Thu, 18 May 2023 10:20:29 -0700 (PDT) List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Tomek CEDRO Date: Thu, 18 May 2023 19:20:16 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: FreeBSD on the pinephone : considerations To: Mario Marietto Cc: freebsd-arm@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4QMcDv2pDgz4YdK X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N My friend Lup Yuen LEE from Singapore is porting from scratch NuttX RTOS to Pinephone, he is writing detailed documentation in form of articles on how he makes step by step things work (i.e. bootloader, uart, kernel, shell, graphics, lvgl ui toolkit, modem command to make calls/sms, now at accelerometer stage), this may be useful for porting drivers and understanding internals.. maybe even using the code (Apache licensed): https://lupyuen.github.io/ -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From nobody Thu May 18 17:34:23 2023 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 4QMcYc5zR0z4Bplp for ; Thu, 18 May 2023 17:35:00 +0000 (UTC) (envelope-from marietto2008@gmail.com) Received: from mail-yb1-xb2d.google.com (mail-yb1-xb2d.google.com [IPv6:2607:f8b0:4864:20::b2d]) (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 4QMcYc2Gfjz4bDc for ; Thu, 18 May 2023 17:35:00 +0000 (UTC) (envelope-from marietto2008@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-yb1-xb2d.google.com with SMTP id 3f1490d57ef6-ba87337c0c3so2429074276.1 for ; Thu, 18 May 2023 10:35:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1684431299; x=1687023299; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=5pPGZuGvFmhF8p3O9BYjPZ/2B0srKByNPuszEJqpAkE=; b=UXSBJjoLEZE8933K2QpCD+9kbt7V4CDtOUB2mfRwfN7aWK5pmB6Buq7hqT3CBG8+43 ZPJYjEwMaWhQtfKto/8QSG7Xfl3klweDI2qdJLX6Co/qX6jl3q4rHWsz5lMrrSuzeou2 qo3iXIQ2tisa0FFl0YxYYrnARRw+9GowIuR5Gke+yvs3sZp/+Uns3huS098jo+E3RbgL Avx376y+IVj7lxv5yNtHrGGSbTLEyQt4qLuRSb/wbJyAdtvvJ54qF72mhHCnMydGcC2W thWhcTs/XLm1pMXunXlyv2I4UJEXBjUnNzaHRJu3aO4T3rSQgPh/l21OGjLaMx8vCmAx cduw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684431299; x=1687023299; 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=5pPGZuGvFmhF8p3O9BYjPZ/2B0srKByNPuszEJqpAkE=; b=eiU/cq0+FG3fFfruNooj4qW84GSh+O3SR8SzMaHld6ceYS7vq0kz/j5rxUUJgMQEvk ILVIDcxYzN73u5d99iQmI3LrVwbW8S5FEQ47EXO0e8II4bHnXtNkgaitS7TVfMMHletC Flclk2FD4bYdP99pqLl2tCQ6zuLWKH1sW0iLFQF9Vk02Zq35rj109USATn6mabXs7icg L6jq2T5m6aWtGY8Yl8Q/+ehaVAyshj9phjHxPlQfyM2qGqAcdPitEwGBKwDIsQJzDnr9 VPEizPnLSKYCy4RKzWp09vO/OY2V0qMuNyQOAp/wa3+Rit+mkzAoSVVG+lP5PSiEXhsd XpzA== X-Gm-Message-State: AC+VfDzdrzT4M5Hi9bDfRrEmUOZ9ZTkGMqGk5gMx+Z/Y2EVfHXbJv0pa FEMCtGcMGZV5fQdRSy2WgeZ1FnlY0gznWqniDoW6BAqu04k= X-Google-Smtp-Source: ACHHUZ442aVe3Pnn1U50cViq24BhVGHuWb1F4dGo1Xvon9sty315iCiV8J279SVrVjPBzdwII2NgETipwWy2TISmxvo= X-Received: by 2002:a25:6d6:0:b0:ba8:2a74:155 with SMTP id 205-20020a2506d6000000b00ba82a740155mr1662400ybg.32.1684431299318; Thu, 18 May 2023 10:34:59 -0700 (PDT) List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Mario Marietto Date: Thu, 18 May 2023 19:34:23 +0200 Message-ID: Subject: Re: FreeBSD on the pinephone : considerations To: Tomek CEDRO Cc: freebsd-arm@freebsd.org Content-Type: multipart/alternative; boundary="0000000000003e992e05fbfb3911" X-Rspamd-Queue-Id: 4QMcYc2Gfjz4bDc X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --0000000000003e992e05fbfb3911 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks. This is too advanced for me,but I want to try to spread the knowledge as much as possible,to find someone that can be interested to grab some information useful to port FreeBSD. On Thu, May 18, 2023 at 7:20=E2=80=AFPM Tomek CEDRO wrot= e: > My friend Lup Yuen LEE from Singapore is porting from scratch NuttX > RTOS to Pinephone, he is writing detailed documentation in form of > articles on how he makes step by step things work (i.e. bootloader, > uart, kernel, shell, graphics, lvgl ui toolkit, modem command to make > calls/sms, now at accelerometer stage), this may be useful for porting > drivers and understanding internals.. maybe even using the code > (Apache licensed): > > https://lupyuen.github.io/ > > -- > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info > --=20 Mario. --0000000000003e992e05fbfb3911 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks. This is too advanced for me,but I want to try to s= pread the knowledge as much as possible,to find someone that can be interes= ted to grab some information useful to port FreeBSD.

On Thu, May 18, 202= 3 at 7:20=E2=80=AFPM Tomek CEDRO <to= mek@cedro.info> wrote:
My friend Lup Yuen LEE from Singapore is porting from scratch= NuttX
RTOS to Pinephone, he is writing detailed documentation in form of
articles on how he makes step by step things work (i.e. bootloader,
uart, kernel, shell, graphics, lvgl ui toolkit, modem command to make
calls/sms, now at accelerometer stage), this may be useful for porting
drivers and understanding internals.. maybe even using the code
(Apache licensed):

https://lupyuen.github.io/

--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info


--
Mario.
--0000000000003e992e05fbfb3911-- From nobody Thu May 18 18:16:10 2023 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 4QMdTK6rD1z4Brp4 for ; Thu, 18 May 2023 18:16:21 +0000 (UTC) (envelope-from rivers@dignus.com) Received: from dignus.com (adsl-065-013-223-202.sip.rdu.bellsouth.net [65.13.223.202]) (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 "office.dignus.com", Issuer "office.dignus.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QMdTJ6jpmz3GS0 for ; Thu, 18 May 2023 18:16:20 +0000 (UTC) (envelope-from rivers@dignus.com) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of rivers@dignus.com designates 65.13.223.202 as permitted sender) smtp.mailfrom=rivers@dignus.com; dmarc=none Received: from office.dignus.com (localhost [127.0.0.1]) by dignus.com (8.16.1/8.16.1) with ESMTPS id 34IIGArQ024383 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 18 May 2023 14:16:10 -0400 (EDT) (envelope-from rivers@office.dignus.com) X-Authentication-Warning: office.dignus.com: Host localhost [127.0.0.1] claimed to be office.dignus.com Received: (from rivers@localhost) by office.dignus.com (8.16.1/8.16.1/Submit) id 34IIGA8P024382; Thu, 18 May 2023 14:16:10 -0400 (EDT) (envelope-from rivers) Date: Thu, 18 May 2023 14:16:10 -0400 (EDT) From: Thomas David Rivers Message-Id: <202305181816.34IIGA8P024382@office.dignus.com> To: freebsd-arm@freebsd.org, rivers@dignus.com Subject: 32-bit executables on aarch64? X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on office.dignus.com X-Spamd-Result: default: False [0.20 / 15.00]; HFILTER_HOSTNAME_4(2.50)[adsl-065-013-223-202.sip.rdu.bellsouth.net]; 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)[+ip4:65.13.223.202]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_TWO(0.00)[2]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; R_DKIM_NA(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; ASN(0.00)[asn:7018, ipnet:65.13.220.0/22, country:US]; FREEFALL_USER(0.00)[rivers]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_NONE(0.00)[]; HAS_XAW(0.00)[]; DMARC_NA(0.00)[dignus.com]; MIME_TRACE(0.00)[0:+] X-Rspamd-Queue-Id: 4QMdTJ6jpmz3GS0 X-Spamd-Bar: / X-ThisMailContainsUnwantedMimeParts: N 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 Tried the following with a small "hello world" program on FreeBSD freebsd 13.2-RELEASE FreeBSD 13.2-RELEASE releng/13.2-n254617-525ecfdad597 GENERIC arm64 # cc -m32 hello.c To get these errors: ld: error: /tmp/hello-1eb3b8.o is incompatible with /usr/lib/crt1.o cc: error: linker command failed with exit code 1 (use -v to see invocation) Is building a 32-bit program not supported on 13.2 arm64? man cc gave me the CLANG doc... which didn't even mention "m32"; so perhaps I just need a different set of options? I tried -arch arm but I still got 64-bit code. Also, I tried several other -arch options and didn't see a difference, even with -arch x86, I still got Aarch64 code. - Many thanks! - - Dave Rivers - -- rivers@dignus.com Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com From nobody Thu May 18 18:22:08 2023 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 4QMdcL6shcz4BsQN for ; Thu, 18 May 2023 18:22:26 +0000 (UTC) (envelope-from jfc@mit.edu) Received: from outgoing-exchange-3.mit.edu (outgoing-exchange-3.mit.edu [18.9.28.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.outgoing-exchange.mit.edu", Issuer "InCommon RSA Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QMdcL59KFz3H4c for ; Thu, 18 May 2023 18:22:26 +0000 (UTC) (envelope-from jfc@mit.edu) Authentication-Results: mx1.freebsd.org; none Received: from oc11exedge2.exchange.mit.edu (OC11EXEDGE2.EXCHANGE.MIT.EDU [18.9.3.18]) by outgoing-exchange-3.mit.edu (8.14.7/8.12.4) with ESMTP id 34IIMBVO030921; Thu, 18 May 2023 14:22:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=outgoing; t=1684434133; bh=TzXDAofguxmnq1MREWFI+m4DTwAiCrr3O3Y1wIkorJo=; h=From:To:CC:Subject:Date:References:In-Reply-To; b=lE+BMW0XMTpbFEPZVZWrENKS1OwhyI/einMleb0bUshI1mfxHlSDow8vM0Fx/KOeN BiapsWKZuj0hKowr0CGjzZpuS+GCNteAi4/ZQd7Q0QuLIGE7FpPFWr7K3Yhx2BYbDH iVfDTxW1URAN0wL2/ZLhDUSG7eqGyv4yitio6IRKlXK6QSCOm+VNeNqbv7BeG/o+CS OLO5wjuj3czvyBSmzy/fTuc2reYLuBgMexPDRXlJ1/NBvPm8Ctq+Blt50NV4QR161O O6E5PsJmDdw27ZNm8HI0FlAhwBb/ftx/ayjnrfQQE/jooeEISReHreXJO9+t1hLv2L 2JE/OlDI42IiA== Received: from OC11EXPO29.exchange.mit.edu (18.9.4.102) by oc11exedge2.exchange.mit.edu (18.9.3.18) with Microsoft SMTP Server (TLS) id 15.0.1497.48; Thu, 18 May 2023 14:22:02 -0400 Received: from oc11exhyb4.exchange.mit.edu (18.9.1.100) by oc11expo29.exchange.mit.edu (18.9.4.102) with Microsoft SMTP Server (TLS) id 15.0.1497.42; Thu, 18 May 2023 14:22:11 -0400 Received: from NAM04-BN8-obe.outbound.protection.outlook.com (104.47.74.41) by oc11exhyb4.exchange.mit.edu (18.9.1.100) with Microsoft SMTP Server (TLS) id 15.0.1497.48 via Frontend Transport; Thu, 18 May 2023 14:22:11 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=e9nZKDrMyfGZWW7WEYWVcvIJnQhhE/M5IVM0u7C0Aq/YWxgt526xcUDvmC2bps+GFiRr3wgG8+M/kqVkcuLAdFP7ojun4pBseT54knsI9WW7ootR0i61VIbV5KIWtI8PFzOxCUGCfWKKdDIN7Qtuh7V/aKXZH5LSJm30wkdgVgUjJI0q8DdXq2Q7oormFjRvjb2yd+NukqAH+z1RFM3Am7yZAlot896dcAep+5dPJ9f7R9/QXQ3uMXopHFW1DV56jjsqtrb26xccVL6BdYELTsP17g3mNvTKffw+CxQkjIVnRYGRYdmbrS3Ek9yBuGauDk2X9EvDwCjOVPUaj/iW1g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=TzXDAofguxmnq1MREWFI+m4DTwAiCrr3O3Y1wIkorJo=; b=R0F5bK0MInz71MGdAEY5wanh/RacAlYXnA7KkxS3OnidjGZaAs+IzK8F4nGCNFhBOv9mFNLdic3h8Eyl+G4SRAZmiY9+X+wmEYDBSFRax2Mf/Ma7c7hr7c065odBXSoLCn6sMiT4l85a3u5G4uZo35XINUVvHPCUK5skFC20Gq8bZrY9MsOiGyaCGJG3LTk3cVP5GC1Y0h/By+dhCDrtHhkezAka3716iatBV8eTmPfS9/pZNZyZ4xEJwly5HFp1fJGQDfH/JIHHmuN3xD0mu/XUh5FwYtuuTkxEqap1e6KuaSSo+LhierFtzoVbtEYMuKp+yE3kTLbd7CRLTNH94A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=mit.edu; dmarc=pass action=none header.from=mit.edu; dkim=pass header.d=mit.edu; arc=none Received: from DS7PR01MB7712.prod.exchangelabs.com (2603:10b6:8:7b::17) by SN6PR01MB5055.prod.exchangelabs.com (2603:10b6:805:d6::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6411.19; Thu, 18 May 2023 18:22:08 +0000 Received: from DS7PR01MB7712.prod.exchangelabs.com ([fe80::5d78:4464:66e8:94a9]) by DS7PR01MB7712.prod.exchangelabs.com ([fe80::5d78:4464:66e8:94a9%7]) with mapi id 15.20.6411.019; Thu, 18 May 2023 18:22:08 +0000 From: John F Carr To: Thomas David Rivers CC: "freebsd-arm@freebsd.org" Subject: Re: 32-bit executables on aarch64? Thread-Topic: 32-bit executables on aarch64? Thread-Index: AQHZibTgTpU99fvZzkaMEV2y0rXZua9gV9iA Date: Thu, 18 May 2023 18:22:08 +0000 Message-ID: <46BE47DA-9306-4682-8320-D2CBEB5918F7@mit.edu> References: <202305181816.34IIGA8P024382@office.dignus.com> In-Reply-To: <202305181816.34IIGA8P024382@office.dignus.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-traffictypediagnostic: DS7PR01MB7712:EE_|SN6PR01MB5055:EE_ x-ms-office365-filtering-correlation-id: abbee6f8-09e0-446b-487c-08db57ccca97 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 3CCDnqyjyqg+w4AXjHc3zATSn17InMrxvfWI8WKD6qhdDbWnnXN0UckFD8yoNxNfa/eX1vqAJC0ntykCCtCvFkKqB2+Ozw0XGoj4b0KCrn8vnjcj3CKChP/5ST8VSHZY7cGzZYRjEotzNQfWNSbDVtg0YumllHEhHswqCgUuhIFDdQ/9UHYS11i5NTrc/dzHTbrzc7Elp8/ba3HKfg6T1WFPFm5o7AAEYMv1R7Z4doJLTKQ2nmknhYNAY3nY2yzaaQhdVmdq6Mv5Y6lNSDiaKc86yC++JoFte+Gw+GY/cXTv40/FVIwMePXhZp8WNjbVeAVzTzCl3J/DDr8mpinNaymAGXY9+v1rUrwcnHfjMu+Ua8U3X1e+2pr1V+eaVCebHMCopImU3KtdNStiN3K1KGG8L60qU0h8yAt6agPkS/FwDPyqxrxBlvoFx+J47XKx6Kf0/FP0ebjV6ahUZ4wSs6+3PPt52fvNOPibChPM0Vx3SnDRFixfxyGrkrmWie3KPbINC7koFUZa/EKDaM3IsSjLoyfa/HB5Ybvn8ncPKzSrbI/nyWWOM7LOHcdZsy1PgSeO/lvm6FjtoDNNVv46NOkia1+Zzv7XKv8D6dkPPZ8= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DS7PR01MB7712.prod.exchangelabs.com;PTR:;CAT:NONE;SFS:(13230028)(4636009)(396003)(376002)(136003)(39860400002)(366004)(346002)(451199021)(478600001)(71200400001)(966005)(41300700001)(5660300002)(6486002)(4326008)(786003)(6916009)(66556008)(66446008)(64756008)(316002)(66476007)(186003)(8676002)(8936002)(6512007)(6506007)(26005)(2906002)(2616005)(76116006)(91956017)(66946007)(36756003)(38100700002)(122000001)(86362001)(38070700005)(53546011)(75432002)(40140700001)(33656002);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?C58MT49O6qaoOTIr5dqmqkS0/eYlwXS98KTw+9/Yrr+7HRA+xX8JbjtOhktc?= =?us-ascii?Q?EM/XQrvqgrxLUR6j2j1BzBFvLsoDhFZ++uGPOmKo9RY91D1mDO+15oAGTMZH?= =?us-ascii?Q?bnkjqDDHN2kBeKxX8Ms64KYcmGt2vsUybh1FaFNt97hlpR35cLbuFKLvHR9u?= =?us-ascii?Q?t/zHYtiKQrAph52ohmFAKIJciS9TvilN1QVt7+INLFFiwlb0GYgIuOErfAo8?= =?us-ascii?Q?5mMhuRdP7gqSQq/7GMaAtfmEnaSUzMKQvmFNQLCWz66WnBZRlDdYOIfLhJmh?= =?us-ascii?Q?6TC7CfZw6DY8uNe6o+FLKLQ17ASAf2BkV5yWc1qRHiUQ/hftDQdQ0Cz5RKFT?= =?us-ascii?Q?b458QC8g8YDJo6VxRE/Kv5HcX260idmVixV4y6PltTyGQXo1Gees8yjg3Xz/?= =?us-ascii?Q?dlOz/4j/gdzCnNfJbrhPeMcIELqEhgWAtlrdjXanocOxrWroLGxWb95eTvdr?= =?us-ascii?Q?UnVwzGztHGFkhLhEr1PmyXNSxHh+dv3XG5E+fxASlltaTcbV4NXGEeqen7FO?= =?us-ascii?Q?jDR0WqsjQKJzGYLPWpj2b+q6K23LkfkShXpFbKXP9dj5OBv/Nvr6eSFJu8oI?= =?us-ascii?Q?rbqw8Tc/x7FBUtnx8by4jvJ7x3VKLSIhi3Jc52RCU9HXKPWK4xjQPPPgVlBF?= =?us-ascii?Q?mMuKO4SPubE+iVZVfhJ6JBr2xBRHMEiRxwz/eo9eCNRQyq2iSeplAQiE6xm8?= =?us-ascii?Q?nFkAvpPPT2l+C5eM32U7aI6IcPx76HZLi0QHGxI4zGefvhbX+zvQRuoQ8kCM?= =?us-ascii?Q?rLQlmSydPBjURJ/qm6WN/cdVhAygStI9XrTDGBLYiXR51ltTvpi38/4UWDys?= =?us-ascii?Q?R2rpZhlH4AJ5FKu8KBaXeYeAuVWsziJhKx7r5CsQQEQckfoqP+xoPeDfOhf0?= =?us-ascii?Q?51jWaYyPIQoxMEReCG+VQQ9/WgXIWv/A9GG9qPoYLwZF+QWqFkPYAdiK+A4C?= =?us-ascii?Q?9TnakJPKAXTPX2XDuOXdMddXrKXCevE1V1SOyliUcdoPB1e4G1QXPHz9mfB7?= =?us-ascii?Q?Fl5c/DBfywjBYTMtI9yUs9tcMIsGg0fUmoauM+GoFWLKlfhHFPHn8FPhxJfD?= =?us-ascii?Q?mOOEQQi7Ggl9A7wmxcfbi85riZjBNPbKFHkssR1KbGeEZYgr+B3BO/nZBLWd?= =?us-ascii?Q?kueNi3/6DIMESck6ec8eOHEoGOK6fWbc6PGpEfIL7TcIMQnbmxpH5NBhxde7?= =?us-ascii?Q?vVFujkvITGj9sGBzAVquuGk0Vl4D9Fu+lKnis5HwydPjtYLXmy+3i5dMkQ5k?= =?us-ascii?Q?nbjZ6CtCCPqV1CQo9plxkRmKLNNmqznpvwIZBQnPz8TDnhgBllJniUk3NuRv?= =?us-ascii?Q?5LIF5NIq3a7LFPHVVnadRj6EuyYHhLEfVzLQZbUNk0inTLE9+ZRdorwvg8DA?= =?us-ascii?Q?f/DhFPxWn/aeyE1d68KjuQAjukoDvmPaa0cS8xo1qXA2MHzsIwkw3nOlB5/3?= =?us-ascii?Q?xTJsUgDflgYJZ+GXwq6HmTrlpj53DpVum2eeHdKzNHzJcswoekLeT03IWmP3?= =?us-ascii?Q?PI1rGzlp7VMfIYbGtXXjKpfBz5Bc1cG3g6nObo/af3bVpx6eHMU5N9tn4TWM?= =?us-ascii?Q?YPDLPD99lUvBR+Py4v4=3D?= Content-Type: text/plain; charset="us-ascii" Content-ID: <84FC39DA9C49C74FA2358D6DB08573EF@prod.exchangelabs.com> 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 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DS7PR01MB7712.prod.exchangelabs.com X-MS-Exchange-CrossTenant-Network-Message-Id: abbee6f8-09e0-446b-487c-08db57ccca97 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 May 2023 18:22:08.5146 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Nk0URI9lpF4d2Tc5M8drbdZJuBZH/EGn1JxjlYI2fGOdpvib/T1j+3m0++9Hb+gr X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR01MB5055 X-OriginatorOrg: mit.edu X-Rspamd-Queue-Id: 4QMdcL59KFz3H4c X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:3, ipnet:18.9.0.0/16, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N I had to set up a jail to test 32 bit ARM on a 64 bit host. If you get pas= t the link error, expect the program to fail at startup. $ file /bin/ls /usr/jail/armv7/bin/ls /bin/ls: ELF 64-bit LSB pie executable, ARM aarch64, version= 1 (FreeBSD), dynamically linked, interpreter /libexec/ld-elf.so.1, for Fre= eBSD 13.2 (1302505), FreeBSD-style, stripped /usr/jail/armv7/bin/ls: ELF 32-bit LSB executable, ARM, EABI5 version 1 (Fr= eeBSD), dynamically linked, interpreter /libexec/ld-elf.so.1, FreeBSD-style= , for FreeBSD 13.2 (1302500), stripped $ /usr/jail/armv7/bin/ls ELF interpreter /libexec/ld-elf.so.1 not found, error 8 Abort trap "Not found" means "is not a 32 bit executable." Because both 32 and 64 bit= progams use the same intepreter pathname they can't both work. > On May 18, 2023, at 14:16, Thomas David Rivers wrote: >=20 >=20 > Tried the following with a small "hello world" program on=20 > FreeBSD freebsd 13.2-RELEASE FreeBSD 13.2-RELEASE releng/13.2-n254617-5= 25ecfdad597 GENERIC arm64 >=20 > # cc -m32 hello.c >=20 > To get these errors: >=20 > ld: error: /tmp/hello-1eb3b8.o is incompatible with /usr/lib/crt1.o > cc: error: linker command failed with exit code 1 (use -v to see invocat= ion) >=20 > Is building a 32-bit program not supported on 13.2 arm64? >=20 > man cc >=20 > gave me the CLANG doc... which didn't even mention "m32"; so perhaps > I just need a different set of options? I tried -arch arm but I still > got 64-bit code. Also, I tried several other -arch options and didn't > see a difference, even with -arch x86, I still got Aarch64 code. >=20 > - Many thanks! - > - Dave Rivers - >=20 > -- > rivers@dignus.com Work: (919) 676-0847 > Get your mainframe programming tools at http://www.dignus.com >=20 From nobody Thu May 18 18:43:32 2023 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 4QMf4j61Bdz4BtW3 for ; Thu, 18 May 2023 18:43:33 +0000 (UTC) (envelope-from rivers@dignus.com) Received: from dignus.com (adsl-065-013-223-202.sip.rdu.bellsouth.net [65.13.223.202]) (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 "office.dignus.com", Issuer "office.dignus.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QMf4j58xQz3QNn for ; Thu, 18 May 2023 18:43:33 +0000 (UTC) (envelope-from rivers@dignus.com) Authentication-Results: mx1.freebsd.org; none Received: from office.dignus.com (localhost [127.0.0.1]) by dignus.com (8.16.1/8.16.1) with ESMTPS id 34IIhWE1024977 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 18 May 2023 14:43:32 -0400 (EDT) (envelope-from rivers@office.dignus.com) X-Authentication-Warning: office.dignus.com: Host localhost [127.0.0.1] claimed to be office.dignus.com Received: (from rivers@localhost) by office.dignus.com (8.16.1/8.16.1/Submit) id 34IIhW5p024976; Thu, 18 May 2023 14:43:32 -0400 (EDT) (envelope-from rivers) Date: Thu, 18 May 2023 14:43:32 -0400 (EDT) From: Thomas David Rivers Message-Id: <202305181843.34IIhW5p024976@office.dignus.com> To: jfc@mit.edu, rivers@dignus.com Subject: Re: 32-bit executables on aarch64? Cc: freebsd-arm@freebsd.org In-Reply-To: <46BE47DA-9306-4682-8320-D2CBEB5918F7@mit.edu> X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on office.dignus.com X-Rspamd-Queue-Id: 4QMf4j58xQz3QNn X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:7018, ipnet:65.13.220.0/22, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N 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 Thanks John! I've not messed around with all of this in some time... Everything has _really_ changed. Does anyone have a pointer to how to run QEMU for Armv7 and install the Tier 2 armv7 image? I found: http://ftp.freebsd.org/pub/FreeBSD/releases/arm/armv7/ISO-IMAGES/13.2/ which seems to have the install image... but I can't find any instructions on how to do an install... If someone has fired-up QEMU for this and happens to have the list-of-what-to-do, it would be terrific... otherwise I'll start stumbling through to see what I can figure out. - Thanks! - - Dave R. - > > I had to set up a jail to test 32 bit ARM on a 64 bit host. If you get past the link error, expect the program to fail at startup. > > $ file /bin/ls /usr/jail/armv7/bin/ls > /bin/ls: ELF 64-bit LSB pie executable, ARM aarch64, version 1 (FreeBSD), dynamically linked, interpreter /libexec/ld-elf.so.1, for FreeBSD 13.2 (1302505), FreeBSD-style, stripped > /usr/jail/armv7/bin/ls: ELF 32-bit LSB executable, ARM, EABI5 version 1 (FreeBSD), dynamically linked, interpreter /libexec/ld-elf.so.1, FreeBSD-style, for FreeBSD 13.2 (1302500), stripped > $ /usr/jail/armv7/bin/ls > ELF interpreter /libexec/ld-elf.so.1 not found, error 8 > Abort trap > > "Not found" means "is not a 32 bit executable." Because both 32 and 64 bit progams use the same intepreter pathname they can't both work. > -- rivers@dignus.com Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com From nobody Thu May 18 18:52:56 2023 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 4QMfHr1rQ2z4Btm3 for ; Thu, 18 May 2023 18:53:12 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic303-25.consmr.mail.gq1.yahoo.com (sonic303-25.consmr.mail.gq1.yahoo.com [98.137.64.206]) (using TLSv1.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 4QMfHq6Fsrz3jrp for ; Thu, 18 May 2023 18:53:11 +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=1684435990; bh=yMRwXlKQa3mxl5ZD+mBjM09KROwVlEs0crxydqoDP9M=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=C8SknhdXyUgTN5/3r6let/Mb8mH6g2Fi0MXwWgVOawejAlWIJelTGzgoqThlskpPBxs0qiyuAGOOEhNyAAziy99FwMb4oN0dYVDZYXKW9w8dBQhkdZDLRiXHBOIzf6owWMkCh8jfuSc8EjhlFYL/7AUHOdtqKothMBTXqjn6/4ZnnHZVj+1+xNZdMLc+g88SBAhvMefj8FJwNybCL9tGBBpGOwQRjOtd2j+RJ64F2FsIedu0F4+8F8Qk+u/hQGhw3Rm105gYNcxGqRwXdbFzZHkYk+10axjz2x4tq4RBEUs6J2QEqoGa+MIeCt32osCjWNQRTIrergJRakM+STJ5Qw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1684435990; bh=HwpErMC6gxneITfAelHZTdKJ6vbc7du5d1IjtuODqVj=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=fkiu1U4H+SDZpfJ9J6KsRRFRqMx71f7O8qHGCk68Q9nsPmbHRYt8zXKUJZQJ0ibMArItIH442NfEvqNlqJjKNQQbLiuFyrQM9nqgi7WjadNhQRMGxtdXAmXsszG3+/PrpcHWcWVwjgTq2nvGk+li+aqqAP+262/0BCxSMqLQ+HknzWsq1AfuE/qVTClozAW6FNxRBLgmA2QtDZleUCOdk0bofDk7IE2SFJOlsD2T+ZHq0SEhPK36WR/opr2bEUUvvgBSnfqVRUGAYzYyUe9iiHEhF4mFMUrmBHL7A1fM5d+oCiSY5/RqtaFtJe6HAqwuEppR2MC1UzQvw+4Xae/YGg== X-YMail-OSG: y1j4G74VM1nbxrzo6WT6hdXXemkeJKvwTopMjqo.Dq.NzQO8dWXBXYFf.jTAPDb s9Lc0Akpru9yAbfxCpEuxtviRU1xkHdhZhX6dhF72YnRIqHQ48OlmVjmrSRyrzbgqVNW75qzwrsy ioearaVxMh9EiToLNhnlJE6Tv5MZY6lZ0qlocctninWVXMtCXoEJBdAZ_ythOBO_hKHds1LmLiAS r4ikP4J2dFsOVmjww6HmwA23D8Y378iAViueZ_vogzQE_50haoQJaErrjfJf_QoPbYDKczHg5Fq9 wV7FNPoSimiLWBbRWoZlSKBxBzdWRmcYpQZfpNRnzqZ.wOIKV5AVAluM.Toxpy1lZyNvzh9S3fsO sHLrp4VlVIlr7HTtQmKrXgLo5yL5hRkTz55tUZHQ_xSTvNqWRnLk8fFU.obxZkalyyZcHJYlKF1B fOBEox64qjPJC1JYMHSenl1okKv1oUuXsuy6es8WsJ8Qd1Z3CAaoTCIq.jGQGhfQu1_xmdUdRPBu 8ezqJVqGSC5T4vFmCHCeCxzRKny2R.YNMWO6pG8GzjS8XbPWpL_9NXuFjuqi6LU_LWT1UCTpCt_A UM9LYVO2DYWBc8yNkruaoAjeHBKIyc3TTyeuXoZ2NLE5YbHEmZkOfFHfKCbUjC5UamFvblWCgrbN 1.a5UL2F_E6JXYsI3HSEXQaSmOZjFbQ.KDRMExmq7VteJrUE90f_ojNGnzS1IVq_a_KckLQ1ulhz yWia0yS2Ia3s1LqBXh5zIiA5xAXXl3OW0PciAFk7LuzvUpBcv_tw4FEOEwkeSo1_fcrs3a14mH1o 11To5MNCw49lTdd78JYSc8OBl7rWpp66mEM1yvh_fjZAm3Hn2Bk8o9QsoMQX_vjoSc31IOFiukYD WaLXlbWJoEF6xPKFy35U4yqhY8umGoh3tic01wNjeJmZ_zzeUTe6Qh_sfUCr316NWAC0EVHae61q eWCABGTfFdwd8yDN3zjL6mM7_ax_e0.LXMaChRDgX9XF8TQiw_aGdgm2HAhhVtxu8Zk_uzUW.aV2 UQzDHmGCh4yH5uzh5LIc5_PpdWnhzFc8mJkwO2XnuUS2TrUpSGgm.iY4Zv7jfj8cP.L8Ja46GX2T gPm.q8e83b44O8sR6OxRt44NRQ4IgKkTTESuso4o56eH_5fT3PrS1eKtkZBBRtUqGClpuKZJ0VZ5 XI_0CVMohaZVLVqJQxTpkmJDy3KYJsZ0BOWWTY.eNUFpyJ0Nqh058OJRBMPlLWMv1Gs47mpGQJjm 1Oo9r.NepBdJsgKo3abxZI7GAlMJHwKzmAAv_ugHmOzo1b67xUc3u5snhqS8AXOFWakv.OYf6GAi 3R5S4frfVNt3VRcDbZoIzQaaiLoq6K1T.SlATqkwk7M.QeNftnXYfqzJuVPKG4E3T46atMs9Q8N4 xTg2f0LSMiAkDbP_SAu0Vgin.S_zD5cC3epikMXOj2lf3OQhiDY7dUg57nk033ZgG0efQTJMfoBg Dg9bUN_xjP2nG.6j6fqBXHCmTq5wmX9HWCalb.38zGBn5Hq1Xulblk1ZnQTiyXOPtfkq8Zx44g6b Ov0Sun2vOS.Ck8X6QL2uYUt6DmUoGx9xusxWhDEUF0zBG5YcEFURHbW9lr2MiER8shpoPBxv4.TI uBXl03M7AwmsngDtfou_6Ct13WU0mhmAc35usEsxIve7mC_G6smRMds5GUMiyK3fCpQkRZ_IMmCW fwYBCZort_Zl29Se_XDCjdVr625LhLASyqrowec0SQnesUEy_WqoIWZVQu1G2tAJfY2j_xiGsHGT .gzg0w34xPSbA07qj8NrbwiK.jk0nAKNQxBKVasunStmuFEKcczJazp74xinyQ5.Me3uDRbRP2G4 ClA_6rOeNIxvsYTvJuLp4u2gsRp86ZuALXqm4fxSPW5L2K5IPOlufs_NLcvPTV9KlCFGFxunWyPK oncYH6ZAmsviB90kSChzAZT_QFUIxnE9bl3C_dpkDSP0gnzodtYDdZWX_gJZljMtj0hamy4.24rd vCQ0mEBz273Fu1JiPdayVegaTZUPibfqGD_hjHsawr.COB6KgY3D4KX4S.iGTkwCIOaR3bLLqjwJ JaXBzf3E98LoYuoBwe3GA.6Z9EhfAV4BiemuG.UOo3cFj6zyBehJ2s9NDGQEzUnY9w.cE9Pxpw_0 7ziUzFB51gSJrt5JtgbmRypXLsG_cbafz61JG3TTTF0rUY8ekSRn4d318aZIoyvjEi0dL7NvKIi5 GzNmPFYYSsNbCZ3QmnZv0uIzwTAzD7KWdiZJIlFN4p6BBvSjPceldSn_zF0mkEh9zr4UUf7adb7x vHg-- X-Sonic-MF: X-Sonic-ID: 35905dd6-5982-4b91-8a5d-76ce9bcc3274 Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.gq1.yahoo.com with HTTP; Thu, 18 May 2023 18:53:10 +0000 Received: by hermes--production-ne1-574d4b7954-q7frw (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID aa2a05a9d34eb13d3a1e41238bb07b1d; Thu, 18 May 2023 18:53:08 +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 \(3731.400.51.1.1\)) Subject: Re: 32-bit executables on aarch64? From: Mark Millard In-Reply-To: <46BE47DA-9306-4682-8320-D2CBEB5918F7@mit.edu> Date: Thu, 18 May 2023 11:52:56 -0700 Cc: John F Carr , "freebsd-arm@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <9916CA51-E1F3-45C5-A489-6731B12D6F65@yahoo.com> References: <202305181816.34IIGA8P024382@office.dignus.com> <46BE47DA-9306-4682-8320-D2CBEB5918F7@mit.edu> To: Thomas David Rivers X-Mailer: Apple Mail (2.3731.400.51.1.1) X-Rspamd-Queue-Id: 4QMfHq6Fsrz3jrp X-Spamd-Bar: ---- 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] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On May 18, 2023, at 11:22, John F Carr wrote: > I had to set up a jail to test 32 bit ARM on a 64 bit host. I just install a armv7 world in a directory tree and have a script that does a chroot into the directory tree after devfs and nullfs mounts (and also does the umount's). An example: # more ~/do-chroot-main-CA7.sh=20 #! /bin/sh mkdir -p /usr/obj/DESTDIRs/main-CA7-chroot/dev/ \ && mount -tdevfs devfs /usr/obj/DESTDIRs/main-CA7-chroot/dev/ \ && mkdir -p = /usr/obj/DESTDIRs/main-CA7-chroot/usr/local/poudriere/data/packages/main-C= A7-default/ \ && mount_nullfs /usr/local/poudriere/data/packages/main-CA7-default \ = /usr/obj/DESTDIRs/main-CA7-chroot/usr/local/poudriere/data/packages/main-C= A7-default/ \ && mkdir -p /usr/obj/DESTDIRs/main-CA7-chroot/usr/ports/ \ && mount_nullfs /usr/ports /usr/obj/DESTDIRs/main-CA7-chroot/usr/ports/ = \ && env IN_CHROOT=3D"main-CA7-chroot" chroot = /usr/obj/DESTDIRs/main-CA7-chroot/ umount /usr/obj/DESTDIRs/main-CA7-chroot/usr/ports/ umount = /usr/obj/DESTDIRs/main-CA7-chroot/usr/local/poudriere/data/packages/main-C= A7-default/ umount /usr/obj/DESTDIRs/main-CA7-chroot/dev/ ("IN_CHROOT" is something specific to what I set up.) Clearly I adjust some material in the armv7 world as well, such as causing it to use the path: /usr/local/poudriere/data/packages/main-CA7-default/ > If you get past the link error, expect the program to fail at startup. Yea, no system lib32 for enabling armv7 programs directly. (powerpc64 and powerpc is an example context where lib32 was put in place.) > $ file /bin/ls /usr/jail/armv7/bin/ls > /bin/ls: ELF 64-bit LSB pie executable, ARM aarch64, = version 1 (FreeBSD), dynamically linked, interpreter = /libexec/ld-elf.so.1, for FreeBSD 13.2 (1302505), FreeBSD-style, = stripped > /usr/jail/armv7/bin/ls: ELF 32-bit LSB executable, ARM, EABI5 version = 1 (FreeBSD), dynamically linked, interpreter /libexec/ld-elf.so.1, = FreeBSD-style, for FreeBSD 13.2 (1302500), stripped > $ /usr/jail/armv7/bin/ls > ELF interpreter /libexec/ld-elf.so.1 not found, error 8 > Abort trap >=20 > "Not found" means "is not a 32 bit executable." Because both 32 and = 64 bit progams use the same intepreter pathname they can't both work. >=20 >=20 >> On May 18, 2023, at 14:16, Thomas David Rivers = wrote: >>=20 >>=20 >> Tried the following with a small "hello world" program on=20 >> FreeBSD freebsd 13.2-RELEASE FreeBSD 13.2-RELEASE = releng/13.2-n254617-525ecfdad597 GENERIC arm64 >>=20 >> # cc -m32 hello.c >>=20 >> To get these errors: >>=20 >> ld: error: /tmp/hello-1eb3b8.o is incompatible with /usr/lib/crt1.o >> cc: error: linker command failed with exit code 1 (use -v to see = invocation) >>=20 >> Is building a 32-bit program not supported on 13.2 arm64? >>=20 >> man cc >>=20 >> gave me the CLANG doc... which didn't even mention "m32"; so perhaps >> I just need a different set of options? I tried -arch arm but I = still >> got 64-bit code. Also, I tried several other -arch options and = didn't >> see a difference, even with -arch x86, I still got Aarch64 code. >>=20 >> - Many thanks! - >> - Dave Rivers - >>=20 >> -- >> rivers@dignus.com Work: (919) 676-0847 >> Get your mainframe programming tools at http://www.dignus.com >>=20 >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Fri May 19 02:49:03 2023 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 4QMrrz3NzVz4CKky for ; Fri, 19 May 2023 02:49:07 +0000 (UTC) (envelope-from rivers@dignus.com) Received: from dignus.com (adsl-065-013-223-202.sip.rdu.bellsouth.net [65.13.223.202]) (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 "office.dignus.com", Issuer "office.dignus.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QMrry0MVCz3DbB for ; Fri, 19 May 2023 02:49:05 +0000 (UTC) (envelope-from rivers@dignus.com) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of rivers@dignus.com designates 65.13.223.202 as permitted sender) smtp.mailfrom=rivers@dignus.com; dmarc=none Received: from office.dignus.com (localhost [127.0.0.1]) by dignus.com (8.16.1/8.16.1) with ESMTPS id 34J2n3kV029622 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Thu, 18 May 2023 22:49:03 -0400 (EDT) (envelope-from rivers@office.dignus.com) X-Authentication-Warning: office.dignus.com: Host localhost [127.0.0.1] claimed to be office.dignus.com Received: (from rivers@localhost) by office.dignus.com (8.16.1/8.16.1/Submit) id 34J2n3hg029621 for freebsd-arm@freebsd.org; Thu, 18 May 2023 22:49:03 -0400 (EDT) (envelope-from rivers) Date: Thu, 18 May 2023 22:49:03 -0400 (EDT) From: Thomas David Rivers Message-Id: <202305190249.34J2n3hg029621@office.dignus.com> To: freebsd-arm@freebsd.org Subject: some QEMU success in running armv7 X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=unavailable autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on office.dignus.com X-Spamd-Result: default: False [-0.79 / 15.00]; HFILTER_HOSTNAME_4(2.50)[adsl-065-013-223-202.sip.rdu.bellsouth.net]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.985]; R_SPF_ALLOW(-0.20)[+ip4:65.13.223.202:c]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[dignus.com]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; ARC_NA(0.00)[]; R_DKIM_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; MID_RHS_MATCH_FROMTLD(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; ASN(0.00)[asn:7018, ipnet:65.13.220.0/22, country:US]; FROM_HAS_DN(0.00)[]; FREEFALL_USER(0.00)[rivers]; TO_DN_NONE(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; HAS_XAW(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; RCVD_TLS_LAST(0.00)[] X-Rspamd-Queue-Id: 4QMrry0MVCz3DbB X-Spamd-Bar: / X-ThisMailContainsUnwantedMimeParts: N 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 Just f.y.i. - here's the steps I was able to deduce today to get FreeBSD armv7 running under qemu... just in case someone goes looking for this... (I was doing this on a FreeBSD 12.3-RELEASE x86_64 system.) 1. Retrieve the armv7 image from: fetch https://download.freebsd.org/releases/arm/armv7/ISO-IMAGES/13.2/FreeBSD-13.2-RELEASE-arm-armv7-GENERICSD.img.xz and unzip it. This is an actual hard-drive image of a working system. 2. Assuming the qemu port has been installed - this command starts that system qemu-system-arm -M virt -m 512m -nographic \ -bios edk2-arm-code.fd \ -hda FreeBSD-13.2-RELEASE-arm-armv7-GENERICSD.img the existing terminal will be the console. There is no networking. There root user's password is 'root'. Unfortunately this doesn't provide networking in the guest. This compilation of QEMU also doesn't support the "-netdev user" mode of networking so I can't take advantage of that. (The FreeBSD 12.3 host is using QEMU emulator version 7.2.0 - from just the pkg install.) However, I found that using this option on qemu: -nic tap,ifname=tap7,script=no,downscript=no got it to use the tap interface on the host to emulate the virtio device to the guest. I also found this discussion regarding alignment issues in the virtio driver in armv7: https://forums.freebsd.org/threads/kernel-panic-on-armv7-with-qemu.89016/#post-610281 that resulted in PR 271288. Apparently it's because of newer versions of QEMU doing a better job at reporting unaligned memory accesses in the guest for the armv7 "ldm" instruction. When I use the tap interface, I did get the exact panic mentioned in the forum and the PR. I did find that specifying the rtl8139 device worked around the panic with the QEMU option: -nic tap,ifname=tap7,script=no,downscript=no,model=rtl8139 by the way - tap7 happens to be a tap device I'd already configured on the host FreeBSD 12.3 system - if you're doing this yourself, it will likely need to be a different tap device, see this write-up for info about how to configure a tap + bridge on your FreeBSD host: http://bsdwiki.reedmedia.net/wiki/networking_qemu_virtual_bsd_systems.html So - it seems a newer version of the armv7 kernel with the patch applied will fix the virtio driver problem, until then, model=rtl8139 works around it and I have networking and everything! - Dave R. - -- rivers@dignus.com Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com From nobody Fri May 19 07:37:13 2023 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 4QMzFf6tCFz4Bbw0 for ; Fri, 19 May 2023 07:37:26 +0000 (UTC) (envelope-from eduardo@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 4QMzFf60w0z44Nf for ; Fri, 19 May 2023 07:37:26 +0000 (UTC) (envelope-from eduardo@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1684481846; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=s0b94eOvefp3+7WEvu2drvDFIJlEZ7IlaghX00vjBBw=; b=D+bPbitjQo46ixNGp2Tvk9MSnJ81j5e9XohVEL2eAUDFGj6GXBTM7vIwtWvFJiEaE++IJX 8Fu5YYhfl9Wvz+i4W/FuAq0nh1HxGxKgNhGR+JLw3ziAHQvMtnkX9IYungdkoZtvaOKe8l tdEivucRKcySYV9DcQwkJwPr4VPUFVcHavsXpIYy35zrX+Esqu6gyS3dirzc5Fs/3WfQo9 LgWlV4QmZop2oXkHJ0cXF49Zh4p7bwmbroU887QCmmO6hCvIBC5MYTaelQRWc3FrA7bEZh tg4mMNqWthTy9vPKYjbnLQocCK7MqjEE3XkloZhpeKwXY0a9kuas5S5f096MZw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1684481846; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=s0b94eOvefp3+7WEvu2drvDFIJlEZ7IlaghX00vjBBw=; b=cXwTYEl9bGnvYBBPNOr3w5wMzrbv2gTUSSVAc/m4964jt2B3LNIoV83xF5+ezFLKkuqiKW nywVvVeIf6fX7GnHRX/A5//5RCUyuhWs00c7woXXDbnMmVH4RZfL7TcAweYSRtKA12I2m6 9n/8+6ohuRRVz7QtRYgCI8ZNtYM5k10GfbiGuPJJ9v6VxF8UXlqMTlU0j7yhvuhd0/3/5f RwYDtNmL2iequydhCd2KRxVKxiYrJkEuZX8myypw0hvgZataEUvDf6CGyTsQc0FDg2sVcZ c4X5TCZePiMXrhpB0MYAlRmIZNUKeUeZTinJk/nRc1++griuTNCUVQgO/uWvig== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1684481846; a=rsa-sha256; cv=none; b=uMmGTKH4DanezR1YgTtjDSj+GalAJeYWMtqHUAF5wnA0nYLcCJkmLyvSxoj6LLAQZtGECv g9ZaO+92iKzgxbdzhLn6eCXGaJhAB8in+qwDb+B9zDhnJa6io2+XFi6uU+lA+Ak/JrAQUw s+jUxyC+S30prUzvQ5zFbJJKR1LaP8n/m1rlNmhWmU3xo0Sm3f+A+x4FclJaPNw2LgdX7y GjZgejHL+ftXuwjZ++TBKhWuEQ14viKMIHOgDXBsGTo5JcRsy9mOOizAJjNhwHJscrS/Ln pXk4JczUYluYFeaSvtbFbUB0U658XRCU3ijfJi9YwxZ9pXTxGe/GBGq5m3PyUQ== Received: from mail-pj1-f50.google.com (mail-pj1-f50.google.com [209.85.216.50]) (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)) (Authenticated sender: eduardo) by smtp.freebsd.org (Postfix) with ESMTPSA id 4QMzFf4XvLzl2c for ; Fri, 19 May 2023 07:37:26 +0000 (UTC) (envelope-from eduardo@freebsd.org) Received: by mail-pj1-f50.google.com with SMTP id 98e67ed59e1d1-253520adb30so1629729a91.1 for ; Fri, 19 May 2023 00:37:26 -0700 (PDT) X-Gm-Message-State: AC+VfDzqwOm3NpN/dlAj0og2OuGjBAcrztPfXaVU7XPHLZu6Bqz/U9mj 7jwxglEWnW/NBlWn3420heghOUptSCN3TOVkY4s= X-Google-Smtp-Source: ACHHUZ5a0xKUPLeqgDuV3bCduEAnp/HKw/ma6HYS42GY3Frd32fPKfyFFxgEOnr2MNVLOpA6xUfXgiLRK+b3rPtisXA= X-Received: by 2002:a17:90b:1109:b0:253:84dd:142c with SMTP id gi9-20020a17090b110900b0025384dd142cmr793267pjb.4.1684481845620; Fri, 19 May 2023 00:37:25 -0700 (PDT) List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 References: <77CD0716-3BC8-47EB-8743-F2BD9CA43D31@yahoo.com> <432A1A16-9FE5-4339-AB38-8F3E03A5D4EF@yahoo.com> In-Reply-To: From: Nuno Teixeira Date: Fri, 19 May 2023 08:37:13 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Raspberry Pi POE+ hat overlay To: Mark Millard Cc: Doug Rabson , freebsd-arm@freebsd.org Content-Type: multipart/alternative; boundary="00000000000009f75005fc06fe05" X-ThisMailContainsUnwantedMimeParts: N --00000000000009f75005fc06fe05 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for great explanation about overclocking and firmware. I was lost between firmware versions used in raspberry linux and freebsd port. Now I have a better picture of why this setup make sense for a specific firmware. I will stick with freq 2000 as my first goal was to set to 1800. And for now on, I will be watching firmware port version updates to check changes carefully. Yours, Mark Millard escreveu no dia quinta, 18/05/2023 =C3=A0(= s) 18:07: > On May 18, 2023, at 05:48, Nuno Teixeira wrote: > > > Indeed, voltage was the missing bit! > > > > I'm trying to setup 1800 as default now for revs >=3D 1.4 following > https://www.raspberrypi.com/news/bullseye-bonus-1-8ghz-raspberry-pi-4/ > that only talk about setting arm_freq=3D1800 but doesn't mention to adjus= t > voltage. > > It was nice that raspberry tell us what voltage exacly value they use > for new default 1800. > > > > What I've got now is: > > > > [pi4] > > over_voltage=3D6 > > arm_freq=3D2000 > > sdram_freq_min=3D3200 > > ### force_turbo=3D1 > > > > My tests shows that we don't need force_turbo=3D1 for a normal running = and > system do an auto 600 -> 2000 change when needed. Thats nice. > > I will note that the RPi* firmware itself varies the > frequency and voltages by default --but the way of > disabling that also disables powerd from being > effective as I understand. (As I understand the > firmware's policy details have changed over time > but I do not know the details or when.) > > This makes use of powerd on the RPi*, with the firmware's > adjustments also enabled, involve 2 competing mechanisms, > if I understand right. I'm not aware of any horrible > consequences in actual ooperation but I found force_turbo > to lead to less time being taken in build activities back > when I last measured it. > > It is true that I've not looked into this area in a long > time. > > > Also, arm_boost=3D1 with force_turbo or not, is ignored. > > > https://github.com/raspberrypi/documentation/blob/8b096a52e394c10360549af= d0a620755df467446/documentation/asciidoc/computers/config_txt/overclocking.= adoc > > (from 2021-Nov-04) did not have arm_boost documented yet. > > > https://github.com/raspberrypi/documentation/blob/da45bd8c982e91e11c60999= 1ba2fc8783872ef67/documentation/asciidoc/computers/config_txt/overclocking.= adoc > > (from 2021-Nov-11) has arm_boost documented. > > These give a clue about the vintage of RPi* firmware needed > to have the arm_boost notation implemented. > > > sdram_freq and sdram_freq_min are set to 3200 by default, so I think I > will not need sdram_freq_min=3D3200 here. > > > https://github.com/raspberrypi/documentation/blob/2cbcd18fc155044f20ae630= 5fa0e62629b56893c/configuration/config-txt/overclocking.md > > (from 2021-Mar-31) shows the Pi4 sdram_freq_min as 400. > The defaults have changed with firmware updates. > > Note that the official RPi* port has 2021-Mar-03 firmware, > so before 2021-Mar-31. > > > https://github.com/raspberrypi/documentation/blob/75e6050edd9e1b0c47c5862= 3133dc05a02c16351/documentation/asciidoc/computers/config_txt/overclocking.= adoc > > (from 2021-Aug-09) shows the Pi4/CM4 sdram_freq_min as 3200. > > These give a clue about the vintage of RPi* firmware needed > to have the sdram_freq_min be 3200 by default. > > My settings are for a wide range of firmware vintages, not > just modern ones. Each item was shown (at the time added) > was shown to cut the times for the likes of buildworld, > buildkernel, or poudriere bulk activities that I did. > > Also, I tend to leave in place what has worked and still > does work, rather than to track the changes in defaults > over time in even more detail. I'd likely have different > settings listed if I'd started at a later point that had > newer defaults. > > > The only thing that I can't understand is how to calculate voltage: > > > > over_voltage: 0 (1.35V, 1.2V on Raspberry Pi 1) ??? > > ( https://www.raspberrypi.com/documentation/computers/config_txt.html ) > > > > Also, "7. Take it to the max" ( > https://magpi.raspberrypi.com/articles/how-to-overclock-raspberry-pi-4 ): > > > > over_voltage=3D6 (?) > > arm_freq=3D2147 > > gpu_freq=3D750 > > I'll note that I never attempted to take each RPi4B to > its maximum for normal operation. I targeted having a > setting combination that was reliable (had some margin) > on all the example RPi4B's. > > I did have to explore were failures occured to do that. > I did have access to RPi4B's that were unreliable with > arm_freq=3D2100 for any over_voltage that I tried. Backing > off to 2000 gave me reliable results on all the RPi4B's. > > I never had trouble with sdram_freq_min=3D3200 but it did > help in contexts with the default being 400. > > > Thanks, > > > > > > Mark Millard escreveu no dia quinta, 18/05/2023 > =C3=A0(s) 11:57: > > On May 18, 2023, at 01:29, Nuno Teixeira wrote: > > > > > Confirmed that arm_boost is enable by default on rpi4 rev >=3D 1.4 as= I > checked with htop. > > > > > > Also, tested arm_freq=3D1800 and it crashes FreeBSD around initializi= ng > console/video and detecting mouse. > > > > Overclocking by setting the arm_freq directly involves also > > managing over_voltage explicitly, such as: > > > > over_voltage=3D6 > > > > A sequence I use (and have used for a long time) is: > > > > [pi4] > > over_voltage=3D6 > > arm_freq=3D2000 > > sdram_freq_min=3D3200 > > force_turbo=3D1 > > > > But each RPi4B has heatsinks, a case with a fan, > > and a power supply rated for 5.1V 3.5A (so: has > > some extra margin). > > > > But the range of RPi4B's span Rev 1.1, Rev 1.4, > > and Rev 1.5, a mix of 4 GiByte RAM and 8 GiByte > > RAM models. All use those settings. > > > > As I understand, arm_boost implicitly does the > > extra things required for its implicit frequency, > > unlike assigning arm_freq or the like. > > > > If force_turbo is not used, it can be that: > > > > # > > # Local addition that avoids USB3 SSD boot failures that look like: > > # uhub_reattach_port: port ? reset failed, error=3DUSB_ERR_TIMEOUT > > # uhub_reattach_port: device problem (USB_ERR_TIMEOUT), disabling por= t > ? > > initial_turbo=3D60 > > > > is required for USB based booting. But this also > > gets into if the notation is supported or not for > > the firmware vintage used. > > > > The initial_turbo use happens to avoid frequency > > variability during boot and it appears that FreeBSD > > does not necessarily tolerate such variability in > > that time frame. > > > > Also: I happen to have USB3 boot media for which use > > of usb_pgood_delay=3D2000 is sufficient but without > > some such in/for U-Boot, U-Boot has problems > > recognizing the device (before FreeBSD is even > > involved). I build the U-Boot port with the > > assignment built in. > > > > > As linux config.txt says: > > > --- > > > [pi4] > > > # Run as fast as firmware / board allows > > > arm_boost=3D1 > > > --- > > > firmware must be updated to support this feature for sure. > > > > I'm not aware of a dated list of when the various > > config.txt notations were first supported (firmware > > version). This makes it messier to use the web's > > published information, if one is using the firmware > > vintage that FreeBSD has in its port for the > > firmware. > > > > The notation that I use has been around for a long > > time. > > > > > Cheers, > > > > > > Nuno Teixeira escreveu no dia quarta, > 17/05/2023 =C3=A0(s) 14:08: > > > (...) > > > > > > I was meant using 13.2 not 12.3 :) > > > > > > Doug Rabson escreveu no dia quarta, 17/05/2023 =C3= =A0(s) > 13:47: > > > I'm not sure about 12.3 either - you could try with 13.2 and see if > that makes a difference. > > > > > > On Wed, 17 May 2023 at 13:45, Nuno Teixeira > wrote: > > > Hey, > > > > > > Ok. I'm new to rpi4 and arm in general but tomorrow I will force > 'arm_freq=3D1800' again just to see it it crashes again. > > > I will check too what values linux shows. > > > > > > I don't know if firmware/uboot version included in 12.3 supports this > feature. > > > > > > Cheers, > > > > > > Doug Rabson escreveu no dia quarta, 17/05/2023 =C3= =A0(s) > 13:11: > > > Hi Nuno, > > > > > > I'm not sure where to start - I just happened to notice in the > documentation here: > https://www.raspberrypi.com/documentation/computers/config_txt.html that > the cpu frequency Pi4B R1.4 was listed as 1800 if arm_boot=3D1 so I tried= it. > > > > > > Doug. > > > > > > > > > > > > On Wed, 17 May 2023 at 11:11, Nuno Teixeira > wrote: > > > Hello Doug, > > > > > > I have too a 1.5 rpi but arm_boost=3D1 isn't doing anything, htop sho= ws > 1500Mhz when doing something intensive. > > > I'm running 13.2 stable > > > > > > Do I missing something? > > > > > > Could you take a look at my setup? > > > > > > Thanks, > > > > > > Doug Rabson escreveu no dia ter=C3=A7a, 16/05/2023 = =C3=A0(s) > 17:19: > > > > > > On Sat, 13 May 2023 at 13:45, Doug Rabson wrote: > > > I was able to build an updated rpi-firmware port based on 1.20210805 > and this boots successfully on pi400 as well as rpi4. With this, I can lo= ad > the rpi-poe-plus overlay and I just need to try and reverse engineer the > undocumented mailbox API by reading the Linux code. > > > > > > I have a first approximation of a fan driver which works with the > 1.20210805 firmware (actually, I substituted rpi-poe-plus.dtbo from > 1.20210831 which just changes the fan levels for the POE+). I'm testing > with an rpi4B rev 1.5 with 'make -j4 buildworld' and the fan is keeping t= he > cpu temperature below 65 degrees which is nice, especially since I set > arm_boost=3D1 in config.txt which boosts the cpu frequency up to 1800 for > this board. > > > > > > Does anyone have a pointer to the problem with firmware later than > 20210805? Would it make any kind of sense to try to get the fix into > releng/13.2 as an errata? > > > > > > > =3D=3D=3D > Mark Millard > marklmi at yahoo.com > > --=20 Nuno Teixeira FreeBSD Committer (ports) --00000000000009f75005fc06fe05 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for great explanation about overclocking and f= irmware.
I was lost between firmware versions used in raspberry l= inux and freebsd port.

Now I have a better picture= of why this setup make sense for a specific firmware.

=
I will stick with freq 2000 as my first goal was to set to 1800.

And for now on, I will be watching firmware port ve= rsion updates to check changes carefully.=C2=A0

Yo= urs,

Mark Millard <markl= mi@yahoo.com> escreveu no dia quinta, 18/05/2023 =C3=A0(s) 18:07:
On May 18, 2023, a= t 05:48, Nuno Teixeira <eduardo@freebsd.org> wrote:

> Indeed, voltage was the missing bit!
>
> I'm trying to setup 1800 as default now for revs >=3D 1.4 follo= wing https://www.raspberrypi.c= om/news/bullseye-bonus-1-8ghz-raspberry-pi-4/ that only talk about sett= ing arm_freq=3D1800 but doesn't mention to adjust voltage.
> It was nice that raspberry tell us what voltage exacly value they use = for new default 1800.
>
> What I've got now is:
>
> [pi4]
> over_voltage=3D6
> arm_freq=3D2000
> sdram_freq_min=3D3200
> ### force_turbo=3D1
>
> My tests shows that we don't need force_turbo=3D1 for a normal run= ning and system do an auto 600 -> 2000 change when needed. Thats nice.
I will note that the RPi* firmware itself varies the
frequency and voltages by default --but the way of
disabling that also disables powerd from being
effective as I understand. (As I understand the
firmware's policy details have changed over time
but I do not know the details or when.)

This makes use of powerd on the RPi*, with the firmware's
adjustments also enabled, involve 2 competing mechanisms,
if I understand right. I'm not aware of any horrible
consequences in actual ooperation but I found force_turbo
to lead to less time being taken in build activities back
when I last measured it.

It is true that I've not looked into this area in a long
time.

> Also, arm_boost=3D1 with force_turbo or not, is ignored.

https://github.com/rasp= berrypi/documentation/blob/8b096a52e394c10360549afd0a620755df467446/documen= tation/asciidoc/computers/config_txt/overclocking.adoc

(from 2021-Nov-04) did not have arm_boost documented yet.

https://github.com/rasp= berrypi/documentation/blob/da45bd8c982e91e11c609991ba2fc8783872ef67/documen= tation/asciidoc/computers/config_txt/overclocking.adoc

(from 2021-Nov-11) has arm_boost documented.

These give a clue about the vintage of RPi* firmware needed
to have the arm_boost notation implemented.

> sdram_freq and sdram_freq_min are set to 3200 by default, so I think I= will not need sdram_freq_min=3D3200 here.

https://github.com/raspberrypi/documentation= /blob/2cbcd18fc155044f20ae6305fa0e62629b56893c/configuration/config-txt/ove= rclocking.md

(from 2021-Mar-31) shows the Pi4 sdram_freq_min as 400.
The defaults have changed with firmware updates.

Note that the official RPi* port has 2021-Mar-03 firmware,
so before 2021-Mar-31.

https://github.com/rasp= berrypi/documentation/blob/75e6050edd9e1b0c47c58623133dc05a02c16351/documen= tation/asciidoc/computers/config_txt/overclocking.adoc

(from 2021-Aug-09) shows the Pi4/CM4 sdram_freq_min as 3200.

These give a clue about the vintage of RPi* firmware needed
to have the sdram_freq_min be 3200 by default.

My settings are for a wide range of firmware vintages, not
just modern ones. Each item was shown (at the time added)
was shown to cut the times for the likes of buildworld,
buildkernel, or poudriere bulk activities that I did.

Also, I tend to leave in place what has worked and still
does work, rather than to track the changes in defaults
over time in even more detail. I'd likely have different
settings listed if I'd started at a later point that had
newer defaults.

> The only thing that I can't understand is how to calculate voltage= :
>
> over_voltage: 0 (1.35V, 1.2V on Raspberry Pi 1) ???
> ( https://www.raspberrypi.co= m/documentation/computers/config_txt.html )
>
> Also, "7. Take it to the max" ( https://magpi.raspberrypi.com/articles/how-to-overclock-ra= spberry-pi-4 ):
>
> over_voltage=3D6 (?)
> arm_freq=3D2147
> gpu_freq=3D750

I'll note that I never attempted to take each RPi4B to
its maximum for normal operation. I targeted having a
setting combination that was reliable (had some margin)
on all the example RPi4B's.

I did have to explore were failures occured to do that.
I did have access to RPi4B's that were unreliable with
arm_freq=3D2100 for any over_voltage that I tried. Backing
off to 2000 gave me reliable results on all the RPi4B's.

I never had trouble with sdram_freq_min=3D3200 but it did
help in contexts with the default being 400.

> Thanks,
>
>
> Mark Millard <marklmi@yahoo.com> escreveu no dia quinta, 18/05/2023 =C3=A0(s) 11= :57:
> On May 18, 2023, at 01:29, Nuno Teixeira <eduardo@freebsd.org> wrote:
>
> > Confirmed that arm_boost is enable by default on rpi4 rev >=3D= 1.4 as I checked with htop.
> >
> > Also, tested arm_freq=3D1800 and it crashes FreeBSD around initia= lizing console/video and detecting mouse.
>
> Overclocking by setting the arm_freq directly involves also
> managing over_voltage explicitly, such as:
>
> over_voltage=3D6
>
> A sequence I use (and have used for a long time) is:
>
> [pi4]
> over_voltage=3D6
> arm_freq=3D2000
> sdram_freq_min=3D3200
> force_turbo=3D1
>
> But each RPi4B has heatsinks, a case with a fan,
> and a power supply rated for 5.1V 3.5A (so: has
> some extra margin).
>
> But the range of RPi4B's span Rev 1.1, Rev 1.4,
> and Rev 1.5, a mix of 4 GiByte RAM and 8 GiByte
> RAM models. All use those settings.
>
> As I understand, arm_boost implicitly does the
> extra things required for its implicit frequency,
> unlike assigning arm_freq or the like.
>
> If force_turbo is not used, it can be that:
>
> #
> # Local addition that avoids USB3 SSD boot failures that look like: > #=C2=A0 =C2=A0uhub_reattach_port: port ? reset failed, error=3DUSB_ERR= _TIMEOUT
> #=C2=A0 =C2=A0uhub_reattach_port: device problem (USB_ERR_TIMEOUT), di= sabling port ?
> initial_turbo=3D60
>
> is required for USB based booting. But this also
> gets into if the notation is supported or not for
> the firmware vintage used.
>
> The initial_turbo use happens to avoid frequency
> variability during boot and it appears that FreeBSD
> does not necessarily tolerate such variability in
> that time frame.
>
> Also: I happen to have USB3 boot media for which use
> of usb_pgood_delay=3D2000 is sufficient but without
> some such in/for U-Boot, U-Boot has problems
> recognizing the device (before FreeBSD is even
> involved). I build the U-Boot port with the
> assignment built in.
>
> > As linux config.txt says:
> > ---
> > [pi4]
> > # Run as fast as firmware / board allows
> > arm_boost=3D1
> > ---
> > firmware must be updated to support this feature for sure.
>
> I'm not aware of a dated list of when the various
> config.txt notations were first supported (firmware
> version). This makes it messier to use the web's
> published information, if one is using the firmware
> vintage that FreeBSD has in its port for the
> firmware.
>
> The notation that I use has been around for a long
> time.
>
> > Cheers,
> >
> > Nuno Teixeira <eduardo@freebsd.org> escreveu no dia quarta, 17/05/2023 = =C3=A0(s) 14:08:
> > (...)
> >
> > I was meant using 13.2 not 12.3 :)
> >
> > Doug Rabson <dfr@rabson.org> escreveu no dia quarta, 17/05/2023 =C3=A0(s) 13:4= 7:
> > I'm not sure about 12.3 either - you could try with 13.2 and = see if that makes a difference.
> >
> > On Wed, 17 May 2023 at 13:45, Nuno Teixeira <eduardo@freebsd.org> wrote:<= br> > > Hey,
> >
> > Ok. I'm new to rpi4 and arm in general but tomorrow I will fo= rce 'arm_freq=3D1800' again just to see it it crashes again.
> > I will check too what values linux shows.
> >
> > I don't know if firmware/uboot version included in 12.3 suppo= rts this feature.
> >
> > Cheers,
> >
> > Doug Rabson <dfr@rabson.org> escreveu no dia quarta, 17/05/2023 =C3=A0(s) 13:1= 1:
> > Hi Nuno,
> >
> > I'm not sure where to start - I just happened to notice in th= e documentation here: https://www= .raspberrypi.com/documentation/computers/config_txt.html that the cpu f= requency Pi4B R1.4 was listed as 1800 if arm_boot=3D1 so I tried it.
> >
> > Doug.
> >
> >
> >
> > On Wed, 17 May 2023 at 11:11, Nuno Teixeira <eduardo@freebsd.org> wrote:<= br> > > Hello Doug,
> >
> > I have too a 1.5 rpi but arm_boost=3D1 isn't doing anything, = htop shows 1500Mhz when doing something intensive.
> > I'm running 13.2 stable
> >
> > Do I missing something?
> >
> > Could you take a look at my setup?
> >
> > Thanks,
> >
> > Doug Rabson <dfr@rabson.org> escreveu no dia ter=C3=A7a, 16/05/2023 =C3=A0(s) = 17:19:
> >
> > On Sat, 13 May 2023 at 13:45, Doug Rabson <dfr@rabson.org> wrote:
> > I was able to build an updated rpi-firmware port based on 1.20210= 805 and this boots successfully on pi400 as well as rpi4. With this, I can = load the rpi-poe-plus overlay and I just need to try and reverse engineer t= he undocumented mailbox API by reading the Linux code.
> >
> > I have a first approximation of a fan driver which works with the= 1.20210805 firmware (actually, I substituted rpi-poe-plus.dtbo from 1.2021= 0831 which just changes the fan levels for the POE+). I'm testing with = an rpi4B rev 1.5 with 'make -j4 buildworld' and the fan is keeping = the cpu temperature below 65 degrees which is nice, especially since I set = arm_boost=3D1 in config.txt which boosts the cpu frequency up to 1800 for t= his board.
> >
> > Does anyone have a pointer to the problem with firmware later tha= n 20210805? Would it make any kind of sense to try to get the fix into rele= ng/13.2 as an errata?
> >



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



--
Nuno Teixeira
FreeBSD Committ= er (ports)
--00000000000009f75005fc06fe05-- From nobody Fri May 19 07:38:56 2023 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 4QMzHd4VvQz4Bc9V for ; Fri, 19 May 2023 07:39:09 +0000 (UTC) (envelope-from eduardo@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 4QMzHd4DhTz44Qt for ; Fri, 19 May 2023 07:39:09 +0000 (UTC) (envelope-from eduardo@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1684481949; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=WNaSK62FL/VbKyzgPcGpXScfG7m3EzvaNnXyeno7CgM=; b=TefcpTzJJhQv338QJDjnsKp5hOJ9RDSSeL0GrZPsCOF9b9dW8pqYYJrxMiVA0u0oeam5t0 JACsOcOrQOz2gnsHt+0++WbBZpM17cPb8GdDAYntPqdjlQqhgj3Kgo52A2nhbylOFnQCZp t6RqhtzEc/o/G1VSteDvKerCJU3SELSn98dYxL5FjzhBV4MBnCoDpcnYhwCXuA+Dei2v1a ZArKiHFcvCaDyprzUgl03IsWd4PfCuSQLbkEi3/zlm8oTDQv7iMUJbUeXCAaI8kG1gz80t lLeQICQ68eLEBHY/WnpKF52etHbLneXk6EZ7mVIsuY2a/FAklzoJ4+eD0GPxqA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1684481949; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=WNaSK62FL/VbKyzgPcGpXScfG7m3EzvaNnXyeno7CgM=; b=MIdwWDqYWfOL9vdiKARZkPPhd2Zj9VJKxiJ3TldDD2m6Ge0ZTkLpd9Kckivv3zg9AbvJHb 32pmdNAAwIO8ylzSHbvz5UPbYJhszgn7+zX1NccuJtVCpmOMqD4GUzFOnyaGsP91H8oRSK nKhLwiDxyX1LkM4Tv4AEUiW8bybg36yaEdXyi/ZF/0NkFwJOeqY3p4YTWpOVYwmuk44PfM horV6YLnOmkfPdTx7UovR0llnJSEJ7K83yolR6/pAwA92UeVTVx3wyjOfknK9lOc38y0Hu 24Vj0P50WOcoT7yAj16A4QiBhhgq9zJuU3n1AON2R2LOXLp68e61f7PKG1AEDg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1684481949; a=rsa-sha256; cv=none; b=Ee9xlhr0kN9GxjFdB6R4DDJFXD0B4tvoJEgmSt5P7HnF31xD0NnUDZkax1ltr8ui33BFvP Os/p5elx8DDwsPlzVEtL1t0mgQGPDm3g3wByFUYsXaM24gJ9E2whq7lqJwBpQpbW+fcq2Y 6Oru/J3mN2TorccZh7npI7M+jjSNAYJ+efQJ3U/o8tPpNWLuoqOOZFouYLAIEB2i1jaaPY 5LnXhhpNZEE1iXR+zKH3sYWxekDwNJ6HyLs1wbrtilVXQFeYDptd7VS7Z7TkzPaJilVa+J jLYVTfSV/Ol+PZWFroRirEz2MRo778Gv4gtNVoLlQQYKD+App43IR/nSoh57Rw== Received: from mail-pl1-f181.google.com (mail-pl1-f181.google.com [209.85.214.181]) (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)) (Authenticated sender: eduardo) by smtp.freebsd.org (Postfix) with ESMTPSA id 4QMzHd2l3JzlWF for ; Fri, 19 May 2023 07:39:09 +0000 (UTC) (envelope-from eduardo@freebsd.org) Received: by mail-pl1-f181.google.com with SMTP id d9443c01a7336-1ae4baa77b2so21820615ad.2 for ; Fri, 19 May 2023 00:39:09 -0700 (PDT) X-Gm-Message-State: AC+VfDxQmInaSVTYS6a9ntDqxmSIF5Y5vD6CyEFuyOKx5lrG+BrVmusw oRZaFzWrUomswlHVoebofLnYuvqHhSYX1f/8UYU= X-Google-Smtp-Source: ACHHUZ7ijGvTYB0xoLZm7PTnXPHgCqfRyPrEG4LAG0IqweWqdYn1ZdioDx3WL2BzY9n0LgTadmKlqXYQnHVb14MpAPU= X-Received: by 2002:a17:903:230c:b0:1ac:a61c:7a12 with SMTP id d12-20020a170903230c00b001aca61c7a12mr2051480plh.57.1684481948355; Fri, 19 May 2023 00:39:08 -0700 (PDT) List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 References: <77CD0716-3BC8-47EB-8743-F2BD9CA43D31@yahoo.com> <432A1A16-9FE5-4339-AB38-8F3E03A5D4EF@yahoo.com> In-Reply-To: From: Nuno Teixeira Date: Fri, 19 May 2023 08:38:56 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Raspberry Pi POE+ hat overlay To: Mark Millard Cc: Doug Rabson , freebsd-arm@freebsd.org Content-Type: multipart/alternative; boundary="00000000000029915105fc070489" X-ThisMailContainsUnwantedMimeParts: N --00000000000029915105fc070489 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable (...) Using: [pi4] over_voltage=3D6 arm_freq=3D2000 sdram_freq_min=3D3200 force_turbo=3D1 Start to like force_turbo on :) Cheers! Nuno Teixeira escreveu no dia sexta, 19/05/2023 =C3= =A0(s) 08:37: > Thanks for great explanation about overclocking and firmware. > I was lost between firmware versions used in raspberry linux and freebsd > port. > > Now I have a better picture of why this setup make sense for a specific > firmware. > > I will stick with freq 2000 as my first goal was to set to 1800. > > And for now on, I will be watching firmware port version updates to check > changes carefully. > > Yours, > > Mark Millard escreveu no dia quinta, 18/05/2023 =C3= =A0(s) > 18:07: > >> On May 18, 2023, at 05:48, Nuno Teixeira wrote: >> >> > Indeed, voltage was the missing bit! >> > >> > I'm trying to setup 1800 as default now for revs >=3D 1.4 following >> https://www.raspberrypi.com/news/bullseye-bonus-1-8ghz-raspberry-pi-4/ >> that only talk about setting arm_freq=3D1800 but doesn't mention to adju= st >> voltage. >> > It was nice that raspberry tell us what voltage exacly value they use >> for new default 1800. >> > >> > What I've got now is: >> > >> > [pi4] >> > over_voltage=3D6 >> > arm_freq=3D2000 >> > sdram_freq_min=3D3200 >> > ### force_turbo=3D1 >> > >> > My tests shows that we don't need force_turbo=3D1 for a normal running >> and system do an auto 600 -> 2000 change when needed. Thats nice. >> >> I will note that the RPi* firmware itself varies the >> frequency and voltages by default --but the way of >> disabling that also disables powerd from being >> effective as I understand. (As I understand the >> firmware's policy details have changed over time >> but I do not know the details or when.) >> >> This makes use of powerd on the RPi*, with the firmware's >> adjustments also enabled, involve 2 competing mechanisms, >> if I understand right. I'm not aware of any horrible >> consequences in actual ooperation but I found force_turbo >> to lead to less time being taken in build activities back >> when I last measured it. >> >> It is true that I've not looked into this area in a long >> time. >> >> > Also, arm_boost=3D1 with force_turbo or not, is ignored. >> >> >> https://github.com/raspberrypi/documentation/blob/8b096a52e394c10360549a= fd0a620755df467446/documentation/asciidoc/computers/config_txt/overclocking= .adoc >> >> (from 2021-Nov-04) did not have arm_boost documented yet. >> >> >> https://github.com/raspberrypi/documentation/blob/da45bd8c982e91e11c6099= 91ba2fc8783872ef67/documentation/asciidoc/computers/config_txt/overclocking= .adoc >> >> (from 2021-Nov-11) has arm_boost documented. >> >> These give a clue about the vintage of RPi* firmware needed >> to have the arm_boost notation implemented. >> >> > sdram_freq and sdram_freq_min are set to 3200 by default, so I think I >> will not need sdram_freq_min=3D3200 here. >> >> >> https://github.com/raspberrypi/documentation/blob/2cbcd18fc155044f20ae63= 05fa0e62629b56893c/configuration/config-txt/overclocking.md >> >> (from 2021-Mar-31) shows the Pi4 sdram_freq_min as 400. >> The defaults have changed with firmware updates. >> >> Note that the official RPi* port has 2021-Mar-03 firmware, >> so before 2021-Mar-31. >> >> >> https://github.com/raspberrypi/documentation/blob/75e6050edd9e1b0c47c586= 23133dc05a02c16351/documentation/asciidoc/computers/config_txt/overclocking= .adoc >> >> (from 2021-Aug-09) shows the Pi4/CM4 sdram_freq_min as 3200. >> >> These give a clue about the vintage of RPi* firmware needed >> to have the sdram_freq_min be 3200 by default. >> >> My settings are for a wide range of firmware vintages, not >> just modern ones. Each item was shown (at the time added) >> was shown to cut the times for the likes of buildworld, >> buildkernel, or poudriere bulk activities that I did. >> >> Also, I tend to leave in place what has worked and still >> does work, rather than to track the changes in defaults >> over time in even more detail. I'd likely have different >> settings listed if I'd started at a later point that had >> newer defaults. >> >> > The only thing that I can't understand is how to calculate voltage: >> > >> > over_voltage: 0 (1.35V, 1.2V on Raspberry Pi 1) ??? >> > ( https://www.raspberrypi.com/documentation/computers/config_txt.html = ) >> > >> > Also, "7. Take it to the max" ( >> https://magpi.raspberrypi.com/articles/how-to-overclock-raspberry-pi-4 )= : >> > >> > over_voltage=3D6 (?) >> > arm_freq=3D2147 >> > gpu_freq=3D750 >> >> I'll note that I never attempted to take each RPi4B to >> its maximum for normal operation. I targeted having a >> setting combination that was reliable (had some margin) >> on all the example RPi4B's. >> >> I did have to explore were failures occured to do that. >> I did have access to RPi4B's that were unreliable with >> arm_freq=3D2100 for any over_voltage that I tried. Backing >> off to 2000 gave me reliable results on all the RPi4B's. >> >> I never had trouble with sdram_freq_min=3D3200 but it did >> help in contexts with the default being 400. >> >> > Thanks, >> > >> > >> > Mark Millard escreveu no dia quinta, 18/05/2023 >> =C3=A0(s) 11:57: >> > On May 18, 2023, at 01:29, Nuno Teixeira wrote: >> > >> > > Confirmed that arm_boost is enable by default on rpi4 rev >=3D 1.4 a= s I >> checked with htop. >> > > >> > > Also, tested arm_freq=3D1800 and it crashes FreeBSD around initializ= ing >> console/video and detecting mouse. >> > >> > Overclocking by setting the arm_freq directly involves also >> > managing over_voltage explicitly, such as: >> > >> > over_voltage=3D6 >> > >> > A sequence I use (and have used for a long time) is: >> > >> > [pi4] >> > over_voltage=3D6 >> > arm_freq=3D2000 >> > sdram_freq_min=3D3200 >> > force_turbo=3D1 >> > >> > But each RPi4B has heatsinks, a case with a fan, >> > and a power supply rated for 5.1V 3.5A (so: has >> > some extra margin). >> > >> > But the range of RPi4B's span Rev 1.1, Rev 1.4, >> > and Rev 1.5, a mix of 4 GiByte RAM and 8 GiByte >> > RAM models. All use those settings. >> > >> > As I understand, arm_boost implicitly does the >> > extra things required for its implicit frequency, >> > unlike assigning arm_freq or the like. >> > >> > If force_turbo is not used, it can be that: >> > >> > # >> > # Local addition that avoids USB3 SSD boot failures that look like: >> > # uhub_reattach_port: port ? reset failed, error=3DUSB_ERR_TIMEOUT >> > # uhub_reattach_port: device problem (USB_ERR_TIMEOUT), disabling >> port ? >> > initial_turbo=3D60 >> > >> > is required for USB based booting. But this also >> > gets into if the notation is supported or not for >> > the firmware vintage used. >> > >> > The initial_turbo use happens to avoid frequency >> > variability during boot and it appears that FreeBSD >> > does not necessarily tolerate such variability in >> > that time frame. >> > >> > Also: I happen to have USB3 boot media for which use >> > of usb_pgood_delay=3D2000 is sufficient but without >> > some such in/for U-Boot, U-Boot has problems >> > recognizing the device (before FreeBSD is even >> > involved). I build the U-Boot port with the >> > assignment built in. >> > >> > > As linux config.txt says: >> > > --- >> > > [pi4] >> > > # Run as fast as firmware / board allows >> > > arm_boost=3D1 >> > > --- >> > > firmware must be updated to support this feature for sure. >> > >> > I'm not aware of a dated list of when the various >> > config.txt notations were first supported (firmware >> > version). This makes it messier to use the web's >> > published information, if one is using the firmware >> > vintage that FreeBSD has in its port for the >> > firmware. >> > >> > The notation that I use has been around for a long >> > time. >> > >> > > Cheers, >> > > >> > > Nuno Teixeira escreveu no dia quarta, >> 17/05/2023 =C3=A0(s) 14:08: >> > > (...) >> > > >> > > I was meant using 13.2 not 12.3 :) >> > > >> > > Doug Rabson escreveu no dia quarta, 17/05/2023 =C3= =A0(s) >> 13:47: >> > > I'm not sure about 12.3 either - you could try with 13.2 and see if >> that makes a difference. >> > > >> > > On Wed, 17 May 2023 at 13:45, Nuno Teixeira >> wrote: >> > > Hey, >> > > >> > > Ok. I'm new to rpi4 and arm in general but tomorrow I will force >> 'arm_freq=3D1800' again just to see it it crashes again. >> > > I will check too what values linux shows. >> > > >> > > I don't know if firmware/uboot version included in 12.3 supports thi= s >> feature. >> > > >> > > Cheers, >> > > >> > > Doug Rabson escreveu no dia quarta, 17/05/2023 =C3= =A0(s) >> 13:11: >> > > Hi Nuno, >> > > >> > > I'm not sure where to start - I just happened to notice in the >> documentation here: >> https://www.raspberrypi.com/documentation/computers/config_txt.html that >> the cpu frequency Pi4B R1.4 was listed as 1800 if arm_boot=3D1 so I trie= d it. >> > > >> > > Doug. >> > > >> > > >> > > >> > > On Wed, 17 May 2023 at 11:11, Nuno Teixeira >> wrote: >> > > Hello Doug, >> > > >> > > I have too a 1.5 rpi but arm_boost=3D1 isn't doing anything, htop sh= ows >> 1500Mhz when doing something intensive. >> > > I'm running 13.2 stable >> > > >> > > Do I missing something? >> > > >> > > Could you take a look at my setup? >> > > >> > > Thanks, >> > > >> > > Doug Rabson escreveu no dia ter=C3=A7a, 16/05/2023 = =C3=A0(s) >> 17:19: >> > > >> > > On Sat, 13 May 2023 at 13:45, Doug Rabson wrote: >> > > I was able to build an updated rpi-firmware port based on 1.20210805 >> and this boots successfully on pi400 as well as rpi4. With this, I can l= oad >> the rpi-poe-plus overlay and I just need to try and reverse engineer the >> undocumented mailbox API by reading the Linux code. >> > > >> > > I have a first approximation of a fan driver which works with the >> 1.20210805 firmware (actually, I substituted rpi-poe-plus.dtbo from >> 1.20210831 which just changes the fan levels for the POE+). I'm testing >> with an rpi4B rev 1.5 with 'make -j4 buildworld' and the fan is keeping = the >> cpu temperature below 65 degrees which is nice, especially since I set >> arm_boost=3D1 in config.txt which boosts the cpu frequency up to 1800 fo= r >> this board. >> > > >> > > Does anyone have a pointer to the problem with firmware later than >> 20210805? Would it make any kind of sense to try to get the fix into >> releng/13.2 as an errata? >> > > >> >> >> >> =3D=3D=3D >> Mark Millard >> marklmi at yahoo.com >> >> > > -- > Nuno Teixeira > FreeBSD Committer (ports) > --=20 Nuno Teixeira FreeBSD Committer (ports) --00000000000029915105fc070489 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
(...)

Using:

<= /div>
[pi4]
over_voltage=3D6
arm_freq=3D2000
sdram_freq_min=3D3200
force_turbo=3D1

=
Start to like force_turbo on :)
<= div>
Cheers!

Nuno Teixeira <eduardo@freebsd.org> escreveu no dia sexta, 19/05/2023 =C3=A0= (s) 08:37:
Thanks for great explanation about overclocking and firmwa= re.
I was lost between firmware versions used in raspberry linux = and freebsd port.

Now I have a better picture of w= hy this setup make sense for a specific firmware.

= I will stick with freq 2000 as my first goal was to set to 1800.
<= div>
And for now on, I will be watching firmware port version= updates to check changes carefully.=C2=A0

Yours,<= br>

Mark Millard <marklmi@yahoo.com> escreveu no dia quinta, 18/05/2023 =C3=A0(s= ) 18:07:
On May = 18, 2023, at 05:48, Nuno Teixeira <eduardo@freebsd.org> wrote:

> Indeed, voltage was the missing bit!
>
> I'm trying to setup 1800 as default now for revs >=3D 1.4 follo= wing https://www.raspberrypi.c= om/news/bullseye-bonus-1-8ghz-raspberry-pi-4/ that only talk about sett= ing arm_freq=3D1800 but doesn't mention to adjust voltage.
> It was nice that raspberry tell us what voltage exacly value they use = for new default 1800.
>
> What I've got now is:
>
> [pi4]
> over_voltage=3D6
> arm_freq=3D2000
> sdram_freq_min=3D3200
> ### force_turbo=3D1
>
> My tests shows that we don't need force_turbo=3D1 for a normal run= ning and system do an auto 600 -> 2000 change when needed. Thats nice.
I will note that the RPi* firmware itself varies the
frequency and voltages by default --but the way of
disabling that also disables powerd from being
effective as I understand. (As I understand the
firmware's policy details have changed over time
but I do not know the details or when.)

This makes use of powerd on the RPi*, with the firmware's
adjustments also enabled, involve 2 competing mechanisms,
if I understand right. I'm not aware of any horrible
consequences in actual ooperation but I found force_turbo
to lead to less time being taken in build activities back
when I last measured it.

It is true that I've not looked into this area in a long
time.

> Also, arm_boost=3D1 with force_turbo or not, is ignored.

https://github.com/rasp= berrypi/documentation/blob/8b096a52e394c10360549afd0a620755df467446/documen= tation/asciidoc/computers/config_txt/overclocking.adoc

(from 2021-Nov-04) did not have arm_boost documented yet.

https://github.com/rasp= berrypi/documentation/blob/da45bd8c982e91e11c609991ba2fc8783872ef67/documen= tation/asciidoc/computers/config_txt/overclocking.adoc

(from 2021-Nov-11) has arm_boost documented.

These give a clue about the vintage of RPi* firmware needed
to have the arm_boost notation implemented.

> sdram_freq and sdram_freq_min are set to 3200 by default, so I think I= will not need sdram_freq_min=3D3200 here.

https://github.com/raspberrypi/documentation= /blob/2cbcd18fc155044f20ae6305fa0e62629b56893c/configuration/config-txt/ove= rclocking.md

(from 2021-Mar-31) shows the Pi4 sdram_freq_min as 400.
The defaults have changed with firmware updates.

Note that the official RPi* port has 2021-Mar-03 firmware,
so before 2021-Mar-31.

https://github.com/rasp= berrypi/documentation/blob/75e6050edd9e1b0c47c58623133dc05a02c16351/documen= tation/asciidoc/computers/config_txt/overclocking.adoc

(from 2021-Aug-09) shows the Pi4/CM4 sdram_freq_min as 3200.

These give a clue about the vintage of RPi* firmware needed
to have the sdram_freq_min be 3200 by default.

My settings are for a wide range of firmware vintages, not
just modern ones. Each item was shown (at the time added)
was shown to cut the times for the likes of buildworld,
buildkernel, or poudriere bulk activities that I did.

Also, I tend to leave in place what has worked and still
does work, rather than to track the changes in defaults
over time in even more detail. I'd likely have different
settings listed if I'd started at a later point that had
newer defaults.

> The only thing that I can't understand is how to calculate voltage= :
>
> over_voltage: 0 (1.35V, 1.2V on Raspberry Pi 1) ???
> ( https://www.raspberrypi.co= m/documentation/computers/config_txt.html )
>
> Also, "7. Take it to the max" ( https://magpi.raspberrypi.com/articles/how-to-overclock-ra= spberry-pi-4 ):
>
> over_voltage=3D6 (?)
> arm_freq=3D2147
> gpu_freq=3D750

I'll note that I never attempted to take each RPi4B to
its maximum for normal operation. I targeted having a
setting combination that was reliable (had some margin)
on all the example RPi4B's.

I did have to explore were failures occured to do that.
I did have access to RPi4B's that were unreliable with
arm_freq=3D2100 for any over_voltage that I tried. Backing
off to 2000 gave me reliable results on all the RPi4B's.

I never had trouble with sdram_freq_min=3D3200 but it did
help in contexts with the default being 400.

> Thanks,
>
>
> Mark Millard <marklmi@yahoo.com> escreveu no dia quinta, 18/05/2023 =C3=A0(s) 11= :57:
> On May 18, 2023, at 01:29, Nuno Teixeira <eduardo@freebsd.org> wrote:
>
> > Confirmed that arm_boost is enable by default on rpi4 rev >=3D= 1.4 as I checked with htop.
> >
> > Also, tested arm_freq=3D1800 and it crashes FreeBSD around initia= lizing console/video and detecting mouse.
>
> Overclocking by setting the arm_freq directly involves also
> managing over_voltage explicitly, such as:
>
> over_voltage=3D6
>
> A sequence I use (and have used for a long time) is:
>
> [pi4]
> over_voltage=3D6
> arm_freq=3D2000
> sdram_freq_min=3D3200
> force_turbo=3D1
>
> But each RPi4B has heatsinks, a case with a fan,
> and a power supply rated for 5.1V 3.5A (so: has
> some extra margin).
>
> But the range of RPi4B's span Rev 1.1, Rev 1.4,
> and Rev 1.5, a mix of 4 GiByte RAM and 8 GiByte
> RAM models. All use those settings.
>
> As I understand, arm_boost implicitly does the
> extra things required for its implicit frequency,
> unlike assigning arm_freq or the like.
>
> If force_turbo is not used, it can be that:
>
> #
> # Local addition that avoids USB3 SSD boot failures that look like: > #=C2=A0 =C2=A0uhub_reattach_port: port ? reset failed, error=3DUSB_ERR= _TIMEOUT
> #=C2=A0 =C2=A0uhub_reattach_port: device problem (USB_ERR_TIMEOUT), di= sabling port ?
> initial_turbo=3D60
>
> is required for USB based booting. But this also
> gets into if the notation is supported or not for
> the firmware vintage used.
>
> The initial_turbo use happens to avoid frequency
> variability during boot and it appears that FreeBSD
> does not necessarily tolerate such variability in
> that time frame.
>
> Also: I happen to have USB3 boot media for which use
> of usb_pgood_delay=3D2000 is sufficient but without
> some such in/for U-Boot, U-Boot has problems
> recognizing the device (before FreeBSD is even
> involved). I build the U-Boot port with the
> assignment built in.
>
> > As linux config.txt says:
> > ---
> > [pi4]
> > # Run as fast as firmware / board allows
> > arm_boost=3D1
> > ---
> > firmware must be updated to support this feature for sure.
>
> I'm not aware of a dated list of when the various
> config.txt notations were first supported (firmware
> version). This makes it messier to use the web's
> published information, if one is using the firmware
> vintage that FreeBSD has in its port for the
> firmware.
>
> The notation that I use has been around for a long
> time.
>
> > Cheers,
> >
> > Nuno Teixeira <eduardo@freebsd.org> escreveu no dia quarta, 17/05/2023 = =C3=A0(s) 14:08:
> > (...)
> >
> > I was meant using 13.2 not 12.3 :)
> >
> > Doug Rabson <dfr@rabson.org> escreveu no dia quarta, 17/05/2023 =C3=A0(s) 13:4= 7:
> > I'm not sure about 12.3 either - you could try with 13.2 and = see if that makes a difference.
> >
> > On Wed, 17 May 2023 at 13:45, Nuno Teixeira <eduardo@freebsd.org> wrote:<= br> > > Hey,
> >
> > Ok. I'm new to rpi4 and arm in general but tomorrow I will fo= rce 'arm_freq=3D1800' again just to see it it crashes again.
> > I will check too what values linux shows.
> >
> > I don't know if firmware/uboot version included in 12.3 suppo= rts this feature.
> >
> > Cheers,
> >
> > Doug Rabson <dfr@rabson.org> escreveu no dia quarta, 17/05/2023 =C3=A0(s) 13:1= 1:
> > Hi Nuno,
> >
> > I'm not sure where to start - I just happened to notice in th= e documentation here: https://www= .raspberrypi.com/documentation/computers/config_txt.html that the cpu f= requency Pi4B R1.4 was listed as 1800 if arm_boot=3D1 so I tried it.
> >
> > Doug.
> >
> >
> >
> > On Wed, 17 May 2023 at 11:11, Nuno Teixeira <eduardo@freebsd.org> wrote:<= br> > > Hello Doug,
> >
> > I have too a 1.5 rpi but arm_boost=3D1 isn't doing anything, = htop shows 1500Mhz when doing something intensive.
> > I'm running 13.2 stable
> >
> > Do I missing something?
> >
> > Could you take a look at my setup?
> >
> > Thanks,
> >
> > Doug Rabson <dfr@rabson.org> escreveu no dia ter=C3=A7a, 16/05/2023 =C3=A0(s) = 17:19:
> >
> > On Sat, 13 May 2023 at 13:45, Doug Rabson <dfr@rabson.org> wrote:
> > I was able to build an updated rpi-firmware port based on 1.20210= 805 and this boots successfully on pi400 as well as rpi4. With this, I can = load the rpi-poe-plus overlay and I just need to try and reverse engineer t= he undocumented mailbox API by reading the Linux code.
> >
> > I have a first approximation of a fan driver which works with the= 1.20210805 firmware (actually, I substituted rpi-poe-plus.dtbo from 1.2021= 0831 which just changes the fan levels for the POE+). I'm testing with = an rpi4B rev 1.5 with 'make -j4 buildworld' and the fan is keeping = the cpu temperature below 65 degrees which is nice, especially since I set = arm_boost=3D1 in config.txt which boosts the cpu frequency up to 1800 for t= his board.
> >
> > Does anyone have a pointer to the problem with firmware later tha= n 20210805? Would it make any kind of sense to try to get the fix into rele= ng/13.2 as an errata?
> >



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



--
Nuno TeixeiraFreeBSD Committer (ports)


--
Nuno Teixeira
FreeBSD Committ= er (ports)
--00000000000029915105fc070489-- From nobody Fri May 19 07:45:17 2023 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 4QMzQy4xbRz4BcYQ for ; Fri, 19 May 2023 07:45:30 +0000 (UTC) (envelope-from marietto2008@gmail.com) Received: from mail-yb1-xb2d.google.com (mail-yb1-xb2d.google.com [IPv6:2607:f8b0:4864:20::b2d]) (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 4QMzQy2lSxz46xT for ; Fri, 19 May 2023 07:45:30 +0000 (UTC) (envelope-from marietto2008@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-yb1-xb2d.google.com with SMTP id 3f1490d57ef6-ba818eb96dcso2595757276.0 for ; Fri, 19 May 2023 00:45:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1684482329; x=1687074329; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=CtjLvqjxXOQAoavWxDZi0rLcHfk15L5roUhC1IcvmqM=; b=rL0sV/fEDm/QqBflpFNiRQsCw8m4Vsw6jccmOGDdvmJlqzpjGKm2ygKeKDZfUoJpab 3Mx+Xl3GgVXTvVY2In0fAYCGAozArEs9WwYWcSeIgmThsTYJlTWockQ4k3bDy4annqq4 0/9j7ICXmCvyLqogHE71aiiMLcI0Pp1sYqfaT55VK5Fzz1Wum1qcwNNYxtsI0s9iewR1 7UN28kdRoFuiHYl83Ym1kGbOD9DNbP7sesJP5kEWSI0lO0oSAIiyaZj0EUA8mNQlald7 Gu+9RkMkCDxWsR7nzbm+V7iYckOlVdOW2Kd0mwsmdJNAqbfP8sAU+6QGlR5Cwl+nI+we Izmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684482329; x=1687074329; 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=CtjLvqjxXOQAoavWxDZi0rLcHfk15L5roUhC1IcvmqM=; b=Ze0UFy3Bqe8QBuxH63RwSg8Bkee1wj3JWJadJtu44SEcfjtNW33hcuTtUqwx6s86vn 1LevJAHW+gzw5EEr2YzrgjTrWXsefPbCZi1atSD0s6JXhMAv5A07X9kQpO24pHCVyarw 7Q2SKJ7/OS9ct1cBXS/UgQvE2dHl1bDvgwTK4EVLhvYoxOQiM+IN7/0MPU88lg6kCPxH P3Zpa/kIMPgXgb65MBtqrd5jIKAKnR9JWLBFUo0gGwEHFNCaAf54IWU83vtoK9Fm5AYJ z2K52S/T/JxcaaHcT/VNgOHNDwRQDw2JHdaKHPPc1WnjenxFfd2ASHsJU9rWnYun9ZSC IoeQ== X-Gm-Message-State: AC+VfDwycW0KFO1ozBsZPS/MiLmrn5h/3pcmm8iMrza7UjsxmdDMB+W0 OvlV/EX+HIsA7FLMiEw4MJkbOBYG/88Qb5l8V6GG3K4dnQU= X-Google-Smtp-Source: ACHHUZ7wmQrcLWNthm7hYQGHwLWgDCf+CzEYpl1TfYEE+dHCQNCabCZbalG2P153LkvnOXMlatEORheet9vuZc1bvEU= X-Received: by 2002:a05:6902:120c:b0:ba8:58f4:aaba with SMTP id s12-20020a056902120c00b00ba858f4aabamr1112199ybu.24.1684482329294; Fri, 19 May 2023 00:45:29 -0700 (PDT) List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 References: <202305190249.34J2n3hg029621@office.dignus.com> In-Reply-To: <202305190249.34J2n3hg029621@office.dignus.com> From: Mario Marietto Date: Fri, 19 May 2023 09:45:17 +0200 Message-ID: Subject: Re: some QEMU success in running armv7 To: Thomas David Rivers Cc: freebsd-arm@freebsd.org Content-Type: multipart/alternative; boundary="000000000000de3b2505fc071a08" X-Rspamd-Queue-Id: 4QMzQy2lSxz46xT X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --000000000000de3b2505fc071a08 Content-Type: text/plain; charset="UTF-8" Nice review. infortunately kvm does not work ? and a qemu vm without kvm is very slow and useless. Il ven 19 mag 2023, 04:49 Thomas David Rivers ha scritto: > > Just f.y.i. - here's the steps I was able to deduce today > to get FreeBSD armv7 running under qemu... just in case > someone goes looking for this... (I was doing this on a > FreeBSD 12.3-RELEASE x86_64 system.) > > > 1. Retrieve the armv7 image from: > fetch > https://download.freebsd.org/releases/arm/armv7/ISO-IMAGES/13.2/FreeBSD-13.2-RELEASE-arm-armv7-GENERICSD.img.xz > and unzip it. This is an actual hard-drive image of a working > system. > > 2. Assuming the qemu port has been installed - this command > starts that system > > qemu-system-arm -M virt -m 512m -nographic \ > -bios edk2-arm-code.fd \ > -hda FreeBSD-13.2-RELEASE-arm-armv7-GENERICSD.img > > the existing terminal will be the console. There is no > networking. > > There root user's password is 'root'. > > Unfortunately this doesn't provide networking in the guest. This > compilation of QEMU also doesn't support the "-netdev user" mode > of networking so I can't take advantage of that. (The FreeBSD 12.3 > host is using QEMU emulator version 7.2.0 - from just the pkg > install.) However, I found that using this option on qemu: > > -nic tap,ifname=tap7,script=no,downscript=no > > got it to use the tap interface on the host to emulate the virtio > device to the guest. > > I also found this discussion regarding alignment issues in the > virtio driver in armv7: > > > https://forums.freebsd.org/threads/kernel-panic-on-armv7-with-qemu.89016/#post-610281 > > that resulted in PR 271288. Apparently it's because of newer versions > of QEMU doing a better job at reporting unaligned memory accesses in the > guest for the armv7 "ldm" instruction. > > When I use the tap interface, I did get the exact panic mentioned > in the forum and the PR. > > I did find that specifying the rtl8139 device worked around the panic > with the QEMU option: > > -nic tap,ifname=tap7,script=no,downscript=no,model=rtl8139 > > by the way - tap7 happens to be a tap device I'd already configured > on the host FreeBSD 12.3 system - if you're doing this yourself, > it will likely need to be a different tap device, see this > write-up for info about how to configure a tap + bridge on your > FreeBSD host: > > http://bsdwiki.reedmedia.net/wiki/networking_qemu_virtual_bsd_systems.html > > So - it seems a newer version of the armv7 kernel with the patch > applied will fix the virtio driver problem, until then, model=rtl8139 > works around it and I have networking and everything! > > - Dave R. - > > -- > rivers@dignus.com Work: (919) 676-0847 > Get your mainframe programming tools at http://www.dignus.com > > --000000000000de3b2505fc071a08 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Nice review. infortunately kvm does not work ? and a qemu= vm without kvm is very slow and useless.

Il ven 19 mag 2023, 04:49 Thomas D= avid Rivers <rivers@dignus.com&= gt; ha scritto:

Just f.y.i. - here's the steps I was able to deduce today
to get FreeBSD armv7 running under qemu... just in case
someone goes looking for this... (I was doing this on a
FreeBSD 12.3-RELEASE x86_64 system.)


1.=C2=A0 =C2=A0Retrieve the armv7 image from:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 fetch https://download.fr= eebsd.org/releases/arm/armv7/ISO-IMAGES/13.2/FreeBSD-13.2-RELEASE-arm-armv7= -GENERICSD.img.xz
=C2=A0 =C2=A0 =C2=A0and unzip it.=C2=A0 =C2=A0This is an actual hard-drive = image of a working
=C2=A0 =C2=A0 =C2=A0system.

2.=C2=A0 Assuming the qemu port has been installed - this command
=C2=A0 =C2=A0 starts that system

=C2=A0 =C2=A0 qemu-system-arm -M virt -m 512m -nographic \
=C2=A0 =C2=A0 =C2=A0 =C2=A0-bios edk2-arm-code.fd \
=C2=A0 =C2=A0 =C2=A0 =C2=A0-hda FreeBSD-13.2-RELEASE-arm-armv7-GENERICSD.im= g

=C2=A0 =C2=A0 the existing terminal will be the console.=C2=A0 There is no<= br> =C2=A0 =C2=A0 networking.

=C2=A0 =C2=A0 There root user's password is 'root'.

Unfortunately this doesn't provide networking in the guest.=C2=A0 This<= br> compilation of QEMU also doesn't support the "-netdev user" m= ode
of networking so I can't take advantage of that.=C2=A0 (The FreeBSD 12.= 3
host is using QEMU emulator version 7.2.0 - from just the pkg
install.)=C2=A0 However, I found that using this option on qemu:

=C2=A0 =C2=A0 -nic tap,ifname=3Dtap7,script=3Dno,downscript=3Dno

got it to use the tap interface on the host to emulate the virtio
device to the guest.

I also found this discussion regarding alignment issues in the
virtio driver in armv7:

=C2=A0 https://forums.freebsd.org/threads/kernel-panic-on-armv7-with-qemu.89016= /#post-610281

that resulted in PR 271288.=C2=A0 =C2=A0Apparently it's because of newe= r versions
of QEMU doing a better job at reporting unaligned memory accesses in the guest for the armv7 "ldm" instruction.

When I use the tap interface, I did get the exact panic mentioned
in the forum and the PR.

I did find that specifying the rtl8139 device worked around the panic
with the QEMU option:

=C2=A0 -nic tap,ifname=3Dtap7,script=3Dno,downscript=3Dno,model=3Drtl8139
by the way - tap7 happens to be a tap device I'd already configured
on the host FreeBSD 12.3 system - if you're doing this yourself,
it will likely need to be a different tap device, see this
write-up for info about how to configure a tap + bridge on your
FreeBSD host:
=C2=A0 =C2=A0ht= tp://bsdwiki.reedmedia.net/wiki/networking_qemu_virtual_bsd_systems.html

So - it seems a newer version of the armv7 kernel with the patch
applied will fix the virtio driver problem, until then, model=3Drtl8139
works around it and I have networking and everything!

=C2=A0 =C2=A0 =C2=A0 =C2=A0 - Dave R. -

--
r= ivers@dignus.com=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 Work: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com
--000000000000de3b2505fc071a08-- From nobody Fri May 19 11:42:16 2023 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 4QN4hM1R4Zz4Bqrf for ; Fri, 19 May 2023 11:42:27 +0000 (UTC) (envelope-from samm@freebsd.org) Received: from reindeer.net-art.cz (reindeer.net-art.cz [IPv6:2001:15e8:110:513c::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "reindeer.net-art.cz", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QN4hL0w78z4YmD for ; Fri, 19 May 2023 11:42:26 +0000 (UTC) (envelope-from samm@freebsd.org) Authentication-Results: mx1.freebsd.org; dkim=none; spf=softfail (mx1.freebsd.org: 2001:15e8:110:513c::1 is neither permitted nor denied by domain of samm@freebsd.org) smtp.mailfrom=samm@freebsd.org; dmarc=none Received: by reindeer.net-art.cz (Postfix, from userid 65534) id CA1BD5F039; Fri, 19 May 2023 12:42:16 +0100 (BST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on reindeer X-Spam-Level: X-Spam-Status: No, score=-1.2 required=10.0 tests=BAYES_00, RCVD_IN_DNSWL_BLOCKED,SPF_HELO_NONE,SPF_SOFTFAIL,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.2 Received: from owl.net-art.cz (unknown [IPv6:2a03:6920:0:10::101]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "owl.net-art.cz", Issuer "R3" (not verified)) by reindeer.net-art.cz (Postfix) with ESMTPS id 64A2B5EEB7; Fri, 19 May 2023 12:42:16 +0100 (BST) Received: from [::1] (account samm@net-art.cz HELO webmail.net-art.cz) by owl.net-art.cz (CommuniGate Pro SMTP 6.1.20) with ESMTPA id 1809924; Fri, 19 May 2023 13:42:16 +0200 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Date: Fri, 19 May 2023 13:42:16 +0200 From: Alex Samorukov To: Jason Bacon Cc: "Rodney W. Grimes" , freebsd-arm@freebsd.org Subject: Re: VirtualBox In-Reply-To: <5d6eb34c-a624-0d75-06d5-550d0567a2ae@gmail.com> References: <202305181358.34IDwX6o088856@gndrsh.dnsmgr.net> <5d6eb34c-a624-0d75-06d5-550d0567a2ae@gmail.com> Message-ID: X-Sender: samm@freebsd.org Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Result: default: False [-3.03 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.998]; NEURAL_HAM_LONG(-0.93)[-0.935]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; ARC_NA(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; R_DKIM_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:24806, ipnet:2001:15e8::/32, country:CZ]; MIME_TRACE(0.00)[0:+]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all:c]; RCVD_TLS_LAST(0.00)[]; FREEFALL_USER(0.00)[samm]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; DMARC_NA(0.00)[freebsd.org]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Queue-Id: 4QN4hL0w78z4YmD X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N >> > > For lack of available info, I naively tried booting the aarch64 disc1 > ISO, which not surprisingly didn't work. Not even sure if this is the > right approach, but it seems like the intuitive one the the average > VirtualBox user. I think it would be ideal if the experience were the > same as for x86. Just try UTM :) Again, VirtualBox is a road to nowhere - it emulates x86 on aarch. Of course, performance will be terrible, as well as emulation quality. KVM just works, and if you need UI - UTM works pretty well for me, at least. And you will get near-native speed, as it is arm64 guest on arm64 host which uses native macOS virtualisation framework. From nobody Fri May 19 13:10:15 2023 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 4QN6dw6llSz4Bwp3 for ; Fri, 19 May 2023 13:10:28 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [IPv6:2a00:1450:4864:20::630]) (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 4QN6dw4m31z3Kvp for ; Fri, 19 May 2023 13:10:28 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ej1-x630.google.com with SMTP id a640c23a62f3a-965ddb2093bso521108966b.2 for ; Fri, 19 May 2023 06:10:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20221208.gappssmtp.com; s=20221208; t=1684501827; x=1687093827; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=qvdG2ZloS7De4xUpa+CKt8GjX888atMJdRQot3DIL28=; b=cevaAAIgC1GGpfdgIxsmQ7GynFy1Iwi6HXpzB3axr/G+FHjiUxC6j/7UfwG3sWXaJe 1ZRVXgX2goV1WiPqcX0MZph5DrzCvFppJjtI+HDFow3jVZ/5BC+btEvsm2cNfirZ/ZKM Soc3WJtDTonLiSjWJ1CfHKPXWm5ZTPTJQyhAGZTSLVm6fkbbrNcuHIfrq++Ld5MwROHA l9dmEnXtwwX94jVYMmWbMt9Q3dpH2isPVL318LBrCPQf3AjjkP7aIL48a7CM6KjtgGKw Dh8M+poIZet6Acc84l52IZIHdvBBwZq+b9A0gkomewAZX1XLUenCPt9dhbe7IDGVeXNG 1GPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684501827; x=1687093827; 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=qvdG2ZloS7De4xUpa+CKt8GjX888atMJdRQot3DIL28=; b=FmU/dokaFwwHoHa7wQRkav+PDzqYDbxK7qHkg7RjAtVxgdF1ajFst253REyhbUvx01 WysHIXH/pEOibrDn6WG+56YzLRsnP7cjGMzVdYem+WdIaMqOLzRoaTCaSCQviMg+Cb5z eaqZ55PojPo4uaB6FvFC1OEJ6pnCmXnFzMfVQ3W/xmdRDJ2RwhHnt329HX4BF68u4ZpM DLEHvA+C2TBTfYzgHnDhw/mL8RmdYYgV+evRpiNjylgKu1wWMhSQFDpx0r99hVk/P7ZG A9CfN6xTV9LSGIWbXDAPRLhiVgtzaWVxuESUPhj/RPXBTQTu7c1Qa09ifahTU/yD51Zp PYiA== X-Gm-Message-State: AC+VfDyFdoc4Nu1Cr8PRRBf//nzCRtJtdHG8nc2ppKjJe3SkqS9Y0F32 fWVyzpd9DndWdP5T5UJD3ApusF5R8OXkSQcoKh/thiimTiOEW/PoJ2Y= X-Google-Smtp-Source: ACHHUZ7QVnplneUzpVBnRqN4XIzCRSHt+sk/7gbjsXispH3ZgVnvNyy7qKUAyIXhUTj8jEKAlOUSJxAesWzKwkH+dxw= X-Received: by 2002:a17:907:a01:b0:966:265d:edc7 with SMTP id bb1-20020a1709070a0100b00966265dedc7mr1468967ejc.69.1684501827062; Fri, 19 May 2023 06:10:27 -0700 (PDT) List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 References: <202305190249.34J2n3hg029621@office.dignus.com> In-Reply-To: From: Warner Losh Date: Fri, 19 May 2023 07:10:15 -0600 Message-ID: Subject: Re: some QEMU success in running armv7 To: Mario Marietto Cc: Thomas David Rivers , freebsd-arm@freebsd.org Content-Type: multipart/alternative; boundary="000000000000069e3005fc0ba550" X-Rspamd-Queue-Id: 4QN6dw4m31z3Kvp X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --000000000000069e3005fc0ba550 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable You'd never use kvm for armv7 when running on amd64 anyway... You can't run the code directly, but have to use the emulation stream. Warner On Fri, May 19, 2023 at 1:45=E2=80=AFAM Mario Marietto wrote: > Nice review. infortunately kvm does not work ? and a qemu vm without kvm > is very slow and useless. > > Il ven 19 mag 2023, 04:49 Thomas David Rivers ha > scritto: > >> >> Just f.y.i. - here's the steps I was able to deduce today >> to get FreeBSD armv7 running under qemu... just in case >> someone goes looking for this... (I was doing this on a >> FreeBSD 12.3-RELEASE x86_64 system.) >> >> >> 1. Retrieve the armv7 image from: >> fetch >> https://download.freebsd.org/releases/arm/armv7/ISO-IMAGES/13.2/FreeBSD-= 13.2-RELEASE-arm-armv7-GENERICSD.img.xz >> and unzip it. This is an actual hard-drive image of a working >> system. >> >> 2. Assuming the qemu port has been installed - this command >> starts that system >> >> qemu-system-arm -M virt -m 512m -nographic \ >> -bios edk2-arm-code.fd \ >> -hda FreeBSD-13.2-RELEASE-arm-armv7-GENERICSD.img >> >> the existing terminal will be the console. There is no >> networking. >> >> There root user's password is 'root'. >> >> Unfortunately this doesn't provide networking in the guest. This >> compilation of QEMU also doesn't support the "-netdev user" mode >> of networking so I can't take advantage of that. (The FreeBSD 12.3 >> host is using QEMU emulator version 7.2.0 - from just the pkg >> install.) However, I found that using this option on qemu: >> >> -nic tap,ifname=3Dtap7,script=3Dno,downscript=3Dno >> >> got it to use the tap interface on the host to emulate the virtio >> device to the guest. >> >> I also found this discussion regarding alignment issues in the >> virtio driver in armv7: >> >> >> https://forums.freebsd.org/threads/kernel-panic-on-armv7-with-qemu.89016= /#post-610281 >> >> that resulted in PR 271288. Apparently it's because of newer versions >> of QEMU doing a better job at reporting unaligned memory accesses in the >> guest for the armv7 "ldm" instruction. >> >> When I use the tap interface, I did get the exact panic mentioned >> in the forum and the PR. >> >> I did find that specifying the rtl8139 device worked around the panic >> with the QEMU option: >> >> -nic tap,ifname=3Dtap7,script=3Dno,downscript=3Dno,model=3Drtl8139 >> >> by the way - tap7 happens to be a tap device I'd already configured >> on the host FreeBSD 12.3 system - if you're doing this yourself, >> it will likely need to be a different tap device, see this >> write-up for info about how to configure a tap + bridge on your >> FreeBSD host: >> >> http://bsdwiki.reedmedia.net/wiki/networking_qemu_virtual_bsd_systems.ht= ml >> >> So - it seems a newer version of the armv7 kernel with the patch >> applied will fix the virtio driver problem, until then, model=3Drtl8139 >> works around it and I have networking and everything! >> >> - Dave R. - >> >> -- >> rivers@dignus.com Work: (919) 676-0847 >> Get your mainframe programming tools at http://www.dignus.com >> >> --000000000000069e3005fc0ba550 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
You'd never use kvm for armv7 when running on amd= 64 anyway... You can't run
the code directly, but have to use= the emulation stream.

Warner

On Fri, May 19, 2023= at 1:45=E2=80=AFAM Mario Marietto <marietto2008@gmail.com> wrote:
Nice review. infortunately kv= m does not work ? and a qemu vm without kvm is very slow and useless.
=
Il ven= 19 mag 2023, 04:49 Thomas David Rivers <rivers@dignus.com> ha scritto:

Just f.y.i. - here's the steps I was able to deduce today
to get FreeBSD armv7 running under qemu... just in case
someone goes looking for this... (I was doing this on a
FreeBSD 12.3-RELEASE x86_64 system.)


1.=C2=A0 =C2=A0Retrieve the armv7 image from:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 fetch https://download.fr= eebsd.org/releases/arm/armv7/ISO-IMAGES/13.2/FreeBSD-13.2-RELEASE-arm-armv7= -GENERICSD.img.xz
=C2=A0 =C2=A0 =C2=A0and unzip it.=C2=A0 =C2=A0This is an actual hard-drive = image of a working
=C2=A0 =C2=A0 =C2=A0system.

2.=C2=A0 Assuming the qemu port has been installed - this command
=C2=A0 =C2=A0 starts that system

=C2=A0 =C2=A0 qemu-system-arm -M virt -m 512m -nographic \
=C2=A0 =C2=A0 =C2=A0 =C2=A0-bios edk2-arm-code.fd \
=C2=A0 =C2=A0 =C2=A0 =C2=A0-hda FreeBSD-13.2-RELEASE-arm-armv7-GENERICSD.im= g

=C2=A0 =C2=A0 the existing terminal will be the console.=C2=A0 There is no<= br> =C2=A0 =C2=A0 networking.

=C2=A0 =C2=A0 There root user's password is 'root'.

Unfortunately this doesn't provide networking in the guest.=C2=A0 This<= br> compilation of QEMU also doesn't support the "-netdev user" m= ode
of networking so I can't take advantage of that.=C2=A0 (The FreeBSD 12.= 3
host is using QEMU emulator version 7.2.0 - from just the pkg
install.)=C2=A0 However, I found that using this option on qemu:

=C2=A0 =C2=A0 -nic tap,ifname=3Dtap7,script=3Dno,downscript=3Dno

got it to use the tap interface on the host to emulate the virtio
device to the guest.

I also found this discussion regarding alignment issues in the
virtio driver in armv7:

=C2=A0 https://forums.freebsd.org/threads/kernel-panic-on-armv7-with-qemu.89016= /#post-610281

that resulted in PR 271288.=C2=A0 =C2=A0Apparently it's because of newe= r versions
of QEMU doing a better job at reporting unaligned memory accesses in the guest for the armv7 "ldm" instruction.

When I use the tap interface, I did get the exact panic mentioned
in the forum and the PR.

I did find that specifying the rtl8139 device worked around the panic
with the QEMU option:

=C2=A0 -nic tap,ifname=3Dtap7,script=3Dno,downscript=3Dno,model=3Drtl8139
by the way - tap7 happens to be a tap device I'd already configured
on the host FreeBSD 12.3 system - if you're doing this yourself,
it will likely need to be a different tap device, see this
write-up for info about how to configure a tap + bridge on your
FreeBSD host:
=C2=A0 =C2=A0ht= tp://bsdwiki.reedmedia.net/wiki/networking_qemu_virtual_bsd_systems.html

So - it seems a newer version of the armv7 kernel with the patch
applied will fix the virtio driver problem, until then, model=3Drtl8139
works around it and I have networking and everything!

=C2=A0 =C2=A0 =C2=A0 =C2=A0 - Dave R. -

--
r= ivers@dignus.com=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 Work: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com
--000000000000069e3005fc0ba550-- From nobody Sat May 20 18:59:51 2023 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 4QNtM00stTz4BQDl for ; Sat, 20 May 2023 19:00:12 +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 4QNtLy3b5Xz3sWD for ; Sat, 20 May 2023 19:00:10 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=TQpnBD8N; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.31 as permitted sender) smtp.mailfrom=marklmi@yahoo.com; dmarc=pass (policy=reject) header.from=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1684609208; bh=GFYPLGSKwQRLhD6Ie70ub61dyM+OdnDSESugTWCCAK4=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=TQpnBD8NuyCYV4nrk4Le13bQ5w3g9febGrJGVnahDHw94ggv55aHEEJwdYAcXO4PhaZpnfCgrp8mKBvBE6IZDX8clVn+j5jrlJ5ROnJEIQilyutxjuuFmlEhvjAlqjhXZlkXpXqEFy0VazNaRbb3Soc1WHpvTFnXJyow/DGD1qWSEUGpv4GDrPg/T1RZTYCq3SZTGqRXxt3m7lOIdpaGLCRhvkgWGPpzOsvE8g0QDZ8WGG/3j+QZC9UOUDZLkLaLGdphatZkrgIFW63GGDchaulzWKiJXDR9rrRjnOp5Hy9V7RQnaOjmaV0E8kg5NVQ+3XmhGVz8NhHypcys8n3szA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1684609208; bh=E/Ug/QJH9CaYhMqnOBrZu/e3RtDxu75mWO6id0icz2S=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=d9+LTBuEBsB8uewXRHY3fCLTr8vWPa9yuVEosN9CUTf9GWEXuTxLJuzkHwsR52jyd9CXTemnv2CRpaJrj3FPgdsik/SlMAyezZJeWvepJEMQukNPVYPxTawxBcxWdim6nMV1YxbWsTjg+VFV0bzqcgQYlRsCuNo6f4IoJNegdGITNjVfzPbj/E7sUCBWzYaQ8W0YT01GL1GQ7E2QEyGSwiO1JyHOmBnt+wCsGluTNhjufblZTlsXlq0JVZ1eZFgA60dJ0bT2in1vow3ohTbkmFj9eBhVQp8keNI3POe3303OptkBX+eKLtVgJjefHw01QXzTaP+9BKbBAtXoLl/eDw== X-YMail-OSG: BfAkGN0VM1llp9x6fUHl2fdSpVIIqncra_odTFLhsnxoI1rihC1NIIwNtUAKGK4 E2.AO7sDS5IngX8NReRzeXr9wBDeCz0ivD8LurM0vMWC5rypz9SSHhZ_sFW0Gnvnj1QcjxHfdEZI 6OfcDDrQvoC_qmUq3V0YJ9Gr62l2oXHIA9MVdWI7skeAN65DrNAgb72ncQRdYiTFthJVrx5hd4x. UfDpOYSLsH3LkK1NCWCfH2d3McbzvBPi7sNnPa3mO4a1hm2PLmcW57yAdt.Bwmtum0_dQvqIuOir XunDbjHIpTyBSz8dpUUIRlICCE4e55p_Eq5I7A85G7XHxTRQznV03mkuWs7uzqOBBd8_kyIbE2hW KQWJDsIIJFWxXX5QR3ARuAgPtF_.XotohlvJj5ZfLcHrDJoggM64oCk2IYE3E.V3XOT6IiRXex20 fJn44bX3QU1S7wUNmB1FF4Li3UzEdAPUqizHtAu82n0CaUsXZlzIru_uuZcoyB85_hkXizp.5LEz 4BWj.GgXZlxhapyG9pn65mQivclbwA1zFNj53A57.1zHJeNfWwq.3UQdbh642V7bRShqYkHELU6f 1G3TUbhWaJMq4rutNFIA7ufjpMJH_nbh0lh3fLtsB22RJPTX5TYSV_v_iiZlqPhOsGJNOBNqDA0I 6hKFqyZul9uUa4HMa5v579awDjQUn21oMhVPZSpZOCwNvS5hTYjRsZ45Q4g7FaRTpWQIsmlm7K9B .oQ1d1Q0aR_LXLuIuhLixITZb0jBymk1E5BWqjEdY8yfjt8i6jMEAVrNmzlZ1BMcVGczTd18dayn wRysXj1rq1_Hzrb3KtiHHxekbP0dWnd3vbUHe7xVyKfXhsWDrtGNlF4JYS0O5y5OtoiBgAwPHNYI 5D5YZ5jdqALq_DNE8u_U9GUAft6t56sV.JieKwGZScIQpwZ8jCiri.BJv24I8HJZ1rqRP53ignGw apyEQfKmkR539xaqMYyo7Jx5GLrtG3un2M4k5lNwx7Ip1BxLdXbo.cYvzc7DWhT3yT2WxHpuBlAc 76Nq5x7ja3x_kcZrbgnjBXjjZ7aUNCi.BFKkbejt4mWhDSjvwNt6gGO9WnH7QBWhqgUpa6xThh6C TRgCN.zLRriRUvAkLW5KcEkPWnTxxs54tCMeWefNab0YH2bffaZIAHHldM1bgJYzk6IiNtA7Zw0l dPf4TFgLO8epnexKF.qY3U_TISnGBv6ZkmA1BjCHf8q_0JUPmRfEZhzc.TZxJiUgbG1DRCQCJfXd iVv6sfrX2WIdl_jgOFEyiKT9CnaFk0ebe0KN21Tcelx2fPobFgDscx8xjE5BKE5D.aAAoIjTGQU_ E95S_UivdvtlTM2dF5Oq_3iNhrqULETWXrvz23vXvQtG8SOygxh9HFGUr1nXhObOdAZWoFfcW5cb tFI.ean2K7H8r75XtoltEP6bhHO0zX44SIrt8GFfALT9LK494BJscDvO0iAkY5yCIskJxis2VEto M5UX6vDPwegXlsvovpc3WlFWY7HKNVF_Ia0mDw72ai9km73M3L6bnlFXEH3_LLcePW8GgePWXXUI iugrpbdrYBB7L2AgFBSLikh6QkQhTDPGo6JkRuhiYg_WDVsvDms4bimKH8_rH17t.UfA1543pZv7 ykcwKxt9FSn5xF5jDJzqfbQLiQ6Z4OemMbt0ZxdM.v2Zhan29muw6D_pxw_OAm67oMXEn9k7MeQT 7RdeBvcWJPHxr_2p1nhjhdvcQQgOWU_fGQaGXTktjFM2RExB0YjyFnzVWKoUHW7tVRQv.uvN1IEa fp_PuNHc3h8WeXP0mEMEy8OydCaxBw7dQA8lQK3qOtxfxFYh0bJlRxSLtS.TRB4hnCTwxdRuttnN e5peiaDdGijrnwK.otvfIuKzCe.8q8KF9H33GS5yiJu0MigfAahZEzISJj1ithTXRb6TZGB92SEd XciJ01ISar7M3l2vCaFIoNjdQNhNmsT_FlBotItmEpEtJAhHd1AmUOpCRtU5wI9CHPIirwyeljyh fO4CvpUfs13AlWwCDa8nraISH3DWrwn6yU.S46C.pUBaoPY4GeqpSgFZluQlDn4fyEzv2DvwPyKK Hx2x6jLSNmFnue3QXcRdYtYvJpPnQWwl.bJpQu6z0cWoQq2j6FJzWa3nCq9ysGbi5ZhkPeZVholT A1m7qABZTOMDQwBVBXTeG2FlmsvcAB1VTiLQHjETbYdkO5WQG7zVinWWT8AQxBlSJ1N12R3zLCh6 TA4lz45A2YtMqSD2MFbCVEwAXsMc_JSq.QDNnlI8gQFEhbYlblc61fxokOS5ziUZAcGMtCmVrHNU oAw-- X-Sonic-MF: X-Sonic-ID: fe8a122f-0cc0-4c92-b717-75a68e6418af Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.gq1.yahoo.com with HTTP; Sat, 20 May 2023 19:00:08 +0000 Received: by hermes--production-ne1-574d4b7954-bq277 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 40fb482f13db21b8a093bb27b262092f; Sat, 20 May 2023 19:00:03 +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 \(3731.400.51.1.1\)) Subject: Re: Armv7 (rpi2) getting stuck in buildworld for -current From: Mark Millard In-Reply-To: <03F330A1-35E4-40D4-B9C6-407041BBEC58@yahoo.com> Date: Sat, 20 May 2023 11:59:51 -0700 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: References: <7758885B-3115-47F0-A453-1C010313D4B8@yahoo.com> <03F330A1-35E4-40D4-B9C6-407041BBEC58@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3731.400.51.1.1) X-Spamd-Result: default: False [-3.42 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.92)[-0.920]; 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]; MIME_GOOD(-0.10)[text/plain]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.31:from]; TO_DN_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; DKIM_TRACE(0.00)[yahoo.com:+]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org] X-Rspamd-Queue-Id: 4QNtLy3b5Xz3sWD X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N I set up the RPi2B v1.1 and started a -j4 buildworld buildkernel from-scratch rebuild on/of: # uname -apKU # long output line split for readability FreeBSD OPiP2E_RPi2v1p1 14.0-CURRENT FreeBSD 14.0-CURRENT #74 main-n262658-b347c2284603-dirty: Fri Apr 28 23:07:41 PDT 2023 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA7-nodbg-clang/usr/main-src/arm.a= rmv7/sys/GENERIC-NODBG-CA7 arm armv7 1400088 1400088 (The original build was done on another machine.) At somewhat under 18 hrs it finished with the large swap use during the overlapping time frame for these 4 builds: clang/libclang/CodeGen/CodeGenAction.o clang/libclang/CodeGen/CodeGenFunction.o clang/libclang/CodeGen/CodeGenModule.o clang/libclang/CodeGen/CodeGenPGO.o These are my notes from the information for somewhat after the swap use dropped off. My armv7 builds disable targeting other architectures but I also have WITH_CLANG_EXTRAS=3D . (Not that the build has gotten that far yet.) I show the controlling file content later below. I used no assignments for: #vm.pfault_oom_attempts=3D-1 #vm.pfault_oom_attempts=3D 10 #vm.pfault_oom_wait=3D ??? but did/do have: vm.pageout_oom_seq=3D120 vm.swap_enabled=3D0 vm.swap_idle_enabled=3D0 in use for this experiment. FYI: make[1]: "/usr/main-src/Makefile.inc1" line 326: SYSTEM_COMPILER: = Determined that CC=3Dcc matches the source tree. Not bootstrapping a = cross-compiler. make[1]: "/usr/main-src/Makefile.inc1" line 331: SYSTEM_LINKER: = Determined that LD=3Dld matches the source tree. Not bootstrapping a = cross-linker. (Those 2 have significant time implications for the overall build.) Based on (my modified) top, sampling every 3 seconds, Mem: . . ., 754020Ki MaxObsActive, 186756Ki MaxObsWired, 923356Ki MaxObs(Act+Wir+Lndry) Swap: 1740Mi Total, . . ., 756828Ki MaxObsUsed, 1442Mi MaxObs(Act+Lndry+SwapUsed), 1615Mi MaxObs(Act+Wir+Lndry+SwapUsed) So: slightly over 739 MiBytes of swap observed to have been in use at one time. As for the overlapping time's duration: file creation and modification times, in time order were: (via extraction from ls -TldU output:) 09:37:28 creation of clang/libclang/CodeGen/CodeGenAction.o 09:38:44 creation of clang/libclang/CodeGen/CodeGenFunction.o 09:40:19 creation of clang/libclang/CodeGen/CodeGenModule.o 09:41:28 creation of clang/libclang/CodeGen/CodeGenPGO.o (via extraction from ls -Tld output:) 09:47:15 modification of clang/libclang/CodeGen/CodeGenFunction.o 09:49:53 modification of clang/libclang/CodeGen/CodeGenAction.o 09:50:10 modification of clang/libclang/CodeGen/CodeGenPGO.o 09:54:49 modification of clang/libclang/CodeGen/CodeModule.o So: 09:41:28 . . . 09:47:15 (under 6 min) for the overlapping time frame and the highest swap space use happened inside that interval. During this, there were times mixes of CPUn and "swread" STATE for the compiles. But at no point were all observed to be blocked waiting, at no point was only 1 observed to show a CPUn with a large WCPU. This is largely attributable to the USB media having tiny latencies compared to spinning rust and having reasonable transfer rates for the type of I/O: NMVe USB3 media (that is also USB2 compatible for USB powered usage). My use of: # # Delay when persistent low free RAM leads to # Out Of Memory killing of processes: vm.pageout_oom_seq=3D120 and: # # Together this pair avoids swapping out the process kernel stacks. # This avoids processes for interacting with the system from being # hung-up. vm.swap_enabled=3D0 vm.swap_idle_enabled=3D0 did not lead to any problems so far. For reference: Via systat -vmstat I monitored . . . VN PAGER SWAP PAGER in out in out count =20 pages ioflt . . . . . . intrn . . . Both VN in and SWAP in can contribute to ioflt, faults that required I/O. The ioflt number would be before the "ioflt" text. There is a later line that lists intrn (somewhat below ioflt): "in-transit blocking page faults". The intrn number would be before the "intrn" text. The figures varied under 600 for ioflt and intrn for what I saw during the large swap space use, with matching SWAP activity, no significant VN activity. (The figures are for an about 5 second update interval, as I remember.) (I watched the on screen updates. I did not try to capture the material in a file.) I expect that these figures would be large for a sustained period in your context. I also monitored with "gstat -spod". I assume that stat is more familiar. (I use -spod even when "d" happens to not be going to show any activity.) [I do not recommend leaving "systat -swap" running: it accumulates a large set of memory leaks and so can mess up tracking swap space use by being a signficant contributor. I did not put it to significant use other than discovering that problem.] Configuration points . . . /boot/efi/config.txt has: enable_uart=3D1 dtoverlay=3Dmmc # # Local addition that avoids (at least) USB3 SSD boot failures that look = like: # uhub_reattach_port: port ? reset failed, error=3DUSB_ERR_TIMEOUT # uhub_reattach_port: device problem (USB_ERR_TIMEOUT), disabling port = ? initial_turbo=3D60 # # Local additions: uart_2ndstage=3D1 dtdebug=3D1 kernel=3Du-boot.bin.2023.01.armv7 kernel7=3Du-boot.bin.2023.01.armv7 dtoverlay=3Ddisable-bt # force_turbo=3D1 ( /etc/rc.conf has powerd commented out. ) (I build u-boot with a couple of settings added.) (Leaving initial_turbo in place allows disabling force_turbo independently --but still allowing the USB booting to work during the temporary turbo status. intial_turbo is not required when force_turbo is enabled --but does not hurt.) /boot/loader.conf has : # # Delay when persistent low free RAM leads to # Out Of Memory killing of processes: vm.pageout_oom_seq=3D120 # # For plunty of swap/paging space (will not # run out), avoid pageout delays leading to # Out Of Memory killing of processes: #vm.pfault_oom_attempts=3D-1 # # For possibly insufficient swap/paging space # (might run out), increase the pageout delay # that leads to Out Of Memory killing of # processes: #vm.pfault_oom_attempts=3D 10 #vm.pfault_oom_wait=3D ??? # (The multiplication is the total but there # are other potential tradoffs in the factors # multiplied, even for nearly the same total.) (As I understand you are now using defaults for vm.pfault_oom_attempts and vm.pfault_oom_wait . So I did as well for those 2 for this experiment.) /etc/sysctl.conf has: # # Together this pair avoids swapping out the process kernel stacks. # This avoids processes for interacting with the system from being # hung-up. vm.swap_enabled=3D0 vm.swap_idle_enabled=3D0 # more ~/src.configs/src.conf.CA7-nodbg-clang-alt.aarch64-host=20 TO_TYPE=3Darmv7 # KERNCONF=3DGENERIC-NODBG-CA7 TARGET=3Darm .if ${.MAKE.LEVEL} =3D=3D 0 TARGET_ARCH=3D${TO_TYPE} .export TARGET_ARCH .endif # WITH_SYSTEM_COMPILER=3D WITH_SYSTEM_LINKER=3D # WITH_ELFTOOLCHAIN_BOOTSTRAP=3D #Disables avoiding bootstrap: WITHOUT_LLVM_TARGET_ALL=3D WITHOUT_LLVM_TARGET_AARCH64=3D WITH_LLVM_TARGET_ARM=3D WITHOUT_LLVM_TARGET_MIPS=3D WITHOUT_LLVM_TARGET_POWERPC=3D WITHOUT_LLVM_TARGET_RISCV=3D WITHOUT_LLVM_TARGET_X86=3D WITH_CLANG=3D WITH_CLANG_IS_CC=3D WITH_CLANG_FULL=3D WITH_CLANG_EXTRAS=3D WITH_LLD=3D WITH_LLD_IS_LD=3D # WITH_LLDB=3D # WITH_BOOT=3D # WITHOUT_WERROR=3D MALLOC_PRODUCTION=3D WITH_MALLOC_PRODUCTION=3D WITHOUT_ASSERT_DEBUG=3D WITHOUT_LLVM_ASSERTIONS=3D # # Avoid stripping but do not control host -g status as well: DEBUG_FLAGS+=3D # WITH_REPRODUCIBLE_BUILD=3D WITH_DEBUG_FILES=3D # XCFLAGS+=3D -mcpu=3Dcortex-a7 XCXXFLAGS+=3D -mcpu=3Dcortex-a7 # There is no XCPPFLAGS but XCPP gets XCFLAGS content. (An armv7 host does not need differing content than an aarch64 host, thus the use of the *.aarch64-host file.) However long the overall build ends up taking, the above is part of why the details end up as they will end up. /etc/crontab notes: I do not know if you leave the following enabled during the long builds or not ( from /etc/crontab ): # Perform daily/weekly/monthly maintenance. 1 3 * * * root periodic daily 15 4 * * 6 root periodic weekly 30 5 1 * * root periodic monthly that can run things like "/usr/local/sbin/pkg check -qsa" (daily example) that would compete for resources. I left them active, so daily competed with the build for a while, but it did not happen to overlap with the high swapspace use time frame. I commonly disable these for builds that will span into the hours it indicates, at least when I'm monitoring builds for comparisons and such. =3D=3D=3D Mark Millard marklmi at yahoo.com