Hi Joe,
On 08/15/2012 07:31 PM, Joe Hershberger wrote:
Hi Michal,
On Wed, Aug 15, 2012 at 3:49 AM, Michal Simek monstr@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_commo...
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.
I don't think that this is not my fundamental misunderstanding.
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.
We are working in this area for quite a long time to be convinced that this is the best solution we can make. And even this is only one way how to maintain this platform. Creating new u-boot board description for every board or configuration is bad idea.
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.
Zynq is not like any other ARM based board. There is still a lot of space for configuring it and you need all the time any input from user even if you use reference board. All reference boards contains a lot of connectors which started with FMC, pins, configurable options.
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).
My expectation is to have one DTS for microblaze and one for Zynq. Then user can use device-tree generator from Xilinx EDK to get DTS and will replace template in u-boot.
<--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.
no problem with that
+#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.
no problem with that
+#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.
Of course you always know it but not if you create generic platform. But if you like I will remove others phys which are not physically placed on zc702.
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.
Don't agree with that. There is not unlimited number of peripherals/drivers which you can use. I don't expect any u-boot size explosion. Enabling support for basic drivers is reasonable.
Anyway I am OK to remove other phys and wait till DM with OF is ready. Because in that time I expect that we will have to enable all platform acceptable drivers anyway.
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.
I don't think that creating special u-boot board for every zynq platform is good solution. But we will see when DM is done.
Thanks, Michal