NanoBSD config script for RPI2
Warner Losh
imp at bsdimp.com
Mon Feb 6 06:17:10 UTC 2017
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 <imp at bsdimp.com> wrote:
> On Sun, Feb 5, 2017 at 2:22 PM, Karl Denninger <karl at denninger.net> 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 <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 at 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 at NewFS.denninger.net
>>>>> <mailto:karl at NewFS.denninger.net>:/usr/obj/usr/src/sys/KSD-SMP
>>>>> root at NewFS:/disk/karl # which mkimg
>>>>> /usr/bin/mkimg
>>>>> root at 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 at 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 at denninger.net <mailto:karl at 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.....
>>
>> 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
More information about the freebsd-arm
mailing list