From nobody Sun Dec 10 13:08: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 4Sp4wR0Qfgz53nNx for ; Sun, 10 Dec 2023 13:09:43 +0000 (UTC) (envelope-from jsm@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 4Sp4wQ6qW4z4Xkb for ; Sun, 10 Dec 2023 13:09:42 +0000 (UTC) (envelope-from jsm@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1702213783; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=dtYDdFtnKdcETPobU9+8UbF8rA5t+CCmWOG6lOLjIAY=; b=iQawRYHFKcVIPobEPaLgTVB/dEul07+xYrEui+UcXWGwPPBQFg1UMz5G7AJv/HPV3YObIs yCh0XauBUSEpOoo+D0w10xNAM69MGRAm79HDW3nNCNtdqbsjx2p/VU+pPMPAkXFxAUc23q dATMDxVcIT+1te09QdB3MKr30hhsDwKsYOLHo5VkdrhW+GJhf6WIZz6KrvnAMBFsSLsL79 FKMQlIYD/WX/WzacefwYTLVPDNTtpRqmRWUTOw4pGciyPXemU9HnraYZRWbK5/fGEX4ldH H3CSYf8eN6Q0SiCDV4qCgHW8jqalLsljbdKxc+JYoX9V4s55sRjX6FiAmRP1Nw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1702213783; a=rsa-sha256; cv=none; b=DTojHVx41GZu4TaHvEYN+a82KpxAtO59qhgFNaFXym3r+ZZoUo6uPZsnflkDNKNgqgH47O 1oc/MsXn6gAPuLAE6ywMJSzxvAk3gxepRN5t6+iHVBUDZuAfBdkwkAcuEMbq66GC7eQ7BO hpxfZP+xo58CaYXX7MUN7U0Y2Zfl+u2IhKyPpFPWsM/nKv5Zxq6nZ24Q3i/NgWjn0sr9pB P85FnY1gpcqHQklkACx9l0j6fDZIIUrqXCQ65XqbK0TTtIjN7urb/o+/lyYehK/80BdaLR wo0UKI7XsE5h6NQXu91RUFN10sqINtoVW/c9OgqZ+cipzyWA2zwO6ze9f1Fd0Q== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1702213783; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=dtYDdFtnKdcETPobU9+8UbF8rA5t+CCmWOG6lOLjIAY=; b=gAri1up6PXMQE81fAxk/1DvFM3dQEPuA4piNOqWasTZQfDnO6n/b3TeZ0caBJE5VJFSLgQ Jie2eI6IY3UFEoom9kf8zq0nnaMSfzXmSiucRN1eo2jQuqHVyCgZ0I8oKrknQoZZokhCJ1 ukzSK0fc0ADIaD4EWh9Ce0bCtvrvF8zGGVlQDTM4wUvjdM2YO1mxTRZ0EnhhEDJ2VzVPiL Gw2EbkjieCx5Vqj0Tt91Wlia4/lWDieF8UvLiFT1bDpYX4KCAJIDJVMKd7jLtP/gFrQSXd E+e1UcN+8XfFrZ7XgbaawAbDtcfYGN9y435TQW/DAaRGcGZN0qw3wUBY3g8+hA== Received: from [192.168.1.5] (mail.northatlanticmusicsupplies.com [212.237.182.202]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: jsm) by smtp.freebsd.org (Postfix) with ESMTPSA id 4Sp4wQ440gz12T5 for ; Sun, 10 Dec 2023 13:09:42 +0000 (UTC) (envelope-from jsm@FreeBSD.org) Message-ID: <27c55e4e-21d2-44f7-9436-95fa1e5b4722@FreeBSD.org> Date: Sun, 10 Dec 2023 14:08:59 +0100 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: firefox broken on arm64 Content-Language: en-US From: Jesper Schmitz Mouridsen To: freebsd-arm@freebsd.org References: <9518dc38-e44b-42ae-bf87-6039ac278ac8@FreeBSD.org> <46c52d37-36ec-45fc-8098-1029996c717c@FreeBSD.org> In-Reply-To: <46c52d37-36ec-45fc-8098-1029996c717c@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 03.12.2023 11.59, Jesper Schmitz Mouridsen wrote: > > > On 03.12.2023 09.38, void wrote: >> On Sun, Dec 03, 2023 at 08:34:21AM +0100, Jesper Schmitz Mouridsen wrote: >>> >>> Just build firefox-esr-115.5.0_1,1  and firefox-116.0.3_1,2 the first >>> runs with aslr disabled, the latter signals 4. >>> >>> Any suggestions on what is going on are appreciated. >> >> What's the uname -aKU ? > > FreeBSD generic 14.0-RELEASE FreeBSD 14.0-RELEASE #0 > releng/14.0-n265380-f9716eee8ab4: Fri Nov 10 09:12:14 UTC 2023 > root@releng1.nyi.freebsd.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC > arm64 1400097 1400097 > >  did you build from ports or poudriere? > From ports. > > If the >> latter, what's the /etc/make.conf contain? >> >> Please post sysctl -a | grep aslr >> > > kern.elf32.aslr.shared_page: 0 > kern.elf32.aslr.stack: 1 > kern.elf32.aslr.honor_sbrk: 0 > kern.elf32.aslr.pie_enable: 0 > kern.elf32.aslr.enable: 0 > kern.elf64.aslr.shared_page: 1 > kern.elf64.aslr.stack: 1 > kern.elf64.aslr.honor_sbrk: 0 > kern.elf64.aslr.pie_enable: 1 > kern.elf64.aslr.enable: 1 > vm.aslr_restarts: 256 > > I did the esr build to test the build setup, since also the pkg in the > official pkg repo behaves the same i.e the one before 115.5 since 115.5 > did not hit the pkg repo yet, which works without aslr (set by > proccontrol) So unless 116 introduces something which requires sysctl > changes for the building tool chain while building my test should be valid. > > Thanks > > /jsm > > Hi Just FYI I have managed to cross-compile firefox115-esr on amd64 to aaarhc64 so that takes me ~20 min compute time to compile as opposed to 5-7 hours on my arm boards... I think it broke somewhere between 115 and 116, but now bisecting is doable to the extend the port patches allows. Can someone btw tell me hove the libwebrtc patches are generated..? From nobody Tue Dec 12 16:22: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 4SqP6460Zgz548RZ for ; Tue, 12 Dec 2023 16:22:36 +0000 (UTC) (envelope-from mats@exmandato.se) Received: from mailout.mellstrand.net (mailout.mellstrand.net [IPv6:2001:2040:4:1::52]) (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 "mailout.mellstrand.net", Issuer "ZeroSSL RSA Domain Secure Site CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4SqP635Lkfz4cvd for ; Tue, 12 Dec 2023 16:22:35 +0000 (UTC) (envelope-from mats@exmandato.se) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=exmandato.se header.s=mailout header.b=DD6xTsJk; spf=pass (mx1.freebsd.org: domain of mats@exmandato.se designates 2001:2040:4:1::52 as permitted sender) smtp.mailfrom=mats@exmandato.se; dmarc=pass (policy=reject) header.from=exmandato.se Received: by mailout.mellstrand.net Tue, 12 Dec 2023 17:22:27 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=exmandato.se; s=mailout; t=1702398147; bh=CtMfEFuexxtFYEE8JVI2ZGO7uJOv+f6cSfSkAxdc3XU=; h=From:Subject:Date:To; b=DD6xTsJkpxm+HfrPgiuVEmV6lXAY0Zf8V4bsAvAM0sN6vghS0gP6KO2c5ESEMNrjA KFc9ZQU9230ybPIfFruKoxxKST73j5goZyl4GG/Tt7hEe43+oFN8wgxlgeeW4fx8BV mmRjNvbsyv0XWRCIM/+WNlXn2022I3rwxwRAOznaCkLbqyb5MgbIs8liiL+KH2DPDE NZU7cIkvGpma0jt+c/OMD+dG+ghwPBKnRMSdyHpairXasOpzzgx05kld8XFvRMRnpb TQbmAXJfa32ll3LGExCiR9FNwHr3K1fxWhZM3hKG3MFah8t3cDDbU4DpKXbgFsAiT/ rh3rPJ+OMTYkA== From: Mats Mellstrand Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 Subject: FreeBSD on raspberry PI 5 Message-Id: <0856BB69-6BDB-4570-B010-F22BF262DE84@exmandato.se> Date: Tue, 12 Dec 2023 17:22:16 +0100 To: freebsd-arm@freebsd.org X-Spamd-Result: default: False [-3.48 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.98)[-0.982]; DMARC_POLICY_ALLOW(-0.50)[exmandato.se,reject]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+a:mailout.mellstrand.net]; R_DKIM_ALLOW(-0.20)[exmandato.se:s=mailout]; MIME_GOOD(-0.10)[text/plain]; RCVD_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; ASN(0.00)[asn:3301, ipnet:2001:2040::/32, country:SE]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[exmandato.se:+]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; TO_DN_NONE(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Queue-Id: 4SqP635Lkfz4cvd X-Spamd-Bar: --- Hi, Has anyone had success installing ad run FreeBSD on Raspberry Pi 5 If so, how did you do? /mm From nobody Tue Dec 12 16:55: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 4SqPrk5JVRz54BV1 for ; Tue, 12 Dec 2023 16:56:06 +0000 (UTC) (envelope-from wschnr@googlemail.com) Received: from mail-ej1-f54.google.com (mail-ej1-f54.google.com [209.85.218.54]) (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 4SqPrk0TNrz3FQJ for ; Tue, 12 Dec 2023 16:56:06 +0000 (UTC) (envelope-from wschnr@googlemail.com) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of wschnr@googlemail.com designates 209.85.218.54 as permitted sender) smtp.mailfrom=wschnr@googlemail.com; dmarc=none Received: by mail-ej1-f54.google.com with SMTP id a640c23a62f3a-a22eba5a290so102119666b.3 for ; Tue, 12 Dec 2023 08:56:06 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702400163; x=1703004963; h=content-transfer-encoding:to:subject:message-id:date:from :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=JBLhcVs+9giUj9pfpy7Pf+fGoQeF07as9yCN3SRjJs0=; b=YJNUi9wpzyC35cTC3+mbbO23akktPg7ThtgaQ6UmRVRMTLdMs8nsOOV37cVbyyhT74 iKMB4ppfo2oSTBdLo1XKM1kez1AcmrDVMuNM7GLWw5UuToImObxSqxQt8oKKMd/OgY0l BlGLhwwY9MPSAvZ2C8KkSTrAgLwIcXHdEfjfGmFiSGyz9JYORj9TkHmRUNfDLjCgJ2FG GuQyhVv/DRFD4RpJO7X48LqUM/FSZhMTG1C3BWa+s9fjEcAs0XJ8X3knYe4j+9zsyadr zecdaKsyf4UKWcwr+uTWLGOyiB4knisiBNfnsD0QZuBpV0vczP2+sAeh/DVvgJI4L+JD EvoQ== X-Gm-Message-State: AOJu0YwmwMNe4camX7CaJbROBvQcdQb4anUlVd05FIc7R+LdTvkl5vbp tm1Z2h4rH+tkhd4taGC9OpuwQc8VqZVZ6mFgeHgi/h1NqKloOQ== X-Google-Smtp-Source: AGHT+IFfUvD+GtujZr6GwzyRqNcKWyNJ0JZtDol4Aj5T2j9XECjbfkFno6YdfIsc1j5ynVzbW35S9LrR1nhniDv0wSY= X-Received: by 2002:a17:906:2207:b0:a1f:9f48:6cbf with SMTP id s7-20020a170906220700b00a1f9f486cbfmr2061368ejs.92.1702400163347; Tue, 12 Dec 2023 08:56:03 -0800 (PST) List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 From: Wolfram Schneider Date: Tue, 12 Dec 2023 17:55:51 +0100 Message-ID: Subject: FreeBSD 14.0-RELEASE/arm64 runs fine on Hetzner cloud To: freebsd-arm@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Result: default: False [1.62 / 15.00]; NEURAL_SPAM_LONG(1.00)[1.000]; NEURAL_SPAM_MEDIUM(0.99)[0.992]; FORGED_SENDER(0.30)[wosch@freebsd.org,wschnr@googlemail.com]; NEURAL_HAM_SHORT(-0.27)[-0.274]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; RWL_MAILSPIKE_GOOD(-0.10)[209.85.218.54:from]; MIME_GOOD(-0.10)[text/plain]; RCVD_COUNT_ONE(0.00)[1]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; R_DKIM_NA(0.00)[]; FROM_NEQ_ENVFROM(0.00)[wosch@freebsd.org,wschnr@googlemail.com]; RCVD_IN_DNSWL_NONE(0.00)[209.85.218.54:from]; DMARC_NA(0.00)[freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[googlemail.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; TO_DOM_EQ_FROM_DOM(0.00)[] X-Rspamd-Queue-Id: 4SqPrk0TNrz3FQJ X-Spamd-Bar: + Hi, I tried the new iso image FreeBSD-14.0-RELEASE-arm64-aarch64-bootonly.iso on the Hetzner.com arm64 cloud. There are a lot of improvements since FreeBSD 13.2 for arm64. Everything worked fine during the installation, I used the default setup with zfs. Thanks to everybody who made this possible! The system reports itself as: hw.model: ARM Neoverse-N1 r3p1 apparently an Ampere =C2=AE Altra =C2=AE Q80-30 CPU. In case you are wondering about the performance - I tried the biggest VM and ran 'make buildworld'. It took 30minutes. hetzner cax41 (arm64), 16 cores, 32GB RAM, zfs on nvme >>> World built in 1817 seconds, ncpu: 16, make -j16 disk I/O: 1.3Gbyte/s The arm64 VMs at hetzner.com have more RAM or CPU for the same price as the intel/amd based VM. I estimate overall the arm64 VMs are are 30-40% cheaper than amd64 VMs at Hetzner. -Wolfram --=20 Wolfram Schneider https://wolfram.schneider.org From nobody Thu Dec 14 11:17: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 4SrVFK1gFLz53qbw for ; Thu, 14 Dec 2023 11:17:41 +0000 (UTC) (envelope-from ronald@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 4SrVFK17Kxz4VPF for ; Thu, 14 Dec 2023 11:17:41 +0000 (UTC) (envelope-from ronald@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1702552661; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=pUoGJuXnWcw7QvGfmrKqtPkxR56OlshzEm13MxTzN1s=; b=AgeBclVdaJ1vLvFDKTOidlbH9HzXo3NsWBkDl76a4zo8PQ1Dx1wHb1o9/ETC8WzlXyHlzJ 7VHJeF6+ex2ObpI6CmgEjKv9qxCHcDQClB2aCghSOTpnd20giRUnPnkphnRyvGtcpOWEy4 BNgLa4twO9j0NsQaH8fCdSCwu/n0qe3dWP18WHWbJv7mPGbzva8sGumV+O/ox8K2LNTP8O tMy4YpyAlvndCvbaxzhd3bySCXSXmqx0ZITcgNBzyXnza4Wnp9//r7MJSKXu+JmPzbP3pU mJVWZTK6hJAkpIi8z6vIzRajLrKkXVkQ8DBr7bJLFOcUtxzC4pCpP8poJ/XadQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1702552661; a=rsa-sha256; cv=none; b=GmqYZ8/xiCRGCfFkaC+lD4Dkd/yKB8AxXT3annfSeyYFx4AhFG1cIylFwBjll2y8tr0N9O RNwEZmM1zZfWWNVoDmHbwBykv9BFf88aag93t0X15N3egdgtCfUqH3O/Wgg9UZBz/E64cA X3VfPCxUjcxItPf5wOwjFoAdB1CLy0UtZ5NZ2TDMPy+h8ylZC+nPG9AvkhPUmzUPaqVxYW 2Ad4z/Lh5QQ5f6bHUULQC5gYhDtdy/wMPVrJ31/WpVHnxFG7PAnWMuPEcn6qrKrA1/xNp1 rx5jIjPYxyfCk6G7S2sTpFsRcfmg5nDOglyn5MZek6OlgNYrgobfr7Xlx/bRlw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1702552661; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=pUoGJuXnWcw7QvGfmrKqtPkxR56OlshzEm13MxTzN1s=; b=Nkjs997uin30wvQTloq9HlgINhlg9FKXSzLVZjtCreyBF6/CUQ9b0o4UwjEjYUQE663WnP VwM7bfZilD7g+bt4BzRrS6diYozWBO28F8VNtg9tBFRM/XmBR+CrqcDxVmzIKk9n+BJMyr H6J0fg5fWa+hVCx45t/gkbOWm2vAMMt1FtwpPyV+xki/Ix+vcpYLBwmkhTsNL33c4rLLZz T4ajtLavr/wC4OcIgILAha6iHgPO+tzOPNlhHcdUJB9ZhN4z/9Tj7enh2SJaQZm7/PMm3n q8t7Gani+SHcA90q1jcHlfni7JNmZb2fQksUczTPRwVUhnBU3WHbAmgzX9oCaA== Received: from [IPV6:2001:1c00:2709:2010:493e:9031:fcc0:f007] (2001-1c00-2709-2010-493e-9031-fcc0-f007.cable.dynamic.v6.ziggo.nl [IPv6:2001:1c00:2709:2010:493e:9031:fcc0:f007]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: ronald/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4SrVFJ5jwvzk3f for ; Thu, 14 Dec 2023 11:17:40 +0000 (UTC) (envelope-from ronald@FreeBSD.org) Message-ID: Date: Thu, 14 Dec 2023 12:17:36 +0100 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: initarm() parsing bootargs? References: <881889965.11901.1702500020716@localhost> Content-Language: en-US To: "freebsd-arm@freebsd.org" From: Ronald Klop In-Reply-To: <881889965.11901.1702500020716@localhost> X-Forwarded-Message-Id: <881889965.11901.1702500020716@localhost> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi, I'm looking into some code but it is really early in the boot path so I find it hard to debug. Do you have some pointers? Booting my RPI it gets a parameter "bootargs" passed. I used this in a driver. See the forwarded email below for the details about this. But in sys/arm64/arm64/machdep_boot.c I found this code. It looks likes it would nicely get and parse this "bootargs" which is called "linux_command_line" here. void parse_fdt_bootargs(void) { if (loader_envp == NULL && fdt_get_chosen_bootargs(linux_command_line, LBABI_MAX_COMMAND_LINE) == 0) { init_static_kenv(static_kenv, sizeof(static_kenv)); cmdline_set_env(linux_command_line, CMDLINE_GUARD); } } But kern_getenv() does not give me any values from this "bootargs" string. I started adding some printf() lines from initarm() up until this method but that is never printed. Is it too early in the boot to print anything? How do others debug these pieces of code? Regards, Ronald. -------- Forwarded Message -------- Subject: Re: git: 3878bbf1bb9e - main - Teach if_smsc to get MAC from bootargs. Date: Wed, 13 Dec 2023 21:40:20 +0100 (CET) From: Ronald Klop To: Emmanuel Vadot CC: Ronald Klop *Van:* Emmanuel Vadot *Datum:* donderdag, 7 december 2023 14:35 *Aan:* Ronald Klop *CC:* src-committers@FreeBSD.org, dev-commits-src-all@FreeBSD.org, dev-commits-src-main@FreeBSD.org *Onderwerp:* Re: git: 3878bbf1bb9e - main - Teach if_smsc to get MAC from bootargs. On Thu, 7 Dec 2023 11:33:05 GMT Ronald Klop wrote: > The branch main has been updated by ronald: > > URL: https://cgit.FreeBSD.org/src/commit/?id=3878bbf1bb9e68f8579b57cde7d4e5c77de93320 > > commit 3878bbf1bb9e68f8579b57cde7d4e5c77de93320 > Author:     Ronald Klop > AuthorDate: 2023-11-04 14:14:00 +0000 > Commit:     Ronald Klop > CommitDate: 2023-12-07 11:32:01 +0000 > >     Teach if_smsc to get MAC from bootargs. > >     Some Raspberry Pi pass smsc95xx.macaddr=XX:XX:XX:XX:XX:XX as bootargs. >     Use this if no ethernet address is found in an EEPROM. >     As last resort fall back to ether_gen_addr() instead of random MAC. > >     PR:     274092 >     Reported by:    Patrick M. Hausen (via ML) >     Reviewed by:    imp, karels, zlei >     Tested by:      Patrick M. Hausen >     Approved by:    karels >     MFC after:      1 month >     Relnotes:       yes >     Differential Revision: https://reviews.freebsd.org/D42463 > --- >  sys/dev/usb/net/if_smsc.c | 86 +++++++++++++++++++++++++++++++++++++++++++++-- >  sys/net/ethernet.h        |  1 + >  sys/net/if_ethersubr.c    | 10 ++++-- >  3 files changed, 92 insertions(+), 5 deletions(-) > > diff --git a/sys/dev/usb/net/if_smsc.c b/sys/dev/usb/net/if_smsc.c > index ec8197229f17..54b18e0a67c9 100644 > --- a/sys/dev/usb/net/if_smsc.c > +++ b/sys/dev/usb/net/if_smsc.c > @@ -179,6 +179,8 @@ static const struct usb_device_id smsc_devs[] = { >  #define ETHER_IS_VALID(addr) \ >   (!ETHER_IS_MULTICAST(addr) && !ETHER_IS_ZERO(addr)) > > +#define BOOTARGS_SMSC95XX    "smsc95xx.macaddr" > + >  static device_probe_t smsc_probe; >  static device_attach_t smsc_attach; >  static device_detach_t smsc_detach; > @@ -1538,6 +1540,76 @@ smsc_ioctl(if_t ifp, u_long cmd, caddr_t data) >   return (rc); >  } > > +#ifdef FDT > +static bool > +smsc_get_smsc95xx_macaddr(char* bootargs, size_t len, struct usb_ether *ue) > +{ > + int values[6]; > + int i; > + char* p; > + > + p = strnstr(bootargs, BOOTARGS_SMSC95XX, len); > + if (p == NULL) > +     return (false); > + > + if (sscanf(p, BOOTARGS_SMSC95XX "=%x:%x:%x:%x:%x:%x%*c", > +         &values[0], &values[1], &values[2], > +         &values[3], &values[4], &values[5]) != 6) { > +     smsc_warn_printf((struct smsc_softc *)ue->ue_sc, > +             "invalid mac from bootargs '%s'.\n", p); > +     return (false); > + } > + > + for (i = 0; i < ETHER_ADDR_LEN; ++i) > +     ue->ue_eaddr[i] = values[i]; > + > + smsc_dbg_printf((struct smsc_softc *)ue->ue_sc, > +         "bootargs mac=%6D.\n", ue->ue_eaddr, ":"); > + return (true); > +} > + > +/** > + * Raspberry Pi is known to pass smsc95xx.macaddr=XX:XX:XX:XX:XX:XX via > + * bootargs. > + */ > +static bool > +smsc_bootargs_get_mac_addr(device_t dev, struct usb_ether *ue) > +{ > + char *bootargs; > + ssize_t len; > + phandle_t node; > + > + /* only use bootargs for the first device > +  * to prevent duplicate mac addresses */ > + if (device_get_unit(dev) != 0) > +     return (false); > + node = OF_finddevice("/chosen"); > + if (node == -1) > +     return (false); > + if (OF_hasprop(node, "bootargs") == 0) { > +     smsc_dbg_printf((struct smsc_softc *)ue->ue_sc, > +             "bootargs not found"); > +     return (false); > + } > + len = OF_getprop_alloc(node, "bootargs", (void **)&bootargs); > + if (len == -1 || bootargs == NULL) { > +     smsc_warn_printf((struct smsc_softc *)ue->ue_sc, > +             "failed alloc for bootargs (%lu)", len); > +     return (false); > + }  All this can be replaced with a call to fdt_get_chosen_bootargs.  Also we already do this for arm and arm64 in machdep_boot.c and store the linux boot args in a static var called linux_command_line, maybe make it not static and get it from this driver.  While you're at it make bcm2835_fbd.c and bcm2835_fb.c use this as they also get and parse the bootargs.  Cheers, [...snip...] -- Emmanuel Vadot Dear Emmanuel, I'm looking into this function fdt_get_chosen_bootargs. Unfortunately it uses static memory allocation which conflicts with another remark I got in the review. But what I do see is that it parses this bootargs string into kern_setenv in sys/kern/subr_boot.c: boot_parse_arg(...). parse_fdt_bootargs (sys/arm64/arm64/machdep_boot.c) -> cmdline_set_env -> boot_parse_cmdline (subr_boot.c) -> boot_parse_cmdline_delim -> boot_parse_arg Would that be usable? I don't see the value in the output of kenv(1) but maybe that is not related. I'll try to come up with a testcase on my RPI to see if this bootargs ends up in kern_getenv in a parsed way. Regards, Ronald. From nobody Thu Dec 14 17:50:34 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 4Srfyw3S5Sz52nYk for ; Thu, 14 Dec 2023 17:50:48 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com [IPv6:2a00:1450:4864:20::635]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Srfyw19yvz3fvH for ; Thu, 14 Dec 2023 17:50:48 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ej1-x635.google.com with SMTP id a640c23a62f3a-a1d93da3eb7so977569166b.0 for ; Thu, 14 Dec 2023 09:50:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1702576245; x=1703181045; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=cq0QnHEhTXt2gUH0KGdNKEWcEwqHRKs+wyUrwNNFthQ=; b=vMq7CNIdr5xjFV/LzJc6gn05A6ZHfk+dsjR43dDci1l3J/8BLJsQ+zh8LO9d96ZznO n+6WPaqoNZvukW+LN2utjbpnvTTVbxwtx8eI9MZqvehtLXslhDTaSyaX8VdJ39nNs3/W Jj0U0ZbeiP3fEcZZvMAKzi5n09i8cCjdrSeXQACb96Li3xzt35ICP49MoPDaFpc9miEg fID//SZEhgBvVEHi1qgmKOC2Hlh2nIS0NJCb/3funKkrr+dHZZu2ndddlMciPBRRoWkx by2wgVj2OgDaPaiGllL+ZB6DR087g+zf1mxGAjukgnFk4F6QsziiMco+lIfnls0xXKXG eeRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702576245; x=1703181045; 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=cq0QnHEhTXt2gUH0KGdNKEWcEwqHRKs+wyUrwNNFthQ=; b=hefC4Cc96qDyueLJu8PjQqZhfKWBdl5FcROQ+DPKD2chl8XGzORx9kuyQJNZCazjlC amJKnpu0tqDvet9y0Zhos7l/69dJYMlc3P5Q7cFr/Wu/xpYg54OIKLhlOmuSaZsYuBq8 M2pwhZR9Awl4sXXyH/gINf5ca+afWnrrEfIeqAYhXk49W2hRfH6KeU9Y6mZ2aHYi2QcS jfCUXff2qtUIuAZFEdT/T8JkpIm4zFvU6QAgea1+IjMaa6UL7IC57TtXLavJI6DvyXnh 0hXzK6WCdS41nITwRacuQzFIs+lV2m8h6buhbB2ZLYsvwvdOgH5ZS50GHdtWJzDTsmip ewLw== X-Gm-Message-State: AOJu0YwWwN65oea0soZSDjoGnX2QM5eD04/+zMN2yToyzVSq4S4zV01y PyZaK7C+Dlh5w4Uv3rVXlbIJpiIF0lendWiHZXYFvQ== X-Google-Smtp-Source: AGHT+IGlrP1MOBsQdNzx0E0mUdzSVg1bBV+1xhT7w1a8iJqwRvyFOItFd/uT+xQK+2TzSZSCT0XmLxYZzD8EC9oNBuU= X-Received: by 2002:a17:906:c281:b0:a1c:7dce:d416 with SMTP id r1-20020a170906c28100b00a1c7dced416mr5041475ejz.124.1702576245321; Thu, 14 Dec 2023 09:50:45 -0800 (PST) List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 References: <881889965.11901.1702500020716@localhost> In-Reply-To: From: Warner Losh Date: Thu, 14 Dec 2023 10:50:34 -0700 Message-ID: Subject: Re: initarm() parsing bootargs? To: Ronald Klop Cc: "freebsd-arm@freebsd.org" Content-Type: multipart/alternative; boundary="0000000000004e41bc060c7bec57" X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4Srfyw19yvz3fvH --0000000000004e41bc060c7bec57 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Dec 14, 2023 at 4:17=E2=80=AFAM Ronald Klop wr= ote: > Hi, > > I'm looking into some code but it is really early in the boot path so I > find it hard to debug. Do you have some pointers? > > Booting my RPI it gets a parameter "bootargs" passed. I used this in a > driver. See the forwarded email below for the details about this. > > But in sys/arm64/arm64/machdep_boot.c I found this code. It looks likes i= t > would nicely get and parse this "bootargs" which is called > "linux_command_line" here. > > void > parse_fdt_bootargs(void) > { > > if (loader_envp =3D=3D NULL && > fdt_get_chosen_bootargs(linux_command_line, > LBABI_MAX_COMMAND_LINE) =3D=3D 0) { > init_static_kenv(static_kenv, sizeof(static_kenv)); > cmdline_set_env(linux_command_line, CMDLINE_GUARD); > } > } > > But kern_getenv() does not give me any values from this "bootargs" string= . > > I started adding some printf() lines from initarm() up until this method > but that is never printed. Is it too early in the boot to print anything? > How do others debug these pieces of code? > You need EARLY_PRINTF defined. And maybe some more stuff as well. For Allwinner, I could tell you how, but I see nothing in the devices that the RPi uses. It most likely needs SOCDEV_PA and SOCDEV_VA assigned correctly. I've never done early arg parsing. But one thing you can do is to verify at runtime that the linux command line is really there in the FDT exported from the kernel. RPi has weird ways to pass stuff into the kernel historically, though I can't recall the details beyond that. Warner > Regards, > Ronald. > > > > > -------- Forwarded Message -------- > Subject: Re: git: 3878bbf1bb9e - main - Teach if_smsc to get MAC > from bootargs. > Date: Wed, 13 Dec 2023 21:40:20 +0100 (CET) > From: Ronald Klop > To: Emmanuel Vadot > CC: Ronald Klop > > > > *Van:* Emmanuel Vadot > *Datum:* donderdag, 7 december 2023 14:35 > *Aan:* Ronald Klop > *CC:* src-committers@FreeBSD.org, dev-commits-src-all@FreeBSD.org, > dev-commits-src-main@FreeBSD.org > *Onderwerp:* Re: git: 3878bbf1bb9e - main - Teach if_smsc to get MAC from > bootargs. > > On Thu, 7 Dec 2023 11:33:05 GMT > Ronald Klop wrote: > > > The branch main has been updated by ronald: > > > > URL: > https://cgit.FreeBSD.org/src/commit/?id=3D3878bbf1bb9e68f8579b57cde7d4e5c= 77de93320 > < > https://cgit.FreeBSD.org/src/commit/?id=3D3878bbf1bb9e68f8579b57cde7d4e5c= 77de93320 > > > > > > commit 3878bbf1bb9e68f8579b57cde7d4e5c77de93320 > > Author: Ronald Klop > > AuthorDate: 2023-11-04 14:14:00 +0000 > > Commit: Ronald Klop > > CommitDate: 2023-12-07 11:32:01 +0000 > > > > Teach if_smsc to get MAC from bootargs. > > > > Some Raspberry Pi pass smsc95xx.macaddr=3DXX:XX:XX:XX:XX:XX a= s > bootargs. > > Use this if no ethernet address is found in an EEPROM. > > As last resort fall back to ether_gen_addr() instead of rando= m > MAC. > > > > PR: 274092 > > Reported by: Patrick M. Hausen (via ML) > > Reviewed by: imp, karels, zlei > > Tested by: Patrick M. Hausen > > Approved by: karels > > MFC after: 1 month > > Relnotes: yes > > Differential Revision: https://reviews.freebsd.org/D42463 < > https://reviews.freebsd.org/D42463> > > --- > > sys/dev/usb/net/if_smsc.c | 86 > +++++++++++++++++++++++++++++++++++++++++++++-- > > sys/net/ethernet.h | 1 + > > sys/net/if_ethersubr.c | 10 ++++-- > > 3 files changed, 92 insertions(+), 5 deletions(-) > > > > diff --git a/sys/dev/usb/net/if_smsc.c b/sys/dev/usb/net/if_smsc.= c > > index ec8197229f17..54b18e0a67c9 100644 > > --- a/sys/dev/usb/net/if_smsc.c > > +++ b/sys/dev/usb/net/if_smsc.c > > @@ -179,6 +179,8 @@ static const struct usb_device_id smsc_devs[] > =3D { > > #define ETHER_IS_VALID(addr) \ > > (!ETHER_IS_MULTICAST(addr) && !ETHER_IS_ZERO(addr)) > > > > +#define BOOTARGS_SMSC95XX "smsc95xx.macaddr" > > + > > static device_probe_t smsc_probe; > > static device_attach_t smsc_attach; > > static device_detach_t smsc_detach; > > @@ -1538,6 +1540,76 @@ smsc_ioctl(if_t ifp, u_long cmd, caddr_t > data) > > return (rc); > > } > > > > +#ifdef FDT > > +static bool > > +smsc_get_smsc95xx_macaddr(char* bootargs, size_t len, struct > usb_ether *ue) > > +{ > > + int values[6]; > > + int i; > > + char* p; > > + > > + p =3D strnstr(bootargs, BOOTARGS_SMSC95XX, len); > > + if (p =3D=3D NULL) > > + return (false); > > + > > + if (sscanf(p, BOOTARGS_SMSC95XX "=3D%x:%x:%x:%x:%x:%x%*c", > > + &values[0], &values[1], &values[2], > > + &values[3], &values[4], &values[5]) !=3D 6) { > > + smsc_warn_printf((struct smsc_softc *)ue->ue_sc, > > + "invalid mac from bootargs '%s'.\n", p); > > + return (false); > > + } > > + > > + for (i =3D 0; i < ETHER_ADDR_LEN; ++i) > > + ue->ue_eaddr[i] =3D values[i]; > > + > > + smsc_dbg_printf((struct smsc_softc *)ue->ue_sc, > > + "bootargs mac=3D%6D.\n", ue->ue_eaddr, ":"); > > + return (true); > > +} > > + > > +/** > > + * Raspberry Pi is known to pass > smsc95xx.macaddr=3DXX:XX:XX:XX:XX:XX via > > + * bootargs. > > + */ > > +static bool > > +smsc_bootargs_get_mac_addr(device_t dev, struct usb_ether *ue) > > +{ > > + char *bootargs; > > + ssize_t len; > > + phandle_t node; > > + > > + /* only use bootargs for the first device > > + * to prevent duplicate mac addresses */ > > + if (device_get_unit(dev) !=3D 0) > > + return (false); > > + node =3D OF_finddevice("/chosen"); > > + if (node =3D=3D -1) > > + return (false); > > + if (OF_hasprop(node, "bootargs") =3D=3D 0) { > > + smsc_dbg_printf((struct smsc_softc *)ue->ue_sc, > > + "bootargs not found"); > > + return (false); > > + } > > + len =3D OF_getprop_alloc(node, "bootargs", (void **)&bootargs); > > + if (len =3D=3D -1 || bootargs =3D=3D NULL) { > > + smsc_warn_printf((struct smsc_softc *)ue->ue_sc, > > + "failed alloc for bootargs (%lu)", len); > > + return (false); > > + } > > All this can be replaced with a call to fdt_get_chosen_bootargs. > Also we already do this for arm and arm64 in machdep_boot.c and > store > the linux boot args in a static var called linux_command_line, maybe > make it not static and get it from this driver. > While you're at it make bcm2835_fbd.c and bcm2835_fb.c use this as > they also get and parse the bootargs. > > Cheers, > > [...snip...] > > -- > Emmanuel Vadot > > > > Dear Emmanuel, > > I'm looking into this function fdt_get_chosen_bootargs. Unfortunately it > uses static memory allocation which conflicts with another remark I got i= n > the review. > > But what I do see is that it parses this bootargs string into kern_setenv > in sys/kern/subr_boot.c: boot_parse_arg(...). > parse_fdt_bootargs (sys/arm64/arm64/machdep_boot.c) -> cmdline_set_env > -> boot_parse_cmdline (subr_boot.c) -> boot_parse_cmdline_delim -> > boot_parse_arg > Would that be usable? > > I don't see the value in the output of kenv(1) but maybe that is not > related. > > I'll try to come up with a testcase on my RPI to see if this bootargs end= s > up in kern_getenv in a parsed way. > > Regards, > Ronald. > > --0000000000004e41bc060c7bec57 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Dec 14, 2023 at 4:17=E2=80=AF= AM Ronald Klop <ronald@freebsd.org= > wrote:
= Hi,

I'm looking into some code but it is really early in the boot path so I= find it hard to debug. Do you have some pointers?

Booting my RPI it gets a parameter "bootargs" passed. I used this= in a driver. See the forwarded email below for the details about this.

But in sys/arm64/arm64/machdep_boot.c I found this code. It looks likes it = would nicely get and parse this "bootargs" which is called "= linux_command_line" here.

void
parse_fdt_bootargs(void)
{

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if (loader_envp =3D=3D NULL && fd= t_get_chosen_bootargs(linux_command_line,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0LBABI_MAX_COMMAND_LINE) =3D= =3D 0) {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0init_static_k= env(static_kenv, sizeof(static_kenv));
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0cmdline_set_e= nv(linux_command_line, CMDLINE_GUARD);
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
}

But kern_getenv() does not give me any values from this "bootargs"= ; string.

I started adding some printf() lines from initarm() up until this method bu= t that is never printed. Is it too early in the boot to print anything?
How do others debug these pieces of code?

You need EARLY_PRINTF defined. And maybe some more stuff as well. For Al= lwinner, I could tell you how, but I see nothing in the devices that the RP= i uses. It most likely needs SOCDEV_PA and SOCDEV_VA assigned correctly. I&= #39;ve never done early arg parsing.

But one thing= you can do is to verify at runtime that the linux command line is really t= here in the FDT exported from the kernel. RPi has weird ways to pass stuff = into the kernel historically, though I can't recall the details beyond = that.

Warner
=C2=A0
Regards,
Ronald.




-------- Forwarded Message --------
Subject:=C2=A0 =C2=A0 =C2=A0 =C2=A0 Re: git: 3878bbf1bb9e - main - Teach if= _smsc to get MAC from bootargs.
Date:=C2=A0 =C2=A0Wed, 13 Dec 2023 21:40:20 +0100 (CET)
From:=C2=A0 =C2=A0Ronald Klop <ronald-lists@klop.ws>
To:=C2=A0 =C2=A0 =C2=A0Emmanuel Vadot <manu@bidouilliste.com>
CC:=C2=A0 =C2=A0 =C2=A0Ronald Klop <ronald@FreeBSD.org>



*Van:* Emmanuel Vadot <manu@bidouilliste.com>
*Datum:* donderdag, 7 december 2023 14:35
*Aan:* Ronald Klop <ronald@FreeBSD.org>
*CC:* src-committers@FreeBSD.org, dev-commits-src-all@FreeBSD.org, dev-comm= its-src-main@FreeBSD.org
*Onderwerp:* Re: git: 3878bbf1bb9e - main - Teach if_smsc to get MAC from b= ootargs.

=C2=A0 =C2=A0 =C2=A0On Thu, 7 Dec 2023 11:33:05 GMT
=C2=A0 =C2=A0 =C2=A0Ronald Klop <ronald@FreeBSD.org> wrote:

=C2=A0 =C2=A0 =C2=A0 > The branch main has been updated by ronald:
=C2=A0 =C2=A0 =C2=A0 >
=C2=A0 =C2=A0 =C2=A0 > URL: https://cgit.FreeBSD.org/src/commit/?id=3D3878bbf1bb9e68f8579b= 57cde7d4e5c77de93320 <https://cgit.FreeBSD.org/src/commit/?id=3D3878bbf1bb9e68f8579b5= 7cde7d4e5c77de93320>
=C2=A0 =C2=A0 =C2=A0 >
=C2=A0 =C2=A0 =C2=A0 > commit 3878bbf1bb9e68f8579b57cde7d4e5c77de93320 =C2=A0 =C2=A0 =C2=A0 > Author: =C2=A0=C2=A0=C2=A0=C2=A0Ronald Klop <r= onald@FreeBSD.org>
=C2=A0 =C2=A0 =C2=A0 > AuthorDate: 2023-11-04 14:14:00 +0000
=C2=A0 =C2=A0 =C2=A0 > Commit: =C2=A0=C2=A0=C2=A0=C2=A0Ronald Klop <r= onald@FreeBSD.org>
=C2=A0 =C2=A0 =C2=A0 > CommitDate: 2023-12-07 11:32:01 +0000
=C2=A0 =C2=A0 =C2=A0 >
=C2=A0 =C2=A0 =C2=A0 > =C2=A0=C2=A0=C2=A0=C2=A0Teach if_smsc to get MAC = from bootargs.
=C2=A0 =C2=A0 =C2=A0 >
=C2=A0 =C2=A0 =C2=A0 > =C2=A0=C2=A0=C2=A0=C2=A0Some Raspberry Pi pass sm= sc95xx.macaddr=3DXX:XX:XX:XX:XX:XX as bootargs.
=C2=A0 =C2=A0 =C2=A0 > =C2=A0=C2=A0=C2=A0=C2=A0Use this if no ethernet a= ddress is found in an EEPROM.
=C2=A0 =C2=A0 =C2=A0 > =C2=A0=C2=A0=C2=A0=C2=A0As last resort fall back = to ether_gen_addr() instead of random MAC.
=C2=A0 =C2=A0 =C2=A0 >
=C2=A0 =C2=A0 =C2=A0 > =C2=A0=C2=A0=C2=A0=C2=A0PR: =C2=A0=C2=A0=C2=A0=C2= =A0274092
=C2=A0 =C2=A0 =C2=A0 > =C2=A0=C2=A0=C2=A0=C2=A0Reported by: =C2=A0=C2=A0= =C2=A0Patrick M. Hausen (via ML)
=C2=A0 =C2=A0 =C2=A0 > =C2=A0=C2=A0=C2=A0=C2=A0Reviewed by: =C2=A0=C2=A0= =C2=A0imp, karels, zlei
=C2=A0 =C2=A0 =C2=A0 > =C2=A0=C2=A0=C2=A0=C2=A0Tested by: =C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0Patrick M. Hausen
=C2=A0 =C2=A0 =C2=A0 > =C2=A0=C2=A0=C2=A0=C2=A0Approved by: =C2=A0=C2=A0= =C2=A0karels
=C2=A0 =C2=A0 =C2=A0 > =C2=A0=C2=A0=C2=A0=C2=A0MFC after: =C2=A0=C2=A0= =C2=A0=C2=A0=C2=A01 month
=C2=A0 =C2=A0 =C2=A0 > =C2=A0=C2=A0=C2=A0=C2=A0Relnotes: =C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0yes
=C2=A0 =C2=A0 =C2=A0 > =C2=A0=C2=A0=C2=A0=C2=A0Differential Revision: https://reviews.freebsd.org/D42463 <https://reviews.= freebsd.org/D42463>
=C2=A0 =C2=A0 =C2=A0 > ---
=C2=A0 =C2=A0 =C2=A0 > =C2=A0sys/dev/usb/net/if_smsc.c | 86 ++++++++++++= +++++++++++++++++++++++++++++++++--
=C2=A0 =C2=A0 =C2=A0 > =C2=A0sys/net/ethernet.h =C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0| =C2=A01 +
=C2=A0 =C2=A0 =C2=A0 > =C2=A0sys/net/if_ethersubr.c =C2=A0=C2=A0=C2=A0| = 10 ++++--
=C2=A0 =C2=A0 =C2=A0 > =C2=A03 files changed, 92 insertions(+), 5 deleti= ons(-)
=C2=A0 =C2=A0 =C2=A0 >
=C2=A0 =C2=A0 =C2=A0 > diff --git a/sys/dev/usb/net/if_smsc.c b/sys/dev/= usb/net/if_smsc.c
=C2=A0 =C2=A0 =C2=A0 > index ec8197229f17..54b18e0a67c9 100644
=C2=A0 =C2=A0 =C2=A0 > --- a/sys/dev/usb/net/if_smsc.c
=C2=A0 =C2=A0 =C2=A0 > +++ b/sys/dev/usb/net/if_smsc.c
=C2=A0 =C2=A0 =C2=A0 > @@ -179,6 +179,8 @@ static const struct usb_devic= e_id smsc_devs[] =3D {
=C2=A0 =C2=A0 =C2=A0 > =C2=A0#define ETHER_IS_VALID(addr) \
=C2=A0 =C2=A0 =C2=A0 > =C2=A0=C2=A0(!ETHER_IS_MULTICAST(addr) &&= !ETHER_IS_ZERO(addr))
=C2=A0 =C2=A0 =C2=A0 >
=C2=A0 =C2=A0 =C2=A0 > +#define BOOTARGS_SMSC95XX =C2=A0=C2=A0=C2=A0&quo= t;smsc95xx.macaddr"
=C2=A0 =C2=A0 =C2=A0 > +
=C2=A0 =C2=A0 =C2=A0 > =C2=A0static device_probe_t smsc_probe;
=C2=A0 =C2=A0 =C2=A0 > =C2=A0static device_attach_t smsc_attach;
=C2=A0 =C2=A0 =C2=A0 > =C2=A0static device_detach_t smsc_detach;
=C2=A0 =C2=A0 =C2=A0 > @@ -1538,6 +1540,76 @@ smsc_ioctl(if_t ifp, u_lon= g cmd, caddr_t data)
=C2=A0 =C2=A0 =C2=A0 > =C2=A0=C2=A0return (rc);
=C2=A0 =C2=A0 =C2=A0 > =C2=A0}
=C2=A0 =C2=A0 =C2=A0 >
=C2=A0 =C2=A0 =C2=A0 > +#ifdef FDT
=C2=A0 =C2=A0 =C2=A0 > +static bool
=C2=A0 =C2=A0 =C2=A0 > +smsc_get_smsc95xx_macaddr(char* bootargs, size_t= len, struct usb_ether *ue)
=C2=A0 =C2=A0 =C2=A0 > +{
=C2=A0 =C2=A0 =C2=A0 > + int values[6];
=C2=A0 =C2=A0 =C2=A0 > + int i;
=C2=A0 =C2=A0 =C2=A0 > + char* p;
=C2=A0 =C2=A0 =C2=A0 > +
=C2=A0 =C2=A0 =C2=A0 > + p =3D strnstr(bootargs, BOOTARGS_SMSC95XX, len)= ;
=C2=A0 =C2=A0 =C2=A0 > + if (p =3D=3D NULL)
=C2=A0 =C2=A0 =C2=A0 > + =C2=A0=C2=A0=C2=A0=C2=A0return (false);
=C2=A0 =C2=A0 =C2=A0 > +
=C2=A0 =C2=A0 =C2=A0 > + if (sscanf(p, BOOTARGS_SMSC95XX "=3D%x:%x:= %x:%x:%x:%x%*c",
=C2=A0 =C2=A0 =C2=A0 > + =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0&values[0], &values[1], &values[2],
=C2=A0 =C2=A0 =C2=A0 > + =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0&values[3], &values[4], &values[5]) !=3D 6) {
=C2=A0 =C2=A0 =C2=A0 > + =C2=A0=C2=A0=C2=A0=C2=A0smsc_warn_printf((struc= t smsc_softc *)ue->ue_sc,
=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"invalid mac from bootargs '%s'.\n&= quot;, p);
=C2=A0 =C2=A0 =C2=A0 > + =C2=A0=C2=A0=C2=A0=C2=A0return (false);
=C2=A0 =C2=A0 =C2=A0 > + }
=C2=A0 =C2=A0 =C2=A0 > +
=C2=A0 =C2=A0 =C2=A0 > + for (i =3D 0; i < ETHER_ADDR_LEN; ++i)
=C2=A0 =C2=A0 =C2=A0 > + =C2=A0=C2=A0=C2=A0=C2=A0ue->ue_eaddr[i] =3D = values[i];
=C2=A0 =C2=A0 =C2=A0 > +
=C2=A0 =C2=A0 =C2=A0 > + smsc_dbg_printf((struct smsc_softc *)ue->ue_= sc,
=C2=A0 =C2=A0 =C2=A0 > + =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0"bootargs mac=3D%6D.\n", ue->ue_eaddr, ":");
=C2=A0 =C2=A0 =C2=A0 > + return (true);
=C2=A0 =C2=A0 =C2=A0 > +}
=C2=A0 =C2=A0 =C2=A0 > +
=C2=A0 =C2=A0 =C2=A0 > +/**
=C2=A0 =C2=A0 =C2=A0 > + * Raspberry Pi is known to pass smsc95xx.macadd= r=3DXX:XX:XX:XX:XX:XX via
=C2=A0 =C2=A0 =C2=A0 > + * bootargs.
=C2=A0 =C2=A0 =C2=A0 > + */
=C2=A0 =C2=A0 =C2=A0 > +static bool
=C2=A0 =C2=A0 =C2=A0 > +smsc_bootargs_get_mac_addr(device_t dev, struct = usb_ether *ue)
=C2=A0 =C2=A0 =C2=A0 > +{
=C2=A0 =C2=A0 =C2=A0 > + char *bootargs;
=C2=A0 =C2=A0 =C2=A0 > + ssize_t len;
=C2=A0 =C2=A0 =C2=A0 > + phandle_t node;
=C2=A0 =C2=A0 =C2=A0 > +
=C2=A0 =C2=A0 =C2=A0 > + /* only use bootargs for the first device
=C2=A0 =C2=A0 =C2=A0 > + =C2=A0* to prevent duplicate mac addresses */ =C2=A0 =C2=A0 =C2=A0 > + if (device_get_unit(dev) !=3D 0)
=C2=A0 =C2=A0 =C2=A0 > + =C2=A0=C2=A0=C2=A0=C2=A0return (false);
=C2=A0 =C2=A0 =C2=A0 > + node =3D OF_finddevice("/chosen"); =C2=A0 =C2=A0 =C2=A0 > + if (node =3D=3D -1)
=C2=A0 =C2=A0 =C2=A0 > + =C2=A0=C2=A0=C2=A0=C2=A0return (false);
=C2=A0 =C2=A0 =C2=A0 > + if (OF_hasprop(node, "bootargs") =3D= =3D 0) {
=C2=A0 =C2=A0 =C2=A0 > + =C2=A0=C2=A0=C2=A0=C2=A0smsc_dbg_printf((struct= smsc_softc *)ue->ue_sc,
=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"bootargs not found");
=C2=A0 =C2=A0 =C2=A0 > + =C2=A0=C2=A0=C2=A0=C2=A0return (false);
=C2=A0 =C2=A0 =C2=A0 > + }
=C2=A0 =C2=A0 =C2=A0 > + len =3D OF_getprop_alloc(node, "bootargs&q= uot;, (void **)&bootargs);
=C2=A0 =C2=A0 =C2=A0 > + if (len =3D=3D -1 || bootargs =3D=3D NULL) { =C2=A0 =C2=A0 =C2=A0 > + =C2=A0=C2=A0=C2=A0=C2=A0smsc_warn_printf((struc= t smsc_softc *)ue->ue_sc,
=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"failed alloc for bootargs (%lu)", len= );
=C2=A0 =C2=A0 =C2=A0 > + =C2=A0=C2=A0=C2=A0=C2=A0return (false);
=C2=A0 =C2=A0 =C2=A0 > + }

=C2=A0 =C2=A0 =C2=A0 =C2=A0All this can be replaced with a call to fdt_get_= chosen_bootargs.
=C2=A0 =C2=A0 =C2=A0 =C2=A0Also we already do this for arm and arm64 in mac= hdep_boot.c and store
=C2=A0 =C2=A0 =C2=A0the linux boot args in a static var called linux_comman= d_line, maybe
=C2=A0 =C2=A0 =C2=A0make it not static and get it from this driver.
=C2=A0 =C2=A0 =C2=A0 =C2=A0While you're at it make bcm2835_fbd.c and bc= m2835_fb.c use this as
=C2=A0 =C2=A0 =C2=A0they also get and parse the bootargs.

=C2=A0 =C2=A0 =C2=A0 =C2=A0Cheers,

=C2=A0 =C2=A0 =C2=A0[...snip...]

=C2=A0 =C2=A0 =C2=A0--
=C2=A0 =C2=A0 =C2=A0Emmanuel Vadot <manu@bidouilliste.com> <manu@freebsd.org>



Dear Emmanuel,

I'm looking into this function fdt_get_chosen_bootargs. Unfortunately i= t uses static memory allocation which conflicts with another remark I got i= n the review.

But what I do see is that it parses this bootargs string into kern_setenv i= n sys/kern/subr_boot.c: boot_parse_arg(...).
parse_fdt_bootargs (sys/arm64/arm64/machdep_boot.c) ->=C2=A0cmdline_set_= env ->=C2=A0boot_parse_cmdline (subr_boot.c) -> boot_parse_cmdline_de= lim -> boot_parse_arg
Would that be usable?

I don't see the value in the output of kenv(1) but maybe that is not re= lated.

I'll try to come up with a testcase on my RPI to see if this bootargs e= nds up in kern_getenv in a parsed way.

Regards,
Ronald.

--0000000000004e41bc060c7bec57-- From nobody Thu Dec 14 19:05: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 4SrhdC1Wqqz53ckw for ; Thu, 14 Dec 2023 19:05:35 +0000 (UTC) (envelope-from mhorne@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 4SrhdC0shhz4K0L; Thu, 14 Dec 2023 19:05:35 +0000 (UTC) (envelope-from mhorne@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1702580735; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=Ew0pfUvPCQvB84U04+QXesUvsJftDeU5uC5CXn07K1M=; b=pUQYIkXfUK04TMvLfzZMsdaIixxVypf2EirTJK4ykNeGDT2ZEPKChJZAGlMnygLR1UOuVI dwnBrNxUQK8O9CsMa5PRthvcGxKppqVVLmQZt9aadFznrCfMuUVWlCIht/6USS1W9pr07d ZFWGRYr/NJFegpXOKhYrzTfAQUwQYb8G17JEQKpW6YxkmDULLSIdNPyMP5N8UsodthVMbN W3oW+dV0kDV2m7bSNa2LODjWvUOl4ZIPfr4DacFAg/WL0IQj8PHXU+ydMZgTT5Go9X+tHu RYfnl1lPmpEDe7o2G2WUq4SsZyKzF0R2ykNIBFP9mVsT4Sj/mQj+WhDpZIIUgw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1702580735; a=rsa-sha256; cv=none; b=W2WSs24hm28ugt3cq+UIZj0N1Oj+luxhxjnR5FwMT/siXB/vLgXETSKhSmvU2jrQXb00hM 942ctwvIrE2I/PwGtFp6VwsnsaDuxcHZFCfu/UUB8EV75MrRhdVlz7QbgbVxYcQS6jmSry XRzfZKZpHxelROEiyDcy/LZ6Yy4gyRemqzjgRL/BZFiMqg/pefIsSdm0dDlPO6cl70+G/o gC+FnPOZQgOuWbD+iaANttZr5NYLbZl1KfpPIhB8Nq93N4u9o5hpJ5p8jx0yg9sdMymqew 2sCX89VQa1XWxRKe2KbY744boeNaLJQCyHqPHEdZUzvLtFXqfCLTnH65pvPW3Q== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1702580735; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=Ew0pfUvPCQvB84U04+QXesUvsJftDeU5uC5CXn07K1M=; b=uP1CDq5QKI7LTyXZwrNv506UzWJ3xMKjKLR+PRtOh1iLfmVvv4BK/PzqoJWB13UsClh4xy ji9ca+g2NXB8REN/BZSxtqypj0lfEvlOWKYSaDEfqbgcjCKicjqO80+vyXV7MJOMQ5fqcV 6nuImuCAXxfxOs0dbFJPNljYnEaFKW0SRDfE+FwvPUrT3Z9HtzlPx9yW9y4mfKnQnubV7E 8GJkETpjLU3g2cIDY+SU3p/Ign6q6nuairS/T9ExNzb5UZDk9YGYEo9hRFNsyJ7Pzjff3o TKRSoHg+LNfA3lwrufvR5dpqYykPxuTPMFBbF5rGB9OK6reZJeSC+/TyefX3dg== Received: from [192.168.1.151] (host-173-212-76-127.public.eastlink.ca [173.212.76.127]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: mhorne) by smtp.freebsd.org (Postfix) with ESMTPSA id 4SrhdB5pSqzsHZ; Thu, 14 Dec 2023 19:05:34 +0000 (UTC) (envelope-from mhorne@freebsd.org) Message-ID: <7853cbc5-6853-4caf-9174-6627126bc93d@freebsd.org> Date: Thu, 14 Dec 2023 15:05:33 -0400 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: initarm() parsing bootargs? Content-Language: en-CA To: Ronald Klop , "freebsd-arm@freebsd.org" References: <881889965.11901.1702500020716@localhost> From: Mitchell Horne Autocrypt: addr=mhorne@freebsd.org; keydata= xsBNBFyS2dQBCADdiXBG8hBVLmYbxu7aSzbwLwUf3HkGFz3rooS1kwyy+SfmjZ4UKNnl9WMx WKrJ7OAZpiNH6bLQ5nsqfx09OnpWL8c/QuPbhNdUywQoqqYpRI0K8GEn//nS9Gs0KTYwVpWb XlrzP+jf3Uh/9L5mcQmStLIH4zaaqMYHW+pMuPrvBmLIHTvLj2QjOkxslrcUdord9uvxe5Ht LU8RuTpQpHOKz705Z9/v7twFdi2HtKzpLwO6SzVyu351di1J+GihsVpcT5josQV5cHbIP3Un x+kmtKBEEc/jl/zBglF7ruWUtwgbryID+2ZPEaO1Mj+RResX4LFVMusq3uUpWRb5WJXxABEB AAHNI01pdGNoZWxsIEhvcm5lIDxtaG9ybmVARnJlZUJTRC5vcmc+wsCUBBMBCgA+AhsDBQsJ CAcCBhUKCQgLAgQWAgMBAh4BAheAFiEEkp/cYPcfabAiQvACi/gnTOdUid8FAmIyDpUFCQtC z0EACgkQi/gnTOdUid8IsQf+N8IptrrCgifT5Z0/WUVFfnHThFOKf4zBjaGswsIM8+VKsKnF 15jCWHODUHP6s+dcQ4nQi81PHPsnMfBSkGPvN/X3ess2/1KUVkH+6tAJbqXDjXhD8HT+i0NM QEFIXlLnotpgIKW3yOHjKv3ZvKw9LCvUjyNY9vOJmLk/6AbbkFh+INo65nXtQWb/hM5FVEHW S+zUoU8AqZRJoVAQfj9wmIfg/HdsxeDGKL0zkv5AwKpccvb8VJNGJbCVMgoy5uQYcUeXxcie cg0VlbFLshNQTfyhVQ85vyuHahARrUWs/k8KiYODoBnW1ChtyF8yM6VZTzSYx7pINqPq2YZy i/Htd87ATQRcktnUAQgA3zt4M4ecoQqfxpjliNLujt9klDqvmkJvWmzMuMXdzlPgGRJ0doio 9YIeEdkOt6xN0pPTK/ReCZ8WqFQ8zo23u1pwGuo0CnR58XF19wyxyUuKu/PHbt+56mC8tNHm AXsMyXQmlDqWvn/WzLY7euNRtNS4QQIwtxfM5EC4GGa5KQwxn0kM7dkUSOE/cxr+/kNbHHzb gagZR4cnNUqtPPr3dYXcibCTzgz96Lyt3/qMLXX9RTBRzu+O6E+byxWOe8ar/ZlwY2b4wTQG mhgNttkSxKtxMpZnd8+DGV/bI1P5Ct/K2GeCwNyupQGON5ymn6o7jTch+qmFX0ItkBWO4zn4 9QARAQABwsB8BBgBCgAmAhsMFiEEkp/cYPcfabAiQvACi/gnTOdUid8FAmIyDtwFCQtCz4gA CgkQi/gnTOdUid/i5gf/aQ75pJR4TJFM2vVVr6PDIwTdl0b5EchB4w4s4g/zE84XNbMOQanb BginLYEhAacLQVAvM3XdvUEhwrhaMQdjdSEB1krResL3/mbxrtKwdHSMbHA3IS3XdvxFWTB7 P5JjUSPsW6hqgoidbn4w3OxaNHhs45H2b0Nx5QiKcSyepmCZuB52gCEHnEnrdaz8TFQMXOLq 94WbTmZeIjChW3FB61m1gTf0UEFjoZAfTAUB+pbwoCa4AykIeZnDC19vjsruVU9Gy5rLglwd bjsZNfXIJGOZNEvdF8FOBwM7DlXx7SYvTJcUNoNJjOKtQ0bYGVgGqYOB/y2mTjVuKeU0eOkN Uw== In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 12/14/23 07:17, Ronald Klop wrote: > Hi, > > I'm looking into some code but it is really early in the boot path so I > find it hard to debug. Do you have some pointers? > > Booting my RPI it gets a parameter "bootargs" passed. I used this in a > driver. See the forwarded email below for the details about this. > > But in sys/arm64/arm64/machdep_boot.c I found this code. It looks likes > it would nicely get and parse this "bootargs" which is called > "linux_command_line" here. > > void > parse_fdt_bootargs(void) > { > >         if (loader_envp == NULL && > fdt_get_chosen_bootargs(linux_command_line, >             LBABI_MAX_COMMAND_LINE) == 0) { >                 init_static_kenv(static_kenv, sizeof(static_kenv)); >                 cmdline_set_env(linux_command_line, CMDLINE_GUARD); >         } > } > > But kern_getenv() does not give me any values from this "bootargs" string. > > I started adding some printf() lines from initarm() up until this method > but that is never printed. Is it too early in the boot to print anything? Yes, it is too early. In general, the console is not available until after cn_init() is called by initarm(). In the 'typical' boot case, the kernel environment is inherited from loader(8), this is done in freebsd_parse_boot_param(), and note that it sets loader_envp. This parse_fdt_bootargs() functionality was added to support the "LinuxABI" boot scheme, where the kernel is loaded and executed directly by u-boot (no loader(8)). So on arm64, parsing bootargs is skipped "by default" (loader(8) case). I think you could experiment by removing the "loader_envp == NULL" part of the conditional. What I am unsure about is if a second call to init_static_kenv() will properly append to the existing environment, or squash it. > How do others debug these pieces of code? > Mostly I try to avoid it, but it is not always possible :) When you can't easily use EARLY_PRINTF, I have resorted to running in QEMU and attaching the debugger to its GDB stub. This allows you to set breakpoints and step through code of interest before the console is available. I did not really check it, but there is some info here: https://www.qemu.org/docs/master/system/gdb.html Cheers, Mitchell > Regards, > Ronald. > > > > > -------- Forwarded Message -------- > Subject:     Re: git: 3878bbf1bb9e - main - Teach if_smsc to get MAC > from bootargs. > Date:     Wed, 13 Dec 2023 21:40:20 +0100 (CET) > From:     Ronald Klop > To:     Emmanuel Vadot > CC:     Ronald Klop > > > > *Van:* Emmanuel Vadot > *Datum:* donderdag, 7 december 2023 14:35 > *Aan:* Ronald Klop > *CC:* src-committers@FreeBSD.org, dev-commits-src-all@FreeBSD.org, > dev-commits-src-main@FreeBSD.org > *Onderwerp:* Re: git: 3878bbf1bb9e - main - Teach if_smsc to get MAC > from bootargs. > >     On Thu, 7 Dec 2023 11:33:05 GMT >     Ronald Klop wrote: > >      > The branch main has been updated by ronald: >      > >      > URL: > https://cgit.FreeBSD.org/src/commit/?id=3878bbf1bb9e68f8579b57cde7d4e5c77de93320 >      > >      > commit 3878bbf1bb9e68f8579b57cde7d4e5c77de93320 >      > Author:     Ronald Klop >      > AuthorDate: 2023-11-04 14:14:00 +0000 >      > Commit:     Ronald Klop >      > CommitDate: 2023-12-07 11:32:01 +0000 >      > >      >     Teach if_smsc to get MAC from bootargs. >      > >      >     Some Raspberry Pi pass smsc95xx.macaddr=XX:XX:XX:XX:XX:XX as > bootargs. >      >     Use this if no ethernet address is found in an EEPROM. >      >     As last resort fall back to ether_gen_addr() instead of > random MAC. >      > >      >     PR:     274092 >      >     Reported by:    Patrick M. Hausen (via ML) >      >     Reviewed by:    imp, karels, zlei >      >     Tested by:      Patrick M. Hausen >      >     Approved by:    karels >      >     MFC after:      1 month >      >     Relnotes:       yes >      >     Differential Revision: https://reviews.freebsd.org/D42463 > >      > --- >      >  sys/dev/usb/net/if_smsc.c | 86 > +++++++++++++++++++++++++++++++++++++++++++++-- >      >  sys/net/ethernet.h        |  1 + >      >  sys/net/if_ethersubr.c    | 10 ++++-- >      >  3 files changed, 92 insertions(+), 5 deletions(-) >      > >      > diff --git a/sys/dev/usb/net/if_smsc.c b/sys/dev/usb/net/if_smsc.c >      > index ec8197229f17..54b18e0a67c9 100644 >      > --- a/sys/dev/usb/net/if_smsc.c >      > +++ b/sys/dev/usb/net/if_smsc.c >      > @@ -179,6 +179,8 @@ static const struct usb_device_id > smsc_devs[] = { >      >  #define ETHER_IS_VALID(addr) \ >      >   (!ETHER_IS_MULTICAST(addr) && !ETHER_IS_ZERO(addr)) >      > >      > +#define BOOTARGS_SMSC95XX    "smsc95xx.macaddr" >      > + >      >  static device_probe_t smsc_probe; >      >  static device_attach_t smsc_attach; >      >  static device_detach_t smsc_detach; >      > @@ -1538,6 +1540,76 @@ smsc_ioctl(if_t ifp, u_long cmd, caddr_t > data) >      >   return (rc); >      >  } >      > >      > +#ifdef FDT >      > +static bool >      > +smsc_get_smsc95xx_macaddr(char* bootargs, size_t len, struct > usb_ether *ue) >      > +{ >      > + int values[6]; >      > + int i; >      > + char* p; >      > + >      > + p = strnstr(bootargs, BOOTARGS_SMSC95XX, len); >      > + if (p == NULL) >      > +     return (false); >      > + >      > + if (sscanf(p, BOOTARGS_SMSC95XX "=%x:%x:%x:%x:%x:%x%*c", >      > +         &values[0], &values[1], &values[2], >      > +         &values[3], &values[4], &values[5]) != 6) { >      > +     smsc_warn_printf((struct smsc_softc *)ue->ue_sc, >      > +             "invalid mac from bootargs '%s'.\n", p); >      > +     return (false); >      > + } >      > + >      > + for (i = 0; i < ETHER_ADDR_LEN; ++i) >      > +     ue->ue_eaddr[i] = values[i]; >      > + >      > + smsc_dbg_printf((struct smsc_softc *)ue->ue_sc, >      > +         "bootargs mac=%6D.\n", ue->ue_eaddr, ":"); >      > + return (true); >      > +} >      > + >      > +/** >      > + * Raspberry Pi is known to pass > smsc95xx.macaddr=XX:XX:XX:XX:XX:XX via >      > + * bootargs. >      > + */ >      > +static bool >      > +smsc_bootargs_get_mac_addr(device_t dev, struct usb_ether *ue) >      > +{ >      > + char *bootargs; >      > + ssize_t len; >      > + phandle_t node; >      > + >      > + /* only use bootargs for the first device >      > +  * to prevent duplicate mac addresses */ >      > + if (device_get_unit(dev) != 0) >      > +     return (false); >      > + node = OF_finddevice("/chosen"); >      > + if (node == -1) >      > +     return (false); >      > + if (OF_hasprop(node, "bootargs") == 0) { >      > +     smsc_dbg_printf((struct smsc_softc *)ue->ue_sc, >      > +             "bootargs not found"); >      > +     return (false); >      > + } >      > + len = OF_getprop_alloc(node, "bootargs", (void **)&bootargs); >      > + if (len == -1 || bootargs == NULL) { >      > +     smsc_warn_printf((struct smsc_softc *)ue->ue_sc, >      > +             "failed alloc for bootargs (%lu)", len); >      > +     return (false); >      > + } > >       All this can be replaced with a call to fdt_get_chosen_bootargs. >       Also we already do this for arm and arm64 in machdep_boot.c and > store >     the linux boot args in a static var called linux_command_line, maybe >     make it not static and get it from this driver. >       While you're at it make bcm2835_fbd.c and bcm2835_fb.c use this as >     they also get and parse the bootargs. > >       Cheers, > >     [...snip...] > >     -- >     Emmanuel Vadot > > > > Dear Emmanuel, > > I'm looking into this function fdt_get_chosen_bootargs. Unfortunately it > uses static memory allocation which conflicts with another remark I got > in the review. > > But what I do see is that it parses this bootargs string into > kern_setenv in sys/kern/subr_boot.c: boot_parse_arg(...). > parse_fdt_bootargs (sys/arm64/arm64/machdep_boot.c) -> cmdline_set_env > -> boot_parse_cmdline (subr_boot.c) -> boot_parse_cmdline_delim -> > boot_parse_arg > Would that be usable? > > I don't see the value in the output of kenv(1) but maybe that is not > related. > > I'll try to come up with a testcase on my RPI to see if this bootargs > ends up in kern_getenv in a parsed way. > > Regards, > Ronald. > From nobody Fri Dec 15 11:06: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 4Ss5xM45bdz52fFt for ; Fri, 15 Dec 2023 11:05:59 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (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 4Ss5xL5Vywz3Vx4 for ; Fri, 15 Dec 2023 11:05:58 +0000 (UTC) (envelope-from freebsd@omnilan.de) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of freebsd@omnilan.de designates 2a00:e10:2800::a130 as permitted sender) smtp.mailfrom=freebsd@omnilan.de; dmarc=none Received: from mh0.gentlemail.de (mh0.gentlemail.de [IPv6:2a00:e10:2800:0:0:0:0:a135]) by mx0.gentlemail.de (8.15.2/8.15.2) with ESMTP id 3BFB5l9Y016115; Fri, 15 Dec 2023 12:05:48 +0100 (CET) (envelope-from freebsd@omnilan.de) Received: from [10.100.100.61] (unknown [217.110.88.38]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id D9119A9A; Fri, 15 Dec 2023 12:05:47 +0100 (CET) Message-ID: <5211ad65-5289-4776-b839-7c681de77bf4@omnilan.de> Date: Fri, 15 Dec 2023 12:06:02 +0100 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: u-boot-nanopi-r5c [Was: Re: 14-BETA5 panic on rk3566] Content-Language: en-US To: Emmanuel Vadot Cc: freebsd-arm References: <2CE509A2-AECF-4562-A080-589AC7888F21@edc.ro> <20231012184430.952dd9d5a26c97ee225c9e77@bidouilliste.com> From: Harry In-Reply-To: <20231012184430.952dd9d5a26c97ee225c9e77@bidouilliste.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spamd-Result: default: False [-3.29 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; XM_UA_NO_VERSION(0.01)[]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:61157, ipnet:2a00:e10:2800::/38, country:DE]; RCPT_COUNT_TWO(0.00)[2]; TO_DN_ALL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; DMARC_NA(0.00)[omnilan.de]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Queue-Id: 4Ss5xL5Vywz3Vx4 X-Spamd-Bar: --- On 10/12/23 18:44, Emmanuel Vadot wrote: >> can this be merged to 14-STABLE >> /sys/dev/iicbus/pmic/rockchip/rk8xx_clocks.c >> this seems to cause a panic >> clkidef.name = (nclks = 2) ? clknames[0] : "clk32kout1"; >> > It's a bit too late tbh, also I don't consider rk356x stable even in > 15-CURRENT, so this will be merged in stable/14 at some point but for > now if you want to run on rk356x please use 15-CURRENT. Hi Emmanuel, thanks for your great FreeBSD contributions! Highly appreciate the Porting-FreeBSD-to-a-new-ARM-Board publication too! Quick question - I'm new to arm/u-boot, but some FreeBSD src & ports experience here... In u-boot-2023.10 there's (master/)configs/nanopi-r5c-rk3568_defconfig added. Simply copy'n'paste the ports/sysutils/u-boot-nanopi-r4s to u-boot-nanopi-r5c isn't enough... (after updating u-boot-master from 2023.07 to 2023.10, done that) I don't understand sysutils/atf-master resp. sysutils/atf-rk3399. Simply creating new rk3568 slave ports doesn't work since PLAT rk3568 isn't implemenmted upstream...  I guess I would have to adjust sysutils/u-boot-nanopi-r5c to get rid of the AT-F dependency first... but You mention running 15-CURRENT on rk356x How to boot? Would highly appreciate links - I'm currently trying to deploy FriendlyELEC R5C here - I could successfully start 14-stable, but just by try'n'error metgod, gluing lots of different loader blobs onto SDcard.  I need to learn a lot, so I'm trying to do it a little bit smarter than try'n'error... Thanks in advance, -harry From nobody Fri Dec 15 15:56:40 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 4SsDP15fglz53kH3 for ; Fri, 15 Dec 2023 15:56:53 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mx.blih.net (mx.blih.net [212.83.155.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4SsDP12Jccz4WFD for ; Fri, 15 Dec 2023 15:56:53 +0000 (UTC) (envelope-from manu@bidouilliste.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bidouilliste.com; s=mx; t=1702655803; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Y8e/SSf08v3NnGXpoGq42awpYg0YhPyMf6DtyCZswV8=; b=KLfUwpUAO/mTwlih27gmqXTwyUniZWC5WPvO7ZcbbShQBHytvRaa1JJR6thhbUku1wn/x6 0KQ5LLYnUSSWrE3e7hd9zQasbHe58/7WicOyhADmRor/YDy9VZhGey5aESBW4pJOvGtz53 fUS4fa7c52TVYlqRb7YhfLnob1Dd4Y4= Received: from skull.home.blih.net (lfbn-lyo-1-2174-135.w90-66.abo.wanadoo.fr [90.66.97.135]) by mx.blih.net (OpenSMTPD) with ESMTPSA id 9c2634be (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Fri, 15 Dec 2023 15:56:43 +0000 (UTC) Date: Fri, 15 Dec 2023 16:56:40 +0100 From: Emmanuel Vadot To: Harry Cc: freebsd-arm Subject: Re: u-boot-nanopi-r5c [Was: Re: 14-BETA5 panic on rk3566] Message-Id: <20231215165640.78bab647c883368b8fc9c34e@bidouilliste.com> In-Reply-To: <5211ad65-5289-4776-b839-7c681de77bf4@omnilan.de> References: <2CE509A2-AECF-4562-A080-589AC7888F21@edc.ro> <20231012184430.952dd9d5a26c97ee225c9e77@bidouilliste.com> <5211ad65-5289-4776-b839-7c681de77bf4@omnilan.de> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd15.0) List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:12876, ipnet:212.83.128.0/19, country:FR] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4SsDP12Jccz4WFD Hi, On Fri, 15 Dec 2023 12:06:02 +0100 Harry wrote: > On 10/12/23 18:44, Emmanuel Vadot wrote: > >> can this be merged to 14-STABLE > >> /sys/dev/iicbus/pmic/rockchip/rk8xx_clocks.c > >> this seems to cause a panic > >> clkidef.name =3D (nclks =3D 2) ? clknames[0] : "clk32kout1"; > >> > > It's a bit too late tbh, also I don't consider rk356x stable even in > > 15-CURRENT, so this will be merged in stable/14 at some point but for > > now if you want to run on rk356x please use 15-CURRENT. >=20 >=20 > Hi Emmanuel, >=20 > thanks for your great FreeBSD contributions! Highly appreciate the=20 > Porting-FreeBSD-to-a-new-ARM-Board publication too! Thanks. > Quick question - I'm new to arm/u-boot, but some FreeBSD src & ports=20 > experience here... >=20 > In u-boot-2023.10 there's (master/)configs/nanopi-r5c-rk3568_defconfig=20 > added. > Simply copy'n'paste the ports/sysutils/u-boot-nanopi-r4s to=20 > u-boot-nanopi-r5c isn't enough... (after updating u-boot-master from=20 > 2023.07 to 2023.10, done that) >=20 > I don't understand sysutils/atf-master resp. sysutils/atf-rk3399. > Simply creating new rk3568 slave ports doesn't work since PLAT rk3568=20 > isn't implemenmted upstream...=A0 I guess I would have to adjust=20 > sysutils/u-boot-nanopi-r5c to get rid of the AT-F dependency first... but Yes upstream TF-A doesn't have rk356x support right now so we have to use the ones provided at https://github.com/rockchip-linux/rkbin > You mention running 15-CURRENT on rk356x >=20 > How to boot? >=20 > Would highly appreciate links - I'm currently trying to deploy=20 > FriendlyELEC R5C here - I could successfully start 14-stable, but just=20 > by try'n'error metgod, gluing lots of different loader blobs onto=20 > SDcard.=A0 I need to learn a lot, so I'm trying to do it a little bit=20 > smarter than try'n'error... >=20 >=20 > Thanks in advance, >=20 > -harry >=20 >=20 U-Boot also doesn't support the DRAM controller so we also need an external blob from rkbin. That's the main reason I haven't done ports for u-boot on rk356x so one have to compile u-boot themselve. It can be simply done like any other u-boot targets and only needs two env variable : export BL31=3D/path/to/rkbin/bin/rk35/rk3568_bl31_v1.43.elf export ROCKCHIP_TPL=3D/path/to/rkbin/bin/rk35/rk3568_ddr_1560MHz_v1.18.bin Cheers, --=20 Emmanuel Vadot From nobody Sat Dec 16 03:30:21 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 4SsWnG5QgZz54SyV for ; Sat, 16 Dec 2023 03:30:26 +0000 (UTC) (envelope-from fred@thegalacticzoo.com) Received: from nmtao101.oxsus-vadesecure.net (mta-131b.oxsus-vadesecure.net [135.148.117.229]) (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 4SsWnF62kQz4bJ5 for ; Sat, 16 Dec 2023 03:30:25 +0000 (UTC) (envelope-from fred@thegalacticzoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=webcom.xion.oxcs.net header.s=mail1 header.b="eLSJN/s1"; spf=pass (mx1.freebsd.org: domain of fred@thegalacticzoo.com designates 135.148.117.229 as permitted sender) smtp.mailfrom=fred@thegalacticzoo.com; arc=pass ("oxsus-vadesecure.net:s=arc-202309-rsa2048:i=1"); dmarc=pass (policy=quarantine) header.from=thegalacticzoo.com ARC-Seal: i=1; a=rsa-sha256; d=oxsus-vadesecure.net; s=arc-202309-rsa2048; t=1702697422; cv=none; b=JUCJoBeR62lUGJY7l2xRAtPiIvADAEkDTj0Dbp5hPLle8rNpmF/nbtPocmqGuE+yinB9xNqdPF+k+xsGxsjQXy9JoljvjWW5h62OgOia50fEZwfT02mMEOTF9L7Vp9EUaRx/YvAneMfYvzEfNr2UTM46R/2aYSEC8Pi8stwv+p7og1hMENQHvKQ+cGit9uzzPQx/K/vg3JicFNJ6Q8pLJQZo9yvwGyrh9kJhHBU26eJFVtHQXvQRm+s1dno/t2mV4LBY+mM/t8IU8Phw1Z/msfhlJyf+OInekcXDWspSJu6rJJIeFhWXXChTY6DJN/B5etUUczdmY4VXU+N7G4XJQg== ARC-Message-Signature: i=1; a=rsa-sha256; d=oxsus-vadesecure.net; s=arc-202309-rsa2048; t=1702697422; c=relaxed/relaxed; h=from:reply-to:subject:date:to:cc:resent-date:resent-from:resent-to:resent-cc:in-reply-to:references:list-id:list-help:list-unsubscribe:list-subscribe:list-post:list-owner:list-archive; bh=P1tcSe82QqmbNWxRh2u/RYsPiy7tWThGm7TegPpMqfU=; b=CIW8VKFDdRQOiU3JV/LgATtwo8Wc6xiZQAuEhSWcvZ+MJuItkH8RTo2ZMoeFISH4NPpKXF4xrKEmnf54DEY3qoNojuEm/TU0E80yi9e8ZVoy7zl2/lSCDTYZ36hLzIzQ33lKzZLZBcEQngHUeFKVgdGK5Chfkh9mAU9nVg1QLZ1b1QOrZdouRtETWKEA7BcidXTJr+jHn0Fnq1k3lOCW8SSuw2MR69SDhkEN3YBl8TPj1NxWVZbC5dhuProaw6h5pFoFUsu0gQA8lhPNvwVawwloyLw3beYckoOvRFToyGP3ZrVOyLQcWxWzrNFiYr36nqgLQUXV4Nkv94ozkKiC2Q== ARC-Authentication-Results: i=1; DKIM-Signature: v=1; a=rsa-sha256; bh=P1tcSe82QqmbNWxRh2u/RYsPiy7tWThGm7TegP pMqfU=; c=relaxed/relaxed; d=webcom.xion.oxcs.net; h=from:reply-to: subject:date:to:cc:resent-date:resent-from:resent-to:resent-cc: in-reply-to:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; q=dns/txt; s=mail1; t=1702697422; x=1703302222; b=eLSJN/s1LC4vp7M9i4I7CL4WGsvD0zDgNqMbMYBNV KdNdybhLGYmWnmccc6V8pT8KkOfw+qOiuuM/7tXUeXSUgHb/5V/VSE0J3SWFFFmkjRpWC+p c/Zc2ALqk+r5vBIIdnzI4phF1bRLAkfF5STTq1HNIwGkmGTf3Kc3+rRWQ49z3s8sC+xzCDF iGNVhOgQnzpIEU24xb0LJUqjcfY3/XofoWp+GONOuKzlor1ppHtzhO8PPi8r3uFlmQvZCa7 9z2WjiL8gfU0wBit3WQxjtPKcb8Bv/2fa0/UOUASxwF1xuFND+AY/d18amerqQEtjjVXDcj kDOpHJ3iPOSdVAYeg== Received: from proxy-10.proxy.cloudus.ewr.xion.oxcs.net ([76.14.239.229]) by oxsus1nmtao01p.internal.vadesecure.com with ngmta id ccf7ba60-17a13248b7ad78e6; Sat, 16 Dec 2023 03:30:22 +0000 To: freebsd-arm@freebsd.org Cc: "fredfinster58@gmail.com" From: "Fred G. Finster" Subject: Re: u-boot-nanopi-r5c [Was: Re: 14-BETA5 panic on rk3566] https://personalbsd.org/images Organization: Kliktel.co Message-ID: <43691d67-3d00-e8d5-f917-fbb2963454cc@thegalacticzoo.com> Date: Fri, 15 Dec 2023 19:30:21 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spamd-Result: default: False [-3.00 / 15.00]; ARC_ALLOW(-1.00)[oxsus-vadesecure.net:s=arc-202309-rsa2048:i=1]; URL_IN_SUBJECT(1.00)[personalbsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000]; FAKE_REPLY(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.998]; DMARC_POLICY_ALLOW(-0.50)[thegalacticzoo.com,quarantine]; R_DKIM_ALLOW(-0.20)[webcom.xion.oxcs.net:s=mail1]; R_SPF_ALLOW(-0.20)[+ip4:135.148.117.228/30]; ONCE_RECEIVED(0.10)[]; MIME_GOOD(-0.10)[text/plain]; RWL_MAILSPIKE_GOOD(-0.10)[135.148.117.229:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; RCPT_COUNT_TWO(0.00)[2]; DKIM_TRACE(0.00)[webcom.xion.oxcs.net:+]; HAS_ORG_HEADER(0.00)[]; ASN(0.00)[asn:16276, ipnet:135.148.0.0/17, country:FR]; RCVD_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_CC(0.00)[gmail.com] X-Rspamd-Queue-Id: 4SsWnF62kQz4bJ5 X-Spamd-Bar: -- > From: Emmanuel Vadot > Date: Fri, 15 Dec 2023 15:56:40 UTC > > Hi, > > On Fri, 15 Dec 2023 12:06:02 +0100 > Harry wrote: > >> On 10/12/23 18:44, Emmanuel Vadot wrote: >> >> can this be merged to 14-STABLE >> >> /sys/dev/iicbus/pmic/rockchip/rk8xx_clocks.c >> >> this seems to cause a panic >> >> clkidef.name = (nclks = 2) ? clknames[0] : "clk32kout1"; >> >> >> > It's a bit too late tbh, also I don't consider rk356x stable even in >> > 15-CURRENT, so this will be merged in stable/14 at some point but for >> > now if you want to run on rk356x please use 15-CURRENT. >> >> >> Hi Emmanuel, >> >> thanks for your great FreeBSD contributions! Highly appreciate the >> Porting-FreeBSD-to-a-new-ARM-Board publication too! > > Thanks. > >> Quick question - I'm new to arm/u-boot, but some FreeBSD src & ports >> experience here... >> >> In u-boot-2023.10 there's (master/)configs/nanopi-r5c-rk3568_defconfig >> added. >> Simply copy'n'paste the ports/sysutils/u-boot-nanopi-r4s to >> u-boot-nanopi-r5c isn't enough... (after updating u-boot-master from >> 2023.07 to 2023.10, done that) >> >> I don't understand sysutils/atf-master resp. sysutils/atf-rk3399. >> Simply creating new rk3568 slave ports doesn't work since PLAT rk3568 >> isn't implemenmted upstream... I guess I would have to adjust >> sysutils/u-boot-nanopi-r5c to get rid of the AT-F dependency first... but > > Yes upstream TF-A doesn't have rk356x support right now so we have to > use the ones provided at https://github.com/rockchip-linux/rkbin > >> You mention running 15-CURRENT on rk356x >> >> How to boot? >> >> Would highly appreciate links - I'm currently trying to deploy >> FriendlyELEC R5C here - I could successfully start 14-stable, but just >> by try'n'error metgod, gluing lots of different loader blobs onto >> SDcard. I need to learn a lot, so I'm trying to do it a little bit >> smarter than try'n'error... >> >> >> Thanks in advance, >> >> -harry >> >> > > U-Boot also doesn't support the DRAM controller so we also need an > external blob from rkbin. > That's the main reason I haven't done ports for u-boot on rk356x so > one have to compile u-boot themselve. > It can be simply done like any other u-boot targets and only needs two > env variable : > export BL31=/path/to/rkbin/bin/rk35/rk3568_bl31_v1.43.elf > export > ROCKCHIP_TPL=/path/to/rkbin/bin/rk35/rk3568_ddr_1560MHz_v1.18.bin > > Cheers, > > -- > Emmanuel Vadot Hary, I can see you are testing and setting up a build environment for the Nano Pi R5C SBC. Look at Sleep Walkers work over at https://personalBSD.org and Telegram Group t.me/personalbsd https://personalbsd.org/images/FreeBSD-aarch64-14.0-CURRENT-NanoPi-R5C-20230522.img.xz Give this image a test run on your hardware NanoPi r5c. Then read register settings and save. See what settings and values (ie binary blobs NOT LOADED ) exist in your kernel boot image. Then modify your own sources and build another new image again. Chat with SleepWalker and maybe get a working build environment? ExtroWerk user, was porting FreeBSD to a GeniaTech RK3566 SBC board. https://t.me/PersonalBSD/11146 I see ExtroWerk was asking me to build an image for him. https://extrowerk.com/2023-10-30/Geniatech-XPI-3566-ZERO-SBC.html https://github.com/extrowerk Yes, Harry, I want to see you successfully build a FreeBSD kernel from source to run and execute on the NanoPi r5c single board computer. Ie Get all the "little ducks in a row." like binary blobs, makefiles, KERNCONF=GENERIC-NANOPIR5C . Best of luck to you, Harry. -- Fred Finster GhostBSD-Arm64.blogspot.com t.me/ghostbsd Telegram Channel GhostBSD.org website From nobody Sat Dec 16 10:34: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 4SsjBq2mmjz53kFC for ; Sat, 16 Dec 2023 10:34:43 +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 4SsjBn72f5z4Gfq for ; Sat, 16 Dec 2023 10:34:41 +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 6B8D05F2AE; Sat, 16 Dec 2023 10:34:36 +0000 (GMT) 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,SPF_HELO_NONE, SPF_SOFTFAIL autolearn=no autolearn_force=no version=3.4.2 Received: from owl.net-art.cz (owl.net-art.cz [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 B03B35EE94 for ; Sat, 16 Dec 2023 10:34:32 +0000 (GMT) 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 2202298 for freebsd-arm@freebsd.org; Sat, 16 Dec 2023 11:34:29 +0100 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Date: Sat, 16 Dec 2023 11:34:29 +0100 From: Alex Samorukov To: freebsd-arm@freebsd.org Subject: problems on FreeBSD14 on armv6 board (RPI1-B) Message-ID: <59dba804e50560ff89809ef3a839f3f4@freebsd.org> X-Sender: samm@freebsd.org Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Result: default: False [-3.10 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:24806, ipnet:2001:15e8::/32, country:CZ]; DMARC_NA(0.00)[freebsd.org]; RCVD_COUNT_THREE(0.00)[3]; RCPT_COUNT_ONE(0.00)[1]; FROM_HAS_DN(0.00)[]; FREEFALL_USER(0.00)[samm]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; R_SPF_SOFTFAIL(0.00)[~all:c]; TO_DOM_EQ_FROM_DOM(0.00)[] X-Rspamd-Queue-Id: 4SsjBn72f5z4Gfq X-Spamd-Bar: --- Hello, I just upgraded my old (but still working) RPI-B board to FreeBSD 14 using cross-build [1]. Good news - it actually boots fine and seems to work. But i found a problem - `ps -x` command fails: root@rpi:# ps ax Floating exception (core dumped) I tried to recompile it with default flags myself on rpi, but the result is the same. This is output from the gdb: root@rpi:/usr/src # gdb /bin/ps GNU gdb (GDB) 12.1 [GDB v12.1 for FreeBSD] Copyright (C) 2022 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "armv6-portbld-freebsd14.0". Type "show configuration" for configuration details. For bug reporting instructions, please see: . Find the GDB manual and other documentation resources online at: . For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /bin/ps... Reading symbols from /usr/lib/debug//bin/ps.debug... (gdb) run ax Starting program: /bin/ps ax Program received signal SIGFPE, Arithmetic exception. Floating point underflow. 0x0002423c in getpcpu (k=k@entry=0x2083aa00) at /usr/home/srvadm/freebsd-src/bin/ps/print.c:649 649 /usr/home/srvadm/freebsd-src/bin/ps/print.c: No such file or directory. [1] https://smallhacks.wordpress.com/2023/07/20/updating-freebsd-on-armv6-board-rpi-b/ Is it some known issue? Is anyone else using RPI on FreeBSD 14? From nobody Sat Dec 16 15:04:20 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 4SsqB507FRz542mv for ; Sat, 16 Dec 2023 15:04:29 +0000 (UTC) (envelope-from SRS0=DYMK=H3=klop.ws=ronald-lists@realworks.nl) Received: from smtp-relay-int-backup.realworks.nl (smtp-relay-int-backup.realworks.nl [87.255.56.188]) (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 4SsqB44zL5z4lR9; Sat, 16 Dec 2023 15:04:28 +0000 (UTC) (envelope-from SRS0=DYMK=H3=klop.ws=ronald-lists@realworks.nl) Authentication-Results: mx1.freebsd.org; none Received: from rwvirtual98.colo.realworks.nl (rwvirtual98.colo.realworks.nl [10.0.10.102]) by mailrelayint1.colo2.realworks.nl (Postfix) with ESMTP id 4Ssq9w6B15z1dY; Sat, 16 Dec 2023 16:04:20 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2; t=1702739060; 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; bh=u7QQ3GV6PBiRs+4oI4Godwax1HNLoxXJZyRDKmL1Toc=; b=q7HzyBIQUqt2IQTBOWmOBVUJj8JmUS/WdGwe/4SPyI17WXDAHSqBx216WTOORcxcep2ILp qFEEkIEMNKmRzvA6d0yv8khdXQ1BO+PUh/2t5nFyzJ8AFVp1lpx1v9lnosFOLpz5ppZIvL wyo1uQCDpikAuweJ8Ov4hTZolZb9VJipxbVKjLWToG4MB4KgaJ1tBmGbWcbtOryy6RsGkR pPtA58o5xTlVzrJU+OHg5ddlu0SFYWo5oefJa7+bk02IUJjCxNlD3xVR0sN6+MVDRIYrp7 JyQNCNHYN707ApV9sSimkiE6ao5eX6Qt0E/8FXnsqWh0RIOIKnioWuv7hrGG9A== Received: from rwvirtual98.colo.realworks.nl (localhost [127.0.0.1]) by rwvirtual98.colo.realworks.nl (Postfix) with ESMTP id A5D1DA02F0; Sat, 16 Dec 2023 16:04:20 +0100 (CET) Date: Sat, 16 Dec 2023 16:04:20 +0100 (CET) From: Ronald Klop To: ronald@freebsd.org Cc: freebsd-arm@freebsd.org, Alex Samorukov Message-ID: <2025707260.15114.1702739060451@localhost> In-Reply-To: <59dba804e50560ff89809ef3a839f3f4@freebsd.org> Subject: Re: problems on FreeBSD14 on armv6 board (RPI1-B) List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_15113_923267729.1702739060449" X-Mailer: Realworks (683.43) X-Originating-Host: from (localhost [127.0.0.1]) by rwvirtual98 [10.0.10.102] with HTTP; Sat, 16 Dec 2023 16:04:20 +0100 Importance: Normal X-Priority: 3 (Normal) 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:38930, ipnet:87.255.32.0/19, country:NL] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4SsqB44zL5z4lR9 ------=_Part_15113_923267729.1702739060449 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable >From the release notes: Availability FreeBSD 14.0-RELEASE is now available for the amd64, aarch64, i386, powerpc= , powerpc64, powerpc64le, powerpcspe, armv7, and riscv64 architectures. So no armv6. Doesn=E2=80=99t mean it can=E2=80=99t work of course. But no = =E2=80=9Cformal=E2=80=9D testing in the release. Regards, Ronald =20 Van: Alex Samorukov Datum: 16 december 2023 11:34 Aan: freebsd-arm@freebsd.org Onderwerp: problems on FreeBSD14 on armv6 board (RPI1-B) >=20 >=20 > Hello, >=20 > I just upgraded my old (but still working) RPI-B board to FreeBSD 14 usin= g cross-build [1]. Good news - it actually boots fine and seems to work. Bu= t i found a problem - `ps -x` command fails: >=20 > root@rpi:# ps ax > Floating exception (core dumped) >=20 > I tried to recompile it with default flags myself on rpi, but the result = is the same. >=20 > This is output from the gdb: >=20 > root@rpi:/usr/src # gdb /bin/ps > GNU gdb (GDB) 12.1 [GDB v12.1 for FreeBSD] > Copyright (C) 2022 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. > Type "show copying" and "show warranty" for details. > This GDB was configured as "armv6-portbld-freebsd14.0". > Type "show configuration" for configuration details. > For bug reporting instructions, please see: > . > Find the GDB manual and other documentation resources online at: > . >=20 > For help, type "help". > Type "apropos word" to search for commands related to "word"... > Reading symbols from /bin/ps... > Reading symbols from /usr/lib/debug//bin/ps.debug... > (gdb) run ax > Starting program: /bin/ps ax >=20 > Program received signal SIGFPE, Arithmetic exception. > Floating point underflow. > 0x0002423c in getpcpu (k=3Dk@entry=3D0x2083aa00) at /usr/home/srvadm/free= bsd-src/bin/ps/print.c:649 > 649 /usr/home/srvadm/freebsd-src/bin/ps/print.c: No such file or director= y. >=20 >=20 > [1] https://smallhacks.wordpress.com/2023/07/20/updating-freebsd-on-armv6= -board-rpi-b/ >=20 >=20 > Is it some known issue? Is anyone else using RPI on FreeBSD 14? >=20 >=20 >=20 >=20 >=20 ------=_Part_15113_923267729.1702739060449 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable From the release notes:

Availability

FreeBSD 14.0-RELEASE is now available for the amd64, aarch64, i386, po= werpc, powerpc64, powerpc64le, powerpcspe, armv7, and riscv64 architectures= .


So no armv6. Doesn=E2=80=99t me= an it can=E2=80=99t work of course. But no =E2=80=9Cformal=E2=80=9D testing= in the release.

Reg= ards,

Ronald  <= /p>

Van: Alex Samorukov <samm@free= bsd.org>
Datum: 16 december 2023 11:34
Aa= n: freebsd-arm@freebsd.org
Onderwerp: problems= on FreeBSD14 on armv6 board (RPI1-B)

Hello,

I just upgraded my old (but still working) RPI-B board to FreeBSD 14 using = cross-build [1]. Good news - it actually boots fine and seems to work. But = i found a problem - `ps -x` command fails:

root@rpi:# ps ax
Floating exception (core dumped)

I tried to recompile it with default flags myself on rpi, but the result is= the same.

This is output from the gdb:

root@rpi:/usr/src # gdb /bin/ps
GNU gdb (GDB) 12.1 [GDB v12.1 for FreeBSD]
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "armv6-portbld-freebsd14.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/= software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
     <http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /bin/ps...
Reading symbols from /usr/lib/debug//bin/ps.debug...
(gdb) run ax
Starting program: /bin/ps ax

Program received signal SIGFPE, Arithmetic exception.
Floating point underflow.
0x0002423c in getpcpu (k=3Dk@entry=3D0x2083aa00) at /usr/home/srvadm/freebs= d-src/bin/ps/print.c:649
649 /usr/home/srvadm/freebsd-src/bin/ps/print.c: No such file or directory.=


[1] https://smallhacks.wordpress.com/2023/07/20/updatin= g-freebsd-on-armv6-board-rpi-b/


Is it some known issue? Is anyone else using RPI on FreeBSD 14?




------=_Part_15113_923267729.1702739060449-- From nobody Sat Dec 16 15:30: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 4Ssqmn6d8Zz54446 for ; Sat, 16 Dec 2023 15:31:05 +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 4Ssqmn4QWGz4ngP; Sat, 16 Dec 2023 15:31:05 +0000 (UTC) (envelope-from samm@freebsd.org) Authentication-Results: mx1.freebsd.org; none Received: by reindeer.net-art.cz (Postfix, from userid 65534) id 035AF5F2AE; Sat, 16 Dec 2023 15:31:03 +0000 (GMT) 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,SPF_HELO_NONE, SPF_SOFTFAIL autolearn=no autolearn_force=no version=3.4.2 Received: from owl.net-art.cz (owl.net-art.cz [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 8E31F5EE94; Sat, 16 Dec 2023 15:31:02 +0000 (GMT) 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 2202337; Sat, 16 Dec 2023 16:30:59 +0100 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Date: Sat, 16 Dec 2023 16:30:59 +0100 From: Alex Samorukov To: Ronald Klop Cc: ronald@freebsd.org, freebsd-arm@freebsd.org Subject: Re: problems on FreeBSD14 on armv6 board (RPI1-B) In-Reply-To: <2025707260.15114.1702739060451@localhost> References: <2025707260.15114.1702739060451@localhost> Message-ID: <692d499f4e1111795479366541a588d7@freebsd.org> X-Sender: samm@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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:24806, ipnet:2001:15e8::/32, country:CZ] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4Ssqmn4QWGz4ngP Thank you for your reply. Yes, it explains why I was not able to find the pkg for the armv6. Probably will revert this board back to 13.x, it is part of my home automation and works very stable with FreeBSD despite its age. Probably this is not the best idea to invest a lot of time in armv6/FreeBSD14, as this CPU is already EoL. Oleksij On 2023/12/16 16:04, Ronald Klop wrote: > FreeBSD 14.0-RELEASE is now available for the amd64, aarch64, i386, > powerpc, powerpc64, powerpc64le, powerpcspe, armv7, and riscv64 > architectures. > > So no armv6. Doesn’t mean it can’t work of course. But no > “formal” testing in the release. > From nobody Sat Dec 16 16:16:40 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 4Ssrng5MPKz547QQ for ; Sat, 16 Dec 2023 16:16:55 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic313-19.consmr.mail.gq1.yahoo.com (sonic313-19.consmr.mail.gq1.yahoo.com [98.137.65.82]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Ssrnf3XvQz3CGn for ; Sat, 16 Dec 2023 16:16:54 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b="jHC/LtOl"; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.82 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=1702743412; bh=djrY/qw6UZvypWFn8Ouv8P6AUOHVNlf9NXiHfuVrUFA=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=jHC/LtOlZklOJ2cAgYQRnVr6Yh1nDMEEsOWFZcBfbiSlVMSvhULG+ifiFGiCFHn3IFwFOoKRlNUpKVVuRADsL2S9LSj2joB986FdhrGK1VhDpZaJe0EWEaImJcVjTtpwpKhJu/vkQT4Ocz0jur2p0+j0lTazIvIdMbeUPpA4/nt+jg2egOrNo+E2WiXPDdcmtXeVqi8DZbXjkl+GAvqzhFKG787kJruXU4rUiryFDiHBeC/jqUrMik843c2lgEIdjmTfsO7PAbDUaA+po4BH7FVDWNTimqKmxPEWs2xpD3RL6zMfeocMlXxQxfDrH0ZjqeIddnmV7ZO7NBCzS+j5/g== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1702743412; bh=vtZv+Bk/FeFjgmF9h2tDlMcX9Rv6lrCOddkxqlfVArH=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=NgZm/EwmU5Yy/MkPTI5Ve98TfhLBoq6XKWhRKWq//wVILUpBsQCwHO65b26zcrG7JjjVl2hQFaAyfrWOKQY9C8rJ0B2wQYr0ihJvZGJt/mN94H7HGzcZ5B0zsKa7RsyOkIdv/xWaE6wJ7nEUtojPVk/1TCNzfxt2/SA9o7DUKym77wp0nFczmWv3e77Sa1HtdYjeGQoKF99Ekl8kTuy+e6f/hOWSIuDN+tyPNNlU6m8cYjslsAfNPidoaoYaH/+CFDnG7BMKV0FxRqwLbdZIbGXWO+H5d5tkFj26LbvjF462aVk70XRe3u1mJ7d/h0PdAxkUMy4Tiiy9YvyD8rjnVA== X-YMail-OSG: wMrv1bEVM1lTXSbBAoq3ded46UrFLxXWVxZ6wkr_cGUFaDIPgq19hRvLfAajml4 I0VSm_CBK0P.24ohb3kdcxFd1kP6uuwGh.3Yd8tQqB69b1X7leoDHybeqAWI.ZK3zBVvO73xeavr IPO2Dg3OvZT.E0aOrt5ay.wf0TCCvRAe2txIpmfDgd68.o1TGZ0u4V1RUb8zEQsuQRMco8dvaZS2 DDP2EsB70AIOJy61lz3xn3.Y_GrnCOwfxTF3LJNmgAOqRDBnjMJj8HNvOnQU.Y5tZqqtAk28s6S4 tW7.Uv4Gse.ewgvIfEx62kqc7SzSKn9omeLOxcyKp2SBeTuBq514maiFaGE8Nf8iaRKXVY8eJcHe gNGXFOgaC3.ksKEbrG7xDUzzUuJsGA2ZPjGcCeHOFP_mNaYwKM9QAvbKnM0b0RSEpwI8_eHF8ih0 dGEpeckmPCCju4vYB_uWrOlnzOiff_exicEwu8MQ5Wfn7NMRvE_Yn8aeYF_z2V4Zc25I6mbGzGPM SzT1hRVvRI7JPvZonU.JktVt6URPteI75AhwTlzaQ6dLyYF0R5kB8V1VfxHpFRhDcS96GF1ZSH9C BR_fDEs.y2LCXz07LS7n3BR5xZXv1l82oeTHrTchwcW.AYh1G2PKeZKlhs.EqipHjCW8PD.xzd.Z d0WGcu.lQMxCiA03Zra3RuPaQipdYck7zyBxzW4fgMDh4OXCOe3Halg1yBJUJhWUMeJ_umGpbyon 12XopSoNncMYRg74PD9EZoAAs_d1U5TeAJJ4rgdQU.zKwKvnTBLGMP9ZKkvVYazzY6TmRGAIudRg xgznmzpxji2oNpwhc1cCBDFE30eSI7FmCw_sQpwrOcnfuc08apawrOW78iA.nLux8XwW_ZXsy77j imFZjIZCeD3.s7uus5gVeIKHs0gTJCqoqfu3oVAp2_3oltDNw0Kv4bPVcEFOCDpf8z7rny9TqP6M lPegfa4C2HOdgwS9fPWm9VirdL1YdhdtwrU0BTs3cDwXzYsKMocsM7y52jNruOBV6NKyE3cl3wy2 Uz3F6ha.aaMXW.qPpQ9Y3e_NvxV1Cum95R_JxiqwbC1dAarVOfs_IF2rVQfDgRHQ9Np.De1EmX0h J6dILBeP3biNMpbcKImC4fEPE59BzSNP9J3OUHxtD06wsNM7SgOyA5pTvaFAil8Hy_xOkySRAnuj ORoguwzkMrSs83NprIiNutnxUOjjZghM5Ls3jNBbuU97uLe7orSJDMdImtLWfOi1Mdf3k4jc_SDj _gK0MmGFtZr.bonc64qrQhKAtpMi5CYSKcf.vmFDxzIWV07FTbio8_SmZabLTDkySLqr68sJnSfV 5bLOnWL2VYj9aI0iZPpB9injIXjeuaJ_ZQA0OXMeLlM4Y8o_TjqOUFTHBZ8oaYouQNhWlGUXTlG7 2fyLk3TVldhcBIr3K.f5qDa49cE31_6QYgy_6iYDL43HfRYkD7HogMW1UAtTJaJl8zukj372kF0t K_b9rQranXqbXVn5DAZU3Im5uB_ccl5nZfgCeNm.Y5kGsEIgxVuo1RsJwSdOxGisLQlVxzlDTs_w HAjVINPxXrsq4XLGbQhzyTRe7ZnLE1YyUfW5GBZxvKqinxc1wOpcKXlyJjACwHAJpQhrtg8PjKGI OAWOrj2cXJjuw2roxv12Oioxr4_gtLYqpyFU.6LR75bktOQpGO5VJ6Q6yD8rGn39wF9.GxFuMshD TOuFlTyDVw6Qn5rZEdJOFrjFegM0G8579S.oFEF7gH3um5PSfw1bVZf5RXJmBT2NEPfkowxzWgTg NoOBsuGixenEeMYPPYi93FV5Dch8uox0tjXWQ6Ajvh6gtwxTmj7EIctDwSzjFcJNxxtT6SIbrphP 6O.ThR4teEtgP4djr.sf4JPgp32ai3D8AOQ_IeuGio.vLB58w0VLsaXkF8gWdyoPMJjMXb25rVFQ 4fPLPlvBfGodNzL4fTVZ2UnRZOnyKnwyGDDNGki41TvW.vYjosf8mIrRrWH5BPKsa1bEvyeu4.T9 JxgK64ERIOFITkWerXp7Eh0_iQRqHvvYUrX1WPsYBkjijfPY7lb4KeXe0w60AotvtysKcw2ZtaIq O3jVyhMkP.hSR1SnhOB2c62fGytMuuoPsz7McHCwlkrkXQfyy4ztlC.YfEz0HDeDI3f3jSHv1oXa 8Q._nD8kpzcGbfFeu4x0KWmcKTn87WLplbjBl.Y_GjPxKOILJ._bkA84pr863MyWot6pApAVbvue 5AFKT8UMdZ0oYrB3g7JlCB_GLJ2CLhWbfAe8DB0N2FW3PL7Fh1gCWXht.Z9CsdY1EWy3jBW1iQae vkw-- X-Sonic-MF: X-Sonic-ID: db2922d5-5b30-45da-93d4-db221368abc2 Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.gq1.yahoo.com with HTTP; Sat, 16 Dec 2023 16:16:52 +0000 Received: by hermes--production-gq1-6949d6d8f9-nsbdm (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID b6cc19b48850ca2f1298caa39ba862c5; Sat, 16 Dec 2023 16:16:51 +0000 (UTC) Content-Type: text/plain; charset=utf-8 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.300.61.1.2\)) Subject: Re: problems on FreeBSD14 on armv6 board (RPI1-B) From: Mark Millard X-Priority: 3 (Normal) In-Reply-To: <2025707260.15114.1702739060451@localhost> Date: Sat, 16 Dec 2023 08:16:40 -0800 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <29274DE1-57D2-45D3-BEB0-CBCF7C70681D@yahoo.com> References: <2025707260.15114.1702739060451@localhost> To: Alex Samorukov X-Mailer: Apple Mail (2.3774.300.61.1.2) 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.881]; 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]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.82:from]; MID_RHS_MATCH_FROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.82:from]; DKIM_TRACE(0.00)[yahoo.com:+]; TO_DN_ALL(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCPT_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; HAS_X_PRIO_THREE(0.00)[3]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4Ssrnf3XvQz3CGn X-Spamd-Bar: --- On Dec 16, 2023, at 07:04, Ronald Klop wrote: >=20 > =46rom the release notes: >=20 > Availability > FreeBSD 14.0-RELEASE is now available for the amd64, aarch64, i386, = powerpc, powerpc64, powerpc64le, powerpcspe, armv7, and riscv64 = architectures. >=20 > So no armv6. Doesn=E2=80=99t mean it can=E2=80=99t work of course. But = no =E2=80=9Cformal=E2=80=9D testing in the release. > Regards, > Ronald =20 Looking in another place, https://www.freebsd.org/platforms/ , = indicates: 14.x for 32-bit ARMv6 (armv6) has Support Tier: Tier 3 https://docs.freebsd.org/en/articles/committers-guide/#archs reports for Tier 3: QUOTE Tier 3 platforms have at least partial FreeBSD support. They are not = supported by the security officer, release engineering, and Ports = Management Team. . . . The FreeBSD Project provides no guarantees to consumers of Tier 3 = platforms and is not committed to maintaining resources to support = development. Tier 3 platforms may not always be buildable, nor are any = kernel or userland ABIs considered stable. END QUOTE The projected 15.x Support Tier is listed as: Unsupported > Van: Alex Samorukov > Datum: 16 december 2023 11:34 > Aan: freebsd-arm@freebsd.org > Onderwerp: problems on FreeBSD14 on armv6 board (RPI1-B) > Hello, >=20 > I just upgraded my old (but still working) RPI-B board to FreeBSD 14 = using cross-build [1]. Good news - it actually boots fine and seems to = work. But i found a problem - `ps -x` command fails: >=20 > root@rpi:# ps ax > Floating exception (core dumped) >=20 > I tried to recompile it with default flags myself on rpi, but the = result is the same. >=20 > This is output from the gdb: >=20 > root@rpi:/usr/src # gdb /bin/ps > GNU gdb (GDB) 12.1 [GDB v12.1 for FreeBSD] > Copyright (C) 2022 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later = > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. > Type "show copying" and "show warranty" for details. > This GDB was configured as "armv6-portbld-freebsd14.0". > Type "show configuration" for configuration details. > For bug reporting instructions, please see: > . > Find the GDB manual and other documentation resources online at: > . >=20 > For help, type "help". > Type "apropos word" to search for commands related to "word"... > Reading symbols from /bin/ps... > Reading symbols from /usr/lib/debug//bin/ps.debug... > (gdb) run ax > Starting program: /bin/ps ax >=20 > Program received signal SIGFPE, Arithmetic exception. > Floating point underflow. > 0x0002423c in getpcpu (k=3Dk@entry=3D0x2083aa00) at = /usr/home/srvadm/freebsd-src/bin/ps/print.c:649 > 649 /usr/home/srvadm/freebsd-src/bin/ps/print.c: No such file or = directory. >=20 >=20 > [1] = https://smallhacks.wordpress.com/2023/07/20/updating-freebsd-on-armv6-boar= d-rpi-b/ >=20 >=20 > Is it some known issue? Is anyone else using RPI on FreeBSD 14? =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sat Dec 16 17:23: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 4SstH82RNDz54Bbn for ; Sat, 16 Dec 2023 17:24:04 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic316-54.consmr.mail.gq1.yahoo.com (sonic316-54.consmr.mail.gq1.yahoo.com [98.137.69.30]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4SstH66zv0z3NGg for ; Sat, 16 Dec 2023 17:24:02 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=DjhnLT75; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.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=1702747440; bh=pkyIui7fDId5+cxrXavf4CBXdAzldHECPJOz+YPzBU8=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=DjhnLT75T9tG3qLgJGtW/SlNgsFcKJ+LASUsYi5PVBxyWyg6cfEoV+fjwvb5SOJMWb5zh3Pg9SW6KtAnIWcabN9tOlMaP0nKZhPpjxGRhBQ3VdpP4aWijziHgpzmFZCvyigkiq49VVadFSOsD/yHrO9Y6fQ0KbHZJpVEXNwOklRXdhNsmHXkKnggLkCk0HIGHAZoC3ec8Y0j05coJkQlVbn1JiqnhjHYaDEyPgNNE+sJMv/5fTQOVTsB2L8oZTjcCyBB6amGLjBi4CXA+hzHfERuHUhK3RYiqRDXCrm1ypMyN0cFKSkpVaNLsl0EzbAkJ1w2ir6KNEDNuQdecv3MwA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1702747440; bh=tvXXBGPxsQkVm1k2ADuTTVFzZNKiOzb/V916an/GnFs=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=rc0BTYcWC58+Hwm2YedF2HeC2PDjBKin6rIf6KcQlzy10/Q5ZuFv1iOVrNRQDZuiVlvFAj/OK2XMYwnWLbO7OZpxGW/3pMRccAm4o+j0o0Tfc2iaKA0t9zzZqnoGMW57qhkFwoP42FqoS5JoEPDoHSfVhZ32MpWK7n66JRqVBD43zf1QeT60h2YevQBS0Ss49I8wXonaCNKI5plLVHZ5p2Tunksk+nRMn5gzCrseVnJ4jtvBaRcd49IolOq++piZdyuboyDlAVZ4Rn3etXbCwGqOFQr3pCM56PfngNEulKF/GycKx3Zb41HkPrB5Iv4dMarrtbR4t1+OxCd1jEDMiQ== X-YMail-OSG: 4jfWAy8VM1lb.YW91FzJ5iOqg_Y1sITQdGoE3KFpjEq3nR_vxyI9zMtUpbPuXaJ 00Ln67QeXID5E39ePYQavI_3ybe2lGFXJgCGYOOw_PUfGCtayrrRG8zsdLIS2IvIfm6weS6BIEH6 tUOXckD09Y7s7YFEAn0o.WxnqEA._HN6gDsq.qYtzmS4CySmecogqQwO2ME5g2v2KVQogmIVRERk 4nKg.EMcivkG5L4m9D6zvv4487zeitRX2OKR3tC8R5XGHDUuwl3s1GrQG8HO3EdVtVq3BEqDmmpx qZxm.4G9W3rDGSLNoXkhCWriAtTuCsm4vymRkQNL4PmYpDipFC4M8mPqZwdPF_uvJCl5NU8_FK7x Dp5bMOj_ju9u9YBALy4mmEI4fTagRYU95E1__fpJc1vyznG5RhHwY6gCNbcIey6p_clhpnKof8N1 DqQ2HfsESNJ2HWHvg6NesOXOJ.Zu2EJ3x8HiUkild2LDyG1.04jBZI0w7YEH8XIX5TydZK7TXyj5 y1Ng3RmbWT5f3bIXf0un1IHaehQYsL0AaI4TMJsNeD.val6WQ0GM7RyjPPEYiqK.YyTRNtD1q5Vc 6MOfGe0qn3LTWUnDFgbSeytYFAg_nwb7T6.Y5wRVrHty.7ELz.LzGGd8zcclWbmD3Ne1KvjqvZ0I tTOQsu3JycAzhbhS7sMCEX4GX0HyS.U45Auz16x4KFMfwaDTgL8huRaFnxwoeU1QknxoBSco_mm7 UO_hilMrcOZ4nkhNmbglswcA1v057Ho_1bVk4366t9654PZQUyxZ75m3DN1ONz0edz3zRoLuNIsa M5wL8vfgk_WnmgqaZS345sy7ZxtwXFZdM_geGPRRcI5Ux5WfKAHjgiRqjIII5KTg0rc08dKesWCC FLkw5Sswd3cAfDHght_sG7JJeV0hMAL_H2WDUxuiWzyynKnbLKS2zwsSTCJUc8VDs8QWPhuBsH8L t_Ikd8YhYXVrh7wNSyndNIYc1l7njphSKD5sjGThKVrydsybeb_6_g2rUcNtG_C.r0Gg7YPK8cWi 3K.TD202GNhNh7I.Mk80vPv_7f3FL5HU6jSxyuyRCFOSEc7WwpKMiOet5AU.wZs0nHaD9iZGnkY0 fPHveChC4nhDD538KnhJFb0CZk4WXfYesw00SyczR4EgJkfLR4kp9ghjdAzf6TVSBZ12NR40ZErl 7q_OgUMsu1qBOArldUVSkpo_1g.lDI61BR4k.VMuywbKmByY7l9_mjby6oTuDKKagroFVLzsLHPk HP0l2Ox7RklwiM1eF2mYe.BoSsPLlJ5rAHwtQclyYBT1HDPq45zlFH9o.jjNzRFY3gqdQfzRoQmx WJFESuOxX.Ghw016ukxajPHh1xrgdv8Fp_FOisdjsHfeukPQtmCHI8pgnIN1DfMwl.Y48LY3VY.t i5bKjPuq_15P__gPtgksacBRp4NIcsJiRRUKX0InAWWY__pOmZagG0nKSwP37oZz212BCy5TQNJi Rlq98vIS_rbYDdZEy5NHmN6FIAnfMsVJvci4hd80hMhg1BDzyJ68VD1HDyiQchIrUFUVE0gTOQKG BvdBEb8of6Vcr8UuQQNjRYkjyvT9wD9ZFqPUgB.QZD1aeVfl5Bj8adKRrr5gWs.DyExEIEtt1MNY LJJok4BLSnVMPdcW.wRf_0qiLGZ.RB2.kwBuQH9fQSptauqEOrNZ6RDHnJ9VyRFeGJyJnz42VEya VzTDqnbZyDpnSisd_ax5MtL71BBBQKgUZGciH2kpCgO_k_AtbUHbFpCCF8uOPrpXyTR.Hg756PMy LHtQ7Wk9qNFsMUj.HPvKcilvD4wHXscmccKpkwb4WVw.4UFT9cUh1985HMt7vuFa5CAEE1Xufp3k qarMHhPD1vnWVlECqrKqBXrrlSR5WyVCArUH_ZOmhRMPghIio010cfEmmW3bfxaK1Gr_hH.BykXw gQfLzXRxwzRsdUsBM8g6heHCRal6kFQIXhsNgWnu06m7g9fOcpMqcpedxEBGvgHIhHrAfdaowkX5 lR9KQLcAm8kuDZw7LVDslmcu2jWxYNyEvV.i4UYz6BZqmPKEaQtBrTnLqSD6NP7mY7pMjXuA93GM _alqmGWW8LiX9MHBXJnFnFF68AXUdgCQXIeqJlr3BFZXaL4Df4xcug16DGNhfrAIt7Kc_E.WQZ4c 6nM45ZteOLQYFE1a3tnzGjAwIbQG2RPg_OHwCZfKUzqqCQ.4W9k2dC6Q1mr3RUaA64i4as2F46Rr kI0a9XKS9Zsi4QWFsrCB76gpEkQXH944Txf0X6QdqfKgOmDPEBTNJLn4okHwbI5rcMS1DQGj._gW tCQ-- X-Sonic-MF: X-Sonic-ID: 0ae39110-742d-4cf6-98ba-8dd93da3cc2e Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Sat, 16 Dec 2023 17:24:00 +0000 Received: by hermes--production-gq1-6949d6d8f9-c9pk7 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 12d684ec6b8c8634b591f25b27ebdb9a; Sat, 16 Dec 2023 17:23:57 +0000 (UTC) Content-Type: text/plain; charset=utf-8 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.300.61.1.2\)) Subject: Re: problems on FreeBSD14 on armv6 board (RPI1-B) From: Mark Millard X-Priority: 3 (Normal) In-Reply-To: <29274DE1-57D2-45D3-BEB0-CBCF7C70681D@yahoo.com> Date: Sat, 16 Dec 2023 09:23:46 -0800 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <3E19FD5D-BC1A-4BA0-970F-BF195D8F7470@yahoo.com> References: <2025707260.15114.1702739060451@localhost> <29274DE1-57D2-45D3-BEB0-CBCF7C70681D@yahoo.com> To: Alex Samorukov X-Mailer: Apple Mail (2.3774.300.61.1.2) 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.998]; 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]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.30:from]; MID_RHS_MATCH_FROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.30:from]; DKIM_TRACE(0.00)[yahoo.com:+]; TO_DN_ALL(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCPT_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; HAS_X_PRIO_THREE(0.00)[3]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4SstH66zv0z3NGg X-Spamd-Bar: --- On Dec 16, 2023, at 08:16, Mark Millard wrote: > On Dec 16, 2023, at 07:04, Ronald Klop wrote: >>=20 >> =46rom the release notes: >>=20 >> Availability >> FreeBSD 14.0-RELEASE is now available for the amd64, aarch64, i386, = powerpc, powerpc64, powerpc64le, powerpcspe, armv7, and riscv64 = architectures. >>=20 >> So no armv6. Doesn=E2=80=99t mean it can=E2=80=99t work of course. = But no =E2=80=9Cformal=E2=80=9D testing in the release. >> Regards, >> Ronald =20 >=20 > Looking in another place, https://www.freebsd.org/platforms/ , = indicates: >=20 > 14.x for 32-bit ARMv6 (armv6) has Support Tier: Tier 3 >=20 > https://docs.freebsd.org/en/articles/committers-guide/#archs reports > for Tier 3: >=20 > QUOTE > Tier 3 platforms have at least partial FreeBSD support. They are not = supported by the security officer, release engineering, and Ports = Management Team. > . . . > The FreeBSD Project provides no guarantees to consumers of Tier 3 = platforms and is not committed to maintaining resources to support = development. Tier 3 platforms may not always be buildable, nor are any = kernel or userland ABIs considered stable. > END QUOTE >=20 > The projected 15.x Support Tier is listed as: Unsupported I also should have looked at the history of the port->package builds for quarterly 132releng-armv6 and reported: The most recent build that finished (stopped:done) was started on: Tue, 05 Sep 2023 02:38:35 GMT It is the source of what is currently provided via pkg . So no security updates from after that time frame via use of pkg, at least for now. The most recent build attempt was started at: Thu, 05 Oct 2023 02:37:41 GMT and had 34637 queued but 8276 built before it crashed. Generally the quarterly 132releng-armv6 builds attempting the full 34000+ packages resulted in "stopped:crashed". One completed: Tue, 01 Aug 2023 04:37:22 GMT crashed, having built: 14831 Sat, 05 Aug 2023 04:40:30 GMT "done", having built: 26346 Thu, 07 Sep 2023 02:38:44 GMT crashed, having built: 8272 Thu, 05 Oct 2023 02:37:41 GMT crashed, having built: 8276 (It is harder to judge the total that were available after an incremental build.) All of the 7 "done" quarterly 132releng-armv6 builds are from 2023-August builds (after Aug-01) and from early 2023-Sep builds. After that: all crashed. Quarterly 132releng-armv6 is the only type of armv6 build attempted after Mon, 21 Aug 2023 15:02:47 GMT (the last latest for main-armv6 build that has been attempted). >> Van: Alex Samorukov >> Datum: 16 december 2023 11:34 >> Aan: freebsd-arm@freebsd.org >> Onderwerp: problems on FreeBSD14 on armv6 board (RPI1-B) >> Hello, >>=20 >> I just upgraded my old (but still working) RPI-B board to FreeBSD 14 = using cross-build [1]. Good news - it actually boots fine and seems to = work. But i found a problem - `ps -x` command fails: >>=20 >> root@rpi:# ps ax >> Floating exception (core dumped) >>=20 >> I tried to recompile it with default flags myself on rpi, but the = result is the same. >>=20 >> This is output from the gdb: >>=20 >> root@rpi:/usr/src # gdb /bin/ps >> GNU gdb (GDB) 12.1 [GDB v12.1 for FreeBSD] >> Copyright (C) 2022 Free Software Foundation, Inc. >> License GPLv3+: GNU GPL version 3 or later = >> This is free software: you are free to change and redistribute it. >> There is NO WARRANTY, to the extent permitted by law. >> Type "show copying" and "show warranty" for details. >> This GDB was configured as "armv6-portbld-freebsd14.0". >> Type "show configuration" for configuration details. >> For bug reporting instructions, please see: >> . >> Find the GDB manual and other documentation resources online at: >> . >>=20 >> For help, type "help". >> Type "apropos word" to search for commands related to "word"... >> Reading symbols from /bin/ps... >> Reading symbols from /usr/lib/debug//bin/ps.debug... >> (gdb) run ax >> Starting program: /bin/ps ax >>=20 >> Program received signal SIGFPE, Arithmetic exception. >> Floating point underflow. >> 0x0002423c in getpcpu (k=3Dk@entry=3D0x2083aa00) at = /usr/home/srvadm/freebsd-src/bin/ps/print.c:649 >> 649 /usr/home/srvadm/freebsd-src/bin/ps/print.c: No such file or = directory. >>=20 >>=20 >> [1] = https://smallhacks.wordpress.com/2023/07/20/updating-freebsd-on-armv6-boar= d-rpi-b/ >>=20 >>=20 >> Is it some known issue? Is anyone else using RPI on FreeBSD 14? >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sat Dec 16 22:07: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 4St0bC2F3wz52mj4 for ; Sat, 16 Dec 2023 22:08:23 +0000 (UTC) (envelope-from jsm@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4St0bC1gNFz4dvQ for ; Sat, 16 Dec 2023 22:08:23 +0000 (UTC) (envelope-from jsm@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1702764503; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=/STWOmocX5QfmBuS8diqQ4vXGxZ8tv1tsetv/cYn0Ks=; b=vY65ZTg1RzR1anikOeZQA2S0BJtrSaPHYwsR/7Z8aSjYkAPekIX2ILtsURbZKbtqHeBIe6 6cxqiD6gcOapRn+f8PY/mWxeIXUIFMmtKmBsPXYDkb4ShkZo99hIRdzUGi4dyVV0xlzbFW BC8o7QeEitPxp6/NGjjl5w5T35BgJ7P+2Im3i9wf3jeRe3xmIGipbazQYasp7vYIh+XePJ zlApjma3jh82iE0jv5hIblU7YLN5Bz8C6JkGLmjPVzrrqdc92lyTUsuR3DopBLSwta4E8f Xn1d23Vs/gvLElHthr/uf04vUaEiO99PGfk7VZev+cIg5fUFvhA9Kwfe0VsFTg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1702764503; a=rsa-sha256; cv=none; b=PcMdDvsIRglPHJSJikhgti0czK/LebZe5Cs7ty+GD6DxL0Zydk7TmBfYaVV1AMvyIyzmUH HsnvJSxvQ4ETrL/Ao9vWdIUXc8GAjRhG3XY4LKqDkv6CiOIwCLgPD19DHDAPSfNqS/MtOU kVDztOydGch6K45dCcJ34csJhnwXntxnRBe9HHiBvIRp/8nwp09FTZ33+BprRy+Juzso+X DylHIxR+WCU4PKHbn6ydRHGaI2nSL/96DdMBHtL2CF39gwT7hcro5kOyMtbvTf4RWOIU8v 9WjRkgaGDOwhJhmTY/vjJIY1rHS1/I1ZvybgLTwfxv/jNaruUvwZhbvWMNIf1w== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1702764503; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=/STWOmocX5QfmBuS8diqQ4vXGxZ8tv1tsetv/cYn0Ks=; b=p9FRjtxQ6qbKGWKZi3NcWqMR2A0tPkSv6XmBjBYYnK9OHrCzfDTW6oQeUm8rtJ1gzaUQix C1vgov1J6xTGDAWV+W9gTsxFyyuWD9DU0gotD+u71ryQDdQUZYVvBNYM4H5cGHn6Yg8ga5 jrr/CgBS/CalG1g2jPjcMEm1LxfKzby/GTQh85jhJoSwrmQ2v3sh6ND6/Rkcy2WZiuya72 gqkua1oITSLu4xSPuAUV+rTyXCqOEL9EbOoPxq3JsIBzWMSbdlsoIC5b4V21WemANGxj/B WfAqau0QaMwO3fQApVulvmrWXP9dZhj3Wa7ccMOawhjVJ0AfHV/BvYXJPaet3Q== Received: from [192.168.1.5] (mail.northatlanticmusicsupplies.com [212.237.182.202]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: jsm) by smtp.freebsd.org (Postfix) with ESMTPSA id 4St0bB66BFztwS for ; Sat, 16 Dec 2023 22:08:22 +0000 (UTC) (envelope-from jsm@FreeBSD.org) Message-ID: <7daaaade-955d-4678-bec4-a34a196b27b7@FreeBSD.org> Date: Sat, 16 Dec 2023 23:07:46 +0100 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: firefox broken on arm64 Content-Language: en-US From: Jesper Schmitz Mouridsen To: freebsd-arm@freebsd.org References: <9518dc38-e44b-42ae-bf87-6039ac278ac8@FreeBSD.org> <46c52d37-36ec-45fc-8098-1029996c717c@FreeBSD.org> <27c55e4e-21d2-44f7-9436-95fa1e5b4722@FreeBSD.org> In-Reply-To: <27c55e4e-21d2-44f7-9436-95fa1e5b4722@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 10.12.2023 14.08, Jesper Schmitz Mouridsen wrote: > > > On 03.12.2023 11.59, Jesper Schmitz Mouridsen wrote: >> >> >> On 03.12.2023 09.38, void wrote: >>> On Sun, Dec 03, 2023 at 08:34:21AM +0100, Jesper Schmitz Mouridsen >>> wrote: >>>> >>>> Just build firefox-esr-115.5.0_1,1  and firefox-116.0.3_1,2 the >>>> first runs with aslr disabled, the latter signals 4. >>>> >>>> Any suggestions on what is going on are appreciated. >>> >>> What's the uname -aKU ? >> >> FreeBSD generic 14.0-RELEASE FreeBSD 14.0-RELEASE #0 >> releng/14.0-n265380-f9716eee8ab4: Fri Nov 10 09:12:14 UTC 2023 >> root@releng1.nyi.freebsd.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC arm64 1400097 1400097 >> >>   did you build from ports or poudriere? >>  From ports. >> >> If the >>> latter, what's the /etc/make.conf contain? >>> >>> Please post sysctl -a | grep aslr >>> >> >> kern.elf32.aslr.shared_page: 0 >> kern.elf32.aslr.stack: 1 >> kern.elf32.aslr.honor_sbrk: 0 >> kern.elf32.aslr.pie_enable: 0 >> kern.elf32.aslr.enable: 0 >> kern.elf64.aslr.shared_page: 1 >> kern.elf64.aslr.stack: 1 >> kern.elf64.aslr.honor_sbrk: 0 >> kern.elf64.aslr.pie_enable: 1 >> kern.elf64.aslr.enable: 1 >> vm.aslr_restarts: 256 >> >> I did the esr build to test the build setup, since also the pkg in the >> official pkg repo behaves the same i.e the one before 115.5 since >> 115.5 did not hit the pkg repo yet, which works without aslr (set by >> proccontrol) So unless 116 introduces something which requires sysctl >> changes for the building tool chain while building my test should be >> valid. >> >> Thanks >> >> /jsm >> >> > Hi > Just FYI > I have managed to cross-compile firefox115-esr on amd64 to aaarhc64 so > that takes me ~20 min compute time to compile as opposed to 5-7 hours on > my arm boards... I think it broke somewhere between 115 and 116, but now > bisecting is doable to the extend the port patches allows. Can someone > btw tell me hove the libwebrtc patches are generated..? > I build and bisected with --disable-webrtc so I did not need the patches for that.. It breaks here: changeset: 743155:5c5cf716aa0b user: Jan de Mooij date: Wed Jun 07 16:34:51 2023 +0000 summary: Bug 1835876 part 2 - Disable code write protection in content processes. r=nbp [root@freebsd2 /tmp3/bisect/mozilla-unified]# hg log -r 743154 changeset: 743154:028f981600d7 user: Jan de Mooij date: Wed Jun 07 16:34:51 2023 +0000 summary: Bug 1835876 part 1 - Remove unused ProtectionSetting::Protected. r=nbp Related to w^x.. I can only make it work by reverting the whole of the two above commits... (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271081#c7) Still disabling aslr is required /Jsm From nobody Sat Dec 16 22:17:14 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 4St0p93ybTz52nvt for ; Sat, 16 Dec 2023 22:17:53 +0000 (UTC) (envelope-from marietto2008@gmail.com) Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [IPv6:2a00:1450:4864:20::62f]) (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 4St0p853nKz3C0k for ; Sat, 16 Dec 2023 22:17:52 +0000 (UTC) (envelope-from marietto2008@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=doQass3o; spf=pass (mx1.freebsd.org: domain of marietto2008@gmail.com designates 2a00:1450:4864:20::62f as permitted sender) smtp.mailfrom=marietto2008@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-ej1-x62f.google.com with SMTP id a640c23a62f3a-a1f8f470903so217644466b.1 for ; Sat, 16 Dec 2023 14:17:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1702765071; x=1703369871; darn=freebsd.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=k3B7BNb8xnjDyZzGYaXM5XDaja5ledbXvZq84Jpsj0s=; b=doQass3oU+HHYGr5TILH4ALcEfA/4toaMgghnfMNAJ7zcFIfgREzn2z8d0DsyBoY25 MONkRZr1l9Y3x7i7qf/IA6LfKTE0Jyl7qhZSVggZXv+zfw37jGOQQFlGqh7RbOzECHQg S8GHPWxm3Mr9ZirVFNo1FP6FSyF8r3Ee3DiKtcwdXXhWjEY+P/S3GQpubxjK0yjTYlCr wXbjdn51nPm66B0Y9Oz1xqfpxth2I4otC/9SLkpeKlK3KMo9DTiuDJVpyj/0M7GDPBj3 OaRYozIbzg87HF6C2UmaXe0/2ZSysgvAJuZnNTExGo++BgH8yNlmmsrEuXktumTVQd75 h2Pw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702765071; x=1703369871; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=k3B7BNb8xnjDyZzGYaXM5XDaja5ledbXvZq84Jpsj0s=; b=MuPwDOuM/+mTBU3qE1UECSnKDU2af+dI3Txto6X2ndUDuCfxnUArXCVzxx1SVrcAr1 Xytig580klaSMC4U/GOF+HOzNvRAaBG7Jc/oGzXU04Hd8RVtV8tW415VoDEHfsuh6QE/ QMcMWj4PxqTRf7erspZtsom4hFXlxp8bNJ9h1piQtbTI5YXuUtnkEysJhS/xFHjZHv1L txdo2AYAzhw59Z1Eyxz48NP4WBxfiDx7CNRzMPXaQr3MlnG550QHhgwFsibdeZ1b9rym Hy7CAuiSO/+I4kh4rcOa2IFNqiuFgqQl3tzJsXV9PYmmcud+Torer5v3HkijyoqlsEEU ThAA== X-Gm-Message-State: AOJu0YwGEm6NCdVjy4LpKSMjw/ptdYZmzsQo5pK+qUVQNkC/kTWqH7Ki j+tMD8I1E2rZcJuCcU+QTl2sM19uyzMxkbgOK4vGkbgJLAM= X-Google-Smtp-Source: AGHT+IFFaqB6yQRF7Pbc5d5kBxpB65lJ0pFSUTcok0WBKOe+zTMP5AQE+yNl25K5IKmXEm29lxhpAAnOCBBTUzqy2EY= X-Received: by 2002:a17:906:a054:b0:a19:a19b:c72f with SMTP id bg20-20020a170906a05400b00a19a19bc72fmr6864693ejb.127.1702765070667; Sat, 16 Dec 2023 14:17:50 -0800 (PST) List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 From: Mario Marietto Date: Sat, 16 Dec 2023 23:17:14 +0100 Message-ID: Subject: How to boot FreeBSD for arm 32 bit as DomU with u-boot on my ARM Chromebook To: freebsd-arm@freebsd.org Content-Type: multipart/alternative; boundary="0000000000002c52af060ca7e3fa" X-Spamd-Result: default: False [-3.97 / 15.00]; NEURAL_HAM_LONG(-0.99)[-0.993]; NEURAL_HAM_MEDIUM(-0.99)[-0.992]; NEURAL_HAM_SHORT(-0.99)[-0.986]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_COUNT_ONE(0.00)[1]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::62f:from]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ARC_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; 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)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-Rspamd-Queue-Id: 4St0p853nKz3C0k X-Spamd-Bar: --- --0000000000002c52af060ca7e3fa Content-Type: text/plain; charset="UTF-8" Hello. I'm trying to boot FreeBSD for arm32 bit as DomU on my ARM Chromebook. Basically there are two ways to accomplish this task : 1) to write a patch that allows the FreeBSD kernel to boot as a zImage file. This could be accomplished applying this patch to a specific file that's on the source code of FreeBSD : https://xenbits.xen.org/gitweb/?p=p...8;hb=0782e25d98cc1391472717035f986c979edef0c9 This patch was written by Julien Grall a lot of time ago and now it does not work anymore. This is the reason : It appears FreeBSD-CURRENT removed the last step converting the kernel file to kernel.bin. The patch can be readily rebased, but without kernel.bin that doesn't do too much. So,without a rebase of that patch the first option is not applicable. And I'm not able to fix it. 2) booting FreeBSD using U-Boot,as explained to me by a xen developer : I was trying to explain why and how Julien's patch works so that you could be the one to re-do something similar or fix the patch on the FreeBSD kernel that you are working with. I am happy to help review and write patches but I don't work with the FreeBSD kernel so I wouldn't be able to help you quickly. However, I might have a suggestion. Do you know if FreeBSD can be booted by U-Boot ? Because U-Boot definitely boots as Xen on ARM guest firmware/bootloader. You should be able to build U-Boot and use the U-Boot binary as Xen guest kernel, then U-Boot could load FreeBSD from disk or network and start it. For instance as domU config file: kernel="/home/petalinux/u-boot.bin" disk = [ '/home/petalinux/test.img,raw,xvda' ] I know it is important to build u-boot with the following config to make it work on Xen. CONFIG_CMO_BY_VA_ONLY=y This option seems more doable to me according to my knowledge. But I need to understand how to do it. Well,let's say that on the ARM Chromebook I'm forced to use and install a customized version of u-boot,created by virtual open systems,because it is the only one that allows bypassing its bootloader protection. You can find more information here : http://www.virtualopensystems.com/en/solutions/guides/kvm-on-chromebook/?vos=tech This is the relevant section to read : Bootloader : If you wish to skip this chapter you can download a pre-compiled binary of the bootloader: $ wget http://www.virtualopensystems.com/downloads/guides/kvm_on_chromebook/nv_u-boot-snow.kpart To be able to run KVM on ARM platforms, the kernel has to be booted in hypervisor mode. Because of this relatively recent requirement (due to the introduction of the virtualization extensions), up until now all booting methods would boot the kernel in the standard Supervisor mode. For the ARM Chromebook the default boot procedure doesn't allow us to boot in hypervisor mode. Although the laptop's boot mechanism is based on the frequently used u-boot, the binary is located in RO memory. Fortunately, a chained u-boot mechanism can be used (i.e. starting another u-boot after the original). We can then enter hypervisor mode from our custom iteration of u-boot and subsequently load our kernel and userspace. Checkout the needed u-boot code : $ git clone git://github.com/virtualopensystems/u-boot.git$ cd u-boot$ ./scripts/build.sh If successful, a message about how to copy the bootloader on the USB flash disk or SD card will appear. We will use it later when preparing the boot medium to start our system. If you have followed the Setting up the boot medium chapter and you have a prepared boot device, then you can update u-boot by running : $ sudo dd if=nv_uboot-snow.kpart of=/dev/sdX1 so,the needed u-boot that we must use should be installed on the first partition of the sd card. There is another relevant section to read : Setting up the boot medium Now it is time to copy all the relevant files that we created in the previous chapters,and use them to boot Chromebook with a different kernel and OS. In all these examples the device /dev/sdX is used. Take extra care to change the examples to the device that you have attached. Insert the boot medium on your workstation and carefully execute the following step. First we need to properly format the boot medium. In the uboot source directory : $ sudo ./scripts/sdcard.sh /dev/sdX This will erase all data and create 4 partitions in the medium, along with copying the u-boot binary to the first partition: Partition 1 = ChromeOS signed binary (V.O.S chained u-boot) Partition 2 = not used Partition 3 = EXT2 partition for u-boot files (uImage and exynos5250-snow.dtb) Partition 4 = EXT4 partition for userspace files With u-boot being copied, next is the kernel image and DTB file. From the kernel source execute : $ mkdir ../mnt/ $ sudo mount /dev/sdX3 ../mnt/ $ sudo cp arch/arm/boot/uImage ../mnt/ $ sudo cp arch/arm/boot/dts/exynos5250-snow.dtb ../mnt/ $ sudo umount /dev/sdX3 Finally, we have to copy the Ubuntu userspace filesystem that we created earlier: $ sudo mount /dev/sdX4 mnt/$ sudo cp -a ./precise/* mnt/$ sudo umount /dev/sdX4 Now,my idea is to chainload the already chain loaded u-boot created by V.O.S to the new u-boot that we need for booting FreeBSD and that can be installed in the partition n.2,as shown in this scheme,because it is not used : Partition 1 = ChromeOS signed binary (V.O.S chained u-boot) Partition 2 = not used (maybe we can install the u-boot for arm 32 bit,compatible with FreeBSD on this partition) Partition 3 = EXT2 partition for u-boot files (uImage and exynos5250-snow.dtb) Partition 4 = EXT4 partition for userspace files Take in consideration that default boot string is hardcoded here,in the snow.h file of the custom u-boot created by VOS : https://github.com/virtualopensyste...18a39b6c177dff58a/include/configs/snow.h#L101 and it needs to be recompiled because it should point to the partition n.2,where I will install the u-boot files as explained here : https://wiki.freebsd.org/arm/Chromebook I have some questions to ask before I start working on this. 1) The xen developer said : You should be able to build U-Boot and use the U-Boot binary as Xen guest kernel... where is the u-boot binary,according to this document ? https://wiki.freebsd.org/arm/Chromebook I don't see it. 2) where is the source code of the file that I can get here : http://commondatastorage.googleapis.com/chromeos-localmirror/distfiles/nv_uboot-snow-simplefb.kpart.bz2 I need the source code if I want to recompile u-boot so that it can point to the partition 4. Maybe it can be found on this link : http://linux-exynos.org/dist/chromebook/nv_uboot/ but it can't be opened.... 3) in this specific scenario the source code of u-boot should run on arm 32 bit,not on arm 64,because I have the Samsung Chromebook "SNOW" model XE303C12,that's powered by a Samsung Exynos 5250 (ARMv7 32 bit Cortex A15) Soc. 4) I'm not sure if I can chainload the customized u-boot created by V.O.S that should be installed on the first partition with the u-boot tailored for booting FreeBSD that should be installed on the partition 2.... 5) the xen developer said that u-boot should be compiled enabling this option : Code: CONFIG_CMO_BY_VA_ONLY=y Well,can you provide some good source that can help me to understand how I can recompile u-boot for FreeBSD ? thanks. -- Mario. --0000000000002c52af060ca7e3fa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
<= div id=3D"gmail-:1ay" class=3D"gmail-a3s gmail-aiL">
Hello.=

I'm trying to boot FreeBSD for arm32 bit as DomU on my ARM Chromebook. = Basically there are two ways to accomplish this task :

1) to write a patch that allows the FreeBSD kernel to boot as a zImage=20 file. This could be accomplished applying this patch to a specific file=20 that's on the source code of FreeBSD :


https://xenbits.xen.org/gitweb/?p=3Dp...8;hb= =3D0782e25d98cc1391472717035f986c979edef0c9


This patch was written by Julien Grall a lot of time ago and now it does no= t work anymore. This is the reason :


=09
=09
It appears FreeBSD-CURRENT removed the last step converting the=20 kernel file to kernel.bin. The patch can be readily rebased, but without kernel.bin that doesn't do too much.
=09


So,without a rebase of that patch the first option is not applicable. And I= 'm not able to fix it.

2) booting FreeBSD using U-Boot,as explained to me by a xen developer :


=09
=09
I was trying to explain why and how Julien's patch works so that you= =20 could be the one to re-do something similar or fix the patch on the=20 FreeBSD kernel that you are working with. I am happy to help review and=20 write patches but I don't work with the FreeBSD kernel so I wouldn'= t be=20 able to help you quickly. However, I might have a suggestion. Do you=20 know if FreeBSD can be booted by U-Boot ? Because U-Boot definitely=20 boots as Xen on ARM guest firmware/bootloader. You should be able to=20 build U-Boot and use the U-Boot binary as Xen guest kernel, then U-Boot=20 could load FreeBSD from disk or network and start it. For instance as=20 domU config file:

kernel=3D"/home/petalinux/u-boot.bin"
disk =3D [ '/home/petalinux/test.img,raw,xvda' ]

I know it is important to build u-boot with the following config to make it= work on Xen.

CONFIG_CMO_BY_VA_ONLY=3Dy
=09


This option seems more doable to me according to my knowledge. But I need t= o understand how to do it.

Well,let's say that on the ARM Chromebook I'm forced to use and ins= tall a customized version of u-boot,created by virtual open systems,because it is the only one that allows bypassing its bootloader protection. You=20 can find more information here :

http:/= /www.virtualopensystems.com/en/solutions/guides/kvm-on-chromebook/?vos=3Dte= ch

This is the relevant section to read :


=09
=09
Bootloader :

If you wish to skip this chapter you can download a pre-compiled binary of = the bootloader:


$ wget http://www.virtualopensystems.com/downloads/guides/kvm_on_chromebook= /nv_u-boot-snow.kpart


To be able to run KVM on ARM platforms, the kernel has to be booted in=20 hypervisor mode. Because of this relatively recent requirement (due to=20 the introduction of the virtualization extensions), up until now all=20 booting methods would boot the kernel in the standard Supervisor mode.=20 For the ARM Chromebook the default boot procedure doesn't allow us to= =20 boot in hypervisor mode. Although the laptop's boot mechanism is based= =20 on the frequently used u-boot, the binary is located in RO memory.=20 Fortunately, a chained u-boot mechanism can be used (i.e. starting=20 another u-boot after the original). We can then enter hypervisor mode=20 from our custom iteration of u-boot and subsequently load our kernel and userspace.

Checkout the needed u-boot code :


$ git clone git://github.com/virtualopens= ystems/u-boot.git$ cd u-boot$ ./scripts/build.sh


If successful, a message about how to copy the bootloader on the USB=20 flash disk or SD card will appear. We will use it later when preparing=20 the boot medium to start our system. If you have followed the Setting up the boot medium chapter and you have a prepared boot device, then you=20 can update u-boot by running :


$ sudo dd if=3Dnv_uboot-snow.kpart of=3D/dev/sdX1
=09


so,the needed u-boot that we must use should be installed on the first part= ition of the sd card.

There is another relevant section to read :


=09
=09
Setting up the boot medium

Now it is time to copy all the relevant files that we created in the=20 previous chapters,and use them to boot Chromebook with a different=20 kernel and OS. In all these examples the device /dev/sdX is used. Take=20 extra care to change the examples to the device that you have attached.=20 Insert the boot medium on your workstation and carefully execute the=20 following step. First we need to properly format the boot medium.

In the uboot source directory :


$ sudo ./scripts/sdcard.sh /dev/sdX


This will erase all data and create 4 partitions in the medium, along with = copying the u-boot binary to the first partition:


Partition 1 =3D ChromeOS signed binary (V.O.S chained u-boot)
Partition 2 =3D not used
Partition 3 =3D EXT2 partition for u-boot files (uImage and exynos5250-snow= .dtb)
Partition 4 =3D EXT4 partition for userspace files


With u-boot being copied, next is the kernel image and DTB file. From the k= ernel source execute :


$ mkdir ../mnt/
$ sudo mount /dev/sdX3 ../mnt/
$ sudo cp arch/arm/boot/uImage ../mnt/
$ sudo cp arch/arm/boot/dts/exynos5250-snow.dtb ../mnt/
$ sudo umount /dev/sdX3


Finally, we have to copy the Ubuntu userspace filesystem that we created ea= rlier:


$ sudo mount /dev/sdX4 mnt/$ sudo cp -a ./precise/* mnt/$ sudo umount /dev/= sdX4
=09


Now,my idea is to chainload the already chain loaded u-boot created by=20 V.O.S to the new u-boot that we need for booting FreeBSD and that can be installed in the partition n.2,as shown in this scheme,because it is=20 not used :


Partition 1 =3D ChromeOS signed binary (V.O.S chained u-boot)
Partition 2 =3D not used (maybe we can install the u-boot for arm 32 bit,co= mpatible with FreeBSD on this partition)
Partition 3 =3D EXT2 partition for u-boot files (uImage and exynos5250-snow= .dtb)
Partition 4 =3D EXT4 partition for userspace files


Take in consideration that default boot string is hardcoded here,in the sno= w.h file of the custom u-boot created by VOS :


https://github.com/virtualopensyste...18a39b6c= 177dff58a/include/configs/snow.h#L101


and it needs to be recompiled because it should point to the partition=20 n.2,where I will install the u-boot files as explained here :


https://wiki.freebsd.org/arm/Chromebook


I have some questions to ask before I start working on this.

1) The xen developer said :


=09
=09
You should be able to build U-Boot and use the U-Boot binary as Xen gues= t kernel...
=09


where is the u-boot binary,according to this document ?

https://wiki.freebsd.org/arm/Chromebook

I don't see it.


2) where is the source code of the file that I can get here :

http://commondatastorage.googleapis.com/ch= romeos-localmirror/distfiles/nv_uboot-snow-simplefb.kpart.bz2

I need the source code if I want to recompile u-boot so that it can point t= o the partition 4.

Maybe it can be found on this link :

http://linux-exynos.org/dist/chromebook/= nv_uboot/

but it can't be opened....


3) in this specific scenario the source code of u-boot should run on arm 32 bit,not on arm 64,because I have the Samsung Chromebook "SNOW"= ; model XE303C12,that's powered by a Samsung Exynos 5250 (ARMv7 32 bit Cortex= =20 A15) Soc.


4) I'm not sure if I can chainload the customized u-boot created by=20 V.O.S that should be installed on the first partition with the u-boot=20 tailored for booting FreeBSD that should be installed on the partition=20 2....


5) the xen developer said that u-boot should be compiled enabling this opti= on :


=09 =09
Code: 

CONFIG_CMO_BY_VA_ONLY=3Dy


Well,can you provide some good source that can help me to understand how I = can recompile u-boot for FreeBSD ? thanks.

--
Mario.
--0000000000002c52af060ca7e3fa-- From nobody Sat Dec 16 23:35: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 4St2Wm2DX3z53dY3 for ; Sat, 16 Dec 2023 23:35:32 +0000 (UTC) (envelope-from stanislav.silnicki@mailgate.us) Received: from mailgate.us (mailgate.us [185.72.246.236]) by mx1.freebsd.org (Postfix) with ESMTP id 4St2Wj6G9fz3HGJ for ; Sat, 16 Dec 2023 23:35:29 +0000 (UTC) (envelope-from stanislav.silnicki@mailgate.us) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=mailgate.us header.s=mail header.b=XkRt98ZO; spf=pass (mx1.freebsd.org: domain of stanislav.silnicki@mailgate.us designates 185.72.246.236 as permitted sender) smtp.mailfrom=stanislav.silnicki@mailgate.us; dmarc=none Received: from localhost (api.telegram.org [192.168.2.1]) by mailgate.us (Postfix) with ESMTPSA id 8A1857A4DC for ; Sun, 17 Dec 2023 02:35:21 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailgate.us; s=mail; t=1702769722; bh=ocCazKnrgkil/JBAVNvj5TTQ+3wBIzWS6ynFSpmYhy8=; h=From:Subject:To:References:Date; b=XkRt98ZONrPornff0N6MlN6PMlTWQHi19b22q73uQvPWGI8hU2gp4C4uhWcoqdfjZ BIYptdOYAhl5w050SDuwDM+nIfB5RcmiE/tGM7yExCiwCqzPGVs+kOPEJGM5G68mi5 Biq+UWrEPAX7GhfM5lA5iboQAlTmZl47VuZ0khqg= Content-Type: multipart/alternative; boundary="----sinikael-?=_1-17027697189480.8312620581783601" From: Stanislav Silnicki Subject: Re: How to boot FreeBSD for arm 32 bit as DomU with u-boot on my ARM Chromebook X-Type: replyAll To: freebsd-arm@freebsd.org User-Agent: Desktop Message-Id: <97aa980b9b44.6eb7f9d5c54e7@mailgate.us> References: Content-Transfer-Encoding: quoted-printable Date: Sat, 16 Dec 2023 23:35:17 +0000 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 X-Spamd-Result: default: False [-3.39 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_SPF_ALLOW(-0.20)[+ip4:185.72.246.236/32]; R_DKIM_ALLOW(-0.20)[mailgate.us:s=mail]; RCVD_NO_TLS_LAST(0.10)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; XM_UA_NO_VERSION(0.01)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_COUNT_ONE(0.00)[1]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; DKIM_TRACE(0.00)[mailgate.us:+]; RCVD_VIA_SMTP_AUTH(0.00)[]; ASN(0.00)[asn:47447, ipnet:185.72.246.0/24, country:DE]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; DMARC_NA(0.00)[mailgate.us]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Queue-Id: 4St2Wj6G9fz3HGJ X-Spamd-Bar: --- ------sinikael-?=_1-17027697189480.8312620581783601 Content-Type: text/plain; format=flowed Content-Transfer-Encoding: 7bit Hi Mario, U-Boot beast is hiding in this den: https://source.denx.de/u-boot/u-boot.git I took a brief look at your post and it seems to me, that option CONFIG_CMO_BY_VA_ONLY is irrelevant to your target armv7 32 bit platform: https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/cpu/armv8/Kconfig?ref_type=heads#L3 As for compiling the u-boot, it is a doable task, given that you understand what you are doing. There are no specific options in u-boot devoted to FreeBSD. It is a boot loader, whose mission to make basic hardware initialization, read you kernel file from some media into RAM and then pass it control. Basically, you can grab some defconfig, prepared for any other Exynos5250 based board (say, this one: https://source.denx.de/u-boot/u-boot/-/blob/master/configs/arndale_defconfig?ref_type=heads) and adopt it somehow. As per my experience, you have to respect these two options, compiling u-boot for FreeBSD: https://github.com/freebsd/freebsd-ports/blob/main/sysutils/u-boot-master/files/FreeBSD_Fragment As I understand, it makes sure, that u-boot keeps in secure mode during boot and passes control to ubldr, which boots FreBSD kernel, in that mode. Otherwise, there a lot of surprises you may realize. Hope, this will help to progress you tasks Stan Mario Marietto wrote: Hello. I'm trying to boot FreeBSD for arm32 bit as DomU on my ARM Chromebook. Basically there are two ways to accomplish this task : 1) to write a patch that allows the FreeBSD kernel to boot as a zImage file. This could be accomplished applying this patch to a specific file that's on the source code of FreeBSD : https://xenbits.xen.org/gitweb/?p=p...8;hb=0782e25d98cc1391472717035f986c979edef0c9 This patch was written by Julien Grall a lot of time ago and now it does not work anymore. This is the reason : It appears FreeBSD-CURRENT removed the last step converting the kernel file to kernel.bin. The patch can be readily rebased, but without kernel.bin that doesn't do too much. So,without a rebase of that patch the first option is not applicable. And I'm not able to fix it. 2) booting FreeBSD using U-Boot,as explained to me by a xen developer : I was trying to explain why and how Julien's patch works so that you could be the one to re-do something similar or fix the patch on the FreeBSD kernel that you are working with. I am happy to help review and write patches but I don't work with the FreeBSD kernel so I wouldn't be able to help you quickly. However, I might have a suggestion. Do you know if FreeBSD can be booted by U-Boot ? Because U-Boot definitely boots as Xen on ARM guest firmware/bootloader. You should be able to build U-Boot and use the U-Boot binary as Xen guest kernel, then U-Boot could load FreeBSD from disk or network and start it. For instance as domU config file: kernel="/home/petalinux/u-boot.bin" disk = [ '/home/petalinux/test.img,raw,xvda' ] I know it is important to build u-boot with the following config to make it work on Xen. CONFIG_CMO_BY_VA_ONLY=y This option seems more doable to me according to my knowledge. But I need to understand how to do it. Well,let's say that on the ARM Chromebook I'm forced to use and install a customized version of u-boot,created by virtual open systems,because it is the only one that allows bypassing its bootloader protection. You can find more information here : http://www.virtualopensystems.com/en/solutions/guides/kvm-on-chromebook/?vos=tech This is the relevant section to read : Bootloader : If you wish to skip this chapter you can download a pre-compiled binary of the bootloader: $ wget http://www.virtualopensystems.com/downloads/guides/kvm_on_chromebook/nv_u-boot-snow.kpart To be able to run KVM on ARM platforms, the kernel has to be booted in hypervisor mode. Because of this relatively recent requirement (due to the introduction of the virtualization extensions), up until now all booting methods would boot the kernel in the standard Supervisor mode. For the ARM Chromebook the default boot procedure doesn't allow us to boot in hypervisor mode. Although the laptop's boot mechanism is based on the frequently used u-boot, the binary is located in RO memory. Fortunately, a chained u-boot mechanism can be used (i.e. starting another u-boot after the original). We can then enter hypervisor mode from our custom iteration of u-boot and subsequently load our kernel and userspace. Checkout the needed u-boot code : $ git clone git://github.com/virtualopensystems/u-boot.git$ cd u-boot$ ./scripts/build.sh If successful, a message about how to copy the bootloader on the USB flash disk or SD card will appear. We will use it later when preparing the boot medium to start our system. If you have followed the Setting up the boot medium chapter and you have a prepared boot device, then you can update u-boot by running : $ sudo dd if=nv_uboot-snow.kpart of=/dev/sdX1 so,the needed u-boot that we must use should be installed on the first partition of the sd card. There is another relevant section to read : Setting up the boot medium Now it is time to copy all the relevant files that we created in the previous chapters,and use them to boot Chromebook with a different kernel and OS. In all these examples the device /dev/sdX is used. Take extra care to change the examples to the device that you have attached. Insert the boot medium on your workstation and carefully execute the following step. First we need to properly format the boot medium. In the uboot source directory : $ sudo ./scripts/sdcard.sh /dev/sdX This will erase all data and create 4 partitions in the medium, along with copying the u-boot binary to the first partition: Partition 1 = ChromeOS signed binary (V.O.S chained u-boot) Partition 2 = not used Partition 3 = EXT2 partition for u-boot files (uImage and exynos5250-snow.dtb) Partition 4 = EXT4 partition for userspace files With u-boot being copied, next is the kernel image and DTB file. From the kernel source execute : $ mkdir ../mnt/ $ sudo mount /dev/sdX3 ../mnt/ $ sudo cp arch/arm/boot/uImage ../mnt/ $ sudo cp arch/arm/boot/dts/exynos5250-snow.dtb ../mnt/ $ sudo umount /dev/sdX3 Finally, we have to copy the Ubuntu userspace filesystem that we created earlier: $ sudo mount /dev/sdX4 mnt/$ sudo cp -a ./precise/* mnt/$ sudo umount /dev/sdX4 Now,my idea is to chainload the already chain loaded u-boot created by V.O.S to the new u-boot that we need for booting FreeBSD and that can be installed in the partition n.2,as shown in this scheme,because it is not used : Partition 1 = ChromeOS signed binary (V.O.S chained u-boot) Partition 2 = not used (maybe we can install the u-boot for arm 32 bit,compatible with FreeBSD on this partition) Partition 3 = EXT2 partition for u-boot files (uImage and exynos5250-snow.dtb) Partition 4 = EXT4 partition for userspace files Take in consideration that default boot string is hardcoded here,in the snow.h file of the custom u-boot created by VOS : https://github.com/virtualopensyste...18a39b6c177dff58a/include/configs/snow.h#L101 and it needs to be recompiled because it should point to the partition n.2,where I will install the u-boot files as explained here : https://wiki.freebsd.org/arm/Chromebook I have some questions to ask before I start working on this. 1) The xen developer said : You should be able to build U-Boot and use the U-Boot binary as Xen guest kernel... where is the u-boot binary,according to this document ? https://wiki.freebsd.org/arm/Chromebook I don't see it. 2) where is the source code of the file that I can get here : http://commondatastorage.googleapis.com/chromeos-localmirror/distfiles/nv_uboot-snow-simplefb.kpart.bz2 I need the source code if I want to recompile u-boot so that it can point to the partition 4. Maybe it can be found on this link : http://linux-exynos.org/dist/chromebook/nv_uboot/ but it can't be opened.... 3) in this specific scenario the source code of u-boot should run on arm 32 bit,not on arm 64,because I have the Samsung Chromebook "SNOW" model XE303C12,that's powered by a Samsung Exynos 5250 (ARMv7 32 bit Cortex A15) Soc. 4) I'm not sure if I can chainload the customized u-boot created by V.O.S that should be installed on the first partition with the u-boot tailored for booting FreeBSD that should be installed on the partition 2.... 5) the xen developer said that u-boot should be compiled enabling this option : Code: CONFIG_CMO_BY_VA_ONLY=y Well,can you provide some good source that can help me to understand how I can recompile u-boot for FreeBSD ? thanks. -- Mario. ------sinikael-?=_1-17027697189480.8312620581783601 Content-Type: text/html; format=flowed Content-Transfer-Encoding: 7bit
Hi Mario,

U-Boot  beast is hiding in this den: https://source.denx.de/u-boot/u-boot.git
I took a brief look at your post and it seems to me, that option CONFIG_CMO_BY_VA_ONLY is irrelevant to your target armv7 32 bit platform: https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/cpu/armv8/Kconfig?ref_type=heads#L3

As for compiling the u-boot, it is a doable task, given that you understand what you are doing. There are no specific options in u-boot devoted to FreeBSD. It is a boot loader, whose mission to make basic hardware initialization, read you kernel file from some media into RAM and then pass it control.

Basically, you can grab some defconfig, prepared for any other Exynos5250 based board  (say, this one: https://source.denx.de/u-boot/u-boot/-/blob/master/configs/arndale_defconfig?ref_type=heads) and adopt it somehow.

As per my experience, you have to respect these two options, compiling u-boot for FreeBSD: https://github.com/freebsd/freebsd-ports/blob/main/sysutils/u-boot-master/files/FreeBSD_Fragment

As I understand, it makes sure, that u-boot keeps in secure mode during boot and passes control to ubldr, which boots FreBSD kernel, in that mode. Otherwise, there a lot of surprises you may realize.

Hope, this will help to progress you tasks
Stan

Mario Marietto wrote:


Hello.

I'm trying to boot FreeBSD for arm32 bit as DomU on my ARM Chromebook. Basically there are two ways to accomplish this task :

1) to write a patch that allows the FreeBSD kernel to boot as a zImage file. This could be accomplished applying this patch to a specific file that's on the source code of FreeBSD :


https://xenbits.xen.org/gitweb/?p=p...8;hb=0782e25d98cc1391472717035f986c979edef0c9


This patch was written by Julien Grall a lot of time ago and now it does not work anymore. This is the reason :


It appears FreeBSD-CURRENT removed the last step converting the kernel file to kernel.bin. The patch can be readily rebased, but without kernel.bin that doesn't do too much.


So,without a rebase of that patch the first option is not applicable. And I'm not able to fix it.

2) booting FreeBSD using U-Boot,as explained to me by a xen developer :


I was trying to explain why and how Julien's patch works so that you could be the one to re-do something similar or fix the patch on the FreeBSD kernel that you are working with. I am happy to help review and write patches but I don't work with the FreeBSD kernel so I wouldn't be able to help you quickly. However, I might have a suggestion. Do you know if FreeBSD can be booted by U-Boot ? Because U-Boot definitely boots as Xen on ARM guest firmware/bootloader. You should be able to build U-Boot and use the U-Boot binary as Xen guest kernel, then U-Boot could load FreeBSD from disk or network and start it. For instance as domU config file:

kernel="/home/petalinux/u-boot.bin"
disk = [ '/home/petalinux/test.img,raw,xvda' ]

I know it is important to build u-boot with the following config to make it work on Xen.

CONFIG_CMO_BY_VA_ONLY=y


This option seems more doable to me according to my knowledge. But I need to understand how to do it.

Well,let's say that on the ARM Chromebook I'm forced to use and install a customized version of u-boot,created by virtual open systems,because it is the only one that allows bypassing its bootloader protection. You can find more information here :

http://www.virtualopensystems.com/en/solutions/guides/kvm-on-chromebook/?vos=tech

This is the relevant section to read :


Bootloader :

If you wish to skip this chapter you can download a pre-compiled binary of the bootloader:


$ wget http://www.virtualopensystems.com/downloads/guides/kvm_on_chromebook/nv_u-boot-snow.kpart


To be able to run KVM on ARM platforms, the kernel has to be booted in hypervisor mode. Because of this relatively recent requirement (due to the introduction of the virtualization extensions), up until now all booting methods would boot the kernel in the standard Supervisor mode. For the ARM Chromebook the default boot procedure doesn't allow us to boot in hypervisor mode. Although the laptop's boot mechanism is based on the frequently used u-boot, the binary is located in RO memory. Fortunately, a chained u-boot mechanism can be used (i.e. starting another u-boot after the original). We can then enter hypervisor mode from our custom iteration of u-boot and subsequently load our kernel and userspace.

Checkout the needed u-boot code :


$ git clone git://github.com/virtualopensystems/u-boot.git$ cd u-boot$ ./scripts/build.sh


If successful, a message about how to copy the bootloader on the USB flash disk or SD card will appear. We will use it later when preparing the boot medium to start our system. If you have followed the Setting up the boot medium chapter and you have a prepared boot device, then you can update u-boot by running :


$ sudo dd if=nv_uboot-snow.kpart of=/dev/sdX1


so,the needed u-boot that we must use should be installed on the first partition of the sd card.

There is another relevant section to read :


Setting up the boot medium

Now it is time to copy all the relevant files that we created in the previous chapters,and use them to boot Chromebook with a different kernel and OS. In all these examples the device /dev/sdX is used. Take extra care to change the examples to the device that you have attached. Insert the boot medium on your workstation and carefully execute the following step. First we need to properly format the boot medium.

In the uboot source directory :


$ sudo ./scripts/sdcard.sh /dev/sdX


This will erase all data and create 4 partitions in the medium, along with copying the u-boot binary to the first partition:


Partition 1 = ChromeOS signed binary (V.O.S chained u-boot)
Partition 2 = not used
Partition 3 = EXT2 partition for u-boot files (uImage and exynos5250-snow.dtb)
Partition 4 = EXT4 partition for userspace files


With u-boot being copied, next is the kernel image and DTB file. From the kernel source execute :


$ mkdir ../mnt/
$ sudo mount /dev/sdX3 ../mnt/
$ sudo cp arch/arm/boot/uImage ../mnt/
$ sudo cp arch/arm/boot/dts/exynos5250-snow.dtb ../mnt/
$ sudo umount /dev/sdX3


Finally, we have to copy the Ubuntu userspace filesystem that we created earlier:


$ sudo mount /dev/sdX4 mnt/$ sudo cp -a ./precise/* mnt/$ sudo umount /dev/sdX4


Now,my idea is to chainload the already chain loaded u-boot created by V.O.S to the new u-boot that we need for booting FreeBSD and that can be installed in the partition n.2,as shown in this scheme,because it is not used :


Partition 1 = ChromeOS signed binary (V.O.S chained u-boot)
Partition 2 = not used (maybe we can install the u-boot for arm 32 bit,compatible with FreeBSD on this partition)
Partition 3 = EXT2 partition for u-boot files (uImage and exynos5250-snow.dtb)
Partition 4 = EXT4 partition for userspace files


Take in consideration that default boot string is hardcoded here,in the snow.h file of the custom u-boot created by VOS :


https://github.com/virtualopensyste...18a39b6c177dff58a/include/configs/snow.h#L101


and it needs to be recompiled because it should point to the partition n.2,where I will install the u-boot files as explained here :


https://wiki.freebsd.org/arm/Chromebook


I have some questions to ask before I start working on this.

1) The xen developer said :


You should be able to build U-Boot and use the U-Boot binary as Xen guest kernel...


where is the u-boot binary,according to this document ?

https://wiki.freebsd.org/arm/Chromebook

I don't see it.


2) where is the source code of the file that I can get here :

http://commondatastorage.googleapis.com/chromeos-localmirror/distfiles/nv_uboot-snow-simplefb.kpart.bz2

I need the source code if I want to recompile u-boot so that it can point to the partition 4.

Maybe it can be found on this link :

http://linux-exynos.org/dist/chromebook/nv_uboot/

but it can't be opened....


3) in this specific scenario the source code of u-boot should run on arm 32 bit,not on arm 64,because I have the Samsung Chromebook "SNOW" model XE303C12,that's powered by a Samsung Exynos 5250 (ARMv7 32 bit Cortex A15) Soc.


4) I'm not sure if I can chainload the customized u-boot created by V.O.S that should be installed on the first partition with the u-boot tailored for booting FreeBSD that should be installed on the partition 2....


5) the xen developer said that u-boot should be compiled enabling this option :


Code: 

CONFIG_CMO_BY_VA_ONLY=y


Well,can you provide some good source that can help me to understand how I can recompile u-boot for FreeBSD ? thanks.
--
Mario.
------sinikael-?=_1-17027697189480.8312620581783601-- From nobody Sat Dec 16 23:56:41 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 4St30w1rvBz53gCp for ; Sat, 16 Dec 2023 23:57:20 +0000 (UTC) (envelope-from marietto2008@gmail.com) Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (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 4St30w0bg1z3JVt for ; Sat, 16 Dec 2023 23:57:20 +0000 (UTC) (envelope-from marietto2008@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-lj1-x22f.google.com with SMTP id 38308e7fff4ca-2cc63b3ed71so6557201fa.3 for ; Sat, 16 Dec 2023 15:57:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1702771038; x=1703375838; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=GsgZ1Z5bC0nl/SV7+k7XO5ltkFALA659Z1grABCfYTs=; b=LtPth+lKrM9vbTcGe4GIhxs2up6Vf/V0e8dMBiO2kg5n8H9QPoLeE5a00M4WuTBSpS mf+22tAqUvFKiIxZ8upU12UjvX5Yt+QC1bdOiYG0N2paksz+GbaxnVdUzoaZRqr457od 6Yb1PjUAaM/11jVI8JuoTw1h1FUzIB37zYVBZK2djgn9CplpF0wMIx3huOwNMQ4QJIgG joaEU4CNuQrCoJgJ+qPnxR4K2QTRC2XHbdT8buhAYUvzykfet4+wBsDDlOhrVWR2uL4i tuBlI2uwHBjKBOe5ZhC6PS10tpMlmD73YXzMa84OQQKe9VtHLzL+HFM7tThKT00D+G+C J6sw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702771038; x=1703375838; 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=GsgZ1Z5bC0nl/SV7+k7XO5ltkFALA659Z1grABCfYTs=; b=tTWW56VnDNymIwPUb857nUWftgdNqQMRhz/+PX15yzghUpQRCSvOpeQ1f0siCbLVzE SBPDS47+Yav5E1JFtorVj1mA+X3tgcCLU99rykhltReNZKRlA3GrjvranrWZyAi4VVSe PQFr2M/PdKFPtDt+lXx9nYEbdt6XCm+YLTMeNJuCT+peBdBDhbfJriomxembIowQAra8 HlesKdz1VTT6aESq44EUlkM1GS1vI+ars5z1N60um+mj1EAMI7BpFBRpNDC2jP9d1GsL Kv1PciAv8BrZ624zefd4HKIujmqaCFq88ARATNYauwkC713WnRKSf2TZeWxbrO6LVceV C96A== X-Gm-Message-State: AOJu0YwxCmIm80IQUyAdfCszehcGainmBjR84mA6MLeyLmKMuZlDixem zqo/+0oOLh90J+krAD6Y/TeHZrNFwA+vSISPt+sOEl2lfbrwAg== X-Google-Smtp-Source: AGHT+IEaxzYPN7WqjwCqqbKwDqfr5YLkYUTBZUb0nIceXfeliaSCcuRLiR9Hi04MYT9OZI7FYLpofg/SHfvSDqnJf7A= X-Received: by 2002:a05:6512:ba8:b0:50c:d30:3a05 with SMTP id b40-20020a0565120ba800b0050c0d303a05mr8893705lfv.25.1702771038023; Sat, 16 Dec 2023 15:57:18 -0800 (PST) List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 References: <97aa980b9b44.6eb7f9d5c54e7@mailgate.us> In-Reply-To: <97aa980b9b44.6eb7f9d5c54e7@mailgate.us> From: Mario Marietto Date: Sun, 17 Dec 2023 00:56:41 +0100 Message-ID: Subject: Re: How to boot FreeBSD for arm 32 bit as DomU with u-boot on my ARM Chromebook To: Stanislav Silnicki Cc: freebsd-arm@freebsd.org Content-Type: multipart/alternative; boundary="000000000000daf264060ca946b2" X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4St30w0bg1z3JVt --000000000000daf264060ca946b2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable ---> As I understand, it makes sure that u-boot keeps in secure mode during boot and passes control to ubldr, which boots FreeBSD kernel, in that mode. Can you elaborate your sentence more ? I know that the bootloader secure mode is bypassed by the virtual open systems u-boot. Are you saying that when the control passes to the second u-boot,it will happen in secure mode,so that the bypass that happened loading the first u-boot,is annulled ? If this is true,maybe can I boot FreeBSD using the virtual-open-system custom u-boot ? Is this compatible with FreeBSD ? Where can I find the u-boot.bin that the xen developer talked about ? thanks bro'. On Sun, Dec 17, 2023 at 12:35=E2=80=AFAM Stanislav Silnicki < stanislav.silnicki@mailgate.us> wrote: > Hi Mario, > > U-Boot beast is hiding in this den: > https://source.denx.de/u-boot/u-boot.git > I took a brief look at your post and it seems to me, that option > CONFIG_CMO_BY_VA_ONLY is irrelevant to your target armv7 32 bit platform: > https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/cpu/armv8/Kco= nfig?ref_type=3Dheads#L3 > > As for compiling the u-boot, it is a doable task, given that you > understand what you are doing. There are no specific options in u-boot > devoted to FreeBSD. It is a boot loader, whose mission to make basic > hardware initialization, read you kernel file from some media into RAM an= d > then pass it control. > > Basically, you can grab some defconfig, prepared for any other Exynos5250 > based board (say, this one: > https://source.denx.de/u-boot/u-boot/-/blob/master/configs/arndale_defcon= fig?ref_type=3Dheads) > and adopt it somehow. > > As per my experience, you have to respect these two options, compiling > u-boot for FreeBSD: > https://github.com/freebsd/freebsd-ports/blob/main/sysutils/u-boot-master= /files/FreeBSD_Fragment > > As I understand, it makes sure, that u-boot keeps in secure mode during > boot and passes control to ubldr, which boots FreBSD kernel, in that mode= . > Otherwise, there a lot of surprises you may realize. > > Hope, this will help to progress you tasks > Stan > > Mario Marietto wrote: > > > Hello. > > I'm trying to boot FreeBSD for arm32 bit as DomU on my ARM Chromebook. > Basically there are two ways to accomplish this task : > > 1) to write a patch that allows the FreeBSD kernel to boot as a zImage > file. This could be accomplished applying this patch to a specific file > that's on the source code of FreeBSD : > > > > https://xenbits.xen.org/gitweb/?p=3Dp...8;hb=3D0782e25d98cc1391472717035f= 986c979edef0c9 > > > > This patch was written by Julien Grall a lot of time ago and now it does > not work anymore. This is the reason : > > > It appears FreeBSD-CURRENT removed the last step converting the kernel > file to kernel.bin. The patch can be readily rebased, but without > kernel.bin that doesn't do too much. > > > > So,without a rebase of that patch the first option is not applicable. And > I'm not able to fix it. > > 2) booting FreeBSD using U-Boot,as explained to me by a xen developer : > > > I was trying to explain why and how Julien's patch works so that you coul= d > be the one to re-do something similar or fix the patch on the FreeBSD > kernel that you are working with. I am happy to help review and write > patches but I don't work with the FreeBSD kernel so I wouldn't be able to > help you quickly. However, I might have a suggestion. Do you know if > FreeBSD can be booted by U-Boot ? Because U-Boot definitely boots as Xen = on > ARM guest firmware/bootloader. You should be able to build U-Boot and use > the U-Boot binary as Xen guest kernel, then U-Boot could load FreeBSD fro= m > disk or network and start it. For instance as domU config file: > > kernel=3D"/home/petalinux/u-boot.bin" > disk =3D [ '/home/petalinux/test.img,raw,xvda' ] > > I know it is important to build u-boot with the following config to make > it work on Xen. > > CONFIG_CMO_BY_VA_ONLY=3Dy > > > > This option seems more doable to me according to my knowledge. But I need > to understand how to do it. > > Well,let's say that on the ARM Chromebook I'm forced to use and install a > customized version of u-boot,created by virtual open systems,because it i= s > the only one that allows bypassing its bootloader protection. You can fin= d > more information here : > > > http://www.virtualopensystems.com/en/solutions/guides/kvm-on-chromebook/?= vos=3Dtech > > This is the relevant section to read : > > > Bootloader : > > If you wish to skip this chapter you can download a pre-compiled binary o= f > the bootloader: > > > $ wget > http://www.virtualopensystems.com/downloads/guides/kvm_on_chromebook/nv_u= -boot-snow.kpart > > > To be able to run KVM on ARM platforms, the kernel has to be booted in > hypervisor mode. Because of this relatively recent requirement (due to th= e > introduction of the virtualization extensions), up until now all booting > methods would boot the kernel in the standard Supervisor mode. For the AR= M > Chromebook the default boot procedure doesn't allow us to boot in > hypervisor mode. Although the laptop's boot mechanism is based on the > frequently used u-boot, the binary is located in RO memory. Fortunately, = a > chained u-boot mechanism can be used (i.e. starting another u-boot after > the original). We can then enter hypervisor mode from our custom iteratio= n > of u-boot and subsequently load our kernel and userspace. > > Checkout the needed u-boot code : > > > $ git clone git://github.com/virtualopensystems/u-boot.git$ cd u-boot$ > ./scripts/build.sh > > > If successful, a message about how to copy the bootloader on the USB flas= h > disk or SD card will appear. We will use it later when preparing the boot > medium to start our system. If you have followed the Setting up the boot > medium chapter and you have a prepared boot device, then you can update > u-boot by running : > > > $ sudo dd if=3Dnv_uboot-snow.kpart of=3D/dev/sdX1 > > > > so,the needed u-boot that we must use should be installed on the first > partition of the sd card. > > There is another relevant section to read : > > > Setting up the boot medium > > Now it is time to copy all the relevant files that we created in the > previous chapters,and use them to boot Chromebook with a different kernel > and OS. In all these examples the device /dev/sdX is used. Take extra car= e > to change the examples to the device that you have attached. Insert the > boot medium on your workstation and carefully execute the following step. > First we need to properly format the boot medium. > > In the uboot source directory : > > > $ sudo ./scripts/sdcard.sh /dev/sdX > > > This will erase all data and create 4 partitions in the medium, along wit= h > copying the u-boot binary to the first partition: > > > Partition 1 =3D ChromeOS signed binary (V.O.S chained u-boot) > Partition 2 =3D not used > Partition 3 =3D EXT2 partition for u-boot files (uImage and > exynos5250-snow.dtb) > Partition 4 =3D EXT4 partition for userspace files > > > With u-boot being copied, next is the kernel image and DTB file. From the > kernel source execute : > > > $ mkdir ../mnt/ > $ sudo mount /dev/sdX3 ../mnt/ > $ sudo cp arch/arm/boot/uImage ../mnt/ > $ sudo cp arch/arm/boot/dts/exynos5250-snow.dtb ../mnt/ > $ sudo umount /dev/sdX3 > > > Finally, we have to copy the Ubuntu userspace filesystem that we created > earlier: > > > $ sudo mount /dev/sdX4 mnt/$ sudo cp -a ./precise/* mnt/$ sudo umount > /dev/sdX4 > > > > Now,my idea is to chainload the already chain loaded u-boot created by > V.O.S to the new u-boot that we need for booting FreeBSD and that can be > installed in the partition n.2,as shown in this scheme,because it is not > used : > > > Partition 1 =3D ChromeOS signed binary (V.O.S chained u-boot) > Partition 2 =3D not used (maybe we can install the u-boot for arm 32 > bit,compatible with FreeBSD on this partition) > Partition 3 =3D EXT2 partition for u-boot files (uImage and > exynos5250-snow.dtb) > Partition 4 =3D EXT4 partition for userspace files > > > Take in consideration that default boot string is hardcoded here,in the > snow.h file of the custom u-boot created by VOS : > > > > https://github.com/virtualopensyste...18a39b6c177dff58a/include/configs/s= now.h#L101 > > > > and it needs to be recompiled because it should point to the partition > n.2,where I will install the u-boot files as explained here : > > > https://wiki.freebsd.org/arm/Chromebook > > > I have some questions to ask before I start working on this. > > 1) The xen developer said : > > > You should be able to build U-Boot and use the U-Boot binary as Xen guest > kernel... > > > > where is the u-boot binary,according to this document ? > > https://wiki.freebsd.org/arm/Chromebook > > I don't see it. > > > 2) where is the source code of the file that I can get here : > > > http://commondatastorage.googleapis.com/chromeos-localmirror/distfiles/nv= _uboot-snow-simplefb.kpart.bz2 > > I need the source code if I want to recompile u-boot so that it can point > to the partition 4. > > Maybe it can be found on this link : > > http://linux-exynos.org/dist/chromebook/nv_uboot/ > > but it can't be opened.... > > > 3) in this specific scenario the source code of u-boot should run on arm > 32 bit,not on arm 64,because I have the Samsung Chromebook "SNOW" model > XE303C12,that's powered by a Samsung Exynos 5250 (ARMv7 32 bit Cortex A15= ) > Soc. > > > 4) I'm not sure if I can chainload the customized u-boot created by V.O.S > that should be installed on the first partition with the u-boot tailored > for booting FreeBSD that should be installed on the partition 2.... > > > 5) the xen developer said that u-boot should be compiled enabling this > option : > > > Code: > > CONFIG_CMO_BY_VA_ONLY=3Dy > > > > Well,can you provide some good source that can help me to understand how = I > can recompile u-boot for FreeBSD ? thanks. > > -- > Mario. > > --=20 Mario. --000000000000daf264060ca946b2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
---> As=20 I understand, it makes sure that u-boot keeps in secure mode during boot=20 and passes control to ubldr, which boots FreeBSD kernel, in that mode.

Can you elaborate your sentence more ? I know that the= bootloader secure mode is bypassed by the virtual open systems u-boot. Are= you saying that when the control passes to the second u-boot,it will happe= n in secure mode,so that the bypass that happened loading the first u-boot,= is annulled ? If this is true,maybe can I boot FreeBSD using the virtual-op= en-system custom u-boot ? Is this compatible with FreeBSD ? Where can I fin= d the u-boot.bin that the xen developer talked about ? thanks bro'.



On Sun, Dec 17, 2023 at 12:35=E2=80=AFAM S= tanislav Silnicki <sta= nislav.silnicki@mailgate.us> wrote:
=20 =20 =20 =20 =20 =20 =20
=20 =20 =20 =20 =20 =20 =20
Hi=20 Mario,

U-Boot=C2=A0 beas= t is=20 hiding in this den: https://source.denx.de/u-boot/u-boot.git
I took a brief look at your post and it seems to me, that=20 option=C2=A0CONFIG_CMO_BY_VA_ONLY=C2=A0is irrelevant to=20 your target armv7 32 bit=20 platform:=C2=A0https:/= /source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/cpu/armv8/Kconfig?ref_= type=3Dheads#L3

As=20 for compiling the u-boot, it is a doable task, given that you understand=20 what you are doing. There are no specific options in u-boot devoted to=20 FreeBSD. It is a boot loader, whose mission to make basic hardware=20 initialization, read you kernel file from some media into RAM and then pass= =20 it control.

Basi= cally, you can grab some defconfig,=20 prepared for any other Exynos5250 based board=C2=A0 (say, this one: https://source.denx.de/u-boot/u-= boot/-/blob/master/configs/arndale_defconfig?ref_type=3Dheads)=20 and adopt it somehow.

As per my experience, you have to respect=20 these two options, compiling u-boot for FreeBSD:=C2=A0https://github.com/freebsd/freebsd-ports/blo= b/main/sysutils/u-boot-master/files/FreeBSD_Fragment

As=20 I understand, it makes sure, that u-boot keeps in secure mode during boot= =20 and passes control to ubldr, which boots FreBSD kernel, in that mode.=20 Otherwise, there a lot of surprises you may realize.

Hope, this=20 will help to progress you tasks
Stan

Mario=20 Marietto wrote:


Hello.

I'm trying to boot FreeBSD for arm32 bit as DomU on my ARM Chromebook.= =20 Basically there are two ways to accomplish this task :

1) to write a patch that allows the FreeBSD kernel to boot as a zImage=20 file. This could be accomplished applying this patch to a specific file=20 that's on the source code of FreeBSD :


https://xenbits.xen.org/gitweb/?p=3Dp...8;hb= =3D0782e25d98cc1391472717035f986c979edef0c9


This patch was written by Julien Grall a lot of time ago and now it does=20 not work anymore. This is the reason :


=09
=09
It appears FreeBSD-CURRENT removed the last step converting the=20 kernel file to kernel.bin. The patch can be readily rebased, but without kernel.bin that doesn't do too much.
=09


So,without a rebase of that patch the first option is not applicable. And= =20 I'm not able to fix it.

2) booting FreeBSD using U-Boot,as explained to me by a xen developer :


=09
=09
I was trying to explain why and how Julien's patch works so that you= =20 could be the one to re-do something similar or fix the patch on the=20 FreeBSD kernel that you are working with. I am happy to help review and=20 write patches but I don't work with the FreeBSD kernel so I wouldn'= t be=20 able to help you quickly. However, I might have a suggestion. Do you=20 know if FreeBSD can be booted by U-Boot ? Because U-Boot definitely=20 boots as Xen on ARM guest firmware/bootloader. You should be able to=20 build U-Boot and use the U-Boot binary as Xen guest kernel, then U-Boot=20 could load FreeBSD from disk or network and start it. For instance as=20 domU config file:

kernel=3D"/home/petalinux/u-boot.bin"
disk =3D [ '/home/petalinux/test.img,raw,xvda' ]

I know it is important to build u-boot with the following config to make it= =20 work on Xen.

CONFIG_CMO_BY_VA_ONLY=3Dy
=09


This option seems more doable to me according to my knowledge. But I need= =20 to understand how to do it.

Well,let's say that on the ARM Chromebook I'm forced to use and ins= tall a customized version of u-boot,created by virtual open systems,because it is the only one that allows bypassing its bootloader protection. You=20 can find more information here :

http:/= /www.virtualopensystems.com/en/solutions/guides/kvm-on-chromebook/?vos=3Dte= ch

This is the relevant section to read :


=09
=09
Bootloader :

If you wish to skip this chapter you can download a pre-compiled binary of= =20 the bootloader:


$ wget http://www.virtualopensystems.com/downloads/guides/kvm_on_chromebook= /nv_u-boot-snow.kpart


To be able to run KVM on ARM platforms, the kernel has to be booted in=20 hypervisor mode. Because of this relatively recent requirement (due to=20 the introduction of the virtualization extensions), up until now all=20 booting methods would boot the kernel in the standard Supervisor mode.=20 For the ARM Chromebook the default boot procedure doesn't allow us to= =20 boot in hypervisor mode. Although the laptop's boot mechanism is based= =20 on the frequently used u-boot, the binary is located in RO memory.=20 Fortunately, a chained u-boot mechanism can be used (i.e. starting=20 another u-boot after the original). We can then enter hypervisor mode=20 from our custom iteration of u-boot and subsequently load our kernel and userspace.

Checkout the needed u-boot code :


$ git clone git://github.com/virtualopensystems/u-boot.git$ c= d=20 u-boot$ ./scripts/build.sh


If successful, a message about how to copy the bootloader on the USB=20 flash disk or SD card will appear. We will use it later when preparing=20 the boot medium to start our system. If you have followed the Setting up the boot medium chapter and you have a prepared boot device, then you=20 can update u-boot by running :


$ sudo dd if=3Dnv_uboot-snow.kpart of=3D/dev/sdX1
=09


so,the needed u-boot that we must use should be installed on the first=20 partition of the sd card.

There is another relevant section to read :


=09
=09
Setting up the boot medium

Now it is time to copy all the relevant files that we created in the=20 previous chapters,and use them to boot Chromebook with a different=20 kernel and OS. In all these examples the device /dev/sdX is used. Take=20 extra care to change the examples to the device that you have attached.=20 Insert the boot medium on your workstation and carefully execute the=20 following step. First we need to properly format the boot medium.

In the uboot source directory :


$ sudo ./scripts/sdcard.sh /dev/sdX


This will erase all data and create 4 partitions in the medium, along with= =20 copying the u-boot binary to the first partition:


Partition 1 =3D ChromeOS signed binary (V.O.S chained u-boot)
Partition 2 =3D not used
Partition 3 =3D EXT2 partition for u-boot files (uImage and=20 exynos5250-snow.dtb)
Partition 4 =3D EXT4 partition for userspace files


With u-boot being copied, next is the kernel image and DTB file. From the= =20 kernel source execute :


$ mkdir ../mnt/
$ sudo mount /dev/sdX3 ../mnt/
$ sudo cp arch/arm/boot/uImage ../mnt/
$ sudo cp arch/arm/boot/dts/exynos5250-snow.dtb ../mnt/
$ sudo umount /dev/sdX3


Finally, we have to copy the Ubuntu userspace filesystem that we created=20 earlier:


$ sudo mount /dev/sdX4 mnt/$ sudo cp -a ./precise/* mnt/$ sudo umount=20 /dev/sdX4
=09


Now,my idea is to chainload the already chain loaded u-boot created by=20 V.O.S to the new u-boot that we need for booting FreeBSD and that can be installed in the partition n.2,as shown in this scheme,because it is=20 not used :


Partition 1 =3D ChromeOS signed binary (V.O.S chained u-boot)
Partition 2 =3D not used (maybe we can install the u-boot for arm 32=20 bit,compatible with FreeBSD on this partition)
Partition 3 =3D EXT2 partition for u-boot files (uImage and=20 exynos5250-snow.dtb)
Partition 4 =3D EXT4 partition for userspace files


Take in consideration that default boot string is hardcoded here,in the=20 snow.h file of the custom u-boot created by VOS :


https://github.com/virtualopensyste...18a39b6c= 177dff58a/include/configs/snow.h#L101


and it needs to be recompiled because it should point to the partition=20 n.2,where I will install the u-boot files as explained here :


https://wiki.freebsd.org/arm/Chromebook


I have some questions to ask before I start working on this.

1) The xen developer said :


=09
=09
You should be able to build U-Boot and use the U-Boot binary as Xen=20 guest kernel...
=09


where is the u-boot binary,according to this document ?

https://wiki.freebsd.org/arm/Chromebook

I don't see it.


2) where is the source code of the file that I can get here :

http://commondatastorage.googleapis.com/chromeos-localmirror/dist= files/nv_uboot-snow-simplefb.kpart.bz2

I need the source code if I want to recompile u-boot so that it can point= =20 to the partition 4.

Maybe it can be found on this link :

http://linux-exynos.org/dist/chromebook/nv_= uboot/

but it can't be opened....


3) in this specific scenario the source code of u-boot should run on arm 32 bit,not on arm 64,because I have the Samsung Chromebook "SNOW&quo= t; model XE303C12,that's powered by a Samsung Exynos 5250 (ARMv7 32 bit Cortex= =20 A15) Soc.


4) I'm not sure if I can chainload the customized u-boot created by=20 V.O.S that should be installed on the first partition with the u-boot=20 tailored for booting FreeBSD that should be installed on the partition=20 2....


5) the xen developer said that u-boot should be compiled enabling this=20 option :


=09 =09
Code: 

CONFIG_CMO_BY_VA_ONLY=3Dy


Well,can you provide some good source that can help me to understand how I= =20 can recompile u-boot for FreeBSD ?=20 thanks.

=
--
Mario.
=20 =20 =20
=20 =20


--
Mario.
--000000000000daf264060ca946b2--