head -r357356: fails to boot RPi4 but boots Rock64 (same media, moved between machines); -r356426 booted both

[Mark Millard]

[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üchemann <maciphone2 at googlemail.com> wrote:
> 
> 
> 
>>> Am 01.02.2020 um 20:02 schrieb Mark Millard <marklmi at yahoo.com>:
>>> 
>>> I described the original sequence that made the originally
>>> -r356426 based Rock64 microSD card also bootable on the
>>> RPi4 in:
>>> 
>>> https://lists.freebsd.org/pipermail/freebsd-arm/2020-January/021117.html
>>> 
>> 
>> Thanks for posting (I also ’ve both boards available), 
>> so we can assume that’s an (known) RPI4-only issue, which I also encounter when compiling to 
>> GENERIC-NODEBUG(or whatever kernel)  to  r357335 yesterday.
>> I discussed that with Kyle Evans in : 
>> https://reviews.freebsd.org/D15955
>> 
>> . . .
>> That was a copy/paste-issue because I was watching football the same time I wrote :-)
>> 
>>> . . .
>> 
>> The rescan seems to fail... so that if you were on mountroot > -prompt   it probably wouldn’t be help to mount 
>> by ufs:/….     
> 
> As long as it is reporting:
> 
> "APs not started"
> 
> that APs issue likely has nothing to do with lack of
> rescanning for "card insertion / removal detection".
> 
> Also, the examples of
> 
> 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
> 
> are new compared to -r356426 .
> 
> 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.
> 
>> But I’ve read somewhere that 1 user had success by mounting mmc/uSD by typing ufs:/… @mountroot
> 
> "PSCI version number mismatched with DT" and "APs not started"
> can not be fixed by such a activity.
> 
>> 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 ….
> 
> I do not get such and I want the APs to start and such.
> 
>> 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 
>> 
> 

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=ufs:/dev/ufs/rootfs
  vfs.root.mountfrom.options=rw

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: ============== REGISTER DUMP ==============
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: ===========================================
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.

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