Re: [U-Boot] [PATCH V2 08/21] mx6: add plugin file for use with imximage.cfg
On 22/09/2012 04:39, Troy Kisky wrote: The plugin command of mkimage can take this file as an argument. Signed-off-by: Troy Kisky troy.ki...@boundarydevices.com --- Hi Troy, I agree with Vikram that a better explanation of what a plugin is can help to understand without reading deeply into the i.MX6 manual. So a plugin is a chunk of code that can be called directly by the BootROM of i.MX processors supporting V2 version of the i.MX header. In my understanding, this is supported by i.MX53, too. After the plugin run, the control is returned to the BootROM. Now that we have some basis, why do we need this mechanism to boot this board ? Is it not possible to make the same initialization directly in u-boot ? In principle, this adds stil some code that is not so easy to maintain. arch/arm/cpu/armv7/mx6/Makefile |5 +- arch/arm/cpu/armv7/mx6/plugin.S | 164 ++ arch/arm/include/asm/arch-mx6/imx-regs.h |1 + 3 files changed, 169 insertions(+), 1 deletion(-) create mode 100644 arch/arm/cpu/armv7/mx6/plugin.S diff --git a/arch/arm/cpu/armv7/mx6/Makefile b/arch/arm/cpu/armv7/mx6/Makefile index cbce411..b1fce4e 100644 --- a/arch/arm/cpu/armv7/mx6/Makefile +++ b/arch/arm/cpu/armv7/mx6/Makefile @@ -33,11 +33,14 @@ SOBJS = lowlevel_init.o SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c) OBJS := $(addprefix $(obj),$(SOBJS) $(COBJS)) -all: $(obj).depend $(LIB) +all: $(obj).depend $(LIB) plugin.bin $(LIB): $(OBJS) $(call cmd_link_o_target, $(OBJS)) +plugin.bin: plugin.o + $(OBJCOPY) -O binary --gap-fill 0xff $ $@ If we add a plugin mechanism, we can have several plugins (booting directly from Net, maybe ?). We should then have a general mechanism. A directory plugins here can contain the code, and it is compiled only if a CONFIG_ is set or better if required from imximage.cfg + # # defines $(obj).depend target diff --git a/arch/arm/cpu/armv7/mx6/plugin.S b/arch/arm/cpu/armv7/mx6/plugin.S new file mode 100644 index 000..99c6b20 --- /dev/null +++ b/arch/arm/cpu/armv7/mx6/plugin.S @@ -0,0 +1,164 @@ +/* + * Copyright (C) 2012 Boundary Devices Inc. + * + * Licensed under the GPL-2 or later. + */ +#include config.h +#include asm/arch/imx-regs.h + +#define HAB_RVT_ENTRY0x98 +#define HAB_RVT_FAIL_SAFE_VECT 0xbc +#define HAB_RVT_LOAD_DATA0xc8 + +#define HDR_SELF_PTR 0x14 +#define HDR_BOOT_DATA0x20 +#define HDR_IMAGE_LEN0x24 + +#define L2X0_CTRL0x100 +#define SCU_CONFIG 0x004 + +/* + * Disable L2 cache because ROM will turn it on when a plugin is used. + * There are cache coherence problems if cache is on when Linux kernel + * expects it to be off. + */ +.macro disable_l2_cache + ldr r1, =L2_BASE_ADDR + mov r0, #0x0 + str r0, [r1, #L2X0_CTRL] +.endm + + +/* + * plugin_start(void **start, size_t *bytes, UINT32 *ivt_offset) + */ +plugin_start: +/* Save the return address and the function arguments */ + push{r0-r8, lr} + +/* r0-r2 must be = 0x100 and must be 4 byte aligned */ + cmp r0, #0x100 + cmphs r1, #0x100 + cmphs r2, #0x100 + +/* rCPU: 22 - mx6q, 12 - mx6dl, 12|0x100 - solo, 2 - sololite */ +#define rCPU r2 +#define rIomux r3 +#define rVal0r4 /* mx6q value */ +#define rVal1r5 /* mx6dl value */ +#define rVal2r6 /* mx6solo value */ +#define rVal3r7 /* mx6sololite value */ +#define rFlaglr +#define rTable r8 + + orr rFlag, r0, r1 + orr rFlag, rFlag, r2 + orrlo rFlag, rFlag, #1 + + mov rCPU, #22 /* mx6q */ + mov r1, #SCU_BASE_ADDR + ldr r0, [r1, #SCU_CONFIG] + and r0, r0, #3 + cmp r0, #3 /* is mx6q? */ + movne rCPU, #12 /* mx6dl */ + cmpne r0, #1 /* is mx6dl? */ + movne rCPU, #2/* mx6 sololite */ + + ldrne r1, =ANATOP_BASE_ADDR + ldrne r0, [r1, #0x280] + movne r0, r0, LSR #16 + cmpne r0, #0x60 /* is mx6 Sololite? */ + movne rCPU, #12 | 0x100 /* Solo */ Ok - until here you have checked which processor is running. Now the more obscure code: + + mov rVal0, #0 + mov rVal1, #0 + mov rVal2, #0 + mov rVal3, #0 + ldr rIomux, =IOMUXC_BASE_ADDR + adr rTable, mx6_table + b 3f + +1: movsr0, r1, LSR #30 + beq 2f + mov r1, r1, LSL rCPU + movsr1, r1, LSR #32-10 + addne r1, rIomux, r1, LSL #2 + cmp r0, #3 + subne r0, r0, #1 + orr r1, r1, r0 + The reason is to write GPR12 ? But why do we need a plugin for that ? I do not understand why we cannot do it in the initialization
Re: [U-Boot] [PATCH V2 01/21] imximage: make header variable length
On 22/09/2012 04:38, Troy Kisky wrote: Hi Troy, Also, the header offset is no longer right before the code starts. Comment and subject of the patch do not match. Can you better explain it ? What have making header variable length, that is, a new feature, with the header offset is no longer rigth, that is, a bug ? Do we already have a variable header the we add a vrec_header function to image_type_params ? Series tested on an mx51 and mx6q --- tools/imximage.c | 142 +++--- tools/imximage.h | 10 ++-- 2 files changed, 87 insertions(+), 65 deletions(-) diff --git a/tools/imximage.c b/tools/imximage.c index 03a7716..25d3b74 100644 --- a/tools/imximage.c +++ b/tools/imximage.c @@ -65,12 +65,15 @@ static table_entry_t imximage_versions[] = { {-1,, (Invalid), }, }; -static struct imx_header imximage_header; static uint32_t imximage_version; static set_dcd_val_t set_dcd_val; static set_dcd_rst_t set_dcd_rst; static set_imx_hdr_t set_imx_hdr; +static set_imx_size_t set_imx_size; +static uint32_t g_flash_offset; + +static struct image_type_params imximage_params; static uint32_t get_cfg_value(char *token, char *name, int linenr) { @@ -207,85 +210,79 @@ static void set_dcd_rst_v2(struct imx_header *imxhdr, uint32_t dcd_len, dcd_v2-write_dcd_command.param = DCD_COMMAND_PARAM; } -static void set_imx_hdr_v1(struct imx_header *imxhdr, uint32_t dcd_len, - struct stat *sbuf, - struct mkimage_params *params) +static int set_imx_hdr_v1(struct imx_header *imxhdr, uint32_t dcd_len, + uint32_t entry_point, uint32_t flash_offset) { imx_header_v1_t *hdr_v1 = imxhdr-header.hdr_v1; flash_header_v1_t *fhdr_v1 = hdr_v1-fhdr; dcd_v1_t *dcd_v1 = hdr_v1-dcd_table; - uint32_t base_offset; - - /* Exit if there is no BOOT_FROM field specifying the flash_offset */ - if(imxhdr-flash_offset == FLASH_OFFSET_UNDEFINED) { - fprintf(stderr, Error: Header v1: No BOOT_FROM tag in %s\n, - params-imagename); - exit(EXIT_FAILURE); - } Do you drop BOOT_FROM ? Then this should be documented. Is this to allow that the same image can be loaded from different media, that share the same flash offset ? Then, instead of drop it, I suggest to add more entries in the imximage file, one for each media that is allow. Something like: BOOT_FROM sd, nand, spi and maybe a check in the code if all entries do not share the same start address. + uint32_t hdr_base; + uint32_t header_length = (((char *)dcd_v1-addr_data[dcd_len].addr) + - ((char *)imxhdr)); For V1, the header is preallocated with the maximum size, that is the maximum number of DCD entries the SOC in V1 can support. Why do we need a dynamic length for V1 processors ? As far as I know, the number of entries and fields for theses SOCs (i.MX25, i.MX35, i.MX51) is fixed. /* Set magic number */ fhdr_v1-app_code_barker = APP_CODE_BARKER; - fhdr_v1-app_dest_ptr = params-addr; - fhdr_v1-app_dest_ptr = params-ep - imxhdr-flash_offset - - sizeof(struct imx_header); - fhdr_v1-app_code_jump_vector = params-ep; + hdr_base = entry_point - header_length; + fhdr_v1-app_dest_ptr = hdr_base - flash_offset; + fhdr_v1-app_code_jump_vector = entry_point; - base_offset = fhdr_v1-app_dest_ptr + imxhdr-flash_offset ; - fhdr_v1-dcd_ptr_ptr = - (uint32_t) (offsetof(flash_header_v1_t, dcd_ptr) - - offsetof(flash_header_v1_t, app_code_jump_vector) + - base_offset); - - fhdr_v1-dcd_ptr = base_offset + - offsetof(imx_header_v1_t, dcd_table); - - /* The external flash header must be at the end of the DCD table */ - dcd_v1-addr_data[dcd_len].type = sbuf-st_size + - imxhdr-flash_offset + - sizeof(struct imx_header); + fhdr_v1-dcd_ptr_ptr = hdr_base + offsetof(flash_header_v1_t, dcd_ptr); + fhdr_v1-dcd_ptr = hdr_base + offsetof(imx_header_v1_t, dcd_table); /* Security feature are not supported */ fhdr_v1-app_code_csf = 0; fhdr_v1-super_root_key = 0; + return header_length; +} + Ok, I skip review of this part - it depends on your answer on the previous question. -static void set_imx_hdr_v2(struct imx_header *imxhdr, uint32_t dcd_len, - struct stat *sbuf, - struct mkimage_params *params) +static int set_imx_hdr_v2(struct imx_header *imxhdr, uint32_t dcd_len, + uint32_t entry_point, uint32_t flash_offset) { imx_header_v2_t *hdr_v2 = imxhdr-header.hdr_v2; flash_header_v2_t *fhdr_v2 = hdr_v2-fhdr; - -
Re: [U-Boot] [PATCH V2 02/21] imximage: check dcd_len as entries added
On 22/09/2012 04:38, Troy Kisky wrote: Before the len was checked after the entire file was processed, so it could have already overflowed. Hi Troy, Signed-off-by: Troy Kisky troy.ki...@boundarydevices.com --- tools/imximage.c | 26 +++--- 1 file changed, 11 insertions(+), 15 deletions(-) diff --git a/tools/imximage.c b/tools/imximage.c index 25d3b74..0bfbec3 100644 --- a/tools/imximage.c +++ b/tools/imximage.c @@ -71,6 +71,7 @@ static set_dcd_val_t set_dcd_val; static set_dcd_rst_t set_dcd_rst; static set_imx_hdr_t set_imx_hdr; static set_imx_size_t set_imx_size; +static uint32_t max_dcd_entries; static uint32_t g_flash_offset; static struct image_type_params imximage_params; @@ -173,13 +174,6 @@ static void set_dcd_rst_v1(struct imx_header *imxhdr, uint32_t dcd_len, { dcd_v1_t *dcd_v1 = imxhdr-header.hdr_v1.dcd_table; - if (dcd_len MAX_HW_CFG_SIZE_V1) { - fprintf(stderr, Error: %s[%d] - - DCD table exceeds maximum size(%d)\n, - name, lineno, MAX_HW_CFG_SIZE_V1); - exit(EXIT_FAILURE); - } - dcd_v1-preamble.barker = DCD_BARKER; dcd_v1-preamble.length = dcd_len * sizeof(dcd_type_addr_data_t); } @@ -193,13 +187,6 @@ static void set_dcd_rst_v2(struct imx_header *imxhdr, uint32_t dcd_len, { dcd_v2_t *dcd_v2 = imxhdr-header.hdr_v2.dcd_table; - if (dcd_len MAX_HW_CFG_SIZE_V2) { - fprintf(stderr, Error: %s[%d] - - DCD table exceeds maximum size(%d)\n, - name, lineno, MAX_HW_CFG_SIZE_V2); - exit(EXIT_FAILURE); - } - dcd_v2-header.tag = DCD_HEADER_TAG; dcd_v2-header.length = cpu_to_be16( dcd_len * sizeof(dcd_addr_data_t) + 8); @@ -293,12 +280,14 @@ static void set_hdr_func(struct imx_header *imxhdr) set_dcd_rst = set_dcd_rst_v1; set_imx_hdr = set_imx_hdr_v1; set_imx_size = set_imx_size_v1; + max_dcd_entries = MAX_HW_CFG_SIZE_V1; break; case IMXIMAGE_V2: set_dcd_val = set_dcd_val_v2; set_dcd_rst = set_dcd_rst_v2; set_imx_hdr = set_imx_hdr_v2; set_imx_size = set_imx_size_v2; + max_dcd_entries = MAX_HW_CFG_SIZE_V2; break; default: err_imximage_version(imximage_version); @@ -425,8 +414,15 @@ static void parse_cfg_fld(struct imx_header *imxhdr, int32_t *cmd, value = get_cfg_value(token, name, lineno); (*set_dcd_val)(imxhdr, name, lineno, fld, value, *dcd_len); - if (fld == CFG_REG_VALUE) + if (fld == CFG_REG_VALUE) { (*dcd_len)++; + if (*dcd_len max_dcd_entries) { + fprintf(stderr, Error: %s[%d] - + DCD table exceeds maximum size(%d)\n, + name, lineno, max_dcd_entries); + exit(EXIT_FAILURE); + } + } break; default: break; This patch seems to me unrelated to the rest, and fixes the case when too much DCD entries are put into the imximage.cfg file. What about to rebase it on the current code and post it as separate patch ? I think this can be merged directly, also in the current realease. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 04/21] imximage: cleanup parsing
On 22/09/2012 04:39, Troy Kisky wrote: Move to pulling tokens instead of pushing them. Remove need for switch statements to process commands. Add error messages such as command not finished, extra data at end of line, and invalid token Add ';' as command separator. Signed-off-by: Troy Kisky troy.ki...@boundarydevices.com --- Hi Troy, you add code in previous patch and you remove it in this one. This makes quite difficult to review them. Normally, we do do have this case, and code is not added and removed in the same patches series. Should you not squash patches together and / or rearrange them with different topic ? Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] mx25: add CPU revision 1.2
tested on a MCIMX257CJM4A which now reports : CPU: Freescale i.MX25 rev1.2 at 399 MHz Signed-off-by: Eric Bénard e...@eukrea.com Acked-by: Otavio Salvador ota...@ossystems.com.br --- v2 : rebased against 2012.10-rc1, added Otavio's ack arch/arm/cpu/arm926ejs/mx25/generic.c |3 +++ arch/arm/include/asm/arch-mx25/imx-regs.h |1 + 2 files changed, 4 insertions(+), 0 deletions(-) diff --git a/arch/arm/cpu/arm926ejs/mx25/generic.c b/arch/arm/cpu/arm926ejs/mx25/generic.c index a5c15ce..3b7f327 100644 --- a/arch/arm/cpu/arm926ejs/mx25/generic.c +++ b/arch/arm/cpu/arm926ejs/mx25/generic.c @@ -140,6 +140,9 @@ u32 get_cpu_rev(void) case 0x01: system_rev |= CHIP_REV_1_1; break; + case 0x02: + system_rev |= CHIP_REV_1_2; + break; default: system_rev |= 0x8000; break; diff --git a/arch/arm/include/asm/arch-mx25/imx-regs.h b/arch/arm/include/asm/arch-mx25/imx-regs.h index 672f9d7..e780296 100644 --- a/arch/arm/include/asm/arch-mx25/imx-regs.h +++ b/arch/arm/include/asm/arch-mx25/imx-regs.h @@ -357,5 +357,6 @@ struct aips_regs { #define CHIP_REV_1_0 0x10 #define CHIP_REV_1_1 0x11 +#define CHIP_REV_1_2 0x12 #endif /* _IMX_REGS_H */ -- 1.7.7.6 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/2] mx25: add CPU revision 1.2
tested on a MCIMX257CJM4A which now reports : CPU: Freescale i.MX25 rev1.2 at 399 MHz Signed-off-by: Eric Bénard e...@eukrea.com Acked-by: Otavio Salvador ota...@ossystems.com.br --- v2 : rebased against 2012.10-rc1, added Otavio's ack arch/arm/cpu/arm926ejs/mx25/generic.c |3 +++ arch/arm/include/asm/arch-mx25/imx-regs.h |1 + 2 files changed, 4 insertions(+), 0 deletions(-) diff --git a/arch/arm/cpu/arm926ejs/mx25/generic.c b/arch/arm/cpu/arm926ejs/mx25/generic.c index a5c15ce..3b7f327 100644 --- a/arch/arm/cpu/arm926ejs/mx25/generic.c +++ b/arch/arm/cpu/arm926ejs/mx25/generic.c @@ -140,6 +140,9 @@ u32 get_cpu_rev(void) case 0x01: system_rev |= CHIP_REV_1_1; break; + case 0x02: + system_rev |= CHIP_REV_1_2; + break; default: system_rev |= 0x8000; break; diff --git a/arch/arm/include/asm/arch-mx25/imx-regs.h b/arch/arm/include/asm/arch-mx25/imx-regs.h index 672f9d7..e780296 100644 --- a/arch/arm/include/asm/arch-mx25/imx-regs.h +++ b/arch/arm/include/asm/arch-mx25/imx-regs.h @@ -357,5 +357,6 @@ struct aips_regs { #define CHIP_REV_1_0 0x10 #define CHIP_REV_1_1 0x11 +#define CHIP_REV_1_2 0x12 #endif /* _IMX_REGS_H */ -- 1.7.7.6 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 2/2] add Eukrea's CPUIMX25
this board is based on an i.MX25 from Freescale. It consists of a SOM containing : - NAND flash (internal or external boot supported and tested) - mDDR (64MB tested) - ethernet PHY connected in RMII mode (tested) and a baseboard containing : - a serial transceiver on UART1 (tested) - a SDCard connector on eSDHC1 (tested but disabled until Benoît's fix gets applied) bootlog : U-Boot 2012.10-rc1-3-gdd12be5 (Sep 23 2012 - 13:53:21) CPU: Freescale i.MX25 rev1.2 at 399 MHz Reset cause: POR DRAM: 64 MiB NAND: 256 MiB MMC: In:serial Out: serial Err: serial Net: FEC Hit any key to stop autoboot: 0 Signed-off-by: Eric Bénard e...@eukrea.com --- v2: rebased against 2012.10-rc1, disabled eSDHC until proper fix from Benoît gets applied, updated bootlog. MAINTAINERS |2 + board/eukrea/cpuimx25/Makefile| 44 +++ board/eukrea/cpuimx25/config.mk |5 + board/eukrea/cpuimx25/cpuimx25.c | 123 ++ board/eukrea/cpuimx25/imximage.cfg| 55 board/eukrea/cpuimx25/lowlevel_init.S | 113 boards.cfg|2 + include/configs/cpuimx25.h| 198 + nand_spl/board/eukrea/cpuimx25/Makefile | 79 nand_spl/board/eukrea/cpuimx25/config.mk |1 + nand_spl/board/eukrea/cpuimx25/u-boot.lds | 83 11 files changed, 705 insertions(+), 0 deletions(-) create mode 100644 board/eukrea/cpuimx25/Makefile create mode 100644 board/eukrea/cpuimx25/config.mk create mode 100644 board/eukrea/cpuimx25/cpuimx25.c create mode 100644 board/eukrea/cpuimx25/imximage.cfg create mode 100644 board/eukrea/cpuimx25/lowlevel_init.S create mode 100644 include/configs/cpuimx25.h create mode 100644 nand_spl/board/eukrea/cpuimx25/Makefile create mode 100644 nand_spl/board/eukrea/cpuimx25/config.mk create mode 100644 nand_spl/board/eukrea/cpuimx25/u-boot.lds diff --git a/MAINTAINERS b/MAINTAINERS index aa54fe1..94e759f 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -606,6 +606,8 @@ Eric Benard e...@eukrea.com cpuat91 ARM920T cpu9260 ARM926EJS (AT91SAM9260 SoC) cpu9G20 ARM926EJS (AT91SAM9G20 SoC) + cpuimx25i.MX25 + cpuimx25nandi.MX25 Ajay Bhargav ajay.bhar...@einfochips.com diff --git a/board/eukrea/cpuimx25/Makefile b/board/eukrea/cpuimx25/Makefile new file mode 100644 index 000..46131fd --- /dev/null +++ b/board/eukrea/cpuimx25/Makefile @@ -0,0 +1,44 @@ +# +# (C) Copyright 2009 DENX Software Engineering +# Author: John Rigby jcri...@gmail.com +# +# See file CREDITS for list of people who contributed to this +# project. +# +# This program is free software; you can redistribute it and/or +# modify it under the terms of the GNU General Public License as +# published by the Free Software Foundation; either version 2 of +# the License, or (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 59 Temple Place, Suite 330, Boston, +# MA 02111-1307 USA +# + +include $(TOPDIR)/config.mk + +LIB= $(obj)lib$(BOARD).o + +COBJS := cpuimx25.o +SOBJS := lowlevel_init.o + +SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c) +OBJS := $(addprefix $(obj),$(COBJS)) +SOBJS := $(addprefix $(obj),$(SOBJS)) + +$(LIB):$(obj).depend $(OBJS) $(SOBJS) + $(call cmd_link_o_target, $(OBJS) $(SOBJS)) + +# + +include $(SRCTREE)/rules.mk + +sinclude $(obj).depend + +# diff --git a/board/eukrea/cpuimx25/config.mk b/board/eukrea/cpuimx25/config.mk new file mode 100644 index 000..18b2883 --- /dev/null +++ b/board/eukrea/cpuimx25/config.mk @@ -0,0 +1,5 @@ +ifdef CONFIG_NAND_SPL +CONFIG_SYS_TEXT_BASE = 0x810c +else +CONFIG_SYS_TEXT_BASE = 0x8120 +endif diff --git a/board/eukrea/cpuimx25/cpuimx25.c b/board/eukrea/cpuimx25/cpuimx25.c new file mode 100644 index 000..72fa8a5 --- /dev/null +++ b/board/eukrea/cpuimx25/cpuimx25.c @@ -0,0 +1,123 @@ +/* + * (C) Copyright 2009 DENX Software Engineering + * (C) Copyright 2012 Eukrea Electromatique www.eukrea.com + * Eric Benard e...@eukrea.com + * + * Based on tx25.c: + * Author: John Rigby jri...@gmail.com + * + * Based on imx27lite.c: + * Copyright (C) 2008,2009 Eric Jarrige jora...@users.sourceforge.net + * Copyright (C) 2009 Ilya Yanok ya...@emcraft.com + * And: + * RedBoot tx25_misc.c Copyright (C) 2009 Red Hat + * + * This program is free software; you can
Re: [U-Boot] [PATCH v6] [RFC] early_malloc for DM added.
On Sep 23, 2012 8:09 AM, Tomas Hlavacek tmshl...@gmail.com wrote: early_malloc for DM with support for more heaps and lightweight first heap in the same memory as an early stack. Adaptation layer for seamless calling of early_malloc or dlmalloc from DM based on init stage added (dmmalloc() and related functions). Signed-off-by: Tomas Hlavacek tmshl...@gmail.com --- [snip] +#ifdef CONFIG_SYS_EARLY_MALLOC +__weak struct early_heap_header *early_brk(size_t size) +{ + struct early_heap_header *h = + (struct early_heap_header *)CONFIG_SYS_EARLY_HEAP_ADDR; + struct early_heap_header *ehp = gd-early_heap_first; + + while (ehp != NULL) { + if (ehp == h) + return NULL; + + ehp = ehp-next_early_heap; + } if (g-early_heap_first == NULL) h = CONFIF_SYS_EARLY_HEAP_ADDR); else return NULL; + + h-free_space_pointer = (void *)(roundup( + (phys_addr_t)CONFIG_SYS_EARLY_HEAP_ADDR + + sizeof(struct early_heap_header), + sizeof(phys_addr_t))); + h-free_bytes = size - roundup(sizeof(struct early_heap_header), + sizeof(phys_addr_t)); + h-next_early_heap = NULL; + + return h; +} Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 0/6] Add h2200 support and pxa25x ethernet gadget
Patch 2/6 (usbethernet support) was revied. I've added only simple noisy defintion (at the end of patch). +#ifndef DEBUG +# define NOISY 0 +#endif Patch 3/6 was also revied. Lukasz Dalek (6): h2200: Add support for iPAQ h2200 palmtop pxa25x: Add support for USB ethernet gadget pxa: Add some stuff to examine cpu model and rev usbether: Fixed bug when using with PXA25X chips usbether: Define CONFIG_USB_ETH_{CDC,SUBSET} usbether: Removed DEV_CONFIG_{CDC,SUBSET} arch/arm/cpu/pxa/cpuinfo.c | 11 +- arch/arm/include/asm/arch-pxa/pxa.h | 13 + board/h2200/Makefile| 51 + board/h2200/h2200-header.S | 27 + board/h2200/h2200.c | 66 ++ board/h2200/h2200.h | 28 + boards.cfg |2 + drivers/usb/gadget/Makefile |1 + drivers/usb/gadget/ether.c | 69 +- drivers/usb/gadget/pxa25x_udc.c | 2059 +++ drivers/usb/gadget/pxa25x_udc.h | 162 +++ include/configs/h2200.h | 189 12 files changed, 2646 insertions(+), 32 deletions(-) create mode 100644 board/h2200/Makefile create mode 100644 board/h2200/h2200-header.S create mode 100644 board/h2200/h2200.c create mode 100644 board/h2200/h2200.h create mode 100644 drivers/usb/gadget/pxa25x_udc.c create mode 100644 drivers/usb/gadget/pxa25x_udc.h create mode 100644 include/configs/h2200.h -- 1.7.8.6 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/6] h2200: Add support for iPAQ h2200 palmtop
Basic support of HP iPAQ h2200 palmtop. Support includes also USB ethernet gadget. Signed-off-by: Lukasz Dalek luk0...@gmail.com --- board/h2200/Makefile | 51 board/h2200/h2200-header.S | 27 ++ board/h2200/h2200.c| 66 +++ board/h2200/h2200.h| 28 +++ boards.cfg |2 + include/configs/h2200.h| 189 6 files changed, 363 insertions(+), 0 deletions(-) create mode 100644 board/h2200/Makefile create mode 100644 board/h2200/h2200-header.S create mode 100644 board/h2200/h2200.c create mode 100644 board/h2200/h2200.h create mode 100644 include/configs/h2200.h diff --git a/board/h2200/Makefile b/board/h2200/Makefile new file mode 100644 index 000..2265aa9 --- /dev/null +++ b/board/h2200/Makefile @@ -0,0 +1,51 @@ +# +# h2200 Support +# +# Copyright (C) 2012 Lukasz Dalek luk0...@gmail.com +# +# This program is free software; you can redistribute it and/or +# modify it under the terms of the GNU General Public License as +# published by the Free Software Foundation; either version 2 of +# the License, or (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 59 Temple Place, Suite 330, Boston, +# MA 02111-1307 USA +# + +include $(TOPDIR)/config.mk + +LIB= $(obj)lib$(BOARD).o + +COBJS := h2200.o + +SRCS := $(COBJS:.o=.c) h2200-header.S +OBJS := $(addprefix $(obj),$(COBJS)) + +ALL: $(LIB) h2200-header.bin + +h2200-header.o: h2200-header.S + $(CC) $(CFLAGS) -c -o $@ $ + +h2200-header.bin: h2200-header.o + $(OBJCOPY) -O binary $ $@ + +all: $(LIB) h2200-header.bin + +$(LIB):$(obj).depend $(OBJS) + $(call cmd_link_o_target, $(OBJS)) + +# + +# defines $(obj).depend target +include $(SRCTREE)/rules.mk + +sinclude $(obj).depend + +# diff --git a/board/h2200/h2200-header.S b/board/h2200/h2200-header.S new file mode 100644 index 000..c335bfe --- /dev/null +++ b/board/h2200/h2200-header.S @@ -0,0 +1,27 @@ +/* + * iPAQ h2200 header + * + * Copyright (C) 2012 Lukasz Dalek luk0...@gmail.com + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + */ + + .word 0xea0003fe /* b 0x1000 */ + + .org 0x40 + .ascii ECEC + + .org 0x1000 - 1 + .byte 0x0 diff --git a/board/h2200/h2200.c b/board/h2200/h2200.c new file mode 100644 index 000..a6b1c48 --- /dev/null +++ b/board/h2200/h2200.c @@ -0,0 +1,66 @@ +/* + * iPAQ h2200 board configuration + * + * Copyright (C) 2012 Lukasz Dalek luk0...@gmail.com + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + */ + +#include common.h +#include asm/arch/pxa.h +#include asm/arch/pxa-regs.h +#include asm/io.h +#include h2200.h + +DECLARE_GLOBAL_DATA_PTR; + +#ifdef CONFIG_H2200_USBETH +int board_eth_init(bd_t *bis) +{ + usb_eth_initialize(bis); + return 0; +} +#endif + +int board_init(void) +{ + /* We have RAM, disable cache */ + dcache_disable(); + icache_disable(); + + gd-bd-bi_arch_number = MACH_TYPE_H2200; + + /* adress of boot parameters */ + gd-bd-bi_boot_params = 0xa100; + + /*
[U-Boot] [PATCH v2 3/6] pxa: Add some stuff to examine cpu model and rev
Add function which return CPU model and revision which can be used for cpu detection. Signed-off-by: Lukasz Dalek luk0...@gmail.com --- arch/arm/cpu/pxa/cpuinfo.c | 11 +-- arch/arm/include/asm/arch-pxa/pxa.h | 13 + 2 files changed, 22 insertions(+), 2 deletions(-) diff --git a/arch/arm/cpu/pxa/cpuinfo.c b/arch/arm/cpu/pxa/cpuinfo.c index f1cdd40..bab6340 100644 --- a/arch/arm/cpu/pxa/cpuinfo.c +++ b/arch/arm/cpu/pxa/cpuinfo.c @@ -24,9 +24,11 @@ #include errno.h #include linux/compiler.h -#defineCPU_MASK_PXA_REVID 0x00f +#defineCPU_MASK_PXA_PRODID 0x03f0 +#defineCPU_MASK_PXA_REVID 0x000f + +#defineCPU_MASK_PRODREV(CPU_MASK_PXA_PRODID | CPU_MASK_PXA_REVID) -#defineCPU_MASK_PXA_PRODID 0x3f0 #defineCPU_VALUE_PXA25X0x100 #defineCPU_VALUE_PXA27X0x110 @@ -51,6 +53,11 @@ int cpu_is_pxa27x(void) return id == CPU_VALUE_PXA27X; } +uint32_t pxa_get_cpu_revision(void) +{ + return pxa_get_cpuid() CPU_MASK_PRODREV; +} + #ifdef CONFIG_DISPLAY_CPUINFO static const char *pxa25x_get_revision(void) { diff --git a/arch/arm/include/asm/arch-pxa/pxa.h b/arch/arm/include/asm/arch-pxa/pxa.h index 49c6552..b67d8f2 100644 --- a/arch/arm/include/asm/arch-pxa/pxa.h +++ b/arch/arm/include/asm/arch-pxa/pxa.h @@ -22,8 +22,21 @@ #ifndef__PXA_H__ #define__PXA_H__ +#define PXA255_A0 0x0106 +#define PXA250_C0 0x0105 +#define PXA250_B2 0x0104 +#define PXA250_B1 0x0103 +#define PXA250_B0 0x0102 +#define PXA250_A1 0x0101 +#define PXA250_A0 0x0100 +#define PXA210_C0 0x0125 +#define PXA210_B2 0x0124 +#define PXA210_B1 0x0123 +#define PXA210_B0 0x0122 + int cpu_is_pxa25x(void); int cpu_is_pxa27x(void); +uint32_t pxa_get_cpu_revision(void); void pxa2xx_dram_init(void); #endif /* __PXA_H__ */ -- 1.7.8.6 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 4/6] usbether: Fixed bug when using with PXA25X chips
PXA25X chips don't support alternate settings so driver uses non-CDC driver. But only code defined between DEV_CONFIG_CDC signals that network is up. This patch is fixing this bug by signaling that network is up after USB SET_INTERFACE request. Signed-off-by: Lukasz Dalek luk0...@gmail.com --- drivers/usb/gadget/ether.c | 17 - 1 files changed, 16 insertions(+), 1 deletions(-) diff --git a/drivers/usb/gadget/ether.c b/drivers/usb/gadget/ether.c index d975fb6..9ce2c17 100644 --- a/drivers/usb/gadget/ether.c +++ b/drivers/usb/gadget/ether.c @@ -44,7 +44,12 @@ extern struct platform_data brd; unsigned packet_received, packet_sent; -#define DEV_CONFIG_CDC 1 +#ifdef CONFIG_USB_GADGET_PXA2XX +# undef DEV_CONFIG_CDC +# define DEV_CONFIG_SUBSET 1 +#else +# define DEV_CONFIG_CDC1 +#endif #define GFP_ATOMIC ((gfp_t) 0) #define GFP_KERNEL ((gfp_t) 0) @@ -864,7 +869,9 @@ static struct usb_gadget_stringsstringtab = { /**/ static u8 control_req[USB_BUFSIZ]; +#if defined(DEV_CONFIG_CDC) || defined(CONFIG_USB_ETH_RNDIS) static u8 status_req[STATUS_BYTECOUNT] __attribute__ ((aligned(4))); +#endif /** @@ -1352,6 +1359,14 @@ eth_setup(struct usb_gadget *gadget, const struct usb_ctrlrequest *ctrl) if (gadget_is_pxa(gadget)) { value = eth_set_config(dev, DEV_CONFIG_VALUE, GFP_ATOMIC); + /* +* PXA25x driver use non-CDC ethernet gadget. +* But only _CDC and _RNDIS code can signalize +* that network is working. So we signalize it +* here. +*/ + l_ethdev.network_started = 1; + debug(USB network up!\n); goto done_set_intf; } -- 1.7.8.6 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 5/6] usbether: Define CONFIG_USB_ETH_{CDC, SUBSET}
Introduced CONFIG_USB_ETH_CDC and CONFIG_USB_ETH_SUBSET as preparation for removal DEV_CONFIG_CDC and DEV_CONFIG_SUBSET Signed-off-by: Lukasz Dalek luk0...@gmail.com --- drivers/usb/gadget/ether.c | 19 ++- 1 files changed, 14 insertions(+), 5 deletions(-) diff --git a/drivers/usb/gadget/ether.c b/drivers/usb/gadget/ether.c index 9ce2c17..7e6491d 100644 --- a/drivers/usb/gadget/ether.c +++ b/drivers/usb/gadget/ether.c @@ -44,12 +44,21 @@ extern struct platform_data brd; unsigned packet_received, packet_sent; -#ifdef CONFIG_USB_GADGET_PXA2XX -# undef DEV_CONFIG_CDC -# define DEV_CONFIG_SUBSET 1 -#else -# define DEV_CONFIG_CDC1 +#undef DEV_CONFIG_CDC +#undef DEV_CONFIG_SUBSET + +#if !defined(CONFIG_USB_ETH_CDC) !defined(CONFIG_USB_ETH_SUBSET) +# define DEV_CONFIG_CDC1 /* preserve default behavior */ +#endif + +#if defined(CONFIG_USB_ETH_CDC) +# define DEV_CONFIG_CDC1 #endif + +#if defined(CONFIG_USB_ETH_SUBSET) +# define DEV_CONFIG_SUBSET 1 +#endif + #define GFP_ATOMIC ((gfp_t) 0) #define GFP_KERNEL ((gfp_t) 0) -- 1.7.8.6 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 6/6] usbether: Removed DEV_CONFIG_{CDC,SUBSET}
Removed DEV_CONFIG_CDC and DEV_CONFIG_SUBSET and replaced it with CONFIG_USB_ETH_CDC and CONFIG_USB_ETH_SUBSET. Signed-off-by: Lukasz Dalek luk0...@gmail.com --- drivers/usb/gadget/ether.c | 75 +-- 1 files changed, 30 insertions(+), 45 deletions(-) diff --git a/drivers/usb/gadget/ether.c b/drivers/usb/gadget/ether.c index 7e6491d..1e187e5 100644 --- a/drivers/usb/gadget/ether.c +++ b/drivers/usb/gadget/ether.c @@ -44,21 +44,6 @@ extern struct platform_data brd; unsigned packet_received, packet_sent; -#undef DEV_CONFIG_CDC -#undef DEV_CONFIG_SUBSET - -#if !defined(CONFIG_USB_ETH_CDC) !defined(CONFIG_USB_ETH_SUBSET) -# define DEV_CONFIG_CDC1 /* preserve default behavior */ -#endif - -#if defined(CONFIG_USB_ETH_CDC) -# define DEV_CONFIG_CDC1 -#endif - -#if defined(CONFIG_USB_ETH_SUBSET) -# define DEV_CONFIG_SUBSET 1 -#endif - #define GFP_ATOMIC ((gfp_t) 0) #define GFP_KERNEL ((gfp_t) 0) @@ -174,9 +159,9 @@ static struct usb_gadget_driver eth_driver; /* main config is either CDC, or its simple subset */ static inline int is_cdc(struct eth_dev *dev) { -#if!defined(DEV_CONFIG_SUBSET) +#if!defined(CONFIG_USB_ETH_SUBSET) return 1; /* only cdc possible */ -#elif !defined(DEV_CONFIG_CDC) +#elif !defined(CONFIG_USB_ETH_CDC) return 0; /* only subset possible */ #else return dev-cdc;/* depends on what hardware we found */ @@ -420,7 +405,7 @@ rndis_config = { * get those drivers from MCCI, or bundled with various products. */ -#ifdef DEV_CONFIG_CDC +#ifdef CONFIG_USB_ETH_CDC static struct usb_interface_descriptor control_intf = { .bLength = sizeof control_intf, @@ -459,7 +444,7 @@ static const struct usb_cdc_header_desc header_desc = { .bcdCDC = __constant_cpu_to_le16(0x0110), }; -#if defined(DEV_CONFIG_CDC) || defined(CONFIG_USB_ETH_RNDIS) +#if defined(CONFIG_USB_ETH_CDC) || defined(CONFIG_USB_ETH_RNDIS) static const struct usb_cdc_union_desc union_desc = { .bLength = sizeof union_desc, @@ -493,7 +478,7 @@ static const struct usb_cdc_acm_descriptor acm_descriptor = { #endif -#ifndef DEV_CONFIG_CDC +#ifndef CONFIG_USB_ETH_CDC /* * SAFE loosely follows CDC WMC MDLM, violating the spec in various @@ -543,7 +528,7 @@ static const struct usb_cdc_ether_desc ether_desc = { .bNumberPowerFilters = 0, }; -#if defined(DEV_CONFIG_CDC) || defined(CONFIG_USB_ETH_RNDIS) +#if defined(CONFIG_USB_ETH_CDC) || defined(CONFIG_USB_ETH_RNDIS) /* * include the status endpoint if we can, even where it's optional. @@ -575,7 +560,7 @@ fs_status_desc = { }; #endif -#ifdef DEV_CONFIG_CDC +#ifdef CONFIG_USB_ETH_CDC /* the default data interface has no endpoints ... */ @@ -630,7 +615,7 @@ rndis_data_intf = { #endif -#ifdef DEV_CONFIG_SUBSET +#ifdef CONFIG_USB_ETH_SUBSET /* * Simple CDC-subset option is a simple vendor-neutral model that most @@ -676,7 +661,7 @@ fs_sink_desc = { static const struct usb_descriptor_header *fs_eth_function[11] = { (struct usb_descriptor_header *) otg_descriptor, -#ifdef DEV_CONFIG_CDC +#ifdef CONFIG_USB_ETH_CDC /* cdc mode descriptors */ (struct usb_descriptor_header *) control_intf, (struct usb_descriptor_header *) header_desc, @@ -690,12 +675,12 @@ static const struct usb_descriptor_header *fs_eth_function[11] = { (struct usb_descriptor_header *) fs_source_desc, (struct usb_descriptor_header *) fs_sink_desc, NULL, -#endif /* DEV_CONFIG_CDC */ +#endif /* CONFIG_USB_ETH_CDC */ }; static inline void fs_subset_descriptors(void) { -#ifdef DEV_CONFIG_SUBSET +#ifdef CONFIG_USB_ETH_SUBSET /* behavior is CDC Subset; extra descriptors say SAFE */ fs_eth_function[1] = (struct usb_descriptor_header *) subset_data_intf; fs_eth_function[2] = (struct usb_descriptor_header *) header_desc; @@ -733,7 +718,7 @@ static const struct usb_descriptor_header *fs_rndis_function[] = { * descriptors, unless they only run at full speed. */ -#if defined(DEV_CONFIG_CDC) || defined(CONFIG_USB_ETH_RNDIS) +#if defined(CONFIG_USB_ETH_CDC) || defined(CONFIG_USB_ETH_RNDIS) static struct usb_endpoint_descriptor hs_status_desc = { .bLength = USB_DT_ENDPOINT_SIZE, @@ -743,7 +728,7 @@ hs_status_desc = { .wMaxPacketSize = __constant_cpu_to_le16(STATUS_BYTECOUNT), .bInterval =LOG2_STATUS_INTERVAL_MSEC + 4, }; -#endif /* DEV_CONFIG_CDC */ +#endif /* CONFIG_USB_ETH_CDC */ static struct usb_endpoint_descriptor hs_source_desc = { @@ -776,7 +761,7 @@ dev_qualifier = { static const struct usb_descriptor_header *hs_eth_function[11] = { (struct usb_descriptor_header *) otg_descriptor, -#ifdef DEV_CONFIG_CDC +#ifdef CONFIG_USB_ETH_CDC /* cdc mode descriptors */ (struct usb_descriptor_header *)
[U-Boot] [PATCH] env: remove duplicated env_get_char_spec()
env_fat and env_remote have an implementation of env_get_char_spec() function that is not different than the default. Remove the duplicated code. Signed-off-by: Igor Grinberg grinb...@compulab.co.il --- common/env_fat.c|5 - common/env_remote.c |5 - 2 files changed, 0 insertions(+), 10 deletions(-) diff --git a/common/env_fat.c b/common/env_fat.c index bad92aa..ca76967 100644 --- a/common/env_fat.c +++ b/common/env_fat.c @@ -40,11 +40,6 @@ env_t *env_ptr; DECLARE_GLOBAL_DATA_PTR; -uchar env_get_char_spec(int index) -{ - return *((uchar *)(gd-env_addr + index)); -} - int env_init(void) { /* use default */ diff --git a/common/env_remote.c b/common/env_remote.c index 3bf0f95..87af1936 100644 --- a/common/env_remote.c +++ b/common/env_remote.c @@ -41,11 +41,6 @@ DECLARE_GLOBAL_DATA_PTR; #define CONFIG_ENV_OFFSET 0 #endif -uchar env_get_char_spec(int index) -{ - return *((uchar *)(gd-env_addr + index)); -} - int env_init(void) { if (crc32(0, env_ptr-data, ENV_SIZE) == env_ptr-crc) { -- 1.7.3.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 05/21] imximage: add expression evaluation
On 22/09/2012 04:39, Troy Kisky wrote: Basic expressions with order precedence is now supported. ie. (3 + ((1+2*3)/--2 + --5 *(8/4))) is 16. Signed-off-by: Troy Kisky troy.ki...@boundarydevices.com --- Hi Troy, tools/imximage.c | 172 ++ 1 file changed, 162 insertions(+), 10 deletions(-) diff --git a/tools/imximage.c b/tools/imximage.c index 1e120354..2c5a622 100644 I have some general considerations. First, if you plan to add support for expression evaluation, this feature should be available generally for mkimage, that means also other processors / architecture can profit of it. It should be moved away from imximage.c code. Then, you want also let that the preprocesso can parse the imximage code. I can imagine that in such terms it could be then possible to define in imximage.cfg something like: #define DDR_VAL (1 17 | 3 7) #define ADDRESS 0x0x53something DATA 4 ADDRESS DDR_VAL Else, why do we need the power of C preprocessor ? If this is true, can you explain us which is the use case using the C preprocessor and which is the one for the expression evaluator ? And why do we need both ? --- a/tools/imximage.c +++ b/tools/imximage.c @@ -380,20 +380,172 @@ char *grab_token(char *dest, int size, char *src) return src; } +char precedence[] = { + /* ( + - * /^ | ) */ +0, 2, 2, 1, 1, 3, 4, 5, 6 +}; +char unary_operations[] = (+-; +char binary_operations[] = +-*/^|); + +uint32_t do_func(uint32_t val1, uint32_t val2, int op) +{ + switch (op) { + case 1: + return val1 + val2; + case 2: + return val1 - val2; + case 3: + return val1 * val2; + case 4: + return val1 / val2; + case 5: + return val1 val2; + case 6: + return val1 ^ val2; + case 7: + return val1 | val2; + } + fprintf(stderr, Error: in func %s: val1=%d val2=%d op = %d\n, + __func__, val1, val2, op); + exit(EXIT_FAILURE); +} + +int find_op(char c, char *p) +{ + int i; + for (i = 0; ; i++) { + if (c == p[i]) + return i; + if (!p[i]) + break; + } + return -1; +} + +#define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0])) + static uint32_t get_cfg_value(struct data_src *ds, uint32_t *pval) { char *endptr; - uint32_t value; + int op_i = 0; + int val_i = 0; + unsigned char op[16]; + uint32_t val[16]; + int unary = 1; + char *p; - if (skip_separators(ds)) - return -1; - errno = 0; - value = strtoul(ds-p, endptr, 16); - if (errno || (ds-p == endptr)) - return -1; - *pval = value; - ds-p = endptr; - return 0; + p = ds-p; + for (;;) { + char c; + int i, j; + char *ops = unary ? unary_operations : binary_operations; + + if (unary) { + ds-p = p; + if (skip_separators(ds)) + return -1; + p = ds-p; + c = *p; + } else { + for (;;) { + c = *p; + if ((c != ' ') (c != '\t')) + break; + p++; + } + } + i = find_op(c, ops); + debug(%d,%c,%d:%s\n, i, c, unary, p); + if ((i 0) unary) { + if (val_i = ARRAY_SIZE(val)) + return -1; + errno = 0; + val[val_i++] = strtoul(p, endptr, 16); + if (errno || (p == endptr)) { + ds-p = p; + return -1; + } + p = endptr; + unary = 0; + debug(val[%d]=%x,%d,%d\n, val_i - 1, val[val_i - 1], + op_i, val_i); +do_unary: + while (op_i) { + j = op[op_i - 1]; + if (!(j 0x80)) + break; + op_i--; + val[val_i - 1] = do_func(0, + val[val_i - 1], j 0x7f); + debug(un:%d,%x,%d,%d\n, val[val_i - 1], j, + op_i, val_i); + } + continue; + } + if (i 0) { + c = 0; + i = 8; + } else { + p++; + } + if (c == '(') { +
Re: [U-Boot] [PATCH V2 17/21] mx6: soc: add get_cpu_type
On 22/09/2012 19:07, Troy Kisky wrote: On 9/21/2012 7:50 PM, Fabio Estevam wrote: Hi Troy, On Fri, Sep 21, 2012 at 11:39 PM, Troy Kisky troy.ki...@boundarydevices.com wrote: Add function to return the processor type. i.e. MX6Q, MX6DL, MX6SOLO, MX6SOLOLITE On arch/arm/imx-common/cpu.c we have: static const char *get_imx_type(u32 imxtype) { switch (imxtype) { case 0x63: return 6Q;/* Quad-core version of the mx6 */ case 0x61: return 6DS;/* Dual/Solo version of the mx6 */ case 0x60: return 6SL;/* Solo-Lite version of the mx6 */ case 0x51: return 51; case 0x53: return 53; default: return ??; } } ,which seems to serve the same purpose. Regards, Fabio Estevam No, not similar to get_imx_type, but it is similar to get_cpu_rev. I guess I should fix get_imx_type, and get_cpu_rev, instead of adding a new one. Indeed. Try to use as much as possible code in imx-common, avoiding to duplicate code. Best regards, Stefano -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-mpc85xx (for v2012.10)
Argh, actually I think I sent the pull request, but it got stuck in our mail system, and I didn't notice. Thanks for sending this out, Kumar. On Sep 22, 2012, at 9:09, Kumar Gala ga...@kernel.crashing.org wrote: Tom, Sorry for both sending this and the late request. I think Andy's been swamped with some chip bringup and lost notice of window (thus my sending this request). Would be good to get this stuff (and some fixes, etc) into v2012.10. Thanks - k The following changes since commit ee1f4caaa2a3f79d692155eec8a4c7289d60e106: Tom Rini (1): Prepare v2012.10-rc1 are available in the git repository at: git://git.denx.de/u-boot-mpc85xx.git master Andy Fleming (1): Revert powerpc: Fix declaration type for I/O functions Joakim Tjernlund (2): mpc85xx: Initial SP alignment is wrong. powerpc: Stack Pointer not properly aligned Kumar Gala (3): Add e6500 processor detection Add IFC offset for DPAA/Corenet platforms Added new ext fields to IFC Liu Gang (6): powerpc/corenet_ds: Update README.srio-boot-corenet powerpc/corenet_ds: Get rid of the SRIOBOOT_MASTER build target powerpc/corenet_ds: Get rid of the CONFIG_SRIOBOOT_SLAVE_PORTx macro powerpc/corenet_ds: Update README and README.srio-pcie-boot-corenet powerpc/corenet_ds: Master module for boot from PCIE powerpc/corenet_ds: Slave module for boot from PCIE Matthew McClintock (6): p1014rdb: set ddr bus width properly depending on SVR p1010rdb: fix ddr values for p1014rdb (setting bus width to 16bit) powerpc/p1010rdb: nandboot: compare SVR properly nand_spl: update udelay for Freescale boards nand_spl: p1023rds: wait before enabling DDR controller nand_spl: change out_be32 to raw_writel and depend on subsequent sync Paul Gortmaker (1): mpc85xx: use LCRR_DBYP define instead of raw constant Prabhakar Kushwaha (2): powerpc/mpc85xx:Enable debugger support to missed e500v2 SoC powerpc/mpc85xx: Add IFC LAW target ID for FSL High-End SoC Scott Wood (6): nand/fsl_elbc: shrink SPL a bit by converting out_be32() to __raw_writel() powerpc/fsl-corenet: remove dead variant symbols powerpc/fsl-corenet: work around erratum A004510 powerpc/85xx: clear out TLB on boot powerpc/p1_p2_rdb_pc: print -PC suffix in board name powerpc/mpc85xx/p1_p2_rdb: add all LAWs during SPL Shaohui Xie (1): powerpc/CoreNet: add tool to support pbl image build. Timur Tabi (6): powerpc/85xx: add support for FM2 DTSEC5 fm-eth: add function fm_info_get_phy_address() powerpc/85xx: introduce function serdes_device_from_fm_port() fm-eth: use fdt_status_disabled() function in ft_fixup_port() powerpc/85xx: get rid of enum board_slots in P4080 MDIO driver powerpc/85xx: remove support for the Freescale P3060 York Sun (14): powerpc/mpc85xx: Make NMG_CPU_A011 workaround conditional powerpc/mpc8xxx: Remove P1015 and P1016 from CPU list powerpc/mpc8xxx: Add immap for topology and rcpm registers powerpc/mpc8xxx: use topology registers to calculate number of cores powerpc/mpc8xxx: fix core id for multicore booting powerpc/mpc85xx: Skip zero values for DDR debug registers powerpc/mpc8xxx: Add fine timing support for DDR3 powerpc/mpc8xxx: Add support for cas latency 12 and above powerpc/mpc8xxx: Enable 3-way and 4-way DDR interleaving powerpc/mpc8xxx: Fix bug for extended DDR timing powerpc/mpc8xxx DDR: Fix CAS latency calculation powerpc/mpc8xxx DDR: Fall back to raw timing for first controller only powerpc/mpc8xxx DDR: Fix interactive DDR debugging powerpc/mpc8xxx: Move HWCONFIG_BUFFER_SIZE into config.h Makefile |6 + README | 37 +- arch/powerpc/cpu/mpc85xx/Makefile | 10 - arch/powerpc/cpu/mpc85xx/cmd_errata.c |9 +- arch/powerpc/cpu/mpc85xx/cpu.c | 15 +- arch/powerpc/cpu/mpc85xx/cpu_init.c| 52 ++- arch/powerpc/cpu/mpc85xx/ddr-gen3.c| 26 +- arch/powerpc/cpu/mpc85xx/fdt.c |7 +- arch/powerpc/cpu/mpc85xx/fsl_corenet_serdes.c |8 +- arch/powerpc/cpu/mpc85xx/p3060_ids.c | 117 - arch/powerpc/cpu/mpc85xx/p3060_serdes.c| 118 - arch/powerpc/cpu/mpc85xx/release.S | 87 +++- arch/powerpc/cpu/mpc85xx/speed.c |3 +- arch/powerpc/cpu/mpc85xx/start.S | 376 +-- arch/powerpc/cpu/mpc8xxx/cpu.c | 68 ++- arch/powerpc/cpu/mpc8xxx/ddr/ctrl_regs.c | 223 - arch/powerpc/cpu/mpc8xxx/ddr/ddr3_dimm_params.c| 25 +- arch/powerpc/cpu/mpc8xxx/ddr/interactive.c | 26 +-
[U-Boot] [PATCH] env: checkpatch clean env_fat
env_fat has several checkpatch warnings - clean those up. Signed-off-by: Igor Grinberg grinb...@compulab.co.il --- common/env_fat.c | 20 ++-- 1 files changed, 14 insertions(+), 6 deletions(-) diff --git a/common/env_fat.c b/common/env_fat.c index ca76967..6ef5318 100644 --- a/common/env_fat.c +++ b/common/env_fat.c @@ -58,6 +58,7 @@ int saveenv(void) block_dev_desc_t *dev_desc = NULL; int dev = FAT_ENV_DEVICE; int part = FAT_ENV_PART; + int err; res = (char *)env_new.data; len = hexport_r(env_htab, '\0', res, ENV_SIZE, 0, NULL); @@ -67,7 +68,7 @@ int saveenv(void) } #ifdef CONFIG_MMC - if (strcmp (FAT_ENV_INTERFACE, mmc) == 0) { + if (strcmp(FAT_ENV_INTERFACE, mmc) == 0) { struct mmc *mmc = find_mmc_device(dev); if (!mmc) { @@ -86,14 +87,17 @@ int saveenv(void) FAT_ENV_INTERFACE, dev); return 1; } - if (fat_register_device(dev_desc, part) != 0) { + + err = fat_register_device(dev_desc, part); + if (err) { printf(Failed to register %s%d:%d\n, FAT_ENV_INTERFACE, dev, part); return 1; } env_new.crc = crc32(0, env_new.data, ENV_SIZE); - if (file_fat_write(FAT_ENV_FILE, (void *)env_new, sizeof(env_t)) == -1) { + err = file_fat_write(FAT_ENV_FILE, (void *)env_new, sizeof(env_t)); + if (err == -1) { printf(\n** Unable to write \%s\ from %s%d:%d **\n, FAT_ENV_FILE, FAT_ENV_INTERFACE, dev, part); return 1; @@ -110,9 +114,10 @@ void env_relocate_spec(void) block_dev_desc_t *dev_desc = NULL; int dev = FAT_ENV_DEVICE; int part = FAT_ENV_PART; + int err; #ifdef CONFIG_MMC - if (strcmp (FAT_ENV_INTERFACE, mmc) == 0) { + if (strcmp(FAT_ENV_INTERFACE, mmc) == 0) { struct mmc *mmc = find_mmc_device(dev); if (!mmc) { @@ -133,14 +138,17 @@ void env_relocate_spec(void) set_default_env(NULL); return; } - if (fat_register_device(dev_desc, part) != 0) { + + err = fat_register_device(dev_desc, part); + if (err) { printf(Failed to register %s%d:%d\n, FAT_ENV_INTERFACE, dev, part); set_default_env(NULL); return; } - if (file_fat_read(FAT_ENV_FILE, (unsigned char *)buf, CONFIG_ENV_SIZE) == -1) { + err = file_fat_read(FAT_ENV_FILE, (uchar *)buf, CONFIG_ENV_SIZE); + if (err == -1) { printf(\n** Unable to read \%s\ from %s%d:%d **\n, FAT_ENV_FILE, FAT_ENV_INTERFACE, dev, part); set_default_env(NULL); -- 1.7.3.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v6] [RFC] early_malloc for DM added.
Hello! On Sun, Sep 23, 2012 at 3:06 PM, Graeme Russ graeme.r...@gmail.com wrote: On Sep 23, 2012 8:09 AM, Tomas Hlavacek tmshl...@gmail.com wrote: early_malloc for DM with support for more heaps and lightweight first heap in the same memory as an early stack. Adaptation layer for seamless calling of early_malloc or dlmalloc from DM based on init stage added (dmmalloc() and related functions). Signed-off-by: Tomas Hlavacek tmshl...@gmail.com --- [snip] +#ifdef CONFIG_SYS_EARLY_MALLOC +__weak struct early_heap_header *early_brk(size_t size) +{ + struct early_heap_header *h = + (struct early_heap_header *)CONFIG_SYS_EARLY_HEAP_ADDR; + struct early_heap_header *ehp = gd-early_heap_first; + + while (ehp != NULL) { + if (ehp == h) + return NULL; + + ehp = ehp-next_early_heap; + } if (g-early_heap_first == NULL) h = CONFIF_SYS_EARLY_HEAP_ADDR); else return NULL; Yes, I was too paranoid. What about: if (g-early_heap_first != NULL) return NULL; + + h-free_space_pointer = (void *)(roundup( + (phys_addr_t)CONFIG_SYS_EARLY_HEAP_ADDR + + sizeof(struct early_heap_header), + sizeof(phys_addr_t))); + h-free_bytes = size - roundup(sizeof(struct early_heap_header), + sizeof(phys_addr_t)); + h-next_early_heap = NULL; + + return h; +} Tomas ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ZFS: fix some warnings, cleanup
Add some CCs On Wednesday 19 September 2012 17:32:36 Pavel Herrmann wrote: Fix warnings about type mismatch in cmd_zfs. Dont use a global block_dev_desc, instead use a local one in each cmd. Signed-off-by: Pavel Herrmann morpheus.i...@gmail.com --- common/cmd_zfs.c | 7 +-- fs/zfs/zfs.c | 2 -- include/zfs_common.h | 3 --- 3 files changed, 5 insertions(+), 7 deletions(-) diff --git a/common/cmd_zfs.c b/common/cmd_zfs.c index a6ea2c0..42e286e 100644 --- a/common/cmd_zfs.c +++ b/common/cmd_zfs.c @@ -46,7 +46,8 @@ #define DOS_FS_TYPE_OFFSET 0x36 #define DOS_FS32_TYPE_OFFSET 0x52 -static int do_zfs_load(cmd_tbl_t *cmdtp, int flag, int argc, char *argv[]) +static int do_zfs_load(cmd_tbl_t *cmdtp, int flag, int argc, + char * const argv[]) { char *filename = NULL; char *ep; @@ -60,6 +61,7 @@ static int do_zfs_load(cmd_tbl_t *cmdtp, int flag, int argc, char *argv[]) const char *addr_str; struct zfs_file zfile; struct device_s vdev; + struct block_dev_desc *zfs_dev_desc; if (argc 3) return CMD_RET_USAGE; @@ -178,7 +180,7 @@ int zfs_print(const char *entry, const struct zfs_dirhook_info *data) -static int do_zfs_ls(cmd_tbl_t *cmdtp, int flag, int argc, char *argv[]) +static int do_zfs_ls(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) { const char *filename = /; int dev; @@ -186,6 +188,7 @@ static int do_zfs_ls(cmd_tbl_t *cmdtp, int flag, int argc, char *argv[]) char *ep; int part_length; struct device_s vdev; + struct block_dev_desc *zfs_dev_desc; if (argc 3) return cmd_usage(cmdtp); diff --git a/fs/zfs/zfs.c b/fs/zfs/zfs.c index 360f723..d709e02 100644 --- a/fs/zfs/zfs.c +++ b/fs/zfs/zfs.c @@ -31,8 +31,6 @@ #include asm/byteorder.h #include zfs_common.h -block_dev_desc_t *zfs_dev_desc; - /* * The zfs plug-in routines for GRUB are: * diff --git a/include/zfs_common.h b/include/zfs_common.h index 04e73d0..fa0919a 100644 --- a/include/zfs_common.h +++ b/include/zfs_common.h @@ -66,9 +66,6 @@ struct zfs_filesystem { block_dev_desc_t *dev_desc; }; - -extern block_dev_desc_t *zfs_dev_desc; - struct device_s { uint64_t part_length; }; ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] FAT: split block device interactions from filesystem logic
add some CCs On Wednesday 19 September 2012 16:34:02 Pavel Herrmann wrote: Put block device interaction code into separate file from filesystem logic. This makes it easier to change block device API, and is similar to what other filesystems do. Cleanup some logic inconsistencies as well. Signed-off-by: Pavel Herrmann morpheus.i...@gmail.com --- fs/fat/Makefile| 4 +- fs/fat/dev.c | 191 + fs/fat/fat.c | 175 ++-- fs/fat/fat_write.c | 21 +++--- include/fat.h | 7 ++ 5 files changed, 228 insertions(+), 170 deletions(-) create mode 100644 fs/fat/dev.c diff --git a/fs/fat/Makefile b/fs/fat/Makefile index 9635d36..5d10b24 100644 --- a/fs/fat/Makefile +++ b/fs/fat/Makefile @@ -24,8 +24,8 @@ include $(TOPDIR)/config.mk LIB = $(obj)libfat.o AOBJS= -COBJS-$(CONFIG_CMD_FAT) := fat.o -COBJS-$(CONFIG_FAT_WRITE):= fat_write.o +COBJS-$(CONFIG_CMD_FAT) := fat.o dev.o +COBJS-$(CONFIG_FAT_WRITE) := fat_write.o dev.o ifndef CONFIG_SPL_BUILD COBJS-$(CONFIG_CMD_FAT) += file.o diff --git a/fs/fat/dev.c b/fs/fat/dev.c new file mode 100644 index 000..d5ff0c5 --- /dev/null +++ b/fs/fat/dev.c @@ -0,0 +1,191 @@ +/* + * (C) Copyright 2012 + * Pavel Herrmann morpheus.i...@gmail.com + * + * See file CREDITS for list of people who contributed to this + * project. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; either version 2 of + * the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, + * MA 02111-1307 USA + */ + +#include common.h +#include fat.h +#include part.h +#include errno.h + +#define DOS_BOOT_MAGIC_OFFSET 0x1fe +#define DOS_FS_TYPE_OFFSET 0x36 +#define DOS_FS32_TYPE_OFFSET0x52 + +static block_dev_desc_t *cur_dev; +static unsigned int cur_part_nr; +static disk_partition_t cur_part_info; + +int fat_disk_read(__u32 block, __u32 nr_blocks, void *buf) +{ + if (!cur_dev || !cur_dev-block_read) + return -1; + + return cur_dev-block_read(cur_dev-dev, + cur_part_info.start + block, nr_blocks, buf); +} + +int fat_disk_write(__u32 block, __u32 nr_blocks, void *buf) +{ + if (!cur_dev || !cur_dev-block_read) + return -1; + + return cur_dev-block_read(cur_dev-dev, + cur_part_info.start + block, nr_blocks, buf); +} + +int fat_get_blksz(void) +{ + if (cur_dev == NULL) + return -EINVAL; + return cur_dev-blksz; +} + +int fat_get_partsize(void) +{ + if (cur_dev == NULL) + return -EINVAL; + return cur_part_info.size; +} + +int fat_register_device(block_dev_desc_t *dev_desc, int part_no) +{ + ALLOC_CACHE_ALIGN_BUFFER(unsigned char, buffer, dev_desc-blksz); + + /* First close any currently found FAT filesystem */ + cur_dev = NULL; + +#if (defined(CONFIG_CMD_IDE) || \ + defined(CONFIG_CMD_SATA) || \ + defined(CONFIG_CMD_SCSI) || \ + defined(CONFIG_CMD_USB) || \ + defined(CONFIG_MMC) || \ + defined(CONFIG_SYSTEMACE)) + + /* Read the partition table, if present */ + if (!get_partition_info(dev_desc, part_no, cur_part_info)) { + cur_dev = dev_desc; + cur_part_nr = part_no; + } +#endif + + /* Otherwise it might be a superfloppy (whole-disk FAT filesystem) */ + if (!cur_dev) { + if (part_no != 1) { + printf(** Partition %d not valid on device %d **\n, + part_no, dev_desc-dev); + return -1; + } + + cur_dev = dev_desc; + cur_part_nr = 1; + cur_part_info.start = 0; + cur_part_info.size = dev_desc-lba; + cur_part_info.blksz = dev_desc-blksz; + memset(cur_part_info.name, 0, sizeof(cur_part_info.name)); + memset(cur_part_info.type, 0, sizeof(cur_part_info.type)); + } + + /* Make sure it has a valid FAT header */ + if (fat_disk_read(0, 1, buffer) != 1) { + cur_dev = NULL; + return -1; + } + + /* Check if it's actually a DOS volume */ + if (memcmp(buffer + DOS_BOOT_MAGIC_OFFSET, \x55\xAA, 2)) { + cur_dev = NULL; + return -1; + } + + /* Check for
Re: [U-Boot] [PATCH] ZFS: fix some warnings, cleanup
Dear Pavel Herrmann, Did you test the changes? Add some CCs On Wednesday 19 September 2012 17:32:36 Pavel Herrmann wrote: Fix warnings about type mismatch in cmd_zfs. Dont use a global block_dev_desc, instead use a local one in each cmd. The warnings generated would be appreciated in the commit message. Signed-off-by: Pavel Herrmann morpheus.i...@gmail.com --- common/cmd_zfs.c | 7 +-- fs/zfs/zfs.c | 2 -- include/zfs_common.h | 3 --- 3 files changed, 5 insertions(+), 7 deletions(-) diff --git a/common/cmd_zfs.c b/common/cmd_zfs.c index a6ea2c0..42e286e 100644 --- a/common/cmd_zfs.c +++ b/common/cmd_zfs.c @@ -46,7 +46,8 @@ #define DOS_FS_TYPE_OFFSET 0x36 #define DOS_FS32_TYPE_OFFSET 0x52 -static int do_zfs_load(cmd_tbl_t *cmdtp, int flag, int argc, char *argv[]) +static int do_zfs_load(cmd_tbl_t *cmdtp, int flag, int argc, + char * const argv[]) { char *filename = NULL; char *ep; @@ -60,6 +61,7 @@ static int do_zfs_load(cmd_tbl_t *cmdtp, int flag, int argc, char *argv[]) const char *addr_str; struct zfs_file zfile; struct device_s vdev; + struct block_dev_desc *zfs_dev_desc; if (argc 3) return CMD_RET_USAGE; @@ -178,7 +180,7 @@ int zfs_print(const char *entry, const struct zfs_dirhook_info *data) -static int do_zfs_ls(cmd_tbl_t *cmdtp, int flag, int argc, char *argv[]) +static int do_zfs_ls(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) { const char *filename = /; int dev; @@ -186,6 +188,7 @@ static int do_zfs_ls(cmd_tbl_t *cmdtp, int flag, int argc, char *argv[]) char *ep; int part_length; struct device_s vdev; + struct block_dev_desc *zfs_dev_desc; if (argc 3) return cmd_usage(cmdtp); diff --git a/fs/zfs/zfs.c b/fs/zfs/zfs.c index 360f723..d709e02 100644 --- a/fs/zfs/zfs.c +++ b/fs/zfs/zfs.c @@ -31,8 +31,6 @@ #include asm/byteorder.h #include zfs_common.h -block_dev_desc_t *zfs_dev_desc; - /* * The zfs plug-in routines for GRUB are: * diff --git a/include/zfs_common.h b/include/zfs_common.h index 04e73d0..fa0919a 100644 --- a/include/zfs_common.h +++ b/include/zfs_common.h @@ -66,9 +66,6 @@ struct zfs_filesystem { block_dev_desc_t *dev_desc; }; - -extern block_dev_desc_t *zfs_dev_desc; - struct device_s { uint64_t part_length; }; Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v7] [RFC] early_malloc for DM added.
early_malloc for DM with support for more heaps and lightweight first heap in the same memory as an early stack. Adaptation layer for seamless calling of early_malloc or dlmalloc from DM based on init stage added (dmmalloc() and related functions). Signed-off-by: Tomas Hlavacek tmshl...@gmail.com --- Changelog since v5: dmmalloc() and all dm* functions has been moved to header, made static inline and preprocessor-dependent blocks are reworked. early_malloc_active() corrected and made not static. s/CONFIG_SYS_DM/CONFIG_DM/ applied. Changelog sice v6: Check of first heap emptyness in early_brk() has been simplified. arch/arm/include/asm/global_data.h|3 + arch/arm/lib/board.c |8 +++ arch/avr32/include/asm/global_data.h |3 + arch/avr32/lib/board.c|9 +++ arch/blackfin/include/asm/global_data.h |3 + arch/blackfin/lib/board.c |8 +++ arch/m68k/include/asm/global_data.h |3 + arch/m68k/lib/board.c |8 +++ arch/microblaze/include/asm/global_data.h |3 + arch/microblaze/lib/board.c |9 +++ arch/mips/include/asm/global_data.h |3 + arch/mips/lib/board.c |8 +++ arch/nds32/include/asm/global_data.h |3 + arch/nds32/lib/board.c|8 +++ arch/nios2/include/asm/global_data.h |3 + arch/nios2/lib/board.c|8 +++ arch/openrisc/include/asm/global_data.h |3 + arch/openrisc/lib/board.c |8 +++ arch/powerpc/include/asm/global_data.h|3 + arch/powerpc/lib/board.c |8 +++ arch/sandbox/include/asm/global_data.h|3 + arch/sandbox/lib/board.c |8 +++ arch/sh/include/asm/global_data.h |3 + arch/sh/lib/board.c |8 +++ arch/sparc/include/asm/global_data.h |3 + arch/sparc/lib/board.c|8 +++ arch/x86/include/asm/global_data.h|3 + arch/x86/lib/board.c | 18 ++ common/Makefile |1 + common/dmmalloc.c | 88 include/dmmalloc.h| 89 + 31 files changed, 344 insertions(+) create mode 100644 common/dmmalloc.c create mode 100644 include/dmmalloc.h diff --git a/arch/arm/include/asm/global_data.h b/arch/arm/include/asm/global_data.h index f8088fe..ef727b0 100644 --- a/arch/arm/include/asm/global_data.h +++ b/arch/arm/include/asm/global_data.h @@ -82,6 +82,9 @@ typedef struct global_data { unsigned long post_log_res; /* success of POST test */ unsigned long post_init_f_time; /* When post_init_f started */ #endif +#ifdef CONFIG_SYS_EARLY_MALLOC + void*early_heap_first; /* heap for early_malloc */ +#endif } gd_t; #include asm-generic/global_data_flags.h diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c index f1951e8..f73d8b2 100644 --- a/arch/arm/lib/board.c +++ b/arch/arm/lib/board.c @@ -53,6 +53,10 @@ #include post.h #include logbuff.h +#ifdef CONFIG_DM +#include dmmalloc.h +#endif + #ifdef CONFIG_BITBANGMII #include miiphy.h #endif @@ -281,6 +285,10 @@ void board_init_f(ulong bootflag) memset((void *)gd, 0, sizeof(gd_t)); +#ifdef CONFIG_SYS_EARLY_MALLOC + gd-early_heap_first = early_brk(CONFIG_SYS_EARLY_HEAP_SIZE); +#endif /* CONFIG_SYS_EARLY_MALLOC */ + gd-mon_len = _bss_end_ofs; #ifdef CONFIG_OF_EMBED /* Get a pointer to the FDT */ diff --git a/arch/avr32/include/asm/global_data.h b/arch/avr32/include/asm/global_data.h index 7878bb1..0654a61 100644 --- a/arch/avr32/include/asm/global_data.h +++ b/arch/avr32/include/asm/global_data.h @@ -48,6 +48,9 @@ typedef struct global_data { #endif void**jt; /* jump table */ charenv_buf[32];/* buffer for getenv() before reloc. */ +#ifdef CONFIG_SYS_EARLY_MALLOC + void*early_heap_first; /* heap for early_malloc */ +#endif } gd_t; #include asm-generic/global_data_flags.h diff --git a/arch/avr32/lib/board.c b/arch/avr32/lib/board.c index d7a64b4..f1bd946 100644 --- a/arch/avr32/lib/board.c +++ b/arch/avr32/lib/board.c @@ -42,6 +42,11 @@ #ifdef CONFIG_GENERIC_ATMEL_MCI #include mmc.h #endif + +#ifdef CONFIG_DM +#include dmmalloc.h +#endif + DECLARE_GLOBAL_DATA_PTR; unsigned long monitor_flash_len; @@ -161,6 +166,10 @@ void board_init_f(ulong board_type) memset(gd_data, 0, sizeof(gd_data)); gd = gd_data; +#ifdef CONFIG_SYS_EARLY_MALLOC + gd-early_heap_first = early_brk(CONFIG_SYS_EARLY_HEAP_SIZE); +#endif /* CONFIG_SYS_EARLY_MALLOC */ + /* Perform initialization sequence */ board_early_init_f(); cpu_init(); diff --git a/arch/blackfin/include/asm/global_data.h
Re: [U-Boot] [PATCH V2 06/21] imximage: add plugin commands
On 22/09/2012 04:39, Troy Kisky wrote: Add commands plugin address filename iomux_entry addr, data1 [, data2, [, data3]] write_entry addr, data1 [, data2, [, data3]] Why do we need explicitely an IOMUX command ? As far as I can see, the program image defined in V2 defines a plugin, but not an iomux. I am expecting that the imximage generates a iMX header only, without moving some code from the initialization code directly here. In the manula there is a Write Data (what we have always had), a Check data and an Unlock commands. If we start to add special commands, maybe we are staring again to reimplement U-Boot. We could have some SET_CLK, SET_CPU_FREQ, and so on. What I am really mising in this series is why you are moving a lot of things from U-Boot into the iMX header. It seems to me we want to put much more code in the iMX header as what it is really required to boot the device. Adding / modifying the syntax requires to update doc/README.imximage, too. Signed-off-by: Troy Kisky troy.ki...@boundarydevices.com --- tools/imximage.c | 334 -- tools/imximage.h | 11 +- 2 files changed, 283 insertions(+), 62 deletions(-) diff --git a/tools/imximage.c b/tools/imximage.c index 2c5a622..fae786a 100644 --- a/tools/imximage.c +++ b/tools/imximage.c @@ -31,7 +31,6 @@ #include mkimage.h #include image.h #include imximage.h - /* * Supported commands for configuration file */ @@ -39,6 +38,9 @@ static table_entry_t imximage_cmds[] = { {CMD_BOOT_FROM, BOOT_FROM,boot command, }, {CMD_DATA, DATA, Reg Write Data, }, {CMD_IMAGE_VERSION, IMAGE_VERSION,image version, }, + {CMD_PLUGIN,plugin, plugin addr,file, }, + {CMD_IOMUX_ENTRY, iomux_entry, Write iomux reg, }, + {CMD_WRITE_ENTRY, write_entry, Write register, }, {-1,, , }, }; @@ -69,8 +71,8 @@ static uint32_t imximage_version; static set_dcd_val_t set_dcd_val; static set_imx_hdr_t set_imx_hdr; -static set_imx_size_t set_imx_size; static uint32_t *p_max_dcd; +static uint32_t *header_size_ptr; static uint32_t g_flash_offset; static struct image_type_params imximage_params; @@ -88,8 +90,7 @@ static uint32_t detect_imximage_version(struct imx_header *imx_hdr) return IMXIMAGE_V1; /* Try to detect V2 */ - if ((fhdr_v2-header.tag == IVT_HEADER_TAG) - (hdr_v2-dcd_table.header.tag == DCD_HEADER_TAG)) + if ((fhdr_v2-header.tag == IVT_HEADER_TAG)) return IMXIMAGE_V2; Help me to understand. I am reading i.MX6 manual and, even if the number of DCD entries could be variable, I do not see why the header tag of DCD is moving. At least, this is what I can see on picture 7-19, Image Vector table. return IMXIMAGE_VER_INVALID; @@ -160,7 +161,7 @@ static int set_dcd_val_v2(struct imx_header *imxhdr, uint32_t *data) } static int set_imx_hdr_v1(struct imx_header *imxhdr, - uint32_t entry_point, uint32_t flash_offset) + uint32_t entry_point, uint32_t flash_offset, int plugin) { imx_header_v1_t *hdr_v1 = imxhdr-header.hdr_v1; flash_header_v1_t *fhdr_v1 = hdr_v1-fhdr; @@ -180,22 +181,12 @@ static int set_imx_hdr_v1(struct imx_header *imxhdr, /* Security feature are not supported */ fhdr_v1-app_code_csf = 0; fhdr_v1-super_root_key = 0; + header_size_ptr = (uint32_t *)(((char *)imxhdr) + header_length - 4); return header_length; } -static void set_imx_size_v1(struct imx_header *imxhdr, uint32_t file_size, - uint32_t flash_offset) -{ - uint32_t *p = (uint32_t *)(((char *)imxhdr) - + imximage_params.header_size); - - /* The external flash header must be at the end of the DCD table */ - /* file_size includes header */ - p[-1] = file_size + flash_offset; -} I think you have to squash some of your patches or to defines them in another way. You added this code previously, and you drop now. This makes more difficult to review your patches. - static int set_imx_hdr_v2(struct imx_header *imxhdr, - uint32_t entry_point, uint32_t flash_offset) + uint32_t entry_point, uint32_t flash_offset, int plugin) { imx_header_v2_t *hdr_v2 = imxhdr-header.hdr_v2; flash_header_v2_t *fhdr_v2 = hdr_v2-fhdr; @@ -216,27 +207,20 @@ static int set_imx_hdr_v2(struct imx_header *imxhdr, fhdr_v2-boot_data_ptr = hdr_base + offsetof(imx_header_v2_t, boot_data); hdr_v2-boot_data.start = hdr_base - flash_offset; + hdr_v2-boot_data.plugin = plugin; /* Security feature are not supported */ fhdr_v2-csf = 0; + header_size_ptr = hdr_v2-boot_data.size; return
[U-Boot] [PATCH 1/4] COMMON: Add __stringify() function
Copied from Linux kernel: commit 8f7c2c37319a81ef4c2bfdec67b1ccd5744d97e4 Date: Wed Apr 8 16:58:57 2009 +0800 This function converts static number to string in preprocessor. This is useful as it allows higher usage of puts() in favour of printf() Signed-off-by: Marek Vasut ma...@denx.de Cc: Wolfgang Denk w...@denx.de --- include/common.h |1 + include/linux/stringify.h | 12 2 files changed, 13 insertions(+), 0 deletions(-) create mode 100644 include/linux/stringify.h diff --git a/include/common.h b/include/common.h index 55025c0..9937a57 100644 --- a/include/common.h +++ b/include/common.h @@ -39,6 +39,7 @@ typedef volatile unsigned charvu_char; #include linux/bitops.h #include linux/types.h #include linux/string.h +#include linux/stringify.h #include asm/ptrace.h #include stdarg.h #if defined(CONFIG_PCI) (defined(CONFIG_4xx) !defined(CONFIG_AP1000)) diff --git a/include/linux/stringify.h b/include/linux/stringify.h new file mode 100644 index 000..841cec8 --- /dev/null +++ b/include/linux/stringify.h @@ -0,0 +1,12 @@ +#ifndef __LINUX_STRINGIFY_H +#define __LINUX_STRINGIFY_H + +/* Indirect stringification. Doing two levels allows the parameter to be a + * macro itself. For example, compile with -DFOO=bar, __stringify(FOO) + * converts to bar. + */ + +#define __stringify_1(x...)#x +#define __stringify(x...) __stringify_1(x) + +#endif /* !__LINUX_STRINGIFY_H */ -- 1.7.7.6 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/4] COMMON: Use __stringify() instead of xstr()
Kill multiple occurances and redeclaration of xstr in favor of __stringify(). Signed-off-by: Marek Vasut ma...@denx.de Cc: Wolfgang Denk w...@denx.de --- include/configs/MPC8308RDB.h|9 ++- include/configs/amcc-common.h | 25 ++- include/configs/at91sam9263ek.h |5 +--- include/configs/cam_enc_4xx.h | 36 -- include/configs/ea20.h | 11 +++-- include/configs/enbw_cmc.h | 19 +++-- include/configs/flea3.h | 14 +--- include/configs/ima3-mx53.h | 10 +++- include/configs/imx27lite-common.h | 15 + include/configs/km/keymile-common.h | 13 --- include/configs/km/km-powerpc.h | 12 +- include/configs/km/km_arm.h | 14 ++-- include/configs/manroland/common.h | 21 --- include/configs/mpc8308_p1m.h |9 ++- include/configs/mx35pdk.h | 14 +--- include/configs/qong.h |9 ++- include/configs/tam3517-common.h| 11 +++-- include/configs/tx25.h |5 +--- 18 files changed, 104 insertions(+), 148 deletions(-) diff --git a/include/configs/MPC8308RDB.h b/include/configs/MPC8308RDB.h index 7f2761c..a2716aa 100644 --- a/include/configs/MPC8308RDB.h +++ b/include/configs/MPC8308RDB.h @@ -525,9 +525,6 @@ #define CONFIG_BOOTDELAY 5 /* -1 disables auto-boot */ -#define xstr(s)str(s) -#define str(s) #s - #defineCONFIG_EXTRA_ENV_SETTINGS \ netdev=eth0\0 \ consoledev=ttyS0\0\ @@ -561,10 +558,10 @@ bootm ${kernel_addr_r} - ${fdt_addr_r}\0 \ bootcmd=run flash_self\0 \ load=tftp ${loadaddr} ${u-boot}\0 \ - update=protect off xstr(CONFIG_SYS_MONITOR_BASE) \ -+${filesize};era xstr(CONFIG_SYS_MONITOR_BASE) \ + update=protect off __stringify(CONFIG_SYS_MONITOR_BASE) \ ++${filesize};era __stringify(CONFIG_SYS_MONITOR_BASE)\ +${filesize};cp.b ${fileaddr}\ - xstr(CONFIG_SYS_MONITOR_BASE) ${filesize}\0 \ + __stringify(CONFIG_SYS_MONITOR_BASE) ${filesize}\0 \ upd=run load update\0 \ #endif /* __CONFIG_H */ diff --git a/include/configs/amcc-common.h b/include/configs/amcc-common.h index 056a22a..9d0c80b 100644 --- a/include/configs/amcc-common.h +++ b/include/configs/amcc-common.h @@ -189,14 +189,11 @@ #define CONFIG_ADDMISC addmisc=setenv bootargs ${bootargs}\0 #endif -#define xstr(s)str(s) -#define str(s) #s - /* * General common environment variables shared on all AMCC eval boards */ #define CONFIG_AMCC_DEF_ENV\ - netdev= xstr(CONFIG_USE_NETDEV) \0 \ + netdev= __stringify(CONFIG_USE_NETDEV) \0 \ nfsargs=setenv bootargs root=/dev/nfs rw \ nfsroot=${serverip}:${rootpath}\0 \ ramargs=setenv bootargs root=/dev/ram rw\0\ @@ -204,15 +201,15 @@ ip=${ipaddr}:${serverip}:${gatewayip}:${netmask} \ :${hostname}:${netdev}:off panic=1\0 \ addtty=setenv bootargs ${bootargs}\ -console= xstr(CONFIG_USE_TTY) ,${baudrate}\0 \ +console= __stringify(CONFIG_USE_TTY) ,${baudrate}\0 \ CONFIG_ADDMISC \ initrd_high=3000\0\ kernel_addr_r=100\0 \ fdt_addr_r=180\0 \ ramdisk_addr_r=190\0 \ - hostname= xstr(CONFIG_HOSTNAME) \0 \ - bootfile= xstr(CONFIG_HOSTNAME) /uImage\0 \ - ramdisk_file= xstr(CONFIG_HOSTNAME) /uRamdisk\0 \ + hostname= __stringify(CONFIG_HOSTNAME) \0 \ + bootfile= __stringify(CONFIG_HOSTNAME) /uImage\0 \ + ramdisk_file= __stringify(CONFIG_HOSTNAME) /uRamdisk\0 \ CONFIG_AMCC_DEF_ENV_ROOTPATH /* @@ -234,7 +231,7 @@ net_self=run net_self_load; \ run ramargs addip addtty addmisc; \ bootm ${kernel_addr_r} ${ramdisk_addr_r} ${fdt_addr_r}\0 \ - fdt_file= xstr(CONFIG_HOSTNAME) /
[U-Boot] [PATCH 4/4] COMMON: Use __stringify() instead of rest of implementations
Fix up the rest of implementations of __stringify(). Signed-off-by: Marek Vasut ma...@denx.de Cc: Wolfgang Denk w...@denx.de --- board/logicpd/zoom2/zoom2_serial.h |7 +++ include/configs/astro_mcf5373l.h |7 +++ include/configs/tegra20-common.h | 12 +++- include/nios2.h|5 +++-- 4 files changed, 12 insertions(+), 19 deletions(-) diff --git a/board/logicpd/zoom2/zoom2_serial.h b/board/logicpd/zoom2/zoom2_serial.h index 4e30587..ad63a07 100644 --- a/board/logicpd/zoom2/zoom2_serial.h +++ b/board/logicpd/zoom2/zoom2_serial.h @@ -22,6 +22,8 @@ #ifndef ZOOM2_SERIAL_H #define ZOOM2_SERIAL_H +#include linux/stringify.h + extern int zoom2_debug_board_connected (void); #define SERIAL_TL16CP754C_BASE 0x1000 /* Zoom2 Serial chip address */ @@ -31,9 +33,6 @@ extern int zoom2_debug_board_connected (void); #define QUAD_BASE_2(SERIAL_TL16CP754C_BASE + 0x200) #define QUAD_BASE_3(SERIAL_TL16CP754C_BASE + 0x300) -#define S(a) #a -#define N(a) S(quad##a) - #define QUAD_INIT(n) \ int quad_init_##n(void)\ { \ @@ -61,7 +60,7 @@ int quad_tstc_##n(void) \ } \ struct serial_device zoom2_serial_device##n = \ { \ - N(n), \ + __stringify(n), \ quad_init_##n, \ NULL, \ quad_setbrg_##n,\ diff --git a/include/configs/astro_mcf5373l.h b/include/configs/astro_mcf5373l.h index 5c4cac9..a0ed8f1 100644 --- a/include/configs/astro_mcf5373l.h +++ b/include/configs/astro_mcf5373l.h @@ -33,6 +33,8 @@ #ifndef _CONFIG_ASTRO_MCF5373L_H #define _CONFIG_ASTRO_MCF5373L_H +#include linux/stringify.h + /* * set the card type to actually compile for; either of * the possibilities listed below has to be used! @@ -209,12 +211,9 @@ * u-boot: 'set' command */ -#define _QUOTEME(x)#x -#define QUOTEME(x) _QUOTEME(x) - #define CONFIG_EXTRA_ENV_SETTINGS \ loaderversion=11\0\ - card_id=QUOTEME(ASTRO_ID)\0 \ + card_id=__stringify(ASTRO_ID)\0 \ alterafile=0\0\ xilinxfile=0\0\ xilinxload=imxtract 0x54 $xilinxfile 0x4100\ diff --git a/include/configs/tegra20-common.h b/include/configs/tegra20-common.h index 4c02f20..6f20d75 100644 --- a/include/configs/tegra20-common.h +++ b/include/configs/tegra20-common.h @@ -24,14 +24,7 @@ #ifndef __TEGRA20_COMMON_H #define __TEGRA20_COMMON_H #include asm/sizes.h - -/* - * QUOTE(m) will evaluate to a string version of the value of the macro m - * passed in. The extra level of indirection here is to first evaluate the - * macro m before applying the quoting operator. - */ -#define QUOTE_(m) #m -#define QUOTE(m)QUOTE_(m) +#include linux/stringify.h /* * High Level Configuration Options @@ -58,7 +51,8 @@ #define TEGRA_LP0_ADDR 0x1C406000 #define TEGRA_LP0_SIZE 0x2000 #define TEGRA_LP0_VEC \ - lp0_vec= QUOTE(TEGRA_LP0_SIZE) @ QUOTE(TEGRA_LP0_ADDR) + lp0_vec= __stringify(TEGRA_LP0_SIZE) \ + @ __stringify(TEGRA_LP0_ADDR) #else #define TEGRA_LP0_VEC #endif diff --git a/include/nios2.h b/include/nios2.h index 54954e3..df8126a 100644 --- a/include/nios2.h +++ b/include/nios2.h @@ -24,6 +24,8 @@ #ifndef __NIOS2_H__ #define __NIOS2_H__ +#include linux/stringify.h + /* * Control registers -- use with wrctl() rdctl() *--*/ @@ -36,11 +38,10 @@ /* * Access to control regs *--*/ -#define _str_(x) #x #define rdctl(reg)\ ({unsigned int val;\ - asm volatile( rdctl %0, ctl _str_(reg)\ + asm volatile(rdctl %0, ctl __stringify(reg) \ : =r (val) ); val;}) #define wrctl(reg,val)\ -- 1.7.7.6 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/6] h2200: Add support for iPAQ h2200 palmtop
Dear Lukasz Dalek, [...] +int dram_init(void) +{ + /* + * Everything except MSC0 was already set up by + * 1st stage bootloader + */ + clrsetbits_le32(MSC0, 0x, 0x246c7ffc); This magic would use more description eventually. + gd-ram_size = CONFIG_SYS_SDRAM_SIZE; + return 0; +} diff --git a/board/h2200/h2200.h b/board/h2200/h2200.h new file mode 100644 Do you need this file at all? Can the udc_disconnect() not be put somewhere into usb.h ? [...] Rest seems fine, thanks. 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 v2 2/6] pxa25x: Add support for USB ethernet gadget
Dear Lukasz Dalek, Add to pxa25x based devices support for USB ethernet gadget. This is a port of pxa25x UDC driver from Linux kernel. Signed-off-by: Lukasz Dalek luk0...@gmail.com --- drivers/usb/gadget/Makefile |1 + drivers/usb/gadget/pxa25x_udc.c | 2059 +++ drivers/usb/gadget/pxa25x_udc.h | 162 +++ 3 files changed, insertions(+), 0 deletions(-) create mode 100644 drivers/usb/gadget/pxa25x_udc.c create mode 100644 drivers/usb/gadget/pxa25x_udc.h [...] So what's the change here? Or is it a repost? 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 1/2] i.MX: mxc_ipuv3_fb: add ipuv3_fb_shutdown() routine to stop IPU before bootm
On 22/09/2012 16:37, Fabio Estevam wrote: On Sat, Sep 22, 2012 at 10:42 AM, Otavio Salvador ota...@ossystems.com.br wrote: Hello Eric, On Fri, Sep 21, 2012 at 5:36 PM, Eric Nelson eric.nel...@boundarydevices.com wrote: Signed-off-by: Eric Nelson eric.nel...@boundarydevices.com Did you test it in mx5 too? We seem to need to handle it in mx5 too as we had hungs in FSL kernel when using framebuffer in U-Boot. We're using a patch in kernel for workaround it but it seems your fix does what is need. I have just tested Eric's series on a mx53loco and it does fix the kernel hang issue. I made some comments on this series and hopefully Eric's v2 can get into 2012.10, since this is a bug fix. Ok, I am waiting for V2 and I will push it. Anyway, a question about the issue. It seems to me that it is not possible with IPUV3 (I have not tested myself, so my question) to get the u-boot splashscreen displayed on the LCD until the kernel has finished to boot. This could be possible (and it is possible on other SOC) if the IPU is loaded as module instead of statically linked to the kernel, and if the kernel does not touch the IPU setup. This means also that it should not disable the clocks used by U-Boot for the IPU. But I understand from your patch that this way is not possible on iMX53/MX6, and IPU must be always disabled. Is this correct ? Best regards, Stefano -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] mx25: add CPU revision 1.2
On 22/09/2012 22:50, Eric Bénard wrote: tested on a MCIMX257CJM4A which now reports : CPU: Freescale i.MX25 rev1.2 at 399 MHz Signed-off-by: Eric Bénard e...@eukrea.com --- arch/arm/cpu/arm926ejs/mx25/generic.c |3 +++ arch/arm/include/asm/arch-mx25/imx-regs.h |1 + 2 files changed, 4 insertions(+), 0 deletions(-) diff --git a/arch/arm/cpu/arm926ejs/mx25/generic.c b/arch/arm/cpu/arm926ejs/mx25/generic.c index 8b07dae..cb74b82 100644 --- a/arch/arm/cpu/arm926ejs/mx25/generic.c +++ b/arch/arm/cpu/arm926ejs/mx25/generic.c @@ -140,6 +140,9 @@ u32 get_cpu_rev(void) case 0x01: system_rev |= CHIP_REV_1_1; break; + case 0x02: + system_rev |= CHIP_REV_1_2; + break; default: system_rev |= 0x8000; break; diff --git a/arch/arm/include/asm/arch-mx25/imx-regs.h b/arch/arm/include/asm/arch-mx25/imx-regs.h index cf925d7..35a2fb6 100644 --- a/arch/arm/include/asm/arch-mx25/imx-regs.h +++ b/arch/arm/include/asm/arch-mx25/imx-regs.h @@ -355,5 +355,6 @@ struct aips_regs { #define CHIP_REV_1_0 0x10 #define CHIP_REV_1_1 0x11 +#define CHIP_REV_1_2 0x12 #endif /* _IMX_REGS_H */ Acked-by: Stefano Babic sba...@denx.de Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v8] [RFC] early_malloc for DM added.
early_malloc for DM with support for more heaps and lightweight first heap in the same memory as an early stack. Adaptation layer for seamless calling of early_malloc or dlmalloc from DM based on init stage added (dmmalloc() and related functions). Signed-off-by: Tomas Hlavacek tmshl...@gmail.com --- Changelog since v5: dmmalloc() and all dm* functions has been moved to header, made static inline and preprocessor-dependent blocks are reworked. early_malloc_active() corrected and made not static. s/CONFIG_SYS_DM/CONFIG_DM/ applied. Changelog sice v6: Check of first heap emptyness in early_brk() has been simplified. Changelog since v7: dmcalloc() implmentation added. Comments added to header. arch/arm/include/asm/global_data.h|3 + arch/arm/lib/board.c |8 ++ arch/avr32/include/asm/global_data.h |3 + arch/avr32/lib/board.c|9 +++ arch/blackfin/include/asm/global_data.h |3 + arch/blackfin/lib/board.c |8 ++ arch/m68k/include/asm/global_data.h |3 + arch/m68k/lib/board.c |8 ++ arch/microblaze/include/asm/global_data.h |3 + arch/microblaze/lib/board.c |9 +++ arch/mips/include/asm/global_data.h |3 + arch/mips/lib/board.c |8 ++ arch/nds32/include/asm/global_data.h |3 + arch/nds32/lib/board.c|8 ++ arch/nios2/include/asm/global_data.h |3 + arch/nios2/lib/board.c|8 ++ arch/openrisc/include/asm/global_data.h |3 + arch/openrisc/lib/board.c |8 ++ arch/powerpc/include/asm/global_data.h|3 + arch/powerpc/lib/board.c |8 ++ arch/sandbox/include/asm/global_data.h|3 + arch/sandbox/lib/board.c |8 ++ arch/sh/include/asm/global_data.h |3 + arch/sh/lib/board.c |8 ++ arch/sparc/include/asm/global_data.h |3 + arch/sparc/lib/board.c|8 ++ arch/x86/include/asm/global_data.h|3 + arch/x86/lib/board.c | 18 + common/Makefile |1 + common/dmmalloc.c | 88 ++ include/dmmalloc.h| 117 + 31 files changed, 372 insertions(+) create mode 100644 common/dmmalloc.c create mode 100644 include/dmmalloc.h diff --git a/arch/arm/include/asm/global_data.h b/arch/arm/include/asm/global_data.h index f8088fe..ef727b0 100644 --- a/arch/arm/include/asm/global_data.h +++ b/arch/arm/include/asm/global_data.h @@ -82,6 +82,9 @@ typedef struct global_data { unsigned long post_log_res; /* success of POST test */ unsigned long post_init_f_time; /* When post_init_f started */ #endif +#ifdef CONFIG_SYS_EARLY_MALLOC + void*early_heap_first; /* heap for early_malloc */ +#endif } gd_t; #include asm-generic/global_data_flags.h diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c index f1951e8..f73d8b2 100644 --- a/arch/arm/lib/board.c +++ b/arch/arm/lib/board.c @@ -53,6 +53,10 @@ #include post.h #include logbuff.h +#ifdef CONFIG_DM +#include dmmalloc.h +#endif + #ifdef CONFIG_BITBANGMII #include miiphy.h #endif @@ -281,6 +285,10 @@ void board_init_f(ulong bootflag) memset((void *)gd, 0, sizeof(gd_t)); +#ifdef CONFIG_SYS_EARLY_MALLOC + gd-early_heap_first = early_brk(CONFIG_SYS_EARLY_HEAP_SIZE); +#endif /* CONFIG_SYS_EARLY_MALLOC */ + gd-mon_len = _bss_end_ofs; #ifdef CONFIG_OF_EMBED /* Get a pointer to the FDT */ diff --git a/arch/avr32/include/asm/global_data.h b/arch/avr32/include/asm/global_data.h index 7878bb1..0654a61 100644 --- a/arch/avr32/include/asm/global_data.h +++ b/arch/avr32/include/asm/global_data.h @@ -48,6 +48,9 @@ typedef struct global_data { #endif void**jt; /* jump table */ charenv_buf[32];/* buffer for getenv() before reloc. */ +#ifdef CONFIG_SYS_EARLY_MALLOC + void*early_heap_first; /* heap for early_malloc */ +#endif } gd_t; #include asm-generic/global_data_flags.h diff --git a/arch/avr32/lib/board.c b/arch/avr32/lib/board.c index d7a64b4..f1bd946 100644 --- a/arch/avr32/lib/board.c +++ b/arch/avr32/lib/board.c @@ -42,6 +42,11 @@ #ifdef CONFIG_GENERIC_ATMEL_MCI #include mmc.h #endif + +#ifdef CONFIG_DM +#include dmmalloc.h +#endif + DECLARE_GLOBAL_DATA_PTR; unsigned long monitor_flash_len; @@ -161,6 +166,10 @@ void board_init_f(ulong board_type) memset(gd_data, 0, sizeof(gd_data)); gd = gd_data; +#ifdef CONFIG_SYS_EARLY_MALLOC + gd-early_heap_first = early_brk(CONFIG_SYS_EARLY_HEAP_SIZE); +#endif /* CONFIG_SYS_EARLY_MALLOC */ + /* Perform initialization sequence */ board_early_init_f(); cpu_init(); diff --git
Re: [U-Boot] [PATCH V2 08/21] mx6: add plugin file for use with imximage.cfg
On 09/23/2012 03:17 AM, Stefano Babic wrote: On 22/09/2012 04:39, Troy Kisky wrote: The plugin command of mkimage can take this file as an argument. Signed-off-by: Troy Kiskytroy.ki...@boundarydevices.com --- Hi Troy, I agree with Vikram that a better explanation of what a plugin is can help to understand without reading deeply into the i.MX6 manual. So a plugin is a chunk of code that can be called directly by the BootROM of i.MX processors supporting V2 version of the i.MX header. In my understanding, this is supported by i.MX53, too. After the plugin run, the control is returned to the BootROM. Hi Stefano, It seems that there's some general confusion on the list, so I think a little more background and commentary is in order. The primary rationale for plugins is to allow separate link maps in a single image loaded by the BootROM. The idea is to allow first-level code to initialize resources (usually DDR) while running in internal RAM, then return to the boot rom for further image loading (typically into DDR). This prevents the need for the first-level code to support all boot sources (SPI-NOR, NAND, SD card, etc) and allows it to focus on machine setup. The feature is normally needed to allow the first level to access a PMIC. I'm surprised that the 51evk and 53Loco boards aren't using it. Troy's rationale for using it now is to enable a single image on i.MX6Quad, Dual lite and Solo processors, which have very slight initialization differences. The 6Solo processor has 32-bit DDR bus, so it would otherwise require a separate binary. By doing this in code (plugin), we can introduce a conditional based on processor type and have a single image that will boot on any of the three. The other key change for these processors is the location of the iomux controller (moved on 6Solo/Duallite from 6Quad). 6Solo has 32-bit DDR and iomux controller moved from 6Q 6Duallite has 64-bit DDR but same iomux location as 6Q Note that this highlights a slight down side to the plugin approach. Because of the movement of the iomux controller, we can't use a universal i.MX6 image header to write any IOMUX registers through imximage.cfg. Regards, Eric ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 10/11] Add u-boot-pad.bin target to the Makefile
Dear Marek Vasut, In message 201209212124.05075.ma...@denx.de you wrote: Leave u-boot.bin be, that's the u-boot binary ... the new name might be u- boot.img (as in flash image), what do you say ? Please re-read my earlier posting here: http://article.gmane.org/gmane.comp.boot-loaders.u-boot/141749 Are there any strong arguments against my proposal? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de If programming was easy, they wouldn't need something as complicated as a human being to do it, now would they? - L. Wall R. L. Schwartz, _Programming Perl_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v8] [RFC] early_malloc for DM added.
Dear Tomas Hlavacek, In message 1348416940-20319-1-git-send-email-tmshl...@gmail.com you wrote: early_malloc for DM with support for more heaps and lightweight first heap in the same memory as an early stack. Adaptation layer for seamless calling of early_malloc or dlmalloc from DM based on init stage added (dmmalloc() and related functions). Signed-off-by: Tomas Hlavacek tmshl...@gmail.com --- Changelog since v5: dmmalloc() and all dm* functions has been moved to header, made static inline and preprocessor-dependent blocks are reworked. early_malloc_active() corrected and made not static. s/CONFIG_SYS_DM/CONFIG_DM/ applied. Changelog sice v6: Check of first heap emptyness in early_brk() has been simplified. Changelog since v7: dmcalloc() implmentation added. Comments added to header. Your change log does not make much sense to me. It appears there has been some dmcalloc() implementation already in v5 (and eearlier?), as you write there you moved it into the header file. Now you add it again? This changelog is intended to desccribe the difference between the patch versions, to allow a reviewer to recognize which comments you addressed, and where you decided otherwise. Your log does not provide any such information. Also, please re-read the recommendations for the commit message. FOO added is considered bad; please use something like add FOO instead (i. e. describe what this commit actually does). Also, please make sure tu run ALL patches through checkpatch before submitting; your patch throws 4 errors that all need fixing. Finally, you might want to consult a spell checker every now and then (see for example implmentation, perfrom, etc.). Thanks. Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de I'm not a god, I was misquoted. - Lister, Red Dwarf ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] i.MX: mxc_ipuv3_fb: add ipuv3_fb_shutdown() routine to stop IPU before bootm
On 23.09.2012 17:56, Stefano Babic wrote: On 22/09/2012 16:37, Fabio Estevam wrote: On Sat, Sep 22, 2012 at 10:42 AM, Otavio Salvador ota...@ossystems.com.br wrote: Hello Eric, On Fri, Sep 21, 2012 at 5:36 PM, Eric Nelson eric.nel...@boundarydevices.com wrote: Signed-off-by: Eric Nelsoneric.nel...@boundarydevices.com Did you test it in mx5 too? We seem to need to handle it in mx5 too as we had hungs in FSL kernel when using framebuffer in U-Boot. We're using a patch in kernel for workaround it but it seems your fix does what is need. I have just tested Eric's series on a mx53loco and it does fix the kernel hang issue. I made some comments on this series and hopefully Eric's v2 can get into 2012.10, since this is a bug fix. Ok, I am waiting for V2 and I will push it. Anyway, a question about the issue. It seems to me that it is not possible with IPUV3 (I have not tested myself, so my question) to get the u-boot splashscreen displayed on the LCD until the kernel has finished to boot. This could be possible (and it is possible on other SOC) if the IPU is loaded as module instead of statically linked to the kernel, and if the kernel does not touch the IPU setup. This means also that it should not disable the clocks used by U-Boot for the IPU. But I understand from your patch that this way is not possible on iMX53/MX6, and IPU must be always disabled. Is this correct ? I'm no expert on this, so I might be wrong and people will correct me: No, not always. It's my understanding that at the *moment* we have to disable the IPU in U-Boot before jumping into the kernel due to a bug in Sascha's kernel IPU driver: http://lists.infradead.org/pipermail/linux-arm-kernel/2012-September/121980.html http://lists.infradead.org/pipermail/linux-arm-kernel/2012-September/122100.html So from my understanding, this isn't a SOC limitation. But we have to do it as long as the kernel's IPU driver isn't fixed. Sorry if this is wrong ;) Best regards Dirk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] i.MX: mxc_ipuv3_fb: add ipuv3_fb_shutdown() routine to stop IPU before bootm
Hi Stefano, On 09/23/2012 08:56 AM, Stefano Babic wrote: On 22/09/2012 16:37, Fabio Estevam wrote: On Sat, Sep 22, 2012 at 10:42 AM, Otavio Salvador ota...@ossystems.com.br wrote: Hello Eric, On Fri, Sep 21, 2012 at 5:36 PM, Eric Nelson eric.nel...@boundarydevices.com wrote: Signed-off-by: Eric Nelsoneric.nel...@boundarydevices.com Did you test it in mx5 too? We seem to need to handle it in mx5 too as we had hungs in FSL kernel when using framebuffer in U-Boot. We're using a patch in kernel for workaround it but it seems your fix does what is need. I have just tested Eric's series on a mx53loco and it does fix the kernel hang issue. I made some comments on this series and hopefully Eric's v2 can get into 2012.10, since this is a bug fix. Ok, I am waiting for V2 and I will push it. I'll forward this later today. Anyway, a question about the issue. It seems to me that it is not possible with IPUV3 (I have not tested myself, so my question) to get the u-boot splashscreen displayed on the LCD until the kernel has finished to boot. This could be possible (and it is possible on other SOC) if the IPU is loaded as module instead of statically linked to the kernel, and if the kernel does not touch the IPU setup. This means also that it should not disable the clocks used by U-Boot for the IPU. I'm not sure I understand. The splash screen comes up as soon as the call to ipuv3_fb_init() is made (in board_video_skip() in my implementation for SABRE Lite). As it stands, if we leave the IPU running, we'll see garbage on the display as the kernel re-purposes the RAM used by U-Boot's frame buffer. But I understand from your patch that this way is not possible on iMX53/MX6, and IPU must be always disabled. Is this correct ? Sascha responded to a note about this on AKML that the hand-over of a live FB isn't a supported kernel use case and it's definitely tricky. I don't know about the policy, but from a practical matter, the IPU frame buffer implementation in U-Boot isn't currently up to that task, since: it only supports a single display (i.MX6 can handle 4) it only supports 16bpp Additional functionality would be helpful here. I would like to see a handoff of display settings from U-Boot to the kernel, but that's also a tricky thing as long as we're supporting different mechanisms (DT in main-line and kernel parameters in older kernels). Regards, Eric ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v8] [RFC] early_malloc for DM added.
Dear Wolfgang Denk, On Sun, Sep 23, 2012 at 6:32 PM, Wolfgang Denk w...@denx.de wrote: Changelog since v7: dmcalloc() implmentation added. Comments added to header. Your change log does not make much sense to me. It appears there has been some dmcalloc() implementation already in v5 (and eearlier?), as you write there you moved it into the header file. Now you add it again? Well no. The dmcalloc function returned always NULL in the early stage in the previous versions. The current version of dmcalloc simulates calloc also in the early_mallocator stage. Also, please re-read the recommendations for the commit message. FOO added is considered bad; please use something like add FOO instead (i. e. describe what this commit actually does). I will do that. Tomas ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] i.MX: mxc_ipuv3_fb: add ipuv3_fb_shutdown() routine to stop IPU before bootm
On Sun, Sep 23, 2012 at 1:46 PM, Eric Nelson eric.nel...@boundarydevices.com wrote: As it stands, if we leave the IPU running, we'll see garbage on the display as the kernel re-purposes the RAM used by U-Boot's frame buffer. And on mx53qsb we get kernel hangs at about half of the boots (tested on 2.6.35 FSL kernel). So turning off the IPU in U-boot, as Eric did in this series is an important fix. Regards, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] COMMON: Add __stringify() function
Hi Marek, On Sun, 23 Sep 2012 17:41:22 +0200, Marek Vasut ma...@denx.de wrote: Copied from Linux kernel: commit 8f7c2c37319a81ef4c2bfdec67b1ccd5744d97e4 Date: Wed Apr 8 16:58:57 2009 +0800 This function converts static number to string in preprocessor. This is useful as it allows higher usage of puts() in favour of printf() Fix commit message: this fonction is not limited to numbers. Signed-off-by: Marek Vasut ma...@denx.de Cc: Wolfgang Denk w...@denx.de --- include/common.h |1 + include/linux/stringify.h | 12 2 files changed, 13 insertions(+), 0 deletions(-) create mode 100644 include/linux/stringify.h diff --git a/include/common.h b/include/common.h index 55025c0..9937a57 100644 --- a/include/common.h +++ b/include/common.h @@ -39,6 +39,7 @@ typedef volatile unsigned char vu_char; #include linux/bitops.h #include linux/types.h #include linux/string.h +#include linux/stringify.h #include asm/ptrace.h #include stdarg.h #if defined(CONFIG_PCI) (defined(CONFIG_4xx) !defined(CONFIG_AP1000)) diff --git a/include/linux/stringify.h b/include/linux/stringify.h new file mode 100644 index 000..841cec8 --- /dev/null +++ b/include/linux/stringify.h @@ -0,0 +1,12 @@ +#ifndef __LINUX_STRINGIFY_H +#define __LINUX_STRINGIFY_H + +/* Indirect stringification. Doing two levels allows the parameter to be a + * macro itself. For example, compile with -DFOO=bar, __stringify(FOO) + * converts to bar. + */ + +#define __stringify_1(x...) #x +#define __stringify(x...)__stringify_1(x) + +#endif /* !__LINUX_STRINGIFY_H */ Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 08/21] mx6: add plugin file for use with imximage.cfg
On 23/09/2012 18:23, Eric Nelson wrote: On 09/23/2012 03:17 AM, Stefano Babic wrote: On 22/09/2012 04:39, Troy Kisky wrote: The plugin command of mkimage can take this file as an argument. Signed-off-by: Troy Kiskytroy.ki...@boundarydevices.com --- Hi Troy, I agree with Vikram that a better explanation of what a plugin is can help to understand without reading deeply into the i.MX6 manual. So a plugin is a chunk of code that can be called directly by the BootROM of i.MX processors supporting V2 version of the i.MX header. In my understanding, this is supported by i.MX53, too. After the plugin run, the control is returned to the BootROM. Hi Stefano, It seems that there's some general confusion on the list, so I think a little more background and commentary is in order. Well, it is - thanks for explanation. The primary rationale for plugins is to allow separate link maps in a single image loaded by the BootROM. The idea is to allow first-level code to initialize resources (usually DDR) while running in internal RAM, then return to the boot rom for further image loading (typically into DDR). This prevents the need for the first-level code to support all boot sources (SPI-NOR, NAND, SD card, etc) and allows it to focus on machine setup. The feature is normally needed to allow the first level to access a PMIC. I'm surprised that the 51evk and 53Loco boards aren't using it. The mx51 uses a V1 header and the plugin feature is not supported at all. So, it can't, simply. The mx53 can, but it is not needed. Both boards boot without plugin. So it seem we have a misunderstanding, and thanks to raise this issue ;-) The setup is done by the SOC interpreting the DCD data into the iMX header. After this setup, that in any case cannot be very long, the control is still taken by the bootROM, that copies data from the media device to the DDR according to the values set into the iMX header. Still without plugin. After the copy, the bootROM gives the control to U-Boot for the rest that starts with the usual initialization. There is no need to setup the pMIC on mx51evk and mx53qsb to get the DDR running. However, even if we need it, we can do it in another way, as I will explain now. Troy's rationale for using it now is to enable a single image on i.MX6Quad, Dual lite and Solo processors, which have very slight initialization differences. The 6Solo processor has 32-bit DDR bus, so it would otherwise require a separate binary. By doing this in code (plugin), we can introduce a conditional based on processor type and have a single image that will boot on any of the three. Ok - but why cannot this check be done directly by U-Boot ? My understanding is that you want to add a plugin written in assembly to allow different setup of the DDR controller. Let's see how we can do with standard U-Boot code. Core of the startup is that the SOC copies itself some code into the internal RAM and started. This is done by bootROM, running is own code and running the plugin. We have already this mechanism with the SPL framework. The big advantage for this approach is that the same mechanism can be used on SOC of different vendors, while the one in this series is a solution strictly bound with (some) Freescale's SOC. The imx header can be still adapted to copy the SPL code into the internal RAM. When SPL is running, you have all freedom to check which is the CPU running and to adjust your DDR setting, and everything is C code. Both MX5 and MX6 have plenty of internal RAM to do this, because SPL requires ~30KB. I think the goal to have the same U-Boot binary can be reached using the SPL framework. As you are running U-Boot code, you have the possibility to do whatever you want. So my question is: if the main reason is to have a single image for all your iMX6 boards, why cannot we do it in a standard way using SPL ? The other key change for these processors is the location of the iomux controller (moved on 6Solo/Duallite from 6Quad). 6Solo has 32-bit DDR and iomux controller moved from 6Q 6Duallite has 64-bit DDR but same iomux location as 6Q Note that this highlights a slight down side to the plugin approach. Because of the movement of the iomux controller, we can't use a universal i.MX6 image header to write any IOMUX registers through imximage.cfg. However, you can do it with this approach: - you have a general imx header, that does not write into IOMUX It is your choice if this should set the DDR or not. You could also decide to have an empty DCD table. - your imx Header is generated for your SPL code, and the destination address for the SPL code is put into internal RAM - the bootROM will start reading the iMX header and DCD data and copies data from media (NAND, SPI, ..) into iRAM. There is no need for any special setup because the iRAM is always available. Then it gives the control to the SPL. - the SPL starts and performs the setup of the DDR, checking
Re: [U-Boot] [PATCH 1/2] i.MX: mxc_ipuv3_fb: add ipuv3_fb_shutdown() routine to stop IPU before bootm
On 23/09/2012 18:46, Eric Nelson wrote: Hi Stefano, On 09/23/2012 08:56 AM, Stefano Babic wrote: On 22/09/2012 16:37, Fabio Estevam wrote: On Sat, Sep 22, 2012 at 10:42 AM, Otavio Salvador ota...@ossystems.com.br wrote: Hello Eric, On Fri, Sep 21, 2012 at 5:36 PM, Eric Nelson eric.nel...@boundarydevices.com wrote: Signed-off-by: Eric Nelsoneric.nel...@boundarydevices.com Did you test it in mx5 too? We seem to need to handle it in mx5 too as we had hungs in FSL kernel when using framebuffer in U-Boot. We're using a patch in kernel for workaround it but it seems your fix does what is need. I have just tested Eric's series on a mx53loco and it does fix the kernel hang issue. I made some comments on this series and hopefully Eric's v2 can get into 2012.10, since this is a bug fix. Ok, I am waiting for V2 and I will push it. I'll forward this later today. Ok Anyway, a question about the issue. It seems to me that it is not possible with IPUV3 (I have not tested myself, so my question) to get the u-boot splashscreen displayed on the LCD until the kernel has finished to boot. This could be possible (and it is possible on other SOC) if the IPU is loaded as module instead of statically linked to the kernel, and if the kernel does not touch the IPU setup. This means also that it should not disable the clocks used by U-Boot for the IPU. I'm not sure I understand. The splash screen comes up as soon as the call to ipuv3_fb_init() is made (in board_video_skip() in my implementation for SABRE Lite). As it stands, if we leave the IPU running, we'll see garbage on the display as the kernel re-purposes the RAM used by U-Boot's frame buffer. Right, if the kernel reuse the same memory. I am aware that it is not implemented, I am asking if there some reason to make it impossible. Some customers want to have a picture shown on the LCD until their application is running. This makes sense, because the application can take a lot of time before displaying something on the LCD. If we reserve some memory for this scope, that is not used by the kernel later (passing the mem= parameter, for example, or using a .reserve entry in the board initialization code), we can reach the goal. In U-Boot we have a single display with 16bit, that means that the memory consumption is not very high. But I understand from your patch that this way is not possible on iMX53/MX6, and IPU must be always disabled. Is this correct ? Sascha responded to a note about this on AKML that the hand-over of a live FB isn't a supported kernel use case and it's definitely tricky. And I agree with him, the handover is tricky and not easy, I mean, it can work with a SOC (it remains tricky..) but not with another one. What I am saying is not this, but what happens if the IPU is not touched until the IPU modules are loaded. I don't know about the policy, but from a practical matter, the IPU frame buffer implementation in U-Boot isn't currently up to that task, since: it only supports a single display (i.MX6 can handle 4) it only supports 16bpp Additional functionality would be helpful here. Agree with you. And this is the reason I am not supposing that the kernel takes the IPU setup made by U-Boot. It could be a nightmare. I would like to see a handoff of display settings from U-Boot to the kernel, but that's also a tricky thing as long as we're supporting different mechanisms (DT in main-line and kernel parameters in older kernels). Yes, and a lot of other things. I know Anatolji implemented this behavior for a PPC5121, but we cannot generalize. I agree that the handoff is difficult and not maintainable. My question is different: if the IPU drivers in kernel are compiled as modules, and I will load them only after booting, and the framebuffer's memory is reserved so that the kernel does not touch it, is there still a known reason because the IPU should not run when we boot the kernel? I know this issue with USB, maybe we have now the same with the IPU. Note: this has nothing to do with this patch ;-). I will merge it into the current release when you push V2. Best regards, Stefano -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/2] add Eukrea's CPUIMX25
On 9/23/2012 5:33 PM, Eric Bénard wrote: this board is based on an i.MX25 from Freescale. It consists of a SOM containing : - NAND flash (internal or external boot supported and tested) - mDDR (64MB tested) - ethernet PHY connected in RMII mode (tested) and a baseboard containing : - a serial transceiver on UART1 (tested) - a SDCard connector on eSDHC1 (tested but disabled until Benoît's fix gets applied) bootlog : U-Boot 2012.10-rc1-3-gdd12be5 (Sep 23 2012 - 13:53:21) CPU: Freescale i.MX25 rev1.2 at 399 MHz Reset cause: POR DRAM: 64 MiB NAND: 256 MiB MMC: In:serial Out: serial Err: serial Net: FEC Hit any key to stop autoboot: 0 Signed-off-by: Eric Bénarde...@eukrea.com --- v2: rebased against 2012.10-rc1, disabled eSDHC until proper fix from Benoît gets applied, updated bootlog. MAINTAINERS |2 + board/eukrea/cpuimx25/Makefile| 44 +++ board/eukrea/cpuimx25/config.mk |5 + board/eukrea/cpuimx25/cpuimx25.c | 123 ++ board/eukrea/cpuimx25/imximage.cfg| 55 board/eukrea/cpuimx25/lowlevel_init.S | 113 boards.cfg|2 + include/configs/cpuimx25.h| 198 + nand_spl/board/eukrea/cpuimx25/Makefile | 79 nand_spl/board/eukrea/cpuimx25/config.mk |1 + nand_spl/board/eukrea/cpuimx25/u-boot.lds | 83 11 files changed, 705 insertions(+), 0 deletions(-) create mode 100644 board/eukrea/cpuimx25/Makefile create mode 100644 board/eukrea/cpuimx25/config.mk create mode 100644 board/eukrea/cpuimx25/cpuimx25.c create mode 100644 board/eukrea/cpuimx25/imximage.cfg create mode 100644 board/eukrea/cpuimx25/lowlevel_init.S create mode 100644 include/configs/cpuimx25.h create mode 100644 nand_spl/board/eukrea/cpuimx25/Makefile create mode 100644 nand_spl/board/eukrea/cpuimx25/config.mk create mode 100644 nand_spl/board/eukrea/cpuimx25/u-boot.lds diff --git a/MAINTAINERS b/MAINTAINERS index aa54fe1..94e759f 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -606,6 +606,8 @@ Eric Benarde...@eukrea.com cpuat91 ARM920T cpu9260 ARM926EJS (AT91SAM9260 SoC) cpu9G20 ARM926EJS (AT91SAM9G20 SoC) + cpuimx25i.MX25 + cpuimx25nandi.MX25 Ajay Bhargavajay.bhar...@einfochips.com diff --git a/board/eukrea/cpuimx25/Makefile b/board/eukrea/cpuimx25/Makefile new file mode 100644 index 000..46131fd --- /dev/null +++ b/board/eukrea/cpuimx25/Makefile @@ -0,0 +1,44 @@ +# +# (C) Copyright 2009 DENX Software Engineering +# Author: John Rigbyjcri...@gmail.com +# +# See file CREDITS for list of people who contributed to this +# project. +# +# This program is free software; you can redistribute it and/or +# modify it under the terms of the GNU General Public License as +# published by the Free Software Foundation; either version 2 of +# the License, or (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 59 Temple Place, Suite 330, Boston, +# MA 02111-1307 USA +# + +include $(TOPDIR)/config.mk + +LIB= $(obj)lib$(BOARD).o + +COBJS := cpuimx25.o +SOBJS := lowlevel_init.o + +SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c) +OBJS := $(addprefix $(obj),$(COBJS)) +SOBJS := $(addprefix $(obj),$(SOBJS)) + +$(LIB):$(obj).depend $(OBJS) $(SOBJS) + $(call cmd_link_o_target, $(OBJS) $(SOBJS)) + +# + +include $(SRCTREE)/rules.mk + +sinclude $(obj).depend + +# diff --git a/board/eukrea/cpuimx25/config.mk b/board/eukrea/cpuimx25/config.mk new file mode 100644 index 000..18b2883 --- /dev/null +++ b/board/eukrea/cpuimx25/config.mk @@ -0,0 +1,5 @@ +ifdef CONFIG_NAND_SPL +CONFIG_SYS_TEXT_BASE = 0x810c +else +CONFIG_SYS_TEXT_BASE = 0x8120 +endif diff --git a/board/eukrea/cpuimx25/cpuimx25.c b/board/eukrea/cpuimx25/cpuimx25.c new file mode 100644 index 000..72fa8a5 --- /dev/null +++ b/board/eukrea/cpuimx25/cpuimx25.c @@ -0,0 +1,123 @@ +/* + * (C) Copyright 2009 DENX Software Engineering + * (C) Copyright 2012 Eukrea Electromatiquewww.eukrea.com + * Eric Benarde...@eukrea.com + * + * Based on tx25.c: + * Author: John Rigbyjri...@gmail.com + * + * Based on imx27lite.c: + * Copyright (C) 2008,2009 Eric Jarrigejora...@users.sourceforge.net + * Copyright (C) 2009 Ilya Yanokya...@emcraft.com + * And: + * RedBoot tx25_misc.c Copyright (C) 2009
[U-Boot] [PATCH V2 2/2] i.MX: shut down video before launch of O/S
Signed-off-by: Eric Nelson eric.nel...@boundarydevices.com --- V2 moves arch_preboot_os() into imx-common/cpu.c instead of adding file imx-common/preboot.c arch/arm/imx-common/cpu.c |9 + 1 files changed, 9 insertions(+), 0 deletions(-) diff --git a/arch/arm/imx-common/cpu.c b/arch/arm/imx-common/cpu.c index fa1d468..a10d12d 100644 --- a/arch/arm/imx-common/cpu.c +++ b/arch/arm/imx-common/cpu.c @@ -30,6 +30,7 @@ #include asm/arch/clock.h #include asm/arch/sys_proto.h #include asm/arch/crm_regs.h +#include ipu_pixfmt.h #ifdef CONFIG_FSL_ESDHC #include fsl_esdhc.h @@ -138,3 +139,11 @@ u32 get_ahb_clk(void) return get_periph_clk() / (ahb_podf + 1); } + +#if defined(CONFIG_VIDEO_IPUV3) +void arch_preboot_os(void) +{ + /* disable video before launching O/S */ + ipuv3_fb_shutdown(); +} +#endif -- 1.7.9 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2 1/2] i.MX: mxc_ipuv3_fb: add ipuv3_fb_shutdown() routine to stop IPU frame buffer
Signed-off-by: Eric Nelson eric.nel...@boundarydevices.com Tested-by: Fabio Estevam fabio.este...@freescale.com --- V2 is unchanged from V1 drivers/video/mxc_ipuv3_fb.c | 20 include/ipu_pixfmt.h |1 + 2 files changed, 21 insertions(+), 0 deletions(-) diff --git a/drivers/video/mxc_ipuv3_fb.c b/drivers/video/mxc_ipuv3_fb.c index c38e22d..47b336e 100644 --- a/drivers/video/mxc_ipuv3_fb.c +++ b/drivers/video/mxc_ipuv3_fb.c @@ -38,6 +38,7 @@ #include videomodes.h #include ipu.h #include mxcfb.h +#include ipu_regs.h static int mxcfb_map_video_memory(struct fb_info *fbi); static int mxcfb_unmap_video_memory(struct fb_info *fbi); @@ -576,6 +577,25 @@ err0: return ret; } +void ipuv3_fb_shutdown(void) +{ + int i; + struct ipu_stat *stat = (struct ipu_stat *)IPU_STAT; + + for (i = 0; i ARRAY_SIZE(mxcfb_info); i++) { + struct fb_info *fbi = mxcfb_info[i]; + if (fbi) { + struct mxcfb_info *mxc_fbi = fbi-par; + ipu_disable_channel(mxc_fbi-ipu_ch); + ipu_uninit_channel(mxc_fbi-ipu_ch); + } + } + for (i = 0; i ARRAY_SIZE(stat-int_stat); i++) { + __raw_writel(__raw_readl(stat-int_stat[i]), +stat-int_stat[i]); + } +} + void *video_hw_init(void) { int ret; diff --git a/include/ipu_pixfmt.h b/include/ipu_pixfmt.h index 0019898..4baa711 100644 --- a/include/ipu_pixfmt.h +++ b/include/ipu_pixfmt.h @@ -77,5 +77,6 @@ #define IPU_PIX_FMT_YUV422P fourcc('4', '2', '2', 'P') /* 16 YUV 4:2:2 */ int ipuv3_fb_init(struct fb_videomode *mode, uint8_t disp, uint32_t pixfmt); +void ipuv3_fb_shutdown(void); #endif -- 1.7.9 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2 0/2] i.MX: ipufb: shut down IPU frame buffer before booting
V2 moves arch_preboot_os() into arch/arm/imx-common/cpu.c ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] FAT: split block device interactions from filesystem logic
Hi Pavel, On Sunday, September 23, 2012 5:28:31 PM, Pavel Herrmann wrote: add some CCs On Wednesday 19 September 2012 16:34:02 Pavel Herrmann wrote: Put block device interaction code into separate file from filesystem logic. This makes it easier to change block device API, and is similar to what other filesystems do. Cleanup some logic inconsistencies as well. Sounds good. See my comments below. This might need some light rework to make it applicable after http://patchwork.ozlabs.org/patch/184793/, which should be applied soon. Signed-off-by: Pavel Herrmann morpheus.i...@gmail.com --- fs/fat/Makefile| 4 +- fs/fat/dev.c | 191 + fs/fat/fat.c | 175 ++-- fs/fat/fat_write.c | 21 +++--- include/fat.h | 7 ++ 5 files changed, 228 insertions(+), 170 deletions(-) create mode 100644 fs/fat/dev.c diff --git a/fs/fat/Makefile b/fs/fat/Makefile index 9635d36..5d10b24 100644 --- a/fs/fat/Makefile +++ b/fs/fat/Makefile @@ -24,8 +24,8 @@ include $(TOPDIR)/config.mk LIB= $(obj)libfat.o AOBJS = -COBJS-$(CONFIG_CMD_FAT):= fat.o -COBJS-$(CONFIG_FAT_WRITE):= fat_write.o +COBJS-$(CONFIG_CMD_FAT):= fat.o dev.o +COBJS-$(CONFIG_FAT_WRITE) := fat_write.o dev.o ifndef CONFIG_SPL_BUILD COBJS-$(CONFIG_CMD_FAT)+= file.o diff --git a/fs/fat/dev.c b/fs/fat/dev.c new file mode 100644 index 000..d5ff0c5 --- /dev/null +++ b/fs/fat/dev.c @@ -0,0 +1,191 @@ +/* + * (C) Copyright 2012 + * Pavel Herrmann morpheus.i...@gmail.com Since 99% of the code here comes from fat.c and fat_write.c, the copyright information from these files should probably be added here too. + * + * See file CREDITS for list of people who contributed to this + * project. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; either version 2 of + * the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, + * MA 02111-1307 USA + */ + +#include common.h +#include fat.h +#include part.h +#include errno.h + +#define DOS_BOOT_MAGIC_OFFSET 0x1fe +#define DOS_FS_TYPE_OFFSET 0x36 +#define DOS_FS32_TYPE_OFFSET0x52 + +static block_dev_desc_t *cur_dev; +static unsigned int cur_part_nr; +static disk_partition_t cur_part_info; + +int fat_disk_read(__u32 block, __u32 nr_blocks, void *buf) +{ + if (!cur_dev || !cur_dev-block_read) + return -1; + + return cur_dev-block_read(cur_dev-dev, + cur_part_info.start + block, nr_blocks, buf); +} + +int fat_disk_write(__u32 block, __u32 nr_blocks, void *buf) +{ + if (!cur_dev || !cur_dev-block_read) + return -1; + + return cur_dev-block_read(cur_dev-dev, + cur_part_info.start + block, nr_blocks, buf); +} block_write... Please, split this patch into: - moved code + renaming, - behavior changes (one patch per behavior change). That will make things clearer and easier to review. + +int fat_get_blksz(void) cur_dev-blksz is ulong, so long might be better here, even if it does not seem strictly necessary. +{ + if (cur_dev == NULL) + return -EINVAL; + return cur_dev-blksz; Or cur_part_info.blksize? Your calls to this function replace both usages, so please make sure that this won't cause any trouble. +} + +int fat_get_partsize(void) long? +{ + if (cur_dev == NULL) + return -EINVAL; This test looks unrelated to the line below and changes the behavior where this function is called. Please clarify. + return cur_part_info.size; +} + +int fat_register_device(block_dev_desc_t *dev_desc, int part_no) +{ + ALLOC_CACHE_ALIGN_BUFFER(unsigned char, buffer, dev_desc-blksz); + + /* First close any currently found FAT filesystem */ + cur_dev = NULL; + +#if (defined(CONFIG_CMD_IDE) || \ + defined(CONFIG_CMD_SATA) || \ + defined(CONFIG_CMD_SCSI) || \ + defined(CONFIG_CMD_USB) || \ + defined(CONFIG_MMC) || \ + defined(CONFIG_SYSTEMACE)) + + /* Read the partition table, if present */ + if (!get_partition_info(dev_desc, part_no, cur_part_info)) { + cur_dev = dev_desc; + cur_part_nr = part_no; + } +#endif + + /* Otherwise it might be a
Re: [U-Boot] [PATCH v2 2/2] add Eukrea's CPUIMX25
On 23/09/2012 14:03, Eric Bénard wrote: this board is based on an i.MX25 from Freescale. It consists of a SOM containing : - NAND flash (internal or external boot supported and tested) - mDDR (64MB tested) - ethernet PHY connected in RMII mode (tested) and a baseboard containing : - a serial transceiver on UART1 (tested) - a SDCard connector on eSDHC1 (tested but disabled until Benoît's fix gets applied) Hi Eric, bootlog : U-Boot 2012.10-rc1-3-gdd12be5 (Sep 23 2012 - 13:53:21) CPU: Freescale i.MX25 rev1.2 at 399 MHz Reset cause: POR DRAM: 64 MiB NAND: 256 MiB MMC: In:serial Out: serial Err: serial Net: FEC Hit any key to stop autoboot: 0 Signed-off-by: Eric Bénard e...@eukrea.com --- v2: rebased against 2012.10-rc1, disabled eSDHC until proper fix from Benoît gets applied, updated bootlog. MAINTAINERS |2 + board/eukrea/cpuimx25/Makefile| 44 +++ board/eukrea/cpuimx25/config.mk |5 + board/eukrea/cpuimx25/cpuimx25.c | 123 ++ board/eukrea/cpuimx25/imximage.cfg| 55 board/eukrea/cpuimx25/lowlevel_init.S | 113 boards.cfg|2 + include/configs/cpuimx25.h| 198 + nand_spl/board/eukrea/cpuimx25/Makefile | 79 nand_spl/board/eukrea/cpuimx25/config.mk |1 + nand_spl/board/eukrea/cpuimx25/u-boot.lds | 83 There is a main issue with these patches. According to some discussion in previous threads and hopefully I do not misinterprete Wolfgang's will about the direction that U-Boot will have in future, the nand_spl code is obsolete and it remains for the already supported boards. However, new boards must implement SPL using the SPL framework. New boards using nand_spl will not be integrated in mainline. +# diff --git a/board/eukrea/cpuimx25/config.mk b/board/eukrea/cpuimx25/config.mk new file mode 100644 index 000..18b2883 --- /dev/null +++ b/board/eukrea/cpuimx25/config.mk @@ -0,0 +1,5 @@ +ifdef CONFIG_NAND_SPL +CONFIG_SYS_TEXT_BASE = 0x810c +else +CONFIG_SYS_TEXT_BASE = 0x8120 +endif config.mk is obsolete in board's directory. We removed most of these config.mk. It must not be used anymore. +int board_init() +{ +#ifdef CONFIG_MXC_UART Maybe you can drop the #ifdef, CONFIG_MXC_UART should always be set +#ifdef CONFIG_FSL_ESDHC +int board_mmc_getcd(struct mmc *mmc) +{ + struct iomuxc_mux_ctl *muxctl; + struct iomuxc_pad_ctl *padctl; + struct gpio_regs *gpio2 = (struct gpio_regs *)IMX_GPIO2_BASE; + u32 val; + + muxctl = (struct iomuxc_mux_ctl *)IMX_IOPADMUX_BASE; + padctl = (struct iomuxc_pad_ctl *)IMX_IOPADCTL_BASE; + + writel(MX25_PIN_MUX_MODE(5), muxctl-pad_de_b); Why is the setup of the iomux here and not in board_mmc_init ? diff --git a/board/eukrea/cpuimx25/lowlevel_init.S b/board/eukrea/cpuimx25/lowlevel_init.S new file mode 100644 index 000..76e4e6f --- /dev/null +++ b/board/eukrea/cpuimx25/lowlevel_init.S @@ -0,0 +1,113 @@ +/* + * (C) Copyright 2009 DENX Software Engineering + * (C) Copyright 2012 Eukrea Electromatique www.eukrea.com + * Eric Benard e...@eukrea.com + * + * Based on tx25 and zmx25: + * Author: John Rigby jri...@gmail.com + * + * Based on U-Boot and RedBoot sources for several different i.mx + * platforms. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; either version 2 of + * the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, + * MA 02111-1307 USA + */ + +#include asm/macro.h +#include asm/arch/macro.h +#include asm/arch/imx-regs.h +#include generated/asm-offsets.h + +.macro init_m3if + write32 0xb8003000, 0x1 +.endm + +.macro init_clocks + write32 0x53f80064, 0x + write32 0x53f80008, 0x20034000 + + /* + * enable all implemented clocks in all three + * clock control registers + */ + write32 0x53f8000c, 0x1fff + write32 0x53f80010, 0x + write32 0x53f80014, 0xfdfff +.endm + +.macro init_lpddr + /* Skip SDRAM initialization if we run from RAM */ + cmp pc, #0x8000 + bls 1f + cmp pc, #0x9000 +
Re: [U-Boot] [PATCH] mx6qsabresd: Add Ethernet support
On 19/09/2012 05:24, Fabio Estevam wrote: From: Fabio Estevam fabio.este...@freescale.com mx6qsabresd has a AR8031 Gigabit PHY. Add support for it. Also increase CONFIG_SYS_MALLOC_LEN so that FEC buffer allocation does not fail. Tested on 1Gbp and 100Mbps networks. Suggested-by: Kim Phillips kim.phill...@freescale.com Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- Applied to u-boot-imx, next branch. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx6qsabresd: Add 8-bit USDHC support
On 18/09/2012 21:27, Fabio Estevam wrote: USDHC3 has 8 pins wired in mx6qsabresd. Configure the extra pins. Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- Applied to u-boot-imx, next branch, thanks. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] mx51evk: Add CONFIG_REVISION_TAG
On 18/09/2012 16:48, Benoît Thébaudeau wrote: FSL 2.6.35 kernel assumes that the bootloader passes the CONFIG_REVISION_TAG information. If this data is not present, the kernel misconfigures the TZIC, which results in the timer interrupt handler never being called, so the kernel deadlocks while calibrating its delay. Suggested-by: Greg Topmiller greg.topmil...@jdsu.com Signed-off-by: Benoît Thébaudeau benoit.thebaud...@advansee.com Cc: Stefano Babic sba...@denx.de Cc: Fabio Estevam feste...@gmail.com --- Applied to u-boot-imx (fix), thanks. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] KARO TX25: Fix NAND Flash R/W cycle times
On 08/08/2012 15:55, Benoît Thébaudeau wrote: The NAND Flash of the KARO TX25 board is a Samsung K9F1G08U0B with 25-ns R/W cycle times. However, the NFC clock for this board was set to 66.5 MHz, so using the NFC driver in symmetric mode (i.e. 1 NFC clock cycle = 1 NF R/W cycle) resulted in NF R/W cycle times of 15 ns, hence corrupted NF accesses. This patch fixes this issue by setting the NFC clock to the highest frequency complying to the 25-ns NF R/W cycle times specification, i.e. 33.25 MHz. Applied to u-boot-imx(fix), thanks. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] mx25: add CPU revision 1.2
Hi, Le Sun, 23 Sep 2012 14:02:17 +0200, Eric Bénard e...@eukrea.com a écrit : tested on a MCIMX257CJM4A which now reports : CPU: Freescale i.MX25 rev1.2 at 399 MHz Signed-off-by: Eric Bénard e...@eukrea.com Acked-by: Otavio Salvador ota...@ossystems.com.br --- v2 : rebased against 2012.10-rc1, added Otavio's ack sorry for the noise, this one was missing the v2 in the subject and I git Ctrl-C to late :-( Eric ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Displays on i.MX (was Re: [PATCH 1/2])
Hi Stefano, I changed the subject line because we've veered off-topic. On 09/23/2012 10:27 AM, Stefano Babic wrote: On 23/09/2012 18:46, Eric Nelson wrote: Hi Stefano, On 09/23/2012 08:56 AM, Stefano Babic wrote: On 22/09/2012 16:37, Fabio Estevam wrote: On Sat, Sep 22, 2012 at 10:42 AM, Otavio Salvador ota...@ossystems.com.br wrote: Hello Eric, On Fri, Sep 21, 2012 at 5:36 PM, Eric Nelson eric.nel...@boundarydevices.com wrote: Signed-off-by: Eric Nelsoneric.nel...@boundarydevices.com Did you test it in mx5 too? We seem to need to handle it in mx5 too as we had hungs in FSL kernel when using framebuffer in U-Boot. We're using a patch in kernel for workaround it but it seems your fix does what is need. I have just tested Eric's series on a mx53loco and it does fix the kernel hang issue. I made some comments on this series and hopefully Eric's v2 can get into 2012.10, since this is a bug fix. Ok, I am waiting for V2 and I will push it. I'll forward this later today. Ok Anyway, a question about the issue. It seems to me that it is not possible with IPUV3 (I have not tested myself, so my question) to get the u-boot splashscreen displayed on the LCD until the kernel has finished to boot. This could be possible (and it is possible on other SOC) if the IPU is loaded as module instead of statically linked to the kernel, and if the kernel does not touch the IPU setup. This means also that it should not disable the clocks used by U-Boot for the IPU. I'm not sure I understand. The splash screen comes up as soon as the call to ipuv3_fb_init() is made (in board_video_skip() in my implementation for SABRE Lite). As it stands, if we leave the IPU running, we'll see garbage on the display as the kernel re-purposes the RAM used by U-Boot's frame buffer. Right, if the kernel reuse the same memory. I am aware that it is not implemented, I am asking if there some reason to make it impossible. Some customers want to have a picture shown on the LCD until their application is running. This makes sense, because the application can take a lot of time before displaying something on the LCD. If we reserve some memory for this scope, that is not used by the kernel later (passing the mem= parameter, for example, or using a .reserve entry in the board initialization code), we can reach the goal. In U-Boot we have a single display with 16bit, that means that the memory consumption is not very high. But I understand from your patch that this way is not possible on iMX53/MX6, and IPU must be always disabled. Is this correct ? Sascha responded to a note about this on AKML that the hand-over of a live FB isn't a supported kernel use case and it's definitely tricky. And I agree with him, the handover is tricky and not easy, I mean, it can work with a SOC (it remains tricky..) but not with another one. What I am saying is not this, but what happens if the IPU is not touched until the IPU modules are loaded. I don't know about the policy, but from a practical matter, the IPU frame buffer implementation in U-Boot isn't currently up to that task, since: it only supports a single display (i.MX6 can handle 4) it only supports 16bpp Additional functionality would be helpful here. Agree with you. And this is the reason I am not supposing that the kernel takes the IPU setup made by U-Boot. It could be a nightmare. I would like to see a handoff of display settings from U-Boot to the kernel, but that's also a tricky thing as long as we're supporting different mechanisms (DT in main-line and kernel parameters in older kernels). Yes, and a lot of other things. I know Anatolji implemented this behavior for a PPC5121, but we cannot generalize. I agree that the handoff is difficult and not maintainable. My question is different: if the IPU drivers in kernel are compiled as modules, and I will load them only after booting, and the framebuffer's memory is reserved so that the kernel does not touch it, is there still a known reason because the IPU should not run when we boot the kernel? I know this issue with USB, maybe we have now the same with the IPU. i Note: this has nothing to do with this patch ;-). I will merge it into the current release when you push V2. I agree with all of your goals but have a more mundane set for U-Boot and i.MX6: -- HDMI support -- Better strategy for storing display setup. The implementation of a compiled-in list of supported displays doesn't scale. -- Hand-off of display setup to DT-enabled kernel (Sascha's drivers) -- Multiple displays -- Hand-off of display setup to older kernels My thought is to take things in more or less this order, although a couple of things can make the last one trivial to do in a boot script and it's a pain point for me. (My blog post on setting up bootargs doesn't seem to be doing the trick) My thinking is that: HDMI support can and should support EDID and flexible choice of resolution, and We'll need
Re: [U-Boot] [PATCH v2 2/6] pxa25x: Add support for USB ethernet gadget
On 23.09.2012 17:44, Marek Vasut wrote: Dear Lukasz Dalek, Add to pxa25x based devices support for USB ethernet gadget. This is a port of pxa25x UDC driver from Linux kernel. Signed-off-by: Lukasz Dalekluk0...@gmail.com --- drivers/usb/gadget/Makefile |1 + drivers/usb/gadget/pxa25x_udc.c | 2059 +++ drivers/usb/gadget/pxa25x_udc.h | 162 +++ 3 files changed, insertions(+), 0 deletions(-) create mode 100644 drivers/usb/gadget/pxa25x_udc.c create mode 100644 drivers/usb/gadget/pxa25x_udc.h [...] So what's the change here? Or is it a repost? Best regards, Marek Vasut Everything was fine except DEBUG_NOISY defintions. I fixed them and I have resend patch. Can I ask what about patches 3,4,5,6? Łukasz Dałek ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] i.MX: mxc_ipuv3_fb: add ipuv3_fb_shutdown() routine to stop IPU before bootm
On Sun, Sep 23, 2012 at 07:27:41PM +0200, Stefano Babic wrote: I would like to see a handoff of display settings from U-Boot to the kernel, but that's also a tricky thing as long as we're supporting different mechanisms (DT in main-line and kernel parameters in older kernels). Yes, and a lot of other things. I know Anatolji implemented this behavior for a PPC5121, but we cannot generalize. I agree that the handoff is difficult and not maintainable. My question is different: if the IPU drivers in kernel are compiled as modules, and I will load them only after booting, and the framebuffer's memory is reserved so that the kernel does not touch it, is there still a known reason because the IPU should not run when we boot the kernel? I know this issue with USB, maybe we have now the same with the IPU. The clock framework disables all unused clocks in a late_initcall. when the IPU is compiled as a module, the IPU clock will be one of those. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/6] pxa25x: Add support for USB ethernet gadget
Dear Łukasz Dałek, On 23.09.2012 17:44, Marek Vasut wrote: Dear Lukasz Dalek, Add to pxa25x based devices support for USB ethernet gadget. This is a port of pxa25x UDC driver from Linux kernel. Signed-off-by: Lukasz Dalekluk0...@gmail.com --- drivers/usb/gadget/Makefile |1 + drivers/usb/gadget/pxa25x_udc.c | 2059 +++ drivers/usb/gadget/pxa25x_udc.h | 162 +++ 3 files changed, insertions(+), 0 deletions(-) create mode 100644 drivers/usb/gadget/pxa25x_udc.c create mode 100644 drivers/usb/gadget/pxa25x_udc.h [...] So what's the change here? Or is it a repost? Best regards, Marek Vasut Everything was fine except DEBUG_NOISY defintions. I fixed them and I have resend patch. http://www.denx.de/wiki/U-Boot/Patches did you read this? Worth reading so I don't have to repeat myself ;-) Can I ask what about patches 3,4,5,6? I think they're fine ... did you do any changes to them ? Łukasz Dałek 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 1/4] COMMON: Add __stringify() function
Dear Albert ARIBAUD, Hi Marek, On Sun, 23 Sep 2012 17:41:22 +0200, Marek Vasut ma...@denx.de wrote: Copied from Linux kernel: commit 8f7c2c37319a81ef4c2bfdec67b1ccd5744d97e4 Date: Wed Apr 8 16:58:57 2009 +0800 This function converts static number to string in preprocessor. This is useful as it allows higher usage of puts() in favour of printf() Fix commit message: this fonction is not limited to numbers. WFM, can you review the series please ? Signed-off-by: Marek Vasut ma...@denx.de Cc: Wolfgang Denk w...@denx.de --- include/common.h |1 + include/linux/stringify.h | 12 2 files changed, 13 insertions(+), 0 deletions(-) create mode 100644 include/linux/stringify.h diff --git a/include/common.h b/include/common.h index 55025c0..9937a57 100644 --- a/include/common.h +++ b/include/common.h @@ -39,6 +39,7 @@ typedef volatile unsigned charvu_char; #include linux/bitops.h #include linux/types.h #include linux/string.h +#include linux/stringify.h #include asm/ptrace.h #include stdarg.h #if defined(CONFIG_PCI) (defined(CONFIG_4xx) !defined(CONFIG_AP1000)) diff --git a/include/linux/stringify.h b/include/linux/stringify.h new file mode 100644 index 000..841cec8 --- /dev/null +++ b/include/linux/stringify.h @@ -0,0 +1,12 @@ +#ifndef __LINUX_STRINGIFY_H +#define __LINUX_STRINGIFY_H + +/* Indirect stringification. Doing two levels allows the parameter to be a + * macro itself. For example, compile with -DFOO=bar, __stringify(FOO) + * converts to bar. + */ + +#define __stringify_1(x...)#x +#define __stringify(x...) __stringify_1(x) + +#endif /* !__LINUX_STRINGIFY_H */ Amicalement, 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 v2 2/6] pxa25x: Add support for USB ethernet gadget
On 23.09.2012 20:24, Marek Vasut wrote: Dear Łukasz Dałek, On 23.09.2012 17:44, Marek Vasut wrote: Dear Lukasz Dalek, Add to pxa25x based devices support for USB ethernet gadget. This is a port of pxa25x UDC driver from Linux kernel. Signed-off-by: Lukasz Dalekluk0...@gmail.com --- drivers/usb/gadget/Makefile |1 + drivers/usb/gadget/pxa25x_udc.c | 2059 +++ drivers/usb/gadget/pxa25x_udc.h | 162 +++ 3 files changed, insertions(+), 0 deletions(-) create mode 100644 drivers/usb/gadget/pxa25x_udc.c create mode 100644 drivers/usb/gadget/pxa25x_udc.h [...] So what's the change here? Or is it a repost? Best regards, Marek Vasut Everything was fine except DEBUG_NOISY defintions. I fixed them and I have resend patch. http://www.denx.de/wiki/U-Boot/Patches did you read this? Worth reading so I don't have to repeat myself ;-) Yes. Can I ask what about patches 3,4,5,6? I think they're fine ... did you do any changes to them ? If they are ok then my job is done :-) Łukasz Dałek ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/6] h2200: Add support for iPAQ h2200 palmtop
On 23.09.2012 17:43, Marek Vasut wrote: + gd-ram_size = CONFIG_SYS_SDRAM_SIZE; + return 0; +} diff --git a/board/h2200/h2200.h b/board/h2200/h2200.h new file mode 100644 Do you need this file at all? Can the udc_disconnect() not be put somewhere into usb.h ? Can I just move this declaration into h2200.c? Łukasz Dałek ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/2] add Eukrea's CPUIMX25
Hi Vikram, Le Sun, 23 Sep 2012 23:02:18 +0530, Vikram Narayanan vikram...@gmail.com a écrit : Why the clock init is in two places? imximage.cfg and this file. Am I missing something? imximage.cfg for internal boot, lowlevel_init.S for external boot. Eric ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [NEXT PATCH v1 4/7] MX35: Add soc_boot_mode and soc_boot_device to MX35
Hi Stefano, Le Thu, 6 Sep 2012 10:04:57 +0200, Stefano Babic sba...@denx.de a écrit : +#define RCSR_MEM_CTL_WEIM0 +#define RCSR_MEM_CTL_NAND1 +#define RCSR_MEM_CTL_SD 2 +#define RCSR_MEM_TYPE_NOR0 +#define RCSR_MEM_TYPE_ONENAND2 +#define RCSR_MEM_TYPE_SD 0 +#define RCSR_MEM_TYPE_I2C2 +#define RCSR_MEM_TYPE_SPI3 + +u32 spl_boot_device(void) +{ + puts(spl_boot_device\n); + struct ccm_regs *ccm = + (struct ccm_regs *)IMX_CCM_BASE; + +#if 1 + return BOOT_DEVICE_MMC1; +#endif thisseems not clean and seems caused by the fact that the define RCSR_MEM_CTL_SD should be 3 and not 2 so in your tests the function spl_boot_device was not detecting the right boot mode. Also IMHO this define should be named RCSR_MEM_CTL_EXPANSION as in the app note AN3996 at end of page 3 (there is a typo in the reference manual which seems to be a copy'n paste from i.MX25 as it doesn't take in acount the ATA HDD case) : http://cache.freescale.com/files/dsp/doc/app_note/AN3996.pdf + + u32 rcsr = readl(ccm-rcsr); + u32 mem_type, mem_ctl; + + /* In external mode, no boot device is returned */ + if ((rcsr 10) 0x03) + return BOOT_DEVICE_NONE; + + mem_ctl = (rcsr 25) 0x03; + mem_type = (rcsr 23) 0x03; + + switch (mem_ctl) { + case RCSR_MEM_CTL_WEIM: + switch (mem_type) { + case RCSR_MEM_TYPE_NOR: + return BOOT_DEVICE_NOR; + case RCSR_MEM_TYPE_ONENAND: + return BOOT_DEVICE_ONE_NAND; + default: + return BOOT_DEVICE_NONE; + } + case RCSR_MEM_CTL_NAND: + return BOOT_DEVICE_NAND; + case RCSR_MEM_CTL_SD: + switch (mem_type) { + case RCSR_MEM_TYPE_SD: + return BOOT_DEVICE_MMC1; + case RCSR_MEM_TYPE_I2C: + return BOOT_DEVICE_I2C; + case RCSR_MEM_TYPE_SPI: + return BOOT_DEVICE_SPI; + default: + return BOOT_DEVICE_NONE; + } + } + + return BOOT_DEVICE_NONE; +} + Eric ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/6] h2200: Add support for iPAQ h2200 palmtop
Dear Łukasz Dałek, On 23.09.2012 17:43, Marek Vasut wrote: + gd-ram_size = CONFIG_SYS_SDRAM_SIZE; + return 0; +} diff --git a/board/h2200/h2200.h b/board/h2200/h2200.h new file mode 100644 Do you need this file at all? Can the udc_disconnect() not be put somewhere into usb.h ? Can I just move this declaration into h2200.c? extern ... ? No, checkpatch will scream and extern is prohibited for a good reason. Łukasz Dałek 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 v2 2/6] pxa25x: Add support for USB ethernet gadget
Dear Łukasz Dałek, On 23.09.2012 20:24, Marek Vasut wrote: Dear Łukasz Dałek, On 23.09.2012 17:44, Marek Vasut wrote: Dear Lukasz Dalek, Add to pxa25x based devices support for USB ethernet gadget. This is a port of pxa25x UDC driver from Linux kernel. Signed-off-by: Lukasz Dalekluk0...@gmail.com --- drivers/usb/gadget/Makefile |1 + drivers/usb/gadget/pxa25x_udc.c | 2059 +++ drivers/usb/gadget/pxa25x_udc.h | 162 +++ | 3 files changed, insertions(+), 0 deletions(-) create mode 100644 drivers/usb/gadget/pxa25x_udc.c create mode 100644 drivers/usb/gadget/pxa25x_udc.h [...] So what's the change here? Or is it a repost? Best regards, Marek Vasut Everything was fine except DEBUG_NOISY defintions. I fixed them and I have resend patch. http://www.denx.de/wiki/U-Boot/Patches did you read this? Worth reading so I don't have to repeat myself ;-) Yes. Can I ask what about patches 3,4,5,6? I think they're fine ... did you do any changes to them ? If they are ok then my job is done :-) You did not answer my question ... and no, your job isn't done ... once your code is mainline, you're the maintainer, every change to common code will also be your responsibility to at least review/test on your hardware etc ... you know the drill. Even though PXA is semi-dead, so I don't expect much happening there. Łukasz Dałek 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 v2 1/6] h2200: Add support for iPAQ h2200 palmtop
On 23.09.2012 21:31, Marek Vasut wrote: Dear Łukasz Dałek, On 23.09.2012 17:43, Marek Vasut wrote: + gd-ram_size = CONFIG_SYS_SDRAM_SIZE; + return 0; +} diff --git a/board/h2200/h2200.h b/board/h2200/h2200.h new file mode 100644 Do you need this file at all? Can the udc_disconnect() not be put somewhere into usb.h ? Can I just move this declaration into h2200.c? extern ... ? No, checkpatch will scream and extern is prohibited for a good reason. So where should I put it? Łukasz Dałek ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/6] pxa25x: Add support for USB ethernet gadget
On 23.09.2012 21:32, Marek Vasut wrote: Dear Łukasz Dałek, On 23.09.2012 20:24, Marek Vasut wrote: Dear Łukasz Dałek, On 23.09.2012 17:44, Marek Vasut wrote: Dear Lukasz Dalek, Add to pxa25x based devices support for USB ethernet gadget. This is a port of pxa25x UDC driver from Linux kernel. Signed-off-by: Lukasz Dalekluk0...@gmail.com --- drivers/usb/gadget/Makefile |1 + drivers/usb/gadget/pxa25x_udc.c | 2059 +++ drivers/usb/gadget/pxa25x_udc.h | 162 +++ | 3 files changed, insertions(+), 0 deletions(-) create mode 100644 drivers/usb/gadget/pxa25x_udc.c create mode 100644 drivers/usb/gadget/pxa25x_udc.h [...] So what's the change here? Or is it a repost? Best regards, Marek Vasut Everything was fine except DEBUG_NOISY defintions. I fixed them and I have resend patch. http://www.denx.de/wiki/U-Boot/Patches did you read this? Worth reading so I don't have to repeat myself ;-) Yes. Can I ask what about patches 3,4,5,6? I think they're fine ... did you do any changes to them ? If they are ok then my job is done :-) You did not answer my question ... and no, your job isn't done ... once your code is mainline, you're the maintainer, every change to common code will also be your responsibility to at least review/test on your hardware etc ... you know the drill. Even though PXA is semi-dead, so I don't expect much happening there. No, since last email I didn't change anything. But for now you have said that they're fine, so all I have to wait. Am I wrong? Łukasz Dałek ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/6] h2200: Add support for iPAQ h2200 palmtop
Dear Łukasz Dałek, On 23.09.2012 21:31, Marek Vasut wrote: Dear Łukasz Dałek, On 23.09.2012 17:43, Marek Vasut wrote: +gd-ram_size = CONFIG_SYS_SDRAM_SIZE; +return 0; +} diff --git a/board/h2200/h2200.h b/board/h2200/h2200.h new file mode 100644 Do you need this file at all? Can the udc_disconnect() not be put somewhere into usb.h ? Can I just move this declaration into h2200.c? extern ... ? No, checkpatch will scream and extern is prohibited for a good reason. So where should I put it? Isn't it a general call? some include/usb.h ? Łukasz Dałek 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 v2 2/6] pxa25x: Add support for USB ethernet gadget
Dear Łukasz Dałek, On 23.09.2012 21:32, Marek Vasut wrote: Dear Łukasz Dałek, On 23.09.2012 20:24, Marek Vasut wrote: Dear Łukasz Dałek, On 23.09.2012 17:44, Marek Vasut wrote: Dear Lukasz Dalek, Add to pxa25x based devices support for USB ethernet gadget. This is a port of pxa25x UDC driver from Linux kernel. Signed-off-by: Lukasz Dalekluk0...@gmail.com --- drivers/usb/gadget/Makefile |1 + drivers/usb/gadget/pxa25x_udc.c | 2059 +++ drivers/usb/gadget/pxa25x_udc.h | 162 +++ | 3 files changed, insertions(+), 0 deletions(-) create mode 100644 drivers/usb/gadget/pxa25x_udc.c create mode 100644 drivers/usb/gadget/pxa25x_udc.h [...] So what's the change here? Or is it a repost? Best regards, Marek Vasut Everything was fine except DEBUG_NOISY defintions. I fixed them and I have resend patch. http://www.denx.de/wiki/U-Boot/Patches did you read this? Worth reading so I don't have to repeat myself ;-) Yes. Can I ask what about patches 3,4,5,6? I think they're fine ... did you do any changes to them ? If they are ok then my job is done :-) You did not answer my question ... and no, your job isn't done ... once your code is mainline, you're the maintainer, every change to common code will also be your responsibility to at least review/test on your hardware etc ... you know the drill. Even though PXA is semi-dead, so I don't expect much happening there. No, since last email I didn't change anything. But for now you have said that they're fine, so all I have to wait. Am I wrong? You're right. Łukasz Dałek Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Performance of the ARM's PL310 L2 cache.
Dear Tom Rini, On Fri, Aug 17, 2012 at 05:49:53PM +0200, Lukasz Majewski wrote: Hi Aneesh, I've enabled the L2 cache for Trats board. Please find results from performance tests. The test function as well as my way for enabling L2 are attached to this e-mail. [snip] Have you had similar results with OMAP? Do you do more configuration when enabling the L2 at OMAP? At least on some parts, it's similar here. The normal sequence of operations is loading a relatively small payload (kernel, maybe device tree) from storage and then booting it (which turns off L2 anyways). This is why I was willing to disable DCACHE as a USB workaround, the common use-case doesn't see a great deal of help from dcache being on. I saw some pretty significant perf. boost with L1, I was planning to check L2 on mx6q, but I'm not sure if it's worth it anymore. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] i2c_probe: update for use in scripting
Allow the use of an I2C address to test and return success if one or more devices is found. This allows device presence to alter the flow of a script. e.g. if i2c probe 0x04 ; then echo found Hannstar touch ; fi Signed-off-by: Eric Nelson eric.nel...@boundarydevices.com --- common/cmd_i2c.c | 20 1 files changed, 16 insertions(+), 4 deletions(-) diff --git a/common/cmd_i2c.c b/common/cmd_i2c.c index 795814d..b64b975 100644 --- a/common/cmd_i2c.c +++ b/common/cmd_i2c.c @@ -557,18 +557,28 @@ mod_i2c_mem(cmd_tbl_t *cmdtp, int incrflag, int flag, int argc, char * const arg /* * Syntax: - * i2c probe {addr}{.0, .1, .2} + * i2c probe {addr} + * + * Returns zero (success) if one or more I2C devices was found */ static int do_i2c_probe (cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) { int j; + int addr = -1; + int found = 0; #if defined(CONFIG_SYS_I2C_NOPROBES) int k, skip; uchar bus = GET_BUS_NUM; #endif /* NOPROBES */ + if (argc == 2) + addr = simple_strtol(argv[1], 0, 16); + puts (Valid chip addresses:); for (j = 0; j 128; j++) { + if ((0 = addr) (j != addr)) + continue; + #if defined(CONFIG_SYS_I2C_NOPROBES) skip = 0; for (k=0; k NUM_ELEMENTS_NOPROBE; k++) { @@ -580,8 +590,10 @@ static int do_i2c_probe (cmd_tbl_t *cmdtp, int flag, int argc, char * const argv if (skip) continue; #endif - if (i2c_probe(j) == 0) + if (i2c_probe(j) == 0) { printf( %02X, j); + found++; + } } putc ('\n'); @@ -594,7 +606,7 @@ static int do_i2c_probe (cmd_tbl_t *cmdtp, int flag, int argc, char * const argv putc ('\n'); #endif - return 0; + return (0 == found); } /* @@ -1331,7 +1343,7 @@ U_BOOT_CMD( i2c mm chip address[.0, .1, .2] - write to I2C device (auto-incrementing)\n i2c mw chip address[.0, .1, .2] value [count] - write to I2C device (fill)\n i2c nm chip address[.0, .1, .2] - write to I2C device (constant address)\n - i2c probe - show devices on the I2C bus\n + i2c probe [address] - test for and show device(s) on the I2C bus\n i2c read chip address[.0, .1, .2] length memaddress - read to memory \n i2c reset - re-init the I2C Controller\n #if defined(CONFIG_CMD_SDRAM) -- 1.7.9 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/6] h2200: Add support for iPAQ h2200 palmtop
On 23.09.2012 22:05, Marek Vasut wrote: Dear Łukasz Dałek, On 23.09.2012 21:31, Marek Vasut wrote: Dear Łukasz Dałek, On 23.09.2012 17:43, Marek Vasut wrote: + gd-ram_size = CONFIG_SYS_SDRAM_SIZE; + return 0; +} diff --git a/board/h2200/h2200.h b/board/h2200/h2200.h new file mode 100644 Do you need this file at all? Can the udc_disconnect() not be put somewhere into usb.h ? Can I just move this declaration into h2200.c? extern ... ? No, checkpatch will scream and extern is prohibited for a good reason. So where should I put it? Isn't it a general call? some include/usb.h ? For old layer maybe it is. I'm not sure but include/usb.h is for device implementing usb host but pxa can only be device. Including usb.h generate error. I'm going to add sd card support and other functions, maybe leaving it would be better idea? Łukasz Dałek ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/2] add Eukrea's CPUIMX25
Hi Stefano, Le Sun, 23 Sep 2012 19:46:50 +0200, Stefano Babic sba...@denx.de a écrit : nand_spl/board/eukrea/cpuimx25/Makefile | 79 nand_spl/board/eukrea/cpuimx25/config.mk |1 + nand_spl/board/eukrea/cpuimx25/u-boot.lds | 83 There is a main issue with these patches. According to some discussion in previous threads and hopefully I do not misinterprete Wolfgang's will about the direction that U-Boot will have in future, the nand_spl code is obsolete and it remains for the already supported boards. However, new boards must implement SPL using the SPL framework. New boards using nand_spl will not be integrated in mainline. else that would have been to easy ;-) OK I'll look at this SPL framework based on your serie introducing woorburn board, Thanks ! Eric ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/6] h2200: Add support for iPAQ h2200 palmtop
Dear Łukasz Dałek, On 23.09.2012 22:05, Marek Vasut wrote: Dear Łukasz Dałek, On 23.09.2012 21:31, Marek Vasut wrote: Dear Łukasz Dałek, On 23.09.2012 17:43, Marek Vasut wrote: + gd-ram_size = CONFIG_SYS_SDRAM_SIZE; + return 0; +} diff --git a/board/h2200/h2200.h b/board/h2200/h2200.h new file mode 100644 Do you need this file at all? Can the udc_disconnect() not be put somewhere into usb.h ? Can I just move this declaration into h2200.c? extern ... ? No, checkpatch will scream and extern is prohibited for a good reason. So where should I put it? Isn't it a general call? some include/usb.h ? For old layer maybe it is. I'm not sure but include/usb.h is for device implementing usb host but pxa can only be device. PXA can be both, actually u-boot is mostly about host. Just put it there. Including usb.h generate error. I'm going to add sd card support and other functions, maybe leaving it would be better idea? Why do you think usb.h is not a good place ? Łukasz Dałek 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 v2 1/6] h2200: Add support for iPAQ h2200 palmtop
On 23.09.2012 22:52, Marek Vasut wrote: Dear Łukasz Dałek, On 23.09.2012 22:05, Marek Vasut wrote: Dear Łukasz Dałek, On 23.09.2012 21:31, Marek Vasut wrote: Dear Łukasz Dałek, On 23.09.2012 17:43, Marek Vasut wrote: + gd-ram_size = CONFIG_SYS_SDRAM_SIZE; + return 0; +} diff --git a/board/h2200/h2200.h b/board/h2200/h2200.h new file mode 100644 Do you need this file at all? Can the udc_disconnect() not be put somewhere into usb.h ? Can I just move this declaration into h2200.c? extern ... ? No, checkpatch will scream and extern is prohibited for a good reason. So where should I put it? Isn't it a general call? some include/usb.h ? For old layer maybe it is. I'm not sure but include/usb.h is for device implementing usb host but pxa can only be device. PXA can be both, actually u-boot is mostly about host. Just put it there. Including usb.h generate error. I'm going to add sd card support and other functions, maybe leaving it would be better idea? Why do you think usb.h is not a good place ? Because: #if defined(CONFIG_USB_UHCI) || defined(CONFIG_USB_OHCI) || \ defined(CONFIG_USB_EHCI) || defined(CONFIG_USB_OHCI_NEW) || \ defined(CONFIG_USB_SL811HS) || defined(CONFIG_USB_ISP116X_HCD) || \ defined(CONFIG_USB_R8A66597_HCD) || defined(CONFIG_USB_DAVINCI) || \ defined(CONFIG_USB_OMAP3) || defined(CONFIG_USB_DA8XX) || \ defined(CONFIG_USB_BLACKFIN) || defined(CONFIG_USB_AM35X) ... #else #error USB Lowlevel not defined #endif All of these definitions are usb host implementation (maybe OTG too) but pxa cannot be host. Łukasz Dałek ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/6] h2200: Add support for iPAQ h2200 palmtop
Dear Łukasz Dałek, On 23.09.2012 22:52, Marek Vasut wrote: Dear Łukasz Dałek, On 23.09.2012 22:05, Marek Vasut wrote: Dear Łukasz Dałek, On 23.09.2012 21:31, Marek Vasut wrote: Dear Łukasz Dałek, On 23.09.2012 17:43, Marek Vasut wrote: +gd-ram_size = CONFIG_SYS_SDRAM_SIZE; +return 0; +} diff --git a/board/h2200/h2200.h b/board/h2200/h2200.h new file mode 100644 Do you need this file at all? Can the udc_disconnect() not be put somewhere into usb.h ? Can I just move this declaration into h2200.c? extern ... ? No, checkpatch will scream and extern is prohibited for a good reason. So where should I put it? Isn't it a general call? some include/usb.h ? For old layer maybe it is. I'm not sure but include/usb.h is for device implementing usb host but pxa can only be device. PXA can be both, actually u-boot is mostly about host. Just put it there. Including usb.h generate error. I'm going to add sd card support and other functions, maybe leaving it would be better idea? Why do you think usb.h is not a good place ? Because: #if defined(CONFIG_USB_UHCI) || defined(CONFIG_USB_OHCI) || \ defined(CONFIG_USB_EHCI) || defined(CONFIG_USB_OHCI_NEW) || \ defined(CONFIG_USB_SL811HS) || defined(CONFIG_USB_ISP116X_HCD) || \ defined(CONFIG_USB_R8A66597_HCD) || defined(CONFIG_USB_DAVINCI) || \ defined(CONFIG_USB_OMAP3) || defined(CONFIG_USB_DA8XX) || \ defined(CONFIG_USB_BLACKFIN) || defined(CONFIG_USB_AM35X) ... #else #error USB Lowlevel not defined #endif All of these definitions are usb host implementation (maybe OTG too) but pxa cannot be host. PXA2xx is OHCI host with one OTG port. what about include/usb/pxa27x_udc.h ... btw can't pxa27x and pxa25x UDC use the same driver? Łukasz Dałek 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 v2 1/6] h2200: Add support for iPAQ h2200 palmtop
On 23.09.2012 23:04, Marek Vasut wrote: Dear Łukasz Dałek, On 23.09.2012 22:52, Marek Vasut wrote: Dear Łukasz Dałek, On 23.09.2012 22:05, Marek Vasut wrote: Dear Łukasz Dałek, On 23.09.2012 21:31, Marek Vasut wrote: Dear Łukasz Dałek, On 23.09.2012 17:43, Marek Vasut wrote: + gd-ram_size = CONFIG_SYS_SDRAM_SIZE; + return 0; +} diff --git a/board/h2200/h2200.h b/board/h2200/h2200.h new file mode 100644 Do you need this file at all? Can the udc_disconnect() not be put somewhere into usb.h ? Can I just move this declaration into h2200.c? extern ... ? No, checkpatch will scream and extern is prohibited for a good reason. So where should I put it? Isn't it a general call? some include/usb.h ? For old layer maybe it is. I'm not sure but include/usb.h is for device implementing usb host but pxa can only be device. PXA can be both, actually u-boot is mostly about host. Just put it there. Including usb.h generate error. I'm going to add sd card support and other functions, maybe leaving it would be better idea? Why do you think usb.h is not a good place ? Because: #if defined(CONFIG_USB_UHCI) || defined(CONFIG_USB_OHCI) || \ defined(CONFIG_USB_EHCI) || defined(CONFIG_USB_OHCI_NEW) || \ defined(CONFIG_USB_SL811HS) || defined(CONFIG_USB_ISP116X_HCD) || \ defined(CONFIG_USB_R8A66597_HCD) || defined(CONFIG_USB_DAVINCI) || \ defined(CONFIG_USB_OMAP3) || defined(CONFIG_USB_DA8XX) || \ defined(CONFIG_USB_BLACKFIN) || defined(CONFIG_USB_AM35X) ... #else #error USB Lowlevel not defined #endif All of these definitions are usb host implementation (maybe OTG too) but pxa cannot be host. PXA2xx is OHCI host with one OTG port. From pxa255 documentation: The UDC supports 16 endpoints and can operate half-duplex at a rate of 12 Mbps (as a slave only, not as a host or hub controller). what about include/usb/pxa27x_udc.h ... btw can't pxa27x and pxa25x UDC use the same driver? pxa27x_udc driver is using older layer which doesn't work with usb ethernet driver. Btw. pxa27x can be host, pxa25x can't. Łukasz Dałek ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/6] h2200: Add support for iPAQ h2200 palmtop
Dear Łukasz Dałek, On 23.09.2012 23:04, Marek Vasut wrote: Dear Łukasz Dałek, On 23.09.2012 22:52, Marek Vasut wrote: Dear Łukasz Dałek, On 23.09.2012 22:05, Marek Vasut wrote: Dear Łukasz Dałek, On 23.09.2012 21:31, Marek Vasut wrote: Dear Łukasz Dałek, On 23.09.2012 17:43, Marek Vasut wrote: + gd-ram_size = CONFIG_SYS_SDRAM_SIZE; + return 0; +} diff --git a/board/h2200/h2200.h b/board/h2200/h2200.h new file mode 100644 Do you need this file at all? Can the udc_disconnect() not be put somewhere into usb.h ? Can I just move this declaration into h2200.c? extern ... ? No, checkpatch will scream and extern is prohibited for a good reason. So where should I put it? Isn't it a general call? some include/usb.h ? For old layer maybe it is. I'm not sure but include/usb.h is for device implementing usb host but pxa can only be device. PXA can be both, actually u-boot is mostly about host. Just put it there. Including usb.h generate error. I'm going to add sd card support and other functions, maybe leaving it would be better idea? Why do you think usb.h is not a good place ? Because: #if defined(CONFIG_USB_UHCI) || defined(CONFIG_USB_OHCI) || \ defined(CONFIG_USB_EHCI) || defined(CONFIG_USB_OHCI_NEW) || \ defined(CONFIG_USB_SL811HS) || defined(CONFIG_USB_ISP116X_HCD) || \ defined(CONFIG_USB_R8A66597_HCD) || defined(CONFIG_USB_DAVINCI) || \ defined(CONFIG_USB_OMAP3) || defined(CONFIG_USB_DA8XX) || \ defined(CONFIG_USB_BLACKFIN) || defined(CONFIG_USB_AM35X) ... #else #error USB Lowlevel not defined #endif All of these definitions are usb host implementation (maybe OTG too) but pxa cannot be host. PXA2xx is OHCI host with one OTG port. From pxa255 documentation: The UDC supports 16 endpoints and can operate half-duplex at a rate of 12 Mbps (as a slave only, not as a host or hub controller). what about include/usb/pxa27x_udc.h ... btw can't pxa27x and pxa25x UDC use the same driver? pxa27x_udc driver is using older layer which doesn't work with usb ethernet driver. Btw. pxa27x can be host, pxa25x can't. Can you update the new gadget driver to be compatible with pxa27x then ? Łukasz Dałek 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 1/4] COMMON: Add __stringify() function
Hi Marek, On Sun, 23 Sep 2012 20:21:54 +0200, Marek Vasut ma...@denx.de wrote: Dear Albert ARIBAUD, Hi Marek, On Sun, 23 Sep 2012 17:41:22 +0200, Marek Vasut ma...@denx.de wrote: Copied from Linux kernel: commit 8f7c2c37319a81ef4c2bfdec67b1ccd5744d97e4 Date: Wed Apr 8 16:58:57 2009 +0800 This function converts static number to string in preprocessor. This is useful as it allows higher usage of puts() in favour of printf() Fix commit message: this fonction is not limited to numbers. WFM, can you review the series please ? Sorry, should have mentioned that apart from this, the series looks fine to me. FWIW: Acked-by: Albert ARIBAUD albert.u.b...@aribaud.net Signed-off-by: Marek Vasut ma...@denx.de Cc: Wolfgang Denk w...@denx.de --- include/common.h |1 + include/linux/stringify.h | 12 2 files changed, 13 insertions(+), 0 deletions(-) create mode 100644 include/linux/stringify.h diff --git a/include/common.h b/include/common.h index 55025c0..9937a57 100644 --- a/include/common.h +++ b/include/common.h @@ -39,6 +39,7 @@ typedef volatile unsigned char vu_char; #include linux/bitops.h #include linux/types.h #include linux/string.h +#include linux/stringify.h #include asm/ptrace.h #include stdarg.h #if defined(CONFIG_PCI) (defined(CONFIG_4xx) !defined(CONFIG_AP1000)) diff --git a/include/linux/stringify.h b/include/linux/stringify.h new file mode 100644 index 000..841cec8 --- /dev/null +++ b/include/linux/stringify.h @@ -0,0 +1,12 @@ +#ifndef __LINUX_STRINGIFY_H +#define __LINUX_STRINGIFY_H + +/* Indirect stringification. Doing two levels allows the parameter to be a + * macro itself. For example, compile with -DFOO=bar, __stringify(FOO) + * converts to bar. + */ + +#define __stringify_1(x...) #x +#define __stringify(x...)__stringify_1(x) + +#endif /* !__LINUX_STRINGIFY_H */ Amicalement, 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 v2 1/6] h2200: Add support for iPAQ h2200 palmtop
On 23.09.2012 23:31, Marek Vasut wrote: Dear Łukasz Dałek, On 23.09.2012 23:04, Marek Vasut wrote: PXA2xx is OHCI host with one OTG port. From pxa255 documentation: The UDC supports 16 endpoints and can operate half-duplex at a rate of 12 Mbps (as a slave only, not as a host or hub controller). what about include/usb/pxa27x_udc.h ... btw can't pxa27x and pxa25x UDC use the same driver? pxa27x_udc driver is using older layer which doesn't work with usb ethernet driver. Btw. pxa27x can be host, pxa25x can't. Can you update the new gadget driver to be compatible with pxa27x then ? I don't have any board with pxa27x processor. And I'm quite sure that differences between pxa25x and pxa27x usb are too big. Even in Linux kernel are two separate drivers for 25x and 27x chips. Łukasz Dałek ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] COMMON: Add __stringify() function
Dear Albert ARIBAUD, Hi Marek, On Sun, 23 Sep 2012 20:21:54 +0200, Marek Vasut ma...@denx.de wrote: Dear Albert ARIBAUD, Hi Marek, On Sun, 23 Sep 2012 17:41:22 +0200, Marek Vasut ma...@denx.de wrote: Copied from Linux kernel: commit 8f7c2c37319a81ef4c2bfdec67b1ccd5744d97e4 Date: Wed Apr 8 16:58:57 2009 +0800 This function converts static number to string in preprocessor. This is useful as it allows higher usage of puts() in favour of printf() Fix commit message: this fonction is not limited to numbers. WFM, can you review the series please ? Sorry, should have mentioned that apart from this, the series looks fine to me. FWIW: Acked-by: Albert ARIBAUD albert.u.b...@aribaud.net Ok, and it's now build-tested properly on arm and PPC. What would you expect in the commit message, lemme take a stab: Pull in the __stringify() macro from Linux kernel. This macro is usually used to convert numbers to strings at preprocessor level, yet it is not limited only to that. Seriously, I'm out of creative ideas here, please help :-( Signed-off-by: Marek Vasut ma...@denx.de Cc: Wolfgang Denk w...@denx.de --- include/common.h |1 + include/linux/stringify.h | 12 2 files changed, 13 insertions(+), 0 deletions(-) create mode 100644 include/linux/stringify.h diff --git a/include/common.h b/include/common.h index 55025c0..9937a57 100644 --- a/include/common.h +++ b/include/common.h @@ -39,6 +39,7 @@ typedef volatile unsigned charvu_char; #include linux/bitops.h #include linux/types.h #include linux/string.h +#include linux/stringify.h #include asm/ptrace.h #include stdarg.h #if defined(CONFIG_PCI) (defined(CONFIG_4xx) !defined(CONFIG_AP1000)) diff --git a/include/linux/stringify.h b/include/linux/stringify.h new file mode 100644 index 000..841cec8 --- /dev/null +++ b/include/linux/stringify.h @@ -0,0 +1,12 @@ +#ifndef __LINUX_STRINGIFY_H +#define __LINUX_STRINGIFY_H + +/* Indirect stringification. Doing two levels allows the parameter to be a + * macro itself. For example, compile with -DFOO=bar, __stringify(FOO) + * converts to bar. + */ + +#define __stringify_1(x...)#x +#define __stringify(x...) __stringify_1(x) + +#endif /* !__LINUX_STRINGIFY_H */ Amicalement, Best regards, Marek Vasut Amicalement, Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [NEXT PATCH v1 2/7] NAND: added NAND type to nand_ids
Hi Stefano, Le Mon, 10 Sep 2012 14:09:21 +0200, Stefano Babic sba...@denx.de a écrit : The chip supports ONFI, but it seems the i.MX driver does not. Quite as described in http://patchwork.ozlabs.org/patch/60042/. READ-ID is always sent with address 0, I do not know if we can convince the driver to send the address. to add ONFI support to i.MX's driver, you can check this patch (in barebox, a similar patch for Linux is cooking, actually tested on i.MX53 and i.MX25) : http://git.pengutronix.de/?p=barebox.git;a=commit;h=632c45795065e6a7471ab82be38e808eb6204341 Eric ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4] i.MX6: mx6qsabrelite: Add splash screen support
On 09/22/2012 10:19 AM, Eric Nelson wrote: On 09/22/2012 10:02 AM, Fabio Estevam wrote: Hi Eric, On Sat, Sep 22, 2012 at 1:51 PM, Eric Nelson eric.nel...@boundarydevices.com wrote: Interestingly, I saw U-Boot display on HDMI during my testing, so I'm pretty certain that all we need is the HDMI transmitter initialization sequence. Excellent, could you please share the HDMI transmitter init sequence? Hi Fabio, I haven't worked through the details, but I'm sure they're in here ;) https://github.com/boundarydevices/linux-imx6/blob/boundary-L3.0.35_MX6DQ_ER_1208-Beta/drivers/video/mxc_hdmi.c This may be easier than I thought (a set of writes to a single register). I did a little digging, and it seems that the power-on defaults for the HDMI transmitter work pretty well with my display (many thanks to the chip designers!). Without some more digging, I'm not very confident that the clocks are all getting set up properly, but the attached patch allows me to get 1080P video over HDMI. It also highlights some issues in the I2C detection structure (two parallel arrays that I hacked), but it gives me a lot more confidence that HDMI is achievable in the short term for at least one display. Regards, Eric diff --git a/board/freescale/mx6qsabrelite/mx6qsabrelite.c b/board/freescale/mx6qsabrelite/mx6qsabrelite.c index ed60c6d..d274bad 100644 --- a/board/freescale/mx6qsabrelite/mx6qsabrelite.c +++ b/board/freescale/mx6qsabrelite/mx6qsabrelite.c @@ -39,6 +39,7 @@ #include linux/fb.h #include ipu_pixfmt.h #include asm/arch/crm_regs.h +#include asm/arch/mxc_hdmi.h #include i2c.h DECLARE_GLOBAL_DATA_PTR; @@ -379,6 +380,20 @@ int setup_sata(void) #if defined(CONFIG_VIDEO_IPUV3) static struct fb_videomode videomodes[] = {{ + .name = HDMI, + .refresh= 60, + .xres = 1920, + .yres = 1080, + .pixclock = 7692, + .left_margin= 100, + .right_margin = 40, + .upper_margin = 30, + .lower_margin = 3, + .hsync_len = 10, + .vsync_len = 2, + .sync = FB_SYNC_EXT, /* a.k.a. LVDS or HDMI */ + .vmode = FB_VMODE_NONINTERLACED + }, { .name = Hannstar-XGA, .refresh= 60, .xres = 1024, @@ -427,22 +442,33 @@ static struct fb_videomode videomodes[] = {{ struct i2c_display { int bus; int addr; + int pixfmt; char const *name; }; +#define IS_HDMI(d) (0 (d).bus) + static struct i2c_display const i2c_displays[] = { { + .bus = -1, + .addr = -1, + .name = HDMI, + .pixfmt = IPU_PIX_FMT_RGB24, +}, { .bus = 2, .addr = 0x4, .name = Hannstar-XGA, + .pixfmt = IPU_PIX_FMT_LVDS666, }, { .bus = 2, .addr = 0x38, .name = wsvga-lvds, + .pixfmt = IPU_PIX_FMT_LVDS666, }, { .bus = 2, .addr = 0x48, .name = wvga-rgb, + .pixfmt = IPU_PIX_FMT_RGB666, } }; static iomux_v3_cfg_t rgb_pads[] = { @@ -495,12 +521,20 @@ int board_video_skip(void) if (!panel) { for (i = 0; i ARRAY_SIZE(i2c_displays); i++) { struct i2c_display const *dev = i2c_displays+i; - if ((0 == i2c_set_bus_num(dev-bus)) + if ((0 dev-bus) + + (0 == i2c_set_bus_num(dev-bus)) (0 == i2c_probe(dev-addr))) { panel = dev-name; printf(auto-detected panel %s\n, panel); break; + } else if (0 dev-bus) { +u8 reg = __raw_readb(HDMI_ARB_BASE_ADDR+HDMI_PHY_STAT0); +if (regHDMI_PHY_HPD) { + panel = dev-name; + printf(detected HDMI monitor\n); +} } } if (!panel) { @@ -513,9 +547,26 @@ int board_video_skip(void) break; } if (i ARRAY_SIZE(videomodes)) { - ret = ipuv3_fb_init(videomodes+i, 0, IPU_PIX_FMT_RGB666); + ret = ipuv3_fb_init(videomodes+i, 0, i2c_displays[i].pixfmt); if (!ret) { - if (IS_LVDS(videomodes[i])) + if IS_HDMI(i2c_displays[i]) { +u8 reg; +reg = __raw_readb( + HDMI_ARB_BASE_ADDR + +HDMI_PHY_CONF0); +reg |= HDMI_PHY_CONF0_PDZ_MASK; +__raw_writeb(reg, + HDMI_ARB_BASE_ADDR + +HDMI_PHY_CONF0); +reg |= HDMI_PHY_CONF0_ENTMDS_MASK; +__raw_writeb(reg, + HDMI_ARB_BASE_ADDR + +HDMI_PHY_CONF0); +reg |= HDMI_PHY_CONF0_GEN2_TXPWRON_MASK; +__raw_writeb(reg, + HDMI_ARB_BASE_ADDR + +HDMI_PHY_CONF0); + } else if (IS_LVDS(videomodes[i])) gpio_direction_output(LVDS_BACKLIGHT_GP, 1); else { imx_iomux_v3_setup_multiple_pads( ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] How to manage RMOBILE patches?
Hi, ping Best regards, Nobuhiro On Mon, Sep 10, 2012 at 9:41 AM, Nobuhiro Iwamatsu iwama...@nigauri.org wrote: Hi, On Sat, Sep 8, 2012 at 2:09 AM, Albert ARIBAUD albert.u.b...@aribaud.net wrote: Hi Tom, On Thu, 6 Sep 2012 13:58:57 -0700, Tom Rini tr...@ti.com wrote: On 09/06/2012 12:28 PM, Albert ARIBAUD wrote: Hi Nobuhiro, On Thu, 6 Sep 2012 08:20:59 +0900, Nobuhiro Iwamatsu iwama...@nigauri.org wrote: Hi, Tom. On Wed, Sep 5, 2012 at 11:17 PM, Tom Rini tr...@ti.com wrote: On 09/05/2012 04:18 AM, Albert ARIBAUD wrote: Hi Nobuhiro, On Wed, 5 Sep 2012 11:26:37 +0900, Nobuhiro Iwamatsu iwama...@nigauri.org wrote: Hi, On Wed, Sep 5, 2012 at 2:36 AM, Tom Rini tr...@ti.com wrote: On Mon, Sep 03, 2012 at 09:15:56PM +0200, Wolfgang Denk wrote: Dear Nobuhiro Iwamatsu, In message CABMQnVLBEEjcEtfTzdeThHfTLp=b24qsognfjbzr-8ywytj...@mail.gmail.com you wrote: I am working supporting Renesas RMOBILE to U-Boot. Renesas's RMOBILE SoC family contains an ARM Cortex-A9, and this uses the same IP as SH. (For example, timer, ether, serial, etc.) I already sent to patches of rmobile, I got review from some developers. And the patch is managed by the arm/rmobile branch of u-boot-sh[0] which I have maintained, now. Since I had you take the patch of rmobile into an ARM repository, I consulted with Albert about the future development approach. We thought two methods are considered. One is Albert picks up a patch from ML to ARM repository, As this is ARM code, this appears the most natural approach to me Another is whether to have pull from the repository by having a repository for rmobile made. If this is an ARM SoC, then it should go through the ARM repo - even if we should later decide that there is so much traffic that a separate rmobile repo would be sustified, thi would still be a sub-repo, which Albert would pull from. Another option, which Mike is using for, iirc, sf and blackfin, is just to add rmobile-master / rmobile-next as branches to the u-boot-sh repository. Yes, this is one of easy way. But Albert won't pull form u-boot-sh, if If my understanding is not wrong. This just means that they'll end up on u-boot/master from u-boot.sh (and from there into u-boot-arm later on). To be clear, what I'm saying is just add a few more branches to u-boot-sh that Albert will pull (since they're ARM stuff). Say u-boot-sh/rmobile/master and u-boot-sh/rmobile/next. Then not get too hung up on which repository a merge message comes from. :) I was going to do by how to explain you. However, I think that Albert mistook by my shortage of explanation. Thank you for following up. Nobuhiro I understand that some ARM patches would be stored in some branch (say rmobile/master) of the u-boot-sh repo and pull-requested to me from there. What I still don't understand is *why* this should be done. Before they get on this branch, the patches would still have to go through the mailing list for review, just like the ARM patches that end up applied to u-boot-arm/master, except they'd have to do through an intermediate branch. If there are benefits in this, someone will have to lay them out for me, because right now I don't see them. I think the answer is, given how you wish to work, there's not. It's a workflow problem only. If it's no easier for you to get a pull request from Nobuhiro once the patches have been reviewed than for you to pull them out of patchwork once they have been reviewed, then since your preference is for patchwork, via patchwork and into u-boot-arm is how they'll work. Thanks for this answer. I personally prefer applying patches from patchwork directly into u-boot-arm/master. OK, could you pickup rmobile patches from patchwork, please? But I already archived rmobile patches in patchwork.. Best regards, Nobuhiro -- Nobuhiro Iwamatsu iwamatsu at {nigauri.org / debian.org} GPG ID: 40AD1FA6 -- Nobuhiro Iwamatsu iwamatsu at {nigauri.org / debian.org} GPG ID: 40AD1FA6 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/3] i.MX6: implement hdmidet command
This series implements an HDMI detection command for i.MX6 boards and configures mx6qsabrelite to use it as discussed in this thread on the ML: http://lists.denx.de/pipermail/u-boot/2012-September/135037.html ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/3] i.MX6: Add hdmidet command to detect attached HDMI monitor
Signed-off-by: Eric Nelson eric.nel...@boundarydevices.com --- arch/arm/imx-common/Makefile |1 + arch/arm/imx-common/cmd_hdmidet.c | 37 + 2 files changed, 38 insertions(+), 0 deletions(-) create mode 100644 arch/arm/imx-common/cmd_hdmidet.c diff --git a/arch/arm/imx-common/Makefile b/arch/arm/imx-common/Makefile index 31dc52e..7c1e34c 100644 --- a/arch/arm/imx-common/Makefile +++ b/arch/arm/imx-common/Makefile @@ -33,6 +33,7 @@ COBJS-$(CONFIG_I2C_MXC) += i2c-mxv7.o endif COBJS-$(CONFIG_CMD_BMODE) += cmd_bmode.o COBJS-y += preboot_os.o +COBJS-$(CONFIG_CMD_HDMIDETECT) += cmd_hdmidet.o COBJS := $(sort $(COBJS-y)) SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c) diff --git a/arch/arm/imx-common/cmd_hdmidet.c b/arch/arm/imx-common/cmd_hdmidet.c new file mode 100644 index 000..ede5d88 --- /dev/null +++ b/arch/arm/imx-common/cmd_hdmidet.c @@ -0,0 +1,37 @@ +/* + * Copyright (C) 2012 Boundary Devices Inc. + * + * See file CREDITS for list of people who contributed to this + * project. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; either version 2 of + * the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, + * MA 02111-1307 USA + */ +#include common.h +#include asm/arch/imx-regs.h +#include asm/arch/mxc_hdmi.h +#include asm/io.h + +int do_hdmidet(cmd_tbl_t *cmdtp, int flag, int argc, char *argv[]) +{ + u8 reg = __raw_readb(HDMI_ARB_BASE_ADDR+HDMI_PHY_STAT0); + return (regHDMI_PHY_HPD) + ? 0 : 1; +} + +U_BOOT_CMD(hdmidet, 1, 1, do_hdmidet, + detect HDMI monitor, + +); -- 1.7.9 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/3] i.MX6: add HDMI transmitter register declarations from kernel WIP.
Original source from Pengutronix HDMI driver work: http://git.pengutronix.de/?p=imx/linux-2.6.git;a=commitdiff;h=72c31cd67ac880bd90785af86f8e46f8ea7b3bb0 Signed-off-by: Eric Nelson eric.nel...@boundarydevices.com --- arch/arm/include/asm/arch-mx6/mxc_hdmi.h | 1053 ++ 1 files changed, 1053 insertions(+), 0 deletions(-) create mode 100644 arch/arm/include/asm/arch-mx6/mxc_hdmi.h diff --git a/arch/arm/include/asm/arch-mx6/mxc_hdmi.h b/arch/arm/include/asm/arch-mx6/mxc_hdmi.h new file mode 100644 index 000..02a413f --- /dev/null +++ b/arch/arm/include/asm/arch-mx6/mxc_hdmi.h @@ -0,0 +1,1053 @@ +/* + * Copyright (C) 2011 Freescale Semiconductor, Inc. + */ + +/* + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License along + * with this program; if not, write to the Free Software Foundation, Inc., + * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. + */ + +#ifndef __MXC_HDMI_H__ +#define __MXC_HDMI_H__ + +/* + * Hdmi controller registers + */ + +/* Identification Registers */ +#define HDMI_DESIGN_ID 0x +#define HDMI_REVISION_ID0x0001 +#define HDMI_PRODUCT_ID00x0002 +#define HDMI_PRODUCT_ID10x0003 +#define HDMI_CONFIG0_ID 0x0004 +#define HDMI_CONFIG1_ID 0x0005 +#define HDMI_CONFIG2_ID 0x0006 +#define HDMI_CONFIG3_ID 0x0007 + +/* Interrupt Registers */ +#define HDMI_IH_FC_STAT00x0100 +#define HDMI_IH_FC_STAT10x0101 +#define HDMI_IH_FC_STAT20x0102 +#define HDMI_IH_AS_STAT00x0103 +#define HDMI_IH_PHY_STAT0 0x0104 +#define HDMI_IH_I2CM_STAT0 0x0105 +#define HDMI_IH_CEC_STAT0 0x0106 +#define HDMI_IH_VP_STAT00x0107 +#define HDMI_IH_I2CMPHY_STAT0 0x0108 +#define HDMI_IH_AHBDMAAUD_STAT0 0x0109 + +#define HDMI_IH_MUTE_FC_STAT0 0x0180 +#define HDMI_IH_MUTE_FC_STAT1 0x0181 +#define HDMI_IH_MUTE_FC_STAT2 0x0182 +#define HDMI_IH_MUTE_AS_STAT0 0x0183 +#define HDMI_IH_MUTE_PHY_STAT0 0x0184 +#define HDMI_IH_MUTE_I2CM_STAT0 0x0185 +#define HDMI_IH_MUTE_CEC_STAT0 0x0186 +#define HDMI_IH_MUTE_VP_STAT0 0x0187 +#define HDMI_IH_MUTE_I2CMPHY_STAT0 0x0188 +#define HDMI_IH_MUTE_AHBDMAAUD_STAT00x0189 +#define HDMI_IH_MUTE0x01FF + +/* Video Sample Registers */ +#define HDMI_TX_INVID0 0x0200 +#define HDMI_TX_INSTUFFING 0x0201 +#define HDMI_TX_GYDATA0 0x0202 +#define HDMI_TX_GYDATA1 0x0203 +#define HDMI_TX_RCRDATA00x0204 +#define HDMI_TX_RCRDATA10x0205 +#define HDMI_TX_BCBDATA00x0206 +#define HDMI_TX_BCBDATA10x0207 + +/* Video Packetizer Registers */ +#define HDMI_VP_STATUS 0x0800 +#define HDMI_VP_PR_CD 0x0801 +#define HDMI_VP_STUFF 0x0802 +#define HDMI_VP_REMAP 0x0803 +#define HDMI_VP_CONF0x0804 +#define HDMI_VP_STAT0x0805 +#define HDMI_VP_INT 0x0806 +#define HDMI_VP_MASK0x0807 +#define HDMI_VP_POL 0x0808 + +/* Frame Composer Registers */ +#define HDMI_FC_INVIDCONF 0x1000 +#define HDMI_FC_INHACTV00x1001 +#define HDMI_FC_INHACTV10x1002 +#define HDMI_FC_INHBLANK0 0x1003 +#define HDMI_FC_INHBLANK1 0x1004 +#define HDMI_FC_INVACTV00x1005 +#define HDMI_FC_INVACTV10x1006 +#define HDMI_FC_INVBLANK0x1007 +#define HDMI_FC_HSYNCINDELAY0 0x1008 +#define HDMI_FC_HSYNCINDELAY1 0x1009 +#define HDMI_FC_HSYNCINWIDTH0 0x100A +#define HDMI_FC_HSYNCINWIDTH1 0x100B +#define HDMI_FC_VSYNCINDELAY
[U-Boot] [PATCH 3/3] i.MX6: mx6qsabrelite: Include hdmidet command.
Signed-off-by: Eric Nelson eric.nel...@boundarydevices.com --- board/freescale/mx6qsabrelite/mx6qsabrelite.c |6 ++ include/configs/mx6qsabrelite.h |1 + 2 files changed, 7 insertions(+), 0 deletions(-) diff --git a/board/freescale/mx6qsabrelite/mx6qsabrelite.c b/board/freescale/mx6qsabrelite/mx6qsabrelite.c index d274d8c..ed60c6d 100644 --- a/board/freescale/mx6qsabrelite/mx6qsabrelite.c +++ b/board/freescale/mx6qsabrelite/mx6qsabrelite.c @@ -551,6 +551,12 @@ void lcd_iomux(void) |MXC_CCM_CCGR3_LDB_DI0_MASK; writel(reg, mxc_ccm-CCGR3); + /* Turn on HDMI PHY clock */ + reg = __raw_readl(mxc_ccm-CCGR2); + reg |= MXC_CCM_CCGR2_HDMI_TX_IAHBCLK_MASK + |MXC_CCM_CCGR2_HDMI_TX_ISFRCLK_MASK; + writel(reg, mxc_ccm-CCGR2); + /* set PFD1_FRAC to 0x13 == 455 MHz (480*18)/0x13 */ writel(ANATOP_PFD_480_PFD1_FRAC_MASK, anatop-pfd_480_clr); writel(0x13ANATOP_PFD_480_PFD1_FRAC_SHIFT, anatop-pfd_480_set); diff --git a/include/configs/mx6qsabrelite.h b/include/configs/mx6qsabrelite.h index 8601685..80707d0 100644 --- a/include/configs/mx6qsabrelite.h +++ b/include/configs/mx6qsabrelite.h @@ -144,6 +144,7 @@ #define CONFIG_BMP_16BPP #define CONFIG_VIDEO_LOGO #define CONFIG_IPUV3_CLK 26000 +#define CONFIG_CMD_HDMIDETECT /* allow to overwrite serial and ethaddr */ #define CONFIG_ENV_OVERWRITE -- 1.7.9 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/6] h2200: Add support for iPAQ h2200 palmtop
Dear Łukasz Dałek, On 23.09.2012 23:31, Marek Vasut wrote: Dear Łukasz Dałek, On 23.09.2012 23:04, Marek Vasut wrote: PXA2xx is OHCI host with one OTG port. From pxa255 documentation: The UDC supports 16 endpoints and can operate half-duplex at a rate of 12 Mbps (as a slave only, not as a host or hub controller). what about include/usb/pxa27x_udc.h ... btw can't pxa27x and pxa25x UDC use the same driver? pxa27x_udc driver is using older layer which doesn't work with usb ethernet driver. Btw. pxa27x can be host, pxa25x can't. Can you update the new gadget driver to be compatible with pxa27x then ? I don't have any board with pxa27x processor. And I'm quite sure that differences between pxa25x and pxa27x usb are too big. Even in Linux kernel are two separate drivers for 25x and 27x chips. Isn't the 25x only a subset of the 27x ? Łukasz Dałek 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 6/6] fdt: Add a Linux tool for reading values from FDT files
Dear Mike Frysinger, On Monday 20 August 2012 20:51:32 Joe Hershberger wrote: On Mon, Aug 20, 2012 at 7:24 PM, Mike Frysinger wrote: On Monday 20 August 2012 19:40:45 Joe Hershberger wrote: On Fri, Aug 17, 2012 at 6:35 PM, Mike Frysinger wrote: On Friday 17 August 2012 16:34:40 Joe Hershberger wrote: Designed to be able to access itb files on a filesystem or an mtd partition. Supports print and list (like the fdt command) and also offset for finding the offset and size of a given property in an FDT file. This is especially helpful when reading properties from an ITB file. doesn't the ftdump utility from the dtc package cover your needs ? No. The purpose is to use this utility e.g. in a Linux shell script to retrieve a property from the ITB. The two places I use it are to retrieve a version number from the ITB and to identify the offset and size of a data block (image) in the ITB. From what I can see the ftdump utility in the dtc component just dumps the ITB as a single blob with no options. I'm looking at the dtc 1.2.0 source. ... so wouldn't the logical thing be to extend ftdump to support your needs and send a patch to the DTC authors rather than to write an entire tool from scratch and commit it to a tree that is merely a user of device trees ? Yes it probably would have been, if I had noticed that the ftdump utility existed, then that is the approach I would have taken. I think it is of specific use to u-boot users, but if you think it's better to extend ftdump, I guess I could take that approach. i think it has a better chance of being maintained and other people using it if it were merged into the canonical DTC project. i can see a more swiss army type tool being useful to people rather than having to pipe it all through awk. git: git://git.jdl.com/software/dtc.git e-mail: devicetree-disc...@lists.ozlabs.org they're friendly people :) Mostly :-) 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 v8] [RFC] early_malloc for DM added.
Dear Tomas Hlavacek, [..] + + if (early_malloc_active()) { + addr = early_malloc(size); + for (i=0; isize; i++) + addr[i] = 0; memset() ? + + return addr; + } +#endif /* CONFIG_SYS_EARLY_MALLOC */ + return calloc(n, elem_size); +} + +static inline void *dmrealloc(void *oldmem, size_t bytes) +{ +#ifdef CONFIG_SYS_EARLY_MALLOC + if (early_malloc_active()) + return NULL; I wonder how should this be implemented ... maybe early_malloc + standard memcpy() +#endif /* CONFIG_SYS_EARLY_MALLOC */ + return dmrealloc(oldmem, bytes); +} + +#endif /* CONFIG_DM */ +#endif /* __INCLUDE_DMMALLOC_H */ + 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 v2 1/6] h2200: Add support for iPAQ h2200 palmtop
On 24.09.2012 01:05, Marek Vasut wrote: Dear Łukasz Dałek, On 23.09.2012 23:31, Marek Vasut wrote: Dear Łukasz Dałek, On 23.09.2012 23:04, Marek Vasut wrote: PXA2xx is OHCI host with one OTG port. From pxa255 documentation: The UDC supports 16 endpoints and can operate half-duplex at a rate of 12 Mbps (as a slave only, not as a host or hub controller). what about include/usb/pxa27x_udc.h ... btw can't pxa27x and pxa25x UDC use the same driver? pxa27x_udc driver is using older layer which doesn't work with usb ethernet driver. Btw. pxa27x can be host, pxa25x can't. Can you update the new gadget driver to be compatible with pxa27x then ? I don't have any board with pxa27x processor. And I'm quite sure that differences between pxa25x and pxa27x usb are too big. Even in Linux kernel are two separate drivers for 25x and 27x chips. Isn't the 25x only a subset of the 27x ? Maybe it is. You've asked me if I could update driver to compatible with pxa27x and my answer is no. Maybe someone with pxa27x chip could. I will left that h2200.h header. I'm sure that it will be helpful some day. Łukasz Dałek ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/6] h2200: Add support for iPAQ h2200 palmtop
Dear Łukasz Dałek, On 24.09.2012 01:05, Marek Vasut wrote: Dear Łukasz Dałek, On 23.09.2012 23:31, Marek Vasut wrote: Dear Łukasz Dałek, On 23.09.2012 23:04, Marek Vasut wrote: PXA2xx is OHCI host with one OTG port. From pxa255 documentation: The UDC supports 16 endpoints and can operate half-duplex at a rate of 12 Mbps (as a slave only, not as a host or hub controller). what about include/usb/pxa27x_udc.h ... btw can't pxa27x and pxa25x UDC use the same driver? pxa27x_udc driver is using older layer which doesn't work with usb ethernet driver. Btw. pxa27x can be host, pxa25x can't. Can you update the new gadget driver to be compatible with pxa27x then ? I don't have any board with pxa27x processor. And I'm quite sure that differences between pxa25x and pxa27x usb are too big. Even in Linux kernel are two separate drivers for 25x and 27x chips. Isn't the 25x only a subset of the 27x ? Maybe it is. You've asked me if I could update driver to compatible with pxa27x and my answer is no. Maybe someone with pxa27x chip could. I can test it. It'd be good to have only one driver and get rid of the old one seems to be the way to go. I will left that h2200.h header. I'm sure that it will be helpful some day. For what exactly? Just put it into include/usb.h . Łukasz Dałek 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 V2 08/21] mx6: add plugin file for use with imximage.cfg
On 09/23/2012 10:08 AM, Stefano Babic wrote: On 23/09/2012 18:23, Eric Nelson wrote: On 09/23/2012 03:17 AM, Stefano Babic wrote: On 22/09/2012 04:39, Troy Kisky wrote: The plugin command of mkimage can take this file as an argument. Signed-off-by: Troy Kiskytroy.ki...@boundarydevices.com --- Hi Troy, I agree with Vikram that a better explanation of what a plugin is can help to understand without reading deeply into the i.MX6 manual. So a plugin is a chunk of code that can be called directly by the BootROM of i.MX processors supporting V2 version of the i.MX header. In my understanding, this is supported by i.MX53, too. After the plugin run, the control is returned to the BootROM. Hi Stefano, It seems that there's some general confusion on the list, so I think a little more background and commentary is in order. Well, it is - thanks for explanation. The primary rationale for plugins is to allow separate link maps in a single image loaded by the BootROM. The idea is to allow first-level code to initialize resources (usually DDR) while running in internal RAM, then return to the boot rom for further image loading (typically into DDR). This prevents the need for the first-level code to support all boot sources (SPI-NOR, NAND, SD card, etc) and allows it to focus on machine setup. The feature is normally needed to allow the first level to access a PMIC. I'm surprised that the 51evk and 53Loco boards aren't using it. The mx51 uses a V1 header and the plugin feature is not supported at all. So, it can't, simply. The mx53 can, but it is not needed. Both boards boot without plugin. So it seem we have a misunderstanding, and thanks to raise this issue ;-) The setup is done by the SOC interpreting the DCD data into the iMX header. After this setup, that in any case cannot be very long, the control is still taken by the bootROM, that copies data from the media device to the DDR according to the values set into the iMX header. Still without plugin. After the copy, the bootROM gives the control to U-Boot for the rest that starts with the usual initialization. There is no need to setup the pMIC on mx51evk and mx53qsb to get the DDR running. However, even if we need it, we can do it in another way, as I will explain now. Troy's rationale for using it now is to enable a single image on i.MX6Quad, Dual lite and Solo processors, which have very slight initialization differences. The 6Solo processor has 32-bit DDR bus, so it would otherwise require a separate binary. By doing this in code (plugin), we can introduce a conditional based on processor type and have a single image that will boot on any of the three. Ok - but why cannot this check be done directly by U-Boot ? My understanding is that you want to add a plugin written in assembly to allow different setup of the DDR controller. Let's see how we can do with standard U-Boot code. Core of the startup is that the SOC copies itself some code into the internal RAM and started. This is done by bootROM, running is own code and running the plugin. We have already this mechanism with the SPL framework. The big advantage for this approach is that the same mechanism can be used on SOC of different vendors, while the one in this series is a solution strictly bound with (some) Freescale's SOC. The imx header can be still adapted to copy the SPL code into the internal RAM. When SPL is running, you have all freedom to check which is the CPU running and to adjust your DDR setting, and everything is C code. Both MX5 and MX6 have plenty of internal RAM to do this, because SPL requires ~30KB. This is the part that gets interesting. You're right that SPL **can** do the job, but only if it supports the boot media. For the most part, it's reasonable to expect the code to be written in U-Boot for that, since the boot media may also be used to load kernels, RAM disks and the like. But what about the serial boot modes (especially USB)? We likely wouldn't implement them (we haven't yet pulled in USB slave support) and to paraphrase US bumper stickers: You can take imx_usb away from me when you pry it from my cold dead hands ;) If you're not aware of imx_usb, it's a utility that Troy wrote to allow download over the boot ROM's USB protocol. Some commentary is here: http://boundarydevices.com/unbricking-nitrogen6x-sabre-lite-i-mx6-board/ The sources are here (requires libusb): https://github.com/boundarydevices/imx_usb_loader I think the goal to have the same U-Boot binary can be reached using the SPL framework. As you are running U-Boot code, you have the possibility to do whatever you want. So my question is: if the main reason is to have a single image for all your iMX6 boards, why cannot we do it in a standard way using SPL ? The related question is whether or not the benefits of a single image is worth the carrying cost. This is probably more useful for those who boot directly to SD card, where the cost of
Re: [U-Boot] [PATCH v2 1/6] h2200: Add support for iPAQ h2200 palmtop
On 24.09.2012 01:25, Marek Vasut wrote: Dear Łukasz Dałek, On 24.09.2012 01:05, Marek Vasut wrote: Dear Łukasz Dałek, On 23.09.2012 23:31, Marek Vasut wrote: Dear Łukasz Dałek, On 23.09.2012 23:04, Marek Vasut wrote: PXA2xx is OHCI host with one OTG port. From pxa255 documentation: The UDC supports 16 endpoints and can operate half-duplex at a rate of 12 Mbps (as a slave only, not as a host or hub controller). what about include/usb/pxa27x_udc.h ... btw can't pxa27x and pxa25x UDC use the same driver? pxa27x_udc driver is using older layer which doesn't work with usb ethernet driver. Btw. pxa27x can be host, pxa25x can't. Can you update the new gadget driver to be compatible with pxa27x then ? I don't have any board with pxa27x processor. And I'm quite sure that differences between pxa25x and pxa27x usb are too big. Even in Linux kernel are two separate drivers for 25x and 27x chips. Isn't the 25x only a subset of the 27x ? Maybe it is. You've asked me if I could update driver to compatible with pxa27x and my answer is no. Maybe someone with pxa27x chip could. I can test it. It'd be good to have only one driver and get rid of the old one seems to be the way to go. Does this driver work with usb ethernet gadget? I will left that h2200.h header. I'm sure that it will be helpful some day. For what exactly? Just put it into include/usb.h . I can't. It doesn't compile because of #error at 170 line. Łukasz Dałek ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v8] [RFC] early_malloc for DM added.
Hi Tomas, On Mon, Sep 24, 2012 at 2:15 AM, Tomas Hlavacek tmshl...@gmail.com wrote: early_malloc for DM with support for more heaps and lightweight first heap in the same memory as an early stack. Adaptation layer for seamless calling of early_malloc or dlmalloc from DM based on init stage added (dmmalloc() and related functions). Signed-off-by: Tomas Hlavacek tmshl...@gmail.com --- Changelog since v5: dmmalloc() and all dm* functions has been moved to header, made static inline and preprocessor-dependent blocks are reworked. early_malloc_active() corrected and made not static. s/CONFIG_SYS_DM/CONFIG_DM/ applied. Changelog sice v6: Check of first heap emptyness in early_brk() has been simplified. Changelog since v7: dmcalloc() implmentation added. Comments added to header. arch/arm/include/asm/global_data.h|3 + arch/arm/lib/board.c |8 ++ arch/avr32/include/asm/global_data.h |3 + arch/avr32/lib/board.c|9 +++ arch/blackfin/include/asm/global_data.h |3 + arch/blackfin/lib/board.c |8 ++ arch/m68k/include/asm/global_data.h |3 + arch/m68k/lib/board.c |8 ++ arch/microblaze/include/asm/global_data.h |3 + arch/microblaze/lib/board.c |9 +++ arch/mips/include/asm/global_data.h |3 + arch/mips/lib/board.c |8 ++ arch/nds32/include/asm/global_data.h |3 + arch/nds32/lib/board.c|8 ++ arch/nios2/include/asm/global_data.h |3 + arch/nios2/lib/board.c|8 ++ arch/openrisc/include/asm/global_data.h |3 + arch/openrisc/lib/board.c |8 ++ arch/powerpc/include/asm/global_data.h|3 + arch/powerpc/lib/board.c |8 ++ arch/sandbox/include/asm/global_data.h|3 + arch/sandbox/lib/board.c |8 ++ arch/sh/include/asm/global_data.h |3 + arch/sh/lib/board.c |8 ++ arch/sparc/include/asm/global_data.h |3 + arch/sparc/lib/board.c|8 ++ arch/x86/include/asm/global_data.h|3 + arch/x86/lib/board.c | 18 + common/Makefile |1 + common/dmmalloc.c | 88 ++ include/dmmalloc.h| 117 + 31 files changed, 372 insertions(+) create mode 100644 common/dmmalloc.c create mode 100644 include/dmmalloc.h diff --git a/arch/arm/include/asm/global_data.h b/arch/arm/include/asm/global_data.h index f8088fe..ef727b0 100644 --- a/arch/arm/include/asm/global_data.h +++ b/arch/arm/include/asm/global_data.h @@ -82,6 +82,9 @@ typedef struct global_data { unsigned long post_log_res; /* success of POST test */ unsigned long post_init_f_time; /* When post_init_f started */ #endif +#ifdef CONFIG_SYS_EARLY_MALLOC + void*early_heap_first; /* heap for early_malloc */ +#endif } gd_t; #include asm-generic/global_data_flags.h diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c index f1951e8..f73d8b2 100644 --- a/arch/arm/lib/board.c +++ b/arch/arm/lib/board.c @@ -53,6 +53,10 @@ #include post.h #include logbuff.h +#ifdef CONFIG_DM +#include dmmalloc.h +#endif + #ifdef CONFIG_BITBANGMII #include miiphy.h #endif @@ -281,6 +285,10 @@ void board_init_f(ulong bootflag) memset((void *)gd, 0, sizeof(gd_t)); +#ifdef CONFIG_SYS_EARLY_MALLOC + gd-early_heap_first = early_brk(CONFIG_SYS_EARLY_HEAP_SIZE); +#endif /* CONFIG_SYS_EARLY_MALLOC */ + I just realised that all these initialisers can be dumped - early_brk() will be called when early_malloc() is first called [snip] diff --git a/arch/x86/lib/board.c b/arch/x86/lib/board.c index 90cf7fc..a670f9e 100644 --- a/arch/x86/lib/board.c +++ b/arch/x86/lib/board.c @@ -40,6 +40,10 @@ #include asm/init_helpers.h #include asm/init_wrappers.h +#ifdef CONFIG_DM +#include dmmalloc.h +#endif + /* * Breath some life into the board... * @@ -85,6 +89,17 @@ typedef int (init_fnc_t) (void); /* + * Initialize early heap (when enabled by config). + */ +#ifdef CONFIG_SYS_EARLY_MALLOC +static void early_malloc_init(void) +{ + gd-early_heap_first = early_brk(CONFIG_SYS_EARLY_HEAP_SIZE); +} +#endif /* CONFIG_SYS_EARLY_MALLOC */ So this uglyness goes + + +/* * init_sequence_f is the list of init functions which are run when U-Boot * is executing from Flash with a limited 'C' environment. The following * limitations must be considered when implementing an '_f' function: @@ -99,6 +114,9 @@ init_fnc_t *init_sequence_f[] = { cpu_init_f, board_early_init_f, env_init, +#ifdef CONFIG_SYS_EARLY_MALLOC + early_malloc_init, +#endif /*
Re: [U-Boot] [PATCH v8] [RFC] early_malloc for DM added.
Hi Graeme! On Mon, Sep 24, 2012 at 2:00 AM, Graeme Russ graeme.r...@gmail.com wrote: Hi Tomas, On Mon, Sep 24, 2012 at 2:15 AM, Tomas Hlavacek tmshl...@gmail.com wrote: early_malloc for DM with support for more heaps and lightweight first heap in the same memory as an early stack. Adaptation layer for seamless calling of early_malloc or dlmalloc from DM based on init stage added (dmmalloc() and related functions). Signed-off-by: Tomas Hlavacek tmshl...@gmail.com --- Changelog since v5: dmmalloc() and all dm* functions has been moved to header, made static inline and preprocessor-dependent blocks are reworked. early_malloc_active() corrected and made not static. s/CONFIG_SYS_DM/CONFIG_DM/ applied. Changelog sice v6: Check of first heap emptyness in early_brk() has been simplified. Changelog since v7: dmcalloc() implmentation added. Comments added to header. arch/arm/include/asm/global_data.h|3 + arch/arm/lib/board.c |8 ++ arch/avr32/include/asm/global_data.h |3 + arch/avr32/lib/board.c|9 +++ arch/blackfin/include/asm/global_data.h |3 + arch/blackfin/lib/board.c |8 ++ arch/m68k/include/asm/global_data.h |3 + arch/m68k/lib/board.c |8 ++ arch/microblaze/include/asm/global_data.h |3 + arch/microblaze/lib/board.c |9 +++ arch/mips/include/asm/global_data.h |3 + arch/mips/lib/board.c |8 ++ arch/nds32/include/asm/global_data.h |3 + arch/nds32/lib/board.c|8 ++ arch/nios2/include/asm/global_data.h |3 + arch/nios2/lib/board.c|8 ++ arch/openrisc/include/asm/global_data.h |3 + arch/openrisc/lib/board.c |8 ++ arch/powerpc/include/asm/global_data.h|3 + arch/powerpc/lib/board.c |8 ++ arch/sandbox/include/asm/global_data.h|3 + arch/sandbox/lib/board.c |8 ++ arch/sh/include/asm/global_data.h |3 + arch/sh/lib/board.c |8 ++ arch/sparc/include/asm/global_data.h |3 + arch/sparc/lib/board.c|8 ++ arch/x86/include/asm/global_data.h|3 + arch/x86/lib/board.c | 18 + common/Makefile |1 + common/dmmalloc.c | 88 ++ include/dmmalloc.h| 117 + 31 files changed, 372 insertions(+) create mode 100644 common/dmmalloc.c create mode 100644 include/dmmalloc.h diff --git a/arch/arm/include/asm/global_data.h b/arch/arm/include/asm/global_data.h index f8088fe..ef727b0 100644 --- a/arch/arm/include/asm/global_data.h +++ b/arch/arm/include/asm/global_data.h @@ -82,6 +82,9 @@ typedef struct global_data { unsigned long post_log_res; /* success of POST test */ unsigned long post_init_f_time; /* When post_init_f started */ #endif +#ifdef CONFIG_SYS_EARLY_MALLOC + void*early_heap_first; /* heap for early_malloc */ +#endif } gd_t; #include asm-generic/global_data_flags.h diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c index f1951e8..f73d8b2 100644 --- a/arch/arm/lib/board.c +++ b/arch/arm/lib/board.c @@ -53,6 +53,10 @@ #include post.h #include logbuff.h +#ifdef CONFIG_DM +#include dmmalloc.h +#endif + #ifdef CONFIG_BITBANGMII #include miiphy.h #endif @@ -281,6 +285,10 @@ void board_init_f(ulong bootflag) memset((void *)gd, 0, sizeof(gd_t)); +#ifdef CONFIG_SYS_EARLY_MALLOC + gd-early_heap_first = early_brk(CONFIG_SYS_EARLY_HEAP_SIZE); +#endif /* CONFIG_SYS_EARLY_MALLOC */ + I just realised that all these initialisers can be dumped - early_brk() will be called when early_malloc() is first called Yes, but how can I determine the size of the new heap which the early_brk gives out? When I have CONFIG_SYS_EARLY_HEAP_SIZE macro in board configuration I can ignore the size passed to the default early_brk and return the full-sized heap as configuration says (when the requested size is lower than configured heap size and NULL otherwise). But what if somebody implements at some point a dynamic early_brk capable of returning multiple heaps? Should I safely assume that the future dynamic early_brk would give out multiples of page size or so? All other comments understood and agreed. Thanks, Tomas ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v8] [RFC] early_malloc for DM added.
Hi Thomas, On Mon, Sep 24, 2012 at 10:35 AM, Tomas Hlavacek tmshl...@gmail.com wrote: Hi Graeme! On Mon, Sep 24, 2012 at 2:00 AM, Graeme Russ graeme.r...@gmail.com wrote: Hi Tomas, On Mon, Sep 24, 2012 at 2:15 AM, Tomas Hlavacek tmshl...@gmail.com wrote: early_malloc for DM with support for more heaps and lightweight first heap in the same memory as an early stack. Adaptation layer for seamless calling of early_malloc or dlmalloc from DM based on init stage added (dmmalloc() and related functions). Signed-off-by: Tomas Hlavacek tmshl...@gmail.com --- Changelog since v5: dmmalloc() and all dm* functions has been moved to header, made static inline and preprocessor-dependent blocks are reworked. early_malloc_active() corrected and made not static. s/CONFIG_SYS_DM/CONFIG_DM/ applied. Changelog sice v6: Check of first heap emptyness in early_brk() has been simplified. Changelog since v7: dmcalloc() implmentation added. Comments added to header. arch/arm/include/asm/global_data.h|3 + arch/arm/lib/board.c |8 ++ arch/avr32/include/asm/global_data.h |3 + arch/avr32/lib/board.c|9 +++ arch/blackfin/include/asm/global_data.h |3 + arch/blackfin/lib/board.c |8 ++ arch/m68k/include/asm/global_data.h |3 + arch/m68k/lib/board.c |8 ++ arch/microblaze/include/asm/global_data.h |3 + arch/microblaze/lib/board.c |9 +++ arch/mips/include/asm/global_data.h |3 + arch/mips/lib/board.c |8 ++ arch/nds32/include/asm/global_data.h |3 + arch/nds32/lib/board.c|8 ++ arch/nios2/include/asm/global_data.h |3 + arch/nios2/lib/board.c|8 ++ arch/openrisc/include/asm/global_data.h |3 + arch/openrisc/lib/board.c |8 ++ arch/powerpc/include/asm/global_data.h|3 + arch/powerpc/lib/board.c |8 ++ arch/sandbox/include/asm/global_data.h|3 + arch/sandbox/lib/board.c |8 ++ arch/sh/include/asm/global_data.h |3 + arch/sh/lib/board.c |8 ++ arch/sparc/include/asm/global_data.h |3 + arch/sparc/lib/board.c|8 ++ arch/x86/include/asm/global_data.h|3 + arch/x86/lib/board.c | 18 + common/Makefile |1 + common/dmmalloc.c | 88 ++ include/dmmalloc.h| 117 + 31 files changed, 372 insertions(+) create mode 100644 common/dmmalloc.c create mode 100644 include/dmmalloc.h diff --git a/arch/arm/include/asm/global_data.h b/arch/arm/include/asm/global_data.h index f8088fe..ef727b0 100644 --- a/arch/arm/include/asm/global_data.h +++ b/arch/arm/include/asm/global_data.h @@ -82,6 +82,9 @@ typedef struct global_data { unsigned long post_log_res; /* success of POST test */ unsigned long post_init_f_time; /* When post_init_f started */ #endif +#ifdef CONFIG_SYS_EARLY_MALLOC + void*early_heap_first; /* heap for early_malloc */ +#endif } gd_t; #include asm-generic/global_data_flags.h diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c index f1951e8..f73d8b2 100644 --- a/arch/arm/lib/board.c +++ b/arch/arm/lib/board.c @@ -53,6 +53,10 @@ #include post.h #include logbuff.h +#ifdef CONFIG_DM +#include dmmalloc.h +#endif + #ifdef CONFIG_BITBANGMII #include miiphy.h #endif @@ -281,6 +285,10 @@ void board_init_f(ulong bootflag) memset((void *)gd, 0, sizeof(gd_t)); +#ifdef CONFIG_SYS_EARLY_MALLOC + gd-early_heap_first = early_brk(CONFIG_SYS_EARLY_HEAP_SIZE); +#endif /* CONFIG_SYS_EARLY_MALLOC */ + I just realised that all these initialisers can be dumped - early_brk() will be called when early_malloc() is first called Yes, but how can I determine the size of the new heap which the early_brk gives out? When I have CONFIG_SYS_EARLY_HEAP_SIZE macro in board configuration I can ignore the size passed to the default early_brk and return the full-sized heap as configuration says (when the requested size is lower than configured heap size and NULL default early_brk() should always use CONFIG_SYS_EARLY_HEAP_SIZE otherwise). But what if somebody implements at some point a dynamic early_brk capable of returning multiple heaps? Should I safely assume that the future dynamic early_brk would give out multiples of page size or so? Very good point. I would assume early_brk() will always return the largest possible chunk of memory it can. These sizes might be specified as multiple #defines in the board config or may be dynamically determined via hardware probing. Either way, that is a problem for the implementer to deal with
[U-Boot] [RFC] [PATCH 0/3] Linker-generated arrays
This is a first stab at the linker-generated array. Basically, this concept is a generic abstraction of how u_boot_cmd works today. The patch 2/3 contains a huge pile of documentation which should clarify most of the questions. NOTE: Compile-testing in progress, but it works with m28evk and sandbox for now. Marek Vasut (3): common: Add symbol handling for generic lists into Makefile common: Implement support for linker-generated arrays common: Add .u_boot_list into all linker files Makefile | 21 +++- arch/arm/cpu/arm920t/ep93xx/u-boot.lds |5 + arch/arm/cpu/arm926ejs/mxs/u-boot-spl.lds|4 + arch/arm/cpu/arm926ejs/spear/u-boot-spl.lds |4 + arch/arm/cpu/armv7/omap-common/u-boot-spl.lds|5 + arch/arm/cpu/ixp/u-boot.lds |5 + arch/arm/cpu/u-boot.lds |5 + arch/avr32/cpu/u-boot.lds|5 + arch/blackfin/cpu/u-boot.lds |4 + arch/microblaze/cpu/u-boot.lds |5 + arch/nds32/cpu/n1213/u-boot.lds |5 + arch/nios2/cpu/u-boot.lds|5 + arch/powerpc/cpu/74xx_7xx/u-boot.lds |5 + arch/powerpc/cpu/mpc512x/u-boot.lds |5 + arch/powerpc/cpu/mpc5xx/u-boot.lds |5 + arch/powerpc/cpu/mpc5xxx/u-boot-customlayout.lds |3 + arch/powerpc/cpu/mpc5xxx/u-boot.lds |5 + arch/powerpc/cpu/mpc8220/u-boot.lds |5 + arch/powerpc/cpu/mpc824x/u-boot.lds |5 + arch/powerpc/cpu/mpc8260/u-boot.lds |5 + arch/powerpc/cpu/mpc83xx/u-boot.lds |5 + arch/powerpc/cpu/mpc85xx/u-boot-nand.lds |4 + arch/powerpc/cpu/mpc85xx/u-boot-nand_spl.lds |4 + arch/powerpc/cpu/mpc85xx/u-boot.lds |5 + arch/powerpc/cpu/mpc86xx/u-boot.lds |5 + arch/powerpc/cpu/ppc4xx/u-boot.lds |5 + arch/sandbox/cpu/u-boot.lds |5 + arch/sh/cpu/sh2/u-boot.lds |4 + arch/sh/cpu/sh3/u-boot.lds |4 + arch/sh/cpu/sh4/u-boot.lds |4 + arch/x86/cpu/u-boot.lds |5 + board/BuS/eb_cpu5282/u-boot.lds |5 + board/LEOX/elpt860/u-boot.lds|5 + board/RPXClassic/u-boot.lds |5 + board/RPXlite/u-boot.lds |5 + board/RPXlite_dw/u-boot.lds |5 + board/RRvision/u-boot.lds|5 + board/actux1/u-boot.lds |5 + board/actux2/u-boot.lds |5 + board/actux3/u-boot.lds |5 + board/adder/u-boot.lds |5 + board/ait/cam_enc_4xx/u-boot-spl.lds |4 + board/altera/nios2-generic/u-boot.lds|5 + board/amcc/acadia/u-boot-nand.lds|3 + board/amcc/bamboo/u-boot-nand.lds|3 + board/amcc/canyonlands/u-boot-nand.lds |3 + board/amcc/kilauea/u-boot-nand.lds |3 + board/amcc/sequoia/u-boot-nand.lds |3 + board/amcc/sequoia/u-boot-ram.lds|3 + board/amirix/ap1000/u-boot.lds |5 + board/astro/mcf5373l/u-boot.lds |5 + board/c2mon/u-boot.lds |5 + board/cobra5272/u-boot.lds |5 + board/cogent/u-boot.lds |5 + board/dave/PPChameleonEVB/u-boot.lds |5 + board/davinci/da8xxevm/u-boot-spl-da850evm.lds |6 ++ board/davinci/da8xxevm/u-boot-spl-hawk.lds |5 + board/dbau1x00/u-boot.lds|5 + board/dvlhost/u-boot.lds |5 + board/eltec/mhpc/u-boot.lds |5 + board/emk/top860/u-boot.lds |5 + board/ep88x/u-boot.lds |5 + board/esd/dasa_sim/u-boot.lds|5 + board/esd/pmc440/u-boot-nand.lds |3 + board/esd/tasreg/u-boot.lds |5 + board/esteem192e/u-boot.lds |5 + board/etx094/u-boot.lds |5 + board/evb64260/u-boot.lds|5 + board/fads/u-boot.lds|5 + board/flagadm/u-boot.lds |5 + board/freescale/m5208evbe/u-boot.lds |5 + board/freescale/m52277evb/u-boot.lds |5 + board/freescale/m5235evb/u-boot.lds |5 + board/freescale/m5249evb/u-boot.lds |5 + board/freescale/m5253demo/u-boot.lds |5 + board/freescale/m5253evbe/u-boot.lds |5 +
[U-Boot] [PATCH 1/3] common: Add symbol handling for generic lists into Makefile
This patch adds essential components for generation of the contents of the linker section that is used by the linker-generated array. All of the contents is held in a separate file, u-boot.lst, which is generated at runtime just before U-Boot is linked. The purpose of this code is to especially generate the appropriate boundary symbols around each subsection in the section carrying the linker-generated arrays. Obviously, the interim linker code for actual placement of the variables into the section is generated too. The generated file, u-boot.lst, is included into u-boot.lds via the linker INCLUDE directive in u-boot.lds . Adjustments are made in the Makefile and spl/Makefile so that the u-boot.lds and u-boot-spl.lds depend on their respective .lst files. Signed-off-by: Marek Vasut ma...@denx.de Cc: Joe Hershberger joe.hershber...@gmail.com Cc: Mike Frysinger vap...@gentoo.org --- Makefile | 21 ++--- spl/Makefile | 14 +- 2 files changed, 31 insertions(+), 4 deletions(-) diff --git a/Makefile b/Makefile index e3a27c6..592987a 100644 --- a/Makefile +++ b/Makefile @@ -510,7 +510,10 @@ else GEN_UBOOT = \ UNDEF_SYM=`$(OBJDUMP) -x $(LIBBOARD) $(LIBS) | \ sed -n -e 's/.*\($(SYM_PREFIX)__u_boot_cmd_.*\)/-u\1/p'|sort|uniq`;\ - cd $(LNDIR) $(LD) $(LDFLAGS) $(LDFLAGS_$(@F)) $$UNDEF_SYM $(__OBJS) \ + UNDEF_LST=`$(OBJDUMP) -x $(LIBBOARD) $(LIBS) | \ + sed -n -e 's/.*\($(SYM_PREFIX)__u_boot_list_.*\)/-u\1/p'|sort|uniq`;\ + cd $(LNDIR) $(LD) $(LDFLAGS) $(LDFLAGS_$(@F)) \ + $$UNDEF_SYM $$UNDEF_LST $(__OBJS) \ --start-group $(__LIBS) --end-group $(PLATFORM_LIBS) \ -Map u-boot.map -o u-boot endif @@ -543,8 +546,20 @@ $(SUBDIR_EXAMPLES): $(obj)u-boot $(LDSCRIPT): depend $(MAKE) -C $(dir $@) $(notdir $@) -$(obj)u-boot.lds: $(LDSCRIPT) - $(CPP) $(CPPFLAGS) $(LDPPFLAGS) -ansi -D__ASSEMBLY__ -P - $^ $@ +$(obj)u-boot.lst: $(LIBBOARD) $(LIBS) + $(OBJDUMP) -h $(LIBBOARD) $(LIBS) | \ + sed -n -e 's/.*\(\.u_boot_list[^ ]\+\).*$$/\1/p' | \ + sed 's/\.[^\.]\+$$//' | \ + sed -n ':s /^.\+$$/ { p;s/^\(.*\)\.[^\.]*$$/\1/;b s }' | \ + sed -n 's/\./.#/g;h;s/$$/\a/p;g;s/$$/@/p;g;s/$$/~/p;' | \ + LC_COLLATE=C sort -u | \ + sed 's/#//g' | \ + sed -n -e '/\a$$/ { s/\./_/g;s/\a$$/__start = .;/p; }'\ + -e '/~$$/ { s/\./_/g;s/~$$/__end = .;/p; }'\ + -e '/@$$/ { s/\(.*\)@$$/*(SORT(\1.*));/p }' $@ + +$(obj)u-boot.lds: $(LDSCRIPT) $(obj)u-boot.lst + $(CPP) $(CPPFLAGS) $(LDPPFLAGS) -ansi -D__ASSEMBLY__ -P - $ $@ nand_spl: $(TIMESTAMP_FILE) $(VERSION_FILE) depend $(MAKE) -C nand_spl/board/$(BOARDDIR) all diff --git a/spl/Makefile b/spl/Makefile index d4cb668..545adfe 100644 --- a/spl/Makefile +++ b/spl/Makefile @@ -148,7 +148,19 @@ $(START): depend $(LIBS): depend $(MAKE) -C $(SRCTREE)$(dir $(subst $(SPLTREE),,$@)) -$(obj)u-boot-spl.lds: $(LDSCRIPT) depend +$(obj)u-boot-spl.lst: $(LIBS) + $(OBJDUMP) -h $(LIBS) | \ + sed -n -e 's/.*\(\.u_boot_list[^ ]\+\).*$$/\1/p' | \ + sed 's/\.[^\.]\+$$//' | \ + sed -n ':s /^.\+$$/ { p;s/^\(.*\)\.[^\.]*$$/\1/;b s }' | \ + sed -n 's/\./.#/g;h;s/$$/\a/p;g;s/$$/@/p;g;s/$$/~/p;' | \ + LC_COLLATE=C sort -u | \ + sed 's/#//g' | \ + sed -n -e '/\a$$/ { s/\./_/g;s/\a$$/__start = .;/p; }'\ + -e '/~$$/ { s/\./_/g;s/~$$/__end = .;/p; }'\ + -e '/@$$/ { s/\(.*\)@$$/*(SORT(\1.*));/p }' $@ + +$(obj)u-boot-spl.lds: $(LDSCRIPT) $(obj)u-boot-spl.lst depend $(CPP) $(CPPFLAGS) $(LDPPFLAGS) -ansi -D__ASSEMBLY__ -P - $ $@ depend:$(obj).depend -- 1.7.10.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot