[meta-xilinx] Zynq TTC usage by Linux

[Mike Looijmans]

On 25-10-16 08:39, Edward Wingate wrote:
> On Mon, Oct 24, 2016 at 11:16 PM, Mike Looijmans
> <mike.looijmans at topic.nl> 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_0        0xE000A204
>> #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.looijmans at topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail