Re: [U-Boot] [PATCH] bch: Fix build on FreeBSD host

[Jonathan Gray]

On Tue, Jun 20, 2017 at 09:02:29AM +0200, Emmanuel Vadot wrote:
> endian.h on FreeBSD system exist in sys/ subdirectory.
> FreeBSD already have a fls function defined in strings.h which is included
> in string.h if __BSD_VISIBLE is defined, as a check for this.

This broke the build of u-boot on OpenBSD where there is no fls in
strings.h.

> 
> Signed-off-by: Emmanuel Vadot 
> ---
>  lib/bch.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/lib/bch.c b/lib/bch.c
> index ec53483774..7a2d9d3b86 100644
> --- a/lib/bch.c
> +++ b/lib/bch.c
> @@ -61,7 +61,11 @@
>  #include 
>  #else
>  #include 
> +#if defined(__FreeBSD__)
> +#include 
> +#else
>  #include 
> +#endif
>  #include 
>  #include 
>  #include 
> @@ -113,6 +117,7 @@ struct gf_poly_deg1 {
>  };
>  
>  #ifdef USE_HOSTCC
> +#ifndef __BSD_VISIBLE
>  static int fls(int x)
>  {
>   int r = 32;
> @@ -142,6 +147,7 @@ static int fls(int x)
>   return r;
>  }
>  #endif
> +#endif
>  
>  /*
>   * same as encode_bch(), but process input data one byte at a time
> -- 
> 2.13.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

Re: [U-Boot] [PATCH v3] watchdog: Introduce watchdog driver for Intel Tangier

[Bin Meng]

Hi Andy,

On Sun, Jul 16, 2017 at 9:37 PM, Andy Shevchenko
 wrote:
> On Fri, 2017-07-07 at 12:51 +0800, Bin Meng wrote:
>> On Thu, Jul 6, 2017 at 1:33 AM, Andy Shevchenko
>>  wrote:
>> > From: Felipe Balbi 
>> >
>> > Add watchdog driver for Intel Tangier based platforms.
>
> Can we get it applied?
>

Yes, it's on my todo list.

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

Re: [U-Boot] [PATCH 2/2] [rfc] support booting arm64 android image

[Tom Rini]

On Wed, Jul 19, 2017 at 12:44:48PM +1000, Bin Chen wrote:
> On 18 July 2017 at 22:32, Tom Rini  wrote:
> 
> > On Thu, Jul 13, 2017 at 05:33:08PM +1000, Bin Chen wrote:
> > > Hi Tom,
> > >
> > > Thanks for the review.
> > >
> > > On 13 July 2017 at 04:25, Tom Rini  wrote:
> > >
> > > > On Tue, Jul 11, 2017 at 03:56:04PM +1000, Bin Chen wrote:
> > > >
> > > > > It's my understanding that we are supposed to use booti, instead of
> > > > bootm,
> > > > > for arm64 image. But booti lacks of android image support. Bootm has
> > > > > the andriod image support but lack of the arm64 image handling.
> > > > >
> > > > > So, what is suppose the right way of booting an android arm64 image?
> > > > > or, should we create a separate command?
> > > > >
> > > > > This patch is an invitation for that discussion.
> > > > >
> > > > > It *hacked* the booti command and it aslo assume the dtb is in the
> > > > second area
> > > > > of android boot image. It also has other belives like u-boot should
> > be
> > > > > in control of where to put the kernnel/ramdisk/dtb images so it
> > ignores
> > > > > the value specified in the android images.
> > > > >
> > > > > Signed-off-by: Bin Chen 
> > > >
> > > > So, booti is very much for the "Image" format described in the Linux
> > > > kernel in Documentation/arm64/booting.txt.  One can (and people have)
> > > > used bootm on aarch64 for "uImage" style kernels and FIT kernels, and I
> > > > would see being able to boot an aarch64 Android image with bootm as the
> > > > way to go forward.
> > >
> > >
> > > Are you suggesting that we should use bootm path, instead of booti?
> > >
> > > I have two questions regarding this:
> > >
> > > 1. currently arm64 kernel don't have a uImage kernel target. And I'm not
> > > sure
> > >  if adding that will be something that is wanted and/or sensible.
> >
> > There's some confusion here.  bootm is not only for "uImage" kernels.
> > It for example handles the aarch32 Android image format.
> >
> > > 2. bootm path doesn't have the logic that is currently in the booti, such
> > > as the
> > > kernel relocation.
> >
> > Now I'm confused, what is different in an "Android" image for aarch64
> > than from a standard aarch64 Linux kernel 'Image' ?
> >
> 
> Android image wraps the 'Image'. There is a section called “kernel” in
> Android
> image, and will place the Image there [1]. Do you think it is the right way
> to do that?
> 
> I think that's the case for aarch32 android image as well, but replace the
> 'Image' with
> aarch32 kernel build target - I don't know what the format of that target
> is.
> 
> [1]
> https://android.googlesource.com/platform/system/core/+/master/mkbootimg/bootimg.h
> 
> 
> > > Also, one other question raised during internal discussion was why the
> > > booti
> > > was created in the first place, if we could have had that implemented in
> > > the
> > > bootm path.
> >
> > Well, there's some discussion in the archives about this.  The short
> > answer is that "bootm" wasn't supposed to become a "figure out whatever
> > this image is, boot it" command.
> >
> 
> Good to know the idea beyond that and what bootm isn't supposed to be.
> That helps to decide whether we should stuff things into bootm or having a
> separate one.
> 
> 
> > In hindsight, now, I'm thinking that the aarch32 Android image support
> > maybe should have gone into "bootandroid" and in turn it would be easier
> > to get someone to write a new command, say "bootauto" that would ask
> > bootm/bootelf/bootefi/bootandroid/bootz/booti/etc if it liked the image
> > found at $address and if so, boot it, and if not, move on to checking
> > the next type.
> >
> 
> That seems the idea what many people agree upon. Not sure how easy
> to move aarch32 support out and I don't have a aarch32 platform to test.
> Do you think we'll want to start with aarch64 (considering that may be the
> aarch
> for most android phone out there) and have a separate boota(ndroid) command?

I think the best path forward today is to make sure that whatever
aarch64-Image support code that's needed from cmd/booti.c is available
so that 'bootm' can see that we have an Android-style image and then
further that we have an Image underneath it, rather than a zImage, and
handle running it appropriately.  I think bootm, aka "boot application
image from memory" is the best place to handle both 32 and 64bit Android
style images, as things stand today, at least.

-- 
Tom


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

Re: [U-Boot] [PATCH 2/2] [rfc] support booting arm64 android image

[Bin Chen]

Andy,

On 14 July 2017 at 17:30, Andy Yan  wrote:

> Hi:
>
> 2017-07-13 15:33 GMT+08:00 Bin Chen :
>
>> Hi Tom,
>>
>> Thanks for the review.
>>
>> On 13 July 2017 at 04:25, Tom Rini  wrote:
>>
>> > On Tue, Jul 11, 2017 at 03:56:04PM +1000, Bin Chen wrote:
>> >
>> > > It's my understanding that we are supposed to use booti, instead of
>> > bootm,
>> > > for arm64 image. But booti lacks of android image support. Bootm has
>> > > the andriod image support but lack of the arm64 image handling.
>> > >
>> > > So, what is suppose the right way of booting an android arm64 image?
>> > > or, should we create a separate command?
>> > >
>> > > This patch is an invitation for that discussion.
>> > >
>> > > It *hacked* the booti command and it aslo assume the dtb is in the
>> > second area
>> > > of android boot image. It also has other belives like u-boot should be
>> > > in control of where to put the kernnel/ramdisk/dtb images so it
>> ignores
>> > > the value specified in the android images.
>> > >
>> > > Signed-off-by: Bin Chen 
>> >
>> > So, booti is very much for the "Image" format described in the Linux
>> > kernel in Documentation/arm64/booting.txt.  One can (and people have)
>> > used bootm on aarch64 for "uImage" style kernels and FIT kernels, and I
>> > would see being able to boot an aarch64 Android image with bootm as the
>> > way to go forward.
>>
>>
>> Are you suggesting that we should use bootm path, instead of booti?
>>
>> I have two questions regarding this:
>>
>> 1. currently arm64 kernel don't have a uImage kernel target. And I'm not
>> sure
>>  if adding that will be something that is wanted and/or sensible.
>>
>>
>   It seems that bootm doesn't always require a uImage kernel. Consider we
> use bootm to boot a ARM32 based android boot.img.
> we pack the zImage in boot.img directly, without make it to uImage .
>

You are right!


> 2. bootm path doesn't have the logic that is currently in the booti, such
>> as the
>> kernel relocation.
>>
>> Also, one other question raised during internal discussion was why the
>> booti
>> was created in the first place, if we could have had that implemented in
>> the
>> bootm path.
>>
>>
>>
>> > The analogy would be that we use bootm for Android
>> > on arm not bootz.  Thanks!
>> >
>> > --
>> > Tom
>> >
>>
>>
>>
>> --
>> Regards,
>> Bin
>> ___
>> U-Boot mailing list
>> U-Boot@lists.denx.de
>> https://lists.denx.de/listinfo/u-boot
>>
>
>


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

Re: [U-Boot] [PATCH 2/2] [rfc] support booting arm64 android image

[Bin Chen]

On 18 July 2017 at 22:32, Tom Rini  wrote:

> On Thu, Jul 13, 2017 at 05:33:08PM +1000, Bin Chen wrote:
> > Hi Tom,
> >
> > Thanks for the review.
> >
> > On 13 July 2017 at 04:25, Tom Rini  wrote:
> >
> > > On Tue, Jul 11, 2017 at 03:56:04PM +1000, Bin Chen wrote:
> > >
> > > > It's my understanding that we are supposed to use booti, instead of
> > > bootm,
> > > > for arm64 image. But booti lacks of android image support. Bootm has
> > > > the andriod image support but lack of the arm64 image handling.
> > > >
> > > > So, what is suppose the right way of booting an android arm64 image?
> > > > or, should we create a separate command?
> > > >
> > > > This patch is an invitation for that discussion.
> > > >
> > > > It *hacked* the booti command and it aslo assume the dtb is in the
> > > second area
> > > > of android boot image. It also has other belives like u-boot should
> be
> > > > in control of where to put the kernnel/ramdisk/dtb images so it
> ignores
> > > > the value specified in the android images.
> > > >
> > > > Signed-off-by: Bin Chen 
> > >
> > > So, booti is very much for the "Image" format described in the Linux
> > > kernel in Documentation/arm64/booting.txt.  One can (and people have)
> > > used bootm on aarch64 for "uImage" style kernels and FIT kernels, and I
> > > would see being able to boot an aarch64 Android image with bootm as the
> > > way to go forward.
> >
> >
> > Are you suggesting that we should use bootm path, instead of booti?
> >
> > I have two questions regarding this:
> >
> > 1. currently arm64 kernel don't have a uImage kernel target. And I'm not
> > sure
> >  if adding that will be something that is wanted and/or sensible.
>
> There's some confusion here.  bootm is not only for "uImage" kernels.
> It for example handles the aarch32 Android image format.
>
> > 2. bootm path doesn't have the logic that is currently in the booti, such
> > as the
> > kernel relocation.
>
> Now I'm confused, what is different in an "Android" image for aarch64
> than from a standard aarch64 Linux kernel 'Image' ?
>

Android image wraps the 'Image'. There is a section called “kernel” in
Android
image, and will place the Image there [1]. Do you think it is the right way
to do that?

I think that's the case for aarch32 android image as well, but replace the
'Image' with
aarch32 kernel build target - I don't know what the format of that target
is.

[1]
https://android.googlesource.com/platform/system/core/+/master/mkbootimg/bootimg.h


> > Also, one other question raised during internal discussion was why the
> > booti
> > was created in the first place, if we could have had that implemented in
> > the
> > bootm path.
>
> Well, there's some discussion in the archives about this.  The short
> answer is that "bootm" wasn't supposed to become a "figure out whatever
> this image is, boot it" command.
>

Good to know the idea beyond that and what bootm isn't supposed to be.
That helps to decide whether we should stuff things into bootm or having a
separate one.


> In hindsight, now, I'm thinking that the aarch32 Android image support
> maybe should have gone into "bootandroid" and in turn it would be easier
> to get someone to write a new command, say "bootauto" that would ask
> bootm/bootelf/bootefi/bootandroid/bootz/booti/etc if it liked the image
> found at $address and if so, boot it, and if not, move on to checking
> the next type.
>

That seems the idea what many people agree upon. Not sure how easy
to move aarch32 support out and I don't have a aarch32 platform to test.
Do you think we'll want to start with aarch64 (considering that may be the
aarch
for most android phone out there) and have a separate boota(ndroid) command?


> --
> Tom
>



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

Re: [U-Boot] [RFC PATCH] common: board_f: Make reserve_mmu a weak function

[York Sun]

On 07/18/2017 10:59 PM, Michal Simek wrote:
> Hi Simon,
> 
> On 18.7.2017 16:50, Simon Glass wrote:
>> Hi Michal,
>>
>> On 18 July 2017 at 07:23, Michal Simek  wrote:
>>> Hi Simon,
>>>
>>> On 18.7.2017 16:01, Simon Glass wrote:
 Hi Michal,

 On 13 July 2017 at 06:50, Michal Simek  wrote:
> From: Siva Durga Prasad Paladugu 
>
> Make reserve_mmu a weak so that it provides an option
> to customize this routine as per platform need

 Why do you need this? Can we instead have the generic code do the
 right thing? Or can we use reserve_arch() to handle this?
>>>
>>> reserve_mmu is called just for ARM.
>>
>> What arch are you using?
> 
> arm64 - a53s
> 
>>
>>> What we need to do is support configuration where we have small memory
>>> OCM and we need to put mmu table to different location (TCM) because it
>>> is simply big and it can't be placed where it is placed now.
>>
>> What is TCM? Is this the internal SRAM?
> 
> It is internal sram which is used mostly by R5s in the system but a53
> has also access to it.
> 
>>
>> I don't understand 'simply big'. Are you saying it is too big to go
>> into main memory?
> 
> These configuration can't use DDR. One of that configuration which we
> are using is DDR memory test. It means you run from internal sram (256kB
> OCM + 256k TCM).
> Another configuration is for loading stuff to EMMC on different boards.
> It means you don't need to setup DDR for generic emmc programming.
> 
> All these configurations are using console over DCC - arm jtag uart.
> 
>>
>>>
>>> Based on looking at code the key question is if we can call reserve_mmu
>>> at that time when reserve_arch is called now.
>>> On zynqmp I can't see any issue to allocate tlb on the stack and call it
>>> from it. The question is if this is valid for all arms.
>>>
>>> This is just a small hack I have created to move it to stack.
>>>
>>>   diff --git a/common/board_f.c b/common/board_f.c
>>>   index 88e20e0168b2..32386c957962 100644
>>>   --- a/common/board_f.c
>>>   +++ b/common/board_f.c
>>>   @@ -433,13 +433,13 @@ __weak int reserve_mmu(void)
>>>{
>>>   /* reserve TLB table */
>>>   gd->arch.tlb_size = PGTABLE_SIZE;
>>>   -   gd->relocaddr -= gd->arch.tlb_size;
>>>   +   gd->start_addr_sp -= gd->arch.tlb_size;
>>>
>>>   /* round down to next 64 kB limit */
>>>   -   gd->relocaddr &= ~(0x1 - 1);
>>>   +   gd->start_addr_sp &= ~(0x1 - 1);
>>>
>>>   -   gd->arch.tlb_addr = gd->relocaddr;
>>>   -   debug("TLB table from %08lx to %08lx\n", gd->arch.tlb_addr,
>>>   +   gd->arch.tlb_addr = gd->start_addr_sp;
>>>   +   printf("TLB table from %08lx to %08lx\n", gd->arch.tlb_addr,
>>> gd->arch.tlb_addr + gd->arch.tlb_size);
>>>
>>>#ifdef CONFIG_SYS_MEM_RESERVE_SECURE
>>>   @@ -837,7 +837,7 @@ static int initf_dm(void)
>>>/* Architecture-specific memory reservation */
>>>__weak int reserve_arch(void)
>>>{
>>>   -   return 0;
>>>   +   return reserve_mmu();
>>>}
>>>
>>>__weak int arch_cpu_init_dm(void)
>>>   @@ -998,10 +998,6 @@ static init_fnc_t init_sequence_f[] = {
>>>   reserve_pram,
>>>#endif
>>>   reserve_round_4k,
>>>   -#if !(defined(CONFIG_SYS_ICACHE_OFF) &&
>>> defined(CONFIG_SYS_DCACHE_OFF)) && \
>>>   -   defined(CONFIG_ARM)
>>>   -   reserve_mmu,
>>>   -#endif
>>>#ifdef CONFIG_DM_VIDEO
>>>   reserve_video,
>>>#else
>>>
>>> For us we can't just rewrite tlb addresses as we want to do because we
>>> can't allow reserve_mmu to allocate 64kB alied PGTABLE_SIZE in
>>> relocation structure.
>>
>> Why not?
> 
> Because we need to fit to 256kB of memory also with relocation and also
> space for data. And IIRC MMU table size is 64kB.
> Another option could be to disable relocation.
> 
Michal,

For your reference, we use two stage MMU setup for FSL ARMv8 SoCs. We 
setup an early MMU in arch_cpu_init() so we can enable d-cache very 
early to speed up execution. Our DDR init and testing is done on top of 
that. After DDR init, we use the reserved MMU table in DDR to setup a 
final MMU for normal use.

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

Re: [U-Boot] U-Boot Tool: fw_setenv - kernel option?

[Tom Rini]

On Mon, Jul 17, 2017 at 04:08:27PM +0200, Arno Steffens wrote:

> After using a plain vanilla instead of a vendor kernel I do have
> problems with fw_setenv.
> Althoug fw_printenv still works fine, after usage of fw_setenv the
> environment is destroyed, CRC error.
> 
> I checked a lot of things, changed u-boot, devicetree, fw_setenv ...
> and finally came to the point, that it just depends on the kernel.
> Only changing the kernel makes the difference. I assume that there is
> an option not enabled. Honestly, I am lost with the differences - I
> couldn't identify the one that makes difference. 
> Using an older config file, with lot more options, than it works also
> with a newer kernel.
> 
> Someone has an idea, which of the million settings is my friend?
> CONFIG_CRC16 and 32 are both enabled.

The most likely answer here is that in the working kernel you have
things enabled correctly for your environment storage device (I would
guess some form of NAND) and in the not working kernel you do not have
things such as ECC scheme configured correctly, so writes do not work.

-- 
Tom


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

Re: [U-Boot] [PULL] Please pull u-boot-imx

[Tom Rini]

On Fri, Jul 14, 2017 at 05:46:02PM +0200, Stefano Babic wrote:

> Hi Tom,
> 
> please pull from u-boot-imx, thanks !
> 
> All boards compile clean, there are still warning for 9 boards dur to
> fec_get_miibus. Patch was already sent by Lothar and will follow the
> normal way through Joe's tree. At the moment, it is ok to still have
> these warnings.

OK, but we better get them resolved sooner rather than later.

> 
> The following changes since commit 8d3a25685e4aac7070365a2b3c53c2c81b27930f:
> 
>   Merge git://git.denx.de/u-boot-dm (2017-07-11 20:28:46 -0400)
> 
> are available in the git repository at:
> 
>   git://www.denx.de/git/u-boot-imx.git master
> 
> for you to fetch changes up to 651782a08b5bb4e710bda1b11fff774b8ade384f:
> 
>   mx6cuboxi: Move CONFIG_CMD_SATA to Kconfig (2017-07-14 15:16:01 +0200)
> 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH] ARM: Mark AE boards orphan

[Tom Rini]

On Tue, Jul 18, 2017 at 06:05:05PM +0200, Marek Vasut wrote:

> I no longer have any of these boards, mark boards orphan.
> 
> Signed-off-by: Marek Vasut 
> Cc: Tom Rini 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH 26/52] rockchip: rk3368: define CONFIG_SYS_SDRAM_BASE

[Heiko Stuebner]

Am Dienstag, 18. Juli 2017, 22:36:06 CEST schrieb Philipp Tomsich:
> With the new common SDRAM code for Rockchip, we need to define
> CONFIG_SYS_SDRAM_BASE to correctly indicate the start of the physical
> address range mapping onto DRAM.
> 
> Signed-off-by: Philipp Tomsich 
> ---
> 
>  include/configs/rk3368_common.h | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/include/configs/rk3368_common.h b/include/configs/rk3368_common.h
> index b0c858c..488f8c5 100644
> --- a/include/configs/rk3368_common.h
> +++ b/include/configs/rk3368_common.h
> @@ -15,6 +15,7 @@
>  #define CONFIG_SYS_SDRAM_BASE0

^^ isn't that already defined here?

>  #define SDRAM_MAX_SIZE   0xff00
>  #define CONFIG_NR_DRAM_BANKS 1
> +#define CONFIG_SYS_SDRAM_BASE0
>  #define CONFIG_SYS_MAXARGS   16
>  #define CONFIG_BAUDRATE  115200
>  #define CONFIG_SYS_MALLOC_LEN(32 << 20)
> 


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

[U-Boot] [PATCH 37/52] rockchip: clk: rk3368: define DMA1_SRST_REQ and DMA2_SRST_REQ

[Philipp Tomsich]

On he RK3368, we need to temporarily disable security on the DMA
engines during TPL and SPL to allow the MMC host to DMA into DRAM.  To
do so, we need to reset the two DMA engines, which in turn requires
the DMA1_SRST_REQ and DMA2_SRST_REQ constants to refer to the
appropriate bits in the CRU.

As the ATF correctly initialises security (and only leaves EL3 after
doing so), this can not pose a security issue.

Signed-off-by: Philipp Tomsich 
---

 arch/arm/include/asm/arch-rockchip/cru_rk3368.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/include/asm/arch-rockchip/cru_rk3368.h 
b/arch/arm/include/asm/arch-rockchip/cru_rk3368.h
index 24a9cc0..bf09e2f 100644
--- a/arch/arm/include/asm/arch-rockchip/cru_rk3368.h
+++ b/arch/arm/include/asm/arch-rockchip/cru_rk3368.h
@@ -102,6 +102,10 @@ enum {
/* SOFTRST1_CON */
MCU_PO_SRST_MASK= BIT(13),
MCU_SYS_SRST_MASK   = BIT(12),
+   DMA1_SRST_REQ   = BIT(2),
+
+   /* SOFTRST4_CON */
+   DMA2_SRST_REQ   = BIT(0),
 
/* GLB_RST_CON */
PMU_GLB_SRST_CTRL_SHIFT = 2,
-- 
2.1.4

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

[U-Boot] [PATCH 15/52] armv8: spl: Support separate stack for TPL

[Philipp Tomsich]

To allow a TPL and SPL to run from different addresses/memories, we
need to split setup of the TPL and SPL stacks.  To do so, we introduce
CONFIG_TPL_STACK (not listed in Kconfig) which can be used to override
the initial stack pointer for TPL.

To provide backward compatibility for existing boards, this is added
as an optional configuration item and the normal search order (i.e.
SPL_STACK, then SYS_STACK) apply if not defined.

Signed-off-by: Philipp Tomsich 
---

 arch/arm/lib/crt0_64.S   | 4 +++-
 scripts/config_whitelist.txt | 1 +
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/arm/lib/crt0_64.S b/arch/arm/lib/crt0_64.S
index 57e728f..177b5bf 100644
--- a/arch/arm/lib/crt0_64.S
+++ b/arch/arm/lib/crt0_64.S
@@ -69,7 +69,9 @@ ENTRY(_main)
 /*
  * Set up initial C runtime environment and call board_init_f(0).
  */
-#if defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_STACK)
+#if defined(CONFIG_TPL_BUILD) && defined(CONFIG_TPL_STACK)
+   ldr x0, =(CONFIG_TPL_STACK)
+#elif defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_STACK)
ldr x0, =(CONFIG_SPL_STACK)
 #else
ldr x0, =(CONFIG_SYS_INIT_SP_ADDR)
diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt
index 1ab6101..34aadc5 100644
--- a/scripts/config_whitelist.txt
+++ b/scripts/config_whitelist.txt
@@ -4997,6 +4997,7 @@ CONFIG_TI_SPI_MMAP
 CONFIG_TMU_TIMER
 CONFIG_TPL_DRIVERS_MISC_SUPPORT
 CONFIG_TPL_PAD_TO
+CONFIG_TPL_STACK
 CONFIG_TPM_TIS_BASE_ADDRESS
 CONFIG_TPS6586X_POWER
 CONFIG_TQM834X
-- 
2.1.4

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

[U-Boot] [PATCH 18/52] lib: spl: differentiate between TPL and SPL for libfdt/of_control/of_platdata

[Philipp Tomsich]

This splits the compilation of code modules for TPL and SPL for
OF_CONTROL (and related) features between TPL and SPL.  The typical
use-case of this is a TPL stage that uses OF_PLATDATA at TPL and
provides full OF_CONTROL at SPL (e.g. on the RK3368).

Signed-off-by: Philipp Tomsich 
---

 lib/Makefile | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/lib/Makefile b/lib/Makefile
index eacc7d6..2eef1eb 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -49,11 +49,11 @@ obj-$(CONFIG_RSA) += rsa/
 obj-$(CONFIG_SHA1) += sha1.o
 obj-$(CONFIG_SHA256) += sha256.o
 
-obj-$(CONFIG_SPL_SAVEENV) += qsort.o
-obj-$(CONFIG_$(SPL_)OF_LIBFDT) += libfdt/
-ifneq ($(CONFIG_SPL_BUILD)$(CONFIG_SPL_OF_PLATDATA),yy)
-obj-$(CONFIG_$(SPL_)OF_CONTROL) += fdtdec_common.o
-obj-$(CONFIG_$(SPL_)OF_CONTROL) += fdtdec.o
+obj-$(CONFIG_$(SPL_TPL_)SAVEENV) += qsort.o
+obj-$(CONFIG_$(SPL_TPL_)OF_LIBFDT) += libfdt/
+ifneq ($(CONFIG_$(SPL_TPL_)BUILD)$(CONFIG_$(SPL_TPL_)OF_PLATDATA),yy)
+obj-$(CONFIG_$(SPL_TPL_)OF_CONTROL) += fdtdec_common.o
+obj-$(CONFIG_$(SPL_TPL_)OF_CONTROL) += fdtdec.o
 endif
 
 ifdef CONFIG_SPL_BUILD
-- 
2.1.4

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

[U-Boot] [PATCH 47/52] rockchip: rk3368: spl: add TPL support

[Philipp Tomsich]

This adds the TPL support for the RK3368, including the u-boot-tpl.lds.

Signed-off-by: Philipp Tomsich 
---

 arch/arm/mach-rockchip/Makefile  |   1 +
 arch/arm/mach-rockchip/rk3368-board-tpl.c| 158 +++
 arch/arm/mach-rockchip/rk3368/u-boot-tpl.lds |  13 +++
 3 files changed, 172 insertions(+)
 create mode 100644 arch/arm/mach-rockchip/rk3368-board-tpl.c
 create mode 100644 arch/arm/mach-rockchip/rk3368/u-boot-tpl.lds

diff --git a/arch/arm/mach-rockchip/Makefile b/arch/arm/mach-rockchip/Makefile
index 633c91e..960f40f 100644
--- a/arch/arm/mach-rockchip/Makefile
+++ b/arch/arm/mach-rockchip/Makefile
@@ -12,6 +12,7 @@ obj-spl-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o 
save_boot_param.o
 obj-tpl-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o save_boot_param.o
 
 obj-tpl-$(CONFIG_ROCKCHIP_RK3188) += rk3188-board-tpl.o
+obj-tpl-$(CONFIG_ROCKCHIP_RK3368) += rk3368-board-tpl.o
 
 obj-spl-$(CONFIG_ROCKCHIP_RK3036) += rk3036-board-spl.o
 obj-spl-$(CONFIG_ROCKCHIP_RK3188) += rk3188-board-spl.o
diff --git a/arch/arm/mach-rockchip/rk3368-board-tpl.c 
b/arch/arm/mach-rockchip/rk3368-board-tpl.c
new file mode 100644
index 000..376b478
--- /dev/null
+++ b/arch/arm/mach-rockchip/rk3368-board-tpl.c
@@ -0,0 +1,158 @@
+/*
+ * (C) Copyright 2017 Theobroma Systems Design und Consulting GmbH
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#define DEBUG
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+/*
+ * The ARMv8 generic timer uses the STIMER1 as its clock-source.
+ * Set up the STIMER1 to free-running (i.e. auto-reload) to start
+ * the generic timer counting (if we don't do this, udelay will not
+ * work and block indefinitively).
+ */
+static void secure_timer_init(void)
+{
+   struct rk_timer * const stimer1 =
+   (struct rk_timer * const)0xff830020;
+   const u32 TIMER_EN = BIT(0);
+
+   writel(~0u, &stimer1->timer_load_count0);
+   writel(~0u, &stimer1->timer_load_count1);
+   writel(TIMER_EN, &stimer1->timer_ctrl_reg);
+}
+
+/*
+ * The SPL (and also the full U-Boot stage on the RK3368) will run in
+ * secure mode (i.e. EL3) and an ATF will eventually be booted before
+ * starting up the operating system... so we can initialize the SGRF
+ * here and rely on the ATF installing the final (secure) policy
+ * later.
+ */
+static inline uintptr_t sgrf_soc_con_addr(unsigned no)
+{
+   const uintptr_t SGRF_BASE = 0xff74;
+
+   return SGRF_BASE + sizeof(u32) * no;
+}
+
+static inline uintptr_t sgrf_busdmac_addr(unsigned no)
+{
+   const uintptr_t SGRF_BUSDMAC_BASE = 0xff740100;
+
+   return SGRF_BUSDMAC_BASE + sizeof(u32) * no;
+}
+
+static void sgrf_init(void)
+{
+   struct rk3368_cru * const cru =
+   (struct rk3368_cru * const)0xff76;
+   const u16 SGRF_SOC_CON_SEC = GENMASK(15, 0);
+   const u16 SGRF_BUSDMAC_CON0_SEC = BIT(2);
+   const u16 SGRF_BUSDMAC_CON1_SEC = GENMASK(15, 12);
+
+   /* Set all configurable IP to 'non secure'-mode */
+   rk_setreg(sgrf_soc_con_addr(5), SGRF_SOC_CON_SEC);
+   rk_setreg(sgrf_soc_con_addr(6), SGRF_SOC_CON_SEC);
+   rk_setreg(sgrf_soc_con_addr(7), SGRF_SOC_CON_SEC);
+
+   /*
+* From rockchip-uboot/arch/arm/cpu/armv8/rk33xx/cpu.c
+* Original comment: "ddr space set no secure mode"
+*/
+   rk_clrreg(sgrf_soc_con_addr(8), SGRF_SOC_CON_SEC);
+   rk_clrreg(sgrf_soc_con_addr(9), SGRF_SOC_CON_SEC);
+   rk_clrreg(sgrf_soc_con_addr(10), SGRF_SOC_CON_SEC);
+
+   /* Set 'secure dma' to 'non secure'-mode */
+   rk_setreg(sgrf_busdmac_addr(0), SGRF_BUSDMAC_CON0_SEC);
+   rk_setreg(sgrf_busdmac_addr(1), SGRF_BUSDMAC_CON1_SEC);
+
+   dsb();  /* barrier */
+
+   rk_setreg(&cru->softrst_con[1], DMA1_SRST_REQ);
+   rk_setreg(&cru->softrst_con[4], DMA2_SRST_REQ);
+
+   dsb();  /* barrier */
+   udelay(10);
+
+   rk_clrreg(&cru->softrst_con[1], DMA1_SRST_REQ);
+   rk_clrreg(&cru->softrst_con[4], DMA2_SRST_REQ);
+}
+
+void board_debug_uart_init(void)
+{
+   struct rk3368_grf * const grf =
+   (struct rk3368_grf * const)0xff77;
+
+#if defined(CONFIG_DEBUG_UART_BASE) && (CONFIG_DEBUG_UART_BASE == 0xff18)
+   /* Enable early UART0 on the RK3368 */
+   rk_clrsetreg(&grf->gpio2d_iomux,
+RK3368_GPIO2D0_MASK, RK3368_GPIO2D0_UART0_SIN);
+   rk_clrsetreg(&grf->gpio2d_iomux,
+RK3368_GPIO2D1_MASK, RK3368_GPIO2D1_UART0_SOUT);
+#endif
+}
+
+void board_init_f(ulong dummy)
+{
+   struct udevice *dev;
+   int ret;
+
+#define EARLY_UART
+#ifdef EARLY_UART
+   /*
+* Debug UART can be used from here if required:
+*
+* debug_uart_init();
+* printch('a');
+* printhex8(0x1234);
+* printascii("string");
+*/
+   debug_uart_init();
+   printascii("U-Boot 

[U-Boot] [PATCH 31/52] rockchip: pinctrl: rk3368: add GMAC (RGMII only) support

[Philipp Tomsich]

To add GMAC (Gigabit Ethernet) support (limited to RGMII only at this
point), we need support for additional pin-configuration.  This commit
adds the pinctrl support for GMAC in RGMII mode:
 * adds a PERIPH_ID_GMAC and the mapping from IRQ number to PERIPH_ID
 * configures the RGMII pins

Signed-off-by: Philipp Tomsich 
---

 drivers/pinctrl/rockchip/pinctrl_rk3368.c | 36 +++
 1 file changed, 36 insertions(+)

diff --git a/drivers/pinctrl/rockchip/pinctrl_rk3368.c 
b/drivers/pinctrl/rockchip/pinctrl_rk3368.c
index b77c5ab..aecd11d 100644
--- a/drivers/pinctrl/rockchip/pinctrl_rk3368.c
+++ b/drivers/pinctrl/rockchip/pinctrl_rk3368.c
@@ -54,6 +54,33 @@ static void pinctrl_rk3368_uart_config(struct 
rk3368_pinctrl_priv *priv,
}
 }
 
+#if CONFIG_IS_ENABLED(GMAC_ROCKCHIP)
+static void pinctrl_rk3368_gmac_config(struct rk3368_grf *grf, int gmac_id)
+{
+   rk_clrsetreg(&grf->gpio3b_iomux,
+RK3368_GPIO3B0_MASK | RK3368_GPIO3B1_MASK |
+RK3368_GPIO3B2_MASK | RK3368_GPIO3B5_MASK |
+RK3368_GPIO3B6_MASK | RK3368_GPIO3B7_MASK,
+RK3368_GPIO3B0_MAC_TXD0 | RK3368_GPIO3B1_MAC_TXD1 |
+RK3368_GPIO3B2_MAC_TXD2 | RK3368_GPIO3B5_MAC_TXEN |
+RK3368_GPIO3B6_MAC_TXD3 | RK3368_GPIO3B7_MAC_RXD0);
+   rk_clrsetreg(&grf->gpio3c_iomux,
+RK3368_GPIO3C0_MASK | RK3368_GPIO3C1_MASK |
+RK3368_GPIO3C2_MASK | RK3368_GPIO3C3_MASK |
+RK3368_GPIO3C4_MASK | RK3368_GPIO3C5_MASK |
+RK3368_GPIO3C6_MASK,
+RK3368_GPIO3C0_MAC_RXD1 | RK3368_GPIO3C1_MAC_RXD2 |
+RK3368_GPIO3C2_MAC_RXD3 | RK3368_GPIO3C3_MAC_MDC |
+RK3368_GPIO3C4_MAC_RXDV | RK3368_GPIO3C5_MAC_RXEN |
+RK3368_GPIO3C6_MAC_CLK);
+   rk_clrsetreg(&grf->gpio3d_iomux,
+RK3368_GPIO3D0_MASK | RK3368_GPIO3D1_MASK |
+RK3368_GPIO3D4_MASK,
+RK3368_GPIO3D0_MAC_MDIO | RK3368_GPIO3D1_MAC_RXCLK |
+RK3368_GPIO3D4_MAC_TXCLK);
+}
+#endif
+
 static int rk3368_pinctrl_request(struct udevice *dev, int func, int flags)
 {
struct rk3368_pinctrl_priv *priv = dev_get_priv(dev);
@@ -67,6 +94,11 @@ static int rk3368_pinctrl_request(struct udevice *dev, int 
func, int flags)
case PERIPH_ID_UART4:
pinctrl_rk3368_uart_config(priv, func);
break;
+#if CONFIG_IS_ENABLED(GMAC_ROCKCHIP)
+   case PERIPH_ID_GMAC:
+   pinctrl_rk3368_gmac_config(priv->grf, func);
+   break;
+#endif
default:
return -EINVAL;
}
@@ -96,6 +128,10 @@ static int rk3368_pinctrl_get_periph_id(struct udevice *dev,
return PERIPH_ID_UART1;
case 55:
return PERIPH_ID_UART0;
+#if CONFIG_IS_ENABLED(GMAC_ROCKCHIP)
+   case 27:
+   return PERIPH_ID_GMAC;
+#endif
}
 
return -ENOENT;
-- 
2.1.4

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

[U-Boot] [PATCH 11/52] spl: dm: Kconfig: split CLK support for SPL and TPL

[Philipp Tomsich]

Introduce TPL_CLK to allow finer-grained selection of TPL features
for feature-rich (i.e. DM-based) TPL stages.

Signed-off-by: Philipp Tomsich 
---

 drivers/clk/Kconfig  | 10 ++
 drivers/clk/Makefile |  2 +-
 2 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 9c13587..b40bde2 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -20,6 +20,16 @@ config SPL_CLK
  setting up clocks within SPL, and allows the same drivers to be
  used as U-Boot proper.
 
+config TPL_CLK
+   bool "Enable clock support in TPL"
+   depends on CLK && TPL_DM
+   help
+ The clock subsystem adds a small amount of overhead to the image.
+ If this is acceptable and you have a need to use clock drivers in
+ SPL, enable this option. It might provide a cleaner interface to
+ setting up clocks within TPL, and allows the same drivers to be
+ used as U-Boot proper.
+
 config CLK_BCM6345
bool "Clock controller driver for BCM6345"
depends on CLK && ARCH_BMIPS
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 2746a80..844bc4e 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -5,7 +5,7 @@
 # SPDX-License-Identifier:  GPL-2.0+
 #
 
-obj-$(CONFIG_CLK) += clk-uclass.o clk_fixed_rate.o
+obj-$(CONFIG_$(SPL_TPL_)CLK) += clk-uclass.o clk_fixed_rate.o
 obj-$(CONFIG_ARCH_ROCKCHIP) += rockchip/
 obj-$(CONFIG_SANDBOX) += clk_sandbox.o
 obj-$(CONFIG_SANDBOX) += clk_sandbox_test.o
-- 
2.1.4

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

[U-Boot] [PATCH 46/52] rockchip: rk3368: spl: enable SPL_FRAMEWORK in rk3368_common.h

[Philipp Tomsich]

To build TPL and SPL stages for the RK3368, we will also need to
enable the SPL_FRAMEWORK.

Signed-off-by: Philipp Tomsich 
---

 include/configs/rk3368_common.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/configs/rk3368_common.h b/include/configs/rk3368_common.h
index 8ffc293..2a3876e 100644
--- a/include/configs/rk3368_common.h
+++ b/include/configs/rk3368_common.h
@@ -24,6 +24,7 @@
 
 #define COUNTER_FREQUENCY   2400
 
+#define CONFIG_SPL_FRAMEWORK
 #define CONFIG_SYS_NS16550_MEM32
 
 #define CONFIG_SYS_TEXT_BASE   0x0020
-- 
2.1.4

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

[U-Boot] [PATCH 16/52] spl: allow a separate TEXT_BASE, LDSCRIPT and MAX_SIZE for TPL

[Philipp Tomsich]

For the bringup of the RK3368, we need to support TPL and SPL running
from different addresses... which requires both stages to use a
distinct TEXT_BASE.

This commit adds support for having a separate LDSCRIPT for TPL (which
is expected to make use of the TPL_MAX_SIZE define) and for having a
the option of defining TPL_TEXT_BASE and having the TPL stage linked
against this address.

Note that the handling of the TEXT_BASE is designed to not interfere
with the previous assumption that SPL_TEXT_BASE should be used for TPL
as well, unless TPL_TEXT_BASE is defined.  For this reason, the test
in Makefile.spl uses the following (seemingly redundant checks):
 1. looks for $(SPL_TPL_)TEXT_BASE
 2. looks for SPL_TEXT_BASE (even when building in TPL)

Signed-off-by: Philipp Tomsich 
---

 scripts/Makefile.spl | 10 --
 scripts/config_whitelist.txt |  3 +++
 2 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl
index 3e35cd6..4a9a58f 100644
--- a/scripts/Makefile.spl
+++ b/scripts/Makefile.spl
@@ -103,9 +103,9 @@ u-boot-spl-platdata := $(obj)/dts/dt-platdata.o
 endif
 
 # Linker Script
-ifdef CONFIG_SPL_LDSCRIPT
+ifdef CONFIG_$(SPL_TPL_)LDSCRIPT
 # need to strip off double quotes
-LDSCRIPT := $(addprefix $(srctree)/,$(CONFIG_SPL_LDSCRIPT:"%"=%))
+LDSCRIPT := $(addprefix $(srctree)/,$(CONFIG_$(SPL_TPL_)LDSCRIPT:"%"=%))
 endif
 
 ifeq ($(wildcard $(LDSCRIPT)),)
@@ -293,9 +293,15 @@ LDFLAGS_$(SPL_BIN) += -T u-boot-spl.lds $(LDFLAGS_FINAL)
 # Avoid 'Not enough room for program headers' error on binutils 2.28 onwards.
 LDFLAGS_$(SPL_BIN) += $(call ld-option, --no-dynamic-linker)
 
+# First try the best-match (i.e. SPL_TEXT_BASE for SPL, TPL_TEXT_BASE for TPL)
+ifneq ($(CONFIG_$(SPL_TPL_)TEXT_BASE),)
+LDFLAGS_$(SPL_BIN) += -Ttext $(CONFIG_$(SPL_TPL_)TEXT_BASE)
+else
+# And then fall back to just testing for SPL_TEXT_BASE, even if in TPL mode
 ifneq ($(CONFIG_SPL_TEXT_BASE),)
 LDFLAGS_$(SPL_BIN) += -Ttext $(CONFIG_SPL_TEXT_BASE)
 endif
+endif
 
 MKIMAGEFLAGS_$(SPL_BIN).sfp = -T socfpgaimage
 $(obj)/$(SPL_BIN).sfp: $(obj)/$(SPL_BIN).bin FORCE
diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt
index 34aadc5..d8d00f5 100644
--- a/scripts/config_whitelist.txt
+++ b/scripts/config_whitelist.txt
@@ -4996,8 +4996,11 @@ CONFIG_TI_KSNAV
 CONFIG_TI_SPI_MMAP
 CONFIG_TMU_TIMER
 CONFIG_TPL_DRIVERS_MISC_SUPPORT
+CONFIG_TPL_LDSCRIPT
+CONFIG_TPL_MAX_SIZE
 CONFIG_TPL_PAD_TO
 CONFIG_TPL_STACK
+CONFIG_TPL_TEXT_BASE
 CONFIG_TPM_TIS_BASE_ADDRESS
 CONFIG_TPS6586X_POWER
 CONFIG_TQM834X
-- 
2.1.4

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

[U-Boot] [PATCH 35/52] rockchip: clk: rk3368: do not change CPLL/GPLL before returning to BROM

[Philipp Tomsich]

The RK3368 has a somewhat temperamental BootROM (which I learned the
hard way) when it comes to reconfiguring the CPLL and GPLL (in fact,
experiments show that changing the GPLL broke things for me, while
changing the CPLL seems to be more benign).  These should not be
modified by the SPL stage, if we intend to return to the BootROM for
chain booting the next stage.

This commit changes the clock initialisation to not change CPLL/GPLL
before returning to the BootROM (i.e. in TPL).  As it's safe to change
these settings if we no longer intend to return to U-Boot, we'll run
the full PLL setup a little later (i.e. in SPL).

Signed-off-by: Philipp Tomsich 
---

 drivers/clk/rockchip/clk_rk3368.c | 18 +-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/rockchip/clk_rk3368.c 
b/drivers/clk/rockchip/clk_rk3368.c
index 809ad19..d05be72 100644
--- a/drivers/clk/rockchip/clk_rk3368.c
+++ b/drivers/clk/rockchip/clk_rk3368.c
@@ -50,10 +50,14 @@ struct pll_div {
   (_nr * _no) == hz, #hz "Hz cannot be hit with PLL " \
   "divisors on line " __stringify(__LINE__));
 
+#if IS_ENABLED(CONFIG_SPL_BUILD) || IS_ENABLED(CONFIG_TPL_BUILD)
 static const struct pll_div apll_l_init_cfg = PLL_DIVISORS(APLL_L_HZ, 12, 2);
 static const struct pll_div apll_b_init_cfg = PLL_DIVISORS(APLL_B_HZ, 1, 2);
+#if !defined(CONFIG_TPL_BUILD)
 static const struct pll_div gpll_init_cfg = PLL_DIVISORS(GPLL_HZ, 1, 2);
 static const struct pll_div cpll_init_cfg = PLL_DIVISORS(CPLL_HZ, 1, 6);
+#endif
+#endif
 
 /* Get pll rate by id */
 static uint32_t rkclk_pll_get_rate(struct rk3368_cru *cru,
@@ -82,6 +86,7 @@ static uint32_t rkclk_pll_get_rate(struct rk3368_cru *cru,
}
 }
 
+#if IS_ENABLED(CONFIG_SPL_BUILD) || IS_ENABLED(CONFIG_TPL_BUILD)
 static int rkclk_set_pll(struct rk3368_cru *cru, enum rk3368_pll_id pll_id,
 const struct pll_div *div)
 {
@@ -121,15 +126,23 @@ static int rkclk_set_pll(struct rk3368_cru *cru, enum 
rk3368_pll_id pll_id,
 
return 0;
 }
+#endif
 
+#if IS_ENABLED(CONFIG_SPL_BUILD) || IS_ENABLED(CONFIG_TPL_BUILD)
 static void rkclk_init(struct rk3368_cru *cru)
 {
u32 apllb, aplll, dpll, cpll, gpll;
 
rkclk_set_pll(cru, APLLB, &apll_b_init_cfg);
rkclk_set_pll(cru, APLLL, &apll_l_init_cfg);
+#if !defined(CONFIG_TPL_BUILD)
+   /*
+* If we plan to return to the boot ROM, we can't increase the
+* GPLL rate from the SPL stage.
+*/
rkclk_set_pll(cru, GPLL, &gpll_init_cfg);
rkclk_set_pll(cru, CPLL, &cpll_init_cfg);
+#endif
 
apllb = rkclk_pll_get_rate(cru, APLLB);
aplll = rkclk_pll_get_rate(cru, APLLL);
@@ -140,6 +153,7 @@ static void rkclk_init(struct rk3368_cru *cru)
debug("%s apllb(%d) apll(%d) dpll(%d) cpll(%d) gpll(%d)\n",
   __func__, apllb, aplll, dpll, cpll, gpll);
 }
+#endif
 
 static ulong rk3368_mmc_get_clk(struct rk3368_cru *cru, uint clk_id)
 {
@@ -261,13 +275,15 @@ static struct clk_ops rk3368_clk_ops = {
 
 static int rk3368_clk_probe(struct udevice *dev)
 {
-   struct rk3368_clk_priv *priv = dev_get_priv(dev);
+   struct rk3368_clk_priv __maybe_unused *priv = dev_get_priv(dev);
 #if CONFIG_IS_ENABLED(OF_PLATDATA)
struct rk3368_clk_plat *plat = dev_get_platdata(dev);
 
priv->cru = map_sysmem(plat->dtd.reg[1], plat->dtd.reg[3]);
 #endif
+#if IS_ENABLED(CONFIG_SPL_BUILD) || IS_ENABLED(CONFIG_TPL_BUILD)
rkclk_init(priv->cru);
+#endif
 
return 0;
 }
-- 
2.1.4

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

[U-Boot] [PATCH 24/52] rockchip: rk3368: mkimage: add support for the RK3368

[Philipp Tomsich]

This commit adds support for RK3368 SoC in mkimage.

Signed-off-by: Philipp Tomsich 
---

 tools/rkcommon.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tools/rkcommon.c b/tools/rkcommon.c
index 25b0340..04e8272 100644
--- a/tools/rkcommon.c
+++ b/tools/rkcommon.c
@@ -77,6 +77,7 @@ static struct spl_info spl_infos[] = {
{ "rk322x", "RK32", 0x8000 - 0x1000, false, false },
{ "rk3288", "RK32", 0x8000, false, false },
{ "rk3328", "RK32", 0x8000 - 0x1000, false, false },
+   { "rk3368", "RK33", 0x8000 - 0x1000, false, true },
{ "rk3399", "RK33", 0x3 - 0x2000, false, true },
{ "rv1108", "RK11", 0x1800, false, false},
 };
-- 
2.1.4

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

[U-Boot] [PATCH 39/52] rockchip: clk: rk3368: support configuring the DRAM PLL (from TPL)

[Philipp Tomsich]

As part of the DRAM initialisation process (running as part of the TPL
stage) on the RK3368, we need to set up the DRAM PLL.

This implements support for configuring the PLL to for 1200, 1332 or
1600 MHz (i.e. for DDR3-1200, DDR3-1333, DDR3-1600 operating modes).

Signed-off-by: Philipp Tomsich 
---

 drivers/clk/rockchip/clk_rk3368.c | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/drivers/clk/rockchip/clk_rk3368.c 
b/drivers/clk/rockchip/clk_rk3368.c
index 1327116..1bed4e2 100644
--- a/drivers/clk/rockchip/clk_rk3368.c
+++ b/drivers/clk/rockchip/clk_rk3368.c
@@ -308,18 +308,16 @@ static ulong rk3368_clk_get_rate(struct clk *clk)
return rate;
 }
 
+#if IS_ENABLED(CONFIG_TPL_BUILD)
 static ulong rk3368_ddr_set_clk(struct rk3368_cru *cru, ulong set_rate)
 {
const struct pll_div *dpll_cfg = NULL;
const ulong MHz = 100;
 
/* Fout = ((Fin /NR) * NF )/ NO */
-   static const struct pll_div dpll_1200 =
-   PLL_DIVISORS(1200 * MHz, 1, 1);
-   static const struct pll_div dpll_1332 =
-   PLL_DIVISORS(1332 * MHz, 2, 1);
-   static const struct pll_div dpll_1600 =
-   PLL_DIVISORS(1600 * MHz, 3, 2);
+   static const struct pll_div dpll_1200 = PLL_DIVISORS(1200 * MHz, 1, 1);
+   static const struct pll_div dpll_1332 = PLL_DIVISORS(1332 * MHz, 2, 1);
+   static const struct pll_div dpll_1600 = PLL_DIVISORS(1600 * MHz, 3, 2);
 
switch (set_rate) {
case 1200*MHz:
@@ -338,6 +336,7 @@ static ulong rk3368_ddr_set_clk(struct rk3368_cru *cru, 
ulong set_rate)
 
return set_rate;
 }
+#endif
 
 static ulong rk3368_clk_set_rate(struct clk *clk, ulong rate)
 {
@@ -346,9 +345,11 @@ static ulong rk3368_clk_set_rate(struct clk *clk, ulong 
rate)
 
debug("%s id:%ld rate:%ld\n", __func__, clk->id, rate);
switch (clk->id) {
+#if IS_ENABLED(CONFIG_TPL_BUILD)
case CLK_DDR:
ret = rk3368_ddr_set_clk(priv->cru, rate);
break;
+#endif
 #if !IS_ENABLED(CONFIG_SPL_BUILD) || CONFIG_IS_ENABLED(MMC_SUPPORT)
case HCLK_SDMMC:
case HCLK_EMMC:
-- 
2.1.4

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

[U-Boot] [PATCH 42/52] net: gmac_rockchip: Add support for the RK3368 GMAC

[Philipp Tomsich]

The GMAC in the RK3368 once again is identical to the incarnation in
the RK3288 and the RK3399, except for where some of the configuration
and control registers are located in the GRF.

This adds the RK3368-specific logic necessary to reuse this driver.

Signed-off-by: Philipp Tomsich 
---

 drivers/net/gmac_rockchip.c | 54 +
 1 file changed, 54 insertions(+)

diff --git a/drivers/net/gmac_rockchip.c b/drivers/net/gmac_rockchip.c
index c9f9e83..2e4a812 100644
--- a/drivers/net/gmac_rockchip.c
+++ b/drivers/net/gmac_rockchip.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -83,6 +84,32 @@ static int rk3288_gmac_fix_mac_speed(struct dw_eth_dev *priv)
return 0;
 }
 
+static int rk3368_gmac_fix_mac_speed(struct dw_eth_dev *priv)
+{
+   struct rk3368_grf *grf;
+   int clk;
+
+   switch (priv->phydev->speed) {
+   case 10:
+   clk = RK3368_GMAC_CLK_SEL_2_5M;
+   break;
+   case 100:
+   clk = RK3368_GMAC_CLK_SEL_25M;
+   break;
+   case 1000:
+   clk = RK3368_GMAC_CLK_SEL_125M;
+   break;
+   default:
+   debug("Unknown phy speed: %d\n", priv->phydev->speed);
+   return -EINVAL;
+   }
+
+   grf = syscon_get_first_range(ROCKCHIP_SYSCON_GRF);
+   rk_clrsetreg(&grf->soc_con15, RK3368_GMAC_CLK_SEL_MASK, clk);
+
+   return 0;
+}
+
 static int rk3399_gmac_fix_mac_speed(struct dw_eth_dev *priv)
 {
struct rk3399_grf_regs *grf;
@@ -129,6 +156,26 @@ static void rk3288_gmac_set_to_rgmii(struct 
gmac_rockchip_platdata *pdata)
 pdata->tx_delay << RK3288_CLK_TX_DL_CFG_GMAC_SHIFT);
 }
 
+static void rk3368_gmac_set_to_rgmii(struct gmac_rockchip_platdata *pdata)
+{
+   struct rk3368_grf *grf;
+
+   grf = syscon_get_first_range(ROCKCHIP_SYSCON_GRF);
+   rk_clrsetreg(&grf->soc_con15,
+RK3368_RMII_MODE_MASK | RK3368_GMAC_PHY_INTF_SEL_MASK,
+RK3368_GMAC_PHY_INTF_SEL_RGMII);
+
+   rk_clrsetreg(&grf->soc_con16,
+RK3368_RXCLK_DLY_ENA_GMAC_MASK |
+RK3368_TXCLK_DLY_ENA_GMAC_MASK |
+RK3368_CLK_RX_DL_CFG_GMAC_MASK |
+RK3368_CLK_TX_DL_CFG_GMAC_MASK,
+RK3368_RXCLK_DLY_ENA_GMAC_ENABLE |
+RK3368_TXCLK_DLY_ENA_GMAC_ENABLE |
+pdata->rx_delay << RK3368_CLK_RX_DL_CFG_GMAC_SHIFT |
+pdata->tx_delay << RK3368_CLK_TX_DL_CFG_GMAC_SHIFT);
+}
+
 static void rk3399_gmac_set_to_rgmii(struct gmac_rockchip_platdata *pdata)
 {
struct rk3399_grf_regs *grf;
@@ -208,6 +255,11 @@ const struct rk_gmac_ops rk3288_gmac_ops = {
.set_to_rgmii = rk3288_gmac_set_to_rgmii,
 };
 
+const struct rk_gmac_ops rk3368_gmac_ops = {
+   .fix_mac_speed = rk3368_gmac_fix_mac_speed,
+   .set_to_rgmii = rk3368_gmac_set_to_rgmii,
+};
+
 const struct rk_gmac_ops rk3399_gmac_ops = {
.fix_mac_speed = rk3399_gmac_fix_mac_speed,
.set_to_rgmii = rk3399_gmac_set_to_rgmii,
@@ -216,6 +268,8 @@ const struct rk_gmac_ops rk3399_gmac_ops = {
 static const struct udevice_id rockchip_gmac_ids[] = {
{ .compatible = "rockchip,rk3288-gmac",
  .data = (ulong)&rk3288_gmac_ops },
+   { .compatible = "rockchip,rk3368-gmac",
+ .data = (ulong)&rk3368_gmac_ops },
{ .compatible = "rockchip,rk3399-gmac",
  .data = (ulong)&rk3399_gmac_ops },
{ }
-- 
2.1.4

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

[U-Boot] [PATCH 48/52] rockchip: rk3368: spl: add SPL support

[Philipp Tomsich]

Adds SPL support for the RK3368 (assuming that our TPL stage has
initialised DRAM and set up the memory firewall).

This includes an implementation of board_debug_uart_init().

Signed-off-by: Philipp Tomsich 
---

 arch/arm/mach-rockchip/rk3368-board-spl.c | 91 +++
 1 file changed, 91 insertions(+)
 create mode 100644 arch/arm/mach-rockchip/rk3368-board-spl.c

diff --git a/arch/arm/mach-rockchip/rk3368-board-spl.c 
b/arch/arm/mach-rockchip/rk3368-board-spl.c
new file mode 100644
index 000..eefe3bf
--- /dev/null
+++ b/arch/arm/mach-rockchip/rk3368-board-spl.c
@@ -0,0 +1,91 @@
+/*
+ * (C) Copyright 2017 Theobroma Systems Design und Consulting GmbH
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+/*
+ * The ARMv8 generic timer uses the STIMER1 as its clock-source.
+ * Set up the STIMER1 to free-running (i.e. auto-reload) to start
+ * the generic timer counting (if we don't do this, udelay will not
+ * work and block indefinitively).
+ */
+static void secure_timer_init(void)
+{
+   struct rk_timer * const stimer1 =
+   (struct rk_timer * const)0xff830020;
+   const u32 TIMER_EN = BIT(0);
+
+   writel(~0u, &stimer1->timer_load_count0);
+   writel(~0u, &stimer1->timer_load_count1);
+   writel(TIMER_EN, &stimer1->timer_ctrl_reg);
+}
+
+void board_debug_uart_init(void)
+{
+   struct rk3368_grf * const grf =
+   (struct rk3368_grf * const)0xff77;
+
+#if defined(CONFIG_DEBUG_UART_BASE) && (CONFIG_DEBUG_UART_BASE == 0xff18)
+   /* Enable early UART0 on the RK3368 */
+   rk_clrsetreg(&grf->gpio2d_iomux,
+RK3368_GPIO2D0_MASK, RK3368_GPIO2D0_UART0_SIN);
+   rk_clrsetreg(&grf->gpio2d_iomux,
+RK3368_GPIO2D1_MASK, RK3368_GPIO2D1_UART0_SOUT);
+#endif
+}
+
+void board_init_f(ulong dummy)
+{
+   struct udevice *dev;
+   int ret;
+
+   ret = spl_early_init();
+   if (ret) {
+   debug("spl_early_init() failed: %d\n", ret);
+   hang();
+   }
+
+   /* Make sure the ARMv8 generic timer counts */
+   secure_timer_init();
+
+   ret = uclass_get_device(UCLASS_RAM, 0, &dev);
+   if (ret) {
+   debug("DRAM init failed: %d\n", ret);
+   return;
+   }
+}
+
+u32 spl_boot_mode(const u32 boot_device)
+{
+   return MMCSD_MODE_RAW;
+}
+
+u32 spl_boot_device(void)
+{
+   return BOOT_DEVICE_MMC1;
+}
+
+#ifdef CONFIG_SPL_LOAD_FIT
+int board_fit_config_name_match(const char *name)
+{
+   /* Just empty function now - can't decide what to choose */
+   debug("%s: %s\n", __func__, name);
+
+   return 0;
+}
+#endif
-- 
2.1.4

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

[U-Boot] [PATCH 45/52] rockchip: dts: rk3368: add DMC node in rk3368.dtsi

[Philipp Tomsich]

For full SPL support, including DRAM initialisation, we need a few
nodes from the DTS: this commit adds the DMC (DRAM controller) node,
the service_msch (memory scheduler) node and marks GRF, PMUGRF and CRU
as 'u-boot,dm-pre-reloc'.  In addition to this, we also include the
dt-binding for the DMC to allow DTS files including this DTSI to refer
to the symbolic constants for the DDR3 bin and for the
memory-schedule.

Note that the DMC contains both the memory regions for the
(Designware) protocol controller as well as the DDR PHY.

Signed-off-by: Philipp Tomsich 
---

 arch/arm/dts/rk3368.dtsi | 26 --
 1 file changed, 20 insertions(+), 6 deletions(-)

diff --git a/arch/arm/dts/rk3368.dtsi b/arch/arm/dts/rk3368.dtsi
index 9daf765..8dd6549 100644
--- a/arch/arm/dts/rk3368.dtsi
+++ b/arch/arm/dts/rk3368.dtsi
@@ -46,6 +46,7 @@
 #include 
 #include 
 #include 
+#include 
 
 / {
compatible = "rockchip,rk3368";
@@ -227,6 +228,23 @@
#clock-cells = <0>;
};
 
+   dmc: dmc@ff61 {
+   u-boot,dm-pre-reloc;
+   compatible = "rockchip,rk3368-dmc", "syscon";
+   rockchip,cru = <&cru>;
+   rockchip,grf = <&grf>;
+   rockchip,msch = <&service_msch>;
+   reg = <0 0xff61 0 0x400
+  0 0xff62 0 0x400>;
+   };
+
+   service_msch: syscon@ffac {
+   u-boot,dm-pre-reloc;
+   compatible = "rockchip,rk3368-msch", "syscon";
+   reg = <0x0 0xffac 0x0 0x2000>;
+   status = "okay";
+   };
+
sdmmc: dwmmc@ff0c {
compatible = "rockchip,rk3368-dw-mshc", 
"rockchip,rk3288-dw-mshc";
reg = <0x0 0xff0c 0x0 0x4000>;
@@ -546,12 +564,6 @@
status = "disabled";
};
 
-   dmc: dmc@ff61 {
-   u-boot,dm-pre-reloc;
-   compatible = "rockchip,rk3368-dmc", "syscon";
-   reg = <0x0 0xff61 0x0 0x1000>;
-   };
-
i2c0: i2c@ff65 {
compatible = "rockchip,rk3368-i2c", "rockchip,rk3288-i2c";
reg = <0x0 0xff65 0x0 0x1000>;
@@ -653,6 +665,7 @@
};
 
cru: clock-controller@ff76 {
+   u-boot,dm-pre-reloc;
compatible = "rockchip,rk3368-cru";
reg = <0x0 0xff76 0x0 0x1000>;
rockchip,grf = <&grf>;
@@ -661,6 +674,7 @@
};
 
grf: syscon@ff77 {
+   u-boot,dm-pre-reloc;
compatible = "rockchip,rk3368-grf", "syscon";
reg = <0x0 0xff77 0x0 0x1000>;
};
-- 
2.1.4

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

[U-Boot] [PATCH 40/52] rockchip: clk: rk3368: add support for GMAC (SLCK_MAC) clock

[Philipp Tomsich]

To enable the GMAC on the RK3368, we need to set up the clocking
appropriately to generate a tx_clk for the MAC.

This adds an implementation that implements the use of the <&ext_gmac>
clock (i.e. an external 125MHz clock for RGMII provided by the PHY).
This is the clock setup used by the boards currently supported by
U-Boot (i.e. Geekbox, Sheep and RK3368-uQ7).

This includes the change from commit
 - rockchip: clk: rk3368: define GMAC_MUX_SEL_EXTCLK

Signed-off-by: Philipp Tomsich 
---

 arch/arm/include/asm/arch-rockchip/cru_rk3368.h |  3 +++
 drivers/clk/rockchip/clk_rk3368.c   | 19 +--
 2 files changed, 20 insertions(+), 2 deletions(-)

diff --git a/arch/arm/include/asm/arch-rockchip/cru_rk3368.h 
b/arch/arm/include/asm/arch-rockchip/cru_rk3368.h
index 21f11e0..2b1197f 100644
--- a/arch/arm/include/asm/arch-rockchip/cru_rk3368.h
+++ b/arch/arm/include/asm/arch-rockchip/cru_rk3368.h
@@ -89,6 +89,9 @@ enum {
MCU_CLK_DIV_SHIFT   = 0,
MCU_CLK_DIV_MASK= GENMASK(4, 0),
 
+   /* CLKSEL43_CON */
+   GMAC_MUX_SEL_EXTCLK = BIT(8),
+
/* CLKSEL51_CON */
MMC_PLL_SEL_SHIFT   = 8,
MMC_PLL_SEL_MASK= GENMASK(9, 8),
diff --git a/drivers/clk/rockchip/clk_rk3368.c 
b/drivers/clk/rockchip/clk_rk3368.c
index 1bed4e2..2b6c8da 100644
--- a/drivers/clk/rockchip/clk_rk3368.c
+++ b/drivers/clk/rockchip/clk_rk3368.c
@@ -338,6 +338,19 @@ static ulong rk3368_ddr_set_clk(struct rk3368_cru *cru, 
ulong set_rate)
 }
 #endif
 
+#if CONFIG_IS_ENABLED(GMAC_ROCKCHIP)
+static ulong rk3368_gmac_set_clk(struct rk3368_cru *cru,
+ulong clk_id, ulong set_rate)
+{
+   /*
+* This models the 'assigned-clock-parents = <&ext_gmac>' from
+* the DTS and switches to the 'ext_gmac' clock parent.
+*/
+   rk_setreg(&cru->clksel_con[43], GMAC_MUX_SEL_EXTCLK);
+   return set_rate;
+}
+#endif
+
 static ulong rk3368_clk_set_rate(struct clk *clk, ulong rate)
 {
struct rk3368_clk_priv *priv = dev_get_priv(clk->dev);
@@ -356,10 +369,12 @@ static ulong rk3368_clk_set_rate(struct clk *clk, ulong 
rate)
ret = rk3368_mmc_set_clk(clk, rate);
break;
 #endif
+#if CONFIG_IS_ENABLED(GMAC_ROCKCHIP)
case SCLK_MAC:
-   /* nothing to do, as this is an external clock */
-   ret = rate;
+   /* select the external clock */
+   ret = rk3368_gmac_set_clk(priv->cru, clk->id, rate);
break;
+#endif
default:
return -ENOENT;
}
-- 
2.1.4

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

[U-Boot] [PATCH 50/52] rockchip: board: lion-rk3368: add support for the RK3368-uQ7

[Philipp Tomsich]

The RK3368-uQ7 (codenamed 'Lion') is a micro-Qseven (40mm x 70mm,
MXM-230 edge connector compatible with the Qseven specification)
form-factor system-on-module based on the octo-core Rockchip RK3368.
It is designed, supported and manufactured by Theobroma Systems.

It provides the following features:
 - 8x Cortex-A53 (in 2 clusters of 4 cores each)
 - (on-module) up to 4GB of DDR3 memory
 - (on-module) SPI-NOR flash
 - (on-module) eMMC
 - Gigabit Ethernet (with an on-module KSZ9031 PHY)
 - USB
 - HDMI
 - MIPI-DSI/single-channel LVDS (muxed on the 'LVDS-A' pin-group)
 - various 'slow' interfaces (e.g. UART, SPI, I2C, I2S, ...)

Signed-off-by: Philipp Tomsich 

---

 arch/arm/dts/Makefile  |   1 +
 arch/arm/dts/rk3368-lion.dts   | 209 +
 arch/arm/mach-rockchip/rk3368/Kconfig  |  21 +++
 board/theobroma-systems/lion_rk3368/Kconfig|  15 ++
 board/theobroma-systems/lion_rk3368/MAINTAINERS|  10 +
 board/theobroma-systems/lion_rk3368/Makefile   |   7 +
 board/theobroma-systems/lion_rk3368/README |  60 ++
 .../theobroma-systems/lion_rk3368/fit_spl_atf.its  |  51 +
 board/theobroma-systems/lion_rk3368/lion_rk3368.c  |  25 +++
 configs/lion-rk3368_defconfig  |  79 
 include/configs/lion_rk3368.h  |  19 ++
 11 files changed, 497 insertions(+)
 create mode 100644 arch/arm/dts/rk3368-lion.dts
 create mode 100644 board/theobroma-systems/lion_rk3368/Kconfig
 create mode 100644 board/theobroma-systems/lion_rk3368/MAINTAINERS
 create mode 100644 board/theobroma-systems/lion_rk3368/Makefile
 create mode 100644 board/theobroma-systems/lion_rk3368/README
 create mode 100644 board/theobroma-systems/lion_rk3368/fit_spl_atf.its
 create mode 100644 board/theobroma-systems/lion_rk3368/lion_rk3368.c
 create mode 100644 configs/lion-rk3368_defconfig
 create mode 100644 include/configs/lion_rk3368.h

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index fd28290..5a22bb1 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -42,6 +42,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += \
rk3288-veyron-mickey.dtb \
rk3288-veyron-minnie.dtb \
rk3328-evb.dtb \
+   rk3368-lion.dtb \
rk3368-sheep.dtb \
rk3368-geekbox.dtb \
rk3368-px5-evb.dtb \
diff --git a/arch/arm/dts/rk3368-lion.dts b/arch/arm/dts/rk3368-lion.dts
new file mode 100644
index 000..be5e3c9
--- /dev/null
+++ b/arch/arm/dts/rk3368-lion.dts
@@ -0,0 +1,209 @@
+/*
+ * (C) Copyright 2017 Theobroma Systems Design und Consulting GmbH
+ *
+ * SPDX-License-Identifier: GPL-2.0+   X11
+ */
+
+/dts-v1/;
+#include "rk3368.dtsi"
+#include 
+
+/ {
+   model = "Theobroma Systems RK3368-uQ7 SoM";
+   compatible = "tsd,rk3368-uq7", "tsd,lion", "rockchip,rk3368";
+
+   config {
+   u-boot,spl-payload-offset = <0x4>; /* @ 256KB */
+   u-boot,mmc-env-offset = <0x4000>;  /* @  16KB */
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   u-boot,spl-boot-order = &emmc, &sdmmc;
+   };
+
+   aliases {
+   mmc0 = &emmc;
+   mmc1 = &sdmmc;
+   };
+
+   memory@0 {
+   device_type = "memory";
+   reg = <0x0 0x0 0x0 0x8000>;
+   };
+
+   ext_gmac: gmac-clk {
+   compatible = "fixed-clock";
+   clock-frequency = <12500>;
+   clock-output-names = "ext_gmac";
+   #clock-cells = <0>;
+   };
+
+   vcc_sys: vcc-sys-regulator {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc_sys";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   regulator-always-on;
+   regulator-boot-on;
+   };
+};
+
+&dmc {
+/*
+ * possible settings for rockchip,memory-schedule
+ *   DMC_MSCH_CBDR   column -> bank -> device -> row
+ *   DMC_MSCH_CBRD   column -> bank -> row -> device
+ *   DMC_MSCH_CRBD   column -> row -> bank -> device
+ */
+   rockchip,memory-schedule = ;
+   rockchip,ddr-frequency = <8>;
+   rockchip,ddr-speed-bin = ;
+
+   status = "okay";
+};
+
+&uart0 {
+   status = "okay";
+};
+
+&emmc {
+   u-boot,dm-pre-reloc;
+   status = "okay";
+   bus-width = <8>;
+   cap-mmc-highspeed;
+   clock-frequency = <15000>;
+   disable-wp;
+   keep-power-in-suspend;
+   non-removable;
+   num-slots = <1>;
+   vmmc-supply = <&vcc33_io>;
+   vqmmc-supply = <&vcc18_io>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&emmc_clk>, <&emmc_cmd>, <&emmc_bus8>;
+};
+
+&sdmmc {
+   u-boot,dm-pre-reloc;
+   status = "okay";
+};
+
+&gmac {
+   status = "okay";
+   phy-supply = <&vcc33_io>;
+   phy-mode = "rgmii";
+   clock_in_out = "input";
+   snps,reset-gpio = <&gpio3 1

[U-Boot] [PATCH 20/52] spl: add TPL_DRIVER_MISC_SUPPORT option

[Philipp Tomsich]

This adds the TPL_DRIVER_MISC_SUPPORT option to allow activation of
DRIVER_MISC_SUPPORT for devices that need it in the TPL stage.

Signed-off-by: Philipp Tomsich 
---

 common/spl/Kconfig | 8 
 1 file changed, 8 insertions(+)

diff --git a/common/spl/Kconfig b/common/spl/Kconfig
index f49b958..def8107 100644
--- a/common/spl/Kconfig
+++ b/common/spl/Kconfig
@@ -718,6 +718,14 @@ config TPL_BOOTROM_SUPPORT
  BOOT_DEVICE_BOOTROM (or fall-through to the next boot device in the
  boot device list, if not implemented for a given board)
 
+config TPL_DRIVERS_MISC_SUPPORT
+   bool "Support misc drivers in TPL"
+   help
+ Enable miscellaneous drivers in TPL. These drivers perform various
+ tasks that don't fall nicely into other categories, Enable this
+ option to build the drivers in drivers/misc as part of an TPL
+ build, for those that support building in TPL (not all drivers do).
+
 config TPL_ENV_SUPPORT
bool "Support an environment"
help
-- 
2.1.4

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

[U-Boot] [PATCH 12/52] spl: dm: Kconfig: split OF_CONTROL and OF_PLATDATA between SPL and TPL

[Philipp Tomsich]

For the RK3368, we want to use OF_PLATDATA in TPL, but full OF_CONTROL
in SPL: this requires the introduction of a new family of
configuration options to decouple SPL_OF_CONTROL and SPL_OF_PLATDATA
from TPL.

Consequently, Makefile.spl needs to be adjusted to test for these
configuration items through the $(SPL_TPL_) macro instead of
hard-coding the SPL variant.

Signed-off-by: Philipp Tomsich 
---

 Makefile |  2 +-
 dts/Kconfig  | 29 +
 scripts/Makefile.spl |  4 ++--
 3 files changed, 32 insertions(+), 3 deletions(-)

diff --git a/Makefile b/Makefile
index 119ad49..d5cdf2a 100644
--- a/Makefile
+++ b/Makefile
@@ -1378,7 +1378,7 @@ u-boot.lds: $(LDSCRIPT) prepare FORCE
 spl/u-boot-spl.bin: spl/u-boot-spl
@:
 spl/u-boot-spl: tools prepare \
-   $(if $(CONFIG_OF_SEPARATE)$(CONFIG_SPL_OF_PLATDATA),dts/dt.dtb)
+   $(if 
$(CONFIG_OF_SEPARATE)$(CONFIG_$(SPL_TPL_)OF_PLATDATA),dts/dt.dtb)
$(Q)$(MAKE) obj=spl -f $(srctree)/scripts/Makefile.spl all
 
 spl/sunxi-spl.bin: spl/u-boot-spl
diff --git a/dts/Kconfig b/dts/Kconfig
index b3009af..bbadc32 100644
--- a/dts/Kconfig
+++ b/dts/Kconfig
@@ -32,6 +32,14 @@ config SPL_OF_CONTROL
  which is not enough to support device tree. Enable this option to
  allow such boards to be supported by U-Boot SPL.
 
+config TPL_OF_CONTROL
+   bool "Enable run-time configuration via Device Tree in TPL"
+   depends on TPL && OF_CONTROL
+   help
+ Some boards use device tree in U-Boot but only have 4KB of SRAM
+ which is not enough to support device tree. Enable this option to
+ allow such boards to be supported by U-Boot TPL.
+
 config OF_LIVE
bool "Enable use of a live tree"
depends on OF_CONTROL
@@ -135,4 +143,25 @@ config SPL_OF_PLATDATA
  declarations for each node. See README.platdata for more
  information.
 
+config TPL_OF_PLATDATA
+   bool "Generate platform data for use in TPL"
+   depends on TPL_OF_CONTROL
+   help
+ For very constrained SPL environments the overhead of decoding
+ device tree nodes and converting their contents into platform data
+ is too large. This overhead includes libfdt code as well as the
+ device tree contents itself. The latter is fairly compact, but the
+ former can add 3KB or more to a Thumb 2 Image.
+
+ This option enables generation of platform data from the device
+ tree as C code. This code creates devices using U_BOOT_DEVICE()
+ declarations. The benefit is that it allows driver code to access
+ the platform data directly in C structures, avoidin the libfdt
+ overhead.
+
+ This option works by generating C structure declarations for each
+ compatible string, then adding platform data and U_BOOT_DEVICE
+ declarations for each node. See README.platdata for more
+ information.
+
 endmenu
diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl
index ac3c2c7..3e35cd6 100644
--- a/scripts/Makefile.spl
+++ b/scripts/Makefile.spl
@@ -98,7 +98,7 @@ endif
 
 u-boot-spl-init := $(head-y)
 u-boot-spl-main := $(libs-y)
-ifdef CONFIG_SPL_OF_PLATDATA
+ifdef CONFIG_$(SPL_TPL_)OF_PLATDATA
 u-boot-spl-platdata := $(obj)/dts/dt-platdata.o
 endif
 
@@ -202,7 +202,7 @@ cmd_cat = cat $(filter-out $(PHONY), $^) > $@
 quiet_cmd_copy = COPY$@
   cmd_copy = cp $< $@
 
-ifeq 
($(CONFIG_SPL_OF_CONTROL)$(CONFIG_OF_SEPARATE)$(CONFIG_SPL_OF_PLATDATA),yy)
+ifeq 
($(CONFIG_$(SPL_TPL_)OF_CONTROL)$(CONFIG_OF_SEPARATE)$(CONFIG_$(SPL_TPL_)OF_PLATDATA),yy)
 $(obj)/$(SPL_BIN)-dtb.bin: $(obj)/$(SPL_BIN)-nodtb.bin \
$(if $(CONFIG_SPL_SEPARATE_BSS),,$(obj)/$(SPL_BIN)-pad.bin) \
$(obj)/$(SPL_BIN).dtb FORCE
-- 
2.1.4

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

[U-Boot] [PATCH 30/52] rockchip: rk3368: grf: use shifted-constants and prefix with RK3368_

[Philipp Tomsich]

The RK3368 GRF header was still defines with a shifted-mask but with
non-shifted function selectors for the IOMUX defines.  As the RK3368
support is still fresh enough to allow a quick rename, we do this now
before having more code use this.

As some of the downstream drivers (e.g. the Designware GMAC wrapper)
may need to include the grf-header of multiple devices, we rename the
various defines for the RK3368 by prefixing them with the device name.
This avoids future trouble during driver integration.

Signed-off-by: Philipp Tomsich 
---

 arch/arm/include/asm/arch-rockchip/grf_rk3368.h | 617 +---
 drivers/pinctrl/rockchip/pinctrl_rk3368.c   |  17 +-
 2 files changed, 334 insertions(+), 300 deletions(-)

diff --git a/arch/arm/include/asm/arch-rockchip/grf_rk3368.h 
b/arch/arm/include/asm/arch-rockchip/grf_rk3368.h
index a438f5d..a97dc1e 100644
--- a/arch/arm/include/asm/arch-rockchip/grf_rk3368.h
+++ b/arch/arm/include/asm/arch-rockchip/grf_rk3368.h
@@ -1,4 +1,6 @@
-/* (C) Copyright 2016 Rockchip Electronics Co., Ltd
+/*
+ * (C) Copyright 2016 Rockchip Electronics Co., Ltd
+ * (C) Copyright 2017 Theobroma Systems Design und Consulting GmbH
  *
  * SPDX-License-Identifier: GPL-2.0+
  */
@@ -100,315 +102,318 @@ check_member(rk3368_pmu_grf, os_reg[0], 0x200);
 
 /*GRF_GPIO0C_IOMUX*/
 enum {
-   GPIO0C7_SHIFT   = 14,
-   GPIO0C7_MASK= 3 << GPIO0C7_SHIFT,
-   GPIO0C7_GPIO= 0,
-   GPIO0C7_LCDC_D19,
-   GPIO0C7_TRACE_D9,
-   GPIO0C7_UART1_RTSN,
-
-   GPIO0C6_SHIFT   = 12,
-   GPIO0C6_MASK= 3 << GPIO0C6_SHIFT,
-   GPIO0C6_GPIO= 0,
-   GPIO0C6_LCDC_D18,
-   GPIO0C6_TRACE_D8,
-   GPIO0C6_UART1_CTSN,
-
-   GPIO0C5_SHIFT   = 10,
-   GPIO0C5_MASK= 3 << GPIO0C5_SHIFT,
-   GPIO0C5_GPIO= 0,
-   GPIO0C5_LCDC_D17,
-   GPIO0C5_TRACE_D7,
-   GPIO0C5_UART1_SOUT,
-
-   GPIO0C4_SHIFT   = 8,
-   GPIO0C4_MASK= 3 << GPIO0C4_SHIFT,
-   GPIO0C4_GPIO= 0,
-   GPIO0C4_LCDC_D16,
-   GPIO0C4_TRACE_D6,
-   GPIO0C4_UART1_SIN,
-
-   GPIO0C3_SHIFT   = 6,
-   GPIO0C3_MASK= 3 << GPIO0C3_SHIFT,
-   GPIO0C3_GPIO= 0,
-   GPIO0C3_LCDC_D15,
-   GPIO0C3_TRACE_D5,
-   GPIO0C3_MCU_JTAG_TDO,
-
-   GPIO0C2_SHIFT   = 4,
-   GPIO0C2_MASK= 3 << GPIO0C2_SHIFT,
-   GPIO0C2_GPIO= 0,
-   GPIO0C2_LCDC_D14,
-   GPIO0C2_TRACE_D4,
-   GPIO0C2_MCU_JTAG_TDI,
-
-   GPIO0C1_SHIFT   = 2,
-   GPIO0C1_MASK= 3 << GPIO0C1_SHIFT,
-   GPIO0C1_GPIO= 0,
-   GPIO0C1_LCDC_D13,
-   GPIO0C1_TRACE_D3,
-   GPIO0C1_MCU_JTAG_TRTSN,
-
-   GPIO0C0_SHIFT   = 0,
-   GPIO0C0_MASK= 3 << GPIO0C0_SHIFT,
-   GPIO0C0_GPIO= 0,
-   GPIO0C0_LCDC_D12,
-   GPIO0C0_TRACE_D2,
-   GPIO0C0_MCU_JTAG_TDO,
+   RK3368_GPIO0C7_MASK= GENMASK(15, 14),
+   RK3368_GPIO0C7_GPIO= 0,
+   RK3368_GPIO0C7_LCDC_D19= (1 << 14),
+   RK3368_GPIO0C7_TRACE_D9= (2 << 14),
+   RK3368_GPIO0C7_UART1_RTSN  = (3 << 14),
+
+   RK3368_GPIO0C6_MASK= GENMASK(13, 12),
+   RK3368_GPIO0C6_GPIO= 0,
+   RK3368_GPIO0C6_LCDC_D18= (1 << 12),
+   RK3368_GPIO0C6_TRACE_D8= (2 << 12),
+   RK3368_GPIO0C6_UART1_CTSN  = (3 << 12),
+
+   RK3368_GPIO0C5_MASK= GENMASK(11, 10),
+   RK3368_GPIO0C5_GPIO= 0,
+   RK3368_GPIO0C5_LCDC_D17= (1 << 10),
+   RK3368_GPIO0C5_TRACE_D7= (2 << 10),
+   RK3368_GPIO0C5_UART1_SOUT  = (3 << 10),
+
+   RK3368_GPIO0C4_MASK= GENMASK(9, 8),
+   RK3368_GPIO0C4_GPIO= 0,
+   RK3368_GPIO0C4_LCDC_D16= (1 << 8),
+   RK3368_GPIO0C4_TRACE_D6= (2 << 8),
+   RK3368_GPIO0C4_UART1_SIN   = (3 << 8),
+
+   RK3368_GPIO0C3_MASK= GENMASK(7, 6),
+   RK3368_GPIO0C3_GPIO= 0,
+   RK3368_GPIO0C3_LCDC_D15= (1 << 6),
+   RK3368_GPIO0C3_TRACE_D5= (2 << 6),
+   RK3368_GPIO0C3_MCU_JTAG_TDO= (3 << 6),
+
+   RK3368_GPIO0C2_MASK= GENMASK(5, 4),
+   RK3368_GPIO0C2_GPIO= 0,
+   RK3368_GPIO0C2_LCDC_D14= (1 << 4),
+   RK3368_GPIO0C2_TRACE_D4= (2 << 4),
+   RK3368_GPIO0C2_MCU_JTAG_TDI= (3 << 4),
+
+   RK3368_GPIO0C1_MASK= GENMASK(3, 2),
+   RK3368_GPIO0C1_GPIO= 0,
+   RK3368_GPIO0C1_LCDC_D13= (1 << 2),
+   RK3368_GPIO0C1_TRACE_D3= (2 << 2),
+   RK3368_GPIO0C1_MCU_JTAG_TRTSN  = (3 << 2),
+
+   RK3368_GPIO0C0_MASK= GENMASK(1, 0),
+   RK3368_GPIO0C0_GPIO= 0,
+   RK3368_GPIO0C0_LCDC_D12= (1 << 0),
+   RK3368_GPIO0C

[U-Boot] [PATCH 27/52] rockchip: rk3368: spl: define COUNTER_FREQUENCY to 24MHz

[Philipp Tomsich]

The BootROM of the RK3368 Boot ROM does not initialise cntfrq_el0.
This change defines COUNTER_FREQUENCY, which is used by the AArch64 init
code in arch/arm/cpu/armv8/start.S to set up cntfrq_el0.

If the counter-frequency is not correctly set up, the calculation of
delays using the ARMv8 generic timer can not work correctly.

Signed-off-by: Philipp Tomsich 
---

 include/configs/rk3368_common.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/configs/rk3368_common.h b/include/configs/rk3368_common.h
index 488f8c5..7ab3b46 100644
--- a/include/configs/rk3368_common.h
+++ b/include/configs/rk3368_common.h
@@ -22,6 +22,8 @@
 #define CONFIG_SYS_CBSIZE  1024
 #define CONFIG_SKIP_LOWLEVEL_INIT
 
+#define COUNTER_FREQUENCY   2400
+
 #define CONFIG_SYS_NS16550_MEM32
 
 #define CONFIG_SYS_TEXT_BASE   0x0020
-- 
2.1.4

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

[U-Boot] [PATCH 14/52] armv8: remove unused low-level modules from TPL

[Philipp Tomsich]

TPL builds today don't need to call into firmware or set up the MMU
(if this changes, it should be controlled through a config option
whether to include this or not), but include the needed support code
for this anyway.

Even for a feature-rich TPL (including DM support as for the RK3368),
this equates to a size difference of approx. 10% in TPL binary size:
- without this change:
   textdatabssdechex filename
  236353112 24  26771   6893 tpl/u-boot-tpl
- with this change:
   textdatabssdechex filename
  215833112 24  24719   608f tpl/u-boot-tpl

Signed-off-by: Philipp Tomsich 
---

 arch/arm/cpu/armv8/Makefile | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm/cpu/armv8/Makefile b/arch/arm/cpu/armv8/Makefile
index c447085..e831471 100644
--- a/arch/arm/cpu/armv8/Makefile
+++ b/arch/arm/cpu/armv8/Makefile
@@ -9,12 +9,14 @@ extra-y   := start.o
 
 obj-y  += cpu.o
 obj-y  += generic_timer.o
+ifndef CONFIG_TPL_BUILD
 obj-y  += cache_v8.o
-obj-y  += exceptions.o
 obj-y  += cache.o
 obj-y  += tlb.o
 obj-y  += transition.o
 obj-y  += fwcall.o
+endif
+obj-y  += exceptions.o
 obj-y  += cpu-dt.o
 obj-$(CONFIG_ARM_SMCCC)+= smccc-call.o
 
-- 
2.1.4

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

[U-Boot] [PATCH 41/52] rockchip: clk: rk3368: mark 'priv' __maybe_unused in rk3368_clk_set_rate()

[Philipp Tomsich]

With the clock support in rk3368_clk_set_rate() conditionalized on
various feature definitions, 'priv' can remain unused (e.g. in the
SPL build when only MMC is enabled).

Signed-off-by: Philipp Tomsich 
---

 drivers/clk/rockchip/clk_rk3368.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clk/rockchip/clk_rk3368.c 
b/drivers/clk/rockchip/clk_rk3368.c
index 2b6c8da..d3f6c29 100644
--- a/drivers/clk/rockchip/clk_rk3368.c
+++ b/drivers/clk/rockchip/clk_rk3368.c
@@ -353,7 +353,7 @@ static ulong rk3368_gmac_set_clk(struct rk3368_cru *cru,
 
 static ulong rk3368_clk_set_rate(struct clk *clk, ulong rate)
 {
-   struct rk3368_clk_priv *priv = dev_get_priv(clk->dev);
+   __maybe_unused struct rk3368_clk_priv *priv = dev_get_priv(clk->dev);
ulong ret = 0;
 
debug("%s id:%ld rate:%ld\n", __func__, clk->id, rate);
-- 
2.1.4

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

[U-Boot] [PATCH 13/52] spl: dm: use CONFIG_IS_ENABLED to test for the DM option

[Philipp Tomsich]

Even though there's now a TPL_DM configuration option, the spl logic
still checks for SPL_DM and thus does not pick up the proper config
option.

This introduces the use of CONFIG_IS_ENABLED(DM) in spl.c to always
pick up the desired configuration option instead of having a
hard-coded check for the SPL variant.

Signed-off-by: Philipp Tomsich 
---

 common/spl/spl.c|  5 +++--
 include/linux/kconfig.h | 13 +
 2 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/common/spl/spl.c b/common/spl/spl.c
index db55d26..233e4fe 100644
--- a/common/spl/spl.c
+++ b/common/spl/spl.c
@@ -6,6 +6,7 @@
  *
  * SPDX-License-Identifier:GPL-2.0+
  */
+
 #include 
 #include 
 #include 
@@ -243,7 +244,7 @@ static int spl_common_init(bool setup_malloc)
return ret;
}
}
-   if (IS_ENABLED(CONFIG_SPL_DM)) {
+   if (CONFIG_IS_ENABLED(DM)) {
bootstage_start(BOOTSTATE_ID_ACCUM_DM_SPL, "dm_spl");
/* With CONFIG_SPL_OF_PLATDATA, bring in all devices */
ret = dm_init_and_scan(!CONFIG_IS_ENABLED(OF_PLATDATA));
@@ -425,7 +426,7 @@ void board_init_r(gd_t *dummy1, ulong dummy2)
  gd->malloc_ptr / 1024);
 #endif
 
-   if (IS_ENABLED(CONFIG_SPL_ATF_SUPPORT)) {
+   if (CONFIG_IS_ENABLED(ATF_SUPPORT)) {
debug("loaded - jumping to U-Boot via ATF BL31.\n");
bl31_entry();
}
diff --git a/include/linux/kconfig.h b/include/linux/kconfig.h
index 486fb94..fbfc718 100644
--- a/include/linux/kconfig.h
+++ b/include/linux/kconfig.h
@@ -51,12 +51,25 @@
 #define _IS_SPL 1
 #endif
 
+#ifdef CONFIG_TPL_BUILD
+#define _IS_TPL 1
+#endif
+
+#if defined(CONFIG_TPL_BUILD)
+#define config_val(cfg) _config_val(_IS_TPL, cfg)
+#define _config_val(x, cfg) __config_val(x, cfg)
+#define __config_val(x, cfg) ___config_val(__ARG_PLACEHOLDER_##x, cfg)
+#define ___config_val(arg1_or_junk, cfg)  \
+   config_val(arg1_or_junk CONFIG_TPL_##cfg, CONFIG_##cfg)
+#define config_val(__ignored, val, ...) val
+#else
 #define config_val(cfg) _config_val(_IS_SPL, cfg)
 #define _config_val(x, cfg) __config_val(x, cfg)
 #define __config_val(x, cfg) ___config_val(__ARG_PLACEHOLDER_##x, cfg)
 #define ___config_val(arg1_or_junk, cfg)  \
config_val(arg1_or_junk CONFIG_SPL_##cfg, CONFIG_##cfg)
 #define config_val(__ignored, val, ...) val
+#endif
 
 /*
  * CONFIG_VAL(FOO) evaluates to the value of
-- 
2.1.4

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

[U-Boot] [PATCH 33/52] rockchip: clk: rk3368: implement bandwidth adjust for PLLs

[Philipp Tomsich]

The RK3368 TRM recommends to configure the bandwith adjustment (CON2)
for PLLs to NF/2.  This implements this for all reconfigurations of
PLLs and removes the 'has_bwadj' flag (as the RK3368 always has the
bandwidth-adjustment feature according to its manual).

Signed-off-by: Philipp Tomsich 
---

 drivers/clk/rockchip/clk_rk3368.c | 17 -
 1 file changed, 12 insertions(+), 5 deletions(-)

diff --git a/drivers/clk/rockchip/clk_rk3368.c 
b/drivers/clk/rockchip/clk_rk3368.c
index e1d9aeb..d8f06d5 100644
--- a/drivers/clk/rockchip/clk_rk3368.c
+++ b/drivers/clk/rockchip/clk_rk3368.c
@@ -1,6 +1,7 @@
 /*
  * (C) Copyright 2017 Rockchip Electronics Co., Ltd
  * Author: Andy Yan 
+ * (C) Copyright 2017 Theobroma Systems Design und Consulting GmbH
  * SPDX-License-Identifier:GPL-2.0
  */
 
@@ -74,7 +75,7 @@ static uint32_t rkclk_pll_get_rate(struct rk3368_cru *cru,
 }
 
 static int rkclk_set_pll(struct rk3368_cru *cru, enum rk3368_pll_id pll_id,
-const struct pll_div *div, bool has_bwadj)
+const struct pll_div *div)
 {
struct rk3368_pll *pll = &cru->pll[pll_id];
/* All PLLs have same VCO and output frequency range restrictions*/
@@ -92,6 +93,12 @@ static int rkclk_set_pll(struct rk3368_cru *cru, enum 
rk3368_pll_id pll_id,
 ((div->nr - 1) << PLL_NR_SHIFT) |
 ((div->no - 1) << PLL_OD_SHIFT));
writel((div->nf - 1) << PLL_NF_SHIFT, &pll->con1);
+   /*
+* BWADJ should be set to NF / 2 to ensure the nominal bandwidth.
+* Compare the RK3368 TRM, section "3.6.4 PLL Bandwidth Adjustment".
+*/
+   clrsetbits_le32(&pll->con2, PLL_BWADJ_MASK, (div->nf >> 1) - 1);
+
udelay(10);
 
/* return from reset */
@@ -111,10 +118,10 @@ static void rkclk_init(struct rk3368_cru *cru)
 {
u32 apllb, aplll, dpll, cpll, gpll;
 
-   rkclk_set_pll(cru, APLLB, &apll_b_init_cfg, false);
-   rkclk_set_pll(cru, APLLL, &apll_l_init_cfg, false);
-   rkclk_set_pll(cru, GPLL, &gpll_init_cfg, false);
-   rkclk_set_pll(cru, CPLL, &cpll_init_cfg, false);
+   rkclk_set_pll(cru, APLLB, &apll_b_init_cfg);
+   rkclk_set_pll(cru, APLLL, &apll_l_init_cfg);
+   rkclk_set_pll(cru, GPLL, &gpll_init_cfg);
+   rkclk_set_pll(cru, CPLL, &cpll_init_cfg);
 
apllb = rkclk_pll_get_rate(cru, APLLB);
aplll = rkclk_pll_get_rate(cru, APLLL);
-- 
2.1.4

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

[U-Boot] [PATCH 44/52] rockchip: rk3368: add DRAM controller driver with DRAM initialisation

[Philipp Tomsich]

This adds a DRAM controller driver for the RK3368 and places it in
drivers/ddr/rockchip (where the other DM-enabled DRAM controller
drivers for rockchip devices should also be moved eventually).

At this stage, only the following feature-set is supported:
 - DDR3
 - 32-bit configuration (i.e. fully populated)
 - dual-rank (i.e. no auto-detection of ranks)
 - DDR3-1600K speed-bin

This driver expects to run from a TPL stage that will later return to
the RK3368 BROM.  It communicates with later stages through the
os_reg2 in the pmugrf (i.e. using the same mechanism as Rockchip's DDR
init code).

Unlike other DMC drivers for RK32xx and RK33xx parts, the required
timings are calculated within the driver based on a target frequency
and a DDR3 speed-bin (only the DDR3-1600K speed-bin is support at this
time).

The RK3368 also has the DDRC0_CON0 (DDR ch. 0, control-register 0)
register for controlling the operation of its (single-channel) DRAM
controller in the GRF block.  This provides for selecting DDR3, mobile
DDR modes, and control low-power operation.
As part of this change, DDRC0_CON0 is also added to the GRF structure
definition (at offset 0x600).

Signed-off-by: Philipp Tomsich 
---

 arch/arm/include/asm/arch-rockchip/ddr_rk3368.h| 187 
 arch/arm/include/asm/arch-rockchip/grf_rk3368.h|  13 +-
 arch/arm/mach-rockchip/rk3368/Makefile |   1 -
 arch/arm/mach-rockchip/rk3368/sdram_rk3368.c   |  60 --
 .../clock/rockchip,rk3368-dmc.txt  |  67 ++
 drivers/ram/Makefile   |   2 +
 drivers/ram/rockchip/Makefile  |   7 +
 drivers/ram/rockchip/dmc-rk3368.c  | 990 +
 include/dt-bindings/memory/rk3368-dmc.h|  30 +
 9 files changed, 1286 insertions(+), 71 deletions(-)
 create mode 100644 arch/arm/include/asm/arch-rockchip/ddr_rk3368.h
 delete mode 100644 arch/arm/mach-rockchip/rk3368/sdram_rk3368.c
 create mode 100644 doc/device-tree-bindings/clock/rockchip,rk3368-dmc.txt
 create mode 100644 drivers/ram/rockchip/Makefile
 create mode 100644 drivers/ram/rockchip/dmc-rk3368.c
 create mode 100644 include/dt-bindings/memory/rk3368-dmc.h

diff --git a/arch/arm/include/asm/arch-rockchip/ddr_rk3368.h 
b/arch/arm/include/asm/arch-rockchip/ddr_rk3368.h
new file mode 100644
index 000..4e2b233
--- /dev/null
+++ b/arch/arm/include/asm/arch-rockchip/ddr_rk3368.h
@@ -0,0 +1,187 @@
+/*
+ * (C) Copyright 2017 Theobroma Systems Design und Consulting GmbH
+ *
+ * SPDX-License-Identifier:GPL-2.0
+ */
+
+#ifndef __ASM_ARCH_DDR_RK3368_H__
+#define __ASM_ARCH_DDR_RK3368_H__
+
+/*
+ * The RK3368 DDR PCTL differs from the incarnation in the RK3288 only
+ * in a few details. Most notably, it has an additional field to track
+ * tREFI in controller cycles (i.e. trefi_mem_ddr3).
+ */
+struct rk3368_ddr_pctl {
+   u32 scfg;
+   u32 sctl;
+   u32 stat;
+   u32 intrstat;
+   u32 reserved0[12];
+   u32 mcmd;
+   u32 powctl;
+   u32 powstat;
+   u32 cmdtstat;
+   u32 cmdtstaten;
+   u32 reserved1[3];
+   u32 mrrcfg0;
+   u32 mrrstat0;
+   u32 mrrstat1;
+   u32 reserved2[4];
+   u32 mcfg1;
+   u32 mcfg;
+   u32 ppcfg;
+   u32 mstat;
+   u32 lpddr2zqcfg;
+   u32 reserved3;
+   u32 dtupdes;
+   u32 dtuna;
+   u32 dtune;
+   u32 dtuprd0;
+   u32 dtuprd1;
+   u32 dtuprd2;
+   u32 dtuprd3;
+   u32 dtuawdt;
+   u32 reserved4[3];
+   u32 togcnt1u;
+   u32 tinit;
+   u32 trsth;
+   u32 togcnt100n;
+   u32 trefi;
+   u32 tmrd;
+   u32 trfc;
+   u32 trp;
+   u32 trtw;
+   u32 tal;
+   u32 tcl;
+   u32 tcwl;
+   u32 tras;
+   u32 trc;
+   u32 trcd;
+   u32 trrd;
+   u32 trtp;
+   u32 twr;
+   u32 twtr;
+   u32 texsr;
+   u32 txp;
+   u32 txpdll;
+   u32 tzqcs;
+   u32 tzqcsi;
+   u32 tdqs;
+   u32 tcksre;
+   u32 tcksrx;
+   u32 tcke;
+   u32 tmod;
+   u32 trstl;
+   u32 tzqcl;
+   u32 tmrr;
+   u32 tckesr;
+   u32 tdpd;
+   u32 trefi_mem_ddr3;
+   u32 reserved5[45];
+   u32 dtuwactl;
+   u32 dturactl;
+   u32 dtucfg;
+   u32 dtuectl;
+   u32 dtuwd0;
+   u32 dtuwd1;
+   u32 dtuwd2;
+   u32 dtuwd3;
+   u32 dtuwdm;
+   u32 dturd0;
+   u32 dturd1;
+   u32 dturd2;
+   u32 dturd3;
+   u32 dtulfsrwd;
+   u32 dtulfsrrd;
+   u32 dtueaf;
+   u32 dfitctrldelay;
+   u32 dfiodtcfg;
+   u32 dfiodtcfg1;
+   u32 dfiodtrankmap;
+   u32 dfitphywrdata;
+   u32 dfitphywrlat;
+   u32 reserved7[2];
+   u32 dfitrddataen;
+   u32 dfitphyrdlat;
+   u32 reserved8[2];
+   u32 dfitphyupdtype0;
+   u32 dfitphyupdtype1;
+   u32 dfitphyupdtype2;
+   u32 dfitphyupdtype3;
+   u32 dfitctrlupdmin;
+   u32 dfitctrlupdmax;
+   u32 dfitctrlupddly;
+   u32 reser

[U-Boot] [PATCH 49/52] rockchip: rk3368: spl: mark SPL and TPL as supported for ROCKCHIP_RK3368

[Philipp Tomsich]

With SPL and TPL support for the RK3368 in place, mark SPL and TPL as
supported from Kconfig for the RK3368.  As this is primarily tested on
the RK3368-uQ7, we'll leave it to board's individual defconfig to
enable.

Also enable DEBUG_UART_BOARD_INIT for the RK3368, so we get output
during the early boot-up, as we turn on TPL and SPL.

Signed-off-by: Philipp Tomsich 
---

 arch/arm/mach-rockchip/Kconfig | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig
index 2ad4943..fd08897 100644
--- a/arch/arm/mach-rockchip/Kconfig
+++ b/arch/arm/mach-rockchip/Kconfig
@@ -67,6 +67,13 @@ config ROCKCHIP_RK3328
 config ROCKCHIP_RK3368
bool "Support Rockchip RK3368"
select ARM64
+   select SUPPORT_SPL
+   select SUPPORT_TPL
+   select SPL_SEPARATE_BSS
+   select SPL_SERIAL_SUPPORT
+   select TPL_SERIAL_SUPPORT
+   select ENABLE_ARM_SOC_BOOT0_HOOK
+   select DEBUG_UART_BOARD_INIT
select SYS_NS16550
help
  The Rockchip RK3368 is a ARM-based SoC with a octa-core (organised
-- 
2.1.4

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

[U-Boot] [PATCH 21/52] drivers: spl: consistently use the $(SPL_TPL_) macro

[Philipp Tomsich]

To simplify drivers/Makefile a bit when using TPL/SPL, we consistently
use the $(SPL_TPL_) macro to test for drivers that have separate
configuration symbols for the full U-boot, SPL and TPL stages.
Instead of explicitly repeating them in two separate if-guarded
sections of the Makefile, we can now simply list these options once.

Signed-off-by: Philipp Tomsich 
---

 drivers/Makefile | 36 
 1 file changed, 16 insertions(+), 20 deletions(-)

diff --git a/drivers/Makefile b/drivers/Makefile
index 058bccb..2bd769f 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -2,33 +2,34 @@
 # SPDX-License-Identifier: GPL-2.0+
 #
 
-obj-$(CONFIG_$(SPL_TPL_)DM)+= core/
-obj-$(CONFIG_$(SPL_)CLK)   += clk/
-obj-$(CONFIG_$(SPL_)LED)   += led/
-obj-$(CONFIG_$(SPL_)PHY)   += phy/
-obj-$(CONFIG_$(SPL_)PINCTRL)   += pinctrl/
-obj-$(CONFIG_$(SPL_)RAM)   += ram/
+obj-$(CONFIG_$(SPL_TPL_)CLK) += clk/
+obj-$(CONFIG_$(SPL_TPL_)DM) += core/
+obj-$(CONFIG_$(SPL_TPL_)DRIVERS_MISC_SUPPORT) += misc/ sysreset/ firmware/
+obj-$(CONFIG_$(SPL_TPL_)I2C_SUPPORT) += i2c/
+obj-$(CONFIG_$(SPL_TPL_)LED) += led/
+obj-$(CONFIG_$(SPL_TPL_)MMC_SUPPORT) += mmc/
+obj-$(CONFIG_$(SPL_TPL_)NAND_SUPPORT) += mtd/nand/
+obj-$(CONFIG_$(SPL_TPL_)PHY) += phy/
+obj-$(CONFIG_$(SPL_TPL_)PINCTRL) += pinctrl/
+obj-$(CONFIG_$(SPL_TPL_)RAM) += ram/
+obj-$(CONFIG_$(SPL_TPL_)SERIAL_SUPPORT) += serial/
+obj-$(CONFIG_$(SPL_TPL_)SPI_FLASH_SUPPORT) += mtd/spi/
+obj-$(CONFIG_$(SPL_TPL_)SPI_SUPPORT) += spi/
 
+ifndef CONFIG_TPL_BUILD
 ifdef CONFIG_SPL_BUILD
 
 obj-$(CONFIG_SPL_CPU_SUPPORT) += cpu/
 obj-$(CONFIG_SPL_CRYPTO_SUPPORT) += crypto/
-obj-$(CONFIG_SPL_I2C_SUPPORT) += i2c/
 obj-$(CONFIG_SPL_GPIO_SUPPORT) += gpio/
-obj-$(CONFIG_SPL_MMC_SUPPORT) += mmc/
 obj-$(CONFIG_SPL_MPC8XXX_INIT_DDR_SUPPORT) += ddr/fsl/
 obj-$(CONFIG_ARMADA_38X) += ddr/marvell/a38x/
 obj-$(CONFIG_ARMADA_XP) += ddr/marvell/axp/
 obj-$(CONFIG_ALTERA_SDRAM) += ddr/altera/
-obj-$(CONFIG_SPL_SERIAL_SUPPORT) += serial/
-obj-$(CONFIG_SPL_SPI_SUPPORT) += spi/
 obj-$(CONFIG_SPL_POWER_SUPPORT) += power/ power/pmic/
 obj-$(CONFIG_SPL_POWER_SUPPORT) += power/regulator/
-obj-$(CONFIG_SPL_DRIVERS_MISC_SUPPORT) += misc/ sysreset/ firmware/
 obj-$(CONFIG_SPL_MTD_SUPPORT) += mtd/
-obj-$(CONFIG_SPL_NAND_SUPPORT) += mtd/nand/
 obj-$(CONFIG_SPL_ONENAND_SUPPORT) += mtd/onenand/
-obj-$(CONFIG_SPL_SPI_FLASH_SUPPORT) += mtd/spi/
 obj-$(CONFIG_SPL_UBI) += mtd/ubispl/
 obj-$(CONFIG_SPL_DMA_SUPPORT) += dma/
 obj-$(CONFIG_SPL_ETH_SUPPORT) += net/
@@ -48,18 +49,13 @@ obj-$(CONFIG_OMAP_USB_PHY) += usb/phy/
 obj-$(CONFIG_SPL_SATA_SUPPORT) += block/
 obj-$(CONFIG_SPL_USB_HOST_SUPPORT) += block/
 obj-$(CONFIG_SPL_MMC_SUPPORT) += block/
+
+endif
 endif
 
 ifdef CONFIG_TPL_BUILD
 
-obj-$(CONFIG_TPL_I2C_SUPPORT) += i2c/
-obj-$(CONFIG_TPL_DRIVERS_MISC_SUPPORT) += misc/ sysreset/ firmware/
-obj-$(CONFIG_TPL_MMC_SUPPORT) += mmc/
 obj-$(CONFIG_TPL_MPC8XXX_INIT_DDR_SUPPORT) += ddr/fsl/
-obj-$(CONFIG_TPL_NAND_SUPPORT) += mtd/nand/
-obj-$(CONFIG_TPL_SERIAL_SUPPORT) += serial/
-obj-$(CONFIG_TPL_SPI_FLASH_SUPPORT) += mtd/spi/
-obj-$(CONFIG_TPL_SPI_SUPPORT) += spi/
 
 endif
 
-- 
2.1.4

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

[U-Boot] [PATCH 26/52] rockchip: rk3368: define CONFIG_SYS_SDRAM_BASE

[Philipp Tomsich]

With the new common SDRAM code for Rockchip, we need to define
CONFIG_SYS_SDRAM_BASE to correctly indicate the start of the physical
address range mapping onto DRAM.

Signed-off-by: Philipp Tomsich 
---

 include/configs/rk3368_common.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/configs/rk3368_common.h b/include/configs/rk3368_common.h
index b0c858c..488f8c5 100644
--- a/include/configs/rk3368_common.h
+++ b/include/configs/rk3368_common.h
@@ -15,6 +15,7 @@
 #define CONFIG_SYS_SDRAM_BASE  0
 #define SDRAM_MAX_SIZE 0xff00
 #define CONFIG_NR_DRAM_BANKS   1
+#define CONFIG_SYS_SDRAM_BASE  0
 #define CONFIG_SYS_MAXARGS 16
 #define CONFIG_BAUDRATE115200
 #define CONFIG_SYS_MALLOC_LEN  (32 << 20)
-- 
2.1.4

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

[U-Boot] [PATCH 23/52] rockchip: rk3368: improve Kconfig text for the RK3368

[Philipp Tomsich]

The RK3368 option in Kconfig referred to the RK3328 (copy-and-paste)
and had a few typos and unnecessarily used UTF-8 characters.  While
fixing this, I also reformatted and further clarified the text
(e.g. made the grouping into a a big and little cluster of 4 cores
each explicit).

Signed-off-by: Philipp Tomsich 
---

 arch/arm/mach-rockchip/Kconfig | 15 +--
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig
index 523bc11..2ad4943 100644
--- a/arch/arm/mach-rockchip/Kconfig
+++ b/arch/arm/mach-rockchip/Kconfig
@@ -69,12 +69,15 @@ config ROCKCHIP_RK3368
select ARM64
select SYS_NS16550
help
- The Rockchip RK3328 is a ARM-based SoC with a octa-core Cortex-A53.
- including NEON and GPU, 512KB L2 cache for big cluster and 256 KB
- L2 cache for little cluser, PowerVR G6110 based graphics, one video
- output processor supporting LVDS、HDMI、eDP, several DDR3 options
- and video codec support. Peripherals include Gigabit Ethernet,
- USB2 host and OTG, SDIO, I2S, UARTs, SPI, I2C and PWMs.
+ The Rockchip RK3368 is a ARM-based SoC with a octa-core (organised
+ into a big and little cluster with 4 cores each) Cortex-A53 including
+ AdvSIMD, 512KB L2 cache (for the big cluster) and 256 KB L2 cache
+ (for the little cluster), PowerVR G6110 based graphics, one video
+ output processor supporting LVDS/HDMI/eDP, several DDR3 options and
+ video codec support.
+
+ On-chip peripherals include Gigabit Ethernet, USB2 host and OTG, SDIO,
+ I2S, UARTs, SPI, I2C and PWMs.
 
 config ROCKCHIP_RK3399
bool "Support Rockchip RK3399"
-- 
2.1.4

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

[U-Boot] [PATCH 51/52] rockchip: board: puma-rk3399: fix warnings in puma_rk3399/fit_spl_atf.its

[Philipp Tomsich]

The ITS file generated warnings due to @ designations in the naming
which cause DTC to complain as follows:
  Warning (unit_address_vs_reg): Node /images/uboot@1 has a unit name, but no 
reg property
  Warning (unit_address_vs_reg): Node /images/atf@1 has a unit name, but no reg 
property
  Warning (unit_address_vs_reg): Node /images/pmu@1 has a unit name, but no reg 
property
  Warning (unit_address_vs_reg): Node /images/fdt@1 has a unit name, but no reg 
property
  Warning (unit_address_vs_reg): Node /configurations/conf@1 has a unit name, 
but no reg property

This removes the @ part from the names, as we only have a single
image for each payload aspect (and only a single configuration) anyway.

Signed-off-by: Philipp Tomsich 
---

 board/theobroma-systems/puma_rk3399/fit_spl_atf.its | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/board/theobroma-systems/puma_rk3399/fit_spl_atf.its 
b/board/theobroma-systems/puma_rk3399/fit_spl_atf.its
index f93c251..0519fad 100644
--- a/board/theobroma-systems/puma_rk3399/fit_spl_atf.its
+++ b/board/theobroma-systems/puma_rk3399/fit_spl_atf.its
@@ -13,7 +13,7 @@
#address-cells = <1>;
 
images {
-   uboot@1 {
+   uboot {
description = "U-Boot (64-bit)";
data = /incbin/("../../../u-boot-nodtb.bin");
type = "standalone";
@@ -21,7 +21,7 @@
compression = "none";
load = <0x0020>;
};
-   atf@1 {
+   atf {
description = "ARM Trusted Firmware";
data = /incbin/("../../../bl31.bin");
type = "firmware";
@@ -30,14 +30,14 @@
load = <0x1000>;
entry = <0x1000>;
};
-   pmu@1 {
+   pmu {
description = "Cortex-M0 firmware";
data = /incbin/("../../../rk3399m0.bin");
type = "pmu-firmware";
compression = "none";
load = <0xff8c>;
 };
-   fdt@1 {
+   fdt {
description = "RK3399-Q7 (Puma) flat device-tree";
data = /incbin/("../../../u-boot.dtb");
type = "flat_dt";
@@ -46,12 +46,12 @@
};
 
configurations {
-   default = "conf@1";
-   conf@1 {
+   default = "conf";
+   conf {
description = "Theobroma Systems RK3399-Q7 (Puma) SoM";
-   firmware = "uboot@1";
-   loadables = "atf@1";
-   fdt = "fdt@1";
+   firmware = "uboot";
+   loadables = "atf";
+   fdt = "fdt";
};
};
 };
-- 
2.1.4

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

[U-Boot] [PATCH 28/52] rockchip: rk3368: spl: add memory layout for TPL and SPL

[Philipp Tomsich]

For the RK3368, we use a multi-stage boot-process consisting of the
following:
  1.  TPL: initalises DRAM, returns to boot-ROM (which then loads
   the next stage and transfers control to it)
  2.  SPL: a full-features SPL stage including OF_CONTROL and FIT
   image loading, which fetches the ATF, DTB and full U-Boot
   and then transfers control to the ATF (using the BL31
   parameter block to indicate the location of BL33/U-Boot)
  3.  ATF: sets up the secure world and exits to BL33 (i.e. a full
   U-Boot) in the normal world
  4.  full U-Boot

TPL/SPL and the full U-Boot are built from this tree and need to
run from distinct text addresses and with distinct initial stack
pointer addresses.

This commit sets up the configuration to run:
  -  TPL from the SRAM at 0xff8c (note that the first 0x1000
 are reserved for use by the boot-ROM and contain the SP
 when the TPL is entered)
  -  SPL from DRAM at 0x0
  -  U-Boot from DRAM at 0x20

Signed-off-by: Philipp Tomsich 
---

 include/configs/rk3368_common.h | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/include/configs/rk3368_common.h b/include/configs/rk3368_common.h
index 7ab3b46..8ffc293 100644
--- a/include/configs/rk3368_common.h
+++ b/include/configs/rk3368_common.h
@@ -30,6 +30,17 @@
 #define CONFIG_SYS_INIT_SP_ADDR0x0030
 #define CONFIG_SYS_LOAD_ADDR   0x0028
 
+#define CONFIG_SPL_TEXT_BASE0x
+#define CONFIG_SPL_MAX_SIZE 0x4
+#define CONFIG_SPL_BSS_START_ADDR   0x40
+#define CONFIG_SPL_BSS_MAX_SIZE 0x2
+
+#define CONFIG_TPL_LDSCRIPT \
+ "arch/arm/mach-rockchip/rk3368/u-boot-tpl.lds"
+#define CONFIG_TPL_TEXT_BASE   0xff8c1000
+#define CONFIG_TPL_MAX_SIZE0x7000
+#define CONFIG_TPL_STACK   0xff8c
+
 #define CONFIG_BOUNCE_BUFFER
 
 #ifndef CONFIG_SPL_BUILD
-- 
2.1.4

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

[U-Boot] [PATCH 22/52] rockchip: Makefile: allow selective inclusion of sdram_common.o from TPL/SPL/U-Boot

[Philipp Tomsich]

The utility functions in sdram_common.c will be useful both for some
SPL implementations (and if unused, the linked will discard these
anyway) and for the full U-Boot stage.

This changes selects sdram_common.o through the $(SPL_TPL_) macro to
allow better control of its inclusion through the CONFIG_ROM,
CONFIG_SPL_RAM or CONFIG_TPL_RAM options.

Signed-off-by: Philipp Tomsich 
---

 arch/arm/mach-rockchip/Makefile | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/arch/arm/mach-rockchip/Makefile b/arch/arm/mach-rockchip/Makefile
index cb8d3ef..8a3cb9f 100644
--- a/arch/arm/mach-rockchip/Makefile
+++ b/arch/arm/mach-rockchip/Makefile
@@ -5,6 +5,7 @@
 #
 
 obj-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
+obj-$(CONFIG_$(SPL_TPL_)RAM) += sdram_common.o
 
 ifdef CONFIG_TPL_BUILD
 obj-$(CONFIG_ROCKCHIP_RK3188) += rk3188-board-tpl.o
@@ -21,9 +22,6 @@ obj-$(CONFIG_ROCKCHIP_RK3188) += rk3188-board.o
 obj-$(CONFIG_ROCKCHIP_RK322X) += rk322x-board.o
 obj-$(CONFIG_ROCKCHIP_RK3288) += rk3288-board.o
 obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036-board.o
-ifdef CONFIG_RAM
-obj-y += sdram_common.o
-endif
 endif
 ifndef CONFIG_ARM64
 obj-y += rk_timer.o
-- 
2.1.4

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

[U-Boot] [PATCH 10/52] spl: dm: Kconfig: SPL_CLK depens on SPL_DM

[Philipp Tomsich]

SPL_CLK should also depend on SPL_DM (and not just on CLK).
Add the additional dependency.

Signed-off-by: Philipp Tomsich 
---

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

diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 44da716..9c13587 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -12,7 +12,7 @@ config CLK
 
 config SPL_CLK
bool "Enable clock support in SPL"
-   depends on CLK
+   depends on CLK && SPL_DM
help
  The clock subsystem adds a small amount of overhead to the image.
  If this is acceptable and you have a need to use clock drivers in
-- 
2.1.4

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

[U-Boot] [PATCH 43/52] rockchip: Makefile: streamline SPL/TPL configuration

[Philipp Tomsich]

Handling TPL and SPL in the Makefile for mach-rockchip was based on
nested if checks and/or if-else-if paths.  This can be simplified and
made more readable by using $(SPL_TPL_) and by introducing
intermediate variables for the aggregation of SPL and TPL features.

Signed-off-by: Philipp Tomsich 
---

 arch/arm/mach-rockchip/Makefile | 46 +
 1 file changed, 28 insertions(+), 18 deletions(-)

diff --git a/arch/arm/mach-rockchip/Makefile b/arch/arm/mach-rockchip/Makefile
index 8a3cb9f..633c91e 100644
--- a/arch/arm/mach-rockchip/Makefile
+++ b/arch/arm/mach-rockchip/Makefile
@@ -4,37 +4,47 @@
 # SPDX-License-Identifier: GPL-2.0+
 #
 
-obj-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
-obj-$(CONFIG_$(SPL_TPL_)RAM) += sdram_common.o
+# We don't want the bootrom-helper present in a full U-Boot build, as
+# this may have entered from ATF with the stack-pointer pointing to
+# inaccessible/protected memory (and the bootrom-helper assumes that
+# the stack-pointer is valid before switching to the U-Boot stack).
+obj-spl-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o save_boot_param.o
+obj-tpl-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o save_boot_param.o
+
+obj-tpl-$(CONFIG_ROCKCHIP_RK3188) += rk3188-board-tpl.o
+
+obj-spl-$(CONFIG_ROCKCHIP_RK3036) += rk3036-board-spl.o
+obj-spl-$(CONFIG_ROCKCHIP_RK3188) += rk3188-board-spl.o
+obj-spl-$(CONFIG_ROCKCHIP_RK322X) += rk322x-board-spl.o
+obj-spl-$(CONFIG_ROCKCHIP_RK3288) += rk3288-board-spl.o
+obj-spl-$(CONFIG_ROCKCHIP_RK3368) += rk3368-board-spl.o
+obj-spl-$(CONFIG_ROCKCHIP_RK3399) += rk3399-board-spl.o
 
-ifdef CONFIG_TPL_BUILD
-obj-$(CONFIG_ROCKCHIP_RK3188) += rk3188-board-tpl.o
-obj-$(CONFIG_ROCKCHIP_BROM_HELPER) += save_boot_param.o
-else ifdef CONFIG_SPL_BUILD
-obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036-board-spl.o
-obj-$(CONFIG_ROCKCHIP_RK3188) += rk3188-board-spl.o
-obj-$(CONFIG_ROCKCHIP_RK322X) += rk322x-board-spl.o
-obj-$(CONFIG_ROCKCHIP_RK3288) += rk3288-board-spl.o
-obj-$(CONFIG_ROCKCHIP_RK3399) += rk3399-board-spl.o
-obj-$(CONFIG_ROCKCHIP_BROM_HELPER) += save_boot_param.o
-else
+ifeq ($(CONFIG_SPL_BUILD)$(CONFIG_TPL_BUILD),)
 obj-$(CONFIG_ROCKCHIP_RK3188) += rk3188-board.o
 obj-$(CONFIG_ROCKCHIP_RK322X) += rk322x-board.o
 obj-$(CONFIG_ROCKCHIP_RK3288) += rk3288-board.o
 obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036-board.o
 endif
+
+obj-$(CONFIG_$(SPL_TPL_)RAM) += sdram_common.o
+
 ifndef CONFIG_ARM64
 obj-y += rk_timer.o
 endif
-obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036/
-
-ifndef CONFIG_TPL_BUILD
-obj-$(CONFIG_ROCKCHIP_RK3188) += rk3188/
-endif
 
+obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036/
+obj-tpl-$(CONFIG_ROCKCHIP_RK3188) += rk3188/
 obj-$(CONFIG_ROCKCHIP_RK322X) += rk322x/
 obj-$(CONFIG_ROCKCHIP_RK3288) += rk3288/
 obj-$(CONFIG_ROCKCHIP_RK3328) += rk3328/
 obj-$(CONFIG_ROCKCHIP_RK3368) += rk3368/
 obj-$(CONFIG_ROCKCHIP_RK3399) += rk3399/
 obj-$(CONFIG_ROCKCHIP_RV1108) += rv1108/
+
+# Clear out SPL objects, in case this is a TPL build
+obj-spl-$(CONFIG_TPL_BUILD) =
+
+# Now add SPL/TPL objects back into the main build
+obj-$(CONFIG_SPL_BUILD) += $(obj-spl-y)
+obj-$(CONFIG_TPL_BUILD) += $(obj-tpl-y)
-- 
2.1.4

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

[U-Boot] [PATCH 36/52] rockchip: clk: rk3368: implement DPLL (DRAM PLL) support

[Philipp Tomsich]

To implement a TPL stage (incl. its DRAM controller setup) for the
RK3368, we'll want to configure the DPLL (DRAM PLL).

This commit implements setting the DPLL (CLK_DDR) and provides PLL
configuration details for the common DRAM operating speeds found on
RK3368 boards.

Signed-off-by: Philipp Tomsich 
---

 drivers/clk/rockchip/clk_rk3368.c | 35 +++
 1 file changed, 35 insertions(+)

diff --git a/drivers/clk/rockchip/clk_rk3368.c 
b/drivers/clk/rockchip/clk_rk3368.c
index d05be72..33d2946 100644
--- a/drivers/clk/rockchip/clk_rk3368.c
+++ b/drivers/clk/rockchip/clk_rk3368.c
@@ -250,6 +250,37 @@ static ulong rk3368_clk_get_rate(struct clk *clk)
return rate;
 }
 
+static ulong rk3368_ddr_set_clk(struct rk3368_cru *cru, ulong set_rate)
+{
+   const struct pll_div *dpll_cfg = NULL;
+   const ulong MHz = 100;
+
+   /* Fout = ((Fin /NR) * NF )/ NO */
+   static const struct pll_div dpll_1200 =
+   PLL_DIVISORS(1200 * MHz, 1, 1);
+   static const struct pll_div dpll_1332 =
+   PLL_DIVISORS(1332 * MHz, 2, 1);
+   static const struct pll_div dpll_1600 =
+   PLL_DIVISORS(1600 * MHz, 3, 2);
+
+   switch (set_rate) {
+   case 1200*MHz:
+   dpll_cfg = &dpll_1200;
+   break;
+   case 1332*MHz:
+   dpll_cfg = &dpll_1332;
+   break;
+   case 1600*MHz:
+   dpll_cfg = &dpll_1600;
+   break;
+   default:
+   error("Unsupported SDRAM frequency!,%ld\n", set_rate);
+   }
+   rkclk_set_pll(cru, DPLL, dpll_cfg);
+
+   return set_rate;
+}
+
 static ulong rk3368_clk_set_rate(struct clk *clk, ulong rate)
 {
struct rk3368_clk_priv *priv = dev_get_priv(clk->dev);
@@ -257,6 +288,10 @@ static ulong rk3368_clk_set_rate(struct clk *clk, ulong 
rate)
 
debug("%s id:%ld rate:%ld\n", __func__, clk->id, rate);
switch (clk->id) {
+   case CLK_DDR:
+   ret = rk3368_ddr_set_clk(priv->cru, rate);
+   break;
+
case SCLK_SDMMC:
case SCLK_EMMC:
ret = rk3368_mmc_set_clk(priv->cru, clk->id, rate);
-- 
2.1.4

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

[U-Boot] [PATCH 29/52] rockchip: rk3368: syscon: MSCH/PMUGRF/GRF support for OF_PLATDATA

[Philipp Tomsich]

The RK3368 has both a limited SPL size (just 0x7000 bytes) and the
added challenge of booting in AArch64, which increases the code size
for SPL (particularily when using the LP64 programming model).  For
this reason we expect the RK3368 to always use OF_PLATDATA for its
SPL stage.

This change adds support for the MSCH, PMUGRF and GRF register regions
in syscon, which are necessary for initialising the RK3368's DRAM
controller.

Signed-off-by: Philipp Tomsich 
---

 arch/arm/mach-rockchip/rk3368/syscon_rk3368.c | 35 +++
 1 file changed, 35 insertions(+)

diff --git a/arch/arm/mach-rockchip/rk3368/syscon_rk3368.c 
b/arch/arm/mach-rockchip/rk3368/syscon_rk3368.c
index 03e97eb..90a993e 100644
--- a/arch/arm/mach-rockchip/rk3368/syscon_rk3368.c
+++ b/arch/arm/mach-rockchip/rk3368/syscon_rk3368.c
@@ -1,6 +1,8 @@
 /*
  * (C) Copyright 2017 Rockchip Electronics Co., Ltd
  * Author: Andy Yan 
+ * (C) Copyright 2017 Theobroma Systems Design und Consulting GmbH
+ *
  * SPDX-License-Identifier:GPL-2.0+
  */
 
@@ -14,6 +16,8 @@ static const struct udevice_id rk3368_syscon_ids[] = {
  .data = ROCKCHIP_SYSCON_GRF },
{ .compatible = "rockchip,rk3368-pmugrf",
  .data = ROCKCHIP_SYSCON_PMUGRF },
+   { .compatible = "rockchip,rk3368-msch",
+ .data = ROCKCHIP_SYSCON_MSCH },
{ }
 };
 
@@ -22,3 +26,34 @@ U_BOOT_DRIVER(syscon_rk3368) = {
.id = UCLASS_SYSCON,
.of_match = rk3368_syscon_ids,
 };
+
+#if CONFIG_IS_ENABLED(OF_PLATDATA)
+static int rk3368_syscon_bind_of_platdata(struct udevice *dev)
+{
+   dev->driver_data = dev->driver->of_match->data;
+   debug("syscon: %s %d\n", dev->name, (uint)dev->driver_data);
+
+   return 0;
+}
+
+U_BOOT_DRIVER(rockchip_rk3368_grf) = {
+   .name = "rockchip_rk3368_grf",
+   .id = UCLASS_SYSCON,
+   .of_match = rk3368_syscon_ids,
+   .bind = rk3368_syscon_bind_of_platdata,
+};
+
+U_BOOT_DRIVER(rockchip_rk3368_pmugrf) = {
+   .name = "rockchip_rk3368_pmugrf",
+   .id = UCLASS_SYSCON,
+   .of_match = rk3368_syscon_ids + 1,
+   .bind = rk3368_syscon_bind_of_platdata,
+};
+
+U_BOOT_DRIVER(rockchip_rk3368_msch) = {
+   .name = "rockchip_rk3368_msch",
+   .id = UCLASS_SYSCON,
+   .of_match = rk3368_syscon_ids + 2,
+   .bind = rk3368_syscon_bind_of_platdata,
+};
+#endif
-- 
2.1.4

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

[U-Boot] [PATCH 25/52] rockchip: rk3368: pmugrf: add definitions for os_reg[0..3]

[Philipp Tomsich]

On the RK3368 we use a TPL-stage similar to Rockchip's DDR init
(i.e. it initialises DRAM, leaves some info for the next stage and
returns to the BootROM).  To allow compatibility with Rockchip's DDR
init code, we use the same register os_reg2 in pmugrf for passing
this info (i.e. DRAM size and configuration) between stages.

This change adds the definitions for os_reg[0] through os_reg[3] to
the pmugrf structure for the RK3368.

Signed-off-by: Philipp Tomsich 
---

 arch/arm/include/asm/arch-rockchip/grf_rk3368.h | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/arm/include/asm/arch-rockchip/grf_rk3368.h 
b/arch/arm/include/asm/arch-rockchip/grf_rk3368.h
index 93c4e7d..a438f5d 100644
--- a/arch/arm/include/asm/arch-rockchip/grf_rk3368.h
+++ b/arch/arm/include/asm/arch-rockchip/grf_rk3368.h
@@ -92,10 +92,11 @@ struct rk3368_pmu_grf {
u32 gpio0d_drv;
u32 gpio0l_sr;
u32 gpio0h_sr;
-   u32 reserved[(0x200 - 0x34) / 4 - 1];
+   u32 reserved[0x72];
u32 os_reg[4];
 };
-check_member(rk3368_pmu_grf, os_reg[3], 0x20c);
+check_member(rk3368_pmu_grf, gpio0h_sr, 0x34);
+check_member(rk3368_pmu_grf, os_reg[0], 0x200);
 
 /*GRF_GPIO0C_IOMUX*/
 enum {
-- 
2.1.4

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

[U-Boot] [PATCH 38/52] rockchip: clk: rk3368: implement MMC/SD clock reparenting

[Philipp Tomsich]

The original clock support for MMC/SD cards on the RK3368 suffered
from a tendency to select a divider less-or-equal to the the one
giving the requested clock-rate: this can lead to higher-than-expected
(or rather: higher than supported) clock rates for the MMC/SD
communiction.

This change rewrites the MMC/SD clock generation to:
 * always generate a clock less-than-or-equal to the requested clock
 * support reparenting among the CPLL, GPLL and OSC24M parents to
   generate the highest clock that does not exceed the requested rate

In addition to this, the Linux DTS uses HCLK_MMC/HCLK_SDMMC instead of
SCLK_MMC/SCLK_SDMMC: to match this (and to ensure that clock setup
always works), we adjust the driver appropriately.

This includes the changes from:
 - rockchip: clk: rk3368: convert MMC_PLL_SEL_* definitions to shifted-value 
form

Signed-off-by: Philipp Tomsich 
---

 arch/arm/include/asm/arch-rockchip/cru_rk3368.h |   8 +-
 drivers/clk/rockchip/clk_rk3368.c   | 119 ++--
 2 files changed, 95 insertions(+), 32 deletions(-)

diff --git a/arch/arm/include/asm/arch-rockchip/cru_rk3368.h 
b/arch/arm/include/asm/arch-rockchip/cru_rk3368.h
index bf09e2f..21f11e0 100644
--- a/arch/arm/include/asm/arch-rockchip/cru_rk3368.h
+++ b/arch/arm/include/asm/arch-rockchip/cru_rk3368.h
@@ -92,10 +92,10 @@ enum {
/* CLKSEL51_CON */
MMC_PLL_SEL_SHIFT   = 8,
MMC_PLL_SEL_MASK= GENMASK(9, 8),
-   MMC_PLL_SEL_CPLL= 0,
-   MMC_PLL_SEL_GPLL,
-   MMC_PLL_SEL_USBPHY_480M,
-   MMC_PLL_SEL_24M,
+   MMC_PLL_SEL_CPLL= (0 << MMC_PLL_SEL_SHIFT),
+   MMC_PLL_SEL_GPLL= (1 << MMC_PLL_SEL_SHIFT),
+   MMC_PLL_SEL_USBPHY_480M = (2 << MMC_PLL_SEL_SHIFT),
+   MMC_PLL_SEL_24M = (3 << MMC_PLL_SEL_SHIFT),
MMC_CLK_DIV_SHIFT   = 0,
MMC_CLK_DIV_MASK= GENMASK(6, 0),
 
diff --git a/drivers/clk/rockchip/clk_rk3368.c 
b/drivers/clk/rockchip/clk_rk3368.c
index 33d2946..1327116 100644
--- a/drivers/clk/rockchip/clk_rk3368.c
+++ b/drivers/clk/rockchip/clk_rk3368.c
@@ -59,6 +59,8 @@ static const struct pll_div cpll_init_cfg = 
PLL_DIVISORS(CPLL_HZ, 1, 6);
 #endif
 #endif
 
+static ulong rk3368_clk_get_rate(struct clk *clk);
+
 /* Get pll rate by id */
 static uint32_t rkclk_pll_get_rate(struct rk3368_cru *cru,
   enum rk3368_pll_id pll_id)
@@ -155,16 +157,17 @@ static void rkclk_init(struct rk3368_cru *cru)
 }
 #endif
 
+#if !IS_ENABLED(CONFIG_SPL_BUILD) || CONFIG_IS_ENABLED(MMC_SUPPORT)
 static ulong rk3368_mmc_get_clk(struct rk3368_cru *cru, uint clk_id)
 {
u32 div, con, con_id, rate;
u32 pll_rate;
 
switch (clk_id) {
-   case SCLK_SDMMC:
+   case HCLK_SDMMC:
con_id = 50;
break;
-   case SCLK_EMMC:
+   case HCLK_EMMC:
con_id = 51;
break;
case SCLK_SDIO0:
@@ -175,7 +178,7 @@ static ulong rk3368_mmc_get_clk(struct rk3368_cru *cru, 
uint clk_id)
}
 
con = readl(&cru->clksel_con[con_id]);
-   switch ((con & MMC_PLL_SEL_MASK) >> MMC_PLL_SEL_SHIFT) {
+   switch (con & MMC_PLL_SEL_MASK) {
case MMC_PLL_SEL_GPLL:
pll_rate = rkclk_pll_get_rate(cru, GPLL);
break;
@@ -183,6 +186,8 @@ static ulong rk3368_mmc_get_clk(struct rk3368_cru *cru, 
uint clk_id)
pll_rate = OSC_HZ;
break;
case MMC_PLL_SEL_CPLL:
+   pll_rate = rkclk_pll_get_rate(cru, CPLL);
+   break;
case MMC_PLL_SEL_USBPHY_480M:
default:
return -EINVAL;
@@ -190,23 +195,76 @@ static ulong rk3368_mmc_get_clk(struct rk3368_cru *cru, 
uint clk_id)
div = (con & MMC_CLK_DIV_MASK) >> MMC_CLK_DIV_SHIFT;
rate = DIV_TO_RATE(pll_rate, div);
 
+   debug("%s: raw rate %d (post-divide by 2)\n", __func__, rate);
return rate >> 1;
 }
 
-static ulong rk3368_mmc_set_clk(struct rk3368_cru *cru,
-   ulong clk_id, ulong rate)
+static ulong rk3368_mmc_find_best_rate_and_parent(struct clk *clk,
+ ulong rate,
+ u32 *best_mux,
+ u32 *best_div)
+{
+   int i;
+   ulong best_rate = 0;
+   const ulong MHz = 100;
+   const struct {
+   u32 mux;
+   ulong rate;
+   } parents[] = {
+   { .mux = MMC_PLL_SEL_CPLL, .rate = CPLL_HZ },
+   { .mux = MMC_PLL_SEL_GPLL, .rate = GPLL_HZ },
+   { .mux = MMC_PLL_SEL_24M,  .rate = 24 * MHz }
+   };
+
+   debug("%s: target rate %ld\n", __func__, rate);
+   for (i = 0; i < ARRAY_SIZE(parents); ++i) {
+   /*
+* Find the largest rate no larger than the target-rate fo

[U-Boot] [PATCH 17/52] spl: Kconfig: split SYS_MALLOC_SIMPLE for TPL and SPL

[Philipp Tomsich]

As include/malloc.h already checks for SYS_MALLOC_SIMPLE using the
CONFIG_IS_ENABLED macro, we need to move to having separate entries
as we switch to fully separate configuration for SPL and TPL.

Signed-off-by: Philipp Tomsich 
---

 common/spl/Kconfig | 9 +
 1 file changed, 9 insertions(+)

diff --git a/common/spl/Kconfig b/common/spl/Kconfig
index dd94801..f49b958 100644
--- a/common/spl/Kconfig
+++ b/common/spl/Kconfig
@@ -62,6 +62,15 @@ config SPL_SYS_MALLOC_SIMPLE
  this will make the SPL binary smaller at the cost of more heap
  usage as the *_simple malloc functions do not re-use free-ed mem.
 
+config TPL_SYS_MALLOC_SIMPLE
+   bool
+   prompt "Only use malloc_simple functions in the TPL"
+   help
+ Say Y here to only use the *_simple malloc functions from
+ malloc_simple.c, rather then using the versions from dlmalloc.c;
+ this will make the TPL binary smaller at the cost of more heap
+ usage as the *_simple malloc functions do not re-use free-ed mem.
+
 config SPL_STACK_R
bool "Enable SDRAM location for SPL stack"
help
-- 
2.1.4

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

[U-Boot] [PATCH 52/52] rockchip: board: puma_rk3399: rename ATF firmware

[Philipp Tomsich]

From: Klaus Goger 

Prefix the bl31 firmware needed to build uboot.itb so it can coexist in
the build area with ATFs from other boards (i.e. lion_rk3368).

Signed-off-by: Klaus Goger 
Signed-off-by: Philipp Tomsich 
---

 board/theobroma-systems/puma_rk3399/README  | 2 +-
 board/theobroma-systems/puma_rk3399/fit_spl_atf.its | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/board/theobroma-systems/puma_rk3399/README 
b/board/theobroma-systems/puma_rk3399/README
index 250e345..214281a 100644
--- a/board/theobroma-systems/puma_rk3399/README
+++ b/board/theobroma-systems/puma_rk3399/README
@@ -37,7 +37,7 @@ Compile the ATF
 
   > cd arm-trusted-firmware
   > make CROSS_COMPILE=aarch64-linux-gnu- PLAT=rk3399 bl31
-  > cp build/rk3399/release/bl31.bin ../u-boot
+  > cp build/rk3399/release/bl31.bin ../u-boot/bl31-rk3399.bin
 
 Compile the M0 firmware
 ===
diff --git a/board/theobroma-systems/puma_rk3399/fit_spl_atf.its 
b/board/theobroma-systems/puma_rk3399/fit_spl_atf.its
index 0519fad..520f846 100644
--- a/board/theobroma-systems/puma_rk3399/fit_spl_atf.its
+++ b/board/theobroma-systems/puma_rk3399/fit_spl_atf.its
@@ -23,7 +23,7 @@
};
atf {
description = "ARM Trusted Firmware";
-   data = /incbin/("../../../bl31.bin");
+   data = /incbin/("../../../bl31-rk3399.bin");
type = "firmware";
arch = "arm64";
compression = "none";
-- 
2.1.4

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

[U-Boot] [PATCH 34/52] rockchip: clk: rk3368: support OF_PLATDATA for the RK3368 clk driver

[Philipp Tomsich]

With the RK3368's limited TPL size, we'll want to use OF_PLATFDATA for
the SPL stage.  This implements support for OF_PLATDATA in the clock
driver for the RK3368.

Signed-off-by: Philipp Tomsich 
---

 drivers/clk/rockchip/clk_rk3368.c | 17 +
 1 file changed, 17 insertions(+)

diff --git a/drivers/clk/rockchip/clk_rk3368.c 
b/drivers/clk/rockchip/clk_rk3368.c
index d8f06d5..809ad19 100644
--- a/drivers/clk/rockchip/clk_rk3368.c
+++ b/drivers/clk/rockchip/clk_rk3368.c
@@ -8,7 +8,9 @@
 #include 
 #include 
 #include 
+#include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -19,6 +21,12 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
+#if CONFIG_IS_ENABLED(OF_PLATDATA)
+struct rk3368_clk_plat {
+   struct dtd_rockchip_rk3368_cru dtd;
+};
+#endif
+
 struct pll_div {
u32 nr;
u32 nf;
@@ -254,7 +262,11 @@ static struct clk_ops rk3368_clk_ops = {
 static int rk3368_clk_probe(struct udevice *dev)
 {
struct rk3368_clk_priv *priv = dev_get_priv(dev);
+#if CONFIG_IS_ENABLED(OF_PLATDATA)
+   struct rk3368_clk_plat *plat = dev_get_platdata(dev);
 
+   priv->cru = map_sysmem(plat->dtd.reg[1], plat->dtd.reg[3]);
+#endif
rkclk_init(priv->cru);
 
return 0;
@@ -262,9 +274,11 @@ static int rk3368_clk_probe(struct udevice *dev)
 
 static int rk3368_clk_ofdata_to_platdata(struct udevice *dev)
 {
+#if !CONFIG_IS_ENABLED(OF_PLATDATA)
struct rk3368_clk_priv *priv = dev_get_priv(dev);
 
priv->cru = (struct rk3368_cru *)devfdt_get_addr(dev);
+#endif
 
return 0;
 }
@@ -291,6 +305,9 @@ U_BOOT_DRIVER(rockchip_rk3368_cru) = {
.id = UCLASS_CLK,
.of_match   = rk3368_clk_ids,
.priv_auto_alloc_size = sizeof(struct rk3368_clk_priv),
+#if CONFIG_IS_ENABLED(OF_PLATDATA)
+   .platdata_auto_alloc_size = sizeof(struct rk3368_clk_plat),
+#endif
.ofdata_to_platdata = rk3368_clk_ofdata_to_platdata,
.ops= &rk3368_clk_ops,
.bind   = rk3368_clk_bind,
-- 
2.1.4

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

[U-Boot] [PATCH 32/52] rockchip: pinctrl: rk3368: add support for configuring the MMC pins

[Philipp Tomsich]

The RK3368 has two SD/MMC controllers that can be used from U-Boot
both during SPL and for booting an OS from the full bootloader stage.
While both are configured to (mostly) sensible settings from the BROM,
additional configuration for the MMC controller is needed to configure
it to 8bit mode.

This adds pinctrl support for the MMC controller.

Signed-off-by: Philipp Tomsich 
---

 drivers/pinctrl/rockchip/pinctrl_rk3368.c | 48 +++
 1 file changed, 48 insertions(+)

diff --git a/drivers/pinctrl/rockchip/pinctrl_rk3368.c 
b/drivers/pinctrl/rockchip/pinctrl_rk3368.c
index aecd11d..23950d0 100644
--- a/drivers/pinctrl/rockchip/pinctrl_rk3368.c
+++ b/drivers/pinctrl/rockchip/pinctrl_rk3368.c
@@ -81,6 +81,46 @@ static void pinctrl_rk3368_gmac_config(struct rk3368_grf 
*grf, int gmac_id)
 }
 #endif
 
+static void pinctrl_rk3368_sdmmc_config(struct rk3368_grf *grf, int mmc_id)
+{
+   switch (mmc_id) {
+   case PERIPH_ID_EMMC:
+   debug("mmc id = %d setting registers!\n", mmc_id);
+   rk_clrsetreg(&grf->gpio1c_iomux,
+RK3368_GPIO1C2_MASK | RK3368_GPIO1C3_MASK |
+RK3368_GPIO1C4_MASK | RK3368_GPIO1C5_MASK |
+RK3368_GPIO1C6_MASK | RK3368_GPIO1C7_MASK,
+RK3368_GPIO1C2_EMMC_DATA0 |
+RK3368_GPIO1C3_EMMC_DATA1 |
+RK3368_GPIO1C4_EMMC_DATA2 |
+RK3368_GPIO1C5_EMMC_DATA3 |
+RK3368_GPIO1C6_EMMC_DATA4 |
+RK3368_GPIO1C7_EMMC_DATA5);
+   rk_clrsetreg(&grf->gpio1d_iomux,
+RK3368_GPIO1D0_MASK | RK3368_GPIO1D1_MASK |
+RK3368_GPIO1D2_MASK | RK3368_GPIO1D3_MASK,
+RK3368_GPIO1D0_EMMC_DATA6 |
+RK3368_GPIO1D1_EMMC_DATA7 |
+RK3368_GPIO1D2_EMMC_CMD |
+RK3368_GPIO1D3_EMMC_PWREN);
+   rk_clrsetreg(&grf->gpio2a_iomux,
+RK3368_GPIO2A3_MASK | RK3368_GPIO2A4_MASK,
+RK3368_GPIO2A3_EMMC_RSTNOUT |
+RK3368_GPIO2A4_EMMC_CLKOUT);
+   break;
+   case PERIPH_ID_SDCARD:
+   /*
+* We assume that the BROM has already set this up
+* correctly for us and that there's nothing to do
+* here.
+*/
+   break;
+   default:
+   debug("mmc id = %d iomux error!\n", mmc_id);
+   break;
+   }
+}
+
 static int rk3368_pinctrl_request(struct udevice *dev, int func, int flags)
 {
struct rk3368_pinctrl_priv *priv = dev_get_priv(dev);
@@ -94,6 +134,10 @@ static int rk3368_pinctrl_request(struct udevice *dev, int 
func, int flags)
case PERIPH_ID_UART4:
pinctrl_rk3368_uart_config(priv, func);
break;
+   case PERIPH_ID_EMMC:
+   case PERIPH_ID_SDCARD:
+   pinctrl_rk3368_sdmmc_config(priv->grf, func);
+   break;
 #if CONFIG_IS_ENABLED(GMAC_ROCKCHIP)
case PERIPH_ID_GMAC:
pinctrl_rk3368_gmac_config(priv->grf, func);
@@ -128,6 +172,10 @@ static int rk3368_pinctrl_get_periph_id(struct udevice 
*dev,
return PERIPH_ID_UART1;
case 55:
return PERIPH_ID_UART0;
+   case 35:
+   return PERIPH_ID_EMMC;
+   case 32:
+   return PERIPH_ID_SDCARD;
 #if CONFIG_IS_ENABLED(GMAC_ROCKCHIP)
case 27:
return PERIPH_ID_GMAC;
-- 
2.1.4

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

[U-Boot] [PATCH 19/52] spl: consistently use $(SPL_TPL_) to select features for SPL and TPL builds

[Philipp Tomsich]

To allow for a finer-grained control of features for TPL and SPL
builds all modules/boot-methods/etc. need to be consistently selected
based on the $(SPL_TPL_) macros.

This allows splitting the associated config-options in Kconfig: we
don't split the Kconfig options here and now, as this should happen on
an as-needed basis, whenever someone needs a feature/boot-method/etc.
in their TPL.

Signed-off-by: Philipp Tomsich 
---

 common/Makefile |  8 
 common/spl/Makefile | 36 ++--
 2 files changed, 22 insertions(+), 22 deletions(-)

diff --git a/common/Makefile b/common/Makefile
index 539cf98..14345de 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -53,7 +53,7 @@ obj-$(CONFIG_ENV_IS_IN_UBI) += env_ubi.o
 obj-$(CONFIG_ENV_IS_NOWHERE) += env_nowhere.o
 
 obj-$(CONFIG_CMD_BEDBUG) += bedbug.o
-obj-$(CONFIG_$(SPL_)OF_LIBFDT) += fdt_support.o
+obj-$(CONFIG_$(SPL_TPL_)OF_LIBFDT) += fdt_support.o
 
 obj-$(CONFIG_MII) += miiphyutil.o
 obj-$(CONFIG_CMD_MII) += miiphyutil.o
@@ -148,9 +148,9 @@ obj-y += malloc_simple.o
 endif
 obj-y += image.o
 obj-$(CONFIG_ANDROID_BOOT_IMAGE) += image-android.o
-obj-$(CONFIG_$(SPL_)OF_LIBFDT) += image-fdt.o
-obj-$(CONFIG_$(SPL_)FIT) += image-fit.o
-obj-$(CONFIG_$(SPL_)FIT_SIGNATURE) += image-sig.o
+obj-$(CONFIG_$(SPL_TPL_)OF_LIBFDT) += image-fdt.o
+obj-$(CONFIG_$(SPL_TPL_)FIT) += image-fit.o
+obj-$(CONFIG_$(SPL_TPL_)FIT_SIGNATURE) += image-sig.o
 obj-$(CONFIG_IO_TRACE) += iotrace.o
 obj-y += memsize.o
 obj-y += stdio.o
diff --git a/common/spl/Makefile b/common/spl/Makefile
index 189b272..112b3e6 100644
--- a/common/spl/Makefile
+++ b/common/spl/Makefile
@@ -10,24 +10,24 @@
 
 ifdef CONFIG_SPL_BUILD
 obj-$(CONFIG_SPL_FRAMEWORK) += spl.o
-obj-$(CONFIG_SPL_BOOTROM_SUPPORT) += spl_bootrom.o
-obj-$(CONFIG_SPL_LOAD_FIT) += spl_fit.o
-obj-$(CONFIG_SPL_NOR_SUPPORT) += spl_nor.o
-obj-$(CONFIG_SPL_XIP_SUPPORT) += spl_xip.o
-obj-$(CONFIG_SPL_YMODEM_SUPPORT) += spl_ymodem.o
+obj-$(CONFIG_$(SPL_TPL_)BOOTROM_SUPPORT) += spl_bootrom.o
+obj-$(CONFIG_$(SPL_TPL_)LOAD_FIT) += spl_fit.o
+obj-$(CONFIG_$(SPL_TPL_)SPL_NOR_SUPPORT) += spl_nor.o
+obj-$(CONFIG_$(SPL_TPL_)SPL_XIP_SUPPORT) += spl_xip.o
+obj-$(CONFIG_$(SPL_TPL_)SPL_YMODEM_SUPPORT) += spl_ymodem.o
 ifndef CONFIG_SPL_UBI
-obj-$(CONFIG_SPL_NAND_SUPPORT) += spl_nand.o
-obj-$(CONFIG_SPL_ONENAND_SUPPORT) += spl_onenand.o
+obj-$(CONFIG_$(SPL_TPL_)NAND_SUPPORT) += spl_nand.o
+obj-$(CONFIG_$(SPL_TPL_)ONENAND_SUPPORT) += spl_onenand.o
 endif
-obj-$(CONFIG_SPL_UBI) += spl_ubi.o
-obj-$(CONFIG_SPL_NET_SUPPORT) += spl_net.o
-obj-$(CONFIG_SPL_MMC_SUPPORT) += spl_mmc.o
-obj-$(CONFIG_SPL_ATF_SUPPORT) += spl_atf.o
-obj-$(CONFIG_SPL_USB_SUPPORT) += spl_usb.o
-obj-$(CONFIG_SPL_FAT_SUPPORT) += spl_fat.o
-obj-$(CONFIG_SPL_EXT_SUPPORT) += spl_ext.o
-obj-$(CONFIG_SPL_SATA_SUPPORT) += spl_sata.o
-obj-$(CONFIG_SPL_DFU_SUPPORT) += spl_dfu.o
-obj-$(CONFIG_SPL_SPI_LOAD) += spl_spi.o
-obj-$(CONFIG_SPL_RAM_SUPPORT) += spl_ram.o
+obj-$(CONFIG_$(SPL_TPL_)UBI) += spl_ubi.o
+obj-$(CONFIG_$(SPL_TPL_)NET_SUPPORT) += spl_net.o
+obj-$(CONFIG_$(SPL_TPL_)MMC_SUPPORT) += spl_mmc.o
+obj-$(CONFIG_$(SPL_TPL_)ATF_SUPPORT) += spl_atf.o
+obj-$(CONFIG_$(SPL_TPL_)USB_SUPPORT) += spl_usb.o
+obj-$(CONFIG_$(SPL_TPL_)FAT_SUPPORT) += spl_fat.o
+obj-$(CONFIG_$(SPL_TPL_)EXT_SUPPORT) += spl_ext.o
+obj-$(CONFIG_$(SPL_TPL_)SATA_SUPPORT) += spl_sata.o
+obj-$(CONFIG_$(SPL_TPL_)DFU_SUPPORT) += spl_dfu.o
+obj-$(CONFIG_$(SPL_TPL_)SPI_LOAD) += spl_spi.o
+obj-$(CONFIG_$(SPL_TPL_)RAM_SUPPORT) += spl_ram.o
 endif
-- 
2.1.4

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

[U-Boot] [PATCH 04/52] rockchip: back-to-bootrom: split BACK_TO_BOOTROM for TPL/SPL

[Philipp Tomsich]

The back-to-bootrom option is rather unfortunately named
  CONFIG_ROCKCHIP_SPL_BACK_TO_BOOTROM
instead of
  CONFIG_SPL_ROCKCHIP_BACK_TO_BOOTROM

To make is selectable through CONFIG_IS_ENABLED(ROCKCHIP_BACK_TO_BOOTROM),
we need to rename it.  At the same time, we introduce a TPL_ variant of
the option to give us finer-grained control over when it should be used.

This change is motivated by our RK3368 boot process, which returns to
the boot ROM only from the TPL stage, but not from the SPL stage.

Signed-off-by: Philipp Tomsich 
---

 arch/arm/mach-rockchip/Kconfig| 15 +--
 arch/arm/mach-rockchip/rk3188-board-spl.c |  5 ++---
 arch/arm/mach-rockchip/rk3188-board.c |  2 +-
 arch/arm/mach-rockchip/rk3288-board-spl.c |  4 ++--
 arch/arm/mach-rockchip/rk3288-board.c |  4 ++--
 arch/arm/mach-rockchip/rk3399-board-spl.c |  4 ++--
 configs/evb-rk3288_defconfig  |  2 +-
 configs/fennec-rk3288_defconfig   |  2 +-
 configs/firefly-rk3288_defconfig  |  2 +-
 configs/miqi-rk3288_defconfig |  2 +-
 configs/popmetal-rk3288_defconfig |  2 +-
 configs/rock2_defconfig   |  2 +-
 configs/rock_defconfig|  2 +-
 configs/tinker-rk3288_defconfig   |  2 +-
 doc/README.rockchip   |  2 +-
 include/configs/rk3188_common.h   |  2 +-
 include/configs/rk3288_common.h   |  2 +-
 include/configs/rock.h|  2 +-
 include/configs/rockchip-common.h |  2 +-
 19 files changed, 35 insertions(+), 25 deletions(-)

diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig
index bb44c61..523bc11 100644
--- a/arch/arm/mach-rockchip/Kconfig
+++ b/arch/arm/mach-rockchip/Kconfig
@@ -99,10 +99,21 @@ config ROCKCHIP_RV1108
  The Rockchip RV1108 is a ARM-based SoC with a single-core Cortex-A7
  and a DSP.
 
-config ROCKCHIP_SPL_BACK_TO_BROM
+config SPL_ROCKCHIP_BACK_TO_BROM
bool "SPL returns to bootrom"
default y if ROCKCHIP_RK3036
select ROCKCHIP_BROM_HELPER
+   depends on SPL
+   help
+ Rockchip SoCs have ability to load SPL & U-Boot binary. If enabled,
+  SPL will return to the boot rom, which will then load the U-Boot
+  binary to keep going on.
+
+config TPL_ROCKCHIP_BACK_TO_BROM
+   bool "TPL returns to bootrom"
+   default y if ROCKCHIP_RK3368
+   select ROCKCHIP_BROM_HELPER
+   depends on TPL
help
  Rockchip SoCs have ability to load SPL & U-Boot binary. If enabled,
   SPL will return to the boot rom, which will then load the U-Boot
@@ -120,7 +131,7 @@ config ROCKCHIP_BROM_HELPER
bool
 
 config SPL_MMC_SUPPORT
-   default y if !ROCKCHIP_SPL_BACK_TO_BROM
+   default y if !SPL_ROCKCHIP_BACK_TO_BROM
 
 source "arch/arm/mach-rockchip/rk3036/Kconfig"
 source "arch/arm/mach-rockchip/rk3188/Kconfig"
diff --git a/arch/arm/mach-rockchip/rk3188-board-spl.c 
b/arch/arm/mach-rockchip/rk3188-board-spl.c
index c3e174d..d3866bf 100644
--- a/arch/arm/mach-rockchip/rk3188-board-spl.c
+++ b/arch/arm/mach-rockchip/rk3188-board-spl.c
@@ -167,8 +167,7 @@ void board_init_f(ulong dummy)
}
 
setup_arm_clock();
-
-#if defined(CONFIG_ROCKCHIP_SPL_BACK_TO_BROM) && 
!defined(CONFIG_SPL_BOARD_INIT)
+#if CONFIG_IS_ENABLED(ROCKCHIP_BACK_TO_BROM) && !defined(CONFIG_SPL_BOARD_INIT)
back_to_bootrom();
 #endif
 }
@@ -229,7 +228,7 @@ void spl_board_init(void)
}
 
preloader_console_init();
-#ifdef CONFIG_ROCKCHIP_SPL_BACK_TO_BROM
+#if CONFIG_IS_ENABLED(ROCKCHIP_BACK_TO_BROM)
back_to_bootrom();
 #endif
return;
diff --git a/arch/arm/mach-rockchip/rk3188-board.c 
b/arch/arm/mach-rockchip/rk3188-board.c
index 3e76100..622e046 100644
--- a/arch/arm/mach-rockchip/rk3188-board.c
+++ b/arch/arm/mach-rockchip/rk3188-board.c
@@ -39,7 +39,7 @@ int board_late_init(void)
 
 int board_init(void)
 {
-#if defined(CONFIG_ROCKCHIP_SPL_BACK_TO_BROM)
+#if CONFIG_IS_ENABLED(ROCKCHIP_BACK_TO_BROM)
struct udevice *pinctrl;
int ret;
 
diff --git a/arch/arm/mach-rockchip/rk3288-board-spl.c 
b/arch/arm/mach-rockchip/rk3288-board-spl.c
index 5668fd2..6b7bf85 100644
--- a/arch/arm/mach-rockchip/rk3288-board-spl.c
+++ b/arch/arm/mach-rockchip/rk3288-board-spl.c
@@ -249,7 +249,7 @@ void board_init_f(ulong dummy)
debug("DRAM init failed: %d\n", ret);
return;
}
-#if defined(CONFIG_ROCKCHIP_SPL_BACK_TO_BROM) && 
!defined(CONFIG_SPL_BOARD_INIT)
+#if CONFIG_IS_ENABLED(ROCKCHIP_BACK_TO_BROM) && !defined(CONFIG_SPL_BOARD_INIT)
back_to_bootrom();
 #endif
 }
@@ -316,7 +316,7 @@ void spl_board_init(void)
}
 
preloader_console_init();
-#ifdef CONFIG_ROCKCHIP_SPL_BACK_TO_BROM
+#if CONFIG_IS_ENABLED(ROCKCHIP_BACK_TO_BROM)
back_to_bootrom();
 #endif
return;
diff --git a/arch/arm/mach-rockchip/rk3288-board.c 
b/arch/arm/mach-rockchip/rk3288-board.c
i

[U-Boot] [PATCH 07/52] spl: dm: Kconfig: split REGMAP/SYSCON support for TPL from SPL

[Philipp Tomsich]

This change introduces TPL variants of the REGMAP and SYSCON config
options (i.e. TPL_REGMAP and TPL_SYSCON in analogy to SPL_REGMAP and
SPL_SYSCON) in preparation of a finer-grained feature selection for
building feature-rich TPL variants.

Signed-off-by: Philipp Tomsich 
---

 drivers/core/Kconfig  | 19 +++
 drivers/core/Makefile |  4 ++--
 2 files changed, 21 insertions(+), 2 deletions(-)

diff --git a/drivers/core/Kconfig b/drivers/core/Kconfig
index 01e6d71..6b5796b 100644
--- a/drivers/core/Kconfig
+++ b/drivers/core/Kconfig
@@ -105,6 +105,16 @@ config SPL_REGMAP
  support any bus type (I2C, SPI) but so far this only supports
  direct memory access.
 
+config TPL_REGMAP
+   bool "Support register maps in TPL"
+   depends on TPL_DM
+   help
+ Hardware peripherals tend to have one or more sets of registers
+ which can be accessed to control the hardware. A register map
+ models this with a simple read/write interface. It can in principle
+ support any bus type (I2C, SPI) but so far this only supports
+ direct memory access.
+
 config SYSCON
bool "Support system controllers"
depends on REGMAP
@@ -123,6 +133,15 @@ config SPL_SYSCON
  by this uclass, including accessing registers via regmap and
  assigning a unique number to each.
 
+config TPL_SYSCON
+   bool "Support system controllers in TPL"
+   depends on TPL_REGMAP
+   help
+ Many SoCs have a number of system controllers which are dealt with
+ as a group by a single driver. Some common functionality is provided
+ by this uclass, including accessing registers via regmap and
+ assigning a unique number to each.
+
 config DEVRES
bool "Managed device resources"
depends on DM
diff --git a/drivers/core/Makefile b/drivers/core/Makefile
index 435cf98..dcfb1b0 100644
--- a/drivers/core/Makefile
+++ b/drivers/core/Makefile
@@ -9,8 +9,8 @@ obj-$(CONFIG_DEVRES) += devres.o
 obj-$(CONFIG_$(SPL_)DM_DEVICE_REMOVE)  += device-remove.o
 obj-$(CONFIG_$(SPL_)SIMPLE_BUS)+= simple-bus.o
 obj-$(CONFIG_DM)   += dump.o
-obj-$(CONFIG_$(SPL_)REGMAP)+= regmap.o
-obj-$(CONFIG_$(SPL_)SYSCON)+= syscon-uclass.o
+obj-$(CONFIG_$(SPL_TPL_)REGMAP)+= regmap.o
+obj-$(CONFIG_$(SPL_TPL_)SYSCON)+= syscon-uclass.o
 obj-$(CONFIG_OF_LIVE) += of_access.o of_addr.o
 ifndef CONFIG_DM_DEV_READ_INLINE
 obj-$(CONFIG_OF_CONTROL) += read.o
-- 
2.1.4

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

[U-Boot] [PATCH 09/52] spl: dm: Kconfig: introduce TPL_RAM (in analogy to SPL_RAM)

[Philipp Tomsich]

To allow finer grained selection of features for TPL, we introduce
TPL_RAM (in analogy to SPL_RAM).

Signed-off-by: Philipp Tomsich 
---

 drivers/ram/Kconfig | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/ram/Kconfig b/drivers/ram/Kconfig
index e75c23f..836be25 100644
--- a/drivers/ram/Kconfig
+++ b/drivers/ram/Kconfig
@@ -17,6 +17,15 @@ config SPL_RAM
  SPL, enable this option. It might provide a cleaner interface to
  setting up RAM (e.g. SDRAM / DDR) within SPL.
 
+config TPL_RAM
+   bool "Enable RAM support in SPL"
+   depends on RAM && TPL_DM
+   help
+ The RAM subsystem adds a small amount of overhead to the image.
+ If this is acceptable and you have a need to use RAM drivers in
+ TPL, enable this option. It might provide a cleaner interface to
+ setting up RAM (e.g. SDRAM / DDR) within TPL.
+
 config STM32_SDRAM
bool "Enable STM32 SDRAM support"
depends on RAM
-- 
2.1.4

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

[U-Boot] [PATCH 02/52] spl: configure 'return to bootrom' separately for SPL and TPL

[Philipp Tomsich]

On the RK3368, we want our TPL to use the 'return to bootrom' boot
method (to have the bootrom load up the SPL stage) and then continue
with different boot methods (MMC, SPI, etc.) from SPL.

This adds the config option needed to control the availabily of the
'return to bootrom' boot-method separately for the TPL stage.

Signed-off-by: Philipp Tomsich 
---

 common/spl/Kconfig | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/common/spl/Kconfig b/common/spl/Kconfig
index ee767b7..dd94801 100644
--- a/common/spl/Kconfig
+++ b/common/spl/Kconfig
@@ -698,6 +698,17 @@ config TPL
 
 if TPL
 
+config TPL_BOOTROM_SUPPORT
+bool "Support returning to the BOOTROM (from TPL)"
+   help
+ Some platforms (e.g. the Rockchip RK3368) provide support in their
+ ROM for loading the next boot-stage after performing basic setup
+ from the TPL stage.
+
+ Enable this option, to return to the BOOTROM through the
+ BOOT_DEVICE_BOOTROM (or fall-through to the next boot device in the
+ boot device list, if not implemented for a given board)
+
 config TPL_ENV_SUPPORT
bool "Support an environment"
help
-- 
2.1.4

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

[U-Boot] [PATCH 08/52] spl: dm: Kconfig: SPL_RAM depends on SPL_DM

[Philipp Tomsich]

This commit models the dependency from SPL_RAM to SPL_DM in Kconfig.

Signed-off-by: Philipp Tomsich 
---

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

diff --git a/drivers/ram/Kconfig b/drivers/ram/Kconfig
index 61afd7a..e75c23f 100644
--- a/drivers/ram/Kconfig
+++ b/drivers/ram/Kconfig
@@ -10,7 +10,7 @@ config RAM
 
 config SPL_RAM
bool "Enable RAM support in SPL"
-   depends on RAM
+   depends on RAM && SPL_DM
help
  The RAM subsystem adds a small amount of overhead to the image.
  If this is acceptable and you have a need to use RAM drivers in
-- 
2.1.4

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

[U-Boot] [PATCH 03/52] rockchip: back-to-bootrom: add 'back-to-bootrom' support for AArch64

[Philipp Tomsich]

The back-to-bootrom support for Rockchip is equivalent to an
(assembly) implementation of setjmp/longjmp (i.e. it saves the
stack-pointer, link-register and callee-saved registers). Up until
now, this had only been implemented for AArch32 (i.e. ARMv7 or older),
which puts the new ARMv8 devices (which boot in AArch64 mode) at a
slight disadvantage.

To allow use of the 'back-to-bootrom' feature on new devices (e.g. the
RK3368), this commit adds an implementation for AArch64.

Signed-off-by: Philipp Tomsich 
---

 arch/arm/mach-rockchip/save_boot_param.S | 37 
 1 file changed, 37 insertions(+)

diff --git a/arch/arm/mach-rockchip/save_boot_param.S 
b/arch/arm/mach-rockchip/save_boot_param.S
index 5e6c8db..945a9dd 100644
--- a/arch/arm/mach-rockchip/save_boot_param.S
+++ b/arch/arm/mach-rockchip/save_boot_param.S
@@ -1,11 +1,47 @@
 /*
  * (C) Copyright 2016 Rockchip Electronics Co., Ltd
+ * (C) Copyright 2017 Theobroma Systems Design und Consulting GmbH
  *
  * SPDX-License-Identifier: GPL-2.0+
  */
 
 #include 
 
+#if defined(CONFIG_ARM64)
+.globl SAVE_SP_ADDR
+SAVE_SP_ADDR:
+   .quad 0
+
+ENTRY(save_boot_params)
+   sub sp, sp, #0x100
+   stp x29, x30, [sp, #0x50]
+   stp x27, x28, [sp, #0x40]
+   stp x25, x26, [sp, #0x30]
+   stp x23, x24, [sp, #0x20]
+   stp x21, x22, [sp, #0x10]
+   stp x19, x20, [sp, #0]
+   ldr x8, =SAVE_SP_ADDR
+   mov x9, sp
+   str x9, [x8]
+   b   save_boot_params_ret  /* back to my caller */
+ENDPROC(save_boot_params)
+
+.globl _back_to_bootrom_s
+ENTRY(_back_to_bootrom_s)
+   ldr x0, =SAVE_SP_ADDR
+   ldr x0, [x0]
+   mov sp, x0
+   ldp x29, x30, [sp, #0x50]
+   ldp x27, x28, [sp, #0x40]
+   ldp x25, x26, [sp, #0x30]
+   ldp x23, x24, [sp, #0x20]
+   ldp x21, x22, [sp, #0x10]
+   ldp x19, x20, [sp]
+   add sp, sp, #0x100
+   mov x0, xzr
+   ret
+ENDPROC(_back_to_bootrom_s)
+#else
 .globl SAVE_SP_ADDR
 SAVE_SP_ADDR:
.word 0
@@ -30,3 +66,4 @@ ENTRY(_back_to_bootrom_s)
mov r0, #0
pop {r1-r12, pc}
 ENDPROC(_back_to_bootrom_s)
+#endif
-- 
2.1.4

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

[U-Boot] [PATCH 05/52] rockchip: back-to-bootrom: simplify the #ifdef-check for LIBGENERIC in TPL/SPL

[Philipp Tomsich]

With the finer-grained control over LIBGENERIC_SUPPORT for TPL/SPL (i.e.
with the newly introduced distinction between TPL_LIBGENERIC_SUPPORT and
SPL_LIBGENERIC_SUPPORT), we can simplify the #ifdef-check to simply use
CONFIG_IS_ENABELD.

Signed-off-by: Philipp Tomsich 
---

 arch/arm/mach-rockchip/bootrom.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-rockchip/bootrom.c b/arch/arm/mach-rockchip/bootrom.c
index da36f92..4d38ed6 100644
--- a/arch/arm/mach-rockchip/bootrom.c
+++ b/arch/arm/mach-rockchip/bootrom.c
@@ -9,8 +9,8 @@
 
 void back_to_bootrom(void)
 {
-#if defined(CONFIG_SPL_LIBGENERIC_SUPPORT) && !defined(CONFIG_TPL_BUILD)
-   printf("Returning to boot ROM...");
+#if CONFIG_IS_ENABLED(LIBGENERIC_SUPPORT)
+   printf("Returning to boot ROM...\n");
 #endif
_back_to_bootrom_s();
 }
-- 
2.1.4

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

[U-Boot] [PATCH 06/52] spl: dm: Kconfig: use more specific prereqs for SPL_REGMAP and SPL_SYSCON

[Philipp Tomsich]

SPL_REGMAP and SPL_SYSCON were marked as depending on DM, when a
stricter dependency of SPL_DM was possible.  This commit makes the
prereq more specific.

Signed-off-by: Philipp Tomsich 
---

 drivers/core/Kconfig | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/core/Kconfig b/drivers/core/Kconfig
index fb5c4e8..01e6d71 100644
--- a/drivers/core/Kconfig
+++ b/drivers/core/Kconfig
@@ -97,7 +97,7 @@ config REGMAP
 
 config SPL_REGMAP
bool "Support register maps in SPL"
-   depends on DM
+   depends on SPL_DM
help
  Hardware peripherals tend to have one or more sets of registers
  which can be accessed to control the hardware. A register map
@@ -116,7 +116,7 @@ config SYSCON
 
 config SPL_SYSCON
bool "Support system controllers in SPL"
-   depends on REGMAP
+   depends on SPL_REGMAP
help
  Many SoCs have a number of system controllers which are dealt with
  as a group by a single driver. Some common functionality is provided
-- 
2.1.4

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

[U-Boot] [PATCH 01/52] spl: add a 'return to bootrom' boot method

[Philipp Tomsich]

Some devices (e.g. the RK3368) have only limited SRAM, but provide
support for loading the next boot stage after our SPL performs basic
setup (e.g. DRAM).

For target systems like these, we add a boot device BOOTROM that will
invoke a board-specific hook to return to the bootrom (if supported).

Signed-off-by: Philipp Tomsich 
---

 arch/arm/include/asm/spl.h |  1 +
 common/spl/Kconfig | 11 +++
 common/spl/Makefile|  1 +
 common/spl/spl_bootrom.c   | 27 +++
 include/spl.h  | 10 ++
 5 files changed, 50 insertions(+)
 create mode 100644 common/spl/spl_bootrom.c

diff --git a/arch/arm/include/asm/spl.h b/arch/arm/include/asm/spl.h
index 0e67470..df45511 100644
--- a/arch/arm/include/asm/spl.h
+++ b/arch/arm/include/asm/spl.h
@@ -30,6 +30,7 @@ enum {
BOOT_DEVICE_BOARD,
BOOT_DEVICE_DFU,
BOOT_DEVICE_XIP,
+   BOOT_DEVICE_BOOTROM,
BOOT_DEVICE_NONE
 };
 #endif
diff --git a/common/spl/Kconfig b/common/spl/Kconfig
index 4de8139..ee767b7 100644
--- a/common/spl/Kconfig
+++ b/common/spl/Kconfig
@@ -25,6 +25,17 @@ config SPL_BOARD_INIT
  spl_board_init() from board_init_r(). This function should be
  provided by the board.
 
+config SPL_BOOTROM_SUPPORT
+bool "Support returning to the BOOTROM"
+   help
+ Some platforms (e.g. the Rockchip RK3368) provide support in their
+ ROM for loading the next boot-stage after performing basic setup
+ from the SPL stage.
+
+ Enable this option, to return to the BOOTROM through the
+ BOOT_DEVICE_BOOTROM (or fall-through to the next boot device in the
+ boot device list, if not implemented for a given board)
+
 config SPL_RAW_IMAGE_SUPPORT
bool "Support SPL loading and booting of RAW images"
default n if (ARCH_MX6 && (SPL_MMC_SUPPORT || SPL_SATA_SUPPORT))
diff --git a/common/spl/Makefile b/common/spl/Makefile
index 47a64dd..189b272 100644
--- a/common/spl/Makefile
+++ b/common/spl/Makefile
@@ -10,6 +10,7 @@
 
 ifdef CONFIG_SPL_BUILD
 obj-$(CONFIG_SPL_FRAMEWORK) += spl.o
+obj-$(CONFIG_SPL_BOOTROM_SUPPORT) += spl_bootrom.o
 obj-$(CONFIG_SPL_LOAD_FIT) += spl_fit.o
 obj-$(CONFIG_SPL_NOR_SUPPORT) += spl_nor.o
 obj-$(CONFIG_SPL_XIP_SUPPORT) += spl_xip.o
diff --git a/common/spl/spl_bootrom.c b/common/spl/spl_bootrom.c
new file mode 100644
index 000..6804246
--- /dev/null
+++ b/common/spl/spl_bootrom.c
@@ -0,0 +1,27 @@
+/*
+ * Copyright (C) 2017 Theobroma Systems Design und Consulting GmH
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+
+__weak void board_return_to_bootrom(void)
+{
+}
+
+static int spl_return_to_bootrom(struct spl_image_info *spl_image,
+struct spl_boot_device *bootdev)
+{
+   /*
+* If the board implements a way to return to its ROM (with
+* the expectation that the next stage of will be booted by
+* the ROM), it will implement board_return_to_bootrom() and
+* should not return from it.
+*/
+   board_return_to_bootrom();
+   return false;
+}
+
+SPL_LOAD_IMAGE_METHOD("BOOTROM", 0, BOOT_DEVICE_BOOTROM, 
spl_return_to_bootrom);
diff --git a/include/spl.h b/include/spl.h
index ccb1404..b5c2994 100644
--- a/include/spl.h
+++ b/include/spl.h
@@ -278,4 +278,14 @@ int spl_mmc_load_image(struct spl_image_info *spl_image,
   struct spl_boot_device *bootdev);
 
 void bl31_entry(void);
+
+/**
+ * board_return_to_bootrom - allow for boards to continue with the boot ROM
+ *
+ * If a board (e.g. the Rockchip RK3368 boards) provide some
+ * supporting functionality for SPL in their boot ROM and the SPL
+ * stage wants to return to the ROM code to continue booting, boards
+ * can implement 'board_return_to_bootrom'.
+ */
+void board_return_to_bootrom(void);
 #endif
-- 
2.1.4

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

[U-Boot] [PATCH] HACK: DO NOT MERGE: Simple program to printout preprocessed values

[Tom Rini]

When migrating to Kconfig there may be cases where the symbol to be
migrated depends on a preprocessed or calculated value, and thus
moveconfig.py will not migrate it correctly.  Introduce an easily
hackable tool, tools/printvars.c that will give the final value.  Hack
the main Makefile to only build this tool, and buildman to save this
tool.  Thus it becomes "quick" to have buildman build this tool for
every board in U-Boot today.

Signed-off-by: Tom Rini 
---
 Makefile|  2 +-
 tools/Makefile  |  3 +++
 tools/buildman/builderthread.py |  4 +---
 tools/printvars.c   | 18 ++
 4 files changed, 23 insertions(+), 4 deletions(-)
 create mode 100644 tools/printvars.c

diff --git a/Makefile b/Makefile
index 452596485dd3..40542e9db077 100644
--- a/Makefile
+++ b/Makefile
@@ -851,7 +851,7 @@ quiet_cmd_cfgcheck = CFGCHK  $2
 cmd_cfgcheck = $(srctree)/scripts/check-config.sh $2 \
$(srctree)/scripts/config_whitelist.txt $(srctree)
 
-all:   $(ALL-y)
+all:   tools
 ifeq ($(CONFIG_DM_I2C_COMPAT)$(CONFIG_SANDBOX),y)
@echo "= WARNING =="
@echo "This board uses CONFIG_DM_I2C_COMPAT. Please remove"
diff --git a/tools/Makefile b/tools/Makefile
index cb1683e1539c..a0a5d71f608c 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -55,6 +55,9 @@ HOSTCFLAGS_xway-swap-bytes.o := -pedantic
 hostprogs-y += mkenvimage
 mkenvimage-objs := mkenvimage.o os_support.o lib/crc32.o
 
+hostprogs-y += printvars
+printvars-objs := printvars.o
+
 hostprogs-y += dumpimage mkimage
 hostprogs-$(CONFIG_FIT_SIGNATURE) += fit_info fit_check_sign
 
diff --git a/tools/buildman/builderthread.py b/tools/buildman/builderthread.py
index 9e8ca80c5b53..3992f5fcd4cf 100644
--- a/tools/buildman/builderthread.py
+++ b/tools/buildman/builderthread.py
@@ -364,9 +364,7 @@ class BuilderThread(threading.Thread):
 
 # Now write the actual build output
 if keep_outputs:
-self.CopyFiles(result.out_dir, build_dir, '', ['u-boot*', '*.bin',
-'*.map', '*.img', 'MLO', 'SPL', 'include/autoconf.mk',
-'spl/u-boot-spl*'])
+self.CopyFiles(result.out_dir, build_dir, '', ['tools/printvars'])
 
 def CopyFiles(self, out_dir, build_dir, dirname, patterns):
 """Copy files from the build directory to the output.
diff --git a/tools/printvars.c b/tools/printvars.c
new file mode 100644
index ..95ae065ab62f
--- /dev/null
+++ b/tools/printvars.c
@@ -0,0 +1,18 @@
+#include 
+/* HACK: Give us typedefs so we can proceed */
+typedef uint32_t u32;
+typedef uint16_t u16;
+typedef uint8_t u8;
+typedef int32_t s32;
+typedef int16_t s16;
+typedef int8_t s8;
+#include 
+#include 
+
+int main(int argc, char **argv) {
+#ifdef CONFIG_WHATEVER
+   printf("CONFIG_WHATEVER=whatever");
+#endif
+
+   return 0;
+}
-- 
1.9.1

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

[U-Boot] Enc: Uboot compatible with board Tegra124-nyan-big (ChromeBook G3 HP 14")

[Alexandre N. Perfeito]

  Hi,



   I resend the e-mail as you asked !


  Can help in this tip .


Best Regards

Perfeito,Alexander


De: s...@google.com  em nome de Simon Glass 
Enviado: segunda-feira, 17 de julho de 2017 19:50
Para: Alexandre N. Perfeito
Assunto: Re: Uboot compatible with board Tegra124-nyan-big (ChromeBook G3 HP 
14")

Hi,

On 17 July 2017 at 10:33, Alexandre N. Perfeito 
mailto:perfeit...@hotmail.com>> wrote:


Simon,


Hi , My Name is Alexander and i need some tip information about U-boot 
Board Nyan-Big to runinng Linux v4.4.x.x.

Can you please resend this to the U-Boot mailing list and cc me?

Thanks,
Simon


I compiled source 4.4.0.70 Ubuntu distribution in chroot environment in my 
chormebook Tegra Tk1.
After compilation the generated files were the following:


[aperfeito@alarm boot]$ ls -l
total 24992
-rw-r--r-- 1 root root98874 Jul 13 14:54 config-4.4.70-ARCH
-rw-r--r-- 1 root root  8277506 Jul 13 14:54 initrd.img-4.4.70-ARCH
-rw-r--r-- 1 root root  2033244 Jul 13 14:54 System.map-4.4.70-ARCH
-rw-r--r-- 1 root root 15175680 Jul 13 14:54 vmlinuz-4.4.70-ARCH


I also compiled the u-boot-tegra in the same environment in chroot Ubuntu 
Xenial distribution these were compiled according to the email of Tom Warren 
send before

  Make 'nyan-big_defconfig' and everything ok as you see below the generated 
files:


[aperfeito@alarm u-boot-tegra]$ ls *.bin
u-boot.bin  u-boot-dtb-tegra.bin  u-boot-nodtb-tegra.bin
u-boot-dtb.bin  u-boot-nodtb.bin  u-boot-tegra.bin


Now is the tip I'm asking you:
I have two suggestions on how to put this in the KERNEL partition of my USB.
  My USB has two partitions
   To 1st. KERNEL Name with 16 megabytes of space dev / sda6
   A 2st.  ROOFS   Name approximately 29 Gigabytes of space where I worked to 
compile the UbuntuXenial and Uboot-Tegra srcs kernel as you see in the email.



Sugestion : 1
mkimage -D "-I dts -O dtb -p 2048" -f kernel.its vmlinux.uimg
  dd if=/dev/zero of=bootloader.bin bs=512 count=1
  vbutil_kernel \
--pack vmlinux.kpart \
--version 1 \
--vmlinuz vmlinux.uimg \
--arch arm \
--keyblock kernel.keyblock \   --> How I do This  if necessary
--signprivate kernel_data_key.vbprivk \  --> How I do This if necessary
--config cmdline \ --> TXT file whit this config below
--bootloader bootloader.bin


  *   kernel.its adjust to files below as given to te src kernel 4.4.0-70
./arch/arm/boot/dts/tegra124-nyan-blaze.dtb
./arch/arm/boot/dts/tegra124-nyan-big.dtb
  *
___TXT CONFIG FILE 
__
  *
console=tty1 init=/sbin/init root=PARTUUID=%U/PARTNROFF=1 rootwait rw noinitrd 
lsm.module_locking=0  ## OR ###
  *
initrd=/boot/initrd.img-4.4.0-ARCH console=ttyS0,115200n8 console=tty1 
ignore_loglevel earlyprintk cgroup_enable=memory root=/dev/sda7

  ###  For config line need your sugestion with is the best.


Sugestion: 2

  I have to copy the kernel, generated initramfs, and dtb to the SDA6 partition 
and added the following kernel config to /dev/sda7/roofsparttion 
:/boot/extlinux/extlinux.conf


LABEL UbuntuXenial
 MENU LABEL UbuntuXenial on sda7 with 4.4 kernel
 LINUX /boot/vmlinuz-4.4.0
 FDT /boot/dtb/tegra124-nyan-big.dtb
 APPEND initrd=/boot/initrd.img-4.4.0-ARCH console=ttyS0,115200n8 console=tty1 
ignore_loglevel earlyprintk cgroup_enable=memory root=/dev/sda7


How to make U-boot-Tegra now Work with Kernel 4.4.x.x as v3.10.x.x Kernels 
booting on USB.

Best Regards
Perfeito Alexander









De: Tom Warren mailto:twar...@nvidia.com>>
Enviado: segunda-feira, 17 de julho de 2017 10:48
Para: Alexandre N. Perfeito
Cc: Simon Glass
Assunto: RE: Uboot compatible with board Tegra124-nyan-big (ChromeBook G3 HP 
14")


See ‘nyan-big_defconfig’. Added Simon to CC as he’s used this build quite a lot.



HTH,



Tom



From: Alexandre N. Perfeito 
[mailto:perfeit...@hotmail.com]
Sent: Wednesday, July 12, 2017 11:02 AM
To: Tom Warren mailto:twar...@nvidia.com>>
Subject: Uboot compatible with board Tegra124-nyan-big (ChromeBook G3 HP 14")



Tom,



   Hi,

  I woud like to know if exist u-boot/configs/defconfig-for-this-board , to 
build a Das-U-boot to running Mainline Kernel 4.4



Thanks



Best Regards



Perfeito,Alexander






This email message is for the sole use of the intended recipient(s) and may 
contain confidential information.  Any unauthorized review, use, disclosure or 
distribution is prohibited.  If you are not the intended recipient, please 
contact the sender by reply email and destroy all copies of the original 
message.


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

Re: [U-Boot] [PATCH 1/1] common: Move CONFIG_BOOTARGS to Kconfig

[Tom Rini]

On Mon, Jul 17, 2017 at 04:44:55PM +0300, Sam Protsenko wrote:

> Also introduce CONFIG_USE_BOOTARGS option so we can control if
> CONFIG_BOOTARGS defined at all.
> 
> Signed-off-by: Sam Protsenko 
[snip]
> +config USE_BOOTARGS
> + bool "Enable boot arguments"
> + default n

n is default, we don't need this.

[snip]
> diff --git a/configs/P1020MBG-PC_36BIT_SDCARD_defconfig 
> b/configs/P1020MBG-PC_36BIT_SDCARD_defconfig
> index e297a0da5b..88a795b42e 100644
> --- a/configs/P1020MBG-PC_36BIT_SDCARD_defconfig
> +++ b/configs/P1020MBG-PC_36BIT_SDCARD_defconfig
> @@ -13,6 +13,7 @@ CONFIG_OF_BOARD_SETUP=y
>  CONFIG_OF_STDOUT_VIA_ALIAS=y
>  CONFIG_SYS_EXTRA_OPTIONS="SDCARD"
>  CONFIG_BOOTDELAY=10
> +CONFIG_USE_BOOTARGS=y
>  CONFIG_BOARD_EARLY_INIT_F=y
>  CONFIG_SPL=y
>  CONFIG_SPL_ENV_SUPPORT=y

This is the first of a number of examples where USE_BOOTARGS is set to y
but there's no BOOTARGS set.  That doesn't make sense.  Looking at it a
bit more in detail, the conversion didn't happen right in cases where we
have:
#define CONFIG_BOOTARGS SOME_OTHER_DEFINE.

That may become tricky.  I'm going to post a horrible hack to help,
shortly.

-- 
Tom


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

Re: [U-Boot] mkimage Question

[Wolfgang Denk]

Dear Jeff,

In message <9CEC332718C5B346927BF91C9F4A66EAC03346@prgmbx01> you wrote:
> 
> New to U-Boot. It came installed with the BSP on a vendor MPC board
> to boot vxWorks. I have a requirement to use a checksum when
> downloading the vxWorks ELF image. Our development environ is Windows
> 7, using cross-compiler for target MPC. I have the source for U-Boot
> and see that mkimage is in the tools subdirectory, but I can't build
> all of U-boot for Windows (or even using the Wind River cross
> compiler tools).

The standard approach here would be to install Linux in a VM and use
this as a more developer-friendly environment.

On the other hand, why do you need mkimage at all?  There is a ton
of tools which can compute a standard CRC32 checksum (which is what
U-Boot uses), and U-Boot also has a "crc" command to verify the
checksum of a certain memory range.  So it may be a little bit more
typing, but the goal can be reached without compiling any new tools.

> Does denx have a compiled mkimage.exe for Windows?

Shudder... no, we don;t.  We are a 100% Windows-free company :-)

> Is there a way to build it by itself (without building all of U-boot)
> for Windows? I'm currently using mkimage.exe from CompuLab, but the
> company wants it from a more standard source, or preferably to build
> it ourselves. Thanks.

Windows is not exaclty a preferred or even well supported build
environment.  Today it is so easy to run a VM that this is probably
the way you should look at.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
I don't mind criticism. You know me. I've  never  been  one  to  take
offence  at  criticism. No one could say I'm the sort to take offence
at criticism -- Not twice, anyway. Not without blowing bubbles.
  - Terry Pratchett, _Witches Abroad_
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v2 2/7] efi_loader: implement multiple event support

[Heinrich Schuchardt]

Up to now the boot time supported only a single event.
This patch now allows four events.

Signed-off-by: Heinrich Schuchardt 
---
v2
add TPL constants
consider multiple events in efi_wait_for_event
move notification to new function efi_signal_event
---
 include/efi_api.h |  13 ++-
 include/efi_loader.h  |  24 ++
 lib/efi_loader/efi_boottime.c | 195 --
 3 files changed, 168 insertions(+), 64 deletions(-)

diff --git a/include/efi_api.h b/include/efi_api.h
index a1f822..a3b8e04576 100644
--- a/include/efi_api.h
+++ b/include/efi_api.h
@@ -28,8 +28,17 @@ enum efi_event_type {
EFI_TIMER_RELATIVE = 2
 };
 
-#define EVT_NOTIFY_WAIT0x0100
-#define EVT_NOTIFY_SIGNAL  0x0200
+#define EVT_TIMER  0x8000
+#define EVT_RUNTIME0x4000
+#define EVT_NOTIFY_WAIT0x0100
+#define EVT_NOTIFY_SIGNAL  0x0200
+#define EVT_SIGNAL_EXIT_BOOT_SERVICES  0x0201
+#define EVT_SIGNAL_VIRTUAL_ADDRESS_CHANGE  0x6202
+
+#define TPL_APPLICATION0x04
+#define TPL_CALLBACK   0x08
+#define TPL_NOTIFY 0x10
+#define TPL_HIGH_LEVEL 0x1F
 
 struct efi_event;
 
diff --git a/include/efi_loader.h b/include/efi_loader.h
index d7847d23e5..3d18bfbd2e 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -63,6 +63,30 @@ struct efi_object {
void *handle;
 };
 
+/**
+ * struct efi_event
+ *
+ * @type:  Type of event, see efi_create_event
+ * @notify_tpl:Task priority level of notifications
+ * @trigger_time:  Period of the timer
+ * @trigger_next:  Next time to trigger the timer
+ * @nofify_function:   Function to call when the event is triggered
+ * @notify_context:Data to be passed to the notify function
+ * @trigger_type:  Type of timer, see efi_set_timer
+ * @signaled:  The notify function was already called
+ */
+struct efi_event {
+   u32 type;
+   unsigned long notify_tpl;
+   void (EFIAPI *notify_function)(struct efi_event *event, void *context);
+   void *notify_context;
+   u64 trigger_next;
+   u64 trigger_time;
+   enum efi_event_type trigger_type;
+   int signaled;
+};
+
+
 /* This list contains all UEFI objects we know of */
 extern struct list_head efi_obj_list;
 
diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
index 0eda465359..a49acc8693 100644
--- a/lib/efi_loader/efi_boottime.c
+++ b/lib/efi_loader/efi_boottime.c
@@ -82,6 +82,18 @@ efi_status_t efi_exit_func(efi_status_t ret)
return ret;
 }
 
+static void efi_signal_event(struct efi_event *event)
+{
+   if (event->signaled)
+   return;
+   event->signaled = 1;
+   if (event->type & EVT_NOTIFY_SIGNAL) {
+   EFI_EXIT(EFI_SUCCESS);
+   event->notify_function(event, event->notify_context);
+   EFI_ENTRY("returning from notification function");
+   }
+}
+
 static efi_status_t efi_unsupported(const char *funcname)
 {
debug("EFI: App called into unimplemented function %s\n", funcname);
@@ -163,22 +175,10 @@ static efi_status_t EFIAPI efi_free_pool_ext(void *buffer)
 }
 
 /*
- * Our event capabilities are very limited. Only support a single
- * event to exist, so we don't need to maintain lists.
+ * Our event capabilities are very limited. Only a small limited
+ * number of events is allowed to coexist.
  */
-static struct efi_event {
-   enum efi_event_type type;
-   u32 trigger_type;
-   u32 trigger_time;
-   u64 trigger_next;
-   unsigned long notify_tpl;
-   void (EFIAPI *notify_function) (struct efi_event *event,
-   void *context);
-   void *notify_context;
-} efi_event = {
-   /* Disable timers on bootup */
-   .trigger_next = -1ULL,
-};
+static struct efi_event efi_events[16];
 
 static efi_status_t EFIAPI efi_create_event(
enum efi_event_type type, ulong notify_tpl,
@@ -187,13 +187,10 @@ static efi_status_t EFIAPI efi_create_event(
void *context),
void *notify_context, struct efi_event **event)
 {
+   int i;
+
EFI_ENTRY("%d, 0x%lx, %p, %p", type, notify_tpl, notify_function,
  notify_context);
-   if (efi_event.notify_function) {
-   /* We only support one event at a time */
-   return EFI_EXIT(EFI_OUT_OF_RESOURCES);
-   }
-
if (event == NULL)
return EFI_EXIT(EFI_INVALID_PARAMETER);
 
@@ -204,13 +201,20 @@ static efi_status_t EFIAPI efi_create_event(
notify_function == NULL)
return EFI_EXIT(EFI_INVALID_PARAMETER);
 
-   efi_event.type = type;
-   efi_event.notify_tpl = notify_tpl;
-   efi_event.no

[U-Boot] [PATCH v2 4/7] efi_loader: refactor efi_create_event

[Heinrich Schuchardt]

efi_create_event is refactored to make it possible to call it
internally. For EFI applications wrapper function
efi_create_event_ext is created.

Signed-off-by: Heinrich Schuchardt 
---
v2
new patch
---
 include/efi_loader.h  |  6 ++
 lib/efi_loader/efi_boottime.c | 35 +++
 2 files changed, 29 insertions(+), 12 deletions(-)

diff --git a/include/efi_loader.h b/include/efi_loader.h
index b922720068..c3640153e1 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -116,6 +116,12 @@ efi_status_t efi_exit_func(efi_status_t ret);
 void efi_runtime_relocate(ulong offset, struct efi_mem_desc *map);
 /* Call this to set the current device name */
 void efi_set_bootdev(const char *dev, const char *devnr, const char *path);
+/* Call this to create an event */
+efi_status_t efi_create_event(enum efi_event_type type, UINTN notify_tpl,
+ void (EFIAPI *notify_function) (
+   struct efi_event *event,
+   void *context),
+ void *notify_context, struct efi_event **event);
 
 /* Generic EFI memory allocator, call this to get memory */
 void *efi_alloc(uint64_t len, int memory_type);
diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
index c3c00b7a87..e38da35a8a 100644
--- a/lib/efi_loader/efi_boottime.c
+++ b/lib/efi_loader/efi_boottime.c
@@ -180,26 +180,23 @@ static efi_status_t EFIAPI efi_free_pool_ext(void *buffer)
  */
 static struct efi_event efi_events[16];
 
-static efi_status_t EFIAPI efi_create_event(
-   enum efi_event_type type, UINTN notify_tpl,
-   void (EFIAPI *notify_function) (
+efi_status_t efi_create_event(enum efi_event_type type, UINTN notify_tpl,
+ void (EFIAPI *notify_function) (
struct efi_event *event,
void *context),
-   void *notify_context, struct efi_event **event)
+ void *notify_context, struct efi_event **event)
 {
int i;
 
-   EFI_ENTRY("%d, 0x%zx, %p, %p", type, notify_tpl, notify_function,
- notify_context);
if (event == NULL)
-   return EFI_EXIT(EFI_INVALID_PARAMETER);
+   return EFI_INVALID_PARAMETER;
 
if ((type & EVT_NOTIFY_SIGNAL) && (type & EVT_NOTIFY_WAIT))
-   return EFI_EXIT(EFI_INVALID_PARAMETER);
+   return EFI_INVALID_PARAMETER;
 
if ((type & (EVT_NOTIFY_SIGNAL|EVT_NOTIFY_WAIT)) &&
notify_function == NULL)
-   return EFI_EXIT(EFI_INVALID_PARAMETER);
+   return EFI_INVALID_PARAMETER;
 
for (i = 0; i < ARRAY_SIZE(efi_events); ++i) {
if (efi_events[i].type)
@@ -212,11 +209,25 @@ static efi_status_t EFIAPI efi_create_event(
efi_events[i].trigger_next = -1ULL;
efi_events[i].signaled = 0;
*event = &efi_events[i];
-   return EFI_EXIT(EFI_SUCCESS);
+   return EFI_SUCCESS;
}
-   return EFI_EXIT(EFI_OUT_OF_RESOURCES);
+   return EFI_OUT_OF_RESOURCES;
 }
 
+static efi_status_t EFIAPI efi_create_event_ext(
+   enum efi_event_type type, UINTN notify_tpl,
+   void (EFIAPI *notify_function) (
+   struct efi_event *event,
+   void *context),
+   void *notify_context, struct efi_event **event)
+{
+   EFI_ENTRY("%d, 0x%zx, %p, %p", type, notify_tpl, notify_function,
+ notify_context);
+   return EFI_EXIT(efi_create_event(type, notify_tpl, notify_function,
+notify_context, event));
+}
+
+
 /*
  * Our timers have to work without interrupts, so we check whenever keyboard
  * input or disk accesses happen if enough time elapsed for it to fire.
@@ -1100,7 +,7 @@ static const struct efi_boot_services efi_boot_services = 
{
.get_memory_map = efi_get_memory_map_ext,
.allocate_pool = efi_allocate_pool_ext,
.free_pool = efi_free_pool_ext,
-   .create_event = efi_create_event,
+   .create_event = efi_create_event_ext,
.set_timer = efi_set_timer,
.wait_for_event = efi_wait_for_event,
.signal_event = efi_signal_event_ext,
-- 
2.13.2

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

[U-Boot] [PATCH v2 0/7] efi_loader: event services

[Heinrich Schuchardt]

Currently U-Boot only allows a single event. This is sufficient to run 
grub but not for other workloads as iPXE.

The EFI_SIMPLE_TEXT_INPUT_PROTOCOL requires an event WaitForKey. This
is used for instance by the iPXE shell.

The 1st patch replaces void * by struct efi_event * where applicable.
This renders the code more readable.

The 2nd patch implements the support for multiple events.

The 3rd patch corrects the size of the tpl level function parameters to
match UINTN.

The 4th patch makes efi_create_event internally callable.

The 5th patch makes efi_set_timer internally callable.

The 6th patch sets up events to track console input and to signal this
to the WaitForKey event.

The 7th patch implements the conversion of multiples of 100ns to
multiples of 1000 ns in efi_set_timer.

---
v2
Patches 1, 3, 4, 5, 7 are new.
A patch to silence debug output for WaitForKey has been dropped.
Patches 2 and 6 are completely reworked compared to v1 of the patch
series.
Multiple events in WaitForEvent are addressed.
The serial console handling is move to dynamically allocated events.
---

Heinrich Schuchardt (7):
  efi_loader: use struct efi_event * instead of void *
  efi_loader: implement multiple event support
  efi_loader: correct size for tpl level
  efi_loader: refactor efi_create_event
  efi_loader: refactor efi_set_timer
  efi_console: set up events
  efi_loader: correctly implement 100ns conversion

 cmd/bootefi.c |   1 +
 include/efi_api.h |  44 ---
 include/efi_loader.h  |  39 +-
 lib/efi_loader/efi_boottime.c | 298 +-
 lib/efi_loader/efi_console.c  |  40 +-
 5 files changed, 316 insertions(+), 106 deletions(-)

-- 
2.13.2

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

[U-Boot] [PATCH v2 5/7] efi_loader: refactor efi_set_timer

[Heinrich Schuchardt]

efi_set_timer is refactored to make the function callable internally.
Wrapper function efi_set_timer_ext is provided for EFI applications.

Signed-off-by: Heinrich Schuchardt 
---
v2
new patch
---
 include/efi_loader.h  |  3 +++
 lib/efi_loader/efi_boottime.c | 21 +
 2 files changed, 16 insertions(+), 8 deletions(-)

diff --git a/include/efi_loader.h b/include/efi_loader.h
index c3640153e1..342e960d14 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -122,6 +122,9 @@ efi_status_t efi_create_event(enum efi_event_type type, 
UINTN notify_tpl,
struct efi_event *event,
void *context),
  void *notify_context, struct efi_event **event);
+/* Call this to set a timer */
+efi_status_t efi_set_timer(struct efi_event *event, int type,
+  uint64_t trigger_time);
 
 /* Generic EFI memory allocator, call this to get memory */
 void *efi_alloc(uint64_t len, int memory_type);
diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
index e38da35a8a..7f10b6090a 100644
--- a/lib/efi_loader/efi_boottime.c
+++ b/lib/efi_loader/efi_boottime.c
@@ -253,16 +253,14 @@ void efi_timer_check(void)
WATCHDOG_RESET();
 }
 
-static efi_status_t EFIAPI efi_set_timer(struct efi_event *event, int type,
-uint64_t trigger_time)
+efi_status_t efi_set_timer(struct efi_event *event, int type,
+  uint64_t trigger_time)
 {
/* We don't have 64bit division available everywhere, so limit timer
 * distances to 32bit bits. */
u32 trigger32 = trigger_time;
int i;
 
-   EFI_ENTRY("%p, %d, %"PRIx64, event, type, trigger_time);
-
if (trigger32 < trigger_time) {
printf("WARNING: Truncating timer from %"PRIx64" to %x\n",
   trigger_time, trigger32);
@@ -284,13 +282,20 @@ static efi_status_t EFIAPI efi_set_timer(struct efi_event 
*event, int type,
timer_get_us() + (trigger32 / 10);
break;
default:
-   return EFI_EXIT(EFI_INVALID_PARAMETER);
+   return EFI_INVALID_PARAMETER;
}
event->trigger_type = type;
event->trigger_time = trigger_time;
-   return EFI_EXIT(EFI_SUCCESS);
+   return EFI_SUCCESS;
}
-   return EFI_EXIT(EFI_INVALID_PARAMETER);
+   return EFI_INVALID_PARAMETER;
+}
+
+static efi_status_t EFIAPI efi_set_timer_ext(struct efi_event *event, int type,
+uint64_t trigger_time)
+{
+   EFI_ENTRY("%p, %d, %"PRIx64, event, type, trigger_time);
+   return EFI_EXIT(efi_set_timer(event, type, trigger_time));
 }
 
 static efi_status_t EFIAPI efi_wait_for_event(unsigned long num_events,
@@ -1112,7 +1117,7 @@ static const struct efi_boot_services efi_boot_services = 
{
.allocate_pool = efi_allocate_pool_ext,
.free_pool = efi_free_pool_ext,
.create_event = efi_create_event_ext,
-   .set_timer = efi_set_timer,
+   .set_timer = efi_set_timer_ext,
.wait_for_event = efi_wait_for_event,
.signal_event = efi_signal_event_ext,
.close_event = efi_close_event,
-- 
2.13.2

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

[U-Boot] [PATCH v2 6/7] efi_console: set up events

[Heinrich Schuchardt]

Set up a timer event and the WaitForKey event.
In the notify function of the timer event check for console input
and signal the WaitForKey event accordingly.

Signed-off-by: Heinrich Schuchardt 
---
v2
dynamically register events to monitor the serial console
input
---
 cmd/bootefi.c |  1 +
 include/efi_loader.h  |  6 +-
 lib/efi_loader/efi_boottime.c |  2 +-
 lib/efi_loader/efi_console.c  | 40 +++-
 4 files changed, 46 insertions(+), 3 deletions(-)

diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index 966d001d41..cf717564c4 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -112,6 +112,7 @@ static void efi_init_obj_list(void)
efi_obj_list_initalized = 1;
list_add_tail(&loaded_image_info_obj.link, &efi_obj_list);
list_add_tail(&bootefi_device_obj.link, &efi_obj_list);
+   efi_console_register();
 #ifdef CONFIG_PARTITIONS
efi_disk_register();
 #endif
diff --git a/include/efi_loader.h b/include/efi_loader.h
index 342e960d14..2abb6b87e1 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -26,7 +26,7 @@ extern struct efi_runtime_services efi_runtime_services;
 extern struct efi_system_table systab;
 
 extern const struct efi_simple_text_output_protocol efi_con_out;
-extern const struct efi_simple_input_interface efi_con_in;
+extern struct efi_simple_input_interface efi_con_in;
 extern const struct efi_console_control_protocol efi_console_control;
 extern const struct efi_device_path_to_text_protocol efi_device_path_to_text;
 
@@ -90,6 +90,8 @@ struct efi_event {
 /* This list contains all UEFI objects we know of */
 extern struct list_head efi_obj_list;
 
+/* Called by bootefi to make console interface available */
+int efi_console_register(void);
 /* Called by bootefi to make all disk storage accessible as EFI objects */
 int efi_disk_register(void);
 /* Called by bootefi to make GOP (graphical) interface available */
@@ -125,6 +127,8 @@ efi_status_t efi_create_event(enum efi_event_type type, 
UINTN notify_tpl,
 /* Call this to set a timer */
 efi_status_t efi_set_timer(struct efi_event *event, int type,
   uint64_t trigger_time);
+/* Call this to signal an event */
+void efi_signal_event(struct efi_event *event);
 
 /* Generic EFI memory allocator, call this to get memory */
 void *efi_alloc(uint64_t len, int memory_type);
diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
index 7f10b6090a..137a4036c6 100644
--- a/lib/efi_loader/efi_boottime.c
+++ b/lib/efi_loader/efi_boottime.c
@@ -82,7 +82,7 @@ efi_status_t efi_exit_func(efi_status_t ret)
return ret;
 }
 
-static void efi_signal_event(struct efi_event *event)
+void efi_signal_event(struct efi_event *event)
 {
if (event->signaled)
return;
diff --git a/lib/efi_loader/efi_console.c b/lib/efi_loader/efi_console.c
index 8ef7326fef..dbe98ac08b 100644
--- a/lib/efi_loader/efi_console.c
+++ b/lib/efi_loader/efi_console.c
@@ -421,8 +421,46 @@ static efi_status_t EFIAPI efi_cin_read_key_stroke(
return EFI_EXIT(EFI_SUCCESS);
 }
 
-const struct efi_simple_input_interface efi_con_in = {
+struct efi_simple_input_interface efi_con_in = {
.reset = efi_cin_reset,
.read_key_stroke = efi_cin_read_key_stroke,
.wait_for_key = NULL,
 };
+
+static struct efi_event *console_timer_event;
+
+static void efi_key_notify(struct efi_event *event, void *context)
+{
+}
+
+static void efi_console_timer_notify(struct efi_event *event, void *context)
+{
+   EFI_ENTRY("%p, %p", event, context);
+   if (tstc())
+   efi_signal_event(efi_con_in.wait_for_key);
+   EFI_EXIT(EFI_SUCCESS);
+}
+
+/* This gets called from do_bootefi_exec(). */
+int efi_console_register(void)
+{
+   efi_status_t r;
+   r = efi_create_event(EVT_NOTIFY_WAIT, TPL_CALLBACK,
+efi_key_notify, NULL, &efi_con_in.wait_for_key);
+   if (r != EFI_SUCCESS) {
+   printf("ERROR: Failed to register WaitForKey event\n");
+   return r;
+   }
+   r = efi_create_event(EVT_TIMER | EVT_NOTIFY_SIGNAL, TPL_CALLBACK,
+efi_console_timer_notify, NULL,
+&console_timer_event);
+   if (r != EFI_SUCCESS) {
+   printf("ERROR: Failed to register console event\n");
+   return r;
+   }
+   /* 5000 ns cycle is sufficient for 2 MBaud */
+   r = efi_set_timer(console_timer_event, EFI_TIMER_PERIODIC, 50);
+   if (r != EFI_SUCCESS)
+   printf("ERROR: Failed to set console timer\n");
+   return r;
+}
-- 
2.13.2

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

[U-Boot] [PATCH v2 7/7] efi_loader: correctly implement 100ns conversion

[Heinrich Schuchardt]

In efi_set_timer we receive the trigger time in intervals of 100 ns.
We should convert it to intervals of 1000 ns by 64bit division.

The patch supplies function efi_div10 that uses multiplication to
implement the missing 64 bit division.

Signed-off-by: Heinrich Schuchardt 
---
v2
move this to separate patch
implement a 64bit division by 10
---
 lib/efi_loader/efi_boottime.c | 48 +++
 1 file changed, 39 insertions(+), 9 deletions(-)

diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
index 137a4036c6..c58066474e 100644
--- a/lib/efi_loader/efi_boottime.c
+++ b/lib/efi_loader/efi_boottime.c
@@ -82,6 +82,39 @@ efi_status_t efi_exit_func(efi_status_t ret)
return ret;
 }
 
+/* Low 32 bit */
+#define EFI_LOW32(a) (a & 0xULL)
+/* High 32 bit */
+#define EFI_HIGH32(a) (a >> 32)
+
+/*
+ * 64bit division by 10 implemented as multiplication by 1 / 10
+ *
+ * Decimals of one tenth: 0x1 / 0xA = 0x0.1...
+ */
+#define EFI_TENTH 0x199A
+static u64 efi_div10(u64 a)
+{
+   u64 prod;
+   u64 rem;
+   u64 ret;
+
+   ret  = EFI_HIGH32(a) * EFI_HIGH32(EFI_TENTH);
+   prod = EFI_HIGH32(a) * EFI_LOW32(EFI_TENTH);
+   rem  = EFI_LOW32(prod);
+   ret += EFI_HIGH32(prod);
+   prod = EFI_LOW32(a) * EFI_HIGH32(EFI_TENTH);
+   rem += EFI_LOW32(prod);
+   ret += EFI_HIGH32(prod);
+   prod = EFI_LOW32(a) * EFI_LOW32(EFI_TENTH);
+   rem += EFI_HIGH32(prod);
+   ret += EFI_HIGH32(rem);
+   /* Round to nearest integer */
+   if (rem >= (1 << 31))
+   ++ret;
+   return ret;
+}
+
 void efi_signal_event(struct efi_event *event)
 {
if (event->signaled)
@@ -245,7 +277,7 @@ void efi_timer_check(void)
continue;
if (efi_events[i].trigger_type == EFI_TIMER_PERIODIC) {
efi_events[i].trigger_next +=
-   efi_events[i].trigger_time / 10;
+   efi_events[i].trigger_time;
efi_events[i].signaled = 0;
}
efi_signal_event(&efi_events[i]);
@@ -256,15 +288,13 @@ void efi_timer_check(void)
 efi_status_t efi_set_timer(struct efi_event *event, int type,
   uint64_t trigger_time)
 {
-   /* We don't have 64bit division available everywhere, so limit timer
-* distances to 32bit bits. */
-   u32 trigger32 = trigger_time;
int i;
 
-   if (trigger32 < trigger_time) {
-   printf("WARNING: Truncating timer from %"PRIx64" to %x\n",
-  trigger_time, trigger32);
-   }
+   /*
+* The parameter defines a multiple of 100ns.
+* We use multiples of 1000ns. So divide by 10.
+*/
+   trigger_time = efi_div10(trigger_time);
 
for (i = 0; i < ARRAY_SIZE(efi_events); ++i) {
if (event != &efi_events[i])
@@ -279,7 +309,7 @@ efi_status_t efi_set_timer(struct efi_event *event, int 
type,
case EFI_TIMER_PERIODIC:
case EFI_TIMER_RELATIVE:
event->trigger_next =
-   timer_get_us() + (trigger32 / 10);
+   timer_get_us() + trigger_time;
break;
default:
return EFI_INVALID_PARAMETER;
-- 
2.13.2

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

[U-Boot] [PATCH v2 3/7] efi_loader: correct size for tpl level

[Heinrich Schuchardt]

The UEFI standard defines the type for the tpl level as EFI_TPL
alias UINTN.

UINTN is an integer is defined as an unsigned integer of native
width. So we can use size_t for the definition.

Signed-off-by: Heinrich Schuchardt 
---
v2
new patch
---
 include/efi_api.h |  8 +---
 include/efi_loader.h  |  2 +-
 lib/efi_loader/efi_boottime.c | 12 ++--
 3 files changed, 12 insertions(+), 10 deletions(-)

diff --git a/include/efi_api.h b/include/efi_api.h
index a3b8e04576..8e5342c79c 100644
--- a/include/efi_api.h
+++ b/include/efi_api.h
@@ -28,6 +28,8 @@ enum efi_event_type {
EFI_TIMER_RELATIVE = 2
 };
 
+#define UINTN size_t
+
 #define EVT_TIMER  0x8000
 #define EVT_RUNTIME0x4000
 #define EVT_NOTIFY_WAIT0x0100
@@ -45,8 +47,8 @@ struct efi_event;
 /* EFI Boot Services table */
 struct efi_boot_services {
struct efi_table_hdr hdr;
-   efi_status_t (EFIAPI *raise_tpl)(unsigned long new_tpl);
-   void (EFIAPI *restore_tpl)(unsigned long old_tpl);
+   efi_status_t (EFIAPI *raise_tpl)(UINTN new_tpl);
+   void (EFIAPI *restore_tpl)(UINTN old_tpl);
 
efi_status_t (EFIAPI *allocate_pages)(int, int, unsigned long,
  efi_physical_addr_t *);
@@ -58,7 +60,7 @@ struct efi_boot_services {
efi_status_t (EFIAPI *free_pool)(void *);
 
efi_status_t (EFIAPI *create_event)(enum efi_event_type type,
-   unsigned long notify_tpl,
+   UINTN notify_tpl,
void (EFIAPI *notify_function) (
struct efi_event *event,
void *context),
diff --git a/include/efi_loader.h b/include/efi_loader.h
index 3d18bfbd2e..b922720068 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -77,7 +77,7 @@ struct efi_object {
  */
 struct efi_event {
u32 type;
-   unsigned long notify_tpl;
+   UINTN notify_tpl;
void (EFIAPI *notify_function)(struct efi_event *event, void *context);
void *notify_context;
u64 trigger_next;
diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
index a49acc8693..c3c00b7a87 100644
--- a/lib/efi_loader/efi_boottime.c
+++ b/lib/efi_loader/efi_boottime.c
@@ -105,15 +105,15 @@ static int guidcmp(const efi_guid_t *g1, const efi_guid_t 
*g2)
return memcmp(g1, g2, sizeof(efi_guid_t));
 }
 
-static unsigned long EFIAPI efi_raise_tpl(unsigned long new_tpl)
+static unsigned long EFIAPI efi_raise_tpl(UINTN new_tpl)
 {
-   EFI_ENTRY("0x%lx", new_tpl);
+   EFI_ENTRY("0x%zx", new_tpl);
return EFI_EXIT(0);
 }
 
-static void EFIAPI efi_restore_tpl(unsigned long old_tpl)
+static void EFIAPI efi_restore_tpl(UINTN old_tpl)
 {
-   EFI_ENTRY("0x%lx", old_tpl);
+   EFI_ENTRY("0x%zx", old_tpl);
EFI_EXIT(efi_unsupported(__func__));
 }
 
@@ -181,7 +181,7 @@ static efi_status_t EFIAPI efi_free_pool_ext(void *buffer)
 static struct efi_event efi_events[16];
 
 static efi_status_t EFIAPI efi_create_event(
-   enum efi_event_type type, ulong notify_tpl,
+   enum efi_event_type type, UINTN notify_tpl,
void (EFIAPI *notify_function) (
struct efi_event *event,
void *context),
@@ -189,7 +189,7 @@ static efi_status_t EFIAPI efi_create_event(
 {
int i;
 
-   EFI_ENTRY("%d, 0x%lx, %p, %p", type, notify_tpl, notify_function,
+   EFI_ENTRY("%d, 0x%zx, %p, %p", type, notify_tpl, notify_function,
  notify_context);
if (event == NULL)
return EFI_EXIT(EFI_INVALID_PARAMETER);
-- 
2.13.2

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

[U-Boot] [PATCH v2 1/7] efi_loader: use struct efi_event * instead of void *

[Heinrich Schuchardt]

In our implementation the internal structure of events is known.
So use the known type instead of void.

Signed-off-by: Heinrich Schuchardt 
---
v2
new patch
---
 include/efi_api.h | 23 +--
 lib/efi_loader/efi_boottime.c | 25 ++---
 2 files changed, 27 insertions(+), 21 deletions(-)

diff --git a/include/efi_api.h b/include/efi_api.h
index ea63e80b47..a1f822 100644
--- a/include/efi_api.h
+++ b/include/efi_api.h
@@ -31,6 +31,8 @@ enum efi_event_type {
 #define EVT_NOTIFY_WAIT0x0100
 #define EVT_NOTIFY_SIGNAL  0x0200
 
+struct efi_event;
+
 /* EFI Boot Services table */
 struct efi_boot_services {
struct efi_table_hdr hdr;
@@ -48,16 +50,17 @@ struct efi_boot_services {
 
efi_status_t (EFIAPI *create_event)(enum efi_event_type type,
unsigned long notify_tpl,
-   void (EFIAPI *notify_function) (void *event,
-   void *context),
-   void *notify_context, void **event);
-   efi_status_t (EFIAPI *set_timer)(void *event, int type,
+   void (EFIAPI *notify_function) (
+   struct efi_event *event,
+   void *context),
+   void *notify_context, struct efi_event **event);
+   efi_status_t (EFIAPI *set_timer)(struct efi_event *event, int type,
uint64_t trigger_time);
efi_status_t (EFIAPI *wait_for_event)(unsigned long number_of_events,
-   void *event, unsigned long *index);
-   efi_status_t (EFIAPI *signal_event)(void *event);
-   efi_status_t (EFIAPI *close_event)(void *event);
-   efi_status_t (EFIAPI *check_event)(void *event);
+   struct efi_event **event, unsigned long *index);
+   efi_status_t (EFIAPI *signal_event)(struct efi_event *event);
+   efi_status_t (EFIAPI *close_event)(struct efi_event *event);
+   efi_status_t (EFIAPI *check_event)(struct efi_event *event);
 #define EFI_NATIVE_INTERFACE   0x
efi_status_t (EFIAPI *install_protocol_interface)(
void **handle, efi_guid_t *protocol,
@@ -71,7 +74,7 @@ struct efi_boot_services {
   void **);
void *reserved;
efi_status_t (EFIAPI *register_protocol_notify)(
-   efi_guid_t *protocol, void *event,
+   efi_guid_t *protocol, struct efi_event *event,
void **registration);
efi_status_t (EFIAPI *locate_handle)(
enum efi_locate_search_type search_type,
@@ -374,7 +377,7 @@ struct efi_simple_input_interface {
efi_status_t(EFIAPI *read_key_stroke)(
struct efi_simple_input_interface *this,
struct efi_input_key *key);
-   void *wait_for_key;
+   struct efi_event *wait_for_key;
 };
 
 #define CONSOLE_CONTROL_GUID \
diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
index fa264f3f3d..0eda465359 100644
--- a/lib/efi_loader/efi_boottime.c
+++ b/lib/efi_loader/efi_boottime.c
@@ -166,13 +166,14 @@ static efi_status_t EFIAPI efi_free_pool_ext(void *buffer)
  * Our event capabilities are very limited. Only support a single
  * event to exist, so we don't need to maintain lists.
  */
-static struct {
+static struct efi_event {
enum efi_event_type type;
u32 trigger_type;
u32 trigger_time;
u64 trigger_next;
unsigned long notify_tpl;
-   void (EFIAPI *notify_function) (void *event, void *context);
+   void (EFIAPI *notify_function) (struct efi_event *event,
+   void *context);
void *notify_context;
 } efi_event = {
/* Disable timers on bootup */
@@ -181,9 +182,10 @@ static struct {
 
 static efi_status_t EFIAPI efi_create_event(
enum efi_event_type type, ulong notify_tpl,
-   void (EFIAPI *notify_function) (void *event,
-   void *context),
-   void *notify_context, void **event)
+   void (EFIAPI *notify_function) (
+   struct efi_event *event,
+   void *context),
+   void *notify_context, struct efi_event **event)
 {
EFI_ENTRY("%d, 0x%lx, %p, %p", type, notify_tpl, notify_function,
  notify_context);
@@ -231,7 +233,7 @@ void efi_timer_check(void)
WATCHDOG_RESET();
 }
 
-static efi_status_t EFIAPI efi_set_timer(void *event, int type,
+static efi_status_t EFIAPI efi_set_timer(struct efi_event *event, int type,
 uint64_t trigger_time)
 {
/* We don't have 64bit division availabl

[U-Boot] [PATCH] FIT: List kernel_noload in the list of types

[Tom Rini]

In the source_file_format.txt file we talk about how to construct a
valid FIT image.  While it already says to look at the source for the
full list, add kernel_noload to the explicit list of types.  This is
arguably the most important type to use as most often we are including a
kernel that will run from wherever it is loaded into memory and execute.

This for example, allows you to create a single FIT image for Linux that
can be used on both OMAP and i.MX devices as the kernel will not need to
be moved in memory.

Signed-off-by: Tom Rini 
---
 doc/uImage.FIT/source_file_format.txt | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/doc/uImage.FIT/source_file_format.txt 
b/doc/uImage.FIT/source_file_format.txt
index afff301c8859..136d3d7078ee 100644
--- a/doc/uImage.FIT/source_file_format.txt
+++ b/doc/uImage.FIT/source_file_format.txt
@@ -159,8 +159,8 @@ the '/images' node should have the following layout:
   Mandatory properties:
   - description : Textual description of the component sub-image
   - type : Name of component sub-image type, supported types are:
-"standalone", "kernel", "ramdisk", "firmware", "script", "filesystem",
-"flat_dt" and others (see uimage_type in common/image.c).
+"standalone", "kernel", "kernel_noload", "ramdisk", "firmware", "script",
+"filesystem", "flat_dt" and others (see uimage_type in common/image.c).
   - data : Path to the external file which contains this node's binary data.
   - compression : Compression used by included data. Supported compressions
 are "gzip" and "bzip2". If no compression is used compression property
-- 
1.9.1

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

Re: [U-Boot] [PATCH] net: Mark the ip_udp_hdr struct as packed

[Joe Hershberger]

Hi Maxime,

On Wed, Jul 12, 2017 at 9:34 AM, Maxime Ripard
 wrote:
> The -mno-unaligned-access flag used on ARM to prevent GCC from generating
> unaligned accesses (obviously) will only do so on packed structures.
>
> It seems like gcc 7.1 is a bit stricter than previous gcc versions on this,
> and using it lead to data abort for unaligned accesses when generating
> network traffic.
>
> Fix this by adding the packed attribute to the ip_udp_hdr structure in
> order to let GCC do its job.
>
> Signed-off-by: Maxime Ripard 
> ---
>  include/net.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/net.h b/include/net.h
> index 997db9210a8f..7b815afffafa 100644
> --- a/include/net.h
> +++ b/include/net.h
> @@ -390,7 +390,7 @@ struct ip_udp_hdr {
> u16 udp_dst;/* UDP destination port */
> u16 udp_len;/* Length of UDP packet */
> u16 udp_xsum;   /* Checksum */
> -};
> +} __attribute__ ((packed));

Do you have an example of why this is unaligned? It seems that the
structure itself is naturally packed (each element is aligned to its
access size). It seems the only time this would hit a dabort is if the
head of the buffer is not 32-bit aligned. Maybe we should address the
place where that is the case instead of forcing byte-wise accesses in
general for this structure?

Thanks,
-Joe

>  #define IP_UDP_HDR_SIZE(sizeof(struct ip_udp_hdr))
>  #define UDP_HDR_SIZE   (IP_UDP_HDR_SIZE - IP_HDR_SIZE)
> --
> 2.13.0
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] configs: ti: armv7: Fixes bug in fit_loadaddr for ramfs boot

[Tom Rini]

On Tue, Jul 18, 2017 at 10:10:15AM -0500, Andrew F. Davis wrote:
> On 07/18/2017 07:59 AM, Tom Rini wrote:
> > On Mon, Jul 17, 2017 at 01:01:36PM -0500, Andrew F. Davis wrote:
> >> From: Madan Srinivas 
> >>
> >> The load address of ramdisk, rdaddr is 0x8808 and fit_loadaddr
> >> is defined as 0x8800. This leaves only 512Kbytes for the
> >> fit image. When the FIT images are larger than this, it will
> >> overwite the ramdisk and cause the boot to fail.
> >>
> >> For eg, The K2 HS fit images are a few MB and end up overwriting
> >> the ramdsk. This patch moves the fit_loadaddr to 0x8700,
> >> leaving a 16MB window for the fit image. This memory can be
> >> reclaimed once the kernel starts running.
> >>
> >> Signed-off-by: Madan Srinivas 
> >> ---
> >>  include/configs/ti_armv7_common.h | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/include/configs/ti_armv7_common.h 
> >> b/include/configs/ti_armv7_common.h
> >> index a4676d3a7f..16ea22857f 100644
> >> --- a/include/configs/ti_armv7_common.h
> >> +++ b/include/configs/ti_armv7_common.h
> >> @@ -53,7 +53,7 @@
> >>  
> >>  #define DEFAULT_FIT_TI_ARGS \
> >>"boot_fit=0\0" \
> >> -  "fit_loadaddr=0x8800\0" \
> >> +  "fit_loadaddr=0x8700\0" \
> >>"fit_bootfile=fitImage\0" \
> >>"update_to_fit=setenv loadaddr ${fit_loadaddr}; setenv bootfile 
> >> ${fit_bootfile}\0" \
> >>"loadfit=run args_mmc; bootm ${loadaddr}#${fdtfile};\0" \
> > 
> > OK, why is fit_loadaddr different from loadaddr?
> > 
> 
> Are you asking why they are different addresses? They need to be or the
> kernel will be unpacked from the FIT onto the FIT image (I think).

And here we get to one of the sad parts about FIT images.  If you
construct your FIT with:
kernel@1 { 
...
type = "kernel_noload";

Then you can do what I describe, load the FIT image to $loadaddr and
this even works for when you include a ramdisk in the image too.  Now,
if you're using type = "kernel" which I suspect you are, it then depends
on if there is overlap between where the FIT image is loaded into memory
and where you set load/entry of the kernel inside of the FIT image.

And, I assume it's intentional that you're using a FIT image for kernel
and device tree, but separate initrd file, and we wouldn't address the
issue by including the ramdisk into the FIT itself.

-- 
Tom


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

Re: [U-Boot] [PATCH v2 1/1] meson-gx: reserved memory regions

[Heinrich Schuchardt]

Hello Tom, hello Albert,

I did not see any objections.

Can this be merged?
https://patchwork.ozlabs.org/patch/774142/

Best regards

Heinrich


On 06/09/2017 10:13 PM, Heinrich Schuchardt wrote:
> The Odroid C2 has two GiB of memory with two reserved regions.
> reg = <0x0 0x0 0x0 0x100>;
> reg = <0x0 0x1000 0x0 0x20>;
> 
> Patch
> bfcef28ae4cf (arm: add initial support for Amlogic Meson and
> ODROID-C2) provided function dram_init_banksize to reserve the
> first 16 MiB of RAM for firmware in function dram_init_banksize
> in arch/arm/mach-meson/board.c and defined
> CONFIG_NR_DRAM_BANKS = 1.
> 
> With this patch dram_init_banksize is changed to additionally
> reserve the 2MiB region for the ARM Trusted Firmware (BL31).
> CONFIG_NR_DRAM_BANKS is set to 2.
> 
> Cc: Andreas Färber 
> Signed-off-by: Heinrich Schuchardt 
> ---
> v2:
>   Do not change the dtb but the board file as
>   suggested by Andreas Färber.
> ---
>  arch/arm/mach-meson/board.c | 8 +---
>  include/configs/meson-gxbb-common.h | 2 +-
>  2 files changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm/mach-meson/board.c b/arch/arm/mach-meson/board.c
> index 273dbeb020..e89c6aace9 100644
> --- a/arch/arm/mach-meson/board.c
> +++ b/arch/arm/mach-meson/board.c
> @@ -37,9 +37,11 @@ int dram_init(void)
>  int dram_init_banksize(void)
>  {
>   /* Reserve first 16 MiB of RAM for firmware */
> - gd->bd->bi_dram[0].start = CONFIG_SYS_SDRAM_BASE + (16 * 1024 * 1024);
> - gd->bd->bi_dram[0].size = gd->ram_size - (16 * 1024 * 1024);
> -
> + gd->bd->bi_dram[0].start = 0x100;
> + gd->bd->bi_dram[0].size  = 0xf00;
> + /* Reserve 2 MiB for ARM Trusted Firmware (BL31) */
> + gd->bd->bi_dram[1].start = 0x1000;
> + gd->bd->bi_dram[1].size  = gd->ram_size - 0x1020;
>   return 0;
>  }
>  
> diff --git a/include/configs/meson-gxbb-common.h 
> b/include/configs/meson-gxbb-common.h
> index 89e3807a14..ed55f441a4 100644
> --- a/include/configs/meson-gxbb-common.h
> +++ b/include/configs/meson-gxbb-common.h
> @@ -10,7 +10,7 @@
>  
>  #define CONFIG_CPU_ARMV8
>  #define CONFIG_REMAKE_ELF
> -#define CONFIG_NR_DRAM_BANKS 1
> +#define CONFIG_NR_DRAM_BANKS 2
>  #define CONFIG_ENV_IS_NOWHERE1
>  #define CONFIG_ENV_SIZE  0x2000
>  #define CONFIG_SYS_MAXARGS   32
> 

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

Re: [U-Boot] [PATCH v2 01/12] efi_loader: refactor efi_open_protocol

[Heinrich Schuchardt]

On 07/18/2017 03:12 PM, Alexander Graf wrote:
> On 07/11/2017 10:06 PM, Heinrich Schuchardt wrote:
>> efi_open_protocol was implemented to call a protocol specific open
>> function to retrieve the protocol interface.
>>
>> The UEFI specification does not know of such a function.
>>
>> It is not possible to implement InstallProtocolInterface with the
>> current design.
>>
>> With the patch the protocol interface itself is stored in the list
>> of installed protocols of an efi_object instead of an open function.
>>
>> Signed-off-by: Heinrich Schuchardt 
>> ---
>> v2
>> Remove implementation of efi_return_handle.
>> ---
>>   cmd/bootefi.c | 14 +++---
>>   include/efi_loader.h  | 17 ++---
>>   lib/efi_loader/efi_boottime.c | 18 ++
>>   lib/efi_loader/efi_disk.c | 29 +++--
>>   lib/efi_loader/efi_gop.c  |  2 +-
>>   lib/efi_loader/efi_image_loader.c |  8 
>>   lib/efi_loader/efi_net.c  | 30 +++---
>>   7 files changed, 26 insertions(+), 92 deletions(-)
>>
>> diff --git a/cmd/bootefi.c b/cmd/bootefi.c
>> index 7ddeead671..7cf0129a18 100644
>> --- a/cmd/bootefi.c
>> +++ b/cmd/bootefi.c
>> @@ -54,14 +54,6 @@ static struct efi_device_path_file_path
>> bootefi_device_path[] = {
>>   }
>>   };
>>   -static efi_status_t EFIAPI bootefi_open_dp(void *handle, efi_guid_t
>> *protocol,
>> -void **protocol_interface, void *agent_handle,
>> -void *controller_handle, uint32_t attributes)
>> -{
>> -*protocol_interface = bootefi_device_path;
>> -return EFI_SUCCESS;
>> -}
>> -
>>   /* The EFI loaded_image interface for the image executed via
>> "bootefi" */
>>   static struct efi_loaded_image loaded_image_info = {
>>   .device_handle = bootefi_device_path,
>> @@ -78,7 +70,7 @@ static struct efi_object loaded_image_info_obj = {
>>* return handle which points to loaded_image_info
>>*/
>>   .guid = &efi_guid_loaded_image,
>> -.open = &efi_return_handle,
>> +.protocol_interface = &loaded_image_info,
>>   },
>>   {
>>   /*
>> @@ -86,7 +78,7 @@ static struct efi_object loaded_image_info_obj = {
>>* bootefi_device_path
>>*/
>>   .guid = &efi_guid_device_path,
>> -.open = &bootefi_open_dp,
>> +.protocol_interface = bootefi_device_path,
>>   },
>>   },
>>   };
>> @@ -99,7 +91,7 @@ static struct efi_object bootefi_device_obj = {
>>   /* When asking for the device path interface, return
>>* bootefi_device_path */
>>   .guid = &efi_guid_device_path,
>> -.open = &bootefi_open_dp,
>> +.protocol_interface = bootefi_device_path
>>   }
>>   },
>>   };
>> diff --git a/include/efi_loader.h b/include/efi_loader.h
>> index 99619f53a9..c620652307 100644
>> --- a/include/efi_loader.h
>> +++ b/include/efi_loader.h
>> @@ -49,15 +49,10 @@ struct efi_class_map {
>>   /*
>>* When the UEFI payload wants to open a protocol on an object to
>> get its
>>* interface (usually a struct with callback functions), this struct
>> maps the
>> - * protocol GUID to the respective protocol handler open function for
>> that
>> - * object protocol combination.
>> - */
>> + * protocol GUID to the respective protocol interface */
>>   struct efi_handler {
>>   const efi_guid_t *guid;
>> -efi_status_t (EFIAPI *open)(void *handle,
>> -efi_guid_t *protocol, void **protocol_interface,
>> -void *agent_handle, void *controller_handle,
>> -uint32_t attributes);
>> +void *protocol_interface;
>>   };
>> /*
>> @@ -91,14 +86,6 @@ void efi_smbios_register(void);
>>   /* Called by networking code to memorize the dhcp ack package */
>>   void efi_net_set_dhcp_ack(void *pkt, int len);
>>   -/*
>> - * Stub implementation for a protocol opener that just returns the
>> handle as
>> - * interface
>> - */
>> -efi_status_t EFIAPI efi_return_handle(void *handle,
>> -efi_guid_t *protocol, void **protocol_interface,
>> -void *agent_handle, void *controller_handle,
>> -uint32_t attributes);
>>   /* Called from places to check whether a timer expired */
>>   void efi_timer_check(void);
>>   /* PE loader implementation */
>> diff --git a/lib/efi_loader/efi_boottime.c
>> b/lib/efi_loader/efi_boottime.c
>> index 2ecec60281..0f67dc2037 100644
>> --- a/lib/efi_loader/efi_boottime.c
>> +++ b/lib/efi_loader/efi_boottime.c
>> @@ -443,7 +443,6 @@ static efi_status_t EFIAPI efi_load_image(bool
>> boot_policy,
>>   .protocols = {
>>   {
>>   .guid = &efi_guid_loaded_image,
>> -.open = &efi_return_handle,
>>   },
>>   },
>>   };
>> @@ -453,6 +452,7 @@ static efi_status_t EFIAPI efi_load_image(bool
>> boot_policy,
>>

Re: [U-Boot] [PATCH 3/4] configs: k2x_evm: Reorder default boot command

[Tom Rini]

On Mon, Jul 17, 2017 at 12:59:14PM -0500, Andrew F. Davis wrote:

> We first split the CONFIG_BOOTCOMMAND into its components to improve
> readability. We then make the following order changes:
> 
>  - Run findfdt first so the fdt name can be used in envboot like OMAP
>  - Install the boot monitor before running the PMMC so we can make any
>  needed secure changes before PMMC, do this on both HS and non-HS
>  - Move set_name_pmmc to just before get_pmmc_${boot}
> 
> Signed-off-by: Andrew F. Davis 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH 1/4] configs: k2x_evm: Adds FIT loading environment variables

[Tom Rini]

On Mon, Jul 17, 2017 at 12:59:12PM -0500, Andrew F. Davis wrote:

> Updates the default u-boot environment variables to support FIT image
> loading.
> 
> Signed-off-by: Andrew F. Davis 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH] arm: mach-keystone: Fixes issue with return values in inline assembly

[Tom Rini]

On Mon, Jul 17, 2017 at 01:02:02PM -0500, Andrew F. Davis wrote:

> From: "Srinivas, Madan" 
> 
> The inline assembly functions in mon.c assume that the caller will
> check for the return value in r0 according to regular ARM calling
> conventions.
> 
> However, this assumption breaks down if the compiler inlines the
> functions. The caller is then under no obligation to use r0 for the
> result.
> 
> To fix this disconnect, we must explicitly move the return value
> from the smc/bl call to the variable that the function returns.
> 
> Signed-off-by: Madan Srinivas 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH 2/4] configs: k2x_evm: Adds environment variables for secure devices

[Tom Rini]

On Mon, Jul 17, 2017 at 12:59:13PM -0500, Andrew F. Davis wrote:

> From: Madan Srinivas 
> 
> Updates the default u-boot environment variables to support secure
> boot. On secure devices, a secure boot monitor (sec-bm) needs to
> be installed by u-boot.
> 
> Signed-off-by: Madan Srinivas 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH 4/4] arm: mach-keystone: Updates mon_install for K2G HS

[Tom Rini]

On Mon, Jul 17, 2017 at 12:59:15PM -0500, Andrew F. Davis wrote:

> From: Madan Srinivas 
> 
> On early K2 devices (eg. K2HK) the secure ROM code does not support
> loading secure code to firewall protected memory, before decrypting,
> authenticating and executing it.
> 
> To load the boot monitor on these devices, it is necessary to first
> authenticate and run a copy loop from non-secure memory that copies
> the boot monitor behind firewall protected memory, before decrypting
> and executing it.
> 
> On K2G, the secure ROM does not allow secure code executing from
> unprotected memory. Further, ROM first copies the signed and encrypted
> image into firewall protected memory, then decrypts, authenticates
> and executes it.
> 
> As a result of this, we cannot use the copy loop for K2G. The
> mon_install has to be modified to pass the address the signed and
> encrypted secure boot monitor image to the authentication API.
> 
> For backward compatibility with other K2 devices and K2G GP,
> the mon_install API still supports a single argument. In this case
> the second argument is set to 0 by u-boot and is ignored by ROM
> 
> Signed-off-by: Thanh Tran 
> Signed-off-by: Madan Srinivas 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH 0/4] Add default secure boot env for K2x

[Tom Rini]

On Mon, Jul 17, 2017 at 12:59:11PM -0500, Andrew F. Davis wrote:

> Hello all,
> 
> This series adds the default environment variables needed to boot
> K2x family secure devices.
> 
> Thanks,
> Andrew
> 
> Andrew F. Davis (2):
>   configs: k2x_evm: Adds FIT loading environment variables
>   configs: k2x_evm: Reorder default boot command
> 
> Madan Srinivas (2):
>   configs: k2x_evm: Adds environment variables for secure devices
>   arm: mach-keystone: Updates mon_install for K2G HS
> 
>  arch/arm/mach-keystone/cmd_mon.c  |  8 ++--
>  arch/arm/mach-keystone/include/mach/mon.h |  2 +-
>  arch/arm/mach-keystone/mon.c  |  7 ---
>  include/configs/k2e_evm.h |  9 +
>  include/configs/k2g_evm.h | 23 ---
>  include/configs/k2hk_evm.h|  9 +
>  include/configs/ti_armv7_keystone2.h  | 30 +++---
>  7 files changed, 76 insertions(+), 12 deletions(-)

Overall, we need to look at, as a follow up, moving things into
include/environment/ti/, thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH 1/2] board: ti: am57xx: Fix detection of board version

[Tom Rini]

On Sun, Jul 16, 2017 at 07:59:18PM +0530, Lokesh Vutla wrote:

> board_is*("rev", board_ti_get_rev()) uses strncmp() for
> revison detection and assumes it is success if return value
> is <= 0. This will fail in case of multiple versions, as
> revb will be true for board_is_*revb() and board_is_*reva().
> Fix it by looking for exact match of the string.
> 
> Signed-off-by: Lokesh Vutla 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH 2/2] board: ti: x15: Add support for beagle_X15 revC

[Tom Rini]

On Sun, Jul 16, 2017 at 07:59:19PM +0530, Lokesh Vutla wrote:

> BeagleBoard X15 revC board is similar to X15 revB1 except
> with a SR2.0 where revB1 uses a SR1.1. Add board detection
> support for revC.
> 
> Signed-off-by: Lokesh Vutla 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH 4/5] efi_loader: gop: fixes for CONFIG_DM_VIDEO without CONFIG_LCD

[Tom Rini]

On Tue, Jul 18, 2017 at 05:06:49PM +0200, Alexander Graf wrote:
> On 07/18/2017 04:54 PM, Simon Glass wrote:
> >Hi Alex,
> >
> >On 18 July 2017 at 07:47, Alexander Graf  wrote:
> >>On 07/18/2017 04:00 PM, Simon Glass wrote:
> >>>Hi,
> >>>
> >>>On 12 July 2017 at 05:52, Alexander Graf  wrote:
> 
> On 25.06.17 01:05, Rob Clark wrote:
> >Signed-off-by: Rob Clark 
> >Cc: Alexander Graf 
> 
> Looks reasonable to me, but could probably use a commit message ;). Also
> please make sure to CC Simon on all things DM.
> 
> >>>Can we drop the CONFIG_LCD support entirely? This is legacy code at
> >>>this point. What boards use it?
> >>
> >>Sounds like someone would first need to convert a bunch of boards :).
> >>
> >>$ for i in $(grep CONFIG_LCD configs/* | cut -d : -f 1); do grep -q DM_VIDEO
> >>$i || echo $i; done
> >>configs/at91sam9261ek_dataflash_cs0_defconfig
> >>configs/at91sam9261ek_dataflash_cs3_defconfig
> >>configs/at91sam9261ek_nandflash_defconfig
> >>configs/at91sam9263ek_dataflash_cs0_defconfig
> >>configs/at91sam9263ek_dataflash_defconfig
> >>configs/at91sam9263ek_nandflash_defconfig
> >>configs/at91sam9263ek_norflash_boot_defconfig
> >>configs/at91sam9263ek_norflash_defconfig
> >>configs/at91sam9g10ek_dataflash_cs0_defconfig
> >>configs/at91sam9g10ek_dataflash_cs3_defconfig
> >>configs/at91sam9g10ek_nandflash_defconfig
> >>configs/at91sam9m10g45ek_mmc_defconfig
> >>configs/at91sam9m10g45ek_nandflash_defconfig
> >>configs/at91sam9n12ek_mmc_defconfig
> >>configs/at91sam9n12ek_nandflash_defconfig
> >>configs/at91sam9n12ek_spiflash_defconfig
> >>configs/at91sam9rlek_dataflash_defconfig
> >>configs/at91sam9rlek_mmc_defconfig
> >>configs/at91sam9rlek_nandflash_defconfig
> >>configs/at91sam9x5ek_dataflash_defconfig
> >>configs/at91sam9x5ek_mmc_defconfig
> >>configs/at91sam9x5ek_nandflash_defconfig
> >>configs/at91sam9x5ek_spiflash_defconfig
> >>configs/brppt1_mmc_defconfig
> >>configs/brppt1_nand_defconfig
> >>configs/brppt1_spi_defconfig
> >>configs/brxre1_defconfig
> >>configs/cm_t3517_defconfig
> >>configs/cm_t35_defconfig
> >>configs/picosam9g45_defconfig
> >>configs/pm9261_defconfig
> >>configs/pm9263_defconfig
> >>configs/sama5d36ek_cmp_mmc_defconfig
> >>configs/sama5d36ek_cmp_nandflash_defconfig
> >>configs/sama5d36ek_cmp_spiflash_defconfig
> >>configs/sama5d3xek_mmc_defconfig
> >>configs/sama5d3xek_nandflash_defconfig
> >>configs/sama5d3xek_spiflash_defconfig
> >>configs/sama5d4ek_mmc_defconfig
> >>configs/sama5d4ek_nandflash_defconfig
> >>configs/sama5d4ek_spiflash_defconfig
> >>configs/zipitz2_defconfig
> >Not really. I suspect none of those uses EFI_LOADER
> 
> Why not? I really don't want to limit EFI_LOADER to something I
> consider good. It's supposed to be the *one* interface that just
> works for everyone.
> 
> >There is video driver for atmel which is most of the boards in that
> >list, but we can disable EFI_LOADER until they are converted.
> 
> No, I won't disable EFI_LOADER on any board because it's not
> converted. I'd rather add support to EFI_LOADER to support more
> boards that are not converted to DM ;).
> 
> >We should avoid adding new features to legacy code paths as it makes
> >DM conversion harder and less likely to complete.
> 
> I agree, but the solution is not to disable EFI_LOADER, it's to
> convert boards.

Lets CC some Atmel folks...

-- 
Tom


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

Re: [U-Boot] [PATCH 05/30] Convert CONFIG_ENV_IS_IN_FLASH to Kconfig

[Tom Rini]

On Tue, Jul 18, 2017 at 05:01:39PM +0200, Daniel Schwierzeck wrote:
> 2017-07-18 16:00 GMT+02:00 Simon Glass :
> > Hi Daniel,
> >
> > On 10 July 2017 at 15:09, Daniel Schwierzeck
> >  wrote:
> >>
> >>
> >> Am 09.07.2017 um 22:52 schrieb Simon Glass:
> >>> This converts the following to Kconfig:
> >>>CONFIG_ENV_IS_IN_FLASH
> >>>
> >>> Signed-off-by: Simon Glass 
> >>> ---
> >>>
> >>
> >> ...
> >>
> >>> diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
> >>> index 579371e8ee..3046d90b4d 100644
> >>> --- a/arch/mips/Kconfig
> >>> +++ b/arch/mips/Kconfig
> >>> @@ -21,6 +21,7 @@ config TARGET_QEMU_MIPS
> >>>   select SUPPORTS_CPU_MIPS64_R1
> >>>   select SUPPORTS_CPU_MIPS64_R2
> >>>   select ROM_EXCEPTION_VECTORS
> >>> + imply ENV_IS_IN_FLASH
> >>>
> >>>  config TARGET_MALTA
> >>>   bool "Support malta"
> >>> @@ -42,6 +43,7 @@ config TARGET_MALTA
> >>>   select SWAP_IO_SPACE
> >>>   select MIPS_L1_CACHE_SHIFT_6
> >>>   select ROM_EXCEPTION_VECTORS
> >>> + imply ENV_IS_IN_FLASH
> >>>
> >>>  config TARGET_VCT
> >>>   bool "Support vct"
> >>> @@ -108,6 +110,7 @@ config TARGET_BOSTON
> >>>   select SUPPORTS_CPU_MIPS64_R2
> >>>   select SUPPORTS_CPU_MIPS64_R6
> >>>   select ROM_EXCEPTION_VECTORS
> >>> + imply ENV_IS_IN_FLASH
> >>>
> >>>  config TARGET_XILFPGA
> >>>   bool "Support Imagination Xilfpga"
> >>> @@ -197,6 +200,7 @@ config CPU_MIPS64_R2
> >>>   bool "MIPS64 Release 2"
> >>>   depends on SUPPORTS_CPU_MIPS64_R2
> >>>   select 64BIT
> >>> + imply ENV_IS_IN_FLASH
> >>>   help
> >>> Choose this option to build a kernel for release 2 through 5 of 
> >>> the
> >>> MIPS64 architecture.
> >>> @@ -297,6 +301,7 @@ config CPU_MIPS32
> >>>  config CPU_MIPS64
> >>>   bool
> >>>   default y if CPU_MIPS64_R1 || CPU_MIPS64_R2 || CPU_MIPS64_R6
> >>> + imply ENV_IS_IN_FLASH
> >>
> >> this is wrong as CONFIG_CPU_MIPS64 is a generic MIPS symbol and not a
> >> specific for a machine or board
> >
> > Well the intent is to reduce the number of changes to individual
> > boards / defconfig files. So in fact I want to use this more generic
> > option.
> 
> yes, but adding "imply ENV_IS_IN_FLASH" to the Kconfig symbols
> CPU_MIPS64 and MIPS_CM is wrong due to the logical intent of these
> symbols. If you want to add the imply for all MIPS boards, then the
> correct place would be the MIPS symbol in arch/Kconfig. But enabling
> ENV_IS_IN_FLASH for all MIPS boards would be wrong too. Thus the
> "imply ENV_IS_IN_FLASH" only makes sense with the TARGET_* symbols
> because these describe default board configs.
> 
> >
> >>
> >>>
> >>>  config MIPS_TUNE_4KC
> >>>   bool
> >>> @@ -401,6 +406,7 @@ config DYNAMIC_IO_PORT_BASE
> >>>
> >>>  config MIPS_CM
> >>>   bool
> >>> + imply ENV_IS_IN_FLASH
> >>
> >> dito for CONFIG_MIPS_CM
> >>
> >>>   help
> >>> Select this if your system contains a MIPS Coherence Manager and 
> >>> you
> >>> wish U-Boot to configure it or make use of it to retrieve system
> >>
> >> ...
> >>
> >>> diff --git a/configs/vct_platinum_defconfig 
> >>> b/configs/vct_platinum_defconfig
> >>> index f8b9d7e61b..0e4fcbaa26 100644
> >>> --- a/configs/vct_platinum_defconfig
> >>> +++ b/configs/vct_platinum_defconfig
> >>> @@ -12,6 +12,7 @@ CONFIG_CMD_DHCP=y
> >>>  CONFIG_CMD_PING=y
> >>>  CONFIG_CMD_SNTP=y
> >>>  CONFIG_CMD_FAT=y
> >>> +CONFIG_ENV_IS_IN_FLASH=y
> >>
> >> for consistency with the other MIPS boards in this patch, this should be
> >> added as "imply CONFIG_ENV_IS_IN_FLASH" in arch/mips/Kconfig under
> >> "config TARGET_VCT"
> >
> > If there are only 1-2 boards affected then I think it makes more sense
> > to put the change in the defconfig file. Adjusting Kconfig for
> > individual boards just seems odd...?
> >
> 
> but you already touched all TARGET_* symbols in arch/mips/Kconfig
> except TARGET_VCT. Instead you patched all defconfig files for the 12
> VCT related boards which is contrary to the intention of your patch.
> 
> So please only update the TARGET_* options either in arch/mips/Kconfig
> or arch/mips/mach-*/Kconfig, thanks.

To echo this, the moveconfig.py imply logic is good, but we then need to
see if it follows the human logic side.  ie environment is a board
choice, not SoC/etc, so we need to shuffle it around to the right area.
Thanks!

-- 
Tom


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

[U-Boot] [PATCH] ARM: Mark AE boards orphan

[Marek Vasut]

I no longer have any of these boards, mark boards orphan.

Signed-off-by: Marek Vasut 
Cc: Tom Rini 
---
 board/aries/m28evk/MAINTAINERS   | 4 ++--
 board/aries/m53evk/MAINTAINERS   | 4 ++--
 board/aries/ma5d4evk/MAINTAINERS | 4 ++--
 board/aries/mcvevk/MAINTAINERS   | 4 ++--
 4 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/board/aries/m28evk/MAINTAINERS b/board/aries/m28evk/MAINTAINERS
index f600e7d884..aad6313dbe 100644
--- a/board/aries/m28evk/MAINTAINERS
+++ b/board/aries/m28evk/MAINTAINERS
@@ -1,6 +1,6 @@
 M28EVK BOARD
-M: Marek Vasut 
-S: Maintained
+#M:Marek Vasut 
+S: Orphan (since 2017-07)
 F: board/aries/m28evk/
 F: include/configs/m28evk.h
 F: configs/m28evk_defconfig
diff --git a/board/aries/m53evk/MAINTAINERS b/board/aries/m53evk/MAINTAINERS
index 71137f0802..73a68cf5aa 100644
--- a/board/aries/m53evk/MAINTAINERS
+++ b/board/aries/m53evk/MAINTAINERS
@@ -1,6 +1,6 @@
 M53EVK BOARD
-M: Marek Vasut 
-S: Maintained
+#M:Marek Vasut 
+S: Orphan (since 2017-07)
 F: board/aries/m53evk/
 F: include/configs/m53evk.h
 F: configs/m53evk_defconfig
diff --git a/board/aries/ma5d4evk/MAINTAINERS b/board/aries/ma5d4evk/MAINTAINERS
index 664a29a0df..a2fab52dfc 100644
--- a/board/aries/ma5d4evk/MAINTAINERS
+++ b/board/aries/ma5d4evk/MAINTAINERS
@@ -1,6 +1,6 @@
 Aries MA5D4EVK BOARD
-M: Marek Vasut 
-S: Maintained
+#M:Marek Vasut 
+S: Orphan (since 2017-07)
 F: board/aries/ma5d4evk/
 F: include/configs/ma5d4evk.h
 F: configs/ma5d4evk_defconfig
diff --git a/board/aries/mcvevk/MAINTAINERS b/board/aries/mcvevk/MAINTAINERS
index c3a3a2b87d..0b719a154c 100644
--- a/board/aries/mcvevk/MAINTAINERS
+++ b/board/aries/mcvevk/MAINTAINERS
@@ -1,5 +1,5 @@
 Aries MCVEVK BOARD
-M: Marek Vasut 
-S: Maintained
+#M:Marek Vasut 
+S: Orphan (since 2017-07)
 F: include/configs/socfpga_mcvevk.h
 F: configs/socfpga_mcvevk_defconfig
-- 
2.11.0

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

[U-Boot] [PATCH v2 6/6] ram: stm32: add stm32h7 support

[patrice.chotard]

From: Patrice Chotard 

STM32F7 and H7 shared the same SDRAM control block.
On STM32H7 few control bits has been added.
The current driver need some minor adaptation as FMC block
enable/disable for H7.

Signed-off-by: Patrice Chotard 
---
v2: _ rework comment
_ replace generic_clear_bit/set_bit() by clrbits_le32/setbits_le32()


 drivers/ram/stm32_sdram.c | 25 -
 1 file changed, 24 insertions(+), 1 deletion(-)

diff --git a/drivers/ram/stm32_sdram.c b/drivers/ram/stm32_sdram.c
index 6fb89fb..b1b0289 100644
--- a/drivers/ram/stm32_sdram.c
+++ b/drivers/ram/stm32_sdram.c
@@ -54,6 +54,12 @@ struct stm32_fmc_regs {
u32 sdsr;   /* SDRAM Status register */
 };
 
+/*
+ * NOR/PSRAM Control register BCR1
+ * FMC controller Enable, only availabe for H7
+ */
+#define FMC_BCR1_FMCEN BIT(31)
+
 /* Control register SDCR */
 #define FMC_SDCR_RPIPE_SHIFT   13  /* RPIPE bit shift */
 #define FMC_SDCR_RBURST_SHIFT  12  /* RBURST bit shift */
@@ -123,6 +129,11 @@ enum stm32_fmc_bank {
MAX_SDRAM_BANK,
 };
 
+enum stm32_fmc_family {
+   STM32F7_FMC,
+   STM32H7_FMC,
+};
+
 struct bank_params {
struct stm32_sdram_control *sdram_control;
struct stm32_sdram_timing *sdram_timing;
@@ -134,6 +145,7 @@ struct stm32_sdram_params {
struct stm32_fmc_regs *base;
u8 no_sdram_banks;
struct bank_params bank_params[MAX_SDRAM_BANK];
+   enum stm32_fmc_family family;
 };
 
 #define SDRAM_MODE_BL_SHIFT0
@@ -151,6 +163,10 @@ int stm32_sdram_init(struct udevice *dev)
u32 ref_count;
u8 i;
 
+   /* disable the FMC controller */
+   if (params->family == STM32H7_FMC)
+   clrbits_le32(®s->bcr1, FMC_BCR1_FMCEN);
+
for (i = 0; i < params->no_sdram_banks; i++) {
control = params->bank_params[i].sdram_control;
timing = params->bank_params[i].sdram_timing;
@@ -193,6 +209,7 @@ int stm32_sdram_init(struct udevice *dev)
| timing->txsr << FMC_SDTR_TXSR_SHIFT
| timing->tmrd << FMC_SDTR_TMRD_SHIFT,
®s->sdtr2);
+
if (target_bank == SDRAM_BANK1)
ctb = FMC_SDCMR_BANK_1;
else
@@ -225,6 +242,10 @@ int stm32_sdram_init(struct udevice *dev)
writel(ref_count << 1, ®s->sdrtr);
}
 
+   /* enable the FMC controller */
+   if (params->family == STM32H7_FMC)
+   setbits_le32(®s->bcr1, FMC_BCR1_FMCEN);
+
return 0;
 }
 
@@ -305,6 +326,7 @@ static int stm32_fmc_probe(struct udevice *dev)
return -EINVAL;
 
params->base = (struct stm32_fmc_regs *)addr;
+   params->family = dev_get_driver_data(dev);
 
 #ifdef CONFIG_CLK
struct clk clk;
@@ -337,7 +359,8 @@ static struct ram_ops stm32_fmc_ops = {
 };
 
 static const struct udevice_id stm32_fmc_ids[] = {
-   { .compatible = "st,stm32-fmc" },
+   { .compatible = "st,stm32-fmc", .data = STM32F7_FMC },
+   { .compatible = "st,stm32h7-fmc", .data = STM32H7_FMC },
{ }
 };
 
-- 
1.9.1

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

[U-Boot] [PATCH v2 4/6] ram: stm32: add second SDRAM bank management

[patrice.chotard]

From: Patrice Chotard 

FMC is able to manage 2 SDRAM banks, but the current driver
implementation is only able to manage the first SDRAM bank.

Even if only bank2 is used, some bank1 registers must be
configured.

Signed-off-by: Patrice Chotard 
Reviewed-by: Simon Glass 
---

v2: _ add Reviewed-by: Simon Glass

 doc/device-tree-bindings/ram/st,stm32-fmc.txt |  19 ++-
 drivers/ram/stm32_sdram.c | 215 +-
 2 files changed, 155 insertions(+), 79 deletions(-)

diff --git a/doc/device-tree-bindings/ram/st,stm32-fmc.txt 
b/doc/device-tree-bindings/ram/st,stm32-fmc.txt
index 3d1392c..99f76d5 100644
--- a/doc/device-tree-bindings/ram/st,stm32-fmc.txt
+++ b/doc/device-tree-bindings/ram/st,stm32-fmc.txt
@@ -40,12 +40,19 @@ Example:
pinctrl-names = "default";
status = "okay";
 
-   mr-nbanks = <1>;
/* sdram memory configuration from sdram datasheet */
-   bank1: bank@0 {
-  st,sdram-control = /bits/ 8 ;
-  st,sdram-timing = /bits/ 8 ;
-   };
-}
+   };
+
+   /* sdram memory configuration from sdram datasheet */
+   bank2: bank@1 {
+  st,sdram-control = /bits/ 8 ;
+  st,sdram-timing = /bits/ 8 ;
+   };
+   }
diff --git a/drivers/ram/stm32_sdram.c b/drivers/ram/stm32_sdram.c
index 4029811..6fb89fb 100644
--- a/drivers/ram/stm32_sdram.c
+++ b/drivers/ram/stm32_sdram.c
@@ -117,12 +117,23 @@ struct stm32_sdram_timing {
u8 twr;
u8 trcd;
 };
-struct stm32_sdram_params {
-   struct stm32_fmc_regs *base;
-   u8 no_sdram_banks;
+enum stm32_fmc_bank {
+   SDRAM_BANK1,
+   SDRAM_BANK2,
+   MAX_SDRAM_BANK,
+};
+
+struct bank_params {
struct stm32_sdram_control *sdram_control;
struct stm32_sdram_timing *sdram_timing;
u32 sdram_ref_count;
+   enum stm32_fmc_bank target_bank;
+};
+
+struct stm32_sdram_params {
+   struct stm32_fmc_regs *base;
+   u8 no_sdram_banks;
+   struct bank_params bank_params[MAX_SDRAM_BANK];
 };
 
 #define SDRAM_MODE_BL_SHIFT0
@@ -132,96 +143,154 @@ struct stm32_sdram_params {
 int stm32_sdram_init(struct udevice *dev)
 {
struct stm32_sdram_params *params = dev_get_platdata(dev);
+   struct stm32_sdram_control *control;
+   struct stm32_sdram_timing *timing;
struct stm32_fmc_regs *regs = params->base;
-   struct stm32_sdram_control *control = params->sdram_control;
-   struct stm32_sdram_timing *timing = params->sdram_timing;
-
-   writel(control->sdclk << FMC_SDCR_SDCLK_SHIFT
-   | control->cas_latency << FMC_SDCR_CAS_SHIFT
-   | control->no_banks << FMC_SDCR_NB_SHIFT
-   | control->memory_width << FMC_SDCR_MWID_SHIFT
-   | control->no_rows << FMC_SDCR_NR_SHIFT
-   | control->no_columns << FMC_SDCR_NC_SHIFT
-   | control->rd_pipe_delay << FMC_SDCR_RPIPE_SHIFT
-   | control->rd_burst << FMC_SDCR_RBURST_SHIFT,
-   ®s->sdcr1);
-
-   writel(timing->trcd << FMC_SDTR_TRCD_SHIFT
-   | timing->trp << FMC_SDTR_TRP_SHIFT
-   | timing->twr << FMC_SDTR_TWR_SHIFT
-   | timing->trc << FMC_SDTR_TRC_SHIFT
-   | timing->tras << FMC_SDTR_TRAS_SHIFT
-   | timing->txsr << FMC_SDTR_TXSR_SHIFT
-   | timing->tmrd << FMC_SDTR_TMRD_SHIFT,
-   ®s->sdtr1);
-
-   writel(FMC_SDCMR_BANK_1 | FMC_SDCMR_MODE_START_CLOCK,
-  ®s->sdcmr);
-   udelay(200);/* 200 us delay, page 10, "Power-Up" */
-   FMC_BUSY_WAIT(regs);
-
-   writel(FMC_SDCMR_BANK_1 | FMC_SDCMR_MODE_PRECHARGE,
-  ®s->sdcmr);
-   udelay(100);
-   FMC_BUSY_WAIT(regs);
-
-   writel((FMC_SDCMR_BANK_1 | FMC_SDCMR_MODE_AUTOREFRESH
-   | 7 << FMC_SDCMR_NRFS_SHIFT), ®s->sdcmr);
-   udelay(100);
-   FMC_BUSY_WAIT(regs);
-
-   writel(FMC_SDCMR_BANK_1 | (SDRAM_MODE_BL << SDRAM_MODE_BL_SHIFT
-  | control->cas_latency << SDRAM_MODE_CAS_SHIFT)
-  << FMC_SDCMR_MODE_REGISTER_SHIFT | FMC_SDCMR_MODE_WRITE_MODE,
-  ®s->sdcmr);
-   udelay(100);
-   FMC_BUSY_WAIT(regs);
-
-   writel(FMC_SDCMR_BANK_1 | FMC_SDCMR_MODE_NORMAL,
-  ®s->sdcmr);
-   FMC_BUSY_WAIT(regs);
-
-   /* Refresh timer */
-   writel((params->sdram_ref_count) << 1, ®s->sdrtr);
+   enum stm32_fmc_bank target_bank;
+   u32 ctb; /* SDCMR register: Command Target Bank */
+   u32 ref_count;
+   u8 i;
+
+   for (i = 0; i < params->no_sdram_banks; i++) {
+   control = params->bank_params[i].sdram_control;
+   timing = params->bank_params[i].sdram_timing;
+   target_bank = params->bank_params[i].target_bank;
+   ref_count = params->bank_params[i].sdram_ref_count;
+
+   writel(control->sdclk << FM

[U-Boot] [PATCH v2 2/6] ram: stm32: get base address from DT

[patrice.chotard]

From: Patrice Chotard 

Retrieve RAM base address from DT instead of using STM32_SDRAM_FMC

For STM32F7, FMC block base address is 0xA000, but SDRAM
registers are located at offset 0x140 inside FMC block.
Update the stm32_fmc_regs fields with all FMC registers
to map SDRAM registers at the right address.

These additionals registers will be used later.

Signed-off-by: Patrice Chotard 
---

v2: _ use dev_read_addr() instead of devfdt_get_addr() 

 drivers/ram/stm32_sdram.c | 92 ---
 1 file changed, 64 insertions(+), 28 deletions(-)

diff --git a/drivers/ram/stm32_sdram.c b/drivers/ram/stm32_sdram.c
index 4146b9d..9b2cec4 100644
--- a/drivers/ram/stm32_sdram.c
+++ b/drivers/ram/stm32_sdram.c
@@ -10,25 +10,50 @@
 #include 
 #include 
 #include 
-#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
 struct stm32_fmc_regs {
-   u32 sdcr1;  /* Control register 1 */
-   u32 sdcr2;  /* Control register 2 */
-   u32 sdtr1;  /* Timing register 1 */
-   u32 sdtr2;  /* Timing register 2 */
-   u32 sdcmr;  /* Mode register */
-   u32 sdrtr;  /* Refresh timing register */
-   u32 sdsr;   /* Status register */
+   /* 0x0 */
+   u32 bcr1;   /* NOR/PSRAM Chip select control register 1 */
+   u32 btr1;   /* SRAM/NOR-Flash Chip select timing register 1 */
+   u32 bcr2;   /* NOR/PSRAM Chip select Control register 2 */
+   u32 btr2;   /* SRAM/NOR-Flash Chip select timing register 2 */
+   u32 bcr3;   /* NOR/PSRAMChip select Control register 3 */
+   u32 btr3;   /* SRAM/NOR-Flash Chip select timing register 3 */
+   u32 bcr4;   /* NOR/PSRAM Chip select Control register 4 */
+   u32 btr4;   /* SRAM/NOR-Flash Chip select timing register 4 */
+   u32 reserved1[24];
+
+   /* 0x80 */
+   u32 pcr;/* NAND Flash control register */
+   u32 sr; /* FIFO status and interrupt register */
+   u32 pmem;   /* Common memory space timing register */
+   u32 patt;   /* Attribute memory space timing registers  */
+   u32 reserved2[1];
+   u32 eccr;   /* ECC result registers */
+   u32 reserved3[27];
+
+   /* 0x104 */
+   u32 bwtr1;  /* SRAM/NOR-Flash write timing register 1 */
+   u32 reserved4[1];
+   u32 bwtr2;  /* SRAM/NOR-Flash write timing register 2 */
+   u32 reserved5[1];
+   u32 bwtr3;  /* SRAM/NOR-Flash write timing register 3 */
+   u32 reserved6[1];
+   u32 bwtr4;  /* SRAM/NOR-Flash write timing register 4 */
+   u32 reserved7[8];
+
+   /* 0x140 */
+   u32 sdcr1;  /* SDRAM Control register 1 */
+   u32 sdcr2;  /* SDRAM Control register 2 */
+   u32 sdtr1;  /* SDRAM Timing register 1 */
+   u32 sdtr2;  /* SDRAM Timing register 2 */
+   u32 sdcmr;  /* SDRAM Mode register */
+   u32 sdrtr;  /* SDRAM Refresh timing register */
+   u32 sdsr;   /* SDRAM Status register */
 };
 
-/*
- * FMC registers base
- */
-#define STM32_SDRAM_FMC((struct stm32_fmc_regs 
*)SDRAM_FMC_BASE)
-
 /* Control register SDCR */
 #define FMC_SDCR_RPIPE_SHIFT   13  /* RPIPE bit shift */
 #define FMC_SDCR_RBURST_SHIFT  12  /* RBURST bit shift */
@@ -66,9 +91,9 @@ struct stm32_fmc_regs {
 
 #define FMC_SDSR_BUSY  BIT(5)
 
-#define FMC_BUSY_WAIT()do { \
+#define FMC_BUSY_WAIT(regs)do { \
__asm__ __volatile__ ("dsb" : : : "memory"); \
-   while (STM32_SDRAM_FMC->sdsr & FMC_SDSR_BUSY) \
+   while (regs->sdsr & FMC_SDSR_BUSY) \
; \
} while (0)
 
@@ -93,6 +118,7 @@ struct stm32_sdram_timing {
u8 trcd;
 };
 struct stm32_sdram_params {
+   struct stm32_fmc_regs *base;
u8 no_sdram_banks;
struct stm32_sdram_control sdram_control;
struct stm32_sdram_timing sdram_timing;
@@ -106,6 +132,7 @@ struct stm32_sdram_params {
 int stm32_sdram_init(struct udevice *dev)
 {
struct stm32_sdram_params *params = dev_get_platdata(dev);
+   struct stm32_fmc_regs *regs = params->base;
 
writel(params->sdram_control.sdclk << FMC_SDCR_SDCLK_SHIFT
| params->sdram_control.cas_latency << FMC_SDCR_CAS_SHIFT
@@ -115,7 +142,7 @@ int stm32_sdram_init(struct udevice *dev)
| params->sdram_control.no_columns << FMC_SDCR_NC_SHIFT
| params->sdram_control.rd_pipe_delay << FMC_SDCR_RPIPE_SHIFT
| params->sdram_control.rd_burst << FMC_SDCR_RBURST_SHIFT,
-   &STM32_SDRAM_FMC->sdcr1);
+   ®s->sdcr1);
 
writel(params->sdram_timing.trcd << FMC_SDTR_TRCD_SHIFT
| params->sdram_timing.trp << FMC_SDTR_TRP_SHIFT
@@ -124,36 +151,36 @@ int stm32_sdram_init(struct udevice *dev)
| params->sdram_timing.tras << FMC_SDTR_TRAS_SHIFT
| params->sdram_timing.txsr << FMC_SDTR_TX

[U-Boot] [PATCH v2 5/6] ARM: DTS: stm32: remove useless mr-nbanks property

[patrice.chotard]

From: Patrice Chotard 

FMC driver is now able to discover the bank number by
parsing bank subnodes.

Signed-off-by: Patrice Chotard 
Reviewed-by: Simon Glass 
---

v2: _ add Reviewed-by: Simon Glass

 arch/arm/dts/stm32f746-disco.dts | 1 -
 arch/arm/dts/stm32f769-disco.dts | 1 -
 2 files changed, 2 deletions(-)

diff --git a/arch/arm/dts/stm32f746-disco.dts b/arch/arm/dts/stm32f746-disco.dts
index 2c7fa79..c92c2e2 100644
--- a/arch/arm/dts/stm32f746-disco.dts
+++ b/arch/arm/dts/stm32f746-disco.dts
@@ -195,7 +195,6 @@
pinctrl-names = "default";
status = "okay";
 
-   mr-nbanks = <1>;
/* Memory configuration from sdram datasheet MT48LC_4M32_B2B5-6A */
bank1: bank@0 {
   st,sdram-control = /bits/ 8 ;
/* Memory configuration from sdram datasheet MT48LC_4M32_B2B5-6A */
bank1: bank@0 {
   st,sdram-control = /bits/ 8 https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v2 3/6] ram: stm32: replace fdtdec_get by ofnode calls

[patrice.chotard]

From: Patrice Chotard 

Replace all fdtdec_get..() calls by ofnode_read...() or dev_read..().
This will allow drivers to support a live device tree.

Signed-off-by: Patrice Chotard 
Reviewed-by: Simon Glass 
---

v2: _ add Reviewed-by: Simon Glass


 drivers/ram/stm32_sdram.c | 83 +++
 1 file changed, 47 insertions(+), 36 deletions(-)

diff --git a/drivers/ram/stm32_sdram.c b/drivers/ram/stm32_sdram.c
index 9b2cec4..4029811 100644
--- a/drivers/ram/stm32_sdram.c
+++ b/drivers/ram/stm32_sdram.c
@@ -120,8 +120,8 @@ struct stm32_sdram_timing {
 struct stm32_sdram_params {
struct stm32_fmc_regs *base;
u8 no_sdram_banks;
-   struct stm32_sdram_control sdram_control;
-   struct stm32_sdram_timing sdram_timing;
+   struct stm32_sdram_control *sdram_control;
+   struct stm32_sdram_timing *sdram_timing;
u32 sdram_ref_count;
 };
 
@@ -133,24 +133,26 @@ int stm32_sdram_init(struct udevice *dev)
 {
struct stm32_sdram_params *params = dev_get_platdata(dev);
struct stm32_fmc_regs *regs = params->base;
-
-   writel(params->sdram_control.sdclk << FMC_SDCR_SDCLK_SHIFT
-   | params->sdram_control.cas_latency << FMC_SDCR_CAS_SHIFT
-   | params->sdram_control.no_banks << FMC_SDCR_NB_SHIFT
-   | params->sdram_control.memory_width << FMC_SDCR_MWID_SHIFT
-   | params->sdram_control.no_rows << FMC_SDCR_NR_SHIFT
-   | params->sdram_control.no_columns << FMC_SDCR_NC_SHIFT
-   | params->sdram_control.rd_pipe_delay << FMC_SDCR_RPIPE_SHIFT
-   | params->sdram_control.rd_burst << FMC_SDCR_RBURST_SHIFT,
+   struct stm32_sdram_control *control = params->sdram_control;
+   struct stm32_sdram_timing *timing = params->sdram_timing;
+
+   writel(control->sdclk << FMC_SDCR_SDCLK_SHIFT
+   | control->cas_latency << FMC_SDCR_CAS_SHIFT
+   | control->no_banks << FMC_SDCR_NB_SHIFT
+   | control->memory_width << FMC_SDCR_MWID_SHIFT
+   | control->no_rows << FMC_SDCR_NR_SHIFT
+   | control->no_columns << FMC_SDCR_NC_SHIFT
+   | control->rd_pipe_delay << FMC_SDCR_RPIPE_SHIFT
+   | control->rd_burst << FMC_SDCR_RBURST_SHIFT,
®s->sdcr1);
 
-   writel(params->sdram_timing.trcd << FMC_SDTR_TRCD_SHIFT
-   | params->sdram_timing.trp << FMC_SDTR_TRP_SHIFT
-   | params->sdram_timing.twr << FMC_SDTR_TWR_SHIFT
-   | params->sdram_timing.trc << FMC_SDTR_TRC_SHIFT
-   | params->sdram_timing.tras << FMC_SDTR_TRAS_SHIFT
-   | params->sdram_timing.txsr << FMC_SDTR_TXSR_SHIFT
-   | params->sdram_timing.tmrd << FMC_SDTR_TMRD_SHIFT,
+   writel(timing->trcd << FMC_SDTR_TRCD_SHIFT
+   | timing->trp << FMC_SDTR_TRP_SHIFT
+   | timing->twr << FMC_SDTR_TWR_SHIFT
+   | timing->trc << FMC_SDTR_TRC_SHIFT
+   | timing->tras << FMC_SDTR_TRAS_SHIFT
+   | timing->txsr << FMC_SDTR_TXSR_SHIFT
+   | timing->tmrd << FMC_SDTR_TMRD_SHIFT,
®s->sdtr1);
 
writel(FMC_SDCMR_BANK_1 | FMC_SDCMR_MODE_START_CLOCK,
@@ -169,7 +171,7 @@ int stm32_sdram_init(struct udevice *dev)
FMC_BUSY_WAIT(regs);
 
writel(FMC_SDCMR_BANK_1 | (SDRAM_MODE_BL << SDRAM_MODE_BL_SHIFT
-  | params->sdram_control.cas_latency << SDRAM_MODE_CAS_SHIFT)
+  | control->cas_latency << SDRAM_MODE_CAS_SHIFT)
   << FMC_SDCMR_MODE_REGISTER_SHIFT | FMC_SDCMR_MODE_WRITE_MODE,
   ®s->sdcmr);
udelay(100);
@@ -187,27 +189,36 @@ int stm32_sdram_init(struct udevice *dev)
 
 static int stm32_fmc_ofdata_to_platdata(struct udevice *dev)
 {
-   int ret;
-   int node = dev_of_offset(dev);
-   const void *blob = gd->fdt_blob;
+   ofnode bank_node;
struct stm32_sdram_params *params = dev_get_platdata(dev);
 
-   params->no_sdram_banks = fdtdec_get_uint(blob, node, "mr-nbanks", 1);
+   params->no_sdram_banks = dev_read_u32_default(dev, "mr-nbanks", 1);
debug("%s, no of banks = %d\n", __func__, params->no_sdram_banks);
 
-   fdt_for_each_subnode(node, blob, node) {
-   ret = fdtdec_get_byte_array(blob, node, "st,sdram-control",
-   (u8 *)¶ms->sdram_control,
-   sizeof(params->sdram_control));
-   if (ret)
-   return ret;
-   ret = fdtdec_get_byte_array(blob, node, "st,sdram-timing",
-   (u8 *)¶ms->sdram_timing,
-   sizeof(params->sdram_timing));
-   if (ret)
-   return ret;
-
-   params->sdram_ref_count = fdtdec_get_int(blob, node,
+   dev_for_each_subnode(bank_node, dev) {
+   params->sdram_con

[U-Boot] [PATCH v2 1/6] ram: stm32: migrate fmc defines in driver file

[patrice.chotard]

From: Patrice Chotard 

Migrate all FMC defines from arch/arm/include/asm/arch-stm32f7/fmc.h
to drivers/ram/stm32_sdram.c

This will avoid to add an additionnal arch-stm32xx/fmc.h file when
a new stm32 family soc will be introduced.

Signed-off-by: Patrice Chotard 
Reviewed-by: Vikas Manocha 
Reviewed-by: Simon Glass 
---

v2: _ add Reviewed-by: Simon Glass

 arch/arm/include/asm/arch-stm32f7/fmc.h| 74 --
 board/st/stm32f746-disco/stm32f746-disco.c |  1 -
 drivers/ram/stm32_sdram.c  | 59 +++-
 3 files changed, 58 insertions(+), 76 deletions(-)
 delete mode 100644 arch/arm/include/asm/arch-stm32f7/fmc.h

diff --git a/arch/arm/include/asm/arch-stm32f7/fmc.h 
b/arch/arm/include/asm/arch-stm32f7/fmc.h
deleted file mode 100644
index 4741e5a..000
--- a/arch/arm/include/asm/arch-stm32f7/fmc.h
+++ /dev/null
@@ -1,74 +0,0 @@
-/*
- * (C) Copyright 2013
- * Pavel Boldin, Emcraft Systems, pabol...@emcraft.com
- *
- * (C) Copyright 2015
- * Kamil Lulko, 
- *
- * SPDX-License-Identifier:GPL-2.0+
- */
-
-#ifndef _MACH_FMC_H_
-#define _MACH_FMC_H_
-
-struct stm32_fmc_regs {
-   u32 sdcr1;  /* Control register 1 */
-   u32 sdcr2;  /* Control register 2 */
-   u32 sdtr1;  /* Timing register 1 */
-   u32 sdtr2;  /* Timing register 2 */
-   u32 sdcmr;  /* Mode register */
-   u32 sdrtr;  /* Refresh timing register */
-   u32 sdsr;   /* Status register */
-};
-
-/*
- * FMC registers base
- */
-#define STM32_SDRAM_FMC((struct stm32_fmc_regs 
*)SDRAM_FMC_BASE)
-
-/* Control register SDCR */
-#define FMC_SDCR_RPIPE_SHIFT   13  /* RPIPE bit shift */
-#define FMC_SDCR_RBURST_SHIFT  12  /* RBURST bit shift */
-#define FMC_SDCR_SDCLK_SHIFT   10  /* SDRAM clock divisor shift */
-#define FMC_SDCR_WP_SHIFT  9   /* Write protection shift */
-#define FMC_SDCR_CAS_SHIFT 7   /* CAS latency shift */
-#define FMC_SDCR_NB_SHIFT  6   /* Number of banks shift */
-#define FMC_SDCR_MWID_SHIFT4   /* Memory width shift */
-#define FMC_SDCR_NR_SHIFT  2   /* Number of row address bits shift */
-#define FMC_SDCR_NC_SHIFT  0   /* Number of col address bits shift */
-
-/* Timings register SDTR */
-#define FMC_SDTR_TMRD_SHIFT0   /* Load mode register to active */
-#define FMC_SDTR_TXSR_SHIFT4   /* Exit self-refresh time */
-#define FMC_SDTR_TRAS_SHIFT8   /* Self-refresh time */
-#define FMC_SDTR_TRC_SHIFT 12  /* Row cycle delay */
-#define FMC_SDTR_TWR_SHIFT 16  /* Recovery delay */
-#define FMC_SDTR_TRP_SHIFT 20  /* Row precharge delay */
-#define FMC_SDTR_TRCD_SHIFT24  /* Row-to-column delay */
-
-
-#define FMC_SDCMR_NRFS_SHIFT   5
-
-#define FMC_SDCMR_MODE_NORMAL  0
-#define FMC_SDCMR_MODE_START_CLOCK 1
-#define FMC_SDCMR_MODE_PRECHARGE   2
-#define FMC_SDCMR_MODE_AUTOREFRESH 3
-#define FMC_SDCMR_MODE_WRITE_MODE  4
-#define FMC_SDCMR_MODE_SELFREFRESH 5
-#define FMC_SDCMR_MODE_POWERDOWN   6
-
-#define FMC_SDCMR_BANK_1   BIT(4)
-#define FMC_SDCMR_BANK_2   BIT(3)
-
-#define FMC_SDCMR_MODE_REGISTER_SHIFT  9
-
-#define FMC_SDSR_BUSY  BIT(5)
-
-#define FMC_BUSY_WAIT()do { \
-   __asm__ __volatile__ ("dsb" : : : "memory"); \
-   while (STM32_SDRAM_FMC->sdsr & FMC_SDSR_BUSY) \
-   ; \
-   } while (0)
-
-
-#endif /* _MACH_FMC_H_ */
diff --git a/board/st/stm32f746-disco/stm32f746-disco.c 
b/board/st/stm32f746-disco/stm32f746-disco.c
index fc4c60c..4314c71 100644
--- a/board/st/stm32f746-disco/stm32f746-disco.c
+++ b/board/st/stm32f746-disco/stm32f746-disco.c
@@ -13,7 +13,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/drivers/ram/stm32_sdram.c b/drivers/ram/stm32_sdram.c
index 902de2b..4146b9d 100644
--- a/drivers/ram/stm32_sdram.c
+++ b/drivers/ram/stm32_sdram.c
@@ -10,11 +10,68 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
+struct stm32_fmc_regs {
+   u32 sdcr1;  /* Control register 1 */
+   u32 sdcr2;  /* Control register 2 */
+   u32 sdtr1;  /* Timing register 1 */
+   u32 sdtr2;  /* Timing register 2 */
+   u32 sdcmr;  /* Mode register */
+   u32 sdrtr;  /* Refresh timing register */
+   u32 sdsr;   /* Status register */
+};
+
+/*
+ * FMC registers base
+ */
+#define STM32_SDRAM_FMC((struct stm32_fmc_regs 
*)SDRAM_FMC_BASE)
+
+/* Control register SDCR */
+#define FMC_SDCR_RPIPE_SHIFT   13  /* RPIPE bit shift */
+#define FMC_SDCR_RBURST_SHIFT  12  /* RBURST bit shift */
+#define FMC_SDCR_SDCLK_SHIFT   10  /* SDRAM clock divisor shift */
+#define FMC_SDCR_WP_SHIFT  9   /* Write protection shift */
+#define FMC_SDCR_CAS_SHIFT 7   /* CAS latency shift */
+#define FMC_SDCR_NB_SHIFT   

[U-Boot] [PATCH v2 0/6] Extend stm32 SDRAM driver

[patrice.chotard]

From: Patrice Chotard 

This series aims to add some improvements to existing ram 
driver decicated to stm32 SoCs :
_ some code clean up
_ full DT support, now the FMC base is retrieved through DT
_ update DT API by using ofnode_read...() or dev_read..() instead
  of fdtdec_get..() to support livetree
_ add second SDRAM bank support needed for STM32H7-Discovery board 
  which uses the second SDRAM bank
_ add stm32 H7 support

v2: _ use dev_read_addr() instead of devfdt_get_addr() in patch 2
_ rework comment in patch 6
_ replace generic_clear_bit/set_bit() by clrbits_le32/setbits_le32() in
  patch 6

Patrice Chotard (6):
  ram: stm32: migrate fmc defines in driver file
  ram: stm32: get base address from DT
  ram: stm32: replace fdtdec_get by ofnode calls
  ram: stm32: add second SDRAM bank management
  ARM: DTS: stm32: remove useless mr-nbanks property
  ram: stm32: add stm32h7 support

 arch/arm/dts/stm32f746-disco.dts  |   1 -
 arch/arm/dts/stm32f769-disco.dts  |   1 -
 arch/arm/include/asm/arch-stm32f7/fmc.h   |  74 --
 board/st/stm32f746-disco/stm32f746-disco.c|   1 -
 doc/device-tree-bindings/ram/st,stm32-fmc.txt |  19 +-
 drivers/ram/stm32_sdram.c | 338 --
 6 files changed, 280 insertions(+), 154 deletions(-)
 delete mode 100644 arch/arm/include/asm/arch-stm32f7/fmc.h

-- 
1.9.1

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

Re: [U-Boot] [EXT] How to update Espressobin (U-Boot) firmware?

[Kostya Porotchkin]

Hi, Andre,

> -Original Message-
> From: Andre Przywara [mailto:andre.przyw...@arm.com]
> Sent: Tuesday, July 18, 2017 18:24
> To: Kostya Porotchkin
> Cc: Stefan Roese; Marc Zyngier; Thomas Petazzoni; Gregory CLEMENT;
> Antoine Tenart; Andreas Färber; U-Boot; Benjamin (Guodan) Huang
> Subject: Re: [EXT] How to update Espressobin (U-Boot) firmware?
> 
> Hi Kosta,
> 
> On 18/07/17 16:13, Kostya Porotchkin wrote:
> > The A37xx SoC does not support boot from SD.
> 
> Ah!
> 
> > Only boot from eMMC is supported, however your board probably only has
> soldering pads for the eMMC and not eMMC chip installed.
> > If you want to play with the bootloader without jeopardizing your SPI
> image, you have to use either UART or SATA boot mode.
> 
> Does SATA boot work like SD boot, where the boot image starts at sector
> 1? And it needs to be flagged as a SATA boot image, right?
[Konstantin Porotchkin] Correct. You can put it on LBA-1 or LBA-34 if you use 
GPT.
Just remember, this image is very special. It's actually a multipart image
that we merge into a single blob for easier usage with the u-boot "bubt" 
command.

> 
> > For the boot image build you will need to obtain the u-boot, ATF and
> the image building tools sources.
> > https://github.com/MarvellEmbeddedProcessors/atf-marvell/tree/atf-v1.3
> > -armada-17.06
> > https://github.com/MarvellEmbeddedProcessors/A3700-utils-marvell/tree/
> > A3700_utils-armada-17.06
> > https://github.com/MarvellEmbeddedProcessors/u-boot-marvell/tree/u-boo
> > t-2017.03-armada-17.06
> >
> > The "utils" git contains also the UART download tool.
> > It uses a proprietary download protocol and not xmodem one as in KW
> case.
> > The flash image structure on this platform also differs from KW, so
> please do not try to directly burn a "bin" or "kw" file created by the
> u-boot build system.
> > The ATF git from above already contains the required changes in the
> Makefile for running the additional steps of the final flash image
> formatting.
> > Additionally, the boot image contains a boot device information in its
> header, so you cannot move SPI flash image to another boot device.
> >
> > For the boot loader build instructions please check the following
> documents:
> > https://github.com/MarvellEmbeddedProcessors/atf-marvell/blob/atf-v1.3
> > -17.04/docs/marvell/build.txt
> > https://github.com/MarvellEmbeddedProcessors/u-boot-marvell/blob/u-boo
> > t-2017.03-armada-17.06/doc/mvebu/build.txt
> >
> > UART boot details:
> > https://github.com/MarvellEmbeddedProcessors/u-boot-marvell/blob/u-boo
> > t-2017.03-armada-17.06/doc/mvebu/uart_boot.txt
> 
> Thanks a ton for those links and information, that was exactly what I
> was looking for!
> Do you mind if I (later ;-) write up those steps in a document which we
> merge into the repo?
> Something like [1], which proved useful in the past just to point people
> to - that would save you some typing as well ;-)
[Konstantin Porotchkin] Sure, any additional source of information would be 
great.
I just notified the Espressobin WIKI team about urgent need for this type of 
document and for an alternative boot source usage example.
Hope the new WIKI entry will be ready shortly.

Regards
Kosta
> 
> Cheers,
> Andre.
> 
> [1]
> http://git.denx.de/?p=u-
> boot.git;a=blob;f=board/sunxi/README.sunxi64;hb=HEAD
> 
> >
> >
> > Regards
> > Kosta
> >
> >> -Original Message-
> >> From: Andre Przywara [mailto:andre.przyw...@arm.com]
> >> Sent: Tuesday, July 18, 2017 17:45
> >> To: Kostya Porotchkin
> >> Cc: Stefan Roese; Marc Zyngier; Thomas Petazzoni; Gregory CLEMENT;
> >> Antoine Tenart; Andreas Färber; U-Boot
> >> Subject: [EXT] How to update Espressobin (U-Boot) firmware?
> >>
> >> External Email
> >>
> >> -
> >> -
> >> Hi,
> >>
> >> I wanted to exploit U-Boot's EFI support on the Espressobin board, to
> >> use off-the-shelf arm64 distribution installer images. This should
> >> work with current U-Boot, which has support for the Espressobin board
> >> (and for UEFI).
> >>
> >> The firmware my board ships with seems to be built from older and
> >> non- upstream sources - and, in contrast to the Macchiatobin board -
> >> I cannot find either proper sources for all components (mv-ddr, ATF)
> >> nor
> >> *any* kind of instructions how to (re-)build and update the firmware.
> >>
> >> So I was wondering if there are any instructions or documentation I
> >> missed on how to update at least U-Boot?
> >>
> >> I see some hints that people are apparently chain-loading mainline U-
> >> Boot, is this the only way?
> >> I dumped the SPI flash and could identify the ATF FIP image on it,
> >> but I am a bit wary of bricking the board by just squashing a freshly
> >> built u- boot.bin into that - which I guess wouldn't work that easily
> anyway.
> >>
> >> And to allow experimentation: Are the boot selection jumpers actually
> >> working? Setting them to SD card (111) doesn't seem to make a

Re: [U-Boot] [EXT] How to update Espressobin (U-Boot) firmware?

[Andre Przywara]

Hi Kosta,

On 18/07/17 16:13, Kostya Porotchkin wrote:
> The A37xx SoC does not support boot from SD.

Ah!

> Only boot from eMMC is supported, however your board probably only has 
> soldering pads for the eMMC and not eMMC chip installed.
> If you want to play with the bootloader without jeopardizing your SPI image, 
> you have to use either UART or SATA boot mode.

Does SATA boot work like SD boot, where the boot image starts at sector
1? And it needs to be flagged as a SATA boot image, right?

> For the boot image build you will need to obtain the u-boot, ATF and the 
> image building tools sources.
> https://github.com/MarvellEmbeddedProcessors/atf-marvell/tree/atf-v1.3-armada-17.06
> https://github.com/MarvellEmbeddedProcessors/A3700-utils-marvell/tree/A3700_utils-armada-17.06
> https://github.com/MarvellEmbeddedProcessors/u-boot-marvell/tree/u-boot-2017.03-armada-17.06
> 
> The "utils" git contains also the UART download tool.
> It uses a proprietary download protocol and not xmodem one as in KW case.
> The flash image structure on this platform also differs from KW, so please do 
> not try to directly burn a "bin" or "kw" file created by the u-boot build 
> system.
> The ATF git from above already contains the required changes in the Makefile 
> for running the additional steps of the final flash image formatting.
> Additionally, the boot image contains a boot device information in its 
> header, so you cannot move SPI flash image to another boot device.
> 
> For the boot loader build instructions please check the following documents:
> https://github.com/MarvellEmbeddedProcessors/atf-marvell/blob/atf-v1.3-17.04/docs/marvell/build.txt
> https://github.com/MarvellEmbeddedProcessors/u-boot-marvell/blob/u-boot-2017.03-armada-17.06/doc/mvebu/build.txt
> 
> UART boot details:
> https://github.com/MarvellEmbeddedProcessors/u-boot-marvell/blob/u-boot-2017.03-armada-17.06/doc/mvebu/uart_boot.txt

Thanks a ton for those links and information, that was exactly what I
was looking for!
Do you mind if I (later ;-) write up those steps in a document which we
merge into the repo?
Something like [1], which proved useful in the past just to point people
to - that would save you some typing as well ;-)

Cheers,
Andre.

[1]
http://git.denx.de/?p=u-boot.git;a=blob;f=board/sunxi/README.sunxi64;hb=HEAD

> 
> 
> Regards
> Kosta
> 
>> -Original Message-
>> From: Andre Przywara [mailto:andre.przyw...@arm.com]
>> Sent: Tuesday, July 18, 2017 17:45
>> To: Kostya Porotchkin
>> Cc: Stefan Roese; Marc Zyngier; Thomas Petazzoni; Gregory CLEMENT;
>> Antoine Tenart; Andreas Färber; U-Boot
>> Subject: [EXT] How to update Espressobin (U-Boot) firmware?
>>
>> External Email
>>
>> --
>> Hi,
>>
>> I wanted to exploit U-Boot's EFI support on the Espressobin board, to
>> use off-the-shelf arm64 distribution installer images. This should work
>> with current U-Boot, which has support for the Espressobin board (and
>> for UEFI).
>>
>> The firmware my board ships with seems to be built from older and non-
>> upstream sources - and, in contrast to the Macchiatobin board - I cannot
>> find either proper sources for all components (mv-ddr, ATF) nor
>> *any* kind of instructions how to (re-)build and update the firmware.
>>
>> So I was wondering if there are any instructions or documentation I
>> missed on how to update at least U-Boot?
>>
>> I see some hints that people are apparently chain-loading mainline U-
>> Boot, is this the only way?
>> I dumped the SPI flash and could identify the ATF FIP image on it, but I
>> am a bit wary of bricking the board by just squashing a freshly built u-
>> boot.bin into that - which I guess wouldn't work that easily anyway.
>>
>> And to allow experimentation: Are the boot selection jumpers actually
>> working? Setting them to SD card (111) doesn't seem to make a difference
>> (it still booted off the SPI flash, apparently). Or does it fall back to
>> SPI flash in case the SD image is not valid (I put the dumped image at
>> sector 1)?
>> I see that selecting "UART" (110) gives me that "E" prompt, apparently
>> waiting for some data to be fed, but again can't tell what to do from
>> here? I take it that mkimage/kwboot won't work as is, as it needs ATF? I
>> found some mentioning of a Windows binary, but hope that's not the only
>> way to use this mode?
>>
>> I'd be very grateful for any insight into this!
>>
>> Cheers,
>> Andre.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [EXT] How to update Espressobin (U-Boot) firmware?

[Kostya Porotchkin]

Hi, Andre,

The A37xx SoC does not support boot from SD.
Only boot from eMMC is supported, however your board probably only has 
soldering pads for the eMMC and not eMMC chip installed.
If you want to play with the bootloader without jeopardizing your SPI image, 
you have to use either UART or SATA boot mode.

For the boot image build you will need to obtain the u-boot, ATF and the image 
building tools sources.
https://github.com/MarvellEmbeddedProcessors/atf-marvell/tree/atf-v1.3-armada-17.06
https://github.com/MarvellEmbeddedProcessors/A3700-utils-marvell/tree/A3700_utils-armada-17.06
https://github.com/MarvellEmbeddedProcessors/u-boot-marvell/tree/u-boot-2017.03-armada-17.06

The "utils" git contains also the UART download tool.
It uses a proprietary download protocol and not xmodem one as in KW case.
The flash image structure on this platform also differs from KW, so please do 
not try to directly burn a "bin" or "kw" file created by the u-boot build 
system.
The ATF git from above already contains the required changes in the Makefile 
for running the additional steps of the final flash image formatting.
Additionally, the boot image contains a boot device information in its header, 
so you cannot move SPI flash image to another boot device.

For the boot loader build instructions please check the following documents:
https://github.com/MarvellEmbeddedProcessors/atf-marvell/blob/atf-v1.3-17.04/docs/marvell/build.txt
https://github.com/MarvellEmbeddedProcessors/u-boot-marvell/blob/u-boot-2017.03-armada-17.06/doc/mvebu/build.txt

UART boot details:
https://github.com/MarvellEmbeddedProcessors/u-boot-marvell/blob/u-boot-2017.03-armada-17.06/doc/mvebu/uart_boot.txt


Regards
Kosta

> -Original Message-
> From: Andre Przywara [mailto:andre.przyw...@arm.com]
> Sent: Tuesday, July 18, 2017 17:45
> To: Kostya Porotchkin
> Cc: Stefan Roese; Marc Zyngier; Thomas Petazzoni; Gregory CLEMENT;
> Antoine Tenart; Andreas Färber; U-Boot
> Subject: [EXT] How to update Espressobin (U-Boot) firmware?
> 
> External Email
> 
> --
> Hi,
> 
> I wanted to exploit U-Boot's EFI support on the Espressobin board, to
> use off-the-shelf arm64 distribution installer images. This should work
> with current U-Boot, which has support for the Espressobin board (and
> for UEFI).
> 
> The firmware my board ships with seems to be built from older and non-
> upstream sources - and, in contrast to the Macchiatobin board - I cannot
> find either proper sources for all components (mv-ddr, ATF) nor
> *any* kind of instructions how to (re-)build and update the firmware.
> 
> So I was wondering if there are any instructions or documentation I
> missed on how to update at least U-Boot?
> 
> I see some hints that people are apparently chain-loading mainline U-
> Boot, is this the only way?
> I dumped the SPI flash and could identify the ATF FIP image on it, but I
> am a bit wary of bricking the board by just squashing a freshly built u-
> boot.bin into that - which I guess wouldn't work that easily anyway.
> 
> And to allow experimentation: Are the boot selection jumpers actually
> working? Setting them to SD card (111) doesn't seem to make a difference
> (it still booted off the SPI flash, apparently). Or does it fall back to
> SPI flash in case the SD image is not valid (I put the dumped image at
> sector 1)?
> I see that selecting "UART" (110) gives me that "E" prompt, apparently
> waiting for some data to be fed, but again can't tell what to do from
> here? I take it that mkimage/kwboot won't work as is, as it needs ATF? I
> found some mentioning of a Windows binary, but hope that's not the only
> way to use this mode?
> 
> I'd be very grateful for any insight into this!
> 
> Cheers,
> Andre.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot