From nobody Thu Dec 09 16:01:54 2021 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id AB27818CB87F for ; Thu, 9 Dec 2021 16:05:28 +0000 (UTC) (envelope-from mindal@semihalf.com) Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J8zQc443jz52F1 for ; Thu, 9 Dec 2021 16:05:28 +0000 (UTC) (envelope-from mindal@semihalf.com) Received: by mail-ed1-x529.google.com with SMTP id x10so3949936edd.5 for ; Thu, 09 Dec 2021 08:05:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=semihalf-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dNHYvo27Tb887sgDlhvZL8qFxFU+J3ZKdstfq57pviI=; b=70yXonqwsLL2i61oyFnz88mCauqNCBh7M/yAwbHGlafbu/e4Fg/cNsyCQuoqbh4Jtq hoe4XrEuNbsBdQTfQjGUjuLf0kruKsbm1JSD4xFq7jJUPoie773rCWJd9uCA8vqVOmxb F85Hlofx0yZY8rSGLG5lygLt9uQqxDArx1MJFGYkLB4Y5qHEehXhXyOuUge4j+DlqYDr dcPL7fnEKkb3Sp+UG13ER71GjrXh0yzbJwujZDfKgsHLrmfYFO7s7V8/r/19SlMo2+tR YW9/pAinX6evq+BVL3+ErLim0zqvi1UXxHTo9SzMFRy6egX4F0TfZdGMm6/dZquUNaUd mDqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dNHYvo27Tb887sgDlhvZL8qFxFU+J3ZKdstfq57pviI=; b=Pk7t+tuK4hG/a83VsVuL3J5zMAqwyTaQ7gM6jevMFYQCLM1zc/weCyP/u2aEWR50/7 /pOHwpYtdl6JyUnqw/se27U/DvBjMkzFxGLn2QcBf1Fe7tLFw617SMspjLPDx+zRWQJx xpV7TfeqtwQOFh7eJ/eaR7d4txseyx/TkOQKK5xc4kclQ2uqxjZbTSmIGxsR351Y8Fw4 O7sqI+Iq5wjaFCKXuh+nGJO1TFTz6ZbPLk1vM40TD4Mhdlcm86w3REXuYq59H5cb7BfH NG+FmfHEzdR5bqTdZESQ3w4BlLTimuKj01PlO1K+MT6OUxVZjB8Ei6Gor76NUTAAWT+1 4rGQ== X-Gm-Message-State: AOAM5336AcyTB37TpoZHiSpRL2+1UGXbuqZy//ybILqc76u7yYzt1LD6 qkT7NpVx1PDQmzR1+cjC3L3F+fGFs+VtRB3yKABFCkZANNOcJA== X-Google-Smtp-Source: ABdhPJzAcoHsZ9+JbvSPKP7AHukHvaoSNZnLxcDGQjAH/6n3CPJOag5ZRsR7gzfkQxrx5CpKnABn1KRl4p7z1AhO0aM= X-Received: by 2002:a05:6402:27cf:: with SMTP id c15mr25793387ede.128.1639065725726; Thu, 09 Dec 2021 08:02:05 -0800 (PST) List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 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> <43901D57-9C39-4FAC-A2BE-CCE642791705@yahoo.com> In-Reply-To: <43901D57-9C39-4FAC-A2BE-CCE642791705@yahoo.com> From: =?UTF-8?Q?Kornel_Dul=C4=99ba?= Date: Thu, 9 Dec 2021 17:01:54 +0100 Message-ID: Subject: Re: Rock64 configuration fails to boot for main 22c4ab6cb015 but worked for main 06bd74e1e39c (Nov 21): e.MMC mishandled? To: marklmi@yahoo.com Cc: Emmanuel Vadot , Free BSD , "wma@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4J8zQc443jz52F1 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N Hi, On Thu, Dec 9, 2021 at 2:04 PM Mark Millard via freebsd-arm wrote: > > Hello again. > > On 2021-Dec-9, at 00:43, Mark Millard wrote: > > > On 2021-Dec-8, at 23:19, Emmanuel Vadot wrote: > > > >> Hi Mark, > > > > Hello. > > > >> On Wed, 8 Dec 2021 20:36:20 -0800 > >> Mark Millard via freebsd-current 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 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: at usbus4 > >>> umass0 on uhub1 > >>> umass0: 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: 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: 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 > >>> da0: Delete methods: > >>> > >>> 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 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: at usbus4 > >>> umass0 on uhub0 > >>> umass0: 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: 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: 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 > >>> da0: Delete methods: > >>> 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.