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

From: Kornel_Dulęba <mindal_at_semihalf.com>
Date: Thu, 09 Dec 2021 16:01:54 UTC
Hi,

On Thu, Dec 9, 2021 at 2:04 PM Mark Millard via freebsd-arm
<freebsd-arm@freebsd.org> wrote:
>
> 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.)

I don't think de9c000cedfe has anything to do with it as it only
modifies the Freescale sdhci driver.
The Rock64 MMC controller doesn't use that code.

In 8661e085fb95 I fixed the HS200/HS400 capability detection primarily
for DT based controllers.
Rock64 controller declares HS200 support with "mmc-hs200-1_8v;"
property in the eMMC node in rk3328-rock64.dts.
I guess that since it doesn't work the quickest WA for this would be
to add SDHCI_QUIRK_BROKEN_MMC_HS200 to sc->quirks in sdhci_fdt.c.