Petalinux 2014.2 support for TE0720

[Antti Lukats]

Hi

we will soon release Petalinux BSP for TE0720 and also for TE0710 and TE0712 boards.

Currently we have those in testing, all functions checked work as expected.

NOTE: we will not support petalinux earlier as 2014.2, and as soon as 2014.3 is released we keep 2014.3 as base version (not 2014.2), this is due to the differences in Vivado Board Part (Custom Board support) file structures.

[indar]

Hi,

That's a good news indeed. I also noticed your new entry on your TE0720 wiki about Petalinux (although it's still empty atm). Beside the BSP, I hope you also give a hint/tutorial of how to create and use custom IP and its driver in the Petalinux environment. So far I get stuck on the driver produced by Vivado HLS to be used in my Petalinux. I cannot use that driver and its functionality right away although I can access my custom module using simple UIO mechanism within the Petalinux. But when I create a standalone app, the driver works flawlessly.

best,
Indar

[amb_kosh]

Hello,

do you provide a download for the BSP-file, either 2014.1 or 2014.2?

regards,

Jörg

[Antti Lukats]

Hi

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

I did move the developer snapshot archives to public folder that should become visible under public downloads.
But as the files are larger, maybe they will be moved to FTP or somewhere else.

more official release comes soon too, we hope to get it out within 2 weeks.

2014.2 is supported as long as 2014.3 is released, then we update 2014.3 and keep it as base release version.

Xilinx does not officially support "board part" (Custom Board) flow in 2014.2 so there are lots of things that should work but do not. They are not showstoppers but pita and troublesome. For this release we most likely will drop 2014.2 as soon as 2014.3 is out.

[Rolf Kary-Ehlers]

Hi Oleksandr

we are using "buildroot" to build our Linux Image and the toolchain for the TE0720 on the TE0701 Carrier Board.
In Buildroot we have chosen the linux-te-3.9 from the Trenz-Electronic github, the te_zynq_defconfig and the TE0720-01-2IF devicetree source file.
We are using U-Boot as Bootloader and the U-Boot root file system image.
The "Buildroot toolchain" is used for Application development.

It works fine and it is comfortable to use. Now I have some Questions.

- When will  linux-te-3.14 be available in this repository?

- Is it possible to use the Peta Linux 2014.2 within buildroot and how can I implement it in buildroot.
  Which steps are necessary to generate the devicetree source file working together with Kernel 3.14.

Kind regards
Rolf

[Antti Lukats]

Hi

with petalinux 2014.2 everything just works.

if you have petalinux installed, and our 720 bsp for petalinux, then you can just select 3.14 (it is already preselected)

when you change hardware in Vivado, then just drag the HDF into petalinux VM and run

petalinux-config --get-hw-description
petalinux-build

this will update the device the tree from vivado design, and build everything (for boot bin one more step is needed)

in the devicetree folder make sure you only edit the system-top.dts as all other files are generated ones.

Antti

[Rolf Kary-Ehlers]

Hi Antti

will the linux-te-3.9 from the Trenz-Electronic github be updated to linux-te-3.14?
In your answer you just say, use Petalinux and erverything is fine.
We would prefer not to change our build system "Buildroot".

If this is not longer supported, I have some questions:
Does Petalinux support support the feaures of "Buildroot" like:
- additional Libraries: boost, NE10, FFTW, ACE, etc.
- Linux Patches
Do the PetaLinux Tools and the Xilinx Software Development Kit work need Vivado on the same system?

Kind regards
Rolf

[Antti Lukats]

Hi Rolf,

I think I found a way to not answer no

As linux kernel xlnx-3.14 provides all needed support for Trenz Modules you can consider xlnx-3.14. is te-3.14
Based on that it makes no sense for us to provide exact duplicate of xlnx-3.14

Buildroot:
1 ASFAIK petalinux is built on top of buildroot and yocto
2 petalinux can use remote kernel, you just select your kernel in the main config screen

if you use buildroot without petalinux for any reason, I guess you can continue using it

Our policy is (and actually has been) to provide support for as-mainstream and as standard-accepted solutions with minimal patching and customization.

With petalinux 2014.2 virtually all functions are available with vendor supported flow, vendor=xilinx flow=petalinux

So saying once again, if you create vivado design for TE0720, and even bare template petalinux projects, and just drag HDF into it, it results in valid booting Linux system.

Our 720-BSP for petalinux provides just some customization for special functions it does not apply ANY PATCHES at all. All done by the standard customization flow.

720-BSP includes following files that are "customized"

1) system-top.dts
2) platform-top.h
3) fsbl-hooks.c

1) support and fixes to device tree
2) u-boot customization
3) early readout of MAC address from EEPROM (sets PS7-ETH mac address)

so 3 files changed, everything else is just customization done by petalinux-config gui menus.

--
WORK FLOW (this can be different, but this is what works)

1 WinPC with Vivado, used to create HDF file
2 linux VM with petalinux installed NO LICENSE, optional SDK installed without LICENSE!

create HDF, drag into VM
petalinux-config --get-hw-description
petalinx-build

those will build all needed files except BOOT.BIN
the process above does not need vivado or SDK in the linux VM

if you want to build BOOT.BIN in linux VM then Xilinx SDK must be installed, it ok not to install Xilinx license, bootgen runs without it

We are really working hard and this all will be described in our online manual also, but I hope it explains a bit the work flow.

As Xilinx does not officially support "custom board" flow in 2014.2, and was we ARE using "custom board" flow already, we consider 2014.2 as temporary version, meaning as soon as 2014.3 comes out, we are forced to switch 2014.3 in the hope that it will be at least somewhat LTS version. Or at least we will use it as long term support version.

Custom board support in 2014.2 is possible, we are doing it, but Xilinx is not supporting it, and we are not opening any more new webcases as they are related to feature that Xilinx last public release does not support.

There are some minor issues with 2014.2, both in Vivado IPI as in petalinux, they are more as annoyance as real issues, and have simple workarounds. We implement those fixes in our petalinux-bsp's.

[spoilerhead]

Hello Antti,

I think I messed up my installation somewhere. Could you tell me where I'd have to put the .bsp file ?

I'm currently building a working petalinux from your provided snapshot, using

Code: [Select]

cd 720_bsp.sdk
petalinux-create --type project --template zynq --name test
cd test
petalinux-config --get-hw-description=..
petalinux-config -c rootfs
petalinux-build
petalinux-package --boot --fsbl /tftpboot/zynq_fsbl.elf --fpga ../design_1_wrapper.bit --uboot=/tftpboot/u-boot.elf

on a first glance this works perfectly fine, but on a second one it's missing i.e. the MAC address setting from the TE0720 module.

I'm pretty sure this is because i messed up the placement of the .bsp file, but any help would be welcome.

regards,
dieter

edit:
of course, i have to add

Code: [Select]

-s /srv/shared/TE0720-2014.2-beta-1.bsp to the

Code: [Select]

petalinux-create call. doh 

[daveo]

Hi Oleksandr

we are using "buildroot" to build our Linux Image and the toolchain for the TE0720 on the TE0701 Carrier Board.
In Buildroot we have chosen the linux-te-3.9 from the Trenz-Electronic github, the te_zynq_defconfig and the TE0720-01-2IF devicetree source file.
We are using U-Boot as Bootloader and the U-Boot root file system image.
The "Buildroot toolchain" is used for Application development.

It works fine and it is comfortable to use. Now I have some Questions.

- When will  linux-te-3.14 be available in this repository?

- Is it possible to use the Peta Linux 2014.2 within buildroot and how can I implement it in buildroot.
  Which steps are necessary to generate the devicetree source file working together with Kernel 3.14.

Kind regards
Rolf

Hi Rolf,

I'm trying to setup this same environment (Buildroot with linux-te-3.9), eventually moving to a newer kernel as well.  Are you at all willing to elaborate on your Buildroot setup, or discuss any additional modifications you had to make to get your environment working?

Best regards,
Dave Oostdyk

[Antti Lukats]

Hello Antti,

I think I messed up my installation somewhere. Could you tell me where I'd have to put the .bsp file ?

I'm currently building a working petalinux from your provided snapshot, using

Code: [Select]

cd 720_bsp.sdk
petalinux-create --type project --template zynq --name test
cd test
petalinux-config --get-hw-description=..
petalinux-config -c rootfs
petalinux-build
petalinux-package --boot --fsbl /tftpboot/zynq_fsbl.elf --fpga ../design_1_wrapper.bit --uboot=/tftpboot/u-boot.elf

on a first glance this works perfectly fine, but on a second one it's missing i.e. the MAC address setting from the TE0720 module.

I'm pretty sure this is because i messed up the placement of the .bsp file, but any help would be welcome.

regards,
dieter

edit:
of course, i have to add

Code: [Select]

-s /srv/shared/TE0720-2014.2-beta-1.bsp to the

Code: [Select]

petalinux-create call. doh 

1) you have to INSTALL the bsp as explained in petalinux getting started guide.

2) MAC Address setting is currently done in the fsbl_hooks.c
if you create your own FSBL you must copy the content of the hook function before handoff

There is a catch-issue, this is something other vendors have problem also, it is possible to read and set and display the MAC from FSBL, this setting will be used and honored by LINUX when linux boots, but u-boot will not see it, actually it needed to set MAC address to empty string to prevent uboot from overwriting the MAC address that was already set.

It is possible to FIX this by changing uboot board.c file, but as 2014.3 is scheduled for 2nd week of October we will wait up that release before making decision how to overcome the uboot-MAC address problem.

I can assure, there is no "stock option" in current official petalinux to grab the MAC address into uboot, unless the address is written in environment directly.

the uboot-MAC problem and solution was already briefly described here

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

[Rolf Kary-Ehlers]

Hi Antti

Thank you for your help, Petalinux is working now with Kernel 3.14 on the TE0720-02 Module.
I took the TE0720-2014.2-beta-1.bsp.gz from the Trenz Website to build my own image.
It is a beta release, so there are some known problems, and some problems I do have with this kernel.

1. I am trying to mount a nfs shared folder on this Image using the following command:

Code: [Select]

mount 192.168.83.112:/tftpboot /mnt
mount: wrong fs type, bad option, bad superblock on 192.168.83.112:/tftpboot,
       missing codepage or helper program, or other error
       (for several filesystems (e.g. nfs, cifs) you might
       need a /sbin/mount.<type> helper program)

       In some cases useful info is found in syslog - try
       dmesg | tail or so.

I have already added nfs support, and codepages to the Kernel config:

Code: [Select]

CONFIG_NETWORK_FILESYSTEMS=y
CONFIG_NFS_FS=y
CONFIG_NFS_V2=y
CONFIG_NFS_V3=y
CONFIG_NFS_V3_ACL=y
CONFIG_NFS_V4=y
CONFIG_NFS_SWAP=y
CONFIG_NFS_V4_1=y
CONFIG_NFS_V4_2=y
CONFIG_PNFS_FILE_LAYOUT=y
CONFIG_NFS_V4_1_IMPLEMENTATION_ID_DOMAIN="kernel.org"
CONFIG_NFS_V4_1_MIGRATION=y
--------
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-1"
CONFIG_NLS_CODEPAGE_437=y
....
CONFIG_NLS_CODEPAGE_850=y

I added Portmap support to the rootfs config:

Code: [Select]

#
# portmap
#
CONFIG_ROOTFS_PACKAGES_PORTMAP=y
CONFIG_ROOTFS_PACKAGES_PORTMAP_UTILS=y

/val/log/dmesg shows nfs success messages:

Code: [Select]

[    0.804252] RPC: Registered tcp NFSv4.1 backchannel transport module.
[    1.794430] hw perfevents: enabled with ARMv7 Cortex-A9 PMU driver, 7 counters available
[    1.807618] futex hash table entries: 512 (order: 3, 32768 bytes)
[    1.816287] bounce pool size: 64 pages
[    1.822293] NFS: Registering the id_resolver key type
[    1.826395] Key type id_resolver registered
[    1.829344] Key type id_legacy registered
[    1.831987] nfs4filelayout_init: NFSv4 File Layout Driver Registering...
[    1.837623] jffs2: version 2.2. (NAND) (SUMMARY)  \xffffffc2\xffffffa9 2001-2006 Red Hat, Inc.

Where can I find nfs-utils in the configs?
I found out, that the file /sbin/mount.nfs is missing.

2. Annother issue is that I cannot use shared memory in the user applications.
In Kernel 3.9 this worked well.
The following code sample leads to a "Bus error"

Code: [Select]

shm_fd = shm_open(fname, oflags, (mode_t)0x666);
ftruncate(shm_fd, (off_t)size)
ptr = mmap(0, (size_t) size, PROT_READ|PROT_WRITE, MAP_SHARED, shm_fd, (off_t) 0);

There is no additional information about this problem in /val/log/dmesg

What about zynq-fixes-for-3.14 in the Xilinx github, do I have to install this and if so, how can I do this?

I hope you or somone else can help me to fix these bugs.

Kind regards
Rolf

[Andrei Errapart]

Code: [Select]

shm_fd = shm_open(fname, oflags, (mode_t)0x666);


Should read instead:

Code: [Select]

shm_fd = shm_open(fname, oflags, (mode_t)0666);

The last parameter is a bitflag of Unix access permissions, which are traditionally presented in octal.

[Rolf Kary-Ehlers]

Hello Andrei

thank you for your reply. I changed it to octal number representation, but the error (bus error) is still there.
The class that encapsulates these function calls was writen years ago and worked always well with these wrong numbers.
We have changed to kernel 3.14 recently from kernel 3.9 where it was working well, too.

Do you have annother idea to fix this issue?

best regards
Rolf

[Andrei Errapart]

Hello Rolf,


There is no other fault within these three lines of code and to the best of my knowledge, no special support in the kernel is required. Please find attached a trivial shared memory test program, which should print out "Success!" on every invocation.

Thus, the error must be somewhere else and I can give only generic instructions on how to find it:
1) Check return values of the system calls and print (or log, or throw) an error message as soon as possible. System calls are time-expensive anyway, thus, error checking doesn't hurt performance, but helps debugging enormously.
2) Run the program under strace and examine the output (search for /dev/shm). An example:
         strace ./shmtest >& log.txt
    The program prints both the parameters and the return values of system calls executed by the target program. Let me note that "shm_open" is translated into several system calls (open, fcntl, ftruncate and mmap). In the case of a multi-threaded program, add "-f" to the strace arguments in order to force strace to follow (v)forks.
    This requires the program "strace" to be enabled in the petalinux rootfs configuration (can be found under "Filesystem Packages -> devel").

Hopefully it helps.


best regards,
Andrei

[Rolf Kary-Ehlers]

Hello Andrei,

thank you for the test program. It printed Success!, so I could be pretty shure that the shm-functions where not the problem.
The problem was, that one memory block was too big, so that the shared memory was allocated partly. It did not fail, as I would have expected.
The "bus error" happened in memset(...) writing through the end.
I should activate remote debugging when the main problem (nfs mount) is fixed, printf-debugging is not the right thing to use.

kind regrads,
Rolf

[Andrei Errapart]

Hello Rolf,


I have been tackling the NFS problem, too. Haven't yet looked at everything; there are still some ideas to try.

Let me note that in the case there is not enough shared memory available, the /dev directory can be remounted with a bigger size option:
   mount -o remount,size=1M /dev
This can be done in a custom startup script, as described in: http://www.xilinx.com/support/answers/55998.htm


best regards,
Andrei

[Rolf Kary-Ehlers]

Hello Antti

finally I found the wrong setting for the nfs mount error.
In the rootfs petalinux-config settings the options:
- util-linux
- util-linux-mount
- util-linux-umount
were set to true by default.
I changed them to state false.
The result is that the /sbin/mount and /bin/umount links are then redirected to the "busybox mount", which works properly.

Are the util-linux mount tools buggy or are missing some extra utils?
I think both should work, when they are selected, the tool "util-linux-mount" seems to need the tool /sbin/mount.nfs, which is missing.

best regards
Rolf

[Antti Lukats]

good catch!

they probably are disabled in the peta 2014.2 template, I remember that I did enable them during config for some reason.

[Rolf Kary-Ehlers]

Hello,

the petalinux installation installs 4 toolchains to build the code.
They support only softfp emulation.
Is it possible to get or create a toolchain that is compiled for hard floating point?
e.g.: arm-xilinx-linux-gnueabihf


kind regards,
Rolf

PS: @Andrei, many thanks for your tip to increase shm-size, I could leave the software unchanged.

[Antti Lukats]

To: Rolf

this question should really be asked from Xilinx petalinux support, not from us.

2014.3 should be released second week october (Xilinx semi-official statement) maybe something is changed there already.

[Rolf Kary-Ehlers]

Hello Antti,

Thank you, I have already sent a request to their support forum.

Annother question is, what is the advantage of the 'util-linux-mount'.
I guess it should work properly also, if the nfs utils are added.

kind regards
Rolf

[Antti Lukats]

Hi Rolf,

yes I guessed it too, and that enabling it does not harm.
I guessed wrong. I think under some settings it should of course work.

[janani.subraveti]

Hi.. I am using petalinux 2015.2 , i have a multithreaded program with pthread header file included in my rootfs apps and when i build using petalinux-build it is not building this application and i dont know where can i add pthread library to the petalinux tool and get it build.

[Andrei Errapart]

It would have been better to start a new thread, because the topic of this thread is not relevant to your question in any way.

You have to be able to modify your Makefile. Brief introduction can be found here: https://www.cs.usask.ca/staff/oster/makefiles.html

It should be sufficient to add the line

Code: [Select]

LDLIBS += -lpthread
after the line beginning with "APP".

Can you post your Makefile?

[janani.subraveti]

Code: [Select]

ifndef PETALINUX
$(error "Error: PETALINUX environment variable not set.  Change to the root of your PetaLinux install, and source the settings.sh file")
endif

include apps.common.mk

APP = cmdthread

# Add any other object files to this list below
APP_OBJS = cmdthread.o

all: build install

build: $(APP)

$(APP): $(APP_OBJS)
$(CC) $(LDFLAGS) -o $@ $(APP_OBJS) $(LDLIBS)

clean:
-rm -f $(APP) *.elf *.gdb *.o

.PHONY: install image

install: $(APP)
$(TARGETINST) -d $(APP) /bin/$(APP)

%.o: %.c
$(CC) -c $(CFLAGS) -o $@ $<

help:
@echo ""
@echo "Quick reference for various supported build targets for $(INSTANCE)."
@echo "----------------------------------------------------"
@echo "  clean                  clean out build objects"
@echo "  all                    build $(INSTANCE) and install to rootfs host copy"
@echo "  build                  build subsystem"
@echo "  install                install built objects to rootfs host copy"
for the following source file

Code: [Select]

#include <stdio.h>
#include <stdlib.h>
#include <pthread.h>
#include <unistd.h>


void *myfunc (void *myvar);



int main(int argc, char *argv[])
{
pthread_t thread1,thread2;
char *msg1 = "thread1";
char *msg2 = "thread2";
int ret1,ret2;

ret1 = pthread_create(&thread1, NULL, myfunc, (void *) msg1);//pass address of the thread1,secondly NULL which is an attribute to be passed,thirdly the function to be passed and fourthly the arguments to be passed as arguments to the above function.

ret2 = pthread_create(&thread2, NULL, myfunc, (void *) msg2);


printf("Main function after pthread_create\n");

pthread_join(thread1, NULL);
pthread_join(thread1, NULL);

printf("first thread ret1 = %d\n", ret1);
printf("Second thread ret2 = %d\n", ret2);
return 0;

}


void *myfunc (void *myvar)
{
//char *msg;
//msg = (char *) myvar;

int i;
for(i = 0;i<10;i++)
{
printf("%s %d\n",(char*)myvar,i);
sleep(1);

}
return NULL;

}


[Andrei Errapart]

I assumed that you post the Makefile only when you're unable to follow the instructions. Don't be afraid of changing Makefiles yourself.

After the change, you can verify that it compiles by only compiling your application with the command

Code: [Select]

petalinux-build -c rootfs/cmdthread

This is faster than full build.

[janani.subraveti]

I performed it already before by giving

Code: [Select]

%.o: %.c
$(CC) -c $(CFLAGS) -o $@ $< -pthread
instead of

Code: [Select]

%.o: %.c
$(CC) -c $(CFLAGS) -o $@ $< in the make file and tried to build it which showed no effect at all.

kind regards.

[janani.subraveti]

Ahh got it... the correct make file is this

Code: [Select]

ifndef PETALINUX
$(error "Error: PETALINUX environment variable not set.  Change to the root of your PetaLinux install, and source the settings.sh file")
endif

include apps.common.mk

APP = cmdthread

# Add any other object files to this list below
APP_OBJS = cmdthread.o

all: build install

build: $(APP)

$(APP): $(APP_OBJS)
$(CC) $(LDFLAGS) -o $@ $(APP_OBJS) $(LDLIBS) -lpthread

clean:
-rm -f $(APP) *.elf *.gdb *.o

.PHONY: install image

install: $(APP)
$(TARGETINST) -d $(APP) /bin/$(APP)

%.o: %.c
$(CC) -c $(CFLAGS) -o $@ $<

help:
@echo ""
@echo "Quick reference for various supported build targets for $(INSTANCE)."
@echo "----------------------------------------------------"
@echo "  clean                  clean out build objects"
@echo "  all                    build $(INSTANCE) and install to rootfs host copy"
@echo "  build                  build subsystem"
@echo "  install                install built objects to rootfs host copy"