TE0720 GPIO design for 2014.4 Petalinux

[Fady]

Hi,
I'm using TRENZ TE-0720, the carrier board TE-0701, Petalinux 2014.4 and I'm trying to boot a PetaLinux Image on Hardware with SD Card, but it didn't work and the led 3 of TE-0720 was on.

Welcome to minicom 2.3

OPTIONS: I18n
Compiled on Dec  4 2009, 12:17:18.
Port /dev/ttyUSB1

                 Press CTRL-A Z for help on special keys                 
                                                                         
                                                                         
SoM: TE0720-02 SC REV:02                                                 
MAC: 00 04 A3 AC 16 65                                                   
                                           
                                           
U-Boot 2014.07 (Apr 22 2015 - 18:00:17)   
                                           
I2C:   ready                               
DRAM:  ECC disabled 1 GiB                 
MMC:   zynq_sdhci: 0                       
SF: Detected W25Q256 with page size 256 Bytes, erase size 4 KiB, total 32 MiB
*** Warning - bad CRC, using default environment

In:    serial
Out:   serial
Err:   serial
Net:   Gem.e000b000
Warning: failed to set MAC address

U-BOOT for TE0720-02-GPIO

Hit any key to stop autoboot:  0
Device: zynq_sdhci
Manufacturer ID: 41
OEM: 3432
Name: SD4GB
Tran Speed: 50000000
Rd Block Len: 512
SD version 3.0
High Capacity: Yes
Capacity: 3.7 GiB
Bus Width: 4-bit
reading image.ub
3115216 bytes read in 256 ms (11.6 MiB/s)
## Loading kernel from FIT Image at 01000000 ...
   Using 'conf@1' configuration
   Trying 'kernel@1' kernel subimage
     Description:  PetaLinux Kernel
     Type:         Kernel Image
     Compression:  gzip compressed
     Data Start:   0x010000f0
     Data Size:    3098899 Bytes = 3 MiB
     Architecture: ARM
     OS:           Linux
     Load Address: 0x00008000
     Entry Point:  0x00008000
     Hash algo:    crc32
     Hash value:   88606faa
   Verifying Hash Integrity ... crc32+ OK
## Loading fdt from FIT Image at 01000000 ...
   Using 'conf@1' configuration
   Trying 'fdt@1' fdt subimage
     Description:  Flattened Device Tree blob
     Type:         Flat Device Tree
     Compression:  uncompressed
     Data Start:   0x012f4ae8
     Data Size:    15019 Bytes = 14.7 KiB
     Architecture: ARM
     Hash algo:    crc32
     Hash value:   6c8ca5cd
   Verifying Hash Integrity ... crc32+ OK
   Booting using the fdt blob at 0x12f4ae8
   Uncompressing Kernel Image ... OK
   Loading Device Tree to 07ff9000, end 07fffaaa ... OK

Starting kernel ...




I have downloaded TE0720-02-GPIO.bsp  from http://www.trenz-electronic.de/download/d0/Trenz_Electronic/d1/TE0720-GigaZee/d2/Test_Designs/d3/TE0720-02-GPIO.html

Petalinux
##Create Petalinux project
$ petalinux-create -t project -s <path-to-bsp>
##Change into the directory of your PetaLinux project
$ cd TE0720-02-GPIO
##Import Hardware Description
petalinux-config --get-hw-description=hw-description/
##Build system image
$ petalinux-config
##configure Linux system
$ petalinux-build
##Generate the rootfs.cpio image
$ petalinux-config
$ petalinux-build
$ petalinux-package --image -c rootfs --format initramfs
##Generate Boot Image for Zynq
petalinux-package --boot --fsbl images/linux/zynq_fsbl.elf --u-boot
##Copy image files to SD card partitions
$ cp images/linux/BOOT.BIN /media/boot/
$ cp images/linux/image.ub /media/boot/
$ cp images/linux/rootfs.cpio /media/rootfs/
##Extract the file system
$ cd /media/rootfs
$ pax -rvf rootfs.cpio

But when i downloaded BOOT.BIN and image.ub from the same link, and copied them to the SD card, the Linux boots well. So what's wrong with the steps i made? I don't know what's the problem.

[Antti Lukats]

Hi

we will merge the GPIO project into main ref design distribution package and remove the old one soon. We sometimes see that the boot.bin generated with petalinux does not boot, not fully clear why, in such cases we build the boot.bin with bootgen directly.

http://www.trenz-electronic.de/de/download/d0/Trenz_Electronic/d1/TE0720-GigaZee/d2/reference_designs.html

there is ready to use .bat file that does generate boot.bin

[danwwright]

I just went through this same exercise with my new TE0720-02 SC REV:04 and the carrier board TE0703.  My steps are below:

##Create Petalinux project
$ petalinux-create -t project -s TE0720-02-refplnx.bsp
##Change into the directory of your PetaLinux project
$ cd cd TE0720-02-refplnx/
##Import Hardware Description
$ petalinux-config --get-hw-description=hw-description/
##at this point some configuration screen appears in the terminal and I simply exit with the defaults
##Build system image
$ petalinux-build
##Generate the rootfs.cpio image
$ petalinux-package --image -c rootfs --format initramfs
##Generate Boot Image for Zynq
$ petalinux-package --boot --fsbl images/linux/zynq_fsbl.elf --u-boott
##Copy image files to SD card partitions
$ cp images/linux/BOOT.BIN /media/boot/
$ cp images/linux/image.ub /media/boot/

Note I copied ONLY BOOT.BIN and image.ub to the SD card and it booted JUST FINE.  My question is: HOW?

Where is the device tree blob and the rootfs?  Do these get packed into image.ub somehow?

My objective is a successfully booting system that will mount a rootfs in the eMMC.  As a step along the way I initially extracted the ubuntu rootfs I intend to use into /media/rootfs/ and that's why I didn't bother with putting the Petalinux-supplied rootfs.  I was hoping that the kernel when it booted would mount that rootfs in that partition in the SD card.

But Linux DOES boot successfully but it's not mounting /media/rootfs.  Where is it finding the device tree blob and rootfs it's using and how do I set up a boot out of QSPI (containing BOOT.bin, the kernel and device tree) such that Linux mounts a rootfs in eMMC?

[Antti Lukats]

you have to read the linux howto's

the EASY way of booting with petalinux is with device tree embedded in image.ub file, hence you do not see anywhere.

it is possible to have it separately, as well of course

[danwwright]

Thanks.  After booting I see this:

root@TE0720-02-refplnx:~# ls -l /dev/m*
crw-r-----    1 root     kmem        1,   1 Jan  1 00:00 /dev/mem
brw-rw----    1 root     root      179,   0 Jan  1 00:00 /dev/mmcblk0
brw-rw----    1 root     root      179,   1 Jan  1 00:00 /dev/mmcblk0p1
brw-rw----    1 root     root      179,   2 Jan  1 00:00 /dev/mmcblk0p2
lrwxrwxrwx    1 root     root            12 Jan  1 00:00 /dev/mtab -> /proc/mounts
crw-rw----    2 root     root       90,   0 Jan  1 00:00 /dev/mtd0
crw-rw----    1 root     root       90,   1 Jan  1 00:00 /dev/mtd0ro
crw-rw----    2 root     root       90,   2 Jan  1 00:00 /dev/mtd1
crw-rw----    1 root     root       90,   3 Jan  1 00:00 /dev/mtd1ro
crw-rw----    2 root     root       90,   4 Jan  1 00:00 /dev/mtd2
crw-rw----    1 root     root       90,   5 Jan  1 00:00 /dev/mtd2ro
crw-rw----    2 root     root       90,   6 Jan  1 00:00 /dev/mtd3
crw-rw----    1 root     root       90,   7 Jan  1 00:00 /dev/mtd3ro
brw-rw----    1 root     root       31,   0 Jan  1 00:00 /dev/mtdblock0
brw-rw----    1 root     root       31,   1 Jan  1 00:00 /dev/mtdblock1
brw-rw----    1 root     root       31,   2 Jan  1 00:00 /dev/mtdblock2
brw-rw----    1 root     root       31,   3 Jan  1 00:00 /dev/mtdblock3

So the zynq ONLY knows about the SD card and QSPI flash.  It doesn't know about the eMMC.  Doesn't the eMMC appear in the device tree?

[danwwright]

Also I see that when I build a kernel and specify user-supplied bootargs:

console=ttyPS0,115200 rootfstype=ext4 root=/dev/mmcblk0p2 rw rootwait ip=:::::eth0:dhcp earlyprintk

which is telling the kernel to use a partition on the SD card as its rootfs it STILL instead mounting a ramdisk as its rootfs.  I check to make sure that the kernel really is seeing these bootargs like so:

root@TE0720-02-refplnx:~# cat /proc/cmdline
console=ttyPS0,115200 rootfstype=ext4 root=/dev/mmcblk0p2 rw rootwait ip=:::::eth0:dhcp earlyprintk

so the kernel IS seeing the bootargs telling it to mount a rootfs on the SD card.  How is that possible?

[Antti Lukats]

this seems like generic linux /petalinux question.

We do not experiment that much with bootargs for the kernel.

[danwwright]

Okay- but there is still the problem of the missing eMMC from the /dev directory.  Using the straight TE0720-02-refplnx build after it boots I see this:

root@TE0720-02-refplnx:~# ls -l /dev/m*
crw-r-----    1 root     kmem        1,   1 Jan  1 00:00 /dev/mem
brw-rw----    1 root     root      179,   0 Jan  1 00:00 /dev/mmcblk0
brw-rw----    1 root     root      179,   1 Jan  1 00:00 /dev/mmcblk0p1
brw-rw----    1 root     root      179,   2 Jan  1 00:00 /dev/mmcblk0p2
lrwxrwxrwx    1 root     root            12 Jan  1 00:00 /dev/mtab -> /proc/mounts
crw-rw----    2 root     root       90,   0 Jan  1 00:00 /dev/mtd0
crw-rw----    1 root     root       90,   1 Jan  1 00:00 /dev/mtd0ro
crw-rw----    2 root     root       90,   2 Jan  1 00:00 /dev/mtd1
crw-rw----    1 root     root       90,   3 Jan  1 00:00 /dev/mtd1ro
crw-rw----    2 root     root       90,   4 Jan  1 00:00 /dev/mtd2
crw-rw----    1 root     root       90,   5 Jan  1 00:00 /dev/mtd2ro
crw-rw----    2 root     root       90,   6 Jan  1 00:00 /dev/mtd3
crw-rw----    1 root     root       90,   7 Jan  1 00:00 /dev/mtd3ro
brw-rw----    1 root     root       31,   0 Jan  1 00:00 /dev/mtdblock0
brw-rw----    1 root     root       31,   1 Jan  1 00:00 /dev/mtdblock1
brw-rw----    1 root     root       31,   2 Jan  1 00:00 /dev/mtdblock2
brw-rw----    1 root     root       31,   3 Jan  1 00:00 /dev/mtdblock3

So the TE0720 (using SD boot in a TE0703 carrier board) ONLY knows about the SD card and QSPI flash.  It doesn't know about the eMMC.  Shouldn't there should be a /dev/mmcblk0 AND a /dev/mmcblk1 ?  Please take a look.  Was there some omission in the device tree?

[Antti Lukats]

Dear Dan,

the "GPIO" demo design was made as demo that has all IO used as GPIO, it was not made to have all features added in. The reason for not adding eMMC was probably consideration that the design should also work on modules that do not have eMMC installed.

This was not explained anywhere, sorry for that.

We are doing cleanup of our reference designs. eMMC would be added back as well, in some ref designs for sure.

[danwwright]

This was built from TE0720-02-refplnx.bsp rather than the GPIO bsp.  But looking at the device tree (in Petalinux /subsystems/linux/configs/device-tree/zynq-7000.dtsi) I do see this:

      sdhci0: sdhci@e0100000 {
         compatible = "arasan,sdhci-8.9a";
         status = "disabled";
         clock-names = "clk_xin", "clk_ahb";
         clocks = <&clkc 21>, <&clkc 32>;
         interrupt-parent = <&intc>;
         interrupts = <0 24 4>;
         reg = <0xe0100000 0x1000>;
      };

      sdhci1: sdhci@e0101000 {
         compatible = "arasan,sdhci-8.9a";
         status = "disabled";
         clock-names = "clk_xin", "clk_ahb";
         clocks = <&clkc 22>, <&clkc 33>;
         interrupt-parent = <&intc>;
         interrupts = <0 47 4>;
         reg = <0xe0101000 0x1000>;
      };

It looks like both are there.  But both specify: 'status = "disabled";'.  I'll try enabling them and see if they then show up in /dev.

[Antti Lukats]

nono

this is ALWAYS as this in that file, you should not edit that file

you can enable them in top DTS file, that is the correct way!!

[danwwright]

You're right- mods should be made to the DTS file.  However I spend many hours experimenting with different device-tree settings but I was unable to get the eMMC device to appear.  This is a big problem for us since in our board onto which the TE0720 mounts there is no SD card.  If you are successful in getting the eMMC to show up please let me know- even before rolling out a new release as this issue is holding us up.  Thanks!

[Antti Lukats]

Hi

I see, but first do you see eMMC in the u-boot ? this is first thing to test!

This test does not depend at all on devicetree..

[danwwright]

Yes the system boots fine out of eMMC- so we need not wonder if it's a hardware problem.  The knowledge that it's NOT a hardware issue is still no help at all in getting petalunix to mount a partition in eMMC.

It's a kernel/device tree issue and you should be able to see it immediately on a system there by just booting a straight petalunix build from your TE0720-02-refplnx.bsp.  It's Linux that can't see the device- that's the problem.

[danwwright]

Has there been any progress in making the eMMC visible in the petalinux built from your latest bsp?

[Thorsten Trenz]

Hi,
as soon as the Petalinux 2015.2 is available, we will make new bsp, taking care eMMC is visible in  Petalinux.

Best Regards
Thorsten Trenz

[danwwright]

Do we no when petalinux 2015.2 will be released?

[danwwright]

Ah- I now see that 2015.2 Petalinux is already released and is ready for download on the Xilinx site.

Can you tell me when your new bsp will be available?

[Thorsten Trenz]

Hi,
I cannot give you deadline. Its vacation time at the moment. We will work on it, as soon as time permits.

Best Regards
Thorsten Trenz

[Antti Lukats]

Has there been any progress in making the eMMC visible in the petalinux built from your latest bsp?

Dear Dan,

unfortunately we are failing to see the problem. To our best knowledge and understanding there is no problem with 2014.4 and emmc. I just tested it again, and I see no issue.

if you want to use eMMC with TE0720 then there is ONE change to be done:

1) enable SDIO1 in Vivado

NO OTHER CHANGES ANYWHERE!

And Linux will see emmc.

I did just do exactly this, and it is working as described.
Linux did see second mmc device: eMMC on TE0720

Of course you have to follow Xilinx ZYNQ concepts, but this something you have to-do ALWAYS.

https://wiki.trenz-electronic.de/display/PD/Zynq+Troubleshooting+Guide

[danwwright]

Will there be a .bsp file for the TE0720 that can be used with Petalinux 2015.2 anytime soon?

[danwwright]

Or BoardFiles for Vivado 2015.2 ?

[danwwright]

I'm currently attempting to us the 2014.4 board files and attempting to follow the instructions on your page:

https://wiki.trenz-electronic.de/display/TE0720/TE0720+Petalinux+Guide

Step-by-Step
Install Vivado Board Part support files by copying them into C:\Xilinx\Vivado\2014.2\data\
Unzip "IP Core archive" to some location on local drive   <------------------------------------------------ where to get this archive?
...

On many of your pages you refer to files by some English language description rather than actually specifying a file name- and this leads to a lot of ambiguity.

Even if the actual name of the file might change in the future still to actually give the present file name is still very valuable.  From it we can see the file type you're talking about and some hint about what a future name might look like.  Best of all of course would be to give a link where one could download the file being referred to.

I gather that there are both "board part files" (which I have found) and an "IP Core archive" which I have not.

Also can the 2014.4 board part files be used with Vivado 2015.2?

Thanks

[danwwright]

Proceeding in Vivado 2015.2 with just the board part files I specify my board TE0720-2-1CF in the Vivado Project Summary and so it appears that Vivado understands what board I have.  But then when I go into the configuration of the Zynq in the diagram view and look at the peripherals nothing is set (see screen capture).  Shouldn't Vivado know what peripherals the TE0720 has and which pins these are connected to?  Or does all of this need to be added manually in the dialog shown in the screen capture?

[Antti Lukats]

I'm currently attempting to us the 2014.4 board files and attempting to follow the instructions on your page:

https://wiki.trenz-electronic.de/display/TE0720/TE0720+Petalinux+Guide

Step-by-Step
Install Vivado Board Part support files by copying them into C:\Xilinx\Vivado\2014.2\data\
Unzip "IP Core archive" to some location on local drive   <------------------------------------------------ where to get this archive?
...

On many of your pages you refer to files by some English language description rather than actually specifying a file name- and this leads to a lot of ambiguity.

Even if the actual name of the file might change in the future still to actually give the present file name is still very valuable.  From it we can see the file type you're talking about and some hint about what a future name might look like.  Best of all of course would be to give a link where one could download the file being referred to.

I gather that there are both "board part files" (which I have found) and an "IP Core archive" which I have not.

Also can the 2014.4 board part files be used with Vivado 2015.2?

Thanks

2014.4 can be used in 2015.2

in the design archive there is bat file that DOES ALL project creation for you, you just run the .bat and it creates the project, only board part files need to be available before that

[danwwright]

Where is "the design archive"?  Does the archive have a name and can you tell me where this can be downloaded?

[Xiao Chen]

you can find  "the design archive"  on our download page. For the TE0720 ist here the link :

http://www.trenz-electronic.de/de/download/d0/Trenz_Electronic/d1/TE0720-GigaZee/d2/reference_designs/d3/2014.4.html

[danwwright]

Thanks Xiao

I had simply been trying to create a new Vivado project from scratch and specifying my model of TE0720 from the board_parts and then I created a board diagram and added a zynq to the diagram.  Looking at the zynq (by double clicking it in the diagram) I found that it did not know any of the board peripherals it had or what pins these might be connected to.  I was relying on the specification of the board to fill in all of those details but it apparently did not.  It seems that just specifying the board in the Vivado project create does absolutely nothing.

If I run the bat file in the TE0720-02 archive then I do then get a project with all of the peripherals specified in the zynq in the Vivado diagram.  Apparently some script in the archive was being run that set all of this up?  Any idea which tcl script this was?

Thanks,
Dan

[Antti Lukats]

when you create the new BD using board part files, AND let the AUTOMATION run then it would set some setting in the PS7 system. That is all the board flow does initially. There is a limited list of IP Cores that can be described in board part files, if they are then those interface can be attached to "default IP" for the given interface.

in 2015.2 there are many more features in board part files, that make them more valuable. Still the board part files can not contain information that is "customer specific", it is possible to define all pins by some generic name say from connector pin number, later it is possible to use those name eg J1_23 in the constraint files when assign pins to own peripherals.

[Xiao Chen]

Thanks Xiao

I had simply been trying to create a new Vivado project from scratch and specifying my model of TE0720 from the board_parts and then I created a board diagram and added a zynq to the diagram.  Looking at the zynq (by double clicking it in the diagram) I found that it did not know any of the board peripherals it had or what pins these might be connected to.  I was relying on the specification of the board to fill in all of those details but it apparently did not.  It seems that just specifying the board in the Vivado project create does absolutely nothing.

If I run the bat file in the TE0720-02 archive then I do then get a project with all of the peripherals specified in the zynq in the Vivado diagram.  Apparently some script in the archive was being run that set all of this up?  Any idea which tcl script this was?

Thanks,
Dan

To specify the zynq you need click "Run Block Automation" above the diagram screen.

It seems that, you have run the make_project.bat file. You are right, with this bat file some script will run, like make_project.tcl, set_project_name.tcl, set_board.tcl etc. and with this bat file a project can be created automatically.