Date: Tue, 16 Mar 2021 16:10:05 -0700 From: Mark Millard <marklmi@yahoo.com> To: Greg V <greg@unrelenting.technology> Cc: freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: aarch64 based on main 58661b3ba9eb : panic for "ufs_dirbad: /: bad dir ino 66371814 at offset 106496: mangled entry" Message-ID: <80D7FDC3-1143-479C-85B2-DFF8EFB3CF64@yahoo.com> In-Reply-To: <KD82QQ.TGD40FIHR8HQ3@unrelenting.technology> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2021-Mar-16, at 04:39, Greg V <greg at unrelenting.technology> wrote: > On Tue, Mar 16, 2021 at 02:53, Mark Millard via freebsd-arm = <freebsd-arm at freebsd.org> wrote: >> = https://unrelentingtech.s3.dualstack.eu-west-1.amazonaws.com/flash-image-2= 020-07-01-mainline-tfa.bin >> With this media I get to see the kernel output that >> was missing before and so would have a chance of >> gathering evidence if there was a boot problem. >=20 > This is because FreeBSD was switched to actually correct parsing of = serial settings: > https://reviews.freebsd.org/D25373 >=20 > And only in these newer firmwares are the settings also correct :) >=20 >> I still have never tried to use the PCIe bus. 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. >=20 >> ( I've no clue how to accurately rebuild >> flash-image-2020-07-01-mainline-tfa.bin . Being >> able to rebuild in a known way could be an >> advantage to using a working port.) >=20 > You'll need to study EDK2 and TF-A documentation to understand all = these things, > but some rough info: >=20 > EDK2 forks: https://github.com/unrelentingtech/edk2/commits/master = https://github.com/unrelentingtech/edk2-platforms/commits/master >=20 > EDK2 build commands (before that, you'll need to build the tools in = the repo etc.): >=20 > export = PACKAGES_PATH=3D/usr/home/greg/src/github.com/tianocore/edk2:/usr/home/gre= g/src/github.com/tianocore/edk2-platforms:/usr/home/greg/src/github.com/ti= anocore/edk2-non-osi; ./edksetup.sh >=20 > DTC_PREFIX=3D/usr/local/bin/ CLANG38_BIN=3D/usr/local/llvm80/bin/ = CLANG38_AARCH64_PREFIX=3Daarch64-none-elf- build -a AARCH64 -p = Platform/SolidRun/Armada80x0McBin/Armada80x0McBin.dsc -n 8 -t CLANG38 -b = DEBUG -D X64EMU_ENABLE=3DTRUE -D CAPSULE_ENABLE=3DFALSE >=20 > The final build image is produced by TF-A, mainline is = https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git and the = build command is >=20 > gmake -j8 HOSTCC=3Dclang10 CROSS_COMPILE=3Daarch64-none-elf- = ARCH=3Daarch64 = SCP_BL2=3D/home/greg/src/github.com/MarvellEmbeddedProcessors/binaries-mar= vell/mrvl_scp_bl2.img = MV_DDR_PATH=3D/home/greg/src/github.com/MarvellEmbeddedProcessors/mv-ddr-m= arvell = BL33=3D/home/greg/src/github.com/tianocore/edk2/Build/Armada80x0McBin-AARC= H64/DEBUG_CLANG38/FV/ARMADA_EFI.fd PLAT=3Da80x0_mcbin LOG_LEVEL=3D30 E=3D0= all fip >=20 > the MV_DDR_PATH should have = https://github.com/MarvellEmbeddedProcessors/mv-ddr-marvell/tree/mv_ddr-ar= mada-atf-mainline checked out (note the mainline branch for mainline = TF-A), the SCP_BL2 is from = https://github.com/MarvellEmbeddedProcessors/binaries-marvell/tree/binarie= s-marvell-armada-18.12 and BL33 is the .fd image built by the EDK2 build = system. >=20 > and the TF-A makefile needs a gmake fix >=20 > --- i/plat/marvell/armada/a8k/common/ble/ble.mk > +++ w/plat/marvell/armada/a8k/common/ble/ble.mk > @@ -29,4 +29,4 @@ BLE_LINKERFILE :=3D $(BLE_PATH)/ble.ld.S > FORCE: >=20 > $(MV_DDR_LIB): FORCE > - @+make -C $(MV_DDR_PATH) --no-print-directory = PLAT_INCLUDES=3D"$(PLAT_INCLUDES)" PLATFORM=3D$(PLAT) ARCH=3DAARCH64 = OBJ_DIR=3D$(CURDIR)/$(BUILD_PLAT)/ble > + @+$(MAKE) -C $(MV_DDR_PATH) --no-print-directory = PLAT_INCLUDES=3D"$(PLAT_INCLUDES)" PLATFORM=3D$(PLAT) ARCH=3DAARCH64 = OBJ_DIR=3D$(CURDIR)/$(BUILD_PLAT)/ble >=20 >=20 >> There is also: >> https://people.freebsd.org/~manu/flash-image-2020-07-01.bin >> and: >> = https://unrelentingtech.s3.dualstack.eu-west-1.amazonaws.com/flash-image-2= 020-07-01.bin >> that I have not tried. >=20 > That build has the same EDK2, but vendor TF-A = (https://github.com/unrelentingtech/atf-marvell/tree/atf-v1.5-armada-18.12= ) instead of mainline. >=20 > If mainline works for you, great, no reason to switch to that one. > I've had some issue with mainline=E2=80=A6 IIRC, it refused to run = from the SD card because of some SD timeout thing, only worked from SPI = flash. >=20 Thanks for the explanations and other information --and the improved build. =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?80D7FDC3-1143-479C-85B2-DFF8EFB3CF64>