| Message ID | 20210319075718.14181-1-peng.fan@oss.nxp.com |
|---|---|
| Headers | show |
| Series | imx: update for i.MX8M | expand |
From: Peng Fan <peng.fan@nxp.com> Use NXP logo. The vendor and board dir not changed, only replace the content of freescale.bmp. Signed-off-by: Peng Fan <peng.fan@nxp.com> --- tools/logos/freescale.bmp | Bin 46738 -> 47670 bytes 1 file changed, 0 insertions(+), 0 deletions(-) diff --git a/tools/logos/freescale.bmp b/tools/logos/freescale.bmp index 1589e8073d133b61d5dedb99ff393ef9aa68a07f..43e0591c8ead8641e0fa8de3f13fcca5f55b3a69 100644 GIT binary patch literal 47670 zcmeI5JC9^X6~}A3=l1ktd%Jt4AJdPCLEaE)$sJg7KtM_c84^N58zEuI!T}Lv7$Hl1 z080)mIk6)GkZ|C@PT@=V6Tmt3ew?aXJ&U|u<5SX3-+tWb?%(~-|NL(~?!Nt#mtP3k zUS13FL)iM&l@Ra4?UfkI$8$ga{ps(-f8gKXtAC1@zxbKBefwP@1_L2J`>(kA=3n9; zfBUr%Uw<jqKmCpP@dtkv;s<Yummhp6y1#!eu0Q@(Y+k$&Kl;ln@#;^15UWrAD)zts zL`*;YMhu=m7cV~gtvGHMV*mah#s0lt3b9;?S3iFz_fhz9Ccp%k025#WOn?b60Vco% zm;e)C0!)AjFaajO1egF5U;<2l2`~XBzyz286JP>NfC(@GCcp%k025#WOn?b6fu~4d zcbZe}H0uAd^sal^c7@${>Lu~d`F?-eRlIHCH(&Tur*3vg+pIhFe(v48n{`CHet@>m z!yfJN1=qx$T{rK4+uqN0xi6T{w#&3_XT4u~G@orYhi7TKn?QTmXBE1Cz!%)z675)V zh%Xmq?<bodmN#kZXAP*g%kAbl#ro>%3Sej6dbfI*!1EOA`@?LW+3QI>{8-kfZnL~0 zVc!8tV7;P+4GtooCs^OF*GFcZs!F21xmjvq`|_5oQP?DGg__j${eoGiq{V5z*`o7M z!Zxf|RCyeMgA7pjsjlzWiv{aCfxVj_Bx)yY&$bn7TG-k_DAs^_$gBy}P#0A}Rl@cy z<e6qomdE{Sf^Iz^bbY@bPMLMgT1F6)T~Zg3tidOsJjO0!Wj#nd1Y|vB)<x8Wix^!K zE}{z~q3iqm#gJLYsD+LoSz%k&iHoRc4IYyEHOhL-x{hE+s4<H?PyKoT+Kq*69VBIq zg>lNdj#1kPk`uP}YnkkVvq$3~gs!nLGV2JnOM3=&60)6#gyqqfb(BM7VVq9KoI^a^ zJM0B<l=T*#JvtllSO+fR%Q|GO9fUo^BQ1io=a7fFPkRVDg|uw_3%tUJkNfA1TGqh& z&{3V~)MG7nb)VDsltJy4M^v}3YjhFSEfP3L$lA(!x>&E%zI5u5<8cN@rDj0Gm&%*o zK7;iri6B<m(7B43rI8rcSR7pz2^=J1Ei(w##_6!GEf#oGjxe-9_HVsurn&b&gLNKt z&<AB$OVn4B$qIY2wSy@BcnF+_SO<}`<&Ux3%x?{$Td<qQr>42@c?pl#vo?KuR?Pl} z>0I?a#1nSpAU<p3AXR)r@<_X-QL}2+RN8a2u{`Q166zYdnIL3G4id7K(K@79bq|hC zTd-?c(`he+{Y>IcS+DlMTAoQNU-3PJaF8m{`b9&CF1<sem*5}x87f(4BZ#GKT_j|U zTp#2Rqvebn#;;YM(>Zjb*J7V{E1q4)x*xSGj|pplEqkqf*p{{IbBg%Y-vt{%*o~x- zD%ORxXLW7+pa|9pYNKmY80+bpSGrO<T({yPRjdnX&u6X5W6IhlJ?#8bP3v0sIT?VD zyImX_5q1shV%iH~`<c&hrEV2#Ss0x{ABTF{jIb+Mm(!kOt!FSKx*mX<t)P8fzjk3% z2WQ-hu=`nO(;iGs^FYI<>VryHXLU{Hz4K%)Uk$=;B8v2~&PEU*t0yj4;&O<lnsrhb z&%^9FP9y!^eXR4SH?vvH`UWTXox%FtGsfJ(028^C^Oe%)=wY2rd&}(%#tp2Z^#*9Y znswkHIf|Zm3!7jfEkx`d*15EYs81<tERUe;xDuw04LL*&=SBpJeX3(~M9eJ=o2mWV zh}dP;*|Z0!cO>iW=1xx7OYsJeOzr|%YvRyxM~w`a$JT4|_`uHV{`umiKko17xgzUq z+S?wW6M|w5!mjjdIr%11b<Y@B2WueIfP1uGBNIzXtn+DagWbj?>znN}oUzx}CU+4u zG=siz^bxGkIY#>_>TLv(0_#Eqkv$OqSJskQKeFBY2=o4u)<zJ?vo4~>vQM&JZqY+} zizDcoVAjuC?79Q7<FJX)mt|c{dop3stY6EoE9SbB!fu>(Deb8+OR<JC$I9ABWxfhs zgRs|$g-oZ1?mNm7uk$uJUC;F@jreTk2GgE;LxT0A&t(+88rGxvfjHf4nssMZX+*GP z+RL*(;~X8kL)=M;gk8g0P$n{Lne}Ev%-aL(+l?CpNp&qd`f5GoHa(kpH0zc<WC@FT zBSFi%OAmFLLnP|z{*YUM9l62xk~PH{9z)cwlPA$N6vlL121g1^26RzSj>{x2!mKTL z>~M0Z6J0A=hq`uj!!t>G46K@U<nvAE5R2E}h)}1j)goTnuOsM|b>Jee!McSGY&!G# zh|M;l4u+Z{57Dv?bsehN-BYZwJW7dbomR7s6L!nzGKQ~z>!m#^^BL3xYq*4kqpY?x z>!>`|u_jK^pBQUD?a{2sxs!l)0+(iqVLR4t@^#%Bj!{RP%RDXCLE0l&TUp1tmJ?Nz z34Mlj7_w`0eVP&H=q>m2`Q9P7!?Z`SR)sOmd^jgqPrvr+qhsxl8T7M;9x=i~njR~N zS;rAX!uD&UleMR7WIK?{(h+trDcG_Ogx$w_beaR|B=FUlj}pk6{8^PlNYsAjL)2#7 zU6A?IRCgit1r}_HbgcdI*fRz;@492!iGrD=?;yQN!tT9mSSM*u?e6K?PQG>?q76e| zA17YK5wNy>P%yN6EVRSnDUR)i9+ITJn6)o!&qL5b)Y2roILQdxW9_-fa0n~B@@<GG zK7@n7IC>M4%qn!fl_R<CPr+<iU3+Hjbd6M{gXpvRaLJ6%+INxoB*oq*5u0b5o{Qt_ znn-(*u5lWl4%Z=TT)tsWHA5GPSo<N{0Ia@+Yhg4o+?ZJ}<FTgFUdUR>+QRm0Bd!56 zEm$NSutpd0bn9)_@g6Uln2OWOnvNinpYae|7!_`hwJwaBw(lYd>#P;`;vVB<ck|a{ z4(vtV_V{%HwaI*;Tl?$LJqN+>?z>3HT9(JN<!p~a8;LKs=FWIXChaNJC|$>>Z4NQf z+DS|bTV=tRbuvU_L6$f00D-LASmIdLbtdhFti8GjrBSg)qM?I?!j4#@u!ElLGGX<s z`9lC%dm|X`&|chDk##QZd8`vzTV2~|?Y^@sk1=cMA~k^1*R->8x5PS|_I%c|&&h@m zqiagmu$L{56zj8vEx9kiLE4aYDTn0Ko@1TL+UPnejA|EI9;LsyYg*{*V1tXKn(cpN zu@1&S)!SU?&%CZn5k!6&sEq__$J#|}_uY+)B)TSMF!X~Sj}dhfc@Gg}S@)vG%!kq1 z_YYSalftNYtK0_>CDHXG%HtTXvd~CfEU_-8J;e=J<GL?>=^?}{n>?2x9Rzp7i!!5` zr>xH|kLpq_jd*p5busN3)*Cw*V?e{LW=%N=?x)Hl#roDCqUkdbTw2rEC5Un!QcioC zb$8ILUBU*LBkPQV;C{+QXx3FB8~a`H%35$Gv&R05l+$dpP1~mCYBR8$W_C?9xLU}A zyr7mkB=JuykCO*tzw6`i0871k8Y~KH^NMk>5CaC5h*onoHW>X|<r@8;6)5cceQvK6 z@kx@0@XClSUI`KYq(`G&+D26s2lmajSk3<Z>`paL_`is^nE(@D0!)AjFaajO1egF5 xU;<2l2`~XBzyz286JP>NfC(@GCcp%k025#WOn?b60Vco%m;e)C0!+Xs@IN4k?7IK} literal 46738 zcmeHPOOo3-5>+o+F%hLuC^QO9^bKb38_e2s4X@@7o|q%_&e!l_PT_0#9Pa$#y#xqS zREgz|R)Kbj_~iE?kpw|X|N8gu|KHj1yL|pr{{HjJZueg~|FZj=e99sHe}D16e@IpT zcDo<(Pf9<m8imh0|F_$H{w(eG_djLW{r1~$yAK~e>^^?{xcl_!lk|Vyefjcb_x0=7 z-M4SwcHh5$7g;}chj9!91_A?tfxtjuATSUZ2n+-U0t118z@LJ^`Et3OPp;a^M=hVv zdq3&tQTy#fPeOh+n#19wyjDJii1S$)4kqYuvOeQD27y&hCR>@6*PEQpxvl(sAIIzU zdbwP$3hlm>#m≺J;oKmgDszxax;|I=%G@pYd9|!*sn$MFr_`xk_VH&RTYM=}~qS zC2b}#n$E6OI-l`4UoEx_2`?WFA%}*L8)gE4!6Wgkpk#U(GlR#_IvbcGD6l+9><aP? z`^nI6B>IRwBhnhb=AA%w6t68><$RQAv-S-6MPgin&~Om?eHn<o0e>l23ttG8Gv<SH z7Ir(^Y=K0ZHlg)7p+1~WmTm)UPs2w!IS_>0!uTY0jZQhvlAm=<^svTAI)+vmGz<2S zWFu3t3%@Z(D64=%Yhs`B<8+qUE`AF{r=$Fn|5{OBGvpfMB`^(#0;z!>Gr$-E_sIG& z6*Rj5YvVUEG+7~Nt@{Z-B$LXaD+Wb8j)19xJixFu1hLYRf>x%#qE&K;WONy|Kwb$f z(1D@#qR9%Em@1%os)9u7#q)?p-N_D3#yL|v<N=1~bj2V@w4l@9CW4g_t43jv#uP!s zE58p<nH?qoBDMeNj)=$8#iGs<uz4ML0dk9by*PTpK3?Qp61E{2m>IGKKUt|1NPWC2 zc27`7Bd~_nXAbPh$mX$pXoj$|xULs1$txPjhN?jt`9U&|Esb?>WNOGsxRlcRrA5nf z5~|Q3JvLskzR@A`sQ`&KE;`Fp=u;ko(fQ;nV#Nz(!AWlH1aWDTvJ8SJ16jy{MmnVI zU@4JND#}ukyGyy5QG8Q&ImiOBu<I51BI6_LaG@0rA5@j|lt8Ofa$_P+tD{jir{y+V zZ$NbIq5T%7l4lA{(Cht*PXHl18>KJdbo4~14UgZ7D}l1xqDR@iplxW<;?ZxEl=LZ& zBNrEkT;BU^juTwp=UJZ1hg{KeS)G7Y3t;D!5KR@~sN91<xfb?$mV5g=qjeU6<=ng6 zJ1g`(betng-{I@>&B@8H5_iaZH>BO{yX<}3$Sf0$-YEk6`{PjVL#J{^%RpctFc26B z3<Q1>0!P_Z&?B};ds^jj_998?pO>*;lHlz3UJg%7B70tF+kT(!b?1myw(Hvf@+X@N zV6YbftPM>p*ye?9PUw-j)|1#Ch6^wmo$WT;@d%QOzt%wcsncFous0giUKi9ie}&!D zfYM&ylHUw$+tg97d@o0}=oY0P&{+z5-Rh~1>21dil7v(d)XJEU_`4x)gl|I?R((7V zg$@d;c^i+7!P)989_F(ly&>8#LN|K-Al7ZfHGaC;83@@$#^3=CiGK=$zSNxuT1=pR z(xh3(Mlb0$sUNO|><q{oMitMiGmzHMrl^YMz6uOw6v*~{9Q4qImiGEwg-FjUArDF2 zkx*&3M<cu?k}v`)9qXz2vYFjITK6(?8R@M;o3=CdU>fs^nSu7!avIH{YiLZ=EYw0= z)Dx;&LX7CF4MH7efUlUpY*a?Ll=m&v+oWw+)&Y!pMUCLFfTt7+?;KD<r;aZHRdmhM z*k}}uy>nOr34!$uqYA#&xr6oY@vn%%=n@6;&;o6he)u5WXW4+T#~eW#Zjy6KVh?p8 zS=TTsgAJ~~9#C00CanT?d4*5dOhDpC)@PfW&$=2V>%}Cp1WDznR=Qw6nzdm`39KBz zWn!BtEi9QZQUFPcw1l1b1!cUTqDdb$CJGVdKybCDGNHj956iWf{N-IKs&s6?VsCD$ z5>k}Bqpi*H258e(=;EZy!%hPWj`jk8d*a!YjJ($I!lc3ink*LvSR;W!1~1T<O!Pwp z_{$RkT46M-(kNayAO_x}&`a8ntw;zVgBT7mujGi!_W68_7RpK_;a3r*i)U&Q$G~Jm z2-P{_l%%~jQUg;$v_XdHg#0WqBA^%reCxv2q0M2Z^#~P4aK<_tqzM#^;PZSCbP9HM ziuuC`$Rt%-Qw<28)Brh3Bu^Lu@Efdix^0chKBe*$?T41ybrjU@cd^cmf)0?L8xBbv z*~{dK6mz~6Nr18>-<moP1}6tbEAU6%EJclX5bk6vx?gY5p7*5BUbn&)MhZQqL%gol zSZ84n)wq>uQd#zb5P~}5f;D4wP78GK77FGD59&6(SWBw!C}yx9L%JJ`^!RqrW~<k` zCEIuv%r?1JVa=6@q;U703qd!A=4+^|H!8c5%LVO6k<PX-h&y>D+3fqJ?Wb_lt+vza zML|v+Q03p5L3J*!lM<ozoklQ)0@QV?(kOk!Y<d)<GP+IKRwOmjFTcLj4Gl}b$|ztE zBj%V_()5NaRY7cKfK@%HgaV`ibXdW3v8ivZv=TfgzHnbK6x8NZWVb}GXEo|JcGdav zs~#^^+o}pIAh1LuNdR5Hpf>k=(CP{(935Kl)h|1f=BCKiaV0=1;Q@r$<Y<YSI=ybx z%vK#~1^aHa>nJb{44tG9bd9l5Rh!}DJjo<1gEZ~~DPbwzXkV>pa&c7iDY7Px+Pzo< zX$$Q--V<8=B5Yxb?B$g;HqT*D@Kgi3Lxx2KH7{epyioz@9?}d=#;jGOr9!WrdHJ(K z`u;>hTX>l$hLl;U1`r1H=7M6gf~1pY;ybzSBt?3C{<F7~2@fE|CI@QW!t$6l>L*YO z-1mew0phe}@Fitvlvna`V5H1u%#kk1G=0iCf&*--Ac41|$%LjTZ%EZ^$M67_t~IKW zJ6qlNz`kcig5l;6(_^-AGNv|$vNhJohshXBBZ0QE#Zfy3;`+`pJ$tU{wZ=7MSO)WL zbXOQPl{weaM|+NX(q2b_b;CSt`e-u<Q!Ikg-2@5eNHZM7AxTL#p+Dy@Sxs`6E)hqu zF(O@BjNrCWQ;|(eTJ&{8d+mw@-tjWQ=#ns$djOy5a4Go>W(OA}={6lC^PzuY#z?9; zUM3=fmPnQcj%H}36*iuz_Uwj`2Hjk3Zf3e@uS?r7CE>%FUP|gX0t7~rH=-24Vxx{E zh8=Hs=#4UA`;YX9?9$YZC;Tf$#s(vGI0uaCtaqG(woFUd$cDPTu0YxYy;BL^qSv_M ziR}K^B~N>RD!kC~PcdiEFi|4ArW*}MkJ4i(TgUMrtVCGWEi+2LMN|%-d8IZP3v7*p zBV>XjhIC?-qtW{W($(|bNocP~A~b>}9cci9X0tlk=wFqqyVcfAV!!**lB5Bv`*E=Z zQeZ6w$C@g9ex>n^*#!xa7Re!!^ecWi$^iFZ*0!?oq%SVW!QidXUbPg-YK#6p)^7E5 z41$YB%#xIAVdZ#H>Sy;nk4D`e6Fyn3ugE2ufQ&Xo!>rC?RM0i22I&fIu1HoP-HTt} zRp_|uX3&e|VR|+rR5K)upjpSu6_O7rD<#Mo9qXJh!Z=N?g5``(pREV^Q33fkIXX~J zL%T*gEm&G{Jrm4eI0@v!mL3PPwTr(=(j}0|P3xc)c1VH!GXlz3r3(uX?6R0dd9-vs z%2!&couy^8CA3?l7hXu~Mu@7y#60`=T^YLRf>?l<m^p<C%MA0QBLmsm9ZeU+o|frb zoJs{?v-vJhK08K*G5VV@r->8Jcmr)n*Fw-TpH{u1MULW)E~Vwrd51O~dRr>c7OWhc z4-2UzxdC%Z(qeg&q9terNZ1qVF4pP((hT=6Q|oP~prHTzM_!27_0h8S6wgdI?S<?V z#HCGsw<Zp6k$UNpGv6NaCnKo~MQl~fknlO!41xS|Q5o?rg&2{8q-16@fIYCs3LT^5 z-F^L~xw*I&w&l<c1r1THHq~GmGh*tUEgtii%KKC|NmdY4AWqciEy1L*b8$>GHHXyf zoA4be;Aw!Y)+0tVC726sV2ztSX!(m4cpb{q@%7H+1TjT=UF5s=bd8pskGT<fy`_Hw zC$h_28ot-29Jw8Ya(Bt<9Wv1h%e=5nEZpnOru3MqTVc(#-G{ITcDl`^bFj>@-p)R% z_{k-Bbl)Xt(Mn4s_07sldcM07ZKgK^`w6gST3ov3EkfJrtbsnf*ro`#oqA|bX92>% zu--5hItKrgCPvSjB}8n9@ZND9*jQp4*gpl1w^icVP(I&ik^*Vn$DR-EX;_QfRb;<e zEW9ngSvrE}O|Y(zo=3Zjv{;#MdY=Gm#LinJ#A@@}AJB9X$sE!e5{q8~&oT3tC?Dmw z()@3Gb0=Zl3GL=Oy1fzaMq($jQ`+7?_QjfagW_68duTI}td%n8Rv~aBk*tz2h}I&| z3+=n!?^~;A&<O%lw3iki1G0w@Xc7r;Y95k0nEME%&>l$lA=<Dt(5{glxnx6xlPFCj z4bu5Nl0-R*k0Ve=acuY1jgKoC5+(?wjn#qn1f4A#64LVAae%!gwzaGp>CO}Pntaq= zkH8e_5!<gv^9E=89*MoaFcQfP)Lz>?Li@GIt>xR_|L($C(Sxo=!0sH8Dn@A6=xkXl zJ0g5i&_f$Tv8C#FCaWObdE{tUM*kR3A0H2kjI^SS=&eH=&5vt*uM%3M1?*lT8Axvs zAkC8k4eYez7mMwI^ae<)h)!gu-zJhoGLU{4X+qdV`(gP*KtVt+d_a3SkrbA3eiZ_- z!~odcM8Xxxt8@$|MIdc2EumdM6C2RI0)d3I-lPES<|jo4(yzd_W@(UCuz_~EMskf^ zvya*x2xus`2f!|Admw!Wq6?(;op-<vv^9|oq!-}3v#W<Tz&;G5?}T%iyazU~k;}ZJ z_g(}B+V>*%2z`5flsfasBZ3F-6oE--52&XgZPrquJ&@iE*RCLfJ&^7Kv}vQGJ&@iM r)LCKjJ;vF-(J>Gh2n+-U0t118z(8OiFc26B3<L%O1A&3SBMAHf{C!M# -- 2.30.0
On Fri, Mar 19, 2021 at 12:26 AM Peng Fan (OSS) <peng.fan@oss.nxp.com> wrote: > > From: Ye Li <ye.li@nxp.com> > > Update LPDDR4 script to sync with v2020.04 u-boot > > Signed-off-by: Ye Li <ye.li@nxp.com> Peng, The commit log does not make sense. I believe you want to say something like 'Update LPDDR4 script to sync with <xyz> version of the NXP MX8M_DDR_tool'. > --- > board/freescale/imx8mm_evk/lpddr4_timing.c | 692 +++++++++------------ > 1 file changed, 280 insertions(+), 412 deletions(-) > > diff --git a/board/freescale/imx8mm_evk/lpddr4_timing.c b/board/freescale/imx8mm_evk/lpddr4_timing.c > index 8e48b9d81b..4373ca624e 100644 > --- a/board/freescale/imx8mm_evk/lpddr4_timing.c > +++ b/board/freescale/imx8mm_evk/lpddr4_timing.c > @@ -1,129 +1,162 @@ > // SPDX-License-Identifier: GPL-2.0+ > /* > - * Copyright 2019 NXP > + * Copyright 2018-2019 NXP > + * > + * Generated code from MX8M_DDR_tool > */ I understand that this file is a direct output of the NXP MX8M_DDR tool but it would be nice to see you add to the comment above what version of the tool you used to produce this what functional differences it makes. If you knew what version of the tool produced the original file one could compare versions. As I am the maintainer of an IMX8M Mini board also, I try to pay attention to NXP's updates to the DDR timing config files to let me know if something important has changed. Best Regards, Tim
On Fri, Mar 19, 2021 at 12:31 AM Peng Fan (OSS) <peng.fan@oss.nxp.com> wrote: > > From: Ye Li <ye.li@nxp.com> > > Users reported LPDDR4 MR12 value is set to 0 during PHY training, > not the value from FSP timing structure, which cause compliance test failed. > The root cause is the CATrainOpt[0] is set to 1 in 2D FSP timing > but not set in 1D. According to PHY training application node, > to enable the feature both 1D and 2D need set this field to 1, > otherwise the training result will be incorrect. > The PHY training doc also recommends to set CATrainOpt[0] to 0 to use > MR12 value from message block (FSP structure). So update the LPDDR4 > scripts of all mscale to clear CATrainOpt[0]. Peng, Is this issue being addressed by an update of the NXP i.MX 8M Family DDR Tools app that generates this code? Is there a reference to this issue online anywhere? A bit unrelated but I would love to see NXP step up and replace the silly NXP i.MX 8M Family DDR Tools windows app with code that could be enabled in the SPL to do the same thing. Personally it's a bit of a joke to require having a Windows PC around to bring up an ARM processor board and I would hope there are folks at NXP that are utterly ashamed at this as well. One could easily use the opensource imx-usb-loader to load an SPL that performed this calibration and training code. Tim
> Subject: Re: [PATCH 02/26] imx8mm_evk: Update to latest LPDDR4 script > > On Fri, Mar 19, 2021 at 12:26 AM Peng Fan (OSS) <peng.fan@oss.nxp.com> > wrote: > > > > From: Ye Li <ye.li@nxp.com> > > > > Update LPDDR4 script to sync with v2020.04 u-boot > > > > Signed-off-by: Ye Li <ye.li@nxp.com> > > Peng, > > The commit log does not make sense. I believe you want to say something like > 'Update LPDDR4 script to sync with <xyz> version of the NXP > MX8M_DDR_tool'. I directly cherry-pick this patch from downstream tree, Ye could comment more here. Regards, Peng. > > > --- > > board/freescale/imx8mm_evk/lpddr4_timing.c | 692 > > +++++++++------------ > > 1 file changed, 280 insertions(+), 412 deletions(-) > > > > diff --git a/board/freescale/imx8mm_evk/lpddr4_timing.c > > b/board/freescale/imx8mm_evk/lpddr4_timing.c > > index 8e48b9d81b..4373ca624e 100644 > > --- a/board/freescale/imx8mm_evk/lpddr4_timing.c > > +++ b/board/freescale/imx8mm_evk/lpddr4_timing.c > > @@ -1,129 +1,162 @@ > > // SPDX-License-Identifier: GPL-2.0+ > > /* > > - * Copyright 2019 NXP > > + * Copyright 2018-2019 NXP > > + * > > + * Generated code from MX8M_DDR_tool > > */ > > I understand that this file is a direct output of the NXP MX8M_DDR tool but it > would be nice to see you add to the comment above what version of the tool > you used to produce this what functional differences it makes. If you knew > what version of the tool produced the original file one could compare versions. > > As I am the maintainer of an IMX8M Mini board also, I try to pay attention to > NXP's updates to the DDR timing config files to let me know if something > important has changed. > > Best Regards, > > Tim
Hi Tim, On 24.03.21 22:25, Tim Harvey wrote: > On Fri, Mar 19, 2021 at 12:31 AM Peng Fan (OSS) <peng.fan@oss.nxp.com> wrote: >> >> From: Ye Li <ye.li@nxp.com> >> >> Users reported LPDDR4 MR12 value is set to 0 during PHY training, >> not the value from FSP timing structure, which cause compliance test failed. >> The root cause is the CATrainOpt[0] is set to 1 in 2D FSP timing >> but not set in 1D. According to PHY training application node, >> to enable the feature both 1D and 2D need set this field to 1, >> otherwise the training result will be incorrect. >> The PHY training doc also recommends to set CATrainOpt[0] to 0 to use >> MR12 value from message block (FSP structure). So update the LPDDR4 >> scripts of all mscale to clear CATrainOpt[0]. > > Peng, > > Is this issue being addressed by an update of the NXP i.MX 8M Family > DDR Tools app that generates this code? Is there a reference to this > issue online anywhere? > > A bit unrelated but I would love to see NXP step up and replace the > silly NXP i.MX 8M Family DDR Tools windows app with code that could be > enabled in the SPL to do the same thing. Personally it's a bit of a > joke to require having a Windows PC around to bring up an ARM > processor board and I would hope there are folks at NXP that are > utterly ashamed at this as well. One could easily use the opensource > imx-usb-loader to load an SPL that performed this calibration and > training code. You find a lot of friends here....most of us will frankly be glad if there will be such as tool, or at least if some code is published to help to port to Linux. NXP story did not show a big interest in the past with the Windows-based MFGTools, but I hoped this was changed with "uuu". Such as tool will really help to improve i.MX support and enlarge NXP community (just a couple of notes: I do not expect Peng can decide this, but he can report our thought internally to NXP). Best regards, Stefano -- ===================================================================== DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic@denx.de =====================================================================
On 2021/3/25 16:14, Stefano Babic wrote: > Hi Tim, > > On 24.03.21 22:25, Tim Harvey wrote: >> On Fri, Mar 19, 2021 at 12:31 AM Peng Fan (OSS) <peng.fan@oss.nxp.com> >> wrote: >>> >>> From: Ye Li <ye.li@nxp.com> >>> >>> Users reported LPDDR4 MR12 value is set to 0 during PHY training, >>> not the value from FSP timing structure, which cause compliance test >>> failed. >>> The root cause is the CATrainOpt[0] is set to 1 in 2D FSP timing >>> but not set in 1D. According to PHY training application node, >>> to enable the feature both 1D and 2D need set this field to 1, >>> otherwise the training result will be incorrect. >>> The PHY training doc also recommends to set CATrainOpt[0] to 0 to use >>> MR12 value from message block (FSP structure). So update the LPDDR4 >>> scripts of all mscale to clear CATrainOpt[0]. >> >> Peng, >> >> Is this issue being addressed by an update of the NXP i.MX 8M Family >> DDR Tools app that generates this code? Is there a reference to this >> issue online anywhere? >> >> A bit unrelated but I would love to see NXP step up and replace the >> silly NXP i.MX 8M Family DDR Tools windows app with code that could be >> enabled in the SPL to do the same thing. Personally it's a bit of a >> joke to require having a Windows PC around to bring up an ARM >> processor board and I would hope there are folks at NXP that are >> utterly ashamed at this as well. One could easily use the opensource >> imx-usb-loader to load an SPL that performed this calibration and >> training code. > > You find a lot of friends here....most of us will frankly be glad if > there will be such as tool, or at least if some code is published to > help to port to Linux. NXP story did not show a big interest in the past > with the Windows-based MFGTools, but I hoped this was changed with > "uuu". Such as tool will really help to improve i.MX support and enlarge > NXP community (just a couple of notes: I do not expect Peng can decide > this, but he can report our thought internally to NXP). I have forwarded Tim's to NXP internal. And will also add yours' comments about this DDR tool. I am not the DDR guy, it is out of my power to do the convert, but I'll try to sell your ideas. Thanks, Peng. > > Best regards, > Stefano >
Hello Peng, > -----Original Message----- > From: U-Boot <u-boot-bounces@lists.denx.de> On Behalf Of Peng Fan (OSS) > Sent: Friday, March 19, 2021 8:57 AM > To: sbabic@denx.de; festevam@gmail.com > Cc: u-boot@lists.denx.de; uboot-imx@nxp.com; Ye Li <ye.li@nxp.com> > Subject: [PATCH 03/26] imx8mm_evk: Switch to new imx8mm evk board > > From: Ye Li <ye.li@nxp.com> > > Update PMIC to use PCA9540, the legacy board not supported by NXP This commit seems rather a "nuclear" to me, as de-facto it drops the initialization of ROMH PMIC in favor of PCA one, leaving all the previous board revisions not to be properly sourced. I know that there might be no intention to provide a support for earlier revisions of i.MX8M Mini EVKs from NXP, but providing no backward compatibility to those boards which are still in use by a lot of people for development purposes is highly undesirable either. TBH, I've tested this patch on the old EVK where ROMH PMIC is present, and apart from having some error messages in SPL regarding the register writes - it does boots. What worries me the most though is that DTS changes some voltage settings, which I'm not sure how the SOC would react on. To my opinion, this patch should either be complemented with the mechanism to provide a level of backward compatibility (where the PMIC can be dynamically identified and instantiated), or the separate implementation should be presented which would make the old board type not to be bootable at all if it is considered not to be supported any longer. Or this patch should be reverted in an effort to come up with a solution which covers new revision without "damaging" the currently integrated one. Fabio / Stefano, Do you have any thoughts here on how this should be handled further, considering the fact that the backward compatibility of 2021.07 release is not kept for this board type across multiple revisions? I'd really like to get your opinion here as I do have those boards in development and would need to come up with the idea on what to do with them. Also, this should be taken care of in the Yocto, since there is only one definition of the i.MX8MM EVK machine which does not make any distinction regarding the revision. Thanks a lot! > > Signed-off-by: Ye Li <ye.li@nxp.com> > --- > arch/arm/dts/imx8mm-evk-u-boot.dtsi | 4 +- > arch/arm/dts/imx8mm-evk.dtsi | 127 +++++++++++++++------------- > board/freescale/imx8mm_evk/spl.c | 33 ++++---- > configs/imx8mm_evk_defconfig | 2 +- > 4 files changed, 86 insertions(+), 80 deletions(-) > > diff --git a/arch/arm/dts/imx8mm-evk-u-boot.dtsi b/arch/arm/dts/imx8mm-evk- > u-boot.dtsi > index e843a5648e..7f48912b49 100644 > --- a/arch/arm/dts/imx8mm-evk-u-boot.dtsi > +++ b/arch/arm/dts/imx8mm-evk-u-boot.dtsi > @@ -114,11 +114,11 @@ > u-boot,dm-spl; > }; > > -&{/soc@0/bus@30800000/i2c@30a20000/pmic@4b} { > +&{/soc@0/bus@30800000/i2c@30a20000/pca9450@25} { > u-boot,dm-spl; > }; > > -&{/soc@0/bus@30800000/i2c@30a20000/pmic@4b/regulators} { > +&{/soc@0/bus@30800000/i2c@30a20000/pca9450@25/regulators} { > u-boot,dm-spl; > }; > > diff --git a/arch/arm/dts/imx8mm-evk.dtsi b/arch/arm/dts/imx8mm-evk.dtsi > index 6518f088b2..60179e006d 100644 > --- a/arch/arm/dts/imx8mm-evk.dtsi > +++ b/arch/arm/dts/imx8mm-evk.dtsi > @@ -126,115 +126,120 @@ > pinctrl-0 = <&pinctrl_i2c1>; > status = "okay"; > > - pmic@4b { > - compatible = "rohm,bd71847"; > - reg = <0x4b>; > - pinctrl-names = "default"; > + pmic: pca9450@25 { > + reg = <0x25>; > + compatible = "nxp,pca9450a"; > + /* PMIC PCA9450 PMIC_nINT GPIO1_IO3 */ > pinctrl-0 = <&pinctrl_pmic>; > - interrupt-parent = <&gpio1>; > - interrupts = <3 IRQ_TYPE_LEVEL_LOW>; > - rohm,reset-snvs-powered; > - > - #clock-cells = <0>; > - clocks = <&osc_32k 0>; > - clock-output-names = "clk-32k-out"; > + gpio_intr = <&gpio1 3 GPIO_ACTIVE_LOW>; > > regulators { > - buck1_reg: BUCK1 { > - regulator-name = "buck1"; > - regulator-min-microvolt = <700000>; > - regulator-max-microvolt = <1300000>; > + #address-cells = <1>; > + #size-cells = <0>; > + > + pca9450,pmic-buck2-uses-i2c-dvs; > + /* Run/Standby voltage */ > + pca9450,pmic-buck2-dvs-voltage = <950000>, > + <850000>; > + > + buck1_reg: regulator@0 { > + reg = <0>; > + regulator-compatible = "buck1"; > + regulator-min-microvolt = <600000>; > + regulator-max-microvolt = <2187500>; > regulator-boot-on; > regulator-always-on; > - regulator-ramp-delay = <1250>; > + regulator-ramp-delay = <3125>; > }; > > - buck2_reg: BUCK2 { > - regulator-name = "buck2"; > - regulator-min-microvolt = <700000>; > - regulator-max-microvolt = <1300000>; > + buck2_reg: regulator@1 { > + reg = <1>; > + regulator-compatible = "buck2"; > + regulator-min-microvolt = <600000>; > + regulator-max-microvolt = <2187500>; > regulator-boot-on; > regulator-always-on; > - regulator-ramp-delay = <1250>; > - rohm,dvs-run-voltage = <1000000>; > - rohm,dvs-idle-voltage = <900000>; > + regulator-ramp-delay = <3125>; > }; > > - buck3_reg: BUCK3 { > - // BUCK5 in datasheet > - regulator-name = "buck3"; > - regulator-min-microvolt = <700000>; > - regulator-max-microvolt = <1350000>; > + buck3_reg: regulator@2 { > + reg = <2>; > + regulator-compatible = "buck3"; > + regulator-min-microvolt = <600000>; > + regulator-max-microvolt = <2187500>; > regulator-boot-on; > regulator-always-on; > }; > > - buck4_reg: BUCK4 { > - // BUCK6 in datasheet > - regulator-name = "buck4"; > - regulator-min-microvolt = <3000000>; > - regulator-max-microvolt = <3300000>; > + buck4_reg: regulator@3 { > + reg = <3>; > + regulator-compatible = "buck4"; > + regulator-min-microvolt = <600000>; > + regulator-max-microvolt = <3400000>; > regulator-boot-on; > regulator-always-on; > }; > > - buck5_reg: BUCK5 { > - // BUCK7 in datasheet > - regulator-name = "buck5"; > - regulator-min-microvolt = <1605000>; > - regulator-max-microvolt = <1995000>; > + buck5_reg: regulator@4 { > + reg = <4>; > + regulator-compatible = "buck5"; > + regulator-min-microvolt = <600000>; > + regulator-max-microvolt = <3400000>; > regulator-boot-on; > regulator-always-on; > }; > > - buck6_reg: BUCK6 { > - // BUCK8 in datasheet > - regulator-name = "buck6"; > - regulator-min-microvolt = <800000>; > - regulator-max-microvolt = <1400000>; > + buck6_reg: regulator@5 { > + reg = <5>; > + regulator-compatible = "buck6"; > + regulator-min-microvolt = <600000>; > + regulator-max-microvolt = <3400000>; > regulator-boot-on; > regulator-always-on; > }; > > - ldo1_reg: LDO1 { > - regulator-name = "ldo1"; > + ldo1_reg: regulator@6 { > + reg = <6>; > + regulator-compatible = "ldo1"; > regulator-min-microvolt = <1600000>; > regulator-max-microvolt = <3300000>; > regulator-boot-on; > regulator-always-on; > }; > > - ldo2_reg: LDO2 { > - regulator-name = "ldo2"; > + ldo2_reg: regulator@7 { > + reg = <7>; > + regulator-compatible = "ldo2"; > regulator-min-microvolt = <800000>; > - regulator-max-microvolt = <900000>; > + regulator-max-microvolt = <1150000>; > regulator-boot-on; > regulator-always-on; > }; > > - ldo3_reg: LDO3 { > - regulator-name = "ldo3"; > - regulator-min-microvolt = <1800000>; > + ldo3_reg: regulator@8 { > + reg = <8>; > + regulator-compatible = "ldo3"; > + regulator-min-microvolt = <800000>; > regulator-max-microvolt = <3300000>; > regulator-boot-on; > regulator-always-on; > }; > > - ldo4_reg: LDO4 { > - regulator-name = "ldo4"; > - regulator-min-microvolt = <900000>; > - regulator-max-microvolt = <1800000>; > + ldo4_reg: regulator@9 { > + reg = <9>; > + regulator-compatible = "ldo4"; > + regulator-min-microvolt = <800000>; > + regulator-max-microvolt = <3300000>; > regulator-boot-on; > regulator-always-on; > }; > > - ldo6_reg: LDO6 { > - regulator-name = "ldo6"; > - regulator-min-microvolt = <900000>; > - regulator-max-microvolt = <1800000>; > - regulator-boot-on; > - regulator-always-on; > + ldo5_reg: regulator@10 { > + reg = <10>; > + regulator-compatible = "ldo5"; > + regulator-min-microvolt = <1800000>; > + regulator-max-microvolt = <3300000>; > }; > + > }; > }; > }; > diff --git a/board/freescale/imx8mm_evk/spl.c > b/board/freescale/imx8mm_evk/spl.c > index 64bc60651d..4ef7f6f180 100644 > --- a/board/freescale/imx8mm_evk/spl.c > +++ b/board/freescale/imx8mm_evk/spl.c > @@ -26,7 +26,7 @@ > #include <dm/device-internal.h> > > #include <power/pmic.h> > -#include <power/bd71837.h> > +#include <power/pca9450.h> > > DECLARE_GLOBAL_DATA_PTR; > > @@ -94,7 +94,7 @@ static int power_init_board(void) > struct udevice *dev; > int ret; > > - ret = pmic_get("pmic@4b", &dev); > + ret = pmic_get("pca9450@25", &dev); > if (ret == -ENODEV) { > puts("No pmic\n"); > return 0; > @@ -102,25 +102,26 @@ static int power_init_board(void) > if (ret != 0) > return ret; > > - /* decrease RESET key long push time from the default 10s to 10ms */ > - pmic_reg_write(dev, BD718XX_PWRONCONFIG1, 0x0); > + /* BUCKxOUT_DVS0/1 control BUCK123 output */ > + pmic_reg_write(dev, PCA9450_BUCK123_DVS, 0x29); > > - /* unlock the PMIC regs */ > - pmic_reg_write(dev, BD718XX_REGLOCK, 0x1); > + /* Buck 1 DVS control through PMIC_STBY_REQ */ > + pmic_reg_write(dev, PCA9450_BUCK1CTRL, 0x59); > > - /* increase VDD_SOC to typical value 0.85v before first DRAM access */ > - pmic_reg_write(dev, BD718XX_BUCK1_VOLT_RUN, 0x0f); > + /* Set DVS1 to 0.8v for suspend */ > + pmic_reg_write(dev, PCA9450_BUCK1OUT_DVS1, 0x10); > > - /* increase VDD_DRAM to 0.975v for 3Ghz DDR */ > - pmic_reg_write(dev, BD718XX_1ST_NODVS_BUCK_VOLT, 0x83); > + /* increase VDD_DRAM to 0.95v for 3Ghz DDR */ > + pmic_reg_write(dev, PCA9450_BUCK3OUT_DVS0, 0x1C); > > -#ifndef CONFIG_IMX8M_LPDDR4 > - /* increase NVCC_DRAM_1V2 to 1.2v for DDR4 */ > - pmic_reg_write(dev, BD718XX_4TH_NODVS_BUCK_VOLT, 0x28); > -#endif > + /* VDD_DRAM needs off in suspend, set B1_ENMODE=10 (ON by > PMIC_ON_REQ = H && PMIC_STBY_REQ = L) */ > + pmic_reg_write(dev, PCA9450_BUCK3CTRL, 0x4a); > + > + /* set VDD_SNVS_0V8 from default 0.85V */ > + pmic_reg_write(dev, PCA9450_LDO2CTRL, 0xC0); > > - /* lock the PMIC regs */ > - pmic_reg_write(dev, BD718XX_REGLOCK, 0x11); > + /* set WDOG_B_CFG to cold reset */ > + pmic_reg_write(dev, PCA9450_RESET_CTRL, 0xA1); > > return 0; > } > diff --git a/configs/imx8mm_evk_defconfig b/configs/imx8mm_evk_defconfig > index e22b7de56f..ae9e0626dd 100644 > --- a/configs/imx8mm_evk_defconfig > +++ b/configs/imx8mm_evk_defconfig > @@ -83,7 +83,7 @@ CONFIG_PINCTRL=y > CONFIG_SPL_PINCTRL=y > CONFIG_PINCTRL_IMX8M=y > CONFIG_DM_PMIC=y > -CONFIG_SPL_DM_PMIC_BD71837=y > +CONFIG_SPL_DM_PMIC_PCA9450=y > CONFIG_DM_REGULATOR=y > CONFIG_DM_REGULATOR_FIXED=y > CONFIG_DM_REGULATOR_GPIO=y > -- > 2.30.0 -- andrey
Hi Andrey, On Wed, May 12, 2021 at 6:47 PM ZHIZHIKIN Andrey <andrey.zhizhikin@leica-geosystems.com> wrote: > > Update PMIC to use PCA9540, the legacy board not supported by NXP > > This commit seems rather a "nuclear" to me, as de-facto it drops the initialization of ROMH PMIC in > favor of PCA one, leaving all the previous board revisions not to be properly sourced. > > I know that there might be no intention to provide a support for earlier revisions of i.MX8M Mini > EVKs from NXP, but providing no backward compatibility to those boards which are still in use by > a lot of people for development purposes is highly undesirable either. > > TBH, I've tested this patch on the old EVK where ROMH PMIC is present, and apart from having some > error messages in SPL regarding the register writes - it does boots. What worries me the most though > is that DTS changes some voltage settings, which I'm not sure how the SOC would react on. > > To my opinion, this patch should either be complemented with the mechanism to provide a > level of backward compatibility (where the PMIC can be dynamically identified and instantiated), > or the separate implementation should be presented which would make the old board type not to > be bootable at all if it is considered not to be supported any longer. Or this patch should be reverted > in an effort to come up with a solution which covers new revision without "damaging" the currently > integrated one. > > Fabio / Stefano, > Do you have any thoughts here on how this should be handled further, considering the fact that the > backward compatibility of 2021.07 release is not kept for this board type across multiple revisions? > > I'd really like to get your opinion here as I do have those boards in development and would need to > come up with the idea on what to do with them. > > Also, this should be taken care of in the Yocto, since there is only one definition of the i.MX8MM EVK > machine which does not make any distinction regarding the revision. You bring a good point. What about adding a new defconfig to support the old imx8mm-evk with the Rohm PMIC? Then we could have imx8mm_evk_defconfig for the new version and imx8mm_evk_rohm_defconfig for the old one. What do you think? Thanks
Hi Fabio, On Fri, May 14, 2021 at 9:30 AM Fabio Estevam <festevam@gmail.com> wrote: > > Hi Andrey, > > On Wed, May 12, 2021 at 6:47 PM ZHIZHIKIN Andrey > <andrey.zhizhikin@leica-geosystems.com> wrote: > > > > Update PMIC to use PCA9540, the legacy board not supported by NXP > > > > This commit seems rather a "nuclear" to me, as de-facto it drops the initialization of ROMH PMIC in > > favor of PCA one, leaving all the previous board revisions not to be properly sourced. > > > > I know that there might be no intention to provide a support for earlier revisions of i.MX8M Mini > > EVKs from NXP, but providing no backward compatibility to those boards which are still in use by > > a lot of people for development purposes is highly undesirable either. > > > > TBH, I've tested this patch on the old EVK where ROMH PMIC is present, and apart from having some > > error messages in SPL regarding the register writes - it does boots. What worries me the most though > > is that DTS changes some voltage settings, which I'm not sure how the SOC would react on. > > > > To my opinion, this patch should either be complemented with the mechanism to provide a > > level of backward compatibility (where the PMIC can be dynamically identified and instantiated), > > or the separate implementation should be presented which would make the old board type not to > > be bootable at all if it is considered not to be supported any longer. Or this patch should be reverted > > in an effort to come up with a solution which covers new revision without "damaging" the currently > > integrated one. > > > > Fabio / Stefano, > > Do you have any thoughts here on how this should be handled further, considering the fact that the > > backward compatibility of 2021.07 release is not kept for this board type across multiple revisions? > > > > I'd really like to get your opinion here as I do have those boards in development and would need to > > come up with the idea on what to do with them. > > > > Also, this should be taken care of in the Yocto, since there is only one definition of the i.MX8MM EVK > > machine which does not make any distinction regarding the revision. > > You bring a good point. > > What about adding a new defconfig to support the old imx8mm-evk with > the Rohm PMIC? > > Then we could have imx8mm_evk_defconfig for the new version and > imx8mm_evk_rohm_defconfig for the old one. > > What do you think? Maybe a dynamic way to identify if BD71837 or PCA9450 (by probing i2c) would work better? Different configs would imply different builds and binaries, which is a problem when trying to support a single build for both the old EVK and EVKB (and the main difference is the PMIC, nothing really major). I also share Andrey's concerns, as we do have several EVKs in hands, and having one single build would facilitate quite a bit. Cheers, -- Ricardo Salveti de Araujo
Hi Ricardo, On Fri, May 14, 2021 at 12:29 PM Ricardo Salveti <rsalveti@rsalveti.net> wrote: > Maybe a dynamic way to identify if BD71837 or PCA9450 (by probing i2c) > would work better? Yes, agreed. On imx53-qsb we support both Dialog and NXP PMICs in the same defconfig. > Different configs would imply different builds and binaries, which is > a problem when trying to support a single build for both the old EVK > and EVKB (and the main difference is the PMIC, nothing really major). > > I also share Andrey's concerns, as we do have several EVKs in hands, > and having one single build would facilitate quite a bit. Agreed. Thanks
Hello Fabio, > -----Original Message----- > From: Fabio Estevam <festevam@gmail.com> > Sent: Friday, May 14, 2021 2:31 PM > To: ZHIZHIKIN Andrey <andrey.zhizhikin@leica-geosystems.com> > Cc: Peng Fan (OSS) <peng.fan@oss.nxp.com>; sbabic@denx.de; u- > boot@lists.denx.de; uboot-imx@nxp.com; Ye Li <ye.li@nxp.com> > Subject: Re: [PATCH 03/26] imx8mm_evk: Switch to new imx8mm evk board > > > Hi Andrey, > > On Wed, May 12, 2021 at 6:47 PM ZHIZHIKIN Andrey <andrey.zhizhikin@leica- > geosystems.com> wrote: > > > > Update PMIC to use PCA9540, the legacy board not supported by NXP > > > > This commit seems rather a "nuclear" to me, as de-facto it drops the > > initialization of ROMH PMIC in favor of PCA one, leaving all the previous board > revisions not to be properly sourced. > > > > I know that there might be no intention to provide a support for > > earlier revisions of i.MX8M Mini EVKs from NXP, but providing no > > backward compatibility to those boards which are still in use by a lot of people > for development purposes is highly undesirable either. > > > > TBH, I've tested this patch on the old EVK where ROMH PMIC is present, > > and apart from having some error messages in SPL regarding the > > register writes - it does boots. What worries me the most though is that DTS > changes some voltage settings, which I'm not sure how the SOC would react on. > > > > To my opinion, this patch should either be complemented with the > > mechanism to provide a level of backward compatibility (where the PMIC > > can be dynamically identified and instantiated), or the separate > > implementation should be presented which would make the old board type > > not to be bootable at all if it is considered not to be supported any > > longer. Or this patch should be reverted in an effort to come up with a solution > which covers new revision without "damaging" the currently integrated one. > > > > Fabio / Stefano, > > Do you have any thoughts here on how this should be handled further, > > considering the fact that the backward compatibility of 2021.07 release is not > kept for this board type across multiple revisions? > > > > I'd really like to get your opinion here as I do have those boards in > > development and would need to come up with the idea on what to do with > them. > > > > Also, this should be taken care of in the Yocto, since there is only > > one definition of the i.MX8MM EVK machine which does not make any > distinction regarding the revision. > > You bring a good point. > > What about adding a new defconfig to support the old imx8mm-evk with the > Rohm PMIC? This would not be the only change that is necessary to provide support for both ROMH and PCA PMIC ICs. From the commit, it seems that also the "duplication" should be done in DTS and SPL PMIC code in power_init_board(void) should also be adapted to get PMIC based on the config option. I'm not saying it is not feasible - it is perfectly doable, but would require some verification afterwards. I can try to come up with the patch set for this but cannot commit to test the change since I do not own a updated EVK board. I guess an ideal situation would be that NXP can step in here to provide the better version of this patch where both revisions are supported, and they can verify the change on both EVK revisions. > > Then we could have imx8mm_evk_defconfig for the new version and > imx8mm_evk_rohm_defconfig for the old one. Yes, ultimately this would be possible provided that both DTS and SPL code are made in a way to provide implementation for both PMIC types. > > What do you think? > > Thanks -- andrey
Hello Ricardo, > -----Original Message----- > From: Ricardo Salveti <rsalveti@rsalveti.net> > Sent: Friday, May 14, 2021 5:29 PM > To: Fabio Estevam <festevam@gmail.com> > Cc: ZHIZHIKIN Andrey <andrey.zhizhikin@leica-geosystems.com>; Peng Fan > (OSS) <peng.fan@oss.nxp.com>; sbabic@denx.de; u-boot@lists.denx.de; uboot- > imx@nxp.com; Ye Li <ye.li@nxp.com>; vanessa.maegima@foundries.io; > igor.opaniuk@foundries.io > Subject: Re: [PATCH 03/26] imx8mm_evk: Switch to new imx8mm evk board > > > Hi Fabio, > > On Fri, May 14, 2021 at 9:30 AM Fabio Estevam <festevam@gmail.com> wrote: > > > > Hi Andrey, > > > > On Wed, May 12, 2021 at 6:47 PM ZHIZHIKIN Andrey > > <andrey.zhizhikin@leica-geosystems.com> wrote: > > > > > > Update PMIC to use PCA9540, the legacy board not supported by NXP > > > > > > This commit seems rather a "nuclear" to me, as de-facto it drops the > initialization of ROMH PMIC in > > > favor of PCA one, leaving all the previous board revisions not to be properly > sourced. > > > > > > I know that there might be no intention to provide a support for earlier > revisions of i.MX8M Mini > > > EVKs from NXP, but providing no backward compatibility to those boards > which are still in use by > > > a lot of people for development purposes is highly undesirable either. > > > > > > TBH, I've tested this patch on the old EVK where ROMH PMIC is present, and > apart from having some > > > error messages in SPL regarding the register writes - it does boots. What > worries me the most though > > > is that DTS changes some voltage settings, which I'm not sure how the SOC > would react on. > > > > > > To my opinion, this patch should either be complemented with the > mechanism to provide a > > > level of backward compatibility (where the PMIC can be dynamically > identified and instantiated), > > > or the separate implementation should be presented which would make the > old board type not to > > > be bootable at all if it is considered not to be supported any longer. Or this > patch should be reverted > > > in an effort to come up with a solution which covers new revision without > "damaging" the currently > > > integrated one. > > > > > > Fabio / Stefano, > > > Do you have any thoughts here on how this should be handled further, > considering the fact that the > > > backward compatibility of 2021.07 release is not kept for this board type > across multiple revisions? > > > > > > I'd really like to get your opinion here as I do have those boards in > development and would need to > > > come up with the idea on what to do with them. > > > > > > Also, this should be taken care of in the Yocto, since there is only one > definition of the i.MX8MM EVK > > > machine which does not make any distinction regarding the revision. > > > > You bring a good point. > > > > What about adding a new defconfig to support the old imx8mm-evk with > > the Rohm PMIC? > > > > Then we could have imx8mm_evk_defconfig for the new version and > > imx8mm_evk_rohm_defconfig for the old one. > > > > What do you think? > > Maybe a dynamic way to identify if BD71837 or PCA9450 (by probing i2c) > would work better? This might be solution given that there is an implementation in SPL which can be used to query I2C to determine the PMIC type and get it dynamically. I'm not aware if this functionality exist, I would need to search for the reference in the U-Boot tree for this. But still, as I previously replied to Fabio, it would still need to have 2 separate entries in DTS for both PMICs, and SPL power_init_board(void) code should be extended to request the PMIC based on the type detected. I guess this can be done in 2 steps: first make the PMIC selection based on the config option in SPL, and then - replace it with dynamic query (if possible). > > Different configs would imply different builds and binaries, which is > a problem when trying to support a single build for both the old EVK > and EVKB (and the main difference is the PMIC, nothing really major). This is especially true for Yocto builds, but there would be a way to define separate U-Boot config based on the type, so having 2 separate config files would not be technically impossible to achieve. However, I totally agree with you - one build for both revisions would be the best solution here. > > I also share Andrey's concerns, as we do have several EVKs in hands, > and having one single build would facilitate quite a bit. > > Cheers, > -- > Ricardo Salveti de Araujo -- andrey
On 2021/5/13 5:47, ZHIZHIKIN Andrey wrote: > Hello Peng, > >> -----Original Message----- >> From: U-Boot <u-boot-bounces@lists.denx.de> On Behalf Of Peng Fan (OSS) >> Sent: Friday, March 19, 2021 8:57 AM >> To: sbabic@denx.de; festevam@gmail.com >> Cc: u-boot@lists.denx.de; uboot-imx@nxp.com; Ye Li <ye.li@nxp.com> >> Subject: [PATCH 03/26] imx8mm_evk: Switch to new imx8mm evk board >> >> From: Ye Li <ye.li@nxp.com> >> >> Update PMIC to use PCA9540, the legacy board not supported by NXP > > This commit seems rather a "nuclear" to me, as de-facto it drops the initialization of ROMH PMIC in > favor of PCA one, leaving all the previous board revisions not to be properly sourced. > > I know that there might be no intention to provide a support for earlier revisions of i.MX8M Mini > EVKs from NXP, but providing no backward compatibility to those boards which are still in use by > a lot of people for development purposes is highly undesirable either. > > TBH, I've tested this patch on the old EVK where ROMH PMIC is present, and apart from having some > error messages in SPL regarding the register writes - it does boots. What worries me the most though > is that DTS changes some voltage settings, which I'm not sure how the SOC would react on. > > To my opinion, this patch should either be complemented with the mechanism to provide a > level of backward compatibility (where the PMIC can be dynamically identified and instantiated), > or the separate implementation should be presented which would make the old board type not to > be bootable at all if it is considered not to be supported any longer. Or this patch should be reverted > in an effort to come up with a solution which covers new revision without "damaging" the currently > integrated one. The old evk board was no longer supported by NXP, all new boards using new PMIC. No damage, just some default voltage settings different. It is ok to add back the old pmic, but it finally will retire and no one will use it in production I think. Regards, Peng. > > Fabio / Stefano, > Do you have any thoughts here on how this should be handled further, considering the fact that the > backward compatibility of 2021.07 release is not kept for this board type across multiple revisions? > > I'd really like to get your opinion here as I do have those boards in development and would need to > come up with the idea on what to do with them. > > Also, this should be taken care of in the Yocto, since there is only one definition of the i.MX8MM EVK > machine which does not make any distinction regarding the revision. > > Thanks a lot! > >> >> Signed-off-by: Ye Li <ye.li@nxp.com> >> --- >> arch/arm/dts/imx8mm-evk-u-boot.dtsi | 4 +- >> arch/arm/dts/imx8mm-evk.dtsi | 127 +++++++++++++++------------- >> board/freescale/imx8mm_evk/spl.c | 33 ++++---- >> configs/imx8mm_evk_defconfig | 2 +- >> 4 files changed, 86 insertions(+), 80 deletions(-) >> >> diff --git a/arch/arm/dts/imx8mm-evk-u-boot.dtsi b/arch/arm/dts/imx8mm-evk- >> u-boot.dtsi >> index e843a5648e..7f48912b49 100644 >> --- a/arch/arm/dts/imx8mm-evk-u-boot.dtsi >> +++ b/arch/arm/dts/imx8mm-evk-u-boot.dtsi >> @@ -114,11 +114,11 @@ >> u-boot,dm-spl; >> }; >> >> -&{/soc@0/bus@30800000/i2c@30a20000/pmic@4b} { >> +&{/soc@0/bus@30800000/i2c@30a20000/pca9450@25} { >> u-boot,dm-spl; >> }; >> >> -&{/soc@0/bus@30800000/i2c@30a20000/pmic@4b/regulators} { >> +&{/soc@0/bus@30800000/i2c@30a20000/pca9450@25/regulators} { >> u-boot,dm-spl; >> }; >> >> diff --git a/arch/arm/dts/imx8mm-evk.dtsi b/arch/arm/dts/imx8mm-evk.dtsi >> index 6518f088b2..60179e006d 100644 >> --- a/arch/arm/dts/imx8mm-evk.dtsi >> +++ b/arch/arm/dts/imx8mm-evk.dtsi >> @@ -126,115 +126,120 @@ >> pinctrl-0 = <&pinctrl_i2c1>; >> status = "okay"; >> >> - pmic@4b { >> - compatible = "rohm,bd71847"; >> - reg = <0x4b>; >> - pinctrl-names = "default"; >> + pmic: pca9450@25 { >> + reg = <0x25>; >> + compatible = "nxp,pca9450a"; >> + /* PMIC PCA9450 PMIC_nINT GPIO1_IO3 */ >> pinctrl-0 = <&pinctrl_pmic>; >> - interrupt-parent = <&gpio1>; >> - interrupts = <3 IRQ_TYPE_LEVEL_LOW>; >> - rohm,reset-snvs-powered; >> - >> - #clock-cells = <0>; >> - clocks = <&osc_32k 0>; >> - clock-output-names = "clk-32k-out"; >> + gpio_intr = <&gpio1 3 GPIO_ACTIVE_LOW>; >> >> regulators { >> - buck1_reg: BUCK1 { >> - regulator-name = "buck1"; >> - regulator-min-microvolt = <700000>; >> - regulator-max-microvolt = <1300000>; >> + #address-cells = <1>; >> + #size-cells = <0>; >> + >> + pca9450,pmic-buck2-uses-i2c-dvs; >> + /* Run/Standby voltage */ >> + pca9450,pmic-buck2-dvs-voltage = <950000>, >> + <850000>; >> + >> + buck1_reg: regulator@0 { >> + reg = <0>; >> + regulator-compatible = "buck1"; >> + regulator-min-microvolt = <600000>; >> + regulator-max-microvolt = <2187500>; >> regulator-boot-on; >> regulator-always-on; >> - regulator-ramp-delay = <1250>; >> + regulator-ramp-delay = <3125>; >> }; >> >> - buck2_reg: BUCK2 { >> - regulator-name = "buck2"; >> - regulator-min-microvolt = <700000>; >> - regulator-max-microvolt = <1300000>; >> + buck2_reg: regulator@1 { >> + reg = <1>; >> + regulator-compatible = "buck2"; >> + regulator-min-microvolt = <600000>; >> + regulator-max-microvolt = <2187500>; >> regulator-boot-on; >> regulator-always-on; >> - regulator-ramp-delay = <1250>; >> - rohm,dvs-run-voltage = <1000000>; >> - rohm,dvs-idle-voltage = <900000>; >> + regulator-ramp-delay = <3125>; >> }; >> >> - buck3_reg: BUCK3 { >> - // BUCK5 in datasheet >> - regulator-name = "buck3"; >> - regulator-min-microvolt = <700000>; >> - regulator-max-microvolt = <1350000>; >> + buck3_reg: regulator@2 { >> + reg = <2>; >> + regulator-compatible = "buck3"; >> + regulator-min-microvolt = <600000>; >> + regulator-max-microvolt = <2187500>; >> regulator-boot-on; >> regulator-always-on; >> }; >> >> - buck4_reg: BUCK4 { >> - // BUCK6 in datasheet >> - regulator-name = "buck4"; >> - regulator-min-microvolt = <3000000>; >> - regulator-max-microvolt = <3300000>; >> + buck4_reg: regulator@3 { >> + reg = <3>; >> + regulator-compatible = "buck4"; >> + regulator-min-microvolt = <600000>; >> + regulator-max-microvolt = <3400000>; >> regulator-boot-on; >> regulator-always-on; >> }; >> >> - buck5_reg: BUCK5 { >> - // BUCK7 in datasheet >> - regulator-name = "buck5"; >> - regulator-min-microvolt = <1605000>; >> - regulator-max-microvolt = <1995000>; >> + buck5_reg: regulator@4 { >> + reg = <4>; >> + regulator-compatible = "buck5"; >> + regulator-min-microvolt = <600000>; >> + regulator-max-microvolt = <3400000>; >> regulator-boot-on; >> regulator-always-on; >> }; >> >> - buck6_reg: BUCK6 { >> - // BUCK8 in datasheet >> - regulator-name = "buck6"; >> - regulator-min-microvolt = <800000>; >> - regulator-max-microvolt = <1400000>; >> + buck6_reg: regulator@5 { >> + reg = <5>; >> + regulator-compatible = "buck6"; >> + regulator-min-microvolt = <600000>; >> + regulator-max-microvolt = <3400000>; >> regulator-boot-on; >> regulator-always-on; >> }; >> >> - ldo1_reg: LDO1 { >> - regulator-name = "ldo1"; >> + ldo1_reg: regulator@6 { >> + reg = <6>; >> + regulator-compatible = "ldo1"; >> regulator-min-microvolt = <1600000>; >> regulator-max-microvolt = <3300000>; >> regulator-boot-on; >> regulator-always-on; >> }; >> >> - ldo2_reg: LDO2 { >> - regulator-name = "ldo2"; >> + ldo2_reg: regulator@7 { >> + reg = <7>; >> + regulator-compatible = "ldo2"; >> regulator-min-microvolt = <800000>; >> - regulator-max-microvolt = <900000>; >> + regulator-max-microvolt = <1150000>; >> regulator-boot-on; >> regulator-always-on; >> }; >> >> - ldo3_reg: LDO3 { >> - regulator-name = "ldo3"; >> - regulator-min-microvolt = <1800000>; >> + ldo3_reg: regulator@8 { >> + reg = <8>; >> + regulator-compatible = "ldo3"; >> + regulator-min-microvolt = <800000>; >> regulator-max-microvolt = <3300000>; >> regulator-boot-on; >> regulator-always-on; >> }; >> >> - ldo4_reg: LDO4 { >> - regulator-name = "ldo4"; >> - regulator-min-microvolt = <900000>; >> - regulator-max-microvolt = <1800000>; >> + ldo4_reg: regulator@9 { >> + reg = <9>; >> + regulator-compatible = "ldo4"; >> + regulator-min-microvolt = <800000>; >> + regulator-max-microvolt = <3300000>; >> regulator-boot-on; >> regulator-always-on; >> }; >> >> - ldo6_reg: LDO6 { >> - regulator-name = "ldo6"; >> - regulator-min-microvolt = <900000>; >> - regulator-max-microvolt = <1800000>; >> - regulator-boot-on; >> - regulator-always-on; >> + ldo5_reg: regulator@10 { >> + reg = <10>; >> + regulator-compatible = "ldo5"; >> + regulator-min-microvolt = <1800000>; >> + regulator-max-microvolt = <3300000>; >> }; >> + >> }; >> }; >> }; >> diff --git a/board/freescale/imx8mm_evk/spl.c >> b/board/freescale/imx8mm_evk/spl.c >> index 64bc60651d..4ef7f6f180 100644 >> --- a/board/freescale/imx8mm_evk/spl.c >> +++ b/board/freescale/imx8mm_evk/spl.c >> @@ -26,7 +26,7 @@ >> #include <dm/device-internal.h> >> >> #include <power/pmic.h> >> -#include <power/bd71837.h> >> +#include <power/pca9450.h> >> >> DECLARE_GLOBAL_DATA_PTR; >> >> @@ -94,7 +94,7 @@ static int power_init_board(void) >> struct udevice *dev; >> int ret; >> >> - ret = pmic_get("pmic@4b", &dev); >> + ret = pmic_get("pca9450@25", &dev); >> if (ret == -ENODEV) { >> puts("No pmic\n"); >> return 0; >> @@ -102,25 +102,26 @@ static int power_init_board(void) >> if (ret != 0) >> return ret; >> >> - /* decrease RESET key long push time from the default 10s to 10ms */ >> - pmic_reg_write(dev, BD718XX_PWRONCONFIG1, 0x0); >> + /* BUCKxOUT_DVS0/1 control BUCK123 output */ >> + pmic_reg_write(dev, PCA9450_BUCK123_DVS, 0x29); >> >> - /* unlock the PMIC regs */ >> - pmic_reg_write(dev, BD718XX_REGLOCK, 0x1); >> + /* Buck 1 DVS control through PMIC_STBY_REQ */ >> + pmic_reg_write(dev, PCA9450_BUCK1CTRL, 0x59); >> >> - /* increase VDD_SOC to typical value 0.85v before first DRAM access */ >> - pmic_reg_write(dev, BD718XX_BUCK1_VOLT_RUN, 0x0f); >> + /* Set DVS1 to 0.8v for suspend */ >> + pmic_reg_write(dev, PCA9450_BUCK1OUT_DVS1, 0x10); >> >> - /* increase VDD_DRAM to 0.975v for 3Ghz DDR */ >> - pmic_reg_write(dev, BD718XX_1ST_NODVS_BUCK_VOLT, 0x83); >> + /* increase VDD_DRAM to 0.95v for 3Ghz DDR */ >> + pmic_reg_write(dev, PCA9450_BUCK3OUT_DVS0, 0x1C); >> >> -#ifndef CONFIG_IMX8M_LPDDR4 >> - /* increase NVCC_DRAM_1V2 to 1.2v for DDR4 */ >> - pmic_reg_write(dev, BD718XX_4TH_NODVS_BUCK_VOLT, 0x28); >> -#endif >> + /* VDD_DRAM needs off in suspend, set B1_ENMODE=10 (ON by >> PMIC_ON_REQ = H && PMIC_STBY_REQ = L) */ >> + pmic_reg_write(dev, PCA9450_BUCK3CTRL, 0x4a); >> + >> + /* set VDD_SNVS_0V8 from default 0.85V */ >> + pmic_reg_write(dev, PCA9450_LDO2CTRL, 0xC0); >> >> - /* lock the PMIC regs */ >> - pmic_reg_write(dev, BD718XX_REGLOCK, 0x11); >> + /* set WDOG_B_CFG to cold reset */ >> + pmic_reg_write(dev, PCA9450_RESET_CTRL, 0xA1); >> >> return 0; >> } >> diff --git a/configs/imx8mm_evk_defconfig b/configs/imx8mm_evk_defconfig >> index e22b7de56f..ae9e0626dd 100644 >> --- a/configs/imx8mm_evk_defconfig >> +++ b/configs/imx8mm_evk_defconfig >> @@ -83,7 +83,7 @@ CONFIG_PINCTRL=y >> CONFIG_SPL_PINCTRL=y >> CONFIG_PINCTRL_IMX8M=y >> CONFIG_DM_PMIC=y >> -CONFIG_SPL_DM_PMIC_BD71837=y >> +CONFIG_SPL_DM_PMIC_PCA9450=y >> CONFIG_DM_REGULATOR=y >> CONFIG_DM_REGULATOR_FIXED=y >> CONFIG_DM_REGULATOR_GPIO=y >> -- >> 2.30.0 > > -- andrey >
Hi Andrey, On Sun, May 16, 2021 at 11:31 AM ZHIZHIKIN Andrey <andrey.zhizhikin@leica-geosystems.com> wrote: > > Hello Ricardo, > > > -----Original Message----- > > From: Ricardo Salveti <rsalveti@rsalveti.net> > > Sent: Friday, May 14, 2021 5:29 PM > > To: Fabio Estevam <festevam@gmail.com> > > Cc: ZHIZHIKIN Andrey <andrey.zhizhikin@leica-geosystems.com>; Peng Fan > > (OSS) <peng.fan@oss.nxp.com>; sbabic@denx.de; u-boot@lists.denx.de; uboot- > > imx@nxp.com; Ye Li <ye.li@nxp.com>; vanessa.maegima@foundries.io; > > igor.opaniuk@foundries.io > > Subject: Re: [PATCH 03/26] imx8mm_evk: Switch to new imx8mm evk board > > > > > > Hi Fabio, > > > > On Fri, May 14, 2021 at 9:30 AM Fabio Estevam <festevam@gmail.com> wrote: > > > > > > Hi Andrey, > > > > > > On Wed, May 12, 2021 at 6:47 PM ZHIZHIKIN Andrey > > > <andrey.zhizhikin@leica-geosystems.com> wrote: > > > > > > > > Update PMIC to use PCA9540, the legacy board not supported by NXP > > > > > > > > This commit seems rather a "nuclear" to me, as de-facto it drops the > > initialization of ROMH PMIC in > > > > favor of PCA one, leaving all the previous board revisions not to be properly > > sourced. > > > > > > > > I know that there might be no intention to provide a support for earlier > > revisions of i.MX8M Mini > > > > EVKs from NXP, but providing no backward compatibility to those boards > > which are still in use by > > > > a lot of people for development purposes is highly undesirable either. > > > > > > > > TBH, I've tested this patch on the old EVK where ROMH PMIC is present, and > > apart from having some > > > > error messages in SPL regarding the register writes - it does boots. What > > worries me the most though > > > > is that DTS changes some voltage settings, which I'm not sure how the SOC > > would react on. > > > > > > > > To my opinion, this patch should either be complemented with the > > mechanism to provide a > > > > level of backward compatibility (where the PMIC can be dynamically > > identified and instantiated), > > > > or the separate implementation should be presented which would make the > > old board type not to > > > > be bootable at all if it is considered not to be supported any longer. Or this > > patch should be reverted > > > > in an effort to come up with a solution which covers new revision without > > "damaging" the currently > > > > integrated one. > > > > > > > > Fabio / Stefano, > > > > Do you have any thoughts here on how this should be handled further, > > considering the fact that the > > > > backward compatibility of 2021.07 release is not kept for this board type > > across multiple revisions? > > > > > > > > I'd really like to get your opinion here as I do have those boards in > > development and would need to > > > > come up with the idea on what to do with them. > > > > > > > > Also, this should be taken care of in the Yocto, since there is only one > > definition of the i.MX8MM EVK > > > > machine which does not make any distinction regarding the revision. > > > > > > You bring a good point. > > > > > > What about adding a new defconfig to support the old imx8mm-evk with > > > the Rohm PMIC? > > > > > > Then we could have imx8mm_evk_defconfig for the new version and > > > imx8mm_evk_rohm_defconfig for the old one. > > > > > > What do you think? > > > > Maybe a dynamic way to identify if BD71837 or PCA9450 (by probing i2c) > > would work better? > > This might be solution given that there is an implementation in SPL which > can be used to query I2C to determine the PMIC type and get it dynamically. > > I'm not aware if this functionality exist, I would need to search for the reference > in the U-Boot tree for this. > > But still, as I previously replied to Fabio, it would still need to have 2 separate > entries in DTS for both PMICs, and SPL power_init_board(void) code should be > extended to request the PMIC based on the type detected. > > I guess this can be done in 2 steps: first make the PMIC selection based on the > config option in SPL, and then - replace it with dynamic query (if possible). > > > > > Different configs would imply different builds and binaries, which is > > a problem when trying to support a single build for both the old EVK > > and EVKB (and the main difference is the PMIC, nothing really major). > > This is especially true for Yocto builds, but there would be a way to define > separate U-Boot config based on the type, so having 2 separate config files > would not be technically impossible to achieve. > > However, I totally agree with you - one build for both revisions would be the > best solution here. Just as a reference, Toradex has worked around this issue for their imx8mmevk-based design by implementing the dynamic board rev selection in their tree ("verdin-imx8mm: implement hardware version detection"). With this patch, they use the same Uboot defconfig with two different dtbs being selected at runtime in board.c. We have implemented a similar logic in our tree and it worked for both EVK and EVKB versions. > > > > > I also share Andrey's concerns, as we do have several EVKs in hands, > > and having one single build would facilitate quite a bit. > > > > Cheers, > > -- > > Ricardo Salveti de Araujo > > -- andrey Regards, Vanessa
Hello Vanessa, > -----Original Message----- > From: Vanessa Maegima <vanessa.maegima@foundries.io> > Sent: Tuesday, May 18, 2021 3:15 PM > To: ZHIZHIKIN Andrey <andrey.zhizhikin@leica-geosystems.com> > Cc: Ricardo Salveti <rsalveti@rsalveti.net>; Fabio Estevam > <festevam@gmail.com>; Peng Fan (OSS) <peng.fan@oss.nxp.com>; > sbabic@denx.de; u-boot@lists.denx.de; uboot-imx@nxp.com; Ye Li > <ye.li@nxp.com>; igor.opaniuk@foundries.io > Subject: Re: [PATCH 03/26] imx8mm_evk: Switch to new imx8mm evk board > > > Hi Andrey, > > On Sun, May 16, 2021 at 11:31 AM ZHIZHIKIN Andrey <andrey.zhizhikin@leica- > geosystems.com> wrote: > > > > Hello Ricardo, > > > > > -----Original Message----- > > > From: Ricardo Salveti <rsalveti@rsalveti.net> > > > Sent: Friday, May 14, 2021 5:29 PM > > > To: Fabio Estevam <festevam@gmail.com> > > > Cc: ZHIZHIKIN Andrey <andrey.zhizhikin@leica-geosystems.com>; Peng > > > Fan > > > (OSS) <peng.fan@oss.nxp.com>; sbabic@denx.de; u-boot@lists.denx.de; > > > uboot- imx@nxp.com; Ye Li <ye.li@nxp.com>; > > > vanessa.maegima@foundries.io; igor.opaniuk@foundries.io > > > Subject: Re: [PATCH 03/26] imx8mm_evk: Switch to new imx8mm evk > > > board > > > > > > > > > Hi Fabio, > > > > > > On Fri, May 14, 2021 at 9:30 AM Fabio Estevam <festevam@gmail.com> > wrote: > > > > > > > > Hi Andrey, > > > > > > > > On Wed, May 12, 2021 at 6:47 PM ZHIZHIKIN Andrey > > > > <andrey.zhizhikin@leica-geosystems.com> wrote: > > > > > > > > > > Update PMIC to use PCA9540, the legacy board not supported by > > > > > > NXP > > > > > > > > > > This commit seems rather a "nuclear" to me, as de-facto it drops > > > > > the > > > initialization of ROMH PMIC in > > > > > favor of PCA one, leaving all the previous board revisions not > > > > > to be properly > > > sourced. > > > > > > > > > > I know that there might be no intention to provide a support for > > > > > earlier > > > revisions of i.MX8M Mini > > > > > EVKs from NXP, but providing no backward compatibility to those > > > > > boards > > > which are still in use by > > > > > a lot of people for development purposes is highly undesirable either. > > > > > > > > > > TBH, I've tested this patch on the old EVK where ROMH PMIC is > > > > > present, and > > > apart from having some > > > > > error messages in SPL regarding the register writes - it does > > > > > boots. What > > > worries me the most though > > > > > is that DTS changes some voltage settings, which I'm not sure > > > > > how the SOC > > > would react on. > > > > > > > > > > To my opinion, this patch should either be complemented with the > > > mechanism to provide a > > > > > level of backward compatibility (where the PMIC can be > > > > > dynamically > > > identified and instantiated), > > > > > or the separate implementation should be presented which would > > > > > make the > > > old board type not to > > > > > be bootable at all if it is considered not to be supported any > > > > > longer. Or this > > > patch should be reverted > > > > > in an effort to come up with a solution which covers new > > > > > revision without > > > "damaging" the currently > > > > > integrated one. > > > > > > > > > > Fabio / Stefano, > > > > > Do you have any thoughts here on how this should be handled > > > > > further, > > > considering the fact that the > > > > > backward compatibility of 2021.07 release is not kept for this > > > > > board type > > > across multiple revisions? > > > > > > > > > > I'd really like to get your opinion here as I do have those > > > > > boards in > > > development and would need to > > > > > come up with the idea on what to do with them. > > > > > > > > > > Also, this should be taken care of in the Yocto, since there is > > > > > only one > > > definition of the i.MX8MM EVK > > > > > machine which does not make any distinction regarding the revision. > > > > > > > > You bring a good point. > > > > > > > > What about adding a new defconfig to support the old imx8mm-evk > > > > with the Rohm PMIC? > > > > > > > > Then we could have imx8mm_evk_defconfig for the new version and > > > > imx8mm_evk_rohm_defconfig for the old one. > > > > > > > > What do you think? > > > > > > Maybe a dynamic way to identify if BD71837 or PCA9450 (by probing > > > i2c) would work better? > > > > This might be solution given that there is an implementation in SPL > > which can be used to query I2C to determine the PMIC type and get it > dynamically. > > > > I'm not aware if this functionality exist, I would need to search for > > the reference in the U-Boot tree for this. > > > > But still, as I previously replied to Fabio, it would still need to > > have 2 separate entries in DTS for both PMICs, and SPL > > power_init_board(void) code should be extended to request the PMIC based > on the type detected. > > > > I guess this can be done in 2 steps: first make the PMIC selection > > based on the config option in SPL, and then - replace it with dynamic query (if > possible). > > > > > > > > Different configs would imply different builds and binaries, which > > > is a problem when trying to support a single build for both the old > > > EVK and EVKB (and the main difference is the PMIC, nothing really major). > > > > This is especially true for Yocto builds, but there would be a way to > > define separate U-Boot config based on the type, so having 2 separate > > config files would not be technically impossible to achieve. > > > > However, I totally agree with you - one build for both revisions would > > be the best solution here. > > Just as a reference, Toradex has worked around this issue for their imx8mmevk- > based design by implementing the dynamic board rev selection in their tree > ("verdin-imx8mm: implement hardware version detection"). With this patch, > they use the same Uboot defconfig with two different dtbs being selected at > runtime in board.c. I've also found this implementation for Toradex Verdin CoM, but did not track which commit brought it. Thanks for pointing out the commit message - I would certainly have a look at it further! > > We have implemented a similar logic in our tree and it worked for both EVK and > EVKB versions. I was thinking that this would be done by NXP as well for the EVK they distribute, but the statement was rather clear: No backward compatibility is provided as the old EVK is not supported any longer. > > > > > > > > > I also share Andrey's concerns, as we do have several EVKs in hands, > > > and having one single build would facilitate quite a bit. > > > > > > Cheers, > > > -- > > > Ricardo Salveti de Araujo > > > > -- andrey > > Regards, > Vanessa -- andrey
From: Peng Fan <peng.fan@nxp.com> This patchset is to upstream NXP downstream patches targeting next release: 2021.07. - Enviorment cleanup - ddr script update for ddr4/lpddr4 boards - update fuse path - Support i.MX8MQ B2 - Add i.MX8MN 11*11 variant - Change pca9450 API accepting address Jacky Bai (1): imx8mn: Update the DDR4 timing script on imx8mn ddr4 evk Peng Fan (12): tools: imx image: fix write warning imx8mm/p: remove boot.cmd imx8mm_evk: add/cleanup variable for distro imx8mp_evk: add/cleanup variable for distro imx8mp_evk: spl: clean up including headers imx8mp_evk: Increase VDD_ARM to 0.95v Overdrive voltage power: pca9450: add a new parameter for power_pca9450_init imx8mn_evk: drop duplicated code imx8mn: Add LPDDR4 EVK board support imx: logos: use NXP logo imx8m: soc: update fuse path arch: mach-imx: imx8m: fix unique_id read error for imx8mp Sherry Sun (1): imx8mp: ddr: Add inline ECC feature support Ye Li (11): imx8mm_evk: Update to latest LPDDR4 script imx8mm_evk: Switch to new imx8mm evk board imx8mp_evk: Update LPDDR4 timing for new FW 202006 imx8mp_evk: Update LPDDR4 refresh time imx8mn: Add low drive mode support for DDR4/LPDDR4 EVK imx8mn: Add support for 11x11 UltraLite part number imx8m: Update thermal and PMU kernel nodes for dual/single cores imx8m: ddr: Disable CA VREF Training for LPDDR4 iMX8MQ: Recognize the B2 revision misc: ocotp: Update OCOTP driver for iMX8MQ B2 imx8mq_evk: Applying default LPDDR4 script for B2 haidong.zheng (1): imx8mp: refine power on imx8mp board arch/arm/dts/Makefile | 1 + arch/arm/dts/imx8mm-evk-u-boot.dtsi | 4 +- arch/arm/dts/imx8mm-evk.dtsi | 127 +- arch/arm/dts/imx8mn-ddr4-evk-u-boot.dtsi | 3 + arch/arm/dts/imx8mn-evk-u-boot.dtsi | 26 + arch/arm/dts/imx8mn-evk.dts | 128 ++ arch/arm/include/asm/arch-imx/cpu.h | 12 +- arch/arm/include/asm/arch-imx8m/imx-regs.h | 11 + arch/arm/include/asm/mach-imx/sys_proto.h | 6 +- arch/arm/mach-imx/cpu.c | 8 +- arch/arm/mach-imx/imx8m/Kconfig | 6 + arch/arm/mach-imx/imx8m/soc.c | 183 +- board/freescale/imx8mm_evk/boot.cmd | 35 - board/freescale/imx8mm_evk/lpddr4_timing.c | 692 +++---- board/freescale/imx8mm_evk/spl.c | 33 +- board/freescale/imx8mn_evk/Kconfig | 6 +- board/freescale/imx8mn_evk/Makefile | 6 + board/freescale/imx8mn_evk/ddr4_timing.c | 1057 +++++------ board/freescale/imx8mn_evk/ddr4_timing_ld.c | 1057 +++++++++++ board/freescale/imx8mn_evk/lpddr4_timing.c | 1587 +++++++++++++++++ board/freescale/imx8mn_evk/lpddr4_timing_ld.c | 1440 +++++++++++++++ board/freescale/imx8mn_evk/spl.c | 50 +- board/freescale/imx8mp_evk/boot.cmd | 25 - board/freescale/imx8mp_evk/lpddr4_timing.c | 372 +++- board/freescale/imx8mp_evk/spl.c | 38 +- board/freescale/imx8mq_evk/spl.c | 2 +- board/phytec/phycore_imx8mp/spl.c | 2 +- configs/imx8mm_evk_defconfig | 2 +- configs/imx8mn_evk_defconfig | 93 + drivers/ddr/imx/imx8m/Kconfig | 8 + drivers/misc/mxc_ocotp.c | 2 +- drivers/power/pmic/pmic_pca9450.c | 4 +- include/configs/imx8mm_evk.h | 8 +- include/configs/imx8mp_evk.h | 8 +- include/power/pca9450.h | 2 +- tools/imx8image.c | 2 +- tools/imx8mimage.c | 2 +- tools/logos/freescale.bmp | Bin 46738 -> 47670 bytes 38 files changed, 5745 insertions(+), 1303 deletions(-) create mode 100644 arch/arm/dts/imx8mn-evk-u-boot.dtsi create mode 100644 arch/arm/dts/imx8mn-evk.dts delete mode 100644 board/freescale/imx8mm_evk/boot.cmd create mode 100644 board/freescale/imx8mn_evk/ddr4_timing_ld.c create mode 100644 board/freescale/imx8mn_evk/lpddr4_timing.c create mode 100644 board/freescale/imx8mn_evk/lpddr4_timing_ld.c delete mode 100644 board/freescale/imx8mp_evk/boot.cmd mode change 100644 => 100755 board/freescale/imx8mp_evk/lpddr4_timing.c create mode 100644 configs/imx8mn_evk_defconfig -- 2.30.0