On 16/10/2014 03:16, Nikolay Dimitrov wrote: > Hi Sean, guys, > > On 10/15/2014 10:47 AM, Sean Cross wrote: >> On 15/10/2014 12:47, Nikolay Dimitrov wrote: >>> Hi Marek, >>> >>> On 10/15/2014 12:38 AM, Marek Vasut wrote: >>>> On Sunday, October 12, 2014 at 08:33:21 AM, Sean Cross wrote: >>>>> On 12/10/2014 05:04, Fabio Estevam wrote: >>>>>> On Sat, Oct 11, 2014 at 11:21 AM, Sean Cross <x...@kosagi.com> >>>>>> wrote: >>>>>>>> Ok, understood. Just curious: which Ethernet PHY is used on the >>>>>>>> novena >>>>>>>> board? >>>>>>> >>>>>>> It's the same Micrel PHY used on the Sabrelite, the KSZ9021. >>>>>> >>>>>> nitrogen/sabrelite holds Ethernet PHY reset low for 10ms, which >>>>>> is in >>>>>> accordance with ksz9021 datasheet. >>>>>> >>>>>> Shouldn't we wait 10ms here as well? >>>>> >>>>> The reference manual for the PHY indicates that you should hold reset >>>>> low for 10ms after the supply voltage stabilizes. So long as it >>>>> takes >>>>> at least 10msto get from the point at which the CPU starts executing >>>>> its >>>>> ROM code to the point at which the reset line is toggled, we will >>>>> be fine. >>>> >>>> This definitelly is the case, so I presume we don't need the delay ? >>> >>> Well, here's how I see the case. >>> >>> After power on, the PHY unfortunately is out of reset (R20G is DNP, >>> imx6 pin pulled high internally after reset). At some unknown point in >>> time the CPU reaches novena_spl_setup_iomux_enet(). During all this >>> time the PHY is still out of reset. Neither this complies with the >>> recommended sequence, and even more doesn't comply if we remove the >>> delay. >>> >>> If we leave the delay as it is currently implemented, the actual reset >>> sequence is just delayed (by the time it takes the CPU to reach the >>> PHY reset code). At this later point we enforce the proper reset >>> sequence: supply rail is obviously now stable, and we keep the PHY >>> reset low for the minimum specified time: 10ms. >>> >>> My understanding is that this is simple and efficient way to guarantee >>> that for all different cases (different temperatures, different CPU >>> silicon revisions, differently configured drivers/subsystems), the PHY >>> reset timing is generated properly, and will be generated properly in >>> the future when the code evolves. >>> >>> Please tell me if I'm missing something. >> I generally think we'd be fine without the delay, putting it into reset >> in the SPL and pulling it out of reset in U-Boot, but I can understand >> the need for future-proofing and clarity. If someone were to copy the >> code from Novena to a new board, they may find the PHY behaving >> unreliably >> >> If 10ms is the difference between "we ought to be fine" and "we'll >> definitely be fine and not surprise anyone", then we should leave the >> delay in. > > Oops, I think my position on this topic seems to be "too hard headed". > I just wanted to justify why I wrote the patch this way, and I didn't > wanted to look like an opposition. > > Sean, you're in the position of the "oem", so I definitely appreciate > your opinion, together with Marek's and Fabio's imx6 expertise. > > So guys, please advice - what should be the final value of this delay, > and I'll re-send the patch if needed.
My opinion is that, following the principle of least surprise, we should leave the delay in. If, sometime in the future, someone were to micro-optimize the boot sequence, they can strip it out then, but in that case it'd make more sense to load Linux directly from SPL. I say leave it in. Sean _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
