Date: Sat, 1 Feb 2020 14:34:01 -0800 From: Mark Millard <marklmi@yahoo.com> To: =?utf-8?Q?Klaus_K=C3=BCchemann?= <maciphone2@googlemail.com> Cc: freebsd-arm@freebsd.org Subject: Re: head -r357356: fails to boot RPi4 but boots Rock64 (same media, moved between machines); -r356426 booted both Message-ID: <D7321B5B-8551-4FBA-AC3E-5FDA15F22DA2@yahoo.com> In-Reply-To: <DECBBABE-4A52-4AE3-860F-D0D84AE88712@yahoo.com> References: <63205335-8E8A-4CCB-BC80-E4EC767FBC09.ref@yahoo.com> <63205335-8E8A-4CCB-BC80-E4EC767FBC09@yahoo.com> <EF8A3BE3-DF0A-4544-9BD6-3071E6516202@googlemail.com> <E3D981E8-D6D3-4CFA-BA80-4A9BBFBB7E80@yahoo.com> <0908ECCA-4776-4662-9C78-309C20445BE5@googlemail.com> <DECBBABE-4A52-4AE3-860F-D0D84AE88712@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[It looks like I can make what I'm seeing clearer relative to what maciphone2_googlemail.com reported in D15955 .] On 2020-Feb-1, at 14:07, Mark Millard <marklmi at yahoo.com> wrote: > On 2020-Feb-1, at 12:45, Klaus K=C3=BCchemann <maciphone2 at = googlemail.com> wrote: >=20 >=20 >=20 >>> Am 01.02.2020 um 20:02 schrieb Mark Millard <marklmi@yahoo.com>: >>>=20 >>> I described the original sequence that made the originally >>> -r356426 based Rock64 microSD card also bootable on the >>> RPi4 in: >>>=20 >>> = https://lists.freebsd.org/pipermail/freebsd-arm/2020-January/021117.html >>>=20 >>=20 >> Thanks for posting (I also =E2=80=99ve both boards available),=20 >> so we can assume that=E2=80=99s an (known) RPI4-only issue, which I = also encounter when compiling to=20 >> GENERIC-NODEBUG(or whatever kernel) to r357335 yesterday. >> I discussed that with Kyle Evans in :=20 >> https://reviews.freebsd.org/D15955 >>=20 >> . . . >> That was a copy/paste-issue because I was watching football the same = time I wrote :-) >>=20 >>> . . . >>=20 >> The rescan seems to fail... so that if you were on mountroot > = -prompt it probably wouldn=E2=80=99t be help to mount=20 >> by ufs:/=E2=80=A6. =20 >=20 > As long as it is reporting: >=20 > "APs not started" >=20 > that APs issue likely has nothing to do with lack of > rescanning for "card insertion / removal detection". >=20 > Also, the examples of >=20 > QUOTE > psci0: <ARM Power State Co-ordination Interface Driver> on ofwbus0 > psci0: PSCI version number mismatched with DT > device_attach: psci0 attach returned 6 > END QUOTE >=20 > are new compared to -r356426 . >=20 > There seem to be other, bigger issues not involving > "card insertion / removal detection" at all. I'd > prefer that those be addressed first and do not > plan on looking into rescanning related chnagess at > this time. >=20 >> But I=E2=80=99ve read somewhere that 1 user had success by mounting = mmc/uSD by typing ufs:/=E2=80=A6 @mountroot >=20 > "PSCI version number mismatched with DT" and "APs not started" > can not be fixed by such a activity. >=20 >> When I waited a moment after the mount-crash it gave me the = mountroot> prompt on RPI4 but with me no way to mount manually at the = moment, so this issue has to be fixed =E2=80=A6. >=20 > I do not get such and I want the APs to start and such. >=20 >> I have updated the Wiki a little( and will add more today) : >> https://wiki.freebsd.org/arm/Raspberry%20Pi >> .. welcome there if you have interesting news=20 >>=20 >=20 After: CPU 1: (null) (null) r0p0 affinity: 0 CPU 2: (null) (null) r0p0 affinity: 0 CPU 3: (null) (null) r0p0 affinity: 0 I never see anything like (from D15955): Mounting from ufs:/dev/ufs/rootfs failed with error 19. Loader variables: vfs.root.mountfrom=3Dufs:/dev/ufs/rootfs vfs.root.mountfrom.options=3Drw Manual root filesystem specification: <fstype>:<device> [options] Mount <device> using filesystem <fstype> and with the specified (optional) option list. eg. ufs:/dev/da0s1a zfs:zroot/ROOT/default cd9660:/dev/cd0 ro (which is equivalent to: mount -t cd9660 -o ro /dev/cd0 /) ? List valid disk boot devices . Yield 1 second (for background tasks) <empty line> Abort manual input But, I instead the next thing that I see looks like (actual example): sdhci_bcm0-slot0: Controller timeout sdhci_bcm0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D REGISTER = DUMP =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D sdhci_bcm0-slot0: Sys addr: 0x000004c8 | Version: 0x00001002 sdhci_bcm0-slot0: Blk size: 0x00000200 | Blk cnt: 0x00000001 sdhci_bcm0-slot0: Argument: 0x0ee2afff | Trn mode: 0x00000012 sdhci_bcm0-slot0: Present: 0x1fff0a06 | Host ctl: 0x00000007 sdhci_bcm0-slot0: Power: 0x0000000f | Blk gap: 0x00000080 sdhci_bcm0-slot0: Wake-up: 0x00000000 | Clock: 0x00000107 sdhci_bcm0-slot0: Timeout: 0x00000003 | Int stat: 0x00000021 sdhci_bcm0-slot0: Int enab: 0x01ff003b | Sig enab: 0x01ff003a sdhci_bcm0-slot0: AC12 err: 0x00000000 | Host ctl2:0x00000000 sdhci_bcm0-slot0: Caps: 0x45ee6432 | Caps2: 0x0000a525 sdhci_bcm0-slot0: Max curr: 0x00080008 | ADMA err: 0x00000000 sdhci_bcm0-slot0: ADMA addr:0x00000000 | Slot int: 0x00000001 sdhci_bcm0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D mmcsd0: Error indicated: 1 Timeout In my context, "hung up" means watching a sequence of such messages. As far as I can tell, my context simply does not have the issue that you are investigating. =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?D7321B5B-8551-4FBA-AC3E-5FDA15F22DA2>