stand: Move sections around to fix stand/ build with ld.lld on armv7

[kevans]

Summary

(Related to D13941)

When building loader bits, lld fails with the following error: ld: error: section: .dynamic is not contiguous with other relro sections on both ubldr and EFI loader.

Move .dynamic up to make ld.lld happy, adjust .got as necessary for ubldr.

Tested on: OrangePi One (ld.lld, ubldr)
Tested on: Banana Pi-M3 (ld.lld, ubldr)
Tested on: qemu-armv7 (ld.lld, EFI)
Tested on: qemu-armv7 (ld.bfd, EFI)
Tested on: Raspberry Pi 2 (ld.bfd, ubldr) [manu]
Tested on: Banana Pi-M2 (ld.bfd, ubldr) [manu]

Aside: I don't have any armv7 EFI stuff to test boot with, so coverage for that change is lacking. I also haven't checked that that change still builds with ld.bfd, but I have no reason to think it wouldn't.

The only other outstanding issue I've come across is that ld.lld isn't currently setting VFP flag, as diagnosed with this patch by @andrew - https://people.freebsd.org/~andrew/0001-Also-set-the-EF_ARM_VFP_FLOAT-flag.patch -- things otherwise seem good for LLD_BOOTSTRAP.

[imp]

Seems reasonable, but I don't completely understand these goofy things
\

[andrew]

Aside: I don't have any armv7 EFI stuff to test boot with, so coverage for that change is lacking. I also haven't checked that that change still builds with ld.bfd, but I have no reason to think it wouldn't.

There is nanobsd support to build for qemu which uses EFI. There is a config file in tools/tools/nanobsd/embedded/qemu-armv7.cfg, however it will need to be updated as it doesn't know about TARGET_ARCH=armv7.

[imp]

In D13942#292488, @andrew wrote:

Aside: I don't have any armv7 EFI stuff to test boot with, so coverage for that change is lacking. I also haven't checked that that change still builds with ld.bfd, but I have no reason to think it wouldn't.

There is nanobsd support to build for qemu which uses EFI. There is a config file in tools/tools/nanobsd/embedded/qemu-armv7.cfg, however it will need to be updated as it doesn't know about TARGET_ARCH=armv7.

I'll update that...

I also have the tools/boot/universe.sh script that can build almost all boot loader variants. As well as genroot.sh, which I'm trying to flesh out to have minimal bootable images as well. Though that should go hand in hand with updating the nanobsd build stuff so they use a common tool to generate the images that we can then expand to the 'bring your own u-boot party' we have planned for the generic armv7 and arm64 worlds.

[kevans]

I made the following changes to the nanobsd scripts:

diff --git a/tools/tools/nanobsd/embedded/common b/tools/tools/nanobsd/embedded/common
index 41d9484a8fe..33263fc60b3 100644
--- a/tools/tools/nanobsd/embedded/common
+++ b/tools/tools/nanobsd/embedded/common
@@ -535,6 +535,9 @@ std_armeb ( ) {
 std_armv6 ( ) {
 }

+std_armv7 ( ) {
+}
+
 std_i386 ( ) {
        # Default values, if not overridden in .cfg file
        : ${NANO_KERNEL:=GENERIC}
diff --git a/tools/tools/nanobsd/embedded/qemu-armv7.cfg b/tools/tools/nanobsd/embedded/qemu-armv7.cfg
index f80fee91320..d36a8811f1f 100644
--- a/tools/tools/nanobsd/embedded/qemu-armv7.cfg
+++ b/tools/tools/nanobsd/embedded/qemu-armv7.cfg
@@ -27,7 +27,7 @@
 # SUCH DAMAGE.
 #

-NANO_ARCH=armv6
+NANO_ARCH=armv7
 NANO_DRIVE=vtbd0
 NANO_KERNEL=GENERIC
 NANO_NAME=qemu-armv7

and built both LLD_BOOTSTRAP image and non-LLD_BOOTSTRAP image to test with. For both images, I get the following:

>> FreeBSD EFI boot block
   Loader path: /boot/loader.efi

   Initializing modules: ZFS UFS
   Load Path: \EFI\BOOT\BOOTARM.EFI
   Load Device: VenHw(837DCA9E-E874-4D82-B29A-23FE0E23D1E2,003E000A00000000)/HD(1,GPT,46ED2AAE-FBC1-11E7-86D0-0800277E5ADD,0x3,0x640)
   BootCurrent: 0000
   BootOrder: 0018 0000 7cac 47be 001b 0000 33e1 479d 0006 0000 7d18 47be 0006 0000 82ec 479f 0000 0000 f424 0000 0010 0000 fff9 ffff 9e94 45e5 bf9c 45e5 9e90 45e5 1af9 47bf 0002 8000 baed 47be cce0 479f fdc3 47be 0001 0000 0001 0000 0001 0000 bcad 47be 295f 0000 7dd8 47be 7ddc 47be 295f 0000 7db4 47be 295f 0000 2890 46fa 02d0 0000 2880 46fa d859 47be 7e04 47be 0001 0000 0030 0000 d5dd 47be 9e94 45e5 00c0 0000 643c 47bf 0040 0000 c340 b905 643c 47bf cce0 479f 7e04 47be 0004 0000 0030 0000 1d6b 47bf 0000 0000
   Probing 7 block devices........** done
    ZFS found no pools
    UFS found 2 partitions
    command args: -h -S115200

Failed to start image provided by UFS (9)
panic: No bootable partitions found!
.

Fortunately, I get the same results with ld.bfd if I revert my patch, so this seems to speak more for my inability to generate a working nanobsd image. However, it seems that loader is at least as functional as it was before from what I can test.

[imp]

that's seriously AFU boot order.

It's most likely a problem with the u-boot port for this board, though honestly I've never built a EFI image with nanobsd that wasn't x86.

[kevans]

In D13942#292823, @imp wrote:

that's seriously AFU boot order.

It's most likely a problem with the u-boot port for this board, though honestly I've never built a EFI image with nanobsd that wasn't x86.

Well, shucks. =)

So we don't really have an immediate test case for this, since we're still in boot1 above (right?)...do we care? What are the odds of .dynamic moving around breaking things? I know nothing of ELF and linking magic, I'm afraid.

[andrew]

Do you have rS328007? That looks similar to what I was seeing, however in my case it would continue booting then fail to start the secondary CPUs.

[kevans]

In D13942#292914, @andrew wrote:

Do you have rS328007? That looks similar to what I was seeing, however in my case it would continue booting then fail to start the secondary CPUs.

I did not. I did, however, fail to supply an -m option, so I guess it had insufficient RAM to actually boot. This gets us here:

>> FreeBSD EFI boot block
   Loader path: /boot/loader.efi

   Initializing modules: ZFS UFS
   Load Path: \EFI\BOOT\BOOTARM.EFI
   Load Device: VenHw(837DCA9E-E874-4D82-B29A-23FE0E23D1E2,003E000A00000000)/HD(1,GPT,07AFF126-FC74-11E7-86D0-0800277E5ADD,0x3,0x640)
   BootCurrent: 0002
   BootOrder: 0000 0001 0002 0003 0004
   Probing 7 block devices........** done
    ZFS found no pools
    UFS found 2 partitions
    command args: -h -S115200

Consoles: EFI console
console comconsole is invalid!
no valid consoles!
Available consoles:
    efi
Command line arguments: l -h -S115200
Image base: 0x5c539000
EFI version: 2.60
EFI Firmware: EDK II (rev 1.00)

FreeBSD/arm EFI loader, Revision 1.1
(Thu Jan 18 11:10:52 CST 2018 [e-mail])
EFI boot environment
/boot/kernel/kernel text=0x816800 data=0x7d078+0x1df788 syms=[0x4+0x98320+0x4+0xdd0fd]

Hit [Enter] to boot immediately, or any other key for command prompt.
Booting [/boot/kernel/kernel]...
Using DTB provided by EFI at 0x5ffdb000.
Kernel entry at 0x52000180...
Kernel args: (null)
modulep: 0xc0bfc000
relocation_offset 0
Debug facility locked (CPU0)
HW Breakpoints/Watchpoints not enabled on CPU0
KDB: debugger backends: ddb
KDB: current backend: ddb
Copyright (c) 1992-2018 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
        The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 12.0-CURRENT #0 60570599612(overlay-compat)-dirty: Thu Jan 18 11:19:45 CST 2018
    [e-mail]:/usr/embedded/obj.cortexa/usr/src.allwinner-a83t/arm.armv7/sys/GENERIC arm
FreeBSD clang version 6.0.0 (branches/release_60 321788) (based on LLVM 6.0.0)
WARNING: WITNESS option enabled, expect reduced performance.
VT: init without driver.
/wrkdirs/usr/ports/emulators/qemu/work/qemu-2.9.0/tcg/tcg.c:2017: tcg fatal error

This is consistent between ld.bfd and ld.lld both with the ldscript change and without, so I think that's enough to add:

Tested on: qemu-armv7 (ld.lld, EFI)
Tested on: qemu-armv7 (ld.bfd, EFI)

[imp]

Seems reasonable to me still... Especially with the saner testing...

[emaste]

Sounds good to me with the testing that was done.