From nobody Tue Nov 08 07:05:16 2022 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 4N5zdV4Dklz4gbv2 for ; Tue, 8 Nov 2022 07:05:34 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic311-23.consmr.mail.gq1.yahoo.com (sonic311-23.consmr.mail.gq1.yahoo.com [98.137.65.204]) (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 4N5zdV1ShWz3N6N for ; Tue, 8 Nov 2022 07:05:34 +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=1667891131; bh=xFFB3k0xsqdsEG0Ha8iOvyOG3FnFY35r0h1LxEySYDo=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=uXFFwLnBPy3IdDQy3J6IAX/kvNnqU1urwMN7m6v4RvGb0jRuN8gMTJfVr00o8OBN8LZveTIR1xEUK+C6Xmyz063U4bIqJNnYkgd1GMGQPzNQkx2qDPuGTA2zJMwXzvJzG7RZq0y/UmkTayPKdbpvdXVF7oUvuPtNeZ4tfv4zVtzVPzYD8eRuaBvlNXVeiXOpvj6ks5GEooLdvyaQnOnipzW5HH6dWHMNJca9Tv1ja8sbU/inb0N823DLP1HfpoJBinGpkpm9TtAJG1RTqs7uGflJFRpC7vmJEkD9VXl5Qo2VDKe82TJwMo5SvrZFVrALkleBWx/7zVYNYnsX5bIshQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1667891131; bh=X4GraUN4WzHumC504eIiLo+mXjE6vqGIEsQIvRjFxqj=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=WWie2NJL6PRHflqkJ5fJRMRoxkprmmm/HMs/CStk+TBcZs6QqJrWGU38/Clz3aaa0+b3K53EpNx2dckOZKEpZwO16w1oz6YHVkN06Nhedg8+acKbE1RroERIsXa7pZybsCnMAGu5ackKAhbu2KI5g68k9raRnPey9GpU1yDh7vEGVAGsRvsMCVeO8rJNEqcFpgrHckDJRPzv1NI7dulfSYXAJFCDlB/u/cli5RA3+d80YHR9hA3eYZYHl32lX8SZd16PVTsSHNrfCHRDzuTmXW5e4ateguUuZpi+yeYBZSJITnvbJxgkIoJhlh/E6hV7LUtzJUFbTJvWDEhXGs7T8g== X-YMail-OSG: 16QeWGwVM1nRuDUoFLlX0NQXS8N4cbAfFAgQTxfWwDBZZjXlEv_1RMeoCWUw2jV tRzxEgiWfm4buGFhGb087I7gXk3TFno0QeLf0SE99qCkcMWft58O2AXM7isbr8XajokjRRlnRU_. o_sqigpCv4OhYUkF9xuBYlF93zxyCEMX7FpG5_Wk44Db1mPkq58oAbehw9Xl5_vppA8MAyY.rWdH BGoGogoYIAUrBjvmDoWRfsMOBc_YMb5bYJHIa.6BAVOctEOaCk37vNb1S96ubLg7eEvh1cjlagdC 32V7caCeEYmIdzUvNn.8INwIqKl1Psyq8yXuuEZYeL7A5QRVntpeWo.LcL54CdKH7rkd1wlG2qjy ZIE6zUUkTBwD8OLK4FRwaXmYfM.bFPkVYqtS8F3B40zgY0_xGA.B_XzTqr5wKfUMo_LBXRMze0N6 xXjkm5YOoNSR.mQs4DHP9OVU78KzI7U4DYzeyvVr815sX4wErdoz0EBpk8XIWAeZBOzD1jmM4HR9 .9q_cNdhPRZOPrZJwmkX40akcULsEC6.UictIDLfU73ccaY4y5cFgNDfRrOTPCBcw8prZHBmnj.u jO6GMk09VuPHSef6qJvhVnr4X6JFm6TfAZz4NwAgIhoYPBb9s8tTHQsPSO0q5gAh8FdziQGSodoF wJTu4MuYFGL4szDu96aE93ArkSaun6fZhW8WmcDiRs_1Ck67tMgB1mwrNU0ND8CpqZYeWT.AiL2z iLeq2rBIDtyGCfcCzgmBdGF_gI7r5X9NWyPKp1KnIbGvyY9OnM7bU6OhBE_WnXL4KkrzXAyef3Dz WlbIxsLxPU0FxkiU__IE2tbCvRp6uO3fzJZ4nE0QS0UPYV9D6ibWjxbBhNikWxEgFoE5rSYURwaz 2z21xxHa4wX9PTehS46rwz8ORhr1FX4Np268unFsY1RJdIUkWtyhNg9MX65ol4UkC7YFzYvc3d_H tpqXOQk077bjym9EqGU1Q9JqXpqenRAs_iD0jBS7YVbEhrlETeOFOl_Y97uJYAjbN_XP9NCtB88w HbuedevD1CZTgmiOaASJ6.uUgi63THIcyODI9CV3ZQfIEbJQJ5yLiUYSWXYX20XuKiB_Wj6zdTAK CPJL9iE_1o6pwgQzrtjRNmSLJu0hadFZdm2tAMKL0wv8YWyDAWvXhn8ZRxUdHEaPwUHqZ5i2MOe2 YjAS22mrHhg51wvHLrIhAZQ.lMUbfwma0diCycFLbXMhgMx679.RB2yPeTdB4GXN.l8aRtuc.xnX OOdEK2Le7KP82juD5aF5W0.1aXrhrdMml34AkHTvA13ulgxjBDipHQ5P5_VgwZDsrmSU9P4zkyRj 3q_5jYxT2I.N5H7ni4v2VGN2ILh5HCAVDnvvgc.Ph138_A4_L6FJJlSl5NOXgsp_Hwio2KS0RZb6 1OfFLb240cGdhTKwMmsnxZASKGtVGBPcGh50rP50H4sG9ENbaWE8XUuDKnB3B7SjMF.u1j6FkiBM cyJFUrHGDkvxndzS7PwUZSj4RznZtBEAv6Qe2F4_l81SSQVM2OMg7ZPZytt8mQTY4EfDB246mczE Aez4QTHdoHDZp6aagdWWUqwJu1lCcJ46cg1I8nBs.hq6ncJlFsSxhfjIMppoOeQeGlAAPHLKgtmG JF5NW0uRcA7isFWwYu.CZLWP8U1RoMfd7nMHVqnpxeD48U6GiNNbsD9Cc0tQFbdV7M95.5AIU._x jE8nwNV9hzuzXI3S1z2krbsu5Qw7oCLEywMawtjzR8X2qVZ3gduMMcOH6HH7nd.cc8gbv7d09fcT t3vogENnwzCg5bzvSFGLsU.hKpKxJ1SyBongJe5m1igB3G08VJH1qDIBsdr7QyEHwB7DpMopW8lz 8WzgFWafWFZ.vAz40GPFSJbzKD7lIxcPWtxr3.uH4PeioMGcVW_yjm5JQLVWgqYcurhqjZkunqsx RuqjNR14GvlywGmLJSGQ.bCxAZizwXC0Gr9kdtWsfBYVy_g5utPCADSDxHhrGrJzf7f_MhvUYlRk Ekne.9Uvuy8BpD2u.bsAteHu9TWjpv3h8yPZnWSf_Km3vYR2g9HQozMwN.lUkZZI1AHBOmRdHFGX ZRM215Qq.trV_YahHsioEPOntesIqFvqtN97DG2URYopLrGNPzJYXLWOwSQMqtNxJ8ETFFcpdhSC iRe_D1H6y4F728w5Mr1IhcPPw.TGMdqCCZZK3TMcLUQ5yd9pfYD.8g.vzl6JKhk_zcW5Nd0I.J9Z Z6al0o6QoyOaN78wOEsw5NhSfJS8kTs1AS5T6KM5HuGc6RsogXpNrNI0JupUEJ7HhfdhoyZi1W_p FCZY- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Tue, 8 Nov 2022 07:05:31 +0000 Received: by hermes--production-ne1-6bcfb7fb87-5nqxg (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 4b8b2113d8c56534af310daaa2c04471; Tue, 08 Nov 2022 07:05: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.200.110.1.12\)) Subject: Re: adding swap when expanding root filesystem From: Mark Millard In-Reply-To: <20221108043817.GA55121@www.zefox.net> Date: Mon, 7 Nov 2022 23:05:16 -0800 Cc: Mike Karels , freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <9BF0BEB8-6074-4607-BA1B-B3462C5CEA66@yahoo.com> References: <202211071610.2A7GAcHl090048@mail.karels.net> <20221107175206.GA49113@www.zefox.net> <78C2FBC4-D2CE-44B0-9535-02C0EDECD10A@karels.net> <20221107205150.GA53784@www.zefox.net> <09E80B35-0325-44E6-8191-55DCC79A51F1@yahoo.com> <20221108043817.GA55121@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3731.200.110.1.12) X-Rspamd-Queue-Id: 4N5zdV1ShWz3N6N X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] X-ThisMailContainsUnwantedMimeParts: N On Nov 7, 2022, at 20:38, bob prohaska wrote: > On Mon, Nov 07, 2022 at 04:07:08PM -0800, Mark Millard wrote: >> On Nov 7, 2022, at 12:51, bob prohaska wrote: >>=20 >>> . . . >=20 >> Also the amount of space >> U-Boot and the like takes varies. The Rock64 images >> use a 16 MiByte space for its U-Boot and the like, >> which are stored outside any file system.=20 >=20 > I'm not sure how anything can be stored "outside any > filesystem". Might it be better to say "in a private filesystem", > as in not known to the running kernel? Here are the instructions for putting U-Boot (and such) on a Rick64: # more /usr/local/share/u-boot/u-boot-rock64/README=20 U-Boot loader and related files for the Pine64 Rock64. To install this bootloader on an sdcard just do: dd if=3D/usr/local/share/u-boot/u-boot-rock64/idbloader.img = of=3D/path/to/sdcarddevice seek=3D64 bs=3D512 conv=3Dsync dd if=3D/usr/local/share/u-boot/u-boot-rock64/u-boot.itb = of=3D/path/to/sdcarddevice seek=3D16384 bs=3D512 conv=3Dsync idbloader.img and u-boot.itb are not file systems. They are found by the exact position that they must be put at, thus the seek=3D and bs=3D usage in the dd commands above. # file /usr/local/share/u-boot/u-boot-rock64/u-boot.itb /usr/local/share/u-boot/u-boot-rock64/u-boot.itb: Device Tree Blob = version 17, size=3D1184, boot CPU=3D0, string block size=3D131, DT = structure block size=3D992 # file /usr/local/share/u-boot/u-boot-rock64/idbloader.img /usr/local/share/u-boot/u-boot-rock64/idbloader.img: data The content in those files are not representations of file systems. Here is what a gpart show -p indicates for an example Rock64 media with idblooader and U-Boot on it via those dd commands: =3D> 63 244277185 da4 MBR (116G) 63 32705 - free - (16M) 32768 102312 da4s1 fat32lba [active] (50M) 135080 28760 - free - (14M) 163840 241172480 da4s2 freebsd (115G) 241336320 2940928 - free - (1.4G) =3D> 0 241172480 da4s2 BSD (115G) 0 230686720 da4s2a freebsd-ufs (110G) 230686720 10485760 - free - (5.0G) Note the: 63 32705 - free - (16M) The 2 dd commands above put the content of idbloader.img and of u-boot.itb into the so-called "free" space indicated, at very particular positions. > Is there any basic problem with automatically establishing a=20 > swap partition during a microSD card setup? A trio of self- > hosted armv7 Pi2's with swap on microSD have been running=20 > happily for over two years as name, mail and webservers on=20 > 64 GB cards. Admittely, aarch64 is a lot more swap-intensive,=20 > but a Pi3 ran for about a year on a 128 GB card before things=20 > started going wrong. That Pi3 was running buildworld > most of the time. Are you asking for someone to give such support to each of the following contexts (ignoring u-boot-master and u-boot-tools and the like that also show up in the list)? # ls -dC1 /usr/ports/sysutils/u-boot-* /usr/ports/sysutils/u-boot-a13-olinuxino /usr/ports/sysutils/u-boot-a64-olinuxino /usr/ports/sysutils/u-boot-bananapi /usr/ports/sysutils/u-boot-bananapim2 /usr/ports/sysutils/u-boot-beaglebone /usr/ports/sysutils/u-boot-chip /usr/ports/sysutils/u-boot-clearfog /usr/ports/sysutils/u-boot-cubieboard /usr/ports/sysutils/u-boot-cubieboard2 /usr/ports/sysutils/u-boot-cubox-hummingboard /usr/ports/sysutils/u-boot-firefly-rk3399 /usr/ports/sysutils/u-boot-imx-serial-loader /usr/ports/sysutils/u-boot-master /usr/ports/sysutils/u-boot-nanopi-a64 /usr/ports/sysutils/u-boot-nanopi-m1plus /usr/ports/sysutils/u-boot-nanopi-neo /usr/ports/sysutils/u-boot-nanopi-neo-air /usr/ports/sysutils/u-boot-nanopi-neo2 /usr/ports/sysutils/u-boot-nanopi-r4s /usr/ports/sysutils/u-boot-olimex-a20-som-evb /usr/ports/sysutils/u-boot-olinuxino-lime /usr/ports/sysutils/u-boot-olinuxino-lime2 /usr/ports/sysutils/u-boot-olinuxino-lime2-emmc /usr/ports/sysutils/u-boot-orangepi-one /usr/ports/sysutils/u-boot-orangepi-pc /usr/ports/sysutils/u-boot-orangepi-pc-plus /usr/ports/sysutils/u-boot-orangepi-pc2 /usr/ports/sysutils/u-boot-orangepi-plus-2e /usr/ports/sysutils/u-boot-orangepi-r1 /usr/ports/sysutils/u-boot-orangepi-zero /usr/ports/sysutils/u-boot-orangepi-zero-plus /usr/ports/sysutils/u-boot-pandaboard /usr/ports/sysutils/u-boot-pcduino3 /usr/ports/sysutils/u-boot-pine-h64 /usr/ports/sysutils/u-boot-pine64 /usr/ports/sysutils/u-boot-pine64-lts /usr/ports/sysutils/u-boot-pinebook /usr/ports/sysutils/u-boot-pinebookpro /usr/ports/sysutils/u-boot-qemu-arm /usr/ports/sysutils/u-boot-qemu-arm64 /usr/ports/sysutils/u-boot-qemu-riscv64 /usr/ports/sysutils/u-boot-riotboard /usr/ports/sysutils/u-boot-rock-pi-4 /usr/ports/sysutils/u-boot-rock64 /usr/ports/sysutils/u-boot-rockpro64 /usr/ports/sysutils/u-boot-rpi /usr/ports/sysutils/u-boot-rpi-0-w /usr/ports/sysutils/u-boot-rpi-arm64 /usr/ports/sysutils/u-boot-rpi2 /usr/ports/sysutils/u-boot-rpi3 /usr/ports/sysutils/u-boot-rpi3-32 /usr/ports/sysutils/u-boot-rpi4 /usr/ports/sysutils/u-boot-sifive-fu540 /usr/ports/sysutils/u-boot-sifive-fu740 /usr/ports/sysutils/u-boot-sinovoip-bpi-m3 /usr/ports/sysutils/u-boot-sopine /usr/ports/sysutils/u-boot-sopine-spi /usr/ports/sysutils/u-boot-tools /usr/ports/sysutils/u-boot-utilite /usr/ports/sysutils/u-boot-wandboard Just all those that happen to have snapshots made these days?: 13.1+ and 14.0: armv6 RPI-B armv7 GENERICSD aarch64 GENERIC aarch64 RPI aarch64 PINE64 aarch64 PINE64-LTS aarch64 PINEBOOK aarch64 ROCK64 aarch64 ROCKPRO64 riscv64 GENERIC riscv64 GENERICSD 12.4 (in process) : armv6 RPI-B armv7 BANANAPI armv7 CUBIEBOARD armv7 CUBIEBOARD2 armv7 CUBOX-HUMMINGBOARD armv7 RPI2 armv7 WANDBOARD armv7 GENERICSD aarch64 GENERIC aarch64 PINE64 aarch64 PINE64-LTS A subset of those? What fraction of what size user base actually does large port builds and buildworld buildkernel or the like on each of these [or otherwise needs swap space in order to have enough memory space (not just RAM)]. If the volunteer(s) that provide this context have no interest in doing such activities on such hardware, how likely is it that they are going to provide the more involved setup? > . . . >=20 > Configuring swap manually on a RPi microSD system is a very > considerable amount of work. That might contribute to what the volunteer(s) choose to do or not do. > Having it happen by default=20 > wastes at most a few percent of the card capacity. Presuming large enough capacities. 3.5 GiBytes would be more than 10% of 32 GiBytes, for example. What is the distribution of media sizes for folks that do not do large port builds or buildworld buildkernel on such systems --but do use such systems in some way? What fraction of the overall use of such systems is that set of folks? > At this > point I can't see any reason to say it's a bad idea and > have some personal experience to suggest it's a good idea. Getting someone else to be interested in doing what you would find useful can be a challenge. Nothing about that requires that the idea be a bad idea. There are far too many good ideas for various context(s) to implement them all for all the spanned contexts. > [bsdinstall limitations snipped] >=20 > It might be worth mentioning the /boot/loader.conf and=20 > /etc/sysctl.conf additions you've mentioned in other threads, > as adjuncts to having autoconfigured swap on microSD. They've > all been helpful in my experiments on RPi2 and RPi3. I think > they'd be constructive additions to the RPi images and perhaps > others..=20 >=20 Mostly, these things go back to what we learned from markj primarily (vm.pageout_oom_seq) and kib primarily (vm.pfault_oom_attempts and vm.pfault_oom_wait), presuming that I remember which-for-what accurately. Using vm.swap_enabled and vm.swap_idle_enabled to avoid a form of losing communication with the system(s) when they are using the swap/paging space is more recent. =3D=3D=3D Mark Millard marklmi at yahoo.com