Re: [U-Boot] [PATCH v2 0/7] mmc: sunxi: Enable DM_MMC

2019-01-18 Thread Jagan Teki
On Fri, Jan 18, 2019 at 11:18 PM Andre Przywara  wrote:
>
> On Fri, 18 Jan 2019 22:11:36 +0530
> Jagan Teki  wrote:
>
> Hi,
>
> > On Fri, Jan 18, 2019 at 6:00 PM Andre Przywara
> >  wrote:
> > >
> > > On Fri, 18 Jan 2019 07:17:41 -0500
> > > Tom Rini  wrote:
> > >
> > > > On Fri, Jan 18, 2019 at 11:53:49AM +, Andre Przywara wrote:
> > > > > On Thu, 17 Jan 2019 22:39:44 +0530
> > > > > Jagan Teki  wrote:
> > > > >
> > > > > > V2 for previous version[1] changes, for enabling DM_MMC
> > > > > > on Allwinner platform.
> > > > >
> > > > > So this is a neat and simple solution to the DM_MMC problem, to
> > > > > the point where I am wondering why we actually need all those
> > > > > DT driven clock and reset drivers in the first place.
> > > > > But as I understand using plat data in this way is somewhat
> > > > > frowned upon and considered deprecated (although it makes a lot
> > > > > of sense in this context).
> > > > >
> > > > > Also, isn't this series independent from the clock gates/reset
> > > > > patches? So why do you pile them on top of each other in
> > > > > sunxi/next?
> > > > >
> > > > > If we really want to have the full featured DT driven clock and
> > > > > reset support, why not use it together:
> > > > > We keep the current mod clock support in the MMC driver, but
> > > > > use the newly introduced clock gates and reset support via the
> > > > > new clock driver, mostly replacing this series. This would give
> > > > > us some test coverage of the new clock driver, while still
> > > > > avoiding to rush the MMC mod clock implementation.
> > > > >
> > > > > Does that make sense? Happy to bake some patches for that on the
> > > > > weekend.
> > > > >
> > > > > Btw: After talking to Tom on IRC, the DM_MMC deadline is
> > > > > actually _after_ the 2019.04 release, so we don't need to have
> > > > > DM_MMC support in this merge window.
> > > >
> > > > To be clearer, I plan to mark as BROKEN and start saying we're
> > > > going to remove stuff that isn't migrated, after the release.  So
> > > > it would be good to get things moved this release that can be
> > > > moved this release. Trying to use sunxi w/o MMC isn't going to be
> > > > fun :)
> > >
> > > Understood. I just gave it a quick try and it is actually quite
> > > easy: We are pretty good already regarding gate clocks and resets,
> > > with the new DM_CLK driver (v2 on the list). And using them in
> > > sunxi_mmc.c is a piece of cake and very clean.
> > > We just need to keep the MMC mod clock hack in (which this series
> > > here does as well), but can still enable DM_MMC.
> > > And for the next merge window we can tackle this by implementing the
> > > MMC mod clock properly in the clock driver, then replacing the hack
> > > with the normal clk_get_by_name(); clk_set_rate(); sequence.
> >
> > I tried with ahb clock and reset, with v2 version of CLK series and
> > it's straightforward. but mmc clock may take some time along with
> > series of testing. So I just windup this, instead of making some noise
> > at last minute.
>
> What do you mean with that, exactly?
> Do you plan to take your platdata hack for 2019.04?
> I don't like the idea of hacking something up that has no future and
> will be reverted very soon anyway. Instead we should expose the
> foundation part of the clock driver to people now for testing (as you
> did by pushing it, thanks!), but including the MMC gates and resets.
> I have this code ready, just need to test it on some SoCs this evening.
>
> I think taking this change is the best compromise between changing
> not too many things at once, yet still exposing new code to the users
> for testing.
>
> And yes, the MMC mod clock is somewhat of a beast, but if we have
> just this in the next release, it should be easier to debug than when
> we expose the whole of the new clock framework to MMC by then only.

This is I was thinking too, in fact I have created next version wrt
CLK support which may override your recent changes. May be I can
prepare and by combining both. what do you say?
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH] ARM: at91: Convert SPL_GENERATE_ATMEL_PMECC_HEADER to Kconfig

2019-01-18 Thread Derald D. Woods
On Fri, Jan 18, 2019 at 08:37:48AM +, eugen.hris...@microchip.com wrote:
> 
> 
> On 11.01.2019 18:53, Derald Woods wrote:
> > 
> > 
> > On Fri, Jan 11, 2019, 10:51 AM Derald Woods  >  wrote:
> > 
> > 
> > On Fri, Jan 11, 2019, 5:27 AM  >  wrote:
> > 
> > 
> > 
> > On 10.01.2019 03:00, Derald Woods wrote:
> >  > On Mon, Jan 7, 2019 at 3:40 AM  > 
> >  >  > >> wrote:
> >  >
> >  >     Hi Derald,
> >  >
> >  >     Thank you for the patch,
> >  >
> >  >     Some minor questions inline.
> >  >
> >  >
> >  >
> >  > Sorry for the late response. Family and day job take priority.
> >  >
> >  > The patch is the simplest technical conversion that I could
> > produce with
> >  > my board (SAMA5D3-XPLD) as the test platform. I was very
> > careful not to
> >  > touch anything unrelated. It is not intended to address
> > permutations
> >  > outside of the PMECC Kconfig scope. I have submitted these
> > type of
> >  > conversions to U-Boot in the past. Adding speculative things
> > is risky
> >  > when you only have one development board. The patch works
> > well, for me,
> >  > and addresses the original need. All items, in the patch, are
> > currently
> >  > in scope. If there are additions and/or modifications, feel
> > free to
> >  > modify the patch. It is complete from my perspective. I do
> > not have any
> >  > additional time to chase this any further. I have been
> > developing for
> >  > some time now and can handle an 'out of tree' patch, in my
> > environment,
> >  > until something better comes along. This patch is just my
> > contribution
> >  > to the process.
> > 
> > Hello Derald,
> > 
> >   From my point of view the PMECC header generation for SPL
> > should be
> > done if and only if the SPL is being placed in NAND flash namely
> > defconfigs having *nandflash* in the name.
> > 
> > Thus I disagree with enabling it on spiflash configurations
> > (like you
> > did for the *mmc* configurations looks OK)
> > 
> > 
> > The patch is about 'one' thing. Kconfig conversion. Things that you
> > are mentioning do not invalidate my patch. I tried not to add things
> > that were not there originally. That is generally discouraged scope
> > creep. The patch does its job in a provable manner with
> > 
> > 
> > 'without'
> > 
> > changing existing usage.
> 
> 
> Ok, I understand your point.
> Can you make the CONFIG_SPL_GENERATE_ATMEL_PMECC_HEADER depend on 
> NAND_BOOT though ? This way the errors cannot happen again.
> 


I agree.


> Also the other defconfigs need to depend on NAND if they are strict NAND 
> related.
> 


But are the existing configs that enable both SPL_GENERATE_ATMEL_PMECC_HEADER
and SPI_BOOT really valid?

It would appear that those entries may just be placeholders in the event
that an end-user enabled PMECC and NAND_BOOT for that particular board.

I could rework the patch to remove PMECC items from non-NAND_BOOT
configs. Comments could be used to preserve previous values. Does this sound
reasonable?

Additionally, I would make ATMEL_NAND_HW_PMECC dependent on ATMEL_NAND_HWECC
as it should be.

I can only test on the SAMA5D3-XPLD board.

Derald


> Maybe we can get more opinions from someone more familiar with the NAND 
> subsystem ? Adding Miquel and Boris.
> 
> Thanks,
> 
> Eugen
> 
> > 
> > Derald
> > 
> > 
> > If you have any reasons or arguments , or anyone else does, please
> > correct me.
> > 
> > If you do not have time to change the patch, that is OK, I can
> > take over
> > at some point when I have the time or someone else can pick and
> > rework a
> > little bit on that specific point and make a v2.
> > 
> > Thanks again,
> > 
> > Eugen
> > 
> >  >
> >  > Cheers,
> >  >
> >  > Derald
> >  >
> >  >
> >  >     On 15.12.2018 09:36, Derald D. Woods wrote:
> >  >      > This commit converts the following items to Kconfig:
> >  >      >
> >  >      > CONFIG_ATMEL_NAND_HWECC
> >  >      > CONFIG_ATMEL_NAND_HW_PMECC
> >  >      > CONFIG_PMECC_CAP
> >  >      > CONFIG_PMECC_SECTOR_SIZE
> >  >      > CONFIG_SPL_GENERATE_ATMEL_PMECC_HEADER
> >  >      >
> >  >      > [PMECC References]
> >  >      >
> > https://www.at91.com/linux4sam/bin/view/Linux4SAM/PmeccConfigure
> >  >   

Re: [U-Boot] arm: am335x-pdu001: Remove SPI support

2019-01-18 Thread Tom Rini
On Thu, Jan 17, 2019 at 10:40:42AM +0100, Felix Brack wrote:

> On this board SPI is only used to configure the SoC driving the LC TFT
> display which is not used in U-Boot. Hence remove SPI support.
> 
> Signed-off-by: Felix Brack 

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,2/2] travis: Switch QEMU to 3.1.0 version

2019-01-18 Thread Tom Rini
On Wed, Jan 16, 2019 at 03:18:44PM +0100, Michal Simek wrote:

> Vexpress ca15_tc2 is failing with 3.1.0 because of QEMU issue.
> When this patch is applied
> https://patchwork.kernel.org/patch/10754401/
> Vexpress can be also turn to newer QEMU version.
> 
> Signed-off-by: Michal Simek 
> 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] configs: Remove unused am335x_evm defconfigs

2019-01-18 Thread Tom Rini
On Wed, Jan 16, 2019 at 02:38:04PM +0530, Vignesh R wrote:

> These defconfigs don't seem be actively used any more, and have not been
> moved to adapt DM or DT. Therefore delete them.
> 
> Signed-off-by: Vignesh R 
> 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] env: sf: fix environment in SPI NOR

2019-01-18 Thread Tom Rini
On Fri, Jan 18, 2019 at 10:45:56AM +0100, Heiko Schocher wrote:

> commit 9a9d66f5eff0 ("env: add spi_flash_read_env function")
> 
> breaks Environment functionality, as it reads only
> until 2 \0 are found, but fills the buffer with 0x0
> instead 0xff which leads in an incorrect crc sum.
> 
> Fix: init the read buffer with 0xff instead 0x00
> 
> 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] arm: dts: am335x-pdu001: Sync with Linux 5.0-rc2

2019-01-18 Thread Tom Rini
On Thu, Jan 17, 2019 at 11:51:09AM +0100, Felix Brack wrote:

> This patch synchronizes the PDU001 board DTS file with the one used by
> Linux 5.0-rc2.
> Signed-off-by: Felix Brack 

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] configs: am335x_evm: Enable DM_SPI and DM_SPI_FLASH

2019-01-18 Thread Tom Rini
On Wed, Jan 16, 2019 at 12:16:11PM +0530, Vignesh R wrote:

> Enable DM_SPI and DM_SPI_FLASH for actively used defconfigs for
> am335x_evm.
> 
> Signed-off-by: Vignesh R 

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] mkimage: fixup CONFIG_FIT_EXTERNAL_OFFSET

2019-01-18 Thread Tom Rini
On Tue, Jan 15, 2019 at 04:34:19PM +0100, Patrick Wildt wrote:

> The last parameter is expected to be the imagefile.  Since -E is a
> flag having the output name before -p will make mkimage ignore the
> external offset option.
> 
> Signed-off-by: Patrick Wildt 

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] travis: Break up the NXP Layerscape jobs more

2019-01-18 Thread Tom Rini
On Wed, Jan 16, 2019 at 07:19:26AM -0500, Tom Rini wrote:

> The single job for all Layerscape 10xx platforms is close to, and
> sometimes exceeds the time limit for a single job configuration.  Break
> this down into jobs for LS101x, LS104x and LS108x instead.
> 
> Signed-off-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,08/10] pinctrl: Kconfig: spelling fixes

2019-01-18 Thread Tom Rini
On Sun, Jan 13, 2019 at 10:13:26PM +1300, Chris Packham wrote:

> Signed-off-by: Chris Packham 
> 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] cmd: mtd: fix compilation warning for help when SYS_LONGHELP=n

2019-01-18 Thread Tom Rini
On Thu, Jan 17, 2019 at 10:18:47AM +0100, Quentin Schulz wrote:

> cmd/mtd.c:447:13: warning: ‘mtd_help_text’ defined but not used 
> [-Wunused-variable]
> static char mtd_help_text[] =
> ^
> 
> When SYS_LONGHELP is not defined. After looking at how other commands
> work, we should surround the whole help text (even its declaration) with
> an #ifdef CONFIG_SYS_LONGHELP, since it's compiled out when calling
> _CMD_HELP[1] on the help text variable argument to U_BOOT_CMD.
> 
> [1] https://elixir.bootlin.com/u-boot/latest/source/include/command.h#L181
> 
> Signed-off-by: Quentin Schulz 
> Reviewed-by: Miquel Raynal 

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,v3] adding saveenv-command for bananapi r2

2019-01-18 Thread Tom Rini
On Tue, Jan 15, 2019 at 06:49:06PM +0100, Frank Wunderlich wrote:

> bananapi r2 can be booted from sd-card and emmc
> saving the environment have to choose the storage
> from which the device has booted
> 
> also the offset is set to 1MB to make sure env is written
> to block "user data area" between uboot and first partition
> 
> https://www.fw-web.de/dokuwiki/lib/exe/fetch.php?cache==bpi-r2:boot-structure.png
> 
> v3: using generated defconfig
> v2: fixed bracket-style in if-else statement
> 
> Signed-off-by: Frank Wunderlich 

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] travis: Setup QEMU_VERSION as variable

2019-01-18 Thread Tom Rini
On Wed, Jan 16, 2019 at 03:18:43PM +0100, Michal Simek wrote:

> This change enables setting up specific Qemu version or sha1 for new
> targets which are added after (current) v3.0.0 version.
> This changes is preparation step for adding new Xilinx Versal Virt
> platform which was merge after v3.0.0.
> 
> Signed-off-by: Michal Simek 
> Reviewed-by: Bin Meng 
> 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] configs: Remove am43xx_evm_ethboot_defconfig

2019-01-18 Thread Tom Rini
On Wed, Jan 16, 2019 at 02:54:36PM +0530, Vignesh R wrote:

> am43xx_evm_ethboot_defconfig is not being actively used and has not been
> moved to DM or DT. Also, ethboot cannot be tested on AM43xx EVM as such
> due EVM limitations. Therefore delete it.
> 
> Signed-off-by: Vignesh R 
> 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] configs: Remove am335x_boneblack_defconfig

2019-01-18 Thread Tom Rini
On Thu, Jan 17, 2019 at 03:44:06PM +0530, Faiz Abbas wrote:

> The am335x_evm_defconfig supports all am335x_boneblack variants. Remove
> the redundant am335x_boneblack_defconfig.
> 
> Signed-off-by: Faiz Abbas 
> 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,01/10] Kconfig: fix spelling

2019-01-18 Thread Tom Rini
On Sun, Jan 13, 2019 at 10:13:19PM +1300, Chris Packham wrote:

> Signed-off-by: Chris Packham 
> 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,10/10] lib: Kconfig: spelling fixes

2019-01-18 Thread Tom Rini
On Sun, Jan 13, 2019 at 10:13:28PM +1300, Chris Packham wrote:

> Signed-off-by: Chris Packham 
> 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,05/10] work_92105: Kconfig: spelling fixes

2019-01-18 Thread Tom Rini
On Sun, Jan 13, 2019 at 10:13:23PM +1300, Chris Packham wrote:

> Signed-off-by: Chris Packham 

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,06/10] drivers: Kconfig: spelling fixes

2019-01-18 Thread Tom Rini
On Sun, Jan 13, 2019 at 10:13:24PM +1300, Chris Packham wrote:

> Signed-off-by: Chris Packham 
> 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,04/10] x86: Kconfig: spelling fixes

2019-01-18 Thread Tom Rini
On Sun, Jan 13, 2019 at 10:13:22PM +1300, Chris Packham wrote:

> Signed-off-by: Chris Packham 
> 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,03/10] arm: Kconfig: spelling fixes

2019-01-18 Thread Tom Rini
On Sun, Jan 13, 2019 at 10:13:21PM +1300, Chris Packham wrote:

> Signed-off-by: Chris Packham 

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,07/10] i2c: Kconfig: spelling fixes

2019-01-18 Thread Tom Rini
On Sun, Jan 13, 2019 at 10:13:25PM +1300, Chris Packham wrote:

> Signed-off-by: Chris Packham 

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,09/10] video: Kconfig: spelling fixes

2019-01-18 Thread Tom Rini
On Sun, Jan 13, 2019 at 10:13:27PM +1300, Chris Packham wrote:

> Signed-off-by: Chris Packham 
> Reviewed-by: Anatolij Gustschin 
> Reviewed-by: Philipp Tomsich 

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,1/1] disk: efi: GUIDs should be const

2019-01-18 Thread Tom Rini
On Sat, Jan 12, 2019 at 11:25:25AM +0100, Heinrich Schuchardt wrote:

> Make system_guid const.
> 
> Signed-off-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,02/10] common: spl: Kconfig: spelling fixes

2019-01-18 Thread Tom Rini
On Sun, Jan 13, 2019 at 10:13:20PM +1300, Chris Packham wrote:

> Signed-off-by: Chris Packham 
> 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, 2/2] mach-snapdragon: db410: pinctrl: fix pin count

2019-01-18 Thread Tom Rini
On Sat, Jan 12, 2019 at 11:48:28AM +0200, Ramon Fried wrote:

> Pin count in APQ8016 was wrong, fix that.
> 
> Fixes: ad97051b7ff6 ("mach-snapdragon: Introduce pinctrl driver")
> Signed-off-by: Ramon Fried 

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,1/2] dts: db410: fix indentation

2019-01-18 Thread Tom Rini
On Sat, Jan 12, 2019 at 11:48:27AM +0200, Ramon Fried wrote:

> Signed-off-by: Ramon Fried 

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 4/9] mmc: sunxi: Add H6 support

2019-01-18 Thread Andre Przywara
Even though the H6 MMC device is fully compatible to the A64
implementation, we need to differentiate between the two, as the mod
clock is on a different address, and we don't use the DT for that yet.

Add a separate "variant" which just holds the different MMIO address.

Signed-off-by: Andre Przywara 
---
 drivers/mmc/sunxi_mmc.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c
index 35cdccdd7f..16646012bc 100644
--- a/drivers/mmc/sunxi_mmc.c
+++ b/drivers/mmc/sunxi_mmc.c
@@ -688,6 +688,10 @@ static const struct sunxi_mmc_variant sun4i_a10_variant = {
.mclk_offset = 0x88,
 };
 
+static const struct sunxi_mmc_variant sun50i_h6_variant = {
+   .mclk_offset = 0x830,
+};
+
 static const struct udevice_id sunxi_mmc_ids[] = {
{
  .compatible = "allwinner,sun4i-a10-mmc",
@@ -701,6 +705,14 @@ static const struct udevice_id sunxi_mmc_ids[] = {
  .compatible = "allwinner,sun7i-a20-mmc",
  .data = (ulong)_a10_variant,
},
+   {
+ .compatible = "allwinner,sun50i-h6-mmc",
+ .data = (ulong)_h6_variant,
+   },
+   {
+ .compatible = "allwinner,sun50i-h6-emmc",
+ .data = (ulong)_h6_variant,
+   },
{ /* sentinel */ }
 };
 
-- 
2.14.5

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


[U-Boot] [PATCH 7/9] mmc: sunxi: Honour non-removable property in DT

2019-01-18 Thread Andre Przywara
If a board DT describes a cd-gpios property, but also marks the storage
as non-removable, we must ignore the GPIO (as Linux does).

Teach the DM_MMC part of the Allwinner MMC driver about the
non-removable DT property, to fix DM_MMC access on the SoPine and
Pine64-LTS board.

Signed-off-by: Andre Przywara 
---
 drivers/mmc/sunxi_mmc.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c
index 87424c23dc..374775194d 100644
--- a/drivers/mmc/sunxi_mmc.c
+++ b/drivers/mmc/sunxi_mmc.c
@@ -658,7 +658,8 @@ static int sunxi_mmc_probe(struct udevice *dev)
return ret;
 
/* This GPIO is optional */
-   if (!gpio_request_by_name(dev, "cd-gpios", 0, >cd_gpio,
+   if (!dev_read_bool(dev, "non-removable") &&
+   !gpio_request_by_name(dev, "cd-gpios", 0, >cd_gpio,
  GPIOD_IS_IN)) {
int cd_pin = gpio_get_number(>cd_gpio);
 
-- 
2.14.5

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


[U-Boot] [PATCH 9/9] mmc: sunxi: Mark end of DM_MMC #ifdefs

2019-01-18 Thread Andre Przywara
The Allwinner MMC supports both the legacy approach and the driver model,
at the cost of quite some #ifdefs.

Mark the closing #endifs with their respective config symbol, to make it
more obvious where each part ends and begins.

Signed-off-by: Andre Przywara 
---
 drivers/mmc/sunxi_mmc.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c
index 374775194d..ee0bc9da89 100644
--- a/drivers/mmc/sunxi_mmc.c
+++ b/drivers/mmc/sunxi_mmc.c
@@ -104,7 +104,7 @@ static int mmc_resource_init(int sdc_no)
 
return ret;
 }
-#endif
+#endif /* !DM_MMC */
 
 static int mmc_set_mod_clk(struct sunxi_mmc_priv *priv, unsigned int hz)
 {
@@ -566,7 +566,7 @@ struct mmc *sunxi_mmc_init(int sdc_no)
 
return mmc_create(cfg, priv);
 }
-#else
+#else  /* DM_MMC */
 
 static int sunxi_mmc_set_ios(struct udevice *dev)
 {
@@ -747,4 +747,4 @@ U_BOOT_DRIVER(sunxi_mmc_drv) = {
.platdata_auto_alloc_size = sizeof(struct sunxi_mmc_plat),
.priv_auto_alloc_size = sizeof(struct sunxi_mmc_priv),
 };
-#endif
+#endif /* DM_MMC */
-- 
2.14.5

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


[U-Boot] [PATCH 3/9] mmc: sunxi: Add DM clk and reset support

2019-01-18 Thread Andre Przywara
Now that we have the gate clocks and the reset gates in our new
Allwinner clock driver, let's make use of them in the MMC driver, when
DM_MMC is defined.
We treat the reset device as optional now, as the older SoCs don't
implement it.

Signed-off-by: Andre Przywara 
---
 drivers/mmc/sunxi_mmc.c | 18 +-
 1 file changed, 13 insertions(+), 5 deletions(-)

diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c
index 302332bf97..35cdccdd7f 100644
--- a/drivers/mmc/sunxi_mmc.c
+++ b/drivers/mmc/sunxi_mmc.c
@@ -12,6 +12,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -21,7 +23,6 @@
 
 #ifdef CONFIG_DM_MMC
 struct sunxi_mmc_variant {
-   u16 gate_offset;
u16 mclk_offset;
 };
 #endif
@@ -607,9 +608,11 @@ static int sunxi_mmc_probe(struct udevice *dev)
struct mmc_uclass_priv *upriv = dev_get_uclass_priv(dev);
struct sunxi_mmc_plat *plat = dev_get_platdata(dev);
struct sunxi_mmc_priv *priv = dev_get_priv(dev);
+   struct reset_ctl_bulk reset_bulk;
+   struct clk gate_clk;
struct mmc_config *cfg = >cfg;
struct ofnode_phandle_args args;
-   u32 *gate_reg, *ccu_reg;
+   u32 *ccu_reg;
int bus_width, ret;
 
cfg->name = dev->name;
@@ -641,8 +644,14 @@ static int sunxi_mmc_probe(struct udevice *dev)
priv->mmc_no = ((uintptr_t)priv->reg - SUNXI_MMC0_BASE) / 0x1000;
priv->mclkreg = (void *)ccu_reg +
(priv->variant->mclk_offset + (priv->mmc_no * 4));
-   gate_reg = (void *)ccu_reg + priv->variant->gate_offset;
-   setbits_le32(gate_reg, BIT(AHB_GATE_OFFSET_MMC(priv->mmc_no)));
+
+   ret = clk_get_by_name(dev, "ahb", _clk);
+   if (!ret)
+   clk_enable(_clk);
+
+   ret = reset_get_bulk(dev, _bulk);
+   if (!ret)
+   reset_deassert_bulk(_bulk);
 
ret = mmc_set_mod_clk(priv, 2400);
if (ret)
@@ -676,7 +685,6 @@ static int sunxi_mmc_bind(struct udevice *dev)
 }
 
 static const struct sunxi_mmc_variant sun4i_a10_variant = {
-   .gate_offset = 0x60,
.mclk_offset = 0x88,
 };
 
-- 
2.14.5

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


[U-Boot] [PATCH 6/9] mmc: sunxi: Add A80 support

2019-01-18 Thread Andre Przywara
Add the Allwinner A80 mod clock address and bind it to its compatible
string. The special config clock is handled via the clock driver.

Signed-off-by: Andre Przywara 
---
 drivers/mmc/sunxi_mmc.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c
index 62b658c435..87424c23dc 100644
--- a/drivers/mmc/sunxi_mmc.c
+++ b/drivers/mmc/sunxi_mmc.c
@@ -692,6 +692,10 @@ static const struct sunxi_mmc_variant sun50i_h6_variant = {
.mclk_offset = 0x830,
 };
 
+static const struct sunxi_mmc_variant sun9i_a80_variant = {
+   .mclk_offset = 0x410,
+};
+
 static const struct udevice_id sunxi_mmc_ids[] = {
{
  .compatible = "allwinner,sun4i-a10-mmc",
@@ -709,6 +713,10 @@ static const struct udevice_id sunxi_mmc_ids[] = {
  .compatible = "allwinner,sun8i-a83t-emmc",
  .data = (ulong)_a10_variant,
},
+   {
+ .compatible = "allwinner,sun9i-a80-mmc",
+ .data = (ulong)_a80_variant,
+   },
{
  .compatible = "allwinner,sun50i-a64-mmc",
  .data = (ulong)_a10_variant,
-- 
2.14.5

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


[U-Boot] [PATCH 8/9] arm: sunxi: Enable DM_MMC

2019-01-18 Thread Andre Przywara
From: Jagan Teki 

Enable DM_MMC for all Allwinner SoCs, this will eventually
enable BLK.

Also removed DM_MMC enablement in few parts of sunxi
configurations.

Signed-off-by: Jagan Teki 
Signed-off-by: Andre Przywara 
---
 arch/arm/Kconfig  | 1 +
 arch/arm/mach-sunxi/Kconfig   | 1 -
 configs/Linksprite_pcDuino3_defconfig | 1 -
 3 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index a23cbd5719..075c3dfe81 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -851,6 +851,7 @@ config ARCH_SUNXI
select DM_ETH
select DM_GPIO
select DM_KEYBOARD
+   select DM_MMC if MMC
select DM_SERIAL
select DM_USB if DISTRO_DEFAULTS
select OF_BOARD_SETUP
diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
index 3c54f5106d..74e234cded 100644
--- a/arch/arm/mach-sunxi/Kconfig
+++ b/arch/arm/mach-sunxi/Kconfig
@@ -154,7 +154,6 @@ config MACH_SUN4I
bool "sun4i (Allwinner A10)"
select CPU_V7A
select ARM_CORTEX_CPU_IS_UP
-   select DM_MMC if MMC
select DM_SCSI if SCSI
select PHY_SUN4I_USB
select DRAM_SUN4I
diff --git a/configs/Linksprite_pcDuino3_defconfig 
b/configs/Linksprite_pcDuino3_defconfig
index 9156f132d1..18f658e96b 100644
--- a/configs/Linksprite_pcDuino3_defconfig
+++ b/configs/Linksprite_pcDuino3_defconfig
@@ -14,7 +14,6 @@ CONFIG_SPL_I2C_SUPPORT=y
 # CONFIG_SPL_EFI_PARTITION is not set
 CONFIG_DEFAULT_DEVICE_TREE="sun7i-a20-pcduino3"
 CONFIG_SCSI_AHCI=y
-CONFIG_DM_MMC=y
 CONFIG_ETH_DESIGNWARE=y
 CONFIG_MII=y
 CONFIG_SUN7I_GMAC=y
-- 
2.14.5

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


[U-Boot] [PATCH 2/9] sunxi: clk: A80: add MMC clock support

2019-01-18 Thread Andre Przywara
The A80 handles resets and clock gates for the MMC devices differently,
outside of the CCU IP block. Consequently we have a separate clock
device with a separate binding for that.

Implement that with the respective clock gates and resets to allow the
A80 taking part in the DM_MMC game.

Signed-off-by: Andre Przywara 
---
 drivers/clk/sunxi/clk_a80.c | 28 +++-
 1 file changed, 27 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/sunxi/clk_a80.c b/drivers/clk/sunxi/clk_a80.c
index d6dd6a1fa1..2bfc2ca9f5 100644
--- a/drivers/clk/sunxi/clk_a80.c
+++ b/drivers/clk/sunxi/clk_a80.c
@@ -30,19 +30,45 @@ static const struct ccu_reset a80_resets[] = {
[RST_BUS_UART5] = RESET(0x5b4, BIT(21)),
 };
 
+static const struct ccu_clk_gate a80_mmc_gates[] = {
+   [0] = GATE(0x0, BIT(16)),
+   [1] = GATE(0x4, BIT(16)),
+   [2] = GATE(0x8, BIT(16)),
+   [3] = GATE(0xc, BIT(16)),
+};
+
+static const struct ccu_reset a80_mmc_resets[] = {
+   [0] = GATE(0x0, BIT(18)),
+   [1] = GATE(0x4, BIT(18)),
+   [2] = GATE(0x8, BIT(18)),
+   [3] = GATE(0xc, BIT(18)),
+};
+
 static const struct ccu_desc a80_ccu_desc = {
.gates = a80_gates,
.resets = a80_resets,
 };
 
+static const struct ccu_desc a80_mmc_clk_desc = {
+   .gates = a80_mmc_gates,
+   .resets = a80_mmc_resets,
+};
+
 static int a80_clk_bind(struct udevice *dev)
 {
-   return sunxi_reset_bind(dev, ARRAY_SIZE(a80_resets));
+   ulong count = ARRAY_SIZE(a80_resets);
+
+   if (device_is_compatible(dev, "allwinner,allwinner,sun9i-a80-mmc"))
+   count = ARRAY_SIZE(a80_mmc_resets);
+
+   return sunxi_reset_bind(dev, count);
 }
 
 static const struct udevice_id a80_ccu_ids[] = {
{ .compatible = "allwinner,sun9i-a80-ccu",
  .data = (ulong)_ccu_desc },
+   { .compatible = "allwinner,allwinner,sun9i-a80-mmc",
+ .data = (ulong)_mmc_clk_desc },
{ }
 };
 
-- 
2.14.5

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


[U-Boot] [PATCH 5/9] mmc: sunxi: Add missing compatible strings

2019-01-18 Thread Andre Przywara
From: Jagan Teki 

From our driver's perspective there is no difference between the MMC
controllers for the A83T, A64 and H5 compared to the A10/A20 type.

As we now have support for the formerly missing reset gates, we can
add their compatible strings, to make those SoCs work with DM_MMC.

Signed-off-by: Jagan Teki 
Signed-off-by: Andre Przywara 
---
 drivers/mmc/sunxi_mmc.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c
index 16646012bc..62b658c435 100644
--- a/drivers/mmc/sunxi_mmc.c
+++ b/drivers/mmc/sunxi_mmc.c
@@ -705,6 +705,18 @@ static const struct udevice_id sunxi_mmc_ids[] = {
  .compatible = "allwinner,sun7i-a20-mmc",
  .data = (ulong)_a10_variant,
},
+   {
+ .compatible = "allwinner,sun8i-a83t-emmc",
+ .data = (ulong)_a10_variant,
+   },
+   {
+ .compatible = "allwinner,sun50i-a64-mmc",
+ .data = (ulong)_a10_variant,
+   },
+   {
+ .compatible = "allwinner,sun50i-a64-emmc",
+ .data = (ulong)_a10_variant,
+   },
{
  .compatible = "allwinner,sun50i-h6-mmc",
  .data = (ulong)_h6_variant,
-- 
2.14.5

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


[U-Boot] [PATCH 1/9] sunxi: clk: add MMC gates/resets

2019-01-18 Thread Andre Przywara
Add the MMC clock gates and reset bits for all the Allwinner SoCs.
This allows them to be used by the MMC driver.

We don't advertise the mod clock yet, as this is still handled by the
MMC driver.

Signed-off-by: Andre Przywara 
---
 drivers/clk/sunxi/clk_a10.c  | 4 
 drivers/clk/sunxi/clk_a10s.c | 3 +++
 drivers/clk/sunxi/clk_a23.c  | 6 ++
 drivers/clk/sunxi/clk_a31.c  | 8 
 drivers/clk/sunxi/clk_a64.c  | 6 ++
 drivers/clk/sunxi/clk_a83t.c | 6 ++
 drivers/clk/sunxi/clk_h3.c   | 6 ++
 drivers/clk/sunxi/clk_h6.c   | 6 ++
 drivers/clk/sunxi/clk_r40.c  | 8 
 9 files changed, 53 insertions(+)

diff --git a/drivers/clk/sunxi/clk_a10.c b/drivers/clk/sunxi/clk_a10.c
index b00f51af8b..2aa41efe17 100644
--- a/drivers/clk/sunxi/clk_a10.c
+++ b/drivers/clk/sunxi/clk_a10.c
@@ -18,6 +18,10 @@ static struct ccu_clk_gate a10_gates[] = {
[CLK_AHB_OHCI0] = GATE(0x060, BIT(2)),
[CLK_AHB_EHCI1] = GATE(0x060, BIT(3)),
[CLK_AHB_OHCI1] = GATE(0x060, BIT(4)),
+   [CLK_AHB_MMC0]  = GATE(0x060, BIT(8)),
+   [CLK_AHB_MMC1]  = GATE(0x060, BIT(9)),
+   [CLK_AHB_MMC2]  = GATE(0x060, BIT(10)),
+   [CLK_AHB_MMC3]  = GATE(0x060, BIT(11)),
 
[CLK_APB1_UART0]= GATE(0x06c, BIT(16)),
[CLK_APB1_UART1]= GATE(0x06c, BIT(17)),
diff --git a/drivers/clk/sunxi/clk_a10s.c b/drivers/clk/sunxi/clk_a10s.c
index aa904ce067..87b74e52dc 100644
--- a/drivers/clk/sunxi/clk_a10s.c
+++ b/drivers/clk/sunxi/clk_a10s.c
@@ -16,6 +16,9 @@ static struct ccu_clk_gate a10s_gates[] = {
[CLK_AHB_OTG]   = GATE(0x060, BIT(0)),
[CLK_AHB_EHCI]  = GATE(0x060, BIT(1)),
[CLK_AHB_OHCI]  = GATE(0x060, BIT(2)),
+   [CLK_AHB_MMC0]  = GATE(0x060, BIT(8)),
+   [CLK_AHB_MMC1]  = GATE(0x060, BIT(9)),
+   [CLK_AHB_MMC2]  = GATE(0x060, BIT(10)),
 
[CLK_APB1_UART0]= GATE(0x06c, BIT(16)),
[CLK_APB1_UART1]= GATE(0x06c, BIT(17)),
diff --git a/drivers/clk/sunxi/clk_a23.c b/drivers/clk/sunxi/clk_a23.c
index 854259bf81..1ef2359286 100644
--- a/drivers/clk/sunxi/clk_a23.c
+++ b/drivers/clk/sunxi/clk_a23.c
@@ -13,6 +13,9 @@
 #include 
 
 static struct ccu_clk_gate a23_gates[] = {
+   [CLK_BUS_MMC0]  = GATE(0x060, BIT(8)),
+   [CLK_BUS_MMC1]  = GATE(0x060, BIT(9)),
+   [CLK_BUS_MMC2]  = GATE(0x060, BIT(10)),
[CLK_BUS_OTG]   = GATE(0x060, BIT(24)),
[CLK_BUS_EHCI]  = GATE(0x060, BIT(26)),
[CLK_BUS_OHCI]  = GATE(0x060, BIT(29)),
@@ -35,6 +38,9 @@ static struct ccu_reset a23_resets[] = {
[RST_USB_PHY1]  = RESET(0x0cc, BIT(1)),
[RST_USB_HSIC]  = RESET(0x0cc, BIT(2)),
 
+   [RST_BUS_MMC0]  = RESET(0x2c0, BIT(8)),
+   [RST_BUS_MMC1]  = RESET(0x2c0, BIT(9)),
+   [RST_BUS_MMC2]  = RESET(0x2c0, BIT(10)),
[RST_BUS_OTG]   = RESET(0x2c0, BIT(24)),
[RST_BUS_EHCI]  = RESET(0x2c0, BIT(26)),
[RST_BUS_OHCI]  = RESET(0x2c0, BIT(29)),
diff --git a/drivers/clk/sunxi/clk_a31.c b/drivers/clk/sunxi/clk_a31.c
index a38d76cb7c..5bd8b7dccc 100644
--- a/drivers/clk/sunxi/clk_a31.c
+++ b/drivers/clk/sunxi/clk_a31.c
@@ -13,6 +13,10 @@
 #include 
 
 static struct ccu_clk_gate a31_gates[] = {
+   [CLK_AHB1_MMC0] = GATE(0x060, BIT(8)),
+   [CLK_AHB1_MMC1] = GATE(0x060, BIT(9)),
+   [CLK_AHB1_MMC2] = GATE(0x060, BIT(10)),
+   [CLK_AHB1_MMC3] = GATE(0x060, BIT(11)),
[CLK_AHB1_OTG]  = GATE(0x060, BIT(24)),
[CLK_AHB1_EHCI0]= GATE(0x060, BIT(26)),
[CLK_AHB1_EHCI1]= GATE(0x060, BIT(27)),
@@ -40,6 +44,10 @@ static struct ccu_reset a31_resets[] = {
[RST_USB_PHY1]  = RESET(0x0cc, BIT(1)),
[RST_USB_PHY2]  = RESET(0x0cc, BIT(2)),
 
+   [RST_AHB1_MMC0] = RESET(0x2c0, BIT(8)),
+   [RST_AHB1_MMC1] = RESET(0x2c0, BIT(9)),
+   [RST_AHB1_MMC2] = RESET(0x2c0, BIT(10)),
+   [RST_AHB1_MMC3] = RESET(0x2c0, BIT(11)),
[RST_AHB1_OTG]  = RESET(0x2c0, BIT(24)),
[RST_AHB1_EHCI0]= RESET(0x2c0, BIT(26)),
[RST_AHB1_EHCI1]= RESET(0x2c0, BIT(27)),
diff --git a/drivers/clk/sunxi/clk_a64.c b/drivers/clk/sunxi/clk_a64.c
index a2ba6eefc5..910275fbce 100644
--- a/drivers/clk/sunxi/clk_a64.c
+++ b/drivers/clk/sunxi/clk_a64.c
@@ -13,6 +13,9 @@
 #include 
 
 static const struct ccu_clk_gate a64_gates[] = {
+   [CLK_BUS_MMC0]  = GATE(0x060, BIT(8)),
+   [CLK_BUS_MMC1]  = GATE(0x060, BIT(9)),
+   [CLK_BUS_MMC2]  = GATE(0x060, BIT(10)),
[CLK_BUS_OTG]   = GATE(0x060, BIT(23)),
[CLK_BUS_EHCI0] = GATE(0x060, BIT(24)),
[CLK_BUS_EHCI1] = GATE(0x060, BIT(25)),
@@ -38,6 +41,9 @@ static const struct 

[U-Boot] [PATCH 0/9] sunxi: enable DM_MMC

2019-01-18 Thread Andre Przywara
This series enables the Allwinner MMC driver to drive all SoCs with its
DM_MMC variant. We use the gates clock and reset support from the new
clock driver, but keep the actual mod clock in its somewhat hackish
state. Properly supporting this via the clock driver is a bit more work.
The per-compatible variant struct for now only holds the mod clock
address (which will go away), but we will need the struct later again
for the various timing modes.

This allows us to eventually enable DM_MMC for all SoCs, and get rid of
the nasty deprecation warning.

The first patch adds the MMC clock gates and resets to the clock driver.
Patch 2/9 adds support for the A80 MMC config clock, which is a bit
special. I can't test this, so please give this a try if you have a board.

Patch 3 uses the new clocks in the MMC driver, the following three patches
add the remaining compatible strings along with their required mod clock
addresses.

Patch 7 fixes the Pine64-LTS board, while patch 8 eventually enables
everything. Patch 9 is some comment fix to make it easier to reason
about what part of the driver is for DM_MMC and which is not.

I successfully compiled the HEAD for all 142 Allwinner boards, also
compiled all patches for selected boards.

This was briefly tested on Pine-H64 (H6), Pine64-LTS (A64), OrangePi PC 2
(H5), OrangePi Zero (H2+) and BananaPi-M1 (A20).

Please run it on every board that you can get hold of to give this series
a good shake.

This goes on top of current sunxi/master (543049ab5906) and is available
on https://github.com/apritzel/u-boot/commits/sunxi-dm.

This replaces Jagan's v2 series "mmc: sunxi: Enable DM_MMC" in a more
driver model compliant way, borrowing two patches from him.

Cheers,
Andre.

Andre Przywara (7):
  sunxi: clk: add MMC gates/resets
  sunxi: clk: A80: add MMC clock support
  mmc: sunxi: Add DM clk and reset support
  mmc: sunxi: Add H6 support
  mmc: sunxi: Add A80 support
  mmc: sunxi: Honour non-removable property in DT
  mmc: sunxi: Mark end of DM_MMC #ifdefs

Jagan Teki (2):
  mmc: sunxi: Add missing compatible strings
  arm: sunxi: Enable DM_MMC

 arch/arm/Kconfig  |  1 +
 arch/arm/mach-sunxi/Kconfig   |  1 -
 configs/Linksprite_pcDuino3_defconfig |  1 -
 drivers/clk/sunxi/clk_a10.c   |  4 +++
 drivers/clk/sunxi/clk_a10s.c  |  3 ++
 drivers/clk/sunxi/clk_a23.c   |  6 
 drivers/clk/sunxi/clk_a31.c   |  8 +
 drivers/clk/sunxi/clk_a64.c   |  6 
 drivers/clk/sunxi/clk_a80.c   | 28 -
 drivers/clk/sunxi/clk_a83t.c  |  6 
 drivers/clk/sunxi/clk_h3.c|  6 
 drivers/clk/sunxi/clk_h6.c|  6 
 drivers/clk/sunxi/clk_r40.c   |  8 +
 drivers/mmc/sunxi_mmc.c   | 59 +--
 14 files changed, 131 insertions(+), 12 deletions(-)

-- 
2.14.5

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


Re: [U-Boot] [PATCH v2 2/9] ARM: rockchip: rk3188: Remove the pinctrl setup and enable uart at SPL

2019-01-18 Thread Lukasz Majewski
Hi David,

> Hi Heiko,
> 
> 在 2019/1/6 上午1:17, Heiko Stuebner 写道:
> >> diff --git a/arch/arm/mach-rockchip/rk3188-board-spl.c
> >> b/arch/arm/mach-rockchip/rk3188-board-spl.c index
> >> 3c6c3d3c09..a5e4d39cb7 100644 ---
> >> a/arch/arm/mach-rockchip/rk3188-board-spl.c +++
> >> b/arch/arm/mach-rockchip/rk3188-board-spl.c @@ -120,7 +120,7 @@
> >> void board_debug_uart_init(void) 
> >>   void board_init_f(ulong dummy)
> >>   {
> >> -  struct udevice *pinctrl, *dev;
> >> +  struct udevice *dev;
> >>int ret;
> >>   
> >>   #define EARLY_UART
> >> @@ -134,10 +134,7 @@ void board_init_f(ulong dummy)
> >> * printascii("string");
> >> */
> >>debug_uart_init();
> >> -  printch('s');
> >> -  printch('p');
> >> -  printch('l');
> >> -  printch('\n');
> >> +  printascii("U-Boot SPL board init");  
> > Did you test this change?
> > I remember rk3188 having issues (aka hanging) when trying to print
> > strings through the debug uart and only printch working at all.
> > (Timer issue or so?) ... Not sure if this got fixed in the meantime?
> >   

But you are using the debug uart for "production". Please use the
proper driver.

You may either properly setup normal uart or buffer the console output
until the uart is configured by device model (DM).


> 
> I don't know there was a issue, but i test it on the Radxa board
> today, it looks okay.
> 
> U-Boot SPL board init
> U-Boot SPL 2019.01-rc1-9-gdd7b9156fe (Jan 14 2019 - 19:53:50
> +0800) Returning to boot ROM...
> 
> 
> U-Boot 2019.01-rc1-9-gdd7b9156fe (Jan 14 2019 - 19:53:50 +0800)
> 
> Model: Radxa Rock
> DRAM:  2 GiB
> MMC:   dwmmc@10214000: 0
> Loading Environment from MMC... Card did not respond to voltage
> select! *** Warning - No block device, using default environment
> 
> In:serial@20064000
> Out:   serial@20064000
> Err:   serial@20064000
> Model: Radxa Rock
> rockchip_dnl_key_pressed: adc_channel_single_shot fail!
> Net:   Net Initialization Skipped
> No ethernet found.
> Hit any key to stop autoboot:  0
> =>  
> 
> 
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot




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


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


[U-Boot] TPL max size for RK3288 ?

2019-01-18 Thread Tom Rini
Hey,

So I was playing with how to make our linker scripts more re-usable
and have the kinds of link error on excessive size checks that we find
really useful to avoid introducing run time failures, and I found
something.  On rk3288 we don't size TPL_MAX_SIZE, only for rk3368.  Is
there a reasonable one to set here?  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] configs: move CONFIG_SPL_TEXT_BASE to Kconfig

2019-01-18 Thread Tom Rini
On Mon, Jan 07, 2019 at 10:12:42AM +0100, Simon Goldschmidt wrote:
> On Wed, Jan 2, 2019 at 9:13 PM Simon Goldschmidt
>  wrote:
> >
> > Hi Marek,
> >
> > Am 14.11.2018 um 19:51 schrieb Simon Goldschmidt:
> > > On 07.10.2018 02:49, Tom Rini wrote:
> > >> On Sun, Sep 30, 2018 at 02:31:53PM +0200, Simon Goldschmidt wrote:
> > >>
> > >>> Moved CONFIG_SPL_TEXT_BASE to common/spl/Kconfig with
> > >>> help from moveconfig.py (only had to prepare socfpga,
> > >>> stm32f746 and am33x/43x manually)
> > >>>
> > >>> Signed-off-by: Simon Goldschmidt 
> > >>> ---
> > >>>
> > >>> This patch is in preparation for boot-from-FPGA for
> > >>> socfpga cyclone5, where we need a different SPL_TEXT_BASE.
> > >>> By moving this to Kconfig, this can then be done via
> > >>> defconfig.
> > >>>
> > >>> I did notice that some defconfig files change more than
> > >>> necessary, it seems like they are out of sync?
> > >> So, I see at least one set of problems with the conversion, the am33*
> > >> family gets put to 0x0 which isn't right.  I'm going to pull out the
> > >> print tool I made and posted a while back and use that for conversion.
> > >> Thanks for the starting point!
> > >
> > > Tom, what's the status on this? I still can't build an SPL for socfpga
> > > gen5 boot from FPGA because I can't change SPL_TEXT_BASE.
> > >
> > > Marek, if getting CONFIG_SPL_TEXT_BASE into 2019.01 won't work, can we
> > > have a separate (k)config option for socfpga only? That might be useful
> > > anyway as when booting from fpga, there is no 64 KByte size limit and
> > > the "magic value into magic register to unlock support for issuing warm
> > > reset" must not be written as the SPL is not in SRAM. But that might
> > > have its separate config option, too...
> > >
> > > Anyway, I just need input to know in which direction I should continue.
> > > I'm waiting to get all our versions of SPL and U-Boot running from
> > > mainline (with only board configs added for our private boards).
> >
> > I still cannot build an SPL to boot from FPGA since CONFIG_SPL_TEXT_BASE
> > is hard-coded to OnChip RAM (while when booting from FPGA, it has to be
> > placed into the FPGA bridge).
> >
> > Since both Tom and myself did not seem to have immediate luck with
> > bringing CONFIG_SPL_TEXT_BASE to Kconfig, may I suggest to add a Kconfig
> > option 'Boot from FPGA' for socfpga_gen5?
> >
> > Or do you have another idea at hand of how to proceed here?
> >
> > Please note that there might be other settings that may change when
> > booting from FPGA, e.g. the maximum code size for SPL is not limited any
> > more.
> 
> Gentle ping?
> 
> I'd really like to get boot-from-FPGA finally working in the next release!

So, migrating CONFIG_SPL_TEXT_BASE.  A problem is that we don't get the
value for CONFIG_SPL_TEXT_BASE, only CONFIG_TEXT_BASE, once we move it
to Kconfig and are building non-SPL.  This is a problem for the TI K2
boards.  This however can be fixed by leveraging Andrew's patch[1] as
"ISW" is just a generic term and we can set that on the K2 platforms and
adjust CONFIG_SYS_INIT_SP_ADDR to use that.  Next, rockchip rk3368 needs
to be updated to make use of CONFIG_TPL_TEXT_BASE via Kconfig, which
exists already, rather than the workaround it's doing.  Finally, some
PowerPC boards that are using TPL are in a similar spot where they also
need to use CONFIG_TPL_TEXT_BASE and are using the mechanic where we'll
pass SPL_TEXT_BASE in TPL, if TPL_TEXT_BASE isn't set.

So, what's all this mean?  Well, the rockchip issue looks pretty easy to
deal with and verify, so I'll tackle that first and post something
shortly.  The PowerPC thing also doesn't look too terrible (it's only a
few headers) so I'll tackle that second.  And then the TI one I'll work
on 3rd, after I get Andrew's patch merged in, which should be fairly
soon (v3 fixed a small issue I found when merging v2).

[1]: https://patchwork.ozlabs.org/patch/1026946/
-- 
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] Convert Pico-Pi i.MX7D to DM

2019-01-18 Thread Fabio Estevam
Hi Joris,

On Fri, Jan 18, 2019 at 6:23 PM Joris Offouga  wrote:
>
> Hi all,
>
> I try to convert Pico-Pi i.MX7D to DM but I'm having some trouble with
> pmic and ethernet.
> you can see the log lower
>
> Do you have an idea to solve this?

Maybe you could take a look at Byan's patch that converted imx7s-warp
to use PMIC DM:
https://patches.linaro.org/patch/156034/

You also need to convert I2C first.

Bryan's complete series can be found here:
https://patches.linaro.org/project/u-boot/list/

Hope this helps and looking forward to your patches :-)

Regards,

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


Re: [U-Boot] [PATCH 2/2] env: Fix saving environment to "bad CRC" location

2019-01-18 Thread Simon Goldschmidt
Am Fr., 18. Jan. 2019, 20:20 hat Sam Protsenko 
geschrieben:

> In case when the environment on some location is malformed (CRC isn't
> matching), there is a chance we won't be able to save the environment to
> that location. For example, consider the case when we only have the
> environment on eMMC, but it's zeroed out. In that case, we won't be able
> to "env save" to it, because of "bad CRC" error. That's happening
> because in env_load() function we consider malformed environment as
> incorrect one, and  defaulting to the location with highest (0)
> priority, which can be different from one we are dealing with right now
> (e.g., highest priority can be ENV_FAT on SD card, which is not
> inserted, but we want to use ENV_MMC on eMMC, where we were booted
> from).
>
> This issue began to reproduce after commit d30ba2315ae3 ("u-boot: remove
> driver lookup loop from env_save()") on BeagleBone Black, but that
> commit didn't introduce the wrong logic, it just changed the behavior
> for default location to use, merely revealing this issue.
>

In my opinion, this automatism of selecting a driver to save the env can
always produce a behaviour that is unexpected to the user.

I wonder if it wouldn't be better to either let the board define some
default env driver for saving or the user should specify the driver as
argument to 'env save'.

Note that this is not an objection to your oatches, I'm just not content
with the current auto-selection...

Regards,
Simon


> To fix that, let's implement next logic in env_load():
>   1. Try to find out correct environment; if found -- use it
>   2. If working environment wasn't found, but we found malformed one
>  (with bad CRC), let's use it for further "env save". But make sure
>  to use malformed environment location with highest priority.
>   3. If neither correct nor malformed environment was found, let's
>  default to environment location with highest priority (0)
>
> Steps to reproduce mentioned issue on BeagleBone Black (fixed in this
> patch):
>
> 1. Boot from SD card and erase eMMC in U-Boot shell:
>=> mmc dev 1
>=> mmc erase 0 10
>=> gpt write mmc 1 $partitions
> 2. Write new SPL and U-Boot to eMMC; the rest of eMMC will stay filled
>with zeroes
> 3. Boot from eMMC; try to do:
>=> env save
> 4. Observe the error (incorrect behavior). Correct behavior: environment
>should be stored correctly on eMMC, in spite of it has "bad CRC"
>
> Fixes: d30ba2315ae3 ("u-boot: remove driver lookup loop from env_save()")
> Signed-off-by: Sam Protsenko 
> ---
>  env/env.c | 25 +++--
>  1 file changed, 19 insertions(+), 6 deletions(-)
>
> diff --git a/env/env.c b/env/env.c
> index 003509d342..4b417b90a2 100644
> --- a/env/env.c
> +++ b/env/env.c
> @@ -177,6 +177,7 @@ int env_get_char(int index)
>  int env_load(void)
>  {
> struct env_driver *drv;
> +   int best_prio = -1;
> int prio;
>
> for (prio = 0; (drv = env_driver_lookup(ENVOP_LOAD, prio));
> prio++) {
> @@ -195,20 +196,32 @@ int env_load(void)
>  * one message.
>  */
> ret = drv->load();
> -   if (ret) {
> -   debug("Failed (%d)\n", ret);
> -   } else {
> +   if (!ret) {
> printf("OK\n");
> return 0;
> +   } else if (ret == -ENOMSG) {
> +   /* Handle "bad CRC" case */
> +   if (best_prio == -1)
> +   best_prio = prio;
> +   } else {
> +   debug("Failed (%d)\n", ret);
> }
> }
>
> /*
>  * In case of invalid environment, we set the 'default' env
> location
> -* to the highest priority. In this way, next calls to env_save()
> -* will restore the environment at the right place.
> +* to the best choice, i.e.:
> +*   1. Environment location with bad CRC, if such location was
> found
> +*   2. Otherwise use the location with highest priority
> +*
> +* This way, next calls to env_save() will restore the environment
> +* at the right place.
>  */
> -   env_get_location(ENVOP_LOAD, 0);
> +   if (best_prio >= 0)
> +   debug("Selecting environment with bad CRC\n");
> +   else
> +   best_prio = 0;
> +   env_get_location(ENVOP_LOAD, best_prio);
>
> return -ENODEV;
>  }
> --
> 2.20.1
>
> ___
> 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] Convert Pico-Pi i.MX7D to DM

2019-01-18 Thread Joris Offouga

Hi all,

I try to convert Pico-Pi i.MX7D to DM but I'm having some trouble with 
pmic and ethernet.

you can see the log lower

Do you have an idea to solve this?

Thanks in advance.

Best Regards,

Joris Offouga

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


Re: [U-Boot] [PATCH v4 2/2] imx: Add PHYTEC phyBOARD-i.MX6UL-Segin

2019-01-18 Thread Martyn Welch
Hi All,

Is there anything preventing this series being merged? I don't think
I've seen any further issues raised.

Sorry if it's already been merged somewhere and I've missed it...

Martyn

On Tue, 2018-12-11 at 11:34 +, Martyn Welch wrote:
> Port for the PHYTEC phyBOARD-i.MX6UL-Segin single board computer.
> Based on
> the PHYTEC phyCORE-i.MX6UL SOM (PCL063).
> 
> CPU:   Freescale i.MX6UL rev1.2 528 MHz (running at 396 MHz)
> CPU:   Industrial temperature grade (-40C to 105C) at 44C
> Reset cause: POR
> Board: PHYTEC phyCORE-i.MX6UL
> I2C:   ready
> DRAM:  256 MiB
> NAND:  512 MiB
> MMC:   FSL_SDHC: 0
> In:serial
> Out:   serial
> Err:   serial
> Net:   FEC0
> 
> Working:
>  - Eth0
>  - i2C
>  - MMC/SD
>  - NAND
>  - UART (1 & 5)
>  - USB (host & otg)
> 
> Signed-off-by: Martyn Welch 
> 
> ---
> 
> Changes in v4:
> - Added PXE boot option
> - Switched i2c to DM support
> 
> Changes in v3:
> - Correct spelling of Phytec
> - Remove unneeded license information
> - Correct image name in documentation
> - Correct whitespacing
> - Enable SPL to boot from MMC
> - Simplify defconfig, remove non-SPL build
> 
> Changes in v2:
> - Switch to driver model
> 
>  arch/arm/dts/Makefile |   3 +-
>  arch/arm/dts/imx6ul-pcl063.dtsi   | 173 +
>  arch/arm/dts/imx6ul-phycore-segin.dts |  76 ++
>  arch/arm/mach-imx/mx6/Kconfig |  13 ++
>  board/phytec/pcl063/Kconfig   |  12 ++
>  board/phytec/pcl063/MAINTAINERS   |   8 +
>  board/phytec/pcl063/Makefile  |   7 +
>  board/phytec/pcl063/README|  26 
>  board/phytec/pcl063/pcl063.c  | 206
> ++
>  board/phytec/pcl063/spl.c | 160 
>  configs/phycore_pcl063_defconfig  |  62 
>  include/configs/pcl063.h  |  94 
>  12 files changed, 839 insertions(+), 1 deletion(-)
>  create mode 100644 arch/arm/dts/imx6ul-pcl063.dtsi
>  create mode 100644 arch/arm/dts/imx6ul-phycore-segin.dts
>  create mode 100644 board/phytec/pcl063/Kconfig
>  create mode 100644 board/phytec/pcl063/MAINTAINERS
>  create mode 100644 board/phytec/pcl063/Makefile
>  create mode 100644 board/phytec/pcl063/README
>  create mode 100644 board/phytec/pcl063/pcl063.c
>  create mode 100644 board/phytec/pcl063/spl.c
>  create mode 100644 configs/phycore_pcl063_defconfig
>  create mode 100644 include/configs/pcl063.h
> 
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index 949ee472fc..68411623e5 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -453,7 +453,8 @@ dtb-$(CONFIG_MX6UL) += \
>   imx6ul-isiot-nand.dtb \
>   imx6ul-opos6uldev.dtb \
>   imx6ul-14x14-evk.dtb \
> - imx6ul-9x9-evk.dtb
> + imx6ul-9x9-evk.dtb \
> + imx6ul-phycore-segin.dtb
>  
>  dtb-$(CONFIG_MX6ULL) += imx6ull-14x14-evk.dtb
>  
> diff --git a/arch/arm/dts/imx6ul-pcl063.dtsi b/arch/arm/dts/imx6ul-
> pcl063.dtsi
> new file mode 100644
> index 00..24a6a47983
> --- /dev/null
> +++ b/arch/arm/dts/imx6ul-pcl063.dtsi
> @@ -0,0 +1,173 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2018 Collabora Ltd.
> + *
> + * Based on dts[i] from Phytec barebox port:
> + * Copyright (C) 2016 PHYTEC Messtechnik GmbH
> + * Author: Christian Hemp 
> + */
> +
> +/dts-v1/;
> +
> +#include "imx6ul.dtsi"
> +
> +/ {
> + model = "Phytec phyCORE-i.MX6 Ultra Lite SOM";
> + compatible = "phytec,imx6ul-pcl063", "fsl,imx6ul";
> +
> + memory {
> + reg = <0x8000 0x2000>;
> + };
> +
> + chosen {
> + stdout-path = 
> + };
> +};
> +
> + {
> + pinctrl-names = "default";
> + pinctrl-0 = <_enet1>;
> + phy-mode = "rmii";
> + phy-handle = <>;
> + status = "okay";
> +
> + mdio: mdio {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + ethphy0: ethernet-phy@1 {
> + reg = <1>;
> + micrel,led-mode = <1>;
> + };
> + };
> +};
> +
> + {
> + pinctrl-names = "default";
> + pinctrl-0 = <_gpmi_nand>;
> + nand-on-flash-bbt;
> + fsl,no-blockmark-swap;
> + status = "okay";
> +
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + partition@0 {
> + label = "uboot";
> + reg = <0x0 0x40>;
> + };
> +
> + partition@40 {
> + label = "uboot-env";
> + reg = <0x40 0x10>;
> + };
> +
> + partition@50 {
> + label = "root";
> + reg = <0x50 0x0>;
> + };
> +};
> +
> + {
> + clock-frequency = <10>;
> + pinctrl-names = "default", "gpio";
> + pinctrl-0 = <_i2c1>;
> + pinctrl-1 = <_i2c1_gpio>;
> + scl-gpios = < 28 GPIO_ACTIVE_HIGH>;
> + sda-gpios = < 29 GPIO_ACTIVE_HIGH>;
> + status = "okay";
> +
> + eeprom@52 {
> + compatible = "cat,24c32";
> + reg = <0x52>;
> + 

[U-Boot] [PATCH 2/2] env: Fix saving environment to "bad CRC" location

2019-01-18 Thread Sam Protsenko
In case when the environment on some location is malformed (CRC isn't
matching), there is a chance we won't be able to save the environment to
that location. For example, consider the case when we only have the
environment on eMMC, but it's zeroed out. In that case, we won't be able
to "env save" to it, because of "bad CRC" error. That's happening
because in env_load() function we consider malformed environment as
incorrect one, and  defaulting to the location with highest (0)
priority, which can be different from one we are dealing with right now
(e.g., highest priority can be ENV_FAT on SD card, which is not
inserted, but we want to use ENV_MMC on eMMC, where we were booted
from).

This issue began to reproduce after commit d30ba2315ae3 ("u-boot: remove
driver lookup loop from env_save()") on BeagleBone Black, but that
commit didn't introduce the wrong logic, it just changed the behavior
for default location to use, merely revealing this issue.

To fix that, let's implement next logic in env_load():
  1. Try to find out correct environment; if found -- use it
  2. If working environment wasn't found, but we found malformed one
 (with bad CRC), let's use it for further "env save". But make sure
 to use malformed environment location with highest priority.
  3. If neither correct nor malformed environment was found, let's
 default to environment location with highest priority (0)

Steps to reproduce mentioned issue on BeagleBone Black (fixed in this
patch):

1. Boot from SD card and erase eMMC in U-Boot shell:
   => mmc dev 1
   => mmc erase 0 10
   => gpt write mmc 1 $partitions
2. Write new SPL and U-Boot to eMMC; the rest of eMMC will stay filled
   with zeroes
3. Boot from eMMC; try to do:
   => env save
4. Observe the error (incorrect behavior). Correct behavior: environment
   should be stored correctly on eMMC, in spite of it has "bad CRC"

Fixes: d30ba2315ae3 ("u-boot: remove driver lookup loop from env_save()")
Signed-off-by: Sam Protsenko 
---
 env/env.c | 25 +++--
 1 file changed, 19 insertions(+), 6 deletions(-)

diff --git a/env/env.c b/env/env.c
index 003509d342..4b417b90a2 100644
--- a/env/env.c
+++ b/env/env.c
@@ -177,6 +177,7 @@ int env_get_char(int index)
 int env_load(void)
 {
struct env_driver *drv;
+   int best_prio = -1;
int prio;
 
for (prio = 0; (drv = env_driver_lookup(ENVOP_LOAD, prio)); prio++) {
@@ -195,20 +196,32 @@ int env_load(void)
 * one message.
 */
ret = drv->load();
-   if (ret) {
-   debug("Failed (%d)\n", ret);
-   } else {
+   if (!ret) {
printf("OK\n");
return 0;
+   } else if (ret == -ENOMSG) {
+   /* Handle "bad CRC" case */
+   if (best_prio == -1)
+   best_prio = prio;
+   } else {
+   debug("Failed (%d)\n", ret);
}
}
 
/*
 * In case of invalid environment, we set the 'default' env location
-* to the highest priority. In this way, next calls to env_save()
-* will restore the environment at the right place.
+* to the best choice, i.e.:
+*   1. Environment location with bad CRC, if such location was found
+*   2. Otherwise use the location with highest priority
+*
+* This way, next calls to env_save() will restore the environment
+* at the right place.
 */
-   env_get_location(ENVOP_LOAD, 0);
+   if (best_prio >= 0)
+   debug("Selecting environment with bad CRC\n");
+   else
+   best_prio = 0;
+   env_get_location(ENVOP_LOAD, best_prio);
 
return -ENODEV;
 }
-- 
2.20.1

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


[U-Boot] [PATCH 1/2] env: common: Return specific error code on bad CRC

2019-01-18 Thread Sam Protsenko
Callers of env_import*() functions might want to check the case when we
have incorrect environment (with bad CRC). For example, when environment
location is being defined in env_load(), call chain may look like this:

env_load() -> drv->load() = env_mmc_load() -> env_import()

Return code will be passed from env_import() all way up to env_load().
Right now both env_mmc_load() and env_import() return -EIO error code,
so env_load() can't differentiate between two cases:
  1. Driver reports the error, because device is not accessible
  2. Device is actually accessible, but environment is broken

Let's return -ENOMSG in env_import(), so we can distinguish two cases
mentioned above. It will make it possible to continue working with "bad
CRC" environment (like doing "env save"), instead of considering it not
functional (implemented in subsequent patch).

Signed-off-by: Sam Protsenko 
---
 env/common.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/env/common.c b/env/common.c
index d1a6a52860..324502ed82 100644
--- a/env/common.c
+++ b/env/common.c
@@ -115,7 +115,7 @@ int env_import(const char *buf, int check)
 
if (crc32(0, ep->data, ENV_SIZE) != crc) {
set_default_env("bad CRC", 0);
-   return -EIO;
+   return -ENOMSG; /* needed for env_load() */
}
}
 
@@ -169,7 +169,7 @@ int env_import_redund(const char *buf1, int buf1_read_fail,
 
if (!crc1_ok && !crc2_ok) {
set_default_env("bad CRC", 0);
-   return -EIO;
+   return -ENOMSG; /* needed for env_load() */
} else if (crc1_ok && !crc2_ok) {
gd->env_valid = ENV_VALID;
} else if (!crc1_ok && crc2_ok) {
-- 
2.20.1

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


[U-Boot] [PATCH 0/2] env: Fix "env save" to malformed environment

2019-01-18 Thread Sam Protsenko
In case when environment is malformed (e.g. zeroed out), we are not
able to save new environment to that location. Let's fix that by not
considering the location with "bad CRC" environment as not accessible.

Sam Protsenko (2):
  env: common: Return specific error code on bad CRC
  env: Fix saving environment to "bad CRC" location

 env/common.c |  4 ++--
 env/env.c| 25 +++--
 2 files changed, 21 insertions(+), 8 deletions(-)

-- 
2.20.1

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


[U-Boot] [PATCH 1/1] efi_loader: comments for variable services

2019-01-18 Thread Heinrich Schuchardt
Comment the functions implementing the runtime variable services.

Signed-off-by: Heinrich Schuchardt 
---
 lib/efi_loader/efi_variable.c | 86 +--
 1 file changed, 81 insertions(+), 5 deletions(-)

diff --git a/lib/efi_loader/efi_variable.c b/lib/efi_loader/efi_variable.c
index 2ac27731fe..aff28bf9f0 100644
--- a/lib/efi_loader/efi_variable.c
+++ b/lib/efi_loader/efi_variable.c
@@ -47,6 +47,19 @@
 
 #define PREFIX_LEN (strlen("efi_----_"))
 
+/**
+ * efi_to_native() - convert the UEFI variable name and vendor GUID to U-Boot
+ *  variable name
+ *
+ * The U-Boot variable name is a concatenation of prefix 'efi', the hexstring
+ * encoded vendor GUID, and the UTF-8 encoded UEFI variable name separated by
+ * underscores, e.g. 'efi_8be4df61-93ca-11d2-aa0d-00e098032b8c_BootOrder'.
+ *
+ * @native:pointer to pointer to U-Boot variable name
+ * @variable_name: UEFI variable name
+ * @vendor:vendor GUID
+ * Return: status code
+ */
 static efi_status_t efi_to_native(char **native, const u16 *variable_name,
  const efi_guid_t *vendor)
 {
@@ -65,6 +78,15 @@ static efi_status_t efi_to_native(char **native, const u16 
*variable_name,
return EFI_SUCCESS;
 }
 
+/**
+ * prefix() - skip over prefix
+ *
+ * Skip over a prefix string.
+ *
+ * @str:   string with prefix
+ * @prefix:prefix string
+ * Return: string without prefix, or NULL if prefix not found
+ */
 static const char *prefix(const char *str, const char *prefix)
 {
size_t n = strlen(prefix);
@@ -73,7 +95,16 @@ static const char *prefix(const char *str, const char 
*prefix)
return NULL;
 }
 
-/* parse attributes part of variable value, if present: */
+/**
+ * parse_attr() - decode attributes part of variable value
+ *
+ * Convert the string encoded attributes of a UEFI variable to a bit mask.
+ * TODO: Several attributes are not supported.
+ *
+ * @str:   value of U-Boot variable
+ * @attrp: pointer to UEFI attributes
+ * Return: pointer to remainder of U-Boot variable value
+ */
 static const char *parse_attr(const char *str, u32 *attrp)
 {
u32 attr = 0;
@@ -111,7 +142,21 @@ static const char *parse_attr(const char *str, u32 *attrp)
return str;
 }
 
-/* 
http://wiki.phoenix.com/wiki/index.php/EFI_RUNTIME_SERVICES#GetVariable.28.29 */
+/**
+ * efi_efi_get_variable() - retrieve value of a UEFI variable
+ *
+ * This function implements the GetVariable runtime service.
+ *
+ * See the Unified Extensible Firmware Interface (UEFI) specification for
+ * details.
+ *
+ * @variable_name: name of the variable
+ * @vendor:vendor GUID
+ * @attributes:attributes of the variable
+ * @data_size: size of the buffer to which the variable value is copied
+ * @data:  buffer to which the variable value is copied
+ * Return: status code
+ */
 efi_status_t EFIAPI efi_get_variable(u16 *variable_name,
 const efi_guid_t *vendor, u32 *attributes,
 efi_uintn_t *data_size, void *data)
@@ -190,7 +235,21 @@ efi_status_t EFIAPI efi_get_variable(u16 *variable_name,
return EFI_EXIT(EFI_SUCCESS);
 }
 
-/* 
http://wiki.phoenix.com/wiki/index.php/EFI_RUNTIME_SERVICES#GetNextVariableName.28.29
 */
+/**
+ * efi_efi_get_next_variable() - get next UEFI variable
+ *
+ * This function implements the GetNextVariable runtime service.
+ *
+ * See the Unified Extensible Firmware Interface (UEFI) specification for
+ * details.
+ *
+ * @variable_name_size:on entry size of the buffer for the variable 
name, on
+ * exit the length of the name of the next variable
+ * @variable_name: on entry name of the current variable, on exit the name
+ * of the next variable
+ * @vendor:vendor GUID
+ * Return: status code
+ */
 efi_status_t EFIAPI efi_get_next_variable_name(efi_uintn_t *variable_name_size,
   u16 *variable_name,
   const efi_guid_t *vendor)
@@ -200,7 +259,21 @@ efi_status_t EFIAPI efi_get_next_variable_name(efi_uintn_t 
*variable_name_size,
return EFI_EXIT(EFI_DEVICE_ERROR);
 }
 
-/* 
http://wiki.phoenix.com/wiki/index.php/EFI_RUNTIME_SERVICES#SetVariable.28.29 */
+/**
+ * efi_efi_set_variable() - set value of a UEFI variable
+ *
+ * This function implements the SetVariable runtime service.
+ *
+ * See the Unified Extensible Firmware Interface (UEFI) specification for
+ * details.
+ *
+ * @variable_name: name of the variable
+ * @vendor:vendor GUID
+ * @attributes:attributes of the variable
+ * @data_size: size of the buffer with the variable value
+ * @data:  buffer with the variable value
+ * Return: status code
+ */
 

Re: [U-Boot] [RESEND] [PATCH v3 0/8] Convert i.MX7 WaRP7 ports to DM

2019-01-18 Thread Fabio Estevam
Hi Bryan,

On Fri, Jan 18, 2019 at 3:40 PM Bryan O'Donoghue
 wrote:
>
> V3-Resend:
> - Looks like this set got lost in the ether, resending.
>
> V3:
> - Fix Lucas' mail address "Auer, Lucas" makes git send-mail choke
>
> V2:
> - Add review-by as indicated - Peng Fan
> - Squash commit 4 and 5 from v1 - Peng Fan
> - Leave usdhc1 intact because of alias of mmc0 to usdhc3 - Bryan
> - Add correction for spelling mistake in imx7d-pinfunc.h - Lukas Auer
> - Imports imx7s-warp7.dts from kernel unmodified as a result of #1 - Bryan
>
> V1:
> This series does a minimal conversion of WaRP7 and the BL33 version of
> WaRP7 to the DM.
>
> Pinctrl, GPIO, I2C, Regulators, PMIC and MMC are converted. Later patches
> will convert USB and UART.
>
> Bryan O'Donoghue (8):
>   arm: dts: imx7: Correct spelling mistake in GPIO name
>   arm: dts: imx7s-warp: Import Linux warp7 dts
>   arm: imx7s-warp: Add DT file hooks
>   arm: imx7s-warp: Convert to DM MMC initialization
>   arm: dts: imx7s-warp: Create alias for mmc0 to 
>   warp7: defconfig: Switch on IMX7 GPIO/pinctrl for both ports
>   warp7: defconfig: Switch to DM for I2C
>   arm: imx7s-warp: Convert to DM PMIC

Looks good, thanks:

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


Re: [U-Boot] [PATCH 1/2] armv8: ls1088ardb: Update MAINTAINERS

2019-01-18 Thread York Sun
On 1/16/19 7:49 AM, Rajesh Bhagat wrote:
> From: York Sun 
> 
> Signed-off-by: York Sun 
> CC: Rajesh Bhagat 
> ---

This set is applied to fsl-qoriq master, awaiting upstream.

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


Re: [U-Boot] [PATCH] armv7: dts: ls1021a: Remove aliases property name warning

2019-01-18 Thread York Sun
On 1/5/19 12:06 AM, Rajesh Bhagat wrote:
> Remove aliases property name warning while compilation:
> Warning (alias_paths): /aliases: aliases property name must
> include only lowercase and '-'
> 
> Signed-off-by: Rajesh Bhagat 
> ---

Applied to fsl-qoriq master, awaiting upstream.
Thanks.

York

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


Re: [U-Boot] [u-boot][PATCH] ls1046aqds: Bypass xfi port fixup for KR mode

2019-01-18 Thread York Sun
On 12/10/18 1:27 AM, Florinel Iordache wrote:
> u-boot makes a fixup for LS1046AQDS board to setup the properties
>  'fixed-link' and 'phy-connection-type' to 'xgmii' but in case of
>  backplane mode this fixup is not correct because it causes the KR link
>  to fail and so it must be bypassed in order to keep the link in KR mode
>  as it is defined in DTS.
> 
> Signed-off-by: Florinel Iordache 
> ---


Applied to fsl-qoriq master, awaiting upstream.
Thanks.

York

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


Re: [U-Boot] [PATCH] armv8: fsl-layerscape: properly configure qdma ICID

2019-01-18 Thread York Sun
On 12/12/18 3:45 AM, laurentiu.tu...@nxp.com wrote:
> From: Laurentiu Tudor 
> 
> The ICIDs for the qdma device are not configured through SCFG but
> through some registers found in the actual device register block.
> 
> Signed-off-by: Laurentiu Tudor 
> ---


Applied to fsl-qoriq master, awaiting upstream.
Thanks.

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


Re: [U-Boot] [U-Boot, v1] mmc: fsl_esdhc: make get_cd work well in dm_mmc_ops

2019-01-18 Thread York Sun
On 12/14/18 2:02 AM, Yinbo Zhu wrote:
> This patch is to make get_cd work well when DM_MMC enabled
> 
> Signed-off-by: Yinbo Zhu 
> ---

Applied to fsl-qoriq master, awaiting upstream.
Thanks.

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


Re: [U-Boot] [PATCH] fsl-layerscape: dpaa: fix fsl-mc status in fdt with bootefi

2019-01-18 Thread York Sun
On 12/18/18 5:01 AM, Mian Yousaf Kaukab wrote:
> fsl-mc lazyapply command applies dpl from efi_exit_boot_services().
> Status of fsl-mc node in working fdt is updated at this stage.
> However, an efi application like grub may already have copied the fdt.
> So the updates to fdt done at efi_exit_boot_services() may not be visible
> to the OS. Fix it by updating fdt earlier if fsl-mc lazyapply command is
> used.
> 
> Fixes: b7b8410a8f (ls2080: Exit dpaa only right before exiting U-Boot)
> Signed-off-by: Mian Yousaf Kaukab 
> ---

Applied to fsl-qoriq master, awaiting upstream.
Thanks.

York

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


Re: [U-Boot] [PATCH 1/2] armv8: ls1043a: add SVR definitions for 23x23 package silicon

2019-01-18 Thread York Sun
On 12/19/18 10:31 PM, Z.q. Hou wrote:
> From: Hou Zhiqiang 
> 
> LS1043A/LS1023A 23x23 package silicon has different SVR:VAR_PER.
> 
> Signed-off-by: Hou Zhiqiang 


This set has been applied to fsl-qoriq master, awaiting upstream.
Thanks.

York

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


Re: [U-Boot] [RESEND PATCH 1/2] env: fix allow to build multiple environments

2019-01-18 Thread York Sun
On 1/11/19 11:30 PM, Rajesh Bhagat wrote:
> Patch fixes build error when enabling CONFIG_ENV_IS_IN_SPI_FLAS
> and CONFIG_ENV_IS_IN_MMC at the same time mentioned issue in
> below link:
> 
> Refer: https://lists.denx.de/pipermail/u-boot/2018-February/319565.html
> 
> build error when enabling CONFIG_ENV_IS_IN_SPI_FLASH and
> CONFIG_ENV_IS_IN_MMC at the same time.
> 
> Signed-off-by: Rajesh Bhagat 
> ---
> Depends on:
> https://patchwork.ozlabs.org/project/uboot/list/?series=83635
> 

This set has been applied to fsl-qoriq master, awaiting upstream.
Thanks.

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


Re: [U-Boot] [PATCH 1/7] armv8: fsl-layerscape: fixes for TFABOOT framework

2019-01-18 Thread York Sun
On 12/26/18 8:37 PM, Rajesh Bhagat wrote:
> Fixes for TFABOOT framework
> - update eMMC bootsrc to SD_MMC
> - Increase buffer size for mcinitcmd from 256 to 512
> - Fix mcinitcmd and bootcmd for Secure Boot
> 
> Signed-off-by: Pankit Garg 
> Signed-off-by: Rajesh Bhagat 
> ---

This set has been applied to fsl-qoriq master, awaiting upstream.
Thanks.

York

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


[U-Boot] Please pull u-boot-fsl-qoriq master

2019-01-18 Thread York Sun
Tom,

The following changes since commit d3689267f92c5956e09cc7d1baa4700141662bff:

  Prepare v2019.01 (2019-01-14 17:02:36 -0500)

are available in the Git repository at:

  git://git.denx.de/u-boot-fsl-qoriq.git tags/fsl-qoriq-for-v2019.04-rc1

for you to fetch changes up to a200ebea630002b14def4a015642fa341dc9cd11:

  armv8: ls2088ardb: Update MAINTAINERS (2019-01-17 13:17:51 -0800)


Add TFA boot flow for more boards

Add TFA boot defconfig for ls1088a and ls2088a.
Add dts fixup for PCIe endpoint and root complex.

Travis build log is https://travis-ci.org/yorksun/u-boot/builds/481076641


Florinel Iordache (1):
  ls1046aqds: Bypass xfi port fixup for KR mode

Hou Zhiqiang (2):
  armv8: ls1043a: add SVR definitions for 23x23 package silicon
  armv8: ls1043a: correct the PCIe INTx fixup

Laurentiu Tudor (1):
  armv8: fsl-layerscape: properly configure qdma ICID

Mian Yousaf Kaukab (1):
  fsl-layerscape: dpaa: fix fsl-mc status in fdt with bootefi

Pankit Garg (3):
  ls1043a: add support for nand-boot cmd for TFA
  armv8: ls1088ardb: Add TFABOOT support
  armv8: ls1088aqds: Add TFABOOT support

Rajesh Bhagat (7):
  armv8: fsl-layerscape: fixes for TFABOOT framework
  drivers: ifc: restore the legacy flow for IFC config
  armv8: ls2088ardb: Add TFABOOT support
  armv8: ls2088aqds: Add TFABOOT support
  env: fix allow to build multiple environments
  configs: update TFABOOT defconfigs for SD boot support
  armv7: dts: ls1021a: Remove aliases property name warning

Xiaowei Bao (3):
  pci: layerscape: Modify the EP and RC mode judge method
  pci: layerscape: Do not scan when PEX work in EP mode
  pci: layerscape: Add the dts fixup for EP and RC

Yinbo Zhu (1):
  mmc: fsl_esdhc: make get_cd work well in dm_mmc_ops

York Sun (2):
  armv8: ls1088ardb: Update MAINTAINERS
  armv8: ls2088ardb: Update MAINTAINERS

 arch/arm/cpu/armv8/fsl-layerscape/Kconfig  |  26 +--
 arch/arm/cpu/armv8/fsl-layerscape/cpu.c|   4 +-
 arch/arm/cpu/armv8/fsl-layerscape/fdt.c|   2 +-
 arch/arm/cpu/armv8/fsl-layerscape/soc.c|  13 +-
 arch/arm/dts/fsl-ls2088a-rdb-qspi.dts  |   4 +
 arch/arm/dts/ls1021a-iot.dtsi  |   6 +-
 arch/arm/dts/ls1021a-qds.dtsi  |  10 +-
 arch/arm/dts/ls1021a-twr.dtsi  |   6 +-
 .../arm/include/asm/arch-fsl-layerscape/fsl_icid.h |   6 +-
 .../include/asm/arch-fsl-layerscape/immap_lsch2.h  |   1 +
 arch/arm/include/asm/arch-fsl-layerscape/soc.h |   3 +
 board/freescale/ls1046aqds/eth.c   |  35 ++--
 board/freescale/ls1088a/MAINTAINERS|   5 +
 board/freescale/ls1088a/ddr.c  |  11 ++
 board/freescale/ls1088a/ls1088a.c  | 196
-
 board/freescale/ls2080a/ls2080a.c  |  10 +-
 board/freescale/ls2080aqds/MAINTAINERS |   2 +
 board/freescale/ls2080aqds/ddr.c   |  12 ++
 board/freescale/ls2080aqds/ls2080aqds.c|   3 +-
 board/freescale/ls2080ardb/MAINTAINERS |   3 +
 board/freescale/ls2080ardb/ddr.c   |  12 ++
 board/freescale/ls2080ardb/ls2080ardb.c|  40 -
 configs/ls1043aqds_tfa_defconfig   |   1 +
 configs/ls1043ardb_tfa_defconfig   |   1 +
 configs/ls1046aqds_tfa_defconfig   |   1 +
 configs/ls1046ardb_tfa_defconfig   |   1 +
 configs/ls1088aqds_tfa_defconfig   |  70 
 configs/ls1088ardb_tfa_SECURE_BOOT_defconfig   |  64 +++
 configs/ls1088ardb_tfa_defconfig   |  62 +++
 configs/ls2088aqds_tfa_defconfig   |  64 +++
 configs/ls2088ardb_tfa_SECURE_BOOT_defconfig   |  74 
 configs/ls2088ardb_tfa_defconfig   |  73 
 drivers/misc/fsl_ifc.c | 173 ++
 drivers/mmc/fsl_esdhc.c|   1 -
 drivers/net/fsl-mc/mc.c|   5 +
 drivers/pci/pcie_layerscape.c  |  21 +--
 drivers/pci/pcie_layerscape.h  |   1 +
 drivers/pci/pcie_layerscape_fixup.c|  25 ++-
 include/configs/ls1043a_common.h   |   2 +
 include/configs/ls1088a_common.h   |  11 +-
 include/configs/ls1088aqds.h   |  99 ++-
 include/configs/ls1088ardb.h   | 137 +-
 include/configs/ls2080a_common.h   |   8 +
 include/configs/ls2080aqds.h   |  40 -
 include/configs/ls2080ardb.h   | 137 +-
 include/environment.h  |   9 -
 include/fsl-mc/fsl_mc.h

[U-Boot] [PATCH 1/1] efi_loader: remove duplicate function mem2hex()

2019-01-18 Thread Heinrich Schuchardt
Replace duplicate function mem2hex() by inline function bin2hex().

Signed-off-by: Heinrich Schuchardt 
---
 lib/efi_loader/efi_variable.c | 15 +--
 1 file changed, 1 insertion(+), 14 deletions(-)

diff --git a/lib/efi_loader/efi_variable.c b/lib/efi_loader/efi_variable.c
index eea7f68b85..2ac27731fe 100644
--- a/lib/efi_loader/efi_variable.c
+++ b/lib/efi_loader/efi_variable.c
@@ -47,19 +47,6 @@
 
 #define PREFIX_LEN (strlen("efi_----_"))
 
-static char *mem2hex(char *hexstr, const u8 *mem, int count)
-{
-   static const char hexchars[] = "0123456789abcdef";
-
-   while (count-- > 0) {
-   u8 ch = *mem++;
-   *hexstr++ = hexchars[ch >> 4];
-   *hexstr++ = hexchars[ch & 0xf];
-   }
-
-   return hexstr;
-}
-
 static efi_status_t efi_to_native(char **native, const u16 *variable_name,
  const efi_guid_t *vendor)
 {
@@ -282,7 +269,7 @@ efi_status_t EFIAPI efi_set_variable(u16 *variable_name,
 
/* store payload: */
s += sprintf(s, "(blob)");
-   s = mem2hex(s, data, data_size);
+   s = bin2hex(s, data, data_size);
*s = '\0';
 
debug("%s: setting: %s=%s\n", __func__, native_name, val);
-- 
2.20.1

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


Re: [U-Boot] Porting u-boot to flash micro with proprietary (non-GPL) flash programming library

2019-01-18 Thread Ulf Samuelsson

Den 2019-01-14 kl. 17:55, skrev Ulf Samuelsson:
No Answer, so I am resending.

Question is:
How to port U-Boot to a flash microprocessor, where the vendor
does not supply source code to the library to program the internal flash 
without violating GPL?


Best Regards
Ulf Samuelsson

I am working in a project where we are considering using U-Boot as a 
bootloader for a flash microcontroller with an ARM Cortex-Rx core.

The chip is currently not supported by U-Boot.

The processor will not be running linux.

Our board will use
•    On Chip Flash
•    External Parallel Flash
•    External SPI Flash

Problem:
To program the internal flash, we need to use the a library from the CPU 
vendor which is only supplied to us in binary form.


Their license forbids us to link that library to open source code in a 
way that “contaminates” their code with GPL.


GPL forbids code to be linked with non-GPL code.

There are a few common exceptions to GPL when running linux.
1.    Linking with a shared library is OK.
2.    Using a device driver which was originally written for another
     OS. (I think this has been primarily used for graphics drivers)

Right now, our idea is to do runtime linking to the flash programming 
library similar to a shared library.


For various reasons, we plan to have our own first level bootloader 
which has very simple functionality, and this will be contain the vendor 
flash programming library.


U-boot, can when started, query the first level bootloader for the 
location of the entry points in the library and use the result to fill 
in a struct containing the address of the entry points. As far as I 
understand, this will not be static linking, so this should be allowed 
in GPL.


Q:    Is this a reasonable approach to the problem?

Even if acceptable, there may be several ways of implementing this.
Here is what I can think of:
==
1) CALLING THROUGH AN EXTERNAL CALL TABLE
The first level bootloader has a call table containing the absolute
addresses of the flash library entry points.
The u-boot driver will declare the table external, and define the table 
in the linker command file.
u-boot needs a header file describing the call table (probably 
implemented as a struct)


==
2) COPYING A STRUCT FROM A KNOWN ADDRESS IN THE FIRST LEVEL BOOTLOADER

The simplest way I can envision, is that the first level bootloader has 
a struct containing an field for each entrypoint. The field contains the 
absolute address of the entry point.


The struct is copied into an u-boot datastructure as is.
u-boot can call any entry by an indirect call.

   (*externallib.function1)();

For this to work, u-boot needs to know the absolute address of the table 
inside the first level bootloader.
Both u-boot and the first level bootloader will contain a definition of 
the struct in a header file.



==
3) COPYING A STRUCT FROM AN UNKNOWN ADDRESS THROUGH A SUPERVISOR CALL.
The first level bootloader will reside in flash at the reset address. It 
has a supervisor call exception vector. A specific supervisor call can

return the address of the struct above.

With this method, U-boot does not need to have internal knowledge of 
where the struct is located in the first level bootloader.


It does need to have a header file describing the struct.

==
4) CREATING A CALL TABLE BY QUERYING FOR EACH ENTRY.

This assumes that u-boot should not have any knowledge of a struct. 
Instead a supervisor call is implemented which sends a parameter 
defining which entry point of interest. The supervisor call returns the 
absolute address of the entry point.


==
Q:    Are any of the methods above violating the GPL license?
==
Q:    Is there another method which is recommended to handle the problem 
with proprietary vendor flash libraries?

==
Q:    If a processor contains functionality in a bootROM, for which 
source is not available. How can that be used in u-boot?





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


Re: [U-Boot] [PATCH v2 0/7] mmc: sunxi: Enable DM_MMC

2019-01-18 Thread Andre Przywara
On Fri, 18 Jan 2019 22:11:36 +0530
Jagan Teki  wrote:

Hi,

> On Fri, Jan 18, 2019 at 6:00 PM Andre Przywara
>  wrote:
> >
> > On Fri, 18 Jan 2019 07:17:41 -0500
> > Tom Rini  wrote:
> >  
> > > On Fri, Jan 18, 2019 at 11:53:49AM +, Andre Przywara wrote:  
> > > > On Thu, 17 Jan 2019 22:39:44 +0530
> > > > Jagan Teki  wrote:
> > > >  
> > > > > V2 for previous version[1] changes, for enabling DM_MMC
> > > > > on Allwinner platform.  
> > > >
> > > > So this is a neat and simple solution to the DM_MMC problem, to
> > > > the point where I am wondering why we actually need all those
> > > > DT driven clock and reset drivers in the first place.
> > > > But as I understand using plat data in this way is somewhat
> > > > frowned upon and considered deprecated (although it makes a lot
> > > > of sense in this context).
> > > >
> > > > Also, isn't this series independent from the clock gates/reset
> > > > patches? So why do you pile them on top of each other in
> > > > sunxi/next?
> > > >
> > > > If we really want to have the full featured DT driven clock and
> > > > reset support, why not use it together:
> > > > We keep the current mod clock support in the MMC driver, but
> > > > use the newly introduced clock gates and reset support via the
> > > > new clock driver, mostly replacing this series. This would give
> > > > us some test coverage of the new clock driver, while still
> > > > avoiding to rush the MMC mod clock implementation.
> > > >
> > > > Does that make sense? Happy to bake some patches for that on the
> > > > weekend.
> > > >
> > > > Btw: After talking to Tom on IRC, the DM_MMC deadline is
> > > > actually _after_ the 2019.04 release, so we don't need to have
> > > > DM_MMC support in this merge window.  
> > >
> > > To be clearer, I plan to mark as BROKEN and start saying we're
> > > going to remove stuff that isn't migrated, after the release.  So
> > > it would be good to get things moved this release that can be
> > > moved this release. Trying to use sunxi w/o MMC isn't going to be
> > > fun :)  
> >
> > Understood. I just gave it a quick try and it is actually quite
> > easy: We are pretty good already regarding gate clocks and resets,
> > with the new DM_CLK driver (v2 on the list). And using them in
> > sunxi_mmc.c is a piece of cake and very clean.
> > We just need to keep the MMC mod clock hack in (which this series
> > here does as well), but can still enable DM_MMC.
> > And for the next merge window we can tackle this by implementing the
> > MMC mod clock properly in the clock driver, then replacing the hack
> > with the normal clk_get_by_name(); clk_set_rate(); sequence.  
> 
> I tried with ahb clock and reset, with v2 version of CLK series and
> it's straightforward. but mmc clock may take some time along with
> series of testing. So I just windup this, instead of making some noise
> at last minute.

What do you mean with that, exactly?
Do you plan to take your platdata hack for 2019.04?
I don't like the idea of hacking something up that has no future and
will be reverted very soon anyway. Instead we should expose the
foundation part of the clock driver to people now for testing (as you
did by pushing it, thanks!), but including the MMC gates and resets.
I have this code ready, just need to test it on some SoCs this evening.

I think taking this change is the best compromise between changing
not too many things at once, yet still exposing new code to the users
for testing.

And yes, the MMC mod clock is somewhat of a beast, but if we have
just this in the next release, it should be easier to debug than when
we expose the whole of the new clock framework to MMC by then only.

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


[U-Boot] [RESEND] [PATCH v3 8/8] arm: imx7s-warp: Convert to DM PMIC

2019-01-18 Thread Bryan O'Donoghue
This patch converts the warp7 and warp7_bl33 board ports over to using the
DM PMIC model.

Signed-off-by: Bryan O'Donoghue 
Reviewed-by: Peng Fan 
Cc: Peng Fan 
Cc: Fabio Estevam 
Cc: Stefano Babic 
---
 board/warp7/warp7.c  | 27 +++
 configs/warp7_bl33_defconfig |  6 ++
 configs/warp7_defconfig  |  6 ++
 include/configs/warp7.h  |  6 --
 4 files changed, 23 insertions(+), 22 deletions(-)

diff --git a/board/warp7/warp7.c b/board/warp7/warp7.c
index 19f0df4d09..6ebeb08e33 100644
--- a/board/warp7/warp7.c
+++ b/board/warp7/warp7.c
@@ -64,29 +64,24 @@ int board_early_init_f(void)
return 0;
 }
 
-#ifdef CONFIG_POWER
-#define I2C_PMIC   0
-static struct pmic *pfuze;
+#ifdef CONFIG_DM_PMIC
 int power_init_board(void)
 {
-   int ret;
-   unsigned int reg, rev_id;
+   struct udevice *dev;
+   int ret, dev_id, rev_id;
 
-   ret = power_pfuze3000_init(I2C_PMIC);
-   if (ret)
+   ret = pmic_get("pfuze3000", );
+   if (ret == -ENODEV)
+   return 0;
+   if (ret != 0)
return ret;
 
-   pfuze = pmic_get("PFUZE3000");
-   ret = pmic_probe(pfuze);
-   if (ret)
-   return ret;
-
-   pmic_reg_read(pfuze, PFUZE3000_DEVICEID, );
-   pmic_reg_read(pfuze, PFUZE3000_REVID, _id);
-   printf("PMIC: PFUZE3000 DEV_ID=0x%x REV_ID=0x%x\n", reg, rev_id);
+   dev_id = pmic_reg_read(dev, PFUZE3000_DEVICEID);
+   rev_id = pmic_reg_read(dev, PFUZE3000_REVID);
+   printf("PMIC: PFUZE3000 DEV_ID=0x%x REV_ID=0x%x\n", dev_id, rev_id);
 
/* disable Low Power Mode during standby mode */
-   pmic_reg_write(pfuze, PFUZE3000_LDOGCTL, 0x1);
+   pmic_clrsetbits(dev, PFUZE3000_LDOGCTL, 0, 1);
 
return 0;
 }
diff --git a/configs/warp7_bl33_defconfig b/configs/warp7_bl33_defconfig
index 2e80011cbc..7b40bfbd6d 100644
--- a/configs/warp7_bl33_defconfig
+++ b/configs/warp7_bl33_defconfig
@@ -45,3 +45,9 @@ CONFIG_PINCTRL=y
 CONFIG_PINCTRL_IMX7=y
 CONFIG_DM_GPIO=y
 CONFIG_DM_I2C=y
+CONFIG_DM_PMIC=y
+CONFIG_DM_PMIC_PFUZE100=y
+CONFIG_DM_REGULATOR=y
+CONFIG_DM_REGULATOR_PFUZE100=y
+CONFIG_DM_REGULATOR_FIXED=y
+CONFIG_DM_REGULATOR_GPIO=y
diff --git a/configs/warp7_defconfig b/configs/warp7_defconfig
index 9f7dc73a11..d1c8e403a7 100644
--- a/configs/warp7_defconfig
+++ b/configs/warp7_defconfig
@@ -58,3 +58,9 @@ CONFIG_PINCTRL=y
 CONFIG_PINCTRL_IMX7=y
 CONFIG_DM_GPIO=y
 CONFIG_DM_I2C=y
+CONFIG_DM_PMIC=y
+CONFIG_DM_PMIC_PFUZE100=y
+CONFIG_DM_REGULATOR=y
+CONFIG_DM_REGULATOR_PFUZE100=y
+CONFIG_DM_REGULATOR_FIXED=y
+CONFIG_DM_REGULATOR_GPIO=y
diff --git a/include/configs/warp7.h b/include/configs/warp7.h
index 41eb8d7e1d..043f2861b6 100644
--- a/include/configs/warp7.h
+++ b/include/configs/warp7.h
@@ -129,12 +129,6 @@
 #define CONFIG_SYS_I2C_MXC
 #define CONFIG_SYS_I2C_SPEED   10
 
-/* PMIC */
-#define CONFIG_POWER
-#define CONFIG_POWER_I2C
-#define CONFIG_POWER_PFUZE3000
-#define CONFIG_POWER_PFUZE3000_I2C_ADDR0x08
-
 /* environment organization */
 #define CONFIG_ENV_SIZESZ_8K
 
-- 
2.20.0

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


[U-Boot] [RESEND] [PATCH v3 4/8] arm: imx7s-warp: Convert to DM MMC initialization

2019-01-18 Thread Bryan O'Donoghue
Converts from fixed initialization of MMC to DM initialization of MMC.

Signed-off-by: Bryan O'Donoghue 
Cc: Albert Aribaud 
Cc: Peng Fan 
Cc: Fabio Estevam 
Cc: Stefano Babic 
---
 board/warp7/warp7.c  | 34 --
 configs/warp7_bl33_defconfig |  1 +
 configs/warp7_defconfig  |  1 +
 3 files changed, 2 insertions(+), 34 deletions(-)

diff --git a/board/warp7/warp7.c b/board/warp7/warp7.c
index 3d32b3eb52..146d722b15 100644
--- a/board/warp7/warp7.c
+++ b/board/warp7/warp7.c
@@ -30,8 +30,6 @@ DECLARE_GLOBAL_DATA_PTR;
 
 #define UART_PAD_CTRL  (PAD_CTL_DSE_3P3V_49OHM | PAD_CTL_PUS_PU100KOHM | \
PAD_CTL_HYS)
-#define USDHC_PAD_CTRL (PAD_CTL_DSE_3P3V_32OHM | PAD_CTL_SRE_SLOW |\
-   PAD_CTL_HYS | PAD_CTL_PUE | PAD_CTL_PUS_PU47KOHM)
 
 #define I2C_PAD_CTRL   (PAD_CTL_DSE_3P3V_32OHM | PAD_CTL_SRE_SLOW | \
PAD_CTL_HYS | PAD_CTL_PUE | PAD_CTL_PUS_PU100KOHM)
@@ -74,43 +72,11 @@ static iomux_v3_cfg_t const uart1_pads[] = {
MX7D_PAD_UART1_RX_DATA__UART1_DCE_RX | MUX_PAD_CTRL(UART_PAD_CTRL),
 };
 
-static iomux_v3_cfg_t const usdhc3_pads[] = {
-   MX7D_PAD_SD3_CLK__SD3_CLK | MUX_PAD_CTRL(USDHC_PAD_CTRL),
-   MX7D_PAD_SD3_CMD__SD3_CMD | MUX_PAD_CTRL(USDHC_PAD_CTRL),
-   MX7D_PAD_SD3_DATA0__SD3_DATA0 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
-   MX7D_PAD_SD3_DATA1__SD3_DATA1 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
-   MX7D_PAD_SD3_DATA2__SD3_DATA2 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
-   MX7D_PAD_SD3_DATA3__SD3_DATA3 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
-   MX7D_PAD_SD3_DATA4__SD3_DATA4 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
-   MX7D_PAD_SD3_DATA5__SD3_DATA5 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
-   MX7D_PAD_SD3_DATA6__SD3_DATA6 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
-   MX7D_PAD_SD3_DATA7__SD3_DATA7 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
-   MX7D_PAD_SD3_RESET_B__SD3_RESET_B | MUX_PAD_CTRL(USDHC_PAD_CTRL),
-};
-
 static void setup_iomux_uart(void)
 {
imx_iomux_v3_setup_multiple_pads(uart1_pads, ARRAY_SIZE(uart1_pads));
 };
 
-static struct fsl_esdhc_cfg usdhc_cfg[1] = {
-   {USDHC3_BASE_ADDR},
-};
-
-int board_mmc_getcd(struct mmc *mmc)
-{
-   /* Assume uSDHC3 emmc is always present */
-   return 1;
-}
-
-int board_mmc_init(bd_t *bis)
-{
-   imx_iomux_v3_setup_multiple_pads(usdhc3_pads, ARRAY_SIZE(usdhc3_pads));
-   usdhc_cfg[0].sdhc_clk = mxc_get_clock(MXC_ESDHC3_CLK);
-
-   return fsl_esdhc_initialize(bis, _cfg[0]);
-}
-
 int board_early_init_f(void)
 {
setup_iomux_uart();
diff --git a/configs/warp7_bl33_defconfig b/configs/warp7_bl33_defconfig
index 12141fedd3..b2f943c775 100644
--- a/configs/warp7_bl33_defconfig
+++ b/configs/warp7_bl33_defconfig
@@ -24,6 +24,7 @@ CONFIG_OF_CONTROL=y
 CONFIG_CMD_FS_GENERIC=y
 CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_DFU_MMC=y
+CONFIG_DM_MMC=y
 CONFIG_FSL_ESDHC=y
 CONFIG_USB=y
 CONFIG_USB_EHCI_HCD=y
diff --git a/configs/warp7_defconfig b/configs/warp7_defconfig
index fee98dfbbe..65d801ffe2 100644
--- a/configs/warp7_defconfig
+++ b/configs/warp7_defconfig
@@ -33,6 +33,7 @@ CONFIG_OF_CONTROL=y
 CONFIG_CMD_FS_GENERIC=y
 CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_DFU_MMC=y
+CONFIG_DM_MMC=y
 CONFIG_FSL_ESDHC=y
 CONFIG_OPTEE=y
 CONFIG_USB=y
-- 
2.20.0

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


[U-Boot] [RESEND] [PATCH v3 5/8] arm: dts: imx7s-warp: Create alias for mmc0 to

2019-01-18 Thread Bryan O'Donoghue
This patch sets up an alias for mmc0 to usdhc3.

Before the DM conversion only usdhc3 was enabled and therefore it appeared
as MMC 0 to u-boot. After enabling MMC DM though usdhc3 defaults to MMC 2,
which left unattended would drive changes to existing warp7 bootscripts and
environment variables that rely on mmc 0.

Setup the alias of mmc0 and usdhc3 so that existing warp7 boot code will
work unmodified.

Signed-off-by: Bryan O'Donoghue 
Cc: Albert Aribaud 
Cc: Peng Fan 
Cc: Fabio Estevam 
Cc: Stefano Babic 
---
 arch/arm/dts/imx7s-warp.dts | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/dts/imx7s-warp.dts b/arch/arm/dts/imx7s-warp.dts
index f7ba2c0a24..d28b7ec715 100644
--- a/arch/arm/dts/imx7s-warp.dts
+++ b/arch/arm/dts/imx7s-warp.dts
@@ -17,6 +17,10 @@
reg = <0x8000 0x2000>;
};
 
+   aliases {
+   mmc0 = 
+   };
+
gpio-keys {
compatible = "gpio-keys";
pinctrl-0 = <_gpio>;
-- 
2.20.0

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


[U-Boot] [RESEND] [PATCH v3 6/8] warp7: defconfig: Switch on IMX7 GPIO/pinctrl for both ports

2019-01-18 Thread Bryan O'Donoghue
Switches on the IMX7 pinctrl driver for the warp7 and warp7_bl33 ports,
necessary to convert over to DM for this board.

It is necessary to switch on pinctrl and GPIO in one go.

Signed-off-by: Bryan O'Donoghue 
Cc: Peng Fan 
Cc: Fabio Estevam 
Cc: Stefano Babic 
---
 configs/warp7_bl33_defconfig | 3 +++
 configs/warp7_defconfig  | 3 +++
 2 files changed, 6 insertions(+)

diff --git a/configs/warp7_bl33_defconfig b/configs/warp7_bl33_defconfig
index b2f943c775..7f21bb4f53 100644
--- a/configs/warp7_bl33_defconfig
+++ b/configs/warp7_bl33_defconfig
@@ -41,3 +41,6 @@ CONFIG_USB_ETH_CDC=y
 CONFIG_USBNET_HOST_ADDR="de:ad:be:af:00:00"
 CONFIG_OPTEE_TZDRAM_SIZE=0x200
 CONFIG_DEFAULT_DEVICE_TREE="imx7s-warp"
+CONFIG_PINCTRL=y
+CONFIG_PINCTRL_IMX7=y
+CONFIG_DM_GPIO=y
diff --git a/configs/warp7_defconfig b/configs/warp7_defconfig
index 65d801ffe2..2d3171e42a 100644
--- a/configs/warp7_defconfig
+++ b/configs/warp7_defconfig
@@ -54,3 +54,6 @@ CONFIG_OPTEE_TZDRAM_SIZE=0x300
 CONFIG_OPTEE_TZDRAM_BASE=0x9d00
 CONFIG_BOOTM_OPTEE=y
 CONFIG_DEFAULT_DEVICE_TREE="imx7s-warp"
+CONFIG_PINCTRL=y
+CONFIG_PINCTRL_IMX7=y
+CONFIG_DM_GPIO=y
-- 
2.20.0

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


[U-Boot] [RESEND] [PATCH v3 7/8] warp7: defconfig: Switch to DM for I2C

2019-01-18 Thread Bryan O'Donoghue
This commit switches to DM I2C for warp7 and warp7_bl33 defconfigs.

Signed-off-by: Bryan O'Donoghue 
Reviewed-by: Peng Fan 
Cc: Peng Fan 
Cc: Fabio Estevam 
Cc: Stefano Babic 
---
 board/warp7/warp7.c  | 24 
 configs/warp7_bl33_defconfig |  1 +
 configs/warp7_defconfig  |  1 +
 include/configs/warp7.h  |  2 --
 4 files changed, 2 insertions(+), 26 deletions(-)

diff --git a/board/warp7/warp7.c b/board/warp7/warp7.c
index 146d722b15..19f0df4d09 100644
--- a/board/warp7/warp7.c
+++ b/board/warp7/warp7.c
@@ -31,26 +31,6 @@ DECLARE_GLOBAL_DATA_PTR;
 #define UART_PAD_CTRL  (PAD_CTL_DSE_3P3V_49OHM | PAD_CTL_PUS_PU100KOHM | \
PAD_CTL_HYS)
 
-#define I2C_PAD_CTRL   (PAD_CTL_DSE_3P3V_32OHM | PAD_CTL_SRE_SLOW | \
-   PAD_CTL_HYS | PAD_CTL_PUE | PAD_CTL_PUS_PU100KOHM)
-
-#ifdef CONFIG_SYS_I2C_MXC
-#define PC MUX_PAD_CTRL(I2C_PAD_CTRL)
-/* I2C1 for PMIC */
-static struct i2c_pads_info i2c_pad_info1 = {
-   .scl = {
-   .i2c_mode = MX7D_PAD_I2C1_SCL__I2C1_SCL | PC,
-   .gpio_mode = MX7D_PAD_I2C1_SCL__GPIO4_IO8 | PC,
-   .gp = IMX_GPIO_NR(4, 8),
-   },
-   .sda = {
-   .i2c_mode = MX7D_PAD_I2C1_SDA__I2C1_SDA | PC,
-   .gpio_mode = MX7D_PAD_I2C1_SDA__GPIO4_IO9 | PC,
-   .gp = IMX_GPIO_NR(4, 9),
-   },
-};
-#endif
-
 int dram_init(void)
 {
gd->ram_size = PHYS_SDRAM_SIZE;
@@ -130,10 +110,6 @@ int board_init(void)
/* address of boot parameters */
gd->bd->bi_boot_params = PHYS_SDRAM + 0x100;
 
-   #ifdef CONFIG_SYS_I2C_MXC
-   setup_i2c(0, CONFIG_SYS_I2C_SPEED, 0x7f, _pad_info1);
-   #endif
-
return 0;
 }
 
diff --git a/configs/warp7_bl33_defconfig b/configs/warp7_bl33_defconfig
index 7f21bb4f53..2e80011cbc 100644
--- a/configs/warp7_bl33_defconfig
+++ b/configs/warp7_bl33_defconfig
@@ -44,3 +44,4 @@ CONFIG_DEFAULT_DEVICE_TREE="imx7s-warp"
 CONFIG_PINCTRL=y
 CONFIG_PINCTRL_IMX7=y
 CONFIG_DM_GPIO=y
+CONFIG_DM_I2C=y
diff --git a/configs/warp7_defconfig b/configs/warp7_defconfig
index 2d3171e42a..9f7dc73a11 100644
--- a/configs/warp7_defconfig
+++ b/configs/warp7_defconfig
@@ -57,3 +57,4 @@ CONFIG_DEFAULT_DEVICE_TREE="imx7s-warp"
 CONFIG_PINCTRL=y
 CONFIG_PINCTRL_IMX7=y
 CONFIG_DM_GPIO=y
+CONFIG_DM_I2C=y
diff --git a/include/configs/warp7.h b/include/configs/warp7.h
index a391dfb5c1..41eb8d7e1d 100644
--- a/include/configs/warp7.h
+++ b/include/configs/warp7.h
@@ -126,9 +126,7 @@
(CONFIG_SYS_INIT_RAM_ADDR + CONFIG_SYS_INIT_SP_OFFSET)
 
 /* I2C configs */
-#define CONFIG_SYS_I2C
 #define CONFIG_SYS_I2C_MXC
-#define CONFIG_SYS_I2C_MXC_I2C1
 #define CONFIG_SYS_I2C_SPEED   10
 
 /* PMIC */
-- 
2.20.0

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


[U-Boot] [RESEND] [PATCH v3 2/8] arm: dts: imx7s-warp: Import Linux warp7 dts

2019-01-18 Thread Bryan O'Donoghue
This patch imports the Linux kernel warp7 dts as at upstream kernel commit
cf76c364a1e1.

Signed-off-by: Bryan O'Donoghue 
Cc: Albert Aribaud 
Cc: Peng Fan 
Cc: Fabio Estevam 
Cc: Stefano Babic 
---
 arch/arm/dts/imx7s-warp.dts | 438 
 1 file changed, 438 insertions(+)
 create mode 100644 arch/arm/dts/imx7s-warp.dts

diff --git a/arch/arm/dts/imx7s-warp.dts b/arch/arm/dts/imx7s-warp.dts
new file mode 100644
index 00..f7ba2c0a24
--- /dev/null
+++ b/arch/arm/dts/imx7s-warp.dts
@@ -0,0 +1,438 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2016 NXP Semiconductors.
+ * Author: Fabio Estevam 
+ */
+
+/dts-v1/;
+
+#include 
+#include "imx7s.dtsi"
+
+/ {
+   model = "Warp i.MX7 Board";
+   compatible = "warp,imx7s-warp", "fsl,imx7s";
+
+   memory@8000 {
+   reg = <0x8000 0x2000>;
+   };
+
+   gpio-keys {
+   compatible = "gpio-keys";
+   pinctrl-0 = <_gpio>;
+   autorepeat;
+
+   back {
+   label = "Back";
+   gpios = < 1 GPIO_ACTIVE_HIGH>;
+   linux,code = ;
+   wakeup-source;
+   };
+   };
+
+   reg_brcm: regulator-brcm {
+   compatible = "regulator-fixed";
+   enable-active-high;
+   gpio = < 10 GPIO_ACTIVE_HIGH>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_brcm_reg>;
+   regulator-name = "brcm_reg";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   startup-delay-us = <20>;
+   };
+
+   reg_bt: regulator-bt {
+   compatible = "regulator-fixed";
+   pinctrl-names = "default";
+   pinctrl-0 = <_bt_reg>;
+   enable-active-high;
+   gpio = < 17 GPIO_ACTIVE_HIGH>;
+   regulator-name = "bt_reg";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   regulator-always-on;
+   };
+
+   sound {
+   compatible = "simple-audio-card";
+   simple-audio-card,name = "imx7-sgtl5000";
+   simple-audio-card,format = "i2s";
+   simple-audio-card,bitclock-master = <_master>;
+   simple-audio-card,frame-master = <_master>;
+   simple-audio-card,cpu {
+   sound-dai = <>;
+   };
+
+   dailink_master: simple-audio-card,codec {
+   sound-dai = <>;
+   clocks = < IMX7D_AUDIO_MCLK_ROOT_CLK>;
+   };
+   };
+};
+
+ {
+   assigned-clocks = < IMX7D_PLL_AUDIO_POST_DIV>;
+   assigned-clock-rates = <884736000>;
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_i2c1>;
+   status = "okay";
+
+   pmic: pfuze3000@8 {
+   compatible = "fsl,pfuze3000";
+   reg = <0x08>;
+
+   regulators {
+   sw1a_reg: sw1a {
+   regulator-min-microvolt = <70>;
+   regulator-max-microvolt = <1475000>;
+   regulator-boot-on;
+   regulator-always-on;
+   regulator-ramp-delay = <6250>;
+   };
+
+   /* use sw1c_reg to align with pfuze100/pfuze200 */
+   sw1c_reg: sw1b {
+   regulator-min-microvolt = <70>;
+   regulator-max-microvolt = <1475000>;
+   regulator-boot-on;
+   regulator-always-on;
+   regulator-ramp-delay = <6250>;
+   };
+
+   sw2_reg: sw2 {
+   regulator-min-microvolt = <150>;
+   regulator-max-microvolt = <185>;
+   regulator-boot-on;
+   regulator-always-on;
+   };
+
+   sw3a_reg: sw3 {
+   regulator-min-microvolt = <90>;
+   regulator-max-microvolt = <165>;
+   regulator-boot-on;
+   regulator-always-on;
+   };
+
+   swbst_reg: swbst {
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <515>;
+   };
+
+   snvs_reg: vsnvs {
+   regulator-min-microvolt = <100>;
+   regulator-max-microvolt = <300>;
+   regulator-boot-on;
+

[U-Boot] [RESEND] [PATCH v3 1/8] arm: dts: imx7: Correct spelling mistake in GPIO name

2019-01-18 Thread Bryan O'Donoghue
As pointed out by Lucas WDOD1_WDOG_ANY should be WDOG1_WDOG_ANY. Once
corrected we can import the latest kernel DTS unmodified.

Signed-off-by: Bryan O'Donoghue 
Reported-by: Lukas Auer 
---
 arch/arm/dts/imx7d-pinfunc.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/dts/imx7d-pinfunc.h b/arch/arm/dts/imx7d-pinfunc.h
index f6f7e78f88..f2493bc63d 100644
--- a/arch/arm/dts/imx7d-pinfunc.h
+++ b/arch/arm/dts/imx7d-pinfunc.h
@@ -17,9 +17,9 @@
 
 #define MX7D_PAD_LPSR_GPIO1_IO00__GPIO1_IO0   0x 
0x0030 0x 0x0 0x0
 #define MX7D_PAD_LPSR_GPIO1_IO00__PWM4_OUT0x 
0x0030 0x 0x1 0x0
-#define MX7D_PAD_LPSR_GPIO1_IO00__WDOD1_WDOG_ANY  0x 
0x0030 0x 0x2 0x0
-#define MX7D_PAD_LPSR_GPIO1_IO00__WDOD1_WDOG_B0x 
0x0030 0x 0x3 0x0
-#define MX7D_PAD_LPSR_GPIO1_IO00__WDOD1_WDOG__RST_B_DEB   0x 
0x0030 0x 0x4 0x0
+#define MX7D_PAD_LPSR_GPIO1_IO00__WDOG1_WDOG_ANY  0x 
0x0030 0x 0x2 0x0
+#define MX7D_PAD_LPSR_GPIO1_IO00__WDOG1_WDOG_B0x 
0x0030 0x 0x3 0x0
+#define MX7D_PAD_LPSR_GPIO1_IO00__WDOG1_WDOG__RST_B_DEB   0x 
0x0030 0x 0x4 0x0
 #define MX7D_PAD_LPSR_GPIO1_IO01__GPIO1_IO1   0x0004 
0x0034 0x 0x0 0x0
 #define MX7D_PAD_LPSR_GPIO1_IO01__PWM1_OUT0x0004 
0x0034 0x 0x1 0x0
 #define MX7D_PAD_LPSR_GPIO1_IO01__CCM_ENET_REF_CLK3   0x0004 
0x0034 0x 0x2 0x0
-- 
2.20.0

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


[U-Boot] [RESEND] [PATCH v3 3/8] arm: imx7s-warp: Add DT file hooks

2019-01-18 Thread Bryan O'Donoghue
This patch adds DT file hooks for imx7s-warp.dtb to the warp7 and
warp7_bl33 builds.

Signed-off-by: Bryan O'Donoghue 
Reviewed-by: Peng Fan 
Cc: Albert Aribaud 
Cc: Peng Fan 
Cc: Fabio Estevam 
Cc: Stefano Babic 
---
 arch/arm/dts/Makefile| 3 ++-
 configs/warp7_bl33_defconfig | 3 ++-
 configs/warp7_defconfig  | 3 ++-
 3 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index dda4e59491..4fe7e90902 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -460,7 +460,8 @@ dtb-$(CONFIG_MX6ULL) += imx6ull-14x14-evk.dtb
 
 dtb-$(CONFIG_MX7) += imx7-colibri.dtb \
imx7d-sdb.dtb \
-   imx7d-sdb-qspi.dtb
+   imx7d-sdb-qspi.dtb \
+   imx7s-warp.dtb
 
 dtb-$(CONFIG_ARCH_MX7ULP) += imx7ulp-evk.dtb
 
diff --git a/configs/warp7_bl33_defconfig b/configs/warp7_bl33_defconfig
index a568c6d10e..12141fedd3 100644
--- a/configs/warp7_bl33_defconfig
+++ b/configs/warp7_bl33_defconfig
@@ -20,6 +20,7 @@ CONFIG_CMD_EXT2=y
 CONFIG_CMD_EXT4=y
 CONFIG_CMD_EXT4_WRITE=y
 CONFIG_CMD_FAT=y
+CONFIG_OF_CONTROL=y
 CONFIG_CMD_FS_GENERIC=y
 CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_DFU_MMC=y
@@ -37,5 +38,5 @@ CONFIG_USB_GADGET_DOWNLOAD=y
 CONFIG_USB_ETHER=y
 CONFIG_USB_ETH_CDC=y
 CONFIG_USBNET_HOST_ADDR="de:ad:be:af:00:00"
-CONFIG_OF_LIBFDT=y
 CONFIG_OPTEE_TZDRAM_SIZE=0x200
+CONFIG_DEFAULT_DEVICE_TREE="imx7s-warp"
diff --git a/configs/warp7_defconfig b/configs/warp7_defconfig
index 4d443295ba..fee98dfbbe 100644
--- a/configs/warp7_defconfig
+++ b/configs/warp7_defconfig
@@ -29,6 +29,7 @@ CONFIG_CMD_EXT2=y
 CONFIG_CMD_EXT4=y
 CONFIG_CMD_EXT4_WRITE=y
 CONFIG_CMD_FAT=y
+CONFIG_OF_CONTROL=y
 CONFIG_CMD_FS_GENERIC=y
 CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_DFU_MMC=y
@@ -47,8 +48,8 @@ CONFIG_USB_GADGET_DOWNLOAD=y
 CONFIG_USB_ETHER=y
 CONFIG_USB_ETH_CDC=y
 CONFIG_USBNET_HOST_ADDR="de:ad:be:af:00:00"
-CONFIG_OF_LIBFDT=y
 CONFIG_OPTEE_LOAD_ADDR=0x8400
 CONFIG_OPTEE_TZDRAM_SIZE=0x300
 CONFIG_OPTEE_TZDRAM_BASE=0x9d00
 CONFIG_BOOTM_OPTEE=y
+CONFIG_DEFAULT_DEVICE_TREE="imx7s-warp"
-- 
2.20.0

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


[U-Boot] [RESEND] [PATCH v3 0/8] Convert i.MX7 WaRP7 ports to DM

2019-01-18 Thread Bryan O'Donoghue
V3-Resend:
- Looks like this set got lost in the ether, resending.

V3:
- Fix Lucas' mail address "Auer, Lucas" makes git send-mail choke

V2:
- Add review-by as indicated - Peng Fan
- Squash commit 4 and 5 from v1 - Peng Fan
- Leave usdhc1 intact because of alias of mmc0 to usdhc3 - Bryan
- Add correction for spelling mistake in imx7d-pinfunc.h - Lukas Auer
- Imports imx7s-warp7.dts from kernel unmodified as a result of #1 - Bryan

V1:
This series does a minimal conversion of WaRP7 and the BL33 version of
WaRP7 to the DM.

Pinctrl, GPIO, I2C, Regulators, PMIC and MMC are converted. Later patches
will convert USB and UART.

Bryan O'Donoghue (8):
  arm: dts: imx7: Correct spelling mistake in GPIO name
  arm: dts: imx7s-warp: Import Linux warp7 dts
  arm: imx7s-warp: Add DT file hooks
  arm: imx7s-warp: Convert to DM MMC initialization
  arm: dts: imx7s-warp: Create alias for mmc0 to 
  warp7: defconfig: Switch on IMX7 GPIO/pinctrl for both ports
  warp7: defconfig: Switch to DM for I2C
  arm: imx7s-warp: Convert to DM PMIC

 arch/arm/dts/Makefile|   3 +-
 arch/arm/dts/imx7d-pinfunc.h |   6 +-
 arch/arm/dts/imx7s-warp.dts  | 442 +++
 board/warp7/warp7.c  |  85 +--
 configs/warp7_bl33_defconfig |  14 +-
 configs/warp7_defconfig  |  14 +-
 include/configs/warp7.h  |   8 -
 7 files changed, 484 insertions(+), 88 deletions(-)
 create mode 100644 arch/arm/dts/imx7s-warp.dts

-- 
2.20.0

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


Re: [U-Boot] [PATCH v1 1/1] arm64: dt: poplar: add optee node

2019-01-18 Thread Simon Glass
On Thu, 17 Jan 2019 at 07:37, Igor Opaniuk  wrote:
>
> As Poplar supports running TF-A with OP-TEE as BL32
> payload, add op-tee node in DT, which enables usage of
> OP-TEE driver (which provides an interface for requesting services
> from OP-TEE).
>
> Signed-off-by: Igor Opaniuk 
> ---
>  arch/arm/dts/hi3798cv200-poplar.dts | 7 +++
>  1 file changed, 7 insertions(+)

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


[U-Boot] [PATCH] cmd: image_info: Add checking of default FIT config

2019-01-18 Thread Bryan O'Donoghue
This patch adds a check for the default FIT config to iminfo. Once applied
any signing of the config will show a pass fail similar to rsa+/rsa-.

Output looks like this:

   Hash(es) for Image 0 (kernel@1): sha1+
   Hash(es) for Image 1 (f...@imx7s-warp.dtb): sha1+
   Hash(es) for Image 2 (ramdisk@1): sha1+
   Hash(es) for Image 3 (bootscr): sha1+
   Hash for default configuration: sha1,rsa2048:mbl-fit-rot-key+

Signed-off-by: Bryan O'Donoghue 
Cc: Jun Nie 
Cc: Simon Glass 
Cc: Tom Rini 
Reviewed-by: Simon Glass 
---
 cmd/bootm.c | 17 +
 1 file changed, 17 insertions(+)

diff --git a/cmd/bootm.c b/cmd/bootm.c
index c3a063474a..b3bd236165 100644
--- a/cmd/bootm.c
+++ b/cmd/bootm.c
@@ -244,6 +244,9 @@ static int do_iminfo(cmd_tbl_t *cmdtp, int flag, int argc, 
char * const argv[])
 
 static int image_info(ulong addr)
 {
+#if defined(CONFIG_FIT)
+   int cfg_noffset;
+#endif
void *hdr = (void *)addr;
 
printf("\n## Checking Image at %08lx ...\n", addr);
@@ -294,6 +297,20 @@ static int image_info(ulong addr)
return 1;
}
 
+   cfg_noffset = fit_conf_get_node(hdr, NULL);
+   if (!cfg_noffset) {
+   printf("Could not find configuration node: %s\n",
+  fdt_strerror(cfg_noffset));
+   return 1;
+   }
+
+   puts("   Hash for default configuration: ");
+   if (fit_config_verify(hdr, cfg_noffset)) {
+   puts("Unable to verify default fit config\n");
+   return 1;
+   }
+   puts("\n");
+
return 0;
 #endif
default:
-- 
2.20.1

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


Re: [U-Boot] [PATCH v6.1 15/20] arm: sunxi: Enable CLK, RESET

2019-01-18 Thread Jagan Teki
On Fri, Jan 11, 2019 at 4:48 PM Jagan Teki  wrote:
>
> CLK and DM_RESET drivers are now available for all of
> the Allwinner platforms, so enable them in arch/arm/Kconfig
>
> Enabling CLK will select DM_RESET by default.
>
> Signed-off-by: Jagan Teki 
> ---

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


Re: [U-Boot] [PATCH v6 00/20] clk: Add Allwinner CLK, RESET support

2019-01-18 Thread Jagan Teki
On Fri, Jan 11, 2019 at 12:13 AM Jagan Teki  wrote:
>
> This series fixes few comments from previous verision for Allwinner
> clock gates, resets and dropped clock tree patches which I have
> mentioned on previous series[1].
>
> Changes for v6:
> - use ARRAY_SIZE for reset array instead of number
> - remove comment from sunxi_reset_request
> - Enable CONFIG_USB_OHCI_HCD on few missing boards
> - collect Marek Acked-by
>
> Any inputs,
> Jagan.
>
> [1] https://patchwork.ozlabs.org/cover/1019654/
>
> Jagan Teki (20):
>   clk: Add Allwinner A64 CLK driver
>   reset: Add Allwinner RESET driver
>   clk: sunxi: Add Allwinner H3/H5 CLK driver
>   clk: sunxi: Add Allwinner A10/A20 CLK driver
>   clk: sunxi: Add Allwinner A10s/A13 CLK driver
>   clk: sunxi: Add Allwinner A31 CLK driver
>   clk: sunxi: Add Allwinner A23/A33 CLK driver
>   clk: sunxi: Add Allwinner A83T CLK driver
>   clk: sunxi: Add Allwinner R40 CLK driver
>   clk: sunxi: Add Allwinner V3S CLK driver
>   clk: sunxi: Implement UART clocks
>   clk: sunxi: Implement UART resets
>   clk: sunxi: Add Allwinner H6 CLK driver
>   sunxi: A64: Update sun50i-a64-ccu.h
>   sunxi: Enable CLK
>   phy: sun4i-usb: Use CLK and RESET support
>   reset: Add reset valid
>   musb-new: sunxi: Use CLK and RESET support
>   sunxi: usb: Switch to Generic host controllers
>   usb: host: Drop [e-o]hci-sunxi drivers

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


Re: [U-Boot] [PATCH 1/2] ARM: dts: sun8i: Update A80 dts(i) from Linux-v4.18-rc3

2019-01-18 Thread Jagan Teki
On Fri, Jan 11, 2019 at 4:46 PM Jagan Teki  wrote:
>
> Update all A80 devicetree dtsi and dtsi files from
> Linux-v4.18-rc3 with below commits.
>
> arch/arm/boot/dts/sun9i-a80*:
>
> commit 190e3138f9577885691540dca59c2f07540bde04
> Merge: cafc87023b0d a7affb13b271
> Author: Arnd Bergmann 
> Date:   Tue Mar 27 14:58:00 2018 +0200
>
> Merge tag 'sunxi-h3-h5-for-4.17' of 
> ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/sunxi/linux into next/dt
>
> include/dt-bindings/*/sun9i-a80-*:
>
> commit 783ab76ae553abc23f80ef7511052d055697531b
> Author: Chen-Yu Tsai 
> Date:   Sat Jan 28 20:22:36 2017 +0800
>
> clk: sunxi-ng: Add A80 Display Engine CCU
>
> Note: sun9i-a80-cx-a99.dts is updated only uart0, since the same
> dts is not available in Linux.
>
> Signed-off-by: Jagan Teki 
> ---

Applied both to u-boot-sunxi/master
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] am335x: EFI: tftp: CACHE: Misaligned operation at range [9ce7e470, 9ce7e4b0]

2019-01-18 Thread Matwey V. Kornilov
Hello,

I am running u-boot 2018.11 at BeagleBoneBlack with the following setup.

I have EFI Grub image with tftp module enabled. This image is deployed
by tftp and it is advertised by dhcp. When started Grub loads Linux
kernel and initrd and boots OS.

Such setup works fine with qemu-arm and OVMF (TianoCore EFI).

Now, I am trying to use BeagleBoneBlack and do the following:

=> run findfdt
=> run loadfdt
=> print fdt_addr_r
fdt_addr_r=0x8800
=> dhcp
link up on port 0, speed 100, full duplex
BOOTP broadcast 1
DHCP client bound to address 192.168.185.197 (20 ms)
Using cpsw device
TFTP from server 192.168.185.80; our IP address is 192.168.185.197
Filename '/bootarm.efi'.
Load address: 0x8200
Loading: ###
 4.1 MiB/s
done
Bytes transferred = 448512 (6d800 hex)
=> bootefi 0x8200 0x8800

Then I see Grub menu for a moment and the console is constantly flooding
be the following messages with very high rate (dozens of lines per second):

CACHE: Misaligned operation at range [9ce7e470, 9ce7e4b0]

At the same time I see in tcpdump that there is ongoing exchange between
tftp server and the board. After some time I see that the kernel is
booting and CACHE messages disappear:

bash-4.4# uname -a
Linux 88cc78c5ecd6 5.0.0-rc1-default+ #1 SMP PREEMPT Tue Jan 15 19:23:17
MSK 2019 armv7l armv7l armv7l GNU/Linux

The question is how to fix this CACHE messages or their reason?

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


Re: [U-Boot] [PATCH v2 0/7] mmc: sunxi: Enable DM_MMC

2019-01-18 Thread Jagan Teki
On Fri, Jan 18, 2019 at 6:00 PM Andre Przywara  wrote:
>
> On Fri, 18 Jan 2019 07:17:41 -0500
> Tom Rini  wrote:
>
> > On Fri, Jan 18, 2019 at 11:53:49AM +, Andre Przywara wrote:
> > > On Thu, 17 Jan 2019 22:39:44 +0530
> > > Jagan Teki  wrote:
> > >
> > > > V2 for previous version[1] changes, for enabling DM_MMC
> > > > on Allwinner platform.
> > >
> > > So this is a neat and simple solution to the DM_MMC problem, to the
> > > point where I am wondering why we actually need all those DT driven
> > > clock and reset drivers in the first place.
> > > But as I understand using plat data in this way is somewhat frowned
> > > upon and considered deprecated (although it makes a lot of sense in
> > > this context).
> > >
> > > Also, isn't this series independent from the clock gates/reset
> > > patches? So why do you pile them on top of each other in sunxi/next?
> > >
> > > If we really want to have the full featured DT driven clock and
> > > reset support, why not use it together:
> > > We keep the current mod clock support in the MMC driver, but use the
> > > newly introduced clock gates and reset support via the new clock
> > > driver, mostly replacing this series. This would give us some test
> > > coverage of the new clock driver, while still avoiding to rush the
> > > MMC mod clock implementation.
> > >
> > > Does that make sense? Happy to bake some patches for that on the
> > > weekend.
> > >
> > > Btw: After talking to Tom on IRC, the DM_MMC deadline is actually
> > > _after_ the 2019.04 release, so we don't need to have DM_MMC
> > > support in this merge window.
> >
> > To be clearer, I plan to mark as BROKEN and start saying we're going
> > to remove stuff that isn't migrated, after the release.  So it would
> > be good to get things moved this release that can be moved this
> > release. Trying to use sunxi w/o MMC isn't going to be fun :)
>
> Understood. I just gave it a quick try and it is actually quite easy: We
> are pretty good already regarding gate clocks and resets, with the new
> DM_CLK driver (v2 on the list). And using them in sunxi_mmc.c is a piece
> of cake and very clean.
> We just need to keep the MMC mod clock hack in (which this series here
> does as well), but can still enable DM_MMC.
> And for the next merge window we can tackle this by implementing the
> MMC mod clock properly in the clock driver, then replacing the hack
> with the normal clk_get_by_name(); clk_set_rate(); sequence.

I tried with ahb clock and reset, with v2 version of CLK series and
it's straightforward. but mmc clock may take some time along with
series of testing. So I just windup this, instead of making some noise
at last minute.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH] ARM: chiliboard: enable DM_SPI

2019-01-18 Thread Marcin Niestroj
Add DM_SPI to suppress build warning about dm conversion.

Signed-off-by: Marcin Niestroj 
---
 configs/chiliboard_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/chiliboard_defconfig b/configs/chiliboard_defconfig
index 02eb324811..ceba006e0c 100644
--- a/configs/chiliboard_defconfig
+++ b/configs/chiliboard_defconfig
@@ -42,6 +42,7 @@ CONFIG_DM_ETH=y
 CONFIG_MII=y
 CONFIG_DRIVER_TI_CPSW=y
 CONFIG_SPI=y
+CONFIG_DM_SPI=y
 CONFIG_OMAP3_SPI=y
 CONFIG_TIMER=y
 CONFIG_OMAP_TIMER=y
-- 
2.20.1

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


Re: [U-Boot] [PATCH 19/26] configs: mx6sabresd: Add SPL FIT and DM support

2019-01-18 Thread Tom Rini
On Fri, Jan 18, 2019 at 03:26:42PM +, Abel Vesa wrote:
> On 19-01-18 13:16:07, Fabio Estevam wrote:
> > Hi Abel,
> > 
> > On Fri, Jan 18, 2019 at 12:59 PM Abel Vesa  wrote:
> > 
> > > +CONFIG_OF_CONTROL=y
> > > +CONFIG_SPL_OF_CONTROL=y
> > > +CONFIG_DEFAULT_DEVICE_TREE="imx6q-sabresd"
> > 
> > Does this mean that only imx6q-sabresd variant is supported after this
> > series is applied?
> > 
> > We still need to support imx6dl/imx6qp sabresd in the same binary as
> > we currently do today.
> 
> Hmmm, so all the dtbs get built, trouble is we need to specify which dtb gets
> used by SPL. This is why the DEFAULT_DEVICE_TREE gets set.
> 
> A solution to do what you're asking is to have a dtb in SPL that works for
> all socs (dl/qp/q) for each board (sabreauto/sabresd). I'm afraid it might
> get too big to fit in sram. I'll give it a try tomorrow.
> 
> As for the u-boot proper, in order to have one u-boot.itb file that works
> on all socs we need to support MULTI_FIT in u-boot proper and make u-boot
> chose from the fit table the right dtb. I'll try to do that for the next
> version of this patchset. I'll keep you up to date with the development.

Please note that this isn't the first family to have this problem.
Please see the TI Keystone 2 families and CONFIG_DTB_RESELECT as I would
swear we can go from a "good enough for all" to "correct for what we're
on" DTB in both SPL and U-Boot.  And then yes, you end up compressing
the DTBs too so that we can fit things into limited space.  And if we
still run into problems, which we might well still, lets talk.  And it
might indeed end up making the most sense to make up a "just enough for
SPL for everyone" DTB or set of DTBs too.

-- 
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 01/26] usb: Rename SPL_USB_SUPPORT to SPL_USB_STORAGE

2019-01-18 Thread Abel Vesa
On 19-01-18 10:03:14, Tom Rini wrote:
> On Fri, Jan 18, 2019 at 02:53:15PM +, 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 
> 
> Thanks!
> 
> Reviewed-by: Tom Rini 
> 
> Do you have a follow-up patch to then disable this option and remove the
> line you added to mx6_spl.h as you can't do SPL from USB storage devices
> on these platforms?
> 

Hmm, I missed that in. I'm sure there will be a need for a new version
of this patchset so I'll remove that in the next version.

> -- 
> Tom

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


Re: [U-Boot] [PATCH 11/26] arm: dts: Add imx6q-sabreauto dts file

2019-01-18 Thread Fabio Estevam
On Fri, Jan 18, 2019 at 1:07 PM Abel Vesa  wrote:
>
> Add imx6q-sabreauto dts support from Linux.

Please specify the kernel version you used.

> diff --git a/arch/arm/dts/imx6q-sabreauto.dts 
> b/arch/arm/dts/imx6q-sabreauto.dts
> new file mode 100644
> index 000..334b924
> --- /dev/null
> +++ b/arch/arm/dts/imx6q-sabreauto.dts
> @@ -0,0 +1,25 @@
> +/*
> + * Copyright 2012 Freescale Semiconductor, Inc.
> + * Copyright 2011 Linaro Ltd.
> + *
> + * The code contained herein is licensed under the GNU General Public
> + * License. You may obtain a copy of the GNU General Public License
> + * Version 2 or later at the following locations:

In 4.20 version we have switched to SPDX, so I would recommend you to
use the dts files from 4.20 at least.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 19/26] configs: mx6sabresd: Add SPL FIT and DM support

2019-01-18 Thread Abel Vesa
On 19-01-18 13:16:07, Fabio Estevam wrote:
> Hi Abel,
> 
> On Fri, Jan 18, 2019 at 12:59 PM Abel Vesa  wrote:
> 
> > +CONFIG_OF_CONTROL=y
> > +CONFIG_SPL_OF_CONTROL=y
> > +CONFIG_DEFAULT_DEVICE_TREE="imx6q-sabresd"
> 
> Does this mean that only imx6q-sabresd variant is supported after this
> series is applied?
> 
> We still need to support imx6dl/imx6qp sabresd in the same binary as
> we currently do today.

Hmmm, so all the dtbs get built, trouble is we need to specify which dtb gets
used by SPL. This is why the DEFAULT_DEVICE_TREE gets set.

A solution to do what you're asking is to have a dtb in SPL that works for
all socs (dl/qp/q) for each board (sabreauto/sabresd). I'm afraid it might
get too big to fit in sram. I'll give it a try tomorrow.

As for the u-boot proper, in order to have one u-boot.itb file that works
on all socs we need to support MULTI_FIT in u-boot proper and make u-boot
chose from the fit table the right dtb. I'll try to do that for the next
version of this patchset. I'll keep you up to date with the development.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


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

2019-01-18 Thread Michal Simek
On 18. 01. 19 16:13, 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.
> For getting this work it would be necessary to setup dev->req_seq in
> pre_bind function.
> 
> int i2c_pre_bind(struct udevice *dev)
> {
>   if (dev->req_seq == -1) {
>   dev->req_seq = ++i2c_highest_id;
>   }
>   return 0;
> }
> 
> It can be done also in post_bind but it looks quite weird that
> controller has highest ID then i2c-mux sub-buses connected to it.
> For example:
> ZynqMP> i2c bus
> Bus 3: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 0:i2c@ff02->i2c-mux@75->i2c@0
> Bus 1:i2c@ff02->i2c-mux@75->i2c@1
> Bus 2:i2c@ff02->i2c-mux@75->i2c@2
> Bus 17:   i2c@ff03
>74: i2c-mux@74, offset len 1, flags 0
>75: i2c-mux@75, offset len 1, flags 0
> Bus 4:i2c@ff03->i2c-mux@74->i2c@0
> Bus 5:i2c@ff03->i2c-mux@74->i2c@1
> Bus 6:i2c@ff03->i2c-mux@74->i2c@2
> Bus 7:i2c@ff03->i2c-mux@74->i2c@3
> ...
> 
> That's why I think it would be better to introduce pre_bind hooks and
> call it in device_bind_common() before binding childs.

I have retested again and this is working properly.

This is the patch.

diff --git a/drivers/i2c/i2c-uclass.c b/drivers/i2c/i2c-uclass.c
index aaece115f02f..8430a23eece7 100644
--- a/drivers/i2c/i2c-uclass.c
+++ b/drivers/i2c/i2c-uclass.c
@@ -637,14 +637,28 @@ int i2c_uclass_init(struct uclass *class)
return 0;
 }

+static int i2c_post_bind(struct udevice *dev)
+{
+   int ret = 0;
+
+   debug("%s %d\n", __func__, dev->req_seq);
+
+   if (dev->req_seq == -1)
+   dev->req_seq = ++i2c_highest_id;
+
+#if CONFIG_IS_ENABLED(OF_CONTROL) && !CONFIG_IS_ENABLED(OF_PLATDATA)
+   ret = dm_scan_fdt_dev(dev);
+#endif
+
+   return ret;
+}
+
 UCLASS_DRIVER(i2c) = {
.id = UCLASS_I2C,
.name   = "i2c",
.flags  = DM_UC_FLAG_SEQ_ALIAS,
.init   = i2c_uclass_init,
-#if CONFIG_IS_ENABLED(OF_CONTROL) && !CONFIG_IS_ENABLED(OF_PLATDATA)
-   .post_bind  = dm_scan_fdt_dev,
-#endif
+   .post_bind  = i2c_post_bind,
.post_probe = i2c_post_probe,
.per_device_auto_alloc_size = sizeof(struct dm_i2c_bus),
.per_child_platdata_auto_alloc_size = sizeof(struct dm_i2c_chip),


And this is the output
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
   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
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

Without this fix i2c controllers have only -1 because they are not
listed in DT.

I will send this as a patch when this is all reviewed.

Thanks,
Michal

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




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


Re: [U-Boot] [PATCH 0/2] Board support updates for topic-miamiplus modules

2019-01-18 Thread Michal Simek
On 18. 01. 19 9:02, Mike Looijmans wrote:
> Patches rebased for re-submission, were sent earlier as part of a longer
> series.
> 
> This improves performance and functionality for the topic-miamiplus
> boards with Zynq 7035/7045/7100.
> 
> Mike Looijmans (2):
>   topic-miamiplus: Run CPU at 800MHz for speedgrade-2
>   board: topic-miamiplus: Run IO PLL at 1000 MHz
> 
>  arch/arm/dts/zynq-topic-miamiplus.dts  |  9 ++
>  .../topic/zynq/zynq-topic-miamiplus/ps7_init_gpl.c | 34 
> ++
>  2 files changed, 25 insertions(+), 18 deletions(-)
> 

Applied both.

Thanks,
Michal

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




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


Re: [U-Boot] [PATCH 19/26] configs: mx6sabresd: Add SPL FIT and DM support

2019-01-18 Thread Fabio Estevam
Hi Abel,

On Fri, Jan 18, 2019 at 12:59 PM Abel Vesa  wrote:

> +CONFIG_OF_CONTROL=y
> +CONFIG_SPL_OF_CONTROL=y
> +CONFIG_DEFAULT_DEVICE_TREE="imx6q-sabresd"

Does this mean that only imx6q-sabresd variant is supported after this
series is applied?

We still need to support imx6dl/imx6qp sabresd in the same binary as
we currently do today.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH 2/4] fdt: Introduce fdtdec_get_alias_highest_id()

2019-01-18 Thread Michal Simek
Find out the highest alias ID used for certain subsystem.
This call will be used for alocating IDs for i2c buses which are not
described in DT.

Signed-off-by: Michal Simek 
---

 include/fdtdec.h | 13 +
 lib/fdtdec.c | 33 +
 2 files changed, 46 insertions(+)

diff --git a/include/fdtdec.h b/include/fdtdec.h
index f1bcbf837ffb..c2dd87ede226 100644
--- a/include/fdtdec.h
+++ b/include/fdtdec.h
@@ -626,6 +626,19 @@ int fdtdec_get_alias_seq(const void *blob, const char 
*base, int node,
 int *seqp);
 
 /**
+ * Get the highest alias number for susbystem.
+ *
+ * It parses all aliases and find out highest recorded alias for subsystem.
+ * Aliases are of the form  where  is the sequence number.
+ *
+ * @param blob Device tree blob (if NULL, then error is returned)
+ * @param base Base name for alias susbystem (before the number)
+ *
+ * @return 0 highest alias ID, -1 if not found
+ */
+int fdtdec_get_alias_highest_id(const void *blob, const char *base);
+
+/**
  * Get a property from the /chosen node
  *
  * @param blob Device tree blob (if NULL, then NULL is returned)
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index 18663ce6bdac..55811975ef54 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -549,6 +549,39 @@ int fdtdec_get_alias_seq(const void *blob, const char 
*base, int offset,
return -ENOENT;
 }
 
+int fdtdec_get_alias_highest_id(const void *blob, const char *base)
+{
+   int base_len = strlen(base);
+   int prop_offset;
+   int aliases;
+   int max = -1;
+
+   debug("Looking for highest alias id for '%s'\n", base);
+
+   aliases = fdt_path_offset(blob, "/aliases");
+   for (prop_offset = fdt_first_property_offset(blob, aliases);
+prop_offset > 0;
+prop_offset = fdt_next_property_offset(blob, prop_offset)) {
+   const char *prop;
+   const char *name;
+   int len, val;
+
+   prop = fdt_getprop_by_offset(blob, prop_offset, , );
+   debug("   - %s, %s\n", name, prop);
+   if (*prop != '/' || prop[len - 1] ||
+   strncmp(name, base, base_len))
+   continue;
+
+   val = trailing_strtol(name);
+   if (val > max) {
+   debug("Found seq %d\n", val);
+   max = val;
+   }
+   }
+
+   return max;
+}
+
 const char *fdtdec_get_chosen_prop(const void *blob, const char *name)
 {
int chosen_node;
-- 
1.9.1

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


[U-Boot] [PATCH 3/4] i2c: dm: Record maximum id of devices before probing devices

2019-01-18 Thread Michal Simek
There is a need to find out the first free i2c ID which can be used for
i2s buses (including i2c buses connected to i2c mux). Do it early in
init and share this variable with other i2c classes for uniq bus
identification.

Signed-off-by: Michal Simek 
---

 drivers/i2c/i2c-uclass.c | 19 +++
 include/i2c.h|  3 +++
 2 files changed, 22 insertions(+)

diff --git a/drivers/i2c/i2c-uclass.c b/drivers/i2c/i2c-uclass.c
index 975318e5f254..aaece115f02f 100644
--- a/drivers/i2c/i2c-uclass.c
+++ b/drivers/i2c/i2c-uclass.c
@@ -23,6 +23,8 @@ enum {
PIN_COUNT,
 };
 
+int i2c_highest_id = -1;
+
 /* Useful debugging function */
 void i2c_dump_msgs(struct i2c_msg *msg, int nmsgs)
 {
@@ -619,10 +621,27 @@ static int i2c_child_post_bind(struct udevice *dev)
 #endif
 }
 
+int i2c_uclass_init(struct uclass *class)
+{
+#ifdef CONFIG_OF_LIVE
+   int ret;
+
+   ret = of_alias_get_highest_id("i2c");
+   if (ret >= 0)
+   i2c_highest_id = ret;
+#else
+   i2c_highest_id = fdtdec_get_alias_highest_id(gd->fdt_blob, "i2c");
+#endif
+   debug("%s: i2c highest_id %d\n", __func__, i2c_highest_id);
+
+   return 0;
+}
+
 UCLASS_DRIVER(i2c) = {
.id = UCLASS_I2C,
.name   = "i2c",
.flags  = DM_UC_FLAG_SEQ_ALIAS,
+   .init   = i2c_uclass_init,
 #if CONFIG_IS_ENABLED(OF_CONTROL) && !CONFIG_IS_ENABLED(OF_PLATDATA)
.post_bind  = dm_scan_fdt_dev,
 #endif
diff --git a/include/i2c.h b/include/i2c.h
index ccffc1955275..c69e26deaeed 100644
--- a/include/i2c.h
+++ b/include/i2c.h
@@ -16,6 +16,9 @@
 #ifndef _I2C_H_
 #define _I2C_H_
 
+/* Stores maximum highest i2c alias number */
+extern int i2c_highest_id;
+
 /*
  * For now there are essentially two parts to this file - driver model
  * here at the top, and the older code below (with CONFIG_SYS_I2C being
-- 
1.9.1

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


[U-Boot] [PATCH 4/4] i2c: mux: Add support for not listed sub-buses

2019-01-18 Thread Michal Simek
Before this patch is applied all i2c sub-buses are using number -1 and
they can't be addresses(switch to). If all busses are listed in DT alias
they will get proper numbers and U-Boot can work with them.
In Linux buses which are not listed in DT alias get uniq number which
starts from the first highest free ID.

This is the behavior on ZynqMP zcu100-revA before this patch is applied.

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@0
Bus -1: i2c@1
Bus -1: i2c@2
Bus 1:  i2c@ff03
   74: i2c-mux@74, offset len 1, flags 0
   75: i2c-mux@75, offset len 1, flags 0
Bus -1: i2c@0
Bus -1: i2c@1
Bus -1: i2c@2
Bus -1: i2c@3
Bus -1: i2c@4
Bus -1: i2c@0
Bus -1: i2c@1
Bus -1: i2c@2
Bus -1: i2c@3
Bus -1: i2c@4
Bus -1: i2c@5
Bus -1: i2c@6
Bus -1: i2c@7

When the patch is applied also i2c-mux busses are listed properly.

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: generic_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

Signed-off-by: Michal Simek 
---

zcu102-revA

Before this patch applied for !DM case with static description
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

When Patch is applied with OF_LIVE - of_alias_get_highest_id() is used
ZynqMP> i2c bus
Bus 0:  i2c@ff02
   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
   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
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

For !OF_LIVE - hardcoded number is used
ZynqMP> i2c bus
Bus 0:  i2c@ff02
   75: i2c-mux@75, offset len 1, flags 0
Bus 21: i2c@ff02->i2c-mux@75->i2c@0
Bus 22: i2c@ff02->i2c-mux@75->i2c@1
Bus 23: i2c@ff02->i2c-mux@75->i2c@2
Bus 1:  i2c@ff03
   74: i2c-mux@74, offset len 1, flags 0
   75: i2c-mux@75, offset len 1, flags 0
Bus 24: i2c@ff03->i2c-mux@74->i2c@0
Bus 25: i2c@ff03->i2c-mux@74->i2c@1
Bus 26: i2c@ff03->i2c-mux@74->i2c@2
Bus 27: i2c@ff03->i2c-mux@74->i2c@3
Bus 28: i2c@ff03->i2c-mux@74->i2c@4
Bus 29: i2c@ff03->i2c-mux@75->i2c@0
Bus 30: i2c@ff03->i2c-mux@75->i2c@1
Bus 31: i2c@ff03->i2c-mux@75->i2c@2
Bus 32: i2c@ff03->i2c-mux@75->i2c@3
Bus 33: i2c@ff03->i2c-mux@75->i2c@4
Bus 34: i2c@ff03->i2c-mux@75->i2c@5
Bus 35: i2c@ff03->i2c-mux@75->i2c@6
Bus 36: i2c@ff03->i2c-mux@75->i2c@7

---
 drivers/i2c/muxes/i2c-mux-uclass.c | 35 +--
 1 file changed, 33 insertions(+), 2 deletions(-)

diff --git a/drivers/i2c/muxes/i2c-mux-uclass.c 
b/drivers/i2c/muxes/i2c-mux-uclass.c
index a680ee176253..cb69d053fd59 100644
--- a/drivers/i2c/muxes/i2c-mux-uclass.c
+++ b/drivers/i2c/muxes/i2c-mux-uclass.c
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 /**
@@ -59,13 +60,42 @@ static int i2c_mux_post_bind(struct udevice *mux)
dev_for_each_subnode(node, mux) {
struct udevice *dev;
const char *name;
+   const char *arrow = "->";
+   char *full_name;
+   int 

[U-Boot] [PATCH 1/4] dm: core: Add of_alias_get_highest_id()

2019-01-18 Thread Michal Simek
The same functionality was added to Linux for i2c bus registration with this
commit message:

"
of: base: add function to get highest id of an alias stem

I2C supports adding adapters using either a dynamic or fixed id. The
latter is provided by aliases in the DT case. To prevent id collisions
of those two types, install this function which gives us the highest
fixed id, so we can then let the dynamically created ones come after
this highest number.

Signed-off-by: Wolfram Sang 
Acked-by: Rob Herring 
Signed-off-by: Wolfram Sang 
"

Add it also to U-Boot for DM I2C support.

Signed-off-by: Michal Simek 
---

 drivers/core/of_access.c | 18 ++
 include/dm/of_access.h   |  9 +
 2 files changed, 27 insertions(+)

diff --git a/drivers/core/of_access.c b/drivers/core/of_access.c
index 14c020a687b7..7c2df2354109 100644
--- a/drivers/core/of_access.c
+++ b/drivers/core/of_access.c
@@ -812,6 +812,24 @@ int of_alias_get_id(const struct device_node *np, const 
char *stem)
return id;
 }
 
+int of_alias_get_highest_id(const char *stem)
+{
+   struct alias_prop *app;
+   int id = -ENODEV;
+
+   mutex_lock(_mutex);
+   list_for_each_entry(app, _lookup, link) {
+   if (strcmp(app->stem, stem) != 0)
+   continue;
+
+   if (app->id > id)
+   id = app->id;
+   }
+   mutex_unlock(_mutex);
+
+   return id;
+}
+
 struct device_node *of_get_stdout(void)
 {
return of_stdout;
diff --git a/include/dm/of_access.h b/include/dm/of_access.h
index 5ed1a0cdb427..5cbfd220bfd4 100644
--- a/include/dm/of_access.h
+++ b/include/dm/of_access.h
@@ -425,6 +425,15 @@ int of_alias_scan(void);
 int of_alias_get_id(const struct device_node *np, const char *stem);
 
 /**
+ * of_alias_get_highest_id - Get highest alias id for the given stem
+ * @stem:  Alias stem to be examined
+ *
+ * The function travels the lookup table to get the highest alias id for the
+ * given alias stem. It returns the alias id if found.
+ */
+int of_alias_get_highest_id(const char *stem);
+
+/**
  * of_get_stdout() - Get node to use for stdout
  *
  * @return node referred to by stdout-path alias, or NULL if none
-- 
1.9.1

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


[U-Boot] [PATCH 0/4] Align U-Boot I2C DM bus ID handling with Linux

2019-01-18 Thread Michal Simek
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.
For getting this work it would be necessary to setup dev->req_seq in
pre_bind function.

int i2c_pre_bind(struct udevice *dev)
{
if (dev->req_seq == -1) {
dev->req_seq = ++i2c_highest_id;
}
return 0;
}

It can be done also in post_bind but it looks quite weird that
controller has highest ID then i2c-mux sub-buses connected to it.
For example:
ZynqMP> i2c bus
Bus 3:  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 0:  i2c@ff02->i2c-mux@75->i2c@0
Bus 1:  i2c@ff02->i2c-mux@75->i2c@1
Bus 2:  i2c@ff02->i2c-mux@75->i2c@2
Bus 17: i2c@ff03
   74: i2c-mux@74, offset len 1, flags 0
   75: i2c-mux@75, offset len 1, flags 0
Bus 4:  i2c@ff03->i2c-mux@74->i2c@0
Bus 5:  i2c@ff03->i2c-mux@74->i2c@1
Bus 6:  i2c@ff03->i2c-mux@74->i2c@2
Bus 7:  i2c@ff03->i2c-mux@74->i2c@3
...

That's why I think it would be better to introduce pre_bind hooks and
call it in device_bind_common() before binding childs.

Thanks,
Michal


Michal Simek (4):
  dm: core: Add of_alias_get_highest_id()
  fdt: Introduce fdtdec_get_alias_highest_id()
  i2c: dm: Record maximum id of devices before probing devices
  i2c: mux: Add support for not listed sub-buses

 drivers/core/of_access.c   | 18 ++
 drivers/i2c/i2c-uclass.c   | 19 +++
 drivers/i2c/muxes/i2c-mux-uclass.c | 35 +--
 include/dm/of_access.h |  9 +
 include/fdtdec.h   | 13 +
 include/i2c.h  |  3 +++
 lib/fdtdec.c   | 33 +
 7 files changed, 128 insertions(+), 2 deletions(-)

-- 
1.9.1

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


Re: [U-Boot] [PATCH v3 2/4] net: add MSCC Ocelot switch support

2019-01-18 Thread Daniel Schwierzeck


Am 17.01.19 um 17:07 schrieb Gregory CLEMENT:
> This patch adds support for the Microsemi Ethernet switch present on
> Ocelot SoCs.
> 
> Signed-off-by: Gregory CLEMENT 
> ---
>  MAINTAINERS |   1 +
>  drivers/net/Kconfig |   7 +
>  drivers/net/Makefile|   1 +
>  drivers/net/ocelot_switch.c | 765 
>  4 files changed, 774 insertions(+)
>  create mode 100644 drivers/net/ocelot_switch.c
> 

Reviewed-by: Daniel Schwierzeck 

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


[U-Boot] [PATCH 26/26] board: mx6sabresd: Remove the enet reset gpio handling

2019-01-18 Thread Abel Vesa
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 
---
 board/freescale/mx6sabresd/mx6sabresd.c | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/board/freescale/mx6sabresd/mx6sabresd.c 
b/board/freescale/mx6sabresd/mx6sabresd.c
index 71b9bfe..c9f2076 100644
--- a/board/freescale/mx6sabresd/mx6sabresd.c
+++ b/board/freescale/mx6sabresd/mx6sabresd.c
@@ -94,13 +94,6 @@ static iomux_v3_cfg_t const enet_pads[] = {
 static void setup_iomux_enet(void)
 {
SETUP_IOMUX_PADS(enet_pads);
-
-   /* Reset AR8031 PHY */
-   gpio_request(IMX_GPIO_NR(1, 25), "ENET PHY Reset");
-   gpio_direction_output(IMX_GPIO_NR(1, 25) , 0);
-   mdelay(10);
-   gpio_set_value(IMX_GPIO_NR(1, 25), 1);
-   udelay(100);
 }
 
 static iomux_v3_cfg_t const usdhc2_pads[] = {
-- 
2.7.4

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


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

2019-01-18 Thread Fabio Estevam
Hi Abel,

On Fri, Jan 18, 2019 at 12:53 PM Abel Vesa  wrote:
>
> This comes as a next iteration to the followin RFC:
> https://lists.denx.de/pipermail/u-boot/2019-January/354834.html
>
> Changes since that RFC:
>  * Add all the dl/qp/q dts and dtsi files from linux as suggested
>by Fabio Estevam
>  * Removed the ENET reset gpio handling from board file since
>relying on the phy-reset-gpios from imx6qdl-sabresd.dtsi
>  * Reworked the SPL_USB_SUPPORT and renamed it to SPL_USB_STORAGE
>as suggested by Tom Rini

What boards did you use to test this series?

After this series is applied are we still able to boot imx6q/dl/qp
sabresd with the same U-Boot image?
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH 13/26] arm: dts: Add imx6dl-sabreauto dts file

2019-01-18 Thread Abel Vesa
Add imx6dl-sabreauto dts support from Linux.

Signed-off-by: Abel Vesa 
---
 arch/arm/dts/Makefile |  3 ++-
 arch/arm/dts/imx6dl-sabreauto.dts | 17 +
 2 files changed, 19 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/dts/imx6dl-sabreauto.dts

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index eeb2587..d766ab5 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -442,7 +442,8 @@ dtb-$(CONFIG_MX6QDL) += \
imx6q-icore-rqs.dtb \
imx6q-logicpd.dtb \
imx6q-sabreauto.dtb \
-   imx6q-sabresd.dtb
+   imx6q-sabresd.dtb \
+   imx6dl-sabreauto.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..a6ce7b4
--- /dev/null
+++ b/arch/arm/dts/imx6dl-sabreauto.dts
@@ -0,0 +1,17 @@
+/*
+ * Copyright (C) 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.
+ */
+
+/dts-v1/;
+
+#include "imx6dl.dtsi"
+#include "imx6qdl-sabreauto.dtsi"
+
+/ {
+   model = "Freescale i.MX6 DualLite/Solo SABRE Automotive Board";
+   compatible = "fsl,imx6dl-sabreauto", "fsl,imx6dl";
+};
-- 
2.7.4

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


[U-Boot] [PATCH 14/26] arm: dts: Add imx6dl-sabresd dts file

2019-01-18 Thread Abel Vesa
Add imx6dl-sabresd dts support from Linux.

Signed-off-by: Abel Vesa 
---
 arch/arm/dts/Makefile   |  3 ++-
 arch/arm/dts/imx6dl-sabresd.dts | 17 +
 2 files changed, 19 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/dts/imx6dl-sabresd.dts

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index d766ab5..520d1a5 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -443,7 +443,8 @@ dtb-$(CONFIG_MX6QDL) += \
imx6q-logicpd.dtb \
imx6q-sabreauto.dtb \
imx6q-sabresd.dtb \
-   imx6dl-sabreauto.dtb
+   imx6dl-sabreauto.dtb \
+   imx6dl-sabresd.dtb
 
 dtb-$(CONFIG_MX6SL) += imx6sl-evk.dtb
 
diff --git a/arch/arm/dts/imx6dl-sabresd.dts b/arch/arm/dts/imx6dl-sabresd.dts
new file mode 100644
index 000..1e45f2f
--- /dev/null
+++ b/arch/arm/dts/imx6dl-sabresd.dts
@@ -0,0 +1,17 @@
+/*
+ * Copyright (C) 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.
+ */
+
+/dts-v1/;
+
+#include "imx6dl.dtsi"
+#include "imx6qdl-sabresd.dtsi"
+
+/ {
+   model = "Freescale i.MX6 DualLite SABRE Smart Device Board";
+   compatible = "fsl,imx6dl-sabresd", "fsl,imx6dl";
+};
-- 
2.7.4

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


[U-Boot] [PATCH 11/26] arm: dts: Add imx6q-sabreauto dts file

2019-01-18 Thread Abel Vesa
Add imx6q-sabreauto dts support from Linux.

Signed-off-by: Abel Vesa 
---
 arch/arm/dts/Makefile|  3 ++-
 arch/arm/dts/imx6q-sabreauto.dts | 25 +
 2 files changed, 27 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/dts/imx6q-sabreauto.dts

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index b2ca87d..fee6338 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -440,7 +440,8 @@ dtb-$(CONFIG_MX6QDL) += \
imx6q-icore.dtb \
imx6q-icore-mipi.dtb \
imx6q-icore-rqs.dtb \
-   imx6q-logicpd.dtb
+   imx6q-logicpd.dtb \
+   imx6q-sabreauto.dtb
 
 dtb-$(CONFIG_MX6SL) += imx6sl-evk.dtb
 
diff --git a/arch/arm/dts/imx6q-sabreauto.dts b/arch/arm/dts/imx6q-sabreauto.dts
new file mode 100644
index 000..334b924
--- /dev/null
+++ b/arch/arm/dts/imx6q-sabreauto.dts
@@ -0,0 +1,25 @@
+/*
+ * Copyright 2012 Freescale Semiconductor, Inc.
+ * Copyright 2011 Linaro Ltd.
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+/dts-v1/;
+
+#include "imx6q.dtsi"
+#include "imx6qdl-sabreauto.dtsi"
+
+/ {
+   model = "Freescale i.MX6 Quad SABRE Automotive Board";
+   compatible = "fsl,imx6q-sabreauto", "fsl,imx6q";
+};
+
+ {
+   status = "okay";
+};
-- 
2.7.4

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


[U-Boot] [PATCH 20/26] mx6sabreauto: Add DM_GPIO support

2019-01-18 Thread Abel Vesa
Add the DM_GPIO related config for mx6sabreauto.
Also add the gpio request calls.

Signed-off-by: Abel Vesa 
---
 board/freescale/mx6sabreauto/mx6sabreauto.c | 3 +++
 configs/mx6sabreauto_defconfig  | 1 +
 2 files changed, 4 insertions(+)

diff --git a/board/freescale/mx6sabreauto/mx6sabreauto.c 
b/board/freescale/mx6sabreauto/mx6sabreauto.c
index c1bef85..b28e5e3 100644
--- a/board/freescale/mx6sabreauto/mx6sabreauto.c
+++ b/board/freescale/mx6sabreauto/mx6sabreauto.c
@@ -501,6 +501,7 @@ iomux_v3_cfg_t const backlight_pads[] = {
 
 static void setup_iomux_backlight(void)
 {
+   gpio_request(IMX_GPIO_NR(2, 9), "backlight");
gpio_direction_output(IMX_GPIO_NR(2, 9), 1);
SETUP_IOMUX_PADS(backlight_pads);
 }
@@ -594,6 +595,7 @@ int board_init(void)
else
setup_i2c(1, CONFIG_SYS_I2C_SPEED, 0x7f, _i2c_pad_info1);
/* I2C 3 Steer */
+   gpio_request(IMX_GPIO_NR(5, 4), "steer logic");
gpio_direction_output(IMX_GPIO_NR(5, 4), 1);
SETUP_IOMUX_PADS(i2c3_pads);
 #ifndef CONFIG_SYS_FLASH_CFI
@@ -602,6 +604,7 @@ int board_init(void)
else
setup_i2c(2, CONFIG_SYS_I2C_SPEED, 0x7f, _i2c_pad_info2);
 #endif
+   gpio_request(IMX_GPIO_NR(1, 15), "expander en");
gpio_direction_output(IMX_GPIO_NR(1, 15), 1);
SETUP_IOMUX_PADS(port_exp);
 
diff --git a/configs/mx6sabreauto_defconfig b/configs/mx6sabreauto_defconfig
index fa3d649..bcd6ff0 100644
--- a/configs/mx6sabreauto_defconfig
+++ b/configs/mx6sabreauto_defconfig
@@ -56,6 +56,7 @@ CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y
 CONFIG_SPL_DM=y
 CONFIG_DFU_MMC=y
 CONFIG_DFU_SF=y
+CONFIG_DM_GPIO=y
 CONFIG_DM_MMC=y
 CONFIG_FSL_ESDHC=y
 CONFIG_NAND=y
-- 
2.7.4

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


[U-Boot] [PATCH 18/26] configs: mx6sabreauto: Add SPL FIT and DM support

2019-01-18 Thread Abel Vesa
Enable all the necessary configs for SPL DM and FIT support for
mx6sabreauto.

Signed-off-by: Abel Vesa 
---
 configs/mx6sabreauto_defconfig | 14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/configs/mx6sabreauto_defconfig b/configs/mx6sabreauto_defconfig
index e55c2d9..fa3d649 100644
--- a/configs/mx6sabreauto_defconfig
+++ b/configs/mx6sabreauto_defconfig
@@ -4,18 +4,27 @@ CONFIG_SYS_TEXT_BASE=0x1780
 CONFIG_SPL_GPIO_SUPPORT=y
 CONFIG_SPL_LIBCOMMON_SUPPORT=y
 CONFIG_SPL_LIBGENERIC_SUPPORT=y
+CONFIG_SYS_MALLOC_F_LEN=0x2000
 CONFIG_TARGET_MX6SABREAUTO=y
 CONFIG_SPL_MMC_SUPPORT=y
 CONFIG_SPL_SERIAL_SUPPORT=y
+CONFIG_SPL_SYS_MALLOC_F_LEN=0x400
 CONFIG_SPL=y
 CONFIG_SPL_LIBDISK_SUPPORT=y
 CONFIG_NXP_BOARD_REVISION=y
 CONFIG_NR_DRAM_BANKS=1
+CONFIG_TPL_SYS_MALLOC_F_LEN=0x400
+CONFIG_FIT=y
+CONFIG_SPL_FIT_PRINT=y
+CONFIG_SPL_LOAD_FIT=y
+CONFIG_SPL_FIT_SOURCE="arch/arm/mach-imx/mx6/fit_spl.its"
 CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=arch/arm/mach-imx/spl_sd.cfg"
 # CONFIG_CONSOLE_MUX is not set
 CONFIG_SYS_CONSOLE_IS_IN_ENV=y
 CONFIG_SYS_CONSOLE_OVERWRITE_ROUTINE=y
 CONFIG_SUPPORT_RAW_INITRD=y
+CONFIG_SPL_SEPARATE_BSS=y
+CONFIG_SPL_FIT_IMAGE_TINY=y
 CONFIG_SPL_EXT_SUPPORT=y
 CONFIG_SPL_I2C_SUPPORT=y
 CONFIG_SPL_WATCHDOG_SUPPORT=y
@@ -39,8 +48,12 @@ CONFIG_CMD_EXT4=y
 CONFIG_CMD_EXT4_WRITE=y
 CONFIG_CMD_FAT=y
 CONFIG_CMD_FS_GENERIC=y
+CONFIG_OF_CONTROL=y
+CONFIG_SPL_OF_CONTROL=y
+CONFIG_DEFAULT_DEVICE_TREE="imx6q-sabreauto"
 CONFIG_ENV_IS_IN_MMC=y
 CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y
+CONFIG_SPL_DM=y
 CONFIG_DFU_MMC=y
 CONFIG_DFU_SF=y
 CONFIG_DM_MMC=y
@@ -67,4 +80,3 @@ CONFIG_USB_HOST_ETHER=y
 CONFIG_USB_ETHER_ASIX=y
 CONFIG_VIDEO=y
 # CONFIG_VIDEO_SW_CURSOR is not set
-CONFIG_OF_LIBFDT=y
-- 
2.7.4

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


  1   2   >