Date: Fri, 9 Dec 2022 09:25:10 +0900 From: =?UTF-8?B?SGlyb28gT25vICjlsI/ph47lr5vnlJ8p?= <hiroo.ono+freebsd@gmail.com> To: Warner Losh <imp@bsdimp.com> Cc: Mark Millard <marklmi@yahoo.com>, freebsd-arm@freebsd.org Subject: Re: Succeeded to boot on Lenovo Yoga C630 Message-ID: <CANtk6ShzbOcw%2B86J_M_AQeDHU36ptQG%2Bj7XndYzhCJ3E0N0Qqw@mail.gmail.com> In-Reply-To: <CANCZdfpKnxeRp3RtPGrq%2BsCMqXjq0AnYWuN2orHt1qt57KRh0Q@mail.gmail.com> References: <CANtk6SgUoqC_Jgdtu=CZnFvnLzqP445MQqfwhV5%2BBgX_%2BVFUZA@mail.gmail.com> <B55013C7-B04C-48E4-BC0F-C106DA08348F@yahoo.com> <CANtk6Shwaea09TiTZq3UZwzCoXjm8TqkA930QQwS_i3_Awd5bg@mail.gmail.com> <CANCZdfqpTW3AVHPfHPWOEpEW2QPTE6aADGNzhH=pQT4btA1%2BvQ@mail.gmail.com> <CANtk6Si4Eg3vd4j3wvgCt%2BoodpNK7ikei-XikEmXPMdQUane3w@mail.gmail.com> <CANCZdfpKnxeRp3RtPGrq%2BsCMqXjq0AnYWuN2orHt1qt57KRh0Q@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 Losh <imp@bsdi= mp.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+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 "<<BOOT>>" 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 >> >> > >> >>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANtk6ShzbOcw%2B86J_M_AQeDHU36ptQG%2Bj7XndYzhCJ3E0N0Qqw>