On 30-08-16 00:52, Edward Wingate wrote:
> 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.
>
Correct, the kernel unlocks the SLCR just once. Locking them is just going to
be a pointless cause of headaches, the registers are already protected against
accidental (or malicious) changes by the kernel's priviliged mode.
> 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.
>
Correct, the kernel unlocks the SLCR just once. Locking them is just going to
be a pointless cause of headaches, the registers are already protected against
accidental (or malicious) changes by the kernel's priviliged mode.
Kind regards,
Mike Looijmans
System Expert
|
TOPIC Products |
|
| |
|
Materiaalweg 4 |
|
| |
|
5681 RJ Best |
T: |
+31 (0) 499 33 69 69 | |
|
Postbus 440 |
E: |
||
|
5680 AK Best |
W: |
||
| The Netherlands |
Please consider the environment before printing this
e-mail
Topic zoekt gedreven (embedded) software specialisten!
-- _______________________________________________ meta-xilinx mailing list [email protected] https://lists.yoctoproject.org/listinfo/meta-xilinx
