Date: Sun, 5 May 2019 14:53:55 -0600 From: Warner Losh <imp@bsdimp.com> To: James Shuriff <james@opentech.cc> Cc: "Andrey V. Elsukov" <bu7cher@yandex.ru>, "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org> Subject: Re: MMCCAM Stack Not Showing BSD Slice Message-ID: <CANCZdfoKz0oWN9VqbrQD4sPhtj4hgsX4dR1LNvXxQ8htjuZ0PQ@mail.gmail.com> In-Reply-To: <BN7PR06MB51877C4D304ED1E7724856D7AA370@BN7PR06MB5187.namprd06.prod.outlook.com> References: <BN7PR06MB51879B7DCDAE6A5BA28C6D41AA360@BN7PR06MB5187.namprd06.prod.outlook.com> <62c176f7-ada7-1243-f603-b6ead448d11e@yandex.ru> <BN7PR06MB5187E860530EF95C70C10A19AA370@BN7PR06MB5187.namprd06.prod.outlook.com> <BN7PR06MB5187E1D8232BAFD41429D326AA370@BN7PR06MB5187.namprd06.prod.outlook.com> <CANCZdfr0du8ekK900oGtOv14KV3hJ-ZGCz%2BXbHyo0agn58n8JQ@mail.gmail.com> <BN7PR06MB51877C4D304ED1E7724856D7AA370@BN7PR06MB5187.namprd06.prod.outlook.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <james@opentech.cc> 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 <imp@bsdimp.com> > *Sent:* Sunday, May 5, 2019 4:06 PM > *To:* James Shuriff <james@opentech.cc> > *Cc:* Andrey V. Elsukov <bu7cher@yandex.ru>; freebsd-arm@freebsd.org > *Subject:* Re: MMCCAM Stack Not Showing BSD Slice > > > > > > On Sun, May 5, 2019, 1:59 PM James Shuriff <james@opentech.cc> 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' <bu7cher@yandex.ru>; 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 <bu7cher@yandex.ru> > Sent: Sunday, May 5, 2019 8:56 AM > To: James Shuriff <james@opentech.cc>; 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<mailto: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). >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfoKz0oWN9VqbrQD4sPhtj4hgsX4dR1LNvXxQ8htjuZ0PQ>