From owner-freebsd-arm@freebsd.org Sun Feb 17 12:56:17 2019 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 31F2714F222F for ; Sun, 17 Feb 2019 12:56:17 +0000 (UTC) (envelope-from freebsdnewbie@freenet.de) Received: from mout3.freenet.de (mout3.freenet.de [195.4.92.93]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (Client CN "*.freenet.de", Issuer "TeleSec ServerPass Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C0C506D6B5 for ; Sun, 17 Feb 2019 12:56:15 +0000 (UTC) (envelope-from freebsdnewbie@freenet.de) Received: from [195.4.92.164] (helo=mjail1.freenet.de) by mout3.freenet.de with esmtpa (ID freebsdnewbie@freenet.de) (port 25) (Exim 4.90_1 #2) id 1gvLzH-0001ty-BJ for freebsd-arm@freebsd.org; Sun, 17 Feb 2019 13:56:03 +0100 Received: from [::1] (port=59402 helo=mjail1.freenet.de) by mjail1.freenet.de with esmtpa (ID freebsdnewbie@freenet.de) (Exim 4.90_1 #2) id 1gvLzH-0003FX-AT for freebsd-arm@freebsd.org; Sun, 17 Feb 2019 13:56:03 +0100 Received: from sub4.freenet.de ([195.4.92.123]:35074) by mjail1.freenet.de with esmtpa (ID freebsdnewbie@freenet.de) (Exim 4.90_1 #2) id 1gvLwh-0001PO-7z for freebsd-arm@freebsd.org; Sun, 17 Feb 2019 13:53:23 +0100 Received: from p4fd9f72e.dip0.t-ipconnect.de ([79.217.247.46]:19866 helo=freebsd-t450.fritz.box) by sub4.freenet.de with esmtpsa (ID freebsdnewbie@freenet.de) (TLSv1.2:ECDHE-RSA-CHACHA20-POLY1305:256) (port 587) (Exim 4.90_1 #2) id 1gvLwh-0006x0-5S for freebsd-arm@freebsd.org; Sun, 17 Feb 2019 13:53:23 +0100 Date: Sun, 17 Feb 2019 13:53:21 +0100 From: Manuel =?iso-8859-15?Q?St=FChn?= To: freebsd-arm@freebsd.org Subject: [BBB] NanoBSD ubldr problems Message-ID: <20190217125321.GA30529@freebsd-t450.fritz.box> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline User-Agent: Mutt/1.11.2 (2019-01-07) X-Originated-At: 79.217.247.46!19866 X-Rspamd-Queue-Id: C0C506D6B5 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of freebsdnewbie@freenet.de designates 195.4.92.93 as permitted sender) smtp.mailfrom=freebsdnewbie@freenet.de X-Spamd-Result: default: False [-2.67 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_FIVE(0.00)[5]; RECEIVED_SPAMHAUS_PBL(0.00)[46.247.217.79.zen.spamhaus.org : 127.0.0.10]; FROM_HAS_DN(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[93.92.4.195.rep.mailspike.net : 127.0.0.18]; R_SPF_ALLOW(-0.20)[+ip4:195.4.92.0/23]; FREEMAIL_FROM(0.00)[freenet.de]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[freenet.de]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-0.97)[-0.970,0]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MX_GOOD(-0.01)[emig.freenet.de,emig.freenet.de,emig.freenet.de,emig.freenet.de]; NEURAL_HAM_SHORT(-0.39)[-0.387,0]; NEURAL_HAM_MEDIUM(-0.90)[-0.900,0]; IP_SCORE(-0.00)[country: DE(-0.01)]; RCVD_IN_DNSWL_LOW(-0.10)[93.92.4.195.list.dnswl.org : 127.0.5.1]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[freenet.de]; ASN(0.00)[asn:5430, ipnet:195.4.0.0/16, country:DE]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Feb 2019 12:56:17 -0000 Hi, I'm having some trouble getting plain NanoBSD running on an beaglebone black. Eventually I've got it working by making these two changes: 1. switch partitions NANO_SLICE_CFG from s2 to s3 and NANO_SLICE_ROOT from s3 to s2 in nanobsd/embedded/common 2. mark fat-partition active during mkimg for std-embedded NANO_LAYOUT The switch of partitions is necessary, because ubldr seems to not boot kernels from partitions other than ${DISK}s2 out of the box. Setting loaderdev does not help because ubldr has some issues; by using two different structs (disk_devdesc and uboot_devdesc) synonymously for providing slice and partition information down a call stack and not defining them as packed, padding prevents correct information transport. See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233097 Even with these changes applied, ubldr does not boot the s3-slice which contains the rootfs in default nanobsd-config, but tries s2 (conf) which fails because conf does not contain any kernel. I read in the source comments that ubldr will prioritise those partitions containing active flag in mbr-based disks over those without, but it is neccessary to mark the FAT-slice active because the BBB-ROM-loader will not boot u-boot because it checks for an active FAT-partition to find MLO and stuff. Setting loaderdev to "disk 0:3.0" in uboot helps, but trying to make it permanent via uEnv.txt does not work. Isn't uEnv.txt evaluated? As far as I understand, the boot does only work if the rootfs is located in the first slice to probe by ubldr, correct? How does the described update procedure (image-ping-pong) for arm NanoBSD work then?