Re: [U-Boot] [PATCH v2 0/3] ARM: at91: save mmc environment in a FAT file instead of some sectors
On 1/19/2015 3:06 PM, Josh Wu wrote: I sent these patches days ago with other patches which refactor SAMA5 common configuration files, see URL: http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/203128/focus=203182 Since the patches which refactor SAMA5 common configuration files is rejected. So this time I only send the patches which only convert the mmc environment to FAT file. Sorry, I forgot to add following changes: Changes in v2: - refined commit messages - fix a compile error for at91sam9x5 mmc env file. Best Regards, Josh Wu Josh Wu (3): ARM: at91: sama5d3_xplained: save environment in a FAT file in MMC card ARM: at91: sama5d3xek: save enviroment as a FAT file in MMC card ARM: at91: at91sam9x5: save environment to a FAT file in MMC card include/configs/at91sam9x5ek.h | 11 ++- include/configs/sama5d3_xplained.h | 10 ++ include/configs/sama5d3xek.h | 10 ++ 3 files changed, 18 insertions(+), 13 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH] dm:spi:fsl_qspi add DM support
Hi Jagan,
On 1/19/2015 2:47 PM, Jagan Teki wrote:
Hi Peng,
On 17 January 2015 at 11:29, Peng Fan wrote:
Hi Simon ,Jagan
This patch is based on git://git.denx.de/u-boot-spi.git master branch,
since some fsl_qspi's new feature is still in this git repo and have
not been merged to mainline.
I saw Simon sent out a new patch that remove the per_child_auto_alloc_size
from the platforms' driver code and move it to spi uclass driver. In
this patch I do not remove it, since this is a RFC version, and Jagan's
spi git repo still has it. I can remove it in formal version if needed.
Please take your time to review and comment this patch.
Appreciate for your work on adding dm on fsl-qspi.
But, I'm sending v2 RFC for spi-nor stuff where your driver be part of that
instead of drivers/spi - I'm planning to send it in this MW.
ok.
My plan is we review this dm stuff but in anyway if the new spi-nor is been
merged you'r driver needs to move on spi-nor with relevant changes.
Comments?
ok. I can do some work to make the driver match the new spi-nor stuff.
If you have anytime, you can review the dm stuff.
There are small issues about register configuration in this patch, and I
am fixing it in my side. Anyway, I'll wait your v2 patch, and based on
your spi-nor stuff to add the dm stuff for fsl_qspi driver.
This patch adds DM support for fsl_qspi driver, the DM part needs
device tree support.
Partial of the original driver code is reused, such as the AHB part,
the LUT initialization and etc. The driver now supports new DM and original
driver by define "CONFIG_DM_SPI". Until device tree is integrated, the
original part can be discarded.
The driver code file is now as following:
"
Common code that needs both by DM or original driver code.
#if defined(CONFIG_DM_SPI)
DM part
#else
Original driver code
#endif
"
In DM part, some reconstruction is done. A fsl_qspi_runcmd is included to
simplify the code, but not the original qspi_op_s. fsl_qspi_get_seqid
is included to get seqid, but not hardcoded in original qspi_op_s.
Signed-off-by: Peng Fan
---
drivers/spi/fsl_qspi.c | 420 +++--
drivers/spi/fsl_qspi.h | 1 +
2 files changed, 405 insertions(+), 16 deletions(-)
diff --git a/drivers/spi/fsl_qspi.c b/drivers/spi/fsl_qspi.c
index 5e0b069..ee151b3 100644
--- a/drivers/spi/fsl_qspi.c
+++ b/drivers/spi/fsl_qspi.c
@@ -13,6 +13,13 @@
#include
#include "fsl_qspi.h"
+#ifdef CONFIG_DM_SPI
+#include
+#include
+#include
+#include
+#endif
+
#define RX_BUFFER_SIZE 0x80
#ifdef CONFIG_MX6SX
#define TX_BUFFER_SIZE 0x200
@@ -71,27 +78,41 @@
#define qspi_write32 out_be32
#endif
-static unsigned long spi_bases[] = {
- QSPI0_BASE_ADDR,
-#ifdef CONFIG_MX6SX
- QSPI1_BASE_ADDR,
-#endif
-};
+#ifdef CONFIG_DM_SPI
+DECLARE_GLOBAL_DATA_PTR;
+#define QUADSPI_AHBMAP_BANK_MAXSIZESZ_64M
-static unsigned long amba_bases[] = {
- QSPI0_AMBA_BASE,
-#ifdef CONFIG_MX6SX
- QSPI1_AMBA_BASE,
-#endif
+struct fsl_qspi_platdata {
+ u32 max_hz;
+ u32 reg_base;
+ u32 amba_base;
+ u32 flash_num;
};
struct fsl_qspi {
+ u32 reg_base;
+ u32 amba_base;
+ size_t cmd_len;
+ u8 cmd_buf[32];
+ size_t data_len;
+ int qspi_is_init;
+ size_t flash_size;
+ u32 bank_memmap_phy[4];
+ int cs;
+ u32 sf_addr;
+ int flash_num;
+ u8 cur_seqid;
+ u32 freq;
+};
+#else
+struct fsl_qspi {
struct spi_slave slave;
unsigned long reg_base;
unsigned long amba_base;
u32 sf_addr;
u8 cur_seqid;
};
+#endif
/* QSPI support swapping the flash read/write data
* in hardware for LS102xA, but not for VF610 */
@@ -104,11 +125,6 @@ static inline u32 qspi_endian_xchg(u32 data)
#endif
}
-static inline struct fsl_qspi *to_qspi_spi(struct spi_slave *slave)
-{
- return container_of(slave, struct fsl_qspi, slave);
-}
-
static void qspi_set_lut(struct fsl_qspi *qspi)
{
struct fsl_qspi_regs *regs = (struct fsl_qspi_regs *)qspi->reg_base;
@@ -367,6 +383,377 @@ static void qspi_init_ahb_read(struct fsl_qspi_regs *regs)
}
#endif
+#ifdef CONFIG_DM_SPI
+/* Get the SEQID for the command */
+static int fsl_qspi_get_seqid(struct fsl_qspi *q, u8 cmd)
+{
+ switch (cmd) {
+ case QSPI_CMD_FAST_READ:
+ case QSPI_CMD_FAST_READ_4B:
+ return SEQID_FAST_READ;
+ case QSPI_CMD_WREN:
+ return SEQID_WREN;
+ case QSPI_CMD_RDSR:
+ return SEQID_RDSR;
+ case QSPI_CMD_SE:
+ return SEQID_SE;
+ case QSPI_CMD_PP:
+ case QSPI_CMD_PP_4B:
+ return SEQID_PP;
+ case QSPI_CMD_RDID:
+
Re: [U-Boot] [PATCH v1 6/6] omap3: add support for QUIPOS Cairo board.
Hello Simon, On Fri, 16 Jan 2015 10:20:15 -0700, Simon Glass wrote: > Hi Albert, > > On 16 January 2015 at 01:09, Albert ARIBAUD (3ADEV) > wrote: > > Signed-off-by: Albert ARIBAUD (3ADEV) > > --- > > > > arch/arm/cpu/armv7/omap3/Kconfig | 5 + > > board/quipos/cairo/Kconfig | 12 ++ > > board/quipos/cairo/Makefile | 8 + > > board/quipos/cairo/cairo.c | 90 > > board/quipos/cairo/cairo.h | 321 > > configs/cairo_defconfig | 4 + > > include/configs/omap3_cairo.h| 437 > > +++ > > 7 files changed, 877 insertions(+) > > create mode 100644 board/quipos/cairo/Kconfig > > create mode 100644 board/quipos/cairo/Makefile > > create mode 100644 board/quipos/cairo/cairo.c > > create mode 100644 board/quipos/cairo/cairo.h > > create mode 100644 configs/cairo_defconfig > > create mode 100644 include/configs/omap3_cairo.h > > Can this use driver model for serial? We are just creating problems > for future otherwise. Will do in v2. > Regards, > Simon Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v1 4/8] lpc32xx: add GPIO support
Hello Simon, On Fri, 16 Jan 2015 10:17:52 -0700, Simon Glass wrote: > Hi Albert, > > On 16 January 2015 at 00:19, Albert ARIBAUD (3ADEV) > wrote: > > Signed-off-by: Albert ARIBAUD (3ADEV) > > --- > > > > arch/arm/include/asm/arch-lpc32xx/gpio.h | 43 ++ > > drivers/gpio/Makefile| 1 + > > drivers/gpio/lpc32xx_gpio.c | 223 > > +++ > > 3 files changed, 267 insertions(+) > > create mode 100644 arch/arm/include/asm/arch-lpc32xx/gpio.h > > create mode 100644 drivers/gpio/lpc32xx_gpio.c > > This should be done with driver model these days. I'll move it to DM in v2. > Regards, > Simon Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v1 7/8] lpc32xx: add lpc32xx-spl.bin boot image target
Hello Marek, On Fri, 16 Jan 2015 14:08:58 +0100, Marek Vasut wrote: > On Friday, January 16, 2015 at 08:19:19 AM, Albert ARIBAUD (3ADEV) wrote: > > Signed-off-by: Albert ARIBAUD (3ADEV) > > --- > > > > Makefile | 3 + > > scripts/Makefile.spl | 11 > > tools/.gitignore | 1 + > > tools/Makefile| 2 + > > tools/mklpc32xxboot.c | 169 > > ++ 5 files changed, 186 > > insertions(+) > > create mode 100644 tools/mklpc32xxboot.c > > Hi! > > Are you positive this shouldn't be part of mkimage please ? No, I'm not positive. :) I'll move this to mkimage in v2. > Best regards, > Marek Vasut Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: spl: Allow board_init_r() to run with a larger stack
Hi Simon, On 18/01/2015 19:55, Simon Glass wrote: > At present SPL uses a single stack, either CONFIG_SPL_STACK or > CONFIG_SYS_INIT_SP_ADDR. Since some SPL features (such as MMC and > environment) require a lot of stack, some boards set CONFIG_SPL_STACK to > point into SDRAM. They then set up SDRAM very early, before board_init_f(), > so that the larger stack can be used. > > This is an abuse of lowlevel_init(). That function should only be used for > essential start-up code which cannot be delayed. An example of a valid use is > when only part of the SPL code is visible/executable, and the SoC must be set > up so that board_init_f() can be reached. It should not be used for SDRAM > init, console init, etc. > > Add a CONFIG_SPL_STACK_R option, which allows the stack to be moved to a new > address before board_init_r() is called in SPL. > > The expected SPL flow (for CONFIG_SPL_FRAMEWORK) is now: > > Execution starts with start.S. Two main functions can be provided by the > board implementation. The purpose and limitations of each is described below. > After that, the common board_init_r() is called to perform the SPL task. > > lowlevel_init(): > - purpose: essential init to permit execution to reach board_init_f() > - no global_data, but there is a stack > - must not set up SDRAM or use console > - must only do the bare minimum to allow execution to continue to > board_init_f() > - this is almost never needed > - return normally from this function > > board_init_f(): > - purpose: set up the machine ready for running board_init_r(): > i.e. SDRAM and serial UART > - global_data is available > - preloader_console_init() can be called here in extremis > - stack is in SRAM > - should set up SDRAM, and anything needed to make the UART work > - these is no need to clear BSS, it will be done by crt0.S > - must return normally from this function (don't call board_init_r() > directly) > > Here the BSS is cleared. If CONFIG_SPL_STACK_R is defined, then at this point > the stack and global_data are relocated to below that address. > > board_init_r(): > - purpose: main execution, common code > - global_data is available > - SDRAM is available > - stack is optionally in SDRAM, if CONFIG_SPL_STACK_R is defined and > points into SDRAM > - preloader_console_init() can be called here - typically this is > done by defining CONFIG_SPL_BOARD_INIT and then supplying a > spl_board_init() function containing this call > - loads U-Boot or (in falcon mode) Linux > > Note: This patch is intended to apply over the top of Tom's SPL changes and > this series: > > https://patchwork.ozlabs.org/patch/423785/ > > Signed-off-by: Simon Glass > --- > > arch/arm/lib/crt0.S | 13 ++--- > common/spl/spl.c| 35 +++ > doc/README.SPL | 42 ++ > 3 files changed, 87 insertions(+), 3 deletions(-) > > diff --git a/arch/arm/lib/crt0.S b/arch/arm/lib/crt0.S > index 22df3e5..7939ced 100644 > --- a/arch/arm/lib/crt0.S > +++ b/arch/arm/lib/crt0.S > @@ -113,7 +113,14 @@ here: > /* Set up final (full) environment */ > > bl c_runtime_cpu_setup /* we still call old routine here */ > - > +#endif > +#if !defined(CONFIG_SPL_BUILD) || defined(CONFIG_SPL_FRAMEWORK) > +# ifdef CONFIG_SPL_BUILD > + /* Use a DRAM stack for the rest of SPL, if requested */ > + bl spl_relocate_stack_gd > + cmp r0, #0 > + movne sp, r0 > +# endif > ldr r0, =__bss_start/* this is auto-relocated! */ > ldr r1, =__bss_end /* this is auto-relocated! */ > > @@ -124,9 +131,10 @@ clbss_l:cmp r0, r1 /* while not at > end of BSS */ > addlo r0, r0, #4 /* move to next */ > blo clbss_l > > +#if ! defined(CONFIG_SPL_BUILD) > bl coloured_LED_init > bl red_led_on > - > +#endif > /* call board_init_r(gd_t *id, ulong dest_addr) */ > mov r0, r9 /* gd_t */ > ldr r1, [r9, #GD_RELOCADDR] /* dest_addr */ > @@ -134,7 +142,6 @@ clbss_l:cmp r0, r1 /* while not at > end of BSS */ > ldr pc, =board_init_r /* this is auto-relocated! */ > > /* we should not return here. */ > - > #endif > > ENDPROC(_main) > diff --git a/common/spl/spl.c b/common/spl/spl.c > index 1826c47..78bb279 100644 > --- a/common/spl/spl.c > +++ b/common/spl/spl.c > @@ -276,3 +276,38 @@ void preloader_console_init(void) > spl_display_print(); > #endif > } > + > +/** > + * spl_relocate_stack_gd() - Relocate stack ready for board_init_r() > execution > + * > + * Sometimes board_init_f() runs with a stack in SRAM but we want to use > SDRAM > + * for the main board_init_r() execution. This is typically
Re: [U-Boot] [PATCH] arm: spl: Allow board_init_r() to run with a larger stack
On 18.01.2015 19:55, Simon Glass wrote: At present SPL uses a single stack, either CONFIG_SPL_STACK or CONFIG_SYS_INIT_SP_ADDR. Since some SPL features (such as MMC and environment) require a lot of stack, some boards set CONFIG_SPL_STACK to point into SDRAM. They then set up SDRAM very early, before board_init_f(), so that the larger stack can be used. This is an abuse of lowlevel_init(). That function should only be used for essential start-up code which cannot be delayed. An example of a valid use is when only part of the SPL code is visible/executable, and the SoC must be set up so that board_init_f() can be reached. It should not be used for SDRAM init, console init, etc. Add a CONFIG_SPL_STACK_R option, which allows the stack to be moved to a new address before board_init_r() is called in SPL. The expected SPL flow (for CONFIG_SPL_FRAMEWORK) is now: Execution starts with start.S. Two main functions can be provided by the board implementation. The purpose and limitations of each is described below. After that, the common board_init_r() is called to perform the SPL task. lowlevel_init(): - purpose: essential init to permit execution to reach board_init_f() - no global_data, but there is a stack - must not set up SDRAM or use console - must only do the bare minimum to allow execution to continue to board_init_f() - this is almost never needed - return normally from this function board_init_f(): - purpose: set up the machine ready for running board_init_r(): i.e. SDRAM and serial UART - global_data is available - preloader_console_init() can be called here in extremis - stack is in SRAM - should set up SDRAM, and anything needed to make the UART work - these is no need to clear BSS, it will be done by crt0.S - must return normally from this function (don't call board_init_r() directly) Here the BSS is cleared. If CONFIG_SPL_STACK_R is defined, then at this point the stack and global_data are relocated to below that address. board_init_r(): - purpose: main execution, common code - global_data is available - SDRAM is available - stack is optionally in SDRAM, if CONFIG_SPL_STACK_R is defined and points into SDRAM - preloader_console_init() can be called here - typically this is done by defining CONFIG_SPL_BOARD_INIT and then supplying a spl_board_init() function containing this call - loads U-Boot or (in falcon mode) Linux Note: This patch is intended to apply over the top of Tom's SPL changes and this series: https://patchwork.ozlabs.org/patch/423785/ Signed-off-by: Simon Glass Reviewed-by: Stefan Roese Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: spl: Allow board_init_r() to run with a larger stack
Hello Simon, On Sun, 18 Jan 2015 11:55:36 -0700, Simon Glass wrote: > At present SPL uses a single stack, either CONFIG_SPL_STACK or > CONFIG_SYS_INIT_SP_ADDR. Since some SPL features (such as MMC and > environment) require a lot of stack, some boards set CONFIG_SPL_STACK to > point into SDRAM. They then set up SDRAM very early, before board_init_f(), > so that the larger stack can be used. > > This is an abuse of lowlevel_init(). That function should only be used for > essential start-up code which cannot be delayed. An example of a valid use is > when only part of the SPL code is visible/executable, and the SoC must be set > up so that board_init_f() can be reached. It should not be used for SDRAM > init, console init, etc. > > Add a CONFIG_SPL_STACK_R option, which allows the stack to be moved to a new > address before board_init_r() is called in SPL. > > The expected SPL flow (for CONFIG_SPL_FRAMEWORK) is now: > > Execution starts with start.S. Two main functions can be provided by the > board implementation. The purpose and limitations of each is described below. > After that, the common board_init_r() is called to perform the SPL task. > > lowlevel_init(): > - purpose: essential init to permit execution to reach board_init_f() > - no global_data, but there is a stack > - must not set up SDRAM or use console > - must only do the bare minimum to allow execution to continue to > board_init_f() > - this is almost never needed > - return normally from this function > > board_init_f(): > - purpose: set up the machine ready for running board_init_r(): > i.e. SDRAM and serial UART > - global_data is available > - preloader_console_init() can be called here in extremis > - stack is in SRAM > - should set up SDRAM, and anything needed to make the UART work > - these is no need to clear BSS, it will be done by crt0.S > - must return normally from this function (don't call board_init_r() > directly) > > Here the BSS is cleared. If CONFIG_SPL_STACK_R is defined, then at this point > the stack and global_data are relocated to below that address. > > board_init_r(): > - purpose: main execution, common code > - global_data is available > - SDRAM is available > - stack is optionally in SDRAM, if CONFIG_SPL_STACK_R is defined and > points into SDRAM > - preloader_console_init() can be called here - typically this is > done by defining CONFIG_SPL_BOARD_INIT and then supplying a > spl_board_init() function containing this call > - loads U-Boot or (in falcon mode) Linux Seems to me that now SPL and non-SPL boot sequences are mostly similar in the name, order and purpose of the functions called (which is a good thing!) so maybe this sequence should be described in a single document rather than in doc/README.SPL? Just opening the discussion; I have no strong opinion on this. > Note: This patch is intended to apply over the top of Tom's SPL changes and > this series: > > https://patchwork.ozlabs.org/patch/423785/ > > Signed-off-by: Simon Glass > --- Acked-by: Albert ARIBAUD Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: spl: Allow board_init_r() to run with a larger stack
Hello Simon, added Bo Shen to cc, as he currently try to set BSS (and stack) into SDRAM for at91 based boards ... Bo, could you try this aproach? Am 18.01.2015 19:55, schrieb Simon Glass: At present SPL uses a single stack, either CONFIG_SPL_STACK or CONFIG_SYS_INIT_SP_ADDR. Since some SPL features (such as MMC and environment) require a lot of stack, some boards set CONFIG_SPL_STACK to point into SDRAM. They then set up SDRAM very early, before board_init_f(), so that the larger stack can be used. This is an abuse of lowlevel_init(). That function should only be used for essential start-up code which cannot be delayed. An example of a valid use is when only part of the SPL code is visible/executable, and the SoC must be set up so that board_init_f() can be reached. It should not be used for SDRAM init, console init, etc. Add a CONFIG_SPL_STACK_R option, which allows the stack to be moved to a new address before board_init_r() is called in SPL. The expected SPL flow (for CONFIG_SPL_FRAMEWORK) is now: Execution starts with start.S. Two main functions can be provided by the board implementation. The purpose and limitations of each is described below. After that, the common board_init_r() is called to perform the SPL task. lowlevel_init(): - purpose: essential init to permit execution to reach board_init_f() - no global_data, but there is a stack - must not set up SDRAM or use console - must only do the bare minimum to allow execution to continue to board_init_f() - this is almost never needed - return normally from this function board_init_f(): - purpose: set up the machine ready for running board_init_r(): i.e. SDRAM and serial UART - global_data is available - preloader_console_init() can be called here in extremis - stack is in SRAM - should set up SDRAM, and anything needed to make the UART work - these is no need to clear BSS, it will be done by crt0.S - must return normally from this function (don't call board_init_r() directly) Here the BSS is cleared. If CONFIG_SPL_STACK_R is defined, then at this point the stack and global_data are relocated to below that address. board_init_r(): - purpose: main execution, common code - global_data is available - SDRAM is available - stack is optionally in SDRAM, if CONFIG_SPL_STACK_R is defined and points into SDRAM - preloader_console_init() can be called here - typically this is done by defining CONFIG_SPL_BOARD_INIT and then supplying a spl_board_init() function containing this call - loads U-Boot or (in falcon mode) Linux Note: This patch is intended to apply over the top of Tom's SPL changes and Sound good! Can you point me, which patches you mean? Thanks! this series: https://patchwork.ozlabs.org/patch/423785/ Signed-off-by: Simon Glass --- arch/arm/lib/crt0.S | 13 ++--- common/spl/spl.c| 35 +++ doc/README.SPL | 42 ++ 3 files changed, 87 insertions(+), 3 deletions(-) Hmm... I miss here "arch/arm/lib/spl.c" where "clearing BSS" should get removed ... or? diff --git a/arch/arm/lib/crt0.S b/arch/arm/lib/crt0.S index 22df3e5..7939ced 100644 --- a/arch/arm/lib/crt0.S +++ b/arch/arm/lib/crt0.S @@ -113,7 +113,14 @@ here: /* Set up final (full) environment */ bl c_runtime_cpu_setup /* we still call old routine here */ - +#endif +#if !defined(CONFIG_SPL_BUILD) || defined(CONFIG_SPL_FRAMEWORK) +# ifdef CONFIG_SPL_BUILD + /* Use a DRAM stack for the rest of SPL, if requested */ + bl spl_relocate_stack_gd + cmp r0, #0 + movne sp, r0 +# endif ldr r0, =__bss_start/* this is auto-relocated! */ ldr r1, =__bss_end /* this is auto-relocated! */ @@ -124,9 +131,10 @@ clbss_l:cmpr0, r1 /* while not at end of BSS */ addlo r0, r0, #4 /* move to next */ blo clbss_l +#if ! defined(CONFIG_SPL_BUILD) bl coloured_LED_init bl red_led_on - +#endif /* call board_init_r(gd_t *id, ulong dest_addr) */ mov r0, r9 /* gd_t */ ldr r1, [r9, #GD_RELOCADDR] /* dest_addr */ @@ -134,7 +142,6 @@ clbss_l:cmp r0, r1 /* while not at end of BSS */ ldr pc, =board_init_r /* this is auto-relocated! */ /* we should not return here. */ - #endif ENDPROC(_main) diff --git a/common/spl/spl.c b/common/spl/spl.c index 1826c47..78bb279 100644 --- a/common/spl/spl.c +++ b/common/spl/spl.c @@ -276,3 +276,38 @@ void preloader_console_init(void) spl_display_print(); #endif } + +/** + * spl_relocate_stack_gd() - Relocate stack ready for board_init_r() execution + * + * Sometimes
Re: [U-Boot] [PATCH 0/9] Remove use of gdata for global_data
Hello Simon, On Tue, 23 Dec 2014 12:04:50 -0700, Simon Glass wrote: > Some ARM boards use global_data in SPL before it set up by crt0.S. To > achieve this they use a separate global_data variable called gdata which > resides in the data section. The one set up by crt0.S is generally ignored. > > This prevents crt0.S from setting up things like the early malloc() pool. > It therefore prevents driver model from being used in SPL. > > However gdata really isn't needed. In fact lowlevel_init() is called just > before board_init_f() so, for SPL at least, there is no point in doing > anything before board_init_f(). The one slightly messy area is that SPL > may want to move the stack from SRAM to SDRAM at some point. But this should > be done at the end of board_init_f() (or before board_init_r() is called) > and is not a reason to init DRAM before board_init_f(). > > It isn't that difficult to get rid of gdata. This series builds on Tom Rini's > recent series for omap3, and extends it to the other offenders: imx, sunxi > and zynq. > > I have tested so far only on sunxi. This series is available at u-boot-dm > branch 'gd-working'. Overall series: Acked-by: Albert ARIBAUD Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/mpc85xx: Add DSP side awareness for Freescale Heterogeneous SoCs
Kindly ignore this one, as I forgot to add v2 changes in this patch. Sending
another one.
Regards,
Shaveta
-Original Message-
From: Shaveta Leekha [mailto:shav...@freescale.com]
Sent: Monday, January 19, 2015 12:44 PM
To: u-boot@lists.denx.de
Cc: Aggrwal Poonam-B10812; Sun York-R58495; Leekha Shaveta-B20052
Subject: [PATCH] powerpc/mpc85xx: Add DSP side awareness for Freescale
Heterogeneous SoCs
The code provides framework for heterogeneous multicore chips based on StarCore
and Power Architecture which are chasis-2 compliant, like B4860 and B4420
It will make u-boot recognize all non-ppc cores and peripherals like SC3900/DSP
CPUs, MAPLE, CPRI and print their configuration in u-boot logs.
Example boot logs of B4860QDS:
U-Boot 2015.01-00232-geef6e36-dirty (Jan 19 2015 - 11:58:45)
CPU0: B4860E, Version: 2.2, (0x86880022)
Core: e6500, Version: 2.0, (0x80400120) Clock Configuration:
CPU0:1600 MHz, CPU1:1600 MHz, CPU2:1600 MHz, CPU3:1600 MHz,
DSP CPU0:1200 MHz, DSP CPU1:1200 MHz, DSP CPU2:1200 MHz, DSP CPU3:1200
MHz,
DSP CPU4:1200 MHz, DSP CPU5:1200 MHz,
CCB:666.667 MHz,
DDR:933.333 MHz (1866.667 MT/s data rate) (Asynchronous), IFC:166.667 MHz
CPRI:600 MHz
MAPLE:600 MHz, MAPLE-ULB:800 MHz, MAPLE-eTVPE:1000 MHz
FMAN1: 666.667 MHz
QMAN: 333.333 MHz
Top level changes include:
(1) Top level CONFIG to identify HETEROGENUOUS clusters
(2) CONFIGS for SC3900/DSP components
(3) Global structures like "cpu_type" and "MPC85xx_SYS_INFO"
updated for dsp cores and other components
(3) APIs to get DSP num cores and their Mask like:
cpu_dsp_mask, cpu_num_dspcores etc same as that of PowerPC
(5) Code to fetch and print SC cores and other heterogenous
device's frequencies
(6) README added for the same
Signed-off-by: Shaveta Leekha
---
arch/powerpc/cpu/mpc85xx/cpu.c| 28 ++
arch/powerpc/cpu/mpc85xx/speed.c | 140 +
arch/powerpc/cpu/mpc8xxx/cpu.c| 91 ++-
arch/powerpc/include/asm/config_mpc85xx.h | 14 +++-
arch/powerpc/include/asm/processor.h |5 +
doc/README.Heterogeneous-SoCs | 105 +
include/common.h |2 +
include/e500.h| 11 +++
8 files changed, 393 insertions(+), 3 deletions(-) create mode 100644
doc/README.Heterogeneous-SoCs
diff --git a/arch/powerpc/cpu/mpc85xx/cpu.c b/arch/powerpc/cpu/mpc85xx/cpu.c
index 3d6ec84..ef08489 100644
--- a/arch/powerpc/cpu/mpc85xx/cpu.c
+++ b/arch/powerpc/cpu/mpc85xx/cpu.c
@@ -73,6 +73,11 @@ int checkcpu (void)
unsigned int i, core, nr_cores = cpu_numcores();
u32 mask = cpu_mask();
+#ifdef CONFIG_HETROGENOUS_CLUSTERS
+ unsigned int j, dsp_core, dsp_numcores = cpu_num_dspcores();
+ u32 dsp_mask = cpu_dsp_mask();
+#endif
+
svr = get_svr();
major = SVR_MAJ(svr);
minor = SVR_MIN(svr);
@@ -166,6 +171,16 @@ int checkcpu (void)
printf("CPU%d:%-4s MHz, ", core,
strmhz(buf1, sysinfo.freq_processor[core]));
}
+
+#ifdef CONFIG_HETROGENOUS_CLUSTERS
+ for_each_cpu(j, dsp_core, dsp_numcores, dsp_mask) {
+ if (!(j & 3))
+ printf("\n ");
+ printf("DSP CPU%d:%-4s MHz, ", j,
+ strmhz(buf1, sysinfo.freq_processor_dsp[dsp_core]));
+ }
+#endif
+
printf("\n CCB:%-4s MHz,", strmhz(buf1, sysinfo.freq_systembus));
printf("\n");
@@ -224,6 +239,19 @@ int checkcpu (void)
printf(" QE:%-4s MHz\n", strmhz(buf1, sysinfo.freq_qe));
#endif
+#if defined(CONFIG_SYS_CPRI)
+ printf(" ");
+ printf("CPRI:%-4s MHz", strmhz(buf1, sysinfo.freq_cpri)); #endif
+
+#if defined(CONFIG_SYS_MAPLE)
+ printf("\n ");
+ printf("MAPLE:%-4s MHz, ", strmhz(buf1, sysinfo.freq_maple));
+ printf("MAPLE-ULB:%-4s MHz, ", strmhz(buf1, sysinfo.freq_maple_ulb));
+ printf("MAPLE-eTVPE:%-4s MHz\n",
+ strmhz(buf1, sysinfo.freq_maple_etvpe)); #endif
+
#ifdef CONFIG_SYS_DPAA_FMAN
for (i = 0; i < CONFIG_SYS_NUM_FMAN; i++) {
printf(" FMAN%d: %s MHz\n", i + 1,
diff --git a/arch/powerpc/cpu/mpc85xx/speed.c b/arch/powerpc/cpu/mpc85xx/speed.c
index 7e69873..e24b857 100644
--- a/arch/powerpc/cpu/mpc85xx/speed.c
+++ b/arch/powerpc/cpu/mpc85xx/speed.c
@@ -34,6 +34,10 @@ void get_sys_info(sys_info_t *sys_info) #ifdef
CONFIG_FSL_CORENET
volatile ccsr_clk_t *clk = (void *)(CONFIG_SYS_FSL_CORENET_CLK_ADDR);
unsigned int cpu;
+#ifdef CONFIG_HETROGENOUS_CLUSTERS
+ unsigned int dsp_cpu;
+ uint rcw_tmp1, rcw_tmp2;
+#endif
#ifdef CONFIG_SYS_FSL_QORIQ_CHASSIS2
int cc_group[12] = CONFIG_SYS_FSL_CLUSTER_CLOCKS; #endif @@ -157,6
+161,7 @@ void get_sys_info(sys_info_t *sys_info)
else
freq_c_pl
[U-Boot] [PATCH][v2] powerpc/mpc85xx: Add DSP side awareness for Freescale Heterogeneous SoCs
The code provides framework for heterogeneous multicore chips based on StarCore
and Power Architecture which are chasis-2 compliant, like B4860 and B4420
It will make u-boot recognize all non-ppc cores and peripherals like
SC3900/DSP CPUs, MAPLE, CPRI and print their configuration in u-boot logs.
Example boot logs of B4860QDS:
U-Boot 2015.01-00232-geef6e36-dirty (Jan 19 2015 - 11:58:45)
CPU0: B4860E, Version: 2.2, (0x86880022)
Core: e6500, Version: 2.0, (0x80400120)
Clock Configuration:
CPU0:1600 MHz, CPU1:1600 MHz, CPU2:1600 MHz, CPU3:1600 MHz,
DSP CPU0:1200 MHz, DSP CPU1:1200 MHz, DSP CPU2:1200 MHz, DSP CPU3:1200
MHz,
DSP CPU4:1200 MHz, DSP CPU5:1200 MHz,
CCB:666.667 MHz,
DDR:933.333 MHz (1866.667 MT/s data rate) (Asynchronous), IFC:166.667 MHz
CPRI:600 MHz
MAPLE:600 MHz, MAPLE-ULB:800 MHz, MAPLE-eTVPE:1000 MHz
FMAN1: 666.667 MHz
QMAN: 333.333 MHz
Top level changes include:
(1) Top level CONFIG to identify HETEROGENUOUS clusters
(2) CONFIGS for SC3900/DSP components
(3) Global structures like "cpu_type" and "MPC85xx_SYS_INFO"
updated for dsp cores and other components
(3) APIs to get DSP num cores and their Mask like:
cpu_dsp_mask, cpu_num_dspcores etc same as that of PowerPC
(5) Code to fetch and print SC cores and other heterogenous
device's frequencies
(6) README added for the same
Signed-off-by: Shaveta Leekha
---
chnages in v2:
Incorporated review comments
All DSP aware code is enclosed with #ifdef
to not increase the uboot code size for other platforms
Tested it on B4860QDS and on T4240QDS
arch/powerpc/cpu/mpc85xx/cpu.c| 28 ++
arch/powerpc/cpu/mpc85xx/speed.c | 140 +
arch/powerpc/cpu/mpc8xxx/cpu.c| 91 ++-
arch/powerpc/include/asm/config_mpc85xx.h | 14 +++-
arch/powerpc/include/asm/processor.h |5 +
doc/README.Heterogeneous-SoCs | 105 +
include/common.h |2 +
include/e500.h| 11 +++
8 files changed, 393 insertions(+), 3 deletions(-)
create mode 100644 doc/README.Heterogeneous-SoCs
diff --git a/arch/powerpc/cpu/mpc85xx/cpu.c b/arch/powerpc/cpu/mpc85xx/cpu.c
index 3d6ec84..ef08489 100644
--- a/arch/powerpc/cpu/mpc85xx/cpu.c
+++ b/arch/powerpc/cpu/mpc85xx/cpu.c
@@ -73,6 +73,11 @@ int checkcpu (void)
unsigned int i, core, nr_cores = cpu_numcores();
u32 mask = cpu_mask();
+#ifdef CONFIG_HETROGENOUS_CLUSTERS
+ unsigned int j, dsp_core, dsp_numcores = cpu_num_dspcores();
+ u32 dsp_mask = cpu_dsp_mask();
+#endif
+
svr = get_svr();
major = SVR_MAJ(svr);
minor = SVR_MIN(svr);
@@ -166,6 +171,16 @@ int checkcpu (void)
printf("CPU%d:%-4s MHz, ", core,
strmhz(buf1, sysinfo.freq_processor[core]));
}
+
+#ifdef CONFIG_HETROGENOUS_CLUSTERS
+ for_each_cpu(j, dsp_core, dsp_numcores, dsp_mask) {
+ if (!(j & 3))
+ printf("\n ");
+ printf("DSP CPU%d:%-4s MHz, ", j,
+ strmhz(buf1, sysinfo.freq_processor_dsp[dsp_core]));
+ }
+#endif
+
printf("\n CCB:%-4s MHz,", strmhz(buf1, sysinfo.freq_systembus));
printf("\n");
@@ -224,6 +239,19 @@ int checkcpu (void)
printf(" QE:%-4s MHz\n", strmhz(buf1, sysinfo.freq_qe));
#endif
+#if defined(CONFIG_SYS_CPRI)
+ printf(" ");
+ printf("CPRI:%-4s MHz", strmhz(buf1, sysinfo.freq_cpri));
+#endif
+
+#if defined(CONFIG_SYS_MAPLE)
+ printf("\n ");
+ printf("MAPLE:%-4s MHz, ", strmhz(buf1, sysinfo.freq_maple));
+ printf("MAPLE-ULB:%-4s MHz, ", strmhz(buf1, sysinfo.freq_maple_ulb));
+ printf("MAPLE-eTVPE:%-4s MHz\n",
+ strmhz(buf1, sysinfo.freq_maple_etvpe));
+#endif
+
#ifdef CONFIG_SYS_DPAA_FMAN
for (i = 0; i < CONFIG_SYS_NUM_FMAN; i++) {
printf(" FMAN%d: %s MHz\n", i + 1,
diff --git a/arch/powerpc/cpu/mpc85xx/speed.c b/arch/powerpc/cpu/mpc85xx/speed.c
index 7e69873..e24b857 100644
--- a/arch/powerpc/cpu/mpc85xx/speed.c
+++ b/arch/powerpc/cpu/mpc85xx/speed.c
@@ -34,6 +34,10 @@ void get_sys_info(sys_info_t *sys_info)
#ifdef CONFIG_FSL_CORENET
volatile ccsr_clk_t *clk = (void *)(CONFIG_SYS_FSL_CORENET_CLK_ADDR);
unsigned int cpu;
+#ifdef CONFIG_HETROGENOUS_CLUSTERS
+ unsigned int dsp_cpu;
+ uint rcw_tmp1, rcw_tmp2;
+#endif
#ifdef CONFIG_SYS_FSL_QORIQ_CHASSIS2
int cc_group[12] = CONFIG_SYS_FSL_CLUSTER_CLOCKS;
#endif
@@ -157,6 +161,7 @@ void get_sys_info(sys_info_t *sys_info)
else
freq_c_pll[i] = sys_info->freq_systembus * ratio[i];
}
+
#ifdef CONFIG_SYS_FSL_QORIQ_CHASSIS2
/*
* As per CHASSIS2 architeture total 12 clusters are posible and
@@ -181,6 +186,20 @@ void
[U-Boot] [PATCH] ARM: at91: mmc portA support is only for at91sam9g20ek_2mmc board
Current the MMC support will enable MCI port A, Which is only exist for 2mmc board. So by default we need to disable MMC (port A) support. And only enable it for 2mmc board. Otherwise, dataflash won't work in at91sam9260ek board as MMC has confliction with Dataflash in the CLK pin. Signed-off-by: Josh Wu --- configs/at91sam9g20ek_2mmc_defconfig | 3 +++ configs/at91sam9g20ek_mmc_defconfig | 3 --- include/configs/at91sam9260ek.h | 6 -- 3 files changed, 7 insertions(+), 5 deletions(-) create mode 100644 configs/at91sam9g20ek_2mmc_defconfig delete mode 100644 configs/at91sam9g20ek_mmc_defconfig diff --git a/configs/at91sam9g20ek_2mmc_defconfig b/configs/at91sam9g20ek_2mmc_defconfig new file mode 100644 index 000..4eef04f --- /dev/null +++ b/configs/at91sam9g20ek_2mmc_defconfig @@ -0,0 +1,3 @@ +CONFIG_SYS_EXTRA_OPTIONS="AT91SAM9G20,AT91SAM9G20EK_2MMC,SYS_USE_MMC" +CONFIG_ARM=y +CONFIG_TARGET_AT91SAM9260EK=y diff --git a/configs/at91sam9g20ek_mmc_defconfig b/configs/at91sam9g20ek_mmc_defconfig deleted file mode 100644 index 8cca2e5..000 --- a/configs/at91sam9g20ek_mmc_defconfig +++ /dev/null @@ -1,3 +0,0 @@ -CONFIG_SYS_EXTRA_OPTIONS="AT91SAM9G20,SYS_USE_MMC" -CONFIG_ARM=y -CONFIG_TARGET_AT91SAM9260EK=y diff --git a/include/configs/at91sam9260ek.h b/include/configs/at91sam9260ek.h index a6a80de..c4b2e16 100644 --- a/include/configs/at91sam9260ek.h +++ b/include/configs/at91sam9260ek.h @@ -90,7 +90,6 @@ #define CONFIG_CMD_PING1 #define CONFIG_CMD_DHCP1 #define CONFIG_CMD_NAND1 -#define CONFIG_CMD_MMC #define CONFIG_CMD_FAT #define CONFIG_CMD_USB 1 @@ -133,14 +132,17 @@ # define CONFIG_MACH_TYPE MACH_TYPE_AT91SAM9260EK #endif -/* DataFlash */ #ifndef CONFIG_AT91SAM9G20EK_2MMC +/* DataFlash */ #define CONFIG_ATMEL_DATAFLASH_SPI #define CONFIG_HAS_DATAFLASH 1 #define CONFIG_SYS_MAX_DATAFLASH_BANKS 2 #define CONFIG_SYS_DATAFLASH_LOGIC_ADDR_CS00xC000 /* CS0 */ #define CONFIG_SYS_DATAFLASH_LOGIC_ADDR_CS10xD000 /* CS1 */ #define AT91_SPI_CLK 1500 +#else +/* Enable MMC. The MCCK is conflicted with DataFlash */ +#define CONFIG_CMD_MMC #endif #ifdef CONFIG_AT91SAM9G20EK -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] powerpc/mpc85xx: Add DSP side awareness for Freescale Heterogeneous SoCs
The code provides framework for heterogeneous multicore chips based on StarCore
and Power Architecture which are chasis-2 compliant, like B4860 and B4420
It will make u-boot recognize all non-ppc cores and peripherals like
SC3900/DSP CPUs, MAPLE, CPRI and print their configuration in u-boot logs.
Example boot logs of B4860QDS:
U-Boot 2015.01-00232-geef6e36-dirty (Jan 19 2015 - 11:58:45)
CPU0: B4860E, Version: 2.2, (0x86880022)
Core: e6500, Version: 2.0, (0x80400120)
Clock Configuration:
CPU0:1600 MHz, CPU1:1600 MHz, CPU2:1600 MHz, CPU3:1600 MHz,
DSP CPU0:1200 MHz, DSP CPU1:1200 MHz, DSP CPU2:1200 MHz, DSP CPU3:1200
MHz,
DSP CPU4:1200 MHz, DSP CPU5:1200 MHz,
CCB:666.667 MHz,
DDR:933.333 MHz (1866.667 MT/s data rate) (Asynchronous), IFC:166.667 MHz
CPRI:600 MHz
MAPLE:600 MHz, MAPLE-ULB:800 MHz, MAPLE-eTVPE:1000 MHz
FMAN1: 666.667 MHz
QMAN: 333.333 MHz
Top level changes include:
(1) Top level CONFIG to identify HETEROGENUOUS clusters
(2) CONFIGS for SC3900/DSP components
(3) Global structures like "cpu_type" and "MPC85xx_SYS_INFO"
updated for dsp cores and other components
(3) APIs to get DSP num cores and their Mask like:
cpu_dsp_mask, cpu_num_dspcores etc same as that of PowerPC
(5) Code to fetch and print SC cores and other heterogenous
device's frequencies
(6) README added for the same
Signed-off-by: Shaveta Leekha
---
arch/powerpc/cpu/mpc85xx/cpu.c| 28 ++
arch/powerpc/cpu/mpc85xx/speed.c | 140 +
arch/powerpc/cpu/mpc8xxx/cpu.c| 91 ++-
arch/powerpc/include/asm/config_mpc85xx.h | 14 +++-
arch/powerpc/include/asm/processor.h |5 +
doc/README.Heterogeneous-SoCs | 105 +
include/common.h |2 +
include/e500.h| 11 +++
8 files changed, 393 insertions(+), 3 deletions(-)
create mode 100644 doc/README.Heterogeneous-SoCs
diff --git a/arch/powerpc/cpu/mpc85xx/cpu.c b/arch/powerpc/cpu/mpc85xx/cpu.c
index 3d6ec84..ef08489 100644
--- a/arch/powerpc/cpu/mpc85xx/cpu.c
+++ b/arch/powerpc/cpu/mpc85xx/cpu.c
@@ -73,6 +73,11 @@ int checkcpu (void)
unsigned int i, core, nr_cores = cpu_numcores();
u32 mask = cpu_mask();
+#ifdef CONFIG_HETROGENOUS_CLUSTERS
+ unsigned int j, dsp_core, dsp_numcores = cpu_num_dspcores();
+ u32 dsp_mask = cpu_dsp_mask();
+#endif
+
svr = get_svr();
major = SVR_MAJ(svr);
minor = SVR_MIN(svr);
@@ -166,6 +171,16 @@ int checkcpu (void)
printf("CPU%d:%-4s MHz, ", core,
strmhz(buf1, sysinfo.freq_processor[core]));
}
+
+#ifdef CONFIG_HETROGENOUS_CLUSTERS
+ for_each_cpu(j, dsp_core, dsp_numcores, dsp_mask) {
+ if (!(j & 3))
+ printf("\n ");
+ printf("DSP CPU%d:%-4s MHz, ", j,
+ strmhz(buf1, sysinfo.freq_processor_dsp[dsp_core]));
+ }
+#endif
+
printf("\n CCB:%-4s MHz,", strmhz(buf1, sysinfo.freq_systembus));
printf("\n");
@@ -224,6 +239,19 @@ int checkcpu (void)
printf(" QE:%-4s MHz\n", strmhz(buf1, sysinfo.freq_qe));
#endif
+#if defined(CONFIG_SYS_CPRI)
+ printf(" ");
+ printf("CPRI:%-4s MHz", strmhz(buf1, sysinfo.freq_cpri));
+#endif
+
+#if defined(CONFIG_SYS_MAPLE)
+ printf("\n ");
+ printf("MAPLE:%-4s MHz, ", strmhz(buf1, sysinfo.freq_maple));
+ printf("MAPLE-ULB:%-4s MHz, ", strmhz(buf1, sysinfo.freq_maple_ulb));
+ printf("MAPLE-eTVPE:%-4s MHz\n",
+ strmhz(buf1, sysinfo.freq_maple_etvpe));
+#endif
+
#ifdef CONFIG_SYS_DPAA_FMAN
for (i = 0; i < CONFIG_SYS_NUM_FMAN; i++) {
printf(" FMAN%d: %s MHz\n", i + 1,
diff --git a/arch/powerpc/cpu/mpc85xx/speed.c b/arch/powerpc/cpu/mpc85xx/speed.c
index 7e69873..e24b857 100644
--- a/arch/powerpc/cpu/mpc85xx/speed.c
+++ b/arch/powerpc/cpu/mpc85xx/speed.c
@@ -34,6 +34,10 @@ void get_sys_info(sys_info_t *sys_info)
#ifdef CONFIG_FSL_CORENET
volatile ccsr_clk_t *clk = (void *)(CONFIG_SYS_FSL_CORENET_CLK_ADDR);
unsigned int cpu;
+#ifdef CONFIG_HETROGENOUS_CLUSTERS
+ unsigned int dsp_cpu;
+ uint rcw_tmp1, rcw_tmp2;
+#endif
#ifdef CONFIG_SYS_FSL_QORIQ_CHASSIS2
int cc_group[12] = CONFIG_SYS_FSL_CLUSTER_CLOCKS;
#endif
@@ -157,6 +161,7 @@ void get_sys_info(sys_info_t *sys_info)
else
freq_c_pll[i] = sys_info->freq_systembus * ratio[i];
}
+
#ifdef CONFIG_SYS_FSL_QORIQ_CHASSIS2
/*
* As per CHASSIS2 architeture total 12 clusters are posible and
@@ -181,6 +186,20 @@ void get_sys_info(sys_info_t *sys_info)
sys_info->freq_processor[cpu] =
freq_c_pll[cplx_pll] / core_cplx_pll_div[c_pll_sel];
}
+
+#ifdef CONFIG_HETROGENOUS_CLUSTERS
+
[U-Boot] [PATCH v2 2/3] ARM: at91: sama5d3xek: save enviroment as a FAT file in MMC card
This patch will save U-Boot environment as a file: uboot.env, in FAT partition instead of in raw sector of MMC card. This make us easier to manage the environment file. Signed-off-by: Josh Wu --- include/configs/sama5d3xek.h | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/include/configs/sama5d3xek.h b/include/configs/sama5d3xek.h index f2849d7..c29f25b 100644 --- a/include/configs/sama5d3xek.h +++ b/include/configs/sama5d3xek.h @@ -215,13 +215,15 @@ "bootm 0x2200 - 0x2100" #elif CONFIG_SYS_USE_MMC /* bootstrap + u-boot + env in sd card */ -#define CONFIG_ENV_IS_IN_MMC -#define CONFIG_ENV_OFFSET 0x2000 -#define CONFIG_ENV_SIZE0x1000 +#define CONFIG_ENV_IS_IN_FAT +#define CONFIG_FAT_WRITE +#define FAT_ENV_INTERFACE "mmc" +#define FAT_ENV_FILE "uboot.env" +#define FAT_ENV_DEVICE_AND_PART"0" +#define CONFIG_ENV_SIZE0x4000 #define CONFIG_BOOTCOMMAND "fatload mmc 0:1 0x2100 dtb; " \ "fatload mmc 0:1 0x2200 uImage; " \ "bootm 0x2200 - 0x2100" -#define CONFIG_SYS_MMC_ENV_DEV 0 #else #define CONFIG_ENV_IS_NOWHERE #endif -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot.img size limit for spl fat load ?
Hello Ayoub, On Fri, 16 Jan 2015 15:42:37 +0100, Ayoub Zaki wrote: > Hello list, > > I'm using u-boot-2014.10 and trying to build it with LCD support for the > Beaglebone black to include a Boot logo image. > It seems that spl hangs while fat loading a 2.8MB sized u-boot.img ! > I reduced the the logo header file and rebuild u-boot, that worked for a > 1.6MB sized u-boot.img. > Is there any size limit for u-boot ? how to increase the memory allocated > by spl ? There should not be a size limit for SPL fat load. What may happen is that SPL code is overwritten before it exits, or U-Boot itself is corrupted after being loaded. I assume you've seen the SPL banner and not the U-Boot one; that alone does not tell us whether SPL or U-Boot did hang. Can you build U-boot with debug enabled? If this results in too big an SPL image, then try and at least enable debug for the image chainloading parts, so that you can see how far SPL code gets run. > Thanks you. No problem. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 3/3] ARM: at91: at91sam9x5: save environment to a FAT file in MMC card
This patch will save U-Boot environment as a file: uboot.env, in FAT partition instead of saving it in raw sector of MMC card. This make us easier to manage the environment file. Signed-off-by: Josh Wu --- include/configs/at91sam9x5ek.h | 11 ++- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/include/configs/at91sam9x5ek.h b/include/configs/at91sam9x5ek.h index b1d4baa..6d8b71d 100644 --- a/include/configs/at91sam9x5ek.h +++ b/include/configs/at91sam9x5ek.h @@ -203,11 +203,12 @@ "bootm 0x2200" #else /* CONFIG_SYS_USE_MMC */ /* bootstrap + u-boot + env + linux in mmc */ -#define CONFIG_ENV_IS_IN_MMC -/* For FAT system, most cases it should be in the reserved sector */ -#define CONFIG_ENV_OFFSET 0x2000 -#define CONFIG_ENV_SIZE0x1000 -#define CONFIG_SYS_MMC_ENV_DEV 0 +#define CONFIG_ENV_IS_IN_FAT +#define CONFIG_FAT_WRITE +#define FAT_ENV_INTERFACE "mmc" +#define FAT_ENV_FILE "uboot.env" +#define FAT_ENV_DEVICE_AND_PART "0" +#define CONFIG_ENV_SIZE0x4000 #endif #ifdef CONFIG_SYS_USE_MMC -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/3] ARM: at91: sama5d3_xplained: save environment in a FAT file in MMC card
This patch will save U-Boot environment as a file: uboot.env, in FAT partition instead of saving it in raw sector of MMC card. This make us easier to manage the environment file. Signed-off-by: Josh Wu --- include/configs/sama5d3_xplained.h | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/include/configs/sama5d3_xplained.h b/include/configs/sama5d3_xplained.h index d5588b1..a697035 100644 --- a/include/configs/sama5d3_xplained.h +++ b/include/configs/sama5d3_xplained.h @@ -169,13 +169,15 @@ "bootz 0x2200 - 0x2100" #elif CONFIG_SYS_USE_MMC /* bootstrap + u-boot + env in sd card */ -#define CONFIG_ENV_IS_IN_MMC -#define CONFIG_ENV_OFFSET 0x2000 -#define CONFIG_ENV_SIZE0x1000 +#define CONFIG_ENV_IS_IN_FAT +#define CONFIG_FAT_WRITE +#define FAT_ENV_INTERFACE "mmc" +#define FAT_ENV_FILE "uboot.env" +#define FAT_ENV_DEVICE_AND_PART"0" +#define CONFIG_ENV_SIZE0x4000 #define CONFIG_BOOTCOMMAND "fatload mmc 0:1 0x2100 at91-sama5d3_xplained.dtb; " \ "fatload mmc 0:1 0x2200 zImage; " \ "bootz 0x2200 - 0x2100" -#define CONFIG_SYS_MMC_ENV_DEV 0 #else #define CONFIG_ENV_IS_NOWHERE #endif -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 0/3] ARM: at91: save mmc environment in a FAT file instead of some sectors
I sent these patches days ago with other patches which refactor SAMA5 common configuration files, see URL: http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/203128/focus=203182 Since the patches which refactor SAMA5 common configuration files is rejected. So this time I only send the patches which only convert the mmc environment to FAT file. Josh Wu (3): ARM: at91: sama5d3_xplained: save environment in a FAT file in MMC card ARM: at91: sama5d3xek: save enviroment as a FAT file in MMC card ARM: at91: at91sam9x5: save environment to a FAT file in MMC card include/configs/at91sam9x5ek.h | 11 ++- include/configs/sama5d3_xplained.h | 10 ++ include/configs/sama5d3xek.h | 10 ++ 3 files changed, 18 insertions(+), 13 deletions(-) -- 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] usb: common: provide a _weak board_usb_cleanup() function
This patch implement _weak function for board_usb_cleanup.
This function (usb_board_cleanup) implementation is board-specific
feature.
board_usb_cleanup function can be used to clean up after failed
board-specific USB initialization.
Signed-off-by: Inha Song
---
common/usb.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/common/usb.c b/common/usb.c
index 736cd9f..fbb4495 100644
--- a/common/usb.c
+++ b/common/usb.c
@@ -1063,4 +1063,10 @@ int board_usb_init(int index, enum usb_init_type init)
{
return 0;
}
+
+__weak
+int board_usb_cleanup(int index, enum usb_init_type init)
+{
+ return 0;
+}
/* EOF */
--
2.0.0.390.gcb682f8
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] usb: invoke board specific USB cleanup interface
This patch invoke board-specific USB cleanup (board_usb_cleanup) interface. Signed-off-by: Inha Song --- common/cmd_dfu.c | 1 + common/cmd_thordown.c | 1 + common/cmd_usb_mass_storage.c | 1 + 3 files changed, 3 insertions(+) diff --git a/common/cmd_dfu.c b/common/cmd_dfu.c index e975abe..161d38b 100644 --- a/common/cmd_dfu.c +++ b/common/cmd_dfu.c @@ -68,6 +68,7 @@ static int do_dfu(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) } exit: g_dnl_unregister(); + board_usb_cleanup(controller_index, USB_INIT_DEVICE); done: dfu_free_entities(); diff --git a/common/cmd_thordown.c b/common/cmd_thordown.c index 8ed1dc6..436b7f5 100644 --- a/common/cmd_thordown.c +++ b/common/cmd_thordown.c @@ -56,6 +56,7 @@ int do_thor_down(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) exit: g_dnl_unregister(); + board_usb_cleanup(controller_index, USB_INIT_DEVICE); done: dfu_free_entities(); diff --git a/common/cmd_usb_mass_storage.c b/common/cmd_usb_mass_storage.c index 2c879ea..53a765e 100644 --- a/common/cmd_usb_mass_storage.c +++ b/common/cmd_usb_mass_storage.c @@ -154,6 +154,7 @@ int do_usb_mass_storage(cmd_tbl_t *cmdtp, int flag, } exit: g_dnl_unregister(); + board_usb_cleanup(controller_index, USB_INIT_DEVICE); return CMD_RET_SUCCESS; } -- 2.0.0.390.gcb682f8 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/2] Invoke board specific board_usb_cleanup function
This patches invoke board-specific usb cleanup interface (board_usb_cleanup) After USB initalization. Inha Song (2): usb: common: provide a _weak board_usb_cleanup() function usb: invoke board specific USB cleanup interface common/cmd_dfu.c | 1 + common/cmd_thordown.c | 1 + common/cmd_usb_mass_storage.c | 1 + common/usb.c | 6 ++ 4 files changed, 9 insertions(+) -- 2.0.0.390.gcb682f8 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH] dm:spi:fsl_qspi add DM support
Hi Peng,
On 17 January 2015 at 11:29, Peng Fan wrote:
> Hi Simon ,Jagan
>
> This patch is based on git://git.denx.de/u-boot-spi.git master branch,
> since some fsl_qspi's new feature is still in this git repo and have
> not been merged to mainline.
> I saw Simon sent out a new patch that remove the per_child_auto_alloc_size
> from the platforms' driver code and move it to spi uclass driver. In
> this patch I do not remove it, since this is a RFC version, and Jagan's
> spi git repo still has it. I can remove it in formal version if needed.
> Please take your time to review and comment this patch.
Appreciate for your work on adding dm on fsl-qspi.
But, I'm sending v2 RFC for spi-nor stuff where your driver be part of that
instead of drivers/spi - I'm planning to send it in this MW.
My plan is we review this dm stuff but in anyway if the new spi-nor is been
merged you'r driver needs to move on spi-nor with relevant changes.
Comments?
> This patch adds DM support for fsl_qspi driver, the DM part needs
> device tree support.
>
> Partial of the original driver code is reused, such as the AHB part,
> the LUT initialization and etc. The driver now supports new DM and original
> driver by define "CONFIG_DM_SPI". Until device tree is integrated, the
> original part can be discarded.
>
> The driver code file is now as following:
> "
>
> Common code that needs both by DM or original driver code.
>
> #if defined(CONFIG_DM_SPI)
>
> DM part
>
> #else
>
> Original driver code
>
> #endif
> "
>
> In DM part, some reconstruction is done. A fsl_qspi_runcmd is included to
> simplify the code, but not the original qspi_op_s. fsl_qspi_get_seqid
> is included to get seqid, but not hardcoded in original qspi_op_s.
>
> Signed-off-by: Peng Fan
> ---
> drivers/spi/fsl_qspi.c | 420
> +++--
> drivers/spi/fsl_qspi.h | 1 +
> 2 files changed, 405 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/spi/fsl_qspi.c b/drivers/spi/fsl_qspi.c
> index 5e0b069..ee151b3 100644
> --- a/drivers/spi/fsl_qspi.c
> +++ b/drivers/spi/fsl_qspi.c
> @@ -13,6 +13,13 @@
> #include
> #include "fsl_qspi.h"
>
> +#ifdef CONFIG_DM_SPI
> +#include
> +#include
> +#include
> +#include
> +#endif
> +
> #define RX_BUFFER_SIZE 0x80
> #ifdef CONFIG_MX6SX
> #define TX_BUFFER_SIZE 0x200
> @@ -71,27 +78,41 @@
> #define qspi_write32 out_be32
> #endif
>
> -static unsigned long spi_bases[] = {
> - QSPI0_BASE_ADDR,
> -#ifdef CONFIG_MX6SX
> - QSPI1_BASE_ADDR,
> -#endif
> -};
> +#ifdef CONFIG_DM_SPI
> +DECLARE_GLOBAL_DATA_PTR;
> +#define QUADSPI_AHBMAP_BANK_MAXSIZESZ_64M
>
> -static unsigned long amba_bases[] = {
> - QSPI0_AMBA_BASE,
> -#ifdef CONFIG_MX6SX
> - QSPI1_AMBA_BASE,
> -#endif
> +struct fsl_qspi_platdata {
> + u32 max_hz;
> + u32 reg_base;
> + u32 amba_base;
> + u32 flash_num;
> };
>
> struct fsl_qspi {
> + u32 reg_base;
> + u32 amba_base;
> + size_t cmd_len;
> + u8 cmd_buf[32];
> + size_t data_len;
> + int qspi_is_init;
> + size_t flash_size;
> + u32 bank_memmap_phy[4];
> + int cs;
> + u32 sf_addr;
> + int flash_num;
> + u8 cur_seqid;
> + u32 freq;
> +};
> +#else
> +struct fsl_qspi {
> struct spi_slave slave;
> unsigned long reg_base;
> unsigned long amba_base;
> u32 sf_addr;
> u8 cur_seqid;
> };
> +#endif
>
> /* QSPI support swapping the flash read/write data
> * in hardware for LS102xA, but not for VF610 */
> @@ -104,11 +125,6 @@ static inline u32 qspi_endian_xchg(u32 data)
> #endif
> }
>
> -static inline struct fsl_qspi *to_qspi_spi(struct spi_slave *slave)
> -{
> - return container_of(slave, struct fsl_qspi, slave);
> -}
> -
> static void qspi_set_lut(struct fsl_qspi *qspi)
> {
> struct fsl_qspi_regs *regs = (struct fsl_qspi_regs *)qspi->reg_base;
> @@ -367,6 +383,377 @@ static void qspi_init_ahb_read(struct fsl_qspi_regs
> *regs)
> }
> #endif
>
> +#ifdef CONFIG_DM_SPI
> +/* Get the SEQID for the command */
> +static int fsl_qspi_get_seqid(struct fsl_qspi *q, u8 cmd)
> +{
> + switch (cmd) {
> + case QSPI_CMD_FAST_READ:
> + case QSPI_CMD_FAST_READ_4B:
> + return SEQID_FAST_READ;
> + case QSPI_CMD_WREN:
> + return SEQID_WREN;
> + case QSPI_CMD_RDSR:
> + return SEQID_RDSR;
> + case QSPI_CMD_SE:
> + return SEQID_SE;
> + case QSPI_CMD_PP:
> + case QSPI_CMD_PP_4B:
> + return SEQID_PP;
> + case QSPI_CMD_RDID:
> + return SEQID_RDID;
> + case QSPI_CMD_BE_4K:
> + return SEQID_BE_4K;
> +#ifdef CONFIG_SPI_FLASH_BAR
> +
Re: [U-Boot] [PATCH] ARM: atmel: at91sam9m10g45ek: enable SPL
Hello Bo, added Simon to cc ... Am 19.01.2015 02:41, schrieb Bo Shen: Hi Andreas, On 01/16/2015 06:16 PM, Andreas Bießmann wrote: Hi Bo, On 01/16/2015 10:30 AM, Bo Shen wrote: On 01/16/2015 05:10 PM, Andreas Bießmann wrote: On 01/16/2015 03:53 AM, Bo Shen wrote: --- a/arch/arm/cpu/arm926ejs/at91/Makefile +++ b/arch/arm/cpu/arm926ejs/at91/Makefile @@ -25,5 +25,9 @@ obj-y+= reset.o obj-y+= timer.o ifndef CONFIG_SKIP_LOWLEVEL_INIT +ifdef CONFIG_SPL_BUILD +obj-y+= spl_lowlevel_init.o +else obj-y+= lowlevel_init.o endif +endif I'm fine with having two variants of lowlevel_init for a time, but we should consolidate this and use C-style initialisation of SDRAM and stuff for the other armv5 at91 devices in future. AFAIK the a/a/c/arm926ejs/at91/lowlevel_init.S is mainly used for NOR Flash boots, so using the SPL code (but not necessarily the two binary mechanism) for the NOR Flash boots in future is appreciated. OK, when all the arm9 at91 related board has SPL support, then I will do this. Can we achieve this in this MW? I will try, but not sure. As I don't have this kind of board :( I need to check whether we still have this kind of board. +ENTRY(lowlevel_init) +/* + * Setup a temporary stack + */ +ldrsp, =CONFIG_SYS_INIT_SP_ADDR +bicsp, sp, #7 /* 8-byte alignment for ABI compliance */ + +ldrr9, =gdata I remember some patches removing the SPL gdata stuff, is that true? Thanks. Yes, just search for it, the following patch do this. http://patchwork.ozlabs.org/patch/423789/ (arm: Reduce the scope of lowlevel_init()) I think we should use the function provided there. What do you think? OK. I will do it in next version. Thanks. Hmm... looking into this patch [1] ... it says: +* Call the very early init function. This should do only the +* absolute bare minimum to get started. It should not: +* +* - set up DRAM +* - use global_data +* - clear BSS +* - try to start a console but if we have small init ram for SPL (like on the sam9260 with 4k sram) we should init here SDRAM, so we could set bss and stack into RAM in board_init_f, which is called after this function. So we should rework the comment here ... or? bye, Heiko [1] http://patchwork.ozlabs.org/patch/423789/ -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] dm:gpio:mxc get configuration from dtb
This patch supports getting gpios' configuration from dtb.
CONFIG_OF_CONTROL is used to indicated which part is for device tree,
and which is not.
This patch is already tested on mx6sxsabresd board. Since device tree
has not been upstreamed, if want to test this patch. The followings
need to be done.
+ pieces of code does not gpio_request when using gpio_direction_xxx and
etc, need to request gpio.
+ move the gpio settings from board_early_init_f to board_init
+ define CONFIG_DM ,CONFIG_DM_GPIO and CONFIG_OF_CONTROL
+ Add device tree file and do related configuration in
`make ARCH=arm menuconfig`
Signed-off-by: Peng Fan
---
drivers/gpio/mxc_gpio.c | 76 +
1 file changed, 76 insertions(+)
diff --git a/drivers/gpio/mxc_gpio.c b/drivers/gpio/mxc_gpio.c
index 8bb9e39..8603068 100644
--- a/drivers/gpio/mxc_gpio.c
+++ b/drivers/gpio/mxc_gpio.c
@@ -14,6 +14,10 @@
#include
#include
#include
+#ifdef CONFIG_OF_CONTROL
+#include
+DECLARE_GLOBAL_DATA_PTR;
+#endif
enum mxc_gpio_direction {
MXC_GPIO_DIRECTION_IN,
@@ -258,6 +262,7 @@ static const struct dm_gpio_ops gpio_mxc_ops = {
.get_function = mxc_gpio_get_function,
};
+#ifndef CONFIG_OF_CONTROL
static const struct mxc_gpio_plat mxc_plat[] = {
{ (struct gpio_regs *)GPIO1_BASE_ADDR },
{ (struct gpio_regs *)GPIO2_BASE_ADDR },
@@ -274,6 +279,7 @@ static const struct mxc_gpio_plat mxc_plat[] = {
{ (struct gpio_regs *)GPIO7_BASE_ADDR },
#endif
};
+#endif
static int mxc_gpio_probe(struct udevice *dev)
{
@@ -283,7 +289,19 @@ static int mxc_gpio_probe(struct udevice *dev)
int banknum;
char name[18], *str;
+#ifdef CONFIG_OF_CONTROL
+ /*
+* In dts file add:
+* aliases {
+* gpio0 = &gpio1;
+* gpio1 = &gpio2;
+* .
+* };
+* Then set banknum accoring dev's seq number. */
+ banknum = dev->seq;
+#else
banknum = plat - mxc_plat;
+#endif
sprintf(name, "GPIO%d_", banknum + 1);
str = strdup(name);
if (!str)
@@ -295,14 +313,71 @@ static int mxc_gpio_probe(struct udevice *dev)
return 0;
}
+#ifdef CONFIG_OF_CONTROL
+static int mxc_gpio_bind(struct udevice *device)
+{
+ struct mxc_gpio_plat *plat = device->platdata;
+ struct gpio_regs *ctrl;
+
+ if (plat)
+ return 0;
+ /*
+* In the dts file, gpiox bank are as following:
+* gpio1: gpio@0209c000 {
+* compatible = "fsl,imx6q-gpio", "fsl,imx35-gpio";
+* reg = <0x0209c000 0x4000>;
+* interrupts = <0 66 0x04 0 67 0x04>;
+* gpio-controller;
+* #gpio-cells = <2>;
+* interrupt-controller;
+* #interrupt-cells = <2>;
+* };
+*
+* gpio2: gpio@020a {
+* compatible = "fsl,imx6q-gpio", "fsl,imx35-gpio";
+* reg = <0x020a 0x4000>;
+* interrupts = <0 68 0x04 0 69 0x04>;
+* gpio-controller;
+* #gpio-cells = <2>;
+* interrupt-controller;
+* #interrupt-cells = <2>;
+* };
+*
+* gpio1 is the 1st bank, gpio2 is the 2nd bank and gpio3
+*/
+
+ ctrl = (struct gpio_regs *)fdtdec_get_addr(gd->fdt_blob,
+ device->of_offset, "reg");
+ plat = calloc(1, sizeof(*plat));
+ if (!plat)
+ return -ENOMEM;
+
+ plat->regs = ctrl;
+
+ device->platdata = plat;
+
+ return 0;
+}
+
+static const struct udevice_id mxc_gpio_ids[] = {
+ { .compatible = "fsl,imx35-gpio" },
+ { }
+};
+#endif
+
U_BOOT_DRIVER(gpio_mxc) = {
.name = "gpio_mxc",
.id = UCLASS_GPIO,
.ops= &gpio_mxc_ops,
.probe = mxc_gpio_probe,
.priv_auto_alloc_size = sizeof(struct mxc_bank_info),
+#ifdef CONFIG_OF_CONTROL
+ .of_match = mxc_gpio_ids,
+ .bind = mxc_gpio_bind,
+#endif
};
+#ifndef CONFIG_OF_CONTROL
U_BOOT_DEVICES(mxc_gpios) = {
{ "gpio_mxc", &mxc_plat[0] },
{ "gpio_mxc", &mxc_plat[1] },
@@ -320,3 +395,4 @@ U_BOOT_DEVICES(mxc_gpios) = {
#endif
};
#endif
+#endif
--
1.8.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: atmel: at91sam9m10g45ek: enable SPL
Hello Bo, Am 19.01.2015 02:38, schrieb Bo Shen: Hi Heiko, On 01/16/2015 07:35 PM, Heiko Schocher wrote: Hello Bo Am 16.01.2015 03:53, schrieb Bo Shen: Supports boot up from NAND flash with software ECC eanbled. And supports boot up from SD/MMC card with FAT file system. As the boot from SD/MMC card with FAT file system, the BSS segment is too big to fit into SRAM, so, use the lds to put it into SDRAM. So, we need to initialize the SDRAM as soon as possible. Borrow the low level init code from for this purpose. As there is a little change, which need lowlevel init, so also change taurus board based on at91sam9260, corvus board based on at91sam9g45. (CONFIG_SPL_STACK is replaced by CONFIG_SYS_INIT_SP_ADDR) Signed-off-by: Bo Shen --- arch/arm/Kconfig| 1 + arch/arm/cpu/arm926ejs/at91/Makefile| 4 ++ arch/arm/cpu/arm926ejs/at91/spl_lowlevel_init.S | 37 arch/arm/cpu/at91-common/spl_at91.c | 7 +-- arch/arm/cpu/at91-common/u-boot-spl-arm9.lds| 48 +++ board/atmel/at91sam9m10g45ek/at91sam9m10g45ek.c | 80 + configs/at91sam9m10g45ek_mmc_defconfig | 5 +- configs/at91sam9m10g45ek_nandflash_defconfig| 5 +- include/configs/at91sam9m10g45ek.h | 65 include/configs/corvus.h| 7 ++- include/configs/taurus.h| 7 ++- 11 files changed, 256 insertions(+), 10 deletions(-) create mode 100644 arch/arm/cpu/arm926ejs/at91/spl_lowlevel_init.S create mode 100644 arch/arm/cpu/at91-common/u-boot-spl-arm9.lds Acked-by: Heiko Schocher Thanks. but it does not boot on the corvus board ... please add this fix to your patch: diff --git a/include/configs/corvus.h b/include/configs/corvus.h index efc8ce5..dc25d95 100644 --- a/include/configs/corvus.h +++ b/include/configs/corvus.h @@ -90,7 +90,7 @@ #define CONFIG_SYS_SDRAM_SIZE 0x0800 #ifdef CONFIG_SPL_BUILD -#define CONFIG_SYS_INIT_SP_ADDR0x31 +#define CONFIG_SYS_INIT_SP_ADDR(16 * 1024) #else #define CONFIG_SYS_INIT_SP_ADDR \ (CONFIG_SYS_SDRAM_BASE + 4 * 1024 - GENERATED_GBL_DATA_SIZE) Tested your patch also on the taurus board, there it boots fine! so, after you fixed the corvus board, you can add my: Tested-by: Heiko Schocher Thanks, I will add this fix into next version. Thanks! Thanks! And one question ... [...] diff --git a/arch/arm/cpu/arm926ejs/at91/spl_lowlevel_init.S b/arch/arm/cpu/arm926ejs/at91/spl_lowlevel_init.S new file mode 100644 index 000..f1b2ec9 --- /dev/null +++ b/arch/arm/cpu/arm926ejs/at91/spl_lowlevel_init.S @@ -0,0 +1,37 @@ +/* + * A lowlevel_init function that sets up the stack to call a C function to + * perform further init. + * + * (C) Copyright 2010 + * Texas Instruments, + * + * Author : + *Aneesh V + * + * SPDX-License-Identifier:GPL-2.0+ + */ + +#include +#include +#include + +ENTRY(lowlevel_init) +/* + * Setup a temporary stack + */ +ldrsp, =CONFIG_SYS_INIT_SP_ADDR Could we use here a new define (saying CONFIG_SYS_INIT_SP_LOWLEVEL)? Benefit would be, we can setup first the stack in sram, and after RAM init, which is done with your patch very early, we can set the stack with CONFIG_SYS_INIT_SP_ADDR into RAM! With using CONFIG_SYS_INIT_SP_ADDR here, the stack gets set twice to CONFIG_SYS_INIT_SP_ADDR ... I just try to get SPL on an atsam9260 based board working with only 4k sram ... so it would be nice to have stack also optionally in RAM ... but we have problems with the debugger adapter on the board ... so I have to wait some more days to try this part ... This just for the at91sam9260 based boards, not for others. Or else, we also need to add this definition for other boards. Can you do the following check? #ifdef CONFIG_SYS_INIT_SP_LOWLEVEL ldrsp, =CONFIG_SYS_INIT_SP_LOWLEVEL #else ldrsp, =CONFIG_SYS_INIT_SP_ADDR #endif If it is acceptable, can you add through your patches, as I my patch nowhere will use it. Or we check if "CONFIG_SYS_INIT_SP_LOWLEVEL" is defined, if not we set default to: #define CONFIG_SYS_INIT_SP_LOWLEVEL CONFIG_SYS_INIT_SP_ADDR so, something like: diff --git a/arch/arm/cpu/arm926ejs/at91/spl_lowlevel_init.S b/arch/arm/cpu/arm926ejs/at91/spl_lowlevel_init.S index f1b2ec9..ed9adc7 100644 --- a/arch/arm/cpu/arm926ejs/at91/spl_lowlevel_init.S +++ b/arch/arm/cpu/arm926ejs/at91/spl_lowlevel_init.S @@ -15,11 +15,15 @@ #include #include +#ifndef CONFIG_SYS_INIT_SP_ADDR_LOWLEVEL +#define CONFIG_SYS_INIT_SP_ADDR_LOWLEVEL CONFIG_SYS_INIT_SP_ADDR +#endif + ENTRY(lowlevel_init) /* * Setup a temporary stack */ - ldr sp, =CONFIG_SYS_INIT_SP_ADDR + ldr sp, =CONFIG_SYS_INIT_SP_ADDR_LOWLEVEL bic sp, sp, #7 /* 8-byte alignment for ABI compliance */ ldr r9, =gdata so we do
Re: [U-Boot] [linux-sunxi] [u-boot 2/2] sun5i: bump DEBE priority (useful on a10s only)
On Sun, 04 Jan 2015 20:49:38 +0100 Hans de Goede wrote: > Hi, > > On 04-01-15 20:19, Michal Suchanek wrote: > >Setting magic 'reserved' hpcr bit on sun5i DEBE seems required for > >smooth HDMI scanout of large frambuffer (eg. 1080p). > > > >This fix comes at the cost of some overall memory bandwidth so it > >might be appropriate to detect a10s and only apply there (and not a13). > > Hmm, Sairhei is the expert on this, adding him to the Cc. Sairhei, what > do you think of the proposed change ? I don't have A10s hardware, so have no idea and can't test anything myself. It would be great to have a better description of what exactly is happening before the patch. And precisely how the patch is helping. A description of the test setup and benchmark numbers would be appreciated. And it would be perfect if somebody else could reproduce the test and confirm the results. I may try to check A20 with the bus width artificially reduced to 16 bits (not a totally unrealistic configuration, since A20-OLinuXino-LIME board exists). If sun5i and sun7i are similar enough, then the magic reserved bit may have some effect there too. But that's a different hardware either way. -- Best regards, Siarhei Siamashka ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 3/7] video: Add support for SSD2828 (parallel LCD to MIPI bridge)
SSD2828 can take pixel data coming from a parallel LCD interface and translate it on the fly into MIPI DSI interface for driving a MIPI compatible TFT display. SSD2828 is configured over SPI interface, which may or may not have MISO pin wired up on some hardware. So a write-only SPI mode also has to be supported. The SSD2828 support code is implemented as a utility function and needs to be called from real display drivers, which are responsible for driving parallel LCD hardware in front of the video pipeline. The usage instructions are provided as comments in the header file. Signed-off-by: Siarhei Siamashka --- Changes in v2: - Add missing static keyword for 'construct_pll_config' function - Fix 'mipi_dsi_loosely_packed_pixel_format' handling bug (swapped roles of SSD2828_VIDEO_PIXEL_FORMAT_18BPP_PACKED and SSD2828_VIDEO_PIXEL_FORMAT_18BPP_LOOSELY_PACKED) - Add the Kconfig option to enable SSD2828 - Move the Kconfig parts with GPIO pins settings from 'sunxi' to 'video', as requested by Hans de Goede. - Add Kconfig option for 'tx_clk' selection drivers/video/Kconfig | 70 drivers/video/Makefile | 1 + drivers/video/ssd2828.c | 422 drivers/video/ssd2828.h | 123 ++ 4 files changed, 616 insertions(+) create mode 100644 drivers/video/ssd2828.c create mode 100644 drivers/video/ssd2828.h diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig index fdbf3f6..ec14a37 100644 --- a/drivers/video/Kconfig +++ b/drivers/video/Kconfig @@ -6,3 +6,73 @@ config VIDEO_X86 Turn on this option to enable a very simple driver which uses vesa to discover the video mode and then provides a frame buffer for use by U-Boot. + +config VIDEO_LCD_SSD2828 + bool "SSD2828 bridge chip" + default n + ---help--- + Support for the SSD2828 bridge chip, which can take pixel data coming + from a parallel LCD interface and translate it on the fly into MIPI DSI + interface for driving a MIPI compatible LCD panel. It uses SPI for + configuration. + +config VIDEO_LCD_SSD2828_TX_CLK + int "SSD2828 TX_CLK frequency (in MHz)" + depends on VIDEO_LCD_SSD2828 + ---help--- + The frequency of the crystal, which is clocking SSD2828. It may be + anything in the 8MHz-30MHz range and the exact value should be + retrieved from the board schematics. Or in the case of Allwinner + hardware, it can be usually found as 'lcd_xtal_freq' variable in + FEX files. + +config VIDEO_LCD_SSD2828_RESET + string "RESET pin of SSD2828" + depends on VIDEO_LCD_SSD2828 + default "" + ---help--- + The reset pin of SSD2828 chip. This takes a string in the format + understood by 'name_to_gpio' function, e.g. PH1 for pin 1 of port H. + +config VIDEO_LCD_SPI_CS + string "SPI CS pin for LCD related config job" + depends on VIDEO_LCD_SSD2828 + default "" + ---help--- + This is one of the SPI communication pins, involved in setting up a + working LCD configuration. The exact role of SPI may differ for + different hardware setups. The option takes a string in the format + understood by 'name_to_gpio' function, e.g. PH1 for pin 1 of port H. + +config VIDEO_LCD_SPI_SCLK + string "SPI SCLK pin for LCD related config job" + depends on VIDEO_LCD_SSD2828 + default "" + ---help--- + This is one of the SPI communication pins, involved in setting up a + working LCD configuration. The exact role of SPI may differ for + different hardware setups. The option takes a string in the format + understood by 'name_to_gpio' function, e.g. PH1 for pin 1 of port H. + +config VIDEO_LCD_SPI_MOSI + string "SPI MOSI pin for LCD related config job" + depends on VIDEO_LCD_SSD2828 + default "" + ---help--- + This is one of the SPI communication pins, involved in setting up a + working LCD configuration. The exact role of SPI may differ for + different hardware setups. The option takes a string in the format + understood by 'name_to_gpio' function, e.g. PH1 for pin 1 of port H. + +config VIDEO_LCD_SPI_MISO + string "SPI MISO pin for LCD related config job (optional)" + depends on VIDEO_LCD_SSD2828 + default "" + ---help--- + This is one of the SPI communication pins, involved in setting up a + working LCD configuration. The exact role of SPI may differ for + different hardware setups. If wired up, this pin may provide additional + useful functionality. Such as bi-directional communication with the + hardware and LCD panel id retrieval (if the panel can report it). The + option takes a string in the format understood by 'name_to_gpio' + function, e.g. PH1 for pin 1 of port H. diff --git a/drivers/video/Makefile b/drivers/video/Makefile index 42b1eaa..3629868
[U-Boot] [PATCH v2 2/7] include: Add header file with MIPI DSI constants from linux 3.18
The file, originally named "include/video/mipi_display.h", is taken from
linux 3.18 (commit b2776bf7149bddd1f4161f14f79520f17fc1d71d).
It provides MIPI DSI constants for DCS commands, which are needed to
implement support for SSD2828 in u-boot.
Signed-off-by: Siarhei Siamashka
---
Changes in v2:
- Update commmit message to mention the exact linux kernel version,
commit hash and the original name of the header file.
include/mipi_display.h | 130 +
1 file changed, 130 insertions(+)
create mode 100644 include/mipi_display.h
diff --git a/include/mipi_display.h b/include/mipi_display.h
new file mode 100644
index 000..ddcc8ca
--- /dev/null
+++ b/include/mipi_display.h
@@ -0,0 +1,130 @@
+/*
+ * Defines for Mobile Industry Processor Interface (MIPI(R))
+ * Display Working Group standards: DSI, DCS, DBI, DPI
+ *
+ * Copyright (C) 2010 Guennadi Liakhovetski
+ * Copyright (C) 2006 Nokia Corporation
+ * Author: Imre Deak
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#ifndef MIPI_DISPLAY_H
+#define MIPI_DISPLAY_H
+
+/* MIPI DSI Processor-to-Peripheral transaction types */
+enum {
+ MIPI_DSI_V_SYNC_START = 0x01,
+ MIPI_DSI_V_SYNC_END = 0x11,
+ MIPI_DSI_H_SYNC_START = 0x21,
+ MIPI_DSI_H_SYNC_END = 0x31,
+
+ MIPI_DSI_COLOR_MODE_OFF = 0x02,
+ MIPI_DSI_COLOR_MODE_ON = 0x12,
+ MIPI_DSI_SHUTDOWN_PERIPHERAL= 0x22,
+ MIPI_DSI_TURN_ON_PERIPHERAL = 0x32,
+
+ MIPI_DSI_GENERIC_SHORT_WRITE_0_PARAM= 0x03,
+ MIPI_DSI_GENERIC_SHORT_WRITE_1_PARAM= 0x13,
+ MIPI_DSI_GENERIC_SHORT_WRITE_2_PARAM= 0x23,
+
+ MIPI_DSI_GENERIC_READ_REQUEST_0_PARAM = 0x04,
+ MIPI_DSI_GENERIC_READ_REQUEST_1_PARAM = 0x14,
+ MIPI_DSI_GENERIC_READ_REQUEST_2_PARAM = 0x24,
+
+ MIPI_DSI_DCS_SHORT_WRITE= 0x05,
+ MIPI_DSI_DCS_SHORT_WRITE_PARAM = 0x15,
+
+ MIPI_DSI_DCS_READ = 0x06,
+
+ MIPI_DSI_SET_MAXIMUM_RETURN_PACKET_SIZE = 0x37,
+
+ MIPI_DSI_END_OF_TRANSMISSION= 0x08,
+
+ MIPI_DSI_NULL_PACKET= 0x09,
+ MIPI_DSI_BLANKING_PACKET= 0x19,
+ MIPI_DSI_GENERIC_LONG_WRITE = 0x29,
+ MIPI_DSI_DCS_LONG_WRITE = 0x39,
+
+ MIPI_DSI_LOOSELY_PACKED_PIXEL_STREAM_YCBCR20= 0x0c,
+ MIPI_DSI_PACKED_PIXEL_STREAM_YCBCR24= 0x1c,
+ MIPI_DSI_PACKED_PIXEL_STREAM_YCBCR16= 0x2c,
+
+ MIPI_DSI_PACKED_PIXEL_STREAM_30 = 0x0d,
+ MIPI_DSI_PACKED_PIXEL_STREAM_36 = 0x1d,
+ MIPI_DSI_PACKED_PIXEL_STREAM_YCBCR12= 0x3d,
+
+ MIPI_DSI_PACKED_PIXEL_STREAM_16 = 0x0e,
+ MIPI_DSI_PACKED_PIXEL_STREAM_18 = 0x1e,
+ MIPI_DSI_PIXEL_STREAM_3BYTE_18 = 0x2e,
+ MIPI_DSI_PACKED_PIXEL_STREAM_24 = 0x3e,
+};
+
+/* MIPI DSI Peripheral-to-Processor transaction types */
+enum {
+ MIPI_DSI_RX_ACKNOWLEDGE_AND_ERROR_REPORT= 0x02,
+ MIPI_DSI_RX_END_OF_TRANSMISSION = 0x08,
+ MIPI_DSI_RX_GENERIC_SHORT_READ_RESPONSE_1BYTE = 0x11,
+ MIPI_DSI_RX_GENERIC_SHORT_READ_RESPONSE_2BYTE = 0x12,
+ MIPI_DSI_RX_GENERIC_LONG_READ_RESPONSE = 0x1a,
+ MIPI_DSI_RX_DCS_LONG_READ_RESPONSE = 0x1c,
+ MIPI_DSI_RX_DCS_SHORT_READ_RESPONSE_1BYTE = 0x21,
+ MIPI_DSI_RX_DCS_SHORT_READ_RESPONSE_2BYTE = 0x22,
+};
+
+/* MIPI DCS commands */
+enum {
+ MIPI_DCS_NOP= 0x00,
+ MIPI_DCS_SOFT_RESET = 0x01,
+ MIPI_DCS_GET_DISPLAY_ID = 0x04,
+ MIPI_DCS_GET_RED_CHANNEL= 0x06,
+ MIPI_DCS_GET_GREEN_CHANNEL = 0x07,
+ MIPI_DCS_GET_BLUE_CHANNEL = 0x08,
+ MIPI_DCS_GET_DISPLAY_STATUS = 0x09,
+ MIPI_DCS_GET_POWER_MODE = 0x0A,
+ MIPI_DCS_GET_ADDRESS_MODE = 0x0B,
+ MIPI_DCS_GET_PIXEL_FORMAT = 0x0C,
+ MIPI_DCS_GET_DISPLAY_MODE = 0x0D,
+ MIPI_DCS_GET_SIGNAL_MODE= 0x0E,
+ MIPI_DCS_GET_DIAGNOSTIC_RESULT = 0x0F,
+ MIPI_DCS_ENTER_SLEEP_MODE = 0x10,
+ MIPI_DCS_EXIT_SLEEP_MODE= 0x11,
+ MIPI_DCS_ENTER_PARTIAL_MODE = 0x12,
+ MIPI_DCS_ENTER_NORMAL_MODE = 0x13,
+ MIPI_DCS_EXIT_INVERT_MODE = 0x20,
+ MIPI_DCS_ENTER_INVERT_MODE = 0x21,
+ MIPI_DCS_SET_GAMMA_
[U-Boot] [PATCH v2 5/7] sun6i: Add LCD display support for MSI Primo81 tablet
The MSI Primo81 tablet has B079XAN01/LP079X01 7.85" 768x1024 IPS MIPI display, connected to the parallel LCD interface via SSD2828 bridge chip. The panel has 18-bit color depth and needs dithering, in spite of having RGB data delivered from A31s to SSD2828 using 24-bit arrangement. Signed-off-by: Siarhei Siamashka --- Changes in v2: - Set CONFIG_VIDEO_LCD_SSD2828_TX_CLK option to 27MHz instead of relying on the hardcoded value in C sources. configs/MSI_Primo81_defconfig | 10 ++ 1 file changed, 10 insertions(+) diff --git a/configs/MSI_Primo81_defconfig b/configs/MSI_Primo81_defconfig index b4b0f6d..5fc0289 100644 --- a/configs/MSI_Primo81_defconfig +++ b/configs/MSI_Primo81_defconfig @@ -1,6 +1,16 @@ CONFIG_SPL=y CONFIG_SYS_EXTRA_OPTIONS="" CONFIG_FDTFILE="sun6i-a31s-primo81.dtb" +CONFIG_VIDEO_LCD_MODE="x:768,y:1024,depth:18,pclk_khz:66000,le:56,ri:60,up:30,lo:36,hs:64,vs:50,sync:3,vmode:0" +CONFIG_VIDEO_LCD_PANEL_MIPI_4_LANE_513_MBPS_VIA_SSD2828=y +CONFIG_VIDEO_LCD_SSD2828_TX_CLK=27 +CONFIG_VIDEO_LCD_SSD2828_RESET="PA26" +CONFIG_VIDEO_LCD_SPI_CS="PH9" +CONFIG_VIDEO_LCD_SPI_SCLK="PH10" +CONFIG_VIDEO_LCD_SPI_MOSI="PH11" +CONFIG_VIDEO_LCD_SPI_MISO="PH12" +CONFIG_VIDEO_LCD_BL_EN="PA25" +CONFIG_VIDEO_LCD_BL_PWM="PH13" CONFIG_USB_KEYBOARD=n +S:CONFIG_ARM=y +S:CONFIG_ARCH_SUNXI=y -- 2.0.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 4/7] video: sunxi: Hook up SSD2828 with the sunxi video driver
Convert GPIO names from Kconfig strings into pin numbers for
the 'ssd2828_config' struct. Add SSD2828 initialization between
enabling the parallel LCD interface and turning on the backlight.
Signed-off-by: Siarhei Siamashka
---
Changes in v2:
- The 'sunxi' Kconfig change now only has LCD panel option
addition (the rest had been moved to the 'video' Kconfig).
- Handle SSD2828 initialization directly in 'sunxi_display.c'
without the extra 'sunxi_lcd_panel.c' source file, because
the SSD2828 glue code is small enough.
- Change from 'sunxi_name_to_gpio' to 'name_to_gpio'
board/sunxi/Kconfig | 7 +++
drivers/video/sunxi_display.c | 38 ++
2 files changed, 45 insertions(+)
diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig
index 6a4d764..747e56e 100644
--- a/board/sunxi/Kconfig
+++ b/board/sunxi/Kconfig
@@ -387,6 +387,13 @@ config VIDEO_LCD_PANEL_LVDS
bool "Generic lvds interface LCD panel"
select VIDEO_LCD_IF_LVDS
+config VIDEO_LCD_PANEL_MIPI_4_LANE_513_MBPS_VIA_SSD2828
+ bool "MIPI 4-lane, 513Mbps LCD panel via SSD2828 bridge chip"
+ select VIDEO_LCD_SSD2828
+ select VIDEO_LCD_IF_PARALLEL
+ ---help---
+7.85" 768x1024 LCD panels, such as LG LP079X01 or AUO B079XAN01.0
+
endchoice
diff --git a/drivers/video/sunxi_display.c b/drivers/video/sunxi_display.c
index d92dfa8..c7d237b 100644
--- a/drivers/video/sunxi_display.c
+++ b/drivers/video/sunxi_display.c
@@ -20,6 +20,7 @@
#include
#include
#include "videomodes.h"
+#include "ssd2828.h"
DECLARE_GLOBAL_DATA_PTR;
@@ -826,6 +827,40 @@ static void sunxi_vga_external_dac_enable(void)
}
#endif /* CONFIG_VIDEO_VGA_VIA_LCD */
+#ifdef CONFIG_VIDEO_LCD_SSD2828
+static int sunxi_ssd2828_init(const struct ctfb_res_modes *mode)
+{
+ struct ssd2828_config cfg = {
+ .csx_pin = name_to_gpio(CONFIG_VIDEO_LCD_SPI_CS),
+ .sck_pin = name_to_gpio(CONFIG_VIDEO_LCD_SPI_SCLK),
+ .sdi_pin = name_to_gpio(CONFIG_VIDEO_LCD_SPI_MOSI),
+ .sdo_pin = name_to_gpio(CONFIG_VIDEO_LCD_SPI_MISO),
+ .reset_pin = name_to_gpio(CONFIG_VIDEO_LCD_SSD2828_RESET),
+ .ssd2828_tx_clk_khz = CONFIG_VIDEO_LCD_SSD2828_TX_CLK * 1000,
+ .ssd2828_color_depth = 24,
+#ifdef CONFIG_VIDEO_LCD_PANEL_MIPI_4_LANE_513_MBPS_VIA_SSD2828
+ .mipi_dsi_number_of_data_lanes = 4,
+ .mipi_dsi_bitrate_per_data_lane_mbps = 513,
+ .mipi_dsi_delay_after_exit_sleep_mode_ms = 100,
+ .mipi_dsi_delay_after_set_display_on_ms = 200
+#else
+#error MIPI LCD panel needs configuration parameters
+#endif
+ };
+
+ if (cfg.csx_pin == -1 || cfg.sck_pin == -1 || cfg.sdi_pin == -1) {
+ printf("SSD2828: SPI pins are not properly configured\n");
+ return 1;
+ }
+ if (cfg.reset_pin == -1) {
+ printf("SSD2828: Reset pin is not properly configured\n");
+ return 1;
+ }
+
+ return ssd2828_init(&cfg, mode);
+}
+#endif /* CONFIG_VIDEO_LCD_SSD2828 */
+
static void sunxi_engines_init(void)
{
sunxi_composer_init();
@@ -858,6 +893,9 @@ static void sunxi_mode_set(const struct ctfb_res_modes
*mode,
sunxi_lcdc_tcon0_mode_set(mode);
sunxi_composer_enable();
sunxi_lcdc_enable();
+#ifdef CONFIG_VIDEO_LCD_SSD2828
+ sunxi_ssd2828_init(mode);
+#endif
sunxi_lcdc_backlight_enable();
break;
case sunxi_monitor_vga:
--
2.0.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/7] sunxi: axp221: Add ELDO[1-3] support
And also add Kconfig option for selecting ELDO3 voltage. The reason
for having this option is that the Android kernel sets ELDO3 to
1.2V when powering up LCD in the case if 'lcd_if' configuration
variable is set to 6 (LCD_IF_EXT_DSI) in the FEX file. Most likely
to supply power for a SSD2828 chip.
However on the MSI Primo81 tablet, which is using this particular
'lcd_if = 6' setup for LCD, setting the ELDO3 voltage appears to
be unnecessary and it works regardless. Having no schematics of
this tablet, I can only guess that 1.2V is supplied to SSD2828
in some other way.
Signed-off-by: Siarhei Siamashka
---
Changes in v2:
- Avoid code duplication, as suggested by Anatolij Gustschin.
board/sunxi/board.c| 1 +
drivers/power/Kconfig | 10 ++
drivers/power/axp221.c | 33 +
include/axp221.h | 7 +++
4 files changed, 51 insertions(+)
diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index 7d6d075..6b19f75 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -189,6 +189,7 @@ void sunxi_board_init(void)
power_failed |= axp221_set_aldo1(CONFIG_AXP221_ALDO1_VOLT);
power_failed |= axp221_set_aldo2(CONFIG_AXP221_ALDO2_VOLT);
power_failed |= axp221_set_aldo3(CONFIG_AXP221_ALDO3_VOLT);
+ power_failed |= axp221_set_eldo(3, CONFIG_AXP221_ELDO3_VOLT);
#endif
printf("DRAM:");
diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
index e68e16b..f8f0239 100644
--- a/drivers/power/Kconfig
+++ b/drivers/power/Kconfig
@@ -63,3 +63,13 @@ config AXP221_ALDO3_VOLT
Set the voltage (mV) to program the axp221 aldo3 at, set to 0 to
disable aldo3. This is typically connected to VCC-PLL and AVCC and
must be set to 3V.
+
+config AXP221_ELDO3_VOLT
+ int "axp221 eldo3 voltage"
+ depends on AXP221_POWER
+ default 0
+ ---help---
+ Set the voltage (mV) to program the axp221 eldo3 at, set to 0 to
+ disable eldo3. On some A31(s) tablets it might be used to supply
+ 1.2V for the SSD2828 chip (converter of parallel LCD interface
+ into MIPI DSI).
diff --git a/drivers/power/axp221.c b/drivers/power/axp221.c
index 4c86f09..58bbd45 100644
--- a/drivers/power/axp221.c
+++ b/drivers/power/axp221.c
@@ -302,6 +302,39 @@ int axp221_set_aldo3(unsigned int mvolt)
AXP221_OUTPUT_CTRL3_ALDO3_EN);
}
+int axp221_set_eldo(int eldo_num, unsigned int mvolt)
+{
+ int ret;
+ u8 cfg = axp221_mvolt_to_cfg(mvolt, 700, 3300, 100);
+ u8 addr, bits;
+
+ switch (eldo_num) {
+ case 3:
+ addr = AXP221_ELDO3_CTRL;
+ bits = AXP221_OUTPUT_CTRL2_ELDO3_EN;
+ break;
+ case 2:
+ addr = AXP221_ELDO2_CTRL;
+ bits = AXP221_OUTPUT_CTRL2_ELDO2_EN;
+ break;
+ case 1:
+ addr = AXP221_ELDO1_CTRL;
+ bits = AXP221_OUTPUT_CTRL2_ELDO1_EN;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ if (mvolt == 0)
+ return axp221_clrbits(AXP221_OUTPUT_CTRL2, bits);
+
+ ret = pmic_bus_write(addr, cfg);
+ if (ret)
+ return ret;
+
+ return axp221_setbits(AXP221_OUTPUT_CTRL2, bits);
+}
+
int axp221_init(void)
{
/* This cannot be 0 because it is used in SPL before BSS is ready */
diff --git a/include/axp221.h b/include/axp221.h
index e6639f1..6f24a61 100644
--- a/include/axp221.h
+++ b/include/axp221.h
@@ -26,6 +26,9 @@
#define AXP221_OUTPUT_CTRL1_ALDO1_EN (1 << 6)
#define AXP221_OUTPUT_CTRL1_ALDO2_EN (1 << 7)
#define AXP221_OUTPUT_CTRL20x12
+#define AXP221_OUTPUT_CTRL2_ELDO1_EN (1 << 0)
+#define AXP221_OUTPUT_CTRL2_ELDO2_EN (1 << 1)
+#define AXP221_OUTPUT_CTRL2_ELDO3_EN (1 << 2)
#define AXP221_OUTPUT_CTRL2_DLDO1_EN (1 << 3)
#define AXP221_OUTPUT_CTRL2_DLDO2_EN (1 << 4)
#define AXP221_OUTPUT_CTRL2_DLDO3_EN (1 << 5)
@@ -37,6 +40,9 @@
#define AXP221_DLDO2_CTRL 0x16
#define AXP221_DLDO3_CTRL 0x17
#define AXP221_DLDO4_CTRL 0x18
+#define AXP221_ELDO1_CTRL 0x19
+#define AXP221_ELDO2_CTRL 0x1a
+#define AXP221_ELDO3_CTRL 0x1b
#define AXP221_DCDC1_CTRL 0x21
#define AXP221_DCDC2_CTRL 0x22
#define AXP221_DCDC3_CTRL 0x23
@@ -69,6 +75,7 @@ int axp221_set_dldo4(unsigned int mvolt);
int axp221_set_aldo1(unsigned int mvolt);
int axp221_set_aldo2(unsigned int mvolt);
int axp221_set_aldo3(unsigned int mvolt);
+int axp221_set_eldo(int eldo_num, unsigned int mvolt);
int axp221_init(void);
int axp221_get_sid(unsigned int *sid);
int axp_drivebus_enable(void);
--
2.0.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 0/7] video: Support for SSD2828 (parallel LCD to MIPI bridge)
This is the v2 of http://lists.denx.de/pipermail/u-boot/2015-January/200807.html It addresses the review comments. One other change is the introduction of CONFIG_VIDEO_LCD_SSD2828_TX_CLK option. The Allwinner A20 reference tablet schematics suggests the use of 12MHz for 'tx_clk'. But the MSI Primo81 tablet has it as 27MHz. So it can be indeed different in different devices and deserves a config option. The patch "video: sunxi: Switch from 'tx_clk' to 'pclk' for SSD2828" had been dropped, because the Kconfig option makes it unnecessary. Other than MSI Primo81, there is at least one more tablet with SSD2828: http://linux-sunxi.org/ICOU_Fatty_I Inspecting Android kernel sources indicates that two more GPIO pins are needed to support it. These changes can be submitted as a separate patchset later. Siarhei Siamashka (7): sunxi: axp221: Add ELDO[1-3] support include: Add header file with MIPI DSI constants from linux 3.18 video: Add support for SSD2828 (parallel LCD to MIPI bridge) video: sunxi: Hook up SSD2828 with the sunxi video driver sun6i: Add LCD display support for MSI Primo81 tablet video: ssd2828: Allow using 'pclk' as the PLL clock source video: ssd2828: Use MIPI DCS commands to retrieve the LCD panel id board/sunxi/Kconfig | 7 + board/sunxi/board.c | 1 + configs/MSI_Primo81_defconfig | 10 + drivers/power/Kconfig | 10 + drivers/power/axp221.c| 33 +++ drivers/video/Kconfig | 72 ++ drivers/video/Makefile| 1 + drivers/video/ssd2828.c | 578 ++ drivers/video/ssd2828.h | 128 ++ drivers/video/sunxi_display.c | 38 +++ include/axp221.h | 7 + include/mipi_display.h| 130 ++ 12 files changed, 1015 insertions(+) create mode 100644 drivers/video/ssd2828.c create mode 100644 drivers/video/ssd2828.h create mode 100644 include/mipi_display.h -- 2.0.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 7/7] video: ssd2828: Use MIPI DCS commands to retrieve the LCD panel id
Or at least try to do this. With the possibility of bi-directional
communication, it seems natural to expect that MIPI displays
should be able to handle automatic configuration for the screen
resolution and timings nicely. But the reality is not so pretty.
It appears that the manufacturers of MIPI LCD panels are not very
disciplined and do not follow any kind of standard guidelines
when it comes to providing the panel identification information.
MIPI DSI even has two alternative standard DCS commands for
potentially reading the vendor/panel id: MIPI_DCS_GET_DISPLAY_ID
and MIPI_DCS_READ_DDB_START. But these commands do not seem to
be widely implemented in real hardware. Moreover, the vendors
seem to sometimes invent their own custom new commands, while
ignoring the standard ones.
This particular patch probes both of the standard DCS panel
identification commands and prints the returned raw data to
the u-boot console. The standard DCS commands return zero on
the MSI Primo81 tablet though, so they are not very usaful in
practice. The code for probing additonal non-standard DCS
commands is also included (these commands do return something
on the MSI Primo81), but commented out for safety reasons.
We don't know what the future brings. Maybe the LCD panels
manufacturers are going to start acting responsibly some day.
And will implement proper panel identification more often.
Regarding what we have right now. The information retrieval
DCS commands still work if reducing the clock speed to the very
minimum and enabling only one lane on my MSI Primo81 tablet.
Potentially it means that one could perhaps swap two different
MIPI LCD panels (if they have a compatible connector) and still
have the software handling this fine by doing runtime selection
of the right settings (based on checking the panel id).
Signed-off-by: Siarhei Siamashka
---
Changes in v2:
- Comment out the use of non-standard DCS commands and adjusted
the commit message to mention this.
drivers/video/ssd2828.c | 142
1 file changed, 142 insertions(+)
diff --git a/drivers/video/ssd2828.c b/drivers/video/ssd2828.c
index 8b09082..7efe40f 100644
--- a/drivers/video/ssd2828.c
+++ b/drivers/video/ssd2828.c
@@ -98,6 +98,9 @@
#defineSSD2828_CFGR_LPE(1 << 10)
#defineSSD2828_CFGR_TXD(1 << 11)
+#defineSSD2828_ISR_READ_DATA_READY (1 << 0)
+#defineSSD2828_ISR_BTA_RESPONSE(1 << 2)
+
#defineSSD2828_VIDEO_MODE_NON_BURST_WITH_SYNC_PULSES (0 << 2)
#defineSSD2828_VIDEO_MODE_NON_BURST_WITH_SYNC_EVENTS (1 << 2)
#defineSSD2828_VIDEO_MODE_BURST(2 << 2)
@@ -167,6 +170,30 @@ static void write_hw_register(const struct ssd2828_config
*cfg, u8 regnum,
soft_spi_xfer_24bit_3wire(cfg, 0x72 | val);
}
+static int await_completion(const struct ssd2828_config *cfg,
+ u8 reg, u32 mask, u32 val)
+{
+ unsigned long tmo = timer_get_us() + 10;
+
+ while ((read_hw_register(cfg, reg) & mask) != val) {
+ if (timer_get_us() > tmo)
+ return 1;
+ }
+ return 0;
+}
+
+static int await_bits_set(const struct ssd2828_config *cfg,
+ u8 reg, u32 val)
+{
+ return await_completion(cfg, reg, val, val);
+}
+
+static int await_bits_clear(const struct ssd2828_config *cfg,
+ u8 reg, u32 val)
+{
+ return await_completion(cfg, reg, val, 0);
+}
+
/*
* Send MIPI command to the LCD panel (cmdnum < 0xB0)
*/
@@ -179,6 +206,79 @@ static void send_mipi_dcs_command(const struct
ssd2828_config *cfg, u8 cmdnum)
}
/*
+ * Sends a MIPI DCS command to retrieve information from the LCD panel.
+ */
+static int send_mipi_dcs_read_command(const struct ssd2828_config *cfg,
+ u8 cmdnum,
+ u8 *result_buf,
+ int bufsize)
+{
+ int size, i, result = 0;
+ /* Save CFGR register */
+ u32 old_cfgr = read_hw_register(cfg, SSD2828_CFGR);
+
+ /* Set the read enable bit */
+ write_hw_register(cfg, SSD2828_CFGR, old_cfgr | SSD2828_CFGR_REN);
+ /* Clear buffers and bring the state machine to its initial state */
+ write_hw_register(cfg, SSD2828_OCR, 1);
+ if (await_bits_clear(cfg, SSD2828_OCR, 1) != 0)
+ goto err;
+ /* Clear the RW1C bits in the ISR register */
+ write_hw_register(cfg, SSD2828_ISR, read_hw_register(cfg, SSD2828_ISR));
+
+ /* Set the payload size (only the DCS command itself) */
+ write_hw_register(cfg, SSD2828_PSCR1, 1);
+ /* Set maximum return size */
+ write_hw_register(cfg, SSD2828_MRSR, bufsize);
+ /* Write the
[U-Boot] [PATCH v2 6/7] video: ssd2828: Allow using 'pclk' as the PLL clock source
Instead of using the internal 'tx_clk' clock source, it is also
possible to use the pixel clock signal from the parallel LCD
interface ('pclk') as the reference clock for PLL.
The 'tx_clk' clock speed may be different on different boards/devices
(the allowed range is 8MHz - 30MHz). Which is not very convenient,
especially considering the need to know the exact 'tx_clk' clock
speed. This clock speed may be difficult to identify without having
device schematics and/or accurate documentation/sources every time.
Using 'pclk' is free from all these problems.
Signed-off-by: Siarhei Siamashka
---
Changes in v2:
- Set default value for VIDEO_LCD_SSD2828_TX_CLK in Kconfig
drivers/video/Kconfig | 4 +++-
drivers/video/ssd2828.c | 20 +---
drivers/video/ssd2828.h | 11 ---
3 files changed, 28 insertions(+), 7 deletions(-)
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index ec14a37..d9d4afc 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -19,12 +19,14 @@ config VIDEO_LCD_SSD2828
config VIDEO_LCD_SSD2828_TX_CLK
int "SSD2828 TX_CLK frequency (in MHz)"
depends on VIDEO_LCD_SSD2828
+ default 0
---help---
The frequency of the crystal, which is clocking SSD2828. It may be
anything in the 8MHz-30MHz range and the exact value should be
retrieved from the board schematics. Or in the case of Allwinner
hardware, it can be usually found as 'lcd_xtal_freq' variable in
- FEX files.
+ FEX files. It can be also set to 0 for selecting PCLK from the
+ parallel LCD interface instead of TX_CLK as the PLL clock source.
config VIDEO_LCD_SSD2828_RESET
string "RESET pin of SSD2828"
diff --git a/drivers/video/ssd2828.c b/drivers/video/ssd2828.c
index be68d38..8b09082 100644
--- a/drivers/video/ssd2828.c
+++ b/drivers/video/ssd2828.c
@@ -340,7 +340,7 @@ static int ssd2828_configure_video_interface(const struct
ssd2828_config *cfg,
int ssd2828_init(const struct ssd2828_config *cfg,
const struct ctfb_res_modes *mode)
{
- u32 lp_div, pll_freq_kbps, pll_config;
+ u32 lp_div, pll_freq_kbps, reference_freq_khz, pll_config;
/* The LP clock speed is limited by 10MHz */
const u32 mipi_dsi_low_power_clk_khz = 1;
/*
@@ -374,6 +374,20 @@ int ssd2828_init(const struct ssd2828_config *cfg,
}
/*
+* Pick the reference clock for PLL. If we know the exact 'tx_clk'
+* clock speed, then everything is good. If not, then we can fallback
+* to 'pclk' (pixel clock from the parallel LCD interface). In the
+* case of using this fallback, it is necessary to have parallel LCD
+* already initialized and running at this point.
+*/
+ reference_freq_khz = cfg->ssd2828_tx_clk_khz;
+ if (reference_freq_khz == 0) {
+ reference_freq_khz = mode->pixclock_khz;
+ /* Use 'pclk' as the reference clock for PLL */
+ cfgr_reg |= SSD2828_CFGR_CSS;
+ }
+
+ /*
* Setup the parallel LCD timings in the appropriate registers.
*/
if (ssd2828_configure_video_interface(cfg, mode) != 0) {
@@ -390,10 +404,10 @@ int ssd2828_init(const struct ssd2828_config *cfg,
/* PLL Configuration Register */
pll_config = construct_pll_config(
cfg->mipi_dsi_bitrate_per_data_lane_mbps * 1000,
- cfg->ssd2828_tx_clk_khz);
+ reference_freq_khz);
write_hw_register(cfg, SSD2828_PLCR, pll_config);
- pll_freq_kbps = decode_pll_config(pll_config, cfg->ssd2828_tx_clk_khz);
+ pll_freq_kbps = decode_pll_config(pll_config, reference_freq_khz);
lp_div = DIV_ROUND_UP(pll_freq_kbps, mipi_dsi_low_power_clk_khz * 8);
/* VC Control Register */
diff --git a/drivers/video/ssd2828.h b/drivers/video/ssd2828.h
index 14b96c5..1af6fa4 100644
--- a/drivers/video/ssd2828.h
+++ b/drivers/video/ssd2828.h
@@ -47,8 +47,12 @@ struct ssd2828_config {
* to TX_CLK_XIO/TX_CLK_XIN pins), which is necessary at least for
* clocking SPI after reset. The exact clock speed is not strictly,
* defined, but the datasheet says that it must be somewhere in the
-* 8MHz - 30MHz range (see "TX_CLK Timing" section). It is used as
-* a reference clock for PLL and must be set correctly.
+* 8MHz - 30MHz range (see "TX_CLK Timing" section). It can be also
+* used as a reference clock for PLL. If the exact clock frequency
+* is known, then it can be specified here. If it is unknown, or the
+* information is not trustworthy, then it can be set to 0.
+*
+* If unsure, set to 0.
*/
int ssd2828_tx_clk_khz;
@@ -115,7 +119,8 @@ struct ssd2828_config {
* The right place to insert this function call is after the parallel LCD
* interface is initialized
Re: [U-Boot] [PATCH] mpc85xx/t102xqds: convert deep sleep to generic board interface
Hi York, > -Original Message- > From: Sun York-R58495 > Sent: Saturday, January 17, 2015 1:23 AM > To: Tang Yuantian-B29983 > Cc: u-boot@lists.denx.de > Subject: Re: [PATCH] mpc85xx/t102xqds: convert deep sleep to generic board > interface > > Yuantian, > > On 01/15/2015 06:23 PM, Tang Yuantian-B29983 wrote: > > Hi York, > > > > Yes, I did it on purpose. T102XQDS is not supported in SDK1.7 anymore. > > So I don't want to put more efforts to add SPI/NAND/SD boot deep sleep > support. > > That's not a good reason. Regardless if Freescale SDK supports a board, as > far as > it benefits the community, we keep the support. > > > That means t102xqds only supports nor-boot deep sleep and need not to > update spl.c. > > > > It is the same case for T1040QDS. > > A note in readme would be nice. I am not going to push for a fix. Not having > the > console silenced is no big deal in case someone uses SPL with deep sleep. I am not sure I understand you right, but Non-nor deep sleep support is more than just disabling console. We need to update board head file, like t102xqds.h, as well. I think you are right. We should add non-nor boot support. Please apply these patches. I will send another two patch to support QDS non-nor boot deep sleep on qds. Regards, Yuantian > > York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: atmel: at91sam9m10g45ek: enable SPL
Hi Andreas, On 01/16/2015 06:16 PM, Andreas Bießmann wrote: Hi Bo, On 01/16/2015 10:30 AM, Bo Shen wrote: On 01/16/2015 05:10 PM, Andreas Bießmann wrote: On 01/16/2015 03:53 AM, Bo Shen wrote: --- a/arch/arm/cpu/arm926ejs/at91/Makefile +++ b/arch/arm/cpu/arm926ejs/at91/Makefile @@ -25,5 +25,9 @@ obj-y+= reset.o obj-y+= timer.o ifndef CONFIG_SKIP_LOWLEVEL_INIT +ifdef CONFIG_SPL_BUILD +obj-y+= spl_lowlevel_init.o +else obj-y+= lowlevel_init.o endif +endif I'm fine with having two variants of lowlevel_init for a time, but we should consolidate this and use C-style initialisation of SDRAM and stuff for the other armv5 at91 devices in future. AFAIK the a/a/c/arm926ejs/at91/lowlevel_init.S is mainly used for NOR Flash boots, so using the SPL code (but not necessarily the two binary mechanism) for the NOR Flash boots in future is appreciated. OK, when all the arm9 at91 related board has SPL support, then I will do this. Can we achieve this in this MW? I will try, but not sure. As I don't have this kind of board :( I need to check whether we still have this kind of board. +ENTRY(lowlevel_init) +/* + * Setup a temporary stack + */ +ldrsp, =CONFIG_SYS_INIT_SP_ADDR +bicsp, sp, #7 /* 8-byte alignment for ABI compliance */ + +ldrr9, =gdata I remember some patches removing the SPL gdata stuff, is that true? Thanks. Yes, just search for it, the following patch do this. http://patchwork.ozlabs.org/patch/423789/ (arm: Reduce the scope of lowlevel_init()) I think we should use the function provided there. What do you think? OK. I will do it in next version. Thanks. Best regards Andreas Bießmann Best Regards, Bo Shen ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: atmel: at91sam9m10g45ek: enable SPL
Hi Heiko, On 01/16/2015 07:35 PM, Heiko Schocher wrote: Hello Bo Am 16.01.2015 03:53, schrieb Bo Shen: Supports boot up from NAND flash with software ECC eanbled. And supports boot up from SD/MMC card with FAT file system. As the boot from SD/MMC card with FAT file system, the BSS segment is too big to fit into SRAM, so, use the lds to put it into SDRAM. So, we need to initialize the SDRAM as soon as possible. Borrow the low level init code from for this purpose. As there is a little change, which need lowlevel init, so also change taurus board based on at91sam9260, corvus board based on at91sam9g45. (CONFIG_SPL_STACK is replaced by CONFIG_SYS_INIT_SP_ADDR) Signed-off-by: Bo Shen --- arch/arm/Kconfig| 1 + arch/arm/cpu/arm926ejs/at91/Makefile| 4 ++ arch/arm/cpu/arm926ejs/at91/spl_lowlevel_init.S | 37 arch/arm/cpu/at91-common/spl_at91.c | 7 +-- arch/arm/cpu/at91-common/u-boot-spl-arm9.lds| 48 +++ board/atmel/at91sam9m10g45ek/at91sam9m10g45ek.c | 80 + configs/at91sam9m10g45ek_mmc_defconfig | 5 +- configs/at91sam9m10g45ek_nandflash_defconfig| 5 +- include/configs/at91sam9m10g45ek.h | 65 include/configs/corvus.h| 7 ++- include/configs/taurus.h| 7 ++- 11 files changed, 256 insertions(+), 10 deletions(-) create mode 100644 arch/arm/cpu/arm926ejs/at91/spl_lowlevel_init.S create mode 100644 arch/arm/cpu/at91-common/u-boot-spl-arm9.lds Acked-by: Heiko Schocher Thanks. but it does not boot on the corvus board ... please add this fix to your patch: diff --git a/include/configs/corvus.h b/include/configs/corvus.h index efc8ce5..dc25d95 100644 --- a/include/configs/corvus.h +++ b/include/configs/corvus.h @@ -90,7 +90,7 @@ #define CONFIG_SYS_SDRAM_SIZE 0x0800 #ifdef CONFIG_SPL_BUILD -#define CONFIG_SYS_INIT_SP_ADDR0x31 +#define CONFIG_SYS_INIT_SP_ADDR(16 * 1024) #else #define CONFIG_SYS_INIT_SP_ADDR \ (CONFIG_SYS_SDRAM_BASE + 4 * 1024 - GENERATED_GBL_DATA_SIZE) Tested your patch also on the taurus board, there it boots fine! so, after you fixed the corvus board, you can add my: Tested-by: Heiko Schocher Thanks, I will add this fix into next version. Thanks! And one question ... [...] diff --git a/arch/arm/cpu/arm926ejs/at91/spl_lowlevel_init.S b/arch/arm/cpu/arm926ejs/at91/spl_lowlevel_init.S new file mode 100644 index 000..f1b2ec9 --- /dev/null +++ b/arch/arm/cpu/arm926ejs/at91/spl_lowlevel_init.S @@ -0,0 +1,37 @@ +/* + * A lowlevel_init function that sets up the stack to call a C function to + * perform further init. + * + * (C) Copyright 2010 + * Texas Instruments, + * + * Author : + *Aneesh V + * + * SPDX-License-Identifier:GPL-2.0+ + */ + +#include +#include +#include + +ENTRY(lowlevel_init) +/* + * Setup a temporary stack + */ +ldrsp, =CONFIG_SYS_INIT_SP_ADDR Could we use here a new define (saying CONFIG_SYS_INIT_SP_LOWLEVEL)? Benefit would be, we can setup first the stack in sram, and after RAM init, which is done with your patch very early, we can set the stack with CONFIG_SYS_INIT_SP_ADDR into RAM! With using CONFIG_SYS_INIT_SP_ADDR here, the stack gets set twice to CONFIG_SYS_INIT_SP_ADDR ... I just try to get SPL on an atsam9260 based board working with only 4k sram ... so it would be nice to have stack also optionally in RAM ... but we have problems with the debugger adapter on the board ... so I have to wait some more days to try this part ... This just for the at91sam9260 based boards, not for others. Or else, we also need to add this definition for other boards. Can you do the following check? #ifdef CONFIG_SYS_INIT_SP_LOWLEVEL ldr sp, =CONFIG_SYS_INIT_SP_LOWLEVEL #else ldr sp, =CONFIG_SYS_INIT_SP_ADDR #endif If it is acceptable, can you add through your patches, as I my patch nowhere will use it. bye, Heiko Best Regards, Bo Shen ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] usb: musb-new: omap2430: Reset the MUSB controller early
On Sunday, January 18, 2015 at 05:44:45 PM, Paul Kocialkowski wrote:
> When booting from USB peripheral boot, the bootrom will not properly deinit
> the MUSB controller, which doesn't clearly indicate an USB disconnection
> to the host and leaves U-Boot to deal with the state of the previous USB
> session.
>
> On some host controller drivers (e.g. xhci_hcd), this ends up in a failure
> during set address, caused by the lack of proper disconnection
> notification.
>
> Resetting the controller early in U-Boot notifies the host of the
> disconnection and doesn't hurt other use cases.
>
> Signed-off-by: Paul Kocialkowski
> ---
> drivers/usb/musb-new/omap2430.c | 17 +
> 1 file changed, 17 insertions(+)
>
> diff --git a/drivers/usb/musb-new/omap2430.c
> b/drivers/usb/musb-new/omap2430.c index 98f4830..6b256bb 100644
> --- a/drivers/usb/musb-new/omap2430.c
> +++ b/drivers/usb/musb-new/omap2430.c
> @@ -321,6 +321,7 @@ static int omap2430_musb_init(struct musb *musb)
> {
> u32 l;
> int status = 0;
> + int timeout = 10;
> #ifndef __UBOOT__
> struct device *dev = musb->controller;
> struct omap2430_glue *glue = dev_get_drvdata(dev->parent);
> @@ -331,6 +332,22 @@ static int omap2430_musb_init(struct musb *musb)
> (struct omap_musb_board_data *)musb->controller;
> #endif
>
> + /* Reset the controller */
> + musb_writel(musb->mregs, OTG_SYSCONFIG, SOFTRST);
> +
> + while (timeout--) {
Hi!
Just a minor nitpick, you might want to replace the timeout with get_timer(0)
and friends, see for example drivers/spi/altera_spi.c:161 (the inner loop in
spi_xfer() ).
+CC Hans, can you test on sunxi please ?
Thank you !
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/9] sunxi: Stop differentiating between 512M and 1G variants of the same board
On Sun, 18 Jan 2015 13:23:26 +0100
Hans de Goede wrote:
> While working on adding more boards I noticed that we lack a config for
> the 512M cubieboard, and that some of the new boards which I want to add also
> have 512M and 1G variants, rather then adding 2 defconfig's for all of these,
> lets switch the exising boards which have both a 512M and 1024M variant over
> to the sun4i dram autoconfig code.
>
> This also drops the foo_RAMSIZE_defconfig variants of boards where we
> currently
> have 2 separate configs already.
>
> Note:
> 1) The newly introduced CONFIG_DRAM_EMR1 kconfig value is not used with
> a value other then its default for now, but we need this to be configurable
> to support some new boards with auto dram config.
>
> 2) We always set all CONFIG_DRAM_foo values in defconfigs, even if they match
> the defaults, this is done to make it more clear what values are used for a
> certain board.
>
> This has been tested on a Mele A1000, Mini-X and a Cubieboard, all 1G
> variants, the dram autoconfig code has also been tested on a 512M mk802
> (a defconfig for the mk802 is added in a later patch).
>
> Signed-off-by: Hans de Goede
Thanks for finally finding time to do some refinements in this pile of
junk dram settings for the boards that you are maintaining.
I think that adding the Kconfig options is fine as long as they
are not abused and the 'dram_para' structure is kept. We want to
be able to update DRAM settings without the need of recompiling SPL.
Currently this can be relatively easily done by finding and patching
the 'dram_para' structure inside of the SPL binary.
In general this looks like a good change. However see below.
[...]
> +++ b/board/sunxi/dram_sun4i_auto.c
> @@ -0,0 +1,31 @@
> +/* this file is generated, don't edit it yourself */
> +
> +#include
> +#include
> +
> +static struct dram_para dram_para = {
> + .clock = CONFIG_DRAM_CLK,
> + .type = 3,
> + .rank_num = 1,
> + .density = 0,
> + .io_width = 0,
> + .bus_width = 0,
> + .cas = 6,
> + .zq = CONFIG_DRAM_ZQ,
> + .odt_en = 0,
> + .size = 0,
> + .tpr0 = 0x30926692,
> + .tpr1 = 0x1090,
> + .tpr2 = 0x1a0c8,
> + .tpr3 = 0,
> + .tpr4 = 0,
> + .tpr5 = 0,
> + .emr1 = CONFIG_DRAM_EMR1,
> + .emr2 = 0,
> + .emr3 = 0,
> +};
As we already discussed earlier
http://lists.denx.de/pipermail/u-boot/2014-September/189266.html
these tpr0/tpr1/tpr2 settings are configured for DDR2-800E (and 400MHz
clock speed because of double data rate). Yes, DDR2 (!) instead of
DDR3. This in practice is not very much off from DDR3-800, except for
the tXS parameter. But tXS is only relevant for self-refresh, which is
currently not used by the u-boot or the mainline kernel anyway. That's
why this all does not crash and burn in an obvious way.
Anyway, these timings are still wrong for the boards running DRAM
at the clock speeds higher than 400MHz. For example, they are ~20%
outside of the valid range at 480MHz and this all works by pure luck,
thanks to the hardware typically having some safety/overclocking margin.
If we look at the parameters used by the sun7i boards:
.cas = 9,
.tpr0 = 0x42d899b7,
.tpr1 = 0xa090,
.tpr2 = 0x22a00,
... then we can see that the settings are also a bit fishy. The
tpr1/tpr2 parameters are matching DDR3-800 timings. And tpr0 is
matching DDR3-1333 timings with 1KB (!) page size, while many sunxi
devices are using 2KB pages. So it's some weird crossbreed, which
is however somewhat less wrong than the settings from sun4i boards.
I would suggest trying one of the following DRAM settings, generated
as explained at http://linux-sunxi.org/Mainline_U-boot#DRAM_Settings
And injecting the .clock, .zq and .emr1 parameters from Kconfig.
static struct dram_para dram_para = { /* DRAM timings: 7-7-7-18 (480 MHz) */
.clock = 480,
.type = 3,
.rank_num = 1,
.cas = 7,
.zq= 0x7b,
.odt_en= 0,
.tpr0 = 0x30927790,
.tpr1 = 0xa0b0,
.tpr2 = 0x23200,
.tpr3 = 0x0,
.tpr4 = 0x0,
.tpr5 = 0x0,
.emr1 = 0x0,
.emr2 = 0x8,
.emr3 = 0x0,
.active_windowing = 1,
};
static struct dram_para dram_para = { /* DRAM timings: 7-8-8-20 (528 MHz) */
.clock = 528,
.type = 3,
.rank_num = 1,
.cas = 7,
.zq= 0x7b,
.odt_en= 0,
.tpr0 = 0x36948890,
.tpr1 = 0xa0c0,
.tpr2 = 0x23600,
.tpr3 = 0x0,
.tpr4 = 0x0,
.tpr5 = 0x0,
.emr1 = 0x0,
.emr2 = 0x8,
.emr3 = 0x0,
.active_windowing = 1,
};
Alternatively, we can add runtime calculation of cas/tpr0/tpr1/tpr2/emr2
parameters directly into SPL, thus better matching the selected DRAM
clock speed and reducing memory access latency.
[U-Boot] [PATCH 0/2] MIPS: initial support for driver model
- add support for CONFIG_SYS_INIT_SP_ADDR - add support for CONFIG_SYS_MALLOC_F_LEN - implement MIPS specific setup of gd_t structure and malloc area after initial stack area Daniel Schwierzeck (2): MIPS: add support for CONFIG_SYS_INIT_SP_ADDR MIPS: add support for pre-relocation malloc arch/mips/cpu/mips32/start.S | 29 - arch/mips/cpu/mips64/start.S | 29 - arch/mips/include/asm/config.h | 2 -- 3 files changed, 56 insertions(+), 4 deletions(-) -- 2.1.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] MIPS: add support for CONFIG_SYS_INIT_SP_ADDR
Support the existing config option CONFIG_SYS_INIT_SP_ADDR on MIPS. This allows to move the initial stack to other places than the beginning of RAM. Signed-off-by: Daniel Schwierzeck --- arch/mips/cpu/mips32/start.S | 7 ++- arch/mips/cpu/mips64/start.S | 7 ++- 2 files changed, 12 insertions(+), 2 deletions(-) diff --git a/arch/mips/cpu/mips32/start.S b/arch/mips/cpu/mips32/start.S index 384ea26..5946859 100644 --- a/arch/mips/cpu/mips32/start.S +++ b/arch/mips/cpu/mips32/start.S @@ -15,6 +15,11 @@ #define CONFIG_SYS_MIPS_CACHE_MODE CONF_CM_CACHABLE_NONCOHERENT #endif +#ifndef CONFIG_SYS_INIT_SP_ADDR +#define CONFIG_SYS_INIT_SP_ADDR(CONFIG_SYS_SDRAM_BASE + \ + CONFIG_SYS_INIT_SP_OFFSET) +#endif + /* * For the moment disable interrupts, mark the kernel mode and * set ST0_KX so that the CPU does not spit fire when using @@ -135,7 +140,7 @@ reset: #endif /* Set up temporary stack */ - li sp, CONFIG_SYS_SDRAM_BASE + CONFIG_SYS_INIT_SP_OFFSET + li sp, CONFIG_SYS_INIT_SP_ADDR movefp, sp la t9, board_init_f diff --git a/arch/mips/cpu/mips64/start.S b/arch/mips/cpu/mips64/start.S index 6ff714e..81df923 100644 --- a/arch/mips/cpu/mips64/start.S +++ b/arch/mips/cpu/mips64/start.S @@ -15,6 +15,11 @@ #define CONFIG_SYS_MIPS_CACHE_MODE CONF_CM_CACHABLE_NONCOHERENT #endif +#ifndef CONFIG_SYS_INIT_SP_ADDR +#define CONFIG_SYS_INIT_SP_ADDR(CONFIG_SYS_SDRAM_BASE + \ + CONFIG_SYS_INIT_SP_OFFSET) +#endif + #ifdef CONFIG_SYS_LITTLE_ENDIAN #define MIPS64_R_INFO(ssym, r_type3, r_type2, r_type) \ (((r_type) << 24) | ((r_type2) << 16) | ((r_type3) << 8) | (ssym)) @@ -129,7 +134,7 @@ reset: #endif /* Set up temporary stack */ - dli sp, CONFIG_SYS_SDRAM_BASE + CONFIG_SYS_INIT_SP_OFFSET + dli sp, CONFIG_SYS_INIT_SP_ADDR movefp, sp dla t9, board_init_f -- 2.1.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] MIPS: add support for pre-relocation malloc
Implement MIPS specific setup of the gd_t structure to support pre-relocation malloc. If CONFIG_SYS_MALLOC_F_LEN is specified, a memory area will be reserved after the initial stack area and the gd->malloc_base pointer will be initialized. After this patch the new driver model can be used on MIPS. Signed-off-by: Daniel Schwierzeck --- arch/mips/cpu/mips32/start.S | 24 +++- arch/mips/cpu/mips64/start.S | 24 +++- arch/mips/include/asm/config.h | 2 -- 3 files changed, 46 insertions(+), 4 deletions(-) diff --git a/arch/mips/cpu/mips32/start.S b/arch/mips/cpu/mips32/start.S index 5946859..36b92cc 100644 --- a/arch/mips/cpu/mips32/start.S +++ b/arch/mips/cpu/mips32/start.S @@ -140,9 +140,31 @@ reset: #endif /* Set up temporary stack */ - li sp, CONFIG_SYS_INIT_SP_ADDR + li t0, -16 + li t1, CONFIG_SYS_INIT_SP_ADDR + and sp, t1, t0 # force 16 byte alignment + sub sp, sp, GD_SIZE # reserve space for gd + and sp, sp, t0 # force 16 byte alignment + movek0, sp # save gd pointer +#ifdef CONFIG_SYS_MALLOC_F_LEN + li t2, CONFIG_SYS_MALLOC_F_LEN + sub sp, sp, t2 # reserve space for early malloc + and sp, sp, t0 # force 16 byte alignment +#endif movefp, sp + /* Clear gd */ + movet0, k0 +1: + sw zero, 0(t0) + blt t0, t1, 1b +addi t0, 4 + +#ifdef CONFIG_SYS_MALLOC_F_LEN + addut0, k0, GD_MALLOC_BASE # gd->malloc_base offset + sw sp, 0(t0) +#endif + la t9, board_init_f jr t9 move ra, zero diff --git a/arch/mips/cpu/mips64/start.S b/arch/mips/cpu/mips64/start.S index 81df923..471bc1e 100644 --- a/arch/mips/cpu/mips64/start.S +++ b/arch/mips/cpu/mips64/start.S @@ -134,9 +134,31 @@ reset: #endif /* Set up temporary stack */ - dli sp, CONFIG_SYS_INIT_SP_ADDR + dli t0, -16 + dli t1, CONFIG_SYS_INIT_SP_ADDR + and sp, t1, t0 # force 16 byte alignment + dsubsp, sp, GD_SIZE # reserve space for gd + and sp, sp, t0 # force 16 byte alignment + movek0, sp # save gd pointer +#ifdef CONFIG_SYS_MALLOC_F_LEN + dli t2, CONFIG_SYS_MALLOC_F_LEN + dsubsp, sp, t2 # reserve space for early malloc + and sp, sp, t0 # force 16 byte alignment +#endif movefp, sp + /* Clear gd */ + movet0, k0 +1: + sw zero, 0(t0) + blt t0, t1, 1b +daddi t0, 4 + +#ifdef CONFIG_SYS_MALLOC_F_LEN + daddu t0, k0, GD_MALLOC_BASE # gd->malloc_base offset + sw sp, 0(t0) +#endif + dla t9, board_init_f jr t9 move ra, zero diff --git a/arch/mips/include/asm/config.h b/arch/mips/include/asm/config.h index 1c8a42b..3a891ba 100644 --- a/arch/mips/include/asm/config.h +++ b/arch/mips/include/asm/config.h @@ -7,8 +7,6 @@ #ifndef _ASM_CONFIG_H_ #define _ASM_CONFIG_H_ -#define CONFIG_SYS_GENERIC_GLOBAL_DATA - #define CONFIG_LMB #define CONFIG_SYS_BOOT_RAMDISK_HIGH -- 2.1.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] MIPS: add Kconfig option for CONFIG_SWAP_IO_SPACE
Signed-off-by: Daniel Schwierzeck --- arch/mips/Kconfig | 4 include/configs/malta.h | 2 -- 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig index d87cbb4..ef78929 100644 --- a/arch/mips/Kconfig +++ b/arch/mips/Kconfig @@ -29,6 +29,7 @@ config TARGET_MALTA select SUPPORTS_LITTLE_ENDIAN select SUPPORTS_CPU_MIPS32_R1 select SUPPORTS_CPU_MIPS32_R2 + select SWAP_IO_SPACE config TARGET_VCT bool "Support vct" @@ -181,6 +182,9 @@ config 32BIT config 64BIT bool +config SWAP_IO_SPACE + bool + endif endmenu diff --git a/include/configs/malta.h b/include/configs/malta.h index a29b86b..684d249 100644 --- a/include/configs/malta.h +++ b/include/configs/malta.h @@ -38,8 +38,6 @@ #define CONFIG_SYS_MHZ 250 /* arbitrary value */ #define CONFIG_SYS_MIPS_TIMER_FREQ (CONFIG_SYS_MHZ * 100) -#define CONFIG_SWAP_IO_SPACE - /* * Memory map */ -- 2.1.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] MIPS: replace $(CPU) with Kconfig symbols
Conditionally set head-y and lib-y with boolean Kconfig symbols for selected CPU. This deprecates the usage of the $(CPU) variable. Signed-off-by: Daniel Schwierzeck --- arch/mips/Kconfig | 8 arch/mips/Makefile | 6 -- 2 files changed, 12 insertions(+), 2 deletions(-) diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig index 363f5ac..d87cbb4 100644 --- a/arch/mips/Kconfig +++ b/arch/mips/Kconfig @@ -167,6 +167,14 @@ config SUPPORTS_CPU_MIPS64_R1 config SUPPORTS_CPU_MIPS64_R2 bool +config CPU_MIPS32 + bool + default y if CPU_MIPS32_R1 || CPU_MIPS32_R2 + +config CPU_MIPS64 + bool + default y if CPU_MIPS64_R1 || CPU_MIPS64_R2 + config 32BIT bool diff --git a/arch/mips/Makefile b/arch/mips/Makefile index 1907b57..0a9e7e6 100644 --- a/arch/mips/Makefile +++ b/arch/mips/Makefile @@ -2,7 +2,9 @@ # SPDX-License-Identifier: GPL-2.0+ # -head-y := arch/mips/cpu/$(CPU)/start.o +head-$(CONFIG_CPU_MIPS32) := arch/mips/cpu/mips32/start.o +head-$(CONFIG_CPU_MIPS64) := arch/mips/cpu/mips64/start.o -libs-y += arch/mips/cpu/$(CPU)/ +libs-$(CONFIG_CPU_MIPS32) += arch/mips/cpu/mips32/ +libs-$(CONFIG_CPU_MIPS64) += arch/mips/cpu/mips64/ libs-y += arch/mips/lib/ -- 2.1.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [linux-sunxi] Re: linux-sunxi/u-boot-sunxi is no longer supported, time to switch to upstream u-boot
On Sun, 18 Jan 2015 11:38:06 -0800 (PST) Ezaul Zillmer wrote: > Hello > > How could run u-boot with lcd with > Cubieboard2 + DVK-521 using Kernke 3.19rc3 > u-boot-wip with HDMI is already running > not get to do the LCD picture > > Configuration it would be LCD e toud > > fex [...] There are several options: 1. If you can ensure that your fex file is available in the sunxi-boards repository, then you will get your LCD settings available on the http://linux-sunxi.org/LCD wiki page after the next round of automatic conversion. 2. If you are really impatient, then you can go to http://linux-sunxi.org/LCD#Script_for_automated_conversion Then copy/paste this script into some file with *.rb extension and run it on your fex file to get the CONFIG_VIDEO_LCD_MODE line for your board. This is currently work in progress and will definitely change in the near future. There is no reason why we can't get complete u-boot defconfigs (not just LCD settings alone) generated from fex files automatically. Along with dts/dtb files for the kernel. Stay tuned. -- Best regards, Siarhei Siamashka ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] linux-sunxi/u-boot-sunxi is no longer supported, time to switch to upstream u-boot
Hello How could run u-boot with lcd with Cubieboard2 + DVK-521 using Kernke 3.19rc3 u-boot-wip with HDMI is already running not get to do the LCD picture Configuration it would be LCD e toud fex [disp_init] disp_init_enable = 1 disp_mode = 0 screen0_output_type = 1 screen0_output_mode = 4 screen1_output_type = 0 screen1_output_mode = 4 fb0_width = 1024 fb0_height = 768 fb0_framebuffer_num = 2 fb0_format = 10 fb0_pixel_sequence = 0 fb0_scaler_mode_enable = 0 fb1_width = 1024 fb1_height = 768 fb1_framebuffer_num = 2 fb1_format = 10 fb1_pixel_sequence = 0 fb1_scaler_mode_enable = 0 lcd0_backlight = 197 lcd1_backlight = 197 lcd0_bright = 50 lcd0_contrast = 50 lcd0_saturation = 57 lcd0_hue = 50 lcd1_bright = 50 lcd1_contrast = 50 lcd1_saturation = 57 lcd1_hue = 50 [lcd0_para] lcd_used = 1 lcd_x = 800 lcd_y = 480 lcd_dclk_freq = 33 lcd_pwm_not_used = 0 lcd_pwm_ch = 0 lcd_pwm_freq = 1 lcd_pwm_pol = 0 lcd_max_bright = 240 lcd_min_bright = 64 lcd_if = 0 lcd_hbp = 215 lcd_ht = 1055 lcd_vbp = 34 lcd_vt = 1050 lcd_vspw = 3 lcd_hspw = 20 lcd_hv_if = 0 lcd_hv_smode = 0 lcd_hv_s888_if = 0 lcd_hv_syuv_if = 0 lcd_lvds_ch = 0 lcd_lvds_mode = 0 lcd_lvds_bitwidth = 0 lcd_lvds_io_cross = 0 lcd_cpu_if = 0 lcd_frm = 1 lcd_io_cfg0 = 0 lcd_gamma_correction_en = 0 lcd_gamma_tbl_0 = 0x0 lcd_gamma_tbl_1 = 0x10101 lcd_gamma_tbl_255 = 0xff lcd_bl_en_used = 1 lcd_bl_en = port:PH07<1><0><1> lcd_power_used = 1 lcd_power = port:PH08<1><0><1> lcd_pwm_used = 1 lcd_pwm = port:PB02<2><0> lcd_gpio_0 = port:PH15<0><0> lcd_gpio_1 = lcd_gpio_2 = lcd_gpio_3 = lcdd0 = port:PD00<2><0> lcdd1 = port:PD01<2><0> lcdd2 = port:PD02<2><0> lcdd3 = port:PD03<2><0> lcdd4 = port:PD04<2><0> lcdd5 = port:PD05<2><0> lcdd6 = port:PD06<2><0> lcdd7 = port:PD07<2><0> lcdd8 = port:PD08<2><0> lcdd9 = port:PD09<2><0> lcdd10 = port:PD10<2><0> lcdd11 = port:PD11<2><0> lcdd12 = port:PD12<2><0> lcdd13 = port:PD13<2><0> lcdd14 = port:PD14<2><0> lcdd15 = port:PD15<2><0> lcdd16 = port:PD16<2><0> lcdd17 = port:PD17<2><0> lcdd18 = port:PD18<2><0> lcdd19 = port:PD19<2><0> lcdd20 = port:PD20<2><0> lcdd21 = port:PD21<2><0> lcdd22 = port:PD22<2><0> lcdd23 = port:PD23<2><0> lcdclk = port:PD24<2><0> lcdde = port:PD25<2><0> lcdhsync = port:PD26<2><0> lcdvsync = port:PD27<2><0> [ctp_para] ctp_used = 1 ctp_name = "ft5x_ts" ctp_twi_id = 1 ctp_twi_addr = 0x38 ctp_screen_max_x = 800 ctp_screen_max_y = 480 ctp_revert_x_flag = 0 ctp_revert_y_flag = 1 ctp_exchange_x_y_flag = 0 ctp_firm = 1 ctp_wakeup = port:PB13<1><1> [ctp_list_para] ctp_det_used = 1 ft5x_ts = 1 gt82x = 0 gslX680 = 0 gt9xx_ts = 0 gt811 = 0 [gpio_para] gpio_pin_3 = port:PH07<6> ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] GPL license statement
Hello all, every now and then a new round of discussions about the U-Boot licensing terms comes to boil. As I started this project nearly 15 years ago, and still regularly participate in it's development processes, I've been asked to comment on this topic. Here we go: Legal disclaimer: I am speaking for myself only. I do not claim to represent the opinion of the community, nor that of my employer, DENX. Short answer / management summary: -- The U-Boot project uses version 2 of the GNU General Public License as published by the Free Software Foundation as general license. This is version 2 only, not version 3, not even "version 2 or any later version”. There are no plans nor any ongoing activities to change that. Any attempts to re-license U-Boot under a different license (say, GPL-3.0 [1]) would require an enormous amount of efforts. I have never seen any indications that any entity would be willing to start any such development or pay for the necessary efforts. Long answer including background information: - U-Boot is a community project, and development is driven by contributions from the community. There may be a large number of source files in the U-Boot project which are coyrighted by me, but that does not mean much. I am just a small part of this community. No individual entity, person or company, has sole power of representation so he could decide which direction the development takes. They can submit proposals and patches, but that does not mean that the community will automatically accept these. They can even create forks of the U-Boot project, but again it is up to the community to decide what constitutes the "mainline" version of U-Boot that is supported by the community. In the end it is up for the community to decide what is considered best and what will be publicly accepted. The project wide license for U-Boot is GPL-2.0. Individual files are covered by other, compatible licenses, but the license for the U-Boot image that you will install and run on your devices is GPL-2.0. If anybody wanted to change this licensing, that would require considerable efforts. Assume we attempt to make the smallest possible change: open the path for later versions of the GPL, i. e. introduce GPL-2.0+ as general U-Boot license. That would mean that all files in U-Boot that are currently covered by GPL-2.0 only whould need to be either removed, relicenced by their respective authors, or reimplemen- ted from scratch. This affects a LOT of code. U-Boot was created with the explicit intention to borrow as much code from the Linux kernel as possible. And that was done. And Linux is licensed unter GPL-2.0. In the result, not only a lot of individual files, but whole sub-systems in U-Boot are covered by GPL-2.0: whole MTD / UBI / UBIFS as well as most other file system code, many device drivers, large parts of the networking code, etc. etc. So what are the options? - If we remove all such code, U-Boot would no longer compile or fail to boot on the overwhelming majority of supported systems - and on the remaining ones the functionality would be so crippled to render it basically unusable. - Trying to contact all individual authors who contributed parts to the GPL-2.0 code in U-Boot would be not only a Sisyphean task, but it would also be bound to fail, as some of the involved authors have clearly delcared in the past that they refuse to do so. - So remains reimplementing all these missing parts from scratch, and getting it into a usable state on the plethora of systems supported by U-Boot. That would be a tremendous effort, worth probably several man-years of development. So far, nobody ever even came close to seriously considering such a venture. So U-Boot is stuck with status quo - it's licensed under GPL-2.0. But why are there any discussions at all? What could be reasons that would eventually motivate the community to change the status quo of U-Boot licensing? License terms have always been a somewhat controversial issue. This is unavoidable, as there are many different interests. Just to give two examples: 1. Device Owner: Assume there is a developer who has been actively contributing to the development of U-Boot for a number of years, dedicating a significant amount of efforts to the community. Then he buys some device, and quickly finds out: - There is an annoying bug or problem or limitation of functio- nality in the device, and the vendor is not going to fix that. - The device is running U-Boot, and the bug is in the vendor provided U-Boot code. You can easily verify this because the vendor prvides the full source code of U-Boot as required by GPL. - The problem is trivial to fix, for example simply by upgrading to a more recent version of U-Boot. - It is impossible to install a different version of U-Boot on the devic
[U-Boot] [PATCH] arm: spl: Allow board_init_r() to run with a larger stack
At present SPL uses a single stack, either CONFIG_SPL_STACK or CONFIG_SYS_INIT_SP_ADDR. Since some SPL features (such as MMC and environment) require a lot of stack, some boards set CONFIG_SPL_STACK to point into SDRAM. They then set up SDRAM very early, before board_init_f(), so that the larger stack can be used. This is an abuse of lowlevel_init(). That function should only be used for essential start-up code which cannot be delayed. An example of a valid use is when only part of the SPL code is visible/executable, and the SoC must be set up so that board_init_f() can be reached. It should not be used for SDRAM init, console init, etc. Add a CONFIG_SPL_STACK_R option, which allows the stack to be moved to a new address before board_init_r() is called in SPL. The expected SPL flow (for CONFIG_SPL_FRAMEWORK) is now: Execution starts with start.S. Two main functions can be provided by the board implementation. The purpose and limitations of each is described below. After that, the common board_init_r() is called to perform the SPL task. lowlevel_init(): - purpose: essential init to permit execution to reach board_init_f() - no global_data, but there is a stack - must not set up SDRAM or use console - must only do the bare minimum to allow execution to continue to board_init_f() - this is almost never needed - return normally from this function board_init_f(): - purpose: set up the machine ready for running board_init_r(): i.e. SDRAM and serial UART - global_data is available - preloader_console_init() can be called here in extremis - stack is in SRAM - should set up SDRAM, and anything needed to make the UART work - these is no need to clear BSS, it will be done by crt0.S - must return normally from this function (don't call board_init_r() directly) Here the BSS is cleared. If CONFIG_SPL_STACK_R is defined, then at this point the stack and global_data are relocated to below that address. board_init_r(): - purpose: main execution, common code - global_data is available - SDRAM is available - stack is optionally in SDRAM, if CONFIG_SPL_STACK_R is defined and points into SDRAM - preloader_console_init() can be called here - typically this is done by defining CONFIG_SPL_BOARD_INIT and then supplying a spl_board_init() function containing this call - loads U-Boot or (in falcon mode) Linux Note: This patch is intended to apply over the top of Tom's SPL changes and this series: https://patchwork.ozlabs.org/patch/423785/ Signed-off-by: Simon Glass --- arch/arm/lib/crt0.S | 13 ++--- common/spl/spl.c| 35 +++ doc/README.SPL | 42 ++ 3 files changed, 87 insertions(+), 3 deletions(-) diff --git a/arch/arm/lib/crt0.S b/arch/arm/lib/crt0.S index 22df3e5..7939ced 100644 --- a/arch/arm/lib/crt0.S +++ b/arch/arm/lib/crt0.S @@ -113,7 +113,14 @@ here: /* Set up final (full) environment */ bl c_runtime_cpu_setup /* we still call old routine here */ - +#endif +#if !defined(CONFIG_SPL_BUILD) || defined(CONFIG_SPL_FRAMEWORK) +# ifdef CONFIG_SPL_BUILD + /* Use a DRAM stack for the rest of SPL, if requested */ + bl spl_relocate_stack_gd + cmp r0, #0 + movne sp, r0 +# endif ldr r0, =__bss_start/* this is auto-relocated! */ ldr r1, =__bss_end /* this is auto-relocated! */ @@ -124,9 +131,10 @@ clbss_l:cmpr0, r1 /* while not at end of BSS */ addlo r0, r0, #4 /* move to next */ blo clbss_l +#if ! defined(CONFIG_SPL_BUILD) bl coloured_LED_init bl red_led_on - +#endif /* call board_init_r(gd_t *id, ulong dest_addr) */ mov r0, r9 /* gd_t */ ldr r1, [r9, #GD_RELOCADDR] /* dest_addr */ @@ -134,7 +142,6 @@ clbss_l:cmp r0, r1 /* while not at end of BSS */ ldr pc, =board_init_r /* this is auto-relocated! */ /* we should not return here. */ - #endif ENDPROC(_main) diff --git a/common/spl/spl.c b/common/spl/spl.c index 1826c47..78bb279 100644 --- a/common/spl/spl.c +++ b/common/spl/spl.c @@ -276,3 +276,38 @@ void preloader_console_init(void) spl_display_print(); #endif } + +/** + * spl_relocate_stack_gd() - Relocate stack ready for board_init_r() execution + * + * Sometimes board_init_f() runs with a stack in SRAM but we want to use SDRAM + * for the main board_init_r() execution. This is typically because we need + * more stack space for things like the MMC sub-system. + * + * This function calculates the stack position, copies the global_data into + * place and returns the new stack position. The caller is responsible
Re: [U-Boot] [PATCH v1 2/4] virt-dt: Allow reservation of the secure region when it is in a RAM carveout.
On Thu, 2015-01-15 at 16:49 -0700, Stephen Warren wrote: > On 01/13/2015 12:45 PM, Ian Campbell wrote: > > In this case the secure code lives in RAM, and hence needs to be reserved, > > but > > it has been relocated, so the reservation of __secure_start does not apply. > > > > Add support for setting CONFIG_ARMV7_SECURE_RESERVE_SIZE to reserve such a > > region. > > > > This will be used in a subsequent patch for Jetson-TK1 > > It's rather hard to review this without any documentation in the README, > of the new symbol, or any of the existing: > > CONFIG_ARMV7_NONSEC > CONFIG_ARMV7_VIRT > CONFIG_ARMV7_PSCI > > It'd be nice to have a description of what those do exactly, and how > they interact or conflict. Anyone got any opinions in the new Kconfig-world regarding whether it is more or less appropriate to use the help section of the Kconfig file vs. the README file? ...and only now do I notice that the first two of the three options mentioned above are already documented in the Kconfig and the third (PSCI) isn't a Kconfig option (yet?) so there's no ambiguity about where it should be put. I also just noticed that the README says "Later we will add a configuration tool - probably similar to or even identical to what's used for the Linux kernel". Ian. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 6/9] sunxi: Remove CONFIG_TARGET_FOO for sun4i, sun6i and sun8i boards
Hi, On 18-01-15 17:31, Ian Campbell wrote: On Sun, 2015-01-18 at 13:23 +0100, Hans de Goede wrote: CONFIG_TARGET_FOO is only used in board/sunxi/Makefile to select the dram config for sun5i and sun7i boards and in board/sunxi/gmac.c for some special handling of the bananapi/bananapro (both sun7i), iow it is not used at all on any sun4i, sun6i and sun8i boards so lets get rid of it there. How close are we to being able to do the same for sun5i and/or sun7i? For sun5i it is a matter of me sitting down, doing the work, then testing on all the boards, then submit to the list for review. For sun7i it is more or less the same, except that I do not own 1 or 2 supported sun7i boards, but I guess it is safe to say that if autoconfig works for all the boards I do own that it will work on the one I do not own also, never the less when I get around to this I'll also ask the MAINTAINERS to test. The banana* stuff probably ought to become CONFIG_SUNXI_GMAX_DELAY (or whatever it was, you've told me like three times now but I can't seem to retain it...) sooner rather than later. Ack, this is all a matter of spending the time to make the necessary changes. I did the sun4i work now, because I wanted to clean up the sun4i stuff before adding more sun4i boards. Regards, Hans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/9] sunxi: Convert Linksprite_pcDuino_defconfig to use auto dram configuration
Hi, On 18-01-15 17:26, Ian Campbell wrote: On Sun, 2015-01-18 at 16:24 +, Ian Campbell wrote: On Sun, 2015-01-18 at 13:23 +0100, Hans de Goede wrote: Currently we've separate detailed dram settings for all sun4i boards, this moves them There's only one board here, did you intend for the next patch to be folder with this one as a bulk switch? Or is there something particularly interesting about this one? Maybe you intended to Cc Zoltan who is listed in MAINTAINERS for this board for testing? (Whereas apparently you own all the ones in the next patch). Right, but rather then Cc-ing him I've mailed him privately. Regards, Hans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/9] sunxi: Convert Linksprite_pcDuino_defconfig to use auto dram configuration
Hi,
On 18-01-15 17:24, Ian Campbell wrote:
On Sun, 2015-01-18 at 13:23 +0100, Hans de Goede wrote:
Currently we've separate detailed dram settings for all sun4i boards, this
moves them
There's only one board here, did you intend for the next patch to be
folder with this one as a bulk switch? Or is there something
particularly interesting about this one?
The only thing special about this board is that it is the only currently
supported sun4i board which I do not have :)
I'm waiting for Zoltan to get back to me with testing results and then I
can add his Tested-by, I can squash it into the next patch and add his
Tested-by there, I guess that makes more sense.
Regards,
Hans
over to using auto dram configuration so that we can get rid of
all the per board dram_foo.c files.
Signed-off-by: Hans de Goede
---
board/sunxi/Makefile | 2 +-
board/sunxi/dram_sun4i_408_1024_iow8.c | 31 ---
configs/Linksprite_pcDuino_defconfig | 3 +++
3 files changed, 4 insertions(+), 32 deletions(-)
delete mode 100644 board/sunxi/dram_sun4i_408_1024_iow8.c
diff --git a/board/sunxi/Makefile b/board/sunxi/Makefile
index 606bf73..0111b56 100644
--- a/board/sunxi/Makefile
+++ b/board/sunxi/Makefile
@@ -32,7 +32,7 @@ obj-$(CONFIG_TARGET_MELE_A1000) +=
dram_sun4i_auto.o
obj-$(CONFIG_TARGET_MELE_M3) += dram_sun7i_384_1024_iow16.o
obj-$(CONFIG_TARGET_MINI_X) += dram_sun4i_auto.o
obj-$(CONFIG_TARGET_MSI_PRIMO73) += dram_sun7i_384_1024_iow16.o
-obj-$(CONFIG_TARGET_PCDUINO) += dram_sun4i_408_1024_iow8.o
+obj-$(CONFIG_TARGET_PCDUINO) += dram_sun4i_auto.o
obj-$(CONFIG_TARGET_PCDUINO3) += dram_linksprite_pcduino3.o
obj-$(CONFIG_TARGET_QT840A) += dram_sun7i_384_512_busw16_iow16.o
obj-$(CONFIG_TARGET_R7DONGLE) += dram_r7dongle.o
diff --git a/board/sunxi/dram_sun4i_408_1024_iow8.c
b/board/sunxi/dram_sun4i_408_1024_iow8.c
deleted file mode 100644
index c6d87d2..000
--- a/board/sunxi/dram_sun4i_408_1024_iow8.c
+++ /dev/null
@@ -1,31 +0,0 @@
-/* this file is generated, don't edit it yourself */
-
-#include
-#include
-
-static struct dram_para dram_para = {
- .clock = 408,
- .type = 3,
- .rank_num = 1,
- .density = 2048,
- .io_width = 8,
- .bus_width = 32,
- .cas = 6,
- .zq = 123,
- .odt_en = 0,
- .size = 1024,
- .tpr0 = 0x30926692,
- .tpr1 = 0x1090,
- .tpr2 = 0x1a0c8,
- .tpr3 = 0,
- .tpr4 = 0,
- .tpr5 = 0,
- .emr1 = 0,
- .emr2 = 0,
- .emr3 = 0,
-};
-
-unsigned long sunxi_dram_init(void)
-{
- return dramc_init(&dram_para);
-}
diff --git a/configs/Linksprite_pcDuino_defconfig
b/configs/Linksprite_pcDuino_defconfig
index f5b0ca9..0bf329e 100644
--- a/configs/Linksprite_pcDuino_defconfig
+++ b/configs/Linksprite_pcDuino_defconfig
@@ -5,3 +5,6 @@ CONFIG_FDTFILE="sun4i-a10-pcduino.dtb"
+S:CONFIG_ARCH_SUNXI=y
+S:CONFIG_MACH_SUN4I=y
+S:CONFIG_TARGET_PCDUINO=y
++S:CONFIG_DRAM_CLK=408
++S:CONFIG_DRAM_ZQ=123
++S:CONFIG_DRAM_EMR1=0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] usb: musb-new: omap2430: Reset the MUSB controller early
When booting from USB peripheral boot, the bootrom will not properly deinit the
MUSB controller, which doesn't clearly indicate an USB disconnection to the host
and leaves U-Boot to deal with the state of the previous USB session.
On some host controller drivers (e.g. xhci_hcd), this ends up in a failure
during set address, caused by the lack of proper disconnection notification.
Resetting the controller early in U-Boot notifies the host of the disconnection
and doesn't hurt other use cases.
Signed-off-by: Paul Kocialkowski
---
drivers/usb/musb-new/omap2430.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/usb/musb-new/omap2430.c b/drivers/usb/musb-new/omap2430.c
index 98f4830..6b256bb 100644
--- a/drivers/usb/musb-new/omap2430.c
+++ b/drivers/usb/musb-new/omap2430.c
@@ -321,6 +321,7 @@ static int omap2430_musb_init(struct musb *musb)
{
u32 l;
int status = 0;
+ int timeout = 10;
#ifndef __UBOOT__
struct device *dev = musb->controller;
struct omap2430_glue *glue = dev_get_drvdata(dev->parent);
@@ -331,6 +332,22 @@ static int omap2430_musb_init(struct musb *musb)
(struct omap_musb_board_data *)musb->controller;
#endif
+ /* Reset the controller */
+ musb_writel(musb->mregs, OTG_SYSCONFIG, SOFTRST);
+
+ while (timeout--) {
+ l = musb_readl(musb->mregs, OTG_SYSCONFIG);
+
+ if (l & SOFTRST)
+ udelay(1);
+ else
+ break;
+ }
+
+ if (timeout == 0) {
+ dev_err(musb->controller, "MUSB reset is taking too long\n");
+ return -ENODEV;
+ }
#ifndef __UBOOT__
/* We require some kind of external transceiver, hooked
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/9] sunxi: Stop differentiating between 512M and 1G variants of the same board
Hi, On 18-01-15 17:22, Ian Campbell wrote: On Sun, 2015-01-18 at 13:23 +0100, Hans de Goede wrote: diff --git a/board/sunxi/dram_sun4i_auto.c b/board/sunxi/dram_sun4i_auto.c new file mode 100644 index 000..115b597 --- /dev/null +++ b/board/sunxi/dram_sun4i_auto.c @@ -0,0 +1,31 @@ +/* this file is generated, don't edit it yourself */ This isn't strictly true any more, is it? Yeah I was thinking the same thing when working on this but I wasn't sure what to do I'll drop the comment, as it is clearly false. And thanks for the reviews. Acked-by: Ian Campbell Regards, Hans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 7/9] sunxi: Add mk802 board / defconfig
On Sun, 2015-01-18 at 13:23 +0100, Hans de Goede wrote: > The mk802 is the "classic" Allwinner A10 based hdmi tv-stick, it features > 512M or 1G RAM, 4G nand, a mini-hdmi female connector, USB-A receptacle, > mini-usb receptacle (OTG) and USB-wifi. Somewhat unique the mk802 does not > use the AXP209 pmic, it does not have a pmic at all. > > For more details see: http://linux-sunxi.org/Rikomagic_mk802 > > Signed-off-by: Hans de Goede For the three mk802* patches (#7..#9), iff you add MAINTAINERS entries, then: Acked-by: Ian Campbell Ian. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Fastboot and MUSB driver on OMAP3
> > > The SET_ADDRESS request is received just fine, it then sets > > > musb->ep0_state = MUSB_EP0_STAGE_STATUSIN; but no IRQ arrives to trigger > > > another call to musb_g_ep0_irq. Eventually, the host just sends back > > > another SET_REQUEST. Looking at dmesg on the host (Device not responding > > > to set address), I guess that the device should send something back and > > > it apparently doesn't. > > Over the past few days, I have figured part of the problem (I am still > far from being done). I was loading the U-Boot SPL via USB, which > implies that the bootrom sets up the USB link first: that was the key to > that first issue. The controller was simply not being reset properly: > MUSB_POWER_SOFTCONN was still present in the MUSB_POWER register, so I > cleared it early and cleared the interrupt registers as well. Then, the > musb-new driver could work properly. Actually, issuing a software reset works just as well and seems cleaner to me. I will submit a patch about this. Apparently, this behaviour can be observed with xhci_hcd on the host (USB3), but not with ehci-pci (USB2), where it works fine. > While working on this, I flashed the U-Boot SPL to the internal memory. > When the device boots from it, with no USB cable attached, neither the > legacy musb driver nor musb-new work properly. I only get the first IRQ > and nothing more. However, as soon as I boot with the bootrom > initializing USB, it works in U-Boot. So there must be an extra step in > the initialization process that the bootrom is taking and U-Boot is > missing. > > I have looked at muxing and clocks, everything seems to be fine, so I'm > starting to run out of ideas. It turns out this was the MAX14526 MUIC not muxing the USB connector to the TWL. I suspect that it only does it automatically when VBUS is there during its initialization (which is the case when booting from USB, but not when booting with no USB cable attached). Of course, I will be submitting code for this along with the rest of the patches for LG Optimus Black (P970) codename sniper support when things are ready. -- Paul Kocialkowski, Replicant developer Replicant is a fully free Android distribution running on several devices, a free software mobile operating system putting the emphasis on freedom and privacy/security. Website: http://www.replicant.us/ Blog: http://blog.replicant.us/ Wiki/tracker/forums: http://redmine.replicant.us/ signature.asc Description: This is a digitally signed message part ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 6/9] sunxi: Remove CONFIG_TARGET_FOO for sun4i, sun6i and sun8i boards
On Sun, 2015-01-18 at 16:31 +, Ian Campbell wrote: > On Sun, 2015-01-18 at 13:23 +0100, Hans de Goede wrote: > > CONFIG_TARGET_FOO is only used in board/sunxi/Makefile to select the > > dram config for sun5i and sun7i boards and in board/sunxi/gmac.c for some > > special handling of the bananapi/bananapro (both sun7i), iow it is not used > > at all on any sun4i, sun6i and sun8i boards so lets get rid of it there. > > How close are we to being able to do the same for sun5i and/or sun7i? > > The banana* stuff probably ought to become CONFIG_SUNXI_GMAX_DELAY (or > whatever it was, you've told me like three times now but I can't seem to > retain it...) sooner rather than later. Oh, forgot the most important bit ;-) Acked-by: Ian Campbell Ian. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 6/9] sunxi: Remove CONFIG_TARGET_FOO for sun4i, sun6i and sun8i boards
On Sun, 2015-01-18 at 13:23 +0100, Hans de Goede wrote: > CONFIG_TARGET_FOO is only used in board/sunxi/Makefile to select the > dram config for sun5i and sun7i boards and in board/sunxi/gmac.c for some > special handling of the bananapi/bananapro (both sun7i), iow it is not used > at all on any sun4i, sun6i and sun8i boards so lets get rid of it there. How close are we to being able to do the same for sun5i and/or sun7i? The banana* stuff probably ought to become CONFIG_SUNXI_GMAX_DELAY (or whatever it was, you've told me like three times now but I can't seem to retain it...) sooner rather than later. Ian. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/9] sunxi: Convert sun4i boards to use auto dram configuration
On Sun, 2015-01-18 at 13:23 +0100, Hans de Goede wrote: > Currently we've separate detailed dram settings for all sun4i boards, this > moves them over to using auto dram configuration so that we can get rid of > all the per board dram_foo.c files. > > This been tested on a A10-OLinuXino-Lime, Chuwi_V7_CW0825 and > ba10_tv_box. Unless I'm mistaken that's one for each of the dram_*.c removed, good. > Signed-off-by: Hans de Goede Acked-by: Ian Campbell ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/9] sunxi: Convert Linksprite_pcDuino_defconfig to use auto dram configuration
On Sun, 2015-01-18 at 16:24 +, Ian Campbell wrote: > On Sun, 2015-01-18 at 13:23 +0100, Hans de Goede wrote: > > Currently we've separate detailed dram settings for all sun4i boards, this > > moves them > > There's only one board here, did you intend for the next patch to be > folder with this one as a bulk switch? Or is there something > particularly interesting about this one? Maybe you intended to Cc Zoltan who is listed in MAINTAINERS for this board for testing? (Whereas apparently you own all the ones in the next patch). ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/9] sunxi: Convert Linksprite_pcDuino_defconfig to use auto dram configuration
On Sun, 2015-01-18 at 13:23 +0100, Hans de Goede wrote:
> Currently we've separate detailed dram settings for all sun4i boards, this
> moves them
There's only one board here, did you intend for the next patch to be
folder with this one as a bulk switch? Or is there something
particularly interesting about this one?
> over to using auto dram configuration so that we can get rid of
> all the per board dram_foo.c files.
>
> Signed-off-by: Hans de Goede
> ---
> board/sunxi/Makefile | 2 +-
> board/sunxi/dram_sun4i_408_1024_iow8.c | 31 ---
> configs/Linksprite_pcDuino_defconfig | 3 +++
> 3 files changed, 4 insertions(+), 32 deletions(-)
> delete mode 100644 board/sunxi/dram_sun4i_408_1024_iow8.c
>
> diff --git a/board/sunxi/Makefile b/board/sunxi/Makefile
> index 606bf73..0111b56 100644
> --- a/board/sunxi/Makefile
> +++ b/board/sunxi/Makefile
> @@ -32,7 +32,7 @@ obj-$(CONFIG_TARGET_MELE_A1000) +=
> dram_sun4i_auto.o
> obj-$(CONFIG_TARGET_MELE_M3) += dram_sun7i_384_1024_iow16.o
> obj-$(CONFIG_TARGET_MINI_X) += dram_sun4i_auto.o
> obj-$(CONFIG_TARGET_MSI_PRIMO73) += dram_sun7i_384_1024_iow16.o
> -obj-$(CONFIG_TARGET_PCDUINO) += dram_sun4i_408_1024_iow8.o
> +obj-$(CONFIG_TARGET_PCDUINO) += dram_sun4i_auto.o
> obj-$(CONFIG_TARGET_PCDUINO3)+= dram_linksprite_pcduino3.o
> obj-$(CONFIG_TARGET_QT840A) += dram_sun7i_384_512_busw16_iow16.o
> obj-$(CONFIG_TARGET_R7DONGLE)+= dram_r7dongle.o
> diff --git a/board/sunxi/dram_sun4i_408_1024_iow8.c
> b/board/sunxi/dram_sun4i_408_1024_iow8.c
> deleted file mode 100644
> index c6d87d2..000
> --- a/board/sunxi/dram_sun4i_408_1024_iow8.c
> +++ /dev/null
> @@ -1,31 +0,0 @@
> -/* this file is generated, don't edit it yourself */
> -
> -#include
> -#include
> -
> -static struct dram_para dram_para = {
> - .clock = 408,
> - .type = 3,
> - .rank_num = 1,
> - .density = 2048,
> - .io_width = 8,
> - .bus_width = 32,
> - .cas = 6,
> - .zq = 123,
> - .odt_en = 0,
> - .size = 1024,
> - .tpr0 = 0x30926692,
> - .tpr1 = 0x1090,
> - .tpr2 = 0x1a0c8,
> - .tpr3 = 0,
> - .tpr4 = 0,
> - .tpr5 = 0,
> - .emr1 = 0,
> - .emr2 = 0,
> - .emr3 = 0,
> -};
> -
> -unsigned long sunxi_dram_init(void)
> -{
> - return dramc_init(&dram_para);
> -}
> diff --git a/configs/Linksprite_pcDuino_defconfig
> b/configs/Linksprite_pcDuino_defconfig
> index f5b0ca9..0bf329e 100644
> --- a/configs/Linksprite_pcDuino_defconfig
> +++ b/configs/Linksprite_pcDuino_defconfig
> @@ -5,3 +5,6 @@ CONFIG_FDTFILE="sun4i-a10-pcduino.dtb"
> +S:CONFIG_ARCH_SUNXI=y
> +S:CONFIG_MACH_SUN4I=y
> +S:CONFIG_TARGET_PCDUINO=y
> ++S:CONFIG_DRAM_CLK=408
> ++S:CONFIG_DRAM_ZQ=123
> ++S:CONFIG_DRAM_EMR1=0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/9] sunxi: Stop differentiating between 512M and 1G variants of the same board
On Sun, 2015-01-18 at 13:23 +0100, Hans de Goede wrote: > diff --git a/board/sunxi/dram_sun4i_auto.c b/board/sunxi/dram_sun4i_auto.c > new file mode 100644 > index 000..115b597 > --- /dev/null > +++ b/board/sunxi/dram_sun4i_auto.c > @@ -0,0 +1,31 @@ > +/* this file is generated, don't edit it yourself */ This isn't strictly true any more, is it? Acked-by: Ian Campbell Ian. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/9] sunxi: ba10_tv_box_defconfig: Fix USB not working
On Sun, 2015-01-18 at 13:23 +0100, Hans de Goede wrote: > PH12 is Vbus enable for Vbus2, not Vbus1. > > Signed-off-by: Hans de Goede Acked-by: Ian Campbell ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/9] sunxi: axp209: Disable interrupts when intializing the axp209
On Sun, 2015-01-18 at 13:23 +0100, Hans de Goede wrote: > We do not use the axp209 interrupt, and at least in my mini-x (which does not > have a power button) the pwr-button pin and the irq pin are soldered together, > so if the axp209 keeps it irq asserted to long it will see a 10s pwr-button > press and hard power off the board, disabling the irqs fixes this. > > Signed-off-by: Hans de Goede Acked-by: Ian Campbell ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 06/14] arm: mx6: cm-fx6: add hdmi console
Hi Soeren,
On 01/14/2015 01:34 PM, Soeren Moch wrote:
Add support for hdmi console.
Signed-off-by: Nikita Kiryanov
Cc: Stefano Babic
Cc: Igor Grinberg
---
board/compulab/cm_fx6/cm_fx6.c | 51
++
include/configs/cm_fx6.h | 15 +
2 files changed, 66 insertions(+)
[...]
+struct display_info_t const displays[] = {
+ {
+ .bus= -1,
+ .addr = 0,
+ .pixfmt = IPU_PIX_FMT_RGB24,
+ .detect = detect_hdmi,
+ .enable = cm_fx6_enable_hdmi,
+ .mode = {
+ .name = "HDMI",
+ .refresh= 60,
+ .xres = 1024,
+ .yres = 768,
+ .pixclock = 40385,
+ .left_margin= 220,
+ .right_margin = 40,
+ .upper_margin = 21,
+ .lower_margin = 7,
+ .hsync_len = 60,
+ .vsync_len = 10,
+ .sync = FB_SYNC_EXT,
+ .vmode = FB_VMODE_NONINTERLACED,
+ }
+ },
+};
This is not VESA compliant.
+static void cm_fx6_setup_display(void)
+{
+ struct mxc_ccm_reg *mxc_ccm = (struct mxc_ccm_reg *) CCM_BASE_ADDR;
+ int reg;
+
+ enable_ipu_clock();
+ imx_setup_hdmi();
+ reg = __raw_readl(&mxc_ccm->CCGR3);
+ reg |= MXC_CCM_CCGR3_IPU1_IPU_DI0_MASK;
+ writel(reg, &mxc_ccm->CCGR3);
+}
This will not give the correct pixel clock for a framerate of 60 frames
per second (as probably expected).
Just as a warning: Due to the non-standard video timing most hdmi
monitors will not work. For more compatible settings please have a look
into the tbs2910 board code.
Thanks for the pointer. I'll take a look at the tbs2910 code when I
expand the set of supported display presets. For now this is a
preliminary support.
--
Regards,
Nikita Kiryanov
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 8/9] sunxi: Add mk802ii board / defconfig
The mk802ii is a revised version of the mk802 A10 based hdmi tv-stick, it features 1G RAM, 4G nand, a hdmi male connector, USB-A receptacle, 2 micro usb receptacles (OTG & power) and USB-wifi, and does come with an axp209 pmic. For more details see: http://linux-sunxi.org/Rikomagic_mk802ii Signed-off-by: Hans de Goede --- configs/mk802ii_defconfig | 9 + 1 file changed, 9 insertions(+) create mode 100644 configs/mk802ii_defconfig diff --git a/configs/mk802ii_defconfig b/configs/mk802ii_defconfig new file mode 100644 index 000..500f4df --- /dev/null +++ b/configs/mk802ii_defconfig @@ -0,0 +1,9 @@ +CONFIG_SPL=y +CONFIG_SYS_EXTRA_OPTIONS="AXP209_POWER,USB_EHCI" +CONFIG_FDTFILE="sun4i-a10-mk802ii.dtb" ++S:CONFIG_ARM=y ++S:CONFIG_ARCH_SUNXI=y ++S:CONFIG_MACH_SUN4I=y ++S:CONFIG_DRAM_CLK=360 ++S:CONFIG_DRAM_ZQ=123 ++S:CONFIG_DRAM_EMR1=0 -- 2.1.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 5/9] sunxi: Convert sun4i boards to use auto dram configuration
Currently we've separate detailed dram settings for all sun4i boards, this
moves them over to using auto dram configuration so that we can get rid of
all the per board dram_foo.c files.
This been tested on a A10-OLinuXino-Lime, Chuwi_V7_CW0825 and
ba10_tv_box.
Signed-off-by: Hans de Goede
---
board/sunxi/Makefile| 8 +---
board/sunxi/dram_a10_olinuxino_l.c | 31 ---
board/sunxi/dram_sun4i_384_1024_iow8.c | 31 ---
board/sunxi/dram_sun4i_408_1024_iow16.c | 31 ---
configs/A10-OLinuXino-Lime_defconfig| 3 +++
configs/Chuwi_V7_CW0825_defconfig | 3 +++
configs/ba10_tv_box_defconfig | 3 +++
7 files changed, 10 insertions(+), 100 deletions(-)
delete mode 100644 board/sunxi/dram_a10_olinuxino_l.c
delete mode 100644 board/sunxi/dram_sun4i_384_1024_iow8.c
delete mode 100644 board/sunxi/dram_sun4i_408_1024_iow16.c
diff --git a/board/sunxi/Makefile b/board/sunxi/Makefile
index 0111b56..f838e7b 100644
--- a/board/sunxi/Makefile
+++ b/board/sunxi/Makefile
@@ -11,7 +11,7 @@
obj-y += board.o
obj-$(CONFIG_SUNXI_GMAC) += gmac.o
obj-$(CONFIG_SUNXI_AHCI) += ahci.o
-obj-$(CONFIG_TARGET_A10_OLINUXINO_L) += dram_a10_olinuxino_l.o
+obj-$(CONFIG_MACH_SUN4I) += dram_sun4i_auto.o
obj-$(CONFIG_TARGET_A10S_OLINUXINO_M) += dram_a10s_olinuxino_m.o
obj-$(CONFIG_TARGET_A13_OLINUXINO) += dram_a13_olinuxino.o
obj-$(CONFIG_TARGET_A13_OLINUXINOM)+= dram_a13_oli_micro.o
@@ -20,19 +20,13 @@ obj-$(CONFIG_TARGET_A20_OLINUXINO_L2) +=
dram_a20_olinuxino_l2.o
obj-$(CONFIG_TARGET_A20_OLINUXINO_M) += dram_sun7i_384_1024_iow16.o
# This is not a typo, uses the same mem settings as the a10s-olinuxino-m
obj-$(CONFIG_TARGET_AUXTEK_T004) += dram_a10s_olinuxino_m.o
-obj-$(CONFIG_TARGET_BA10_TV_BOX) += dram_sun4i_384_1024_iow8.o
obj-$(CONFIG_TARGET_BANANAPI) += dram_bananapi.o
obj-$(CONFIG_TARGET_BANANAPRO) += dram_bananapi.o
-obj-$(CONFIG_TARGET_CHUWI_V7_CW0825) += dram_sun4i_408_1024_iow16.o
-obj-$(CONFIG_TARGET_CUBIEBOARD)+= dram_sun4i_auto.o
obj-$(CONFIG_TARGET_CUBIEBOARD2) += dram_cubieboard2.o
obj-$(CONFIG_TARGET_CUBIETRUCK)+= dram_cubietruck.o
obj-$(CONFIG_TARGET_I12_TVBOX) += dram_sun7i_384_1024_iow16.o
-obj-$(CONFIG_TARGET_MELE_A1000)+= dram_sun4i_auto.o
obj-$(CONFIG_TARGET_MELE_M3) += dram_sun7i_384_1024_iow16.o
-obj-$(CONFIG_TARGET_MINI_X)+= dram_sun4i_auto.o
obj-$(CONFIG_TARGET_MSI_PRIMO73) += dram_sun7i_384_1024_iow16.o
-obj-$(CONFIG_TARGET_PCDUINO) += dram_sun4i_auto.o
obj-$(CONFIG_TARGET_PCDUINO3) += dram_linksprite_pcduino3.o
obj-$(CONFIG_TARGET_QT840A)+= dram_sun7i_384_512_busw16_iow16.o
obj-$(CONFIG_TARGET_R7DONGLE) += dram_r7dongle.o
diff --git a/board/sunxi/dram_a10_olinuxino_l.c
b/board/sunxi/dram_a10_olinuxino_l.c
deleted file mode 100644
index 24a1bd9..000
--- a/board/sunxi/dram_a10_olinuxino_l.c
+++ /dev/null
@@ -1,31 +0,0 @@
-/* this file is generated, don't edit it yourself */
-
-#include
-#include
-
-static struct dram_para dram_para = {
- .clock = 480,
- .type = 3,
- .rank_num = 1,
- .density = 4096,
- .io_width = 16,
- .bus_width = 16,
- .cas = 6,
- .zq = 123,
- .odt_en = 0,
- .size = 512,
- .tpr0 = 0x30926692,
- .tpr1 = 0x1090,
- .tpr2 = 0x1a0c8,
- .tpr3 = 0,
- .tpr4 = 0,
- .tpr5 = 0,
- .emr1 = 0x4,
- .emr2 = 0,
- .emr3 = 0,
-};
-
-unsigned long sunxi_dram_init(void)
-{
- return dramc_init(&dram_para);
-}
diff --git a/board/sunxi/dram_sun4i_384_1024_iow8.c
b/board/sunxi/dram_sun4i_384_1024_iow8.c
deleted file mode 100644
index b0fcc55..000
--- a/board/sunxi/dram_sun4i_384_1024_iow8.c
+++ /dev/null
@@ -1,31 +0,0 @@
-/* this file is generated, don't edit it yourself */
-
-#include
-#include
-
-static struct dram_para dram_para = {
- .clock = 384,
- .type = 3,
- .rank_num = 1,
- .density = 2048,
- .io_width = 8,
- .bus_width = 32,
- .cas = 6,
- .zq = 123,
- .odt_en = 0,
- .size = 1024,
- .tpr0 = 0x30926692,
- .tpr1 = 0x1090,
- .tpr2 = 0x1a0c8,
- .tpr3 = 0,
- .tpr4 = 0,
- .tpr5 = 0,
- .emr1 = 0x4,
- .emr2 = 0,
- .emr3 = 0,
-};
-
-unsigned long sunxi_dram_init(void)
-{
- return dramc_init(&dram_para);
-}
diff --git a/board/sunxi/dram_sun4i_408_1024_iow16.c
b/board/sunxi/dram_sun4i_408_1024_iow16.c
deleted file mode 100644
index 1bc9f73..000
--- a/board/sunxi/dram_sun4i_408_1024_iow16.c
+++ /dev/null
@@ -1,31 +0,0 @@
-/* this file is generated, don't edit it yourself */
-
-#include
-#include
-
-static struct dram_para dram_para = {
- .clock = 408,
- .type = 3,
- .rank_num = 1,
- .density = 4096,
[U-Boot] [PATCH 9/9] sunxi: Add mk802_a10s board / defconfig
The mk802_a10s re-uses is the "classic" mk802 case and functionality, but has
an A10s SoC inside rather then the A10, it features 512M or 1G RAM, 4G nand,
a mini-hdmi female connector, USB-A receptacle, mini-usb receptacle (OTG)
and a sdio realtek wifi chip. Unlike the original mk802 it does have a pmic,
the axp152.
For more details see: http://linux-sunxi.org/Semitime_g2
Signed-off-by: Hans de Goede
---
board/sunxi/Kconfig | 4
board/sunxi/Makefile | 1 +
board/sunxi/dram_sun5i_auto.c | 31 +++
configs/mk802_a10s_defconfig | 11 +++
4 files changed, 47 insertions(+)
create mode 100644 board/sunxi/dram_sun5i_auto.c
create mode 100644 configs/mk802_a10s_defconfig
diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig
index b9c25cc..c5ce099 100644
--- a/board/sunxi/Kconfig
+++ b/board/sunxi/Kconfig
@@ -127,6 +127,10 @@ config TARGET_MELE_M3
bool "MELE_M3"
depends on MACH_SUN7I
+config TARGET_MK802_A10S
+ bool "MK802_A10S"
+ depends on MACH_SUN5I
+
config TARGET_MSI_PRIMO73
bool "MSI Primo73 (7\" tablet)"
depends on MACH_SUN7I
diff --git a/board/sunxi/Makefile b/board/sunxi/Makefile
index f838e7b..feb439a 100644
--- a/board/sunxi/Makefile
+++ b/board/sunxi/Makefile
@@ -26,6 +26,7 @@ obj-$(CONFIG_TARGET_CUBIEBOARD2) += dram_cubieboard2.o
obj-$(CONFIG_TARGET_CUBIETRUCK)+= dram_cubietruck.o
obj-$(CONFIG_TARGET_I12_TVBOX) += dram_sun7i_384_1024_iow16.o
obj-$(CONFIG_TARGET_MELE_M3) += dram_sun7i_384_1024_iow16.o
+obj-$(CONFIG_TARGET_MK802_A10S)+= dram_sun5i_auto.o
obj-$(CONFIG_TARGET_MSI_PRIMO73) += dram_sun7i_384_1024_iow16.o
obj-$(CONFIG_TARGET_PCDUINO3) += dram_linksprite_pcduino3.o
obj-$(CONFIG_TARGET_QT840A)+= dram_sun7i_384_512_busw16_iow16.o
diff --git a/board/sunxi/dram_sun5i_auto.c b/board/sunxi/dram_sun5i_auto.c
new file mode 100644
index 000..a5965db
--- /dev/null
+++ b/board/sunxi/dram_sun5i_auto.c
@@ -0,0 +1,31 @@
+/* this file is generated, don't edit it yourself */
+
+#include
+#include
+
+static struct dram_para dram_para = {
+ .clock = CONFIG_DRAM_CLK,
+ .type = 3,
+ .rank_num = 1,
+ .density = 0,
+ .io_width = 0,
+ .bus_width = 0,
+ .cas = 9,
+ .zq = CONFIG_DRAM_ZQ,
+ .odt_en = 0,
+ .size = 0,
+ .tpr0 = 0x42d899b7,
+ .tpr1 = 0xa090,
+ .tpr2 = 0x22a00,
+ .tpr3 = 0,
+ .tpr4 = 0,
+ .tpr5 = 0,
+ .emr1 = CONFIG_DRAM_EMR1,
+ .emr2 = 0x10,
+ .emr3 = 0,
+};
+
+unsigned long sunxi_dram_init(void)
+{
+ return dramc_init(&dram_para);
+}
diff --git a/configs/mk802_a10s_defconfig b/configs/mk802_a10s_defconfig
new file mode 100644
index 000..086e1e4
--- /dev/null
+++ b/configs/mk802_a10s_defconfig
@@ -0,0 +1,11 @@
+CONFIG_SPL=y
+CONFIG_SYS_EXTRA_OPTIONS="AXP152_POWER,USB_EHCI"
+CONFIG_FDTFILE="sun5i-a10s-mk802.dtb"
+CONFIG_USB1_VBUS_PIN="PB10"
++S:CONFIG_ARM=y
++S:CONFIG_ARCH_SUNXI=y
++S:CONFIG_MACH_SUN5I=y
++S:CONFIG_TARGET_MK802_A10S=y
++S:CONFIG_DRAM_CLK=432
++S:CONFIG_DRAM_ZQ=123
++S:CONFIG_DRAM_EMR1=0
--
2.1.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 6/9] sunxi: Remove CONFIG_TARGET_FOO for sun4i, sun6i and sun8i boards
CONFIG_TARGET_FOO is only used in board/sunxi/Makefile to select the dram config for sun5i and sun7i boards and in board/sunxi/gmac.c for some special handling of the bananapi/bananapro (both sun7i), iow it is not used at all on any sun4i, sun6i and sun8i boards so lets get rid of it there. Signed-off-by: Hans de Goede --- board/sunxi/Kconfig | 57 configs/A10-OLinuXino-Lime_defconfig | 1 - configs/CSQ_CS908_defconfig | 1 - configs/Chuwi_V7_CW0825_defconfig| 1 - configs/Colombus_defconfig | 1 - configs/Cubieboard_defconfig | 1 - configs/Hummingbird_A31_defconfig| 1 - configs/Linksprite_pcDuino_defconfig | 1 - configs/MSI_Primo81_defconfig| 10 ++- configs/Mele_A1000_defconfig | 1 - configs/Mele_M9_defconfig| 1 - configs/Mini-X_defconfig | 1 - configs/ba10_tv_box_defconfig| 1 - 13 files changed, 9 insertions(+), 69 deletions(-) diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig index f7064d0..b9c25cc 100644 --- a/board/sunxi/Kconfig +++ b/board/sunxi/Kconfig @@ -75,10 +75,6 @@ config SYS_CONFIG_NAME choice prompt "Board" -config TARGET_A10_OLINUXINO_L - bool "A10_OLINUXINO_L" - depends on MACH_SUN4I - config TARGET_A10S_OLINUXINO_M bool "A10S_OLINUXINO_M" depends on MACH_SUN5I @@ -115,58 +111,22 @@ config TARGET_BANANAPRO bool "BANANAPRO" depends on MACH_SUN7I -config TARGET_CHUWI_V7_CW0825 - bool "CHUWI_V7_CW0825" - depends on MACH_SUN4I - -config TARGET_COLOMBUS - bool "COLOMBUS" - depends on MACH_SUN6I - config TARGET_CUBIEBOARD2 bool "CUBIEBOARD2" depends on MACH_SUN7I -config TARGET_CUBIEBOARD - bool "CUBIEBOARD" - depends on MACH_SUN4I - config TARGET_CUBIETRUCK bool "CUBIETRUCK" depends on MACH_SUN7I -config TARGET_HUMMINGBIRD_A31 - bool "HUMMINGBIRD_A31" - depends on MACH_SUN6I - -config TARGET_IPPO_Q8H_V5 - bool "IPPO_Q8H_V5" - depends on MACH_SUN8I - -config TARGET_PCDUINO - bool "PCDUINO" - depends on MACH_SUN4I - config TARGET_PCDUINO3 bool "PCDUINO3" depends on MACH_SUN7I -config TARGET_MELE_A1000 - bool "MELE_A1000" - depends on MACH_SUN4I - config TARGET_MELE_M3 bool "MELE_M3" depends on MACH_SUN7I -config TARGET_MELE_M9 - bool "MELE_M9" - depends on MACH_SUN6I - -config TARGET_MINI_X - bool "MINI_X" - depends on MACH_SUN4I - config TARGET_MSI_PRIMO73 bool "MSI Primo73 (7\" tablet)" depends on MACH_SUN7I @@ -180,23 +140,6 @@ config TARGET_MSI_PRIMO73 OTG and 3.5mm headphone jack. More details are available at http://linux-sunxi.org/MSI_Primo73 -config TARGET_MSI_PRIMO81 - bool "MSI Primo81 (7.85\" tablet)" - depends on MACH_SUN6I - ---help--- - The MSI Primo81 is an A31s based tablet, with 1G RAM, 16G NAND, - 1024x768 IPS LCD display, mono speaker, 0.3 MP front camera, 2.0 MP - rear camera, 3500 mAh battery, gt911 touchscreen, mma8452 accelerometer - and rtl8188etv usb wifi. Has "power", "volume+" and "volume-" buttons - (both volume buttons are also connected to the UBOOT_SEL pin). The - external connectors are represented by MicroSD slot, MiniHDMI, MicroUSB - OTG and 3.5mm headphone jack. More details are available at - http://linux-sunxi.org/MSI_Primo81 - -config TARGET_BA10_TV_BOX - bool "BA10_TV_BOX" - depends on MACH_SUN4I - config TARGET_I12_TVBOX bool "I12_TVBOX" depends on MACH_SUN7I diff --git a/configs/A10-OLinuXino-Lime_defconfig b/configs/A10-OLinuXino-Lime_defconfig index ac7adc8..8fa1a33 100644 --- a/configs/A10-OLinuXino-Lime_defconfig +++ b/configs/A10-OLinuXino-Lime_defconfig @@ -4,7 +4,6 @@ CONFIG_FDTFILE="sun4i-a10-olinuxino-lime.dtb" +S:CONFIG_ARM=y +S:CONFIG_ARCH_SUNXI=y +S:CONFIG_MACH_SUN4I=y -+S:CONFIG_TARGET_A10_OLINUXINO_L=y +S:CONFIG_DRAM_CLK=480 +S:CONFIG_DRAM_ZQ=123 +S:CONFIG_DRAM_EMR1=4 diff --git a/configs/CSQ_CS908_defconfig b/configs/CSQ_CS908_defconfig index 1b6cdbf..4040bee 100644 --- a/configs/CSQ_CS908_defconfig +++ b/configs/CSQ_CS908_defconfig @@ -4,7 +4,6 @@ CONFIG_FDTFILE="sun6i-a31s-cs908.dtb" +S:CONFIG_ARM=y +S:CONFIG_ARCH_SUNXI=y +S:CONFIG_MACH_SUN6I=y -+S:CONFIG_TARGET_CSQ_CS908=y +S:CONFIG_DRAM_CLK=432 +S:CONFIG_DRAM_ZQ=123 # Ethernet phy power diff --git a/configs/Chuwi_V7_CW0825_defconfig b/configs/Chuwi_V7_CW0825_defconfig index 9617907..3141024 100644 --- a/configs/Chuwi_V7_CW0825_defconfig +++ b/configs/Chuwi_V7_CW0825_defconfig @@ -11,7 +11,6 @@ CONFIG_VIDEO_LCD_PANEL_HITACHI_TX18D42VM=y +S:CONFIG_ARM=y +S:CONFIG_ARCH_SUNXI=y +S:CONFIG_MACH_SUN4I=y -+S:CONFIG_TARGET_CHUWI_V7_CW0825=y +S:CONFIG_DRAM_CLK=408 +S:CONFIG_DRAM_ZQ=123 +S:CONFIG_DRAM_EMR1=4 diff --git a/configs/Colombus_de
[U-Boot] [PATCH 4/9] sunxi: Convert Linksprite_pcDuino_defconfig to use auto dram configuration
Currently we've separate detailed dram settings for all sun4i boards, this
moves them over to using auto dram configuration so that we can get rid of
all the per board dram_foo.c files.
Signed-off-by: Hans de Goede
---
board/sunxi/Makefile | 2 +-
board/sunxi/dram_sun4i_408_1024_iow8.c | 31 ---
configs/Linksprite_pcDuino_defconfig | 3 +++
3 files changed, 4 insertions(+), 32 deletions(-)
delete mode 100644 board/sunxi/dram_sun4i_408_1024_iow8.c
diff --git a/board/sunxi/Makefile b/board/sunxi/Makefile
index 606bf73..0111b56 100644
--- a/board/sunxi/Makefile
+++ b/board/sunxi/Makefile
@@ -32,7 +32,7 @@ obj-$(CONFIG_TARGET_MELE_A1000) +=
dram_sun4i_auto.o
obj-$(CONFIG_TARGET_MELE_M3) += dram_sun7i_384_1024_iow16.o
obj-$(CONFIG_TARGET_MINI_X)+= dram_sun4i_auto.o
obj-$(CONFIG_TARGET_MSI_PRIMO73) += dram_sun7i_384_1024_iow16.o
-obj-$(CONFIG_TARGET_PCDUINO) += dram_sun4i_408_1024_iow8.o
+obj-$(CONFIG_TARGET_PCDUINO) += dram_sun4i_auto.o
obj-$(CONFIG_TARGET_PCDUINO3) += dram_linksprite_pcduino3.o
obj-$(CONFIG_TARGET_QT840A)+= dram_sun7i_384_512_busw16_iow16.o
obj-$(CONFIG_TARGET_R7DONGLE) += dram_r7dongle.o
diff --git a/board/sunxi/dram_sun4i_408_1024_iow8.c
b/board/sunxi/dram_sun4i_408_1024_iow8.c
deleted file mode 100644
index c6d87d2..000
--- a/board/sunxi/dram_sun4i_408_1024_iow8.c
+++ /dev/null
@@ -1,31 +0,0 @@
-/* this file is generated, don't edit it yourself */
-
-#include
-#include
-
-static struct dram_para dram_para = {
- .clock = 408,
- .type = 3,
- .rank_num = 1,
- .density = 2048,
- .io_width = 8,
- .bus_width = 32,
- .cas = 6,
- .zq = 123,
- .odt_en = 0,
- .size = 1024,
- .tpr0 = 0x30926692,
- .tpr1 = 0x1090,
- .tpr2 = 0x1a0c8,
- .tpr3 = 0,
- .tpr4 = 0,
- .tpr5 = 0,
- .emr1 = 0,
- .emr2 = 0,
- .emr3 = 0,
-};
-
-unsigned long sunxi_dram_init(void)
-{
- return dramc_init(&dram_para);
-}
diff --git a/configs/Linksprite_pcDuino_defconfig
b/configs/Linksprite_pcDuino_defconfig
index f5b0ca9..0bf329e 100644
--- a/configs/Linksprite_pcDuino_defconfig
+++ b/configs/Linksprite_pcDuino_defconfig
@@ -5,3 +5,6 @@ CONFIG_FDTFILE="sun4i-a10-pcduino.dtb"
+S:CONFIG_ARCH_SUNXI=y
+S:CONFIG_MACH_SUN4I=y
+S:CONFIG_TARGET_PCDUINO=y
++S:CONFIG_DRAM_CLK=408
++S:CONFIG_DRAM_ZQ=123
++S:CONFIG_DRAM_EMR1=0
--
2.1.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 7/9] sunxi: Add mk802 board / defconfig
The mk802 is the "classic" Allwinner A10 based hdmi tv-stick, it features 512M or 1G RAM, 4G nand, a mini-hdmi female connector, USB-A receptacle, mini-usb receptacle (OTG) and USB-wifi. Somewhat unique the mk802 does not use the AXP209 pmic, it does not have a pmic at all. For more details see: http://linux-sunxi.org/Rikomagic_mk802 Signed-off-by: Hans de Goede --- configs/mk802_defconfig | 10 ++ 1 file changed, 10 insertions(+) create mode 100644 configs/mk802_defconfig diff --git a/configs/mk802_defconfig b/configs/mk802_defconfig new file mode 100644 index 000..d6b51a5 --- /dev/null +++ b/configs/mk802_defconfig @@ -0,0 +1,10 @@ +CONFIG_SPL=y +CONFIG_SYS_EXTRA_OPTIONS="USB_EHCI" +CONFIG_FDTFILE="sun4i-a10-mk802.dtb" +CONFIG_USB2_VBUS_PIN="PH12" ++S:CONFIG_ARM=y ++S:CONFIG_ARCH_SUNXI=y ++S:CONFIG_MACH_SUN4I=y ++S:CONFIG_DRAM_CLK=360 ++S:CONFIG_DRAM_ZQ=123 ++S:CONFIG_DRAM_EMR1=0 -- 2.1.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/9] sunxi: Stop differentiating between 512M and 1G variants of the same board
While working on adding more boards I noticed that we lack a config for
the 512M cubieboard, and that some of the new boards which I want to add also
have 512M and 1G variants, rather then adding 2 defconfig's for all of these,
lets switch the exising boards which have both a 512M and 1024M variant over
to the sun4i dram autoconfig code.
This also drops the foo_RAMSIZE_defconfig variants of boards where we currently
have 2 separate configs already.
Note:
1) The newly introduced CONFIG_DRAM_EMR1 kconfig value is not used with
a value other then its default for now, but we need this to be configurable
to support some new boards with auto dram config.
2) We always set all CONFIG_DRAM_foo values in defconfigs, even if they match
the defaults, this is done to make it more clear what values are used for a
certain board.
This has been tested on a Mele A1000, Mini-X and a Cubieboard, all 1G
variants, the dram autoconfig code has also been tested on a 512M mk802
(a defconfig for the mk802 is added in a later patch).
Signed-off-by: Hans de Goede
---
arch/arm/include/asm/arch-sunxi/dram_sun4i.h | 2 +-
board/sunxi/Kconfig | 36 +++-
board/sunxi/MAINTAINERS | 2 --
board/sunxi/Makefile | 8 +++
board/sunxi/dram_cubieboard.c| 31
board/sunxi/dram_sun4i_360_1024_iow16.c | 31
board/sunxi/dram_sun4i_360_1024_iow8.c | 31
board/sunxi/dram_sun4i_360_512.c | 31
board/sunxi/dram_sun4i_auto.c| 31
configs/Cubieboard_defconfig | 3 +++
configs/Mele_A1000G_defconfig| 8 ---
configs/Mele_A1000_defconfig | 3 +++
configs/Mini-X-1Gb_defconfig | 7 --
configs/Mini-X_defconfig | 3 +++
14 files changed, 63 insertions(+), 164 deletions(-)
delete mode 100644 board/sunxi/dram_cubieboard.c
delete mode 100644 board/sunxi/dram_sun4i_360_1024_iow16.c
delete mode 100644 board/sunxi/dram_sun4i_360_1024_iow8.c
delete mode 100644 board/sunxi/dram_sun4i_360_512.c
create mode 100644 board/sunxi/dram_sun4i_auto.c
delete mode 100644 configs/Mele_A1000G_defconfig
delete mode 100644 configs/Mini-X-1Gb_defconfig
diff --git a/arch/arm/include/asm/arch-sunxi/dram_sun4i.h
b/arch/arm/include/asm/arch-sunxi/dram_sun4i.h
index 6c1ec5b..40c385a 100644
--- a/arch/arm/include/asm/arch-sunxi/dram_sun4i.h
+++ b/arch/arm/include/asm/arch-sunxi/dram_sun4i.h
@@ -76,7 +76,7 @@ struct dram_para {
u32 cas;
u32 zq;
u32 odt_en;
- u32 size;
+ u32 size; /* For compat with dram.c files from u-boot-sunxi, unused */
u32 tpr0;
u32 tpr1;
u32 tpr2;
diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig
index e65b8af..f7064d0 100644
--- a/board/sunxi/Kconfig
+++ b/board/sunxi/Kconfig
@@ -37,21 +37,31 @@ config MACH_SUN9I
endchoice
-if MACH_SUN6I || MACH_SUN8I
-
config DRAM_CLK
- int "sun6i dram clock speed"
- default 312
+ int "sunxi dram clock speed"
+ default 312 if MACH_SUN6I || MACH_SUN8I
+ default 360 if MACH_SUN4I || MACH_SUN5I || MACH_SUN7I
---help---
Set the dram clock speed, valid range 240 - 480, must be a multiple
- of 24.
+ of 24. Note on sun4i / sun5i / sun7i this is only used by boards
+ which use dram autoconfig.
config DRAM_ZQ
- int "sun6i dram zq value"
- default 123
+ int "sunxi dram zq value"
+ default 123 if MACH_SUN4I || MACH_SUN5I || MACH_SUN6I || MACH_SUN8I
+ default 127 if MACH_SUN7I
---help---
- Set the dram zq value.
-
+ Set the dram zq value. Note on sun4i / sun5i / sun7i this is only
+ used by boards which use dram autoconfig.
+
+if MACH_SUN4I || MACH_SUN5I || MACH_SUN7I
+config DRAM_EMR1
+ int "sunxi dram emr1 value"
+ default 0 if MACH_SUN4I
+ default 4 if MACH_SUN5I || MACH_SUN7I
+ ---help---
+ Set the dram controller emr1 value. Note this is only used by boards
+ which use dram autoconfig.
endif
config SYS_CONFIG_NAME
@@ -141,10 +151,6 @@ config TARGET_PCDUINO3
bool "PCDUINO3"
depends on MACH_SUN7I
-config TARGET_MELE_A1000G
- bool "MELE_A1000G"
- depends on MACH_SUN4I
-
config TARGET_MELE_A1000
bool "MELE_A1000"
depends on MACH_SUN4I
@@ -157,10 +163,6 @@ config TARGET_MELE_M9
bool "MELE_M9"
depends on MACH_SUN6I
-config TARGET_MINI_X_1GB
- bool "MINI_X_1GB"
- depends on MACH_SUN4I
-
config TARGET_MINI_X
bool "MINI_X"
depends on MACH_SUN4I
diff --git a/board/sunxi/MAINTAINERS b/board/sunxi/MAINTAINERS
index 7cd0b20..16429d4 100644
--- a/board/sunxi/MAINTAINERS
+++ b/board/sunxi/MAINTAINERS
@@ -8,10 +8,8 @@ F: configs/ba10_tv_box_defconfig
[U-Boot] [PATCH 1/9] sunxi: axp209: Disable interrupts when intializing the axp209
We do not use the axp209 interrupt, and at least in my mini-x (which does not
have a power button) the pwr-button pin and the irq pin are soldered together,
so if the axp209 keeps it irq asserted to long it will see a 10s pwr-button
press and hard power off the board, disabling the irqs fixes this.
Signed-off-by: Hans de Goede
---
drivers/power/axp209.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/power/axp209.c b/drivers/power/axp209.c
index 3b1a6a7..4565398 100644
--- a/drivers/power/axp209.c
+++ b/drivers/power/axp209.c
@@ -16,6 +16,11 @@ enum axp209_reg {
AXP209_DCDC3_VOLTAGE = 0x27,
AXP209_LDO24_VOLTAGE = 0x28,
AXP209_LDO3_VOLTAGE = 0x29,
+ AXP209_IRQ_ENABLE1 = 0x40,
+ AXP209_IRQ_ENABLE2 = 0x41,
+ AXP209_IRQ_ENABLE3 = 0x42,
+ AXP209_IRQ_ENABLE4 = 0x43,
+ AXP209_IRQ_ENABLE5 = 0x44,
AXP209_IRQ_STATUS5 = 0x4c,
AXP209_SHUTDOWN = 0x32,
AXP209_GPIO0_CTRL = 0x90,
@@ -143,7 +148,7 @@ int axp209_set_ldo4(int mvolt)
int axp209_init(void)
{
u8 ver;
- int rc;
+ int i, rc;
rc = axp209_read(AXP209_CHIP_VERSION, &ver);
if (rc)
@@ -155,6 +160,13 @@ int axp209_init(void)
if (ver != 0x1)
return -1;
+ /* Mask all interrupts */
+ for (i = AXP209_IRQ_ENABLE1; i <= AXP209_IRQ_ENABLE5; i++) {
+ rc = axp209_write(i, 0);
+ if (rc)
+ return rc;
+ }
+
return 0;
}
--
2.1.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/9] sunxi: ba10_tv_box_defconfig: Fix USB not working
PH12 is Vbus enable for Vbus2, not Vbus1. Signed-off-by: Hans de Goede --- configs/ba10_tv_box_defconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configs/ba10_tv_box_defconfig b/configs/ba10_tv_box_defconfig index 6ca7c57..37bf51b 100644 --- a/configs/ba10_tv_box_defconfig +++ b/configs/ba10_tv_box_defconfig @@ -1,7 +1,7 @@ CONFIG_SPL=y CONFIG_SYS_EXTRA_OPTIONS="AXP209_POWER,SUNXI_EMAC,USB_EHCI" CONFIG_FDTFILE="sun4i-a10-ba10-tvbox.dtb" -CONFIG_USB1_VBUS_PIN="PH12" +CONFIG_USB2_VBUS_PIN="PH12" +S:CONFIG_ARM=y +S:CONFIG_ARCH_SUNXI=y +S:CONFIG_MACH_SUN4I=y -- 2.1.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] sunxi: display: Make lcd display clk phase configurable
Hi, On 18-01-15 12:33, Siarhei Siamashka wrote: On Tue, 13 Jan 2015 13:33:32 +0100 Hans de Goede wrote: While running some tests with an Olinuxino-A13-Micro + a 7" Olimex LCD module I noticed that the screen flickered. This is caused by the lcd display clk phase reg value being set to 0, where it should be 1 in this setup. This commit adds a Kconfig option for the lcd display clk phase, so that we can set it per board. This defaults to 1, because looking at all the fex files in sunxi-boards, that is by far the most used value. What is the name of this option in fex files? Good question on sun4i / sun5i / sun7i it is stored in lcd_io_cfg0 but as a raw register value, rather then the clk phase value, so you need to shift right by 28 to get the actual value, e.g.: lcd_io_cfg0 = 268435456 Means (0x1000 >> 28) == 1 On sun6i / sun8i it is not clear, the allwinner kernel code uses lcd_hv_clk_phase which gets converted to an actual register value in a complicated method unfortunately, see the allwinner kernel sources. Where as the fex files seem to use lcd_io_phase which is not used by the kernel AFAICT ... Looking at the register values used under android it just seems to end up being 0 on sun6i / sun8i. Regards, Hans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 00/14] cm-fx6 updates and a new splash screen feature
Hi Simon, On 01/15/2015 12:48 AM, Simon Glass wrote: Hi Nikita, On 14 January 2015 at 01:42, Nikita Kiryanov wrote: This series consists of updates for cm-fx6. Some of these updates (specifically: compulab: splash: use errno values compulab: splash: refactor splash.c compulab: splash: support multiple splash sources compulab: splash: support loading splash from sf) produce an end result which is not really compulab specific and could be useful for other boards as well, so as a last step in the series this code is converted to common code (common: convert compulab splash load code to common code). The new feature: CONFIG_SPLASH_SOURCE This user option will enable splash_source.c, a module which implements a standard way for boards to define a collection of splash screen locations, as well as routines for loading the splash image into memory. When invoked using splash_source_load(locations, size), the module will consult the environment variable "splashsource" and compare its value with the splash location names as provided by board code. If there's a match, that splash location is used. If there's no mach, no splash image will be loaded. If splashsource is left undefined, the first splash location is used as default. Are you planning to work on joining up video and lcd beyond this series? Yes. I already started working on the next step. Regards, Simon -- Regards, Nikita Kiryanov ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PULL] u-boot-usb/master
The following changes since commit ab77f24119e80257de4ab017b877f92f96980562: Merge branch 'master' of git://git.denx.de/u-boot-ti (2015-01-16 10:25:01 -0500) are available in the git repository at: git://git.denx.de/u-boot-usb.git master for you to fetch changes up to 119339759266b81af1aa8883702b6b651d7752dd: usb: eth: asix88179: add ability to modify MAC address (2015-01-18 12:31:36 +0100) Alex Sadovsky (1): usb: gadget: pxa25x_udc: fix use-before-initialized bug Hans de Goede (13): USB: make "usb start" start usb only once config_distro_bootcmd.h: Remove unnecessary magic to avoid repeated USB scans usb: Add an interval parameter to create_int_queue usb: Fix usb_kbd_deregister when console-muxing is used usb: Do not log an error when no devices is plugged into a root-hub-less hcd musb-new: Add register defines for different reg layout on sunxi musb-new: Add sunxi musb controller support musb-new: Use time based timeouts rather then cpu-cycles based timeouts musb-new: Fix interrupt transfers not working musb-new: Fix reset sequence when in host mode musb-new: Properly remove a transfer from the schedule on timeout musb-new: Add urb and hep parameters to construct_urb musb-new: Add interrupt queue support Rene Griessl (1): usb: eth: asix88179: add ability to modify MAC address Stefan Roese (2): usb: gadget: composite: Fix NULL pointer crash in USB compliance test usb: gadget: f_dfu: Add get_alt function to pass the USB compliance test common/cmd_usb.c | 48 +++--- common/usb.c | 11 +++-- common/usb_kbd.c | 10 +++- drivers/usb/eth/asix88179.c | 14 ++ drivers/usb/gadget/composite.c| 8 +++ drivers/usb/gadget/f_dfu.c| 8 +++ drivers/usb/gadget/pxa25x_udc.c | 4 +- drivers/usb/host/ehci-hcd.c | 4 +- drivers/usb/musb-new/Makefile | 1 + drivers/usb/musb-new/musb_host.c | 12 +++-- drivers/usb/musb-new/musb_host.h | 1 + drivers/usb/musb-new/musb_regs.h | 92 ++ drivers/usb/musb-new/musb_uboot.c | 178 +++--- drivers/usb/musb-new/sunxi.c | 279 drivers/usb/musb-new/usb-compat.h | 1 + include/config_distro_bootcmd.h | 12 + include/usb.h | 14 -- 17 files changed, 602 insertions(+), 95 deletions(-) create mode 100644 drivers/usb/musb-new/sunxi.c ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] sunxi: display: Make lcd display clk phase configurable
On Tue, 13 Jan 2015 13:33:32 +0100 Hans de Goede wrote: > While running some tests with an Olinuxino-A13-Micro + a 7" Olimex LCD module > I noticed that the screen flickered. This is caused by the lcd display clk > phase reg value being set to 0, where it should be 1 in this setup. > > This commit adds a Kconfig option for the lcd display clk phase, so that we > can set it per board. This defaults to 1, because looking at all the fex > files in sunxi-boards, that is by far the most used value. What is the name of this option in fex files? > This commit updated the Ippo and MSI Primo73 tablet defconfigs to override the > default of 1 with 0, as that is the correct value for those tablets, this > keeps the register settings the same as before this commit. > > The Olinuxino-A13 defconfigs are not updated, changing the register setting > for these boards from 0 to 1, this is intentional. [...] -- Best regards, Siarhei Siamashka ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Unreadable UBIFS partition after power cuts
Hello Anton, Am 17.01.2015 17:06, schrieb Anton Habegger: Now I realized the "dangling branch" and "dangling match" messages on Linux is generated during the ubifs_replay_journal(). Under U-Boot this call is disabled: super.c mount_ubifs: #ifndef __UBOOT__ err = ubifs_replay_journal(c); if (err) goto out_journal; #endif I'm unfortunately not an expert in UBIFS, but I'm wondering how can U-Boot grantee to open a UBIFS volume after an power cut in a not corrupted state without replaying the journal? Thank you to give me one hint again. Could you try to enable it? The necessary functions should be also in the U-Boot code, so this should be not to difficult ... Thanks! bye, Heiko -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
