Date: Thu, 18 Mar 2021 12:24:45 +0100 From: Marcin Wojtas <mw@semihalf.com> To: Mark Millard <marklmi@yahoo.com> Cc: Greg V <greg@unrelenting.technology>, freebsd-arm <freebsd-arm@freebsd.org>, Mark Murray <mrvmurray@icloud.com> Subject: Re: MACHIATOBin Double Shot booted into FreeBSD from Optane in PCIe slot Message-ID: <CAPv3WKeoxsdVHt2FFMP%2B3uoPoDCcFQ3EuPagiqAoYoyi2HTvzg@mail.gmail.com> In-Reply-To: <7744246D-0F1A-4035-BCAA-0903A3AB030D@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> <7744246D-0F1A-4035-BCAA-0903A3AB030D@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Mark, =C5=9Br., 17 mar 2021 o 06:01 Mark Millard via freebsd-arm <freebsd-arm@freebsd.org> napisa=C5=82(a): > > 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-= 2020-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 > 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 g= it context. > 7381bbee29df (freebsd/main, freebsd/HEAD, pure-src, main) cam: Run all XP= T_ASYNC ccbs in a dedicated thread > FreeBSD CA72n16 14.0-CURRENT FreeBSD 14.0-CURRENT mm-src-n245445-def0058c= c690 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. > > > > 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, enable= d > pcib0: rman_reserve_resource: start=3D0x800000000, end=3D0x800003fff, cou= nt=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=3D0= x8086 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 Up to this part everything looks fine - BootROM loaded first part of the image (DDR training) and executed it in SRAM. > Error: image checksum verification failed > Error: no valid header till end of media > Error: Failed boot attempt 01. error =3D 0x041 Above message is from the BootROM - it tries to fetch remaining part of the image (later to be executed from DRAM). This step fails. If it's not consistent, I'd check the uSD card is placed firmly in the slot and/or try also some different cards. Best regards, Marcin > > 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.1= 2.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.1= 2.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 0xf= 4280000 > NOTICE: Done > NOTICE: Load image to CP0 MSS AP0 > NOTICE: Loading MSS image from addr. 0x40286cc Size 0x1cd8 to MSS at 0xf= 2280000 > NOTICE: Done > NOTICE: Load image to AP0 MSS > NOTICE: Loading MSS image from addr. 0x402a3a4 Size 0x5420 to MSS at 0xf= 0580000 > 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) > > _______________________________________________ > 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"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAPv3WKeoxsdVHt2FFMP%2B3uoPoDCcFQ3EuPagiqAoYoyi2HTvzg>