Author Topic: TE0726 boot problem  (Read 208 times)

javier.reyes.g

  • Active Member
  • *
  • Posts: 19
TE0726 boot problem
« on: May 11, 2018, 07:24:18 PM »
I have followed the instructions for the test_board example for v2017.4, to build a linux image for the 726 board. I might be doing something wrong, because the kernel is not starting up.

Code: [Select]
0
reading image.ub
9524000 bytes read in 533 ms (17 MiB/s)
reading system.dtb
14073 bytes read in 14 ms (981.4 KiB/s)
## Loading kernel from FIT Image at 10000000 ...
   Using 'conf@1' configuration
   Trying 'kernel@0' kernel subimage                                             
     Description:  Linux Kernel                                                   
     Type:         Kernel Image                                                   
     Compression:  uncompressed                                                   
     Data Start:   0x100000d4                                                     
     Data Size:    3785328 Bytes = 3.6 MiB
     Architecture: ARM
     OS:           Linux
     Load Address: 0x00008000
     Entry Point:  0x00008000
     Hash algo:    sha1
     Hash value:   1ed0c0d412b7e16bb4a20f36d6cf27b9f3395aae
## Flattened Device Tree blob at 11800000
   Booting using the fdt blob at 0x11800000
   Loading Kernel Image ... OK
   Loading Device Tree to 07ff9000, end 07fff6f8 ... OK

Starting kernel ...

After this, there is no response... As I have mentioned several times, the instructions are not so clear, and they differ from the Xilinx documentation. I am not sure if what I am doing is correct for this board.

1. Created the Vivado project
2. Exported the HDF file including bitstream
3. Run init script and create petalinux project
4. Petalinx-config (in menu selecting boot image from Flash - Kernel and DTB from SD, and rootfs from INITRAMFS)
5. petalinux-config -c kernel - in menu enable the driver for USB-to-Ethernet
6. petalinux-config -c rootfs
7. petalinux-build
8. petalinux-package --boot --format BIN --fsbl ./images/linux/zynq_fsbl.elf --fpga ./images/linux/download.bit --u-boot
9. Copy image.ub, system.dtb to SD card (format FAT32) - Also tried copying everything in images/linux/ to SD, as I understand rootfs is loaded in RAM.
10. Program flash with BOOT.BIN in SDK menu (using the zynq_fsbl_flash.elf found in the prebuilt/software/m/ from the test_board project.
11. Connect serial monitor and power on board

I have tried also creating the vivado project by myself, and building the image as shown in Xilinx Docs, and several tutorials online. Always the same result.

What might be wrong?

Thanks in advance
« Last Edit: May 11, 2018, 07:29:13 PM by javier.reyes.g »

JH

  • Sr. Member
  • ****
  • Posts: 469
Re: TE0726 boot problem
« Reply #1 on: May 14, 2018, 08:26:11 AM »
Hi,
which assembly variant of TE0726 did you use? One of the M versions (512MB and dual core) , correct ?
Did you try out the prebuilt files (Boot.bin and image.ub)? Does this work?

We provide also a petalinux template, did you try out this?
  • test_board/os/petalinux
there is a init script (init_config.sh) to change some absolute path from your location. You must run this before you import the hdf
Changes  we have done in this project are described here:br
John

javier.reyes.g

  • Active Member
  • *
  • Posts: 19
Re: TE0726 boot problem
« Reply #2 on: May 14, 2018, 02:42:04 PM »
Hi

Thanks for the reply

I use the TE0726-02M.

I used the petalinux template, and the init_config.sh script correctly.

If I use the prebuilt image of the test_board project (image.ub), does the SD card only requires one partition? Only the image.ub needs to be copied? Should it be FAT32 right? And for the BOOT.BIN, it also need to be programmed with the SDK menu "Program Flash" using the zynq_fsbl_flash.elf?

Thanks for the guidance

JH

  • Sr. Member
  • ****
  • Posts: 469
Re: TE0726 boot problem
« Reply #3 on: May 14, 2018, 03:02:48 PM »
Hi,
instructions: https://wiki.trenz-electronic.de/display/PD/TE0726+Test+Board#TE0726TestBoard-Launch

One partition is enough, for this example rootfs is RAM Disk, included into image.ub.
You can also use SDK, since Vivado 2017.3, you must use this special FSBL on Viivado/SDK GUI. Older version works without FSBL.

br
John

javier.reyes.g

  • Active Member
  • *
  • Posts: 19
Re: TE0726 boot problem
« Reply #4 on: May 14, 2018, 03:25:17 PM »
Hi JH

I just tried with the image.ub already built in test_board, (programming with the TCL command), and the boot shows:

Code: [Select]
In:    serial@e0001000
Out:   serial@e0001000
Err:   serial@e0001000
Hit any key to stop autoboot:  0
** Bad device mmc 1 **
Zynq>

I asume that the prompt I am getting is from the U-boot, so I understand is the kernel that is not booting.

Thanks for any comment on this

JH

  • Sr. Member
  • ****
  • Posts: 469
Re: TE0726 boot problem
« Reply #5 on: May 14, 2018, 03:35:24 PM »
Hi,

orginal image.ub and boot.bin? If you generate all files with our scripts, they will be overwrite original files.

Did you erase the flash completely? Uboot environment can be stored on flash, this will be overwrite default setup. Did you try out to overwrite uboot enviroment at some previous moment?

br
John


javier.reyes.g

  • Active Member
  • *
  • Posts: 19
Re: TE0726 boot problem
« Reply #6 on: May 14, 2018, 03:51:45 PM »
Hi

I run TE scripts only for Vivado project creation (including hardware build and export). Did not run petalinux commands so that image is not overwritten.

I programmed with the TCL command, and also with the SDK GUI menu (using the BOOT.BIN in prebuilt/boot_images/m/u-boot/ and the FSBL in prebuilt/software/m/zynq_fsbl_flash.elf).

If I program the BOOT.BIN in prebult/boot_images/m/hello_te726/ the application works normally (prints the message prompt in a loop).

I am including the option to verify blank before programming.

I tried before some other tutorials, including https://eewiki.net/display/Motley/Getting+Started+with+the+ZynqBerry and at the final part, there are some env commands that I tried, but also there was never a successful boot. I assume the environment values given then were deleted as I am now trying the BOOT.BIN directly from the test_board project you provide, and the image.ub directly as well. The memory is being erased, so nothing done before should not have any relation.

Regards

JH

  • Sr. Member
  • ****
  • Posts: 469
Re: TE0726 boot problem
« Reply #7 on: May 14, 2018, 04:23:21 PM »
Hi,

i used the same file and get:
Code: [Select]
U-Boot 2017.01 (Jan 29 2018 - 13:17:37 +0100)

Board: Xilinx Zynq
I2C:   ready
DRAM:  ECC disabled 256 MiB
MMC:   sdhci@e0101000: 0 (SD)
SF: Detected s25fl128s_64k with page size 256 Bytes, erase size 64 KiB, total 16                                      MiB
*** Warning - bad CRC, using default environment

In:    serial
Out:   serial
Err:   serial
U-BOOT for petalinux

Hit any key to stop autoboot:  0
Device: sdhci@e0101000
Manufacturer ID: 3
OEM: 5344
Name: SS08G
Tran Speed: 50000000
Rd Block Len: 512
SD version 3.0
High Capacity: Yes
Capacity: 7.4 GiB
Bus Width: 4-bit
Erase Group Size: 512 Bytes
reading image.ub
...

SD is mmc 0 and in your case uboot try toget access to mmc 1.

There was a similar problem, by other user, as he try out the same link like you has posted:
There was the problem with the device tree entry.
So at the moment I think you has the same problem.
Can you try out to clear flash only with Vivado, see attachment picture.
After erase, it should not boot, please try out before you configure with programming.


br
John









javier.reyes.g

  • Active Member
  • *
  • Posts: 19
Re: TE0726 boot problem
« Reply #8 on: May 14, 2018, 04:47:40 PM »
Hi JH

I checked the thread and links, and make sense, I could have changed the env variables before. I made the change (delete the previously saved env values with run eraseenv in the u-boot promt). Now the boot seems to have changed, but stills something fails. I know that might be annoying but I really have been trying a lot, and not even the prebuilt project seems clear enough.

Code: [Select]
sdhci@e0101000: 0 (SD)
SF: Detected s25fl128s_64k with page size 256 Bytes, erase size 64 KiB, total 16 MiB
*** Warning - bad CRC, using default environment

In:    serial
Out:   serial
Err:   serial
U-BOOT for petalinux                                                                                                                                   
                                                                                                                                                       
Hit any key to stop autoboot:  0                                                                                                                       
Device: sdhci@e0101000                                                                                                                                 
Manufacturer ID: 9c                                                                                                                                     
OEM: 534f
Name: USD00
Tran Speed: 50000000
Rd Block Len: 512
SD version 3.0
High Capacity: Yes
Capacity: 15 GiB
Bus Width: 4-bit
Erase Group Size: 512 Bytes
reading image.ub
9559592 bytes read in 677 ms (13.5 MiB/s)
## Loading kernel from FIT Image at 10000000 ...
   Using 'conf@1' configuration
   Verifying Hash Integrity ... OK
   Trying 'kernel@0' kernel subimage
     Description:  Linux Kernel
     Type:         Kernel Image
     Compression:  uncompressed
     Data Start:   0x100000d4
     Data Size:    3788176 Bytes = 3.6 MiB
     Architecture: ARM
     OS:           Linux
     Load Address: 0x00008000
     Entry Point:  0x00008000
     Hash algo:    sha1
     Hash value:   36837c0bc22e1f60c993754bd384b6b751245fd3
   Verifying Hash Integrity ... sha1+ OK
## Loading ramdisk from FIT Image at 10000000 ...
   Using 'conf@1' configuration
   Trying 'ramdisk@0' ramdisk subimage
     Description:  ramdisk
     Type:         RAMDisk Image
     Compression:  uncompressed
     Data Start:   0x103a086c
     Data Size:    5755338 Bytes = 5.5 MiB
     Architecture: ARM
     OS:           Linux
     Load Address: unavailable
     Entry Point:  unavailable
     Hash algo:    sha1
     Hash value:   25e4494972caf5f9fb76a10f8a65024d261eec80
   Verifying Hash Integrity ... sha1+ OK
## Loading fdt from FIT Image at 10000000 ...
   Using 'conf@1' configuration
   Trying 'fdt@0' fdt subimage
     Description:  Flattened Device Tree blob
     Type:         Flat Device Tree
     Compression:  uncompressed
     Data Start:   0x1039cf58
     Data Size:    14435 Bytes = 14.1 KiB
     Architecture: ARM
     Hash algo:    sha1
     Hash value:   9836eb3d798b5a3f02e8a6d0cd809bf27e15edd0
   Verifying Hash Integrity ... sha1+ OK
   Booting using the fdt blob at 0x1039cf58
   Loading Kernel Image ... OK
   Loading Ramdisk to 07a82000, end 07fff1ca ...

As far as I can understand, the previous problem was solved, as in the link for the zedboard they mentioned
Quote
My first guess is that your environment is being read from non-volatile memory on your PicoZed, instead of using the default values you have compiled into the u-boot executable.  I've been bitten by this a couple of times when pulling out a board I haven't used for a while, and I forgot that I saved the environment variables for whatever I was doing in the past.
To elaborate, you can save environment variables in QSPI, and u-boot looks there first before using the default values compiled into the object code.  If you don't see a message indicating something like "CRC error, using default environment" when u-boot begins, it is reading the env vars from QSPI.   The fix is to simply erase the env sectors from QSPI from the u-boot command line with "run eraseenv".  Or you can force it to use the default environment from the command line as well, with "env default -a".

Now, the boot process seems to freeze at loading the ram disk in memory. I asume it would be easier to load a rootfs from a partition in the SD, but I haven't been able to make it work in any way, so it would be logical to solve this issue first and then try to improve the process modifying the hardware, or building a modified version of the linux kernel.

Regards

JH

  • Sr. Member
  • ****
  • Posts: 469
Re: TE0726 boot problem
« Reply #9 on: May 14, 2018, 05:04:54 PM »
Hi,
can you tell me the serial number of your TE0726?

It's also possible to send this number to support@trenz-electronic.de
I will check one time the assembly option.

The log seems to be the same, here is my:
Code: [Select]
Hit any key to stop autoboot:  0
Device: sdhci@e0101000
Manufacturer ID: 3
OEM: 5344
Name: SS08G
Tran Speed: 50000000
Rd Block Len: 512
SD version 3.0
High Capacity: Yes
Capacity: 7.4 GiB
Bus Width: 4-bit
Erase Group Size: 512 Bytes
reading image.ub
9559592 bytes read in 676 ms (13.5 MiB/s)
## Loading kernel from FIT Image at 10000000 ...
   Using 'conf@1' configuration
   Verifying Hash Integrity ... OK
   Trying 'kernel@0' kernel subimage
     Description:  Linux Kernel
     Type:         Kernel Image
     Compression:  uncompressed
     Data Start:   0x100000d4
     Data Size:    3788176 Bytes = 3.6 MiB
     Architecture: ARM
     OS:           Linux
     Load Address: 0x00008000
     Entry Point:  0x00008000
     Hash algo:    sha1
     Hash value:   36837c0bc22e1f60c993754bd384b6b751245fd3
   Verifying Hash Integrity ... sha1+ OK
## Loading ramdisk from FIT Image at 10000000 ...
   Using 'conf@1' configuration
   Trying 'ramdisk@0' ramdisk subimage
     Description:  ramdisk
     Type:         RAMDisk Image
     Compression:  uncompressed
     Data Start:   0x103a086c
     Data Size:    5755338 Bytes = 5.5 MiB
     Architecture: ARM
     OS:           Linux
     Load Address: unavailable
     Entry Point:  unavailable
     Hash algo:    sha1
     Hash value:   25e4494972caf5f9fb76a10f8a65024d261eec80
   Verifying Hash Integrity ... sha1+ OK
## Loading fdt from FIT Image at 10000000 ...
   Using 'conf@1' configuration
   Trying 'fdt@0' fdt subimage
     Description:  Flattened Device Tree blob
     Type:         Flat Device Tree
     Compression:  uncompressed
     Data Start:   0x1039cf58
     Data Size:    14435 Bytes = 14.1 KiB
     Architecture: ARM
     Hash algo:    sha1
     Hash value:   9836eb3d798b5a3f02e8a6d0cd809bf27e15edd0
   Verifying Hash Integrity ... sha1+ OK
   Booting using the fdt blob at 0x1039cf58
   Loading Kernel Image ... OK
   Loading Ramdisk to 07a82000, end 07fff1ca ... OK
   Loading Device Tree to 07a7b000, end 07a81862 ... OK

Starting kernel ...


but my starts, strange...


br
John

javier.reyes.g

  • Active Member
  • *
  • Posts: 19
Re: TE0726 boot problem
« Reply #10 on: May 14, 2018, 05:24:39 PM »
Hi JH

Thanks for your follow-up on the matter.

The board serial number is 462342. The model is TE0726-02 (M).

What I can see from the two logs, is that the device tree is not being loaded into memory. There is currently not system.dts file on the SD card (as there is no device tree file in the test_board project). Is the device tree included in image.ub kernel somehow? I will retry the building process to give it a try meanwhile.

Regards

JH

  • Sr. Member
  • ****
  • Posts: 469
Re: TE0726 boot problem
« Reply #11 on: May 15, 2018, 09:14:41 AM »
Hi,

this is a TE0726-02 --> without M
You has only 128MB DDR3, see page 7:
PS: Default image.ub includes kernel, rootsf and devicetree. You can change everything on petalinux config.

br
John

javier.reyes.g

  • Active Member
  • *
  • Posts: 19
Re: TE0726 boot problem
« Reply #12 on: May 15, 2018, 01:48:24 PM »
Hi

What a dumb problem... The link that was referred to me when the board was handed, said https://shop.trenz-electronic.de/de/TE0726-03M-ZynqBerry-Zynq-7010-in-Raspberry-Pi-Formfaktor?c=358, which is in fact the model with 512MB. Just FYI, when you list all available models, there is room to confusion, as the only model with 128MB is the model R, and is show disassembled. We all believed that we had a model M.

In that case, what model should I select from the board_files.csv?

1   ,te0726-01          ,xc7z010clg225-1   ,trenz.biz:te0726_01:part0:1.0   ,01         ,qspi_single  ,s25fl128s-3.3v-qspi-x4-single|SPIx4|16 ,PCB:1  |B:1|I:1|P:1|R:128MB
2   ,te0726-03r         ,xc7z010clg225-1   ,trenz.biz:te0726_r:part0:2.1    ,r          ,qspi_single  ,s25fl128s-3.3v-qspi-x4-single|SPIx4|16 ,PCB:2.3|B:1|I:1|P:2|R:128MB_L

And also, if I where to config and build without the scripts, how (or where) should I define the memory size?

Thanks for the support

Regards

JH

  • Sr. Member
  • ****
  • Posts: 469
Re: TE0726 boot problem
« Reply #13 on: May 15, 2018, 02:22:10 PM »
Hi,

you must use TE0726-03R --> ID 2
I know, sometimes the product name will be changed, but product is nearly the same.
I've some basic documentation:
And also add a Wiki description, to make this a little bit clearer:It's not perfect yet, but i try to make it a little bit clearer  from time to time.
One design project for all variants instead of single project for every assembly variant + revision is the only way to handle all this boards at the moment. There are to much variants to support one or two design updates for newer vivado versions per year, if i generate a single project for all. List of currently available design, see:To your memory question. Memory is set on PS IP  --> We provide default setting with the board part files.
After export of the HDF from the design, SDK or Petalinux project can use the information to set correct size. Size can be also reduced on petalinux config( in case you need a part for other purpose).
br
John

javier.reyes.g

  • Active Member
  • *
  • Posts: 19
Re: TE0726 boot problem
« Reply #14 on: May 15, 2018, 03:20:52 PM »
Hi

It looks like a nightmare... I just tried the prebuilt image (by zero dowloaded the test_board project, created the project with the scripts, launched SDK with the TE TCL command, programmed flash with prebuilt/boot_images/r/BOOT.BIN and the special FSBL in prebuilt/software/r/zynq_fsbl_flash.elf, copied the prebuilt/os/r/image.ub to the SD card, and now this happening at boot:

Code: [Select]
0
Device: sdhci@e0101000
Manufacturer ID: 9c
OEM: 534f
Name: USD00
Tran Speed: 50000000
Rd Block Len: 512
SD version 3.0                                                                   
High Capacity: Yes                                                               
Capacity: 15 GiB                                                                 
Bus Width: 4-bit                                                                 
Erase Group Size: 512 Bytes                                                       
reading image.ub
9559496 bytes read in 679 ms (13.4 MiB/s)
## Loading kernel from FIT Image at 10000000 ...
   Using 'conf@1' configuration
   Verifying Hash Integrity ... OK
   Trying 'kernel@0' kernel subimage
     Description:  Linux Kernel
     Type:         Kernel Image
     Compression:  uncompressed
     Data Start:   0x100000d4
     Data Size:    3788176 Bytes = 3.6 MiB
     Architecture: ARM
     OS:           Linux
     Load Address: 0x00008000
     Entry Point:  0x00008000
     Hash algo:    sha1
     Hash value:   c1514747fb4833af6a63f18f4cd2debf58255f62
   Verifying Hash Integrity ... sha1+ OK
## Loading ramdisk from FIT Image at 10000000 ...
   Using 'conf@1' configuration
   Trying 'ramdisk@0' ramdisk subimage
     Description:  ramdisk
     Type:         RAMDisk Image
     Compression:  uncompressed
     Data Start:   0x103a086c
     Data Size:    5755241 Bytes = 5.5 MiB
     Architecture: ARM
     OS:           Linux
     Load Address: unavailable
     Entry Point:  unavailable
     Hash algo:    sha1
     Hash value:   a283296efdb5a1a320bc315e1416a1626b8395bf
   Verifying Hash Integrity ... sha1+ OK
## Loading fdt from FIT Image at 10000000 ...
   Using 'conf@1' configuration
   Trying 'fdt@0' fdt subimage
     Description:  Flattened Device Tree blob
     Type:         Flat Device Tree
     Compression:  uncompressed
     Data Start:   0x1039cf58
     Data Size:    14435 Bytes = 14.1 KiB
     Architecture: ARM
     Hash algo:    sha1
     Hash value:   82fa3f697766b4849d08daf8df89981ea35cdd68
   Verifying Hash Integrity ... sha1+ OK
   Booting using the fdt blob at 0x1039cf58
   Loading Kernel Image ... OK
   Loading Ramdisk to 06dc6000, end 07343169 ... OK
ERROR: image is not a fdt - must RESET the board to recover.
FDT creation failed! hanging...### ERROR ### Please RESET the board ###

Any idea what is happening?

Thanks in advance

Regards

JH

  • Sr. Member
  • ****
  • Posts: 469
Re: TE0726 boot problem
« Reply #15 on: May 15, 2018, 03:26:41 PM »
Hi,

maybe this is may mistake. I've no TE0726 with 128MB on place. I found:
So I didn't change correctly all petalinux settings for smaller RAM size. I will check sources.

br
John

JH

  • Sr. Member
  • ****
  • Posts: 469
Re: TE0726 boot problem
« Reply #16 on: May 16, 2018, 09:45:02 AM »
Hi,
it was my mistake. Netboot offset is not set automatically on HDF import. I will regenerate the files and will upload new version.
I let you know, when it's finished.
Or you generate petalinux by yourself

br
John

javier.reyes.g

  • Active Member
  • *
  • Posts: 19
Re: TE0726 boot problem
« Reply #17 on: May 16, 2018, 04:32:50 PM »
Hi JH

I will try to build it my myself, following the material available. I still find some unclear things...

1. If I want to set the presets of a Vivado project (following as an example this guide https://eewiki.net/display/Motley/Getting+Started+with+the+ZynqBerry, which is the most clear procedure I have found), the TCL file provided there containing the defaults presets for the Zynqberry 726-03M (ZynqBerryPSDefault.tcl) would still be applicable? Of course, modifying the memory size:

Before
Code: [Select]
CONFIG.PCW_DDR_RAM_HIGHADDR {0x1FFFFFFF}  \

After
Code: [Select]
CONFIG.PCW_DDR_RAM_HIGHADDR {0x07FFFFFF}  \

If not, is there any similar file provided by Trenz? Or the only way is to use the reference design project and scripts (which IMHO is more confuse to use and do not facilitate the comparison to the workflow described by Xilinx)?

2. To configure the memory size in petalinux, I see in the menu:

Code: [Select]
Subsystem AUTO Hardware Settings
    Memory Settings
        (0x0) System memory base address
        (0x8000000) System memory size (NEW)
        (0x0) kernel base address
        (0x400000) u-boot text base address offset to memory base address

Should the 2nd element (System memory size) be changed to 0x07FFFFFF for 128MB?
The 4th also should be adjusted? I have looked around in internet but I cannot find anything related.

3. There is nothing mentioned in the instructions of the reference design, but it is shown in the above mentioned tutorial: In petalinux-config menu:

Code: [Select]
Advanced bootable images storage Settings
    boot image settings
    u-boot env partition settings
    kernel image settings
    jffs2 rootfs image settings
    dtb image settings

As far as I understand, the boot image settings need to be changed (by default shows image storage media as primary SD, but should be primary flash, right?).

Other configs that are not mentioned:

jffs2 rootfs image settings - This is by default at primary flash. Should the right config be different? The names (partition and file) are also specified as jffs2 and rootfs.jffs2 respectively. Is the rootfs generated with this config?

dtb image settings - This is by default from boot image. What I have seen is that the device tree is compiled by petalinux, and that for the use of the Ethernet interface (usb-to-ethernet hub) it is necessary to add some lines to the system-top.dtsi file before building the image. Should this item be changed to read the device tree from SD, and copy the system.dtb generated by petalinux to the SD along with the image.ub?

3. The petalinux-config menu shows:

Code: [Select]
u-boot Configuration
    (zynq_zc702_config) u-boot config target
     (0x10000000) netboot offset

On this part is that you mention I should set the memory size, which is unclear... Should I set this value to the max size of the address for 128MB (0x07FFFFFF)? If so, what relation is there between this and the memory size in the Subsystem Auto Hardware Settings?

Also, this u-boot config target is showing a zc702_config. Is this a correct setting? I thought the ZC702 was an evaluation board from Xilinx using the 7Z020 device, which is quite different to the 7Z010 that the zynqberry 726 uses.

4. On the same config menu says:

Code: [Select]
Image Packaging Configuration
    Root filesystem type (INITRAMFS)
    (image.ub) name for bootable kernel image
    (0x1000) DTB padding size

Is it necessary here to let the default config? I would think it needs to match the rootfs selected before (JFFS2). Or is the right one the INITRAMFS? If I were to use a specific rootfs, as explained in the guide I linked above (debian or ubuntu), Should the DTB be modified somehow?

This is the type of information that should be clarified in the documentation of the reference design, as the default options do not work, and this are selectable according to the hardware (Trenz side).

I appreciate any comment on this questions, as it might seem that are too many. I do not intend to make other to do my work, but simply obtain help that I cannot find anywhere.

Regards

JH

  • Sr. Member
  • ****
  • Posts: 469
Re: TE0726 boot problem
« Reply #18 on: May 17, 2018, 10:18:58 AM »
Hi,
i've upload new version.My additional changes for 128MB variant, this must be done manually after HDF import, if you use the template for all variants:to your questions:

1. we provide board part files (included into the reference design), you can export this tcl with Vivado after you has run board automation for IP. So you can also export your additional PS changes.
2.memory size will be set from HDF import if you create a new project, you can reduce manually, if you need space for other purpose.

3. https://wiki.trenz-electronic.de/display/PD/TE0726+Test+Board#TE0726TestBoard-Programmingthis small package can primary only boot from QSPI, but secondary boot, like with Uboot can us SD to load linux for example

3.(net boot + zc702 ;-)) this will be not reduced automatically, so for very small RAM you must do manually, i used half size (https://wiki.trenz-electronic.de/display/PD/TE0726+Test+Board#TE0726TestBoard-Config)See also https://www.xilinx.com/support/answers/59853.htmlXilinx create default config always from here evaluation boards, over HDF import this will be overwrite. Unfortunately not always all correctly. And zc702 is only the name from the template, you find sources on xilinx git.I've add all changes after HDF import on: https://wiki.trenz-electronic.de/display/PD/TE0726+Test+Board#TE0726TestBoard-SoftwareDesign-PetaLinuxSometimes this will changed during Vivado/petalinux version, but the basics are the same.

4. depending what you want to do, we didn't changed on our example


So summary:Net boot offset was my mistake for this small variant (I've no 128MB on place, so I can't test). I've documented all changes i've done after create project with the exported HDF on:
PS: Some documents links:For links with "xilinx20xx_x" you should always use the same UG like your installed vivado/petalinux version.

br
John

javier.reyes.g

  • Active Member
  • *
  • Posts: 19
Re: TE0726 boot problem
« Reply #19 on: May 24, 2018, 01:29:26 PM »
Hi JH

Sorry to bother again... The recent build that you edited and uploaded with the change for the 128MB variant, I have tried it today and there seems to be a problem with the scripts:

Code: [Select]
javier@ubuntu:~/Downloads/test_board$ source /opt/Xilinx/Vivado/2017.4/settings64.sh
javier@ubuntu:~/Downloads/test_board$ chmod +x _create_linux_setup.sh
javier@ubuntu:~/Downloads/test_board$ ./_create_linux_setup.sh
------------------------Set design paths----------------------------
-- Run Design with: _create_linux_setup.sh
-- Use Design Path: /home/javier/Downloads/test_board
--------------------------------------------------------------------
------------------------TE Reference Design-------------------------
--------------------------------------------------------------------
-- (c)  Go to CMD-File Generation (Manual setup)                   
-- (d)  Go to Documentation (Web Documentation)                     
-- (x)  Exit Batch (nothing is done!)                               
-- (0)  Create minimum setup of CMD-Files and exit Batch           
-- (1)  Create maximum setup of CMD-Files and exit Batch           
----                                                               
 Select (ex.:'0' for min setup):
0
---------------------------Minimal Setup----------------------------
--- 1. Open design_basic_settings.sh with text editor
--- 2. Set Xilinx Installation path, default: XILDIR=/opt/Xilinx/
--- 3. Set the Board Part you bought, example: PARTNUMBER=te0726-3m
--- For available names see: ./board_files/TExxxx_board_files.csv
--- 4. Save design_basic_settings.sh
--- 5. To create vivado project, execute: ./vivado_create_project_guimode.sh
--- Use Trenz Electronic Wiki for more information:
--- https://wiki.trenz-electronic.de/display/PD/Project+Delivery
--------------------------------------------------------------------
Press [Enter] key to continue...
javier@ubuntu:~/Downloads/test_board$ vim design_basic_settings.sh
javier@ubuntu:~/Downloads/test_board$ chmod +x vivado_create_project_guimode.sh
javier@ubuntu:~/Downloads/test_board$ chmod +x vivado_open_existing_project_guimode.sh
javier@ubuntu:~/Downloads/test_board$ ./vivado_create_project_guimode.sh
------------------------Set design paths----------------------------
-- Run Design with: vivado_create_project_guimode.sh
-- Use Design Path: /home/javier/Downloads/test_board
---------------------Load basic design settings---------------------
--------------------------------------------------------------------
------------------Set Xilinx environment variables------------------
-- Use Xilinx Version: 2017.4 --
--Info: Configure Xilinx Vivado Settings --
-- Info: /opt/xilinx//Vivado/2017.4/.settings64-Vivado.sh not found --
--Info: Configure Xilinx SDK Settings --
-- Info: /opt/xilinx//SDK/2017.4/.settings64-SDK_Core_Tools.sh not found --
--Info: Configure Xilinx LAbTools Settings --
-- Info: /opt/xilinx//Vivado_Lab/2017.4/settings64.sh not found --
--------------------------------------------------------------------
-- Error: Need Vivado to run. --
---------------------------Error occurs-----------------------------
--------------------------------------------------------------------
javier@ubuntu:~/Downloads/test_board$ vim design_basic_settings.sh
javier@ubuntu:~/Downloads/test_board$

Checking the script vivado_create_design.sh, I have seen that it checks this:

Code: [Select]
source $bashfile_path/design_basic_settings.sh
echo --------------------------------------------------------------------
echo ------------------Set Xilinx environment variables------------------
VIVADO_XSETTINGS=${XILDIR}/Vivado/${VIVADO_VERSION}/.settings64-Vivado.sh
SDK_XSETTINGS=${XILDIR}/SDK/${VIVADO_VERSION}/.settings64-SDK_Core_Tools.sh
LABTOOL_XSETTINGS=${XILDIR}/Vivado_Lab/${VIVADO_VERSION}/settings64.sh
if [ "${ENABLE_SDSOC}" == "" ]; then ENABLE_SDSOC=0; fi
if [ ${ENABLE_SDSOC} == 1 ]; then
  echo --Info: SDSOC use Vivado and SDK from SDx installation --
  SDSOC_XSETTINGS=${XILDIR}/SDx/${VIVADO_VERSION}/settings64.sh
  VIVADO_XSETTINGS=${XILDIR}/Vivado/${VIVADO_VERSION}/settings64.sh
  SDK_XSETTINGS=${XILDIR}/SDK/${VIVADO_VERSION}/settings64.sh
fi

The conditional looking for ENABLE_SDSOC == "" is causing that it never finds the right path for the settings (In this case, /opt/Xilinx/Vivado/2017.4/settings.sh), and tries to read a non-existing file (/opt/Xilinx/Vivado/2017.4/.settings64-vivado.sh). Is it perhaps an error during the update?

Thanks in advance

Regards

JH

  • Sr. Member
  • ****
  • Posts: 469
Re: TE0726 boot problem
« Reply #20 on: May 24, 2018, 01:58:47 PM »
Hi,
since 2017.4 Xilinx SDSoC use same default install folder for included Vivado than normal Vivado installation.
On Windows they have included SDSoC settings on normal".../Vivado/{Vivado_version}/settings64.sh". This loads normally  also ".settings64-Vivado.sh" and  ".settings64-SDK_Core_Tools.sh" and unfortunately in the new version also all SDSoC environments. So i've replaced this  because other Eclipse plugin SDSoC SDK is used with SDSoC settings instead of normal SDK.

I thought on Linux is the same (I didn't try out, because I've only win os.).

Replace:
VIVADO_XSETTINGS=${XILDIR}/Vivado/${VIVADO_VERSION}/.settings64-Vivado.sh with
VIVADO_XSETTINGS=${XILDIR}/Vivado/${VIVADO_VERSION}/settings.sh
The same for SDK.


Can you tell me which settings...sh do you see on your Vivado installation path.
Can you send me this information to "support@trenz-electronic.de", also add this *.sh file on the email. I will check, if I can generate a general bugfix for this problem.

br
John