Re: [meta-xilinx] Zynq TTC usage by Linux
On 25-10-16 18:30, Edward Wingate wrote: 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? In general, the PL would include a DMA controller that writes to RAM directly, and the PS picks it up there (usually interrupt based, but can be timer or something else too). The IIO framework does this nicely for most ADC/DAC type chips. The kernel has all the smart cache handling stuff built-in, giving a choice of "coherent" or "streaming" memory on all platforms. It's so portable that I can use the same driver code for FPGA on a PCIe card in an x86 PC as for the Zynq. And if you connect to the ACP port instead of the HP port, you won't even have to handle the caching at all (less throughput for large chunks, but no cache management and the PL can write into the CPU cache giving a noticable performance boost in some cases). Maybe you should take a look at our Dyplo system that allows you to connect "whatever you have in logic as long as it produces and/or consumes data" together... 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 -- Mike Looijmans 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 Please consider the environment before printing this e-mail -- ___ meta-xilinx mailing list meta-xilinx@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-xilinx
Re: [meta-xilinx] Zynq TTC usage by Linux
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
On 25-10-16 08:39, Edward Wingate wrote: On Mon, Oct 24, 2016 at 11:16 PM, Mike Looijmans wrote: On 25-10-16 08:03, Edward Wingate wrote: Could you explain about how GPIO hogs eliminate dealing with race-condition prone registers? Which registers are prone to race conditions in the first place? For example, to enable the GPIO output mode on MIO pin 0, you'd have to do this in bare metal code: #define ZYNQ_GPIO_DIRM_00xE000A204 #define ZYNQ_GPIO_OEN_0 0xE000A208 unsigned int reg reg = ioread((ZYNQ_GPIO_DIRM_0 + 0)); iowrite(addr, (ZYNQ_GPIO_OEN_0 + 0) | 0x1); reg = ioread((ZYNQ_GPIO_DIRM_0 + 0)); iowrite(addr, (ZYNQ_GPIO_OEN_0 + 0) | 0x1); If between reading and writing the registers, the other CPU does something similar (e.g. enable output on MIO 1) the result will be undefined. Setting the GPIO value can be done race-free using the "MASK_DATA_0_LSW" register (writing 0xFFFE0001 to address 0xE000A000 will set GPIO 0 to "high" without interfering with the other CPU). Thanks for that, Mike. This is useful information I don't find anywhere else. PS: My generic advice would be to stay away from AMP as far as you possibly can. There's hardly any advantage over letting the Linux kernel handle things, and the disadvantages are plentiful. When you need real time control, do you forego Linux and use an RTOS exclusively? Or have you used some RT Linux? 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". 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 Please consider the environment before printing this e-mail -- ___ meta-xilinx mailing list meta-xilinx@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-xilinx
Re: [meta-xilinx] Zynq TTC usage by Linux
On Mon, Oct 24, 2016 at 11:16 PM, Mike Looijmans wrote: > On 25-10-16 08:03, Edward Wingate wrote: >> Could you explain about how GPIO hogs eliminate dealing with >> race-condition prone registers? Which registers are prone to race >> conditions in the first place? > > For example, to enable the GPIO output mode on MIO pin 0, you'd have to do > this in bare metal code: > > #define ZYNQ_GPIO_DIRM_00xE000A204 > #define ZYNQ_GPIO_OEN_0 0xE000A208 > unsigned int reg > reg = ioread((ZYNQ_GPIO_DIRM_0 + 0)); > iowrite(addr, (ZYNQ_GPIO_OEN_0 + 0) | 0x1); > reg = ioread((ZYNQ_GPIO_DIRM_0 + 0)); > iowrite(addr, (ZYNQ_GPIO_OEN_0 + 0) | 0x1); > > If between reading and writing the registers, the other CPU does something > similar (e.g. enable output on MIO 1) the result will be undefined. > > Setting the GPIO value can be done race-free using the "MASK_DATA_0_LSW" > register (writing 0xFFFE0001 to address 0xE000A000 will set GPIO 0 to "high" > without interfering with the other CPU). Thanks for that, Mike. This is useful information I don't find anywhere else. > PS: My generic advice would be to stay away from AMP as far as you possibly > can. There's hardly any advantage over letting the Linux kernel handle > things, and the disadvantages are plentiful. When you need real time control, do you forego Linux and use an RTOS exclusively? Or have you used some RT Linux? -- ___ meta-xilinx mailing list meta-xilinx@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-xilinx
Re: [meta-xilinx] Zynq TTC usage by Linux
On 25-10-16 08:03, Edward Wingate wrote: On Sat, Oct 22, 2016 at 3:06 AM, Mike Looijmans wrote: One of the TTCs used to be used for clock source. This should still be the case if you use dynamic clocks, because the ARM timer is fixed to the CPU speed and does not handle frequency changes (though I think it should be possible to fix this purely in software, no-one seems to care though). The TTC can use the prescaler to adjust the timing when the CPU speed changes. But if you use AMP, frequency scaling will affect both cores, so you probably cannot use it anyway. Thanks for this information, Mike. I'm probably not using dynamic clocks since I'm using both the global arm timer and AMP. In what cases are dynamic clocks used? Just for my information, how are they enabled? Enabling frequency scaling in the kernel will make the CPU clock switch between 333 and 666 MHz on demand. This results in considerable power saving, and is transparent to the system. For AMP, I assigned the TTC1 interrupts to the remoteproc. I also add GPIO "hogs" for all GPIO signals it uses. That way, the AMP firmware doesn't need to modify various race-condition prone registers. Could you explain about how GPIO hogs eliminate dealing with race-condition prone registers? Which registers are prone to race conditions in the first place? For example, to enable the GPIO output mode on MIO pin 0, you'd have to do this in bare metal code: #define ZYNQ_GPIO_DIRM_00xE000A204 #define ZYNQ_GPIO_OEN_0 0xE000A208 unsigned int reg reg = ioread((ZYNQ_GPIO_DIRM_0 + 0)); iowrite(addr, (ZYNQ_GPIO_OEN_0 + 0) | 0x1); reg = ioread((ZYNQ_GPIO_DIRM_0 + 0)); iowrite(addr, (ZYNQ_GPIO_OEN_0 + 0) | 0x1); If between reading and writing the registers, the other CPU does something similar (e.g. enable output on MIO 1) the result will be undefined. Setting the GPIO value can be done race-free using the "MASK_DATA_0_LSW" register (writing 0xFFFE0001 to address 0xE000A000 will set GPIO 0 to "high" without interfering with the other CPU). PS: My generic advice would be to stay away from AMP as far as you possibly can. There's hardly any advantage over letting the Linux kernel handle things, and the disadvantages are plentiful. 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 Please consider the environment before printing this e-mail -- ___ meta-xilinx mailing list meta-xilinx@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-xilinx
Re: [meta-xilinx] Zynq TTC usage by Linux
On Sat, Oct 22, 2016 at 3:06 AM, Mike Looijmans wrote: > One of the TTCs used to be used for clock source. This should still be the > case if you use dynamic clocks, because the ARM timer is fixed to the CPU > speed and does not handle frequency changes (though I think it should be > possible to fix this purely in software, no-one seems to care though). > The TTC can use the prescaler to adjust the timing when the CPU speed changes. > But if you use AMP, frequency scaling will affect both cores, so you > probably cannot use it anyway. Thanks for this information, Mike. I'm probably not using dynamic clocks since I'm using both the global arm timer and AMP. In what cases are dynamic clocks used? Just for my information, how are they enabled? > For AMP, I assigned the TTC1 interrupts to the remoteproc. I also add GPIO > "hogs" for all GPIO signals it uses. That way, the AMP firmware doesn't need > to modify various race-condition prone registers. Could you explain about how GPIO hogs eliminate dealing with race-condition prone registers? Which registers are prone to race conditions in the first place? -- ___ meta-xilinx mailing list meta-xilinx@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-xilinx
Re: [meta-xilinx] Zynq TTC usage by Linux
One of the TTCs used to be used for clock source. This should still be
the case if you use dynamic clocks, because the ARM timer is fixed to
the CPU speed and does not handle frequency changes (though I think it
should be possible to fix this purely in software, no-one seems to care
though). The TTC can use the prescaler to adjust the timing when the CPU
speed changes. But if you use AMP, frequency scaling will affect both
cores, so you probably cannot use it anyway.
For AMP, I assigned the TTC1 interrupts to the remoteproc. I also add
GPIO "hogs" for all GPIO signals it uses. That way, the AMP firmware
doesn't need to modify various race-condition prone registers.
On 21-10-16 06:19, Edward Wingate wrote:
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 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
--
Mike Looijmans
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
Please consider the environment before printing this e-mail
--
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx
Re: [meta-xilinx] Zynq TTC usage by Linux
HI Edward, > -Original Message- > From: meta-xilinx-boun...@yoctoproject.org [mailto:meta-xilinx- > boun...@yoctoproject.org] On Behalf Of Edward Wingate > Sent: Friday, October 21, 2016 12:42 PM > To: Nathan Rossi > Cc: meta-xilinx@yoctoproject.org > Subject: Re: [meta-xilinx] Zynq TTC usage by Linux > > 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. [Wendy] you will need to modify zynq_remoteproc driver to deregister it. > > > If not invalidating it in the linux kernel device tree should be fine. [Wendy] If it is working for you, this is easier. Best Regards, Wendy > > Yep, it's working with this. Thanks! > -- > ___ > meta-xilinx mailing list > meta-xilinx@yoctoproject.org > https://lists.yoctoproject.org/listinfo/meta-xilinx This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. -- ___ meta-xilinx mailing list meta-xilinx@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-xilinx
Re: [meta-xilinx] Zynq TTC usage by Linux
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
On Fri, Oct 21, 2016 at 2:19 PM, Edward Wingate wrote:
> 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.
Previously ttc0 was the default clock source for the kernel. Depending
on your kernel/devicetree that might still be the case. Newer kernels
select the arm_global_timer over the ttc.
During boot you will see something along the lines of:
[0.000473] clocksource: arm_global_timer: mask: 0x
max_cycles: 0x13381ebc09, max_idle_ns: 440795204118 ns
[0.002702] clocksource: ttc_clocksource: mask: 0x max_cycles:
0x, max_idle_ns: 2150193541 ns
...
[0.970221] clocksource: Switched to clocksource arm_global_timer
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
I could be mistaken but remoteproc should be able to unregister the
clocksource from the kernel and provide it to the remoteproc
application? If not invalidating it in the linux kernel device tree
should be fine.
Regards,
Nathan
>
>
>
>
> On Thu, Oct 20, 2016 at 5:31 PM, Edward Wingate 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
--
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx
Re: [meta-xilinx] Zynq TTC usage by Linux
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 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
[meta-xilinx] Zynq TTC usage by Linux
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
