From owner-freebsd-arm@freebsd.org Sun May 5 20:54:08 2019 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 76C571594EE0 for ; Sun, 5 May 2019 20:54:08 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qt1-x82c.google.com (mail-qt1-x82c.google.com [IPv6:2607:f8b0:4864:20::82c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C88A57101B for ; Sun, 5 May 2019 20:54:06 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qt1-x82c.google.com with SMTP id i31so12581619qti.13 for ; Sun, 05 May 2019 13:54:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8ZEh6fQMUHeYwJhHLnUMfqbok9AICPHfpz5HkWol0pk=; b=fM4oLPEHcfn8mtK25iCOybrp/P2Ea4tcQ4/BWFqZOGzjdA5OVf/3ZC8s7+n4+F4/bY dvP0Wb6Rs5TVBtEpL1wuCbi3tvdhAt9s0T/nJfMOhQfz1Q7UB7ZYk1DH7maj4mWSMzLI nCMHmDbU4MaMcYv2AAtPkU5ilEfn+6ka/e1MB6ypIqvaf3WwoT0Qq8LMofucwjFoSNeD rtAqJPT/F4WvWHggus6one5iEmS7DSedztyBJIxL80yg3eRvX75pluZ7pwx2imJkdq1R nMiKIpJRTIXcvxj3MQ2K04ouTefGQR/ZwRADQfGw5NItN27oAxAHBAo4VH87WFK2YQgv aeVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8ZEh6fQMUHeYwJhHLnUMfqbok9AICPHfpz5HkWol0pk=; b=UMLbo1USM1FV+hIlLDtFC8thDP0KTI1eICSM5w8SMxE2dhMnD1qLcZ4Rwee+xh57K0 DnvvkJUlx0P/YJNWm90QaIqaknh9RU0lynRQoZVEp/kRRM8LkKwTyEWuvBJ2/vk/1Pcq iRvEzwuqGxxl5VX3bkQp2QkRW2sgakGBwfkQ+Cx6TS66TACl1TgQegXdV1TNSjfWjmMt 1EgnnhdvZ8iFlYwj1ugfpOjSk2w0U8j4HVvZZyhHw4B/qvvr1r87rUqn5XRUv1si4pZT knJaEI7eSJefE/k7D2wPqPkuPpqs6UltE2CHHQeD/GNiFjvljwMHrm5kKkzaQqjeT1Rg 5t5w== X-Gm-Message-State: APjAAAXQgn3+JOY5jik10QjWcers+/qhqWcA9DrTNaKlirgg5Qpt0jrj 48/WQodQAx07Dx3P71tUGxonYqLLVFj/GxB2m1fyxD3J X-Google-Smtp-Source: APXvYqyNDXqBCS1CVj/j2ZDsiaTAfjTUjlnWGexAPHDMANq1NrLcj8VJCGqXPcQcgv2ouVn3tLqduGam+dD2b394jzo= X-Received: by 2002:ac8:19db:: with SMTP id s27mr3753634qtk.33.1557089646214; Sun, 05 May 2019 13:54:06 -0700 (PDT) MIME-Version: 1.0 References: <62c176f7-ada7-1243-f603-b6ead448d11e@yandex.ru> In-Reply-To: From: Warner Losh Date: Sun, 5 May 2019 14:53:55 -0600 Message-ID: Subject: Re: MMCCAM Stack Not Showing BSD Slice To: James Shuriff Cc: "Andrey V. Elsukov" , "freebsd-arm@freebsd.org" X-Rspamd-Queue-Id: C88A57101B X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=fM4oLPEH X-Spamd-Result: default: False [-5.80 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; RCVD_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; MX_GOOD(-0.01)[cached: ALT1.aspmx.l.google.com]; RCVD_IN_DNSWL_NONE(0.00)[c.2.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; NEURAL_HAM_SHORT(-0.87)[-0.872,0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; IP_SCORE(-2.92)[ip: (-9.09), ipnet: 2607:f8b0::/32(-3.20), asn: 15169(-2.25), country: US(-0.06)]; FREEMAIL_CC(0.00)[yandex.ru] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 May 2019 20:54:08 -0000 So /evi/freebsd/loader.env would be relative to the ESP (the s1 fat partition). It's a simplified version of loader.conf in that it only understands foo=3Dbar type variables. There's another new loader variable called uefi_rootdev. However, UEFI doesn't really have a notion of BSD partitions (or any nested partitioning schemes), so there's no standardized way to specify disk0s2a. In a complex system, this would be a problem. However, in your simple scenario, you may be able to say 'rootdev=3Ddisk0s2a:' in loader.env and have things work. I just added loader.env in the past couple of weeks, so I've not yet updated the docs because we have no loader.efi(8) man page. There is a uefi(8) that I was unaware of when I did these changes. Maybe I could add something there. We have a lot of undocumented tribal knowledge about the boot process that we should commit to paper / manpage :) Warner On Sun, May 5, 2019 at 2:34 PM James Shuriff wrote: > Makes sense. I can see the loader code that makes that assumption. If the > loader disk is partitioned set_currdev_pdinfo assumes it=E2=80=99s GPT. I= don=E2=80=99t > think VideoCore supports GPT disks (I=E2=80=99m using a Raspberry Pi 3 Mo= del B). > > > > I patched the loader to use D_SLICEWILD instead of D_PARTISGPT. Now > currdev defaults to disk0s1a. I can=E2=80=99t find any good documentation= on > /efi/freebsd/loader.env so I=E2=80=99m looking for the parser that reads = the file. > I see sanity checks for currdev and it *should* be failing the sanity che= ck > but if it is it=E2=80=99s not being logged. > > > > - James Shuriff > > > > *From:* Warner Losh > *Sent:* Sunday, May 5, 2019 4:06 PM > *To:* James Shuriff > *Cc:* Andrey V. Elsukov ; freebsd-arm@freebsd.org > *Subject:* Re: MMCCAM Stack Not Showing BSD Slice > > > > > > On Sun, May 5, 2019, 1:59 PM James Shuriff wrote: > > The "currdev" is defaulting to disk0p1: when it should be disk0s2a:. > loader_lua.efi seems to read a file "/boot/freebsd/loader.env" off the > FAT16 partition but it uses a particular format that is "subtly different= " > from loader.conf. I'm trying to set currdev here. When I set "currdev" in > the loader prompt instead of just passing it the kernel it mounts the roo= t > filesystem automatically. > > > > Loader.efi assumes GPT partitioning. While MBR kinda works, it has not > been well tested and bugs like this are lurking. > > > > Warner > > > > - James Shuriff > > -----Original Message----- > From: James Shuriff > Sent: Sunday, May 5, 2019 11:02 AM > To: 'Andrey V. Elsukov' ; freebsd-arm@freebsd.org > Subject: RE: MMCCAM Stack Not Showing BSD Slice > > Yes, it does show sdda0s2 as a consumer. This didn't happen with the MMC > stack so I assumed it was a bug. I've destroyed the label and now the sli= ce > is appearing. > > loader_lua.efi isn't finding the boot partition. It complains about not > finding /boot/lua/loader.lua. I have to manually tell it to "load > disk0s2a:/boot/kernel/kernel" and "boot". Then the kernel doesn't automou= nt > the root partition. I tried using vfs.root.mountfrom in loader.conf and > it's still not automounting. This was a problem when I had the label and > still is after I removed it. > > My current loader.conf: > vfs.root.mountfrom=3D"ufs:/dev/sdda0s2a" > hw.usb.template=3D3 > boot_multicons=3D"YES" > boot_serial=3D"YES" > > My current fstab: > # DeviceMountpointFStypeOptionsDumpPass# > /dev/sdda0s2a/ufsrw11 > /dev/sdda0s1/boot/firmwaremsdosfsrw,noatime00 > tmpfs/tmptmpfsrw,mode=3D1777,size=3D60m00 > proc/procprocfsrw00 > //JAMES@STEVE-PC/TV/mnt/tvsmbfsrw,-N00 > > Any ideas? This started when I switched to the MMCCAM stack so I assumed > it was all the same issue. I copied loader_lua.efi to the FAT16 partition > as /EFI/BOOT/bootaa64.efi. > > - James Shuriff > > -----Original Message----- > From: Andrey V. Elsukov > Sent: Sunday, May 5, 2019 8:56 AM > To: James Shuriff ; freebsd-arm@freebsd.org > Subject: Re: MMCCAM Stack Not Showing BSD Slice > > On 04.05.2019 16:04, James Shuriff wrote: > > Working on current branch for Aarch64 with MMCCAM stack. I have an MBR > > disk partitioned with a 50M fat32lba partition and a 30G BSD slice. > > The BSD slice contains a single UFS partition (root). With the MMC > > stack I would see mmcsd0s1, mmcsd0s2, and mmcsd0s2a. With the MMCCAM > > stack I only see sdda0s1 and sdda0s2. There should be an sdda0s2a. I > > can still mount the root partition via labels (/dev/ufs/rootfs). Any > > ideas? > > ufs/rootfs was found on the sdda0s2 and then mounted for r/w. GPART_BSD > had no chance to taste sdda0s2 slice, and thus there is no BSD label. > This happens sometimes with labels that share the same provider. > > I think if you do `glabel list` you will see that ufs/rootfs uses sdda0s2= . > > -- > WBR, Andrey V. Elsukov > > ________________________________ > DISCLAIMER: This message and any attachments are intended solely for the > use of the recipient and may contain confidential information. If you hav= e > received this message in error please delete it and promptly notify the > sender, James Shuriff (james@opentech.cc). > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > > ------------------------------ > DISCLAIMER: This message and any attachments are intended solely for the > use of the recipient and may contain confidential information. If you hav= e > received this message in error please delete it and promptly notify the > sender, James Shuriff (james@opentech.cc). >