[meta-xilinx] Xilinx SDK toolchain

[Edward Wingate]

I've been using a jethro build on a Zynq-7000 system.  When I
create/build a Linux Application hello world project on Xilinx SDK
2016.3 and try executing it, I get "-sh: ./test.elf: No such file or
directory".   I think this is because of a toolchain or rootfs library
mismatch between the Xilinx SDK and the Linux distro.  The Xilinx SDK
is currently using toolchain "Xilinx ARM v7 GNU/Linux Toolchain"

How would I set up the Xilinx SDK to be able to use the proper
toolchain or libraries? I am running Xilinx SDK on a Windows7 machine,
while the jethro Yocto build is running on a Ubuntu Linux machine.  Do
I need to point the Xilinx SDK to something that Yocto produces on the
Linux machine?

Thanks for your help.

Ed
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] Zynq TTC usage by Linux

[Edward Wingate]

On Tue, Oct 25, 2016 at 12:01 AM, Mike Looijmans
 wrote:
> Usually the term "real time" is applied to too many things. For example,
> your desktop PC experiences latencies of over 1 ms for typical interrupts,
> but it still functions fine when running various audio and video
> applications that have real-time requirements far below that. The trick is
> to go from "you must read a sample from the ADC 44100 times per second" to
> "the DMA extracts samples at 44100 Hz and you must copy the data from the
> DMA buffer at least once per second".

So one way is to set up some buffers in DDR RAM for the PL to write to
and then, based on perhaps an FPGA interrupt, Linux would go and read
those buffers?  In this case, the buffers in RAM would have to be
marked by Linux as uncached, is that correct?  Would this be
accomplished via the device tree?

Or would there be a DMA controller in the PL and Linux goes through
that instead of directly to RAM?

Thanks so much for this, Mike.  I'm learning a lot.


> On the Zynq, I move the hard real time tasks to the FPGA where they belong.
> Even in AMP mode, the CPU isn't actually a real-time system, because it will
> still have to compete with other periferals (and the other CPU) for memory
> bandwidth and other resources. It's still possible to have something on the
> system cause the 'realtime' CPU to stall for an inderterminate time.
>
> Linux running on the ARM cores, without any RT patch, is perfectly capable
> of handling say 10,000 interrupts per second reliably. So even if you decide
> to run a motor control loop on the CPU, that'll work just fine.
>
>
>
> Kind regards,
>
> Mike Looijmans
> System Expert
>
> TOPIC Products
> Materiaalweg 4, NL-5681 RJ Best
> Postbus 440, NL-5680 AK Best
> Telefoon: +31 (0) 499 33 69 79
> E-mail: mike.looijm...@topicproducts.com
> Website: www.topicproducts.com
>
>
>
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] Zynq TTC usage by Linux

[Edward Wingate]

On Fri, Oct 21, 2016 at 12:26 AM, Nathan Rossi  wrote:
> This is informing that the ttc device is probed and setup as a
> clocksource device. Althought it is probably not used.
> You can also check to see what is currently in use: cat
> /sys/devices/system/clocksource/clocksource0/current_clocksource

Fortunately, my kernel is using the arm global timer.

> I could be mistaken but remoteproc should be able to unregister the
> clocksource from the kernel and provide it to the remoteproc
> application?

Is this capability built in already? Are there parameters I need to
somehow specify during modprobe?  Or do I need to modify
zynq_remoteproc driver?  I couldn't find any documentation about this.

> If not invalidating it in the linux kernel device tree should be fine.

Yep, it's working with this.  Thanks!
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] Zynq TTC usage by Linux

[Edward Wingate]

It looks like Linux is aware of TTC0 at least, from dmesg:
clocksource: ttc_clocksource: mask: 0x max_cycles: 0x,
max_idle_ns: 537538477 ns
ps7-ttc #0 at 9e808000, irq=18

And it is allocated with virtual memory mapping (/proc/vmallocinfo):
0x9e808000-0x9e80a0008192 of_iomap+0x2c/0x34 phys=f8001000 ioremap

I can disable it in my device tree with:
ps7_ttc_0: ps7-ttc@f8001000 { compatible = "invalid"; }

Does anyone know what TTC0 would be used for?  Doesn't seem to be
critical as Linux stills boots and runs OK.  Thanks for your help.




On Thu, Oct 20, 2016 at 5:31 PM, Edward Wingate <edwinga...@gmail.com> wrote:
> Does Linux use the Zynq's triple timer counters (TTC0/1) for anything
> by default?  Running in AMP mode with Linux on CPU0, I'm trying to use
> TTC0/TTC1 from CPU1, but don't seem to be able to. I don't see the
> TTCs' address space in /proc/iomem though.  Thanks for any help.
>
> Ed
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] cross-compiling

[Edward Wingate]

Thanks Nathan and Mike, I just installed the SDK from Yocto and the
Linux executables it generates are working fine.


On Tue, Oct 11, 2016 at 12:31 AM, Nathan Rossi  wrote:
> On Tue, Oct 11, 2016 at 5:17 PM, Mike Looijmans  
> wrote:
>> I suspect one of your toolchains is using hard-float ABI and the other
>> soft-float. This will work fine if you don't exchange any floating-point
>> data.
>
> Xilinx changed their default toolchain provided by XSDK to arm hard
> float in a recent version (v2016.1?).
>
> As such meta-xilinx also switched (krogoth and newer) to defaulting to
> hard-float as there was no longer a need to default to soft-fp for
> compatibility. You can read a bit about it here:
>
> https://lists.yoctoproject.org/pipermail/meta-xilinx/2016-February/001466.html
>
>>
>> The solution is to use the same toolchain for everything. Don't use the
>> Yocto toolchain for the rootfs and then the Xilinx toolchain for an
>> executable.
>
> This is definitely recommended, you can build an "SDK" with Yocto if
> you need the toolchain for standalone development.
>
> Some reference links:
> http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#cross-development-toolchain-generation
> http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#sdk-dev-environment
>
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

[meta-xilinx] cross-compiling

[Edward Wingate]

I cross-compiled an application to run on Linux on the Zynq-7020.
Trying to execute it gives "No such file or directory" error.

# file app_hello.elf
app_hello.elf: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV),
dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for
GNU/Linux 4.4.0,
BuildID[sha1]=06498863e79d3eabe670610b2cbb0440272f047e, not stripped

I don't have /lib/ld-linux-armhf.so.3, but I do have
/lib/ld-linux.so.3.  I symlinked ld-linux-armhf.so.3 to ld-linux.so.3
and my application runs fine now.

Where did things go wrong?  Is my Yocto build not properly creating
ld-linux-armhf.so.3?  Or is my application cross-compilation using the
wrong ld-linux?  I'm using Xilinx SDK 2016.2 to cross-compile the
Linux application.

Thanks for any help.

Ed
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

[meta-xilinx] Xilinx SDK projects in Yocto

[Edward Wingate]

Is it possible to use Yocto to compile a Xilinx SDK project?  Would I
use the Linux version of Xilinx SDK, or could/would I use some other
toolchain that's more command-line oriented?  Could I furthermore
build a BOOT.BIN from, say, a Xilinx SDK-based FSBL and a Yocto
generated u-boot.elf?  Can anyone point me to or provide example
recipes that accomplish some of these things?  Thanks for any help.
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] Help with ethernet0 device tree node

[Edward Wingate]

On Mon, Aug 29, 2016 at 3:52 PM, Edward Wingate <edwinga...@gmail.com> wrote:
> So it turns out the application I'm running on CPU1 was interfering
> with Linux on CPU0.

And apologies for not mentioning my running in an AMP configuration,
but it did not seem related at the time.
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] Help with ethernet0 device tree node

[Edward Wingate]

So it turns out the application I'm running on CPU1 was interfering
with Linux on CPU0.  My application on CPU1 uses eth1/gem1 and Linux
on CPU0 uses eth0/gem0.

The CPU1 application performs this sequence of register writes to set
the GEM1 divisor values during initialization:

*(volatile unsigned int *)(SLCR_UNLOCK_ADDR) = SLCR_UNLOCK_KEY_VALUE;
*(volatile unsigned int *)(SLCR_GEM1_CLK_CTRL_ADDR) = SOME_VALUE;
*(volatile unsigned int *)(SLCR_LOCK_ADDR) = SLCR_LOCK_KEY_VALUE;

The third line is (re)locking the SCLR registers and it is my
conjecture that doing this somehow interferes with Linux's eth0
operation because by not performing the locking (commenting out that
line in my CPU1 application), Linux is able to successfully change the
eth0 speed.  Conjecturing further, it seems like Linux keeps the SLCR
registers unlocked and assumes they remain so.  It should probably
check the SLCR_LOCKSTA register for the lock status and unlock if
necessary.  I tried to find in the kernel where this would occur, but
got lost in the kernel driver code.



On Thu, Aug 11, 2016 at 4:41 AM, Nathan Rossi <nat...@nathanrossi.com> wrote:
> On Wed, Aug 10, 2016 at 7:29 AM, Edward Wingate <edwinga...@gmail.com> wrote:
>> Nathan,
>>
>> May I ask where your gem0 clock is sourced from?
>> My gem0 clock is sourced from iopll and my clock tree looks like this:
>>
>> ps_clk
>>  iopll_int
>> iopll
>>gem0_mux
>>   gem0_div0
>>  gem0_div1
>> gem0_emio_mux
>>gem0
>>  armpll_int
>> armpll
>>cpu_mux
>>   cpu_div
>>  cpu_1x_div
>> cpu_1x
>>gem0_aper
>>
>> I'm wondering if the gem0_emio_mux before gem0 is the issue (I'm not
>> going through EMIO).
>
> The "gem0_emio_mux" refers to the fact that the gem unlike other
> peripherals can mux their clock source from EMIO, it simply represents
> the MSB of the SRCSEL section of the GEM*_CLK_CTRL register in the
> SLCR. The kernel just implements it as two muxes (just like the MIO
> muxes for e.g. the can peripherals). The important part is the tree is
> sourced from the iopll <- ps_clk.
>
> The clk tree on the zybo looks similar:
>
>clock enable_cnt  prepare_cntrate
> accuracy   phase
>
>  ps_clk   335000
>0 0
> iopll_int 11  10
>0 0
>iopll  88  10
>0 0
>   gem1_mux00  10
>0 0
>  gem1_div0001667
>0 0
> gem1_div1 001667
>0 0
>gem1_emio_mux   001667
> 0 0
>   gem1001667
>0 0
>   gem0_mux11  10
>0 0
>  gem0_div011  10
>0 0
> gem0_div1 11   12500
>0 0
>gem0_emio_mux   11   12500
> 0 0
>   gem011   12500
>0 0
>
> armpll_int11  13
>0 0
>armpll 22  13
>0 0
>   cpu_mux 11  13
>0 0
>  cpu_div  33   65000
>0 0
> cpu_1x_div11   10833
>0 0
>cpu_1x10   10   10833
>0 0
>   gem1_aper   00   10833
>0 0
>   gem0_aper   22   10833
>0 0
>
> And when linked at 100M/25MHz
>
>   gem0_mux11  10
>0 0
>  gem0_div011  10
>0 0
> gem0_div1 112500
>0 0
>gem0_emio_mux   112500
> 0 0
>   gem0112500
>0 0
>
>>
>> Also, my p

Re: [meta-xilinx] Help with ethernet0 device tree node

[Edward Wingate]

Nathan,

May I ask where your gem0 clock is sourced from?
My gem0 clock is sourced from iopll and my clock tree looks like this:

ps_clk
 iopll_int
iopll
   gem0_mux
  gem0_div0
 gem0_div1
gem0_emio_mux
   gem0
 armpll_int
armpll
   cpu_mux
  cpu_div
 cpu_1x_div
cpu_1x
   gem0_aper

I'm wondering if the gem0_emio_mux before gem0 is the issue (I'm not
going through EMIO).

Also, my ps7_ethernet0 node has this in it:
clock-names = "ref_clk", "aper_clk";
clocks = < 13>, < 30>;

The "30" in clocks is referring to gem0_aper, which looks out of place
in the clock tree (being under armpll instead of iopll).


On Mon, Aug 8, 2016 at 12:08 PM, Edward Wingate <edwinga...@gmail.com> wrote:
> On Sun, Jul 31, 2016 at 6:26 AM, Nathan Rossi <nat...@nathanrossi.com> wrote:
>>
>> I tested this with both the emacps and the macb driver (linux-xlnx
>> kernel v2016.2, on a ZYBO). Both advertise and link correctly with a
>> 100M switch and forced advert 100M with a 1G switch, and packets are
>> transmitted and received correctly.
>
> Appreciate the confirmation, Nathan.
>
>> If you are having issues with this before diving into the board/hw/etc
>> testing double check your clock setup (and that it is propagated to
>> FSBL/SPL correctly), and/or EMIO setup if you are routing through PL.
>
> I'll be doing so in coming days.  But despite the initial clock setup
> from FSBL, won't Linux mess with the registers during boot and
> ethernet initialization?  I wonder, can I change the link speed while
> in u-boot to see if it works there?  I'm tftping in u-boot
> successfully, probably at 1Gbps.
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] Help with ethernet0 device tree node

[Edward Wingate]

On Sun, Jul 31, 2016 at 6:26 AM, Nathan Rossi  wrote:
>
> I tested this with both the emacps and the macb driver (linux-xlnx
> kernel v2016.2, on a ZYBO). Both advertise and link correctly with a
> 100M switch and forced advert 100M with a 1G switch, and packets are
> transmitted and received correctly.

Appreciate the confirmation, Nathan.

> If you are having issues with this before diving into the board/hw/etc
> testing double check your clock setup (and that it is propagated to
> FSBL/SPL correctly), and/or EMIO setup if you are routing through PL.

I'll be doing so in coming days.  But despite the initial clock setup
from FSBL, won't Linux mess with the registers during boot and
ethernet initialization?  I wonder, can I change the link speed while
in u-boot to see if it works there?  I'm tftping in u-boot
successfully, probably at 1Gbps.
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

[meta-xilinx] Help with ethernet0 device tree node

[Edward Wingate]

My eth0 interface can only run at 1Gbps.  If I plug into a 100 Mbps
switch or use ethtool to set the link speed, it looks like it
succeeded:
xemacps e000b000.ps7-ethernet: link down
xemacps e000b000.ps7-ethernet: Set clk to 2500 Hz
xemacps e000b000.ps7-ethernet: link up (100/FULL)

But I can no longer communicate on the network.  Setting the link
speed back to 1Gbps fixes things.

I currently have this in my device tree for eth0:

 ps7_ethernet_0: ps7-ethernet@e000b000 {
phy-handle = <>;
phy-mode = "rgmii-id";
compatible = "xlnx,ps7-ethernet-1.00.a";
clock-names = "ref_clk", "aper_clk";
clocks = < 13>, < 30>;
xlnx,enet-slcr-1000mbps-div0 = <0xa>;
xlnx,enet-slcr-1000mbps-div1 = <0x1>;
xlnx,enet-slcr-100mbps-div0 = <0xa>;
xlnx,enet-slcr-100mbps-div1 = <0x5>;
xlnx,enet-slcr-10mbps-div0 = <0xa>;
xlnx,enet-slcr-10mbps-div1 = <0x32>;
xlnx,ptp-enet-clock = <5>;
mdio {
#address-cells = <1>;
#size-cells = <0>;
phy0: phy@0 {
compatible = "marvell,88e1510";
device_type = "ethernet-phy";
reg = <0>;
} ;
};
} ;

I got the ethernet0 device tree node from here (plus bits from
elsewhere that I have come across to try and get this to work):
http://www.wiki.xilinx.com/Zynq+Emacps+Linux+Driver

My ENET0 clock comes from the iopll.  My clock tree currently looks like this:

  ps_clk   33
0 0
 iopll_int 11   0
0 0
iopll 11   11   0
0 0
   gem0_mux11   0
0 0
  gem0_div011   0
0 0
 gem0_div1 11   12499
0 0
gem0_emio_mux   11   12499
 0 0
   gem011   12499
0 0

When I set the link speed to 100Mbps, the clock rate column for gem0
does not change from 125MHz. I think I do not have the clock set up
correctly for eth0.

Can anyone see what's missing or wrong?

Thank you for any help.
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

[meta-xilinx] PS I2C access by CPU1

[Edward Wingate]

I'm using Zynq 7020 AMP config with Linux on CPU0 and FreeRTOS on
CPU1.  ps7_i2c_0 is to be used by CPU1.  What is the proper device
tree setting to use for ps7_i2c_0 in this case?

1) ps7_i2c_0: ps7-i2c@e0004000 { compatible = "invalid"; };
or
2) ps7_i2c_0: ps7-i2c@e0004000 {
bus-id = <0>;
clocks = < 38>;
compatible = "cdns,i2c-r1p10", "xlnx,ps7-i2c-1.00.a";
interrupt-parent = <_scugic_0>;
interrupts = <0 25 4>;
reg = <0xe0004000 0x1000>;
i2c-clk = <40>;
#address-cells = <1>;
#size-cells = <0>;} ;

It seems if I use #1, the i2c port does not respond to CPU1, even
though I am using "clk_ignore_unused" kernel parameter to ensure i2c
clock is not disabled.

If I use #2, i2c port responds to CPU1, but then I would need to be
vigilant that nothing on Linux is trying to use that i2c port?

I am using #2 since #1 doesn't work, but is there a more proper way to
do this so that Linux/CPU0 doesn't have access to the i2c port?

Thanks for your help.

Ed
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

[meta-xilinx] linux-xlnx-dev.bb recipe

[Edward Wingate]

I've been using linux-xlnx-dev.bb recipe to compile a kernel with the following:
PREFERRED_PROVIDER_virtual/kernel = "linux-xlnx-dev"
SRCREV_pn-linux-xlnx-dev = "3be00480727bf360d912223026b789011b1e5251"

This was pointing to a 4.0 kernel.  Now, on a fresh build, I get
"unable to find revision" errors:

WARNING: Failed to fetch URL
git://github.com/Xilinx/linux-xlnx.git;protocol=https;branch=master-next,
attempting MIRRORS if available
ERROR: Fetcher failure: Unable to find revision
3be00480727bf360d912223026b789011b1e5251 in branch master-next even
from upstream
ERROR: Function failed: Fetcher failure for URL:
'git://github.com/Xilinx/linux-xlnx.git;protocol=https;branch=master-next'.
Unable to fetch URL from any source.

Can I still get to this kernel revision somehow?  Or was this revision
struck from the source tree?

Thanks,
Ed
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx