From nobody Sun Dec 18 11:31:01 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 4NZgdc215hzt0Sx for ; Sun, 18 Dec 2022 11:31:16 +0000 (UTC) (envelope-from hiroo.ono@gmail.com) Received: from mail-pj1-x1029.google.com (mail-pj1-x1029.google.com [IPv6:2607:f8b0:4864:20::1029]) (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 4NZgdb05FYz3jVN for ; Sun, 18 Dec 2022 11:31:15 +0000 (UTC) (envelope-from hiroo.ono@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=abSJynl3; spf=pass (mx1.freebsd.org: domain of hiroo.ono@gmail.com designates 2607:f8b0:4864:20::1029 as permitted sender) smtp.mailfrom=hiroo.ono@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-pj1-x1029.google.com with SMTP id u5so6514913pjy.5 for ; Sun, 18 Dec 2022 03:31:14 -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=E2sy6h94J4kBBATzpOr99wydn/rzPNwmtx8+48p+QSI=; b=abSJynl38eAgVOV4LSWiIoxoWw/6qMoNoYeUmPO8pn7mCH0jKmzO7/1a27R8UQPyey JGO5TiTaMn5HhlMoJO8XsF8IY/N/WxK5FmnBCfy9hvQHUsH1SDa+CDVr2yDwROGs5W4L quJ9ck1Vf1yLoeyBxx6viVukPkA83S3sb8ns0XzPTC/9SYBzugemt7wbITpBrrHC5Hrb LxMapdZJa6gPIoAzl9t+mTJ1izHhgqYS3yuH6n0ZlS2k+37jmwF2V215XAX/+LSzvGJ9 ogtSJ02L/pISy4N12fNT1Nw7P+z85gFPVCyGbXpeFRHKHLuuZFfike7/evmhYF+q87S1 QBlQ== 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=E2sy6h94J4kBBATzpOr99wydn/rzPNwmtx8+48p+QSI=; b=iXcpZDFR6tqd/kSSszQuhPbr82K9JuLqf6tFVPJfdLAubriML96TZKLPh5Kg8QWP4a FPP2bMP0t+O1XctIi22YGK929aS2ICp8iXdUYuJYTp1hbC301cyapRFES7FM2EBBWL3U EnwQStp9pYlGTyEB2piQP043UlmLLVfblxdgQtB08bXwLZk9ccNqODM1CcKLjSQXlXGQ k/3S0qkk9BnYv5SLK9rhYA6tu2PCjywfphnQ8TjrSPrsxLCXklqsCoKtwCeQZyhpRD4a ptOgK2gwtTrqutvlPdlK++bUIduS+iC1sXJ6NBRVaxDp5CwdCK2XJWYDUhQ8Dm5Gr3jU zUNQ== X-Gm-Message-State: ANoB5pmj2tKfv2ncaQNW94PQTK92dA7I48IBl5qiu1PbLRJtubOo5+4o +W1bvXrE4ltMQ5L19Bp5cgnHTa44xS7jcSByEggLaNZVtKE= X-Google-Smtp-Source: AA0mqf4aijNUYoVU2GSF1gdUiI2phJNQxU66vjpE4maZSFT/wV0fm8+m4cIfceWsxnkAe5lKvjeRtLAhNqaVP9xMK6g= X-Received: by 2002:a17:902:f78c:b0:186:8c13:50b3 with SMTP id q12-20020a170902f78c00b001868c1350b3mr80357621pln.153.1671363073399; Sun, 18 Dec 2022 03:31:13 -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: Sun, 18 Dec 2022 20:31:01 +0900 Message-ID: Subject: Still did not succeed 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-Spamd-Result: default: False [-3.08 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_SHORT(-0.08)[-0.078]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; HAS_REPLYTO(0.00)[hiroo.ono+freebsd@gmail.com]; FREEMAIL_REPLYTO(0.00)[gmail.com]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::1029:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; ARC_NA(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; RCVD_COUNT_TWO(0.00)[2]; REPLYTO_ADDR_EQ_FROM(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MIME_TRACE(0.00)[0:+]; TAGGED_FROM(0.00)[freebsd]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FREEMAIL_ENVFROM(0.00)[gmail.com]; FREEMAIL_CC(0.00)[yahoo.com,freebsd.org] X-Rspamd-Queue-Id: 4NZgdb05FYz3jVN X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N 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. The loader freezed in efi_do_vmap(), so I needed to add efi_disable_vmap=3D"YES" in loader.conf. 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. 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. 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) 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+0x1439= ea] > >> >> 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 foun= d! > >> >> 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. Thoug= h if you are on the video display and getting that framebuffer output, it w= on'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 larg= e backlog of MFC-able loader changes. If it is with stable, then it makes s= ense: I fixed a bug where parse_uefi_con_out would return serial if '8be4df= 61-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 consol= e. 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 (p= er 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 kern= el. 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 cras= h 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 message= s > >> >> > are output anyway about the lack. Only if you know that the conte= xt > >> >> > is a Device Tree style of boot are the messages actually reportin= g > >> >> > a problem. > >> >> > > >> >> > > >> >> > =3D=3D=3D > >> >> > Mark Millard > >> >> > marklmi at yahoo.com > >> >> > > >> >>