On Wed, Dec 4, 2019 at 11:45 AM Bobby Johnson wrote:
>
>
>
> > On Nov 30, 2019, at 3:40 PM, Bobby Johnson wrote:
> >
> > Thanks for the ideas. This machine will do PXE but apparently only
> > with UEFI. I tried releases back to 6.2 via a usb drive all with the
> > same result.
> >
> > One other thing I tried was dd-ing a current install image to a
> > partition on the onboard disk. I get the bootloader, but then it
> > can't find /bsd and I can't ls the contents of the install from the
> > bootloader.
> >
> >> On Thu, Nov 28, 2019 at 3:59 AM Stuart Henderson
> >> wrote:
> >>
> >>> On 2019/11/27 15:59, Bobby Johnson wrote:
> >>> Hello,
> >>>
> >>> Attempting to install OpenBSD on the Lenovo C930, Kaby Lake laptop.
> >>> When booting I only see the entry point at line and then it restarts.
> >>> It does this with a very recent snapshot on bsd.rd and bsd, booting
> >>> from a usb drive.
> >>
> >> As well as Stefan's suggestion of legacy PXE, maybe try 6.6 or 6.5 as well
> >> instead of the very recent snapshot?
> >>
> >>> I found the NVME wasn't in the pcidevs. The vendor also wasn't
> >>> listed, HYNIX, 0x151c. I added the vendor and and device id for the
> >>> card, regenerated the pcidevs.h and pcidevs_data.h and recompiled.
> >>> Is that all that's necessary to get a new nvme to attach? Anything
> >>> else I could look into to get it booting?
> >>
> >> Kernel drivers attach much later than the "entry point", even if the
> >> NVME isn't being picked up, that wouldn't make it restart here.
> >>
> >>> Below is what I added to pcidevs
> >>>
> >>> vendor HYNIX 0x1c5c Hynix
> >>> product HYNIX NVME1 0x1527 NVMe
> >>>
> >>> Bobby
> >>>
> >>
> >> NVME normally attaches by device subclass/interface, this code in
> >> nvme_pci_match() in sys/dev/pci/nvme_pci.c:
> >>
> >>if (PCI_CLASS(pa->pa_class) == PCI_CLASS_MASS_STORAGE &&
> >>PCI_SUBCLASS(pa->pa_class) == PCI_SUBCLASS_MASS_STORAGE_NVM &&
> >>PCI_INTERFACE(pa->pa_class) == NVME_PCI_INTERFACE)
> >>return (1);
> >>
> >> If the class/subclass/interface match then there's no need to look at
> >> vendor/device id. Currently the driver has a special attachment for some
> >> Apple device ids. It's very unlikely that your device needs any change,
> >> but if it did then you'd add it alongside the Apple ones (as well as
> >> updating pcidevs).
> >>
> >> FWIW here's a pcidump -v example of a device which already matches:
> >>
> >> 5:0:0: Samsung SM961/PM961 NVMe
> >>0x: Vendor ID: 144d, Product ID: a804
> >>0x0004: Command: 0006, Status: 0010
> >>0x0008: Class: 01 Mass Storage, Subclass: 08 NVM,
> >>Interface: 02, Revision: 00
> >>
> >> or this in lspci -v
> >>
> >> 05:00.0 Non-Volatile memory controller: Samsung Electronics Co Ltd NVMe
> >> SSD Controller SM961/PM961 (prog-if 02 [NVM Express])
> >>
> >> There's no dev/vendor match for this but still:
> >>
> >> nvme0 at pci5 dev 0 function 0 "Samsung SM961/PM961 NVMe" rev 0x00: msix,
> >> NVMe 1.2
> >> nvme0: SAMSUNG MZVLW256HEHP-000L7, firmware 4L7QCXB7, serial S35ENX0J765205
> >> scsibus1 at nvme0: 2 targets, initiator 0
> >>
>
> Figured out how to do UEFI pxe. Same result though.
I found some recent commits by bluhm@ to get a laptop with maybe a
similar problem working. His work didn't fix my problem, but the hex
dump command he added to the bootloader gives a possible clue. When I
boot I get an entry point of 0x1001000. From the bootloader when I do
a hex dump around that location I see some stuff. On the VM I'm
testing on I just see everything set to ff at the same location.
I've tried to see if I could change the entry point by altering delta
in sys/arch/amd64/stand/efiboot/exec_i386.c. But even with a small
change my test vm won't boot with it.
Any clues how I could test further?
