On Tue, Jun 06, 2017 at 08:18:40AM +0200, Sascha Hauer wrote: > On Fri, Jun 02, 2017 at 03:18:08PM +0200, Michael Grzeschik wrote: > > This adds support support for the i.MX6UL Technexion Pico Hobbit. > > The board comes with different amounts of RAM. We create one image > > for the 256MB and one for the 512MB variant. > > > > Signed-off-by: Michael Grzeschik <[email protected]> > > --- > > v1 -> v2: - removed already prepared clock setup > > > > + > > +&usdhc1 { > > + #address-cells = <1>; > > + #size-cells = <1>; > > + > > + partition@0 { > > + label = "barebox"; > > + reg = <0x0 0xc0000>; > > + }; > > + > > + environment_usdhc1: partition@c0000 { > > + label = "barebox-environment"; > > + reg = <0xc0000 0x40000>; > > + }; > > +}; > > + > > +&fec2 { > > + /* > > + There are two possible ways to start the phy. Let the hardware > > + reset it properly or reset it a second time in software. > > + Unfortunetly the phy needs some microseconds after reset to > > + settle down. As there is no property like > > + phy-post-reset-delay, we better leave the reset to the > > + hardware. > > + */ > > + /delete-property/ phy-reset-gpios; > > + /delete-property/ phy-reset-duration; > > Recent Kernels support phy-reset-post-delay. Can we just add support for > it in barebox aswell?
Could we for now stick with this? When I write the phy-reset-post-delay patches I will then adopt this node in the regarding series. This gives me some time, as I can not test the post-delay patch in the next two weeks. Thanks, Michael -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | _______________________________________________ barebox mailing list [email protected] http://lists.infradead.org/mailman/listinfo/barebox
