Date: Sun, 25 Dec 2022 10:46:37 +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: Still did not succeed to boot on Lenovo Yoga C630 Message-ID: <CANtk6SgK6n75PQ94M8CPKY5vCCEs_viQMFsJxW1kZ%2B412ee9AA@mail.gmail.com> In-Reply-To: <CANCZdfrF8P0FgU-E-n8hgNVshg3BBJuCuYOdTwEz4DMQ3mPDvg@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> <CANtk6ShVXDHt5K0UoGaMgw0o_w3HPCMPGYdu-m1hCUkZ3ZMcUQ@mail.gmail.com> <CANCZdfqyMUUDVgg4YHZNaXGVb9E8TXmFH0jtQuXN0TkCti46vQ@mail.gmail.com> <CANtk6SgeCFSwkRpXDd9DsR%2BN%2BNNa_c9pm6-8u6c9Q2au0ZiWZA@mail.gmail.com> <CANCZdfrF8P0FgU-E-n8hgNVshg3BBJuCuYOdTwEz4DMQ3mPDvg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
2022=E5=B9=B412=E6=9C=8824=E6=97=A5(=E5=9C=9F) 10:03 Warner Losh <imp@bsdim=
p.com>:
>
>
>
> On Fri, Dec 23, 2022 at 5:49 PM Hiroo Ono (=E5=B0=8F=E9=87=8E=E5=AF=9B=E7=
=94=9F) <hiroo.ono+freebsd@gmail.com> wrote:
>>
>> The current status of FreeBSD 14-current on Lenovo Yoga C630 is as follo=
ws:
>>
>> 1) Merging from OpenBSD's loader code made the loader boot apart from
>> 3 points (#2 to 4 ).
>> 2) when comconsole->c_init() runs the 2nd time, it seems to freeze.
>> (might be C630 specific)
>> 3) SetVirtualAddressMap() in efi_do_vmap() freezes. (might also
>> affect other snapdragon systems like Microsoft Arm Developer Kit)
>> 4) The kernel is kicked but does not start.
>>
>> 1) is quite straightforward. What needs to be changed is
>> stand/efi/loader/arch/arm64/start.S.
>
>
> Can you share what needs to be done? To my eye, we don't need any changes=
, so it would be good to know what you've had to do exactly.
>
>>
>> For 2), I do not know what to do. Currently, I commented out
>> comconsole from struct console *consoles[] in stand/efi/loader/conf.c
>> as a workaround. Maybe, I should write a fault handler that helps
>> returning from the fault.
>
>
> There were problems with this with HyperV on aarch64 too.
>
> Something like
> diff --git a/stand/efi/loader/efiserialio.c b/stand/efi/loader/efiseriali=
o.c
> index 8b3f8e83e0b3..54ee39096685 100644
> --- a/stand/efi/loader/efiserialio.c
> +++ b/stand/efi/loader/efiserialio.c
> @@ -261,11 +261,11 @@ comc_probe(struct console *sc)
> if (comc_port =3D=3D NULL)
> return;
> }
> - comc_port->baudrate =3D COMSPEED;
> + comc_port->baudrate =3D 0;
> comc_port->ioaddr =3D 0; /* default port */
> - comc_port->databits =3D 8; /* 8,n,1 */
> - comc_port->parity =3D NoParity; /* 8,n,1 */
> - comc_port->stopbits =3D OneStopBit; /* 8,n,1 */
> + comc_port->databits =3D 0; /* 8,n,1 */
> + comc_port->parity =3D 0; /* 8,n,1 */
> + comc_port->stopbits =3D 0; /* 8,n,1 */
> comc_port->ignore_cd =3D 1; /* ignore cd */
> comc_port->rtsdtr_off =3D 0; /* rts-dtr is on */
> comc_port->sio =3D NULL;
>
> was needed. Possibly the following would be better:
>
> diff --git a/stand/efi/loader/efiserialio.c b/stand/efi/loader/efiseriali=
o.c
> index 8b3f8e83e0b3..54ee39096685 100644
> --- a/stand/efi/loader/efiserialio.c
> +++ b/stand/efi/loader/efiserialio.c
> @@ -494,8 +494,7 @@ comc_setup(void)
> return (false);
>
> status =3D comc_port->sio->SetAttributes(comc_port->sio,
> - comc_port->baudrate, 0, 0, comc_port->parity,
> - comc_port->databits, comc_port->stopbits);
> + 0, 0, 0, 0, 0, 0);
> if (EFI_ERROR(status))
> return (false);
Following change could avoid freeze in comconsole->c_init().
----------
--- a/stand/efi/loader/efiserialio.c
+++ b/stand/efi/loader/efiserialio.c
@@ -467,8 +467,10 @@ comc_speed_set(struct env_var *ev, int flags,
const void *value)
if (comc_parse_intval(value, &speed) !=3D CMD_OK)
return (CMD_ERROR);
- comc_port->baudrate =3D speed;
- (void) comc_setup();
+ if (comc_port->baudrate !=3D speed) {
+ comc_port->baudrate =3D speed;
+ (void) comc_setup();
+ }
env_setenv(ev->ev_name, flags | EV_NOHOOK, value, NULL, NULL);
----------
comc_speed_set sets new speed to comc_port->baudrate and calls comc_setup()=
.
But if the new value of comc_port->baudrate is same as the previous
one, comc_setup() freezes at
status =3D comc_port->sio->GetControl(comc_port->sio, &control);
Now, the remaining problem is that the kernel does not start.
Linux and OpenBSD run on the machine, so there should be a solution...
>> 3), I dumped each memory map's VirtualStart and PhysicalStart. All
>> VirtualStart were 0. So overwriting VirutalStart by the value of
>> PhysicalStart and running SetVirtualAddressMap should work. But in
>> reality, it doesn't.
>> OpenBSD does not use SetVirtualAddress for arm64 and Linux seems to
>> have abandoned it for arm64 in 2019.
>> https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?=
id=3D4e46c2a956215482418d7b315749fb1b6c6bc224
>> Maybe, we also can avoid SetVirtualAddressMap (by
>> efi_disable_vmap=3D"YES"). In this case, (as you wrote) I should change
>> the kernel to treat VA=3D=3DPA if VirtualStart is 0. (OpenBSD seems to d=
o
>> so).
>
>
> FreeBSD tends to prefer this... Our kernel needs to cope with cases where=
it has
> been called (many kexec environments provide PA !=3D VA virtual mappings =
that we
> can't change).
>
>>
>> About 4), I am completely confused. In elf64_exec in
>> stand/efi/loader/arch/arm64/exec.c, the memory address that the kernel
>> was loaded is calculated as:
>> entry =3D efi_translate(ehdr->e_entry); // which becomes 0xb340000
>> and later kicked as:
>> (*entry)(modulep);
>> I wrote that this calculation is doubtful, but it was right. I dumped
>> the data at the address 0xb340000 and compared it with the output of
>> objdump -D loader_lua.syms. It turned out that it matched with the
>> kernel's _start code in locore.S.
>> Putting some code that jumps to loader's ImageBase address at the
>> start of kernel's _start did not change anything, so I judged that the
>> kernel is not started at all.
>> The excerpt of the loader's memmap command output is as follows:
>> Type Physical Virtual #Pages At=
tr
>> LoaderData 0000b33ea000 000000000000 00000000 UC WC WT WB WP RP X=
P
>> LoaderCode 0000bb909000 000000000000 000000d1 UC WC WT WB WP RP XP
>> From this output, I wonder if the memory attributes on Yoga C630 is
>> properly implemented, but as XP (exec protect) bit is on, I tried to
>> set it off by DXE services' SetMemoryAttributes() (with a lot of
>> transcription from the standards...).It succeeded, but the kernel
>> still did not run.
>>
>> From this tweet:
>> https://twitter.com/canadianbryan/status/1598053941270679552 and its
>> replies, the Microsoft Arm Developer Kit seems to have similar
>> problem, so if somebody succeeded to run FreeBSD on it, please share
>> the information how to do it.
>
>
> I run other arm64 machines w/o issue with the current code. I've not hear=
d from Allan
> for his changes, nor seen any reviews come through...
>
> Where can one buy one of these systems. It seems just odd-ball enough tha=
t I can
> justify picking one up for work...
Currently, a Snapdragon system easy to purchase is the Microsoft Arm
Developer Kit, I suppose. It is about $600.
For laptops, Qualcomm has a list:
https://www.qualcomm.com/products/application/mobile-computing/laptop-devic=
e-finder
> Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANtk6SgK6n75PQ94M8CPKY5vCCEs_viQMFsJxW1kZ%2B412ee9AA>