Date: Sun, 5 Feb 2017 10:53:35 -0600 From: Karl Denninger <karl@denninger.net> To: "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org> Subject: Re: NanoBSD config script for RPI2 Message-ID: <41e02f9b-7884-1eec-b4e0-a32c962642b9@denninger.net> In-Reply-To: <1892E365-966E-4DFA-8DE0-9BAD584754A1@dsl-only.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>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] 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 ;; 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..... -- Karl Denninger karl@denninger.net <mailto:karl@denninger.net> /The Market Ticker/ /[S/MIME encrypted email preferred]/ [-- Attachment #2 --] 0 *H 010 `He 0 *H \0X0@=0 *H 01 0 UUS10UFlorida10U Niceville10U Cuda Systems LLC1 0UCuda Systems LLC CA1"0 *H Cuda Systems LLC CA0 161218194535Z 211217194535Z0W1 0 UUS10UFlorida10U Cuda Systems LLC10Ukarl@denninger.net0"0 *H 0 ͍fd`1ie6";fSz`5¹/?{=Ӵowj ħ_fnӴMG\ҢҖ4ib}>@mJo&m M; Q9U cj] p퐆W.2E= ^¢tzĄ'5i7_ `~#dY `]R]N%R}EXzqV@[oN T>5AwYˡA "\v&YG]+($p:M,T?=mJkMљg*ym L! J[./d?W^LysD'1 +V'~{-SSX = q-f=%&V<m4 BeSet| l2m 6iO{wv + aH Xˈ5=~é*C!?uJr3tb' 3`Oe)üLxt&3N526 llU .|Cp[l? 007++0)0'+0http://cudasystems.net:88880 U 0 0 `HB0 U 0, `HB OpenSSL Generated Certificate0 U /Zi 0GhG0 U #0$q}ݽʒm50 U 0karl@denninger.net0 *H b% X% gwq Ɂэr K[DMJ35W6 sz8d|qB2Cyw2PbV} â[!W{HD7oD.TZ'w6~g( -,]R8P{*[f<1=7 jGj9铚~3f2AʺN k~@vz^j(>ͺyh2y { /9}4.45#S|<fW!.,Bss*Q+h =}l@ "q "M&6J5*,G {hɫjbNgǠ.ЃXȶ4$O.5evHlZba!4eE!x|Za1nZ5TuPvW|#G+ DZpI7S'n0 haGa@vZ e|]Cu+))vRyY10001 0 UUS10UFlorida10U Niceville10U Cuda Systems LLC1 0UCuda Systems LLC CA1"0 *H Cuda Systems LLC CA=0 `He M0 *H 1 *H 0 *H 1 170205165335Z0O *H 1B@+Oy7/vPQB J4%q飇W8aru x'3-}0l *H 1_0]0 `He*0 `He0 *H 0*H 0 *H @0+0 *H (0 +71001 0 UUS10UFlorida10U Niceville10U Cuda Systems LLC1 0UCuda Systems LLC CA1"0 *H Cuda Systems LLC CA=0 *H 101 0 UUS10UFlorida10U Niceville10U Cuda Systems LLC1 0UCuda Systems LLC CA1"0 *H Cuda Systems LLC CA=0 *H beIk<N5rtE>:gǰ);dǭ&a"u E}L#'.MWzyZ} >k ;)L<]kNDzLggvX ͈[ \J!ky Iݏ!_)Yٍ )ȭp6D> -eQ2ˈ\ o m Br(-UQG!?ܳ^-*mVUL;z̍nEK؈`Zazb/XIտ Pl:Q@5V <b=B)nQS.\m-~_"ٽ#XFa(P" )/ .n?u|_WqI0So L(W=,> !EE)8i9*P>Y[K22JM%mrmw\~ف[uCmY)Ǘߠgg/1-cťhelp
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?41e02f9b-7884-1eec-b4e0-a32c962642b9>