[U-Boot] Xilinx Zed Board resets with Master

[Jagan Teki]

On Thu, Mar 27, 2014 at 5:31 PM, Michal Simek <monstr at 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 <monstr at 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 <sjg at 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 <sjg at chromium.org>
>     Tested-by: Che-Liang Chiou <clchiou at chromium.org>
>     Signed-off-by: Simon Glass <sjg at 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.