MMCCAM Stack Not Showing BSD Slice

[Warner Losh]

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 at 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’s GPT. I don’t
> think VideoCore supports GPT disks (I’m using a Raspberry Pi 3 Model B).
>
>
>
> I patched the loader to use D_SLICEWILD instead of D_PARTISGPT. Now
> currdev defaults to disk0s1a. I can’t find any good documentation on
> /efi/freebsd/loader.env so I’m looking for the parser that reads the file.
> I see sanity checks for currdev and it *should* be failing the sanity check
> but if it is it’s not being logged.
>
>
>
> - James Shuriff
>
>
>
> *From:* Warner Losh <imp at bsdimp.com>
> *Sent:* Sunday, May 5, 2019 4:06 PM
> *To:* James Shuriff <james at opentech.cc>
> *Cc:* Andrey V. Elsukov <bu7cher at yandex.ru>; freebsd-arm at freebsd.org
> *Subject:* Re: MMCCAM Stack Not Showing BSD Slice
>
>
>
>
>
> On Sun, May 5, 2019, 1:59 PM James Shuriff <james at 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 root
> 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 at yandex.ru>; freebsd-arm at 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 slice
> 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 automount
> 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="ufs:/dev/sdda0s2a"
> hw.usb.template=3
> boot_multicons="YES"
> boot_serial="YES"
>
> My current fstab:
> # DeviceMountpointFStypeOptionsDumpPass#
> /dev/sdda0s2a/ufsrw11
> /dev/sdda0s1/boot/firmwaremsdosfsrw,noatime00
> tmpfs/tmptmpfsrw,mode=1777,size=60m00
> proc/procprocfsrw00
> //JAMES at 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 at yandex.ru>
> Sent: Sunday, May 5, 2019 8:56 AM
> To: James Shuriff <james at opentech.cc>; freebsd-arm at 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 have
> received this message in error please delete it and promptly notify the
> sender, James Shuriff (james at opentech.cc<mailto:james at opentech.cc>).
> _______________________________________________
> freebsd-arm at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-arm
> To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org"
>
> ------------------------------
> DISCLAIMER: This message and any attachments are intended solely for the
> use of the recipient and may contain confidential information. If you have
> received this message in error please delete it and promptly notify the
> sender, James Shuriff (james at opentech.cc).
>