From nobody Sun Dec 18 20:33:23 2022 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NZvgQ6gQRzt6p5 for ; Sun, 18 Dec 2022 20:33:38 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NZvgQ2DLTz3jgy for ; Sun, 18 Dec 2022 20:33:38 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=yh3AW78r; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2a00:1450:4864:20::530) smtp.mailfrom=wlosh@bsdimp.com; dmarc=none Received: by mail-ed1-x530.google.com with SMTP id i9so10429785edj.4 for ; Sun, 18 Dec 2022 12:33:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=UBpF85ub17VQVtaNAXTKD3qcztxM40Srt5Ypk/kueEw=; b=yh3AW78r7CNujpJYc1OLc4iIPU8O0jultOBIsSnF2BJY5Ehzbl14OhJ6OBQmElZ63n sbS+8Upvv2xYJDS7HqD/9W9xEVeRaKYm8HgeJH7O1nwD47SptH0U1dtZjN+EDOXsi3il Inrzq7v5ZpWbJBJAA0O754CWSBDC9wrPj/eE7RltubsqxaPiunj/L2ln3uArru3q0rOg 23dtrukAYf2IX2MkinHrU28+XdA+b2mTHpG4siomI9VyMITwb8GqSqH14XAVw9aexpok iw7mVsjvnqdLeEcMhm2J3m1yJqXgtED1kzaXC7r1AssTaCf4GVw8Cp511hznDa7ma2N1 qx6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=UBpF85ub17VQVtaNAXTKD3qcztxM40Srt5Ypk/kueEw=; b=NTNuYHIEBMjuHPTobij/PrMqDBwSO6A7kdWgxgdUgU93M5awT1wQRQPwi9RE2bxRX1 nhyG1RsuGN2kovBbodVac/5mxVZepsbBFE9AKs+H4REZPMCstHxNDfi27KkhWSiuJu/v VbZ7gYIq/bMUOhXI0U/9krmNCnFgiljKj9XJnLn2IEiQY/XHugvufCqG1qrgftAXSYni hiiZLY2qKZmIPemykuESG/3JzdHIzD4vo2/uuzACnC3TXadUxi5NK2k6zMT0qkU7EOO4 urzHL8FBDJ3uQprptbIoYeiwRRmv8s3CAZL+J+Uh/IOsSUF/lfVAdbMlnbS7zpgVgV+p jUqA== X-Gm-Message-State: AFqh2kq93ZaHCVjnQ5YaKLXdFbX0AWqLmUc9CmfzeY2f8iKo60cFulwx DoAERpPVPesA7bGhDTfB5Ou2YdJLclEdBXEd/8yyLHJdFQ7xjT0h X-Google-Smtp-Source: AMrXdXuSB/Kd4Iq2ijBATtEITPxjr55jimQpZd0psowO3rB18pgH4mXGJv/xUNj3cr44hIibIRrvV3STk8OA1Qg2AEg= X-Received: by 2002:a05:6402:2203:b0:472:c7fe:4754 with SMTP id cq3-20020a056402220300b00472c7fe4754mr2095140edb.173.1671395615093; Sun, 18 Dec 2022 12:33:35 -0800 (PST) List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Sun, 18 Dec 2022 13:33:23 -0700 Message-ID: Subject: Re: Still did not succeed to boot on Lenovo Yoga C630 To: hiroo.ono+freebsd@gmail.com Cc: Mark Millard , freebsd-arm@freebsd.org Content-Type: multipart/alternative; boundary="000000000000eac9fb05f0201de7" X-Spamd-Result: default: False [-2.99 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.994]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; FREEMAIL_TO(0.00)[gmail.com]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; R_SPF_NA(0.00)[no SPF record]; FREEMAIL_CC(0.00)[yahoo.com,freebsd.org]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::530:from]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; FROM_HAS_DN(0.00)[]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; TO_DN_SOME(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; TAGGED_RCPT(0.00)[freebsd]; DMARC_NA(0.00)[bsdimp.com]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4NZvgQ2DLTz3jgy X-Spamd-Bar: -- X-ThisMailContainsUnwantedMimeParts: N --000000000000eac9fb05f0201de7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Dec 18, 2022 at 4:31 AM Hiroo Ono (=E5=B0=8F=E9=87=8E=E5=AF=9B=E7= =94=9F) < hiroo.ono+freebsd@gmail.com> wrote: > Hello, > > I investigated a little more. > I thought it was the kernel that did not run, but still it did not get > through the loader. > Keep at it... > The loader freezed in efi_do_vmap(), so I needed to add > efi_disable_vmap=3D"YES" in loader.conf. > No. The code for this needs to be fixed... More on that in a second... > At last, in elf64_exec, it tried to run (*entry)(modulep) where the > address entry is calculated from ehdr->e_entry by efi_translate() in > stand/efi/loader/copy.c. There, > ehdr->e_entry was 0xffff000000020000 (should be 0xffff000000000800, > but I modified a little) and > stage_offset was 0x10000b33e0000. > The sum of two which efi_translate() returns is 0x100000000b3400000. > It overflows uint64_t and becomes 0xb3400000. > Yea, I think this is wrong. > Currently, I do not understand well what the functions in > stand/efi/loader/copy.c do, and do not know how to workaround this > problem. > So there's two things going on here. First is that on arm64 we should *NEVER* copy the kernel. It loads at a specific address and we jump to where it loaded in RAM (in your case, I think it should be stage_offset + (ehdr->e_entry - KERNBASE). Kernbase is 0xffff000000000000 so we should jump to 0x10000brre0000 + 0x20000 (or maybe 0x800 is you suggest). The kernel code that's there should do some tricks to find out where it was loaded, turn on the MMU and then jump to the VA to continue starting up the kernel. The arm64 kernel is linked with a VA. Old amd64 kernels expected to start at a fixed physical address, but the UEFI spec allows memory to be mapped anywhere which means it was recently switched to create a page table in the boot loader, then jump to the right VA, and use the page table to find what PA that is and use that to bootstrap the pmap. This works great on amd64, but sometimes goes astray on arm64 (though the way it does for you doesn't make sense to me). The amd64 code used to start at a PA, and that's what the 'copy' routine is supposed to do: copy the kernel down that fixed address and jump to it. I don't think we'll ever want that on arm64, though, and that might also be getting in your way (thought I'm doing this from memory w/o careful study of the code because it's fresh in my mind due to getting arm64 working with linuxboot). Also, vmap *MUST* be called in the boot loader. The trouble is, it assumes VA =3D=3D PA, but that's not strictly true. If you boot via LinuxBoot, for example, it has a memory mapping that's not VA =3D=3D PA so at least some parts of the kernel fail their VA =3D=3D PA asserts. the vmap code in the loader currently blindly assumes VA =3D=3D PA, but it should, IMHO, only do that if the VA f= rom entry from the table from the get memory map call is 0. Today it blindly overwrites it. You might try changing that, and removing the bit in the kernel that checks for VA =3D=3D PA and bails out if there's= a mismatch. Here's the patch I'm temporarily using until I have the time to do more than a quick, superficial analysis of the issue: diff --git a/sys/arm64/arm64/efirt_machdep.c b/sys/arm64/arm64/efirt_machdep.c index 727c9c37f94d..075174d164d8 100644 --- a/sys/arm64/arm64/efirt_machdep.c +++ b/sys/arm64/arm64/efirt_machdep.c @@ -193,8 +193,8 @@ efi_create_1t1_map(struct efi_md *map, int ndesc, int descsz) continue; if (p->md_virt !=3D 0 && p->md_virt !=3D p->md_phys) { if (bootverbose) - printf("EFI Runtime entry %d is mapped\n", i); - goto fail; + printf("EFI Runtime entry %d is mapped PA %#lx VA %#lx\n", i, p->md_phys, p->md_virt); +// goto fail; } if ((p->md_phys & EFI_PAGE_MASK) !=3D 0) { if (bootverbose) clearly, not suitable for upstreaming, eh? And I have about 2 dozen commits in my queue ahead of that one that need refinement, review and upstreaming before I jump into this issue. It will be after the first of the year at least before I'll look at it since I just started my year-end vacation... Warner > 2022=E5=B9=B412=E6=9C=889=E6=97=A5(=E9=87=91) 9:25 Hiroo Ono (=E5=B0=8F= =E9=87=8E=E5=AF=9B=E7=94=9F) : > > > > 2022=E5=B9=B412=E6=9C=889=E6=97=A5(=E9=87=91) 3:19 Warner Losh : > > > > > > > > > > > > On Wed, Dec 7, 2022 at 4:21 PM Hiroo Ono (=E5=B0=8F=E9=87=8E=E5=AF=9B= =E7=94=9F) < > hiroo.ono+freebsd@gmail.com> wrote: > > >> > > >> 2022=E5=B9=B412=E6=9C=887=E6=97=A5(=E6=B0=B4) 1:18 Warner Losh : > > >> > > > >> > > > >> > > > >> > On Tue, Dec 6, 2022 at 7:59 AM Hiroo Ono (=E5=B0=8F=E9=87=8E=E5=AF= =9B=E7=94=9F) < > hiroo.ono+freebsd@gmail.com> wrote: > > >> > > >> >> OK, I (and the subject) was wrong. The loader boots, and show > > >> >> following log at last: > > >> >> > > >> >> Loading kernel... > > >> >> /boot/kernel/kernel text=3D0x2a8 text=3D0x8bcbf0 text=3D0x1f97ac > > >> >> data=3D0x1a6ac0 data=3D0x0+0x381000 syms=3D[0x8+0x11f6a0+0x8+0x14= 39ea] > > >> >> Loading configured modules... > > >> >> can't find '/boot/entropy' > > >> >> can't find '/etc/hostid' > > >> >> No valid device tree blob found! > > >> >> WARNING! Trying to fire up the kernel, but no device tree blob > found! > > >> >> EFI framebuffer information > > >> >> addr, size 0x80400000, 0x7e9000 > > >> >> dimensions 1920 x 1080 > > >> >> stride 1920 > > >> >> masks 0x00ff0000, 0x0000ff00, 0x000000ff, 0xff000000 > > >> >> > > >> >> and it stops here. No "<>" line is displayed. > > >> >> So, it seems that the kernel is loaded but could not be started. > > >> > > > >> > > > >> > There are several causes of this. > > >> > > > >> > Most likely is that the console is setup to go somewhere else. > Though if you are on the video display and getting that framebuffer outpu= t, > it won't not go there w/o some setting to override (say to force serial). > > >> > > >> In the loader, when comconsole->c_init() is called for the second > > >> time, the function does not return. (I commented out comconsole to > > >> make the loader work, but it is rather brutal and is not a proper > > >> solution). > > >> But the function parse_uefi_con_out() in stand/efi/loader/main.c > > >> always returns RB_SERIAL, so the loader tries to use the serial > > >> console. > > > > > > > > > I wonder why that is. Is this -current or -stable? I have a rather > large backlog of MFC-able loader changes. If it is with stable, then it > makes sense: I fixed a bug where parse_uefi_con_out would return serial i= f > '8be4df61-93ca-11d2-aa0d-00e098032b8c-ConOut' was unset. Is it set? Now = we > return Video console if we fine evidence there's a video console. > > > > It is stable/13. > > I tried 14-current, and the same change to loader was needed (merging > > OpenBSD's start.S and ldscript.arm64, and commenting out comconsole). > > Even with these change, the console defaults to serial, so I changed > > parse_uefi_con_out() to always return 0. > > Still, it stops at the same point. The kernel does not seem to boot. > > > > Running efi-show from the loader prompt did not show > > '8be4df61-93ca-11d2-aa0d-00e098032b8c-ConOut' > > The variable name containing 'ConOut' were: > > > > global NV,BS,RS ConOut =3D > > > VenHw(9042A9DE-23DC-4A38-96FB-7ADED080516A),/VenHw(857A8741-0EEC-43BD-048= 2-27D14ED47D72)/Uart(115200,8,N,1) > > global NV,BS,RS ConOutDev =3D > > > VenHw(9042A9DE-23DC-4A38-96FB-7ADED080516A),/VenHw(857A8741-0EEC-43BD-048= 2-27D14ED47D72)/Uart(115200,8,N,1) > > > > > Now, why it fails the second time, I don't know. > > > > > >> > > >> If a similar thing happens with the kernel, it may be stopping at > > >> serial console initialization. > > > > > > > > > The kernel doesn't use the EFI routines to initialize the serial > console. But if the kernel is being told the wrong console, then it could > also be booting just fine or almost fine and hitting some bug later. > > > > > >> > > >> > Next most likely is that FreeBSD doesn't cope well with having bot= h > FDT and ACPI information available. But since not DTB is being passed in > (per that message) that's not likely at play here. > > >> > > >> I managed to load the dtb file and the boot process stopped at the > > >> same point. The problem is not here? > > > > > > > > > Yea, I don't think so. > > > > > > Warner > > > > > >> > > >> > Finally, the loader passes a large number of tables, etc to the > kernel. It's quite possible that, for reasons still unknown, that data is > wrong or if standard conforming not expected by the kernel. this leads to= a > crash before we've setup the console in the kernel which looks a lot like= a > hang. > > >> > > > >> > Warner > > >> > > > >> > > > >> >> > > >> >> > . . . > > >> >> > > > >> >> > Such also happens for stable/13, releng/13.* based installation= s > > >> >> > 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. > > >> >> > > > >> >> > > > >> >> > =3D=3D=3D > > >> >> > Mark Millard > > >> >> > marklmi at yahoo.com > > >> >> > > > >> >> > --000000000000eac9fb05f0201de7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Dec 18, 2022 at 4:31 AM Hiroo= Ono (=E5=B0=8F=E9=87=8E=E5=AF=9B=E7=94=9F) <hiroo.ono+freebsd@gmail.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">Hello,

I investigated a little more.
I thought it was the kernel that did not run, but still it did not get
through the loader.

Keep at it...
=
=C2=A0
The loader freezed in efi_do_vmap(), so I needed to add
efi_disable_vmap=3D"YES" in loader.conf.
No. The code for this needs to be fixed...=C2=A0 More on that i= n a second...
=C2=A0
At last, in elf64_exec, it tried to run (*entry)(modulep) where the
address entry is calculated from ehdr->e_entry by efi_translate() in
stand/efi/loader/copy.c. There,
ehdr->e_entry was 0xffff000000020000 (should be 0xffff000000000800,
but I modified a little) and
stage_offset was 0x10000b33e0000.
The sum of two which efi_translate() returns is 0x100000000b3400000.
It overflows uint64_t and becomes 0xb3400000.

Yea, I think this is wrong.
=C2=A0
Currently, I do not understand well what the functions in
stand/efi/loader/copy.c do, and do not know how to workaround this
problem.

So there's two things goin= g on here. First is that on arm64 we should *NEVER* copy the
kern= el. It loads at a specific address and we jump to where it loaded in RAM (i= n your case,
I think it should be stage_offset=C2=A0+ (ehdr->e= _entry - KERNBASE). Kernbase is 0xffff000000000000
so we should j= ump to 0x10000brre0000=C2=A0+ 0x20000 (or maybe 0x800 is you suggest). The = kernel
code that's there should do some tricks to find out wh= ere it was loaded, turn on the MMU and
then jump to the VA to con= tinue starting up the kernel. The arm64 kernel is linked with a VA. Old amd= 64
kernels expected to start at a fixed physical address, but the= UEFI spec allows memory to be mapped anywhere
which means it was= recently switched to create a page table in the boot loader, then jump to = the right
VA, and use the page table to find what PA that is and = use that to bootstrap the pmap. This works great on
amd64, but so= metimes goes astray on arm64 (though the way it does for you doesn't ma= ke sense
to me). The amd64 code used to start at a PA, and that&#= 39;s what the 'copy' routine is supposed to do:
copy the = kernel down that fixed address and jump to it. I don't think we'll = ever want that on arm64, though,
and that might also be getting i= n your way (thought I'm doing this from memory w/o careful study of
the code because it's fresh in my mind due to getting arm64 work= ing with linuxboot).

Also, vmap *MUST* be called i= n the boot loader. The trouble is, it assumes VA =3D=3D PA, but that's = not
strictly true. If you boot via LinuxBoot, for example, it has= a memory mapping that's not VA =3D=3D PA so
at least some pa= rts of the kernel fail their VA =3D=3D PA asserts. the vmap code in the loa= der currently
blindly assumes VA =3D=3D PA, but it should, IMHO, = only do that if the VA from entry from the table from
the get mem= ory map call is 0. Today it blindly overwrites it. You might try changing t= hat, and removing
the bit in the kernel that checks for VA =3D=3D= PA and bails out if there's a mismatch. Here's the patch I'm
temporarily using until I have the time to do more than a quick, s= uperficial analysis of the issue:

diff --git a/sys= /arm64/arm64/efirt_machdep.c b/sys/arm64/arm64/efirt_machdep.c
index 727= c9c37f94d..075174d164d8 100644
--- a/sys/arm64/arm64/efirt_machdep.c
= +++ b/sys/arm64/arm64/efirt_machdep.c
@@ -193,8 +193,8 @@ efi_create_1t1= _map(struct efi_md *map, int ndesc, int descsz)
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 continue;
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (p->md_virt != =3D 0 && p->md_virt !=3D p->md_phys) {
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (boot= verbose)
- =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 printf("EFI Runtime entr= y %d is mapped\n", i);
- =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 goto fail;
+ =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 printf("EFI Runtime entry %d is mapped PA %#lx VA %#lx\n",= i, p->md_phys, p->md_virt);
+// =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 goto fail;
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 if ((p->md_phys & EFI_PAGE_MASK) !=3D 0) {
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 if (bootverbose)

clearly, not suita= ble for upstreaming, eh? And I have about 2 dozen commits in my queue ahead= of that
one that need refinement, review and upstreaming before = I jump into this issue. It will be after the first
of the year at= least before I'll look at it since I just started my year-end vacation= ...

Warner
=C2=A0
2022=E5=B9=B412=E6=9C=889=E6=97=A5(=E9=87=91) 9:25 Hiroo Ono (=E5=B0=8F=E9= =87=8E=E5=AF=9B=E7=94=9F) <hiroo.ono+freebsd@gmail.com>:
>
> 2022=E5=B9=B412=E6=9C=889=E6=97=A5(=E9=87=91) 3:19 Warner Losh <imp@bsdimp.com>: > >
> >
> >
> > On Wed, Dec 7, 2022 at 4:21 PM Hiroo Ono (=E5=B0=8F=E9=87=8E=E5= =AF=9B=E7=94=9F) <hiroo.ono+freebsd@gmail.com> wrote:
> >>
> >> 2022=E5=B9=B412=E6=9C=887=E6=97=A5(=E6=B0=B4) 1:18 Warner Los= h <imp@bsdimp.com>:
> >> >
> >> >
> >> >
> >> > On Tue, Dec 6, 2022 at 7:59 AM Hiroo Ono (=E5=B0=8F=E9= =87=8E=E5=AF=9B=E7=94=9F) <hiroo.ono+freebsd@gmail.com> wrote:
> >>
> >> >> OK, I (and the subject) was wrong. The loader boots,= and show
> >> >> following log at last:
> >> >>
> >> >> Loading kernel...
> >> >> /boot/kernel/kernel text=3D0x2a8 text=3D0x8bcbf0 tex= t=3D0x1f97ac
> >> >> data=3D0x1a6ac0 data=3D0x0+0x381000 syms=3D[0x8+0x11= f6a0+0x8+0x1439ea]
> >> >> Loading configured modules...
> >> >> can't find '/boot/entropy'
> >> >> can't find '/etc/hostid'
> >> >> No valid device tree blob found!
> >> >> WARNING! Trying to fire up the kernel, but no device= tree blob found!
> >> >> EFI framebuffer information
> >> >> addr, size=C2=A0 =C2=A0 =C2=A0 =C2=A0 0x80400000, 0x= 7e9000
> >> >> dimensions=C2=A0 =C2=A0 =C2=A01920 x 1080
> >> >> stride=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A01920
> >> >> masks=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 0x00f= f0000, 0x0000ff00, 0x000000ff, 0xff000000
> >> >>
> >> >> and it stops here. No "<<BOOT>>&quo= t; line is displayed.
> >> >> So, it seems that the kernel is loaded but could not= be started.
> >> >
> >> >
> >> > There are several causes of this.
> >> >
> >> > Most likely is that the console is setup to go somewhere= else. Though if you are on the video display and getting that framebuffer = output, it won't not go there w/o some setting to override (say to forc= e serial).
> >>
> >> In the loader, when comconsole->c_init() is called for the= second
> >> time, the function does not return. (I commented out comconso= le to
> >> make the loader work, but it is rather brutal and is not a pr= oper
> >> solution).
> >> But the function parse_uefi_con_out() in stand/efi/loader/mai= n.c
> >> always returns RB_SERIAL, so the loader tries to use the seri= al
> >> console.
> >
> >
> > I wonder why that is. Is this -current or -stable? I have a rathe= r large backlog of MFC-able loader changes. If it is with stable, then it m= akes sense: I fixed a bug where parse_uefi_con_out would return serial if &= #39;8be4df61-93ca-11d2-aa0d-00e098032b8c-ConOut' was unset. Is it set?= =C2=A0 Now we return Video console if we fine evidence there's a video = console.
>
> It is stable/13.
> I tried 14-current, and the same change to loader was needed (merging<= br> > OpenBSD's start.S and ldscript.arm64, and commenting out comconsol= e).
> Even with these change, the console defaults to serial, so I changed > parse_uefi_con_out() to always return 0.
> Still, it stops at the same point. The kernel does not seem to boot. >
> Running efi-show from the loader prompt did not show
> '8be4df61-93ca-11d2-aa0d-00e098032b8c-ConOut'
> The variable name containing 'ConOut' were:
>
> global NV,BS,RS ConOut =3D
> VenHw(9042A9DE-23DC-4A38-96FB-7ADED080516A),/VenHw(857A8741-0EEC-43BD-= 0482-27D14ED47D72)/Uart(115200,8,N,1)
> global NV,BS,RS ConOutDev =3D
> VenHw(9042A9DE-23DC-4A38-96FB-7ADED080516A),/VenHw(857A8741-0EEC-43BD-= 0482-27D14ED47D72)/Uart(115200,8,N,1)
>
> > Now, why it fails the second time, I don't know.
> >
> >>
> >> If a similar thing happens with the kernel, it may be stoppin= g at
> >> serial console initialization.
> >
> >
> > The kernel doesn't use the EFI routines to initialize the ser= ial console. But if the kernel is being told the wrong console, then it cou= ld also be booting just fine or almost fine and hitting some bug later.
> >
> >>
> >> > Next most likely is that FreeBSD doesn't cope well w= ith having both FDT and ACPI information available. But since not DTB is be= ing passed in (per that message) that's not likely at play here.
> >>
> >> I managed to load the dtb file and the boot process stopped a= t the
> >> same point. The problem is not here?
> >
> >
> > Yea, I don't think so.
> >
> > Warner
> >
> >>
> >> > Finally, the loader passes a large number of tables, etc= to the kernel. It's quite possible that, for reasons still unknown, th= at data is wrong or if standard conforming not expected by the kernel. this= leads to a crash before we've setup the console in the kernel which lo= oks a lot like a hang.
> >> >
> >> > Warner
> >> >
> >> >
> >> >>
> >> >> > . . .
> >> >> >
> >> >> > Such also happens for stable/13, releng/13.* ba= sed installations
> >> >> > as well --and likely others too.
> >> >> >
> >> >> > ACPI booting does not use Device Tree informati= on but the messages
> >> >> > are output anyway about the lack. Only if you k= now that the context
> >> >> > is a Device Tree style of boot are the messages= actually reporting
> >> >> > a problem.
> >> >> >
> >> >> >
> >> >> > =3D=3D=3D
> >> >> > Mark Millard
> >> >> > marklmi at yahoo.com
> >> >> >
> >> >>
--000000000000eac9fb05f0201de7--