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

[Michal Simek <monstr@monstr.eu>]

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_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