Date: Sun, 5 May 2019 15:10:06 -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: <CANCZdfof2KVVFdd3Q4miaPyD0JR5RDCsv%2B6hf7jq8Pi_5S3QLg@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
Also, you'd have to tinker with the searching for root algorithm if you wanted to make the D_SLICEWILD work. We don't nest in the searching as well. I'm surprised, a little that it settled on disk0s1a, though. For other platforms we do support nesting, so I'm sure it's that code kinda sorta working, but not really working that's allowing you to get as far as you do. 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?CANCZdfof2KVVFdd3Q4miaPyD0JR5RDCsv%2B6hf7jq8Pi_5S3QLg>