From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michal Simek Date: Thu, 16 Aug 2012 08:12:37 +0200 Subject: [U-Boot] [PATCH 4/4 v2] xilinx: Add new Zynq board In-Reply-To: References: <1344946559-12498-1-git-send-email-monstr@monstr.eu> <502B628B.6060603@monstr.eu> Message-ID: <502C8F55.3040204@monstr.eu> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 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