From owner-freebsd-arm@freebsd.org Tue Mar 16 11:39:39 2021 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id D93445A9B45 for ; Tue, 16 Mar 2021 11:39:39 +0000 (UTC) (envelope-from greg@unrelenting.technology) Received: from out0.migadu.com (out0.migadu.com [IPv6:2001:41d0:2:267::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4F0BCY5HGmz4RMS for ; Tue, 16 Mar 2021 11:39:37 +0000 (UTC) (envelope-from greg@unrelenting.technology) Date: Tue, 16 Mar 2021 14:39:20 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=unrelenting.technology; s=key1; t=1615894769; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=6HC36G+1BsJa14N7/wvFKEQ6AhDIU3+Rw5X6J+noN24=; b=QGZIPjOxsPO2zdoODS52WrG5mQF69qr+sc+I9Q2hfVb+Qblo/eZKM+lUh09FtnDIdsZTcl O/xAwjXxtDimX9vHpkQu0UY2anGQCegUh9AEJp3rTvVskL0ZMDuBGQjFWtSzuLKzUCZRGe 0owWr87TcGff6EcRVgFhBDIL+uDe77it4pvvctQTckLeMKuMuyUCw1n850LVMYlGpX/eVJ FZY0FiVI4vKcAvPh6BSArpCRzPZBJaV5IPsuVHFdROkM45Q0sp9jwoOeoWzBxSz64WBiju 18YymlQUAl4kcJqRpbTJHxO7yx8KvWNz4FcSFfKAPqhpiftv/7++oLo4r1/TuA== X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Greg V 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" To: Mark Millard Cc: Mark Murray , freebsd-arm Message-Id: In-Reply-To: <13F0E8C6-639D-4529-8348-79DDCCC3B4F4@yahoo.com> References: <3420FB5B-6499-42E5-8FFE-F9BF57CCECE7@icloud.com> <5D99B7D1-CDF6-4C96-AF62-ADF9626639CF@yahoo.com> <13F0E8C6-639D-4529-8348-79DDCCC3B4F4@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: quoted-printable X-Migadu-Flow: FLOW_OUT X-Migadu-Auth-User: greg@unrelenting.technology X-Rspamd-Queue-Id: 4F0BCY5HGmz4RMS X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=unrelenting.technology header.s=key1 header.b=QGZIPjOx; dmarc=pass (policy=none) header.from=unrelenting.technology; spf=pass (mx1.freebsd.org: domain of greg@unrelenting.technology designates 2001:41d0:2:267:: as permitted sender) smtp.mailfrom=greg@unrelenting.technology X-Spamd-Result: default: False [-2.79 / 15.00]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[unrelenting.technology:s=key1]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; RCPT_COUNT_THREE(0.00)[3]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2001:41d0:2:267::]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; SPAMHAUS_ZRD(0.00)[2001:41d0:2:267:::from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[unrelenting.technology:+]; DMARC_POLICY_ALLOW(-0.50)[unrelenting.technology,none]; SUBJ_EXCESS_QP(1.20)[]; NEURAL_HAM_SHORT(-0.99)[-0.994]; FREEMAIL_TO(0.00)[yahoo.com]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[2001:41d0:2:267:::from]; ASN(0.00)[asn:16276, ipnet:2001:41d0::/32, country:FR]; FREEMAIL_CC(0.00)[icloud.com,freebsd.org]; MAILMAN_DEST(0.00)[freebsd-arm] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Porting FreeBSD to ARM processors List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2021 11:39:39 -0000 On Tue, Mar 16, 2021 at 02:53, Mark Millard via freebsd-arm=20 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: on acpi0 > pcib0: Bus is cache-coherent > pcib0: ECAM for bus 0-0 at mem e0000000-e00fffff > pci0: 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.