From nobody Fri Dec 09 00:25:10 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 4NSsHS4s5Bz4jtXf for ; Fri, 9 Dec 2022 00:25:24 +0000 (UTC) (envelope-from hiroo.ono@gmail.com) Received: from mail-pf1-x434.google.com (mail-pf1-x434.google.com [IPv6:2607:f8b0:4864:20::434]) (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 4NSsHS2wQ7z3xfM for ; Fri, 9 Dec 2022 00:25:24 +0000 (UTC) (envelope-from hiroo.ono@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pf1-x434.google.com with SMTP id 65so2560068pfx.9 for ; Thu, 08 Dec 2022 16:25:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :reply-to:in-reply-to:references:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=5FS/8vO4EvHe16L/caWWL+q+9XuyA6qr6/SXMlVejUo=; b=H2b+WSWZ5WRxZfpgKT8p/GJ42IJYAryHUQfZRQsK6iUEaPh4D19bGOGGOgFXXbY5bA yHMhaHSZcN9RZrXPlo4/DQPyQvdPdO+fh3Ix1LSey7KhBSGyWkNKNUv+D4zD7Vc9h90n VUYh46kiWFb/7F7UM8+aBfWQ9ohjzYtKgzO2ivsjWC7v2PKsbkk4pYlWzlnSgITaNjB9 Siu043PQ/p+43H8EdwVuLXCMjTLWw8p64n+RJ6OaJVdJCbhgehtscYalejtVa1m65YJ7 WoMJfekxlGuo6GbIzGqShHOS3CeysyrXTGflNy1YCqDGhm3iZf1WybJzFFevBCKcXFV8 D/Mg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :reply-to:in-reply-to:references:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=5FS/8vO4EvHe16L/caWWL+q+9XuyA6qr6/SXMlVejUo=; b=SHv2VkFb3m6QzPoLEpOENIfdfu6QTSIY6TDOL+AbCWvaTpqKdKwroJ2I4vEnwf7asF KseBo4B69KA7BVVgDkAOUZ8lwPqlqBQQvoe1MY5Kp/5Ty/RrAL6i3fObBLEejr9mIPBi P9yluY6+Q5S65IHJJiaMYtnd7o2gEHo2Z0M2ONY7amEoNKhXZL6h4r5MaJr7VFvSki8F gDDMYk4jsMcN23LVNcyBYovEyNSesJzQykCGD0DTyU4u1dQ8gLfe/fOtjZOElhWoCH4Z r3NgyhPJxAz8jPwW62BVt2mXpQlj4W0+W0OjONLMaC0D9bKUs9wFQdWcNxOaraeQA4dQ wj1w== X-Gm-Message-State: ANoB5pl4cwmA8cuMFh2v+ToL32VTH+1pikSaiPBnxNP4ZlSqaX7c+W5y KRBXUPOM62i/gQD3vLwsphrJ+sDZxDAPTIe9pqM= X-Google-Smtp-Source: AA0mqf6+3O5xWelCIbR+UHwB4b37Xa/E1OkbjN05qQXG97iNRid0cIp4OeiTk1C4c/Vqs4u98ysQHJ+7w5yLoygS+Vo= X-Received: by 2002:a63:f453:0:b0:478:d3a8:6ba5 with SMTP id p19-20020a63f453000000b00478d3a86ba5mr12672090pgk.619.1670545522461; Thu, 08 Dec 2022 16:25:22 -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: Reply-To: hiroo.ono+freebsd@gmail.com From: =?UTF-8?B?SGlyb28gT25vICjlsI/ph47lr5vnlJ8p?= Date: Fri, 9 Dec 2022 09:25:10 +0900 Message-ID: Subject: Re: Succeeded to boot on Lenovo Yoga C630 To: Warner Losh Cc: Mark Millard , freebsd-arm@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4NSsHS2wQ7z3xfM X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TAGGED_FROM(0.00)[freebsd] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N 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) 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) 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 = 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 changes. If it is with stable, then it makes sen= se: 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 V= ideo 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-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 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 b= ooting just fine or almost fine and hitting some bug later. > >> >> > Next most likely is that FreeBSD doesn't cope well with having both FD= T 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 hang. >> > >> > 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 >> >> > >> >>