Date: Sun, 19 Aug 2018 09:23:45 -0700 From: Mark Millard <marklmi@yahoo.com> To: "O. Hartmann" <ohartmann@walstatt.org> Cc: "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org> Subject: Re: [PINE64] mmcsd0: aw_mmc0: Error indicated Message-ID: <23F43EA1-3741-47BD-97D9-2BA816692492@yahoo.com> In-Reply-To: <BA9CEB4A-736A-4016-89F5-992AB12AA2B8@yahoo.com> References: <20180819141538.1eb442ef@thor.intern.walstatt.dynvpn.de> <BA9CEB4A-736A-4016-89F5-992AB12AA2B8@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[Just clarifying my wording where it was incomplete. Not tied to your problem but reading what I wrote in one area would be confusing.] On 2018-Aug-19, at 6:15 AM, Mark Millard <marklmi26-fbsd at yahoo.com> = wrote: > On 2018-Aug-19, at 5:15 AM, O. Hartmann <ohartmann@walstatt.org> = wrote: >=20 >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA512 >>=20 >> Running 12-CURRENT for a while now on a PINE64+, 2GB RAM from SD, I = face since months >> those errors regarding the aw_mmc controller: >>=20 >> [...] >>=20 >> aw_mmc0: controller timeout >> aw_mmc0: timeout updating clock >> mmcsd0: Error indicated: 1 Timeout >> g_vfs_done():ufs/rootfs[WRITE(offset=3D3281551360, length=3D4096)]error= =3D 5 >> aw_mmc0: controller timeout >> aw_mmc0: timeout updating clock >> mmcsd0: Error indicated: 1 Timeout >> g_vfs_done():ufs/rootfs[WRITE(offset=3D3282788352, length=3D4096)]error= =3D 5 >> aw_mmc0: controller timeout >> aw_mmc0: timeout updating clock >> mmcsd0: Error indicated: 1 Timeout >> g_vfs_done():ufs/rootfs[WRITE(offset=3D3283681280, = length=3D32768)]error =3D 5 >>=20 >> [...] >>=20 >> ... and a while, the system ic completely stuck and needs hard reset. >>=20 >> I can remember this error since I played around with 12-CURRENT on = the PINE64 and that is >> on various revisions since December 2017. >>=20 >> Is this related to some known issues or could this be related to my = hardware? >>=20 >> System is: >>=20 >> FreeBSD 12.0-CURRENT #13 r336753: Fri Jul 27 06:02:30 CEST 2018 arm64 >>=20 >> I have a custom-built kernel with some add-ons like IPFW. >>=20 >=20 > [These notes are based on a normal sdcard, not my historical > e.MCC on an adapter. The e.MMC context no longer directly > boots.] >=20 > I've been running head -r337400 with then-modern: >=20 > A) /boot/efi/dtb/ > (/boot/efi being a mount of the msdosfs, > dtb/ being copy of target media's UFS /boot/dtb/ ) > B) /boot/efi/EFI/BOOT/bootaa64.efi > (copy of . . ./stand/efi/loader/loader.efi from the build tree) > and with -r476715 /usr/port 's: > C) sysutils/u-boot-pine64 > (via /usr/local/share/u-boot/u-boot-pine64/u-boot-sunxi-with-spl.bin = dd'd) >=20 > My boot sdcard has a full installworld installkernel but I normally = have > its /etc/fstab edited to redirect the root file system (and swap = partition) > to a USB drive. >=20 > But I've had no operational troubles so far when booted to the sdcard = (via > an edit if its /etc.fstab file to self-reference the root file = system). >=20 > For reference: >=20 > mmcsd0: 32GB <SDHC SE32G 8.0 SN <replaced> MFG 07/2017 by 3 SD> at = mmc0 50.0MHz/4bit/32768-block >=20 > The kernel is from: >=20 > # more /usr/src/sys/arm64/conf/GENERIC-NODBG=20 > # > # GENERIC -- Custom configuration for the arm64/aarch64 > # >=20 > include "GENERIC" >=20 > ident GENERIC-NODBG >=20 > makeoptions DEBUG=3D-g # Build kernel with gdb(1) = debug symbols >=20 > options ALT_BREAK_TO_DEBUGGER >=20 > options KDB # Enable kernel debugger = support >=20 > # For minimum debugger support (stable branch) use: > #options KDB_TRACE # Print a stack trace for a = panic > options DDB # Enable the kernel debugger >=20 > # Extra stuff: > #options VERBOSE_SYSINIT # Enable verbose sysinit = messages > #options BOOTVERBOSE=3D1 > #options BOOTHOWTO=3DRB_VERBOSE > #options KTR > #options KTR_MASK=3DKTR_TRAP > ##options KTR_CPUMASK=3D0xF > #options KTR_VERBOSE >=20 > # Disable any extra checking for. . . > nooptions DEADLKRES # Enable the deadlock resolver > nooptions INVARIANTS # Enable calls of extra sanity = checking > nooptions INVARIANT_SUPPORT # Extra sanity checks of = internal structures, required by INVARIANTS > nooptions WITNESS # Enable checks to detect = deadlocks and cycles > nooptions WITNESS_SKIPSPIN # Don't run witness on = spinlocks for speed > nooptions DIAGNOSTIC > nooptions MALLOC_DEBUG_MAXZONES # Separate malloc(9) zones > nooptions BUF_TRACKING > nooptions FULL_BUF_TRACKING >=20 >=20 >=20 > Notes: >=20 > I do get the two messages during boot: >=20 > mmc0: ACMD42 failed, RESULT: 4 > mmc0: Card at relative address 43690 failed to set bus width >=20 > but things seem to be operating fine. The context for the below was probably unclear via my incomplete statement of context: > Because of my use of WITHOUT_BINTUTILS for buildworld buildkernel > I added: >=20 > BUILD_DEPENDS+=3D objdump:devel/binutils >=20 > to: >=20 > /usr/ports/sysutils/u-boot-master/Makefile >=20 > in order for sysutils/u-boot-pine64 to build under > poudriere-devel . I should have started with: "Because of my use of WITHOUT_BINTUTILS for buildworld buildkernel for my amd64 environment that I did the cross build to aarch64 from . . ." I built via an amd64 -> aarch64 cross build overall. The sysutils/u-boot-pine64 build tried to use the amd64 (or other host) objdump during its activity for cross builds and its absence in the *host* environment for the cross changed the result of the build before this change to the Makefile. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D230288 is about that (starting from before I figured out what was going on). [I also also used WITHOUT_BINTUTILS for the aarch64 TARGET_ARCH in the cross 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?23F43EA1-3741-47BD-97D9-2BA816692492>