On Wed, Dec 4, 2019 at 11:45 AM Bobby Johnson <[email protected]> wrote: > > > > > On Nov 30, 2019, at 3:40 PM, Bobby Johnson <[email protected]> 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 <[email protected]> > >> 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 > >> 0x0000: 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?
