Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 16 Mar 2021 14:39:20 +0300
From:      Greg V <greg@unrelenting.technology>
To:        Mark Millard <marklmi@yahoo.com>
Cc:        Mark Murray <mrvmurray@icloud.com>, freebsd-arm <freebsd-arm@freebsd.org>
Subject:   Re: aarch64 based on main 58661b3ba9eb : panic for "ufs_dirbad: =?UTF-8?Q?=2F=3A=0D=0A?= bad dir ino 66371814 at offset 106496: mangled entry"
Message-ID:  <KD82QQ.TGD40FIHR8HQ3@unrelenting.technology>
In-Reply-To: <13F0E8C6-639D-4529-8348-79DDCCC3B4F4@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>

next in thread | previous in thread | raw e-mail | index | archive | help


On Tue, Mar 16, 2021 at 02:53, Mark Millard via freebsd-arm=20
<freebsd-arm@freebsd.org> wrote:
>=20
> https://unrelentingtech.s3.dualstack.eu-west-1.amazonaws.com/flash-image-=
2020-07-01-mainline-tfa.bin
>=20
> 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=20
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:
>=20
> 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
>=20
> 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=20
these things,
but some rough info:

EDK2 forks: https://github.com/unrelentingtech/edk2/commits/master=20
https://github.com/unrelentingtech/edk2-platforms/commits/master

EDK2 build commands (before that, you'll need to build the tools in the=20
repo etc.):

export=20
PACKAGES_PATH=3D/usr/home/greg/src/github.com/tianocore/edk2:/usr/home/greg=
/src/github.com/tianocore/edk2-platforms:/usr/home/greg/src/github.com/tian=
ocore/edk2-non-osi;=20
 ./edksetup.sh

DTC_PREFIX=3D/usr/local/bin/ CLANG38_BIN=3D/usr/local/llvm80/bin/=20
CLANG38_AARCH64_PREFIX=3Daarch64-none-elf- build -a AARCH64 -p=20
Platform/SolidRun/Armada80x0McBin/Armada80x0McBin.dsc -n 8 -t CLANG38=20
-b DEBUG -D X64EMU_ENABLE=3DTRUE -D CAPSULE_ENABLE=3DFALSE

The final build image is produced by TF-A, mainline is=20
https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git and the=20
build command is

gmake -j8 HOSTCC=3Dclang10 CROSS_COMPILE=3Daarch64-none-elf- ARCH=3Daarch64=
=20
SCP_BL2=3D/home/greg/src/github.com/MarvellEmbeddedProcessors/binaries-marv=
ell/mrvl_scp_bl2.img=20
MV_DDR_PATH=3D/home/greg/src/github.com/MarvellEmbeddedProcessors/mv-ddr-ma=
rvell=20
BL33=3D/home/greg/src/github.com/tianocore/edk2/Build/Armada80x0McBin-AARCH=
64/DEBUG_CLANG38/FV/ARMADA_EFI.fd=20
PLAT=3Da80x0_mcbin LOG_LEVEL=3D30 E=3D0 all fip

the MV_DDR_PATH should have=20
https://github.com/MarvellEmbeddedProcessors/mv-ddr-marvell/tree/mv_ddr-arm=
ada-atf-mainline=20
checked out (note the mainline branch for mainline TF-A), the SCP_BL2=20
is from=20
https://github.com/MarvellEmbeddedProcessors/binaries-marvell/tree/binaries=
-marvell-armada-18.12=20
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 :=3D $(BLE_PATH)/ble.ld.S
 FORCE:

 $(MV_DDR_LIB): FORCE
- @+make -C $(MV_DDR_PATH) --no-print-directory=20
PLAT_INCLUDES=3D"$(PLAT_INCLUDES)" PLATFORM=3D$(PLAT) ARCH=3DAARCH64=20
OBJ_DIR=3D$(CURDIR)/$(BUILD_PLAT)/ble
+ @+$(MAKE) -C $(MV_DDR_PATH) --no-print-directory=20
PLAT_INCLUDES=3D"$(PLAT_INCLUDES)" PLATFORM=3D$(PLAT) ARCH=3DAARCH64=20
OBJ_DIR=3D$(CURDIR)/$(BUILD_PLAT)/ble


> There is also:
>=20
> 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
>=20
> that I have not tried.

That build has the same EDK2, but vendor TF-A=20
(https://github.com/unrelentingtech/atf-marvell/tree/atf-v1.5-armada-18.12)=
=20
instead of mainline.

If mainline works for you, great, no reason to switch to that one.
I've had some issue with mainline=85 IIRC, it refused to run from the=20
SD card because of some SD timeout thing, only worked from SPI flash.





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?KD82QQ.TGD40FIHR8HQ3>