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

Mark Millard via freebsd-arm <[email protected]>
Newsgroups gmane.os.freebsd.devel.arm
Message-ID <[email protected]>
On 2021-Dec-8, at 23:19, Emmanuel Vadot <[email protected]> wrote:

> Hi Mark,

Hello.

> On Wed, 8 Dec 2021 20:36:20 -0800
> Mark Millard via freebsd-current <[email protected]> wrote:
> 
>> [ Note: [email protected] 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)
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.