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 <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.
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
--
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
