diff mbox

[U-Boot] Xilinx Zed Board resets with Master

Message ID 53341331.8060905@monstr.eu
State Not Applicable
Delegated to: Michal Simek
Headers show

Commit Message

Michal Simek March 27, 2014, 12:01 p.m. UTC
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@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@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@chromium.org>
    Tested-by: Che-Liang Chiou <clchiou@chromium.org>
    Signed-off-by: Simon Glass <sjg@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.


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.

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

Thanks,
Michal

Comments

Jagan Teki March 27, 2014, 12:11 p.m. UTC | #1
On Thu, Mar 27, 2014 at 5:31 PM, Michal Simek <monstr@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@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@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@chromium.org>
>     Tested-by: Che-Liang Chiou <clchiou@chromium.org>
>     Signed-off-by: Simon Glass <sjg@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!
Michal Simek March 27, 2014, 1:17 p.m. UTC | #2
>>>> 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.

Here is how files are generated.
[u-boot]$ make -j8 V=1 | grep u-boot\.dtb
  cp dts/dt.dtb u-boot.dtb
  cat u-boot.bin dts/dt.dtb > u-boot-dtb.bin

u-boot.dtb is just dtb file.

[u-boot]$ ls -la u-boot*
-rwxr-xr-x 1 monstr monstr 1525805 2014-03-27 14:13 u-boot
-rw-r--r-- 1 monstr monstr  270608 2014-03-27 14:13 u-boot.bin
-rw-r--r-- 1 monstr monstr   11860 2014-03-27 13:00 u-boot.dtb
-rw-r--r-- 1 monstr monstr  282468 2014-03-27 14:13 u-boot-dtb.bin
-rw-r--r-- 1 monstr monstr  270672 2014-03-27 14:13 u-boot.img
-rw-r--r-- 1 monstr monstr    1179 2014-03-27 12:55 u-boot.lds
-rw-r--r-- 1 monstr monstr  267756 2014-03-27 14:13 u-boot.map
-rw-r--r-- 1 monstr monstr  811906 2014-03-27 14:13 u-boot.srec
[u-boot]$ dtc -O dts -I dtb u-boot.dtb | head -n 20
/dts-v1/;

/ {
	#address-cells = <0x1>;
	#size-cells = <0x1>;
	compatible = "xlnx,zynq-7000";
	model = "Xilinx Zynq";

	aliases {
		ethernet0 = "/amba@0/ps7-ethernet@e000b000";
		serial0 = "/amba@0/serial@e0001000";
		spi0 = "/amba@0/ps7-qspi@e000d000";
	};

	chosen {
		bootargs = "console=ttyPS0,115200 root=/dev/ram rw earlyprintk";
		linux,stdout-path = "/amba@0/serial@e0001000";
	};

	cpus {

M
Tim Sander March 27, 2014, 4:32 p.m. UTC | #3
Hi Michal
Am Donnerstag, 27. März 2014, 14:17:41 schrieb Michal Simek:
> >>>> 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.
If adding the dtb file in the boot.bif file is not the right way and no elf file 
with dtb is generated: What is the right way to generate an image for use with 
the SD-Card?

Best regards
Tim
Michal Simek March 27, 2014, 4:46 p.m. UTC | #4
Hi Tim,

On 03/27/2014 05:32 PM, Tim Sander wrote:
> Hi Michal
> Am Donnerstag, 27. März 2014, 14:17:41 schrieb Michal Simek:
>>>>>> 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.
> If adding the dtb file in the boot.bif file is not the right way and no elf file 
> with dtb is generated: What is the right way to generate an image for use with 
> the SD-Card?

you can just use static u-boot configuration.
I have never tried to add dtb as partition to boot.bin.
If you want to use this dtb driver u-boot I would suggest you
to look at u-boot SPL which should be able to handle binary formats
with dtbs.

Thanks,
Michal
diff mbox

Patch

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)