Xilinx Zed Board resets with Master

U-Boot Tim Sander 4 participants 14 messages Mar 27, 2014 – Apr 3, 2014 Arm/Zynq architecture

Share & tools

Tim Sander

author

2014-03-27 08:08 UTC #0 lore raw

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
}

Best regards
Tim

Michal Simek

2014-03-27 08:21 UTC #1 lore raw

Hi,

Quoted 23 lines · Tim Sander

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

Quoted 7 lines

And u-boot.bif looks like that:
the_ROM_image:
{
[bootloader]zynq_fsbl_0.elf
system.bit
u-boot.elf
}

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

Thanks,
Michal

Signature · 14 lines

Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140327/fec525a0/attachment.pgp>

Jagan Teki

2014-03-27 08:50 UTC #2 lore raw

Hi Tim,

Quoted 34 lines · Michal Simek

Hi,
Quoted 23 lines · Tim Sander
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
Quoted 7 lines
And u-boot.bif looks like that:
the_ROM_image:
{
[bootloader]zynq_fsbl_0.elf
system.bit
u-boot.elf
}

Quoted 6 lines

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

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"

Means even uart node is not written in zynq-zed.dts serial configurations are static driver it self
as of now.

Please check and may be you can try u-boot-dtb.elf.

thanks!

Signature · 1 line

Jagan.

Tim Sander

author

2014-03-27 10:33 UTC #3 lore raw

Hi Michael, Jagan

Thanks for your replies.

Quoted 28 lines · Michal Simek

Quoted 27 lines
Hi,
Quoted 24 lines · Tim Sander
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

Quoted 8 lines

Quoted 8 lines
Quoted 8 lines
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...

Quoted 7 lines

Quoted 7 lines
Quoted 1 line
}
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.

Quoted 3 lines

Quoted 3 lines
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'

Quoted 4 lines

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?

Quoted 3 lines

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?

Quoted 1 line

Please check and may be you can try u-boot-dtb.elf.

Mh, don't know how to create this kind of file?

Best regards
Tim

Michal Simek

2014-03-27 12:01 UTC #4 lore raw

Hi Tim,

Quoted 35 lines · Tim Sander

Hi Michael, Jagan
Thanks for your replies.
Quoted 32 lines · Michal Simek
Quoted 31 lines
Hi,
Quoted 28 lines · Tim Sander
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:
{

Quoted 6 lines

Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
[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 <[email protected]>
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 <[email protected]>

Tested-by Che-Liang Chiou <[email protected]>

Signed-off-by Simon Glass <[email protected]>

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>

Quoted 19 lines

Quoted 7 lines
Quoted 7 lines
Quoted 1 line
}
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.
Quoted 3 lines
Quoted 3 lines
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.

Quoted 6 lines

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.

board/xilinx/zynq/board.c +5 -0

index 485a5e4..559ef3d 100644
@@ -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) {

include/configs/zynq-common.h +0 -6

index 731e69b..8a63cd5 100644
@@ -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

Quoted 5 lines

Quoted 4 lines
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.

Quoted 5 lines

Quoted 3 lines
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.

Quoted 2 lines

Quoted 1 line
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

Signature · 334 lines

Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform

-------------- next part --------------
/*
 * Device Tree Generator version: 1.1
 *
 * (C) Copyright 2007-2013 Xilinx, Inc.
 * (C) Copyright 2007-2013 Michal Simek
 * (C) Copyright 2007-2012 PetaLogix Qld Pty Ltd
 *
 * Michal SIMEK <[email protected]>
 *
 * CAUTION: This file is automatically generated by libgen.
 * Version: Xilinx EDK 14.5 EDK_P.58f
 *
 */

/dts-v1/;
/ {
	#address-cells = <1>;
	#size-cells = <1>;
	compatible = "xlnx,zynq-7000";
	model = "Xilinx Zynq";
	aliases {
		ethernet0 = &ps7_ethernet_0;
		serial0 = &ps7_uart_1;
		spi0 = &ps7_qspi_0;
	} ;
	chosen {
		bootargs = "console=ttyPS0,115200 root=/dev/ram rw earlyprintk";
		linux,stdout-path = "/amba at 0/serial at e0001000";
	} ;
	cpus {
		#address-cells = <1>;
		#size-cells = <0>;
		ps7_cortexa9_0: cpu at 0 {
			bus-handle = <&ps7_axi_interconnect_0>;
			clock-latency = <1000>;
			clocks = <&clkc 3>;
			compatible = "arm,cortex-a9";
			device_type = "cpu";
			interrupt-handle = <&ps7_scugic_0>;
			operating-points = <666667 1000000 333334 1000000 222223 1000000>;
			reg = <0x0>;
		} ;
		ps7_cortexa9_1: cpu at 1 {
			bus-handle = <&ps7_axi_interconnect_0>;
			clocks = <&clkc 3>;
			compatible = "arm,cortex-a9";
			device_type = "cpu";
			interrupt-handle = <&ps7_scugic_0>;
			reg = <0x1>;
		} ;
	} ;
	pmu {
		compatible = "arm,cortex-a9-pmu";
		interrupt-parent = <&ps7_scugic_0>;
		interrupts = <0 5 4>, <0 6 4>;
		reg = <0xf8891000 0x1000>, <0xf8893000 0x1000>;
		reg-names = "cpu0", "cpu1";
	} ;
	ps7_ddr_0: memory at 0 {
		device_type = "memory";
		reg = <0x0 0x20000000>;
	} ;
	ps7_axi_interconnect_0: amba at 0 {
		#address-cells = <1>;
		#size-cells = <1>;
		compatible = "xlnx,ps7-axi-interconnect-1.00.a", "simple-bus";
		ranges ;
		ps7_afi_0: ps7-afi at f8008000 {
			compatible = "xlnx,ps7-afi-1.00.a";
			reg = <0xf8008000 0x1000>;
		} ;
		ps7_afi_1: ps7-afi at f8009000 {
			compatible = "xlnx,ps7-afi-1.00.a";
			reg = <0xf8009000 0x1000>;
		} ;
		ps7_afi_2: ps7-afi at f800a000 {
			compatible = "xlnx,ps7-afi-1.00.a";
			reg = <0xf800a000 0x1000>;
		} ;
		ps7_afi_3: ps7-afi at f800b000 {
			compatible = "xlnx,ps7-afi-1.00.a";
			reg = <0xf800b000 0x1000>;
		} ;
		ps7_ddrc_0: ps7-ddrc at f8006000 {
			compatible = "xlnx,ps7-ddrc-1.00.a", "xlnx,ps7-ddrc", "xlnx,zynq-ddrc-1.00.a";
			reg = <0xf8006000 0x1000>;
			xlnx,has-ecc = <0x0>;
		} ;
		ps7_dev_cfg_0: ps7-dev-cfg at f8007000 {
			clock-names = "ref_clk", "fclk0", "fclk1", "fclk2", "fclk3";
			clocks = <&clkc 12>, <&clkc 15>, <&clkc 16>, <&clkc 17>, <&clkc 18>;
			compatible = "xlnx,ps7-dev-cfg-1.00.a";
			interrupt-parent = <&ps7_scugic_0>;
			interrupts = <0 8 4>;
			reg = <0xf8007000 0x100>;
		} ;
		ps7_dma_s: ps7-dma at f8003000 {
			#dma-cells = <1>;
			#dma-channels = <8>;
			#dma-requests = <4>;
			clock-names = "apb_pclk";
			clocks = <&clkc 27>;
			compatible = "xlnx,ps7-dma-1.00.a", "arm,primecell", "arm,pl330";
			interrupt-names = "abort", "dma0", "dma1", "dma2", "dma3",
				"dma4", "dma5", "dma6", "dma7";
			interrupt-parent = <&ps7_scugic_0>;
			interrupts = <0 13 4>, <0 14 4>, <0 15 4>, <0 16 4>, <0 17 4>, <0 40 4>, <0 41 4>, <0 42 4>, <0 43 4>;
			reg = <0xf8003000 0x1000>;
		} ;
		ps7_ethernet_0: ps7-ethernet at e000b000 {
			#address-cells = <1>;
			#size-cells = <0>;
			clock-names = "ref_clk", "aper_clk";
			clocks = <&clkc 13>, <&clkc 30>;
			compatible = "xlnx,ps7-ethernet-1.00.a";
			interrupt-parent = <&ps7_scugic_0>;
			interrupts = <0 22 4>;
			local-mac-address = [00 0a 35 00 00 00];
			phy-handle = <&phy0>;
			phy-mode = "rgmii-id";
			reg = <0xe000b000 0x1000>;
			xlnx,eth-mode = <0x1>;
			xlnx,has-mdio = <0x1>;
			xlnx,ptp-enet-clock = <111111115>;
			mdio {
				#address-cells = <1>;
				#size-cells = <0>;
				phy0: phy at 0 {
					compatible = "marvell,88e1510";
					device_type = "ethernet-phy";
					reg = <0>;
				} ;
			} ;
		} ;
		ps7_globaltimer_0: ps7-globaltimer at f8f00200 {
			clocks = <&clkc 4>;
			compatible = "xlnx,ps7-globaltimer-1.00.a", "arm,cortex-a9-global-timer";
			interrupt-parent = <&ps7_scugic_0>;
			interrupts = <1 11 0x301>;
			reg = <0xf8f00200 0x100>;
		} ;
		ps7_gpio_0: ps7-gpio at e000a000 {
			#gpio-cells = <2>;
			clocks = <&clkc 42>;
			compatible = "xlnx,ps7-gpio-1.00.a", "xlnx,zynq-gpio-1.00.a";
			emio-gpio-width = <64>;
			gpio-controller ;
			gpio-mask-high = <0xc0000>;
			gpio-mask-low = <0xfe81>;
			interrupt-parent = <&ps7_scugic_0>;
			interrupts = <0 20 4>;
			reg = <0xe000a000 0x1000>;
		} ;
		ps7_iop_bus_config_0: ps7-iop-bus-config at e0200000 {
			compatible = "xlnx,ps7-iop-bus-config-1.00.a";
			reg = <0xe0200000 0x1000>;
		} ;
		ps7_ocmc_0: ps7-ocmc at f800c000 {
			compatible = "xlnx,ps7-ocmc-1.00.a", "xlnx,zynq-ocm-1.0";
			interrupt-parent = <&ps7_scugic_0>;
			interrupts = <0 3 4>;
			reg = <0xf800c000 0x1000>;
		} ;
		ps7_pl310_0: ps7-pl310 at f8f02000 {
			arm,data-latency = <3 2 2>;
			arm,tag-latency = <2 2 2>;
			cache-level = <2>;
			cache-unified ;
			compatible = "xlnx,ps7-pl310-1.00.a", "arm,pl310-cache";
			interrupt-parent = <&ps7_scugic_0>;
			interrupts = <0 2 4>;
			reg = <0xf8f02000 0x1000>;
		} ;
		ps7_qspi_0: ps7-qspi at e000d000 {
			clock-names = "ref_clk", "aper_clk";
			clocks = <&clkc 10>, <&clkc 43>;
			compatible = "xlnx,ps7-qspi-1.00.a", "xlnx,zynq-qspi-1.00.a";
			interrupt-parent = <&ps7_scugic_0>;
			interrupts = <0 19 4>;
			is-dual = <0>;
			num-chip-select = <1>;
			reg = <0xe000d000 0x1000>;
			xlnx,fb-clk = <0x1>;
			xlnx,qspi-mode = <0x0>;
			#address-cells = <1>;
			#size-cells = <0>;
			flash at 0 {
				compatible = "n25q128";
				reg = <0x0>;
				spi-max-frequency = <50000000>;
				#address-cells = <1>;
				#size-cells = <1>;
				partition at qspi-fsbl-uboot {
					label = "qspi-fsbl-uboot";
					reg = <0x0 0x100000>;
				};
				partition at qspi-linux {
					label = "qspi-linux";
					reg = <0x100000 0x500000>;
				};
				partition at qspi-device-tree {
					label = "qspi-device-tree";
					reg = <0x600000 0x20000>;
				};
				partition at qspi-rootfs {
					label = "qspi-rootfs";
					reg = <0x620000 0x5E0000>;
				};
				partition at qspi-bitstream {
					label = "qspi-bitstream";
					reg = <0xC00000 0x400000>;
				};
			};

		} ;
		ps7_qspi_linear_0: ps7-qspi-linear at fc000000 {
			clock-names = "ref_clk", "aper_clk";
			clocks = <&clkc 10>, <&clkc 43>;
			compatible = "xlnx,ps7-qspi-linear-1.00.a";
			reg = <0xfc000000 0x1000000>;
		} ;
		ps7_scugic_0: ps7-scugic at f8f01000 {
			#address-cells = <2>;
			#interrupt-cells = <3>;
			#size-cells = <1>;
			compatible = "xlnx,ps7-scugic-1.00.a", "arm,cortex-a9-gic", "arm,gic";
			interrupt-controller ;
			num_cpus = <2>;
			num_interrupts = <96>;
			reg = <0xf8f01000 0x1000>, <0xf8f00100 0x100>;
		} ;
		ps7_scutimer_0: ps7-scutimer at f8f00600 {
			clocks = <&clkc 4>;
			compatible = "xlnx,ps7-scutimer-1.00.a", "arm,cortex-a9-twd-timer";
			interrupt-parent = <&ps7_scugic_0>;
			interrupts = <1 13 0x301>;
			reg = <0xf8f00600 0x20>;
		} ;
		ps7_scuwdt_0: ps7-scuwdt at f8f00620 {
			clocks = <&clkc 4>;
			compatible = "xlnx,ps7-scuwdt-1.00.a";
			device_type = "watchdog";
			interrupt-parent = <&ps7_scugic_0>;
			interrupts = <1 14 0x301>;
			reg = <0xf8f00620 0xe0>;
		} ;
		ps7_sd_0: ps7-sdio at e0100000 {
			clock-frequency = <50000000>;
			clock-names = "clk_xin", "clk_ahb";
			clocks = <&clkc 21>, <&clkc 32>;
			compatible = "xlnx,ps7-sdio-1.00.a", "generic-sdhci", "arasan,sdhci-8.9a";
			interrupt-parent = <&ps7_scugic_0>;
			interrupts = <0 24 4>;
			reg = <0xe0100000 0x1000>;
			xlnx,has-cd = <0x1>;
			xlnx,has-power = <0x0>;
			xlnx,has-wp = <0x1>;
		} ;
		ps7_slcr_0: ps7-slcr at f8000000 {
			compatible = "xlnx,ps7-slcr-1.00.a", "xlnx,zynq-slcr";
			reg = <0xf8000000 0x1000>;
			clocks {
				#address-cells = <1>;
				#size-cells = <0>;
				clkc: clkc {
					#clock-cells = <1>;
					clock-output-names = "armpll", "ddrpll", "iopll", "cpu_6or4x", "cpu_3or2x",
						"cpu_2x", "cpu_1x", "ddr2x", "ddr3x", "dci",
						"lqspi", "smc", "pcap", "gem0", "gem1",
						"fclk0", "fclk1", "fclk2", "fclk3", "can0",
						"can1", "sdio0", "sdio1", "uart0", "uart1",
						"spi0", "spi1", "dma", "usb0_aper", "usb1_aper",
						"gem0_aper", "gem1_aper", "sdio0_aper", "sdio1_aper", "spi0_aper",
						"spi1_aper", "can0_aper", "can1_aper", "i2c0_aper", "i2c1_aper",
						"uart0_aper", "uart1_aper", "gpio_aper", "lqspi_aper", "smc_aper",
						"swdt", "dbg_trc", "dbg_apb";
					compatible = "xlnx,ps7-clkc";
					fclk-enable = <0xf>;
					ps-clk-frequency = <33333333>;
				} ;
			} ;
		} ;
		ps7_ttc_0: ps7-ttc at f8001000 {
			clocks = <&clkc 6>;
			compatible = "xlnx,ps7-ttc-1.00.a", "cdns,ttc";
			interrupt-names = "ttc0", "ttc1", "ttc2";
			interrupt-parent = <&ps7_scugic_0>;
			interrupts = <0 10 4>, <0 11 4>, <0 12 4>;
			reg = <0xf8001000 0x1000>;
		} ;
		ps7_uart_1: serial at e0001000 {
			clock-names = "ref_clk", "aper_clk";
			clocks = <&clkc 24>, <&clkc 41>;
			compatible = "xlnx,ps7-uart-1.00.a", "xlnx,xuartps";
			current-speed = <115200>;
			device_type = "serial";
			interrupt-parent = <&ps7_scugic_0>;
			interrupts = <0 50 4>;
			port-number = <0>;
			reg = <0xe0001000 0x1000>;
			xlnx,has-modem = <0x0>;
		} ;
		ps7_usb_0: ps7-usb at e0002000 {
			clocks = <&clkc 28>;
			compatible = "xlnx,ps7-usb-1.00.a", "xlnx,zynq-usb-1.00.a";
			dr_mode = "host";
			interrupt-parent = <&ps7_scugic_0>;
			interrupts = <0 21 4>;
			phy_type = "ulpi";
			reg = <0xe0002000 0x1000>;
		} ;
		ps7_xadc: ps7-xadc at f8007100 {
			clocks = <&clkc 12>;
			compatible = "xlnx,ps7-xadc-1.00.a";
			interrupt-parent = <&ps7_scugic_0>;
			interrupts = <0 7 4>;
			reg = <0xf8007100 0x20>;
		} ;
	} ;
} ;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140327/b00e758d/attachment.pgp>

Michal Simek

2014-03-27 12:05 UTC #5 lore raw

Quoted 156 lines · Michal Simek

Hi Tim,
Quoted 35 lines · Tim Sander
Hi Michael, Jagan
Thanks for your replies.
Quoted 32 lines · Michal Simek
Quoted 31 lines
Hi,
Quoted 28 lines · Tim Sander
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:
{
Quoted 6 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
[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 <[email protected]>
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 <[email protected]>
Tested-by Che-Liang Chiou <[email protected]>
Signed-off-by Simon Glass <[email protected]>
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>
Quoted 19 lines
Quoted 7 lines
Quoted 7 lines
Quoted 1 line
}
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.
Quoted 3 lines
Quoted 3 lines
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.
Quoted 6 lines
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.
board/xilinx/zynq/board.c +5 -0
index 485a5e4..559ef3d 100644
@@ -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) {
include/configs/zynq-common.h +0 -1
index 731e69b..8a63cd5 100644
@@ -200,14 +200,8 @@
 #define CONFIG_FIT_VERBOSE     1 /* enable fit_format_{error,warning}() */
 
 /* FDT support */
-#define CONFIG_OF_CONTROL

include/configs/zynq-common.h line 207

Quoted 10 lines

include/configs/zynq-common.h +0 -5

-#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)

I was too fast for static configuration you can just removed this. (checkboard() function is required by CONFIG_DISPLAY_BOARDINFO_LATE) which I have disabled here.

include/configs/zynq-common.h +0 -9

index 731e69b..0d5a145 100644
@@ -199,15 +199,6 @@
 #define CONFIG_FIT
 #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)

Thanks,
Michal

Signature · 14 lines

Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140327/8cecb2c2/attachment.pgp>

Jagan Teki

2014-03-27 12:11 UTC #6 lore raw

In reply to Michal Simek

Quoted 187 lines · Michal Simek

Hi Tim,
Quoted 35 lines · Tim Sander
Hi Michael, Jagan
Thanks for your replies.
Quoted 32 lines · Michal Simek
Quoted 31 lines
Hi,
Quoted 28 lines · Tim Sander
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:
{
Quoted 6 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
[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 <[email protected]>
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 <[email protected]>
Tested-by Che-Liang Chiou <[email protected]>
Signed-off-by Simon Glass <[email protected]>
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>
Quoted 19 lines
Quoted 7 lines
Quoted 7 lines
Quoted 1 line
}
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.
Quoted 3 lines
Quoted 3 lines
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.
Quoted 6 lines
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.
board/xilinx/zynq/board.c +5 -0
index 485a5e4..559ef3d 100644
@@ -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) {
include/configs/zynq-common.h +0 -6
index 731e69b..8a63cd5 100644
@@ -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
Quoted 5 lines
Quoted 4 lines
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.
Quoted 3 lines
Quoted 3 lines
Means even uart node is not written in zynq-zed.dts serial configurations are static driver it self
as of now.

Quoted 6 lines

Quoted 2 lines
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.

Quoted 7 lines

Quoted 3 lines
Quoted 2 lines
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!

Signature · 1 line

Jagan.

Michal Simek

2014-03-27 13:17 UTC #7 lore raw

Quoted 11 lines

Quoted 6 lines
Quoted 2 lines
Quoted 1 line
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 at 0/ps7-ethernet at e000b000";
		serial0 = "/amba at 0/serial at e0001000";
		spi0 = "/amba at 0/ps7-qspi at e000d000";
	};

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

	cpus {

Signature · 14 lines

Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140327/c5ddb85e/attachment.pgp>

Tim Sander

author

2014-03-27 16:32 UTC #8 lore raw

Hi Michal
Am Donnerstag, 27. M?rz 2014, 14:17:41 schrieb Michal Simek:

Quoted 7 lines

Quoted 7 lines
Quoted 7 lines
Quoted 3 lines
Quoted 1 line
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

2014-03-27 16:46 UTC #9 lore raw

Hi Tim,

Quoted 4 lines · Tim Sander

Hi Michal
Am Donnerstag, 27. M?rz 2014, 14:17:41 schrieb Michal Simek:
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 1 line
Please check and may be you can try u-boot-dtb.elf.

Quoted 8 lines

Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 1 line
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

Tim Sander

author

2014-03-28 15:20 UTC #10 lore raw

Hi Michal

Quoted 12 lines · Tim Sander

Quoted 11 lines
Hi Michal
Am Donnerstag, 27. M?rz 2014, 14:17:41 schrieb Michal Simek:
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 3 lines
Quoted 1 line
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.

Quoted 5 lines

Quoted 3 lines
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 assume you mean static configuration a config with OF_CONTROL disabled. Ok, i have tried to boot that with bootgen. That does not work. Loading that into memory and booting it from within the debugger works though. In both cases with or without OF_CONTROL enabled.

Quoted 4 lines

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.

So my main focus is to test CONFIG_ARMV7_NONSEC to boot linux in normal mode. I wanted to test recent mainline with that. So focusing on u-boot SPL is to far off my targets. So i am happy with hardware debugger loadeing for the time beeing.

Getting back to CONFIG_ARMV7_NONSEC. This is unfortunatly not working with the Zynq. Currently the board switches to monitor mode but when the u-boot switches to normal mode it jumps to PC:0xc (LR:0x10) which seems like a data abort exeption or some other secure mode violation exception?
Is there a good way to find out what happened? I am currently stuck with this and my local FAE has also no idea. Attached is a patch which at least works until the return from the monitor mode.

Best regards
Tim

Michal Simek

2014-04-01 13:20 UTC #11 lore raw

Hi Tim,

Quoted 17 lines · Tim Sander

Hi Michal
Quoted 16 lines · Tim Sander
Quoted 14 lines
Hi Michal
Am Donnerstag, 27. M?rz 2014, 14:17:41 schrieb Michal Simek:
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 3 lines
Quoted 1 line
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?

Quoted 5 lines

Quoted 1 line
you can just use static u-boot configuration.
I assume you mean static configuration a config with OF_CONTROL disabled. Ok, i have tried to boot that with bootgen. That does not work. Loading that into memory and booting it from within the debugger works though. In both cases with or without OF_CONTROL enabled.

ok. I am not using bootgen that's why good that you have at least one config which is working. Feel free to use xilinx u-boot from github which is synchronized with mainline code.

Quoted 8 lines

Quoted 4 lines
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.
So my main focus is to test CONFIG_ARMV7_NONSEC to boot linux in normal mode. I wanted to test recent mainline with that. So focusing on u-boot SPL is to far off my targets. So i am happy with hardware debugger loadeing for the time beeing.

ok.

Quoted 7 lines

Getting back to CONFIG_ARMV7_NONSEC. This is unfortunatly not working with the Zynq. Currently the board switches to monitor mode but when the u-boot switches to normal mode it jumps to PC:0xc (LR:0x10) which seems like a data abort exeption or some other secure mode violation exception?
Is there a good way to find out what happened? I am currently stuck with this and my local FAE has also no idea. Attached is a patch which at least works until the return from the monitor mode.

yes I know. I have got an email from you some days ago but haven't answered it yet. I haven't played with it but at least I am aware about the code which is working on zynq.
Look at this repo
https://github.com/serngawy/OpenVirtualization
it is secure monitor code which does exactly what you have described switching from monitor mode to normal mode.

Albert could know more about proper u-boot behaviour how this should be handled.

Thanks,
Michal

Signature · 14 lines

Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140401/769deb2a/attachment.pgp>

Tim Sander

author

2014-04-03 09:27 UTC #12 lore raw

In reply to Tim Sander

Quoted 33 lines

Quoted 12 lines · Tim Sander
Quoted 11 lines
Hi Michal
Am Donnerstag, 27. M?rz 2014, 14:17:41 schrieb Michal Simek:
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 3 lines
Quoted 1 line
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.
Quoted 5 lines
Quoted 3 lines
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 assume you mean static configuration a config with OF_CONTROL disabled. Ok, i have tried to boot that with bootgen. That does not work. Loading that into memory and booting it from within the debugger works though. In both cases with or without OF_CONTROL enabled.
Quoted 4 lines
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.
So my main focus is to test CONFIG_ARMV7_NONSEC to boot linux in normal mode. I wanted to test recent mainline with that. So focusing on u-boot SPL is to far off my targets. So i am happy with hardware debugger loadeing for the time beeing.

Quoted 7 lines

Getting back to CONFIG_ARMV7_NONSEC. This is unfortunatly not working with the Zynq. Currently the board switches to monitor mode but when the u-boot switches to normal mode it jumps to PC:0xc (LR:0x10) which seems like a data abort exeption or some other secure mode violation exception? Is there a good way to find out what happened? I am currently stuck with this and my local FAE has also no idea. Attached is a patch which at least works until the return from the monitor mode.

Just a small information: I can boot a OF_CONTROL on a RevC Zynq Board but not Rev. D. So i can at least confirm that a board with RevC boots a mainline u-boot with OF_CONTROL disabled. I have no idea why the bootgen for the Rev. D board fails even if i have replaced the bitstream for the non eng. sample FPGA. But at least that also works when loaded with an HW-Debugger.

Best regards
Tim

Michal Simek

2014-04-03 09:28 UTC #13 lore raw

Quoted 41 lines · Tim Sander

Hi
Quoted 33 lines
Quoted 12 lines · Tim Sander
Quoted 11 lines
Hi Michal
Am Donnerstag, 27. M?rz 2014, 14:17:41 schrieb Michal Simek:
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 3 lines
Quoted 1 line
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.
Quoted 5 lines
Quoted 3 lines
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 assume you mean static configuration a config with OF_CONTROL disabled. Ok, i have tried to boot that with bootgen. That does not work. Loading that into memory and booting it from within the debugger works though. In both cases with or without OF_CONTROL enabled.
Quoted 4 lines
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.
So my main focus is to test CONFIG_ARMV7_NONSEC to boot linux in normal mode. I wanted to test recent mainline with that. So focusing on u-boot SPL is to far off my targets. So i am happy with hardware debugger loadeing for the time beeing.
Quoted 7 lines
Getting back to CONFIG_ARMV7_NONSEC. This is unfortunatly not working with the Zynq. Currently the board switches to monitor mode but when the u-boot switches to normal mode it jumps to PC:0xc (LR:0x10) which seems like a data abort exeption or some other secure mode violation exception? Is there a good way to find out what happened? I am currently stuck with this and my local FAE has also no idea. Attached is a patch which at least works until the return from the monitor mode.

Quoted 5 lines

Just a small information: I can boot a OF_CONTROL on a RevC Zynq Board but not Rev. D. So i can at least confirm that a board with RevC boots a mainline u-boot with OF_CONTROL disabled. I have no idea why the bootgen for the Rev. D board fails even if i have replaced the bitstream for the non eng. sample FPGA. But at least that also works when loaded with an HW-Debugger.

Interesting. Please use xilinx forums then can help you.