Re: [U-Boot] [PATCH v1 0/7] Enable high speed and heavy load for DDR4 for LSCH3

[Joakim Tjernlund]

On Thu, 2015-11-05 at 12:47 -0800, York Sun wrote:
> 
> On 11/05/2015 11:53 AM, Joakim Tjernlund wrote:
> > On Thu, 2015-11-05 at 10:29 -0800, York Sun wrote:
> > > 
> > > On 11/05/2015 10:19 AM, Joakim Tjernlund wrote:
> > > > On Thu, 2015-11-05 at 09:42 -0800, York Sun wrote:
> > > > > 
> > > > > On 11/05/2015 01:55 AM, Joakim Tjernlund wrote:
> > > > > > On Thu, 2015-11-05 at 08:23 +, Yuantian Tang wrote:
> > > > > > > Hi Jocke,
> > > > > > > 
> > > > > > > we achieved deep sleep mode that did exactly what you asked for.
> > > > > > > If waken up from deep sleep, soc will resume from uboot and 
> > > > > > > re-initialized DDR controller with
> > > > > > > contents
> > > > > > > untouched.
> > > > > > > Please refer to drivers/ddr/fsl/fsl_ddr_gen4.c and look at 
> > > > > > > DEEP_SLEEP related code.
> > > > > > 
> > > > > > Looking at it now and it looks the same as for ddr3? Some questions 
> > > > > > though:
> > > > > >  289if (is_warm_boot()) {
> > > > > >  289 /* enter self-refresh */
> > > > > >  290 temp_sdram_cfg = ddr_in32(&ddr->sdram_cfg_2);
> > > > > >  291 temp_sdram_cfg |= SDRAM_CFG2_FRC_SR;
> > > > > >  292 ddr_out32(&ddr->sdram_cfg_2, temp_sdram_cfg);
> > > > > > 
> > > > > > Why do you need to force SR here? The DDR RAM must already be in SR 
> > > > > > at this point?
> > > > > > I come from CPU reset state so my DDR controller has HW default 
> > > > > > values so
> > > > > > this does not feel safe.
> > > > > 
> > > > > This may be redundant. If the code runs to this line, it should come 
> > > > > back from a
> > > > > deep sleep. The core is in reset state but the DDR controller is not. 
> > > > > It should
> > > > > be in self-refresh mode. I will leave that to Yuantian to comment.
> > > > 
> > > > OK
> > > > 
> > > > > 
> > > > > > 
> > > > > >  293 /* do board specific memory setup */
> > > > > >  294 board_mem_sleep_setup();
> > > > > >  295 
> > > > > >  296 temp_sdram_cfg = (ddr_in32(&ddr->sdram_cfg) | 
> > > > > > SDRAM_CFG_BI);
> > > > > > SDRAM_CFG_BI skips a lot(all?) init of DDR RAM. What if you want to 
> > > > > > change some DDR RAM
> > > > > > timing/config due to a bug? Then you would have to force a cold 
> > > > > > start.
> > > > > > 
> > > > > > Do you use ECC? Seems to be some issues with ECC if you skip D_INIT
> > > > > > 
> > > > > 
> > > > > To perform a warm start, the data in DDR is preserved. So you don't 
> > > > > need to init
> > > > > the data again for ECC. To preserve data, you cannot run D_INIT 
> > > > > again, which
> > > > > will destroy the data for sure.
> > > > 
> > > > yes, but what about SDRAM_CFG_BI? Why do you need to set that here?
> > > > I much rather just skip D_INIT and reconfigure DDR RAM, just in case 
> > > > one wants
> > > > to correct some aspect of DDR config in later releases and feels a lot 
> > > > more robust.
> > > > 
> > > > Our systems cannot be coldstarted just because you upgrade SW on them.
> > > 
> > > Jocke,
> > > 
> > > If your memory has been intialized, you can set [BI] bit to bypass
> > > re-initialization. It does different things than D_INIT. In short, D_INIT
> > > initialize the data, i.e. the content of DDR, while BI bypassing 
> > > initializing
> > > DDR memory (or "chip" if that is easier to understand).
> > 
> > Yes, that is what I want, reinit of chip, but not data contents.
> > I wrote why:
> > "just in case one wants to correct some aspect of DDR config in later 
> > releases and feels a lot more
> > robust"
> 
> Jocke,
> 
> I am not 100% sure. I will take this question to our DDR designer.

I am really want to know ...

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

Re: [U-Boot] aarch64-linux-gnu-objdump gives all zeros in init_sequence_f[]

[Albert ARIBAUD]

Hello Shawn,

On Thu, 12 Nov 2015 13:43:18 +0800, Shawn Guo 
wrote:
> Hi,
> 
> I need some help to understand aarch64-linux-gnu-objdump output in .data
> section as below.  It's part of the dump of u-boot image with command
> 'aarch64-linux-gnu-objdump -D -z u-boot'.
> 
> Disassembly of section .data:
> 
> 35039898 :
>   
> 
> 35039948 :
> 35039948:   .word   0x
> 3503994c:   .word   0x
> 35039950:   .word   0x
> 35039954:   .word   0x
> 35039958:   .word   0x
> 3503995c:   .word   0x
> 35039960:   .word   0x
> 35039964:   .word   0x
> 35039968:   .word   0x
> 3503996c:   .word   0x
> 35039970:   .word   0x
> 35039974:   .word   0x
> 35039978:   .word   0x
> 3503997c:   .word   0x
> 35039980:   .word   0x
> 35039984:   .word   0x
> 35039988:   .word   0x
> 3503998c:   .word   0x
> 35039990:   .word   0x
> 35039994:   .word   0x
> 35039998:   .word   0x
> 3503999c:   .word   0x
> 350399a0:   .word   0x
> 350399a4:   .word   0x
> 350399a8:   .word   0x
> 350399ac:   .word   0x
> 350399b0:   .word   0x
> 350399b4:   .word   0x
> 350399b8:   .word   0x
> 350399bc:   .word   0x
> 350399c0:   .word   0x
> 350399c4:   .word   0x
> 350399c8:   .word   0x
> 350399cc:   .word   0x
> 350399d0:   .word   0x
> 350399d4:   .word   0x
> 350399d8:   .word   0x
> 350399dc:   .word   0x
> 350399e0:   .word   0x
> 350399e4:   .word   0x
> 350399e8:   .word   0x
> 350399ec:   .word   0x
> 350399f0:   .word   0x
> 350399f4:   .word   0x
> 350399f8:   .word   0x
> 350399fc:   .word   0x
> 35039a00:   .word   0x
> 35039a04:   .word   0x
> 35039a08:   .word   0x
> 35039a0c:   .word   0x
> 35039a10:   .word   0x
> 35039a14:   .word   0x
> 35039a18:   .word   0x
> 35039a1c:   .word   0x
> 35039a20:   .word   0x
> 35039a24:   .word   0x
> 35039a28:   .word   0x
> 35039a2c:   .word   0x
> 35039a30:   .word   0x
> 35039a34:   .word   0x
> 35039a38:   .word   0x
> 35039a3c:   .word   0x
> 35039a40:   .word   0x
> 35039a44:   .word   0x
> 35039a48:   .word   0x
> 35039a4c:   .word   0x
> 
> The init_sequence_f[] is an array defined in U-Boot v2015.04 source
> common/board_f.c, which holds a bunch of pointers to critical
> initialization functions that have to be called during boot.  Obviously,
> the array cannot be all zeros like what objdump tells.  And I confirmed
> that by printing the pointers at run-time as below.
> 
> init_sequence_f[0]: 35004280
> init_sequence_f[1]: 350042a8
> init_sequence_f[2]: 35004380
> init_sequence_f[3]: 350042a0
> init_sequence_f[4]: 350044b8
> init_sequence_f[5]: 35004388
> init_sequence_f[6]: 35029538
> init_sequence_f[7]: 3500675c
> init_sequence_f[8]: 3500447c
> init_sequence_f[9]: 3501d864
> init_sequence_f[10]: 35013778
> init_sequence_f[11]: 35004398
> init_sequence_f[12]: 35028ab8
> init_sequence_f[13]: 35004278
> init_sequence_f[14]: 35004270
> init_sequence_f[15]: 3500445c
> init_sequence_f[16]: 35001f20
> init_sequence_f[17]: 35004574
> init_sequence_f[18]: 350042b0
> init_sequence_f[19]: 350042c4
> init_s

Re: [U-Boot] [RFC PATCH] lib/tiny-printf.c: Add tiny printf function for space limited environments

[Albert ARIBAUD]

Hello Stefan,

On Thu, 12 Nov 2015 04:56:32 +0100, Stefan Roese  wrote:
> Hi Albert,
> 
> On 11.11.2015 18:04, Albert ARIBAUD wrote:
> > On Wed, 11 Nov 2015 15:25:09 +0100, Stefan Roese  wrote:
> >> This patch adds a small printf() version that supports all basic formats.
> >> Its intented to be used in U-Boot SPL versions on platforms with very
> >> limited internal RAM sizes.
> >
> > It would be very useful to document CONFIG_USE_TINY_PRINTF in ./README,
> > and especially to indicate which format specifiers are supported and
> > which are not.
> 
> We're not documenting the config options in the README any more,
> if they are introduced via Kconfig.

Sorry, that's me being a dinosaur again. :)

> The help text is in Kconfig
> now. But I surely can add this info about the supported format
> specifiers, yet in v2. Just waiting for some more review comments...

Ok, thanks.

> Thanks,
> Stefan

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

Re: [U-Boot] [PATCH v2] Fix board init code to use a valid C runtime environment

[Albert ARIBAUD]

Hello Thomas,

On Thu, 12 Nov 2015 13:59:28 +0800, Thomas Chou 
wrote:
> Hi Albert,
> 
> On 2015年11月11日 02:30, Albert ARIBAUD wrote:
> > board_init_f_mem() alters the C runtime environment's
> > stack it ls actually already using. This is not a valid
> > C runtime environment.
> >
> > Split board_init_f_mem into C functions which do not
> > alter their own stack and therefore run in a valid C
> > runtime environment.
> >
> > Signed-off-by: Albert ARIBAUD 
> > ---
> > For NIOS2, this patch hopefully contains all manual
> > fixes by Thomas.
> >
> > Changes in v2:
> > - Fix all checkpatch issues
> > - Fix board_init_f_malloc prototype mismatch
> > - Fix board_init_[f_]xxx typo in NIOS2
> > - Fix aarch64 asm 'sub' syntax error
> >
> >   arch/arc/lib/start.S| 20 +---
> >   arch/arm/lib/crt0.S | 10 ++--
> >   arch/arm/lib/crt0_64.S  | 10 ++--
> >   arch/microblaze/cpu/start.S |  4 ++--
> >   arch/nios2/cpu/start.S  | 17 --
> >   arch/powerpc/cpu/ppc4xx/start.S | 18 ++
> >   arch/x86/cpu/start.S| 10 ++--
> >   arch/x86/lib/fsp/fsp_common.c   |  4 ++--
> >   common/init/board_init.c| 31 ++--
> >   include/common.h| 52 
> > +
> >   10 files changed, 125 insertions(+), 51 deletions(-)
> >
> 
> Additional fixes,
> 
> diff --git a/common/init/board_init.c b/common/init/board_init.c
> index 8839a4a..703e6d8 100644
> --- a/common/init/board_init.c
> +++ b/common/init/board_init.c
> @@ -46,6 +46,7 @@ void board_init_f_gd(struct global_data *gd_ptr)
>   for (ptr = (int *)gd_ptr; ptr < (int *)(gd_ptr + 1); )
>   *ptr++ = 0;
>   #endif
> + arch_setup_gd(gd_ptr);

Correct -- in ARM (Thumb-1 at least) we cannot use arch_setup_gd() so
we set GD (in r9) from within arch/arm/lib/crt0.S, but for NIOS2 it
might (and apparently does) work. Where is GD stored in NIOS2?


 
>   }
> 
>   ulong board_init_f_malloc_size(void)
> --
> diff --git a/arch/nios2/cpu/start.S b/arch/nios2/cpu/start.S
> index c163ce1..0adff46 100644
> --- a/arch/nios2/cpu/start.S
> +++ b/arch/nios2/cpu/start.S
> @@ -110,7 +110,7 @@ _reloc:
>   movhi   r2, %hi(board_init_f_gd_size@h)
>   ori r2, r2, %lo(board_init_f_gd_size@h)
>   callr   r2
> - sub sp, sp, r4
> + sub sp, sp, r2

Sorry, didn't know / realize the NIOS2 ABI has r2 iass the function
value return register, not r4.

>   mov r4, sp
>   movhi   r2, %hi(board_init_f_gd@h)
>   ori r2, r2, %lo(board_init_f_gd@h)
> @@ -119,16 +119,12 @@ _reloc:
>   movhi   r2, %hi(board_init_f_malloc_size@h)
>   ori r2, r2, %lo(board_init_f_malloc_size@h)
>   callr   r2
> - sub sp, sp, r4
> + sub sp, sp, r2

Ditto.

>   mov r4, sp
>   movhi   r2, %hi(board_init_f_malloc@h)
>   ori r2, r2, %lo(board_init_f_malloc@h)
>   callr   r2
> 
> - /* Update stack- and frame-pointers */
> - mov sp, r2
> - mov fp, sp
> -

Oops.

>   /* Call board_init_f -- never returns */
>   mov r4, r0
>   movhi   r2, %hi(board_init_f@h)
> 
> Otherwise,
> 
> Tested-by: Thomas Chou 
> Acked-by: Thomas Chou 
>
> Thanks.

Thanks to you; Will send a v3 to account for your and Simon's comments.

> Best regards,
> Thomas

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

Re: [U-Boot] [PATCH] ARM: crt0: Pass malloc base address

[Albert ARIBAUD]

Hello Simon,

On Wed, 11 Nov 2015 14:49:05 -0700, Simon Glass 
wrote:
> Hi Fabio,
> 
> On 11 November 2015 at 14:24, Fabio Estevam 
> wrote:
> > Hi Simon,
> >
> > On Wed, Nov 11, 2015 at 7:08 PM, Simon Glass 
> > wrote:
> >
> >> That test is intended to avoid setting up simple malloc() if we
> >> plan to use full malloc() in SPL. Of course, full malloc() is set
> >> up a little later (in spl_init()). But we should not need both -
> >> either we use simple malloc() or full malloc().
> >>
> >> But for your board I see:
> >>
> >> $ grep CONFIG_SYS_SPL_MALLOC_SIZE b/mx6sabresd_spl/u-boot.cfg
> >> #define CONFIG_SYS_SPL_MALLOC_SIZE 0x320
> >>
> >> So you will not be able to use simple malloc(). I'd suggest calling
> >> spl_init() from board_init_f() if you need malloc() there. But it
> >
> > Yes, I do call spl_init() from board_init_f() prior to calling
> > malloc() and this has been working fine prior to 5ba534d247d418.
> >
> >> presumably needs to be done after you have SDRAM up. So perhaps
> >
> > The trick here is that I need malloc to work prior to have SDRAM
> > configured.
> >
> > On cgtqmx6eval we need to read SPI NOR to determine what kind of DDR
> > we will need to configure.
> >
> > Otavio has sent the SPL support for cgtqmx6eval, but it has not
> > reached U-boot mainline yet.
> >
> > I am reproducing the problem on a mx6sabresd_spl target with the
> > simple example code I sent previously.
> 
> I see. That's not a use case I have seen before.
> 
> I'd suggest changing the #ifdef to always set up early malloc() if
> CONFIG_SYS_MALLOC_F is set. There will of course be a new malloc()
> once spi_init() is called, but that does not matter.
> 
> In your patch, please be careful to add some docs to the README on
> this point (the early malloc() is only there to permit DRAM init,
> etc.). It could get quite confusing...

I'm not sure all details are clear to me so let me chime in on this.

IIUC, what Fabio needs is a working C runtime including malloc, based on
some IRAM rather than SDRAM.

This means there will be two phases where malloc can be used, the usual
one after SDRAM init, and a new one before SDRAM init.

Of course, the amount of memory reserved for the malloc arena cannot
be the same in IRAM as it will be in SDRAM, meaning that the routine
which reserves the arena must handle both cases, by detecting whether
it is running before or after SDRAM init and choosing the right malloc
size macro, or by just bein passed that info from the code responsible
for maintaining the C runtime environment (arch/arm/lib/crt0.C in the
ARM case) -- via the 'chunk_id' method I described earlier in
https://www.mail-archive.com/u-boot@lists.denx.de/msg191898.html

There is a *VERY* *BIG* *PROBLEM* to the whole idea of
malloc-before-SDRAM:

We could manage to transfer the pre-SDRAM-init maloc arena content to
the post-SDRAM-init malloc arena, thus preserving all pre- SDRAM-init
mallocs() across the stack switch.

*BUT*: all (variable-stored) pointers to pre-SDRAM-malloc'ed space will
become dangling pointers, because we have no easy way of telling where
these pointers are and relocating them.

This means that the mallocs() done before SDRAM init are lost and that
al pointers to them /will/ become dangling, including any copies and
derivatives of these; all code which depend these pointers and their
will have to handle the situation, which will prove *quite* complex or,
to be blunter, will prove not actually done, and will prove so through
weird bugs creeping up that we'll take some time to relate to malloc
issues, and to fix.

Of course, we could just decide that any malloc done before SDRAM init
is lost and that user code should deal with it. But I fear it will do so
just as badly as it would handle the "maloc transfer" alternative I just
described. Plus, if the malloc'ed data contains hardware module state
or any non-recoverable-again information, then we *cannot* just drop
it. 

Now, there is a systemic solution: that all code which stores a
malloc-arena-based pointer value in memory call a system-provided
function which, if running pre-SDRAM-init, would record the location of
the pointer in a list; upon C environment switch from pre- to
post-SDRAM contexts, the list would be run through and each pointer
would be 'relocated' from the old to the new maloc arena. Post-init,
the functon would not do any recording. That causes a slight
performance hit on mallocs, but I don't think it'll affect boot time
that much.

Only code which has to run before SDRAM init would have to use the
function.

The benefit of this approach is that maloc'ed space would remain
malloc'ed after SDRAM init and declared pointers to it would remain
valid. Code which has to malloc before SDRAM init would not have to
re-malloc or fix anything, or even realize the stack and malloc arena
have moved, as long as it has declared its malloc-related pointer(s).

Of course the list would be limited. But seeing as we'd be running in a
tight context and

Re: [U-Boot] [RFC PATCH v2 1/2] Reserve secure memory

[Scott Wood]

On Wed, 2015-11-11 at 19:34 -0800, York Sun wrote:
> 
> On 11/11/2015 06:17 PM, Thomas Chou wrote:
> > Hi York,
> > 
> > On 2015年11月12日 06:50, York Sun wrote:
> > > diff --git a/include/asm-generic/global_data.h b/include/asm
> > > -generic/global_data.h
> > > index d0383f3..336f3a0 100644
> > > --- a/include/asm-generic/global_data.h
> > > +++ b/include/asm-generic/global_data.h
> > > @@ -58,6 +58,7 @@ typedef struct global_data {
> > > 
> > >   unsigned long relocaddr;/* Start address of U-Boot in
> > > RAM */
> > >   phys_size_t ram_size;   /* RAM size */
> > > + phys_addr_t secure_ram; /* Secure memory addr */
> > 
> > Shouldn't this be included only if CONFIG_SYS_MEM_RESERVE_SECURE ?
> 
> It can be. It will require checking CONFIG_SYS_MEM_RESERVE_SECURE every time
> this variable is used. I will add it in next version.

Why would that be better than leaving it unifdeffed?

-Scott

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

[U-Boot] [PATCH v5] colibri_vf: Add board_usb_phy_mode function

[Sanchayan Maity]

Add board_usb_phy_mode function for detecting whether a port is
being used as host or client using a GPIO. On Colibri Vybrid we
provide GPIO 102 for this very same purpose.

Signed-off-by: Sanchayan Maity 
---
Changes since v4:
No need to break after return.

Changes since v3:
Return USB_INIT_DEVICE or USB_INIT_HOST after checking for
the GPIO state to account for the fact that the previous
logic breaks in case if the enum for USB mode were to ever
be changed.

Add comments based on Stefan's feedback.

Changes since v2:

Instead of returning 0 from board_usb_phy_mode return it as
USB_INIT_HOST.

Changes since v1:

Move the GPIO request call to the board_init function as all
further calls to board_usb_phy_mode will actually result in the
gpio_request failing.
---
 board/toradex/colibri_vf/colibri_vf.c | 33 -
 1 file changed, 32 insertions(+), 1 deletion(-)

diff --git a/board/toradex/colibri_vf/colibri_vf.c 
b/board/toradex/colibri_vf/colibri_vf.c
index a6d1c5b..c65ccb3 100644
--- a/board/toradex/colibri_vf/colibri_vf.c
+++ b/board/toradex/colibri_vf/colibri_vf.c
@@ -21,6 +21,7 @@
 #include 
 #include 
 #include 
+#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -34,6 +35,7 @@ DECLARE_GLOBAL_DATA_PTR;
PAD_CTL_DSE_50ohm | PAD_CTL_OBE_IBE_ENABLE)
 
 #define USB_PEN_GPIO   83
+#define USB_CDET_GPIO  102
 
 static struct ddrmc_cr_setting colibri_vf_cr_settings[] = {
/* levelling */
@@ -92,6 +94,7 @@ static struct ddrmc_cr_setting colibri_vf_cr_settings[] = {
 
 static const iomux_v3_cfg_t usb_pads[] = {
VF610_PAD_PTD4__GPIO_83,
+   VF610_PAD_PTC29__GPIO_102,
 };
 
 int dram_init(void)
@@ -280,7 +283,6 @@ static void setup_iomux_gpio(void)
VF610_PAD_PTB23__GPIO_93,
VF610_PAD_PTB26__GPIO_96,
VF610_PAD_PTB28__GPIO_98,
-   VF610_PAD_PTC29__GPIO_102,
VF610_PAD_PTC30__GPIO_103,
VF610_PAD_PTA7__GPIO_134,
};
@@ -509,6 +511,10 @@ int board_init(void)
 
setbits_le32(&scsc->sosc_ctr, SCSC_SOSC_CTR_SOSC_EN);
 
+#ifdef CONFIG_USB_EHCI_VF
+   gpio_request(USB_CDET_GPIO, "usb-cdet-gpio");
+#endif
+
return 0;
 }
 
@@ -554,4 +560,29 @@ int board_ehci_hcd_init(int port)
}
return 0;
 }
+
+int board_usb_phy_mode(int port)
+{
+   switch (port) {
+   case 0:
+   /*
+* Port 0 is used only in client mode on Colibri Vybrid modules
+* Check for state of USB client gpio pin and accordingly return
+* USB_INIT_DEVICE or USB_INIT_HOST.
+*/
+   if (gpio_get_value(USB_CDET_GPIO))
+   return USB_INIT_DEVICE;
+   else
+   return USB_INIT_HOST;
+   case 1:
+   /* Port 1 is used only in host mode on Colibri Vybrid modules */
+   return USB_INIT_HOST;
+   default:
+   /*
+* There are only two USB controllers on Vybrid. Ideally we will
+* not reach here. However return USB_INIT_HOST if we do.
+*/
+   return USB_INIT_HOST;
+   }
+}
 #endif
-- 
2.6.2

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

Re: [U-Boot] [PATCH v2] Fix board init code to use a valid C runtime environment

[Thomas Chou]

Hi Albert,

On 2015年11月11日 02:30, Albert ARIBAUD wrote:

board_init_f_mem() alters the C runtime environment's
stack it ls actually already using. This is not a valid
C runtime environment.

Split board_init_f_mem into C functions which do not
alter their own stack and therefore run in a valid C
runtime environment.

Signed-off-by: Albert ARIBAUD 
---
For NIOS2, this patch hopefully contains all manual
fixes by Thomas.

Changes in v2:
- Fix all checkpatch issues
- Fix board_init_f_malloc prototype mismatch
- Fix board_init_[f_]xxx typo in NIOS2
- Fix aarch64 asm 'sub' syntax error

  arch/arc/lib/start.S| 20 +---
  arch/arm/lib/crt0.S | 10 ++--
  arch/arm/lib/crt0_64.S  | 10 ++--
  arch/microblaze/cpu/start.S |  4 ++--
  arch/nios2/cpu/start.S  | 17 --
  arch/powerpc/cpu/ppc4xx/start.S | 18 ++
  arch/x86/cpu/start.S| 10 ++--
  arch/x86/lib/fsp/fsp_common.c   |  4 ++--
  common/init/board_init.c| 31 ++--
  include/common.h| 52 +
  10 files changed, 125 insertions(+), 51 deletions(-)



Additional fixes,

diff --git a/common/init/board_init.c b/common/init/board_init.c
index 8839a4a..703e6d8 100644
--- a/common/init/board_init.c
+++ b/common/init/board_init.c
@@ -46,6 +46,7 @@ void board_init_f_gd(struct global_data *gd_ptr)
for (ptr = (int *)gd_ptr; ptr < (int *)(gd_ptr + 1); )
*ptr++ = 0;
 #endif
+   arch_setup_gd(gd_ptr);
 }

 ulong board_init_f_malloc_size(void)
--
diff --git a/arch/nios2/cpu/start.S b/arch/nios2/cpu/start.S
index c163ce1..0adff46 100644
--- a/arch/nios2/cpu/start.S
+++ b/arch/nios2/cpu/start.S
@@ -110,7 +110,7 @@ _reloc:
movhi   r2, %hi(board_init_f_gd_size@h)
ori r2, r2, %lo(board_init_f_gd_size@h)
callr   r2
-   sub sp, sp, r4
+   sub sp, sp, r2
mov r4, sp
movhi   r2, %hi(board_init_f_gd@h)
ori r2, r2, %lo(board_init_f_gd@h)
@@ -119,16 +119,12 @@ _reloc:
movhi   r2, %hi(board_init_f_malloc_size@h)
ori r2, r2, %lo(board_init_f_malloc_size@h)
callr   r2
-   sub sp, sp, r4
+   sub sp, sp, r2
mov r4, sp
movhi   r2, %hi(board_init_f_malloc@h)
ori r2, r2, %lo(board_init_f_malloc@h)
callr   r2

-   /* Update stack- and frame-pointers */
-   mov sp, r2
-   mov fp, sp
-
/* Call board_init_f -- never returns */
mov r4, r0
movhi   r2, %hi(board_init_f@h)

Otherwise,

Tested-by: Thomas Chou 
Acked-by: Thomas Chou 

Thanks.

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

[U-Boot] aarch64-linux-gnu-objdump gives all zeros in init_sequence_f[]

[Shawn Guo]

Hi,

I need some help to understand aarch64-linux-gnu-objdump output in .data
section as below.  It's part of the dump of u-boot image with command
'aarch64-linux-gnu-objdump -D -z u-boot'.

Disassembly of section .data:

35039898 :


35039948 :
35039948:   .word   0x
3503994c:   .word   0x
35039950:   .word   0x
35039954:   .word   0x
35039958:   .word   0x
3503995c:   .word   0x
35039960:   .word   0x
35039964:   .word   0x
35039968:   .word   0x
3503996c:   .word   0x
35039970:   .word   0x
35039974:   .word   0x
35039978:   .word   0x
3503997c:   .word   0x
35039980:   .word   0x
35039984:   .word   0x
35039988:   .word   0x
3503998c:   .word   0x
35039990:   .word   0x
35039994:   .word   0x
35039998:   .word   0x
3503999c:   .word   0x
350399a0:   .word   0x
350399a4:   .word   0x
350399a8:   .word   0x
350399ac:   .word   0x
350399b0:   .word   0x
350399b4:   .word   0x
350399b8:   .word   0x
350399bc:   .word   0x
350399c0:   .word   0x
350399c4:   .word   0x
350399c8:   .word   0x
350399cc:   .word   0x
350399d0:   .word   0x
350399d4:   .word   0x
350399d8:   .word   0x
350399dc:   .word   0x
350399e0:   .word   0x
350399e4:   .word   0x
350399e8:   .word   0x
350399ec:   .word   0x
350399f0:   .word   0x
350399f4:   .word   0x
350399f8:   .word   0x
350399fc:   .word   0x
35039a00:   .word   0x
35039a04:   .word   0x
35039a08:   .word   0x
35039a0c:   .word   0x
35039a10:   .word   0x
35039a14:   .word   0x
35039a18:   .word   0x
35039a1c:   .word   0x
35039a20:   .word   0x
35039a24:   .word   0x
35039a28:   .word   0x
35039a2c:   .word   0x
35039a30:   .word   0x
35039a34:   .word   0x
35039a38:   .word   0x
35039a3c:   .word   0x
35039a40:   .word   0x
35039a44:   .word   0x
35039a48:   .word   0x
35039a4c:   .word   0x

The init_sequence_f[] is an array defined in U-Boot v2015.04 source
common/board_f.c, which holds a bunch of pointers to critical
initialization functions that have to be called during boot.  Obviously,
the array cannot be all zeros like what objdump tells.  And I confirmed
that by printing the pointers at run-time as below.

init_sequence_f[0]: 35004280
init_sequence_f[1]: 350042a8
init_sequence_f[2]: 35004380
init_sequence_f[3]: 350042a0
init_sequence_f[4]: 350044b8
init_sequence_f[5]: 35004388
init_sequence_f[6]: 35029538
init_sequence_f[7]: 3500675c
init_sequence_f[8]: 3500447c
init_sequence_f[9]: 3501d864
init_sequence_f[10]: 35013778
init_sequence_f[11]: 35004398
init_sequence_f[12]: 35028ab8
init_sequence_f[13]: 35004278
init_sequence_f[14]: 35004270
init_sequence_f[15]: 3500445c
init_sequence_f[16]: 35001f20
init_sequence_f[17]: 35004574
init_sequence_f[18]: 350042b0
init_sequence_f[19]: 350042c4
init_sequence_f[20]: 350042cc
init_sequence_f[21]: 350042f8
init_sequence_f[22]: 350044d4
init_sequence_f[23]: 3500430c
init_sequence_f[24]: 35004314
init_sequence_f[25]: 35004330
init_sequence_f[26]: 35004390
init_sequence_f[27

[U-Boot] [RFC PATCH v3 0/2] Make most DDR non-secure in MMU while keep a small block secure

[York Sun]

This set is to change MMU tables so DDR is in non-secure mode that
non-secure master such as SDHC DMA can access the data. To mix
secure and non-secure MMU entries, the MMU tables themselves have
to be in secure memory. A small portion memory is reserved at the
end of DDR (before debug server and MC) to host secure application
and the MMU tables.

This is different from existing armv7 secure_ram_addr() solution.
U-boot can run in the middle of memory if the memory is large.
Having security memory at the very end simplifies MMU setup.

This is RFC patch, verified on LS2085AQDS only.

Changes in v3:
  Put ifdef around secure_ram
  Move defining CONFIG_SYS_MEM_RESERVE_SECURE to patch 2/2
  Replace CONFIG_FSL_PPA_RESERVED_DRAM_SIZE with CONFIG_SYS_MEM_RESERVE_SECURE
  Sanity check gd->secure_ram before using
  Define CONFIG_SYS_MEM_RESERVE_SECURE in SoC header file
  Include ls1043ardb
  Modified commit message.

Changes in v2:
  Do not use CONFIG_SYS_MEM_TOP_HIDE mechanism
  Move gd->arch.secure_ram to gd->secure_ram.
  Change the calculation of gd->secure_ram accordingly.
  Chnage commit message slightly accordingly.

Changes in v1:
  Initial patch.
  Depends on http://patchwork.ozlabs.org/patch/540248/

York Sun (2):
  Reserve secure memory
  armv8: fsl-layerscape: Make DDR non secure in MMU tables

 README|8 ++
 arch/arm/cpu/armv8/fsl-layerscape/cpu.c   |  146 +++--
 arch/arm/include/asm/arch-fsl-layerscape/config.h |6 +
 arch/arm/include/asm/arch-fsl-layerscape/cpu.h|   12 +-
 board/freescale/ls1043ardb/ddr.c  |4 +
 board/freescale/ls2085a/ddr.c |   15 +++
 board/freescale/ls2085aqds/ddr.c  |   15 +++
 board/freescale/ls2085ardb/ddr.c  |   15 +++
 common/board_f.c  |9 ++
 common/cmd_bdinfo.c   |4 +
 include/asm-generic/global_data.h |   13 ++
 11 files changed, 233 insertions(+), 14 deletions(-)

-- 
1.7.9.5

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

[U-Boot] [RFC PATCH v3 2/2] armv8: fsl-layerscape: Make DDR non secure in MMU tables

[York Sun]

DDR has been set as secure in MMU tables. Non-secure master such
as SDHC DMA cannot access data correctly. Mixing secure and non-
secure MMU entries requirs the MMU tables themselves in secure
memory. This patch moves MMU tables into a secure DDR area.

Early MMU tables are changed to set DDR as non-secure. Before
setting final MMU tables in secure DDR, existing MMU needs to be
updated with a secure DDR entry. A new table is added into final
MMU tables so secure memory can have 2MB granuality.

gd->secure_ram tracks the location of this secure memory. For
ARMv8 SoCs, the RAM base is not zero and RAM is divided into several
banks. gd->secure_ram needs to be maintained before using. This
maintenance is board-specific, depending on the SoC and memory
bank of the secure memory falls into.

"bdinfo" command shows gd->secure_ram value if this memory is marked
as secure by MMU.

Signed-off-by: York Sun 

---

Changes in v3:
  Replace CONFIG_FSL_PPA_RESERVED_DRAM_SIZE with CONFIG_SYS_MEM_RESERVE_SECURE
  Sanity check gd->secure_ram before using
  Define CONFIG_SYS_MEM_RESERVE_SECURE in SoC header file
  Include ls1043ardb
  Modified commit message.

Changes in v2:
  Move gd->arch.secure_ram to gd->secure_ram.
  Change the calculation of gd->secure_ram accordingly.
  Chnage commit message slightly accordingly.

Changes in v1: None

 arch/arm/cpu/armv8/fsl-layerscape/cpu.c   |  146 +++--
 arch/arm/include/asm/arch-fsl-layerscape/config.h |6 +
 arch/arm/include/asm/arch-fsl-layerscape/cpu.h|   12 +-
 board/freescale/ls1043ardb/ddr.c  |4 +
 board/freescale/ls2085a/ddr.c |   15 +++
 board/freescale/ls2085aqds/ddr.c  |   15 +++
 board/freescale/ls2085ardb/ddr.c  |   15 +++
 common/cmd_bdinfo.c   |4 +
 include/asm-generic/global_data.h |   11 +-
 9 files changed, 213 insertions(+), 15 deletions(-)

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c 
b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
index 9d1c70f..cda8d9b 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
@@ -207,10 +207,86 @@ static inline void early_mmu_setup(void)
 }
 
 /*
+ * Called from early mmu setup. The phys_addr needs to be in
+ * the table and aligned. This function sets the block to secure.
+ */
+static inline int fixup_early_secure_ddr(u64 *level0_table,
+phys_addr_t phys_addr)
+{
+   int ret = 0;
+#ifdef CONFIG_SYS_MEM_RESERVE_SECURE
+   struct table_info table = {};
+   struct sys_mmu_table ddr_entry = {
+   0, 0, BLOCK_SIZE_L1, MT_NORMAL, PMD_SECT_OUTER_SHARE
+   };
+
+   ddr_entry.virt_addr = phys_addr;
+   ddr_entry.phys_addr = phys_addr;
+   ret = find_table(&ddr_entry, &table, level0_table);
+   if (!ret)
+   ret = set_block_entry(&ddr_entry, &table);
+#endif
+
+   return ret;
+}
+/*
+ * Called from final mmu setup. The phys_addr is new, non-existing
+ * address. A new sub table is created @level2_table_secure.
+ */
+static inline int final_secure_ddr(u64 *level0_table,
+  u64 *level2_table_secure,
+  phys_addr_t phys_addr)
+{
+   int ret = -EINVAL;
+#ifdef CONFIG_SYS_MEM_RESERVE_SECURE
+   struct table_info table = {};
+   struct sys_mmu_table ddr_entry = {
+   0, 0, BLOCK_SIZE_L1, MT_NORMAL,
+   PMD_SECT_OUTER_SHARE | PMD_SECT_NS
+   };
+   u64 index;
+
+   /* Need to create a new table */
+   ddr_entry.virt_addr = phys_addr & ~(BLOCK_SIZE_L1 - 1);
+   ddr_entry.phys_addr = phys_addr & ~(BLOCK_SIZE_L1 - 1);
+   ret = find_table(&ddr_entry, &table, level0_table);
+   if (ret)
+   return ret;
+   index = (ddr_entry.virt_addr - table.table_base) >> SECTION_SHIFT_L1;
+   set_pgtable_table(table.ptr, index, level2_table_secure);
+   table.ptr = level2_table_secure;
+   table.table_base = ddr_entry.virt_addr;
+   table.entry_size = BLOCK_SIZE_L2;
+   ret = set_block_entry(&ddr_entry, &table);
+   if (ret) {
+   printf("MMU error: could not fill non-secure ddr block 
entries\n");
+   return ret;
+   }
+   ddr_entry.virt_addr = phys_addr;
+   ddr_entry.phys_addr = phys_addr;
+   ddr_entry.size = CONFIG_SYS_MEM_RESERVE_SECURE;
+   ddr_entry.attribute = PMD_SECT_OUTER_SHARE;
+   ret = find_table(&ddr_entry, &table, level0_table);
+   if (ret) {
+   printf("MMU error: could not find secure ddr table\n");
+   return ret;
+   }
+   ret = set_block_entry(&ddr_entry, &table);
+   if (ret)
+   printf("MMU error: could not set secure ddr block entry\n");
+#endif
+
+   return ret;
+}
+
+/*
  * The final tables look similar to early tables, but different in detail.
  * These tables are in DRAM. Su

[U-Boot] [RFC PATCH v3 1/2] Reserve secure memory

[York Sun]

Secure memory is at the end of memory, separated and reserved
from OS,  tracked by gd->secure_ram. Secure memory can host
MMU tables, security monitor, etc.

Signed-off-by: York Sun 

---

Changes in v3:
  Put ifdef around secure_ram
  Move defining CONFIG_SYS_MEM_RESERVE_SECURE to patch 2/2

Changes in v2:
  Do not use CONFIG_SYS_MEM_TOP_HIDE mechanism

Changes in v1:
  Initial patch.
  Depends on http://patchwork.ozlabs.org/patch/540248/

 README|8 
 common/board_f.c  |9 +
 include/asm-generic/global_data.h |4 
 3 files changed, 21 insertions(+)

diff --git a/README b/README
index ef8d437..61cbc82 100644
--- a/README
+++ b/README
@@ -3881,6 +3881,14 @@ Configuration Settings:
Scratch address used by the alternate memory test
You only need to set this if address zero isn't writeable
 
+- CONFIG_SYS_MEM_RESERVE_SECURE
+   If defined, the size of CONFIG_SYS_MEM_RESERVE_SECURE memory
+   is substracted from total RAM and won't be reported to OS.
+   This memory can be used as secure memory. A variable
+   gd->secure_ram is used to track the location. In systems
+   the RAM base is not zero, or RAM is divided into banks,
+   this variable needs to be recalcuated to get the address.
+
 - CONFIG_SYS_MEM_TOP_HIDE (PPC only):
If CONFIG_SYS_MEM_TOP_HIDE is defined in the board config 
header,
this specified memory area will get subtracted from the top
diff --git a/common/board_f.c b/common/board_f.c
index 725eb18..8061105 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -323,6 +323,15 @@ static int setup_dest_addr(void)
 * Ram is setup, size stored in gd !!
 */
debug("Ram size: %08lX\n", (ulong)gd->ram_size);
+#ifdef CONFIG_SYS_MEM_RESERVE_SECURE
+   /* Reserve memory for secure MMU tables, and/or security monitor */
+   gd->ram_size -= CONFIG_SYS_MEM_RESERVE_SECURE;
+   /*
+* Record secure memory location. Need recalcuate if memory splits
+* into banks, or the ram base is not zero.
+*/
+   gd->secure_ram = gd->ram_size;
+#endif
 #if defined(CONFIG_SYS_MEM_TOP_HIDE)
/*
 * Subtract specified amount of memory to hide so that it won't
diff --git a/include/asm-generic/global_data.h 
b/include/asm-generic/global_data.h
index d0383f3..8cdafd6 100644
--- a/include/asm-generic/global_data.h
+++ b/include/asm-generic/global_data.h
@@ -58,6 +58,10 @@ typedef struct global_data {
 
unsigned long relocaddr;/* Start address of U-Boot in RAM */
phys_size_t ram_size;   /* RAM size */
+#ifdef CONFIG_SYS_MEM_RESERVE_SECURE
+   /* Secure memory addr. LSB is a flag for "secured". */
+   phys_addr_t secure_ram;
+#endif
unsigned long mon_len;  /* monitor len */
unsigned long irq_sp;   /* irq stack pointer */
unsigned long start_addr_sp;/* start_addr_stackpointer */
-- 
1.7.9.5

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

Re: [U-Boot] [PATCH v3 00/12] dm: input: Move keyboard drivers to driver model

[Bin Meng]

Hi Simon,

On Thu, Nov 12, 2015 at 5:56 AM, Simon Glass  wrote:
> Hi Bin,
>
> On 11 November 2015 at 10:05, Simon Glass  wrote:
>> This series adds a new uclass for keyboards and converts some drivers
>> over to use it.
>>
>> This series includes some work to remove code duplication in the keyboard
>> drivers by updating them to use the input library (input.c). This unifies
>> the keycode decoding logic in one place. In order to do this some
>> enhancements are needed to the input library and these are also included.
>>
>> The cros_ec and tegra_kbc drivers are converted to use driver model.
>>
>> The i8042 driver is converted also, after various tidy-ups. The driver has
>> some strange interactions with the cfb_console driver. This is removed in
>> this series which is possible because the only user is x86. Some i8042
>> features have been dropped (the only deliberate one is the flashing cursor
>> which does not seem to be used by any board).
>>
>> Also the i8042 driver currently has its own keycode-decoding logic. This
>> series removes it in favour of the input library. Therefore testing of this
>> new driver would be appreciated. So far I have only been able to test on
>> link, which does not have a full keyboard. Also, while German keyboard
>> support is implemented, I am unable to test that either.
>>
>> These changes can be considered the first step towards moving stdio to
>> driver model. For that to be useful we need to convert LCD and video also.
>>
>> Note: This series is missing the code to call the update_leds() method when
>> the LEDs change. This needs to be added to keyboard_tstc() and
>> keyboard_getc(). If someone is able to test this I can send a patch for that
>> also.
>>
>> This series is available at u-boot-dm branch input-working.
>
> Can you please try testing this for your crash when pressing 'caps
> lock'? I'm not sure what is going on there and I don't have hardware
> to test with.

I've tested the v3 patch. Looks the behavior is the same as v2. Note
the crash when pressing 'caps lock' only happens in v1. Starting from
v2, pressing 'caps lock' does not light the LED, and the characters
typed is still lower case. This is the same as the 'num lock' as I
reported before.

[snip]

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

Re: [U-Boot] [RFC PATCH] lib/tiny-printf.c: Add tiny printf function for space limited environments

[Stefan Roese]

Hi Albert,

On 11.11.2015 18:04, Albert ARIBAUD wrote:

On Wed, 11 Nov 2015 15:25:09 +0100, Stefan Roese  wrote:

This patch adds a small printf() version that supports all basic formats.
Its intented to be used in U-Boot SPL versions on platforms with very
limited internal RAM sizes.


It would be very useful to document CONFIG_USE_TINY_PRINTF in ./README,
and especially to indicate which format specifiers are supported and
which are not.


We're not documenting the config options in the README any more,
if they are introduced via Kconfig. The help text is in Kconfig
now. But I surely can add this info about the supported format
specifiers, yet in v2. Just waiting for some more review comments...

Thanks,
Stefan

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

Re: [U-Boot] [PATCH v3 01/12] input: Support the German keymap

[Bin Meng]

Hi Simon,

On Thu, Nov 12, 2015 at 1:05 AM, Simon Glass  wrote:
> Add support for the German keymap, taken from i8042.c. This can be selected
> when the input library it initialised.
>
> Signed-off-by: Simon Glass 
> ---
>

Reviewed-by: Bin Meng 

Please check one nits below.

> Changes in v3:
> - Refactor the German keyboard code to use data rather than code
>
> Changes in v2:
> - Update input_add_tables() to add error checking
>
>  board/kosagi/novena/novena.c |   2 +-
>  drivers/input/cros_ec_keyb.c |   2 +-
>  drivers/input/input.c| 109 
> ++-
>  drivers/input/tegra-kbc.c|   2 +-
>  include/input.h  |   3 +-
>  5 files changed, 102 insertions(+), 16 deletions(-)
>
> diff --git a/board/kosagi/novena/novena.c b/board/kosagi/novena/novena.c
> index 4a9f724..babba85 100644
> --- a/board/kosagi/novena/novena.c
> +++ b/board/kosagi/novena/novena.c
> @@ -88,7 +88,7 @@ int drv_keyboard_init(void)
> debug("%s: Cannot set up input\n", __func__);
> return -1;
> }
> -   input_add_tables(&button_input);
> +   input_add_tables(&button_input, false);
> button_input.read_keys = novena_gpio_button_read_keys;
>
> error = input_stdio_register(&dev);
> diff --git a/drivers/input/cros_ec_keyb.c b/drivers/input/cros_ec_keyb.c
> index fe5caea..9bc4555 100644
> --- a/drivers/input/cros_ec_keyb.c
> +++ b/drivers/input/cros_ec_keyb.c
> @@ -211,7 +211,7 @@ static int cros_ec_kbd_probe(struct udevice *dev)
>
> priv->input = input;
> input->dev = dev;
> -   input_add_tables(input);
> +   input_add_tables(input, false);
> input->read_keys = cros_ec_kbc_check;
> strcpy(sdev->name, "cros-ec-keyb");
>
> diff --git a/drivers/input/input.c b/drivers/input/input.c
> index 9e552f3..96fc195 100644
> --- a/drivers/input/input.c
> +++ b/drivers/input/input.c
> @@ -79,6 +79,88 @@ static unsigned char kbd_ctrl_xlate[] = {
> '\r', 0xff, '/',  '*',
>  };
>
> +static const uchar kbd_plain_xlate_german[] = {
> +   0xff, 0x1b,  '1',  '2',  '3',  '4',  '5',  '6', /* scan 00-07 */
> +'7',  '8',  '9',  '0', 0xe1, '\'', 0x08, '\t', /* scan 08-0F */
> +'q',  'w',  'e',  'r',  't',  'z',  'u',  'i', /* scan 10-17 */
> +'o',  'p', 0x81,  '+', '\r', 0xff,  'a',  's', /* scan 18-1F */
> +'d',  'f',  'g',  'h',  'j',  'k',  'l', 0x94, /* scan 20-27 */
> +   0x84,  '^', 0xff,  '#',  'y',  'x',  'c',  'v', /* scan 28-2F */
> +'b',  'n',  'm',  ',',  '.',  '-', 0xff,  '*', /* scan 30-37 */
> +' ',  ' ', 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, /* scan 38-3F */
> +   0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,  '7', /* scan 40-47 */
> +'8',  '9',  '-',  '4',  '5',  '6',  '+',  '1', /* scan 48-4F */
> +'2',  '3',  '0',  ',', 0xff, 0xff,  '<', 0xff, /* scan 50-57 */
> +   0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, /* scan 58-5F */
> +   0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, /* scan 60-67 */
> +   0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, /* scan 68-6F */
> +   0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, /* scan 70-77 */
> +   0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, /* scan 78-7F */
> +   '\r', 0xff,  '/',  '*',
> +};
> +
> +static unsigned char kbd_shift_xlate_german[] = {
> +  0xff, 0x1b,  '!',  '"', 0x15,  '$',  '%',  '&', /* scan 00-07 */
> +'/',  '(',  ')',  '=',  '?',  '`', 0x08, '\t', /* scan 08-0F */
> +'Q',  'W',  'E',  'R',  'T',  'Z',  'U',  'I', /* scan 10-17 */
> +'O',  'P', 0x9a,  '*', '\r', 0xff,  'A',  'S', /* scan 18-1F */
> +'D',  'F',  'G',  'H',  'J',  'K',  'L', 0x99, /* scan 20-27 */
> +   0x8e, 0xf8, 0xff, '\'',  'Y',  'X',  'C',  'V', /* scan 28-2F */
> +'B',  'N',  'M',  ';',  ':',  '_', 0xff,  '*', /* scan 30-37 */
> +' ',  ' ', 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, /* scan 38-3F */
> +   0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,  '7', /* scan 40-47 */
> +'8',  '9',  '-',  '4',  '5',  '6',  '+',  '1', /* scan 48-4F */
> +'2',  '3',  '0',  ',', 0xff, 0xff,  '>', 0xff, /* scan 50-57 */
> +   0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, /* scan 58-5F */
> +   0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, /* scan 60-67 */
> +   0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, /* scan 68-6F */
> +   0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, /* scan 70-77 */
> +   0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, /* scan 78-7F */
> +   '\r', 0xff,  '/',  '*',
> +};
> +
> +static unsigned char kbd_right_alt_xlate_german[] = {
> +   0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, /* scan 00-07 */
> +'{',  '[',  ']',  '}', '\\', 0xff, 0xff, 0xff, /* scan 08-0F */
> +'@', 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, /* scan 10-17 */
> +   0xff, 0xff, 0xff,  '~', 0xff, 0xff, 0xff, 0xff, /* scan 18-1F */
> +   0xff, 0xff, 

Re: [U-Boot] [PATCH] arm: socfpga: Fix cache configuration

[Marek Vasut]

On Thursday, November 12, 2015 at 03:33:42 AM, Chin Liang See wrote:

[...]

> > > > > I just noticed, that here the L2 cache gets disabled and is not
> > > > > enabled again in function v7_outer_cache_enable(). This looks a
> > > > > bit suspicious.
> > > > > 
> > > > > Dinh, did you perhaps miss to re-enable the L2 cache after the
> > > > > aux_ctrl register setup again?
> > > > 
> > > > I guess we should pester Dinh now :-)
> > > 
> > > I recompiled the latest source and it works for me.
> > > Here is the printout message.
> > > Wonder any modification against commit a55f28624e97e1e43ac?
> > > 
> > > 
> > > U-Boot 2015.10-08073-ga55f286 (Nov 11 2015 - 23:19:06 +0800)
> > > 
> > > CPU:   Altera SoCFPGA Platform
> > > FPGA:  Altera Cyclone V, SE/A6 or SX/C6 or ST/D6, version 0x0
> > > BOOT:  SD/MMC External Transceiver (1.8V)
> > > 
> > >Watchdog enabled
> > > 
> > > I2C:   ready
> > > DRAM:  1 GiB
> > > MMC:   SOCFPGA DWMMC: 0
> > > *** Warning - bad CRC, using default environment
> > > 
> > > In:serial
> > > Out:   serial
> > > Err:   serial
> > > Model: Altera SOCFPGA Cyclone V SoC Development Kit
> > > Net:
> > > Error: ethernet@ff702000 address not set.
> > > No ethernet found.
> > > Hit any key to stop autoboot:  0
> > > => dcache
> > > Data (writethrough) Cache is ON
> > > => icache
> > > Instruction Cache is ON
> > > => usb start
> > > starting USB...
> > > USB0:   Core Release: 2.93a
> > > scanning bus 0 for devices... 2 USB Device(s) found
> > > 
> > >scanning usb for storage devices... 1 Storage Device(s) found
> > > 
> > > => usb info
> > > 1: Hub,  USB Revision 1.10
> > > 
> > >  -  U-Boot Root Hub
> > >  - Class: Hub
> > >  - PacketSize: 8  Configurations: 1
> > >  - Vendor: 0x  Product 0x Version 0.0
> > >  
> > >Configuration: 1
> > >- Interfaces: 1 Self Powered 0mA
> > >
> > >  Interface: 0
> > >  - Alternate Setting 0, Endpoints: 1
> > >  - Class Hub
> > >  - Endpoint 1 In Interrupt MaxPacket 2 Interval 255ms
> > > 
> > > 2: Mass Storage,  USB Revision 2.0
> > > 
> > >  - SanDisk  SDDR-113 9412
> > >  - Class: (from Interface) Mass Storage
> > >  - PacketSize: 64  Configurations: 1
> > >  - Vendor: 0x0781  Product 0xa7c1 Version 148.18
> > >  
> > >Configuration: 1
> > >- Interfaces: 1 Bus Powered 500mA
> > >
> > >  Interface: 0
> > >  - Alternate Setting 0, Endpoints: 2
> > >  - Class Mass Storage, Transp. SCSI, Bulk only
> > >  - Endpoint 1 In Bulk MaxPacket 512
> > >  - Endpoint 2 Out Bulk MaxPacket 512
> > 
> > Yeah, that's because you're using high-quality USB sticks which leave
> > skid marks on the USB port. Now try with some dirt cheap USB 2.0 stick.
> > 
> > 058f:6387 Alcor Micro Corp. Flash Drive
> > 
> > The thing above is my absolute fav when it comes to testing corner cases:
> > http://www.intenso.de/produkte.php?kategorie=23&&produkt=1255723475

Hi!

> It takes some amount of time for digging out a USB 2.0 stick :)

Well sorry about living in a developing country ;-)

> But it still work for me as below.
> Let me check out the code and see any clue.
> 
> 
> 2: Mass Storage,  USB Revision 2.0
>  -  USB DISK 2.0 0781076602A6
>  - Class: (from Interface) Mass Storage
>  - PacketSize: 64  Configurations: 1
>  - Vendor: 0x13fe  Product 0x1e00 Version 1.16
>Configuration: 1
>- Interfaces: 1 Bus Powered 200mA
>  Interface: 0
>  - Alternate Setting 0, Endpoints: 2
>  - Class Mass Storage, Transp. SCSI, Bulk only
>  - Endpoint 1 In Bulk MaxPacket 512
>  - Endpoint 2 Out Bulk MaxPacket 512

Fascinating. Could it be that it's only these really crappy USB sticks which
trigger some odd condition in the controller ? I will dig out the trusty SoCDK
and check it there this week.

btw. these Alcor sticks work for me in Linux 3.18.x, but seems like that's not 
always the case:
http://comments.gmane.org/gmane.linux.usb.general/86117
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [RFC PATCH v2 1/2] Reserve secure memory

[York Sun]

On 11/11/2015 06:17 PM, Thomas Chou wrote:
> Hi York,
> 
> On 2015年11月12日 06:50, York Sun wrote:
>> diff --git a/include/asm-generic/global_data.h 
>> b/include/asm-generic/global_data.h
>> index d0383f3..336f3a0 100644
>> --- a/include/asm-generic/global_data.h
>> +++ b/include/asm-generic/global_data.h
>> @@ -58,6 +58,7 @@ typedef struct global_data {
>>
>>  unsigned long relocaddr;/* Start address of U-Boot in RAM */
>>  phys_size_t ram_size;   /* RAM size */
>> +phys_addr_t secure_ram; /* Secure memory addr */
> 
> Shouldn't this be included only if CONFIG_SYS_MEM_RESERVE_SECURE ?

It can be. It will require checking CONFIG_SYS_MEM_RESERVE_SECURE every time
this variable is used. I will add it in next version.

Thanks.

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

Re: [U-Boot] [PATCH v5 01/21] rockchip: add timer driver

[hl]

Hi Ben,

On 12/11/15 10:04, Ben Chan wrote:

On Tue, Nov 10, 2015 at 2:24 AM, Lin Huang  wrote:

some rockchip soc will not include lib/timer.c in SPL stage,
so implement timer driver for some soc can use us delay function in SPL.

Signed-off-by: Lin Huang 
Acked-by: Simon Glass 
---
Changes in v1: None
Changes in v2:
- add udelay function
Changes in v3:
- fix some coding style
Changes in v4: None
Changes in v5: None

  arch/arm/include/asm/arch-rockchip/timer.h | 22 ++
  arch/arm/mach-rockchip/Makefile|  1 +
  arch/arm/mach-rockchip/board-spl.c | 21 ++---
  arch/arm/mach-rockchip/rk_timer.c  | 48 ++
  include/configs/rk3288_common.h|  3 +-
  5 files changed, 75 insertions(+), 20 deletions(-)
  create mode 100644 arch/arm/include/asm/arch-rockchip/timer.h
  create mode 100644 arch/arm/mach-rockchip/rk_timer.c

diff --git a/arch/arm/include/asm/arch-rockchip/timer.h 
b/arch/arm/include/asm/arch-rockchip/timer.h
new file mode 100644
index 000..59444d4
--- /dev/null
+++ b/arch/arm/include/asm/arch-rockchip/timer.h
@@ -0,0 +1,22 @@
+/*
+ * (C) Copyright 2015 Rockchip Electronics Co., Ltd
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#ifndef __ASM_ARCH_TIMER_H
+#define __ASM_ARCH_TIMER_H
+
+struct rk_timer {

question: should these use sized integer type?

you mean use u32, i think unsigned int is the same with u32

+   unsigned int timer_load_count0;

nit: it may be clearer to use _l / _h suffix instead of 0 / 1
it is correspond to TRM register name,  and  it can easy to find 
register in TRM.



+   unsigned int timer_load_count1;
+   unsigned int timer_curr_value0;
+   unsigned int timer_curr_value1;
+   unsigned int timer_ctrl_reg;
+   unsigned int timer_int_status;
+};
+
+void rockchip_timer_init(void);
+void rockchip_udelay(unsigned int us);
+
+#endif
diff --git a/arch/arm/mach-rockchip/Makefile b/arch/arm/mach-rockchip/Makefile
index 5a4e383..abe03a8 100644
--- a/arch/arm/mach-rockchip/Makefile
+++ b/arch/arm/mach-rockchip/Makefile
@@ -10,4 +10,5 @@ else
  obj-y += board.o
  endif
  obj-y += common.o
+obj-y += rk_timer.o
  obj-$(CONFIG_ROCKCHIP_RK3288) += rk3288/
diff --git a/arch/arm/mach-rockchip/board-spl.c 
b/arch/arm/mach-rockchip/board-spl.c
index 28c3949..0426adf 100644
--- a/arch/arm/mach-rockchip/board-spl.c
+++ b/arch/arm/mach-rockchip/board-spl.c
@@ -18,6 +18,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -110,24 +111,6 @@ static void configure_l2ctlr(void)
 write_l2ctlr(l2ctlr);
  }

-struct rk3288_timer {
-   u32 timer_load_count0;
-   u32 timer_load_count1;
-   u32 timer_curr_value0;
-   u32 timer_curr_value1;
-   u32 timer_ctrl_reg;
-   u32 timer_int_status;
-};
-
-void init_timer(void)
-{
-   struct rk3288_timer * const timer7_ptr = (void *)TIMER7_BASE;
-
-   writel(0x, &timer7_ptr->timer_load_count0);
-   writel(0x, &timer7_ptr->timer_load_count1);
-   writel(1, &timer7_ptr->timer_ctrl_reg);
-}
-
  static int configure_emmc(struct udevice *pinctrl)
  {
 struct gpio_desc desc;
@@ -197,7 +180,7 @@ void board_init_f(ulong dummy)
 hang();
 }

-   init_timer();
+   rockchip_timer_init();
 configure_l2ctlr();

 ret = uclass_get_device(UCLASS_CLK, 0, &dev);
diff --git a/arch/arm/mach-rockchip/rk_timer.c 
b/arch/arm/mach-rockchip/rk_timer.c
new file mode 100644
index 000..ae693c0
--- /dev/null
+++ b/arch/arm/mach-rockchip/rk_timer.c
@@ -0,0 +1,48 @@
+/*
+ * (C) Copyright 2015 Rockchip Electronics Co., Ltd
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+struct rk_timer * const timer_ptr = (void *)CONFIG_SYS_TIMER_BASE;
+
+static uint64_t rockchip_get_ticks(void)
+{
+   uint64_t timebase_h, timebase_l;
+
+   timebase_l = readl(&timer_ptr->timer_curr_value0);
+   timebase_h = readl(&timer_ptr->timer_curr_value1);
+
+   return timebase_h << 32 | timebase_l;
+}
+
+static unsigned int usec_to_tick(unsigned long usec)

should probably use 'uint64_t' for 'tick' and the return value,  and
use 'unsigned int' for 'usec'

Yes, you are right, will correct it next version.



+{
+   unsigned int tick = usec;
+   tick *= CONFIG_SYS_TIMER_RATE / (1000 * 1000);
+   return tick;
+}
+
+void rockchip_udelay(unsigned int us)

nit: perhaps use 'usec' instead of 'us' for consistency with usec_to_tick

Okay, will modify next version.



+{
+   uint64_t tmp;
+
+   /* get current timestamp */

nit: the comment is kind of misleadning as 'tmp' isn't the current timestamp


+   tmp = rockchip_get_ticks() + usec_to_tick(us);
+
+   /* loop till event */
+   while (rockchip_get_ticks() < tmp+1)
+   ;
+}
+
+void rockchip_timer_init(void)
+{
+   writel(0x, &timer_ptr->timer_load_count0);
+   writel(0

Re: [U-Boot] [PATCH] arm: socfpga: Fix cache configuration

[Chin Liang See]

On Thu, 2015-11-12 at 01:53 +0100, Marek Vasut wrote:
> On Thursday, November 12, 2015 at 01:49:09 AM, Chin Liang See wrote:
> > Hi Marek,
> > 
> > On Mon, 2015-11-09 at 17:02 +0100, Marek Vasut wrote:
> > > On Monday, November 09, 2015 at 04:46:54 PM, Stefan Roese wrote:
> > > > Hi Marek,
> > > 
> > > Hi!
> > > 
> > > > On 09.11.2015 14:49, Marek Vasut wrote:
> > > > 
> > > > 
> > > > 
> > > >  --- a/include/configs/socfpga_common.h
> > > >  +++ b/include/configs/socfpga_common.h
> > > >  @@ -73,7 +73,6 @@
> > > >  
> > > > /*
> > > > 
> > > >  * Cache
> > > >  */
> > > >  
> > > >  -#define CONFIG_SYS_ARM_CACHE_WRITEALLOC
> > > >  
> > > > #define CONFIG_SYS_CACHELINE_SIZE 32
> > > > #define CONFIG_SYS_L2_PL310
> > > > #define CONFIG_SYS_PL310_BASE   SOCFPGA_MPUL2_ADDRESS
> > > > >>> 
> > > > >>> I hate to say it, but I am running into issues with this patch :-(
> > > > >> 
> > > > >> I'm sorry to hear this.
> > > > >> 
> > > > >>> I use a standard USB stick here and with this patch, I am getting
> > > > >>> the following failure (with enabled and disabled cache):
> > > > >>> 
> > > > >>> => usb reset
> > > > >>> resetting USB...
> > > > >>> USB0:   Core Release: 2.93a
> > > > >>> scanning bus 0 for devices... unable to get descriptor, error 0
> > > > >>> usb_new_device: Cannot read configuration, skipping device
> > > > >>> 058f:6387 1 USB Device(s) found
> > > > >>> 
> > > > >>>  scanning usb for storage devices... 0 Storage Device(s)
> > > > >>>  found
> > > > >>> 
> > > > >>> => dcache off
> > > > >>> => usb reset
> > > > >>> resetting USB...
> > > > >>> USB0:   Core Release: 2.93a
> > > > >>> scanning bus 0 for devices... 2 USB Device(s) found
> > > > >>> 
> > > > >>>  scanning usb for storage devices... 1 Storage Device(s)
> > > > >>>  found
> > > > >>> 
> > > > >>> If I revert this patch, my USB stick works as well.
> > > > >>> 
> > > > >>> I am also aware that Stefan mentions that without this patch, cache
> > > > >>> is not enabled at all. On the other hand, I cannot find any
> > > > >>> obviously faulty behavior in the dwc2 driver, it does
> > > > >>> flush_dcache_range()/invalidate_dcache_range() in the right places.
> > > > >>> 
> > > > >>> Any ideas please ?
> > > > >> 
> > > > >> Perhaps its a timing related issue? As the code is executed faster
> > > > >> with cache enabled. Just an idea - perhaps there is still some ugly
> > > > >> code that doesn't do proper timer based loops / delays.
> > > > > 
> > > > > I doubt that's not the case. If I disable cache just around the hcdma
> > > > > bit in the driver (disable before the flush_dcache_range() and
> > > > > enable after invalidate_dcache_range() in the driver), it still
> > > > > fails.
> > > > 
> > > > Did you check if this problem is perhaps also related to Dinh's L2
> > > > cache patch:
> > > > 
> > > > 8d8e13e1 arm: socfpga: enable data/inst prefetch and shared override in
> > > > the L2
> > > > 
> > > > ?
> > > 
> > > Yes I did, but reverting this patch had no impact.
> > > 
> > > > I just noticed, that here the L2 cache gets disabled and is not
> > > > enabled again in function v7_outer_cache_enable(). This looks a
> > > > bit suspicious.
> > > > 
> > > > Dinh, did you perhaps miss to re-enable the L2 cache after the
> > > > aux_ctrl register setup again?
> > > 
> > > I guess we should pester Dinh now :-)
> > 
> > I recompiled the latest source and it works for me.
> > Here is the printout message.
> > Wonder any modification against commit a55f28624e97e1e43ac?
> > 
> > 
> > U-Boot 2015.10-08073-ga55f286 (Nov 11 2015 - 23:19:06 +0800)
> > 
> > CPU:   Altera SoCFPGA Platform
> > FPGA:  Altera Cyclone V, SE/A6 or SX/C6 or ST/D6, version 0x0
> > BOOT:  SD/MMC External Transceiver (1.8V)
> >Watchdog enabled
> > I2C:   ready
> > DRAM:  1 GiB
> > MMC:   SOCFPGA DWMMC: 0
> > *** Warning - bad CRC, using default environment
> > 
> > In:serial
> > Out:   serial
> > Err:   serial
> > Model: Altera SOCFPGA Cyclone V SoC Development Kit
> > Net:
> > Error: ethernet@ff702000 address not set.
> > No ethernet found.
> > Hit any key to stop autoboot:  0
> > => dcache
> > Data (writethrough) Cache is ON
> > => icache
> > Instruction Cache is ON
> > => usb start
> > starting USB...
> > USB0:   Core Release: 2.93a
> > scanning bus 0 for devices... 2 USB Device(s) found
> >scanning usb for storage devices... 1 Storage Device(s) found
> > => usb info
> > 1: Hub,  USB Revision 1.10
> >  -  U-Boot Root Hub
> >  - Class: Hub
> >  - PacketSize: 8  Configurations: 1
> >  - Vendor: 0x  Product 0x Version 0.0
> >Configuration: 1
> >- Interfaces: 1 Self Powered 0mA
> >  Interface: 0
> >  - Alternate Setting 0, Endpoints: 1
> >  - Class Hub
> >  - Endpoint 1 In Interrupt MaxPacket 2 Interval 255ms
> > 
> > 2: Mass Storage,  USB Revision 2.0
> >  - SanDisk  SDDR-113 9412
> >  - Clas

Re: [U-Boot] [PATCH] buildman: README: add links for toolchains not available on kernel.org

[Bin Meng]

On Thu, Nov 12, 2015 at 10:19 AM, Marek Vasut  wrote:
> On Thursday, November 12, 2015 at 02:16:05 AM, Thomas Chou wrote:
>> Hi Marek,
>
> Hi!
>
>> On 2015年11月11日 23:54, Marek Vasut wrote:
>> > On Wednesday, November 11, 2015 at 02:37:08 PM, Thomas Chou wrote:
>> >> Add links for toolchains not available on kernel.org.
>> >>
>> >> The sh4 toolchains from kernel.org dose not work for some boards,
>> >> so use the sh from Sourcery.
>> >>
>> >> Signed-off-by: Thomas Chou 
>> >
>> > Wouldn't it instead make more sense to get kernel.org to mirror those
>> > toolchains ? The links might not last forever, but I think kernel.org
>> > is not gonna go belly-up any soon.
>>
>> Agree. But I think it will be helpful to offer these links when it is
>> missing or not working on kernel.org.
>
> Sure, but if it's missing on k.org, it should just be added there too.

Adding Tony who is maintaining the kernel.org toolchains
(https://www.kernel.org/pub/tools/crosstool/)

>
>> I realized now that buildman is an effective and must-have tool. Every
>> developer should run buildman before submitting patches, though it does
>> take hours to run. The problem is that some toolchains are not easily
>> found until looking into tools/moveconfig.py. So we should make it
>> available.
>
> Yeah.
>
> Best regards,
> Marek Vasut

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

Re: [U-Boot] [PATCH v5 09/21] rockchip: rk3036: Add header files for GRF

[Ben Chan]

On Tue, Nov 10, 2015 at 2:24 AM, Lin Huang  wrote:
> GRF is the gereral register file. Add header files with register definitions.
>
> Signed-off-by: Lin Huang 
> Acked-by: Simon Glass 
> ---
> Changes in v1:
> - clean copyright announcement
> Changes in v2:
> - move some macro to grf_rk3036.h
> Changes in v3: None
> Changes in v4: None
> Changes in v5: None
>
>  arch/arm/include/asm/arch-rockchip/grf_rk3036.h | 493 
> 
>  1 file changed, 493 insertions(+)
>  create mode 100644 arch/arm/include/asm/arch-rockchip/grf_rk3036.h
>
> diff --git a/arch/arm/include/asm/arch-rockchip/grf_rk3036.h 
> b/arch/arm/include/asm/arch-rockchip/grf_rk3036.h
> new file mode 100644
> index 000..72d133c
> --- /dev/null
> +++ b/arch/arm/include/asm/arch-rockchip/grf_rk3036.h
> @@ -0,0 +1,493 @@
> +/*
> + * (C) Copyright 2015 Rockchip Electronics Co., Ltd
> + *
> + * SPDX-License-Identifier: GPL-2.0+
> + */
> +#ifndef _ASM_ARCH_GRF_RK3036_H
> +#define _ASM_ARCH_GRF_RK3036_H
> +
> +#include 
> +
> +struct rk3036_grf {
> +   unsigned int reserved[0x2a];

nit: should these use sized integer type (e.g. u32) like rk3288_grf does?

> +   unsigned int gpio0a_iomux;
> +   unsigned int gpio0b_iomux;
> +   unsigned int gpio0c_iomux;
> +   unsigned int gpio0d_iomux;
> +
> +   unsigned int gpio1a_iomux;
> +   unsigned int gpio1b_iomux;
> +   unsigned int gpio1c_iomux;
> +   unsigned int gpio1d_iomux;
> +
> +   unsigned int gpio2a_iomux;
> +   unsigned int gpio2b_iomux;
> +   unsigned int gpio2c_iomux;
> +   unsigned int gpio2d_iomux;
> +
> +   unsigned int reserved2[0x0a];
> +   unsigned int gpiods;
> +   unsigned int reserved3[0x05];
> +   unsigned int gpio0l_pull;
> +   unsigned int gpio0h_pull;
> +   unsigned int gpio1l_pull;
> +   unsigned int gpio1h_pull;
> +   unsigned int gpio2l_pull;
> +   unsigned int gpio2h_pull;
> +   unsigned int reserved4[4];
> +   unsigned int soc_con0;
> +   unsigned int soc_con1;
> +   unsigned int soc_con2;
> +   unsigned int soc_status0;
> +   unsigned int reserved5;
> +   unsigned int soc_con3;
> +   unsigned int reserved6;
> +   unsigned int dmac_con0;
> +   unsigned int dmac_con1;
> +   unsigned int dmac_con2;
> +   unsigned int reserved7[5];
> +   unsigned int uoc0_con5;
> +   unsigned int reserved8[4];
> +   unsigned int uoc1_con4;
> +   unsigned int uoc1_con5;
> +   unsigned int reserved9;
> +   unsigned int ddrc_stat;
> +   unsigned int uoc_con6;
> +   unsigned int soc_status1;
> +   unsigned int cpu_con0;
> +   unsigned int cpu_con1;
> +   unsigned int cpu_con2;
> +   unsigned int cpu_con3;
> +   unsigned int reserved10;
> +   unsigned int reserved11;
> +   unsigned int cpu_status0;
> +   unsigned int cpu_status1;
> +   unsigned int os_reg[8];
> +   unsigned int reserved12[6];
> +   unsigned int dll_con[4];
> +   unsigned int dll_status[4];
> +   unsigned int dfi_wrnum;
> +   unsigned int dfi_rdnum;
> +   unsigned int dfi_actnum;
> +   unsigned int dfi_timerval;
> +   unsigned int nfi_fifo[4];
> +   unsigned int reserved13[0x10];
> +   unsigned int usbphy0_con[8];
> +   unsigned int usbphy1_con[8];
> +   unsigned int reserved14[0x10];
> +   unsigned int chip_tag;
> +   unsigned int sdmmc_det_cnt;
> +};
> +check_member(rk3036_grf, sdmmc_det_cnt, 0x304);
> +
> +/* GRF_GPIO0A_IOMUX */
> +enum {
> +   GPIO0A3_SHIFT   = 6,
> +   GPIO0A3_MASK= 1,
> +   GPIO0A3_GPIO= 0,
> +   GPIO0A3_I2C1_SDA,
> +
> +   GPIO0A2_SHIFT   = 4,
> +   GPIO0A2_MASK= 1,
> +   GPIO0A2_GPIO= 0,
> +   GPIO0A2_I2C1_SCL,
> +
> +   GPIO0A1_SHIFT   = 2,
> +   GPIO0A1_MASK= 3,
> +   GPIO0A1_GPIO= 0,
> +   GPIO0A1_I2C0_SDA,
> +   GPIO0A1_PWM2,
> +
> +   GPIO0A0_SHIFT   = 0,
> +   GPIO0A0_MASK= 3,
> +   GPIO0A0_GPIO= 0,
> +   GPIO0A0_I2C0_SCL,
> +   GPIO0A0_PWM1,
> +
> +};
> +
> +/* GRF_GPIO0B_IOMUX */
> +enum {
> +   GPIO0B6_SHIFT   = 12,
> +   GPIO0B6_MASK= 3,
> +   GPIO0B6_GPIO= 0,
> +   GPIO0B6_MMC1_D3,
> +   GPIO0B6_I2S1_SCLK,
> +
> +   GPIO0B5_SHIFT   = 10,
> +   GPIO0B5_MASK= 3,
> +   GPIO0B5_GPIO= 0,
> +   GPIO0B5_MMC1_D2,
> +   GPIO0B5_I2S1_SDI,
> +
> +   GPIO0B4_SHIFT   = 8,
> +   GPIO0B4_MASK= 3,
> +   GPIO0B4_GPIO= 0,
> +   GPIO0B4_MMC1_D1,
> +   GPIO0B4_I2S1_LRCKTX,
> +
> +   GPIO0B3_SHIFT   = 6,
> +   GPIO0B3_MASK= 3,
> +   GPIO0B3_GPIO= 0,
> +   GPIO0B3_MMC1_D0,
> +   GPIO0B3_I2S1_LRCKRX,
> +
> +   GPIO0B1_SHIFT   = 2,
> +  

Re: [U-Boot] [PULL] Please pull u-boot-nios/master

[Tom Rini]

On Thu, Nov 12, 2015 at 08:36:57AM +0800, Thomas Chou wrote:

> Hi Tom,
> 
> Please pull,
> 
> The following changes since commit b375219e732f044e7f48b676fa4e36e7c29d81e1:
> 
>   ARM: uniphier: drop UniPhier specific SMP code (2015-11-11 23:35:35 +0900)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-nios.git master
> 
> for you to fetch changes up to 038be18fd95aa6283eafb85ceabc0b880976424b:
> 
>   nios2: add 3c120 and 10m50 devboards MAINTAINERS (2015-11-12 08:26:59 +0800)
> 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH] buildman: README: add links for toolchains not available on kernel.org

[Marek Vasut]

On Thursday, November 12, 2015 at 02:16:05 AM, Thomas Chou wrote:
> Hi Marek,

Hi!

> On 2015年11月11日 23:54, Marek Vasut wrote:
> > On Wednesday, November 11, 2015 at 02:37:08 PM, Thomas Chou wrote:
> >> Add links for toolchains not available on kernel.org.
> >> 
> >> The sh4 toolchains from kernel.org dose not work for some boards,
> >> so use the sh from Sourcery.
> >> 
> >> Signed-off-by: Thomas Chou 
> > 
> > Wouldn't it instead make more sense to get kernel.org to mirror those
> > toolchains ? The links might not last forever, but I think kernel.org
> > is not gonna go belly-up any soon.
> 
> Agree. But I think it will be helpful to offer these links when it is
> missing or not working on kernel.org.

Sure, but if it's missing on k.org, it should just be added there too.

> I realized now that buildman is an effective and must-have tool. Every
> developer should run buildman before submitting patches, though it does
> take hours to run. The problem is that some toolchains are not easily
> found until looking into tools/moveconfig.py. So we should make it
> available.

Yeah.

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

Re: [U-Boot] [RFC PATCH v2 1/2] Reserve secure memory

[Thomas Chou]

Hi York,

On 2015年11月12日 06:50, York Sun wrote:

diff --git a/include/asm-generic/global_data.h 
b/include/asm-generic/global_data.h
index d0383f3..336f3a0 100644
--- a/include/asm-generic/global_data.h
+++ b/include/asm-generic/global_data.h
@@ -58,6 +58,7 @@ typedef struct global_data {

unsigned long relocaddr;/* Start address of U-Boot in RAM */
phys_size_t ram_size;   /* RAM size */
+   phys_addr_t secure_ram; /* Secure memory addr */


Shouldn't this be included only if CONFIG_SYS_MEM_RESERVE_SECURE ?


unsigned long mon_len;  /* monitor len */
unsigned long irq_sp;   /* irq stack pointer */
unsigned long start_addr_sp;/* start_addr_stackpointer */


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

Re: [U-Boot] [PATCH v5 01/21] rockchip: add timer driver

[Ben Chan]

On Tue, Nov 10, 2015 at 2:24 AM, Lin Huang  wrote:
>
> some rockchip soc will not include lib/timer.c in SPL stage,
> so implement timer driver for some soc can use us delay function in SPL.
>
> Signed-off-by: Lin Huang 
> Acked-by: Simon Glass 
> ---
> Changes in v1: None
> Changes in v2:
> - add udelay function
> Changes in v3:
> - fix some coding style
> Changes in v4: None
> Changes in v5: None
>
>  arch/arm/include/asm/arch-rockchip/timer.h | 22 ++
>  arch/arm/mach-rockchip/Makefile|  1 +
>  arch/arm/mach-rockchip/board-spl.c | 21 ++---
>  arch/arm/mach-rockchip/rk_timer.c  | 48 
> ++
>  include/configs/rk3288_common.h|  3 +-
>  5 files changed, 75 insertions(+), 20 deletions(-)
>  create mode 100644 arch/arm/include/asm/arch-rockchip/timer.h
>  create mode 100644 arch/arm/mach-rockchip/rk_timer.c
>
> diff --git a/arch/arm/include/asm/arch-rockchip/timer.h 
> b/arch/arm/include/asm/arch-rockchip/timer.h
> new file mode 100644
> index 000..59444d4
> --- /dev/null
> +++ b/arch/arm/include/asm/arch-rockchip/timer.h
> @@ -0,0 +1,22 @@
> +/*
> + * (C) Copyright 2015 Rockchip Electronics Co., Ltd
> + *
> + * SPDX-License-Identifier: GPL-2.0+
> + */
> +
> +#ifndef __ASM_ARCH_TIMER_H
> +#define __ASM_ARCH_TIMER_H
> +
> +struct rk_timer {

question: should these use sized integer type?

> +   unsigned int timer_load_count0;

nit: it may be clearer to use _l / _h suffix instead of 0 / 1

> +   unsigned int timer_load_count1;
> +   unsigned int timer_curr_value0;
> +   unsigned int timer_curr_value1;
> +   unsigned int timer_ctrl_reg;
> +   unsigned int timer_int_status;
> +};
> +
> +void rockchip_timer_init(void);
> +void rockchip_udelay(unsigned int us);
> +
> +#endif
> diff --git a/arch/arm/mach-rockchip/Makefile b/arch/arm/mach-rockchip/Makefile
> index 5a4e383..abe03a8 100644
> --- a/arch/arm/mach-rockchip/Makefile
> +++ b/arch/arm/mach-rockchip/Makefile
> @@ -10,4 +10,5 @@ else
>  obj-y += board.o
>  endif
>  obj-y += common.o
> +obj-y += rk_timer.o
>  obj-$(CONFIG_ROCKCHIP_RK3288) += rk3288/
> diff --git a/arch/arm/mach-rockchip/board-spl.c 
> b/arch/arm/mach-rockchip/board-spl.c
> index 28c3949..0426adf 100644
> --- a/arch/arm/mach-rockchip/board-spl.c
> +++ b/arch/arm/mach-rockchip/board-spl.c
> @@ -18,6 +18,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -110,24 +111,6 @@ static void configure_l2ctlr(void)
> write_l2ctlr(l2ctlr);
>  }
>
> -struct rk3288_timer {
> -   u32 timer_load_count0;
> -   u32 timer_load_count1;
> -   u32 timer_curr_value0;
> -   u32 timer_curr_value1;
> -   u32 timer_ctrl_reg;
> -   u32 timer_int_status;
> -};
> -
> -void init_timer(void)
> -{
> -   struct rk3288_timer * const timer7_ptr = (void *)TIMER7_BASE;
> -
> -   writel(0x, &timer7_ptr->timer_load_count0);
> -   writel(0x, &timer7_ptr->timer_load_count1);
> -   writel(1, &timer7_ptr->timer_ctrl_reg);
> -}
> -
>  static int configure_emmc(struct udevice *pinctrl)
>  {
> struct gpio_desc desc;
> @@ -197,7 +180,7 @@ void board_init_f(ulong dummy)
> hang();
> }
>
> -   init_timer();
> +   rockchip_timer_init();
> configure_l2ctlr();
>
> ret = uclass_get_device(UCLASS_CLK, 0, &dev);
> diff --git a/arch/arm/mach-rockchip/rk_timer.c 
> b/arch/arm/mach-rockchip/rk_timer.c
> new file mode 100644
> index 000..ae693c0
> --- /dev/null
> +++ b/arch/arm/mach-rockchip/rk_timer.c
> @@ -0,0 +1,48 @@
> +/*
> + * (C) Copyright 2015 Rockchip Electronics Co., Ltd
> + *
> + * SPDX-License-Identifier: GPL-2.0+
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +struct rk_timer * const timer_ptr = (void *)CONFIG_SYS_TIMER_BASE;
> +
> +static uint64_t rockchip_get_ticks(void)
> +{
> +   uint64_t timebase_h, timebase_l;
> +
> +   timebase_l = readl(&timer_ptr->timer_curr_value0);
> +   timebase_h = readl(&timer_ptr->timer_curr_value1);
> +
> +   return timebase_h << 32 | timebase_l;
> +}
> +
> +static unsigned int usec_to_tick(unsigned long usec)

should probably use 'uint64_t' for 'tick' and the return value,  and
use 'unsigned int' for 'usec'

> +{
> +   unsigned int tick = usec;
> +   tick *= CONFIG_SYS_TIMER_RATE / (1000 * 1000);
> +   return tick;
> +}
> +
> +void rockchip_udelay(unsigned int us)

nit: perhaps use 'usec' instead of 'us' for consistency with usec_to_tick

> +{
> +   uint64_t tmp;
> +
> +   /* get current timestamp */

nit: the comment is kind of misleadning as 'tmp' isn't the current timestamp

> +   tmp = rockchip_get_ticks() + usec_to_tick(us);
> +
> +   /* loop till event */
> +   while (rockchip_get_ticks() < tmp+1)
> +   ;
> +}
> +
> +void rockchip_timer_init(void)
> +{
> +   writel(0x, &timer_ptr->timer_load_count0);
> +   writel(0xf

[U-Boot] [RFC PATCH v2 0/2] Make most DDR non-secure in MMU while keep a small block secure

[York Sun]

This set is to change MMU tables so DDR is in non-secure mode that
non-secure master such as SDHC DMA can access the data. To mix
secure and non-secure MMU entries, the MMU tables themselves have
to be in secure memory. A small portion memory is reserved at the
end of DDR (before debug server and MC) to host secure application
and the MMU tables.

This is different from existing armv7 secure_ram_addr() solution.
U-boot can run in the middle of memory if the memory is large.
Having security memory at the very end simplifies MMU setup.

Changes in v2:
  Do not use CONFIG_SYS_MEM_TOP_HIDE mechanism
  Move gd->arch.secure_ram to gd->secure_ram.
  Change the calculation of gd->secure_ram accordingly.
  Chnage commit message slightly accordingly.

Changes in v1:
  Initial patch.
  Depends on http://patchwork.ozlabs.org/patch/540248/

York Sun (2):
  Reserve secure memory
  armv8: fsl-layerscape: Make DDR non secure in MMU tables

 README |8 ++
 arch/arm/cpu/armv8/fsl-layerscape/cpu.c|  126 ++--
 arch/arm/include/asm/arch-fsl-layerscape/cpu.h |   12 ++-
 board/freescale/ls2085a/ddr.c  |   13 +++
 board/freescale/ls2085aqds/ddr.c   |   13 +++
 board/freescale/ls2085ardb/ddr.c   |   13 +++
 common/board_f.c   |9 ++
 common/cmd_bdinfo.c|4 +
 include/asm-generic/global_data.h  |1 +
 include/configs/ls2085a_common.h   |6 ++
 10 files changed, 192 insertions(+), 13 deletions(-)

-- 
1.7.9.5

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

Re: [U-Boot] [PATCH v2] buildman: README: add links for toolchains not available on kernel.org

[Bin Meng]

On Thu, Nov 12, 2015 at 9:29 AM, Thomas Chou  wrote:
> Add links for toolchains not available on kernel.org.
>
> The sh4 toolchains from kernel.org dose not work for some boards,
> so use the sh from Sourcery.
>
> Signed-off-by: Thomas Chou 
> ---

Reviewed-by: Bin Meng 

> v2
>   add toolchain file links.
>   add sudo to write /toolchains.
>
>  tools/buildman/README | 23 ++-
>  1 file changed, 22 insertions(+), 1 deletion(-)
>
> diff --git a/tools/buildman/README b/tools/buildman/README
> index 10c7135..66502af 100644
> --- a/tools/buildman/README
> +++ b/tools/buildman/README
> @@ -156,7 +156,6 @@ aarch64: 
> /opt/linaro/gcc-linaro-aarch64-none-elf-4.8-2013.10_linux
>  [toolchain-alias]
>  x86: i386
>  blackfin: bfin
> -sh: sh4
>  nds32: nds32le
>  openrisc: or32
>
> @@ -341,6 +340,28 @@ Testing
>   - found 
> '/home/sjg/.buildman-toolchains/gcc-4.5.1-nolibc/or32-linux/bin/or32-linux-gcc'
>  Tool chain test:  OK
>
> +Or download them all from kernel.org and move them to /toolchains directory,
> +
> +$ for i in aarch64 arm avr32 i386 m68k microblaze mips or32 powerpc sparc
> +  do
> +  ./tools/buildman/buildman --fetch-arch $i
> +  done
> +$ sudo mkdir -p /toolchains
> +$ sudo mv ~/.buildman-toolchains/*/* /toolchains/
> +
> +For those not available from kernel.org, download from the following links.
> +
> +arc: 
> https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/releases/
> +arc_gnu_2015.06_prebuilt_uclibc_le_archs_linux_install.tar.gz
> +blackfin: http://sourceforge.net/projects/adi-toolchain/files/
> +blackfin-toolchain-elf-gcc-4.5-2014R1_45-RC2.x86_64.tar.bz2
> +nds32: http://osdk.andestech.com/packages/
> +nds32le-linux-glibc-v1.tgz
> +nios2: http://sourcery.mentor.com/public/gnu_toolchain/nios2-linux-gnu/
> +sourceryg++-2015.11-27-nios2-linux-gnu-i686-pc-linux-gnu.tar.bz2
> +sh: http://sourcery.mentor.com/public/gnu_toolchain/sh-linux-gnu/
> +renesas-4.4-200-sh-linux-gnu-i686-pc-linux-gnu.tar.bz2
> +
>  Buildman should now be set up to use your new toolchain.
>
>  At the time of writing, U-Boot has these architectures:
> --

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

Re: [U-Boot] Enabling semantic parsers for host tools

[Masahiro Yamada]

Hi Michal,

2015-11-11 17:22 GMT+09:00 Michal Simek :
> Hi Masahiro,
>
> I just find out that u-boot doesn't call sparse for tools.
> Do you have any plan to support it?

Sorry, I have not cared about this area,
and I am busier for Linux these days.

Can you find some time to work for that?  Or any volunteer?

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

[U-Boot] [PATCH v2] buildman: README: add links for toolchains not available on kernel.org

[Thomas Chou]

Add links for toolchains not available on kernel.org.

The sh4 toolchains from kernel.org dose not work for some boards,
so use the sh from Sourcery.

Signed-off-by: Thomas Chou 
---
v2
  add toolchain file links.
  add sudo to write /toolchains.

 tools/buildman/README | 23 ++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/tools/buildman/README b/tools/buildman/README
index 10c7135..66502af 100644
--- a/tools/buildman/README
+++ b/tools/buildman/README
@@ -156,7 +156,6 @@ aarch64: 
/opt/linaro/gcc-linaro-aarch64-none-elf-4.8-2013.10_linux
 [toolchain-alias]
 x86: i386
 blackfin: bfin
-sh: sh4
 nds32: nds32le
 openrisc: or32
 
@@ -341,6 +340,28 @@ Testing
  - found 
'/home/sjg/.buildman-toolchains/gcc-4.5.1-nolibc/or32-linux/bin/or32-linux-gcc'
 Tool chain test:  OK
 
+Or download them all from kernel.org and move them to /toolchains directory,
+
+$ for i in aarch64 arm avr32 i386 m68k microblaze mips or32 powerpc sparc
+  do
+  ./tools/buildman/buildman --fetch-arch $i
+  done
+$ sudo mkdir -p /toolchains
+$ sudo mv ~/.buildman-toolchains/*/* /toolchains/
+
+For those not available from kernel.org, download from the following links.
+
+arc: 
https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/releases/
+arc_gnu_2015.06_prebuilt_uclibc_le_archs_linux_install.tar.gz
+blackfin: http://sourceforge.net/projects/adi-toolchain/files/
+blackfin-toolchain-elf-gcc-4.5-2014R1_45-RC2.x86_64.tar.bz2
+nds32: http://osdk.andestech.com/packages/
+nds32le-linux-glibc-v1.tgz
+nios2: http://sourcery.mentor.com/public/gnu_toolchain/nios2-linux-gnu/
+sourceryg++-2015.11-27-nios2-linux-gnu-i686-pc-linux-gnu.tar.bz2
+sh: http://sourcery.mentor.com/public/gnu_toolchain/sh-linux-gnu/
+renesas-4.4-200-sh-linux-gnu-i686-pc-linux-gnu.tar.bz2
+
 Buildman should now be set up to use your new toolchain.
 
 At the time of writing, U-Boot has these architectures:
-- 
2.5.0

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

Re: [U-Boot] [PATCH] buildman: README: add links for toolchains not available on kernel.org

[Thomas Chou]

Hi Marek,

On 2015年11月11日 23:54, Marek Vasut wrote:

On Wednesday, November 11, 2015 at 02:37:08 PM, Thomas Chou wrote:

Add links for toolchains not available on kernel.org.

The sh4 toolchains from kernel.org dose not work for some boards,
so use the sh from Sourcery.

Signed-off-by: Thomas Chou 


Wouldn't it instead make more sense to get kernel.org to mirror those
toolchains ? The links might not last forever, but I think kernel.org
is not gonna go belly-up any soon.



Agree. But I think it will be helpful to offer these links when it is 
missing or not working on kernel.org.


I realized now that buildman is an effective and must-have tool. Every 
developer should run buildman before submitting patches, though it does 
take hours to run. The problem is that some toolchains are not easily 
found until looking into tools/moveconfig.py. So we should make it 
available.


Best regards,
Thomas

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

Re: [U-Boot] [PATCH] arm: socfpga: Fix cache configuration

[Marek Vasut]

On Thursday, November 12, 2015 at 01:49:09 AM, Chin Liang See wrote:
> Hi Marek,
> 
> On Mon, 2015-11-09 at 17:02 +0100, Marek Vasut wrote:
> > On Monday, November 09, 2015 at 04:46:54 PM, Stefan Roese wrote:
> > > Hi Marek,
> > 
> > Hi!
> > 
> > > On 09.11.2015 14:49, Marek Vasut wrote:
> > > 
> > > 
> > > 
> > >  --- a/include/configs/socfpga_common.h
> > >  +++ b/include/configs/socfpga_common.h
> > >  @@ -73,7 +73,6 @@
> > >  
> > > /*
> > > 
> > >  * Cache
> > >  */
> > >  
> > >  -#define CONFIG_SYS_ARM_CACHE_WRITEALLOC
> > >  
> > > #define CONFIG_SYS_CACHELINE_SIZE 32
> > > #define CONFIG_SYS_L2_PL310
> > > #define CONFIG_SYS_PL310_BASE SOCFPGA_MPUL2_ADDRESS
> > > >>> 
> > > >>> I hate to say it, but I am running into issues with this patch :-(
> > > >> 
> > > >> I'm sorry to hear this.
> > > >> 
> > > >>> I use a standard USB stick here and with this patch, I am getting
> > > >>> the following failure (with enabled and disabled cache):
> > > >>> 
> > > >>> => usb reset
> > > >>> resetting USB...
> > > >>> USB0:   Core Release: 2.93a
> > > >>> scanning bus 0 for devices... unable to get descriptor, error 0
> > > >>> usb_new_device: Cannot read configuration, skipping device
> > > >>> 058f:6387 1 USB Device(s) found
> > > >>> 
> > > >>>  scanning usb for storage devices... 0 Storage Device(s)
> > > >>>  found
> > > >>> 
> > > >>> => dcache off
> > > >>> => usb reset
> > > >>> resetting USB...
> > > >>> USB0:   Core Release: 2.93a
> > > >>> scanning bus 0 for devices... 2 USB Device(s) found
> > > >>> 
> > > >>>  scanning usb for storage devices... 1 Storage Device(s)
> > > >>>  found
> > > >>> 
> > > >>> If I revert this patch, my USB stick works as well.
> > > >>> 
> > > >>> I am also aware that Stefan mentions that without this patch, cache
> > > >>> is not enabled at all. On the other hand, I cannot find any
> > > >>> obviously faulty behavior in the dwc2 driver, it does
> > > >>> flush_dcache_range()/invalidate_dcache_range() in the right places.
> > > >>> 
> > > >>> Any ideas please ?
> > > >> 
> > > >> Perhaps its a timing related issue? As the code is executed faster
> > > >> with cache enabled. Just an idea - perhaps there is still some ugly
> > > >> code that doesn't do proper timer based loops / delays.
> > > > 
> > > > I doubt that's not the case. If I disable cache just around the hcdma
> > > > bit in the driver (disable before the flush_dcache_range() and
> > > > enable after invalidate_dcache_range() in the driver), it still
> > > > fails.
> > > 
> > > Did you check if this problem is perhaps also related to Dinh's L2
> > > cache patch:
> > > 
> > > 8d8e13e1 arm: socfpga: enable data/inst prefetch and shared override in
> > > the L2
> > > 
> > > ?
> > 
> > Yes I did, but reverting this patch had no impact.
> > 
> > > I just noticed, that here the L2 cache gets disabled and is not
> > > enabled again in function v7_outer_cache_enable(). This looks a
> > > bit suspicious.
> > > 
> > > Dinh, did you perhaps miss to re-enable the L2 cache after the
> > > aux_ctrl register setup again?
> > 
> > I guess we should pester Dinh now :-)
> 
> I recompiled the latest source and it works for me.
> Here is the printout message.
> Wonder any modification against commit a55f28624e97e1e43ac?
> 
> 
> U-Boot 2015.10-08073-ga55f286 (Nov 11 2015 - 23:19:06 +0800)
> 
> CPU:   Altera SoCFPGA Platform
> FPGA:  Altera Cyclone V, SE/A6 or SX/C6 or ST/D6, version 0x0
> BOOT:  SD/MMC External Transceiver (1.8V)
>Watchdog enabled
> I2C:   ready
> DRAM:  1 GiB
> MMC:   SOCFPGA DWMMC: 0
> *** Warning - bad CRC, using default environment
> 
> In:serial
> Out:   serial
> Err:   serial
> Model: Altera SOCFPGA Cyclone V SoC Development Kit
> Net:
> Error: ethernet@ff702000 address not set.
> No ethernet found.
> Hit any key to stop autoboot:  0
> => dcache
> Data (writethrough) Cache is ON
> => icache
> Instruction Cache is ON
> => usb start
> starting USB...
> USB0:   Core Release: 2.93a
> scanning bus 0 for devices... 2 USB Device(s) found
>scanning usb for storage devices... 1 Storage Device(s) found
> => usb info
> 1: Hub,  USB Revision 1.10
>  -  U-Boot Root Hub
>  - Class: Hub
>  - PacketSize: 8  Configurations: 1
>  - Vendor: 0x  Product 0x Version 0.0
>Configuration: 1
>- Interfaces: 1 Self Powered 0mA
>  Interface: 0
>  - Alternate Setting 0, Endpoints: 1
>  - Class Hub
>  - Endpoint 1 In Interrupt MaxPacket 2 Interval 255ms
> 
> 2: Mass Storage,  USB Revision 2.0
>  - SanDisk  SDDR-113 9412
>  - Class: (from Interface) Mass Storage
>  - PacketSize: 64  Configurations: 1
>  - Vendor: 0x0781  Product 0xa7c1 Version 148.18
>Configuration: 1
>- Interfaces: 1 Bus Powered 500mA
>  Interface: 0
>  - Alternate Setting 0, Endpoints: 2
>  - Class Mass Storage, Transp. SCSI, Bulk only
>  - Endpoint 1 In Bulk MaxP

Re: [U-Boot] [PATCH] arm: socfpga: Fix cache configuration

[Chin Liang See]

Hi Marek,

On Mon, 2015-11-09 at 17:02 +0100, Marek Vasut wrote:
> On Monday, November 09, 2015 at 04:46:54 PM, Stefan Roese wrote:
> > Hi Marek,
> 
> Hi!
> 
> > On 09.11.2015 14:49, Marek Vasut wrote:
> > 
> > 
> > 
> >  --- a/include/configs/socfpga_common.h
> >  +++ b/include/configs/socfpga_common.h
> >  @@ -73,7 +73,6 @@
> >  
> > /*
> > 
> >  * Cache
> >  */
> >  
> >  -#define CONFIG_SYS_ARM_CACHE_WRITEALLOC
> >  
> > #define CONFIG_SYS_CACHELINE_SIZE 32
> > #define CONFIG_SYS_L2_PL310
> > #define CONFIG_SYS_PL310_BASE   SOCFPGA_MPUL2_ADDRESS
> > >>> 
> > >>> I hate to say it, but I am running into issues with this patch :-(
> > >> 
> > >> I'm sorry to hear this.
> > >> 
> > >>> I use a standard USB stick here and with this patch, I am getting the
> > >>> following failure (with enabled and disabled cache):
> > >>> 
> > >>> => usb reset
> > >>> resetting USB...
> > >>> USB0:   Core Release: 2.93a
> > >>> scanning bus 0 for devices... unable to get descriptor, error 0
> > >>> usb_new_device: Cannot read configuration, skipping device 058f:6387
> > >>> 1 USB Device(s) found
> > >>> 
> > >>>  scanning usb for storage devices... 0 Storage Device(s) found
> > >>> 
> > >>> => dcache off
> > >>> => usb reset
> > >>> resetting USB...
> > >>> USB0:   Core Release: 2.93a
> > >>> scanning bus 0 for devices... 2 USB Device(s) found
> > >>> 
> > >>>  scanning usb for storage devices... 1 Storage Device(s) found
> > >>> 
> > >>> If I revert this patch, my USB stick works as well.
> > >>> 
> > >>> I am also aware that Stefan mentions that without this patch, cache is
> > >>> not enabled at all. On the other hand, I cannot find any obviously
> > >>> faulty behavior in the dwc2 driver, it does
> > >>> flush_dcache_range()/invalidate_dcache_range() in the right places.
> > >>> 
> > >>> Any ideas please ?
> > >> 
> > >> Perhaps its a timing related issue? As the code is executed faster
> > >> with cache enabled. Just an idea - perhaps there is still some ugly
> > >> code that doesn't do proper timer based loops / delays.
> > > 
> > > I doubt that's not the case. If I disable cache just around the hcdma bit
> > > in the driver (disable before the flush_dcache_range() and enable after
> > > invalidate_dcache_range() in the driver), it still fails.
> > 
> > Did you check if this problem is perhaps also related to Dinh's L2
> > cache patch:
> > 
> > 8d8e13e1 arm: socfpga: enable data/inst prefetch and shared override in the
> > L2
> > 
> > ?
> 
> Yes I did, but reverting this patch had no impact.
> 
> > I just noticed, that here the L2 cache gets disabled and is not
> > enabled again in function v7_outer_cache_enable(). This looks a
> > bit suspicious.
> > 
> > Dinh, did you perhaps miss to re-enable the L2 cache after the
> > aux_ctrl register setup again?
> 
> I guess we should pester Dinh now :-)


I recompiled the latest source and it works for me.
Here is the printout message.
Wonder any modification against commit a55f28624e97e1e43ac?


U-Boot 2015.10-08073-ga55f286 (Nov 11 2015 - 23:19:06 +0800)

CPU:   Altera SoCFPGA Platform
FPGA:  Altera Cyclone V, SE/A6 or SX/C6 or ST/D6, version 0x0
BOOT:  SD/MMC External Transceiver (1.8V)
   Watchdog enabled
I2C:   ready
DRAM:  1 GiB
MMC:   SOCFPGA DWMMC: 0
*** Warning - bad CRC, using default environment

In:serial
Out:   serial
Err:   serial
Model: Altera SOCFPGA Cyclone V SoC Development Kit
Net:
Error: ethernet@ff702000 address not set.
No ethernet found.
Hit any key to stop autoboot:  0
=> dcache
Data (writethrough) Cache is ON
=> icache
Instruction Cache is ON
=> usb start
starting USB...
USB0:   Core Release: 2.93a
scanning bus 0 for devices... 2 USB Device(s) found
   scanning usb for storage devices... 1 Storage Device(s) found
=> usb info
1: Hub,  USB Revision 1.10
 -  U-Boot Root Hub
 - Class: Hub
 - PacketSize: 8  Configurations: 1
 - Vendor: 0x  Product 0x Version 0.0
   Configuration: 1
   - Interfaces: 1 Self Powered 0mA
 Interface: 0
 - Alternate Setting 0, Endpoints: 1
 - Class Hub
 - Endpoint 1 In Interrupt MaxPacket 2 Interval 255ms

2: Mass Storage,  USB Revision 2.0
 - SanDisk  SDDR-113 9412
 - Class: (from Interface) Mass Storage
 - PacketSize: 64  Configurations: 1
 - Vendor: 0x0781  Product 0xa7c1 Version 148.18
   Configuration: 1
   - Interfaces: 1 Bus Powered 500mA
 Interface: 0
 - Alternate Setting 0, Endpoints: 2
 - Class Mass Storage, Transp. SCSI, Bulk only
 - Endpoint 1 In Bulk MaxPacket 512
 - Endpoint 2 Out Bulk MaxPacket 512

=> fatls usb 0
nfs/
  5099520   rootfs.tar
   119858   pcie-altera.ko
gen3/
gen2/
   173733   altera_rpde.ko
   173214   altera_epde.ko
12196   dmaxfer
  4091760   zimage,ok
 2961   0002-nios2-add-max10-defconfig.patch
 6963   0001-nios2-add-max10-device-tree.patch
59026   iperf-arm
  7268512   

[U-Boot] [PULL] Please pull u-boot-nios/master

[Thomas Chou]

Hi Tom,

Please pull,

The following changes since commit b375219e732f044e7f48b676fa4e36e7c29d81e1:

  ARM: uniphier: drop UniPhier specific SMP code (2015-11-11 23:35:35 +0900)

are available in the git repository at:

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

for you to fetch changes up to 038be18fd95aa6283eafb85ceabc0b880976424b:

  nios2: add 3c120 and 10m50 devboards MAINTAINERS (2015-11-12 08:26:59 +0800)


Thomas Chou (15):
  dm: implement a MTD uclass
  cfi_flash: convert to driver model
  nios2: use cfi flash driver model
  nios2: add memcpy_fromio and memcpy_toio
  mtd: add altera quadspi driver
  nios2: nios2-generic: do not allocate rx buf in net.c
  net: zap altera_tse_initialize prototypes
  net: altera_tse: factor out stop mac func
  net: altera_tse: wait sgdma in altera_tse_recv
  net: altera_tse: add priv ops to prepare msgdma support
  net: altera_tse: add mSG-DMA support
  nios2: add 10m50 devboard support
  nios2: rename board nios2-generic to 3c120_devboard
  nios2: change README.nios2 to use 10m50 as template
  nios2: add 3c120 and 10m50 devboards MAINTAINERS

 arch/nios2/dts/10m50_devboard.dts  | 267 
 arch/nios2/include/asm/io.h|   4 +
 board/altera/nios2/MAINTAINERS |  13 +
 configs/10m50_defconfig|  26 ++
 .../{nios2-generic_defconfig => 3c120_defconfig}   |   4 +-
 doc/README.nios2   |  14 +-
 doc/device-tree-bindings/mtd/altera_qspi.txt   |  35 +++
 doc/device-tree-bindings/mtd/mtd-physmap.txt   |  88 +++
 drivers/mtd/Kconfig|  32 +++
 drivers/mtd/Makefile   |   2 +
 drivers/mtd/altera_qspi.c  | 273 +
 drivers/mtd/cfi_flash.c|  78 ++
 drivers/mtd/mtd-uclass.c   |  21 ++
 drivers/net/altera_tse.c   | 237 +++---
 drivers/net/altera_tse.h   |  80 +-
 include/configs/10m50_devboard.h   | 103 
 .../configs/{nios2-generic.h => 3c120_devboard.h}  |   6 +-
 include/dm/uclass-id.h |   1 +
 include/flash.h|   3 +
 include/linux/mtd/mtd.h|   2 +
 include/mtd.h  |  23 ++
 include/netdev.h   |   3 -
 22 files changed, 1269 insertions(+), 46 deletions(-)
 create mode 100644 arch/nios2/dts/10m50_devboard.dts
 create mode 100644 board/altera/nios2/MAINTAINERS
 create mode 100644 configs/10m50_defconfig
 rename configs/{nios2-generic_defconfig => 3c120_defconfig} (88%)
 create mode 100644 doc/device-tree-bindings/mtd/altera_qspi.txt
 create mode 100644 doc/device-tree-bindings/mtd/mtd-physmap.txt
 create mode 100644 drivers/mtd/altera_qspi.c
 create mode 100644 drivers/mtd/mtd-uclass.c
 create mode 100644 include/configs/10m50_devboard.h
 rename include/configs/{nios2-generic.h => 3c120_devboard.h} (96%)
 create mode 100644 include/mtd.h
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] board/ti/am335x: add support for BeagleBone Green

[Tom Rini]

On Wed, Nov 11, 2015 at 09:10:52AM -0600, Robert Nelson wrote:

> SeeedStudio BeagleBone Green (BBG) is clone of the BeagleBone Black (BBB) 
> minus
> the HDMI port and addition of two Grove connectors (i2c2 and usart2).
> 
> This board can be identified by the 1A value after A335BNLT (BBB) in the at24 
> eeprom:
> 1A: [aa 55 33 ee 41 33 33 35  42 4e 4c 54 1a 00 00 00 |.U3.A335BNLT|]
> 
> http://beagleboard.org/green
> http://www.seeedstudio.com/wiki/Beaglebone_green
> 
> In Mainline Kernel as of:
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=79a4e64c679d8a0b1037da174e4aea578c80c4e6
> 
> Patch tested on BeagleBone Black (rev C) and BeagleBone Green (production 
> model)
> 
> Signed-off-by: Robert Nelson 
> CC: Tom Rini 
> CC: Jason Kridner 

Reviewed-by: Tom Rini 

-- 
Tom


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

[U-Boot] how to load u-boot environment from nand while spl is loading

[Francesco Lucconi]

I'm working with imx28evk reference board with u-boot 2011.12 and for my 
specific purposes I have to load u-boot nand environment during spl 
binary is loading. I'm working with a static environment but this is not 
so useful because I need to initialize some drivers (such as serial 
console) with the current values stored within nand flash environment 
(such as baudrate variable).
Comparing my u-boot version with more recent ones (u-boot 2015.10) I've 
found out that the enviroment loading has been applied during ram 
bootstrapping...can't we do this operation before u-boot.bin has been 
loaded in ddr memory?

Could you send me any tips to solve this issue?
--
Francesco Lucconi
SW Design Dept.


Via 1° Maggio, 26
60131 Ancona - Zona Baraccola (Italy)
T: +39 071 2506590
F: +39 071 2506518
Email: francesco.lucc...@aethra.com 
Website: www.aethra.com 

NOTA BENE: Le informazioni contenute in questo messaggio sono riservate 
e sono destinate esclusivamente alle persone indicate in indirizzo o a 
chi sia stato da quelle autorizzato. La confidenzialità e la 
riservatezza non vengono in alcun modo meno neanche nel caso in cui il 
messaggio sia stato per errore trasmesso a persona o soggetto diverso 
dal destinatario e, in ogni caso, la circolazione e la riproduzione di 
questo messaggio è strettamente proibita. Se avete ricevuto questo 
messaggio per errore, vi preghiamo di contattarci immediatamente (Legge 
196/03).
PLEASE NOTE: The information contained in this message is privileged and 
confidential and is intended only for use of the addressee(s) or of 
those responsible to deliver it to the addressee(s). Neither the 
confidentiality nor any privilege attaching to this message is waived, 
lost or destroyed by reason that it has been mistakenly transmitted to a 
person or entity other than the addressee(s). Please note that any 
distribution, dissemination or copying of this message is strictly 
prohibited. In case you have received this message in error, please 
notify us immediately (Law 196/03).
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [RFC PATCH v2 1/2] Reserve secure memory

[York Sun]

Secure memory is at the end of memory, separated and reserved
from OS,  tracked by gd->secure_ram. Secure memory can host
MMU tables, security monitor, etc.

Signed-off-by: York Sun 

---

Changes in v2:
  Do not use CONFIG_SYS_MEM_TOP_HIDE mechanism

Changes in v1:
  Initial patch.
  Depends on http://patchwork.ozlabs.org/patch/540248/

 README|8 
 common/board_f.c  |9 +
 include/asm-generic/global_data.h |1 +
 include/configs/ls2085a_common.h  |6 ++
 4 files changed, 24 insertions(+)

diff --git a/README b/README
index ef8d437..61cbc82 100644
--- a/README
+++ b/README
@@ -3881,6 +3881,14 @@ Configuration Settings:
Scratch address used by the alternate memory test
You only need to set this if address zero isn't writeable
 
+- CONFIG_SYS_MEM_RESERVE_SECURE
+   If defined, the size of CONFIG_SYS_MEM_RESERVE_SECURE memory
+   is substracted from total RAM and won't be reported to OS.
+   This memory can be used as secure memory. A variable
+   gd->secure_ram is used to track the location. In systems
+   the RAM base is not zero, or RAM is divided into banks,
+   this variable needs to be recalcuated to get the address.
+
 - CONFIG_SYS_MEM_TOP_HIDE (PPC only):
If CONFIG_SYS_MEM_TOP_HIDE is defined in the board config 
header,
this specified memory area will get subtracted from the top
diff --git a/common/board_f.c b/common/board_f.c
index 725eb18..8061105 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -323,6 +323,15 @@ static int setup_dest_addr(void)
 * Ram is setup, size stored in gd !!
 */
debug("Ram size: %08lX\n", (ulong)gd->ram_size);
+#ifdef CONFIG_SYS_MEM_RESERVE_SECURE
+   /* Reserve memory for secure MMU tables, and/or security monitor */
+   gd->ram_size -= CONFIG_SYS_MEM_RESERVE_SECURE;
+   /*
+* Record secure memory location. Need recalcuate if memory splits
+* into banks, or the ram base is not zero.
+*/
+   gd->secure_ram = gd->ram_size;
+#endif
 #if defined(CONFIG_SYS_MEM_TOP_HIDE)
/*
 * Subtract specified amount of memory to hide so that it won't
diff --git a/include/asm-generic/global_data.h 
b/include/asm-generic/global_data.h
index d0383f3..336f3a0 100644
--- a/include/asm-generic/global_data.h
+++ b/include/asm-generic/global_data.h
@@ -58,6 +58,7 @@ typedef struct global_data {
 
unsigned long relocaddr;/* Start address of U-Boot in RAM */
phys_size_t ram_size;   /* RAM size */
+   phys_addr_t secure_ram; /* Secure memory addr */
unsigned long mon_len;  /* monitor len */
unsigned long irq_sp;   /* irq stack pointer */
unsigned long start_addr_sp;/* start_addr_stackpointer */
diff --git a/include/configs/ls2085a_common.h b/include/configs/ls2085a_common.h
index 0011e72..adf132c 100644
--- a/include/configs/ls2085a_common.h
+++ b/include/configs/ls2085a_common.h
@@ -75,6 +75,12 @@
 #define CONFIG_SYS_FSL_DDR_MAIN_NUM_CTRLS  2
 
 /*
+ * Reserve secure memory
+ * To be aligned with MMU block size
+ */
+#define CONFIG_SYS_MEM_RESERVE_SECURE  (2048 * 1024)   /* 2MB */
+
+/*
  * SMP Definitinos
  */
 #define CPU_RELEASE_ADDR   secondary_boot_func
-- 
1.7.9.5

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

Re: [U-Boot] [PATCH v2 18/26] dm: usb: Remove inactive children after a bus scan

[Hans de Goede]

Hi,

On 11-11-15 00:30, Simon Glass wrote:

Hi Hans,

On 9 November 2015 at 12:25, Simon Glass  wrote:

Hi Hans,

On 9 November 2015 at 00:22, Hans de Goede  wrote:

Hi,

On 09-11-15 07:48, Simon Glass wrote:


Each scan of the USB bus may return different results. Existing
driver-model
devices are reused when found, but if a device no longer exists it will
stay
around, de-activated, but bound.

Detect these devices and remove them after the scan completes.

Signed-off-by: Simon Glass 



I wonder how this is better then my original:
"dm: usb: Use device_unbind_children to clean up usb devs on stop"

Patch, the end result of both patches is the same and both are
a NOP when DM_DEVICE_REMOVE is not set. Where as my code seems
to be a much more KISS approach to the problem (my approach is
just 3 lines vs 23 lines for yours).

I know we will need usb_find_child in the DM_DEVICE_REMOVE not
set case, but why not only revert the:

"dm: usb: Rename usb_find_child to usb_find_emul_child"

commit, keep the other 2 you revert and drop this patch ?

This drops 3 patches from your patch-set and the end result is
more clean IMHO.


I would like to avoid binding/unbinding things when nothing changes if
possible. Also I'd like to support attaching device tree
nodes/properties to USB devices as necessary, as we do with PCI, and
removing things breaks that.

I still have to figure out one more test case, so I'll do that before
commenting further.


I've added the test case and pushed a new tree. However it turns out
that this doesn't behave differently.

So please can you go ahead and run your original (manual) test case?
I'd like to make sure that my automated tests are correct and catch
the bug you reported and fixed.


Ok, I've ran a whole battery of tests on your u-boot-dm/usb-working branch.

There are 2 issues:

1) You need to add these change to the commit introducing usb-keyb dm
support (or one of the related commits), otherwise usb-keyb support
breaks:

--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -513,6 +513,7 @@ config ARCH_SUNXI
select DM
select DM_GPIO
select DM_ETH
+   select DM_KEYBOARD
select DM_SERIAL
select DM_USB
select OF_CONTROL

The breakage is that without this usb_scan_device() returns -96
(EPFNOSUPPORT) for usb keyboards.

2) With that branch there still is the purely cosmetical issue,
that if one plugs a usb-stick + keyb into the same hub, then swaps
their place and do "usb reset" and then "usb tree" looks like this:

USB device tree:
  1  Hub (480 Mb/s, 100mA)
  |   USB2.0 Hub
  |
  +-3  Human Interface (1.5 Mb/s, 100mA)
  |SINO WEALTH USB Composite Device
  |
  +-2  Mass Storage (480 Mb/s, 100mA)
   USB Flash Disk 4C0E960F

Notice the order of devices listed: 1 - 3 - 2, which is a bit weird,
as said this is purely cosmetical.

Note you can easily fix this by only reverting the:

"dm: usb: Rename usb_find_child to usb_find_emul_child"

commit, and keep the other 2 you revert and dropping this patch ?

As I already suggested before, this is both more KISS and as you
can see it solves some actually (admittedly very minor) issues.

I'm not really buying your arguments for your more complex solution,
as shown above re-using the devices actually causes issues.

Your other argument of wanting to attach device-tree properties
I also do not find a strong argument, for one there has never been
a need to do so sofar, and if we ever need this we need a way
to specify which usb-device the properties belong to based on
the topology under the host / root-hub anyway, and match things
up when first scanning the bus. And if we can match things up
on the first scan we can also match them up on subsequent scans
and attach the same of-node again.

Anyways I'm fine with doing things your way, but I still have
a preference for the more KISS and IMHO robust solution of
simple unbinding all devices on usb-stop.

###

Talking about usb-stop, there is still one (BIG!) problem after
this patch set when building usb-support with DM_DEVICE_REMOVE
not set. This means that the controllers dma engines will not
be stopped when booting the actual OS and they will still be
accessing parts of the main memory while the actual OS is
booting, which is BAD. So I suggest adding something like
this to all host drivers which use dma in this way:

#if defined CONFIG_DM_USB && !defined CONFIG_DM_DEVICE_REMOVE
#error The EHCI driver cannot be used without CONFIG_DM_DEVICE_REMOVE otherwise 
DMA stays active while booting the OS
#endif

Regards,

Hans












Changes in v2: None

   drivers/usb/host/usb-uclass.c | 23 +++
   1 file changed, 23 insertions(+)

diff --git a/drivers/usb/host/usb-uclass.c b/drivers/usb/host/usb-uclass.c
index 4aa92f8..50538e0 100644
--- a/drivers/usb/host/usb-uclass.c
+++ b/drivers/usb/host/usb-uclass.c
@@ -202,6 +202,20 @@ static void usb_scan_bus(struct udevice *bus, bool
recurse)
 printf("%d USB Device(s) found

[U-Boot] [RFC PATCH v2 2/2] armv8: fsl-layerscape: Make DDR non secure in MMU tables

[York Sun]

DDR has been set as secure in MMU tables. Non-secure master such
as SDHC DMA cannot access data correctly. Mixing secure and non-
secure MMU entries requirs the MMU tables themselves in secure
memory. This patch moves MMU tables into a secure DDR area.

Early MMU tables are changed to set DDR as non-secure. Before
setting final MMU tables in secure DDR, existing MMU needs to be
updated with a secure DDR entry. A new table is added into final
MMU tables so secure memory can have 2MB granuality.

"bdinfo" command shows gd->secure_ram value.

Signed-off-by: York Sun 

---

Changes in v2:
  Move gd->arch.secure_ram to gd->secure_ram.
  Change the calculation of gd->secure_ram accordingly.
  Chnage commit message slightly accordingly.

Changes in v1: None

 arch/arm/cpu/armv8/fsl-layerscape/cpu.c|  126 ++--
 arch/arm/include/asm/arch-fsl-layerscape/cpu.h |   12 ++-
 board/freescale/ls2085a/ddr.c  |   13 +++
 board/freescale/ls2085aqds/ddr.c   |   13 +++
 board/freescale/ls2085ardb/ddr.c   |   13 +++
 common/cmd_bdinfo.c|4 +
 6 files changed, 168 insertions(+), 13 deletions(-)

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c 
b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
index 9d1c70f..a372b3f 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
@@ -207,10 +207,86 @@ static inline void early_mmu_setup(void)
 }
 
 /*
+ * Called from early mmu setup. The phys_addr needs to be in
+ * the table and aligned. This function sets the block to secure.
+ */
+static inline int fixup_early_secure_ddr(u64 *level0_table,
+phys_addr_t phys_addr)
+{
+   int ret = 0;
+#ifdef CONFIG_FSL_PPA_RESERVED_DRAM_SIZE
+   struct table_info table = {};
+   struct sys_mmu_table ddr_entry = {
+   0, 0, BLOCK_SIZE_L1, MT_NORMAL, PMD_SECT_OUTER_SHARE
+   };
+
+   ddr_entry.virt_addr = phys_addr;
+   ddr_entry.phys_addr = phys_addr;
+   ret = find_table(&ddr_entry, &table, level0_table);
+   if (!ret)
+   ret = set_block_entry(&ddr_entry, &table);
+#endif
+
+   return ret;
+}
+/*
+ * Called from final mmu setup. The phys_addr is new, non-existing
+ * address. A new sub table is created @level2_table_secure.
+ */
+static inline int final_secure_ddr(u64 *level0_table,
+  u64 *level2_table_secure,
+  phys_addr_t phys_addr)
+{
+   int ret = 0;
+#ifdef CONFIG_FSL_PPA_RESERVED_DRAM_SIZE
+   struct table_info table = {};
+   struct sys_mmu_table ddr_entry = {
+   0, 0, BLOCK_SIZE_L1, MT_NORMAL,
+   PMD_SECT_OUTER_SHARE | PMD_SECT_NS
+   };
+   u64 index;
+
+   /* Need to create a new table */
+   ddr_entry.virt_addr = phys_addr & ~(BLOCK_SIZE_L1 - 1);
+   ddr_entry.phys_addr = phys_addr & ~(BLOCK_SIZE_L1 - 1);
+   ret = find_table(&ddr_entry, &table, level0_table);
+   if (ret)
+   return ret;
+   index = (ddr_entry.virt_addr - table.table_base) >> SECTION_SHIFT_L1;
+   set_pgtable_table(table.ptr, index, level2_table_secure);
+   table.ptr = level2_table_secure;
+   table.table_base = ddr_entry.virt_addr;
+   table.entry_size = BLOCK_SIZE_L2;
+   ret = set_block_entry(&ddr_entry, &table);
+   if (ret) {
+   printf("MMU error: could not fill non-secure ddr block 
entries\n");
+   return ret;
+   }
+   ddr_entry.virt_addr = phys_addr;
+   ddr_entry.phys_addr = phys_addr;
+   ddr_entry.size = CONFIG_FSL_PPA_RESERVED_DRAM_SIZE;
+   ddr_entry.attribute = PMD_SECT_OUTER_SHARE;
+   ret = find_table(&ddr_entry, &table, level0_table);
+   if (ret) {
+   printf("MMU error: could not find secure ddr table\n");
+   return ret;
+   }
+   ret = set_block_entry(&ddr_entry, &table);
+   if (ret)
+   printf("MMU error: could not set secure ddr block entry\n");
+#endif
+
+   return ret;
+}
+
+/*
  * The final tables look similar to early tables, but different in detail.
  * These tables are in DRAM. Sub tables are added to enable cache for
  * QBMan and OCRAM.
  *
+ * Put the MMU table in secure memory if gd->secure_ram is set.
+ * OCRAM will be not used for this purpose so gd->secure_ram can't be 0.
+ *
  * Level 1 table 0 contains 512 entries for each 1GB from 0 to 512GB.
  * Level 1 table 1 contains 512 entries for each 1GB from 512GB to 1TB.
  * Level 2 table 0 contains 512 entries for each 2MB from 0 to 1GB.
@@ -224,17 +300,35 @@ static inline void early_mmu_setup(void)
 static inline void final_mmu_setup(void)
 {
unsigned int el, i;
-   u64 *level0_table = (u64 *)gd->arch.tlb_addr;
-   u64 *level1_table0 = (u64 *)(gd->arch.tlb_addr + 0x1000);
-   u64 *level1_table1 = (u64 *)(gd->arch.tlb_addr + 0x2000);
-   u64 *level2_table0 = (

Re: [U-Boot] [PATCH 2/2] README: Add more clarification about CONFIG_SYS_SPL_MALLOC_START

[Simon Glass]

Hi Fabio,

On 11 November 2015 at 15:15, Fabio Estevam  wrote:
> From: Fabio Estevam 
>
> Make clear that when the user selects CONFIG_SYS_SPL_MALLOC_START the
> full malloc will be used in SPL and also that this malloc pool
> can be used prior to configuring SPL.
>
> Signed-off-by: Fabio Estevam 
> ---
>  README | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/README b/README
> index ef8d437..4f3dd13 100644
> --- a/README
> +++ b/README
> @@ -3568,6 +3568,8 @@ FIT uImage format:
>
> CONFIG_SYS_SPL_MALLOC_START
> Starting address of the malloc pool used in SPL.
> +   When this option is set the full malloc is used in SPL.
> +   This malloc pool can be used prior to DRAM initialization.

This is the 'full' malloc(). So I think you need to mention that this
is set up by spl_init(), and before that, the simple malloc() can be
used if CONFIG_SYS_MALLOC_F is defined.

There is great potential for confusion so I'd like the docs to be very clear.

>
> CONFIG_SYS_SPL_MALLOC_SIZE
> The size of the malloc pool used in SPL.
> --
> 1.9.1
>

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

Re: [U-Boot] [PATCH 1/2] board_init: Fix the logic to setup malloc_base

[Simon Glass]

Hi Fabio,

On 11 November 2015 at 15:15, Fabio Estevam  wrote:
> From: Fabio Estevam 
>
> Prior to commit 5ba534d247d418 ("arm: Switch 32-bit ARM to using generic
> global_data setup") we used to have assembly code that configured the
> malloc_base address.
>
> After this commit we use the board_init_f_mem() function in C to setup
> malloc_base address.
>
> However the ifdef logic has a problem that prevents malloc_base to be
> configured in the SPL case.

Would you mind rewording this a bit to avoid confusion? The point here
is that a deliberate choice was made to support only early malloc() or
full malloc() in SPL, but not both. The point of your change is to
allow both to be used, one after the other, in SPL.

>
> This issue has been observed in a Congatec board, where we need to
> retrieve the manufacturing information from the SPI NOR (the SPI API
> calls malloc) prior to configuring the DRAM. In this case as malloc_base
> was not configured we always see malloc to fail.
>
> Adjust the ifdef logic so that malloc_base is always configured when
> CONFIG_SYS_MALLOC_F is set.
>
> Signed-off-by: Fabio Estevam 
> ---
>  common/init/board_init.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/common/init/board_init.c b/common/init/board_init.c
> index e74b63b..1c6126d 100644
> --- a/common/init/board_init.c
> +++ b/common/init/board_init.c
> @@ -50,8 +50,7 @@ ulong board_init_f_mem(ulong top)
>  #endif
> arch_setup_gd(gd_ptr);
>
> -#if defined(CONFIG_SYS_MALLOC_F) && \
> -   (!defined(CONFIG_SPL_BUILD) || !defined(CONFIG_SYS_SPL_MALLOC_START))
> +#if defined(CONFIG_SYS_MALLOC_F)
> top -= CONFIG_SYS_MALLOC_F_LEN;
> gd->malloc_base = top;
>  #endif
> --
> 1.9.1
>

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

[U-Boot] [PATCH 1/2] board_init: Fix the logic to setup malloc_base

[Fabio Estevam]

From: Fabio Estevam 

Prior to commit 5ba534d247d418 ("arm: Switch 32-bit ARM to using generic
global_data setup") we used to have assembly code that configured the
malloc_base address.

After this commit we use the board_init_f_mem() function in C to setup
malloc_base address.

However the ifdef logic has a problem that prevents malloc_base to be
configured in the SPL case.

This issue has been observed in a Congatec board, where we need to
retrieve the manufacturing information from the SPI NOR (the SPI API 
calls malloc) prior to configuring the DRAM. In this case as malloc_base
was not configured we always see malloc to fail.

Adjust the ifdef logic so that malloc_base is always configured when
CONFIG_SYS_MALLOC_F is set.

Signed-off-by: Fabio Estevam 
---
 common/init/board_init.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/common/init/board_init.c b/common/init/board_init.c
index e74b63b..1c6126d 100644
--- a/common/init/board_init.c
+++ b/common/init/board_init.c
@@ -50,8 +50,7 @@ ulong board_init_f_mem(ulong top)
 #endif
arch_setup_gd(gd_ptr);
 
-#if defined(CONFIG_SYS_MALLOC_F) && \
-   (!defined(CONFIG_SPL_BUILD) || !defined(CONFIG_SYS_SPL_MALLOC_START))
+#if defined(CONFIG_SYS_MALLOC_F)
top -= CONFIG_SYS_MALLOC_F_LEN;
gd->malloc_base = top;
 #endif
-- 
1.9.1

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

[U-Boot] [PATCH 2/2] README: Add more clarification about CONFIG_SYS_SPL_MALLOC_START

[Fabio Estevam]

From: Fabio Estevam 

Make clear that when the user selects CONFIG_SYS_SPL_MALLOC_START the
full malloc will be used in SPL and also that this malloc pool
can be used prior to configuring SPL.

Signed-off-by: Fabio Estevam 
---
 README | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/README b/README
index ef8d437..4f3dd13 100644
--- a/README
+++ b/README
@@ -3568,6 +3568,8 @@ FIT uImage format:
 
CONFIG_SYS_SPL_MALLOC_START
Starting address of the malloc pool used in SPL.
+   When this option is set the full malloc is used in SPL.
+   This malloc pool can be used prior to DRAM initialization.
 
CONFIG_SYS_SPL_MALLOC_SIZE
The size of the malloc pool used in SPL.
-- 
1.9.1

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

Re: [U-Boot] [PATCH v3 00/12] dm: input: Move keyboard drivers to driver model

[Simon Glass]

Hi Bin,

On 11 November 2015 at 10:05, Simon Glass  wrote:
> This series adds a new uclass for keyboards and converts some drivers
> over to use it.
>
> This series includes some work to remove code duplication in the keyboard
> drivers by updating them to use the input library (input.c). This unifies
> the keycode decoding logic in one place. In order to do this some
> enhancements are needed to the input library and these are also included.
>
> The cros_ec and tegra_kbc drivers are converted to use driver model.
>
> The i8042 driver is converted also, after various tidy-ups. The driver has
> some strange interactions with the cfb_console driver. This is removed in
> this series which is possible because the only user is x86. Some i8042
> features have been dropped (the only deliberate one is the flashing cursor
> which does not seem to be used by any board).
>
> Also the i8042 driver currently has its own keycode-decoding logic. This
> series removes it in favour of the input library. Therefore testing of this
> new driver would be appreciated. So far I have only been able to test on
> link, which does not have a full keyboard. Also, while German keyboard
> support is implemented, I am unable to test that either.
>
> These changes can be considered the first step towards moving stdio to
> driver model. For that to be useful we need to convert LCD and video also.
>
> Note: This series is missing the code to call the update_leds() method when
> the LEDs change. This needs to be added to keyboard_tstc() and
> keyboard_getc(). If someone is able to test this I can send a patch for that
> also.
>
> This series is available at u-boot-dm branch input-working.

Can you please try testing this for your crash when pressing 'caps
lock'? I'm not sure what is going on there and I don't have hardware
to test with.

>
> Changes in v3:
> - Refactor the German keyboard code to use data rather than code
> - Drop unrelated cros_keyb change
> - Fix 'QUICK' typo
> - Fix missing 'use' word
> - Drop patches already applied
>
> Changes in v2:
> - Update input_add_tables() to add error checking
> - Convert two multi-line comments to single-line comments
> - Correct call to input_init()
> - Drop CONFIG_VGA_AS_SINGLE_DEVICE from all x86 board config files
> - Use device tree to handle this quirk
>
> Simon Glass (12):
>   input: Support the German keymap
>   input: Adjust structure of code in process_modifier()
>   input: Handle caps lock
>   input: Allow updating of keyboard LEDs
>   input: i8042: Convert to use the input library
>   input: Add a Kconfig option for the i8042 keyboard
>   x86: Add an i8042 device for boards that have it
>   Drop CONFIG_ISA_KEYBOARD
>   input: Convert i8042 to driver model
>   i8042: Handle a duplicate power-on-reset response
>   video: input: Clean up after i8042 conversion
>   input: Convert 'keyboard' driver to use input library
>
>  README   |  30 +-
>  arch/x86/Kconfig |   6 +
>  arch/x86/dts/bayleybay.dts   |   1 +
>  arch/x86/dts/chromebook_link.dts |   5 +
>  arch/x86/dts/keyboard.dtsi   |   5 +
>  board/kosagi/novena/novena.c |   2 +-
>  board/mpl/pip405/README  |   4 -
>  doc/device-tree-bindings/input/i8042.txt |  10 +
>  drivers/input/Kconfig|  10 +
>  drivers/input/Makefile   |   2 +-
>  drivers/input/cros_ec_keyb.c |   2 +-
>  drivers/input/i8042.c| 563 
> ---
>  drivers/input/input.c| 158 +++--
>  drivers/input/keyboard.c | 290 +++-
>  drivers/input/tegra-kbc.c|   2 +-
>  drivers/video/cfb_console.c  |  20 +-
>  include/configs/MIP405.h |   5 -
>  include/configs/PIP405.h |   5 -
>  include/configs/bayleybay.h  |   3 -
>  include/configs/chromebox_panther.h  |   2 -
>  include/configs/minnowmax.h  |   1 -
>  include/configs/x86-chromebook.h |   2 +-
>  include/configs/x86-common.h |   2 +-
>  include/i8042.h  |   6 -
>  include/input.h  |  17 +-
>  include/keyboard.h   |   5 +
>  26 files changed, 376 insertions(+), 782 deletions(-)
>  create mode 100644 arch/x86/dts/keyboard.dtsi
>  create mode 100644 doc/device-tree-bindings/input/i8042.txt
>
> --
> 2.6.0.rc2.230.g3dd15c0
>

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

Re: [U-Boot] [PATCH] ARM: crt0: Pass malloc base address

[Simon Glass]

Hi Fabio,

On 11 November 2015 at 14:24, Fabio Estevam  wrote:
> Hi Simon,
>
> On Wed, Nov 11, 2015 at 7:08 PM, Simon Glass  wrote:
>
>> That test is intended to avoid setting up simple malloc() if we plan
>> to use full malloc() in SPL. Of course, full malloc() is set up a
>> little later (in spl_init()). But we should not need both - either we
>> use simple malloc() or full malloc().
>>
>> But for your board I see:
>>
>> $ grep CONFIG_SYS_SPL_MALLOC_SIZE b/mx6sabresd_spl/u-boot.cfg
>> #define CONFIG_SYS_SPL_MALLOC_SIZE 0x320
>>
>> So you will not be able to use simple malloc(). I'd suggest calling
>> spl_init() from board_init_f() if you need malloc() there. But it
>
> Yes, I do call spl_init() from board_init_f() prior to calling
> malloc() and this has been working fine prior to 5ba534d247d418.
>
>> presumably needs to be done after you have SDRAM up. So perhaps
>
> The trick here is that I need malloc to work prior to have SDRAM configured.
>
> On cgtqmx6eval we need to read SPI NOR to determine what kind of DDR
> we will need to configure.
>
> Otavio has sent the SPL support for cgtqmx6eval, but it has not
> reached U-boot mainline yet.
>
> I am reproducing the problem on a mx6sabresd_spl target with the
> simple example code I sent previously.

I see. That's not a use case I have seen before.

I'd suggest changing the #ifdef to always set up early malloc() if
CONFIG_SYS_MALLOC_F is set. There will of course be a new malloc()
once spi_init() is called, but that does not matter.

In your patch, please be careful to add some docs to the README on
this point (the early malloc() is only there to permit DRAM init,
etc.). It could get quite confusing...

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

Re: [U-Boot] [PATCH] ARM: crt0: Pass malloc base address

[Fabio Estevam]

Hi Simon,

On Wed, Nov 11, 2015 at 7:08 PM, Simon Glass  wrote:

> That test is intended to avoid setting up simple malloc() if we plan
> to use full malloc() in SPL. Of course, full malloc() is set up a
> little later (in spl_init()). But we should not need both - either we
> use simple malloc() or full malloc().
>
> But for your board I see:
>
> $ grep CONFIG_SYS_SPL_MALLOC_SIZE b/mx6sabresd_spl/u-boot.cfg
> #define CONFIG_SYS_SPL_MALLOC_SIZE 0x320
>
> So you will not be able to use simple malloc(). I'd suggest calling
> spl_init() from board_init_f() if you need malloc() there. But it

Yes, I do call spl_init() from board_init_f() prior to calling
malloc() and this has been working fine prior to 5ba534d247d418.

> presumably needs to be done after you have SDRAM up. So perhaps

The trick here is that I need malloc to work prior to have SDRAM configured.

On cgtqmx6eval we need to read SPI NOR to determine what kind of DDR
we will need to configure.

Otavio has sent the SPL support for cgtqmx6eval, but it has not
reached U-boot mainline yet.

I am reproducing the problem on a mx6sabresd_spl target with the
simple example code I sent previously.

Regards,

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

Re: [U-Boot] [PATCH] ARM: crt0: Pass malloc base address

[Simon Glass]

Hi Fabio,

On 11 November 2015 at 14:00, Fabio Estevam  wrote:
> Hi Simon and Albert,
>
> On Wed, Nov 11, 2015 at 6:41 PM, Fabio Estevam  wrote:
>> Hi Simon,
>>
>> On Wed, Nov 11, 2015 at 6:26 PM, Simon Glass  wrote:
>>
>>> Thanks for digging into this. But this should be set up in 
>>> board_init_f_mem():
>>>
>>> #if defined(CONFIG_SYS_MALLOC_F) && \
>>>(!defined(CONFIG_SPL_BUILD) || !defined(CONFIG_SYS_SPL_MALLOC_START))
>>>top -= CONFIG_SYS_MALLOC_F_LEN;
>>>gd->malloc_base = top;
>>> #endif
>>>
>>> Is it possible that the #ifdef logic is wrong for your board?
>>
>> Good point. Looks like this is the problem indeed.
>>
>> I have manually removed the #ifdef logic just for testing:
>>
>> --- a/common/init/board_init.c
>> +++ b/common/init/board_init.c
>> @@ -50,11 +50,8 @@ ulong board_init_f_mem(ulong top)
>>  #endif
>> arch_setup_gd(gd_ptr);
>>
>> -#if defined(CONFIG_SYS_MALLOC_F) && \
>> -   (!defined(CONFIG_SPL_BUILD) || !defined(CONFIG_SYS_SPL_MALLOC_START))
>> top -= CONFIG_SYS_MALLOC_F_LEN;
>> gd->malloc_base = top;
>> -#endif
>>
>> return top;
>>  }
>>
>> ,and then malloc() works fine in SPL.
>
> If I change the logic like this then malloc() works:
>
> --- a/common/init/board_init.c
> +++ b/common/init/board_init.c
> @@ -51,7 +51,7 @@ ulong board_init_f_mem(ulong top)
> arch_setup_gd(gd_ptr);
>
>  #if defined(CONFIG_SYS_MALLOC_F) && \
> -   (!defined(CONFIG_SPL_BUILD) || !defined(CONFIG_SYS_SPL_MALLOC_START))
> +   (defined(CONFIG_SPL_BUILD) || !defined(CONFIG_SYS_SPL_MALLOC_START))
> top -= CONFIG_SYS_MALLOC_F_LEN;
> gd->malloc_base = top;
>  #endif
>
>
> Shouldn't we test for defined(CONFIG_SPL_BUILD) instead of
> !defined(CONFIG_SPL_BUILD)?

That test is intended to avoid setting up simple malloc() if we plan
to use full malloc() in SPL. Of course, full malloc() is set up a
little later (in spl_init()). But we should not need both - either we
use simple malloc() or full malloc().

But for your board I see:

$ grep CONFIG_SYS_SPL_MALLOC_SIZE b/mx6sabresd_spl/u-boot.cfg
#define CONFIG_SYS_SPL_MALLOC_SIZE 0x320

So you will not be able to use simple malloc(). I'd suggest calling
spl_init() from board_init_f() if you need malloc() there. But it
presumably needs to be done after you have SDRAM up. So perhaps
consider removing some things from board_init_f() and put them in
spl_board init()?

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

Re: [U-Boot] [PATCH] ARM: crt0: Pass malloc base address

[Fabio Estevam]

Hi Simon and Albert,

On Wed, Nov 11, 2015 at 6:41 PM, Fabio Estevam  wrote:
> Hi Simon,
>
> On Wed, Nov 11, 2015 at 6:26 PM, Simon Glass  wrote:
>
>> Thanks for digging into this. But this should be set up in 
>> board_init_f_mem():
>>
>> #if defined(CONFIG_SYS_MALLOC_F) && \
>>(!defined(CONFIG_SPL_BUILD) || !defined(CONFIG_SYS_SPL_MALLOC_START))
>>top -= CONFIG_SYS_MALLOC_F_LEN;
>>gd->malloc_base = top;
>> #endif
>>
>> Is it possible that the #ifdef logic is wrong for your board?
>
> Good point. Looks like this is the problem indeed.
>
> I have manually removed the #ifdef logic just for testing:
>
> --- a/common/init/board_init.c
> +++ b/common/init/board_init.c
> @@ -50,11 +50,8 @@ ulong board_init_f_mem(ulong top)
>  #endif
> arch_setup_gd(gd_ptr);
>
> -#if defined(CONFIG_SYS_MALLOC_F) && \
> -   (!defined(CONFIG_SPL_BUILD) || !defined(CONFIG_SYS_SPL_MALLOC_START))
> top -= CONFIG_SYS_MALLOC_F_LEN;
> gd->malloc_base = top;
> -#endif
>
> return top;
>  }
>
> ,and then malloc() works fine in SPL.

If I change the logic like this then malloc() works:

--- a/common/init/board_init.c
+++ b/common/init/board_init.c
@@ -51,7 +51,7 @@ ulong board_init_f_mem(ulong top)
arch_setup_gd(gd_ptr);

 #if defined(CONFIG_SYS_MALLOC_F) && \
-   (!defined(CONFIG_SPL_BUILD) || !defined(CONFIG_SYS_SPL_MALLOC_START))
+   (defined(CONFIG_SPL_BUILD) || !defined(CONFIG_SYS_SPL_MALLOC_START))
top -= CONFIG_SYS_MALLOC_F_LEN;
gd->malloc_base = top;
 #endif


Shouldn't we test for defined(CONFIG_SPL_BUILD) instead of
!defined(CONFIG_SPL_BUILD)?

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

Re: [U-Boot] [PATCH] ARM: crt0: Pass malloc base address

[Fabio Estevam]

Hi Albert,

On Wed, Nov 11, 2015 at 6:33 PM, Albert ARIBAUD
 wrote:

>> +#if defined(CONFIG_SYS_MALLOC_F_LEN)
>> + sub sp, sp, #CONFIG_SYS_MALLOC_F_LEN
>> + str sp, [r9, #GD_MALLOC_BASE]
>> +#endif
>
> NAK, as this only papers over the actual issue. Board_init_f_mem should
> have set the malloc base in GD. Therefore, rather than doing it again
> later, we must determine why it was not properly done earlier.1
>
> Can you give me the toolchain version, board name and commit ID that I
> could use to reproduce the *faulty* build and check the generated code?

Sure, I am testing top of head U-boot (cad049907). Target is
mx6sabresd_spl_defconfig.

Toolchain is: arm-linux-gnueabi-gcc (Ubuntu/Linaro 4.7.3-12ubuntu1) 4.7.3

In order to reproduce the malloc failure, please apply this patch
against mainline:

--- a/board/freescale/mx6sabresd/mx6sabresd.c
+++ b/board/freescale/mx6sabresd/mx6sabresd.c
@@ -30,6 +30,7 @@
 #include "../common/pfuze.h"
 #include 
 #include 
+#include 

 DECLARE_GLOBAL_DATA_PTR;

@@ -833,6 +834,8 @@ static void spl_dram_init(void)

 void board_init_f(ulong dummy)
 {
+void __iomem *ptr;
+
 /* setup AIPS and disable watchdog */
 arch_cpu_init();

@@ -848,6 +851,12 @@ void board_init_f(ulong dummy)
 /* UART clocks enabled and gd valid - init serial console */
 preloader_console_init();

+spl_init();
+
+ptr = malloc(64);
+if (!ptr)
+puts("*** malloc returned NULL\n");
+
 /* DDR initialization */
 spl_dram_init();

Also, as I just explained to Simon if I remove the ifdefery like this:

--- a/common/init/board_init.c
+++ b/common/init/board_init.c
@@ -50,11 +50,8 @@ ulong board_init_f_mem(ulong top)
 #endif
arch_setup_gd(gd_ptr);

-#if defined(CONFIG_SYS_MALLOC_F) && \
-   (!defined(CONFIG_SPL_BUILD) || !defined(CONFIG_SYS_SPL_MALLOC_START))
top -= CONFIG_SYS_MALLOC_F_LEN;
gd->malloc_base = top;
-#endif

return top;
 }

Then malloc() works fine in SPL.

So it seems I need to find a way to make CONFIG_SPL_BUILD=n or
CONFIG_SYS_SPL_MALLOC_START=n.

Thanks,

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

Re: [U-Boot] [PATCH] ARM: crt0: Pass malloc base address

[Fabio Estevam]

Hi Simon,

On Wed, Nov 11, 2015 at 6:26 PM, Simon Glass  wrote:

> Thanks for digging into this. But this should be set up in board_init_f_mem():
>
> #if defined(CONFIG_SYS_MALLOC_F) && \
>(!defined(CONFIG_SPL_BUILD) || !defined(CONFIG_SYS_SPL_MALLOC_START))
>top -= CONFIG_SYS_MALLOC_F_LEN;
>gd->malloc_base = top;
> #endif
>
> Is it possible that the #ifdef logic is wrong for your board?

Good point. Looks like this is the problem indeed.

I have manually removed the #ifdef logic just for testing:

--- a/common/init/board_init.c
+++ b/common/init/board_init.c
@@ -50,11 +50,8 @@ ulong board_init_f_mem(ulong top)
 #endif
arch_setup_gd(gd_ptr);

-#if defined(CONFIG_SYS_MALLOC_F) && \
-   (!defined(CONFIG_SPL_BUILD) || !defined(CONFIG_SYS_SPL_MALLOC_START))
top -= CONFIG_SYS_MALLOC_F_LEN;
gd->malloc_base = top;
-#endif

return top;
 }

,and then malloc() works fine in SPL.

Doing a make mx6sabresd_spl_defconfig I get:
CONFIG_SYS_MALLOC_F=y

For SPL_BUILD I get in menuconfig:

 Symbol: SPL_BUILD [=SPL_BUILD]
 Type  : unknown

and CONFIG_SYS_SPL_MALLOC_START does not exist.

Regards,

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

Re: [U-Boot] [PATCH] ARM: crt0: Pass malloc base address

[Albert ARIBAUD]

Hello Fabio,

On Wed, 11 Nov 2015 18:23:17 -0200, Fabio Estevam 
wrote:
> From: Fabio Estevam 
> 
> Commit 5ba534d247d418 ("arm: Switch 32-bit ARM to using generic global_data
> setup") causes malloc() to fail in SPL.
> 
> The reason is that the GD_MALLOC_BASE is not passed anymore.

This is the explanation of the SPL fail, but not the /cause/ of it.
IOW, why is GD_MALLOC_BASE not passed any more, and what function or
routine is it not passed any more to?

> Restore the code that passes malloc base so that we can have
> malloc working in SPL code again.
> 
> [...]

> +#if defined(CONFIG_SYS_MALLOC_F_LEN)
> + sub sp, sp, #CONFIG_SYS_MALLOC_F_LEN
> + str sp, [r9, #GD_MALLOC_BASE]
> +#endif

NAK, as this only papers over the actual issue. Board_init_f_mem should
have set the malloc base in GD. Therefore, rather than doing it again
later, we must determine why it was not properly done earlier.1

Can you give me the toolchain version, board name and commit ID that I
could use to reproduce the *faulty* build and check the generated code?

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

Re: [U-Boot] [PATCH] ARM: crt0: Pass malloc base address

[Simon Glass]

Hi Fabio,

On 11 November 2015 at 13:23, Fabio Estevam  wrote:
> From: Fabio Estevam 
>
> Commit 5ba534d247d418 ("arm: Switch 32-bit ARM to using generic global_data
> setup") causes malloc() to fail in SPL.
>
> The reason is that the GD_MALLOC_BASE is not passed anymore.
>
> Restore the code that passes malloc base so that we can have
> malloc working in SPL code again.
>
> Signed-off-by: Fabio Estevam 
> ---
>  arch/arm/lib/crt0.S | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/arch/arm/lib/crt0.S b/arch/arm/lib/crt0.S
> index 80548eb..d620126 100644
> --- a/arch/arm/lib/crt0.S
> +++ b/arch/arm/lib/crt0.S
> @@ -87,6 +87,10 @@ ENTRY(_main)
> mov sp, r0
>
> mov r0, #0
> +#if defined(CONFIG_SYS_MALLOC_F_LEN)
> +   sub sp, sp, #CONFIG_SYS_MALLOC_F_LEN
> +   str sp, [r9, #GD_MALLOC_BASE]
> +#endif
> bl  board_init_f
>
>  #if ! defined(CONFIG_SPL_BUILD)
> --
> 1.9.1
>

Thanks for digging into this. But this should be set up in board_init_f_mem():

#if defined(CONFIG_SYS_MALLOC_F) && \
   (!defined(CONFIG_SPL_BUILD) || !defined(CONFIG_SYS_SPL_MALLOC_START))
   top -= CONFIG_SYS_MALLOC_F_LEN;
   gd->malloc_base = top;
#endif

Is it possible that the #ifdef logic is wrong for your board?

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

[U-Boot] [PATCH] ARM: crt0: Pass malloc base address

[Fabio Estevam]

From: Fabio Estevam 

Commit 5ba534d247d418 ("arm: Switch 32-bit ARM to using generic global_data
setup") causes malloc() to fail in SPL.

The reason is that the GD_MALLOC_BASE is not passed anymore.

Restore the code that passes malloc base so that we can have
malloc working in SPL code again.

Signed-off-by: Fabio Estevam 
---
 arch/arm/lib/crt0.S | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/lib/crt0.S b/arch/arm/lib/crt0.S
index 80548eb..d620126 100644
--- a/arch/arm/lib/crt0.S
+++ b/arch/arm/lib/crt0.S
@@ -87,6 +87,10 @@ ENTRY(_main)
mov sp, r0
 
mov r0, #0
+#if defined(CONFIG_SYS_MALLOC_F_LEN)
+   sub sp, sp, #CONFIG_SYS_MALLOC_F_LEN
+   str sp, [r9, #GD_MALLOC_BASE]
+#endif
bl  board_init_f
 
 #if ! defined(CONFIG_SPL_BUILD)
-- 
1.9.1

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

Re: [U-Boot] [PATCH] Revert "arm: Switch 32-bit ARM to using generic global_data setup"

[Fabio Estevam]

On Tue, Nov 10, 2015 at 7:52 PM, Simon Glass  wrote:

> That suggests that gd->malloc_base is not being set up, or is being
> overwritten later. Presumably it should not be NULL?

Yes, gd->malloc_base is NULL. I just prepared a patch to fix this
issue and will submit it soon.

Regards,

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

Re: [U-Boot] [PATCH v2 18/26] dm: usb: Remove inactive children after a bus scan

[Simon Glass]

Hi Hans,

On 11 November 2015 at 10:02, Hans de Goede  wrote:
>
> Hi,
>
>
> On 11-11-15 00:30, Simon Glass wrote:
>>
>> Hi Hans,
>>
>> On 9 November 2015 at 12:25, Simon Glass  wrote:
>>>
>>> Hi Hans,
>>>
>>> On 9 November 2015 at 00:22, Hans de Goede  wrote:

 Hi,

 On 09-11-15 07:48, Simon Glass wrote:
>
>
> Each scan of the USB bus may return different results. Existing
> driver-model
> devices are reused when found, but if a device no longer exists it will
> stay
> around, de-activated, but bound.
>
> Detect these devices and remove them after the scan completes.
>
> Signed-off-by: Simon Glass 



 I wonder how this is better then my original:
 "dm: usb: Use device_unbind_children to clean up usb devs on stop"

 Patch, the end result of both patches is the same and both are
 a NOP when DM_DEVICE_REMOVE is not set. Where as my code seems
 to be a much more KISS approach to the problem (my approach is
 just 3 lines vs 23 lines for yours).

 I know we will need usb_find_child in the DM_DEVICE_REMOVE not
 set case, but why not only revert the:

 "dm: usb: Rename usb_find_child to usb_find_emul_child"

 commit, keep the other 2 you revert and drop this patch ?

 This drops 3 patches from your patch-set and the end result is
 more clean IMHO.
>>>
>>>
>>> I would like to avoid binding/unbinding things when nothing changes if
>>> possible. Also I'd like to support attaching device tree
>>> nodes/properties to USB devices as necessary, as we do with PCI, and
>>> removing things breaks that.
>>>
>>> I still have to figure out one more test case, so I'll do that before
>>> commenting further.
>>
>>
>> I've added the test case and pushed a new tree. However it turns out
>> that this doesn't behave differently.
>>
>> So please can you go ahead and run your original (manual) test case?
>> I'd like to make sure that my automated tests are correct and catch
>> the bug you reported and fixed.
>
>
> Ok, I've ran a whole battery of tests on your u-boot-dm/usb-working branch.

Thanks!

>
> There are 2 issues:
>
> 1) You need to add these change to the commit introducing usb-keyb dm
> support (or one of the related commits), otherwise usb-keyb support
> breaks:
>
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -513,6 +513,7 @@ config ARCH_SUNXI
> select DM
> select DM_GPIO
> select DM_ETH
> +   select DM_KEYBOARD
> select DM_SERIAL
> select DM_USB
> select OF_CONTROL
>
> The breakage is that without this usb_scan_device() returns -96
> (EPFNOSUPPORT) for usb keyboards.

OK. I am a bit concerned this might affect other boards too. Still, if
we get this series applied soon there is plenty of time for testing.
I'll look a bit closer.

>
> 2) With that branch there still is the purely cosmetical issue,
> that if one plugs a usb-stick + keyb into the same hub, then swaps
> their place and do "usb reset" and then "usb tree" looks like this:
>
> USB device tree:
>   1  Hub (480 Mb/s, 100mA)
>   |   USB2.0 Hub
>   |
>   +-3  Human Interface (1.5 Mb/s, 100mA)
>   |SINO WEALTH USB Composite Device
>   |
>   +-2  Mass Storage (480 Mb/s, 100mA)
>USB Flash Disk 4C0E960F
>
> Notice the order of devices listed: 1 - 3 - 2, which is a bit weird,
> as said this is purely cosmetical.
>
> Note you can easily fix this by only reverting the:
>
> "dm: usb: Rename usb_find_child to usb_find_emul_child"
>
> commit, and keep the other 2 you revert and dropping this patch ?
>
> As I already suggested before, this is both more KISS and as you
> can see it solves some actually (admittedly very minor) issues.
>
> I'm not really buying your arguments for your more complex solution,
> as shown above re-using the devices actually causes issues.
>
> Your other argument of wanting to attach device-tree properties
> I also do not find a strong argument, for one there has never been
> a need to do so sofar, and if we ever need this we need a way
> to specify which usb-device the properties belong to based on
> the topology under the host / root-hub anyway, and match things
> up when first scanning the bus. And if we can match things up
> on the first scan we can also match them up on subsequent scans
> and attach the same of-node again.
>
> Anyways I'm fine with doing things your way, but I still have
> a preference for the more KISS and IMHO robust solution of
> simple unbinding all devices on usb-stop.

I wonder if it really is more complex. My preferred algorithm is to
remove any devices that have not been probed after a scan. Yours is to
remove and unbind any USB devices before a scan. What is the
difference?

I much prefer not unbinding and rebinding devices. To my mind, devices
should be bound once if possible, and most of the time it is possible.
This is different from the Linux approach of combining 'bind' and
'probe'. At present sandbox cannot

Re: [U-Boot] [PATCH] fastboot: mmc: Fix use of 64 bit division

[Tom Rini]

On Wed, Nov 11, 2015 at 05:36:09PM +0100, Hans de Goede wrote:

> Directly doing a 64 bit division (when CONFIG_SYS_64BIT_LBA is set)
> causes linking to fail when building u-boot for ARMv7 with a hard-float
> tool-chain.
> 
> This commit fixes this by properly using div_u64 for the division.
> 
> Note that an alternative fix would be to stop using lbaint_t for
> blkcnt / blks, since the passed in "download_bytes" is only 32 bits
> anyways. But we may want to support files / partitions larger then 4G
> in the near future and using div_u64 is future proof for when
> download_bytes' type gets changed to a lbaint_t itself.
> 
> Signed-off-by: Hans de Goede 

Reviewed-by: Tom Rini 

-- 
Tom


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

[U-Boot] [PATCH v3 08/12] Drop CONFIG_ISA_KEYBOARD

[Simon Glass]

This option is mentioned but does not do anything. Drop it.

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

Changes in v3:
- Drop unrelated cros_keyb change

Changes in v2: None

 README   | 5 -
 board/mpl/pip405/README  | 4 
 include/configs/MIP405.h | 5 -
 include/configs/PIP405.h | 5 -
 4 files changed, 19 deletions(-)

diff --git a/README b/README
index e69e73f..fd8b6b6 100644
--- a/README
+++ b/README
@@ -1767,11 +1767,6 @@ CBFS (Coreboot Filesystem) support
a default value of 65536 will be defined.
 
 - Keyboard Support:
-   CONFIG_ISA_KEYBOARD
-
-   Define this to enable standard (PC-Style) keyboard
-   support
-
CONFIG_I8042_KBD
Standard PC keyboard driver with US (is default) and
GERMAN key layout (switch via environment 'keymap=de') support.
diff --git a/board/mpl/pip405/README b/board/mpl/pip405/README
index 012db1c..1b73dbe 100644
--- a/board/mpl/pip405/README
+++ b/board/mpl/pip405/README
@@ -114,10 +114,6 @@ RTC
 
 CONFIG_RTC_MC146818MC146818 RTC support
 
-Keyboard:
--
-CONFIG_ISA_KEYBOARDStandard (PC-Style) Keyboard support
-
 Video:
 --
 CONFIG_VIDEO_CT69000   Enable Chips & Technologies 69000 Video chip
diff --git a/include/configs/MIP405.h b/include/configs/MIP405.h
index ec62c8a..ba93c18 100644
--- a/include/configs/MIP405.h
+++ b/include/configs/MIP405.h
@@ -362,11 +362,6 @@
 #define CONFIG_ISO_PARTITION /* Experimental */
 
 /
- * Keyboard support
- /
-#undef CONFIG_ISA_KEYBOARD
-
-/
  * Video support
  /
 #define CONFIG_VIDEO   /*To enable video controller support */
diff --git a/include/configs/PIP405.h b/include/configs/PIP405.h
index 45eecc4..aac5a4d 100644
--- a/include/configs/PIP405.h
+++ b/include/configs/PIP405.h
@@ -319,11 +319,6 @@
 #define CONFIG_ISO_PARTITION /* Experimental */
 
 /
- * Keyboard support
- /
-#define CONFIG_ISA_KEYBOARD
-
-/
  * Video support
  /
 #define CONFIG_VIDEO   /*To enable video controller support */
-- 
2.6.0.rc2.230.g3dd15c0

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

[U-Boot] [PATCH v3 11/12] video: input: Clean up after i8042 conversion

[Simon Glass]

Now that i8042 uses driver model, adjust other mentions of it and remove old
code that is no-longer used. Update the README and unify the keyboard text
into one place.

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

Changes in v3:
- Fix missing 'use' word

Changes in v2: None

 README  | 29 -
 drivers/video/cfb_console.c | 20 
 2 files changed, 16 insertions(+), 33 deletions(-)

diff --git a/README b/README
index fd8b6b6..abd31d5 100644
--- a/README
+++ b/README
@@ -867,11 +867,11 @@ The following options need to be configured:
(0-5, cf. cfb_console.c)
VIDEO_FB_ADRS   framebuffer address
VIDEO_KBD_INIT_FCT  keyboard int fct
-   (i.e. i8042_kbd_init())
+   (i.e. rx51_kp_init())
VIDEO_TSTC_FCT  test char fct
-   (i.e. i8042_tstc)
+   (i.e. rx51_kp_tstc)
VIDEO_GETC_FCT  get char fct
-   (i.e. i8042_getc)
+   (i.e. rx51_kp_getc)
CONFIG_VIDEO_LOGO   display Linux logo in
upper left corner
CONFIG_VIDEO_BMP_LOGO   use bmp_logo.h instead of
@@ -1767,11 +1767,15 @@ CBFS (Coreboot Filesystem) support
a default value of 65536 will be defined.
 
 - Keyboard Support:
-   CONFIG_I8042_KBD
-   Standard PC keyboard driver with US (is default) and
-   GERMAN key layout (switch via environment 'keymap=de') support.
-   Export function i8042_kbd_init, i8042_tstc and i8042_getc
-   for cfb_console. Supports cursor blinking.
+   See Kconfig help for available keyboard drivers.
+
+   CONFIG_KEYBOARD
+
+   Define this to enable a custom keyboard support.
+   This simply calls drv_keyboard_init() which must be
+   defined in your board-specific files. This option is deprecated
+   and is only used by novena. For new boards, use driver model
+   instead.
 
 - Video support:
CONFIG_VIDEO
@@ -1832,15 +1836,6 @@ CBFS (Coreboot Filesystem) support
boot.  See the documentation file README.video for a
description of this variable.
 
-
-- Keyboard Support:
-   CONFIG_KEYBOARD
-
-   Define this to enable a custom keyboard support.
-   This simply calls drv_keyboard_init() which must be
-   defined in your board-specific files.
-   The only board using this so far is RBC823.
-
 - LCD Support: CONFIG_LCD
 
Define this to enable LCD support (for output to LCD
diff --git a/drivers/video/cfb_console.c b/drivers/video/cfb_console.c
index f191392..f15c964 100644
--- a/drivers/video/cfb_console.c
+++ b/drivers/video/cfb_console.c
@@ -15,8 +15,10 @@
  * logo can be placed in the upper left corner and additional board
  * information strings (that normally goes to serial port) can be drawn.
  *
- * The console driver can use the standard PC keyboard interface (i8042)
- * for character input. Character output goes to a memory mapped video
+ * The console driver can use a keyboard interface for character input
+ * but this is deprecated. Only rk51 uses it.
+ *
+ * Character output goes to a memory-mapped video
  * framebuffer with little or big-endian organisation.
  * With environment setting 'console=serial' the console i/o can be
  * forced to serial port.
@@ -38,7 +40,6 @@
  * VIDEO_DATA_FORMAT - graphical data format GDF
  * VIDEO_FB_ADRS - start of video memory
  *
- * CONFIG_I8042_KBD  - AT Keyboard driver for i8042
  * VIDEO_KBD_INIT_FCT- init function for keyboard
  * VIDEO_TSTC_FCT- keyboard_tstc function
  * VIDEO_GETC_FCT- keyboard_getc function
@@ -158,19 +159,6 @@
 #define VIDEO_FB_ADRS  (pGD->frameAdrs)
 
 /*
- * Console device defines with i8042 keyboard controller
- * Any other keyboard controller must change this section
- */
-
-#ifdef CONFIG_I8042_KBD
-#include 
-
-#define VIDEO_KBD_INIT_FCT i8042_kbd_init()
-#define VIDEO_TSTC_FCT i8042_tstc
-#define VIDEO_GETC_FCT i8042_getc
-#endif
-
-/*
  * Console device
  */
 
-- 
2.6.0.rc2.230.g3dd15c0

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

[U-Boot] [PATCH v3 12/12] input: Convert 'keyboard' driver to use input library

[Simon Glass]

This has duplicated scan code tables and logic. We can use the input
library to implement most of the features here.

This needs testing. The only supported board appears to be TQM5200.
Unfortunately no maintainer is listed for this board.

Signed-off-by: Simon Glass 
---

Changes in v3:
- Drop patches already applied

Changes in v2: None

 drivers/input/keyboard.c | 290 +++
 include/keyboard.h   |   5 +
 2 files changed, 43 insertions(+), 252 deletions(-)

diff --git a/drivers/input/keyboard.c b/drivers/input/keyboard.c
index eec8c27..b31efbf 100644
--- a/drivers/input/keyboard.c
+++ b/drivers/input/keyboard.c
@@ -10,290 +10,76 @@
 
 #include 
 #include 
-
-#include 
+#include 
 #include 
+#include 
 
-#undef KBG_DEBUG
-
-#ifdef KBG_DEBUG
-#definePRINTF(fmt,args...) printf (fmt ,##args)
-#else
-#define PRINTF(fmt,args...)
-#endif
-
-
-#defineDEVNAME "kbd"
-
-#defineLED_SCR 0x01/* scroll lock led */
-#defineLED_CAP 0x04/* caps lock led */
-#defineLED_NUM 0x02/* num lock led */
-
-#defineKBD_BUFFER_LEN  0x20  /* size of the keyboardbuffer */
+static struct input_config config;
 
-#if defined(CONFIG_MPC5xxx) || defined(CONFIG_MPC8540) || 
defined(CONFIG_MPC8541) || defined(CONFIG_MPC8555)
-int ps2ser_check(void);
+static int kbd_read_keys(struct input_config *config)
+{
+#if defined(CONFIG_MPC5xxx) || defined(CONFIG_MPC8540) || \
+   defined(CONFIG_MPC8541) || defined(CONFIG_MPC8555)
+   /* no ISR is used, so received chars must be polled */
+   ps2ser_check();
 #endif
 
-static volatile char kbd_buffer[KBD_BUFFER_LEN];
-static volatile int in_pointer = 0;
-static volatile int out_pointer = 0;
+   return 1;
+}
 
-static unsigned char leds = 0;
-static unsigned char num_lock = 0;
-static unsigned char caps_lock = 0;
-static unsigned char scroll_lock = 0;
-static unsigned char shift = 0;
-static unsigned char ctrl = 0;
-static unsigned char alt = 0;
-static unsigned char e0 = 0;
+static int check_leds(int ret)
+{
+   int leds;
 
-/**
- * Queue handling
- **/
+   leds = input_leds_changed(&config);
+   if (leds >= 0)
+   pckbd_leds(leds);
 
-/* puts character in the queue and sets up the in and out pointer */
-static void kbd_put_queue(char data)
-{
-   if((in_pointer+1)==KBD_BUFFER_LEN) {
-   if(out_pointer==0) {
-   return; /* buffer full */
-   } else{
-   in_pointer=0;
-   }
-   } else {
-   if((in_pointer+1)==out_pointer)
-   return; /* buffer full */
-   in_pointer++;
-   }
-   kbd_buffer[in_pointer]=data;
-   return;
+   return ret;
 }
 
 /* test if a character is in the queue */
 static int kbd_testc(struct stdio_dev *dev)
 {
-#if defined(CONFIG_MPC5xxx) || defined(CONFIG_MPC8540) || 
defined(CONFIG_MPC8541) || defined(CONFIG_MPC8555)
-   /* no ISR is used, so received chars must be polled */
-   ps2ser_check();
-#endif
-   if(in_pointer==out_pointer)
-   return(0); /* no data */
-   else
-   return(1);
+   return check_leds(input_tstc(&config));
 }
 
 /* gets the character from the queue */
 static int kbd_getc(struct stdio_dev *dev)
 {
-   char c;
-   while(in_pointer==out_pointer) {
-#if defined(CONFIG_MPC5xxx) || defined(CONFIG_MPC8540) || 
defined(CONFIG_MPC8541) || defined(CONFIG_MPC8555)
-   /* no ISR is used, so received chars must be polled */
-   ps2ser_check();
-#endif
-   ;}
-   if((out_pointer+1)==KBD_BUFFER_LEN)
-   out_pointer=0;
-   else
-   out_pointer++;
-   c=kbd_buffer[out_pointer];
-   return (int)c;
-
+   return check_leds(input_getc(&config));
 }
 
-/* Simple translation table for the keys */
-
-static unsigned char kbd_plain_xlate[] = {
-   0xff,0x1b, '1', '2', '3', '4', '5', '6', '7', '8', '9', '0', '-', 
'=','\b','\t',/* 0x00 - 0x0f */
-'q', 'w', 'e', 'r', 't', 'y', 'u', 'i', 'o', 'p', '[', ']','\r',0xff, 
'a', 's',/* 0x10 - 0x1f */
-'d', 'f', 'g', 'h', 'j', 'k', 'l', ';','\'', '`',0xff,'\\', 'z', 'x', 
'c', 'v',/* 0x20 - 0x2f */
-'b', 'n', 'm', ',', '.', '/',0xff,0xff,0xff, ' 
',0xff,0xff,0xff,0xff,0xff,0xff,/* 0x30 - 0x3f */
-   0xff,0xff,0xff,0xff,0xff,0xff,0xff, '7', '8', '9', '-', '4', '5', '6', 
'+', '1',/* 0x40 - 0x4f */
-'2', '3', '0', 
'.',0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,  /* 0x50 - 
0x5F */
-   '\r',0xff,0xff
-   };
-
-static unsigned char kbd_shift_xlate[] = {
-   0xff,0x1b, '!', '@', '#', '$', '%', '^', '&', '*', '(', ')', '_', 
'+','\b','\t', 

[U-Boot] [PATCH v3 09/12] input: Convert i8042 to driver model

[Simon Glass]

Adjust this driver to support driver model. The only users are x86 boards
so this should be safe.

Signed-off-by: Simon Glass 
---

Changes in v3: None
Changes in v2: None

 drivers/input/Makefile |   2 +-
 drivers/input/i8042.c  | 109 ++---
 include/i8042.h|   6 ---
 3 files changed, 76 insertions(+), 41 deletions(-)

diff --git a/drivers/input/Makefile b/drivers/input/Makefile
index 9388dfe..5f15265 100644
--- a/drivers/input/Makefile
+++ b/drivers/input/Makefile
@@ -7,7 +7,7 @@
 
 obj-$(CONFIG_DM_KEYBOARD) += keyboard-uclass.o
 
-obj-$(CONFIG_I8042_KBD) += i8042.o
+obj-$(CONFIG_I8042_KEYB) += i8042.o
 obj-$(CONFIG_TEGRA_KEYBOARD) += tegra-kbc.o
 obj-$(CONFIG_TWL4030_INPUT) += twl4030.o
 obj-$(CONFIG_CROS_EC_KEYB) += cros_ec_keyb.o
diff --git a/drivers/input/i8042.c b/drivers/input/i8042.c
index 270805b..e5e2926 100644
--- a/drivers/input/i8042.c
+++ b/drivers/input/i8042.c
@@ -8,8 +8,11 @@
 /* i8042.c - Intel 8042 keyboard driver routines */
 
 #include 
+#include 
+#include 
 #include 
 #include 
+#include 
 #include 
 
 /* defines */
@@ -17,8 +20,9 @@
 #define out8(p, v) outb(v, p)
 
 /* locals */
-static struct input_config config;
-static bool extended;
+struct i8042_kbd_priv {
+   bool extended;  /* true if an extended keycode is expected next */
+};
 
 static unsigned char ext_key_map[] = {
0x1c, /* keypad enter */
@@ -60,12 +64,20 @@ static int kbd_output_full(void)
return kbd_timeout != -1;
 }
 
-static void kbd_led_set(int flags)
+/**
+ * check_leds() - Check the keyboard LEDs and update them it needed
+ *
+ * @ret:   Value to return
+ * @return value of @ret
+ */
+static int i8042_kbd_update_leds(struct udevice *dev, int leds)
 {
kbd_input_empty();
out8(I8042_DATA_REG, CMD_SET_KBD_LED);
kbd_input_empty();
-   out8(I8042_DATA_REG, flags & 0x7);
+   out8(I8042_DATA_REG, leds & 0x7);
+
+   return 0;
 }
 
 static int kbd_write(int reg, int value)
@@ -144,6 +156,8 @@ static int kbd_controller_present(void)
 /*
  * Implement a weak default function for boards that optionally
  * need to skip the i8042 initialization.
+ *
+ * TODO(s...@chromium.org): Use device tree for this?
  */
 int __weak board_i8042_skip(void)
 {
@@ -190,6 +204,8 @@ int i8042_disable(void)
 
 static int i8042_kbd_check(struct input_config *input)
 {
+   struct i8042_kbd_priv *priv = dev_get_priv(input->dev);
+
if ((in8(I8042_STS_REG) & STATUS_OBF) == 0) {
return 0;
} else {
@@ -201,15 +217,15 @@ static int i8042_kbd_check(struct input_config *input)
if (scan_code == 0xfa) {
return 0;
} else if (scan_code == 0xe0) {
-   extended = true;
+   priv->extended = true;
return 0;
}
if (scan_code & 0x80) {
scan_code &= 0x7f;
release = true;
}
-   if (extended) {
-   extended = false;
+   if (priv->extended) {
+   priv->extended = false;
for (i = 0; ext_key_map[i]; i++) {
if (ext_key_map[i] == scan_code) {
scan_code = 0x60 + i;
@@ -221,21 +237,23 @@ static int i8042_kbd_check(struct input_config *input)
return 0;
}
 
-   input_add_keycode(&config, scan_code, release);
+   input_add_keycode(input, scan_code, release);
return 1;
}
 }
 
 /* i8042_kbd_init - reset keyboard and init state flags */
-int i8042_kbd_init(void)
+static int i8042_start(struct udevice *dev)
 {
+   struct keyboard_priv *uc_priv = dev_get_uclass_priv(dev);
+   struct input_config *input = &uc_priv->input;
int keymap, try;
char *penv;
int ret;
 
if (!kbd_controller_present() || board_i8042_skip()) {
debug("i8042 keyboard controller is not present\n");
-   return -1;
+   return -ENOENT;
}
 
/* Init keyboard device (default US layout) */
@@ -251,42 +269,65 @@ int i8042_kbd_init(void)
return -1;
}
 
-   ret = input_init(&config, keymap == KBD_GER);
+   ret = input_add_tables(input, keymap == KBD_GER);
if (ret)
return ret;
-   config.read_keys = i8042_kbd_check;
-   input_allow_repeats(&config, true);
 
-   kbd_led_set(NORMAL);
+   i8042_kbd_update_leds(dev, NORMAL);
+   debug("%s: started\n", __func__);
 
return 0;
 }
 
 /**
- * check_leds() - Check the keyboard LEDs and update them it needed
+ * Set up the i8042 keyboard. This is called by the stdio device handler
  *
- * @ret:   Value to return
- * @return value of @ret
+ * We want to do this init when the keyboard is ac

[U-Boot] [PATCH v3 07/12] x86: Add an i8042 device for boards that have it

[Simon Glass]

Some boards have an i8042 device. Enable the driver for all x86 boards, and
add a device tree node for those which may have this keyboard.

Also adjust the configuration so that i8042 is always separate from the VGA,
and rename the stdin driver accordingly. With this commit the keyboard will
not work, but it is fixed in the next commit.

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

Changes in v3: None
Changes in v2:
- Drop CONFIG_VGA_AS_SINGLE_DEVICE from all x86 board config files

 arch/x86/Kconfig |  6 ++
 arch/x86/dts/bayleybay.dts   |  1 +
 arch/x86/dts/chromebook_link.dts |  5 +
 arch/x86/dts/keyboard.dtsi   |  5 +
 doc/device-tree-bindings/input/i8042.txt | 10 ++
 include/configs/bayleybay.h  |  3 ---
 include/configs/chromebox_panther.h  |  2 --
 include/configs/minnowmax.h  |  1 -
 include/configs/x86-chromebook.h |  2 +-
 include/configs/x86-common.h |  2 +-
 10 files changed, 29 insertions(+), 8 deletions(-)
 create mode 100644 arch/x86/dts/keyboard.dtsi
 create mode 100644 doc/device-tree-bindings/input/i8042.txt

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index f92082d..d8aeaaf 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -420,6 +420,12 @@ config PCIE_ECAM_SIZE
  so a default 0x1000 size covers all of the 256 buses which is the
  maximum number of PCI buses as defined by the PCI specification.
 
+config I8042_KEYB
+   default y
+
+config DM_KEYBOARD
+   default y
+
 source "arch/x86/lib/efi/Kconfig"
 
 endmenu
diff --git a/arch/x86/dts/bayleybay.dts b/arch/x86/dts/bayleybay.dts
index 52d0999..aa86387 100644
--- a/arch/x86/dts/bayleybay.dts
+++ b/arch/x86/dts/bayleybay.dts
@@ -10,6 +10,7 @@
 #include 
 
 /include/ "skeleton.dtsi"
+/include/ "keyboard.dtsi"
 /include/ "serial.dtsi"
 /include/ "rtc.dtsi"
 
diff --git a/arch/x86/dts/chromebook_link.dts b/arch/x86/dts/chromebook_link.dts
index f27263a..7870bb1 100644
--- a/arch/x86/dts/chromebook_link.dts
+++ b/arch/x86/dts/chromebook_link.dts
@@ -1,6 +1,7 @@
 /dts-v1/;
 
 /include/ "skeleton.dtsi"
+/include/ "keyboard.dtsi"
 /include/ "serial.dtsi"
 /include/ "rtc.dtsi"
 
@@ -41,6 +42,10 @@
stdout-path = "/serial";
};
 
+   keyboard {
+   intel,duplicate-por;
+   };
+
spd {
compatible = "memory-spd";
#address-cells = <1>;
diff --git a/arch/x86/dts/keyboard.dtsi b/arch/x86/dts/keyboard.dtsi
new file mode 100644
index 000..000751b
--- /dev/null
+++ b/arch/x86/dts/keyboard.dtsi
@@ -0,0 +1,5 @@
+/ {
+   keyboard {
+   compatible = "intel,i8042-keyboard";
+   };
+};
diff --git a/doc/device-tree-bindings/input/i8042.txt 
b/doc/device-tree-bindings/input/i8042.txt
new file mode 100644
index 000..cd079c2
--- /dev/null
+++ b/doc/device-tree-bindings/input/i8042.txt
@@ -0,0 +1,10 @@
+i8042 Keyboard
+
+The Intel i8042 is a keyboard controller used on many x86 PCs.
+
+Required properties:
+- compatible: "intel,i8042-keyboard"
+
+Optional properties:
+- intel,duplicate-por: Indicates that a keyboard reset may result in a
+  duplicate POR byte, which should be ignored.
diff --git a/include/configs/bayleybay.h b/include/configs/bayleybay.h
index 1ba2998..ac6b45b 100644
--- a/include/configs/bayleybay.h
+++ b/include/configs/bayleybay.h
@@ -33,9 +33,6 @@
 #define CONFIG_MMC_SDMA
 #define CONFIG_CMD_MMC
 
-/* BayTrail IGD support */
-#define CONFIG_VGA_AS_SINGLE_DEVICE
-
 /* Environment configuration */
 #define CONFIG_ENV_SECT_SIZE   0x1000
 #define CONFIG_ENV_OFFSET  0x006ff000
diff --git a/include/configs/chromebox_panther.h 
b/include/configs/chromebox_panther.h
index dc732b8..00fe26d 100644
--- a/include/configs/chromebox_panther.h
+++ b/include/configs/chromebox_panther.h
@@ -14,6 +14,4 @@
 /* Avoid a warning in the Realtek Ethernet driver */
 #define CONFIG_SYS_CACHELINE_SIZE 16
 
-#define CONFIG_VGA_AS_SINGLE_DEVICE
-
 #endif /* __CONFIG_H */
diff --git a/include/configs/minnowmax.h b/include/configs/minnowmax.h
index 53d86a2..c90af40 100644
--- a/include/configs/minnowmax.h
+++ b/include/configs/minnowmax.h
@@ -43,7 +43,6 @@
 
 #define VIDEO_IO_OFFSET0
 #define CONFIG_X86EMU_RAW_IO
-#define CONFIG_VGA_AS_SINGLE_DEVICE
 
 #define CONFIG_FIT_SIGNATURE
 #define CONFIG_RSA
diff --git a/include/configs/x86-chromebook.h b/include/configs/x86-chromebook.h
index 2be8850..4ff8b94 100644
--- a/include/configs/x86-chromebook.h
+++ b/include/configs/x86-chromebook.h
@@ -51,7 +51,7 @@
 #define CONFIG_ENV_IS_IN_SPI_FLASH
 #define CONFIG_ENV_OFFSET  0x003f8000
 
-#define CONFIG_STD_DEVICES_SETTINGS "stdin=usbkbd,vga,serial\0" \
+#define CONFIG_STD_DEVICES_SETTINGS "stdin=usbkbd,i8042-kbd,serial\0" \
"stdout=vga,serial\0" \
"stderr=vga

[U-Boot] [PATCH v3 10/12] i8042: Handle a duplicate power-on-reset response

[Simon Glass]

Sometimes we seem to get 0xaa twice which causes the config read to fail.
This causes chromebook_link to fail to set up the keyboard.

Add a check for this and read the config again when detected.

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

Changes in v3:
- Fix 'QUICK' typo

Changes in v2:
- Use device tree to handle this quirk

 drivers/input/i8042.c | 21 +++--
 1 file changed, 19 insertions(+), 2 deletions(-)

diff --git a/drivers/input/i8042.c b/drivers/input/i8042.c
index e5e2926..661d7fd 100644
--- a/drivers/input/i8042.c
+++ b/drivers/input/i8042.c
@@ -15,13 +15,20 @@
 #include 
 #include 
 
+DECLARE_GLOBAL_DATA_PTR;
+
 /* defines */
 #define in8(p) inb(p)
 #define out8(p, v) outb(v, p)
 
+enum {
+   QUIRK_DUP_POR   = 1 << 0,
+};
+
 /* locals */
 struct i8042_kbd_priv {
bool extended;  /* true if an extended keycode is expected next */
+   int quirks; /* quirks that we support */
 };
 
 static unsigned char ext_key_map[] = {
@@ -113,7 +120,7 @@ static int kbd_cmd_write(int cmd, int data)
return kbd_write(I8042_DATA_REG, data);
 }
 
-static int kbd_reset(void)
+static int kbd_reset(int quirk)
 {
int config;
 
@@ -132,6 +139,10 @@ static int kbd_reset(void)
if (config == -1)
goto err;
 
+   /* Sometimes get a second byte */
+   else if ((quirk & QUIRK_DUP_POR) && config == KBD_POR)
+   config = kbd_cmd_read(CMD_RD_CONFIG);
+
config |= CONFIG_AT_TRANS;
config &= ~(CONFIG_KIRQ_EN | CONFIG_MIRQ_EN);
if (kbd_cmd_write(CMD_WR_CONFIG, config))
@@ -246,6 +257,7 @@ static int i8042_kbd_check(struct input_config *input)
 static int i8042_start(struct udevice *dev)
 {
struct keyboard_priv *uc_priv = dev_get_uclass_priv(dev);
+   struct i8042_kbd_priv *priv = dev_get_priv(dev);
struct input_config *input = &uc_priv->input;
int keymap, try;
char *penv;
@@ -264,7 +276,7 @@ static int i8042_start(struct udevice *dev)
keymap = KBD_GER;
}
 
-   for (try = 0; kbd_reset() != 0; try++) {
+   for (try = 0; kbd_reset(priv->quirks) != 0; try++) {
if (try >= KBD_RESET_TRIES)
return -1;
}
@@ -294,10 +306,15 @@ static int i8042_start(struct udevice *dev)
 static int i8042_kbd_probe(struct udevice *dev)
 {
struct keyboard_priv *uc_priv = dev_get_uclass_priv(dev);
+   struct i8042_kbd_priv *priv = dev_get_priv(dev);
struct stdio_dev *sdev = &uc_priv->sdev;
struct input_config *input = &uc_priv->input;
int ret;
 
+   if (fdtdec_get_bool(gd->fdt_blob, dev->of_offset,
+   "intel,duplicate-por"))
+   priv->quirks |= QUIRK_DUP_POR;
+
/* Register the device. i8042_start() will be called soon */
input->dev = dev;
input->read_keys = i8042_kbd_check;
-- 
2.6.0.rc2.230.g3dd15c0

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

[U-Boot] [PATCH v3 05/12] input: i8042: Convert to use the input library

[Simon Glass]

At present the i8042 driver has its own logic and keymaps. In an effort to
unify the code, move it over to use the input library. This changes most of
the keycode-processing logic since it is now in that library. The main
responsibilities of the driver are now to handle the LEDs, deal with the
PS/2 extended keycodes and initialise the the keyboard.

Signed-off-by: Simon Glass 
---

Changes in v3: None
Changes in v2:
- Convert two multi-line comments to single-line comments
- Correct call to input_init()

 drivers/input/i8042.c | 493 +++---
 1 file changed, 69 insertions(+), 424 deletions(-)

diff --git a/drivers/input/i8042.c b/drivers/input/i8042.c
index b1ada86..270805b 100644
--- a/drivers/input/i8042.c
+++ b/drivers/input/i8042.c
@@ -7,251 +7,18 @@
 
 /* i8042.c - Intel 8042 keyboard driver routines */
 
-/* includes */
-
 #include 
-#include 
 #include 
+#include 
+#include 
 
 /* defines */
 #define in8(p) inb(p)
 #define out8(p, v) outb(v, p)
 
 /* locals */
-
-static int kbd_input = -1; /* no input yet */
-static int kbd_mapping = KBD_US;   /* default US keyboard */
-static int kbd_flags = NORMAL; /* after reset */
-static int kbd_state;  /* unshift code */
-
-static unsigned char kbd_fct_map[144] = {
-   /* kbd_fct_map table for scan code */
-0,  AS,  AS,  AS,  AS,  AS,  AS,  AS, /* scan 00-07 */
-   AS,  AS,  AS,  AS,  AS,  AS,  AS,  AS, /* scan 08-0F */
-   AS,  AS,  AS,  AS,  AS,  AS,  AS,  AS, /* scan 10-17 */
-   AS,  AS,  AS,  AS,  AS,  CN,  AS,  AS, /* scan 18-1F */
-   AS,  AS,  AS,  AS,  AS,  AS,  AS,  AS, /* scan 20-27 */
-   AS,  AS,  SH,  AS,  AS,  AS,  AS,  AS, /* scan 28-2F */
-   AS,  AS,  AS,  AS,  AS,  AS,  SH,  AS, /* scan 30-37 */
-   AS,  AS,  CP,   0,   0,   0,   0,   0, /* scan 38-3F */
-0,   0,   0,   0,   0,  NM,  ST,  ES, /* scan 40-47 */
-   ES,  ES,  ES,  ES,  ES,  ES,  ES,  ES, /* scan 48-4F */
-   ES,  ES,  ES,  ES,   0,   0,  AS,   0, /* scan 50-57 */
-0,   0,   0,   0,   0,   0,   0,   0, /* scan 58-5F */
-0,   0,   0,   0,   0,   0,   0,   0, /* scan 60-67 */
-0,   0,   0,   0,   0,   0,   0,   0, /* scan 68-6F */
-   AS,   0,   0,  AS,   0,   0,  AS,   0, /* scan 70-77 */
-0,  AS,   0,   0,   0,  AS,   0,   0, /* scan 78-7F */
-   AS,  CN,  AS,  AS,  AK,  ST,  EX,  EX, /* enhanced */
-   AS,  EX,  EX,  AS,  EX,  AS,  EX,  EX  /* enhanced */
-   };
-
-static unsigned char kbd_key_map[2][5][144] = {
-   { /* US keyboard */
-   { /* unshift code */
-  0, 0x1b,  '1',  '2',  '3',  '4',  '5',  '6', /* scan 00-07 */
-'7',  '8',  '9',  '0',  '-',  '=', 0x08, '\t', /* scan 08-0F */
-'q',  'w',  'e',  'r',  't',  'y',  'u',  'i', /* scan 10-17 */
-'o',  'p',  '[',  ']', '\r',   CN,  'a',  's', /* scan 18-1F */
-'d',  'f',  'g',  'h',  'j',  'k',  'l',  ';', /* scan 20-27 */
-   '\'',  '`',   SH, '\\',  'z',  'x',  'c',  'v', /* scan 28-2F */
-'b',  'n',  'm',  ',',  '.',  '/',   SH,  '*', /* scan 30-37 */
-' ',  ' ',   CP,0,0,0,0,0, /* scan 38-3F */
-  0,0,0,0,0,   NM,   ST,  '7', /* scan 40-47 */
-'8',  '9',  '-',  '4',  '5',  '6',  '+',  '1', /* scan 48-4F */
-'2',  '3',  '0',  '.',0,0,0,0, /* scan 50-57 */
-  0,0,0,0,0,0,0,0, /* scan 58-5F */
-  0,0,0,0,0,0,0,0, /* scan 60-67 */
-  0,0,0,0,0,0,0,0, /* scan 68-6F */
-  0,0,0,0,0,0,0,0, /* scan 70-77 */
-  0,0,0,0,0,0,0,0, /* scan 78-7F */
-   '\r',   CN,  '/',  '*',  ' ',   ST,  'F',  'A', /* extended */
-  0,  'D',  'C',0,  'B',0,  '@',  'P'  /* extended */
-   },
-   { /* shift code */
-  0, 0x1b,  '!',  '@',  '#',  '$',  '%',  '^', /* scan 00-07 */
-'&',  '*',  '(',  ')',  '_',  '+', 0x08, '\t', /* scan 08-0F */
-'Q',  'W',  'E',  'R',  'T',  'Y',  'U',  'I', /* scan 10-17 */
-'O',  'P',  '{',  '}', '\r',   CN,  'A',  'S', /* scan 18-1F */
-'D',  'F',  'G',  'H',  'J',  'K',  'L',  ':', /* scan 20-27 */
-'"',  '~',   SH,  '|',  'Z',  'X',  'C',  'V', /* scan 28-2F */
-'B',  'N',  'M',  '<',  '>',  '?',   SH,  '*', /* scan 30-37 */
-' ',  ' ',   CP,0,0,0,0,0, /* scan 38-3F */
-  0,0,0,0,0,   NM,   ST,  '7', /* scan 40-47 */
-'8',  '9',  '-',  '4',  '5',  '6',  '+',  '1', /* scan 48-4F */
-'2',  '3',  '0',  '.',0,0,0,0, /* scan 50-57 */
-  0,0,0,0,0,0,0,0, /* scan 58-5F */
-  0,0,0,0,0,0,0,0, /* scan 60-67 */
-  0,0,0,0,0,0,0,0, /* scan 

[U-Boot] [PATCH v3 02/12] input: Adjust structure of code in process_modifier()

[Simon Glass]

Move all the '!release' code into one block so that it is clear that it only
applies on key release.

Signed-off-by: Simon Glass 
---

Changes in v3: None
Changes in v2: None

 drivers/input/input.c | 27 ++-
 1 file changed, 14 insertions(+), 13 deletions(-)

diff --git a/drivers/input/input.c b/drivers/input/input.c
index 96fc195..7513226 100644
--- a/drivers/input/input.c
+++ b/drivers/input/input.c
@@ -237,7 +237,6 @@ static struct input_key_xlate *process_modifier(struct 
input_config *config,
int key, int release)
 {
struct input_key_xlate *table;
-   int flip = -1;
int i;
 
/* Start with the main table, and see what modifiers change it */
@@ -252,6 +251,8 @@ static struct input_key_xlate *process_modifier(struct 
input_config *config,
 
/* Handle the lighted keys */
if (!release) {
+   int flip = -1;
+
switch (key) {
case KEY_SCROLLLOCK:
flip = FLAG_SCROLL_LOCK;
@@ -263,19 +264,19 @@ static struct input_key_xlate *process_modifier(struct 
input_config *config,
flip = FLAG_CAPS_LOCK;
break;
}
-   }
 
-   if (flip != -1) {
-   int leds = 0;
-
-   config->leds ^= flip;
-   if (config->flags & FLAG_NUM_LOCK)
-   leds |= INPUT_LED_NUM;
-   if (config->flags & FLAG_CAPS_LOCK)
-   leds |= INPUT_LED_CAPS;
-   if (config->flags & FLAG_SCROLL_LOCK)
-   leds |= INPUT_LED_SCROLL;
-   config->leds = leds;
+   if (flip != -1) {
+   int leds = 0;
+
+   config->leds ^= flip;
+   if (config->flags & FLAG_NUM_LOCK)
+   leds |= INPUT_LED_NUM;
+   if (config->flags & FLAG_CAPS_LOCK)
+   leds |= INPUT_LED_CAPS;
+   if (config->flags & FLAG_SCROLL_LOCK)
+   leds |= INPUT_LED_SCROLL;
+   config->leds = leds;
+   }
}
 
return table;
-- 
2.6.0.rc2.230.g3dd15c0

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

[U-Boot] [PATCH v3 06/12] input: Add a Kconfig option for the i8042 keyboard

[Simon Glass]

Add a new option CONFIG_I8042_KEYB which will replace the current
CONFIG_I8042_KBD. This new name fits better with existing drivers.

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

Changes in v3: None
Changes in v2: None

 drivers/input/Kconfig | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/input/Kconfig b/drivers/input/Kconfig
index 447c4c3..d560328 100644
--- a/drivers/input/Kconfig
+++ b/drivers/input/Kconfig
@@ -13,3 +13,13 @@ config CROS_EC_KEYB
  Most ARM Chromebooks use an EC to provide access to the keyboard.
  Messages are used to request key scans from the EC and these are
  then decoded into keys by this driver.
+
+config I8042_KEYB
+   bool "Enable Intel i8042 keyboard support"
+   depends on DM_KEYBOARD
+   help
+ This adds a driver for the i8042 keyboard controller, allowing the
+ keyboard to be used on devices which support this controller. The
+ driver handles English and German keyboards - set the environment
+ variable 'keymap' to "de" to select German. Keyboard repeat is
+ handled by the keyboard itself.
-- 
2.6.0.rc2.230.g3dd15c0

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

[U-Boot] [PATCH v3 04/12] input: Allow updating of keyboard LEDs

[Simon Glass]

Add a function which returns a new keyboard LED value when the LEDs need
updating.

Signed-off-by: Simon Glass 
---

Changes in v3: None
Changes in v2: None

 drivers/input/input.c |  9 +
 include/input.h   | 14 +-
 2 files changed, 22 insertions(+), 1 deletion(-)

diff --git a/drivers/input/input.c b/drivers/input/input.c
index a8a15c9..bf1acdc 100644
--- a/drivers/input/input.c
+++ b/drivers/input/input.c
@@ -276,6 +276,7 @@ static struct input_key_xlate *process_modifier(struct 
input_config *config,
if (config->flags & FLAG_SCROLL_LOCK)
leds |= INPUT_LED_SCROLL;
config->leds = leds;
+   config->leds_changed = flip;
}
}
 
@@ -587,6 +588,14 @@ void input_allow_repeats(struct input_config *config, bool 
allow_repeats)
config->allow_repeats = allow_repeats;
 }
 
+int input_leds_changed(struct input_config *config)
+{
+   if (config->leds_changed)
+   return config->leds;
+
+   return -1;
+}
+
 int input_add_tables(struct input_config *config, bool german)
 {
struct kbd_entry *entry;
diff --git a/include/input.h b/include/input.h
index c1af259..ad120e4 100644
--- a/include/input.h
+++ b/include/input.h
@@ -43,7 +43,8 @@ struct input_config {
/* Which modifiers are active (1 bit for each MOD_... value) */
uchar modifiers;
uchar flags;/* active state keys (FLAGS_...) */
-   uchar leds; /* active LEDS (INPUT_LED_...) */
+   uchar leds; /* active LEDs (INPUT_LED_...) */
+   uchar leds_changed; /* LEDs that just changed */
uchar num_tables;   /* number of modifier tables */
int prev_keycodes[INPUT_BUFFER_LEN];/* keys held last time */
int num_prev_keycodes;  /* number of prev keys */
@@ -162,6 +163,17 @@ void input_set_delays(struct input_config *config, int 
repeat_delay_ms,
 void input_allow_repeats(struct input_config *config, bool allow_repeats);
 
 /**
+ * Check if keyboard LEDs need to be updated
+ *
+ * This can be called after input_tstc() to see if keyboard LEDs need
+ * updating.
+ *
+ * @param config   Input state
+ * @return -1 if no LEDs need updating, other value if they do
+ */
+int input_leds_changed(struct input_config *config);
+
+/**
  * Set up the key map tables
  *
  * This must be called after input_init() or keycode decoding will not work.
-- 
2.6.0.rc2.230.g3dd15c0

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

[U-Boot] [PATCH v3 00/12] dm: input: Move keyboard drivers to driver model

[Simon Glass]

This series adds a new uclass for keyboards and converts some drivers
over to use it.

This series includes some work to remove code duplication in the keyboard
drivers by updating them to use the input library (input.c). This unifies
the keycode decoding logic in one place. In order to do this some
enhancements are needed to the input library and these are also included.

The cros_ec and tegra_kbc drivers are converted to use driver model.

The i8042 driver is converted also, after various tidy-ups. The driver has
some strange interactions with the cfb_console driver. This is removed in
this series which is possible because the only user is x86. Some i8042
features have been dropped (the only deliberate one is the flashing cursor
which does not seem to be used by any board).

Also the i8042 driver currently has its own keycode-decoding logic. This
series removes it in favour of the input library. Therefore testing of this
new driver would be appreciated. So far I have only been able to test on
link, which does not have a full keyboard. Also, while German keyboard
support is implemented, I am unable to test that either.

These changes can be considered the first step towards moving stdio to
driver model. For that to be useful we need to convert LCD and video also.

Note: This series is missing the code to call the update_leds() method when
the LEDs change. This needs to be added to keyboard_tstc() and
keyboard_getc(). If someone is able to test this I can send a patch for that
also.

This series is available at u-boot-dm branch input-working.

Changes in v3:
- Refactor the German keyboard code to use data rather than code
- Drop unrelated cros_keyb change
- Fix 'QUICK' typo
- Fix missing 'use' word
- Drop patches already applied

Changes in v2:
- Update input_add_tables() to add error checking
- Convert two multi-line comments to single-line comments
- Correct call to input_init()
- Drop CONFIG_VGA_AS_SINGLE_DEVICE from all x86 board config files
- Use device tree to handle this quirk

Simon Glass (12):
  input: Support the German keymap
  input: Adjust structure of code in process_modifier()
  input: Handle caps lock
  input: Allow updating of keyboard LEDs
  input: i8042: Convert to use the input library
  input: Add a Kconfig option for the i8042 keyboard
  x86: Add an i8042 device for boards that have it
  Drop CONFIG_ISA_KEYBOARD
  input: Convert i8042 to driver model
  i8042: Handle a duplicate power-on-reset response
  video: input: Clean up after i8042 conversion
  input: Convert 'keyboard' driver to use input library

 README   |  30 +-
 arch/x86/Kconfig |   6 +
 arch/x86/dts/bayleybay.dts   |   1 +
 arch/x86/dts/chromebook_link.dts |   5 +
 arch/x86/dts/keyboard.dtsi   |   5 +
 board/kosagi/novena/novena.c |   2 +-
 board/mpl/pip405/README  |   4 -
 doc/device-tree-bindings/input/i8042.txt |  10 +
 drivers/input/Kconfig|  10 +
 drivers/input/Makefile   |   2 +-
 drivers/input/cros_ec_keyb.c |   2 +-
 drivers/input/i8042.c| 563 ---
 drivers/input/input.c| 158 +++--
 drivers/input/keyboard.c | 290 +++-
 drivers/input/tegra-kbc.c|   2 +-
 drivers/video/cfb_console.c  |  20 +-
 include/configs/MIP405.h |   5 -
 include/configs/PIP405.h |   5 -
 include/configs/bayleybay.h  |   3 -
 include/configs/chromebox_panther.h  |   2 -
 include/configs/minnowmax.h  |   1 -
 include/configs/x86-chromebook.h |   2 +-
 include/configs/x86-common.h |   2 +-
 include/i8042.h  |   6 -
 include/input.h  |  17 +-
 include/keyboard.h   |   5 +
 26 files changed, 376 insertions(+), 782 deletions(-)
 create mode 100644 arch/x86/dts/keyboard.dtsi
 create mode 100644 doc/device-tree-bindings/input/i8042.txt

-- 
2.6.0.rc2.230.g3dd15c0

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

Re: [U-Boot] [PATCH V4 1/3] arm: discard relocation entries for secure text

[Stefano Babic]

On 11/11/2015 02:14, Peng Fan wrote:
> Hi Stefano,
> 
> On Tue, Nov 10, 2015 at 02:14:10PM +0100, Albert ARIBAUD wrote:
>> Hello Peng,
>>
>> On Fri, 23 Oct 2015 10:13:03 +0800, Peng Fan 
>> wrote:
>>> The code such as PSCI in section named secure is bundled with
>>> u-boot image, and when bootm, the code will be copied to their
>>> runtime address same to compliation/linking address -
>>> CONFIG_ARMV7_SECURE_BASE.
>>>
>>> When compile the PSCI code and link it into the u-boot image,
>>> there will be relocation entries in .rel.dyn section for PSCI.
>>> Actually, we do not needs these relocation entries.
>>>
>>> If still keep the relocation entries in .rel.dyn section,
>>> r0 at line 103 and 106 in arch/arm/lib/relocate.S may be an invalid
>>> address which may not support read/write for one SoC.
>>> 102 /* relative fix: increase location by offset */
>>> 103 add r0, r0, r4
>>> 104 ldr r1, [r0]
>>> 105 add r1, r1, r4
>>> 106 str r1, [r0]
>>>
>>> So discard them to avoid touching the relocation entry in
>>> arch/arm/lib/relocate.S.
>>>
>>> Signed-off-by: Peng Fan 
>>> Cc: Tom Warren 
>>> Cc: York Sun 
>>> Cc: Hans De Goede 
>>> Cc: Ian Campbell 
>>> Cc: Albert Aribaud 
>>> Cc: Tom Rini 
>>> Cc: Jan Kiszka 
>>> Cc: Stefano Babic 
>>> ---
>>>
>>> Changes v4:
>>>  none
>>>
>>> V2 thread: http://lists.denx.de/pipermail/u-boot/2015-October/230755.html
>>> Changes v3:
>>>  Move the relocation entries to the very begining and discard them.
>>>
>>> V1 thread: http://lists.denx.de/pipermail/u-boot/2015-October/229426.html
>>> Changes V2:
>>>  Refine commit msg.
>>>  Discard the relocation entry section for secure text.
>>>
>>>  arch/arm/cpu/u-boot.lds | 17 +
>>>  1 file changed, 17 insertions(+)
>>>
>>> diff --git a/arch/arm/cpu/u-boot.lds b/arch/arm/cpu/u-boot.lds
>>> index 03cd9f6..d48a905 100644
>>> --- a/arch/arm/cpu/u-boot.lds
>>> +++ b/arch/arm/cpu/u-boot.lds
>>> @@ -14,6 +14,23 @@ OUTPUT_ARCH(arm)
>>>  ENTRY(_start)
>>>  SECTIONS
>>>  {
>>> +   /*
>>> +* Discard the relocation entries for secure text.
>>> +* The secure code is bundled with u-boot image, so there will
>>> +* be relocations entries for the secure code, since we use
>>> +* "-mword-relocations" to compile and "-pie" to link into the
>>> +* final image. We do not need the relocation entries for secure
>>> +* code, because secure code will not be relocated, it only needs
>>> +* to be copied from loading address to CONFIG_ARMV7_SECURE_BASE,
>>> +* which is the linking and running address for secure code.
>>> +* If keep the relocation entries in .rel.dyn section,
>>> +* "relocation offset + linking address" may locates into an
>>> +* address that is reserved by SoC, then will trigger data abort.
>>> +*
>>> +* The reason that move .rel._secure at the beginning, is to
>>> +* avoid hole in the final image.
>>> +*/
>>> +   /DISCARD/ : { *(.rel._secure*) }
>>> . = 0x;
>>>  
>>> . = ALIGN(4);
>>> -- 
>>> 1.8.4
>>>
>>>
>>
>> Acked-by: Albert ARIBAUD 
>>
> 
> Can you please take a look at the patch set and merge?

I'll do

Best regards,
Stefano Babic


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

[U-Boot] [PATCH v3 01/12] input: Support the German keymap

[Simon Glass]

Add support for the German keymap, taken from i8042.c. This can be selected
when the input library it initialised.

Signed-off-by: Simon Glass 
---

Changes in v3:
- Refactor the German keyboard code to use data rather than code

Changes in v2:
- Update input_add_tables() to add error checking

 board/kosagi/novena/novena.c |   2 +-
 drivers/input/cros_ec_keyb.c |   2 +-
 drivers/input/input.c| 109 ++-
 drivers/input/tegra-kbc.c|   2 +-
 include/input.h  |   3 +-
 5 files changed, 102 insertions(+), 16 deletions(-)

diff --git a/board/kosagi/novena/novena.c b/board/kosagi/novena/novena.c
index 4a9f724..babba85 100644
--- a/board/kosagi/novena/novena.c
+++ b/board/kosagi/novena/novena.c
@@ -88,7 +88,7 @@ int drv_keyboard_init(void)
debug("%s: Cannot set up input\n", __func__);
return -1;
}
-   input_add_tables(&button_input);
+   input_add_tables(&button_input, false);
button_input.read_keys = novena_gpio_button_read_keys;
 
error = input_stdio_register(&dev);
diff --git a/drivers/input/cros_ec_keyb.c b/drivers/input/cros_ec_keyb.c
index fe5caea..9bc4555 100644
--- a/drivers/input/cros_ec_keyb.c
+++ b/drivers/input/cros_ec_keyb.c
@@ -211,7 +211,7 @@ static int cros_ec_kbd_probe(struct udevice *dev)
 
priv->input = input;
input->dev = dev;
-   input_add_tables(input);
+   input_add_tables(input, false);
input->read_keys = cros_ec_kbc_check;
strcpy(sdev->name, "cros-ec-keyb");
 
diff --git a/drivers/input/input.c b/drivers/input/input.c
index 9e552f3..96fc195 100644
--- a/drivers/input/input.c
+++ b/drivers/input/input.c
@@ -79,6 +79,88 @@ static unsigned char kbd_ctrl_xlate[] = {
'\r', 0xff, '/',  '*',
 };
 
+static const uchar kbd_plain_xlate_german[] = {
+   0xff, 0x1b,  '1',  '2',  '3',  '4',  '5',  '6', /* scan 00-07 */
+'7',  '8',  '9',  '0', 0xe1, '\'', 0x08, '\t', /* scan 08-0F */
+'q',  'w',  'e',  'r',  't',  'z',  'u',  'i', /* scan 10-17 */
+'o',  'p', 0x81,  '+', '\r', 0xff,  'a',  's', /* scan 18-1F */
+'d',  'f',  'g',  'h',  'j',  'k',  'l', 0x94, /* scan 20-27 */
+   0x84,  '^', 0xff,  '#',  'y',  'x',  'c',  'v', /* scan 28-2F */
+'b',  'n',  'm',  ',',  '.',  '-', 0xff,  '*', /* scan 30-37 */
+' ',  ' ', 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, /* scan 38-3F */
+   0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,  '7', /* scan 40-47 */
+'8',  '9',  '-',  '4',  '5',  '6',  '+',  '1', /* scan 48-4F */
+'2',  '3',  '0',  ',', 0xff, 0xff,  '<', 0xff, /* scan 50-57 */
+   0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, /* scan 58-5F */
+   0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, /* scan 60-67 */
+   0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, /* scan 68-6F */
+   0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, /* scan 70-77 */
+   0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, /* scan 78-7F */
+   '\r', 0xff,  '/',  '*',
+};
+
+static unsigned char kbd_shift_xlate_german[] = {
+  0xff, 0x1b,  '!',  '"', 0x15,  '$',  '%',  '&', /* scan 00-07 */
+'/',  '(',  ')',  '=',  '?',  '`', 0x08, '\t', /* scan 08-0F */
+'Q',  'W',  'E',  'R',  'T',  'Z',  'U',  'I', /* scan 10-17 */
+'O',  'P', 0x9a,  '*', '\r', 0xff,  'A',  'S', /* scan 18-1F */
+'D',  'F',  'G',  'H',  'J',  'K',  'L', 0x99, /* scan 20-27 */
+   0x8e, 0xf8, 0xff, '\'',  'Y',  'X',  'C',  'V', /* scan 28-2F */
+'B',  'N',  'M',  ';',  ':',  '_', 0xff,  '*', /* scan 30-37 */
+' ',  ' ', 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, /* scan 38-3F */
+   0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,  '7', /* scan 40-47 */
+'8',  '9',  '-',  '4',  '5',  '6',  '+',  '1', /* scan 48-4F */
+'2',  '3',  '0',  ',', 0xff, 0xff,  '>', 0xff, /* scan 50-57 */
+   0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, /* scan 58-5F */
+   0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, /* scan 60-67 */
+   0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, /* scan 68-6F */
+   0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, /* scan 70-77 */
+   0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, /* scan 78-7F */
+   '\r', 0xff,  '/',  '*',
+};
+
+static unsigned char kbd_right_alt_xlate_german[] = {
+   0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, /* scan 00-07 */
+'{',  '[',  ']',  '}', '\\', 0xff, 0xff, 0xff, /* scan 08-0F */
+'@', 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, /* scan 10-17 */
+   0xff, 0xff, 0xff,  '~', 0xff, 0xff, 0xff, 0xff, /* scan 18-1F */
+   0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, /* scan 20-27 */
+   0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, /* scan 28-2F */
+   0xff, 0xff, 0xe6, 0xff, 0xff, 0xff, 0xff, 0xff, /* scan 30-37 */
+   0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, /* scan 38-3F */
+   0xff, 0xff, 0xff, 0xff, 0xf

[U-Boot] [PATCH v3 03/12] input: Handle caps lock

[Simon Glass]

When caps lock is enabled we should convert lower case to upper case. Add
this to the input key processing so that caps lock works correctly.

Signed-off-by: Simon Glass 
---

Changes in v3: None
Changes in v2: None

 drivers/input/input.c | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/drivers/input/input.c b/drivers/input/input.c
index 7513226..a8a15c9 100644
--- a/drivers/input/input.c
+++ b/drivers/input/input.c
@@ -453,16 +453,19 @@ static int input_keycodes_to_ascii(struct input_config 
*config,
/* Start conversion by looking for the first new keycode (by same). */
for (i = same; i < num_keycodes; i++) {
int key = keycode[i];
-   int ch = (key < table->num_entries) ? table->xlate[key] : 0xff;
+   int ch;
 
/*
 * For a normal key (with an ASCII value), add it; otherwise
 * translate special key to escape sequence if possible.
 */
-   if (ch != 0xff) {
-   if (ch_count < max_chars)
-   output_ch[ch_count] = (uchar)ch;
-   ch_count++;
+   if (key < table->num_entries) {
+   ch = table->xlate[key];
+   if ((config->flags & FLAG_CAPS_LOCK) &&
+   ch >= 'a' && ch <= 'z')
+   ch -= 'a' - 'A';
+   if (ch_count < max_chars && ch != 0xff)
+   output_ch[ch_count++] = (uchar)ch;
} else {
ch_count += input_keycode_to_ansi364(config, key,
output_ch, max_chars);
-- 
2.6.0.rc2.230.g3dd15c0

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

Re: [U-Boot] [RFC PATCH] lib/tiny-printf.c: Add tiny printf function for space limited environments

[Albert ARIBAUD]

Hello Stefan,

On Wed, 11 Nov 2015 15:25:09 +0100, Stefan Roese  wrote:
> This patch adds a small printf() version that supports all basic formats.
> Its intented to be used in U-Boot SPL versions on platforms with very
> limited internal RAM sizes.

It would be very useful to document CONFIG_USE_TINY_PRINTF in ./README,
and especially to indicate which format specifiers are supported and
which are not.

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

Re: [U-Boot] [PATCH v2 18/26] dm: usb: Remove inactive children after a bus scan

[Hans de Goede]

Hi,

On 11-11-15 00:30, Simon Glass wrote:

Hi Hans,

On 9 November 2015 at 12:25, Simon Glass  wrote:

Hi Hans,

On 9 November 2015 at 00:22, Hans de Goede  wrote:

Hi,

On 09-11-15 07:48, Simon Glass wrote:


Each scan of the USB bus may return different results. Existing
driver-model
devices are reused when found, but if a device no longer exists it will
stay
around, de-activated, but bound.

Detect these devices and remove them after the scan completes.

Signed-off-by: Simon Glass 



I wonder how this is better then my original:
"dm: usb: Use device_unbind_children to clean up usb devs on stop"

Patch, the end result of both patches is the same and both are
a NOP when DM_DEVICE_REMOVE is not set. Where as my code seems
to be a much more KISS approach to the problem (my approach is
just 3 lines vs 23 lines for yours).

I know we will need usb_find_child in the DM_DEVICE_REMOVE not
set case, but why not only revert the:

"dm: usb: Rename usb_find_child to usb_find_emul_child"

commit, keep the other 2 you revert and drop this patch ?

This drops 3 patches from your patch-set and the end result is
more clean IMHO.


I would like to avoid binding/unbinding things when nothing changes if
possible. Also I'd like to support attaching device tree
nodes/properties to USB devices as necessary, as we do with PCI, and
removing things breaks that.

I still have to figure out one more test case, so I'll do that before
commenting further.


I've added the test case and pushed a new tree. However it turns out
that this doesn't behave differently.

So please can you go ahead and run your original (manual) test case?
I'd like to make sure that my automated tests are correct and catch
the bug you reported and fixed.


Ok, I've ran a whole battery of tests on your u-boot-dm/usb-working branch.

There are 2 issues:

1) You need to add these change to the commit introducing usb-keyb dm
support (or one of the related commits), otherwise usb-keyb support
breaks:

--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -513,6 +513,7 @@ config ARCH_SUNXI
select DM
select DM_GPIO
select DM_ETH
+   select DM_KEYBOARD
select DM_SERIAL
select DM_USB
select OF_CONTROL

The breakage is that without this usb_scan_device() returns -96
(EPFNOSUPPORT) for usb keyboards.

2) With that branch there still is the purely cosmetical issue,
that if one plugs a usb-stick + keyb into the same hub, then swaps
their place and do "usb reset" and then "usb tree" looks like this:

USB device tree:
  1  Hub (480 Mb/s, 100mA)
  |   USB2.0 Hub
  |
  +-3  Human Interface (1.5 Mb/s, 100mA)
  |SINO WEALTH USB Composite Device
  |
  +-2  Mass Storage (480 Mb/s, 100mA)
   USB Flash Disk 4C0E960F

Notice the order of devices listed: 1 - 3 - 2, which is a bit weird,
as said this is purely cosmetical.

Note you can easily fix this by only reverting the:

"dm: usb: Rename usb_find_child to usb_find_emul_child"

commit, and keep the other 2 you revert and dropping this patch ?

As I already suggested before, this is both more KISS and as you
can see it solves some actually (admittedly very minor) issues.

I'm not really buying your arguments for your more complex solution,
as shown above re-using the devices actually causes issues.

Your other argument of wanting to attach device-tree properties
I also do not find a strong argument, for one there has never been
a need to do so sofar, and if we ever need this we need a way
to specify which usb-device the properties belong to based on
the topology under the host / root-hub anyway, and match things
up when first scanning the bus. And if we can match things up
on the first scan we can also match them up on subsequent scans
and attach the same of-node again.

Anyways I'm fine with doing things your way, but I still have
a preference for the more KISS and IMHO robust solution of
simple unbinding all devices on usb-stop.

###

Talking about usb-stop, there is still one (BIG!) problem after
this patch set when building usb-support with DM_DEVICE_REMOVE
not set. This means that the controllers dma engines will not
be stopped when booting the actual OS and they will still be
accessing parts of the main memory while the actual OS is
booting, which is BAD. So I suggest adding something like
this to all host drivers which use dma in this way:

#if defined CONFIG_DM_USB && !defined CONFIG_DM_DEVICE_REMOVE
#error The EHCI driver cannot be used without CONFIG_DM_DEVICE_REMOVE otherwise 
DMA stays active while booting the OS
#endif

Regards,

Hans












Changes in v2: None

   drivers/usb/host/usb-uclass.c | 23 +++
   1 file changed, 23 insertions(+)

diff --git a/drivers/usb/host/usb-uclass.c b/drivers/usb/host/usb-uclass.c
index 4aa92f8..50538e0 100644
--- a/drivers/usb/host/usb-uclass.c
+++ b/drivers/usb/host/usb-uclass.c
@@ -202,6 +202,20 @@ static void usb_scan_bus(struct udevice *bus, bool
recurse)
 printf("%d USB Device(s) found

[U-Boot] [PATCH] fastboot: mmc: Fix use of 64 bit division

[Hans de Goede]

Directly doing a 64 bit division (when CONFIG_SYS_64BIT_LBA is set)
causes linking to fail when building u-boot for ARMv7 with a hard-float
tool-chain.

This commit fixes this by properly using div_u64 for the division.

Note that an alternative fix would be to stop using lbaint_t for
blkcnt / blks, since the passed in "download_bytes" is only 32 bits
anyways. But we may want to support files / partitions larger then 4G
in the near future and using div_u64 is future proof for when
download_bytes' type gets changed to a lbaint_t itself.

Signed-off-by: Hans de Goede 
---
 common/fb_mmc.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/common/fb_mmc.c b/common/fb_mmc.c
index 0c48cf9..83d66ed 100644
--- a/common/fb_mmc.c
+++ b/common/fb_mmc.c
@@ -11,6 +11,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #ifndef CONFIG_FASTBOOT_GPT_NAME
 #define CONFIG_FASTBOOT_GPT_NAME GPT_ENTRY_NAME
@@ -64,7 +66,7 @@ static void write_raw_image(block_dev_desc_t *dev_desc, 
disk_partition_t *info,
 
/* determine number of blocks to write */
blkcnt = ((download_bytes + (info->blksz - 1)) & ~(info->blksz - 1));
-   blkcnt = blkcnt / info->blksz;
+   blkcnt = div_u64(blkcnt, info->blksz);
 
if (blkcnt > info->size) {
error("too large for partition: '%s'\n", part_name);
-- 
2.5.0

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

Re: [U-Boot] [PATCH v7 21/21] sf: Add SPI NOR protection mechanism

[Jagan Teki]

On 11 November 2015 at 15:13, Fabio Estevam  wrote:
> On Wed, Nov 11, 2015 at 12:56 AM, Simon Glass  wrote:
>
>> It crashes reading the environment:
>>
>> U-Boot 2015.10-00544-gcad0499 (Nov 10 2015 - 17:06:00 -0700)
>>
>> CPU:   Intel(R) Core(TM) i5-3427U CPU @ 1.80GHz
>> DRAM:  2.7 GiB
>> SF: Detected W25Q64CV with page size 256 Bytes, erase size 4 KiB, total 8 MiB
>> *** Warning - bad CRC, using default environment
>>
>> Video: 1280x1024x16
>> Model: Google Link
>> SF: Detected W25Q64CV with page size 256 Bytes, erase size 4 KiB, total 8 MiB
>> Invalid Opcode (Undefined Opcode)
>> EIP: 0010:[<0058>] EFLAGS: 00010283
>> Original EIP :[<52fbb058>]
>
> In this patch we only assign the lock ops if the flash is of ST Micro
> type, so not sure why it affects Winbound flash as well.
>
> Jagan, would you have some ideas, please?

Issue still there? because we added these lock ops only for ST Micro flash's.

thanks!
-- 
Jagan | openedev.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/3] vexpress64: remove #error

[Ryan Harkin]

Hi,

This is a ping to revive this patch and the next one in the series:
"[PATCH 3/3] vexpress64: store env in flash"

Patch 1/3 was resent separately and has been merged.

This patch (and the subsequent one in the series) hasn't been
Reviewed-by or Acked-by anyone, but in a thread for patch 3/3 in this
series, Tom Rini and I had this conversation:

Tom> The host tools are not board-independent as they include a copy of the
Tom> target board env.  Keep that in mind.

Me> So that means we can't use #error in the target board include file
Me> (eg. vexpress_aemv8a.h) to indicate that no board was set, correct?

Tom> Correct.

So if Juno wants to use the NOR flash and therefore, the host tools,
then first we need this patch to remove the #error statements.

Thanks,
Ryan.


On 27 October 2015 at 12:29, Ryan Harkin  wrote:
> On 27 October 2015 at 11:36, Linus Walleij  wrote:
>> On Wed, Oct 21, 2015 at 11:54 AM, Ryan Harkin  wrote:
>>
>>> This patch allows vexpress64 targets to be compiled when
>>> CONFIG_SYS_FLASH_CFI is enabled.
>>
>> I can't see what this has to do with enabling CFI?
>
> The errors happen when I enable CFI on Juno or FVP.  Enabling CFI
> support includes envcrc.c into the build, which then includes
> include/config.h, which in turn includes
> include/configs/vexpress_aemv8a.h, but without a board defined,
> despite building a Juno or FVP configuration.  I don't really know why
> the board isn't defined at that point.
>
> Looking deeper into why envcrc is included into the build, it was
> another #define that included it.
>
> I can see that tools/Makefile adds envcrc if CONFIG_BUILD_ENVCRC is
> defined, which in turn is enabled if ENVCRC-y is defined, which seems
> to happen if CONFIG_ENV_IS_IN_FLASH is defined.
>
> So my comment is wrong.
>
>>
>>> I considered using #warning instead of #error, but this just clutters up
>>> the build output and hides real warnings.
>>>
>>> Without this patch, you see errors during compilation like this:
>>>
>>> include/configs/vexpress_aemv8a.h:42:2: error: #error "Unknown board
>>> variant"
>>>  #error "Unknown board variant"
>>
>> The #error is there because noone could answer the question I
>> posed: what AEMv8 boards are there that are neither FVP nor
>> Juno?
>
> AEMv8 may be the wrong term anyway.  I *think* AEMv8 really only
> refers to one flavour of the FVP:  AEMv8 is an representation of the
> complete ARMv8 architecture, not of a specific CPU variant such as
> Cortex A57, which omits some of the arch.
>
> Everything we're including in this vexpress_aemv8a file is really more
> like just vexpress64, with variants inside it for Juno and FVP.
>
> And with a bit of code to detect and handle the platform differences,
> we could probably create a single binary that works on everything
> covered by this config.  Although I think the #define for the CFI base
> address could be a sticking point there.
>
> Currently, ARM have:
>
> Models:
> - FVP Foundation models
> - FVP AEMv8 models
> - FVP Cortex A57/A53 models
>
> ^ the same binary runs on all three, although I never test on Cortex
> models.  There is a semihosting variant and I've created a DRAM
> variant.
>
> Real boards:
> - Juno R0
> - Juno R1
>
> ^ the same binary runs on both
>
> There are no other public platforms, to my knowledge.  ARM have some
> internal models that have different peripheral sets, CPU
> configurations, etc... but these aren't covered by the public code at
> all.
>
>>
>> So what board variant are you compiling for here? I suspect a
>> non-upstream thingofabob? Maybe there is a better way to cater
>> for that than this magic catch-all?
>
> I was building for Juno.
>
>
>>
>> Yours,
>> Linus Walleij
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2] vexpress64: use 2nd DRAM bank only on juno

[Ryan Harkin]

Hi,

This is just a ping in case this patch has been forgotten.  It was
Acked and Reviewed.

Thanks,
Ryan.


On 27 October 2015 at 12:10, Linus Walleij  wrote:
> On Mon, Oct 26, 2015 at 12:00 PM, Ryan Harkin  wrote:
>
>> This patch makes the 2nd DRAM bank available on Juno only and not on
>> other vexpress64 targets, eg. the FVP models.
>>
>> The commit below added a 2nd bank of NOR flash for Juno, but also for
>> all vexpress64 targets:
>>
>> commit 2d0cee1ca2b9d977fa3214896bb2e30cfec77059
>> Author: Liviu Dudau 
>> Date:   Mon Oct 19 11:08:31 2015 +0100
>>
>> vexpress64: Juno: Declare all 8GB of RAM and make them visible to the 
>> kernel.
>>
>> Juno comes with 8GB RAM, but U-Boot only passes 2GB to the kernel.
>> Declare a secondary memory bank and set the sizes correctly.
>>
>> Signed-off-by: Liviu Dudau 
>> Reviewed-by: Linus Walleij 
>> Reviewed-by: Ryan Harkin 
>> Tested-by: Ryan Harkin 
>>
>> Unfortunately, I only fully tested on Juno R0, R1 and the FVP Foundation
>> model.  Whilst FVP Base AEMV8 models run U-Boot OK, they fail to boot
>> the kernel.
>>
>> Signed-off-by: Ryan Harkin 
>> Acked-by: Liviu Dudau 
>
> Reviewed-by: Linus Walleij 
>
> This relates to the discussion about "unknown board variants"
> that we discuss in another thread, but let's keep that there.
>
> Yours,
> Linus Walleij
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] buildman: README: add links for toolchains not available on kernel.org

[Marek Vasut]

On Wednesday, November 11, 2015 at 02:37:08 PM, Thomas Chou wrote:
> Add links for toolchains not available on kernel.org.
> 
> The sh4 toolchains from kernel.org dose not work for some boards,
> so use the sh from Sourcery.
> 
> Signed-off-by: Thomas Chou 

Wouldn't it instead make more sense to get kernel.org to mirror those
toolchains ? The links might not last forever, but I think kernel.org
is not gonna go belly-up any soon.

> ---
>  tools/buildman/README | 18 +-
>  1 file changed, 17 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/buildman/README b/tools/buildman/README
> index 10c7135..e205278 100644
> --- a/tools/buildman/README
> +++ b/tools/buildman/README
> @@ -156,7 +156,6 @@ aarch64:
> /opt/linaro/gcc-linaro-aarch64-none-elf-4.8-2013.10_linux
> [toolchain-alias]
>  x86: i386
>  blackfin: bfin
> -sh: sh4
>  nds32: nds32le
>  openrisc: or32
> 
> @@ -341,6 +340,23 @@ Testing
>   - found
> '/home/sjg/.buildman-toolchains/gcc-4.5.1-nolibc/or32-linux/bin/or32-linux
> -gcc' Tool chain test:  OK
> 
> +Or download them all from kernel.org and move them to /toolchains
> directory, +
> +$ for i in aarch64 arm avr32 i386 m68k microblaze mips or32 powerpc sparc
> +  do
> +  ./tools/buildman/buildman --fetch-arch $i
> +  done
> +$ mkdir -p /toolchains
> +$ mv ~/.buildman-toolchains/*/* /toolchains/
> +
> +For those not available from kernel.org, download from the following
> links, +
> +arc:
> https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/releases
> / +blackfin: http://sourceforge.net/projects/adi-toolchain/files/
> +nds32: http://osdk.andestech.com/packages/nds32le-linux-glibc-v1.tgz
> +nios2: http://sourcery.mentor.com/public/gnu_toolchain/nios2-linux-gnu/
> +sh: http://sourcery.mentor.com/public/gnu_toolchain/sh-linux-gnu/
> +
>  Buildman should now be set up to use your new toolchain.
> 
>  At the time of writing, U-Boot has these architectures:

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

Re: [U-Boot] how to load u-boot environment from nand while spl is loading

[Marek Vasut]

On Wednesday, November 11, 2015 at 04:29:34 PM, Francesco Lucconi wrote:

Hi,

> I'm working with imx28evk reference board with u-boot 2011.12 and for my
> specific purposes I have to load u-boot nand environment during spl
> binary is loading. I'm working with a static environment but this is not
> so useful because I need to initialize some drivers (such as serial
> console) with the current values stored within nand flash environment
> (such as baudrate variable).
> Comparing my u-boot version with more recent ones (u-boot 2015.10) I've
> found out that the enviroment loading has been applied during ram
> bootstrapping...can't we do this operation before u-boot.bin has been
> loaded in ddr memory?
> Could you send me any tips to solve this issue?

I think that the latest mainline already configures the serial console from
the environment or at least it sets up the environment to be complete enough
for getenv() to work. I'd suggest you give that a spin.

I cannot help you with the ancient U-Boot from Freescale and I'd suggest you
to avoid it like plague if at all possible.

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

[U-Boot] [PATCH 2/2] sf_probe: Add lock ops for SST SPI NOR flash

[Fabio Estevam]

From: Fabio Estevam 

SST SPI NOR flash has the same locking programming bits as ST Micro.

Add support for it.

Signed-off-by: Fabio Estevam 
---
 drivers/mtd/spi/sf_internal.h | 1 +
 drivers/mtd/spi/sf_probe.c| 3 ++-
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/mtd/spi/sf_internal.h b/drivers/mtd/spi/sf_internal.h
index 8793f18..85c8a89 100644
--- a/drivers/mtd/spi/sf_internal.h
+++ b/drivers/mtd/spi/sf_internal.h
@@ -64,6 +64,7 @@ enum spi_nor_option_flags {
 #define SPI_FLASH_CFI_MFR_SPANSION 0x01
 #define SPI_FLASH_CFI_MFR_STMICRO  0x20
 #define SPI_FLASH_CFI_MFR_MACRONIX 0xc2
+#define SPI_FLASH_CFI_MFR_SST  0xbf
 #define SPI_FLASH_CFI_MFR_WINBOND  0xef
 
 /* Erase commands */
diff --git a/drivers/mtd/spi/sf_probe.c b/drivers/mtd/spi/sf_probe.c
index bc05d30..fea6c24 100644
--- a/drivers/mtd/spi/sf_probe.c
+++ b/drivers/mtd/spi/sf_probe.c
@@ -184,8 +184,9 @@ static int spi_flash_validate_params(struct spi_slave *spi, 
u8 *idcode,
 
/* lock hooks are flash specific - assign them based on idcode0 */
switch (idcode[0]) {
-#ifdef CONFIG_SPI_FLASH_STMICRO
+#if defined CONFIG_SPI_FLASH_STMICRO || defined CONFIG_SPI_FLASH_SST
case SPI_FLASH_CFI_MFR_STMICRO:
+   case SPI_FLASH_CFI_MFR_SST:
flash->flash_lock = stm_lock;
flash->flash_unlock = stm_unlock;
flash->flash_is_locked = stm_is_locked;
-- 
1.9.1

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

[U-Boot] [PATCH 1/2] spi_flash: Add error message when lock operations are not supported

[Fabio Estevam]

From: Fabio Estevam 

In the case of lock operations not being supported, we should better let
the user know instead of failing silently.

Signed-off-by: Fabio Estevam 
---
 include/spi_flash.h | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/include/spi_flash.h b/include/spi_flash.h
index 0ae0062..ff51c50 100644
--- a/include/spi_flash.h
+++ b/include/spi_flash.h
@@ -237,8 +237,10 @@ static inline int spi_flash_erase(struct spi_flash *flash, 
u32 offset,
 static inline int spi_flash_protect(struct spi_flash *flash, u32 ofs, u32 len,
bool prot)
 {
-   if (!flash->flash_lock)
+   if (!flash->flash_lock) {
+   printf("Protect operation not supported for this flash\n");
return -EOPNOTSUPP;
+   }
 
if (prot)
return flash->flash_lock(flash, ofs, len);
-- 
1.9.1

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

[U-Boot] [PATCH] board/ti/am335x: add support for BeagleBone Green

[Robert Nelson]

SeeedStudio BeagleBone Green (BBG) is clone of the BeagleBone Black (BBB) minus
the HDMI port and addition of two Grove connectors (i2c2 and usart2).

This board can be identified by the 1A value after A335BNLT (BBB) in the at24 
eeprom:
1A: [aa 55 33 ee 41 33 33 35  42 4e 4c 54 1a 00 00 00 |.U3.A335BNLT|]

http://beagleboard.org/green
http://www.seeedstudio.com/wiki/Beaglebone_green

In Mainline Kernel as of:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=79a4e64c679d8a0b1037da174e4aea578c80c4e6

Patch tested on BeagleBone Black (rev C) and BeagleBone Green (production model)

Signed-off-by: Robert Nelson 
CC: Tom Rini 
CC: Jason Kridner 
---
 board/ti/am335x/board.c  | 12 +---
 include/configs/am335x_evm.h |  7 ++-
 2 files changed, 15 insertions(+), 4 deletions(-)

diff --git a/board/ti/am335x/board.c b/board/ti/am335x/board.c
index f0cb1e2..f56d17e 100644
--- a/board/ti/am335x/board.c
+++ b/board/ti/am335x/board.c
@@ -507,9 +507,15 @@ int board_late_init(void)
safe_string[sizeof(header.name)] = 0;
setenv("board_name", safe_string);
 
-   strncpy(safe_string, (char *)header.version, sizeof(header.version));
-   safe_string[sizeof(header.version)] = 0;
-   setenv("board_rev", safe_string);
+   /* BeagleBone Green eeprom, board_rev: 0x1a 0x00 0x00 0x00 */
+   if ( (header.version[0] == 0x1a) && (header.version[1] == 0x00) &&
+(header.version[2] == 0x00) && (header.version[3] == 0x00) ) {
+   setenv("board_rev", "BBG1");
+   } else {
+   strncpy(safe_string, (char *)header.version, 
sizeof(header.version));
+   safe_string[sizeof(header.version)] = 0;
+   setenv("board_rev", safe_string);
+   }
 #endif
 
return 0;
diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h
index d58816d..ed3fd34 100644
--- a/include/configs/am335x_evm.h
+++ b/include/configs/am335x_evm.h
@@ -186,7 +186,12 @@
"if test $board_name = A335BONE; then " \
"setenv fdtfile am335x-bone.dtb; fi; " \
"if test $board_name = A335BNLT; then " \
-   "setenv fdtfile am335x-boneblack.dtb; fi; " \
+   "if test $board_rev = BBG1; then " \
+   "setenv fdtfile am335x-bonegreen.dtb; " \
+   "else " \
+   "setenv fdtfile am335x-boneblack.dtb; " \
+   "fi; " \
+   "fi; " \
"if test $board_name = A33515BB; then " \
"setenv fdtfile am335x-evm.dtb; fi; " \
"if test $board_name = A335X_SK; then " \
-- 
2.6.2

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

Re: [U-Boot] pull request: u-boot-uniphier/master

[Tom Rini]

On Wed, Nov 11, 2015 at 11:44:50PM +0900, Masahiro Yamada wrote:

> Hi Tom,
> 
> Here is my small pull request for v2016.01-rc1.
> 
> 
> The following changes since commit cad04990715f7eaecd45196e84cf10e9e3248dae:
> 
>   Merge branch 'master' of git://git.denx.de/u-boot-arm (2015-11-10
> 13:38:08 -0500)
> 
> are available in the git repository at:
> 
> 
>   git://git.denx.de/u-boot-uniphier.git master
> 
> for you to fetch changes up to b375219e732f044e7f48b676fa4e36e7c29d81e1:
> 
>   ARM: uniphier: drop UniPhier specific SMP code (2015-11-11 23:35:35 +0900)
> 

Applied to u-boot/master, thanks!

-- 
Tom


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

[U-Boot] pull request: u-boot-uniphier/master

[Masahiro Yamada]

Hi Tom,

Here is my small pull request for v2016.01-rc1.


The following changes since commit cad04990715f7eaecd45196e84cf10e9e3248dae:

  Merge branch 'master' of git://git.denx.de/u-boot-arm (2015-11-10
13:38:08 -0500)

are available in the git repository at:


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

for you to fetch changes up to b375219e732f044e7f48b676fa4e36e7c29d81e1:

  ARM: uniphier: drop UniPhier specific SMP code (2015-11-11 23:35:35 +0900)


Masahiro Yamada (3):
  ARM: dts: uniphier: fix interrupt number of USB core for PH1-Pro4
  ARM: dts: uniphier: add USB xHCI nodes for PH1-Pro5 and ProXstream2
  ARM: uniphier: drop UniPhier specific SMP code

 arch/arm/dts/uniphier-ph1-ld6b-ref.dts   |  8 
 arch/arm/dts/uniphier-ph1-pro4.dtsi  |  2 +-
 arch/arm/dts/uniphier-ph1-pro5-4kbox.dts |  4 
 arch/arm/dts/uniphier-ph1-pro5.dtsi  | 18 ++
 arch/arm/dts/uniphier-proxstream2-gentil.dts |  8 
 arch/arm/dts/uniphier-proxstream2-vodka.dts  |  4 
 arch/arm/dts/uniphier-proxstream2.dtsi   | 18 ++
 arch/arm/mach-uniphier/Kconfig   |  8 
 arch/arm/mach-uniphier/lowlevel_init.S   | 53
-
 9 files changed, 61 insertions(+), 62 deletions(-)


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

Re: [U-Boot] [PATCH] ARM: uniphier: drop UniPhier specific SMP code

[Masahiro Yamada]

2015-11-08 21:43 GMT+09:00 Tom Rini :
> On Sat, Nov 07, 2015 at 01:12:14AM +0900, Masahiro Yamada wrote:
>> 2015-11-06 22:46 GMT+09:00 Tom Rini :
>> > On Fri, Nov 06, 2015 at 10:16:30PM +0900, Masahiro Yamada wrote:
>> >
>> >> The latest Linux can directly handle SMP operations for UniPhier SoCs
>> >> without any help of U-boot.  Drop the relevant code from U-boot.
>> >>
>> >> See commit b1e4006aeda8c8784029de17d47987c21ea75f6d ("ARM: uniphier:
>> >> rework SMP operations to use trampoline code") in Linux Kernel.
>> >>
>> >> Signed-off-by: Masahiro Yamada 
>> >
>> > So my question for you is how much of a concern is running older kernels
>> > and newer U-Boots on these platforms?  I know that for example we
>> > couldn't do something like that in "beagle" land, and for Allwinner
>> > platforms we still have ways of making the older but most featureful
>> > kernels work.
>>
>>
>> Good question.
>>
>> Socionext (and my former company, Panasonic) tended to
>> modify source code locally (ugly hacks here and there) and never tried
>> to push patches to the upstream.
>>
>> I started the kernel upstreaming this year,
>> and the company changed the mind and stared to realize its importance,
>> but it is under way.
>>
>> The mainline kernel requires some more extra patches that have not
>> been upstreamed yet.
>>
>> So, our customers cannot do anything with the mainline kernel alone.
>> They are supposed to use software stacks released from us.
>>
>> So, the combination of the older kernels + newer U-boot does not matter.
>> The older kernels were not working in the first place.
>
> Thanks!
>
> Reviewed-by: Tom Rini 
>


Applied to u-boot-uniphier.


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

Re: [U-Boot] [PATCH 2/2] ARM: dts: uniphier: add USB xHCI nodes for PH1-Pro5 and ProXstream2

[Masahiro Yamada]

2015-11-04 21:56 GMT+09:00 Masahiro Yamada :
> This makes USB3.0 available on new SoCs/boards.
>
> Signed-off-by: Masahiro Yamada 
> ---
>
>  arch/arm/dts/uniphier-ph1-ld6b-ref.dts   |  8 
>  arch/arm/dts/uniphier-ph1-pro5-4kbox.dts |  4 
>  arch/arm/dts/uniphier-ph1-pro5.dtsi  | 18 ++
>  arch/arm/dts/uniphier-proxstream2-gentil.dts |  8 
>  arch/arm/dts/uniphier-proxstream2-vodka.dts  |  4 
>  arch/arm/dts/uniphier-proxstream2.dtsi   | 18 ++
>  6 files changed, 60 insertions(+)
>

Applied to u-boot-uniphier.



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

Re: [U-Boot] [PATCH 1/2] ARM: dts: uniphier: fix interrupt number of USB core for PH1-Pro4

[Masahiro Yamada]

2015-11-05 0:32 GMT+09:00 Masahiro Yamada :
> Hi Bin,
>
>
> 2015-11-04 22:03 GMT+09:00 Bin Meng :
>> Hi Masahiro,
>>
>> On Wed, Nov 4, 2015 at 8:56 PM, Masahiro Yamada
>>  wrote:
>>> The IRQ is not used in U-boot, but this would be useful to sync
>>> device trees between Linux and U-boot.
>>
>> Nits: U-boot -> U-Boot
>
>
> Thanks.
>
> I will fix it when I apply this patch.
>
>

Applied to u-boot-uniphier/master, fixing U-boot -> U-Boot.



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

[U-Boot] [RFC PATCH] lib/tiny-printf.c: Add tiny printf function for space limited environments

[Stefan Roese]

This patch adds a small printf() version that supports all basic formats.
Its intented to be used in U-Boot SPL versions on platforms with very
limited internal RAM sizes.

To enable it, just define CONFIG_USE_TINY_PRINTF in your defconfig. This
will result in the SPL using this tiny function and the main U-Boot
still using the full-blown printf() function.

This code was copied from:
http://www.sparetimelabs.com/printfrevisited
With mostly only coding style related changes so that its checkpatch
clean.

The size reduction is about 2.5KiB. Here a comparison for the db-88f6820-gp
(Marvell A38x) SPL:

Without this patch:
 108075   132982824  124197   1e525 ./spl/u-boot-spl

With this patch:
 105398   132982852  121548   1dacc ./spl/u-boot-spl

Note:
To make it possible to compile tiny-printf.c instead of vsprintf.c when
CONFIG_USE_TINY_PRINTF is defined, the functions printf() and vprintf() are
moved from common/console.c into vsprintf.c in this patch.

Signed-off-by: Stefan Roese 
Cc: Simon Glass 
Cc: Hans de Goede 
Cc: Tom Rini 
---
 common/console.c  |  39 
 lib/Kconfig   |   8 
 lib/Makefile  |   7 ++-
 lib/tiny-printf.c | 130 ++
 lib/vsprintf.c|  39 
 5 files changed, 183 insertions(+), 40 deletions(-)
 create mode 100644 lib/tiny-printf.c

diff --git a/common/console.c b/common/console.c
index ace206c..2bfd59f 100644
--- a/common/console.c
+++ b/common/console.c
@@ -535,45 +535,6 @@ void puts(const char *s)
}
 }
 
-int printf(const char *fmt, ...)
-{
-   va_list args;
-   uint i;
-   char printbuffer[CONFIG_SYS_PBSIZE];
-
-   va_start(args, fmt);
-
-   /* For this to work, printbuffer must be larger than
-* anything we ever want to print.
-*/
-   i = vscnprintf(printbuffer, sizeof(printbuffer), fmt, args);
-   va_end(args);
-
-   /* Print the string */
-   puts(printbuffer);
-   return i;
-}
-
-int vprintf(const char *fmt, va_list args)
-{
-   uint i;
-   char printbuffer[CONFIG_SYS_PBSIZE];
-
-#if defined(CONFIG_PRE_CONSOLE_BUFFER) && !defined(CONFIG_SANDBOX)
-   if (!gd->have_console)
-   return 0;
-#endif
-
-   /* For this to work, printbuffer must be larger than
-* anything we ever want to print.
-*/
-   i = vscnprintf(printbuffer, sizeof(printbuffer), fmt, args);
-
-   /* Print the string */
-   puts(printbuffer);
-   return i;
-}
-
 /* test if ctrl-c was pressed */
 static int ctrlc_disabled = 0; /* see disable_ctrl() */
 static int ctrlc_was_pressed = 0;
diff --git a/lib/Kconfig b/lib/Kconfig
index 30e84ed..faf3de3 100644
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -36,6 +36,14 @@ config SYS_VSNPRINTF
  Thumb-2, about 420 bytes). Enable this option for safety when
  using sprintf() with data you do not control.
 
+config USE_TINY_PRINTF
+   bool "Enable tiny printf() version"
+   help
+ This option enables a tiny, stripped down printf version.
+ This should only be used in space limited environments,
+ like SPL versions with hard memory limits. This version
+ reduces the code size by about 2.5KiB on armv7.
+
 config REGEX
bool "Enable regular expression support"
default y if NET
diff --git a/lib/Makefile b/lib/Makefile
index 3eecefa..54b6555 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -79,7 +79,12 @@ obj-y += string.o
 obj-y += time.o
 obj-$(CONFIG_TRACE) += trace.o
 obj-$(CONFIG_LIB_UUID) += uuid.o
-obj-y += vsprintf.o
 obj-$(CONFIG_LIB_RAND) += rand.o
 
+ifeq ($(CONFIG_SPL_BUILD)$(CONFIG_USE_TINY_PRINTF),yy)
+obj-y += tiny-printf.o
+else
+obj-y += vsprintf.o
+endif
+
 subdir-ccflags-$(CONFIG_CC_OPTIMIZE_LIBS_FOR_SPEED) += -O2
diff --git a/lib/tiny-printf.c b/lib/tiny-printf.c
new file mode 100644
index 000..d743a36
--- /dev/null
+++ b/lib/tiny-printf.c
@@ -0,0 +1,130 @@
+/*
+ * Tiny printf version for SPL
+ *
+ * Copied from:
+ * http://www.sparetimelabs.com/printfrevisited/printfrevisited.php
+ *
+ * Copyright (C) 2004,2008  Kustaa Nyholm
+ *
+ * SPDX-License-Identifier:LGPL-2.1+
+ */
+
+#include 
+#include 
+#include 
+
+static char *bf;
+static char buf[12];
+static unsigned int num;
+static char uc;
+static char zs;
+
+static void out(char c)
+{
+   *bf++ = c;
+}
+
+static void out_dgt(char dgt)
+{
+   out(dgt + (dgt < 10 ? '0' : (uc ? 'A' : 'a') - 10));
+   zs = 1;
+}
+
+static void div_out(unsigned int div)
+{
+   unsigned char dgt = 0;
+
+   num &= 0x; /* just for testing the code with 32 bit ints */
+   while (num >= div) {
+   num -= div;
+   dgt++;
+   }
+
+   if (zs || dgt > 0)
+   out_dgt(dgt);
+}
+
+int printf(const char *fmt, ...)
+{
+   va_list va;
+   char ch;
+   char *p;
+
+   va_start(va, fmt);
+
+   while ((ch = *(fmt++))) {
+   if (ch != '%') {
+

Re: [U-Boot] [PATCH v7 21/21] sf: Add SPI NOR protection mechanism

[Fabio Estevam]

On Wed, Nov 11, 2015 at 12:56 AM, Simon Glass  wrote:
> Hi Fabio,
>
> On 10 November 2015 at 16:51, Fabio Estevam  wrote:
>>
>> Hi Simon,
>>
>> On Tue, Nov 10, 2015 at 10:09 PM, Simon Glass  wrote:
>>
>> > This patch breaks chromebook_link - I think because it adds a new
>> > operation which is not supported by all flash chips. Those that are
>> > not supported (i.e that don't have the 'flash_is_locked' method)
>> > should still work.
>>
>> What is the symptom you are seeing? Which SPI NOR flash does this board have?
>
> It crashes reading the environment:
>
> U-Boot 2015.10-00544-gcad0499 (Nov 10 2015 - 17:06:00 -0700)
>
> CPU:   Intel(R) Core(TM) i5-3427U CPU @ 1.80GHz
> DRAM:  2.7 GiB
> SF: Detected W25Q64CV with page size 256 Bytes, erase size 4 KiB, total 8 MiB
> *** Warning - bad CRC, using default environment
>
> Video: 1280x1024x16
> Model: Google Link
> SF: Detected W25Q64CV with page size 256 Bytes, erase size 4 KiB, total 8 MiB
> Invalid Opcode (Undefined Opcode)

I am wondering if this invalid opcode is caused by 6c2f758cee266f7648.

Could you please try this?

--- a/arch/x86/include/asm/bitops.h
+++ b/arch/x86/include/asm/bitops.h
@@ -364,7 +364,7 @@ static __inline__ int ffs(int x)
__asm__("bsfl %1,%0\n\t"
"jnz 1f\n\t"
"movl $-1,%0\n"
-   "1:" : "=r" (r) : "rm" (x));
+   "1:" : "=r" (r) : "g" (x));

return r+1;
 }
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] buildman: README: add links for toolchains not available on kernel.org

[Thomas Chou]

Add links for toolchains not available on kernel.org.

The sh4 toolchains from kernel.org dose not work for some boards,
so use the sh from Sourcery.

Signed-off-by: Thomas Chou 
---
 tools/buildman/README | 18 +-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/tools/buildman/README b/tools/buildman/README
index 10c7135..e205278 100644
--- a/tools/buildman/README
+++ b/tools/buildman/README
@@ -156,7 +156,6 @@ aarch64: 
/opt/linaro/gcc-linaro-aarch64-none-elf-4.8-2013.10_linux
 [toolchain-alias]
 x86: i386
 blackfin: bfin
-sh: sh4
 nds32: nds32le
 openrisc: or32
 
@@ -341,6 +340,23 @@ Testing
  - found 
'/home/sjg/.buildman-toolchains/gcc-4.5.1-nolibc/or32-linux/bin/or32-linux-gcc'
 Tool chain test:  OK
 
+Or download them all from kernel.org and move them to /toolchains directory,
+
+$ for i in aarch64 arm avr32 i386 m68k microblaze mips or32 powerpc sparc
+  do
+  ./tools/buildman/buildman --fetch-arch $i
+  done
+$ mkdir -p /toolchains
+$ mv ~/.buildman-toolchains/*/* /toolchains/
+
+For those not available from kernel.org, download from the following links,
+
+arc: 
https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/releases/
+blackfin: http://sourceforge.net/projects/adi-toolchain/files/
+nds32: http://osdk.andestech.com/packages/nds32le-linux-glibc-v1.tgz
+nios2: http://sourcery.mentor.com/public/gnu_toolchain/nios2-linux-gnu/
+sh: http://sourcery.mentor.com/public/gnu_toolchain/sh-linux-gnu/
+
 Buildman should now be set up to use your new toolchain.
 
 At the time of writing, U-Boot has these architectures:
-- 
2.5.0

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

Re: [U-Boot] [PATCH 1/2] tools: zynqimage: Add Xilinx Zynq boot header generation to mkimage

[Nathan Rossi]

On Wed, Nov 11, 2015 at 9:46 PM, Nathan Rossi  wrote:
> As with other platforms vendors love to create their own boot header
> formats. Xilinx is no different and for the Zynq platform/SoC there
> exists the "boot.bin" which is read by the platforms bootrom. This
> format is described to a useful extent within the Xilinx Zynq TRM.
>
> This implementation adds support for the 'zynqimage' to mkimage. The
> implementation only considers the most common boot header which is
> un-encrypted and packed directly after the boot header itself (no
> XIP, etc.). However this implementation does take into consideration the
> other fields of the header for image dumping use cases (vector table and
> register initialization).
>
> Signed-off-by: Nathan Rossi 
> Cc: Michal Simek 
> Cc: Tom Rini 
> ---
>  common/image.c|   1 +
>  include/image.h   |   3 +-
>  tools/Makefile|   1 +
>  tools/zynqimage.c | 259 
> ++
>  4 files changed, 263 insertions(+), 1 deletion(-)
>  create mode 100644 tools/zynqimage.c
>
> diff --git a/common/image.c b/common/image.c
> index 85c4f39..c36927f 100644
> --- a/common/image.c
> +++ b/common/image.c
> @@ -158,6 +158,7 @@ static const table_entry_t uimage_type[] = {
> {   IH_TYPE_RKIMAGE,"rkimage","Rockchip Boot Image" },
> {   IH_TYPE_RKSD,   "rksd",   "Rockchip SD Boot Image" },
> {   IH_TYPE_RKSPI,  "rkspi",  "Rockchip SPI Boot Image" },
> +   {   IH_TYPE_ZYNQIMAGE,  "zynqimage",  "Xilinx Zynq Boot Image" },
> {   -1, "",   "",   },
>  };
>
> diff --git a/include/image.h b/include/image.h
> index 08ae24a..299d6d2 100644
> --- a/include/image.h
> +++ b/include/image.h
> @@ -248,8 +248,9 @@ struct lmb;
>  #define IH_TYPE_RKIMAGE23  /* Rockchip Boot Image
>   */
>  #define IH_TYPE_RKSD   24  /* Rockchip SD card */
>  #define IH_TYPE_RKSPI  25  /* Rockchip SPI image   */
> +#define IH_TYPE_ZYNQIMAGE  26  /* Xilinx Zynq Boot Image */
>
> -#define IH_TYPE_COUNT  26  /* Number of image types */
> +#define IH_TYPE_COUNT  27  /* Number of image types */
>
>  /*
>   * Compression Types
> diff --git a/tools/Makefile b/tools/Makefile
> index 9082bda..9cfd80b 100644
> --- a/tools/Makefile
> +++ b/tools/Makefile
> @@ -98,6 +98,7 @@ dumpimage-mkimage-objs := aisimage.o \
> lib/sha256.o \
> common/hash.o \
> ublimage.o \
> +   zynqimage.o \
> $(LIBFDT_OBJS) \
> $(RSA_OBJS-y)
>
> diff --git a/tools/zynqimage.c b/tools/zynqimage.c
> new file mode 100644
> index 000..6d417d1
> --- /dev/null
> +++ b/tools/zynqimage.c
> @@ -0,0 +1,259 @@
> +/*
> + * Copyright (C) 2015 Nathan Rossi 
> + *
> + * SPDX-License-Identifier:GPL-2.0+
> + *
> + * The following Boot Header format/structures and values are defined in the
> + * following documents:
> + *   * Xilinx Zynq-7000 Technical Reference Manual (Section 6.3)
> + *   * Xilinx Zynq-7000 Software Developers Guide (Appendix A.7 and A.8)
> + *
> + * Expected Header Size = 0x8C0
> + * Forced as 'little' endian, 32-bit words
> + *
> + *  0x  0 - Interrupt Table (8 words)
> + *  ... (Default value = 0xeafe)
> + *  0x 1f
> + *  0x 20 - Width Detection
> + * * DEFAULT_WIDTHDETECTION0xaa995566
> + *  0x 24 - Image Identifier
> + * * DEFAULT_IMAGEIDENTIFIER   0x584c4e58
> + *  0x 28 - Encryption
> + * * 0x - None
> + * * 0xa5c3c5a3 - eFuse
> + * * 0x3a5c3c5a - bbRam
> + *  0x 2C - User Field
> + *  0x 30 - Image Offset
> + *  0x 34 - Image Size
> + *  0x 38 - Reserved (0x) (according to spec)
> + *  * FSBL defines this field for Image Destination Address.
> + *  0x 3C - Image Load
> + *  0x 40 - Image Stored Size
> + *  0x 44 - Reserved (0x) (according to spec)
> + *  * FSBL defines this field for QSPI configuration Data.
> + *  0x 48 - Checksum
> + *  0x 4c - Unused (21 words)
> + *  ...
> + *  0x 9c
> + *  0x a0 - Register Initialization, 256 Address and Data word pairs
> + * * List is terminated with an address of 0x or
> + *  ...* at the max number of entries
> + *  0x89c
> + *  0x8a0 - Unused (8 words)
> + *  ...
> + *  0x8bf
> + *  0x8c0 - Data/Image starts here or above
> + */
> +
> +#include "imagetool.h"
> +#include "mkimage.h"
> +#include 
> +
> +#define HEADER_INTERRUPT_DEFAULT (cpu_to_le32(0xeafe))
> +#define HEADER_REGINIT_NULL (cpu_to_le32(0x))
> +#define HEADER_WIDTHDETECTION (cpu_to_le32(0xaa995566))
> +#define HEADER_IMAGEIDENTIFIER (cpu_to_le32(0x584c4e58))
> +
> +enum {
> +   ENCRYPTION_EFUSE = 0xa5c3c5a3,
> +   ENCRYPTION_BBRAM = 0x3a5c3c5a,
> +   ENCRYPTION_NONE = 0x0,
> +};
> +
> +struct zynq_reginit 

[U-Boot] [PATCH 0/2] Add Xilinx Zynq boot.bin support

[Nathan Rossi]

This patch series adds support for the 'zynqimage' type to mkimage for
the Xilinx Zynq platform. As well as adding make targets to generate
the boot.bin image file containing SPL by default.

Nathan Rossi (2):
  tools: zynqimage: Add Xilinx Zynq boot header generation to mkimage
  ARM: zynq: Add target for building bootable SPL image for Zynq

 Makefile |   3 +
 common/image.c   |   1 +
 include/image.h  |   3 +-
 scripts/Makefile.spl |  11 +++
 tools/Makefile   |   1 +
 tools/zynqimage.c| 259 +++
 6 files changed, 277 insertions(+), 1 deletion(-)
 create mode 100644 tools/zynqimage.c

-- 
2.6.2

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

[U-Boot] [PATCH 1/2] tools: zynqimage: Add Xilinx Zynq boot header generation to mkimage

[Nathan Rossi]

As with other platforms vendors love to create their own boot header
formats. Xilinx is no different and for the Zynq platform/SoC there
exists the "boot.bin" which is read by the platforms bootrom. This
format is described to a useful extent within the Xilinx Zynq TRM.

This implementation adds support for the 'zynqimage' to mkimage. The
implementation only considers the most common boot header which is
un-encrypted and packed directly after the boot header itself (no
XIP, etc.). However this implementation does take into consideration the
other fields of the header for image dumping use cases (vector table and
register initialization).

Signed-off-by: Nathan Rossi 
Cc: Michal Simek 
Cc: Tom Rini 
---
 common/image.c|   1 +
 include/image.h   |   3 +-
 tools/Makefile|   1 +
 tools/zynqimage.c | 259 ++
 4 files changed, 263 insertions(+), 1 deletion(-)
 create mode 100644 tools/zynqimage.c

diff --git a/common/image.c b/common/image.c
index 85c4f39..c36927f 100644
--- a/common/image.c
+++ b/common/image.c
@@ -158,6 +158,7 @@ static const table_entry_t uimage_type[] = {
{   IH_TYPE_RKIMAGE,"rkimage","Rockchip Boot Image" },
{   IH_TYPE_RKSD,   "rksd",   "Rockchip SD Boot Image" },
{   IH_TYPE_RKSPI,  "rkspi",  "Rockchip SPI Boot Image" },
+   {   IH_TYPE_ZYNQIMAGE,  "zynqimage",  "Xilinx Zynq Boot Image" },
{   -1, "",   "",   },
 };
 
diff --git a/include/image.h b/include/image.h
index 08ae24a..299d6d2 100644
--- a/include/image.h
+++ b/include/image.h
@@ -248,8 +248,9 @@ struct lmb;
 #define IH_TYPE_RKIMAGE23  /* Rockchip Boot Image  
*/
 #define IH_TYPE_RKSD   24  /* Rockchip SD card */
 #define IH_TYPE_RKSPI  25  /* Rockchip SPI image   */
+#define IH_TYPE_ZYNQIMAGE  26  /* Xilinx Zynq Boot Image */
 
-#define IH_TYPE_COUNT  26  /* Number of image types */
+#define IH_TYPE_COUNT  27  /* Number of image types */
 
 /*
  * Compression Types
diff --git a/tools/Makefile b/tools/Makefile
index 9082bda..9cfd80b 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -98,6 +98,7 @@ dumpimage-mkimage-objs := aisimage.o \
lib/sha256.o \
common/hash.o \
ublimage.o \
+   zynqimage.o \
$(LIBFDT_OBJS) \
$(RSA_OBJS-y)
 
diff --git a/tools/zynqimage.c b/tools/zynqimage.c
new file mode 100644
index 000..6d417d1
--- /dev/null
+++ b/tools/zynqimage.c
@@ -0,0 +1,259 @@
+/*
+ * Copyright (C) 2015 Nathan Rossi 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ *
+ * The following Boot Header format/structures and values are defined in the
+ * following documents:
+ *   * Xilinx Zynq-7000 Technical Reference Manual (Section 6.3)
+ *   * Xilinx Zynq-7000 Software Developers Guide (Appendix A.7 and A.8)
+ *
+ * Expected Header Size = 0x8C0
+ * Forced as 'little' endian, 32-bit words
+ *
+ *  0x  0 - Interrupt Table (8 words)
+ *  ... (Default value = 0xeafe)
+ *  0x 1f
+ *  0x 20 - Width Detection
+ * * DEFAULT_WIDTHDETECTION0xaa995566
+ *  0x 24 - Image Identifier
+ * * DEFAULT_IMAGEIDENTIFIER   0x584c4e58
+ *  0x 28 - Encryption
+ * * 0x - None
+ * * 0xa5c3c5a3 - eFuse
+ * * 0x3a5c3c5a - bbRam
+ *  0x 2C - User Field
+ *  0x 30 - Image Offset
+ *  0x 34 - Image Size
+ *  0x 38 - Reserved (0x) (according to spec)
+ *  * FSBL defines this field for Image Destination Address.
+ *  0x 3C - Image Load
+ *  0x 40 - Image Stored Size
+ *  0x 44 - Reserved (0x) (according to spec)
+ *  * FSBL defines this field for QSPI configuration Data.
+ *  0x 48 - Checksum
+ *  0x 4c - Unused (21 words)
+ *  ...
+ *  0x 9c
+ *  0x a0 - Register Initialization, 256 Address and Data word pairs
+ * * List is terminated with an address of 0x or
+ *  ...* at the max number of entries
+ *  0x89c
+ *  0x8a0 - Unused (8 words)
+ *  ...
+ *  0x8bf
+ *  0x8c0 - Data/Image starts here or above
+ */
+
+#include "imagetool.h"
+#include "mkimage.h"
+#include 
+
+#define HEADER_INTERRUPT_DEFAULT (cpu_to_le32(0xeafe))
+#define HEADER_REGINIT_NULL (cpu_to_le32(0x))
+#define HEADER_WIDTHDETECTION (cpu_to_le32(0xaa995566))
+#define HEADER_IMAGEIDENTIFIER (cpu_to_le32(0x584c4e58))
+
+enum {
+   ENCRYPTION_EFUSE = 0xa5c3c5a3,
+   ENCRYPTION_BBRAM = 0x3a5c3c5a,
+   ENCRYPTION_NONE = 0x0,
+};
+
+struct zynq_reginit {
+   uint32_t address;
+   uint32_t data;
+};
+
+#define HEADER_INTERRUPT_VECTORS 8
+#define HEADER_REGINITS 256
+
+struct zynq_header {
+   uint32_t interrupt_vectors[HEADER_INTERRUPT_VECTORS]; /* 0x0 */
+   uint32_t width_detection; /* 0x20 */
+   uint32_t image_identifier; /* 0x24 */
+

[U-Boot] [PATCH 2/2] ARM: zynq: Add target for building bootable SPL image for Zynq

[Nathan Rossi]

Add a build target to generate 'boot.bin' which includes SPL. This is
used by the platforms BootROM to load SPL directly.

This change also conditionally changes what the 'boot.bin' target
generates depending on the SoC. Leaving the behaviour unchanged for the
AT91 targets.

Signed-off-by: Nathan Rossi 
Signed-off-by: Michal Simek 
Cc: Tom Rini 
Cc: Andreas Bießmann 
Cc: Heiko Schocher 
---
 Makefile |  3 +++
 scripts/Makefile.spl | 11 +++
 2 files changed, 14 insertions(+)

diff --git a/Makefile b/Makefile
index 61050ad..b7da462 100644
--- a/Makefile
+++ b/Makefile
@@ -1335,6 +1335,9 @@ spl/sunxi-spl.bin: spl/u-boot-spl
 spl/u-boot-spl-dtb.sfp: spl/u-boot-spl
@:
 
+spl/boot.bin: spl/u-boot-spl
+   @:
+
 tpl/u-boot-tpl.bin: tools prepare
$(Q)$(MAKE) obj=tpl -f $(srctree)/scripts/Makefile.spl all
 
diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl
index dd235b9..b0d8551 100644
--- a/scripts/Makefile.spl
+++ b/scripts/Makefile.spl
@@ -116,6 +116,7 @@ MKIMAGEFLAGS_MLO.byteswap = -T omapimage -n byteswap -a 
$(CONFIG_SPL_TEXT_BASE)
 MLO MLO.byteswap: $(obj)/u-boot-spl.bin
$(call if_changed,mkimage)
 
+ifeq ($(CONFIG_SYS_SOC),"at91")
 MKIMAGEFLAGS_boot.bin = -T atmelimage
 
 ifeq ($(CONFIG_SPL_GENERATE_ATMEL_PMECC_HEADER),y)
@@ -126,6 +127,12 @@ endif
 
 boot.bin: $(obj)/u-boot-spl.bin
$(call if_changed,mkimage)
+else
+MKIMAGEFLAGS_boot.bin = -T zynqimage
+
+spl/boot.bin: $(obj)/u-boot-spl-dtb.bin
+   $(call if_changed,mkimage)
+endif
 
 ALL-y  += $(obj)/$(SPL_BIN).bin $(obj)/$(SPL_BIN).cfg
 
@@ -149,6 +156,10 @@ ifeq ($(CONFIG_SYS_SOC),"at91")
 ALL-y  += boot.bin
 endif
 
+ifdef CONFIG_ARCH_ZYNQ
+ALL-y  += $(obj)/boot.bin
+endif
+
 all:   $(ALL-y)
 
 quiet_cmd_cat = CAT $@
-- 
2.6.2

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

Re: [U-Boot] [PATCH] arm: novena: Switch novena to config_distro_bootcmd

[Vagrant Cascadian]

On 2015-11-10, Marek Vasut wrote:
> Switch Novena to distro bootcmd, so it can be used with debian easily.
...
> diff --git a/include/configs/novena.h b/include/configs/novena.h
> index 718989f..b0f4c02 100644
> --- a/include/configs/novena.h
> +++ b/include/configs/novena.h
> @@ -199,6 +201,11 @@
>   "rootdev=/dev/mmcblk0p2\0"  \
>   "netdev=eth0\0" \
>   "kernel_addr_r="__stringify(CONFIG_LOADADDR)"\0"\
> + "kernel_addr_r="__stringify(CONFIG_LOADADDR)"\0"\
> + "pxefile_addr_r="__stringify(CONFIG_LOADADDR)"\0"   \
> + "scriptaddr="__stringify(CONFIG_LOADADDR)"\0"   \
> + "ramdisk_addr_r=0x2800\0"   \
> + "fdt_addr_r=0x1000\0"   \
>   "addcons="  \
>   "setenv bootargs ${bootargs} "  \
>   "console=${consdev},${baudrate}\0"  \

kernel_addr_r only needs to be set once. :)

Thanks for submitting!

live well,
  vagrant


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

[U-Boot] [RFC PATCH v1 0/2] Make most DDR non-secure in MMU while keep a small block secure

[York Sun]

This set is to change MMU tables so DDR is in non-secure mode that
non-secure master such as SDHC DMA can access the data. To mix
secure and non-secure MMU entries, the MMU tables themselves have
to be in secure memory. A small portion memory is reserved at the
end of DDR (before debug server and MC) to host secure application
and the MMU tables.

Changes in v1:
  Initial patch.
  Depends on http://patchwork.ozlabs.org/patch/540248/

York Sun (2):
  armv8: fsl-layerscape: Reserve memory for PPA
  armv8: fsl-layerscape: Make DDR non secure in MMU tables

 README|   14 +-
 arch/arm/cpu/armv8/fsl-layerscape/cpu.c   |  149 +++--
 arch/arm/include/asm/arch-fsl-layerscape/config.h |3 +
 arch/arm/include/asm/arch-fsl-layerscape/cpu.h|   12 +-
 arch/arm/include/asm/global_data.h|3 +
 board/freescale/ls2085a/ddr.c |   10 ++
 board/freescale/ls2085a/ls2085a.c |   17 ---
 board/freescale/ls2085aqds/ddr.c  |   10 ++
 board/freescale/ls2085aqds/ls2085aqds.c   |   17 ---
 board/freescale/ls2085ardb/ddr.c  |   10 ++
 board/freescale/ls2085ardb/ls2085ardb.c   |   17 ---
 common/cmd_bdinfo.c   |4 +
 include/configs/ls2085a_common.h  |4 +-
 13 files changed, 201 insertions(+), 69 deletions(-)

-- 
1.7.9.5

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

[U-Boot] [Patch V4 7/7] armv8/ls1043ardb: add USB support

[Gong Qianyu]

Add support for the third USB controller for LS1043A.

Signed-off-by: Gong Qianyu 
---
V4:
 - No change.
V3:
 - New Patch. Tested on LS1043ARDB board.

 arch/arm/include/asm/arch-fsl-layerscape/immap_lsch2.h |  6 +++---
 board/freescale/ls1043ardb/ls1043ardb.c| 16 
 include/configs/ls1043ardb.h   | 13 +
 include/linux/usb/xhci-fsl.h   |  9 -
 4 files changed, 40 insertions(+), 4 deletions(-)

diff --git a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch2.h 
b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch2.h
index f52815d..83caa91 100644
--- a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch2.h
+++ b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch2.h
@@ -30,9 +30,9 @@
 #define CONFIG_SYS_NS16550_COM2(CONFIG_SYS_IMMR + 
0x011c0600)
 #define CONFIG_SYS_NS16550_COM3(CONFIG_SYS_IMMR + 
0x011d0500)
 #define CONFIG_SYS_NS16550_COM4(CONFIG_SYS_IMMR + 
0x011d0600)
-#define CONFIG_SYS_FSL_XHCI_USB1_ADDR  (CONFIG_SYS_IMMR + 0x01f0)
-#define CONFIG_SYS_FSL_XHCI_USB2_ADDR  (CONFIG_SYS_IMMR + 0x0200)
-#define CONFIG_SYS_FSL_XHCI_USB3_ADDR  (CONFIG_SYS_IMMR + 0x0210)
+#define CONFIG_SYS_LS1043A_XHCI_USB1_ADDR  (CONFIG_SYS_IMMR + 0x01f0)
+#define CONFIG_SYS_LS1043A_XHCI_USB2_ADDR  (CONFIG_SYS_IMMR + 0x0200)
+#define CONFIG_SYS_LS1043A_XHCI_USB3_ADDR  (CONFIG_SYS_IMMR + 0x0210)
 #define CONFIG_SYS_PCIE1_ADDR  (CONFIG_SYS_IMMR + 0x240)
 #define CONFIG_SYS_PCIE2_ADDR  (CONFIG_SYS_IMMR + 0x250)
 #define CONFIG_SYS_PCIE3_ADDR  (CONFIG_SYS_IMMR + 0x260)
diff --git a/board/freescale/ls1043ardb/ls1043ardb.c 
b/board/freescale/ls1043ardb/ls1043ardb.c
index 9032ed3..cdd50d6 100644
--- a/board/freescale/ls1043ardb/ls1043ardb.c
+++ b/board/freescale/ls1043ardb/ls1043ardb.c
@@ -69,7 +69,23 @@ int dram_init(void)
 
 int board_early_init_f(void)
 {
+   struct ccsr_scfg *scfg = (struct ccsr_scfg *)CONFIG_SYS_FSL_SCFG_ADDR;
+   u32 usb_pwrfault;
+
fsl_lsch2_early_init_f();
+
+#ifdef CONFIG_HAS_FSL_XHCI_USB
+   out_be32(&scfg->rcwpmuxcr0, 0x);
+   out_be32(&scfg->usbdrvvbus_selcr, SCFG_USBDRVVBUS_SELCR_USB1);
+   usb_pwrfault = (SCFG_USBPWRFAULT_DEDICATED <<
+   SCFG_USBPWRFAULT_USB3_SHIFT) |
+   (SCFG_USBPWRFAULT_DEDICATED <<
+   SCFG_USBPWRFAULT_USB2_SHIFT) |
+   (SCFG_USBPWRFAULT_SHARED <<
+SCFG_USBPWRFAULT_USB1_SHIFT);
+   out_be32(&scfg->usbpwrfault_selcr, usb_pwrfault);
+#endif
+
return 0;
 }
 
diff --git a/include/configs/ls1043ardb.h b/include/configs/ls1043ardb.h
index 3fa9b3b..7d113a0 100644
--- a/include/configs/ls1043ardb.h
+++ b/include/configs/ls1043ardb.h
@@ -278,4 +278,17 @@
 #define CONFIG_ETHPRIME"FM1@DTSEC3"
 #endif
 
+/* USB */
+#define CONFIG_HAS_FSL_XHCI_USB
+#ifdef CONFIG_HAS_FSL_XHCI_USB
+#define CONFIG_USB_XHCI
+#define CONFIG_USB_XHCI_FSL
+#define CONFIG_USB_XHCI_DWC3
+#define CONFIG_USB_MAX_CONTROLLER_COUNT3
+#define CONFIG_SYS_USB_XHCI_MAX_ROOT_PORTS 2
+#define CONFIG_CMD_USB
+#define CONFIG_USB_STORAGE
+#define CONFIG_CMD_EXT2
+#endif
+
 #endif /* __LS1043ARDB_H__ */
diff --git a/include/linux/usb/xhci-fsl.h b/include/linux/usb/xhci-fsl.h
index 602a413..b0ff129 100644
--- a/include/linux/usb/xhci-fsl.h
+++ b/include/linux/usb/xhci-fsl.h
@@ -54,11 +54,18 @@ struct fsl_xhci {
 #if defined(CONFIG_LS102XA)
 #define CONFIG_SYS_FSL_XHCI_USB1_ADDR CONFIG_SYS_LS102XA_XHCI_USB1_ADDR
 #define CONFIG_SYS_FSL_XHCI_USB2_ADDR 0
+#define CONFIG_SYS_FSL_XHCI_USB3_ADDR 0
 #elif defined(CONFIG_LS2085A)
 #define CONFIG_SYS_FSL_XHCI_USB1_ADDR CONFIG_SYS_LS2085A_XHCI_USB1_ADDR
 #define CONFIG_SYS_FSL_XHCI_USB2_ADDR CONFIG_SYS_LS2085A_XHCI_USB2_ADDR
+#define CONFIG_SYS_FSL_XHCI_USB3_ADDR 0
+#elif defined(CONFIG_LS1043A)
+#define CONFIG_SYS_FSL_XHCI_USB1_ADDR CONFIG_SYS_LS1043A_XHCI_USB1_ADDR
+#define CONFIG_SYS_FSL_XHCI_USB2_ADDR CONFIG_SYS_LS1043A_XHCI_USB2_ADDR
+#define CONFIG_SYS_FSL_XHCI_USB3_ADDR CONFIG_SYS_LS1043A_XHCI_USB3_ADDR
 #endif
 
 #define FSL_USB_XHCI_ADDR  {CONFIG_SYS_FSL_XHCI_USB1_ADDR, \
-   CONFIG_SYS_FSL_XHCI_USB2_ADDR}
+   CONFIG_SYS_FSL_XHCI_USB2_ADDR, \
+   CONFIG_SYS_FSL_XHCI_USB3_ADDR}
 #endif /* _ASM_ARCH_XHCI_FSL_H_ */
-- 
2.1.0.27.g96db324

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

[U-Boot] [Patch V4 3/7] armv8/ls1043ardb: dts: add dtb support

[Gong Qianyu]

Reuse dts files from ls1043a linux kernel. Some parts in dts files
may not be needed by U-Boot.

Signed-off-by: Gong Qianyu 
---
V4:
 - No change.
V3:
 - Modified the dts file according to ls1043a upstreaming linux kernel.
V2:
 - New Patch.

 arch/arm/dts/Makefile|   1 +
 arch/arm/dts/fsl-ls1043a-rdb.dts |  84 
 arch/arm/dts/fsl-ls1043a.dtsi| 160 +++
 configs/ls1043ardb_defconfig |   2 +
 4 files changed, 247 insertions(+)

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 9542fff..7e12f01 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -89,6 +89,7 @@ dtb-$(CONFIG_LS102XA) += ls1021a-qds.dtb \
ls1021a-twr.dtb
 dtb-$(CONFIG_FSL_LSCH3) += fsl-ls2085a-qds.dtb \
fsl-ls2085a-rdb.dtb
+dtb-$(CONFIG_FSL_LSCH2) += fsl-ls1043a-rdb.dtb
 
 dtb-$(CONFIG_MACH_SUN4I) += \
sun4i-a10-a1000.dtb \
diff --git a/arch/arm/dts/fsl-ls1043a-rdb.dts b/arch/arm/dts/fsl-ls1043a-rdb.dts
new file mode 100644
index 000..17a0681
--- /dev/null
+++ b/arch/arm/dts/fsl-ls1043a-rdb.dts
@@ -0,0 +1,84 @@
+/*
+ * Device Tree Include file for Freescale Layerscape-1043A family SoC.
+ *
+ * Copyright (C) 2015, Freescale Semiconductor
+ *
+ * Mingkai Hu 
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+/dts-v1/;
+/include/ "fsl-ls1043a.dtsi"
+
+/ {
+   model = "LS1043A RDB Board";
+};
+
+&i2c0 {
+   status = "okay";
+   ina220@40 {
+   compatible = "ti,ina220";
+   reg = <0x40>;
+   shunt-resistor = <1000>;
+   };
+   adt7461a@4c {
+   compatible = "adi,adt7461a";
+   reg = <0x4c>;
+   };
+   eeprom@56 {
+   compatible = "at24,24c512";
+   reg = <0x52>;
+   };
+
+   eeprom@57 {
+   compatible = "at24,24c512";
+   reg = <0x53>;
+   };
+
+   rtc@68 {
+   compatible = "pericom,pt7c4338";
+   reg = <0x68>;
+   };
+};
+
+&ifc {
+   status = "okay";
+   #address-cells = <2>;
+   #size-cells = <1>;
+   /* NOR, NAND Flashes and FPGA on board */
+   ranges = <0x0 0x0 0x0 0x6000 0x0800
+ 0x2 0x0 0x0 0x7e80 0x0001
+ 0x3 0x0 0x0 0x7fb0 0x0100>;
+
+   nor@0,0 {
+   compatible = "cfi-flash";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   reg = <0x0 0x0 0x800>;
+   bank-width = <2>;
+   device-width = <1>;
+   };
+
+   nand@1,0 {
+   compatible = "fsl,ifc-nand";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   reg = <0x1 0x0 0x1>;
+   };
+
+   cpld: board-control@2,0 {
+   compatible = "fsl,ls1043ardb-cpld";
+   reg = <0x2 0x0 0x100>;
+   };
+};
+
+&duart0 {
+   status = "okay";
+};
+
+&duart1 {
+   status = "okay";
+};
diff --git a/arch/arm/dts/fsl-ls1043a.dtsi b/arch/arm/dts/fsl-ls1043a.dtsi
new file mode 100644
index 000..280e959
--- /dev/null
+++ b/arch/arm/dts/fsl-ls1043a.dtsi
@@ -0,0 +1,160 @@
+/*
+ * Device Tree Include file for Freescale Layerscape-1043A family SoC.
+ *
+ * Copyright (C) 2014-2015, Freescale Semiconductor
+ *
+ * Mingkai Hu 
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+/include/ "skeleton64.dtsi"
+
+/ {
+   compatible = "fsl,ls1043a";
+   interrupt-parent = <&gic>;
+   cpus {
+   #address-cells = <2>;
+   #size-cells = <0>;
+
+   cpu0: cpu@0 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53";
+   reg = <0x0 0x0>;
+   clocks = <&clockgen 1 0>;
+   };
+
+   cpu1: cpu@1 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53";
+   reg = <0x0 0x1>;
+   clocks = <&clockgen 1 0>;
+   };
+
+   cpu2: cpu@2 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53";
+   reg = <0x0 0x2>;
+   clocks = <&clockgen 1 0>;
+   };
+
+   cpu3: cpu@3 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53";
+   reg = <0x0 0x3>;
+   clocks = <&clockgen 1 0>;
+   };

[U-Boot] [Patch V4 4/7] armv8/ls1043aqds: add LS1043AQDS board support

[Gong Qianyu]

From: Shaohui Xie 

LS1043AQDS Specification:
-
Memory subsystem:
 * 2GByte DDR4 DIMM
 * 128 Mbyte NOR flash single-chip memory
 * 512 Mbyte NAND flash
 * 16 Mbyte high-speed SPI flash
 * SD connector to interface with the SD memory card

Ethernet:
 * Two RGMII ports
 * XFI 10G port
 * SGMII
 * QSGMII with 4x 1G ports

PCIe: supports Gen 1 and Gen 2

SATA 3.0: one SATA 3.0 port

USB 3.0: two micro AB connector and one type A connector

UART: supports two UARTs up to 115200 bps for console

Signed-off-by: Shaohui Xie 
Signed-off-by: Mingkai Hu 
Signed-off-by: Hou Zhiqiang 
Signed-off-by: Gong Qianyu 
---
V4:
 - Fix vid macros in config file and add vid support.
 - Remove RAW_TIMING definition for DDR3.
 - Remove LS1043AQDS_MDIO_10GC related code because LS1043AQDS has no phy for 
it.
V3:
 - Update the commit message.
 - Remove #ifdef in fdt.h.
 - Rename ls1043aqds_sdcard_defconfig to ls1043aqds_sdcard_ifc_defconfig.
V2:
 - No change.

 arch/arm/Kconfig   |   9 +
 arch/arm/include/asm/arch-fsl-layerscape/fdt.h |   1 +
 board/freescale/common/vid.c   |  22 +
 board/freescale/ls1043aqds/Kconfig |  15 +
 board/freescale/ls1043aqds/MAINTAINERS |   9 +
 board/freescale/ls1043aqds/Makefile|   9 +
 board/freescale/ls1043aqds/README  |  96 
 board/freescale/ls1043aqds/ddr.c   | 131 ++
 board/freescale/ls1043aqds/ddr.h   |  60 +++
 board/freescale/ls1043aqds/eth.c   | 492 +
 board/freescale/ls1043aqds/ls1043aqds.c| 333 ++
 board/freescale/ls1043aqds/ls1043aqds_pbi.cfg  |  14 +
 board/freescale/ls1043aqds/ls1043aqds_qixis.h  |  39 ++
 board/freescale/ls1043aqds/ls1043aqds_rcw_nand.cfg |   7 +
 .../freescale/ls1043aqds/ls1043aqds_rcw_sd_ifc.cfg |   8 +
 configs/ls1043aqds_defconfig   |   3 +
 configs/ls1043aqds_nand_defconfig  |   4 +
 configs/ls1043aqds_nor_ddr3_defconfig  |   2 +
 configs/ls1043aqds_sdcard_ifc_defconfig|   4 +
 include/configs/ls1043aqds.h   | 387 
 20 files changed, 1645 insertions(+)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 0d756cb..267dd2a 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -634,6 +634,14 @@ config TARGET_LS1021ATWR
select CPU_V7
select SUPPORT_SPL
 
+config TARGET_LS1043AQDS
+   bool "Support ls1043aqds"
+   select ARM64
+   select ARMV8_MULTIENTRY
+   select SUPPORT_SPL
+   help
+ Support for Freescale LS1043AQDS platform.
+
 config TARGET_LS1043ARDB
bool "Support ls1043ardb"
select ARM64
@@ -758,6 +766,7 @@ source "board/freescale/ls2085aqds/Kconfig"
 source "board/freescale/ls2085ardb/Kconfig"
 source "board/freescale/ls1021aqds/Kconfig"
 source "board/freescale/ls1021atwr/Kconfig"
+source "board/freescale/ls1043aqds/Kconfig"
 source "board/freescale/ls1043ardb/Kconfig"
 source "board/freescale/mx23evk/Kconfig"
 source "board/freescale/mx25pdk/Kconfig"
diff --git a/arch/arm/include/asm/arch-fsl-layerscape/fdt.h 
b/arch/arm/include/asm/arch-fsl-layerscape/fdt.h
index 4da73ab..099563e 100644
--- a/arch/arm/include/asm/arch-fsl-layerscape/fdt.h
+++ b/arch/arm/include/asm/arch-fsl-layerscape/fdt.h
@@ -11,4 +11,5 @@ void alloc_stream_ids(int start_id, int count, u32 
*stream_ids, int max_cnt);
 void append_mmu_masters(void *blob, const char *smmu_path,
const char *master_name, u32 *stream_ids, int count);
 void fdt_fixup_smmu_pcie(void *blob);
+void fdt_fixup_board_enet(void *fdt);
 #endif /* _ASM_ARMV8_FSL_LAYERSCAPE_FDT_H_ */
diff --git a/board/freescale/common/vid.c b/board/freescale/common/vid.c
index 6b8af14..f1bed51 100644
--- a/board/freescale/common/vid.c
+++ b/board/freescale/common/vid.c
@@ -7,7 +7,12 @@
 #include 
 #include 
 #include 
+#include 
+#ifdef CONFIG_LS1043A
+#include 
+#else
 #include 
+#endif
 #include "vid.h"
 
 DECLARE_GLOBAL_DATA_PTR;
@@ -240,7 +245,11 @@ static int set_voltage_to_IR(int i2caddress, int vdd)
 * SoC before converting into an IR VID value
 */
vdd += board_vdd_drop_compensation();
+#ifdef CONFIG_LS1043A
+   vid = DIV_ROUND_UP(vdd - 265, 5);
+#else
vid = DIV_ROUND_UP(vdd - 245, 5);
+#endif
 
ret = i2c_write(i2caddress, IR36021_LOOP1_MANUAL_ID_OFFSET,
1, (void *)&vid, sizeof(vid));
@@ -276,8 +285,12 @@ static int set_voltage(int i2caddress, int vdd)
 int adjust_vdd(ulong vdd_override)
 {
int re_enable = disable_interrupts();
+#ifdef CONFIG_LS1043A
+   struct ccsr_gur *gur = (void *)(CONFIG_SYS_FSL_GUTS_ADDR);
+#else
ccsr_gur_t __iomem *gur =
(void __iomem *)(CONFIG_SYS_MPC85xx_GUTS_ADDR);
+#endif
u32 fusesr;
u8 vid;
int vdd_target, vdd_current, vdd_last;
@@ -352,12 +365,21 @@ int

[U-Boot] [Patch V4 6/7] armv8/ls1043ardb: add DSPI support

[Gong Qianyu]

Use the U-Boot Driver Model. Just enable Freescale DSPI driver
and set DSPI related parameters in dts file.

Signed-off-by: Gong Qianyu 
---
V4:
 - No change.
V3:
 - New Patch.
 - Tested on LS1043ARDB board.

 arch/arm/dts/fsl-ls1043a-rdb.dts| 19 +++
 arch/arm/dts/fsl-ls1043a.dtsi   | 26 ++
 configs/ls1043ardb_defconfig|  3 +++
 configs/ls1043ardb_nand_defconfig   |  5 +
 configs/ls1043ardb_sdcard_defconfig |  5 +
 include/configs/ls1043ardb.h| 10 ++
 6 files changed, 68 insertions(+)

diff --git a/arch/arm/dts/fsl-ls1043a-rdb.dts b/arch/arm/dts/fsl-ls1043a-rdb.dts
index 17a0681..16c5c89 100644
--- a/arch/arm/dts/fsl-ls1043a-rdb.dts
+++ b/arch/arm/dts/fsl-ls1043a-rdb.dts
@@ -15,6 +15,25 @@
 
 / {
model = "LS1043A RDB Board";
+
+aliases {
+   spi1 = &dspi0;
+};
+
+};
+
+&dspi0 {
+   bus-num = <0>;
+   status = "okay";
+
+   dspiflash: n25q12a {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "spi-flash";
+   reg = <0>;
+   spi-max-frequency = <100>; /* input clock */
+   };
+
 };
 
 &i2c0 {
diff --git a/arch/arm/dts/fsl-ls1043a.dtsi b/arch/arm/dts/fsl-ls1043a.dtsi
index 280e959..85ea81e 100644
--- a/arch/arm/dts/fsl-ls1043a.dtsi
+++ b/arch/arm/dts/fsl-ls1043a.dtsi
@@ -79,6 +79,32 @@
clocks = <&sysclk>;
};
 
+   dspi0: dspi@210 {
+   compatible = "fsl,vf610-dspi";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0x0 0x210 0x0 0x1>;
+   interrupts = <0 64 0x4>;
+   clock-names = "dspi";
+   clocks = <&clockgen 4 0>;
+   num-cs = <6>;
+   big-endian;
+   status = "disabled";
+   };
+
+   dspi1: dspi@211 {
+   compatible = "fsl,vf610-dspi";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0x0 0x211 0x0 0x1>;
+   interrupts = <0 65 0x4>;
+   clock-names = "dspi";
+   clocks = <&clockgen 4 0>;
+   num-cs = <6>;
+   big-endian;
+   status = "disabled";
+   };
+
ifc: ifc@153 {
compatible = "fsl,ifc", "simple-bus";
reg = <0x0 0x153 0x0 0x1>;
diff --git a/configs/ls1043ardb_defconfig b/configs/ls1043ardb_defconfig
index f77fbbf..0102e0d 100644
--- a/configs/ls1043ardb_defconfig
+++ b/configs/ls1043ardb_defconfig
@@ -4,3 +4,6 @@ CONFIG_TARGET_LS1043ARDB=y
 CONFIG_FSL_LAYERSCAPE=y
 CONFIG_DEFAULT_DEVICE_TREE="fsl-ls1043a-rdb"
 CONFIG_OF_CONTROL=y
+CONFIG_DM=y
+CONFIG_SPI_FLASH=y
+CONFIG_DM_SPI=y
diff --git a/configs/ls1043ardb_nand_defconfig 
b/configs/ls1043ardb_nand_defconfig
index fffaca0..661cbc2 100644
--- a/configs/ls1043ardb_nand_defconfig
+++ b/configs/ls1043ardb_nand_defconfig
@@ -2,3 +2,8 @@ CONFIG_SPL=y
 CONFIG_SYS_EXTRA_OPTIONS="RAMBOOT_PBL,SPL_FSL_PBL,NAND_BOOT,SYS_FSL_DDR4"
 CONFIG_ARM=y
 CONFIG_TARGET_LS1043ARDB=y
+CONFIG_DEFAULT_DEVICE_TREE="fsl-ls1043a-rdb"
+CONFIG_OF_CONTROL=y
+CONFIG_DM=y
+CONFIG_SPI_FLASH=y
+CONFIG_DM_SPI=y
diff --git a/configs/ls1043ardb_sdcard_defconfig 
b/configs/ls1043ardb_sdcard_defconfig
index 5fe0470..b53dd15 100644
--- a/configs/ls1043ardb_sdcard_defconfig
+++ b/configs/ls1043ardb_sdcard_defconfig
@@ -2,3 +2,8 @@ CONFIG_SPL=y
 CONFIG_SYS_EXTRA_OPTIONS="RAMBOOT_PBL,SPL_FSL_PBL,SD_BOOT,SYS_FSL_DDR4"
 CONFIG_ARM=y
 CONFIG_TARGET_LS1043ARDB=y
+CONFIG_DEFAULT_DEVICE_TREE="fsl-ls1043a-rdb"
+CONFIG_OF_CONTROL=y
+CONFIG_DM=y
+CONFIG_SPI_FLASH=y
+CONFIG_DM_SPI=y
diff --git a/include/configs/ls1043ardb.h b/include/configs/ls1043ardb.h
index 307d947..3fa9b3b 100644
--- a/include/configs/ls1043ardb.h
+++ b/include/configs/ls1043ardb.h
@@ -222,6 +222,16 @@
 #define CONFIG_SYS_EEPROM_PAGE_WRITE_BITS  3
 #define CONFIG_SYS_EEPROM_PAGE_WRITE_DELAY_MS  5
 
+/* DSPI */
+#define CONFIG_FSL_DSPI
+#ifdef CONFIG_FSL_DSPI
+#define CONFIG_CMD_SF
+#define CONFIG_DM_SPI_FLASH
+#define CONFIG_SPI_FLASH_STMICRO
+#define CONFIG_SF_DEFAULT_BUS  1
+#define CONFIG_SF_DEFAULT_CS   0
+#endif
+
 /*
  * Environment
  */
-- 
2.1.0.27.g96db324

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

[U-Boot] [Patch V4 5/7] armv8/ls1043aqds: dts: add dtb support

[Gong Qianyu]

Reuse the dts files from ls1043a linux kernel.

Signed-off-by: Gong Qianyu 
---
V4:
 - No change.
V3:
 - No change.
V2:
 - New Patch.

 arch/arm/dts/Makefile|   3 +-
 arch/arm/dts/fsl-ls1043a-qds.dts | 124 +++
 configs/ls1043aqds_defconfig |   2 +
 3 files changed, 128 insertions(+), 1 deletion(-)

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 7e12f01..88a500d 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -89,7 +89,8 @@ dtb-$(CONFIG_LS102XA) += ls1021a-qds.dtb \
ls1021a-twr.dtb
 dtb-$(CONFIG_FSL_LSCH3) += fsl-ls2085a-qds.dtb \
fsl-ls2085a-rdb.dtb
-dtb-$(CONFIG_FSL_LSCH2) += fsl-ls1043a-rdb.dtb
+dtb-$(CONFIG_FSL_LSCH2) += fsl-ls1043a-qds.dtb \
+   fsl-ls1043a-rdb.dtb
 
 dtb-$(CONFIG_MACH_SUN4I) += \
sun4i-a10-a1000.dtb \
diff --git a/arch/arm/dts/fsl-ls1043a-qds.dts b/arch/arm/dts/fsl-ls1043a-qds.dts
new file mode 100644
index 000..7435222
--- /dev/null
+++ b/arch/arm/dts/fsl-ls1043a-qds.dts
@@ -0,0 +1,124 @@
+/*
+ * Device Tree Include file for Freescale Layerscape-1043A family SoC.
+ *
+ * Copyright (C) 2015, Freescale Semiconductor
+ *
+ * Mingkai Hu 
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+/dts-v1/;
+/include/ "fsl-ls1043a.dtsi"
+
+/ {
+   model = "LS1043A QDS Board";
+};
+
+&i2c0 {
+   status = "okay";
+   pca9547@77 {
+   compatible = "philips,pca9547";
+   reg = <0x77>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   i2c@0 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0x0>;
+
+   rtc@68 {
+   compatible = "dallas,ds3232";
+   reg = <0x68>;
+   /* IRQ10_B */
+   interrupts = <0 150 0x4>;
+   };
+   };
+
+   i2c@2 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0x2>;
+
+   ina220@40 {
+   compatible = "ti,ina220";
+   reg = <0x40>;
+   shunt-resistor = <1000>;
+   };
+
+   ina220@41 {
+   compatible = "ti,ina220";
+   reg = <0x41>;
+   shunt-resistor = <1000>;
+   };
+   };
+
+   i2c@3 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0x3>;
+
+   eeprom@56 {
+   compatible = "at24,24c512";
+   reg = <0x56>;
+   };
+
+   eeprom@57 {
+   compatible = "at24,24c512";
+   reg = <0x57>;
+   };
+
+   adt7461a@4c {
+   compatible = "adt7461a";
+   reg = <0x4c>;
+   };
+   };
+   };
+};
+
+&ifc {
+   #address-cells = <2>;
+   #size-cells = <1>;
+   /* NOR, NAND Flashes and FPGA on board */
+   ranges = <0x0 0x0 0x0 0x6000 0x0800
+ 0x2 0x0 0x0 0x7e80 0x0001
+ 0x3 0x0 0x0 0x7fb0 0x0100>;
+   status = "okay";
+
+   nor@0,0 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "cfi-flash";
+   reg = <0x0 0x0 0x800>;
+   bank-width = <2>;
+   device-width = <1>;
+   };
+
+   nand@2,0 {
+   compatible = "fsl,ifc-nand";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   reg = <0x1 0x0 0x1>;
+   };
+
+   fpga: board-control@3,0 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "simple-bus";
+   reg = <0x3 0x0 0x100>;
+   bank-width = <1>;
+   device-width = <1>;
+   ranges = <0 3 0 0x100>;
+   };
+};
+
+&duart0 {
+   status = "okay";
+};
+
+&duart1 {
+   status = "okay";
+};
diff --git a/configs/ls1043aqds_defconfig b/configs/ls1043aqds_defconfig
index ee5bea2..cf163d6 100644
--- a/configs/ls1043aqds_defconfig
+++ b/configs/ls1043aqds_defconfig
@@ -1,3 +1,5 @@
 CONFIG_SYS_EXTRA_OPTIONS="SYS_FSL_DDR4"
 CONFIG_ARM=y
 CONFIG_TARGET_LS1043AQDS=y
+CONFIG_DEFAULT_DEVICE_TREE="fsl-ls1043a-qds"
+CONFIG_OF_CONTROL=y
-- 
2.1.0.27.g96db324

_

[U-Boot] [Patch V4 1/7] pci/layerscape: add support for LS1043A PCIe LUT register access

[Gong Qianyu]

From: Mingkai Hu 

The endian and base address of PEX LUT register region is different
between Chassis 2 and Chassis 3, so move the base address definition
to chassis specific header file and add pex_lut_* functions to access
LUT register.

Signed-off-by: Mingkai Hu 
Signed-off-by: Gong Qianyu 
---
V4:
 - Use #ifndef CONFIG_LS102XA instead of #ifdef CONFIG_FSL_LAYERSCAPE.
V3:
 - No change.
V2:
 - Fix compile errors for ls1021a.

 arch/arm/include/asm/arch-fsl-layerscape/config.h  |  2 ++
 arch/arm/include/asm/arch-fsl-layerscape/immap_lsch2.h |  4 
 arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h |  4 
 arch/arm/include/asm/arch-fsl-layerscape/soc.h |  8 
 drivers/pci/pcie_layerscape.c  | 14 +++---
 5 files changed, 25 insertions(+), 7 deletions(-)

diff --git a/arch/arm/include/asm/arch-fsl-layerscape/config.h 
b/arch/arm/include/asm/arch-fsl-layerscape/config.h
index 87bb937..fe361da 100644
--- a/arch/arm/include/asm/arch-fsl-layerscape/config.h
+++ b/arch/arm/include/asm/arch-fsl-layerscape/config.h
@@ -44,6 +44,7 @@
 #define CONFIG_SYS_FSL_CCSR_SCFG_LE
 #define CONFIG_SYS_FSL_ESDHC_LE
 #define CONFIG_SYS_FSL_IFC_LE
+#define CONFIG_SYS_FSL_PEX_LUT_LE
 
 #define CONFIG_SYS_MEMAC_LITTLE_ENDIAN
 
@@ -113,6 +114,7 @@
 #define CONFIG_SYS_FSL_WDOG_BE
 #define CONFIG_SYS_FSL_DSPI_BE
 #define CONFIG_SYS_FSL_QSPI_BE
+#define CONFIG_SYS_FSL_PEX_LUT_BE
 
 #define QE_MURAM_SIZE  0x6000UL
 #define MAX_QE_RISC1
diff --git a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch2.h 
b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch2.h
index d941437..f52815d 100644
--- a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch2.h
+++ b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch2.h
@@ -60,6 +60,10 @@
 #define CONFIG_SYS_PCIE1_PHYS_ADDR 0x40ULL
 #define CONFIG_SYS_PCIE2_PHYS_ADDR 0x48ULL
 #define CONFIG_SYS_PCIE3_PHYS_ADDR 0x50ULL
+/* LUT registers */
+#define PCIE_LUT_BASE  0x1
+#define PCIE_LUT_LCTRL00x7F8
+#define PCIE_LUT_DBG   0x7FC
 
 /* TZ Address Space Controller Definitions */
 #define TZASC1_BASE0x0110  /* as per CCSR map. */
diff --git a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h 
b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
index 6a70d44..e700af0 100644
--- a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
+++ b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
@@ -78,6 +78,10 @@
 #define CONFIG_SYS_PCIE2_PHYS_ADDR 0x12ULL
 #define CONFIG_SYS_PCIE3_PHYS_ADDR 0x14ULL
 #define CONFIG_SYS_PCIE4_PHYS_ADDR 0x16ULL
+/* LUT registers */
+#define PCIE_LUT_BASE  0x8
+#define PCIE_LUT_LCTRL00x7F8
+#define PCIE_LUT_DBG   0x7FC
 
 /* Device Configuration */
 #define DCFG_BASE  0x01e0
diff --git a/arch/arm/include/asm/arch-fsl-layerscape/soc.h 
b/arch/arm/include/asm/arch-fsl-layerscape/soc.h
index 5ed456e..8691906 100644
--- a/arch/arm/include/asm/arch-fsl-layerscape/soc.h
+++ b/arch/arm/include/asm/arch-fsl-layerscape/soc.h
@@ -23,6 +23,14 @@
 #define scfg_out32(a, v)   out_be32(a, v)
 #endif
 
+#ifdef CONFIG_SYS_FSL_PEX_LUT_LE
+#define pex_lut_in32(a)   in_le32(a)
+#define pex_lut_out32(a, v)   out_le32(a, v)
+#elif defined(CONFIG_SYS_FSL_PEX_LUT_BE)
+#define pex_lut_in32(a)   in_be32(a)
+#define pex_lut_out32(a, v)   out_be32(a, v)
+#endif
+
 struct cpu_type {
char name[15];
u32 soc_ver;
diff --git a/drivers/pci/pcie_layerscape.c b/drivers/pci/pcie_layerscape.c
index 4cee038..43e3dc4 100644
--- a/drivers/pci/pcie_layerscape.c
+++ b/drivers/pci/pcie_layerscape.c
@@ -11,8 +11,9 @@
 #include 
 #include 
 #include 
-#ifdef CONFIG_FSL_LAYERSCAPE
+#ifndef CONFIG_LS102XA
 #include 
+#include 
 #endif
 
 #ifndef CONFIG_SYS_PCI_MEMORY_BUS
@@ -57,11 +58,6 @@
 #define PCIE_ATU_FUNC(x)   (((x) & 0x7) << 16)
 #define PCIE_ATU_UPPER_TARGET  0x91C
 
-/* LUT registers */
-#define PCIE_LUT_BASE  0x8
-#define PCIE_LUT_LCTRL00x7F8
-#define PCIE_LUT_DBG   0x7FC
-
 #define PCIE_DBI_RO_WR_EN  0x8bc
 
 #define PCIE_LINK_CAP  0x7c
@@ -162,7 +158,7 @@ static int ls_pcie_link_state(struct ls_pcie *pcie)
 {
u32 state;
 
-   state = readl(pcie->dbi + PCIE_LUT_BASE + PCIE_LUT_DBG) &
+   state = pex_lut_in32(pcie->dbi + PCIE_LUT_BASE + PCIE_LUT_DBG) &
LTSSM_STATE_MASK;
if (state < LTSSM_PCIE_L0) {
debug("PCIe link error. LTSSM=0x%02x.\n", state);
@@ -466,16 +462,20 @@ static void ls_pcie_setup_ep(struct ls_pcie *pcie, struct 
ls_pcie_info *info)
 
for (pf = 0; pf < PCIE_PF_NUM; pf++) {
for (vf = 0; vf <= PCI