Is there a quick and easy way to do a software reset on the RZ?
Or is simply branching to the reset handler the appropriate way to do this?
(I'm working on code that will download a new code image into the CS0 flash space - and then I need to "reset").
Thanks.
Thank you Chris.
Can you tell me when the estimated release date of the BSP for the RZ/A1L is? Is there a development repository for it?
The repository will be the same as the existing RZ/A1H.
We will just be adding support for more Renesas boards, some of them based on RZ/A1L.
If you are tracking the github repositories, then you will start to see RZ/A1L updates within the next 2 weeks.
The actually 'release date' of the BSP that gets posted on RenesasRulz is not that important if you are tracking the repositories directly.
Good news!
I decided to delete everything and make a clean build and now I finally have /dev/input/event0
But if I try cat /dev/input/event0 nothing happens.
Could it be the interrupt not working? How can I check it?
Thanks again!
Hi all!
I'm working on a RZA1H based board. For demo purposes I'm trying to use the LCD touchscreen panel that came with the RZA1H starter kit +. I managed to show images on the screen, but I'm struggling with the touchscreen on the TFT board.
I compiled the kernel with EDT-FT5X06 driver, but it's not working.
I'm not working with the kernel available on the official GIT, but with a different one. Since I have no error compiling or booting the system, I think that the driver is fine and that I miss something else.
I don't know how to port the driver from the official kernel to mine, and I don't know how to edit the dtb file for my board, all I know is where the file is, and that the I2C lines for the touch screen, on the new board are:
P1_6/I2C_SCL3
P1_7/I2C_SDA3
Can someone guide me through the correct process to make the touchscreen work please?
Thank you in advance!
So, now when I power on the board i get this errors:
------------[ cut here ]------------
WARNING: at fs/sysfs/dir.c:536 sysfs_add_one+0x78/0x98()
sysfs: cannot create duplicate filename '/devices/platform/i2c-riic.3'
Modules linked in:
[<c00132c4>] (unwind_backtrace+0x0/0xe0) from [<c001e7b0>] (warn_slowpath_common+0x4c/0x64)
[<c001e7b0>] (warn_slowpath_common+0x4c/0x64) from [<c001e7f4>] (warn_slowpath_fmt+0x2c/0x3c)
[<c001e7f4>] (warn_slowpath_fmt+0x2c/0x3c) from [<c00e9ec4>] (sysfs_add_one+0x78/0x98)
[<c00e9ec4>] (sysfs_add_one+0x78/0x98) from [<c00ea074>] (create_dir+0x58/0xb0)
[<c00ea074>] (create_dir+0x58/0xb0) from [<c00ea3e0>] (sysfs_create_dir+0xbc/0xdc)
[<c00ea3e0>]te_dir+0xbc/0xdc) from [<c01c8e9c>] (kobject_add_internal+0xd4/0x1d0)
[<c01c8e9c>] (kobject_add_internal+0xd4/0x1d0) from [<c01c91e8>] (kobject_add+0x6c/0x8c)
[<c01c91e8>] (kobject_add+0x6c/0x8c) from [<c0211508>] (device_add+0xe4/0x558)
[<c0211508>] (device_add+0xe4/0x558) from [<c0214df8>] (platform_device_add+0x130/0x1c4)
[<c0214df8>] (platform_device_add+0x130/0x1c4) from [<c0215248>] (platform_device_register_full+0x90/0xcc)
[<c0215248>] (platform_device_register_full+0x90/0xcc) from [<c04be720>] (hachiko_init+0x1a8/0x2f8)
[<c04be720>] (hachiko_init+0x1a8/0x2f8) from [<c04ba744>] (customize_machine+0x1c/0x28)
[<c04ba744>] (customize_machine+0x1c/0x28) from [<c0008624>] (do_one_initcall+0x8c/0x150)
[<c0008624>] (do_one_initcall+0x8c/0x150) from [<c04b9810>] (kernel_init_freeable+0xf4/0x1b4)
[<c04b9810>] (kernel_init_freeable+0xf4/0x1b4) from [<c038eb2c>] (kernel_init+0x8/0xe4)
[<c038eb2c>] (kernel_init+0x8/0xe4) from [<c000d9d8>] (ret_from_fork+0x14/0x3c)
---[ end trace 20e163409d1e28f9 ]---
------------[ cut here ]------------
WARNING: at lib/kobject.c:196 kobject_add_internal+0x180/0x1d0()
kobject_add_internal failed for i2c-riic.3 with -EEXIST, don't try to register things with the same name in the same directory.
Modules linked in:
[<c00132c4>] (unwind_backtrace+0x0/0xe0) from [<c001e7b0>] (warn_slowpath_common+0x4c/0x64)
[<c001e7b0>] (warn_slowpath_common+0x4c/0x64) from [<c001e7f4>] (warn_slowpath_fmt+0x2c/0x3c)
[<c001e7f4>] (warn_slowpath_fmt+0x2c/0x3c) from [<c01c8f48>] (kobject_add_internal+0x180/0x1d0)
[<c01c8f48>] (kobject_add_internal+0x180/0x1d0) from [<c01c91e8>] (kobject_add+0x6c/0x8c)
[<c01c91e8>] (kobject_add+0x6c/0x8c) from [<c0211508>] (device_add+0xe4/0x558)
[<c0211508>] (device_add+0xe4/0x558) from [<c0214df8>] (platform_device_add+0x130/0x1c4)
[<c0214df8>] (platform_device_add+0x130/0x1c4) from [<c0215248>] (platform_device_register_full+0x90/0xcc)
[<c0215248>] (platform_device_register_full+0x90/0xcc) from [<c04be720>] (hachiko_init+0x1a8/0x2f8)
[<c04be720>] (hachiko_init+0x1a8/0x2f8) from [<c04ba744>] (customize_machine+0x1c/0x28)
[<c04ba744>] (customize_machine+0x1c/0x28) from [<c0008624>] (do_one_initcall+0x8c/0x150)
[<c0008624>] (do_one_initcall+0x8c/0x150) from [<c04b9810>] (kernel_init_freeable+0xf4/0x1b4)
[<c04b9810>] (kernel_init_freeable+0xf4/0x1b4) from [<c038eb2c>] (kernel_init+0x8/0xe4)
[<c038eb2c>] (kernel_init+0x8/0xe4) from [<c000d9d8>] (ret_from_fork+0x14/0x3c)
---[ end trace 20e163409d1e28fa ]---
I verified with an oscilloscope SDA SCL and the interrupt pin. When I touch the the screen I can see waveforms, unfortunately I haven't a protocol analyzer so I can't see what's going on.
Further informations!
I tried ts_test and when I touch the screen it promps out:
i2c-riic i2c-riic.3: i2c bus is busy.
ft5x06-ts 3-0038: Unable to write to i2c touchscreen!
So it's working, but something else is keeping the bus busy! now I just need to understand what it is!
UPDATE::
Removing: platform_device_register_full(&riic3_info);
from my board.c fixed the errors at boot. But I'm still having this issue when I try ts_test:
i2c-riic i2c-riic.3: i2c bus is busy.
ft5x06-ts 3-0038: Unable to write to i2c touchscreen!
this is what I get when I boot the board:
i2c /dev entries driver
i2c-riic i2c-riic.0: version 2013-04-19: 100[kbps]
i2c-riic i2c-riic.1: version 2013-04-19: 100[kbps]
ft5x06_set_mode: changed mode to 0x00
input: FT5X06 Multiple Touch Controller as /devices/platform/i2c-riic.3/i2c-3/3-
0038/input/input0
i2c-riic i2c-riic.3: version 2013-04-19: 100[kbps]
Thanks. I got that working fairly easily - but now I'm having trouble clearing the WOVF bit at startup. I've gone over the user manual and think I'm following all the proper steps - but I end up in the abort handler if I include the suspect line. (in red below).
Where can I find the Linux BSP code that does this? I'd like to see if they're using a trick I'm missing...
Here's my code to clear the WOVF bit:
> sysfs: cannot create duplicate filename '/devices/platform/i2c-riic.3'
> UPDATE::
> Removing: platform_device_register_full(&riic3_info);
> from my board.c fixed the errors at boot.
My guess on that was that you were registering the i2c in more than one place in your board file.
If when you run ts_test, and everytime you touch the screen you see the busy message, then at least you know the interrupt pin is working which is good.
You will get the "i2c is busy message" if the i2c lines are being held low (by either the touchscreen IC, or the RZ itself). You should put a scope (or volt meter) on there and see if that is the case.
If one of the lines are low, you can tell if it's the RZ driving it or not by reading the RIIC3CR1 register.
Address 0xFCFEEC00 (32-bit register).
$ mem r l FCFEEC00
bit 0: current state of the SDA pin (0=low, 1=high)
bit 1: current state of the SCL pin (0=low, 1=high)
bit 2: is RZ driving the SDA pin low? (0=yes, 1=no)
bit 3: is RZ driving the SCL pin low? (0=yes, 1=no)
If the RZ is driving it, then maybe it's not finishing the last i2c transaction. But, that's strange because this is the same driver that we're using on other boards.
One other thing I noticed is that u-boot uses the bank command as well. So, if you do a read of an address above 16MB (sf read xxx) , it sets the bank register which might screw things up when you boot if you are assuming there is not bank register. The easy fix for that is to just do a dummy read of some SPI flash address below 16MB.
Yes, it's recommended to reset the SPI flash any time you reboot the system because of that exact issue (the bank being set). Also on some SPI flash, the kernel will put the SPI flash into "extended address mode" meaning the SPI flash then expects 4-byte address for a legacy SPI READ (0x03) command instead of just 3 bytes of address.....but the RZ has no idea about that. so when it goes to boot it will send out a READ command (0x03) followed by a 3-byte address (00 00 00) and then get back garbage because the SPI flash is thinking another address byte is coming.
>but now I'm having trouble clearing the WOVF bit at startup.
The WOVF will be cleared automatically on reset. You should not have to do anything.
>Where can I find the Linux BSP code that does this? I'd like to see if they're using a trick I'm missing.
here:
https://github.com/renesas-rz/linux-3.14/blob/master/arch/arm/mach-shmobile/board-rskrza1.c#L2267
#define WTCSR 0
#define WTCNT 2
#define WRCSR 4
static void r7s72100_restart(enum reboot_mode mode, const char *cmd)
{
void *base = ioremap_nocache(0xFCFE0000, 0x10);
/* If you have board specific stuff to do, you can do it
here before you reboot */
/* NOTE: A reboot command doesn't 'sync' before this function
is called. See funciotn reboot() in kernel/reboot.c */
/* Dummy read (must read WRCSR:WOVF at least once before clearing) */
*(volatile uint8_t *)(base + WRCSR) = *(uint8_t *)(base + WRCSR);
*(volatile uint16_t *)(base + WRCSR) = 0xA500; /* Clear WOVF */
*(volatile uint16_t *)(base + WRCSR) = 0x5A5F; /* Reset Enable */
*(volatile uint16_t *)(base + WTCNT) = 0x5A00; /* Counter to 00 */
*(volatile uint16_t *)(base + WTCSR) = 0xA578; /* Start timer */
while(1); /* Wait for WDT overflow */
}
|
None of the line is low. If I touch the screen the interrupt line goes down, and on SDA and SCL I see some waveform. The reset pin is always up.
If I try "i2cdetect 3" I get:
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- UU -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
which I think it's good, because as far as I know UU means that's reserved by a driver.
Also"evtesthangs after this messages:
$ evtest /dev/input/event0
Input driver version is 1.0.1
Input device ID: bus 0x18 vendor 0x0 product 0x0 version 0x0
Input device name: "FT5X06 Multiple Touch Controller"
Supported events:
Event type 0 (EV_SYN)
Event type 1 (EV_KEY)
Event code 330 (BTN_TOUCH)
Event type 3 (EV_ABS)
Event code 0 (ABS_X)
Value 0
Min 0
Max 1279
Event code 1 (ABS_Y)
Value 0
Min 0
Max 799
Event code 24 (ABS_PRESSURE)
Value 0
Min 0
Max 1
Properties:
Testing ... (interrupt to exit)
If I touch the screen nothing happens.
This is the output of "cat /proc/interrupts" :
CPU0
32: 5934 GIC ft5x06_ts
41: 0 GIC RZA1DMA
42: 0 GIC RZA1DMA
43: 0 GIC RZA1DMA
44: 0 GIC RZA1DMA
45: 0 GIC RZA1DMA
46: 0 GIC RZA1DMA
47: 0 GIC RZA1DMA
48: 0 GIC RZA1DMA
49: 0 GIC RZA1DMA
50: 0 GIC RZA1DMA
51: 0 GIC RZA1DMA
52: 0 GIC RZA1DMA
53: 0 GIC RZA1DMA
54: 0 GIC RZA1DMA
55: 0 GIC RZA1DMA
56: 0 GIC RZA1DMA
57: 0 GIC RZA1DMA_E
73: 51055 GIC r8a66597_hcd:usb1
74: 142 GIC r8a66597_hcd:usb2
75: 0 GIC vdc5fb.0: s0_vi_vsync
76: 0 GIC vdc5fb.0: s0_lo_vsync
77: 0 GIC vdc5fb.0: s0_vsyncerr
78: 0 GIC vdc5fb.0: gr3_vline
79: 0 GIC vdc5fb.0: s0_vfield
80: 0 GIC vdc5fb.0: iv1_vbuferr
81: 0 GIC vdc5fb.0: iv3_vbuferr
82: 0 GIC vdc5fb.0: iv5_vbuferr
83: 0 GIC vdc5fb.0: iv6_vbuferr
84: 0 GIC vdc5fb.0: s0_wline
85: 0 GIC vdc5fb.0: s1_vi_vsync
86: 0 GIC vdc5fb.0: s1_lo_vsync
87: 0 GIC vdc5fb.0: s1_vsyncerr
88: 0 GIC vdc5fb.0: s1_vfield
89: 0 GIC vdc5fb.0: iv2_vbuferr
90: 0 GIC vdc5fb.0: iv4_vbuferr
91: 0 GIC vdc5fb.0: s1_wline
92: 0 GIC vdc5fb.0: oir_vi_vsync
93: 0 GIC vdc5fb.0: oir_lo_vsync
94: 0 GIC vdc5fb.0: oir_vline
95: 0 GIC vdc5fb.0: oir_vfield
96: 0 GIC vdc5fb.0: iv7_vbuferr
97: 0 GIC vdc5fb.0: iv8_vbuferr
99: 0 GIC vdc5fb.1: s0_vi_vsync
100: 0 GIC vdc5fb.1: s0_lo_vsync
101: 0 GIC vdc5fb.1: s0_vsyncerr
102: 0 GIC vdc5fb.1: gr3_vline
103: 0 GIC vdc5fb.1: s0_vfield
104: 0 GIC vdc5fb.1: iv1_vbuferr
105: 0 GIC vdc5fb.1: iv3_vbuferr
106: 0 GIC vdc5fb.1: iv5_vbuferr
107: 0 GIC vdc5fb.1: iv6_vbuferr
108: 0 GIC vdc5fb.1: s0_wline
109: 0 GIC vdc5fb.1: s1_vi_vsync
110: 0 GIC vdc5fb.1: s1_lo_vsync
111: 0 GIC vdc5fb.1: s1_vsyncerr
112: 0 GIC vdc5fb.1: s1_vfield
113: 0 GIC vdc5fb.1: iv2_vbuferr
114: 0 GIC vdc5fb.1: iv4_vbuferr
115: 0 GIC vdc5fb.1: s1_wline
116: 0 GIC vdc5fb.1: oir_vi_vsync
117: 0 GIC vdc5fb.1: oir_lo_vsync
118: 0 GIC vdc5fb.1: oir_vline
119: 0 GIC vdc5fb.1: oir_vfield
120: 0 GIC vdc5fb.1: iv7_vbuferr
121: 0 GIC vdc5fb.1: iv8_vbuferr
139: 104266 GIC sh_mtu2.0
146: 0 GIC sh_adc.0
170: 0 GIC sh_adc.0
171: 0 GIC sh_adc.0
189: 0 GIC riic.0
190: 0 GIC riic.0
191: 0 GIC riic.0
192: 0 GIC riic.0
193: 0 GIC riic.0
194: 0 GIC riic.0
195: 0 GIC riic.0
196: 0 GIC riic.0
197: 0 GIC riic.1
198: 0 GIC riic.1
199: 0 GIC riic.1
200: 0 GIC riic.1
201: 0 GIC riic.1
202: 0 GIC riic.1
203: 0 GIC riic.1
204: 0 GIC riic.1
213: 2969 GIC riic.3
214: 97937 GIC riic.3
215: 0 GIC riic.3
216: 6076 GIC riic.3
217: 6052 GIC riic.3
218: 91 GIC riic.3
219: 0 GIC riic.3
220: 0 GIC riic.3
233: 0 GIC sh-sci.3:break
234: 0 GIC sh-sci.3:rx err
235: 202 GIC sh-sci.3:rx full
236: 1159 GIC sh-sci.3:tx empty
253: 0 GIC rz-can-err-g
258: 54925 GIC rz-can-rx
259: 0 GIC rz-can-err-m
260: 32 GIC rz-can-tx
270: 0 GIC sh_rspi.0-0
271: 0 GIC sh_rspi.0-1
272: 0 GIC sh_rspi.0-2
273: 0 GIC sh_rspi.1-0
274: 0 GIC sh_rspi.1-1
275: 0 GIC sh_rspi.1-2
276: 0 GIC sh_rspi.2-0
277: 0 GIC sh_rspi.2-1
278: 0 GIC sh_rspi.2-2
279: 0 GIC sh_rspi.3-0
280: 0 GIC sh_rspi.3-1
281: 0 GIC sh_rspi.3-2
282: 0 GIC sh_rspi.4-0
283: 0 GIC sh_rspi.4-1
284: 0 GIC sh_rspi.4-2
300: 12 GIC sh_mmc:error
301: 4 GIC sh_mmc:int
302: 0 GIC sh_mobile_sdhi.0
303: 52 GIC sh_mobile_sdhi.0
304: 0 GIC sh_mobile_sdhi.0
308: 0 GIC sh-rtc alarm
309: 0 GIC sh-rtc period
310: 0 GIC sh-rtc carry
Err: 0
Sorry for the long post, I'm trying to provide as much information as possible, I think that the solution is close.
According to section 12.5.5 of the User's manual, the WOVF bit is NOT cleared when a watchdog reset occurs. Thus, it needs to be cleared manually - or else a subsequent watchdog reset will not occur.
I see, though, that the Linux code clears it just before starting the watchdog - which is a bit cleaner than my method. I'll see if I can get that to work for me...
oops, you're right. sorry (was getting confused with another SoC).
That bit stays set so SW can know a WDT occurred.
Well, I can say that the reset code above is the only code in the BSP that writes to the WDT and it seems to work. I reset the board lot of times without having to press the button.
but, your issue is that you cast the address as a uint8_t *, not a uint16_t *
#define WRCSR_R (*(volatile uint8_t *)0xFCFE0004uL)
so...that's not going to clear anything.
Actually, no. According to the user manual, reads from the WRCSR register must be done as 8-bit reads. Even the Linux code does this. (I had to create the "WRCSR_R" macro myself - since the .h files from Renesas do not provide an 8-bit interface to that register).
Nevertheless, it looks like my new code is working just fine - so I'm off to my next (unrelated) problem.
Thanks!
Hi,
of course it can work by using a cached area, it is just that the mirrored addresses are not supported on the M target
Un-cached areas for the video buffers are easier to handle at first (since you don't have to do anything extra).
However for performance reasons I would recommend to use cached areas anyway.
It will depend on your MMU settings, likely you are going to setup the L1D as write-back.
So the only thing to take care of is, before you release the screen buffer back to the VDC5, to flush (write back) the L1D cache contents.
Otherwise you will get artefacts since the modified graphic contents might be likely in L1 data cache still, but the VDC5 (like all other bus masters) have no visibility of the MMU, so will fetch old data from the SRAM.
For example in a "graphics sample" application, you could do
WaitVsync((int32_t)VSYNC_WAIT_COUNT);
update_output_screen();
>> call here the L1D write back routines
regards
I had taken trail with A1/H RSK board and in that mirror RAM was used for lcd buffer and I had also observed that it doesn't work in cached RAM.
Now I want to modified my current A1/H BSP to A1/M which supposed to be the same because of pin to pin compatibility with A1H and the difference is only RAM capacity.
If you see RAM address mapping In Usermanual page no 2601 Table 53.1.It shows that Mirror RAM space is reserved for A1/M which means that we have only cached RAM.
Does LCD works in cached RAM space for A1/M??
Please note that the instructions specify to leave J11 "OPEN", but the picture shows it jumpered. I've tried both ways and neither seem to make a difference.
You want to leave J11 open, otherwise the RZ board will back feed 5 volts to the host PC on the VBUS pin. Remember, gadgets are not supposed to be driving the VCC line in a USB connector.
After you plug it in, after you do a "ifconfig -a", what do you see? Do you also have the kernel networking TCP/IP components enabled in the kernel?
The RZ/A1 BSP ships with some documentation that shows how to use the mini USB port 0 on the Dev Kit as an "Ethernet over USB" gadget. Those instructions can be found here:
https://github.com/renesas-rz/rskrza1_bsp/blob/master/doc/testing/usb-function.txt
We have 2 Dev Kits and have tried using the stock BSP and these instructions to work on both of them. Neither board shows a "usb0" network device and there are no kernel messages for the "g_ether: gadget". We must be doing something wrong but we have followed the instructions very carefully.
$ grep -i usb_eth .config
CONFIG_USB_ETH=y
CONFIG_USB_ETH_RNDIS=y
# CONFIG_USB_ETH_EEM is not set
$ lsusb
Bus 001 Device 001: ID 1d6b:0002
The kernel is being booted with the "usbgs=0" parameter:
$ cat /proc/cmdline
console=ttySC2,115200 console=tty0 ignore_loglevel usbgs=0 root=/dev/null rootflags=physaddr=0x18800000
When I plug in a mini usb, nothing happens. Here is a picture of one set. What could I be doing wrong? Thank you.
