Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 5 Feb 2017 23:17:07 -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:  <CANCZdfrbuKi9qKv0wMrT%2BE3r0FZFm4Tge0xP3zBa22K8aTyJWg@mail.gmail.com>
In-Reply-To: <CANCZdfpsWt3z1LJL5W=9a1SqT=PtCqGLjSjWs_=gdRsKNCzG8w@mail.gmail.com>
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> <ce443e27-9586-3113-7fde-25d31361fd89@denninger.net> <CANCZdfpsWt3z1LJL5W=9a1SqT=PtCqGLjSjWs_=gdRsKNCzG8w@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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@bsdimp.com> wrote:
> On Sun, Feb 5, 2017 at 2:22 PM, Karl Denninger <karl@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@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.....
>>
>> 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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfrbuKi9qKv0wMrT%2BE3r0FZFm4Tge0xP3zBa22K8aTyJWg>