[U-Boot] [PATCH] arm: socfpga: Fixes: Rename CONFIG_SPL_RESET_SUPPORT to CONFIG_SPL_DM_RESET

2018-07-12 Thread Ley Foon Tan
Commit bfc6bae8fa1f2d8a9c51548767b02f1a1e0ffe52

This commit rename CONFIG_SPL_RESET_SUPPORT to CONFIG_SPL_DM_RESET. Update
with new CONFIG name and enable CONFIG_SPL_DM_RESET when CONFIG_DM_RESET is 
enabled.

Signed-off-by: Ley Foon Tan 
Acked-by: Marek Vasut 

---
v3:
- Select SPL_DM_RESET when DM_RESET is enabled.

v2:
- Rename commit title, add "Fixes:" tag
- Add Acked-by from Marek
---
 arch/arm/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 5b3746c..05bf871 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -764,6 +764,7 @@ config ARCH_SOCFPGA
select DM_SERIAL
select ENABLE_ARM_SOC_BOOT0_HOOK if TARGET_SOCFPGA_GEN5 || 
TARGET_SOCFPGA_ARRIA10
select OF_CONTROL
+   select SPL_DM_RESET if DM_RESET
select SPL_LIBCOMMON_SUPPORT
select SPL_LIBDISK_SUPPORT
select SPL_LIBGENERIC_SUPPORT
@@ -772,7 +773,6 @@ config ARCH_SOCFPGA
select SPL_OF_CONTROL
select SPL_SERIAL_SUPPORT
select SPL_DM_SERIAL
-   select SPL_RESET_SUPPORT
select SPL_SPI_FLASH_SUPPORT if SPL_SPI_SUPPORT
select SPL_SPI_SUPPORT if DM_SPI
select SPL_WATCHDOG_SUPPORT
-- 
2.7.4

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH] mtd: nand: denali: Replace the ad-hoc cache management with bouncebuf

2018-07-12 Thread Masahiro Yamada
2018-07-12 21:51 GMT+09:00 Marek Vasut :
> On 06/20/2018 09:14 AM, Masahiro Yamada wrote:
>> Hi Marek,
>
> Hi!
>
>> 2018-06-20 13:43 GMT+09:00 Marek Vasut :
>>> On 06/19/2018 08:39 AM, Masahiro Yamada wrote:
 Hi Marek,
>>>
>>> Hi,
>>>
 2018-06-08 5:17 GMT+09:00 Marek Vasut :
> Replace the ad-hoc DMA cache management functions with common bouncebuf,
> since those functions are not handling cases where unaligned buffer is
> passed in,


 Were you hit by a problem,
 or just-in-case replacement?
>>>
>>> Yes, UBI triggers unaligned cache operations on my system (SoCFPGA).
 I thought I took care of the buffer alignment.

 The bounce buffer is allocated by kmalloc():
 https://github.com/u-boot/u-boot/blob/v2018.05/drivers/mtd/nand/denali.c#L1348

 According to the lib/linux_compat.c implementation,
 it returns memory aligned with ARCH_DMA_MINALIGN.


 If the buffer is passed from the upper MTD layer,
 the NAND core also makes sure the enough alignment:
 https://github.com/u-boot/u-boot/blob/v2018.05/drivers/mtd/nand/denali.c#L1273

 This is how this driver works in Linux.

 I'd rather want to keep the current code
 unless this is a real problem,


 One possible clean-up is to move dma_(un)map_single to a common place.
>>> Is there any chance you can try UBI on the denali nand on uniphier ? :)
>>
>>
>> I tested the driver only for raw block devices.
>>
>> OK, I will test UBI on my platform.
>>
>> BTW, do you see the problem only in U-Boot?
>> Is the denali driver in Linux working fine?
>
> Bump on this one ?
>

Sorry for delay.


UBI is working for me without your patch.

Not sure what is the difference.

I will dig into it a little more, though.




-- 
Best Regards
Masahiro Yamada
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [Bug & Question] ubifs does not understand ".." in file path ?

2018-07-12 Thread Masahiro Yamada
Hi.


I was playing around with the ditro-boot on NAND + UBI.

I was hit by a problem when loading files from ubifs.


My 'extlinux.conf' script looks like this:

-
menu title UniPhier Boot Options.

timeout 5

default UniPhier

label UniPhier
  kernel ../Image
  initrd ../rootfs.cpio.gz
  fdtdir ..
--


As doc/README.distro says,
'extlinux.conf' is generally located in 'extlinux' subdirectory.

So, the paths to kernel, initrd, fdt usually contain '..'

This totally works fine when loading files
from a FAT-formated MMC device.

'run bootcmd_mmc0' successfully boots Linus
in the disto-boot manner.



However, 'run bootcmd_ubifs0' fails to boot.


=> run bootcmd_ubifs0
ubi0: attaching mtd1
ubi0: scanning is finished
ubi0: attached mtd1 (name "mtd=1", size 1023 MiB)
ubi0: PEB size: 262144 bytes (256 KiB), LEB size: 253952 bytes
ubi0: min./max. I/O unit sizes: 4096/4096, sub-page size 4096
ubi0: VID header offset: 4096 (aligned 4096), data offset: 8192
ubi0: good PEBs: 4088, bad PEBs: 4, corrupted PEBs: 0
ubi0: user volume: 1, internal volumes: 1, max. volumes count: 128
ubi0: max/mean erase counter: 1/0, WL threshold: 4096, image sequence
number: 1407739552
ubi0: available PEBs: 0, total reserved PEBs: 4088, PEBs reserved for
bad PEB handling: 76
UBIFS (ubi0:0): UBIFS: mounted UBI device 0, volume 0, name "boot", R/O mode
UBIFS (ubi0:0): LEB size: 253952 bytes (248 KiB), min./max. I/O unit
sizes: 4096 bytes/4096 bytes
UBIFS (ubi0:0): FS size: 1014284288 bytes (967 MiB, 3994 LEBs),
journal size 33521664 bytes (31 MiB, 132 LEBs)
UBIFS (ubi0:0): reserved for root: 4952683 bytes (4836 KiB)
UBIFS (ubi0:0): media format: w5/r0 (latest is w4/r0), UUID
cc8f68da-030d-408c-a91f-f8cc195a2946, small LPT model
Scanning ubi 0:...
Found /boot/extlinux/extlinux.conf
Retrieving file: /boot/extlinux/extlinux.conf
148 bytes read in 1 ms (144.5 KiB/s)
UniPhier Boot Options.
1:  UniPhier
Enter choice: 1:UniPhier
Retrieving file: /boot/extlinux/../rootfs.cpio.gz
Skipping UniPhier for failure retrieving initrd
SCRIPT FAILED: continuing...




The boot log says
it succeeded in loading '/boot/extlinux/extlinux.conf'
but failed in loading '/boot/extlinux/../rootfs.cpio.gz'



In my quick experiments,

load '/boot/extlinux/extlinux.conf'-> SUCCESS
load '/boot/extlinux/../rootfs.cpio.gz'-> FAILURE
load '/boot/rootfs.cpio.gz'-> SUCCESS
load '/boot/extlinux/../Image' -> FAILURE
load '/boot/Image' -> SUCCESS
load '/boot/extlinux/../uniphier-ld20-ref.dtb' -> FAILURE
load '/boot/uniphier-ld20-ref.dtb' -> SUCCESS



From the test results above,
my conclusion is loading a file path that contains '..' is not working.


Not sure where the root cause is.
Anybody who has insight about this?



-- 
Best Regards
Masahiro Yamada
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 1/3] dfu: Fix data abort in dfu_free_entities()

2018-07-12 Thread Andy Shevchenko
On Fri, Jul 13, 2018 at 1:10 AM, Sam Protsenko
 wrote:
> The story of this change goes further... Just checked the reason, the
> bug was introduced here [1]. So we can either use my patch (which adds
> corresponding comment to ensure we won't "fix" it later), or the whole
> design of dfu_config_entities() vs dfu_free_entities() should be
> revised.

Effectively you are reverting that commit, perhaps make it clear in
commit message that this is a revert.

>
> Lukasz, what do you think about this?
>
> [1] 
> http://git.denx.de/?p=u-boot.git;a=commit;h=5d8fae79163e94671956c99654abf48cf49757ba
>
> On Fri, Jul 13, 2018 at 12:52 AM, Sam Protsenko
>  wrote:
>> In case of error in dfu_config_entities(), it frees "dfu" array, which
>> leads to "data abort" in dfu_free_entities(), which tries to free the
>> same array (and even tries to access it from linked list first). The
>> issue occurs e.g. when partition table on device does not match
>> $dfu_alt_info layout:
>>
>> => dfu 0 mmc 1 list
>> Couldn't find part #2 on mmc device #1
>> DFU entities configuration failed!
>> data abort
>>
>> To fix this issue, do not free "dfu" array in dfu_config_entities(). It
>> will be freed later in dfu_free_entities().
>>
>> Signed-off-by: Sam Protsenko 
>> ---
>>  drivers/dfu/dfu.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/dfu/dfu.c b/drivers/dfu/dfu.c
>> index e7c91193b9..a3c09334b7 100644
>> --- a/drivers/dfu/dfu.c
>> +++ b/drivers/dfu/dfu.c
>> @@ -462,7 +462,7 @@ int dfu_config_entities(char *env, char *interface, char 
>> *devstr)
>> ret = dfu_fill_entity([i], s, alt_num_cnt, interface,
>>   devstr);
>> if (ret) {
>> -   free(dfu);
>> +   /* We will free "dfu" in dfu_free_entities() */
>> return -1;
>> }
>>
>> --
>> 2.18.0
>>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot



-- 
With Best Regards,
Andy Shevchenko
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 1/3] dfu: Fix data abort in dfu_free_entities()

2018-07-12 Thread Sam Protsenko
The story of this change goes further... Just checked the reason, the
bug was introduced here [1]. So we can either use my patch (which adds
corresponding comment to ensure we won't "fix" it later), or the whole
design of dfu_config_entities() vs dfu_free_entities() should be
revised.

Lukasz, what do you think about this?

[1] 
http://git.denx.de/?p=u-boot.git;a=commit;h=5d8fae79163e94671956c99654abf48cf49757ba

On Fri, Jul 13, 2018 at 12:52 AM, Sam Protsenko
 wrote:
> In case of error in dfu_config_entities(), it frees "dfu" array, which
> leads to "data abort" in dfu_free_entities(), which tries to free the
> same array (and even tries to access it from linked list first). The
> issue occurs e.g. when partition table on device does not match
> $dfu_alt_info layout:
>
> => dfu 0 mmc 1 list
> Couldn't find part #2 on mmc device #1
> DFU entities configuration failed!
> data abort
>
> To fix this issue, do not free "dfu" array in dfu_config_entities(). It
> will be freed later in dfu_free_entities().
>
> Signed-off-by: Sam Protsenko 
> ---
>  drivers/dfu/dfu.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/dfu/dfu.c b/drivers/dfu/dfu.c
> index e7c91193b9..a3c09334b7 100644
> --- a/drivers/dfu/dfu.c
> +++ b/drivers/dfu/dfu.c
> @@ -462,7 +462,7 @@ int dfu_config_entities(char *env, char *interface, char 
> *devstr)
> ret = dfu_fill_entity([i], s, alt_num_cnt, interface,
>   devstr);
> if (ret) {
> -   free(dfu);
> +   /* We will free "dfu" in dfu_free_entities() */
> return -1;
> }
>
> --
> 2.18.0
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 4/4 v2] arm64: ls1012a: enable DM support for sata

2018-07-12 Thread York Sun
On 06/04/2018 02:13 AM, andy.t...@nxp.com wrote:
> From: Yuantian Tang 
> 
> Enable related configs to support sata DM feature.
> 
> Signed-off-by: Tang Yuantian 
> ---
> v2:
> - add 2g5rdb and qds board support
> 
>  configs/ls1012a2g5rdb_qspi_defconfig  |6 +-
>  configs/ls1012aqds_qspi_defconfig |7 ++-
>  configs/ls1012ardb_qspi_SECURE_BOOT_defconfig |7 ++-
>  configs/ls1012ardb_qspi_defconfig |7 ++-
>  4 files changed, 23 insertions(+), 4 deletions(-)

Andy,

Does this set depend on something else? I got compiling error for all
these four boards

../drivers/ata/sata_ceva.c:10:31: fatal error: asm/arch/hardware.h: No
such file or directory

York
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH 3/3] dfu: Provide more verbose error message

2018-07-12 Thread Sam Protsenko
It might be useful for user to see some human-readable root cause
message in addition to "configuration failed" message, so that the issue
can be fixed quickly.

Signed-off-by: Sam Protsenko 
---
 drivers/dfu/dfu.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/dfu/dfu.c b/drivers/dfu/dfu.c
index 5b9abd685d..318949529b 100644
--- a/drivers/dfu/dfu.c
+++ b/drivers/dfu/dfu.c
@@ -71,6 +71,7 @@ int dfu_init_env_entities(char *interface, char *devstr)
ret = dfu_config_entities(env_bkp, interface, devstr);
if (ret) {
pr_err("DFU entities configuration failed!\n");
+   pr_err("(partition table does not match dfu_alt_info?)\n");
goto done;
}
 
-- 
2.18.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH 2/3] dfu: Fix memory leak in dfu_init_env_entities()

2018-07-12 Thread Sam Protsenko
In case of error in dfu_init_env_entities(), env_bkp will leak. Fix it
by providing single return path.

Signed-off-by: Sam Protsenko 
---
 drivers/dfu/dfu.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/dfu/dfu.c b/drivers/dfu/dfu.c
index a3c09334b7..5b9abd685d 100644
--- a/drivers/dfu/dfu.c
+++ b/drivers/dfu/dfu.c
@@ -56,7 +56,7 @@ int dfu_init_env_entities(char *interface, char *devstr)
 {
const char *str_env;
char *env_bkp;
-   int ret;
+   int ret = 0;
 
 #ifdef CONFIG_SET_DFU_ALT_INFO
set_dfu_alt_info(interface, devstr);
@@ -71,11 +71,12 @@ int dfu_init_env_entities(char *interface, char *devstr)
ret = dfu_config_entities(env_bkp, interface, devstr);
if (ret) {
pr_err("DFU entities configuration failed!\n");
-   return ret;
+   goto done;
}
 
+done:
free(env_bkp);
-   return 0;
+   return ret;
 }
 
 static unsigned char *dfu_buf;
-- 
2.18.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH 1/3] dfu: Fix data abort in dfu_free_entities()

2018-07-12 Thread Sam Protsenko
In case of error in dfu_config_entities(), it frees "dfu" array, which
leads to "data abort" in dfu_free_entities(), which tries to free the
same array (and even tries to access it from linked list first). The
issue occurs e.g. when partition table on device does not match
$dfu_alt_info layout:

=> dfu 0 mmc 1 list
Couldn't find part #2 on mmc device #1
DFU entities configuration failed!
data abort

To fix this issue, do not free "dfu" array in dfu_config_entities(). It
will be freed later in dfu_free_entities().

Signed-off-by: Sam Protsenko 
---
 drivers/dfu/dfu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/dfu/dfu.c b/drivers/dfu/dfu.c
index e7c91193b9..a3c09334b7 100644
--- a/drivers/dfu/dfu.c
+++ b/drivers/dfu/dfu.c
@@ -462,7 +462,7 @@ int dfu_config_entities(char *env, char *interface, char 
*devstr)
ret = dfu_fill_entity([i], s, alt_num_cnt, interface,
  devstr);
if (ret) {
-   free(dfu);
+   /* We will free "dfu" in dfu_free_entities() */
return -1;
}
 
-- 
2.18.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] Please pull from u-boot-i2c

2018-07-12 Thread Tom Rini
On Thu, Jul 12, 2018 at 04:11:11PM +0200, Heiko Schocher wrote:

> Hello Tom,
> 
> please pull from u-boot-i2c.git master
> 
> The following changes since commit 1612ff0dfba57b1002d8c7a54778eb553ace98f4:
> 
>   Merge branch 'master' of git://git.denx.de/u-boot-mips (2018-07-11 21:55:20 
> -0400)
> 
> are available in the Git repository at:
> 
>   git://git.denx.de/u-boot-i2c.git master
> 
> for you to fetch changes up to 971490c89251ae1a4a9e2a85911de5c217a4027c:
> 
>   lpi2c: Add bus busy error handling (2018-07-12 11:09:42 +0200)
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] Pull request: u-boot-ubi/master

2018-07-12 Thread Tom Rini
On Thu, Jul 12, 2018 at 11:17:45AM +0200, Heiko Schocher wrote:

> Hello Tom,
> 
> please pull from u-boot-ubi.git master
> 
> The following changes since commit 1612ff0dfba57b1002d8c7a54778eb553ace98f4:
> 
>   Merge branch 'master' of git://git.denx.de/u-boot-mips (2018-07-11 21:55:20 
> -0400)
> 
> are available in the Git repository at:
> 
>   git://git.denx.de/u-boot-ubi.git master
> 
> for you to fetch changes up to 5a08cfee3967d6e8174d7de135af1daa8e4aea00:
> 
>   ubifs: remove useless code (2018-07-12 07:27:34 +0200)
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] Please pull u-boot-dm

2018-07-12 Thread Stephen Warren

On 07/12/2018 12:17 PM, Stephen Warren wrote:

On 07/12/2018 09:52 AM, Stephen Warren wrote:

On 07/11/2018 06:12 PM, Simon Glass wrote:

Hi Stephen,

On 11 July 2018 at 16:01, Stephen Warren  wrote:

On 07/10/2018 02:24 PM, Simon Glass wrote:


Hi Stephen,

On 10 July 2018 at 13:53, Stephen Warren  
wrote:


On 07/10/2018 12:47 PM, Tom Rini wrote:



On Mon, Jul 09, 2018 at 01:53:43PM -0600, Simon Glass wrote:


Hi Tom.

Here are some test-coverage and DM core enhancements. Also it 
adds a

way to access the binman definition from U-Boot.


The following changes since commit
8c5d4fd0ec222701598a27b26ab7265d4cee45a3:

 Prepare v2018.07 (2018-07-09 10:24:14 -0400)

are available in the Git repository at:

 git://git.denx.de/u-boot-dm.git

for you to fetch changes up to
16b8d6b76992690c65c58dc8b0591496cc5e46ef:

 binman: Support updating the device tree with calc'd info
(2018-07-09 09:11:00 -0600)




This pull has caused intermittent/random build errors on my Jenkins
system.
The log shows:


    LD  spl/u-boot-spl
    OBJCOPY spl/u-boot-spl-nodtb.bin
    COPY    spl/u-boot-spl.bin
    BINMAN  u-boot-tegra.bin
    BINMAN  u-boot-nodtb-tegra.bin
    BINMAN  u-boot-dtb-tegra.bin
binman: pylibfdt error -9: FDT_ERR_BADMAGIC


/var/lib/jenkins/workspace/u-boot-denx_uboot-master-build/src/u-boot/Makefile:1244: 


recipe for target 'u-boot-tegra.bin' failed
make[1]: *** [u-boot-tegra.bin] Error 1
make[1]: *** Waiting for unfinished jobs
make[1]: Leaving directory

'/var/lib/jenkins/workspace/u-boot-denx_uboot-master-build/build/u-boot/beaver' 


Makefile:148: recipe for target 'sub-make' failed
make: *** [sub-make] Error 2
make: Leaving directory
'/var/lib/jenkins/workspace/u-boot-denx_uboot-master-build/src/u-boot' 





This doesn't happen every time; my Jenkins system builds 25 
Tegra/sandbox
boards, yet a varying set of boards fail each time I trigger the 
build:

Just
beaver the first time, then just colibri_t20 and ventana, then just
medcom-wide. Note that the system performs incremental builds, if 
that

matters.



That might be the fdt_resize() problem which David Gibson has just
sorted out upstream. If you can run binman -D (to get a stack trace)
that might help. I should be able to do a patch if that is the
problem.



Is this the backtrace you're looking for?


[swarren@swarren-lx1 u-boot]$
CROSS_COMPILE=/home/swarren/shared/gcc-linaro-7.2.1-2017.11-i686_arm-linux-gnueabihf/bin/arm-linux-gnueabihf- 

sh -c "make O=build-beaver -s beaver_defconfig && make 
O=build-beaver -s

-j8"
arch/arm/dts/tegra30-apalis.dtb: Warning 
(avoid_unnecessary_addr_size):
/i2c@7000d000/tps65911@2d/regulators: unnecessary 
#address-cells/#size-cells

without "ranges" or child "reg" property
arch/arm/dts/tegra30-beaver.dtb: Warning 
(avoid_unnecessary_addr_size):
/i2c@7000d000/tps65911@2d/regulators: unnecessary 
#address-cells/#size-cells

without "ranges" or child "reg" property
binman: pylibfdt error -9: FDT_ERR_BADMAGIC

Traceback (most recent call last):
   File "../tools/binman/binman", line 120, in RunBinman
 ret_code = control.Binman(options, args)
   File
"/home/swarren/shared/git_wa/tegra-uboot-flasher/u-boot/tools/binman/control.py", 


line 128, in Binman
 dtb = fdt.FdtScan(fname)
   File
"/home/swarren/shared/git_wa/tegra-uboot-flasher/u-boot/tools/binman/../dtoc/fdt.py", 


line 459, in FdtScan
 dtb = Fdt(fname)
   File
"/home/swarren/shared/git_wa/tegra-uboot-flasher/u-boot/tools/binman/../dtoc/fdt.py", 


line 315, in __init__
 self._fdt_obj = libfdt.Fdt(fd.read())
   File "scripts/dtc/pylibfdt/libfdt.py", line 207, in __init__
 check_err(fdt_check_header(self._fdt));
   File "scripts/dtc/pylibfdt/libfdt.py", line 160, in check_err
 raise FdtException(val)
FdtException: pylibfdt error -9: FDT_ERR_BADMAGIC
/home/swarren/shared/git_wa/tegra-uboot-flasher/u-boot/Makefile:1244:
recipe for target 'u-boot-tegra.bin' failed
make[1]: *** [u-boot-tegra.bin] Error 1
make[1]: *** Waiting for unfinished jobs


Thanks for that. But actually that is not something I have seen or can
explain. Here it is reading the DT at the start and somehow failing in
the check. That DT is created by the U-Boot build system. Is it
possible that your system has its own libfdt installed?

As it happened, the pylibfdt changes have been applied upstream today,
so I'll prepare a patch to sync U-Boot up with that. Hopefully that
will resolve any issues, but I am not sure.


I have the standard Ubuntu 16.04 packages installed, but no 
non-standard local builds:


device-tree-compiler 1.4.0+dfsg-2
libfdt1:amd64    1.4.0+dfsg-2


I suspect this is a missing dependency in the makefiles, or perhaps some 
process isn't waiting for its child to exit. The code that's finding the 
bad FDT magic appears to be reading from a file that hasn't yet been 
written yet:


[pid 26251] execve("../tools/binman/binman", 
["../tools/binman/binman", "-d", "u-boot.dtb", "-O", 

Re: [U-Boot] [PATCH v2] cmd: fastboot: Validate user input

2018-07-12 Thread Sam Protsenko
Hi Tom,

If there is no objections here, can we apply this patch?

Thanks.

On Sat, Jun 30, 2018 at 7:20 AM, Simon Glass  wrote:
> On 29 June 2018 at 11:59, Sam Protsenko  wrote:
>> In case when user provides '-' as USB controller index, like this:
>>
>> => fastboot -
>>
>> data abort occurs in strcmp() function in do_fastboot(), here:
>>
>> if (!strcmp(argv[1], "udp"))
>>
>> (tested on BeagleBone Black).
>>
>> That's because argv[1] is NULL when user types in the '-', and null
>> pointer dereference occurs in strcmp() (which is ok according to C
>> standard specification). So we must validate user input to prevent such
>> behavior.
>>
>> While at it, check also the result of strtoul() function and handle
>> error cases properly.
>>
>> Signed-off-by: Sam Protsenko 
>> ---
>> Changes for v2:
>>   - replace argv check with argc check
>>   - add mentioning of testing platform in commit message
>>
>>  cmd/fastboot.c | 13 -
>>  1 file changed, 12 insertions(+), 1 deletion(-)
>
> Reviewed-by: Simon Glass 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 1/1] common: print \n in initr_scsi()

2018-07-12 Thread Heinrich Schuchardt
On 06/20/2018 12:03 AM, Simon Glass wrote:
> Hi Heinrich,
> 
> On 14 June 2018 at 23:01, Heinrich Schuchardt  wrote:
>> Typically init_scsi() does not output anything. So initr_scsi() should
>> provide a \n or we may see borked output like
>>
>> SCSI:  Net:   No ethernet found.
>>
>> as observed with sandbox_defconfig.
>>
>> Signed-off-by: Heinrich Schuchardt 
>> ---
>>  common/board_r.c | 1 +
>>  1 file changed, 1 insertion(+)
> 
> Instead of this, we should enable DM_SCSI on sandbox.
> 
> Regards,
> Simon
> 
The function initr_scsi() is built for
#if defined(CONFIG_SCSI) && !defined(CONFIG_DM_SCSI)

Once all boards that support CONFIG_SCSI can be configured with
CONFIG_DM_SCSI we should remove the symbol CONFIG_SCSI and function
initr_scsi(). But we have not even enabled BLK for all supported boards.
BLK is required for DM_SCSI.

Till then problem I observed will be reproducible on other architectures
than sandbox if no SCSI disk is attached.

Best regards

Heinrich
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] Please pull u-boot-dm

2018-07-12 Thread Stephen Warren

On 07/12/2018 09:52 AM, Stephen Warren wrote:

On 07/11/2018 06:12 PM, Simon Glass wrote:

Hi Stephen,

On 11 July 2018 at 16:01, Stephen Warren  wrote:

On 07/10/2018 02:24 PM, Simon Glass wrote:


Hi Stephen,

On 10 July 2018 at 13:53, Stephen Warren  wrote:


On 07/10/2018 12:47 PM, Tom Rini wrote:



On Mon, Jul 09, 2018 at 01:53:43PM -0600, Simon Glass wrote:


Hi Tom.

Here are some test-coverage and DM core enhancements. Also it adds a
way to access the binman definition from U-Boot.


The following changes since commit
8c5d4fd0ec222701598a27b26ab7265d4cee45a3:

 Prepare v2018.07 (2018-07-09 10:24:14 -0400)

are available in the Git repository at:

 git://git.denx.de/u-boot-dm.git

for you to fetch changes up to
16b8d6b76992690c65c58dc8b0591496cc5e46ef:

 binman: Support updating the device tree with calc'd info
(2018-07-09 09:11:00 -0600)




This pull has caused intermittent/random build errors on my Jenkins
system.
The log shows:


    LD  spl/u-boot-spl
    OBJCOPY spl/u-boot-spl-nodtb.bin
    COPY    spl/u-boot-spl.bin
    BINMAN  u-boot-tegra.bin
    BINMAN  u-boot-nodtb-tegra.bin
    BINMAN  u-boot-dtb-tegra.bin
binman: pylibfdt error -9: FDT_ERR_BADMAGIC


/var/lib/jenkins/workspace/u-boot-denx_uboot-master-build/src/u-boot/Makefile:1244: 


recipe for target 'u-boot-tegra.bin' failed
make[1]: *** [u-boot-tegra.bin] Error 1
make[1]: *** Waiting for unfinished jobs
make[1]: Leaving directory

'/var/lib/jenkins/workspace/u-boot-denx_uboot-master-build/build/u-boot/beaver' 


Makefile:148: recipe for target 'sub-make' failed
make: *** [sub-make] Error 2
make: Leaving directory
'/var/lib/jenkins/workspace/u-boot-denx_uboot-master-build/src/u-boot' 





This doesn't happen every time; my Jenkins system builds 25 
Tegra/sandbox
boards, yet a varying set of boards fail each time I trigger the 
build:

Just
beaver the first time, then just colibri_t20 and ventana, then just
medcom-wide. Note that the system performs incremental builds, if that
matters.



That might be the fdt_resize() problem which David Gibson has just
sorted out upstream. If you can run binman -D (to get a stack trace)
that might help. I should be able to do a patch if that is the
problem.



Is this the backtrace you're looking for?


[swarren@swarren-lx1 u-boot]$
CROSS_COMPILE=/home/swarren/shared/gcc-linaro-7.2.1-2017.11-i686_arm-linux-gnueabihf/bin/arm-linux-gnueabihf- 

sh -c "make O=build-beaver -s beaver_defconfig && make 
O=build-beaver -s

-j8"
arch/arm/dts/tegra30-apalis.dtb: Warning (avoid_unnecessary_addr_size):
/i2c@7000d000/tps65911@2d/regulators: unnecessary 
#address-cells/#size-cells

without "ranges" or child "reg" property
arch/arm/dts/tegra30-beaver.dtb: Warning (avoid_unnecessary_addr_size):
/i2c@7000d000/tps65911@2d/regulators: unnecessary 
#address-cells/#size-cells

without "ranges" or child "reg" property
binman: pylibfdt error -9: FDT_ERR_BADMAGIC

Traceback (most recent call last):
   File "../tools/binman/binman", line 120, in RunBinman
 ret_code = control.Binman(options, args)
   File
"/home/swarren/shared/git_wa/tegra-uboot-flasher/u-boot/tools/binman/control.py", 


line 128, in Binman
 dtb = fdt.FdtScan(fname)
   File
"/home/swarren/shared/git_wa/tegra-uboot-flasher/u-boot/tools/binman/../dtoc/fdt.py", 


line 459, in FdtScan
 dtb = Fdt(fname)
   File
"/home/swarren/shared/git_wa/tegra-uboot-flasher/u-boot/tools/binman/../dtoc/fdt.py", 


line 315, in __init__
 self._fdt_obj = libfdt.Fdt(fd.read())
   File "scripts/dtc/pylibfdt/libfdt.py", line 207, in __init__
 check_err(fdt_check_header(self._fdt));
   File "scripts/dtc/pylibfdt/libfdt.py", line 160, in check_err
 raise FdtException(val)
FdtException: pylibfdt error -9: FDT_ERR_BADMAGIC
/home/swarren/shared/git_wa/tegra-uboot-flasher/u-boot/Makefile:1244:
recipe for target 'u-boot-tegra.bin' failed
make[1]: *** [u-boot-tegra.bin] Error 1
make[1]: *** Waiting for unfinished jobs


Thanks for that. But actually that is not something I have seen or can
explain. Here it is reading the DT at the start and somehow failing in
the check. That DT is created by the U-Boot build system. Is it
possible that your system has its own libfdt installed?

As it happened, the pylibfdt changes have been applied upstream today,
so I'll prepare a patch to sync U-Boot up with that. Hopefully that
will resolve any issues, but I am not sure.


I have the standard Ubuntu 16.04 packages installed, but no non-standard 
local builds:


device-tree-compiler 1.4.0+dfsg-2
libfdt1:amd64    1.4.0+dfsg-2


I suspect this is a missing dependency in the makefiles, or perhaps some 
process isn't waiting for its child to exit. The code that's finding the 
bad FDT magic appears to be reading from a file that hasn't yet been 
written yet:



[pid 26251] execve("../tools/binman/binman", ["../tools/binman/binman", "-d", "u-boot.dtb", "-O", ".", "-I", ".", 
"-I", "../board/nvidia/beaver", 

Re: [U-Boot] Please pull u-boot-dm

2018-07-12 Thread Stephen Warren

On 07/11/2018 06:12 PM, Simon Glass wrote:

Hi Stephen,

On 11 July 2018 at 16:01, Stephen Warren  wrote:

On 07/10/2018 02:24 PM, Simon Glass wrote:


Hi Stephen,

On 10 July 2018 at 13:53, Stephen Warren  wrote:


On 07/10/2018 12:47 PM, Tom Rini wrote:



On Mon, Jul 09, 2018 at 01:53:43PM -0600, Simon Glass wrote:


Hi Tom.

Here are some test-coverage and DM core enhancements. Also it adds a
way to access the binman definition from U-Boot.


The following changes since commit
8c5d4fd0ec222701598a27b26ab7265d4cee45a3:

 Prepare v2018.07 (2018-07-09 10:24:14 -0400)

are available in the Git repository at:

 git://git.denx.de/u-boot-dm.git

for you to fetch changes up to
16b8d6b76992690c65c58dc8b0591496cc5e46ef:

 binman: Support updating the device tree with calc'd info
(2018-07-09 09:11:00 -0600)




This pull has caused intermittent/random build errors on my Jenkins
system.
The log shows:


LD  spl/u-boot-spl
OBJCOPY spl/u-boot-spl-nodtb.bin
COPYspl/u-boot-spl.bin
BINMAN  u-boot-tegra.bin
BINMAN  u-boot-nodtb-tegra.bin
BINMAN  u-boot-dtb-tegra.bin
binman: pylibfdt error -9: FDT_ERR_BADMAGIC


/var/lib/jenkins/workspace/u-boot-denx_uboot-master-build/src/u-boot/Makefile:1244:
recipe for target 'u-boot-tegra.bin' failed
make[1]: *** [u-boot-tegra.bin] Error 1
make[1]: *** Waiting for unfinished jobs
make[1]: Leaving directory

'/var/lib/jenkins/workspace/u-boot-denx_uboot-master-build/build/u-boot/beaver'
Makefile:148: recipe for target 'sub-make' failed
make: *** [sub-make] Error 2
make: Leaving directory
'/var/lib/jenkins/workspace/u-boot-denx_uboot-master-build/src/u-boot'




This doesn't happen every time; my Jenkins system builds 25 Tegra/sandbox
boards, yet a varying set of boards fail each time I trigger the build:
Just
beaver the first time, then just colibri_t20 and ventana, then just
medcom-wide. Note that the system performs incremental builds, if that
matters.



That might be the fdt_resize() problem which David Gibson has just
sorted out upstream. If you can run binman -D (to get a stack trace)
that might help. I should be able to do a patch if that is the
problem.



Is this the backtrace you're looking for?


[swarren@swarren-lx1 u-boot]$
CROSS_COMPILE=/home/swarren/shared/gcc-linaro-7.2.1-2017.11-i686_arm-linux-gnueabihf/bin/arm-linux-gnueabihf-
sh -c "make O=build-beaver -s beaver_defconfig && make O=build-beaver -s
-j8"
arch/arm/dts/tegra30-apalis.dtb: Warning (avoid_unnecessary_addr_size):
/i2c@7000d000/tps65911@2d/regulators: unnecessary #address-cells/#size-cells
without "ranges" or child "reg" property
arch/arm/dts/tegra30-beaver.dtb: Warning (avoid_unnecessary_addr_size):
/i2c@7000d000/tps65911@2d/regulators: unnecessary #address-cells/#size-cells
without "ranges" or child "reg" property
binman: pylibfdt error -9: FDT_ERR_BADMAGIC

Traceback (most recent call last):
   File "../tools/binman/binman", line 120, in RunBinman
 ret_code = control.Binman(options, args)
   File
"/home/swarren/shared/git_wa/tegra-uboot-flasher/u-boot/tools/binman/control.py",
line 128, in Binman
 dtb = fdt.FdtScan(fname)
   File
"/home/swarren/shared/git_wa/tegra-uboot-flasher/u-boot/tools/binman/../dtoc/fdt.py",
line 459, in FdtScan
 dtb = Fdt(fname)
   File
"/home/swarren/shared/git_wa/tegra-uboot-flasher/u-boot/tools/binman/../dtoc/fdt.py",
line 315, in __init__
 self._fdt_obj = libfdt.Fdt(fd.read())
   File "scripts/dtc/pylibfdt/libfdt.py", line 207, in __init__
 check_err(fdt_check_header(self._fdt));
   File "scripts/dtc/pylibfdt/libfdt.py", line 160, in check_err
 raise FdtException(val)
FdtException: pylibfdt error -9: FDT_ERR_BADMAGIC
/home/swarren/shared/git_wa/tegra-uboot-flasher/u-boot/Makefile:1244:
recipe for target 'u-boot-tegra.bin' failed
make[1]: *** [u-boot-tegra.bin] Error 1
make[1]: *** Waiting for unfinished jobs


Thanks for that. But actually that is not something I have seen or can
explain. Here it is reading the DT at the start and somehow failing in
the check. That DT is created by the U-Boot build system. Is it
possible that your system has its own libfdt installed?

As it happened, the pylibfdt changes have been applied upstream today,
so I'll prepare a patch to sync U-Boot up with that. Hopefully that
will resolve any issues, but I am not sure.


I have the standard Ubuntu 16.04 packages installed, but no non-standard 
local builds:


device-tree-compiler 1.4.0+dfsg-2
libfdt1:amd641.4.0+dfsg-2

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v2 13/21] spi: Extend the core to ease integration of SPI memory controllers

2018-07-12 Thread Miquel Raynal
Hi Stefan,

> > +   memset(tx_buf + pos, 0xff, op->dummy.nbytes);
> > +   pos += op->dummy.nbytes;
> > +   }
> > +
> > +   if (tx_data)
> > +   memcpy(tx_buf + pos, op->data.buf.out, op->data.nbytes);
> > +
> > +   ret = spi_xfer(slave, xfer_len * 8, tx_buf, rx_buf,
> > +  SPI_XFER_BEGIN | SPI_XFER_END);
> > +   spi_release_bus(slave);
> > +
> > +   for (i = 0; i < pos; i++)
> > +   debug("%02x ", tx_buf[i]);
> > +   debug("| [%dB %s] ",
> > + tx_data || rx_data ? op->data.nbytes : 0,
> > + tx_data || rx_data ? (tx_data ? "out" : "in") : "-");
> > +   for (; i < xfer_len; i++)
> > +   debug("%02x ", rx_buf[i]);  
> 
>   debug("%02x ", tx_data ? tx_buf[i] : rx_buf[i]);
> 
> I won't have much more time today. Will get back to this in ~2 weeks.

Sure!

Debug line changed.

Thanks,
Miquèl
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] Microblaze gpio reset handling

2018-07-12 Thread Michal Simek
Hi Simon,

I have looked at converting the rest of microblaze drivers to DM and I
am curious why I can't use top level compatible string in DM based drivers.
I am looking at ways how to move gpio and microblaze soft reset to
sysreset framework and I see that core is not able to find out my high
level xlnx,microblaze compatible string.


/ {
#address-cells = <1>;
#size-cells = <1>;
compatible = "xlnx,microblaze";
model = "Xilinx MicroBlaze";
hard-reset-gpios = <_gpio 0 1>;

As far I have seen only nodes are checked but unfortunately Microblaze
is using hard-reset-gpios in root for years and will be good to keep it
like that.

I have already tested to bind that driver from board file like
device_bind_driver(gd->dm_root, "microblaze_sysreset", "reset", NULL);
which is working fine but just asking if there is another solution for this.

Thanks,
Michal

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH] gpio: xilinx: Convert driver to DM

2018-07-12 Thread Michal Simek
This patch is enabling GPIO_DM support to have an option to use this
driver together with zynq gpio driver.
!DM part is kept there till Microblaze is cleanup which will be done
hopefully soon.

Just a note:
There is no reason to initialize uc-priv->name because it is completely
unused.

Signed-off-by: Michal Simek 
---

 drivers/gpio/xilinx_gpio.c | 225 -
 1 file changed, 224 insertions(+), 1 deletion(-)

diff --git a/drivers/gpio/xilinx_gpio.c b/drivers/gpio/xilinx_gpio.c
index 74c5be0865d1..ca33473042d7 100644
--- a/drivers/gpio/xilinx_gpio.c
+++ b/drivers/gpio/xilinx_gpio.c
@@ -1,6 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0+
 /*
- * Copyright (c) 2013 Xilinx, Michal Simek
+ * Copyright (c) 2013 - 2018 Xilinx, Michal Simek
  */
 
 #include 
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 
 static LIST_HEAD(gpio_list);
 
@@ -23,6 +24,8 @@ struct gpio_regs {
u32 gpiodir;
 };
 
+#if !defined(CONFIG_DM_GPIO)
+
 #define GPIO_NAME_SIZE 10
 
 struct gpio_names {
@@ -345,3 +348,223 @@ int gpio_alloc_dual(u32 baseaddr, const char *name, u32 
gpio_no0, u32 gpio_no1)
/* Return the first gpio allocated for this device */
return ret;
 }
+#else
+#define XILINX_GPIO_MAX_BANK   2
+
+struct xilinx_gpio_platdata {
+   struct gpio_regs *regs;
+   int bank_max[XILINX_GPIO_MAX_BANK];
+   int bank_input[XILINX_GPIO_MAX_BANK];
+   int bank_output[XILINX_GPIO_MAX_BANK];
+};
+
+static int xilinx_gpio_get_bank_pin(unsigned offset, u32 *bank_num,
+   u32 *bank_pin_num, struct udevice *dev)
+{
+   struct xilinx_gpio_platdata *platdata = dev_get_platdata(dev);
+   u32 bank, max_pins;
+   /* the first gpio is 0 not 1 */
+   u32 pin_num = offset;
+
+   for (bank = 0; bank < XILINX_GPIO_MAX_BANK; bank++) {
+   max_pins = platdata->bank_max[bank];
+   if (pin_num < max_pins) {
+   debug("%s: found at bank 0x%x pin 0x%x\n", __func__,
+ bank, pin_num);
+   *bank_num = bank;
+   *bank_pin_num = pin_num;
+   return 0;
+   }
+   pin_num -= max_pins;
+   }
+
+   return -EINVAL;
+}
+
+static int xilinx_gpio_set_value(struct udevice *dev, unsigned offset,
+int value)
+{
+   struct xilinx_gpio_platdata *platdata = dev_get_platdata(dev);
+   int val, ret;
+   u32 bank, pin;
+
+   ret = xilinx_gpio_get_bank_pin(offset, , , dev);
+   if (ret)
+   return ret;
+
+   debug("%s: regs: %lx, gpio: %x, bank %x, pin %x\n", __func__,
+ (ulong)platdata->regs, offset, bank, pin);
+
+   if (value) {
+   val = readl(>regs->gpiodata + bank * 2);
+   val = val | (1 << pin);
+   writel(val, >regs->gpiodata + bank * 2);
+   } else {
+   val = readl(>regs->gpiodata + bank * 2);
+   val = val & ~(1 << pin);
+   writel(val, >regs->gpiodata + bank * 2);
+   }
+
+   return val;
+};
+
+static int xilinx_gpio_get_value(struct udevice *dev, unsigned offset)
+{
+   struct xilinx_gpio_platdata *platdata = dev_get_platdata(dev);
+   int val, ret;
+   u32 bank, pin;
+
+   ret = xilinx_gpio_get_bank_pin(offset, , , dev);
+   if (ret)
+   return ret;
+
+   debug("%s: regs: %lx, gpio: %x, bank %x, pin %x\n", __func__,
+ (ulong)platdata->regs, offset, bank, pin);
+
+   val = readl(>regs->gpiodata + bank * 2);
+   val = !!(val & (1 << pin));
+
+   return val;
+};
+
+static int xilinx_gpio_get_function(struct udevice *dev, unsigned offset)
+{
+   struct xilinx_gpio_platdata *platdata = dev_get_platdata(dev);
+   int val, ret;
+   u32 bank, pin;
+
+   /* Check if all pins are inputs */
+   if (platdata->bank_input[bank])
+   return GPIOF_INPUT;
+
+   /* Check if all pins are outputs */
+   if (platdata->bank_output[bank])
+   return GPIOF_OUTPUT;
+
+   ret = xilinx_gpio_get_bank_pin(offset, , , dev);
+   if (ret)
+   return ret;
+
+   /* FIXME test on dual */
+   val = readl(>regs->gpiodir + bank * 2);
+   val = !(val & (1 << pin));
+
+   /* input is 1 in reg but GPIOF_INPUT is 0 */
+   /* output is 0 in reg but GPIOF_OUTPUT is 1 */
+
+   return val;
+}
+
+static int xilinx_gpio_direction_output(struct udevice *dev, unsigned offset,
+   int value)
+{
+   struct xilinx_gpio_platdata *platdata = dev_get_platdata(dev);
+   int val, ret;
+   u32 bank, pin;
+
+   ret = xilinx_gpio_get_bank_pin(offset, , , dev);
+   if (ret)
+   return ret;
+
+   /* can't change it if all is input by default */
+   if (platdata->bank_input[bank])
+   return -EINVAL;
+
+   if 

[U-Boot] Please pull from u-boot-i2c

2018-07-12 Thread Heiko Schocher

Hello Tom,

please pull from u-boot-i2c.git master

The following changes since commit 1612ff0dfba57b1002d8c7a54778eb553ace98f4:

  Merge branch 'master' of git://git.denx.de/u-boot-mips (2018-07-11 21:55:20 
-0400)

are available in the Git repository at:

  git://git.denx.de/u-boot-i2c.git master

for you to fetch changes up to 971490c89251ae1a4a9e2a85911de5c217a4027c:

  lpi2c: Add bus busy error handling (2018-07-12 11:09:42 +0200)


Gao Pan (1):
  imx: lpi2c: fix clock issue when NACK detected

Ye Li (3):
  imx_lpi2c: Update lpi2c driver to support imx8
  lpi2c: Fix bus stop problem in xfer
  lpi2c: Add bus busy error handling

 drivers/i2c/imx_lpi2c.c   | 82 
++

 {arch/arm/include/asm/arch-mx7ulp => include}/imx_lpi2c.h |  0
 2 files changed, 50 insertions(+), 32 deletions(-)
 rename {arch/arm/include/asm/arch-mx7ulp => include}/imx_lpi2c.h (100%)

Travis tests are fine:

https://travis-ci.org/hsdenx/u-boot-i2c/builds/403024936

bye,
Heiko
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: h...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH V2 3/4] lpi2c: Fix bus stop problem in xfer

2018-07-12 Thread Heiko Schocher

Hello Peng,

Am 08.07.2018 um 05:46 schrieb Peng Fan:

From: Ye Li 

In xfer function, both bus_i2c_read and bus_i2c_write will
send a STOP command.  This causes a problem when reading register
data from i2c device.

Generally two operations comprise the register data reading:
1. Write the register address to i2c device.
   START | chip_addr | W | ACK | register_addr | ACK |

2. Read the Data from i2c device.
   START | chip_addr | R | ACK | DATA  | NACK | STOP

The STOP command should happen at the end of the transfer, otherwise
we will always get data from register address 0

Signed-off-by: Ye Li 
Acked-by: Peng Fan 
Reviewed-by: Heiko Schocher 
---

V2: Add review tag

  drivers/i2c/imx_lpi2c.c | 14 +++---
  1 file changed, 7 insertions(+), 7 deletions(-)


Applied to u-boot-i2c.git master

Thanks!

bye,
Heiko
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: h...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH V2 4/4] lpi2c: Add bus busy error handling

2018-07-12 Thread Heiko Schocher

Hello Peng,

Am 08.07.2018 um 05:46 schrieb Peng Fan:

From: Ye Li 

When doing "i2c dev 4; i2c probe" with ENET daughter card connected
on iMX8QXP MEK board, we met a i2c bus busy issue, that the BBF of
lpi2c always show busy, but the master is idle, and stop is detected
(SDF set).

This patch addes a handling to re-init the lpi2c master for this
case. Then the issue can be worked around.

Signed-off-by: Ye Li 
Acked-by: Peng Fan 
Reviewed-by: Heiko Schocher 
---

V2: Add review tag.
Heiko, I have no idea why the busy show, from the bus, we measured it
is idle, but the controller bit shows busy. We followed Linux kernel's
method to reinit the bus and all works.

  drivers/i2c/imx_lpi2c.c | 53 +
  1 file changed, 32 insertions(+), 21 deletions(-)


Applied to u-boot-i2c.git master

Thanks!

bye,
Heiko
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: h...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH V2 2/4] imx: lpi2c: fix clock issue when NACK detected

2018-07-12 Thread Heiko Schocher

Hello Peng,

Am 08.07.2018 um 05:46 schrieb Peng Fan:

From: Gao Pan 

For LPI2C IP, NACK is detected by the rising edge of the ninth clock.
In current uboot driver, once NACK is detected, it will reset and then
disable LPI2C master. As a result, we can never see the falling edge
of the ninth clock.

Signed-off-by: Gao Pan 
Signed-off-by: Peng Fan 
Reviewed-by: Heiko Schocher 
---

V2: Add review tag

  drivers/i2c/imx_lpi2c.c | 14 ++
  1 file changed, 10 insertions(+), 4 deletions(-)


Applied to u-boot-i2c.git master

Thanks!

bye,
Heiko
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: h...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH V2 1/4] imx_lpi2c: Update lpi2c driver to support imx8

2018-07-12 Thread Heiko Schocher

Hello Peng,

Am 08.07.2018 um 05:46 schrieb Peng Fan:

From: Ye Li 

Add compatible string for i.MX8 and move imx_lpi2c.h from mx7ulp directory
to u-boot include directory as a common header file.

Signed-off-by: Ye Li 
Signed-off-by: Peng Fan 
Reviewed-by: Heiko Schocher 
---

V2: Add review tag

  drivers/i2c/imx_lpi2c.c   | 3 ++-
  {arch/arm/include/asm/arch-mx7ulp => include}/imx_lpi2c.h | 0
  2 files changed, 2 insertions(+), 1 deletion(-)
  rename {arch/arm/include/asm/arch-mx7ulp => include}/imx_lpi2c.h (100%)


Applied to u-boot-i2c.git master

Thanks!

bye,
Heiko
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: h...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v2] arm: socfpga: Fixes: Rename CONFIG_SPL_RESET_SUPPORT to CONFIG_SPL_DM_RESET

2018-07-12 Thread Marek Vasut
On 07/12/2018 01:12 PM, Ley Foon Tan wrote:
> Commit bfc6bae8fa1f2d8a9c51548767b02f1a1e0ffe52
> 
> This commit rename CONFIG_SPL_RESET_SUPPORT to CONFIG_SPL_DM_RESET. Update
> with new CONFIG name.
> 
> Signed-off-by: Ley Foon Tan 
> Acked-by: Marek Vasut 
> 
> ---
> v2:
> - Rename commit title, add "Fixes:" tag
> - Add Acked-by from Marek
> ---
>  arch/arm/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 35b6ea2..4c60538 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -754,6 +754,7 @@ config ARCH_SOCFPGA
>   select DM_SERIAL
>   select ENABLE_ARM_SOC_BOOT0_HOOK if TARGET_SOCFPGA_GEN5 || 
> TARGET_SOCFPGA_ARRIA10
>   select OF_CONTROL
> + select SPL_DM_RESET
>   select SPL_LIBCOMMON_SUPPORT
>   select SPL_LIBDISK_SUPPORT
>   select SPL_LIBGENERIC_SUPPORT
> @@ -762,7 +763,6 @@ config ARCH_SOCFPGA
>   select SPL_OF_CONTROL
>   select SPL_SERIAL_SUPPORT
>   select SPL_DM_SERIAL
> - select SPL_RESET_SUPPORT
>   select SPL_SPI_FLASH_SUPPORT if SPL_SPI_SUPPORT
>   select SPL_SPI_SUPPORT if DM_SPI
>   select SPL_WATCHDOG_SUPPORT
> 

This broke Arria10, dropped

   arm:  +   socfpga_arria10
+arch/arm/dts/socfpga_arria10_socdk_sdmmc.dtb: Warning
(avoid_unnecessary_addr_size): /clocks: unnecessary
#address-cells/#size-cells without "ranges" or child "reg" property
+drivers/built-in.o: In function `ns16550_serial_probe':
+drivers/serial/ns16550.c:378: undefined reference to `reset_get_bulk'
+drivers/serial/ns16550.c:380: undefined reference to `reset_deassert_bulk'
+make[2]: *** [spl/u-boot-spl] Error 1
+make[1]: *** [spl/u-boot-spl] Error 2
+make: *** [sub-make] Error 2

Can you please at least do basic compile tests before submitting the
patches ?

-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [RFC PATCH] gpio: zynq: Setup bank_name to dev->name

2018-07-12 Thread Michal Simek
There should be proper bank name setup to distiguish between different
gpio drivers. Use dev->name for it.

Signed-off-by: Michal Simek 
---

 drivers/gpio/zynq_gpio.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpio/zynq_gpio.c b/drivers/gpio/zynq_gpio.c
index 26f69b1a713f..f793ee5754a8 100644
--- a/drivers/gpio/zynq_gpio.c
+++ b/drivers/gpio/zynq_gpio.c
@@ -337,6 +337,8 @@ static int zynq_gpio_probe(struct udevice *dev)
struct zynq_gpio_privdata *priv = dev_get_priv(dev);
struct gpio_dev_priv *uc_priv = dev_get_uclass_priv(dev);
 
+   uc_priv->bank_name = dev->name;
+
if (priv->p_data)
uc_priv->gpio_count = priv->p_data->ngpio;
 
-- 
1.9.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] UBI fixable bit-flip issue

2018-07-12 Thread Mark Spieth



On 12 July 2018 18:46:11 GMT+10:00, Richard Weinberger  
wrote:

Mark,

Am Donnerstag, 12. Juli 2018, 07:22:13 CEST schrieb Heiko Schocher:

Hello Mark,

added Richard Weinberger to cc...

Am 12.07.2018 um 02:28 schrieb Mark Spieth:
> Hi
> 
> In the process of investigating a boot failure on one of our

devices, the
> 
> UBI: fixable bit-flip detected at PEB
> 
> message was seen with the following behaviour during kernel load in

u-boot.
> 
> Read [2285568] bytes

> UBI: fixable bit-flip detected at PEB 415
> UBI: schedule PEB 415 for scrubbing
> UBI: fixable bit-flip detected at PEB 415
> UBI: fixable bit-flip detected at PEB 419
> UBI: schedule PEB 419 for scrubbing
> UBI: fixable bit-flip detected at PEB 419
> UBI: fixable bit-flip detected at PEB 420
> UBI: schedule PEB 420 for scrubbing
> UBI: fixable bit-flip detected at PEB 420
> UBI: fixable bit-flip detected at PEB 419
> UBI: fixable bit-flip detected at PEB 420
> UBI: fixable bit-flip detected at PEB 419
> UBI: fixable bit-flip detected at PEB 420
> UBI: fixable bit-flip detected at PEB 419
> UBI: fixable bit-flip detected at PEB 420
> UBI: fixable bit-flip detected at PEB 419
> UBI: fixable bit-flip detected at PEB 420
> UBI: fixable bit-flip detected at PEB 419
> UBI: fixable bit-flip detected at PEB 420
> UBI: fixable bit-flip detected at PEB 419
> 
> This repeats until reset.


Do you see the same symptom also on Linux?
We need to be very sure that it is actually a UBI problem.


The linux provided has an up to date mtd/ubi driver so already has the 
75% bitflip threshold thus hiding the issue in a new flash. So the 2 are 
not the same. Untested on linux.





> This fix is not a root cause fix though. Investigating further led
to the following root cause 

> solution. The following is AFAICT.
> 
> When the scrubber chooses a PEB to move the from the free balanced
tree. This tree is sorted by EC 

> (erase count) and then by PEB number.
> 
> The find_wl_entry call uses a max parameter of WL_FREE_MAX_DIFF
which is 8192 in this config. So the 

> find_wl_entry function will find a PEB that is better in error

count that the current PEB EC. This

error count? You mean erase count?


Yes of course.




> can easily cause it to find the PEB that was just moved from if it
is the lowest numbered PEB in the 

> free tree. Waiting for EC to go above 8192 would take a long time
and cause premature aging of the 

> flash PEBs in question.
> 
> The easy solution is to change the max parameter to this call to 0
so it finds a PEB with a smaller 

> EC than the one being replaced. This means it wont use the
previously discarded PEB as its first 

> choice.


For scrubbing this might be a good idea, but not for regular
wear-leveling.

Yes only for scrubbing, not wear leveling.


See comment in UBI:
/*
* When a physical eraseblock is moved, the WL sub-system has to pick
the target
* physical eraseblock to move to. The simplest way would be just to
pick the
* one with the highest erase counter. But in certain workloads this
could lead
* to an unlimited wear of one or few physical eraseblock. Indeed,
imagine a
* situation when the picked physical eraseblock is constantly erased
after the
* data is written to it. So, we have a constant which limits the
highest erase
* counter of the free physical eraseblock to pick. Namely, the WL
sub-system
* does not pick eraseblocks with erase counter greater than the lowest
erase
* counter plus %WL_FREE_MAX_DIFF.
*/
#define WL_FREE_MAX_DIFF (2*UBI_WL_THRESHOLD)

So we could change the logic such that for regular wear-leveling we
keep using WL_FREE_MAX_DIFF,
but for scrubbing (which is 1:1 wear-leveling but the source PEB is
showing bit-flips) we use
a lower value. IMHO WL_FREE_MAX_DIFF/2 would be a good choice.
I'm not sure whether 0 is too extreme and might cause other
distortions.


Yes the wear leveling threshold is still WL_FREE_MAX_DIFF and the 
scubbing threshold is 0.


This is why I'm asking. Because the 2 PEBs will track each others EC I'm 
not sure that will work.


Mark, can you please file a patch and send it to linux-mtd mailing
list?
Such a change needs to go through Linux and then to u-boot.
But first we need to think about and discuss it in detail.


Will do.




  I am not sure if it is so easy ...

> This fix was implemented and fixable bit-flip errors no longer
hang/freeze the boot process! UBI 

> erase and reformat was used between re-tests to get consistent

results.
> 
> Adding the above 75% correctable bitflip threshold is also a good
thing as less movement will ensue 

> when the FLASH is new, but as the flash ages, the root cause will
once again be invoked causing 

> un-recoverable boot failures.
> 
> Note this fault is also in the latest kernel drivers for UBI and
may also exist in other wear 

> leveling implementations. The kernel driver issue may be at fault
for android devices locking 

> up/freezing sporadically during FLASH read when scrubbing due to a
relatively full flash and 

> 

Re: [U-Boot] cmd: Kconfig: Move CONFIG_MP to Kconfig

2018-07-12 Thread Tom Rini
On Thu, Jul 12, 2018 at 07:52:44AM +0200, Michal Simek wrote:

> Hi Tom,
> 
> On 11.7.2018 14:42, Tom Rini wrote:
> > On Tue, Jun 19, 2018 at 12:24:23PM +0200, Michal Simek wrote:
> > 
> >> From: Siva Durga Prasad Paladugu 
> >>
> >> This patch moves CONFIG_MP to Kconfig
> >>
> >> Signed-off-by: Siva Durga Prasad Paladugu 
> >> Signed-off-by: Michal Simek 
> > 
> > Applied to u-boot/master, thanks!
> > 
> 
> FYI: There was v2 of that patch
> https://lists.denx.de/pipermail/u-boot/2018-June/332802.html
> but I will send that changes separately because only zynqmp defconfig
> are affected.

Sorry I missed it, thanks!

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v3 13/21] spi: Extend the core to ease integration of SPI memory controllers

2018-07-12 Thread Miquel Raynal
From: Boris Brezillon 

Some controllers are exposing high-level interfaces to access various
kind of SPI memories. Unfortunately they do not fit in the current
spi_controller model and usually have drivers placed in
drivers/mtd/spi-nor which are only supporting SPI NORs and not SPI
memories in general.

This is an attempt at defining a SPI memory interface which works for
all kinds of SPI memories (NORs, NANDs, SRAMs).

Signed-off-by: Boris Brezillon 
Signed-off-by: Miquel Raynal 
---
 drivers/spi/Kconfig   |   7 +
 drivers/spi/Makefile  |   1 +
 drivers/spi/spi-mem.c | 500 ++
 include/spi-mem.h | 258 ++
 include/spi.h |  11 ++
 5 files changed, 777 insertions(+)
 create mode 100644 drivers/spi/spi-mem.c
 create mode 100644 include/spi-mem.h

diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index f5960a7c95..91f1e360c9 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -18,6 +18,13 @@ config DM_SPI
 
 if DM_SPI
 
+config SPI_MEM
+   bool "SPI memory extension"
+   help
+ Enable this option if you want to enable the SPI memory extension.
+ This extension is meant to simplify interaction with SPI memories
+ by providing an high-level interface to send memory-like commands.
+
 config ALTERA_SPI
bool "Altera SPI driver"
help
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index e73b0cd7d5..9c2bfa3fb1 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -8,6 +8,7 @@ ifdef CONFIG_DM_SPI
 obj-y += spi-uclass.o
 obj-$(CONFIG_SANDBOX) += spi-emul-uclass.o
 obj-$(CONFIG_SOFT_SPI) += soft_spi.o
+obj-$(CONFIG_SPI_MEM) += spi-mem.o
 else
 obj-y += spi.o
 obj-$(CONFIG_SOFT_SPI) += soft_spi_legacy.o
diff --git a/drivers/spi/spi-mem.c b/drivers/spi/spi-mem.c
new file mode 100644
index 00..1aabe56819
--- /dev/null
+++ b/drivers/spi/spi-mem.c
@@ -0,0 +1,500 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2018 Exceet Electronics GmbH
+ * Copyright (C) 2018 Bootlin
+ *
+ * Author: Boris Brezillon 
+ */
+
+#ifndef __UBOOT__
+#include 
+#include 
+#include "internals.h"
+#else
+#include 
+#include 
+#endif
+
+#ifndef __UBOOT__
+/**
+ * spi_controller_dma_map_mem_op_data() - DMA-map the buffer attached to a
+ *   memory operation
+ * @ctlr: the SPI controller requesting this dma_map()
+ * @op: the memory operation containing the buffer to map
+ * @sgt: a pointer to a non-initialized sg_table that will be filled by this
+ *  function
+ *
+ * Some controllers might want to do DMA on the data buffer embedded in @op.
+ * This helper prepares everything for you and provides a ready-to-use
+ * sg_table. This function is not intended to be called from spi drivers.
+ * Only SPI controller drivers should use it.
+ * Note that the caller must ensure the memory region pointed by
+ * op->data.buf.{in,out} is DMA-able before calling this function.
+ *
+ * Return: 0 in case of success, a negative error code otherwise.
+ */
+int spi_controller_dma_map_mem_op_data(struct spi_controller *ctlr,
+  const struct spi_mem_op *op,
+  struct sg_table *sgt)
+{
+   struct device *dmadev;
+
+   if (!op->data.nbytes)
+   return -EINVAL;
+
+   if (op->data.dir == SPI_MEM_DATA_OUT && ctlr->dma_tx)
+   dmadev = ctlr->dma_tx->device->dev;
+   else if (op->data.dir == SPI_MEM_DATA_IN && ctlr->dma_rx)
+   dmadev = ctlr->dma_rx->device->dev;
+   else
+   dmadev = ctlr->dev.parent;
+
+   if (!dmadev)
+   return -EINVAL;
+
+   return spi_map_buf(ctlr, dmadev, sgt, op->data.buf.in, op->data.nbytes,
+  op->data.dir == SPI_MEM_DATA_IN ?
+  DMA_FROM_DEVICE : DMA_TO_DEVICE);
+}
+EXPORT_SYMBOL_GPL(spi_controller_dma_map_mem_op_data);
+
+/**
+ * spi_controller_dma_unmap_mem_op_data() - DMA-unmap the buffer attached to a
+ * memory operation
+ * @ctlr: the SPI controller requesting this dma_unmap()
+ * @op: the memory operation containing the buffer to unmap
+ * @sgt: a pointer to an sg_table previously initialized by
+ *  spi_controller_dma_map_mem_op_data()
+ *
+ * Some controllers might want to do DMA on the data buffer embedded in @op.
+ * This helper prepares things so that the CPU can access the
+ * op->data.buf.{in,out} buffer again.
+ *
+ * This function is not intended to be called from SPI drivers. Only SPI
+ * controller drivers should use it.
+ *
+ * This function should be called after the DMA operation has finished and is
+ * only valid if the previous spi_controller_dma_map_mem_op_data() call
+ * returned 0.
+ *
+ * Return: 0 in case of success, a negative error code otherwise.
+ */
+void spi_controller_dma_unmap_mem_op_data(struct spi_controller *ctlr,
+

[U-Boot] [PATCH v3 20/21] cmd: mtd: add 'mtd' command

2018-07-12 Thread Miquel Raynal
There should not be a 'nand' command, a 'sf' command and certainly not
another 'spi-nand'. Write a 'mtd' command instead to manage all MTD
devices at once. This should be the preferred way to access any MTD
device.

Signed-off-by: Miquel Raynal 
---
 cmd/Kconfig  |   5 +
 cmd/Makefile |   1 +
 cmd/mtd.c| 334 +++
 drivers/mtd/Makefile |   2 +-
 4 files changed, 341 insertions(+), 1 deletion(-)
 create mode 100644 cmd/mtd.c

diff --git a/cmd/Kconfig b/cmd/Kconfig
index 2fa0829925..f5d4d1d36c 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -848,6 +848,11 @@ config CMD_MMC_SWRITE
  Enable support for the "mmc swrite" command to write Android sparse
  images to eMMC.
 
+config CMD_MTD
+   bool "mtd"
+   help
+ MTD commands support.
+
 config CMD_NAND
bool "nand"
default y if NAND_SUNXI
diff --git a/cmd/Makefile b/cmd/Makefile
index 323f1fd2c7..32fd102189 100644
--- a/cmd/Makefile
+++ b/cmd/Makefile
@@ -90,6 +90,7 @@ obj-$(CONFIG_CMD_MISC) += misc.o
 obj-$(CONFIG_CMD_MMC) += mmc.o
 obj-$(CONFIG_CMD_MMC_SPI) += mmc_spi.o
 obj-$(CONFIG_MP) += mp.o
+obj-$(CONFIG_CMD_MTD) += mtd.o
 obj-$(CONFIG_CMD_MTDPARTS) += mtdparts.o
 obj-$(CONFIG_CMD_NAND) += nand.o
 obj-$(CONFIG_CMD_NET) += net.o
diff --git a/cmd/mtd.c b/cmd/mtd.c
new file mode 100644
index 00..9d768c8e4d
--- /dev/null
+++ b/cmd/mtd.c
@@ -0,0 +1,334 @@
+// SPDX-License-Identifier:  GPL-2.0+
+/*
+ * mtd.c
+ *
+ * Generic command to handle basic operations on any memory device.
+ *
+ * Copyright: Bootlin, 2018
+ * Author: Miquèl Raynal 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static void mtd_dump_buf(u8 *buf, uint len, uint offset)
+{
+   int i, j;
+
+   for (i = 0; i < len; ) {
+   printf("0x%08x:\t", offset + i);
+   for (j = 0; j < 8; j++)
+   printf("%02x ", buf[i + j]);
+   printf(" ");
+   i += 8;
+   for (j = 0; j < 8; j++)
+   printf("%02x ", buf[i + j]);
+   printf("\n");
+   i += 8;
+   }
+}
+
+static void mtd_show_device(struct mtd_info *mtd)
+{
+   /* Device */
+   printf("* %s", mtd->name);
+   if (mtd->dev)
+   printf(" [device: %s] [parent: %s] [driver: %s]",
+  mtd->dev->name, mtd->dev->parent->name,
+  mtd->dev->driver->name);
+   printf("\n");
+
+   /* MTD informations */
+   printf("\t> type: ");
+   switch (mtd->type) {
+   case MTD_RAM:
+   printf("RAM\n");
+   break;
+   case MTD_ROM:
+   printf("ROM\n");
+   break;
+   case MTD_NORFLASH:
+   printf("NOR flash\n");
+   break;
+   case MTD_NANDFLASH:
+   printf("NAND flash\n");
+   break;
+   case MTD_DATAFLASH:
+   printf("Data flash\n");
+   break;
+   case MTD_UBIVOLUME:
+   printf("UBI volume\n");
+   break;
+   case MTD_MLCNANDFLASH:
+   printf("MLC NAND flash\n");
+   break;
+   case MTD_ABSENT:
+   default:
+   printf("Unknown\n");
+   break;
+   }
+
+   printf("\t> Size: 0x%llx bytes\n", mtd->size);
+   printf("\t> Block: 0x%x bytes\n", mtd->erasesize);
+   printf("\t> Min I/O: 0x%x bytes\n", mtd->writesize);
+
+   if (mtd->oobsize) {
+   printf("\t> OOB size: %u bytes\n", mtd->oobsize);
+   printf("\t> OOB available: %u bytes\n", mtd->oobavail);
+   printf("\t> ECC strength: %u bits\n", mtd->ecc_strength);
+   printf("\t> ECC step size: %u bytes\n", mtd->ecc_step_size);
+   printf("\t> Bitflip threshold: %u bits\n", 
mtd->bitflip_threshold);
+   }
+}
+
+static void mtd_probe_devices_dm(void)
+{
+   struct udevice *dev;
+   int idx = 0;
+
+   /* Devices with DM compliant drivers */
+   while (!uclass_find_device(UCLASS_MTD, idx, ) && dev) {
+   mtd_probe(dev);
+   idx++;
+   }
+}
+
+static uint mtd_len_to_pages(struct mtd_info *mtd, u64 len)
+{
+   do_div(len, mtd->writesize);
+
+   return len;
+}
+
+static bool mtd_is_aligned_with_min_io_size(struct mtd_info *mtd, u64 size)
+{
+   return do_div(size, mtd->writesize);
+}
+
+static bool mtd_is_aligned_with_block_size(struct mtd_info *mtd, u64 size)
+{
+   return do_div(size, mtd->erasesize);
+}
+
+static int do_mtd_list(void)
+{
+   struct mtd_info *mtd;
+   int dev_nb = 0;
+
+   /* Ensure all devices are probed */
+   mtd_probe_devices_dm();
+
+   printf("List of MTD devices:\n");
+   mtd_for_each_device(mtd) {
+   mtd_show_device(mtd);
+   dev_nb++;
+   }
+
+   if (!dev_nb) {
+   printf("No 

Re: [U-Boot] [PATCH v2 13/21] spi: Extend the core to ease integration of SPI memory controllers

2018-07-12 Thread Stefan Roese
Hi Miquel,

just a quick comment below (something I stumbled upon while testing).

On 11.07.2018 17:25, Miquel Raynal wrote:
> From: Boris Brezillon 
> 
> Some controllers are exposing high-level interfaces to access various
> kind of SPI memories. Unfortunately they do not fit in the current
> spi_controller model and usually have drivers placed in
> drivers/mtd/spi-nor which are only supporting SPI NORs and not SPI
> memories in general.
> 
> This is an attempt at defining a SPI memory interface which works for
> all kinds of SPI memories (NORs, NANDs, SRAMs).
> 
> Signed-off-by: Boris Brezillon 
> Signed-off-by: Miquel Raynal 
> ---
>   drivers/spi/Kconfig   |   7 +
>   drivers/spi/Makefile  |   1 +
>   drivers/spi/spi-mem.c | 500 
> ++
>   include/spi-mem.h | 258 ++
>   include/spi.h |  11 ++
>   5 files changed, 777 insertions(+)
>   create mode 100644 drivers/spi/spi-mem.c
>   create mode 100644 include/spi-mem.h
> 
> diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
> index 235a8c7d73..0ee371b2d9 100644
> --- a/drivers/spi/Kconfig
> +++ b/drivers/spi/Kconfig
> @@ -15,6 +15,13 @@ config DM_SPI
>   
>   if DM_SPI
>   
> +config SPI_MEM
> + bool "SPI memory extension"
> + help
> +   Enable this option if you want to enable the SPI memory extension.
> +   This extension is meant to simplify interaction with SPI memories
> +   by providing an high-level interface to send memory-like commands.
> +
>   config ALTERA_SPI
>   bool "Altera SPI driver"
>   help
> diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
> index 4b6000fd9a..982529a0e6 100644
> --- a/drivers/spi/Makefile
> +++ b/drivers/spi/Makefile
> @@ -10,6 +10,7 @@ ifdef CONFIG_DM_SPI
>   obj-y += spi-uclass.o
>   obj-$(CONFIG_SANDBOX) += spi-emul-uclass.o
>   obj-$(CONFIG_SOFT_SPI) += soft_spi.o
> +obj-$(CONFIG_SPI_MEM) += spi-mem.o
>   else
>   obj-y += spi.o
>   obj-$(CONFIG_SOFT_SPI) += soft_spi_legacy.o
> diff --git a/drivers/spi/spi-mem.c b/drivers/spi/spi-mem.c
> new file mode 100644
> index 00..1aabe56819
> --- /dev/null
> +++ b/drivers/spi/spi-mem.c
> @@ -0,0 +1,500 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2018 Exceet Electronics GmbH
> + * Copyright (C) 2018 Bootlin
> + *
> + * Author: Boris Brezillon 
> + */
> +
> +#ifndef __UBOOT__
> +#include 
> +#include 
> +#include "internals.h"
> +#else
> +#include 
> +#include 
> +#endif
> +
> +#ifndef __UBOOT__
> +/**
> + * spi_controller_dma_map_mem_op_data() - DMA-map the buffer attached to a
> + * memory operation
> + * @ctlr: the SPI controller requesting this dma_map()
> + * @op: the memory operation containing the buffer to map
> + * @sgt: a pointer to a non-initialized sg_table that will be filled by this
> + *function
> + *
> + * Some controllers might want to do DMA on the data buffer embedded in @op.
> + * This helper prepares everything for you and provides a ready-to-use
> + * sg_table. This function is not intended to be called from spi drivers.
> + * Only SPI controller drivers should use it.
> + * Note that the caller must ensure the memory region pointed by
> + * op->data.buf.{in,out} is DMA-able before calling this function.
> + *
> + * Return: 0 in case of success, a negative error code otherwise.
> + */
> +int spi_controller_dma_map_mem_op_data(struct spi_controller *ctlr,
> +const struct spi_mem_op *op,
> +struct sg_table *sgt)
> +{
> + struct device *dmadev;
> +
> + if (!op->data.nbytes)
> + return -EINVAL;
> +
> + if (op->data.dir == SPI_MEM_DATA_OUT && ctlr->dma_tx)
> + dmadev = ctlr->dma_tx->device->dev;
> + else if (op->data.dir == SPI_MEM_DATA_IN && ctlr->dma_rx)
> + dmadev = ctlr->dma_rx->device->dev;
> + else
> + dmadev = ctlr->dev.parent;
> +
> + if (!dmadev)
> + return -EINVAL;
> +
> + return spi_map_buf(ctlr, dmadev, sgt, op->data.buf.in, op->data.nbytes,
> +op->data.dir == SPI_MEM_DATA_IN ?
> +DMA_FROM_DEVICE : DMA_TO_DEVICE);
> +}
> +EXPORT_SYMBOL_GPL(spi_controller_dma_map_mem_op_data);
> +
> +/**
> + * spi_controller_dma_unmap_mem_op_data() - DMA-unmap the buffer attached to 
> a
> + *   memory operation
> + * @ctlr: the SPI controller requesting this dma_unmap()
> + * @op: the memory operation containing the buffer to unmap
> + * @sgt: a pointer to an sg_table previously initialized by
> + *spi_controller_dma_map_mem_op_data()
> + *
> + * Some controllers might want to do DMA on the data buffer embedded in @op.
> + * This helper prepares things so that the CPU can access the
> + * op->data.buf.{in,out} buffer again.
> + *
> + * This function is not intended to be called from SPI drivers. Only SPI
> + * controller drivers 

[U-Boot] [PATCH v3 21/21] dt-bindings: Add bindings for SPI NAND devices

2018-07-12 Thread Miquel Raynal
From: Boris Brezillon 

Add bindings for SPI NAND chips.

Signed-off-by: Boris Brezillon 
Signed-off-by: Miquel Raynal 
---
 doc/device-tree-bindings/mtd/spi-nand.txt | 5 +
 1 file changed, 5 insertions(+)
 create mode 100644 doc/device-tree-bindings/mtd/spi-nand.txt

diff --git a/doc/device-tree-bindings/mtd/spi-nand.txt 
b/doc/device-tree-bindings/mtd/spi-nand.txt
new file mode 100644
index 00..8b51f3b6d5
--- /dev/null
+++ b/doc/device-tree-bindings/mtd/spi-nand.txt
@@ -0,0 +1,5 @@
+SPI NAND flash
+
+Required properties:
+- compatible: should be "spi-nand"
+- reg: should encode the chip-select line used to access the NAND chip
-- 
2.14.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v3 18/21] mtd: spinand: Add initial support for the MX35LF2GE4AB chip

2018-07-12 Thread Miquel Raynal
Add support for the MX35LF2GE4AB chip, which is similar to its cousin
MX35LF1GE4AB, with two planes instead of one.

Signed-off-by: Miquel Raynal 
---
 drivers/mtd/nand/spi/macronix.c | 20 ++--
 1 file changed, 14 insertions(+), 6 deletions(-)

diff --git a/drivers/mtd/nand/spi/macronix.c b/drivers/mtd/nand/spi/macronix.c
index dd351dcb6c..662c561e50 100644
--- a/drivers/mtd/nand/spi/macronix.c
+++ b/drivers/mtd/nand/spi/macronix.c
@@ -27,13 +27,13 @@ static SPINAND_OP_VARIANTS(update_cache_variants,
SPINAND_PROG_LOAD_X4(false, 0, NULL, 0),
SPINAND_PROG_LOAD(false, 0, NULL, 0));
 
-static int mx35lf1ge4ab_ooblayout_ecc(struct mtd_info *mtd, int section,
+static int mx35lfxge4ab_ooblayout_ecc(struct mtd_info *mtd, int section,
  struct mtd_oob_region *region)
 {
return -ERANGE;
 }
 
-static int mx35lf1ge4ab_ooblayout_free(struct mtd_info *mtd, int section,
+static int mx35lfxge4ab_ooblayout_free(struct mtd_info *mtd, int section,
   struct mtd_oob_region *region)
 {
if (section)
@@ -45,9 +45,9 @@ static int mx35lf1ge4ab_ooblayout_free(struct mtd_info *mtd, 
int section,
return 0;
 }
 
-static const struct mtd_ooblayout_ops mx35lf1ge4ab_ooblayout = {
-   .ecc = mx35lf1ge4ab_ooblayout_ecc,
-   .free = mx35lf1ge4ab_ooblayout_free,
+static const struct mtd_ooblayout_ops mx35lfxge4ab_ooblayout = {
+   .ecc = mx35lfxge4ab_ooblayout_ecc,
+   .free = mx35lfxge4ab_ooblayout_free,
 };
 
 static int mx35lf1ge4ab_get_eccsr(struct spinand_device *spinand, u8 *eccsr)
@@ -102,8 +102,16 @@ static const struct spinand_info macronix_spinand_table[] 
= {
  _cache_variants,
  _cache_variants),
 SPINAND_HAS_QE_BIT,
-SPINAND_ECCINFO(_ooblayout,
+SPINAND_ECCINFO(_ooblayout,
 mx35lf1ge4ab_ecc_get_status)),
+   SPINAND_INFO("MX35LF2GE4AB", 0x22,
+NAND_MEMORG(1, 2048, 64, 64, 2048, 2, 1, 1),
+NAND_ECCREQ(4, 512),
+SPINAND_INFO_OP_VARIANTS(_cache_variants,
+ _cache_variants,
+ _cache_variants),
+SPINAND_HAS_QE_BIT,
+SPINAND_ECCINFO(_ooblayout, NULL)),
 };
 
 static int macronix_spinand_detect(struct spinand_device *spinand)
-- 
2.14.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v3 12/21] mtd: nand: Pass mode information to nand_page_io_req

2018-07-12 Thread Miquel Raynal
From: Boris Brezillon 

The NAND sub-layers are likely to need the MTD_OPS_XXX mode information
in order to decide if they should enable/disable ECC or how they should
place the OOB bytes in the provided OOB buffer.

Add a field to nand_page_io_req to pass this information.

Signed-off-by: Boris Brezillon 
Signed-off-by: Miquel Raynal 
---
 include/linux/mtd/nand.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
index ada7af4a41..13e8dd1103 100644
--- a/include/linux/mtd/nand.h
+++ b/include/linux/mtd/nand.h
@@ -86,6 +86,7 @@ struct nand_pos {
  * @ooboffs: the OOB offset within the page
  * @ooblen: the number of OOB bytes to read from/write to this page
  * @oobbuf: buffer to store OOB data in or get OOB data from
+ * @mode: one of the %MTD_OPS_XXX mode
  *
  * This object is used to pass per-page I/O requests to NAND sub-layers. This
  * way all useful information are already formatted in a useful way and
@@ -106,6 +107,7 @@ struct nand_page_io_req {
const void *out;
void *in;
} oobbuf;
+   int mode;
 };
 
 /**
@@ -599,6 +601,7 @@ static inline void nanddev_io_iter_init(struct nand_device 
*nand,
 {
struct mtd_info *mtd = nanddev_to_mtd(nand);
 
+   iter->req.mode = req->mode;
iter->req.dataoffs = nanddev_offs_to_pos(nand, offs, >req.pos);
iter->req.ooboffs = req->ooboffs;
iter->oobbytes_per_page = mtd_oobavail(mtd, req);
-- 
2.14.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v3 15/21] mtd: spinand: Add initial support for Micron MT29F2G01ABAGD

2018-07-12 Thread Miquel Raynal
From: Peter Pan 

Add a basic driver for Micron SPI NANDs. Only one device is supported
right now, but the driver will be extended to support more devices
afterwards.

Signed-off-by: Peter Pan 
Signed-off-by: Boris Brezillon 
Signed-off-by: Miquel Raynal 
---
 drivers/mtd/nand/spi/Makefile |   2 +-
 drivers/mtd/nand/spi/core.c   |  17 ++
 drivers/mtd/nand/spi/micron.c | 135 ++
 include/linux/mtd/spinand.h   |   3 +
 4 files changed, 156 insertions(+), 1 deletion(-)
 create mode 100644 drivers/mtd/nand/spi/micron.c

diff --git a/drivers/mtd/nand/spi/Makefile b/drivers/mtd/nand/spi/Makefile
index f0c6e69d2e..4eb745abd4 100644
--- a/drivers/mtd/nand/spi/Makefile
+++ b/drivers/mtd/nand/spi/Makefile
@@ -1,4 +1,4 @@
 # SPDX-License-Identifier: GPL-2.0
 
-spinand-objs := core.o
+spinand-objs := core.o micron.o
 obj-$(CONFIG_MTD_SPI_NAND) += spinand.o
diff --git a/drivers/mtd/nand/spi/core.c b/drivers/mtd/nand/spi/core.c
index 08f853ae11..36b8b52bc2 100644
--- a/drivers/mtd/nand/spi/core.c
+++ b/drivers/mtd/nand/spi/core.c
@@ -829,8 +829,25 @@ static const struct nand_ops spinand_ops = {
.isbad = spinand_isbad,
 };
 
+static const struct spinand_manufacturer *spinand_manufacturers[] = {
+   _spinand_manufacturer,
+};
+
 static int spinand_manufacturer_detect(struct spinand_device *spinand)
 {
+   unsigned int i;
+   int ret;
+
+   for (i = 0; i < ARRAY_SIZE(spinand_manufacturers); i++) {
+   ret = spinand_manufacturers[i]->ops->detect(spinand);
+   if (ret > 0) {
+   spinand->manufacturer = spinand_manufacturers[i];
+   return 0;
+   } else if (ret < 0) {
+   return ret;
+   }
+   }
+
return -ENOTSUPP;
 }
 
diff --git a/drivers/mtd/nand/spi/micron.c b/drivers/mtd/nand/spi/micron.c
new file mode 100644
index 00..83951c5d0f
--- /dev/null
+++ b/drivers/mtd/nand/spi/micron.c
@@ -0,0 +1,135 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2016-2017 Micron Technology, Inc.
+ *
+ * Authors:
+ * Peter Pan 
+ */
+
+#ifndef __UBOOT__
+#include 
+#include 
+#endif
+#include 
+
+#define SPINAND_MFR_MICRON 0x2c
+
+#define MICRON_STATUS_ECC_MASK GENMASK(7, 4)
+#define MICRON_STATUS_ECC_NO_BITFLIPS  (0 << 4)
+#define MICRON_STATUS_ECC_1TO3_BITFLIPS(1 << 4)
+#define MICRON_STATUS_ECC_4TO6_BITFLIPS(3 << 4)
+#define MICRON_STATUS_ECC_7TO8_BITFLIPS(5 << 4)
+
+static SPINAND_OP_VARIANTS(read_cache_variants,
+   SPINAND_PAGE_READ_FROM_CACHE_QUADIO_OP(0, 2, NULL, 0),
+   SPINAND_PAGE_READ_FROM_CACHE_X4_OP(0, 1, NULL, 0),
+   SPINAND_PAGE_READ_FROM_CACHE_DUALIO_OP(0, 1, NULL, 0),
+   SPINAND_PAGE_READ_FROM_CACHE_X2_OP(0, 1, NULL, 0),
+   SPINAND_PAGE_READ_FROM_CACHE_OP(true, 0, 1, NULL, 0),
+   SPINAND_PAGE_READ_FROM_CACHE_OP(false, 0, 1, NULL, 0));
+
+static SPINAND_OP_VARIANTS(write_cache_variants,
+   SPINAND_PROG_LOAD_X4(true, 0, NULL, 0),
+   SPINAND_PROG_LOAD(true, 0, NULL, 0));
+
+static SPINAND_OP_VARIANTS(update_cache_variants,
+   SPINAND_PROG_LOAD_X4(false, 0, NULL, 0),
+   SPINAND_PROG_LOAD(false, 0, NULL, 0));
+
+static int mt29f2g01abagd_ooblayout_ecc(struct mtd_info *mtd, int section,
+   struct mtd_oob_region *region)
+{
+   if (section)
+   return -ERANGE;
+
+   region->offset = 64;
+   region->length = 64;
+
+   return 0;
+}
+
+static int mt29f2g01abagd_ooblayout_free(struct mtd_info *mtd, int section,
+struct mtd_oob_region *region)
+{
+   if (section)
+   return -ERANGE;
+
+   /* Reserve 2 bytes for the BBM. */
+   region->offset = 2;
+   region->length = 62;
+
+   return 0;
+}
+
+static const struct mtd_ooblayout_ops mt29f2g01abagd_ooblayout = {
+   .ecc = mt29f2g01abagd_ooblayout_ecc,
+   .free = mt29f2g01abagd_ooblayout_free,
+};
+
+static int mt29f2g01abagd_ecc_get_status(struct spinand_device *spinand,
+u8 status)
+{
+   switch (status & MICRON_STATUS_ECC_MASK) {
+   case STATUS_ECC_NO_BITFLIPS:
+   return 0;
+
+   case STATUS_ECC_UNCOR_ERROR:
+   return -EBADMSG;
+
+   case MICRON_STATUS_ECC_1TO3_BITFLIPS:
+   return 3;
+
+   case MICRON_STATUS_ECC_4TO6_BITFLIPS:
+   return 6;
+
+   case MICRON_STATUS_ECC_7TO8_BITFLIPS:
+   return 8;
+
+   default:
+   break;
+   }
+
+   return -EINVAL;
+}
+
+static const struct spinand_info micron_spinand_table[] = {
+   SPINAND_INFO("MT29F2G01ABAGD", 0x24,
+NAND_MEMORG(1, 2048, 128, 64, 2048, 2, 1, 1),
+NAND_ECCREQ(8, 512),
+

[U-Boot] [PATCH v3 14/21] mtd: nand: Add core infrastructure to support SPI NANDs

2018-07-12 Thread Miquel Raynal
From: Peter Pan 

Add a SPI NAND framework based on the generic NAND framework and the
spi-mem infrastructure.

In its current state, this framework supports the following features:

- single/dual/quad IO modes
- on-die ECC

Signed-off-by: Peter Pan 
Signed-off-by: Boris Brezillon 
Signed-off-by: Miquel Raynal 
---
 drivers/mtd/nand/Kconfig  |2 +
 drivers/mtd/nand/Makefile |1 +
 drivers/mtd/nand/spi/Kconfig  |7 +
 drivers/mtd/nand/spi/Makefile |4 +
 drivers/mtd/nand/spi/core.c   | 1235 +
 include/linux/mtd/spinand.h   |  427 ++
 6 files changed, 1676 insertions(+)
 create mode 100644 drivers/mtd/nand/spi/Kconfig
 create mode 100644 drivers/mtd/nand/spi/Makefile
 create mode 100644 drivers/mtd/nand/spi/core.c
 create mode 100644 include/linux/mtd/spinand.h

diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index 1c1a1f487e..78ae04bdcb 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -2,3 +2,5 @@ config MTD_NAND_CORE
tristate
 
 source "drivers/mtd/nand/raw/Kconfig"
+
+source "drivers/mtd/nand/spi/Kconfig"
diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile
index e07d0da46a..583e8880f3 100644
--- a/drivers/mtd/nand/Makefile
+++ b/drivers/mtd/nand/Makefile
@@ -3,3 +3,4 @@
 nandcore-objs := core.o bbt.o
 obj-$(CONFIG_MTD_NAND_CORE) += nandcore.o
 obj-$(CONFIG_MTD_NAND) += raw/
+obj-$(CONFIG_MTD_SPI_NAND) += spi/
diff --git a/drivers/mtd/nand/spi/Kconfig b/drivers/mtd/nand/spi/Kconfig
new file mode 100644
index 00..2197cb531f
--- /dev/null
+++ b/drivers/mtd/nand/spi/Kconfig
@@ -0,0 +1,7 @@
+menuconfig MTD_SPI_NAND
+   bool "SPI NAND device Support"
+   depends on MTD && DM_SPI
+   select MTD_NAND_CORE
+   select SPI_MEM
+   help
+ This is the framework for the SPI NAND device drivers.
diff --git a/drivers/mtd/nand/spi/Makefile b/drivers/mtd/nand/spi/Makefile
new file mode 100644
index 00..f0c6e69d2e
--- /dev/null
+++ b/drivers/mtd/nand/spi/Makefile
@@ -0,0 +1,4 @@
+# SPDX-License-Identifier: GPL-2.0
+
+spinand-objs := core.o
+obj-$(CONFIG_MTD_SPI_NAND) += spinand.o
diff --git a/drivers/mtd/nand/spi/core.c b/drivers/mtd/nand/spi/core.c
new file mode 100644
index 00..08f853ae11
--- /dev/null
+++ b/drivers/mtd/nand/spi/core.c
@@ -0,0 +1,1235 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2016-2017 Micron Technology, Inc.
+ *
+ * Authors:
+ * Peter Pan 
+ * Boris Brezillon 
+ */
+
+#define pr_fmt(fmt)"spi-nand: " fmt
+
+#ifndef __UBOOT__
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#else
+#include 
+#include 
+#include 
+#include 
+#include 
+#endif
+
+/* SPI NAND index visible in MTD names */
+static int spi_nand_idx;
+
+static void spinand_cache_op_adjust_colum(struct spinand_device *spinand,
+ const struct nand_page_io_req *req,
+ u16 *column)
+{
+   struct nand_device *nand = spinand_to_nand(spinand);
+   unsigned int shift;
+
+   if (nand->memorg.planes_per_lun < 2)
+   return;
+
+   /* The plane number is passed in MSB just above the column address */
+   shift = fls(nand->memorg.pagesize);
+   *column |= req->pos.plane << shift;
+}
+
+static int spinand_read_reg_op(struct spinand_device *spinand, u8 reg, u8 *val)
+{
+   struct spi_mem_op op = SPINAND_GET_FEATURE_OP(reg,
+ spinand->scratchbuf);
+   int ret;
+
+   ret = spi_mem_exec_op(spinand->slave, );
+   if (ret)
+   return ret;
+
+   *val = *spinand->scratchbuf;
+   return 0;
+}
+
+static int spinand_write_reg_op(struct spinand_device *spinand, u8 reg, u8 val)
+{
+   struct spi_mem_op op = SPINAND_SET_FEATURE_OP(reg,
+ spinand->scratchbuf);
+
+   *spinand->scratchbuf = val;
+   return spi_mem_exec_op(spinand->slave, );
+}
+
+static int spinand_read_status(struct spinand_device *spinand, u8 *status)
+{
+   return spinand_read_reg_op(spinand, REG_STATUS, status);
+}
+
+static int spinand_get_cfg(struct spinand_device *spinand, u8 *cfg)
+{
+   struct nand_device *nand = spinand_to_nand(spinand);
+
+   if (WARN_ON(spinand->cur_target < 0 ||
+   spinand->cur_target >= nand->memorg.ntargets))
+   return -EINVAL;
+
+   *cfg = spinand->cfg_cache[spinand->cur_target];
+   return 0;
+}
+
+static int spinand_set_cfg(struct spinand_device *spinand, u8 cfg)
+{
+   struct nand_device *nand = spinand_to_nand(spinand);
+   int ret;
+
+   if (WARN_ON(spinand->cur_target < 0 ||
+   spinand->cur_target >= nand->memorg.ntargets))
+   return -EINVAL;
+
+   if (spinand->cfg_cache[spinand->cur_target] == cfg)
+   return 0;
+
+   ret = 

[U-Boot] [PATCH v3 19/21] mtd: uclass: add probe function

2018-07-12 Thread Miquel Raynal
The user might want to trigger the probe of any MTD device, export these
functions so they can be called from a command source file.

Signed-off-by: Miquel Raynal 
---
 drivers/mtd/mtd-uclass.c | 9 +
 include/linux/mtd/mtd.h  | 3 +++
 2 files changed, 12 insertions(+)

diff --git a/drivers/mtd/mtd-uclass.c b/drivers/mtd/mtd-uclass.c
index 9ca049c437..9a9470410c 100644
--- a/drivers/mtd/mtd-uclass.c
+++ b/drivers/mtd/mtd-uclass.c
@@ -5,6 +5,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -13,6 +14,14 @@
  * The uclass private is pointed to mtd_info.
  */
 
+int mtd_probe(struct udevice *dev)
+{
+   if (device_active(dev))
+   return 0;
+
+   return device_probe(dev);
+}
+
 UCLASS_DRIVER(mtd) = {
.id = UCLASS_MTD,
.name   = "mtd",
diff --git a/include/linux/mtd/mtd.h b/include/linux/mtd/mtd.h
index cba1b9e875..285875f4cf 100644
--- a/include/linux/mtd/mtd.h
+++ b/include/linux/mtd/mtd.h
@@ -537,5 +537,8 @@ int mtd_arg_off_size(int argc, char *const argv[], int 
*idx, loff_t *off,
 void mtd_get_len_incl_bad(struct mtd_info *mtd, uint64_t offset,
  const uint64_t length, uint64_t *len_incl_bad,
  int *truncated);
+
+int mtd_probe(struct udevice *dev);
+
 #endif
 #endif /* __MTD_MTD_H__ */
-- 
2.14.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v3 16/21] mtd: spinand: Add initial support for Winbond W25M02GV

2018-07-12 Thread Miquel Raynal
From: Frieder Schrempf 

Add support for the W25M02GV chip.

Signed-off-by: Frieder Schrempf 
Signed-off-by: Boris Brezillon 
Signed-off-by: Miquel Raynal 
---
 drivers/mtd/nand/spi/Makefile  |   2 +-
 drivers/mtd/nand/spi/core.c|   1 +
 drivers/mtd/nand/spi/winbond.c | 143 +
 include/linux/mtd/spinand.h|   1 +
 4 files changed, 146 insertions(+), 1 deletion(-)
 create mode 100644 drivers/mtd/nand/spi/winbond.c

diff --git a/drivers/mtd/nand/spi/Makefile b/drivers/mtd/nand/spi/Makefile
index 4eb745abd4..11ba5de68b 100644
--- a/drivers/mtd/nand/spi/Makefile
+++ b/drivers/mtd/nand/spi/Makefile
@@ -1,4 +1,4 @@
 # SPDX-License-Identifier: GPL-2.0
 
-spinand-objs := core.o micron.o
+spinand-objs := core.o micron.o winbond.o
 obj-$(CONFIG_MTD_SPI_NAND) += spinand.o
diff --git a/drivers/mtd/nand/spi/core.c b/drivers/mtd/nand/spi/core.c
index 36b8b52bc2..ef3e6445d8 100644
--- a/drivers/mtd/nand/spi/core.c
+++ b/drivers/mtd/nand/spi/core.c
@@ -831,6 +831,7 @@ static const struct nand_ops spinand_ops = {
 
 static const struct spinand_manufacturer *spinand_manufacturers[] = {
_spinand_manufacturer,
+   _spinand_manufacturer,
 };
 
 static int spinand_manufacturer_detect(struct spinand_device *spinand)
diff --git a/drivers/mtd/nand/spi/winbond.c b/drivers/mtd/nand/spi/winbond.c
new file mode 100644
index 00..eac811d97c
--- /dev/null
+++ b/drivers/mtd/nand/spi/winbond.c
@@ -0,0 +1,143 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2017 exceet electronics GmbH
+ *
+ * Authors:
+ * Frieder Schrempf 
+ * Boris Brezillon 
+ */
+
+#ifndef __UBOOT__
+#include 
+#include 
+#endif
+#include 
+
+#define SPINAND_MFR_WINBOND0xEF
+
+#define WINBOND_CFG_BUF_READ   BIT(3)
+
+static SPINAND_OP_VARIANTS(read_cache_variants,
+   SPINAND_PAGE_READ_FROM_CACHE_QUADIO_OP(0, 2, NULL, 0),
+   SPINAND_PAGE_READ_FROM_CACHE_X4_OP(0, 1, NULL, 0),
+   SPINAND_PAGE_READ_FROM_CACHE_DUALIO_OP(0, 1, NULL, 0),
+   SPINAND_PAGE_READ_FROM_CACHE_X2_OP(0, 1, NULL, 0),
+   SPINAND_PAGE_READ_FROM_CACHE_OP(true, 0, 1, NULL, 0),
+   SPINAND_PAGE_READ_FROM_CACHE_OP(false, 0, 1, NULL, 0));
+
+static SPINAND_OP_VARIANTS(write_cache_variants,
+   SPINAND_PROG_LOAD_X4(true, 0, NULL, 0),
+   SPINAND_PROG_LOAD(true, 0, NULL, 0));
+
+static SPINAND_OP_VARIANTS(update_cache_variants,
+   SPINAND_PROG_LOAD_X4(false, 0, NULL, 0),
+   SPINAND_PROG_LOAD(false, 0, NULL, 0));
+
+static int w25m02gv_ooblayout_ecc(struct mtd_info *mtd, int section,
+ struct mtd_oob_region *region)
+{
+   if (section > 3)
+   return -ERANGE;
+
+   region->offset = (16 * section) + 8;
+   region->length = 8;
+
+   return 0;
+}
+
+static int w25m02gv_ooblayout_free(struct mtd_info *mtd, int section,
+  struct mtd_oob_region *region)
+{
+   if (section > 3)
+   return -ERANGE;
+
+   region->offset = (16 * section) + 2;
+   region->length = 6;
+
+   return 0;
+}
+
+static const struct mtd_ooblayout_ops w25m02gv_ooblayout = {
+   .ecc = w25m02gv_ooblayout_ecc,
+   .free = w25m02gv_ooblayout_free,
+};
+
+static int w25m02gv_select_target(struct spinand_device *spinand,
+ unsigned int target)
+{
+   struct spi_mem_op op = SPI_MEM_OP(SPI_MEM_OP_CMD(0xc2, 1),
+ SPI_MEM_OP_NO_ADDR,
+ SPI_MEM_OP_NO_DUMMY,
+ SPI_MEM_OP_DATA_OUT(1,
+   spinand->scratchbuf,
+   1));
+
+   *spinand->scratchbuf = target;
+   return spi_mem_exec_op(spinand->slave, );
+}
+
+static const struct spinand_info winbond_spinand_table[] = {
+   SPINAND_INFO("W25M02GV", 0xAB,
+NAND_MEMORG(1, 2048, 64, 64, 1024, 1, 1, 2),
+NAND_ECCREQ(1, 512),
+SPINAND_INFO_OP_VARIANTS(_cache_variants,
+ _cache_variants,
+ _cache_variants),
+0,
+SPINAND_ECCINFO(_ooblayout, NULL),
+SPINAND_SELECT_TARGET(w25m02gv_select_target)),
+};
+
+/**
+ * winbond_spinand_detect - initialize device related part in spinand_device
+ * struct if it is a Winbond device.
+ * @spinand: SPI NAND device structure
+ */
+static int winbond_spinand_detect(struct spinand_device *spinand)
+{
+   u8 *id = spinand->id.data;
+   int ret;
+
+   /*
+* Winbond SPI NAND read ID need a dummy byte,
+* so the first byte in raw_id is dummy.
+*/
+   if (id[1] != SPINAND_MFR_WINBOND)
+   return 0;
+
+   ret = 

[U-Boot] [PATCH v3 17/21] mtd: spinand: Add initial support for the MX35LF1GE4AB chip

2018-07-12 Thread Miquel Raynal
From: Boris Brezillon 

Add minimal support for the MX35LF1GE4AB SPI NAND chip.

Signed-off-by: Boris Brezillon 
---
 drivers/mtd/nand/spi/Makefile   |   2 +-
 drivers/mtd/nand/spi/core.c |   1 +
 drivers/mtd/nand/spi/macronix.c | 138 
 include/linux/mtd/spinand.h |   1 +
 4 files changed, 141 insertions(+), 1 deletion(-)
 create mode 100644 drivers/mtd/nand/spi/macronix.c

diff --git a/drivers/mtd/nand/spi/Makefile b/drivers/mtd/nand/spi/Makefile
index 11ba5de68b..a66edd9199 100644
--- a/drivers/mtd/nand/spi/Makefile
+++ b/drivers/mtd/nand/spi/Makefile
@@ -1,4 +1,4 @@
 # SPDX-License-Identifier: GPL-2.0
 
-spinand-objs := core.o micron.o winbond.o
+spinand-objs := core.o macronix.o micron.o winbond.o
 obj-$(CONFIG_MTD_SPI_NAND) += spinand.o
diff --git a/drivers/mtd/nand/spi/core.c b/drivers/mtd/nand/spi/core.c
index ef3e6445d8..362d104846 100644
--- a/drivers/mtd/nand/spi/core.c
+++ b/drivers/mtd/nand/spi/core.c
@@ -830,6 +830,7 @@ static const struct nand_ops spinand_ops = {
 };
 
 static const struct spinand_manufacturer *spinand_manufacturers[] = {
+   _spinand_manufacturer,
_spinand_manufacturer,
_spinand_manufacturer,
 };
diff --git a/drivers/mtd/nand/spi/macronix.c b/drivers/mtd/nand/spi/macronix.c
new file mode 100644
index 00..dd351dcb6c
--- /dev/null
+++ b/drivers/mtd/nand/spi/macronix.c
@@ -0,0 +1,138 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2018 Macronix
+ *
+ * Author: Boris Brezillon 
+ */
+
+#ifndef __UBOOT__
+#include 
+#include 
+#endif
+#include 
+
+#define SPINAND_MFR_MACRONIX   0xC2
+
+static SPINAND_OP_VARIANTS(read_cache_variants,
+   SPINAND_PAGE_READ_FROM_CACHE_X4_OP(0, 1, NULL, 0),
+   SPINAND_PAGE_READ_FROM_CACHE_X2_OP(0, 1, NULL, 0),
+   SPINAND_PAGE_READ_FROM_CACHE_OP(true, 0, 1, NULL, 0),
+   SPINAND_PAGE_READ_FROM_CACHE_OP(false, 0, 1, NULL, 0));
+
+static SPINAND_OP_VARIANTS(write_cache_variants,
+   SPINAND_PROG_LOAD_X4(true, 0, NULL, 0),
+   SPINAND_PROG_LOAD(true, 0, NULL, 0));
+
+static SPINAND_OP_VARIANTS(update_cache_variants,
+   SPINAND_PROG_LOAD_X4(false, 0, NULL, 0),
+   SPINAND_PROG_LOAD(false, 0, NULL, 0));
+
+static int mx35lf1ge4ab_ooblayout_ecc(struct mtd_info *mtd, int section,
+ struct mtd_oob_region *region)
+{
+   return -ERANGE;
+}
+
+static int mx35lf1ge4ab_ooblayout_free(struct mtd_info *mtd, int section,
+  struct mtd_oob_region *region)
+{
+   if (section)
+   return -ERANGE;
+
+   region->offset = 2;
+   region->length = mtd->oobsize - 2;
+
+   return 0;
+}
+
+static const struct mtd_ooblayout_ops mx35lf1ge4ab_ooblayout = {
+   .ecc = mx35lf1ge4ab_ooblayout_ecc,
+   .free = mx35lf1ge4ab_ooblayout_free,
+};
+
+static int mx35lf1ge4ab_get_eccsr(struct spinand_device *spinand, u8 *eccsr)
+{
+   struct spi_mem_op op = SPI_MEM_OP(SPI_MEM_OP_CMD(0x7c, 1),
+ SPI_MEM_OP_NO_ADDR,
+ SPI_MEM_OP_DUMMY(1, 1),
+ SPI_MEM_OP_DATA_IN(1, eccsr, 1));
+
+   return spi_mem_exec_op(spinand->slave, );
+}
+
+static int mx35lf1ge4ab_ecc_get_status(struct spinand_device *spinand,
+  u8 status)
+{
+   struct nand_device *nand = spinand_to_nand(spinand);
+   u8 eccsr;
+
+   switch (status & STATUS_ECC_MASK) {
+   case STATUS_ECC_NO_BITFLIPS:
+   return 0;
+
+   case STATUS_ECC_UNCOR_ERROR:
+   return -EBADMSG;
+
+   case STATUS_ECC_HAS_BITFLIPS:
+   /*
+* Let's try to retrieve the real maximum number of bitflips
+* in order to avoid forcing the wear-leveling layer to move
+* data around if it's not necessary.
+*/
+   if (mx35lf1ge4ab_get_eccsr(spinand, ))
+   return nand->eccreq.strength;
+
+   if (WARN_ON(eccsr > nand->eccreq.strength || !eccsr))
+   return nand->eccreq.strength;
+
+   return eccsr;
+
+   default:
+   break;
+   }
+
+   return -EINVAL;
+}
+
+static const struct spinand_info macronix_spinand_table[] = {
+   SPINAND_INFO("MX35LF1GE4AB", 0x12,
+NAND_MEMORG(1, 2048, 64, 64, 1024, 1, 1, 1),
+NAND_ECCREQ(4, 512),
+SPINAND_INFO_OP_VARIANTS(_cache_variants,
+ _cache_variants,
+ _cache_variants),
+SPINAND_HAS_QE_BIT,
+SPINAND_ECCINFO(_ooblayout,
+mx35lf1ge4ab_ecc_get_status)),
+};
+
+static int macronix_spinand_detect(struct spinand_device *spinand)
+{
+ 

[U-Boot] [PATCH v3 11/21] mtd: nand: Add core infrastructure to deal with NAND devices

2018-07-12 Thread Miquel Raynal
From: Boris Brezillon 

Add an intermediate layer to abstract NAND device interface so that
some logic can be shared between SPI NANDs, parallel/raw NANDs,
OneNANDs, ...

Signed-off-by: Boris Brezillon 
Signed-off-by: Miquel Raynal 
---
 drivers/mtd/nand/Kconfig  |   3 +
 drivers/mtd/nand/Makefile |   2 +
 drivers/mtd/nand/bbt.c| 132 +
 drivers/mtd/nand/core.c   | 243 +++
 include/linux/mtd/nand.h  | 731 ++
 5 files changed,  insertions(+)
 create mode 100644 drivers/mtd/nand/bbt.c
 create mode 100644 drivers/mtd/nand/core.c
 create mode 100644 include/linux/mtd/nand.h

diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index 6d53734718..1c1a1f487e 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -1 +1,4 @@
+config MTD_NAND_CORE
+   tristate
+
 source "drivers/mtd/nand/raw/Kconfig"
diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile
index 8b2d0e118d..e07d0da46a 100644
--- a/drivers/mtd/nand/Makefile
+++ b/drivers/mtd/nand/Makefile
@@ -1,3 +1,5 @@
 # SPDX-License-Identifier: GPL-2.0+
 
+nandcore-objs := core.o bbt.o
+obj-$(CONFIG_MTD_NAND_CORE) += nandcore.o
 obj-$(CONFIG_MTD_NAND) += raw/
diff --git a/drivers/mtd/nand/bbt.c b/drivers/mtd/nand/bbt.c
new file mode 100644
index 00..7e0ad3190c
--- /dev/null
+++ b/drivers/mtd/nand/bbt.c
@@ -0,0 +1,132 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2017 Free Electrons
+ *
+ * Authors:
+ * Boris Brezillon 
+ * Peter Pan 
+ */
+
+#define pr_fmt(fmt)"nand-bbt: " fmt
+
+#include 
+#ifndef __UBOOT__
+#include 
+#endif
+
+/**
+ * nanddev_bbt_init() - Initialize the BBT (Bad Block Table)
+ * @nand: NAND device
+ *
+ * Initialize the in-memory BBT.
+ *
+ * Return: 0 in case of success, a negative error code otherwise.
+ */
+int nanddev_bbt_init(struct nand_device *nand)
+{
+   unsigned int bits_per_block = fls(NAND_BBT_BLOCK_NUM_STATUS);
+   unsigned int nblocks = nanddev_neraseblocks(nand);
+   unsigned int nwords = DIV_ROUND_UP(nblocks * bits_per_block,
+  BITS_PER_LONG);
+
+   nand->bbt.cache = kzalloc(nwords, GFP_KERNEL);
+   if (!nand->bbt.cache)
+   return -ENOMEM;
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(nanddev_bbt_init);
+
+/**
+ * nanddev_bbt_cleanup() - Cleanup the BBT (Bad Block Table)
+ * @nand: NAND device
+ *
+ * Undoes what has been done in nanddev_bbt_init()
+ */
+void nanddev_bbt_cleanup(struct nand_device *nand)
+{
+   kfree(nand->bbt.cache);
+}
+EXPORT_SYMBOL_GPL(nanddev_bbt_cleanup);
+
+/**
+ * nanddev_bbt_update() - Update a BBT
+ * @nand: nand device
+ *
+ * Update the BBT. Currently a NOP function since on-flash bbt is not yet
+ * supported.
+ *
+ * Return: 0 in case of success, a negative error code otherwise.
+ */
+int nanddev_bbt_update(struct nand_device *nand)
+{
+   return 0;
+}
+EXPORT_SYMBOL_GPL(nanddev_bbt_update);
+
+/**
+ * nanddev_bbt_get_block_status() - Return the status of an eraseblock
+ * @nand: nand device
+ * @entry: the BBT entry
+ *
+ * Return: a positive number nand_bbt_block_status status or -%ERANGE if @entry
+ *is bigger than the BBT size.
+ */
+int nanddev_bbt_get_block_status(const struct nand_device *nand,
+unsigned int entry)
+{
+   unsigned int bits_per_block = fls(NAND_BBT_BLOCK_NUM_STATUS);
+   unsigned long *pos = nand->bbt.cache +
+((entry * bits_per_block) / BITS_PER_LONG);
+   unsigned int offs = (entry * bits_per_block) % BITS_PER_LONG;
+   unsigned long status;
+
+   if (entry >= nanddev_neraseblocks(nand))
+   return -ERANGE;
+
+   status = pos[0] >> offs;
+   if (bits_per_block + offs > BITS_PER_LONG)
+   status |= pos[1] << (BITS_PER_LONG - offs);
+
+   return status & GENMASK(bits_per_block - 1, 0);
+}
+EXPORT_SYMBOL_GPL(nanddev_bbt_get_block_status);
+
+/**
+ * nanddev_bbt_set_block_status() - Update the status of an eraseblock in the
+ * in-memory BBT
+ * @nand: nand device
+ * @entry: the BBT entry to update
+ * @status: the new status
+ *
+ * Update an entry of the in-memory BBT. If you want to push the updated BBT
+ * the NAND you should call nanddev_bbt_update().
+ *
+ * Return: 0 in case of success or -%ERANGE if @entry is bigger than the BBT
+ *size.
+ */
+int nanddev_bbt_set_block_status(struct nand_device *nand, unsigned int entry,
+enum nand_bbt_block_status status)
+{
+   unsigned int bits_per_block = fls(NAND_BBT_BLOCK_NUM_STATUS);
+   unsigned long *pos = nand->bbt.cache +
+((entry * bits_per_block) / BITS_PER_LONG);
+   unsigned int offs = (entry * bits_per_block) % BITS_PER_LONG;
+   unsigned long val = status & GENMASK(bits_per_block - 1, 0);
+
+   if (entry >= nanddev_neraseblocks(nand))
+   

[U-Boot] [PATCH v3 04/21] mtd: Fallback to ->_read/write() when ->_read/write_oob() is missing

2018-07-12 Thread Miquel Raynal
Some MTD sublayers/drivers are implementing ->_read/write() and
not ->_read/write_oob().

While for NAND devices both are usually valid, for NOR devices, using
the _oob variant has no real meaning. But, as the MTD layer is supposed
to hide as much as possible the flash complexity to the user, there is
no reason to error out while it is just a matter of rewritting things
internally.

Add a fallback on mtd->_read() (resp. mtd->_write()) when the user calls
mtd_read_oob() (resp. mtd_write_oob()) while mtd->_read_oob() (resp.
mtd->_write_oob) is not implemented. There is already a fallback on the
_oob variant if the former is used.

Signed-off-by: Miquel Raynal 
---
 drivers/mtd/mtdcore.c | 26 --
 1 file changed, 20 insertions(+), 6 deletions(-)

diff --git a/drivers/mtd/mtdcore.c b/drivers/mtd/mtdcore.c
index 9a3efe95df..fb1d68d5e2 100644
--- a/drivers/mtd/mtdcore.c
+++ b/drivers/mtd/mtdcore.c
@@ -1047,20 +1047,27 @@ int mtd_read_oob(struct mtd_info *mtd, loff_t from, 
struct mtd_oob_ops *ops)
 {
int ret_code;
ops->retlen = ops->oobretlen = 0;
-   if (!mtd->_read_oob)
-   return -EOPNOTSUPP;
 
ret_code = mtd_check_oob_ops(mtd, from, ops);
if (ret_code)
return ret_code;
 
+   /* Check the validity of a potential fallback on mtd->_read */
+   if (!mtd->_read_oob && (!mtd->_read || ops->oobbuf))
+   return -EOPNOTSUPP;
+
+   if (mtd->_read_oob)
+   ret_code = mtd->_read_oob(mtd, from, ops);
+   else
+   ret_code = mtd->_read(mtd, from, ops->len, >retlen,
+ ops->datbuf);
+
/*
 * In cases where ops->datbuf != NULL, mtd->_read_oob() has semantics
 * similar to mtd->_read(), returning a non-negative integer
 * representing max bitflips. In other cases, mtd->_read_oob() may
 * return -EUCLEAN. In all cases, perform similar logic to mtd_read().
 */
-   ret_code = mtd->_read_oob(mtd, from, ops);
if (unlikely(ret_code < 0))
return ret_code;
if (mtd->ecc_strength == 0)
@@ -1075,8 +1082,7 @@ int mtd_write_oob(struct mtd_info *mtd, loff_t to,
int ret;
 
ops->retlen = ops->oobretlen = 0;
-   if (!mtd->_write_oob)
-   return -EOPNOTSUPP;
+
if (!(mtd->flags & MTD_WRITEABLE))
return -EROFS;
 
@@ -1084,7 +1090,15 @@ int mtd_write_oob(struct mtd_info *mtd, loff_t to,
if (ret)
return ret;
 
-   return mtd->_write_oob(mtd, to, ops);
+   /* Check the validity of a potential fallback on mtd->_write */
+   if (!mtd->_write_oob && (!mtd->_write || ops->oobbuf))
+   return -EOPNOTSUPP;
+
+   if (mtd->_write_oob)
+   return mtd->_write_oob(mtd, to, ops);
+   else
+   return mtd->_write(mtd, to, ops->len, >retlen,
+  ops->datbuf);
 }
 EXPORT_SYMBOL_GPL(mtd_write_oob);
 
-- 
2.14.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v3 08/21] mtd: move all flash categories inside MTD submenu

2018-07-12 Thread Miquel Raynal
There is no reason to have NAND, SPI flashes and UBI sections outside of
the MTD submenu in Kconfig.

Signed-off-by: Miquel Raynal 
Reviewed-by: Jagan Teki 
---
 drivers/mtd/Kconfig | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/mtd/Kconfig b/drivers/mtd/Kconfig
index 707359dca1..5f52e9b3f8 100644
--- a/drivers/mtd/Kconfig
+++ b/drivers/mtd/Kconfig
@@ -47,10 +47,10 @@ config RENESAS_RPC_HF
  This enables access to Hyperflash memory through the Renesas
  RCar Gen3 RPC controller.
 
-endmenu
-
 source "drivers/mtd/nand/Kconfig"
 
 source "drivers/mtd/spi/Kconfig"
 
 source "drivers/mtd/ubi/Kconfig"
+
+endmenu
-- 
2.14.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v3 06/21] mtd: fix build issue with includes

2018-07-12 Thread Miquel Raynal
Fix build errors produced by mtd.h and dm/device.h if not included in
the right order.

Signed-off-by: Miquel Raynal 
Reviewed-by: Jagan Teki 
---
 include/linux/mtd/mtd.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/linux/mtd/mtd.h b/include/linux/mtd/mtd.h
index 78eb745c04..32e3f31f8c 100644
--- a/include/linux/mtd/mtd.h
+++ b/include/linux/mtd/mtd.h
@@ -21,6 +21,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define MAX_MTD_DEVICES 32
 #endif
-- 
2.14.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v3 07/21] mtd: move definitions to enlarge their range

2018-07-12 Thread Miquel Raynal
Some helpers might be useful in a future 'mtd' U-Boot command to parse
MTD device list.

Signed-off-by: Miquel Raynal 
---
 drivers/mtd/mtdcore.h   | 6 --
 include/linux/mtd/mtd.h | 6 ++
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/mtd/mtdcore.h b/drivers/mtd/mtdcore.h
index 7b0353399a..1d181a1045 100644
--- a/drivers/mtd/mtdcore.h
+++ b/drivers/mtd/mtdcore.h
@@ -5,7 +5,6 @@
 
 extern struct mutex mtd_table_mutex;
 
-struct mtd_info *__mtd_next_device(int i);
 int add_mtd_device(struct mtd_info *mtd);
 int del_mtd_device(struct mtd_info *mtd);
 int add_mtd_partitions(struct mtd_info *, const struct mtd_partition *, int);
@@ -16,8 +15,3 @@ int parse_mtd_partitions(struct mtd_info *master, const char 
* const *types,
 
 int __init init_mtdchar(void);
 void __exit cleanup_mtdchar(void);
-
-#define mtd_for_each_device(mtd)   \
-   for ((mtd) = __mtd_next_device(0);  \
-(mtd) != NULL; \
-(mtd) = __mtd_next_device(mtd->index + 1))
diff --git a/include/linux/mtd/mtd.h b/include/linux/mtd/mtd.h
index 32e3f31f8c..cba1b9e875 100644
--- a/include/linux/mtd/mtd.h
+++ b/include/linux/mtd/mtd.h
@@ -521,6 +521,12 @@ int del_mtd_device(struct mtd_info *mtd);
 int add_mtd_partitions(struct mtd_info *, const struct mtd_partition *, int);
 int del_mtd_partitions(struct mtd_info *);
 
+struct mtd_info *__mtd_next_device(int i);
+#define mtd_for_each_device(mtd)   \
+   for ((mtd) = __mtd_next_device(0);  \
+(mtd) != NULL; \
+(mtd) = __mtd_next_device(mtd->index + 1))
+
 int mtd_arg_off(const char *arg, int *idx, loff_t *off, loff_t *size,
loff_t *maxsize, int devtype, uint64_t chipsize);
 int mtd_arg_off_size(int argc, char *const argv[], int *idx, loff_t *off,
-- 
2.14.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v3 09/21] mtd: move NAND files into a raw/ subdirectory

2018-07-12 Thread Miquel Raynal
NAND flavors, like serial and parallel, have a lot in common and would
benefit to share code. Let's move raw (parallel) NAND specific code in a
raw/ subdirectory, to ease the addition of a core file in nand/ and the
introduction of a spi/ subdirectory specific to SPI NANDs.

Signed-off-by: Miquel Raynal 
---
 drivers/mtd/Makefile  |   2 +
 drivers/mtd/nand/Kconfig  | 280 +-
 drivers/mtd/nand/Makefile |  76 +--
 drivers/mtd/nand/raw/Kconfig  | 279 +
 drivers/mtd/nand/raw/Makefile |  77 +++
 drivers/mtd/nand/{ => raw}/am335x_spl_bch.c   |   0
 drivers/mtd/nand/{ => raw}/arasan_nfc.c   |   0
 drivers/mtd/nand/{ => raw}/atmel_nand.c   |   0
 drivers/mtd/nand/{ => raw}/atmel_nand_ecc.h   |   0
 drivers/mtd/nand/{ => raw}/davinci_nand.c |   0
 drivers/mtd/nand/{ => raw}/denali.c   |   0
 drivers/mtd/nand/{ => raw}/denali.h   |   0
 drivers/mtd/nand/{ => raw}/denali_dt.c|   0
 drivers/mtd/nand/{ => raw}/denali_spl.c   |   0
 drivers/mtd/nand/{ => raw}/fsl_elbc_nand.c|   0
 drivers/mtd/nand/{ => raw}/fsl_elbc_spl.c |   0
 drivers/mtd/nand/{ => raw}/fsl_ifc_nand.c |   0
 drivers/mtd/nand/{ => raw}/fsl_ifc_spl.c  |   0
 drivers/mtd/nand/{ => raw}/fsl_upm.c  |   0
 drivers/mtd/nand/{ => raw}/fsmc_nand.c|   0
 drivers/mtd/nand/{ => raw}/kb9202_nand.c  |   0
 drivers/mtd/nand/{ => raw}/kirkwood_nand.c|   0
 drivers/mtd/nand/{ => raw}/kmeter1_nand.c |   0
 drivers/mtd/nand/{ => raw}/lpc32xx_nand_mlc.c |   0
 drivers/mtd/nand/{ => raw}/lpc32xx_nand_slc.c |   0
 drivers/mtd/nand/{ => raw}/mxc_nand.c |   0
 drivers/mtd/nand/{ => raw}/mxc_nand.h |   0
 drivers/mtd/nand/{ => raw}/mxc_nand_spl.c |   0
 drivers/mtd/nand/{ => raw}/mxs_nand.c |   0
 drivers/mtd/nand/{ => raw}/mxs_nand.h |   0
 drivers/mtd/nand/{ => raw}/mxs_nand_dt.c  |   0
 drivers/mtd/nand/{ => raw}/mxs_nand_spl.c |   0
 drivers/mtd/nand/{ => raw}/nand.c |   0
 drivers/mtd/nand/{ => raw}/nand_base.c|   0
 drivers/mtd/nand/{ => raw}/nand_bbt.c |   0
 drivers/mtd/nand/{ => raw}/nand_bch.c |   0
 drivers/mtd/nand/{ => raw}/nand_ecc.c |   0
 drivers/mtd/nand/{ => raw}/nand_ids.c |   0
 drivers/mtd/nand/{ => raw}/nand_plat.c|   0
 drivers/mtd/nand/{ => raw}/nand_spl_load.c|   0
 drivers/mtd/nand/{ => raw}/nand_spl_loaders.c |   0
 drivers/mtd/nand/{ => raw}/nand_spl_simple.c  |   0
 drivers/mtd/nand/{ => raw}/nand_timings.c |   0
 drivers/mtd/nand/{ => raw}/nand_util.c|   0
 drivers/mtd/nand/{ => raw}/omap_elm.c |   0
 drivers/mtd/nand/{ => raw}/omap_gpmc.c|   0
 drivers/mtd/nand/{ => raw}/pxa3xx_nand.c  |   0
 drivers/mtd/nand/{ => raw}/pxa3xx_nand.h  |   0
 drivers/mtd/nand/{ => raw}/sunxi_nand.c   |   0
 drivers/mtd/nand/{ => raw}/sunxi_nand_spl.c   |   0
 drivers/mtd/nand/{ => raw}/tegra_nand.c   |   0
 drivers/mtd/nand/{ => raw}/tegra_nand.h   |   0
 drivers/mtd/nand/{ => raw}/vf610_nfc.c|   0
 drivers/mtd/nand/{ => raw}/zynq_nand.c|   0
 54 files changed, 360 insertions(+), 354 deletions(-)
 create mode 100644 drivers/mtd/nand/raw/Kconfig
 create mode 100644 drivers/mtd/nand/raw/Makefile
 rename drivers/mtd/nand/{ => raw}/am335x_spl_bch.c (100%)
 rename drivers/mtd/nand/{ => raw}/arasan_nfc.c (100%)
 rename drivers/mtd/nand/{ => raw}/atmel_nand.c (100%)
 rename drivers/mtd/nand/{ => raw}/atmel_nand_ecc.h (100%)
 rename drivers/mtd/nand/{ => raw}/davinci_nand.c (100%)
 rename drivers/mtd/nand/{ => raw}/denali.c (100%)
 rename drivers/mtd/nand/{ => raw}/denali.h (100%)
 rename drivers/mtd/nand/{ => raw}/denali_dt.c (100%)
 rename drivers/mtd/nand/{ => raw}/denali_spl.c (100%)
 rename drivers/mtd/nand/{ => raw}/fsl_elbc_nand.c (100%)
 rename drivers/mtd/nand/{ => raw}/fsl_elbc_spl.c (100%)
 rename drivers/mtd/nand/{ => raw}/fsl_ifc_nand.c (100%)
 rename drivers/mtd/nand/{ => raw}/fsl_ifc_spl.c (100%)
 rename drivers/mtd/nand/{ => raw}/fsl_upm.c (100%)
 rename drivers/mtd/nand/{ => raw}/fsmc_nand.c (100%)
 rename drivers/mtd/nand/{ => raw}/kb9202_nand.c (100%)
 rename drivers/mtd/nand/{ => raw}/kirkwood_nand.c (100%)
 rename drivers/mtd/nand/{ => raw}/kmeter1_nand.c (100%)
 rename drivers/mtd/nand/{ => raw}/lpc32xx_nand_mlc.c (100%)
 rename drivers/mtd/nand/{ => raw}/lpc32xx_nand_slc.c (100%)
 rename drivers/mtd/nand/{ => raw}/mxc_nand.c (100%)
 rename drivers/mtd/nand/{ => raw}/mxc_nand.h (100%)
 rename drivers/mtd/nand/{ => raw}/mxc_nand_spl.c (100%)
 rename drivers/mtd/nand/{ => raw}/mxs_nand.c (100%)
 rename drivers/mtd/nand/{ => raw}/mxs_nand.h (100%)
 rename drivers/mtd/nand/{ => raw}/mxs_nand_dt.c (100%)
 rename drivers/mtd/nand/{ => raw}/mxs_nand_spl.c (100%)
 rename drivers/mtd/nand/{ => raw}/nand.c (100%)
 rename drivers/mtd/nand/{ => raw}/nand_base.c 

[U-Boot] [PATCH v3 10/21] mtd: rename nand into rawnand in Kconfig prompt

2018-07-12 Thread Miquel Raynal
Sync the Kconfig raw NAND entry title with the code architecture.

Signed-off-by: Miquel Raynal 
---
 drivers/mtd/nand/raw/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mtd/nand/raw/Kconfig b/drivers/mtd/nand/raw/Kconfig
index bdc272142e..118fae7620 100644
--- a/drivers/mtd/nand/raw/Kconfig
+++ b/drivers/mtd/nand/raw/Kconfig
@@ -1,6 +1,6 @@
 
 menuconfig NAND
-   bool "NAND Device Support"
+   bool "Raw NAND Device Support"
 if NAND
 
 config SYS_NAND_SELF_INIT
-- 
2.14.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v3 05/21] mtd: add get/set of_node/flash_node helpers

2018-07-12 Thread Miquel Raynal
From: Brian Norris 

We are going to begin using the mtd->dev.of_node field for MTD device
nodes, so let's add helpers for it. Also, we'll be making some
conversions on spi_nor (and nand_chip eventually) too, so get that ready
with their own helpers.

Signed-off-by: Brian Norris 
Reviewed-by: Boris Brezillon 
Signed-off-by: Miquel Raynal 
Reviewed-by: Jagan Teki 
---
 include/linux/mtd/mtd.h | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/include/linux/mtd/mtd.h b/include/linux/mtd/mtd.h
index 0876897c51..78eb745c04 100644
--- a/include/linux/mtd/mtd.h
+++ b/include/linux/mtd/mtd.h
@@ -310,6 +310,17 @@ struct mtd_info {
int usecount;
 };
 
+static inline void mtd_set_of_node(struct mtd_info *mtd,
+  const struct device_node *np)
+{
+   mtd->dev->node.np = np;
+}
+
+static inline const struct device_node *mtd_get_of_node(struct mtd_info *mtd)
+{
+   return mtd->dev->node.np;
+}
+
 int mtd_ooblayout_ecc(struct mtd_info *mtd, int section,
  struct mtd_oob_region *oobecc);
 int mtd_ooblayout_find_eccregion(struct mtd_info *mtd, int eccbyte,
-- 
2.14.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v3 02/21] mtd: Uninline mtd_write_oob and move it to mtdcore.c

2018-07-12 Thread Miquel Raynal
From: Ezequiel Garcia 

There's no reason for having mtd_write_oob inlined in mtd.h header.
Move it to mtdcore.c where it belongs.

Signed-off-by: Ezequiel Garcia 
Acked-by: Boris Brezillon 
Signed-off-by: Jacek Anaszewski 
Signed-off-by: Miquel Raynal 
---
 drivers/mtd/mtdcore.c   | 12 
 include/linux/mtd/mtd.h | 12 +---
 2 files changed, 13 insertions(+), 11 deletions(-)

diff --git a/drivers/mtd/mtdcore.c b/drivers/mtd/mtdcore.c
index 60ad28efd4..ad61406dac 100644
--- a/drivers/mtd/mtdcore.c
+++ b/drivers/mtd/mtdcore.c
@@ -1031,6 +1031,18 @@ int mtd_read_oob(struct mtd_info *mtd, loff_t from, 
struct mtd_oob_ops *ops)
 }
 EXPORT_SYMBOL_GPL(mtd_read_oob);
 
+int mtd_write_oob(struct mtd_info *mtd, loff_t to,
+   struct mtd_oob_ops *ops)
+{
+   ops->retlen = ops->oobretlen = 0;
+   if (!mtd->_write_oob)
+   return -EOPNOTSUPP;
+   if (!(mtd->flags & MTD_WRITEABLE))
+   return -EROFS;
+   return mtd->_write_oob(mtd, to, ops);
+}
+EXPORT_SYMBOL_GPL(mtd_write_oob);
+
 /**
  * mtd_ooblayout_ecc - Get the OOB region definition of a specific ECC section
  * @mtd: MTD device structure
diff --git a/include/linux/mtd/mtd.h b/include/linux/mtd/mtd.h
index 0c41140465..0876897c51 100644
--- a/include/linux/mtd/mtd.h
+++ b/include/linux/mtd/mtd.h
@@ -355,17 +355,7 @@ int mtd_panic_write(struct mtd_info *mtd, loff_t to, 
size_t len, size_t *retlen,
const u_char *buf);
 
 int mtd_read_oob(struct mtd_info *mtd, loff_t from, struct mtd_oob_ops *ops);
-
-static inline int mtd_write_oob(struct mtd_info *mtd, loff_t to,
-   struct mtd_oob_ops *ops)
-{
-   ops->retlen = ops->oobretlen = 0;
-   if (!mtd->_write_oob)
-   return -EOPNOTSUPP;
-   if (!(mtd->flags & MTD_WRITEABLE))
-   return -EROFS;
-   return mtd->_write_oob(mtd, to, ops);
-}
+int mtd_write_oob(struct mtd_info *mtd, loff_t to, struct mtd_oob_ops *ops);
 
 int mtd_get_fact_prot_info(struct mtd_info *mtd, size_t len, size_t *retlen,
   struct otp_info *buf);
-- 
2.14.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v3 03/21] mtd: Add sanity checks in mtd_write/read_oob()

2018-07-12 Thread Miquel Raynal
From: Boris Brezillon 

Unlike what's done in mtd_read/write(), there are no checks to make sure
the parameters passed to mtd_read/write_oob() are consistent, which
forces implementers of ->_read/write_oob() to do it, which in turn leads
to code duplication and possibly errors in the logic.

Do general sanity checks, like ops fields consistency and range checking.

Signed-off-by: Boris Brezillon 
Cc: Peter Pan 
Signed-off-by: Richard Weinberger 
[Miquel: squashed the fix about the chip's size check]
Signed-off-by: Miquel Raynal 
---
 drivers/mtd/mtdcore.c | 45 +
 1 file changed, 45 insertions(+)

diff --git a/drivers/mtd/mtdcore.c b/drivers/mtd/mtdcore.c
index ad61406dac..9a3efe95df 100644
--- a/drivers/mtd/mtdcore.c
+++ b/drivers/mtd/mtdcore.c
@@ -1010,12 +1010,50 @@ int mtd_panic_write(struct mtd_info *mtd, loff_t to, 
size_t len, size_t *retlen,
 }
 EXPORT_SYMBOL_GPL(mtd_panic_write);
 
+static int mtd_check_oob_ops(struct mtd_info *mtd, loff_t offs,
+struct mtd_oob_ops *ops)
+{
+   /*
+* Some users are setting ->datbuf or ->oobbuf to NULL, but are leaving
+* ->len or ->ooblen uninitialized. Force ->len and ->ooblen to 0 in
+*  this case.
+*/
+   if (!ops->datbuf)
+   ops->len = 0;
+
+   if (!ops->oobbuf)
+   ops->ooblen = 0;
+
+   if (offs < 0 || offs + ops->len > mtd->size)
+   return -EINVAL;
+
+   if (ops->ooblen) {
+   u64 maxooblen;
+
+   if (ops->ooboffs >= mtd_oobavail(mtd, ops))
+   return -EINVAL;
+
+   maxooblen = ((mtd_div_by_ws(mtd->size, mtd) -
+ mtd_div_by_ws(offs, mtd)) *
+mtd_oobavail(mtd, ops)) - ops->ooboffs;
+   if (ops->ooblen > maxooblen)
+   return -EINVAL;
+   }
+
+   return 0;
+}
+
 int mtd_read_oob(struct mtd_info *mtd, loff_t from, struct mtd_oob_ops *ops)
 {
int ret_code;
ops->retlen = ops->oobretlen = 0;
if (!mtd->_read_oob)
return -EOPNOTSUPP;
+
+   ret_code = mtd_check_oob_ops(mtd, from, ops);
+   if (ret_code)
+   return ret_code;
+
/*
 * In cases where ops->datbuf != NULL, mtd->_read_oob() has semantics
 * similar to mtd->_read(), returning a non-negative integer
@@ -1034,11 +1072,18 @@ EXPORT_SYMBOL_GPL(mtd_read_oob);
 int mtd_write_oob(struct mtd_info *mtd, loff_t to,
struct mtd_oob_ops *ops)
 {
+   int ret;
+
ops->retlen = ops->oobretlen = 0;
if (!mtd->_write_oob)
return -EOPNOTSUPP;
if (!(mtd->flags & MTD_WRITEABLE))
return -EROFS;
+
+   ret = mtd_check_oob_ops(mtd, to, ops);
+   if (ret)
+   return ret;
+
return mtd->_write_oob(mtd, to, ops);
 }
 EXPORT_SYMBOL_GPL(mtd_write_oob);
-- 
2.14.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v3 01/21] mtd: Fallback to ->_read/write_oob() when ->_read/write() is missing

2018-07-12 Thread Miquel Raynal
From: Boris Brezillon 

Some MTD sublayers/drivers are implementing ->_read/write_oob() and
provide dummy wrappers for their ->_read/write() implementations.
Let the core handle this case instead of duplicating the logic.

Signed-off-by: Boris Brezillon 
Acked-by: Robert Jarzmik 
Acked-by: Brian Norris 
Reviewed-by: Miquel Raynal 
Tested-by: Ladislav Michl 
Signed-off-by: Miquel Raynal 
Reviewed-by: Jagan Teki 
---
 drivers/mtd/mtdcore.c  | 31 ++--
 drivers/mtd/mtdpart.c  |  6 ++--
 drivers/mtd/nand/nand_base.c   | 56 ---
 drivers/mtd/onenand/onenand_base.c | 60 --
 4 files changed, 33 insertions(+), 120 deletions(-)

diff --git a/drivers/mtd/mtdcore.c b/drivers/mtd/mtdcore.c
index 6217be2352..60ad28efd4 100644
--- a/drivers/mtd/mtdcore.c
+++ b/drivers/mtd/mtdcore.c
@@ -937,7 +937,20 @@ int mtd_read(struct mtd_info *mtd, loff_t from, size_t 
len, size_t *retlen,
 * representing the maximum number of bitflips that were corrected on
 * any one ecc region (if applicable; zero otherwise).
 */
-   ret_code = mtd->_read(mtd, from, len, retlen, buf);
+   if (mtd->_read) {
+   ret_code = mtd->_read(mtd, from, len, retlen, buf);
+   } else if (mtd->_read_oob) {
+   struct mtd_oob_ops ops = {
+   .len = len,
+   .datbuf = buf,
+   };
+
+   ret_code = mtd->_read_oob(mtd, from, );
+   *retlen = ops.retlen;
+   } else {
+   return -ENOTSUPP;
+   }
+
if (unlikely(ret_code < 0))
return ret_code;
if (mtd->ecc_strength == 0)
@@ -952,10 +965,24 @@ int mtd_write(struct mtd_info *mtd, loff_t to, size_t 
len, size_t *retlen,
*retlen = 0;
if (to < 0 || to > mtd->size || len > mtd->size - to)
return -EINVAL;
-   if (!mtd->_write || !(mtd->flags & MTD_WRITEABLE))
+   if ((!mtd->_write && !mtd->_write_oob) ||
+   !(mtd->flags & MTD_WRITEABLE))
return -EROFS;
if (!len)
return 0;
+
+   if (!mtd->_write) {
+   struct mtd_oob_ops ops = {
+   .len = len,
+   .datbuf = (u8 *)buf,
+   };
+   int ret;
+
+   ret = mtd->_write_oob(mtd, to, );
+   *retlen = ops.retlen;
+   return ret;
+   }
+
return mtd->_write(mtd, to, len, retlen, buf);
 }
 EXPORT_SYMBOL_GPL(mtd_write);
diff --git a/drivers/mtd/mtdpart.c b/drivers/mtd/mtdpart.c
index f87c962205..7c756ad8b1 100644
--- a/drivers/mtd/mtdpart.c
+++ b/drivers/mtd/mtdpart.c
@@ -417,8 +417,10 @@ static struct mtd_part *allocate_partition(struct mtd_info 
*master,
slave->mtd.dev.parent = master->dev.parent;
 #endif
 
-   slave->mtd._read = part_read;
-   slave->mtd._write = part_write;
+   if (parent->_read)
+   slave->mtd._read = part_read;
+   if (parent->_write)
+   slave->mtd._write = part_write;
 
if (master->_panic_write)
slave->mtd._panic_write = part_panic_write;
diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index 64e4621aaa..0b58e15b03 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -1863,33 +1863,6 @@ read_retry:
return max_bitflips;
 }
 
-/**
- * nand_read - [MTD Interface] MTD compatibility function for nand_do_read_ecc
- * @mtd: MTD device structure
- * @from: offset to read from
- * @len: number of bytes to read
- * @retlen: pointer to variable to store the number of read bytes
- * @buf: the databuffer to put data
- *
- * Get hold of the chip and call nand_do_read.
- */
-static int nand_read(struct mtd_info *mtd, loff_t from, size_t len,
-size_t *retlen, uint8_t *buf)
-{
-   struct mtd_oob_ops ops;
-   int ret;
-
-   nand_get_device(mtd, FL_READING);
-   memset(, 0, sizeof(ops));
-   ops.len = len;
-   ops.datbuf = buf;
-   ops.mode = MTD_OPS_PLACE_OOB;
-   ret = nand_do_read_ops(mtd, from, );
-   *retlen = ops.retlen;
-   nand_release_device(mtd);
-   return ret;
-}
-
 /**
  * nand_read_oob_std - [REPLACEABLE] the most common OOB data read function
  * @mtd: mtd info structure
@@ -2674,33 +2647,6 @@ static int panic_nand_write(struct mtd_info *mtd, loff_t 
to, size_t len,
return ret;
 }
 
-/**
- * nand_write - [MTD Interface] NAND write with ECC
- * @mtd: MTD device structure
- * @to: offset to write to
- * @len: number of bytes to write
- * @retlen: pointer to variable to store the number of written bytes
- * @buf: the data to write
- *
- * NAND write with ECC.
- */
-static int nand_write(struct mtd_info *mtd, loff_t to, size_t len,
- size_t *retlen, const uint8_t *buf)
-{
-   struct mtd_oob_ops ops;
-   int ret;
-
-   

[U-Boot] [PATCH v3 00/21] SPI-NAND support

2018-07-12 Thread Miquel Raynal
During the last months, Boris Brezillon shared his work to support
serial flashes within Linux. First, he delivered (and merged) a new
layer called spi-mem. He also initiated in Linux MTD subsystem the move
of all 'raw' NAND related code to a raw/ subdirectory, adding at the
same time a NAND core that would be shared with all NAND devices. Then,
he contributed a generic SPI-NAND driver, making use of this NAND core,
as well as some vendor code to drive a few chips.

On top of this work, I added an 'mtd' U-Boot command to handle all sort
of MTD devices. This should become the default command instead of having
one per flash flavor ('sf', 'nand', 'spi-nand' ?).

The series has been tested on an Ocelot board PCB123 (VSC7514),
featuring a Macronix SPI NAND chip.

TL;DR: the series contains:
- A few patches from Linux to resynchronize some areas of the MTD layer.
- Various fixes and re-organization of the MTD subsystem.
- The introduction of the SPI-mem interface.
- The addition of the generic SPI-NAND driver (and its bindings).
- Several SPI NAND chip drivers (Macronix, Micron, Winbond).
- A new 'mtd' command.

Any comments on the code, the organization and the respect of U-Boot
driver model will be welcome.

Thanks,
Miquèl

Changes since v2:
-
* Rebased on u-boot master branch.
* Removed extra-parenthesis in
  "mtd: Fallback to ->_read/write() when ->_read/write_oob() is missing"
* s/fiels/files/ in "mtd: move NAND fiels into a raw/ subdirectory"
* Do not describe generic SPI device properties in SPI NAND bindings.
* Changes in the mtd command:
  * Printing more information in 'mtd list' (device type, device
characteristics)
  * Switch to do_div() instead of '(u32)value64b % value32b' which only
worked because value32b was a power of 2.
  * Removed erase.chip option.
  * By default, erase/read/write happen on the full MTD device while a
dump will only work on a single page.

Changes since v1:
-
* Fixed the nand_memorg structure of the MX35LF2GE4AB chip.
* Added Reviewed-by tags from Jagan.
* Backported and squashed two patches fixing things in the SPI NAND core
  received on the Linux ML.
* Backported more changes in mtdcore.c from Linux.
* Added a patch to add a fallback on mtd->_read/_write() in mtdcore.c
  when mtd->_read/write_oob() is not supported.
* Removed the DT changes, useless as the DTs are not available in
  mainline yet.
* Addressed Boris/Stefan comments on the 'mtd' command.
* Added support for multi-pages OOB read/write.


Boris Brezillon (7):
  mtd: Fallback to ->_read/write_oob() when ->_read/write() is missing
  mtd: Add sanity checks in mtd_write/read_oob()
  mtd: nand: Add core infrastructure to deal with NAND devices
  mtd: nand: Pass mode information to nand_page_io_req
  spi: Extend the core to ease integration of SPI memory controllers
  mtd: spinand: Add initial support for the MX35LF1GE4AB chip
  dt-bindings: Add bindings for SPI NAND devices

Brian Norris (1):
  mtd: add get/set of_node/flash_node helpers

Ezequiel Garcia (1):
  mtd: Uninline mtd_write_oob and move it to mtdcore.c

Frieder Schrempf (1):
  mtd: spinand: Add initial support for Winbond W25M02GV

Miquel Raynal (9):
  mtd: Fallback to ->_read/write() when ->_read/write_oob() is missing
  mtd: fix build issue with includes
  mtd: move definitions to enlarge their range
  mtd: move all flash categories inside MTD submenu
  mtd: move NAND files into a raw/ subdirectory
  mtd: rename nand into rawnand in Kconfig prompt
  mtd: spinand: Add initial support for the MX35LF2GE4AB chip
  mtd: uclass: add probe function
  cmd: mtd: add 'mtd' command

Peter Pan (2):
  mtd: nand: Add core infrastructure to support SPI NANDs
  mtd: spinand: Add initial support for Micron MT29F2G01ABAGD

 cmd/Kconfig   |5 +
 cmd/Makefile  |1 +
 cmd/mtd.c |  334 +++
 doc/device-tree-bindings/mtd/spi-nand.txt |5 +
 drivers/mtd/Kconfig   |4 +-
 drivers/mtd/Makefile  |4 +-
 drivers/mtd/mtd-uclass.c  |9 +
 drivers/mtd/mtdcore.c |  106 ++-
 drivers/mtd/mtdcore.h |6 -
 drivers/mtd/mtdpart.c |6 +-
 drivers/mtd/nand/Kconfig  |  281 +-
 drivers/mtd/nand/Makefile |   79 +-
 drivers/mtd/nand/bbt.c|  132 +++
 drivers/mtd/nand/core.c   |  243 +
 drivers/mtd/nand/raw/Kconfig  |  279 ++
 drivers/mtd/nand/raw/Makefile |   77 ++
 drivers/mtd/nand/{ => raw}/am335x_spl_bch.c   |0
 drivers/mtd/nand/{ => raw}/arasan_nfc.c   |0
 drivers/mtd/nand/{ => raw}/atmel_nand.c   |0
 drivers/mtd/nand/{ => raw}/atmel_nand_ecc.h   |0
 drivers/mtd/nand/{ => raw}/davinci_nand.c |0
 drivers/mtd/nand/{ => 

Re: [U-Boot] [PATCH v2 20/21] cmd: mtd: add 'mtd' command

2018-07-12 Thread Miquel Raynal
Hi Boris,

> > > +
> > > + if (full_erase) {
> > > + off = 0;
> > > + len = mtd->size;
> > > + }
> > > +
> > > + if ((u32)off % mtd->erasesize) {
> > 
> > Sounds dangerous. We have 8GB NANDs on sunxi platforms...  
> 
> [...]
> 
> > > +
> > > + if ((u32)len % mtd->erasesize) {
> > 
> > Same here. I guess there's a do_div() in uboot.  
> 
> In both cases I take the less significant bytes of a 64-bit value. The
> modulo operation is safe as long as mtd->erasesize is a 32-bit value
> too. I don't think there is any danger?

As discussed out of this thread, this works because mtd->erasesize is
always a power of 2. Erase sizes not being a power of 2 do not exist
but it will be safer to switch to do_div().

Thanks,
Miquèl
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 1/1] avb2.0: add proper dependencies to libavb

2018-07-12 Thread Igor Opaniuk
Hi Eugeniu,

Makes sense, will re-send this patch soon with changes based on your
suggestions. Thanks

Regards,
Igor

On 12 July 2018 at 12:27, Eugeniu Rosca  wrote:
> Hi Igor,
>
> Thanks for the fix. See my comments below.
>
> On Thu, Jul 12, 2018 at 10:34:24AM +0300, Igor Opaniuk wrote:
>> Provide proper dependencies for LIBAVB: (FASTBOOT and !BLK):
>> 1. CONFIG_FASTBOOT is needed, as fastboot buffer is re-used (which
>> is initially used in the fastboot protocol for downloads)
>> 2. !CONFIG_BLK, as current implementation currently
>> doesn't support non-legacy block API.
>>
>> Reported-by: Eugeniu Rosca 
>> Signed-off-by: Igor Opaniuk 
>> ---
>>  lib/Kconfig | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/lib/Kconfig b/lib/Kconfig
>> index a77bf1c..4780e7e 100644
>> --- a/lib/Kconfig
>> +++ b/lib/Kconfig
>> @@ -191,7 +191,7 @@ menu "Android Verified Boot"
>>
>>  config LIBAVB
>>   bool "Android Verified Boot 2.0 support"
>> - depends on ANDROID_BOOT_IMAGE
>> + depends on ANDROID_BOOT_IMAGE && FASTBOOT && !BLK
>
> Since libavb library alone is highly portable (it compiles fine with
> several compilers), I'm not sure if's the best choice to make it
> dependent on FASTBOOT (obviously it is not dependent on it). The
> dependency is rather introduced by commit 3af30e4443aa ("avb2.0:
> implement AVB ops"), which re-uses CONFIG_LIBAVB Kconfig symbol to wire
> common/avb_verify.c to Kbuild.
>
> So, unless you have some counter-proposal, I vote for adding a new
> Kconfig symbol for common/avb_verify.c, which then can be marked as
> dependent on FASTBOOT. This will also keep the hopes alive about
> testing libavb on sandbox.
>
> Thanks,
> Eugeniu.



-- 
Regards,
Igor Opaniuk
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH] mtd: nand: denali: Replace the ad-hoc cache management with bouncebuf

2018-07-12 Thread Marek Vasut
On 06/20/2018 09:14 AM, Masahiro Yamada wrote:
> Hi Marek,

Hi!

> 2018-06-20 13:43 GMT+09:00 Marek Vasut :
>> On 06/19/2018 08:39 AM, Masahiro Yamada wrote:
>>> Hi Marek,
>>
>> Hi,
>>
>>> 2018-06-08 5:17 GMT+09:00 Marek Vasut :
 Replace the ad-hoc DMA cache management functions with common bouncebuf,
 since those functions are not handling cases where unaligned buffer is
 passed in,
>>>
>>>
>>> Were you hit by a problem,
>>> or just-in-case replacement?
>>
>> Yes, UBI triggers unaligned cache operations on my system (SoCFPGA).
>>> I thought I took care of the buffer alignment.
>>>
>>> The bounce buffer is allocated by kmalloc():
>>> https://github.com/u-boot/u-boot/blob/v2018.05/drivers/mtd/nand/denali.c#L1348
>>>
>>> According to the lib/linux_compat.c implementation,
>>> it returns memory aligned with ARCH_DMA_MINALIGN.
>>>
>>>
>>> If the buffer is passed from the upper MTD layer,
>>> the NAND core also makes sure the enough alignment:
>>> https://github.com/u-boot/u-boot/blob/v2018.05/drivers/mtd/nand/denali.c#L1273
>>>
>>> This is how this driver works in Linux.
>>>
>>> I'd rather want to keep the current code
>>> unless this is a real problem,
>>>
>>>
>>> One possible clean-up is to move dma_(un)map_single to a common place.
>> Is there any chance you can try UBI on the denali nand on uniphier ? :)
> 
> 
> I tested the driver only for raw block devices.
> 
> OK, I will test UBI on my platform.
> 
> BTW, do you see the problem only in U-Boot?
> Is the denali driver in Linux working fine?

Bump on this one ?

-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v2 20/21] cmd: mtd: add 'mtd' command

2018-07-12 Thread Miquel Raynal
Hi Boris,

Boris Brezillon  wrote on Thu, 12 Jul 2018
00:42:13 +0200:

> On Wed, 11 Jul 2018 17:25:28 +0200
> Miquel Raynal  wrote:
> 
> > +
> > +static void mtd_show_device(struct mtd_info *mtd)
> > +{
> > +   printf("* %s", mtd->name);  
> 
> Printing the device type might be interesting? And maybe also the size,
> writesize, oobsize and erasesize?

Absolutely.

> 
> > +   if (mtd->dev)
> > +   printf(" [device: %s] [parent: %s] [driver: %s]",
> > +  mtd->dev->name, mtd->dev->parent->name,
> > +  mtd->dev->driver->name);
> > +
> > +   printf("\n");
> > +}  

[...]

> > +   } else if (!strcmp(cmd, "erase")) {
> > +   bool scrub = strstr(cmd, ".dontskipbad");
> > +   bool full_erase = strstr(cmd, ".chip");  
> 
> Again, I think .chip extension is not needed. Just consider a full erase
> is requested when offset and length are not provided. Plus, chip is
> misleading since I guess mtd partitions are also exposed as mtd devices,
> and could thus be erased with the .chip extension as well.

".chip" removed.

Default now is mtd->size (the entire MTD device) for erase/read/write,
and mtd->writesize (a page) for a dump.

> 
> > +   struct erase_info erase_op = {};
> > +   u64 off, len;
> > +
> > +   off = argc > 0 ? simple_strtoul(argv[0], NULL, 16) : 0;
> > +   len = argc > 1 ? simple_strtoul(argv[1], NULL, 16) : 
> > mtd->erasesize;  
> 
> Hm. Are we sure we want the default to be 1 eraseblock? Shouldn't we
> consider that missing size means "erase up to the MTD device end". Same
> goes for the read/write accesses, but maybe not for dump where dumping
> a single page makes more sense.

See above.

> 
> > +
> > +   if (full_erase) {
> > +   off = 0;
> > +   len = mtd->size;
> > +   }
> > +
> > +   if ((u32)off % mtd->erasesize) {  
> 
> Sounds dangerous. We have 8GB NANDs on sunxi platforms...

[...]

> > +
> > +   if ((u32)len % mtd->erasesize) {  
> 
> Same here. I guess there's a do_div() in uboot.

In both cases I take the less significant bytes of a 64-bit value. The
modulo operation is safe as long as mtd->erasesize is a 32-bit value
too. I don't think there is any danger?

[...]

Thanks,
Miquèl
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [RFC PATCH v2] u-boot: remove driver lookup loop from env_save()

2018-07-12 Thread Nicholas
On gio, 2018-07-12 at 13:02 +0200, Simon Goldschmidt wrote:
> 
> On 12.07.2018 12:52, Nicholas Faustini wrote:
> > 
> > When called with ENVOP_SAVE, env_get_location() only returns the
> > gd->env_load_location variable without actually checking for
> > the environment location and priority.
> > 
> > This behaviour causes env_save() to fall into an infinite loop when
> > the low-level drv->save() call fails.
> > 
> > The env_save() function should not loop through the environment
> > location list but it should save the environment into the location
> > stored in gd->env_load_location by the last env_load() call.
> > 
> > Signed-off-by: Nicholas Faustini 
> > ---
> > 
> > Changes in v2:
> > - Restore gd->env_load_location to the highest priority location
> > when
> >    env_load() fails
> > 
> >   env/env.c | 10 ++
> >   1 file changed, 6 insertions(+), 4 deletions(-)
> > 
> > diff --git a/env/env.c b/env/env.c
> > index 5c0842a..18eb78d 100644
> > --- a/env/env.c
> > +++ b/env/env.c
> > @@ -205,22 +205,24 @@ int env_load(void)
> >     return 0;
> >     }
> >   
> > +   env_get_location(ENVOP_LOAD, 0);
> A comment why this is required would be good, I guess.
Sure, I thought the same but eventually I didn't put it. Will do in the
next version.
> 
> > 
> > +
> >     return -ENODEV;
> >   }
> >   
> >   int env_save(void)
> >   {
> >     struct env_driver *drv;
> > -   int prio;
> >   
> > -   for (prio = 0; (drv = env_driver_lookup(ENVOP_SAVE,
> > prio)); prio++) {
> > +   drv = env_driver_lookup(ENVOP_SAVE, 0);
> Thinking again about this, would it make more sense to store 
> 'env_load_prio' in 'gd' after successful load? That way, 
> 'env_get_location()' would be more straightforward (no special case
> for 
> ENVOP_SAVE) and here in 'env_save()' we could just write something
> like 
> this:
> 
> drv = env_driver_lookup(ENVOP_SAVE, gd->env_load_prio);
> 
> 
I really like the 'env_load_prio' idea. But I also like having the
special case for ENVOP_SAVE in env_get_location() as it enforces the
fact that the location of 'save' is bound to the location of previous
'load'.
I however don't have a strong opinion on this. I could even remove the
whole switch() statement if we introduce 'env_load_prio'.

Also, I have some doubts about what it should be returned when !drv-
>save and !env_has_inited(drv->location) (below)... I put -ENODEV but I
don't like it so much.

> Simon
> 
> > 
> > +   if (drv) {
> >     int ret;
> >   
> >     if (!drv->save)
> > -   continue;
> > +   return -ENODEV;
> >   
> >     if (!env_has_inited(drv->location))
> > -   continue;
> > +   return -ENODEV;
> >   
> >     printf("Saving Environment to %s... ", drv-
> > >name);
> >     ret = drv->save();
> > 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v2 21/21] dt-bindings: Add bindings for SPI NAND devices

2018-07-12 Thread Miquel Raynal
Hi Boris,

Boris Brezillon  wrote on Thu, 12 Jul 2018
00:44:44 +0200:

> On Wed, 11 Jul 2018 17:25:29 +0200
> Miquel Raynal  wrote:
> 
> > From: Boris Brezillon 
> > 
> > Add bindings for SPI NAND chips.
> > 
> > Signed-off-by: Boris Brezillon 
> > Signed-off-by: Miquel Raynal 
> > ---
> >  doc/device-tree-bindings/mtd/spi-nand.txt | 27 +++
> >  1 file changed, 27 insertions(+)
> >  create mode 100644 doc/device-tree-bindings/mtd/spi-nand.txt
> > 
> > diff --git a/doc/device-tree-bindings/mtd/spi-nand.txt 
> > b/doc/device-tree-bindings/mtd/spi-nand.txt
> > new file mode 100644
> > index 00..d55f80196c
> > --- /dev/null
> > +++ b/doc/device-tree-bindings/mtd/spi-nand.txt
> > @@ -0,0 +1,27 @@
> > +SPI NAND flash
> > +
> > +Required properties:
> > +- compatible: should be "spi-nand"
> > +- reg: should encode the chip-select line used to access the NAND chip
> > +
> > +Optional properties
> > +- spi-max-frequency: maximum frequency of the SPI bus the chip can operate 
> > at.
> > +This should encode board limitations (i.e. max freq can't
> > +be achieved due to crosstalk on IO lines).
> > +When unspecified, the driver assumes the chip can run at
> > +the max frequency defined in the spec (information
> > +extracted chip detection time).
> > +- spi-tx-bus-width: The bus width (number of data wires) that is used for 
> > MOSI.
> > +   Only encodes the board constraints (i.e. when not all IO
> > +   signals are routed on the board). Device constraints are
> > +   extracted when detecting the chip, and controller
> > +   constraints are exposed by the SPI mem controller. If this
> > +   property is missing that means no constraint at the board
> > +   level.
> > +- spi-rx-bus-width: The bus width (number of data wires) that is used for 
> > MISO.
> > +   Only encodes the board constraints (i.e. when not all IO
> > +   signals are routed on the board). Device constraints are
> > +   extracted when detecting the chip, and controller
> > +   constraints are exposed by the SPI mem controller. If this
> > +   property is missing that means no constraint at the board
> > +   level.  
> 
> This section has been dropped from the Linux doc.

Removed.

Thanks,
Miquèl
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] UBI fixable bit-flip issue

2018-07-12 Thread Mark Spieth


On 12 July 2018 18:46:11 GMT+10:00, Richard Weinberger  wrote:
>Mark,
>
>Am Donnerstag, 12. Juli 2018, 07:22:13 CEST schrieb Heiko Schocher:
>> Hello Mark,
>> 
>> added Richard Weinberger to cc...
>> 
>> Am 12.07.2018 um 02:28 schrieb Mark Spieth:
>> > Hi
>> > 
>> > In the process of investigating a boot failure on one of our
>devices, the
>> > 
>> > UBI: fixable bit-flip detected at PEB
>> > 
>> > message was seen with the following behaviour during kernel load in
>u-boot.
>> > 
>> > Read [2285568] bytes
>> > UBI: fixable bit-flip detected at PEB 415
>> > UBI: schedule PEB 415 for scrubbing
>> > UBI: fixable bit-flip detected at PEB 415
>> > UBI: fixable bit-flip detected at PEB 419
>> > UBI: schedule PEB 419 for scrubbing
>> > UBI: fixable bit-flip detected at PEB 419
>> > UBI: fixable bit-flip detected at PEB 420
>> > UBI: schedule PEB 420 for scrubbing
>> > UBI: fixable bit-flip detected at PEB 420
>> > UBI: fixable bit-flip detected at PEB 419
>> > UBI: fixable bit-flip detected at PEB 420
>> > UBI: fixable bit-flip detected at PEB 419
>> > UBI: fixable bit-flip detected at PEB 420
>> > UBI: fixable bit-flip detected at PEB 419
>> > UBI: fixable bit-flip detected at PEB 420
>> > UBI: fixable bit-flip detected at PEB 419
>> > UBI: fixable bit-flip detected at PEB 420
>> > UBI: fixable bit-flip detected at PEB 419
>> > UBI: fixable bit-flip detected at PEB 420
>> > UBI: fixable bit-flip detected at PEB 419
>> > 
>> > This repeats until reset.
>
>Do you see the same symptom also on Linux?
>We need to be very sure that it is actually a UBI problem.

The linux provided has an up to date mtd/ubi driver so already has the 75% 
bitflip threshold thus hiding the issue in a new flash. So the 2 are not the 
same. Untested on linux.

>
>> > This fix is not a root cause fix though. Investigating further led
>to the following root cause 
>> > solution. The following is AFAICT.
>> > 
>> > When the scrubber chooses a PEB to move the from the free balanced
>tree. This tree is sorted by EC 
>> > (erase count) and then by PEB number.
>> > 
>> > The find_wl_entry call uses a max parameter of WL_FREE_MAX_DIFF
>which is 8192 in this config. So the 
>> > find_wl_entry function will find a PEB that is better in error
>count that the current PEB EC. This
>
>error count? You mean erase count?

Yes of course.

> 
>> > can easily cause it to find the PEB that was just moved from if it
>is the lowest numbered PEB in the 
>> > free tree. Waiting for EC to go above 8192 would take a long time
>and cause premature aging of the 
>> > flash PEBs in question.
>> > 
>> > The easy solution is to change the max parameter to this call to 0
>so it finds a PEB with a smaller 
>> > EC than the one being replaced. This means it wont use the
>previously discarded PEB as its first 
>> > choice.
>
>For scrubbing this might be a good idea, but not for regular
>wear-leveling.
Yes only for scrubbing, not wear leveling.
>
>See comment in UBI:
>/*
>* When a physical eraseblock is moved, the WL sub-system has to pick
>the target
>* physical eraseblock to move to. The simplest way would be just to
>pick the
>* one with the highest erase counter. But in certain workloads this
>could lead
>* to an unlimited wear of one or few physical eraseblock. Indeed,
>imagine a
>* situation when the picked physical eraseblock is constantly erased
>after the
>* data is written to it. So, we have a constant which limits the
>highest erase
>* counter of the free physical eraseblock to pick. Namely, the WL
>sub-system
>* does not pick eraseblocks with erase counter greater than the lowest
>erase
> * counter plus %WL_FREE_MAX_DIFF.
> */
>#define WL_FREE_MAX_DIFF (2*UBI_WL_THRESHOLD)
>
>So we could change the logic such that for regular wear-leveling we
>keep using WL_FREE_MAX_DIFF,
>but for scrubbing (which is 1:1 wear-leveling but the source PEB is
>showing bit-flips) we use
>a lower value. IMHO WL_FREE_MAX_DIFF/2 would be a good choice.
>I'm not sure whether 0 is too extreme and might cause other
>distortions.

Yes the wear leveling threshold is still WL_FREE_MAX_DIFF and the scubbing 
threshold is 0.

This is why I'm asking. Because the 2 PEBs will track each others EC I'm not 
sure that will work. 

>
>Mark, can you please file a patch and send it to linux-mtd mailing
>list?
>Such a change needs to go through Linux and then to u-boot.
>But first we need to think about and discuss it in detail.

Will do.

> 
>>   I am not sure if it is so easy ...
>>
>> > This fix was implemented and fixable bit-flip errors no longer
>hang/freeze the boot process! UBI 
>> > erase and reformat was used between re-tests to get consistent
>results.
>> > 
>> > Adding the above 75% correctable bitflip threshold is also a good
>thing as less movement will ensue 
>> > when the FLASH is new, but as the flash ages, the root cause will
>once again be invoked causing 
>> > un-recoverable boot failures.
>> > 
>> > Note this fault is also in the latest kernel drivers for UBI and
>may also exist 

Re: [U-Boot] cmd: Kconfig: Move CONFIG_MP to Kconfig

2018-07-12 Thread Michal Simek
Hi Tom,

On 11.7.2018 14:42, Tom Rini wrote:
> On Tue, Jun 19, 2018 at 12:24:23PM +0200, Michal Simek wrote:
> 
>> From: Siva Durga Prasad Paladugu 
>>
>> This patch moves CONFIG_MP to Kconfig
>>
>> Signed-off-by: Siva Durga Prasad Paladugu 
>> Signed-off-by: Michal Simek 
> 
> Applied to u-boot/master, thanks!
> 

FYI: There was v2 of that patch
https://lists.denx.de/pipermail/u-boot/2018-June/332802.html
but I will send that changes separately because only zynqmp defconfig
are affected.

Thanks,
Michal

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP SoCs




signature.asc
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH] gpio: zynq: Read of mach data in platdata with dev_get_driver_data

2018-07-12 Thread Michal Simek
Remove bogus zynq_gpio_getplat_data() and read driver data directly.

Signed-off-by: Michal Simek 
---

Driver should use platdata structure but this change should be fine
before this is fixed.
Simon: Is ofdata_to_platdata correct function where this should be read?

---
 drivers/gpio/zynq_gpio.c | 29 ++---
 1 file changed, 2 insertions(+), 27 deletions(-)

diff --git a/drivers/gpio/zynq_gpio.c b/drivers/gpio/zynq_gpio.c
index 9a915544784d..26f69b1a713f 100644
--- a/drivers/gpio/zynq_gpio.c
+++ b/drivers/gpio/zynq_gpio.c
@@ -15,8 +15,6 @@
 #include 
 #include 
 
-DECLARE_GLOBAL_DATA_PTR;
-
 /* Maximum banks */
 #define ZYNQ_GPIO_MAX_BANK 4
 
@@ -334,36 +332,11 @@ static const struct udevice_id zynq_gpio_ids[] = {
{ }
 };
 
-static void zynq_gpio_getplat_data(struct udevice *dev)
-{
-   const struct udevice_id *of_match = zynq_gpio_ids;
-   int ret;
-   struct zynq_gpio_privdata *priv = dev_get_priv(dev);
-
-   while (of_match->compatible) {
-   ret = fdt_node_offset_by_compatible(gd->fdt_blob, -1,
-   of_match->compatible);
-   if (ret >= 0) {
-   priv->p_data =
-   (struct zynq_platform_data *)of_match->data;
-   break;
-   } else  {
-   of_match++;
-   continue;
-   }
-   }
-
-   if (!priv->p_data)
-   printf("No Platform data found\n");
-}
-
 static int zynq_gpio_probe(struct udevice *dev)
 {
struct zynq_gpio_privdata *priv = dev_get_priv(dev);
struct gpio_dev_priv *uc_priv = dev_get_uclass_priv(dev);
 
-   zynq_gpio_getplat_data(dev);
-
if (priv->p_data)
uc_priv->gpio_count = priv->p_data->ngpio;
 
@@ -376,6 +349,8 @@ static int zynq_gpio_ofdata_to_platdata(struct udevice *dev)
 
priv->base = (phys_addr_t)dev_read_addr(dev);
 
+   priv->p_data = (struct zynq_platform_data *)dev_get_driver_data(dev);
+
return 0;
 }
 
-- 
1.9.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH] gpio: dm: Support manual relocation for gpio

2018-07-12 Thread Michal Simek
Relocate gpio ops as was done by:
"dm: Add support for all targets which requires MANUAL_RELOC"
(sha1: 484fdf5ba058b07be5ca82763aa2b72063540ef3)

Signed-off-by: Michal Simek 
---

 drivers/gpio/gpio-uclass.c | 35 +++
 1 file changed, 35 insertions(+)

diff --git a/drivers/gpio/gpio-uclass.c b/drivers/gpio/gpio-uclass.c
index e9d08e2ebc25..da5e9ba6e524 100644
--- a/drivers/gpio/gpio-uclass.c
+++ b/drivers/gpio/gpio-uclass.c
@@ -854,11 +854,46 @@ static int gpio_pre_remove(struct udevice *dev)
return gpio_renumber(dev);
 }
 
+static int gpio_post_bind(struct udevice *dev)
+{
+#if defined(CONFIG_NEEDS_MANUAL_RELOC)
+   struct dm_gpio_ops *ops = (struct dm_gpio_ops *)device_get_ops(dev);
+   static int reloc_done;
+
+   if (!reloc_done) {
+   if (ops->request)
+   ops->request += gd->reloc_off;
+   if (ops->free)
+   ops->free += gd->reloc_off;
+   if (ops->direction_input)
+   ops->direction_input += gd->reloc_off;
+   if (ops->direction_output)
+   ops->direction_output += gd->reloc_off;
+   if (ops->get_value)
+   ops->get_value += gd->reloc_off;
+   if (ops->set_value)
+   ops->set_value += gd->reloc_off;
+   if (ops->get_open_drain)
+   ops->get_open_drain += gd->reloc_off;
+   if (ops->set_open_drain)
+   ops->set_open_drain += gd->reloc_off;
+   if (ops->get_function)
+   ops->get_function += gd->reloc_off;
+   if (ops->xlate)
+   ops->xlate += gd->reloc_off;
+
+   reloc_done++;
+   }
+#endif
+   return 0;
+}
+
 UCLASS_DRIVER(gpio) = {
.id = UCLASS_GPIO,
.name   = "gpio",
.flags  = DM_UC_FLAG_SEQ_ALIAS,
.post_probe = gpio_post_probe,
+   .post_bind  = gpio_post_bind,
.pre_remove = gpio_pre_remove,
.per_device_auto_alloc_size = sizeof(struct gpio_dev_priv),
 };
-- 
1.9.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH] sysreset: dm: Support manual relocation for sysreset

2018-07-12 Thread Michal Simek
Relocate sysreset ops as was done by:
"dm: Add support for all targets which requires MANUAL_RELOC"
(sha1: 484fdf5ba058b07be5ca82763aa2b72063540ef3)

Signed-off-by: Michal Simek 
---

 drivers/sysreset/sysreset-uclass.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/drivers/sysreset/sysreset-uclass.c 
b/drivers/sysreset/sysreset-uclass.c
index 7e06c3c90a71..840eab6b5703 100644
--- a/drivers/sysreset/sysreset-uclass.c
+++ b/drivers/sysreset/sysreset-uclass.c
@@ -74,7 +74,23 @@ int do_reset(cmd_tbl_t *cmdtp, int flag, int argc, char * 
const argv[])
return 0;
 }
 
+static int sysreset_post_bind(struct udevice *dev)
+{
+#if defined(CONFIG_NEEDS_MANUAL_RELOC)
+   struct sysreset_ops *ops = sysreset_get_ops(dev);
+   static int reloc_done;
+
+   if (!reloc_done) {
+   if (ops->request)
+   ops->request += gd->reloc_off;
+   reloc_done++;
+   }
+#endif
+   return 0;
+}
+
 UCLASS_DRIVER(sysreset) = {
.id = UCLASS_SYSRESET,
.name   = "sysreset",
+   .post_bind  = sysreset_post_bind,
 };
-- 
1.9.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v3 1/4] lib: fdtdec: Add new variable ram_start to global data

2018-07-12 Thread Michal Simek
On 12.7.2018 09:20, Marek Vasut wrote:
> On 06/25/2018 02:56 PM, Tom Rini wrote:
>> On Mon, Jun 25, 2018 at 08:15:34AM +0200, Michal Simek wrote:
>>> Hi,
>>>
>>> On 22.6.2018 21:28, Simon Glass wrote:
 Hi,

 On 22 June 2018 at 01:41, Michal Simek  wrote:
> Hi Simon,
>
> On 18.6.2018 08:18, Siva Durga Prasad Paladugu wrote:
>> Added new variable ram_start to global data structure for holding
>> the start address of first bank of RAM, and then use this ram_start
>> for calculating ram_top properly. This patch fixes the erroneous
>> calculation of ram_top incase of non zero ram start address.
>> This patch also renames fdtdec_setup_memory_size() to
>> fdtdec_setup_mem_size_start() as this routine now takes care
>> of memory size and start.
>>
>> Signed-off-by: Siva Durga Prasad Paladugu 
>> 
>> Signed-off-by: Michal Simek 
>> ---
>> Changes from v2:
>> - Used new varibale ram_start
>> - Rename fdtdec_setup_memory_size
>>
>> Changes from v1:
>> - None
>> ---
>>  arch/arm/mach-mvebu/arm64-common.c   |  2 +-
>>  board/emulation/qemu-arm/qemu-arm.c  |  2 +-
>>  board/renesas/alt/alt.c  |  2 +-
>>  board/renesas/blanche/blanche.c  |  2 +-
>>  board/renesas/draak/draak.c  |  2 +-
>>  board/renesas/eagle/eagle.c  |  2 +-
>>  board/renesas/gose/gose.c|  2 +-
>>  board/renesas/koelsch/koelsch.c  |  2 +-
>>  board/renesas/lager/lager.c  |  2 +-
>>  board/renesas/porter/porter.c|  2 +-
>>  board/renesas/salvator-x/salvator-x.c|  2 +-
>>  board/renesas/silk/silk.c|  2 +-
>>  board/renesas/stout/stout.c  |  2 +-
>>  board/renesas/ulcb/ulcb.c|  2 +-
>>  board/st/stm32f429-discovery/stm32f429-discovery.c   |  2 +-
>>  board/st/stm32f429-evaluation/stm32f429-evaluation.c |  2 +-
>>  board/st/stm32f469-discovery/stm32f469-discovery.c   |  2 +-
>>  board/st/stm32h743-disco/stm32h743-disco.c   |  2 +-
>>  board/st/stm32h743-eval/stm32h743-eval.c |  2 +-
>>  board/xilinx/zynq/board.c|  2 +-
>>  board/xilinx/zynqmp/zynqmp.c |  2 +-
>>  board/xilinx/zynqmp_r5/board.c   |  2 +-
>>  common/board_f.c |  4 ++--
>>  include/asm-generic/global_data.h|  1 +
>>  include/fdtdec.h | 16 
>> +---
>>  lib/fdtdec.c |  3 ++-
>>  tools/patman/func_test.py|  2 +-
>>  tools/patman/test/-cover-letter.patch|  2 +-
>>  ...orrect-cast-for-sandbox-in-fdtdec_setup_memory_.patch |  4 ++--
>>  tools/patman/test/test01.txt |  2 +-
>>  30 files changed, 41 insertions(+), 37 deletions(-)

 [...]

> sjg: Do you see any issue with this patch?

 I think it is OK. Would like to get more people to look at it though.

>
> I can't see the reason for fixing tools/patman but I will wait for you.

 Changing patman tests is OK with me. Keeps thing consistent.
>>>
>>> thanks Simon.
>>>
>>> Tom: Do you see any issue with this change?
>>
>> Yes, thanks.  You can take it via your tree once Marek has had a chance
>> to test things.
>>
>> Reviewed-by: Tom Rini 
> 
> I'd rather like the rename in a separate patch, since that makes it hard
> to review. I don't see how "This patch fixes the erroneous
> calculation of ram_top incase of non zero ram start address." thought,
> maybe it's hidden in this mega-patch.
> 

We have discussed this with Marek over chat that he will look how
renesas is configuring sdram based.
Fix is done only in lib/fdtdec.c to fill
gd->ram_start = (unsigned long)res.start;

the rest is just renaming around.

Thanks,
Michal



___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH] gpio: zynq: Fix typo in one error message

2018-07-12 Thread Michal Simek
Just fix error message.

Signed-off-by: Michal Simek 
---

 drivers/gpio/zynq_gpio.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpio/zynq_gpio.c b/drivers/gpio/zynq_gpio.c
index afba4580f570..9a915544784d 100644
--- a/drivers/gpio/zynq_gpio.c
+++ b/drivers/gpio/zynq_gpio.c
@@ -178,7 +178,7 @@ static inline void zynq_gpio_get_bank_pin(unsigned int 
pin_num,
}
 
if (bank >= priv->p_data->max_bank) {
-   printf("Inavlid bank and pin num\n");
+   printf("Invalid bank and pin num\n");
*bank_num = 0;
*bank_pin_num = 0;
}
-- 
1.9.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v3 7/9] usb: rockchip: boost up write speed from 4MB/s to 15MB/s

2018-07-12 Thread Alberto Panizzo
Speedup transfers increasing the max chunk size.
Buffers are allocated with memalign thus developer is noticed when heap is
full and in current configuration a buffer allocation of 64K till now
is safe.

Signed-off-by: Alberto Panizzo 
---
 arch/arm/include/asm/arch-rockchip/f_rockusb.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/arch-rockchip/f_rockusb.h 
b/arch/arm/include/asm/arch-rockchip/f_rockusb.h
index 9772321..141aae6 100644
--- a/arch/arm/include/asm/arch-rockchip/f_rockusb.h
+++ b/arch/arm/include/asm/arch-rockchip/f_rockusb.h
@@ -19,7 +19,7 @@
 #define RX_ENDPOINT_MAXIMUM_PACKET_SIZE_1_1  0x0040
 #define TX_ENDPOINT_MAXIMUM_PACKET_SIZE  0x0040
 
-#define EP_BUFFER_SIZE 4096
+#define EP_BUFFER_SIZE 65536
 /*
  * EP_BUFFER_SIZE must always be an integral multiple of maxpacket size
  * (64 or 512 or 1024), else we break on certain controllers like DWC3
-- 
2.7.4

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v3 4/9] usb: rockchip: implement K_FW_LBA_READ_10 command

2018-07-12 Thread Alberto Panizzo
This patch implement reading blocks form selected device with
LBA addressing.

Corresponding command on workstation is:
rkdeveloptool rl   

While we support reading more than one blocks per K_FW_LBA_READ_10
request, rkdeveloptool and original rockchip tool do perform
chunk reads limiting the maximum size per chunk far lower
than max int values.

Signed-off-by: Alberto Panizzo 
---
 arch/arm/include/asm/arch-rockchip/f_rockusb.h |   3 +
 doc/README.rockusb |   1 +
 drivers/usb/gadget/f_rockusb.c | 104 -
 3 files changed, 107 insertions(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/arch-rockchip/f_rockusb.h 
b/arch/arm/include/asm/arch-rockchip/f_rockusb.h
index 0b62771..3f2e763 100644
--- a/arch/arm/include/asm/arch-rockchip/f_rockusb.h
+++ b/arch/arm/include/asm/arch-rockchip/f_rockusb.h
@@ -27,6 +27,7 @@
  */
 
 #define RKUSB_BUF_SIZE EP_BUFFER_SIZE * 2
+#define RKBLOCK_BUF_SIZE   4096
 
 #define RKUSB_STATUS_IDLE  0
 #define RKUSB_STATUS_CMD   1
@@ -120,6 +121,8 @@ struct f_rockusb {
unsigned int lba;
unsigned int dl_size;
unsigned int dl_bytes;
+   unsigned int ul_size;
+   unsigned int ul_bytes;
struct blk_desc *desc;
int reboot_flag;
void *buf;
diff --git a/doc/README.rockusb b/doc/README.rockusb
index 3a93edc..7f58296 100644
--- a/doc/README.rockusb
+++ b/doc/README.rockusb
@@ -47,6 +47,7 @@ Current set of rkdeveloptool commands supported:
 - rfi: Read Flash Id
 - rd : Reset Device
 - td : Test Device Ready
+- rl : Read blocks using LBA
 - wl : Write blocks using LBA
 
 To do
diff --git a/drivers/usb/gadget/f_rockusb.c b/drivers/usb/gadget/f_rockusb.c
index 0314ff0..82f421c 100644
--- a/drivers/usb/gadget/f_rockusb.c
+++ b/drivers/usb/gadget/f_rockusb.c
@@ -328,6 +328,7 @@ static int rockusb_tx_write(const char *buffer, unsigned 
int buffer_size)
 
memcpy(in_req->buf, buffer, buffer_size);
in_req->length = buffer_size;
+   debug("Transferring 0x%x bytes\n", buffer_size);
usb_ep_dequeue(rockusb_func->in_ep, in_req);
ret = usb_ep_queue(rockusb_func->in_ep, in_req, 0);
if (ret)
@@ -421,6 +422,65 @@ static unsigned int rx_bytes_expected(struct usb_ep *ep)
return rx_remain;
 }
 
+/* usb_request complete call back to handle upload image */
+static void tx_handler_ul_image(struct usb_ep *ep, struct usb_request *req)
+{
+   ALLOC_CACHE_ALIGN_BUFFER(char, rbuffer, RKBLOCK_BUF_SIZE);
+   struct f_rockusb *f_rkusb = get_rkusb();
+   struct usb_request *in_req = rockusb_func->in_req;
+   int ret;
+
+   /* Print error status of previous transfer */
+   if (req->status)
+   debug("status: %d ep '%s' trans: %d len %d\n", req->status,
+ ep->name, req->actual, req->length);
+
+   /* On transfer complete reset in_req and feedback host with CSW_GOOD */
+   if (f_rkusb->ul_bytes >= f_rkusb->ul_size) {
+   in_req->length = 0;
+   in_req->complete = rockusb_complete;
+
+   rockusb_tx_write_csw(f_rkusb->tag, 0, CSW_GOOD,
+USB_BULK_CS_WRAP_LEN);
+   return;
+   }
+
+   /* Proceed with current chunk */
+   unsigned int transfer_size = f_rkusb->ul_size - f_rkusb->ul_bytes;
+
+   if (transfer_size > RKBLOCK_BUF_SIZE)
+   transfer_size = RKBLOCK_BUF_SIZE;
+   /* Read at least one block */
+   unsigned int blkcount = (transfer_size + f_rkusb->desc->blksz - 1) /
+   f_rkusb->desc->blksz;
+
+   debug("ul %x bytes, %x blks, read lba %x, ul_size:%x, ul_bytes:%x, ",
+ transfer_size, blkcount, f_rkusb->lba,
+ f_rkusb->ul_size, f_rkusb->ul_bytes);
+
+   int blks = blk_dread(f_rkusb->desc, f_rkusb->lba, blkcount, rbuffer);
+
+   if (blks != blkcount) {
+   printf("failed reading from device %s: %d\n",
+  f_rkusb->dev_type, f_rkusb->dev_index);
+   rockusb_tx_write_csw(f_rkusb->tag, 0, CSW_FAIL,
+USB_BULK_CS_WRAP_LEN);
+   return;
+   }
+   f_rkusb->lba += blkcount;
+   f_rkusb->ul_bytes += transfer_size;
+
+   /* Proceed with USB request */
+   memcpy(in_req->buf, rbuffer, transfer_size);
+   in_req->length = transfer_size;
+   in_req->complete = tx_handler_ul_image;
+   printf("Uploading 0x%x bytes\n", transfer_size);
+   usb_ep_dequeue(rockusb_func->in_ep, in_req);
+   ret = usb_ep_queue(rockusb_func->in_ep, in_req, 0);
+   if (ret)
+   printf("Error %d on queue\n", ret);
+}
+
 /* usb_request complete call back to handle down load image */
 static void rx_handler_dl_image(struct usb_ep *ep, struct usb_request *req)
 {
@@ -565,6 +625,48 @@ static void cb_get_chip_version(struct usb_ep *ep, struct 

[U-Boot] [PATCH v3 5/9] usb: rockchip: implement K_FW_LBA_ERASE_10 command

2018-07-12 Thread Alberto Panizzo
This command is part of the write partition sequence performed by
rkdeveloptool: one partition is first completely erased and
than wrote.

Signed-off-by: Alberto Panizzo 
---
 arch/arm/include/asm/arch-rockchip/f_rockusb.h |  1 +
 doc/README.rockusb |  1 +
 drivers/usb/gadget/f_rockusb.c | 48 ++
 3 files changed, 50 insertions(+)

diff --git a/arch/arm/include/asm/arch-rockchip/f_rockusb.h 
b/arch/arm/include/asm/arch-rockchip/f_rockusb.h
index 3f2e763..9772321 100644
--- a/arch/arm/include/asm/arch-rockchip/f_rockusb.h
+++ b/arch/arm/include/asm/arch-rockchip/f_rockusb.h
@@ -63,6 +63,7 @@ K_FW_LOW_FORMAT = 0x1C,
 K_FW_SET_RESET_FLAG = 0x1E,
 K_FW_SPI_READ_10 = 0x21,
 K_FW_SPI_WRITE_10 = 0x22,
+K_FW_LBA_ERASE_10 = 0x25,
 
 K_FW_SESSION = 0X30,
 K_FW_RESET = 0xff,
diff --git a/doc/README.rockusb b/doc/README.rockusb
index 7f58296..66437e1 100644
--- a/doc/README.rockusb
+++ b/doc/README.rockusb
@@ -49,6 +49,7 @@ Current set of rkdeveloptool commands supported:
 - td : Test Device Ready
 - rl : Read blocks using LBA
 - wl : Write blocks using LBA
+- wlx: Write partition
 
 To do
 -
diff --git a/drivers/usb/gadget/f_rockusb.c b/drivers/usb/gadget/f_rockusb.c
index 82f421c..bcdc2ba 100644
--- a/drivers/usb/gadget/f_rockusb.c
+++ b/drivers/usb/gadget/f_rockusb.c
@@ -692,6 +692,50 @@ static void cb_write_lba(struct usb_ep *ep, struct 
usb_request *req)
}
 }
 
+static void cb_erase_lba(struct usb_ep *ep, struct usb_request *req)
+{
+   ALLOC_CACHE_ALIGN_BUFFER(struct fsg_bulk_cb_wrap, cbw,
+sizeof(struct fsg_bulk_cb_wrap));
+   struct f_rockusb *f_rkusb = get_rkusb();
+   int sector_count, lba, blks;
+
+   memcpy((char *)cbw, req->buf, USB_BULK_CB_WRAP_LEN);
+   sector_count = (int)get_unaligned_be16(>CDB[7]);
+   f_rkusb->tag = cbw->tag;
+
+   if (!f_rkusb->desc) {
+   char *type = f_rkusb->dev_type;
+   int index = f_rkusb->dev_index;
+
+   f_rkusb->desc = blk_get_dev(type, index);
+   if (!f_rkusb->desc ||
+   f_rkusb->desc->type == DEV_TYPE_UNKNOWN) {
+   printf("invalid device \"%s\", %d\n", type, index);
+   rockusb_tx_write_csw(f_rkusb->tag, 0, CSW_FAIL,
+USB_BULK_CS_WRAP_LEN);
+   return;
+   }
+   }
+
+   lba = get_unaligned_be32(>CDB[2]);
+
+   debug("require erase %x sectors from lba %x\n",
+ sector_count, lba);
+
+   blks = blk_derase(f_rkusb->desc, lba, sector_count);
+   if (blks != sector_count) {
+   printf("failed erasing device %s: %d\n", f_rkusb->dev_type,
+  f_rkusb->dev_index);
+   rockusb_tx_write_csw(f_rkusb->tag,
+cbw->data_transfer_length, CSW_FAIL,
+USB_BULK_CS_WRAP_LEN);
+   return;
+   }
+
+   rockusb_tx_write_csw(cbw->tag, cbw->data_transfer_length, CSW_GOOD,
+USB_BULK_CS_WRAP_LEN);
+}
+
 void __weak rkusb_set_reboot_flag(int flag)
 {
struct f_rockusb *f_rkusb = get_rkusb();
@@ -824,6 +868,10 @@ static const struct cmd_dispatch_info cmd_dispatch_info[] 
= {
.cb = cb_not_support,
},
{
+   .cmd = K_FW_LBA_ERASE_10,
+   .cb = cb_erase_lba,
+   },
+   {
.cmd = K_FW_SESSION,
.cb = cb_not_support,
},
-- 
2.7.4

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v3 9/9] usb: rockchip: on K_FW_LBA_WRITE_10 remove magic block size of 512 bytes

2018-07-12 Thread Alberto Panizzo
As well as in K_FW_LBA_READ_10 and K_FW_LBA_ERASE_10 take device's
block size from f_rkusb->desc->blksz instead of the fixed 512 bytes.

Keep original behaviour of retry probing assigned block device on
every host request to manage late SDCard plugs.

Signed-off-by: Alberto Panizzo 
---
 drivers/usb/gadget/f_rockusb.c | 39 +--
 1 file changed, 21 insertions(+), 18 deletions(-)

diff --git a/drivers/usb/gadget/f_rockusb.c b/drivers/usb/gadget/f_rockusb.c
index 574d610..e81eb16 100644
--- a/drivers/usb/gadget/f_rockusb.c
+++ b/drivers/usb/gadget/f_rockusb.c
@@ -490,19 +490,6 @@ static void rx_handler_dl_image(struct usb_ep *ep, struct 
usb_request *req)
unsigned int buffer_size = req->actual;
 
transfer_size = f_rkusb->dl_size - f_rkusb->dl_bytes;
-   if (!f_rkusb->desc) {
-   char *type = f_rkusb->dev_type;
-   int index = f_rkusb->dev_index;
-
-   f_rkusb->desc = blk_get_dev(type, index);
-   if (!f_rkusb->desc ||
-   f_rkusb->desc->type == DEV_TYPE_UNKNOWN) {
-   puts("invalid mmc device\n");
-   rockusb_tx_write_csw(f_rkusb->tag, 0, CSW_FAIL,
-USB_BULK_CS_WRAP_LEN);
-   return;
-   }
-   }
 
if (req->status != 0) {
printf("Bad status: %d\n", req->status);
@@ -516,7 +503,7 @@ static void rx_handler_dl_image(struct usb_ep *ep, struct 
usb_request *req)
 
memcpy((void *)f_rkusb->buf, buffer, transfer_size);
f_rkusb->dl_bytes += transfer_size;
-   int blks = 0, blkcnt = transfer_size  / 512;
+   int blks = 0, blkcnt = transfer_size  / f_rkusb->desc->blksz;
 
debug("dl %x bytes, %x blks, write lba %x, dl_size:%x, dl_bytes:%x, ",
  transfer_size, blkcnt, f_rkusb->lba, f_rkusb->dl_size,
@@ -547,8 +534,8 @@ static void rx_handler_dl_image(struct usb_ep *ep, struct 
usb_request *req)
else
f_rkusb->buf = f_rkusb->buf_head;
 
-   debug("remain %x bytes, %x sectors\n", req->length,
- req->length / 512);
+   debug("remain %x bytes, %lx sectors\n", req->length,
+ req->length / f_rkusb->desc->blksz);
}
 
req->actual = 0;
@@ -676,10 +663,26 @@ static void cb_write_lba(struct usb_ep *ep, struct 
usb_request *req)
 
memcpy((char *)cbw, req->buf, USB_BULK_CB_WRAP_LEN);
sector_count = (int)get_unaligned_be16(>CDB[7]);
+   f_rkusb->tag = cbw->tag;
+
+   if (!f_rkusb->desc) {
+   char *type = f_rkusb->dev_type;
+   int index = f_rkusb->dev_index;
+
+   f_rkusb->desc = blk_get_dev(type, index);
+   if (!f_rkusb->desc ||
+   f_rkusb->desc->type == DEV_TYPE_UNKNOWN) {
+   printf("invalid device \"%s\", %d\n", type, index);
+   rockusb_tx_write_csw(f_rkusb->tag, 0, CSW_FAIL,
+USB_BULK_CS_WRAP_LEN);
+   return;
+   }
+   }
+
f_rkusb->lba = get_unaligned_be32(>CDB[2]);
-   f_rkusb->dl_size = sector_count * 512;
+   f_rkusb->dl_size = sector_count * f_rkusb->desc->blksz;
f_rkusb->dl_bytes = 0;
-   f_rkusb->tag = cbw->tag;
+
debug("require write %x bytes, %x sectors to lba %x\n",
  f_rkusb->dl_size, sector_count, f_rkusb->lba);
 
-- 
2.7.4

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v3 8/9] usb: rockchip: fix printing csw debug info

2018-07-12 Thread Alberto Panizzo
Workstation tool was happy while console on device were printing
random numbers..

Signed-off-by: Alberto Panizzo 
---
 drivers/usb/gadget/f_rockusb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/gadget/f_rockusb.c b/drivers/usb/gadget/f_rockusb.c
index 0959b8c..574d610 100644
--- a/drivers/usb/gadget/f_rockusb.c
+++ b/drivers/usb/gadget/f_rockusb.c
@@ -384,7 +384,7 @@ static int rockusb_tx_write_csw(u32 tag, int residue, u8 
status, int size)
csw->residue = cpu_to_be32(residue);
csw->status = status;
 #ifdef DEBUG
-   printcsw((char *));
+   printcsw((char *)csw);
 #endif
return rockusb_tx_write((char *)csw, size);
 }
-- 
2.7.4

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v3 6/9] usb: rockchip: be quiet on serial port while transferring data

2018-07-12 Thread Alberto Panizzo
While downloading or uploading megabytes of data we had thousands of
printf in console like:

transfer 0x1 bytes done
OR
Uploading 0x1000 bytes

This because transfers are chunked and there is no way on target
side to know the overall transfer size (to print one string per
overall transfer).

All these prints on serial console do slow down significantly the
transfer and does not offer a significant information to the
developer: rkdeveloptool and Rockchip original tool do use small
chunks read/writes on big transfers. This allows on workstation
to print percentage of transfer complete and as well offers to
developer the information about: transfer is running OK.
On error, either the percentage will stop or an error will be shown
on workstation console.

Signed-off-by: Alberto Panizzo 
---
 drivers/usb/gadget/f_rockusb.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/gadget/f_rockusb.c b/drivers/usb/gadget/f_rockusb.c
index bcdc2ba..0959b8c 100644
--- a/drivers/usb/gadget/f_rockusb.c
+++ b/drivers/usb/gadget/f_rockusb.c
@@ -474,7 +474,7 @@ static void tx_handler_ul_image(struct usb_ep *ep, struct 
usb_request *req)
memcpy(in_req->buf, rbuffer, transfer_size);
in_req->length = transfer_size;
in_req->complete = tx_handler_ul_image;
-   printf("Uploading 0x%x bytes\n", transfer_size);
+   debug("Uploading 0x%x bytes\n", transfer_size);
usb_ep_dequeue(rockusb_func->in_ep, in_req);
ret = usb_ep_queue(rockusb_func->in_ep, in_req, 0);
if (ret)
@@ -536,7 +536,7 @@ static void rx_handler_dl_image(struct usb_ep *ep, struct 
usb_request *req)
req->complete = rx_handler_command;
req->length = EP_BUFFER_SIZE;
f_rkusb->buf = f_rkusb->buf_head;
-   printf("transfer 0x%x bytes done\n", f_rkusb->dl_size);
+   debug("transfer 0x%x bytes done\n", f_rkusb->dl_size);
f_rkusb->dl_size = 0;
rockusb_tx_write_csw(f_rkusb->tag, 0, CSW_GOOD,
 USB_BULK_CS_WRAP_LEN);
-- 
2.7.4

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v3 3/9] rockchip: rk3288: implement reading chip version from bootrom code

2018-07-12 Thread Alberto Panizzo
This allows rockusb code to reply correctly to K_FW_GET_CHIP_VER
command.

On RK3288 chip version is at 0x4ff0 and on tested hardware it
corresponds at the string "320A20140813V200"

Signed-off-by: Alberto Panizzo 
---
 arch/arm/mach-rockchip/rk3288/Makefile |  1 +
 arch/arm/mach-rockchip/rk3288/rockusb_rk3288.c | 30 ++
 2 files changed, 31 insertions(+)
 create mode 100644 arch/arm/mach-rockchip/rk3288/rockusb_rk3288.c

diff --git a/arch/arm/mach-rockchip/rk3288/Makefile 
b/arch/arm/mach-rockchip/rk3288/Makefile
index a0033a0..da0eb4a 100644
--- a/arch/arm/mach-rockchip/rk3288/Makefile
+++ b/arch/arm/mach-rockchip/rk3288/Makefile
@@ -7,3 +7,4 @@
 obj-y += clk_rk3288.o
 obj-y += rk3288.o
 obj-y += syscon_rk3288.o
+obj-$(CONFIG_USB_FUNCTION_ROCKUSB) += rockusb_rk3288.o
diff --git a/arch/arm/mach-rockchip/rk3288/rockusb_rk3288.c 
b/arch/arm/mach-rockchip/rk3288/rockusb_rk3288.c
new file mode 100644
index 000..62057c1
--- /dev/null
+++ b/arch/arm/mach-rockchip/rk3288/rockusb_rk3288.c
@@ -0,0 +1,30 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2018 Amarula Solutions
+ * Written by Alberto Panizzo 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define ROM_PHYS   0x
+
+#define ROM_CHIP_VER_ADDR_ADDR (ROM_PHYS + 0x4FF0)
+#define ROM_CHIP_VER_ADDR_SIZE 16
+
+int rk_get_bootrom_chip_version(unsigned int *chip_info, int size)
+{
+   if (!chip_info)
+   return -1;
+   if (size < ROM_CHIP_VER_ADDR_SIZE / sizeof(int))
+   return -1;
+
+   memcpy((char *)chip_info, (char *)ROM_CHIP_VER_ADDR_ADDR,
+  ROM_CHIP_VER_ADDR_SIZE);
+
+   return 0;
+}
-- 
2.7.4

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v3 1/9] usb: rockchip: fix command failed on host side due to missing data

2018-07-12 Thread Alberto Panizzo
Two consecutive rockusb_tx_write without waiting for request complete
do results in transfer reset of first request and thus no or incomplete
data transfer. This because rockusb_tx_write do use just one USB request
to keep serialization.

So calls like:
rockusb_tx_write_str(emmc_id);
rockusb_tx_write_csw(cbw->tag, cbw->data_transfer_length, CSW_GOOD);

was succeeding only when DEBUG was defined because the time spent
printing debug info was enough for transfer to complete.

This patch fixes the issue adding a simple request complete handler
called rockusb_tx_write_csw to be set as complete handler of in_req
when sending back simple payload + CSW replies to commands.

This new handler will always send CSW_GOOD replies because in case
of error the command callback itself must send back an error CSW as
unique reply to command.

This patch fixes execution of:
$ rkdeveloptool rfi
when DEBUG is not defined.

Signed-off-by: Alberto Panizzo 
---
 drivers/usb/gadget/f_rockusb.c | 22 --
 1 file changed, 20 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/gadget/f_rockusb.c b/drivers/usb/gadget/f_rockusb.c
index b8833d0..58e483c 100644
--- a/drivers/usb/gadget/f_rockusb.c
+++ b/drivers/usb/gadget/f_rockusb.c
@@ -388,6 +388,20 @@ static int rockusb_tx_write_csw(u32 tag, int residue, u8 
status, int size)
return rockusb_tx_write((char *)csw, size);
 }
 
+static void tx_handler_send_csw(struct usb_ep *ep, struct usb_request *req)
+{
+   struct f_rockusb *f_rkusb = get_rkusb();
+   int status = req->status;
+
+   if (status)
+   debug("status: %d ep '%s' trans: %d\n",
+ status, ep->name, req->actual);
+
+   /* Return back to default in_req complete function after sending CSW */
+   req->complete = rockusb_complete;
+   rockusb_tx_write_csw(f_rkusb->tag, 0, CSW_GOOD, USB_BULK_CS_WRAP_LEN);
+}
+
 static unsigned int rx_bytes_expected(struct usb_ep *ep)
 {
struct f_rockusb *f_rkusb = get_rkusb();
@@ -496,13 +510,17 @@ static void cb_read_storage_id(struct usb_ep *ep, struct 
usb_request *req)
 {
ALLOC_CACHE_ALIGN_BUFFER(struct fsg_bulk_cb_wrap, cbw,
 sizeof(struct fsg_bulk_cb_wrap));
+   struct f_rockusb *f_rkusb = get_rkusb();
char emmc_id[] = "EMMC ";
 
printf("read storage id\n");
memcpy((char *)cbw, req->buf, USB_BULK_CB_WRAP_LEN);
+
+   /* Prepare for sending subsequent CSW_GOOD */
+   f_rkusb->tag = cbw->tag;
+   f_rkusb->in_req->complete = tx_handler_send_csw;
+
rockusb_tx_write_str(emmc_id);
-   rockusb_tx_write_csw(cbw->tag, cbw->data_transfer_length, CSW_GOOD,
-USB_BULK_CS_WRAP_LEN);
 }
 
 static void cb_write_lba(struct usb_ep *ep, struct usb_request *req)
-- 
2.7.4

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v3 2/9] usb: rockchip: implement skeleton for K_FW_GET_CHIP_VER command

2018-07-12 Thread Alberto Panizzo
Chip Version is a string saved in BOOTROM address space Little Endian.

Ex for rk3288: 0x33323041 0x32303134 0x30383133 0x56323030
which brings:  320A20140813V200

Note that memory version do invert MSB/LSB so printing the char
buffer would show: A02341023180002V

Signed-off-by: Alberto Panizzo 
---
 doc/README.rockusb |  9 ++---
 drivers/usb/gadget/f_rockusb.c | 44 +-
 2 files changed, 49 insertions(+), 4 deletions(-)

diff --git a/doc/README.rockusb b/doc/README.rockusb
index 5405dc4..3a93edc 100644
--- a/doc/README.rockusb
+++ b/doc/README.rockusb
@@ -42,9 +42,12 @@ see doc/README.rockchip for more detail about how to get 
U-Boot binary.
 
 sudo rkdeveloptool wl  64 
 
-There are plenty of Rockusb command. but wl(write lba) and
-rd(reboot) command. These two command can let people flash
-image to device.
+Current set of rkdeveloptool commands supported:
+- rci: Read Chip Info
+- rfi: Read Flash Id
+- rd : Reset Device
+- td : Test Device Ready
+- wl : Write blocks using LBA
 
 To do
 -
diff --git a/drivers/usb/gadget/f_rockusb.c b/drivers/usb/gadget/f_rockusb.c
index 58e483c..0314ff0 100644
--- a/drivers/usb/gadget/f_rockusb.c
+++ b/drivers/usb/gadget/f_rockusb.c
@@ -523,6 +523,48 @@ static void cb_read_storage_id(struct usb_ep *ep, struct 
usb_request *req)
rockusb_tx_write_str(emmc_id);
 }
 
+int __weak rk_get_bootrom_chip_version(unsigned int *chip_info, int size)
+{
+   return 0;
+}
+
+static void cb_get_chip_version(struct usb_ep *ep, struct usb_request *req)
+{
+   ALLOC_CACHE_ALIGN_BUFFER(struct fsg_bulk_cb_wrap, cbw,
+sizeof(struct fsg_bulk_cb_wrap));
+   struct f_rockusb *f_rkusb = get_rkusb();
+   unsigned int chip_info[4], i;
+
+   memset(chip_info, 0, sizeof(chip_info));
+   rk_get_bootrom_chip_version(chip_info, 4);
+
+   /*
+* Chip Version is a string saved in BOOTROM address space Little Endian
+*
+* Ex for rk3288: 0x33323041 0x32303134 0x30383133 0x56323030
+* which brings:  320A20140813V200
+*
+* Note that memory version do invert MSB/LSB so printing the char
+* buffer will show: A02341023180002V
+*/
+   printf("read chip version: ");
+   for (i = 0; i < 4; i++) {
+   printf("%c%c%c%c",
+  (chip_info[i] >> 24) & 0xFF,
+  (chip_info[i] >> 16) & 0xFF,
+  (chip_info[i] >>  8) & 0xFF,
+  (chip_info[i] >>  0) & 0xFF);
+   }
+   printf("\n");
+   memcpy((char *)cbw, req->buf, USB_BULK_CB_WRAP_LEN);
+
+   /* Prepare for sending subsequent CSW_GOOD */
+   f_rkusb->tag = cbw->tag;
+   f_rkusb->in_req->complete = tx_handler_send_csw;
+
+   rockusb_tx_write((char *)chip_info, sizeof(chip_info));
+}
+
 static void cb_write_lba(struct usb_ep *ep, struct usb_request *req)
 {
ALLOC_CACHE_ALIGN_BUFFER(struct fsg_bulk_cb_wrap, cbw,
@@ -661,7 +703,7 @@ static const struct cmd_dispatch_info cmd_dispatch_info[] = 
{
},
{
.cmd = K_FW_GET_CHIP_VER,
-   .cb = cb_not_support,
+   .cb = cb_get_chip_version,
},
{
.cmd = K_FW_LOW_FORMAT,
-- 
2.7.4

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v3 0/9] Improve rockusb support in U-Boot

2018-07-12 Thread Alberto Panizzo
rockusb protocol has been introduced by Eddie Cai in U-Boot mainline
allowing to write internal eMMC of RK3288 based boards (and potentially
all other Rockchip's CPUs).

On workstation side the open source project rkdeveloptool do implement
the rockusb protocol. You can find it on GitHub here:
https://github.com/rockchip-linux/rkdeveloptool

This patchset increase the supported functionalities on target side
allowing developers to:
- Read flash: rl command of rkdeveloptool
- Read chip version: rci command of rkdeveloptool
- Complete the write cycle implementing block erase
- Improve read/write speed

Changes in v2:
- Reworked patch 1/8 to obtain simpler and more logical code
- Rewrote some patch messages
- Updated documentation in README.rockusb  patch by patch
- Added patch 8/8 to fix debug prints of original code

Changes in v3:
- Removed magic block size of 512 bytes for all implemented commands
  original behavior of re-probing a non present block device
  (like a non plugged SD-Card) is kept

Alberto Panizzo (9):
  usb: rockchip: fix command failed on host side due to missing data
  usb: rockchip: implement skeleton for K_FW_GET_CHIP_VER command
  rockchip: rk3288: implement reading chip version from bootrom code
  usb: rockchip: implement K_FW_LBA_READ_10 command
  usb: rockchip: implement K_FW_LBA_ERASE_10 command
  usb: rockchip: be quiet on serial port while transferring data
  usb: rockchip: boost up write speed from 4MB/s to 15MB/s
  usb: rockchip: fix printing csw debug info
  usb: rockchip: on K_FW_LBA_WRITE_10 remove magic block size of 512
bytes

 arch/arm/include/asm/arch-rockchip/f_rockusb.h |   6 +-
 arch/arm/mach-rockchip/rk3288/Makefile |   1 +
 arch/arm/mach-rockchip/rk3288/rockusb_rk3288.c |  30 +++
 doc/README.rockusb |  11 +-
 drivers/usb/gadget/f_rockusb.c | 261 ++---
 5 files changed, 281 insertions(+), 28 deletions(-)
 create mode 100644 arch/arm/mach-rockchip/rk3288/rockusb_rk3288.c

-- 
2.7.4

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [RFC PATCH v2] u-boot: remove driver lookup loop from env_save()

2018-07-12 Thread Simon Goldschmidt



On 12.07.2018 12:52, Nicholas Faustini wrote:

When called with ENVOP_SAVE, env_get_location() only returns the
gd->env_load_location variable without actually checking for
the environment location and priority.

This behaviour causes env_save() to fall into an infinite loop when
the low-level drv->save() call fails.

The env_save() function should not loop through the environment
location list but it should save the environment into the location
stored in gd->env_load_location by the last env_load() call.

Signed-off-by: Nicholas Faustini 
---

Changes in v2:
- Restore gd->env_load_location to the highest priority location when
   env_load() fails

  env/env.c | 10 ++
  1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/env/env.c b/env/env.c
index 5c0842a..18eb78d 100644
--- a/env/env.c
+++ b/env/env.c
@@ -205,22 +205,24 @@ int env_load(void)
return 0;
}
  
+	env_get_location(ENVOP_LOAD, 0);


A comment why this is required would be good, I guess.


+
return -ENODEV;
  }
  
  int env_save(void)

  {
struct env_driver *drv;
-   int prio;
  
-	for (prio = 0; (drv = env_driver_lookup(ENVOP_SAVE, prio)); prio++) {

+   drv = env_driver_lookup(ENVOP_SAVE, 0);


Thinking again about this, would it make more sense to store 
'env_load_prio' in 'gd' after successful load? That way, 
'env_get_location()' would be more straightforward (no special case for 
ENVOP_SAVE) and here in 'env_save()' we could just write something like 
this:


drv = env_driver_lookup(ENVOP_SAVE, gd->env_load_prio);


Simon


+   if (drv) {
int ret;
  
  		if (!drv->save)

-   continue;
+   return -ENODEV;
  
  		if (!env_has_inited(drv->location))

-   continue;
+   return -ENODEV;
  
  		printf("Saving Environment to %s... ", drv->name);

ret = drv->save();


___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [RFC PATCH v2] u-boot: remove driver lookup loop from env_save()

2018-07-12 Thread Nicholas Faustini
When called with ENVOP_SAVE, env_get_location() only returns the
gd->env_load_location variable without actually checking for
the environment location and priority.

This behaviour causes env_save() to fall into an infinite loop when
the low-level drv->save() call fails.

The env_save() function should not loop through the environment
location list but it should save the environment into the location
stored in gd->env_load_location by the last env_load() call.

Signed-off-by: Nicholas Faustini 
---

Changes in v2:
- Restore gd->env_load_location to the highest priority location when
  env_load() fails

 env/env.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/env/env.c b/env/env.c
index 5c0842a..18eb78d 100644
--- a/env/env.c
+++ b/env/env.c
@@ -205,22 +205,24 @@ int env_load(void)
return 0;
}
 
+   env_get_location(ENVOP_LOAD, 0);
+
return -ENODEV;
 }
 
 int env_save(void)
 {
struct env_driver *drv;
-   int prio;
 
-   for (prio = 0; (drv = env_driver_lookup(ENVOP_SAVE, prio)); prio++) {
+   drv = env_driver_lookup(ENVOP_SAVE, 0);
+   if (drv) {
int ret;
 
if (!drv->save)
-   continue;
+   return -ENODEV;
 
if (!env_has_inited(drv->location))
-   continue;
+   return -ENODEV;
 
printf("Saving Environment to %s... ", drv->name);
ret = drv->save();
-- 
2.7.4

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [ v1 07/10] video: add support of STM32 MIPI DSI controller driver

2018-07-12 Thread Yannick Fertré
Add the STM32 DSI controller driver that uses the Synopsys DesignWare
MIPI DSI host controller bridge.

Signed-off-by: Yannick Fertré 
---
 drivers/video/stm32/Kconfig |  10 +
 drivers/video/stm32/Makefile|   1 +
 drivers/video/stm32/stm32_dsi.c | 427 
 3 files changed, 438 insertions(+)
 create mode 100644 drivers/video/stm32/stm32_dsi.c

diff --git a/drivers/video/stm32/Kconfig b/drivers/video/stm32/Kconfig
index 78b1fac..5b5e2c4 100644
--- a/drivers/video/stm32/Kconfig
+++ b/drivers/video/stm32/Kconfig
@@ -13,6 +13,16 @@ menuconfig VIDEO_STM32
  DSI. This option enables these supports which can be used on
  devices which have RGB TFT or DSI display connected.
 
+config VIDEO_STM32_DSI
+   bool "Enable STM32 DSI video support"
+   depends on VIDEO_STM32
+   select VIDEO_MIPI_DSI
+   select VIDEO_BRIDGE
+   select VIDEO_DW_MIPI_DSI
+   help
+ This option enables support DSI internal bridge which can be used on
+ devices which have DSI devices connected.
+
 config VIDEO_STM32_MAX_XRES
int "Maximum horizontal resolution (for memory allocation purposes)"
depends on VIDEO_STM32
diff --git a/drivers/video/stm32/Makefile b/drivers/video/stm32/Makefile
index 7297e5f..f8b42d1 100644
--- a/drivers/video/stm32/Makefile
+++ b/drivers/video/stm32/Makefile
@@ -6,3 +6,4 @@
 #  Yannick Fertre 
 
 obj-${CONFIG_VIDEO_STM32} = stm32_ltdc.o
+obj-${CONFIG_VIDEO_STM32_DSI} += stm32_dsi.o
diff --git a/drivers/video/stm32/stm32_dsi.c b/drivers/video/stm32/stm32_dsi.c
new file mode 100644
index 000..43da83d
--- /dev/null
+++ b/drivers/video/stm32/stm32_dsi.c
@@ -0,0 +1,427 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2018 STMicroelectronics - All Rights Reserved
+ * Author(s): Philippe Cornu  for STMicroelectronics.
+ *   Yannick Fertre  for STMicroelectronics.
+ *
+ * This MIPI DSI controller driver is inspired from the Linux Kernel driver
+ * drivers/gpu/drm/stm/dw_mipi_dsi-stm.c.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define HWVER_130  0x31333000  /* IP version 1.30 */
+#define HWVER_131  0x31333100  /* IP version 1.31 */
+
+/* DSI digital registers & bit definitions */
+#define DSI_VERSION0x00
+#define VERSIONGENMASK(31, 8)
+
+/*
+ * DSI wrapper registers & bit definitions
+ * Note: registers are named as in the Reference Manual
+ */
+#define DSI_WCFGR  0x0400  /* Wrapper ConFiGuration Reg */
+#define WCFGR_DSIM BIT(0)  /* DSI Mode */
+#define WCFGR_COLMUX   GENMASK(3, 1)   /* COLor MUltipleXing */
+
+#define DSI_WCR0x0404  /* Wrapper Control Reg */
+#define WCR_DSIEN  BIT(3)  /* DSI ENable */
+
+#define DSI_WISR   0x040C  /* Wrapper Interrupt and Status Reg */
+#define WISR_PLLLS BIT(8)  /* PLL Lock Status */
+#define WISR_RRS   BIT(12) /* Regulator Ready Status */
+
+#define DSI_WPCR0  0x0418  /* Wrapper Phy Conf Reg 0 */
+#define WPCR0_UIX4 GENMASK(5, 0)   /* Unit Interval X 4 */
+#define WPCR0_TDDL BIT(16) /* Turn Disable Data Lanes */
+
+#define DSI_WRPCR  0x0430  /* Wrapper Regulator & Pll Ctrl Reg */
+#define WRPCR_PLLENBIT(0)  /* PLL ENable */
+#define WRPCR_NDIV GENMASK(8, 2)   /* pll loop DIVision Factor */
+#define WRPCR_IDF  GENMASK(14, 11) /* pll Input Division Factor */
+#define WRPCR_ODF  GENMASK(17, 16) /* pll Output Division Factor */
+#define WRPCR_REGENBIT(24) /* REGulator ENable */
+#define WRPCR_BGRENBIT(28) /* BandGap Reference ENable */
+#define IDF_MIN1
+#define IDF_MAX7
+#define NDIV_MIN   10
+#define NDIV_MAX   125
+#define ODF_MIN1
+#define ODF_MAX8
+
+/* dsi color format coding according to the datasheet */
+enum dsi_color {
+   DSI_RGB565_CONF1,
+   DSI_RGB565_CONF2,
+   DSI_RGB565_CONF3,
+   DSI_RGB666_CONF1,
+   DSI_RGB666_CONF2,
+   DSI_RGB888,
+};
+
+#define LANE_MIN_KBPS  31250
+#define LANE_MAX_KBPS  50
+
+/* Timeout for regulator on/off, pll lock/unlock & fifo empty */
+#define TIMEOUT_US 20
+
+struct stm32_dsi_priv {
+   struct mipi_dsi_device device;
+   void __iomem *base;
+   struct udevice *panel;
+   u32 pllref_clk;
+   u32 hw_version;
+   int lane_min_kbps;
+   int lane_max_kbps;
+};
+
+static inline void dsi_write(struct stm32_dsi_priv *dsi, u32 reg, u32 val)
+{
+   writel(val, dsi->base + reg);
+}
+
+static inline u32 dsi_read(struct stm32_dsi_priv *dsi, u32 reg)
+{
+   return readl(dsi->base + reg);
+}
+
+static inline void dsi_set(struct stm32_dsi_priv *dsi, u32 reg, u32 mask)
+{
+   

[U-Boot] [ v1 10/10] board: Add STM32F769 SoC, discovery board support

2018-07-12 Thread Yannick Fertré
Signed-off-by: Yannick Fertré 
---
 configs/stm32f769-disco_defconfig | 67 +++
 1 file changed, 67 insertions(+)
 create mode 100644 configs/stm32f769-disco_defconfig

diff --git a/configs/stm32f769-disco_defconfig 
b/configs/stm32f769-disco_defconfig
new file mode 100644
index 000..bc99894
--- /dev/null
+++ b/configs/stm32f769-disco_defconfig
@@ -0,0 +1,67 @@
+CONFIG_ARM=y
+CONFIG_STM32=y
+CONFIG_SYS_TEXT_BASE=0x08008000
+CONFIG_SYS_MALLOC_F_LEN=0xC00
+CONFIG_STM32F7=y
+CONFIG_TARGET_STM32F746_DISCO=y
+CONFIG_DEFAULT_DEVICE_TREE="stm32f769-disco"
+CONFIG_ENV_VARS_UBOOT_CONFIG=y
+CONFIG_BOOTDELAY=3
+CONFIG_USE_BOOTARGS=y
+CONFIG_BOOTARGS="console=ttyS0,115200 earlyprintk consoleblank=0 
ignore_loglevel"
+# CONFIG_DISPLAY_CPUINFO is not set
+# CONFIG_DISPLAY_BOARDINFO is not set
+CONFIG_BOARD_EARLY_INIT_F=y
+CONFIG_HUSH_PARSER=y
+CONFIG_SYS_PROMPT="U-Boot > "
+CONFIG_AUTOBOOT_KEYED=y
+CONFIG_AUTOBOOT_PROMPT="Hit SPACE in %d seconds to stop autoboot.\n"
+CONFIG_AUTOBOOT_STOP_STR=" "
+CONFIG_CMD_BOOTZ=y
+CONFIG_CMD_GPT=y
+# CONFIG_RANDOM_UUID is not set
+CONFIG_CMD_MMC=y
+CONFIG_CMD_SF=y
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_DHCP=y
+CONFIG_CMD_MII=y
+CONFIG_CMD_PING=y
+CONFIG_CMD_SNTP=y
+CONFIG_CMD_DNS=y
+CONFIG_CMD_LINK_LOCAL=y
+CONFIG_CMD_BMP=y
+CONFIG_CMD_TIMER=y
+CONFIG_CMD_EXT2=y
+CONFIG_CMD_EXT4=y
+CONFIG_CMD_FAT=y
+CONFIG_CMD_FS_GENERIC=y
+# CONFIG_SPL_DOS_PARTITION is not set
+# CONFIG_SPL_EFI_PARTITION is not set
+CONFIG_OF_CONTROL=y
+CONFIG_NET_RANDOM_ETHADDR=y
+CONFIG_NETCONSOLE=y
+# CONFIG_BLK is not set
+CONFIG_DM_MMC=y
+# CONFIG_SPL_DM_MMC is not set
+CONFIG_ARM_PL180_MMCI=y
+CONFIG_MTD=y
+CONFIG_MTD_NOR_FLASH=y
+CONFIG_DM_SPI_FLASH=y
+CONFIG_SPI_FLASH=y
+CONFIG_SPI_FLASH_STMICRO=y
+CONFIG_DM_ETH=y
+CONFIG_ETH_DESIGNWARE=y
+# CONFIG_PINCTRL_FULL is not set
+CONFIG_SPI=y
+CONFIG_DM_SPI=y
+CONFIG_STM32_QSPI=y
+CONFIG_DM_VIDEO=y
+CONFIG_BACKLIGHT_GPIO=y
+CONFIG_VIDEO_LCD_ORISETECH_OTM8009A=y
+CONFIG_VIDEO_STM32=y
+CONFIG_VIDEO_STM32_DSI=y
+CONFIG_VIDEO_STM32_MAX_XRES=480
+CONFIG_VIDEO_STM32_MAX_YRES=800
+CONFIG_VIDEO_BRIDGE=y
+CONFIG_OF_LIBFDT_OVERLAY=y
+# CONFIG_EFI_LOADER is not set
-- 
1.9.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [ v1 08/10] arm: dts: stm32: add dsi for STM32F746

2018-07-12 Thread Yannick Fertré
Add mipi dsi bridge node in device-tree.

Signed-off-by: Yannick Fertré 
---
 arch/arm/dts/stm32f746.dtsi | 12 
 1 file changed, 12 insertions(+)

diff --git a/arch/arm/dts/stm32f746.dtsi b/arch/arm/dts/stm32f746.dtsi
index afa7832..005d267 100644
--- a/arch/arm/dts/stm32f746.dtsi
+++ b/arch/arm/dts/stm32f746.dtsi
@@ -340,6 +340,18 @@
u-boot,dm-pre-reloc;
status = "disabled";
};
+
+   dsi: dsi@40016c00 {
+   compatible = "st,stm32-dsi";
+   reg = <0x40016C00 0x800>;
+   resets = < STM32F7_APB2_RESET(DSI)>;
+   clocks =  < 0 STM32F7_APB2_CLOCK(DSI)>,
+ < 0 STM32F7_APB2_CLOCK(LTDC)>,
+ <_hse>;
+   clock-names = "pclk", "px_clk", "ref";
+   u-boot,dm-pre-reloc;
+   status = "disabled";
+   };
};
 };
 
-- 
1.9.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 1/1] avb2.0: add proper dependencies to libavb

2018-07-12 Thread Eugeniu Rosca
Hi Igor,

Thanks for the fix. See my comments below.

On Thu, Jul 12, 2018 at 10:34:24AM +0300, Igor Opaniuk wrote:
> Provide proper dependencies for LIBAVB: (FASTBOOT and !BLK):
> 1. CONFIG_FASTBOOT is needed, as fastboot buffer is re-used (which
> is initially used in the fastboot protocol for downloads)
> 2. !CONFIG_BLK, as current implementation currently
> doesn't support non-legacy block API.
> 
> Reported-by: Eugeniu Rosca 
> Signed-off-by: Igor Opaniuk 
> ---
>  lib/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/lib/Kconfig b/lib/Kconfig
> index a77bf1c..4780e7e 100644
> --- a/lib/Kconfig
> +++ b/lib/Kconfig
> @@ -191,7 +191,7 @@ menu "Android Verified Boot"
>  
>  config LIBAVB
>   bool "Android Verified Boot 2.0 support"
> - depends on ANDROID_BOOT_IMAGE
> + depends on ANDROID_BOOT_IMAGE && FASTBOOT && !BLK

Since libavb library alone is highly portable (it compiles fine with
several compilers), I'm not sure if's the best choice to make it
dependent on FASTBOOT (obviously it is not dependent on it). The
dependency is rather introduced by commit 3af30e4443aa ("avb2.0:
implement AVB ops"), which re-uses CONFIG_LIBAVB Kconfig symbol to wire
common/avb_verify.c to Kbuild.

So, unless you have some counter-proposal, I vote for adding a new
Kconfig symbol for common/avb_verify.c, which then can be marked as
dependent on FASTBOOT. This will also keep the hopes alive about
testing libavb on sandbox.

Thanks,
Eugeniu.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [ v1 06/10] video: add MIPI DSI host controller bridge

2018-07-12 Thread Yannick Fertré
Add a Synopsys Designware MIPI DSI host bridge driver, based on the
Rockchip version from rockchip/dw-mipi-dsi.c with phy & bridge APIs.

Signed-off-by: Yannick Fertré 
---
 drivers/video/Kconfig   |   9 +
 drivers/video/Makefile  |   1 +
 drivers/video/dw_mipi_dsi.c | 826 
 include/dw_mipi_dsi.h   |  32 ++
 4 files changed, 868 insertions(+)
 create mode 100644 drivers/video/dw_mipi_dsi.c
 create mode 100644 include/dw_mipi_dsi.h

diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index e1029e5..3ccc8df 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -674,6 +674,15 @@ config VIDEO_DW_HDMI
  rather requires a SoC-specific glue driver to call it), it
  can not be enabled from the configuration menu.
 
+config VIDEO_DW_MIPI_DSI
+   bool
+   help
+ Enables the common driver code for the Synopsis Designware
+ MIPI DSI block found in SoCs from various vendors.
+ As this does not provide any functionality by itself (but
+ rather requires a SoC-specific glue driver to call it), it
+ can not be enabled from the configuration menu.
+
 config VIDEO_SIMPLE
bool "Simple display driver for preconfigured display"
help
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index 018343f..bb2fd3c 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -52,6 +52,7 @@ obj-$(CONFIG_FORMIKE) += formike.o
 obj-$(CONFIG_LG4573) += lg4573.o
 obj-$(CONFIG_AM335X_LCD) += am335x-fb.o
 obj-$(CONFIG_VIDEO_DW_HDMI) += dw_hdmi.o
+obj-$(CONFIG_VIDEO_DW_MIPI_DSI) += dw_mipi_dsi.o
 obj-${CONFIG_VIDEO_MIPI_DSI} += mipi_display.o
 obj-$(CONFIG_VIDEO_SIMPLE) += simplefb.o
 obj-${CONFIG_VIDEO_TEGRA124} += tegra124/
diff --git a/drivers/video/dw_mipi_dsi.c b/drivers/video/dw_mipi_dsi.c
new file mode 100644
index 000..db278c5
--- /dev/null
+++ b/drivers/video/dw_mipi_dsi.c
@@ -0,0 +1,826 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2016, Fuzhou Rockchip Electronics Co., Ltd
+ * Copyright (C) 2018, STMicroelectronics - All Rights Reserved
+ * Author(s): Philippe Cornu  for STMicroelectronics.
+ *Yannick Fertre  for STMicroelectronics.
+ *
+ * This generic Synopsys DesignWare MIPI DSI host driver is inspired from
+ * the Linux Kernel driver drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define HWVER_131  0x31333100  /* IP version 1.31 */
+
+#define DSI_VERSION0x00
+#define VERSIONGENMASK(31, 8)
+
+#define DSI_PWR_UP 0x04
+#define RESET  0
+#define POWERUPBIT(0)
+
+#define DSI_CLKMGR_CFG 0x08
+#define TO_CLK_DIVISION(div)   (((div) & 0xff) << 8)
+#define TX_ESC_CLK_DIVISION(div)   ((div) & 0xff)
+
+#define DSI_DPI_VCID   0x0c
+#define DPI_VCID(vcid) ((vcid) & 0x3)
+
+#define DSI_DPI_COLOR_CODING   0x10
+#define LOOSELY18_EN   BIT(8)
+#define DPI_COLOR_CODING_16BIT_1   0x0
+#define DPI_COLOR_CODING_16BIT_2   0x1
+#define DPI_COLOR_CODING_16BIT_3   0x2
+#define DPI_COLOR_CODING_18BIT_1   0x3
+#define DPI_COLOR_CODING_18BIT_2   0x4
+#define DPI_COLOR_CODING_24BIT 0x5
+
+#define DSI_DPI_CFG_POL0x14
+#define COLORM_ACTIVE_LOW  BIT(4)
+#define SHUTD_ACTIVE_LOW   BIT(3)
+#define HSYNC_ACTIVE_LOW   BIT(2)
+#define VSYNC_ACTIVE_LOW   BIT(1)
+#define DATAEN_ACTIVE_LOW  BIT(0)
+
+#define DSI_DPI_LP_CMD_TIM 0x18
+#define OUTVACT_LPCMD_TIME(p)  (((p) & 0xff) << 16)
+#define INVACT_LPCMD_TIME(p)   ((p) & 0xff)
+
+#define DSI_DBI_VCID   0x1c
+#define DSI_DBI_CFG0x20
+#define DSI_DBI_PARTITIONING_EN0x24
+#define DSI_DBI_CMDSIZE0x28
+
+#define DSI_PCKHDL_CFG 0x2c
+#define CRC_RX_EN  BIT(4)
+#define ECC_RX_EN  BIT(3)
+#define BTA_EN BIT(2)
+#define EOTP_RX_EN BIT(1)
+#define EOTP_TX_EN BIT(0)
+
+#define DSI_GEN_VCID   0x30
+
+#define DSI_MODE_CFG   0x34
+#define ENABLE_VIDEO_MODE  0
+#define ENABLE_CMD_MODEBIT(0)
+
+#define DSI_VID_MODE_CFG   0x38
+#define ENABLE_LOW_POWER   (0x3f << 8)
+#define ENABLE_LOW_POWER_MASK  (0x3f << 8)
+#define VID_MODE_TYPE_NON_BURST_SYNC_PULSES0x0
+#define VID_MODE_TYPE_NON_BURST_SYNC_EVENTS0x1
+#define VID_MODE_TYPE_BURST0x2
+#define VID_MODE_TYPE_MASK 0x3
+
+#define 

[U-Boot] [ v1 05/10] video: add support of panel RM68200

2018-07-12 Thread Yannick Fertré
Support for Raydium RM68200 720p dsi 2dl video mode panel.
This rm68200 panel driver is based on the Linux Kernel driver from
drivers/gpu/drm/panel/panel-raydium-rm68200.c.

Signed-off-by: Yannick Fertré 
---
 drivers/video/Kconfig   |   8 +
 drivers/video/Makefile  |   1 +
 drivers/video/raydium-rm68200.c | 338 
 3 files changed, 347 insertions(+)
 create mode 100644 drivers/video/raydium-rm68200.c

diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 8a168c8..e1029e5 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -337,6 +337,14 @@ config VIDEO_LCD_ORISETECH_OTM8009A
help
  Support for Orise Tech otm8009a 480p dsi 2dl video mode panel.
 
+config VIDEO_LCD_RAYDIUM_RM68200
+   bool "RM68200 DSI LCD panel support"
+   depends on DM_VIDEO
+   select VIDEO_MIPI_DSI
+   default n
+   help
+ Support for Raydium rm68200 720x1280 dsi 2dl video mode panel.
+
 config VIDEO_LCD_SSD2828
bool "SSD2828 bridge chip"
default n
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index b9d7d81..018343f 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -36,6 +36,7 @@ obj-$(CONFIG_VIDEO_EFI) += efi.o
 obj-$(CONFIG_VIDEO_LCD_ANX9804) += anx9804.o
 obj-$(CONFIG_VIDEO_LCD_HITACHI_TX18D42VM) += hitachi_tx18d42vm_lcd.o
 obj-$(CONFIG_VIDEO_LCD_ORISETECH_OTM8009A) += orisetech_otm8009a.o
+obj-$(CONFIG_VIDEO_LCD_RAYDIUM_RM68200) += raydium-rm68200.o
 obj-$(CONFIG_VIDEO_LCD_SSD2828) += ssd2828.o
 obj-$(CONFIG_VIDEO_MB862xx) += mb862xx.o videomodes.o
 obj-$(CONFIG_VIDEO_MX3) += mx3fb.o videomodes.o
diff --git a/drivers/video/raydium-rm68200.c b/drivers/video/raydium-rm68200.c
new file mode 100644
index 000..b0b10c1
--- /dev/null
+++ b/drivers/video/raydium-rm68200.c
@@ -0,0 +1,338 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2018 STMicroelectronics - All Rights Reserved
+ * Author(s): Yannick Fertre  for STMicroelectronics.
+ *Philippe Cornu  for STMicroelectronics.
+ *
+ * This rm68200 panel driver is inspired from the Linux Kernel driver
+ * drivers/gpu/drm/panel/panel-raydium-rm68200.c.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/*** Manufacturer Command Set ***/
+#define MCS_CMD_MODE_SW0xFE /* CMD Mode Switch */
+#define MCS_CMD1_UCS   0x00 /* User Command Set (UCS = CMD1) */
+#define MCS_CMD2_P00x01 /* Manufacture Command Set Page0 (CMD2 P0) */
+#define MCS_CMD2_P10x02 /* Manufacture Command Set Page1 (CMD2 P1) */
+#define MCS_CMD2_P20x03 /* Manufacture Command Set Page2 (CMD2 P2) */
+#define MCS_CMD2_P30x04 /* Manufacture Command Set Page3 (CMD2 P3) */
+
+/* CMD2 P0 commands (Display Options and Power) */
+#define MCS_STBCTR 0x12 /* TE1 Output Setting Zig-Zag Connection */
+#define MCS_SGOPCTR0x16 /* Source Bias Current */
+#define MCS_SDCTR  0x1A /* Source Output Delay Time */
+#define MCS_INVCTR 0x1B /* Inversion Type */
+#define MCS_EXT_PWR_IC 0x24 /* External PWR IC Control */
+#define MCS_SETAVDD0x27 /* PFM Control for AVDD Output */
+#define MCS_SETAVEE0x29 /* PFM Control for AVEE Output */
+#define MCS_BT2CTR 0x2B /* DDVDL Charge Pump Control */
+#define MCS_BT3CTR 0x2F /* VGH Charge Pump Control */
+#define MCS_BT4CTR 0x34 /* VGL Charge Pump Control */
+#define MCS_VCMCTR 0x46 /* VCOM Output Level Control */
+#define MCS_SETVGN 0x52 /* VG M/S N Control */
+#define MCS_SETVGP 0x54 /* VG M/S P Control */
+#define MCS_SW_CTRL0x5F /* Interface Control for PFM and MIPI */
+
+/* CMD2 P2 commands (GOA Timing Control) - no description in datasheet */
+#define GOA_VSTV1  0x00
+#define GOA_VSTV2  0x07
+#define GOA_VCLK1  0x0E
+#define GOA_VCLK2  0x17
+#define GOA_VCLK_OPT1  0x20
+#define GOA_BICLK1 0x2A
+#define GOA_BICLK2 0x37
+#define GOA_BICLK3 0x44
+#define GOA_BICLK4 0x4F
+#define GOA_BICLK_OPT1 0x5B
+#define GOA_BICLK_OPT2 0x60
+#define MCS_GOA_GPO1   0x6D
+#define MCS_GOA_GPO2   0x71
+#define MCS_GOA_EQ 0x74
+#define MCS_GOA_CLK_GALLON 0x7C
+#define MCS_GOA_FS_SEL00x7E
+#define MCS_GOA_FS_SEL10x87
+#define MCS_GOA_FS_SEL20x91
+#define MCS_GOA_FS_SEL30x9B
+#define MCS_GOA_BS_SEL00xAC
+#define MCS_GOA_BS_SEL10xB5
+#define MCS_GOA_BS_SEL20xBF
+#define MCS_GOA_BS_SEL30xC9
+#define MCS_GOA_BS_SEL40xD3
+
+/* CMD2 P3 commands (Gamma) */
+#define MCS_GAMMA_VP   0x60 /* Gamma VP1~VP16 */
+#define MCS_GAMMA_VN   0x70 /* Gamma VN1~VN16 */
+
+struct rm68200_panel_priv {
+   struct udevice *reg;
+   struct udevice *backlight;
+   struct gpio_desc reset;
+};
+
+static const struct display_timing 

[U-Boot] [ v1 04/10] video: add support of panel OTM8009A

2018-07-12 Thread Yannick Fertré
Support for Orise Tech otm8009a 480p dsi 2dl video mode panel.

Signed-off-by: Yannick Fertré 
---
 drivers/video/Kconfig  |   8 +
 drivers/video/Makefile |   1 +
 drivers/video/orisetech_otm8009a.c | 366 +
 3 files changed, 375 insertions(+)
 create mode 100644 drivers/video/orisetech_otm8009a.c

diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 560da1a..8a168c8 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -329,6 +329,14 @@ config VIDEO_LCD_ANX9804
from a parallel LCD interface and translate it on the fy into a DP
interface for driving eDP TFT displays. It uses I2C for configuration.
 
+config VIDEO_LCD_ORISETECH_OTM8009A
+   bool "OTM8009A DSI LCD panel support"
+   depends on DM_VIDEO
+   select VIDEO_MIPI_DSI
+   default n
+   help
+ Support for Orise Tech otm8009a 480p dsi 2dl video mode panel.
+
 config VIDEO_LCD_SSD2828
bool "SSD2828 bridge chip"
default n
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index 4e2ec41..b9d7d81 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -35,6 +35,7 @@ obj-$(CONFIG_VIDEO_DA8XX) += da8xx-fb.o videomodes.o
 obj-$(CONFIG_VIDEO_EFI) += efi.o
 obj-$(CONFIG_VIDEO_LCD_ANX9804) += anx9804.o
 obj-$(CONFIG_VIDEO_LCD_HITACHI_TX18D42VM) += hitachi_tx18d42vm_lcd.o
+obj-$(CONFIG_VIDEO_LCD_ORISETECH_OTM8009A) += orisetech_otm8009a.o
 obj-$(CONFIG_VIDEO_LCD_SSD2828) += ssd2828.o
 obj-$(CONFIG_VIDEO_MB862xx) += mb862xx.o videomodes.o
 obj-$(CONFIG_VIDEO_MX3) += mx3fb.o videomodes.o
diff --git a/drivers/video/orisetech_otm8009a.c 
b/drivers/video/orisetech_otm8009a.c
new file mode 100644
index 000..c5a1ee4
--- /dev/null
+++ b/drivers/video/orisetech_otm8009a.c
@@ -0,0 +1,366 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2018 STMicroelectronics - All Rights Reserved
+ * Author(s): Yannick Fertre  for STMicroelectronics.
+ *Philippe Cornu  for STMicroelectronics.
+ *
+ * This otm8009a panel driver is inspired from the Linux Kernel driver
+ * drivers/gpu/drm/panel/panel-orisetech-otm8009a.c.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define OTM8009A_BACKLIGHT_DEFAULT 240
+#define OTM8009A_BACKLIGHT_MAX 255
+
+/* Manufacturer Command Set */
+#define MCS_ADRSFT 0x  /* Address Shift Function */
+#define MCS_PANSET 0xB3A6  /* Panel Type Setting */
+#define MCS_SD_CTRL0xC0A2  /* Source Driver Timing Setting */
+#define MCS_P_DRV_M0xC0B4  /* Panel Driving Mode */
+#define MCS_OSC_ADJ0xC181  /* Oscillator Adjustment for Idle/Normal mode */
+#define MCS_RGB_VID_SET0xC1A1  /* RGB Video Mode Setting */
+#define MCS_SD_PCH_CTRL0xC480  /* Source Driver Precharge Control */
+#define MCS_NO_DOC10xC48A  /* Command not documented */
+#define MCS_PWR_CTRL1  0xC580  /* Power Control Setting 1 */
+#define MCS_PWR_CTRL2  0xC590  /* Power Control Setting 2 for Normal Mode */
+#define MCS_PWR_CTRL4  0xC5B0  /* Power Control Setting 4 for DC Voltage */
+#define MCS_PANCTRLSET10xCB80  /* Panel Control Setting 1 */
+#define MCS_PANCTRLSET20xCB90  /* Panel Control Setting 2 */
+#define MCS_PANCTRLSET30xCBA0  /* Panel Control Setting 3 */
+#define MCS_PANCTRLSET40xCBB0  /* Panel Control Setting 4 */
+#define MCS_PANCTRLSET50xCBC0  /* Panel Control Setting 5 */
+#define MCS_PANCTRLSET60xCBD0  /* Panel Control Setting 6 */
+#define MCS_PANCTRLSET70xCBE0  /* Panel Control Setting 7 */
+#define MCS_PANCTRLSET80xCBF0  /* Panel Control Setting 8 */
+#define MCS_PANU2D10xCC80  /* Panel U2D Setting 1 */
+#define MCS_PANU2D20xCC90  /* Panel U2D Setting 2 */
+#define MCS_PANU2D30xCCA0  /* Panel U2D Setting 3 */
+#define MCS_PAND2U10xCCB0  /* Panel D2U Setting 1 */
+#define MCS_PAND2U20xCCC0  /* Panel D2U Setting 2 */
+#define MCS_PAND2U30xCCD0  /* Panel D2U Setting 3 */
+#define MCS_GOAVST 0xCE80  /* GOA VST Setting */
+#define MCS_GOACLKA1   0xCEA0  /* GOA CLKA1 Setting */
+#define MCS_GOACLKA3   0xCEB0  /* GOA CLKA3 Setting */
+#define MCS_GOAECLK0xCFC0  /* GOA ECLK Setting */
+#define MCS_NO_DOC20xCFD0  /* Command not documented */
+#define MCS_GVDDSET0xD800  /* GVDD/NGVDD */
+#define MCS_VCOMDC 0xD900  /* VCOM Voltage Setting */
+#define MCS_GMCT2_2P   0xE100  /* Gamma Correction 2.2+ Setting */
+#define MCS_GMCT2_2N   0xE200  /* Gamma Correction 2.2- Setting */
+#define MCS_NO_DOC30xF5B6  /* Command not documented */
+#define MCS_CMD2_ENA1  0xFF00  /* Enable Access Command2 "CMD2" */
+#define MCS_CMD2_ENA2  0xFF80  /* Enable Access Orise Command2 */
+
+struct otm8009a_panel_priv {
+   struct udevice *reg;
+   struct gpio_desc reset;
+};
+
+static const struct display_timing default_timing = {
+   .pixelclock.typ = 32729000,
+   .hactive.typ= 480,
+   

[U-Boot] [ v1 09/10] arm: dts: stm32: add display for STM32F769 disco board

2018-07-12 Thread Yannick Fertré
Enable the display controller, mipi dsi bridge & panel.
Set panel display timings.

Signed-off-by: Yannick Fertré 
---
 arch/arm/dts/stm32f769-disco.dts | 59 
 1 file changed, 59 insertions(+)

diff --git a/arch/arm/dts/stm32f769-disco.dts b/arch/arm/dts/stm32f769-disco.dts
index 59c9d31..93659f7 100644
--- a/arch/arm/dts/stm32f769-disco.dts
+++ b/arch/arm/dts/stm32f769-disco.dts
@@ -84,6 +84,36 @@
compatible = "st,button1";
button-gpio = < 0 0>;
};
+
+   panel: panel {
+   compatible = "orisetech,otm8009a";
+   reset-gpios = < 15 1>;
+   status = "okay";
+
+   port {
+   panel_in: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+
+   display-timings {
+   timing@0 {
+   clock-frequency = <32729000>;
+   hactive = <480>;
+   hfront-porch = <120>;
+   hback-porch = <63>;
+   hsync-len = <120>;
+   vactive = <800>;
+   vfront-porch = <12>;
+   vback-porch = <12>;
+   vsync-len = <12>;
+   hsync-active = <0>;
+   vsync-active = <0>;
+   de-active = <0>;
+   pixelclk-active = <1>;
+   };
+   };
+   };
 };
 
 _hse {
@@ -264,3 +294,32 @@
bus-width = <4>;
max-frequency = <2500>;
 };
+
+ {
+   status = "okay";
+
+   ports {
+   port@0 {
+   dp_out: endpoint {
+   remote-endpoint = <_in>;
+   };
+   };
+   };
+};
+
+ {
+   status = "okay";
+
+   ports {
+   port@0 {
+   dsi_out: endpoint {
+   remote-endpoint = <_in>;
+   };
+   };
+   port@1 {
+   dsi_in: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+   };
+};
-- 
1.9.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [ v1 02/10] video: add support of MIPI DSI interface

2018-07-12 Thread Yannick Fertré
Mipi_display.c contains a set of dsi helpers.
This file is a copy of file drm_mipi_dsi.c (linux kernel).

Signed-off-by: Yannick Fertré 
---
 drivers/video/Kconfig|   9 +
 drivers/video/Makefile   |   1 +
 drivers/video/mipi_display.c | 817 +++
 include/mipi_display.h   | 257 +-
 4 files changed, 1083 insertions(+), 1 deletion(-)
 create mode 100644 drivers/video/mipi_display.c

diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 5ee9032..560da1a 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -73,6 +73,15 @@ config VIDEO_ANSI
  Enable ANSI escape sequence decoding for a more fully functional
  console.
 
+config VIDEO_MIPI_DSI
+   bool "Support MIPI DSI interface"
+   depends on DM_VIDEO
+   default y if DM_VIDEO
+   help
+ Support MIPI DSI interface for driving a MIPI compatible device.
+ The MIPI Display Serial Interface (MIPI DSI) defines a high-speed
+ serial interface between a host processor and a display module.
+
 config CONSOLE_NORMAL
bool "Support a simple text console"
depends on DM_VIDEO
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index 7c89c67..4e2ec41 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -50,6 +50,7 @@ obj-$(CONFIG_FORMIKE) += formike.o
 obj-$(CONFIG_LG4573) += lg4573.o
 obj-$(CONFIG_AM335X_LCD) += am335x-fb.o
 obj-$(CONFIG_VIDEO_DW_HDMI) += dw_hdmi.o
+obj-${CONFIG_VIDEO_MIPI_DSI} += mipi_display.o
 obj-$(CONFIG_VIDEO_SIMPLE) += simplefb.o
 obj-${CONFIG_VIDEO_TEGRA124} += tegra124/
 obj-${CONFIG_EXYNOS_FB} += exynos/
diff --git a/drivers/video/mipi_display.c b/drivers/video/mipi_display.c
new file mode 100644
index 000..9c96b9d
--- /dev/null
+++ b/drivers/video/mipi_display.c
@@ -0,0 +1,817 @@
+/*
+ * MIPI DSI Bus
+ *
+ * Copyright (C) 2012-2013, Samsung Electronics, Co., Ltd.
+ * Copyright (C) 2018 STMicroelectronics - All Rights Reserved
+ * Andrzej Hajda 
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the
+ * "Software"), to deal in the Software without restriction, including
+ * without limitation the rights to use, copy, modify, merge, publish,
+ * distribute, sub license, and/or sell copies of the Software, and to
+ * permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the
+ * next paragraph) shall be included in all copies or substantial portions
+ * of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDERS, AUTHORS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM,
+ * DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
+ * OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE
+ * USE OR OTHER DEALINGS IN THE SOFTWARE.
+ *
+ * Mipi_display.c contains a set of dsi helpers.
+ * This file is inspired from the drm helper file 
drivers/gpu/drm/drm_mipi_dsi.c
+ * (kernel linux).
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/**
+ * DOC: dsi helpers
+ *
+ * These functions contain some common logic and helpers to deal with MIPI DSI
+ * peripherals.
+ *
+ * Helpers are provided for a number of standard MIPI DSI command as well as a
+ * subset of the MIPI DCS command set.
+ */
+
+/**
+ * mipi_dsi_attach - attach a DSI device to its DSI host
+ * @dsi: DSI peripheral
+ */
+int mipi_dsi_attach(struct mipi_dsi_device *dsi)
+{
+   const struct mipi_dsi_host_ops *ops = dsi->host->ops;
+
+   if (!ops || !ops->attach)
+   return -ENOSYS;
+
+   return ops->attach(dsi->host, dsi);
+}
+EXPORT_SYMBOL(mipi_dsi_attach);
+
+/**
+ * mipi_dsi_detach - detach a DSI device from its DSI host
+ * @dsi: DSI peripheral
+ */
+int mipi_dsi_detach(struct mipi_dsi_device *dsi)
+{
+   const struct mipi_dsi_host_ops *ops = dsi->host->ops;
+
+   if (!ops || !ops->detach)
+   return -ENOSYS;
+
+   return ops->detach(dsi->host, dsi);
+}
+EXPORT_SYMBOL(mipi_dsi_detach);
+
+/**
+ * mipi_dsi_device_transfer - transfer message to a DSI device
+ * @dsi: DSI peripheral
+ * @msg: message
+ */
+static ssize_t mipi_dsi_device_transfer(struct mipi_dsi_device *dsi,
+   struct mipi_dsi_msg *msg)
+{
+   const struct mipi_dsi_host_ops *ops = dsi->host->ops;
+
+   if (!ops || !ops->transfer)
+   return -ENOSYS;
+
+   if (dsi->mode_flags & MIPI_DSI_MODE_LPM)
+   msg->flags |= MIPI_DSI_MSG_USE_LPM;
+
+   return ops->transfer(dsi->host, msg);
+}
+
+/**
+ * mipi_dsi_packet_format_is_short - check if a packet is of 

[U-Boot] [ v1 03/10] dm: panel: get timings from panel

2018-07-12 Thread Yannick Fertré
Get timings from panel instead of read device tree.

Signed-off-by: Yannick Fertré 
---
 drivers/video/panel-uclass.c | 11 +++
 include/panel.h  | 18 ++
 2 files changed, 29 insertions(+)

diff --git a/drivers/video/panel-uclass.c b/drivers/video/panel-uclass.c
index 2841bb3..aec44a8 100644
--- a/drivers/video/panel-uclass.c
+++ b/drivers/video/panel-uclass.c
@@ -18,6 +18,17 @@ int panel_enable_backlight(struct udevice *dev)
return ops->enable_backlight(dev);
 }
 
+int panel_get_display_timing(struct udevice *dev,
+struct display_timing *timings)
+{
+   struct panel_ops *ops = panel_get_ops(dev);
+
+   if (!ops->get_display_timing)
+   return -ENOSYS;
+
+   return ops->get_display_timing(dev, timings);
+}
+
 UCLASS_DRIVER(panel) = {
.id = UCLASS_PANEL,
.name   = "panel",
diff --git a/include/panel.h b/include/panel.h
index 46dca48b..6237d32 100644
--- a/include/panel.h
+++ b/include/panel.h
@@ -15,6 +15,15 @@ struct panel_ops {
 * @return 0 if OK, -ve on error
 */
int (*enable_backlight)(struct udevice *dev);
+   /**
+* get_timings() - Get display timings from panel.
+*
+* @dev:Panel device containing the display timings
+* @tim:Place to put timings
+* @return 0 if OK, -ve on error
+*/
+   int (*get_display_timing)(struct udevice *dev,
+ struct display_timing *timing);
 };
 
 #define panel_get_ops(dev) ((struct panel_ops *)(dev)->driver->ops)
@@ -27,4 +36,13 @@ struct panel_ops {
  */
 int panel_enable_backlight(struct udevice *dev);
 
+/**
+ * panel_get_display_timing() - Get display timings from panel.
+ *
+ * @dev:   Panel device containing the display timings
+ * @return 0 if OK, -ve on error
+ */
+int panel_get_display_timing(struct udevice *dev,
+struct display_timing *timing);
+
 #endif
-- 
1.9.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [ v1 01/10] video: stm32: stm32_ltdc: add bridge to display controller

2018-07-12 Thread Yannick Fertré
Manage a bridge insert between the display controller & a panel.

Signed-off-by: Yannick Fertré 
---
 drivers/video/stm32/stm32_ltdc.c | 154 +++
 1 file changed, 92 insertions(+), 62 deletions(-)

diff --git a/drivers/video/stm32/stm32_ltdc.c b/drivers/video/stm32/stm32_ltdc.c
index dc6c889..4a1db5e 100644
--- a/drivers/video/stm32/stm32_ltdc.c
+++ b/drivers/video/stm32/stm32_ltdc.c
@@ -4,22 +4,20 @@
  * Author(s): Philippe Cornu  for STMicroelectronics.
  *   Yannick Fertre  for STMicroelectronics.
  */
-
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 
-DECLARE_GLOBAL_DATA_PTR;
-
 struct stm32_ltdc_priv {
void __iomem *regs;
-   struct display_timing timing;
enum video_log2_bpp l2bpp;
u32 bg_col_argb;
u32 crop_x, crop_y, crop_w, crop_h;
@@ -174,8 +172,8 @@ static u32 stm32_ltdc_get_pixel_format(enum video_log2_bpp 
l2bpp)
case VIDEO_BPP2:
case VIDEO_BPP4:
default:
-   debug("%s: warning %dbpp not supported yet, %dbpp instead\n",
- __func__, VNBITS(l2bpp), VNBITS(VIDEO_BPP16));
+   pr_warn("%s: warning %dbpp not supported yet, %dbpp instead\n",
+   __func__, VNBITS(l2bpp), VNBITS(VIDEO_BPP16));
pf = PF_RGB565;
break;
}
@@ -209,23 +207,23 @@ static void stm32_ltdc_enable(struct stm32_ltdc_priv 
*priv)
setbits_le32(priv->regs + LTDC_GCR, GCR_LTDCEN);
 }
 
-static void stm32_ltdc_set_mode(struct stm32_ltdc_priv *priv)
+static void stm32_ltdc_set_mode(struct stm32_ltdc_priv *priv,
+   struct display_timing *timings)
 {
void __iomem *regs = priv->regs;
-   struct display_timing *timing = >timing;
u32 hsync, vsync, acc_hbp, acc_vbp, acc_act_w, acc_act_h;
u32 total_w, total_h;
u32 val;
 
/* Convert video timings to ltdc timings */
-   hsync = timing->hsync_len.typ - 1;
-   vsync = timing->vsync_len.typ - 1;
-   acc_hbp = hsync + timing->hback_porch.typ;
-   acc_vbp = vsync + timing->vback_porch.typ;
-   acc_act_w = acc_hbp + timing->hactive.typ;
-   acc_act_h = acc_vbp + timing->vactive.typ;
-   total_w = acc_act_w + timing->hfront_porch.typ;
-   total_h = acc_act_h + timing->vfront_porch.typ;
+   hsync = timings->hsync_len.typ - 1;
+   vsync = timings->vsync_len.typ - 1;
+   acc_hbp = hsync + timings->hback_porch.typ;
+   acc_vbp = vsync + timings->vback_porch.typ;
+   acc_act_w = acc_hbp + timings->hactive.typ;
+   acc_act_h = acc_vbp + timings->vactive.typ;
+   total_w = acc_act_w + timings->hfront_porch.typ;
+   total_h = acc_act_h + timings->vfront_porch.typ;
 
/* Synchronization sizes */
val = (hsync << 16) | vsync;
@@ -247,14 +245,14 @@ static void stm32_ltdc_set_mode(struct stm32_ltdc_priv 
*priv)
 
/* Signal polarities */
val = 0;
-   debug("%s: timing->flags 0x%08x\n", __func__, timing->flags);
-   if (timing->flags & DISPLAY_FLAGS_HSYNC_HIGH)
+   debug("%s: timing->flags 0x%08x\n", __func__, timings->flags);
+   if (timings->flags & DISPLAY_FLAGS_HSYNC_HIGH)
val |= GCR_HSPOL;
-   if (timing->flags & DISPLAY_FLAGS_VSYNC_HIGH)
+   if (timings->flags & DISPLAY_FLAGS_VSYNC_HIGH)
val |= GCR_VSPOL;
-   if (timing->flags & DISPLAY_FLAGS_DE_HIGH)
+   if (timings->flags & DISPLAY_FLAGS_DE_HIGH)
val |= GCR_DEPOL;
-   if (timing->flags & DISPLAY_FLAGS_PIXDATA_NEGEDGE)
+   if (timings->flags & DISPLAY_FLAGS_PIXDATA_NEGEDGE)
val |= GCR_PCPOL;
clrsetbits_le32(regs + LTDC_GCR,
GCR_HSPOL | GCR_VSPOL | GCR_DEPOL | GCR_PCPOL, val);
@@ -330,96 +328,128 @@ static int stm32_ltdc_probe(struct udevice *dev)
struct video_uc_platdata *uc_plat = dev_get_uclass_platdata(dev);
struct video_priv *uc_priv = dev_get_uclass_priv(dev);
struct stm32_ltdc_priv *priv = dev_get_priv(dev);
-   struct udevice *panel;
+#ifdef CONFIG_VIDEO_BRIDGE
+   struct udevice *bridge = NULL;
+#endif
+   struct udevice *panel = NULL;
+   struct display_timing timings;
struct clk pclk;
struct reset_ctl rst;
-   int rate, ret;
+   int ret;
 
priv->regs = (void *)dev_read_addr(dev);
if ((fdt_addr_t)priv->regs == FDT_ADDR_T_NONE) {
-   debug("%s: ltdc dt register address error\n", __func__);
+   dev_err(dev, "ltdc dt register address error\n");
return -EINVAL;
}
 
ret = clk_get_by_index(dev, 0, );
if (ret) {
-   debug("%s: peripheral clock get error %d\n", __func__, ret);
+   dev_err(dev, "peripheral clock get error %d\n", ret);
return ret;
}
 
ret = clk_enable();
if 

[U-Boot] [ v1 00/10] [INTERNAL REVIEW] splash screen on the stm32f769 disco board

2018-07-12 Thread Yannick Fertré
Version 1:
- Initial commit:

This serie contains all patchsets needed for displaying a splash screen 
on the stm32f769 disco board.
A new config has been created configs/stm32f769-disco_defconfig.
This is necessary due to the difference of panels between stm32f769-disco &
stm32f746-disco boards.

Yannick Fertré (10):
  video: stm32: stm32_ltdc: add bridge to display controller
  video: add support of MIPI DSI interface
  dm: panel: get timings  from panel
  video: add support of panel OTM8009A
  video: add support of panel RM68200
  video: add MIPI DSI host controller bridge
  video: add support of STM32 MIPI DSI controller driver
  arm: dts: stm32: add dsi for STM32F746
  arm: dts: stm32: add display for STM32F769 disco board
  board: Add STM32F769 SoC, discovery board support

 arch/arm/dts/stm32f746.dtsi|  12 +
 arch/arm/dts/stm32f769-disco.dts   |  59 +++
 configs/stm32f769-disco_defconfig  |  67 +++
 drivers/video/Kconfig  |  34 ++
 drivers/video/Makefile |   4 +
 drivers/video/dw_mipi_dsi.c| 826 +
 drivers/video/mipi_display.c   | 817 
 drivers/video/orisetech_otm8009a.c | 366 
 drivers/video/panel-uclass.c   |  11 +
 drivers/video/raydium-rm68200.c| 338 +++
 drivers/video/stm32/Kconfig|  10 +
 drivers/video/stm32/Makefile   |   1 +
 drivers/video/stm32/stm32_dsi.c| 427 +++
 drivers/video/stm32/stm32_ltdc.c   | 154 ---
 include/dw_mipi_dsi.h  |  32 ++
 include/mipi_display.h | 257 +++-
 include/panel.h|  18 +
 17 files changed, 3370 insertions(+), 63 deletions(-)
 create mode 100644 configs/stm32f769-disco_defconfig
 create mode 100644 drivers/video/dw_mipi_dsi.c
 create mode 100644 drivers/video/mipi_display.c
 create mode 100644 drivers/video/orisetech_otm8009a.c
 create mode 100644 drivers/video/raydium-rm68200.c
 create mode 100644 drivers/video/stm32/stm32_dsi.c
 create mode 100644 include/dw_mipi_dsi.h

-- 
1.9.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] ls1021a: problem with errata A009007

2018-07-12 Thread Ran Wang
Hi Heiko

> -Original Message-

> >> Subject: ls1021a: problem with errata A009007
> >>
> >> Hello Ran Wang,
> >>
> >> I have ported successfully U-Boot to an ls1021a based board and works
> >> nice for the HW I have access to.
> >>
> >> Now the customer reports problems on his HW with
> >> SYS_FSL_ERRATUM_A009007
> >> which is always activated.
> >>
> >> Board does not boot, and crashes in erratum_a009007()
> >>
> >> (Sorry I have no logs ... nor access to this HW)
> >>
> >> Disabling this function, and U-Boot boots ...
> >>
> >> Customer states/confirmed me, that he has the same HW ...
> >>
> >> On the board USB is not used.
> >>
> >> Any ideas hints what can be wrong here?
> >>
> > I just re-reverified on  latest upstream U-Boot with LS1021ATWR board. It
> worked fine.
> > You might need to know what kind of crash they encountered:
> 
> I am sorry ... no debugger there ...
> 
> > 1. That erratum workaround programming will happen before the UART
> > print activated, that means no log will show when writing those register,
> how does then know the crash?
> 
> Good question ... they removed the erratum_a009007() function, and SPL /
> U-Boot booted fine ... but I think currently, the HW is bogus ...
> I cannot verify this with the HW i have ...
> 

One simple way to verify if has HW issue on this programming is to manually do 
it with command mm.w:

Disable 9007 workaround, boot to U-Boot console:
=> md 851200c 1
0851200c:    
=> mm.w 851200c
0851200c: 800c ? 0
0851200e:  ? q
=> mm.w 851200c
0851200c: 800c ? 8000
0851200e:  ? q
=> mm.w 851200c
0851200c: 800c ? 8004
0851200e:  ? q
=> mm.w 851200c
0851200c: 800c ? 800c
0851200e:  ? q

See if system will crash.

> > 2.  Except erratum programming, USB controller (xHCI) will NOT be
> initialized untill U-Boot command 'usb start'
> > is executed. That means if user didn't type 'usb start', USB IP will not 
> > begin
> to work at all.
> 
> Yes, and on the board USB is not used at all...
> 

If customer board doesn't have USB port, you can unselect all USB errata 
workaround directly.

> > 3. Anyway, this erratum is used to pass USB compliance test only, you
> > could disable this workaround on your board if you don't any USB issue on
> normal use case, I think it's fine.
> 
> Thanks for your clarification!
> 
Welcome

Ran
> --
> DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: h...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] Pull request: u-boot-ubi/master

2018-07-12 Thread Heiko Schocher

Hello Tom,

please pull from u-boot-ubi.git master

The following changes since commit 1612ff0dfba57b1002d8c7a54778eb553ace98f4:

  Merge branch 'master' of git://git.denx.de/u-boot-mips (2018-07-11 21:55:20 
-0400)

are available in the Git repository at:

  git://git.denx.de/u-boot-ubi.git master

for you to fetch changes up to 5a08cfee3967d6e8174d7de135af1daa8e4aea00:

  ubifs: remove useless code (2018-07-12 07:27:34 +0200)


Christophe Kerello (1):
  ubifs: remove useless code

Stefan Agner (1):
  cmd: ubi: print load size after establishing volume size

Stefan Roese (1):
  cmd: ubi: Add additional message upon UBI attach error

 cmd/ubi.c| 6 +++---
 fs/ubifs/super.c | 8 
 fs/ubifs/ubifs.h | 2 +-
 3 files changed, 8 insertions(+), 8 deletions(-)

Travis build fine:
https://travis-ci.org/hsdenx/u-boot-ubi/builds/402965000

bye,
Heiko
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: h...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v1] cmd: ubi: print load size after establishing volume size

2018-07-12 Thread Heiko Schocher

Hello Stefan,

Am 25.06.2018 um 11:19 schrieb Stefan Agner:

From: Stefan Agner 

When using static volumes, the file size stored in the volume is
determined at runtime. Currently the ubi command prints the file
size specified on the console, which leads to a rather confusing
series of messages:
   # ubi read ${fdt_addr_r} testvol
   Read 0 bytes from volume testvol to 8200
   No size specified -> Using max size (179924992)

Make sure to print the actual size read in any case:
   # ubi read ${fdt_addr_r} testvol
   No size specified -> Using max size (179924992)
   Read 179924992 bytes from volume testvol to 8200

Signed-off-by: Stefan Agner 
---

  cmd/ubi.c | 5 ++---
  1 file changed, 2 insertions(+), 3 deletions(-)


applied to u-boot-ubi.git master

Thanks!

bye,
Heiko
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: h...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH] cmd: ubi: Add additional message upon UBI attach error

2018-07-12 Thread Heiko Schocher

Hello Stefan,

Am 26.06.2018 um 08:12 schrieb Stefan Roese:

When trying to attach an UBI MTD partition via "ubi part", it may happen
that the MTD partition defined in U-Boot (via mtdparts) is not big
enough than the one, where the UBI device has been created on. This
may lead to errors, which are not really descriptive to debug and
solve this issue, like:

ubi0 error: vtbl_check: too large reserved_pebs 1982, good PEBs 1020
ubi0 error: vtbl_check: volume table check failed: record 0, error 9

or:

ubi0 error: init_volumes: not enough PEBs, required 1738, available 1020
ubi0 error: ubi_wl_init: no enough physical eraseblocks (-718, need 1)
ubi0 error: ubi_attach_mtd_dev: failed to attach mtd1, error -12

Lets add an additional message upon attach failure, to aid the U-Boot
user to solve this problem.

Signed-off-by: Stefan Roese 
Cc: Stefano Babic 
Cc: Heiko Schocher 
---
  cmd/ubi.c | 1 +
  1 file changed, 1 insertion(+)


applied to u-boot-ubi.git master

Thanks!

bye,
Heiko
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: h...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH] ubifs: remove useless code

2018-07-12 Thread Heiko Schocher

Hello Patrice,

Am 27.06.2018 um 10:06 schrieb Patrice Chotard:

From: Christophe Kerello 

By checking ubifs source code, s_instances parameter is not
used anymore. So, set this parameter and the associated source
code under __UBOOT__ compilation.

Signed-off-by: Christophe Kerello 
Signed-off-by: Patrice Chotard 
---

  fs/ubifs/super.c | 8 
  fs/ubifs/ubifs.h | 2 +-
  2 files changed, 5 insertions(+), 5 deletions(-)


applied to u-boot-ubi.git master

Thanks!

bye,
Heiko
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: h...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v1 0/5] board: toradex: add Colibri iMX6ULL support

2018-07-12 Thread Stefan Agner
On 30.05.2018 19:01, Stefan Agner wrote:
> From: Stefan Agner 
> 
> This patchset adds Toradex Colibri iMX6ULL support. It makes
> use of the device tree support for the MXS NAND driver and
> hence depends on:
> https://patchwork.ozlabs.org/cover/897263/
> https://patchwork.ozlabs.org/cover/901995/
> 

FWIW, the above dependencies are now part of v2018.07. This still
applies cleanly on v2018.07 so I guess I don't have to resend.

--
Stefan

> --
> Stefan
> 
> 
> Stefan Agner (5):
>   mtd: nand: mxs_nand: add device tree support for i.MX 6
>   imx: add macro to detect whether USB has been initialized
>   ARM: dts: imx6ull: use same compatible string as Linux is using
>   board: toradex: add new and upcoming SKUs
>   board: toradex: add Colibri iMX6ULL support
> 
>  arch/arm/dts/imx6ull-colibri.dts  | 550 ++
>  arch/arm/dts/imx6ull.dtsi |   2 +-
>  arch/arm/include/asm/arch-mx6/imx-regs.h  |   7 +
>  arch/arm/mach-imx/mx6/Kconfig |   8 +
>  board/toradex/colibri-imx6ull/Kconfig |  29 +
>  board/toradex/colibri-imx6ull/MAINTAINERS |  10 +
>  board/toradex/colibri-imx6ull/Makefile|   4 +
>  .../toradex/colibri-imx6ull/colibri-imx6ull.c | 408 +
>  board/toradex/colibri-imx6ull/imximage.cfg| 106 
>  board/toradex/common/tdx-cfg-block.c  |   7 +
>  board/toradex/common/tdx-cfg-block.h  |   7 +
>  configs/colibri-imx6ull_defconfig |  76 +++
>  drivers/mtd/nand/mxs_nand_dt.c|   8 +
>  include/configs/colibri-imx6ull.h | 199 +++
>  14 files changed, 1420 insertions(+), 1 deletion(-)
>  create mode 100644 arch/arm/dts/imx6ull-colibri.dts
>  create mode 100644 board/toradex/colibri-imx6ull/Kconfig
>  create mode 100644 board/toradex/colibri-imx6ull/MAINTAINERS
>  create mode 100644 board/toradex/colibri-imx6ull/Makefile
>  create mode 100644 board/toradex/colibri-imx6ull/colibri-imx6ull.c
>  create mode 100644 board/toradex/colibri-imx6ull/imximage.cfg
>  create mode 100644 configs/colibri-imx6ull_defconfig
>  create mode 100644 include/configs/colibri-imx6ull.h
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] UBI fixable bit-flip issue

2018-07-12 Thread Richard Weinberger
Mark,

Am Donnerstag, 12. Juli 2018, 07:22:13 CEST schrieb Heiko Schocher:
> Hello Mark,
> 
> added Richard Weinberger to cc...
> 
> Am 12.07.2018 um 02:28 schrieb Mark Spieth:
> > Hi
> > 
> > In the process of investigating a boot failure on one of our devices, the
> > 
> > UBI: fixable bit-flip detected at PEB
> > 
> > message was seen with the following behaviour during kernel load in u-boot.
> > 
> > Read [2285568] bytes
> > UBI: fixable bit-flip detected at PEB 415
> > UBI: schedule PEB 415 for scrubbing
> > UBI: fixable bit-flip detected at PEB 415
> > UBI: fixable bit-flip detected at PEB 419
> > UBI: schedule PEB 419 for scrubbing
> > UBI: fixable bit-flip detected at PEB 419
> > UBI: fixable bit-flip detected at PEB 420
> > UBI: schedule PEB 420 for scrubbing
> > UBI: fixable bit-flip detected at PEB 420
> > UBI: fixable bit-flip detected at PEB 419
> > UBI: fixable bit-flip detected at PEB 420
> > UBI: fixable bit-flip detected at PEB 419
> > UBI: fixable bit-flip detected at PEB 420
> > UBI: fixable bit-flip detected at PEB 419
> > UBI: fixable bit-flip detected at PEB 420
> > UBI: fixable bit-flip detected at PEB 419
> > UBI: fixable bit-flip detected at PEB 420
> > UBI: fixable bit-flip detected at PEB 419
> > UBI: fixable bit-flip detected at PEB 420
> > UBI: fixable bit-flip detected at PEB 419
> > 
> > This repeats until reset.

Do you see the same symptom also on Linux?
We need to be very sure that it is actually a UBI problem.

> > This fix is not a root cause fix though. Investigating further led to the 
> > following root cause 
> > solution. The following is AFAICT.
> > 
> > When the scrubber chooses a PEB to move the from the free balanced tree. 
> > This tree is sorted by EC 
> > (erase count) and then by PEB number.
> > 
> > The find_wl_entry call uses a max parameter of WL_FREE_MAX_DIFF which is 
> > 8192 in this config. So the 
> > find_wl_entry function will find a PEB that is better in error count that 
> > the current PEB EC. This

error count? You mean erase count?
 
> > can easily cause it to find the PEB that was just moved from if it is the 
> > lowest numbered PEB in the 
> > free tree. Waiting for EC to go above 8192 would take a long time and cause 
> > premature aging of the 
> > flash PEBs in question.
> > 
> > The easy solution is to change the max parameter to this call to 0 so it 
> > finds a PEB with a smaller 
> > EC than the one being replaced. This means it wont use the previously 
> > discarded PEB as its first 
> > choice.

For scrubbing this might be a good idea, but not for regular wear-leveling.

See comment in UBI:
/*
 * When a physical eraseblock is moved, the WL sub-system has to pick the target
 * physical eraseblock to move to. The simplest way would be just to pick the
 * one with the highest erase counter. But in certain workloads this could lead
 * to an unlimited wear of one or few physical eraseblock. Indeed, imagine a
 * situation when the picked physical eraseblock is constantly erased after the
 * data is written to it. So, we have a constant which limits the highest erase
 * counter of the free physical eraseblock to pick. Namely, the WL sub-system
 * does not pick eraseblocks with erase counter greater than the lowest erase
 * counter plus %WL_FREE_MAX_DIFF.
 */
#define WL_FREE_MAX_DIFF (2*UBI_WL_THRESHOLD)

So we could change the logic such that for regular wear-leveling we keep using 
WL_FREE_MAX_DIFF,
but for scrubbing (which is 1:1 wear-leveling but the source PEB is showing 
bit-flips) we use
a lower value. IMHO WL_FREE_MAX_DIFF/2 would be a good choice.
I'm not sure whether 0 is too extreme and might cause other distortions.

Mark, can you please file a patch and send it to linux-mtd mailing list?
Such a change needs to go through Linux and then to u-boot.
But first we need to think about and discuss it in detail.
 
>   I am not sure if it is so easy ...
>
> > This fix was implemented and fixable bit-flip errors no longer hang/freeze 
> > the boot process! UBI 
> > erase and reformat was used between re-tests to get consistent results.
> > 
> > Adding the above 75% correctable bitflip threshold is also a good thing as 
> > less movement will ensue 
> > when the FLASH is new, but as the flash ages, the root cause will once 
> > again be invoked causing 
> > un-recoverable boot failures.
> > 
> > Note this fault is also in the latest kernel drivers for UBI and may also 
> > exist in other wear 
> > leveling implementations. The kernel driver issue may be at fault for 
> > android devices locking 
> > up/freezing sporadically during FLASH read when scrubbing due to a 
> > relatively full flash and 
> > correctable errors causing ping pong PEB moves.
> > 
> > The question is, is my root cause solution sound or have I missed something?
> 
> I have to think about, before I write nonsene, but may Richard has
> here a deeper insight.

Please see my comments. :)

Thanks,
//richard

___
U-Boot mailing 

Re: [U-Boot] [PATCH 2/2] dm: sunxi: Use DM for MMC and SATA on all A10 boards

2018-07-12 Thread Adam Sampson
On Thu, Jul 12, 2018 at 12:40:14PM +0530, Jagan Teki wrote:
> Did you test eMMC in any of A10 look it is not detecting during SD
> boot and vice-versa happened during eMMC boot. May be it's because of
> pincrtrl for U-Boot which is not initializing for in DM_MMC.

No, I don't have any boards with eMMC, so I haven't tested eMMC with
either A10 or A20, I'm afraid.

(I also haven't been able to find an A13 board to test with -- if there
are any A13 owners reading this, I suspect a similar change would work,
and it'll need doing before the A13 boards get removed for not having DM
support...)

-- 
Adam Sampson  
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] ls1021a: problem with errata A009007

2018-07-12 Thread Heiko Schocher

Hello Ran Wang,

Am 12.07.2018 um 10:04 schrieb Ran Wang:

Hi Heiko,


-Original Message-
From: Heiko Schocher [mailto:h...@denx.de]
Sent: Thursday, July 12, 2018 13:44
To: Ran Wang 
Cc: Sriram Dash ; Rajesh Bhagat
; Suresh Gupta ; u-
b...@lists.denx.de
Subject: ls1021a: problem with errata A009007

Hello Ran Wang,

I have ported successfully U-Boot to an ls1021a based board and works nice
for the HW I have access to.

Now the customer reports problems on his HW with
SYS_FSL_ERRATUM_A009007
which is always activated.

Board does not boot, and crashes in erratum_a009007()

(Sorry I have no logs ... nor access to this HW)

Disabling this function, and U-Boot boots ...

Customer states/confirmed me, that he has the same HW ...

On the board USB is not used.

Any ideas hints what can be wrong here?


I just re-reverified on  latest upstream U-Boot with LS1021ATWR board. It 
worked fine.
You might need to know what kind of crash they encountered:


I am sorry ... no debugger there ...


1. That erratum workaround programming will happen before the UART print 
activated, that means
no log will show when writing those register, how does then know the crash?


Good question ... they removed the erratum_a009007() function, and
SPL / U-Boot booted fine ... but I think currently, the HW is bogus ...
I cannot verify this with the HW i have ...


2.  Except erratum programming, USB controller (xHCI) will NOT be initialized 
untill U-Boot command 'usb start'
is executed. That means if user didn't type 'usb start', USB IP will not begin 
to work at all.


Yes, and on the board USB is not used at all...


3. Anyway, this erratum is used to pass USB compliance test only, you could 
disable this workaround
on your board if you don't any USB issue on normal use case, I think it's fine.


Thanks for your clarification!

bye,
Heiko
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: h...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] UBI fixable bit-flip issue

2018-07-12 Thread Heiko Schocher

Hello Mark,

Am 12.07.2018 um 07:38 schrieb Mark Spieth:


On 12/07/18 15:22, Heiko Schocher wrote:

Hello Mark,

added Richard Weinberger to cc...

Am 12.07.2018 um 02:28 schrieb Mark Spieth:

Hi

In the process of investigating a boot failure on one of our devices, the

UBI: fixable bit-flip detected at PEB

message was seen with the following behaviour during kernel load in u-boot.

Read [2285568] bytes
UBI: fixable bit-flip detected at PEB 415
UBI: schedule PEB 415 for scrubbing
UBI: fixable bit-flip detected at PEB 415
UBI: fixable bit-flip detected at PEB 419
UBI: schedule PEB 419 for scrubbing
UBI: fixable bit-flip detected at PEB 419
UBI: fixable bit-flip detected at PEB 420
UBI: schedule PEB 420 for scrubbing
UBI: fixable bit-flip detected at PEB 420
UBI: fixable bit-flip detected at PEB 419
UBI: fixable bit-flip detected at PEB 420
UBI: fixable bit-flip detected at PEB 419
UBI: fixable bit-flip detected at PEB 420
UBI: fixable bit-flip detected at PEB 419
UBI: fixable bit-flip detected at PEB 420
UBI: fixable bit-flip detected at PEB 419
UBI: fixable bit-flip detected at PEB 420
UBI: fixable bit-flip detected at PEB 419
UBI: fixable bit-flip detected at PEB 420
UBI: fixable bit-flip detected at PEB 419

This repeats until reset.

U boot is a patched version of 2010.06 supplied by the chip vendor. No newer version is available 
from the vendor to try.


:-(

Can you use current mainline ? It s hard to say something
about a 8 year old vendor U-Boot version ...

I know. I did look at the current 2018.07 and 2014.10 as comparison.

There are many patches applied by the vendor so porting them with the large changes to driver 
structure would be difficult and time consuming.

The vendor is Lantiq and the SDK is current (this year).



The patches include the init eba/wl swap.


What do you mean here?

https://lists.denx.de/pipermail/u-boot/2013-January/143199.html
This patch was already applied by the vendor.

ubi_eba_init_scan() must be initialised before ubi_wl_init_scan() and in that baseline they were the 
wrong way around.


There is only 1 other message chain for fixable bit flips (2011) and that was not useful for this 
problem.



A more detailed log with debugging available follows:

UBI: fixable bit-flip detected at PEB 419
UBI DBG: schedule_erase: schedule erasure of PEB 419, EC 19, torture 0
UBI DBG: erase_worker: erase PEB 419 EC 19
UBI DBG: sync_erase: erase PEB 419, old EC 19
UBI DBG: do_sync_erase: erase PEB 419
UBI DBG: sync_erase: erased PEB 419, new EC 20
UBI DBG: ubi_io_write_ec_hdr: write EC header to PEB 419
UBI DBG: ubi_io_write: write 2048 bytes to PEB 419:0
UBI DBG: ensure_wear_leveling: schedule scrubbing
UBI DBG: wear_leveling_worker: scrub PEB 420 to PEB 419
UBI DBG: ubi_io_read_vid_hdr: read VID header from PEB 420
UBI DBG: ubi_io_read: read 2048 bytes from PEB 420:2048
UBI DBG: ubi_eba_copy_leb: copy LEB 6:11, PEB 420 to PEB 419
UBI DBG: ubi_eba_copy_leb: read 126976 bytes of data
UBI DBG: ubi_io_read: read 126976 bytes from PEB 420:4096
UBI: fixable bit-flip detected at PEB 420
UBI DBG: ubi_io_write_vid_hdr: write VID header to PEB 419
UBI DBG: ubi_io_write: write 2048 bytes to PEB 419:2048
UBI DBG: ubi_io_read_vid_hdr: read VID header from PEB 419
UBI DBG: ubi_io_read: read 2048 bytes from PEB 419:2048
UBI DBG: ubi_io_write: write 126976 bytes to PEB 419:4096
UBI DBG: ubi_io_read: read 126976 bytes from PEB 419:4096
UBI: fixable bit-flip detected at PEB 419
UBI DBG: schedule_erase: schedule erasure of PEB 419, EC 20, torture 0
UBI DBG: erase_worker: erase PEB 419 EC 20
UBI DBG: sync_erase: erase PEB 419, old EC 20
UBI DBG: do_sync_erase: erase PEB 419
UBI DBG: sync_erase: erased PEB 419, new EC 21
UBI DBG: ubi_io_write_ec_hdr: write EC header to PEB 419
UBI DBG: ubi_io_write: write 2048 bytes to PEB 419:0
UBI DBG: ensure_wear_leveling: schedule scrubbing
UBI DBG: wear_leveling_worker: scrub PEB 420 to PEB 419
UBI DBG: ubi_io_read_vid_hdr: read VID header from PEB 420
UBI DBG: ubi_io_read: read 2048 bytes from PEB 420:2048
UBI DBG: ubi_eba_copy_leb: copy LEB 6:11, PEB 420 to PEB 419
UBI DBG: ubi_eba_copy_leb: read 126976 bytes of data
UBI DBG: ubi_io_read: read 126976 bytes from PEB 420:4096
UBI: fixable bit-flip detected at PEB 420
UBI DBG: ubi_io_write_vid_hdr: write VID header to PEB 419
UBI DBG: ubi_io_write: write 2048 bytes to PEB 419:2048
UBI DBG: ubi_io_read_vid_hdr: read VID header from PEB 419
UBI DBG: ubi_io_read: read 2048 bytes from PEB 419:2048
UBI DBG: ubi_io_write: write 126976 bytes to PEB 419:4096
UBI DBG: ubi_io_read: read 126976 bytes from PEB 419:4096
UBI: fixable bit-flip detected at PEB 419

Investigation showed that a read with correctable bit errors was done returning -EUCLEAN to the 
ubi read function.


Having read https://lists.denx.de/pipermail/u-boot/2013-September/161961.html which details a 
workaround to not return EUCLEAN from the NAND reader unless the number of fixed bits returned 
was 75% of the total number of correctable bits was 

Re: [U-Boot] [PATCH v2 04/21] mtd: Fallback to ->_read/write() when ->_read/write_oob() is missing

2018-07-12 Thread Miquel Raynal
Hi Boris,

Boris Brezillon  wrote on Thu, 12 Jul 2018
00:20:52 +0200:

> On Wed, 11 Jul 2018 17:25:12 +0200
> Miquel Raynal  wrote:
> 
> > Some MTD sublayers/drivers are implementing ->_read/write() and
> > not ->_read/write_oob().
> > 
> > While for NAND devices both are usually valid, for NOR devices, using
> > the _oob variant has no real meaning. But, as the MTD layer is supposed
> > to hide as much as possible the flash complexity to the user, there is
> > no reason to error out while it is just a matter of rewritting things
> > internally.
> > 
> > Add a fallback on mtd->_read() (resp. mtd->_write()) when the user calls
> > mtd_read_oob() (resp. mtd_write_oob()) while mtd->_read_oob() (resp.
> > mtd->_write_oob) is not implemented. There is already a fallback on the
> > _oob variant if the former is used.  
> 
> Now I'm jealous. Can we have the same thing Linux :-).

U-Boot, one step ahead ;)

> 
> > 
> > Signed-off-by: Miquel Raynal 
> > ---
> >  drivers/mtd/mtdcore.c | 26 --
> >  1 file changed, 20 insertions(+), 6 deletions(-)
> > 
> > diff --git a/drivers/mtd/mtdcore.c b/drivers/mtd/mtdcore.c
> > index ba170f212e..095c58cf8c 100644
> > --- a/drivers/mtd/mtdcore.c
> > +++ b/drivers/mtd/mtdcore.c
> > @@ -1048,20 +1048,27 @@ int mtd_read_oob(struct mtd_info *mtd, loff_t from, 
> > struct mtd_oob_ops *ops)
> >  {
> > int ret_code;
> > ops->retlen = ops->oobretlen = 0;
> > -   if (!mtd->_read_oob)
> > -   return -EOPNOTSUPP;
> >  
> > ret_code = mtd_check_oob_ops(mtd, from, ops);
> > if (ret_code)
> > return ret_code;
> >  
> > +   /* Check the validity of a potential fallback on mtd->_read */
> > +   if ((!mtd->_read_oob) && (!mtd->_read || ops->oobbuf))  
> 
> Parens around !mtd->_read_oob are not needed.

[...]

> > -   return mtd->_write_oob(mtd, to, ops);
> > +   /* Check the validity of a potential fallback on mtd->_write */
> > +   if ((!mtd->_write_oob) && (!mtd->_write || ops->oobbuf))  
> 
> Ditto.
> 

Right!

Thanks,
Miquèl
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH] arm: socfpga: Fixes: include

2018-07-12 Thread Marek Vasut
On 07/12/2018 03:44 PM, Ley Foon Tan wrote:
> Fix compilation warning when enable CONFIG_DEBUG_UART.
> 
> arch/arm/mach-socfpga/spl_s10.c: In function ‘board_init_f’:
> arch/arm/mach-socfpga/spl_s10.c:146:2: warning: implicit declaration of 
> function ‘debug_uart_init’; did you mean ‘part_init’? 
> [-Wimplicit-function-declaration]
>   debug_uart_init();
> 
> Signed-off-by: Ley Foon Tan 
> ---
>  arch/arm/mach-socfpga/spl_s10.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/mach-socfpga/spl_s10.c b/arch/arm/mach-socfpga/spl_s10.c
> index 69c2ee3..69d6e91 100644
> --- a/arch/arm/mach-socfpga/spl_s10.c
> +++ b/arch/arm/mach-socfpga/spl_s10.c
> @@ -8,6 +8,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> 
Applied, thanks

-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


  1   2   >