November 2013 - U-Boot

[U-Boot] [PATCH] boards.cfg: update email address for ti814x_evm maintainer
by Matt Porter 12 Nov '13

12 Nov '13

Update my email address as ti814x_evm maintainer to save people some frustrating bounces and non-response. Signed-off-by: Matt Porter <matt.porter(a)linaro.org> --- boards.cfg | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/boards.cfg b/boards.cfg index 5e10125..cd6bec4 100644 --- a/boards.cfg +++ b/boards.cfg @@ -264,7 +264,7 @@ Active arm armv7 am33xx ti am335x Active arm armv7 am33xx ti am335x am335x_evm_uart5 am335x_evm:SERIAL6,CONS_INDEX=1,NAND Tom Rini <trini(a)ti.com> Active arm armv7 am33xx ti am335x am335x_evm_usbspl am335x_evm:SERIAL1,CONS_INDEX=1,NAND,SPL_USBETH_SUPPORT Tom Rini <trini(a)ti.com> Active arm armv7 am33xx ti am43xx am43xx_evm am43xx_evm:SERIAL1,CONS_INDEX=1 - -Active arm armv7 am33xx ti ti814x ti814x_evm - Matt Porter <mporter(a)ti.com> +Active arm armv7 am33xx ti ti814x ti814x_evm - Matt Porter <matt.porter(a)linaro.org> Active arm armv7 am33xx ti ti816x ti816x_evm - - Active arm armv7 at91 atmel sama5d3xek sama5d3xek_mmc sama5d3xek:SAMA5D3,SYS_USE_MMC Bo Shen <voice.shen(a)atmel.com> Active arm armv7 at91 atmel sama5d3xek sama5d3xek_nandflash sama5d3xek:SAMA5D3,SYS_USE_NANDFLASH Bo Shen <voice.shen(a)atmel.com> -- 1.8.4

2 1

[U-Boot] Pull request: u-boot-video/master
by Anatolij Gustschin 12 Nov '13

12 Nov '13

Hi Tom, here are LCD panel support patches for cm_t35 board and a fix for Raspberry Pi LCD driver. Please pull. Thanks! Anatolij The following changes since commit 649acfe149e8a534a17eab54004a51d69b5556ed: MPC824x: remove obsolete "PN62" board (2013-11-11 14:46:24 -0500) are available in the git repository at: git://git.denx.de/u-boot-video.git master for you to fetch changes up to 63c4f17b2f8017d22241522a48c765073b8791b0: cm_t35: use scf0403 driver (2013-11-12 10:12:07 +0100) ---------------------------------------------------------------- Anatolij Gustschin (1): lcd: allow overriding lcd_get_size() Andre Heider (2): ARM: bcm2835: add missing mbox overscan response field video: bcm2835: respect the pitch value Nikita Kiryanov (6): spi: omap3: remove semicolon from #define spi: omap3: add support for more word lengths spi: define SPI_XFER_ONCE lcd: add DataImage SCF0403x LCD panel support omap3_dss: define DSS_ONOFF cm_t35: use scf0403 driver arch/arm/include/asm/arch-bcm2835/mbox.h | 1 + arch/arm/include/asm/arch-omap3/dss.h | 9 +- board/compulab/cm_t35/cm_t35.c | 12 ++ board/compulab/common/omap3_display.c | 46 ++++- common/lcd.c | 10 +- drivers/spi/omap3_spi.c | 71 ++++--- drivers/spi/omap3_spi.h | 8 +- drivers/spi/spi.c | 13 ++ drivers/video/Makefile | 1 + drivers/video/bcm2835.c | 11 ++ drivers/video/scf0403_lcd.c | 296 ++++++++++++++++++++++++++++++ include/configs/cm_t35.h | 3 + include/scf0403_lcd.h | 11 ++ include/spi.h | 17 ++ 14 files changed, 475 insertions(+), 34 deletions(-) create mode 100644 drivers/video/scf0403_lcd.c create mode 100644 include/scf0403_lcd.h

2 1

[U-Boot] [PATCH RFC] imx: add multi-architecture README
by Eric Nelson 12 Nov '13

12 Nov '13

Signed-off-by: Eric Nelson <eric.nelson(a)boundarydevices.com> --- doc/README.imx6-multi-arch | 254 +++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 254 insertions(+) create mode 100644 doc/README.imx6-multi-arch diff --git a/doc/README.imx6-multi-arch b/doc/README.imx6-multi-arch new file mode 100644 index 0000000..a31718c --- /dev/null +++ b/doc/README.imx6-multi-arch @@ -0,0 +1,254 @@ +Supporting multiple architectures on Freescale i.MX6 + +This file describes how to support multiple CPU architectures +(i.MX6DQ and i.MX6DLS) in a single U-Boot image. + +Because memory configuration differs between architectures, +auto-configuration of DDR is also covered. + +1. BACKGROUND +------------- +The Freescale i.MX6 processor family contains four processors which are pin +compatible. Refer to http://freescale.com/imx6series for details and reference +manuals, but the highlights from a U-Boot perspective are as follows: + +i.MX6Q - Quad core, 64-bit DDR1066, 256K OCRAM +i.MX6D - Dual core, 64-bit DDR1066, 256K OCRAM +i.MX6DL - Dual core, 64-bit DDR800, 128K OCRAM +i.MX6S - Single core, 32-bit DDR800, 128K OCRAM + +These processors are also largely register-compatible, but not completely. +In particular, the IOMUX registers for common functions are in different +locations and have different selector values. + +The register addresses and values are consistent between the first +two processors in the list above (i.MX6DQ processors) and the second +two (i.MX6DLS for Dual-Lite/Solo). + +The i.MX6SL (Solo-Lite) processor is not pin compatible, so this +document does not describe support for that variant. + +Because of the pin-compatibility, a number of manufacturers produce +identical boards with BOM options for two or more of the processors. + +Similarly, identical boards are offered in a number of different +memory layouts, whether by partially populating the DRAM sockets +or by populating them with different densities of DDR. + +By following the conventions described in this document, a board +can support each of these options in a single boot image, and +decrease the overhead for managing images. + +Note that adding multi-arch support will add to the size of the +bootable image and slow the boot process slightly. If size and +speed are critical, a configuration-specific build can be produced +that removes this overhead. + +2. BOOT FLOW +------------ +The boot process for i.MX6 processors begins with execution of a first +level loader in the processor's internal ROM. This loader samples +boot pins and on-chip fuses to determine the source of the secondary +boot image. + +The boot image itself consists of a header (the DCD) which describes +the load address and payload (the U-Boot firmware). It also contains +a set of register/value pairs used to initialize the CPU prior +to execution of U-Boot. + +The boot image is produced in a final stage of the build process +by the imximage tool by processing a configuration (.cfg) file. + +In a single-architecture, single memory-layout image, the DCD +can include DDR memory initialization values and the load address +may be DDR directly. + +In order to support multiple processors, the DCD must contain +a load address for the i.MX6's internal RAM (OCRAM) because the +DDR memory speed (at least) will be dependent on the processor +variant. Thankfully, the DCD items needed to load this binary +are consistent between all of the processors. + +For this reason, support for SPL (secondary program loader) is +a requirement in order to support multiple architectures in the +same image. The SPL image will determine the processor variant +and memory configuration, configure the IOMUX controller and +DDR appropriately, then load either a full version of U-Boot +or an O/S. + +3. DDR configuration +-------------------- + +The DDR configuration data for single architecture boards is defined +within .cfg files in the various board directories. + +As of this writing, most boards use the structure defined in +board/boundary/nitrogen6x/ that separates the pieces of DCD +data according to function, with this general form: + + #include "ddr-setup.cfg" + #include "1066mhz_4x128mx16.cfg" + #include "clocks.cfg" + +Note that only the second of these is specific to the CPU +variant or memory-layout, and the multi-arch equivalent +can simply omit that for later initialization. + + #include "ddr-setup.cfg" + #include "clocks.cfg" + +In order to support the use of the memory configuration +files by both the SPL code and the imximage tool, the +memory configuration files (1066mhz_4x128mx16.cfg, et cetera) +have been converted to use the DCD_REG macro. + +In other words, this declaration in 1066mhz_4x128mx16.cfg + + DCD_REG(MX6_MMDC_P0_MDCFG0, 0x555A7974) + +will be turned into this by the preprocessor when +used by imximage: + + DATA 4, MX6_MMDC_P0_MDCFG0, 0x555A7974 + +and this when used to generate memory configuration tables +used by the SPL: + {MX6_MMDC_P0_MDCFG0, 0x555A7974}, + +3. IOMUX declarations +--------------------- + +The declarations inside the header files + arch/arm/include/asm/arch-mx6/mx6q_pins.h +and + arch/arm/include/asm/arch-mx6/mx6dl_pins.h + +are used to configure the pads usage for a particular +board design. + +As mentioned earlier, the register addresses and values +are different between the 6DQ and 6DLS processor sets, +and these differences are expressed in two header files: + +For i.MX6Q and i.MX6D: + arch/arm/include/asm/arch-mx6/mx6q_pins.h + +and for i.MX6DL and i.MX6S: + arch/arm/include/asm/arch-mx6/mx6dls_pins.h + +For example, the SD3_DAT2 pad is used for SD card data +on all currently supported i.MX6 boards. + +On i.MX6DQ, this is selected by writing a zero to the +mux register at address 0x020E02C8. On i.MX6DLS, the +address is 0x020E031C. + +The header files mx6q_pins.h and mx6dls_pins consolidate +the settings through a macro providing a common name +of SD3_DAT2__USDHC3_DAT2: + + MX6_PAD_DECL(SD3_DAT2__USDHC3_DAT2,...) + +By using the MX6_PAD_DECL macro, this can be expanded +in one of three ways, depending on the declarations of +CONFIG_MX6x by a board file. Valid options are: + + MX6Q - single architecture for i.MX6DQ + MX6DL - single architecture for i.MX6DL/S + MX6QDL - multi-architecture + +In the first two cases, the MX6_PAD_DECL macro will +be expanded into a declararation with the MX6_PAD_ +prefix: + MX6_PAD_name = IOMUX_PAD(...) + +In the last case, the MX6_PAD_DECL macro will be +expanded into two sets of declarations, with the +prefix MX6Q_PAD_ for the i.MX6DQ pads and the +prefix MX6DL_PAD_ for the i.MX6DLS pads. + +This is accomplished by the header file mx6-pins.h: + + #ifdef CONFIG_MX6QDL + enum { + #define MX6_PAD_DECL ... + #include "mx6q_pins.h" + + #define MX6_PAD_DECL ... + #include "mx6dl_pins.h" + }; + #elif defined(CONFIG_MX6Q) + enum { + #define MX6_PAD_DECL ... + #include "mx6q_pins.h" + }; + #elif defined(CONFIG_MX6DL) + enum { + #define MX6_PAD_DECL ... + #include "mx6dl_pins.h" + }; + #endif + +4. IOMUX usage in board files +----------------------------- + +The machinery described above is sufficient to allow a set of +pad registers to be defined for a specific architecture: + + static iomux_v3_cfg_t const mypads[] = { + MX6_PAD_x, + ... + }; + +or multiple architectures: + static iomux_v3_cfg_t const mx6q_pads[] = { + MX6Q_PAD_x, + ... + }; + + static iomux_v3_cfg_t const mx6dl_pads[] = { + MX6DL_PAD_x, + ... + }; + +In practice, 90% of the references to pads are in these +types of static arrays, and mostly separated by usage +(ethernet pads in a different array from UART pads). + +Going forward, it is recommended that these be consolidated +instead by architecture, such that all pads that apply to +both i.MX6DQ and i.MX6DLS architectures are defined in +"boardname-pads.h" with macros of this form: + MX6_PAD_DEF(PAD_REFERENCE) + +And that this file be included twice when being used in a +multi-architecture build. + +e.g. + static iomux_v3_cfg_t const mx6q_nitrogen_pads[] = { + #define MX6_PAD_DEF(PAD_DEF) MX6Q_PAD_#PAD_DEF, + #include "nitrogen6x-pads.h" + }; + static iomux_v3_cfg_t const mx6dl_nitrogen_pads[] = { + #define MX6_PAD_DEF(PAD_DEF) MX6DL_PAD_#PAD_DEF, + #include "nitrogen6x-pads.h" + }}; + +Doing this allows the bulk of the pads to be defined in a +single place. + +For pads that are specific to i.MX6DQ or i.MX6DLS, it is +recommended that they be defined directly in the board file. + +Finally, the convenience macro MX6REF(x) allows run-time +selection of a variable based on the CPU type on which +the reference is made: + + imx_iomux_v3_setup_multiple_pads( + MX6REF(nitrogen_pads), + ARRAY_SIZE(MX6REF(nitrogen_pads)) + ); + +N.B. This doesn't work, since ARRAY_SIZE can't be passed this +kind of reference... + -- 1.8.1.2

3 10

[U-Boot] mx28: disable DCDC-converter and use internal linear regulators
by Mårten Wikman 12 Nov '13

12 Nov '13

Hello, I'm having a problem with the internal DCDC-converter on a custom board. I'm now looking for a way to disable the internal DCDC-converter and use the internal regulators to power the CPU and memories. If I understand it correctly the pmu is configured in arch/arm/cpu/arm926ejs/mxs/spl_power_init.c. How do I disable the internal DCDC-converter and use internal linear regulator instead?

1 0

[U-Boot] [PATCH V2 0/6] Add support for SPI based DataImage LCD panel
by Nikita Kiryanov 12 Nov '13

12 Nov '13

This patch ports the Linux driver for DataImage SCF0403852GGU04 and SCF0403526GGU20 LCD panels into U-Boot. As a preparation step, variable SPI word length support is added to omap3_spi and the generic SPI interface. Finally, the driver is used in cm_t35 board. The SPI changes were tested with a Beagle I2C/SPI/MDIO Protocol Analyzer, and also with a DataImage SCF0403 lcd as part of the DataImage driver test. Patch number 6 depends on http://patchwork.ozlabs.org/patch/275283/ Cc: Tom Rini <trini(a)ti.com> Cc: Anatolij Gustschin <agust(a)denx.de> Cc: Igor Grinberg <grinberg(a)compulab.co.il> Cc: Jagannadha Sutradharudu Teki <jagannadh.teki(a)gmail.com> Changes in V2: - Rebased on top of latest U-Boot - New patches: 1) spi: omap3: remove semicolon from #define 2) spi: define SPI_XFER_ONCE 3) omap3_dss: define DSS_ONOFF 1 is a preliminary cleanup suggested by Gerhard Sittig and Igor Grinberg 2 and 3 are splitting off some new #defines to separate patches - Moved wordlen to generic spi_slave struct, and added generic implementation for spi_set_wordlen which only updates the struct without touching the hardware (Igor Grinberg) - Updated wordlen in hardware just before doing SPI transactions, not when changing wordlen (Igor Grinberg) - OMAP3 specific check of wordlen value from old implementation of spi_set_wordlen moved to xfer. It refines the more general check done in the new spi_set_wordlen. - Fixed comment style in spi.h following a rebase on top of latest U-Boot - Added SPDX-License-Identifier to all new files (Anatolij Gustschin) - s/printf/puts for not formatted strings in scf0403 driver (Anatolij Gustschin) - Do not fail scf0403 driver init if an invalid reset_gpio is given (Igor Grinberg) Nikita Kiryanov (6): spi: omap3: remove semicolon from #define spi: omap3: add support for more word lengths spi: define SPI_XFER_ONCE lcd: add DataImage SCF0403x LCD panel support omap3_dss: define DSS_ONOFF cm_t35: use scf0403 driver arch/arm/include/asm/arch-omap3/dss.h | 9 +- board/compulab/cm_t35/cm_t35.c | 12 ++ board/compulab/common/omap3_display.c | 46 +++++- drivers/spi/omap3_spi.c | 71 +++++--- drivers/spi/omap3_spi.h | 8 +- drivers/spi/spi.c | 13 ++ drivers/video/Makefile | 1 + drivers/video/scf0403_lcd.c | 296 ++++++++++++++++++++++++++++++++++ include/configs/cm_t35.h | 3 + include/scf0403_lcd.h | 11 ++ include/spi.h | 17 ++ 11 files changed, 456 insertions(+), 31 deletions(-) create mode 100644 drivers/video/scf0403_lcd.c create mode 100644 include/scf0403_lcd.h -- 1.8.1.2

3 18

[U-Boot] [PATCH 2/2] video: bcm2835: fix various output modes
by Andre Heider 12 Nov '13

12 Nov '13

Depending on the firmware's video options [1] the active SDTV or HDTV mode can yield a framebuffer with noncontiguous horizontal lines, giving a messed up display, for both, u-boot and the loaded kernel. To always archive the required contiguousness for the used 16bpp, round the framebuffer width down so its aligned to a width of 16. [1] http://elinux.org/RPiconfig#Video_mode_options Signed-off-by: Andre Heider <a.heider(a)gmail.com> --- drivers/video/bcm2835.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/video/bcm2835.c b/drivers/video/bcm2835.c index 58a6163..1404340 100644 --- a/drivers/video/bcm2835.c +++ b/drivers/video/bcm2835.c @@ -52,7 +52,7 @@ void lcd_ctrl_init(void *lcdbase) return; } - w = msg_query->physical_w_h.body.resp.width; + w = ROUND(msg_query->physical_w_h.body.resp.width, 16); h = msg_query->physical_w_h.body.resp.height; debug("bcm2835: Setting up display for %d x %d\n", w, h); -- 1.8.3.2

3 14

[U-Boot] How to build tools/imls ?
by Masahiro Yamada 12 Nov '13

12 Nov '13

Hello. I could not understand where tools/imls/Makefile is invoked from. (I grepped the top Makefile with "imls" but no hit.) So, I treaked as follows to add imls entry point: --- a/Makefile +++ b/Makefile @@ -773,7 +773,7 @@ $(TIMESTAMP_FILE): @LC_ALL=C date +'#define U_BOOT_TIME "%T"' >> $@.tmp @cmp -s $@ $@.tmp && rm -f $@.tmp || mv -f $@.tmp $@ -easylogo env gdb: +easylogo env gdb imls: $(MAKE) -C tools/$@ all MTD_VERSION=${MTD_VERSION} gdbtools: gdb And I tried "make imls". But I still had a error like follows: tools/imls/imls.c:17:22: fatal error: asm/page.h: No such file or directory #include <asm/page.h> ^ compilation terminated. make[1]: *** [imls.o] Error 1 It seems already to be broken. Anybody would mind if I deleted "tools/imls" ? Anybody use this tool? Best Regards Masahiro Yamada

1 0

[U-Boot] How to build tools/updater ?
by Masahiro Yamada 12 Nov '13

12 Nov '13

Hello all. Anybody knows if tools/updater is used? I tried "make updater" but I got following error. gcc -M -g -Os -D__KERNEL__ -DCONFIG_SYS_TEXT_BASE=0 -I/home/yamada/workspace/arm-linux-pf/u-boot/include -I/home/yamada/workspace/arm-linux-pf/u-boot/arch/sandbox/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/lib/gcc/x86_64-linux-gnu/4.8/include -pipe -DCONFIG_SANDBOX -D__SANDBOX__ -U_FORTIFY_SOURCE -DCONFIG_ARCH_MAP_SYSMEM -DCONFIG_SYS_GENERIC_BOARD -I/home/yamada/workspace/arm-linux-pf/u-boot -I/home/yamada/workspace/arm-linux-pf/u-boot/board/MAI/AmigaOneG3SE -MQ flash_hw.o flash_hw.c >.depend.flash_hw flash_hw.c:14:19: fatal error: memio.h: No such file or directory #include <memio.h> ^ compilation terminated. make[1]: *** No rule to make target `.depend', needed by `all'. Stop. Best Regards Masahiro Yamada

1 0

[U-Boot] [PATCH v1] patman: add Series-commit-notes tag and section
by Albert ARIBAUD 12 Nov '13

12 Nov '13

Sometimes a commit should have notes enclosed with it rather than withing the cover letter -- possibly even because there is no cover letter. Add 'Series-commit-notes' tag, similar to 'Series-notes'; lines between this tag and the next END line are inserted in the patch right after the '---' separator line. Signed-off-by: Albert ARIBAUD <albert.u.boot(a)aribaud.net> --- tools/patman/commit.py | 2 ++ tools/patman/patchstream.py | 7 +++++-- tools/patman/series.py | 2 +- 3 files changed, 8 insertions(+), 3 deletions(-) diff --git a/tools/patman/commit.py b/tools/patman/commit.py index 900cfb3..89cce7f 100644 --- a/tools/patman/commit.py +++ b/tools/patman/commit.py @@ -21,6 +21,7 @@ class Commit: changes: Dict containing a list of changes (single line strings). The dict is indexed by change version (an integer) cc_list: List of people to aliases/emails to cc on this commit + notes: List of lines in the commit (not series) notes """ def __init__(self, hash): self.hash = hash @@ -28,6 +29,7 @@ class Commit: self.tags = [] self.changes = {} self.cc_list = [] + self.notes = [] def AddChange(self, version, info): """Add a new change line to the change list for a version. diff --git a/tools/patman/patchstream.py b/tools/patman/patchstream.py index c204523..4c20144 100644 --- a/tools/patman/patchstream.py +++ b/tools/patman/patchstream.py @@ -84,7 +84,7 @@ class PatchStream: name: Tag name (part after 'Series-') value: Tag value (part after 'Series-xxx: ') """ - if name == 'notes': + if (name == 'notes' or name == 'commit-notes'): self.in_section = name self.skip_blank = False if self.is_log: @@ -165,6 +165,9 @@ class PatchStream: elif self.in_section == 'notes': if self.is_log: self.series.notes += self.section + elif self.in_section == 'commit-notes': + if self.is_log: + self.commit.notes += self.section else: self.warn.append("Unknown section '%s'" % self.in_section) self.in_section = None @@ -276,7 +279,7 @@ class PatchStream: out = [] log = self.series.MakeChangeLog(self.commit) out += self.FormatTags(self.tags) - out += [line] + log + out += [line] + self.commit.notes + [''] + log elif self.found_test: if not re_allowed_after_test.match(line): self.lines_after_test += 1 diff --git a/tools/patman/series.py b/tools/patman/series.py index 88c0d87..5eeb452 100644 --- a/tools/patman/series.py +++ b/tools/patman/series.py @@ -12,7 +12,7 @@ import terminal # Series-xxx tags that we understand valid_series = ['to', 'cc', 'version', 'changes', 'prefix', 'notes', 'name', - 'cover-cc', 'process_log'] + 'cover-cc', 'process_log', 'commit_notes'] class Series(dict): """Holds information about a patch series, including all tags. -- 1.8.3.2

3 2

[U-Boot] MPC8641D stucks before relocation
by Ashish Khetan 12 Nov '13

12 Nov '13

hii I am using MPC8641D based custom board for evaluation purpose. I am using minimal configuration for this board i.e. only FLASH and DDR initialisation. when I compiled U-boot in debug mode its printing addresses, i check for those addresses and found that it is unable to relocate itself to DDR(4*MT47H64M16). The following message was printed... U-Boot 2013.04 (Oct 25 2013 - 15:05:33) Unicore software on multiprocessor system!! To enable mutlticore build define CONFIG_MP CPU: 8641, Version: 2.1, (0x80900021) Core: E600 Core 0 (MSSCR0=8000, PORDEVSR=ab08307), Version: 2.2, (0x80040202) Clock Configuration: CPU:800 MHz, MPX:400 MHz DDR:200 MHz (400 MT/s data rate), LBC:25 MHz L1: D-cache 32 KB enabled I-cache 32 KB enabled L2: Disabled Board: Wind River SBC8641D DRAM: DDR: 512 MiB Top of RAM usable for U-Boot at: 20000000 Reserving 114k for U-Boot at: 1ffe3000 Reserving 136k for malloc() at: 1ffc1000 Reserving 80 Bytes for Board Info at: 1ffc0fb0 Reserving 152 Bytes for Global Data at: 1ffc0f18 Stack Pointer at: 1ffc0f00 New Stack Pointer is: 1ffc0f00 and stuck here... Any pointer or link to get more about this will be helpful. Thanks in Advance

3 6