Date: Tue, 16 Mar 2021 22:00:47 -0700 From: Mark Millard <marklmi@yahoo.com> To: Greg V <greg@unrelenting.technology> Cc: freebsd-arm <freebsd-arm@freebsd.org>, Mark Murray <mrvmurray@icloud.com> Subject: MACHIATOBin Double Shot booted into FreeBSD from Optane in PCIe slot Message-ID: <7744246D-0F1A-4035-BCAA-0903A3AB030D@yahoo.com> In-Reply-To: <80D7FDC3-1143-479C-85B2-DFF8EFB3CF64@yahoo.com> References: <D0D027B5-8CF1-46F7-A5D5-DDC61C198822.ref@yahoo.com> <D0D027B5-8CF1-46F7-A5D5-DDC61C198822@yahoo.com> <3420FB5B-6499-42E5-8FFE-F9BF57CCECE7@icloud.com> <5D99B7D1-CDF6-4C96-AF62-ADF9626639CF@yahoo.com> <13F0E8C6-639D-4529-8348-79DDCCC3B4F4@yahoo.com> <KD82QQ.TGD40FIHR8HQ3@unrelenting.technology> <80D7FDC3-1143-479C-85B2-DFF8EFB3CF64@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
I've no plans on generally using the PCIe slot but I decided to test using it with an Optane as the only storage media (besides the microsd card that has the UEFI/ACPI material on it). It worked fine based on UEFI/ACPI being (indirectly) from: = https://unrelentingtech.s3.dualstack.eu-west-1.amazonaws.com/flash-image-2= 020-07-01-mainline-tfa.bin So I did the following (starting with being powered off already), at least in summary: A) Disconnected the usual power source B) Disconnected the SATA disk setup C) Plugged in the Optane into the PCIe slot D) Plugged in power that could handle far more E) Booted from the Optane (I used the UEFI UI to select the "UEFI Misc Device" in Boot Manager.) F) Transfered materials to update the FreeBSD (prebuilt) that was on the Optane. (Using ethernet dongle in the USB3 port, like normal for my context.) G) Ran the procedure for updating FreeBSD on the Macch. (A bunch of chroot directory trees are updated as well, not just the boot context.) H) Rebooted, again selecting "UEFI Misc Device". It is now running based on main 7381bbee29df (form 2021-Mar-12) from the Optane media: # ~/fbsd-based-on-what-freebsd-main.sh=20 merge-base: 7381bbee29df959e88ec59866cf2878263e7f3b2 merge-base: CommitDate: 2021-03-12 20:29:42 +0000 def0058cc690 (HEAD -> mm-src) mm-src snapshot for mm's patched build in = git context. 7381bbee29df (freebsd/main, freebsd/HEAD, pure-src, main) cam: Run all = XPT_ASYNC ccbs in a dedicated thread FreeBSD CA72n16 14.0-CURRENT FreeBSD 14.0-CURRENT = mm-src-n245445-def0058cc690 GENERIC-NODBG arm64 aarch64 1400005 1400005 >> . . . A >> verbose boot reported: >> pcib0: <Generic PCI host controller> on acpi0 >> pcib0: Bus is cache-coherent >> pcib0: ECAM for bus 0-0 at mem e0000000-e00fffff >> pci0: <PCI bus> on pcib0 >> pci0: domain=3D0, physical bus=3D0 >> but that was all for pci*. pciconf -l reported >> an empty output. >=20 > That's all you'll see without a card inserted. > On this device, we can only expose this much with ECAM. Now it shows as follows (verbose boot used): pcib0: <Generic PCI host controller> on acpi0 pcib0: Bus is cache-coherent pcib0: ECAM for bus 0-0 at mem e0000000-e00fffff pci0: <PCI bus> on pcib0 pci0: domain=3D0, physical bus=3D0 found-> vendor=3D0x8086, dev=3D0x2700, revid=3D0x00 domain=3D0, bus=3D0, slot=3D0, func=3D0 class=3D01-08-02, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0006, statreg=3D0x0010, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 = ns) intpin=3Da, irq=3D255 powerspec 3 supports D0 D3 current D0 MSI-X supports 32 messages in map 0x10 map[10]: type Memory, range 64, base 0x800000000, size 14, = enabled pcib0: rman_reserve_resource: start=3D0x800000000, end=3D0x800003fff, = count=3D0x4000 nvme0: <Generic NVMe Device> mem 0x800000000-0x800003fff at device 0.0 = on pci0 nvme0: attempting to allocate 5 MSI-X vectors (32 supported) nvme0: using IRQs 11-15 for MSI-X nvme0: CapLo: 0x04010fff: MQES 4095, CQR, TO 4 nvme0: CapHi: 0x00000020: DSTRD 0, CSS 1, MPSMIN 0, MPSMAX 0 nvme0: Version: 0x00010000: 1.0 . . . pass0 at nvme0 bus 0 scbus4 target 0 lun 1 pass0: <INTEL SSDPED1D480GA *REPLACED*> pass0: Serial Number *REPLACED* pass0: nvme version 1.0 x4 (max x4) lanes PCIe Gen3 (max Gen3) link nda0 at nvme0 bus 0 scbus4 target 0 lun 1 GEOM: new disk nda0 nda0: <INTEL SSDPED1D480GA *REPLACED*> nda0: Serial Number *REPLACED* nda0: nvme version 1.0 x4 (max x4) lanes PCIe Gen3 (max Gen3) link nda0: 457862MB (937703088 512 byte sectors) # pciconf -lv nvme0@pci0:0:0:0: class=3D0x010802 rev=3D0x00 hdr=3D0x00 = vendor=3D0x8086 device=3D0x2700 subvendor=3D0x8086 subdevice=3D0x3900 vendor =3D 'Intel Corporation' device =3D 'Optane SSD 900P Series' class =3D mass storage subclass =3D NVM Thanks again. Note on the "image checksum verification failed" notices and such . . . I have seen the rejection of the microsd card UEFI/ACPI material's checksum sometimes (same media both ways, no content update). With your report as well, it seems that reading microsd card media is unreliable at the start. Its simple retries worked in my case, for example: BootROM - 2.03 Starting CP-0 IOROM 1.07 Booting from SD 0 (0x29) Found valid image at boot postion 0x000 lNOTICE: Starting binary extension NOTICE: SVC: SW Revision 0x0. SVC is not supported mv_ddr: mv_ddr-devel-18.08.0-ga881467 (Jul 01 2020 - 21:18:08) mv_ddr: completed successfully NOTICE: Cold boot Error: image checksum verification failed Error: no valid header till end of media Error: Failed boot attempt 01. error =3D 0x041 BootROM - 2.03 Starting CP-0 IOROM 1.07 Booting from SD 0 (0x29) Found valid image at boot postion 0x000 lNOTICE: Starting binary extension NOTICE: SVC: SW Revision 0x0. SVC is not supported mv_ddr: mv_ddr-devel-18.08.0-ga881467 (Jul 01 2020 - 21:18:08) mv_ddr: completed successfully NOTICE: Cold boot NOTICE: Booting Trusted Firmware NOTICE: BL1: v2.3(release):v2.3-269-g568a88172-dirty = (Marvell-devel-18.12.0) NOTICE: BL1: Built : 21:19:59, Jul 1 2020 NOTICE: BL1: Booting BL2 NOTICE: BL2: v2.3(release):v2.3-269-g568a88172-dirty = (Marvell-devel-18.12.0) NOTICE: BL2: Built : 21:20:00, Jul 1 2020 NOTICE: SCP_BL2 contains 5 concatenated images NOTICE: Skipping MSS CP3 related image NOTICE: Skipping MSS CP2 related image NOTICE: Load image to CP1 MSS AP0 NOTICE: Loading MSS image from addr. 0x40269f4 Size 0x1cd8 to MSS at = 0xf4280000 NOTICE: Done NOTICE: Load image to CP0 MSS AP0 NOTICE: Loading MSS image from addr. 0x40286cc Size 0x1cd8 to MSS at = 0xf2280000 NOTICE: Done NOTICE: Load image to AP0 MSS NOTICE: Loading MSS image from addr. 0x402a3a4 Size 0x5420 to MSS at = 0xf0580000 NOTICE: Done NOTICE: SCP Image doesn't contain PM firmware NOTICE: BL1: Booting BL31 lNOTICE: MSS PM is not supported in this build NOTICE: BL31: v2.3(release):v2.3-269-g568a88172-dirty = (Marvell-devel-18.12.0) NOTICE: BL31: Built : 21:19:59, Jul 1 2020 For the sequence: NOTICE: Cold boot Error: image checksum verification failed Error: no valid header till end of media Error: Failed boot attempt 01. error =3D 0x041 Is all that before it is even executing material that is from the microsd card? If it is, then the problem would not seem to be tied to the specific image used but be a more general problem reading microsd media by code that is in use before the microsd card's code is in use. I've not tried other media or any such yet. It is not the media that I'd used for so long before switching images: At the time I kept the original media as it was so that I could revert to it if needed. The two media (older and newer) are not of the same type. I'd never noticed such retries with the older media --but I was not looking for such either. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7744246D-0F1A-4035-BCAA-0903A3AB030D>