February 2016 - U-Boot

[U-Boot] [PATCH v3 0/3] ARM: at91: add PMC_PLLICPR init function
by Wenyou Yang 18 Feb '16

18 Feb '16

To reduce the duplicated code, add PLLICPR init function, use the function to clean up the PMC_PLLICPR directly writing code. It is based on the following patch set. http://lists.denx.de/pipermail/u-boot/2016-February/244370.html http://lists.denx.de/pipermail/u-boot/2016-February/244399.html http://lists.denx.de/pipermail/u-boot/2016-February/244408.html Changes in v3: - collect Tested-by from Heiko Schocher. Changes in v2: - move at91_pllicpr_init() definition to the common file, clock.c. - fix checkpatch errors. Wenyou Yang (3): ARM: at91: clock: add PMC_PLLICPR init function ARM: at91: clean up the PMC_PLLICPR init code board: atmel: clean up the PMC_PLLICPR init code arch/arm/mach-at91/clock.c | 7 +++++++ arch/arm/mach-at91/include/mach/at91_pmc.h | 7 +++++++ arch/arm/mach-at91/include/mach/clk.h | 1 + arch/arm/mach-at91/spl_at91.c | 5 +---- board/atmel/sama5d3_xplained/sama5d3_xplained.c | 4 +--- board/atmel/sama5d3xek/sama5d3xek.c | 4 +--- board/atmel/sama5d4_xplained/sama5d4_xplained.c | 4 +--- board/atmel/sama5d4ek/sama5d4ek.c | 4 +--- 8 files changed, 20 insertions(+), 16 deletions(-) -- 1.7.9.5

2 6

[U-Boot] [PATCH v3 0/4] ARM: at91: add UTMI PLL handle functions
by Wenyou Yang 18 Feb '16

18 Feb '16

To reduce the duplicated code, add UTMI PLL enable/disable functions, replace the UTMI PLL handle code with these functions. It is based on the following patch set. http://lists.denx.de/pipermail/u-boot/2016-February/244370.html Changes in v3: - collect Tested-by from Heiko Schocher. Changes in v2: - remain asm/io.h include. Wenyou Yang (4): ARM: at91: clock: add UTMI PLL enable/disable function ARM: at91: armv7: clean up UTMI PLL handle code drivers: usb: atmel: clean up the UTMI PLL code board: atmel: siemens: clean up UTMI PLL code arch/arm/mach-at91/armv7/sama5d2_devices.c | 5 +-- arch/arm/mach-at91/armv7/sama5d3_devices.c | 5 +-- arch/arm/mach-at91/armv7/sama5d4_devices.c | 5 +-- arch/arm/mach-at91/clock.c | 48 ++++++++++++++++++++++++++++ arch/arm/mach-at91/include/mach/clk.h | 3 ++ board/siemens/corvus/board.c | 4 +-- drivers/usb/host/ehci-atmel.c | 38 +++------------------- drivers/usb/host/ohci-at91.c | 20 ++++-------- 8 files changed, 66 insertions(+), 62 deletions(-) -- 1.7.9.5

2 8

[U-Boot] [PATCH 1/2] net: phy: marvell: Call phy_reset() where possible
by Stefan Roese 18 Feb '16

18 Feb '16

Instead of coding the soft PHY reset function multiple times in marvell.c, lets call the common phy_reset() function from phy.c. Signed-off-by: Stefan Roese <sr(a)denx.de> Cc: Stefan Agner <stefan(a)agner.ch> Cc: Hao Zhang <hzhang(a)ti.com> Cc: Michal Simek <monstr(a)monstr.eu> Cc: Andy Fleming <afleming(a)gmail.com> Cc: Joe Hershberger <joe.hershberger(a)ni.com> --- drivers/net/phy/marvell.c | 23 ++--------------------- 1 file changed, 2 insertions(+), 21 deletions(-) diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c index eab1558..6e3dc85 100644 --- a/drivers/net/phy/marvell.c +++ b/drivers/net/phy/marvell.c @@ -172,7 +172,6 @@ static int m88e1011s_startup(struct phy_device *phydev) static int m88e1111s_config(struct phy_device *phydev) { int reg; - int timeout; if ((phydev->interface == PHY_INTERFACE_MODE_RGMII) || (phydev->interface == PHY_INTERFACE_MODE_RGMII_ID) || @@ -236,16 +235,7 @@ static int m88e1111s_config(struct phy_device *phydev) MIIM_88E1111_PHY_EXT_SR, reg); /* soft reset */ - timeout = 1000; - phy_write(phydev, MDIO_DEVAD_NONE, MII_BMCR, BMCR_RESET); - udelay(1000); - reg = phy_read(phydev, MDIO_DEVAD_NONE, MII_BMCR); - while ((reg & BMCR_RESET) && --timeout) { - udelay(1000); - reg = phy_read(phydev, MDIO_DEVAD_NONE, MII_BMCR); - } - if (!timeout) - printf("%s: phy soft reset timeout\n", __func__); + phy_reset(phydev); reg = phy_read(phydev, MDIO_DEVAD_NONE, MIIM_88E1111_PHY_EXT_SR); @@ -258,16 +248,7 @@ static int m88e1111s_config(struct phy_device *phydev) } /* soft reset */ - timeout = 1000; - phy_write(phydev, MDIO_DEVAD_NONE, MII_BMCR, BMCR_RESET); - udelay(1000); - reg = phy_read(phydev, MDIO_DEVAD_NONE, MII_BMCR); - while ((reg & BMCR_RESET) && --timeout) { - udelay(1000); - reg = phy_read(phydev, MDIO_DEVAD_NONE, MII_BMCR); - } - if (!timeout) - printf("%s: phy soft reset timeout\n", __func__); + phy_reset(phydev); genphy_config_aneg(phydev); -- 2.7.1

3 5

[U-Boot] [PATCH] ARM: uniphier: remove unused umc_polling()
by Masahiro Yamada 18 Feb '16

18 Feb '16

This function is unused. Signed-off-by: Masahiro Yamada <yamada.masahiro(a)socionext.com> --- arch/arm/mach-uniphier/dram/umc-regs.h | 9 --------- 1 file changed, 9 deletions(-) diff --git a/arch/arm/mach-uniphier/dram/umc-regs.h b/arch/arm/mach-uniphier/dram/umc-regs.h index a6957a4..b33e2da 100644 --- a/arch/arm/mach-uniphier/dram/umc-regs.h +++ b/arch/arm/mach-uniphier/dram/umc-regs.h @@ -120,15 +120,6 @@ #include <linux/types.h> -static inline void umc_polling(u32 address, u32 expval, u32 mask) -{ - u32 nmask = ~mask; - u32 data; - do { - data = readl(address) & nmask; - } while (data != expval); -} - static inline void umc_dram_init_start(void __iomem *dramcont) { writel(0x00000002, dramcont + UMC_INITSET); -- 1.9.1

1 0

[U-Boot] NAND bad block checking policy
by Guilherme de Oliveira Costa 18 Feb '16

18 Feb '16

Hello, I'm using U-Boot 2013.01.01, and I've noticed an odd behaviour when the system is checking for bad blocks on my Micron NAND. Let's say we have a NAND memory with the following features: Memory Size 128 MB Sector size 128 KiB Page size 2048 b OOB size 64 b Erase size 131072 b If I try and mark a block as bad manually (via nand markbad), the following happens: U-Boot@UCC3# nand markbad 0x4290000 block 0x04290000 successfully marked as bad U-Boot@UCC3# nand bad Device 0 bad blocks: 04280000 Everything seems fine. However, after a reboot, the system loses the information. Sifting through the code, I found the it is only checking the first two pages OOB. Note however that the block that gets marked as bad is block 0x4280000, which is aligned in memory with the eraseblock size (1st page in the eraseblock). Also, if I dump the oob info from 0x428000, it is not flagged as bad, but in 0x429000, the first byte is still 0x00, indicating it as bad. If I mark the 1st or 2nd page in an erase block as bad, then the information persists through boot cycles. Also, I've verified that we are not using a NAND based bbt. My main concern is that, because this checking shared between functionalities, everytime we erase a block, we keep losing bad block information, because inner pages (i.e. not the 1st or 2nd in an eraseblock), are flagged as good, which, in my point of view, is a bad thing. If this is indeed the intended behaviour, it seems to me that it is due to performance reasons. So, in this case, should we mark the whole eraseblock as bad (by writing 0x00 to the 1st or 2nd pages) if we find a single bad page in a block? Isn't this also a bad solution, since we will be marking 128kiB as bad due to a single page? Shouldn't this control be made at a finer level (i.e. page level)? Regards, Guilherme Esta mensagem e qualquer anexo a ela s?o documentos confidenciais e direcionados exclusivamente ao(s) destinat?rio(s). Qualquer uso, desvio, sonega??o, supress?o, revela??o ou divulga??o n?o autorizada ? proibida e sujeita ?s san??es e/ou repara??es legais por ato il?cito (C?digo Penal, Artigos 151 e 152). Caso n?o seja um dos destinat?rios expressamente indicados, por favor entre em contato com o remetente, respondendo este e-mail e destrua quaisquer c?pias da mensagem original. Qualquer opini?o, cr?tica ou an?lise descrita nesta mensagem ? de responsabilidade ?nica do remetente, a menos quando estiver explicitamente expresso que seja da empresa remetente. This message and any attachment are confidential information for the sole use of the intended recipients. Any unauthorized use, deviation, withholdment, suppression, disclosure or distribution is prohibited and is subjected to legal sanctions and/or compensations per illicit act (Penal Code, articles 151 and 152). If you are not one of the intended recipients, please contact the sender by reply e-mail and destroy any copy of the original message. Any view, comment or analysis expressed in this message is sole responsibility from the sender, except when it's specifically expressed that it's the view, comment or analysis of the company.

1 0

[U-Boot] [PATCH v2] spi-nor: Correct the logic to detect flash rw mode
by Bin Meng 18 Feb '16

18 Feb '16

spi->mode includes all available modes for operating on SPI flashes, and we should test each bit instead of a switch..case statement to make the detection logic correct. Signed-off-by: Bin Meng <bmeng.cn(a)gmail.com> --- Changes in v2: - Write mode detection should not be in a 'else' branch drivers/mtd/spi-nor/m25p80.c | 19 +++++-------------- 1 file changed, 5 insertions(+), 14 deletions(-) diff --git a/drivers/mtd/spi-nor/m25p80.c b/drivers/mtd/spi-nor/m25p80.c index 4e0a53c..8edc481 100644 --- a/drivers/mtd/spi-nor/m25p80.c +++ b/drivers/mtd/spi-nor/m25p80.c @@ -178,26 +178,17 @@ static int m25p80_spi_nor(struct spi_nor *nor) return ret; } - switch (spi->mode) { - case SPI_RX_SLOW: + if (spi->mode & SPI_RX_SLOW) nor->read_mode = SNOR_READ; - break; - case SPI_RX_DUAL: + else if (spi->mode & SPI_RX_DUAL) nor->read_mode = SNOR_READ_1_1_2; - break; - case SPI_RX_QUAD: + else if (spi->mode & SPI_RX_QUAD) nor->read_mode = SNOR_READ_1_1_4; - break; - } - switch (spi->mode) { - case SPI_TX_BYTE: + if (spi->mode & SPI_TX_BYTE) nor->mode = SNOR_WRITE_1_1_BYTE; - break; - case SPI_TX_QUAD: + else if (spi->mode & SPI_TX_QUAD) nor->mode = SNOR_WRITE_1_1_4; - break; - } nor->memory_map = spi->memory_map; nor->max_write_size = spi->max_write_size; -- 1.8.2.1

1 0

[U-Boot] [PATCH] spi-nor: Correct the logic to detect flash rw mode
by Bin Meng 18 Feb '16

18 Feb '16

spi->mode includes all available modes for operating on SPI flashes, and we should test each bit instead of a switch..case statement to make the detection logic correct. Signed-off-by: Bin Meng <bmeng.cn(a)gmail.com> --- drivers/mtd/spi-nor/m25p80.c | 20 +++++--------------- 1 file changed, 5 insertions(+), 15 deletions(-) diff --git a/drivers/mtd/spi-nor/m25p80.c b/drivers/mtd/spi-nor/m25p80.c index 4e0a53c..9d17449 100644 --- a/drivers/mtd/spi-nor/m25p80.c +++ b/drivers/mtd/spi-nor/m25p80.c @@ -178,26 +178,16 @@ static int m25p80_spi_nor(struct spi_nor *nor) return ret; } - switch (spi->mode) { - case SPI_RX_SLOW: + if (spi->mode & SPI_RX_SLOW) nor->read_mode = SNOR_READ; - break; - case SPI_RX_DUAL: + else if (spi->mode & SPI_RX_DUAL) nor->read_mode = SNOR_READ_1_1_2; - break; - case SPI_RX_QUAD: + else if (spi->mode & SPI_RX_QUAD) nor->read_mode = SNOR_READ_1_1_4; - break; - } - - switch (spi->mode) { - case SPI_TX_BYTE: + else if (spi->mode & SPI_TX_BYTE) nor->mode = SNOR_WRITE_1_1_BYTE; - break; - case SPI_TX_QUAD: + else if (spi->mode & SPI_TX_QUAD) nor->mode = SNOR_WRITE_1_1_4; - break; - } nor->memory_map = spi->memory_map; nor->max_write_size = spi->max_write_size; -- 1.8.2.1

1 0

[U-Boot] [PATCH] RFC/BUG Workaround regression with "mkimage -T rksd".
by Vagrant Cascadian 18 Feb '16

18 Feb '16

While this patch allows "mkimage -T rksd" to work, boot is still broken in other ways, so something more needs to be fixed. Partially Reverts "rockchip: jerry: Enable EDP and HDMI video output" This partiall reverts commit 74336f7daa4b1a45d04ddc9ef05737af54ae4836. For some reason, the change made to the rk3288.dtsi broke "mkimage -T rksd", which resulted in a different image type that fails to boot: $ ./tools/mkimage -T rksd -n rk3288 -d spl/u-boot-spl-dtb.bin u-boot-spl-dtb.rksd Warning: SPL image is too large (size 0x80ec) and will not boot $ ./tools/mkimage -l u-boot-spl-dtb.rksd Image Type: MVEBU Boot from (null) Image Image version:0 Data Size: -4 Bytes = 4194304.00 kB = 4096.00 MB Load Address: 00000000 Entry Point: 00000000 Normally, mkimage -T rksd should generate an image like this: mkimage -l u-boot-spl-dtb.rksd GP Header: Size 3b8cdcfc LoadAddr be9f9d51 However, booting with the "fixed" .rksd image still fails, probably because of issues in the device-tree: U-Boot 2016.03-rc2 (Feb 18 2016 - 04:08:20 +0000) Model: Firefly-RK3288 DRAM: 2 GiB Video device 'vop@ff930000' cannot allocate frame buffer memory -ensure the device is set up before relocation Error binding driver 'rk_vop': -28 Video device 'vop@ff940000' cannot allocate frame buffer memory -ensure the device is set up before relocation Error binding driver 'rk_vop': -28 Some drivers failed to bind initcall sequence 7ffb0a10 failed at call 00109f9b (err=-28) Hopefully a more complete fix will be obvious to someone, or there is a better way to generate boot images for firefly-rk3288. Signed-off-by: Vagrant Cascadian <vagrant(a)debian.org> --- arch/arm/dts/rk3288.dtsi | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/arm/dts/rk3288.dtsi b/arch/arm/dts/rk3288.dtsi index e51c75c..e2a65be 100644 --- a/arch/arm/dts/rk3288.dtsi +++ b/arch/arm/dts/rk3288.dtsi @@ -707,7 +707,6 @@ iommus = <&vopl_mmu>; power-domains = <&power RK3288_PD_VIO>; status = "disabled"; - u-boot,dm-pre-reloc; vopl_out: port { #address-cells = <1>; #size-cells = <0>; -- 2.1.4

2 1

[U-Boot] [PATCH] ARM: zynq: Enable SPL RAM support by default
by Michal Simek 18 Feb '16

18 Feb '16

Use RAM support in jtagboot mode. Signed-off-by: Michal Simek <michal.simek(a)xilinx.com> --- include/configs/zynq-common.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/configs/zynq-common.h b/include/configs/zynq-common.h index e8c3ef0c3872..9bd3e9f32665 100644 --- a/include/configs/zynq-common.h +++ b/include/configs/zynq-common.h @@ -307,6 +307,7 @@ #define CONFIG_SPL_LIBGENERIC_SUPPORT #define CONFIG_SPL_SERIAL_SUPPORT #define CONFIG_SPL_BOARD_INIT +#define CONFIG_SPL_RAM_DEVICE #define CONFIG_SPL_LDSCRIPT "arch/arm/mach-zynq/u-boot-spl.lds" -- 1.9.1

2 1

[U-Boot] test/py main_signon
by Michal Simek 17 Feb '16

17 Feb '16

Hi Stephen, trying to run the latest testing on zynq board and getting this main_signon error. This is what I am running ./test/py/test.py --bd zynq_zc702 --build --board-identity zc702 and getting below. Thanks, Michal U-Boot 2016.03-rc2 (Feb 16 2016 - 13:10:03 +0100) Model: Zynq ZC702 Development Board Board: Xilinx Zynq I2C: ready DRAM: ECC disabled 1 GiB Bad pattern found on console: main_signon FAILED: request = <SubRequest 'u_boot_console' for <Function 'test_version'>> @pytest.fixture(scope='function') def u_boot_console(request): """Generate the value of a test's u_boot_console fixture. Args: request: The pytest request. Returns: The fixture value. """ > console.ensure_spawned() test/py/conftest.py:311: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ self = <u_boot_console_exec_attach.ConsoleExecAttach object at 0x7f2b33dee8d0> def ensure_spawned(self): """Ensure a connection to a correctly running U-Boot instance. This may require spawning a new Sandbox process or resetting target hardware, as defined by the implementation sub-class. This is an internal function and should not be called directly. Args: None. Returns: Nothing. """ if self.p: return try: self.log.start_section('Starting U-Boot') self.at_prompt = False self.p = self.get_spawn() # Real targets can take a long time to scroll large amounts of # text if LCD is enabled. This value may need tweaking in the # future, possibly per-test to be optimal. This works for 'help' # on board 'seaboard'. if not self.config.gdbserver: self.p.timeout = 30000 self.p.logfile_read = self.logstream if self.config.buildconfig.get('config_spl', False) == 'y': m = self.p.expect([pattern_u_boot_spl_signon] + self.bad_patterns) if m != 0: raise Exception('Bad pattern found on console: ' + > self.bad_pattern_ids[m - 1]) E Exception: Bad pattern found on console: main_signon test/py/u_boot_console_base.py:310: Exception

4 10