[U-Boot] [PATCH 4/4 v2] xilinx: Add new Zynq board

[Joe Hershberger]

Hi Michal,

On Wed, Aug 15, 2012 at 3:49 AM, Michal Simek <monstr at 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