View source for Special:NewMessages

Jump to: navigation, search
First page
First page
Previous page
Previous page
Last page
Last page

Full thread

From Talk:R-Car/Boards/Yocto-Gen3

GPIO access problem with R-Car Starter Kit Pro

Using R-Car Starterkit Pro, we are now developing a bear metal software which boots directly from ATF. However, we made slight modifications to ATF.

We added the modifications described below when we built the software, where the program will boot in EL2 mode, instead of booting from ATF. Namely, we added modifications to plat/renesas/rcar/platform.mk.

225:# Process RCAR_BL33_EXECUTION_EL flag
226:ifndef RCAR_BL33_EXECUTION_EL
227:RCAR_BL33_EXECUTION_EL := 0      <--- We changed the value "0" to "1"
228:endif
229:$(eval $(call add_define,RCAR_BL33_EXECUTION_EL))

Using the conditions described above, we made codes below.

#define PFC_BASE		(0xE6060000U)

#define PFC_PMMR		(PFC_BASE + 0x0000U)
#define PFC_GPSR6		(PFC_BASE + 0x0118U)
#define GPIO_INOUTSEL6		(GPIO_BASE + 0x5404U)

static inline uint32_t mmio_read_32(uintptr_t addr)
{
	return *(volatile uint32_t*)addr;
}

static inline void mmio_clrbits_32(uintptr_t addr, uint32_t clear)
{
	mmio_write_32(addr, mmio_read_32(addr) & ~clear);
}

static inline void mmio_setbits_32(uintptr_t addr, uint32_t set)
{
	mmio_write_32(addr, mmio_read_32(addr) | set);
}

int main(void)
{
	UINT32_T reg;

	reg = mmio_read_32(PFC_PMMR);
	mmio_clrbits_32(PFC_PMMR, (UINT32_T)(1<<11|1<<12|1<<13));
	reg = mmio_read_32(PFC_PMMR);

	reg = mmio_read_32(PFC_GPSR6);
	mmio_clrbits_32(PFC_GPSR6, (UINT32_T)(1<<11|1<<12|1<<13));
	reg = mmio_read_32(PFC_GPSR6);
	reg = mmio_read_32(PFC_PMMR);

	reg = mmio_read_32(GPIO_INOUTSEL6);
	mmio_setbits_32(GPIO_INOUTSEL6, (UINT32_T)(1<<11|1<<12|1<<13));
	reg = mmio_read_32(GPIO_INOUTSEL6);

	return 0;
}

This code processes GPIO resister settings. mmio_setbits_32() sets parameter values to GPIO resister. mmio_read_32() reads out GPIO resister values both pre- and post- GPIO resister settings. We got value "0x00013880" readout when we boot from ATF of Yocto ver. 2.12. However, we got value "0x00000000" when we boot from ATF of Yocto ver. 3.9.0. It seems GPIO settings are not properly set when we boot from ATF of Yocto ver. 3.9.0.

We wonder if there are any changes made to accessing methods of GPIO setting resister between Yocto ver. 2.12. and ver. 3.9.0.? Further, how we can properly make GPIO settings in ATF of Yocto ver. 3.9.0.?

00:53, 2 April 2020

Hello,


I noticed that you use old version BSP.

Yocto v3.21.0 is latest BSP.

So, could you update BSP to v3.21.0 from v3.9.0.

It may fix this issue.

00:13, 3 April 2020

Thank you for the reply.
I also tried Yocto v3.21.0.
But I was unable to access GPIO.

17:05, 6 April 2020

Hello,

In generally, we should keep to a correct order of register settings to work correctly.

It is possible to mistake the order, so please try to reverse the order of PFC/GPIO setting.

Sorry, I cannot test it because I don't have verification environment for bare metal application ...

01:34, 8 April 2020

I tried reversing the order of the PFC and GPIO settings and the results were the same.

02:49, 10 April 2020

Hello,

I think gpio module is initialized in ATF until v2.12.0 at least.

But, for any reasons, it maybe removed.

So, it may work to add to initialize any register (it is clock of modules? , or switch of module?) to your program.

Is it possible to investigate how to initialize gpio module?

19:05, 16 April 2020

I think it will take some time, but I'll investigate how to initialize.

02:45, 22 April 2020
 
 
 
 
 
 
 

Full thread

From Talk:R-Car/Boards/Yocto-Gen3

AGL7.0 Home screen NOT displayed

You do not have permission to edit this page, for the following reasons:

  • The action you have requested is limited to users in the group: Users.
  • You must confirm your email address before editing pages. Please set and validate your email address through your user preferences.

You can view and copy the source of this page.

 

Return to Thread:Talk:R-Car/Boards/Yocto-Gen3/AGL7.0 Home screen NOT displayed.

Hello.

Is the penguin and AGL logo displayed on the monitor during startup?

Ygohda (talk)00:24, 15 April 2019

Hello,

Thank you very much for your reply.

No, there is nothing displayed on the monitor during startup and even after Linux login prompt is shown on serial console which is running on other PC. The monitor says that no signal input.

00:51, 15 April 2019

Hi OK, please paste the result of the "printenv" command.

Ygohda (talk)18:46, 15 April 2019

Hello,

Here is the results of printenv command.

 baudrate=115200
 bootargs=console=ttySC0,115200 ignore_loglevel vmalloc=384M video=HDMI-A-1:1920x1080-32@60 root=/dev/mmcblk0p1 rw rootfstype=ext4 rootwait rootdelay=2
 bootcmd=run load_ker; run load_dtb; booti 0x48080000 - 0x48000000
 bootdelay=3
 fdt_high=0xffffffffffffffff
 filesize=12a7200
 initrd_high=0xffffffffffffffff
 load_dtb=ext4load mmc 0:1 0x48000000 /boot/r8a7795-es1-h3ulcb.dtb
 load_ker=ext4load mmc 0:1 0x48080000 /boot/Image
 stderr=serial
 stdin=serial
 stdout=serial
 ver=U-Boot 2015.04 (Apr 08 2019 - 09:51:12)
 
 Environment size: 547/131068 bytes
20:35, 15 April 2019

> load_dtb=ext4load mmc 0:1 0x48000000 /boot/r8a7795-es1-h3ulcb.dtb

This device tree is for the H3 v1.1 SK(RTP0RC7795SKBX0010SA00).

> [ 0.005726] NOTICE: BL2: PRR is R-Car H3 Ver.2.0

According to the above log you are using H3 v2.0 SK.

Please use the "r8a7795-h3ulcb.dtb".

Ygohda (talk)21:40, 15 April 2019

Hello.

Now the home screen is successfully displayed! Thank you so much for your support.

23:36, 15 April 2019
 
 
 
 
 
 

Full thread

From Talk:R-Car/Boards/Yocto-Gen3

I2C errors appeared with multiple usb devices

With multiple USB devices connected environment, I2C bus error occur when operating I2C device. We observed the following two patterns.

Pattern 1: [ 133.082741] i2c-rcar e66d8000.i2c: error -11 : f

Arbitration lost occurs on the I2C bus, and rcar_i2c_master_xfer() fails with EAGAIN. When an I2C interrupt occurs, bit 5 (Master Arbitration Lost) of the Master Status Register (ICMSR) is set.


Pattern 2: [ 183.453555] i2c-rcar e66d8000.i2c: error -110 : 13

I2C device access timeout occurs and rcar_i2c_master_xfer () fails with ETIMEDOUT. Timeout occurs because the Master Stop Transmitted bit of the Master Status Register (ICMSR) is not set.

Although the causal relationship between the USB devices and the I2C bus is unclear, it seems that the hardware is detecting an abnormality. (From Master Status Register (ICMSR))


[ Reproduce environment ] Renesas bsp 3.15 Rcar M3 StarterKit + KF-M06

M3 USB2.0(CN 5) <-------> USBHUB <----> USB WIFI

                                                           <----> USB MEMORY * 2
                                                           <----> USB mouse dongle

KF-M06(CN 29) <--------> CMOS Camera

When CMOS camera is operated (capture), I2C bus error occurs probability as below. pattern1: 1/10. pattern2: 1/2.

Thanks, WN

Wnatsume (talk)01:03, 7 March 2019

Hi Can we reproduce this phenomenon if we don't use USB Wifi? M3 USB2.0(CN5) <---> USB HUB <---> USB MEMORY * 2 and USB mouse dongle KF-M06(CN29) <---> CMOS camera(ov5642)

I cannot reproduce.(0/20) Could you try it on another KF board?

Ygohda (talk)19:42, 13 March 2019

As a result of our confirmation again, it can be reproduced, even if the USB device is not connected. Let me share the reproduction the scenario below. In addition, I used another board butI2C error is still reproduced.

[ Reproduce environment ]

- Renesas bsp 3.15 - Rcar M3 StarterKit + KF-M06 - CMOS Camera OV5642

 https://
    www.aliexpress.com/item/OV5642-5-Million-High-Sensitivity-Camera-Module-Image-Sensor-Module-Manual-Fine-tuning-with-JPEG-Interface/32909308847.html
 Connected CMOS Camera to CN 29 on KF-M06.

- capture command

 Customized based on V4L2 video capture example in here.
 https://
    linuxtv.org/downloads/v4l-dvb-apis-new/uapi/v4l/capture.c.html
 please see the attached file.
 
 # capture -d /dev/video0 -F -f rgb32 -L 0 -T 0 -W 12800 -H 720 -c 1000 -t 60 -z

[pattern1]

[ 1491.549362] i2c-rcar e66d8000.i2c: error -11 : f

[pattern2]

[ 1443.614690] i2c-rcar e66d8000.i2c: error -110 : 3

When capture command was executed, I2C bus error occurs probability as below. pattern1: 3/10. pattern2: 4/10.

Your feedback would be welcome. Thanks

Wnatsume (talk)06:07, 1 April 2019

I confirmed but did not reproduce.(0/20)

root@m3ulcb:~# dmesg|grep ov5642
[    2.583901] ov5642 22-003c: Chip ID 0x5642 detected
root@m3ulcb:~# capture -d /dev/video0 -F -f rgb32 -L 0 -T 0 -W 1280 -H 720 -c 1000 -t 60 -z
fb0 Fixed Info:
     @ 0x57400000, len=8294400, line=7680 bytes,
   Geometry - 1280 x 800, 32 bpp
/dev/video0 FPS:  29.1
(snip)
/dev/video0 FPS:  29.1
root@m3ulcb:~#

My environments:
- M3 SK (Connected: HDMI, Serial(cn12), Ether(cn7))
- KF M06(Connected: CMOS camera(cn29))

Ygohda (talk)03:09, 2 April 2019

Thank you for the confirmation. Let me re-check with another camera module.

Wnatsume (talk)04:01, 11 April 2019
 
 
 
 
First page
First page
Previous page
Previous page
Last page
Last page