Hi Michal, On Wed, Aug 15, 2012 at 3:49 AM, Michal Simek <mon...@monstr.eu> wrote: > Hi Joe, > > sorry missed this one. > > > On 08/14/2012 05:48 PM, Joe Hershberger wrote: >> >> Are you thinking that this will be the one and only Zynq board? >> Perhaps a layout like what Xilinx has in their branch is more >> appropriate. >> >> >> http://git.xilinx.com/?p=u-boot-xarm.git;a=history;f=board/xilinx/zynq_common;hb=refs/heads/master > > > My intention is to have one zynq generic board as I have it for microblaze. > The main reason is that every board design could be different and supporting > all variants is impossible.
I believe this is a fundamental misunderstanding of the Zynq architecture. With the microblaze and virtex ppc architecture you basically have an FPGA that happens to have a processor in it. The Zynq architecture is the opposite... an ARM system that happens to have an FPGA attached to it. The different boards have plenty of hard IP and peripherals available for all of the key interfaces that u-boot needs to be aware of. Certainly there can be other peripherals added to the fabric and those can be handles with device tree. Generally these boards are well defined, unlike microblaze targets. > > When DM is ready to use with OF then DTS will handle the board differences. > That's fine, but I doubt we will see u-boot collapse into directory of DTS files and one board per architecture. I expect it to have much more impact as a way of eliminating the separate targets for boards that have several variants in their configuration (PCI or not, etc). <--snip--> >>> +#define CONFIG_ETHADDR 00:0a:35:00:b2:02 >> >> >> Don't put MAC addresses in a config file. > > > Where should be MAC address setup? In the environment. > > >> >>> +#define CONFIG_IPADDR 192.168.0.105 >>> +#define CONFIG_SERVERIP 192.168.0.101 >>> +#define CONFIG_GATEWAYIP 192.168.0.1 >> >> >> Is this really helpful? > > > yes or no. Why not to define? It is setup for my network > but it can be easily changed. Again... the environment. It is easily added to the environment. > > >> >>> + >>> +#define CONFIG_BOOTP_SERVERIP >>> +#define CONFIG_BOOTP_BOOTPATH >>> +#define CONFIG_BOOTP_GATEWAY >>> +#define CONFIG_BOOTP_HOSTNAME >>> +#define CONFIG_BOOTP_MAY_FAIL >>> + >>> +/* MII and Phylib */ >>> +#define CONFIG_MII >>> +#define CONFIG_SYS_FAULT_ECHO_LINK_DOWN >>> +#define CONFIG_PHYLIB >>> +#define CONFIG_PHY_ATHEROS >>> +#define CONFIG_PHY_BROADCOM >>> +#define CONFIG_PHY_DAVICOM >>> +#define CONFIG_PHY_GIGE >>> +#define CONFIG_PHY_LXT >>> +#define CONFIG_PHY_MARVELL >>> +#define CONFIG_PHY_MICREL >>> +#define CONFIG_PHY_NATSEMI >>> +#define CONFIG_PHY_REALTEK >>> +#define CONFIG_PHY_VITESSE >> >> >> I guess since this is a ficticious board it has every manufacturer's phy >> on it? > > > This is not fictitious board. It is targetting to zc702 with Marwell phy > but this configuration should work for zynq generic board as I describe > above. This comes back to the fact that you know what phy is on this board because it is not a random board with a Zynq on it, it is a specific board with specific peripherals. > > I have checked u-boot size and enabling all phys increase u-boot size for > 4.5kB > which is fine. That's not a reasonable approach. It you take that approach with every peripheral, then u-boot explodes in size. > > Also still there are others option with using programmable logic with > axi_ethernet > IP where other phys can be used. And yet this board has no other phy on the fabric. Let the board that does enable those phys. -Joe _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
