Problem with memory transfers

Problem with memory transfers


I read the memory from the XeonPhi by using the MicAccessAPI and boot an own 32bit kernel on the card. Now I had problems, seeing my debug data on the host. On the XeonPhi, I write directly to some memory like this (in 32bit code):
c6 05 05 80 0b 00 44     movb   $0x44,0xb8005
But the value 0x44 does not become visible with the MicAccessAPI. It seems like the data is staying in the cache or the core hangs. wbinvd and clflush after the mov instruction did not help.

After some experimenting, I figured out that following code seems work:
bf 00 80 0b 00           mov    $0xb8000,%edi
c6 07 aa                 movb   $0xaa,(%edi)

Is the latter variant reliable? I also tried loops that wrote 64 and more bytes in a row and some of these did not become visible...


2 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

Nevermind. Looks like the fboot1 bootloader does not switch back to 32bit mode if it loads a 64bit ELF image instead of a Linux bzImage. That was left a bit vague in the manual.

Which makes me wonder, whether the SFI tables are there and in which states the AP cores are left...


Leave a Comment

Please sign in to add a comment. Not a member? Join today