From nobody Mon May 31 03:49:32 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 45654C7C56E for ; Mon, 31 May 2021 03:49:38 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic307-8.consmr.mail.gq1.yahoo.com (sonic307-8.consmr.mail.gq1.yahoo.com [98.137.64.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4FthB97303z3JCR for ; Mon, 31 May 2021 03:49:37 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1622432975; bh=PjTT7sGi8VVPs0bAEA+pYh6pc5EIm0tBlai6MTC0mpo=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=AM00Kj6RcvfxyrQS9QXLElEKJPKV3fja8kFf6q33IJnYv7NlaQ9jEq575cT394SmHchorC6X3ylxi9Em+QULMa2cFHDw5TGmZg+HKFoqh5DM6ROZr4nGPnzjYQGBMdDr2yOQPvQlbObrDGa84qJ+06yc0vQm9/A9fszFQMnPuQUIvknMGta5nC2L/K5rS9Z6/+IfXpMTBVbimHIpS4JQvcNha21+b7E93VUGf/E588+0Pk6okvpRbtuw+RkrFZS/IbFpNciy+Pg3ZhIZa3fxNWWyhvTwb9Kf8WRPHrvMaDXbwjHYuF8hXGhba+NoTRmheSeqQ6n2uMbAeteX4PDMUg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1622432975; bh=+jzsstJGQOtZ2phz2BcaLdUqXkuTIlWc+Y2n/FaC5MW=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=hWPcFcrJ3EJOtkqgtvkVhpaJ/8CSMuRDxwhWhKgcz4h8mfQeyZYySjkFiQnnz7O9GC5jh0OqpcAfwifH+5FbJ3s4zJHpqjo5iVedbsslEdxsmO6OMRa8OG5zr2mSqDvZIYrVcq9yqTGTuh9kt1Ed5Vi/Mk7N+YOm+/ZIDT/Dff5ftM14A2rUiO5pTjFTDsaEeuM/HzEEvMNzYmNCuCEoxl464y+0EeFcdwat5QJ02KPKolEd4oy9RmnpWAUercrFE9Tiuk5ML7vpis1HtvLG/57Zc2JGpetRRIHIyuPKTcZR0+ipoQFdexkzl2c4zAgpO8f31iCbB9ltoS0lBxwDDg== X-YMail-OSG: O0wTQtMVM1mJO_KdbZ4Ff8g99OjfSfUYZXV0fBDFQ4LtEOja0Hr0umf0rOJQmpl d8EZdnF8VCRdNSht6zs.ZVwQDT2e.Nc2ZUYoBPpYanpch_dKx8Wm8e3qnS08.xABhgsVH1ktcrie z.fy5YtgVmldw1UFrbf5.ai2F5bywNBckN8mtVZrHfUImvJJ8UbrGkZuDa_DLkOWJSPFmZ3WrBzY 0rUIBEd9wiD4WGMECpkH3iPfciwMeKNdH2r0w0vt5ws9KU0HJFxcHCxHDYe7HPlRP2YrkIN_oWLu gp_lWV5eFb3I9.IYotThIPzr.BVTdKNed5aAgWj8Az6TNXjlqip.r4sA5KP8C1O5gzTC1jGzt1ag ulp30Yi3V06QBEqq8eM_fw84EFAjzXyOZMZBj2PpHj.fwZ_u6tDk0I0_QMnkRW5XaM5n1DkDPi91 FNbsuoKIwTvsK0KqsmCo4DbZKQe4G8SdURsbJMfawBDHFLUbdKjFXrNB0QU8AXT.oh.bfc2bw1vr CUnQdV.gJqb3oaRMz9GMlVLyAQlJyHs8P4fAaLPs.6k1apSI00W37xEjeGO0idXq6VLJzjnHca04 DZPGscltTrtSQ1cCPs1orw3wdSnWMskW7SlplwCEUp8DUYK5r_xzGG2X5XjFeD5tUMg0sZhk7i87 9vTezb4_1lkCgCBj3iXPKLLGTniu6zB0ACIcZj4agfRPWDTMaXSWVkbCYcz0gqm33cjz7usmXUuD cCGRD6tEcob.V78rLxEWgD5KsNpvqO6khKjwIC285oo2ea.Pbh_y.NQHGdeDyWrMrW4DZlbLhcQE dZWHgtCmv_3myvXthh1WKJARloQmHIgguD8_mNfOEwJ_hC79LWExt8xgFsMOv6dzJc1xvDV1gd14 3ywNVlEt8Q25yEOnJ.8iOsKM74pGHSQHvmXHpQpFuirWyNojWOlTWFMgHH4WiJESZd79Od1AUHCE z6qGKLJeLkFmHHsRYSTqllAJNVLpX.VBh7r64P1TKQIam7E.c2B_SMUOfWPmjhHwCY8DjSFCIaja egzPl1xELKmv_wycndhubTUG0_Rky7XmX6JL.8PLz9vrkggwhjI6sgeT05JhnT_.Z7y6tAn2c.2Q 1bCGX3dBfTFW4S0V4e6igHZ133Vzt6g_siXzwkzYqhk8jkh9lHVdGFiHtTgFNsdBAm9uBdYGyF6p .SQglhdZA_t3X7j5IhL6G_ma5mc5QoKzyTcqdrbgKSykaB8lqaHpyiQc8N3RgE_7t33oxvuM32kV sfpW0y573j9fSAE2yIQ4L1uw0qPbBhRQ3AxrSdbgTzHuxPYoXt1P8nex2ymSC1CMRH4p3F.bCO7l EJjy.8bGsy96Ggd54iz5pAwbIcZ476cKi4zrt0McX8shJo9gMt41_ieFybnMUkb5YDTpnxblWz_D rrmMMZcEwe8F8Qkoa_gVEL3yxTrm10ai8RgSj1M_LFpJG5309kW_Kkz16EzMJ0SBUTKwQRaD9Xng i0QZ1.e9.F6N1nbAjgz2Wt7dLpCjIMF.VhiBE94Fi4JXC4SkW1JaHJqoKfBZ6JCpyMgDQ.mnk8iB ZrY4uCQ2Bt5GxKbn0zrfP_mwG8cCDNk7b1T4zMI7NqEiJJ6hsLqcQjxoaz44eGWbNnON9fTVXnB7 ryqAN7_MvNte7e4mchIFoSSCwYEYngwHg0ubt81VlesnzqR1ILHH6IYgieO3eegZh_yoiLqKw8OW _nmKNbqVKCGx4H__wwECsFZl8yEAkH5PtcW.7fhxaIPqbpyOD9LVw0CnsIKgPWlZKajjnJLMkShx n3xGbPj7y26k09lQg32euEixW23KXISjp7XwpMgAk.KtpDX9JhMlim1UbNPJQH9IGO5OTibxsE9T 4mQwstAx8ALIDyLR3scwu36.3GCBmFiMPMdpQRpcqecdVCPk7J2ZT8vJjdZwnsaib36FB_GMHIvz dKI_VBBjodoYmncrmTBvnlxC.VzByZH8yUcp04YD6cEipBknP6Lk8uo85OfVMc7tjva7NkWz7IG6 tmGDGqQeo10fsRc57t7V2L70HwzH3G8ZKNkyBoDDMCfn187TrTowQPAqlJJqZVLWbsWmtXUswEhF 8_R4y.zN9GT7CFvuSwYSEHWSIyTdoHCD8HYs52e3E3Eeh8SlYU5neEwIUeMVolI48WE807iasQsG mLBDOekCmhdrlQNf8hBbow6WioSU3PenVHJDNXxqLhRHz0KKYPzcHhao5zUZuK8MEUnwFNAnwmav .jf24sExWN.95lAUG4kdPb6GylsMHIcKVsH_GEJzCulQ9hnYj8FLjySTUAlU3mzrvvwCphYk2pRH 5WEHuXxSfONeMCxh2pH3.OGGDlyorK1oN696pGXG5DyMVbHOs7SUzPb_VWMeXrlGZJ0HGTUPLfPB 4QDDS4S1Y2P89QRGGfUQVPke4xui9mxCZpdWn4Flob21HGKiBKMY82kfCokiy7hXHLHhqQOqGo3T bZ0_2zy1RkOlkCeGa203Ybw1Ku7Rx9E6MJwRC.ZCDerQ- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.gq1.yahoo.com with HTTP; Mon, 31 May 2021 03:49:35 +0000 Received: by kubenode581.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 46b8088dd28c50fd7031fd27ff8e0302; Mon, 31 May 2021 03:49:32 +0000 (UTC) Content-Type: text/plain; charset=utf-8 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 (Mac OS X Mail 14.0 \(3654.80.0.2.43\)) Subject: Re: Boot from USB on RPi4 8GB? In-Reply-To: Date: Sun, 30 May 2021 20:49:32 -0700 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F3EE8D2-649B-4522-AD5A-7C308291802F@dsllsn.net> <43FAEEAC-EE36-4810-88AA-FF82AFBCC128@yahoo.com> <2F58272B-BD9C-464B-9A98-BF638971BA86@dsllsn.net> To: freebsd@dsllsn.net X-Mailer: Apple Mail (2.3654.80.0.2.43) X-Rspamd-Queue-Id: 4FthB97303z3JCR X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-arm X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-May-30, at 16:54, William Carson via freebsd-arm wrote: >> On May 30, 2021, at 4:08 PM, Mark Millard wrote: >>=20 >> On 2021-May-30, at 13:50, Mark Millard via freebsd-arm wrote: >>=20 >>> On 2021-May-30, at 10:59, William Carson via freebsd-arm = wrote: >>>=20 >>>>> . . . >>>>> I use a USB3 SSD that has small enough power requirements >>>>> to not require a powered hub. (I also use a 5.1V 3.5A >>>>> power supply as part of that context.) I've never tried >>>>> spinning rust or higher powered USB3 media. >>>=20 >>> I view the power supply that I use as just giving a little >>> more margin, not as a way to increase what the devices >>> total to. >>>=20 >>>> . . . I'm not sure what's considered "high powered" but the Samsung = tech specs say this particular model uses 5.7 W on average and 10.0 W = maximum. But it does seem curious that the Raspberry PI OS will boot = this disk without issue, so I don't think it's the drive. I also tried a = Samsung 950 PRO using a different enclosure (QNINE NVME Enclosure, M.2 = PCIe SSD (M Key) to USB 3.0 External Case), but it behaved the same. >>> . . . >>>=20 >>> Then you need to use a powered hub for that device. >>=20 >> I should have just referred to independent power. You >> had written: >>=20 >> QUOTE >> I'm trying to use a SAMSUNG (MZ-V7E500BW) 970 EVO SSD 500GB - M.2 = NVMe, attached via the Geekworm X872 M.2 NVMe 2280/2260/2242/2230 SSD = Expansion Board. >> END QUOTE >>=20 >> = https://geekworm.com/products/raspberry-pi-4-x872-m-2-nvme-2280-2260-2242-= 2230-ssd-expansion-board >>=20 >> shows that it has its own power connector and has an image >> that says "please power x872 via DC Jack of XH2.54 connector >> if SSD is not recognized or low power". Later text on the >> page says: >>=20 >> QUOTE >> Specifications: >> Power Supply >> =E2=80=A2 5Vdc +/-5% , Powered by Raspberry Pi USB port >> =E2=80=A2 5Vdc via DC power jack or XH2.5 connector, Extra power = for the SSD >> END QUOTE >>=20 >> So, if I gather right, you need to connect a power >> supply to the X872 and another to the RPi4B. >>=20 >> Another image says "Note: NOT recommended to use SAMSUNG SSD, >> if use SAMSUNG SSD, please close WiFi". Later text on the page >> says the same. >=20 > A-ha, indeed. I just noticed that as well. I've gone ahead and ordered = a supplementary power supply and a lower-power NVMe to do more testing. = I'll send an update once I've received and tested them. >=20 > Thank you for hopefully pointing me in the right direction. I do not know if the "supplementary power supply" would be sufficient for the existing drive to work, but it is likely necessary. Similarly for any other drive that could require a significant portion of the 1.2A at times. (I've no clue what else you have plugged into USB or how much power(/current) those devices take (if any). So I do not know what to subtract from the 1.2A.) The USB3 SSDs that I'm using are based on: ATA Version is: ATA8-ACS, ACS-2 T13/2015-D revision 3 SATA Version is: SATA 3.0, 6.0 Gb/s (current: 6.0 Gb/s) This helps explain why I've got no power problem: older technology. Note that SATA 3.0 can be somewhat faster than the original USB3 already, at least in some respects. >> = https://www.raspberrypi.org/documentation/hardware/raspberrypi/power/READM= E.md >>> lists: >>>=20 >>> "Maximum total USB peripheral current draw" as: 1.2A , >>> which at 5.1V is 6W. (Possibly should have listed the 6.12W figure.) >>> That figure is the total for all USB devices attached >>> that are not powered independently. >>>=20 >>> That document also says that a 5.1V supply is required, >>> not 5V. >>>=20 >>> The power supply that the RPi folks supply is 5.1V @ 3A >>> or 15.3W. Even the 5.1V 3.5A power supply that I use >>> only multiplies out to 17.85W. >>=20 >=20 >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Mon May 31 05:27:31 2021 X-Original-To: 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 E79CAD78DD3 for ; Mon, 31 May 2021 05:27:38 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic309-22.consmr.mail.gq1.yahoo.com (sonic309-22.consmr.mail.gq1.yahoo.com [98.137.65.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4FtkMF465Cz3QPC for ; Mon, 31 May 2021 05:27:37 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1622438855; bh=zRyduKlKK6C0w0Pjn3QFuyOLthSvk7FC7bUYclcKJu0=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=ZOdV6FZ6bZZekxjeLqwkh7VKg1v7HWl8n7kRAGmG8LeVljX/pbEAdFXbl/Uu2O4Us2lhHgUeVompK1o8LZvPNaDfR7mapfrBzYJZRLmVfjANI3np/vrvSED6SmsVS2TYYeXPeLAEEAJVpSsbrvP6jw3hy4ADR096GKwT3DjjQdijFMXvJUzOzkE6+ZMk/jjEqcl3PAdXue7yS6UEVb626NvdjbO3ZlSstGCK5yGl3CCQJEfw+V3WYZph7X39EaMzGC8dXGnYEOrjxtLgmRMTmt8yZ1huGTZfhFmre+fSqwwZx5l8FkJD+GC1wfHiiLRoSW9ARX25N9vIJ8UHwwzruA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1622438855; bh=yu3GUJ/YhJ0KqYfdIh6Mi+UhI+ttfS1I3W7381Dxfls=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=sNdMsTLK7OQpMBmW0hYYgu66EwfXkTLE1HhkRKKzGaLpwcCJMzqgRQ2T620YtJUo2LMJOkGBBk4V+B1K8iy8GocRJrIvy8LLc3E+8mdwbuQDxDXIOfJvzwavwNWzERZS1BXqRpB+iL8g3xkZN0g5yzPgjQeR0mzgz4Dm9rwyJIkOlMMjzViQGsriHnaLTL/J4UyWKwaHyBNSIqyLqFVELkrEpFnIReJs/IBsFWu1up75SkZHnJs3rRuxGF7C62E/owuL5V9zQjkOZSNW6d9WkVXr9ZQ203/dHPKLjrBixHGxA7UjYbhhE77ZAO/4GVdVLsHQF7bHuiI5Jyqs3lmvXw== X-YMail-OSG: 3TalKqMVM1nfUuaafoCvxUEL0DjTBxhpSPx9sahojNBBnD7E72iW044Py1p_oUK dv2bApOfWozGxvLM3_qqckZ.s99fFMyB9t5LBNLMnxtKM2JTAepMMH5i_KVg47ZSDlCHeNyUm5Lt Aa2ZadZonkGsgmyJNPxKW60WUjr4Z60ZgUx8xP.sO8J2HAkytIXFWlheIm.waDVWkk.QAxEbnB1M ospE.2W8kKR5EAg6jDfFXOuHp80DvNSO.mCh6rq4A00pSxLpzPmgJoICOYC73549RgLzCNd.kNjz W_Jc.54LnUwiqST5ZdQ.3gGgyqM7SnuwbMappvNbySUPeaJfW_ijZXvgnfH6BpOU1PpS9MbXdIAR hWl3e9G_wkGd1B35H8x3BaHNL5WswRsTE17msi2zv9jV59xqlv6QSi8OFN_HAEuhNr1qc1jwmm1e WIUQIxztJyk2qZ93l9t0bIVYJfIGTcOU7ckcpwWk1VLC1b475XkZ57Rno2ZufE.oIraq_MJdfm8D gaXzLutEeFJ9Fik6ptdWV2nQk_CBG5fvIZTjSPLefQtwgySy677eEsda13lbXAvjjraVyxQc8aI9 0Cjyq7MCUN0pssfJ_yf7SV1VwqXJez_Ag9Q_jKiMJc2osmktFj6M02J.pvRA8bQEnDM6zd1s3oz7 yudqjNQ0.bdkElrtlcV9.10PlJEBEM3Si5F91gzlvu1xfbrz_foAWcYpBagWQqIHBjaOJeIioeQC RRuazPDYHtUXprdsXDxQuaD7U3hAgvlInYGJ7zi69jSvvqtrreW8losRTWT1JPijdXwmTwYfBGqB lKmQzW3Krb4Yb9EM.jMDlMnhcwRYXCnZTMfpk.gVWSY6iK6_aNI_f2FaR48A4XsmFtpl1mLB4jSe 8YU3pZFXH4xbiNFBQMfgrQ73w8RQHpPV6yh6XE3Z0MgeGPoa8hwPEWZjs5.XFIqFsovcsU2.zUbU UVlSYOsYB7ZW.81qoLXtlx9sanZ8UOof9Z2ujYceSKJSphsNOQkaKFk1_5YqgPPRWe7USomq3.kj N9tHTcUegv_IwmeuMXCpr08C93vyggWJ3lpNV6iRZ1hgf7aoMUG4WGbFzdPxgUdJw34eIw4HVl.M 0upEDCnwCH5N9.dO5CANaf9N85ZQicFeiArmVK16IEQM3pi0S1eKYZ4qW_ARKR0A4KT5bAvEY2qY 62wXwkoC2AkcBW3LpNAQWVd43nC75akl5x.evmPTDbAKSAhISTXLzg53zmUYYA40ASv0I2yWWzA7 fFotaK05xVOaJHJuZ5VO0ebAXlc9__pLK1GvhF0pMLZy_8bh_aJwt0A_3.5OwxUTINADKKaAW4sJ uS6zMci6G4SSDJwMSsfratQLila98RlbjOt3InJljcMIN.eIKUfJQaY7oGt9c2CXwCzJJAgsU457 yshEwMWLLaqBxhmkMhv0LntxDcuHmU5Qzhl9a8Fi8egssfK1WlrOmoyT_TVuDRhwDUN5Ddx1WMcO PqCua97znwwGatiCar7q1AvZ1YPFqINDuupab7u7J.Jqkfy_p7HZbROLYxxyZHVVkPdR_kv4beJ6 C_qEHOVyqi6qgUW8WdozhtiAVVWUGsuT8WQzS7CpXH.t9JEdmubafmz4.UEcsS.nGPzvKAkCKsrZ 9ckrSmDaki.69Ccv.v1s8lyYZABhtp.rVy7JDchZ.njdPuqfxLxAvJAUGHcqq.5PLC_Fz0DOUbFo rwEcKUOHdS.IobwCzZWRUydTD5IYtUgBd_diEg0DP5oodAEa1ma07MIzqRkVXav.KwdosqCZyeqc o0qkJC.5m8nYmNlpzby94XoOpUgToxFbQGGEykiH2z0bdMmO6pEZFhCi7qiBe3_nO8d7031oLXmP xdtJdhOG71FgMKb8lB24HVTUZf5OW9xezs_24FP4y3rTtGfu9viNwt982mFxcouPofLOXDH91k7b ZV0yrWYvr2RvQ5NWNzWI0pJpM9C6ShOeugsRdCWVUdr571vCqQ7WvKQSN5EvQDbXHcsIuQviixXm _.cVRx06c_dFsQG9WGxD3Qc8N_O1.inx2DcyRdsyk_6PRTOfHtUVIlj9v3ZM8guKJEnpvq2jtKZt OFwyed2iESb8iVn.c6M_EC7ItwSz81Jju0I8ERUaVvr_E.1nam5UEyTfm3hyjgH_czogd18muKsp p6BaedEeTHr4VXmGpj3w3ksaTYYwGv4RzJ2YjzoYB7Wm6Tw.e0xwoWbia59V6HLc.3EUzp9lh5YZ n1e45M5UOQ2JPTXs.rg7oCVC6OP70mN0xrHQ_iGts4HhWd5AsOxgIa2eUjnZ3tTT9.qU6P0_voV1 WVJ1KzYaLXTNHiG0XcCLH2xHi6R16ClS9Fk.Ui9kPQ8Ola8WcJtSZJfjtNTcU7DpoOzDafiNntzL xP1NocwHya2zPXgpD5Ho7KLn1wcDz5QmoQMH4hbGqeS4awQ68TaBDE8v88zDUsJ.FbSVIUHqiMdF ovLLorczzyYYdj7p8QSPuXmWw6CQRM65wIt3GZCRU7cO4hvKi86VbzRBcgEdcXXHUL0WE8baRPhZ lFIK42_AZp4YLZNDEqcKRojPkUqn1ZMi3HkHqtmTsZ59eJ0d3bM7flyUm.uzwvHLrTCkTGCNZOhm yUoIZhicGo5bJEqjiHRSmmqmz56hBJ77AWj.R9miGxCyZLNcoHpb3yj2KqAQrK_H1ZDG1VntD1bH tM.U- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Mon, 31 May 2021 05:27:35 +0000 Received: by kubenode563.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 49aa2b701f17f3e1c310e4c171ffde94; Mon, 31 May 2021 05:27:32 +0000 (UTC) Content-Type: text/plain; charset=us-ascii 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 (Mac OS X Mail 14.0 \(3654.80.0.2.43\)) Subject: Re: /usr/local/share/u-boot/u-boot-orangepi-plus-2e/README out of date ; orangepi-plus-2e and RPi2 v1.1 get "Kernel args: (null)" In-Reply-To: <0482F239-B137-42F5-8802-8883D08D5868@yahoo.com> Date: Sun, 30 May 2021 22:27:31 -0700 Cc: "freebsd-arm@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <5F226A9B-852D-4E72-9896-0509E56D3318@yahoo.com> References: <40298C05-5F50-4437-B15B-7A02EA070EAE.ref@yahoo.com> <40298C05-5F50-4437-B15B-7A02EA070EAE@yahoo.com> <20210513111517.86336633bae9568d8599f229@bidouilliste.com> <20210513124050.47714a83f876d67a80e28080@bidouilliste.com> <3C04FB55-4A26-48C8-833F-E4AC84DC4F78@yahoo.com> <99906599-273E-4216-A41E-DE642F33E392@yahoo.com> <0482F239-B137-42F5-8802-8883D08D5868@yahoo.com> To: Emmanuel Vadot X-Mailer: Apple Mail (2.3654.80.0.2.43) X-Rspamd-Queue-Id: 4FtkMF465Cz3QPC X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=ZOdV6FZ6; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.148 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RBL_DBL_DONT_QUERY_IPS(0.00)[98.137.65.148:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; SPAMHAUS_ZRD(0.00)[98.137.65.148:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.148:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.148:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[arm] Reply-To: marklmi@yahoo.com From: Mark Millard via arm X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-May-24, at 20:10, Mark Millard wrote: > On 2021-May-24, at 15:53, Mark Millard wrote: >=20 >> On 2021-May-13, at 12:03, Mark Millard wrote: >>=20 >>>>>> . . . >>=20 >> I do not know if the FreeBSD kernel has been depending >> on some U-Boot initialization for root-on-USB and the >> two no longer match or what. >>=20 >> But I've used a release/13.0.0.0 microsd card based >> boot to get older U-Boot materials (Quarterly as it >> turns out). Installing such got me back to having a >> root-on-USB boot of the OPi+2e (other than the >> mircosd card having the older U-Boot (2020.10 as it >> turns out). Of course there is also the matching >> boot.scr involved --but it also is on the USB SSD. >> (Similarly reverted RPi2 U-Boot, other than needing >> to switch boot.scr to match.) >>=20 >> After booting with the reverted U-Boot related >> material: >>=20 >> # mount -onoatime -tmsdosfs /dev/mmcsd1s1 /mnt >> # mount -onoatime /dev/mmcsd1s2a /media >>=20 >> # ls -Tla /mnt/ >> total 20 >> drwxr-xr-x 1 root wheel 16384 Dec 31 16:00:00 1979 . >> drwxr-xr-x 25 root wheel 512 Dec 31 16:00:40 2009 .. >>=20 >> # ls -Tla /media/ >> total 60 >> drwxr-xr-x 2 root wheel 512 May 24 15:43:19 2021 . >> drwxr-xr-x 25 root wheel 512 Dec 31 16:00:40 2009 .. >> -rwxr-xr-x 1 root wheel 52456 Apr 24 19:48:36 2021 bootcode.bin >>=20 >> The media is also set up for booting an RPi2 via >> root-in-USB ( other than bootcode.bin ). >>=20 >> If FreeBSD and the more modern U-Boot were well matched >> for USB support, I'd expect that this sort of thing would >> work (no boot.scr needed). >>=20 >> For reference: >>=20 >> # ~/fbsd-based-on-what-freebsd-main.sh=20 >> FreeBSD OPiP2E_RPi2v11 14.0-CURRENT FreeBSD 14.0-CURRENT = mm-src-n245445-def0058cc690 GENERIC-NODBG arm armv7 1400005 1400005 >> def0058cc690 (HEAD -> mm-src) mm-src snapshot for mm's patched build = in git context. >> merge-base: 7381bbee29df959e88ec59866cf2878263e7f3b2 >> merge-base: CommitDate: 2021-03-12 20:29:42 +0000 >> 7381bbee29df (freebsd/main, freebsd/HEAD, pure-src, main) cam: Run = all XPT_ASYNC ccbs in a dedicated thread >> n245444 (--first-parent --count for merge-base) >=20 > Looks like 2021.04 (even before 2021.04_1) also has the > problem for root-on-USB handling. >=20 > I managed to find a 2021-Apr-09 u-boot-orangepi-plus-2e > directory copy that was 2021.04 (and its boot.scr) but > before the UEFI change. When I tried it for the > root-on-USB context I still got the hangup after "Kernel > args: (null)" in: >=20 > . . . > Hit [Enter] to boot immediately, or any other key for command prompt. > Booting [/boot/kernel/kernel]... =20 > Using DTB provided by EFI at 0x47eea000. > Kernel entry at 0xb2e00200... > Kernel args: (null) >=20 >=20 > So it does not appear to be the UEFI change so much as > 2021.04 in general for which the FreeBSD kernel and > the U-Boot are apparently(?) mismatched for root-on-USB. >=20 >=20 > Reverting again to 2020.10 U-Boot got back the root-on-USB > status. For this the boot looks like: >=20 > . . . > Hit [Enter] to boot immediately, or any other key for command prompt. > Booting [/boot/kernel/kernel]... =20 > Using DTB provided by EFI at 0x47ef5000. > Kernel entry at 0xb2e00200... > Kernel args: (null) > ---<>--- > KDB: debugger backends: ddb > KDB: current backend: ddb > Copyright (c) 1992-2021 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, = 1994 > The Regents of the University of California. All rights = reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 14.0-CURRENT mm-src-n245445-def0058cc690 GENERIC-NODBG arm > FreeBSD clang version 11.0.1 (git@github.com:llvm/llvm-project.git = llvmorg-11.0.1-0-g43ff75f2c3fe) > . . . >=20 Well, I got a surprise in exploring: removing boot.scr and ubldr.bin did not prevent booting. (Noticed by the accident of ending up with one of them missing that I only later noticed.) So I recorded a boot and: . . . U-Boot SPL 2020.10 (Apr 19 2021 - 18:04:31 +0000) DRAM: 2048 MiB Trying to boot from MMC1 U-Boot 2020.10 (Apr 19 2021 - 18:04:31 +0000) Allwinner Technology CPU: Allwinner H3 (SUN8I 1680) Model: Xunlong Orange Pi Plus 2E DRAM: 2 GiB . . . Device 0: Vendor: OWC Rev: 0 Prod: Envoy Pro mini =20 Type: Hard Disk Capacity: 228936.5 MB =3D 223.5 GB (468862128 x 512) ... is now current device Scanning usb 0:4... 30675 bytes read in 3 ms (9.8 MiB/s) Found EFI removable media binary efi/boot/bootarm.efi . . . Booting /efi\boot\bootarm.efi Consoles: EFI console =20 |=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08= \=08|=08/=08-=08\=08|=08/=08-=08\=08 Reading loader env vars from = /efi/freebsd/loader.env Setting currdev to disk2p4: |=08/=08-=08\=08|=08/=08FreeBSD/arm EFI loader, Revision 1.1 . . . So I've likely been been booting via UEFI for some time via 2020.10 (or even before?), just without noticing at the time. The other implication is likely that what disabled root-on-USB for my context was not the boot.scr removal material but some (possibly proper) subset of other material changed (extracted from ports' main 0d6e5081eb00 commit cgit display): diff --git a/sysutils/u-boot-master/files/FreeBSD_Fragment = b/sysutils/u-boot-master/files/FreeBSD_Fragment index 630d295cc8f1..f3837a932e98 100644 --- a/sysutils/u-boot-master/files/FreeBSD_Fragment +++ b/sysutils/u-boot-master/files/FreeBSD_Fragment @@ -1,3 +1,2 @@ -CONFIG_API=3Dy CONFIG_ARMV7_NONSEC=3Dn -CONFIG_CMD_CACHE=3Dy +CONFIG_EFI_GRUB_ARM32_WORKAROUND=3Dy diff --git a/sysutils/u-boot-master/files/patch-api_api.c = b/sysutils/u-boot-master/files/patch-api_api.c deleted file mode 100644 index 5de1e5e653d9..000000000000 --- a/sysutils/u-boot-master/files/patch-api_api.c +++ /dev/null @@ -1,14 +0,0 @@ ---- api/api.c.orig 2018-07-09 14:24:14 UTC -+++ api/api.c -@@ -289,6 +289,11 @@ static int API_dev_close(va_list ap) - if (!err) - di->state =3D DEV_STA_CLOSED; -=20 -+ if (dcache_status()) -+ flush_dcache_all(); -+ if (icache_status()) -+ invalidate_icache_all(); -+ - return err; - } -=20 diff --git a/sysutils/u-boot-master/files/FreeBSD_Fragment = b/sysutils/u-boot-master/files/FreeBSD_Fragment index 630d295cc8f1..f3837a932e98 100644 --- a/sysutils/u-boot-master/files/FreeBSD_Fragment +++ b/sysutils/u-boot-master/files/FreeBSD_Fragment @@ -1,3 +1,2 @@ -CONFIG_API=3Dy CONFIG_ARMV7_NONSEC=3Dn -CONFIG_CMD_CACHE=3Dy +CONFIG_EFI_GRUB_ARM32_WORKAROUND=3Dy diff --git a/sysutils/u-boot-master/files/boot.cmd = b/sysutils/u-boot-master/files/boot.cmd deleted file mode 100644 index b3ce82975eb3..000000000000 --- a/sysutils/u-boot-master/files/boot.cmd +++ /dev/null @@ -1,2 +0,0 @@ -fatload ${devtype} ${devnum}:${distro_bootpart} ${kernel_addr_r} = ubldr.bin && go ${kernel_addr_r} -echo "Cannot load ubldr.bin" diff --git a/sysutils/u-boot-master/files/patch-api_api.c = b/sysutils/u-boot-master/files/patch-api_api.c deleted file mode 100644 index 5de1e5e653d9..000000000000 --- a/sysutils/u-boot-master/files/patch-api_api.c +++ /dev/null @@ -1,14 +0,0 @@ ---- api/api.c.orig 2018-07-09 14:24:14 UTC -+++ api/api.c -@@ -289,6 +289,11 @@ static int API_dev_close(va_list ap) - if (!err) - di->state =3D DEV_STA_CLOSED; -=20 -+ if (dcache_status()) -+ flush_dcache_all(); -+ if (icache_status()) -+ invalidate_icache_all(); -+ - return err; - } -=20 diff --git a/sysutils/u-boot-master/files/patch-api_api__storage.c = b/sysutils/u-boot-master/files/patch-api_api__storage.c deleted file mode 100644 index 2e5846fb9a5c..000000000000 --- a/sysutils/u-boot-master/files/patch-api_api__storage.c +++ /dev/null @@ -1,25 +0,0 @@ ---- api/api_storage.c.orig 2019-07-08 19:23:28 UTC -+++ api/api_storage.c -@@ -69,13 +69,6 @@ void dev_stor_init(void) - specs[ENUM_SATA].type =3D DEV_TYP_STOR | DT_STOR_SATA; - specs[ENUM_SATA].name =3D "sata"; - #endif --#if defined(CONFIG_SCSI) -- specs[ENUM_SCSI].max_dev =3D CONFIG_SYS_SCSI_MAX_DEVICE; -- specs[ENUM_SCSI].enum_started =3D 0; -- specs[ENUM_SCSI].enum_ended =3D 0; -- specs[ENUM_SCSI].type =3D DEV_TYP_STOR | DT_STOR_SCSI; -- specs[ENUM_SCSI].name =3D "scsi"; --#endif - #if defined(CONFIG_CMD_USB) && defined(CONFIG_USB_STORAGE) - specs[ENUM_USB].max_dev =3D USB_MAX_STOR_DEV; - specs[ENUM_USB].enum_started =3D 0; -@@ -281,7 +274,7 @@ int dev_enum_storage(struct device_info *di) - { - int i; -=20 -- /* check: ide, usb, scsi, mmc */ -+ /* check: ide, usb, mmc */ - for (i =3D ENUM_IDE; i < ENUM_MAX; i ++) { - if (dev_enum_stor(i, di)) - return 1; diff --git a/sysutils/u-boot-master/files/patch-cmd_boot.c = b/sysutils/u-boot-master/files/patch-cmd_boot.c deleted file mode 100644 index b0c520aeb2ed..000000000000 --- a/sysutils/u-boot-master/files/patch-cmd_boot.c +++ /dev/null @@ -1,13 +0,0 @@ ---- cmd/boot.c.orig 2018-07-09 14:24:14 UTC -+++ cmd/boot.c -@@ -18,6 +18,10 @@ __attribute__((weak)) - unsigned long do_go_exec(ulong (*entry)(int, char * const []), int = argc, - char * const argv[]) - { -+ if (dcache_status()) -+ flush_dcache_all(); -+ if (icache_status()) -+ invalidate_icache_all(); - return entry (argc, argv); - } -=20 diff --git a/sysutils/u-boot-master/files/patch-cmd_elf.c = b/sysutils/u-boot-master/files/patch-cmd_elf.c deleted file mode 100644 index a6cac78a0989..000000000000 --- a/sysutils/u-boot-master/files/patch-cmd_elf.c +++ /dev/null @@ -1,14 +0,0 @@ ---- cmd/elf.c.orig 2018-07-09 14:24:14 UTC -+++ cmd/elf.c -@@ -153,6 +153,11 @@ static unsigned long do_bootelf_exec(ulong = (*entry)(in - { - unsigned long ret; -=20 -+ if (dcache_status()) -+ flush_dcache_all(); -+ if (icache_status()) -+ invalidate_icache_all(); -+ - /* - * pass address parameter as argv[0] (aka command name), - * and all remaining args =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Mon May 31 05:32:38 2021 X-Original-To: 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 57A8BD7AC17 for ; Mon, 31 May 2021 05:32:44 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic316-8.consmr.mail.gq1.yahoo.com (sonic316-8.consmr.mail.gq1.yahoo.com [98.137.69.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4FtkT70n1jz3j45 for ; Mon, 31 May 2021 05:32:42 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1622439160; bh=qJSqK6M8WKfX9KrWik+TNcMihqXZike0ei6ei0Etyf4=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=UgU9i8NOyB5cNb+P3s/VQcqiXaYkjAFJA+XdcjZti4PAZd4NEZAAr7g0TaO2dLt7PAIy0zM2iMjJZLMhKiAUW/ACb/UgPJhB4yRfk8o23Ius5VLHRHAKeirTAxMlQA11VIZTUzl5/JNg4lLH8iE+KBPoClOQOnru4+5Xiwq5ejpt2mGT5ZkLdqyTJowLoVbrFMTBb9quaiYMiP7MpdyZd/U11z4x2ucduv+3JwsuljSjcx6iobe/D0VpGMlO6yRtIxEPwuvbKzQ1tc809GfFKaVwbENHgLmNo3XcO9zFj2SEARBM8sORR8d+vgpcuMml8/Z3RUQqv5zgn3lwZdCHTw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1622439160; bh=HllboPBbNw5w3nL9dlCVKIAm8vzcXi4to0NHjSS5sTN=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=WTTNqRUX96iMwQ8A8xq8+AmW9r1N7sAmcmDjYazMxfXiefAgNErGT0vJCw92EzM1WAI7aTnIvTmpF+YHIP+RAuXar4wvbhBP9yN/MqdtL4lKBt5WZS0vhHjbTKd7RWkjIZpEsbUnqmgYMWPfmPGFvKMXkoSDqtZjjHpfg/TKcyGclRlTW1CHtMLZYmJYXg13xCz4X4wzoIFJ0dd/d0IWkuI4A5iiEa21wN6lWjjAbBaljf//uGjfC2yM0e66+RZeMlU6C8u0npXaCZZQ5rGkvITtDRvht4+PmIw19fJRaQAR2gfgOpVAkq7uqVQy75/acP4Qu0Qp7jJGQo0LnUmuDw== X-YMail-OSG: dv.snioVM1kxeQ7p5zEcNdip4WuJuAqNFv67UTNjumFta.qGzPRnDWP3Q.PXq0H bvMQCp1nPLJ16UWwEcSNF7eXwN.89rKEPyDMD284hH3gJkb8uUVRHsnmY3fhdNl8vPZINanl.SKj tDFCPMjA5R9jx92zXqdxT0U7HVpaAdhTVQvMoyl.a7J3HVmGNjCRO8dhmEy.OlxDJDKQPlBJkBwB swBW530Hg_vuGIb6fJL.9eqh8IT5UzGxo7j_Dn1.hNW2dqQs_AYxMdpHEqPSKzcnqgbkyojZEG2F Q2rWEJGS2SN0MOLNVO.aJtP.nSChdtDytktX_dVi71qb1s9eXqMQ2.y5iO1fTELMVwceZMk6M3u6 1nqgshytGlBnoiByEjSs8_uNwtwMtLJT6ewXESBCHZTdg6_LvhwnwURNtd0QblTNJbbUlbMv17GA _G0ow5A4geE5PMJ7fu3HJsVtJPSt6.SmpON_RU.sJNB69y5x45lS0dmkm1c5wLuhOmakkq1OgUxa SUPX1USp3R.egVchX54YBRKnf6XC..qGXzF4PIiAvJh.vHRBCcIA9bLui2XDl7EXkP8WHNf01Ez3 .df1e2SN.7qBmgc1Rph6XhFGFRRVNfReppcsgxG739PCujhNo.Qddm9dFAG8K8itU_AazIsh0ltW AY.Abth_XgA1P9qOBf93S0nhWDL259LSrephojVOBERZBVUqVGuqX31fKXT3XEaqbv6n1dXu4GIw mn56DiHcROp80.ngc9SEeMCYMpTVF5ddxeffPwxD1ICXdNt7UiK2VDE8BhyaoznYbf_k1HNGIaQ6 iQrMmqdSDRf.EtUN4wAeM3z9nwTuXONkHiCjuHjYrkwWyQlyUqFA4TfXxP9g3tmsTnRNhEMdmGw2 yAok4w3FE.siLVSVTfZlisEDyqOLBiwg0FJQ42zpa6Dcg0HXcOpL9F5gPFS3sdHM9MEP9cBzqp50 TB6HuLLPqJdW1WtGD7Z24GRJurxHBgSF94tJYQrSdVk6TZDE1khbhExKHou9DgWuc.g44VIhojAo H92iO9VRyg0eGcNXy3sdQv6npShZE7cF9jd0LgYpZIJf1xUndf_aPZ6X67wU9WTUorCnE_3ap8HR IO3gxMGGBdYrKv54M.fjbD9f4zqEMRILO6sByqOjo_n827U0Jr4dMuKVUfTf4GDhem.a29O0YPvj tKoehvFkb7k9R9R1iSvQXEPAw6Nc0bKfQc7Nw56HTAdok9uGCCrObOWrfdHBAC8QCzd1nwmK2071 _xerZQXeZeMXXF63V6G3AQmTB5G2qxn20wpTeDJDIvz7Um9z.8veuygvKQvJG2XiSFN3yJFgq8ZE nJA7dwdJ2ueIsgDr5n23BZJiWifFO_jlnfN0j.XgYiSfBsF4uz9GDqbWDl7VP4JW2sTcHjKRGsvD kV.OPc1XVB5YuHYBjgMqG_miQlwBnCfGjmeNyf0PjbdBl5Du3AKgy7PvpRv5K.T1x3MNILOtM0Pz 6NOyizIRUb_QXnbeuBbwOGk1OpQT.yaUHfNFx.o_UL_BkwyUdYvssqC_ZtoNyiVn2OTEalP5iivD IoLFsZOZcoHhfJUi3_ixtJAGandVp3nIu7IJmvWr35ZLdL.OZof8PW.k6wWdi29c8Q27BVK9ctmx JrtR5JsxtaTTp14J7R1Oh0ZWeJ.SBRGGGybgWVhAvOi2GhoOA8Eb7lhv4j6qtI79FNnuAoKHVBAr SUbyzxO4dI_BsJc9MpTMEkdmVPKE5ymsag109f.qg18QNjxHWTM7XdvL23C1TO.iYeT45_4mnDbf 78pSp7fa2vJwDbUTifj.UklhTmzSYMXqEz43ka1mSKV9Rwjltva9pPXPnYEI7XGVVUZ1z8vCdxxo V4ULaWh0GoDaK4SPaeqeEGR6ZQdj3oFf1R9.QxW3Ln_o8g3c7hJ1kuzxRig7qHct7nSOFe5W_Kir zHR3JnnGZFtmfSHk0FXl4ZlAjxF1d5jXoScUORUJGZ4x8UUFXznRXBeoiQ9cqBbsvlHMTcXHv402 yFF9rbuHVavug5vKdM16Iu7OPIXq9Cw8inNymm3wZa4f7tDQ3aSQNppLodAgbhuHxNQclrXqtBzf PfOIdYe3JoYkST3DKdTX5Eim_Z5p6mSLALB_SBTePTxQZKMlVuIBkRM2cP9Uw_pi5HaBFQQF4U4s Y6aNzwcSiXkSafk.xufvdi86U2C4qW05DM6ID_goKRswBnDUJVczMbOXUf2e9AF54OjHvcySxABR vC0QXRHuzEeUwuTNtacf2WCBNkX.7Se6Gmys_LbLbrV6dJtuoM_6ZBo.Bi7lueyWw_v8BNND082d LrQGh5loeJ0cDmevKurxya.y0nf0MpzASfBifK0pg8XyPyNlcEkfj5QTTYL8.ZeDBZ8V7tg4oJr1 Os7X4GbOVuJiDO71Q9Iuy0qf13FnfCXb57e64vchwXdeMjvo9oo5ZkdRzwnwJE5mHdTp1ccd1RcQ 2UKoQzyG9MxWM6AmDFKQm6Cuo3XVu_9N837fNmBS8WPuZgDc4blQMTaAHMEaE2uCV24ASJI12dBd zMavfF7hcAoMe08F2.OCemar4IIhIeWoaI._DQb0B9Kc70My7JO63mFhb.JcXDZr03V3VgcsLcmw KdQkgedeawGD8SaWbcwuPTSk- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Mon, 31 May 2021 05:32:40 +0000 Received: by kubenode570.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID ab3ef4612edaa398ed8e241c1f2887b0; Mon, 31 May 2021 05:32:39 +0000 (UTC) Content-Type: text/plain; charset=us-ascii 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 (Mac OS X Mail 14.0 \(3654.80.0.2.43\)) Subject: Re: /usr/local/share/u-boot/u-boot-orangepi-plus-2e/README out of date ; orangepi-plus-2e and RPi2 v1.1 get "Kernel args: (null)" In-Reply-To: <5F226A9B-852D-4E72-9896-0509E56D3318@yahoo.com> Date: Sun, 30 May 2021 22:32:38 -0700 Cc: "freebsd-arm@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <30B373C0-4C73-4F3A-BDA6-E4CDC55E80C9@yahoo.com> References: <40298C05-5F50-4437-B15B-7A02EA070EAE.ref@yahoo.com> <40298C05-5F50-4437-B15B-7A02EA070EAE@yahoo.com> <20210513111517.86336633bae9568d8599f229@bidouilliste.com> <20210513124050.47714a83f876d67a80e28080@bidouilliste.com> <3C04FB55-4A26-48C8-833F-E4AC84DC4F78@yahoo.com> <99906599-273E-4216-A41E-DE642F33E392@yahoo.com> <0482F239-B137-42F5-8802-8883D08D5868@yahoo.com> <5F226A9B-852D-4E72-9896-0509E56D3318@yahoo.com> To: Emmanuel Vadot X-Mailer: Apple Mail (2.3654.80.0.2.43) X-Rspamd-Queue-Id: 4FtkT70n1jz3j45 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=UgU9i8NO; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.32 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[98.137.69.32:from]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; SPAMHAUS_ZRD(0.00)[98.137.69.32:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.32:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.32:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[arm] Reply-To: marklmi@yahoo.com From: Mark Millard via arm X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-May-30, at 22:27, Mark Millard wrote: > On 2021-May-24, at 20:10, Mark Millard wrote: >=20 >> On 2021-May-24, at 15:53, Mark Millard wrote: >>=20 >>> On 2021-May-13, at 12:03, Mark Millard wrote: >>>=20 >>>>>>> . . . >>>=20 >>> I do not know if the FreeBSD kernel has been depending >>> on some U-Boot initialization for root-on-USB and the >>> two no longer match or what. >>>=20 >>> But I've used a release/13.0.0.0 microsd card based >>> boot to get older U-Boot materials (Quarterly as it >>> turns out). Installing such got me back to having a >>> root-on-USB boot of the OPi+2e (other than the >>> mircosd card having the older U-Boot (2020.10 as it >>> turns out). Of course there is also the matching >>> boot.scr involved --but it also is on the USB SSD. >>> (Similarly reverted RPi2 U-Boot, other than needing >>> to switch boot.scr to match.) >>>=20 >>> After booting with the reverted U-Boot related >>> material: >>>=20 >>> # mount -onoatime -tmsdosfs /dev/mmcsd1s1 /mnt >>> # mount -onoatime /dev/mmcsd1s2a /media >>>=20 >>> # ls -Tla /mnt/ >>> total 20 >>> drwxr-xr-x 1 root wheel 16384 Dec 31 16:00:00 1979 . >>> drwxr-xr-x 25 root wheel 512 Dec 31 16:00:40 2009 .. >>>=20 >>> # ls -Tla /media/ >>> total 60 >>> drwxr-xr-x 2 root wheel 512 May 24 15:43:19 2021 . >>> drwxr-xr-x 25 root wheel 512 Dec 31 16:00:40 2009 .. >>> -rwxr-xr-x 1 root wheel 52456 Apr 24 19:48:36 2021 bootcode.bin >>>=20 >>> The media is also set up for booting an RPi2 via >>> root-in-USB ( other than bootcode.bin ). >>>=20 >>> If FreeBSD and the more modern U-Boot were well matched >>> for USB support, I'd expect that this sort of thing would >>> work (no boot.scr needed). >>>=20 >>> For reference: >>>=20 >>> # ~/fbsd-based-on-what-freebsd-main.sh=20 >>> FreeBSD OPiP2E_RPi2v11 14.0-CURRENT FreeBSD 14.0-CURRENT = mm-src-n245445-def0058cc690 GENERIC-NODBG arm armv7 1400005 1400005 >>> def0058cc690 (HEAD -> mm-src) mm-src snapshot for mm's patched build = in git context. >>> merge-base: 7381bbee29df959e88ec59866cf2878263e7f3b2 >>> merge-base: CommitDate: 2021-03-12 20:29:42 +0000 >>> 7381bbee29df (freebsd/main, freebsd/HEAD, pure-src, main) cam: Run = all XPT_ASYNC ccbs in a dedicated thread >>> n245444 (--first-parent --count for merge-base) >>=20 >> Looks like 2021.04 (even before 2021.04_1) also has the >> problem for root-on-USB handling. >>=20 >> I managed to find a 2021-Apr-09 u-boot-orangepi-plus-2e >> directory copy that was 2021.04 (and its boot.scr) but >> before the UEFI change. When I tried it for the >> root-on-USB context I still got the hangup after "Kernel >> args: (null)" in: >>=20 >> . . . >> Hit [Enter] to boot immediately, or any other key for command prompt. >> Booting [/boot/kernel/kernel]... =20 >> Using DTB provided by EFI at 0x47eea000. >> Kernel entry at 0xb2e00200... >> Kernel args: (null) >>=20 >>=20 >> So it does not appear to be the UEFI change so much as >> 2021.04 in general for which the FreeBSD kernel and >> the U-Boot are apparently(?) mismatched for root-on-USB. >>=20 >>=20 >> Reverting again to 2020.10 U-Boot got back the root-on-USB >> status. For this the boot looks like: >>=20 >> . . . >> Hit [Enter] to boot immediately, or any other key for command prompt. >> Booting [/boot/kernel/kernel]... =20 >> Using DTB provided by EFI at 0x47ef5000. >> Kernel entry at 0xb2e00200... >> Kernel args: (null) >> ---<>--- >> KDB: debugger backends: ddb >> KDB: current backend: ddb >> Copyright (c) 1992-2021 The FreeBSD Project. >> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, = 1994 >> The Regents of the University of California. All rights = reserved. >> FreeBSD is a registered trademark of The FreeBSD Foundation. >> FreeBSD 14.0-CURRENT mm-src-n245445-def0058cc690 GENERIC-NODBG arm >> FreeBSD clang version 11.0.1 (git@github.com:llvm/llvm-project.git = llvmorg-11.0.1-0-g43ff75f2c3fe) >> . . . >>=20 >=20 > Well, I got a surprise in exploring: removing boot.scr > and ubldr.bin did not prevent booting. (Noticed by the > accident of ending up with one of them missing that I > only later noticed.) So I recorded a boot and: >=20 > . . . > U-Boot SPL 2020.10 (Apr 19 2021 - 18:04:31 +0000) > DRAM: 2048 MiB > Trying to boot from MMC1 >=20 >=20 > U-Boot 2020.10 (Apr 19 2021 - 18:04:31 +0000) Allwinner Technology >=20 > CPU: Allwinner H3 (SUN8I 1680) > Model: Xunlong Orange Pi Plus 2E > DRAM: 2 GiB > . . . > Device 0: Vendor: OWC Rev: 0 Prod: Envoy Pro mini =20 > Type: Hard Disk > Capacity: 228936.5 MB =3D 223.5 GB (468862128 x 512) > ... is now current device > Scanning usb 0:4... > 30675 bytes read in 3 ms (9.8 MiB/s) > Found EFI removable media binary efi/boot/bootarm.efi > . . . > Booting /efi\boot\bootarm.efi > Consoles: EFI console =20 >=20 >=20 > |=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08 Reading loader env vars from = /efi/freebsd/loader.env >=20 >=20 > Setting currdev to disk2p4: >=20 >=20 > |=08/=08-=08\=08|=08/=08FreeBSD/arm EFI loader, Revision 1.1 > . . . >=20 > So I've likely been been booting via UEFI for > some time via 2020.10 (or even before?), just > without noticing at the time. >=20 > The other implication is likely that what disabled > root-on-USB for my context was not the boot.scr > removal material but some (possibly proper) subset > of other material changed (extracted from > ports' main 0d6e5081eb00 commit cgit display): Nope: I forgot that I've tried 2021.04 from before the UEFI changes referenced, and also had the problem for that context. Still it is interesting that I'm getting a UEFI boot context from 2020.10 . > . . . >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Mon May 31 12:33:57 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 76DF3BFDFD3; Mon, 31 May 2021 12:34:07 +0000 (UTC) (envelope-from dsl@mcusim.org) Received: from mcusim.org (mcusim.org [176.58.93.53]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4FtvqL2zWMz4jpL; Mon, 31 May 2021 12:34:06 +0000 (UTC) (envelope-from dsl@mcusim.org) Received: from x230.ds (unknown [83.28.234.19]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mcusim.org (Postfix) with ESMTPSA id 5E02876478; Mon, 31 May 2021 14:33:59 +0200 (CEST) Date: Mon, 31 May 2021 14:33:57 +0200 From: Dmitry Salychev To: freebsd-arm@freebsd.org Cc: freebsd-hackers@freebsd.org Subject: U-Boot for HoneyComb LX2 Message-ID: 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 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Rspamd-Queue-Id: 4FtvqL2zWMz4jpL X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=reject) header.from=mcusim.org; spf=pass (mx1.freebsd.org: domain of dsl@mcusim.org designates 176.58.93.53 as permitted sender) smtp.mailfrom=dsl@mcusim.org X-Spamd-Result: default: False [-1.80 / 15.00]; RCVD_TLS_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[176.58.93.53:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+a]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_SPAM_SHORT(1.00)[1.000]; SPAMHAUS_ZRD(0.00)[176.58.93.53:from:127.0.2.255]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[mcusim.org,reject]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:36236, ipnet:176.58.93.0/24, country:US]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arm,freebsd-hackers]; RECEIVED_SPAMHAUS_PBL(0.00)[83.28.234.19:received] X-Spam: Yes X-ThisMailContainsUnwantedMimeParts: N Hi, I'm working on three ports to compile BL2, BL31, BL32 and BL33 (u-boot) bootloaders for HoneyComb LX2 in FreeBSD. They're based on what NXP shared in their Layerscape SDK and patches from SolidRun [1]. I've managed to compile Reset Configuration Word (rcw), u-boot and ARM trusted firmware (atf) and write them to one of the existing images shared by SolidRun [2]. However, my HoneyComb LX2 is on a way to me and this is why I cannot try to boot the resulted image on my own. I'm really interested how far it'll go, but I don't expect anything beyond u-boot. Could somebody who has HoneyComb do me a favor and try to boot that image of mine? It should work with DDR4-3200 only: ftp://mcusim.org/ftp/lx2160acex7_2000_700_3200_8_5_2-2fff64e_changed_bld.img.xz If you want to take a look at the sysutils/rcw-lx2160acex7, sysutils/u-boot-lx2160acex7 and sysutils/atf-lx2160acex7, here is the link: https://github.com/mcusim/freebsd-ports Thanks in advance. Regards, Dmitry [1] https://github.com/SolidRun/lx2160a_build [2] https://images.solid-run.com/LX2k/lx2160a_build/ From nobody Mon May 31 13:22:57 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 037F5C78A36; Mon, 31 May 2021 13:23:10 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (cross.sbone.de [195.201.62.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Ftwvx63rJz4nMQ; Mon, 31 May 2021 13:23:09 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id C3ED38D4A172; Mon, 31 May 2021 13:23:01 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 8C566E707C2; Mon, 31 May 2021 13:23:00 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id f8aD0Q7H0FMw; Mon, 31 May 2021 13:22:59 +0000 (UTC) Received: from [192.168.2.110] (unknown [IPv6:fde9:577b:c1a9:31:3c8a:b6b3:7bcf:6aac]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 1F9F0E707B9; Mon, 31 May 2021 13:22:58 +0000 (UTC) From: "Bjoern A. Zeeb" To: "Dmitry Salychev" Cc: freebsd-arm@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: U-Boot for HoneyComb LX2 Date: Mon, 31 May 2021 13:22:57 +0000 X-Mailer: MailMate (2.0BETAr6151) Message-ID: <198F84BF-5932-4E58-BCE3-CC33B185923A@lists.zabbadoz.net> In-Reply-To: References: 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 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4Ftwvx63rJz4nMQ X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On 31 May 2021, at 12:33, Dmitry Salychev wrote: Hi, > I'm working on three ports to compile BL2, BL31, BL32 and BL33 = > (u-boot) > bootloaders for HoneyComb LX2 in FreeBSD. They're based on what NXP = > shared in > their Layerscape SDK and patches from SolidRun [1]. > > I've managed to compile Reset Configuration Word (rcw), u-boot and ARM = > trusted > firmware (atf) and write them to one of the existing images shared by > SolidRun [2]. > > However, my HoneyComb LX2 is on a way to me and this is why I cannot = > try to > boot the resulted image on my own. I'm really interested how far it'll = > go, but > I don't expect anything beyond u-boot. Could somebody who has = > HoneyComb do me > a favor and try to boot that image of mine? It should work with = > DDR4-3200 > only: > > ftp://mcusim.org/ftp/lx2160acex7_2000_700_3200_8_5_2-2fff64e_changed_b= ld.img.xz > > If you want to take a look at the sysutils/rcw-lx2160acex7, > sysutils/u-boot-lx2160acex7 and sysutils/atf-lx2160acex7, here is the = > link: > > https://github.com/mcusim/freebsd-ports That=E2=80=99s great news! I might give it a try. I=E2=80=99ve got a local tree (on Jan 2021, needs updating to latest and = re-test before submit) for the uEFI firmware (not u-boot). /bz From nobody Mon May 31 13:40:16 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 5F5F7C7A80B; Mon, 31 May 2021 13:40:20 +0000 (UTC) (envelope-from dsl@mcusim.org) Received: from mcusim.org (mcusim.org [176.58.93.53]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4FtxHm1nHcz4qnR; Mon, 31 May 2021 13:40:19 +0000 (UTC) (envelope-from dsl@mcusim.org) Received: from x230.ds (unknown [83.28.234.19]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mcusim.org (Postfix) with ESMTPSA id 3F8DA76771; Mon, 31 May 2021 15:40:18 +0200 (CEST) Date: Mon, 31 May 2021 15:40:16 +0200 From: Dmitry Salychev To: "Bjoern A. Zeeb" Cc: freebsd-arm@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: U-Boot for HoneyComb LX2 Message-ID: References: <198F84BF-5932-4E58-BCE3-CC33B185923A@lists.zabbadoz.net> 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 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <198F84BF-5932-4E58-BCE3-CC33B185923A@lists.zabbadoz.net> X-Rspamd-Queue-Id: 4FtxHm1nHcz4qnR X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-Spam: Yes X-ThisMailContainsUnwantedMimeParts: N Bjoern, On Mon, May 31, 2021 at 01:22:57PM +0000, Bjoern A. Zeeb wrote: > On 31 May 2021, at 12:33, Dmitry Salychev wrote: > > Hi, > > > I'm working on three ports to compile BL2, BL31, BL32 and BL33 > > (u-boot) > > bootloaders for HoneyComb LX2 in FreeBSD. They're based on what NXP > > shared in > > their Layerscape SDK and patches from SolidRun [1]. > > > > I've managed to compile Reset Configuration Word (rcw), u-boot and ARM > > trusted > > firmware (atf) and write them to one of the existing images shared by > > SolidRun [2]. > > > > However, my HoneyComb LX2 is on a way to me and this is why I cannot > > try to > > boot the resulted image on my own. I'm really interested how far it'll > > go, but > > I don't expect anything beyond u-boot. Could somebody who has > > HoneyComb do me > > a favor and try to boot that image of mine? It should work with > > DDR4-3200 > > only: > > > > ftp://mcusim.org/ftp/lx2160acex7_2000_700_3200_8_5_2-2fff64e_changed_bld.img.xz > > > > If you want to take a look at the sysutils/rcw-lx2160acex7, > > sysutils/u-boot-lx2160acex7 and sysutils/atf-lx2160acex7, here is the > > link: > > > > https://github.com/mcusim/freebsd-ports > > That’s great news! I might give it a try. > > I’ve got a local tree (on Jan 2021, needs updating to latest and > re-test before > submit) for the uEFI firmware (not u-boot). > > /bz You could try to boot SolidRun's own from SD card first: lx2160acex7_2000_700_3200_8_5_2-2fff64e.img.xz and see how it'll work and mine after. I wonder whether there'll be any difference or not. Regards, Dmitry From nobody Mon May 31 20:43:23 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 2BBF4C7D425 for ; Mon, 31 May 2021 20:43:27 +0000 (UTC) (envelope-from jfc@mit.edu) Received: from outgoing-exchange-1.mit.edu (outgoing-exchange-1.mit.edu [18.9.28.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.outgoing-exchange.mit.edu", Issuer "InCommon RSA Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Fv6gy1Szqz3D0J for ; Mon, 31 May 2021 20:43:25 +0000 (UTC) (envelope-from jfc@mit.edu) Received: from oc11exedge2.exchange.mit.edu (OC11EXEDGE2.EXCHANGE.MIT.EDU [18.9.3.18]) by outgoing-exchange-1.mit.edu (8.14.7/8.12.4) with ESMTP id 14VKhNJ0027034 for ; Mon, 31 May 2021 16:43:24 -0400 Received: from OC11EXPO29.exchange.mit.edu (18.9.4.102) by oc11exedge2.exchange.mit.edu (18.9.3.18) with Microsoft SMTP Server (TLS) id 15.0.1497.18; Mon, 31 May 2021 16:43:02 -0400 Received: from OC11EXPO29.exchange.mit.edu (18.9.4.102) by oc11expo29.exchange.mit.edu (18.9.4.102) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 31 May 2021 16:43:23 -0400 Received: from OC11EXPO29.exchange.mit.edu ([18.9.4.102]) by oc11expo29.exchange.mit.edu ([18.9.4.102]) with mapi id 15.00.1497.015; Mon, 31 May 2021 16:43:23 -0400 From: John F Carr To: freebsd-arm Subject: Status of wireless driver development for Raspberry Pi? Thread-Topic: Status of wireless driver development for Raspberry Pi? Thread-Index: AQHXVl2ZZ0BqZ27RMk23ojwIPMgBSw== Date: Mon, 31 May 2021 20:43:23 +0000 Message-ID: <94AF68C7-3E9A-4686-AA20-DC592C84A2FD@exchange.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [108.7.221.50] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable 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 X-Rspamd-Queue-Id: 4Fv6gy1Szqz3D0J X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of jfc@mit.edu designates 18.9.28.15 as permitted sender) smtp.mailfrom=jfc@mit.edu X-Spamd-Result: default: False [-2.48 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_FIVE(0.00)[5]; HAS_XOIP(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:18.9.28.0/24]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; DMARC_NA(0.00)[mit.edu]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; TO_DN_ALL(0.00)[]; RCVD_IN_DNSWL_MED(-0.20)[18.9.28.15:from]; NEURAL_HAM_SHORT(-0.98)[-0.982]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:3, ipnet:18.9.0.0/16, country:US]; SUBJECT_ENDS_QUESTION(1.00)[]; MAILMAN_DEST(0.00)[freebsd-arm] X-ThisMailContainsUnwantedMimeParts: N According to a page that hasn't been updated for a while (https://wiki.free= bsd.org/SDIO) work is in progress on Broadcom wireless drivers for the Rasp= berry Pi 3 and 4. I'm supposed to start by building the GENERIC-MMCCAM ker= nel. A CAM device will then appear which I can then use camcontrol to talk= to. I built the kernel and booted it on my Pi 3B+, which has a Broadcom = 43455/6 according to Linux. All camcontrol finds is the mini SD card. I s= ee only one call to sdhci_init_slot in bcm2835_sdhost.c so maybe that's the= problem. It supports exactly one SDIO device, a memory card. Any thoughts? Is it worth thinking about the wireless chip or is it just t= oo much work? # camcontrol devlist at scbus0 target 0 lun 0 (pass0,= sdda0) # camcontrol devlist -v scbus0 on sdhci_slot0 bus 0: at scbus0 target 0 lun 0 (pass0,= sdda0) scbus-1 on xpt0 bus 0: <> at scbus-1 target -1 lun ffffffff (xpt0) From nobody Tue Jun 1 03:09:29 2021 X-Original-To: freebsd-arm@freebsd.org Received: from mlmmj.nyi.freebsd.org (unknown [127.0.1.24]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 30620DFE7FB for ; Tue, 1 Jun 2021 03:09:29 +0000 (UTC) (envelope-from freebsd-arm+bounces-help@FreeBSD.org) Subject: =?utf-8?q?Unable_to_unsubscribe_from_freebsd-arm=40FreeBSD.org?= From: freebsd-arm+help@FreeBSD.org To: freebsd-arm@freebsd.org Message-ID: <1622516969-3182-mlmmj-3d6d1e23@FreeBSD.org> Date: Tue, 01 Jun 2021 03:09:29 +0000 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 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-ThisMailContainsUnwantedMimeParts: N Hi, this is the Mlmmj program managing the mailing list. You were unable to be unsubscribed from the list because you are not subscribed. If you are receiving messages, perhaps a different email address is subscribed. To find out which address you are subscribed with, refer to the message welcoming you to the list, or look at the envelope "Return-Path" header of a message you receive from the list. From nobody Tue Jun 1 07:18:22 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 8D37FBFE817 for ; Tue, 1 Jun 2021 07:18:22 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4FvNmZ36KYz3lGf for ; Tue, 1 Jun 2021 07:18:22 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4BCF51EF50 for ; Tue, 1 Jun 2021 07:18:22 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 1517IMEH034080 for ; Tue, 1 Jun 2021 07:18:22 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 1517IMeA034079 for freebsd-arm@FreeBSD.org; Tue, 1 Jun 2021 07:18:22 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 244491] Patch for RockPro64 4GB ram detection Date: Tue, 01 Jun 2021 07:18:22 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: phk@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: Overcome By Events X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status resolution Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated 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 X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D244491 Poul-Henning Kamp changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |Closed Resolution|--- |Overcome By Events --- Comment #1 from Poul-Henning Kamp --- Seems to have been fixed upstream. --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Tue Jun 1 13:06:40 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 AA87FE76521 for ; Tue, 1 Jun 2021 13:06:40 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4FvXVS4K7Bz3DBl for ; Tue, 1 Jun 2021 13:06:40 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 7710824214 for ; Tue, 1 Jun 2021 13:06:40 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 151D6eDC018853 for ; Tue, 1 Jun 2021 13:06:40 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 151D6eXA018852 for freebsd-arm@FreeBSD.org; Tue, 1 Jun 2021 13:06:40 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 256334] [genet] Race condition in Pi4's gen_attach() can cause SIGSEGV. Date: Tue, 01 Jun 2021 13:06:40 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: ghuckriede@blackberry.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated 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 X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D256334 Bug ID: 256334 Summary: [genet] Race condition in Pi4's gen_attach() can cause SIGSEGV. Product: Base System Version: CURRENT Hardware: arm64 OS: Any Status: New Severity: Affects Only Me Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: ghuckriede@blackberry.com 'genet' driver starts interrupt handlers before ifp is allocated. Version: git main @ d3f7975fcb346ea28dde079a9c04cff5ef20a8d7 gen_intr() uses sc->ifp here: https://cgit.freebsd.org/src/blame/sys/arm64/broadcom/genet/if_genet.c#n1260 gen_attach() calls bus_setup_intr() here: https://cgit.freebsd.org/src/blame/sys/arm64/broadcom/genet/if_genet.c#n283 https://cgit.freebsd.org/src/blame/sys/arm64/broadcom/genet/if_genet.c#n290 gen_attach() calls if_alloc() here: https://cgit.freebsd.org/src/blame/sys/arm64/broadcom/genet/if_genet.c#n298 Possible fixes: gen_attach() could either hold GEN_LOCK() or complete the init before the bus_setup_intr() calls. --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Wed Jun 2 09:01:13 2021 X-Original-To: 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 B6752EA9A4B for ; Wed, 2 Jun 2021 09:01:17 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mx.blih.net (mx.blih.net [212.83.155.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mx.blih.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Fw30r1Xs4z4ftw for ; Wed, 2 Jun 2021 09:01:15 +0000 (UTC) (envelope-from manu@bidouilliste.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bidouilliste.com; s=mx; t=1622624473; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=GKdwDDEwWUDP78tMlIH34OcYXkb+Shc/NOzFzdKYA8I=; b=d3pPAO/nhfYBKx1pKXZ65SXu9A0ocoF13TzQfVANSsSEkMHZ1fje4T7BChLk8xjGSG8pX+ xmHFnSVfgnVhXhtSidaoUS58LRYl5kR38ivty1aVNZzDiZ5patTTFPwCPGx9VTZfpdlJ5L QvFG6IgGhegoGfZtlXetwvlhvJ1DZTU= Received: from skull.home.blih.net (lfbn-idf2-1-644-4.w86-247.abo.wanadoo.fr [86.247.100.4]) by mx.blih.net (OpenSMTPD) with ESMTPSA id 0f992fd8 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Wed, 2 Jun 2021 09:01:13 +0000 (UTC) Date: Wed, 2 Jun 2021 11:01:13 +0200 From: Emmanuel Vadot To: marklmi@yahoo.com Cc: Mark Millard via arm Subject: Re: /usr/local/share/u-boot/u-boot-orangepi-plus-2e/README out of date ; orangepi-plus-2e and RPi2 v1.1 get "Kernel args: (null)" Message-Id: <20210602110113.a92bf9beb5cd9f736934e62b@bidouilliste.com> In-Reply-To: <30B373C0-4C73-4F3A-BDA6-E4CDC55E80C9@yahoo.com> References: <40298C05-5F50-4437-B15B-7A02EA070EAE.ref@yahoo.com> <40298C05-5F50-4437-B15B-7A02EA070EAE@yahoo.com> <20210513111517.86336633bae9568d8599f229@bidouilliste.com> <20210513124050.47714a83f876d67a80e28080@bidouilliste.com> <3C04FB55-4A26-48C8-833F-E4AC84DC4F78@yahoo.com> <99906599-273E-4216-A41E-DE642F33E392@yahoo.com> <0482F239-B137-42F5-8802-8883D08D5868@yahoo.com> <5F226A9B-852D-4E72-9896-0509E56D3318@yahoo.com> <30B373C0-4C73-4F3A-BDA6-E4CDC55E80C9@yahoo.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) 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 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4Fw30r1Xs4z4ftw X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bidouilliste.com header.s=mx header.b=d3pPAO/n; dmarc=pass (policy=none) header.from=bidouilliste.com; spf=pass (mx1.freebsd.org: domain of manu@bidouilliste.com designates 212.83.155.74 as permitted sender) smtp.mailfrom=manu@bidouilliste.com X-Spamd-Result: default: False [-1.66 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+mx]; DKIM_TRACE(0.00)[bidouilliste.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[bidouilliste.com,none]; FREEMAIL_TO(0.00)[yahoo.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[212.83.155.74:from]; ASN(0.00)[asn:12876, ipnet:212.83.128.0/19, country:FR]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[bidouilliste.com:s=mx]; FREEFALL_USER(0.00)[manu]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.84)[0.841]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; SPAMHAUS_ZRD(0.00)[212.83.155.74:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[arm] X-ThisMailContainsUnwantedMimeParts: N On Sun, 30 May 2021 22:32:38 -0700 Mark Millard via arm wrote: > On 2021-May-30, at 22:27, Mark Millard wrote: >=20 > > On 2021-May-24, at 20:10, Mark Millard wrote: > >=20 > >> On 2021-May-24, at 15:53, Mark Millard wrote: > >>=20 > >>> On 2021-May-13, at 12:03, Mark Millard wrote: > >>>=20 > >>>>>>> . . . > >>>=20 > >>> I do not know if the FreeBSD kernel has been depending > >>> on some U-Boot initialization for root-on-USB and the > >>> two no longer match or what. > >>>=20 > >>> But I've used a release/13.0.0.0 microsd card based > >>> boot to get older U-Boot materials (Quarterly as it > >>> turns out). Installing such got me back to having a > >>> root-on-USB boot of the OPi+2e (other than the > >>> mircosd card having the older U-Boot (2020.10 as it > >>> turns out). Of course there is also the matching > >>> boot.scr involved --but it also is on the USB SSD. > >>> (Similarly reverted RPi2 U-Boot, other than needing > >>> to switch boot.scr to match.) > >>>=20 > >>> After booting with the reverted U-Boot related > >>> material: > >>>=20 > >>> # mount -onoatime -tmsdosfs /dev/mmcsd1s1 /mnt > >>> # mount -onoatime /dev/mmcsd1s2a /media > >>>=20 > >>> # ls -Tla /mnt/ > >>> total 20 > >>> drwxr-xr-x 1 root wheel 16384 Dec 31 16:00:00 1979 . > >>> drwxr-xr-x 25 root wheel 512 Dec 31 16:00:40 2009 .. > >>>=20 > >>> # ls -Tla /media/ > >>> total 60 > >>> drwxr-xr-x 2 root wheel 512 May 24 15:43:19 2021 . > >>> drwxr-xr-x 25 root wheel 512 Dec 31 16:00:40 2009 .. > >>> -rwxr-xr-x 1 root wheel 52456 Apr 24 19:48:36 2021 bootcode.bin > >>>=20 > >>> The media is also set up for booting an RPi2 via > >>> root-in-USB ( other than bootcode.bin ). > >>>=20 > >>> If FreeBSD and the more modern U-Boot were well matched > >>> for USB support, I'd expect that this sort of thing would > >>> work (no boot.scr needed). > >>>=20 > >>> For reference: > >>>=20 > >>> # ~/fbsd-based-on-what-freebsd-main.sh=20 > >>> FreeBSD OPiP2E_RPi2v11 14.0-CURRENT FreeBSD 14.0-CURRENT mm-src-n2454= 45-def0058cc690 GENERIC-NODBG arm armv7 1400005 1400005 > >>> def0058cc690 (HEAD -> mm-src) mm-src snapshot for mm's patched build = in git context. > >>> merge-base: 7381bbee29df959e88ec59866cf2878263e7f3b2 > >>> merge-base: CommitDate: 2021-03-12 20:29:42 +0000 > >>> 7381bbee29df (freebsd/main, freebsd/HEAD, pure-src, main) cam: Run al= l XPT_ASYNC ccbs in a dedicated thread > >>> n245444 (--first-parent --count for merge-base) > >>=20 > >> Looks like 2021.04 (even before 2021.04_1) also has the > >> problem for root-on-USB handling. > >>=20 > >> I managed to find a 2021-Apr-09 u-boot-orangepi-plus-2e > >> directory copy that was 2021.04 (and its boot.scr) but > >> before the UEFI change. When I tried it for the > >> root-on-USB context I still got the hangup after "Kernel > >> args: (null)" in: > >>=20 > >> . . . > >> Hit [Enter] to boot immediately, or any other key for command prompt. > >> Booting [/boot/kernel/kernel]... =20 > >> Using DTB provided by EFI at 0x47eea000. > >> Kernel entry at 0xb2e00200... > >> Kernel args: (null) > >>=20 > >>=20 > >> So it does not appear to be the UEFI change so much as > >> 2021.04 in general for which the FreeBSD kernel and > >> the U-Boot are apparently(?) mismatched for root-on-USB. > >>=20 > >>=20 > >> Reverting again to 2020.10 U-Boot got back the root-on-USB > >> status. For this the boot looks like: > >>=20 > >> . . . > >> Hit [Enter] to boot immediately, or any other key for command prompt. > >> Booting [/boot/kernel/kernel]... =20 > >> Using DTB provided by EFI at 0x47ef5000. > >> Kernel entry at 0xb2e00200... > >> Kernel args: (null) > >> ---<>--- > >> KDB: debugger backends: ddb > >> KDB: current backend: ddb > >> Copyright (c) 1992-2021 The FreeBSD Project. > >> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 19= 94 > >> The Regents of the University of California. All rights reserved. > >> FreeBSD is a registered trademark of The FreeBSD Foundation. > >> FreeBSD 14.0-CURRENT mm-src-n245445-def0058cc690 GENERIC-NODBG arm > >> FreeBSD clang version 11.0.1 (git@github.com:llvm/llvm-project.git llv= morg-11.0.1-0-g43ff75f2c3fe) > >> . . . > >>=20 > >=20 > > Well, I got a surprise in exploring: removing boot.scr > > and ubldr.bin did not prevent booting. (Noticed by the > > accident of ending up with one of them missing that I > > only later noticed.) So I recorded a boot and: > >=20 > > . . . > > U-Boot SPL 2020.10 (Apr 19 2021 - 18:04:31 +0000) > > DRAM: 2048 MiB > > Trying to boot from MMC1 > >=20 > >=20 > > U-Boot 2020.10 (Apr 19 2021 - 18:04:31 +0000) Allwinner Technology > >=20 > > CPU: Allwinner H3 (SUN8I 1680) > > Model: Xunlong Orange Pi Plus 2E > > DRAM: 2 GiB > > . . . > > Device 0: Vendor: OWC Rev: 0 Prod: Envoy Pro mini =20 > > Type: Hard Disk > > Capacity: 228936.5 MB =3D 223.5 GB (468862128 x 512) > > ... is now current device > > Scanning usb 0:4... > > 30675 bytes read in 3 ms (9.8 MiB/s) > > Found EFI removable media binary efi/boot/bootarm.efi > > . . . > > Booting /efi\boot\bootarm.efi > > Consoles: EFI console =20 > >=20 > >=20 > > |=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/= =08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08 Reading loader env vars from= /efi/freebsd/loader.env > >=20 > >=20 > > Setting currdev to disk2p4: > >=20 > >=20 > > |=08/=08-=08\=08|=08/=08FreeBSD/arm EFI loader, Revision 1.1 > > . . . > >=20 > > So I've likely been been booting via UEFI for > > some time via 2020.10 (or even before?), just > > without noticing at the time. > >=20 > > The other implication is likely that what disabled > > root-on-USB for my context was not the boot.scr > > removal material but some (possibly proper) subset > > of other material changed (extracted from > > ports' main 0d6e5081eb00 commit cgit display): >=20 > Nope: I forgot that I've tried 2021.04 from before > the UEFI changes referenced, and also had the > problem for that context. 2021.04 cannot work on armv7, caches weren't cleared. > Still it is interesting that I'm getting a UEFI > boot context from 2020.10 . The only thing I can suggest is git bisect on u-boot repo and see if you have any result. > > . . . > >=20 >=20 >=20 > =3D=3D=3D > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) >=20 >=20 --=20 Emmanuel Vadot From nobody Wed Jun 2 09:17:43 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 E1803EAA6C5 for ; Wed, 2 Jun 2021 09:17:43 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Fw3Mq5vbtz4h7w for ; Wed, 2 Jun 2021 09:17:43 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id B30541444D for ; Wed, 2 Jun 2021 09:17:43 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 1529Hh9d059264 for ; Wed, 2 Jun 2021 09:17:43 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 1529Hha6059263 for freebsd-arm@FreeBSD.org; Wed, 2 Jun 2021 09:17:43 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 256372] gpioctl fails to set input pull-up condition properly Date: Wed, 02 Jun 2021 09:17:43 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 13.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: paul.r.rzonca@gmail.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated 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 X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D256372 Bug ID: 256372 Summary: gpioctl fails to set input pull-up condition properly Product: Base System Version: 13.0-RELEASE Hardware: arm64 OS: Any Status: New Severity: Affects Only Me Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: paul.r.rzonca@gmail.com load SD card image on either a RPi4 or Pi 400 pick a GPIO pin e.g. 24 enter the following as root; #gpioctl -l | grep 24 */you will see the status of pin 24 usually defaults as an put with val= ue 0 */pin 24: 0 24 */Let's set this input as Pulled-Up=20 #gpioctl -c 24 IN PU #gpioctl -l | grep 24 */you will see the configuration change to=20 */pin 24: 0 24 */but the pin value of 0 should be 1 now, since it has been pulled-up I verified that this is exclusive to the RPi 4 family only. Tested on a RPi= 3B+ and it works properly. Lastly, these are all certified Raspberry Pi products not knock-offs. --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Wed Jun 2 10:40:03 2021 X-Original-To: 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 A559DEAEDB3 for ; Wed, 2 Jun 2021 10:40:09 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic314-19.consmr.mail.gq1.yahoo.com (sonic314-19.consmr.mail.gq1.yahoo.com [98.137.69.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Fw5Bx1YLwz4mrZ for ; Wed, 2 Jun 2021 10:40:08 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1622630407; bh=cEMdlkNIKnS/A2ESX+jCCnufAW2HwF0uCUM8F/j0DYM=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=a1QaX29PQv2Bd4Pxcr53kH3WM9EVn/LXqC3Jw7pjty6Jy5F+H/2LN4SxrO6AV/wLpTYU6vGPx4b/CYwhH/3jQGW+ewpmugyyFXD8BNqhxiMp5SwU74ygWJGM47Q4ob/nUBKwjUmcOh9OeBq45bpKbqIX+EqgdSeI7aQQ3/5ko3YdrVcm8irqqw46k3k2Oo2G6twj+bkxMkZzYPSHX42SKkwmOx0cMeszcxuNlDsGXywZd3GHdQeeVi9J38Z0ntaSYo/x6v5za12jXpV5t9F9wYGarD2sUzQZNPXQ4AQZyl+v/b6eWa3s8ifVbTCdwir63HFJD2jOLa1IQ0fHlnU7hQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1622630407; bh=zl2lMSt9GlRnKkujfhwAj02nOf7G30XRJqTs4FZ3L7k=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=i4/VcCEZenYrSOg3ooSYxCQsK487HULKn5UGk8MlKN2s3fI/nhrc0URAUsaSLbSVzHvdsloW2b9w2EV6wUUIstbmhrTgGq2FQf/mD03ScBU8V3Pib21lYQFGLbauk+3/e7ALMb/pTbFrwp2T7wPlfbxUYdiVVdksw4D/0FpTvKbB22OC+iKfh+aDh0C/LJ2w/+25bdtWAt7QLOLAciDyRtZF0KT1HMOmULD2PK8nFKl1A92L4ROSVlBigdD7A9WbU43LYTZMXUUp8qRIC6MX9Y3cumfhXcxrJptf2CDjBS4mvHxSkcUTnSRt2iPlS6lOjBMsUuEwsAp2z8pS2jMCdA== X-YMail-OSG: PYRBaMMVM1n3_SOAKGEZmGk0Yg30_WbbV1w8lhpE9tR6fGLtbC7pNgMiY7kkBGD NweoRpf9kQHtIcmoQI4U9ypNyybUmu1k40N4PJUze3t0SuzmI5z3vv6n0cKEsD3prnAP8bbgelHy XUCT8S5y5lMYoMZ6KFO_qZs5n1dEjNeAtITXILnIRP5Hf_QU2VJwmgrEbzZJEPFLN5rFobSxltG6 OlttQ313NTXwNONpaGtqKRJM85nrBaox6LvoE9q_jldEwPuI1CsszgTFxfMj3OgWPlYgKXBNSS1Q Zehd7x7yLNbmAAIuJIBMvYhhclS6GihuVh9jG1eIZr9C2T1V9PLFM31kg9jtMqfldPI1pAgQnsss Zi348xvrAk8T6JJFm5gd9idhuz5tavqnw24iJrGIPfNUq9a7T4Q.hVLs6dO.0v08tKYNiL7ctW4X u8plfBiAW53W7IZsKp0.0LQfKBy5sOWjrHImhFxCJSW5x_7ChsOujHSl_hgyN0NWgFYexXOLlxyf YnxIb_GIHXbZam3txjvMLalLdeTQBREXBZcfKeNTsmt2fm.1VKf9OC.DmWWIEdaXENrZmMv5gdKH 0LkjGYS8NXE3ggUGTJd2xO7Wv0APoLnpBZTHOsxzgp2h9.WXWyhGJzEiXHOTHKKJNlfCcfcbnIMy sYhXTi.xuvs4.UypofyM5tgJ.O1nXulTeYEsQzoI3obN8xWYGFwp.HykRJaXmbALISPhkJGBsSMk RZRVRtMpApT0hcWAP1wkwzhlf3jHGFwfohGNnJ3PCql.7rPmX9gnhha0xQGkqSHyuANSU8YOE29Z rrWFIyMahZBa4nYJyAshcv0PZnzvvKlE.LmBRfqKn2GGfQZ3QReTgoskOskQUx62EFLy.ulbM6n2 Lr0n.CsIgXy6hNr4JTtoUL1o7P88Dsm5wOVTgGUd.arMkIVVJfGwyCDbooydIn0KuHhHN4rKb5hb oBMvYOorHWfMjXGDLrfxyMX3k4QlomeJZiis6g9tnMpirS8fAD1ZKrCe2Tp8j6LYSxi0drfdzZ1v tzbGig7FoE0uNvcPFihWmO6A_V4ZpIl_WJkj1oGtJ3YJk6LM0X9xiM8ZUG6k1xR06tHFvyvrhSWv lud8AkAa7KSTY_7DPncM5iCetDrUImAOW_L349Mf42hskzSWAReoXeX69uUij7mXyy7sGADaf60x c3I1Z552zhRScZGkqHKbsoTKYTrsZ8oPP5dI.Ig2czhdPoUV5iqxAxqlYfHoB0Jjl6wFlY1B2Bwu 2xtam4USUmr7L4PBJCHcpx2iL7EQDegw5O2mtZP6Uzkr7O4FIg2U2TZdwJ7Qq_aIVLb_x5NhAWOr TruDpg0QUiBJ5AF0.XQVZ0AWWBygWDbuASqVLX_g1ACX2GfvoRMo6J9jrao5eryZTCtGf6JZeJ42 R4Emr8HLneud_M1e8_KSgUHvE7wB2PGUjHqCpEa.9U8AQ0RXVXn_67yfwHk_6fSdZQKvSKlFXE3M Fq9vZdP1vQQ3s7RbQL1ZQetDwe6qAJBpKVdOhZSyU3HEu1VHg1oQQGGHp7qY1WU2dgPpwfT.Oihy XdMnIWPNVC5NKBiETEYia9v6PYK1K65BH8n2Xp2MaPZ2ylbeQzFdRq9LIXj6P43PdZuoGiuLTx1c nD6ooVuuFMvcOJ4yN2PImBQmK8q4hfabPfajTegIJYFzQWp6BtVqiXTV6h32Nu110V9Z1XsJZvD6 R7gVgqwJhi8gbAkRQWzTLRe.WKe0jYuYQ1n.nsttV..sX3I8jjjT03jQjEDnvRd3LIXQCvpyRcEU O1E5bv83OdP2F6lTKzAMZEUx9ssF.Gb9PCpWnyC4NENtpGJxCybXZaUdaDdfJXMKJ0h7Ox3_Dq2_ rvKLRaqnYSaFMIMD8.dRgqd1l7C78KcuJ.5Lc2z6JIYH8cRO0yuMg6lVE0kKh3ITL8pwy6Fs5ASy 6ipzzvu32PuGef.20S1QHi3j1mQjRXXC.zngA6_99SLCfSzFFs6mK5gWcVBJgxu.avwm22Au19r9 Ov6cEHJxOkJr4Clxs0Cr71JXT9CrUyiEijRh0i7RtoIg5MQA0iFQuvOond4Im2OTFZ5bUmhrtzkZ yHGptmSIViFFsadSt9wRFotlUSuZdrftoWzGfrdW8PNic.64BnHH6z8LoyIY1tyyKib_ZVBFZ0of FomBjjzC_LHE5fD_Q7EV05U52suNLKsnjRY.zkpn8N0rMnvrUGf0qapd61r6jm2b4WPG6y3B.T67 1vIFtNjglmucF_AtXBqkVpk5S1sMrbU9vAW_GL6S4P4vcsjTv.jnYozVrC04DKpzIGU8Et9k_VvM sM38zFhMxrmcVL9SMOee2Du9hPNt3ZSkIEkjOmX0_IALKwvVUPVd9o7jxYwGIAq4nBUwkXQspzAQ JoGaPggRGWv81D8wdmJU50r_md2u8o1.2yQ6xKfFecR62QK3_UBWLL5AF3stZT52BJXaxZbWIzMh gXAYU2LcA1AuYkMB7wZ4KbmNUt8UY423liAjBI9lHil8cm5den4vLLYu27kzgEbzA.GXaLOUrFXs 4J6HaFHdk12.JaSqhBRyJsPrwpVqRFjBlBoSFqoqhFRFRBRQ2AjJd1CFycGvva5IJd8Pailp1g8D EpwBTbXX_sVQVxig- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Wed, 2 Jun 2021 10:40:07 +0000 Received: by kubenode542.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 1eb46000f9064ed31a012075fe9a85bf; Wed, 02 Jun 2021 10:40:05 +0000 (UTC) Content-Type: text/plain; charset=us-ascii 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 (Mac OS X Mail 14.0 \(3654.80.0.2.43\)) Subject: Re: /usr/local/share/u-boot/u-boot-orangepi-plus-2e/README out of date ; orangepi-plus-2e and RPi2 v1.1 get "Kernel args: (null)" In-Reply-To: <20210602110113.a92bf9beb5cd9f736934e62b@bidouilliste.com> Date: Wed, 2 Jun 2021 03:40:03 -0700 Cc: Mark Millard via arm Content-Transfer-Encoding: quoted-printable Message-Id: <41ED2750-3E92-44A5-9855-04B2A3DA4EB1@yahoo.com> References: <40298C05-5F50-4437-B15B-7A02EA070EAE.ref@yahoo.com> <40298C05-5F50-4437-B15B-7A02EA070EAE@yahoo.com> <20210513111517.86336633bae9568d8599f229@bidouilliste.com> <20210513124050.47714a83f876d67a80e28080@bidouilliste.com> <3C04FB55-4A26-48C8-833F-E4AC84DC4F78@yahoo.com> <99906599-273E-4216-A41E-DE642F33E392@yahoo.com> <0482F239-B137-42F5-8802-8883D08D5868@yahoo.com> <5F226A9B-852D-4E72-9896-0509E56D3318@yahoo.com> <30B373C0-4C73-4F3A-BDA6-E4CDC55E80C9@yahoo.com> <20210602110113.a92bf9beb5cd9f736934e62b@bidouilliste.com> To: Emmanuel Vadot X-Mailer: Apple Mail (2.3654.80.0.2.43) X-Rspamd-Queue-Id: 4Fw5Bx1YLwz4mrZ X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: marklmi@yahoo.com From: Mark Millard via arm X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Jun-2, at 02:01, Emmanuel Vadot = wrote: > On Sun, 30 May 2021 22:32:38 -0700 > Mark Millard via arm wrote: >=20 >> On 2021-May-30, at 22:27, Mark Millard wrote: >>=20 >>> On 2021-May-24, at 20:10, Mark Millard wrote: >>>=20 >>>> On 2021-May-24, at 15:53, Mark Millard = wrote: >>>>=20 >>>>> On 2021-May-13, at 12:03, Mark Millard = wrote: >>>>>=20 >>>>>>>>> . . . >>>>>=20 >>>>> I do not know if the FreeBSD kernel has been depending >>>>> on some U-Boot initialization for root-on-USB and the >>>>> two no longer match or what. >>>>>=20 >>>>> But I've used a release/13.0.0.0 microsd card based >>>>> boot to get older U-Boot materials (Quarterly as it >>>>> turns out). Installing such got me back to having a >>>>> root-on-USB boot of the OPi+2e (other than the >>>>> mircosd card having the older U-Boot (2020.10 as it >>>>> turns out). Of course there is also the matching >>>>> boot.scr involved --but it also is on the USB SSD. >>>>> (Similarly reverted RPi2 U-Boot, other than needing >>>>> to switch boot.scr to match.) >>>>>=20 >>>>> After booting with the reverted U-Boot related >>>>> material: >>>>>=20 >>>>> # mount -onoatime -tmsdosfs /dev/mmcsd1s1 /mnt >>>>> # mount -onoatime /dev/mmcsd1s2a /media >>>>>=20 >>>>> # ls -Tla /mnt/ >>>>> total 20 >>>>> drwxr-xr-x 1 root wheel 16384 Dec 31 16:00:00 1979 . >>>>> drwxr-xr-x 25 root wheel 512 Dec 31 16:00:40 2009 .. >>>>>=20 >>>>> # ls -Tla /media/ >>>>> total 60 >>>>> drwxr-xr-x 2 root wheel 512 May 24 15:43:19 2021 . >>>>> drwxr-xr-x 25 root wheel 512 Dec 31 16:00:40 2009 .. >>>>> -rwxr-xr-x 1 root wheel 52456 Apr 24 19:48:36 2021 = bootcode.bin >>>>>=20 >>>>> The media is also set up for booting an RPi2 via >>>>> root-in-USB ( other than bootcode.bin ). >>>>>=20 >>>>> If FreeBSD and the more modern U-Boot were well matched >>>>> for USB support, I'd expect that this sort of thing would >>>>> work (no boot.scr needed). >>>>>=20 >>>>> For reference: >>>>>=20 >>>>> # ~/fbsd-based-on-what-freebsd-main.sh=20 >>>>> FreeBSD OPiP2E_RPi2v11 14.0-CURRENT FreeBSD 14.0-CURRENT = mm-src-n245445-def0058cc690 GENERIC-NODBG arm armv7 1400005 1400005 >>>>> def0058cc690 (HEAD -> mm-src) mm-src snapshot for mm's patched = build in git context. >>>>> merge-base: 7381bbee29df959e88ec59866cf2878263e7f3b2 >>>>> merge-base: CommitDate: 2021-03-12 20:29:42 +0000 >>>>> 7381bbee29df (freebsd/main, freebsd/HEAD, pure-src, main) cam: Run = all XPT_ASYNC ccbs in a dedicated thread >>>>> n245444 (--first-parent --count for merge-base) >>>>=20 >>>> Looks like 2021.04 (even before 2021.04_1) also has the >>>> problem for root-on-USB handling. >>>>=20 >>>> I managed to find a 2021-Apr-09 u-boot-orangepi-plus-2e >>>> directory copy that was 2021.04 (and its boot.scr) but >>>> before the UEFI change. When I tried it for the >>>> root-on-USB context I still got the hangup after "Kernel >>>> args: (null)" in: >>>>=20 >>>> . . . >>>> Hit [Enter] to boot immediately, or any other key for command = prompt. >>>> Booting [/boot/kernel/kernel]... =20 >>>> Using DTB provided by EFI at 0x47eea000. >>>> Kernel entry at 0xb2e00200... >>>> Kernel args: (null) >>>>=20 >>>>=20 >>>> So it does not appear to be the UEFI change so much as >>>> 2021.04 in general for which the FreeBSD kernel and >>>> the U-Boot are apparently(?) mismatched for root-on-USB. >>>>=20 >>>>=20 >>>> Reverting again to 2020.10 U-Boot got back the root-on-USB >>>> status. For this the boot looks like: >>>>=20 >>>> . . . >>>> Hit [Enter] to boot immediately, or any other key for command = prompt. >>>> Booting [/boot/kernel/kernel]... =20 >>>> Using DTB provided by EFI at 0x47ef5000. >>>> Kernel entry at 0xb2e00200... >>>> Kernel args: (null) >>>> ---<>--- >>>> KDB: debugger backends: ddb >>>> KDB: current backend: ddb >>>> Copyright (c) 1992-2021 The FreeBSD Project. >>>> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, = 1994 >>>> The Regents of the University of California. All rights = reserved. >>>> FreeBSD is a registered trademark of The FreeBSD Foundation. >>>> FreeBSD 14.0-CURRENT mm-src-n245445-def0058cc690 GENERIC-NODBG arm >>>> FreeBSD clang version 11.0.1 (git@github.com:llvm/llvm-project.git = llvmorg-11.0.1-0-g43ff75f2c3fe) >>>> . . . >>>>=20 >>>=20 >>> Well, I got a surprise in exploring: removing boot.scr >>> and ubldr.bin did not prevent booting. (Noticed by the >>> accident of ending up with one of them missing that I >>> only later noticed.) So I recorded a boot and: >>>=20 >>> . . . >>> U-Boot SPL 2020.10 (Apr 19 2021 - 18:04:31 +0000) >>> DRAM: 2048 MiB >>> Trying to boot from MMC1 >>>=20 >>>=20 >>> U-Boot 2020.10 (Apr 19 2021 - 18:04:31 +0000) Allwinner Technology >>>=20 >>> CPU: Allwinner H3 (SUN8I 1680) >>> Model: Xunlong Orange Pi Plus 2E >>> DRAM: 2 GiB >>> . . . >>> Device 0: Vendor: OWC Rev: 0 Prod: Envoy Pro mini =20 >>> Type: Hard Disk >>> Capacity: 228936.5 MB =3D 223.5 GB (468862128 x 512) >>> ... is now current device >>> Scanning usb 0:4... >>> 30675 bytes read in 3 ms (9.8 MiB/s) >>> Found EFI removable media binary efi/boot/bootarm.efi >>> . . . >>> Booting /efi\boot\bootarm.efi >>> Consoles: EFI console =20 >>>=20 >>>=20 >>> |=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08 Reading loader env vars from = /efi/freebsd/loader.env >>>=20 >>>=20 >>> Setting currdev to disk2p4: >>>=20 >>>=20 >>> |=08/=08-=08\=08|=08/=08FreeBSD/arm EFI loader, Revision 1.1 >>> . . . >>>=20 >>> So I've likely been been booting via UEFI for >>> some time via 2020.10 (or even before?), just >>> without noticing at the time. >>>=20 >>> The other implication is likely that what disabled >>> root-on-USB for my context was not the boot.scr >>> removal material but some (possibly proper) subset >>> of other material changed (extracted from >>> ports' main 0d6e5081eb00 commit cgit display): >>=20 >> Nope: I forgot that I've tried 2021.04 from before >> the UEFI changes referenced, and also had the >> problem for that context. >=20 > 2021.04 cannot work on armv7, caches weren't cleared. >=20 >> Still it is interesting that I'm getting a UEFI >> boot context from 2020.10 . >=20 > The only thing I can suggest is git bisect on u-boot repo and see if > you have any result. >=20 Just FYI: As a cross check, I tried the U-Boot 2021.04 from fedora 34's uboot-images-armv7-2021.04-3.fc34.noarch.rpm and its (as installed): /usr/share/uboot/orangepi_plus2e/u-boot-sunxi-with-spl.bin The overall boot also hangs, with slightly different messaging: . . . Booting [/boot/kernel/kernel]... =20 Using DTB provided by EFI at 0x47f00000. Kernel entry at 0xb2e00200... Kernel args: (null) EHCI failed to shut down host controller. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Wed Jun 2 11:13:55 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 4D465EF95A7 for ; Wed, 2 Jun 2021 11:14:06 +0000 (UTC) (envelope-from freebsd-arm@dino.sk) Received: from mailhost.netlabit.sk (mailhost.netlabit.sk [84.245.65.72]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Fw5y512Jmz4rTx for ; Wed, 2 Jun 2021 11:14:04 +0000 (UTC) (envelope-from freebsd-arm@dino.sk) Received: from zeta.dino.sk (fw3.dino.sk [84.245.95.254]) (AUTH: LOGIN milan) by mailhost.netlabit.sk with ESMTPA; Wed, 02 Jun 2021 13:13:55 +0200 id 00DD63AB.60B767F3.000083CF Date: Wed, 2 Jun 2021 13:13:55 +0200 From: Milan Obuch To: freebsd-arm@freebsd.org Subject: Re: Oversimplification Message-ID: <20210602131355.0edf2167@zeta.dino.sk> In-Reply-To: <35728cba-0152-9b73-77f9-48683e870bbd@m5p.com> References: <35728cba-0152-9b73-77f9-48683e870bbd@m5p.com> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.33; i386-portbld-freebsd11.4) 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 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4Fw5y512Jmz4rTx X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of freebsd-arm@dino.sk designates 84.245.65.72 as permitted sender) smtp.mailfrom=freebsd-arm@dino.sk X-Spamd-Result: default: False [-3.30 / 15.00]; RCVD_TLS_LAST(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[84.245.65.72:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[dino.sk]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[84.245.65.72:from:127.0.2.255]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.997]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:5578, ipnet:84.245.64.0/18, country:SK]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arm] X-ThisMailContainsUnwantedMimeParts: N On Sun, 30 May 2021 17:49:01 -0400, George Mitchell wrote: > I've never been shy about oversimplifying complex questions, so here > goes: What's the ARM system that presents the least hassle to a > prospective FreeBSD user? Here's what I mean by low hassle: > > 1. Widely available. > 2. Runs some standard FreeBSD image with minimal (or no) tweaking. > 3. I suspect ARM64 means less hassle than ARM32. > 4. Friendly to an external high-speed (at least USB 3; possibly SATA?) > disk. > 5. Hopefully 8GB on-board memory, though 4GB is probably okay if high > speed swapping is available (see point 4). > 6. Affordable, but not cheap. > > And next on my Santa list ... -- George > Did you consider RockPro64 from pine64.com? Two models are available, with 2 GB RAM and 4 GB RAM. There is PCIe x4 slot, USB ports (3.0 and 2.0, four total), so your prerequisites are probably met. Also, you can download FreeBSD-13.0-RELEASE-arm64-aarch64-ROCKPRO64.img.xz from FreeBSD ftp site and start. I could test it in past for some days and it worked. I did not have opportunity to test what could be connected to PCIe slot, but from the same vendor some cards could be had as well - dual SATA-II or M.2/NGFF interface card. Just one a bit odd detail using stock image - console line speed was 1.5 Mb/s. I spent some time figuring this. 4 GB version currently out of stock, unfortunately. They are preparing Quartz64 card, up to 8 GB RAM, no ETA yet. Regards, Milan From nobody Wed Jun 2 13:01:52 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 8F534EFEFA0; Wed, 2 Jun 2021 13:02:04 +0000 (UTC) (envelope-from dsl@mcusim.org) Received: from mcusim.org (mcusim.org [176.58.93.53]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Fw8Lg1pN0z3Hk3; Wed, 2 Jun 2021 13:02:02 +0000 (UTC) (envelope-from dsl@mcusim.org) Received: from x230.ds (unknown [83.28.234.19]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mcusim.org (Postfix) with ESMTPSA id 453287E4A4; Wed, 2 Jun 2021 15:01:54 +0200 (CEST) Date: Wed, 2 Jun 2021 15:01:52 +0200 From: Dmitry Salychev To: "Bjoern A. Zeeb" Cc: freebsd-arm@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: U-Boot for HoneyComb LX2 Message-ID: References: <198F84BF-5932-4E58-BCE3-CC33B185923A@lists.zabbadoz.net> 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 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <198F84BF-5932-4E58-BCE3-CC33B185923A@lists.zabbadoz.net> X-Rspamd-Queue-Id: 4Fw8Lg1pN0z3Hk3 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=reject) header.from=mcusim.org; spf=pass (mx1.freebsd.org: domain of dsl@mcusim.org designates 176.58.93.53 as permitted sender) smtp.mailfrom=dsl@mcusim.org X-Spamd-Result: default: False [-3.80 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[83.28.234.19:received]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+a]; MIME_GOOD(-0.10)[text/plain]; RBL_DBL_DONT_QUERY_IPS(0.00)[176.58.93.53:from]; SPAMHAUS_ZRD(0.00)[176.58.93.53:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[mcusim.org,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:36236, ipnet:176.58.93.0/24, country:US]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-arm,freebsd-hackers]; RCVD_COUNT_TWO(0.00)[2] X-Spam: Yes X-ThisMailContainsUnwantedMimeParts: N > I’ve got a local tree (on Jan 2021, needs updating to latest and > re-test before > submit) for the uEFI firmware (not u-boot). Btw, do you have that tree available somewhere? Did you manage to load a blob from NXP and initialize DPAA2 MC? Regards, Dmitry From nobody Wed Jun 2 17:34:58 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 F2E70DFEAFC for ; Wed, 2 Jun 2021 17:35:07 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from mailhost.m5p.com (mailhost.m5p.com [74.104.188.4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "m5p.com", Issuer "R3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4FwGPl1kqHz4SLG for ; Wed, 2 Jun 2021 17:35:06 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from [IPv6:2001:470:1f07:15ff::26] (court.m5p.com [IPv6:2001:470:1f07:15ff:0:0:0:26]) (authenticated bits=0) by mailhost.m5p.com (8.16.1/8.15.2) with ESMTPSA id 152HYx8r031727 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Wed, 2 Jun 2021 13:35:04 -0400 (EDT) (envelope-from george+freebsd@m5p.com) Subject: Re: Oversimplification To: freebsd-arm@freebsd.org References: <35728cba-0152-9b73-77f9-48683e870bbd@m5p.com> <20210602131355.0edf2167@zeta.dino.sk> From: George Mitchell Message-ID: <985a5668-de53-66b5-c82e-568697d896ab@m5p.com> Date: Wed, 2 Jun 2021 13:34:58 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.9.1 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 In-Reply-To: <20210602131355.0edf2167@zeta.dino.sk> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="PGWuHAAScxWhGoulUmULFPRJMJ8hr0RFQ" X-Spam-Status: No, score=0.2 required=10.0 tests=HELO_MISC_IP,HELO_NO_DOMAIN, NICE_REPLY_A autolearn=no autolearn_force=no version=3.4.5 X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on mattapan.m5p.com X-Rspamd-Queue-Id: 4FwGPl1kqHz4SLG X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of george@m5p.com designates 74.104.188.4 as permitted sender) smtp.mailfrom=george@m5p.com X-Spamd-Result: default: False [-4.42 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+a]; HAS_ATTACHMENT(0.00)[]; TO_DN_NONE(0.00)[]; NEURAL_HAM_SHORT(-0.02)[-0.017]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~]; RBL_DBL_DONT_QUERY_IPS(0.00)[74.104.188.4:from]; ASN(0.00)[asn:701, ipnet:74.104.0.0/16, country:US]; MID_RHS_MATCH_FROM(0.00)[]; TAGGED_FROM(0.00)[freebsd]; R_DKIM_NA(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; DMARC_NA(0.00)[m5p.com]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[74.104.188.4:from:127.0.2.255]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-arm] X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --PGWuHAAScxWhGoulUmULFPRJMJ8hr0RFQ Content-Type: multipart/mixed; boundary="UDdhORyM4XHLwXIDXuTFThEWFHP56cZ4c"; protected-headers="v1" From: George Mitchell To: freebsd-arm@freebsd.org Message-ID: <985a5668-de53-66b5-c82e-568697d896ab@m5p.com> Subject: Re: Oversimplification References: <35728cba-0152-9b73-77f9-48683e870bbd@m5p.com> <20210602131355.0edf2167@zeta.dino.sk> In-Reply-To: <20210602131355.0edf2167@zeta.dino.sk> --UDdhORyM4XHLwXIDXuTFThEWFHP56cZ4c Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 6/2/21 7:13 AM, Milan Obuch wrote: > On Sun, 30 May 2021 17:49:01 -0400, George Mitchell > wrote: >=20 >> I've never been shy about oversimplifying complex questions, so here >> goes: What's the ARM system that presents the least hassle to a >> prospective FreeBSD user? Here's what I mean by low hassle: >> >> 1. Widely available. >> 2. Runs some standard FreeBSD image with minimal (or no) tweaking. >> 3. I suspect ARM64 means less hassle than ARM32. >> 4. Friendly to an external high-speed (at least USB 3; possibly SATA?)= >> disk. >> 5. Hopefully 8GB on-board memory, though 4GB is probably okay if high >> speed swapping is available (see point 4). >> 6. Affordable, but not cheap. >> >> And next on my Santa list ... -- George >> >=20 > Did you consider RockPro64 from pine64.com? Two models are available, > with 2 GB RAM and 4 GB RAM. There is PCIe x4 slot, USB ports (3.0 and > 2.0, four total), so your prerequisites are probably met. Also, you can= > download FreeBSD-13.0-RELEASE-arm64-aarch64-ROCKPRO64.img.xz from > FreeBSD ftp site and start. >=20 > I could test it in past for some days and it worked. I did not have > opportunity to test what could be connected to PCIe slot, but from the > same vendor some cards could be had as well - dual SATA-II or M.2/NGFF > interface card. >=20 > Just one a bit odd detail using stock image - console line speed was > 1.5 Mb/s. I spent some time figuring this. 4 GB version currently out > of stock, unfortunately. >=20 > They are preparing Quartz64 card, up to 8 GB RAM, no ETA yet. >=20 > Regards, > Milan >=20 Thanks for the response! -- George --UDdhORyM4XHLwXIDXuTFThEWFHP56cZ4c-- --PGWuHAAScxWhGoulUmULFPRJMJ8hr0RFQ Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsF5BAABCAAjFiEENdM4ZHktsJW5kKZXwRES3m+p4fkFAmC3wUIFAwAAAAAACgkQwRES3m+p4fkw DA//ZNCCBTZI+03Xzd1cYKvWEhenMSlVCCXkcJlT436aXVk4iOiaBVeG73EbyoN57s3M/JT1+SwK kbsOwvKa2B4q4LJDYPiK16+sQxcyH2CVP5IZDIw04Ihdz1EWh3MwGBiRGpRNDqAJMCOZ8EyPWWy+ o08pEO3X7SkXoPgaj8PfSPDKNGp9dWbhasTbkk07JMxPzTGOyW50J72m2O3qnh0O/YxNH0DrmXrR bDvr8YGVcWABAmG/LUXSIHEgWnyUZ6Yn7dwQezq3w84kyCfXwN2dSA89dYYxd+ZTzeS1aa5Z2mVp n2Yxq1TeoKg/m7PWx6d3WDLvBFAWBWb5RWCnMZBlCn3x55RyRcvMJG476bTbC77FgNyqrx9vzVd1 DgDVJ1MjS6YbYov14a98yng4Le11eALNwKhfF6Ks0+aucr76q9TGq/FqqH/FLJARY6SLGajumfYp z6tTQP/wx8lcLGgBc7mhSXjzg90QVBPlVqg1L/lhhqQuiatBNPDcQ3W8kmd1VZ3oD618ViglMvhv REEDGPKcpDZudOHxKE8il21DHMtld1KbuoKDCPWQhUNRcz1zUZoUgu+rnI1w3EhH7pZmjqwNRA4F XL8h5JFegnmvx8WCoJWMi/PGJNFSvOep4sIXLr4WtwWlfJoxoXcuN7Ny1av0KSNGkUiIUijMYs50 Jng= =HTJF -----END PGP SIGNATURE----- --PGWuHAAScxWhGoulUmULFPRJMJ8hr0RFQ-- From nobody Wed Jun 2 18:47:07 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 65053E7A309 for ; Wed, 2 Jun 2021 18:47:14 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4FwJ0x17qSz4XVk for ; Wed, 2 Jun 2021 18:47:12 +0000 (UTC) (envelope-from ronald-lists@klop.ws) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=klop.ws; s=mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version: Date:Message-ID:From:References:To:Subject:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=igMMLFL/qqmjutXje6V4ghqmxkZmdSi3MYWRiF9Q568=; b=hCtrQdNZ/QSFukzM6HQVqRedm+ w3MyO0D9bZsF/g5sizzpeVIP6IdoHX94MjkynBVDJlqqEg7WsoMy0rdJlVUPbKvuons4QrTgU8VY+ dWRAVGDwvkaPHKpok6Ue+GqCQJqb14tl5KegoT7i1qBxTZ7vKQG1hwkDrMGT1xAzYtNY=; Subject: Re: Status of wireless driver development for Raspberry Pi? To: freebsd-arm@freebsd.org, bzeeb-lists@lists.zabbadoz.net References: <94AF68C7-3E9A-4686-AA20-DC592C84A2FD@exchange.mit.edu> From: Ronald Klop Message-ID: Date: Wed, 2 Jun 2021 20:47:07 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.10.2 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 In-Reply-To: <94AF68C7-3E9A-4686-AA20-DC592C84A2FD@exchange.mit.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Authenticated-As-Hash: 398f5522cb258ce43cb679602f8cfe8b62a256d1 X-Virus-Scanned: by clamav at smarthost1.greenhost.nl X-Spam-Level: - X-Spam-Score: -1.0 X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_50,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A autolearn=disabled version=3.4.2 X-Scan-Signature: a350ae07b5350cdad28cef237d2e7179 X-Rspamd-Queue-Id: 4FwJ0x17qSz4XVk X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=klop.ws header.s=mail header.b=hCtrQdNZ; dmarc=pass (policy=none) header.from=klop.ws; spf=pass (mx1.freebsd.org: domain of ronald-lists@klop.ws designates 195.190.28.88 as permitted sender) smtp.mailfrom=ronald-lists@klop.ws X-Spamd-Result: default: False [-3.00 / 15.00]; ARC_NA(0.00)[]; RWL_MAILSPIKE_VERYGOOD(0.00)[195.190.28.88:from]; R_DKIM_ALLOW(-0.20)[klop.ws:s=mail]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:195.190.28.64/27]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[klop.ws:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[195.190.28.88:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[klop.ws,none]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:47172, ipnet:195.190.28.0/24, country:NL]; MID_RHS_MATCH_FROM(0.00)[]; MAILMAN_DEST(0.00)[freebsd-arm] X-ThisMailContainsUnwantedMimeParts: N On 5/31/21 10:43 PM, John F Carr wrote: > According to a page that hasn't been updated for a while (https://wiki.freebsd.org/SDIO) work is in progress on Broadcom wireless drivers for the Raspberry Pi 3 and 4. I'm supposed to start by building the GENERIC-MMCCAM kernel. A CAM device will then appear which I can then use camcontrol to talk to. I built the kernel and booted it on my Pi 3B+, which has a Broadcom 43455/6 according to Linux. All camcontrol finds is the mini SD card. I see only one call to sdhci_init_slot in bcm2835_sdhost.c so maybe that's the problem. It supports exactly one SDIO device, a memory card. > > Any thoughts? Is it worth thinking about the wireless chip or is it just too much work? > > # camcontrol devlist > at scbus0 target 0 lun 0 (pass0,sdda0) > # camcontrol devlist -v > scbus0 on sdhci_slot0 bus 0: > at scbus0 target 0 lun 0 (pass0,sdda0) > scbus-1 on xpt0 bus 0: > <> at scbus-1 target -1 lun ffffffff (xpt0) > > > As you got no answer from somebody who knows more about this than I do I will try to give some pointers. Here you can search through the history of the mailinglist. https://lists.freebsd.org/archives/freebsd-arm/date.html Look for WiFi/SDIO/RPI kind of subjects. The latest I found about this subject: https://lists.freebsd.org/archives/freebsd-arm/2020-October/022626.html. I don't know anything about the current state. But a USB-WiFi dongle might be a reasonable shortcut. I'll cc the Bjoern from this e-mail. @bjoern: do you have a status update? Regards, Ronald. From nobody Wed Jun 2 18:56:27 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 D2A0DE7A6F8 for ; Wed, 2 Jun 2021 18:56:29 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4FwJCd1d0fz4YWg; Wed, 2 Jun 2021 18:56:28 +0000 (UTC) (envelope-from ronald-lists@klop.ws) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=klop.ws; s=mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version: Date:Message-ID:From:References:To:Subject:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=eMPrvJVOEyvn3V7p/+aohNPUTQiNUioSAGNu5Q9y2jg=; b=IO4q0hpaToQg9CZ8wgyNQa1G/s J2kkkW7hE9nKMPOf81pQVLFzOenh+BIPLEnYoDoIg5xgrBf+UYfAhYmMs10NmkG3wK25vFD7V3gBv u/HuDfk7jEBbAqOvWwsEPVQagoaF8Q06Ej6YSkJibejg2wD+NZUwG0BON0mj/paE2bYQ=; Subject: Re: Status of wireless driver development for Raspberry Pi? To: freebsd-arm@freebsd.org, freebsd-wireless@freebsd.org References: <94AF68C7-3E9A-4686-AA20-DC592C84A2FD@exchange.mit.edu> From: Ronald Klop Message-ID: Date: Wed, 2 Jun 2021 20:56:27 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.10.2 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 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Authenticated-As-Hash: 398f5522cb258ce43cb679602f8cfe8b62a256d1 X-Virus-Scanned: by clamav at smarthost1.greenhost.nl X-Spam-Level: - X-Spam-Score: -1.0 X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_50,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A autolearn=disabled version=3.4.2 X-Scan-Signature: 1fac81774939798d1cdb19633eb460de X-Rspamd-Queue-Id: 4FwJCd1d0fz4YWg X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=klop.ws header.s=mail header.b=IO4q0hpa; dmarc=pass (policy=none) header.from=klop.ws; spf=pass (mx1.freebsd.org: domain of ronald-lists@klop.ws designates 195.190.28.88 as permitted sender) smtp.mailfrom=ronald-lists@klop.ws X-Spamd-Result: default: False [-3.00 / 15.00]; ARC_NA(0.00)[]; RWL_MAILSPIKE_VERYGOOD(0.00)[195.190.28.88:from]; R_DKIM_ALLOW(-0.20)[klop.ws:s=mail]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:195.190.28.64/27]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; DKIM_TRACE(0.00)[klop.ws:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[195.190.28.88:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[klop.ws,none]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:47172, ipnet:195.190.28.0/24, country:NL]; MID_RHS_MATCH_FROM(0.00)[]; MAILMAN_DEST(0.00)[freebsd-wireless,freebsd-arm] X-ThisMailContainsUnwantedMimeParts: N On 6/2/21 8:47 PM, Ronald Klop wrote: > On 5/31/21 10:43 PM, John F Carr wrote: >> According to a page that hasn't been updated for a while (https://wiki.freebsd.org/SDIO) work is in progress on Broadcom wireless drivers for the Raspberry Pi 3 and 4.  I'm supposed to start by building the GENERIC-MMCCAM kernel.  A CAM device will then appear which I can then use camcontrol to talk to.  I built the kernel and booted it on my Pi 3B+, which has a  Broadcom 43455/6 according to Linux.   All camcontrol finds is the mini SD card. I see only one call to sdhci_init_slot in bcm2835_sdhost.c so maybe that's the problem.  It supports exactly one SDIO device, a memory card. >> >> Any thoughts?  Is it worth thinking about the wireless chip or is it just too much work? >> >> # camcontrol devlist >>   at scbus0 target 0 lun 0 (pass0,sdda0) >> # camcontrol devlist -v >> scbus0 on sdhci_slot0 bus 0: >>   at scbus0 target 0 lun 0 (pass0,sdda0) >> scbus-1 on xpt0 bus 0: >> <>                                 at scbus-1 target -1 lun ffffffff (xpt0) >> >> >> > > > As you got no answer from somebody who knows more about this than I do I will try to give some pointers. > > Here you can search through the history of the mailinglist. https://lists.freebsd.org/archives/freebsd-arm/date.html > Look for WiFi/SDIO/RPI kind of subjects. > > The latest I found about this subject: https://lists.freebsd.org/archives/freebsd-arm/2020-October/022626.html. > > I don't know anything about the current state. But a USB-WiFi dongle might be a reasonable shortcut. > > I'll cc the Bjoern from this e-mail. @bjoern: do you have a status update? > > Regards, > Ronald. > Oh, here is another update: https://lists.freebsd.org/archives/freebsd-arm/2020-February/021340.html which points to https://lists.freebsd.org/pipermail/freebsd-wireless/2020-February/008985.html So, somebody on the freebsd-wireless might know about it also, IMHO It would be nice if the work-in-progress of this driver was shared in a known place so more people could help. Regards, Ronald. From nobody Thu Jun 3 06:20:13 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 712DB137588B for ; Thu, 3 Jun 2021 06:20:37 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from vtr.rulingia.com (vtr.rulingia.com [IPv6:2001:19f0:5801:ebe:5400:1ff:fe53:30fd]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA512 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "vtr.rulingia.com", Issuer "R3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4FwbP00h5nz4TFQ for ; Thu, 3 Jun 2021 06:20:35 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from server.rulingia.com (ppp239-208.static.internode.on.net [59.167.239.208]) by vtr.rulingia.com (8.16.1/8.15.2) with ESMTPS id 1536KJ4k019066 (version=TLSv1.3 cipher=AEAD-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 3 Jun 2021 16:20:24 +1000 (AEST) (envelope-from peter@rulingia.com) DKIM-Filter: OpenDKIM Filter v2.10.3 vtr.rulingia.com 1536KJ4k019066 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=rulingia.com; s=default; t=1622701225; bh=UO0qFXfi63zY8IirYMfcoIbHvYXahGFou/9+NodaEec=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=DC9G7Pu5hpPqSHeR+RNoXTCuroBp3qqCADM/R+Y3X94dJNfiOKxWwiW/+ouOq0xd4 Eqsji3Xx2ZLwxJionqYZyVNCfSU5byRwfA3u60aXUZDKctr0aTogz4QGFW9tGVv8zT nIc39zP5+ZkjdP/LQ6tXVCSfLiMOgihAUp2mKZMnP+gYRBGFeDsq4u2EdhSpUE/5QL H6L5hl3aqI8d2sGf2y+sWcDgITxDwQL1mDQJ+zwsTlQOMpVeb6BztqQyAxscJ/UeBI sgstXK2vyX9vWcwI43ImI2hJOOMD58n9q2b9PNfEOrLXO+D6G4L7Hu9ZESfmtGnCoM 9rY1YSE5C798w== X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.16.1/8.16.1) with ESMTPS id 1536KDJ0028215 (version=TLSv1.3 cipher=AEAD-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 3 Jun 2021 16:20:13 +1000 (AEST) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.16.1/8.16.1/Submit) id 1536KDLs028214; Thu, 3 Jun 2021 16:20:13 +1000 (AEST) (envelope-from peter) Date: Thu, 3 Jun 2021 16:20:13 +1000 To: George Mitchell Cc: "freebsd-arm@freebsd.org" Subject: Re: Oversimplification Message-ID: References: <35728cba-0152-9b73-77f9-48683e870bbd@m5p.com> 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 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="CLXGH/OeGZItvI8y" Content-Disposition: inline In-Reply-To: <35728cba-0152-9b73-77f9-48683e870bbd@m5p.com> X-PGP-Key: http://www.rulingia.com/keys/peter.pgp X-Rspamd-Queue-Id: 4FwbP00h5nz4TFQ X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=rulingia.com header.s=default header.b=DC9G7Pu5; dmarc=pass (policy=quarantine) header.from=rulingia.com; spf=pass (mx1.freebsd.org: domain of peter@rulingia.com designates 2001:19f0:5801:ebe:5400:1ff:fe53:30fd as permitted sender) smtp.mailfrom=peter@rulingia.com X-Spamd-Result: default: False [-6.09 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[rulingia.com:s=default]; FREEFALL_USER(0.00)[peter]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-1.00)[-1.000]; TAGGED_RCPT(0.00)[freebsd]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; SPAMHAUS_ZRD(0.00)[2001:19f0:5801:ebe:5400:1ff:fe53:30fd:from:127.0.2.255]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[rulingia.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[rulingia.com,quarantine]; NEURAL_HAM_SHORT(-0.99)[-0.989]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RBL_DBL_DONT_QUERY_IPS(0.00)[2001:19f0:5801:ebe:5400:1ff:fe53:30fd:from]; ASN(0.00)[asn:20473, ipnet:2001:19f0:5800::/38, country:US]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-arm] Reply-To: peter@rulingia.com From: Peter Jeremy via freebsd-arm X-Original-From: Peter Jeremy X-ThisMailContainsUnwantedMimeParts: N --CLXGH/OeGZItvI8y Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2021-May-30 17:49:01 -0400, George Mitchell wro= te: >I've never been shy about oversimplifying complex questions, so here >goes: What's the ARM system that presents the least hassle to a >prospective FreeBSD user? Here's what I mean by low hassle: > >1. Widely available. >2. Runs some standard FreeBSD image with minimal (or no) tweaking. >3. I suspect ARM64 means less hassle than ARM32. >4. Friendly to an external high-speed (at least USB 3; possibly SATA?) > disk. >5. Hopefully 8GB on-board memory, though 4GB is probably okay if high > speed swapping is available (see point 4). >6. Affordable, but not cheap. I'll second Milan's followup. I have a 4GB RockPro64 with the dual-SATA PCIe card and am quite happy with it. It also supports both USB-3 and USB-C, though I haven't experimented with either. Note that the WiFi/Bluetooth module for the RockPro64 uses SDIO, and the combination isn't yet supported by FreeBSD. I also have a BananaPi M1, which has an integral SATA port but I've never managed to get the SATA to work. --=20 Peter Jeremy --CLXGH/OeGZItvI8y Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQKTBAEBCgB9FiEE7rKYbDBnHnTmXCJ+FqWXoOSiCzQFAmC4dJhfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEVF QjI5ODZDMzA2NzFFNzRFNjVDMjI3RTE2QTU5N0EwRTRBMjBCMzQACgkQFqWXoOSi CzQmeg/9FpCsgMO3VZJYJTySw5AOvEjZvqENE7+x2UYtErn7fMG0lrpYqvq7qxDV 5hL7BeL85JblueiVSqt8yXmIAEEl7oRZtALxnTal+FObZU+qc/FxQ7zcfNnftRoX +9Nh2M880Xr0lIHMqKI4ggP54Es5IlXecEk2AU2quYyOR78iUgqL8tl1LRdiCifH xjnqU2e6XtXgA/ft/FfnWdBqOsASc1Ru+L0AMjtZb7XcFPbP0QWQdpZj9wzEOiGn P+n/+f7BkeJLD6b3GO1aqN4egCxCCtKYqLHnvmj89QZqvEYjixC1obGGYp5AKTYk w8IeGLO3rQlLDV/f+2ZHn6JJctjh4I9GxzxM1NHXaCV0aUkELs92HMcZECZduMTA wUKbcGnNN9sveKAgFzMB16DW0a0uKbGRpyiSCDaA2nqa7l1l05lDgkhqAYu3926p BYjDyxaHTEBdiizuJ6m3D6CrYr9HWb2PwYnViHQNfCxDoRWdZCETpFhM73p4cx0I dJ1Yag3KujRcmbl+zI0SA49qt6Jxw/CO7ZaPSYv0LPgsC3CqYbLLLhU+vM0H9cEt ktKPfcHIRJ+YdmpX1lnIiEiRbuGU7bhwp0+tyGAXnk1hiHo0tuMEPdv947dxqH+D z8yVTtA66x4hU413LKsVC9bjAd4Rv/X6EianUnR1B9LOrZMNBv0= =ZAla -----END PGP SIGNATURE----- --CLXGH/OeGZItvI8y-- From nobody Thu Jun 3 06:46:47 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 9C6C11377D42 for ; Thu, 3 Jun 2021 06:46:54 +0000 (UTC) (envelope-from freebsd-arm@dino.sk) Received: from mailhost.netlabit.sk (mailhost.netlabit.sk [84.245.65.72]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4FwbzL1RFpz4Y41 for ; Thu, 3 Jun 2021 06:46:53 +0000 (UTC) (envelope-from freebsd-arm@dino.sk) Received: from zeta.dino.sk (fw3.dino.sk [84.245.95.254]) (AUTH: LOGIN milan) by mailhost.netlabit.sk with ESMTPA; Thu, 03 Jun 2021 08:46:51 +0200 id 00DD63A3.60B87ADB.000116DE Date: Thu, 3 Jun 2021 08:46:47 +0200 From: Milan Obuch To: freebsd-arm@freebsd.org Cc: peter@rulingia.com Subject: Re: Oversimplification Message-ID: <20210603084647.24eeed35@zeta.dino.sk> In-Reply-To: References: <35728cba-0152-9b73-77f9-48683e870bbd@m5p.com> X-Mailer: Claws Mail 3.17.8git86 (GTK+ 2.24.33; i386-unknown-freebsd11.4) 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 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4FwbzL1RFpz4Y41 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Thu, 3 Jun 2021 16:20:13 +1000, Peter Jeremy via freebsd-arm wrote: > On 2021-May-30 17:49:01 -0400, George Mitchell > wrote: > >I've never been shy about oversimplifying complex questions, so here > >goes: What's the ARM system that presents the least hassle to a > >prospective FreeBSD user? Here's what I mean by low hassle: > > > >1. Widely available. > >2. Runs some standard FreeBSD image with minimal (or no) tweaking. > >3. I suspect ARM64 means less hassle than ARM32. > >4. Friendly to an external high-speed (at least USB 3; possibly > > SATA?) disk. > >5. Hopefully 8GB on-board memory, though 4GB is probably okay if high > > speed swapping is available (see point 4). > >6. Affordable, but not cheap. > > I'll second Milan's followup. I have a 4GB RockPro64 with the > dual-SATA PCIe card and am quite happy with it. It also supports > both USB-3 and USB-C, though I haven't experimented with either. > Just out of curiosity - do you mean SATA card from pine64.org shop? Was some extra steps required to make it work? Could you share relevant lines from dmesg output? > Note that the WiFi/Bluetooth module for the RockPro64 uses SDIO, > and the combination isn't yet supported by FreeBSD. > Well, it would be nice to get it to working state... no idea how much work that is. Regards, Milan From nobody Thu Jun 3 07:15:30 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 388A213794A6 for ; Thu, 3 Jun 2021 07:15:53 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from vtr.rulingia.com (vtr.rulingia.com [IPv6:2001:19f0:5801:ebe:5400:1ff:fe53:30fd]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA512 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "vtr.rulingia.com", Issuer "R3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Fwccm4gN7z4bGf for ; Thu, 3 Jun 2021 07:15:51 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from server.rulingia.com (ppp239-208.static.internode.on.net [59.167.239.208]) by vtr.rulingia.com (8.16.1/8.15.2) with ESMTPS id 1537FbuL019287 (version=TLSv1.3 cipher=AEAD-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 3 Jun 2021 17:15:42 +1000 (AEST) (envelope-from peter@rulingia.com) DKIM-Filter: OpenDKIM Filter v2.10.3 vtr.rulingia.com 1537FbuL019287 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=rulingia.com; s=default; t=1622704542; bh=7ZkBuXWyH6hg2sueNhSXRGVWGTYmSuBXbVB2w09U72o=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=laRae6/jE2KReX3OcrQ4h4TmheCMEC2uhMz89Kc50iwozBL1vQD8lo7xgmjEZzt0T qutXekh7PK6bPBCMNV4bxVerf381qWxcBlkUDssxEabEO9PuLJj/FFWmx74i3XyFDM g+V4bGtJCbvrdwPAxwQgBI1GVs3JDPwpbiQTf3ba37+O7uSeU7JwRE4wNhuF/eAN6E c5TyWrHZH2IYJcgsVwoqCibNNJ9b8M+sD2bQ/hS7I2IpD7nVhAx4+F1thKVOjaPUZF eLKe7uMGuUoOIqLaYg90lWmTonv+7bSGdEnl91TtoDYZsgjGJrz6H45sZIdx07c8FM Wv/LPzqdBwfow== X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.16.1/8.16.1) with ESMTPS id 1537FUnI030152 (version=TLSv1.3 cipher=AEAD-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 3 Jun 2021 17:15:30 +1000 (AEST) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.16.1/8.16.1/Submit) id 1537FU8b030151; Thu, 3 Jun 2021 17:15:30 +1000 (AEST) (envelope-from peter) Date: Thu, 3 Jun 2021 17:15:30 +1000 To: Milan Obuch Cc: freebsd-arm@freebsd.org Subject: Re: Oversimplification Message-ID: References: <35728cba-0152-9b73-77f9-48683e870bbd@m5p.com> <20210603084647.24eeed35@zeta.dino.sk> 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 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="3WRfunwktL25iW3F" Content-Disposition: inline In-Reply-To: <20210603084647.24eeed35@zeta.dino.sk> X-PGP-Key: http://www.rulingia.com/keys/peter.pgp X-Rspamd-Queue-Id: 4Fwccm4gN7z4bGf X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: peter@rulingia.com From: Peter Jeremy via freebsd-arm X-Original-From: Peter Jeremy X-ThisMailContainsUnwantedMimeParts: N --3WRfunwktL25iW3F Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2021-Jun-03 08:46:47 +0200, Milan Obuch wrote: >> I'll second Milan's followup. I have a 4GB RockPro64 with the >> dual-SATA PCIe card and am quite happy with it. It also supports >> both USB-3 and USB-C, though I haven't experimented with either. >> > >Just out of curiosity - do you mean SATA card from pine64.org shop? Was >some extra steps required to make it work? Could you share relevant >lines from dmesg output? Yes, this was the pine64.org card - I've build a PineNAS, though I'm still trying to work out how to set it up the way I want. The card doesn't need any special configuration. Note that the RockPro64 doesn't support booting from SATA. pcib0: mem 0xf8000000-0xf9ffffff,0xfd000000-0xfd= ffffff irq 6,7,8 on ofwbus0 pci0: on pcib0 pcib1: at device 0.0 on pci0 pcib0: route pin 1 for device 0.0 to 78 ahci0: irq 78 at device 0.0 on pci1 ahci0: AHCI v1.20 with 2 6Gbps ports, Port Multiplier supported ahci0: quirks=3D0xc00000 ahcich0: at channel 0 on ahci0 ahcich1: at channel 1 on ahci0 ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ACS-3 ATA SATA 3.x device ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) ada1 at ahcich1 bus 0 scbus1 target 0 lun 0 ada1: ACS-3 ATA SATA 3.x device ada1: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) Note that I'm getting occasional CRC errors with those disks, though I wasn't with some older disks. I haven't dug into whether the newer Seagate disks are fussier or the cable is marginal. I am seeing ~160MBps on one channel and 190MBps cumulative across both channels. >> Note that the WiFi/Bluetooth module for the RockPro64 uses SDIO, >> and the combination isn't yet supported by FreeBSD. > >Well, it would be nice to get it to working state... no idea how much >work that is. I wasn't interested in the WiFi so I didn't worry too much. See https://wiki.freebsd.org/SDIO for the latest information (though it may be out of date). --=20 Peter Jeremy --3WRfunwktL25iW3F Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQKTBAEBCgB9FiEE7rKYbDBnHnTmXCJ+FqWXoOSiCzQFAmC4gY1fFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEVF QjI5ODZDMzA2NzFFNzRFNjVDMjI3RTE2QTU5N0EwRTRBMjBCMzQACgkQFqWXoOSi CzRrlw/8DyFH5KHpNgFVN7XA8pI/CzIujbY90cKT8JE8KqgNkvQaRIb2a7T+6tNu WYiPCf8AC+dF77u6+fkyyWHab9VwY52QJcUY5kUpS1QCRX+L8pnqk2SVkDNwkuJJ fFXrxjKKouJb7tO8YFNvhFYY2LxSwg2o/CsRL7f4A61YoGaJ/YoSax3rz0ZqW+/5 SOmdku0ua/JkAeFMb3NrWJhmEWNCazHQ1LPPt5l6sqdDOxwky3UUJZ9db9PKxBmo lCF2goDSNT0qYJwkonKxJZ99WpZQS448OgaV6mbMELrOWQvvyf7JfqGxGC8S8+hH YffcAVAupIrGKONSihewvqctcvwAQpJSjAqb5TxGZEl9n6A/dqERuCzjyMqhqz3B 3Olp6VQMx3UwUAHX7tLN6/izWMw9+x2yy2lNHTRNKAvQo2VgTpPJCnoZZVz3o6Gb aRlpo4X/9XNkUPIa/3fzk66dzVu9045eQVliO2Xmi3vU0nk2bXSYkI/CpBUy7v37 snh3Qu4Vk+P5h6E4LzFQyaSY+XtKeJhMnU2FXOU5/3XKZ51/pzAaAO9CdUq8R0Tk hVsUFnZDEQqE9OvO28zeJy9tfbVltiaunRIBnOSaItALoSwSNiF8uuXlHXrOz3KH yAXhMm77jdc+ivR7+ujXSLc8XpmrskZFlSiVehi+jVtXrwE6FVc= =pP9m -----END PGP SIGNATURE----- --3WRfunwktL25iW3F-- From nobody Thu Jun 3 08:24:24 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 76C28137B30C for ; Thu, 3 Jun 2021 08:24:27 +0000 (UTC) (envelope-from soren.schmidt@gmail.com) Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [IPv6:2a00:1450:4864:20::32f]) (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 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Fwf7v2M4Tz4fCD for ; Thu, 3 Jun 2021 08:24:27 +0000 (UTC) (envelope-from soren.schmidt@gmail.com) Received: by mail-wm1-x32f.google.com with SMTP id l11-20020a05600c4f0bb029017a7cd488f5so3195571wmq.0 for ; Thu, 03 Jun 2021 01:24:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=NH3LK79Z4ynwLACvN+i8DqxanlvJsY4D5FaY5XYYRa8=; b=n//RFV666lJ7ofNoZitfu/FXqR0MHK5t0ENV88BwH5EOCHqvcN0kkEgCljyoAmzDZh Zpz1j96zJo0E9o+50+CbrGwlI2vLJeciM8V0FSdhbI67bSxFbVtLPNcl2yWp2wMTkCY9 K94TaUR9Nej6WdmV6hfoG+M/RD1cG9HAWaUZEHO8ugkhn89r0szZkIA/ivVvfxOcrlA0 t0nq2AfOoT3jRIoNtMmsaytY5OpC1LyWb1ycOY1iq0l+/qdezeK6QS38ASt5TM2xky+T 6toCym9p7OCPNiSi7e8BqNRkGxH4hbFUEyB372q2Bn28dms6xYUh5JbUhYlBEo4cRvT/ qw3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=NH3LK79Z4ynwLACvN+i8DqxanlvJsY4D5FaY5XYYRa8=; b=LYuA/geCmjTqqT/2p786VA6PK6iglM4iibai+awBLgSttBt5t7ZRVmmZhZMSEBoMD/ 2rpzLj3gD4dRSAtws0uvrLEXV4a5iX0qQzf4cm3kDdfGH3bOMyvwDxRZi5WufyMLCR6W mJ9N4R7xNfaoKWG/vu8MiLHdiYvXl1KRJYPePsXTzYqMYvJc2ScLuYKFx1gyww8oBk+s x5tZsYQlSg2/H/pkSWzHxqXMrjG0Wmsn8AgF2pDxUrhcCOQQwcSkhyqEZr5KUIppenK7 CWtGjHCOFZmOvSsmyUiccp3e1Onu5zahzkw4dST3ZfLfOG17b2KIBcRnidpjqJccyrQ6 CyiQ== X-Gm-Message-State: AOAM533GjaEw93SNYyHSgCThT/mZWEGl4a5Fv2huhl/O5mwbPQXHITQm UIWXms00EnVB2T92Ui1LhbCtp+ab5mI= X-Google-Smtp-Source: ABdhPJyZSAe0pewDFzwdoMfM7iH6CjEd7rLqOFRireUa5s3+dLcKn1nxw7R4xReX23g/UktSJBcJkw== X-Received: by 2002:a05:600c:4b88:: with SMTP id e8mr1167242wmp.107.1622708665977; Thu, 03 Jun 2021 01:24:25 -0700 (PDT) Received: from mac.deepcore.dk ([85.27.186.9]) by smtp.gmail.com with ESMTPSA id o6sm2770548wre.73.2021.06.03.01.24.25 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 Jun 2021 01:24:25 -0700 (PDT) From: =?utf-8?Q?S=C3=B8ren_Schmidt?= Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_DCEF6D96-9B3E-44A4-9FEF-E84E573FCFD1"; protocol="application/pgp-signature"; micalg=pgp-sha256 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 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) Subject: Re: Oversimplification Date: Thu, 3 Jun 2021 10:24:24 +0200 In-Reply-To: Cc: Milan Obuch , freebsd-arm@freebsd.org To: peter@rulingia.com References: <35728cba-0152-9b73-77f9-48683e870bbd@m5p.com> <20210603084647.24eeed35@zeta.dino.sk> X-Mailer: Apple Mail (2.3608.120.23.2.7) X-Rspamd-Queue-Id: 4Fwf7v2M4Tz4fCD X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: Y --Apple-Mail=_DCEF6D96-9B3E-44A4-9FEF-E84E573FCFD1 Content-Type: multipart/alternative; boundary="Apple-Mail=_CAFAD67D-0585-47CA-8DFA-2AF81C17AFEB" --Apple-Mail=_CAFAD67D-0585-47CA-8DFA-2AF81C17AFEB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 3 Jun 2021, at 09.15, Peter Jeremy via freebsd-arm = wrote: >=20 > On 2021-Jun-03 08:46:47 +0200, Milan Obuch = wrote: >>> I'll second Milan's followup. I have a 4GB RockPro64 with the >>> dual-SATA PCIe card and am quite happy with it. It also supports >>> both USB-3 and USB-C, though I haven't experimented with either. >>>=20 >>=20 >> Just out of curiosity - do you mean SATA card from pine64.org shop? = Was >> some extra steps required to make it work? Could you share relevant >> lines from dmesg output? >=20 > Yes, this was the pine64.org card - I've build a PineNAS, though I'm > still trying to work out how to set it up the way I want. The card > doesn't need any special configuration. Note that the RockPro64 > doesn't support booting from SATA. If you install u-boot to the SPI you can boot from any media, = SATA/NVMe/USB/SD/MMC. I have patches for the pinebook pro that also works for the rockpro64 = at: https://people.freebsd.org/~sos/PinebookPro/ = YMMV. -- S=C3=B8ren Schmidt sos@deepcore.dk / sos@freebsd.org "So much code to hack, so little time" --Apple-Mail=_CAFAD67D-0585-47CA-8DFA-2AF81C17AFEB-- --Apple-Mail=_DCEF6D96-9B3E-44A4-9FEF-E84E573FCFD1 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEkC0kEuD0Me2xEj5EGvRMAY4qbRsFAmC4kbgACgkQGvRMAY4q bRuNBQ//XVjfaeGLmzD2yz+jsQM2OPqkEH6CrN9FaHApUqTc0y/Ht3+EWCobSG7G e9iBPC0LUBwSurrK+Yi/30eAtIHEuxfszU8+c+oGeNXxrofM4poIihdpYmWb4TH9 kz+6gLQHG2KHHG9TenA970BHYV/9kBY1ypajG4bceaVR26OVkPm2eJ2QI0pmcgx/ oQJodDpAjskRFwgh/VWohbg637Y1+quv94rjHsm5nzJ6mXJ9p2Cmj5hnMit2YXIN +BWGphEkyLwmO3QGMYI8IO7IsR0n7qi/vzmEf/CeBQQ8enNWtNsbC6Q+MuaeISyn 1Tk6BOUljHLRpRRDgxrihkbY7Os3ubr3FIOIc1Wn7Wq4j+UBCHulK/6byVW6kJ/w rfL6LvXXqH2yNfmOsRu4uvCnT9gwchbesGQN/zyHor/aGCai4+Kn8jTJ3Ru/bNJs Z0RNaxnDk5tVCD8o5aAUURadoa58Mru4/u+2aclmFNm9tMdfiR1pbiTzOUzOGReW C1KLU46P6ZhoS2n3dX6lHfdnRbN6QA+s4N0Z34ZVuxElu1fxcWA7JGSTbZxw4nSv zmv2Hf4Izt9UNt6jpGcJheet5xFAThHxVWugIrDUMnPmBDUEpxkJ7ScGOf8MXOU4 AJCTqwayUdTxkH2/zv22d677CXruF7ouFV8Sjf587+kDv9oU2D0= =2guQ -----END PGP SIGNATURE----- --Apple-Mail=_DCEF6D96-9B3E-44A4-9FEF-E84E573FCFD1-- From nobody Thu Jun 3 17:55:50 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 F01BC1368F93 for ; Thu, 3 Jun 2021 17:56:04 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from mailhost.m5p.com (mailhost.m5p.com [74.104.188.4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "m5p.com", Issuer "R3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4FwtqS0Mnnz4SjH for ; Thu, 3 Jun 2021 17:56:03 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from [IPv6:2001:470:1f07:15ff::26] (court.m5p.com [IPv6:2001:470:1f07:15ff:0:0:0:26]) (authenticated bits=0) by mailhost.m5p.com (8.16.1/8.15.2) with ESMTPSA id 153Htp1p036837 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Thu, 3 Jun 2021 13:55:56 -0400 (EDT) (envelope-from george+freebsd@m5p.com) Subject: Re: Oversimplification To: freebsd-arm@freebsd.org References: <35728cba-0152-9b73-77f9-48683e870bbd@m5p.com> From: George Mitchell Message-ID: Date: Thu, 3 Jun 2021 13:55:50 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.9.1 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 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="9f1IzstVup9Skd3w9Z2U0qBe91SaroCYs" X-Spam-Status: No, score=0.2 required=10.0 tests=HELO_MISC_IP,HELO_NO_DOMAIN, NICE_REPLY_A autolearn=no autolearn_force=no version=3.4.5 X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on mattapan.m5p.com X-Rspamd-Queue-Id: 4FwtqS0Mnnz4SjH X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of george@m5p.com designates 74.104.188.4 as permitted sender) smtp.mailfrom=george@m5p.com X-Spamd-Result: default: False [-4.80 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+a]; HAS_ATTACHMENT(0.00)[]; TO_DN_NONE(0.00)[]; NEURAL_HAM_SHORT(-0.40)[-0.396]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~]; RBL_DBL_DONT_QUERY_IPS(0.00)[74.104.188.4:from]; ASN(0.00)[asn:701, ipnet:74.104.0.0/16, country:US]; MID_RHS_MATCH_FROM(0.00)[]; TAGGED_FROM(0.00)[freebsd]; R_DKIM_NA(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; DMARC_NA(0.00)[m5p.com]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[74.104.188.4:from:127.0.2.255]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-arm] X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --9f1IzstVup9Skd3w9Z2U0qBe91SaroCYs Content-Type: multipart/mixed; boundary="xJ9DMOt06DKaCnp1A6SYgMLV0lm9n4uYx"; protected-headers="v1" From: George Mitchell To: freebsd-arm@freebsd.org Message-ID: Subject: Re: Oversimplification References: <35728cba-0152-9b73-77f9-48683e870bbd@m5p.com> In-Reply-To: --xJ9DMOt06DKaCnp1A6SYgMLV0lm9n4uYx Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 6/3/21 2:20 AM, Peter Jeremy via freebsd-arm wrote: > On 2021-May-30 17:49:01 -0400, George Mitchell =20 wrote: >> I've never been shy about oversimplifying complex questions, so here >> goes: What's the ARM system that presents the least hassle to a >> prospective FreeBSD user? Here's what I mean by low hassle: >> >> 1. Widely available. >> 2. Runs some standard FreeBSD image with minimal (or no) tweaking. >> 3. I suspect ARM64 means less hassle than ARM32. >> 4. Friendly to an external high-speed (at least USB 3; possibly SATA?)= >> disk. >> 5. Hopefully 8GB on-board memory, though 4GB is probably okay if high >> speed swapping is available (see point 4). >> 6. Affordable, but not cheap. >=20 > I'll second Milan's followup. I have a 4GB RockPro64 with the > dual-SATA PCIe card and am quite happy with it. It also supports > both USB-3 and USB-C, though I haven't experimented with either. >=20 > Note that the WiFi/Bluetooth module for the RockPro64 uses SDIO, > and the combination isn't yet supported by FreeBSD. >=20 > I also have a BananaPi M1, which has an integral SATA port but I've > never managed to get the SATA to work. >=20 Thanks for the additional data point! -- George --xJ9DMOt06DKaCnp1A6SYgMLV0lm9n4uYx-- --9f1IzstVup9Skd3w9Z2U0qBe91SaroCYs Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsF5BAABCAAjFiEENdM4ZHktsJW5kKZXwRES3m+p4fkFAmC5F6YFAwAAAAAACgkQwRES3m+p4fla sA/+PCm6RIk6xwRimqUbNzQ2c4iNGVbNGmnVi64Pn9LhiocPortPWIwucPi/SnfODqGsMViysXde hdB82nQt3j3AOkpvyZ27zfDs/mhZzG9GtH86e3BxzsDs2Q3uyuVTm8jjC2J8OE6AGkbtK46dB/Fq krp+mWjLWnfi/FXN9OfzXI6Fn8eSL0KA8H7O14XNSN7+/yZ2OC5/Tf9W8m0pwEhmAoPS5u7b5OTp dpQlyEuEA6q7NEr2zRp2z5wHWfGaEVIp7zQuKVFGWb2eaQAAWC33mbvqjelo9j16OJWVeMQ/QRqj VIqXKsq0+3bYephnN5aOhu1LUoYW8Ywp6+181YtSXHbfKVog8u8LbU/b1eVm7mtLsh1a/41n19Gi WiEg5rEHx8m0qsJQ+977ClDIbnLRQSjB+OIeGEpHTNHqttKgM3fN1gNyqGyuHItkC7pSUEbEIs65 RrTT4TgCi90C3TzSvVRCEaqUP9iM8ycdhaEgKBMjhEcE8z+2zeyA8v0m3Jy9ZZRBPS/E1NqiSd3h BRm9tV1867/nmVHsACbECxmmTrtEENlttr2sLw5Zt++KpcBUFtjheyBbp1lhl7CD7J1myB5ZSiAq m7XeX+qBKzzqCYyGLj7W6iO6xzXk3s8asfDUDHcHWhO7wFjEYh2+EP66rKGF+ZMywEJ8HKkdjKGf 5gg= =yF9F -----END PGP SIGNATURE----- --9f1IzstVup9Skd3w9Z2U0qBe91SaroCYs-- From nobody Thu Jun 3 22:28:20 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 BEFAB1377809 for ; Thu, 3 Jun 2021 22:28:23 +0000 (UTC) (envelope-from daniel.engberg.lists@pyret.net) Received: from relay10.mail.gandi.net (relay10.mail.gandi.net [217.70.178.230]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Fx0sf6CXvz4t4D for ; Thu, 3 Jun 2021 22:28:22 +0000 (UTC) (envelope-from daniel.engberg.lists@pyret.net) Received: (Authenticated sender: daniel.engberg@pyret.net) by relay10.mail.gandi.net (Postfix) with ESMTPA id 86699240002; Thu, 3 Jun 2021 22:28:20 +0000 (UTC) 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 Date: Fri, 04 Jun 2021 00:28:20 +0200 From: Daniel Engberg To: freebsd-arm@freebsd.org Subject: Re: Oversimplification User-Agent: Roundcube Webmail/1.4.11 Message-ID: <14923973029d7e187967e4c74bcffe26@pyret.net> X-Sender: daniel.engberg.lists@pyret.net Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4Fx0sf6CXvz4t4D X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of daniel.engberg.lists@pyret.net designates 217.70.178.230 as permitted sender) smtp.mailfrom=daniel.engberg.lists@pyret.net X-Spamd-Result: default: False [-2.40 / 15.00]; FAKE_REPLY(1.00)[]; ARC_NA(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[217.70.178.230:from]; FROM_HAS_DN(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[217.70.178.230:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:217.70.178.192/26]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[pyret.net]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[217.70.178.230:from:127.0.2.255]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:29169, ipnet:217.70.176.0/20, country:FR]; MID_RHS_MATCH_FROM(0.00)[]; MAILMAN_DEST(0.00)[freebsd-arm]; RCVD_IN_DNSWL_LOW(-0.10)[217.70.178.230:from] X-ThisMailContainsUnwantedMimeParts: N Hi, Just wanted to point out that there's is a small PCIe compatibility table over at the wiki page and you're free to contribute. I have ASM1166 card laying here (https://www.silverstonetek.com/product.php?pid=973&area=en) but due to lack of time I haven't been able to test it out yet. https://wiki.freebsd.org/arm/RockChip#Tested_PCIe_devices_on_RockPro64 Regarding Pine64s 2-port SATA card you probably want to look for something newer using the ASM1062 chipset (at least). Best regards, Daniel From nobody Fri Jun 4 11:07:38 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 CC25613AC3FC for ; Fri, 4 Jun 2021 11:07:49 +0000 (UTC) (envelope-from kiri@truefc.org) Received: from kx.truefc.org (1.212.52.36.ap.yournet.ne.jp [36.52.212.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 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", Issuer "smtp" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4FxKjv60DTz3F9l for ; Fri, 4 Jun 2021 11:07:47 +0000 (UTC) (envelope-from kiri@truefc.org) Received: from kx.truefc.org (kx.truefc.org [36.52.212.1]) by kx.truefc.org (8.16.1/8.16.1) with ESMTP id 154B7cQD087733; Fri, 4 Jun 2021 20:07:38 +0900 (JST) (envelope-from kiri@kx.truefc.org) Message-Id: <202106041107.154B7cQD087733@kx.truefc.org> Date: Fri, 04 Jun 2021 20:07:38 +0900 From: KIRIYAMA Kazuhiko To: freebsd-arm@freebsd.org Cc: kiri@truefc.org Subject: Can't enable SDIO wifi module on PBP User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 MULE XEmacs/21.4 (patch 24) (Standard C) (amd64--freebsd) 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 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 4FxKjv60DTz3F9l X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of kiri@truefc.org designates 36.52.212.1 as permitted sender) smtp.mailfrom=kiri@truefc.org X-Spamd-Result: default: False [-3.10 / 15.00]; ARC_NA(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[36.52.212.1:from]; FREEFALL_USER(0.00)[kiri]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:36.52.212.0/29]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[truefc.org]; SPAMHAUS_ZRD(0.00)[36.52.212.1:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; RCVD_COUNT_ONE(0.00)[1]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:10013, ipnet:36.52.208.0/21, country:JP]; MAILMAN_DEST(0.00)[freebsd-arm]; ONCE_RECEIVED(0.10)[] X-ThisMailContainsUnwantedMimeParts: N Hi, all I've reconfigured kernel to GENERIC-MMCCAM on Pinebook Pro (PBP) to use SDIO wifi module Broadcom BCM43456 (AMPAK AP6256 [1]). But nothing SDIO module found : root@kazu:~ # camcontrol devlist -v scbus0 on dw_mmc_sim0 bus 0: scbus1 on dw_mmc_sim1 bus 0: scbus2 on sdhci_slot0 bus 0: at scbus2 target 0 lun 0 (pass0,sdda0) scbus-1 on xpt0 bus 0: <> at scbus-1 target -1 lun ffffffff (xpt0) root@kazu:~ # My environments are as follows : root@kazu:~ # uname -a FreeBSD kazu.tfc 14.0-CURRENT FreeBSD 14.0-CURRENT #0 n246349-daa5350d0e0c: Wed Jun 2 17:01:11 JST 2021 root@tbedfc:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC-MMCCAM arm64 root@kazu:~ # cat /var/run/dmesg.boot ---<>--- GDB: debug ports: uart GDB: current port: uart KDB: debugger backends: ddb gdb KDB: current backend: ddb WARNING: Cannot find freebsd,dts-version property, cannot check DTB compliance Copyright (c) 1992-2021 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 14.0-CURRENT #0 n246349-daa5350d0e0c: Wed Jun 2 17:01:11 JST 2021 root@tbedfc:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC-MMCCAM arm64 FreeBSD clang version 11.0.1 (git@github.com:llvm/llvm-project.git llvmorg-11.0.1-0-g43ff75f2c3fe) WARNING: WITNESS option enabled, expect reduced performance. VT(efifb): resolution 1920x1080 module firmware already present! real memory = 4158373888 (3965 MB) avail memory = 4025626624 (3839 MB) Starting CPU 1 (1) Starting CPU 2 (2) Starting CPU 3 (3) Starting CPU 4 (100) Starting CPU 5 (101) FreeBSD/SMP: Multiprocessor System Detected: 6 CPUs random: unblocking device. random: entropy device external interface MAP f3f16000 mode 2 pages 4 MAP f3f1b000 mode 2 pages 4 MAP f6f40000 mode 2 pages 16 WARNING: Device "kbd" is Giant locked and may be deleted before FreeBSD 14.0. kbd0 at kbdmux0 WARNING: Device "openfirm" is Giant locked and may be deleted before FreeBSD 14.0. ofwbus0: clk_fixed0: on ofwbus0 simplebus0: on ofwbus0 rk_grf0: mem 0xff320000-0xff320fff on ofwbus0 rk3399_pmucru0: mem 0xff750000-0xff750fff on ofwbus0 rk3399_cru0: mem 0xff760000-0xff760fff on ofwbus0 rk_grf1: mem 0xff770000-0xff77ffff on ofwbus0 regfix0: on ofwbus0 regfix1: on ofwbus0 regfix2: on ofwbus0 regfix3: on ofwbus0 regfix4: on ofwbus0 regfix5: on ofwbus0 regfix6: on ofwbus0 regfix7: on ofwbus0 regfix8: on ofwbus0 regfix9: on ofwbus0 regfix10: on ofwbus0 regfix11: on ofwbus0 simple_mfd0: mem 0xff310000-0xff310fff on ofwbus0 psci0: on ofwbus0 gic0: mem 0xfee00000-0xfee0ffff,0xfef00000-0xfefbffff,0xfff00000-0xfff0ffff,0xfff10000-0xfff1ffff,0xfff20000-0xfff2ffff irq 18 on ofwbus0 its0: mem 0xfee20000-0xfee3ffff on gic0 rk_iodomain0: mem 0-0xff31ffff,0-0xfff on rk_grf0 rk_iodomain1: mem 0-0xff76ffff,0-0xffff on rk_grf1 rk_pinctrl0: on ofwbus0 gpio0: mem 0xff720000-0xff7200ff irq 71 on rk_pinctrl0 gpiobus0: on gpio0 gpio1: mem 0xff730000-0xff7300ff irq 72 on rk_pinctrl0 gpiobus1: on gpio1 gpio2: mem 0xff780000-0xff7800ff irq 73 on rk_pinctrl0 gpiobus2: on gpio2 gpio3: mem 0xff788000-0xff7880ff irq 74 on rk_pinctrl0 gpiobus3: on gpio3 gpio4: mem 0xff790000-0xff7900ff irq 75 on rk_pinctrl0 gpiobus4: on gpio4 rk_i2c0: mem 0xff110000-0xff110fff irq 20 on ofwbus0 iicbus0: on rk_i2c0 rk_i2c1: mem 0xff130000-0xff130fff irq 22 on ofwbus0 iicbus1: on rk_i2c1 rk_i2c2: mem 0xff3c0000-0xff3c0fff irq 38 on ofwbus0 iicbus2: on rk_i2c2 syr8270: at addr 0x80 on iicbus2 rk_i2c3: mem 0xff3d0000-0xff3d0fff irq 39 on ofwbus0 iicbus3: on rk_i2c3 rk805_pmu0: at addr 0x36 irq 76 on iicbus2 generic_timer0: irq 2,3,4,5 on ofwbus0 Timecounter "ARM MPCore Timecounter" frequency 24000000 Hz quality 1000 Event timer "ARM MPCore Eventtimer" frequency 24000000 Hz quality 1000 rk_tsadc0: mem 0xff260000-0xff2600ff irq 35 on ofwbus0 rk_usb2phy0: mem 0-0xff76ffff,0-0xffff on rk_grf1 rk_usb2phy1: mem 0-0xff76ffff,0-0xffff on rk_grf1 rk_emmcphy0: mem 0-0xff76ffff,0-0xffff on rk_grf1 rk_pcie_phy0: mem 0-0xff76ffff,0-0xffff on rk_grf1 rk_typec_phy0: mem 0xff7c0000-0xff7fffff on ofwbus0 rk_typec_phy1: mem 0xff800000-0xff83ffff on ofwbus0 cpulist0: on ofwbus0 cpu0: on cpulist0 cpufreq_dt0: on cpu0 cpu1: on cpulist0 cpufreq_dt1: on cpu1 cpu2: on cpulist0 cpufreq_dt2: on cpu2 cpu3: on cpulist0 cpufreq_dt3: on cpu3 cpu4: on cpulist0 cpufreq_dt4: on cpu4 cpu5: on cpulist0 cpufreq_dt5: on cpu5 pmu0: irq 0 on ofwbus0 pmu1: irq 1 on ofwbus0 pcib0: mem 0xf8000000-0xf9ffffff,0xfd000000-0xfdffffff irq 6,7,8 on ofwbus0 pcib0: Gen1 link training timeouted: 0x00080001. pci0: on pcib0 pcib1: at device 0.0 on pci0 pcib0: failed to reserve resource for pcib1 pcib1: failed to allocate initial memory window: 0-0xfffff pci1: on pcib1 rockchip_dwmmc0: mem 0xfe310000-0xfe313fff irq 10 on ofwbus0 rockchip_dwmmc0: Hardware version ID is 270a rockchip_dwmmc1: mem 0xfe320000-0xfe323fff irq 11 on ofwbus0 rockchip_dwmmc1: Hardware version ID is 270a sdhci_fdt0: mem 0xfe330000-0xfe33ffff irq 12 on ofwbus0 rk_emmcphy0: got emmcclk clock sdhci_fdt0-slot0: Hardware doesn't specify timeout clock frequency, setting BROKEN_TIMEOUT quirk. sdhci_fdt0: 1 slot(s) allocated uma_zalloc_debug: zone "malloc-2048" with the following non-sleepable locks held: exclusive sleep mutex SD slot mtx (sdhci) r = 0 (0xffff0000411c6030) locked @ /usr/src/sys/dev/sdhci/sdhci.c:617 stack backtrace: #0 0xffff0000004d819c at witness_debugger+0x64 #1 0xffff0000004d9320 at witness_warn+0x3e8 #2 0xffff0000006f9084 at uma_zalloc_debug+0x2c #3 0xffff0000006f8a8c at uma_zalloc_arg+0x2c #4 0xffff00000043fa18 at malloc+0xa0 #5 0xffff00000000f550 at xpt_alloc_ccb+0x1c #6 0xffff000000034ee0 at mmccam_start_discovery+0x18 #7 0xffff0000002506fc at sdhci_card_task+0x110 #8 0xffff000000255460 at sdhci_fdt_attach+0x5b4 #9 0xffff0000004a3b34 at device_attach+0x400 #10 0xffff0000004a369c at device_probe_and_attach+0x7c #11 0xffff0000004a5880 at bus_generic_new_pass+0xf8 #12 0xffff0000004a5830 at bus_generic_new_pass+0xa8 #13 0xffff0000004a5830 at bus_generic_new_pass+0xa8 #14 0xffff0000004a0ae0 at bus_set_pass+0x4c #15 0xffff0000003f644c at mi_startup+0x12c #16 0xffff0000000008a8 at virtdone+0x6c ehci0: mem 0xfe380000-0xfe39ffff irq 13 on ofwbus0 usbus0: EHCI version 1.0 usbus0 on ehci0 ohci0: mem 0xfe3a0000-0xfe3bffff irq 14 on ofwbus0 usbus1 on ohci0 ehci1: mem 0xfe3c0000-0xfe3dffff irq 15 on ofwbus0 usbus2: EHCI version 1.0 usbus2 on ehci1 ohci1: mem 0xfe3e0000-0xfe3fffff irq 16 on ofwbus0 usbus3 on ohci1 rk_dwc30: on ofwbus0 xhci0: mem 0xfe800000-0xfe8fffff irq 77 on rk_dwc30 xhci0: 64 bytes context size, 32-bit DMA usbus4: trying to attach usbus4 on xhci0 rk_dwc31: on ofwbus0 xhci1: mem 0xfe900000-0xfe9fffff irq 78 on rk_dwc31 xhci1: 64 bytes context size, 32-bit DMA usbus5: trying to attach usbus5 on xhci1 iicbus0: at addr 0x22 iic0: on iicbus0 iic1: on iicbus1 uart0: mem 0xff180000-0xff1800ff irq 26 on ofwbus0 uart0: debug port (-1,n,8,1) uart1: <16750 or compatible> mem 0xff1a0000-0xff1a00ff irq 28 on ofwbus0 uart1: console (1500000,n,8,1) spi0: mem 0xff1d0000-0xff1d0fff irq 31 on ofwbus0 spibus0: on spi0 spibus0: at cs 0 mode 0 iicbus2: at addr 0x82 iic2: on iicbus2 iicbus3: at addr 0x44 iic3: on iicbus3 pwm0: mem 0xff420000-0xff42000f on ofwbus0 pwmbus0: on pwm0 pwmc0: channel 0 on pwmbus0 pwm1: mem 0xff420020-0xff42002f on ofwbus0 pwmbus1: on pwm1 pwmc1: channel 0 on pwmbus1 gpioc0: on gpio0 gpioc1: on gpio1 gpioc2: on gpio2 gpioc3: on gpio3 gpioc4: on gpio4 gpioled0: on ofwbus0 armv8crypto0: Timecounters tick every 1.000 msec usbus0: 480Mbps High Speed USB v2.0 usbus1: 12Mbps Full Speed USB v1.0 rk805_pmu0: registered as a time-of-day clock, resolution 1.000000s Release APs...done usbus2: 480Mbps High Speed USB v2.0 CPU 0: ARM Cortex-A53 r0p4 affinity: 0 0 usbus3: 12Mbps Full Speed USB v1.0 Cache Type = <64 byte D-cacheline,64 byte I-cacheline,VIPT ICache,64 byte ERG,64 byte CWG> usbus4: 5.0Gbps Super Speed USB v3.0 Instruction Set Attributes 0 = usbus5: 5.0Gbps Super Speed USB v3.0 Instruction Set Attributes 1 = <> (noperiph:dw_mmc_sim0:0:-1:ffffffff): Processor Features 0 = Processor Features 1 = <> Memory Model Features 0 = Memory Model Features 1 = <8bit VMID> Memory Model Features 2 = <32bit CCIDX,48bit VA> Debug Features 0 = <2 CTX BKPTs,4 Watchpoints,6 Breakpoints,PMUv3,Debugv8> Debug Features 1 = <> Auxiliary Features 0 = <> Auxiliary Features 1 = <> CPU 1: ARM Cortex-A53 r0p4 affinity: 0 1 Cache Type = <64 byte D-cacheline,64 byte I-cacheline,VIPT ICache,64 byte ERG,64 byte CWG> Memory Model Features 0 = CPU 2: ARM Cortex-A53 r0p4 affinity: 0 2 Cache Type = <64 byte D-cacheline,64 byte I-cacheline,VIPT ICache,64 byte ERG,64 byte CWG> Memory Model Features 0 = CPU 3: ARM Cortex-A53 r0p4 affinity: 0 3 Cache Type = <64 byte D-cacheline,64 byte I-cacheline,VIPT ICache,64 byte ERG,64 byte CWG> Memory Model Features 0 = CPU 4: ARM Cortex-A72 r0p2 affinity: 1 0 Cache Type = <64 byte D-cacheline,64 byte I-cacheline,PIPT ICache,64 byte ERG,64 byte CWG> Memory Model Features 0 = CPU 5: ARM Cortex-A72 r0p2 affinity: 1 1 Cache Type = <64 byte D-cacheline,64 byte I-cacheline,PIPT ICache,64 byte ERG,64 byte CWG> Memory Model Features 0 = XPT_SCAN_{BUS,TGT,LUN} (noperiph:dw_mmc_sim0:0:0:0): XPT_SCAN_{BUS,TGT,LUN} (noperiph:dw_mmc_sim0:0:0:0): ugen4.1: at usbus4 Set up the mmcprobe device... ugen0.1: at usbus0 (mmcprobe0:dw_mmc_sim0:0:0:0): ugen3.1: at usbus3 Periph created ugen1.1: at usbus1 ugen5.1: at usbus5 ugen2.1: at usbus2 (mmcprobe0:dw_mmc_sim0:0:0:0): sysctl_warn_reuse: can't re-use a leaf (dev.uhub.%parent)! sysctl_warn_reuse: can't re-use a leaf (dev.uhub.%parent)! sysctl_warn_reuse: can't re-use a leaf (dev.uhub.%parent)! sysctl_warn_reuse: can't re-use a leaf (dev.uhub.%parent)! sysctl_warn_reuse: can't re-use a leaf (dev.uhub.%parent)! uhub1 on usbus0 uhub5 on usbus2 uhub1: on usbus0 uhub5: on usbus2 uhub4Probe started on usbus5 (mmcprobe0:dw_mmc_sim0:0:0:0): uhub2Probe PROBE_INVALID to PROBE_RESET on usbus3 (mmcprobe0:dw_mmc_sim0:0:0:0): uhub3mmcprobe_start on usbus1 uhub2: on usbus3 (mmcprobe0:dw_mmc_sim0:0:0:0): uhub4: on usbus5 Trying to mount root from ufs:/dev/mmcsd0p3 [rw]... Start with PROBE_RESET uhub3: on usbus1 (mmcprobe0:dw_mmc_sim0:0:0:0): Root mount waiting for:uhub0Start with PROBE_IDENTIFY CAM usbus0 usbus1 on usbus4 usbus2uhub0: on usbus4 usbus3 usbus4 usbus5 WARNING: WITNESS option enabled, expect reduced performance. Unresolved linked clock found: clkin_gmac lock order reversal: (sleepable after non-sleepable) 1st 0xffffa00001026558 dwmmcsim (dwmmcsim, sleep mutex) @ /usr/src/sys/cam/cam_xpt.c:2802 2nd 0xffff000000c12a30 Clock topology lock (Clock topology lock, sx) @ /usr/src/sys/dev/extres/clk/clk.c:1154 lock order dwmmcsim -> Clock topology lock attempted at: #0 0xffff0000004d7e7c at witness_checkorder+0xc50 #1 0xffff0000004743e8 at _sx_xlock+0x7c #2 0xffff0000001ac808 at clk_set_freq+0x4c #3 0xffff00000078a998 at dwmmc_rockchip_update_ios+0x3c #4 0xffff00000078a3bc at dwmmc_update_ios+0xfc #5 0xffff000000789854 at dwmmc_cam_action+0x14c #6 0xffff000000009c34 at xpt_action_default+0xca8 #7 0xffff000000008f5c at xpt_action+0x270 #8 0xffff00000003633c at mmcprobe_start+0x89c #9 0xffff00000000cc10 at xpt_run_allocq+0x104 #10 0xffff00000000cadc at xpt_schedule+0x230 #11 0xffff000000035a78 at mmcprobe_register+0x2a4 #12 0xffff000000003b90 at cam_periph_alloc+0x528 #13 0xffff0000000354dc at mmc_action+0x484 #14 0xffff000000008f5c at xpt_action+0x270 #15 0xffff000000011750 at xpt_scanner_thread+0xcc #16 0xffff000000424198 at fork_exit+0x74 #17 0xffff00000076716c at fork_trampoline+0x14 uhub3: 1 port with 1 removable, self powered (mmcprobe0:dw_mmc_sim0:0:0:0): uhub2: 1 port with 1 removable, self powered Send first XPT_MMC_IO (noperiph:dw_mmc_sim1:0:-1:ffffffff): XPT_SCAN_{BUS,TGT,LUN} (noperiph:dw_mmc_sim1:0:0:0): (mmcprobe0:dw_mmc_sim0:0:0:0): XPT_SCAN_{BUS,TGT,LUN} done with PROBE_RESET (noperiph:dw_mmc_sim1:0:0:0): (mmcprobe0:dw_mmc_sim0:0:0:0): Set up the mmcprobe device... Probe PROBE_RESET to PROBE_SEND_IF_COND (mmcprobe1:dw_mmc_sim1:0:0:0): (mmcprobe0:dw_mmc_sim0:0:0:0): Periph created mmcprobe_done: remaining freeze count 0 (mmcprobe1:dw_mmc_sim1:0:0:0): (mmcprobe0:dw_mmc_sim0:0:0:0): Probe started mmcprobe_start (mmcprobe0:dw_mmc_sim0:0:0:0): (mmcprobe1:dw_mmc_sim1:0:0:0): Start with PROBE_SEND_IF_COND Probe PROBE_INVALID to PROBE_RESET (mmcprobe1:dw_mmc_sim1:0:0:0): mmcprobe_start (mmcprobe1:dw_mmc_sim1:0:0:0): Start with PROBE_RESET (mmcprobe0:dw_mmc_sim0:0:0:0): (mmcprobe1:dw_mmc_sim1:0:0:0): IF_COND: error 1, pattern 00000000 Start with PROBE_IDENTIFY (mmcprobe0:dw_mmc_sim0:0:0:0): Probe PROBE_SEND_IF_COND to PROBE_SDIO_RESET (mmcprobe0:dw_mmc_sim0:0:0:0): mmcprobe_done: remaining freeze count 0 (mmcprobe0:dw_mmc_sim0:0:0:0): mmcprobe_start (mmcprobe0:dw_mmc_sim0:0:0:0): Start with PROBE_SDIO_RESET (mmcprobe0:dw_mmc_sim0:0:0:0): SDIO_RESET: error 1, CCCR CTL register: 00000000 (mmcprobe0:dw_mmc_sim0:0:0:0): Probe PROBE_SDIO_RESET to PROBE_SDIO_INIT (mmcprobe0:dw_mmc_sim0:0:0:0): mmcprobe_done: remaining freeze count 0 (mmcprobe0:dw_mmc_sim0:0:0:0): mmcprobe_start (mmcprobe0:dw_mmc_sim0:0:0:0): Start with PROBE_SDIO_INIT (mmcprobe0:dw_mmc_sim0:0:0:0): SDIO_INIT: error 1, 00000000 00000000 00000000 00000000 (mmcprobe0:dw_mmc_sim0:0:0:0): Probe PROBE_SDIO_INIT to PROBE_SEND_APP_OP_COND (mmcprobe0:dw_mmc_sim0:0:0:0): mmcprobe_done: remaining freeze count 0 (mmcprobe0:dw_mmc_sim0:0:0:0): mmcprobe_start (mmcprobe0:dw_mmc_sim0:0:0:0): APP_OP_COND: error 1, resp 00000000 (mmcprobe0:dw_mmc_sim0:0:0:0): Probe PROBE_SEND_APP_OP_COND to PROBE_MMC_INIT (mmcprobe0:dw_mmc_sim0:0:0:0): mmcprobe_done: remaining freeze count 0 (mmcprobe0:dw_mmc_sim0:0:0:0): mmcprobe_start (mmcprobe0:dw_mmc_sim0:0:0:0): Start with PROBE_MMC_INIT (mmcprobe0:dw_mmc_sim0:0:0:0): MMC_INIT: error 1, resp 00000000 (mmcprobe0:dw_mmc_sim0:0:0:0): Probe PROBE_MMC_INIT to PROBE_INVALID (mmcprobe0:dw_mmc_sim0:0:0:0): mmcprobe_done: remaining freeze count 0 (mmcprobe0:dw_mmc_sim0:0:0:0): Periph invalidated (mmcprobe0:dw_mmc_sim0:0:0:0): Periph destroyed uhub0: 2 ports with 2 removable, self powered uhub4: 2 ports with 2 removable, self powered (mmcprobe1:dw_mmc_sim1:0:0:0): Send first XPT_MMC_IO (noperiph:sdhci_slot0:0:-1:ffffffff): XPT_SCAN_{BUS,TGT,LUN} (mmcprobe1:dw_mmc_sim1:0:0:0): (noperiph:sdhci_slot0:0:0:0): done with PROBE_RESET XPT_SCAN_{BUS,TGT,LUN} (noperiph:sdhci_slot0:0:0:0): (mmcprobe1:dw_mmc_sim1:0:0:0): Set up the mmcprobe device... Probe PROBE_RESET to PROBE_SEND_IF_COND (mmcprobe0:sdhci_slot0:0:0:0): (mmcprobe1:dw_mmc_sim1:0:0:0): Periph created (mmcprobe0:sdhci_slot0:0:0:0): mmcprobe_done: remaining freeze count 0 Probe started (mmcprobe1:dw_mmc_sim1:0:0:0): (mmcprobe0:sdhci_slot0:0:0:0): mmcprobe_start (mmcprobe1:dw_mmc_sim1:0:0:0): Probe PROBE_INVALID to PROBE_RESET Start with PROBE_SEND_IF_COND (mmcprobe0:sdhci_slot0:0:0:0): mmcprobe_start (mmcprobe0:sdhci_slot0:0:0:0): Start with PROBE_RESET (mmcprobe0:sdhci_slot0:0:0:0): (mmcprobe1:dw_mmc_sim1:0:0:0): Start with PROBE_IDENTIFY IF_COND: error 1, pattern 00000000 (mmcprobe1:dw_mmc_sim1:0:0:0): Probe PROBE_SEND_IF_COND to PROBE_SDIO_RESET (mmcprobe1:dw_mmc_sim1:0:0:0): mmcprobe_done: remaining freeze count 0 (mmcprobe1:dw_mmc_sim1:0:0:0): mmcprobe_start (mmcprobe1:dw_mmc_sim1:0:0:0): Start with PROBE_SDIO_RESET (mmcprobe1:dw_mmc_sim1:0:0:0): SDIO_RESET: error 1, CCCR CTL register: 00000000 (mmcprobe1:dw_mmc_sim1:0:0:0): Probe PROBE_SDIO_RESET to PROBE_SDIO_INIT (mmcprobe1:dw_mmc_sim1:0:0:0): mmcprobe_done: remaining freeze count 0 (mmcprobe1:dw_mmc_sim1:0:0:0): mmcprobe_start (mmcprobe1:dw_mmc_sim1:0:0:0): Start with PROBE_SDIO_INIT (mmcprobe1:dw_mmc_sim1:0:0:0): SDIO_INIT: error 1, 00000000 00000000 00000000 00000000 (mmcprobe1:dw_mmc_sim1:0:0:0): Probe PROBE_SDIO_INIT to PROBE_SEND_APP_OP_COND (mmcprobe1:dw_mmc_sim1:0:0:0): mmcprobe_done: remaining freeze count 0 (mmcprobe1:dw_mmc_sim1:0:0:0): mmcprobe_start (mmcprobe1:dw_mmc_sim1:0:0:0): APP_OP_COND: error 1, resp 00000000 (mmcprobe1:dw_mmc_sim1:0:0:0): Probe PROBE_SEND_APP_OP_COND to PROBE_MMC_INIT (mmcprobe1:dw_mmc_sim1:0:0:0): mmcprobe_done: remaining freeze count 0 (mmcprobe1:dw_mmc_sim1:0:0:0): mmcprobe_start (mmcprobe1:dw_mmc_sim1:0:0:0): Start with PROBE_MMC_INIT (mmcprobe1:dw_mmc_sim1:0:0:0): MMC_INIT: error 1, resp 00000000 (mmcprobe1:dw_mmc_sim1:0:0:0): Probe PROBE_MMC_INIT to PROBE_INVALID (mmcprobe1:dw_mmc_sim1:0:0:0): mmcprobe_done: remaining freeze count 0 (mmcprobe1:dw_mmc_sim1:0:0:0): Periph invalidated (mmcprobe1:dw_mmc_sim1:0:0:0): Periph destroyed uhub5: 1 port with 1 removable, self powered uhub1: 1 port with 1 removable, self powered (mmcprobe0:sdhci_slot0:0:0:0): Send first XPT_MMC_IO (mmcprobe0:sdhci_slot0:0:0:0): done with PROBE_RESET (mmcprobe0:sdhci_slot0:0:0:0): Probe PROBE_RESET to PROBE_SEND_IF_COND (mmcprobe0:sdhci_slot0:0:0:0): mmcprobe_done: remaining freeze count 0 (mmcprobe0:sdhci_slot0:0:0:0): mmcprobe_start (mmcprobe0:sdhci_slot0:0:0:0): Start with PROBE_SEND_IF_COND (mmcprobe0:sdhci_slot0:0:0:0): IF_COND: error 1, pattern 00000000 (mmcprobe0:sdhci_slot0:0:0:0): Probe PROBE_SEND_IF_COND to PROBE_SDIO_RESET (mmcprobe0:sdhci_slot0:0:0:0): mmcprobe_done: remaining freeze count 0 (mmcprobe0:sdhci_slot0:0:0:0): mmcprobe_start (mmcprobe0:sdhci_slot0:0:0:0): Start with PROBE_SDIO_RESET (mmcprobe0:sdhci_slot0:0:0:0): SDIO_RESET: error 1, CCCR CTL register: 00000000 (mmcprobe0:sdhci_slot0:0:0:0): Probe PROBE_SDIO_RESET to PROBE_SDIO_INIT (mmcprobe0:sdhci_slot0:0:0:0): mmcprobe_done: remaining freeze count 0 (mmcprobe0:sdhci_slot0:0:0:0): mmcprobe_start (mmcprobe0:sdhci_slot0:0:0:0): Start with PROBE_SDIO_INIT (mmcprobe0:sdhci_slot0:0:0:0): SDIO_INIT: error 1, 00000000 00000000 00000000 00000000 (mmcprobe0:sdhci_slot0:0:0:0): Probe PROBE_SDIO_INIT to PROBE_SEND_APP_OP_COND (mmcprobe0:sdhci_slot0:0:0:0): mmcprobe_done: remaining freeze count 0 (mmcprobe0:sdhci_slot0:0:0:0): mmcprobe_start (mmcprobe0:sdhci_slot0:0:0:0): APP_OP_COND: error 1, resp 00000000 (mmcprobe0:sdhci_slot0:0:0:0): Probe PROBE_SEND_APP_OP_COND to PROBE_MMC_INIT (mmcprobe0:sdhci_slot0:0:0:0): mmcprobe_done: remaining freeze count 0 (mmcprobe0:sdhci_slot0:0:0:0): mmcprobe_start (mmcprobe0:sdhci_slot0:0:0:0): Start with PROBE_MMC_INIT (mmcprobe0:sdhci_slot0:0:0:0): MMC card, OCR 40ff8080 (mmcprobe0:sdhci_slot0:0:0:0): -> sending OCR to card (mmcprobe0:sdhci_slot0:0:0:0): mmcprobe_done: remaining freeze count 0 (mmcprobe0:sdhci_slot0:0:0:0): mmcprobe_start (mmcprobe0:sdhci_slot0:0:0:0): Start with PROBE_MMC_INIT (mmcprobe0:sdhci_slot0:0:0:0): MMC card, OCR 40ff8080 (mmcprobe0:sdhci_slot0:0:0:0): Card is still powering up (mmcprobe0:sdhci_slot0:0:0:0): mmcprobe_done: remaining freeze count 0 (mmcprobe0:sdhci_slot0:0:0:0): mmcprobe_start (mmcprobe0:sdhci_slot0:0:0:0): Start with PROBE_MMC_INIT (mmcprobe0:sdhci_slot0:0:0:0): MMC card, OCR 40ff8080 (mmcprobe0:sdhci_slot0:0:0:0): Card is still powering up (mmcprobe0:sdhci_slot0:0:0:0): mmcprobe_done: remaining freeze count 0 (mmcprobe0:sdhci_slot0:0:0:0): mmcprobe_start (mmcprobe0:sdhci_slot0:0:0:0): Start with PROBE_MMC_INIT (mmcprobe0:sdhci_slot0:0:0:0): MMC card, OCR c0ff8080 (mmcprobe0:sdhci_slot0:0:0:0): Probe PROBE_MMC_INIT to PROBE_GET_CID (mmcprobe0:sdhci_slot0:0:0:0): mmcprobe_done: remaining freeze count 0 (mmcprobe0:sdhci_slot0:0:0:0): mmcprobe_start (mmcprobe0:sdhci_slot0:0:0:0): CID 45010044413431323801ad0efc3e3600 (mmcprobe0:sdhci_slot0:0:0:0): Probe PROBE_GET_CID to PROBE_MMC_SET_RELATIVE_ADDR (mmcprobe0:sdhci_slot0:0:0:0): mmcprobe_done: remaining freeze count 0 (mmcprobe0:sdhci_slot0:0:0:0): mmcprobe_start (mmcprobe0:sdhci_slot0:0:0:0): Probe PROBE_MMC_SET_RELATIVE_ADDR to PROBE_GET_CSD (mmcprobe0:sdhci_slot0:0:0:0): mmcprobe_done: remaining freeze count 0 (mmcprobe0:sdhci_slot0:0:0:0): mmcprobe_start (mmcprobe0:sdhci_slot0:0:0:0): CSD d00f00328f5903ffffffffef8a404000 (mmcprobe0:sdhci_slot0:0:0:0): Probe PROBE_GET_CSD to PROBE_SELECT_CARD (mmcprobe0:sdhci_slot0:0:0:0): mmcprobe_done: remaining freeze count 0 (mmcprobe0:sdhci_slot0:0:0:0): mmcprobe_start (mmcprobe0:sdhci_slot0:0:0:0): Probe PROBE_SELECT_CARD to PROBE_DONE (mmcprobe0:sdhci_slot0:0:0:0): mmcprobe_done: remaining freeze count 0 (noperiph:sdhci_slot0:0:0:0): (mmcprobe0:sdhci_slot0:0:0:0): xpt_async(AC_FOUND_DEVICE) mmcprobe_start (mmcprobe0:sdhci_slot0:0:0:0): Start with PROBE_DONE (mmcprobe0:sdhci_slot0:0:0:0): Periph invalidated (mmcprobe0:sdhci_slot0:0:0:0): Periph destroyed (sdda0:sdhci_slot0:0:0:0): Periph created (pass0:sdhci_slot0:0:0:0): Periph created (sdda0:sdhci_slot0:0:0:0): Capacity: 125069950976, sectors: 244277248 (sdda0:sdhci_slot0:0:0:0): Set SD freq to 25 MHz (min out of host f=25 MHz and card f=52 MHz) (sdda0:sdhci_slot0:0:0:0): Set bus width to 8-bit (min of host 8-bit and card 8-bit) (sdda0:sdhci_slot0:0:0:0): Partition type 'default', size 125069950976 (sdda0:sdhci_slot0:0:0:0): Partition type 'boot0', size 4194304 (sdda0:sdhci_slot0:0:0:0): Partition type 'boot1', size 4194304 (sdda0:sdhci_slot0:0:0:0): Partition type 'RPMB', size 16777216 (sdda0:sdhci_slot0:0:0:0): Don't know what to do with RPMB partitions yet sdda0 at sdhci_slot0 bus 0 scbus2 target 0 lun 0 sdda0: Relative addr: 00000002 Card features: Card memory OCR: 40ff8080 sdda0: Serial Number AD0EFC3E (sdda0:sdhci_slot0:0:0:0): XPT info: CLK 25000000, ... sdda0: MMCHC DA4128 0.1 SN AD0EFC3E MFG 03/2003 by 69 0x0000 (sdda0:sdhci_slot0:0:0:0): Partition 0 -> 1 g_dev_taste: make_dev_alias_p() failed (name=mmcsd0, error=17) (sdda0:sdhci_slot0:0:0:0): Partition 1 -> 2 (sdda0:sdhci_slot0:0:0:0): Partition 2 -> 0 ugen5.2: at usbus5 ure0 on uhub4 ure0: on usbus5 miibus0: on ure0 rgephy0: PHY 0 on miibus0 rgephy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, 1000baseT-FDX-master, auto ue0: on ure0 ue0: Ethernet address: a0:ce:c8:de:9c:95 ugen2.2: at usbus2 uhub6 on uhub5 uhub6: on usbus2 ugen1.2: at usbus1 ukbd0 on uhub3 ukbd0: on usbus1 kbd1 at ukbd0 ums0 on uhub3 ums0: on usbus1 ums0: 3 buttons and [XY] coordinates ID=1 Root mount waiting for: usbus2 uhub6: 4 ports with 4 removable, self powered ugen2.3: at usbus2 mountroot: waiting for device /dev/mmcsd0p3... WARNING: /: TRIM flag on fs but disk does not support TRIM Dual Console: Serial Primary, Video Secondary lock order reversal: 1st 0xffffa00007850770 ufs (ufs, lockmgr) @ /usr/src/sys/kern/vfs_mount.c:1780 2nd 0xffffa00005e52e70 devfs (devfs, lockmgr) @ /usr/src/sys/kern/vfs_subr.c:3035 lock order devfs -> ufs established at: #0 0xffff0000004d7670 at witness_checkorder+0x444 #1 0xffff000000439744 at lockmgr_lock_flags+0x1d8 #2 0xffff0000006debac at ffs_lock+0x64 #3 0xffff0000005647ac at _vn_lock+0x54 #4 0xffff000000544fb8 at vfs_domount+0xeb0 #5 0xffff000000543058 at vfs_donmount+0x2b4 #6 0xffff00000054783c at kernel_mount+0x4c #7 0xffff000000549fd8 at parse_mount+0x49c #8 0xffff000000548520 at vfs_mountroot+0x400 #9 0xffff0000003f7448 at start_init+0x24 #10 0xffff000000424198 at fork_exit+0x74 #11 0xffff00000076716c at fork_trampoline+0x14 lock order ufs -> devfs attempted at: #0 0xffff0000004d7e7c at witness_checkorder+0xc50 #1 0xffff00000043b198 at lockmgr_xlock+0x50 #2 0xffff0000005647ac at _vn_lock+0x54 #3 0xffff00000054e6c4 at vget_finish+0x4c #4 0xffff000000318328 at devfs_allocv+0xd0 #5 0xffff000000317ab8 at devfs_root+0x44 #6 0xffff000000553bb0 at vfs_cache_root_fallback+0x154 #7 0xffff00000054f944 at vflush+0x5c #8 0xffff0000003179c0 at devfs_unmount+0x34 #9 0xffff000000545e4c at dounmount+0x43c #10 0xffff0000005459c8 at kern_unmount+0x2d4 #11 0xffff000000767a40 at do_el0_sync+0x4a4 #12 0xffff000000746a1c at handle_el0_sync+0x90 dwwdt0: mem 0xff848000-0xff8480ff irq 47 on ofwbus0 pwm_backlight0: on ofwbus0 mx25l0: at cs 0 mode 0 on spibus0 mx25l0: device type gd25q128, size 16384K in 256 sectors of 64K, erase size 4K lo0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP Is there any patches to enable SDIO on Broadcom BCM43456 ? Best regards --- Kazuhiko Kiriyama From nobody Fri Jun 4 11:19:28 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 A17AD13AD0BA for ; Fri, 4 Jun 2021 11:19:31 +0000 (UTC) (envelope-from kiri@truefc.org) Received: from kx.truefc.org (1.212.52.36.ap.yournet.ne.jp [36.52.212.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 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", Issuer "smtp" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4FxKzR0ytJz3GGQ for ; Fri, 4 Jun 2021 11:19:30 +0000 (UTC) (envelope-from kiri@truefc.org) Received: from kx.truefc.org (kx.truefc.org [36.52.212.1]) by kx.truefc.org (8.16.1/8.16.1) with ESMTP id 154BJSCG088334; Fri, 4 Jun 2021 20:19:28 +0900 (JST) (envelope-from kiri@kx.truefc.org) Message-Id: <202106041119.154BJSCG088334@kx.truefc.org> Date: Fri, 04 Jun 2021 20:19:28 +0900 From: KIRIYAMA Kazuhiko To: freebsd-arm@freebsd.org Cc: kiri@truefc.org Subject: Re: Can't enable SDIO wifi module on PBP In-Reply-To: <202106041107.154B7cQD087733@kx.truefc.org> References: <202106041107.154B7cQD087733@kx.truefc.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 MULE XEmacs/21.4 (patch 24) (Standard C) (amd64--freebsd) 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 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 4FxKzR0ytJz3GGQ X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Fri, 04 Jun 2021 20:07:38 +0900, KIRIYAMA Kazuhiko wrote: > > Hi, all > > I've reconfigured kernel to GENERIC-MMCCAM on Pinebook Pro (PBP) to use SDIO > wifi module Broadcom BCM43456 (AMPAK AP6256 [1]). But nothing SDIO module Sorry for not adding reference sites. Broadcom BCM43456 on AMPAK AP6256 sites to [1] and FreeBSD SDIO reference site is [2]. [1] https://wiki.pine64.org/wiki/Pinebook_Pro#Hardware_Overview [2] https://wiki.freebsd.org/SDIO > found : > > root@kazu:~ # camcontrol devlist -v > scbus0 on dw_mmc_sim0 bus 0: > scbus1 on dw_mmc_sim1 bus 0: > scbus2 on sdhci_slot0 bus 0: > at scbus2 target 0 lun 0 (pass0,sdda0) > scbus-1 on xpt0 bus 0: > <> at scbus-1 target -1 lun ffffffff (xpt0) > root@kazu:~ # > > My environments are as follows : > > root@kazu:~ # uname -a > FreeBSD kazu.tfc 14.0-CURRENT FreeBSD 14.0-CURRENT #0 n246349-daa5350d0e0c: Wed Jun 2 17:01:11 JST 2021 root@tbedfc:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC-MMCCAM arm64 > root@kazu:~ # cat /var/run/dmesg.boot > ---<>--- > GDB: debug ports: uart > GDB: current port: uart > KDB: debugger backends: ddb gdb > KDB: current backend: ddb > WARNING: Cannot find freebsd,dts-version property, cannot check DTB compliance > Copyright (c) 1992-2021 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 14.0-CURRENT #0 n246349-daa5350d0e0c: Wed Jun 2 17:01:11 JST 2021 > root@tbedfc:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC-MMCCAM arm64 > FreeBSD clang version 11.0.1 (git@github.com:llvm/llvm-project.git llvmorg-11.0.1-0-g43ff75f2c3fe) > WARNING: WITNESS option enabled, expect reduced performance. > VT(efifb): resolution 1920x1080 > module firmware already present! > real memory = 4158373888 (3965 MB) > avail memory = 4025626624 (3839 MB) > Starting CPU 1 (1) > Starting CPU 2 (2) > Starting CPU 3 (3) > Starting CPU 4 (100) > Starting CPU 5 (101) > FreeBSD/SMP: Multiprocessor System Detected: 6 CPUs > random: unblocking device. > random: entropy device external interface > MAP f3f16000 mode 2 pages 4 > MAP f3f1b000 mode 2 pages 4 > MAP f6f40000 mode 2 pages 16 > WARNING: Device "kbd" is Giant locked and may be deleted before FreeBSD 14.0. > kbd0 at kbdmux0 > WARNING: Device "openfirm" is Giant locked and may be deleted before FreeBSD 14.0. > ofwbus0: > clk_fixed0: on ofwbus0 > simplebus0: on ofwbus0 > rk_grf0: mem 0xff320000-0xff320fff on ofwbus0 > rk3399_pmucru0: mem 0xff750000-0xff750fff on ofwbus0 > rk3399_cru0: mem 0xff760000-0xff760fff on ofwbus0 > rk_grf1: mem 0xff770000-0xff77ffff on ofwbus0 > regfix0: on ofwbus0 > regfix1: on ofwbus0 > regfix2: on ofwbus0 > regfix3: on ofwbus0 > regfix4: on ofwbus0 > regfix5: on ofwbus0 > regfix6: on ofwbus0 > regfix7: on ofwbus0 > regfix8: on ofwbus0 > regfix9: on ofwbus0 > regfix10: on ofwbus0 > regfix11: on ofwbus0 > simple_mfd0: mem 0xff310000-0xff310fff on ofwbus0 > psci0: on ofwbus0 > gic0: mem 0xfee00000-0xfee0ffff,0xfef00000-0xfefbffff,0xfff00000-0xfff0ffff,0xfff10000-0xfff1ffff,0xfff20000-0xfff2ffff irq 18 on ofwbus0 > its0: mem 0xfee20000-0xfee3ffff on gic0 > rk_iodomain0: mem 0-0xff31ffff,0-0xfff on rk_grf0 > rk_iodomain1: mem 0-0xff76ffff,0-0xffff on rk_grf1 > rk_pinctrl0: on ofwbus0 > gpio0: mem 0xff720000-0xff7200ff irq 71 on rk_pinctrl0 > gpiobus0: on gpio0 > gpio1: mem 0xff730000-0xff7300ff irq 72 on rk_pinctrl0 > gpiobus1: on gpio1 > gpio2: mem 0xff780000-0xff7800ff irq 73 on rk_pinctrl0 > gpiobus2: on gpio2 > gpio3: mem 0xff788000-0xff7880ff irq 74 on rk_pinctrl0 > gpiobus3: on gpio3 > gpio4: mem 0xff790000-0xff7900ff irq 75 on rk_pinctrl0 > gpiobus4: on gpio4 > rk_i2c0: mem 0xff110000-0xff110fff irq 20 on ofwbus0 > iicbus0: on rk_i2c0 > rk_i2c1: mem 0xff130000-0xff130fff irq 22 on ofwbus0 > iicbus1: on rk_i2c1 > rk_i2c2: mem 0xff3c0000-0xff3c0fff irq 38 on ofwbus0 > iicbus2: on rk_i2c2 > syr8270: at addr 0x80 on iicbus2 > rk_i2c3: mem 0xff3d0000-0xff3d0fff irq 39 on ofwbus0 > iicbus3: on rk_i2c3 > rk805_pmu0: at addr 0x36 irq 76 on iicbus2 > generic_timer0: irq 2,3,4,5 on ofwbus0 > Timecounter "ARM MPCore Timecounter" frequency 24000000 Hz quality 1000 > Event timer "ARM MPCore Eventtimer" frequency 24000000 Hz quality 1000 > rk_tsadc0: mem 0xff260000-0xff2600ff irq 35 on ofwbus0 > rk_usb2phy0: mem 0-0xff76ffff,0-0xffff on rk_grf1 > rk_usb2phy1: mem 0-0xff76ffff,0-0xffff on rk_grf1 > rk_emmcphy0: mem 0-0xff76ffff,0-0xffff on rk_grf1 > rk_pcie_phy0: mem 0-0xff76ffff,0-0xffff on rk_grf1 > rk_typec_phy0: mem 0xff7c0000-0xff7fffff on ofwbus0 > rk_typec_phy1: mem 0xff800000-0xff83ffff on ofwbus0 > cpulist0: on ofwbus0 > cpu0: on cpulist0 > cpufreq_dt0: on cpu0 > cpu1: on cpulist0 > cpufreq_dt1: on cpu1 > cpu2: on cpulist0 > cpufreq_dt2: on cpu2 > cpu3: on cpulist0 > cpufreq_dt3: on cpu3 > cpu4: on cpulist0 > cpufreq_dt4: on cpu4 > cpu5: on cpulist0 > cpufreq_dt5: on cpu5 > pmu0: irq 0 on ofwbus0 > pmu1: irq 1 on ofwbus0 > pcib0: mem 0xf8000000-0xf9ffffff,0xfd000000-0xfdffffff irq 6,7,8 on ofwbus0 > pcib0: Gen1 link training timeouted: 0x00080001. > pci0: on pcib0 > pcib1: at device 0.0 on pci0 > pcib0: failed to reserve resource for pcib1 > pcib1: failed to allocate initial memory window: 0-0xfffff > pci1: on pcib1 > rockchip_dwmmc0: mem 0xfe310000-0xfe313fff irq 10 on ofwbus0 > rockchip_dwmmc0: Hardware version ID is 270a > rockchip_dwmmc1: mem 0xfe320000-0xfe323fff irq 11 on ofwbus0 > rockchip_dwmmc1: Hardware version ID is 270a > sdhci_fdt0: mem 0xfe330000-0xfe33ffff irq 12 on ofwbus0 > rk_emmcphy0: got emmcclk clock > sdhci_fdt0-slot0: Hardware doesn't specify timeout clock frequency, setting BROKEN_TIMEOUT quirk. > sdhci_fdt0: 1 slot(s) allocated > uma_zalloc_debug: zone "malloc-2048" with the following non-sleepable locks held: > exclusive sleep mutex SD slot mtx (sdhci) r = 0 (0xffff0000411c6030) locked @ /usr/src/sys/dev/sdhci/sdhci.c:617 > stack backtrace: > #0 0xffff0000004d819c at witness_debugger+0x64 > #1 0xffff0000004d9320 at witness_warn+0x3e8 > #2 0xffff0000006f9084 at uma_zalloc_debug+0x2c > #3 0xffff0000006f8a8c at uma_zalloc_arg+0x2c > #4 0xffff00000043fa18 at malloc+0xa0 > #5 0xffff00000000f550 at xpt_alloc_ccb+0x1c > #6 0xffff000000034ee0 at mmccam_start_discovery+0x18 > #7 0xffff0000002506fc at sdhci_card_task+0x110 > #8 0xffff000000255460 at sdhci_fdt_attach+0x5b4 > #9 0xffff0000004a3b34 at device_attach+0x400 > #10 0xffff0000004a369c at device_probe_and_attach+0x7c > #11 0xffff0000004a5880 at bus_generic_new_pass+0xf8 > #12 0xffff0000004a5830 at bus_generic_new_pass+0xa8 > #13 0xffff0000004a5830 at bus_generic_new_pass+0xa8 > #14 0xffff0000004a0ae0 at bus_set_pass+0x4c > #15 0xffff0000003f644c at mi_startup+0x12c > #16 0xffff0000000008a8 at virtdone+0x6c > ehci0: mem 0xfe380000-0xfe39ffff irq 13 on ofwbus0 > usbus0: EHCI version 1.0 > usbus0 on ehci0 > ohci0: mem 0xfe3a0000-0xfe3bffff irq 14 on ofwbus0 > usbus1 on ohci0 > ehci1: mem 0xfe3c0000-0xfe3dffff irq 15 on ofwbus0 > usbus2: EHCI version 1.0 > usbus2 on ehci1 > ohci1: mem 0xfe3e0000-0xfe3fffff irq 16 on ofwbus0 > usbus3 on ohci1 > rk_dwc30: on ofwbus0 > xhci0: mem 0xfe800000-0xfe8fffff irq 77 on rk_dwc30 > xhci0: 64 bytes context size, 32-bit DMA > usbus4: trying to attach > usbus4 on xhci0 > rk_dwc31: on ofwbus0 > xhci1: mem 0xfe900000-0xfe9fffff irq 78 on rk_dwc31 > xhci1: 64 bytes context size, 32-bit DMA > usbus5: trying to attach > usbus5 on xhci1 > iicbus0: at addr 0x22 > iic0: on iicbus0 > iic1: on iicbus1 > uart0: mem 0xff180000-0xff1800ff irq 26 on ofwbus0 > uart0: debug port (-1,n,8,1) > uart1: <16750 or compatible> mem 0xff1a0000-0xff1a00ff irq 28 on ofwbus0 > uart1: console (1500000,n,8,1) > spi0: mem 0xff1d0000-0xff1d0fff irq 31 on ofwbus0 > spibus0: on spi0 > spibus0: at cs 0 mode 0 > iicbus2: at addr 0x82 > iic2: on iicbus2 > iicbus3: at addr 0x44 > iic3: on iicbus3 > pwm0: mem 0xff420000-0xff42000f on ofwbus0 > pwmbus0: on pwm0 > pwmc0: channel 0 on pwmbus0 > pwm1: mem 0xff420020-0xff42002f on ofwbus0 > pwmbus1: on pwm1 > pwmc1: channel 0 on pwmbus1 > gpioc0: on gpio0 > gpioc1: on gpio1 > gpioc2: on gpio2 > gpioc3: on gpio3 > gpioc4: on gpio4 > gpioled0: on ofwbus0 > armv8crypto0: > Timecounters tick every 1.000 msec > usbus0: 480Mbps High Speed USB v2.0 > usbus1: 12Mbps Full Speed USB v1.0 > rk805_pmu0: registered as a time-of-day clock, resolution 1.000000s > Release APs...done > usbus2: 480Mbps High Speed USB v2.0 > CPU 0: ARM Cortex-A53 r0p4 affinity: 0 0 > usbus3: 12Mbps Full Speed USB v1.0 > Cache Type = <64 byte D-cacheline,64 byte I-cacheline,VIPT ICache,64 byte ERG,64 byte CWG> > usbus4: 5.0Gbps Super Speed USB v3.0 > Instruction Set Attributes 0 = > usbus5: 5.0Gbps Super Speed USB v3.0 > Instruction Set Attributes 1 = <> > (noperiph:dw_mmc_sim0:0:-1:ffffffff): Processor Features 0 = > Processor Features 1 = <> > Memory Model Features 0 = > Memory Model Features 1 = <8bit VMID> > Memory Model Features 2 = <32bit CCIDX,48bit VA> > Debug Features 0 = <2 CTX BKPTs,4 Watchpoints,6 Breakpoints,PMUv3,Debugv8> > Debug Features 1 = <> > Auxiliary Features 0 = <> > Auxiliary Features 1 = <> > CPU 1: ARM Cortex-A53 r0p4 affinity: 0 1 > Cache Type = <64 byte D-cacheline,64 byte I-cacheline,VIPT ICache,64 byte ERG,64 byte CWG> > Memory Model Features 0 = > CPU 2: ARM Cortex-A53 r0p4 affinity: 0 2 > Cache Type = <64 byte D-cacheline,64 byte I-cacheline,VIPT ICache,64 byte ERG,64 byte CWG> > Memory Model Features 0 = > CPU 3: ARM Cortex-A53 r0p4 affinity: 0 3 > Cache Type = <64 byte D-cacheline,64 byte I-cacheline,VIPT ICache,64 byte ERG,64 byte CWG> > Memory Model Features 0 = > CPU 4: ARM Cortex-A72 r0p2 affinity: 1 0 > Cache Type = <64 byte D-cacheline,64 byte I-cacheline,PIPT ICache,64 byte ERG,64 byte CWG> > Memory Model Features 0 = > CPU 5: ARM Cortex-A72 r0p2 affinity: 1 1 > Cache Type = <64 byte D-cacheline,64 byte I-cacheline,PIPT ICache,64 byte ERG,64 byte CWG> > Memory Model Features 0 = > XPT_SCAN_{BUS,TGT,LUN} > (noperiph:dw_mmc_sim0:0:0:0): XPT_SCAN_{BUS,TGT,LUN} > (noperiph:dw_mmc_sim0:0:0:0): ugen4.1: at usbus4 > Set up the mmcprobe device... > ugen0.1: at usbus0 > (mmcprobe0:dw_mmc_sim0:0:0:0): ugen3.1: at usbus3 > Periph created > ugen1.1: at usbus1 > ugen5.1: at usbus5 > ugen2.1: at usbus2 > (mmcprobe0:dw_mmc_sim0:0:0:0): sysctl_warn_reuse: can't re-use a leaf (dev.uhub.%parent)! > sysctl_warn_reuse: can't re-use a leaf (dev.uhub.%parent)! > sysctl_warn_reuse: can't re-use a leaf (dev.uhub.%parent)! > sysctl_warn_reuse: can't re-use a leaf (dev.uhub.%parent)! > sysctl_warn_reuse: can't re-use a leaf (dev.uhub.%parent)! > uhub1 on usbus0 > uhub5 on usbus2 > uhub1: on usbus0 > uhub5: on usbus2 > uhub4Probe started > on usbus5 > (mmcprobe0:dw_mmc_sim0:0:0:0): uhub2Probe PROBE_INVALID to PROBE_RESET > on usbus3 > (mmcprobe0:dw_mmc_sim0:0:0:0): uhub3mmcprobe_start > on usbus1 > uhub2: on usbus3 > (mmcprobe0:dw_mmc_sim0:0:0:0): uhub4: on usbus5 > Trying to mount root from ufs:/dev/mmcsd0p3 [rw]... > Start with PROBE_RESET > uhub3: on usbus1 > (mmcprobe0:dw_mmc_sim0:0:0:0): Root mount waiting for:uhub0Start with PROBE_IDENTIFY > CAM usbus0 usbus1 on usbus4 > usbus2uhub0: on usbus4 > usbus3 usbus4 usbus5 > WARNING: WITNESS option enabled, expect reduced performance. > Unresolved linked clock found: clkin_gmac > lock order reversal: (sleepable after non-sleepable) > 1st 0xffffa00001026558 dwmmcsim (dwmmcsim, sleep mutex) @ /usr/src/sys/cam/cam_xpt.c:2802 > 2nd 0xffff000000c12a30 Clock topology lock (Clock topology lock, sx) @ /usr/src/sys/dev/extres/clk/clk.c:1154 > lock order dwmmcsim -> Clock topology lock attempted at: > #0 0xffff0000004d7e7c at witness_checkorder+0xc50 > #1 0xffff0000004743e8 at _sx_xlock+0x7c > #2 0xffff0000001ac808 at clk_set_freq+0x4c > #3 0xffff00000078a998 at dwmmc_rockchip_update_ios+0x3c > #4 0xffff00000078a3bc at dwmmc_update_ios+0xfc > #5 0xffff000000789854 at dwmmc_cam_action+0x14c > #6 0xffff000000009c34 at xpt_action_default+0xca8 > #7 0xffff000000008f5c at xpt_action+0x270 > #8 0xffff00000003633c at mmcprobe_start+0x89c > #9 0xffff00000000cc10 at xpt_run_allocq+0x104 > #10 0xffff00000000cadc at xpt_schedule+0x230 > #11 0xffff000000035a78 at mmcprobe_register+0x2a4 > #12 0xffff000000003b90 at cam_periph_alloc+0x528 > #13 0xffff0000000354dc at mmc_action+0x484 > #14 0xffff000000008f5c at xpt_action+0x270 > #15 0xffff000000011750 at xpt_scanner_thread+0xcc > #16 0xffff000000424198 at fork_exit+0x74 > #17 0xffff00000076716c at fork_trampoline+0x14 > uhub3: 1 port with 1 removable, self powered > (mmcprobe0:dw_mmc_sim0:0:0:0): uhub2: 1 port with 1 removable, self powered > Send first XPT_MMC_IO > (noperiph:dw_mmc_sim1:0:-1:ffffffff): XPT_SCAN_{BUS,TGT,LUN} > (noperiph:dw_mmc_sim1:0:0:0): (mmcprobe0:dw_mmc_sim0:0:0:0): XPT_SCAN_{BUS,TGT,LUN} > done with PROBE_RESET > (noperiph:dw_mmc_sim1:0:0:0): (mmcprobe0:dw_mmc_sim0:0:0:0): Set up the mmcprobe device... > Probe PROBE_RESET to PROBE_SEND_IF_COND > (mmcprobe1:dw_mmc_sim1:0:0:0): (mmcprobe0:dw_mmc_sim0:0:0:0): Periph created > mmcprobe_done: remaining freeze count 0 > (mmcprobe1:dw_mmc_sim1:0:0:0): (mmcprobe0:dw_mmc_sim0:0:0:0): Probe started > mmcprobe_start > (mmcprobe0:dw_mmc_sim0:0:0:0): (mmcprobe1:dw_mmc_sim1:0:0:0): Start with PROBE_SEND_IF_COND > Probe PROBE_INVALID to PROBE_RESET > (mmcprobe1:dw_mmc_sim1:0:0:0): mmcprobe_start > (mmcprobe1:dw_mmc_sim1:0:0:0): Start with PROBE_RESET > (mmcprobe0:dw_mmc_sim0:0:0:0): (mmcprobe1:dw_mmc_sim1:0:0:0): IF_COND: error 1, pattern 00000000 > Start with PROBE_IDENTIFY > (mmcprobe0:dw_mmc_sim0:0:0:0): Probe PROBE_SEND_IF_COND to PROBE_SDIO_RESET > (mmcprobe0:dw_mmc_sim0:0:0:0): mmcprobe_done: remaining freeze count 0 > (mmcprobe0:dw_mmc_sim0:0:0:0): mmcprobe_start > (mmcprobe0:dw_mmc_sim0:0:0:0): Start with PROBE_SDIO_RESET > (mmcprobe0:dw_mmc_sim0:0:0:0): SDIO_RESET: error 1, CCCR CTL register: 00000000 > (mmcprobe0:dw_mmc_sim0:0:0:0): Probe PROBE_SDIO_RESET to PROBE_SDIO_INIT > (mmcprobe0:dw_mmc_sim0:0:0:0): mmcprobe_done: remaining freeze count 0 > (mmcprobe0:dw_mmc_sim0:0:0:0): mmcprobe_start > (mmcprobe0:dw_mmc_sim0:0:0:0): Start with PROBE_SDIO_INIT > (mmcprobe0:dw_mmc_sim0:0:0:0): SDIO_INIT: error 1, 00000000 00000000 00000000 00000000 > (mmcprobe0:dw_mmc_sim0:0:0:0): Probe PROBE_SDIO_INIT to PROBE_SEND_APP_OP_COND > (mmcprobe0:dw_mmc_sim0:0:0:0): mmcprobe_done: remaining freeze count 0 > (mmcprobe0:dw_mmc_sim0:0:0:0): mmcprobe_start > (mmcprobe0:dw_mmc_sim0:0:0:0): APP_OP_COND: error 1, resp 00000000 > (mmcprobe0:dw_mmc_sim0:0:0:0): Probe PROBE_SEND_APP_OP_COND to PROBE_MMC_INIT > (mmcprobe0:dw_mmc_sim0:0:0:0): mmcprobe_done: remaining freeze count 0 > (mmcprobe0:dw_mmc_sim0:0:0:0): mmcprobe_start > (mmcprobe0:dw_mmc_sim0:0:0:0): Start with PROBE_MMC_INIT > (mmcprobe0:dw_mmc_sim0:0:0:0): MMC_INIT: error 1, resp 00000000 > (mmcprobe0:dw_mmc_sim0:0:0:0): Probe PROBE_MMC_INIT to PROBE_INVALID > (mmcprobe0:dw_mmc_sim0:0:0:0): mmcprobe_done: remaining freeze count 0 > (mmcprobe0:dw_mmc_sim0:0:0:0): Periph invalidated > (mmcprobe0:dw_mmc_sim0:0:0:0): Periph destroyed > uhub0: 2 ports with 2 removable, self powered > uhub4: 2 ports with 2 removable, self powered > (mmcprobe1:dw_mmc_sim1:0:0:0): Send first XPT_MMC_IO > (noperiph:sdhci_slot0:0:-1:ffffffff): XPT_SCAN_{BUS,TGT,LUN} > (mmcprobe1:dw_mmc_sim1:0:0:0): (noperiph:sdhci_slot0:0:0:0): done with PROBE_RESET > XPT_SCAN_{BUS,TGT,LUN} > (noperiph:sdhci_slot0:0:0:0): (mmcprobe1:dw_mmc_sim1:0:0:0): Set up the mmcprobe device... > Probe PROBE_RESET to PROBE_SEND_IF_COND > (mmcprobe0:sdhci_slot0:0:0:0): (mmcprobe1:dw_mmc_sim1:0:0:0): Periph created > (mmcprobe0:sdhci_slot0:0:0:0): mmcprobe_done: remaining freeze count 0 > Probe started > (mmcprobe1:dw_mmc_sim1:0:0:0): (mmcprobe0:sdhci_slot0:0:0:0): mmcprobe_start > (mmcprobe1:dw_mmc_sim1:0:0:0): Probe PROBE_INVALID to PROBE_RESET > Start with PROBE_SEND_IF_COND > (mmcprobe0:sdhci_slot0:0:0:0): mmcprobe_start > (mmcprobe0:sdhci_slot0:0:0:0): Start with PROBE_RESET > (mmcprobe0:sdhci_slot0:0:0:0): (mmcprobe1:dw_mmc_sim1:0:0:0): Start with PROBE_IDENTIFY > IF_COND: error 1, pattern 00000000 > (mmcprobe1:dw_mmc_sim1:0:0:0): Probe PROBE_SEND_IF_COND to PROBE_SDIO_RESET > (mmcprobe1:dw_mmc_sim1:0:0:0): mmcprobe_done: remaining freeze count 0 > (mmcprobe1:dw_mmc_sim1:0:0:0): mmcprobe_start > (mmcprobe1:dw_mmc_sim1:0:0:0): Start with PROBE_SDIO_RESET > (mmcprobe1:dw_mmc_sim1:0:0:0): SDIO_RESET: error 1, CCCR CTL register: 00000000 > (mmcprobe1:dw_mmc_sim1:0:0:0): Probe PROBE_SDIO_RESET to PROBE_SDIO_INIT > (mmcprobe1:dw_mmc_sim1:0:0:0): mmcprobe_done: remaining freeze count 0 > (mmcprobe1:dw_mmc_sim1:0:0:0): mmcprobe_start > (mmcprobe1:dw_mmc_sim1:0:0:0): Start with PROBE_SDIO_INIT > (mmcprobe1:dw_mmc_sim1:0:0:0): SDIO_INIT: error 1, 00000000 00000000 00000000 00000000 > (mmcprobe1:dw_mmc_sim1:0:0:0): Probe PROBE_SDIO_INIT to PROBE_SEND_APP_OP_COND > (mmcprobe1:dw_mmc_sim1:0:0:0): mmcprobe_done: remaining freeze count 0 > (mmcprobe1:dw_mmc_sim1:0:0:0): mmcprobe_start > (mmcprobe1:dw_mmc_sim1:0:0:0): APP_OP_COND: error 1, resp 00000000 > (mmcprobe1:dw_mmc_sim1:0:0:0): Probe PROBE_SEND_APP_OP_COND to PROBE_MMC_INIT > (mmcprobe1:dw_mmc_sim1:0:0:0): mmcprobe_done: remaining freeze count 0 > (mmcprobe1:dw_mmc_sim1:0:0:0): mmcprobe_start > (mmcprobe1:dw_mmc_sim1:0:0:0): Start with PROBE_MMC_INIT > (mmcprobe1:dw_mmc_sim1:0:0:0): MMC_INIT: error 1, resp 00000000 > (mmcprobe1:dw_mmc_sim1:0:0:0): Probe PROBE_MMC_INIT to PROBE_INVALID > (mmcprobe1:dw_mmc_sim1:0:0:0): mmcprobe_done: remaining freeze count 0 > (mmcprobe1:dw_mmc_sim1:0:0:0): Periph invalidated > (mmcprobe1:dw_mmc_sim1:0:0:0): Periph destroyed > uhub5: 1 port with 1 removable, self powered > uhub1: 1 port with 1 removable, self powered > (mmcprobe0:sdhci_slot0:0:0:0): Send first XPT_MMC_IO > (mmcprobe0:sdhci_slot0:0:0:0): done with PROBE_RESET > (mmcprobe0:sdhci_slot0:0:0:0): Probe PROBE_RESET to PROBE_SEND_IF_COND > (mmcprobe0:sdhci_slot0:0:0:0): mmcprobe_done: remaining freeze count 0 > (mmcprobe0:sdhci_slot0:0:0:0): mmcprobe_start > (mmcprobe0:sdhci_slot0:0:0:0): Start with PROBE_SEND_IF_COND > (mmcprobe0:sdhci_slot0:0:0:0): IF_COND: error 1, pattern 00000000 > (mmcprobe0:sdhci_slot0:0:0:0): Probe PROBE_SEND_IF_COND to PROBE_SDIO_RESET > (mmcprobe0:sdhci_slot0:0:0:0): mmcprobe_done: remaining freeze count 0 > (mmcprobe0:sdhci_slot0:0:0:0): mmcprobe_start > (mmcprobe0:sdhci_slot0:0:0:0): Start with PROBE_SDIO_RESET > (mmcprobe0:sdhci_slot0:0:0:0): SDIO_RESET: error 1, CCCR CTL register: 00000000 > (mmcprobe0:sdhci_slot0:0:0:0): Probe PROBE_SDIO_RESET to PROBE_SDIO_INIT > (mmcprobe0:sdhci_slot0:0:0:0): mmcprobe_done: remaining freeze count 0 > (mmcprobe0:sdhci_slot0:0:0:0): mmcprobe_start > (mmcprobe0:sdhci_slot0:0:0:0): Start with PROBE_SDIO_INIT > (mmcprobe0:sdhci_slot0:0:0:0): SDIO_INIT: error 1, 00000000 00000000 00000000 00000000 > (mmcprobe0:sdhci_slot0:0:0:0): Probe PROBE_SDIO_INIT to PROBE_SEND_APP_OP_COND > (mmcprobe0:sdhci_slot0:0:0:0): mmcprobe_done: remaining freeze count 0 > (mmcprobe0:sdhci_slot0:0:0:0): mmcprobe_start > (mmcprobe0:sdhci_slot0:0:0:0): APP_OP_COND: error 1, resp 00000000 > (mmcprobe0:sdhci_slot0:0:0:0): Probe PROBE_SEND_APP_OP_COND to PROBE_MMC_INIT > (mmcprobe0:sdhci_slot0:0:0:0): mmcprobe_done: remaining freeze count 0 > (mmcprobe0:sdhci_slot0:0:0:0): mmcprobe_start > (mmcprobe0:sdhci_slot0:0:0:0): Start with PROBE_MMC_INIT > (mmcprobe0:sdhci_slot0:0:0:0): MMC card, OCR 40ff8080 > (mmcprobe0:sdhci_slot0:0:0:0): -> sending OCR to card > (mmcprobe0:sdhci_slot0:0:0:0): mmcprobe_done: remaining freeze count 0 > (mmcprobe0:sdhci_slot0:0:0:0): mmcprobe_start > (mmcprobe0:sdhci_slot0:0:0:0): Start with PROBE_MMC_INIT > (mmcprobe0:sdhci_slot0:0:0:0): MMC card, OCR 40ff8080 > (mmcprobe0:sdhci_slot0:0:0:0): Card is still powering up > (mmcprobe0:sdhci_slot0:0:0:0): mmcprobe_done: remaining freeze count 0 > (mmcprobe0:sdhci_slot0:0:0:0): mmcprobe_start > (mmcprobe0:sdhci_slot0:0:0:0): Start with PROBE_MMC_INIT > (mmcprobe0:sdhci_slot0:0:0:0): MMC card, OCR 40ff8080 > (mmcprobe0:sdhci_slot0:0:0:0): Card is still powering up > (mmcprobe0:sdhci_slot0:0:0:0): mmcprobe_done: remaining freeze count 0 > (mmcprobe0:sdhci_slot0:0:0:0): mmcprobe_start > (mmcprobe0:sdhci_slot0:0:0:0): Start with PROBE_MMC_INIT > (mmcprobe0:sdhci_slot0:0:0:0): MMC card, OCR c0ff8080 > (mmcprobe0:sdhci_slot0:0:0:0): Probe PROBE_MMC_INIT to PROBE_GET_CID > (mmcprobe0:sdhci_slot0:0:0:0): mmcprobe_done: remaining freeze count 0 > (mmcprobe0:sdhci_slot0:0:0:0): mmcprobe_start > (mmcprobe0:sdhci_slot0:0:0:0): CID 45010044413431323801ad0efc3e3600 > (mmcprobe0:sdhci_slot0:0:0:0): Probe PROBE_GET_CID to PROBE_MMC_SET_RELATIVE_ADDR > (mmcprobe0:sdhci_slot0:0:0:0): mmcprobe_done: remaining freeze count 0 > (mmcprobe0:sdhci_slot0:0:0:0): mmcprobe_start > (mmcprobe0:sdhci_slot0:0:0:0): Probe PROBE_MMC_SET_RELATIVE_ADDR to PROBE_GET_CSD > (mmcprobe0:sdhci_slot0:0:0:0): mmcprobe_done: remaining freeze count 0 > (mmcprobe0:sdhci_slot0:0:0:0): mmcprobe_start > (mmcprobe0:sdhci_slot0:0:0:0): CSD d00f00328f5903ffffffffef8a404000 > (mmcprobe0:sdhci_slot0:0:0:0): Probe PROBE_GET_CSD to PROBE_SELECT_CARD > (mmcprobe0:sdhci_slot0:0:0:0): mmcprobe_done: remaining freeze count 0 > (mmcprobe0:sdhci_slot0:0:0:0): mmcprobe_start > (mmcprobe0:sdhci_slot0:0:0:0): Probe PROBE_SELECT_CARD to PROBE_DONE > (mmcprobe0:sdhci_slot0:0:0:0): mmcprobe_done: remaining freeze count 0 > (noperiph:sdhci_slot0:0:0:0): (mmcprobe0:sdhci_slot0:0:0:0): xpt_async(AC_FOUND_DEVICE) > mmcprobe_start > (mmcprobe0:sdhci_slot0:0:0:0): Start with PROBE_DONE > (mmcprobe0:sdhci_slot0:0:0:0): Periph invalidated > (mmcprobe0:sdhci_slot0:0:0:0): Periph destroyed > (sdda0:sdhci_slot0:0:0:0): Periph created > (pass0:sdhci_slot0:0:0:0): Periph created > (sdda0:sdhci_slot0:0:0:0): Capacity: 125069950976, sectors: 244277248 > (sdda0:sdhci_slot0:0:0:0): Set SD freq to 25 MHz (min out of host f=25 MHz and card f=52 MHz) > (sdda0:sdhci_slot0:0:0:0): Set bus width to 8-bit (min of host 8-bit and card 8-bit) > (sdda0:sdhci_slot0:0:0:0): Partition type 'default', size 125069950976 > (sdda0:sdhci_slot0:0:0:0): Partition type 'boot0', size 4194304 > (sdda0:sdhci_slot0:0:0:0): Partition type 'boot1', size 4194304 > (sdda0:sdhci_slot0:0:0:0): Partition type 'RPMB', size 16777216 > (sdda0:sdhci_slot0:0:0:0): Don't know what to do with RPMB partitions yet > sdda0 at sdhci_slot0 bus 0 scbus2 target 0 lun 0 > sdda0: Relative addr: 00000002 > Card features: > Card memory OCR: 40ff8080 > sdda0: Serial Number AD0EFC3E > (sdda0:sdhci_slot0:0:0:0): XPT info: CLK 25000000, ... > sdda0: MMCHC DA4128 0.1 SN AD0EFC3E MFG 03/2003 by 69 0x0000 > (sdda0:sdhci_slot0:0:0:0): Partition 0 -> 1 > g_dev_taste: make_dev_alias_p() failed (name=mmcsd0, error=17) > (sdda0:sdhci_slot0:0:0:0): Partition 1 -> 2 > (sdda0:sdhci_slot0:0:0:0): Partition 2 -> 0 > ugen5.2: at usbus5 > ure0 on uhub4 > ure0: on usbus5 > miibus0: on ure0 > rgephy0: PHY 0 on miibus0 > rgephy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, 1000baseT-FDX-master, auto > ue0: on ure0 > ue0: Ethernet address: a0:ce:c8:de:9c:95 > ugen2.2: at usbus2 > uhub6 on uhub5 > uhub6: on usbus2 > ugen1.2: at usbus1 > ukbd0 on uhub3 > ukbd0: on usbus1 > kbd1 at ukbd0 > ums0 on uhub3 > ums0: on usbus1 > ums0: 3 buttons and [XY] coordinates ID=1 > Root mount waiting for: usbus2 > uhub6: 4 ports with 4 removable, self powered > ugen2.3: at usbus2 > mountroot: waiting for device /dev/mmcsd0p3... > WARNING: /: TRIM flag on fs but disk does not support TRIM > Dual Console: Serial Primary, Video Secondary > lock order reversal: > 1st 0xffffa00007850770 ufs (ufs, lockmgr) @ /usr/src/sys/kern/vfs_mount.c:1780 > 2nd 0xffffa00005e52e70 devfs (devfs, lockmgr) @ /usr/src/sys/kern/vfs_subr.c:3035 > lock order devfs -> ufs established at: > #0 0xffff0000004d7670 at witness_checkorder+0x444 > #1 0xffff000000439744 at lockmgr_lock_flags+0x1d8 > #2 0xffff0000006debac at ffs_lock+0x64 > #3 0xffff0000005647ac at _vn_lock+0x54 > #4 0xffff000000544fb8 at vfs_domount+0xeb0 > #5 0xffff000000543058 at vfs_donmount+0x2b4 > #6 0xffff00000054783c at kernel_mount+0x4c > #7 0xffff000000549fd8 at parse_mount+0x49c > #8 0xffff000000548520 at vfs_mountroot+0x400 > #9 0xffff0000003f7448 at start_init+0x24 > #10 0xffff000000424198 at fork_exit+0x74 > #11 0xffff00000076716c at fork_trampoline+0x14 > lock order ufs -> devfs attempted at: > #0 0xffff0000004d7e7c at witness_checkorder+0xc50 > #1 0xffff00000043b198 at lockmgr_xlock+0x50 > #2 0xffff0000005647ac at _vn_lock+0x54 > #3 0xffff00000054e6c4 at vget_finish+0x4c > #4 0xffff000000318328 at devfs_allocv+0xd0 > #5 0xffff000000317ab8 at devfs_root+0x44 > #6 0xffff000000553bb0 at vfs_cache_root_fallback+0x154 > #7 0xffff00000054f944 at vflush+0x5c > #8 0xffff0000003179c0 at devfs_unmount+0x34 > #9 0xffff000000545e4c at dounmount+0x43c > #10 0xffff0000005459c8 at kern_unmount+0x2d4 > #11 0xffff000000767a40 at do_el0_sync+0x4a4 > #12 0xffff000000746a1c at handle_el0_sync+0x90 > dwwdt0: mem 0xff848000-0xff8480ff irq 47 on ofwbus0 > pwm_backlight0: on ofwbus0 > mx25l0: at cs 0 mode 0 on spibus0 > mx25l0: device type gd25q128, size 16384K in 256 sectors of 64K, erase size 4K > lo0: link state changed to UP > ue0: link state changed to DOWN > ue0: link state changed to UP > > > Is there any patches to enable SDIO on Broadcom BCM43456 ? > > Best regards > --- > Kazuhiko Kiriyama > --- Kazuhiko Kiriyama From nobody Fri Jun 4 14:49:29 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 ACA29C7F2EC for ; Fri, 4 Jun 2021 14:49:34 +0000 (UTC) (envelope-from SRS0=tLKA=K6=klop.ws=ronald-lists@realworks.nl) Received: from smtp-relay-int.realworks.nl (smtp-relay-int.realworks.nl [194.109.157.24]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4FxQdp3FlWz3mgv; Fri, 4 Jun 2021 14:49:33 +0000 (UTC) (envelope-from SRS0=tLKA=K6=klop.ws=ronald-lists@realworks.nl) Date: Fri, 4 Jun 2021 16:49:29 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2; t=1622818171; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Ggh1/pFtECwW+lsM5YE/2D0gynAXrzwuKye536fq/ik=; b=sI582FCgfgd01Fek3Ki0DmGytdjM6DE9iHylR60gIUbqWmRuGWdfkAPOSbMjtjaWKWGEJi yl64K5gAXKAT1Xohh8fJfZSPo5jsoDHGthULNqY1QoPA4OljTq1V2LKnTIpXHGDQCmGmzx tIvYhtd9Nwb/wu6Tu5545nRnTfD6l06aZY1ejtqypunxtUGt3mczA6NaxopV6gXGa7QV78 y6+dxN1zYUcV8REhKrCkZsF3eaHQkFb5gDP5/d1ihQ+0BEImlENdSKO4pYroSXrhSbmyRh DYVrFx2FArlW+7RfAFEFgT2nQvYLJ7ii118o+EQtZpvwDRqVod48LXkx1NlIyQ== From: Ronald Klop To: KIRIYAMA Kazuhiko Cc: freebsd-arm@freebsd.org, freebsd-wireless@freebsd.org Message-ID: <1899735108.281.1622818169330@localhost> In-Reply-To: <202106041119.154BJSCG088334@kx.truefc.org> References: <202106041107.154B7cQD087733@kx.truefc.org> <202106041119.154BJSCG088334@kx.truefc.org> Subject: Re: Can't enable SDIO wifi module on PBP 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 Content-Type: multipart/alternative; boundary="----=_Part_280_478119520.1622818169295" X-Mailer: Realworks (563.279.642d63713bf) Importance: Normal X-Priority: 3 (Normal) X-Rspamd-Queue-Id: 4FxQdp3FlWz3mgv X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-Spam: Yes X-ThisMailContainsUnwantedMimeParts: Y ------=_Part_280_478119520.1622818169295 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, People with more knowledge about this should anwer instead of me. But as far as I know there is no driver for this WiFi module on FreeBSD. Regards, Ronald. Van: KIRIYAMA Kazuhiko Datum: vrijdag, 4 juni 2021 13:19 Aan: freebsd-arm@freebsd.org CC: kiri@truefc.org Onderwerp: Re: Can't enable SDIO wifi module on PBP > > On Fri, 04 Jun 2021 20:07:38 +0900, > KIRIYAMA Kazuhiko wrote: > > > > Hi, all > > > > I've reconfigured kernel to GENERIC-MMCCAM on Pinebook Pro (PBP) to use SDIO > > wifi module Broadcom BCM43456 (AMPAK AP6256 [1]). But nothing SDIO module > > Sorry for not adding reference sites. Broadcom BCM43456 on AMPAK AP6256 > sites to [1] and FreeBSD SDIO reference site is [2]. > > [1] https://wiki.pine64.org/wiki/Pinebook_Pro#Hardware_Overview > [2] https://wiki.freebsd.org/SDIO > > > found : > > > > root@kazu:~ # camcontrol devlist -v > > scbus0 on dw_mmc_sim0 bus 0: > > scbus1 on dw_mmc_sim1 bus 0: > > scbus2 on sdhci_slot0 bus 0: > > at scbus2 target 0 lun 0 (pass0,sdda0) > > scbus-1 on xpt0 bus 0: > > <> at scbus-1 target -1 lun ffffffff (xpt0) > > root@kazu:~ # > > > > My environments are as follows : > > > > root@kazu:~ # uname -a > > FreeBSD kazu.tfc 14.0-CURRENT FreeBSD 14.0-CURRENT #0 n246349-daa5350d0e0c: Wed Jun 2 17:01:11 JST 2021 root@tbedfc:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC-MMCCAM arm64 > > root@kazu:~ # cat /var/run/dmesg.boot > > ---<>--- > > GDB: debug ports: uart > > GDB: current port: uart > > KDB: debugger backends: ddb gdb > > KDB: current backend: ddb > > WARNING: Cannot find freebsd,dts-version property, cannot check DTB compliance > > Copyright (c) 1992-2021 The FreeBSD Project. > > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > > The Regents of the University of California. All rights reserved. > > FreeBSD is a registered trademark of The FreeBSD Foundation. > > FreeBSD 14.0-CURRENT #0 n246349-daa5350d0e0c: Wed Jun 2 17:01:11 JST 2021 > > root@tbedfc:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC-MMCCAM arm64 > > FreeBSD clang version 11.0.1 (git@github.com:llvm/llvm-project.git llvmorg-11.0.1-0-g43ff75f2c3fe) > > WARNING: WITNESS option enabled, expect reduced performance. > > VT(efifb): resolution 1920x1080 > > module firmware already present! > > real memory = 4158373888 (3965 MB) > > avail memory = 4025626624 (3839 MB) > > Starting CPU 1 (1) > > Starting CPU 2 (2) > > Starting CPU 3 (3) > > Starting CPU 4 (100) > > Starting CPU 5 (101) > > FreeBSD/SMP: Multiprocessor System Detected: 6 CPUs > > random: unblocking device. > > random: entropy device external interface > > MAP f3f16000 mode 2 pages 4 > > MAP f3f1b000 mode 2 pages 4 > > MAP f6f40000 mode 2 pages 16 > > WARNING: Device "kbd" is Giant locked and may be deleted before FreeBSD 14.0. > > kbd0 at kbdmux0 > > WARNING: Device "openfirm" is Giant locked and may be deleted before FreeBSD 14.0. > > ofwbus0: > > clk_fixed0: on ofwbus0 > > simplebus0: on ofwbus0 > > rk_grf0: mem 0xff320000-0xff320fff on ofwbus0 > > rk3399_pmucru0: mem 0xff750000-0xff750fff on ofwbus0 > > rk3399_cru0: mem 0xff760000-0xff760fff on ofwbus0 > > rk_grf1: mem 0xff770000-0xff77ffff on ofwbus0 > > regfix0: on ofwbus0 > > regfix1: on ofwbus0 > > regfix2: on ofwbus0 > > regfix3: on ofwbus0 > > regfix4: on ofwbus0 > > regfix5: on ofwbus0 > > regfix6: on ofwbus0 > > regfix7: on ofwbus0 > > regfix8: on ofwbus0 > > regfix9: on ofwbus0 > > regfix10: on ofwbus0 > > regfix11: on ofwbus0 > > simple_mfd0: mem 0xff310000-0xff310fff on ofwbus0 > > psci0: on ofwbus0 > > gic0: mem 0xfee00000-0xfee0ffff,0xfef00000-0xfefbffff,0xfff00000-0xfff0ffff,0xfff10000-0xfff1ffff,0xfff20000-0xfff2ffff irq 18 on ofwbus0 > > its0: mem 0xfee20000-0xfee3ffff on gic0 > > rk_iodomain0: mem 0-0xff31ffff,0-0xfff on rk_grf0 > > rk_iodomain1: mem 0-0xff76ffff,0-0xffff on rk_grf1 > > rk_pinctrl0: on ofwbus0 > > gpio0: mem 0xff720000-0xff7200ff irq 71 on rk_pinctrl0 > > gpiobus0: on gpio0 > > gpio1: mem 0xff730000-0xff7300ff irq 72 on rk_pinctrl0 > > gpiobus1: on gpio1 > > gpio2: mem 0xff780000-0xff7800ff irq 73 on rk_pinctrl0 > > gpiobus2: on gpio2 > > gpio3: mem 0xff788000-0xff7880ff irq 74 on rk_pinctrl0 > > gpiobus3: on gpio3 > > gpio4: mem 0xff790000-0xff7900ff irq 75 on rk_pinctrl0 > > gpiobus4: on gpio4 > > rk_i2c0: mem 0xff110000-0xff110fff irq 20 on ofwbus0 > > iicbus0: on rk_i2c0 > > rk_i2c1: mem 0xff130000-0xff130fff irq 22 on ofwbus0 > > iicbus1: on rk_i2c1 > > rk_i2c2: mem 0xff3c0000-0xff3c0fff irq 38 on ofwbus0 > > iicbus2: on rk_i2c2 > > syr8270: at addr 0x80 on iicbus2 > > rk_i2c3: mem 0xff3d0000-0xff3d0fff irq 39 on ofwbus0 > > iicbus3: on rk_i2c3 > > rk805_pmu0: at addr 0x36 irq 76 on iicbus2 > > generic_timer0: irq 2,3,4,5 on ofwbus0 > > Timecounter "ARM MPCore Timecounter" frequency 24000000 Hz quality 1000 > > Event timer "ARM MPCore Eventtimer" frequency 24000000 Hz quality 1000 > > rk_tsadc0: mem 0xff260000-0xff2600ff irq 35 on ofwbus0 > > rk_usb2phy0: mem 0-0xff76ffff,0-0xffff on rk_grf1 > > rk_usb2phy1: mem 0-0xff76ffff,0-0xffff on rk_grf1 > > rk_emmcphy0: mem 0-0xff76ffff,0-0xffff on rk_grf1 > > rk_pcie_phy0: mem 0-0xff76ffff,0-0xffff on rk_grf1 > > rk_typec_phy0: mem 0xff7c0000-0xff7fffff on ofwbus0 > > rk_typec_phy1: mem 0xff800000-0xff83ffff on ofwbus0 > > cpulist0: on ofwbus0 > > cpu0: on cpulist0 > > cpufreq_dt0: on cpu0 > > cpu1: on cpulist0 > > cpufreq_dt1: on cpu1 > > cpu2: on cpulist0 > > cpufreq_dt2: on cpu2 > > cpu3: on cpulist0 > > cpufreq_dt3: on cpu3 > > cpu4: on cpulist0 > > cpufreq_dt4: on cpu4 > > cpu5: on cpulist0 > > cpufreq_dt5: on cpu5 > > pmu0: irq 0 on ofwbus0 > > pmu1: irq 1 on ofwbus0 > > pcib0: mem 0xf8000000-0xf9ffffff,0xfd000000-0xfdffffff irq 6,7,8 on ofwbus0 > > pcib0: Gen1 link training timeouted: 0x00080001. > > pci0: on pcib0 > > pcib1: at device 0.0 on pci0 > > pcib0: failed to reserve resource for pcib1 > > pcib1: failed to allocate initial memory window: 0-0xfffff > > pci1: on pcib1 > > rockchip_dwmmc0: mem 0xfe310000-0xfe313fff irq 10 on ofwbus0 > > rockchip_dwmmc0: Hardware version ID is 270a > > rockchip_dwmmc1: mem 0xfe320000-0xfe323fff irq 11 on ofwbus0 > > rockchip_dwmmc1: Hardware version ID is 270a > > sdhci_fdt0: mem 0xfe330000-0xfe33ffff irq 12 on ofwbus0 > > rk_emmcphy0: got emmcclk clock > > sdhci_fdt0-slot0: Hardware doesn't specify timeout clock frequency, setting BROKEN_TIMEOUT quirk. > > sdhci_fdt0: 1 slot(s) allocated > > uma_zalloc_debug: zone "malloc-2048" with the following non-sleepable locks held: > > exclusive sleep mutex SD slot mtx (sdhci) r = 0 (0xffff0000411c6030) locked @ /usr/src/sys/dev/sdhci/sdhci.c:617 > > stack backtrace: > > #0 0xffff0000004d819c at witness_debugger+0x64 > > #1 0xffff0000004d9320 at witness_warn+0x3e8 > > #2 0xffff0000006f9084 at uma_zalloc_debug+0x2c > > #3 0xffff0000006f8a8c at uma_zalloc_arg+0x2c > > #4 0xffff00000043fa18 at malloc+0xa0 > > #5 0xffff00000000f550 at xpt_alloc_ccb+0x1c > > #6 0xffff000000034ee0 at mmccam_start_discovery+0x18 > > #7 0xffff0000002506fc at sdhci_card_task+0x110 > > #8 0xffff000000255460 at sdhci_fdt_attach+0x5b4 > > #9 0xffff0000004a3b34 at device_attach+0x400 > > #10 0xffff0000004a369c at device_probe_and_attach+0x7c > > #11 0xffff0000004a5880 at bus_generic_new_pass+0xf8 > > #12 0xffff0000004a5830 at bus_generic_new_pass+0xa8 > > #13 0xffff0000004a5830 at bus_generic_new_pass+0xa8 > > #14 0xffff0000004a0ae0 at bus_set_pass+0x4c > > #15 0xffff0000003f644c at mi_startup+0x12c > > #16 0xffff0000000008a8 at virtdone+0x6c > > ehci0: mem 0xfe380000-0xfe39ffff irq 13 on ofwbus0 > > usbus0: EHCI version 1.0 > > usbus0 on ehci0 > > ohci0: mem 0xfe3a0000-0xfe3bffff irq 14 on ofwbus0 > > usbus1 on ohci0 > > ehci1: mem 0xfe3c0000-0xfe3dffff irq 15 on ofwbus0 > > usbus2: EHCI version 1.0 > > usbus2 on ehci1 > > ohci1: mem 0xfe3e0000-0xfe3fffff irq 16 on ofwbus0 > > usbus3 on ohci1 > > rk_dwc30: on ofwbus0 > > xhci0: mem 0xfe800000-0xfe8fffff irq 77 on rk_dwc30 > > xhci0: 64 bytes context size, 32-bit DMA > > usbus4: trying to attach > > usbus4 on xhci0 > > rk_dwc31: on ofwbus0 > > xhci1: mem 0xfe900000-0xfe9fffff irq 78 on rk_dwc31 > > xhci1: 64 bytes context size, 32-bit DMA > > usbus5: trying to attach > > usbus5 on xhci1 > > iicbus0: at addr 0x22 > > iic0: on iicbus0 > > iic1: on iicbus1 > > uart0: mem 0xff180000-0xff1800ff irq 26 on ofwbus0 > > uart0: debug port (-1,n,8,1) > > uart1: <16750 or compatible> mem 0xff1a0000-0xff1a00ff irq 28 on ofwbus0 > > uart1: console (1500000,n,8,1) > > spi0: mem 0xff1d0000-0xff1d0fff irq 31 on ofwbus0 > > spibus0: on spi0 > > spibus0: at cs 0 mode 0 > > iicbus2: at addr 0x82 > > iic2: on iicbus2 > > iicbus3: at addr 0x44 > > iic3: on iicbus3 > > pwm0: mem 0xff420000-0xff42000f on ofwbus0 > > pwmbus0: on pwm0 > > pwmc0: channel 0 on pwmbus0 > > pwm1: mem 0xff420020-0xff42002f on ofwbus0 > > pwmbus1: on pwm1 > > pwmc1: channel 0 on pwmbus1 > > gpioc0: on gpio0 > > gpioc1: on gpio1 > > gpioc2: on gpio2 > > gpioc3: on gpio3 > > gpioc4: on gpio4 > > gpioled0: on ofwbus0 > > armv8crypto0: > > Timecounters tick every 1.000 msec > > usbus0: 480Mbps High Speed USB v2.0 > > usbus1: 12Mbps Full Speed USB v1.0 > > rk805_pmu0: registered as a time-of-day clock, resolution 1.000000s > > Release APs...done > > usbus2: 480Mbps High Speed USB v2.0 > > CPU 0: ARM Cortex-A53 r0p4 affinity: 0 0 > > usbus3: 12Mbps Full Speed USB v1.0 > > Cache Type = <64 byte D-cacheline,64 byte I-cacheline,VIPT ICache,64 byte ERG,64 byte CWG> > > usbus4: 5.0Gbps Super Speed USB v3.0 > > Instruction Set Attributes 0 = > > usbus5: 5.0Gbps Super Speed USB v3.0 > > Instruction Set Attributes 1 = <> > > (noperiph:dw_mmc_sim0:0:-1:ffffffff): Processor Features 0 = > > Processor Features 1 = <> > > Memory Model Features 0 = > > Memory Model Features 1 = <8bit VMID> > > Memory Model Features 2 = <32bit CCIDX,48bit VA> > > Debug Features 0 = <2 CTX BKPTs,4 Watchpoints,6 Breakpoints,PMUv3,Debugv8> > > Debug Features 1 = <> > > Auxiliary Features 0 = <> > > Auxiliary Features 1 = <> > > CPU 1: ARM Cortex-A53 r0p4 affinity: 0 1 > > Cache Type = <64 byte D-cacheline,64 byte I-cacheline,VIPT ICache,64 byte ERG,64 byte CWG> > > Memory Model Features 0 = > > CPU 2: ARM Cortex-A53 r0p4 affinity: 0 2 > > Cache Type = <64 byte D-cacheline,64 byte I-cacheline,VIPT ICache,64 byte ERG,64 byte CWG> > > Memory Model Features 0 = > > CPU 3: ARM Cortex-A53 r0p4 affinity: 0 3 > > Cache Type = <64 byte D-cacheline,64 byte I-cacheline,VIPT ICache,64 byte ERG,64 byte CWG> > > Memory Model Features 0 = > > CPU 4: ARM Cortex-A72 r0p2 affinity: 1 0 > > Cache Type = <64 byte D-cacheline,64 byte I-cacheline,PIPT ICache,64 byte ERG,64 byte CWG> > > Memory Model Features 0 = > > CPU 5: ARM Cortex-A72 r0p2 affinity: 1 1 > > Cache Type = <64 byte D-cacheline,64 byte I-cacheline,PIPT ICache,64 byte ERG,64 byte CWG> > > Memory Model Features 0 = > > XPT_SCAN_{BUS,TGT,LUN} > > (noperiph:dw_mmc_sim0:0:0:0): XPT_SCAN_{BUS,TGT,LUN} > > (noperiph:dw_mmc_sim0:0:0:0): ugen4.1: at usbus4 > > Set up the mmcprobe device... > > ugen0.1: at usbus0 > > (mmcprobe0:dw_mmc_sim0:0:0:0): ugen3.1: at usbus3 > > Periph created > > ugen1.1: at usbus1 > > ugen5.1: at usbus5 > > ugen2.1: at usbus2 > > (mmcprobe0:dw_mmc_sim0:0:0:0): sysctl_warn_reuse: can't re-use a leaf (dev.uhub.%parent)! > > sysctl_warn_reuse: can't re-use a leaf (dev.uhub.%parent)! > > sysctl_warn_reuse: can't re-use a leaf (dev.uhub.%parent)! > > sysctl_warn_reuse: can't re-use a leaf (dev.uhub.%parent)! > > sysctl_warn_reuse: can't re-use a leaf (dev.uhub.%parent)! > > uhub1 on usbus0 > > uhub5 on usbus2 > > uhub1: on usbus0 > > uhub5: on usbus2 > > uhub4Probe started > > on usbus5 > > (mmcprobe0:dw_mmc_sim0:0:0:0): uhub2Probe PROBE_INVALID to PROBE_RESET > > on usbus3 > > (mmcprobe0:dw_mmc_sim0:0:0:0): uhub3mmcprobe_start > > on usbus1 > > uhub2: on usbus3 > > (mmcprobe0:dw_mmc_sim0:0:0:0): uhub4: on usbus5 > > Trying to mount root from ufs:/dev/mmcsd0p3 [rw]... > > Start with PROBE_RESET > > uhub3: on usbus1 > > (mmcprobe0:dw_mmc_sim0:0:0:0): Root mount waiting for:uhub0Start with PROBE_IDENTIFY > > CAM usbus0 usbus1 on usbus4 > > usbus2uhub0: on usbus4 > > usbus3 usbus4 usbus5 > > WARNING: WITNESS option enabled, expect reduced performance. > > Unresolved linked clock found: clkin_gmac > > lock order reversal: (sleepable after non-sleepable) > > 1st 0xffffa00001026558 dwmmcsim (dwmmcsim, sleep mutex) @ /usr/src/sys/cam/cam_xpt.c:2802 > > 2nd 0xffff000000c12a30 Clock topology lock (Clock topology lock, sx) @ /usr/src/sys/dev/extres/clk/clk.c:1154 > > lock order dwmmcsim -> Clock topology lock attempted at: > > #0 0xffff0000004d7e7c at witness_checkorder+0xc50 > > #1 0xffff0000004743e8 at _sx_xlock+0x7c > > #2 0xffff0000001ac808 at clk_set_freq+0x4c > > #3 0xffff00000078a998 at dwmmc_rockchip_update_ios+0x3c > > #4 0xffff00000078a3bc at dwmmc_update_ios+0xfc > > #5 0xffff000000789854 at dwmmc_cam_action+0x14c > > #6 0xffff000000009c34 at xpt_action_default+0xca8 > > #7 0xffff000000008f5c at xpt_action+0x270 > > #8 0xffff00000003633c at mmcprobe_start+0x89c > > #9 0xffff00000000cc10 at xpt_run_allocq+0x104 > > #10 0xffff00000000cadc at xpt_schedule+0x230 > > #11 0xffff000000035a78 at mmcprobe_register+0x2a4 > > #12 0xffff000000003b90 at cam_periph_alloc+0x528 > > #13 0xffff0000000354dc at mmc_action+0x484 > > #14 0xffff000000008f5c at xpt_action+0x270 > > #15 0xffff000000011750 at xpt_scanner_thread+0xcc > > #16 0xffff000000424198 at fork_exit+0x74 > > #17 0xffff00000076716c at fork_trampoline+0x14 > > uhub3: 1 port with 1 removable, self powered > > (mmcprobe0:dw_mmc_sim0:0:0:0): uhub2: 1 port with 1 removable, self powered > > Send first XPT_MMC_IO > > (noperiph:dw_mmc_sim1:0:-1:ffffffff): XPT_SCAN_{BUS,TGT,LUN} > > (noperiph:dw_mmc_sim1:0:0:0): (mmcprobe0:dw_mmc_sim0:0:0:0): XPT_SCAN_{BUS,TGT,LUN} > > done with PROBE_RESET > > (noperiph:dw_mmc_sim1:0:0:0): (mmcprobe0:dw_mmc_sim0:0:0:0): Set up the mmcprobe device... > > Probe PROBE_RESET to PROBE_SEND_IF_COND > > (mmcprobe1:dw_mmc_sim1:0:0:0): (mmcprobe0:dw_mmc_sim0:0:0:0): Periph created > > mmcprobe_done: remaining freeze count 0 > > (mmcprobe1:dw_mmc_sim1:0:0:0): (mmcprobe0:dw_mmc_sim0:0:0:0): Probe started > > mmcprobe_start > > (mmcprobe0:dw_mmc_sim0:0:0:0): (mmcprobe1:dw_mmc_sim1:0:0:0): Start with PROBE_SEND_IF_COND > > Probe PROBE_INVALID to PROBE_RESET > > (mmcprobe1:dw_mmc_sim1:0:0:0): mmcprobe_start > > (mmcprobe1:dw_mmc_sim1:0:0:0): Start with PROBE_RESET > > (mmcprobe0:dw_mmc_sim0:0:0:0): (mmcprobe1:dw_mmc_sim1:0:0:0): IF_COND: error 1, pattern 00000000 > > Start with PROBE_IDENTIFY > > (mmcprobe0:dw_mmc_sim0:0:0:0): Probe PROBE_SEND_IF_COND to PROBE_SDIO_RESET > > (mmcprobe0:dw_mmc_sim0:0:0:0): mmcprobe_done: remaining freeze count 0 > > (mmcprobe0:dw_mmc_sim0:0:0:0): mmcprobe_start > > (mmcprobe0:dw_mmc_sim0:0:0:0): Start with PROBE_SDIO_RESET > > (mmcprobe0:dw_mmc_sim0:0:0:0): SDIO_RESET: error 1, CCCR CTL register: 00000000 > > (mmcprobe0:dw_mmc_sim0:0:0:0): Probe PROBE_SDIO_RESET to PROBE_SDIO_INIT > > (mmcprobe0:dw_mmc_sim0:0:0:0): mmcprobe_done: remaining freeze count 0 > > (mmcprobe0:dw_mmc_sim0:0:0:0): mmcprobe_start > > (mmcprobe0:dw_mmc_sim0:0:0:0): Start with PROBE_SDIO_INIT > > (mmcprobe0:dw_mmc_sim0:0:0:0): SDIO_INIT: error 1, 00000000 00000000 00000000 00000000 > > (mmcprobe0:dw_mmc_sim0:0:0:0): Probe PROBE_SDIO_INIT to PROBE_SEND_APP_OP_COND > > (mmcprobe0:dw_mmc_sim0:0:0:0): mmcprobe_done: remaining freeze count 0 > > (mmcprobe0:dw_mmc_sim0:0:0:0): mmcprobe_start > > (mmcprobe0:dw_mmc_sim0:0:0:0): APP_OP_COND: error 1, resp 00000000 > > (mmcprobe0:dw_mmc_sim0:0:0:0): Probe PROBE_SEND_APP_OP_COND to PROBE_MMC_INIT > > (mmcprobe0:dw_mmc_sim0:0:0:0): mmcprobe_done: remaining freeze count 0 > > (mmcprobe0:dw_mmc_sim0:0:0:0): mmcprobe_start > > (mmcprobe0:dw_mmc_sim0:0:0:0): Start with PROBE_MMC_INIT > > (mmcprobe0:dw_mmc_sim0:0:0:0): MMC_INIT: error 1, resp 00000000 > > (mmcprobe0:dw_mmc_sim0:0:0:0): Probe PROBE_MMC_INIT to PROBE_INVALID > > (mmcprobe0:dw_mmc_sim0:0:0:0): mmcprobe_done: remaining freeze count 0 > > (mmcprobe0:dw_mmc_sim0:0:0:0): Periph invalidated > > (mmcprobe0:dw_mmc_sim0:0:0:0): Periph destroyed > > uhub0: 2 ports with 2 removable, self powered > > uhub4: 2 ports with 2 removable, self powered > > (mmcprobe1:dw_mmc_sim1:0:0:0): Send first XPT_MMC_IO > > (noperiph:sdhci_slot0:0:-1:ffffffff): XPT_SCAN_{BUS,TGT,LUN} > > (mmcprobe1:dw_mmc_sim1:0:0:0): (noperiph:sdhci_slot0:0:0:0): done with PROBE_RESET > > XPT_SCAN_{BUS,TGT,LUN} > > (noperiph:sdhci_slot0:0:0:0): (mmcprobe1:dw_mmc_sim1:0:0:0): Set up the mmcprobe device... > > Probe PROBE_RESET to PROBE_SEND_IF_COND > > (mmcprobe0:sdhci_slot0:0:0:0): (mmcprobe1:dw_mmc_sim1:0:0:0): Periph created > > (mmcprobe0:sdhci_slot0:0:0:0): mmcprobe_done: remaining freeze count 0 > > Probe started > > (mmcprobe1:dw_mmc_sim1:0:0:0): (mmcprobe0:sdhci_slot0:0:0:0): mmcprobe_start > > (mmcprobe1:dw_mmc_sim1:0:0:0): Probe PROBE_INVALID to PROBE_RESET > > Start with PROBE_SEND_IF_COND > > (mmcprobe0:sdhci_slot0:0:0:0): mmcprobe_start > > (mmcprobe0:sdhci_slot0:0:0:0): Start with PROBE_RESET > > (mmcprobe0:sdhci_slot0:0:0:0): (mmcprobe1:dw_mmc_sim1:0:0:0): Start with PROBE_IDENTIFY > > IF_COND: error 1, pattern 00000000 > > (mmcprobe1:dw_mmc_sim1:0:0:0): Probe PROBE_SEND_IF_COND to PROBE_SDIO_RESET > > (mmcprobe1:dw_mmc_sim1:0:0:0): mmcprobe_done: remaining freeze count 0 > > (mmcprobe1:dw_mmc_sim1:0:0:0): mmcprobe_start > > (mmcprobe1:dw_mmc_sim1:0:0:0): Start with PROBE_SDIO_RESET > > (mmcprobe1:dw_mmc_sim1:0:0:0): SDIO_RESET: error 1, CCCR CTL register: 00000000 > > (mmcprobe1:dw_mmc_sim1:0:0:0): Probe PROBE_SDIO_RESET to PROBE_SDIO_INIT > > (mmcprobe1:dw_mmc_sim1:0:0:0): mmcprobe_done: remaining freeze count 0 > > (mmcprobe1:dw_mmc_sim1:0:0:0): mmcprobe_start > > (mmcprobe1:dw_mmc_sim1:0:0:0): Start with PROBE_SDIO_INIT > > (mmcprobe1:dw_mmc_sim1:0:0:0): SDIO_INIT: error 1, 00000000 00000000 00000000 00000000 > > (mmcprobe1:dw_mmc_sim1:0:0:0): Probe PROBE_SDIO_INIT to PROBE_SEND_APP_OP_COND > > (mmcprobe1:dw_mmc_sim1:0:0:0): mmcprobe_done: remaining freeze count 0 > > (mmcprobe1:dw_mmc_sim1:0:0:0): mmcprobe_start > > (mmcprobe1:dw_mmc_sim1:0:0:0): APP_OP_COND: error 1, resp 00000000 > > (mmcprobe1:dw_mmc_sim1:0:0:0): Probe PROBE_SEND_APP_OP_COND to PROBE_MMC_INIT > > (mmcprobe1:dw_mmc_sim1:0:0:0): mmcprobe_done: remaining freeze count 0 > > (mmcprobe1:dw_mmc_sim1:0:0:0): mmcprobe_start > > (mmcprobe1:dw_mmc_sim1:0:0:0): Start with PROBE_MMC_INIT > > (mmcprobe1:dw_mmc_sim1:0:0:0): MMC_INIT: error 1, resp 00000000 > > (mmcprobe1:dw_mmc_sim1:0:0:0): Probe PROBE_MMC_INIT to PROBE_INVALID > > (mmcprobe1:dw_mmc_sim1:0:0:0): mmcprobe_done: remaining freeze count 0 > > (mmcprobe1:dw_mmc_sim1:0:0:0): Periph invalidated > > (mmcprobe1:dw_mmc_sim1:0:0:0): Periph destroyed > > uhub5: 1 port with 1 removable, self powered > > uhub1: 1 port with 1 removable, self powered > > (mmcprobe0:sdhci_slot0:0:0:0): Send first XPT_MMC_IO > > (mmcprobe0:sdhci_slot0:0:0:0): done with PROBE_RESET > > (mmcprobe0:sdhci_slot0:0:0:0): Probe PROBE_RESET to PROBE_SEND_IF_COND > > (mmcprobe0:sdhci_slot0:0:0:0): mmcprobe_done: remaining freeze count 0 > > (mmcprobe0:sdhci_slot0:0:0:0): mmcprobe_start > > (mmcprobe0:sdhci_slot0:0:0:0): Start with PROBE_SEND_IF_COND > > (mmcprobe0:sdhci_slot0:0:0:0): IF_COND: error 1, pattern 00000000 > > (mmcprobe0:sdhci_slot0:0:0:0): Probe PROBE_SEND_IF_COND to PROBE_SDIO_RESET > > (mmcprobe0:sdhci_slot0:0:0:0): mmcprobe_done: remaining freeze count 0 > > (mmcprobe0:sdhci_slot0:0:0:0): mmcprobe_start > > (mmcprobe0:sdhci_slot0:0:0:0): Start with PROBE_SDIO_RESET > > (mmcprobe0:sdhci_slot0:0:0:0): SDIO_RESET: error 1, CCCR CTL register: 00000000 > > (mmcprobe0:sdhci_slot0:0:0:0): Probe PROBE_SDIO_RESET to PROBE_SDIO_INIT > > (mmcprobe0:sdhci_slot0:0:0:0): mmcprobe_done: remaining freeze count 0 > > (mmcprobe0:sdhci_slot0:0:0:0): mmcprobe_start > > (mmcprobe0:sdhci_slot0:0:0:0): Start with PROBE_SDIO_INIT > > (mmcprobe0:sdhci_slot0:0:0:0): SDIO_INIT: error 1, 00000000 00000000 00000000 00000000 > > (mmcprobe0:sdhci_slot0:0:0:0): Probe PROBE_SDIO_INIT to PROBE_SEND_APP_OP_COND > > (mmcprobe0:sdhci_slot0:0:0:0): mmcprobe_done: remaining freeze count 0 > > (mmcprobe0:sdhci_slot0:0:0:0): mmcprobe_start > > (mmcprobe0:sdhci_slot0:0:0:0): APP_OP_COND: error 1, resp 00000000 > > (mmcprobe0:sdhci_slot0:0:0:0): Probe PROBE_SEND_APP_OP_COND to PROBE_MMC_INIT > > (mmcprobe0:sdhci_slot0:0:0:0): mmcprobe_done: remaining freeze count 0 > > (mmcprobe0:sdhci_slot0:0:0:0): mmcprobe_start > > (mmcprobe0:sdhci_slot0:0:0:0): Start with PROBE_MMC_INIT > > (mmcprobe0:sdhci_slot0:0:0:0): MMC card, OCR 40ff8080 > > (mmcprobe0:sdhci_slot0:0:0:0): -> sending OCR to card > > (mmcprobe0:sdhci_slot0:0:0:0): mmcprobe_done: remaining freeze count 0 > > (mmcprobe0:sdhci_slot0:0:0:0): mmcprobe_start > > (mmcprobe0:sdhci_slot0:0:0:0): Start with PROBE_MMC_INIT > > (mmcprobe0:sdhci_slot0:0:0:0): MMC card, OCR 40ff8080 > > (mmcprobe0:sdhci_slot0:0:0:0): Card is still powering up > > (mmcprobe0:sdhci_slot0:0:0:0): mmcprobe_done: remaining freeze count 0 > > (mmcprobe0:sdhci_slot0:0:0:0): mmcprobe_start > > (mmcprobe0:sdhci_slot0:0:0:0): Start with PROBE_MMC_INIT > > (mmcprobe0:sdhci_slot0:0:0:0): MMC card, OCR 40ff8080 > > (mmcprobe0:sdhci_slot0:0:0:0): Card is still powering up > > (mmcprobe0:sdhci_slot0:0:0:0): mmcprobe_done: remaining freeze count 0 > > (mmcprobe0:sdhci_slot0:0:0:0): mmcprobe_start > > (mmcprobe0:sdhci_slot0:0:0:0): Start with PROBE_MMC_INIT > > (mmcprobe0:sdhci_slot0:0:0:0): MMC card, OCR c0ff8080 > > (mmcprobe0:sdhci_slot0:0:0:0): Probe PROBE_MMC_INIT to PROBE_GET_CID > > (mmcprobe0:sdhci_slot0:0:0:0): mmcprobe_done: remaining freeze count 0 > > (mmcprobe0:sdhci_slot0:0:0:0): mmcprobe_start > > (mmcprobe0:sdhci_slot0:0:0:0): CID 45010044413431323801ad0efc3e3600 > > (mmcprobe0:sdhci_slot0:0:0:0): Probe PROBE_GET_CID to PROBE_MMC_SET_RELATIVE_ADDR > > (mmcprobe0:sdhci_slot0:0:0:0): mmcprobe_done: remaining freeze count 0 > > (mmcprobe0:sdhci_slot0:0:0:0): mmcprobe_start > > (mmcprobe0:sdhci_slot0:0:0:0): Probe PROBE_MMC_SET_RELATIVE_ADDR to PROBE_GET_CSD > > (mmcprobe0:sdhci_slot0:0:0:0): mmcprobe_done: remaining freeze count 0 > > (mmcprobe0:sdhci_slot0:0:0:0): mmcprobe_start > > (mmcprobe0:sdhci_slot0:0:0:0): CSD d00f00328f5903ffffffffef8a404000 > > (mmcprobe0:sdhci_slot0:0:0:0): Probe PROBE_GET_CSD to PROBE_SELECT_CARD > > (mmcprobe0:sdhci_slot0:0:0:0): mmcprobe_done: remaining freeze count 0 > > (mmcprobe0:sdhci_slot0:0:0:0): mmcprobe_start > > (mmcprobe0:sdhci_slot0:0:0:0): Probe PROBE_SELECT_CARD to PROBE_DONE > > (mmcprobe0:sdhci_slot0:0:0:0): mmcprobe_done: remaining freeze count 0 > > (noperiph:sdhci_slot0:0:0:0): (mmcprobe0:sdhci_slot0:0:0:0): xpt_async(AC_FOUND_DEVICE) > > mmcprobe_start > > (mmcprobe0:sdhci_slot0:0:0:0): Start with PROBE_DONE > > (mmcprobe0:sdhci_slot0:0:0:0): Periph invalidated > > (mmcprobe0:sdhci_slot0:0:0:0): Periph destroyed > > (sdda0:sdhci_slot0:0:0:0): Periph created > > (pass0:sdhci_slot0:0:0:0): Periph created > > (sdda0:sdhci_slot0:0:0:0): Capacity: 125069950976, sectors: 244277248 > > (sdda0:sdhci_slot0:0:0:0): Set SD freq to 25 MHz (min out of host f=25 MHz and card f=52 MHz) > > (sdda0:sdhci_slot0:0:0:0): Set bus width to 8-bit (min of host 8-bit and card 8-bit) > > (sdda0:sdhci_slot0:0:0:0): Partition type 'default', size 125069950976 > > (sdda0:sdhci_slot0:0:0:0): Partition type 'boot0', size 4194304 > > (sdda0:sdhci_slot0:0:0:0): Partition type 'boot1', size 4194304 > > (sdda0:sdhci_slot0:0:0:0): Partition type 'RPMB', size 16777216 > > (sdda0:sdhci_slot0:0:0:0): Don't know what to do with RPMB partitions yet > > sdda0 at sdhci_slot0 bus 0 scbus2 target 0 lun 0 > > sdda0: Relative addr: 00000002 > > Card features: > > Card memory OCR: 40ff8080 > > sdda0: Serial Number AD0EFC3E > > (sdda0:sdhci_slot0:0:0:0): XPT info: CLK 25000000, ... > > sdda0: MMCHC DA4128 0.1 SN AD0EFC3E MFG 03/2003 by 69 0x0000 > > (sdda0:sdhci_slot0:0:0:0): Partition 0 -> 1 > > g_dev_taste: make_dev_alias_p() failed (name=mmcsd0, error=17) > > (sdda0:sdhci_slot0:0:0:0): Partition 1 -> 2 > > (sdda0:sdhci_slot0:0:0:0): Partition 2 -> 0 > > ugen5.2: at usbus5 > > ure0 on uhub4 > > ure0: on usbus5 > > miibus0: on ure0 > > rgephy0: PHY 0 on miibus0 > > rgephy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, 1000baseT-FDX-master, auto > > ue0: on ure0 > > ue0: Ethernet address: a0:ce:c8:de:9c:95 > > ugen2.2: at usbus2 > > uhub6 on uhub5 > > uhub6: on usbus2 > > ugen1.2: at usbus1 > > ukbd0 on uhub3 > > ukbd0: on usbus1 > > kbd1 at ukbd0 > > ums0 on uhub3 > > ums0: on usbus1 > > ums0: 3 buttons and [XY] coordinates ID=1 > > Root mount waiting for: usbus2 > > uhub6: 4 ports with 4 removable, self powered > > ugen2.3: at usbus2 > > mountroot: waiting for device /dev/mmcsd0p3... > > WARNING: /: TRIM flag on fs but disk does not support TRIM > > Dual Console: Serial Primary, Video Secondary > > lock order reversal: > > 1st 0xffffa00007850770 ufs (ufs, lockmgr) @ /usr/src/sys/kern/vfs_mount.c:1780 > > 2nd 0xffffa00005e52e70 devfs (devfs, lockmgr) @ /usr/src/sys/kern/vfs_subr.c:3035 > > lock order devfs -> ufs established at: > > #0 0xffff0000004d7670 at witness_checkorder+0x444 > > #1 0xffff000000439744 at lockmgr_lock_flags+0x1d8 > > #2 0xffff0000006debac at ffs_lock+0x64 > > #3 0xffff0000005647ac at _vn_lock+0x54 > > #4 0xffff000000544fb8 at vfs_domount+0xeb0 > > #5 0xffff000000543058 at vfs_donmount+0x2b4 > > #6 0xffff00000054783c at kernel_mount+0x4c > > #7 0xffff000000549fd8 at parse_mount+0x49c > > #8 0xffff000000548520 at vfs_mountroot+0x400 > > #9 0xffff0000003f7448 at start_init+0x24 > > #10 0xffff000000424198 at fork_exit+0x74 > > #11 0xffff00000076716c at fork_trampoline+0x14 > > lock order ufs -> devfs attempted at: > > #0 0xffff0000004d7e7c at witness_checkorder+0xc50 > > #1 0xffff00000043b198 at lockmgr_xlock+0x50 > > #2 0xffff0000005647ac at _vn_lock+0x54 > > #3 0xffff00000054e6c4 at vget_finish+0x4c > > #4 0xffff000000318328 at devfs_allocv+0xd0 > > #5 0xffff000000317ab8 at devfs_root+0x44 > > #6 0xffff000000553bb0 at vfs_cache_root_fallback+0x154 > > #7 0xffff00000054f944 at vflush+0x5c > > #8 0xffff0000003179c0 at devfs_unmount+0x34 > > #9 0xffff000000545e4c at dounmount+0x43c > > #10 0xffff0000005459c8 at kern_unmount+0x2d4 > > #11 0xffff000000767a40 at do_el0_sync+0x4a4 > > #12 0xffff000000746a1c at handle_el0_sync+0x90 > > dwwdt0: mem 0xff848000-0xff8480ff irq 47 on ofwbus0 > > pwm_backlight0: on ofwbus0 > > mx25l0: at cs 0 mode 0 on spibus0 > > mx25l0: device type gd25q128, size 16384K in 256 sectors of 64K, erase size 4K > > lo0: link state changed to UP > > ue0: link state changed to DOWN > > ue0: link state changed to UP > > > > > > Is there any patches to enable SDIO on Broadcom BCM43456 ? > > > > Best regards > > --- > > Kazuhiko Kiriyama > > > --- > Kazuhiko Kiriyama > > > > ------=_Part_280_478119520.1622818169295-- From nobody Fri Jun 4 19:34:48 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 F170C1374F25 for ; Fri, 4 Jun 2021 19:34:57 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic309-21.consmr.mail.gq1.yahoo.com (sonic309-21.consmr.mail.gq1.yahoo.com [98.137.65.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4FxXz54zGkz4h2Q for ; Fri, 4 Jun 2021 19:34:57 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1622835295; bh=qLGvkVOQiajMZ5ORg4wfJMYJXZ/ZSoisoRMKH4RFrGE=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=VJQlc2Unxv8DHXuf8VTDTAfr1aoQlIekRrQEyZs6BQk3SLQQKkcqkJLKRvtks4nnWE/cFXo5uUwa/i1IenmrD811VG7M5Mn2cDP5dv7DrRdngWSebIUl4kE0R6PpEJZzh8K84EEH2drQ3fxNfgsxxzyLvnbIUNpPXm2DKiREy+qzKkF5B9tpUgnjHObhQOrmQjLVCRUtFSzKjYgimvYPFzIm6JNF6UNFDiHJoau/YXNFS7G8V1OwhhnLqjqFYXTXSTUfGScDwYjOLvJJ69ASqlt4HlUINLVBanekTUKc3DtgCnPe6O03LRW3WVeGHVrQR9AtQ3QkohTACl/FQNILTg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1622835295; bh=mR6HFWnx2E37kgGckDc4fO8wM1T0QKQdBpzAbSDbtxn=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=iS+nn4YqZKCgF1WSDwx/1c6L5NbufoHkmVOsHb5JZVbwLiy/lmFsbEoyYrqrl+Clj/r6UJ89JEVjMrSDt2VDrVTB62yfGiUU3HcSry6vy22MyCQsIhimzLkfxId9nhmV3w9ViArD2/izRn6BXyRdiau5qzcMhksBuqd81ER07FZ2QZJcb/J2vD8/2agCZyy5AXvQQk9AjoWabCqYCu32/7xJPuM5a1Jl3xTWcMQQb5z9begaVNa5qEIp2I9VybbmoK1QtcG2p02Cr8EtQvy16JzNXxemkaZrOxfUpU12lryplcdLw7ZoUR3x8OWRaezmj+PXBFodMmu+fVXLiepIsQ== X-YMail-OSG: 99wY4R8VM1li.SFAW6A0S8iykT5gIQka15bUEVhzef725B7GsuLC4KijQodOg8f 3lszhKjMH3l8746eZGJU9eQctOC4M5cOltGp4MQPxMRnVSR3dt9E3pSy2f998Jc4b6whXImV62F. 24pqLL1Jtxv5FF.UVdzal1gnqulASVAwBu5zOEBf.NrROEZj.X963f1Bo_vuKOPDxt1OTaMG24rl P0cgmMaN.WWuK6i8XaTMukxtsqWp0bhpF0F0JpEE8gNx6ik1jLurZLdEfjvytGwEHoY3QjqCV15b xjM.kKyxGBCaK4tYxo0Iz9qosYloJIhV0tnNeIHGdMussVwlpk1bsczc5Pxz4YgR.nfDlfeVSHGt pfmV2mxqTcWfKwKO.YOcBNrhXYAtVCjOKgttXPGorm2aKI4EvEyuyqJIqiSLkCJETV8W9WZtvKBx r.pDNXdEcW6VOEde0YqAZjIj7KHhcXxK57jIHH6LwRF04ZD.I61J35pvgCJZQ9UWJmhusdq2aTNZ xhGx4boawaZXs02svH8WVtEk0AVtTucRs.Vw_3LmACs5G_TX_j0jM2SLvRXNBUbFPE.s.IReJxDf 1zu8O020pf1F0XuqYxatyDtZACQLT3iTkz7fDL7v0csj2JL6qBiBUzMR7rwTmcQBs8I0goUoB14H u2Gh79pVBJjO7gmNl3z0.sDoRvvA9orZ5azy.OP1_Kgit3kIYVP8t2F4Acsai9QqAi._trZmhawM kc6x9.hBA1cN_nmS6sYs0uHelwsJ8j7lEkUykiRXVLdpfEU3UYC0s2TY82ZI_mg.0qWQqLRAbYMu nRLYnTOgNmEt36wLARNq0aheo8YoQDy8rLcN_UK45IrWsyrkeYfIp5Z4T9KZkZch_T8jPxYW6Luf T3fnd43nLFHFBYmdq_fusYNMyp5elbzupy80hiw6P2FTw7o8dYg8aXtUIYrAlrvQ3_6PJ5qXBiM4 0gyOxsOHOtuSUPTZp90St3IUBY5leHz08zlYW2ov8qAXpWI6CcEve8zbsr5ynz862R.dU57Kx0r2 WTS22AZvrY4hZ6JfRrg.ZPkVMG4P.Oq_XGfBewSid1i_5eO2IZbOSN6nPzoIHlspxHvNgjeVvjhz Yna2fOVv5iAEDSy0icN_UIy4amFDPR3Jaaur9Qw.Alr57iPvMSRISPioEDkDB0_W_2u72qR4WGcS kNztMdbhFZFX566Vgt0dDmq1hdQcbeA_8B3nFiC1CbqtxvxhKCoO1vSaGZ7QhdOGBMaPt.Y1xyiv dymX6WX0u2KuKU5qiG2Ln4_Et33NIKGKxDAMYviTbAPT68yBcE_W0SbaXDkxHme0wDwAmZ4chj4X NCCkye5nJ6pfZ4pDTP0xL.xbigDDpLta.VKLAJevUwmxfxCRUP3xbilhXm.tUqXZGfDcPf.BDq5n Z5D929q.LclXcIP7k5xsi5LxAfE3MiytmX5MJDpUgKwoxC8FOnDspVQN_qhs3rowyTF6RkvxD9I5 A62S63hpLLiuHrCuaf4_Qh9czGz9WrUc8REjn_JkJyFvgs2WJTK.3xxx78QWMkvaZNmxn64NOTsk s3i83rXK9dS43jFy7i9HT1I2eELaNtLMFrCbBlyAmT7rcklJfPopbJX5_HsHw2W97USYr3SJAoDU 3.MgxMitt9zpw9y7XOy2W_9eUGesL2d4qkJ_0nncJCh3dB9cUbgkbOzR4ANSB9Z_4sgNVA84Fgp3 80A21iLe2lIrvJcuApE03ixUgIMQXFdwOvxCJvlmHb.W5NrM5A8R2WTTWzl7rpI3DLvVryf4XLN7 dhr5GVPTk61jedGEbHlJpbnzCdLhPwz0R_ujI5HX2swvjr_rlLzsnbHFH2.S7mMum1ykZvAlsdT2 8pJ.pP93T2LTQoLPFEPAkmbbQn9Opduvcv84ZyG048IwASZwSaYx8ShneWgRtm3bm3OiJCXXuM.a NdNcQRWQ247qv.pUKGZUTjH24ViRM_G8PiMDmLMlbUy1r3W4i2NJQ5NcvcEBnqJnIGbCAotRWikC kKu3b6HayfpXPBOsIxXsBHWDCgg0HgwRUzPRmEE_TpsZ.JkMnz_4JHneIp70nBfypQB7MoVgX25d Az9oyn7CopSFcBScmOsy9L6wmWouxtKTFQtI9baQVks61futrhtz8xfAdiXu8I5uS6PyHTGMsi65 0Tc15PNK4IIIo5lGUgw.hHaSoIDYvE.WVxEMZMhEKgBX0_EHPmLxacz_HsRT18ynRC.W.1nZp.O_ jDtvCjqQ0SDPMgXVIUsdZzoJVnDeqXB1c_SI2RWxusoYd_TuCqpxar2LuqZQHuTqHcPE8lNQ2Fju h2_5EqapSUYYvhe3GokGhbJ6fyk2dMuhwWlrGYNJBplUv7M_MPoCu1ulNnV5yRloBb4cyNkfm6c2 4jp4yQ0bhQvcJPYT840MB5WXCig6S9D2dh_Av47Sr3F3Jf_u.HBVXkowr2dbD5ScSoqPYed_ossz MAM_fjCKfY6kyYypB.exxTPf2KMPYMQ-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Fri, 4 Jun 2021 19:34:55 +0000 Received: by kubenode508.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 46a8199c5ebf03f95031352f979afc16; Fri, 04 Jun 2021 19:34:50 +0000 (UTC) Content-Type: text/plain; charset=us-ascii 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 (Mac OS X Mail 14.0 \(3654.80.0.2.43\)) Subject: Re: Can't enable SDIO wifi module on PBP In-Reply-To: <202106041107.154B7cQD087733@kx.truefc.org> Date: Fri, 4 Jun 2021 12:34:48 -0700 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <202106041107.154B7cQD087733@kx.truefc.org> To: KIRIYAMA Kazuhiko X-Mailer: Apple Mail (2.3654.80.0.2.43) X-Rspamd-Queue-Id: 4FxXz54zGkz4h2Q X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-arm X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Jun-4, at 04:07, KIRIYAMA Kazuhiko wrote: I do not make any claim that the below notes are tied to any sufficient changes to enable SDIO wifi. They may be more general/generic. > . . . > uma_zalloc_debug: zone "malloc-2048" with the following non-sleepable = locks held: > exclusive sleep mutex SD slot mtx (sdhci) r =3D 0 (0xffff0000411c6030) = locked @ /usr/src/sys/dev/sdhci/sdhci.c:617 > stack backtrace: > #0 0xffff0000004d819c at witness_debugger+0x64 > #1 0xffff0000004d9320 at witness_warn+0x3e8 > #2 0xffff0000006f9084 at uma_zalloc_debug+0x2c > #3 0xffff0000006f8a8c at uma_zalloc_arg+0x2c > #4 0xffff00000043fa18 at malloc+0xa0 > #5 0xffff00000000f550 at xpt_alloc_ccb+0x1c > #6 0xffff000000034ee0 at mmccam_start_discovery+0x18 > #7 0xffff0000002506fc at sdhci_card_task+0x110 > #8 0xffff000000255460 at sdhci_fdt_attach+0x5b4 > #9 0xffff0000004a3b34 at device_attach+0x400 > #10 0xffff0000004a369c at device_probe_and_attach+0x7c > #11 0xffff0000004a5880 at bus_generic_new_pass+0xf8 > #12 0xffff0000004a5830 at bus_generic_new_pass+0xa8 > #13 0xffff0000004a5830 at bus_generic_new_pass+0xa8 > #14 0xffff0000004a0ae0 at bus_set_pass+0x4c > #15 0xffff0000003f644c at mi_startup+0x12c > #16 0xffff0000000008a8 at virtdone+0x6c The above may be a problem that needs to be fixed overall. > . . . > lock order reversal: (sleepable after non-sleepable) > 1st 0xffffa00001026558 dwmmcsim (dwmmcsim, sleep mutex) @ = /usr/src/sys/cam/cam_xpt.c:2802 > 2nd 0xffff000000c12a30 Clock topology lock (Clock topology lock, sx) @ = /usr/src/sys/dev/extres/clk/clk.c:1154 > lock order dwmmcsim -> Clock topology lock attempted at: > #0 0xffff0000004d7e7c at witness_checkorder+0xc50 > #1 0xffff0000004743e8 at _sx_xlock+0x7c > #2 0xffff0000001ac808 at clk_set_freq+0x4c > #3 0xffff00000078a998 at dwmmc_rockchip_update_ios+0x3c > #4 0xffff00000078a3bc at dwmmc_update_ios+0xfc > #5 0xffff000000789854 at dwmmc_cam_action+0x14c > #6 0xffff000000009c34 at xpt_action_default+0xca8 > #7 0xffff000000008f5c at xpt_action+0x270 > #8 0xffff00000003633c at mmcprobe_start+0x89c > #9 0xffff00000000cc10 at xpt_run_allocq+0x104 > #10 0xffff00000000cadc at xpt_schedule+0x230 > #11 0xffff000000035a78 at mmcprobe_register+0x2a4 > #12 0xffff000000003b90 at cam_periph_alloc+0x528 > #13 0xffff0000000354dc at mmc_action+0x484 > #14 0xffff000000008f5c at xpt_action+0x270 > #15 0xffff000000011750 at xpt_scanner_thread+0xcc > #16 0xffff000000424198 at fork_exit+0x74 > #17 0xffff00000076716c at fork_trampoline+0x14 >=20 The above may be another problem that needs to be fixed overall. These lock reports do not look like the typical "just ignore the message" ones. (But I'm not competent to make the actual judgement of status.) > . . . =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Fri Jun 4 22:45:48 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 9420B856FB8 for ; Fri, 4 Jun 2021 22:45:54 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic315-55.consmr.mail.gq1.yahoo.com (sonic315-55.consmr.mail.gq1.yahoo.com [98.137.65.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4FxdCP2G3Wz3Fdt for ; Fri, 4 Jun 2021 22:45:52 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1622846751; bh=OHBPehmWH+ijLC/Ept7ih2q1lz1A6ihyThIvpH5/bMI=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=Bsj7xM9OcExMSGTmWLZK9RIn5v2oLtLgkD/E/EIMms+q2dYBz/ofiq85Tp47Ii0A7J1XQU4le7Zd9YaUqFvEjOWI9x/dMS0RQVS2HiVCiq0yOWeP2EwuWjs4BDz4dU6wKIIcYxvrd0YHXuhfk2cWMVgg+as5hf3MttROrOc8iKVux7rXqk6RoXzdBcl9AcAgTd07xZzRsRIArOdR3OfupR/HA//H+Y+ZgsXyudPSJb0bli1cAzx30qX/z0HAqV8/gLs1PhPhql8YaDkW8Ppiqwb923glWUxZyyCuWZuH0XyIhaUSK0gSpNNZrI5i+IR0k0RKA1bADhpP5k9Y981bmg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1622846751; bh=ygs3SR74J3EOsWzdDTXutX+oDsLjUYUhIph3sI/f1RI=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=e109f273saGvI3WwKGDcVX+Xq7bCuGnc6X3WxjH59ICfIDudYgug3R4veV+BcL7YLH12bwKPgOiM+PBIMlmFz2RuDa878OKSMdhTAKWkAP1hO1paD8jjdHD5iwNm5+ZGLyy7gDU/O/gxgPALJ5m1ZBHT4etT3pT2W/+hmLvOwO9MytiIiAZlg+oD5YWfSx+hE9QkG9Se0PSVGL8ZbpAmwdZ58fz7uQeUQfZjUyeAqa19B0/QXDyAKY+K+Iz1pdMXlJGNzl21hL+8mv+N/v44NysHNB//0Ny2jpVnMZDBDbYEmpt/uyIjUPJWkdTuFgVg3R7S0G4DKNob6sCYGkIBGg== X-YMail-OSG: I8uQ3akVM1l2VpDsuJ06xaLsyYRAsdglC1gB77J2H7rXhOi4NjeZkTnyRmGk71o A7p1YUJ2M8u_RHDJpdpMs86irsOI3clYVBxn1RQi4Y0OE3mLsArZOFXXaThT3HzgiXIKN3n9GKIX K2IkhWqJZCBZET2glpF05yi8yN36EwxDZv44MqrVBJfjMECWqW2sZeHXLXfEeIiuXB_hq2o1ArwL Flbs_Vo_JfqvRXXmYE0nDULTxBmpYuHLO1EAQwA4iKKpk0Qm9XyZp_dRdphR9jnRwPJx1rS1sRoV DL1Ggah.0GktO20dgr5QaTiqFk2PTg85yBi3oI6aJ_OOHsEV_cynKqh3lJdUpen63NhmERJ3vXYo 56h3mTuIzWWpygXA68uVMd_svr8JSzV76HKHU0IK5RigFs0yroJ37T6Ugvq6mrI8.ru3av7Cwz.z k7LRACsc_uCNzTSY5Qz3JgfNsrpSCZ4l3NLZsE8VdXnQaAUcTFVrLD.d90sdxPhDrU2hcYgGM24g hGa9h0k_YQW3qolW8KKNqWFfwzqqoAXZlebXgpOWRZ6QaP3SJMdlpqEzh_2gKCMPSLp.pOXpwYpd n5JCxmW8wZN8EOUUkBTw4uEY7LUi0MULySzC.sexObRU0GKeaTYmICaW6ujUr2hABVeS2fesULag FilIWSGvVa0GpsKTIyFfBh8ThIz_KcaB5K5w5gyuwgDo1oduydYzK1aCux03xBh5V7bDu633BcPk XuGhMZf1OxLes0i.E55Ffq2l6pe66D.0OJl7i9JsoCjctmeccxy5MqChNu3gsgb6KKZKiJU5neG9 elXtrzxuOshdFczzzrBgCzkcXxKl.7K8zOLQBGVtc43Rm_txZDnjf8kXWWckQbStDzgnsBnFs.uK 6onnlGZ4tMxH1vcOHQhR2mRZNsjz2hiE4J6YZrj8VQngUzWjma_uyCGalIFHX78To_U6U3GPHepJ 1BGD9G2xLrxWpQiAUzne8zzf0b2PBp7LiLH1R2NMIPgpgRJqkVSNvBZMKIWdRWDJgD3aJJfM4q4h QRiUP_Yvr1vV6CJkRCROQuf18zQnwVULX86ydO3tUivUhI29rankEt9za7uUhvyD6bUNh0DMZQsW q9QS5E6MF8CdCYzflfXMdjSbTQFsvzsgPjfaaRIWrYop3hwTE1Q5yt73ShavEjadsHOntdusHWqq Q5AUYUu_zeRdvrB4.M2s7EZM.WoA3jZn3O5SXZMIM27iRdNaEP0vIF9nHbaY2lbC_TwUaf23puem 8_MMfCT_rIrV6ho6nLlmEjpJySLBGGcBH4aD9A_uTWc2WgvbeNHTvTcvOiBC2BWGHdfU2DbiPmbB bjiOVb31fsp9vsf26eiNs9uy5f2lCHDlh8tNN9XfgaPpm.W55FupIpeLpkTWIy0WWbnlS.jOlE0s utUYOvIdeqVpY.X2zrFBc6wcjA9eXGcFNSKbKF005ztRlBWa155kouu07Et4CPGkSnx4Hj0OxUtz NKydawHJsA24JVRALUmX8g.xyENWqDB5h.HN9TKXn.4gNN5t3qpwe3B4fqsSO7sIT2QIDpEDO5iG AwZ9OFNn3PWHG73U4zqT48S29EBTz1Dh2PY77ON49tA869dCKuwQaCqLDNVvTakqzZqiwuHwlpMa f95RzeIwhUbgIlBDvDNjyly0zImR0SvZfRdXx481bXAiwsnjzr2mtJzFjv5HcU5QxmTKNMXt1Zl6 itsvcc9UQ9HP7d.t_n0kfrslkRHWbAQy3mB_gA6ueuPUnVi.n_2n0TcWE16RersJWCQZ_MlnIw96 C8RwYGSQnQmhIPjOHvVJoX3Oh3N5.kLD4.3nKjNqK7fhu3PQNHepuE.FF1rQo6sNX1aiKGmEFevk fJ7w0z1B9HE2.u3Eowp0WsFG38Sg2A2byz0EUVTRsxSFaXlkLSDUYNrdozS4GRyw7o8bcFUp0jrk D5Ij7daHX5loblJmHi6m9lJ8yGMpBZmIBHwAzJAYwWPxR_RWRazwYuaRkK3TQJAbleHpOubhfUwV wmFat5J4Kgj6UFlahF.Z1H7UOOXvR4hOsl.dN2_rYIvqw7gxf8OSGeGMoWyqQa1nzDMMZXwd1QoC jk1rjzm1oxVRwgsmf_SbLNaRVOVKTn9S5MJC90tQzIn0FjJysJaCs93.0vIdsvCwWulQBNFpNhWI j5WjYNWkk6qRq2UfwuYX.tnXWLp9T7U1.EDc1aGVO6rQb.EXBhsVJB4xPzitqZqRm3Iis4nSz5aO _CEjnw17WLyC.qdaiSWNkqWQSKYnH_zcwp_cIIRNzsUtZ9lFWA1tpYeR1EMrm1dvy8eom5BQjg60 wDuv9uKtlve4CebKD6rAroRnAf6MDLW0s6XBLbejcaJUIly1srwFyxKM.N2afO_tzpYwMMcvnZ49 MEdmYzS.x1v5u3Fmmu.DVyC846y6UhNMrnv1wCqH_Yb5s3v13luk0iMIzhi_26ayFDqGT37tqEQ3 5dI.18iwdEC_CFiZHGbOPVVVrU1456ylsx_xsDB8bF6W5eyvcN3GqFglLwLAL7BBrLCMExQnK86e X0nDYBiFFHpHt X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Fri, 4 Jun 2021 22:45:51 +0000 Received: by kubenode564.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 664bf94da1f348e67cb0ef158cb16ea6; Fri, 04 Jun 2021 22:45:48 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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 (Mac OS X Mail 14.0 \(3654.80.0.2.43\)) Subject: FYI: A discord report of i2c config.txt / loader.conf settings preventing boot on some RPI4Bs Message-Id: <47B2558B-63EA-4470-9982-1BFD291B0D61@yahoo.com> Date: Fri, 4 Jun 2021 15:45:48 -0700 To: freebsd-arm X-Mailer: Apple Mail (2.3654.80.0.2.43) References: <47B2558B-63EA-4470-9982-1BFD291B0D61.ref@yahoo.com> X-Rspamd-Queue-Id: 4FxdCP2G3Wz3Fdt X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=Bsj7xM9O; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.31 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RBL_DBL_DONT_QUERY_IPS(0.00)[98.137.65.31:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[98.137.65.31:from:127.0.2.255]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.31:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.31:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arm] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-arm X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N For reference: QUOTE Orum: from config.txt on the root of the ESP I removed: dtparam=3Di2c_arm=3Don dtoverlay=3Drpi-poe and from /boot/loader.conf I removed: iicsmb_load=3D"YES" smbus_load=3D"YES" Orum: it worked fine with those on the older Pi I have (2GB) but = wouldn't boot on the newer Pi (4GB) (both with PoE hats) END QUOTE =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Sun Jun 6 04:31:52 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 D4DF2951602 for ; Sun, 6 Jun 2021 04:31:59 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4FyNrG5KHwz3KD8 for ; Sun, 6 Jun 2021 04:31:58 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 1564Vr3i094628 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 5 Jun 2021 21:31:53 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 1564VrX2094627; Sat, 5 Jun 2021 21:31:53 -0700 (PDT) (envelope-from fbsd) Date: Sat, 5 Jun 2021 21:31:52 -0700 From: bob prohaska To: freebsd-arm@freebsd.org Cc: bob prohaska Subject: Strange u-boot behavior Message-ID: <20210606043152.GA94545@www.zefox.net> 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 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Rspamd-Queue-Id: 4FyNrG5KHwz3KD8 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of fbsd@www.zefox.net has no SPF policy when checking 50.1.20.27) smtp.mailfrom=fbsd@www.zefox.net X-Spamd-Result: default: False [-1.09 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; WWW_DOT_DOMAIN(0.50)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[zefox.net]; RBL_DBL_DONT_QUERY_IPS(0.00)[50.1.20.27:from]; AUTH_NA(1.00)[]; SPAMHAUS_ZRD(0.00)[50.1.20.27:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.99)[-0.994]; RCPT_COUNT_TWO(0.00)[2]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arm]; MID_RHS_WWW(0.50)[] X-ThisMailContainsUnwantedMimeParts: N For some time now I've been booting an Rpi3B+ using a microSD card configured with U-Boot 2019.10 (Mar 17 2020 - 22:01:14 -0700) by stopping it at the u-boot prompt and issuing usb reset followed by run bootcmd_usb0 after which the usb hard disk boots and all is well. Lately, usb reset has taken to reporting resetting USB... Bus usb@7e980000: scanning bus usb@7e980000 for devices... Device NOT ready Request Sense returned 02 04 01 5 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found However, usb tree reports USB device tree: 1 Hub (480 Mb/s, 0mA) | U-Boot Root Hub | +-2 Hub (480 Mb/s, 2mA) | +-3 Vendor specific (12 Mb/s, 90mA) | FTDI FT232R USB UART AM00FGTR | +-4 Vendor specific (480 Mb/s, 2mA) | +-5 Mass Storage (480 Mb/s, 0mA) ASMT ASM105x 12345678D558 The problem isn't wholly new; the usb reset command sometimes had to be repeated once or twice before the disk was found. Now it seems a persistent failure. Once FreeBSD has booted, the disk is seen and accessed as usual. Thanks for reading, any hints appreciated! bob prohaska From nobody Sun Jun 6 07:11:20 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 1169F9582CB for ; Sun, 6 Jun 2021 07:11:26 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic308-54.consmr.mail.gq1.yahoo.com (sonic308-54.consmr.mail.gq1.yahoo.com [98.137.68.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4FySNF5WQNz3lx6 for ; Sun, 6 Jun 2021 07:11:25 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1622963484; bh=KlpCLey50x5y7idbmZnlzECGNrqjjQduykBHlyW81oM=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=TTaavY6S8nNJFZj+PAvtZROthekqc8EFu+bwqjB4FuQaSBdxzp1rXoytCMUkDwB+n9BhlggEr/9FjPwPeQjVSak83T1TeQHWSZryk1TyqLR050FVCi1ZD+oMBRQ9Glv7sj9e9lKf3DHrdiamWBhoC0PLCaLECn3lrs6wJl5Z+V8M6U+fXInN2fDDVqHeQpwGDJei2vTFqfS3gq7BWFfRKUSGfxD+dcNnCl0uBVG+dkExmP+JZzUmfXUyRyShwn8sGjSJZJOH/akbj1fBLcH90dewYqJ93N/FL/nkm2Fd2nLUlo/Siq+AYLQPsfTyKNqa+K2mOqxtFzUdPM3UeSE5rg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1622963484; bh=4Z6Cr8sMXN0Sb0UFzwcLg54IAopEwqFOKnpBud6Wksm=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=OpEi20l5NbETWNQMp8ZVPjl+Yw4OOi/XnBB8cuTDnwScidtkBfEMK/a5Gk2xpOIlTcR9DsqvvxU3npx1KghANzc7kqv5XxETo/KJgLkXgceByBQR/ROZqT8wRKvcmLcfgRASj//pRhCB3sKM6qYQc/VYqSX4/ZXsC3fs/Tu2WcJGgh8uvShvRDsu3Mu+1JHKqXMRe1w5Q9ht0A7LnCjogeHjoK94sX4LZxNA3w3kfo44/GBvHsTYPt98kZSnczM2fGoZr9l9vbuh4oIVgPWsnCcHG7Mrs0JpH/A8cTvS3QfJbg6LHTX9Nd0X92DtSmKjCPmiNfVBtDhjCn5A1Iqvzw== X-YMail-OSG: NZkY.AsVM1k5ETtOnEVm4QtUDCun4ziWxLPd3uYqb0A2zKPWNmrrCwe7CtoVkSw 5YZwjO..MMqW8ryijhKVPWiV5XlJHfvoNPQ1_nsMowe1.tGBUxhaaiGTub3DQu6mqAeaw8Gjc1uJ lm0xsIE.0CSlZXYA8rCbARVyn5VaMJhvzlbN.HONA_AkRdc4BfE3YueAuw5EsL7TrwZqYJVEOpLq 1EITKYqrKqVCwHCcsv1M1dNcGWOF3P0Ye_kKBP1YO5MDa_SD3E9TTIY9z6udAWkYTZE_bQ7.2JEJ 1tilK.MGWTMxXQEnakXTjNVlakX1ImwcKYMAXSkQSvS8MQyo3E0m94Jhh.xECeazjkWY8tpjd2aL EQK09UHcpH_XmrNxmUQ.wY8VFekJlydJob.cJrrFNgGvBvUJid3LroPKfEj.I_38sJEMxYdxPn8y p9uTeU3nqq8NT36FnjuVOilSQUek0119cbjqdlj.7NBpUZNgI251WDWZl0.sq4832JalKowjW39P AvixnqwnmSJrSfdf2ZXjn17X8egM89a.JD8WqTs81tjr3f0Gi5hxwshyXjtFKMK0J0t7SA06xfnk YT4JxKqm1DhABsw4VQ6EG2O8_9BmfhNgstWZigdtSFo81i43po9yvHGZQEDYXtT4CWFtaAIEkaqp cSamNBxMF7aujNcWuqzdWrY9QhTNgR0AuKMNUfNGrSc8PBtcBtz4ajrXLMfS6uQWQXbS6oOwgaCn IgohGiaPDu1rfosuf.pbe2cF67o4OKQMp4cRY9ZoWjYt.IzUtq.hGnGXHlBcbUY4r4uUo0tnbICf saEDmafeVYugT2htgrbcTKorY3zhGp8g5PEWQtoJ2nReqd2oGVc4qOoDnfGpCjuEQnYJnc5kdYc7 2MGRBF8yUvqi3Uu0COszzs8J7sF9oGPbvcXUXYlJIGjJ1Hrektf9f7javcm6vOEtHR2W6.LdQNDD Eub0um3U3CkldkPmT36GrnuA7bY6gd9KOgt_Nc7bFGH7iezLraOhGXuKqmfjk1ied947.c2DmMb. oZMYhJ89YOZAsmn0Tj0DbvocpXmfI_qS0CNrUtWfYdNuVzIx6Dfd9Xs26gYz6s5arfLpiGnAHde_ AtOsmqKduHGSa7pB.7Soab5YiwXC_82XUieVnoyycXZ7aY22HlhgBBp8t6fgT9kXNwjs6BuR27v9 cBk7Y0h8f1.6vyU.UHCm.Dfr8KLSsXeaq5lhD0YQNvlQydQvux2g5ZEM9UoQI3JpnrIzqcffdDV4 8TYQwELANiNkWIXHfglJkG46hpyDTskp805wH30Mt4jZ2kQ07OEYXRm7zj9X21MMc0TdhgnwWiV_ j7fzsOJAC74uBmbXXpMn2Dnkwnk94b7ZlG5FXo3isopWmmvWu9GAqVv8IYUGQYD3TmRIj4V7HQIb uz7QG1RIh71UKtccNsyNZsCXhDzsQ6.v_plvJb1gOs2zdENYW_cBu7h7cjRbr_Iss9ARTXzQf0K4 _Hr..3j5TVl1H5qxjc2zdUpaZymzT4JSfD90Ik18bbK7foFlRG51id3ssURgylHs6MjvCB3ucPaT JaMMY8O_Y_juN86EPh9ZpVXLK9BP.Pp.hR2opFzXZ8D2SEFCVRZ7UlZ68tU3im_El4z6VRWOkfIi 53Zv.Rb779NN9WwvNEPI3TaPRMVsSwQdYrw8dC2B_KkytrKbKXXmM18fZK6iIoe0ituzaEWWETEi QrkUfNHRv5YcmGo78ilLQ.Ral9haF7yQzDtSNGGXVPppCAcP4ngmX1yek1ClTP0ZL67rXTrzqC9F wzP30V.za8tUGhGvRMIXNYX1P8rLV8D2nZ7JdSuJmEeBKJQf1VUcPQ8bb41upiYrrYl.qB1uwa_n 8KWxK0.lIlecIxLKMQoRI845d0PfXlCOSrkriP8KHJsnrD_iwnAWepw8g4wkzscUAqVvO_DMBqy8 AgM2lHnulz4wBn8jvoSrPAuoknaBd1xmTuW99_zYLSzBY1QwT2EVJ4VOPPlYkqBS3hduToI8uhiK Jhk0RIQg3iYBQNT_.LAAZbrF9I2qXXG8FSgId4daX1lfnjQi0OgCe2VdRv4MXI0NWrAPrSvsUryZ SxfII40rKAkHW5yaZYDQzH57M5Wvk_oQCJvkhnl0ioqvB9mITZweYr.OfV1gEd5BIsNF1b3UnWw1 0rcTgHBV3yIekkxxzvDZFTMCRVTapOr2XPOj8vgGTnc2BXuT.n1WzuqLaviwBVL4G9_F7kB8Yiu2 n8ZKWQL7yKey6.hRQYCOSDBmXYmkMRrCagwR.8ftbpvXOFtAvKJv6KWlxYMKTpWlKrJPbB2l5DJ4 iNDX205vQ8seliFAgyLdGdYsg63NkNtwxFyp6IdJ3pAa1lVwElzWp7XswgtbZUaqX4_ksJ1qU2ik g3wQyobm8j0wMFf0mRA0TehZvTLzVXwYf7pONDRo1dfGn8IJQELskwcBU70PCXNhtSKxCOaGNrcq 4ihQnGwW6qbYd1V.5Bwo8DhJNgDLOS4X5ZRKXVQT0JZEl.pyKkSE8nhmg9ep75zRJ7.GwHqDs4An M8A-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.gq1.yahoo.com with HTTP; Sun, 6 Jun 2021 07:11:24 +0000 Received: by kubenode569.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 42e0b73b08b1a0f83e2f0eb5f83d4fb9; Sun, 06 Jun 2021 07:11:21 +0000 (UTC) Content-Type: text/plain; charset=us-ascii 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 (Mac OS X Mail 14.0 \(3654.80.0.2.43\)) Subject: Re: Strange u-boot behavior In-Reply-To: <20210606043152.GA94545@www.zefox.net> Date: Sun, 6 Jun 2021 00:11:20 -0700 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <27786296-8C55-4CEC-A587-14BF4465A4F8@yahoo.com> References: <20210606043152.GA94545@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.80.0.2.43) X-Rspamd-Queue-Id: 4FySNF5WQNz3lx6 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-arm X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Jun-5, at 21:31, bob prohaska wrote: > For some time now I've been booting an Rpi3B+ using a microSD > card configured with=20 > U-Boot 2019.10 (Mar 17 2020 - 22:01:14 -0700) I'm unclear. Do you have the whole msdos file system content on the microsd card and only the FreeBSD UFS kernel+world on the USB drive? No msdos file system on the USB drive? Some of the confusion may become clearer about why I might care in my later notes. Another question: why still U-Boot 2019.10 instead of updating to match, say, what is on modern RELEASE or snapshot builds for the version of FreeBSD that you are using on the RPi3B+ ? You seem to be using a generally not-used combination by sticking to an older U-Boot but updating other things. What RPi3B+ firmware version? This can be found via: # strings start.elf | grep "VC_BUILD_ID_" Depending on what is reported: this might have questions about the vintage used. > by stopping it at the u-boot prompt and issuing > usb reset > followed by=20 > run bootcmd_usb0 > after which the usb hard disk boots and all is well. >=20 > Lately, usb reset has taken to reporting > resetting USB... > Bus usb@7e980000: scanning bus usb@7e980000 for devices... Device NOT = ready > Request Sense returned 02 04 01 > 5 USB Device(s) found > scanning usb for storage devices... 0 Storage Device(s) found >=20 > However, usb tree reports > USB device tree: > 1 Hub (480 Mb/s, 0mA) > | U-Boot Root Hub=20 > | > +-2 Hub (480 Mb/s, 2mA) > | > +-3 Vendor specific (12 Mb/s, 90mA) > | FTDI FT232R USB UART AM00FGTR > | =20 > +-4 Vendor specific (480 Mb/s, 2mA) > | =20 > +-5 Mass Storage (480 Mb/s, 0mA) > ASMT ASM105x 12345678D558 >=20 > The problem isn't wholly new; the usb reset command sometimes had > to be repeated once or twice before the disk was found. Now it seems=20= > a persistent failure.=20 >=20 > Once FreeBSD has booted, the disk is seen and accessed as usual.=20 What alternatives have you tried? *) Have you tried starting a boot sequence once with program_usb_boot_timeout=3D1 in config.txt , per notes in: = https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/b= ootflow.md This programs a One Time Programmable bit to cause extra some time to be allowed. The program_usb_boot_timeout=3D1 does not need to be kept in place. After another reboot (to a RaspiOS in order to have the command available): vcgencmd otp_dump | grep 66 should have bit 24 set in what it reports. This might only be useful for option (B) below. I've never found wording specifying the range of modes that this adds time to. But it might apply to all or most modes. @) Have you tried any mixes of bootcode_delay=3D???, boot_delay=3D???, boot_delay_ms=3D??? in config.txt ? These are documented in: = https://www.raspberrypi.org/documentation/configuration/config-txt/boot.md= bootcode_delay can add time before any start*.elf is read from whatever media --but it is not clear if the config.txt containing the bootcode_delay=3D??? and start*.elf can be from different media. boot_delay and boot_delay_ms control waiting some amount of time in start*.elf before loading the next stage (U-Boot for FreeBSD's normal sequence). A) Using a microsd card with only a modern bootcode.bin should be able to have the rest of the material on the USB device, including U-Boot. This way tends to have more fixes/improvements than depending on the internal support for direct USB booting: It supposedly works for more USB devices. I do this on a RPi2B v1.1 that does not have support (B) below. I have done this in temporary contexts on a RPi3B where (B) below seemed to have a problem for some reason. Dealing with booting from (some?) powered hubs can be a type of context where this proves useful. See: = https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/R= EADME.md and "Special bootcode.bin-only boot mode" in: = https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/m= sd.md If the msdos file system that contains bootcode.bin also contains an empty file named "timeout" it will wait longer for a USB device to be ready. See "Known issues" in: = https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/m= sd.md B) "The Raspberry Pi 3B+ supports USB mass storage boot out of the box". So, unless some of those improvements metioned in (A) turn out to be necessary, no microsd card should be needed, presuming that all the required material (including U-Boot) is on the USB drive. I do this on a RPi3B and RPi2B v1.2 (after enabling them: not "out of the box") and all the RPi4B's. (Some RPi4B's required eeprom updates to enable this.) This does not give any control over getting extra time for the USB device to be ready: it would first have to have already read something from the device. But the details of this might be better than the details of some specific microsd card based RPi3B+ firmware boots. I.e., it might be worth a try. C) I will note that it is possible to have the FreeBSD kernel also on the microsd card in a UFS partition and to have "world" on the USB drive. This leads to only FreeBSD's kernel and later using the USB drive. But keeping the copy of the kernel and such on the separate media is messier and atypical. (Note: I do this sort if thing for the ROCK64 where the dd'd U-Boot does not support USB for the FreeBSD loader to put to use. I defer USB first-use to the kernel.) =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Sun Jun 6 14:50:43 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 5E74395194D for ; Sun, 6 Jun 2021 14:50:43 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4FyfZC0yWgz4tbP for ; Sun, 6 Jun 2021 14:50:43 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 0795D2524D for ; Sun, 6 Jun 2021 14:50:43 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 156Eog5Z054377 for ; Sun, 6 Jun 2021 14:50:42 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 156Eog0Q054376 for freebsd-arm@FreeBSD.org; Sun, 6 Jun 2021 14:50:42 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 256441] U-Boot build for Raspberry Pi 3 (arm64) does not boot from MicroSD card slot when >1 USB storage devices are present Date: Sun, 06 Jun 2021 14:50:43 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 13.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: rleigh@codelibre.net X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated 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 X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D256441 Bug ID: 256441 Summary: U-Boot build for Raspberry Pi 3 (arm64) does not boot from MicroSD card slot when >1 USB storage devices are present Product: Base System Version: 13.0-RELEASE Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: rleigh@codelibre.net Using 13.0-RELEASE image on a 16GB SD card, written using the RPi imager to= ol. With 0 or 1 USB storage devices inserted, the system boots fine. With 2-4 = USB storage devices inserted, the system will not boot. Looks like U-Boot is getting stuck in this situation and not able to read the second stage bootloader from the SD card mmc0 storage. May be related to #255080 I have transcribed the console output below (may have some minor typos). With 1 USB storage device inserted: ``` Net: No ethernet found starting USB... Bus usb@7e990000: USB DWC2 scanning bus usb@7e980000 for devices... 5 USB Device(s) found scanning usb for storage devices... 1 Storage Device(s) found Hit any key to stop autoboot: 0 [boot continues successfully] ``` With 2 USB storage device inserted: ``` Net: No ethernet found starting USB... Bus usb@7e990000: USB DWC2 scanning bus usb@7e980000 for devices... 6 USB Device(s) found scanning usb for storage devices... 2 Storage Device(s) found Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found EFI removable media binary efi/boot/bootaa64.efi libfdt fdt_check_header(): FDT_ERR_BADMAGIC Scanning disk mmc@7e300000.blk... ** Unrecognized filesystem type ** Scanning disk usb_mass_storage.lun0... ** Unrecognized filesystem type ** Scanning disk usb_mass_storage.lun0... ERROR: Failure to add disk device usb_mass_storage.lun0, r=3D20 Error: Cannot initialize UEFI sub-system, r=3D20 125912 bytes read in 125 ms (9.6 MiB/s) libfdt fdt_check_header(): FDT_ERR_BADMAGIC Error: Cannot initialize UEFI sub-system, r=3D20 EFI LOAD FAILED: continuing... MMC Device 1 not found no mmc device at slot 1 Device 0: Vendor: Generic Rev: 2.00 Prod: Flash Disk Type: Removable Hard Disk Capacity: 7680.0 MB =3D 7.5 GB (15728640 x 512) ... is now current device ** Unrecognized filesystem type ** Waiting for Ethernet connection... done. BOOTP broadcast 1 ... [boot never succeeds] ``` --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Sun Jun 6 16:00:40 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 53681955C98 for ; Sun, 6 Jun 2021 16:00:42 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Fyh6x5H1Nz3GfZ for ; Sun, 6 Jun 2021 16:00:41 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 156G0eF4097955 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sun, 6 Jun 2021 09:00:40 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 156G0eOZ097954; Sun, 6 Jun 2021 09:00:40 -0700 (PDT) (envelope-from fbsd) Date: Sun, 6 Jun 2021 09:00:40 -0700 From: bob prohaska To: Mark Millard Cc: freebsd-arm@freebsd.org Subject: Re: Strange u-boot behavior Message-ID: <20210606160040.GA97697@www.zefox.net> References: <20210606043152.GA94545@www.zefox.net> <27786296-8C55-4CEC-A587-14BF4465A4F8@yahoo.com> 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 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <27786296-8C55-4CEC-A587-14BF4465A4F8@yahoo.com> X-Rspamd-Queue-Id: 4Fyh6x5H1Nz3GfZ X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Sun, Jun 06, 2021 at 12:11:20AM -0700, Mark Millard wrote: > > > On 2021-Jun-5, at 21:31, bob prohaska wrote: > > > For some time now I've been booting an Rpi3B+ using a microSD > > card configured with > > U-Boot 2019.10 (Mar 17 2020 - 22:01:14 -0700) > > I'm unclear. Do you have the whole msdos file system > content on the microsd card and only the FreeBSD UFS > kernel+world on the USB drive? No msdos file system > on the USB drive? It's a dual-boot system, with a complete FreeBSD-current install on both USB and microSD storage. > > Some of the confusion may become clearer about why I > might care in my later notes. > > Another question: why still U-Boot 2019.10 instead of > updating to match, say, what is on modern RELEASE or > snapshot builds for the version of FreeBSD that you > are using on the RPi3B+ ? You seem to be using a > generally not-used combination by sticking to an older > U-Boot but updating other things. > Purely inertia. U-boot doesn't update via the normal make install cycle, requiring a careful reading of notes for manual upgrade. It was usable two months ago, though not without hiccups. > What RPi3B+ firmware version? This can be found via: > > # strings start.elf | grep "VC_BUILD_ID_" > # strings start.elf | grep "VC_BUILD_ID_" VC_BUILD_ID_USER: dc4 VC_BUILD_ID_TIME: 15:31:38 VC_BUILD_ID_BRANCH: master VC_BUILD_ID_TIME: Jun 7 2018 VC_BUILD_ID_HOSTNAME: dc4-XPS13-9333 VC_BUILD_ID_PLATFORM: raspberrypi_linux VC_BUILD_ID_VERSION: 4800f08a139d6ca1c5ecbee345ea6682e2160881 (clean) That's old, but it used to work with this USB train. > Depending on what is reported: this might have > questions about the vintage used. > > > by stopping it at the u-boot prompt and issuing > > usb reset > > followed by > > run bootcmd_usb0 > > after which the usb hard disk boots and all is well. > > > > Lately, usb reset has taken to reporting > > resetting USB... > > Bus usb@7e980000: scanning bus usb@7e980000 for devices... Device NOT ready > > Request Sense returned 02 04 01 > > 5 USB Device(s) found > > scanning usb for storage devices... 0 Storage Device(s) found > > > > However, usb tree reports > > USB device tree: > > 1 Hub (480 Mb/s, 0mA) > > | U-Boot Root Hub > > | > > +-2 Hub (480 Mb/s, 2mA) > > | > > +-3 Vendor specific (12 Mb/s, 90mA) > > | FTDI FT232R USB UART AM00FGTR > > | > > +-4 Vendor specific (480 Mb/s, 2mA) > > | > > +-5 Mass Storage (480 Mb/s, 0mA) > > ASMT ASM105x 12345678D558 > > > > The problem isn't wholly new; the usb reset command sometimes had > > to be repeated once or twice before the disk was found. Now it seems > > a persistent failure. > > > > Once FreeBSD has booted, the disk is seen and accessed as usual. > > What alternatives have you tried? > > *) Have you tried starting a boot sequence once with > program_usb_boot_timeout=1 in config.txt , per notes in: > > https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/bootflow.md > Just tried it, usb scan still fails to find the mass storage device while usb tree sees it. > This programs a One Time Programmable bit to cause > extra some time to be allowed. The > program_usb_boot_timeout=1 does not need to be kept > in place. After another reboot (to a RaspiOS > in order to have the command available): > > vcgencmd otp_dump | grep 66 > > should have bit 24 set in what it reports. > > This might only be useful for option (B) below. I've > never found wording specifying the range of modes > that this adds time to. But it might apply to all > or most modes. > The "boot from USB" OTP was set during initial experiments some time ago. > @) Have you tried any mixes of bootcode_delay=???, > boot_delay=???, boot_delay_ms=??? in config.txt ? > These are documented in: > > https://www.raspberrypi.org/documentation/configuration/config-txt/boot.md > > bootcode_delay can add time before any start*.elf > is read from whatever media --but it is not clear if > the config.txt containing the bootcode_delay=??? > and start*.elf can be from different media. > > boot_delay and boot_delay_ms control waiting some > amount of time in start*.elf before loading the > next stage (U-Boot for FreeBSD's normal sequence). > I'm seeing lots of MESS:00:00:01.300591:0: hdmi: HDMI:EDID error reading EDID block 0 attempt... errors from u-boot. Up to now they didn't seem to matter. > A) Using a microsd card with only a modern bootcode.bin > should be able to have the rest of the material on the > USB device, including U-Boot. This way tends to have > more fixes/improvements than depending on the internal > support for direct USB booting: It supposedly works for > more USB devices. > I'm using that method on a Pi2, but haven't tried it on the Pi3B since it's a dual-boot. > I do this on a RPi2B v1.1 that does not have support > (B) below. I have done this in temporary contexts > on a RPi3B where (B) below seemed to have a > problem for some reason. Dealing with booting from > (some?) powered hubs can be a type of context where > this proves useful. Indeed, if the disk is moved to the hub it's overlooked by usb tree in addition to being missed by usb scan. > > See: > > https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/README.md > > and "Special bootcode.bin-only boot mode" in: > > https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/msd.md > > If the msdos file system that contains bootcode.bin also > contains an empty file named "timeout" it will wait > longer for a USB device to be ready. See "Known issues" > in: > > https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/msd.md > > B) "The Raspberry Pi 3B+ supports USB mass storage boot out > of the box". So, unless some of those improvements > metioned in (A) turn out to be necessary, no microsd card > should be needed, presuming that all the required > material (including U-Boot) is on the USB drive. > > I do this on a RPi3B and RPi2B v1.2 (after enabling them: > not "out of the box") and all the RPi4B's. (Some RPi4B's > required eeprom updates to enable this.) > > This does not give any control over getting extra time > for the USB device to be ready: it would first have to > have already read something from the device. But the > details of this might be better than the details of > some specific microsd card based RPi3B+ firmware boots. > I.e., it might be worth a try. > > C) I will note that it is possible to have the FreeBSD > kernel also on the microsd card in a UFS partition and > to have "world" on the USB drive. This leads to only > FreeBSD's kernel and later using the USB drive. But > keeping the copy of the kernel and such on the > separate media is messier and atypical. > > (Note: I do this sort if thing for the ROCK64 where > the dd'd U-Boot does not support USB for the FreeBSD > loader to put to use. I defer USB first-use to the > kernel.) It looks to me like upgrading u-boot on the microSD should be the first priority. There remains a lingering suspicion that the USB-SATA adapter (a Startech) might be part of the problem, but why it might stop working now is unclear. Thanks for writing! bob prohaska From nobody Sun Jun 6 17:34:26 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 9D21395ABB5 for ; Sun, 6 Jun 2021 17:34:33 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic305-20.consmr.mail.gq1.yahoo.com (sonic305-20.consmr.mail.gq1.yahoo.com [98.137.64.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4FykCF2R5cz3P2J for ; Sun, 6 Jun 2021 17:34:33 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1623000871; bh=UkL0wam1mQX3a4sN/mWUfD4Z40kA+5VSy7aE5t1u5hw=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=QGCzCar3ZVCWNgwDOTC1+bHSSM3o2HJ5R269Khk2FBouvwnT/Q4uLm6k27hW6JS54TQZ++dHeF1BMBFvjvU5y6rNPSIrSWyRyYLvF2IWMMY7cnuuAFebusrX5kGZtl0ESu77S9AO/BI2PDeBHDYmes7a0ZWmdzljrq3dMC7f6iv7pMHQydL9GqkmagYV5MLSftuKhKx5anRrkZIgAq4BWrf8exBg60zNm7EhB/rA2eptm0rSpQ2inVv0cQzKpOmcIEwURs/Ul1oykJ2o09Pe7Ne9vqWsyG6hWlmdwhwaBV5bHZap5tQ7rBr5RotQgFoOCfN1pOUZZcthotw3Byryzw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1623000871; bh=Bxcxt5xiutPXz07Dj/tfGBGeKO5XnyxZIUwR8uytA0c=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=hbbIkD8Lv4C7z6IlNsNxPxx8U/33MofW6s63sOlJaZve3F4soczpuh7Z7rLhxVfitp7hr1ZiWh68yxP/EHaX9tBbNBdCBijegP0GV8mNEwUfbkQ/lOYYSzTp6kRsBD8sAJtVYRRxcbvW6+zZkMnRIyiuAfjyFN42/bA5jRc4wATgBmcKNG9/CprKKoHKGh7340j7LJSvcRzecpuLTvASHWvq23NtFYhaLLSQSoXzk+ot3KXSPLO8XdQw08FHkTQXibuqJ4Xd5+Tx0aYgrv2snU2tiDGFWRGBiaq1ZXaFfRHEFhzWyKVNiWK6T0yWdAnTMlFVLZvuyNIWxl3oNcrIqw== X-YMail-OSG: .K8L8ogVM1k6gvoVoAUkbuk9eStIe9P.5V7rgTlQIjo98wBbtkuUg04zevvPvfP gmAdDsq.WjRCHjIn6urJOj.zGxvTJHf5GGKD0C2I_ogyZr0cb8wOo.DIGHDqndnRl1gqzKJt3x8g Q36x3gkHgSSgnqFKtvBy8Nt9YtxPkyEp.CLY.oJCbW088WeZbugc5gxDL.sBZDhl8ingt.6A5yFO S3Gnfd4BCfK_bQIWks_KPIITZsaglgpBFacngsBFLEXE5srIWESJZl820VtWkB7ToujyI4P98yrj 2NHzzKbWK_IuttfpG.MHYqh.9IXxBTTk6MROWBIWFO0BBJI0qWEbYX6j7ijcsI84_ycDPpQIVWV6 4.XMPOC.k9l_FIq6HEOIRsVNpgle9FyrBQ8Evp9ug5MfVrCgCYMXGrESkAtXyXeosFl7dGspg3aL kMMARNbdIRrvws9OXSxaHKD3TvvM3b8v.J7DBUTp_WlAGmnTiZ1qXm7MuHivAltqx8o8JtIWuF7n ha_3kquDXwHefna6X6owCi4WBwzfbffWdezmj2KJMz5mbtwfxl.PK5p6lQkF6IYBev7PYFyKpZ8o v_kS1CoA98Qgb3yDBIIMNIVB.yf2JgDfTdxwF7nz91HX24OVm59vT0rk_AwIcg6NrVk4EWnSAZwQ PJqYYJu6NUGVAbdehJM8_Xb6o._xawgp4EDhTrAB9vL4E6aerQ5EGziv25yBxlPpeBFYOMUEZbhQ AwG0vaIb2XSyxn95h8lHg8xLzGMJ91D3CO.OsKZ_KKXe6UgzIjDPxjafhj4xE4AMvR.0V3egQPks RT03pHI3m9xEGaS_0NQX0w0Vz6Mcm9NsHDY6zlP5BF.a1JM9FIXfBayP9SNScc_F8BpVasoh9pLM xRiWzkOAtkbsAwFzX069ash4fJ.6VS0W5i8oXFtbZN_p_E59PKvOiEiGYOL0mbkyUDMkwzgyru6Y aFTKfwwK5L9n8kA_hBEUl8Masp6AJVm9fbnNRrX.E7LiShlp8dBzq59aaJKLab0_zNalVyoffVHw Cret3IqLPrp.Z1pqNz4FP5zjlLs5kX2UbUpzZlezMTdfhQNjxfWbMV3a0vKN1qCcvDeLipLgjaAM AZjPrPZrHmfp3tGWeFE8wwxnRegGf3dDYEAK.x_k_TvCozjJfEQoaAjB1mbgJ5FdFQ4yMq7Te9c4 eQVG2RC.XhAWs4OUTIyZuBOzrDFacM3CEdThWieFCHowxpICuZGHvU2s95z8ynDQAhy97VaZi1Zf ZZHBlnQhio.Oc8j026sMNahaPWtTRVlflcJ0iRQsPBHsvcq7WeaK_Echs8Z0_v7yitJLNIsb.ntv E9lvotFmHgCPpvNYdMJ0Nffbg9HhX6mWDGinZa.nfE4Vinmsf2PAny7DFRkhEge9YCm5E4U8l_Ba uxisUSEGQKrRoRbDJNCXFJVvkF8nErhkObNMV8ga9kOiO1ZC5yKHAT0cymfv0MWOMPjw_A7rJNsO Z3f_1ZMtpZV0me6FEn8trLavvj9pMRVVX3HfLc.1rTnF2mgUfPiQNPsEI0fk8xvlRbEBRE_hUOrq P.93Wlsy6HwtMooiRqUh8BbsSYvPJBO08xZN.8aaJPx98cMwxy_WSVFcPSFlfF_FX4iG6_YpPO7a RwZybey89lGxUr5egWQefaSZSLUqQsaj1GWWVhk3.aHi6b3vxBKSEPABgCxyvRR.yv1d8.aWMrDa 6kRUChMpxUulABXRTzpLKT8rgwJUQxP7vdB1M20kaKuMm7Kq2MdC0GBFgHl4i8rO6HPkKCVnyd.d O.wen5vG9qBTlqhPpd5HMNl.EIwmhyVCB0wDO2W96v2d_w7HDmA8Uc7O5GdGPIojxh04s50Jd14B K2NgBkmjlfCNstLNmkuvGgdf2L.nIIJZAg02zSwvaJwMxnMISZuX594eQ_xwjvDhfnSGD9NaBM0D EkRHRkA6Qf4JQgF5eC7BjL4SUZkvsIfOFVZNHIPr8G_hdAgTWcHLUU6j0BUzOa6EPiuLLPYtYAa8 dnb0xzn2fmpZaThyjnfzZzIC.gOLQrlXQ8sdBH31V3UhXucxJFkE5rPag0PL1xOkqQqkRKAGfnZn UtyW8rqI2ExE099w8FmBiIvYXATFGxbUMnY34simqgtK1qVDX1rfUZqXH47QRd7jmuRNTdzEibEm BvFJ4eqPxug_aqucVMZzzL5OgaKq3D3eUtyHerarr9JJ46Sl2aNBcj6q2fpSYdPExlIGhdQpQTm6 1lJ8VwIbNcF9gSkNMxDSZ2Gs.doSsXb57ksPmux66UGFznLtXvuLNDB9Q5XlxaY_u253iH1gjdxe atR4SL.xtWYvLWx.d8laIHl7Dnj4stQXt4rs9xbFgEzTIvwrjV3FugI_jmDdYROLkKMpViaDgDiQ QrTVu3QwlLWZyWstAkxvMNOQVwagtS48YCRVdzyOoKZEeRFcvY5e1DdD3mVjhT3Ajq4D4jsyJ98G 3uwwxqi659RkdIDQFD3EL7ZF6Kcv5b1VQNc3NVv..qBpP7fL7rQ3RpTAqgPFDkINEPA8WbxI- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Sun, 6 Jun 2021 17:34:31 +0000 Received: by kubenode564.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 12ca7ccffb1585e0654eb8a1e7698377; Sun, 06 Jun 2021 17:34:27 +0000 (UTC) Content-Type: text/plain; charset=us-ascii 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 (Mac OS X Mail 14.0 \(3654.80.0.2.43\)) Subject: Re: Strange u-boot behavior In-Reply-To: <20210606160040.GA97697@www.zefox.net> Date: Sun, 6 Jun 2021 10:34:26 -0700 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <407FDEDF-8595-4F20-91B9-B475CCE95B39@yahoo.com> References: <20210606043152.GA94545@www.zefox.net> <27786296-8C55-4CEC-A587-14BF4465A4F8@yahoo.com> <20210606160040.GA97697@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.80.0.2.43) X-Rspamd-Queue-Id: 4FykCF2R5cz3P2J X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-arm X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Jun-6, at 09:00, bob prohaska wrote: > On Sun, Jun 06, 2021 at 12:11:20AM -0700, Mark Millard wrote: >>=20 >>=20 >> On 2021-Jun-5, at 21:31, bob prohaska wrote: >>=20 >>> For some time now I've been booting an Rpi3B+ using a microSD >>> card configured with=20 >>> U-Boot 2019.10 (Mar 17 2020 - 22:01:14 -0700) >>=20 >> I'm unclear. Do you have the whole msdos file system >> content on the microsd card and only the FreeBSD UFS >> kernel+world on the USB drive? No msdos file system >> on the USB drive? >=20 > It's a dual-boot system, with a complete FreeBSD-current install > on both USB and microSD storage.=20 How do you control which device provides kernel+world if both have a kernel_world? >>=20 >> Some of the confusion may become clearer about why I >> might care in my later notes. >>=20 >> Another question: why still U-Boot 2019.10 instead of >> updating to match, say, what is on modern RELEASE or >> snapshot builds for the version of FreeBSD that you >> are using on the RPi3B+ ? You seem to be using a >> generally not-used combination by sticking to an older >> U-Boot but updating other things. >>=20 > Purely inertia. U-boot doesn't update via the normal make install > cycle, requiring a careful reading of notes for manual upgrade.=20 > It was usable two months ago, though not without hiccups.=20 I will note that U-Boot 2021.04 has problems with USB booting for armv7. I've had to stick with 2020.10 U-Boot for such devices that I want to have USB based booting, with an RPi2B v1.1 and a OPi+2E. Ports has progressed to U-Boot 2021.04 . >> What RPi3B+ firmware version? This can be found via: >>=20 >> # strings start.elf | grep "VC_BUILD_ID_" >>=20 > # strings start.elf | grep "VC_BUILD_ID_" > VC_BUILD_ID_USER: dc4 > VC_BUILD_ID_TIME: 15:31:38 > VC_BUILD_ID_BRANCH: master > VC_BUILD_ID_TIME: Jun 7 2018 > VC_BUILD_ID_HOSTNAME: dc4-XPS13-9333 > VC_BUILD_ID_PLATFORM: raspberrypi_linux > VC_BUILD_ID_VERSION: 4800f08a139d6ca1c5ecbee345ea6682e2160881 (clean) >=20 > That's old, but it used to work with this USB train. =20 bootcode.bin has improvements since back then, as do other things in the RPi firmware. I suggest trying the same vintage that is on 13.0-RELEASE's media. Later possibly newer from snapshot media if it has more recent. In other words: a bias to vintages more other folks are also using, where there is a wider knowledge context for how things are going. For reference, from a RPi4B (and a ROCK64), I am using: # strings start4.elf | grep "VC_BUILD_ID_" VC_BUILD_ID_USER: dom VC_BUILD_ID_TIME: 12:10:40 VC_BUILD_ID_VARIANT: start VC_BUILD_ID_TIME: Feb 25 2021 VC_BUILD_ID_BRANCH: bcm2711_2 VC_BUILD_ID_HOSTNAME: buildbot VC_BUILD_ID_PLATFORM: raspberrypi_linux VC_BUILD_ID_VERSION: 564e5f9b852b23a330b1764bcf0b2d022a20afd0 (clean) >> Depending on what is reported: this might have >> questions about the vintage used. >>=20 >>> by stopping it at the u-boot prompt and issuing >>> usb reset >>> followed by=20 >>> run bootcmd_usb0 >>> after which the usb hard disk boots and all is well. >>>=20 >>> Lately, usb reset has taken to reporting >>> resetting USB... >>> Bus usb@7e980000: scanning bus usb@7e980000 for devices... Device = NOT ready >>> Request Sense returned 02 04 01 >>> 5 USB Device(s) found >>> scanning usb for storage devices... 0 Storage Device(s) found >>>=20 >>> However, usb tree reports >>> USB device tree: >>> 1 Hub (480 Mb/s, 0mA) >>> | U-Boot Root Hub=20 >>> | >>> +-2 Hub (480 Mb/s, 2mA) >>> | >>> +-3 Vendor specific (12 Mb/s, 90mA) >>> | FTDI FT232R USB UART AM00FGTR >>> | =20 >>> +-4 Vendor specific (480 Mb/s, 2mA) >>> | =20 >>> +-5 Mass Storage (480 Mb/s, 0mA) >>> ASMT ASM105x 12345678D558 >>>=20 >>> The problem isn't wholly new; the usb reset command sometimes had >>> to be repeated once or twice before the disk was found. Now it seems=20= >>> a persistent failure.=20 >>>=20 >>> Once FreeBSD has booted, the disk is seen and accessed as usual.=20 >>=20 >> What alternatives have you tried? >>=20 >> *) Have you tried starting a boot sequence once with >> program_usb_boot_timeout=3D1 in config.txt , per notes in: >>=20 >> = https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/b= ootflow.md >>=20 >=20 > Just tried it, usb scan still fails to find the mass storage device = while=20 > usb tree sees it. >=20 >> This programs a One Time Programmable bit to cause >> extra some time to be allowed. The >> program_usb_boot_timeout=3D1 does not need to be kept >> in place. After another reboot (to a RaspiOS >> in order to have the command available): >>=20 >> vcgencmd otp_dump | grep 66 >>=20 >> should have bit 24 set in what it reports. >>=20 >> This might only be useful for option (B) below. I've >> never found wording specifying the range of modes >> that this adds time to. But it might apply to all >> or most modes. >>=20 >=20 > The "boot from USB" OTP was set during initial experiments > some time ago. RPi3B+'s have this set before they are shipped out. >> @) Have you tried any mixes of bootcode_delay=3D???, >> boot_delay=3D???, boot_delay_ms=3D??? in config.txt ? >> These are documented in: >>=20 >> = https://www.raspberrypi.org/documentation/configuration/config-txt/boot.md= >>=20 >> bootcode_delay can add time before any start*.elf >> is read from whatever media --but it is not clear if >> the config.txt containing the bootcode_delay=3D??? >> and start*.elf can be from different media. >>=20 >> boot_delay and boot_delay_ms control waiting some >> amount of time in start*.elf before loading the >> next stage (U-Boot for FreeBSD's normal sequence). >>=20 >=20 > I'm seeing lots of=20 > MESS:00:00:01.300591:0: hdmi: HDMI:EDID error reading EDID block 0 = attempt...=20 > errors from u-boot. Up to now they didn't seem to matter.=20 Do you have a HDMI screen attached? Whatever, bootcode_delay allows extra time for slow HDMI devices. >> A) Using a microsd card with only a modern bootcode.bin >> should be able to have the rest of the material on the >> USB device, including U-Boot. This way tends to have >> more fixes/improvements than depending on the internal >> support for direct USB booting: It supposedly works for >> more USB devices. >>=20 >=20 > I'm using that method on a Pi2, but haven't tried it on the > Pi3B since it's a dual-boot.=20 Which gets back to the question: how do you control which device's kernel+world is booted? >> I do this on a RPi2B v1.1 that does not have support >> (B) below. I have done this in temporary contexts >> on a RPi3B where (B) below seemed to have a >> problem for some reason. Dealing with booting from >> (some?) powered hubs can be a type of context where >> this proves useful. >=20 > Indeed, if the disk is moved to the hub it's overlooked by > usb tree in addition to being missed by usb scan.=20 >=20 >>=20 >=20 >=20 >> See: >>=20 >> = https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/R= EADME.md >>=20 >> and "Special bootcode.bin-only boot mode" in: >>=20 >> = https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/m= sd.md >>=20 >> If the msdos file system that contains bootcode.bin also >> contains an empty file named "timeout" it will wait >> longer for a USB device to be ready. See "Known issues" >> in: >>=20 >> = https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/m= sd.md >>=20 >> B) "The Raspberry Pi 3B+ supports USB mass storage boot out >> of the box". So, unless some of those improvements >> metioned in (A) turn out to be necessary, no microsd card >> should be needed, presuming that all the required >> material (including U-Boot) is on the USB drive. >>=20 >> I do this on a RPi3B and RPi2B v1.2 (after enabling them: >> not "out of the box") and all the RPi4B's. (Some RPi4B's >> required eeprom updates to enable this.) >>=20 >> This does not give any control over getting extra time >> for the USB device to be ready: it would first have to >> have already read something from the device. But the >> details of this might be better than the details of >> some specific microsd card based RPi3B+ firmware boots. >> I.e., it might be worth a try. >>=20 >> C) I will note that it is possible to have the FreeBSD >> kernel also on the microsd card in a UFS partition and >> to have "world" on the USB drive. This leads to only >> FreeBSD's kernel and later using the USB drive. But >> keeping the copy of the kernel and such on the >> separate media is messier and atypical. >>=20 >> (Note: I do this sort if thing for the ROCK64 where >> the dd'd U-Boot does not support USB for the FreeBSD >> loader to put to use. I defer USB first-use to the >> kernel.) >=20 > It looks to me like upgrading u-boot on the microSD should > be the first priority. There remains a lingering suspicion > that the USB-SATA adapter (a Startech) might be part of the > problem, but why it might stop working now is unclear.=20 >=20 I'd include RPi4B firmware updates to match 13.0 with that. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Sun Jun 6 18:24:39 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 C614195DA12 for ; Sun, 6 Jun 2021 18:24:50 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic303-25.consmr.mail.gq1.yahoo.com (sonic303-25.consmr.mail.gq1.yahoo.com [98.137.64.206]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4FylKG3kshz3jWk for ; Sun, 6 Jun 2021 18:24:50 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1623003888; bh=uY0NG3D76Y+K8M/Hm6yFu4cl1SUAwa5Lwteg9/KWLwc=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=IKeq0DGH71ekvhSUq2GBz/TT24C4Ai8xyIkAG4uFz1t3F4VT4AW8ICTq4gAdeUCIdl0YIMZRgU4MQEo/WGNVXsMEOluoyKq4fSl+qKIE9PIZqsKHqSqYcBcylmYxMWvXGY8ovwnrLCmCeRywZat/yjZ6RC8SIXVAWjpy/Tcbggkmpgte64mcw6GDSckOyPfHY14ZXr7aoXeok4k265SlnOQjA4b8slcD2VFiWli619gpcvD7kfC3ZmmF9GQBsiHFgBSdQDd/5UAhPVquybSLaeD0mGlXZCfmQr9jBUYhGBNLxxarpQjzAWRTVUxgVUnESZgCbARVdA4TBwpWQmhG0w== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1623003888; bh=8DoyyFATMeKkevyvcSKMG7OluF2a0loEGLqjkNC7knx=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=MjtQWcycvanewBeXn5uuZo4FY46elxJ0R7accA+MWR9LT467j060A47Ofm51dDLfHik2decHFS5j5NB6Lm7kHuf46YOk+rI3QfWTKPcTjZkwKaLgqhL4yDszp+/FrgkadxztJnTu1OX5F0tFBQ3Ng8MRZoqv+V684o48O4Kaagn+2cbFFRiIQTUryteHJLlqKNq5m5OctrBmgbqda93atibZKdTiM59EVpQ+NhROMSWgGpFIkB3HWITWmzEx8oY4k0dt1LRbVp7AbWlEg4Q4ioYr8pgcruPtrBnxHqNAGiSkvfXYpedvZHXzAkFJ1EOf/qhoQxuHxSfsUt59RQnBag== X-YMail-OSG: rGvGXrYVM1nsagUcI0svB0j6qxcxs_1Xb1E3f9PuqKkyt7QwXYD8bslcG9SnLrO IULx.qn2iXaONXDkc.QyOQbXviSJS6HqSFHFUsqPyU__OKf0b1_AJqNw3qw7UTzPQrsXijwrMlLG 3Y3BNJPojf69kaEClBZoeJmp1SGQ.f5lKx5IuNzzzfVN_N2g33xfkqLhgGISjIlJyeUbFnD0gSiz vf6nslFTvd1k9cNqguc.nP7MxVuS3zmoTLWfcfholwAZZ.xt_4Rrns6cx.qdyxeakxjabGl8Fnei dFRcsxyHkmDvyUKEakI.2KVekPSFN_hv8B066Z2hCM8.SmbWe7GIMA2fL12eGO57WJB8VEiKokL0 yF4OjYTMtKXCGF6X7EqVSubSpzL_5ZLr9b04LXDt_xSjjDsfOG5QwQADkyTRlr._JMkHkeTVcaPC RdLab7imKlb_bj9AL.xdL1dl3G9ySayBeEyMoEdw5yFHuDE_zXBy5Pc5KICtBgId2xuLR__0aA5K 0VEceRV7eNjTbxK5NSQ6aqLKbo3gnniuY..C.TNlIROF74ERS71gauX6fdHrv2GtTySB3aNca.9n p.lW6qjgm6a_5NSYAogReif6H0gYKjE0xq2XtN9mfHFjhfKg5oBbJ4FnlMufeN2p6B2U.asJfSqr GueH3Io0xcS3axSIl3M3s0LyuLGNUkSl9qODSMEM_w0_PcYAQERO0fAq9vJF9JA4SUzS98Wg3OUo DZxuNJri4j6c6bGff7_L4CG9pit.Q3wgJCT79plL2.o3P5SPX7HYOsfpMiaedvJWwlAVOiGdAEZ4 z6XzyZe_CWVSqhaHIxlTKA06u1KZWgpoXbhsm4LMp7LmZCmRyElpbvLIPCX1XZQjgDMdtfO78gOR T5p4Ce3vI06EvFLX1fnynfvGQQHUd4PHaSacd4oLETgDoF_khTV.B.rAxF48YOmR7HXFodU5xmwX Bdtqw6VX4tBwDYJatC6NlN4Aqkq7wdJPykV9ZeQF0nLRGu2exU8ikmbJpnY43HslRPThjMwGptL1 Xjxizp4FzNz7a4rQe_ZUZHOEfHlQyaeamLJgSnUZKvdzxtp5qEgPkFbCgD7YhSxz8tm9KtXp92m6 4j5y9qrMecMPW.a8hh01E8yCSyaAPB3ef8ip56.W026kRmmLfS1NWcZ3WzGbmdGUaYm1DouESkEF GXh6FOXqmm4xzaRqvzweh2UImijYkk_O5sp10VAGZvvk_DF5LHPUMw22LCUS4OI4UJJNE7b3OJw4 n4QyOexZXgdOdZGCSdE3lGBWFV9X0UyN8CoRI2A1jMmUk9B7zLblnbrpS5Gf6TJNGnLNQ6nkzbtN oeVOoDeJjtkzabcfuWG3MURj48zB7gFMrMSGFT8Ku8.FE26JKyXYng3M0uaU2enqqOdehbdxHFHZ lE71IR960l_fGMjHsU4NmzAPhGUXG4hAN2XARqevCTqd7e.ulgEEf2gGspQlmUPfgSUzhA0IEADV 3PlP8V2nONhQe02miQ1V9qXJoRIn8mYgynPCLLS5lHW5Zj7s.vLCpoVNeVjvZ3AzwvIP98i0YGsE OtrGgc5cua2rCm9CuzCj6qA47jqPtE.l8j9tWDiFmXHbp37b6aOUVuB603Qy0Oaqv6j4e2i5on3_ TOcHpHUrIKMFHVE_a9ab7B5IAJafjnwzv.VJx_s3a5oZi2j3YucpmYiL4IiGd1tRUUWueyrqPip1 81lww682gY4zlCWO7wCECLZlmVxXfK2ABlmnK8_a8pnt5F2M.h0rCVXHTRhKbkNKpvnphsmmOndu cYceu7RdrxeVjXTJ5c6zFHuXFRPPH5VQSdOjOu3DQA2QXQLDk_NaCkGr7kgsXQc50QfzUrIJwfvN OZeAez1nEUNMFezP_SknM8PTOL.lBB0MHDj7Eacy7K0Xeaar63t_p16Wc14g.GthmuTD1hfWag_S hZ8gzFADgYtVRtHXQRDaNrcFyX.I.jYU_OWmk1cv9fifw0leFCpDUc1sWtxMH4SK8dvOo4hBWXIv tV1ZWGrT05uqAHH0BNxpvz8zG2Q4VanIgQ1PflLNVHSVLt0immYT.fh4fK4JOtBZpeOOuMkkA49D uqpBJGmh4CfZTSCKid99UFYJUSthn0Pf1vhIP2QJndbFnTJugScaM_MOFJ0qEqpfzvYs8evY9jXd 9EYC.B1x1CxKaM25jsavqpL3iUS.PyRpQvOs3J47GeTme62bvwRhvKbncGMRaPPrxitPvwhbb5NA v8LYAt_zqI4IsH7ieZ_HosYpYXLOvSe5.yNId4aVOsiPFrJnqBFgPOYmbkP5vX13_3IB.LQnDqct lc_a.Jj293xxkt9dLXRGEVk.NTnKkO7.fzJ0roAe2W80dewtOP6GKijx_qb0oJ9csCQISn7syvyP DbArOZ1nZn6hQhCFNrcpJRCMiI5LW.PD4xTRgd4rTN7pm3e9Rz40WFefFZdZKUGYAVXuNHCqSWEJ _iKnpJNz7VS8Ko2wfow-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.gq1.yahoo.com with HTTP; Sun, 6 Jun 2021 18:24:48 +0000 Received: by kubenode513.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID f028d33b950bc8f78d1f44df24ce7833; Sun, 06 Jun 2021 18:24:42 +0000 (UTC) Content-Type: text/plain; charset=us-ascii 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 (Mac OS X Mail 14.0 \(3654.80.0.2.43\)) Subject: Re: Strange u-boot behavior In-Reply-To: <20210606160040.GA97697@www.zefox.net> Date: Sun, 6 Jun 2021 11:24:39 -0700 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <39531089-701F-4A5C-B60E-0D9262DF8B78@yahoo.com> References: <20210606043152.GA94545@www.zefox.net> <27786296-8C55-4CEC-A587-14BF4465A4F8@yahoo.com> <20210606160040.GA97697@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.80.0.2.43) X-Rspamd-Queue-Id: 4FylKG3kshz3jWk X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-arm X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Jun-6, at 09:00, bob prohaska wrote: >> . . . >=20 > I'm seeing lots of=20 > MESS:00:00:01.300591:0: hdmi: HDMI:EDID error reading EDID block 0 = attempt...=20 > errors from u-boot. Up to now they didn't seem to matter.=20 >=20 FYI: The "MESS:" lines are from before U-Boot has been loaded by the RPi firmware. They start even before the firmware loads the .dtb --but after start*.elf is started, so after it and the matching fixup*.dat are loaded. U-Boot is not involved for these HDMI:EDID messages. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Sun Jun 6 21:00:48 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 24A3713C97A9 for ; Sun, 6 Jun 2021 21:00:50 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4FypnD6Kcbz4Rb0 for ; Sun, 6 Jun 2021 21:00:48 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 98B432584 for ; Sun, 6 Jun 2021 21:00:48 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 156L0mG8046714 for ; Sun, 6 Jun 2021 21:00:48 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 156L0mG3046713 for freebsd-arm@FreeBSD.org; Sun, 6 Jun 2021 21:00:48 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <202106062100.156L0mG3046713@kenobi.freebsd.org> X-Authentication-Warning: kenobi.freebsd.org: bugzilla set sender to bugzilla-noreply@FreeBSD.org using -f From: bugzilla-noreply@FreeBSD.org To: freebsd-arm@FreeBSD.org Subject: Problem reports for freebsd-arm@FreeBSD.org that need special attention Date: Sun, 6 Jun 2021 21:00:48 +0000 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 Content-Type: multipart/alternative; boundary="16230132486.9B338a5.45441" Content-Transfer-Encoding: 7bit X-ThisMailContainsUnwantedMimeParts: Y --16230132486.9B338a5.45441 Date: Sun, 6 Jun 2021 21:00:48 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status | Bug Id | Description ------------+-----------+--------------------------------------------------- Open | 238576 | Raspberry Pi 3B+ "shutdown -p" does not shut off Open | 239673 | Spurious Interrupt message from /dev/led/led1 2 problems total for which you should take action. --16230132486.9B338a5.45441--