[U-Boot] [PATCH v1 2/2] spl: move SYS_OS_BASE to Kconfig

[Heiko Schocher]

Move SYS_OS_BASE to Kconfig and cleanup existing
uses.

Signed-off-by: Heiko Schocher 
---

 common/spl/Kconfig   | 10 ++
 configs/a3m071_defconfig |  1 +
 configs/microblaze-generic_defconfig |  1 +
 include/configs/a3m071.h |  1 -
 include/configs/microblaze-generic.h |  2 --
 5 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/common/spl/Kconfig b/common/spl/Kconfig
index 5e2890e..36544cc 100644
--- a/common/spl/Kconfig
+++ b/common/spl/Kconfig
@@ -367,6 +367,16 @@ config SPL_OS_BOOT
  Enable booting directly to an OS from SPL.
  for more info read doc/README.falcon
 
+if SPL_OS_BOOT
+config SYS_OS_BASE
+   hex "addr, where OS is found"
+   depends on SPL && SPL_NOR_SUPPORT
+   help
+ Specify the address, where the OS image is found, which
+ gets booted.
+
+endif # SPL_OS_BOOT
+
 config SPL_POST_MEM_SUPPORT
bool "Support POST drivers"
depends on SPL
diff --git a/configs/a3m071_defconfig b/configs/a3m071_defconfig
index 5356489..ae696b5 100644
--- a/configs/a3m071_defconfig
+++ b/configs/a3m071_defconfig
@@ -11,6 +11,7 @@ CONFIG_BOOTDELAY=3
 CONFIG_SPL=y
 CONFIG_SPL_NOR_SUPPORT=y
 CONFIG_SPL_OS_BOOT=y
+CONFIG_SYS_OS_BASE=0xfc20
 CONFIG_HUSH_PARSER=y
 CONFIG_LOOPW=y
 # CONFIG_CMD_SETEXPR is not set
diff --git a/configs/microblaze-generic_defconfig 
b/configs/microblaze-generic_defconfig
index bc97f60..3dbf48a 100644
--- a/configs/microblaze-generic_defconfig
+++ b/configs/microblaze-generic_defconfig
@@ -16,6 +16,7 @@ CONFIG_SPL=y
 CONFIG_SPL_SYS_MALLOC_SIMPLE=y
 CONFIG_SPL_NOR_SUPPORT=y
 CONFIG_SPL_OS_BOOT=y
+CONFIG_SYS_OS_BASE=0x2c06
 CONFIG_HUSH_PARSER=y
 CONFIG_SYS_PROMPT="U-Boot-mONStR> "
 CONFIG_CMD_ASKENV=y
diff --git a/include/configs/a3m071.h b/include/configs/a3m071.h
index 8514b0e..c437c4a 100644
--- a/include/configs/a3m071.h
+++ b/include/configs/a3m071.h
@@ -331,7 +331,6 @@
 
 #undef CONFIG_BOOTARGS
 
-#define CONFIG_SYS_OS_BASE 0xfc20
 #define CONFIG_SYS_FDT_BASE0xfc1e
 #define CONFIG_SYS_FDT_SIZE(16<<10)
 
diff --git a/include/configs/microblaze-generic.h 
b/include/configs/microblaze-generic.h
index 32b0c62..2a7006f 100644
--- a/include/configs/microblaze-generic.h
+++ b/include/configs/microblaze-generic.h
@@ -293,8 +293,6 @@
 
 /* for booting directly linux */
 
-#define CONFIG_SYS_OS_BASE (CONFIG_SYS_FLASH_BASE + \
-0x6)
 #define CONFIG_SYS_FDT_BASE(CONFIG_SYS_FLASH_BASE + \
 0x4)
 #define CONFIG_SYS_FDT_SIZE(16<<10)
-- 
2.5.5

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

[U-Boot] [PATCH v1] spl: move FDT_FIXUP_PARTITIONS to Kconfig

[Heiko Schocher]

Move FDT_FIXUP_PARTITIONS to Kconfig and cleanup existing
uses.

Signed-off-by: Heiko Schocher 

---
checked with tbot, result:

Boards  : 1213
compile err : 13
not checked : 1
U-Boot good : 1199 bad 0
SPL good: 1199 bad 0

Boards not checked, as they had compile errors:
['adp-ag101p', 'bf533-stamp', 'cm-bf527', 'colibri_pxa270', 'omap4_sdp4430', 
'openrisc-generic', 'qemu-x86_efi_payload64', 'sandbox', 'sandbox_noblk', 
'sandbox_spl', 'smdk5250', 'snow', 'spring']
Boards not checked, as no toolchain:
['xtfpga']


 configs/BSC9131RDB_NAND_SYSCLK100_defconfig| 1 +
 configs/BSC9131RDB_NAND_defconfig  | 1 +
 configs/BSC9131RDB_SPIFLASH_SYSCLK100_defconfig| 1 +
 configs/BSC9131RDB_SPIFLASH_defconfig  | 1 +
 configs/BSC9132QDS_NAND_DDRCLK100_SECURE_defconfig | 1 +
 configs/BSC9132QDS_NAND_DDRCLK100_defconfig| 1 +
 configs/BSC9132QDS_NAND_DDRCLK133_SECURE_defconfig | 1 +
 configs/BSC9132QDS_NAND_DDRCLK133_defconfig| 1 +
 configs/BSC9132QDS_NOR_DDRCLK100_SECURE_defconfig  | 1 +
 configs/BSC9132QDS_NOR_DDRCLK100_defconfig | 1 +
 configs/BSC9132QDS_NOR_DDRCLK133_SECURE_defconfig  | 1 +
 configs/BSC9132QDS_NOR_DDRCLK133_defconfig | 1 +
 configs/BSC9132QDS_SDCARD_DDRCLK100_SECURE_defconfig   | 1 +
 configs/BSC9132QDS_SDCARD_DDRCLK100_defconfig  | 1 +
 configs/BSC9132QDS_SDCARD_DDRCLK133_SECURE_defconfig   | 1 +
 configs/BSC9132QDS_SDCARD_DDRCLK133_defconfig  | 1 +
 configs/BSC9132QDS_SPIFLASH_DDRCLK100_SECURE_defconfig | 1 +
 configs/BSC9132QDS_SPIFLASH_DDRCLK100_defconfig| 1 +
 configs/BSC9132QDS_SPIFLASH_DDRCLK133_SECURE_defconfig | 1 +
 configs/BSC9132QDS_SPIFLASH_DDRCLK133_defconfig| 1 +
 configs/cm_fx6_defconfig   | 1 +
 configs/gwventana_defconfig| 1 +
 configs/pdm360ng_defconfig | 1 +
 include/configs/BSC9131RDB.h   | 7 ---
 include/configs/BSC9132QDS.h   | 8 
 include/configs/cm_fx6.h   | 1 -
 include/configs/gw_ventana.h   | 3 ---
 include/configs/pdm360ng.h | 8 
 lib/Kconfig| 9 +
 29 files changed, 32 insertions(+), 27 deletions(-)

diff --git a/configs/BSC9131RDB_NAND_SYSCLK100_defconfig 
b/configs/BSC9131RDB_NAND_SYSCLK100_defconfig
index babcdd5..9a69785 100644
--- a/configs/BSC9131RDB_NAND_SYSCLK100_defconfig
+++ b/configs/BSC9131RDB_NAND_SYSCLK100_defconfig
@@ -28,3 +28,4 @@ CONFIG_FSL_ESPI=y
 CONFIG_USB=y
 CONFIG_USB_STORAGE=y
 CONFIG_OF_LIBFDT=y
+CONFIG_FDT_FIXUP_PARTITIONS=y
diff --git a/configs/BSC9131RDB_NAND_defconfig 
b/configs/BSC9131RDB_NAND_defconfig
index ad00622..46b5b8e 100644
--- a/configs/BSC9131RDB_NAND_defconfig
+++ b/configs/BSC9131RDB_NAND_defconfig
@@ -28,3 +28,4 @@ CONFIG_FSL_ESPI=y
 CONFIG_USB=y
 CONFIG_USB_STORAGE=y
 CONFIG_OF_LIBFDT=y
+CONFIG_FDT_FIXUP_PARTITIONS=y
diff --git a/configs/BSC9131RDB_SPIFLASH_SYSCLK100_defconfig 
b/configs/BSC9131RDB_SPIFLASH_SYSCLK100_defconfig
index 9045567..9a50d0c 100644
--- a/configs/BSC9131RDB_SPIFLASH_SYSCLK100_defconfig
+++ b/configs/BSC9131RDB_SPIFLASH_SYSCLK100_defconfig
@@ -25,3 +25,4 @@ CONFIG_FSL_ESPI=y
 CONFIG_USB=y
 CONFIG_USB_STORAGE=y
 CONFIG_OF_LIBFDT=y
+CONFIG_FDT_FIXUP_PARTITIONS=y
diff --git a/configs/BSC9131RDB_SPIFLASH_defconfig 
b/configs/BSC9131RDB_SPIFLASH_defconfig
index 178618c..ebb41d2 100644
--- a/configs/BSC9131RDB_SPIFLASH_defconfig
+++ b/configs/BSC9131RDB_SPIFLASH_defconfig
@@ -25,3 +25,4 @@ CONFIG_FSL_ESPI=y
 CONFIG_USB=y
 CONFIG_USB_STORAGE=y
 CONFIG_OF_LIBFDT=y
+CONFIG_FDT_FIXUP_PARTITIONS=y
diff --git a/configs/BSC9132QDS_NAND_DDRCLK100_SECURE_defconfig 
b/configs/BSC9132QDS_NAND_DDRCLK100_SECURE_defconfig
index e678144..5bed9aa 100644
--- a/configs/BSC9132QDS_NAND_DDRCLK100_SECURE_defconfig
+++ b/configs/BSC9132QDS_NAND_DDRCLK100_SECURE_defconfig
@@ -30,3 +30,4 @@ CONFIG_USB_STORAGE=y
 CONFIG_RSA=y
 CONFIG_SPL_RSA=y
 CONFIG_OF_LIBFDT=y
+CONFIG_FDT_FIXUP_PARTITIONS=y
diff --git a/configs/BSC9132QDS_NAND_DDRCLK100_defconfig 
b/configs/BSC9132QDS_NAND_DDRCLK100_defconfig
index e6fde47..defeee1 100644
--- a/configs/BSC9132QDS_NAND_DDRCLK100_defconfig
+++ b/configs/BSC9132QDS_NAND_DDRCLK100_defconfig
@@ -29,3 +29,4 @@ CONFIG_FSL_ESPI=y
 CONFIG_USB=y
 CONFIG_USB_STORAGE=y
 CONFIG_OF_LIBFDT=y
+CONFIG_FDT_FIXUP_PARTITIONS=y
diff --git a/configs/BSC9132QDS_NAND_DDRCLK133_SECURE_defconfig 
b/configs/BSC9132QDS_NAND_DDRCLK133_SECURE_defconfig
index 1d9b541..3a695fc 100644
--- a/configs/BSC9132QDS_NAND_DDRCLK133_SECURE_defconfig
+++ b/configs/BSC9132QDS_NAND_DDRCLK133_SECURE_defconfig
@@ -30,3 +30,4 @@ CONFIG_USB_STORAGE=y
 CONFIG_RSA=y
 CONFIG_SPL_RSA=y
 CONFIG_OF_LIBFDT=y
+CONFIG_FDT_FIXUP_PARTITIONS=y
diff --git a/configs/BSC9132QDS_NAND_DDRCLK133_defconfig 

Re: [U-Boot] SPL load ARM Trusted Firmware BL31?

[Simon Glass]

Hi Masahiro,

On 5 October 2016 at 20:02, Masahiro Yamada 
wrote:
> Hi Simon,
>
>
> 2016-10-06 1:50 GMT+09:00 Simon Glass :
>
>> Long term, I am wondering if ATF could be a library instead of a
>> separate binary? Or perhaps it could be build so that it can be linked
>> against.
>
>
> ATF is runtime firmware, so it will stay there while the system is
running.
> On the other hand, the memory allocated for U-Boot can be freed
> after the system boot up.

That is changing, e.g. with EFI_LOADER. Also it is possible on x86 that
some code may hang around (if SMM etc. is implemented in U-Boot).

>
>
> In the first place, this is a license issue.
>
> U-Boot GPL vs ATF BSD.
>
> I think they can not be linked together.

Ah OK.

Is it not permitted to link a BSD library into U-Boot? Anyway, that is not
so important I suppose.

Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] SPL load ARM Trusted Firmware BL31?

[Michal Simek]

On 5.10.2016 09:50, Simon Glass wrote:
> Hi,
> 
> On 5 October 2016 at 08:39, Michal Simek  wrote:
>> Hi Masahiro,
>>
>> 2016-10-04 20:19 GMT-07:00 Masahiro Yamada :
>>
>>> Hi.
>>>
>>> Recently I implemented ARM Trusted Firmware BL31 for my SoCs.
>>>
>>> But, I am wondering how the boot-flow should be.
>>>
>>>
>>>
>>> Here is my situation.
>>>
>>>
>>> [1]
>>> When my company developed its first ARMv8 SoC,
>>> I had to bring up the system very quickly.
>>>
>>> I was familiar with U-Boot and Linux to some extent, but not with ATF
>>> at that time.
>>> Also I was too pressed, so I decided to build up the system without ATF.
>>>
>>> The boot-flow was like this:
>>>
>>>   BootROM  ->  U-Boot SPL  -> U-Boot proper -> Linux
>>>
>>> In this flow, the secure runtime firmware is missing,
>>> so I used Spin-Table for the enable-method.
>>>
>>>
>>> [2]
>>> Now I finished porting ATF BL31.
>>> The low-level init code (basic SoC init + DRAM initialization)
>>> already exists in U-Boot SPL.
>>> So, I am currently re-using SPL, like follows:
>>>
>>>  BootROM ->  U-Boot SPL  -> ATF BL31 -> U-Boot proper (=BL33) -> Linux
>>>
>>>
>>> As far as I know, SPL can not load multiple images such as BL31, BL32, BL33
>>> (here BL32 is optional).
>>> So, I hacked my SPL to load multi images
>>> and jump to BL31.
>>>
>>
>> this is not entirely truth. If you look at zynqmp you will find out that if
>> you
>> work with atf as kernel and full u-boot as dtb then u-boot SPL can load two
>> images.
>> This is what I use. It is a trick but I am not using any changes to get it
>> work.
>>
>>
>>
>>
>>>
>>>
>>>
>>>
>>> [3]
>>> I am guessing most vendors use vendor-specific firmware for low-level init
>>> because I see many of ARMv8 SoCs disabling CONFIG_SPL.  Correct?
>>>
>>
>> I do use SPL exactly how as used without ATF. It means low level init is
>> done in SPL in EL3.
>>
>>
>>>
>>>  Boot ROM  ->  Vendor proprietary firmware -> ATF BL31  ->  U-Boot or
>>> UEFI (=BL33) -> Linux
>>>
>>>
>>>
>>>
>>> [4]
>>> Is it a good idea to implement everything in ATF like Juno/FVP?
>>>
>>>  BL1 -> BL2 -> BL31 -> U-Boot or UEFI (BL33) -> Linux
>>>
>>
>> We are using only BL31 and nothing else.
>>
>>
>>>
>>>
>>>
>>>
>>>
>>> Recently I saw Simon's binman patches.
>>> It provides a fancy way to pack multiple firmware components into a
>>> single image,
>>> but I did not see the systematic way to load every entry in the image.
>>>   (under way?)
>>>
>>>
>>> I was wondering if I should move my low-level init code
>>> from SPL to ATF BL2 or somewhere.
>>>
>>> Comments are welcome.
>>>
>>
>> I use bootrom -> SPL -> ATF -> full u-boot.
>>
>> I want to use SPL because we have all device drivers in u-boot and
>> in ATF we have only serial driver. If you want to use BL2 just for low
>> level init stuff
>> you can but it is the question if this brings you any value.
>>
>> Anyway check zynqmp. It is not perfect solution but it is at least temporary
>> solution for just this case.
>> FIT image has an option to add more images with load address and I think
>> this is a support
>> we should support in SPL. (doc/uImage.FIT/multi-with-loadables.its)
>> Also there will be probably need to mark images with EL level this targets.
> 
> I have not got into this yet. But I'm really keen on SPL being the
> first thing that runs, and it calling into ATF bits as needed. This
> allows verified boot to work correctly, since we can add signatures to
> the images, etc. It also is easier to follow IMO.

Isn't this already supported if I pretend that ATF is Linux kernel
and dtb is full U-Boot.

> 
> Long term, I am wondering if ATF could be a library instead of a
> separate binary? Or perhaps it could be build so that it can be linked
> against.
> 
> Binman aims to make it easier to create these images with 4-5 separate
> binaries. At some point I'm going to look at ATF in a bit more detail.

I should look at it when you send it because for boot.bin generation
could be useful.

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
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 07/12] dm: x86: video: Add a driver-model driver for ivybridge graphics

[Simon Glass]

Hi Bin,

On 5 October 2016 at 03:20, Bin Meng  wrote:
> Hi Simon,
>
> On Mon, Oct 3, 2016 at 11:12 AM, Simon Glass  wrote:
>> At present we use the legacy vesa driver for graphics. Add a driver which
>> supports driver model. This can be probed only when needed, removing the
>> need to start up the display if it is not used.
>>
>> Signed-off-by: Simon Glass 
>> ---
>>
>>  drivers/video/Kconfig |  12 +
>>  drivers/video/Makefile|   1 +
>>  drivers/video/ivybridge.c | 842 
>> ++
>>  3 files changed, 855 insertions(+)
>>  create mode 100644 drivers/video/ivybridge.c
>>
>> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
>> index 97dbb64..fd26690 100644
>> --- a/drivers/video/Kconfig
>> +++ b/drivers/video/Kconfig
>> @@ -374,6 +374,18 @@ config VIDEO_BROADWELL_IGD
>>   a special tool which configures the VGA ROM, but the graphics
>>   resolution can be selected in U-Boot.
>>
>> +config VIDEO_IVYBRIDGE_IGD
>> +   bool "Enable Intel Ivybridge integration graphics support"
>> +   depends on X86
>> +   help
>> + This enables support for integrated graphics on Intel ivybridge
>> + devices. Initialisation is mostly performed by a VGA boot ROM, with
>> + some setup handled by U-Boot itself. The graphics adaptor works as
>> + a VESA device and supports LCD panels, eDP and LVDS outputs.
>> + Configuration of most aspects of device operation is performed 
>> using
>> + a special tool which configures the VGA ROM, but the graphics
>> + resolution can be selected in U-Boot.
>> +
>>  config VIDEO_ROCKCHIP
>> bool "Enable Rockchip video support"
>> depends on DM_VIDEO
>> diff --git a/drivers/video/Makefile b/drivers/video/Makefile
>> index 3f045fe..2fc88b0 100644
>> --- a/drivers/video/Makefile
>> +++ b/drivers/video/Makefile
>> @@ -20,6 +20,7 @@ obj-$(CONFIG_CONSOLE_TRUETYPE) += console_truetype.o fonts/
>>  endif
>>
>>  obj-$(CONFIG_VIDEO_BROADWELL_IGD) += broadwell_igd.o
>> +obj-$(CONFIG_VIDEO_IVYBRIDGE_IGD) += ivybridge.o
>
> Like broadwell_igd.c, should this be ivybridge_igd.c?
>
>>
>>  obj-$(CONFIG_ATI_RADEON_FB) += ati_radeon_fb.o videomodes.o
>>  obj-$(CONFIG_ATMEL_HLCD) += atmel_hlcdfb.o
>> diff --git a/drivers/video/ivybridge.c b/drivers/video/ivybridge.c
>> new file mode 100644
>> index 000..751c9a0
>> --- /dev/null
>> +++ b/drivers/video/ivybridge.c
>> @@ -0,0 +1,842 @@
>> +1/*
>> + * Copyright (C) 2016 Google, Inc
>> + *
>> + * SPDX-License-Identifier:GPL-2.0
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +struct gt_powermeter {
>> +   u16 reg;
>> +   u32 value;
>> +};
>> +
>
> I know these magic numbers may be inevitable, but if we can put some
> comments here that would be great.

Unfortunately I don't have any details. I've added a comment in v2.

Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2 12/12] dm: x86: Move link to use driver model for video

[Simon Glass]

Update the configuration to use the new driver. Drop the existing plumbing
code and unused header files.

Signed-off-by: Simon Glass 
Reviewed-by: Bin Meng 
---

Changes in v2: None

 arch/x86/cpu/ivybridge/Makefile   |   1 -
 arch/x86/cpu/ivybridge/bd82x6x.c  |  12 -
 arch/x86/cpu/ivybridge/early_me.c |   1 -
 arch/x86/cpu/ivybridge/gma.c  | 850 --
 arch/x86/cpu/ivybridge/gma.h  | 156 -
 arch/x86/cpu/ivybridge/model_206ax.c  |   1 -
 arch/x86/cpu/ivybridge/sata.c |   1 -
 arch/x86/include/asm/arch-ivybridge/bd82x6x.h |  12 -
 arch/x86/include/asm/cpu.h|   1 -
 configs/chromebook_link_defconfig |   2 +
 10 files changed, 2 insertions(+), 1035 deletions(-)
 delete mode 100644 arch/x86/cpu/ivybridge/gma.c
 delete mode 100644 arch/x86/cpu/ivybridge/gma.h
 delete mode 100644 arch/x86/include/asm/arch-ivybridge/bd82x6x.h

diff --git a/arch/x86/cpu/ivybridge/Makefile b/arch/x86/cpu/ivybridge/Makefile
index 9cdb07b..498e71a 100644
--- a/arch/x86/cpu/ivybridge/Makefile
+++ b/arch/x86/cpu/ivybridge/Makefile
@@ -9,7 +9,6 @@ obj-y += fsp_configs.o ivybridge.o
 else
 obj-y += cpu.o
 obj-y += early_me.o
-obj-y += gma.o
 obj-y += lpc.o
 obj-y += model_206ax.o
 obj-y += northbridge.o
diff --git a/arch/x86/cpu/ivybridge/bd82x6x.c b/arch/x86/cpu/ivybridge/bd82x6x.c
index 5b58d6c..e63ea6b 100644
--- a/arch/x86/cpu/ivybridge/bd82x6x.c
+++ b/arch/x86/cpu/ivybridge/bd82x6x.c
@@ -9,14 +9,12 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -155,22 +153,12 @@ void pch_iobp_update(struct udevice *dev, u32 address, 
u32 andvalue,
 
 static int bd82x6x_probe(struct udevice *dev)
 {
-   struct udevice *gma_dev;
-   int ret;
-
if (!(gd->flags & GD_FLG_RELOC))
return 0;
 
/* Cause the SATA device to do its init */
uclass_first_device(UCLASS_AHCI, );
 
-   ret = syscon_get_by_driver_data(X86_SYSCON_GMA, _dev);
-   if (ret)
-   return ret;
-   ret = gma_func0_init(gma_dev);
-   if (ret)
-   return ret;
-
return 0;
 }
 #endif /* CONFIG_HAVE_FSP */
diff --git a/arch/x86/cpu/ivybridge/early_me.c 
b/arch/x86/cpu/ivybridge/early_me.c
index cda96ab..5435a92 100644
--- a/arch/x86/cpu/ivybridge/early_me.c
+++ b/arch/x86/cpu/ivybridge/early_me.c
@@ -162,7 +162,6 @@ int intel_early_me_init_done(struct udevice *dev, struct 
udevice *me_dev,
 
 static const struct udevice_id ivybridge_syscon_ids[] = {
{ .compatible = "intel,me", .data = X86_SYSCON_ME },
-   { .compatible = "intel,gma", .data = X86_SYSCON_GMA },
{ }
 };
 
diff --git a/arch/x86/cpu/ivybridge/gma.c b/arch/x86/cpu/ivybridge/gma.c
deleted file mode 100644
index 37e2e6e..000
--- a/arch/x86/cpu/ivybridge/gma.c
+++ /dev/null
@@ -1,850 +0,0 @@
-/*
- * From Coreboot file of the same name
- *
- * Copyright (C) 2011 Chromium OS Authors
- *
- * SPDX-License-Identifier:GPL-2.0
- */
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-struct gt_powermeter {
-   u16 reg;
-   u32 value;
-};
-
-static const struct gt_powermeter snb_pm_gt1[] = {
-   { 0xa200, 0xcc00 },
-   { 0xa204, 0x0740 },
-   { 0xa208, 0xfe00 },
-   { 0xa20c, 0x },
-   { 0xa210, 0x1700 },
-   { 0xa214, 0x0021 },
-   { 0xa218, 0x0817fe19 },
-   { 0xa21c, 0x },
-   { 0xa220, 0x },
-   { 0xa224, 0xcc00 },
-   { 0xa228, 0x0740 },
-   { 0xa22c, 0xfe00 },
-   { 0xa230, 0x },
-   { 0xa234, 0x1700 },
-   { 0xa238, 0x0021 },
-   { 0xa23c, 0x0817fe19 },
-   { 0xa240, 0x },
-   { 0xa244, 0x },
-   { 0xa248, 0x8000421e },
-   { 0 }
-};
-
-static const struct gt_powermeter snb_pm_gt2[] = {
-   { 0xa200, 0x33a6 },
-   { 0xa204, 0x402d0031 },
-   { 0xa208, 0x00165f83 },
-   { 0xa20c, 0xf100 },
-   { 0xa210, 0x },
-   { 0xa214, 0x00160016 },
-   { 0xa218, 0x002a002b },
-   { 0xa21c, 0x },
-   { 0xa220, 0x },
-   { 0xa224, 0x33a6 },
-   { 0xa228, 0x402d0031 },
-   { 0xa22c, 0x00165f83 },
-   { 0xa230, 0xf100 },
-   { 0xa234, 0x },
-   { 0xa238, 0x00160016 },
-   { 0xa23c, 0x002a002b },
-   { 0xa240, 0x },
-   { 0xa244, 0x },
-   { 0xa248, 0x8000421e },
-   { 0 }
-};
-
-static const struct gt_powermeter ivb_pm_gt1[] = {
-   { 0xa800, 0x },
-   { 0xa804, 0x00021c00 },
-   { 0xa808, 0x0403 },
-   { 0xa80c, 0x02001700 },
-   { 0xa810, 0x05000200 },
-   { 0xa814, 0x },
-   { 0xa818, 

Re: [U-Boot] SPL load ARM Trusted Firmware BL31?

[Michal Simek]

Hi Masahiro,

2016-10-05 19:34 GMT-07:00 Masahiro Yamada :

> Hi Michal,
>
>
> 2016-10-05 23:39 GMT+09:00 Michal Simek :
> > Hi Masahiro,
> >
> > 2016-10-04 20:19 GMT-07:00 Masahiro Yamada <
> yamada.masah...@socionext.com>:
> >
> >> Hi.
> >>
> >> Recently I implemented ARM Trusted Firmware BL31 for my SoCs.
> >>
> >> But, I am wondering how the boot-flow should be.
> >>
> >>
> >>
> >> Here is my situation.
> >>
> >>
> >> [1]
> >> When my company developed its first ARMv8 SoC,
> >> I had to bring up the system very quickly.
> >>
> >> I was familiar with U-Boot and Linux to some extent, but not with ATF
> >> at that time.
> >> Also I was too pressed, so I decided to build up the system without ATF.
> >>
> >> The boot-flow was like this:
> >>
> >>   BootROM  ->  U-Boot SPL  -> U-Boot proper -> Linux
> >>
> >> In this flow, the secure runtime firmware is missing,
> >> so I used Spin-Table for the enable-method.
> >>
> >>
> >> [2]
> >> Now I finished porting ATF BL31.
> >> The low-level init code (basic SoC init + DRAM initialization)
> >> already exists in U-Boot SPL.
> >> So, I am currently re-using SPL, like follows:
> >>
> >>  BootROM ->  U-Boot SPL  -> ATF BL31 -> U-Boot proper (=BL33) -> Linux
> >>
> >>
> >> As far as I know, SPL can not load multiple images such as BL31, BL32,
> BL33
> >> (here BL32 is optional).
> >> So, I hacked my SPL to load multi images
> >> and jump to BL31.
> >>
> >
> > this is not entirely truth. If you look at zynqmp you will find out that
> if
> > you
> > work with atf as kernel and full u-boot as dtb then u-boot SPL can load
> two
> > images.
> > This is what I use. It is a trick but I am not using any changes to get
> it
> > work.
>
>
> Ah, now I see.
>
> The idea I came up with was
> to put every ATF stuff into spl_board_prepare_for_boot().
>


In our ATF implementation we are using structure for passing information
from
fsbl (which loads all images) to ATF to tell ATF what to do.
It means I could use this function to prepare the same in SPL.



>
>
>
> >
> > We are using only BL31 and nothing else.
>
>
> But, prior to commit f3d1cc2ff387ffe22ccd1bdcb2a998ec46149c6d
> (ARM64: zynqmp: Enable SPL for all zynqmp boards),
>
> BootROM -> fsbl -> ATF BL31 -> U-Boot -> Linux
>
> was the only supported solution, yes?
>

yes correct.



>
>
>
> >>
> >>
> >> Recently I saw Simon's binman patches.
> >> It provides a fancy way to pack multiple firmware components into a
> >> single image,
> >> but I did not see the systematic way to load every entry in the image.
> >>   (under way?)
> >>
> >>
> >> I was wondering if I should move my low-level init code
> >> from SPL to ATF BL2 or somewhere.
> >>
> >> Comments are welcome.
> >>
> >
> > I use bootrom -> SPL -> ATF -> full u-boot.
> >
> > I want to use SPL because we have all device drivers in u-boot and
> > in ATF we have only serial driver. If you want to use BL2 just for low
> > level init stuff
> > you can but it is the question if this brings you any value.
>
>
> Yes.  This is one big advantage of using SPL over BL2.
>

right. It is not only about drivers. Also fdt support and high level
functions.
ZynqMP for example has USB dfu boot mode which would be a little bit painful
to do in bl2 but it is almost for free with current SPL.

Thanks,
Michal


-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2 09/12] dm: video: Add driver-model support to vesa graphics

[Simon Glass]

Provide a function to run the Vesa BIOS for a given PCI device and obtain
the resulting configuration (e.g. display size) for use by the video
uclass. This makes it easier to write a video driver that uses vesa and
supports driver model.

Signed-off-by: Simon Glass 
Reviewed-by: Bin Meng 
---

Changes in v2:
- Make vbe_setup_video_priv() static

 drivers/pci/pci_rom.c | 55 +++
 include/vbe.h |  2 ++
 2 files changed, 57 insertions(+)

diff --git a/drivers/pci/pci_rom.c b/drivers/pci/pci_rom.c
index 399055b..21ed17c 100644
--- a/drivers/pci/pci_rom.c
+++ b/drivers/pci/pci_rom.c
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -348,3 +349,57 @@ err:
free(ram);
return ret;
 }
+
+#ifdef CONFIG_DM_VIDEO
+static int vbe_setup_video_priv(struct vesa_mode_info *vesa,
+   struct video_priv *uc_priv,
+   struct video_uc_platdata *plat)
+{
+   if (!vesa->x_resolution)
+   return -ENXIO;
+   uc_priv->xsize = vesa->x_resolution;
+   uc_priv->ysize = vesa->y_resolution;
+   switch (vesa->bits_per_pixel) {
+   case 32:
+   case 24:
+   uc_priv->bpix = VIDEO_BPP32;
+   break;
+   case 16:
+   uc_priv->bpix = VIDEO_BPP16;
+   break;
+   default:
+   return -EPROTONOSUPPORT;
+   }
+   plat->base = vesa->phys_base_ptr;
+   plat->size = vesa->bytes_per_scanline * vesa->y_resolution;
+
+   return 0;
+}
+
+int vbe_setup_video(struct udevice *dev, int (*int15_handler)(void))
+{
+   struct video_uc_platdata *plat = dev_get_uclass_platdata(dev);
+   struct video_priv *uc_priv = dev_get_uclass_priv(dev);
+   int ret;
+
+   /* If we are running from EFI or coreboot, this can't work */
+   if (!ll_boot_init())
+   return -EPERM;
+   bootstage_start(BOOTSTAGE_ID_ACCUM_LCD, "vesa display");
+   ret = dm_pci_run_vga_bios(dev, int15_handler, PCI_ROM_USE_NATIVE |
+   PCI_ROM_ALLOW_FALLBACK);
+   bootstage_accum(BOOTSTAGE_ID_ACCUM_LCD);
+   if (ret) {
+   debug("failed to run video BIOS: %d\n", ret);
+   return ret;
+   }
+
+   ret = vbe_setup_video_priv(_info.vesa, uc_priv, plat);
+   if (ret) {
+   debug("No video mode configured\n");
+   return ret;
+   }
+
+   return 0;
+}
+#endif
diff --git a/include/vbe.h b/include/vbe.h
index 164ccae..a743892 100644
--- a/include/vbe.h
+++ b/include/vbe.h
@@ -106,5 +106,7 @@ extern struct vbe_mode_info mode_info;
 
 struct graphic_device;
 int vbe_get_video_info(struct graphic_device *gdev);
+struct video_priv;
+int vbe_setup_video(struct udevice *dev, int (*int15_handler)(void));
 
 #endif
-- 
2.8.0.rc3.226.g39d4020

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

[U-Boot] [PATCH v2 10/12] x86: Adjust config to support DM_VIDEO

[Simon Glass]

Update the common configuration so that it works correctly when
CONFIG_DM_VIDEO is enabled. This involves dropping the legacy CONFIG_VIDEO
option and changing the stdio device from "vga" to "vidconsole".

Signed-off-by: Simon Glass 
Reviewed-by: Bin Meng 
---

Changes in v2: None

 include/configs/x86-chromebook.h | 10 --
 include/configs/x86-common.h |  2 ++
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/include/configs/x86-chromebook.h b/include/configs/x86-chromebook.h
index 312987e..7fba716 100644
--- a/include/configs/x86-chromebook.h
+++ b/include/configs/x86-chromebook.h
@@ -53,8 +53,14 @@
 
 #define CONFIG_SYS_WHITE_ON_BLACK
 
+#ifdef CONFIG_DM_VIDEO
+#define VIDEO_DEV "vidconsole"
+#else
+#define VIDEO_DEV "vga"
+#endif
+
 #define CONFIG_STD_DEVICES_SETTINGS "stdin=usbkbd,i8042-kbd,serial\0" \
-   "stdout=vga,serial\0" \
-   "stderr=vga,serial\0"
+   "stdout=" VIDEO_DEV ",serial\0" \
+   "stderr=" VIDEO_DEV ",serial\0"
 
 #endif
diff --git a/include/configs/x86-common.h b/include/configs/x86-common.h
index 74b2522..96c53b8 100644
--- a/include/configs/x86-common.h
+++ b/include/configs/x86-common.h
@@ -131,11 +131,13 @@
 /*---
  * Video Configuration
  */
+#ifndef CONFIG_DM_VIDEO
 #define CONFIG_VIDEO
 #define CONFIG_VIDEO_SW_CURSOR
 #define VIDEO_FB_16BPP_WORD_SWAP
 #define CONFIG_VGA_AS_SINGLE_DEVICE
 #define CONFIG_CFB_CONSOLE
+#endif
 #define CONFIG_CONSOLE_SCROLL_LINES 5
 
 /*---
-- 
2.8.0.rc3.226.g39d4020

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

[U-Boot] [PATCH v2 08/12] dm: stdio: Allow lazy probing of video devices

[Simon Glass]

At present all video devices are probed on start-up. It would be better to
probe a device only when it is needed. This can happen if it is referenced
in the stdout environment variable, for example.

Add support for this by searching for a suitable device when needed, probing
it, and finding the stdio device it creates.

Signed-off-by: Simon Glass 
---

Changes in v2:
- Add comment as to why we need #ifndef CONFIG_SYS_CONSOLE_IS_IN_ENV
- Add comment as to why we check for "," in stdio_get_by_name()

 common/stdio.c | 87 +++---
 1 file changed, 83 insertions(+), 4 deletions(-)

diff --git a/common/stdio.c b/common/stdio.c
index f99cfe7..ab9b05d 100644
--- a/common/stdio.c
+++ b/common/stdio.c
@@ -121,19 +121,87 @@ struct list_head* stdio_get_list(void)
return &(devs.list);
 }
 
+#ifdef CONFIG_DM_VIDEO
+/**
+ * stdio_probe_device() - Find a device which provides the given stdio device
+ *
+ * This looks for a device of the given uclass which provides a particular
+ * stdio device. It is currently really only useful for UCLASS_VIDEO.
+ *
+ * Ultimately we want to be able to probe a device by its stdio name. At
+ * present devices register in their probe function (for video devices this
+ * is done in vidconsole_post_probe()) and we don't know what name they will
+ * use until they do so.
+ * TODO(s...@chromium.org): We should be able to determine the name before
+ * probing, and probe the required device.
+ *
+ * @name:  stdio device name (e.g. "vidconsole")
+ * id: Uclass ID of device to look for (e.g. UCLASS_VIDEO)
+ * @sdevp: Returns stdout device, if found, else NULL
+ * @return 0 if found, -ENOENT if no device found with that name, other -ve
+ *on other error
+ */
+static int stdio_probe_device(const char *name, enum uclass_id id,
+ struct stdio_dev **sdevp)
+{
+   struct stdio_dev *sdev;
+   struct udevice *dev;
+   int seq, ret;
+
+   *sdevp = NULL;
+   seq = trailing_strtoln(name, NULL);
+   if (seq == -1)
+   ret = uclass_first_device_err(id, );
+   else
+   ret = uclass_get_device_by_seq(id, seq, );
+   if (ret) {
+   debug("No %s device for seq %d (%s)\n", uclass_get_name(id),
+ seq, name);
+   return ret;
+   }
+   /* The device should be be the last one registered */
+   sdev = list_empty() ? NULL :
+   list_last_entry(, struct stdio_dev, list);
+   if (!sdev || strcmp(sdev->name, name)) {
+   debug("Device '%s' did not register with stdio as '%s'\n",
+ dev->name, name);
+   return -ENOENT;
+   }
+   *sdevp = sdev;
+
+   return 0;
+}
+#endif
+
 struct stdio_dev* stdio_get_by_name(const char *name)
 {
struct list_head *pos;
-   struct stdio_dev *dev;
+   struct stdio_dev *sdev;
 
if(!name)
return NULL;
 
list_for_each(pos, &(devs.list)) {
-   dev = list_entry(pos, struct stdio_dev, list);
-   if(strcmp(dev->name, name) == 0)
-   return dev;
+   sdev = list_entry(pos, struct stdio_dev, list);
+   if (strcmp(sdev->name, name) == 0)
+   return sdev;
}
+#ifdef CONFIG_DM_VIDEO
+   /*
+* We did not find a suitable stdio device. If there is a video
+* driver with a name starting with 'vidconsole', we can try probing
+* that in the hope that it will produce the required stdio device.
+*
+* This function is sometimes called with the entire value of
+* 'stdout', which may include a list of devices separate by commas.
+* Obviously this is not going to work, so we ignore that case. The
+* call path in that case is console_init_r() -> search_device() ->
+* stdio_get_by_name().
+*/
+   if (!strncmp(name, "vidconsole", 10) && !strchr(name, ',') &&
+   !stdio_probe_device(name, UCLASS_VIDEO, ))
+   return sdev;
+#endif
 
return NULL;
 }
@@ -282,6 +350,16 @@ int stdio_add_devices(void)
 #endif
 #endif
 #ifdef CONFIG_DM_VIDEO
+   /*
+* If the console setting is not in environment variables then
+* console_init_r() will not be calling iomux_doenv() (which calls
+* search_device()). So we will not dynamically add devices by
+* calling stdio_probe_device().
+*
+* So just probe all video devices now so that whichever one is
+* required will be available.
+*/
+#ifndef CONFIG_SYS_CONSOLE_IS_IN_ENV
struct udevice *vdev;
 # ifndef CONFIG_DM_KEYBOARD
int ret;
@@ -293,6 +371,7 @@ int stdio_add_devices(void)
;
if (ret)
printf("%s: Video device failed (ret=%d)\n", __func__, ret);
+#endif /* !CONFIG_SYS_CONSOLE_IS_IN_ENV */
 #else
 # 

[U-Boot] [PATCH v2 11/12] dm: x86: Move samus to use new driver model support

[Simon Glass]

Update the samus driver to avoid the direct call to the video BIOS setup.

Signed-off-by: Simon Glass 
Reviewed-by: Bin Meng 
---

Changes in v2: None

 arch/x86/cpu/broadwell/sdram.c |  1 -
 drivers/video/broadwell_igd.c  | 39 +++
 2 files changed, 7 insertions(+), 33 deletions(-)

diff --git a/arch/x86/cpu/broadwell/sdram.c b/arch/x86/cpu/broadwell/sdram.c
index e7befde..74736cd 100644
--- a/arch/x86/cpu/broadwell/sdram.c
+++ b/arch/x86/cpu/broadwell/sdram.c
@@ -291,7 +291,6 @@ void board_debug_uart_init(void)
 
 static const struct udevice_id broadwell_syscon_ids[] = {
{ .compatible = "intel,me", .data = X86_SYSCON_ME },
-   { .compatible = "intel,gma", .data = X86_SYSCON_GMA },
{ }
 };
 
diff --git a/drivers/video/broadwell_igd.c b/drivers/video/broadwell_igd.c
index 4286fd0..beef770 100644
--- a/drivers/video/broadwell_igd.c
+++ b/drivers/video/broadwell_igd.c
@@ -9,10 +9,8 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -20,11 +18,9 @@
 #include 
 #include 
 #include 
-#include 
 #include "i915_reg.h"
 
 struct broadwell_igd_priv {
-   GraphicDevice ctfb;
u8 *regs;
 };
 
@@ -664,10 +660,7 @@ static int broadwell_igd_probe(struct udevice *dev)
 {
struct video_uc_platdata *plat = dev_get_uclass_platdata(dev);
struct video_priv *uc_priv = dev_get_uclass_priv(dev);
-   struct broadwell_igd_priv *priv = dev_get_priv(dev);
bool is_broadwell;
-   GraphicDevice *gdev = >ctfb;
-   int bits_per_pixel;
int ret;
 
if (!ll_boot_init()) {
@@ -683,13 +676,9 @@ static int broadwell_igd_probe(struct udevice *dev)
debug("%s: is_broadwell=%d\n", __func__, is_broadwell);
ret = igd_pre_init(dev, is_broadwell);
if (!ret) {
-   ret = dm_pci_run_vga_bios(dev, broadwell_igd_int15_handler,
- PCI_ROM_USE_NATIVE |
- PCI_ROM_ALLOW_FALLBACK);
-   if (ret) {
-   printf("failed to run video BIOS: %d\n", ret);
-   ret = -EIO;
-   }
+   ret = vbe_setup_video(dev, broadwell_igd_int15_handler);
+   if (ret)
+   debug("failed to run video BIOS: %d\n", ret);
}
if (!ret)
ret = igd_post_init(dev, is_broadwell);
@@ -697,13 +686,8 @@ static int broadwell_igd_probe(struct udevice *dev)
if (ret)
return ret;
 
-   if (vbe_get_video_info(gdev)) {
-   printf("No video mode configured\n");
-   return -ENXIO;
-   }
-
-   /* Use write-through for the graphics memory, 256MB */
-   ret = mtrr_add_request(MTRR_TYPE_WRTHROUGH, gdev->pciBase, 256 << 20);
+   /* Use write-combining for the graphics memory, 256MB */
+   ret = mtrr_add_request(MTRR_TYPE_WRCOMB, plat->base, 256 << 20);
if (!ret)
ret = mtrr_commit(true);
if (ret && ret != -ENOSYS) {
@@ -711,17 +695,8 @@ static int broadwell_igd_probe(struct udevice *dev)
   ret);
}
 
-   bits_per_pixel = gdev->gdfBytesPP * 8;
-   sprintf(gdev->modeIdent, "%dx%dx%d", gdev->winSizeX, gdev->winSizeY,
-   bits_per_pixel);
-   printf("%s\n", gdev->modeIdent);
-   uc_priv->xsize = gdev->winSizeX;
-   uc_priv->ysize = gdev->winSizeY;
-   uc_priv->bpix = ilog2(bits_per_pixel);
-   plat->base = gdev->pciBase;
-   plat->size = gdev->memSize;
-   debug("fb=%x, size %x, display size=%d %d %d\n", gdev->pciBase,
- gdev->memSize, uc_priv->xsize, uc_priv->ysize, uc_priv->bpix);
+   debug("fb=%lx, size %x, display size=%d %d %d\n", plat->base,
+ plat->size, uc_priv->xsize, uc_priv->ysize, uc_priv->bpix);
 
return 0;
 }
-- 
2.8.0.rc3.226.g39d4020

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

[U-Boot] [PATCH v2 07/12] dm: x86: video: Add a driver-model driver for ivybridge graphics

[Simon Glass]

At present we use the legacy vesa driver for graphics. Add a driver which
supports driver model. This can be probed only when needed, removing the
need to start up the display if it is not used.

Signed-off-by: Simon Glass 
---

Changes in v2:
- Drop invalid '1' at start of file
- Comment that no details are available about the magic values

 drivers/video/Kconfig |  12 +
 drivers/video/Makefile|   1 +
 drivers/video/ivybridge_igd.c | 843 ++
 3 files changed, 856 insertions(+)
 create mode 100644 drivers/video/ivybridge_igd.c

diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 97dbb64..fd26690 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -374,6 +374,18 @@ config VIDEO_BROADWELL_IGD
  a special tool which configures the VGA ROM, but the graphics
  resolution can be selected in U-Boot.
 
+config VIDEO_IVYBRIDGE_IGD
+   bool "Enable Intel Ivybridge integration graphics support"
+   depends on X86
+   help
+ This enables support for integrated graphics on Intel ivybridge
+ devices. Initialisation is mostly performed by a VGA boot ROM, with
+ some setup handled by U-Boot itself. The graphics adaptor works as
+ a VESA device and supports LCD panels, eDP and LVDS outputs.
+ Configuration of most aspects of device operation is performed using
+ a special tool which configures the VGA ROM, but the graphics
+ resolution can be selected in U-Boot.
+
 config VIDEO_ROCKCHIP
bool "Enable Rockchip video support"
depends on DM_VIDEO
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index 3f045fe..b888e99 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -20,6 +20,7 @@ obj-$(CONFIG_CONSOLE_TRUETYPE) += console_truetype.o fonts/
 endif
 
 obj-$(CONFIG_VIDEO_BROADWELL_IGD) += broadwell_igd.o
+obj-$(CONFIG_VIDEO_IVYBRIDGE_IGD) += ivybridge_igd.o
 
 obj-$(CONFIG_ATI_RADEON_FB) += ati_radeon_fb.o videomodes.o
 obj-$(CONFIG_ATMEL_HLCD) += atmel_hlcdfb.o
diff --git a/drivers/video/ivybridge_igd.c b/drivers/video/ivybridge_igd.c
new file mode 100644
index 000..94db3dd
--- /dev/null
+++ b/drivers/video/ivybridge_igd.c
@@ -0,0 +1,843 @@
+/*
+ * Copyright (C) 2016 Google, Inc
+ *
+ * SPDX-License-Identifier:GPL-2.0
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct gt_powermeter {
+   u16 reg;
+   u32 value;
+};
+
+/* These are magic values - unfortunately the meaning is unknown */
+static const struct gt_powermeter snb_pm_gt1[] = {
+   { 0xa200, 0xcc00 },
+   { 0xa204, 0x0740 },
+   { 0xa208, 0xfe00 },
+   { 0xa20c, 0x },
+   { 0xa210, 0x1700 },
+   { 0xa214, 0x0021 },
+   { 0xa218, 0x0817fe19 },
+   { 0xa21c, 0x },
+   { 0xa220, 0x },
+   { 0xa224, 0xcc00 },
+   { 0xa228, 0x0740 },
+   { 0xa22c, 0xfe00 },
+   { 0xa230, 0x },
+   { 0xa234, 0x1700 },
+   { 0xa238, 0x0021 },
+   { 0xa23c, 0x0817fe19 },
+   { 0xa240, 0x },
+   { 0xa244, 0x },
+   { 0xa248, 0x8000421e },
+   { 0 }
+};
+
+static const struct gt_powermeter snb_pm_gt2[] = {
+   { 0xa200, 0x33a6 },
+   { 0xa204, 0x402d0031 },
+   { 0xa208, 0x00165f83 },
+   { 0xa20c, 0xf100 },
+   { 0xa210, 0x },
+   { 0xa214, 0x00160016 },
+   { 0xa218, 0x002a002b },
+   { 0xa21c, 0x },
+   { 0xa220, 0x },
+   { 0xa224, 0x33a6 },
+   { 0xa228, 0x402d0031 },
+   { 0xa22c, 0x00165f83 },
+   { 0xa230, 0xf100 },
+   { 0xa234, 0x },
+   { 0xa238, 0x00160016 },
+   { 0xa23c, 0x002a002b },
+   { 0xa240, 0x },
+   { 0xa244, 0x },
+   { 0xa248, 0x8000421e },
+   { 0 }
+};
+
+static const struct gt_powermeter ivb_pm_gt1[] = {
+   { 0xa800, 0x },
+   { 0xa804, 0x00021c00 },
+   { 0xa808, 0x0403 },
+   { 0xa80c, 0x02001700 },
+   { 0xa810, 0x05000200 },
+   { 0xa814, 0x },
+   { 0xa818, 0x00690500 },
+   { 0xa81c, 0x007f },
+   { 0xa820, 0x01002501 },
+   { 0xa824, 0x0300 },
+   { 0xa828, 0x01000331 },
+   { 0xa82c, 0x000c },
+   { 0xa830, 0x00010016 },
+   { 0xa834, 0x01100101 },
+   { 0xa838, 0x00010103 },
+   { 0xa83c, 0x00041300 },
+   { 0xa840, 0x0b30 },
+   { 0xa844, 0x },
+   { 0xa848, 0x7f00 },
+   { 0xa84c, 0x0508 },
+   { 0xa850, 0x0001 },
+   { 0xa854, 0x0004 },
+   { 0xa858, 0x0007 },
+   { 0xa85c, 0x },
+   { 0xa860, 0x0001 },
+   { 0xa248, 0x221e },
+   { 0xa900, 0x },
+   { 0xa904, 0x1c00 },
+   { 0xa908, 0x },

[U-Boot] [PATCH v2 03/12] Fix return value in trailing_strtoln()

[Simon Glass]

This function should return -1 if there is no trailing integer in the
string. Instead it returns 0. Fix it by checking for this condition at the
start.

Signed-off-by: Simon Glass 
Reviewed-by: Bin Meng 
---

Changes in v2: None

 lib/strto.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/lib/strto.c b/lib/strto.c
index a6c0157..e93a4f5 100644
--- a/lib/strto.c
+++ b/lib/strto.c
@@ -160,9 +160,11 @@ long trailing_strtoln(const char *str, const char *end)
 
if (!end)
end = str + strlen(str);
-   for (p = end - 1; p > str; p--) {
-   if (!isdigit(*p))
-   return simple_strtoul(p + 1, NULL, 10);
+   if (isdigit(end[-1])) {
+   for (p = end - 1; p > str; p--) {
+   if (!isdigit(*p))
+   return simple_strtoul(p + 1, NULL, 10);
+   }
}
 
return -1;
-- 
2.8.0.rc3.226.g39d4020

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

[U-Boot] [PATCH v2 06/12] x86: video: Fix typo in broadwell Kconfig

[Simon Glass]

'enabled' should be 'enables'. Fix it.

Signed-off-by: Simon Glass 
Reviewed-by: Bin Meng 
---

Changes in v2: None

 drivers/video/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 8361a71..97dbb64 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -366,7 +366,7 @@ config VIDEO_BROADWELL_IGD
bool "Enable Intel Broadwell integrated graphics device"
depends on X86
help
- This enabled support for integrated graphics on Intel broadwell
+ This enables support for integrated graphics on Intel broadwell
  devices. Initialisation is mostly performed by a VGA boot ROM, with
  some setup handled by U-Boot itself. The graphics adaptor works as
  a VESA device and supports LCD panels, eDP and LVDS outputs.
-- 
2.8.0.rc3.226.g39d4020

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

[U-Boot] [PATCH v2 05/12] dm: core: Add a function to get a uclass name

[Simon Glass]

It is useful in debug() statements to display the name of the uclass for a
device. Add a simple function to provide this.

Signed-off-by: Simon Glass 
Reviewed-by: Bin Meng 
---

Changes in v2:
- Fix typo drive -> driver

 drivers/core/uclass.c | 9 +
 include/dm/uclass.h   | 8 
 2 files changed, 17 insertions(+)

diff --git a/drivers/core/uclass.c b/drivers/core/uclass.c
index de602ae..60610e5 100644
--- a/drivers/core/uclass.c
+++ b/drivers/core/uclass.c
@@ -148,6 +148,15 @@ int uclass_get(enum uclass_id id, struct uclass **ucp)
return 0;
 }
 
+const char *uclass_get_name(enum uclass_id id)
+{
+   struct uclass *uc;
+
+   if (uclass_get(id, ))
+   return NULL;
+   return uc->uc_drv->name;
+}
+
 int uclass_find_device(enum uclass_id id, int index, struct udevice **devp)
 {
struct uclass *uc;
diff --git a/include/dm/uclass.h b/include/dm/uclass.h
index 84f05bc..b583aa8 100644
--- a/include/dm/uclass.h
+++ b/include/dm/uclass.h
@@ -119,6 +119,14 @@ struct uclass_driver {
 int uclass_get(enum uclass_id key, struct uclass **ucp);
 
 /**
+ * uclass_get_name() - Get the name of a uclass driver
+ *
+ * @id: ID to look up
+ * @returns the name of the uclass driver for that ID, or NULL if none
+ */
+const char *uclass_get_name(enum uclass_id id);
+
+/**
  * uclass_get_device() - Get a uclass device based on an ID and index
  *
  * The device is probed to activate it ready for use.
-- 
2.8.0.rc3.226.g39d4020

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

[U-Boot] [PATCH v2 04/12] list: Add list_last_entry() to find the last entry

[Simon Glass]

We have list_first_entry() but in some cases it is useful to find the last
item added to the list. Add a macro for this.

Signed-off-by: Simon Glass 
Reviewed-by: Bin Meng 
---

Changes in v2: None

 include/linux/list.h | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/include/linux/list.h b/include/linux/list.h
index b78851c..5b8d1df 100644
--- a/include/linux/list.h
+++ b/include/linux/list.h
@@ -338,6 +338,17 @@ static inline void list_splice_tail_init(struct list_head 
*list,
list_entry((ptr)->next, type, member)
 
 /**
+ * list_last_entry - get the last element from a list
+ * @ptr:   the list head to take the element from.
+ * @type:  the type of the struct this is embedded in.
+ * @member:the name of the list_struct within the struct.
+ *
+ * Note, that list is expected to be not empty.
+ */
+#define list_last_entry(ptr, type, member) \
+   list_entry((ptr)->prev, type, member)
+
+/**
  * list_for_each   -   iterate over a list
  * @pos:   the  list_head to use as a loop cursor.
  * @head:  the head for your list.
-- 
2.8.0.rc3.226.g39d4020

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

[U-Boot] [PATCH v2 01/12] Revert "x86: broadwell: gpio: Remove the codes to set up pin control"

[Simon Glass]

This makes the assumption that setting up pinctrl in cpu_init_r() is safe.
On samus we need GPIOs before relocation in order to support power control.
This commit fixes the following message on boot:

   initcall sequence ffe5c6f4 failed at call ffe01d3d (err=-1)
   ### ERROR ### Please RESET the board ###

In any case it seems better to leave init to driver model, so that it can
pick up the GPIO driver when it needs it. Since pinctrl is a dependency of
the GPIO driver, we may as well put the dependency there and avoid these
problems.

This reverts commit 9769e05bcf79939bad23a719982dd1f85a110f3c.
Signed-off-by: Simon Glass 
Reviewed-by: Bin Meng 

---

Changes in v2: None

 drivers/gpio/intel_broadwell_gpio.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/gpio/intel_broadwell_gpio.c 
b/drivers/gpio/intel_broadwell_gpio.c
index 8b50900..81ce446 100644
--- a/drivers/gpio/intel_broadwell_gpio.c
+++ b/drivers/gpio/intel_broadwell_gpio.c
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -118,6 +119,12 @@ static int broadwell_gpio_probe(struct udevice *dev)
struct broadwell_bank_platdata *plat = dev_get_platdata(dev);
struct gpio_dev_priv *uc_priv = dev_get_uclass_priv(dev);
struct broadwell_bank_priv *priv = dev_get_priv(dev);
+   struct udevice *pinctrl;
+   int ret;
+
+   /* Set up pin control if available */
+   ret = syscon_get_by_driver_data(X86_SYSCON_PINCONF, );
+   debug("%s, pinctrl=%p, ret=%d\n", __func__, pinctrl, ret);
 
uc_priv->gpio_count = GPIO_PER_BANK;
uc_priv->bank_name = plat->bank_name;
-- 
2.8.0.rc3.226.g39d4020

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

[U-Boot] [PATCH v2 02/12] x86: Add an accelerated memmove() function

[Simon Glass]

Bring in a faster memmove() from Linux 4.7. This speeds up scrolling on the
display.

Signed-off-by: Simon Glass 
---

Changes in v2:
- Move the code into string.c
- Fix multi-line comments that should not be

 arch/x86/include/asm/string.h |   2 +-
 arch/x86/lib/string.c | 161 ++
 2 files changed, 162 insertions(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/string.h b/arch/x86/include/asm/string.h
index 0ad612f..38afd23 100644
--- a/arch/x86/include/asm/string.h
+++ b/arch/x86/include/asm/string.h
@@ -17,7 +17,7 @@ extern char * strchr(const char * s, int c);
 #define __HAVE_ARCH_MEMCPY
 extern void * memcpy(void *, const void *, __kernel_size_t);
 
-#undef __HAVE_ARCH_MEMMOVE
+#define __HAVE_ARCH_MEMMOVE
 extern void * memmove(void *, const void *, __kernel_size_t);
 
 #undef __HAVE_ARCH_MEMCHR
diff --git a/arch/x86/lib/string.c b/arch/x86/lib/string.c
index 6c66431..5343c2b 100644
--- a/arch/x86/lib/string.c
+++ b/arch/x86/lib/string.c
@@ -130,3 +130,164 @@ void *memcpy(void *dstpp, const void *srcpp, size_t len)
 
return dstpp;
 }
+
+void *memmove(void *dest, const void *src, size_t n)
+{
+   int d0, d1, d2, d3, d4, d5;
+   char *ret = dest;
+
+   __asm__ __volatile__(
+   /* Handle more 16 bytes in loop */
+   "cmp $0x10, %0\n\t"
+   "jb 1f\n\t"
+
+   /* Decide forward/backward copy mode */
+   "cmp %2, %1\n\t"
+   "jb 2f\n\t"
+
+   /*
+* movs instruction have many startup latency
+* so we handle small size by general register.
+*/
+   "cmp  $680, %0\n\t"
+   "jb 3f\n\t"
+   /* movs instruction is only good for aligned case */
+   "mov %1, %3\n\t"
+   "xor %2, %3\n\t"
+   "and $0xff, %3\n\t"
+   "jz 4f\n\t"
+   "3:\n\t"
+   "sub $0x10, %0\n\t"
+
+   /* We gobble 16 bytes forward in each loop */
+   "3:\n\t"
+   "sub $0x10, %0\n\t"
+   "mov 0*4(%1), %3\n\t"
+   "mov 1*4(%1), %4\n\t"
+   "mov  %3, 0*4(%2)\n\t"
+   "mov  %4, 1*4(%2)\n\t"
+   "mov 2*4(%1), %3\n\t"
+   "mov 3*4(%1), %4\n\t"
+   "mov  %3, 2*4(%2)\n\t"
+   "mov  %4, 3*4(%2)\n\t"
+   "lea  0x10(%1), %1\n\t"
+   "lea  0x10(%2), %2\n\t"
+   "jae 3b\n\t"
+   "add $0x10, %0\n\t"
+   "jmp 1f\n\t"
+
+   /* Handle data forward by movs */
+   ".p2align 4\n\t"
+   "4:\n\t"
+   "mov -4(%1, %0), %3\n\t"
+   "lea -4(%2, %0), %4\n\t"
+   "shr $2, %0\n\t"
+   "rep movsl\n\t"
+   "mov %3, (%4)\n\t"
+   "jmp 11f\n\t"
+   /* Handle data backward by movs */
+   ".p2align 4\n\t"
+   "6:\n\t"
+   "mov (%1), %3\n\t"
+   "mov %2, %4\n\t"
+   "lea -4(%1, %0), %1\n\t"
+   "lea -4(%2, %0), %2\n\t"
+   "shr $2, %0\n\t"
+   "std\n\t"
+   "rep movsl\n\t"
+   "mov %3,(%4)\n\t"
+   "cld\n\t"
+   "jmp 11f\n\t"
+
+   /* Start to prepare for backward copy */
+   ".p2align 4\n\t"
+   "2:\n\t"
+   "cmp  $680, %0\n\t"
+   "jb 5f\n\t"
+   "mov %1, %3\n\t"
+   "xor %2, %3\n\t"
+   "and $0xff, %3\n\t"
+   "jz 6b\n\t"
+
+   /* Calculate copy position to tail */
+   "5:\n\t"
+   "add %0, %1\n\t"
+   "add %0, %2\n\t"
+   "sub $0x10, %0\n\t"
+
+   /* We gobble 16 bytes backward in each loop */
+   "7:\n\t"
+   "sub $0x10, %0\n\t"
+
+   "mov -1*4(%1), %3\n\t"
+   "mov -2*4(%1), %4\n\t"
+   "mov  %3, -1*4(%2)\n\t"
+   "mov  %4, -2*4(%2)\n\t"
+   "mov -3*4(%1), %3\n\t"
+   "mov -4*4(%1), %4\n\t"
+   "mov  %3, -3*4(%2)\n\t"
+   "mov  %4, -4*4(%2)\n\t"
+   "lea  -0x10(%1), %1\n\t"
+   "lea  -0x10(%2), %2\n\t"
+   "jae 7b\n\t"
+   /* Calculate copy position to head */
+   "add $0x10, %0\n\t"
+   "sub %0, %1\n\t"
+   "sub %0, %2\n\t"
+
+   /* Move data from 8 bytes to 15 bytes */
+   ".p2align 4\n\t"
+   "1:\n\t"
+   "cmp $8, %0\n\t"
+   "jb 8f\n\t"
+   "mov 0*4(%1), %3\n\t"
+   "mov 1*4(%1), %4\n\t"
+   "mov -2*4(%1, %0), %5\n\t"
+   "mov -1*4(%1, %0), %1\n\t"
+
+   "mov  %3, 0*4(%2)\n\t"
+   "mov  

[U-Boot] [PATCH v2 00/12] dm: x86: Improve vesa driver-model support

[Simon Glass]

At present samus uses driver model but link does not. This series fixes
this and adds a few features to make it easier to support driver-model
video on other machines that use vesa.

It also includes a faster memmove() function which speeds up scrolling
dramatically.

Changes in v2:
- Move the code into string.c
- Fix multi-line comments that should not be
- Fix typo drive -> driver
- Drop invalid '1' at start of file
- Comment that no details are available about the magic values
- Add comment as to why we need #ifndef CONFIG_SYS_CONSOLE_IS_IN_ENV
- Add comment as to why we check for "," in stdio_get_by_name()
- Make vbe_setup_video_priv() static

Simon Glass (12):
  Revert "x86: broadwell: gpio: Remove the codes to set up pin control"
  x86: Add an accelerated memmove() function
  Fix return value in trailing_strtoln()
  list: Add list_last_entry() to find the last entry
  dm: core: Add a function to get a uclass name
  x86: video: Fix typo in broadwell Kconfig
  dm: x86: video: Add a driver-model driver for ivybridge graphics
  dm: stdio: Allow lazy probing of video devices
  dm: video: Add driver-model support to vesa graphics
  x86: Adjust config to support DM_VIDEO
  dm: x86: Move samus to use new driver model support
  dm: x86: Move link to use driver model for video

 arch/x86/cpu/broadwell/sdram.c |   1 -
 arch/x86/cpu/ivybridge/Makefile|   1 -
 arch/x86/cpu/ivybridge/bd82x6x.c   |  12 --
 arch/x86/cpu/ivybridge/early_me.c  |   1 -
 arch/x86/cpu/ivybridge/gma.h   | 156 
 arch/x86/cpu/ivybridge/model_206ax.c   |   1 -
 arch/x86/cpu/ivybridge/sata.c  |   1 -
 arch/x86/include/asm/arch-ivybridge/bd82x6x.h  |  12 --
 arch/x86/include/asm/cpu.h |   1 -
 arch/x86/include/asm/string.h  |   2 +-
 arch/x86/lib/string.c  | 161 +
 common/stdio.c |  87 ++-
 configs/chromebook_link_defconfig  |   2 +
 drivers/core/uclass.c  |   9 ++
 drivers/gpio/intel_broadwell_gpio.c|   7 +
 drivers/pci/pci_rom.c  |  55 +++
 drivers/video/Kconfig  |  14 +-
 drivers/video/Makefile |   1 +
 drivers/video/broadwell_igd.c  |  39 +
 .../gma.c => drivers/video/ivybridge_igd.c |  77 +-
 include/configs/x86-chromebook.h   |  10 +-
 include/configs/x86-common.h   |   2 +
 include/dm/uclass.h|   8 +
 include/linux/list.h   |  11 ++
 include/vbe.h  |   2 +
 lib/strto.c|   8 +-
 26 files changed, 410 insertions(+), 271 deletions(-)
 delete mode 100644 arch/x86/cpu/ivybridge/gma.h
 delete mode 100644 arch/x86/include/asm/arch-ivybridge/bd82x6x.h
 rename arch/x86/cpu/ivybridge/gma.c => drivers/video/ivybridge_igd.c (94%)

-- 
2.8.0.rc3.226.g39d4020

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

Re: [U-Boot] SPL load ARM Trusted Firmware BL31?

[Masahiro Yamada]

Hi Michal,


2016-10-05 23:39 GMT+09:00 Michal Simek :
> Hi Masahiro,
>
> 2016-10-04 20:19 GMT-07:00 Masahiro Yamada :
>
>> Hi.
>>
>> Recently I implemented ARM Trusted Firmware BL31 for my SoCs.
>>
>> But, I am wondering how the boot-flow should be.
>>
>>
>>
>> Here is my situation.
>>
>>
>> [1]
>> When my company developed its first ARMv8 SoC,
>> I had to bring up the system very quickly.
>>
>> I was familiar with U-Boot and Linux to some extent, but not with ATF
>> at that time.
>> Also I was too pressed, so I decided to build up the system without ATF.
>>
>> The boot-flow was like this:
>>
>>   BootROM  ->  U-Boot SPL  -> U-Boot proper -> Linux
>>
>> In this flow, the secure runtime firmware is missing,
>> so I used Spin-Table for the enable-method.
>>
>>
>> [2]
>> Now I finished porting ATF BL31.
>> The low-level init code (basic SoC init + DRAM initialization)
>> already exists in U-Boot SPL.
>> So, I am currently re-using SPL, like follows:
>>
>>  BootROM ->  U-Boot SPL  -> ATF BL31 -> U-Boot proper (=BL33) -> Linux
>>
>>
>> As far as I know, SPL can not load multiple images such as BL31, BL32, BL33
>> (here BL32 is optional).
>> So, I hacked my SPL to load multi images
>> and jump to BL31.
>>
>
> this is not entirely truth. If you look at zynqmp you will find out that if
> you
> work with atf as kernel and full u-boot as dtb then u-boot SPL can load two
> images.
> This is what I use. It is a trick but I am not using any changes to get it
> work.


Ah, now I see.

The idea I came up with was
to put every ATF stuff into spl_board_prepare_for_boot().



>
> We are using only BL31 and nothing else.


But, prior to commit f3d1cc2ff387ffe22ccd1bdcb2a998ec46149c6d
(ARM64: zynqmp: Enable SPL for all zynqmp boards),

BootROM -> fsbl -> ATF BL31 -> U-Boot -> Linux

was the only supported solution, yes?



>>
>>
>> Recently I saw Simon's binman patches.
>> It provides a fancy way to pack multiple firmware components into a
>> single image,
>> but I did not see the systematic way to load every entry in the image.
>>   (under way?)
>>
>>
>> I was wondering if I should move my low-level init code
>> from SPL to ATF BL2 or somewhere.
>>
>> Comments are welcome.
>>
>
> I use bootrom -> SPL -> ATF -> full u-boot.
>
> I want to use SPL because we have all device drivers in u-boot and
> in ATF we have only serial driver. If you want to use BL2 just for low
> level init stuff
> you can but it is the question if this brings you any value.


Yes.  This is one big advantage of using SPL over BL2.




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

Re: [U-Boot] [PATCH v2 2/2] tools: buildman: Add compiler wrapper

[Simon Glass]

On 4 October 2016 at 15:33, York Sun  wrote:
> Now we can use compiler wrapper such as ccache or distcc for buildman.
>
> Signed-off-by: York Sun 
> CC: Simon Glass 
> Acked-by: Simon Glass 
>
> ---
>
> Changes in v2:
>   Move preparing variable wrapper to GetWrapper()
>
>  tools/buildman/README   |  9 +
>  tools/buildman/toolchain.py | 18 --
>  2 files changed, 25 insertions(+), 2 deletions(-)

Applied to u-boot-dm, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 1/2] tools: buildmand: Remove duplicated code

[Simon Glass]

On 4 October 2016 at 15:35, york sun  wrote:
> Oops. Please fix the subject when merging. It should read
>
> "buildman" instead of "buildmand".

Fixed and:

Applied to u-boot-dm, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 08/10] binman: Automatically include a U-Boot .dtsi file

[Tom Rini]

On Wed, Oct 05, 2016 at 10:51:04AM -0600, Simon Glass wrote:
> Hi Masahiro,
> 
> On 4 October 2016 at 21:51, Masahiro Yamada
>  wrote:
> >
> > 2016-10-05 9:25 GMT+09:00 Simon Glass :
> > > For boards that need U-Boot-specific additions to the device tree, it is
> > > a minor annoyance to have to add these each time the tree is synced with
> > > upstream.
> > >
> > > Add a means to include a file (e.g. u-boot.dtsi) automatically into the 
> > > .dts
> > > file before it is compiled.
> > >
> > > The file uses is the first one that exists in this list:
> > >
> > >arch//dts/-u-boot.dtsi
> > >arch//dts/-u-boot.dtsi
> > >arch//dts/-u-boot.dtsi
> > >arch//dts/u-boot.dtsi
> > >
> > > Signed-off-by: Simon Glass 
> > > Suggested-by: Tom Rini 
> > > ---
> > >
> > > Changes in v3:
> > > - Add a new patch to automatically include a U-Boot .dtsi file
> > >
> > > Changes in v2: None
> > >
> > >  scripts/Makefile.lib | 15 ++-
> > >  1 file changed, 14 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
> > > index 2539ba5..b414a0c 100644
> > > --- a/scripts/Makefile.lib
> > > +++ b/scripts/Makefile.lib
> > > @@ -164,6 +164,17 @@ cpp_flags  = -Wp,-MD,$(depfile) 
> > > $(NOSTDINC_FLAGS) $(UBOOTINCLUDE) \
> > >
> > >  ld_flags   = $(LDFLAGS) $(ldflags-y)
> > >
> > > +dts_dir = $(srctree)/arch/$(ARCH)/dts
> > > +
> > > +# Try these files in order to find the U-Boot-specific .dtsi include file
> > > +binman_dtsi_options = $(wildcard $(dts_dir)/$(basename $(notdir 
> > > $<))-u-boot.dtsi) \
> > > +   $(wildcard $(dts_dir)/$(subst 
> > > $\",,$(CONFIG_SYS_CPU))-u-boot.dtsi) \
> > > +   $(wildcard $(dts_dir)/$(subst 
> > > $\",,$(CONFIG_SYS_VENDOR))-u-boot.dtsi) \
> > > +   $(wildcard $(dts_dir)/u-boot.dtsi)
> > > +
> > > +# We use the first match
> > > +binman_dtsi = $(firstword $(binman_dtsi_options))
> > > +
> >
> >
> > I do not think this feature is binman-specific.
> >
> > Perhaps u_boot_dtsi?
> >
> > We are already suffering from U-Boot specific properties like
> > "u-boot,dm-pre-reloc", which make it difficult to
> > simply copy DT files from the kernel tree.
> > So, my first guess was this feature might be useful
> > to split such properties out to *-u-boot.dtsi.
> > (it is a trade-off of more and more DT files, though.)
> 
> Yes that was Tom's intent. True, it is not binman-specific and I'm
> happy to change the variable, but let's see if this solves the problem
> first.

It certainly looks like it, thanks!  Perhaps a 11/10 patch to migrate
some platforms u-boot,dm-pre-reloc flags? :)

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 10/10] dtoc: Make integer division python 3.x safe

[Simon Glass]

On 27 September 2016 at 09:03, Paul Burton  wrote:
> If we use the '/' operator then python 3.x will produce a float, and
> refuse to multiply the string sequence in Conv_name_to_c by it with:
>
> TypeError: can't multiply sequence by non-int of type 'float'
>
> Use the '//' operator instead to enforce that we want integer rather
> than floating point division.
>
> Signed-off-by: Paul Burton 
> Acked-by: Simon Glass 
>
> ---
>
> Changes in v2: None
>
>  tools/dtoc/dtoc.py | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Applied to u-boot-dm, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 08/10] dtoc: Use items() to iterate over dictionaries in python 3.x

[Simon Glass]

On 27 September 2016 at 11:55, Simon Glass  wrote:
> On 27 September 2016 at 09:03, Paul Burton  wrote:
>> In python 3.x the iteritems() method has been removed from dictionaries,
>> and the items() method does effectively the same thing. On python 2.x
>> using items() is a little less efficient since it involves copying data,
>> but as speed isn't a concern in the affected code switch to using
>> items() anyway for simplicity.
>>
>> Signed-off-by: Paul Burton 
>>
>> ---
>>
>> Changes in v2:
>> - Just use items() for all python versions
>>
>>  tools/dtoc/dtoc.py | 8 
>>  tools/dtoc/fdt_fallback.py | 2 +-
>>  2 files changed, 5 insertions(+), 5 deletions(-)
>
> Acked-by: Simon Glass 

Applied to u-boot-dm, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 06/10] patman: Use items() to iterate over dictionaries

[Simon Glass]

On 27 September 2016 at 11:55, Simon Glass  wrote:
> On 27 September 2016 at 09:03, Paul Burton  wrote:
>> In python 3.x the iteritems() method has been removed from dictionaries,
>> and the items() method does effectively the same thing. On python 2.x
>> using items() is a little less efficient since it involves copying data,
>> but as speed isn't a concern in this code switch to using items() anyway
>> for simplicity.
>>
>> Signed-off-by: Paul Burton 
>>
>> ---
>>
>> Changes in v2:
>> - Just use items() for all python versions
>>
>>  tools/patman/settings.py | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> Acked-by: Simon Glass 

Applied to u-boot-dm, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 07/10] patman: Fix doctest StringIO import for python 3.x

[Simon Glass]

On 27 September 2016 at 11:55, Simon Glass  wrote:
> On 27 September 2016 at 09:03, Paul Burton  wrote:
>> In python 3.x StringIO is no longer a module, and the class can instead
>> be found in the io module. Adjust the code in the doctest input to
>> account for both.
>>
>> Signed-off-by: Paul Burton 
>>
>> ---
>>
>> Changes in v2:
>> - New patch, need found by running --test.
>>
>>  tools/patman/settings.py | 13 -
>>  1 file changed, 8 insertions(+), 5 deletions(-)
>
> Acked-by: Simon Glass 

Applied to u-boot-dm, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 09/10] dtoc: Decode strings for struct.unpack on python 3.x

[Simon Glass]

On 27 September 2016 at 09:03, Paul Burton  wrote:
> On python 3.x struct.unpack will complain if we provide it with a
> string since it expects to operate on a bytes object. In order to
> satisfy this requirement, encode the string to a bytes object when
> running on python 3.x.
>
> Signed-off-by: Paul Burton 
> Acked-by: Simon Glass 
> ---
>
> Changes in v2: None
>
>  tools/dtoc/fdt_util.py | 3 +++
>  1 file changed, 3 insertions(+)

Applied to u-boot-dm, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 04/10] patman: Import 'configparser' lower case to be python 3.x safe

[Simon Glass]

On 27 September 2016 at 09:03, Paul Burton  wrote:
> In python 3.x module names used in import statements are case sensitive,
> and the configparser module is named in all lower-case. Import it as such
> in order to avoid errors when running with python 3.x.
>
> Signed-off-by: Paul Burton 
> Acked-by: Simon Glass 
> ---
>
> Changes in v2: None
>
>  tools/patman/settings.py | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)

Applied to u-boot-dm, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 02/10] patman: Make print statements python 3.x safe

[Simon Glass]

On 27 September 2016 at 09:03, Paul Burton  wrote:
> In python 3.x, print must be used as a function call. Convert all print
> statements to the function call style, importing from __future__ where
> we print with no trailing newline or print to a file object.
>
> Signed-off-by: Paul Burton 
> Acked-by: Simon Glass 
> ---
>
> Changes in v2: None
>
>  tools/patman/checkpatch.py | 16 
>  tools/patman/get_maintainer.py |  2 +-
>  tools/patman/gitutil.py|  6 +++---
>  tools/patman/patchstream.py|  6 +++---
>  tools/patman/patman.py | 12 ++--
>  tools/patman/series.py | 38 --
>  tools/patman/settings.py   | 16 +---
>  tools/patman/terminal.py   | 12 +++-
>  tools/patman/test.py   |  2 +-
>  9 files changed, 58 insertions(+), 52 deletions(-)

Applied to u-boot-dm, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 09/10] RFC: Use binman for a sunxi board

[Tom Rini]

On Tue, Oct 04, 2016 at 06:25:39PM -0600, Simon Glass wrote:
> Add an example usage of binman for a sunxi board. This involves adding the
> image definition to the device tree and using it in the Makefile.
> 
> This is for example only.
> 
> Signed-off-by: Simon Glass 
> ---
> 
> Changes in v3:
> - Use a -u-boot.dtsi file for the binman changes
> 
> Changes in v2: None
> 
>  Makefile|  4 +---
>  arch/arm/dts/sun7i-a20-pcduino3-u-boot.dtsi | 14 ++
>  2 files changed, 15 insertions(+), 3 deletions(-)
>  create mode 100644 arch/arm/dts/sun7i-a20-pcduino3-u-boot.dtsi

OK, we have a board example for arm and a platform example for x86.  But
lets move this to non-RFC and provide the sunxi example above as the
vendor one (the sunxi rule that you remove is for all sunxi).

Perhaps one of the am335x vboot examples would be the right place to
find a board-specific use for binman?

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 03/10] patman: Make exception handling python 3.x safe

[Simon Glass]

On 27 September 2016 at 09:03, Paul Burton  wrote:
> Syntax for exception handling is a little more strict in python 3.x.
> Convert all uses to a form accepted by both python 2.x & python 3.x.
>
> Signed-off-by: Paul Burton 
> Acked-by: Simon Glass 
> ---
>
> Changes in v2: None
>
>  tools/patman/command.py |  2 +-
>  tools/patman/cros_subprocess.py |  2 +-
>  tools/patman/gitutil.py | 12 ++--
>  3 files changed, 8 insertions(+), 8 deletions(-)

Applied to u-boot-dm, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] SPL load ARM Trusted Firmware BL31?

[Masahiro Yamada]

Hi Simon,


2016-10-06 1:50 GMT+09:00 Simon Glass :

> Long term, I am wondering if ATF could be a library instead of a
> separate binary? Or perhaps it could be build so that it can be linked
> against.


ATF is runtime firmware, so it will stay there while the system is running.
On the other hand, the memory allocated for U-Boot can be freed
after the system boot up.


In the first place, this is a license issue.

U-Boot GPL vs ATF BSD.

I think they can not be linked together.




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

Re: [U-Boot] [PATCH v2 01/10] patman: Replace tabs with spaces

[Simon Glass]

On 27 September 2016 at 09:03, Paul Burton  wrote:
> In preparation for running on python 3.x, which will refuse to run
> scripts which mix tabs & spaces for indentation, replace 2 tab
> characters present in series.py with spaces.
>
> Signed-off-by: Paul Burton 
> Acked-by: Simon Glass 
> ---
>
> Changes in v2: None
>
>  tools/patman/series.py | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

Applied to u-boot-dm, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 05/10] patman: Decode stdout/stderr as utf8, be python 3.x safe

[Simon Glass]

Hi Paul,

On 27 September 2016 at 09:03, Paul Burton  wrote:
> In python 3.x reading stdout or stdin will produce a bytestring rather
> than a string. Decode it in CommunicateFilter such that the rest of the
> code can continue to deal with strings. This works fine with python 2.x
> too.
>
> Signed-off-by: Paul Burton 
> Acked-by: Simon Glass 
> ---
>
> Changes in v2: None
>
>  tools/patman/cros_subprocess.py | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/tools/patman/cros_subprocess.py b/tools/patman/cros_subprocess.py
> index ebd4300..922e560 100644
> --- a/tools/patman/cros_subprocess.py
> +++ b/tools/patman/cros_subprocess.py
> @@ -189,7 +189,7 @@ class Popen(subprocess.Popen):
>  data = ""
>  # We will get an error on read if the pty is closed
>  try:
> -data = os.read(self.stdout.fileno(), 1024)
> +data = os.read(self.stdout.fileno(), 1024).decode('utf8')
>  except OSError:
>  pass
>  if data == "":
> @@ -204,7 +204,7 @@ class Popen(subprocess.Popen):
>  data = ""
>  # We will get an error on read if the pty is closed
>  try:
> -data = os.read(self.stderr.fileno(), 1024)
> +data = os.read(self.stderr.fileno(), 1024).decode('utf8')
>  except OSError:
>  pass
>  if data == "":
> --
> 2.10.0
>

Unfortunately this causes an error:

$ buildman -b dm-push sandbox
boards.cfg is up to date. Nothing to do.
Building 16 commits for 3 boards (3 threads, 3 jobs per thread)
Traceback (most recent call last):
  File "/home/sglass/bin/buildman", line 64, in 
ret_code = control.DoBuildman(options, args)
  File 
"/scratch/sglass/cosarm/src/third_party/u-boot/files/tools/buildman/control.py",
line 300, in DoBuildman
options.keep_outputs, options.verbose)
  File 
"/scratch/sglass/cosarm/src/third_party/u-boot/files/tools/buildman/builder.py",
line 1433, in BuildBoards
self._PrepareOutputSpace()
  File 
"/scratch/sglass/cosarm/src/third_party/u-boot/files/tools/buildman/builder.py",
line 1399, in _PrepareOutputSpace
dir_list.append(self._GetOutputDir(commit_upto))
  File 
"/scratch/sglass/cosarm/src/third_party/u-boot/files/tools/buildman/builder.py",
line 449, in _GetOutputDir
subject = commit.subject.translate(trans_valid_chars)
TypeError: character mapping must return integer, None or unicode

Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] ACPI in general

[Tom Rini]

On Wed, Oct 05, 2016 at 08:48:55PM -0500, Timur Tabi wrote:
> Tom Rini wrote:
> >Well, I wouldn't phrase it quite like that.  I would ask, do we want to
> >go down this path?  How far down would we want to go, if so?
> 
> ACPI is pretty complicated, more so than DT.  UEFI is also open
> source.  I think you need to find a very compelling reason to
> reinvent the wheel.

Yes.  But in brief, we also don't go fully down the ACPI path for x86.
But we can do "something".

I assume you mean EDK II when you say UEFI is open source, and yes
that's true.  But I've said in other places (and other contexts) choices
make all projects stronger.

> ACPI on ARM is reserved for ARM Servers, which is a small market (in
> term of number of units) compared to all other ARM chips.

I think that takes too narrow of a view.  If silicon is sold, someone
will put it somewhere.  And if there's firmware that works, and the
buyer can modify to suit their design, they'll use it.

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] ACPI in general

[Timur Tabi]

Tom Rini wrote:

Well, I wouldn't phrase it quite like that.  I would ask, do we want to
go down this path?  How far down would we want to go, if so?


ACPI is pretty complicated, more so than DT.  UEFI is also open source. 
 I think you need to find a very compelling reason to reinvent the wheel.


ACPI on ARM is reserved for ARM Servers, which is a small market (in 
term of number of units) compared to all other ARM chips.


--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the
Code Aurora Forum, hosted by The Linux Foundation.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] ACPI in general

[Timur Tabi]

On Wed, Oct 5, 2016 at 9:46 AM, Simon Glass  wrote:
>> Is there any activity to bring ACPI to other than x86 arch? If not, do
>> we have a plan to do so?
>
> Not that I know of, sorry.

Note that ACPI for ARM exists on Linux already, and as far as I know,
all ARM ACPI systems use UEFI, not U-Boot.

-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v3 03/10] arm: dts: imx7: add pinctrl defines

[Stefan Agner]

From: Stefan Agner 

Add pinctrl defines for NXP i.MX 7Solo/7Dual SoC. The pinctrl format
is compatible to the Linux kernel, hence this file is a simple copy
from the Linux kernel (commit 97f5c1817b7e).

Signed-off-by: Stefan Agner 
---

 arch/arm/dts/imx7d-pinfunc.h | 1151 ++
 1 file changed, 1151 insertions(+)
 create mode 100644 arch/arm/dts/imx7d-pinfunc.h

diff --git a/arch/arm/dts/imx7d-pinfunc.h b/arch/arm/dts/imx7d-pinfunc.h
new file mode 100644
index 000..32d2464
--- /dev/null
+++ b/arch/arm/dts/imx7d-pinfunc.h
@@ -0,0 +1,1151 @@
+/*
+ * Copyright (C) 2014-2015 Freescale Semiconductor, Inc.
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#ifndef __DTS_IMX7D_PINFUNC_H
+#define __DTS_IMX7D_PINFUNC_H
+
+/*
+ * The pin function ID is a tuple of
+ * 
+ */
+
+#define MX7D_PAD_GPIO1_IO00__GPIO1_IO00x 
0x0030 0x 0x0 0x0
+#define MX7D_PAD_GPIO1_IO00__PWM4_OUT 0x 
0x0030 0x 0x1 0x0
+#define MX7D_PAD_GPIO1_IO00__WDOD1_WDOG_ANY   0x 
0x0030 0x 0x2 0x0
+#define MX7D_PAD_GPIO1_IO00__WDOD1_WDOG_B 0x 
0x0030 0x 0x3 0x0
+#define MX7D_PAD_GPIO1_IO00__WDOD1_WDOG__RST_B_DEB0x 
0x0030 0x 0x4 0x0
+#define MX7D_PAD_GPIO1_IO01__GPIO1_IO10x0004 
0x0034 0x 0x0 0x0
+#define MX7D_PAD_GPIO1_IO01__PWM1_OUT 0x0004 
0x0034 0x 0x1 0x0
+#define MX7D_PAD_GPIO1_IO01__CCM_ENET_REF_CLK30x0004 
0x0034 0x 0x2 0x0
+#define MX7D_PAD_GPIO1_IO01__SAI1_MCLK0x0004 
0x0034 0x 0x3 0x0
+#define MX7D_PAD_GPIO1_IO01__ANATOP_24M_OUT   0x0004 
0x0034 0x 0x4 0x0
+#define MX7D_PAD_GPIO1_IO01__OBSERVE0_OUT 0x0004 
0x0034 0x 0x6 0x0
+#define MX7D_PAD_GPIO1_IO02__GPIO1_IO20x0008 
0x0038 0x 0x0 0x0
+#define MX7D_PAD_GPIO1_IO02__PWM2_OUT 0x0008 
0x0038 0x 0x1 0x0
+#define MX7D_PAD_GPIO1_IO02__CCM_ENET_REF_CLK10x0008 
0x0038 0x0564 0x2 0x3
+#define MX7D_PAD_GPIO1_IO02__SAI2_MCLK0x0008 
0x0038 0x 0x3 0x0
+#define MX7D_PAD_GPIO1_IO02__CCM_CLKO10x0008 
0x0038 0x 0x5 0x0
+#define MX7D_PAD_GPIO1_IO02__OBSERVE1_OUT 0x0008 
0x0038 0x 0x6 0x0
+#define MX7D_PAD_GPIO1_IO02__USB_OTG1_ID  0x0008 
0x0038 0x0734 0x7 0x3
+#define MX7D_PAD_GPIO1_IO03__GPIO1_IO30x000C 
0x003C 0x 0x0 0x0
+#define MX7D_PAD_GPIO1_IO03__PWM3_OUT 0x000C 
0x003C 0x 0x1 0x0
+#define MX7D_PAD_GPIO1_IO03__CCM_ENET_REF_CLK20x000C 
0x003C 0x0570 0x2 0x3
+#define MX7D_PAD_GPIO1_IO03__SAI3_MCLK0x000C 
0x003C 0x 0x3 0x0
+#define MX7D_PAD_GPIO1_IO03__CCM_CLKO20x000C 
0x003C 0x 0x5 0x0
+#define MX7D_PAD_GPIO1_IO03__OBSERVE2_OUT 0x000C 
0x003C 0x 0x6 0x0
+#define MX7D_PAD_GPIO1_IO03__USB_OTG2_ID  0x000C 
0x003C 0x0730 0x7 0x3
+#define MX7D_PAD_GPIO1_IO04__GPIO1_IO40x0010 
0x0040 0x 0x0 0x0
+#define MX7D_PAD_GPIO1_IO04__USB_OTG1_OC  0x0010 
0x0040 0x072C 0x1 0x1
+#define MX7D_PAD_GPIO1_IO04__FLEXTIMER1_CH4   0x0010 
0x0040 0x0594 0x2 0x1
+#define MX7D_PAD_GPIO1_IO04__UART5_CTS_B  0x0010 
0x0040 0x0710 0x3 0x4
+#define MX7D_PAD_GPIO1_IO04__I2C1_SCL 0x0010 
0x0040 0x05D4 0x4 0x2
+#define MX7D_PAD_GPIO1_IO04__OBSERVE3_OUT 0x0010 
0x0040 0x 0x6 0x0
+#define MX7D_PAD_GPIO1_IO05__GPIO1_IO50x0014 
0x0044 0x 0x0 0x0
+#define MX7D_PAD_GPIO1_IO05__USB_OTG1_PWR 0x0014 
0x0044 0x 0x1 0x0
+#define MX7D_PAD_GPIO1_IO05__FLEXTIMER1_CH5   0x0014 
0x0044 0x0598 0x2 0x1
+#define MX7D_PAD_GPIO1_IO05__UART5_RTS_B  0x0014 
0x0044 0x0710 0x3 0x5
+#define MX7D_PAD_GPIO1_IO05__I2C1_SDA 0x0014 
0x0044 0x05D8 0x4 0x2
+#define MX7D_PAD_GPIO1_IO05__OBSERVE4_OUT 0x0014 
0x0044 0x 0x6 0x0
+#define MX7D_PAD_GPIO1_IO06__GPIO1_IO60x0018 
0x0048 0x 0x0 0x0
+#define MX7D_PAD_GPIO1_IO06__USB_OTG2_OC  0x0018 
0x0048 0x0728 0x1 0x1
+#define MX7D_PAD_GPIO1_IO06__FLEXTIMER1_CH6   0x0018 
0x0048 0x059C 0x2 0x1
+#define MX7D_PAD_GPIO1_IO06__UART5_RX_DATA0x0018 
0x0048 0x0714 0x3 0x4
+#define MX7D_PAD_GPIO1_IO06__I2C2_SCL 0x0018 
0x0048 0x05DC 0x4 0x2
+#define MX7D_PAD_GPIO1_IO06__CCM_WAIT 

[U-Boot] [PATCH v3 00/10] mx7: add dt support for Colibri iMX7S/iMX7D

[Stefan Agner]

From: Stefan Agner 

This patchset adds device tree support for Colibri iMX7S/iMX7D.
It is the first device tree enabled board for any i.MX 7 SoC
hence the patchset adds some common infrastructure:
- Add device tree support for serial_mxc.
- imx7.dtsi - I descided to leave the s/d suffix since the SoCs
  are very similar and boards will likely use runtime detection
  to distinguish the two available SoCs.
- The pinmux file imx7d-pinfunc.h is taken from the Kernel and
  stored in the same place

Otherwise the conversion is quite straightforward and simplified
the board code somewhat. Two patches enhance the board support
with PMIC support, which has been the driver for this conversion.

Changes since v2:
- Drop CONFIG_CUSTOM_BOARDINFO again
- Add ifdef OF_CONTROL in serial-mxc driver to allow building the
  driver without OF support

Changes since v1:
- Add Linux kernel commit hash for imx7d-pinfunc.h
- Removed obsolete init declaration in PMIC header file
- Rebased and added Acks

--
Stefan


Stefan Agner (10):
  dm: imx: serial: support device tree
  pinctrl: imx: do not announce driver initialization
  arm: dts: imx7: add pinctrl defines
  arm: dts: imx7: add basic i.MX 7/Colibri iMX7 device tree
  colibri_imx7: remove legancy I2C support
  colibri_imx7: remove legancy UART platform data
  power: pmic: add Ricoh RN5T567 PMIC support
  arm: dts: imx7: add Ricoh RN5T567 PMIC node
  colibri_imx7: use Ricoh RN5T567 to reboot the board
  configs: enable device tree for Colibri iMX7

 arch/arm/dts/Makefile  |2 +
 arch/arm/dts/imx7-colibri.dts  |   97 ++
 arch/arm/dts/imx7.dtsi |  194 
 arch/arm/dts/imx7d-pinfunc.h   | 1151 
 board/toradex/colibri_imx7/colibri_imx7.c  |   92 +-
 configs/colibri_imx7_defconfig |   10 +-
 doc/device-tree-bindings/pmic/rn5t567.txt  |   17 +
 doc/device-tree-bindings/serial/mxc-serial.txt |8 +
 drivers/pinctrl/nxp/pinctrl-imx.c  |2 +-
 drivers/power/pmic/Kconfig |8 +
 drivers/power/pmic/Makefile|1 +
 drivers/power/pmic/rn5t567.c   |   64 ++
 drivers/serial/serial_mxc.c|   32 +-
 include/configs/colibri_imx7.h |2 -
 include/power/rn5t567_pmic.h   |  113 +++
 15 files changed, 1737 insertions(+), 56 deletions(-)
 create mode 100644 arch/arm/dts/imx7-colibri.dts
 create mode 100644 arch/arm/dts/imx7.dtsi
 create mode 100644 arch/arm/dts/imx7d-pinfunc.h
 create mode 100644 doc/device-tree-bindings/pmic/rn5t567.txt
 create mode 100644 doc/device-tree-bindings/serial/mxc-serial.txt
 create mode 100644 drivers/power/pmic/rn5t567.c
 create mode 100644 include/power/rn5t567_pmic.h

-- 
2.10.0

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

Re: [U-Boot] ACPI in general

[Tom Rini]

On Wed, Oct 05, 2016 at 11:33:14PM +, york sun wrote:
> On 10/05/2016 04:15 PM, Timur Tabi wrote:
> > On Wed, Oct 5, 2016 at 9:46 AM, Simon Glass  wrote:
> >>> Is there any activity to bring ACPI to other than x86 arch? If not, do
> >>> we have a plan to do so?
> >>
> >> Not that I know of, sorry.
> >
> > Note that ACPI for ARM exists on Linux already, and as far as I know,
> > all ARM ACPI systems use UEFI, not U-Boot.
> 
> Exactly the reason I asked. Wondering if U-Boot is going down this path.

Well, I wouldn't phrase it quite like that.  I would ask, do we want to
go down this path?  How far down would we want to go, if so?

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/5] check-config: fix wrong comment about how to build whitelist

[Masahiro Yamada]

2016-10-06 1:50 GMT+09:00 Simon Glass :
> BTW, what do you think about updating moveconfig.py to remove things
> from the whitelist as well?


Yeah, I was also thinking of this.





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

Re: [U-Boot] ACPI in general

[york sun]

On 10/05/2016 07:47 AM, Simon Glass wrote:
> Hi York,
>
> On 4 October 2016 at 10:38, york sun  wrote:
>> Simon and Bin,
>>
>> Is there any activity to bring ACPI to other than x86 arch? If not, do
>> we have a plan to do so?
>
> Not that I know of, sorry.

Simon and Bin,

Thanks for replying.

York

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

Re: [U-Boot] [PATCH v2 3/3] dts: rk3288: remove node in dmc which not need anymore

[Vagrant Cascadian]

On 2016-09-19, Kever Yang wrote:
> Since we implement the dram capacity auto detect, we don't
> need to set the channel number and sdram-channel in dts.
>
> Signed-off-by: Kever Yang 

Tested on firefly-rk3288, 2GB and 4GB ram board variants, using u-boot
2016.11-rc1.

Tested-by: Vagrant Cascadian 

> ---
>
> Changes in v2: None
>
>  arch/arm/dts/rk3288-evb.dts  | 3 ---
>  arch/arm/dts/rk3288-fennec.dts   | 3 ---
>  arch/arm/dts/rk3288-firefly.dts  | 2 --
>  arch/arm/dts/rk3288-miniarm.dts  | 3 ---
>  arch/arm/dts/rk3288-popmetal.dts | 3 ---
>  arch/arm/dts/rk3288-rock2-square.dts | 2 --
>  arch/arm/dts/rk3288-veyron.dtsi  | 2 --
>  7 files changed, 18 deletions(-)
>
> diff --git a/arch/arm/dts/rk3288-evb.dts b/arch/arm/dts/rk3288-evb.dts
> index 3e1ee58..3f03e13 100644
> --- a/arch/arm/dts/rk3288-evb.dts
> +++ b/arch/arm/dts/rk3288-evb.dts
> @@ -17,7 +17,6 @@
>  };
>  
>   {
> - rockchip,num-channels = <2>;
>   rockchip,pctl-timing = <0x215 0xc8 0x0 0x35 0x26 0x2 0x70 0x2000d
>   0x6 0x0 0x8 0x4 0x17 0x24 0xd 0x6
>   0x4 0x8 0x4 0x76 0x4 0x0 0x30 0x0
> @@ -25,8 +24,6 @@
>   0x8 0x1f4>;
>   rockchip,phy-timing = <0x48d7dd93 0x187008d8 0x121076
>   0x0 0xc3 0x6 0x2>;
> - /* Add a dummy value to cause of-platdata think this is bytes */
> - rockchip,sdram-channel = /bits/ 8 <0x2 0xa 0x3 0x2 0x2 0x0 0xe 0xe 
> 0xff>;
>   rockchip,sdram-params = <0x20d266a4 0x5b6 2 53300 6 9 0>;
>  };
>  
> diff --git a/arch/arm/dts/rk3288-fennec.dts b/arch/arm/dts/rk3288-fennec.dts
> index 36e9f3d..66ddf8d 100644
> --- a/arch/arm/dts/rk3288-fennec.dts
> +++ b/arch/arm/dts/rk3288-fennec.dts
> @@ -17,7 +17,6 @@
>  };
>  
>   {
> - rockchip,num-channels = <2>;
>   rockchip,pctl-timing = <0x215 0xc8 0x0 0x35 0x26 0x2 0x70 0x2000d
>   0x6 0x0 0x8 0x4 0x17 0x24 0xd 0x6
>   0x4 0x8 0x4 0x76 0x4 0x0 0x30 0x0
> @@ -25,8 +24,6 @@
>   0x8 0x1f4>;
>   rockchip,phy-timing = <0x48d7dd93 0x187008d8 0x121076
>   0x0 0xc3 0x6 0x2>;
> - /* Add a dummy value to cause of-platdata think this is bytes */
> - rockchip,sdram-channel = /bits/ 8 <0x2 0xa 0x3 0x2 0x2 0x0 0xe 0xe 
> 0xff>;
>   rockchip,sdram-params = <0x20d266a4 0x5b6 2 53300 6 9 0>;
>  };
>  
> diff --git a/arch/arm/dts/rk3288-firefly.dts b/arch/arm/dts/rk3288-firefly.dts
> index 3176d50..97568a3 100644
> --- a/arch/arm/dts/rk3288-firefly.dts
> +++ b/arch/arm/dts/rk3288-firefly.dts
> @@ -22,7 +22,6 @@
>  };
>  
>   {
> - rockchip,num-channels = <2>;
>   rockchip,pctl-timing = <0x29a 0xc8 0x1f8 0x42 0x4e 0x4 0xea 0xa
>   0x5 0x0 0xa 0x7 0x19 0x24 0xa 0x7
>   0x5 0xa 0x5 0x200 0x5 0x10 0x40 0x0
> @@ -31,7 +30,6 @@
>   rockchip,phy-timing = <0x48f9aab4 0xea0910 0x1002c200
>   0xa60 0x40 0x10 0x0>;
>   /* Add a dummy value to cause of-platdata think this is bytes */
> - rockchip,sdram-channel = /bits/ 8 <0x1 0xa 0x3 0x2 0x1 0x0 0xf 0xf 
> 0xff>;
>   rockchip,sdram-params = <0x30B25564 0x627 3 66600 3 9 1>;
>  };
>  
> diff --git a/arch/arm/dts/rk3288-miniarm.dts b/arch/arm/dts/rk3288-miniarm.dts
> index c741082..9083028 100644
> --- a/arch/arm/dts/rk3288-miniarm.dts
> +++ b/arch/arm/dts/rk3288-miniarm.dts
> @@ -17,7 +17,6 @@
>  };
>  
>   {
> - rockchip,num-channels = <2>;
>   rockchip,pctl-timing = <0x29a 0xc8 0x1f8 0x42 0x4e 0x4 0xea 0xa
>   0x5 0x0 0xa 0x7 0x19 0x24 0xa 0x7
>   0x5 0xa 0x5 0x200 0x5 0x10 0x40 0x0
> @@ -25,8 +24,6 @@
>   0x5 0x0>;
>   rockchip,phy-timing = <0x48f9aab4 0xea0910 0x1002c200
>   0xa60 0x40 0x10 0x0>;
> - /* Add a dummy value to cause of-platdata think this is bytes */
> - rockchip,sdram-channel = /bits/ 8 <0x1 0xa 0x3 0x2 0x1 0x0 0xf 0xf 
> 0xff>;
>   rockchip,sdram-params = <0x30B25564 0x627 3 66600 3 9 1>;
>  };
>  
> diff --git a/arch/arm/dts/rk3288-popmetal.dts 
> b/arch/arm/dts/rk3288-popmetal.dts
> index 3f61a61..284d5ed 100644
> --- a/arch/arm/dts/rk3288-popmetal.dts
> +++ b/arch/arm/dts/rk3288-popmetal.dts
> @@ -17,7 +17,6 @@
>  };
>  
>   {
> - rockchip,num-channels = <2>;
>   rockchip,pctl-timing = <0x29a 0xc8 0x1f8 0x42 0x4e 0x4 0xea 0xa
>   0x5 0x0 0xa 0x7 0x19 0x24 0xa 0x7
>   0x5 0xa 0x5 0x200 0x5 0x10 0x40 0x0
> @@ -25,8 +24,6 @@
>   0x5 0x0>;
>   rockchip,phy-timing = <0x48f9aab4 0xea0910 0x1002c200
>   0xa60 0x40 0x10 0x0>;
> - /* Add a dummy value to cause of-platdata think this is bytes */
> - rockchip,sdram-channel = /bits/ 8 <0x1 0xa 0x3 0x2 0x1 0x0 0xf 0xf 
> 0xff>;
>   rockchip,sdram-params = <0x30B25564 0x627 3 66600 3 9 1>;
>  };
>  
> diff --git a/arch/arm/dts/rk3288-rock2-square.dts 
> b/arch/arm/dts/rk3288-rock2-square.dts
> index 2c30355..11c580a 100644
> --- 

Re: [U-Boot] [PATCH v2 2/3] rk3288: sdram: auto-detect the capacity

[Vagrant Cascadian]

On 2016-09-19, Kever Yang wrote:
> Add support for rk3288 dram capacity auto detect, support DDR3 and
> LPDDR3, DDR2 is not supported.
> The program will automatically detect:
> - channel number
> - rank number
> - column address number
> - row address number
>
> The dts file do not need to describe those info after apply this patch.
>
> Signed-off-by: Kever Yang 

Tested on firefly-rk3288, 2GB and 4GB ram board variants, using u-boot
2016.11-rc1.

Tested-by: Vagrant Cascadian 

> ---
>
> Changes in v2:
> - update code for OF_PLATDATA enabled
> - bug fix for ddrconfig
>
>  arch/arm/mach-rockchip/rk3288/sdram_rk3288.c | 244 
> ++-
>  1 file changed, 202 insertions(+), 42 deletions(-)
>
> diff --git a/arch/arm/mach-rockchip/rk3288/sdram_rk3288.c 
> b/arch/arm/mach-rockchip/rk3288/sdram_rk3288.c
> index cf9ef2e..b3dc251 100644
> --- a/arch/arm/mach-rockchip/rk3288/sdram_rk3288.c
> +++ b/arch/arm/mach-rockchip/rk3288/sdram_rk3288.c
> @@ -57,6 +57,10 @@ struct rk3288_sdram_params {
>   struct regmap *map;
>  };
>  
> +#define TEST_PATTEN  0x5aa5f00f
> +#define DQS_GATE_TRAINING_ERROR_RANK0(1 << 4)
> +#define DQS_GATE_TRAINING_ERROR_RANK1(2 << 4)
> +
>  #ifdef CONFIG_SPL_BUILD
>  static void copy_to_reg(u32 *dest, const u32 *src, u32 n)
>  {
> @@ -214,7 +218,7 @@ static void ddr_set_en_bst_odt(struct rk3288_grf *grf, 
> uint channel,
>  }
>  
>  static void pctl_cfg(u32 channel, struct rk3288_ddr_pctl *pctl,
> -  const struct rk3288_sdram_params *sdram_params,
> +  struct rk3288_sdram_params *sdram_params,
>struct rk3288_grf *grf)
>  {
>   unsigned int burstlen;
> @@ -264,7 +268,7 @@ static void pctl_cfg(u32 channel, struct rk3288_ddr_pctl 
> *pctl,
>  }
>  
>  static void phy_cfg(const struct chan_info *chan, u32 channel,
> - const struct rk3288_sdram_params *sdram_params)
> + struct rk3288_sdram_params *sdram_params)
>  {
>   struct rk3288_ddr_publ *publ = chan->publ;
>   struct rk3288_msch *msch = chan->msch;
> @@ -446,7 +450,7 @@ static void set_bandwidth_ratio(const struct chan_info 
> *chan, u32 channel,
>  }
>  
>  static int data_training(const struct chan_info *chan, u32 channel,
> -  const struct rk3288_sdram_params *sdram_params)
> +  struct rk3288_sdram_params *sdram_params)
>  {
>   unsigned int j;
>   int ret = 0;
> @@ -549,7 +553,7 @@ static void move_to_access_state(const struct chan_info 
> *chan)
>  }
>  
>  static void dram_cfg_rbc(const struct chan_info *chan, u32 chnum,
> -  const struct rk3288_sdram_params *sdram_params)
> +  struct rk3288_sdram_params *sdram_params)
>  {
>   struct rk3288_ddr_publ *publ = chan->publ;
>  
> @@ -563,7 +567,7 @@ static void dram_cfg_rbc(const struct chan_info *chan, 
> u32 chnum,
>  }
>  
>  static void dram_all_config(const struct dram_info *dram,
> - const struct rk3288_sdram_params *sdram_params)
> + struct rk3288_sdram_params *sdram_params)
>  {
>   unsigned int chan;
>   u32 sys_reg = 0;
> @@ -589,9 +593,173 @@ static void dram_all_config(const struct dram_info 
> *dram,
>   writel(sys_reg, >pmu->sys_reg[2]);
>   rk_clrsetreg(>sgrf->soc_con2, 0x1f, sdram_params->base.stride);
>  }
> +const int ddrconf_table[] = {
> + /* row  col,bw */
> + 0,
> + ((1 << 4) | 1),
> + ((2 << 4) | 1),
> + ((3 << 4) | 1),
> + ((4 << 4) | 1),
> + ((1 << 4) | 2),
> + ((2 << 4) | 2),
> + ((3 << 4) | 2),
> + ((1 << 4) | 0),
> + ((2 << 4) | 0),
> + ((3 << 4) | 0),
> + 0,
> + 0,
> + 0,
> + 0,
> + ((4 << 4) | 2),
> +};
> +
> +static int sdram_rank_bw_detect(struct dram_info *dram, int channel,
> + struct rk3288_sdram_params *sdram_params)
> +{
> + int reg;
> + int need_trainig = 0;
> + const struct chan_info *chan = >chan[channel];
> + struct rk3288_ddr_publ *publ = chan->publ;
> +
> + if (-1 == data_training(chan, channel, sdram_params)) {
> + reg = readl(>datx8[0].dxgsr[0]);
> + /* Check the result for rank 0 */
> + if ((channel == 0) && (reg & DQS_GATE_TRAINING_ERROR_RANK0)) {
> + debug("data training fail!\n");
> + return -EIO;
> + } else if ((channel == 1) &&
> +(reg & DQS_GATE_TRAINING_ERROR_RANK0)) {
> + sdram_params->num_channels = 1;
> + }
> +
> + /* Check the result for rank 1 */
> + if (reg & DQS_GATE_TRAINING_ERROR_RANK1) {
> + sdram_params->ch[channel].rank = 1;
> + clrsetbits_le32(>pgcr, 0xF << 18,
> + sdram_params->ch[channel].rank << 18);
> + need_trainig = 1;

Re: [U-Boot] [U-Boot, v3] net: Fix cache misalignment message after network load operations

[Tom Rini]

On Wed, Sep 14, 2016 at 03:49:22AM +, Peter Chubb wrote:

> After any operation that downloads a file (e.g., pxe get, or dhcp), the
> buffer containing the downloaded data is flushed.  This is unnecessary
> and annoying.  Unnecessary, because
> the network driver should already have fliushed the cache for the DMAed area,
> and annoying because it generates a cache misalignment message.
> 
> Signed-off-by: Peter Chubb 
> Acked-by: Heiko Schocher 
> Acked-by: Joe Hershberger 

Reviewed-by: Tom Rini 

Joe, do you want to pick this up or should I?  Thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] net, cmd: fix misaligned cache operation warning

[Peter.Chubb]

> "Joe" == Joe Hershberger  writes:

>> 
>> Lacking a define for CONFIG_SYS_CACHELINE_SIZE first.

Joe> https://patchwork.ozlabs.org/patch/669691/

Joe> ...is the approach I prefer to take instead of this patch.

Is there anything more I need to do to push this patch?

-- 
Dr Peter Chubb Tel: +61 2 9490 5852  http://ts.data61.csiro.au/
Trustworthy Systems Group   Data61 (formerly NICTA)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] ACPI in general

[york sun]

On 10/05/2016 04:15 PM, Timur Tabi wrote:
> On Wed, Oct 5, 2016 at 9:46 AM, Simon Glass  wrote:
>>> Is there any activity to bring ACPI to other than x86 arch? If not, do
>>> we have a plan to do so?
>>
>> Not that I know of, sorry.
>
> Note that ACPI for ARM exists on Linux already, and as far as I know,
> all ARM ACPI systems use UEFI, not U-Boot.
>

Exactly the reason I asked. Wondering if U-Boot is going down this path.

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

Re: [U-Boot] [PATCH v2 8/8] armv7: ls1021a: Move DDR config options to Kconfig

[york sun]

On 10/05/2016 09:51 AM, Simon Glass wrote:
> Hi York,
>
> On 4 October 2016 at 19:04, York Sun  wrote:
>> Move DDR3, DDR4 and related config options to Kconfig and clean up
>> existing uses.
>>
>> Signed-off-by: York Sun 
>>
>> ---
>>
>> Changes in v2:
>>   No patch
>>
>>  arch/arm/cpu/armv7/ls102xa/Kconfig   | 47 
>> 
>>  arch/arm/include/asm/arch-ls102xa/config.h   | 10 --
>>  configs/ls1021aqds_ddr4_nor_defconfig|  2 +-
>>  configs/ls1021aqds_ddr4_nor_lpuart_defconfig |  3 +-
>>  configs/ls1021aqds_nand_defconfig|  1 +
>>  configs/ls1021aqds_nor_SECURE_BOOT_defconfig |  1 +
>>  configs/ls1021aqds_nor_defconfig |  1 +
>>  configs/ls1021aqds_nor_lpuart_defconfig  |  1 +
>>  configs/ls1021aqds_qspi_defconfig|  1 +
>>  configs/ls1021aqds_sdcard_ifc_defconfig  |  1 +
>>  configs/ls1021aqds_sdcard_qspi_defconfig |  1 +
>>  include/configs/ls1021aqds.h |  1 -
>>  12 files changed, 57 insertions(+), 13 deletions(-)
>
> Reviewed-by: Simon Glass 
>
> You should be able to remove these from scripts/config_whitelist.txt as well.
>

I intend to but not yet. I need to move all of them from PowerPC 
platforms before removing them from the white list.

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

[U-Boot] [PATCH v3 09/10] colibri_imx7: use Ricoh RN5T567 to reboot the board

[Stefan Agner]

From: Stefan Agner 

Use the external PMIC Ricoh RN5T567 to reliably restart the system.

Signed-off-by: Stefan Agner 
---

 board/toradex/colibri_imx7/colibri_imx7.c | 42 +++
 1 file changed, 42 insertions(+)

diff --git a/board/toradex/colibri_imx7/colibri_imx7.c 
b/board/toradex/colibri_imx7/colibri_imx7.c
index bd7d5bc..c64e31e 100644
--- a/board/toradex/colibri_imx7/colibri_imx7.c
+++ b/board/toradex/colibri_imx7/colibri_imx7.c
@@ -21,6 +21,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 
 DECLARE_GLOBAL_DATA_PTR;
@@ -337,6 +339,46 @@ int board_late_init(void)
return 0;
 }
 
+#ifdef CONFIG_DM_PMIC
+int power_init_board(void)
+{
+   struct udevice *dev;
+   int reg, ver;
+   int ret;
+
+
+   ret = pmic_get("rn5t567", );
+   if (ret)
+   return ret;
+   ver = pmic_reg_read(dev, RN5T567_LSIVER);
+   reg = pmic_reg_read(dev, RN5T567_OTPVER);
+
+   printf("PMIC:  RN5T567 LSIVER=0x%02x OTPVER=0x%02x\n", ver, reg);
+
+   /* set judge and press timer of N_OE to minimal values */
+   pmic_clrsetbits(dev, RN5T567_NOETIMSETCNT, 0x7, 0);
+
+   return 0;
+}
+
+void reset_cpu(ulong addr)
+{
+   struct udevice *dev;
+
+   pmic_get("rn5t567", );
+
+   /* Use PMIC to reset, set REPWRTIM to 0 and REPWRON to 1 */
+   pmic_reg_write(dev, RN5T567_REPCNT, 0x1);
+   pmic_reg_write(dev, RN5T567_SLPCNT, 0x1);
+
+   /*
+* Re-power factor detection on PMIC side is not instant. 1ms
+* proved to be enough time until reset takes effect.
+*/
+   mdelay(1);
+}
+#endif
+
 int checkboard(void)
 {
printf("Model: Toradex Colibri iMX7%c\n",
-- 
2.10.0

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

[U-Boot] [PATCH v3 10/10] configs: enable device tree for Colibri iMX7

[Stefan Agner]

From: Stefan Agner 

Enable device tree configuration and specify default device tree
for Toradex Colibri iMX7.

Signed-off-by: Stefan Agner 
---

 configs/colibri_imx7_defconfig | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/configs/colibri_imx7_defconfig b/configs/colibri_imx7_defconfig
index 7c4d349..7a49f74 100644
--- a/configs/colibri_imx7_defconfig
+++ b/configs/colibri_imx7_defconfig
@@ -3,6 +3,7 @@ CONFIG_ARCH_MX7=y
 CONFIG_TARGET_COLIBRI_IMX7=y
 CONFIG_IMX_RDC=y
 CONFIG_IMX_BOOTAUX=y
+CONFIG_DEFAULT_DEVICE_TREE="imx7-colibri"
 
CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=board/toradex/colibri_imx7/imximage.cfg,MX7D"
 CONFIG_BOOTDELAY=1
 CONFIG_HUSH_PARSER=y
@@ -30,8 +31,16 @@ CONFIG_CMD_EXT4=y
 CONFIG_CMD_FAT=y
 CONFIG_CMD_FS_GENERIC=y
 CONFIG_CMD_UBI=y
+CONFIG_OF_CONTROL=y
+CONFIG_OF_EMBED=y
 CONFIG_DFU_MMC=y
+CONFIG_DM_GPIO=y
+CONFIG_DM_I2C=y
 CONFIG_MTD_UBI_FASTMAP=y
+CONFIG_PINCTRL=y
+CONFIG_PINCTRL_IMX7=y
+CONFIG_DM_PMIC=y
+CONFIG_PMIC_RN5T567=y
 CONFIG_USB=y
 CONFIG_USB_EHCI_HCD=y
 CONFIG_USB_STORAGE=y
@@ -41,4 +50,3 @@ CONFIG_USB_GADGET_DOWNLOAD=y
 CONFIG_G_DNL_MANUFACTURER="Toradex"
 CONFIG_G_DNL_VENDOR_NUM=0x1b67
 CONFIG_G_DNL_PRODUCT_NUM=0x4020
-CONFIG_OF_LIBFDT=y
-- 
2.10.0

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

[U-Boot] [PATCH v3 07/10] power: pmic: add Ricoh RN5T567 PMIC support

[Stefan Agner]

From: Stefan Agner 

Add device model enabled PMIC driver for Ricoh RN5T567 PMIC used
on Colibri iMX7.

Signed-off-by: Stefan Agner 
Reviewed-by: Simon Glass 
---

 doc/device-tree-bindings/pmic/rn5t567.txt |  17 +
 drivers/power/pmic/Kconfig|   8 +++
 drivers/power/pmic/Makefile   |   1 +
 drivers/power/pmic/rn5t567.c  |  64 +
 include/power/rn5t567_pmic.h  | 113 ++
 5 files changed, 203 insertions(+)
 create mode 100644 doc/device-tree-bindings/pmic/rn5t567.txt
 create mode 100644 drivers/power/pmic/rn5t567.c
 create mode 100644 include/power/rn5t567_pmic.h

diff --git a/doc/device-tree-bindings/pmic/rn5t567.txt 
b/doc/device-tree-bindings/pmic/rn5t567.txt
new file mode 100644
index 000..e9e6885
--- /dev/null
+++ b/doc/device-tree-bindings/pmic/rn5t567.txt
@@ -0,0 +1,17 @@
+Ricoh RN5T567 PMIC
+
+This file describes the binding info for the PMIC driver.
+
+Required properties:
+- compatible: "ricoh,rn5t567"
+- reg: depending on strapping, e.g. 0x33
+
+With those two properties, the PMIC device can be used to read/write
+registers.
+
+Example:
+
+rn5t567@33 {
+   compatible = "ricoh,rn5t567";
+   reg = <0x33>;
+};
diff --git a/drivers/power/pmic/Kconfig b/drivers/power/pmic/Kconfig
index 69f8d51..13d293a 100644
--- a/drivers/power/pmic/Kconfig
+++ b/drivers/power/pmic/Kconfig
@@ -127,6 +127,14 @@ config PMIC_S5M8767
driver provides basic register access and sets up the attached
regulators if regulator support is enabled.
 
+config PMIC_RN5T567
+   bool "Enable driver for Ricoh RN5T567 PMIC"
+   depends on DM_PMIC
+   ---help---
+   The RN5T567 is a PMIC with 4 step-down DC/DC converters, 5 LDO
+   regulators Real-Time Clock and 4 GPIOs. This driver provides
+   register access only.
+
 config PMIC_TPS65090
bool "Enable driver for Texas Instruments TPS65090 PMIC"
depends on DM_PMIC
diff --git a/drivers/power/pmic/Makefile b/drivers/power/pmic/Makefile
index 52b4f71..37d9eb5 100644
--- a/drivers/power/pmic/Makefile
+++ b/drivers/power/pmic/Makefile
@@ -13,6 +13,7 @@ obj-$(CONFIG_DM_PMIC_SANDBOX) += sandbox.o i2c_pmic_emul.o
 obj-$(CONFIG_PMIC_ACT8846) += act8846.o
 obj-$(CONFIG_PMIC_PM8916) += pm8916.o
 obj-$(CONFIG_PMIC_RK808) += rk808.o
+obj-$(CONFIG_PMIC_RN5T567) += rn5t567.o
 obj-$(CONFIG_PMIC_TPS65090) += tps65090.o
 obj-$(CONFIG_PMIC_S5M8767) += s5m8767.o
 
diff --git a/drivers/power/pmic/rn5t567.c b/drivers/power/pmic/rn5t567.c
new file mode 100644
index 000..001e695
--- /dev/null
+++ b/drivers/power/pmic/rn5t567.c
@@ -0,0 +1,64 @@
+/*
+ * Copyright (C) 2016 Toradex AG
+ * Stefan Agner 
+ *
+ * SPDX-License-Identifier:  GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static int rn5t567_reg_count(struct udevice *dev)
+{
+   return RN5T567_NUM_OF_REGS;
+}
+
+static int rn5t567_write(struct udevice *dev, uint reg, const uint8_t *buff,
+ int len)
+{
+   int ret;
+
+   ret = dm_i2c_write(dev, reg, buff, len);
+   if (ret) {
+   debug("write error to device: %p register: %#x!", dev, reg);
+   return ret;
+   }
+
+   return 0;
+}
+
+static int rn5t567_read(struct udevice *dev, uint reg, uint8_t *buff, int len)
+{
+   int ret;
+
+   ret = dm_i2c_read(dev, reg, buff, len);
+   if (ret) {
+   debug("read error from device: %p register: %#x!", dev, reg);
+   return ret;
+   }
+
+   return 0;
+}
+
+static struct dm_pmic_ops rn5t567_ops = {
+   .reg_count = rn5t567_reg_count,
+   .read = rn5t567_read,
+   .write = rn5t567_write,
+};
+
+static const struct udevice_id rn5t567_ids[] = {
+   { .compatible = "ricoh,rn5t567" },
+   { }
+};
+
+U_BOOT_DRIVER(pmic_rn5t567) = {
+   .name = "rn5t567 pmic",
+   .id = UCLASS_PMIC,
+   .of_match = rn5t567_ids,
+   .ops = _ops,
+};
diff --git a/include/power/rn5t567_pmic.h b/include/power/rn5t567_pmic.h
new file mode 100644
index 000..9ce601f
--- /dev/null
+++ b/include/power/rn5t567_pmic.h
@@ -0,0 +1,113 @@
+/*
+ * Copyright (C) 2016 Toradex AG
+ * Stefan Agner 
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+#ifndef __RN5T567_PMIC_H_
+#define __RN5T567_PMIC_H_
+
+/* RN5T567 registers */
+enum {
+   RN5T567_LSIVER  = 0x00,
+   RN5T567_OTPVER  = 0x01,
+   RN5T567_IODAC   = 0x02,
+   RN5T567_VINDAC  = 0x03,
+   RN5T567_OUT32KEN= 0x05,
+
+   RN5T567_CPUCNT  = 0x06,
+
+   RN5T567_PSWR= 0x07,
+   RN5T567_PONHIS  = 0x09,
+   RN5T567_POFFHIS = 0x0A,
+   RN5T567_WATCHDOG= 0x0B,
+   RN5T567_WATCHDOGCNT = 0x0C,
+   RN5T567_PWRFUNC = 0x0D,
+   

[U-Boot] [PATCH v3 08/10] arm: dts: imx7: add Ricoh RN5T567 PMIC node

[Stefan Agner]

From: Stefan Agner 

Add device tree node for Ricoh RN5T567. Currently we do not need
the individual DC/DC converters or LDO's (and they are also not
yet supported by the driver).

Signed-off-by: Stefan Agner 
---

 arch/arm/dts/imx7-colibri.dts | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/dts/imx7-colibri.dts b/arch/arm/dts/imx7-colibri.dts
index f2da096..cbef5d5 100644
--- a/arch/arm/dts/imx7-colibri.dts
+++ b/arch/arm/dts/imx7-colibri.dts
@@ -24,6 +24,11 @@
sda-gpios = < 5 GPIO_ACTIVE_LOW>;
scl-gpios = < 4 GPIO_ACTIVE_LOW>;
status = "okay";
+
+   rn5t567@33 {
+   compatible = "ricoh,rn5t567";
+   reg = <0x33>;
+   };
 };
 
  {
-- 
2.10.0

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

[U-Boot] [PATCH v3 01/10] dm: imx: serial: support device tree

[Stefan Agner]

From: Stefan Agner 

Support instatiation through device tree. Also parse the fsl,dte-mode
property to determine whether DTE mode shall be used.

Signed-off-by: Stefan Agner 
Reviewed-by: Simon Glass 
---

 doc/device-tree-bindings/serial/mxc-serial.txt |  8 +++
 drivers/serial/serial_mxc.c| 32 --
 2 files changed, 38 insertions(+), 2 deletions(-)
 create mode 100644 doc/device-tree-bindings/serial/mxc-serial.txt

diff --git a/doc/device-tree-bindings/serial/mxc-serial.txt 
b/doc/device-tree-bindings/serial/mxc-serial.txt
new file mode 100644
index 000..ede92a4
--- /dev/null
+++ b/doc/device-tree-bindings/serial/mxc-serial.txt
@@ -0,0 +1,8 @@
+NXP i.MX (MXC) UART
+
+Required properties:
+- compatible: must be "fsl,imx7d-uart"
+- reg: start address and size of the registers
+
+Optional properties:
+- fsl,dte-mode: use DTE mode
diff --git a/drivers/serial/serial_mxc.c b/drivers/serial/serial_mxc.c
index 8545714..4fd2b1d 100644
--- a/drivers/serial/serial_mxc.c
+++ b/drivers/serial/serial_mxc.c
@@ -108,6 +108,8 @@
 #define  UTS_RXFULL (1<<3)  /* RxFIFO full */
 #define  UTS_SOFTRST(1<<0)  /* Software reset */
 
+DECLARE_GLOBAL_DATA_PTR;
+
 #ifndef CONFIG_DM_SERIAL
 
 #ifndef CONFIG_MXC_UART_BASE
@@ -135,8 +137,6 @@
 #define UBRC  0xac /* Baud Rate Count Register */
 #define UTS   0xb4 /* UART Test Register (mx31) */
 
-DECLARE_GLOBAL_DATA_PTR;
-
 #define TXTL  2 /* reset default */
 #define RXTL  1 /* reset default */
 #define RFDIV 4 /* divide input clock by 2 */
@@ -347,9 +347,37 @@ static const struct dm_serial_ops mxc_serial_ops = {
.setbrg = mxc_serial_setbrg,
 };
 
+#if CONFIG_IS_ENABLED(OF_CONTROL)
+static int mxc_serial_ofdata_to_platdata(struct udevice *dev)
+{
+   struct mxc_serial_platdata *plat = dev->platdata;
+   fdt_addr_t addr;
+
+   addr = dev_get_addr(dev);
+   if (addr == FDT_ADDR_T_NONE)
+   return -EINVAL;
+
+   plat->reg = (struct mxc_uart *)addr;
+
+   plat->use_dte = fdtdec_get_bool(gd->fdt_blob, dev->of_offset,
+   "fsl,dte-mode");
+   return 0;
+}
+
+static const struct udevice_id mxc_serial_ids[] = {
+   { .compatible = "fsl,imx7d-uart" },
+   { }
+};
+#endif
+
 U_BOOT_DRIVER(serial_mxc) = {
.name   = "serial_mxc",
.id = UCLASS_SERIAL,
+#if CONFIG_IS_ENABLED(OF_CONTROL)
+   .of_match = mxc_serial_ids,
+   .ofdata_to_platdata = mxc_serial_ofdata_to_platdata,
+   .platdata_auto_alloc_size = sizeof(struct mxc_serial_platdata),
+#endif
.probe = mxc_serial_probe,
.ops= _serial_ops,
.flags = DM_FLAG_PRE_RELOC,
-- 
2.10.0

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

[U-Boot] [PATCH v3 04/10] arm: dts: imx7: add basic i.MX 7/Colibri iMX7 device tree

[Stefan Agner]

From: Stefan Agner 

Add base device for NXP i.MX 7Solo/7Dual. The two SoC are very
similar and hence can share the same device tree for boot loaders
purpose.

Signed-off-by: Stefan Agner 
Reviewed-by: Simon Glass 
---

 arch/arm/dts/Makefile |   2 +
 arch/arm/dts/imx7-colibri.dts |  92 
 arch/arm/dts/imx7.dtsi| 194 ++
 3 files changed, 288 insertions(+)
 create mode 100644 arch/arm/dts/imx7-colibri.dts
 create mode 100644 arch/arm/dts/imx7.dtsi

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 032c5ae..295d578 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -280,6 +280,8 @@ dtb-$(CONFIG_VF610) += vf500-colibri.dtb \
vf610-twr.dtb \
pcm052.dtb
 
+dtb-$(CONFIG_MX7) += imx7-colibri.dtb
+
 dtb-$(CONFIG_SOC_KEYSTONE) += k2hk-evm.dtb \
k2l-evm.dtb \
k2e-evm.dtb \
diff --git a/arch/arm/dts/imx7-colibri.dts b/arch/arm/dts/imx7-colibri.dts
new file mode 100644
index 000..f2da096
--- /dev/null
+++ b/arch/arm/dts/imx7-colibri.dts
@@ -0,0 +1,92 @@
+/*
+ * Copyright 2016 Toradex AG
+ *
+ * SPDX-License-Identifier: GPL-2.0+ or X11
+ */
+
+/dts-v1/;
+#include 
+#include "imx7.dtsi"
+
+/ {
+   model = "Toradex Colibri iMX7S/D";
+   compatible = "toradex,imx7-colibri", "fsl,imx7";
+
+   chosen {
+   stdout-path = 
+   };
+};
+
+ {
+   pinctrl-names = "default", "gpio";
+   pinctrl-0 = <_i2c1>;
+   pinctrl-1 = <_i2c1_gpio>;
+   sda-gpios = < 5 GPIO_ACTIVE_LOW>;
+   scl-gpios = < 4 GPIO_ACTIVE_LOW>;
+   status = "okay";
+};
+
+ {
+   pinctrl-names = "default", "gpio";
+   pinctrl-0 = <_i2c4>;
+   pinctrl-1 = <_i2c4_gpio>;
+   sda-gpios = < 9 GPIO_ACTIVE_LOW>;
+   scl-gpios = < 8 GPIO_ACTIVE_LOW>;
+   status = "okay";
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_uart1 _uart1_ctrl1>;
+   uart-has-rtscts;
+   fsl,dte-mode;
+   status = "okay";
+};
+
+ {
+   pinctrl_i2c4: i2c4-grp {
+   fsl,pins = <
+   MX7D_PAD_ENET1_RGMII_TD3__I2C4_SDA  0x407f
+   MX7D_PAD_ENET1_RGMII_TD2__I2C4_SCL  0x407f
+   >;
+   };
+
+   pinctrl_i2c4_gpio: i2c4-gpio-grp {
+   fsl,pins = <
+   MX7D_PAD_ENET1_RGMII_TD3__GPIO7_IO9 0x407f
+   MX7D_PAD_ENET1_RGMII_TD2__GPIO7_IO8 0x407f
+   >;
+   };
+
+   pinctrl_uart1: uart1-grp {
+   fsl,pins = <
+   MX7D_PAD_UART1_TX_DATA__UART1_DTE_RX0x79
+   MX7D_PAD_UART1_RX_DATA__UART1_DTE_TX0x79
+   MX7D_PAD_SAI2_TX_BCLK__UART1_DTE_CTS0x79
+   MX7D_PAD_SAI2_TX_SYNC__UART1_DTE_RTS0x79
+   >;
+   };
+
+   pinctrl_uart1_ctrl1: uart1-ctrl1-grp {
+   fsl,pins = <
+   MX7D_PAD_SD2_DATA1__GPIO5_IO15  0x14 /* DCD */
+   MX7D_PAD_SD2_DATA0__GPIO5_IO14  0x14 /* DTR */
+   >;
+   };
+};
+
+_lpsr {
+   pinctrl_i2c1: i2c1-grp {
+   fsl,pins = <
+   MX7D_PAD_GPIO1_IO05__I2C1_SDA   0x407f
+   MX7D_PAD_GPIO1_IO04__I2C1_SCL   0x407f
+   >;
+   };
+
+   pinctrl_i2c1_gpio: i2c1-gpio-grp {
+   fsl,pins = <
+   MX7D_PAD_GPIO1_IO05__GPIO1_IO5  0x407f
+   MX7D_PAD_GPIO1_IO04__GPIO1_IO4  0x407f
+   >;
+   };
+};
diff --git a/arch/arm/dts/imx7.dtsi b/arch/arm/dts/imx7.dtsi
new file mode 100644
index 000..755cc46
--- /dev/null
+++ b/arch/arm/dts/imx7.dtsi
@@ -0,0 +1,194 @@
+/*
+ * Copyright 2016 Toradex AG
+ *
+ * SPDX-License-Identifier: GPL-2.0+ or X11
+ */
+#include "imx7d-pinfunc.h"
+#include "skeleton.dtsi"
+
+/ {
+   aliases {
+   gpio0 = 
+   gpio1 = 
+   gpio2 = 
+   gpio3 = 
+   gpio4 = 
+   gpio5 = 
+   gpio6 = 
+   i2c0 = 
+   i2c1 = 
+   i2c2 = 
+   i2c3 = 
+   serial0 = 
+   serial1 = 
+   serial2 = 
+   serial3 = 
+   serial4 = 
+   serial5 = 
+   serial6 = 
+   };
+
+   soc {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "simple-bus";
+   ranges;
+
+   aips1: aips-bus@3000 {
+   compatible = "fsl,aips-bus", "simple-bus";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   reg = <0x3000 0x40>;
+   ranges;
+
+   

[U-Boot] [PATCH v3 06/10] colibri_imx7: remove legancy UART platform data

[Stefan Agner]

From: Stefan Agner 

We now use device tree to provide SoC data to the UART driver, there
is no need for the legancy UART platform data.

Signed-off-by: Stefan Agner 
---

 board/toradex/colibri_imx7/colibri_imx7.c | 10 --
 1 file changed, 10 deletions(-)

diff --git a/board/toradex/colibri_imx7/colibri_imx7.c 
b/board/toradex/colibri_imx7/colibri_imx7.c
index ddb3085..bd7d5bc 100644
--- a/board/toradex/colibri_imx7/colibri_imx7.c
+++ b/board/toradex/colibri_imx7/colibri_imx7.c
@@ -368,13 +368,3 @@ int board_ehci_hcd_init(int port)
return 0;
 }
 #endif
-
-static struct mxc_serial_platdata mxc_serial_plat = {
-   .reg = (struct mxc_uart *)UART1_IPS_BASE_ADDR,
-   .use_dte = true,
-};
-
-U_BOOT_DEVICE(mxc_serial) = {
-   .name = "serial_mxc",
-   .platdata = _serial_plat,
-};
-- 
2.10.0

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

[U-Boot] [PATCH v3 02/10] pinctrl: imx: do not announce driver initialization

[Stefan Agner]

From: Stefan Agner 

It is not usual that drivers announce when they have been initialized.
use dev_dbg to announce device initialization.

Signed-off-by: Stefan Agner 
Reviewed-by: Simon Glass 
---

 drivers/pinctrl/nxp/pinctrl-imx.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pinctrl/nxp/pinctrl-imx.c 
b/drivers/pinctrl/nxp/pinctrl-imx.c
index 40b0616..949d0f3 100644
--- a/drivers/pinctrl/nxp/pinctrl-imx.c
+++ b/drivers/pinctrl/nxp/pinctrl-imx.c
@@ -222,7 +222,7 @@ int imx_pinctrl_probe(struct udevice *dev,
return -ENOMEM;
}
 
-   dev_info(dev, "initialized IMX pinctrl driver\n");
+   dev_dbg(dev, "initialized IMX pinctrl driver\n");
 
return 0;
 }
-- 
2.10.0

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

[U-Boot] [PATCH v3 05/10] colibri_imx7: remove legancy I2C support

[Stefan Agner]

From: Stefan Agner 

Remove legancy I2C config and code in favor of upcomming DM/DT
enable I2C support.

Signed-off-by: Stefan Agner 
---

 board/toradex/colibri_imx7/colibri_imx7.c | 40 ---
 include/configs/colibri_imx7.h|  2 --
 2 files changed, 42 deletions(-)

diff --git a/board/toradex/colibri_imx7/colibri_imx7.c 
b/board/toradex/colibri_imx7/colibri_imx7.c
index 8eedd65..ddb3085 100644
--- a/board/toradex/colibri_imx7/colibri_imx7.c
+++ b/board/toradex/colibri_imx7/colibri_imx7.c
@@ -12,13 +12,11 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -38,9 +36,6 @@ DECLARE_GLOBAL_DATA_PTR;
 
 #define ENET_RX_PAD_CTRL  (PAD_CTL_PUS_PU100KOHM | PAD_CTL_DSE_3P3V_49OHM)
 
-#define I2C_PAD_CTRL(PAD_CTL_DSE_3P3V_32OHM | PAD_CTL_SRE_SLOW | \
-   PAD_CTL_HYS | PAD_CTL_PUE | PAD_CTL_PUS_PU100KOHM)
-
 #define LCD_PAD_CTRL(PAD_CTL_HYS | PAD_CTL_PUS_PU100KOHM | \
PAD_CTL_DSE_3P3V_49OHM)
 
@@ -48,36 +43,6 @@ DECLARE_GLOBAL_DATA_PTR;
 
 #define NAND_PAD_READY0_CTRL (PAD_CTL_DSE_3P3V_49OHM | PAD_CTL_PUS_PU5KOHM)
 
-#ifdef CONFIG_SYS_I2C_MXC
-#define PC MUX_PAD_CTRL(I2C_PAD_CTRL)
-/* I2C1 for PMIC */
-static struct i2c_pads_info i2c_pad_info1 = {
-   .scl = {
-   .i2c_mode = MX7D_PAD_GPIO1_IO04__I2C1_SCL | PC,
-   .gpio_mode = MX7D_PAD_GPIO1_IO04__GPIO1_IO4 | PC,
-   .gp = IMX_GPIO_NR(1, 4),
-   },
-   .sda = {
-   .i2c_mode = MX7D_PAD_GPIO1_IO05__I2C1_SDA | PC,
-   .gpio_mode = MX7D_PAD_GPIO1_IO05__GPIO1_IO5 | PC,
-   .gp = IMX_GPIO_NR(1, 5),
-   },
-};
-/* I2C4 for Colibri I2C */
-static struct i2c_pads_info i2c_pad_info4 = {
-   .scl = {
-   .i2c_mode = MX7D_PAD_ENET1_RGMII_TD2__I2C4_SCL | PC,
-   .gpio_mode = MX7D_PAD_ENET1_RGMII_TD2__GPIO7_IO8 | PC,
-   .gp = IMX_GPIO_NR(7, 8),
-   },
-   .sda = {
-   .i2c_mode = MX7D_PAD_ENET1_RGMII_TD3__I2C4_SDA | PC,
-   .gpio_mode = MX7D_PAD_ENET1_RGMII_TD3__GPIO7_IO9 | PC,
-   .gp = IMX_GPIO_NR(7, 9),
-   },
-};
-#endif
-
 int dram_init(void)
 {
gd->ram_size = get_ram_size((void *)PHYS_SDRAM, PHYS_SDRAM_SIZE);
@@ -331,11 +296,6 @@ int board_early_init_f(void)
 {
setup_iomux_uart();
 
-#ifdef CONFIG_SYS_I2C_MXC
-   setup_i2c(0, CONFIG_SYS_I2C_SPEED, 0x7f, _pad_info1);
-   setup_i2c(3, CONFIG_SYS_I2C_SPEED, 0x7f, _pad_info4);
-#endif
-
return 0;
 }
 
diff --git a/include/configs/colibri_imx7.h b/include/configs/colibri_imx7.h
index 16ae952..55d8fcf 100644
--- a/include/configs/colibri_imx7.h
+++ b/include/configs/colibri_imx7.h
@@ -59,9 +59,7 @@
 #undef CONFIG_BOOTM_RTEMS
 
 /* I2C configs */
-#define CONFIG_SYS_I2C
 #define CONFIG_SYS_I2C_MXC
-#define CONFIG_SYS_I2C_MXC_I2C1/* enable I2C bus 1 */
 #define CONFIG_SYS_I2C_SPEED   10
 
 #define CONFIG_IPADDR  192.168.10.2
-- 
2.10.0

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

Re: [U-Boot] [PATCH v3 08/10] binman: Automatically include a U-Boot .dtsi file

[Stefan Bruens]

On Mittwoch, 5. Oktober 2016 10:51:04 CEST Simon Glass wrote:
> Hi Masahiro,
> 
> On 4 October 2016 at 21:51, Masahiro Yamada
> > 
> > We are already suffering from U-Boot specific properties like
> > "u-boot,dm-pre-reloc", which make it difficult to
> > simply copy DT files from the kernel tree.
> > So, my first guess was this feature might be useful
> > to split such properties out to *-u-boot.dtsi.
> > (it is a trade-off of more and more DT files, though.)
> 
> Yes that was Tom's intent. True, it is not binman-specific and I'm
> happy to change the variable, but let's see if this solves the problem
> first.

Is it possible to use a device tree overlay for this?

Kind regards,

Stefan

-- 
Stefan Brüns  /  Bergstraße 21  /  52062 Aachen
home: +49 241 53809034 mobile: +49 151 50412019
work: +49 2405 49936-424
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 01/10] dm: imx: serial: support device tree

[Stefan Agner]

On 2016-10-04 06:02, Stefano Babic wrote:
> Hi Stefan,
> 
> On 29/08/2016 02:00, Stefan Agner wrote:
>>>
>>> I have applied it, I just noted a slight drawback because this breaks
>>> boards that do not have CONFIG_FIT set.
>>
>> Hm, maybe due to missing CONFIG_OF_LIBFDT? Do you want me to fix it, do
>> you have a certain board you can reproduce it?
> 
> No, I have found it. The patchset breaks two boards (gwventana and
> cmx6), and the reason is that lib/fdtdec.c is not compiled. This is
> because CONFIG_OF_CONTROL is not set for these two boards, but as far as
> I understand this should be not set, because there is no device tree for
> these two boards.
> 
> The issue is generate by the feature use_dte: in fact:
> 
>plat->use_dte = fdtdec_get_bool(gd->fdt_blob, dev->of_offset,
> "fsl,dte-mode");
> 
> but for boards without DT, fdtdec is not built and gd->fdt_blob is maybe
> not set.
> 
> Can you take a look ? What do you think about it ?

Hm, I see... I guess we need to add a CONFIG_IS_ENABLED(OF_CONTROL)
there, that is what other drivers also do (e.g.
drivers/gpio/mpc85xx_gpio.c).

> 
> The second issue is related to CONFIG_CUSTOM_BOARDINFO:
> 
>arm:  +   colibri_imx7
> +Error: You must add new CONFIG options using Kconfig
> +The following new ad-hoc CONFIG options were detected:
> +CONFIG_CUSTOM_BOARDINFO
> +
> +Please add these via Kconfig instead. Find a suitable Kconfig
> +file and add a 'config' or 'menuconfig' option.

Yeah I saw that and we either drop that config or will convert it to a
proper Kconfig soon, see also this thread:
http://lists.denx.de/pipermail/u-boot/2016-October/268669.html

> 
> This is related to:
> 
> Author: Stefan Agner 
> Date:   Mon Aug 1 22:50:24 2016 -0700
> 
> configs: enable device tree for Colibri iMX7
> 
> Enable device tree configuration and specify default device tree
> for Toradex Colibri iMX7. Also configure CONFIG_CUSTOM_BOARDINFO
> to avoid that board info get printed twice (once from the device
> tree and one from the runtime detection in board specific code).
> 
> Signed-off-by: Stefan Agner 
> 
> What about to split it ? I will let this patch to just enable the device
> tree, and let fix the double output with a follow up patch. What do you
> think ?

Sure, lets just not add CONFIG_CUSTOM_BOARDINFO for now and fix that
once we figure out what we do with that config. I'll send new version of
these two patches, or do you want a new patch which works ontop of your
next branch?

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

[U-Boot] [PATCH] udoo: Add a README file

[Fabio Estevam]

Add a README file to explain how to build and flash the SD card
for Udoo boards.

Signed-off-by: Fabio Estevam 
---
 board/udoo/README | 21 +
 1 file changed, 21 insertions(+)
 create mode 100644 board/udoo/README

diff --git a/board/udoo/README b/board/udoo/README
new file mode 100644
index 000..6fbcc59
--- /dev/null
+++ b/board/udoo/README
@@ -0,0 +1,21 @@
+How to use U-Boot on MX6Q/DL Udoo boards
+
+
+- Build U-Boot for MX6Q/DL Udoo boards:
+
+$ make mrproper
+$ make udoo_defconfig
+$ make
+
+This will generate the SPL image called SPL and the u-boot.img.
+
+- Flash the SPL image into the SD card:
+
+sudo dd if=SPL of=/dev/mmcblk0 bs=1k seek=1; sync
+
+- Flash the u-boot.img image into the SD card:
+
+sudo dd if=u-boot.img of=/dev/mmcblk0 bs=1k seek=69; sync
+
+- Insert the SD card in the board, power it up and U-Boot messages should
+come up.
-- 
2.7.4

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

[U-Boot] [PATCH 1/1]: environment in eMMC boot partition

[Sergey Kubushyn]

This allows to place U-Boot environment into eMMC boot partition thus
saving space on user partition for the OS (or whatever.) When booting
off of eMMC many (all?) MCUs can use dedicated boot0/boot1 partitions
to boot so U-Boot (or SPL) is written to one (or both) such partitions.
When such boot configuration is used it makes sense to place environment
in the same partition where the U-Boot itself is so the entire user
partition is available for the OS.

It might be not well polished yet but it is a simple patch that can be
reworked later.

It uses 4 Kconfig variables right now which probably belong to the board
Kconfig. Those are:

CONFIG_ENV_IN_EMMC_BOOT -- tells that environment is in eMMC boot
 partition if defined

CONFIG_EMMC_ENV_PART -- tells which boot partition environment should be
 stored in (either 1 or 2)

CONFIG_EMMC_BOOT_PART -- which boot partition will be used by eMMC to
 read U-Boot/SPL binary for boot protocol (either 1 or 2.) That can be
 different from the environment partition

CONFIG_EMMC_BOOT_ACK -- tells that eMMC should provide boot ACKs if
 defined

Here is an excerpt from actual board Kconfig:

=== Cut ===
config ENV_IN_EMMC_BOOT
bool "Environment is in eMMC boot partition"
default y

config EMMC_ENV_PART
hex "eMMC boot partition used for environment (1 or 2)"
default 1

config EMMC_BOOT_PART
hex "eMMC boot partition the board boots off of (1 or 2)"
default 1

config EMMC_BOOT_ACK
bool "Enable ACKs from eMMC when booting off of boot partition"
default n
=== Cut ===

Signed-off-by: Sergey Kubushyn 
---
--- a/common/env_mmc.c
+++ b/common/env_mmc.c
@@ -68,6 +68,45 @@ int env_init(void)
return 0;
 }

+#ifdef CONFIG_ENV_IN_EMMC_BOOT
+__weak u8 mmc_get_env_part(struct mmc *mmc)
+{
+   return CONFIG_EMMC_ENV_PART;
+}
+
+__weak u8 mmc_get_boot_part(struct mmc *mmc)
+{
+   return CONFIG_EMMC_BOOT_PART;
+}
+
+__weak u8 mmc_get_boot_ack(struct mmc *mmc)
+{
+#ifdef CONFIG_EMMC_BOOT_ACK
+   return 1;
+#else
+   return 0;
+#endif
+}
+
+static int mmc_set_env_part(struct mmc *mmc)
+{
+   int ret = 0;
+   u8 boot_part = 0;
+   u8 boot_ack = 0;
+   u8 env_part = 0;
+
+   boot_part = mmc_get_boot_part(mmc);
+   boot_ack = mmc_get_boot_ack(mmc);
+   env_part = mmc_get_env_part(mmc);
+
+   ret = mmc_set_part_conf(mmc, boot_ack, boot_part, env_part);
+
+   if (ret)
+   puts("MMC switch to boot partition failed\n");
+
+   return ret;
+}
+#else
 #ifdef CONFIG_SYS_MMC_ENV_PART
 __weak uint mmc_get_env_part(struct mmc *mmc)
 {
@@ -96,6 +135,7 @@ static int mmc_set_env_part(struct mmc *mmc)
 #else
 static inline int mmc_set_env_part(struct mmc *mmc) {return 0; };
 #endif
+#endif

 static const char *init_mmc_for_env(struct mmc *mmc)
 {
@@ -113,6 +153,15 @@ static const char *init_mmc_for_env(struct mmc *mmc)

 static void fini_mmc_for_env(struct mmc *mmc)
 {
+#ifdef CONFIG_ENV_IN_EMMC_BOOT
+   u8 boot_part = 0;
+   u8 boot_ack = 0;
+
+   boot_part = mmc_get_boot_part(mmc);
+   boot_ack = mmc_get_boot_ack(mmc);
+
+   mmc_set_part_conf(mmc, boot_ack, boot_part, 0);
+#else
 #ifdef CONFIG_SYS_MMC_ENV_PART
int dev = mmc_get_env_dev();

@@ -121,6 +170,7 @@ static void fini_mmc_for_env(struct mmc *mmc)
 #endif
blk_select_hwpart_devnum(IF_TYPE_MMC, dev, env_mmc_orig_hwpart);
 #endif
+#endif
 }

 #ifdef CONFIG_CMD_SAVEENV


---
**
*  KSI@homeKOI8 Net  < >  The impossible we do immediately.  *
*  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
**
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 0/9] Switch bcm283x platform to use OF_CONTROL

[Alexander Graf]

> Am 05.10.2016 um 18:48 schrieb Fabian Vogt :
> 
> Hi,
> 
> Am Mittwoch, 5. Oktober 2016, 09:54:46 CEST schrieb Stephen Warren:
>> On 09/26/2016 06:26 AM, Fabian Vogt wrote:
>>> This patch series modifies the used drivers to work with OF_CONTROL
>>> and switches the board code and configs to use it.
>>> The added device trees are directly from the linux kernel tree
>>> and can thus be used for booting the (upstream) kernel.
>> 
>> Is there a user-visible or developer-visible benefit to this change? In 
>> general, converting to use DT to instantiate devices simply ends up 
>> using more code (and hence complexity and time) to get to the exact same 
>> state afterwards.
> 
> There are various reasons, like:
> 
> - The device tree describes the platform, so it can also be used by the
>  linux kernel for configuration (no separate dtb needed)

With a bit of lobbying, we might even be able to get a working dt from the rpi 
firmware. That again would enable awesome things like hat support in u-boot :).


Alex

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

[U-Boot] [PATCH] spi: fsl_qspi: Preserve endianness of QSPI MCR

[York Sun]

The endianness can be changed by RCW + PBI sequence. It may have
other than power on reset value.

Signed-off-by: York Sun 
CC: Yuan Yao 
CC: Peng Fan 
CC: Alison Wang 
---

 drivers/spi/fsl_qspi.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/spi/fsl_qspi.c b/drivers/spi/fsl_qspi.c
index 2144fca..992bc73 100644
--- a/drivers/spi/fsl_qspi.c
+++ b/drivers/spi/fsl_qspi.c
@@ -865,6 +865,7 @@ static inline struct fsl_qspi *to_qspi_spi(struct spi_slave 
*slave)
 struct spi_slave *spi_setup_slave(unsigned int bus, unsigned int cs,
unsigned int max_hz, unsigned int mode)
 {
+   u32 mcr_val;
struct fsl_qspi *qspi;
struct fsl_qspi_regs *regs;
u32 total_size;
@@ -896,8 +897,10 @@ struct spi_slave *spi_setup_slave(unsigned int bus, 
unsigned int cs,
 
qspi->slave.max_write_size = TX_BUFFER_SIZE;
 
+   mcr_val = qspi_read32(priv->flags, >regs->mcr);
qspi_write32(qspi->priv.flags, >mcr,
-QSPI_MCR_RESERVED_MASK | QSPI_MCR_MDIS_MASK);
+QSPI_MCR_RESERVED_MASK | QSPI_MCR_MDIS_MASK |
+(mcr_val & QSPI_MCR_END_CFD_MASK));
 
qspi_cfg_smpr(>priv,
  ~(QSPI_SMPR_FSDLY_MASK | QSPI_SMPR_DDRSMP_MASK |
@@ -975,6 +978,7 @@ static int fsl_qspi_child_pre_probe(struct udevice *dev)
 
 static int fsl_qspi_probe(struct udevice *bus)
 {
+   u32 mcr_val;
u32 amba_size_per_chip;
struct fsl_qspi_platdata *plat = dev_get_platdata(bus);
struct fsl_qspi_priv *priv = dev_get_priv(bus);
@@ -999,8 +1003,10 @@ static int fsl_qspi_probe(struct udevice *bus)
priv->flash_num = plat->flash_num;
priv->num_chipselect = plat->num_chipselect;
 
+   mcr_val = qspi_read32(priv->flags, >regs->mcr);
qspi_write32(priv->flags, >regs->mcr,
-QSPI_MCR_RESERVED_MASK | QSPI_MCR_MDIS_MASK);
+QSPI_MCR_RESERVED_MASK | QSPI_MCR_MDIS_MASK |
+(mcr_val & QSPI_MCR_END_CFD_MASK));
 
qspi_cfg_smpr(priv, ~(QSPI_SMPR_FSDLY_MASK | QSPI_SMPR_DDRSMP_MASK |
QSPI_SMPR_FSPHS_MASK | QSPI_SMPR_HSENA_MASK), 0);
-- 
2.7.4

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

[U-Boot] [PATCH 1/1]: add nand_bootupdate for i.MX6 and likes

[Sergey Kubushyn]

This one adds nand_bootupdate command for i.MX6 and similar MCUs. It
generates proper NAND boot structures (FCB, DBBT, etc) and writes those
along with U-Boot mx image to where they belong so system would be able
to boot off of raw NAND.

As of now the only way to do it is by using user-space kobs-ng utility
that has lots of unnecessary bells and whistles and only runs from
Linux so it is impossible to update raw NAND U-Boot from U-Boot itself.

It does not give any choice for the actual data placement in NAND but
that is done deliberately -- there is no reason to put it anywhere but
the only location i.MX6 Boot ROM expects it to be.

This is my THIRD attempt to get it into the main U-Boot tree. I do
really hope it would get applied before I retire.

Signed-off-by: Sergey Kubushyn 
---
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -571,6 +571,16 @@ config CMD_TIME
help
  Run commands and summarize execution time.

+config CMD_NAND_BOOTUPDATE
+   bool "Update NAND bootloader on iMX6 and its brethen"
+   depends on ARCH_MX6 && NAND_BOOT && CMD_NAND
+   help
+ Having iMX6 NAND U-Boot image in memory creates all necessary
+ structures and writes those where they belong along with that
+ U-Boot image so system is able to boot off of raw NAND. Kinda
+ like kobs-ng utility but simpler.
+
+
 # TODO: rename to CMD_SLEEP
 config CMD_MISC
bool "sleep"

--- a/drivers/mtd/nand/Makefile
+++ b/drivers/mtd/nand/Makefile
@@ -67,6 +67,7 @@ obj-$(CONFIG_NAND_OMAP_GPMC) += omap_gpmc.o
 obj-$(CONFIG_NAND_OMAP_ELM) += omap_elm.o
 obj-$(CONFIG_NAND_PLAT) += nand_plat.o
 obj-$(CONFIG_NAND_SUNXI) += sunxi_nand.o
+obj-$(CONFIG_CMD_NAND_BOOTUPDATE) += mxs_nand_bootupdate.o

 else  # minimal SPL drivers

--- a/drivers/mtd/nand/mxs_nand.c
+++ b/drivers/mtd/nand/mxs_nand.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 

 #defineMXS_NAND_DMA_DESCRIPTOR_COUNT   4

@@ -150,7 +151,7 @@ static uint32_t mxs_nand_aux_status_offset(void)
return (MXS_NAND_METADATA_SIZE + 0x3) & ~0x3;
 }

-static inline uint32_t mxs_nand_get_ecc_strength(uint32_t page_data_size,
+uint32_t mxs_nand_get_ecc_strength(uint32_t page_data_size,
uint32_t page_oob_size)
 {
int ecc_strength;
@@ -226,14 +227,14 @@ static inline uint32_t mxs_nand_get_mark_offset(uint32_t 
page_data_size,
return block_mark_bit_offset;
 }

-static uint32_t mxs_nand_mark_byte_offset(struct mtd_info *mtd)
+uint32_t mxs_nand_mark_byte_offset(struct mtd_info *mtd)
 {
uint32_t ecc_strength;
ecc_strength = mxs_nand_get_ecc_strength(mtd->writesize, mtd->oobsize);
return mxs_nand_get_mark_offset(mtd->writesize, ecc_strength) >> 3;
 }

-static uint32_t mxs_nand_mark_bit_offset(struct mtd_info *mtd)
+uint32_t mxs_nand_mark_bit_offset(struct mtd_info *mtd)
 {
uint32_t ecc_strength;
ecc_strength = mxs_nand_get_ecc_strength(mtd->writesize, mtd->oobsize);

--- /dev/null
+++ b/arch/arm/include/asm/imx-common/mxs_nand.h
@@ -0,0 +1,37 @@
+/*
+ * Copyright (C) 2015 PHYTEC Messtechnik GmbH,
+ * Author: Stefan Christ 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef __NAND_MXS_H
+#define __NAND_MXS_H
+
+/*
+ * Functions are definied in drivers/mtd/nand/nand_mxs.c.  They are used to
+ * calculate the ECC Strength, BadBlockMarkerByte and BadBlockMarkerStartBit
+ * which are placed into the FCB structure. The i.MX6 ROM needs these
+ * parameters to read the firmware from NAND.
+ *
+ * The parameters depends on the pagesize and oobsize of NAND chips and are
+ * different for each combination. To avoid placing hardcoded values in the bbu
+ * update handler code, the generic calculation from the driver code is used.
+ */
+
+uint32_t mxs_nand_get_ecc_strength(uint32_t page_data_size,
+   uint32_t page_oob_size);
+
+uint32_t mxs_nand_mark_byte_offset(struct mtd_info *mtd);
+
+uint32_t mxs_nand_mark_bit_offset(struct mtd_info *mtd);
+
+#endif /* __NAND_MXS_H */

--- /dev/null
+++ b/drivers/mtd/nand/mxs_nand_bootupdate.c
@@ -0,0 +1,556 @@
+/*
+ * mxs_nand_bootupdate.c - write U-Boot to MXS NAND to make it bootable
+ *
+ * Copyright (c) 2016 Sergey Kubushyn 
+ *
+ * Most of the source shamelesly stolen from barebox.
+ *
+ * Here is the original copyright:
+ *
+ *=== Cut ===
+ * Copyright (C) 2014 Sascha Hauer, Pengutronix
+ *
+ * This program is free software; you can 

[U-Boot] [PATCH 1/1]: filesystems : add "file exists" cmd

[Sergey Kubushyn]

This adds "file exists" commands to generic FS as well as to FAT, EXT4,
and UBIFS. Also adds "file size" command to UBIFS.

The return value for "file exists" commands is REVERSED i.e. they
return 1 if file exists and 0 otherwise. This is a deliberate decision
because those commands are supposed to be used almost exclusively in
scripts and TRUE value is _not_ zero while FALSE is zero.

As of now the only way to check for a file existence is to attempt a
read on that file (aka load.) That works but it makes an unnecessary
read, overwrites memory at destination address if file not a zero
length one, and outputs unnecessary messages to the console in any
case.

Checking file existence in scripts is a valuable feature that allows
the higher level software (e.g. Linux) to interact with U-Boot by
creating some semaphore files and rebooting. We do use it quite
extensively for system setup at manufacturing time and for other
purposes (e.g. our Android "recovery" is implemented this way.)

Signed-off-by: Sergey Kubushyn 
---
--- a/include/fs.h
+++ b/include/fs.h
@@ -90,6 +90,8 @@ int do_ls(cmd_tbl_t *cmdtp, int flag, int argc, char * const 
argv[],
int fstype);
 int file_exists(const char *dev_type, const char *dev_part, const char *file,
int fstype);
+int do_file_exists(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[],
+   int fstype);
 int do_save(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[],
int fstype);

--- a/fs/fs.c
+++ b/fs/fs.c
@@ -76,7 +76,7 @@ struct fstype_info {
 * Is it legal to pass NULL as .probe()'s  fs_dev_desc parameter? This
 * should be false in most cases. For "virtual" filesystems which
 * aren't based on a U-Boot block device (e.g. sandbox), this can be
-* set to true. This should also be true for the dumm entry at the end
+* set to true. This should also be true for the dummy entry at the end
 * of fstypes[], since that is essentially a "virtual" (non-existent)
 * filesystem.
 */
@@ -449,6 +449,18 @@ int file_exists(const char *dev_type, const char 
*dev_part, const char *file,
return fs_exists(file);
 }

+int do_file_exists(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[],
+   int fstype)
+{
+   if (argc != 4)
+   return CMD_RET_USAGE;
+
+   if (fs_set_blk_dev(argv[1], argv[2], fstype))
+   return 1;
+
+   return fs_exists(argv[3]);
+}
+
 int do_save(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[],
int fstype)
 {

--- a/cmd/ext4.c
+++ b/cmd/ext4.c
@@ -48,6 +48,18 @@ int do_ext4_size(cmd_tbl_t *cmdtp, int flag, int argc,
return do_size(cmdtp, flag, argc, argv, FS_TYPE_EXT);
 }

+int do_ext4_file_exists(cmd_tbl_t *cmdtp, int flag, int argc,
+   char *const argv[])
+{
+   int ret;
+
+   ret = do_file_exists(cmdtp, flag, argc, argv, FS_TYPE_EXT);
+ 
+	if (ret == 0) return 1;

+   if (ret == 1) return 0;
+   return ret;
+}
+
 int do_ext4_load(cmd_tbl_t *cmdtp, int flag, int argc,
char *const argv[])
 {
@@ -92,3 +104,9 @@ U_BOOT_CMD(ext4load, 7, 0, do_ext4_load,
   " [ [addr [filename [bytes [pos]\n"
   "- load binary file 'filename' from 'dev' on 'interface'\n"
   "  to address 'addr' from ext4 filesystem");
+
+U_BOOT_CMD(ext4exist,  4,  0,  do_ext4_file_exists,
+   "check if a file exists",
+   "  \n"
+   "- Check if file 'filename' from 'dev' on 'interface'\n"
+   "  exists and return true/false (for scripting.)");

--- a/cmd/fat.c
+++ b/cmd/fat.c
@@ -19,6 +19,23 @@
 #include 
 #include 

+int do_fat_file_exists(cmd_tbl_t *cmdtp, int flag, int argc, char * const 
argv[])
+{
+   int ret;
+ 
+	ret= do_file_exists(cmdtp, flag, argc, argv, FS_TYPE_FAT);

+
+   if (ret == 0) return 1;
+   if (ret == 1) return 0;
+   return ret;
+}
+
+U_BOOT_CMD(fatexist,   4,  0,  do_fat_file_exists,
+   "check if a file exists",
+   "  \n"
+   "- Check if file 'filename' from 'dev' on 'interface'\n"
+   "  exists and return true/false (for scripting.)");
+
 int do_fat_size(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
 {
return do_size(cmdtp, flag, argc, argv, FS_TYPE_FAT);

--- a/cmd/ubifs.c
+++ b/cmd/ubifs.c
@@ -98,6 +98,7 @@ static int do_ubifs_ls(cmd_tbl_t *cmdtp, int flag, int argc,
return ret;
 }

+
 static int do_ubifs_load(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
 {
@@ -137,6 +138,45 @@ static int do_ubifs_load(cmd_tbl_t *cmdtp, int flag, int 
argc,
return ret;
 }

+static int do_ubifs_file_exists(cmd_tbl_t *cmdtp, int flag, int argc,
+   char * const argv[])
+{
+   int ret;
+

Re: [U-Boot] [PATCH 1/2] armv8: ls2080: Enable CONFIG_DM_USB in defconfigs

[york sun]

On 09/28/2016 11:18 PM, Sriram Dash wrote:
> Enables driver model flag CONFIG_DM_USB for LS2080A
> platform defconfigs.
>
> Signed-off-by: Sriram Dash 
> ---
>  configs/ls2080aqds_SECURE_BOOT_defconfig | 1 +
>  configs/ls2080aqds_defconfig | 1 +
>  configs/ls2080aqds_nand_defconfig| 1 +
>  configs/ls2080aqds_qspi_defconfig| 1 +
>  configs/ls2080ardb_SECURE_BOOT_defconfig | 1 +
>  configs/ls2080ardb_defconfig | 1 +
>  configs/ls2080ardb_nand_defconfig| 2 ++
>  7 files changed, 8 insertions(+)

Sriram,

Please retest ls2080ardb_nand. It fails in my build.

"undefined reference to `dm_scan_fdt_dev'"

York

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

Re: [U-Boot] [PATCH v6 0/2] armv8: Support loading 32-bit OS in AArch32 execution state

[york sun]

On 09/09/2016 01:56 AM, Alison Wang wrote:
> This series is to support loading a 32-bit OS, the execution state will 
> change from
> AArch64 to AArch32 when jumping to kernel. The architecture information will 
> be got
> through checking FIT image, then U-Boot will load 32-bit OS or 64-bit OS 
> automatically.
>
> Spin-table method is used for secondary cores to load 32-bit OS. The 
> architecture
> information will be got through checking FIT image and saved in the os_arch 
> element
> of spin-table, then the secondary cores will check os_arch and jump to 32-bit 
> OS or
> 64-bit OS automatically.
>
> ---
> Changes in v6:
> - Modified armv8_switch_to_el1(). It will always jump to ep when switching to 
> AArch64 or AArch32 modes.
> - Make other platforms compatible with the new armv8_switch_to_el2() and 
> armv8_switch_to_el1().
>
> Changes in v5:
> - Modified armv8_switch_to_el2(). It will always jump to ep when switching to 
> AArch64 or AArch32 modes.
> - Make secondary_switch_to_el2() always jump to ep when switching to AArch64 
> or AArch32 modes.
>
> Changes in v4:
> - Correct config ARM64_SUPPORT_AARCH32.
> - Omit arch and ftaddr arguments.
> - Rename "xreg5" to "tmp".
> - Use xxx_RES1 to combine all RES1 fields in xxx register.
> - Use an immediate cmp directly.
> - Use #ifdef for CONFIG_ARM64_SUPPORT_AARCH32.
>
> Changes in v3:
> - Comments the functions and the arguments.
> - Rename the real parameters.
> - Use the macros instead of the magic values.
> - Remove the redundant codes.
> - Clean up all of the mess in boot_jump_linux().
> - Add CONFIG_ARM64_SUPPORT_AARCH32 to detect for some ARM64 system doesn't 
> support AArch32 state.
> - Adjust the arguments for armv8_switch_to_el2_m and armv8_switch_to_el1_m.
>
> Changes in v2:
> - armv8_switch_to_el2_aarch32() is removed. armv8_switch_to_el2_m is used
>   to switch to AArch64 EL2 or AArch32 Hyp.
> - armv8_switch_to_el1_aarch32() is removed. armv8_switch_to_el1_m is used
>   to switch to AArch64 EL1 or AArch32 SVC.
> - Support to call armv8_switch_to_el2_m and armv8_switch_to_el1_m.
>
> 
> Alison Wang (2):
>   armv8: Support loading 32-bit OS in AArch32 execution state
>   armv8: fsl-layerscape: SMP support for loading 32-bit OS

Alison,

The change overall is OK, but the way you split the patches is not. If 
you apply the first patch and then compile, you will see all our armv8 
platforms are broken. You changed the definition of macro 
armv8_switch_to_el2_m in the first patch, but you change the call in the 
second patch.

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

[U-Boot] [PATCH RFC v8 15/16] mtd: spi-nor: zynq_qspi: Kconfig: Add MTD_ZYNQ

[Jagan Teki]

Add CONFIG_MTD_ZYNQ_QSPI kconfig entry

Signed-off-by: Jagan Teki 
---
 drivers/mtd/spi-nor/Kconfig | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/mtd/spi-nor/Kconfig b/drivers/mtd/spi-nor/Kconfig
index 64d5553..4b2a5e8 100644
--- a/drivers/mtd/spi-nor/Kconfig
+++ b/drivers/mtd/spi-nor/Kconfig
@@ -46,6 +46,15 @@ config MTD_SPI_NOR_USE_4K_SECTORS
  Please note that some tools/drivers/filesystems may not work with
  4096 B erase size (e.g. UBIFS requires 15 KiB as a minimum).
 
+config MTD_ZYNQ_QSPI
+   bool "Zynq QSPI NOR controller driver"
+   depends on ARCH_ZYNQ
+   help
+ Enable the Zynq Quad-SPI (QSPI) driver. This driver can be
+ used to access the SPI NOR flash on platforms embedding this
+ Zynq QSPI IP core. This IP is used to connect the flash in
+ 4-bit qspi, 8-bit dual stacked and shared 4-bit dual parallel.
+
 config SPI_NOR_MISC
bool "Miscellaneous SPI NOR flash's support"
help
-- 
2.7.4

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

[U-Boot] [PATCH RFC v8 16/16] mtd: spi-nor: Add 4-byte address width support

[Jagan Teki]

Add 4-byte address supports, so-that SPI-NOR chips
has > 16MiB should accessible.

Signed-off-by: Jagan Teki 
---
 drivers/mtd/spi-nor/m25p80.c  |  1 +
 drivers/mtd/spi-nor/spi-nor.c | 36 
 include/linux/mtd/spi-nor.h   |  6 +-
 3 files changed, 42 insertions(+), 1 deletion(-)

diff --git a/drivers/mtd/spi-nor/m25p80.c b/drivers/mtd/spi-nor/m25p80.c
index 3393bed..42df9ef 100644
--- a/drivers/mtd/spi-nor/m25p80.c
+++ b/drivers/mtd/spi-nor/m25p80.c
@@ -31,6 +31,7 @@ static void m25p_addr2cmd(struct spi_nor *nor, unsigned int 
addr, u8 *cmd)
cmd[1] = addr >> (nor->addr_width * 8 -  8);
cmd[2] = addr >> (nor->addr_width * 8 - 16);
cmd[3] = addr >> (nor->addr_width * 8 - 24);
+   cmd[4] = addr >> (nor->addr_width * 8 - 32);
 }
 
 static int m25p_cmdsz(struct spi_nor *nor)
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index c280287..f49a70c 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -379,6 +379,36 @@ static int sst_write_bp(struct udevice *dev, loff_t to, 
size_t len,
 }
 #endif
 
+/* Enable/disable 4-byte addressing mode. */
+static int set_4byte(struct spi_nor *nor, const struct spi_nor_info *info,
+int enable)
+{
+   int status;
+   bool need_wren = false;
+   u8 cmd;
+
+   switch (JEDEC_MFR(info)) {
+   case SNOR_MFR_MICRON:
+   /* Some Micron need WREN command; all will accept it */
+   need_wren = true;
+   case SNOR_MFR_MACRONIX:
+   case SNOR_MFR_WINBOND:
+   if (need_wren)
+   write_enable(nor);
+
+   cmd = enable ? SNOR_OP_EN4B : SNOR_OP_EX4B;
+   status = nor->write_reg(nor, cmd, NULL, 0);
+   if (need_wren)
+   write_disable(nor);
+
+   return status;
+   default:
+   /* Spansion style */
+   nor->cmd_buf[0] = enable << 7;
+   return nor->write_reg(nor, SNOR_OP_BRWR, nor->cmd_buf, 1);
+   }
+}
+
 #ifdef CONFIG_SPI_NOR_MACRONIX
 static int macronix_quad_enable(struct spi_nor *nor)
 {
@@ -614,6 +644,12 @@ int spi_nor_scan(struct udevice *dev)
}
 
nor->addr_width = 3;
+   if (mtd->size > SNOR_16MB_BOUN) {
+   nor->addr_width = 4;
+   ret = set_4byte(nor, info, true);
+   if (ret)
+   return ret;
+   }
 
/* Dummy cycles for read */
switch (nor->read_opcode) {
diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
index e2e225a..8f7db7f 100644
--- a/include/linux/mtd/spi-nor.h
+++ b/include/linux/mtd/spi-nor.h
@@ -62,6 +62,10 @@
 #define SNOR_OP_BP 0x02/* Byte program */
 #define SNOR_OP_AAI_WP 0xad/* Auto addr increment word program */
 
+/* Used for Macronix and Winbond flashes. */
+#define SNOR_OP_EN4B   0xb7/* Enter 4-byte mode */
+#define SNOR_OP_EX4B   0xe9/* Exit 4-byte mode */
+
 /* Status Register bits. */
 #define SR_WIP BIT(0)  /* Write in progress */
 #define SR_WEL BIT(1)  /* Write enable latch */
@@ -83,7 +87,7 @@
 /* Flash timeout values */
 #define SNOR_READY_WAIT_PROG   (2 * CONFIG_SYS_HZ)
 #define SNOR_READY_WAIT_ERASE  (5 * CONFIG_SYS_HZ)
-#define SNOR_MAX_CMD_SIZE  4
+#define SNOR_MAX_CMD_SIZE  6
 #define SNOR_16MB_BOUN 0x100
 
 enum snor_option_flags {
-- 
2.7.4

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

[U-Boot] [PATCH RFC v8 14/16] mtd: spi-nor: Add zynq qspi driver

[Jagan Teki]

Zynq qspi controller is works similar way as generic
spi controller with additional features that make this
controller work more specific to flash chips as salve
devices.

Why, zynq qspi written as spi-nor controller driver.

(1) BAR:
It operates the flash chips which are > 16MiB actual
size, but with 3-byte addressing. Usually flash chips
> 16MiB need to operate it on 4-byte addressing but the
zynq qspi controller doesn't support 4-byte addressing.

So, it's a Job of spi-nor generic core to handle flash
chips > 16MiB in 3-byte addressing using bank address reg.

This approach has some issues like spi-nor core generic
operations like read/write/erase has to modify and some
dificuly in adding 4-byte addressing support.

(2) dual flash:
This describes two/dual memories are connected with
a single chip select line from a controller like dual stack
and dual parallel connections see doc/SPI/README.dual-flash
for more details.

Adding this support to spi-nor core looks quite managable and
other generic code might effect and more over this is controller
specific.

Signed-off-by: Jagan Teki 
---
 drivers/mtd/spi-nor/Makefile|   3 +
 drivers/mtd/spi-nor/zynq_qspi.c | 638 
 2 files changed, 641 insertions(+)
 create mode 100644 drivers/mtd/spi-nor/zynq_qspi.c

diff --git a/drivers/mtd/spi-nor/Makefile b/drivers/mtd/spi-nor/Makefile
index 9478720..ebe60d6 100644
--- a/drivers/mtd/spi-nor/Makefile
+++ b/drivers/mtd/spi-nor/Makefile
@@ -10,3 +10,6 @@ endif
 
 ## spi-nor to spi interface driver
 obj-$(CONFIG_MTD_M25P80)   += m25p80.o
+
+## spi-nor drivers
+obj-$(CONFIG_MTD_ZYNQ_QSPI)+= zynq_qspi.o
diff --git a/drivers/mtd/spi-nor/zynq_qspi.c b/drivers/mtd/spi-nor/zynq_qspi.c
new file mode 100644
index 000..d637217
--- /dev/null
+++ b/drivers/mtd/spi-nor/zynq_qspi.c
@@ -0,0 +1,638 @@
+/*
+ * (C) Copyright 2016 Jagan Teki 
+ *
+ * Xilinx Zynq Quad-SPI(QSPI) controller driver (master mode only)
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+/* zynq qspi register bit masks ZYNQ_QSPI___MASK */
+#define ZYNQ_QSPI_CR_IFMODE_MASK   BIT(31) /* Flash intrface mode*/
+#define ZYNQ_QSPI_CR_MSA_MASK  BIT(15) /* Manual start enb */
+#define ZYNQ_QSPI_CR_MCS_MASK  BIT(14) /* Manual chip select */
+#define ZYNQ_QSPI_CR_PCS_MASK  BIT(10) /* Peri chip select */
+#define ZYNQ_QSPI_CR_FW_MASK   GENMASK(7, 6)   /* FIFO width */
+#define ZYNQ_QSPI_CR_SS_MASK   GENMASK(13, 10) /* Slave Select */
+#define ZYNQ_QSPI_CR_BAUD_MASK GENMASK(5, 3)   /* Baud rate div */
+#define ZYNQ_QSPI_CR_CPHA_MASK BIT(2)  /* Clock phase */
+#define ZYNQ_QSPI_CR_CPOL_MASK BIT(1)  /* Clock polarity */
+#define ZYNQ_QSPI_CR_MSTREN_MASK   BIT(0)  /* Mode select */
+#define ZYNQ_QSPI_IXR_RXNEMPTY_MASKBIT(4)  /* RX_FIFO_not_empty */
+#define ZYNQ_QSPI_IXR_TXOW_MASKBIT(2)  /* TX_FIFO_not_full */
+#define ZYNQ_QSPI_IXR_ALL_MASK GENMASK(6, 0)   /* All IXR bits */
+#define ZYNQ_QSPI_ENR_SPI_EN_MASK  BIT(0)  /* SPI Enable */
+#define ZYNQ_QSPI_LQSPICFG_LQMODE_MASK BIT(31) /* Linear QSPI Mode */
+
+/* zynq qspi Transmit Data Register */
+#define ZYNQ_QSPI_TXD_00_00_OFFSET 0x1C/* Transmit 4-byte inst */
+#define ZYNQ_QSPI_TXD_00_01_OFFSET 0x80/* Transmit 1-byte inst */
+#define ZYNQ_QSPI_TXD_00_10_OFFSET 0x84/* Transmit 2-byte inst */
+#define ZYNQ_QSPI_TXD_00_11_OFFSET 0x88/* Transmit 3-byte inst */
+
+#define ZYNQ_QSPI_XFER_BEGIN   BIT(0)
+#define ZYNQ_QSPI_XFER_END BIT(1)
+#define ZYNQ_QSPI_TXFIFO_THRESHOLD 1   /* Tx FIFO threshold level*/
+#define ZYNQ_QSPI_RXFIFO_THRESHOLD 32  /* Rx FIFO threshold level */
+
+#define ZYNQ_QSPI_CR_BAUD_MAX  8   /* Baud rate divisor max val */
+#define ZYNQ_QSPI_CR_BAUD_SHIFT3   /* Baud rate divisor 
shift */
+#define ZYNQ_QSPI_CR_SS_SHIFT  10  /* Slave select shift */
+#define ZYNQ_QSPI_MAX_CMDSZ4   /* 1 byte opcode,3 byte addr */
+
+#define ZYNQ_QSPI_FIFO_DEPTH   63
+#ifndef CONFIG_SYS_ZYNQ_QSPI_WAIT
+#define CONFIG_SYS_ZYNQ_QSPI_WAIT  CONFIG_SYS_HZ/100   /* 10 ms */
+#endif
+
+/* zynq qspi register set */
+struct zynq_qspi_regs {
+   u32 cr; /* 0x00 */
+   u32 isr;/* 0x04 */
+   u32 ier;/* 0x08 */
+   u32 idr;/* 0x0C */
+   u32 imr;/* 0x10 */
+   u32 enr;/* 0x14 */
+   u32 dr; /* 0x18 */
+   u32 txd0r;  /* 0x1C */
+   u32 drxr;   /* 0x20 */
+   u32 sicr;   /* 0x24 */
+   u32 txftr;  /* 0x28 */
+   u32 rxftr;  /* 0x2C */
+   u32 gpior;  /* 0x30 */
+   u32 reserved0[19];
+   u32 txd1r;   

[U-Boot] [PATCH RFC v8 13/16] mtd: spi-nor: Kconfig: Add MTD_M25P80 entry

[Jagan Teki]

Add CONFIG_MTD_M25P80 kconfig entry

Signed-off-by: Jagan Teki 
---
 drivers/mtd/spi-nor/Kconfig | 17 +
 1 file changed, 17 insertions(+)

diff --git a/drivers/mtd/spi-nor/Kconfig b/drivers/mtd/spi-nor/Kconfig
index 3ad2b16..64d5553 100644
--- a/drivers/mtd/spi-nor/Kconfig
+++ b/drivers/mtd/spi-nor/Kconfig
@@ -15,6 +15,23 @@ menuconfig MTD_SPI_NOR
 
 if MTD_SPI_NOR
 
+config MTD_M25P80
+   tristate "Support most SPI Flash chips (AT26DF, M25P, W25X, ...)"
+   depends on DM_SPI
+   help
+ This enables access to most modern SPI flash chips, used for
+ program and data storage.   Series supported include Atmel AT26DF,
+ Spansion S25SL, SST 25VF, ST M25P, and Winbond W25X.  Other chips
+ are supported as well.  See the driver source for the current list,
+ or to add other chips.
+
+ Note that the original DataFlash chips (AT45 series, not AT26DF),
+ need an entirely different driver.
+
+ Set up your spi devices with the right board-specific platform data,
+ if you want to specify device partitioning or to use a device which
+ doesn't support the JEDEC ID instruction.
+
 config MTD_SPI_NOR_USE_4K_SECTORS
bool "Use small 4096 B erase sectors"
default y
-- 
2.7.4

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

[U-Boot] [PATCH RFC v8 12/16] mtd: spi-nor: Add m25p80 driver

[Jagan Teki]

This is MTD SPI-NOR driver for ST M25Pxx (and similar)
serial flash chips which is written as MTD_UCLASS.

Signed-off-by: Jagan Teki 
---
 drivers/mtd/spi-nor/Makefile |   3 +
 drivers/mtd/spi-nor/m25p80.c | 217 +++
 2 files changed, 220 insertions(+)
 create mode 100644 drivers/mtd/spi-nor/m25p80.c

diff --git a/drivers/mtd/spi-nor/Makefile b/drivers/mtd/spi-nor/Makefile
index 8675047..9478720 100644
--- a/drivers/mtd/spi-nor/Makefile
+++ b/drivers/mtd/spi-nor/Makefile
@@ -7,3 +7,6 @@
 ifdef CONFIG_MTD_SPI_NOR
 obj-y  += spi-nor.o spi-nor-ids.o
 endif
+
+## spi-nor to spi interface driver
+obj-$(CONFIG_MTD_M25P80)   += m25p80.o
diff --git a/drivers/mtd/spi-nor/m25p80.c b/drivers/mtd/spi-nor/m25p80.c
new file mode 100644
index 000..3393bed
--- /dev/null
+++ b/drivers/mtd/spi-nor/m25p80.c
@@ -0,0 +1,217 @@
+/*
+ * MTD SPI-NOR driver for ST M25Pxx (and similar) serial flash chips
+ *
+ * Copyright (C) 2016 Jagan Teki 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include 
+#include 
+
+#define MAX_CMD_SIZE   6
+struct m25p {
+   struct spi_slave*spi;
+   struct spi_nor  spi_nor;
+   u8  command[MAX_CMD_SIZE];
+};
+
+static void m25p_addr2cmd(struct spi_nor *nor, unsigned int addr, u8 *cmd)
+{
+   /* opcode is in cmd[0] */
+   cmd[1] = addr >> (nor->addr_width * 8 -  8);
+   cmd[2] = addr >> (nor->addr_width * 8 - 16);
+   cmd[3] = addr >> (nor->addr_width * 8 - 24);
+}
+
+static int m25p_cmdsz(struct spi_nor *nor)
+{
+   return 1 + nor->addr_width;
+}
+
+static int m25p80_read_reg(struct spi_nor *nor, u8 opcode, u8 *val, int len)
+{
+   struct m25p *flash = nor->priv;
+   struct spi_slave *spi = flash->spi;
+   int ret;
+
+   ret = spi_write_then_read(spi, , 1, NULL, val, len);
+   if (ret < 0) {
+   debug("m25p80: error %d reading register %x\n", ret, opcode);
+   return ret;
+   }
+
+   return ret;
+}
+
+static int m25p80_write_reg(struct spi_nor *nor, u8 opcode, u8 *buf, int len)
+{
+   struct m25p *flash = nor->priv;
+   struct spi_slave *spi = flash->spi;
+   int ret;
+
+   ret = spi_write_then_read(spi, , 1, buf, NULL, len);
+   if (ret < 0) {
+   debug("m25p80: error %d writing register %x\n", ret, opcode);
+   return ret;
+   }
+
+   return ret;
+}
+
+/*
+ * TODO: remove the weak after all the other spi_flash_copy_mmap
+ * implementations removed from drivers
+ */
+void __weak flash_copy_mmap(void *data, void *offset, size_t len)
+{
+#ifdef CONFIG_DMA
+   if (!dma_memcpy(data, offset, len))
+   return;
+#endif
+   memcpy(data, offset, len);
+}
+
+static int m25p80_read(struct spi_nor *nor, loff_t from, size_t len,
+  u_char *buf)
+{
+   struct m25p *flash = nor->priv;
+   struct spi_slave *spi = flash->spi;
+   unsigned int dummy = nor->read_dummy;
+   int ret;
+
+   if (nor->memory_map) {
+   spi_xfer(spi, 0, NULL, NULL, SPI_XFER_MMAP);
+   flash_copy_mmap(buf, nor->memory_map + from, len);
+   spi_xfer(spi, 0, NULL, NULL, SPI_XFER_MMAP_END);
+   spi_release_bus(spi);
+   return 0;
+   }
+
+   /* convert the dummy cycles to the number of bytes */
+   dummy /= 8;
+
+   flash->command[0] = nor->read_opcode;
+   m25p_addr2cmd(nor, from, flash->command);
+
+   ret = spi_write_then_read(spi, flash->command, m25p_cmdsz(nor) + dummy,
+ NULL, buf, len);
+   if (ret < 0) {
+   debug("m25p80: error %d reading %x\n", ret, flash->command[0]);
+   return ret;
+   }
+
+   return ret;
+}
+
+static int m25p80_write(struct spi_nor *nor, loff_t to, size_t len,
+   const u_char *buf)
+{
+   struct m25p *flash = nor->priv;
+   struct spi_slave *spi = flash->spi;
+   int cmd_sz = m25p_cmdsz(nor);
+   int ret;
+
+   if ((nor->program_opcode == SNOR_OP_AAI_WP) && (buf != NULL))
+   cmd_sz = 1;
+
+   flash->command[0] = nor->program_opcode;
+   if (buf == NULL)
+   flash->command[0] = nor->erase_opcode;
+   m25p_addr2cmd(nor, to, flash->command);
+
+   ret = spi_write_then_read(spi, flash->command, cmd_sz, buf, NULL, len);
+   if (ret < 0) {
+   debug("m25p80: error %d writing %x\n", ret, flash->command[0]);
+   return ret;
+   }
+
+   return ret;
+}
+
+static int m25p_probe(struct udevice *dev)
+{
+   struct mtd_info *mtd = mtd_get_info(dev);
+   struct spi_slave *spi = dev_get_parent_priv(dev);
+   struct m25p *flash = dev_get_priv(dev);
+   struct spi_nor *nor;
+   int ret;
+
+   nor = >spi_nor;
+
+   flash->spi = spi;

[U-Boot] [PATCH RFC v8 11/16] spi: Add spi_write_then_read

[Jagan Teki]

Add support for SPI synchronous write followed by read,
this is common interface call from spi-nor to spi drivers.

Signed-off-by: Jagan Teki 
---
 drivers/spi/spi-uclass.c | 24 
 include/spi.h| 20 
 2 files changed, 44 insertions(+)

diff --git a/drivers/spi/spi-uclass.c b/drivers/spi/spi-uclass.c
index d9c49e4..bb33fd8 100644
--- a/drivers/spi/spi-uclass.c
+++ b/drivers/spi/spi-uclass.c
@@ -108,6 +108,30 @@ int spi_xfer(struct spi_slave *slave, unsigned int bitlen,
return dm_spi_xfer(slave->dev, bitlen, dout, din, flags);
 }
 
+int spi_write_then_read(struct spi_slave *slave, const u8 *opcode,
+   size_t n_opcode, const u8 *txbuf, u8 *rxbuf,
+   size_t n_buf)
+{
+   unsigned long flags = SPI_XFER_BEGIN;
+   int ret;
+
+   if (n_buf == 0)
+   flags |= SPI_XFER_END;
+
+   ret = spi_xfer(slave, n_opcode * 8, opcode, NULL, flags);
+   if (ret) {
+   debug("spi: failed to send command (%zu bytes): %d\n",
+ n_opcode, ret);
+   } else if (n_buf != 0) {
+   ret = spi_xfer(slave, n_buf * 8, txbuf, rxbuf, SPI_XFER_END);
+   if (ret)
+   debug("spi: failed to transfer %zu bytes of data: %d\n",
+ n_buf, ret);
+   }
+
+   return ret;
+}
+
 static int spi_child_post_bind(struct udevice *dev)
 {
struct dm_spi_slave_platdata *plat = dev_get_parent_platdata(dev);
diff --git a/include/spi.h b/include/spi.h
index 4c17983..336ac99 100644
--- a/include/spi.h
+++ b/include/spi.h
@@ -258,6 +258,26 @@ int spi_set_wordlen(struct spi_slave *slave, unsigned int 
wordlen);
 int  spi_xfer(struct spi_slave *slave, unsigned int bitlen, const void *dout,
void *din, unsigned long flags);
 
+/**
+ * spi_write_then_read - SPI synchronous write followed by read
+ *
+ * This performs a half duplex transaction in which the first transaction
+ * is to send the opcode and if the length of buf is non-zero then it start
+ * the second transaction as tx or rx based on the need from respective slave.
+ *
+ * @slave: slave device with which opcode/data will be exchanged
+ * @opcode:opcode used for specific transfer
+ * @n_opcode:  size of opcode, in bytes
+ * @txbuf: buffer into which data to be written
+ * @rxbuf: buffer into which data will be read
+ * @n_buf: size of buf (whether it's [tx|rx]buf), in bytes
+ *
+ * Returns: 0 on success, not 0 on failure
+ */
+int spi_write_then_read(struct spi_slave *slave, const u8 *opcode,
+   size_t n_opcode, const u8 *txbuf, u8 *rxbuf,
+   size_t n_buf);
+
 /* Copy memory mapped data */
 void spi_flash_copy_mmap(void *data, void *offset, size_t len);
 
-- 
2.7.4

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

[U-Boot] [PATCH RFC v8 09/16] mtd: spi-nor: Kconfig: Add SPI_NOR_SST entry

[Jagan Teki]

Added CONFIG_SPI_NOR_SST kconfig entry

Signed-off-by: Jagan Teki 
---
 drivers/mtd/spi-nor/Kconfig | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/mtd/spi-nor/Kconfig b/drivers/mtd/spi-nor/Kconfig
index 8ed4891..edcc47e 100644
--- a/drivers/mtd/spi-nor/Kconfig
+++ b/drivers/mtd/spi-nor/Kconfig
@@ -50,4 +50,9 @@ config SPI_NOR_STMICRO
help
  Add support for various STMicro SPI flash chips (M25Pxxx and N25Qxxx)
 
+config SPI_NOR_SST
+   bool "SST SPI NOR flash support"
+   help
+ Add support for various SST SPI flash chips (SST25xxx)
+
 endif # MTD_SPI_NOR
-- 
2.7.4

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

[U-Boot] [PATCH RFC v8 07/16] mtd: spi-nor: Kconfig: Add SPI_NOR_SPANSION entry

[Jagan Teki]

Added CONFIG_SPI_NOR_SPANSION kconfig entry

Signed-off-by: Jagan Teki 
---
 drivers/mtd/spi-nor/Kconfig | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/mtd/spi-nor/Kconfig b/drivers/mtd/spi-nor/Kconfig
index c0ca14b..d4303db 100644
--- a/drivers/mtd/spi-nor/Kconfig
+++ b/drivers/mtd/spi-nor/Kconfig
@@ -40,4 +40,9 @@ config SPI_NOR_MACRONIX
help
  Add support for various Macronix SPI flash chips (MX25Lxxx)
 
+config SPI_NOR_SPANSION
+   bool "Spansion SPI NOR flash support"
+   help
+ Add support for various Spansion SPI flash chips (S25FLxxx)
+
 endif # MTD_SPI_NOR
-- 
2.7.4

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

[U-Boot] [PATCH RFC v8 10/16] mtd: spi-nor: Kconfig: Add SPI_NOR_WINBOND entry

[Jagan Teki]

Added CONFIG_SPI_NOR_WINBOND kconfig entry

Signed-off-by: Jagan Teki 
---
 drivers/mtd/spi-nor/Kconfig | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/mtd/spi-nor/Kconfig b/drivers/mtd/spi-nor/Kconfig
index edcc47e..3ad2b16 100644
--- a/drivers/mtd/spi-nor/Kconfig
+++ b/drivers/mtd/spi-nor/Kconfig
@@ -55,4 +55,9 @@ config SPI_NOR_SST
help
  Add support for various SST SPI flash chips (SST25xxx)
 
+config SPI_NOR_WINBOND
+   bool "Winbond SPI NOR flash support"
+   help
+ Add support for various Winbond SPI flash chips (W25xxx)
+
 endif # MTD_SPI_NOR
-- 
2.7.4

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

[U-Boot] [PATCH RFC v8 08/16] mtd: spi-nor: Kconfig: Add SPI_NOR_STMICRO entry

[Jagan Teki]

Added CONFIG_SPI_NOR_STMICRO kconfig entry

Signed-off-by: Jagan Teki 
---
 drivers/mtd/spi-nor/Kconfig | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/mtd/spi-nor/Kconfig b/drivers/mtd/spi-nor/Kconfig
index d4303db..8ed4891 100644
--- a/drivers/mtd/spi-nor/Kconfig
+++ b/drivers/mtd/spi-nor/Kconfig
@@ -45,4 +45,9 @@ config SPI_NOR_SPANSION
help
  Add support for various Spansion SPI flash chips (S25FLxxx)
 
+config SPI_NOR_STMICRO
+   bool "STMicro SPI NOR flash support"
+   help
+ Add support for various STMicro SPI flash chips (M25Pxxx and N25Qxxx)
+
 endif # MTD_SPI_NOR
-- 
2.7.4

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

[U-Boot] [PATCH RFC v8 06/16] mtd: spi-nor: Kconfig: Add SPI_NOR_MACRONIX entry

[Jagan Teki]

Added CONFIG_SPI_NOR_MACRONIX kconfig entry

Signed-off-by: Jagan Teki 
---
 drivers/mtd/spi-nor/Kconfig | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/mtd/spi-nor/Kconfig b/drivers/mtd/spi-nor/Kconfig
index 348709b..c0ca14b 100644
--- a/drivers/mtd/spi-nor/Kconfig
+++ b/drivers/mtd/spi-nor/Kconfig
@@ -35,4 +35,9 @@ config SPI_NOR_MISC
  Add SPI-NOR support for various flash chips like Atmel, EON,
  GigaDevice, and ISSI.
 
+config SPI_NOR_MACRONIX
+   bool "Macronix SPI NOR flash support"
+   help
+ Add support for various Macronix SPI flash chips (MX25Lxxx)
+
 endif # MTD_SPI_NOR
-- 
2.7.4

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

[U-Boot] [PATCH RFC v8 04/16] mtd: spi-nor: Kconfig: Add MTD_SPI_NOR_USE_4K_SECTORS

[Jagan Teki]

Added CONFIG_MTD_SPI_NOR_USE_4K_SECTORS kconfig entry

Signed-off-by: Jagan Teki 
---
 drivers/mtd/spi-nor/Kconfig | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/drivers/mtd/spi-nor/Kconfig b/drivers/mtd/spi-nor/Kconfig
index 130b0a4..40cd5ba 100644
--- a/drivers/mtd/spi-nor/Kconfig
+++ b/drivers/mtd/spi-nor/Kconfig
@@ -12,3 +12,21 @@ menuconfig MTD_SPI_NOR
  as a common core framework between the generic SPI controller drivers 
vs
  SPI-NOR controller drivers for SPI-NOR device access. Note that from 
SPI-NOR
  core to SPI drivers there should be an interface layer.
+
+if MTD_SPI_NOR
+
+config MTD_SPI_NOR_USE_4K_SECTORS
+   bool "Use small 4096 B erase sectors"
+   default y
+   help
+ Many flash memories support erasing small (4096 B) sectors. Depending
+ on the usage this feature may provide performance gain in comparison
+ to erasing whole blocks (32/64 KiB).
+ Changing a small part of the flash's contents is usually faster with
+ small sectors. On the other hand erasing should be faster when using
+ 64 KiB block instead of 16 × 4 KiB sectors.
+
+ Please note that some tools/drivers/filesystems may not work with
+ 4096 B erase size (e.g. UBIFS requires 15 KiB as a minimum).
+
+endif # MTD_SPI_NOR
-- 
2.7.4

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

[U-Boot] [PATCH RFC v8 03/16] mtd: spi-nor: Kconfig: Add MTD_SPI_NOR entry

[Jagan Teki]

Added CONFIG_MTD_SPI_NOR kconfig entry

Signed-off-by: Jagan Teki 
---
 drivers/mtd/Kconfig |  2 ++
 drivers/mtd/spi-nor/Kconfig | 14 ++
 2 files changed, 16 insertions(+)
 create mode 100644 drivers/mtd/spi-nor/Kconfig

diff --git a/drivers/mtd/Kconfig b/drivers/mtd/Kconfig
index 3a9705c..3dc4221 100644
--- a/drivers/mtd/Kconfig
+++ b/drivers/mtd/Kconfig
@@ -41,4 +41,6 @@ source "drivers/mtd/nand/Kconfig"
 
 source "drivers/mtd/spi/Kconfig"
 
+source "drivers/mtd/spi-nor/Kconfig"
+
 source "drivers/mtd/ubi/Kconfig"
diff --git a/drivers/mtd/spi-nor/Kconfig b/drivers/mtd/spi-nor/Kconfig
new file mode 100644
index 000..130b0a4
--- /dev/null
+++ b/drivers/mtd/spi-nor/Kconfig
@@ -0,0 +1,14 @@
+menuconfig MTD_SPI_NOR
+   tristate "SPI-NOR device support"
+   depends on MTD
+   help
+ This is the core SPI NOR framework which can be used to interact 
SPI-NOR
+ to SPI driver interface layer and the SPI-NOR controller driver.
+
+ Unlike normal/generic spi controllers, they are few controllers which 
are
+ exclusively used to connect SPI-NOR devices, called SPI-NOR 
controllers.
+ So technically these controllers shouldn't reside at drivers/spi as 
these
+ may effect the generic SPI bus functionalities, so this SPI-NOR core 
acts
+ as a common core framework between the generic SPI controller drivers 
vs
+ SPI-NOR controller drivers for SPI-NOR device access. Note that from 
SPI-NOR
+ core to SPI drivers there should be an interface layer.
-- 
2.7.4

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

[U-Boot] [PATCH RFC v8 05/16] mtd: spi-nor: Kconfig: Add SPI_NOR_MISC entry

[Jagan Teki]

Added CONFIG_SPI_NOR_MISC kconfig entry

Signed-off-by: Jagan Teki 
---
 drivers/mtd/spi-nor/Kconfig | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/mtd/spi-nor/Kconfig b/drivers/mtd/spi-nor/Kconfig
index 40cd5ba..348709b 100644
--- a/drivers/mtd/spi-nor/Kconfig
+++ b/drivers/mtd/spi-nor/Kconfig
@@ -29,4 +29,10 @@ config MTD_SPI_NOR_USE_4K_SECTORS
  Please note that some tools/drivers/filesystems may not work with
  4096 B erase size (e.g. UBIFS requires 15 KiB as a minimum).
 
+config SPI_NOR_MISC
+   bool "Miscellaneous SPI NOR flash's support"
+   help
+ Add SPI-NOR support for various flash chips like Atmel, EON,
+ GigaDevice, and ISSI.
+
 endif # MTD_SPI_NOR
-- 
2.7.4

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

[U-Boot] [PATCH RFC v8 02/16] mtd: Add SPI-NOR core support

[Jagan Teki]

Some of the SPI device drivers at drivers/spi not a real
spi controllers, Unlike normal/generic SPI controllers they
operates only with SPI-NOR flash devices. these were technically
termed as SPI-NOR controllers, Ex: drivers/spi/fsl_qspi.c

The problem with these were resides at drivers/spi is entire
SPI layer becomes SPI-NOR flash oriented which is absolutely
a wrong indication where SPI layer getting effected more with
flash operations - So this SPI-NOR core will resolve this issue
by separating all SPI-NOR flash operations from spi layer and
creats a generic layer called SPI-NOR core which can be used to
interact SPI-NOR to SPI driver interface layer and the SPI-NOR
controller driver. The idea is taken from Linux spi-nor framework.

--
cmd_sf.c
--
mtd-uclass
---
SPI-NOR Core
---
m25p80.czynq_qspi
---
spi-uclass  SPI NOR chip
---
spi drivers
---
SPI NOR chip
---

Signed-off-by: Jagan Teki 
---
 Makefile  |   1 +
 drivers/mtd/spi-nor/Makefile  |   9 +
 drivers/mtd/spi-nor/spi-nor-ids.c | 176 +++
 drivers/mtd/spi-nor/spi-nor.c | 649 ++
 include/linux/err.h   |   5 +
 include/linux/mtd/spi-nor.h   | 207 
 6 files changed, 1047 insertions(+)
 create mode 100644 drivers/mtd/spi-nor/Makefile
 create mode 100644 drivers/mtd/spi-nor/spi-nor-ids.c
 create mode 100644 drivers/mtd/spi-nor/spi-nor.c
 create mode 100644 include/linux/mtd/spi-nor.h

diff --git a/Makefile b/Makefile
index c67cc99..6404b12 100644
--- a/Makefile
+++ b/Makefile
@@ -642,6 +642,7 @@ libs-$(CONFIG_CMD_NAND) += drivers/mtd/nand/
 libs-y += drivers/mtd/onenand/
 libs-$(CONFIG_CMD_UBI) += drivers/mtd/ubi/
 libs-y += drivers/mtd/spi/
+libs-y += drivers/mtd/spi-nor/
 libs-y += drivers/net/
 libs-y += drivers/net/phy/
 libs-y += drivers/pci/
diff --git a/drivers/mtd/spi-nor/Makefile b/drivers/mtd/spi-nor/Makefile
new file mode 100644
index 000..8675047
--- /dev/null
+++ b/drivers/mtd/spi-nor/Makefile
@@ -0,0 +1,9 @@
+#
+# Copyright (C) 2016 Jagan Teki 
+#
+# SPDX-License-Identifier: GPL-2.0+
+
+## spi-nor core
+ifdef CONFIG_MTD_SPI_NOR
+obj-y  += spi-nor.o spi-nor-ids.o
+endif
diff --git a/drivers/mtd/spi-nor/spi-nor-ids.c 
b/drivers/mtd/spi-nor/spi-nor-ids.c
new file mode 100644
index 000..7f26854
--- /dev/null
+++ b/drivers/mtd/spi-nor/spi-nor-ids.c
@@ -0,0 +1,176 @@
+/*
+ * SPI NOR IDs.
+ *
+ * Copyright (C) 2016 Jagan Teki 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+
+/* Used when the "_ext_id" is two bytes at most */
+#define INFO(_jedec_id, _ext_id, _sector_size, _n_sectors, _flags) \
+   .id = { \
+   ((_jedec_id) >> 16) & 0xff, \
+   ((_jedec_id) >> 8) & 0xff,  \
+   (_jedec_id) & 0xff, \
+   ((_ext_id) >> 8) & 0xff,\
+   (_ext_id) & 0xff,   \
+   },  \
+   .id_len = (!(_jedec_id) ? 0 : (3 + ((_ext_id) ? 2 : 0))),   
\
+   .sector_size = (_sector_size),  \
+   .n_sectors = (_n_sectors),  \
+   .page_size = 256,   \
+   .flags = (_flags),
+
+#define INFO6(_jedec_id, _ext_id, _sector_size, _n_sectors, _flags)\
+   .id = { \
+   ((_jedec_id) >> 16) & 0xff, \
+   ((_jedec_id) >> 8) & 0xff,  \
+   (_jedec_id) & 0xff, \
+   ((_ext_id) >> 16) & 0xff,   \
+   ((_ext_id) >> 8) & 0xff,\
+   (_ext_id) & 0xff,   \
+   },  \
+   .id_len = 6,\
+   .sector_size = (_sector_size),  \
+   .n_sectors = (_n_sectors),  \
+   .page_size = 256,   \
+   .flags = (_flags),
+
+const struct spi_nor_info spi_nor_ids[] = {
+#ifdef CONFIG_SPI_NOR_MACRONIX /* MACRONIX */
+   {"mx25l2006e", INFO(0xc22012, 0x0, 64 * 1024, 4, 0) },
+   {"mx25l4005", 

[U-Boot] [PATCH RFC v8 01/16] dm: mtd: Add dm mtd core ops

[Jagan Teki]

- Add generic dm_mtd operations
- Add mtd_read|erase|write_dm
- Add add_mtd_device_dm

The respetive MTD_UCLASS drivers must install the hooks to these
dm_mtd_ops and other core ops are act as a interface b/w drivers
vs command code.

Signed-off-by: Jagan Teki 
---
 drivers/mtd/mtd-uclass.c | 72 
 include/linux/mtd/mtd.h  | 58 ++
 2 files changed, 130 insertions(+)

diff --git a/drivers/mtd/mtd-uclass.c b/drivers/mtd/mtd-uclass.c
index 7b7c48e..b4ffd92 100644
--- a/drivers/mtd/mtd-uclass.c
+++ b/drivers/mtd/mtd-uclass.c
@@ -1,4 +1,5 @@
 /*
+ * Copyright (C) 2016 Jagan Teki 
  * Copyright (C) 2015 Thomas Chou 
  *
  * SPDX-License-Identifier:GPL-2.0+
@@ -8,6 +9,77 @@
 #include 
 #include 
 #include 
+#include 
+
+int mtd_read_dm(struct udevice *dev, loff_t from, size_t len, size_t *retlen,
+   u_char *buf)
+{
+   struct mtd_info *mtd = mtd_get_info(dev);
+
+   *retlen = 0;
+   if (from < 0 || from > mtd->size || len > mtd->size - from)
+   return -EINVAL;
+   if (!len)
+   return 0;
+
+   return mtd_get_ops(dev)->_read(dev, from, len, retlen, buf);
+}
+
+int mtd_erase_dm(struct udevice *dev, struct erase_info *instr)
+{
+   struct mtd_info *mtd = mtd_get_info(dev);
+
+   if (instr->addr > mtd->size || instr->len > mtd->size - instr->addr)
+   return -EINVAL;
+   if (!(mtd->flags & MTD_WRITEABLE))
+   return -EROFS;
+   instr->fail_addr = MTD_FAIL_ADDR_UNKNOWN;
+   if (!instr->len) {
+   instr->state = MTD_ERASE_DONE;
+   return 0;
+   }
+
+   return mtd_get_ops(dev)->_erase(dev, instr);
+}
+
+int mtd_write_dm(struct udevice *dev, loff_t to, size_t len, size_t *retlen,
+const u_char *buf)
+{
+   struct mtd_info *mtd = mtd_get_info(dev);
+
+   *retlen = 0;
+   if (to < 0 || to > mtd->size || len > mtd->size - to)
+   return -EINVAL;
+   if (!mtd->_write || !(mtd->flags & MTD_WRITEABLE))
+   return -EROFS;
+   if (!len)
+   return 0;
+
+   return mtd_get_ops(dev)->_write(dev, to, len, retlen, buf);
+}
+
+int add_mtd_device_dm(struct udevice *dev)
+{
+   struct mtd_info *mtd = mtd_get_info(dev);
+
+   BUG_ON(mtd->writesize == 0);
+   mtd->usecount = 0;
+
+   if (is_power_of_2(mtd->erasesize))
+   mtd->erasesize_shift = ffs(mtd->erasesize) - 1;
+   else
+   mtd->erasesize_shift = 0;
+
+   if (is_power_of_2(mtd->writesize))
+   mtd->writesize_shift = ffs(mtd->writesize) - 1;
+   else
+   mtd->writesize_shift = 0;
+
+   mtd->erasesize_mask = (1 << mtd->erasesize_shift) - 1;
+   mtd->writesize_mask = (1 << mtd->writesize_shift) - 1;
+
+   return 0;
+}
 
 /*
  * Implement a MTD uclass which should include most flash drivers.
diff --git a/include/linux/mtd/mtd.h b/include/linux/mtd/mtd.h
index 1fd17c3..1d22de1 100644
--- a/include/linux/mtd/mtd.h
+++ b/include/linux/mtd/mtd.h
@@ -506,4 +506,62 @@ void mtd_get_len_incl_bad(struct mtd_info *mtd, uint64_t 
offset,
  const uint64_t length, uint64_t *len_incl_bad,
  int *truncated);
 #endif
+
+#ifdef CONFIG_MTD
+
+struct dm_mtd_ops {
+   int (*_erase)(struct udevice *dev, struct erase_info *instr);
+   int (*_read)(struct udevice *dev, loff_t from, size_t len,
+size_t *retlen, u_char *buf);
+   int (*_write)(struct udevice *dev, loff_t to, size_t len,
+ size_t *retlen, const u_char *buf);
+};
+
+/* Access the serial operations for a device */
+#define mtd_get_ops(dev) ((struct dm_mtd_ops *)(dev)->driver->ops)
+
+/**
+ * mtd_read_dm() - Read data from MTD device
+ *
+ * @dev:   MTD device
+ * @from:  Offset into device in bytes to read from
+ * @len:   Length of bytes to read
+ * @retlen:Length of return bytes read to
+ * @buf:   Buffer to put the data that is read
+ * @return 0 if OK, -ve on error
+ */
+int mtd_read_dm(struct udevice *dev, loff_t from, size_t len, size_t *retlen,
+   u_char *buf);
+
+/**
+ * mtd_write_dm() - Write data to MTD device
+ *
+ * @dev:   MTD device
+ * @to:Offset into device in bytes to write to
+ * @len:   Length of bytes to write
+ * @retlen:Length of return bytes to write to
+ * @buf:   Buffer containing bytes to write
+ * @return 0 if OK, -ve on error
+ */
+int mtd_write_dm(struct udevice *dev, loff_t to, size_t len, size_t *retlen,
+const u_char *buf);
+
+/**
+ * mtd_erase_dm() - Erase blocks of the MTD device
+ *
+ * @dev:   MTD device
+ * @instr: Erase info details of MTD device
+ * @return 0 if OK, -ve on error
+ */
+int mtd_erase_dm(struct udevice *dev, struct erase_info *instr);
+
+/**
+ * add_mtd_device_dm() - 

[U-Boot] [PATCH RFC v8 00/16] SPI-NOR/MTD addition

[Jagan Teki]

On-top-of u-boot-spi/next,

The previous series [1] [2] are added SPI-NOR on top of
mtd/spi where it bypassing DM_SPI_FLASH and use the existing
mtd core (which is non-dm), I feel this is moving in a reverse
direction where adding new feature with the help of non-dm mtd
core support and also few of the spi drivers are not fully dm-driven.

So this new design will keep the mtd/spi as it is and start adding
spi-nor features separately. The idea here is to add the dm features
to MTD first and then add UCLASS_MTD spi-nor drivers so-that the commands
are interfacing to spi-nor through dm-driven MTD core to spi-nor.
And this could also be a generic solutions for all MTD flash's like NAND, NOR 
and etc.

About this series:

--
cmd_sf.c
--
mtd-uclass
---
SPI-NOR Core
---
m25p80.czynq_qspi
---
spi-uclass  SPI NOR chip
---
spi drivers
---
SPI NOR chip
---

drivers/mtd/spi-nor/

- Add dm mtd operations
- spi-nor.c:   Add basic SPI-NOR core like erase/read/write ops and lock's will 
add later
- m25p80.c:spi-nor to spi divers interface layer drivers/spi-nor
- zynq_qspi.c: zynq qspi spi-nor controller driver.

CONFIG_SPI_FLASH_BAR and DUAL_FLASH code shouldn't be part of spi-nor core
as these are strictly controller features. and 4-byte address width in spi-nor
will handle > 16MiB flash devices.

What need to be add:
1) 'sf probe' interface:
   Need to probe the chips in two directions A) one is for direct spi-nor driver
   (zynq_qspi here) and other B) one is for interface driver(m25p80.c). the 
later
   is bit tricky as it will also probe the UCLASS_SPI.

   A) 
   qspi1: spi@e000d000 {
compatible = "xlnx,zynq-qspi-1.0";
status = "disabled";
};

   
   B)
   spi0: spi@e0006000 {
compatible = "xlnx,zynq-spi-r1p6";
status = "disabled";
   };

   alias {
mtd0 = 
spi1 = 
   };

2) sf env:
   same as 1)

Any ideas about this probe interface are 'Welcome'

[1] http://lists.denx.de/pipermail/u-boot/2016-March/249286.html
[2] http://lists.denx.de/pipermail/u-boot/2016-February/245418.html

Jagan Teki (16):
  dm: mtd: Add dm mtd core ops
  mtd: Add SPI-NOR core support
  mtd: spi-nor: Kconfig: Add MTD_SPI_NOR entry
  mtd: spi-nor: Kconfig: Add MTD_SPI_NOR_USE_4K_SECTORS
  mtd: spi-nor: Kconfig: Add SPI_NOR_MISC entry
  mtd: spi-nor: Kconfig: Add SPI_NOR_MACRONIX entry
  mtd: spi-nor: Kconfig: Add SPI_NOR_SPANSION entry
  mtd: spi-nor: Kconfig: Add SPI_NOR_STMICRO entry
  mtd: spi-nor: Kconfig: Add SPI_NOR_SST entry
  mtd: spi-nor: Kconfig: Add SPI_NOR_WINBOND entry
  spi: Add spi_write_then_read
  mtd: spi-nor: Add m25p80 driver
  mtd: spi-nor: Kconfig: Add MTD_M25P80 entry
  mtd: spi-nor: Add zynq qspi driver
  mtd: spi-nor: zynq_qspi: Kconfig: Add MTD_ZYNQ
  mtd: spi-nor: Add 4-byte address width support

 Makefile  |   1 +
 drivers/mtd/Kconfig   |   2 +
 drivers/mtd/mtd-uclass.c  |  72 
 drivers/mtd/spi-nor/Kconfig   |  89 +
 drivers/mtd/spi-nor/Makefile  |  15 +
 drivers/mtd/spi-nor/m25p80.c  | 218 
 drivers/mtd/spi-nor/spi-nor-ids.c | 176 ++
 drivers/mtd/spi-nor/spi-nor.c | 685 ++
 drivers/mtd/spi-nor/zynq_qspi.c   | 638 +++
 drivers/spi/spi-uclass.c  |  24 ++
 include/linux/err.h   |   5 +
 include/linux/mtd/mtd.h   |  58 
 include/linux/mtd/spi-nor.h   | 211 
 include/spi.h |  20 ++
 14 files changed, 2214 insertions(+)
 create mode 100644 drivers/mtd/spi-nor/Kconfig
 create mode 100644 drivers/mtd/spi-nor/Makefile
 create mode 100644 drivers/mtd/spi-nor/m25p80.c
 create mode 100644 drivers/mtd/spi-nor/spi-nor-ids.c
 create mode 100644 drivers/mtd/spi-nor/spi-nor.c
 create mode 100644 drivers/mtd/spi-nor/zynq_qspi.c
 create mode 100644 include/linux/mtd/spi-nor.h

-- 
2.7.4

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

Re: [U-Boot] [PATCH v4 00/17] sf:Updates on flash detection

[Jagan Teki]

Hi Bin,

On Tue, Sep 27, 2016 at 12:52 PM, Bin Meng  wrote:
> Hi Jagan,
>
> On Mon, Sep 26, 2016 at 3:52 AM, Jagan Teki  wrote:
>> From: Jagan Teki 
>>
>> Updated spi_flash_info table in sync with Linux, and removed
>> legacy and unsupported code.
>>
>> Changes for v4:
>> - Rebase to master
>>
>> Changes for v3:
>> - New patches
>> - Fix checkpatch.pl
>> - Fix BIT positions in spi.h
>> - Fix ti_qspi.c mode
>> - Fix commit Nit: s/becuase/because
>>
>> Changes for v2:
>> - New patches.
>>
>> Testing:
>> $ git clone git://git.denx.de/u-boot-spi.git
>> $ cd u-boot-spi
>> $ git checkout -b next origin/next
>>
>
> I lost track of this series for some time. Is this the first series
> that are part of your spi-nor work? I remember I tested some of your
> series but I did not see my "Tested-by" here. Could you please share
> some info? I would like to have some test.

Actually this series not related to spi-nor work, I was ended some
issues on that design where it require to have MTD should be dm-driven
first. Currently I'm working on that, will add CC on to that work.

This series is to familiar with the flash detection code that
eventually used on spi-nor work.

thanks!
-- 
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/5] check-config: fix wrong comment about how to build whitelist

[Simon Glass]

On 26 September 2016 at 19:13, Masahiro Yamada
 wrote:
> Hi Simon,
>
> 2016-09-27 9:34 GMT+09:00 Simon Glass :
>> Hi Masahiro,
>>
>> On 25 September 2016 at 22:04, Masahiro Yamada
>>  wrote:
>>> The command suggested in this comment block is wrong; it would not
>>> rip off CONFIG options that had already been converted to Kconfig.
>>>
>>> Instead, we should use the scripts/build-whitelist.sh tool.
>>>
>>> Signed-off-by: Masahiro Yamada 
>>> ---
>>>
>>>  scripts/check-config.sh | 9 ++---
>>>  1 file changed, 2 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/scripts/check-config.sh b/scripts/check-config.sh
>>> index 28c8fe9..6618dfb 100755
>>> --- a/scripts/check-config.sh
>>> +++ b/scripts/check-config.sh
>>> @@ -5,13 +5,8 @@
>>>  # Check that the u-boot.cfg file provided does not introduce any new
>>>  # ad-hoc CONFIG options
>>>  #
>>> -# You can generate the list of current ad-hoc CONFIG options (those which 
>>> are
>>> -# not in Kconfig) with this command:
>>> -#
>>> -# export LC_ALL=C LC_COLLATE=C
>>> -# git grep CONFIG_ |tr ' \t' '\n\n' |sed -n 
>>> 's/^\(CONFIG_[A-Z0-9_]*\).*/\1/p' \
>>> -#  |sort |uniq >scripts/config_whitelist.txt;
>>> -# unset LC_ALL LC_COLLATE
>>> +# Use scripts/build-whitelist.sh to generate the list of current ad-hoc
>>> +# CONFIG options (those which are not in Kconfig).
>>
>> For me the LC setup is needed. Does it work correctly without it for
>> you? I found that the sorting was wrong.
>
>
> I am not quite sure about this, but it worked for me.
>
>
>
> I can see
>
> export LC_ALL=C
> export LC_COLLATE=C
>
> in both check-config.sh and build-whitelist.sh
>
>
> That's why?

OK thanks. I must have fixed it and forgotten about it.

Reviewed-by: Simon Glass 

BTW, what do you think about updating moveconfig.py to remove things
from the whitelist as well?

Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 11/12] RFC: Use binman for a sunxi board

[Simon Glass]

Hi Tom,

On 2 October 2016 at 21:26, Simon Glass  wrote:
> Hi Tom,
>
> On 1 October 2016 at 18:46, Tom Rini  wrote:
>> On Sat, Oct 01, 2016 at 06:29:42PM -0600, Simon Glass wrote:
>>> Hi Tom,
>>>
>>> On 1 October 2016 at 18:15, Tom Rini  wrote:
>>> > On Wed, Sep 28, 2016 at 09:46:25AM -0600, Simon Glass wrote:
>>> >> Hi Tom,
>>> >>
>>> >> On 27 September 2016 at 19:55, Tom Rini  wrote:
>>> >> > On Sun, Sep 25, 2016 at 03:52:27PM -0600, Simon Glass wrote:
>>> >> >
>>> >> >> Add an example usage of binman for a sunxi board. This involves 
>>> >> >> adding the
>>> >> >> image definition to the device tree and using it in the Makefile.
>>> >> >>
>>> >> >> This is for example only.
>>> >> >>
>>> >> >> Signed-off-by: Simon Glass 
>>> >> >> ---
>>> >> >>
>>> >> >> Changes in v2: None
>>> >> >>
>>> >> >>  Makefile|  4 +---
>>> >> >>  arch/arm/dts/sun7i-a20-pcduino3.dts | 12 
>>> >> >
>>> >> > I think this shows the big problem with using binman today.  For the
>>> >> > common case of ARM, where we sync in the dts* files from upstream, this
>>> >> > will add hunks that must not be overwritten each time.
>>> >> >
>>> >> > Looking at scripts/Makefile.lib::cmd_fdt I wonder if we couldn't come 
>>> >> > up
>>> >> > with some wildcard rule and check if, somewhere CONFIG'd ? $(BOARDDIR)/
>>> >> > ? u-boot.dtsi exists add in -include that/file.dtsi to the CPP rule so
>>> >> > that we can keep the parts that will never get upstream separate.
>>> >>
>>> >> We can do that, but I have found that most boards with the same SoC
>>> >> are the same, or similar. So for x86 [1] I put it in a separate patch
>>> >> with just an #include in the .dts file.
>>> >>
>>> >> We could have binman be a bit smarter about where it looks - e.g. if
>>> >> there is no binman node, it could look in the same directory for a
>>> >> file that matches the board name, or part of it?
>>> >
>>> > I'd really like to try and better solve the generic problem we have tho
>>> > too while we're at it.  ie the u-boot,dm-pre-reloc tag on various nodes
>>> > could also go into this file.
>>>
>>> What sort of solution are you thinking of? A U-Boot .dtsi include that
>>> is #included at the top of all files?
>>
>> Something like:
>> ifneq ($(wildcard 
>> $(srctree)/arch/$(CONFIG_SYS_ARCH)/cpu/$(CONFIG_SYS_CPU)/$(CONFIG_SYS_SOC)/u-boot.dtsi),)
>> dtc_cpp_flags += -include
>> $(srctree)/arch/$(CONFIG_SYS_ARCH)/cpu/$(CONFIG_SYS_CPU)/$(CONFIG_SYS_SOC)/u-boot.dtsi
>> endif
>>
>> And maybe a few other wildcards, I'm not sure, so that for everything
>> rockchip related, ie what binman needs, what nodes need to be pre-reloc,
>> etc, can end up in that one file.  And we use -include to get it so that
>> arch/arm/dts/ can be unmodified from upstream.
>
> OK, I was worried that's what you might mean :-)
>
> I'll take a look.

I've sent v3 with something along these lines. I could not use
-include because I need to avoid having the .dts version header appear
twice. So it has a little 'sed' in it...

Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCHv2 2/2] armv8/fsl-lsch3: consolidate the clock system initialization

[york sun]

On 09/26/2016 01:13 AM, Zhiqiang Hou wrote:
> From: Hou Zhiqiang 
>
> This patch map the sys_info->freq_systembus to Platform PLL, and
> implement the IPs' clock function individually.
>
> Signed-off-by: Hou Zhiqiang 
> ---
> V2:
>  - Generate the patch set base on the latest 
> git://git.denx.de/u-boot-fsl-qoriq.git.
>  - Add Platform clock and IPs' input clock divisors.
>
>  .../arm/cpu/armv8/fsl-layerscape/fsl_lsch3_speed.c | 31 
> --
>  arch/arm/include/asm/arch-fsl-layerscape/config.h  |  8 ++
>  .../include/asm/arch-fsl-layerscape/immap_lsch3.h  |  1 +
>  include/configs/ls2080a_common.h   |  2 +-
>  4 files changed, 33 insertions(+), 9 deletions(-)
>
> diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_speed.c 
> b/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_speed.c
> index a9b12a4..afc8a31 100644
> --- a/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_speed.c
> +++ b/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_speed.c
> @@ -88,11 +88,10 @@ void get_sys_info(struct sys_info *sys_info)
>  #endif
>  #endif
>
> + /* The freq_systembus is used to record frequency of platform PLL */
>   sys_info->freq_systembus *= (gur_in32(>rcwsr[0]) >>
>   FSL_CHASSIS3_RCWSR0_SYS_PLL_RAT_SHIFT) &
>   FSL_CHASSIS3_RCWSR0_SYS_PLL_RAT_MASK;
> - /* Platform clock is half of platform PLL */
> - sys_info->freq_systembus /= 2;
>   sys_info->freq_ddrbus *= (gur_in32(>rcwsr[0]) >>
>   FSL_CHASSIS3_RCWSR0_MEM_PLL_RAT_SHIFT) &
>   FSL_CHASSIS3_RCWSR0_MEM_PLL_RAT_MASK;
> @@ -132,7 +131,8 @@ void get_sys_info(struct sys_info *sys_info)
>   ccr = ifc_in32(_regs.gregs->ifc_ccr);
>   ccr = ((ccr & IFC_CCR_CLK_DIV_MASK) >> IFC_CCR_CLK_DIV_SHIFT) + 1;
>
> - sys_info->freq_localbus = sys_info->freq_systembus / ccr;
> + sys_info->freq_localbus = sys_info->freq_systembus /
> + CONFIG_SYS_FSL_PCLK_DIV / ccr;
>  #endif
>  }
>

Zhiqiang and Prabhakar,

Your patches collide with each other. Can you two work together to sort 
it out?

http://patchwork.ozlabs.org/patch/666849/

York

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

Re: [U-Boot] [PATCH 0/9] Switch bcm283x platform to use OF_CONTROL

[Simon Glass]

+Tom too

On 5 October 2016 at 10:48, Fabian Vogt  wrote:
> Hi,
>
> Am Mittwoch, 5. Oktober 2016, 09:54:46 CEST schrieb Stephen Warren:
>> On 09/26/2016 06:26 AM, Fabian Vogt wrote:
>> > This patch series modifies the used drivers to work with OF_CONTROL
>> > and switches the board code and configs to use it.
>> > The added device trees are directly from the linux kernel tree
>> > and can thus be used for booting the (upstream) kernel.
>>
>> Is there a user-visible or developer-visible benefit to this change? In
>> general, converting to use DT to instantiate devices simply ends up
>> using more code (and hence complexity and time) to get to the exact same
>> state afterwards.
>
> There are various reasons, like:
>
> - The device tree describes the platform, so it can also be used by the
>   linux kernel for configuration (no separate dtb needed)
> - Properties are not hardcoded in the u-boot code
> - Slightly different hardware deviations do not require significant code
>   changes (like #ifdef or even new platdatas), just a new dts and Kconfig
>   adjustments
>
> It's also mentioned in Simon Glass's talk about DM:
> https://events.linuxfoundation.org/sites/events/files/slides/Order%20at%20last%20-%20U-Boot%20driver%20model%20slides%20(2).pdf
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 08/10] binman: Automatically include a U-Boot .dtsi file

[Simon Glass]

Hi Masahiro,

On 4 October 2016 at 21:51, Masahiro Yamada
 wrote:
>
> 2016-10-05 9:25 GMT+09:00 Simon Glass :
> > For boards that need U-Boot-specific additions to the device tree, it is
> > a minor annoyance to have to add these each time the tree is synced with
> > upstream.
> >
> > Add a means to include a file (e.g. u-boot.dtsi) automatically into the .dts
> > file before it is compiled.
> >
> > The file uses is the first one that exists in this list:
> >
> >arch//dts/-u-boot.dtsi
> >arch//dts/-u-boot.dtsi
> >arch//dts/-u-boot.dtsi
> >arch//dts/u-boot.dtsi
> >
> > Signed-off-by: Simon Glass 
> > Suggested-by: Tom Rini 
> > ---
> >
> > Changes in v3:
> > - Add a new patch to automatically include a U-Boot .dtsi file
> >
> > Changes in v2: None
> >
> >  scripts/Makefile.lib | 15 ++-
> >  1 file changed, 14 insertions(+), 1 deletion(-)
> >
> > diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
> > index 2539ba5..b414a0c 100644
> > --- a/scripts/Makefile.lib
> > +++ b/scripts/Makefile.lib
> > @@ -164,6 +164,17 @@ cpp_flags  = -Wp,-MD,$(depfile) $(NOSTDINC_FLAGS) 
> > $(UBOOTINCLUDE) \
> >
> >  ld_flags   = $(LDFLAGS) $(ldflags-y)
> >
> > +dts_dir = $(srctree)/arch/$(ARCH)/dts
> > +
> > +# Try these files in order to find the U-Boot-specific .dtsi include file
> > +binman_dtsi_options = $(wildcard $(dts_dir)/$(basename $(notdir 
> > $<))-u-boot.dtsi) \
> > +   $(wildcard $(dts_dir)/$(subst $\",,$(CONFIG_SYS_CPU))-u-boot.dtsi) \
> > +   $(wildcard $(dts_dir)/$(subst 
> > $\",,$(CONFIG_SYS_VENDOR))-u-boot.dtsi) \
> > +   $(wildcard $(dts_dir)/u-boot.dtsi)
> > +
> > +# We use the first match
> > +binman_dtsi = $(firstword $(binman_dtsi_options))
> > +
>
>
> I do not think this feature is binman-specific.
>
> Perhaps u_boot_dtsi?
>
> We are already suffering from U-Boot specific properties like
> "u-boot,dm-pre-reloc", which make it difficult to
> simply copy DT files from the kernel tree.
> So, my first guess was this feature might be useful
> to split such properties out to *-u-boot.dtsi.
> (it is a trade-off of more and more DT files, though.)

Yes that was Tom's intent. True, it is not binman-specific and I'm
happy to change the variable, but let's see if this solves the problem
first.

Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 1/3] net: fec_mxc: Convert into driver model

[Simon Glass]

Hi,

On 2 October 2016 at 06:34, Jagan Teki  wrote:
> From: Jagan Teki 
>
> This patch add driver model support for fec_mxc driver.
>
> Cc: Simon Glass 
> Cc: Joe Hershberger 
> Cc: Peng Fan 
> Cc: Stefano Babic 
> Cc: Michael Trimarchi 
> Signed-off-by: Jagan Teki 
> ---
>  drivers/net/fec_mxc.c | 273 
> +-
>  drivers/net/fec_mxc.h |  11 ++
>  2 files changed, 258 insertions(+), 26 deletions(-)

I think you would have an easier time if you move all the common code
into common functions, and just have stubs for the legacy and new DM
path. For example fecmxc_probe() is repeating code. There really
should be almost no duplicated code in the driver. It just makes it
hard to maintain, and understand what is happening.

I think it is best to avoid renaming the functions. So for example:

#ifdef CONFIG_DM_ETH
static int fecmxc_recv(struct udevice *dev, int flags, uchar **packetp)
#else
static int fec_recv(struct eth_device *dev)
#endif
{

You may as well keep the name the same - fec_recv().

In one case you have not put the DM_ETH case first. It should be:

#ifdef CONFIG_DM_ETH
...
#else
#endif

rather than:

#ifndef CONFIG_DM_ETH
...
#else
#endif

I'm not sure you are dealing with all the cases. Unfortunately the
driver already has #idefs. For example if CONFIG_PHYLIB is not
defined. With CONFIG_DM_ETH, struct eth_device will not be available,
so you need to make sure no code builds with that.

Also fecmxc_recv() does not appear to work. It needs to set packetp
and return a packet length. Also, do you need a free_pkt()?

Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] SPL load ARM Trusted Firmware BL31?

[Simon Glass]

Hi,

On 5 October 2016 at 08:39, Michal Simek  wrote:
> Hi Masahiro,
>
> 2016-10-04 20:19 GMT-07:00 Masahiro Yamada :
>
>> Hi.
>>
>> Recently I implemented ARM Trusted Firmware BL31 for my SoCs.
>>
>> But, I am wondering how the boot-flow should be.
>>
>>
>>
>> Here is my situation.
>>
>>
>> [1]
>> When my company developed its first ARMv8 SoC,
>> I had to bring up the system very quickly.
>>
>> I was familiar with U-Boot and Linux to some extent, but not with ATF
>> at that time.
>> Also I was too pressed, so I decided to build up the system without ATF.
>>
>> The boot-flow was like this:
>>
>>   BootROM  ->  U-Boot SPL  -> U-Boot proper -> Linux
>>
>> In this flow, the secure runtime firmware is missing,
>> so I used Spin-Table for the enable-method.
>>
>>
>> [2]
>> Now I finished porting ATF BL31.
>> The low-level init code (basic SoC init + DRAM initialization)
>> already exists in U-Boot SPL.
>> So, I am currently re-using SPL, like follows:
>>
>>  BootROM ->  U-Boot SPL  -> ATF BL31 -> U-Boot proper (=BL33) -> Linux
>>
>>
>> As far as I know, SPL can not load multiple images such as BL31, BL32, BL33
>> (here BL32 is optional).
>> So, I hacked my SPL to load multi images
>> and jump to BL31.
>>
>
> this is not entirely truth. If you look at zynqmp you will find out that if
> you
> work with atf as kernel and full u-boot as dtb then u-boot SPL can load two
> images.
> This is what I use. It is a trick but I am not using any changes to get it
> work.
>
>
>
>
>>
>>
>>
>>
>> [3]
>> I am guessing most vendors use vendor-specific firmware for low-level init
>> because I see many of ARMv8 SoCs disabling CONFIG_SPL.  Correct?
>>
>
> I do use SPL exactly how as used without ATF. It means low level init is
> done in SPL in EL3.
>
>
>>
>>  Boot ROM  ->  Vendor proprietary firmware -> ATF BL31  ->  U-Boot or
>> UEFI (=BL33) -> Linux
>>
>>
>>
>>
>> [4]
>> Is it a good idea to implement everything in ATF like Juno/FVP?
>>
>>  BL1 -> BL2 -> BL31 -> U-Boot or UEFI (BL33) -> Linux
>>
>
> We are using only BL31 and nothing else.
>
>
>>
>>
>>
>>
>>
>> Recently I saw Simon's binman patches.
>> It provides a fancy way to pack multiple firmware components into a
>> single image,
>> but I did not see the systematic way to load every entry in the image.
>>   (under way?)
>>
>>
>> I was wondering if I should move my low-level init code
>> from SPL to ATF BL2 or somewhere.
>>
>> Comments are welcome.
>>
>
> I use bootrom -> SPL -> ATF -> full u-boot.
>
> I want to use SPL because we have all device drivers in u-boot and
> in ATF we have only serial driver. If you want to use BL2 just for low
> level init stuff
> you can but it is the question if this brings you any value.
>
> Anyway check zynqmp. It is not perfect solution but it is at least temporary
> solution for just this case.
> FIT image has an option to add more images with load address and I think
> this is a support
> we should support in SPL. (doc/uImage.FIT/multi-with-loadables.its)
> Also there will be probably need to mark images with EL level this targets.

I have not got into this yet. But I'm really keen on SPL being the
first thing that runs, and it calling into ATF bits as needed. This
allows verified boot to work correctly, since we can add signatures to
the images, etc. It also is easier to follow IMO.

Long term, I am wondering if ATF could be a library instead of a
separate binary? Or perhaps it could be build so that it can be linked
against.

Binman aims to make it easier to create these images with 4-5 separate
binaries. At some point I'm going to look at ATF in a bit more detail.

Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2] power: regulator: Add support for gpio regulators

[Simon Glass]

Hi Keerthy,

On 5 October 2016 at 05:58, Keerthy  wrote:
>
>
> On Monday 19 September 2016 06:29 AM, Simon Glass wrote:
>>
>> On 15 September 2016 at 05:34, Keerthy  wrote:
>>>
>>> Add support for gpio regulators. As of now this driver caters
>>> to gpio regulators with one gpio. Supports setting voltage values to gpio
>>> regulators and retrieving the values.
>>>
>>> Signed-off-by: Keerthy 
>>> ---
>>>
>>> Changes in v2:
>>>
>>>   * Added states and voltages as part of plat data to have
>>> a generic state to voltage mapping removing any assumptions.
>>>
>>>  drivers/power/regulator/Kconfig  |   8 ++
>>>  drivers/power/regulator/Makefile |   1 +
>>>  drivers/power/regulator/gpio-regulator.c | 137
>>> +++
>>>  include/power/regulator.h|   1 +
>>>  4 files changed, 147 insertions(+)
>>>  create mode 100644 drivers/power/regulator/gpio-regulator.c
>>
>>
>> Reviewed-by: Simon Glass 
>
>
> Simon,
>
> Wanted to know who is pulling this patch.

Looking in patchwork it is assigned to Przemyslaw.

Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 8/8] armv7: ls1021a: Move DDR config options to Kconfig

[Simon Glass]

Hi York,

On 4 October 2016 at 19:04, York Sun  wrote:
> Move DDR3, DDR4 and related config options to Kconfig and clean up
> existing uses.
>
> Signed-off-by: York Sun 
>
> ---
>
> Changes in v2:
>   No patch
>
>  arch/arm/cpu/armv7/ls102xa/Kconfig   | 47 
> 
>  arch/arm/include/asm/arch-ls102xa/config.h   | 10 --
>  configs/ls1021aqds_ddr4_nor_defconfig|  2 +-
>  configs/ls1021aqds_ddr4_nor_lpuart_defconfig |  3 +-
>  configs/ls1021aqds_nand_defconfig|  1 +
>  configs/ls1021aqds_nor_SECURE_BOOT_defconfig |  1 +
>  configs/ls1021aqds_nor_defconfig |  1 +
>  configs/ls1021aqds_nor_lpuart_defconfig  |  1 +
>  configs/ls1021aqds_qspi_defconfig|  1 +
>  configs/ls1021aqds_sdcard_ifc_defconfig  |  1 +
>  configs/ls1021aqds_sdcard_qspi_defconfig |  1 +
>  include/configs/ls1021aqds.h |  1 -
>  12 files changed, 57 insertions(+), 13 deletions(-)

Reviewed-by: Simon Glass 

You should be able to remove these from scripts/config_whitelist.txt as well.

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

Re: [U-Boot] [PATCH v2 7/8] armv8: fsl-layerscape: Move DDR config options to Kconfig

[Simon Glass]

On 4 October 2016 at 19:03, York Sun  wrote:
>
> Move DDR3, DDR4 and realted options to Kconfig and clean up existing
> uses.
>
> Signed-off-by: York Sun 
>
> ---
>
> Changes in v2:
>   No patch
>
>  arch/arm/cpu/armv8/fsl-layerscape/Kconfig | 54 
> +++
>  arch/arm/include/asm/arch-fsl-layerscape/config.h | 14 --
>  configs/ls1043aqds_defconfig  |  2 +-
>  configs/ls1043aqds_lpuart_defconfig   |  3 +-
>  configs/ls1043aqds_nand_defconfig |  3 +-
>  configs/ls1043aqds_nor_ddr3_defconfig |  1 +
>  configs/ls1043aqds_qspi_defconfig |  3 +-
>  configs/ls1043aqds_sdcard_ifc_defconfig   |  3 +-
>  configs/ls1043aqds_sdcard_qspi_defconfig  |  3 +-
>  configs/ls1043ardb_SECURE_BOOT_defconfig  |  3 +-
>  configs/ls1043ardb_defconfig  |  2 +-
>  configs/ls1043ardb_nand_defconfig |  3 +-
>  configs/ls1043ardb_sdcard_defconfig   |  3 +-
>  include/configs/ls1043a_common.h  |  4 --
>  include/configs/ls1043aqds.h  |  3 --
>  include/configs/ls2080a_common.h  |  1 -
>  16 files changed, 73 insertions(+), 32 deletions(-)


Reviewed-by: Simon Glass 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 0/9] Switch bcm283x platform to use OF_CONTROL

[Fabian Vogt]

Hi,

Am Mittwoch, 5. Oktober 2016, 09:54:46 CEST schrieb Stephen Warren:
> On 09/26/2016 06:26 AM, Fabian Vogt wrote:
> > This patch series modifies the used drivers to work with OF_CONTROL
> > and switches the board code and configs to use it.
> > The added device trees are directly from the linux kernel tree
> > and can thus be used for booting the (upstream) kernel.
> 
> Is there a user-visible or developer-visible benefit to this change? In 
> general, converting to use DT to instantiate devices simply ends up 
> using more code (and hence complexity and time) to get to the exact same 
> state afterwards.

There are various reasons, like:

- The device tree describes the platform, so it can also be used by the
  linux kernel for configuration (no separate dtb needed)
- Properties are not hardcoded in the u-boot code
- Slightly different hardware deviations do not require significant code
  changes (like #ifdef or even new platdatas), just a new dts and Kconfig
  adjustments

It's also mentioned in Simon Glass's talk about DM:
https://events.linuxfoundation.org/sites/events/files/slides/Order%20at%20last%20-%20U-Boot%20driver%20model%20slides%20(2).pdf


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

Re: [U-Boot] [PATCH] arm: ls102xa: Remove reduplicate definition for Generic Timer frequency

[york sun]

On 09/23/2016 01:15 AM, Alison Wang wrote:
> GENERIC_TIMER_CLK and CONFIG_TIMER_CLK_FREQ are both used to define
> Generic Timer frequency. It is reduplicate. This patch will remove
> GENERIC_TIMER_CLK macro.
>
> Signed-off-by: Alison Wang 
> ---
>  arch/arm/cpu/armv7/ls102xa/psci.S  | 2 +-
>  arch/arm/cpu/armv7/ls102xa/timer.c | 2 +-
>  include/configs/ls1021aqds.h   | 5 -
>  include/configs/ls1021atwr.h   | 5 -
>  4 files changed, 2 insertions(+), 12 deletions(-)
>
> diff --git a/arch/arm/cpu/armv7/ls102xa/psci.S 
> b/arch/arm/cpu/armv7/ls102xa/psci.S
> index 8f38680..9efb6d8 100644
> --- a/arch/arm/cpu/armv7/ls102xa/psci.S
> +++ b/arch/arm/cpu/armv7/ls102xa/psci.S
> @@ -36,7 +36,7 @@
>
>   .align  5
>
> -#define  ONE_MS  (GENERIC_TIMER_CLK / 1000)
> +#define  ONE_MS  (CONFIG_TIMER_CLK_FREQ / 1000)
>  #define  RESET_WAIT  (30 * ONE_MS)
>

Alison,

Can you use GENERIC_TIMER_CLK? Recent change in U-Boot doesn't favor 
using CONFIG_* macros.

York

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

Re: [U-Boot] [PATCH v2 2/6] apalis/colibri_t20/t30: deactivate displaying board info

[Stefan Agner]

On 2016-10-05 08:53, Stephen Warren wrote:
> On 10/03/2016 02:27 PM, Stefan Agner wrote:
>> On 03.10.2016 10:28, Stephen Warren wrote:
>>> On 09/30/2016 04:00 AM, Marcel Ziswiler wrote:
 On Wed, 2016-09-28 at 12:00 -0600, Stephen Warren wrote:
> On 09/28/2016 03:35 AM, Marcel Ziswiler wrote:
>>
>> Avoid a checkboard() name clash with our upcoming custom
>> implementation
>> thereof.
> If you want to avoid naming conflicts, please simply name your new
> function something that doesn't conflict. That way it will avoid
> confusion is someone actually wants to enable the
> CONFIG_DISPLAY_BOARDINFO option themselves, plus it avoids taking
> the
> current feature set away.

 No, it is not just any function. We do want our custom checkboard() to
 be called upon boot and not the Tegra generic one just printing a hard
 coded string.

 I guess alternatively we could gate the checkboard() call
 in arch/arm/mach-tegra/board2.c with a

 #if !defined(CONFIG_CUSTOM_BOARDINFO)

 just as introduced a while ago in common/board_info.c

 http://git.denx.de/?p=u-boot.git;a=blob;f=common/board_info.c;h=bd5dcfa
 066358c2cc44ce5d19fcc3e77d555cd09;hb=HEAD#l20

 in order to not print the hard coded name from the device tree.
>>>
>>> I'd prefer to keep the behaviour standard across all Tegra boards. If
>>> you want to do additional actions in the checkboard() function, I
>>> suggest making it call an optional additional function:
>>>
>>> __weak int tegra_checkboard(void)
>>> {
>>> return 0;
>>> }
>>>
>>> int checkboard(void)
>>> {
>>> ...
>>> return tegra_checkboard();
>>> }
>>
>> Well that would print a message "Board: " ... twice, which is rather
>> strange.
> 
> Surely you simply make tegra_checkboard() not contain duplicate code?
> 
>> What do you think of my idea?
> 
> I'd rather not introduce any more ifdefs, but instead have a single
> path through the code-base.

Sorry, I was a bit unclear, with my other idea I meant the answer I sent
to patch 3/6 of this patchset:
http://lists.denx.de/pipermail/u-boot/2016-October/268669.html

It does remove a ifdef...

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

Re: [U-Boot] [PATCH] libfdt: replace ARCH_FIXUP_FDT with ARCH_FIXUP_FDT_MEMORY

[Simon Glass]

Hi Masahiro,

On 4 October 2016 at 21:27, Masahiro Yamada
 wrote:
> Hi Simon,
>
> 2016-10-05 0:37 GMT+09:00 Simon Glass :
>
>>> diff --git a/common/image-fdt.c b/common/image-fdt.c
>>> index 3d23608..91970d4 100644
>>> --- a/common/image-fdt.c
>>> +++ b/common/image-fdt.c
>>> @@ -458,6 +458,11 @@ __weak int ft_verify_fdt(void *fdt)
>>> return 1;
>>>  }
>>>
>>> +__weak int arch_fixup_fdt(void *blob)
>>> +{
>>> +   return 0;
>>> +}
>>
>> Do we have to have a weak function? I was hoping we could avoid these
>> since they make it hard to figure out at build time what code is
>> executed.
>>
>
>
> This hunk is just reverting Michal's commit e2f88dfd2d9671.
>
> Is it better to add an empty stub to every architecture that may call it?

IMO all the FDT fixups need work. Perhaps we need a linker list
approach so we can declare these fixups more easily? Or perhaps that
will just make things harder to figure out?

But in this case I'm keen to avoid going back to using a weak
function. Can we do that?

Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot