Date: Thu, 9 Dec 2021 05:03:56 -0800 From: Mark Millard via freebsd-arm <freebsd-arm@freebsd.org> To: Emmanuel Vadot <manu@bidouilliste.com> Cc: Free BSD <freebsd-arm@freebsd.org>, "wma@freebsd.org" <wma@FreeBSD.org> Subject: Re: Rock64 configuration fails to boot for main 22c4ab6cb015 but worked for main 06bd74e1e39c (Nov 21): e.MMC mishandled? Message-ID: <43901D57-9C39-4FAC-A2BE-CCE642791705@yahoo.com> In-Reply-To: <053617FD-AA34-4A3F-853A-4D2E44F8254B@yahoo.com> References: <243CBFC7-DFB5-4F8B-A8A3-CFF78455148D.ref@yahoo.com> <243CBFC7-DFB5-4F8B-A8A3-CFF78455148D@yahoo.com> <20211209081930.7970b6995a8f7c5f7466227d@bidouilliste.com> <053617FD-AA34-4A3F-853A-4D2E44F8254B@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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: >=20 >> Hi Mark, >=20 > Hello. >=20 >> On Wed, 8 Dec 2021 20:36:20 -0800 >> Mark Millard via freebsd-current <freebsd-current@freebsd.org> wrote: >>=20 >>> [ Note: wma@FreeBSD.org is only a guess, based on: >>> = https://lists.freebsd.org/archives/dev-commits-src-main/2021-December/0019= 31.html ] >>>=20 >>> Attempting to update to: >>>=20 >>> main-n251456-22c4ab6cb015-dirty: Tue Dec 7 19:38:53 PST 2021 >>>=20 >>> resulted in boot failure (showing some boot -v output): >>>=20 >>> . . . >>> 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 >>>=20 >>> Note the the above line. It seems to be unique to >>> the failure. Continuing the output . . . >>>=20 >>> 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 =3D 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=3D0x2<NO_6_BYTE> >>> da0: Delete methods: <NONE(*),ZERO> >>>=20 >>> Nothing more after that. >>>=20 >>> An older kernel (1400042) that happened to be available boots >>> the same configuration when used instead (same world) . . . >>>=20 >>> main-n250903-06bd74e1e39c-dirty: Sun Nov 21 23:02:57 PST 2021 got: >>>=20 >>> 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) >>>=20 >>> Note the lack of trying "150.000MHz (HS200 timing)". Continuing >>> the output . . . >>>=20 >>> 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 >>>=20 >>> Note: The media is actually an e.MMC . Continuing the output . . . >>>=20 >>> . . . >>> 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 =3D 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=3D0x2<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 >>> . . . >>>=20 >>> (I'll stop with that.) >>>=20 >>> So I end up with a 1400042 kernel and a 1400043 world in order to >>> boot. >>>=20 >>> The e.MMC has only: >>>=20 >>> # 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/ >>>=20 >>> where the etc/ has only: >>>=20 >>> # find etc/ -print >>> etc/ >>> etc/hostid >>>=20 >>> 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.) >>>=20 >>> =3D=3D=3D >>> Mark Millard >>> marklmi at yahoo.com >>> ( dsl-only.net went >>> away in early 2018-Mar) >>>=20 >>>=20 >>=20 >> Could you try reverting=20 >> 8661e085fb953855dbc7059f21a64a05ae61b22c "mmc: Fix HS200/HS400 >> capability check" and let me know ? >=20 > 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.) >=20 > Also, I do not know enough to tell the difference between: >=20 > that test being wrong > vs. > mishandling of the combination (presuming it is supposed to be valid) >=20 > So I may end up just reporting if it reverts to the old settings > being in use vs. not. >=20 > But . . . >=20 > 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: >=20 > [ 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 >=20 > 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.) >=20 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.) =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?43901D57-9C39-4FAC-A2BE-CCE642791705>