From owner-freebsd-arm@freebsd.org Mon Feb 6 06:17:10 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0B910CD37A4 for ; Mon, 6 Feb 2017 06:17:10 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CB059128F for ; Mon, 6 Feb 2017 06:17:09 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x22d.google.com with SMTP id j13so58657029iod.3 for ; Sun, 05 Feb 2017 22:17:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=GclDmnw5ftqxSkz4Im/uu+hHCpN/XKv/KxSNBhwZ/nY=; b=YQPc8fH1/G+1Fm/TszWvtob4wOZfr7NKEeGMBaKP+XJvdsDDKI6j6JG6qYgEDgr8h8 1RqnLTsDUhSGVb7wVp0uc8XEbiZHU34tpsoyQ3P8KmiOs8GUheCuL1UeW4UJlA1oPKOu s6qQhjYSXMSvQlZib8zfINgEHYAvkKGewY7HahQIfzwfwkc52q2MVVP/OYOpa7NWOU6E oV9ReDVPkrTFNjTj2rZrWfGCHSv7Svi4AlKYe25lbZ8ZO/c/LdF2BUiqroKHdekegZ3I D5Sp0HZMQd0KENblpXt0ybeDHSDQTL2WyT1+T8lFVSUS/6Qp/4GwWjyuFWMkUc9Y27OW 34JA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=GclDmnw5ftqxSkz4Im/uu+hHCpN/XKv/KxSNBhwZ/nY=; b=bc9war/DYJrocCfVdK1nKCYxoLvj/KboMwFhfCYpPhxQlD4ZfiOTLN7xk60d3Rywzy MCfyXqrtQmxPoDWLsOxuyx3+aiESzdTh4N8G9GoKtTRlTFAzNbBB5bsaixogSjeenXQo c46B0Johbg5BdpNMJEGYHHbjkEvudaKcWx4g2Tf82Y6CMIillGCX6+dAJ4ml13kSKCk6 06Pn4toPmYRvuIM6JxjBRtbBvxyriAMsdFNFSfM+l8xUv0AE0WSN0IbMqgXUvF1Gr6NL H3AUHSKGccW/ZkB31nHWEsjTcBWOhNokz8L4PwfOUEb7dUqQcu1dSJGGph+fURpBwpPR 4pBw== X-Gm-Message-State: AMke39nisNi9pL6cjeLM815p2KTnTVnKDd5qSecckAZ27V24QAIK8mDQ4WCHFUFPfTNGtf3tQ90YZuCoP6W21w== X-Received: by 10.107.20.13 with SMTP id 13mr5693982iou.0.1486361827891; Sun, 05 Feb 2017 22:17:07 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.145.217 with HTTP; Sun, 5 Feb 2017 22:17:07 -0800 (PST) X-Originating-IP: [50.253.99.174] In-Reply-To: References: <69c5a012-c1e7-c887-cd3b-ffcf78d8175e@denninger.net> <506d5c30-93f7-048e-2cde-d76bfaf76a8f@denninger.net> <1892E365-966E-4DFA-8DE0-9BAD584754A1@dsl-only.net> <41e02f9b-7884-1eec-b4e0-a32c962642b9@denninger.net> From: Warner Losh Date: Sun, 5 Feb 2017 23:17:07 -0700 X-Google-Sender-Auth: 0FZ7xnJwxVuksD3G3BY6gDua_d4 Message-ID: Subject: Re: NanoBSD config script for RPI2 To: Karl Denninger Cc: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 06:17:10 -0000 BTW, try r313326. It will fix the mkimg issues as well as the NANO_ROOT issue. It seems to work for me here locally, and corrects a few other issues that were lurking. Warner On Sun, Feb 5, 2017 at 3:57 PM, Warner Losh wrote: > On Sun, Feb 5, 2017 at 2:22 PM, Karl Denninger wrote: >> On 2/5/2017 10:53, Karl Denninger wrote: >>> On 2/4/2017 15:02, Mark Millard wrote: >>>> On 2017-Feb-4, at 10:56 AM, Karl Denninger >>> > wrote: >>>> >>>>> On 2/4/2017 10:38, Warner Losh wrote: >>>>>> On Sat, Feb 4, 2017 at 5:55 AM, Karl Denninger >>>>> denninger.net > wrote: >>>>>>> It fails here during image create.... >>>>>>> >>>>>>> Populating `/pics/CrossBuild/embedded/rpi2/_.s2' >>>>>>> Image `/pics/CrossBuild/embedded/rpi2/_.s2' complete >>>>>>> + [ -n s1 ] >>>>>>> + eval 's1=fat16b' >>>>>>> + s1=fat16b >>>>>>> + out=/pics/CrossBuild/embedded/images/_.disk.image.HD-MCP >>>>>>> + mkimg -a 3 -s mbr -p 'fat16b:=/pics/CrossBuild/embedded/rpi2/_.s1' -p >>>>>>> 'freebsd >>>>>>> :=/pics/CrossBuild/embedded/rpi2/_.s2' -p >>>>>>> 'freebsd:=/pics/CrossBuild/embedded/rp >>>>>>> i2/_.s3' -o /pics/CrossBuild/embedded/images/_.disk.image.HD-MCP >>>>>>> mkimg: invalid option -- a >>>>>>> mkimg: error: unknown option >>>>>>> >>>>>>> usage: mkimg >>>>>>> options: >>>>>>> --formats - list image formats >>>>>>> --schemes - list partition schemes >>>>>>> --version - show version information >>>>>>> >>>>>>> -b - file containing boot code >>>>>>> -c - capacity (in bytes) of the disk >>>>>>> -f >>>>>>> -o - file to write image into >>>>>>> -p >>>>>>> -s >>>>>>> -v - increase verbosity >>>>>>> -y - [developers] enable unit test >>>>>>> -H - number of heads to simulate >>>>>>> -P - physical sector size >>>>>>> -S - logical sector size >>>>>>> -T - number of tracks to simulate >>>>>>> >>>>>>> formats: >>>>>>> qcow - QEMU Copy-On-Write, version 1 >>>>>>> qcow2 - QEMU Copy-On-Write, version 2 >>>>>>> raw - Raw Disk >>>>>>> vhd - Virtual Hard Disk >>>>>>> vhdf - Fixed Virtual Hard Disk >>>>>>> vmdk - Virtual Machine Disk >>>>>>> >>>>>>> schemes: >>>>>>> apm - Apple Partition Map >>>>>>> bsd - BSD disk label >>>>>>> ebr - Extended Boot Record >>>>>>> gpt - GUID Partition Table >>>>>>> mbr - Master Boot Record >>>>>>> pc98 - PC-9800 disk partitions >>>>>>> vtoc8 - SMI VTOC8 disk labels >>>>>>> >>>>>>> Is the "-a" flag attempting to set the active partition? It appears >>>>>>> there's no option to do that in mkimg... >>>>>> Install a newer mkimg: >>>>>> >>>>>> Revision 307550 - (view) (download) (annotate) - [select for diffs] >>>> https://svnweb.freebsd.org/base/?pathrev=312669 shows that >>>> -r3125699 is from head. >>>> >>>> Looking around: stable/11 has not been updated for its mkimg. only >>>> head has -a added at this point. >>>> >>>>>> Modified Tue Oct 18 05:43:12 2016 UTC (3 months, 2 weeks ago) by imp >>>>>> File length: 3730 byte(s) >>>>>> Diff to previous 307544 >>>>>> >>>>>> Add a new flag to mkimg (-a num) to specify the active partition for >>>>>> those partitioning schemes that have this concept. Implement it as an >>>>>> override for mbr's setting 0x80 in the flags for the first partition >>>>>> when we have boot code. >>>>>> >>>>>> Differential Revision: https://reviews.freebsd.org/D4403 >>>>>> >>>>>> Though maybe I should try to add it to the bootstrap tools so I can >>>>>> use a new one after the build. >>>>>> >>>>>> Warner >>>>>> >>>>> root@NewFS:/disk/karl # uname -v >>>>> FreeBSD 11.0-STABLE #15 r312669M: Mon Jan 23 14:01:03 CST 2017 >>>> https://svnweb.freebsd.org/base/?pathrev=312669 shows that >>>> -r3125699 is from head, not from stable/11 . >>>> >>>> If you have a mix of head and stable/11 materials with mkimg from >>>> stable/11 then -a will not be present for mkimg. >>>> >>>>> karl@NewFS.denninger.net >>>>> :/usr/obj/usr/src/sys/KSD-SMP >>>>> root@NewFS:/disk/karl # which mkimg >>>>> /usr/bin/mkimg >>>>> root@NewFS:/disk/karl # pkg install mkimg >>>>> Updating FreeBSD repository catalogue... >>>>> FreeBSD repository is up-to-date. >>>>> All repositories are up-to-date. >>>>> pkg: No packages available to install matching 'mkimg' have been found >>>>> in the repositories >>>>> root@NewFS:/disk/karl # >>>>> >>>>> So.... it's part of base and there is no obvious package (a check for >>>>> ports in */*mkimg* fails too); my system is current as of Jan 23.... >>>>> >>>>> (As an aside I think if I remove the -a it may work on the Pi, since the >>>>> Pi will try to boot the first partition which happens to be DOS -- I >>>>> think. I'll try it.) >>>>> >>>>> -- >>>>> Karl Denninger >>>>> karl@denninger.net >>>> denninger.net > >>>>> /The Market Ticker/ >>>>> /[S/MIME encrypted email preferred]/ >>>> >>>> === >>>> Mark Millard >>>> markmi at dsl-only.net >>>> >>> Manually setting the third partition to active does work to boot, but >>> the default partition settings for root and cfg are also wrong; you need >>> these overrides or the mount of root fails on startup: >>> >>> # >>> # Partition layout for the Pi2 is: >>> # 1 = FAT16 boot (MSDOS) containing bootcode, ubldr, etc. >>> # 2 = CFG >>> # 3 = Root (must be separately marked active so ubldr can find it) >>> # 4 = Altroot >>> # >>> NANO_SLICE_CFG=s2 >>> NANO_SLICE_ROOT=s3 >>> NANO_SLICE_ALTROOT=s4 >>> NANO_ROOT=s3a >>> NANO_ALTROOT=s4a >>> >>> I'm working on some other issues but this allows the unit to boot up and >>> start. You do need to mark the partition active manually but there's a >>> workaround for the need to do that manually -- mount the image after >>> it's built in "common" and set the active flag using gpart: >>> >>> mdi=`mdconfig -f _.disk.image......` >>> gpart set -a active -i 3 $mdi >>> mdconfig -d -u $mdi >>> >>> Which works if used in place of the "-a...." argument to the mkimg >>> command. Perhaps this should be changed in the "common" script and made >>> the general case, at least for 11-STABLE and before, since it should >>> work with pretty-much any version of FreeBSD and obviates the need for >>> the updated mkimg. As things stand right now a checkout of 11-STABLE >>> has a common script that relies on an updated mkimg that isn't present >>> in the system and thus will//not work. >>> >>> This is what I changed in common: >>> >>> case ${NANO_LAYOUT} in >>> std-embedded) >>> # mkimg -a 3 ${skiparg} ${fmtarg} ${bootmbr} -s mbr -p >>> ${s1}:=${NANO_LOG}/_.s1 \ >>> mkimg ${skiparg} ${fmtarg} ${bootmbr} -s mbr -p >>> ${s1}:=${NANO_LOG}/_.s1 \ >>> -p ${s2}:=${NANO_LOG}/_.s2 \ >>> -p ${s3}:=${NANO_LOG}/_.s3 \ >>> -o ${out} >>> mdi=`mdconfig -f ${out}` >>> gpart show $mdi >>> gpart set -a active -i 3 $mdi >>> gpart show $mdi >>> mdconfig -d -u $mdi >>> ;; >>> >>> The two "shows" are (obviously) not necessary but result in log output >>> that shows the active flag successfully set. >>> >>> Partial output from _.di incorporating this change: >>> >>> Populating `/pics/CrossBuild/embedded/rpi2/_.s2' >>> Image `/pics/CrossBuild/embedded/rpi2/_.s2' complete >>> + [ -n s1 ] >>> + eval 's1=fat16b' >>> + s1=fat16b >>> + out=/pics/CrossBuild/embedded/images/_.disk.image.HD-MCP >>> + mkimg -s mbr -p 'fat16b:=/pics/CrossBuild/embedded/rpi2/_.s1' -p >>> 'freebsd:=/pics/CrossBuild/embedded/rpi2/_.s2' -p >>> 'freebsd:=/pics/CrossBuild/embedded/rpi2/_.s3' -o >>> /pics/CrossBuild/embedded/images/_.disk.image.HD-MCP >>> + mdconfig -f /pics/CrossBuild/embedded/images/_.disk.image.HD-MCP >>> + mdi=md0 >>> + gpart show md0 >>> => 1 429840 md0 MBR (210M) >>> 1 65536 1 fat16 (32M) >>> 65537 65536 2 freebsd (32M) >>> 131073 298768 3 freebsd (146M) >>> >>> + gpart set -a active -i 3 md0 >>> active set on md0s3 >>> + gpart show md0 >>> => 1 429840 md0 MBR (210M) >>> 1 65536 1 fat16 (32M) >>> 65537 65536 2 freebsd (32M) >>> 131073 298768 3 freebsd [active] (146M) >>> >>> + mdconfig -d -u md0 >>> + rm -f /pics/CrossBuild/embedded/images/_.disk.image.HD-MCP.xz >>> + echo 'NANO RM -f /pics/CrossBuild/embedded/images/_.disk.image.HD-MCP.xz' >>> NANO RM -f /pics/CrossBuild/embedded/images/_.disk.image.HD-MCP.xz >>> + uname -r >>> + command rm -x -f /pics/CrossBuild/embedded/images/_.disk.image.HD-MCP.xz >>> + xz -9 --keep /pics/CrossBuild/embedded/images/_.disk.image.HD-MCP >>> >>> >>> Onward I go... now I need to figure out how to get packages to work in a >>> cross-compiled world, which might be a bit of a bigger problem since the >>> existing way it's done chroot's into the installed world, which of >>> course means that the "pkg" command is for the wrong architecture..... >> >> The above works -- almost. >> >> The system boots on first start, gets an IP address, sets time and such >> and then hangs here: > ... >> Do I need "console=comconsole" in /boot/loader.conf? I would think >> setting the option in the nanobsd config file would generate that, but >> it does not appear to -- and it also doesn't appear to be necessary, >> because I do get all the boot messages on the serial console side. > > If nanobsd did its thing right, you should have a getty running on > both the serial port and the video "console" regardless of which one > is /dev/console. onifconsole isn't that useful in this situation. > > Warner