Boot issue with VxWorks on TE0715/TE0701

[Chris12]

Hello,
I'm trying to boot a VxWorks kernel on TE0715, but it's not loading...
I'm using FSBL and u-boot from Trenz Reference Design (2018.3) - https://shop.trenz-electronic.de/en/Download/?path=Trenz_Electronic/Modules_and_Module_Carriers/4x5/TE0715/Reference_Design/2018.3

I had no issue doing this on TE0808 so i'm wondering if there is anything specific on TE0715 which could prevent the kernel from loading. The crash seems to happen very early in the boot process, even before loading the device tree...

Any clue would be much appreciated,
thanks!

[JH]

Hi,

can you send me the boot log? Maybe I can find something.

Bu I haven't any experience with VxWorks, so I can't help much more.

Maybe you should also check:
https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18842063/VxWorks
https://www.xilinx.com/support/documentation/application_notes/xapp1158-zynq-7000-vxworks-bsp.pdf

br
John

[Chris12]

Thanks, i'll check these links.

The boot log doesn't say much, here is what I get:

Zynq> tftpb 0x5000000 uVxWorks && tftpb 0x4000000 zynq-test.dtb && bootm 0x5000000 - 0x4000000
Using ethernet@e000b000 device
TFTP from server 172.16.0.42; our IP address is 172.16.0.30
Filename 'uVxWorks'.
Load address: 0x5000000
Loading: #################################################################
         #################################################################
         ##############################
         566.4 KiB/s
done
Bytes transferred = 2342628 (23bee4 hex)
Using ethernet@e000b000 device
TFTP from server 172.16.0.42; our IP address is 172.16.0.30
Filename 'zynq-zc702.dtb'.
Load address: 0x4000000
Loading: #
         268.6 KiB/s
done
Bytes transferred = 3576 (df8 hex)
## Booting kernel from Legacy Image at 05000000 ...
   Image Name:   vxWorks
   Image Type:   ARM VxWorks Kernel Image (uncompressed)
   Data Size:    2342564 Bytes = 2.2 MiB
   Load Address: 00200000
   Entry Point:  00200000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 04000000
   Booting using the fdt blob at 0x4000000
   Loading Kernel Image ... OK
   Loading Device Tree to 07ffc000, end 07fffdf7 ... OK
## Starting vxWorks at 0x00200000, device tree at 0x07ffc000 ...

[JH]

Hi,
how did you generate the device tree dtb file? Is the content correct for your TE0715 configuration?

did you check that part of Linux is not overwrite by device tree:
Linux load address        : 0x0020 0000
Device tree load address: 0x007ff c000

br
John

[Chris12]

I'm using a custom device tree based on a Xilinx ZC702 board. I removed what was not required to keep only the key SoC configuration.
The exact same kernel/dtb works on many other hardware (similar SoC, different board)

But the thing is that I don't think that the DTB is the root cause.
It seems to fail very early in the boot process, I don't have a single log, even with all debug options activated in the kernel.
Actually, it doesn't even enter the CPU initialization phase.
That's why I'm trying to understand what could cause this and if there is some hardware config on this board that would require specific customization on VxWorks side

I also tried booting directly, without uboot (just FSBL + vxworks), and also with the DTB embedded in the kernel. same result.

Thanks

[JH]

Hi,
device tree depends on the activated interface in the Vivado Zynq IP. The exported HDF  of this vivado project is use this configuration to generate FSBL and linux.

If you use definition from other configuration, it can happens everything. Maybe your other eval board has similar configuration like ZC702. Did you select correct DDR size in your device tree?

The parts we have changed manually in the device tree are explained here:
https://wiki.trenz-electronic.de/display/PD/TE0720+Test+Board#TE0720TestBoard-SoftwareDesign-PetaLinux

dtb can be converted back into readable format

https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18842279/Build+Device+Tree+Blob

Our complete device tree is include in the image.ub. I think you could extract but I never test it. Maybe a easer way is to generate one time the petalinux project with our petalinux template and the provide HDF for your assembly variant. The generated dtb is included in the image folder of the generate petalinux project and you can convert back to dts.

br
John

[Chris12]

Hi John,
The issue is now solved.
I was looking in the wrong direction: the kernel is working fine, but I couldn't get any log due to incorrect uart configuration.
Without any log output, I focused my research on a boot issue instead of comm issue.
Thanks for your support!

[JH]

Hi,
thanks for feedback and good to hear that it works.

br
John

[dswiger22]

Sorry to post 2 years later, but I'm having a similar problem as Chris12... I hope you're still around to provide more details.  To summarize my problem, I've got a "known working Trenz board" (TE0706-03 baseboard and TE0715 module) that we've been booting Linux on for several years.  I'm trying to do a VxWorks build with the latest VxWorks tools (VxWorks 7, version 21.11) and am having no luck getting anything out of the console after U-Boot identifies the VxWorks kernel and DTB.  In my past experience (with VxWorks running on other processors), I usually see a large list of initializations ending with the VxWorks ASCII-Art logo, and a '->' prompt.  However, here's all I get with the current setup (the files are read from SD card to memory, then a "bootm" command, pointing at the two memory areas):

Code: [Select]

Zynq> boot
reading uVxWorks
12420356 bytes read in 657 ms (18 MiB/s)
reading zynq-zc706.dtb
4930 bytes read in 16 ms (300.8 KiB/s)
## Booting kernel from Legacy Image at 00300000 ...
   Image Name:   vxworks
   Image Type:   ARM VxWorks Kernel Image (uncompressed)
   Data Size:    12420292 Bytes = 11.8 MiB
   Load Address: 00200000
   Entry Point:  00200000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 00100000
   Booting using the fdt blob at 0x100000
   Loading Kernel Image ... OK
   Loading Device Tree to 1f314000, end 1f318341 ... OK
## Starting vxWorks at 0x00200000, device tree at 0x1f314000 ...
<nothing more>
If you're still around Chris12 and can share what your boot log looked like after you fixed the UART issue, that might be very helpful.  Also a clue as to what you changed your UART configuration to might be helpful.

For our problem, I've tried several modifications of the WindRiver provided DTS files to no avail (note above I used a zynq-zc706.dts file, but I also tried zynq-zc702.dts).  I've also tried to  use the exact same DTS files we're currently using for our Linux build.  While VxWorks tools complain a little (provide tool warnings about the DTS files) they don't indicate that the image should not run.  I feel like this is a UART configuration issue, but haven't landed on the change to make yet.

Thanks for any help!

[JH]

Hi,
I think you must use the the device tree which describes your TE0715 setup. Otherwhise you has annother HW description. Zynq is a configurable system. Each changes on PS or PS-PL (AXI Addresses or CLKs) need mostly other devicetree or some changes on it.
Start for example with our reference design and generate petalinux with our template.
br
John

[dswiger22]

Thanks for the suggestion.  We have been compiling our VxWorks with a DTS file from the known working Linux build, but that hasn't worked for us.  We've even tried stripping down the working DTS file to a "bare minimum" with just the single uart0 and a few other items, with the thought that we have one item described in the DTS that is keeping the software from running or providing text to the console.  That didn't work either.

We'll give it a go with the petalinux boot to see if we can get that to work.  Interestingly, we have already downloaded that build environment and created a pseudo-working U-Boot instance from that. I say pseudo-working because it can boot our existing Linux image, but some of the apps that we run on that Linux image crash.  However, our VxWorks build does not run from the petalinux built U-Boot either.  I would assume that if we get the petalinux image to run, we should be able to use the DTS for that to build our VxWorks image and it should then run.  At least that is my hope.

Thanks again for the suggestion, I really appreciate it.

Dan

[JH]

Hi,
dts is different on every Zynq system. It depends on connected HW and PS-IP configuration. Generated FSBL, Devices tree... everything belongs together. Make sure that all was created from the same XSA file(definition of your PS setup and AXI PL Periphery).
 br
John

[dswiger22]

John,

Thanks for the continued attempts to help me out.  I ended up figuring out my problem.  It was that I was trying to load the DTB in an area of memory not recognized by the "Early MMU" that VxWorks had set up.  I'm not sure if that is a limitation in VxWorks, or just a configuration that I had set wrong.  Regardless, after changing my 'vxboot' parameter below to load the DTB below 0x01d00000, VxWorks started to provide some of its output to the console.  It was at that point that I could start figuring out my DTS problems and other configuration problems keeping it from fully booting.  One big thing that someone bringing up a new VxWorks BSP should be aware of (with Version 21.11 or newer) is that WindRiver has drastically increased security lockdown of their base configuration.  Unless you pick a "Development" profile when starting your VSB project, the shell is disabled by default (one of the hurdles I had to overcome).  For posterity, and in case it helps some future developer, here's what my current boot sequence looks like.  Note that this is more than the bare minimum configuration; I've added a ramfs (/ram0) and enabled ssh which added its own ramfs (/ram).  I also included in the boot sequence a few 'printenv' command results showing the U-Boot environment parameters I needed to boot VxWorks on my platform, and added a few editorial comments {encased in curly braces} to explain the parts of the boot:

Code: [Select]

U-Boot 2016.01 (Nov 19 2019 - 12:51:36 -0500)

Model: Trenz Zynq 7000 Development Board
Board: Xilinx Zynq
DRAM:  ECC disabled 512 MiB
MMC:   sdhci@e0100000: 0
SF: Detected S25FL256S_64K with page size 256 Bytes, erase size 64 KiB, total 32 MiB
In:    serial@e0000000
Out:   serial@e0000000
Err:   serial@e0000000
Model: Trenz Zynq 7000 Development Board
Board: Xilinx Zynq
Net:   ZYNQ GEM: e000b000, phyaddr 0, interface rgmii-id
eth0: ethernet@e000b000
Hit any key to stop autoboot:  0

{ BOOT PARAMETERS FOR VXWORKS }

Zynq> printenv modeboot
modeboot=vxboot
Zynq> printenv bootcmd
bootcmd=run $modeboot
Zynq> printenv bootargs
## Error: "bootargs" not defined
Zynq> printenv vxboot
vxboot=load mmc 0 0x00300000 uVxWorks;load mmc 0 0x01cff700 my-trenz.dtb;bootm 0x00300000 - 0x01cff700
Zynq> boot

{ START OF BOOT FROM U-BOOT PERSPECTIVE }

reading uVxWorks
15896340 bytes read in 841 ms (18 MiB/s)
reading my-trenz.dtb
4946 bytes read in 16 ms (301.8 KiB/s)
## Booting kernel from Legacy Image at 00300000 ...
   Image Name:   vxworks
   Image Type:   ARM VxWorks Kernel Image (uncompressed)
   Data Size:    15896276 Bytes = 15.2 MiB
   Load Address: 00200000
   Entry Point:  00200000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 01cff700
   Booting using the fdt blob at 0x1cff700
   Loading Kernel Image ... OK
   Loading Device Tree to 1f314000, end 1f318351 ... OK
## Starting vxWorks at 0x00200000, device tree at 0x1f314000 ...

{ HANDOFF TO VXWORKS }

protecting primary core interrupt stack
protecting root task stacks
initialize VxBus
        install bus types:
                vxbIeee1588Bus(IEEE1588 bus type)
                vxbSdMmcBus(SdMmc bus type)
                vxbMiiBus(MII bus type)
                vxbFdtBus(Flattened Device Tree bus type)
                vxbNexusBus(Nexus bus type)
        probe and attach devices
protecting non-primary core interrupt stacks
Instantiating /ram0 as rawFs,  device = 0x1
 
 _________            _________
 \........\          /......../
  \........\        /......../
   \........\      /......../
    \........\    /......../
     \........\   \......./
      \........\   \...../              VxWorks SMP 32-bit
       \........\   \.../
        \........\   \./     Release version: 21.11
         \........\   -      Build date: Feb  8 2022 16:00:22
          \........\
           \......./         Copyright Wind River Systems, Inc.
            \...../   -                 1984-2022
             \.../   /.\
              \./   /...\
               -   -------
 
                   Board: Trenz Zynq 7000 Development Board
               CPU Count: 2
          OS Memory Size: 511MB
        ED&R Policy Mode: Permanently Deployed
 
Instantiating /ram as rawFs,  device = 0x10001
Formatting /ram for DOSFS
Instantiating /ram as rawFs, device = 0x10001
Formatting...Retrieved old volume params with %38 confidence:
Volume Parameters: FAT type: FAT32, sectors per cluster 0
  0 FAT copies, 0 clusters, 0 sectors per FAT
  Sectors reserved 0, hidden 0, FAT sectors 0
  Root dir entries 0, sysId (null)  , serial number a0000
  Label:"           " ...
Disk with 1024 sectors of 512 bytes will be formatted with:
Volume Parameters: FAT type: FAT12, sectors per cluster 1
  2 FAT copies, 1010 clusters, 3 sectors per FAT
  Sectors reserved 1, hidden 0, FAT sectors 6
  Root dir entries 112, sysId VXDOS12 , serial number a0000
  Label:"           " ...
OK.
 
Adding 13518 symbols for standalone.
 
->
Good luck,

Dan

[JH]

Hi Dan,
good to hear that you solve the problem and thanks for sharing this information.
br
John