Date: Sun, 18 Dec 2022 20:31:01 +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: Still did not succeed to boot on Lenovo Yoga C630 Message-ID: <CANtk6ShVXDHt5K0UoGaMgw0o_w3HPCMPGYdu-m1hCUkZ3ZMcUQ@mail.gmail.com> In-Reply-To: <CANtk6ShzbOcw%2B86J_M_AQeDHU36ptQG%2Bj7XndYzhCJ3E0N0Qqw@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> <CANtk6ShzbOcw%2B86J_M_AQeDHU36ptQG%2Bj7XndYzhCJ3E0N0Qqw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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) <hiroo.ono+freebsd@gmail.com>: > > 2022=E5=B9=B412=E6=9C=889=E6=97=A5(=E9=87=91) 3:19 Warner Losh <imp@bsdim= p.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@bs= dimp.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+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 "<<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. 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 > >> >> > > >> >>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANtk6ShVXDHt5K0UoGaMgw0o_w3HPCMPGYdu-m1hCUkZ3ZMcUQ>