Parallella Community

The idea of using to build custom Linux packages/distributions/images for Parallella has come up before, and it turns out there is already a .

Would Parallella support in Yocto be useful?
How hard would it be to create a meta-parallella (perhaps a fork of meta-xilinx)?
Would anyone perhaps be interested in working on this?

Cheers,

Andrew

hi, i am familiar with oe, so i can port it to bootstrap-linux,
https://github.com/pikhq/bootstrap-linux

bootstrap-linux is really minimalism.

Hi there,
any update on the meta-layer? I would also like to have a layer for the Parallella in yocto.
I would like to have Angstrom on Parallella, but bootstrap-linux would also be ok. Is anyone working in that direction?
On that base I would try to include the Xenomai patch to get hard realtime.
One could run realtime control algorithms on Cortex-A9 then, and use the Adapteva for muuuuch mathematics. Even video-Processing in the control-loop could be feasilible then, and still having the Linux in the back for everything else...
BR
Joerg

Joerg,

Nathan Rossi has created a Yocto layer for Parallella in his free time and has tested it on a gen0 Parallella board. It's work in progress but a very good start..

https://github.com/nathanrossi/meta-parallella

Andreas

I have just tried the meta-parallella layer and it seems to work ok except there is no hdmi support. I used the correct parallella_e16_hdmi_gpiose_7020.bit.bin.

Looking at the Ubuntu boot log I see that "platform 6c000000.axi_hdmi: Driver axi-hdmi requests probe deferral" pops up in the log quite early - the yocto boot does not contain any mention of hdmi. So it seems to me that the meta-parallella layer device tree is missing the axi-hdmi entries Thus even if you build yocto core-image-sato you dont get an hdmi enabled build with screen.

Looking in https://github.com/nathanrossi/meta-par ... parallella I see that the .dts / .dtsi files do not contain hdmi references.

Does anyone know where the correct device tree is? My next step is to use Vivado and build https://github.com/parallella/parallell ... aster/fpga to get my own version of the bitstream and then generate the device tree with Xilinx tools from github.com/Xilinx/device-tree.git. Perhaps there is a quicker way?

Peter

Peter,

Unfortunately the HDMI still needs a lot of component upgrades to work.l

-new elink design working in vivado. This is getting very close to being done!
-we are working with the latest vivado version. The first one that is "good enough" in our view. The adi HDMI reference design needs to be ported to latest vivado. (being worked on by adi)
-the HDMI driver is not upstreamed by adi so only our private Linux tree will work

Andreas

So I have now had a good play with my Yocto build with the HDMI version (pushed up to github if you are interested). Using it I have had a look at the FPGA and created the first few simple bitstreams and have also built the first simple Epiphany program plus install eSDK and built libelf etc. Next step seems to be to make all this installation a bit simpler.

FIrst a couple of questions - when building the FPGA XPS seems to mark the axi_vdma interrupt as SPI #0 but the zynq-parallella1-hdmi.dts file has this at interrupts = <0 59 0x4>; ie IRQ #91 / SPI #15 so there seems to be a bit of a mismatch with device tree and the FPGA design. Perhaps this is because I caught the code mid way to the next release using Analog Devices updated drivers etc.

Next step would seem to be to create a yocto recipe to create the newlib / epiphany-elf-gcc / epiphany-elf binutils. That would reduce the amount of configuration that you have to do on the target. I guess also a cross compiler so that the Epiphany code could be built on the build machine / released via the yocto generated distribution service... wow that seems quite a lot to do!

But is this the right next step? For a start the existing Yocto build extends meta-xilinx that builds on linux-xlnx but now Parallella has moved to analogdevicesinc/linux base. So the meta-xilinx layer may not be the best basis because for example it might patch linux-xlnx that has already been fixed up to be different from analogdevicesinc/linux. Or alternatively put the linux-xlnx source is likely to be more up to date with respect to zynq changes than the analogdevicesinc/linux source because both are separate forks of the linux master. Right now the yocto layer works and it does pull in analogdevicesinc/linux via parallella-linux and it does use meta-xilinx and it does seem to hang together although I have not done much testing. Perhaps the best next step is to replace the dependance on the linux-xlnx recipe in meta-xilinx.... or is there a commitment to port all the zynq changes from some published release of linux-xlnx into parallella-linux?

Any thoughts?