aarch64 based on main 58661b3ba9eb : panic for "ufs_dirbad: /: bad dir ino 66371814 at offset 106496: mangled entry"

[Mark Millard]

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-2020-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.
> 
> This is because FreeBSD was switched to actually correct parsing of serial settings:
> https://reviews.freebsd.org/D25373
> 
> And only in these newer firmwares are the settings also correct :)
> 
>> 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=0, physical bus=0
>> 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.
> 
>> ( 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.)
> 
> You'll need to study EDK2 and TF-A documentation to understand all these things,
> but some rough info:
> 
> EDK2 forks: https://github.com/unrelentingtech/edk2/commits/master https://github.com/unrelentingtech/edk2-platforms/commits/master
> 
> EDK2 build commands (before that, you'll need to build the tools in the repo etc.):
> 
> export PACKAGES_PATH=/usr/home/greg/src/github.com/tianocore/edk2:/usr/home/greg/src/github.com/tianocore/edk2-platforms:/usr/home/greg/src/github.com/tianocore/edk2-non-osi; ./edksetup.sh
> 
> DTC_PREFIX=/usr/local/bin/ CLANG38_BIN=/usr/local/llvm80/bin/ CLANG38_AARCH64_PREFIX=aarch64-none-elf- build -a AARCH64 -p Platform/SolidRun/Armada80x0McBin/Armada80x0McBin.dsc -n 8 -t CLANG38 -b DEBUG -D X64EMU_ENABLE=TRUE -D CAPSULE_ENABLE=FALSE
> 
> 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
> 
> gmake -j8 HOSTCC=clang10 CROSS_COMPILE=aarch64-none-elf- ARCH=aarch64 SCP_BL2=/home/greg/src/github.com/MarvellEmbeddedProcessors/binaries-marvell/mrvl_scp_bl2.img MV_DDR_PATH=/home/greg/src/github.com/MarvellEmbeddedProcessors/mv-ddr-marvell BL33=/home/greg/src/github.com/tianocore/edk2/Build/Armada80x0McBin-AARCH64/DEBUG_CLANG38/FV/ARMADA_EFI.fd PLAT=a80x0_mcbin LOG_LEVEL=30 E=0 all fip
> 
> the MV_DDR_PATH should have https://github.com/MarvellEmbeddedProcessors/mv-ddr-marvell/tree/mv_ddr-armada-atf-mainline checked out (note the mainline branch for mainline TF-A), the SCP_BL2 is from https://github.com/MarvellEmbeddedProcessors/binaries-marvell/tree/binaries-marvell-armada-18.12 and BL33 is the .fd image built by the EDK2 build system.
> 
> and the TF-A makefile needs a gmake fix
> 
> --- i/plat/marvell/armada/a8k/common/ble/ble.mk
> +++ w/plat/marvell/armada/a8k/common/ble/ble.mk
> @@ -29,4 +29,4 @@ BLE_LINKERFILE := $(BLE_PATH)/ble.ld.S
> FORCE:
> 
> $(MV_DDR_LIB): FORCE
> - @+make -C $(MV_DDR_PATH) --no-print-directory PLAT_INCLUDES="$(PLAT_INCLUDES)" PLATFORM=$(PLAT) ARCH=AARCH64 OBJ_DIR=$(CURDIR)/$(BUILD_PLAT)/ble
> + @+$(MAKE) -C $(MV_DDR_PATH) --no-print-directory PLAT_INCLUDES="$(PLAT_INCLUDES)" PLATFORM=$(PLAT) ARCH=AARCH64 OBJ_DIR=$(CURDIR)/$(BUILD_PLAT)/ble
> 
> 
>> 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-2020-07-01.bin
>> that I have not tried.
> 
> 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.
> 
> If mainline works for you, great, no reason to switch to that one.
> I've had some issue with mainline… IIRC, it refused to run from the SD card because of some SD timeout thing, only worked from SPI flash.
> 

Thanks for the explanations and other information
--and the improved build.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)