[PATCH 2/2] spi: rspi: Replaces "n" by "len" in qspi_transfer_*()

[DongCV]

This patch replaced "n" by "len" bytes of data in qspi_transfer_in() and
qspi_transfer_out() function. This will make improving readability.

Signed-off-by: DongCV <cv-d...@jinso.co.jp>
---
 drivers/spi/spi-rspi.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/spi/spi-rspi.c b/drivers/spi/spi-rspi.c
index 2ee1301..bc3c868 100644
--- a/drivers/spi/spi-rspi.c
+++ b/drivers/spi/spi-rspi.c
@@ -808,7 +808,7 @@ static int qspi_transfer_out(struct rspi_data *rspi, struct 
spi_transfer *xfer)
for (i = 0; i < len; i++)
rspi_write_data(rspi, *tx++);
} else {
-   ret = rspi_pio_transfer(rspi, tx, NULL, n);
+   ret = rspi_pio_transfer(rspi, tx, NULL, len);
if (ret < 0)
return ret;
}
@@ -845,7 +845,7 @@ static int qspi_transfer_in(struct rspi_data *rspi, struct 
spi_transfer *xfer)
for (i = 0; i < len; i++)
*rx++ = rspi_read_data(rspi);
} else {
-   ret = rspi_pio_transfer(rspi, NULL, rx, n);
+   ret = rspi_pio_transfer(rspi, NULL, rx, len);
if (ret < 0)
return ret;
}
-- 
1.9.1

[PATCH 0/2 v4] spi: rspi: Fixes bogus received byte and replaces "n" by "len"

[DongCV]

Hi Mark,
Cc: Geert, Sergei

Thanks for your comments and advices.

I separated my patch into two patches as you've shown me.
These patches fix: 3be09bec42a800d4 "spi: rspi: supports 32bytes 
buffer for DUAL and QUAD". One of them is to fix bogus received byte 
into qspi_transfer_in(), and other is to replace "n" by "len" bytes of 
data in qspi_transfer_in()and qspi_transfer_out().
These patches were tested at v4.10-rc8 on Renesas Gen2 Lager board.

Please consider these patches to Renesas Rcar family.
Thank you.
Jinso/Dong.

DongCV (2):
  spi: rspi: Fixes bogus received byte in qspi_transfer_in()
  spi: rspi: Replaces "n" by "len" in qspi_transfer_in() and
qspi_transfer_out()

 drivers/spi/spi-rspi.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

-- 
1.9.1

[PATCH v4] spi: rspi: Fixes bogus received byte in qspi_transfer_in()

[DongCV]

In qspi_transfer_in(), when receiving the last n (or len) bytes of data,
1 bogus byte was written in the receive buffer.
This code leads to a buffer overflow.

"jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x03b4: 
0x1900 instead
 jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x03b40004: 
0x000c instead"

The error message above happens when trying to mount, unmount, and remount a 
jffs2-formatted device.
This patch removed the bogus write to fixes: 3be09bec42a800d4
"spi: rspi: supports 32bytes buffer for DUAL and QUAD"

And here is Geert's comment:

"May I suggest the following:

spi: rspi: Fix bogus received byte in qspi_transfer_in()

When there are less than QSPI_BUFFER_SIZE remaining bytes to be received,
qspi_transfer_in() writes one bogus byte in the receive buffer, possibly
leading to a buffer overflow.

This can be reproduced by mounting, unmounting, and remounting a
jffs2-formatted device, causing lots of warnings like:

   jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found
   at 0x03b4: 0x1900 instead

Remove the bogus write to fix this. "

Signed-off-by: DongCV <cv-d...@jinso.co.jp>

Reviewed-by: Geert Uytterhoeven <geert+rene...@glider.be>
---
 drivers/spi/spi-rspi.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/spi/spi-rspi.c b/drivers/spi/spi-rspi.c
index 9daf500..2ee1301 100644
--- a/drivers/spi/spi-rspi.c
+++ b/drivers/spi/spi-rspi.c
@@ -848,7 +848,6 @@ static int qspi_transfer_in(struct rspi_data *rspi, struct 
spi_transfer *xfer)
ret = rspi_pio_transfer(rspi, NULL, rx, n);
if (ret < 0)
return ret;
-   *rx++ = ret;
}
n -= len;
}
-- 
1.9.1

Re: [PATCH] spi: rspi: fix the bug related to mount/remount jffs2

[DongCV]

Dear Geert,

Thank you for your reply.


diff --git a/drivers/spi/spi-rspi.c b/drivers/spi/spi-rspi.c
index 9daf500..2ee1301 100644
--- a/drivers/spi/spi-rspi.c
+++ b/drivers/spi/spi-rspi.c
@@ -848,7 +848,6 @@ static int qspi_transfer_in(struct rspi_data *rspi, struct 
spi_transfer *xfer)
   ret = rspi_pio_transfer(rspi, NULL, rx, n);
   if (ret < 0)
   return ret;
- *rx++ = ret;

Storing the success code (0) in the receive buffer is indeed wrong.

However, there are other bugs in that code:

rspi_pio_transfer(rspi, NULL, rx, n) transfers n bytes instead of len,
while n is decreased by len (which is <= n).
Furthermore rx is not incremented.
Hence if len < n, n will still be non-zero, and a new iteration of the
loop will be started, trying to receive more data, and overwriting the
just filled buffer.

The same bug is present in qspi_transfer_out().


   }
   n -= len;
   }
--
1.9.1


(nip)

Apart from sending patches inline, my comments from
https://www.spinics.net/lists/linux-spi/msg09753.html are still valid.


Sorry I might not understand your explanation correctly. Could you 
please explain it more details?
(Because I've tried to understand your explanation then analyzed the 
source code again as below:

https://patchwork.kernel.org/patch/9541629/)

Thank you.
Dong



On 02/06/2017 08:02 PM, Geert Uytterhoeven wrote:

Hi Dong,

On Mon, Feb 6, 2017 at 2:02 AM, DongCV <cv-d...@jinso.co.jp> wrote:

From: Dong <cv-d...@jinso.co.jp>

This patch fixes the output warning logs and data loss when
performing mount/umount then remount the device with jffs2 format.

This is the warning logs when performing mount/umount then remount the device 
with jffs2 format:
"root@linaro-naro:~# mount -t jffs2 /dev/mtdblock2 /mnt/media
[ 3839.928013] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found 
at 0x03b4: 0x1900 instead
[ 3839.956515] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found 
at 0x03b40004: 0x000c instead
[ 3839.985009] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found 
at 0x03b40008: 0xb0b1 instead
[ 3840.013591] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found 
at 0x03b4000c: 0x1900 instead
[ 3840.042087] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found 
at 0x03b40010: 0x0044 instead
[ 3840.070566] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found 
at 0x03b40014: 0xfb1d instead
[ 3840.099159] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found 
at 0x03b40018: 0x0002 instead
[ 3840.127604] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found 
at 0x03b4001c: 0x0001 instead
[ 3840.156043] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found 
at 0x03b40020: 0x81a4 instead
[ 3840.184472] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found 
at 0x03b4002c: 0x6529 instead
[ 3840.212900] jffs2: Further such events for this erase block will not be 
printed
[ 3840.322915] jffs2: notice: (2008) read_dnode: node CRC failed on dnode at 
0x3b40080: read 0xc40b5dfc, calculated 0x264be003
root@linaro-naro[ 3840.356857] jffs2: warning: (2008) 
jffs2_do_read_inode_internal: no data nodes found for ino #2
:~# [ 3840.386659] jffs2: Returned error for crccheck of ino #2. Expect 
badness...

Signed-off-by: Dong <cv-d...@jinso.co.jp>
---
  drivers/spi/spi-rspi.c | 1 -
  1 file changed, 1 deletion(-)

diff --git a/drivers/spi/spi-rspi.c b/drivers/spi/spi-rspi.c
index 9daf500..2ee1301 100644
--- a/drivers/spi/spi-rspi.c
+++ b/drivers/spi/spi-rspi.c
@@ -848,7 +848,6 @@ static int qspi_transfer_in(struct rspi_data *rspi, struct 
spi_transfer *xfer)
 ret = rspi_pio_transfer(rspi, NULL, rx, n);
 if (ret < 0)
 return ret;
-   *rx++ = ret;
 }
 n -= len;
 }

Apart from sending patches inline, my comments from
https://www.spinics.net/lists/linux-spi/msg09753.html are still valid.

Gr{oetje,eeting}s,

 Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
 -- Linus Torvalds

[PATCH] spi: rspi: fix the bug related to mount/remount jffs2

[DongCV]

From: Dong 

This patch fixes the output warning logs and data loss when
performing mount/umount then remount the device with jffs2 format.

This is the warning logs when performing mount/umount then remount the device 
with jffs2 format:
"root@linaro-naro:~# mount -t jffs2 /dev/mtdblock2 /mnt/media
[ 3839.928013] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found 
at 0x03b4: 0x1900 instead
[ 3839.956515] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found 
at 0x03b40004: 0x000c instead
[ 3839.985009] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found 
at 0x03b40008: 0xb0b1 instead
[ 3840.013591] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found 
at 0x03b4000c: 0x1900 instead
[ 3840.042087] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found 
at 0x03b40010: 0x0044 instead
[ 3840.070566] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found 
at 0x03b40014: 0xfb1d instead
[ 3840.099159] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found 
at 0x03b40018: 0x0002 instead
[ 3840.127604] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found 
at 0x03b4001c: 0x0001 instead
[ 3840.156043] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found 
at 0x03b40020: 0x81a4 instead
[ 3840.184472] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found 
at 0x03b4002c: 0x6529 instead
[ 3840.212900] jffs2: Further such events for this erase block will not be 
printed
[ 3840.322915] jffs2: notice: (2008) read_dnode: node CRC failed on dnode at 
0x3b40080: read 0xc40b5dfc, calculated 0x264be003
root@linaro-naro[ 3840.356857] jffs2: warning: (2008) 
jffs2_do_read_inode_internal: no data nodes found for ino #2
:~# [ 3840.386659] jffs2: Returned error for crccheck of ino #2. Expect 
badness...

Signed-off-by: Dong 
---
 drivers/spi/spi-rspi.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/spi/spi-rspi.c b/drivers/spi/spi-rspi.c
index 9daf500..2ee1301 100644
--- a/drivers/spi/spi-rspi.c
+++ b/drivers/spi/spi-rspi.c
@@ -848,7 +848,6 @@ static int qspi_transfer_in(struct rspi_data *rspi, struct 
spi_transfer *xfer)
ret = rspi_pio_transfer(rspi, NULL, rx, n);
if (ret < 0)
return ret;
-   *rx++ = ret;
}
n -= len;
}
-- 
1.9.1

Re: [Lager(H2)-V4.10-rc2]: DISPLAY-UNIT: Does not support 640x480 resolution & Does not support 16-bit for color numbers.

[DongCV]

Dear Laurent,

I apologize for the delayed response.
I've understoodyour opinion. Thank you very much.

Regards,
Dong


On 01/31/2017 06:47 PM, Laurent Pinchart wrote:

Hello Dong,

On Tuesday 31 Jan 2017 15:49:34 DongCV wrote:

DearLaurent,
cc: Geert


Cfr. Laurent Pinchart's answer in the thread "Re: The failure summary

report of GEN2 for linux stable v4.10-rc2":
| I confirm your analysis. However, I think this isn't a new issue. Before
| the aforementioned patch, running
|
| # fbset -xres 640 -yres 480 -laced 0
| # fbset -depth 16 -rgba 5,6,5,0
|
| didn't produce any error, but didn't either resize the display to
| 640x480 or changed the pixel format. With the patch applied, the
| commands are rejected as they should be, as they wouldn't produce the
| expected results. The new behaviour is thus in my opinion correct.

http://www.mail-archive.com/linux-renesas-soc@vger.kernel.org/msg10879.htm
l

I understood your opinion.
However,I wonder why the display size has changed when I implement the
following test procedure.
Could you explain it to me?

* Changed the resolution.
- Perform the following command:
# bmap / dev / fb0 hdmi.bmp (Initial default size is 1024x768.  Please
have look at 1024x768.jpg image)
# fbset -xres 640 -yres 480 -laced 0
# bmap / dev / fb0 hdmi.bmp

I saw the screen size has changed after running the following command.
"#fbset -xres -laced 0 480 640 -yres"(Please have look at 640x480.jpg image)
but I run the following command again
"#bmap / dev / fb0 hdmi.bmp", the image size did not change.

Implement similarly with the 800x600 resolution. (Please have look at
800x600.jpg image)

That's because the screen resolution has not changed. Only the size reported
to the fbdev emulation layer is updated, the screen resolution and framebuffer
stay the same. This is exactly why changing the resolution through the fbdev
device has been disabled recently, it just didn't work. This is a feature that
will never be supported and should thus not be used.

The purpose of the fbdev compatibility layer is to enable the framebuffer
kernel console on top of a DRM/KMS device. The userspace API is available for
applications to use, but they should not expect the full feature set of fbdev.
Applications should be migrated to DRM/KMS.


* Changed the pixel format.
- Perform the following command:
# fbset -depth 16 -rgba 5,6,5,0
# bmap /dev/fb0 hdmi.bmp

(Please have look at pixel_16bit.jpg image)

# fbset -depth 32 -rgba 5,6,5,0
# bmap /dev/fb0 hdmi.bmp

(Please have look at pixel_32bit.jpg image)

I realize that 16bit set image differs from 32bit set image.

Please have a look at the attached image for detail.

This isn't supported for the same reason as above.

[Lager(H2)-V4.10-rc2]: DISPLAY-UNIT: Does not support 640x480 resolution & Does not support 16-bit for color numbers.

[DongCV]

Dear Stefan,
Cc: Geert,

I've tested the linux v4.10-rc2 for Gen2 Lager and found two issues 
about DISPLAY-UNIT:  Does not support 640x480 resolution & Does not 
support 16-bit for color numbers.


"root@linaro-naro:~# fbset -xres 640 -yres 480 -laced 0
 ioctl FBIOPUT_VSCREENINFO: Invalid argument"

"root@linaro-naro:~# fbset -depth 16 -rgba 5,6,5,0
 ioctl FBIOPUT_VSCREENINFO: Invalid argument"


And I found the patch which I think it is the cause of this issues.
The commit name is '865afb1 drm/fb-helper: reject any changes to the fbdev'
If I reverted this patch and retested it on H2 board, the issue will be 
gone!


Please have a look at the attached testlog file for detail.


Regards,
Dong

LAGER SPI_LOADER V0.27 2014.06.20
DEVICE S25FL512


U-Boot 2016.01 (Jul 27 2016 - 15:27:42 +0900)

CPU: Renesas Electronics R8A7790 rev 2.0
Board: Lager
I2C:   ready
DRAM:  512 MiB
MMC:   sh_mmcif: 0, sh-sdhi: 1, sh-sdhi: 2
SF: Detected S25FL512S_256K with page size 512 Bytes, erase size 256 KiB, total 
64 MiB
In:serial_sh
Out:   serial_sh
Err:   serial_sh
Net:   sh_eth
Hit any key to stop autoboot:  0 
sh_eth Waiting for PHY auto negotiation to complete.. done
sh_eth: 100Base/Half
BOOTP broadcast 1
BOOTP broadcast 2
BOOTP broadcast 3
BOOTP broadcast 4
BOOTP broadcast 5
BOOTP broadcast 6
DHCP client bound to address 192.168.1.235 (5781 ms)
Using sh_eth device
TFTP from server 192.168.1.225; our IP address is 192.168.1.235
Filename 'lager/uImage.dtb'.
Load address: 0x40007fc0
Loading: #
 #
 #
 #
 7.5 MiB/s
done
Bytes transferred = 3750536 (393a88 hex)
## Booting kernel from Legacy Image at 40007fc0 ...
   Image Name:   Linux-v4.10-rc2
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:3750472 Bytes = 3.6 MiB
   Load Address: 40008000
   Entry Point:  40008000
   Verifying Checksum ... OK
   XIP Kernel Image ... OK

Starting kernel ...

[0.00] Booting Linux on physical CPU 0x0
[0.00] Linux version 4.10.0-rc2-dirty (dong@dong-Jinso) (gcc version 
4.8.4 (Ubuntu/Linaro 4.8.4-2ubuntu1~14.04.1) ) #275 SMP Thu Jan 19 13:29:13 JST 
2017
[0.00] CPU: ARMv7 Processor [413fc0f2] revision 2 (ARMv7), cr=10c5387d
[0.00] CPU: div instructions available: patching division code
[0.00] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
[0.00] OF: fdt:Machine model: Lager
[0.00] OF: fdt:Ignoring memory block 0x14000 - 0x2
[0.00] debug: ignoring loglevel setting.
[0.00] Memory policy: Data cache writealloc
[0.00] On node 0 totalpages: 262144
[0.00] free_area_init_node: node 0, pgdat c0a32840, node_mem_map 
ef7f9000
[0.00]   Normal zone: 1536 pages used for memmap
[0.00]   Normal zone: 0 pages reserved
[0.00]   Normal zone: 196608 pages, LIFO batch:31
[0.00]   HighMem zone: 65536 pages, LIFO batch:15
[0.00] percpu: Embedded 12 pages/cpu @ef775000 s25152 r0 d24000 u49152
[0.00] pcpu-alloc: s25152 r0 d24000 u49152 alloc=12*4096
[0.00] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 [0] 4 [0] 5 [0] 6 [0] 7 
[0.00] Built 1 zonelists in Zone order, mobility grouping on.  Total 
pages: 260608
[0.00] Kernel command line: console=ttySC0,38400 ignore_loglevel rw 
root=/dev/nfs ip=dhcp
[0.00] PID hash table entries: 4096 (order: 2, 16384 bytes)
[0.00] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
[0.00] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
[0.00] Memory: 1029252K/1048576K available (6144K kernel code, 207K 
rwdata, 1488K rodata, 1024K init, 300K bss, 19324K reserved, 0K cma-reserved, 
262144K high)
[0.00] Virtual kernel memory layout:
[0.00] vector  : 0x - 0x1000   (   4 kB)
[0.00] fixmap  : 0xffc0 - 0xfff0   (3072 kB)
[0.00] vmalloc : 0xf080 - 0xff80   ( 240 MB)
[0.00] lowmem  : 0xc000 - 0xf000   ( 768 MB)
[0.00] pkmap   : 0xbfe0 - 0xc000   (   2 MB)
[0.00]   .text : 0xc0008000 - 0xc070   (7136 kB)
[0.00]   .init : 0xc090 - 0xc0a0   (1024 kB)
[0.00]   .data : 0xc0a0 - 0xc0a33c60   ( 208 kB)
[0.00].bss : 0xc0a35000 - 0xc0a8020c   ( 301 kB)
[0.00] Hierarchical RCU implementation.
[0.00]  Build-time adjustment of leaf fanout to 32.
[0.00] NR_IRQS:16 nr_irqs:16 16
[0.00] arm_arch_timer: Architected cp15 timer(s) running at 10.00MHz 
(virt).
[0.00] clocksource: arch_sys_counter: mask: 0xff 
max_cycles: 0x24e6a1710, max_idle_ns: 440795202120 ns
[0.04] sched_clock: 56 

[Lager(H2)-V4.10-rc2]: QSPI-FLASH: Warning message happened when writing a data file to SPI-FLASH

[DongCV]

Dear Michal,
Cc: Geert,

I've tested the linux v4.10-rc2 for Gen2 Lager and found an issues when 
writing data to SPI-FLASH with jffs2 format


"root@linaro-naro:~# cp test.dat /mnt/media
[  223.874078] [ cut here ]
[  223.888017] WARNING: CPU: 2 PID: 2008 at 
drivers/mtd/spi-nor/spi-nor.c:1182 spi_nor_write+0x84/0x160
[  223.915507] Writing at offset 12 into a NOR page. Writing partial 
pages may decrease reliability and increase wear of NOR flash.

[  223.915543] CPU: 2 PID: 2008 Comm: cp Not tainted 4.10.0-rc2-dirty #166
[  223.970037] Hardware name: Generic R8A7790 (Flattened Device Tree)
[  223.988563] Backtrace:
[  223.995934] [] (dump_backtrace) from [] 
(show_stack+0x18/0x1c)

[  224.018639]  r6:c04786f0 r5: r4:600f0013 r3:00404000
[  224.035626] [] (show_stack) from [] 
(dump_stack+0x80/0xa0)
[  224.057294] [] (dump_stack) from [] 
(__warn+0xd4/0x104)

[  224.078169]  r5: r4:ef203ba8
[  224.088894] [] (__warn) from [] 
(warn_slowpath_fmt+0x40/0x48)
[  224.111337]  r9:c0a2a6cb r8:ef203c8c r7:000c r6: 
r5: r4:eebfa418
[  224.134564] [] (warn_slowpath_fmt) from [] 
(spi_nor_write+0x84/0x160)

..."

Please have a look at the attached testlog file for detail.

And I found the patch which I think it is the cause of this issues.
The commit name is 'e5d05cb mtd: spi-nor: simplify write loop'
If I reverted this patch and retested it on H2 board, the issue will be 
gone!


Regards,
Dong



LAGER SPI_LOADER V0.27 2014.06.20
DEVICE S25FL512


U-Boot 2016.01 (Jul 27 2016 - 15:27:42 +0900)

CPU: Renesas Electronics R8A7790 rev 2.0
Board: Lager
I2C:   ready
DRAM:  512 MiB
MMC:   sh_mmcif: 0, sh-sdhi: 1, sh-sdhi: 2
SF: Detected S25FL512S_256K with page size 512 Bytes, erase size 256 KiB, total 
64 MiB
In:serial_sh
Out:   serial_sh
Err:   serial_sh
Net:   sh_eth
Hit any key to stop autoboot:  0 
sh_eth Waiting for PHY auto negotiation to complete.. done
sh_eth: 100Base/Half
BOOTP broadcast 1
BOOTP broadcast 2
BOOTP broadcast 3
BOOTP broadcast 4
BOOTP broadcast 5
BOOTP broadcast 6
DHCP client bound to address 192.168.1.235 (5781 ms)
Using sh_eth device
TFTP from server 192.168.1.225; our IP address is 192.168.1.235
Filename 'lager/uImage.dtb'.
Load address: 0x40007fc0
Loading: #
 #
 #
 #
 ###
 7.5 MiB/s
done
Bytes transferred = 3974248 (3ca468 hex)
## Booting kernel from Legacy Image at 40007fc0 ...
   Image Name:   Linux-v4.10-rc2
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:3974184 Bytes = 3.8 MiB
   Load Address: 40008000
   Entry Point:  40008000
   Verifying Checksum ... OK
   XIP Kernel Image ... OK

Starting kernel ...

[0.00] Booting Linux on physical CPU 0x0
[0.00] Linux version 4.10.0-rc2-dirty (dong@dong-Jinso) (gcc version 
4.8.4 (Ubuntu/Linaro 4.8.4-2ubuntu1~14.04.1) ) #277 SMP Thu Jan 19 13:50:19 JST 
2017
[0.00] CPU: ARMv7 Processor [413fc0f2] revision 2 (ARMv7), cr=10c5387d
[0.00] CPU: div instructions available: patching division code
[0.00] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
[0.00] OF: fdt:Machine model: Lager
[0.00] OF: fdt:Ignoring memory block 0x14000 - 0x2
[0.00] debug: ignoring loglevel setting.
[0.00] Memory policy: Data cache writealloc
[0.00] On node 0 totalpages: 262144
[0.00] free_area_init_node: node 0, pgdat c0a32e80, node_mem_map 
ef7f9000
[0.00]   Normal zone: 1536 pages used for memmap
[0.00]   Normal zone: 0 pages reserved
[0.00]   Normal zone: 196608 pages, LIFO batch:31
[0.00]   HighMem zone: 65536 pages, LIFO batch:15
[0.00] percpu: Embedded 12 pages/cpu @ef775000 s25152 r0 d24000 u49152
[0.00] pcpu-alloc: s25152 r0 d24000 u49152 alloc=12*4096
[0.00] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 [0] 4 [0] 5 [0] 6 [0] 7 
[0.00] Built 1 zonelists in Zone order, mobility grouping on.  Total 
pages: 260608
[0.00] Kernel command line: console=ttySC0,38400 ignore_loglevel rw 
root=/dev/nfs ip=dhcp
[0.00] PID hash table entries: 4096 (order: 2, 16384 bytes)
[0.00] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
[0.00] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
[0.00] Memory: 1029248K/1048576K available (6144K kernel code, 208K 
rwdata, 1548K rodata, 1024K init, 303K bss, 19328K reserved, 0K cma-reserved, 
262144K high)
[0.00] Virtual kernel memory layout:
[0.00] vector  : 0x - 0x1000   (   4 kB)
[0.00] fixmap  : 0xffc0 - 0xfff0   (3072 kB)
[0.00] vmalloc : 0xf080 - 

Re: The failure summary report of GEN2 for linux stable v4.10-rc2

[DongCV]

Dear Mr Laurent,

Thank you for your quick reply.
This is the log file contains information about the command "modetest -M 
rcar-du" (with the HDMI cable plugged).

Thank you very much.

Jinso Linux team
Dong


On 01/20/2017 08:49 AM, Laurent Pinchart wrote:

Dear Dong,

On Thursday 19 Jan 2017 18:14:45 DongCV wrote:

Dear Mr Laurent

I apologize for the misunderstanding.

No worries, I should have been more precise.


I've retested the HDMI output on Lager(H2) with v4.10-rc2.

The results:

Enabled CMA:

The HDMI cable unplugged: Could not recognize the display.
The HDMI cable plugged: Recognized the display-> test fail.

The VGA cable unplugged: Recognized the display-> test ok.
The VGA cable plugged: Recognized the display-> test ok.


Disabled CMA: The same to the case of enabled CMA.

I attach the test procedures and test tool, test result.
Please have a look at it.

I've followed the same test procedure:

- Check out kernel v4.10-rc2
- Compile the kernel with the CONFIG_CMA_ENABLE.txt you have provided
- Disconnect the VGA and HDMI cables
- Turn the power on to the Lager board, let it boot
- Plug the HDMI cable
- Run 'bmap /dev/fb0 hdmi.bmp' with the hdmi.bmp file you have provided

The output on the display is fine, identical to your 'VGA_Image.jpg' picture.

At this point I believe the key difference between our setups is the HDMI
monitor. Could you please send me the output of

modetest -M rcar-du

with the HDMI cable plugged ?



LAGER SPI_LOADER V0.27 2014.06.20
DEVICE S25FL512


U-Boot 2016.01 (Jul 27 2016 - 15:27:42 +0900)

CPU: Renesas Electronics R8A7790 rev 2.0
Board: Lager
I2C:   ready
DRAM:  512 MiB
MMC:   sh_mmcif: 0, sh-sdhi: 1, sh-sdhi: 2
SF: Detected S25FL512S_256K with page size 512 Bytes, erase size 256 KiB, total 
64 MiB
In:serial_sh
Out:   serial_sh
Err:   serial_sh
Net:   sh_eth
Hit any key to stop autoboot:  0 
sh_eth Waiting for PHY auto negotiation to complete.. done
sh_eth: 100Base/Half
BOOTP broadcast 1
BOOTP broadcast 2
BOOTP broadcast 3
BOOTP broadcast 4
BOOTP broadcast 5
BOOTP broadcast 6
DHCP client bound to address 192.168.1.235 (5781 ms)
Using sh_eth device
TFTP from server 192.168.1.225; our IP address is 192.168.1.235
Filename 'lager/uImage.dtb'.
Load address: 0x40007fc0
Loading: #
 #
 #
 #
 7.2 MiB/s
done
Bytes transferred = 3750536 (393a88 hex)
## Booting kernel from Legacy Image at 40007fc0 ...
   Image Name:   Linux-v4.10-rc2
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:3750472 Bytes = 3.6 MiB
   Load Address: 40008000
   Entry Point:  40008000
   Verifying Checksum ... OK
   XIP Kernel Image ... OK

Starting kernel ...

[0.00] Booting Linux on physical CPU 0x0
[0.00] Linux version 4.10.0-rc2-dirty (dong@dong-Jinso) (gcc version 
4.8.4 (Ubuntu/Linaro 4.8.4-2ubuntu1~14.04.1) ) #327 SMP Fri Jan 20 11:30:16 JST 
2017
[0.00] CPU: ARMv7 Processor [413fc0f2] revision 2 (ARMv7), cr=10c5387d
[0.00] CPU: div instructions available: patching division code
[0.00] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
[0.00] OF: fdt:Machine model: Lager
[0.00] OF: fdt:Ignoring memory block 0x14000 - 0x2
[0.00] debug: ignoring loglevel setting.
[0.00] Memory policy: Data cache writealloc
[0.00] On node 0 totalpages: 262144
[0.00] free_area_init_node: node 0, pgdat c0a32840, node_mem_map 
ef7f9000
[0.00]   Normal zone: 1536 pages used for memmap
[0.00]   Normal zone: 0 pages reserved
[0.00]   Normal zone: 196608 pages, LIFO batch:31
[0.00]   HighMem zone: 65536 pages, LIFO batch:15
[0.00] percpu: Embedded 12 pages/cpu @ef775000 s25152 r0 d24000 u49152
[0.00] pcpu-alloc: s25152 r0 d24000 u49152 alloc=12*4096
[0.00] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 [0] 4 [0] 5 [0] 6 [0] 7 
[0.00] Built 1 zonelists in Zone order, mobility grouping on.  Total 
pages: 260608
[0.00] Kernel command line: console=ttySC0,38400 ignore_loglevel rw 
root=/dev/nfs ip=dhcp
[0.00] PID hash table entries: 4096 (order: 2, 16384 bytes)
[0.00] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
[0.00] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
[0.00] Memory: 1029252K/1048576K available (6144K kernel code, 207K 
rwdata, 1488K rodata, 1024K init, 300K bss, 19324K reserved, 0K cma-reserved, 
262144K highmem)
[0.00] Virtual kernel memory layout:
[0.00] vector  : 0x - 0x1000   (   4 kB)
[0.00] fixmap  : 0xffc0 - 0xfff0   (3072 kB)
[0.00] vmalloc : 0xf080 - 0xff80   ( 24

Re: The failure summary report of GEN2 for linux stable v4.10-rc2

[DongCV]

Hi Laurent,

I found the patch which I think it is the cause of the issues "Does not 
support 640x480 resolution &

Does not support 16-bit color for numbers," that I have reported.
The commit name is '865afb1 drm/fb-helper: reject any changes to the fbdev'
If I reverted this patch and retested it on H2 board, the issue will be 
gone!.


Best regards,
Dong


On 01/17/2017 03:05 PM, DongCV wrote:

Dear Mr Laurent

Thank you for your quick reply.
I've retested the HDMI output on Lager(H2) with v4.10-rc2.

The results:

Enabled CMA:

The HDMI cable unplugged: Could not recognize the display.
The HDMI cable plugged: Recognized the display-> test fail.

The VGA cable unplugged: Recognized the display-> test fail.
The VGA cable plugged: Recognized the display-> test fail.


Disabled CMA: The same to the case of enabled CMA.

I attach the test procedures and test tool, test result.
Please have a look at it.

Thank you very much.

Jinso Linux team
Dong


On 01/17/2017 12:34 AM, Laurent Pinchart wrote:

Hello Dong,

On Monday 16 Jan 2017 18:29:30 カオ・ヴァン・ドン wrote:

Hi all,

We have tested the linux v4.10-rc2 for Gen2 Lager and Koelsch

So we would like to report the summary of the failure.

Thank you for the report.

I've retested the HDMI output on Lager running v4.10-rc2 with
shmobile_defconfig using your test method (with the bmap application) 
and I
haven't been to reproduce the problem. I have also tested v4.8 and 
v4.9, and

both worked fine as well.

The kernel was started with the HDMI cable unplugged in all tests. If 
I boot
the board with the cable plugged in, framebuffer allocation fails due 
to CMA
being disabled. Enabling CMA makes the test pass on all three 
kernels, both

with the HDMI cable plugged at boot and plugged after boot.

If you can still reproduce the problem on your side, could you please 
provide
me with a very detailed test procedure (including the kernel .config 
and any

test application or data you're using) ?





LAGER SPI_LOADER V0.27 2014.06.20
DEVICE S25FL512


U-Boot 2016.01 (Jul 27 2016 - 15:27:42 +0900)

CPU: Renesas Electronics R8A7790 rev 2.0
Board: Lager
I2C:   ready
DRAM:  512 MiB
MMC:   sh_mmcif: 0, sh-sdhi: 1, sh-sdhi: 2
SF: Detected S25FL512S_256K with page size 512 Bytes, erase size 256 KiB, total 
64 MiB
In:serial_sh
Out:   serial_sh
Err:   serial_sh
Net:   sh_eth
Hit any key to stop autoboot:  0 
sh_eth Waiting for PHY auto negotiation to complete.. done
sh_eth: 100Base/Half
BOOTP broadcast 1
BOOTP broadcast 2
BOOTP broadcast 3
BOOTP broadcast 4
BOOTP broadcast 5
BOOTP broadcast 6
DHCP client bound to address 192.168.1.235 (5782 ms)
Using sh_eth device
TFTP from server 192.168.1.225; our IP address is 192.168.1.235
Filename 'lager/uImage.dtb'.
Load address: 0x40007fc0
Loading: #
 #
 #
 #
 7.5 MiB/s
done
Bytes transferred = 3750520 (393a78 hex)
## Booting kernel from Legacy Image at 40007fc0 ...
   Image Name:   Linux-v4.10-rc2
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:3750456 Bytes = 3.6 MiB
   Load Address: 40008000
   Entry Point:  40008000
   Verifying Checksum ... OK
   XIP Kernel Image ... OK

Starting kernel ...

[0.00] Booting Linux on physical CPU 0x0
[0.00] Linux version 4.10.0-rc2-1-g7a2dceb-dirty (dong@dong-Jinso) 
(gcc version 4.8.4 (Ubuntu/Linaro 4.8.4-2ubuntu1~14.04.1) ) #242 SMP Wed Jan 18 
14:47:20 JST 2017
[0.00] CPU: ARMv7 Processor [413fc0f2] revision 2 (ARMv7), cr=10c5387d
[0.00] CPU: div instructions available: patching division code
[0.00] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
[0.00] OF: fdt:Machine model: Lager
[0.00] OF: fdt:Ignoring memory block 0x14000 - 0x2
[0.00] debug: ignoring loglevel setting.
[0.00] Memory policy: Data cache writealloc
[0.00] On node 0 totalpages: 262144
[0.00] free_area_init_node: node 0, pgdat c0a32840, node_mem_map 
ef7f9000
[0.00]   Normal zone: 1536 pages used for memmap
[0.00]   Normal zone: 0 pages reserved
[0.00]   Normal zone: 196608 pages, LIFO batch:31
[0.00]   HighMem zone: 65536 pages, LIFO batch:15
[0.00] percpu: Embedded 12 pages/cpu @ef775000 s25152 r0 d24000 u49152
[0.00] pcpu-alloc: s25152 r0 d24000 u49152 alloc=12*4096
[0.00] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 [0] 4 [0] 5 [0] 6 [0] 7 
[0.00] Built 1 zonelists in Zone order, mobility grouping on.  Total 
pages: 260608
[0.00] Kernel command line: console=ttySC0,38400 ignore_loglevel rw 
root=/dev/nfs ip=dhcp
[0.00] PID hash table entries: 4096 (order: 2, 16384 bytes)
[0.00] Dentry cache hash table en