Re: Succeeded to boot on Lenovo Yoga C630

On Dec 5, 2022, at 09:40, Hiroo Ono (小野寛生) <hiroo.ono+freebsd@gmail.com> wrote:

> I cannot find the original mail in my mailbox, but it is continued
> from this mail.
> https://freebsd-arm.freebsd.narkive.com/dBBAi0yX/loader-efi-does-not-boot-on-lenovo-yoga-c630
> 
> FreeBSD's bootaa64.efi that is distributed officially does not boot on
> Lenovo Yoga C630.
> OpenBSD 7.2's bootaa64.efi booted fine on Yoga C630, so I merged
> OpenBSD's start.S and ldscript.arm64.
> boot1.efi booted fine, but loader_lua.efi still needed to be tweaked.
> 
> It seems that probing on serial console freezes the loader.
> Commenting out serialconsole made the loader_lua.efi to boot the kernel.
> And then, the kernel stopped and complained that it cannot find the
> device tree blob.
> 
> So my questions are:
> 1. Can I disable loader from probing comconsole by some configuration?
> (without tweaking the source.)
> 2. How should I make the loader or kernel to find the dtb file?

The following might be involved in your context.

The following is from a successful boot of a HoneyComb via
UEFI/ACPI (not device tree) via an old log file that I
have around. Note the first two lines.

. . .
No valid device tree blob found!
WARNING! Trying to fire up the kernel, but no device tree blob found!
EFI framebuffer information:
addr, size     0x0, 0x0
dimensions     0 x 0
stride         0
masks          0x00000000, 0x00000000, 0x00000000, 0x00000000
---<<BOOT>>---
GDB: no debug ports present
KDB: debugger backends: ddb
KDB: current backend: ddb
Copyright (c) 1992-2022 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 14.0-CURRENT #59 main-n256584-5bc926af9fd1-dirty: Wed Jul  6 18:10:52 PDT 2022
. . .
Starting background file system checks in 60 seconds.
Sun Jul 17 14:50:56 PDT 
FreeBSD/arm64 (CA72_16Gp_ZFS) (ttyu0)

login: 
. . .

Such also happens for stable/13, releng/13.* based installations
as well --and likely others too.

ACPI booting does not use Device Tree information but the messages
are output anyway about the lack. Only if you know that the context
is a Device Tree style of boot are the messages actually reporting
a problem.


===
Mark Millard
marklmi at yahoo.com