Re: [meta-xilinx] Fwd: PS I2C access by CPU1

[Mike Looijmans]

On 16-04-16 07:25, Edward Wingate wrote:

On Thu, Apr 14, 2016 at 10:43 PM, Mike Looijmans
 wrote:

One would normally add a status="disabled"; instead of changing the
compatible.

You can also completely remove the node using:

/delete-node/ &ps7_i2c_0;


Neither disabled nor delete-node seem to work. CPU1 can't access the
ps7_i2c_0 unless the node is entirely defined in the device tree.
Until I figure out how to do it the right way, I'll have to leave it
like that so that it at least works, though that opens up the
possibility that something in Linux may try to access it.


The kernel "knows" about most of the clock tree in the Zynq, and it will turn 
off any path that wasn't claimed by a driver (even if that clock was already 
running at boot).


This leads to a 'race' with the second CPU, even if the code for that turns 
the clock on at some point, the Linux kernel may still disable it later on.


Most likely the I2C clock is disabled by the kernel.


As for the clock, it just does not seem right to force-enable all clocks.


I just did this to test if it had any effect when using "incompatible"
(and "disabled" and "delete-node").


I would instantiate a "dummy" platform driver that doesn't really do
anything, but manages the resources that the FreeRTOS part needs, such as
clocks and memory ranges. That ensures that other drivers won't access it.


How would this dummy driver ensure other Linux drivers won't access
things without also locking out CPU1 from using, say, the ps7 i2c
controller?


The driver just "registers" and enables the clocks (and power supplies, memory 
ranges or whatever) the second CPU needs, and doesn't actually use them. So it 
registers a memory range, some clocks, and enables these clocks. The driver 
would only have a "probe" method that does this and nothing else.


If there's overlap in memory ranges for example, the kernel will complain 
loudly about that.




Kind regards,

Mike Looijmans
System Expert

TOPIC Embedded Products
Eindhovenseweg 32-C, NL-5683 KH 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] [PATCH 05/20] Add basic Xilinx HDF support

[Cyril Chemparathy]

Hi Jason,

On 4/13/2016 2:23 AM, Jason Wu wrote:
[...]

install -d ${D}${PLATFORM_INIT_DIR}
for fn in ${PLATFORM_INIT}; do
unzip -o ${S}/${HDF} ${fn} -d ${D}${PLATFORM_INIT_DIR}
done


Unfortunately, the approach of peeling open the HDF file and consuming 
its content is problematic.  The HDF file contents are fundamentally in 
a tool dependent format, and these contents are meant to be accessed 
indirectly through HSI interfaces.


Moving forward, we would like to implement a meta-xilinx-tools layer 
with dependencies on Xilinx maintained tools (e.g. HSI) instead of 
breaking open the HDF in this fashion.


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

Re: [meta-xilinx] [PATCH 05/20] Add basic Xilinx HDF support

[Manjukumar Harthikote Matha]

Hi Jason,



Signed-off-by: Jason Wu 
---
  recipes-bsp/hardware-definition-file/hdf.inc | 46

[]

+do_install() {
+   fn=$(unzip -l ${S}/${HDF} | awk '{print $NF}' | grep ".bit$")
+   unzip -o ${S}/${HDF} ${fn} -d ${D}
+   [ "${fn}" == "download.bit"] || mv ${D}/${fn} ${D}/download.bit
+
+   install -d ${PLATFORM_INIT_STAGE_DIR}
+   for fn in ${PLATFORM_INIT}; do
+   unzip -o ${S}/${HDF} ${fn} -d ${PLATFORM_INIT_STAGE_DIR}
+   done




Unfortunately, the approach of peeling open the HDF file and consuming
its content is problematic.  The HDF file contents are fundamentally in
a tool dependent format, and these contents are meant to be accessed
indirectly through HSI interfaces.

Moving forward, we would like to implement a meta-xilinx-tools layer
with dependencies on Xilinx maintained tools (e.g. HSI) instead of
breaking open the HDF in this fashion.

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