Using own IP cores in xillinux 1.3

Questions and discussions about Xillinux

Using own IP cores in xillinux 1.3

Postby bobdxcool »

I have a xillinux 1.3 distribution installed on my microzedboard. I have also enabled UART0 on this board. Now, I wanted to replace the xillybus lite IP core with an IP core of my own. Will the xillinux OS and all drivers continue to work with this xillybus IP core replaced with my own IP core ?

Also, since I have used up UART0 and UART1 of the microzed board, I will implement a serial port on the FPGA using the EMIO pins of the microzed board on my own IP core. I want to use this serial port to communicate with an external serial modem. Now on the xillinux OS, do I have to modify/add any drivers to detect this FPGA serial port or is there any other way of doing it ? Or will it get automatically detected as ttyS0,ttyS1, and so on ?
bobdxcool
 
Posts: 15
Joined:

Re: Using own IP cores in xillinux 1.3

Postby support »

Hi,

It goes like this:

  • The system design in XPS (don't use Vivado for this) should reflect the configuration. That is, which cores are applied, which addresses, interrupts etc. If you change clocks frequencies, be sure to implement the logic design in ISE, so that the constraints are set up correctly.
  • The FSBL within the boot.bin in effect should be derived from this system design.
  • If you remove a core for which there's an entry in the Device Tree, its entry must be removed from the Device Tree as well, or the system will probably hang during boot.
  • If you add a core that has a commonly used driver, adding a suitable entry in the device tree is probably the easiest way to get it up and running. But for a homecooked piece of IP that is attached to the bus, it may be easier to hack together a driver that doesn't rely on the Device Tree, but has the information hardcoded in the driver. Not elegant, but quick & dirty.

These two pages have some more related info:

http://xillybus.com/tutorials/device-tree-zynq-1
viewtopic.php?f=4&t=319

Regards,
Eli
support
 
Posts: 802
Joined:

Re: Using own IP cores in xillinux 1.3

Postby bobdxcool »

eli wrote:Hi,

It goes like this:

  • The system design in XPS (don't use Vivado for this) should reflect the configuration. That is, which cores are applied, which addresses, interrupts etc. If you change clocks frequencies, be sure to implement the logic design in ISE, so that the constraints are set up correctly.
  • The FSBL within the boot.bin in effect should be derived from this system design.
  • If you remove a core for which there's an entry in the Device Tree, its entry must be removed from the Device Tree as well, or the system will probably hang during boot.
  • If you add a core that has a commonly used driver, adding a suitable entry in the device tree is probably the easiest way to get it up and running. But for a homecooked piece of IP that is attached to the bus, it may be easier to hack together a driver that doesn't rely on the Device Tree, but has the information hardcoded in the driver. Not elegant, but quick & dirty.

These two pages have some more related info:

http://xillybus.com/tutorials/device-tree-zynq-1
viewtopic.php?f=4&t=319

Regards,
Eli


eli wrote:Hi,

It goes like this:

  • The system design in XPS (don't use Vivado for this) should reflect the configuration. That is, which cores are applied, which addresses, interrupts etc. If you change clocks frequencies, be sure to implement the logic design in ISE, so that the constraints are set up correctly.
  • The FSBL within the boot.bin in effect should be derived from this system design.
  • If you remove a core for which there's an entry in the Device Tree, its entry must be removed from the Device Tree as well, or the system will probably hang during boot.
  • If you add a core that has a commonly used driver, adding a suitable entry in the device tree is probably the easiest way to get it up and running. But for a homecooked piece of IP that is attached to the bus, it may be easier to hack together a driver that doesn't rely on the Device Tree, but has the information hardcoded in the driver. Not elegant, but quick & dirty.

These two pages have some more related info:

http://xillybus.com/tutorials/device-tree-zynq-1
viewtopic.php?f=4&t=319

Regards,
Eli


I will either use UARTLITE or 16550 UART as mentioned in this forum, https://forums.xilinx.com/t5/Embedded-L ... lse#M13133

But it is also mentioned that the person couldn't get UARTLITE working with microzed. Do you have any suggestion on how to get UARTLITE working on microzed ? Because it would easier to use UARTLITE because with 16550 UART, I would have to modify the kernel config and recompile it.

If I use 16550 UART, these are the steps I would follow:

1.) Remove the following lines below from the existing .dts file of xillinux 1.3
xillybus_lite@50002000 {
interrupt-parent = <0x2>;
interrupts = <0x0 0x3a 0x1>;
reg = <0x50002000 0x1000>;
compatible = "xillybus,xillybus_lite_of-1.00.a";
};
xillybus@50000000 {
dma-coherent;
interrupt-parent = <0x2>;
interrupts = <0x0 0x3b 0x1>;
reg = <0x50000000 0x1000>;
compatible = "xillybus,xillybus-1.00.a";
};

Add the device tree from this forum, https://forums.xilinx.com/t5/Embedded-L ... lse#M13133

2.) Compile .dts to .dtb. Copy it to the SD card and boot the system. Also, before all this I would generate a .bit file using vivado for the two UART 16550 ports I would add and also copy this new .bit file to the SD card.

3.) Now, I would go to the /root/build folder and edit the linux kernel .config file using sudo nano xilinux.config file , and make changes to the serial port section as mentioned in this forum, https://forums.xilinx.com/t5/Embedded-L ... lse#M13133 . I would now save the new .config file.

4.) Now my question is how do I recompile and rebuild the kernel ?
Is it just sudo make menuconfig from the same folder ?
Or do I need to something else ?

After doing all these, I just reboot the microzed board and detect the tty ports using dmesg?
bobdxcool
 
Posts: 15
Joined:

Re: Using own IP cores in xillinux 1.3

Postby bobdxcool »

eli wrote:Hi,

It goes like this:

  • The system design in XPS (don't use Vivado for this) should reflect the configuration. That is, which cores are applied, which addresses, interrupts etc. If you change clocks frequencies, be sure to implement the logic design in ISE, so that the constraints are set up correctly.
  • The FSBL within the boot.bin in effect should be derived from this system design.
  • If you remove a core for which there's an entry in the Device Tree, its entry must be removed from the Device Tree as well, or the system will probably hang during boot.
  • If you add a core that has a commonly used driver, adding a suitable entry in the device tree is probably the easiest way to get it up and running. But for a homecooked piece of IP that is attached to the bus, it may be easier to hack together a driver that doesn't rely on the Device Tree, but has the information hardcoded in the driver. Not elegant, but quick & dirty.

These two pages have some more related info:

http://xillybus.com/tutorials/device-tree-zynq-1
viewtopic.php?f=4&t=319

Regards,
Eli


eli wrote:Hi,

It goes like this:

  • The system design in XPS (don't use Vivado for this) should reflect the configuration. That is, which cores are applied, which addresses, interrupts etc. If you change clocks frequencies, be sure to implement the logic design in ISE, so that the constraints are set up correctly.
  • The FSBL within the boot.bin in effect should be derived from this system design.
  • If you remove a core for which there's an entry in the Device Tree, its entry must be removed from the Device Tree as well, or the system will probably hang during boot.
  • If you add a core that has a commonly used driver, adding a suitable entry in the device tree is probably the easiest way to get it up and running. But for a homecooked piece of IP that is attached to the bus, it may be easier to hack together a driver that doesn't rely on the Device Tree, but has the information hardcoded in the driver. Not elegant, but quick & dirty.

These two pages have some more related info:

http://xillybus.com/tutorials/device-tree-zynq-1
viewtopic.php?f=4&t=319

Regards,
Eli


I will either use UARTLITE or 16550 UART as mentioned in this forum, https://forums.xilinx.com/t5/Embedded-L ... lse#M13133

But it is also mentioned that the person couldn't get UARTLITE working with microzed. Do you have any suggestion on how to get UARTLITE working on microzed ? Because it would easier to use UARTLITE because with 16550 UART, I would have to modify the kernel config and recompile it.

If I use 16550 UART, these are the steps I would follow:

1.) Remove the following lines below from the existing .dts file of xillinux 1.3
xillybus_lite@50002000 {
interrupt-parent = <0x2>;
interrupts = <0x0 0x3a 0x1>;
reg = <0x50002000 0x1000>;
compatible = "xillybus,xillybus_lite_of-1.00.a";
};
xillybus@50000000 {
dma-coherent;
interrupt-parent = <0x2>;
interrupts = <0x0 0x3b 0x1>;
reg = <0x50000000 0x1000>;
compatible = "xillybus,xillybus-1.00.a";
};

Add the device tree from this forum, https://forums.xilinx.com/t5/Embedded-L ... lse#M13133

2.) Compile .dts to .dtb. Copy it to the SD card and boot the system. Also, before all this I would generate a .bit file using vivado for the two UART 16550 ports I would add and also copy this new .bit file to the SD card.

3.) Now, I would go to the /root/build folder and edit the linux kernel .config file using sudo nano xilinux.config file , and make changes to the serial port section as mentioned in this forum, https://forums.xilinx.com/t5/Embedded-L ... lse#M13133 . I would now save the new .config file.

4.) Now my question is how do I recompile and rebuild the kernel ?
Is it just sudo make menuconfig from the same folder ?
Or do I need to something else ?

After doing all these, I just reboot the microzed board and detect the tty ports using dmesg?
bobdxcool
 
Posts: 15
Joined:

Re: Using own IP cores in xillinux 1.3

Postby bobdxcool »

eli wrote:Hi,

It goes like this:

  • The system design in XPS (don't use Vivado for this) should reflect the configuration. That is, which cores are applied, which addresses, interrupts etc. If you change clocks frequencies, be sure to implement the logic design in ISE, so that the constraints are set up correctly.
  • The FSBL within the boot.bin in effect should be derived from this system design.
  • If you remove a core for which there's an entry in the Device Tree, its entry must be removed from the Device Tree as well, or the system will probably hang during boot.
  • If you add a core that has a commonly used driver, adding a suitable entry in the device tree is probably the easiest way to get it up and running. But for a homecooked piece of IP that is attached to the bus, it may be easier to hack together a driver that doesn't rely on the Device Tree, but has the information hardcoded in the driver. Not elegant, but quick & dirty.

These two pages have some more related info:

http://xillybus.com/tutorials/device-tree-zynq-1
viewtopic.php?f=4&t=319

Regards,
Eli


eli wrote:Hi,

It goes like this:

  • The system design in XPS (don't use Vivado for this) should reflect the configuration. That is, which cores are applied, which addresses, interrupts etc. If you change clocks frequencies, be sure to implement the logic design in ISE, so that the constraints are set up correctly.
  • The FSBL within the boot.bin in effect should be derived from this system design.
  • If you remove a core for which there's an entry in the Device Tree, its entry must be removed from the Device Tree as well, or the system will probably hang during boot.
  • If you add a core that has a commonly used driver, adding a suitable entry in the device tree is probably the easiest way to get it up and running. But for a homecooked piece of IP that is attached to the bus, it may be easier to hack together a driver that doesn't rely on the Device Tree, but has the information hardcoded in the driver. Not elegant, but quick & dirty.

These two pages have some more related info:

http://xillybus.com/tutorials/device-tree-zynq-1
viewtopic.php?f=4&t=319

Regards,
Eli


I will either use UARTLITE or 16550 UART as mentioned in this forum, https://forums.xilinx.com/t5/Embedded-L ... lse#M13133

But it is also mentioned that the person couldn't get UARTLITE working with microzed. Do you have any suggestion on how to get UARTLITE working on microzed ? Because it would easier to use UARTLITE because with 16550 UART, I would have to modify the kernel config and recompile it.

If I use 16550 UART, these are the steps I would follow:

1.) Remove the following lines below from the existing .dts file of xillinux 1.3
xillybus_lite@50002000 {
interrupt-parent = <0x2>;
interrupts = <0x0 0x3a 0x1>;
reg = <0x50002000 0x1000>;
compatible = "xillybus,xillybus_lite_of-1.00.a";
};
xillybus@50000000 {
dma-coherent;
interrupt-parent = <0x2>;
interrupts = <0x0 0x3b 0x1>;
reg = <0x50000000 0x1000>;
compatible = "xillybus,xillybus-1.00.a";
};

Add the device tree from this forum, https://forums.xilinx.com/t5/Embedded-L ... lse#M13133

2.) Compile .dts to .dtb. Copy it to the SD card and boot the system. Also, before all this I would generate a .bit file using vivado for the two UART 16550 ports I would add and also copy this new .bit file to the SD card.

3.) Now, I would go to the /root/build folder and edit the linux kernel .config file using sudo nano xilinux.config file , and make changes to the serial port section as mentioned in this forum, https://forums.xilinx.com/t5/Embedded-L ... lse#M13133 . I would now save the new .config file.

4.) Now my question is how do I recompile and rebuild the kernel ?
Is it just sudo make menuconfig from the same folder ?
Or do I need to something else ?

After doing all these, I just reboot the microzed board and detect the tty ports using dmesg?
bobdxcool
 
Posts: 15
Joined:

Re: Using own IP cores in xillinux 1.3

Postby support »

Hi,

In order to obtain the kernel sources as used in Xillinux, please refer to /usr/src/xillinux/linux-patches in Xillinux' file system, the README file in particular. Then compile the kernel following the common practices for a cross compilation for an ARMv7 target (there are plenty of resources for that on the web, probably in relation with Zynq too).

The recommended cross compiler is the one that arrives with Xilinx' SDK, even though other compilers may work well too.

Regards,
Eli
support
 
Posts: 802
Joined:

Re: Using own IP cores in xillinux 1.3

Postby bobdxcool »

eli wrote:Hi,

In order to obtain the kernel sources as used in Xillinux, please refer to /usr/src/xillinux/linux-patches in Xillinux' file system, the README file in particular. Then compile the kernel following the common practices for a cross compilation for an ARMv7 target (there are plenty of resources for that on the web, probably in relation with Zynq too).

The recommended cross compiler is the one that arrives with Xilinx' SDK, even though other compilers may work well too.

Regards,
Eli


When I open the text file, I found this:

These patches are with respect to Diglent's Linux kernel tree, commit ID
7ad8e6023d969336961312ef751228cbb8874752 (tag xilinx-v2013.4).

Digilent's git repository can be downloaded at
https://github.com/Digilent/linux-Digilent-Dev.git

1.) I am actually not looking to download the sources and compile it. What I am looking to do is recompile and rebuild the existing zynq kernel on the zynq board after making changes to the config file. How do you recommend doing this ?

I will also give UARTlite a try.

http://www.wiki.xilinx.com/Uartlite+Driver

2.) From this link above, they say that
To enable the uartlite driver in the linux kernel you either have to integrate it or build it as kernel module (.ko). You can enable it with:

make menuconfig
---> Device Drivers ---> Character devices ---> Serial drivers ---> Xilinx uartlite serial port support

make menuconfig - I know I have to enter this command on the microzed boardin the /root/boot/ to enable it.

But what does , ---> Device Drivers ---> Character devices ---> Serial drivers ---> Xilinx uartlite serial port support THIS MEAN ?

They also say that, Or you can do this in the .config file with either of the following lines:

# integrate into the kernel
CONFIG_SERIAL_UARTLITE=y
# build as loadable module
CONFIG_SERIAL_UARTLITE=m

After that you of course have to rebuild the kernel and deploy it to your Zynq device

Again, when they say rebuild the kernel, after editing and saving the .conf file on the microzedboard, how do I rebuild it on the microzed? What command do I use here ?
bobdxcool
 
Posts: 15
Joined:

Re: Using own IP cores in xillinux 1.3

Postby bobdxcool »

eli wrote:Hi,

In order to obtain the kernel sources as used in Xillinux, please refer to /usr/src/xillinux/linux-patches in Xillinux' file system, the README file in particular. Then compile the kernel following the common practices for a cross compilation for an ARMv7 target (there are plenty of resources for that on the web, probably in relation with Zynq too).

The recommended cross compiler is the one that arrives with Xilinx' SDK, even though other compilers may work well too.

Regards,
Eli


As I was suggested to post in the xillybus forums by microzed forums for xillinux related stuff, I'm post all my xillinux stuff there here,

I am using a different IP core (UART Lite) and removing the pipe drivers in the .dts file and recompiling it to .dtb. I am removing the following two structures from the .dts file

xillybus_lite@50002000 {
interrupt-parent = <0x2>;
interrupts = <0x0 0x3a 0x1>;
reg = <0x50002000 0x1000>;
compatible = "xillybus,xillybus_lite_of-1.00.a";
};
xillybus@50000000 {
dma-coherent;
interrupt-parent = <0x2>;
interrupts = <0x0 0x3b 0x1>;
reg = <0x50000000 0x1000>;
compatible = "xillybus,xillybus-1.00.a";
};

And add two serial ports to device tree (http://www.wiki.xilinx.com/Uartlite+Driver)

uartlite_0@42C00000 {
compatible = "xlnx,axi-uartlite-1.02.a";
reg = <0x42C00000 0x10000>;
interrupt-parent = <&gic>;
interrupts = <0 59 4>;
clock = <100000000>;
};

uartlite_1@42C10000 {
compatible = "xlnx,axi-uartlite-1.02.a";
reg = <0x42C10000 0x10000>;
interrupt-parent = <&gic>;
interrupts = <0 59 4>;
clock = <100000000>;
};

recompile to .dtb and copy this .dtb to the boot folder.

Now in order for me to detect these ports on linux, I have to modify the .config file in the /boot folder as given in this link, http://www.wiki.xilinx.com/Uartlite+Driver

Now I need to rebuild the (entire kernel) I believe as they say in the link above.

But as per xillinux documentation, http://xillybus.com/downloads/doc/xilly ... d_zynq.pdf , in section 6.3, they say The Xillinux distribution comes with the running kernel’s compilation headers. This
is not enough to compile the kernel itself, but allows kernel modules to be compiled
natively on the platform.

NOTE: I want to compile the old kernel with the new configuration on the microzed itself using the compiler that exists on the xillinux itself.

So,

1.) I cannot use the method in 6.3 to compile the entire kernel. But the changes I made to .config file require a full kernel compile and rebuild, right ? Not just modules ?

So, I asked if I could use the instructions in this link, http://www.thegeekstuff.com/2013/06/com ... ux-kernel/ to compile and rebuild ? It seems to be pretty easy to do as well. Also, here do i need to download any header files for compiling entire module ?

2.) If you think I dont need to compile the entire kernel, then I can use the commands in section 6.3 of the xillybus document ?

So, I just need to modify the .config file(config-3.12-.0-xillinux-1.3) with nano, save it, and from the same folder (/boot) run the command below (makefile already exists as per xillinux 1.3 documentation)

# make
make -C /lib/modules/3.12.0-xillinux-1.3/build SUBDIRS=/root/sample modules

And then install them as

make modules_install

and then,

make install (or should I skip this step ?)

Then reboot.

Is this right ?
bobdxcool
 
Posts: 15
Joined:

Re: Using own IP cores in xillinux 1.3

Postby bobdxcool »

eli wrote:Hi,

It goes like this:

  • The system design in XPS (don't use Vivado for this) should reflect the configuration. That is, which cores are applied, which addresses, interrupts etc. If you change clocks frequencies, be sure to implement the logic design in ISE, so that the constraints are set up correctly.
  • The FSBL within the boot.bin in effect should be derived from this system design.
  • If you remove a core for which there's an entry in the Device Tree, its entry must be removed from the Device Tree as well, or the system will probably hang during boot.
  • If you add a core that has a commonly used driver, adding a suitable entry in the device tree is probably the easiest way to get it up and running. But for a homecooked piece of IP that is attached to the bus, it may be easier to hack together a driver that doesn't rely on the Device Tree, but has the information hardcoded in the driver. Not elegant, but quick & dirty.

These two pages have some more related info:

http://xillybus.com/tutorials/device-tree-zynq-1
viewtopic.php?f=4&t=319

Regards,
Eli


From your reply on this page, https://forums.xilinx.com/t5/Embedded-L ... d-p/657370

It is clear that I dont need to rebuild the kernel for both UART 16550 and UART lite.

1.) But I have to replace the xillybus core with the uart lite core and create a new bit file, right ?
For which I have to remove xillybus pipe driver entries in the device tree too.

So, I remove


xillybus_lite@50002000 {
interrupt-parent = <0x2>;
interrupts = <0x0 0x3a 0x1>;
reg = <0x50002000 0x1000>;
compatible = "xillybus,xillybus_lite_of-1.00.a";
};

xillybus@50000000 {
dma-coherent;
interrupt-parent = <0x2>;
interrupts = <0x0 0x3b 0x1>;
reg = <0x50000000 0x1000>;
compatible = "xillybus,xillybus-1.00.a";
};

And add

uartlite_0@42C00000 {
compatible = "xlnx,axi-uartlite-1.02.a";
reg = <0x42C00000 0x10000>;
interrupt-parent = <&gic>;
interrupts = <0 59 4>;
clock = <100000000>;
};

uartlite_1@42C10000 {
compatible = "xlnx,axi-uartlite-1.02.a";
reg = <0x42C10000 0x10000>;
interrupt-parent = <&gic>;
interrupts = <0 59 4>;
clock = <100000000>;
};

2.)Now when I modified the device tree last time to enable UART 0, I had to regenerate the boot.bin file. So, now also I need to generate boot.bin again using your uboot.elf file(http://xillybus.com/downloads/u-boot-xi ... .3.elf.zip) ?
bobdxcool
 
Posts: 15
Joined:


Return to Xillinux (Linux distribution for Zynq-7000)

cron