November 2013 - U-Boot

[U-Boot] [PATCH 1/3 v5] arm: rmobile: Move lowlevel_init.o to taget of each CPU
by Nobuhiro Iwamatsu 21 Nov '13

21 Nov '13

From: Nobuhiro Iwamatsu <iwamatsu(a)nigauri.org> Signed-off-by: Nobuhiro Iwamatsu <iwamatsu(a)nigauri.org> --- v5: add this patch. arch/arm/cpu/armv7/rmobile/Makefile | 9 +++------ 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/arch/arm/cpu/armv7/rmobile/Makefile b/arch/arm/cpu/armv7/rmobile/Makefile index 5e296c4..d6ae11e 100644 --- a/arch/arm/cpu/armv7/rmobile/Makefile +++ b/arch/arm/cpu/armv7/rmobile/Makefile @@ -5,14 +5,11 @@ # SPDX-License-Identifier: GPL-2.0+ # -obj-y = lowlevel_init.o -obj-y += cpu_info.o +obj-y = cpu_info.o obj-y += emac.o obj-$(CONFIG_DISPLAY_BOARDINFO) += board.o obj-$(CONFIG_GLOBAL_TIMER) += timer.o -obj-$(CONFIG_R8A7740) += cpu_info-r8a7740.o -obj-$(CONFIG_R8A7740) += pfc-r8a7740.o -obj-$(CONFIG_SH73A0) += cpu_info-sh73a0.o -obj-$(CONFIG_SH73A0) += pfc-sh73a0.o +obj-$(CONFIG_R8A7740) += lowlevel_init.o cpu_info-r8a7740.o pfc-r8a7740.o +obj-$(CONFIG_SH73A0) += lowlevel_init.o cpu_info-sh73a0.o pfc-sh73a0.o obj-$(CONFIG_TMU_TIMER) += ../../../../sh/lib/time.o -- 1.8.4.3

1 2

[U-Boot] [PATCH v11 0/4] mtd: nand: omap: optimize and clean-up of OMAP NAND driver
by Pekon Gupta 21 Nov '13

21 Nov '13

*changes in v11* [PATCH 2/4] fixed 'unused variable' warning *changes in v10* [PATCH 1/4] re-generated patche using 'git format-patch -M -C' to detect renames [PATCH 2/4] removed #ifdef while including omap_elm.h header in omap_gpmc.c [PATCH 3/4] and [PATCH 4/4] <no update> *changes in v9* (Important) As this patch series was becoming bulky and had many un-related patches, so it has been split into two parts. Part-1: Current patch series focuses on cleaning up GPMC and ELM drivers maintaining existing functionality. And update ecc-scheme selection mechanism across all platforms. Part-2: Next patch series will focus on optimizing data-paths of GPMC and ELM drivers for better performance and scalability. This Part-1 series has following patches, maintaining earlier feedbacks. [PATCH 1/4] [NEW] mtd: nand: omap: make am33xx/elm.c as common driver - move ELM driver source to drivers/mtd/nand/ to reuse driver on all platforms [PATCH 2/4] [SPLIT] mtd: nand: omap: enable BCH ECC scheme using ELM for ... v8 version of this patch is split into follwing part maintaining earlier feedbacks. - [PATCH 2/4] handles ecc-scheme selection clean-up - [PATCH 3/4] add CONFIG_NAND_OMAP_ECCSCHEME [PATCH 3/4] [NEW] mtd: nand: omap: add CONFIG_NAND_OMAP_ECCSCHEME ... - split from previous patch to introduce new CONFIG_xx for having common method of ecc-scheme selection across all platforms. - updated include/configs/ for SoC platforms (like OMAP3) which use omap_gpmc.c [PATCH 4/4] [NEW] am335x: fix GPMC config for NAND and NOR SPL boot - clean separation of NOR Boot and NAND Boot configurations - configuration of GPMC registers moved to arch/am33xx from board/ti/am335x/board.c, so that its re-usable for other boards also. This patch is tested on beagle-bone (white) with NAND cape, using following (a) Patch to add beaglebone pin-mux support http://lists.denx.de/pipermail/u-boot/2013-September/163881.html (b) Hack in board-file to configure GPMC for x16 device -------------- diff --git a/arch/arm/cpu/armv7/am33xx/mem.c b/arch/arm/cpu/armv7/am33xx/mem.c index 56c9e7d..b166a94 100644 --- a/arch/arm/cpu/armv7/am33xx/mem.c +++ b/arch/arm/cpu/armv7/am33xx/mem.c @@ -64,7 +64,7 @@ void gpmc_init(void) u32 base = CONFIG_SYS_FLASH_BASE; #elif defined(CONFIG_NAND) /* configure GPMC for NAND */ - const u32 gpmc_regs[GPMC_MAX_REG] = { M_NAND_GPMC_CONFIG1, + const u32 gpmc_regs[GPMC_MAX_REG] = { M_NAND_GPMC_CONFIG1 | 0x1000, M_NAND_GPMC_CONFIG2, M_NAND_GPMC_CONFIG3, M_NAND_GPMC_CONFIG4, -------------- *changes in v8* [PATCH] mtd: nand: omap: enable BCH ECC scheme using ELM for generic platform - incorporated following feedbacks from Scott Wood <scottwood(a)freescale.com> - using symbolic names (enums) as values of CONFIG_NAND_OMAP_ECCSCHEME - updated omap_select_ecc_scheme(): perform ecc-scheme compatibility checks before updating nand_chip.ecc fields. This avoids corrupting of existing ecc-scheme in case of switching failures. - code clean-up (removed fall-back on omap_select_ecc_scheme() failures) *changes in v7* [PATCH] mtd: nand: omap: enable BCH ECC scheme using ELM for generic platform - omap_gpmc.c: fix: free bytes in OOB (ecclayout->oobfree[0].length) - omap_gpmc.c: cleanup: redundant code added in previous patch versions - am335x_evm.h: cleanup: redundant code added in previous patch versions - tricorder.h: fix: CONFIG_NAND_OMAP_ECCSCHEME *changes in v6* [PATCH] mtd: nand: omap: enable BCH ECC scheme using ELM for generic platform - incorporated feedbacks from Scott Wood <scottwood(a)freescale.com> - renamed CONFIG_SYS_NAND_ECCSCHEME to CONFIG_NAND_OMAP_ECCSCHEME - updated omap_select_ecc_scheme() to handle error conditions without depending on caller. - renamed OMAP_ECC_HAM1_CODE_HW_ROMCODE to OMAP_ECC_HAM1_CODE_HW to keep it naming compatible to linux kernel - updated doc/README.nand and doc/README.omap3 - moved CONFIG_NAND_OMAP_ECCSCHEME description to README.nand *changes in v5* This version of patch is tested on am335x-evm with x8 NAND device, and boots SPL and u-boot from NAND [PATCH] mtd: nand: omap: enable BCH ECC scheme using ELM for generic platform - re-added omap_read_page_bch(): needed proper sequence of while reading DATA and ECC from NAND page, so that calc_ecc generated from GPMC is understood by ELM. - added check to see if NAND OOB can accomodate ECC for entire page *changes in v4* [PATCH] mtd: nand: omap: enable BCH ECC scheme using ELM for generic platform - removed omap_read_page_bch(): chip->ecc.read_page uses default API nand_read_page_hwecc() in nand_base.c - updated tricorder.h: added new CONFIGS for ECCSCHEME & ONFI_DETECTION - converted printf("ECC-SCHEME") to debug("ECC-SCHEME") *changes in v3* [PATCH] mtd: nand: omap: enable BCH ECC scheme using ELM for generic platform (complete re-work) - ecc-scheme is selection is controller by s/w, not CONFIG_NAND_xx - added omap_select_ecc_scheme(), as common function to handle all ecc-scheme related configurations for both board_nand_init() & omap_nand_switch_ecc(). - removed un-used defines from asm/arch-am33xx/omap_gpmc.h - updated doc/REAME.nand - removed un-used defines from asm/omap_gpmc.h *changes in v2* - added documentation for CONFIG_NAND_OMAP_xx in doc/README.nand - added CONFIG_BCH along with CONFIG_NAND_OMAP_ECC_BCH8_CODE_HW_DETECTION_SW to include software library lib/bch.c - fixed board_nand_init() and omap_enable_hwecc() *original v1* This patch series updates BCH8_ECC schemes in mtd/nand/omap_gpmc.c driver - adds scalability for higher ECC schemes in future. - removes CONFIG_AM335x and it makes it generic for all platforms. - optimizes read_data paths Pekon Gupta (4): mtd: nand: omap: make am33xx/elm.c as common driver for all OMAPx and AMxxxx platforms mtd: nand: omap: enable BCH ECC scheme using ELM for generic platform mtd: nand: omap: add CONFIG_NAND_OMAP_ECCSCHEME for selection of ecc-scheme am335x: fix GPMC config for NAND and NOR SPL boot arch/arm/cpu/armv7/am33xx/Makefile | 1 - arch/arm/cpu/armv7/am33xx/mem.c | 52 ++-- arch/arm/include/asm/arch-am33xx/mem.h | 5 - .../include/asm/{arch-am33xx/elm.h => omap_elm.h} | 0 arch/arm/include/asm/omap_gpmc.h | 16 + board/ti/am335x/board.c | 14 +- doc/README.nand | 53 ++++ doc/README.omap3 | 3 +- drivers/mtd/nand/Makefile | 1 + .../am33xx/elm.c => drivers/mtd/nand/omap_elm.c | 6 +- drivers/mtd/nand/omap_gpmc.c | 321 +++++++++++++-------- include/configs/am335x_evm.h | 5 +- include/configs/am335x_igep0033.h | 2 + include/configs/am3517_crane.h | 1 + include/configs/am3517_evm.h | 1 + include/configs/devkit8000.h | 1 + include/configs/mcx.h | 2 +- include/configs/omap3_beagle.h | 1 + include/configs/omap3_evm.h | 1 + include/configs/omap3_evm_quick_nand.h | 1 + include/configs/omap3_igep00x0.h | 1 + include/configs/omap3_overo.h | 1 + include/configs/siemens-am33x-common.h | 2 + include/configs/tam3517-common.h | 2 +- include/configs/tricorder.h | 2 +- 25 files changed, 319 insertions(+), 176 deletions(-) rename arch/arm/include/asm/{arch-am33xx/elm.h => omap_elm.h} (100%) rename arch/arm/cpu/armv7/am33xx/elm.c => drivers/mtd/nand/omap_elm.c (97%) -- 1.8.1

3 6

[U-Boot] [PATCH v10 0/4] mtd: nand: omap: optimize and clean-up of OMAP NAND driver
by Pekon Gupta 21 Nov '13

21 Nov '13

*changes in v10* [PATCH 1/4] re-generated patche using 'git format-patch -M -C' to detect renames [PATCH 2/4] removed #ifdef while including omap_elm.h header in omap_gpmc.c [PATCH 3/4] and [PATCH 4/4] <no update> *changes in v9* (Important) As this patch series was becoming bulky and had many un-related patches, so it has been split into two parts. Part-1: Current patch series focuses on cleaning up GPMC and ELM drivers maintaining existing functionality. And update ecc-scheme selection mechanism across all platforms. Part-2: Next patch series will focus on optimizing data-paths of GPMC and ELM drivers for better performance and scalability. This Part-1 series has following patches, maintaining earlier feedbacks. [PATCH 1/4] [NEW] mtd: nand: omap: make am33xx/elm.c as common driver - move ELM driver source to drivers/mtd/nand/ to reuse driver on all platforms [PATCH 2/4] [SPLIT] mtd: nand: omap: enable BCH ECC scheme using ELM for ... v8 version of this patch is split into follwing part maintaining earlier feedbacks. - [PATCH 2/4] handles ecc-scheme selection clean-up - [PATCH 3/4] add CONFIG_NAND_OMAP_ECCSCHEME [PATCH 3/4] [NEW] mtd: nand: omap: add CONFIG_NAND_OMAP_ECCSCHEME ... - split from previous patch to introduce new CONFIG_xx for having common method of ecc-scheme selection across all platforms. - updated include/configs/ for SoC platforms (like OMAP3) which use omap_gpmc.c [PATCH 4/4] [NEW] am335x: fix GPMC config for NAND and NOR SPL boot - clean separation of NOR Boot and NAND Boot configurations - configuration of GPMC registers moved to arch/am33xx from board/ti/am335x/board.c, so that its re-usable for other boards also. This patch is tested on beagle-bone (white) with NAND cape, using following (a) Patch to add beaglebone pin-mux support http://lists.denx.de/pipermail/u-boot/2013-September/163881.html (b) Hack in board-file to configure GPMC for x16 device -------------- diff --git a/arch/arm/cpu/armv7/am33xx/mem.c b/arch/arm/cpu/armv7/am33xx/mem.c index 56c9e7d..b166a94 100644 --- a/arch/arm/cpu/armv7/am33xx/mem.c +++ b/arch/arm/cpu/armv7/am33xx/mem.c @@ -64,7 +64,7 @@ void gpmc_init(void) u32 base = CONFIG_SYS_FLASH_BASE; #elif defined(CONFIG_NAND) /* configure GPMC for NAND */ - const u32 gpmc_regs[GPMC_MAX_REG] = { M_NAND_GPMC_CONFIG1, + const u32 gpmc_regs[GPMC_MAX_REG] = { M_NAND_GPMC_CONFIG1 | 0x1000, M_NAND_GPMC_CONFIG2, M_NAND_GPMC_CONFIG3, M_NAND_GPMC_CONFIG4, -------------- *changes in v8* [PATCH] mtd: nand: omap: enable BCH ECC scheme using ELM for generic platform - incorporated following feedbacks from Scott Wood <scottwood(a)freescale.com> - using symbolic names (enums) as values of CONFIG_NAND_OMAP_ECCSCHEME - updated omap_select_ecc_scheme(): perform ecc-scheme compatibility checks before updating nand_chip.ecc fields. This avoids corrupting of existing ecc-scheme in case of switching failures. - code clean-up (removed fall-back on omap_select_ecc_scheme() failures) *changes in v7* [PATCH] mtd: nand: omap: enable BCH ECC scheme using ELM for generic platform - omap_gpmc.c: fix: free bytes in OOB (ecclayout->oobfree[0].length) - omap_gpmc.c: cleanup: redundant code added in previous patch versions - am335x_evm.h: cleanup: redundant code added in previous patch versions - tricorder.h: fix: CONFIG_NAND_OMAP_ECCSCHEME *changes in v6* [PATCH] mtd: nand: omap: enable BCH ECC scheme using ELM for generic platform - incorporated feedbacks from Scott Wood <scottwood(a)freescale.com> - renamed CONFIG_SYS_NAND_ECCSCHEME to CONFIG_NAND_OMAP_ECCSCHEME - updated omap_select_ecc_scheme() to handle error conditions without depending on caller. - renamed OMAP_ECC_HAM1_CODE_HW_ROMCODE to OMAP_ECC_HAM1_CODE_HW to keep it naming compatible to linux kernel - updated doc/README.nand and doc/README.omap3 - moved CONFIG_NAND_OMAP_ECCSCHEME description to README.nand *changes in v5* This version of patch is tested on am335x-evm with x8 NAND device, and boots SPL and u-boot from NAND [PATCH] mtd: nand: omap: enable BCH ECC scheme using ELM for generic platform - re-added omap_read_page_bch(): needed proper sequence of while reading DATA and ECC from NAND page, so that calc_ecc generated from GPMC is understood by ELM. - added check to see if NAND OOB can accomodate ECC for entire page *changes in v4* [PATCH] mtd: nand: omap: enable BCH ECC scheme using ELM for generic platform - removed omap_read_page_bch(): chip->ecc.read_page uses default API nand_read_page_hwecc() in nand_base.c - updated tricorder.h: added new CONFIGS for ECCSCHEME & ONFI_DETECTION - converted printf("ECC-SCHEME") to debug("ECC-SCHEME") *changes in v3* [PATCH] mtd: nand: omap: enable BCH ECC scheme using ELM for generic platform (complete re-work) - ecc-scheme is selection is controller by s/w, not CONFIG_NAND_xx - added omap_select_ecc_scheme(), as common function to handle all ecc-scheme related configurations for both board_nand_init() & omap_nand_switch_ecc(). - removed un-used defines from asm/arch-am33xx/omap_gpmc.h - updated doc/REAME.nand - removed un-used defines from asm/omap_gpmc.h *changes in v2* - added documentation for CONFIG_NAND_OMAP_xx in doc/README.nand - added CONFIG_BCH along with CONFIG_NAND_OMAP_ECC_BCH8_CODE_HW_DETECTION_SW to include software library lib/bch.c - fixed board_nand_init() and omap_enable_hwecc() *original v1* This patch series updates BCH8_ECC schemes in mtd/nand/omap_gpmc.c driver - adds scalability for higher ECC schemes in future. - removes CONFIG_AM335x and it makes it generic for all platforms. - optimizes read_data paths Pekon Gupta (4): mtd: nand: omap: make am33xx/elm.c as common driver for all OMAPx and AMxxxx platforms mtd: nand: omap: enable BCH ECC scheme using ELM for generic platform mtd: nand: omap: add CONFIG_NAND_OMAP_ECCSCHEME for selection of ecc-scheme am335x: fix GPMC config for NAND and NOR SPL boot arch/arm/cpu/armv7/am33xx/Makefile | 1 - arch/arm/cpu/armv7/am33xx/mem.c | 52 ++-- arch/arm/include/asm/arch-am33xx/mem.h | 5 - .../include/asm/{arch-am33xx/elm.h => omap_elm.h} | 0 arch/arm/include/asm/omap_gpmc.h | 16 + board/ti/am335x/board.c | 14 +- doc/README.nand | 53 ++++ doc/README.omap3 | 3 +- drivers/mtd/nand/Makefile | 1 + .../am33xx/elm.c => drivers/mtd/nand/omap_elm.c | 6 +- drivers/mtd/nand/omap_gpmc.c | 323 +++++++++++++-------- include/configs/am335x_evm.h | 5 +- include/configs/am335x_igep0033.h | 2 + include/configs/am3517_crane.h | 1 + include/configs/am3517_evm.h | 1 + include/configs/devkit8000.h | 1 + include/configs/mcx.h | 2 +- include/configs/omap3_beagle.h | 1 + include/configs/omap3_evm.h | 1 + include/configs/omap3_evm_quick_nand.h | 1 + include/configs/omap3_igep00x0.h | 1 + include/configs/omap3_overo.h | 1 + include/configs/siemens-am33x-common.h | 2 + include/configs/tam3517-common.h | 2 +- include/configs/tricorder.h | 2 +- 25 files changed, 321 insertions(+), 176 deletions(-) rename arch/arm/include/asm/{arch-am33xx/elm.h => omap_elm.h} (100%) rename arch/arm/cpu/armv7/am33xx/elm.c => drivers/mtd/nand/omap_elm.c (97%) -- 1.8.1

5 10

[U-Boot] i2c issues with efikamx and mainline uboot
by Konstantinos Margaritis 21 Nov '13

21 Nov '13

(Disclaimer: u-boot newbie) Hi all, With Marek's huge help (thanks Marek!) I've tried to merge his tree [1] that provides lcd support for the efikamx/efikasb with recent mainline uboot. It boots, but I've hit some wall now and couldn't get passed it, so I thought I'd ask for some expert advice, Marek suggested I mail here and CC himself and Stefano as well. So, I've migrated the structures to the iomux v3 coding conventions, added some missing defines for iomuxes used, etc. I've forked the code in github [2] and am doing all the changes there, in the hope that I can at some point submit it back to mainline. I also want to to enable multi-host USB support for the platform so that tftp booting will be at last possible, but that's going to happen later, I want to be done with LCD first. The result boots, but in short it fails to initialise the LCD (for the efikamx, didn't test efikasb yet). I noticed that amongst many changes, in drivers/i2c/mxc_i2c.c, i2c_imx_bus_busy() in Marek's tree () got sort of replaced with wait_for_sr_state(), which does the same thing but is more generic -or so I understand, please correct me if I'm wrong in my interpretation. So what's the problem? Well, I2CR_MSTA (master mode) is set, but I2SR_IBB fails to get set. In every case I get this result in the I2SR register: I2SR = 81 -> I2SR_ICF | I2SR_RX_NO_AK, ie. which according to the iMX515 Reference Manual corresponds to: "Transfer is complete, and set by the falling edge of the ninth clock of a byte transfer." + "A “No acknowledge” signal was detected at the ninth clock." so a previous answer didn't send an acknowledge or rather the opposite it sent a NACK. I'm at a loss here, attaching a boot log where I added some printfs around. I'd appreciate any pointer as to what I'm doing wrong. Thanks Konstantinos [1] git://git.denx.de/u-boot-marex.git branch: efikasb2 [2] https://github.com/markos/u-boot branch: efikamx

4 5

[U-Boot] [RESEND PATCH] imx: Easy enabling of SION per-pin using MUX_MODE_SION helper macro
by Otavio Salvador 21 Nov '13

21 Nov '13

The macro allows easy setting in per-pin, as for example: ,---- | imx_iomux_v3_setup_pad(MX6_PAD_NANDF_D1__GPIO_2_1 | MUX_MODE_SION); `---- The IOMUX_CONFIG_SION allows for reading PAD value from PSR register. The following quote from the datasheet: ,---- | ... | 28.4.2.2 GPIO Write Mode | The programming sequence for driving output signals should be as follows: | 1. Configure IOMUX to select GPIO mode (Via IOMUXC), also enable SION if need | to read loopback pad value through PSR | 2. Configure GPIO direction register to output (GPIO_GDIR[GDIR] set to 1b). | 3. Write value to data register (GPIO_DR). | ... `---- This fixes the gpio_get_value to properly work when a GPIO is set for output and has no conflicts. Thanks for Benoît Thébaudeau <benoit.thebaudeau(a)advansee.com>, Fabio Estevam <fabio.estevam(a)freescale.com> and Eric Bénard <eric(a)eukrea.com> for helping to properly trace this down. Signed-off-by: Otavio Salvador <otavio(a)ossystems.com.br> --- arch/arm/include/asm/imx-common/iomux-v3.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/include/asm/imx-common/iomux-v3.h b/arch/arm/include/asm/imx-common/iomux-v3.h index dc2b3ef..dec11a1 100644 --- a/arch/arm/include/asm/imx-common/iomux-v3.h +++ b/arch/arm/include/asm/imx-common/iomux-v3.h @@ -63,6 +63,8 @@ typedef u64 iomux_v3_cfg_t; #define MUX_SEL_INPUT_SHIFT 59 #define MUX_SEL_INPUT_MASK ((iomux_v3_cfg_t)0xf << MUX_SEL_INPUT_SHIFT) +#define MUX_MODE_SION ((iomux_v3_cfg_t)IOMUX_CONFIG_SION << \ + MUX_MODE_SHIFT) #define MUX_PAD_CTRL(x) ((iomux_v3_cfg_t)(x) << MUX_PAD_CTRL_SHIFT) #define IOMUX_PAD(pad_ctrl_ofs, mux_ctrl_ofs, mux_mode, sel_input_ofs, \ -- 1.8.4.rc3

2 1

[U-Boot] u-boot gerrit server
by Vadim Bendebury (вб) 20 Nov '13

20 Nov '13

Gentlemen, I have not forgotten our discussion regarding setting up a sample gerrit server for u-boot during the ELCE mini-summit. Sorry for this long and not very clear email, if there is any interest I will be glad to answer questions and address concerns to the best of my ability, and I am sure Simon (sjg@) will pitch in. Gerrit is used for many different projects now, I spoke with coreboot maintainer who moved their process from email to gerrit - he said it involved a certain threshold effort, but after that the entire community was extremely pleased with the result - none of the patches were lost in more than a year after the transition. Of course coreboot is a much smaller project than u-boot, but both Android and Chrome OS also successfully use gerrit. You can now see the sample u-boot gerrit server at https://u-boot-review.googlesource.com/#/q/status:open,n,z which is a code review interface to the actual gerrit based git server at u-boot.googlesource.com, which in turn is a mirror of the denx u-boot git reporsitory. This particular gerrit server runs on Google infrastructure, replicated in three different datacenters across the world, each having a 10GB/s uplink, with 99.999 reliability. But of course it could be set up on a dedicated server anywhere. There is plenty of documentation available (just click on the 'Documentation' link in the top of the page). I will try to give just a brief description. For the purposes of this demo the patches submitted for review were generated by a script I wrote. The script scrapes http://patchwork.ozlabs.org/project/uboot/list/, downloads the patches from there and tries applying them. Not all patches apply cleanly (as some of them are for branches). If the patch applies cleanly, the script adds two stanzas to the patch description - Change-Id: generated by git - Patch-At: a reference to the patchwork page where the patch was downloaded from and uploads the patch for review as the user named 'Gerrit Tester'. Each upload creates a new git branch just for review purposes. Change-Id is required by gerrit as a universally unique identifier, which will allow to group together multiple versions of the same patch. When the patch with a known Change-ID is uploaded, the review server creates a revision and allows to see the differences between the revisions. Local modifications required to have git generate the Change-Id: stanza are described in https://gerrit-review.googlesource.com/Documentation/user-upload.html Any one can upload patches to this server after creating an account on it. Any Google account will do, or if you don't want to have a Google based email you can create the account using your existing email. Follow the prompts after clicking on 'Sign in' link on the top right. After signing up one should create a password for authentication with the server. Click on the little black triangle next to your name in the top right, then on 'Settings' and then on 'HTTP Password'. Save the lines generated by this in ~/.netrc (with permissions set to 0400) and you are good to go. Now clone the repository using git clone https://u-boot.googlesource.com/u-boot (or just add it as a remote to your existing u-boot tree) and now you can upload patches using git push https://u-boot.googlesource.com/u-boot HEAD:refs/for/master === How review process works ==== For an example comment/modification upload cycle I picked this change: https://u-boot-review.googlesource.com/#/c/1146 Say the comment was that the definition in line 419 on https://u-boot-review.googlesource.com/#/c/1146/1/common/console.c shoudl use #if defined() instead of #ifdef The reviewer double clicks on the line where he wants to leave a comment, a form opens, where the reviewer adds the comment. Then he submits the form, and the comment gets associated with the line. Once all comments are added, they can be published. As a result the author, all other reviewers and any configured mailing list receive the comments in the email: vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv Vadim Bendebury has posted comments on this change. Change subject: sandbox: Allow the console to work earlier ...................................................................... Patch Set 1: (1 comment) https://u-boot-review.googlesource.com/#/c/1146/1/common/console.c File common/console.c: Line 419: #ifdef CONFIG_SANDBOX could this be #if defined() instead? ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Let's say at this point the author can reply to the comment using the same web interface, and make a modification. After that git commit --amend -s will ensure that the new patch keeps the old Change-ID. After the change has been committed, it can be uploaded: vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv $ git push https://u-boot.googlesource.com/u-boot HEAD:refs/for/master remote: Resolving deltas: 100% (8/8) remote: Processing changes: updated: 1, done remote: (W) ae78aca: commit message lines >70 characters; manually wrap lines remote: remote: Updated Changes: remote: https://u-boot-review.googlesource.com/1146 remote: To https://u-boot.googlesource.com/u-boot * [new branch] HEAD -> refs/for/master $ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Now one can see two patch sets on this patch's page: https://u-boot-review.googlesource.com/#/c/1141/ Once the change has been reviewed and agreed upon, the custodian could cherry pick its latest version and submit to the master repository. In the most usual case the gerrit server would be that master repository - in that case all the custodian needs to do is to clikc on the 'publish' button. This server is not configured yet, but in general gerrit allows for three levels of reviewers - those who can just comment, those who can assign a +1 rating to the change (an equivalent of an acked by) and those who can assign a +2 rating or push the change (the custodians). There is no point in setting these up on a mirror, but if so desired, it could be done. I encourage any one to give this a try, try playing with it, upload patches, try commenting, sending reviews, upload new patch versions, etc. >From what I can see looking at other projects, is this is adopted, the quality of and productivity of custodians/maintainers goes way up. --vb

14 68

[U-Boot] Strange UBI problems
by Gary Thomas 20 Nov '13

20 Nov '13

I'm building U-Boot from the FSLC (repo/fork) on an i.MX6 U-Boot 2013.10-00012-g5bc3118-dirty (Nov 19 2013 - 09:17:18) CPU: Freescale i.MX6SOLO rev1.1 at 792 MHz After I made a small change today in the NAND FLASH layout, I can no longer use UBI from U-Boot. Here's what I see today: MyBoard > mtdparts default MyBoard > mtdparts device nand0 <gpmi-nand>, # parts = 4 #: name size offset mask_flags 0: boot 0x001e0000 0x00000000 0 1: env 0x00020000 0x001e0000 0 2: linux 0x00f00000 0x00200000 0 3: fs 0x06f00000 0x01100000 0 active partition: nand0,0 - (boot) 0x001e0000 @ 0x00000000 defaults: mtdids : nand0=gpmi-nand mtdparts: mtdparts=gpmi-nand:1920k(boot),128k(env),15m(linux),-(fs) MyBoard > ubi part linux UBI: attaching mtd1 to ubi0 UBI: physical eraseblock size: 131072 bytes (128 KiB) UBI: logical eraseblock size: 126976 bytes UBI: smallest flash I/O unit: 2048 UBI: VID header offset: 2048 (aligned 2048) UBI: data offset: 4096 UBI error: ubi_read_volume_table: the layout volume was not found UBI error: ubi_init: cannot attach mtd1 UBI error: ubi_init: UBI error: cannot initialize UBI, error -22 UBI init error 22 Notice that when I try to access the 'linux' partition, it's trying to use mtd1 (env). In fact, it doesn't seem to matter at all what partition I try to access, it always wants to use mtd1. Today, I changed the MTD layout from mtdparts=gpmi-nand:896k(boot),128k(env),15m(linux),-(fs) to mtdparts=gpmi-nand:1920k(boot),128k(env),15m(linux),-(fs) I then rebuilt my Linux and reinstalled the partition. Linux is totally happy with this new layout, but U-Boot doesn't like it at all. Just to make sure I have this right, I just restored the previous layout and everything works as expected. What am I missing? Why is UBI not working with this layout? Thanks for any help/pointers -- ------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------

1 1

[U-Boot] [PATCH 1/2] exynos5-dt: enable new CONFIG_SYS_I2C symbols
by Naveen Krishna Chatradhi 20 Nov '13

20 Nov '13

This patch enables the new I2C framework for Exynos5-dt, Also removes HARD_I2C. Signed-off-by: Naveen Krishna Chatradhi <ch.naveen(a)samsung.com> --- These patches were based on v6 version of patches adding support5yy for Exynos5420 on u-boot-samsung.git https://patches.linaro.org/21255/ include/configs/VCMA9.h | 5 +++-- include/configs/arndale.h | 6 +++--- include/configs/exynos5-dt.h | 8 ++++---- 3 files changed, 10 insertions(+), 9 deletions(-) diff --git a/include/configs/VCMA9.h b/include/configs/VCMA9.h index 2034493..363744a 100644 --- a/include/configs/VCMA9.h +++ b/include/configs/VCMA9.h @@ -73,12 +73,13 @@ * the MPL VCMA9 is equipped with an ATMEL 24C256 EEPROM at * address 0x50 with 16bit addressing */ -#define CONFIG_HARD_I2C /* I2C with hardware support */ #define CONFIG_SYS_I2C_SPEED 100000 /* I2C speed */ #define CONFIG_SYS_I2C_SLAVE 0x7F /* I2C slave addr */ /* we use the built-in I2C controller */ -#define CONFIG_DRIVER_S3C24X0_I2C +#define CONFIG_SYS_I2C_S3C24X0_I2C +#define CONFIG_SYS_NUM_I2C_ADAPTERS 1 +#define CONFIG_SYS_I2C #define CONFIG_SYS_I2C_EEPROM_ADDR 0x50 #define CONFIG_SYS_I2C_EEPROM_ADDR_LEN 2 diff --git a/include/configs/arndale.h b/include/configs/arndale.h index ed44a04..ab0a794 100644 --- a/include/configs/arndale.h +++ b/include/configs/arndale.h @@ -216,14 +216,14 @@ /* I2C */ #define CONFIG_SYS_I2C_INIT_BOARD -#define CONFIG_HARD_I2C #define CONFIG_CMD_I2C #define CONFIG_SYS_I2C_SPEED 100000 /* 100 Kbps */ -#define CONFIG_DRIVER_S3C24X0_I2C -#define CONFIG_I2C_MULTI_BUS #define CONFIG_MAX_I2C_NUM 8 #define CONFIG_SYS_I2C_SLAVE 0x0 #define CONFIG_I2C_EDID +#define CONFIG_SYS_I2C_S3C24X0_I2C +#define CONFIG_SYS_NUM_I2C_ADAPTERS 8 +#define CONFIG_SYS_I2C /* PMIC */ #define CONFIG_PMIC diff --git a/include/configs/exynos5-dt.h b/include/configs/exynos5-dt.h index fa6bb89..8a63cb8 100644 --- a/include/configs/exynos5-dt.h +++ b/include/configs/exynos5-dt.h @@ -237,12 +237,12 @@ /* I2C */ #define CONFIG_SYS_I2C_INIT_BOARD -#define CONFIG_HARD_I2C -#define CONFIG_CMD_I2C +#define CONFIG_SYS_I2C_S3C24X0_I2C #define CONFIG_SYS_I2C_SPEED 100000 /* 100 Kbps */ -#define CONFIG_DRIVER_S3C24X0_I2C -#define CONFIG_I2C_MULTI_BUS #define CONFIG_SYS_I2C_SLAVE 0x0 +#define CONFIG_SYS_NUM_I2C_ADAPTERS 11 +#define CONFIG_SYS_I2C +#define CONFIG_CMD_I2C #define CONFIG_I2C_EDID /* SPI */ -- 1.7.10.4

3 2

[U-Boot] [PATCH] net/phy: Add Vitesse VSC8514 PHY support
by shh.xie＠gmail.com 20 Nov '13

20 Nov '13

From: Shaohui Xie <Shaohui.Xie(a)freescale.com> The VSC8514 works in QSGMII interface. Its register set and features are similar to VSC8574 which in QSGMII mode. Signed-off-by: Shaohui Xie <Shaohui.Xie(a)freescale.com> --- drivers/net/phy/vitesse.c | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/drivers/net/phy/vitesse.c b/drivers/net/phy/vitesse.c index 61f863e..9af4efe 100644 --- a/drivers/net/phy/vitesse.c +++ b/drivers/net/phy/vitesse.c @@ -241,6 +241,16 @@ static struct phy_driver VSC8234_driver = { .shutdown = &genphy_shutdown, }; +static struct phy_driver VSC8514_driver = { + .name = "Vitesse VSC8514", + .uid = 0x70670, + .mask = 0xffff0, + .features = PHY_GBIT_FEATURES, + .config = &vsc8574_config, + .startup = &vitesse_startup, + .shutdown = &genphy_shutdown, +}; + static struct phy_driver VSC8574_driver = { .name = "Vitesse VSC8574", .uid = 0x704a0, @@ -310,6 +320,7 @@ int phy_vitesse_init(void) phy_register(&VSC8244_driver); phy_register(&VSC8211_driver); phy_register(&VSC8221_driver); + phy_register(&VSC8514_driver); phy_register(&VSC8574_driver); phy_register(&VSC8662_driver); phy_register(&cis8201_driver); -- 1.8.0

3 3

Re: [U-Boot] [PATCH v8 0/5] mtd: nand: omap: optimize and clean-up of OMAP NAND driver
by Gupta, Pekon 20 Nov '13

20 Nov '13

Hi Matti and Matthias Sorry I was away from my mailbox so couldn't reply you earlier. I'm still away from my setup and other boards, so cannot replicate the issue below until early next week. But I'll surely do so asap.. However, please see my replies below, which might help you someway. > From: matti kaasinen [mailto:matti.kaasinen@gmail.com] > Hi Pekon, > Thanks to Tom Rini's hint I have tried to execute your patch sets > (http://patchwork.ozlabs.org/project/uboot/list/?submitter=17320&state=*) > in order to get Linux and U-Boot working with same NAND flash. > Set-up is pretty much like Mathias has before in this chain. > Latest problem I faced with is that last versions of > 1) "[U-Boot,v8,3/5] mtd: nand: omap: optimize chip->ecc.calculate() for H/W ECC schemes" > and 2) "[U-Boot,v2,2/3] mtd: nand: omap: add support for BCH16_ECC - NAND driver updates" > are not compatible any more. As I told in > https://groups.google.com/forum/#!topic/beagleboard/7ofbE_Rrn_s > versions v5..v7 of 1) could possibly be compatible. There is no change in ECC layout or other functional updates between v7 and v8 of this patch, so if there is any incompatibility then it would be in all versions of the patch.. Few questions.. (1) Which ECC scheme are you using ? - u-boot CONFIG_NAND_OMAP_ECCSCHEME as per doc/README.nand http://lists.denx.de/pipermail/u-boot/2013-October/164646.html - kernel OMAP_ECC_BCH8_CODE_HW OMAP_ECC_BCH8_CODE_HW_DETECTION_SW Or any other.. (2) Is the problem related to incorrect read/write access to x16 NAND ? Or Is it incompatibility in ecc.layout ? You can check this by dumping raw nand page via 'nand dump' command from both u-boot and kernel. (3) you should not pick BCH16 patch-series - because I have not rebased this patch, and re-tested since other base patch-series on which BCH16 will be build, is still not accepted. - Also BCH16 ecc scheme would work only for NAND device with pagesize=4K and oobsize=224. whereas current beaglebone capes have NAND device with pagesize=2K and oobsize=64, so you can only use BCH8 with current NAND capes (for now).. > > 2013/11/1 Matthias Fuchs <mfuchs(a)ma-fu.de> > > Hi Pekon, > > > > should I consider the U-Boot and Linux am335x NAND > > implementation to be compatible? So are the ECC schemes > > in a way identical that I can nandwrite a kernel image from > > Linux and "nand read" it from U-Boot? I tested with the 3.8.13 > > beaglebone kernel (which is of course not very representative) > > and it does not work. If it should work, do you know it that was > > already the case before your patches and with which Linux kernel? I don't think any earlier kernel versions ever supported beaglebone Its only recently that a major patch-series of NAND driver was accepted and tested on beaglebone. The patches are currently in l2-mtd.git tree which should make into 3.13 kernel, before being in linux-next for sometime. (a) Reference: http://lists.infradead.org/pipermail/linux-mtd/2013-October/049462.html (b) In addition to above series, you might need beaglebone DTS updates which you can refer from below .. http://lists.infradead.org/pipermail/linux-mtd/2013-October/049438.html with regards, pekon

2 8