Bug 192324

Comment 1 Hiren Panchasara 2014-08-12 01:31:38 UTC

For fun, I tried to netboot this board. I setup tftpd and nfsd on my laptop and connected the board to it acting as client. It grabs things fine over tftp and nfs but hangs at 

status = BS->ExitBootServices(IH, x86_efi_mapkey); 

in elf64_exec() inside $src/sys/boot/amd64/efi/elf64_freebsd.c

which looks like the same place as booting from sd card. (though I haven't checked/confirmed that)

(just fyi)

I experienced similar issues attempting to boot the minnowboard max from an 11-CURRENT (r272035) memstick image that I built. I also saw the issues from a memstick flashed with the most recent snapshot image (18 Sep - r271779).

I tried twiddling various knobs in /boot/loader.conf. Including but not limited to some of these in various permutations:

kern.pty="vt"|kern.pty="vt_vga"
comconsole_speed="115200"
console="comconsole"

I tried a few different terminal settings in /etc/ttys for ttyu0 also (3wire, std.115200, 3wire.115200). 

I connected through the serial port and also connected a monitor and USB keyboard. They both showed the same result as what Hiren saw. Though there was an extra message about the display when the monitor was attached:

EFI framebuffer information:
addr, size     0x80000000, 0x7e9000
dimensions     1920 x 1080
stride         1920
masks          0x00ff0000, 0x0000ff00, 0x000000ff, 0xff000000


I tried booting with -v and -d from the loader prompt, but it never seems to get far enough for that to matter.

I attempted to debug it a little further. I added debugging statements around the code where the last messages get printed:

Index: sys/boot/amd64/efi/copy.c
===================================================================
--- sys/boot/amd64/efi/copy.c	(revision 272035)
+++ sys/boot/amd64/efi/copy.c	(working copy)
@@ -91,6 +91,7 @@
 void
 x86_efi_copy_finish(void)
 {
+	printf("BEGIN %s\n", __func__);
 	uint64_t	*src, *dst, *last;
 
 	src = (uint64_t *)staging;
@@ -99,4 +100,5 @@
 
 	while (src < last)
 		*dst++ = *src++;
+	printf("END %s\n", __func__);
 }
Index: sys/boot/amd64/efi/elf64_freebsd.c
===================================================================
--- sys/boot/amd64/efi/elf64_freebsd.c	(revision 272035)
+++ sys/boot/amd64/efi/elf64_freebsd.c	(working copy)
@@ -167,8 +167,10 @@
 	err = bi_load(fp->f_args, &modulep, &kernend);
 	if (err != 0)
 		return(err);
+	printf("after bi_load\n");
 
 	status = BS->ExitBootServices(IH, x86_efi_mapkey);
+	printf("after ExitBootServices\n");
 	if (EFI_ERROR(status)) {
 		printf("%s: ExitBootServices() returned 0x%lx\n", __func__,
 		    (long)status);
@@ -176,9 +178,13 @@
 	}
 
 	dev_cleanup();
+	printf("after dev_cleanup\n");
 
+	printf("kernend is %u, modulep is %u, PT4 is %u, ehdr->e_entry is %u\n",
+		kernend, modulep, PT4, ehdr->e_entry);
 	trampoline(trampstack, x86_efi_copy_finish, kernend, modulep, PT4,
 	    ehdr->e_entry);
+	printf("after trampoline\n");
 
 	panic("exec returned");
 }

Here's the output:

Loading /boot/defaults/loader.conf 
/boot/kernel/kernel text=0xfd1f00 data=0x12a530+0x608630 syms=[0x8+0x142c80+0x8+0x15dc80]

Hit [Enter] to boot immediately, or any other key for command prompt.


Type '?' for a list of commands, 'help' for more detailed help.
OK set kern.vty=vt
OK set comconsole_speed=115200
OK set console=comconsole
OK set hw.textmode=1
OK boot -v
Booting...
Start @ 0xffffffff802dd000 ...
EFI framebuffer information:
addr, size     0x80000000, 0x7e9000
dimensions     1920 x 1080
stride         1920
masks          0x00ff0000, 0x0000ff00, 0x000000ff, 0xff000000
after bi_load
after ExitBootServices
after dev_cleanup
kernend is 31100928, modulep is 31092736, PT4 is 1073725440, ehdr->e_entry is 2150486016
BEGIN x86_efi_copy_finish
END x86_efi_copy_finish

After that, there is no further output. So the trampoline call is invoked and runs at least to the point where it invokes x68_efi_copy_finish. I'm not too familiar with assembly code & hardware registers so I can't tell anything beyond that.

So, I did a presentation on this board at BAFUG recently.  In that presentation, I included boot results and screenshots:

What I've found works is to get to an EFI shell, and then launch the loader from the command line -- but ONLY when connected to an HDMI console.

You can see my output (they're embedded videos) at http://www.gushi.org/minnowpreso

Hope these help.

Comment 5 Oliver Pinter 2014-10-05 20:04:05 UTC

take a look at this PR: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194063

Comment 6 Ed Maste 2014-11-11 21:45:21 UTC

With HDMI attached the minnowboard max boots fine for me.

Note that no driver attaches to the UARTs, so a serial console won't work.  From pciconf -lvc:


none7@pci0:0:30:3:      class=0x078000 card=0x72708086 chip=0x0f0a8086 rev=0x0c hdr=0x00
    vendor     = 'Intel Corporation'
    device     = 'ValleyView LPIO1 HSUART Controller'
    class      = simple comms
    cap 01[80] = powerspec 3  supports D0 D3  current D0
none8@pci0:0:30:4:      class=0x078000 card=0x72708086 chip=0x0f0c8086 rev=0x0c hdr=0x00
    vendor     = 'Intel Corporation'
    device     = 'ValleyView LPIO1 HSUART Controller'
    class      = simple comms
    cap 01[80] = powerspec 3  supports D0 D3  current D0

Comment 7 Ed Maste 2014-11-11 22:53:33 UTC

One additional note Matt: adding printfs for debugging like that may not work properly, as printf can malloc(), which can change the memory map, which can make ExitBootServices fail.

Comment 8 Ed Maste 2015-01-05 15:51:11 UTC

With video attached 11-CURRENT works. Serial console will not work until PR 194952 is addressed.

I tested the board using r278031
The way I use to boot using a DVI monitor (and the last EFI firmware available) is to select 800x600 as display resolution and booting from the EFI shell.

I still have heavy problems with the network: when I set a static IP a get several lines as :
Memory modified after free 0xfffff8000366d000(2048) val=ffffffff @ 0xfffff8000366d000

and after 2-3 minutes, a crash in ctx_switch_xsave (repeatable)
I'm still investigating..

Comment 10 Ed Maste 2015-05-19 17:15:48 UTC

(In reply to luca.pizzamiglio from comment #9)

Do you have any further information?  Perhaps submit a new PR with additional details if so?