Crochet produces boom-boom build

Wed Feb 8 14:41:26 UTC 2017

On 2/7/2017 15:36, Karl Denninger wrote:
> On 2/7/2017 12:33, Diane Bruce wrote:
>> On Tue, Feb 07, 2017 at 11:28:36AM -0600, Karl Denninger wrote:
>>> On 2/7/2017 11:26, Diane Bruce wrote:
>>>> On Tue, Feb 07, 2017 at 11:10:32AM -0600, Karl Denninger wrote:
>>> Uh, that is a cold boot.  Brad's image, which appears (at first blush)
>>> to be built with defaults (which I used as well here) comes up and runs
>>> the kernel is starting up (all CPUs start and run, etc.)
>> Then you are missing armstub8.bin in the dos portion of the sd card.
>> The latest crotchet and u-boot-rpi3.bin port will install these.
> I think the path is to figure out is why /boot/loader.efi blows up,
> given that armstub8.bin IS present and is being installed -- and my
> Crochet git grab was yesterday (last change visible appears to be 5 days
> old.)
>
> RPi3 PSCI monitor installed
>
>
> U-Boot 2017.01 (Feb 07 2017 - 14:26:16 -0600)
>
> DRAM:  944 MiB
> RPI 3 Model B (0xa22082)
> MMC:   bcm2835_sdhci: 0
> reading uboot.env
>
> ** Unable to read "uboot.env" from mmc0:1 **
> Using default environment
>
> In:    serial
> Out:   lcd
> Err:   lcd
> Net:   Net Initialization Skipped
> No ethernet found.
> starting USB...
> USB0:   Core Release: 2.80a
> scanning bus 0 for devices... 3 USB Device(s) found
>        scanning usb for storage devices... 0 Storage Device(s) found
>        scanning usb for ethernet devices... 1 Ethernet Device(s) found
> Hit any key to stop autoboot:  0
> switch to partitions #0, OK
> mmc0 is current device
> Scanning mmc 0:1...
> Found EFI removable media binary efi/boot/bootaa64.efi
> reading efi/boot/bootaa64.efi
> 81472 bytes read in 28 ms (2.8 MiB/s)
> ## Starting EFI application at 01000000 ...
> Scanning disks on usb...
> Scanning disks on mmc...
> Adding logical partition
> Adding logical partition
> MMC Device 1 not found
> MMC Device 2 not found
> MMC Device 3 not found
> Found 7 disks
>
>
>>> FreeBSD EFI boot block
>    Loader path: /boot/loader.efi
>
>    Initializing modules: ZFS UFS
>    Probing 3 block devices.....* done
>     ZFS found no pools
>     UFS found 1 partition
> Consoles: EFI console
> Command line arguments: loader.efi
> Image base: 0x379b8008
> EFI version: 2.05
> EFI Firmware: Das U-boot (rev 0.00)
>
> FreeBSD/arm64 EFI loader, Revision 1.1
> (Tue Feb  7 15:15:52 CST 2017 freebsd at NewFS.denninger.net)
> Failed to start image provided by UFS (14)
> "Synchronous Abort" handler, esr 0x96000004
> ELR:     3af62cec
> LR:      3af61d60
> x0 : 0000000000000001 x1 : 0000000000000001
> x2 : 000000003afeb000 x3 : 000000000000003f
> x4 : 0000000000000020 x5 : 0000000000000010
> x6 : 0000000000000000 x7 : 0000000039b260a4
> x8 : 000000003af61d48 x9 : 000000000000000d
> x10: 0000000000000030 x11: 0000000000000000
> x12: 0000000000000000 x13: 0000000000000002
> x14: 0000000000000000 x15: 0000000000000000
> x16: 0000000000000000 x17: 0000000000000000
> x18: 000000003ab30df8 x19: 0000000037a16008
> x20: 0000000000000000 x21: 0000000000000000
> x22: 0000000039b28000 x23: 0000000039b1d49c
> x24: 0000000039b28850 x25: 000000003ab3d740
> x26: 000000003af839a0 x27: 0000000039b2e3e8
> x28: 0000000000000000 x29: 000000003ab2ef60
>
> Resetting CPU ...
>
> resetting ...
>
> That's what I get off a clean build (just re-built/reinstalled the
> u-boot-rpi3 port, just to be sure, then re-ran Crochet.) I can replace
> /boot/loader.efi with the "working" one from Brad's build -- which is
> NOT of the same size (say much less checksum) -- but I suspect whatever
> is producing the bad code in /boot/loader.efi is also producing the bad
> code in the rest of the build.... so fixing the first one should fix the
> second.
>
> What are you building Crochet'd builds for the Pi3 on and what versions
> of aarch64-* do you have on your system?  The clue may lie there.  I am
> building on:
>
> FreeBSD 11.0-STABLE #15 r312669M: Mon Jan 23 14:01:03 CST 2017    
> karl at NewFS.denninger.net:/usr/obj/usr/src/sys/KSD-SMP
>
The build  that runs (and which was uploaded to rasperian by Brad) is:

FreeBSD 12.0-CURRENT #0 r313109M: Thu Feb  2 16:16:39 MST 2017    
raspberry at hive.raspbsd.org:/usr/home/brd/rpi3/crochet/work/obj/arm64.aarch64/usr/src/sys/GENERIC

Note the "M", so local mods (not in the public repo) appear to be in the
kernel source tree.

r313441 (updated a short while ago, but none of the changes since
yesterday appear to touch files that are specific to the ARM
architectures) does not produce a working build here and I've
re-installed both the u-boot port and the crossbuild components just to
make sure I've got the current versions. My cross-build tools are also
at what appear to be current revisions from what I'm able to discern.

root at NewFS:/usr/ports/devel/aarch64-binutils # pkg info|grep aarch
aarch64-binutils-2.27_5,1      GNU binutils for AArch64 cross-development
aarch64-none-elf-binutils-2.27_5,1 GNU binutils for bare metal AArch64
cross-development
aarch64-none-elf-gcc-6.3.0     Cross GNU Compiler Collection for
aarch64noneelf

Since there are local revisions I assume that reverting to 313109 is
unlikely to produce joy without either knowing at what rev those were
committed or having them here, or if there's an issue with the
crossbuild versions that are "latest available publicly."

-- 
Karl Denninger
karl at denninger.net <mailto:karl at denninger.net>
/The Market Ticker/
/[S/MIME encrypted email preferred]/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2993 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.freebsd.org/pipermail/freebsd-arm/attachments/20170208/f657496c/attachment.bin>