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

From: Mark Millard via freebsd-arm <freebsd-arm_at_freebsd.org>
Date: Thu, 09 Dec 2021 08:43:30 UTC
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.)


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