Re: [U-Boot] [PATCH v2 11/11] riscv: Add SiFive FU540 board support

2019-02-02 Thread Anup Patel
On Thu, Jan 24, 2019 at 7:27 PM Andreas Schwab  wrote:
>
> On Jan 24 2019, Alexander Graf  wrote:
>
> > On 24.01.19 14:38, Andreas Schwab wrote:
> >> On Jan 24 2019, Alexander Graf  wrote:
> >>
> >>> Board_init() is too late. This needs to go into early_board_init_f().
> >>
> >> I don't think we can modify the DT that early.
> >
> > I'm sure we can. Worst case we have to copy it over to RAM first.
>
> reserve_fdt is only called much later.

OpenSBI is public now.

Can try with https://github.com/riscv/opensbi.git ?

There is README for SiFive FU540 at
/docs/platform/sifive_fu540.md

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


Re: [U-Boot] [U-Boot, 3/5] tools: dumpimage: Simplify internal logic

2019-02-02 Thread Tom Rini
On Sat, Jan 26, 2019 at 02:31:52AM +, Martyn Welch wrote:

> There are 3 supported modes of operation:
> 
> 1) Show version
> 2) List image contents
> 3) Extract image component
> 
> Option (1) terminates early, so only options (2) and (3) remain. Remove
> redundant check for these modes.
> 
> Signed-off-by: Martyn Welch 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot,5/5] tools: dumpimage: Clarify help

2019-02-02 Thread Tom Rini
On Sat, Jan 26, 2019 at 02:31:54AM +, Martyn Welch wrote:

> Help message isn't clear over the use of the "-T" option (it's to declare
> the type of image that the tool is operating on), which also is optional
> as it defaults to the default image type. It's also missing a description
> of the "-o" option, so add it.
> 
> Signed-off-by: Martyn Welch 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [PATCH 1/3] configs: am65x_evm_r5: Enable GPT support

2019-02-02 Thread Tom Rini
On Fri, Feb 01, 2019 at 03:04:56PM -0600, Andrew F. Davis wrote:

> The second loader stages may be stored on GPT partitions,
> enable support for this here.
> 
> Signed-off-by: Andrew F. Davis 

Reviewed-by: Tom Rini 

-- 
Tom


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


Re: [U-Boot] [U-Boot, 4/5] tools: dumpimage: Add help option and make error paths consistent

2019-02-02 Thread Tom Rini
On Sat, Jan 26, 2019 at 02:31:53AM +, Martyn Welch wrote:

> The utility dumpimage has error paths that display the usage and others
> that exit without displaying usage. Add an explicit help option to
> dumpimage to display the usage and remove it's use in error paths to make
> the error messages more obvious and errors paths more consistent.
> 
> Signed-off-by: Martyn Welch 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [PULL] u-boot-mips

2019-02-02 Thread Tom Rini
On Fri, Feb 01, 2019 at 06:38:53PM +0100, Daniel Schwierzeck wrote:

> Hi Tom,
> 
> please pull some updates and fixes for MIPS
> 
> https://travis-ci.org/danielschwierzeck/u-boot/builds/487434845
> 
> 
> The following changes since commit ab0ec15f77b5692c06fac024f34a90ab4752b41a:
> 
>   Merge tag 'u-boot-amlogic-20190131' of git://git.denx.de/u-boot-amlogic 
> (2019-01-31 07:19:52 -0500)
> 
> are available in the Git repository at:
> 
>   git://git.denx.de/u-boot-mips.git tags/mips-pull-2019-02-01
> 
> for you to fetch changes up to 364e407f3cafd485db4d090430e3861c99858d42:
> 
>   configs: mscc_luton: Add network support. (2019-02-01 14:13:36 +0100)
> 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot,2/5] tools: dumpimage: Simplify arguments

2019-02-02 Thread Tom Rini
On Sat, Jan 26, 2019 at 02:31:51AM +, Martyn Welch wrote:

> The dump image utility has very confusing syntax. If called to list image
> contents ("-l") it takes the image name as a positional argument. If the
> utility is called to extract something from the image, the image must be
> provided via the optional argument "-i" as well as the positional argument
> but the value passed in the positional argument will be completely
> ignored.
> 
> Simplify dumpimage by always providing the image as the first positional
> argument. Assume we want to dump something from the image if we do not
> provide the "-l" option for now.
> 
> Signed-off-by: Martyn Welch 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot, v1, 1/3] ARM: DTS: am43xx: Add aliases for the USB ports

2019-02-02 Thread Tom Rini
On Thu, Jan 24, 2019 at 03:42:51PM +0100, Jean-Jacques Hiblot wrote:

> Although not required, it doesn't hurt to explicitly map the USB ports to
> a USB controller. Without this, the port number will be derived from the
> binding order of the peripheral devices.
> 
> Signed-off-by: Jean-Jacques Hiblot 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [PATCH v2 2/2] test: lib: lmb: add lmb test for multiple RAM banks

2019-02-02 Thread Tom Rini
On Fri, Feb 01, 2019 at 09:23:59PM +0100, Simon Goldschmidt wrote:

> This adds one test case that checks that allocation with multiple
> DRAM banks works correctly.
> 
> Signed-off-by: Simon Goldschmidt 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [PULL] Please pull u-boot-rockchip:tags/for-master-20190201

2019-02-02 Thread Tom Rini
On Fri, Feb 01, 2019 at 06:15:20PM +0100, Philipp Tomsich wrote:

> Tom,
> 
> I am a little late this time with our changes for rc1.  Hope this doesn’t 
> impact your workflow too much.
> Things got a bit messy this time, as some of the series introduced unexpected 
> isses during testing
> (such as the debug UART not being available).
> 
> Travis is still running 
> (https://travis-ci.org/ptomsich/u-boot-rockchip/builds/487509207) on the 
> rebased
> version, but prior to the rebase (and the final fixes), things were testing 
> out correctly.
> 
> Thanks,
> Philipp. 
> 
> 
> The following changes since commit db4a29993d207fec33c07de8b8cb8a3fd22c9e6c:
> 
>   Merge tag 'video-updates-for-2019.04-rc1' of git://git.denx.de/u-boot-video 
> (2019-01-31 16:07:37 -0500)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-rockchip tags/for-master-20190201
> 
> for you to fetch changes up to 73ced87e9af70cba35c4374055dca56e5f9c460d:
> 
>   rockchip: rk3399: spl: ensure that debug_uart_init is called (2019-02-01 
> 16:59:14 +0100)
> 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot, v2, 1/4] spl: Kconfig: Replace CONFIG_SPL_FAT_SUPPORT with CONFIG_SPL_FS_FAT

2019-02-02 Thread Tom Rini
On Wed, Jan 23, 2019 at 02:20:03PM +0800, tien.fong.c...@intel.com wrote:

> From: Tien Fong Chee 
> 
> Replace CONFIG_SPL_FAT_SUPPORT with CONFIG_SPL_FS_FAT so
> obj-$(CONFIG_$(SPL_)FS_FAT) can be used to control the build in both
> SPL and U-Boot.
> 
> Signed-off-by: Tien Fong Chee 
> Reviewed-by: Simon Goldschmidt 
> Reviewed-by: Tom Rini 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [PATCH 2/3] am65x_evm: Allow bootm to load larger kernels

2019-02-02 Thread Tom Rini
On Fri, Feb 01, 2019 at 03:04:57PM -0600, Andrew F. Davis wrote:

> Bootm will fail to load kernels over 8MB, this is not enough
> for our 64bit kernel images. Increase this to 64MB.
> 
> Signed-off-by: Andrew F. Davis 

Reviewed-by: Tom Rini 

-- 
Tom


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


Re: [U-Boot] [U-Boot, v2, 2/4] spl: fat/fs: Add option to include/exclude FAT write build in SPL

2019-02-02 Thread Tom Rini
On Wed, Jan 23, 2019 at 02:20:04PM +0800, tien.fong.c...@intel.com wrote:

> From: Tien Fong Chee 
> 
> Most of the time SPL only needs very simple FAT reading, so having
> CONFIG_IS_ENABLED(FAT_WRITE) to exclude it from SPL build would help
> to save 64KiB default max clustersize from memory.
> 
> Signed-off-by: Tien Fong Chee 
> Reviewed-by: Simon Goldschmidt 
> Reviewed-by: Tom Rini 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [PATCH 3/3] armv7R: K3: am654: Fix order of debug elements in x509 template

2019-02-02 Thread Tom Rini
On Fri, Feb 01, 2019 at 03:04:58PM -0600, Andrew F. Davis wrote:

> The first element in the debug section is expected to be debugUID.
> ROM will not parse this correctly when out of order, fix this here.
> 
> Signed-off-by: Andrew F. Davis 

Reviewed-by: Tom Rini 

-- 
Tom


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


Re: [U-Boot] [U-Boot, 1/5] tools: dumpimage: Provide more feedback on error

2019-02-02 Thread Tom Rini
On Sat, Jan 26, 2019 at 02:31:50AM +, Martyn Welch wrote:

> The dumpimage utility errors out in a number of places without providing
> sufficient feedback to allow the user to easily determine what they have
> done wrong. Add addtional error messages to make the cause of the failure
> more obvious.
> 
> Signed-off-by: Martyn Welch 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot, v2, 3/4] spl: Kconfig: Replace CONFIG_SPL_EXT_SUPPORT to CONFIG_SPL_FS_EXT4

2019-02-02 Thread Tom Rini
On Wed, Jan 23, 2019 at 02:20:05PM +0800, tien.fong.c...@intel.com wrote:

> From: Tien Fong Chee 
> 
> Replace CONFIG_SPL_EXT_SUPPORT to CONFIG_SPLY_FS_EXT4 so both
> obj-$(CONFIG_$(SPL_)FS_EXT4) and CONFIG_IS_ENABLED(FS_EXT4) can be
> used to control the build in both SPL and U-Boot.
> 
> Signed-off-by: Tien Fong Chee 
> Reviewed-by: Tom Rini 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] lmb: handle more than one DRAM BANK

2019-02-02 Thread Tom Rini
On Sat, Jan 26, 2019 at 10:13:04PM +0100, Simon Goldschmidt wrote:

> This fixes the automatic lmb initialization and reservation for boards
> with more than one DRAM bank.
> 
> This fixes the CVE-2018-18439 and -18440 fixes that only allowed to load
> files into the firs DRAM bank from fs and via tftp.
> 
> Found-by: Heinrich Schuchardt 
> Signed-off-by: Simon Goldschmidt 
> Tested-by: Heinrich Schuchardt 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot, v2, 4/4] spl: fat/fs: Add control to build FS EXT4 in SPL

2019-02-02 Thread Tom Rini
On Wed, Jan 23, 2019 at 02:20:06PM +0800, tien.fong.c...@intel.com wrote:

> From: Tien Fong Chee 
> 
> CONFIG_SPL_FS_EXT4 can be used to include/exclude the FS EXT4 from
> SPL build. Excluding the FS EXT4 from SPL build can help to save 20KiB
> memory.
> 
> Signed-off-by: Tien Fong Chee 
> Reviewed-by: Tom Rini 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] regulator: pbias: Handle extended drain IO when changing omap36 PBIAS

2019-02-02 Thread Tom Rini
On Thu, Jan 24, 2019 at 02:33:36PM -0600, Adam Ford wrote:

> The OMAP36 and DM37 TRM state to disable extneded drain IO before
> changing the PBIAS.  This patch does this before pmic writes if
> the CONFIG_MMC_OMAP36XX_PINS flag is set and the cpu family is
> omap36xx
> 
> Signed-off-by: Adam Ford 
> 
> diff --git a/drivers/power/regulator/pbias_regulator.c 
> b/drivers/power/regulator/pbias_regulator.c
> index 366f97b38b..4ed3c94e03 100644

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot, v1, 4/4] configs: removing am335x_evm_usbspl_defconfig

2019-02-02 Thread Tom Rini
On Tue, Jan 22, 2019 at 04:48:19PM +0100, Jean-Jacques Hiblot wrote:

> This feature is now supported by the main config for am335x_evm:
> am335x_evm_defconfig
> 
> Signed-off-by: Jean-Jacques Hiblot 
> Reviewed-by: Tom Rini 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot, v1, 2/3] ARM: DTS: am43xx: Enable the DTS entries for USB port #2 in SPL

2019-02-02 Thread Tom Rini
On Thu, Jan 24, 2019 at 03:42:52PM +0100, Jean-Jacques Hiblot wrote:

> This is required to enable the USB port #2 in SPL when DM_USB is used.
> 
> Signed-off-by: Jean-Jacques Hiblot 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot, v1, 1/4] usb: ether: call _usb_eth_halt() if initialization fails

2019-02-02 Thread Tom Rini
On Tue, Jan 22, 2019 at 04:48:16PM +0100, Jean-Jacques Hiblot wrote:

> If the host does not respond in time, the initialization fails. However
> the usb ether driver will still be registered. This will make
> usb_gadget_probe_driver() fail the next time the initialization is
> attempted because it cannot find an available UDC.
> 
> Fixing this by calling _usb_eth_halt() when the init fails.
> 
> Signed-off-by: Jean-Jacques Hiblot 
> Acked-by: Lukasz Majewski 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] ARM: DTS: Resync am3517-evm.dts with Linux 5.0-rc3

2019-02-02 Thread Tom Rini
On Wed, Jan 23, 2019 at 12:46:42PM -0600, Adam Ford wrote:

> The chosen node was added in the kernel.  This may come in handy
> in the future, so resync with 5.0-rc3
> 
> Signed-off-by: Adam Ford 
> 
> diff --git a/arch/arm/dts/am3517-evm.dts b/arch/arm/dts/am3517-evm.dts
> index 1e2bb68231..3527c0f2df 100644

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] ARM: dts: da850-evm: Re-sync with Kernel 5.0

2019-02-02 Thread Tom Rini
On Wed, Jan 23, 2019 at 12:37:57PM -0600, Adam Ford wrote:

> Resync with Kernel 5.0-rc3
> 
> Signed-off-by: Adam Ford 
> 
> diff --git a/arch/arm/dts/da850-evm.dts b/arch/arm/dts/da850-evm.dts
> index a3c9b34672..f04bc3e153 100644

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] ARM: am3517_evm: Enable DM_SPI and DM_USB

2019-02-02 Thread Tom Rini
On Wed, Jan 23, 2019 at 08:32:19AM -0600, Adam Ford wrote:

> To comply with pending requirements, this sets the flags to
> enable DM_SPI and DM_USB.
> 
> Signed-off-by: Adam Ford 
> 
> diff --git a/configs/am3517_evm_defconfig b/configs/am3517_evm_defconfig
> index 0fe3f7ef09..38cad9cf4e 100644

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] Kconfig: set default BUILD_TARGET for kirkwood

2019-02-02 Thread Tom Rini
On Fri, Jan 18, 2019 at 08:46:43PM +1300, Chris Packham wrote:

> Now that BUILD_TARGET is in Kconfig we can define a default for boards
> using the Kirkwood SoC.
> 
> Signed-off-by: Chris Packham 
> Cc: Jagan Teki 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot,v1,3/3] am335x, shc: adapt shc board to DM

2019-02-02 Thread Tom Rini
On Mon, Jan 21, 2019 at 06:16:28AM +0100, Heiko Schocher wrote:

> port the am335x based shc board to DM, to get rid
> of DW warnings when compiling U-Boot.
> 
> - remove uneccessary board code
> - adapt defconfigs
> - remove unneeded defconfigs
>   configs/am335x_shc_prompt_defconfig
>   configs/am335x_shc_sdboot_prompt_defconfig
> 
> Signed-off-by: Heiko Schocher 
> Reviewed-by: Tom Rini 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot, v1, 3/4] configs: am335x_evm: enable DM_USB_GADGET and USB_ETHER in u-boot and SPL

2019-02-02 Thread Tom Rini
On Tue, Jan 22, 2019 at 04:48:18PM +0100, Jean-Jacques Hiblot wrote:

> The AM335x ROM boot is able to download the SPL from a RNDIS connection
> on USB0. To enable a full RNDIS boot flow (romboot -> SPL -> u-boot -> ..),
> we can use USB_ETHER in SPL and u-boot.
> However this increase the size of the SPL past its limit. So removing the
> unused SPL_EXT_SUPPORT.
> 
> Signed-off-by: Jean-Jacques Hiblot 
> Reviewed-by: Tom Rini 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot, v1, 2/4] ARM: DTS: am335x-evm: Use USB0 in peripheral mode

2019-02-02 Thread Tom Rini
On Tue, Jan 22, 2019 at 04:48:17PM +0100, Jean-Jacques Hiblot wrote:

> This USB port is mainly used for RNDIS and DFU. To be able to use it with
> DM_USB and DM_USB_GADGET, we need to provide a dr_mode value in the DTS.
> 
> Signed-off-by: Jean-Jacques Hiblot 
> Reviewed-by: Tom Rini 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot, v1, 1/3] arm: dts: add am335x-shc.dts for shc board

2019-02-02 Thread Tom Rini
On Mon, Jan 21, 2019 at 06:16:26AM +0100, Heiko Schocher wrote:

> add DTS from linux tree commit
> "47bfa6d9dc8c060bf56554a465c9031e286d2f80"
> 
> change for U-Boot:
> switch to SPDX-license identifier.
> 
> Signed-off-by: Heiko Schocher 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot, v1, 2/3] ARM: dts: am335x-shc: add u-boot specific dtsi

2019-02-02 Thread Tom Rini
On Mon, Jan 21, 2019 at 06:16:27AM +0100, Heiko Schocher wrote:

> add u-boot specific am335x-shc-u-boot.dtsi file,
> in which we add u-boot specific adaptions.
> 
> Signed-off-by: Heiko Schocher 
> Reviewed-by: Tom Rini 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot,v2,1/2] Kconfig: Migrate CONFIG_BUILD_TARGET

2019-02-02 Thread Tom Rini
On Fri, Jan 18, 2019 at 12:52:49PM +0530, Jagan Teki wrote:

> Migrate CONFIG_BUILD_TARGET into Kconfig.
> 
> Signed-off-by: Jagan Teki 

Applied to u-boot/master, thanks!

-- 
Tom


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


[U-Boot] [PATCH v3 16/22] pcm052: board: Remove in-board setup code (it is now replaced by DM setup)

2019-02-02 Thread Lukasz Majewski
This commit cleans up the pcm052.c file to remove dead code after moving to
DTS and DM.

Signed-off-by: Lukasz Majewski 
---

Changes in v3: None
Changes in v2: None

 board/phytec/pcm052/pcm052.c | 267 ---
 1 file changed, 267 deletions(-)

diff --git a/board/phytec/pcm052/pcm052.c b/board/phytec/pcm052/pcm052.c
index 95df0be6c1..4a18b0e0f4 100644
--- a/board/phytec/pcm052/pcm052.c
+++ b/board/phytec/pcm052/pcm052.c
@@ -13,79 +13,9 @@
 #include 
 #include 
 #include 
-#include 
-#include 
-#include 
-#include 
-#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
-/*
- * Default DDR pad settings in arch/arm/include/asm/arch-vf610/iomux-vf610.h
- * do not match our settings. Let us (re)define our own settings here.
- */
-
-#define PCM052_VF610_DDR_PAD_CTRL  PAD_CTL_DSE_20ohm
-#define PCM052_VF610_DDR_PAD_CTRL_1(PAD_CTL_DSE_20ohm | \
-   PAD_CTL_INPUT_DIFFERENTIAL)
-#define PCM052_VF610_DDR_RESET_PAD_CTL (PAD_CTL_DSE_150ohm | \
-   PAD_CTL_PUS_100K_UP | \
-   PAD_CTL_INPUT_DIFFERENTIAL)
-
-enum {
-   PCM052_VF610_PAD_DDR_RESETB = IOMUX_PAD(0x021c, 
__NA_, 0, __NA_, 0, PCM052_VF610_DDR_RESET_PAD_CTL),
-   PCM052_VF610_PAD_DDR_A15__DDR_A_15  = IOMUX_PAD(0x0220, 
__NA_, 0, __NA_, 0, PCM052_VF610_DDR_PAD_CTRL),
-   PCM052_VF610_PAD_DDR_A14__DDR_A_14  = IOMUX_PAD(0x0224, 
__NA_, 0, __NA_, 0, PCM052_VF610_DDR_PAD_CTRL),
-   PCM052_VF610_PAD_DDR_A13__DDR_A_13  = IOMUX_PAD(0x0228, 
__NA_, 0, __NA_, 0, PCM052_VF610_DDR_PAD_CTRL),
-   PCM052_VF610_PAD_DDR_A12__DDR_A_12  = IOMUX_PAD(0x022c, 
__NA_, 0, __NA_, 0, PCM052_VF610_DDR_PAD_CTRL),
-   PCM052_VF610_PAD_DDR_A11__DDR_A_11  = IOMUX_PAD(0x0230, 
__NA_, 0, __NA_, 0, PCM052_VF610_DDR_PAD_CTRL),
-   PCM052_VF610_PAD_DDR_A10__DDR_A_10  = IOMUX_PAD(0x0234, 
__NA_, 0, __NA_, 0, PCM052_VF610_DDR_PAD_CTRL),
-   PCM052_VF610_PAD_DDR_A9__DDR_A_9= IOMUX_PAD(0x0238, 
__NA_, 0, __NA_, 0, PCM052_VF610_DDR_PAD_CTRL),
-   PCM052_VF610_PAD_DDR_A8__DDR_A_8= IOMUX_PAD(0x023c, 
__NA_, 0, __NA_, 0, PCM052_VF610_DDR_PAD_CTRL),
-   PCM052_VF610_PAD_DDR_A7__DDR_A_7= IOMUX_PAD(0x0240, 
__NA_, 0, __NA_, 0, PCM052_VF610_DDR_PAD_CTRL),
-   PCM052_VF610_PAD_DDR_A6__DDR_A_6= IOMUX_PAD(0x0244, 
__NA_, 0, __NA_, 0, PCM052_VF610_DDR_PAD_CTRL),
-   PCM052_VF610_PAD_DDR_A5__DDR_A_5= IOMUX_PAD(0x0248, 
__NA_, 0, __NA_, 0, PCM052_VF610_DDR_PAD_CTRL),
-   PCM052_VF610_PAD_DDR_A4__DDR_A_4= IOMUX_PAD(0x024c, 
__NA_, 0, __NA_, 0, PCM052_VF610_DDR_PAD_CTRL),
-   PCM052_VF610_PAD_DDR_A3__DDR_A_3= IOMUX_PAD(0x0250, 
__NA_, 0, __NA_, 0, PCM052_VF610_DDR_PAD_CTRL),
-   PCM052_VF610_PAD_DDR_A2__DDR_A_2= IOMUX_PAD(0x0254, 
__NA_, 0, __NA_, 0, PCM052_VF610_DDR_PAD_CTRL),
-   PCM052_VF610_PAD_DDR_A1__DDR_A_1= IOMUX_PAD(0x0258, 
__NA_, 0, __NA_, 0, PCM052_VF610_DDR_PAD_CTRL),
-   PCM052_VF610_PAD_DDR_A0__DDR_A_0= IOMUX_PAD(0x025c, 
__NA_, 0, __NA_, 0, PCM052_VF610_DDR_PAD_CTRL),
-   PCM052_VF610_PAD_DDR_BA2__DDR_BA_2  = IOMUX_PAD(0x0260, 
__NA_, 0, __NA_, 0, PCM052_VF610_DDR_PAD_CTRL),
-   PCM052_VF610_PAD_DDR_BA1__DDR_BA_1  = IOMUX_PAD(0x0264, 
__NA_, 0, __NA_, 0, PCM052_VF610_DDR_PAD_CTRL),
-   PCM052_VF610_PAD_DDR_BA0__DDR_BA_0  = IOMUX_PAD(0x0268, 
__NA_, 0, __NA_, 0, PCM052_VF610_DDR_PAD_CTRL),
-   PCM052_VF610_PAD_DDR_CAS__DDR_CAS_B = IOMUX_PAD(0x026c, 
__NA_, 0, __NA_, 0, PCM052_VF610_DDR_PAD_CTRL),
-   PCM052_VF610_PAD_DDR_CKE__DDR_CKE_0 = IOMUX_PAD(0x0270, 
__NA_, 0, __NA_, 0, PCM052_VF610_DDR_PAD_CTRL),
-   PCM052_VF610_PAD_DDR_CLK__DDR_CLK_0 = IOMUX_PAD(0x0274, 
__NA_, 0, __NA_, 0, PCM052_VF610_DDR_PAD_CTRL_1),
-   PCM052_VF610_PAD_DDR_CS__DDR_CS_B_0 = IOMUX_PAD(0x0278, 
__NA_, 0, __NA_, 0, PCM052_VF610_DDR_PAD_CTRL),
-   PCM052_VF610_PAD_DDR_D15__DDR_D_15  = IOMUX_PAD(0x027c, 
__NA_, 0, __NA_, 0, PCM052_VF610_DDR_PAD_CTRL),
-   PCM052_VF610_PAD_DDR_D14__DDR_D_14  = IOMUX_PAD(0x0280, 
__NA_, 0, __NA_, 0, PCM052_VF610_DDR_PAD_CTRL),
-   PCM052_VF610_PAD_DDR_D13__DDR_D_13  = IOMUX_PAD(0x0284, 
__NA_, 0, __NA_, 0, PCM052_VF610_DDR_PAD_CTRL),
-   PCM052_VF610_PAD_DDR_D12__DDR_D_12  = IOMUX_PAD(0x0288, 
__NA_, 0, __NA_, 0, PCM052_VF610_DDR_PAD_CTRL),
-   PCM052_VF610_PAD_DDR_D11__DDR_D_11  = IOMUX_PAD(0x028c, 
__NA_, 0, __NA_, 0, PCM052_VF610_DDR_PAD_CTRL),
-   PCM052_VF610_PAD_DDR_D10__DDR_D_10  = IOMUX_PAD(0x0290, 
__NA_, 0, __NA_, 0, PCM052_VF610_DDR_PAD_CTRL),
-   PCM052_VF610_PAD_DDR_D9__DDR_D_9= IOMUX_PAD(0x0294, 
__NA_, 0, 

[U-Boot] [PATCH v3 11/22] ARM: DTS: Update pcm052 based dts files (bk4r1/pcm052)

2019-02-02 Thread Lukasz Majewski
This commit provides update and renames the bk4r1.dts to vf610-bk4r1.dts
file with more on SoC HW description.
The pcm052.dts has been renamed to vf610-pcm052.dts as well.

Moreover, a new vf610-pcm052.drsi file has been introduced
to reuse the common code between devices based on Phytec's
pcm052 modules.
Ported from Linux kernel - v4.20 (tag)

Signed-off-by: Lukasz Majewski 

---

Changes in v3: None
Changes in v2:
- Rename pcm052.dts to vf610-pcm052.dts
- Rename bk4r1.dts to vf610-bk4r1.dts
- Extract 'u-boot,dm-pre-reloc;' property to separate file (to facilitate
  sync with Linux kernel dts files)

 arch/arm/dts/Makefile |   4 +-
 arch/arm/dts/bk4r1.dts|  47 -
 arch/arm/dts/vf610-bk4r1.dts  |  97 ++
 arch/arm/dts/{pcm052.dts => vf610-pcm052.dts} |   6 +-
 arch/arm/dts/vf610-pcm052.dtsi| 259 ++
 configs/bk4r1_defconfig   |   2 +-
 configs/pcm052_defconfig  |   2 +-
 7 files changed, 361 insertions(+), 56 deletions(-)
 delete mode 100644 arch/arm/dts/bk4r1.dts
 create mode 100644 arch/arm/dts/vf610-bk4r1.dts
 rename arch/arm/dts/{pcm052.dts => vf610-pcm052.dts} (81%)
 create mode 100644 arch/arm/dts/vf610-pcm052.dtsi

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 46f1d693dc..7fe8554e14 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -429,8 +429,8 @@ dtb-$(CONFIG_MACH_SUN9I) += \
 dtb-$(CONFIG_VF610) += vf500-colibri.dtb \
vf610-colibri.dtb \
vf610-twr.dtb \
-   pcm052.dtb \
-   bk4r1.dtb
+   vf610-pcm052.dtb \
+   vf610-bk4r1.dtb
 
 dtb-$(CONFIG_MX53) += imx53-cx9020.dtb
 
diff --git a/arch/arm/dts/bk4r1.dts b/arch/arm/dts/bk4r1.dts
deleted file mode 100644
index 866b80e0b0..00
--- a/arch/arm/dts/bk4r1.dts
+++ /dev/null
@@ -1,47 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+ OR X11
-/*
- * Copyright 2016 Toradex AG
- */
-
-/dts-v1/;
-#include "vf.dtsi"
-
-/ {
-   model = "Phytec phyCORE-Vybrid";
-   compatible = "phytec,pcm052", "fsl,vf610";
-
-   chosen {
-   stdout-path = 
-   };
-
-   aliases {
-   spi0 = 
-   };
-
-};
-
- {
-   status = "okay";
-};
-
- {
-   bus-num = <0>;
-   num-cs = <2>;
-   status = "okay";
-
-   qflash0: spi_flash@0 {
-   #address-cells = <1>;
-   #size-cells = <1>;
-   compatible = "spi-flash";
-   spi-max-frequency = <10800>;
-   reg = <0>;
-   };
-
-   qflash1: spi_flash@1 {
-   #address-cells = <1>;
-   #size-cells = <1>;
-   compatible = "spi-flash";
-   spi-max-frequency = <6600>;
-   reg = <1>;
-   };
-};
diff --git a/arch/arm/dts/vf610-bk4r1.dts b/arch/arm/dts/vf610-bk4r1.dts
new file mode 100644
index 00..55cd53384a
--- /dev/null
+++ b/arch/arm/dts/vf610-bk4r1.dts
@@ -0,0 +1,97 @@
+// SPDX-License-Identifier: GPL-2.0+ OR X11
+/*
+ * (C) Copyright 2018
+ * Lukasz Majewski, DENX Software Engineering, lu...@denx.de.
+ *
+ * Copyright 2016 Toradex AG
+ */
+
+/dts-v1/;
+#include "vf610-pcm052.dtsi"
+#include "vf610-pinfunc.h"
+
+/ {
+   model = "Liebherr (LVF) BK4 Vybrid Board";
+   compatible = "lvf,bk4", "fsl,vf610";
+
+   leds {
+   pinctrl-names = "default";
+   pinctrl-0 = <_gpio_leds>;
+
+   compatible = "gpio-leds";
+
+   /* PTE15 PORT3[24] H6 green */
+   led@0 {
+   label = "0";
+   gpios = < 24 GPIO_ACTIVE_LOW>;
+   default-state = "off";
+   };
+
+   /* PTA12 PORT0[5] H5 green */
+   led@1 {
+   label = "1";
+   gpios = < 5 GPIO_ACTIVE_LOW>;
+   default-state = "off";
+   };
+
+   /* PTE20 PORT3[39] H4 green */
+   led@2 {
+   label = "2";
+   gpios = < 29 GPIO_ACTIVE_LOW>;
+   default-state = "off";
+   };
+
+   /* PTE12 PORT3[21] H3 green */
+   led@3 {
+   label = "3";
+   gpios = < 21 GPIO_ACTIVE_LOW>;
+   default-state = "off";
+   };
+
+   /* LED6 is now PRESET ETH -> PTA16 PORT0[6]  H6 red */
+   /* PTE9  PORT3[18] H5 red */
+   led@4 {
+   label = "5";
+   gpios = < 18 GPIO_ACTIVE_LOW>;
+   default-state = "off";
+   };
+
+   /* PTE23 PORT4[0]  H4 red */
+   led@5 {
+   label = "6";
+   gpios = < 0 GPIO_ACTIVE_LOW>;
+   default-state = "off";
+   };
+
+   /* PTE16 

[U-Boot] [PATCH v3 12/22] ARM: DTS: Provide vf610-bk4r1-u-boot.dtsi for U-Boot specific properties

2019-02-02 Thread Lukasz Majewski
This commit brings a separate file in which the U-Boot specific
properties (like 'dm-pre-reloc') are provided.

Such approach allows easy sync with upstream Linux kernel in the
future.

Signed-off-by: Lukasz Majewski 
Reviewed-by: Tom Rini 

---

Changes in v3: None
Changes in v2:
- New patch

 arch/arm/dts/vf610-bk4r1-u-boot.dtsi | 27 +++
 1 file changed, 27 insertions(+)
 create mode 100644 arch/arm/dts/vf610-bk4r1-u-boot.dtsi

diff --git a/arch/arm/dts/vf610-bk4r1-u-boot.dtsi 
b/arch/arm/dts/vf610-bk4r1-u-boot.dtsi
new file mode 100644
index 00..088926bde2
--- /dev/null
+++ b/arch/arm/dts/vf610-bk4r1-u-boot.dtsi
@@ -0,0 +1,27 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright 2019
+ * Lukasz Majewski, DENX Software Engineering, lu...@denx.de
+ */
+
+/ {
+   soc {
+   u-boot,dm-pre-reloc;
+   };
+};
+
+ {
+   u-boot,dm-pre-reloc;
+};
+
+_ddr {
+   u-boot,dm-pre-reloc;
+};
+
+_uart1 {
+   u-boot,dm-pre-reloc;
+};
+
+ {
+   u-boot,dm-pre-reloc;
+};
-- 
2.11.0

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


[U-Boot] [PATCH v3 15/22] config: bk4: Update include/configs/bk4r1.h file

2019-02-02 Thread Lukasz Majewski
The BK4's config file has changed since its initial posting to main line.
This commit reflects those changes.

Signed-off-by: Lukasz Majewski 
---

Changes in v3: None
Changes in v2: None

 include/configs/bk4r1.h | 214 ++--
 1 file changed, 206 insertions(+), 8 deletions(-)

diff --git a/include/configs/bk4r1.h b/include/configs/bk4r1.h
index a012705870..bbd3e4e636 100644
--- a/include/configs/bk4r1.h
+++ b/include/configs/bk4r1.h
@@ -1,24 +1,222 @@
 /* SPDX-License-Identifier: GPL-2.0+ */
 /*
+ * Copyright (C) 2018
+ * Lukasz Majewski, DENX Software Engineering, lu...@denx.de
+ *
  * Copyright 2016 3ADEV 
  * Written-by: Albert ARIBAUD 
  *
- * Configuration settings for the phytec PCM-052 SoM-based BK4R1.
+ * Configuration settings for BK4R1.
  */
 
+#ifndef __CONFIG_H
+#define __CONFIG_H
+
 /* Define the BK4r1-specific env commands */
-#define PCM052_EXTRA_ENV_SETTINGS \
+#define BK4_EXTRA_ENV_SETTINGS \
+   "bootlimit=3\0" \
+   "eraseuserdata=false\0" \
+   "altbootcmd=led 5 on; " \
+   "boot\0" \
"set_gpio103=mw 0x400ff0c4 0x0080; mw 0x4004819C 0x11bf\0" \
-   "set_gpio122=mw 0x400481e8 0x0282; mw 0x400ff0c4 0x0400\0"
+   "set_gpio102=mw 0x400ff0c4 0x40; mw 0x40048198 0x11bf\0" \
+   "set_gpio96=mw 0x40048180 0x282; mw 0x400ff0c4 0x1\0"\
+   "set_gpio122=mw 0x400481e8 0x0282; mw 0x400ff0c4 0x0400\0"\
+   "set_gpio6=mw 0x40048018 0x282; mw 0x400ff008 0x40\0"\
+   "manage_userdata=" MANAGE_USERDATA "\0"\
+   "ncenable=true\0"\
+   "ncserverip=192.168.0.77\0"\
+   "if_netconsole=ping $ncserverip\0"\
+   "start_netconsole=setenv ncip $serverip; setenv bootdelay 10;" \
+"setenv stdin nc; setenv stdout nc; setenv stderr nc; version;\0" \
+   "preboot=" BK4_NET_INIT \
+   "if ${ncenable}; then run if_netconsole start_netconsole; fi\0"
 
 /* BK4r1 boot command sets GPIO103/PTC30 to force USB hub out of reset*/
-#define PCM052_BOOTCOMMAND "run set_gpio103; sf probe; "
+#define BK4_BOOTCOMMAND "run set_gpio122; run set_gpio96; sf probe; " \
+   "run manage_userdata; "
+
+/* Enable PREBOOT variable */
+#define CONFIG_PREBOOT
+
+/* Set ARP_TIMEOUT to 500ms */
+#define CONFIG_ARP_TIMEOUT 500UL
+
+/* Set ARP_TIMEOUT_COUNT to 3 repetitions */
+#define CONFIG_NET_RETRY_COUNT 5
 
 /* BK4r1 net init sets GPIO122/PTE17 to enable Ethernet */
-#define PCM052_NET_INIT "run set_gpio122; "
+#define BK4_NET_INIT "run set_gpio122;"
+
+/* Check if userdata volume shall be erased */
+#define MANAGE_USERDATA "if ${eraseuserdata}; " \
+   "then ubi part system; " \
+   "ubi remove userdata; " \
+   "ubi create userdata; " \
+   "ubi detach; " \
+   "setenv eraseuserdata false; " \
+   "saveenv; " \
+   "fi; "
+
+/* Autoboot options */
+#define CONFIG_AUTOBOOT_KEYED
+#define CONFIG_AUTOBOOT_PROMPT \
+   "Enter passphrase to stop autoboot, booting in %d seconds\n"
+#define CONFIG_AUTOBOOT_STOP_STR "123"
+
+#include 
+#include 
+
+#define CONFIG_SKIP_LOWLEVEL_INIT
+
+/* Enable passing of ATAGs */
+#define CONFIG_CMDLINE_TAG
+
+/* Size of malloc() pool */
+#define CONFIG_SYS_MALLOC_LEN  (CONFIG_ENV_SIZE + 4 * SZ_1M)
+
+/* Allow to overwrite serial and ethaddr */
+#define CONFIG_ENV_OVERWRITE
+
+/* NAND support */
+#define CONFIG_SYS_NAND_ONFI_DETECTION
+#define CONFIG_SYS_MAX_NAND_DEVICE 1
+
+#define IMX_FEC1_BASE  ENET1_BASE_ADDR
+
+/* QSPI Configs*/
+#ifdef CONFIG_FSL_QSPI
+#define FSL_QSPI_FLASH_SIZE(SZ_16M)
+#define FSL_QSPI_FLASH_NUM 2
+#define CONFIG_SYS_FSL_QSPI_LE
+#endif
+
+#define CONFIG_LOADADDR0x8200
+
+/* We boot from the gfxRAM area of the OCRAM. */
+#define CONFIG_BOARD_SIZE_LIMIT520192
+
+/* boot command, including the target-defined one if any */
+#define CONFIG_BOOTCOMMAND BK4_BOOTCOMMAND "run bootcmd_nand"
+
+/* Extra env settings (including the target-defined ones if any) */
+#define CONFIG_EXTRA_ENV_SETTINGS \
+   BK4_EXTRA_ENV_SETTINGS \
+   "autoload=no\0" \
+   "fdt_high=0x\0" \
+   "initrd_high=0x\0" \
+   "blimg_file=u-boot.vyb\0" \
+   "blimg_addr=0x8100\0" \
+   "dtbkernel_file=fitImage\0" \
+   "dtbkernel_addr=0x8200\0" \
+   "ram_file=uRamdisk\0" \
+   "ram_addr=0x8300\0" \
+   "filesys=rootfs.ubifs\0" \
+   "sys_addr=0x8100\0" \
+   "nfs_root=/path/to/nfs/root\0" \
+   "tftptimeout=1000\0" \
+   "tftptimeoutcountmax=100\0" \
+   "mtdparts=" CONFIG_MTDPARTS_DEFAULT "\0" \
+   "ipaddr=192.168.0.60\0" \
+   

[U-Boot] [PATCH v3 21/22] pcm052: mac: Provide board specific imx_get_mac_from_fuse() function

2019-02-02 Thread Lukasz Majewski
This commit introduces the board specific function to read fused mac
address.

Signed-off-by: Lukasz Majewski 
---

Changes in v3: None
Changes in v2: None

 board/phytec/pcm052/pcm052.c | 41 +
 1 file changed, 41 insertions(+)

diff --git a/board/phytec/pcm052/pcm052.c b/board/phytec/pcm052/pcm052.c
index 721e25105a..1e443a5850 100644
--- a/board/phytec/pcm052/pcm052.c
+++ b/board/phytec/pcm052/pcm052.c
@@ -310,6 +310,47 @@ int board_init(void)
 }
 
 #ifdef CONFIG_TARGET_BK4R1
+void imx_get_mac_from_fuse(int dev_id, unsigned char *mac)
+{
+   struct ocotp_regs *ocotp = (struct ocotp_regs *)OCOTP_BASE_ADDR;
+   struct fuse_bank *bank = >bank[4];
+   struct fuse_bank4_regs *fuse =
+   (struct fuse_bank4_regs *)bank->fuse_regs;
+   u32 value;
+
+   /*
+* BK4 has different layout of stored MAC address
+* than one used in imx_get_mac_from_fuse() @ generic.c
+*/
+
+   switch (dev_id) {
+   case 0:
+   value = readl(>mac_addr1);
+
+   mac[0] = value >> 8;
+   mac[1] = value;
+
+   value = readl(>mac_addr0);
+   mac[2] = value >> 24;
+   mac[3] = value >> 16;
+   mac[4] = value >> 8;
+   mac[5] = value;
+   break;
+   case 1:
+   value = readl(>mac_addr2);
+
+   mac[0] = value >> 24;
+   mac[1] = value >> 16;
+   mac[2] = value >> 8;
+   mac[3] = value;
+
+   value = readl(>mac_addr1);
+   mac[4] = value >> 24;
+   mac[5] = value >> 16;
+   break;
+   }
+}
+
 int board_late_init(void)
 {
struct src *psrc = (struct src *)SRC_BASE_ADDR;
-- 
2.11.0

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


[U-Boot] [PATCH v3 05/22] pcm052: board: Do not enable I2C2 code in the board file

2019-02-02 Thread Lukasz Majewski
As the I2C2 clock is now enabled in the generic clock code, we can remove
this code from a board file.

Signed-off-by: Lukasz Majewski 

---

Changes in v3:
- New patch (separate board code patch)

Changes in v2: None

 board/phytec/pcm052/pcm052.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/board/phytec/pcm052/pcm052.c b/board/phytec/pcm052/pcm052.c
index f988af2abc..cfc8009102 100644
--- a/board/phytec/pcm052/pcm052.c
+++ b/board/phytec/pcm052/pcm052.c
@@ -485,7 +485,7 @@ static void clock_init(void)
clrsetbits_le32(>ccgr9, CCM_REG_CTRL_MASK,
CCM_CCGR9_FEC0_CTRL_MASK | CCM_CCGR9_FEC1_CTRL_MASK);
clrsetbits_le32(>ccgr10, CCM_REG_CTRL_MASK,
-   CCM_CCGR10_NFC_CTRL_MASK | CCM_CCGR10_I2C2_CTRL_MASK);
+   CCM_CCGR10_NFC_CTRL_MASK);
 
clrsetbits_le32(>pll2_ctrl, ANADIG_PLL2_CTRL_POWERDOWN,
ANADIG_PLL2_CTRL_ENABLE | ANADIG_PLL2_CTRL_DIV_SELECT);
-- 
2.11.0

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


[U-Boot] [PATCH v3 22/22] pcm052: bk4: Add board_phy_config() for BK4 to setup ksz8081 phy

2019-02-02 Thread Lukasz Majewski
BK4 requires setup of 50MHz reference clock for its KSZ8081 PHY devices.

Signed-off-by: Lukasz Majewski 

---

Changes in v3: None
Changes in v2: None

 board/phytec/pcm052/pcm052.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/board/phytec/pcm052/pcm052.c b/board/phytec/pcm052/pcm052.c
index 1e443a5850..c30df5df9d 100644
--- a/board/phytec/pcm052/pcm052.c
+++ b/board/phytec/pcm052/pcm052.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -382,6 +383,21 @@ int board_late_init(void)
 
return 0;
 }
+
+/**
+ * KSZ8081
+ */
+#define MII_KSZ8081_REFERENCE_CLOCK_SELECT 0x1f
+#define RMII_50MHz_CLOCK   0x8180
+
+int board_phy_config(struct phy_device *phydev)
+{
+   /* Set 50 MHz reference clock */
+   phy_write(phydev, MDIO_DEVAD_NONE, MII_KSZ8081_REFERENCE_CLOCK_SELECT,
+ RMII_50MHz_CLOCK);
+
+   return genphy_config(phydev);
+}
 #endif /* CONFIG_TARGET_BK4R1 */
 
 int checkboard(void)
-- 
2.11.0

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


[U-Boot] [PATCH v3 18/22] config: bk4: Update u-boot envs to support NOR memories initial setup

2019-02-02 Thread Lukasz Majewski
Signed-off-by: Lukasz Majewski 
---

Changes in v3: None
Changes in v2: None

 include/configs/bk4r1.h | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/include/configs/bk4r1.h b/include/configs/bk4r1.h
index 7bd3411ff2..05ebb7d9c5 100644
--- a/include/configs/bk4r1.h
+++ b/include/configs/bk4r1.h
@@ -200,6 +200,24 @@
"ubi create rootfs2 15E15000 d; " \
"ubi create userdata; " \
"ubi detach\0" \
+   "setup_nor1=" BK4_NET_INIT \
+   "if tftp ${sys_addr} ${tftpdir}ubinor1.img; " \
+   "then sf probe 0:0; " \
+   "sf erase 0 0100; " \
+   "mtdparts default; " \
+   "ubi part nor; " \
+   "ubi create nor1fs; " \
+   "ubi write ${sys_addr} nor1fs ${filesize}; " \
+   "ubi detach; fi\0" \
+   "setup_nor2=" BK4_NET_INIT \
+   "if tftp ${sys_addr} ${tftpdir}ubinor2.img; " \
+   "then sf probe 0:1; " \
+   "sf erase 0 0100; " \
+   "mtdparts default; " \
+   "ubi part nor; " \
+   "ubi create nor2fs; " \
+   "ubi write ${sys_addr} nor2fs ${filesize}; " \
+   "ubi detach; fi\0" \
"prepare_install_bk4r1_envs=" \
"echo 'Preparing envs for SD card recovery!';" \
"setenv ipaddr 192.168.0.99;" \
-- 
2.11.0

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


[U-Boot] [PATCH v3 06/22] vybrid: Define the imx_get_mac_from_fuse() as a __weak function

2019-02-02 Thread Lukasz Majewski
The proposed way of reading fused MAC in the imx_get_mac_from_fuse() may
be different for other boards.

This commit defines the imx_get_mac_from_fuse() as a weak function to allow
board file overriding it with customized function.

Signed-off-by: Lukasz Majewski 
---

Changes in v3: None
Changes in v2: None

 arch/arm/cpu/armv7/vf610/generic.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/cpu/armv7/vf610/generic.c 
b/arch/arm/cpu/armv7/vf610/generic.c
index e0c0b1bcb0..90fa695e98 100644
--- a/arch/arm/cpu/armv7/vf610/generic.c
+++ b/arch/arm/cpu/armv7/vf610/generic.c
@@ -252,7 +252,7 @@ U_BOOT_CMD(
 );
 
 #ifdef CONFIG_FEC_MXC
-void imx_get_mac_from_fuse(int dev_id, unsigned char *mac)
+__weak void imx_get_mac_from_fuse(int dev_id, unsigned char *mac)
 {
struct ocotp_regs *ocotp = (struct ocotp_regs *)OCOTP_BASE_ADDR;
struct fuse_bank *bank = >bank[4];
-- 
2.11.0

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


[U-Boot] [PATCH v3 13/22] defconfig: bk4/pcm052: Update bk4r1|pcm052_defconfig to support DM/DT

2019-02-02 Thread Lukasz Majewski
This commit updates BK4's and PCM052's config files to support as much
as possible device tree and model in u-boot.

Moreover, remove CONFIG_* from pcm052.h (as those are now in
bk4|pcm052_defconfig)

Signed-off-by: Lukasz Majewski 

---

Changes in v3: None
Changes in v2:
- Disable EFI related support and commands (as we do not plan to
  use EFI on this setup)

 configs/bk4r1_defconfig  | 47 ++-
 configs/pcm052_defconfig | 34 --
 include/configs/pcm052.h | 34 --
 3 files changed, 74 insertions(+), 41 deletions(-)

diff --git a/configs/bk4r1_defconfig b/configs/bk4r1_defconfig
index b67a3946ac..e3852f4856 100644
--- a/configs/bk4r1_defconfig
+++ b/configs/bk4r1_defconfig
@@ -2,15 +2,18 @@ CONFIG_ARM=y
 CONFIG_SYS_THUMB_BUILD=y
 CONFIG_ARCH_VF610=y
 CONFIG_SYS_TEXT_BASE=0x3f401000
+CONFIG_SYS_MALLOC_F_LEN=0x800
 CONFIG_TARGET_BK4R1=y
 CONFIG_NR_DRAM_BANKS=1
+CONFIG_FIT=y
 CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=board/phytec/pcm052/imximage.cfg"
 CONFIG_BOOTDELAY=3
 CONFIG_BOARD_EARLY_INIT_F=y
 CONFIG_HUSH_PARSER=y
-CONFIG_CMD_BOOTZ=y
-CONFIG_CMD_EEPROM=y
+# CONFIG_CMD_ELF is not set
 CONFIG_CMD_MEMTEST=y
+CONFIG_CMD_DM=y
+CONFIG_CMD_FUSE=y
 CONFIG_CMD_GPIO=y
 CONFIG_CMD_I2C=y
 CONFIG_CMD_MMC=y
@@ -19,19 +22,45 @@ CONFIG_CMD_SF=y
 CONFIG_CMD_DHCP=y
 CONFIG_CMD_MII=y
 CONFIG_CMD_PING=y
-CONFIG_CMD_DATE=y
+CONFIG_CMD_BOOTCOUNT=y
 CONFIG_CMD_FAT=y
-CONFIG_MTDIDS_DEFAULT="nand0=NAND,nor0=NOR"
-CONFIG_MTDPARTS_DEFAULT="mtdparts=NAND:640k(bootloader),128k(env1),128k(env2),128k(dtb),6144k(kernel),-(root);NOR:-(nor)"
+CONFIG_MTDIDS_DEFAULT="nand0=vf610_nfc,nor0=NOR"
+CONFIG_MTDPARTS_DEFAULT="mtdparts=vf610_nfc:2048k(bootloader),128k(env1),128k(env2),10240k(initrd),40960k(dtbkernel),-(system);NOR:-(nor)"
 CONFIG_CMD_UBI=y
 CONFIG_OF_CONTROL=y
 CONFIG_DEFAULT_DEVICE_TREE="vf610-bk4r1"
 CONFIG_ENV_IS_IN_NAND=y
+CONFIG_NETCONSOLE=y
 CONFIG_DM=y
+CONFIG_BOOTCOUNT_LIMIT=y
+CONFIG_BOOTCOUNT_BOOTLIMIT=3
+CONFIG_SYS_BOOTCOUNT_SINGLEWORD=y
+CONFIG_SYS_BOOTCOUNT_ADDR=0x4006e02c
 CONFIG_DM_GPIO=y
 CONFIG_VYBRID_GPIO=y
+CONFIG_DM_I2C=y
+CONFIG_I2C_SET_DEFAULT_BUS_NUM=y
+CONFIG_I2C_DEFAULT_BUS_NUMBER=0x2
+CONFIG_SYS_I2C_MXC=y
+CONFIG_SYS_I2C_MXC_I2C1=y
+CONFIG_SYS_I2C_MXC_I2C2=y
+CONFIG_SYS_I2C_MXC_I2C3=y
+CONFIG_SYS_I2C_MXC_I2C4=y
+CONFIG_LED=y
+CONFIG_LED_GPIO=y
+CONFIG_MISC=y
+CONFIG_MXC_OCOTP=y
+CONFIG_I2C_EEPROM=y
+CONFIG_SYS_I2C_EEPROM_ADDR=0x50
+CONFIG_SYS_I2C_EEPROM_BUS=2
+CONFIG_SYS_EEPROM_SIZE=32768
+CONFIG_SYS_EEPROM_PAGE_WRITE_BITS=6
+CONFIG_SYS_I2C_EEPROM_ADDR_LEN=2
+CONFIG_DM_MMC=y
 CONFIG_FSL_ESDHC=y
+CONFIG_MTD=y
 CONFIG_NAND_VF610_NFC=y
+CONFIG_NAND_VF610_NFC_DT=y
 CONFIG_SYS_NAND_BUSWIDTH_16BIT=y
 CONFIG_DM_SPI_FLASH=y
 CONFIG_SPI_FLASH=y
@@ -39,10 +68,18 @@ CONFIG_SPI_FLASH_STMICRO=y
 CONFIG_SPI_FLASH_MTD=y
 CONFIG_PHYLIB=y
 CONFIG_PHY_MICREL=y
+CONFIG_DM_ETH=y
+CONFIG_FEC_MXC=y
 CONFIG_MII=y
+CONFIG_PINCTRL=y
+CONFIG_PINCTRL_VYBRID=y
+CONFIG_DM_RTC=y
 CONFIG_RTC_M41T62=y
+# CONFIG_SPL_SERIAL_PRESENT is not set
+# CONFIG_TPL_SERIAL_PRESENT is not set
 CONFIG_DM_SERIAL=y
 CONFIG_FSL_LPUART=y
 CONFIG_SPI=y
 CONFIG_DM_SPI=y
 CONFIG_FSL_QSPI=y
+# CONFIG_EFI_LOADER is not set
diff --git a/configs/pcm052_defconfig b/configs/pcm052_defconfig
index 26ee823df3..906abbfd69 100644
--- a/configs/pcm052_defconfig
+++ b/configs/pcm052_defconfig
@@ -9,7 +9,6 @@ CONFIG_BOOTDELAY=3
 CONFIG_BOARD_EARLY_INIT_F=y
 CONFIG_HUSH_PARSER=y
 CONFIG_CMD_BOOTZ=y
-CONFIG_CMD_EEPROM=y
 CONFIG_CMD_MEMTEST=y
 CONFIG_CMD_GPIO=y
 CONFIG_CMD_I2C=y
@@ -18,7 +17,6 @@ CONFIG_CMD_NAND_TRIMFFS=y
 CONFIG_CMD_DHCP=y
 CONFIG_CMD_MII=y
 CONFIG_CMD_PING=y
-CONFIG_CMD_DATE=y
 CONFIG_CMD_FAT=y
 CONFIG_MTDIDS_DEFAULT="nand0=NAND"
 
CONFIG_MTDPARTS_DEFAULT="mtdparts=NAND:640k(bootloader),128k(env1),128k(env2),128k(dtb),6144k(kernel),-(root)"
@@ -29,12 +27,44 @@ CONFIG_ENV_IS_IN_NAND=y
 CONFIG_DM=y
 CONFIG_DM_GPIO=y
 CONFIG_VYBRID_GPIO=y
+CONFIG_DM_I2C=y
+CONFIG_I2C_SET_DEFAULT_BUS_NUM=y
+CONFIG_I2C_DEFAULT_BUS_NUMBER=0x2
+CONFIG_SYS_I2C_MXC=y
+CONFIG_SYS_I2C_MXC_I2C1=y
+CONFIG_SYS_I2C_MXC_I2C2=y
+CONFIG_SYS_I2C_MXC_I2C3=y
+CONFIG_SYS_I2C_MXC_I2C4=y
+CONFIG_MISC=y
+CONFIG_MXC_OCOTP=y
+CONFIG_I2C_EEPROM=y
+CONFIG_SYS_I2C_EEPROM_ADDR=0x50
+CONFIG_SYS_I2C_EEPROM_BUS=2
+CONFIG_SYS_EEPROM_SIZE=32768
+CONFIG_SYS_EEPROM_PAGE_WRITE_BITS=6
+CONFIG_SYS_I2C_EEPROM_ADDR_LEN=2
+CONFIG_DM_MMC=y
 CONFIG_FSL_ESDHC=y
+CONFIG_MTD=y
 CONFIG_NAND_VF610_NFC=y
+CONFIG_NAND_VF610_NFC_DT=y
 CONFIG_SYS_NAND_BUSWIDTH_16BIT=y
+CONFIG_DM_SPI_FLASH=y
+CONFIG_SPI_FLASH=y
+CONFIG_SPI_FLASH_STMICRO=y
+CONFIG_SPI_FLASH_MTD=y
 CONFIG_PHYLIB=y
 CONFIG_PHY_MICREL=y
+CONFIG_DM_ETH=y
+CONFIG_FEC_MXC=y
 CONFIG_MII=y
+CONFIG_PINCTRL=y
+CONFIG_PINCTRL_VYBRID=y
+CONFIG_DM_RTC=y
 CONFIG_RTC_M41T62=y
 CONFIG_DM_SERIAL=y
 CONFIG_FSL_LPUART=y
+CONFIG_SPI=y
+CONFIG_DM_SPI=y
+CONFIG_FSL_QSPI=y
+# CONFIG_EFI_LOADER is not set
diff --git a/include/configs/pcm052.h 

[U-Boot] [PATCH v3 08/22] pcm052: board: vybrid: Update the board name for BK4 device

2019-02-02 Thread Lukasz Majewski
This commit provides distinction between PCM052 and BK4.

Signed-off-by: Lukasz Majewski 
---

Changes in v3: None
Changes in v2: None

 board/phytec/pcm052/pcm052.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/board/phytec/pcm052/pcm052.c b/board/phytec/pcm052/pcm052.c
index 4e4b870304..5f2c9a9c12 100644
--- a/board/phytec/pcm052/pcm052.c
+++ b/board/phytec/pcm052/pcm052.c
@@ -573,7 +573,10 @@ int board_init(void)
 
 int checkboard(void)
 {
+#ifdef CONFIG_TARGET_BK4R1
+   puts("Board: BK4r1 (L333)\n");
+#else
puts("Board: PCM-052\n");
-
+#endif
return 0;
 }
-- 
2.11.0

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


[U-Boot] [PATCH v3 14/22] config: pcm052: Use SZ_X{MK} from linux/sizes.h for include/configs/pcm052.h

2019-02-02 Thread Lukasz Majewski
Signed-off-by: Lukasz Majewski 
---

Changes in v3: None
Changes in v2: None

 include/configs/pcm052.h | 17 +
 1 file changed, 9 insertions(+), 8 deletions(-)

diff --git a/include/configs/pcm052.h b/include/configs/pcm052.h
index c2ecb7ec18..fb8f3c8609 100644
--- a/include/configs/pcm052.h
+++ b/include/configs/pcm052.h
@@ -9,6 +9,7 @@
 #define __CONFIG_H
 
 #include 
+#include 
 
 #define CONFIG_SKIP_LOWLEVEL_INIT
 
@@ -16,7 +17,7 @@
 #define CONFIG_CMDLINE_TAG
 
 /* Size of malloc() pool */
-#define CONFIG_SYS_MALLOC_LEN  (CONFIG_ENV_SIZE + 2 * 1024 * 1024)
+#define CONFIG_SYS_MALLOC_LEN  (CONFIG_ENV_SIZE + 2 * SZ_1M)
 
 /* Allow to overwrite serial and ethaddr */
 #define CONFIG_ENV_OVERWRITE
@@ -27,7 +28,7 @@
 #define CONFIG_SYS_MAX_NAND_DEVICE 1
 /* QSPI Configs*/
 #ifdef CONFIG_FSL_QSPI
-#define FSL_QSPI_FLASH_SIZE(1 << 24)
+#define FSL_QSPI_FLASH_SIZE(SZ_16M)
 #define FSL_QSPI_FLASH_NUM 2
 #define CONFIG_SYS_FSL_QSPI_LE
 #endif
@@ -154,7 +155,7 @@
 
 /* Physical memory map */
 #define PHYS_SDRAM (0x8000)
-#define PHYS_SDRAM_SIZE(CONFIG_PCM052_DDR_SIZE * 1024 
* 1024)
+#define PHYS_SDRAM_SIZE(CONFIG_PCM052_DDR_SIZE * SZ_1M)
 
 #define CONFIG_SYS_SDRAM_BASE  PHYS_SDRAM
 #define CONFIG_SYS_INIT_RAM_ADDR   IRAM_BASE_ADDR
@@ -167,17 +168,17 @@
 
 /* environment organization */
 #ifdef CONFIG_ENV_IS_IN_MMC
-#define CONFIG_ENV_SIZE(8 * 1024)
+#define CONFIG_ENV_SIZE(SZ_8K)
 
-#define CONFIG_ENV_OFFSET  (12 * 64 * 1024)
+#define CONFIG_ENV_OFFSET  (12 * SZ_64K)
 #define CONFIG_SYS_MMC_ENV_DEV 0
 #endif
 
 #ifdef CONFIG_ENV_IS_IN_NAND
-#define CONFIG_ENV_SECT_SIZE   (128 * 1024)
-#define CONFIG_ENV_SIZE(8 * 1024)
+#define CONFIG_ENV_SECT_SIZE   (SZ_128K)
+#define CONFIG_ENV_SIZE(SZ_8K)
 #define CONFIG_ENV_OFFSET  0xA
-#define CONFIG_ENV_SIZE_REDUND (8 * 1024)
+#define CONFIG_ENV_SIZE_REDUND (SZ_8K)
 #define CONFIG_ENV_OFFSET_REDUND   0xC
 #endif
 
-- 
2.11.0

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


[U-Boot] [PATCH v3 19/22] pcm052: bk4: sdcard: Add support for SD card booting/recovery

2019-02-02 Thread Lukasz Majewski
This code allows reusing the default u-boot as in the late board init, the
default envs are restored and proper recovery scripts executed.

Signed-off-by: Lukasz Majewski 
---

Changes in v3: None
Changes in v2: None

 arch/arm/cpu/armv7/vf610/Kconfig   |  1 +
 arch/arm/include/asm/arch-vf610/imx-regs.h |  2 ++
 board/phytec/pcm052/pcm052.c   | 32 ++
 3 files changed, 35 insertions(+)

diff --git a/arch/arm/cpu/armv7/vf610/Kconfig b/arch/arm/cpu/armv7/vf610/Kconfig
index 13905b5281..5d485a3ce2 100644
--- a/arch/arm/cpu/armv7/vf610/Kconfig
+++ b/arch/arm/cpu/armv7/vf610/Kconfig
@@ -23,6 +23,7 @@ config TARGET_BK4R1
bool "BK4r1"
select SYS_FSL_ERRATUM_ESDHC135
select SYS_FSL_ERRATUM_ESDHC_A001
+   select BOARD_LATE_INIT
 
 endchoice
 
diff --git a/arch/arm/include/asm/arch-vf610/imx-regs.h 
b/arch/arm/include/asm/arch-vf610/imx-regs.h
index 5d1f63c98b..ae0a187c4d 100644
--- a/arch/arm/include/asm/arch-vf610/imx-regs.h
+++ b/arch/arm/include/asm/arch-vf610/imx-regs.h
@@ -289,6 +289,8 @@
 #define SRC_SRSR_WDOG_M4   (0x1 << 4)
 #define SRC_SRSR_WDOG_A5   (0x1 << 3)
 #define SRC_SRSR_POR_RST   (0x1 << 0)
+#define SRC_SBMR1_BOOTCFG1_SDMMCBIT(6)
+#define SRC_SBMR1_BOOTCFG1_MMC  BIT(4)
 #define SRC_SBMR2_BMOD_MASK (0x3 << 24)
 #define SRC_SBMR2_BMOD_SHIFT24
 #define SRC_SBMR2_BMOD_FUSES0x0
diff --git a/board/phytec/pcm052/pcm052.c b/board/phytec/pcm052/pcm052.c
index 4a18b0e0f4..d4f170a503 100644
--- a/board/phytec/pcm052/pcm052.c
+++ b/board/phytec/pcm052/pcm052.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -307,6 +308,37 @@ int board_init(void)
return 0;
 }
 
+#ifdef CONFIG_TARGET_BK4R1
+int board_late_init(void)
+{
+   struct src *psrc = (struct src *)SRC_BASE_ADDR;
+   u32 reg;
+
+   /*
+* BK4r1 handle emergency/service SD card boot
+* Checking the SBMR1 register BOOTCFG1 byte:
+* NAND:
+*  bit [2] - NAND data width - 16
+*  bit [5] - NAND fast boot
+*  bit [7] = 1 - NAND as a source of booting
+* SD card (0x64):
+*  bit [4] = 0 - SD card source
+*  bit [6] = 1 - SD/MMC source
+*/
+
+   reg = readl(>sbmr1);
+   if ((reg & SRC_SBMR1_BOOTCFG1_SDMMC) &&
+   !(reg & SRC_SBMR1_BOOTCFG1_MMC)) {
+   printf("-- SD card boot ---\n");
+   set_default_env("!LVFBootloader", 0);
+   env_set("bootcmd",
+   "run prepare_install_bk4r1_envs; run install_bk4r1rs");
+   }
+
+   return 0;
+}
+#endif /* CONFIG_TARGET_BK4R1 */
+
 int checkboard(void)
 {
 #ifdef CONFIG_TARGET_BK4R1
-- 
2.11.0

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


[U-Boot] [PATCH v3 09/22] ARM: DTS: vybrid: Update vf.dtsi file to descibe more vf610 hardware

2019-02-02 Thread Lukasz Majewski
This patch allows moving vf610 based boards to a device tree and model.
Ported from Linux kernel - v4.20 (tag)

Signed-off-by: Lukasz Majewski 
Reviewed-by: Stefan Agner 
---

Changes in v3: None
Changes in v2: None

 arch/arm/dts/vf.dtsi | 62 
 1 file changed, 62 insertions(+)

diff --git a/arch/arm/dts/vf.dtsi b/arch/arm/dts/vf.dtsi
index ad30059b9a..5e3b2c5b9d 100644
--- a/arch/arm/dts/vf.dtsi
+++ b/arch/arm/dts/vf.dtsi
@@ -22,6 +22,10 @@
spi1 = 
ehci0 = 
ehci1 = 
+   i2c0 = 
+   i2c1 = 
+   i2c2 = 
+   i2c3 = 
};
 
soc {
@@ -89,6 +93,22 @@
status = "disabled";
};
 
+   i2c0: i2c@40066000 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   compatible = "fsl,vf610-i2c";
+   reg = <0x40066000 0x1000>;
+   status = "disabled";
+   };
+
+   i2c1: i2c@40067000 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   compatible = "fsl,vf610-i2c";
+   reg = <0x40067000 0x1000>;
+   status = "disabled";
+   };
+
iomuxc: iomuxc@40048000 {
compatible = "fsl,vf610-iomuxc";
reg = <0x40048000 0x1000>;
@@ -156,6 +176,48 @@
reg = <0x400b4000 0x800>;
status = "disabled";
};
+
+   esdhc1: esdhc@400b2000 {
+   compatible = "fsl,esdhc";
+   reg = <0x400b2000 0x1000>;
+   status = "disabled";
+   };
+
+   fec0: fec@400d {
+ compatible = "fsl,mvf600-fec";
+ reg = <0x400d 0x1000>;
+ status = "disabled";
+   };
+
+   fec1: fec@400d1000 {
+ compatible = "fsl,mvf600-fec";
+ reg = <0x400d1000 0x1000>;
+ status = "disabled";
+   };
+
+   nfc: nand@400e {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   compatible = "fsl,vf610-nfc";
+   reg = <0x400e 0x4000>;
+   status = "disabled";
+   };
+
+   i2c2: i2c@400e6000 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   compatible = "fsl,vf610-i2c";
+   reg = <0x400e6000 0x1000>;
+   status = "disabled";
+   };
+
+   i2c3: i2c@400e7000 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   compatible = "fsl,vf610-i2c";
+   reg = <0x400e7000 0x1000>;
+   status = "disabled";
+   };
};
};
 };
-- 
2.11.0

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


[U-Boot] [PATCH v3 17/22] config: bk4: Update u-boot script to support recovery via SD card

2019-02-02 Thread Lukasz Majewski
Signed-off-by: Lukasz Majewski 
---

Changes in v3: None
Changes in v2: None

 include/configs/bk4r1.h | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/include/configs/bk4r1.h b/include/configs/bk4r1.h
index bbd3e4e636..7bd3411ff2 100644
--- a/include/configs/bk4r1.h
+++ b/include/configs/bk4r1.h
@@ -189,6 +189,37 @@
"ubi part system; " \
"ubi write ${sys_addr} rootfs${active_workset} ${filesize}; " \
"ubi detach; fi\0" \
+   "setup_dtbkernel=nand erase.part dtbkernel; " \
+   "ubi part dtbkernel; " \
+   "ubi create dtbkernel1 972000 s; " \
+   "ubi create dtbkernel2 972000 s; " \
+   "ubi detach\0" \
+   "setup_system=nand erase.part system; " \
+   "ubi part system; " \
+   "ubi create rootfs1 15E15000 d; " \
+   "ubi create rootfs2 15E15000 d; " \
+   "ubi create userdata; " \
+   "ubi detach\0" \
+   "prepare_install_bk4r1_envs=" \
+   "echo 'Preparing envs for SD card recovery!';" \
+   "setenv ipaddr 192.168.0.99;" \
+   "setenv serverip 192.168.0.50;" \
+   "\0" \
+   "install_bk4r1rs="\
+   "led 0 on; " \
+   "nand erase.chip; mtdparts default; "\
+   "led 1 on; "\
+   "run setup_dtbkernel; " \
+   "run setup_system; " \
+   "led 2 on;" \
+   "run update_bootloader_from_sd; "\
+   "run update_dtbkernel_from_sd; "\
+   "run update_rootfs_from_sd; "\
+   "setenv bootcmd 'run bootcmd_nand'; "\
+   "saveenv; " \
+   "led 3 on; " \
+   "echo Finished - Please Power off, REMOVE SDCARD and set boot" \
+   "source to NAND\0" \
"active_workset=1\0"
 
 /* Miscellaneous configurable options */
-- 
2.11.0

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


[U-Boot] [PATCH v3 20/22] pcm052: board: Add code to setup LED default states

2019-02-02 Thread Lukasz Majewski
As one has moved to DM based LEDs, this code is required to setup the
default state.

Signed-off-by: Lukasz Majewski 
---

Changes in v3: None
Changes in v2: None

 board/phytec/pcm052/pcm052.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/board/phytec/pcm052/pcm052.c b/board/phytec/pcm052/pcm052.c
index d4f170a503..721e25105a 100644
--- a/board/phytec/pcm052/pcm052.c
+++ b/board/phytec/pcm052/pcm052.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 DECLARE_GLOBAL_DATA_PTR;
@@ -314,6 +315,9 @@ int board_late_init(void)
struct src *psrc = (struct src *)SRC_BASE_ADDR;
u32 reg;
 
+   if (IS_ENABLED(CONFIG_LED))
+   led_default_state();
+
/*
 * BK4r1 handle emergency/service SD card boot
 * Checking the SBMR1 register BOOTCFG1 byte:
-- 
2.11.0

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


[U-Boot] [PATCH v3 10/22] pcm052: board: cosmetic: Add copyright notice to pcm052.c

2019-02-02 Thread Lukasz Majewski
Signed-off-by: Lukasz Majewski 
---

Changes in v3: None
Changes in v2: None

 board/phytec/pcm052/pcm052.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/board/phytec/pcm052/pcm052.c b/board/phytec/pcm052/pcm052.c
index 5f2c9a9c12..95df0be6c1 100644
--- a/board/phytec/pcm052/pcm052.c
+++ b/board/phytec/pcm052/pcm052.c
@@ -1,5 +1,8 @@
 // SPDX-License-Identifier: GPL-2.0+
 /*
+ * (C) Copyright 2018
+ * Lukasz Majewski, DENX Software Engineering, lu...@denx.de.
+ *
  * Copyright 2013 Freescale Semiconductor, Inc.
  */
 
-- 
2.11.0

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


[U-Boot] [PATCH v3 04/22] vybrid: clock: Provide enable_i2c_clk() function for Vybrid

2019-02-02 Thread Lukasz Majewski
Provide function to enable I2C clocks for vf610 - in the generic code.
This function overrides the default weak function implementation (which
only returns 1).

Signed-off-by: Lukasz Majewski 

---

Changes in v3:
- Add code to enable I2C0 code as suggested by Stefan (so the code can be
  reused by other boards without regressions)
- Exclude the pcm052.c related code to a separate patch

Changes in v2: None

 arch/arm/cpu/armv7/vf610/generic.c  | 22 ++
 arch/arm/include/asm/arch-vf610/clock.h |  3 +++
 2 files changed, 25 insertions(+)

diff --git a/arch/arm/cpu/armv7/vf610/generic.c 
b/arch/arm/cpu/armv7/vf610/generic.c
index cbd3391918..e0c0b1bcb0 100644
--- a/arch/arm/cpu/armv7/vf610/generic.c
+++ b/arch/arm/cpu/armv7/vf610/generic.c
@@ -375,3 +375,25 @@ void enable_caches(void)
mmu_set_region_dcache_behaviour(IRAM_BASE_ADDR, IRAM_SIZE, option);
 }
 #endif
+
+#ifdef CONFIG_SYS_I2C_MXC
+/* i2c_num can be from 0 - 3 */
+int enable_i2c_clk(unsigned char enable, unsigned int i2c_num)
+{
+   struct ccm_reg *ccm = (struct ccm_reg *)CCM_BASE_ADDR;
+
+   switch (i2c_num) {
+   case 0:
+   clrsetbits_le32(>ccgr4, CCM_CCGR4_I2C0_CTRL_MASK,
+   CCM_CCGR4_I2C0_CTRL_MASK);
+   case 2:
+   clrsetbits_le32(>ccgr10, CCM_CCGR10_I2C2_CTRL_MASK,
+   CCM_CCGR10_I2C2_CTRL_MASK);
+   break;
+   default:
+   return -EINVAL;
+   }
+
+   return 0;
+}
+#endif
diff --git a/arch/arm/include/asm/arch-vf610/clock.h 
b/arch/arm/include/asm/arch-vf610/clock.h
index 3bd73a01f3..72184fd608 100644
--- a/arch/arm/include/asm/arch-vf610/clock.h
+++ b/arch/arm/include/asm/arch-vf610/clock.h
@@ -22,6 +22,9 @@ enum mxc_clock {
 void enable_ocotp_clk(unsigned char enable);
 unsigned int mxc_get_clock(enum mxc_clock clk);
 u32 get_lpuart_clk(void);
+#ifdef CONFIG_SYS_I2C_MXC
+int enable_i2c_clk(unsigned char enable, unsigned int i2c_num);
+#endif
 
 #define imx_get_fecclk() mxc_get_clock(MXC_FEC_CLK)
 
-- 
2.11.0

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


[U-Boot] [PATCH v3 07/22] pcm052: board: Remove "m4go" command as it is superseded by "bootaux"

2019-02-02 Thread Lukasz Majewski
The "m4go" provides exactly the same functionality as the IMX generic
"bootaux" command. Remove it to not duplicate the code.

Signed-off-by: Lukasz Majewski 
---

Changes in v3: None
Changes in v2: None

 board/phytec/pcm052/pcm052.c | 38 --
 1 file changed, 38 deletions(-)

diff --git a/board/phytec/pcm052/pcm052.c b/board/phytec/pcm052/pcm052.c
index cfc8009102..4e4b870304 100644
--- a/board/phytec/pcm052/pcm052.c
+++ b/board/phytec/pcm052/pcm052.c
@@ -577,41 +577,3 @@ int checkboard(void)
 
return 0;
 }
-
-static int do_m4go(cmd_tbl_t *cmdtp, int flag, int argc,
-  char * const argv[])
-{
-   ulong addr;
-
-   /* Consume 'm4go' */
-   argc--; argv++;
-
-   /*
-* Parse provided address - default to load_addr in case not provided.
-*/
-
-   if (argc)
-   addr = simple_strtoul(argv[0], NULL, 16);
-   else
-   addr = load_addr;
-
-   /*
-* Write boot address in PERSISTENT_ENTRY1[31:0] aka SRC_GPR2[31:0]
-*/
-   writel(addr + 0x401, 0x4006E028);
-
-   /*
-* Start secondary processor by enabling its clock
-*/
-   writel(0x15a5a, 0x4006B08C);
-
-   return 1;
-}
-
-U_BOOT_CMD(
-   m4go, 2 /* one arg max */, 1 /* repeatable */, do_m4go,
-   "start the secondary Cortex-M4 from scatter file image",
-   "[]\n"
-   "- start secondary Cortex-M4 core using a scatter file image\n"
-   "The argument needs to be a scatter file\n"
-);
-- 
2.11.0

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


[U-Boot] [PATCH v3 03/22] vybrid: ddr: Extend vf610-pinfunc.h with DDR pads definitions

2019-02-02 Thread Lukasz Majewski
This patch provides definitions necessary for VF610 DDR pad configurations.

Signed-off-by: Lukasz Majewski 
Reviewed-by: Stefan Agner 
---

Changes in v3: None
Changes in v2: None

 arch/arm/dts/vf610-pinfunc.h | 50 
 1 file changed, 50 insertions(+)

diff --git a/arch/arm/dts/vf610-pinfunc.h b/arch/arm/dts/vf610-pinfunc.h
index fcad7132c8..24d7126756 100644
--- a/arch/arm/dts/vf610-pinfunc.h
+++ b/arch/arm/dts/vf610-pinfunc.h
@@ -807,4 +807,54 @@
 #define VF610_PAD_PTA7__GPIO_134   0x218 0x000 ALT0 0x0
 #define VF610_PAD_PTA7__VIU_PIX_CLK0x218 0x3AC ALT1 0x1
 
+#define VF610_PAD_DDR_RESETB   0x21c 0x000 ALT0 0x0
+#define VF610_PAD_DDR_A15__DDR_A_150x220 0x000 ALT0 0x0
+#define VF610_PAD_DDR_A14__DDR_A_140x224 0x000 ALT0 0x0
+#define VF610_PAD_DDR_A13__DDR_A_130x228 0x000 ALT0 0x0
+#define VF610_PAD_DDR_A12__DDR_A_120x22c 0x000 ALT0 0x0
+#define VF610_PAD_DDR_A11__DDR_A_110x230 0x000 ALT0 0x0
+#define VF610_PAD_DDR_A10__DDR_A_100x234 0x000 ALT0 0x0
+#define VF610_PAD_DDR_A9__DDR_A_9  0x238 0x000 ALT0 0x0
+#define VF610_PAD_DDR_A8__DDR_A_8  0x23c 0x000 ALT0 0x0
+#define VF610_PAD_DDR_A7__DDR_A_7  0x240 0x000 ALT0 0x0
+#define VF610_PAD_DDR_A6__DDR_A_6  0x244 0x000 ALT0 0x0
+#define VF610_PAD_DDR_A5__DDR_A_5  0x248 0x000 ALT0 0x0
+#define VF610_PAD_DDR_A4__DDR_A_4  0x24c 0x000 ALT0 0x0
+#define VF610_PAD_DDR_A3__DDR_A_3  0x250 0x000 ALT0 0x0
+#define VF610_PAD_DDR_A2__DDR_A_2  0x254 0x000 ALT0 0x0
+#define VF610_PAD_DDR_A1__DDR_A_1  0x258 0x000 ALT0 0x0
+#define VF610_PAD_DDR_A0__DDR_A_0  0x25c 0x000 ALT0 0x0
+#define VF610_PAD_DDR_BA2__DDR_BA_20x260 0x000 ALT0 0x0
+#define VF610_PAD_DDR_BA1__DDR_BA_10x264 0x000 ALT0 0x0
+#define VF610_PAD_DDR_BA0__DDR_BA_00x268 0x000 ALT0 0x0
+#define VF610_PAD_DDR_CAS__DDR_CAS_B   0x26c 0x000 ALT0 0x0
+#define VF610_PAD_DDR_CKE__DDR_CKE_0   0x270 0x000 ALT0 0x0
+#define VF610_PAD_DDR_CLK__DDR_CLK_0   0x274 0x000 ALT0 0x0
+#define VF610_PAD_DDR_CS__DDR_CS_B_0   0x278 0x000 ALT0 0x0
+#define VF610_PAD_DDR_D15__DDR_D_150x27c 0x000 ALT0 0x0
+#define VF610_PAD_DDR_D14__DDR_D_140x280 0x000 ALT0 0x0
+#define VF610_PAD_DDR_D13__DDR_D_130x284 0x000 ALT0 0x0
+#define VF610_PAD_DDR_D12__DDR_D_120x288 0x000 ALT0 0x0
+#define VF610_PAD_DDR_D11__DDR_D_110x28c 0x000 ALT0 0x0
+#define VF610_PAD_DDR_D10__DDR_D_100x290 0x000 ALT0 0x0
+#define VF610_PAD_DDR_D9__DDR_D_9  0x294 0x000 ALT0 0x0
+#define VF610_PAD_DDR_D8__DDR_D_8  0x298 0x000 ALT0 0x0
+#define VF610_PAD_DDR_D7__DDR_D_7  0x29c 0x000 ALT0 0x0
+#define VF610_PAD_DDR_D6__DDR_D_6  0x2a0 0x000 ALT0 0x0
+#define VF610_PAD_DDR_D5__DDR_D_5  0x2a4 0x000 ALT0 0x0
+#define VF610_PAD_DDR_D4__DDR_D_4  0x2a8 0x000 ALT0 0x0
+#define VF610_PAD_DDR_D3__DDR_D_3  0x2ac 0x000 ALT0 0x0
+#define VF610_PAD_DDR_D2__DDR_D_2  0x2b0 0x000 ALT0 0x0
+#define VF610_PAD_DDR_D1__DDR_D_1  0x2b4 0x000 ALT0 0x0
+#define VF610_PAD_DDR_D0__DDR_D_0  0x2b8 0x000 ALT0 0x0
+#define VF610_PAD_DDR_DQM1__DDR_DQM_1  0x2bc 0x000 ALT0 0x0
+#define VF610_PAD_DDR_DQM0__DDR_DQM_0  0x2c0 0x000 ALT0 0x0
+#define VF610_PAD_DDR_DQS1__DDR_DQS_1  0x2c4 0x000 ALT0 0x0
+#define VF610_PAD_DDR_DQS0__DDR_DQS_0  0x2c8 0x000 ALT0 0x0
+#define VF610_PAD_DDR_RAS__DDR_RAS_B   0x2cc 0x000 ALT0 0x0
+#define VF610_PAD_DDR_WE__DDR_WE_B 0x2d0 0x000 ALT0 0x0
+#define VF610_PAD_DDR_ODT1__DDR_ODT_0  0x2d4 0x000 ALT0 0x0
+#define VF610_PAD_DDR_ODT0__DDR_ODT_1  0x2d8 0x000 ALT0 0x0
+#define VF610_PAD_DDR_DDRBYTE1__DDR_DDRBYTE1   0x2dc 0x000 ALT0 0x0
+#define VF610_PAD_DDR_DDRBYTE0__DDR_DDRBYTE0   0x2e0 0x000 ALT0 0x0
 #endif
-- 
2.11.0

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


[U-Boot] [PATCH v3 00/22] imx: vybrid: Update BK4 and PCM052 boards to only use DM/DTS

2019-02-02 Thread Lukasz Majewski
This patch series converts PCM052 and BK4 to use Driver Model and Device
Tree.

Some notable changes:
- The way how MAC address is read from fuses can now be adjusted
- DTS improvement/sync with kernel (also extract u-boot specific properties)
- Using generic code instead of one from board

The output of u-boot boot:
U-Boot 2019.01-rc3-00076-gc149229be0 (Jan 14 2019 - 08:38:48 +0100)

CPU: Freescale Vybrid VF610 at 396 MHz
Reset cause: POWER ON RESET
Model: Liebherr (LVF) BK4 Vybrid Board
Board: BK4r1 (L333)
DRAM:  512 MiB
NAND:  1024 MiB
MMC:   FSL_SDHC: 0
Loading Environment from NAND... OK
In:serial@40028000
Out:   serial@40028000
Err:   serial@40028000
Net:   eth0: fec@400d, eth1: fec@400d1000
Enter passphrase to stop autoboot, booting in 3 seconds

Buildman CI:
./tools/buildman/buildman.py --branch=HEAD  vf610 mx6 vybrid --detail --verbose 
--show_errors --force-build --count=22 --output-dir=../BUILD/

Travis-CI:
https://travis-ci.org/lmajewski/u-boot-dfu/builds/487979522

U-boot master branch: SHA1: db4a29993d207fec33c07de8b8cb8a3fd22c9e6c


Changes in v3:
- Add code to enable I2C0 code as suggested by Stefan (so the code can be
  reused by other boards without regressions)
- Exclude the pcm052.c related code to a separate patch
- New patch (separate board code patch)

Changes in v2:
- Rename pcm052.dts to vf610-pcm052.dts
- Rename bk4r1.dts to vf610-bk4r1.dts
- Extract 'u-boot,dm-pre-reloc;' property to separate file (to facilitate
  sync with Linux kernel dts files)
- New patch
- Disable EFI related support and commands (as we do not plan to
  use EFI on this setup)

Lukasz Majewski (22):
  net: FEC: Add compatible for vybrid (vf610) to reuse fec_mxc.c driver
  net: Kconfig: FEC: Add dependency on VF610
  vybrid: ddr: Extend vf610-pinfunc.h with DDR pads definitions
  vybrid: clock: Provide enable_i2c_clk() function for Vybrid
  pcm052: board: Do not enable I2C2 code in the board file
  vybrid: Define the imx_get_mac_from_fuse() as a __weak function
  pcm052: board: Remove "m4go" command as it is superseded by "bootaux"
  pcm052: board: vybrid: Update the board name for BK4 device
  ARM: DTS: vybrid: Update vf.dtsi file to descibe more vf610 hardware
  pcm052: board: cosmetic: Add copyright notice to pcm052.c
  ARM: DTS: Update pcm052 based dts files (bk4r1/pcm052)
  ARM: DTS: Provide vf610-bk4r1-u-boot.dtsi for U-Boot specific
properties
  defconfig: bk4/pcm052: Update bk4r1|pcm052_defconfig to support DM/DT
  config: pcm052: Use SZ_X{MK} from linux/sizes.h for
include/configs/pcm052.h
  config: bk4: Update include/configs/bk4r1.h file
  pcm052: board: Remove in-board setup code (it is now replaced by DM
setup)
  config: bk4: Update u-boot script to support recovery via SD card
  config: bk4: Update u-boot envs to support NOR memories initial setup
  pcm052: bk4: sdcard: Add support for SD card booting/recovery
  pcm052: board: Add code to setup LED default states
  pcm052: mac: Provide board specific imx_get_mac_from_fuse() function
  pcm052: bk4: Add board_phy_config() for BK4 to setup ksz8081 phy

 arch/arm/cpu/armv7/vf610/Kconfig  |   1 +
 arch/arm/cpu/armv7/vf610/generic.c|  24 +-
 arch/arm/dts/Makefile |   4 +-
 arch/arm/dts/bk4r1.dts|  47 
 arch/arm/dts/vf.dtsi  |  62 +
 arch/arm/dts/vf610-bk4r1-u-boot.dtsi  |  27 ++
 arch/arm/dts/vf610-bk4r1.dts  |  97 +++
 arch/arm/dts/{pcm052.dts => vf610-pcm052.dts} |   6 +-
 arch/arm/dts/vf610-pcm052.dtsi| 259 +
 arch/arm/dts/vf610-pinfunc.h  |  50 
 arch/arm/include/asm/arch-vf610/clock.h   |   3 +
 arch/arm/include/asm/arch-vf610/imx-regs.h|   2 +
 board/phytec/pcm052/pcm052.c  | 386 ++
 configs/bk4r1_defconfig   |  49 +++-
 configs/pcm052_defconfig  |  36 ++-
 drivers/net/Kconfig   |   2 +-
 drivers/net/fec_mxc.c |   1 +
 include/configs/bk4r1.h   | 263 +-
 include/configs/pcm052.h  |  51 +---
 19 files changed, 959 insertions(+), 411 deletions(-)
 delete mode 100644 arch/arm/dts/bk4r1.dts
 create mode 100644 arch/arm/dts/vf610-bk4r1-u-boot.dtsi
 create mode 100644 arch/arm/dts/vf610-bk4r1.dts
 rename arch/arm/dts/{pcm052.dts => vf610-pcm052.dts} (81%)
 create mode 100644 arch/arm/dts/vf610-pcm052.dtsi

-- 
2.11.0

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


[U-Boot] [PATCH v3 02/22] net: Kconfig: FEC: Add dependency on VF610

2019-02-02 Thread Lukasz Majewski
Signed-off-by: Lukasz Majewski 
Reviewed-by: Stefan Agner 
---

Changes in v3: None
Changes in v2: None

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

diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 39ce4e8a1f..f00ab79050 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -187,7 +187,7 @@ config FEC_MXC_MDIO_BASE
 
 config FEC_MXC
bool "FEC Ethernet controller"
-   depends on MX5 || MX6 || MX7 || IMX8
+   depends on MX5 || MX6 || MX7 || IMX8 || VF610
help
  This driver supports the 10/100 Fast Ethernet controller for
  NXP i.MX processors.
-- 
2.11.0

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


[U-Boot] [PATCH v3 01/22] net: FEC: Add compatible for vybrid (vf610) to reuse fec_mxc.c driver

2019-02-02 Thread Lukasz Majewski
The NXP's FEC driver can be reused on vf610 device (with DM).

Signed-off-by: Lukasz Majewski 
Reviewed-by: Stefan Agner 
---

Changes in v3: None
Changes in v2: None

 drivers/net/fec_mxc.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/fec_mxc.c b/drivers/net/fec_mxc.c
index 1a59026a62..5ff49224f4 100644
--- a/drivers/net/fec_mxc.c
+++ b/drivers/net/fec_mxc.c
@@ -1486,6 +1486,7 @@ static const struct udevice_id fecmxc_ids[] = {
{ .compatible = "fsl,imx6ul-fec" },
{ .compatible = "fsl,imx53-fec" },
{ .compatible = "fsl,imx7d-fec" },
+   { .compatible = "fsl,mvf600-fec" },
{ }
 };
 
-- 
2.11.0

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


Re: [U-Boot] [PATCH v4 10/20] arm: dts: Update all the dts[i] files for imx6[q|qp|dl] sabre[auto|sd]

2019-02-02 Thread Lukasz Majewski
On Fri, 1 Feb 2019 16:40:16 +
Abel Vesa  wrote:

> Update all the dts[i] files for imx6[q|qp|dl] sabre[auto|sd] to the
> ones from kernel v4.20 (commit 8fe28cb58bcb2).
> 

Reviewed-by: Lukasz Majewski 

> Signed-off-by: Abel Vesa 
> Acked-by: Peng Fan 
> ---
>  arch/arm/dts/Makefile   |   8 +-
>  arch/arm/dts/imx6dl-sabreauto.dts   |  13 +
>  arch/arm/dts/imx6dl-sabresd.dts |  18 +
>  arch/arm/dts/imx6dl.dtsi| 306 --
>  arch/arm/dts/imx6q-sabreauto.dts|  18 +
>  arch/arm/dts/imx6q-sabresd.dts  |  23 +
>  arch/arm/dts/imx6q.dtsi | 310 --
>  arch/arm/dts/imx6qdl-sabreauto.dtsi | 810
> 
> arch/arm/dts/imx6qdl-sabresd.dtsi   | 741
> + arch/arm/dts/imx6qdl.dtsi
> | 455 +++- arch/arm/dts/imx6qp-sabreauto.dts   |  55
> +++ arch/arm/dts/imx6qp-sabresd.dts |  55 +++
> arch/arm/dts/imx6qp.dtsi| 115 + 13 files changed,
> 2669 insertions(+), 258 deletions(-) create mode 100644
> arch/arm/dts/imx6dl-sabreauto.dts create mode 100644
> arch/arm/dts/imx6dl-sabresd.dts create mode 100644
> arch/arm/dts/imx6q-sabreauto.dts create mode 100644
> arch/arm/dts/imx6q-sabresd.dts create mode 100644
> arch/arm/dts/imx6qdl-sabreauto.dtsi create mode 100644
> arch/arm/dts/imx6qdl-sabresd.dtsi create mode 100644
> arch/arm/dts/imx6qp-sabreauto.dts create mode 100644
> arch/arm/dts/imx6qp-sabresd.dts create mode 100644
> arch/arm/dts/imx6qp.dtsi
> 
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index 46f1d69..e8512af 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -443,7 +443,13 @@ dtb-$(CONFIG_MX6QDL) += \
>   imx6q-icore.dtb \
>   imx6q-icore-mipi.dtb \
>   imx6q-icore-rqs.dtb \
> - imx6q-logicpd.dtb
> + imx6q-logicpd.dtb \
> + imx6q-sabreauto.dtb \
> + imx6q-sabresd.dtb \
> + imx6dl-sabreauto.dtb \
> + imx6dl-sabresd.dtb \
> + imx6qp-sabreauto.dtb \
> + imx6qp-sabresd.dtb
>  
>  dtb-$(CONFIG_MX6SL) += imx6sl-evk.dtb
>  
> diff --git a/arch/arm/dts/imx6dl-sabreauto.dts
> b/arch/arm/dts/imx6dl-sabreauto.dts new file mode 100644
> index 000..660d52a
> --- /dev/null
> +++ b/arch/arm/dts/imx6dl-sabreauto.dts
> @@ -0,0 +1,13 @@
> +// SPDX-License-Identifier: GPL-2.0
> +//
> +// Copyright (C) 2013 Freescale Semiconductor, Inc.
> +
> +/dts-v1/;
> +
> +#include "imx6dl.dtsi"
> +#include "imx6qdl-sabreauto.dtsi"
> +
> +/ {
> + model = "Freescale i.MX6 DualLite/Solo SABRE Automotive
> Board";
> + compatible = "fsl,imx6dl-sabreauto", "fsl,imx6dl";
> +};
> diff --git a/arch/arm/dts/imx6dl-sabresd.dts
> b/arch/arm/dts/imx6dl-sabresd.dts new file mode 100644
> index 000..cd6bbf2
> --- /dev/null
> +++ b/arch/arm/dts/imx6dl-sabresd.dts
> @@ -0,0 +1,18 @@
> +// SPDX-License-Identifier: GPL-2.0
> +//
> +// Copyright (C) 2013 Freescale Semiconductor, Inc.
> +
> +/dts-v1/;
> +
> +#include "imx6dl.dtsi"
> +#include "imx6qdl-sabresd.dtsi"
> +
> +/ {
> + model = "Freescale i.MX6 DualLite SABRE Smart Device Board";
> + compatible = "fsl,imx6dl-sabresd", "fsl,imx6dl";
> +};
> +
> +_csi1_from_ipu1_csi1_mux {
> + clock-lanes = <0>;
> + data-lanes = <1 2>;
> +};
> diff --git a/arch/arm/dts/imx6dl.dtsi b/arch/arm/dts/imx6dl.dtsi
> index 9a4c22c..f0607eb 100644
> --- a/arch/arm/dts/imx6dl.dtsi
> +++ b/arch/arm/dts/imx6dl.dtsi
> @@ -1,12 +1,6 @@
> -
> -/*
> - * Copyright 2013 Freescale Semiconductor, Inc.
> - *
> - * This program is free software; you can redistribute it and/or
> modify
> - * it under the terms of the GNU General Public License version 2 as
> - * published by the Free Software Foundation.
> - *
> - */
> +// SPDX-License-Identifier: GPL-2.0
> +//
> +// Copyright 2013 Freescale Semiconductor, Inc.
>  
>  #include 
>  #include "imx6dl-pinfunc.h"
> @@ -39,6 +33,7 @@
>   396000  1175000
>   >;  
>   clock-latency = <61036>; /* two CLK32
> periods */
> + #cooling-cells = <2>;
>   clocks = < IMX6QDL_CLK_ARM>,
>< IMX6QDL_CLK_PLL2_PFD2_396M>,
>< IMX6QDL_CLK_STEP>,
> @@ -56,39 +51,57 @@
>   device_type = "cpu";
>   reg = <1>;
>   next-level-cache = <>;
> + operating-points = <
> + /* kHzuV */
> + 996000  125
> + 792000  1175000
> + 396000  115
> + >;
> + fsl,soc-operating-points = <
> + /* ARM kHz  SOC-PU uV */
> + 996000  1175000
> + 792000  1175000
> + 396000  1175000
> + >;
> + clock-latency = <61036>; /* 

Re: [U-Boot] [PATCH v4 09/20] arm: dts: Add all the imx6[q|qp|dl] sabre[auto|sd] u-boot dts[i] files

2019-02-02 Thread Lukasz Majewski
On Fri, 1 Feb 2019 16:40:14 +
Abel Vesa  wrote:

> This allows us to keep the basic dts[i] files up-to-date with
> the ones in kernel, but at the same time allowing the u-boot
> to add its own properties to the existing nodes.
> 

Reviewed-by: Lukasz Majewski 

> Signed-off-by: Abel Vesa 
> ---
>  arch/arm/dts/imx6dl-sabreauto-u-boot.dtsi  |  6 ++
>  arch/arm/dts/imx6dl-sabresd-u-boot.dtsi|  6 ++
>  arch/arm/dts/imx6q-sabreauto-u-boot.dtsi   |  6 ++
>  arch/arm/dts/imx6q-sabresd-u-boot.dtsi |  6 ++
>  arch/arm/dts/imx6qdl-sabreauto-u-boot.dtsi | 21 +
>  arch/arm/dts/imx6qdl-sabresd-u-boot.dtsi   | 14 ++
>  arch/arm/dts/imx6qdl-u-boot.dtsi   |  4 ++--
>  arch/arm/dts/imx6qp-sabreauto-u-boot.dtsi  |  6 ++
>  arch/arm/dts/imx6qp-sabresd-u-boot.dtsi|  6 ++
>  9 files changed, 73 insertions(+), 2 deletions(-)
>  create mode 100644 arch/arm/dts/imx6dl-sabreauto-u-boot.dtsi
>  create mode 100644 arch/arm/dts/imx6dl-sabresd-u-boot.dtsi
>  create mode 100644 arch/arm/dts/imx6q-sabreauto-u-boot.dtsi
>  create mode 100644 arch/arm/dts/imx6q-sabresd-u-boot.dtsi
>  create mode 100644 arch/arm/dts/imx6qdl-sabreauto-u-boot.dtsi
>  create mode 100644 arch/arm/dts/imx6qdl-sabresd-u-boot.dtsi
>  create mode 100644 arch/arm/dts/imx6qp-sabreauto-u-boot.dtsi
>  create mode 100644 arch/arm/dts/imx6qp-sabresd-u-boot.dtsi
> 
> diff --git a/arch/arm/dts/imx6dl-sabreauto-u-boot.dtsi
> b/arch/arm/dts/imx6dl-sabreauto-u-boot.dtsi new file mode 100644
> index 000..d75fcc1
> --- /dev/null
> +++ b/arch/arm/dts/imx6dl-sabreauto-u-boot.dtsi
> @@ -0,0 +1,6 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2019 NXP
> + */
> +
> +#include "imx6qdl-sabreauto-u-boot.dtsi"
> diff --git a/arch/arm/dts/imx6dl-sabresd-u-boot.dtsi
> b/arch/arm/dts/imx6dl-sabresd-u-boot.dtsi new file mode 100644
> index 000..e4d7d28
> --- /dev/null
> +++ b/arch/arm/dts/imx6dl-sabresd-u-boot.dtsi
> @@ -0,0 +1,6 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2019 NXP
> + */
> +
> +#include "imx6qdl-sabresd-u-boot.dtsi"
> diff --git a/arch/arm/dts/imx6q-sabreauto-u-boot.dtsi
> b/arch/arm/dts/imx6q-sabreauto-u-boot.dtsi new file mode 100644
> index 000..d75fcc1
> --- /dev/null
> +++ b/arch/arm/dts/imx6q-sabreauto-u-boot.dtsi
> @@ -0,0 +1,6 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2019 NXP
> + */
> +
> +#include "imx6qdl-sabreauto-u-boot.dtsi"
> diff --git a/arch/arm/dts/imx6q-sabresd-u-boot.dtsi
> b/arch/arm/dts/imx6q-sabresd-u-boot.dtsi new file mode 100644
> index 000..e4d7d28
> --- /dev/null
> +++ b/arch/arm/dts/imx6q-sabresd-u-boot.dtsi
> @@ -0,0 +1,6 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2019 NXP
> + */
> +
> +#include "imx6qdl-sabresd-u-boot.dtsi"
> diff --git a/arch/arm/dts/imx6qdl-sabreauto-u-boot.dtsi
> b/arch/arm/dts/imx6qdl-sabreauto-u-boot.dtsi new file mode 100644
> index 000..ea90f40
> --- /dev/null
> +++ b/arch/arm/dts/imx6qdl-sabreauto-u-boot.dtsi
> @@ -0,0 +1,21 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2019 NXP
> + */
> +
> +#include "imx6qdl-u-boot.dtsi"
> +
> +/ {
> + aliases {
> + mmc0 = 
> + };
> +};
> +
> + {
> + no-1-8-v;
> + u-boot,dm-spl;
> +};
> +
> +_usdhc3 {
> + u-boot,dm-spl;
> +};
> diff --git a/arch/arm/dts/imx6qdl-sabresd-u-boot.dtsi
> b/arch/arm/dts/imx6qdl-sabresd-u-boot.dtsi new file mode 100644
> index 000..45f02b1
> --- /dev/null
> +++ b/arch/arm/dts/imx6qdl-sabresd-u-boot.dtsi
> @@ -0,0 +1,14 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2019 NXP
> + */
> +
> +#include "imx6qdl-u-boot.dtsi"
> +
> + {
> + u-boot,dm-spl;
> +};
> +
> +_usdhc3 {
> + u-boot,dm-spl;
> +};
> diff --git a/arch/arm/dts/imx6qdl-u-boot.dtsi
> b/arch/arm/dts/imx6qdl-u-boot.dtsi index dffc21b..45ae2fa 100644
> --- a/arch/arm/dts/imx6qdl-u-boot.dtsi
> +++ b/arch/arm/dts/imx6qdl-u-boot.dtsi
> @@ -7,11 +7,11 @@
>   soc {
>   u-boot,dm-spl;
>  
> - aips-bus@0200 {
> + aips-bus@200 {
>   u-boot,dm-spl;
>   };
>  
> - aips-bus@0210 {
> + aips-bus@210 {
>   u-boot,dm-spl;
>   };
>   };
> diff --git a/arch/arm/dts/imx6qp-sabreauto-u-boot.dtsi
> b/arch/arm/dts/imx6qp-sabreauto-u-boot.dtsi new file mode 100644
> index 000..d75fcc1
> --- /dev/null
> +++ b/arch/arm/dts/imx6qp-sabreauto-u-boot.dtsi
> @@ -0,0 +1,6 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2019 NXP
> + */
> +
> +#include "imx6qdl-sabreauto-u-boot.dtsi"
> diff --git a/arch/arm/dts/imx6qp-sabresd-u-boot.dtsi
> b/arch/arm/dts/imx6qp-sabresd-u-boot.dtsi new file mode 100644
> index 000..e4d7d28
> --- /dev/null
> +++ b/arch/arm/dts/imx6qp-sabresd-u-boot.dtsi
> @@ -0,0 +1,6 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2019 

Re: [U-Boot] [PATCH v4 07/20] board: mx6sabresd: Add board_fit_config_name_match to support FIT in SPL

2019-02-02 Thread Lukasz Majewski
On Fri, 1 Feb 2019 16:40:12 +
Abel Vesa  wrote:

> This matches one of the following three boards (or fails):
>  - imx6q-sabresd
>  - imx6qp-sabresd
>  - imx6dl-sabresd
> 

Reviewed-by: Lukasz Majewski 

> Signed-off-by: Abel Vesa 
> Reviewed-by: Peng Fan 
> ---
>  board/freescale/mx6sabresd/mx6sabresd.c | 18 ++
>  1 file changed, 18 insertions(+)
> 
> diff --git a/board/freescale/mx6sabresd/mx6sabresd.c
> b/board/freescale/mx6sabresd/mx6sabresd.c index 0183ede..4688095
> 100644 --- a/board/freescale/mx6sabresd/mx6sabresd.c
> +++ b/board/freescale/mx6sabresd/mx6sabresd.c
> @@ -1062,3 +1062,21 @@ void board_init_f(ulong dummy)
>   board_init_r(NULL, 0);
>  }
>  #endif
> +
> +#ifdef CONFIG_SPL_LOAD_FIT
> +int board_fit_config_name_match(const char *name)
> +{
> + if (is_mx6dq()) {
> + if (!strcmp(name, "imx6q-sabresd"))
> + return 0;
> + } else if (is_mx6dqp()) {
> + if (!strcmp(name, "imx6qp-sabresd"))
> + return 0;
> + } else if (is_mx6dl()) {
> + if (!strcmp(name, "imx6dl-sabresd"))
> + return 0;
> + }
> +
> + return -1;
> +}
> +#endif




Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de


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


Re: [U-Boot] [PATCH v4 06/20] mmc: fsl_esdhc: Fix DM_REGULATOR ifdefs for SPL builds

2019-02-02 Thread Lukasz Majewski
On Fri, 1 Feb 2019 16:40:11 +
Abel Vesa  wrote:

> Since the fsl_esdhc will also be used by SPL, make the
> preprocessor switches more generic to allow any kind of build.
> 

The same here - as with ehci-mx6.
Thanks Abel for this patch.

Reviewed-by: Lukasz Majewski 

> Signed-off-by: Abel Vesa 
> ---
>  drivers/mmc/fsl_esdhc.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c
> index 21fa2ab..9e34557 100644
> --- a/drivers/mmc/fsl_esdhc.c
> +++ b/drivers/mmc/fsl_esdhc.c
> @@ -804,7 +804,7 @@ static int esdhc_set_voltage(struct mmc *mmc)
>   case MMC_SIGNAL_VOLTAGE_330:
>   if (priv->vs18_enable)
>   return -EIO;
> -#ifdef CONFIG_DM_REGULATOR
> +#if CONFIG_IS_ENABLED(DM_REGULATOR)
>   if (!IS_ERR_OR_NULL(priv->vqmmc_dev)) {
>   ret = regulator_set_value(priv->vqmmc_dev,
> 330); if (ret) {
> @@ -823,7 +823,7 @@ static int esdhc_set_voltage(struct mmc *mmc)
>  
>   return -EAGAIN;
>   case MMC_SIGNAL_VOLTAGE_180:
> -#ifdef CONFIG_DM_REGULATOR
> +#if CONFIG_IS_ENABLED(DM_REGULATOR)
>   if (!IS_ERR_OR_NULL(priv->vqmmc_dev)) {
>   ret = regulator_set_value(priv->vqmmc_dev,
> 180); if (ret) {
> @@ -1442,7 +1442,7 @@ static int fsl_esdhc_probe(struct udevice *dev)
>   int node = dev_of_offset(dev);
>   struct esdhc_soc_data *data =
>   (struct esdhc_soc_data *)dev_get_driver_data(dev);
> -#ifdef CONFIG_DM_REGULATOR
> +#if CONFIG_IS_ENABLED(DM_REGULATOR)
>   struct udevice *vqmmc_dev;
>  #endif
>   fdt_addr_t addr;
> @@ -1500,7 +1500,7 @@ static int fsl_esdhc_probe(struct udevice *dev)
>  
>   priv->vs18_enable = 0;
>  
> -#ifdef CONFIG_DM_REGULATOR
> +#if CONFIG_IS_ENABLED(DM_REGULATOR)
>   /*
>* If emmc I/O has a fixed voltage at 1.8V, this must be
> provided,
>* otherwise, emmc will work abnormally.




Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de


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


Re: [U-Boot] [PATCH v4 08/20] board: mx6sabreauto: Add board_fit_config_name_match to support FIT in SPL

2019-02-02 Thread Lukasz Majewski
On Fri, 1 Feb 2019 16:40:13 +
Abel Vesa  wrote:

> This matches one of the following three boards (or fails):
>  - imx6q-sabreauto
>  - imx6qp-sabreauto
>  - imx6dl-sabreauto
> 

Reviewed-by: Lukasz Majewski 

> Signed-off-by: Abel Vesa 
> Reviewed-by: Peng Fan 
> ---
>  board/freescale/mx6sabreauto/mx6sabreauto.c | 18 ++
>  1 file changed, 18 insertions(+)
> 
> diff --git a/board/freescale/mx6sabreauto/mx6sabreauto.c
> b/board/freescale/mx6sabreauto/mx6sabreauto.c index c1bef85..c8f1263
> 100644 --- a/board/freescale/mx6sabreauto/mx6sabreauto.c
> +++ b/board/freescale/mx6sabreauto/mx6sabreauto.c
> @@ -1097,3 +1097,21 @@ void board_init_f(ulong dummy)
>   board_init_r(NULL, 0);
>  }
>  #endif
> +
> +#ifdef CONFIG_SPL_LOAD_FIT
> +int board_fit_config_name_match(const char *name)
> +{
> + if (is_mx6dq()) {
> + if (!strcmp(name, "imx6q-sabreauto"))
> + return 0;
> + } else if (is_mx6dqp()) {
> + if (!strcmp(name, "imx6qp-sabreauto"))
> + return 0;
> + } else if (is_mx6dl()) {
> + if (!strcmp(name, "imx6dl-sabreauto"))
> + return 0;
> + }
> +
> + return -1;
> +}
> +#endif




Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de


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


Re: [U-Boot] [PATCH v4 03/20] usb: ehci-mx6: Make regulator DM_REGULATOR dependent

2019-02-02 Thread Lukasz Majewski
On Fri, 1 Feb 2019 16:40:08 +
Abel Vesa  wrote:

> Do the regulator related work only if the build has the DM_REGULATOR.
> 

Yes, this part was missing for IMX6Q - especially SPL can get away with
enabling SPL_DM_REGULATOR if needed.

Reviewed-by: Lukasz Majewski 

> Signed-off-by: Abel Vesa 
> Reviewed-by: Peng Fan 
> ---
>  drivers/usb/host/ehci-mx6.c | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/host/ehci-mx6.c b/drivers/usb/host/ehci-mx6.c
> index 1acf08d..9483947 100644
> --- a/drivers/usb/host/ehci-mx6.c
> +++ b/drivers/usb/host/ehci-mx6.c
> @@ -404,6 +404,7 @@ static int mx6_init_after_reset(struct ehci_ctrl
> *dev) if (ret)
>   return ret;
>  
> +#if CONFIG_IS_ENABLED(DM_REGULATOR)
>   if (priv->vbus_supply) {
>   ret = regulator_set_enable(priv->vbus_supply,
>  (type ==
> USB_INIT_DEVICE) ? @@ -413,6 +414,7 @@ static int
> mx6_init_after_reset(struct ehci_ctrl *dev) return ret;
>   }
>   }
> +#endif
>  
>   if (type == USB_INIT_DEVICE)
>   return 0;
> @@ -514,15 +516,17 @@ static int ehci_usb_probe(struct udevice *dev)
>   priv->portnr = dev->seq;
>   priv->init_type = type;
>  
> +#if CONFIG_IS_ENABLED(DM_REGULATOR)
>   ret = device_get_supply_regulator(dev, "vbus-supply",
> >vbus_supply);
>   if (ret)
>   debug("%s: No vbus supply\n", dev->name);
> -
> +#endif
>   ret = ehci_mx6_common_init(ehci, priv->portnr);
>   if (ret)
>   return ret;
>  
> +#if CONFIG_IS_ENABLED(DM_REGULATOR)
>   if (priv->vbus_supply) {
>   ret = regulator_set_enable(priv->vbus_supply,
>  (type ==
> USB_INIT_DEVICE) ? @@ -532,6 +536,7 @@ static int
> ehci_usb_probe(struct udevice *dev) return ret;
>   }
>   }
> +#endif
>  
>   if (priv->init_type == USB_INIT_HOST) {
>   setbits_le32(>usbmode, CM_HOST);




Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de


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


Re: [U-Boot] [PATCH v4 02/20] usb: Rename SPL_USB_SUPPORT to SPL_USB_STORAGE

2019-02-02 Thread Lukasz Majewski
On Fri, 1 Feb 2019 16:40:07 +
Abel Vesa  wrote:

> Since there is the SPL_USB_HOST_SUPPORT for enabling USB support in
> SPL, makes more sense to rename the SPL_USB_SUPPORT as
> SPL_USB_STORAGE. Everything that is not part of the usb storage
> support in SPL is now build under SPL_USB_HOST_SUPPORT.
> 

Reviewed-by: Lukasz Majewski 

> Signed-off-by: Abel Vesa 
> Reviewed-by: Tom Rini 
> ---
>  arch/arm/include/asm/arch-am33xx/spl.h| 2 +-
>  arch/arm/mach-omap2/boot-common.c | 2 +-
>  common/Makefile   | 5 +++--
>  common/spl/Kconfig| 4 ++--
>  common/spl/Makefile   | 2 +-
>  common/spl/spl_usb.c  | 4 
>  configs/am43xx_evm_usbhost_boot_defconfig | 2 +-
>  configs/am43xx_hs_evm_defconfig   | 2 +-
>  8 files changed, 10 insertions(+), 13 deletions(-)
> 
> diff --git a/arch/arm/include/asm/arch-am33xx/spl.h
> b/arch/arm/include/asm/arch-am33xx/spl.h index 0bf8c17..f3910c2 100644
> --- a/arch/arm/include/asm/arch-am33xx/spl.h
> +++ b/arch/arm/include/asm/arch-am33xx/spl.h
> @@ -62,7 +62,7 @@
>  #define BOOT_DEVICE_CPGMAC   0x47
>  
>  #define MMC_BOOT_DEVICES_START   BOOT_DEVICE_MMC1
> -#ifdef CONFIG_SPL_USB_SUPPORT
> +#ifdef CONFIG_SPL_USB_STORAGE
>  #define MMC_BOOT_DEVICES_END BOOT_DEVICE_USB
>  #else
>  #define MMC_BOOT_DEVICES_END BOOT_DEVICE_MMC2
> diff --git a/arch/arm/mach-omap2/boot-common.c
> b/arch/arm/mach-omap2/boot-common.c index 2db1922..c8b8ac6 100644
> --- a/arch/arm/mach-omap2/boot-common.c
> +++ b/arch/arm/mach-omap2/boot-common.c
> @@ -93,7 +93,7 @@ void save_omap_boot_params(void)
>   sys_boot_device = 1;
>   break;
>  #endif
> -#if defined(BOOT_DEVICE_USB) && !defined(CONFIG_SPL_USB_SUPPORT)
> +#if defined(BOOT_DEVICE_USB) && !defined(CONFIG_SPL_USB_STORAGE)
>   case BOOT_DEVICE_USB:
>   sys_boot_device = 1;
>   break;
> diff --git a/common/Makefile b/common/Makefile
> index ad390d0..8c92feb 100644
> --- a/common/Makefile
> +++ b/common/Makefile
> @@ -75,8 +75,9 @@ obj-$(CONFIG_SPL_NET_SUPPORT) += miiphyutil.o
>  obj-$(CONFIG_$(SPL_TPL_)OF_LIBFDT) += fdt_support.o
>  
>  ifdef CONFIG_SPL_USB_HOST_SUPPORT
> -obj-$(CONFIG_SPL_USB_SUPPORT) += usb.o usb_hub.o
> -obj-$(CONFIG_USB_STORAGE) += usb_storage.o
> +obj-y += usb.o
> +obj-y += usb_hub.o
> +obj-$(CONFIG_SPL_USB_STORAGE) += usb_storage.o
>  else
>  obj-$(CONFIG_USB_MUSB_HOST) += usb.o
>  endif
> diff --git a/common/spl/Kconfig b/common/spl/Kconfig
> index 54b0dc3..8b0627e 100644
> --- a/common/spl/Kconfig
> +++ b/common/spl/Kconfig
> @@ -766,9 +766,9 @@ config SPL_USB_HOST_SUPPORT
> device can be attached. This option enables the drivers in
> drivers/usb/host as part of an SPL build.
>  
> -config SPL_USB_SUPPORT
> +config SPL_USB_STORAGE
>   bool "Support loading from USB"
> - depends on SPL_USB_HOST_SUPPORT
> + depends on SPL_USB_HOST_SUPPORT && !(BLK && !DM_USB)
>   help
> Enable support for USB devices in SPL. This allows use of
> USB devices such as hard drives and flash drivers for loading U-Boot.
> diff --git a/common/spl/Makefile b/common/spl/Makefile
> index 6f8d759..a3980ce 100644
> --- a/common/spl/Makefile
> +++ b/common/spl/Makefile
> @@ -22,7 +22,7 @@ obj-$(CONFIG_$(SPL_TPL_)NET_SUPPORT) += spl_net.o
>  obj-$(CONFIG_$(SPL_TPL_)MMC_SUPPORT) += spl_mmc.o
>  obj-$(CONFIG_$(SPL_TPL_)ATF) += spl_atf.o
>  obj-$(CONFIG_$(SPL_TPL_)OPTEE) += spl_optee.o
> -obj-$(CONFIG_$(SPL_TPL_)USB_SUPPORT) += spl_usb.o
> +obj-$(CONFIG_$(SPL_TPL_)USB_STORAGE) += spl_usb.o
>  obj-$(CONFIG_$(SPL_TPL_)FAT_SUPPORT) += spl_fat.o
>  obj-$(CONFIG_$(SPL_TPL_)EXT_SUPPORT) += spl_ext.o
>  obj-$(CONFIG_$(SPL_TPL_)SATA_SUPPORT) += spl_sata.o
> diff --git a/common/spl/spl_usb.c b/common/spl/spl_usb.c
> index c8d8231..e29d579 100644
> --- a/common/spl/spl_usb.c
> +++ b/common/spl/spl_usb.c
> @@ -15,9 +15,7 @@
>  #include 
>  #include 
>  
> -#ifdef CONFIG_USB_STORAGE
>  static int usb_stor_curr_dev = -1; /* current device */
> -#endif
>  
>  static int spl_usb_load_image(struct spl_image_info *spl_image,
> struct spl_boot_device *bootdev)
> @@ -34,13 +32,11 @@ static int spl_usb_load_image(struct
> spl_image_info *spl_image, return err;
>   }
>  
> -#ifdef CONFIG_USB_STORAGE
>   /* try to recognize storage devices immediately */
>   usb_stor_curr_dev = usb_stor_scan(1);
>   stor_dev = blk_get_devnum_by_type(IF_TYPE_USB,
> usb_stor_curr_dev); if (!stor_dev)
>   return -ENODEV;
> -#endif
>  
>   debug("boot mode - FAT\n");
>  
> diff --git a/configs/am43xx_evm_usbhost_boot_defconfig
> b/configs/am43xx_evm_usbhost_boot_defconfig index 5131f19..5bd919b
> 100644 --- a/configs/am43xx_evm_usbhost_boot_defconfig
> +++ b/configs/am43xx_evm_usbhost_boot_defconfig
> @@ -14,7 +14,7 @@ CONFIG_VERSION_VARIABLE=y
>  CONFIG_SPL_MTD_SUPPORT=y
>  CONFIG_SPL_OS_BOOT=y
>  

Re: [U-Boot] [PATCH] MTD: nand: mxs_nand: Allow driver to auto setup ECC in SPL

2019-02-02 Thread Adam Ford
On Sat, Feb 2, 2019 at 11:17 AM Jörg Krause  wrote:
>
> Hi,
>
> On Thu, 2019-01-17 at 07:16 -0600, Adam Ford wrote:
> > The initialization of the NAND in SPL hard-coded ecc.bytes,
> > ecc.size, and ecc.strength which may work for some NAND parts,
> > but it not appropriate for others.  With the pending patch
> > "mxs_nand: Fix BCH read timeout error on boards requiring ECC"
> > the driver can auto configure the ECC when these entries are
> > blank.  This patch has been tested in NAND flash with oob 64
> > and oob 128.
> >
> > Signed-off-by: Adam Ford 
>
> Maybe you can give me a hint where the driver actually does the auto
> configuration?
>
> I've tested the patch on a custom i.MX6ULL board with a Micron NAND
> flash. The SPL loader is able to boot from NAND with and without this
> patch.

I am traveling right now, so I don;t have my editor or source code,
but I can tell you that the patch found in
http://patchwork.ozlabs.org/patch/1020160/  sets up the ECC, and if
these values are not set they will get set.  I won't be back to the
office until a week from Monday.

The reason I found I needed this patch was because I have boards with
different flash parts that used different ECC values.  One my board
boards didn't need the patch because the ECC matched the values
hard-coded here, but my other board would get ECC errors during SPL
because these values didn't match what U-Boot used when it wrote to
flash.

If your board works with and without the patch, I am guessing the ECC
values generated by the above mentioned patch probably set them to the
same values that were hard coded before.

adam
>
> Tested-by: Jörg Krause 
>
> > diff --git a/drivers/mtd/nand/raw/mxs_nand.c 
> > b/drivers/mtd/nand/raw/mxs_nand.c
> > index 2d84bfffe2..95fa452cef 100644
> > --- a/drivers/mtd/nand/raw/mxs_nand.c
> > +++ b/drivers/mtd/nand/raw/mxs_nand.c
> > @@ -1191,9 +1191,6 @@ int mxs_nand_init_spl(struct nand_chip *nand)
> >   nand->ecc.read_page = mxs_nand_ecc_read_page;
> >
> >   nand->ecc.mode  = NAND_ECC_HW;
> > - nand->ecc.bytes = 9;
> > - nand->ecc.size  = 512;
> > - nand->ecc.strength  = 8;
> >
> >   return 0;
> >  }
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] IMX6 NAND boot regression

2019-02-02 Thread Jörg Krause
Hi,

On Sat, 2019-02-02 at 05:30 -0800, Adam Ford wrote:
> On Sat, Feb 2, 2019 at 12:29 AM Jagan Teki  wrote:
> > +Adam, Shyam
> > 
> > On Sat, 2 Feb, 2019, 8:49 AM Stefan Agner  > 
> > > Hi Tim,
> > > 
> > > On 02.02.19 03:32, Tim Harvey wrote:
> > > > Stefan,
> > > > 
> > > > I'm trying to track down an IMX6 SPL NAND boot regression that started
> > > > in v2018.07 with your patch series to mxs_nand.
> > > 
> > > I am sorry about that. Unfortunately I did not had a design at hand where
> > > I was able to test the NAND driver in SPL...
> > > 
> > > > I bisected it back to '5346c31e305a37d39f535cc0d5ae87d8b7e81230 mtd:
> > > > nand: mxs_nand: use self init'. With this particular patch nand bbt
> > > > scanning would crash the board because of nand_chip.scan_btt not being
> > > > assigned. This was later fixed in
> > > > '96d0be07e7498e7174daa6f3b56fc807b9feb71d MTD: nand: mxs_nand_spl: Fix
> > > > empty function pointer for BBT' but cherry-picking that on top of
> > > > 5346c31 fixes the immediate crash while scanning but then I find that
> > > > mxs_read_page_ecc() hangs on the 4th page of reading u-boot.img from
> > > > the NAND. This gets worse 2 patches later where in
> > > > '28897e8d21f8e197e259a91c693de09cd81f2d5a: mtd: nand: mxs_nand: use
> > > > structure for BCH geometry' I find that the first byte of every page
> > > > read is wrong because mxs_nand_swap_block_mark() is getting called on
> > > > the page which swaps the first bytes with oob.
> > > > 
> > > > There are several IMX6 boards out there using both NAND and SPL I
> > > > believe that I would assume were broken by this series. Any ideas on
> > > > the proper resolution?
> > 
> > Look like 2017.03 can be stable boot from nand as for as my test is concern.
> > 
> > We are also trying hard using git bisect, but seems like multiple breakings.
> > 
> > Will keep posted if something move further.
> 
> From a different thread, someone was able to test these patches and
> found they fixed their booting issues:
> 
>  There was a broken function pointer here that was fixed and applied
>  the imx-master, but pending merge with master
>  http://patchwork.ozlabs.org/patch/1019440/
> 
>  Configure ECC from SPL here:
>  http://patchwork.ozlabs.org/patch/1020160/
> 
>  Remove hard-coded ECC parameters since the patch above can autoset them.
>  http://patchwork.ozlabs.org/patch/1026638/
> 
> Maybe those can help.

I can confirm that that the commit
5346c31e305a37d39f535cc0d5ae87d8b7e81230 broke booting from NAND for my
i.MX6ULL board, so I sticked with version 2018.05.

Now, I've tested U-Boot 2019.01 with the three patches Adam suggested
and the SPL loader is able to boot from NAND again.

Jörg

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


Re: [U-Boot] [PATCH] MTD: nand: mxs_nand: Allow driver to auto setup ECC in SPL

2019-02-02 Thread Jörg Krause
Hi,

On Thu, 2019-01-17 at 07:16 -0600, Adam Ford wrote:
> The initialization of the NAND in SPL hard-coded ecc.bytes,
> ecc.size, and ecc.strength which may work for some NAND parts,
> but it not appropriate for others.  With the pending patch
> "mxs_nand: Fix BCH read timeout error on boards requiring ECC"
> the driver can auto configure the ECC when these entries are
> blank.  This patch has been tested in NAND flash with oob 64
> and oob 128.
> 
> Signed-off-by: Adam Ford 

Maybe you can give me a hint where the driver actually does the auto
configuration?

I've tested the patch on a custom i.MX6ULL board with a Micron NAND
flash. The SPL loader is able to boot from NAND with and without this
patch.

Tested-by: Jörg Krause 

> diff --git a/drivers/mtd/nand/raw/mxs_nand.c b/drivers/mtd/nand/raw/mxs_nand.c
> index 2d84bfffe2..95fa452cef 100644
> --- a/drivers/mtd/nand/raw/mxs_nand.c
> +++ b/drivers/mtd/nand/raw/mxs_nand.c
> @@ -1191,9 +1191,6 @@ int mxs_nand_init_spl(struct nand_chip *nand)
>   nand->ecc.read_page = mxs_nand_ecc_read_page;
>  
>   nand->ecc.mode  = NAND_ECC_HW;
> - nand->ecc.bytes = 9;
> - nand->ecc.size  = 512;
> - nand->ecc.strength  = 8;
>  
>   return 0;
>  }

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


Re: [U-Boot] [PATCH v2 00/11] SiFive FU540 Support

2019-02-02 Thread Paul Walmsley

On Tue, 22 Jan 2019, Auer, Lukas wrote:

> For the same reason, I agree with you that it does not make sense to 
> implement the SBI in U-Boot. OpenSBI is better suited to handle this.

It should be possible to link the OpenSBI library with U-boot, then allow 
U-boot to use SBI services itself, and to expose the SBI services to 
whatever it boots.  So the OpenSBI boot firmware wouldn't be used, but the 
underlying library code would be.  That simplifies the boot flow, since 
the (separate) OpenSBI firmware would no longer be needed.

> A boot flow that could be used in this case is the following.
> 
> ZSBL -> U-Boot SPL (M-mode) -> OpenSBI -> U-Boot proper (S-mode)

There are other boot flows that are common on ARM platforms:

- Boot ROM -> SPL -> U-boot -> Linux
- Boot ROM -> SPL -> U-boot -> (SBI implementation / TEE) -> Linux

It would be good if we could avoid prejudicing against any of these boot 
flows.


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


Re: [U-Boot] [PATCH] initcall: Move to inline function

2019-02-02 Thread Alexander Graf


> Am 02.02.2019 um 15:13 schrieb Simon Glass :
> 
> Hi Alex,
> 
>> On Thu, 31 Jan 2019 at 08:06, Alexander Graf  wrote:
>> 
>> The board_r init function was complaining that we are looping through
>> an array, calling all our tiny init stubs sequentially via indirect
>> function calls (which can't be speculated, so they are slow).
> 
> Is this a compiler warning? Could you let me know what this is?

It's the code comment I'm removing with this patch :).

> 
>> 
>> The solution to that is pretty easy though. All we need to do is inline
>> the function that loops through the functions and the compiler will
>> automatically convert almost all indirect calls into direct inlined code.
> 
> You mean it calls the functions one after the other without a
> function-table array?

Exactly. Magical, eh? It even inlines them!

Alex

> 
>> 
>> With this patch, the overall code size drops (by 40 bytes on riscv64)
>> and boot time should become measurably faster for every target.
>> 
>> Signed-off-by: Alexander Graf 
>> ---
>> common/board_r.c   |  5 +
>> include/initcall.h | 35 ++-
>> lib/Makefile   |  1 -
>> lib/initcall.c | 39 ---
>> 4 files changed, 35 insertions(+), 45 deletions(-)
>> delete mode 100644 lib/initcall.c
>> 
> 
> Regards,
> Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH] MTD: nand: mxs_nand_spl: Fix empty function pointer for BBT

2019-02-02 Thread Jörg Krause
On Thu, 2019-01-03 at 15:52 +, Stefan Agner wrote:
> On 30.12.18 17:11, Adam Ford wrote:
> > The initialization function calls a nand_chip.scan_bbt(mtd) but
> > scan_bbt is never initialized resulting in an undefined function
> > pointer.  This will direct the function pointer to nand_default_bbt
> > defined in the same file.
> > 
> > Signed-off-by: Adam Ford 
> 
> Seems sensible
> 
> Acked-by: Stefan Agner 

Fixes crashing NAND SPL loader on my i.MX6ULL board, which was
introduced in commit 5346c31e305a37d39f535cc0d5ae87d8b7e81230 and is
present in U-Boot since version 2018.07.

Tested on a custom i.MX6ULL board with a Micron NAND flash.

Tested-by: Jörg Krause 

> 
> > diff --git a/drivers/mtd/nand/raw/mxs_nand_spl.c 
> > b/drivers/mtd/nand/raw/mxs_nand_spl.c
> > index 2d7bbe83cc..c628f3adec 100644
> > --- a/drivers/mtd/nand/raw/mxs_nand_spl.c
> > +++ b/drivers/mtd/nand/raw/mxs_nand_spl.c
> > @@ -185,6 +185,7 @@ static int mxs_nand_init(void)
> > mtd = nand_to_mtd(_chip);
> > /* set mtd functions */
> > nand_chip.cmdfunc = mxs_nand_command;
> > +   nand_chip.scan_bbt = nand_default_bbt;
> > nand_chip.numchips = 1;
> >  
> > /* identify flash device */

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


Re: [U-Boot] [PATCH v4 1/1] avb: add support for named persistent values

2019-02-02 Thread Simon Glass
Hi Igor,

On Fri, 1 Feb 2019 at 13:38, Igor Opaniuk  wrote:
>
> Hi Simon,
>
> Thanks for reviewing!
>
> > I'm assuming that this test runs with 'make qcheck'?
>
> I've tested only by invoking test.py:
> ./test/py/test.py --bd sandbox --build

Yes that's fine, just wanted to make sure it is invoked in the normal way.

[..]

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


Re: [U-Boot] [PATCH v2 7/7] i2c: mux: Generate longer i2c mux name

2019-02-02 Thread Simon Glass
On Thu, 31 Jan 2019 at 08:31, Michal Simek  wrote:
>
> For !DM case busses are listed as
> ZynqMP> i2c bus
> Bus 0:  zynq_0
> Bus 1:  zynq_0->PCA9544A@0x75:0
> Bus 2:  zynq_0->PCA9544A@0x75:1
> Bus 3:  zynq_0->PCA9544A@0x75:2
> Bus 4:  zynq_1
> Bus 5:  zynq_1->PCA9548@0x74:0
> Bus 6:  zynq_1->PCA9548@0x74:1
> Bus 7:  zynq_1->PCA9548@0x74:2
> Bus 8:  zynq_1->PCA9548@0x74:3
> Bus 9:  zynq_1->PCA9548@0x74:4
> Bus 10: zynq_1->PCA9548@0x75:0
> Bus 11: zynq_1->PCA9548@0x75:1
> Bus 12: zynq_1->PCA9548@0x75:2
> Bus 13: zynq_1->PCA9548@0x75:3
> Bus 14: zynq_1->PCA9548@0x75:4
> Bus 15: zynq_1->PCA9548@0x75:5
> Bus 16: zynq_1->PCA9548@0x75:6
> Bus 17: zynq_1->PCA9548@0x75:7
>
> where is exactly describing i2c bus topology.
> By moving to DM case i2c mux buses are using names from DT and because
> i2c-muxes describing sub busses with the same names like i2c@0, etc it
> is hard to identify which bus is where.
> Linux is adding topology information to i2c-mux busses to identify them
> better.
> This patch is doing the same and composing bus name with topology
> information.
>
> When patch is applied with topology information on zcu102-revA.
> ZynqMP> i2c bus
> Bus 0:  i2c@ff02
>20: gpio@20, offset len 1, flags 0
>21: gpio@21, offset len 1, flags 0
>75: i2c-mux@75, offset len 1, flags 0
> Bus 2:  i2c@ff02->i2c-mux@75->i2c@0
> Bus 3:  i2c@ff02->i2c-mux@75->i2c@1
> Bus 4:  i2c@ff02->i2c-mux@75->i2c@2
> Bus 1:  i2c@ff03  (active 1)
>74: i2c-mux@74, offset len 1, flags 0
>75: i2c-mux@75, offset len 1, flags 0
> Bus 5:  i2c@ff03->i2c-mux@74->i2c@0  (active 5)
>54: eeprom@54, offset len 1, flags 0
> Bus 6:  i2c@ff03->i2c-mux@74->i2c@1
> Bus 7:  i2c@ff03->i2c-mux@74->i2c@2
> Bus 8:  i2c@ff03->i2c-mux@74->i2c@3
> Bus 9:  i2c@ff03->i2c-mux@74->i2c@4
> Bus 10: i2c@ff03->i2c-mux@75->i2c@0
> Bus 11: i2c@ff03->i2c-mux@75->i2c@1
> Bus 12: i2c@ff03->i2c-mux@75->i2c@2
> Bus 13: i2c@ff03->i2c-mux@75->i2c@3
> Bus 14: i2c@ff03->i2c-mux@75->i2c@4
> Bus 15: i2c@ff03->i2c-mux@75->i2c@5
> Bus 16: i2c@ff03->i2c-mux@75->i2c@6
> Bus 17: i2c@ff03->i2c-mux@75->i2c@7
>
> Behavior before the patch is applied.
> ZynqMP> i2c bus
> Bus 0:  i2c@ff02
>20: gpio@20, offset len 1, flags 0
>21: gpio@21, offset len 1, flags 0
>75: i2c-mux@75, offset len 1, flags 0
> Bus 2:  i2c@0
> Bus 3:  i2c@1
> Bus 4:  i2c@2
> Bus 1:  i2c@ff03  (active 1)
>74: i2c-mux@74, offset len 1, flags 0
>75: i2c-mux@75, offset len 1, flags 0
> Bus 5:  i2c@0  (active 5)
>54: eeprom@54, offset len 1, flags 0
> Bus 6:  i2c@1
> Bus 7:  i2c@2
> Bus 8:  i2c@3
> Bus 9:  i2c@4
> Bus 10: i2c@0
> Bus 11: i2c@1
> Bus 12: i2c@2
> Bus 13: i2c@3
> Bus 14: i2c@4
> Bus 15: i2c@5
> Bus 16: i2c@6
> Bus 17: i2c@7
>
> Signed-off-by: Michal Simek 
> ---
>
> Changes in v2:
> - Fix headers
> - Change patch description to focus only on bus name
>
>  drivers/i2c/muxes/i2c-mux-uclass.c | 29 ++---
>  1 file changed, 26 insertions(+), 3 deletions(-)

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


Re: [U-Boot] [RFC 2/3] efi_loader: associate BLK/PARTITION device to efi_disk

2019-02-02 Thread Simon Glass
Hi,

On Thu, 31 Jan 2019 at 22:53, AKASHI Takahiro
 wrote:
>
> Hi Simon,
>
> Thank you for suggestive comments.
> I've got no idea of making DM class for EFI protocol.
>
> On Wed, Jan 30, 2019 at 06:22:47PM -0700, Simon Glass wrote:
> > Hi AKASHI,
> >
> > On Mon, 28 Jan 2019 at 19:59, AKASHI Takahiro
> >  wrote:
> > >
> > > efi_disk_create() will initialize efi_disk attributes for each device,
> > > either UCLASS_BLK or UCLASS_PARTITION.
> > >
> > > Currently (temporarily), efi_disk_obj structure is embedded into
> > > blk_desc to hold efi-specific attributes.
> > >
> > > Signed-off-by: AKASHI Takahiro 
> > > ---
> > >  drivers/block/blk-uclass.c |   9 ++
> > >  drivers/core/device.c  |   3 +
> > >  include/blk.h  |  24 +
> > >  include/dm/device.h|   4 +
> > >  lib/efi_loader/efi_disk.c  | 192 ++---
> > >  5 files changed, 174 insertions(+), 58 deletions(-)
> > >
> >
> > I think the objective should be to drop the EFI data structures.
>
> More or less so, yes.
>
> > So your approach of just including them in DM structures seems about
> > right to me, as a short-term migration measure. Given the large amount
> > of code that has built up I don't think it is possible to do it any
> > other way.
>
> Right.
>
> > It is very unfortunate though.
> >
> > So basically migration could be something like this:
> >
> > 1. Move each of the EFI structs into the DM structs one by one
> > 2. Drop struct members that are not needed and can be calculated from DM 
> > members
> > 3. Update DM to have 1:1 uclasses for each EFI protocol
> > 4. Move all the protocol structs into the DM uclasses
> > 5. Whittle these down until they are just shells used by the API, with
> > everything going through normal DM calls
> >
> > Or would it be better to just start again and rewrite it with the
> > existing code as a base?
> >
> > Looking at it, efi_object is not very useful in DM. It contains two members:
> >
> > 1. link - linked list link, which devices already have, although we
> > don't have a single list of all them. Instead they are linked into
> > separate lists for each uclass
> >
> > 2. protocols - list of protocols. But DM devices support only one
> > protocol. Multiple protocols are handled using child devices. E.g a
> > UCLASS_PMIC device that supports UCLASS_GPIO, UCLASS_REGULATOR and
> > UCLASS_AUDIO_CODEC would have three children, one for each uclass. So
> > perhaps with EFI we should create a separate child for each protocol
> > in a similar way?
> >
> > Which comes back to the idea of creating an EFI child device for every
> > DM device. Perhaps instead we create one EFI child for each protocol
> > supported by the parent device?
>
> Well, "child device as a EFI protocol" is really workable, but
> I have some concerns:
> * Can a DM device be an abstract instance with no real hardware?

Yes we do that quite a bit. Even UCLASS_BLK is like this, if you think about it.

> * There may be two different types of "children" mixed for an EFI object
>- some physical hierarchy, say disk partitions for a raw disk
>- these EFI protocols
>   That is, for example, one raw disk has
>  - partition 1 has
>  - block io protocol
>  - device path protocol
>  - simple file system protocol
>  - partition 2 has
>  - block io protocol
>  - device path protocol
>  - simple file system protocol
>  - block io protocol
>  - device path protocol
> * device path protocol can be annoying as almost all devices (visible
>   to UEFI) have some sort of device path, while corresponding u-boot
>   notion is, say, "scsi 0:1" which only appears on command interfaces.

Yes. We could use the device path from concatenating device names from
all parents, perhaps. I've been thinking about adding that to the
command line as an option.

>
> I'm not sure if those concerns are acceptable.
>
> > Another point is that the operations supported by EFI should be in DM
> > operations structs. For example I think struct
> > efi_simple_text_output_protocol should have methods which call into
> > the corresponding uclass operations.
>
> I have no idea on those "console" devices yet.
>
> > It is confusing that an EFI disk is in fact a partition. Or do I have
> > that wrong?
>
> IMO, EFI disk is any type of EFI object which supports EFI_BLOCK_IO_PROTOCOL.
> So a raw disk(UCLASS_BLK) as well as its partitions(UCLASS_PARTITION) are
> EFI disks as well.
> Is this an answer to you?

Yes OK, I see.

>
> Those said, your suggestion is truly worth considering.

OK, good. Certainly an interesting project.

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


Re: [U-Boot] [PATCH] initcall: Move to inline function

2019-02-02 Thread Simon Glass
Hi Alex,

On Thu, 31 Jan 2019 at 08:06, Alexander Graf  wrote:
>
> The board_r init function was complaining that we are looping through
> an array, calling all our tiny init stubs sequentially via indirect
> function calls (which can't be speculated, so they are slow).

Is this a compiler warning? Could you let me know what this is?

>
> The solution to that is pretty easy though. All we need to do is inline
> the function that loops through the functions and the compiler will
> automatically convert almost all indirect calls into direct inlined code.

You mean it calls the functions one after the other without a
function-table array?

>
> With this patch, the overall code size drops (by 40 bytes on riscv64)
> and boot time should become measurably faster for every target.
>
> Signed-off-by: Alexander Graf 
> ---
>  common/board_r.c   |  5 +
>  include/initcall.h | 35 ++-
>  lib/Makefile   |  1 -
>  lib/initcall.c | 39 ---
>  4 files changed, 35 insertions(+), 45 deletions(-)
>  delete mode 100644 lib/initcall.c
>

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


Re: [U-Boot] [PATCH v2 0/7] Align U-Boot I2C DM bus ID handling with Linux

2019-02-02 Thread Simon Glass
Hi Michal,

On Thu, 31 Jan 2019 at 08:31, Michal Simek  wrote:
>
> U-Boot with I2C_DM enabled is not capable to list i2c busses connected
> to i2c mux. For getting this work there is a need to find out highest
> alias ID and use this uniq number for new buses connected to I2C mux.
> This series is making this happen.
>
> There is only one missing piece which is that also i2c controllers which
> are not listed in DT are not using this feature.
>
> Removing setting up aliases from i2c mux code and unifying it in the
> same code ensures that numbering schema is proper if no alias is
> specified.
>
> ZynqMP> i2c bus
> Bus 0:  i2c@ff02
>20: gpio@20, offset len 1, flags 0
>21: gpio@21, offset len 1, flags 0
>75: i2c-mux@75, offset len 1, flags 0
> Bus 1:  i2c@ff02->i2c-mux@75->i2c@0
> Bus 2:  i2c@ff02->i2c-mux@75->i2c@1
> Bus 3:  i2c@ff02->i2c-mux@75->i2c@2
> Bus 4:  i2c@ff03  (active 4)
>74: i2c-mux@74, offset len 1, flags 0
>75: i2c-mux@75, offset len 1, flags 0
> Bus 5:  i2c@ff03->i2c-mux@74->i2c@0  (active 5)
>54: eeprom@54, offset len 1, flags 0
> Bus 6:  i2c@ff03->i2c-mux@74->i2c@1
> Bus 7:  i2c@ff03->i2c-mux@74->i2c@2
> Bus 8:  i2c@ff03->i2c-mux@74->i2c@3
> Bus 9:  i2c@ff03->i2c-mux@74->i2c@4
> Bus 10: i2c@ff03->i2c-mux@75->i2c@0
> Bus 11: i2c@ff03->i2c-mux@75->i2c@1
> Bus 12: i2c@ff03->i2c-mux@75->i2c@2
> Bus 13: i2c@ff03->i2c-mux@75->i2c@3
> Bus 14: i2c@ff03->i2c-mux@75->i2c@4
> Bus 15: i2c@ff03->i2c-mux@75->i2c@5
> Bus 16: i2c@ff03->i2c-mux@75->i2c@6
> Bus 17: i2c@ff03->i2c-mux@75->i2c@7
>
> Thanks,
> Michal
>
> Changes in v2:
> - Update kernel-doc binding
> - Return -1 in case of error. -1 means that the next free alias is 0.
> - New patch
> - New patch
> - Use dev_read_alias_highest_id()
> - Use uclass private data
> - Use private uclass data
> - Fix headers
> - Change patch description to focus only on bus name

I don't have strong objections to this series, but I'd still like to
try a bit harder on the existing req_seq/seq stuff.

I don't think we necessarily need to set the 'seq' before probe,
although I suppose we could.

But is there anything to stop us moving some of the logic which sets
seq to setting req_seq? We could check the aliases and then set
req_seq during bind(), perhaps?

This would be better for code size since it would help all subsystems.

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


Re: [U-Boot] IMX6 NAND boot regression

2019-02-02 Thread Adam Ford
On Sat, Feb 2, 2019 at 12:29 AM Jagan Teki  wrote:
>
> +Adam, Shyam
>
> On Sat, 2 Feb, 2019, 8:49 AM Stefan Agner 
> > Hi Tim,
> >
> > On 02.02.19 03:32, Tim Harvey wrote:
> > > Stefan,
> > >
> > > I'm trying to track down an IMX6 SPL NAND boot regression that started
> > > in v2018.07 with your patch series to mxs_nand.
> >
> > I am sorry about that. Unfortunately I did not had a design at hand where
> > I was able to test the NAND driver in SPL...
> >
> > >
> > > I bisected it back to '5346c31e305a37d39f535cc0d5ae87d8b7e81230 mtd:
> > > nand: mxs_nand: use self init'. With this particular patch nand bbt
> > > scanning would crash the board because of nand_chip.scan_btt not being
> > > assigned. This was later fixed in
> > > '96d0be07e7498e7174daa6f3b56fc807b9feb71d MTD: nand: mxs_nand_spl: Fix
> > > empty function pointer for BBT' but cherry-picking that on top of
> > > 5346c31 fixes the immediate crash while scanning but then I find that
> > > mxs_read_page_ecc() hangs on the 4th page of reading u-boot.img from
> > > the NAND. This gets worse 2 patches later where in
> > > '28897e8d21f8e197e259a91c693de09cd81f2d5a: mtd: nand: mxs_nand: use
> > > structure for BCH geometry' I find that the first byte of every page
> > > read is wrong because mxs_nand_swap_block_mark() is getting called on
> > > the page which swaps the first bytes with oob.
> > >
> > > There are several IMX6 boards out there using both NAND and SPL I
> > > believe that I would assume were broken by this series. Any ideas on
> > > the proper resolution?
> >
>
> Look like 2017.03 can be stable boot from nand as for as my test is concern.
>
> We are also trying hard using git bisect, but seems like multiple breakings.
>
> Will keep posted if something move further.


From a different thread, someone was able to test these patches and
found they fixed their booting issues:

 There was a broken function pointer here that was fixed and applied
 the imx-master, but pending merge with master
 http://patchwork.ozlabs.org/patch/1019440/

 Configure ECC from SPL here:
 http://patchwork.ozlabs.org/patch/1020160/

 Remove hard-coded ECC parameters since the patch above can autoset them.
 http://patchwork.ozlabs.org/patch/1026638/

Maybe those can help.

adam


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


Re: [U-Boot] Nand boot on imx6q board is broken

2019-02-02 Thread Adam Ford
On Sat, Feb 2, 2019 at 5:17 AM Jörg Krause  wrote:
>
> Hi,
>
> On Thu, 2019-01-31 at 07:22 -0800, Adam Ford wrote:
> > On Wed, Jan 30, 2019 at 11:40 PM Shyam Saini  
> > wrote:
> > > Hi Everyone,
> > >
> > > I'm trying to boot imx6q board from nand but it seems like mainline
> > > u-boot nand boot support for imx6q board is broken.
> >
> > I spent some time trying to make the imx6q_logic board boot from SPL
> > from NAND, but I needed to patch a few things.   Some of them have yet
> > to be approved, but if they work for you, maybe it will help get them
> > approved.
> >
> > There was a broken function pointer here that was fixed and applied
> > the imx-master, but pending merge with master
> > http://patchwork.ozlabs.org/patch/1019440/
> >
> > Configure ECC from SPL here:
> > http://patchwork.ozlabs.org/patch/1020160/
> >
> > Remove hard-coded ECC parameters since the patch above can autoset them.
> > http://patchwork.ozlabs.org/patch/1026638/
> >
> > With those 3 patches and some minor changes to my individual board
> > file and config file, I was able to boot 2019.01 via SPL from NAND.
> > Since it was working for you before, I am guessing the board file
> > stuff and config file stuff is probably already for you.
> >
> > adam
>
> I can confirm that applying these three patches fixes booting from NAND
> on a custom i.MX6ULL board with Micron NAND flash.

Would you mind replaying to the various patch threads adding your 'tested-by'?

thanks
adam
>
> Jörg
>
> > > It is working till v2017.05 with this fix [1].
> > >
> > > I'm using this as my stub:
> > > https://github.com/openedev/u-boot-amarula/tree/icore-nand
> > >
> > >
> > >
> > > When I git bisect between v2017.05 and v2017.07, found this commit
> > > which is further breaking  the nand boot support:
> > > --
> > > ommit bc1fe9006dfaacc5103b5c7057a62215844957b7
> > > Author: Jagan Teki 
> > > Date:   Sun May 7 02:43:05 2017 +0530
> > >
> > > icorem6: Make SPL to pick suitable fdt
> > >
> > > SPL FIT is able to pick the suitable fdt file for u-boot,
> > > so add that function through board_fit_config_name_match.
> > >
> > > Cc: Stefano Babic 
> > > Cc: Matteo Lisi 
> > > Cc: Michael Trimarchi 
> > > Signed-off-by: Jagan Teki 
> > > -
> > > And It is fixed with this [2].
> > >
> > > In mainline u-boot we already  have fix [1] and [2] available but nand
> > > boot is still broken. It seems like problem is some where else, fix
> > > [1] and [2] are just making the bug appear less frequently.
> > >
> > > logs:
> > > [3] nand boot working
> > > [4] Nand boot not working
> > >
> > > Has anyone else faced or fixed the same issue on imx6 board.
> > > Please let me know.
> > >
> > >
> > > [1] https://paste.ubuntu.com/p/nKq7SNWDrn/
> > > [2] https://paste.ubuntu.com/p/tXqbx5dVPJ/
> > > [3] https://paste.ubuntu.com/p/DcBQ4gcSCM/
> > > [4] https://paste.ubuntu.com/p/WVtrqfdVQT/
> > >
> > >
> > > Thanks a lot,
> > > Shyam
> > > ___
> > > U-Boot mailing list
> > > U-Boot@lists.denx.de
> > > https://lists.denx.de/listinfo/u-boot
> > ___
> > U-Boot mailing list
> > U-Boot@lists.denx.de
> > https://lists.denx.de/listinfo/u-boot
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH] MTD: mxs_nand: Fix BCH read timeout error on boards requiring ECC

2019-02-02 Thread Jörg Krause
Hi,

On Thu, 2019-01-03 at 15:55 +, Stefan Agner wrote:
> [this time using reply to all]
> 
> On 03.01.19 03:36, Adam Ford wrote:
> > The LogicPD board uses a Micron Flash with ECC.  To boot this from
> > SPL, the ECC needs to be correctly configured or the BCH engine
> > times out.
> > 
> > Signed-off-by: Adam Ford 
> 
> Looks good to me,
> 
> Acked-by: Stefan Agner 

Tested on a custom i.MX6ULL board with Micron NAND flash.

Fixes:

"""
Trying to boot from NAND
MXS NAND: BCH read timeout
...
MXS NAND: BCH read timeout
"""

Tested-by: Jörg Krause 

> > diff --git a/drivers/mtd/nand/raw/mxs_nand.c 
> > b/drivers/mtd/nand/raw/mxs_nand.c
> > index e3341812a2..2d84bfffe2 100644
> > --- a/drivers/mtd/nand/raw/mxs_nand.c
> > +++ b/drivers/mtd/nand/raw/mxs_nand.c
> > @@ -1163,6 +1163,12 @@ int mxs_nand_init_spl(struct nand_chip *nand)
> >  
> > nand_info->gpmi_regs = (struct mxs_gpmi_regs *)MXS_GPMI_BASE;
> > nand_info->bch_regs = (struct mxs_bch_regs *)MXS_BCH_BASE;
> > +
> > +   if (is_mx6sx() || is_mx7())
> > +   nand_info->max_ecc_strength_supported = 62;
> > +   else
> > +   nand_info->max_ecc_strength_supported = 40;
> > +
> > err = mxs_nand_alloc_buffers(nand_info);
> > if (err)
> > return err;
> > diff --git a/drivers/mtd/nand/raw/mxs_nand_spl.c 
> > b/drivers/mtd/nand/raw/mxs_nand_spl.c
> > index c628f3adec..ba85baac60 100644
> > --- a/drivers/mtd/nand/raw/mxs_nand_spl.c
> > +++ b/drivers/mtd/nand/raw/mxs_nand_spl.c
> > @@ -201,6 +201,7 @@ static int mxs_nand_init(void)
> > /* setup flash layout (does not scan as we override that) */
> > mtd->size = nand_chip.chipsize;
> > nand_chip.scan_bbt(mtd);
> > +   mxs_nand_setup_ecc(mtd);
> >  
> > return 0;
> >  }
> > 

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


Re: [U-Boot] Nand boot on imx6q board is broken

2019-02-02 Thread Jörg Krause
Hi,

On Thu, 2019-01-31 at 07:22 -0800, Adam Ford wrote:
> On Wed, Jan 30, 2019 at 11:40 PM Shyam Saini  
> wrote:
> > Hi Everyone,
> > 
> > I'm trying to boot imx6q board from nand but it seems like mainline
> > u-boot nand boot support for imx6q board is broken.
> 
> I spent some time trying to make the imx6q_logic board boot from SPL
> from NAND, but I needed to patch a few things.   Some of them have yet
> to be approved, but if they work for you, maybe it will help get them
> approved.
> 
> There was a broken function pointer here that was fixed and applied
> the imx-master, but pending merge with master
> http://patchwork.ozlabs.org/patch/1019440/
> 
> Configure ECC from SPL here:
> http://patchwork.ozlabs.org/patch/1020160/
> 
> Remove hard-coded ECC parameters since the patch above can autoset them.
> http://patchwork.ozlabs.org/patch/1026638/
> 
> With those 3 patches and some minor changes to my individual board
> file and config file, I was able to boot 2019.01 via SPL from NAND.
> Since it was working for you before, I am guessing the board file
> stuff and config file stuff is probably already for you.
> 
> adam

I can confirm that applying these three patches fixes booting from NAND
on a custom i.MX6ULL board with Micron NAND flash.

Jörg

> > It is working till v2017.05 with this fix [1].
> > 
> > I'm using this as my stub:
> > https://github.com/openedev/u-boot-amarula/tree/icore-nand
> > 
> > 
> > 
> > When I git bisect between v2017.05 and v2017.07, found this commit
> > which is further breaking  the nand boot support:
> > --
> > ommit bc1fe9006dfaacc5103b5c7057a62215844957b7
> > Author: Jagan Teki 
> > Date:   Sun May 7 02:43:05 2017 +0530
> > 
> > icorem6: Make SPL to pick suitable fdt
> > 
> > SPL FIT is able to pick the suitable fdt file for u-boot,
> > so add that function through board_fit_config_name_match.
> > 
> > Cc: Stefano Babic 
> > Cc: Matteo Lisi 
> > Cc: Michael Trimarchi 
> > Signed-off-by: Jagan Teki 
> > -
> > And It is fixed with this [2].
> > 
> > In mainline u-boot we already  have fix [1] and [2] available but nand
> > boot is still broken. It seems like problem is some where else, fix
> > [1] and [2] are just making the bug appear less frequently.
> > 
> > logs:
> > [3] nand boot working
> > [4] Nand boot not working
> > 
> > Has anyone else faced or fixed the same issue on imx6 board.
> > Please let me know.
> > 
> > 
> > [1] https://paste.ubuntu.com/p/nKq7SNWDrn/
> > [2] https://paste.ubuntu.com/p/tXqbx5dVPJ/
> > [3] https://paste.ubuntu.com/p/DcBQ4gcSCM/
> > [4] https://paste.ubuntu.com/p/WVtrqfdVQT/
> > 
> > 
> > Thanks a lot,
> > Shyam
> > ___
> > U-Boot mailing list
> > U-Boot@lists.denx.de
> > https://lists.denx.de/listinfo/u-boot
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot

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


Re: [U-Boot] [PATCH v3 16/20] mtd: spi: Add lightweight SPI flash stack for SPL

2019-02-02 Thread Jagan Teki
On Fri, Feb 1, 2019 at 10:35 PM Vignesh R  wrote:
>
>
>
> On 01-Feb-19 9:18 PM, Jagan Teki wrote:
> > On Thu, Jan 31, 2019 at 11:20 PM Vignesh R  wrote:
> >>
> [...]
> >>>
> >>> This doesn't look good to me, this change is part of 08/20 and now it
> >>> removed. better do the same change in 08/20 by adding new file
> >>> spi-nor-ids.c
> >>>
> >>
> >> This is intentional. Patch 8-11 clearly shows what all is being sync'd
> >> from Kernel and I would like to keep that as is.
> >> Merging U-Boot specific changes with those patches does not provide a
> >> clean history
> >> spi-nor-ids table is moved out of spi-nor-core.c in this patch because
> >> we need it for two separate compilation units (spi-nor-tiny and
> >> spi-nor-core).
> >
> > Understand this point, but since it's not a direct commit sync and we
> > even add changes wrt u-boot and remove unneeded changes related to
> > Linux.
>
> This is a direct sync. I removed code not related to U-Boot on your
> insistence. But, code organization is same as Linux.
> I had no intention of splitting ID table into a separate file (see RFC
> v1 where it was still in the original file) as there was no other user
> of ID table and keeping table in same file allows compiler to carry out
> compile time optimizations.
>
> It's fine to create -ids.c file in the same commit, otherwise
> > it is simply adding code and removing the same in following commit
> > doesn't suit for bisectable.
> >
>
> Sorry, I do not agree on this.. This patch clearly captures the _need_
> to move ID table out of spi-nor-core.c. Code is being moved out of
> spi-nor-core.c to _support_ tiny stack. At no point in this series
> bisectablility is broken.
>
> Redoing patch 8/20 is non trivial and would be painful rework with no
> gain. I will have to rework patch 8/20 and 14/20 so as to not break
> compilation.

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


Re: [U-Boot] [PATCH v3 19/20] configs: Don't use SPI_FLASH_BAR as default

2019-02-02 Thread Jagan Teki
On Fri, Feb 1, 2019 at 10:38 PM Vignesh R  wrote:
>
> [...]
> >>> Yes, zynq qspi ia unable to handle larger than 16MiB flashes so we used
> >>> BAR to access those.
> >>>
> >>
> >> I wonder how those boards work in kernel that does not support BAR.
> >> Anyways, if you provide a list of SPI controllers on zynq SoCs, I will
> >> add an  imply SPI_FLASH_BAR for such Kconfigs and send a separate patch.
> >
> > for zynq_qspi driver used boards yes and other you can proceed at this 
> > moment.
> >
>
> You mean config ZYNQ_QSPI and config ZYNQMP_GQSPI need BAR support? I
> will send a follow up patch on top of this series

ZYNQ_QSPI as for as I know, rest don't require or supported.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v4 00/20] mx6sabre: Add DM and SPL FIT support

2019-02-02 Thread Fabio Estevam
Hi Abel,

On Fri, Feb 1, 2019 at 2:43 PM Abel Vesa  wrote:
>
> The third version is here:
> https://lists.denx.de/pipermail/u-boot/2019-January/356903.html
>
> So, this time I hope I got it right. Before, I was stupidly trying
> to put a fit in another fit without a really good reason. To my
> excuse, that was working even with the spl_image->os set to 0,
> bug which I (hope) I fixed in the first patch (a new one)
> of this series.

I am happy with the entire series.

One more question: do we get build error when the SPL gets larger than 64kB?
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v4 20/20] configs: mx6sabresd: Reduce SPL size by disabling DOS, EXT and EFI support

2019-02-02 Thread Fabio Estevam
On Fri, Feb 1, 2019 at 2:50 PM Abel Vesa  wrote:
>
> With DM and FIT enabled in SPL, there is an sram overflow. By disabling
> CONFIG_SPL_DOS_PARTITION, CONFIG_SPL_EXT_SUPPORT and
> CONFIG_SPL_EFI_PARTITION, we get to keep the 'one binary to fit all'
> for imx6[q|qp|dl] on sabresd since the final SPL image is now under 64KB.
>
> Signed-off-by: Abel Vesa 

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


Re: [U-Boot] [PATCH v4 19/20] board: mx6sabresd: Remove the enet reset gpio handling

2019-02-02 Thread Fabio Estevam
On Fri, Feb 1, 2019 at 2:53 PM Abel Vesa  wrote:
>
> Rely on the phy-reset-gpios which is set in imx6qdl-sabresd dtsi
> and get rid of the enet reset gpio handling from the board file.
>
> Signed-off-by: Abel Vesa 

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


Re: [U-Boot] [PATCH v4 18/20] board: mx6sabresd: Remove non-DM code

2019-02-02 Thread Fabio Estevam
On Fri, Feb 1, 2019 at 2:51 PM Abel Vesa  wrote:
>
> Since the mx6sabreauto has DM support, remove the unused non-DM code
> from mx6sabresd board file.
>
> Signed-off-by: Abel Vesa 

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


Re: [U-Boot] [PATCH v4 16/20] configs: mx6sabresd: Add DM_SPI_FLASH necessary configs

2019-02-02 Thread Fabio Estevam
On Fri, Feb 1, 2019 at 2:48 PM Abel Vesa  wrote:
>
> Enable all neceassary configs to support DM_SPI_FLASH on mx6sabresd.
>
> Signed-off-by: Abel Vesa 
> Reviewed-by: Peng Fan 

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


Re: [U-Boot] [PATCH v4 17/20] board: mx6sabreauto: Remove the non-DM code

2019-02-02 Thread Fabio Estevam
On Fri, Feb 1, 2019 at 2:50 PM Abel Vesa  wrote:
>
> Since the mx6sabreauto has DM support, remove the unused non-DM code
> from mx6sabreauto board file.
>
> Signed-off-by: Abel Vesa 

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


Re: [U-Boot] [PATCH v4 14/20] mx6sabresd: Add DM_GPIO support

2019-02-02 Thread Fabio Estevam
On Fri, Feb 1, 2019 at 2:46 PM Abel Vesa  wrote:
>
> Add the DM_GPIO related config for mx6sabresd.
> Also add the gpio request calls.
>
> Signed-off-by: Abel Vesa 
> Reviewed-by: Peng Fan 

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


Re: [U-Boot] [PATCH v4 15/20] configs: mx6sabreauto: Add DM_SPI_FLASH necessary configs

2019-02-02 Thread Fabio Estevam
On Fri, Feb 1, 2019 at 2:48 PM Abel Vesa  wrote:
>
> Enable all neceassary configs to support DM_SPI_FLASH on mx6sabreauto.
>
> Signed-off-by: Abel Vesa 
> Reviewed-by: Peng Fan 

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


Re: [U-Boot] [PATCH v4 13/20] mx6sabreauto: Add DM_GPIO support

2019-02-02 Thread Fabio Estevam
On Fri, Feb 1, 2019 at 2:49 PM Abel Vesa  wrote:
>
> Add the DM_GPIO related config for mx6sabreauto.
> Also add the gpio request calls.
>
> Signed-off-by: Abel Vesa 
> Reviewed-by: Peng Fan 

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


Re: [U-Boot] [PATCH v4 10/20] arm: dts: Update all the dts[i] files for imx6[q|qp|dl] sabre[auto|sd]

2019-02-02 Thread Fabio Estevam
On Fri, Feb 1, 2019 at 2:45 PM Abel Vesa  wrote:
>
> Update all the dts[i] files for imx6[q|qp|dl] sabre[auto|sd] to the ones
> from kernel v4.20 (commit 8fe28cb58bcb2).
>
> Signed-off-by: Abel Vesa 
> Acked-by: Peng Fan 

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


Re: [U-Boot] [PATCH v4 12/20] configs: mx6sabresd: Add SPL FIT and DM support

2019-02-02 Thread Fabio Estevam
On Fri, Feb 1, 2019 at 2:47 PM Abel Vesa  wrote:
>
> Enable all the necessary configs for SPL DM and FIT support for
> mx6sabresd.
>
> Signed-off-by: Abel Vesa 

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


Re: [U-Boot] [PATCH v4 11/20] configs: mx6sabreauto: Add SPL FIT and DM support

2019-02-02 Thread Fabio Estevam
On Fri, Feb 1, 2019 at 2:48 PM Abel Vesa  wrote:
>
> Enable all the necessary configs for SPL DM and FIT support for
> mx6sabreauto.
>
> Signed-off-by: Abel Vesa 

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


Re: [U-Boot] [PATCH v4 09/20] arm: dts: Add all the imx6[q|qp|dl] sabre[auto|sd] u-boot dts[i] files

2019-02-02 Thread Fabio Estevam
On Fri, Feb 1, 2019 at 2:46 PM Abel Vesa  wrote:
>
> This allows us to keep the basic dts[i] files up-to-date with
> the ones in kernel, but at the same time allowing the u-boot
> to add its own properties to the existing nodes.
>
> Signed-off-by: Abel Vesa 

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


Re: [U-Boot] [PATCH v4 08/20] board: mx6sabreauto: Add board_fit_config_name_match to support FIT in SPL

2019-02-02 Thread Fabio Estevam
On Fri, Feb 1, 2019 at 2:50 PM Abel Vesa  wrote:
>
> This matches one of the following three boards (or fails):
>  - imx6q-sabreauto
>  - imx6qp-sabreauto
>  - imx6dl-sabreauto
>
> Signed-off-by: Abel Vesa 
> Reviewed-by: Peng Fan 

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


Re: [U-Boot] [PATCH v4 07/20] board: mx6sabresd: Add board_fit_config_name_match to support FIT in SPL

2019-02-02 Thread Fabio Estevam
On Fri, Feb 1, 2019 at 2:50 PM Abel Vesa  wrote:
>
> This matches one of the following three boards (or fails):
>  - imx6q-sabresd
>  - imx6qp-sabresd
>  - imx6dl-sabresd
>
> Signed-off-by: Abel Vesa 
> Reviewed-by: Peng Fan 

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


Re: [U-Boot] [PATCH v4 06/20] mmc: fsl_esdhc: Fix DM_REGULATOR ifdefs for SPL builds

2019-02-02 Thread Fabio Estevam
On Fri, Feb 1, 2019 at 2:44 PM Abel Vesa  wrote:
>
> Since the fsl_esdhc will also be used by SPL, make the
> preprocessor switches more generic to allow any kind of build.
>
> Signed-off-by: Abel Vesa 

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


Re: [U-Boot] [PATCH v4 05/20] configs: imx6sabreauto: Add DM_USB support

2019-02-02 Thread Fabio Estevam
On Fri, Feb 1, 2019 at 2:47 PM Abel Vesa  wrote:
>
> Add the DM support for USB. For that, DM_REGULATOR is needed.
>
> Signed-off-by: Abel Vesa 

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


Re: [U-Boot] [PATCH v4 04/20] configs: imx6sabreauto: Add DM_MMC support

2019-02-02 Thread Fabio Estevam
On Fri, Feb 1, 2019 at 2:49 PM Abel Vesa  wrote:
>
> Add DM_MMC config to imx6sabreauto defconfig.
>
> Signed-off-by: Abel Vesa 

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


Re: [U-Boot] [PATCH v4 03/20] usb: ehci-mx6: Make regulator DM_REGULATOR dependent

2019-02-02 Thread Fabio Estevam
On Fri, Feb 1, 2019 at 2:47 PM Abel Vesa  wrote:
>
> Do the regulator related work only if the build has the DM_REGULATOR.
>
> Signed-off-by: Abel Vesa 
> Reviewed-by: Peng Fan 

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


Re: [U-Boot] [PATCH v4 01/20] common: spl_fit: Fix the spl_fit_image_get_os for FIT_IMAGE_TINY

2019-02-02 Thread Fabio Estevam
On Fri, Feb 1, 2019 at 2:50 PM Abel Vesa  wrote:
>
> There is not really reducing codesize here since there is only
> a call. The function is always built in if CONFIG_$(SPL_TPL_)FIT is set.
> Plus, there was a change in behavior if CONFIG_SPL_OS_BOOT is defined.
> If CONFIG_FIT_IMAGE_TINY is defined, the spl_fit_image_get_os was
> returning -ENOTSUPP and then if CONFIG_SPL_OS_BOOT was also
> defined, the spl_image->os was left set to 0 which in turn
> was skipping the fdt appending resulting in boot-up failure.
>
> Fixes: 337bbb6297775e spl: fit: add SPL_FIT_IMAGE_TINY config to reduce 
> code-size
> Signed-off-by: Abel Vesa 

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


Re: [U-Boot] [PATCH v4 02/20] usb: Rename SPL_USB_SUPPORT to SPL_USB_STORAGE

2019-02-02 Thread Fabio Estevam
On Fri, Feb 1, 2019 at 2:48 PM Abel Vesa  wrote:
>
> Since there is the SPL_USB_HOST_SUPPORT for enabling USB support in SPL,
> makes more sense to rename the SPL_USB_SUPPORT as SPL_USB_STORAGE.
> Everything that is not part of the usb storage support in SPL is now
> build under SPL_USB_HOST_SUPPORT.
>
> Signed-off-by: Abel Vesa 
> Reviewed-by: Tom Rini 

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


  1   2   >