Re: Rock64 configuration fails to boot for main 22c4ab6cb015 but worked for main 06bd74e1e39c (Nov 21): e.MMC mishandled?

Hello again.

On 2021-Dec-9, at 00:43, Mark Millard <marklmi@yahoo.com> wrote:

> On 2021-Dec-8, at 23:19, Emmanuel Vadot <manu@bidouilliste.com> wrote:
> 
>> Hi Mark,
> 
> Hello.
> 
>> On Wed, 8 Dec 2021 20:36:20 -0800
>> Mark Millard via freebsd-current <freebsd-current@freebsd.org> wrote:
>> 
>>> [ Note: wma@FreeBSD.org is only a guess, based on:
>>> https://lists.freebsd.org/archives/dev-commits-src-main/2021-December/001931.html ]
>>> 
>>> Attempting to update to:
>>> 
>>> main-n251456-22c4ab6cb015-dirty: Tue Dec  7 19:38:53 PST 2021
>>> 
>>> resulted in boot failure (showing some boot -v output):
>>> 
>>> . . .
>>> mmc0: Probing bus
>>> . . .
>>> mmc0: SD probe: failed
>>> mmc0: MMC probe: OK (OCR: 0x40ff8080)
>>> mmc0: Current OCR: 0x00ff8080
>>> mmc0: Probing cards
>>> mmc0: New card detected (CID 150100444a4e423452079f43b2ae6313)
>>> mmc0: New card detected (CSD d02701320f5903fff6dbffef8e40400d)
>>> mmc0: Card at relative address 0x0002 added:
>>> mmc0:  card: MMCHC DJNB4R 0.7 SN REPLACED MFG 06/2016 by 21 0x0000
>>> mmc0:  quirks: 0
>>> mmc0:  bus: 8bit, 200MHz (HS400 with enhanced strobe timing)
>>> mmc0:  memory: 244277248 blocks, erase sector 1024 blocks
>>> mmc0: setting transfer rate to 150.000MHz (HS200 timing)
>>> mmcsd0: taking advantage of TRIM
>>> mmcsd0: cache size 65536KB
>>> mmcsd0: 125GB <MMCHC DJNB4R 0.7 SN REPLACED MFG 06/2016 by 21 0x0000> at mmc0 150.0MHz/8bit/1016-block
>>> mmcsd0boot0: 4MB partition 1 at mmcsd0
>>> mmcsd0boot1: 4MB partition 2 at mmcsd0
>>> mmcsd0rpmb: 4MB partition 3 at mmcsd0
>>> . . .
>>> Release APs...done
>>> regulator: shutting down unused regulators
>>> GEOM: new disk mmcsd0
>>> regulator: shutting down vcc_sd... GEOM: new disk mmcsd0boot0
>>> busy
>>> GEOM: new disk mmcsd0boot1
>>> Trying to mount root from ufs:/dev/gpt/Rock64root []...
>>> Unresolved linked clock found: hdmi_phy
>>> Unresolved linked clock found: usb480m_phy
>>> mmcsd0: Error indicated: 4 Failed
>>> 
>>> Note the the above line. It seems to be unique to
>>> the failure. Continuing the output . . .
>>> 
>>> uhub2: 1 port with 1 removable, self powered
>>> uhub1: 2 ports with 2 removable, self powered
>>> uhub0: 1 port with 1 removable, self powered
>>> uhub3: 1 port with 1 removable, self powered
>>> ugen4.2: <vendor 0x04e8 product 0x4001> at usbus4
>>> umass0 on uhub1
>>> umass0: <vendor 0x04e8 product 0x4001, class 0/0, rev 3.20/1.00, addr 1> on usbus4
>>> umass0:  SCSI over Bulk-Only; quirks = 0x0000
>>> umass0:0:0: Attached to scbus0
>>> pass0 at umass-sim0 bus 0 scbus0 target 0 lun 0
>>> pass0: <Samsung PSSD T7 Touch 0> Fixed Direct Access SPC-4 SCSI device
>>> pass0: Serial Number REPLACED
>>> pass0: 400.000MB/s transfers
>>> da0 at umass-sim0 bus 0 scbus0 target 0 lun 0
>>> da0: <Samsung PSSD T7 Touch 0> Fixed Direct Access SPC-4 SCSI device
>>> da0: Serial Number REPLACED
>>> da0: 400.000MB/s transfers
>>> da0: 953869MB (1953525168 512 byte sectors)
>>> da0: quirks=0x2<NO_6_BYTE>
>>> da0: Delete methods: <NONE(*),ZERO>
>>> 
>>> Nothing more after that.
>>> 
>>> An older kernel (1400042) that happened to be available boots
>>> the same configuration when used instead (same world) . . .
>>> 
>>> main-n250903-06bd74e1e39c-dirty: Sun Nov 21 23:02:57 PST 2021 got:
>>> 
>>> mmc0: Probing bus
>>> . . .
>>> mmc0: SD probe: failed
>>> mmc0: MMC probe: OK (OCR: 0x40ff8080)
>>> mmc0: Current OCR: 0x00ff8080
>>> mmc0: Probing cards
>>> mmc0: New card detected (CID 150100444a4e423452079f43b2ae6313)
>>> mmc0: New card detected (CSD d02701320f5903fff6dbffef8e40400d)
>>> mmc0: Card at relative address 0x0002 added:
>>> mmc0:  card: MMCHC DJNB4R 0.7 SN REPLACED MFG 06/2016 by 21 0x0000
>>> mmc0:  quirks: 0
>>> mmc0:  bus: 8bit, 200MHz (HS400 with enhanced strobe timing)
>>> mmc0:  memory: 244277248 blocks, erase sector 1024 blocks
>>> mmc0: setting transfer rate to 52.000MHz (high speed timing)
>>> 
>>> Note the lack of trying "150.000MHz (HS200 timing)".  Continuing
>>> the output . . .
>>> 
>>> mmc0: setting bus width to 8 bits high speed timing
>>> mmcsd0: taking advantage of TRIM
>>> mmcsd0: cache size 65536KB
>>> mmcsd0: 125GB <MMCHC DJNB4R 0.7 SN REPLACED MFG 06/2016 by 21 0x0000> at mmc0 52.0MHz/8bit/1016-block
>>> mmcsd0boot0: 4MB partition 1 at mmcsd0
>>> mmcsd0boot1: 4MB partition 2 at mmcsd0
>>> mmcsd0rpmb: 4MB partition 3 at mmcsd0
>>> 
>>> Note: The media is actually an e.MMC . Continuing the output . . .
>>> 
>>> . . .
>>> Release APs...done
>>> regulator: shutting down unused regulators
>>> GEOM: new disk mmcsd0
>>> regulator: shutting down vcc_sd... Trying to mount root from ufs:/dev/gpt/Rock64root []...
>>> GEOM: new disk mmcsd0boot0
>>> busy
>>> GEOM: new disk mmcsd0boot1
>>> Unresolved linked clock found: hdmi_phy
>>> Unresolved linked clock found: usb480m_phy
>>> Root mount waiting for: usbus1 usbus2 usbus3 usbus4 CAM
>>> uhub1: 1 port with 1 removable, self powered
>>> uhub0: 2 ports with 2 removable, self powered
>>> uhub3: 1 port with 1 removable, self powered
>>> uhub2: 1 port with 1 removable, self powered
>>> ugen4.2: <vendor 0x04e8 product 0x4001> at usbus4
>>> umass0 on uhub0
>>> umass0: <vendor 0x04e8 product 0x4001, class 0/0, rev 3.20/1.00, addr 1> on usbus4
>>> umass0:  SCSI over Bulk-Only; quirks = 0x0000
>>> umass0:0:0: Attached to scbus0
>>> Root mount waiting for: CAM
>>> Root mount waiting for: CAM
>>> Root mount waiting for: CAM
>>> Root mount waiting for: CAM
>>> Root mount waiting for: CAM
>>> Root mount waiting for: CAM
>>> Root mount waiting for: CAM
>>> Root mount waiting for: CAM
>>> Root mount waiting for: CAM
>>> GEOM: new disk da0
>>> pass0 at umass-sim0 bus 0 scbus0 target 0 lun 0
>>> pass0: <Samsung PSSD T7 Touch 0> Fixed Direct Access SPC-4 SCSI device
>>> pass0: Serial Number REPLACED
>>> pass0: 400.000MB/s transfers
>>> da0 at umass-sim0 bus 0 scbus0 target 0 lun 0
>>> da0: <Samsung PSSD T7 Touch 0> Fixed Direct Access SPC-4 SCSI device
>>> da0: Serial Number REPLACED
>>> da0: 400.000MB/s transfers
>>> da0: 953869MB (1953525168 512 byte sectors)
>>> da0: quirks=0x2<NO_6_BYTE>
>>> da0: Delete methods: <NONE(*),ZERO>
>>> random: unblocking device.
>>> Warning: bad time from time-of-day clock, system time will not be set accurately
>>> Dual Console: Serial Primary, Video Secondary
>>> start_init: trying /sbin/init
>>> . . .
>>> 
>>> (I'll stop with that.)
>>> 
>>> So I end up with a 1400042 kernel and a 1400043 world in order to
>>> boot.
>>> 
>>> The e.MMC has only:
>>> 
>>> # ls -FTld *
>>> -r--r--r--   1 root  wheel   6170 Feb  1 04:48:34 2020 COPYRIGHT
>>> drwxr-xr-x  23 root  wheel   1536 Dec  8 20:18:34 2021 boot/
>>> drwxr-xr-x   2 root  wheel    512 Apr 26 14:39:22 2020 etc/
>>> drwx------   2 root  wheel  33280 Nov 27 09:46:08 2019 lost+found/
>>> 
>>> where the etc/ has only:
>>> 
>>> # find etc/ -print
>>> etc/
>>> etc/hostid
>>> 
>>> World comes from the USB3 SSD that is attached but the kernel
>>> comes from the e.MMC instead. (The kernel can deal with the
>>> USB3 SSD just fine, unlike the U-Boot that is involved.)
>>> 
>>> ===
>>> Mark Millard
>>> marklmi at yahoo.com
>>> ( dsl-only.net went
>>> away in early 2018-Mar)
>>> 
>>> 
>> 
>> Could you try reverting 
>> 8661e085fb953855dbc7059f21a64a05ae61b22c "mmc: Fix HS200/HS400
>> capability check" and let me know ?
> 
> I'm in the middle of something on the systems so it may be a while
> before I do that. (I think it will be my first individual revert
> of some specific old change via the git context. Hmm.)
> 
> Also, I do not know enough to tell the difference between:
> 
> that test being wrong
> vs.
> mishandling of the combination (presuming it is supposed to be valid)
> 
> So I may end up just reporting if it reverts to the old settings
> being in use vs. not.
> 
> But . . .
> 
> I've an old Odroid C2 with an old NetBSD 9.0_STABLE (GENERIC64) on
> it that is on the same type of e.MMC device and the e.MMC is used
> to boot. That old NetBSD reports for the ODroid C2 during booting:
> 
> [   1.8295810] ld1 at sdmmc1: <0x15:0x0100:DJNB4R:0x00:0xddebe217:0x000>
> [   1.8295810] ld1: 116 GB, 15205 cyl, 255 head, 63 sec, 512 bytes/sect x 244277248 sectors
> [   1.8439125] ld1: 8-bit width, HS200, 64 MB cache, 100.000 MHz
> 
> So it appears that some form of HS200 is a possibility as far
> as the e.MMC device is concerned. (I make no claims about related
> Rock64 vs. ODroid hardware capability differences --or FreeBSD's
> intent for the Rock64 in this area.)
> 

So, I tried NetBSD 9.2_STABLE on the Rock64 with a e.MMC as the
boot media: it does not use HS200 mode (so it uses 52 MHz, not
100 MHz).

[   1.8672737] ld1 at sdmmc1: <0x15:0x0100:DJNB4R:0x00:0x9f43b223:0x000>
[   1.8773160] ld1: 116 GB, 15205 cyl, 255 head, 63 sec, 512 bytes/sect x 244277248 sectors
[   1.8773160] ld1: 8-bit width, 64 MB cache, 52.000 MHz

Not that I know any details about why, but it does suggest that
the issue may be Rock64 specific, given what NetBSD 9.2_STABLE
does with HS200 on the ODroid C2 . (I updated the C2's NetBSD
vintage to match the Rock64 experiment so comparison/contrast
results would be more reasonable.)

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