Jump to content
  • 0

PCAM 5C WITH ZEDBOARD


BANDI

Question

Hi.,

Im trying to run the project available in Github for Pcam 5C camera with Zedboard using FMC Adapter.

Upto bit stream is done and exported to SDK Successfully.

After creating Application and adding files it is showing errors.

Kindly help regarding this

Version: Vivado 2018.2.1

Link to comment
Share on other sites

Recommended Posts

1 hour ago, Ionel said:

5.A. is reduntant since it is ovrewriten by 5.B. command. Also 5.B command is changing the hardware configuration that may not have a support for mipi/pcam
5.C. It is possible that you change the hardware to add support for mipi/pcam It is not clear. Hardware changes here should be reflected by the device tree.(under amba_pl node where all PL nodes are nested. Check pl.dtsi file under components directory to see what was generated by petalinux for your hardware description (.hdf/.xsa).
5.F What is xlnk node used for?
Are you trying to overwrite an existing device tree node?
Why have it as a child to device tree root node?

5.G Are you having problem with image.ub size? If i recall correctly there is a limit to 100Mb. If so make sure you add only what you need to rootfs or use an ext3/4 partition for `/` mount point instead of a ramdisk. You can do this in via `petalinux-config` check user guide for more details on how to do this.


In your device tree excerpt there is no node for pcam i2c here is an example for zybo-z7-20 under &axi_iic_0 node: https://github.com/Digilent/Zybo-Z7-OS/blob/20/Petalinux/next/project-spec/meta-user/recipes-bsp/device-tree/files/system-user.dtsi

Also the linux kernel used in 2019.1 was patched to fix some ov5640 issues.
Here are the patches you can use:
https://github.com/Digilent/Zybo-Z7-OS/tree/20/Petalinux/next/project-spec/meta-user/recipes-kernel/linux/linux-xlnx

0001-Partially-revert-media-ov5640-Fix-timings-setup-code.patch
0002-media-ov5640-use-old-clock-tree-calculation-methods.patch

As a general rule: Start by having a simple as possible pipeline and add filters at a later stage.You may want to commit(git) when things are working so you can go back. Probably you are already doing this but just as a reminder. Also run `petalinux-config --silent` when you go back to early states/commits this way you avoid wasting time on non issues.

Thank you for the detailed explanation

I also tried to ignore 5B, which works well. with 5C drivers are added for the mipi.

I did check pl.dtsi file. I did not understand what all to be included in the device tree. I mentioned in the previous post of mine about what I was including for the four pcam cameras. Do we need to activate FMC driver in the kernel?

Also, could you please tell me how to check gpio pin numbers in my case? I am not sure about this part.

&mipi_csi2_rx_subsystem_0 {

reset-gpios = <&gpio0 57 GPIO_ACTIVE_LOW>;

csiss_ports: ports {

#address-cells = <1>;

#size-cells = <0>;

csiss_port0: port@0 {

/* Fill cfa-pattern=rggb for raw data types, other fields video-format and video-width user needs to fill */

reg = <0>;

xlnx,cfa-pattern = "rggb";

xlnx,video-format = <12>;

xlnx,video-width = <8>;

csiss_out: endpoint {

remote-endpoint = <&vcap_mipi_in>;

};

};

csiss_port1: port@1 {

/* Fill cfa-pattern=rggb for raw data types, other fields video-format,video-width user needs to fill */

/* User need to add something like remote-endpoint=<&out> under the node csiss_in:endpoint */

reg = <1>;

xlnx,cfa-pattern = "rggb";

xlnx,video-format = <12>;

xlnx,video-width = <8>;

csiss_in: endpoint {

};

};

};

};

 

Now, I will go through the links you provided me for device tree. get back to you about my understandings on it. Will the device tree holds same for Zedboard and FMC with two/four pcam cameras as zybo.

5F- I will be needing staging driver for the accelerators, which I configure in the kernel(this I saw in petalinux manual for opencv part, which i did use while implementing using offline images stored in SD Card)
5G- currently, I have no problem with the size for image.ub

pl.dtsi

Link to comment
Share on other sites

Just to sync our understanding.
Please fill in the `???` and if some statement are not true please make sure you clarify that in next post.

1. You have a development machine which has:
a. Arch x86_64 OS: ubuntu 18.04 
b. Vivado version ???, XSDK version ???, petalinux version ???

2. Your target hardware:
a. Is a zedboard rev ???
b. A pcam rev ??? is attached over FMC adapter

3. Your hardware configuration is https://github.com/Digilent/ZedBoard-FMC-Pcam-Adapter-DEMO/releases/tag/v2019.1-1 without any modifications.

4. You have run the bare-metal(standalone/without OS) demo included in above link and is working. This works without linux

5. Your target OS: 
a. Is a petalinux project that you have created using hardware description in https://github.com/Digilent/ZedBoard-FMC-Pcam-Adapter-DEMO/releases/tag/v2019.1-1
b. First build was working
c. First boot from sd card went ok without any issues (no kenel panic).
d. You started extending the linux kernel and the rootfs to include support for pcam and required tools.
e. At this point things started to go wrong.

Link to comment
Share on other sites

5.A. is reduntant since it is ovrewriten by 5.B. command. Also 5.B command is changing the hardware configuration that may not have a support for mipi/pcam
5.C. It is possible that you change the hardware to add support for mipi/pcam It is not clear. Hardware changes here should be reflected by the device tree.(under amba_pl node where all PL nodes are nested. Check pl.dtsi file under components directory to see what was generated by petalinux for your hardware description (.hdf/.xsa).
5.F What is xlnk node used for?
Are you trying to overwrite an existing device tree node?
Why have it as a child to device tree root node?

5.G Are you having problem with image.ub size? If i recall correctly there is a limit to 100Mb. If so make sure you add only what you need to rootfs or use an ext3/4 partition for `/` mount point instead of a ramdisk. You can do this in via `petalinux-config` check user guide for more details on how to do this.


In your device tree excerpt there is no node for pcam i2c here is an example for zybo-z7-20 under &axi_iic_0 node: https://github.com/Digilent/Zybo-Z7-OS/blob/20/Petalinux/next/project-spec/meta-user/recipes-bsp/device-tree/files/system-user.dtsi

Also the linux kernel used in 2019.1 was patched to fix some ov5640 issues.
Here are the patches you can use:
https://github.com/Digilent/Zybo-Z7-OS/tree/20/Petalinux/next/project-spec/meta-user/recipes-kernel/linux/linux-xlnx

0001-Partially-revert-media-ov5640-Fix-timings-setup-code.patch
0002-media-ov5640-use-old-clock-tree-calculation-methods.patch

As a general rule: Start by having a simple as possible pipeline and add filters at a later stage.You may want to commit(git) when things are working so you can go back. Probably you are already doing this but just as a reminder. Also run `petalinux-config --silent` when you go back to early states/commits this way you avoid wasting time on non issues.

Link to comment
Share on other sites

13 minutes ago, elodg said:

For Linux and V4L2 integration, the Xilinx MIPI CSI-2 subsystem should be used.

could you please tell me if my understanding is right or wrong here. https://github.com/Digilent/ZedBoard-FMC-Pcam-Adapter-DEMO/releases/tag/v2019.1-1?_ga=2.167092222.1978256034.1611579035-2037839658.1594589074 this is the design I am using and I need to create Linux application for four cameras. Can I use this hdf file for creation of petalinux project ? and During the petalinux project- I need to integrate V4L2 and use Xilinix mipi subsystem, connect the end to end node points for successful device tree generation. My main objective is to create linux (FPGA implementation)application using FMC PCAM cameras (2/4 cameras) with zedboard. My another question is if I can use this example desgin or need to create one to reach my goal.

Link to comment
Share on other sites

hello,

I was trying to create an application and running on the zedboard with boot images created by the petalinux for checking the drivers part. I was able to boot and check the errors two days ago.

I have the boot image screenshot which stops in the middle now. any help for this problem ?

large.1580033002_Screenshotfrom2021-03-0318-23-12.png.0c68103a37d2f0f15fa4e5131bdab0bf.png

Quote

=~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2021.03.03 18:20:20 =~=~=~=~=~=~=~=~=~=~=~=

Unknown command 'æ`æx~þøæ`ææ`ææ`ææ~xð~~xð~' - try 'help'
Zynq>
Unknown command 'æ`æx~þøæ`ææ`ææ`ææ~xð~~xð~' - try 'help'
Zynq> boot
Device: mmc@e0100000
Manufacturer ID: 6
OEM: 524b
Name: MSBus Speed: 50000000
Mode : SD High Speed (50MHz)
Rd Block Len: 512
SD version 3.0
High Capacity: Yes
Capacity: 7.3 GiB
Bus Width: 4-bit
Erase Group Size: 512 Bytes
4190944 bytes read in 248 ms (16.1 MiB/s)
## Loading kernel from FIT Image at 10000000 ...
   Using 'conf@system-top.dtb' configuration
   Verifying Hash Integrity ... OK
   Trying 'kernel@1' kernel subimage
     Description:  Linux kernel
     Type:         Kernel Image
     Compression:  uncompressed
     Data Start:   0x10000108
     Data Size:    4167248 Bytes = 4 MiB
     Architecture: ARM
     OS:           Linux
     Load Address: 0x00008000
     Entry Point:  0x00008000
     Hash algo:    sha1
     Hash value:   ce9029c231cdfe6466bd8a112188c4acfaa6e8de
   Verifying Hash Integrity ... sha1+ OK
## Loading fdt from FIT Image at 10000000 ...
   Using 'conf@system-top.dtb' configuration
   Verifying Hash Integrity ... OK
   Trying 'fdt@system-top.dtb' fdt subimage
     Description:  Flattened Device Tree blob
     Type:         Flat Device Tree
     Compression:  uncompressed
     Data Start:   0x103f9858
     Data Size:    21783 Bytes = 21.3 KiB
     Architecture: ARM
     Hash algo:    sha1
     Hash value:   2f96fd6acea5be5dd83132fdf271d64937519788
   Verifying Hash Integrity ... sha1+ OK
   Booting using the fdt blob at 0x103f9858
   Loading Kernel Image ... OK
   Loading Device Tree to 07ff7000, end 07fff516 ... OK

Starting kernel ...

Booting Linux on physical CPU 0x0
Linux version 4.19.0-xilinx-v2019.1 (oe-user@oe-host) (gcc version 8.2.0 (GCC)) #1 SMP PREEMPT Wed Mar 3 16:20:43 UTC 2021
CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), cr=18c5387d
CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
OF: fdt: Machine model: Zynq Zed Development Board
bootconsole [earlycon0] enabled
Memory policy: Data cache writealloc
cma: Reserved 16 MiB at 0x1f000000
random: get_random_bytes called from start_kernel+0x80/0x3c4 with crng_init=0
percpu: Embedded 16 pages/cpu @(ptrval) s35916 r8192 d21428 u65536
Built 1 zonelists, mobility grouping on.  Total pages: 130048
Kernel command line: console=ttyPS0,115200 earlyprintk root=/dev/mmcblk0p2 rw rootwait
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Memory: 492980K/524288K available (6144K kernel code, 206K rwdata, 1628K rodata, 1024K init, 246K bss, 14924K reserved, 16384K cma-reserved, 0K highmem)
Virtual kernel memory layout:
    vector  : 0xffff0000 - 0xffff1000   (   4 kB)
    fixmap  : 0xffc00000 - 0xfff00000   (3072 kB)
    vmalloc : 0xe0800000 - 0xff800000   ( 496 MB)
    lowmem  : 0xc0000000 - 0xe0000000   ( 512 MB)
    pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)
    modules : 0xbf000000 - 0xbfe00000   (  14 MB)
      .text : 0x(ptrval) - 0x(ptrval)   (7136 kB)
      .init : 0x(ptrval) - 0x(ptrval)   (1024 kB)
      .data : 0x(ptrval) - 0x(ptrval)   ( 207 kB)
       .bss : 0x(ptrval) - 0x(ptrval)   ( 247 kB)
rcu: Preemptible hierarchical RCU implementation.
rcu:     RCU restricting CPUs from NR_CPUS=4 to nr_cpu_ids=2.
    Tasks RCU enabled.
rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=2
NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
efuse mapped to (ptrval)
slcr mapped to (ptrval)
L2C: platform modifies aux control register: 0x72360000 -> 0x72760000
L2C: DT/platform modifies aux control register: 0x72360000 -> 0x72760000
L2C-310 erratum 769419 enabled
L2C-310 enabling early BRESP for Cortex-A9
L2C-310 full line of zeros enabled for Cortex-A9
L2C-310 ID prefetch enabled, offset 1 lines
L2C-310 dynamic clock gating enabled, standby mode enabled
L2C-310 cache controller enabled, 8 ways, 512 kB
L2C-310: CACHE_ID 0x410000c8, AUX_CTRL 0x76760001
zynq_clock_init: clkc starts at (ptrval)
Zynq clock init
sched_clock: 64 bits at 333MHz, resolution 3ns, wraps every 4398046511103ns
clocksource: arm_global_timer: mask: 0xffffffffffffffff max_cycles: 0x4ce07af025, max_idle_ns: 440795209040 ns
Switching to timer-based delay loop, resolution 3ns
clocksource: ttc_clocksource: mask: 0xffff max_cycles: 0xffff, max_idle_ns: 537538477 ns
timer #0 at (ptrval), irq=17
Console: colour dummy device 80x30
Calibrating delay loop (skipped), value calculated using timer frequency.. 666.66 BogoMIPS (lpj=3333333)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
CPU: Testing write buffer coherency: ok
CPU0: Spectre v2: using BPIALL workaround
CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
Setting up static identity map for 0x100000 - 0x100060
rcu: Hierarchical SRCU implementation.
smp: Bringing up secondary CPUs ...
CPU1: thread -1, cpu 1, socket 0, mpidr 80000001
CPU1: Spectre v2: using BPIALL workaround
smp: Brought up 1 node, 2 CPUs
SMP: Total of 2 processors activated (1333.33 BogoMIPS).
CPU: All CPU(s) started in SVC mode.
devtmpfs: initialized
VFP support v0.3: implementor 41 architecture 3 part 30 variant 9 rev 4
clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
futex hash table entries: 512 (order: 3, 32768 bytes)
pinctrl core: initialized pinctrl subsystem
NET: Registered protocol family 16
DMA: preallocated 256 KiB pool for atomic coherent allocations
cpuidle: using governor menu
hw-breakpoint: found 5 (+1 reserved) breakpoint and 1 watchpoint registers.
hw-breakpoint: maximum watchpoint size is 4 bytes.
zynq-ocm f800c000.ocmc: ZYNQ OCM pool: 256 KiB @ 0x(ptrval)
zynq-pinctrl 700.pinctrl: zynq pinctrl initialized
e0001000.serial: ttyPS0 at MMIO 0xe0001000 (irq = 26, base_baud = 3125000) is a xuartps
`¬ËתLed
console [ttyPS0] enabled
bootconsole [earlycon0] disabled
bootconsole [earlycon0] disabled
GPIO IRQ not connected
XGpio: gpio@41200000: registered, base is 1020
GPIO IRQ not connected
XGpio: gpio@41210000: registered, base is 1016
vgaarb: loaded
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
media: Linux media interface: v0.10
videodev: Linux video capture interface: v2.00
pps_core: LinuxPPS API ver. 1 registered
pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
PTP clock support registered
EDAC MC: Ver: 3.0.0
FPGA manager framework
Advanced Linux Sound Architecture Driver Initialized.
clocksource: Switched to clocksource arm_global_timer
NET: Registered protocol family 2
tcp_listen_portaddr_hash hash table entries: 512 (order: 0, 6144 bytes)
TCP established hash table entries: 4096 (order: 2, 16384 bytes)
TCP bind hash table entries: 4096 (order: 3, 32768 bytes)
TCP: Hash tables configured (established 4096 bind 4096)
UDP hash table entries: 256 (order: 1, 8192 bytes)
UDP-Lite hash table entries: 256 (order: 1, 8192 bytes)
NET: Registered protocol family 1
RPC: Registered named UNIX socket transport module.
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
hw perfevents: no interrupt-affinity property for /pmu@f8891000, guessing.
hw perfevents: enabled with armv7_cortex_a9 PMU driver, 7 counters available
workingset: timestamp_bits=30 max_order=17 bucket_order=0
jffs2: version 2.2. (NAND) (SUMMARY)  © 2001-2006 Red Hat, Inc.
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
io scheduler mq-deadline registered
io scheduler kyber registered
dma-pl330 f8003000.dmac: Loaded driver for PL330 DMAC-241330
dma-pl330 f8003000.dmac:     DBUFF-128x8bytes Num_Chans-8 Num_Peri-4 Num_Events-16

 

Link to comment
Share on other sites

On 1/8/2021 at 11:05 AM, Ionel said:

Hi @meghuiyer@gmail.com Does it boot if you comment all pcam related nodes in your device tree?

I am not sure if this is right way of doing, I tried this command and ran the boot image. It works now, but I cant really have image displaying on the screen

petalinux-package --boot --force --fsbl ./images/linux/zynqmp_fsbl.elf --fpga ./images/linux/system.bit --u-boot

Log file

Failed to enumerate /dev/media0 (-2)

 

 

Link to comment
Share on other sites

 

11 minutes ago, Ionel said:

Hi @meghuiyer@gmail.com Does it boot if you comment all pcam related nodes in your device tree?

Hi, It does boot and when I check media-ctl -p or media-ctl -V

it says no such command is found. I have enabled the V4L2, Yavta, media-ctl packages, opencv package in the root file system. I have also enabled the drivers for mipi subsystem , i2c controller and ov5640 in the kernel.

Link to comment
Share on other sites

Hello

I need help building the device tree for the Pcam 5c camera and FMC with a zedboard. I am trying to create linux application using zedboard with fmc and PCAM 5c

 Do you  have any idea what to do? this is my device tree, could anyone check on this.

Issue: generates the petalinux project successfully but I do have a problem running the boot image and it says kernel panic (attached log files).

Another question : do I need to include the FMC configuration part during the configuration of the kernel?

&mipi_csi2_rx_subsyst_0{
xlnx,vc = <0x4>;
csiss_ports: ports {
#address-cells = <1>;
#size-cells = <0>;
csiss_port0: port@0 {
reg = <0>;
xlnx,video-format = <0>;
xlnx,video-width = <8>;
mipi_csi2_rx_0_to_demosaic_0: endpoint {
remote-endpoint = <&demosaic_0_from_mipi_csi2_rx_0>;
};
};
csiss_port1: port@1 {
reg = <1>;
xlnx,video-format = <0>;
xlnx,video-width = <8>;
csiss_in: endpoint {
data-lanes = <1 2>;
remote-endpoint = <&ov5640_to_mipi_csi2>;
};v
};
};
};
&v_demosaic_0 {
compatible = "xlnx,v-demosaic";
reset-gpios =<&gpio 86 GPIO_ACTIVE_LOW>;
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
xlnx,video-width = <8>;
demosaic_0_from_mipi_csi2_rx_0: endpoint {
remote-endpoint = <&mipi_csi2_rx_0_to_demosaic_0>;
};
};
port@1 {
reg = <1>;
xlnx,video-width = <8>;
demosaic_0_tov_fb: endpoint {
remote-endpoint = <&vcap_in>;
};
};
};
};

&mipi_csi2_rx_subsyst_1{
xlnx,vc = <0x4>;
csiss_ports: ports {
#address-cells = <1>;
#size-cells = <0>;
csiss_port0: port@0 {
reg = <0>;
xlnx,video-format = <0>;
xlnx,video-width = <8>;
mipi_csi2_rx_1_to_demosaic_1: endpoint {
remote-endpoint = <&demosaic_1_from_mipi_csi2_rx_1>;
};
};
csiss_port1: port@1 {
reg = <1>;
xlnx,video-format = <0>;
xlnx,video-width = <8>;
csiss_in: endpoint {
data-lanes = <1 2>;
remote-endpoint = <&ov5640_to_mipi_csi2>;
};
};
};
};
&v_demosaic_1 {
compatible = "xlnx,v-demosaic";
reset-gpios =<&gpio 86 GPIO_ACTIVE_LOW>;
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
xlnx,video-width = <8>;
demosaic_1_from_mipi_csi2_rx_1: endpoint {
remote-endpoint = <&mipi_csi2_rx_1_to_demosaic_1>;
};
};
port@1 {
reg = <1>;
xlnx,video-width = <8>;
demosaic_0_to_fb: endpoint {
remote-endpoint = <&vcap_in>;
};
};
};
};

&mipi_csi2_rx_subsyst_2{
xlnx,vc = <0x4>;
csiss_ports: ports {
#address-cells = <1>;
#size-cells = <0>;
csiss_port0: port@0 {
reg = <0>;
xlnx,video-format = <0>;
xlnx,video-width = <8>;
mipi_csi2_rx_2_to_demosaic_2: endpoint {
remote-endpoint = <&demosaic_2_from_mipi_csi2_rx_2>;
};
};
csiss_port1: port@1 {
reg = <1>;
xlnx,video-format = <0>;
xlnx,video-width = <8>;
csiss_in: endpoint {
data-lanes = <1 2>;
remote-endpoint = <&ov5640_to_mipi_csi2>;
};
};
};
};
&v_demosaic_2 {
compatible = "xlnx,v-demosaic";
reset-gpios =<&gpio 86 GPIO_ACTIVE_LOW>;
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
xlnx,video-width = <8>;
demosaic_2_from_mipi_csi2_rx_2: endpoint {
remote-endpoint = <&mipi_csi2_rx_2_to_demosaic_2>;
};
};
port@1 {
reg = <1>;
xlnx,video-width = <8>;
demosaic_2_to_fb: endpoint {
remote-endpoint = <&vcap_in>;
};
};
};
};

&mipi_csi2_rx_subsyst_3{
xlnx,vc = <0x4>;
csiss_ports: ports {
#address-cells = <1>;
#size-cells = <0>;
csiss_port0: port@0 {
reg = <0>;
xlnx,video-format = <0>;
xlnx,video-width = <8>;
mipi_csi2_rx_3_to_demosaic_3: endpoint {
remote-endpoint = <&demosaic_3_from_mipi_csi2_rx_3>;
};
};
csiss_port1: port@1 {
reg = <1>;
xlnx,video-format = <0>;
xlnx,video-width = <8>;
csiss_in: endpoint {
data-lanes = <1 2>;
remote-endpoint = <&ov5640_to_mipi_csi2>;
};_
};
};
};
&v_demosaic_3 {
compatible = "xlnx,v-demosaic";
reset-gpios =<&gpio 86 GPIO_ACTIVE_LOW>;
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
xlnx,video-width = <8>;
demosaic_3_from_mipi_csi2_rx_3: endpoint {
remote-endpoint = <&mipi_csi2_rx_3_to_demosaic_3>;
};
};
port@1 {
reg = <1>;
xlnx,video-width = <8>;
demosaic_0_to_fb: endpoint {
remote-endpoint = <&vcap_in>;
};
};
};
};

 

putty(not bootong).log putty(07012021).log (No FMC)putty.log

Link to comment
Share on other sites

There seams to be a misunderstanding either on my part or on yours. To clarify things here is what I understand so far:

You recently switched to Ubuntu 18.04 LTE on the PC (host) and you noticed that the console is  not working, you tried to create a helloworld project in standalone mode (aka bare-metal) for your Zedboard (target) but for some reason its not working. The part which I don't understand  is this image , judging by it the console it's outputting a kernel panic of a Linux boot sequence on the target. This means that you are booting from the SDcard on which you have a embedded Linux setup for the Zedboard. Because you are seeing an output in the terminal it means that the USB-UART is active, which tells me that your UART is working properly (host is set up correctly and the target it sending stuff over the UART). Due to the kernel panic the boot process is interrupted in the kernel space, and is hanging there, before it can hand off the control to the rootfs (user space), this means that you can't run write_led 0xff. write_led, as far as I can tell, is an application which has been packaged in the Zedboard rootfs. If you are booting form the SDcard the JTAG chain will not have limited access to the Zynq, which means you can reprogram the FPGA but I don't think it will allow you to load a new .elf in the processor. Therefore the helloworld will not work properly, thus not sending anything to the UART.

I don't know why you have the kernel panic on the target. But I would like to ask you to use the board in JTAG mode if you are trying to run a bare-metal application on it.

-Ciprian

 

Link to comment
Share on other sites

yes, My target is to use FMC with PCAM cameras for image processing application. Initially I started to use windows and made the fmc card work using the sample code.

later when i switched from windows to ubuntu 18.04 LTE. I am trying to run hello world having linux as OS.

I cant really see ''hello world '' on serial terminal.

also I tried checking using putty write_led 0xff, even this doesn't work. I see that SDCARD image is booting till gpios part or before SCSI part... I dont understand what is the main issue for not having a communication with the zedboard.

 

meghana

 

 

Link to comment
Share on other sites

I must have missed a post, but how did you get from a simple helloworld in bare-metal to booting Linux on the Zedboard?

The crash you sent us in this post is, as far as I can see, a kernel panic from a Linux boot on the Zedboard, write_led 0xff is also a application in Linux developed by Avnet. Are you trying to run helloworld on a target which has Linux on it? Do you want to use the FMC Pcam while running Linux on the Zedboard?

-Ciprian

Link to comment
Share on other sites

Hi

I am using ''PUTTY'' and ''SDK serial Terminal''

settings are Serial line to connect to - /dev/ttyACM0

speed - 115200, data bits - 1, stop bits- 1, Parity and Flow control are none.

this connection works fine, but then I cant really run write_led 0xff  command. It says try ''help''. I have no issues when it comes to windows. the image from SDCARD reads completely.

 

thanks

Link to comment
Share on other sites

So cable drivers must be installed if you can program the FPGA. As to why you cannot run Hello world, check the logs for clues on whether elf download succeeds and could even try debug to see where the processor is stuck at.

SDK terminal show a crash of some sort.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...