JustVince:
no I confirm, this is an official brand "arduino.org" see attachment.
Interesting! I've never seen or used the .ORG boards, all of my Yuns are the original revision .CC boards. At the time that a few of the Arduino founders split off and formed the .ORG group, there were many people coming here to this forum for help with .ORG boards, but the help we could give was limited because there were some definite differences between the original .CC boards and the later .ORG boards. I thought the differences were primarily software, but it looks like there were some significant hardware differences.
Since your board was produced by what was at the time a different company, it's not much of a surprise that the hardware doesn't match the schematics that you will find there on this site. I never went looking for schematics over on the arduino.org site, so I can't say if their schematics contained the level of detail that shows these extra header pins.
Interestingly, I did an image search again, and paid more attention while looking for boards that has the arduino.org identifier. And what do I find in the retired products section of this arduino.cc site, but a picture of an arduino.org board with the pads for the extra pins, but no header installed in them:
Then I created a code and a sketch in C to connect the processor (Master) with the microcontroller (slave) through the SPI.
Very nice! So it looks like there is a SPI device driver on the Linux side that uses the software bit-bang interface. I know that avrdude uses a software SPI interface to load a sketch onto the '32U4 processor, but I didn't know whether the bit-banging was inside of avrdude, or if it used a software interface device driver. I guess it was the latter.
What data transfer rates are you able to sustain? I see you set the clock speed to 4 MHz, which would give a theoretical maximum of 500,000 bytes per second. But that doesn't mean that the Linux side can transmit the data that fast, nor that the sketch side can receive the data that quickly without dropping bytes. (After all, that only leaves 24 clock cycles for the '32U4 to process each byte, which ain't much! :o )