Page 3 of 7

Re: RPi Camera bounty

PostPosted: Wed Jun 24, 2015 1:23 pm
by aolofsson
We have 1,000 Porcupine PCBs at our contract manufacturer. Looks like they will come rolling off the line in early July.
(then they have to make it into the distribution channels at Digikey and RS)
Andreas

Re: RPi Camera bounty

PostPosted: Wed Jun 24, 2015 2:02 pm
by tnt
I started porting all my stuff to the porcupine and in a bitstream that includes the e-link.
But ATM I'm kind of stuck with the I2C.

I'm getting this :
Code: Select all
cdns-i2c e0005000.i2c: timeout waiting on completion


What I did is :
- Enable the I2C1 controller in the PS7 and export it to EMIO
- Use the new ps7_init.{c,h} to generate a new FSBL with the SDK
- Flash it to QSPI
- In the PL, add a a new parallella i2c block and connect the pads to FPGA pins (replacing some of the GPIOs) and adapting name/constraint.
- Generate a new bitstream with this and make sure it's loaeded in the PL
- Add an entry in the device tree :
Code: Select all
      i2c@e0005000 {
         compatible = "cdns,i2c-r1p10";
         reg = <0xe0005000 0x1000>;
         interrupts = <0x0 0x30 0x4>;
         interrupt-parent = <0x1>;
         bus-id = <0x1>;
         clocks = <0x2 0x27>;
         clock-frequency = <400000>;
         #address-cells = <0x1>;
         #size-cells = <0x0>;
      };


And in linux I see the driver being loaded and binded to the right address and interrupt :

Code: Select all
cdns-i2c e0005000.i2c: 400 kHz mmio e0005000 irq 80


But trying to access it, I get the timeout above.

Any idea what's wrong or what I have missed ?

Re: RPi Camera bounty

PostPosted: Wed Jun 24, 2015 2:41 pm
by aolofsson
I can just throw out ideas in the air, please ignore if not helpful:-)

-Yours is quite different from the one in our github repo? I am not familiar enough to say if all the difference are OK?
https://github.com/parallella/parallell ... ella1.dtsi

-What about trying with the I2C interface that is already there for the PMIC? The I2C pins come out on the header as 5V. (need level translator)

Sorry I can't be more useful...

I have pinged Ola who has been messing around some with the I2c and linux is general, so he might have some ideas.

Andreas

Re: RPi Camera bounty

PostPosted: Wed Jun 24, 2015 3:11 pm
by tnt
I actually based this entry off the existing one, but I decompiled the .dtb rather than going from the dts in the linux tree. This is why the symbolic reference like &gic are turned into actual ID numbers. And also why some numbers are hex rather than decimal

What I modified is:
- Removed the ADV node (there is no ADV on this bus)
- Changed the base address to e0005000 which is where the controller is
- Changed the interrupt from 25 to 48 (which should be IRQ80 and seems confirmed by the boot message). IRQ80 is what's listed in the TRM.
- Bumped the frequency to 400 kHz
- Changed the clock node to 0x27 = 39. I got that from zynq-zc770-xm012.dts

As for the other I2C bus, yeah it works, but I can't have the same I2C bus on 2 different sets of pins out of the FPGA so that doesn't help me much. I need them on the RPi camera connector.

Re: RPi Camera bounty

PostPosted: Wed Jun 24, 2015 3:17 pm
by aolofsson
Have you tried backing off on frequency? The zynq rev that you have contains some errata on the i2c.

http://www.xilinx.com/support/answers/47916.html

Re: RPi Camera bounty

PostPosted: Wed Jun 24, 2015 3:31 pm
by olajep
[ previous message got lost? ]

Since you use the EMIO pins you also need a small portion of PL logic (IIRC Vivado will create a OBUF in one of the design stages)
So you need to replace parallella.bit.bin or flash with a new bitstream and remove parallella.bit.bin

Try decreasing the clock frequency to 100 kHZ temporarily until you have it working.
I've been told that you might need to add a filter to the PL logic if you want to run @ 400 kHZ.

// Ola

Re: RPi Camera bounty

PostPosted: Wed Jun 24, 2015 3:49 pm
by olajep
From the zynq dtsi from a more recent adi kernel version:
https://github.com/parallella/parallell ... .dtsi#L120
Code: Select all
      i2c1: i2c@e0005000 {
         compatible = "cdns,i2c-r1p10";
         status = "enabled";
         clocks = <&clkc 39>;
         interrupt-parent = <&intc>;
         interrupts = <0 48 4>;
         reg = <0xe0005000 0x1000>;
         #address-cells = <1>;
         #size-cells = <0>;
      };

Just add
Code: Select all
&i2c1 {
status: "ok";
}


gic changed name to intc but otherwise it should be the same
your device tree looks right to me.

edit: I've seen those console timeout messages. In my case it was because I didn't have a proper bitstream.

Re: RPi Camera bounty

PostPosted: Wed Jun 24, 2015 4:01 pm
by tnt
nm ... I'm an idiot ...

I loaded my new bitstream loading it with xdevcfg, with my custom logic and the I2C EMIO -> PAD connection. And I could access my custom logic so I knew it was loaded. Then I modified the device tree, rebooted the board and saw the I2C driver load but couldn't access it.

See what I did there ? ... I forgot to reload my custom bitstream after having rebooting the board with the new device tree ...

Now it works, interrupts are firing and no timeout messages.

Sorry for the noise ...

Re: RPi Camera bounty

PostPosted: Wed Jun 24, 2015 4:19 pm
by aolofsson
Great news!:-)

Re: RPi Camera bounty

PostPosted: Wed Jun 24, 2015 9:07 pm
by tnt
Ok, got it all working on the rev1 with the porcupine :)
Attached is the first image captured.

It's getting a bit late so I'll do some minor cleanup of the rough edges and publish a first prototype for people to try tomorrow. Just something that takes a single frame or so.

In the mean time you can start doing the hw mod to the porcupine that you'll need to try it. (at the moment this is still needed, I hope to lift that requirement).

MOD:
- GPIO_{N,P}7 is turned into a comparator
- GPIO_N7 is fixed to ~ 0.85v. You can do this either with a dedicated lab supply or a simple resistor divider. Personally I used a 1k to VCC_GPIO (2.5v), then 2*1k in parallell (so = 500ohm) to GND.
- GPIO_P7 is connected to GPIO_N8 through a 1k resistor. (value is not critical, but must be large enough to not distort the signal and low enough so that it doesn't take forever to charge the input capacitance of the pin)

I do have something a bit weird with the Xilinx VDMA controller, I configured it for 4 frame buffers (as opposed to 3 in my previous test) and strangely, it's still iterating through only 3 frame buffers ( 1->2->3->1->... ), it just never uses frame buffer 0 ... not sure wtf is going on there.