On Thu, Mar 27, 2014 at 5:31 PM, Michal Simek <mon...@monstr.eu> wrote: > Hi Tim, > > On 03/27/2014 11:33 AM, Tim Sander wrote: >> Hi Michael, Jagan >> >> Thanks for your replies. >>> On Thu, Mar 27, 2014 at 1:51 PM, Michal Simek <mon...@monstr.eu> wrote: >>>> Hi, >>>> >>>> On 03/27/2014 09:08 AM, Tim Sander wrote: >>>>> Hi >>>>> >>>>> As i have seen that the Xilinx support has entered master i just tried to >>>>> boot it on a Xilinx Zynx Zedboard Rev. D. The build works with the >>>>> xilinx git tree so i am pretty confident that its not some issues with >>>>> bootgen or the embedded fpga image. >>>>> >>>>> The board loads the fpga which can be seen by the blue "done" led of the >>>>> ZedBoard. But then the LED turns off and about after a second or so it >>>>> just >>>>> lights up shortly again to turn off again. So it seems as if the board is >>>>> somehow caught in a reboot loop. Any ideas what might be wrong? >>>>> >>>>> I am building with: >>>>> export PATH=~/xilinx/SDK/2013.3/gnu/arm/lin/bin:$PATH >>>>> export CROSS_COMPILE=arm-xilinx-linux-gnueabi- >>>>> make clean >>>>> make distclean >>>>> make zynq_zed_config >>>>> make >>>>> >>>>> The BOOT.BIN is build >>>>> xilinx/SDK/2013.3/bin/lin64/bootgen -image u-boot.bif -w on -o BOOT.BIN >>>>> >>>>> And u-boot.bif looks like that: >>>>> the_ROM_image: >>>>> { >>>>> >>>>> [bootloader]zynq_fsbl_0.elf >>>>> >>>>> system.bit >>>>> u-boot.elf >> I have added the zynq-zed.dtb file here, as i was not sure where else to put >> it... > > I have just tested on zedboard rev-C I have here > > Head u-boot commit commit > commit 2c072c958bb544c72f0e848375803dbd6971f022 > Author: Simon Glass <s...@chromium.org> > Date: Thu Feb 27 13:26:25 2014 -0700 > > sandbox: config: Enable cros_ec emulation and related items > > Enable the Chrome OS EC emulation for sandbox along with LCD, sound > expanded GPIOs and a few other options to make this work correctly. > > Reviewed-by: Simon Glass <s...@chromium.org> > Tested-by: Che-Liang Chiou <clch...@chromium.org> > Signed-off-by: Simon Glass <s...@chromium.org> > > Copy attached file over this one > arch/arm/dts/zynq-zed.dts > > export ARCH=arm > export CROSS_COMPILE=arm-xilinx-linux-gnueabi- > make zynq_zed_config > make -j > > run xmd > > connect arm hw > dow zynq_fsbl.elf > run > stop > dow -data u-boot-dtb.bin 0x4000000 > rwr pc 0x4000000 > con > exit > > And you should see something like this on your console > > U-Boot 2014.04-rc2-00061-g2c072c9-dirty (Mar 27 2014 - 12:47:39) > > I2C: ready > Memory: ECC disabled > DRAM: 512 MiB > MMC: zynq_sdhci: 0 > Using default environment > > In: serial > Out: serial > Err: serial > Model: Xilinx Zynq > Net: Gem.e000b000 > Warning: failed to set MAC address > > Hit any key to stop autoboot: 0 > zynq-uboot> > > > >>>>> } >>>> >>>> mainline u-boot support is using configuration based on dts files >>>> (OF_CONTROL) And because our DTSes are almost empty in mainline I expect >>>> you are not able to see anything from u-boot. >>>> I recommend you to copy dts file from xilinx kernel and then use >>>> u-boot-dtb version. >> Ok i tried this, and now the reboot loops seems to be gone. The blue "done" >> led now only switches "on" one time and stays on. Unfortunatly i still don't >> see anything on the console in this case. >> I can see that the registers >> lr 0x1d70 0x1d70 >> pc 0xcf6c 0xcf6c >> But according to the u-boot map there is nothing and i am not sure how to >> get information about the relocation without u-boot command line. >> >>>> Or the second option is to remove OF_CONTROL from >>>> zynq-common.h file and then I hope you should be able to see something on >>>> console. >> Removeing OF_CONTROL gives a compile error: >> xilinx/zynq/u-boot-xlnx/arch/arm/lib/board.c:633: undefined reference to >> `checkboard' >> lib/built-in.o: In function `rsa_verify_with_keynode': >> xilinx/zynq/u-boot-xlnx/lib/rsa/rsa-verify.c:284: undefined reference to >> `fdtdec_get_int' > > More things has changed recently. > If you do these changes then non DT configuration is performed. > > diff --git a/board/xilinx/zynq/board.c b/board/xilinx/zynq/board.c > index 485a5e4..559ef3d 100644 > --- a/board/xilinx/zynq/board.c > +++ b/board/xilinx/zynq/board.c > @@ -62,6 +62,11 @@ int board_init(void) > return 0; > } > > +int checkboard(void) > +{ > + return 0; > +} > + > int board_late_init(void) > { > switch ((zynq_slcr_get_boot_mode()) & ZYNQ_BM_MASK) { > diff --git a/include/configs/zynq-common.h b/include/configs/zynq-common.h > index 731e69b..8a63cd5 100644 > --- a/include/configs/zynq-common.h > +++ b/include/configs/zynq-common.h > @@ -200,14 +200,8 @@ > #define CONFIG_FIT_VERBOSE 1 /* enable fit_format_{error,warning}() */ > > /* FDT support */ > -#define CONFIG_OF_CONTROL > -#define CONFIG_OF_SEPARATE > #define CONFIG_DISPLAY_BOARDINFO_LATE > > -/* RSA support */ > -#define CONFIG_FIT_SIGNATURE > -#define CONFIG_RSA > - > /* Extend size of kernel image for uncompression */ > #define CONFIG_SYS_BOOTM_LEN (20 * 1024 * 1024) > > > Then you can use u-boot also for boot.bin (bootgen) generation. > > load fsbl as above and then > dow u-boot > run > exit > > > >>> If you use ML, as Michal said - u-boot operates through FDT support. >>> But I guess even if you use u-boot.elf with FDT enabled, you must get >>> the below error >>> ** CONFIG_OF_CONTROL defined but no FDT - please see doc/README.fdt-control" >> Mh, i now appended the fdt in the bif file. Is this the right approach? > > I won't work. > >>> Means even uart node is not written in zynq-zed.dts serial >>> configurations are static driver it self >>> as of now. >> Does this mean that the serial drivers are statically defined and do not take >> the device tree file into account? > > Jagan wasn't correct on this one because one of my patch series has changed > this. > For static configuration (without OF_CONTROL) are driver statically defined. > For DT configuration is console selection taken from DTS/DTB. Yes - I haven't check OF_ support is pushed on master as well.
> >>> Please check and may be you can try u-boot-dtb.elf. >> Mh, don't know how to create this kind of file? > > Jagan maybe knows more but I don't think u-boot-dtb.elf is generated. > Just u-boot-dtb.bin is generated which should be copied as data file > in xmd and not sure if binary file can be directly used for bootgen. IMHO, there is a file u-boot-dtb (elf) generated when we build FDT u-boot I thought that can have a facility boot using BOOT.BIN. I guess it's good to have a try. thanks! -- Jagan. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot