Re: Rock64 configuration fails to boot for main 22c4ab6cb015 but worked for main 06bd74e1e39c (Nov 21): e.MMC mishandled?
- Reply: Mark Millard via freebsd-arm : "Re: Rock64 configuration fails to boot for main 22c4ab6cb015 but worked for main 06bd74e1e39c (Nov 21): e.MMC mishandled?"
- In reply to: Emmanuel Vadot : "Re: Rock64 configuration fails to boot for main 22c4ab6cb015 but worked for main 06bd74e1e39c (Nov 21): e.MMC mishandled?"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
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)