Date: Sun, 5 Feb 2017 15:55:31 -0700 From: Warner Losh <imp@bsdimp.com> To: Karl Denninger <karl@denninger.net> Cc: "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org> Subject: Re: NanoBSD config script for RPI2 Message-ID: <CANCZdfrRNOtpx-ouUppvXNc2BF3Avo_ejcp1150QR3M8C1qdyA@mail.gmail.com> In-Reply-To: <41e02f9b-7884-1eec-b4e0-a32c962642b9@denninger.net> References: <69c5a012-c1e7-c887-cd3b-ffcf78d8175e@denninger.net> <CANCZdfqSMbygO47LYt7Yxi8m6OAawgta4swnv4WyVFzeD4D0vg@mail.gmail.com> <506d5c30-93f7-048e-2cde-d76bfaf76a8f@denninger.net> <CANCZdfoBYi_9TKpkq9SnBN6k-gWBo5-CAkTLfS5qdsKgfHLU8A@mail.gmail.com> <af492294-0333-5c67-a2b9-e9e9c478ccf2@denninger.net> <1892E365-966E-4DFA-8DE0-9BAD584754A1@dsl-only.net> <41e02f9b-7884-1eec-b4e0-a32c962642b9@denninger.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Feb 5, 2017 at 9:53 AM, Karl Denninger <karl@denninger.net> wrote: > On 2/4/2017 15:02, Mark Millard wrote: >> On 2017-Feb-4, at 10:56 AM, Karl Denninger <karl at denninger.net >> <http://denninger.net>>; wrote: >> >>> On 2/4/2017 10:38, Warner Losh wrote: >>>> On Sat, Feb 4, 2017 at 5:55 AM, Karl Denninger <karl at >>>> denninger.net <http://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> >>>>> options: >>>>> --formats - list image formats >>>>> --schemes - list partition schemes >>>>> --version - show version information >>>>> >>>>> -b <file> - file containing boot code >>>>> -c <num> - capacity (in bytes) of the disk >>>>> -f <format> >>>>> -o <file> - file to write image into >>>>> -p <partition> >>>>> -s <scheme> >>>>> -v - increase verbosity >>>>> -y - [developers] enable unit test >>>>> -H <num> - number of heads to simulate >>>>> -P <num> - physical sector size >>>>> -S <num> - logical sector size >>>>> -T <num> - 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 >>> <mailto: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 <mailto:karl@denninger.net> <mailto:karl at >>> denninger.net <http://denninger.net>>; >>> /The Market Ticker/ >>> /[S/MIME encrypted email preferred]/ >> >> >> === >> Mark Millard >> markmi at dsl-only.net <http://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 > ;; Yea, I'm not going to make that change. mkimg can run as the user, all the other stuff requires root. I'll see about changing it to use a mkimg build as an extra build tool in buildworld though. > 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..... Yes. I need to add that to the base NanoBSD as well. There's two approaches: one is to try to add them directly with the recent support for that from pkg. The other is to include packages on the media and install them on first boot. I'm leaning towards the former. Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfrRNOtpx-ouUppvXNc2BF3Avo_ejcp1150QR3M8C1qdyA>