Example using camera with XIP kernel 4.9


Is there any example available of a working device-tree using a camera (any OVxxxx) for the 4.9 kernel in XIP with single QSPI ?

Best regards

  • In reply to Chris:

    Now you're talking about XIP option in upstream kernel, I remember I had to do some dirty hacks to be able to build my kernel as XIP.
  • In reply to dylan_mesotic:

    Yes, no matter how many times I've tried, and as many different patches I have submitted, the upstream ARM maintainer will not let me enable XIP for MMU enabled systems. (although he is OK with keeping the underlying code working).

    So, you always have to apply this simple patch to be able to enable XIP_KERNEL:

    diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
    index 7f61372a6462..d33e20ffcbe6 100644
    --- a/arch/arm/Kconfig
    +++ b/arch/arm/Kconfig
    @@ -331,7 +331,7 @@ config ARCH_MULTIPLATFORM
    bool "Allow multiple platforms to be selected"
    depends on MMU
    select ARM_HAS_SG_CHAIN
    - select ARM_PATCH_PHYS_VIRT
    select AUTO_ZRELADDR
    select TIMER_OF
    select COMMON_CLK
    @@ -1966,7 +1966,7 @@ endchoice

    config XIP_KERNEL
    bool "Kernel Execute-In-Place from ROM"
    - depends on !ARM_LPAE && !ARCH_MULTIPLATFORM
    + depends on !ARM_LPAE
    Execute-In-Place allows the kernel to run from non-volatile storage
    directly addressable by the CPU, such as NOR flash. This saves RAM

    Since 4.16.-rc1 was released yesterday, I'll have to confirm sometime this week that nothing broke for XIP_KERNEL.
  • In reply to Chris:


    I'm also trying to use an OV7670 with Linux-4.9, but in a RSK+ (RZA1H). With "ceu_example", the code stucked in the while around "ceu_is_capturing" function (CAPSR register always 0x01). You said we must change CEU pin setup in u-boot or kernel, but I can't figure out where... The ideia is "streaming" the images to a webpage, just like 3.14 example.

    Thanks a lot!
  • In reply to Peaga:

    Remember, on the RSK board, you can not use camera and LCD at the same time. They share pins.
    So, you should remove LCD display section (vdc5) from the Device Tree so the pins do not get configured as LCD.

    Or, you can set the status to disabled.
    &vdc50 {
    pinctrl-names = "default";
    pinctrl-0 = <&vdc50_pins>;

    display = <&display0>;
    status = "disabled";

    Then, to set the pins to CEU, you can do this in u-boot, add this code to function board_early_init_f( )
    [file] u-boot-2017.05/board/renesas/rskrza1/rskrza1.c

    /* Enable CEU Camera interface */
    pfc_set_pin_function(10, 1, ALT1, 0, 0); /* VIO_VD */
    pfc_set_pin_function(10, 2, ALT1, 0, 0); /* VIO_HD */
    pfc_set_pin_function(10, 0, ALT1, 0, 0); /* VIO_CLK */

    pfc_set_pin_function(10, 4, ALT1, 0, 0); /* VIO_D0 */
    pfc_set_pin_function(10, 5, ALT1, 0, 0); /* VIO_D1 */
    pfc_set_pin_function(10, 6, ALT1, 0, 0); /* VIO_D2 */
    pfc_set_pin_function(10, 7, ALT1, 0, 0); /* VIO_D3 */

    pfc_set_pin_function(10, 8, ALT1, 0, 0); /* VIO_D4 */
    pfc_set_pin_function(10, 9, ALT1, 0, 0); /* VIO_D5 */
    pfc_set_pin_function(10, 10,ALT1, 0, 0); /* VIO_D6 */
    pfc_set_pin_function(10, 11,ALT1, 0, 0); /* VIO_D7 */

    Or, instead you can add the pin setup to the Device Tree in the kernel.
    The easiest is to just add the CEU pins to a driver that you already know will be used.
    For example, the serial console. Then, when the serial console is loaded, the CEU pins will also get set up.
    Just remember that you have to remove the ";" in the list (after RxD2) and and replace it with a ","

    Something like this:
    [FILE] linux-4.9/arch/arm/boot/dts/r7s72100-rskrza1.dts

    &pinctrl {

    /* Serial Console */
    scif2_pins: serial2 {
    pinmux = <RZA1_PINMUX(3, 0, 6)>, /* TxD2 */
    - <RZA1_PINMUX(3, 2, 4)>; /* RxD2 */
    + <RZA1_PINMUX(3, 2, 4)>, /* RxD2 */
    + /* Enable CEU Camera interface */
    + <RZA1_PINMUX(10, 1, 1>, /* VIO_VD */
    + <RZA1_PINMUX(10, 2, 1>, /* VIO_HD */
    + <RZA1_PINMUX(10, 0, 1>, /* VIO_CLK */
    + <RZA1_PINMUX(10, 4, 1>, /* VIO_D0 */
    + <RZA1_PINMUX(10, 5, 1>, /* VIO_D1 */
    + <RZA1_PINMUX(10, 6, 1>, /* VIO_D2 */
    + <RZA1_PINMUX(10, 7, 1>, /* VIO_D3 */
    + <RZA1_PINMUX(10, 8, 1>, /* VIO_D4 */
    + <RZA1_PINMUX(10, 9, 1>, /* VIO_D5 */
    + <RZA1_PINMUX(10, 10,1>, /* VIO_D6 */
    + <RZA1_PINMUX(10, 11,1>; /* VIO_D7 */

    That should do it.
  • In reply to Chris:

    Hi Chris, thanks for your help!

    I've disabled "vdc50" and added "PINMUX" on Device Tree, but no success... App still stucking on "ceu_is_capturing"... I've also tried "pfc_set_pin_function", with no luck... Double checked the connections, they're fine too!

    Thanks again
  • In reply to Peaga:

    Don't you have some soldering to do (moving some resistors) to be able to use the camera on this board ? I never used this board.
  • In reply to Peaga:

    First make sure something is coming out of the camera pins. That will confirm that the I2C connection is working.

    Even if you set up the CEU pins correctly, if the CEU never sees a VSYNC, HSYNC, or clock, it will never trigger.
  • In reply to dylan_mesotic:

    Actually, now that you mention it, the pin multiplexer (IC38) need to be changed to redirect the pins/signals from LCD to CEU. But, you don't have to change any resistors that I can see or remember (no little yellow stickers on my boards that say 'modified for camera' like I normally do).

    So in u-boot, before you boot the board, change the pin multiplexer.
    There's a special u-boot command ("io_mux") just for the RSK board.

    => io_mux
    io_mux - Change io mux

    io_mux Change the I/O Multiplexers by changing the output of I2C Port Expander 2.
    Usage: io_mux [a|b|c|d]
    a: PX1_EN0=L: P10/P11 = LCD(CN44)
    b: PX1_EN0=H: P10/P11 = CEU(CN41) and RSPI-1(CN25,CN26)

    c: PX1_EN1=L: P2/P3 = IO(JA1), RSPI-4(CN15), SIM(CN4)
    d: PX1_EN1=H: P2/P3 = Ethernet

    Current PX1_EN0 = L
    PX1_EN1 = H

    So you will want to run the command:
    => io_mux b

    then, boot your board.
  • In reply to Chris:

    Hello guys

    I only had to solder a connector for the camera, even some capacitor around was already soldered... And about i2c, looks like it's working fine: if I remove the camera VCC, "ceu_omni" shows me "camera not found"; putting VCC again, I've got "ov7670 found" (I edited the "I2C_BUS_SCAN_" routine)...
  • In reply to Peaga:

    Chris is right, since the number of pins is limited, some of them are shared. So you need to manually tell your u-boot or whatever you want to physically connect VS, HS, CLK to your camera.
    I2C is working (this is normal) but you're stuck here because there is no end of frame interrupt. You're not receiving this interrupt because you're missing at least one signal from your camera and CEU is still waiting for it.
  • In reply to dylan_mesotic:

    Hi guys

    Even changing "io_mux" (both pin "High"), no luck... I'll try to find a Scope so I can check the 3 pins signal...

    Thanks again!
  • In reply to Peaga:

    Hello guys

    Now the camera is working! The problem was "RZA1_PINMUX" for CEU interface. Alternative function "f" is 6, according to datasheet, instead of 1:

    <RZA1_PINMUX(10, 0, 6)>

    Each capture is displaying on a simple webpage (slowly, but it's ok!).

    @Chris, any chance to have this camera driver in kernel again?
  • In reply to Peaga:

    To be honest, I think it will be better for you to switch to a 4.17 kernel.
    The reworked driver has been released, see git.kernel.org/.../renesas-ceu.c
    As I said previously in this post, backporting this driver to the 4.9 kernel will be complicated. Maybe it will be easier to backport it to the 4.14 kernel maintain by Renesas but It may take some time.

  • In reply to dylan_mesotic:

    The newer mainlined CEU driver is much better than the old one. But as Dylan pointed out, it didn't get in until 4.17.

    We're in the process of backporting it to our 4.14 BSP. You can't just copy the driver back because some files in the video subsystem changed between 4.14 and 4.17. After we get it stable and tested, we'll push it to the 4.14 repo on github.

    As for backporting it all the way to 4.9, we will probably not do that.
  • In reply to Chris:

    Thanks guys for the information!

    So I'll wait the 4.14 update!

    Thanks again!