From nobody Sat Dec 24 01:03:07 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 4Nf5QK0WWvz1H4bj for ; Sat, 24 Dec 2022 01:03:21 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) (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 4Nf5QJ1QJ7z3JT2 for ; Sat, 24 Dec 2022 01:03:20 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=nCxqt2zT; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2a00:1450:4864:20::532) smtp.mailfrom=wlosh@bsdimp.com; dmarc=none Received: by mail-ed1-x532.google.com with SMTP id q15so7404621edb.1 for ; Fri, 23 Dec 2022 17:03:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=8ix29Dywhtk3KwjKzsgmPOLMrVmzKq2lyZHXkJrDpwc=; b=nCxqt2zT3oUm9apO6wnSZCbZhfQRxdU+0OVf5XfgHKMp7GQmN/V0yIxYODY/ReLaeG 2s+yCpW2JpDRZr/hoAWUrkO3U0mT/CQkh13PpEVzW9eRZD0hJJpIaSnvlyD90Zdx9+oR bynKvjtSt9Gc03rqmvtD+99UzpQe/LsRvZrF98bqnh5H5m8Wm35L89IUxRw2Fv5WGWNY IUcG1Hv8NAf4t/orI8hhKl5lf5ISdSb7M90+wzz2qlOSMeSGy1C733BL53mV9m3xvv+Y FTuPOIcZD5eTP7pyJFR8DRLlUAbnwdvIqOz2eN5zEgjpYV6sPbRaH81SIWQI6bTmfSBC 8Rhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=8ix29Dywhtk3KwjKzsgmPOLMrVmzKq2lyZHXkJrDpwc=; b=cwFMIx1aqZcHHupDodjeex4FP0wnA+zeylHMKdSA8iNq4wg0Hf+MyDKncHOSzvJKyB xot0aDUhuFXMtPjVy0++SfXgQOIx2rrjiVVZf//AV0pk8jk/Z3+DVsobwsVAUETAa7sW MrrKDUA45PgtwfFVrucOYPODUI76YVsVo3Z2e3XEkdjBnU8VJFcmFRBC+V437cooTgWd TAGh/w9vuy+BhXUjnbN/hR3esNTFxsW1qgD1nskSg5O1cbtf5RpsBKSyJxrIiYP7EJzi El+q2Pkh9WKH9pz9Nxfd38Q+Yj8VeDDNdJ5pNe9yDKbBzKIi1SeqBAdVLsJ3oCgMTQjh sOVA== X-Gm-Message-State: AFqh2kqEcObhMTnbah+RLxc8z6h3eDaoTfBWfxIZIC7df6YvbRuCFMMI pFU3QqBobI2beaN8YkZo5iLPdHIcf6WUj6xC0xnDvQ== X-Google-Smtp-Source: AMrXdXvDSy+VUqDjtpi4+MNciGwenhxJSaNjr+hP0iGAHwgjb3fJB+QtCMkM5VC0yRWwLAbAU3PpU4G85IMgBAJN500= X-Received: by 2002:a05:6402:b18:b0:46b:1396:e132 with SMTP id bm24-20020a0564020b1800b0046b1396e132mr1336403edb.421.1671843798239; Fri, 23 Dec 2022 17:03:18 -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: From: Warner Losh Date: Fri, 23 Dec 2022 18:03:07 -0700 Message-ID: Subject: Re: Still did not succeed to boot on Lenovo Yoga C630 To: hiroo.ono+freebsd@gmail.com Cc: Mark Millard , freebsd-arm@freebsd.org Content-Type: multipart/alternative; boundary="000000000000b6dfee05f0887747" X-Spamd-Result: default: False [-3.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-0.998]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; FREEMAIL_TO(0.00)[gmail.com]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; R_SPF_NA(0.00)[no SPF record]; FREEMAIL_CC(0.00)[yahoo.com,freebsd.org]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::532:from]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; FROM_HAS_DN(0.00)[]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; TO_DN_SOME(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; TAGGED_RCPT(0.00)[freebsd]; DMARC_NA(0.00)[bsdimp.com]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4Nf5QJ1QJ7z3JT2 X-Spamd-Bar: -- X-ThisMailContainsUnwantedMimeParts: N --000000000000b6dfee05f0887747 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 follow= s: > > 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/efiserialio.= 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/efiserialio.= 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); > 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=3D= 4e46c2a956215482418d7b315749fb1b6c6bc224 > 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 do > 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 th= at 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 Att= r > LoaderData 0000b33ea000 000000000000 00000000 UC WC WT WB WP RP XP > 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 heard 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 that I can justify picking one up for work... Warner > 2022=E5=B9=B412=E6=9C=8819=E6=97=A5(=E6=9C=88) 5:33 Warner Losh : > > > > > > > > > On Sun, Dec 18, 2022 at 4:31 AM Hiroo Ono (=E5=B0=8F=E9=87=8E=E5=AF=9B= =E7=94=9F) < > hiroo.ono+freebsd@gmail.com> wrote: > >> > >> 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. > > > > > > Keep at it... > > > >> > >> The loader freezed in efi_do_vmap(), so I needed to add > >> efi_disable_vmap=3D"YES" in loader.conf. > > > > > > No. The code for this needs to be fixed... More on that in a second... > > > >> > >> 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. > > > > > > Yea, I think this is wrong. > > > >> > >> 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. > > > > > > So there's two things going on here. First is that on arm64 we should > *NEVER* copy the > > kernel. It loads at a specific address and we jump to where it loaded i= n > RAM (in your case, > > I think it should be stage_offset + (ehdr->e_entry - KERNBASE). Kernbas= e > is 0xffff000000000000 > > so we should jump to 0x10000brre0000 + 0x20000 (or maybe 0x800 is you > suggest). The kernel > > code that's there should do some tricks to find out where it was loaded= , > turn on the MMU and > > then jump to the VA to continue starting up the kernel. The arm64 kerne= l > is linked with a VA. Old amd64 > > kernels expected to start at a fixed physical address, but the UEFI spe= c > allows memory to be mapped anywhere > > which means it was recently switched to create a page table in the boot > loader, then jump to the right > > VA, and use the page table to find what PA that is and use that to > bootstrap the pmap. This works great on > > amd64, but sometimes goes astray on arm64 (though the way it does for > you doesn't make sense > > to me). The amd64 code used to start at a PA, and that's what the 'copy= ' > routine is supposed to do: > > copy the kernel down that fixed address and jump to it. I don't think > we'll ever want that on arm64, though, > > and that might also be getting in your way (thought I'm doing this from > memory w/o careful study of > > the code because it's fresh in my mind due to getting arm64 working wit= h > linuxboot). > > > > Also, vmap *MUST* be called in the boot loader. The trouble is, it > assumes VA =3D=3D PA, but that's not > > strictly true. If you boot via LinuxBoot, for example, it has a memory > mapping that's not VA =3D=3D PA so > > at least some parts of the kernel fail their VA =3D=3D PA asserts. the = vmap > code in the loader currently > > blindly assumes VA =3D=3D PA, but it should, IMHO, only do that if the = VA > from entry from the table from > > the get memory map call is 0. Today it blindly overwrites it. You might > try changing that, and removing > > the bit in the kernel that checks for VA =3D=3D PA and bails out if the= re's > a mismatch. Here's the patch I'm > > temporarily using until I have the time to do more than a quick, > superficial analysis of the issue: > > > > diff --git a/sys/arm64/arm64/efirt_machdep.c > b/sys/arm64/arm64/efirt_machdep.c > > index 727c9c37f94d..075174d164d8 100644 > > --- a/sys/arm64/arm64/efirt_machdep.c > > +++ b/sys/arm64/arm64/efirt_machdep.c > > @@ -193,8 +193,8 @@ efi_create_1t1_map(struct efi_md *map, int ndesc, > int descsz) > > continue; > > if (p->md_virt !=3D 0 && p->md_virt !=3D p->md_phys) { > > if (bootverbose) > > - printf("EFI Runtime entry %d is > mapped\n", i); > > - goto fail; > > + printf("EFI Runtime entry %d is mapped > PA %#lx VA %#lx\n", i, p->md_phys, p->md_virt); > > +// goto fail; > > } > > if ((p->md_phys & EFI_PAGE_MASK) !=3D 0) { > > if (bootverbose) > > > > clearly, not suitable for upstreaming, eh? And I have about 2 dozen > commits in my queue ahead of that > > one that need refinement, review and upstreaming before I jump into thi= s > issue. It will be after the first > > of the year at least before I'll look at it since I just started my > year-end vacation... > > > > Warner > > > >> > >> 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) < > hiroo.ono+freebsd@gmail.com> 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) < > 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=3D0x1f97= ac > >> > >> >> data=3D0x1a6ac0 data=3D0x0+0x381000 syms=3D[0x8+0x11f6a0+0x8+0= x1439ea] > >> > >> >> 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, 0xff00000= 0 > >> > >> >> > >> > >> >> and it stops here. No "<>" line is displayed. > >> > >> >> So, it seems that the kernel is loaded but could not be starte= d. > >> > >> > > >> > >> > > >> > >> > 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 outpu= t, > 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 t= o > >> > >> 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 sense: I fixed a bug where parse_uefi_con_out would return serial i= f > '8be4df61-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 (mergin= g > >> > 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 > console. 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 passe= d > in (per that message) that's not likely at play here. > >> > >> > >> > >> I managed to load the dtb file and the boot process stopped at th= e > >> > >> 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 or 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 > >> > >> >> > > >> > >> >> > --000000000000b6dfee05f0887747 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
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:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">The current status of Free= BSD 14-current on Lenovo Yoga C630 is as follows:

=C2=A01) Merging from OpenBSD's loader code made the loader boot apart = from
3 points (#2 to 4 ).
=C2=A02) when comconsole->c_init() runs the 2nd time, it seems to freeze= .
(might be C630 specific)
=C2=A03) SetVirtualAddressMap() in efi_do_vmap() freezes. (might also
affect other snapdragon systems like Microsoft Arm Developer Kit)
=C2=A04) 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.

Ca= n 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.
= =C2=A0
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 pr= oblems with this with HyperV on aarch64 too.

Somet= hing like
diff --git a/stand/efi/loader/efiserialio.c b/stand/efi= /loader/efiserialio.c
index 8b3f8e83e0b3..54ee39096685 100644
--- a/s= tand/efi/loader/efiserialio.c
+++ b/stand/efi/loader/efiserialio.c
@@= -261,11 +261,11 @@ comc_probe(struct console *sc)
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (comc_port =3D=3D NULL)
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 r= eturn;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
- =C2=A0 =C2=A0 =C2=A0 comc_port= ->baudrate =3D COMSPEED;
+ =C2=A0 =C2=A0 =C2=A0 comc_port->baudrat= e =3D 0;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 comc_port->ioaddr =3D 0; =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/* default port */- =C2=A0 =C2=A0 =C2=A0 comc_port->databits =3D 8; =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/* 8,n,1 */
- =C2=A0 =C2=A0 =C2=A0 co= mc_port->parity =3D NoParity; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /* 8,n,= 1 */
- =C2=A0 =C2=A0 =C2=A0 comc_port->stopbits =3D OneStopBit; =C2= =A0 =C2=A0 =C2=A0 /* 8,n,1 */
+ =C2=A0 =C2=A0 =C2=A0 comc_port->datab= its =3D 0; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/* 8,n,1 = */
+ =C2=A0 =C2=A0 =C2=A0 comc_port->parity =3D 0; =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0/* 8,n,1 */
+ =C2=A0 =C2=A0 =C2=A0 comc_port->stopbi= ts =3D 0; =C2=A0 =C2=A0 =C2=A0 =C2=A0/* 8,n,1 */
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 comc_port->ignore_cd =3D 1; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 /* ignore cd */
=C2=A0 =C2=A0 =C2=A0 =C2=A0 comc_port->= rtsdtr_off =3D 0; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/* rts-dt= r is on */
=C2=A0 =C2=A0 =C2=A0 =C2=A0 comc_port->sio =3D NULL;

was needed.=C2=A0 Possibly the following would be b= etter:

diff --git a/stand/efi/loader/efiserialio.c b/stand/efi/loa= der/efiserialio.c
index 8b3f8e83e0b3..54ee39096685 100644
--- a/stand= /efi/loader/efiserialio.c
+++ b/stand/efi/loader/efiserialio.c
@= @ -494,8 +494,7 @@ comc_setup(void)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 return (false);

=C2=A0 =C2=A0 =C2=A0 =C2=A0 sta= tus =3D comc_port->sio->SetAttributes(comc_port->sio,
- =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 comc_port->baudrate, 0, 0, comc_port->par= ity,
- =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 comc_port->databits, comc_p= ort->stopbits);
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 0, 0, 0, 0, 0, 0= );
=C2=A0 =C2=A0 =C2=A0 =C2=A0 if (EFI_ERROR(status))
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return (false);
=C2=A0
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.
=C2=A0 OpenBSD does not use SetVirtualAddress for arm64 and Linux seems to<= br> have abandoned it for arm64 in 2019.
=C2=A0 =C2=A0 https://git.kernel.org/pub/scm/linux/kernel/git/= tip/tip.git/commit/?id=3D4e46c2a956215482418d7b315749fb1b6c6bc224
=C2=A0 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 do so).

FreeBSD tends to prefer this... Ou= r kernel needs to cope with cases where it has
been called (many = kexec environments provide PA !=3D VA virtual mappings that we
ca= n't change).
=C2=A0
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:
=C2=A0 =C2=A0 entry =3D efi_translate(ehdr->e_entry);=C2=A0 // which bec= omes 0xb340000
and later kicked as:
=C2=A0 =C2=A0 (*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<= br> kernel is not started at all.
The excerpt of the loader's memmap command output is as follows:
=C2=A0 =C2=A0 Type=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Physical=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Virtual=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 #Pages=C2=A0 =C2=A0 =C2=A0Attr
=C2=A0 =C2=A0 LoaderData 0000b33ea000=C2=A0 000000000000=C2=A0 00000000=C2= =A0 UC WC WT WB WP RP XP
=C2=A0 =C2=A0 LoaderCode 0000bb909000=C2=A0 000000000000=C2=A0 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 oth= er arm64 machines w/o issue with the current code. I've not heard from = Allan
for his changes, nor seen any reviews come through...
=

Where can one buy one of these systems.=C2=A0It seems j= ust odd-ball enough that I can
justify picking one up for work...=

Warner
=C2=A0
2022=E5=B9=B412=E6=9C=8819=E6=97=A5(=E6=9C=88) 5:33 Warner Losh <imp@bsdimp.com>:

>
>
>
> On Sun, Dec 18, 2022 at 4:31 AM Hiroo Ono (=E5=B0=8F=E9=87=8E=E5=AF=9B= =E7=94=9F) <hiroo.ono+freebsd@gmail.com> wrote:
>>
>> 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.
>
>
> Keep at it...
>
>>
>> The loader freezed in efi_do_vmap(), so I needed to add
>> efi_disable_vmap=3D"YES" in loader.conf.
>
>
> No. The code for this needs to be fixed...=C2=A0 More on that in a sec= ond...
>
>>
>> At last, in elf64_exec, it tried to run (*entry)(modulep) where th= e
>> 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 0xffff000000000= 800,
>> but I modified a little) and
>> stage_offset was 0x10000b33e0000.
>> The sum of two which efi_translate() returns is 0x100000000b340000= 0.
>> It overflows uint64_t and becomes 0xb3400000.
>
>
> Yea, I think this is wrong.
>
>>
>> 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.
>
>
> So there's two things going on here. First is that on arm64 we sho= uld *NEVER* copy the
> kernel. It loads at a specific address and we jump to where it loaded = in RAM (in your case,
> I think it should be stage_offset + (ehdr->e_entry - KERNBASE). Ker= nbase is 0xffff000000000000
> so we should jump to 0x10000brre0000 + 0x20000 (or maybe 0x800 is you = suggest). The kernel
> code that's there should do some tricks to find out where it was l= oaded, turn on the MMU and
> then jump to the VA to continue starting up the kernel. The arm64 kern= el is linked with a VA. Old amd64
> kernels expected to start at a fixed physical address, but the UEFI sp= ec allows memory to be mapped anywhere
> which means it was recently switched to create a page table in the boo= t loader, then jump to the right
> VA, and use the page table to find what PA that is and use that to boo= tstrap the pmap. This works great on
> amd64, but sometimes goes astray on arm64 (though the way it does for = you doesn't make sense
> to me). The amd64 code used to start at a PA, and that's what the = 'copy' routine is supposed to do:
> copy the kernel down that fixed address and jump to it. I don't th= ink we'll ever want that on arm64, though,
> and that might also be getting in your way (thought I'm doing this= from memory w/o careful study of
> the code because it's fresh in my mind due to getting arm64 workin= g with linuxboot).
>
> Also, vmap *MUST* be called in the boot loader. The trouble is, it ass= umes VA =3D=3D PA, but that's not
> strictly true. If you boot via LinuxBoot, for example, it has a memory= mapping that's not VA =3D=3D PA so
> at least some parts of the kernel fail their VA =3D=3D PA asserts. the= vmap code in the loader currently
> blindly assumes VA =3D=3D PA, but it should, IMHO, only do that if the= VA from entry from the table from
> the get memory map call is 0. Today it blindly overwrites it. You migh= t try changing that, and removing
> the bit in the kernel that checks for VA =3D=3D PA and bails out if th= ere's a mismatch. Here's the patch I'm
> temporarily using until I have the time to do more than a quick, super= ficial analysis of the issue:
>
> diff --git a/sys/arm64/arm64/efirt_machdep.c b/sys/arm64/arm64/efirt_m= achdep.c
> index 727c9c37f94d..075174d164d8 100644
> --- a/sys/arm64/arm64/efirt_machdep.c
> +++ b/sys/arm64/arm64/efirt_machdep.c
> @@ -193,8 +193,8 @@ efi_create_1t1_map(struct efi_md *map, int ndesc, = int descsz)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0continue;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if (p->= ;md_virt !=3D 0 && p->md_virt !=3D p->md_phys) {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0if (bootverbose)
> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0printf("EFI Runtime entry %d= is mapped\n", i);
> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0goto fail;
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0printf("EFI Runtime entry %d= is mapped PA %#lx VA %#lx\n", i, p->md_phys, p->md_virt);
> +//=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0goto fail;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if ((p-&g= t;md_phys & EFI_PAGE_MASK) !=3D 0) {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0if (bootverbose)
>
> clearly, not suitable for upstreaming, eh? And I have about 2 dozen co= mmits in my queue ahead of that
> one that need refinement, review and upstreaming before I jump into th= is issue. It will be after the first
> of the year at least before I'll look at it since I just started m= y year-end vacation...
>
> Warner
>
>>
>> 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 Los= h <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 W= arner 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 load= er boots, and show
>> > >> >> following log at last:
>> > >> >>
>> > >> >> Loading kernel...
>> > >> >> /boot/kernel/kernel text=3D0x2a8 text=3D0x8= bcbf0 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=C2=A0 =C2=A0 =C2=A0 =C2=A0 0x804= 00000, 0x7e9000
>> > >> >> dimensions=C2=A0 =C2=A0 =C2=A01920 x 1080 >> > >> >> stride=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A01920
>> > >> >> masks=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 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 fra= mebuffer output, it won't not go there w/o some setting to override (sa= y to force serial).
>> > >>
>> > >> In the loader, when comconsole->c_init() is calle= d 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/l= oader/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 hav= e a rather large backlog of MFC-able loader changes. If it is with stable, = then it makes sense: I fixed a bug where parse_uefi_con_out would return se= rial if '8be4df61-93ca-11d2-aa0d-00e098032b8c-ConOut' was unset. Is= it set?=C2=A0 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 t= o 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-0= EEC-43BD-0482-27D14ED47D72)/Uart(115200,8,N,1)
>> > global NV,BS,RS ConOutDev =3D
>> > VenHw(9042A9DE-23DC-4A38-96FB-7ADED080516A),/VenHw(857A8741-0= EEC-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 b= e stopping at
>> > >> serial console initialization.
>> > >
>> > >
>> > > The kernel doesn't use the EFI routines to initializ= e the serial console. But if the kernel is being told the wrong console, th= en it could also be booting just fine or almost fine and hitting some bug l= ater.
>> > >
>> > >>
>> > >> > Next most likely is that FreeBSD doesn't co= pe well with having both FDT and ACPI information available. But since not = DTB is being passed in (per that message) that's not likely at play her= e.
>> > >>
>> > >> 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 ta= bles, etc to the kernel. It's quite possible that, for reasons still un= known, that data is wrong or if standard conforming not expected by the ker= nel. 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, relen= g/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
>> > >> >> >
>> > >> >>
--000000000000b6dfee05f0887747--