From nobody Thu Dec 08 18:18:45 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 4NSj8h2V3vz4k5dx for ; Thu, 8 Dec 2022 18:19:00 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com [IPv6:2a00:1450:4864:20::633]) (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 4NSj8f4F62z4Gx0 for ; Thu, 8 Dec 2022 18:18:57 +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=os0KLKjP; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2a00:1450:4864:20::633) smtp.mailfrom=wlosh@bsdimp.com; dmarc=none Received: by mail-ej1-x633.google.com with SMTP id bj12so5922736ejb.13 for ; Thu, 08 Dec 2022 10:18:57 -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=KFQUhafm0EcNZwgxKBH8VFNqUc+fkLZRs0wbNrx28Hw=; b=os0KLKjP1dzVxZIuHOdkaDEBQWo94pBWmkjs9jpp3EYwE6DNatHBVHA8PRkd7ooqyz 00MuqClvEDEVOIZDqyTrosJNB0K44o1xRw8wZWmIsSxkQdosNdddMggY3XRa8XzutcTt nMJYLeemlXAx4J5kzpeDx73K3a7J/fZ5fWFExast84naPRV3MOAUbhwKKanXHI4fF++B fkZiAE3qQ5gkCNREXlbrE96fO0BD/Q+QIXq9pzCB0ePZ3FNaWNnKIBkBbPAVpLnyaENX fx9s2AXKNhfMJLln6CWEzwgDJiiJsVAWxL5Pzarb62dO0nvavWSr01y6grT1cw1f4u2d pBhA== 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=KFQUhafm0EcNZwgxKBH8VFNqUc+fkLZRs0wbNrx28Hw=; b=cNy54DKspFlFZ+LIyOStAirfxYsGu3ey28xtuLqh7zLHsyS34OqnY3nYRyRIRF+joH lZYLuvCbRrYH0nPSHUExRtHXZZNe3mNy/WJo33zAVfPY12cnz8D9jxs+mkMJNT5mwV4M F6me2qfpcEG50u1keolIeH0T8EZEPNzoT5a5V+BkPd8aycoXiCpL7kJIy8O7rdRLz0yX xJ3DafsIYbT/T3XpOCt5xOYldL8DGg826um7WqKNcP4G8OL0nVs1kIEfGRhIT0+Ao1O/ vLKe7sXCh7ZKQEq0rp+01Bjbz8KxTnqWnVKkar0Mr6ftuI/SjVDfPnmU6/vd/xf0SDMi hHkA== X-Gm-Message-State: ANoB5pmU88M+i0W45SprvB5THFM5EkG+A72HkQNp8ZPdupBMeViuZHZn RzsSUHY8q/EFoTP4hAZ2n97BWIsob0Cc5IxCrqwBXdbydFnlmflc X-Google-Smtp-Source: AA0mqf5LSbdzpZ/IgQl++p+Zs9gweBb7WYPY5DrcP4yuSQRD1WmZxnW7fkYMydpHjjYmTQSZgtdcRuSh7MwvEI2+wgk= X-Received: by 2002:a17:906:29c3:b0:7c0:e0db:f136 with SMTP id y3-20020a17090629c300b007c0e0dbf136mr16127707eje.333.1670523535985; Thu, 08 Dec 2022 10:18:55 -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: Thu, 8 Dec 2022 11:18:45 -0700 Message-ID: Subject: Re: Succeeded to boot on Lenovo Yoga C630 To: hiroo.ono+freebsd@gmail.com Cc: Mark Millard , freebsd-arm@freebsd.org Content-Type: multipart/alternative; boundary="000000000000f39fbc05ef5511ed" X-Spamd-Result: default: False [-3.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; 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::633: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: 4NSj8f4F62z4Gx0 X-Spamd-Bar: -- X-ThisMailContainsUnwantedMimeParts: N --000000000000f39fbc05ef5511ed Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Dec 7, 2022 at 4:21 PM Hiroo Ono (=E5=B0=8F=E9=87=8E=E5=AF=9B=E7=94= =9F) 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+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 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 i= f > 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 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 if '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. 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 both 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 o= r > 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 han= g. > > > > Warner > > > > > >> > >> > . . . > >> > > >> > 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. > >> > > >> > > >> > =3D=3D=3D > >> > Mark Millard > >> > marklmi at yahoo.com > >> > > >> > --000000000000f39fbc05ef5511ed Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
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 <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 text=3D0x1f97ac >> data=3D0x1a6ac0 data=3D0x0+0x381000 syms=3D[0x8+0x11f6a0+0x8+0x143= 9ea]
>> 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 fou= nd!
>> EFI framebuffer information
>> addr, size=C2=A0 =C2=A0 =C2=A0 =C2=A0 0x80400000, 0x7e9000
>> 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 0x00ff0000, 0x0000f= f00, 0x000000ff, 0xff000000
>>
>> and it stops here. No "<<BOOT>>" line is dis= played.
>> 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 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 chang= es. If it is with stable, then it makes sense: I fixed a bug where parse_ue= fi_con_out would return serial if '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.

Now, wh= y it fails the second time, I don't know.
=C2=A0
If a similar thing happens with the kernel, it may be stopping at
serial console initialization.

The kern= el doesn't use the EFI routines to initialize the serial console. But i= f the kernel is being told the wrong console, then it could also be booting= just fine or almost fine and hitting some bug later.
=C2=A0
> 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?

Ye= a, I don't think so.

Warner
=C2=A0
> 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 wro= ng or if standard conforming not expected by the kernel. this leads to a cr= ash 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 installati= ons
>> > as well --and likely others too.
>> >
>> > ACPI booting does not use Device Tree information but the mes= sages
>> > are output anyway about the lack. Only if you know that the c= ontext
>> > is a Device Tree style of boot are the messages actually repo= rting
>> > a problem.
>> >
>> >
>> > =3D=3D=3D
>> > Mark Millard
>> > marklmi at yahoo.com
>> >
>>
--000000000000f39fbc05ef5511ed--