[U-Boot] [PATCH V2 22/24] SPEAr: Correct SoC ID offset in misc configuration space
From: Shiraz Hashim
SoC Core ID offset is 0x30 in miscellaneous configuration address
space. It was wrongly mentioned as periph2 clk enable.
Signed-off-by: Shiraz Hashim
Signed-off-by: Amit Virdi
Acked-by: Stefan Roese
---
arch/arm/include/asm/arch-spear/spr_misc.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/include/asm/arch-spear/spr_misc.h
b/arch/arm/include/asm/arch-spear/spr_misc.h
index 384944d..b8fcf49 100644
--- a/arch/arm/include/asm/arch-spear/spr_misc.h
+++ b/arch/arm/include/asm/arch-spear/spr_misc.h
@@ -37,7 +37,7 @@ struct misc_regs {
u32 amba_clk_cfg; /* 0x24 */
u32 periph_clk_cfg; /* 0x28 */
u32 periph1_clken; /* 0x2C */
- u32 periph2_clken; /* 0x30 */
+ u32 soc_core_id;/* 0x30 */
u32 ras_clken; /* 0x34 */
u32 periph1_rst;/* 0x38 */
u32 periph2_rst;/* 0x3C */
--
1.7.2.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2 23/24] cleanup/SPEAr: Remove unnecessary parenthesis
In SPEAr configuration files, unnecessary paranthesis are used in some
\#defines. Remove them as they serve no purpose
Signed-off-by: Amit Virdi
Acked-by: Stefan Roese
---
arch/arm/include/asm/arch-spear/spr_gpt.h |4 ++--
include/configs/spear-common.h|8
include/configs/spear3xx_evb.h|6 +++---
include/configs/spear6xx_evb.h|2 +-
4 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/arch/arm/include/asm/arch-spear/spr_gpt.h
b/arch/arm/include/asm/arch-spear/spr_gpt.h
index 965b5ab..d95ba52 100644
--- a/arch/arm/include/asm/arch-spear/spr_gpt.h
+++ b/arch/arm/include/asm/arch-spear/spr_gpt.h
@@ -79,7 +79,7 @@ struct gpt_regs {
#define GPT_FREE_RUNNING 0x
/* Timer, HZ specific defines */
-#define CONFIG_SPEAR_HZ(1000)
-#define CONFIG_SPEAR_HZ_CLOCK (830)
+#define CONFIG_SPEAR_HZ1000
+#define CONFIG_SPEAR_HZ_CLOCK 830
#endif
diff --git a/include/configs/spear-common.h b/include/configs/spear-common.h
index 673f483..aee5815 100644
--- a/include/configs/spear-common.h
+++ b/include/configs/spear-common.h
@@ -62,7 +62,7 @@
#define CONFIG_I2C_CHIPADDRESS 0x50
/* Timer, HZ specific defines */
-#define CONFIG_SYS_HZ (1000)
+#define CONFIG_SYS_HZ 1000
/* Flash configuration */
#if defined(CONFIG_FLASH_PNOR)
@@ -74,9 +74,9 @@
#if defined(CONFIG_ST_SMI)
#define CONFIG_SYS_MAX_FLASH_BANKS 2
-#define CONFIG_SYS_FLASH_BASE (0xF800)
-#define CONFIG_SYS_CS1_FLASH_BASE (0xF900)
-#define CONFIG_SYS_FLASH_BANK_SIZE (0x0100)
+#define CONFIG_SYS_FLASH_BASE 0xF800
+#define CONFIG_SYS_CS1_FLASH_BASE 0xF900
+#define CONFIG_SYS_FLASH_BANK_SIZE 0x0100
#define CONFIG_SYS_FLASH_ADDR_BASE {CONFIG_SYS_FLASH_BASE, \
CONFIG_SYS_CS1_FLASH_BASE}
#define CONFIG_SYS_MAX_FLASH_SECT 128
diff --git a/include/configs/spear3xx_evb.h b/include/configs/spear3xx_evb.h
index 242e648..d63c9df 100644
--- a/include/configs/spear3xx_evb.h
+++ b/include/configs/spear3xx_evb.h
@@ -150,13 +150,13 @@
#define CONFIG_SYS_FSMC_NAND_8BIT
#if defined(CONFIG_SPEAR300)
-#define CONFIG_SYS_NAND_BASE (0x8000)
+#define CONFIG_SYS_NAND_BASE 0x8000
#elif defined(CONFIG_SPEAR310)
-#define CONFIG_SYS_NAND_BASE (0x4000)
+#define CONFIG_SYS_NAND_BASE 0x4000
#elif defined(CONFIG_SPEAR320)
-#define CONFIG_SYS_NAND_BASE (0x5000)
+#define CONFIG_SYS_NAND_BASE 0x5000
#endif
diff --git a/include/configs/spear6xx_evb.h b/include/configs/spear6xx_evb.h
index 3e0f50b..4a76134 100644
--- a/include/configs/spear6xx_evb.h
+++ b/include/configs/spear6xx_evb.h
@@ -51,7 +51,7 @@
/* NAND flash configuration */
#define CONFIG_SYS_FSMC_NAND_SP
#define CONFIG_SYS_FSMC_NAND_8BIT
-#define CONFIG_SYS_NAND_BASE (0xD200)
+#define CONFIG_SYS_NAND_BASE 0xD200
/* Environment Settings */
#define CONFIG_EXTRA_ENV_SETTINGS CONFIG_EXTRA_ENV_USBTTY
--
1.7.2.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2 24/24] cleanup/SPEAr: Define configuration flags more elegantly
In SPEAr, some of the configuration flags eg. CONFIG_SPEAR_EMI, were given value "1", which isn't required. Define the flags without assigning any value Signed-off-by: Amit Virdi Acked-by: Stefan Roese --- include/configs/spear-common.h | 16 include/configs/spear3xx_evb.h | 20 ++-- include/configs/spear6xx_evb.h |2 +- 3 files changed, 19 insertions(+), 19 deletions(-) diff --git a/include/configs/spear-common.h b/include/configs/spear-common.h index aee5815..766a315 100644 --- a/include/configs/spear-common.h +++ b/include/configs/spear-common.h @@ -66,7 +66,7 @@ /* Flash configuration */ #if defined(CONFIG_FLASH_PNOR) -#define CONFIG_SPEAR_EMI 1 +#define CONFIG_SPEAR_EMI #else #define CONFIG_ST_SMI #endif @@ -205,11 +205,11 @@ #define CONFIG_BOARD_EARLY_INIT_F #define CONFIG_DISPLAY_CPUINFO #define CONFIG_BOOT_PARAMS_ADDR0x0100 -#define CONFIG_CMDLINE_TAG 1 -#define CONFIG_SETUP_MEMORY_TAGS 1 -#define CONFIG_MISC_INIT_R 1 -#define CONFIG_ZERO_BOOTDELAY_CHECK1 -#define CONFIG_AUTOBOOT_KEYED 1 +#define CONFIG_CMDLINE_TAG +#define CONFIG_SETUP_MEMORY_TAGS +#define CONFIG_MISC_INIT_R +#define CONFIG_ZERO_BOOTDELAY_CHECK +#define CONFIG_AUTOBOOT_KEYED #define CONFIG_AUTOBOOT_STOP_STR " " #define CONFIG_AUTOBOOT_PROMPT \ "Hit SPACE in %d seconds to stop autoboot.\n", bootdelay @@ -227,8 +227,8 @@ #define CONFIG_SYS_MAXARGS 16 #define CONFIG_SYS_BARGSIZECONFIG_SYS_CBSIZE #define CONFIG_SYS_LOAD_ADDR 0x0080 -#define CONFIG_SYS_CONSOLE_INFO_QUIET 1 -#define CONFIG_SYS_64BIT_VSPRINTF 1 +#define CONFIG_SYS_CONSOLE_INFO_QUIET +#define CONFIG_SYS_64BIT_VSPRINTF #define CONFIG_SYS_FLASH_EMPTY_INFO diff --git a/include/configs/spear3xx_evb.h b/include/configs/spear3xx_evb.h index d63c9df..3cd56dc 100644 --- a/include/configs/spear3xx_evb.h +++ b/include/configs/spear3xx_evb.h @@ -29,14 +29,14 @@ * (easy to change) */ #if defined(CONFIG_spear300) -#define CONFIG_SPEAR3XX1 -#define CONFIG_SPEAR3001 +#define CONFIG_SPEAR3XX +#define CONFIG_SPEAR300 #elif defined(CONFIG_spear310) -#define CONFIG_SPEAR3XX1 -#define CONFIG_SPEAR3101 +#define CONFIG_SPEAR3XX +#define CONFIG_SPEAR310 #elif defined(CONFIG_spear320) -#define CONFIG_SPEAR3XX1 -#define CONFIG_SPEAR3201 +#define CONFIG_SPEAR3XX +#define CONFIG_SPEAR320 #endif #if defined(CONFIG_usbtty) @@ -52,17 +52,17 @@ #include /* Ethernet driver configuration */ -#define CONFIG_DW_ALTDESCRIPTOR1 +#define CONFIG_DW_ALTDESCRIPTOR #if defined(CONFIG_SPEAR310) -#define CONFIG_MACB1 +#define CONFIG_MACB #define CONFIG_MACB0_PHY 0x01 #define CONFIG_MACB1_PHY 0x03 #define CONFIG_MACB2_PHY 0x05 #define CONFIG_MACB3_PHY 0x07 #elif defined(CONFIG_SPEAR320) -#define CONFIG_MACB1 +#define CONFIG_MACB #define CONFIG_MACB0_PHY 0x01 #endif @@ -141,7 +141,7 @@ #endif #define CONFIG_SYS_MAX_FLASH_SECT (127 + 8) -#define CONFIG_SYS_FLASH_QUIET_TEST1 +#define CONFIG_SYS_FLASH_QUIET_TEST #endif diff --git a/include/configs/spear6xx_evb.h b/include/configs/spear6xx_evb.h index 4a76134..31b8725 100644 --- a/include/configs/spear6xx_evb.h +++ b/include/configs/spear6xx_evb.h @@ -28,7 +28,7 @@ * High Level Configuration Options * (easy to change) */ -#define CONFIG_SPEAR6001 +#define CONFIG_SPEAR600 #if defined(CONFIG_usbtty) #define CONFIG_SPEAR_USBTTY -- 1.7.2.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [ARM] Status for 2012.03
Le 27/03/2012 22:18, Albert ARIBAUD a écrit :
Hi all,
I have been away from the list quite a few days, and will have a very
tricky time catching up, so with my apologies, I ask people who need me
to apply patches or pull requests for the upcoming release to please
send me a private e-mail and point me to the list message that I should
be acting upon.
FWIW, ./MAKEALL arm on current u-boot-arm/master with CS toolchain
2010q1 builds 277 boards, of which none has errors and 167 have warnings.
The total count of warnings is 248, distributed as:
4 post.c:503: warning: #warning "Not implemented yet"
79 mmc.c:132: warning: no return statement in function returning non-void
165 ohci-hcd.c:{1307,1310,1313}: warning: dereferencing pointer
'pretmp.NNN' does break strict-aliasing rules
(the last one is actually 3 * 51 warnings)
The first one is obvious and should be dealt with, but I consider it not
to be a blocker, for only 4 boards.
The second one seems straightforward to fix today, if not already submitted.
The third one may be an issue, but it could also be a zealous warning
from the specific CS toolchain version I am using. Anyway, it does not
seem ARM related as such.
Therefore I will issue the ARM pull request right away.
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Pull request: u-boot-arm/master
Hi Wolfgang,
The following changes since commit 7cb30b13f12077c7eec8ce2419cd96cd65ace8e2:
Merge branch 'master' of git://git.denx.de/u-boot-cfi-flash
(2012-03-23 21:59:16 +0100)
are available in the git repository at:
git://git.denx.de/u-boot-arm master
Anatolij Gustschin (4):
nhk8815: fix build errors
board/vpac270/onenand.c: Fix build errors
board/ti/beagle/beagle.c: Fix build warnings
arch/arm/cpu/armv7/omap-common/clocks-common.c: Fix build warnings
Andreas Bießmann (1):
atmel-boards: add missing atmel_mci.h
Chander Kashyap (1):
EXYNOS: Add structure for Exynos4 DMC
Christian Riesch (1):
calimain, enbw_cmc: Fix typo in comments
David Müller (ELSOFT AG) (1):
ARM: fix s3c2410 timer code
Dirk Behme (2):
mx6q: mx6qsabrelite: Update the README
imximage: Remove overwriting of flash_offset
Doug Anderson (1):
EXYNOS: SMDK5250: Support all 4 UARTs
Eric Nelson (6):
i.MX6: mx6qsabrelite: add ext2 support
mx6q: mx6qsabrelite: setup_spi() should be called in board_init
to allow use for environment
i.MX6: mx6q_sabrelite: add CONFIG_REVISION_TAG
i.MX6: mx6qsabrelite: add MACH_TYPE_MX6Q_SABRELITE
net: force PKTALIGN to ARCH_DMA_MINALIGN
net: fec_mxc: allow use with cache enabled
Fabio Estevam (15):
mx51evk: Fix CONFIG_SYS_MEMTEST_END
mx53evk: Fix CONFIG_SYS_MEMTEST_END
mx53smd: Fix CONFIG_SYS_MEMTEST_END
efikamx: Fix CONFIG_SYS_MEMTEST_END
mx31pdk: Fix CONFIG_SYS_MEMTEST_END
mx6: Fix reset cause for Power On Reset case
mx6: Remove duplicate definition of ANATOP_BASE_ADDR
pmic_i2c: Return error in case of invalid pmic_i2c_tx_num
mxs_spi: Return proper timeout error
mx6: Read silicon revision from register
USB: ehci-mx6: Add proper IO accessors
mx28evk: Provide default values for SPI bus and chip select
configs: imx: Use CONFIG_SF_DEFAULT_CS
mx53: Make PLL2 to be the parent of UART clock
mx53ard: Initialize return code with error
Grazvydas Ignotas (1):
twl4030: fix potential power supply handling issues
Heiko Schocher (1):
ARM: davinci: fixes for cam_enc_4xx board
Helmut Raiger (1):
mx31: add "ARM11P power gating" to get_reset_cause
Jason Hobbs (1):
ARM: highbank: change env config to use nvram
Marek Vasut (23):
PXA: Remove PXA PCMCIA support
PXA: Fix warning in zipitz2
PXA: Fix missing get_tbclk() breaking vpac boards
M28: Fix LCD PINMUX
M28: Support for the old M28 SoM v1.0
i.MX28: Reformat the DRAM memory configuration data
Examples: Properly append LDFLAGS to LD command
IXP: Make IXP buildable with arm-linux- toolchains
IXP: Fix missing MACH_TYPE_{ACTUX?,PNB3,DVLHOST}
IXP: Squash warnings in IXP NPE
IXP: Move PDNB3 and SCPU from Makefile to boards.cfg
IXP: Fix NAND build warning on PDNB3 and SCPU
IXP: Fix GPIO_INT_ACT_LOW_SET()
i.MX28: Enable additional DRAM address bits
i.MX28: Make the stabilization delays shorter
i.MX28: Drop __naked function from spl_mem_init
ARM926EJS: Implement cache operations
i.MX28: Add cache support into the APBH DMA driver
i.MX28: Add cache support to MXS NAND driver
MMC: Implement generic bounce buffer
i.MX28: Do data transfers via DMA in MMC driver
i.MX28: Make use of the bounce buffer
i.MX28: Enable caches by default
Matt Porter (2):
SPL: Add YMODEM over UART load support
SPL: Enable YMODEM support on BeagleBone and AM335x EVM
Rob Herring (8):
net: calxedaxgmac: fix build due to missing __aligned definition
ARM: highbank: fix warning for calxedaxgmac_initialize
ARM: highbank: add missing get_tbclk
ARM: highbank: fix us_to_tick calculation
ARM: highbank: change TEXT_BASE to 0x8000
ARM: highbank: Add boot counter support
ARM: highbank: add reset support
ARM: highbank: setup env from boot source register
Robert Delien (5):
i.mx28: Added register definitions for DIGCTL registers
i.mx28: Replaced magic numbers for scratch register addresses
with register definitions
Renamed mx28_register to mx28_register_32 to prepare for
mx28_register_8
Introducing 8-bit wide register, mx28_register_8
Fix erroneous 32-bit access to hw_clkctrl_frac0 and
hw_clkctrl_frac1 registers
Simon Glass (39):
arm: Remove jornada link script
fdt: Add fdtdec_find_aliases() to deal with alias nodes
fdt: Add tests for fdtdec
fdt: Tidy up a few fdtdec problems
fdt: Add functions to access phandles, arrays and bools
fdt: Add basic support for decoding GPIO definitions
arm: fdt: Add skeleton device tree file from kernel
tegra: fdt: Add Tegra2x device tree file from kernel
tegra: fdt: Add device tree file for Tegra2 Seaboard from kernel
fdt: Add staging area for device tree binding documentation
Re: [U-Boot] [PATCH 4/5] ARM: EXYNOS: support EXYNOS display driver
Donghwa,
On 30 March 2012 10:59, Donghwa Lee wrote:
> This patch is for EXYNOS Display driver.
>
> Signed-off-by: Donghwa Lee
> Signed-off-by: Inki Dae
> Signed-off-by: Kyungmin Park
> ---
> drivers/video/exynos_fb.c | 160 +
> drivers/video/exynos_fb.h | 62 +++
> drivers/video/exynos_fimd.c | 416
> +++
> 3 files changed, 638 insertions(+), 0 deletions(-)
> create mode 100644 drivers/video/exynos_fb.c
> create mode 100644 drivers/video/exynos_fb.h
> create mode 100644 drivers/video/exynos_fimd.c
>
> diff --git a/drivers/video/exynos_fb.c b/drivers/video/exynos_fb.c
> new file mode 100644
> index 000..5067b22
> --- /dev/null
> +++ b/drivers/video/exynos_fb.c
> +static void lcd_clk_set(void)
> +{
> + struct exynos4_clock *clk =
> + (struct exynos4_clock *)samsung_get_base_clock();
> + struct exynos4_sysreg *sysreg =
> + (struct exynos4_sysreg *)samsung_get_base_sysreg();
> + unsigned int cfg = 0;
This function should be moved to exynos clock driver.
> +
> + /* system register path set */
> + cfg = readl(&sysreg->display_ctrl);
> + cfg |= (1 << 1);
> + writel(cfg, &sysreg->display_ctrl);
> +
> + /* set lcd src clock */
> + cfg &= ~(0xf);
> + cfg |= 0x6;
> + writel(cfg, &clk->src_lcd0);
> +
> + cfg = readl(&clk->gate_ip_lcd0);
> + cfg |= 1 << 0;
> + writel(cfg, &clk->gate_ip_lcd0);
> +
> + /* set fimd ratio */
> + cfg &= ~(0xf);
> + cfg |= 0x1;
> + writel(cfg, &clk->div_lcd0);
> +
> +}
> +
> +void lcd_ctrl_init(void *lcdbase)
> +{
> + lcd_clk_set();
> + /* initialize parameters which is specific to panel. */
> + init_panel_info(&panel_info);
> +
> + panel_width = panel_info.vl_width;
> + panel_height = panel_info.vl_height;
> +
> + exynos_lcd_init_mem(lcdbase, &panel_info);
> +
> + exynos_lcd_init(&panel_info);
> +}
> +
> +
> +void lcd_setcolreg(ushort regno, ushort red, ushort green, ushort blud)
Maybe 'blud' is typo of 'blue'?
> +{
> + return;
Why you declared empty function?
> +}
> +
> +void lcd_enable(void)
> +{
> + lcd_panel_on(&panel_info);
> +}
> +
> +ulong calc_fbsize(void)
> +{
> + return exynos_fimd_calc_fbsize();
> +}
> diff --git a/drivers/video/exynos_fb.h b/drivers/video/exynos_fb.h
> new file mode 100644
> index 000..3b8b0f6
> --- /dev/null
> +++ b/drivers/video/exynos_fb.h
> @@ -0,0 +1,62 @@
> +/*
> + * drivers/video/exynos_fb.h
> + *
> + * Copyright (C) 2012 Donghwa Lee
> + *
> + * This file is subject to the terms and conditions of the GNU General Public
> + * License. See the file COPYING in the main directory of this archive for
> + * more details.
> + *
> + * EXYNOS Frame Buffer Driver
> + * based on skeletonfb.c, sa1100fb.h, s3c2410fb.c
> + */
> +
> +#ifndef _EXYNOS_FB_H_
> +#define _EXYNOS_FB_H_
> +
> +#define ON 1
> +#define OFF 0
> +
> +#define DEBUG
> +#undef DEBUG
> +#ifdef DEBUG
> +#define udebug(args...) printf(args)
> +#else
> +#define udebug(args...) do { } while (0)
> +#endif
Please don't make private debug macros.
Please use debug macro.
> +
> +enum exynos_fb_rgb_mode_t {
> + MODE_RGB_P = 0,
> + MODE_BGR_P = 1,
> + MODE_RGB_S = 2,
> + MODE_BGR_S = 3,
> +};
> +
> +enum s3cfb_cpu_auto_cmd_rate {
s3c? exynos?
Please make it clearly.
> + DISABLE_AUTO_FRM,
> + PER_TWO_FRM,
> + PER_FOUR_FRM,
> + PER_SIX_FRM,
> + PER_EIGHT_FRM,
> + PER_TEN_FRM,
> + PER_TWELVE_FRM,
> + PER_FOURTEEN_FRM,
> + PER_SIXTEEN_FRM,
> + PER_EIGHTEEN_FRM,
> + PER_TWENTY_FRM,
> + PER_TWENTY_TWO_FRM,
> + PER_TWENTY_FOUR_FRM,
> + PER_TWENTY_SIX_FRM,
> + PER_TWENTY_EIGHT_FRM,
> + PER_THIRTY_FRM,
> +};
> +
> +void exynos_fimd_lcd_init_mem(unsigned long screen_base, unsigned long
> fb_size,
> + unsigned long palette_size);
> +void exynos_fimd_lcd_init(vidinfo_t *vid);
> +unsigned long exynos_fimd_calc_fbsize(void);
> +void exynos_c100_gpio_setup(void);
> +void exynos_c110_gpio_setup(void);
Is it use somewhere?
> +
> +#endif
> +
> diff --git a/drivers/video/exynos_fimd.c b/drivers/video/exynos_fimd.c
> new file mode 100644
> index 000..4822741
> --- /dev/null
> +++ b/drivers/video/exynos_fimd.c
> @@ -0,0 +1,416 @@
> +/*
> + * exynos LCD Controller Specific driver.
> + *
> + * Author: InKi Dae
> + * Author: Donghwa Lee
> + *
> + * 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
Re: [U-Boot] [PATCH 5/5] ARM: EXYNOS: add Makefile for exynos display driver
On 30 March 2012 10:59, Donghwa Lee wrote: > Update Makefile for EXYNOS display driver. > > Signed-off-by: Donghwa Lee > Signed-off-by: Inki Dae > Signed-off-by: Kyungmin Park > --- > drivers/video/Makefile | 1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > diff --git a/drivers/video/Makefile b/drivers/video/Makefile > index 6252f6a..8896abe 100644 > --- a/drivers/video/Makefile > +++ b/drivers/video/Makefile > @@ -28,6 +28,7 @@ LIB := $(obj)libvideo.o > COBJS-$(CONFIG_ATI_RADEON_FB) += ati_radeon_fb.o videomodes.o > COBJS-$(CONFIG_ATMEL_LCD) += atmel_lcdfb.o > COBJS-$(CONFIG_CFB_CONSOLE) += cfb_console.o > +COBJS-$(CONFIG_EXYNOS_FB) += exynos_fb.o exynos_fimd.o > COBJS-$(CONFIG_FSL_DIU_FB) += fsl_diu_fb.o videomodes.o > COBJS-$(CONFIG_S6E63D6) += s6e63d6.o > COBJS-$(CONFIG_SED156X) += sed156x.o This patch should be merged into patch4. Thanks Minkyu Kang. -- from. prom. www.promsoft.net ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/5] ARM: EXYNOS: add exynos lcd clock interface
Donghwa,
On 30 March 2012 10:59, Donghwa Lee wrote:
> To get lcd source clock in EXYNOS display driver, added get_lcd_clk()
> interface.
>
> Signed-off-by: Donghwa Lee
> Signed-off-by: Inki Dae
> Signed-off-by: Kyungmin Park
> ---
> arch/arm/cpu/armv7/exynos/clock.c | 50
> +
> 1 files changed, 50 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/cpu/armv7/exynos/clock.c
> b/arch/arm/cpu/armv7/exynos/clock.c
> index 2f7048b..af66d5c 100644
> --- a/arch/arm/cpu/armv7/exynos/clock.c
> +++ b/arch/arm/cpu/armv7/exynos/clock.c
> @@ -414,6 +414,51 @@ static void exynos5_set_mmc_clk(int dev_index, unsigned
> int div)
> writel(val, addr);
> }
>
> +/* get_lcd_clk: return lcd clock frequency */
> +static unsigned long exynos4_get_lcd_clk(void)
> +{
> + struct exynos4_clock *clk =
> + (struct exynos4_clock *)samsung_get_base_clock();
> + unsigned long pclk, sclk;
> + unsigned int sel;
> + unsigned int ratio;
> +
> + /*
> + * CLK_SRC_LCD0
> + * FIMD0_SEL [3:0]
> + */
> +#if defined(CONFIG_EXYNOS4210)
> + sel = readl(&clk->src_lcd0);
> +#else
> + sel = readl(&clk->src_lcd);
> +#endif
You should split the function for exynos4 and exynos5.
Please don't use ifdef.
> + sel = sel & 0xf;
> +
> + if (sel == 0x6)
> + sclk = get_pll_clk(MPLL);
> + else if (sel == 0x7)
> + sclk = get_pll_clk(EPLL);
> + else if (sel == 0x8)
> + sclk = get_pll_clk(VPLL);
> + else
> + return 0;
> +
> + /*
> + * CLK_DIV_LCD0
> + * FIMD0_RATIO [3:0]
> + */
> +#if defined(CONFIG_EXYNOS4210)
> + ratio = readl(&clk->div_lcd0);
> +#else
> + ratio = readl(&clk->div_lcd);
> +#endif
> + ratio = ratio & 0xf;
> +
> + pclk = sclk / (ratio + 1);
> +
> + return pclk;
> +}
> +
> unsigned long get_pll_clk(int pllreg)
> {
> if (cpu_is_exynos5())
> @@ -453,3 +498,8 @@ void set_mmc_clk(int dev_index, unsigned int div)
> else
> exynos4_set_mmc_clk(dev_index, div);
> }
> +
> +unsigned long get_lcd_clk(void)
> +{
> + return exynos4_get_lcd_clk();
> +}
Thanks.
Minkyu Kang.
--
from. prom.
www.promsoft.net
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/5]: ARM: EXYNOS: add data structure for EXYNOS display driver
On 30 March 2012 10:59, Donghwa Lee wrote:
> add vidinfo data structure for EXYNOS display driver.
>
> Signed-off-by: Donghwa Lee
> Signed-off-by: Inki Dae
> Signed-off-by: Kyungmin Park
> ---
> include/lcd.h | 63
> -
> 1 files changed, 62 insertions(+), 1 deletions(-)
>
> diff --git a/include/lcd.h b/include/lcd.h
> index d95feeb..b2a1bc4 100644
> --- a/include/lcd.h
> +++ b/include/lcd.h
> @@ -195,7 +256,6 @@ typedef struct vidinfo {
>
> void *priv; /* Pointer to driver-specific data */
> } vidinfo_t;
> -
unrelated change.
> #endif /* CONFIG_MPC823, CONFIG_CPU_PXA25X, CONFIG_MCC200, CONFIG_ATMEL_LCD
> */
>
> extern vidinfo_t panel_info;
> @@ -213,6 +273,7 @@ void lcd_puts (const char *s);
> void lcd_printf (const char *fmt, ...);
> void lcd_clear(void);
> int lcd_display_bitmap(ulong bmp_image, int x, int y);
> +void init_panel_info (vidinfo_t *vid);
>
> /* Allow boards to customize the information displayed */
> void lcd_show_board_info(void);
> --
Thanks.
Minkyu Kang
--
from. prom.
www.promsoft.net
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] BDI2000 config file for mx35pdk
Hi ! Does someone has a working BDI2000 configuration file for Freescale's mx35pdk ? Thanks ! Gabriel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] BDI2000 config file for mx35pdk
On 30/03/2012 11:12, Gabriel Tisan wrote: > Hi ! > > Does someone has a working BDI2000 configuration file for Freescale's mx35pdk > ? > Hi Gabriel, we are OT here. Anyway, the following configuration worked for me: [INIT] WCP15 0x0001 0x00050078; CP15 control register WCP15 0x0707 0x; CP15 invalidate I&D WCP15 0x0708 0x; CP15 invalidate TLB WCP15 0x4A07 0x; CP15 clean write buf. ; RAM Initialization ;WEIM config CS5 ;WM32 0xB8002050 0xd843 ;WM32 0xB8002054 0x22252521 ;WM32 0xB8002058 0x0a00 ; DDR2 init ;WM32 0xB8001010 0x0304 ;WM32 0xB8001010 0x030C ;WM32 0xB8001004 0x007ffc3f ;WM32 0xB8001000 0x9222 ;WM32 0x8400 0x12345678 ;WM32 0xB8001000 0xA222 ;WM32 0x8000 0x87654321 ;WM32 0x8000 0x87654321 ;WM32 0xB8001000 0xB222 ;WM8 0x8233 0xda ;WM8 0x82000780 0xda ;WM8 0x82000400 0xda ;WM32 0xB8001000 0x82226080 ;WM32 0xB8001004 0x007ffc3f ;WM32 0xB800100C 0x007ffc3f ;WM32 0xB8001010 0x0304 ;WM32 0xB8001008 0x2000 [TARGET] CPUTYPE ARM1136 ;CLOCK 1 ;JTAG clock (0=Adaptive,1=16MHz,2=8MHz,3=4MHz) ;;;CLOCK 0 10 ;JTAG clock : start with 10 kHz then use adaptive CLOCK 3 10;JTAG clock : start with 10 kHz then use 4MHz POWERUP 3000;start delay after power-up detected in ms RESET HARD 100;assert reset for 100 ms ;WAKEUP 100 ;wait after reset released ;STARTUP STOP 2000 ;let boot ROM setup the system ENDIAN LITTLE ;memory model (LITTLE | BIG) ;VECTOR CATCH 0x1f ;catch D_Abort, P_Abort, SWI, Undef and Reset VECTOR CATCH 0x00 ;do not catch any vector BREAKMODE HARD;SOFT or HARD ;BREAKMODE SOFT;SOFT or HARD ; SCANPRED2 9 ; SCANSUCC1 4 ; the ETMBUF after the ARM1136 core ; ; ; !!! Enable to following SCANINIT lines for BDI2000 firmware V1.04 ; !!! Not needed for V1.03 and for upcomming firmware updates. ; SCANINIT r1:t1:w1000:t0:w1000: ;assert reset and toggle TRST SCANINIT r0:w1: ;release reset and wait SCANINIT ch5:w100 ;clock TCK with TMS high and wait ; [HOST] PROMPT mx35pdk> FORMAT BIN FILEmx35pdk/u-boot.bin [FLASH] WORKSPACE 0x1fffc000 ;workspace in internal SRAM CHIPTYPES29M32X16 ;Flash type is S29WS256N CHIPSIZE0x200 ;The size of one flash chip in bytes BUSWIDTH16 ;The width of the flash memory bus FILEmx35pdk/u-boot.bin FORMAT BIN 0xa000 ERASE 0xa000 UNLOCK ERASE 0xa002 UNLOCK ERASE 0xa004 UNLOCK ERASE 0xa006 UNLOCK [REGS] FILEBDI2000/abatron/bdigdb/config/arm11/regIMX31.def 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] lsxl: add support for lschlv2 and lsxhl
> -Original Message- > From: Michael Walle [mailto:mich...@walle.cc] > Sent: 29 March 2012 20:09 > To: Prafulla Wadaskar > Cc: u-boot@lists.denx.de > Subject: Re: [PATCH v2] lsxl: add support for lschlv2 and lsxhl > > Am Donnerstag 29 März 2012, 16:24:23 schrieb Prafulla Wadaskar: > > > -Original Message- > > > From: Michael Walle [mailto:mich...@walle.cc] > > > Sent: 29 March 2012 18:08 > > > To: Prafulla Wadaskar > > > Cc: u-boot@lists.denx.de > > > Subject: Re: [PATCH v2] lsxl: add support for lschlv2 and lsxhl > > > > > > Am Dienstag 27 März 2012, 09:27:49 schrieb Prafulla Wadaskar: > > > > > # diff --git a/board/buffalo/lsxl/config.mk > > > > > b/board/buffalo/lsxl/config.mk new file mode 100644 > > > > > index 000..062554b > > > > > --- /dev/null > > > > > +++ b/board/buffalo/lsxl/config.mk > > > > > @@ -0,0 +1 @@ > > > > > +ALL-y += $(obj)u-boot.kwb > > > > > > > > Pls remove this file > > > > > > Is there another way to build the u-boot.kwb binary by default? > > > > > > The main Makefile states: > > > # Always append ALL so that arch config.mk's can add custom ones > > > > > > and theres a rule for $(obj)u-boot.kwb. > > > > Just pass u-boot.kwm to the make, will do the needful, if this > satisfies > > the goal of generating u-boot.kwb, then why to add one file to the > source > > code? > - this won't work easily for out-of-tree builds, will it? because you > have to > pass $(obj)u-boot.kwb to make and $(obj) is $O which is specified by > the user, > so he has to specify it twice Dear Michael, AFAIK, you need to pass only "u-boot.kwb" to the make (no $(okj) needed) > - i'm only interested in the u-boot.kwb, why shouldn't it be > generated by > default? > - i can't build it with a sinlge make call. Eg. atm i'm doing > make -j3 -C ../u-boot O=`pwd` CROSS_COMPILE=arm-linux-gnueabi- > lschlv2 >otherwise i have to do > make -j3 -C ../u-boot O=`pwd` CROSS_COMPILE=arm-linux-gnueabi- > lschlv2 > make -j3 -C ../u-boot O=`pwd` CROSS_COMPILE=arm-linux-gnueabi- \ >`pwd`/u-boot.kwb "make u-boot.kwb CROSS_COMPILE=arm-linux-gnueabi-" generates u-boot.kwb, this should be valid with other use case too. if not, it makes sense to add an additional line in script that a file in code :-) Regards.. Prafulla . .. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] spi/kirkwood: add weak functions board_spi_bus_claim/release
> -Original Message- > From: Valentin Longchamp [mailto:valentin.longch...@keymile.com] > Sent: 29 March 2012 21:15 > To: Prafulla Wadaskar > Cc: u-boot@lists.denx.de; Gerlando Falauto; Holger Brunck > Subject: Re: [PATCH v2] spi/kirkwood: add weak functions > board_spi_bus_claim/release > > Hi Prafulla, > > On 03/29/2012 02:49 PM, Valentin Longchamp wrote: > > On 03/28/2012 09:48 AM, Prafulla Wadaskar wrote: > >> Basically spi_claim_bus and spi_release_bus are not supported in > current Kirkwood spi driver. > >> These are needed if someone wish to share the same interface pins > with some other peripheral (that is your use case) > > > > Correct, this is exactly our use case: we have the NAND Flash > Controller and the > > SPI controller that share the same pins. > > > >> > >> But this is not board specific whereas, it should be feature > enhancement for Kirkwood spi driver. > > > > This is correct for the mpp part of spi_claim_bus. If you look at > the actual > > implementation that we do in our board specific function, there is > an additional > > step that is needed by our board design. > > > > I have started to implement this, and now I see that with your > approach of doing > the mpp part in the driver does not work and my proposed solution of > doing this > with board specific functions is the correct one: > > The SPI_SI, SPI_SCK, SPI_CSn all can be used with different mpp > configuration. > This is a board design parameter. How can the driver know which one is > used on > the board ? Dear Valentin You should keep by default NF configuration in your board configuration (kwmpp_config), so this becomes your default mpp configuration. If SPI flash is being accessed, all spi_flash calls are guarded with claim_bus and release_bus APIs. In Kirkwood specific claim_bus API, you will backup default configuration (which is NF in your case) for these particular pins (SPI_SI, SPI_SCK, SPI_CSn, MOSI, MISO). and in release_bus API, you will reconfigure backed-up mpp configuration (which will be NF in your case). With this you don't need km_hw_spi_bus_claim() or do_spi_toggle() in your board specific code any more. How come this doesn't work? It should work, if not let's debug the problem. Regards.. Prafulla . . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] spi/kirkwood: add weak functions board_spi_bus_claim/release
Hi Prafulla, For the simplicity of the discussion, I have removed everything in the discussion that is not relevant for the current open point. On 03/30/2012 01:34 PM, Prafulla Wadaskar wrote: > In Kirkwood specific claim_bus API, you will backup default configuration > (which is NF in your case) for these particular pins (SPI_SI, SPI_SCK, > SPI_CSn, MOSI, MISO). But which MPP are these particular pins ? Let's have a look at a single signal, SPI_SCK for instance. From the 88F6281 Hardware Spec [1], page 53, SPI_SCK can be MPP[2], MPP[10]. How can the generic driver know which one actually is wired to the SPI device SCK pin on the currently running hardware (when none is configured as then, since by default for us MPP[2] is NF_IO[4] and MPP[10] is UA0_TXD ) ? This is a board specific ! If you tell me how I easily can find this out in the kirkwood driver, I will be happy to implement your proposed solution. Otherwise, I think we should stick with the board specific function. [1] http://www.marvell.com/embedded-processors/kirkwood/assets/HW_88F6281_OpenSource.pdf Regards -- Valentin Longchamp Embedded Software Engineer Hardware and Chip Integration __ KEYMILE AG Schwarzenburgstr. 73 CH-3097 Liebefeld Phone +41 31 377 1318 Fax +41 31 377 1212 valentin.longch...@keymile.com www.keymile.com __ KEYMILE: A Specialist as a Partner ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/3] env: unify logic to check and apply changes
On 03/29/2012 10:19 PM, Marek Vasut wrote:
Dear Gerlando Falauto,
WD prodded me too long to review this patchset ;-D
Well, better late than never! ;-)
[...]
+#if defined(CONFIG_CMD_NET)
+ else if (strcmp(name, "bootfile") == 0) {
+ copy_filename(BootFile, newval, sizeof(BootFile));
Can you remove the camel-case here please?
That's code I just moved around... Will do, sir.
+ return 0;
+ }
+#endif
+ return 0;
+}
+
[...]
--- a/include/search.h
+++ b/include/search.h
@@ -47,6 +47,13 @@ typedef struct entry {
struct _ENTRY;
/*
+ * Callback function to be called for checking whether the given change
may + * be applied or not. Must return 0 for approval, 1 for denial.
+ */
+typedef int (*apply_cb)(const char *name, const char *oldval,
+ const char *newval, int flag);
Is the typedef really necessary ?
>[From your other email]
>
> I have to admit I'm not much of a fan of how you use this apply()
> callback, is it really necessary?
>
Why ask, if you already know the answer? :-)
I'm not a big fan either, seemed like the easiest approach at the time.
The idea was to keep the hastable (struct hsearch_data) as decoupled as
possible from the environment (env_htab which is, in fact, the only
instance of struct hsearch_data).
What if the function pointer was stored within the hastable itself?
Sort of a virtual method.
This way we get rid of the typedef and the function pointer as a
parameter altogether.
The callback parameter then just becomes a boolean value (meaning,
do/don't call the callback function stored within the hashtable itself).
I like that much better. What do you think?
[...]
/* Flags for himport_r() */
#define H_NOCLEAR 1 /* do not clear hash table before
importing */
+#define H_FORCE2 /* overwrite read-only/write-once
variables */
Make this 1<< x please.
OK.
#endif /* search.h */
diff --git a/lib/hashtable.c b/lib/hashtable.c
index abd61c8..75b9b07 100644
--- a/lib/hashtable.c
+++ b/lib/hashtable.c
@@ -603,6 +603,22 @@ ssize_t hexport_r(struct hsearch_data *htab, const
char sep, * himport()
*/
+/* Check whether variable name is amongst vars[] */
+static int process_var(const char *name, int nvars, char * const vars[])
You mean check_var()?
I mean is_var_in_set_or_is_set_empty().
Sorry, I'm very, very bad at picking function names.
Any suggestion?
+{
+ int i = 0;
+ /* No variables specified means process all of them */
+ if (nvars == 0)
+ return 1;
+
+ for (i = 0; i< nvars; i++) {
+ if (!strcmp(name, vars[i]))
+ return 1;
+ }
+ debug("Skipping non-listed variable %s\n", name);
+ return 0;
+}
+
/*
* Import linearized data into hash table.
*
@@ -639,7 +655,9 @@ ssize_t hexport_r(struct hsearch_data *htab, const char
sep, */
int himport_r(struct hsearch_data *htab,
- const char *env, size_t size, const char sep, int flag)
+ const char *env, size_t size, const char sep, int flag,
+ int nvars, char * const vars[],
+ apply_cb apply)
{
char *data, *sp, *dp, *name, *value;
@@ -726,6 +744,8 @@ int himport_r(struct hsearch_data *htab,
*dp++ = '\0'; /* terminate name */
debug("DELETE CANDIDATE: \"%s\"\n", name);
+ if (!process_var(name, nvars, vars))
+ continue;
if (hdelete_r(name, htab) == 0)
debug("DELETE ERROR
##\n");
@@ -743,10 +763,31 @@ int himport_r(struct hsearch_data *htab,
*sp++ = '\0'; /* terminate value */
++dp;
+ /* Skip variables which are not supposed to be treated */
+ if (!process_var(name, nvars, vars))
+ continue;
+
/* enter into hash table */
e.key = name;
e.data = value;
Do you need to do this if you eventually later figure out you have no apply()
callback and you did this for no reason?
You mean calling process_var()? It's two separate things.
One, filter out the variables that were not asked to be processed, if
there were any (call to process_var())
Two, check whether the new value is acceptable and/or apply it (call
apply())
You could have none, either, or both.
Or else, if you mean moving the e.key = name, e.data = value
assignments, you're right, they should be moved down (but in that case
it would be because the apply function fails, not because it's not
present -- default case is always successful).
+ /* if there is an apply function, check what it has to say */
+ if (apply != NULL) {
+ debug("searching before calling cb function"
+ " for %s\
Re: [U-Boot] [PATCH v2 3/3] env: make "env default" selective, check and apply
On 03/29/2012 10:25 PM, Marek Vasut wrote:
Dear Gerlando Falauto,
Changes in the syntax (user API) for "env default":
-f: override write-once variables
-a: all (resetting the whole env is NOT the default behavior)
Signed-off-by: Gerlando Falauto
I have to admit I'm not much of a fan of how you use this apply() callback, is
it really necessary?
See my previous email.
Also, do we need special command for default env?
I am sorry, I don't get the question. What do you mean?
It's always the same "env import" with an augmented command line.
If you're referring to CONFIG_CMD_DEFAULTENV_VARS, I don't think it's
neeed either, but it was requested at some previous time.
I also think it's misleading to have some syntax for the same command
conditionally enabled. Has it ever been done before?
Thank you,
Gerlando
M
---
README |2 ++
common/cmd_nvedit.c | 43
--- common/env_common.c |
31 ++-
include/config_cmd_all.h |1 +
include/environment.h|5 +
5 files changed, 74 insertions(+), 8 deletions(-)
diff --git a/README b/README
index fda0190..e924575 100644
--- a/README
+++ b/README
@@ -724,6 +724,8 @@ The following options need to be configured:
CONFIG_CMD_CONSOLEconinfo
CONFIG_CMD_CRC32* crc32
CONFIG_CMD_DATE * support for RTC, date/time...
+ CONFIG_CMD_DEFAULTENV_VARS
+ * Reset individual variables to default
CONFIG_CMD_DHCP * DHCP support
CONFIG_CMD_DIAG * Diagnostics
CONFIG_CMD_DS4510 * ds4510 I2C gpio commands
diff --git a/common/cmd_nvedit.c b/common/cmd_nvedit.c
index 871b3b1..317bd1c 100644
--- a/common/cmd_nvedit.c
+++ b/common/cmd_nvedit.c
@@ -674,14 +674,40 @@ int envmatch(uchar *s1, int i2)
return -1;
}
-static int do_env_default(cmd_tbl_t *cmdtp, int flag,
+static int do_env_default(cmd_tbl_t *cmdtp, int __flag,
int argc, char * const argv[])
{
- if (argc != 2 || strcmp(argv[1], "-f") != 0)
- return cmd_usage(cmdtp);
-
- set_default_env("## Resetting to default environment\n");
- return 0;
+ int all = 0, flag = 0;
+ debug("Initial value for argc=%d\n", argc);
+ while (--argc> 0&& **++argv == '-') {
+ char *arg = *argv;
+ while (*++arg) {
+ switch (*arg) {
+ case 'a': /* default all */
+ all = 1;
+ break;
+ case 'f': /* force */
+ flag |= H_FORCE;
+ break;
+ default:
+ return cmd_usage(cmdtp);
+ }
+ }
+ }
+ debug("Final value for argc=%d\n", argc);
+ if (all&& (argc == 0)) {
+ /* Reset the whole environment */
+ set_default_env("## Resetting to default environment\n");
+ return 0;
+ }
+#ifdef CONFIG_CMD_DEFAULTENV_VARS
+ if (!all&& (argc> 0)) {
+ /* Reset individual variables */
+ env_default_vars(argc, argv);
+ return 0;
+ }
+#endif
+ return cmd_usage(cmdtp);
}
static int do_env_delete(cmd_tbl_t *cmdtp, int flag,
@@ -1012,7 +1038,10 @@ U_BOOT_CMD(
#if defined(CONFIG_CMD_ASKENV)
"ask name [message] [size] - ask for environment variable\nenv "
#endif
- "default -f - reset default environment\n"
+ "default [-f] -a - [forcibly] reset default environment\n"
+#if defined(CONFIG_CMD_DEFAULTENV_VARS)
+ "env default [-f] var [...] - [forcibly] reset variable(s) to their
default values\n" +#endif
#if defined(CONFIG_CMD_EDITENV)
"env edit name - edit environment variable\n"
#endif
diff --git a/common/env_common.c b/common/env_common.c
index 7e2bb2f..56719a6 100644
--- a/common/env_common.c
+++ b/common/env_common.c
@@ -157,6 +157,11 @@ const uchar *env_get_addr(int index)
void set_default_env(const char *s)
{
+ /*
+* By default, do not apply changes as they will eventually
+* be applied by someone else
+*/
+ apply_cb apply_function = NULL;
if (sizeof(default_environment)> ENV_SIZE) {
puts("*** Error - default environment is too large\n\n");
return;
@@ -168,6 +173,14 @@ void set_default_env(const char *s)
"using default environment\n\n",
s + 1);
} else {
+ /*
+* This set_to_default was explicitly asked for
+* by the user, as opposed to being a recovery
+
Re: [U-Boot] [PATCH v2 2/3] mmc: use sdhci.c intead of s5p_mmc.c
On 30 March 2012 11:39, Jaehoon Chung wrote: > In driver mmc, generic sdhci code is implemented. > s5p_mmc file is dupulicated. > we are good that use the generic sdhci. > This patch supported the sdhci for Samsung-SoC. > > Signed-off-by: Jaehoon Chung > Signed-off-by: Kyungmin Park > --- > arch/arm/include/asm/arch-exynos/mmc.h | 93 +++--- > arch/arm/include/asm/arch-s5pc1xx/mmc.h | 93 +++--- > drivers/mmc/Makefile | 2 +- > drivers/mmc/s5p_mmc.c | 490 > --- > drivers/mmc/s5p_sdhci.c | 98 ++ > drivers/mmc/sdhci.c | 12 + > include/sdhci.h | 6 + > 7 files changed, 211 insertions(+), 583 deletions(-) > delete mode 100644 drivers/mmc/s5p_mmc.c > create mode 100644 drivers/mmc/s5p_sdhci.c > Acked-by: Minkyu Kang -- from. prom. www.promsoft.net ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/3] ARM: SAMSUNG: support sdhci controller
On 30 March 2012 11:39, Jaehoon Chung wrote: > To support sdhci controller, remove the CONFIG_S5P_MMC.. > Instead, use the CONFIG_S5P_SDHCI/CONFIG_SDHCI. > > Signed-off-by: Jaehoon Chung > Signed-off-by: Kyungmin Park > --- > include/configs/origen.h | 3 ++- > include/configs/s5p_goni.h | 3 ++- > include/configs/s5pc210_universal.h | 3 ++- > include/configs/smdk5250.h | 3 ++- > include/configs/smdkv310.h | 3 ++- > include/configs/trats.h | 3 ++- > 6 files changed, 12 insertions(+), 6 deletions(-) > Acked-by: Minkyu Kang -- from. prom. www.promsoft.net ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] spi/kirkwood: add weak functions board_spi_bus_claim/release
> -Original Message- > From: Valentin Longchamp [mailto:valentin.longch...@keymile.com] > Sent: 30 March 2012 17:45 > To: Prafulla Wadaskar > Cc: u-boot@lists.denx.de; Gerlando Falauto; Holger Brunck > Subject: Re: [PATCH v2] spi/kirkwood: add weak functions > board_spi_bus_claim/release > > Hi Prafulla, > > For the simplicity of the discussion, I have removed everything in the > discussion that is not relevant for the current open point. > > On 03/30/2012 01:34 PM, Prafulla Wadaskar wrote: > > In Kirkwood specific claim_bus API, you will backup default > configuration (which is NF in your case) for these particular pins > (SPI_SI, SPI_SCK, SPI_CSn, MOSI, MISO). > > But which MPP are these particular pins ? > > Let's have a look at a single signal, SPI_SCK for instance. From the > 88F6281 > Hardware Spec [1], page 53, SPI_SCK can be MPP[2], MPP[10]. How can > the generic > driver know which one actually is wired to the SPI device SCK pin on > the > currently running hardware (when none is configured as then, since by > default > for us MPP[2] is NF_IO[4] and MPP[10] is UA0_TXD ) ? This is a board > specific ! > > If you tell me how I easily can find this out in the kirkwood driver, Dear Valentin Please make a use of CONFIG_SF_DEFAULT_CS for this. By default this is defined to 0, lets map it to our default use case i.e. using MPP0-3 for default SPI signals One may pre-define this in his board config as per specific need, and we can use this effectively in Kirkwood_spi driver. i.e. bit0 to be used to configure SPI_CSn bit1 to be used to configure SPI_MOSI... and so on so if my needs are to use 1. MPP7 as SPI_CSn I will define CONFIG_SF_DEFAULT_CS to 0x01 2. MPP6 as SPI_MOSI I will define CONFIG_SF_DEFAULT_CS to 0x02 2. MPP6 as SPI_MOSI and MPP7 as SPI_CSn, I will define CONFIG_SF_DEFAULT_CS to 0x03 .. and so on. Regards.. Prafulla . . . > I will be > happy to implement your proposed solution. Otherwise, I think we > should stick > with the board specific function. > > [1] > http://www.marvell.com/embedded- > processors/kirkwood/assets/HW_88F6281_OpenSource.pdf > > Regards > > -- > Valentin Longchamp > Embedded Software Engineer > Hardware and Chip Integration > __ > KEYMILE AG > Schwarzenburgstr. 73 > CH-3097 Liebefeld > Phone +41 31 377 1318 > Fax +41 31 377 1212 > valentin.longch...@keymile.com > www.keymile.com > __ > KEYMILE: A Specialist as a Partner ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/3] env: unify logic to check and apply changes
Dear Gerlando Falauto,
> On 03/29/2012 10:19 PM, Marek Vasut wrote:
> > Dear Gerlando Falauto,
> >
> > WD prodded me too long to review this patchset ;-D
>
> Well, better late than never! ;-)
>
> [...]
>
> >> +#if defined(CONFIG_CMD_NET)
> >> + else if (strcmp(name, "bootfile") == 0) {
> >> + copy_filename(BootFile, newval, sizeof(BootFile));
> >
> > Can you remove the camel-case here please?
>
> That's code I just moved around... Will do, sir.
Don't call me that way, makes me feel old :D
> >> + return 0;
> >> + }
> >> +#endif
> >> + return 0;
> >> +}
> >> +
>
> [...]
>
> >> --- a/include/search.h
> >> +++ b/include/search.h
> >> @@ -47,6 +47,13 @@ typedef struct entry {
> >>
> >> struct _ENTRY;
> >>
> >> /*
> >>
> >> + * Callback function to be called for checking whether the given change
> >> may + * be applied or not. Must return 0 for approval, 1 for denial.
> >> + */
> >> +typedef int (*apply_cb)(const char *name, const char *oldval,
> >> + const char *newval, int flag);
> >
> > Is the typedef really necessary ?
> >
> >[From your other email]
> >
> > I have to admit I'm not much of a fan of how you use this apply()
> > callback, is it really necessary?
>
> Why ask, if you already know the answer? :-)
>
> I'm not a big fan either, seemed like the easiest approach at the time.
> The idea was to keep the hastable (struct hsearch_data) as decoupled as
> possible from the environment (env_htab which is, in fact, the only
> instance of struct hsearch_data).
>
> What if the function pointer was stored within the hastable itself?
> Sort of a virtual method.
> This way we get rid of the typedef and the function pointer as a
> parameter altogether.
> The callback parameter then just becomes a boolean value (meaning,
> do/don't call the callback function stored within the hashtable itself).
> I like that much better. What do you think?
Don't we always use only one (this callback) function?
>
> [...]
>
> >> /* Flags for himport_r() */
> >> #define H_NOCLEAR 1 /* do not clear hash table before
> >
> > importing */
> >
> >> +#define H_FORCE 2 /* overwrite read-only/write-once
> >
> > variables */
> >
> > Make this 1<< x please.
>
> OK.
>
> >> #endif /* search.h */
> >>
> >> diff --git a/lib/hashtable.c b/lib/hashtable.c
> >> index abd61c8..75b9b07 100644
> >> --- a/lib/hashtable.c
> >> +++ b/lib/hashtable.c
> >> @@ -603,6 +603,22 @@ ssize_t hexport_r(struct hsearch_data *htab, const
> >> char sep, * himport()
> >>
> >>*/
> >>
> >> +/* Check whether variable name is amongst vars[] */
> >> +static int process_var(const char *name, int nvars, char * const
> >> vars[])
> >
> > You mean check_var()?
>
> I mean is_var_in_set_or_is_set_empty().
Nice name :)
> Sorry, I'm very, very bad at picking function names.
> Any suggestion?
The above is quite descriptive ... maybe is_var_in_set() ? And hey, don't be
sorry, you're doing very good job!
>
> >> +{
> >> + int i = 0;
> >> + /* No variables specified means process all of them */
> >> + if (nvars == 0)
> >> + return 1;
> >> +
> >> + for (i = 0; i< nvars; i++) {
> >> + if (!strcmp(name, vars[i]))
> >> + return 1;
> >> + }
> >> + debug("Skipping non-listed variable %s\n", name);
> >> + return 0;
> >> +}
> >> +
> >>
> >> /*
> >>
> >>* Import linearized data into hash table.
> >>*
> >>
> >> @@ -639,7 +655,9 @@ ssize_t hexport_r(struct hsearch_data *htab, const
> >> char sep, */
> >>
> >> int himport_r(struct hsearch_data *htab,
> >>
> >> -const char *env, size_t size, const char sep, int flag)
> >> + const char *env, size_t size, const char sep, int flag,
> >> + int nvars, char * const vars[],
> >> + apply_cb apply)
> >>
> >> {
> >>
> >>char *data, *sp, *dp, *name, *value;
> >>
> >> @@ -726,6 +744,8 @@ int himport_r(struct hsearch_data *htab,
> >>
> >>*dp++ = '\0'; /* terminate name */
> >>
> >>debug("DELETE CANDIDATE: \"%s\"\n", name);
> >>
> >> + if (!process_var(name, nvars, vars))
> >> + continue;
> >>
> >>if (hdelete_r(name, htab) == 0)
> >>
> >>debug("DELETE ERROR
> >
> > ##\n");
> >
> >> @@ -743,10 +763,31 @@ int himport_r(struct hsearch_data *htab,
> >>
> >>*sp++ = '\0'; /* terminate value */
> >>++dp;
> >>
> >> + /* Skip variables which are not supposed to be treated */
> >> + if (!process_var(name, nvars, vars))
> >> + continue;
> >> +
> >>
> >>/* enter into hash table */
> >>e.key = name;
> >>e.data = value;
> >
> > Do you need to do this if you eventually later figure out you have no
> > apply() callback and you did this for no reason?
Re: [U-Boot] [PATCH v2 3/3] env: make "env default" selective, check and apply
Dear Gerlando Falauto,
> On 03/29/2012 10:25 PM, Marek Vasut wrote:
> > Dear Gerlando Falauto,
> >
> >> Changes in the syntax (user API) for "env default":
> >>-f: override write-once variables
> >>-a: all (resetting the whole env is NOT the default behavior)
> >>
> >> Signed-off-by: Gerlando Falauto
> >
> > I have to admit I'm not much of a fan of how you use this apply()
> > callback, is it really necessary?
>
> See my previous email.
>
> > Also, do we need special command for default env?
>
> I am sorry, I don't get the question. What do you mean?
> It's always the same "env import" with an augmented command line.
> If you're referring to CONFIG_CMD_DEFAULTENV_VARS, I don't think it's
> neeed either, but it was requested at some previous time.
Hmm.
> I also think it's misleading to have some syntax for the same command
> conditionally enabled. Has it ever been done before?
Yes it was, but this is creepy -- is this command displaying the compiled-in
set
of env vars?
>
> Thank you,
> Gerlando
>
> > M
> >
> >> ---
> >>
> >> README |2 ++
> >> common/cmd_nvedit.c | 43
> >>
> >> --- common/env_common.c |
> >> 31 ++-
> >>
> >> include/config_cmd_all.h |1 +
> >> include/environment.h|5 +
> >> 5 files changed, 74 insertions(+), 8 deletions(-)
> >>
> >> diff --git a/README b/README
> >> index fda0190..e924575 100644
> >> --- a/README
> >> +++ b/README
> >>
> >> @@ -724,6 +724,8 @@ The following options need to be configured:
> >>CONFIG_CMD_CONSOLEconinfo
> >>CONFIG_CMD_CRC32* crc32
> >>CONFIG_CMD_DATE * support for RTC, date/time...
> >>
> >> + CONFIG_CMD_DEFAULTENV_VARS
> >> + * Reset individual variables to default
> >>
> >>CONFIG_CMD_DHCP * DHCP support
> >>CONFIG_CMD_DIAG * Diagnostics
> >>CONFIG_CMD_DS4510 * ds4510 I2C gpio commands
> >>
> >> diff --git a/common/cmd_nvedit.c b/common/cmd_nvedit.c
> >> index 871b3b1..317bd1c 100644
> >> --- a/common/cmd_nvedit.c
> >> +++ b/common/cmd_nvedit.c
> >> @@ -674,14 +674,40 @@ int envmatch(uchar *s1, int i2)
> >>
> >>return -1;
> >>
> >> }
> >>
> >> -static int do_env_default(cmd_tbl_t *cmdtp, int flag,
> >> +static int do_env_default(cmd_tbl_t *cmdtp, int __flag,
> >>
> >> int argc, char * const argv[])
> >>
> >> {
> >>
> >> - if (argc != 2 || strcmp(argv[1], "-f") != 0)
> >> - return cmd_usage(cmdtp);
> >> -
> >> - set_default_env("## Resetting to default environment\n");
> >> - return 0;
> >> + int all = 0, flag = 0;
> >> + debug("Initial value for argc=%d\n", argc);
> >> + while (--argc> 0&& **++argv == '-') {
> >> + char *arg = *argv;
> >> + while (*++arg) {
> >> + switch (*arg) {
> >> + case 'a': /* default all */
> >> + all = 1;
> >> + break;
> >> + case 'f': /* force */
> >> + flag |= H_FORCE;
> >> + break;
> >> + default:
> >> + return cmd_usage(cmdtp);
> >> + }
> >> + }
> >> + }
> >> + debug("Final value for argc=%d\n", argc);
> >> + if (all&& (argc == 0)) {
> >> + /* Reset the whole environment */
> >> + set_default_env("## Resetting to default environment\n");
> >> + return 0;
> >> + }
> >> +#ifdef CONFIG_CMD_DEFAULTENV_VARS
> >> + if (!all&& (argc> 0)) {
> >> + /* Reset individual variables */
> >> + env_default_vars(argc, argv);
> >> + return 0;
> >> + }
> >> +#endif
> >> + return cmd_usage(cmdtp);
> >>
> >> }
> >>
> >> static int do_env_delete(cmd_tbl_t *cmdtp, int flag,
> >>
> >> @@ -1012,7 +1038,10 @@ U_BOOT_CMD(
> >>
> >> #if defined(CONFIG_CMD_ASKENV)
> >>
> >>"ask name [message] [size] - ask for environment variable\nenv "
> >>
> >> #endif
> >>
> >> - "default -f - reset default environment\n"
> >> + "default [-f] -a - [forcibly] reset default environment\n"
> >> +#if defined(CONFIG_CMD_DEFAULTENV_VARS)
> >> + "env default [-f] var [...] - [forcibly] reset variable(s) to their
> >> default values\n" +#endif
> >>
> >> #if defined(CONFIG_CMD_EDITENV)
> >>
> >>"env edit name - edit environment variable\n"
> >>
> >> #endif
> >>
> >> diff --git a/common/env_common.c b/common/env_common.c
> >> index 7e2bb2f..56719a6 100644
> >> --- a/common/env_common.c
> >> +++ b/common/env_common.c
> >> @@ -157,6 +157,11 @@ const uchar *env_get_addr(int index)
> >>
> >> void set_default_env(const char *s)
> >> {
> >>
> >> + /*
> >> + * By default, do not apply changes as they will eventually
> >> + * be applied by someone
Re: [U-Boot] [ARM] Status for 2012.03
+Marek
Hi Albert,
On Fri, Mar 30, 2012 at 12:08 AM, Albert ARIBAUD
wrote:
> Le 27/03/2012 22:18, Albert ARIBAUD a écrit :
>>
>> Hi all,
>>
>>
>> I have been away from the list quite a few days, and will have a very
>> tricky time catching up, so with my apologies, I ask people who need me
>> to apply patches or pull requests for the upcoming release to please
>> send me a private e-mail and point me to the list message that I should
>> be acting upon.
>
>
> FWIW, ./MAKEALL arm on current u-boot-arm/master with CS toolchain 2010q1
> builds 277 boards, of which none has errors and 167 have warnings.
>
> The total count of warnings is 248, distributed as:
>
> 4 post.c:503: warning: #warning "Not implemented yet"
>
> 79 mmc.c:132: warning: no return statement in function returning
> non-void
>
> 165 ohci-hcd.c:{1307,1310,1313}: warning: dereferencing pointer
> 'pretmp.NNN' does break strict-aliasing rules
I did create a patch for this - it is marked delegated to Marek.
http://patchwork.ozlabs.org/patch/134600/
>
> (the last one is actually 3 * 51 warnings)
>
> The first one is obvious and should be dealt with, but I consider it not to
> be a blocker, for only 4 boards.
>
> The second one seems straightforward to fix today, if not already submitted.
>
> The third one may be an issue, but it could also be a zealous warning from
> the specific CS toolchain version I am using. Anyway, it does not seem ARM
> related as such.
Would be nice to get rid of it, but I think it is specific to some toolchains.
>
> Therefore I will issue the ARM pull request right away.
>
>
> Amicalement,
> --
> Albert.
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/3] env: unify logic to check and apply changes
On 03/30/2012 03:08 PM, Marek Vasut wrote:
Dear Gerlando Falauto,
On 03/29/2012 10:19 PM, Marek Vasut wrote:
Dear Gerlando Falauto,
WD prodded me too long to review this patchset ;-D
Well, better late than never! ;-)
[...]
+#if defined(CONFIG_CMD_NET)
+ else if (strcmp(name, "bootfile") == 0) {
+ copy_filename(BootFile, newval, sizeof(BootFile));
Can you remove the camel-case here please?
That's code I just moved around... Will do, sir.
Don't call me that way, makes me feel old :D
Was more of a way to remark authority than age. :-)
+ return 0;
+ }
+#endif
+ return 0;
+}
+
[...]
--- a/include/search.h
+++ b/include/search.h
@@ -47,6 +47,13 @@ typedef struct entry {
struct _ENTRY;
/*
+ * Callback function to be called for checking whether the given change
may + * be applied or not. Must return 0 for approval, 1 for denial.
+ */
+typedef int (*apply_cb)(const char *name, const char *oldval,
+ const char *newval, int flag);
Is the typedef really necessary ?
>[From your other email]
>
> I have to admit I'm not much of a fan of how you use this apply()
> callback, is it really necessary?
Why ask, if you already know the answer? :-)
I'm not a big fan either, seemed like the easiest approach at the time.
The idea was to keep the hastable (struct hsearch_data) as decoupled as
possible from the environment (env_htab which is, in fact, the only
instance of struct hsearch_data).
What if the function pointer was stored within the hastable itself?
Sort of a virtual method.
This way we get rid of the typedef and the function pointer as a
parameter altogether.
The callback parameter then just becomes a boolean value (meaning,
do/don't call the callback function stored within the hashtable itself).
I like that much better. What do you think?
Don't we always use only one (this callback) function?
Yes, but only because env is the only hashtable present.
Is that a yes or a no, then?
[...]
/* Flags for himport_r() */
#define H_NOCLEAR 1 /* do not clear hash table before
importing */
+#define H_FORCE2 /* overwrite read-only/write-once
variables */
Make this 1<< x please.
OK.
#endif /* search.h */
diff --git a/lib/hashtable.c b/lib/hashtable.c
index abd61c8..75b9b07 100644
--- a/lib/hashtable.c
+++ b/lib/hashtable.c
@@ -603,6 +603,22 @@ ssize_t hexport_r(struct hsearch_data *htab, const
char sep, * himport()
*/
+/* Check whether variable name is amongst vars[] */
+static int process_var(const char *name, int nvars, char * const
vars[])
You mean check_var()?
I mean is_var_in_set_or_is_set_empty().
Nice name :)
Sorry, I'm very, very bad at picking function names.
Any suggestion?
The above is quite descriptive ... maybe is_var_in_set() ? And hey, don't be
sorry, you're doing very good job!
I like is_var_in_set().
Thanks,
Gerlando
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/3] env: make "env default" selective, check and apply
On 03/30/2012 03:09 PM, Marek Vasut wrote: Dear Gerlando Falauto, On 03/29/2012 10:25 PM, Marek Vasut wrote: Dear Gerlando Falauto, Changes in the syntax (user API) for "env default": -f: override write-once variables -a: all (resetting the whole env is NOT the default behavior) Signed-off-by: Gerlando Falauto I have to admit I'm not much of a fan of how you use this apply() callback, is it really necessary? See my previous email. Also, do we need special command for default env? I am sorry, I don't get the question. What do you mean? It's always the same "env import" with an augmented command line. If you're referring to CONFIG_CMD_DEFAULTENV_VARS, I don't think it's neeed either, but it was requested at some previous time. Hmm. I also think it's misleading to have some syntax for the same command conditionally enabled. Has it ever been done before? Yes it was, but this is creepy -- is this command displaying the compiled-in set of env vars? Nope, "env default" will reset the environment to the default. I just made it selective, so that you can specify a subset of variables to be restored to default. I also changed the meaning of "-f", which used to mean "all", and now means "force", and added "-a" which now means "all". Thank you, Gerlando ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] post: remove #warning for kirkwood CPUs
Since commit 96f5c4b the needed functions (get_ticks() and get_tbclk() )
are defined for kirkwood CPUs as well. This warning is then not relevant
anymore.
Signed-off-by: Valentin Longchamp
cc: Holger Brunck
cc: Prafulla Wadaskar
cc: Albert Aribaud
---
post/post.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/post/post.c b/post/post.c
index 8705b12..3b83ce2 100644
--- a/post/post.c
+++ b/post/post.c
@@ -495,8 +495,7 @@ void post_reloc(void)
*/
unsigned long post_time_ms(unsigned long base)
{
-#if defined(CONFIG_PPC) || defined(CONFIG_BLACKFIN) || \
-(defined(CONFIG_ARM) && !defined(CONFIG_KIRKWOOD))
+#if defined(CONFIG_PPC) || defined(CONFIG_BLACKFIN) || defined(CONFIG_ARM)
return (unsigned long)lldiv(get_ticks(), get_tbclk() / CONFIG_SYS_HZ)
- base;
#else
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [ARM] Status for 2012.03
Hi Albert, On 03/30/2012 09:08 AM, Albert ARIBAUD wrote: > Le 27/03/2012 22:18, Albert ARIBAUD a écrit : >> Hi all, >> >> I have been away from the list quite a few days, and will have a very >> tricky time catching up, so with my apologies, I ask people who need me >> to apply patches or pull requests for the upcoming release to please >> send me a private e-mail and point me to the list message that I should >> be acting upon. > > FWIW, ./MAKEALL arm on current u-boot-arm/master with CS toolchain 2010q1 > builds > 277 boards, of which none has errors and 167 have warnings. > > The total count of warnings is 248, distributed as: > > 4post.c:503: warning: #warning "Not implemented yet" The 4 warnings come from our boards (Keymile ARM boards). > The first one is obvious and should be dealt with, but I consider it not to > be a > blocker, for only 4 boards. > I have just sent a patch that corrects this warning. Regards Valentin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [ARM] Status for 2012.03
Dear Simon Glass,
> +Marek
>
> Hi Albert,
>
> On Fri, Mar 30, 2012 at 12:08 AM, Albert ARIBAUD
>
> wrote:
> > Le 27/03/2012 22:18, Albert ARIBAUD a écrit :
> >> Hi all,
> >>
> >>
> >> I have been away from the list quite a few days, and will have a very
> >> tricky time catching up, so with my apologies, I ask people who need me
> >> to apply patches or pull requests for the upcoming release to please
> >> send me a private e-mail and point me to the list message that I should
> >> be acting upon.
> >
> > FWIW, ./MAKEALL arm on current u-boot-arm/master with CS toolchain 2010q1
> > builds 277 boards, of which none has errors and 167 have warnings.
> >
> > The total count of warnings is 248, distributed as:
> >
> > 4 post.c:503: warning: #warning "Not implemented yet"
> >
> > 79 mmc.c:132: warning: no return statement in function returning
> > non-void
> >
> > 165 ohci-hcd.c:{1307,1310,1313}: warning: dereferencing pointer
> > 'pretmp.NNN' does break strict-aliasing rules
>
> I did create a patch for this - it is marked delegated to Marek.
>
> http://patchwork.ozlabs.org/patch/134600/
And stupid maintainer didn't look into it ... bad, bad maintainer. Accept my
apology. But wasn't it decided with Mike that this was indeed a toolchain issue
and not all toolchains choke on it?
>
> > (the last one is actually 3 * 51 warnings)
> >
> > The first one is obvious and should be dealt with, but I consider it not
> > to be a blocker, for only 4 boards.
> >
> > The second one seems straightforward to fix today, if not already
> > submitted.
> >
> > The third one may be an issue, but it could also be a zealous warning
> > from the specific CS toolchain version I am using. Anyway, it does not
> > seem ARM related as such.
>
> Would be nice to get rid of it, but I think it is specific to some
> toolchains.
>
> > Therefore I will issue the ARM pull request right away.
> >
> >
> > Amicalement,
> > --
> > Albert.
> > ___
> > U-Boot mailing list
> > U-Boot@lists.denx.de
> > http://lists.denx.de/mailman/listinfo/u-boot
>
> Regards,
> Simon
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/3] env: unify logic to check and apply changes
Dear Gerlando Falauto,
> On 03/30/2012 03:08 PM, Marek Vasut wrote:
> > Dear Gerlando Falauto,
> >
> >> On 03/29/2012 10:19 PM, Marek Vasut wrote:
> >>> Dear Gerlando Falauto,
> >>>
> >>> WD prodded me too long to review this patchset ;-D
> >>
> >> Well, better late than never! ;-)
> >>
> >> [...]
> >>
> +#if defined(CONFIG_CMD_NET)
> +else if (strcmp(name, "bootfile") == 0) {
> +copy_filename(BootFile, newval, sizeof(BootFile));
> >>>
> >>> Can you remove the camel-case here please?
> >>
> >> That's code I just moved around... Will do, sir.
> >
> > Don't call me that way, makes me feel old :D
>
> Was more of a way to remark authority than age. :-)
;-)
> +return 0;
> +}
> +#endif
> +return 0;
> +}
> +
> >>
> >> [...]
> >>
> --- a/include/search.h
> +++ b/include/search.h
> @@ -47,6 +47,13 @@ typedef struct entry {
>
> struct _ENTRY;
>
> /*
>
> + * Callback function to be called for checking whether the given
> change may + * be applied or not. Must return 0 for approval, 1 for
> denial. + */
> +typedef int (*apply_cb)(const char *name, const char *oldval,
> +const char *newval, int flag);
> >>>
> >>> Is the typedef really necessary ?
> >>>
> >> >[From your other email]
> >> >
> >> > I have to admit I'm not much of a fan of how you use this apply()
> >> > callback, is it really necessary?
> >>
> >> Why ask, if you already know the answer? :-)
> >>
> >> I'm not a big fan either, seemed like the easiest approach at the time.
> >> The idea was to keep the hastable (struct hsearch_data) as decoupled as
> >> possible from the environment (env_htab which is, in fact, the only
> >> instance of struct hsearch_data).
> >>
> >> What if the function pointer was stored within the hastable itself?
> >> Sort of a virtual method.
> >> This way we get rid of the typedef and the function pointer as a
> >> parameter altogether.
> >> The callback parameter then just becomes a boolean value (meaning,
> >> do/don't call the callback function stored within the hashtable itself).
> >> I like that much better. What do you think?
> >
> > Don't we always use only one (this callback) function?
>
> Yes, but only because env is the only hashtable present.
> Is that a yes or a no, then?
Do we expect any more hashtables in the near future ?
> >> [...]
> >>
> /* Flags for himport_r() */
> #define H_NOCLEAR 1 /* do not clear hash table
before
> >>>
> >>> importing */
> >>>
> +#define H_FORCE 2 /* overwrite read-only/write-once
> >>>
> >>> variables */
> >>>
> >>> Make this 1<< x please.
> >>
> >> OK.
> >>
> #endif /* search.h */
>
> diff --git a/lib/hashtable.c b/lib/hashtable.c
> index abd61c8..75b9b07 100644
> --- a/lib/hashtable.c
> +++ b/lib/hashtable.c
> @@ -603,6 +603,22 @@ ssize_t hexport_r(struct hsearch_data *htab,
> const char sep, * himport()
>
> */
>
> +/* Check whether variable name is amongst vars[] */
> +static int process_var(const char *name, int nvars, char * const
> vars[])
> >>>
> >>> You mean check_var()?
> >>
> >> I mean is_var_in_set_or_is_set_empty().
> >
> > Nice name :)
> >
> >> Sorry, I'm very, very bad at picking function names.
> >> Any suggestion?
> >
> > The above is quite descriptive ... maybe is_var_in_set() ? And hey, don't
> > be sorry, you're doing very good job!
>
> I like is_var_in_set().
So be it then ;-)
Thanks!
> Thanks,
> Gerlando
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [ARM] Status for 2012.03
Hi Marek,
On Fri, Mar 30, 2012 at 6:52 AM, Marek Vasut wrote:
> Dear Simon Glass,
>
>> +Marek
>>
>> Hi Albert,
>>
>> On Fri, Mar 30, 2012 at 12:08 AM, Albert ARIBAUD
>>
>> wrote:
>> > Le 27/03/2012 22:18, Albert ARIBAUD a écrit :
>> >> Hi all,
>> >>
>> >>
>> >> I have been away from the list quite a few days, and will have a very
>> >> tricky time catching up, so with my apologies, I ask people who need me
>> >> to apply patches or pull requests for the upcoming release to please
>> >> send me a private e-mail and point me to the list message that I should
>> >> be acting upon.
>> >
>> > FWIW, ./MAKEALL arm on current u-boot-arm/master with CS toolchain 2010q1
>> > builds 277 boards, of which none has errors and 167 have warnings.
>> >
>> > The total count of warnings is 248, distributed as:
>> >
>> > 4 post.c:503: warning: #warning "Not implemented yet"
>> >
>> > 79 mmc.c:132: warning: no return statement in function returning
>> > non-void
>> >
>> > 165 ohci-hcd.c:{1307,1310,1313}: warning: dereferencing pointer
>> > 'pretmp.NNN' does break strict-aliasing rules
>>
>> I did create a patch for this - it is marked delegated to Marek.
>>
>> http://patchwork.ozlabs.org/patch/134600/
>
> And stupid maintainer didn't look into it ... bad, bad maintainer. Accept my
> apology. But wasn't it decided with Mike that this was indeed a toolchain
> issue
> and not all toolchains choke on it?
:-)
Yes. It does feel like a broken toolchain (I felt that the original
code should be warning free, even when I wrote my patch) but it seems
that Albert gets this warning as well. Maybe we should fix it?
>
>>
>> > (the last one is actually 3 * 51 warnings)
>> >
>> > The first one is obvious and should be dealt with, but I consider it not
>> > to be a blocker, for only 4 boards.
>> >
>> > The second one seems straightforward to fix today, if not already
>> > submitted.
>> >
>> > The third one may be an issue, but it could also be a zealous warning
>> > from the specific CS toolchain version I am using. Anyway, it does not
>> > seem ARM related as such.
>>
>> Would be nice to get rid of it, but I think it is specific to some
>> toolchains.
>>
>> > Therefore I will issue the ARM pull request right away.
>> >
>> >
>> > Amicalement,
>> > --
>> > Albert.
>> > ___
>> > U-Boot mailing list
>> > U-Boot@lists.denx.de
>> > http://lists.denx.de/mailman/listinfo/u-boot
>>
>> Regards,
>> Simon
>
> Best regards,
> Marek Vasut
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] lsxl: add support for lschlv2 and lsxhl
Hi Prafulla, [ I'm CCing Wolfgang on this, because i don't know who's responsible for the build/make infrastructure. ] > AFAIK, you need to pass only "u-boot.kwb" to the make (no $(okj) needed) Sorry you're wrong here, that won't work for out-of-tree builds, see below. [mw@thanatos b-u-boot]$ LANG=C make -j3 -C ../u-boot O=`pwd` CROSS_COMPILE=arm-linux-gnueabi- u-boot.kwb make: Entering directory `/home/mw/repo/u-boot' make: *** No rule to make target `u-boot.kwb'. Stop. make: Leaving directory `/home/mw/repo/u-boot' > > - i'm only interested in the u-boot.kwb, why shouldn't it be > > > > generated by > > default? > > > > - i can't build it with a sinlge make call. Eg. atm i'm doing > > > > make -j3 -C ../u-boot O=`pwd` CROSS_COMPILE=arm-linux-gnueabi- > > > > lschlv2 > > > >otherwise i have to do > > > > make -j3 -C ../u-boot O=`pwd` CROSS_COMPILE=arm-linux-gnueabi- > > > > lschlv2 > > > > make -j3 -C ../u-boot O=`pwd` CROSS_COMPILE=arm-linux-gnueabi- \ > > > >`pwd`/u-boot.kwb > > "make u-boot.kwb CROSS_COMPILE=arm-linux-gnueabi-" > generates u-boot.kwb, this should be valid with other use case too. > if not, it makes sense to add an additional line in script that a file in > code :-) Mh, i don't understands what is wrong with a config.mk with only an additional make target? There are other boards too, which handles image generating this way (grep for ALL-y in boards/). Shouldn't be building an uboot image as simple as possible? If we add .PHONY: u-boot.kwb u-boot.kwb: $(obj)u-boot.kwb to the main Makefile, i would say we should add all other image targets, too. I'd say one could add the target to the kirkwood config.mk (if there is one per platform) but i doubt every kirkwood based board will need one (and provides a kwbimage.cfg). -- Michael ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] km_arm: use filesize for erase in update command
We used to have an arbitrary value, which can be a problem if we have a
u-boot image that is bigger than this value.
This patch is dependant on the whole km/arm series and will be included
in the v3 of the series if there is one.
Signed-off-by: Valentin Longchamp
cc: Holger Brunck
cc: Gerlando Falauto
cc: Prafulla Wadaskar
---
include/configs/km/km_arm.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/configs/km/km_arm.h b/include/configs/km/km_arm.h
index 18b114f..67554d0 100644
--- a/include/configs/km/km_arm.h
+++ b/include/configs/km/km_arm.h
@@ -253,7 +253,7 @@ int get_scl(void);
#defineCONFIG_KM_UPDATE_UBOOT
\
"update=" \
- "sf probe 0;sf erase 0 5;" \
+ "sf probe 0;sf erase 0 +${filesize};" \
"sf write ${load_addr_r} 0 ${filesize};\0"
#if defined CONFIG_KM_ENV_IS_IN_SPI_NOR
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ARM1136: add cache flush and invalidate operations
Since commit 5c1ad3e6f8ae578bbe30e09652f1531e9bc22031
(net: fec_mxc: allow use with cache enabled) the FEC_MXC
driver uses flush_dcache_range() and invalidate_dcache_range()
functions. This driver is also configured for ARM1136 based
'flea3' and 'mx35pdk' boards which currently do not build
as there are no ARM1136 specific flush_dcache_range() and
invalidate_dcache_range() functions. Add various ARM1136
cache functions to fix building for 'flea3' and 'mx35pdk'.
Signed-off-by: Anatolij Gustschin
Cc: Stefano Babic
Cc: Fabio Estevam
---
This patch is completely untested, I have not the HW to test on.
Could someone test this patch? The mentioned commit to the
FEC_MXC driver is in u-boot-arm.git master.
Thanks,
Anatolij
arch/arm/cpu/arm1136/cpu.c | 78
1 files changed, 78 insertions(+), 0 deletions(-)
diff --git a/arch/arm/cpu/arm1136/cpu.c b/arch/arm/cpu/arm1136/cpu.c
index 2b91631..43b4f5f 100644
--- a/arch/arm/cpu/arm1136/cpu.c
+++ b/arch/arm/cpu/arm1136/cpu.c
@@ -75,3 +75,81 @@ static void cache_flush(void)
asm ("mcr p15, 0, %0, c7, c7, 0": :"r" (i)); /* invalidate both caches
and flush btb */
asm ("mcr p15, 0, %0, c7, c10, 4": :"r" (i)); /* mem barrier to sync
things */
}
+
+#ifndef CONFIG_SYS_DCACHE_OFF
+
+#ifndef CONFIG_SYS_CACHELINE_SIZE
+#define CONFIG_SYS_CACHELINE_SIZE 32
+#endif
+
+void invalidate_dcache_all(void)
+{
+ asm ("mcr p15, 0, %0, c7, c6, 0" : : "r" (0));
+}
+
+void flush_dcache_all(void)
+{
+ asm ("mcr p15, 0, %0, c7, c10, 0" : : "r" (0));
+ asm ("mcr p15, 0, %0, c7, c10, 4" : : "r" (0));
+}
+
+static inline int bad_cache_range(unsigned long start, unsigned long stop)
+{
+ if ((start | stop) & (CONFIG_SYS_CACHELINE_SIZE - 1)) {
+ printf("Misaligned cache operation [%08lx, %08lx]\n",
+ start, stop);
+ return 1;
+ }
+
+ return 0;
+}
+
+void invalidate_dcache_range(unsigned long start, unsigned long stop)
+{
+ if (bad_cache_range(start, stop))
+ return;
+
+ while (start < stop) {
+ asm ("mcr p15, 0, %0, c7, c6, 1" : : "r" (start));
+ start += CONFIG_SYS_CACHELINE_SIZE;
+ }
+}
+
+void flush_dcache_range(unsigned long start, unsigned long stop)
+{
+ if (bad_cache_range(start, stop))
+ return;
+
+ while (start < stop) {
+ asm ("mcr p15, 0, %0, c7, c14, 1" : : "r" (start));
+ start += CONFIG_SYS_CACHELINE_SIZE;
+ }
+
+ asm ("mcr p15, 0, %0, c7, c10, 4" : : "r" (0));
+}
+
+void flush_cache(unsigned long start, unsigned long size)
+{
+ flush_dcache_range(start, start + size);
+}
+#else /* #ifndef CONFIG_SYS_DCACHE_OFF */
+void invalidate_dcache_all(void)
+{
+}
+
+void flush_dcache_all(void)
+{
+}
+
+void invalidate_dcache_range(unsigned long start, unsigned long stop)
+{
+}
+
+void flush_dcache_range(unsigned long start, unsigned long stop)
+{
+}
+
+void flush_cache(unsigned long start, unsigned long size)
+{
+}
+#endif /* #ifndef CONFIG_SYS_DCACHE_OFF */
--
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/3] env: unify logic to check and apply changes
On 03/30/2012 03:55 PM, Marek Vasut wrote:
Dear Gerlando Falauto,
On 03/30/2012 03:08 PM, Marek Vasut wrote:
Dear Gerlando Falauto,
On 03/29/2012 10:19 PM, Marek Vasut wrote:
[...]
+ return 0;
+ }
+#endif
+ return 0;
+}
+
[...]
--- a/include/search.h
+++ b/include/search.h
@@ -47,6 +47,13 @@ typedef struct entry {
struct _ENTRY;
/*
+ * Callback function to be called for checking whether the given
change may + * be applied or not. Must return 0 for approval, 1 for
denial. + */
+typedef int (*apply_cb)(const char *name, const char *oldval,
+ const char *newval, int flag);
Is the typedef really necessary ?
>[From your other email]
>
> I have to admit I'm not much of a fan of how you use this apply()
> callback, is it really necessary?
Why ask, if you already know the answer? :-)
I'm not a big fan either, seemed like the easiest approach at the time.
The idea was to keep the hastable (struct hsearch_data) as decoupled as
possible from the environment (env_htab which is, in fact, the only
instance of struct hsearch_data).
What if the function pointer was stored within the hastable itself?
Sort of a virtual method.
This way we get rid of the typedef and the function pointer as a
parameter altogether.
The callback parameter then just becomes a boolean value (meaning,
do/don't call the callback function stored within the hashtable itself).
I like that much better. What do you think?
Don't we always use only one (this callback) function?
Yes, but only because env is the only hashtable present.
Is that a yes or a no, then?
Do we expect any more hashtables in the near future ?
I don't think so. Anyway I would rather avoid calling functions
belonging to the environment domain from the hastable domain directly.
For that matter, we have a single "struct hsearch_data" instance in the
whole project, but we keep passing it around as an argument to the
hashtable functions.
Best,
Gerlando
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-ti/master
On Thu, Mar 29, 2012 at 10:35 PM, Albert ARIBAUD wrote: > Hi Tom, > > Le 30/03/2012 02:58, Tom Rini a écrit : > >> On Thu, Mar 29, 2012 at 4:51 PM, Albert ARIBAUD >> wrote: >>> >>> Hi Tom, >>> >>> Le 29/03/2012 20:01, Tom Rini a écrit : On Wed, Mar 28, 2012 at 2:54 PM, Tom Rini wrote: > > > Hello, > > The following changes since commit > 4a3ea216414ad762b3718775a65437c13f0accbc: > Rob Herring (1): > ARM: highbank: setup env from boot source register > > are available in the git repository at: > > git://git.denx.de/u-boot-ti master > > Anatolij Gustschin (2): > board/ti/beagle/beagle.c: Fix build warnings > arch/arm/cpu/armv7/omap-common/clocks-common.c: Fix build warnings > > Tom Rini (3): > sdrc.c: Fix typo in do_sdrc_init() for SPL > OMAP: Remove omap1610inn-based boards > OMAP: Move omap1510inn to Unmaintained / Orphaned Well this is embarrassing. I'd have sworn I tested -s omap but I must not have as omap1510inn doesn't build after that change as it doesn't build as there's no such thing as arch/arm/cpu/arm925t/omap/. Please drop that change out, sorry for the noise. >>> >>> >>> >>> Hmm... I would not expect omap1510inn to build after it has been >>> orphaned, >>> so I am unsure what you mean exactly here. Also, can you precisely list >>> the >>> change(s) that I should drop? >> >> >> So, omap1510inn has no active maintainer, it's listed as the same as >> omap1610inn which was not building. omap1510inn was however building >> until 'OMAP: Move omap1510inn to Unmaintained / Orphaned' in which I >> also added it to the omap SoC family, forgetting that it also forced >> trying to build a non-existent directory, breaking it. > > > Ok, throwing out 'OMAP: Move omap1510inn to Unmaintained / Orphaned' from > u-boot-arm/master. Thanks, sorry again for the noise. -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM1136: add cache flush and invalidate operations
On 30/03/2012 16:02, Anatolij Gustschin wrote: > Since commit 5c1ad3e6f8ae578bbe30e09652f1531e9bc22031 Hi Antolji, > (net: fec_mxc: allow use with cache enabled) the FEC_MXC > driver uses flush_dcache_range() and invalidate_dcache_range() > functions. This driver is also configured for ARM1136 based > 'flea3' and 'mx35pdk' boards which currently do not build > as there are no ARM1136 specific flush_dcache_range() and The issue is known - that is one reason why I marked the cache patches for the -next. I do not know if we can run enough tests before release. Patches for M28 / MX5 / MX6 are not part of u-boot-imx, neither are yet merged into u-boot mainline by Wolfgang. On which tree have you seen that the patch was already merged ? 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 1/3] env: unify logic to check and apply changes
Dear Gerlando Falauto,
> On 03/30/2012 03:55 PM, Marek Vasut wrote:
> > Dear Gerlando Falauto,
> >
> >> On 03/30/2012 03:08 PM, Marek Vasut wrote:
> >>> Dear Gerlando Falauto,
> >>>
> On 03/29/2012 10:19 PM, Marek Vasut wrote:
> [...]
>
> >> + return 0;
> >> + }
> >> +#endif
> >> + return 0;
> >> +}
> >> +
>
> [...]
>
> >> --- a/include/search.h
> >> +++ b/include/search.h
> >> @@ -47,6 +47,13 @@ typedef struct entry {
> >>
> >> struct _ENTRY;
> >>
> >> /*
> >>
> >> + * Callback function to be called for checking whether the given
> >> change may + * be applied or not. Must return 0 for approval, 1 for
> >> denial. + */
> >> +typedef int (*apply_cb)(const char *name, const char *oldval,
> >> + const char *newval, int flag);
> >
> > Is the typedef really necessary ?
> >
> >[From your other email]
> >
> > I have to admit I'm not much of a fan of how you use this
> > apply() callback, is it really necessary?
>
> Why ask, if you already know the answer? :-)
>
> I'm not a big fan either, seemed like the easiest approach at the
> time. The idea was to keep the hastable (struct hsearch_data) as
> decoupled as possible from the environment (env_htab which is, in
> fact, the only instance of struct hsearch_data).
>
> What if the function pointer was stored within the hastable itself?
> Sort of a virtual method.
> This way we get rid of the typedef and the function pointer as a
> parameter altogether.
> The callback parameter then just becomes a boolean value (meaning,
> do/don't call the callback function stored within the hashtable
> itself). I like that much better. What do you think?
> >>>
> >>> Don't we always use only one (this callback) function?
> >>
> >> Yes, but only because env is the only hashtable present.
> >> Is that a yes or a no, then?
> >
> > Do we expect any more hashtables in the near future ?
>
> I don't think so. Anyway I would rather avoid calling functions
> belonging to the environment domain from the hastable domain directly.
> For that matter, we have a single "struct hsearch_data" instance in the
> whole project, but we keep passing it around as an argument to the
> hashtable functions.
Ah, it just came to me.
On the other hand, I have this strange feeling lib/hashtable.c is so modified
for uboot it can't be used (in a generic way) for any other storage than env
...
or am I wrong?
WD, can you comment please?
> Best,
> Gerlando
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [ARM] Status for 2012.03
Dear Simon Glass,
> Hi Marek,
>
> On Fri, Mar 30, 2012 at 6:52 AM, Marek Vasut wrote:
> > Dear Simon Glass,
> >
> >> +Marek
> >>
> >> Hi Albert,
> >>
> >> On Fri, Mar 30, 2012 at 12:08 AM, Albert ARIBAUD
> >>
> >> wrote:
> >> > Le 27/03/2012 22:18, Albert ARIBAUD a écrit :
> >> >> Hi all,
> >> >>
> >> >>
> >> >> I have been away from the list quite a few days, and will have a very
> >> >> tricky time catching up, so with my apologies, I ask people who need
> >> >> me to apply patches or pull requests for the upcoming release to
> >> >> please send me a private e-mail and point me to the list message
> >> >> that I should be acting upon.
> >> >
> >> > FWIW, ./MAKEALL arm on current u-boot-arm/master with CS toolchain
> >> > 2010q1 builds 277 boards, of which none has errors and 167 have
> >> > warnings.
> >> >
> >> > The total count of warnings is 248, distributed as:
> >> >
> >> > 4 post.c:503: warning: #warning "Not implemented yet"
> >> >
> >> > 79 mmc.c:132: warning: no return statement in function returning
> >> > non-void
> >> >
> >> > 165 ohci-hcd.c:{1307,1310,1313}: warning: dereferencing pointer
> >> > 'pretmp.NNN' does break strict-aliasing rules
> >>
> >> I did create a patch for this - it is marked delegated to Marek.
> >>
> >> http://patchwork.ozlabs.org/patch/134600/
> >
> > And stupid maintainer didn't look into it ... bad, bad maintainer. Accept
> > my apology. But wasn't it decided with Mike that this was indeed a
> > toolchain issue and not all toolchains choke on it?
> :
> :-)
>
> Yes. It does feel like a broken toolchain (I felt that the original
> code should be warning free, even when I wrote my patch) but it seems
> that Albert gets this warning as well. Maybe we should fix it?
I don't see this with ELDK 4.2 or 5.0 or 5.1 ;-)
Maybe fundamental rewrite of that code might help instead of adding bandaids ;-)
> >> > (the last one is actually 3 * 51 warnings)
> >> >
> >> > The first one is obvious and should be dealt with, but I consider it
> >> > not to be a blocker, for only 4 boards.
> >> >
> >> > The second one seems straightforward to fix today, if not already
> >> > submitted.
> >> >
> >> > The third one may be an issue, but it could also be a zealous warning
> >> > from the specific CS toolchain version I am using. Anyway, it does not
> >> > seem ARM related as such.
> >>
> >> Would be nice to get rid of it, but I think it is specific to some
> >> toolchains.
> >>
> >> > Therefore I will issue the ARM pull request right away.
> >> >
> >> >
> >> > Amicalement,
> >> > --
> >> > Albert.
> >> > ___
> >> > U-Boot mailing list
> >> > U-Boot@lists.denx.de
> >> > http://lists.denx.de/mailman/listinfo/u-boot
> >>
> >> Regards,
> >> Simon
> >
> > Best regards,
> > Marek Vasut
>
> Regards,
> Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM1136: add cache flush and invalidate operations
Hi Stefano, On Fri, 30 Mar 2012 16:20:19 +0200 Stefano Babic wrote: > On 30/03/2012 16:02, Anatolij Gustschin wrote: > > Since commit 5c1ad3e6f8ae578bbe30e09652f1531e9bc22031 > > Hi Antolji, > > > (net: fec_mxc: allow use with cache enabled) the FEC_MXC > > driver uses flush_dcache_range() and invalidate_dcache_range() > > functions. This driver is also configured for ARM1136 based > > 'flea3' and 'mx35pdk' boards which currently do not build > > as there are no ARM1136 specific flush_dcache_range() and > > The issue is known - that is one reason why I marked the cache patches > for the -next. I do not know if we can run enough tests before release. > > Patches for M28 / MX5 / MX6 are not part of u-boot-imx, neither are yet > merged into u-boot mainline by Wolfgang. On which tree have you seen > that the patch was already merged ? I pulled u-boot-arm.git master for build tests and see this change on the FEC driver in resulting tree. Thanks, Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM1136: add cache flush and invalidate operations
On 30/03/2012 16:35, Anatolij Gustschin wrote: > Hi Stefano, > > On Fri, 30 Mar 2012 16:20:19 +0200 > Stefano Babic wrote: > >> On 30/03/2012 16:02, Anatolij Gustschin wrote: >>> Since commit 5c1ad3e6f8ae578bbe30e09652f1531e9bc22031 >> >> Hi Antolji, >> >>> (net: fec_mxc: allow use with cache enabled) the FEC_MXC >>> driver uses flush_dcache_range() and invalidate_dcache_range() >>> functions. This driver is also configured for ARM1136 based >>> 'flea3' and 'mx35pdk' boards which currently do not build >>> as there are no ARM1136 specific flush_dcache_range() and >> >> The issue is known - that is one reason why I marked the cache patches >> for the -next. I do not know if we can run enough tests before release. >> >> Patches for M28 / MX5 / MX6 are not part of u-boot-imx, neither are yet >> merged into u-boot mainline by Wolfgang. On which tree have you seen >> that the patch was already merged ? > > I pulled u-boot-arm.git master for build tests and see this > change on the FEC driver in resulting tree. However, Albert has sent a report http://www.mail-archive.com/u-boot@lists.denx.de/msg80566.html a none of these boards was broken. But I see now that other boards are affected (the mx28evk does not compile due to missing CONFIG_APBH_DMA). Albert, are these patches part of your pull-request to Wolfgang ? 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] ARM1136: add cache flush and invalidate operations
Dear Stefano Babic, > On 30/03/2012 16:35, Anatolij Gustschin wrote: > > Hi Stefano, > > > > On Fri, 30 Mar 2012 16:20:19 +0200 > > > > Stefano Babic wrote: > >> On 30/03/2012 16:02, Anatolij Gustschin wrote: > >>> Since commit 5c1ad3e6f8ae578bbe30e09652f1531e9bc22031 > >> > >> Hi Antolji, > >> > >>> (net: fec_mxc: allow use with cache enabled) the FEC_MXC > >>> driver uses flush_dcache_range() and invalidate_dcache_range() > >>> functions. This driver is also configured for ARM1136 based > >>> 'flea3' and 'mx35pdk' boards which currently do not build > >>> as there are no ARM1136 specific flush_dcache_range() and > >> > >> The issue is known - that is one reason why I marked the cache patches > >> for the -next. I do not know if we can run enough tests before release. > >> > >> Patches for M28 / MX5 / MX6 are not part of u-boot-imx, neither are yet > >> merged into u-boot mainline by Wolfgang. On which tree have you seen > >> that the patch was already merged ? > > > > I pulled u-boot-arm.git master for build tests and see this > > change on the FEC driver in resulting tree. > > However, Albert has sent a report > http://www.mail-archive.com/u-boot@lists.denx.de/msg80566.html > > a none of these boards was broken. But I see now that other boards are > affected (the mx28evk does not compile due to missing CONFIG_APBH_DMA). Fabio, can you fix please? This is trivial. > Albert, are these patches part of your pull-request to Wolfgang ? I believe the pullRQ isn't cooked yet. The fix for this issue right now would be to merge a patch that implements blank dcache-management functions for arm1136 -- like is in AG's patch. So I'm all for merging AG's patch into AA's tree. It's a good thing this stirred a wave of response including patches. We now know very well which boards are maintained ;-) Also, once any such breaking patch lands into mainline, we'll know in _less_than_24_hours_ that something got broken. (this is handled by DENX CI machine). Finally, we can't really run physical (HW) tests indeed, but did we ever run physical tests with each and every patch? (and to conclude this -- these patches were tested on M28 and MX6Q-board) > > Stefano Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ext2 file system performance
On Thu, Mar 15, 2012 at 09:20:34PM -0400, jonsm...@gmail.com wrote: > The ext2 file system code is reading the kernel image off from my SD > card one sector at a time. Of course this takes 61 seconds to get the > kernel in to memory. Loading the same kernel off from the same SD on > FAT takes less than a second. > > Nice quick FAT reads... > > reading uImage > JDS start 7c0 count 1 > JDS start 9d0 count 2 > JDS start 7d0 count 6 > JDS start 1aa0 count 1090 > JDS start 2b30 count e > JDS start 2b3e count 1 > > Ext2 takes about 8,000 single sector reads. File is not fragmented, it > is the only file on a freshly formatted volume. > Is there anyway to convince the ext2 code to use larger reads? Take a look at my patch submitted here: http://www.mail-archive.com/u-boot@lists.denx.de/msg80677.html Let me know if that works for you. hth, Jason. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] zImage and raw ramdisk support -- test
Guys, I need final test on as much platforms as possible. Can you please run these two following patches and tell me if they work with zImage and raw ramdisk for you? http://patchwork.ozlabs.org/patch/146848/ http://patchwork.ozlabs.org/patch/147440/ I can't promise they will make it to this release (I've been pestering WD pretty thoroughly (sorry about that), though I'm starting to be unhappy to merge this stuff at the verge of release myself). 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] ARM1136: add cache flush and invalidate operations
Hi, On Fri, 30 Mar 2012 17:28:03 +0200 Marek Vasut wrote: ... > > > I pulled u-boot-arm.git master for build tests and see this > > > change on the FEC driver in resulting tree. > > > > However, Albert has sent a report > > http://www.mail-archive.com/u-boot@lists.denx.de/msg80566.html > > > > a none of these boards was broken. But I see now that other boards are > > affected (the mx28evk does not compile due to missing CONFIG_APBH_DMA). > > Fabio, can you fix please? This is trivial. I've a patch to fix mx28evk build already. Will send it shortly. Thanks, Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mx28evk: fix build error
Fix:
drivers/mmc/libmmc.o: In function `mxsmmc_send_cmd':
/home/ag/git/u-boot/drivers/mmc/mxsmmc.c:210: undefined reference to
`mxs_dma_desc_append'
/home/ag/git/u-boot/drivers/mmc/mxsmmc.c:211: undefined reference to
`mxs_dma_go'
drivers/mmc/libmmc.o: In function `mxsmmc_initialize':
/home/ag/git/u-boot/drivers/mmc/mxsmmc.c:306: undefined reference to
`mxs_dma_desc_alloc'
Signed-off-by: Anatolij Gustschin
Cc: Fabio Estevam
---
include/configs/mx28evk.h |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/include/configs/mx28evk.h b/include/configs/mx28evk.h
index cdcc6e0..705fdab 100644
--- a/include/configs/mx28evk.h
+++ b/include/configs/mx28evk.h
@@ -126,6 +126,11 @@
#define CONFIG_SYS_BAUDRATE_TABLE { 9600, 19200, 38400, 57600, 115200 }
/*
+ * DMA
+ */
+#define CONFIG_APBH_DMA
+
+/*
* MMC Driver
*/
#define CONFIG_ENV_IS_IN_MMC
--
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] mx28evk: fix build error
On Fri, Mar 30, 2012 at 12:45 PM, Anatolij Gustschin wrote: > Fix: > drivers/mmc/libmmc.o: In function `mxsmmc_send_cmd': > /home/ag/git/u-boot/drivers/mmc/mxsmmc.c:210: undefined reference to > `mxs_dma_desc_append' > /home/ag/git/u-boot/drivers/mmc/mxsmmc.c:211: undefined reference to > `mxs_dma_go' > drivers/mmc/libmmc.o: In function `mxsmmc_initialize': > /home/ag/git/u-boot/drivers/mmc/mxsmmc.c:306: undefined reference to > `mxs_dma_desc_alloc' > > Signed-off-by: Anatolij Gustschin > Cc: Fabio Estevam Acked-by: Fabio Estevam Thanks ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/3] mmc: sdhci: fix the wrong operation when response type is R1b
Hi Jaehoon,
On Fri, Mar 30, 2012 at 2:23 PM, Jaehoon Chung wrote:
> On 03/30/2012 02:24 PM, Lei Wen wrote:
>
>> Hi Jaehoon,
>>
>> On Fri, Mar 30, 2012 at 12:36 PM, Jaehoon Chung
>> wrote:
>>> Hi Lei.
>>>
>>> First, thanks for implemented the generic sdhci controller.
>>
>> It is my pleasure to share this common code, and I'm glad that it is
>> used for other platforms now. :)
>>
>>>
>>> On 03/30/2012 12:33 PM, Lei Wen wrote:
>>>
Hi Jaehoon,
On Fri, Mar 30, 2012 at 10:39 AM, Jaehoon Chung
wrote:
> When response type is R1b, mask value is added the SDHCI_INT_DAT_END.
> but in while(), didn't check that flag.
> So sdhci controller didn't work fine.
> CMD6 didn't always complete.
Could you elaborate it more in details?
do {
stat = sdhci_readl(host, SDHCI_INT_STATUS);
if (stat & SDHCI_INT_ERROR)
break;
} while ((stat & mask) != mask);
Here in the while condition, if the status read out don't contain all mask,
then the looping would continue.
Do you mean you just need a retry max time set here?
>>>
>>> I found that didn't initialize the eMMC card.
>>> Because when send CMD6, running infinite loop in there.
>>> CMD6's mask is set to SDHCI_INT_RESPONSE and SDHCI_INT_DATA_END.
>>> (Because response type is R1B).
>>> Then mask value maybe is 0x3...
>>> stat = sdhci_readl(host, SDHCI_INT_STATUS);
>>> stat is 0x1.(cmd is done response).
>>> but in while(), stat & mask is 0x1, and mask is 0x3.
>>> ...doing while().
>>> If just add the timeout, then always produced the timeout error.
>>
>> I see your problems. Your silicon only provide SDHCI_INT_RESPONSE for
>> r1b, while the standard
>> sdhci spec require both the flag is set when the r1b command is finished.
>> So my point is you could add a quirk condition check in the previously
>> endless loop checking.
>> If the quirk is true, and timeout count is met, then you could jump
>> out of original looping.
>> And for later checking, this timeout could be regarded as no error,
>> since the controller would never
>> return the SDHCI_INT_DATA_END in your case.
>
>
> Anyway it's need that use the timeout value. right?
Yes, for the timeout patch here, I am ok with that.
> And in our case, It's means that use the quirks?
Using quirks, or set a timeout value large enough? Maybe latter is
more generic. :)
> I didn't find that the sdhci spec require the flag is set when the r1b
> command is finished.
> where is specified?
The spec I mention is
https://www.sdcard.org/developers/overview/host_controller/simple_spec/Simplified_SD_Host_Controller_Spec.pdf
You could look at page 64, the bit description for "Transfer Complete":
(3) In the case of a command with busy
This bit is set when busy is de-asserted. Refer to DAT Line Active
and Command Inhibit (DAT) in the Present State register
> I just understand that the transfer complete bit should be set to 1,
> when send the command with busy flag or read/write with data.
> Is this means?
Yes, that is what I means, if you send a command with r1b flag, then
you should expect both
transfer complete and command complete bit is set, only command
complete bit set doesn't mean
your command is safely treated, and you could do the next step further.
>
> If you want to use the quirks, i will test with applied your opinion.
I think you only need to add timeout into this while looping, and not
touching other code.
do {
stat = sdhci_readl(host, SDHCI_INT_STATUS);
if (stat & SDHCI_INT_ERROR)
break;
} while ((stat & mask) != mask);
>
> Best Regards,
> Jaehoon Chung
Thanks,
Lei
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM1136: add cache flush and invalidate operations
On 30/03/2012 17:28, Marek Vasut wrote: >> >> However, Albert has sent a report >> http://www.mail-archive.com/u-boot@lists.denx.de/msg80566.html >> >> a none of these boards was broken. But I see now that other boards are >> affected (the mx28evk does not compile due to missing CONFIG_APBH_DMA). > > Fabio, can you fix please? This is trivial. > >> Albert, are these patches part of your pull-request to Wolfgang ? > > I believe the pullRQ isn't cooked yet. The fix for this issue right now would > be > to merge a patch that implements blank dcache-management functions for > arm1136 > -- like is in AG's patch. So I'm all for merging AG's patch into AA's tree. I am testing Anatolij's patch on mx35pdk. TFTP from server 192.168.2.14; our IP address is 192.168.2.97 Filename 'mx35pdk/uImage'. Load address: 0x8080 Loading: Misaligned cache operation [8fe726e8, 8fe72728] However, data is correctly loaded. I will check mmc on the "flea" board. > It's a good thing this stirred a wave of response including patches. We now > know > very well which boards are maintained ;-) > > Also, once any such breaking patch lands into mainline, we'll know in > _less_than_24_hours_ that something got broken. (this is handled by DENX CI > machine). Well, this is a good thing - my worries are about that patches for imx were already merged, and > Finally, we can't really run physical (HW) tests indeed, but did we ever run > physical tests with each and every patch? Not every patch, but a patchset that can have influence on several SOCs, yes. > (and to conclude this -- these patches > were tested on M28 and MX6Q-board) mmmh...I suppose the following patches must be merged, too (I had merged into u-boot-next, really): Author: Eric Nelson Date: Sun Mar 4 11:47:37 2012 + i.MX6: define CACHELINE_SIZE and also even if not mandatory: commit 1b2150b0770d8d019a41993d8692e4a29bf70a9e Author: Eric Nelson Date: Sun Mar 4 11:47:38 2012 + i.MX6: implement enable_caches() disabled by default until drivers are fixed Signed-off-by: Eric Nelson Acked-by: Marek Vasut 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] Please pull u-boot-sh/master
Dear Nobuhiro Iwamatsu, In message you wrote: > Dear Wolfgang Denk. > > Please pull u-boot-sh/master. > > The following changes since commit 7cb30b13f12077c7eec8ce2419cd96cd65ace8e2= > : > > Merge branch 'master' of git://git.denx.de/u-boot-cfi-flash > (2012-03-23 21:59:16 +0100) > > are available in the git repository at: > > > git://git.denx.de/u-boot-sh.git master > > for you to fetch changes up to 75d79840ff8ea4e5a21b2b343f0316c57354897d: > > sh: Fix building ecovec board (2012-03-26 10:09:31 +0900) > > > Nobuhiro Iwamatsu (4): > sh: Add header file for interface of SH MMC > sh: sh7757lcr: Add MMC header file of SH > sh: Add header file of MMC framework > sh: ecovec: Remove unused variable > > Phil Edworthy (1): > sh: Fix building ecovec board > > Yoshihiro Shimoda (2): > sh: sh7757lcr: add supporting for MMCIF > sh_spi: Add 4 chip select signals supporting > > arch/sh/include/asm/mmc.h | 18 ++ > arch/sh/lib/board.c |1 + > board/renesas/ecovec/Makefile |8 ++-- > board/renesas/ecovec/ecovec.c |1 - > board/renesas/sh7757lcr/sh7757lcr.c |6 ++ > doc/README.sh7757lcr|1 + > drivers/spi/sh_spi.c| 19 --- > drivers/spi/sh_spi.h|4 +++- > include/configs/sh7757lcr.h | 11 +++ > 9 files changed, 62 insertions(+), 7 deletions(-) > create mode 100644 arch/sh/include/asm/mmc.h Applied, thanks. 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 I know engineers. They love to change things. - Dr. McCoy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request - microblaze
Dear Michal Simek, In message <4f71b03a.8050...@monstr.eu> you wrote: > Dear Wolfgang Denk, > > Please pull this one patch when merge window is open. > > Thanks, > Michal > > > The following changes since commit 7cb30b13f12077c7eec8ce2419cd96cd65ace8e2: >Wolfgang Denk (1): > Merge branch 'master' of git://git.denx.de/u-boot-cfi-flash > > are available in the git repository at: > >git://www.denx.de/git/u-boot-microblaze.git master > > Stephan Linz (1): >microblaze: Enable phylib and mii support > > include/configs/microblaze-generic.h | 21 + > 1 files changed, 21 insertions(+), 0 deletions(-) Applied, thanks. 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 Where there's no emotion, there's no motive for violence. -- Spock, "Dagger of the Mind", stardate 2715.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM1136: add cache flush and invalidate operations
Dear Stefano Babic, > On 30/03/2012 17:28, Marek Vasut wrote: > >> However, Albert has sent a report > >> > >> http://www.mail-archive.com/u-boot@lists.denx.de/msg80566.html > >> > >> a none of these boards was broken. But I see now that other boards are > >> affected (the mx28evk does not compile due to missing CONFIG_APBH_DMA). > > > > Fabio, can you fix please? This is trivial. > > > >> Albert, are these patches part of your pull-request to Wolfgang ? > > > > I believe the pullRQ isn't cooked yet. The fix for this issue right now > > would be to merge a patch that implements blank dcache-management > > functions for arm1136 -- like is in AG's patch. So I'm all for merging > > AG's patch into AA's tree. > > I am testing Anatolij's patch on mx35pdk. > > TFTP from server 192.168.2.14; our IP address is 192.168.2.97 > Filename 'mx35pdk/uImage'. > Load address: 0x8080 > Loading: Misaligned cache operation [8fe726e8, 8fe72728] > > However, data is correctly loaded. I will check mmc on the "flea" board. You get this from FEC? Will have to recheck, this is weird, will recheck once I get back to my m28. > > > It's a good thing this stirred a wave of response including patches. We > > now know very well which boards are maintained ;-) > > > > Also, once any such breaking patch lands into mainline, we'll know in > > _less_than_24_hours_ that something got broken. (this is handled by DENX > > CI machine). > > Well, this is a good thing - my worries are about that patches for imx > were already merged, and > > > Finally, we can't really run physical (HW) tests indeed, but did we ever > > run physical tests with each and every patch? > > Not every patch, but a patchset that can have influence on several SOCs, > yes. Agreed. > > > (and to conclude this -- these patches > > were tested on M28 and MX6Q-board) > > mmmh...I suppose the following patches must be merged, too (I had merged > into u-boot-next, really): > > Author: Eric Nelson > Date: Sun Mar 4 11:47:37 2012 + > > i.MX6: define CACHELINE_SIZE > > and also even if not mandatory: > commit 1b2150b0770d8d019a41993d8692e4a29bf70a9e > Author: Eric Nelson > Date: Sun Mar 4 11:47:38 2012 + > > i.MX6: implement enable_caches() > > disabled by default until drivers are fixed > > Signed-off-by: Eric Nelson > Acked-by: Marek Vasut They weren't already? Hm. > > Best regards, > Stefano Babic 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] mx6qsabrelite: Fix the serial console port
Hi Stefano, On Wed, Mar 28, 2012 at 4:45 PM, Fabio Estevam wrote: > On mx6qsabrelite the console is ttymxc1. > > Signed-off-by: Fabio Estevam Along with the mx28 README patches, this one would be nice to get into 12.03 as well. Thanks, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM1136: add cache flush and invalidate operations
On 30/03/2012 18:05, Marek Vasut wrote: >> >> I am testing Anatolij's patch on mx35pdk. >> >> TFTP from server 192.168.2.14; our IP address is 192.168.2.97 >> Filename 'mx35pdk/uImage'. >> Load address: 0x8080 >> Loading: Misaligned cache operation [8fe726e8, 8fe72728] >> >> However, data is correctly loaded. I will check mmc on the "flea" board. > > You get this from FEC? Yes, I must set explicitely ethact=FEC, because on the mx35pdk ethprime is set to SMC911. >Will have to recheck, this is weird, will recheck once I > get back to my m28. I will check also on the flea3 board later. > >> >>> It's a good thing this stirred a wave of response including patches. We >>> now know very well which boards are maintained ;-) >>> >>> Also, once any such breaking patch lands into mainline, we'll know in >>> _less_than_24_hours_ that something got broken. (this is handled by DENX >>> CI machine). >> >> Well, this is a good thing - my worries are about that patches for imx >> were already merged, and >> >>> Finally, we can't really run physical (HW) tests indeed, but did we ever >>> run physical tests with each and every patch? >> >> Not every patch, but a patchset that can have influence on several SOCs, >> yes. > > Agreed. > >> >>> (and to conclude this -- these patches >>> were tested on M28 and MX6Q-board) >> >> mmmh...I suppose the following patches must be merged, too (I had merged >> into u-boot-next, really): >> >> Author: Eric Nelson >> Date: Sun Mar 4 11:47:37 2012 + >> >> i.MX6: define CACHELINE_SIZE >> >> and also even if not mandatory: >> commit 1b2150b0770d8d019a41993d8692e4a29bf70a9e >> Author: Eric Nelson >> Date: Sun Mar 4 11:47:38 2012 + >> >> i.MX6: implement enable_caches() >> >> disabled by default until drivers are fixed >> >> Signed-off-by: Eric Nelson >> Acked-by: Marek Vasut > > They weren't already? Hm. They are not - I thought to push all patches together, and for this reason they are on the -next branch. I merge both into -master, and they will part of my next pull. 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] post: remove #warning for kirkwood CPUs
Dear Valentin Longchamp, In message <1333114168-7151-1-git-send-email-valentin.longch...@keymile.com> you wrote: > Since commit 96f5c4b the needed functions (get_ticks() and get_tbclk() ) > are defined for kirkwood CPUs as well. This warning is then not relevant > anymore. > > Signed-off-by: Valentin Longchamp > cc: Holger Brunck > cc: Prafulla Wadaskar > cc: Albert Aribaud > --- > post/post.c |3 +-- > 1 files changed, 1 insertions(+), 2 deletions(-) Applied, thanks. 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 Nobody goes to that restaurant anymore. It's too crowded. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ext2 file system performance
Much better 3.5 seconds versus the old 61 seconds. It is still slower than FAT which can load in less than one second. Can those 40 sequential reads starting at 1034 be combined? Read trace from EXT2. EA3131-NXP # ext2load mmc 0:3 0x3000 uImage Loading file "uImage" from mmc device 0:3 (xxa3) <2, 0, 204> <4, 0, 32> <524, 128, 128> <1034, 0, 8> <1034, 8, 1> <1034, 12, 8> <1034, 20, 2> <1034, 24, 8> <1034, 32, 10> <1034, 44, 8> <1034, 52, 3> <1034, 56, 8> <1034, 64, 3> <1034, 68, 8> <1034, 76, 3> <1034, 80, 8> <1034, 88, 3> <1034, 92, 8> <1034, 100, 7> <1034, 108, 8> <1034, 116, 3> <1034, 120, 8> <1034, 128, 4> <1034, 132, 8> <1034, 140, 4> <1034, 144, 8> <1034, 152, 3> <1034, 156, 8> <1034, 164, 4> <1034, 168, 8> <1034, 176, 3> <1034, 180, 8> <1034, 188, 3> <1034, 192, 8> <1034, 200, 3> <1034, 204, 8> <1034, 212, 3> <1034, 216, 8> <1034, 224, 3> <1034, 228, 8> <1034, 236, 6> <4, 0, 32> <527, 0, 128> <1062, 0, 1024> <1086, 0, 1024> <1064, 0, 11264> <1600, 0, 1024> <1602, 0, 1024> <1086, 0, 1024> <1088, 0, 262144> <1600, 0, 1024> <2116, 0, 1024> <1602, 0, 1024> <1604, 0, 262144> <2116, 0, 1024> <2630, 0, 1024> <2116, 0, 1024> <2118, 0, 262144> <2630, 0, 1024> <3144, 0, 1024> <2630, 0, 1024> <2632, 0, 262144> <3144, 0, 1024> <3658, 0, 1024> <3144, 0, 1024> <3146, 0, 262144> <3658, 0, 1024> <4172, 0, 1024> <3658, 0, 1024> <3660, 0, 262144> <4172, 0, 1024> <4686, 0, 1024> <4172, 0, 1024> <4174, 0, 262144> <4686, 0, 1024> <5200, 0, 1024> <4686, 0, 1024> <4688, 0, 262144> <5200, 0, 1024> <5202, 0, 66560> 2175848 bytes read EA3131-NXP # -- Jon Smirl jonsm...@gmail.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/3] env: unify logic to check and apply changes
On 03/30/2012 03:00 PM, Gerlando Falauto wrote:
On 03/29/2012 10:19 PM, Marek Vasut wrote:
[...]
+#if defined(CONFIG_CMD_NET)
+ else if (strcmp(name, "bootfile") == 0) {
+ copy_filename(BootFile, newval, sizeof(BootFile));
Can you remove the camel-case here please?
That's code I just moved around... Will do, sir.
Can't do that, sorry. The global symbol "BootFile" has been defined
somewhere else and it's used all over the place.
[...]
diff --git a/lib/hashtable.c b/lib/hashtable.c
index abd61c8..75b9b07 100644
--- a/lib/hashtable.c
+++ b/lib/hashtable.c
[...]
@@ -726,6 +744,8 @@ int himport_r(struct hsearch_data *htab,
*dp++ = '\0'; /* terminate name */
debug("DELETE CANDIDATE: \"%s\"\n", name);
+ if (!process_var(name, nvars, vars))
+ continue;
if (hdelete_r(name, htab) == 0)
debug("DELETE ERROR
##\n");
@@ -743,10 +763,31 @@ int himport_r(struct hsearch_data *htab,
*sp++ = '\0'; /* terminate value */
++dp;
+ /* Skip variables which are not supposed to be treated */
+ if (!process_var(name, nvars, vars))
+ continue;
+
/* enter into hash table */
e.key = name;
e.data = value;
Do you need to do this if you eventually later figure out you have no
apply()
callback and you did this for no reason?
You mean calling process_var()? It's two separate things.
One, filter out the variables that were not asked to be processed, if
there were any (call to process_var())
Two, check whether the new value is acceptable and/or apply it (call
apply())
You could have none, either, or both.
Or else, if you mean moving the e.key = name, e.data = value
assignments, you're right, they should be moved down (but in that case
it would be because the apply function fails, not because it's not
present -- default case is always successful).
Hhmm... sorry, the assignments need to stay where they are.
Values in e.key and e.data are used by hsearch_r() within the if statement.
+ /* if there is an apply function, check what it has to say */
+ if (apply != NULL) {
+ debug("searching before calling cb function"
+ " for %s\n", name);
+ /*
+ * Search for variable in existing env, so to pass
+ * its previous value to the apply callback
+ */
+ hsearch_r(e, FIND,&rv, htab);
+ debug("previous value was %s\n", rv ? rv->data : "");
+ if (apply(name, rv ? rv->data : NULL, value, flag)) {
+ debug("callback function refused to set"
+ " variable %s, skipping it!\n", name);
+ continue;
+ }
+ }
+
hsearch_r(e, ENTER,&rv, htab);
if (rv == NULL) {
printf("himport_r: can't insert \"%s=%s\" into hash
table\n",
Thank you,
Gerlando
Gerlando
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Pull request: u-boot-staging
Hello Wolfgang, Please pull various fixes and patches that have been submitted before merge window was closed. There is one patch from me, I know that I may not push my own patches through the staging tree. But this patch is trivial and has been acked by two people, so I hope this is okay. The following changes since commit 7cb30b13f12077c7eec8ce2419cd96cd65ace8e2: Merge branch 'master' of git://git.denx.de/u-boot-cfi-flash (2012-03-23 21:59:16 +0100) are available in the git repository at: git://git.denx.de/u-boot-staging.git ag...@denx.de Anatolij Gustschin (1): fs/fat/fat_write.c: Fix GCC 4.6 warnings David Wagner (7): mkenvimage: correct and clarify comments and error messages mkenvimage: Correct an include and add a missing one mkenvimage: More error handling mkenvimage: Read/Write from/to stdin/out by default or if the filename is "-" mkenvimage: Use mmap() when reading from a regular file mkenvimage: Don't try to detect comments in the input file mkenvimage: Really set the redundant byte when applicable Donggeun Kim (2): FAT write: Fix compile errors cmd_fat: add FAT write command Jason Hobbs (1): cmd_pxe.c: fix strict-aliasing warnings Liming Wang (1): ARMV7/Vexpress: add missing get_ticks() and get_tbclk() Mike Frysinger (2): net: smc9: use mdelay() lzma: fix printf warnings Scott Wood (1): MAKEALL: display SPL size if present Simon Glass (1): Remove CONFIG_SYS_EXTBDINFO from snapper9260.h Thomas Weber (1): doc: Fix some typos in different files Tim Kientzle (1): disk/part.c: Fix device enumeration through API Wolfgang Denk (1): mkenvimage: fix usage message MAKEALL |8 ++- README |8 ++- board/armltd/vexpress/ca9x4_ct_vxp.c | 10 +++ common/cmd_fat.c | 57 ++ common/cmd_pxe.c | 16 ++-- disk/part.c |3 + doc/README.AVR32-port-muxing |4 +- doc/README.SNTP |2 +- doc/README.Sandpoint8240 |6 +- doc/README.at91 |6 +- doc/README.ebony |2 +- doc/README.fsl-ddr |4 +- doc/README.mpc832xemds |2 +- doc/README.mpc8360emds |2 +- doc/README.mpc837xemds |2 +- doc/README.mpc8544ds |2 +- doc/README.mpc8572ds |4 +- doc/README.mpc85xxads|2 +- doc/README.mvbc_p|2 +- doc/README.mvblm7|4 +- doc/README.mvsmr |2 +- doc/README.ocotea|2 +- doc/README.p2020rdb |4 +- drivers/net/smc9.c | 15 +--- fs/fat/fat_write.c | 30 ++- include/configs/snapper9260.h|1 - lib/lzma/LzmaTools.c |4 +- tools/mkenvimage.c | 138 -- 28 files changed, 210 insertions(+), 132 deletions(-) Thanks! Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-arm/master
Dear Albert ARIBAUD,
In message <4f755c4a.5090...@aribaud.net> you wrote:
> Hi Wolfgang,
>
> The following changes since commit 7cb30b13f12077c7eec8ce2419cd96cd65ace8e2:
>
>Merge branch 'master' of git://git.denx.de/u-boot-cfi-flash
> (2012-03-23 21:59:16 +0100)
>
> are available in the git repository at:
>
>git://git.denx.de/u-boot-arm master
>
> Anatolij Gustschin (4):
>nhk8815: fix build errors
>board/vpac270/onenand.c: Fix build errors
>board/ti/beagle/beagle.c: Fix build warnings
>arch/arm/cpu/armv7/omap-common/clocks-common.c: Fix build warnings
>
> Andreas Bie�mann (1):
>atmel-boards: add missing atmel_mci.h
>
> Chander Kashyap (1):
>EXYNOS: Add structure for Exynos4 DMC
>
> Christian Riesch (1):
>calimain, enbw_cmc: Fix typo in comments
>
> David M�ller (ELSOFT AG) (1):
>ARM: fix s3c2410 timer code
>
> Dirk Behme (2):
>mx6q: mx6qsabrelite: Update the README
>imximage: Remove overwriting of flash_offset
>
> Doug Anderson (1):
>EXYNOS: SMDK5250: Support all 4 UARTs
>
> Eric Nelson (6):
>i.MX6: mx6qsabrelite: add ext2 support
>mx6q: mx6qsabrelite: setup_spi() should be called in board_init
> to allow use for environment
>i.MX6: mx6q_sabrelite: add CONFIG_REVISION_TAG
>i.MX6: mx6qsabrelite: add MACH_TYPE_MX6Q_SABRELITE
>net: force PKTALIGN to ARCH_DMA_MINALIGN
>net: fec_mxc: allow use with cache enabled
>
> Fabio Estevam (15):
>mx51evk: Fix CONFIG_SYS_MEMTEST_END
>mx53evk: Fix CONFIG_SYS_MEMTEST_END
>mx53smd: Fix CONFIG_SYS_MEMTEST_END
>efikamx: Fix CONFIG_SYS_MEMTEST_END
>mx31pdk: Fix CONFIG_SYS_MEMTEST_END
>mx6: Fix reset cause for Power On Reset case
>mx6: Remove duplicate definition of ANATOP_BASE_ADDR
>pmic_i2c: Return error in case of invalid pmic_i2c_tx_num
>mxs_spi: Return proper timeout error
>mx6: Read silicon revision from register
>USB: ehci-mx6: Add proper IO accessors
>mx28evk: Provide default values for SPI bus and chip select
>configs: imx: Use CONFIG_SF_DEFAULT_CS
>mx53: Make PLL2 to be the parent of UART clock
>mx53ard: Initialize return code with error
>
> Grazvydas Ignotas (1):
>twl4030: fix potential power supply handling issues
>
> Heiko Schocher (1):
>ARM: davinci: fixes for cam_enc_4xx board
>
> Helmut Raiger (1):
>mx31: add "ARM11P power gating" to get_reset_cause
>
> Jason Hobbs (1):
>ARM: highbank: change env config to use nvram
>
> Marek Vasut (23):
>PXA: Remove PXA PCMCIA support
>PXA: Fix warning in zipitz2
>PXA: Fix missing get_tbclk() breaking vpac boards
>M28: Fix LCD PINMUX
>M28: Support for the old M28 SoM v1.0
>i.MX28: Reformat the DRAM memory configuration data
>Examples: Properly append LDFLAGS to LD command
>IXP: Make IXP buildable with arm-linux- toolchains
>IXP: Fix missing MACH_TYPE_{ACTUX?,PNB3,DVLHOST}
>IXP: Squash warnings in IXP NPE
>IXP: Move PDNB3 and SCPU from Makefile to boards.cfg
>IXP: Fix NAND build warning on PDNB3 and SCPU
>IXP: Fix GPIO_INT_ACT_LOW_SET()
>i.MX28: Enable additional DRAM address bits
>i.MX28: Make the stabilization delays shorter
>i.MX28: Drop __naked function from spl_mem_init
>ARM926EJS: Implement cache operations
>i.MX28: Add cache support into the APBH DMA driver
>i.MX28: Add cache support to MXS NAND driver
>MMC: Implement generic bounce buffer
>i.MX28: Do data transfers via DMA in MMC driver
>i.MX28: Make use of the bounce buffer
>i.MX28: Enable caches by default
>
> Matt Porter (2):
>SPL: Add YMODEM over UART load support
>SPL: Enable YMODEM support on BeagleBone and AM335x EVM
>
> Rob Herring (8):
>net: calxedaxgmac: fix build due to missing __aligned definition
>ARM: highbank: fix warning for calxedaxgmac_initialize
>ARM: highbank: add missing get_tbclk
>ARM: highbank: fix us_to_tick calculation
>ARM: highbank: change TEXT_BASE to 0x8000
>ARM: highbank: Add boot counter support
>ARM: highbank: add reset support
>ARM: highbank: setup env from boot source register
>
> Robert Delien (5):
>i.mx28: Added register definitions for DIGCTL registers
>i.mx28: Replaced magic numbers for scratch register addresses
> with register definitions
>Renamed mx28_register to mx28_register_32 to prepare for
> mx28_register_8
>Introducing 8-bit wide register, mx28_register_8
>Fix erroneous 32-bit access to hw_clkctrl_frac0 and
> hw_clkctrl_frac1 registers
>
> Simon Glass (39):
>arm: Remove jornada link script
>fdt: Add fdtdec_find_aliases() to deal with alias nodes
>fdt: Add tests for fdtdec
>fdt:
[U-Boot] [PATCH v2] OMAP: Move omap1510inn to Unmaintained / Orphaned
After removing omap1610inn for not building, move omap1510inn to orphaned as it had the same maintainer. Signed-off-by: Tom Rini --- MAINTAINERS |7 +++ 1 files changed, 3 insertions(+), 4 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 72f8b64..708ded7 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -669,10 +669,6 @@ Igor Grinberg cm-t35 ARM ARMV7 (OMAP3xx Soc) -Kshitij Gupta - - omap1510inn ARM925T - Stefan Herbrechtsmeier dns325 ARM926EJS (Kirkwood SoC) @@ -941,6 +937,9 @@ Sughosh Ganu Unknown / orphaned boards: Board CPU Last known maintainer / Comment . + + omap1510inn ARM925T Kshitij Gupta + lubbock xscale/pxa Kyle Harris / dead address imx31_phycore_eet i.MX31 Guennadi Liakhovetski / resigned -- 1.7.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-staging
Dear Anatolij Gustschin, In message <20120330192423.3cd8e85c@wker> you wrote: > Hello Wolfgang, > > Please pull various fixes and patches that have been submitted > before merge window was closed. There is one patch from me, I know > that I may not push my own patches through the staging tree. But this > patch is trivial and has been acked by two people, so I hope this is okay. > > The following changes since commit 7cb30b13f12077c7eec8ce2419cd96cd65ace8e2: > > Merge branch 'master' of git://git.denx.de/u-boot-cfi-flash (2012-03-23 > 21:59:16 +0100) > > are available in the git repository at: > > git://git.denx.de/u-boot-staging.git ag...@denx.de > > Anatolij Gustschin (1): > fs/fat/fat_write.c: Fix GCC 4.6 warnings > > David Wagner (7): > mkenvimage: correct and clarify comments and error messages > mkenvimage: Correct an include and add a missing one > mkenvimage: More error handling > mkenvimage: Read/Write from/to stdin/out by default or if the filename > is "-" > mkenvimage: Use mmap() when reading from a regular file > mkenvimage: Don't try to detect comments in the input file > mkenvimage: Really set the redundant byte when applicable > > Donggeun Kim (2): > FAT write: Fix compile errors > cmd_fat: add FAT write command > > Jason Hobbs (1): > cmd_pxe.c: fix strict-aliasing warnings > > Liming Wang (1): > ARMV7/Vexpress: add missing get_ticks() and get_tbclk() > > Mike Frysinger (2): > net: smc9: use mdelay() > lzma: fix printf warnings > > Scott Wood (1): > MAKEALL: display SPL size if present > > Simon Glass (1): > Remove CONFIG_SYS_EXTBDINFO from snapper9260.h > > Thomas Weber (1): > doc: Fix some typos in different files > > Tim Kientzle (1): > disk/part.c: Fix device enumeration through API > > Wolfgang Denk (1): > mkenvimage: fix usage message > > MAKEALL |8 ++- > README |8 ++- > board/armltd/vexpress/ca9x4_ct_vxp.c | 10 +++ > common/cmd_fat.c | 57 ++ > common/cmd_pxe.c | 16 ++-- > disk/part.c |3 + > doc/README.AVR32-port-muxing |4 +- > doc/README.SNTP |2 +- > doc/README.Sandpoint8240 |6 +- > doc/README.at91 |6 +- > doc/README.ebony |2 +- > doc/README.fsl-ddr |4 +- > doc/README.mpc832xemds |2 +- > doc/README.mpc8360emds |2 +- > doc/README.mpc837xemds |2 +- > doc/README.mpc8544ds |2 +- > doc/README.mpc8572ds |4 +- > doc/README.mpc85xxads|2 +- > doc/README.mvbc_p|2 +- > doc/README.mvblm7|4 +- > doc/README.mvsmr |2 +- > doc/README.ocotea|2 +- > doc/README.p2020rdb |4 +- > drivers/net/smc9.c | 15 +--- > fs/fat/fat_write.c | 30 ++- > include/configs/snapper9260.h|1 - > lib/lzma/LzmaTools.c |4 +- > tools/mkenvimage.c | 138 > -- > 28 files changed, 210 insertions(+), 132 deletions(-) > > Thanks! Applied, thanks. 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 There is a theory which states that if ever anyone discovers exactly what the Universe is for and why it is here, it will instantly dis- appear and be replaced by something even more bizarre and inexpli- cable. There is another theory which states that this has already happened.-- Douglas Adams, "The Hitchhiker's Guide to the Galaxy" ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 02/20] i2c: Add TPS6586X driver
Hi Heiko,
On Sat, Jan 14, 2012 at 11:30 PM, Heiko Schocher wrote:
> Hello Simon,
>
> Simon Glass wrote:
>> This power management chip supports battery charging and a large number
>> of power supplies. This initial driver only provides the ability to adjust
>> the two synchronous buck converters SM0 and SM1 in a stepwise manner.
>>
>> Signed-off-by: Simon Glass
>> ---
>> Changes in v2:
>> - Split PMU code into separate TPS6586X driver
>>
>> drivers/power/Makefile | 1 +
>> drivers/power/tps6586x.c | 293
>> ++
>> include/tps6586x.h | 68 +++
>> 3 files changed, 362 insertions(+), 0 deletions(-)
>> create mode 100644 drivers/power/tps6586x.c
>> create mode 100644 include/tps6586x.h
>>
>> diff --git a/drivers/power/Makefile b/drivers/power/Makefile
>> index ead00f8..9db8ea2 100644
>> --- a/drivers/power/Makefile
>> +++ b/drivers/power/Makefile
>> @@ -28,6 +28,7 @@ LIB := $(obj)libpower.o
>> COBJS-$(CONFIG_FTPMU010_POWER) += ftpmu010.o
>> COBJS-$(CONFIG_TWL4030_POWER) += twl4030.o
>> COBJS-$(CONFIG_TWL6030_POWER) += twl6030.o
>> +COBJS-$(CONFIG_TPS6586X_POWER) += tps6586x.o
>
> please hold lists sorted.
Done
>
>> COBJS := $(COBJS-y)
>> SRCS := $(COBJS:.o=.c)
>> diff --git a/drivers/power/tps6586x.c b/drivers/power/tps6586x.c
>> new file mode 100644
>> index 000..5915d6f
>> --- /dev/null
>> +++ b/drivers/power/tps6586x.c
>> @@ -0,0 +1,293 @@
>> +/*
>> + * Copyright (c) 2011 The Chromium OS Authors.
>> + * (C) Copyright 2010,2011 NVIDIA Corporation
>> + *
>> + * 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
>> +#include
>> +#include
>> +#include
>> +
>> +/*
>> + * abs() handles unsigned ints, shorts and chars and returns a signed long.
>> + * TODO: Move this into common?
>> + */
>> +#define abs(x) ({ \
>> + long ret; \
>> + { \
>> + typeof((x)) __x = (x); \
>> + ret = (__x < 0) ? -__x : __x; \
>> + } \
>> + ret; \
>> + })
>
> I thought we have such a define, but couldn't find it ... I vote
> for moving it to common ...
OK will do.
Re the comment style, hopefully we are ok with this now.
[snip]
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/20] tegra: warmboot (suspend / resume) support
+Nvidia warmboot authors Hi Tom, On Sat, Jan 14, 2012 at 8:06 PM, Mike Frysinger wrote: > there are a few patches here where the Author hasn't provided his s-o-b tag, > so that'll need fixing ... > -mike I am going to post a new v3 series - can you please organise people to replace to each patch they write with their s-o-b tags if they are happy with it? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] zImage and raw ramdisk support -- test
On Fri, Mar 30, 2012 at 10:38 AM, Marek Vasut wrote: > Guys, > > I need final test on as much platforms as possible. Can you please run these > two > following patches and tell me if they work with zImage and raw ramdisk for > you? > > http://patchwork.ozlabs.org/patch/146848/ > http://patchwork.ozlabs.org/patch/147440/ > > I can't promise they will make it to this release (I've been pestering WD > pretty > thoroughly (sorry about that), though I'm starting to be unhappy to merge this > stuff at the verge of release myself). Hi Marek, These work great on my omap3 Beagle xM C / omap4 Panda, using a zImage and initramfs.. Just added the two appropriate board configs, to enable it.. #define CONFIG_CMD_BOOTZ #define CONFIG_SUPPORT_RAW_INITRD and used todays u-boot git head: http://git.denx.de/?p=u-boot.git;a=commit;h=7cb30b13f12077c7eec8ce2419cd96cd65ace8e2 Tested-by: Robert Nelson Regards, -- Robert Nelson http://www.rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] drivers/mmc/tegra2_mmc.c: fix GCC 4.6 warning
Dear Anatolij Gustschin, In message <1332942000-4992-1-git-send-email-ag...@denx.de> you wrote: > Fix: > tegra2_mmc.c: In function 'mmc_send_cmd': > tegra2_mmc.c:230:3: warning: 'mask' may be used uninitialized in this > function [-Wuninitialized] > > Signed-off-by: Anatolij Gustschin > Cc: Doug Anderson > Cc: Tom Warren > --- > gcc is wrong here, I think. But I'd like to have a clean > build log. > > Anatolij > > drivers/mmc/tegra2_mmc.c |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) Applied, thanks. Tom, Albert: hope this is OK with you; it fixes some real issues, and I want to get clear for -rc1. 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 Command, n.: Statement presented by a human and accepted by a computer in such a manner as to make the human feel as if he is in control. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] drivers/mmc/mmc.c: Fix build warning
Dear Anatolij Gustschin, In message <1333005872-4325-1-git-send-email-ag...@denx.de> you wrote: > Fix: > mmc.c: In function 'mmc_bounce_buffer_start': > mmc.c:132:13: warning: no return statement in function returning > non-void [-Wreturn-type] > > Signed-off-by: Anatolij Gustschin > Cc: Andy Fleming > Cc: Marek Vasut > --- > Note: This appears when building with merged u-boot-arm.git master. Applied, thanks. Albert, Andy: hope this is OK with you. 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 "Morality is one thing. Ratings are everything." - A Network 23 executive on "Max Headroom" ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PULL] u-boot-usb/master
The following changes since commit 7cb30b13f12077c7eec8ce2419cd96cd65ace8e2: Merge branch 'master' of git://git.denx.de/u-boot-cfi-flash (2012-03-23 21:59:16 +0100) are available in the git repository at: git://git.denx.de/u-boot-usb.git master for you to fetch changes up to f9da0f894328802cb8aaeb8a24660e37ff624d26: Enable high speed support for USB device framework and usbtty (2012-03-28 16:31:08 +0200) Vipin KUMAR (1): Enable high speed support for USB device framework and usbtty README|8 +++ drivers/serial/usbtty.c | 50 - drivers/serial/usbtty.h |4 +++ drivers/usb/gadget/core.c |1 - drivers/usb/gadget/ep0.c | 23 +--- include/usbdescriptors.h | 15 + include/usbdevice.h | 22 ++- 7 files changed, 116 insertions(+), 7 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] zImage and raw ramdisk support -- test
Dear Robert Nelson, > On Fri, Mar 30, 2012 at 10:38 AM, Marek Vasut wrote: > > Guys, > > > > I need final test on as much platforms as possible. Can you please run > > these two following patches and tell me if they work with zImage and raw > > ramdisk for you? > > > > http://patchwork.ozlabs.org/patch/146848/ > > http://patchwork.ozlabs.org/patch/147440/ > > > > I can't promise they will make it to this release (I've been pestering WD > > pretty thoroughly (sorry about that), though I'm starting to be unhappy > > to merge this stuff at the verge of release myself). > > Hi Marek, > > These work great on my omap3 Beagle xM C / omap4 Panda, using a zImage > and initramfs.. > > Just added the two appropriate board configs, to enable it.. > #define CONFIG_CMD_BOOTZ > #define CONFIG_SUPPORT_RAW_INITRD > > and used todays u-boot git head: > http://git.denx.de/?p=u-boot.git;a=commit;h=7cb30b13f12077c7eec8ce2419cd96c > d65ace8e2 And it makes u-boot about 20% cooler, doesn't it ;-) Thanks a lot for your testing! > Tested-by: Robert Nelson > > Regards, 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] command, log: print with "log show" a full logbuffer
Dear Heiko Schocher,
In message <1329390141-5356-1-git-send-email...@denx.de> you wrote:
> If the logbuffer contains LOGBUFF_LEN chars, they never got
> printed with the "log show" command, because chars get
> printed with the following for loop:
>
> for (i = 0; i < (size & LOGBUFF_MASK); i++) {
>
> with size = LOGBUFF_LEN and LOGBUFF_MASK = (LOGBUFF_LEN-1)
> for loop never executed ...
>
> Fix this.
>
> Signed-off-by: Heiko Schocher
> ---
> common/cmd_log.c |4 +++-
> 1 files changed, 3 insertions(+), 1 deletions(-)
Applied, thanks.
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
"This is a test of the Emergency Broadcast System. If this had been an
actual emergency, do you really think we'd stick around to tell you?"
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] cosmetic: command, log: Coding Style cleanup
Dear Heiko Schocher, In message <1329724730-22694-1-git-send-email...@denx.de> you wrote: > Signed-off-by: Heiko Schocher > Acked-by: Detlev Zundel > > --- > - changes for v2: > add cosmetic prefix as Detlev Zundel suggested. > > common/cmd_log.c | 98 - > 1 files changed, 52 insertions(+), 46 deletions(-) Applied, thanks. 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 "One planet is all you get." ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] standalone hello_world example crashes on PowerPC
I have also experienced the same problem, by using command md.w E8008080 10. according to our memory map of our custom board. please give solution or what is the cause for this problem. manukumar signal-networks ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] command, log: print log->v2.con value in the "log info" command
Dear Heiko Schocher, In message <1329294067-4472-2-git-send-email...@denx.de> you wrote: > print in the "log info" command, if "log_version = 2" also the > value from "log->v2.con". > > Signed-off-by: Heiko Schocher > --- > [hs@pollux u-boot]$ ./tools/checkpatch.pl > 20120215/0002-command-log-print-log-v2.con-value-in-the-log-info-c.patch > total: 0 errors, 0 warnings, 7 lines checked > > NOTE: Ignored message types: COMPLEX_MACRO CONSIDER_KSTRTO MINMAX > MULTISTATEMENT_MACRO_USE_DO_WHILE > > 20120215/0002-command-log-print-log-v2.con-value-in-the-log-info-c.patch has > no obvious style problems and is ready for submission. > > common/cmd_log.c |1 + > 1 files changed, 1 insertions(+), 0 deletions(-) Applied, thanks. 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 some day we are defeated, well, war has its fortunes, good and bad. -- Commander Kor, "Errand of Mercy", stardate 3201.7 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-nios/master
Hello Wolfgang, On Fri, 24 Feb 2012 11:39:24 +0800 Thomas Chou wrote: > Dear Wolfgang, > > The following changes since commit 2acca35ce4604dcef933f07d90aa9c9c930e1049: > > Merge branch 'master' of git://git.denx.de/u-boot-mmc (2012-02-17 23:54:46 > +0100) > > are available in the git repository at: > > git://git.denx.de/u-boot-nios.git master > > Alex Hornung (2): > nios2: implement get_ticks and get_tbclk > nios2 - adjust gbl data off to account for bd_info > > Stefan Kristiansson (1): > nios2: add flush_dcache_range function > > arch/nios2/cpu/interrupts.c | 21 + > arch/nios2/lib/cache.S | 10 ++ > include/configs/nios2-generic.h |3 ++- > 3 files changed, 33 insertions(+), 1 deletions(-) Just one note: After you have pulled these patches, we should also apply two other patches of the series from from Stefan Kristiansson: http://patchwork.ozlabs.org/patch/123622/ 1/3 http://patchwork.ozlabs.org/patch/123623/ 2/3 The 3rd patch of the series is already included in this pull request and should actually be applied first as the patches 1/3 and 2/3 depend on 3/3. The series is from last year, patches apply cleanly and are already acked. Thanks, Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4] MAKEALL: Add -m/-M option to determine maintainers
Dear Marek Vasut, In message <1330996251-24214-1-git-send-email-ma...@denx.de> you wrote: > The -m option tries to find the board in MAINTAINERS file and figure out the > email. The -M option lists boards including their maintainers emails and all > affiliated emails. There are multiple strategies used to retrieve these > emails: > > 1) Check board/ with git log and use three most recent emails > 2) Check board/ with git log and use three most used emails > 3) Try finding board in MAINTAINERS file and retrieve all emails from there > > The result is then sorted and unique results are retrieved and reported. > > For -m option, only strategy 3) is used. > > Signed-off-by: Marek Vasut > Cc: Wolfgang Denk > --- > MAKEALL | 115 > +-- > 1 files changed, 112 insertions(+), 3 deletions(-) Applied, thanks. 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 Real programmers don't comment their code. It was hard to write, it should be hard to understand. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] Add support for loading and saving the environment to a FAT partition
Dear Maximilian Schwerin, In message <1331632670-14874-2-git-send-email-...@tigris.de> you wrote: > The following must be defined: > > CONFIG_ENV_IS_IN_FAT > Enable this saving environment to FAT. > > FAT_ENV_INTERFACE > Interface the FAT resides on (e.g. mmc). > > FAT_ENV_DEVICE > The interface device number (e.g. 0 for mmc0) > > FAT_ENV_PART > The device part (e.g. 1 for mmc0:1) > > FAT_ENV_FILE > The filename of the environment file. > --- > common/Makefile |1 + > common/cmd_nvedit.c |3 +- > common/env_fat.c| 158 > +++ > 3 files changed, 161 insertions(+), 1 deletions(-) > create mode 100644 common/env_fat.c Applied, thanks. As your SoB was missing, I signed it. I also removed the dead "/* #define DEBUG */" line. 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 PUBLIC NOTICE AS REQUIRED BY LAW: Any Use of This Product, in Any Manner Whatsoever, Will Increase the Amount of Disorder in the Universe. Although No Liability Is Implied Herein, the Consumer Is Warned That This Process Will Ultimately Lead to the Heat Death of the Universe. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] pci: get rid of local prototypes
Dear "Linus Walleij", In message <1332713585-11084-1-git-send-email-linus.wall...@linaro.org> you wrote: > two boards were redeclaring pciauto_region_allocate() in their local > scope for no obvious reason, the function is in anyway, > this is probably just copying artifacts and old cruft. > > Signed-off-by: Linus Walleij > --- > board/esd/cpci750/pci.c |4 > board/prodrive/p3mx/pci.c |4 > 2 files changed, 0 insertions(+), 8 deletions(-) Applied, thanks. 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 Winners never talk about glorious victories. That's because they're the ones who see what the battlefield looks like afterwards. It's only the losers who have glorious victories. - Terry Pratchett, _Small Gods_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] pci: declare pciauto functions in header
Dear "Linus Walleij", In message <1332713595-11120-1-git-send-email-linus.wall...@linaro.org> you wrote: > The FSL PCI driver uses local prototypes for > pciauto_[pre|post]scan_setup_bridge(), this does not seem right, > so move them to the file. > > Fixed a small extern declaration too, this is harmless but distracts > the view since all other prototypes are explicitly external. > > Signed-off-by: Linus Walleij > --- > drivers/pci/fsl_pci_init.c |5 - > include/pci.h |6 +- > 2 files changed, 5 insertions(+), 6 deletions(-) Applied, thanks. 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 The only way you could make a happy marriage is by cuttin' their heads off as soon as they say `I do', yes? You can't make happi- ness... - Terry Pratchett, _Witches Abroad_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4] MAKEALL: Add -m/-M option to determine maintainers
Dear Wolfgang Denk, > Dear Marek Vasut, > > In message <1330996251-24214-1-git-send-email-ma...@denx.de> you wrote: > > The -m option tries to find the board in MAINTAINERS file and figure out > > the email. The -M option lists boards including their maintainers emails > > and all affiliated emails. There are multiple strategies used to > > retrieve these emails: > > > > 1) Check board/ with git log and use three most recent emails > > 2) Check board/ with git log and use three most used emails > > 3) Try finding board in MAINTAINERS file and retrieve all emails from > > there > > > > The result is then sorted and unique results are retrieved and reported. > > > > For -m option, only strategy 3) is used. > > > > Signed-off-by: Marek Vasut > > Cc: Wolfgang Denk > > --- > > > > MAKEALL | 115 > > +-- 1 files > > changed, 112 insertions(+), 3 deletions(-) > > Applied, thanks. bwahwhawhaaa ... now shake with fear, thee maintainers that don't care for their code and didn't dareth to write their name into MAINTAINERS as we shall find you anyway and ... pester you to fix your code. I'm off to shake with fear :) > Best regards, > > Wolfgang Denk 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 2/2] pci: declare pciauto functions in header
Dear "Linus Walleij", In message <1332713595-11120-1-git-send-email-linus.wall...@linaro.org> you wrote: > The FSL PCI driver uses local prototypes for > pciauto_[pre|post]scan_setup_bridge(), this does not seem right, > so move them to the file. > > Fixed a small extern declaration too, this is harmless but distracts > the view since all other prototypes are explicitly external. > > Signed-off-by: Linus Walleij > --- > drivers/pci/fsl_pci_init.c |5 - > include/pci.h |6 +- > 2 files changed, 5 insertions(+), 6 deletions(-) Applied, thanks. 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 There comes to all races an ultimate crisis which you have yet to face One day our minds became so powerful we dared think of ourselves as gods. -- Sargon, "Return to Tomorrow", stardate 4768.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx28evk: fix build error
Dear Anatolij Gustschin, In message <1333122327-5033-1-git-send-email-ag...@denx.de> you wrote: > Fix: > drivers/mmc/libmmc.o: In function `mxsmmc_send_cmd': > /home/ag/git/u-boot/drivers/mmc/mxsmmc.c:210: undefined reference to > `mxs_dma_desc_append' > /home/ag/git/u-boot/drivers/mmc/mxsmmc.c:211: undefined reference to > `mxs_dma_go' > drivers/mmc/libmmc.o: In function `mxsmmc_initialize': > /home/ag/git/u-boot/drivers/mmc/mxsmmc.c:306: undefined reference to > `mxs_dma_desc_alloc' > > Signed-off-by: Anatolij Gustschin > Cc: Fabio Estevam > --- > include/configs/mx28evk.h |5 + > 1 files changed, 5 insertions(+), 0 deletions(-) Applied, thanks. Albert Stefano: hope this is OK with you. 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 Two wrongs don't make a right, but three rights make a left. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V6] BOOT: Add "bootz" command to boot Linux zImage on ARM
Dear Marek Vasut, In message <1331797965-7415-1-git-send-email-ma...@denx.de> you wrote: > From: Marek Vasut > > This command boots Linux zImage from where the zImage is loaded to. Passing > initrd and fdt is supported. > > Tested on i.MX28 based DENX M28EVK > Tested on PXA270 based Voipac PXA270. > > NOTE: This currently only supports ARM, but other architectures can be easily > added by defining bootz_setup(). > > Signed-off-by: Marek Vasut > Cc: Tom Warren > Cc: albert.u.b...@aribaud.net > Cc: aflem...@gmail.com, > Cc: Simon Glass , > Cc: Stephen Warren > Cc: Nicolas Pitre > Cc: Wolfgang Denk > Cc: Detlev Zundel > --- > README |8 +++ > arch/arm/lib/bootm.c | 30 ++ > common/cmd_bootm.c | 141 > +++--- > include/config_cmd_all.h |1 + > 4 files changed, 171 insertions(+), 9 deletions(-) Applied, thanks. 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 Hi there! This is just a note from me, to you, to tell you, the per- son reading this note, that I can't think up any more famous quotes, jokes, nor bizarre stories, so you may as well go home. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/20] tegra: warmboot (suspend / resume) support
Will do. Jimmy/Wei/Yen - I'll send you an update when Simon posts v3 to u-boot@lists.denx.de, and you'll have to respond with a review (Acked-by) and Signed-off-by for each part of the patch series you originally authored. Thanks, Tom > -Original Message- > From: s...@google.com [mailto:s...@google.com] On Behalf Of Simon Glass > Sent: Friday, March 30, 2012 12:24 PM > To: Mike Frysinger > Cc: u-boot@lists.denx.de; Tom Warren; Jimmy Zhang; Yen Lin; Wei Ni > Subject: Re: [U-Boot] [PATCH v2 0/20] tegra: warmboot (suspend / resume) > support > > +Nvidia warmboot authors > > Hi Tom, > > On Sat, Jan 14, 2012 at 8:06 PM, Mike Frysinger wrote: > > there are a few patches here where the Author hasn't provided his > > s-o-b tag, so that'll need fixing ... > > -mike > > I am going to post a new v3 series - can you please organise people to > replace to each patch they write with their s-o-b tags if they are happy > with it? > > Regards, > Simon --- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. --- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] BOOT: Add RAW ramdisk support to bootz
Dear Rob Herring, In message <1332107278-24123-1-git-send-email-robherri...@gmail.com> you wrote: > From: Marek Vasut > > This patch allows loading RAW ramdisk via bootz command. The raw ramdisk is > loaded only in case it's size is specified: > > bootz : > > For example: > > bootz 0x4200 0x4300:0x12345 0x4400 > > Signed-off-by: Marek Vasut > Signed-off-by: Rob Herring > Cc: Tom Warren > Cc: albert.u.b...@aribaud.net > Cc: aflem...@gmail.com > Cc: Simon Glass > Cc: Stephen Warren > Cc: Nicolas Pitre > Cc: Wolfgang Denk > Cc: Detlev Zundel > --- > V3: > - fix operation when CONFIG_FIT is enabled as FIT images use > [:] > > README |5 + > common/cmd_bootm.c |6 -- > common/image.c | 15 --- > 3 files changed, 21 insertions(+), 5 deletions(-) Applied, thanks. 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 Never ascribe to malice that which can adequately be explained by stupidity. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/3] Enable access to FAT filesystem in an ISO9660 El-Torito volume
Dear Marek Vasut, In message <201202270008.56572.ma...@denx.de> you wrote: > > This series fixes several bugs in the FAT code and the USB storage > > stack to make it possible to read from a FAT filesystem image embedded > > as an "El-Torito boot image" in an ISO9660 volume (IE: a CD or DVD). > > > > This has been tested on the eXMeritus HWW-1U-1A > > > > I've addressed the review commentary on these patches and I believe > > that they should be acceptable for merging into "next" now. > > > > Cheers, > > Kyle Moffett > > > what's the status of this patch/patchset? It has been applied long ago. 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 Be kind to unkind people - they need it the most. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] BOOT: Add RAW ramdisk support to bootz
Dear Rob & Marek, In message <1332107278-24123-1-git-send-email-robherri...@gmail.com> you wrote: > From: Marek Vasut > > This patch allows loading RAW ramdisk via bootz command. The raw ramdisk is > loaded only in case it's size is specified: > > bootz : > > For example: > > bootz 0x4200 0x4300:0x12345 0x4400 > > Signed-off-by: Marek Vasut > Signed-off-by: Rob Herring > Cc: Tom Warren > Cc: albert.u.b...@aribaud.net > Cc: aflem...@gmail.com > Cc: Simon Glass > Cc: Stephen Warren > Cc: Nicolas Pitre > Cc: Wolfgang Denk > Cc: Detlev Zundel > --- > V3: > - fix operation when CONFIG_FIT is enabled as FIT images use > [:] Argh... This causes build warnings: + ./MAKEALL TQM860L Configuring for TQM860L board... image.c: In function 'boot_get_ramdisk': image.c:800: warning: unused variable 'end' Why do I get this at all? I did not enable any of the related bootz stuff on my board! Please fix! 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 Vulcans believe peace should not depend on force. -- Amanda, "Journey to Babel", stardate 3842.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] RAMDISK: Fix unused variable issue caused by raw rd support
image.c: In function ‘boot_get_ramdisk’: image.c:800:8: warning: unused variable ‘end’ [-Wunused-variable] Signed-off-by: Marek Vasut Cc: Wolfgang Denk --- common/image.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/common/image.c b/common/image.c index 103e0e6..342b315 100644 --- a/common/image.c +++ b/common/image.c @@ -797,7 +797,9 @@ int boot_get_ramdisk(int argc, char * const argv[], bootm_headers_t *images, ulong rd_addr, rd_load; ulong rd_data, rd_len; const image_header_t *rd_hdr; +#ifdef CONFIG_SUPPORT_RAW_INITRD char *end; +#endif #if defined(CONFIG_FIT) void*fit_hdr; const char *fit_uname_config = NULL; -- 1.7.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] RAMDISK: Fix unused variable issue caused by raw rd support
image.c: In function ‘boot_get_ramdisk’:
image.c:800:8: warning: unused variable ‘end’ [-Wunused-variable]
Signed-off-by: Marek Vasut
---
common/image.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/common/image.c b/common/image.c
index 103e0e6..d55d448 100644
--- a/common/image.c
+++ b/common/image.c
@@ -797,7 +797,6 @@ int boot_get_ramdisk(int argc, char * const argv[],
bootm_headers_t *images,
ulong rd_addr, rd_load;
ulong rd_data, rd_len;
const image_header_t *rd_hdr;
- char *end;
#if defined(CONFIG_FIT)
void*fit_hdr;
const char *fit_uname_config = NULL;
@@ -996,6 +995,7 @@ int boot_get_ramdisk(int argc, char * const argv[],
bootm_headers_t *images,
#endif
default:
#ifdef CONFIG_SUPPORT_RAW_INITRD
+ char *end;
if (argc >= 3 && (end = strchr(argv[2], ':'))) {
rd_len = simple_strtoul(++end, NULL, 16);
rd_data = rd_addr;
--
1.7.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] zImage and raw ramdisk support -- test
Dear Marek Vasut, In message <201203302224.20196.marek.va...@gmail.com> you wrote: > > > and used todays u-boot git head: > > http://git.denx.de/?p=u-boot.git;a=commit;h=7cb30b13f12077c7eec8ce2419cd96c > > d65ace8e2 > > And it makes u-boot about 20% cooler, doesn't it ;-) No. Just so many more build warnigns :-( 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 Bradley's Bromide: If computers get too powerful, we can organize them into a committee - that will do them in. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] RAMDISK: Fix unused variable issue caused by raw rd support
Dear Marek Vasut,
In message <1333142566-30899-1-git-send-email-ma...@denx.de> you wrote:
> image.c: In function ‘boot_get_ramdisk’:
> image.c:800:8: warning: unused variable ‘end’ [-Wunused-variable]
>
> Signed-off-by: Marek Vasut
> ---
> common/image.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/common/image.c b/common/image.c
> index 103e0e6..d55d448 100644
> --- a/common/image.c
> +++ b/common/image.c
> @@ -797,7 +797,6 @@ int boot_get_ramdisk(int argc, char * const argv[],
> bootm_headers_t *images,
> ulong rd_addr, rd_load;
> ulong rd_data, rd_len;
> const image_header_t *rd_hdr;
> - char *end;
> #if defined(CONFIG_FIT)
> void*fit_hdr;
> const char *fit_uname_config = NULL;
> @@ -996,6 +995,7 @@ int boot_get_ramdisk(int argc, char * const argv[],
> bootm_headers_t *images,
> #endif
> default:
> #ifdef CONFIG_SUPPORT_RAW_INITRD
> + char *end;
> if (argc >= 3 && (end = strchr(argv[2], ':'))) {
This works only with CONFIG_SUPPORT_RAW_INITRD undefined.
Otherwise you get:
image.c: In function 'boot_get_ramdisk':
image.c:1000: error: expected expression before 'char'
image.c:1001: error: 'end' undeclared (first use in this function)
image.c:1001: error: (Each undeclared identifier is reported only once
image.c:1001: error: for each function it appears in.)
You need braces to start a new block.
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
"In the face of entropy and nothingness, you kind of have to pretend
it's not there if you want to keep writing good code."
- Karl Lehenbauer
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] RAMDISK: Fix unused variable issue caused by raw rd support
Dear Marek Vasut, In message <1333142350-27117-1-git-send-email-ma...@denx.de> you wrote: > image.c: In function ‘boot_get_ramdisk’: > image.c:800:8: warning: unused variable ‘end’ [-Wunused-variable] > > Signed-off-by: Marek Vasut > Cc: Wolfgang Denk > --- > common/image.c |2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) Applied, thanks. But please don't send base64 encoded messages, because patchwork barfs on these: -> pwapply ~/Mail/U-Boot/13909 Applying patch #149753 to current directory Description: [U-Boot] RAMDISK: Fix unused variable issue caused by raw rd support Traceback (most recent call last): File "/home/wd/bin/pwclient", line 466, in main() File "/home/wd/bin/pwclient", line 449, in main action_apply(rpc, patch_id) File "/home/wd/bin/pwclient", line 264, in action_apply proc.communicate(s) File "/usr/lib64/python2.7/subprocess.py", line 737, in communicate self.stdin.write(input) UnicodeEncodeError: 'ascii' codec can't encode character u'\u2018' in position 406: ordinal not in range(128) 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 Do not underestimate the value of print statements for debugging. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PULL] u-boot-usb/master
Dear Marek Vasut, In message <201203302223.18444.ma...@denx.de> you wrote: > The following changes since commit 7cb30b13f12077c7eec8ce2419cd96cd65ace8e2: > > Merge branch 'master' of git://git.denx.de/u-boot-cfi-flash (2012-03-23 > 21:59:16 +0100) > > are available in the git repository at: > > > git://git.denx.de/u-boot-usb.git master > > for you to fetch changes up to f9da0f894328802cb8aaeb8a24660e37ff624d26: > > Enable high speed support for USB device framework and usbtty (2012-03-28 > 16:31:08 +0200) > > > Vipin KUMAR (1): > Enable high speed support for USB device framework and usbtty > > README|8 +++ > drivers/serial/usbtty.c | 50 > - > drivers/serial/usbtty.h |4 +++ > drivers/usb/gadget/core.c |1 - > drivers/usb/gadget/ep0.c | 23 +--- > include/usbdescriptors.h | 15 + > include/usbdevice.h | 22 ++- > 7 files changed, 116 insertions(+), 7 deletions(-) Applied, thanks. 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 Unix: Some say the learning curve is steep, but you only have to climb it once. - Karl Lehenbauer ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] net/ethoc: use flush_dcache_range instead of flush_dcache
Dear Stefan Kristiansson, In message <1320410288-15008-2-git-send-email-stefan.kristians...@saunalahti.fi> you wrote: > flush_dcache is not declared in the common.h API, > flush_dcache_range however is > > Signed-off-by: Stefan Kristiansson > Cc: Ben Warren > Cc: Thomas Chou > --- > drivers/net/ethoc.c |6 +++--- > 1 files changed, 3 insertions(+), 3 deletions(-) Applied, thanks. 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 Human beings were created by water to transport it uphill. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] net/altera_tse: use flush_dcache_range instead of flush_dcache
Dear Stefan Kristiansson, In message <1320410288-15008-3-git-send-email-stefan.kristians...@saunalahti.fi> you wrote: > flush_dcache is not declared in the common.h API, > flush_dcache_range however is > > Signed-off-by: Stefan Kristiansson > Cc: Ben Warren > Cc: Thomas Chou > --- > drivers/net/altera_tse.c |9 ++--- > 1 files changed, 6 insertions(+), 3 deletions(-) Applied, thanks. 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 "Now here's something you're really going to like!" - Rocket J. Squirrel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-nios/master
Dear Anatolij, In message <20120330223420.10a5d121@wker> you wrote: > Hello Wolfgang, > > On Fri, 24 Feb 2012 11:39:24 +0800 > Thomas Chou wrote: > > > Dear Wolfgang, > > > > The following changes since commit 2acca35ce4604dcef933f07d90aa9c9c930e1049: > > > > Merge branch 'master' of git://git.denx.de/u-boot-mmc (2012-02-17 > > 23:54:46 +0100) > > > > are available in the git repository at: > > > > git://git.denx.de/u-boot-nios.git master > > > > Alex Hornung (2): > > nios2: implement get_ticks and get_tbclk > > nios2 - adjust gbl data off to account for bd_info > > > > Stefan Kristiansson (1): > > nios2: add flush_dcache_range function > > > > arch/nios2/cpu/interrupts.c | 21 + > > arch/nios2/lib/cache.S | 10 ++ > > include/configs/nios2-generic.h |3 ++- > > 3 files changed, 33 insertions(+), 1 deletions(-) > > Just one note: > > After you have pulled these patches, we should also apply two > other patches of the series from from Stefan Kristiansson: > > http://patchwork.ozlabs.org/patch/123622/1/3 > http://patchwork.ozlabs.org/patch/123623/2/3 > > The 3rd patch of the series is already included in this pull > request and should actually be applied first as the patches > 1/3 and 2/3 depend on 3/3. The series is from last year, > patches apply cleanly and are already acked. Thanks for pointing out. I would have mised this without your help. 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 you're not part of the solution, then you're part of the precipi- tate. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [U-boot][INQUIRY] Intel 82599 10Gbe ethernet driver
Hello, This email is in regards to the i82599 driver being ported to U-Boot. Is anyone currently working on it? If not, I'm going to start adding it in. I should have something usable in a couple of weeks and I will conduct my testing on a P4080DS. Thank you. Regards, Timothy M. Smyth ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] net: ll_temac: Add LL TEMAC driver to u-boot
Hello Joe and Michal, Am Mittwoch, den 28.03.2012, 09:53 +0200 schrieb Michal Simek: > Hi Joe, > > >> Stephan Linz wrote: > >>> Xilinx LocalLink Tri-Mode Ether MAC driver can be > >>> used by Xilinx Microblaze or Xilinx ppc405/440 in > >>> SDMA and FIFO mode. DCR or XPS bus can be used. > >> Joe, Wolfgang: I don't agree with this driver because it is doing the same > >> things as my origin > >> version but on 800 lines instead of 1860lines. The next thing is that plb > >> bus on Xilinx fpgas > >> is getting obsolete. > > > > Are you meaning that you already have a driver in u-boot that works on > > this hardware or do you mean the original version somewhere else, like > > Linux? No, there is no u-boot custodian tree with an already merged driver. > > There is really long history about this u-boot driver. The origin version for > ppc was sent to mailing list > April 26, 2008 by Yoshio Kashiwagi. I have tried to add it to mainline > several times > and my latest attempts end with result that I didn't want to follow u-boot > coding style because > of ppc/microblaze differences (not using offset with structure because of > ppc/microblaze differences - dcr/plb access). > That driver has 800 lines. > Based on this strict rule I decided not to continue to push this driver to > mainline > because it is just a lot of work to change it and especially test it. My > origin driver is used by many our customers > on microblaze and ppc and none reported any problem with it. > > After this Stephan decided to change it to be acceptable to mainline > submission. Yes, I've reworked the driver since November 2011 and now, in contrast to the "800 lines" driver submitted by Michal, the new driver has more features than the differnet memory access methods for ppc/microblaze: - eliminates all private data exchange buffer - supports the NetBuf handling for FIFO and DMA mode - supports the new MII bus framework - supports potentially more than just the two memory access methods - includes a complete register description (structs and defines) - split into differnet parts for better overview and readability > > > > As for plb being near obsolescence, are you recommending a change to > > the driver to drop support for that bus option? Or do you mean for > > that reason the driver itself should be omitted? > > should be obsolete in a year or so and if you add it to mainline it will be > there > but in 2013 there will be minimal number of users for it. No! It may be that PLB will no longer be interesting for new designs. But there are many existing FPGA solutions which will use the latest software releases on it. Moreover, this also aplied to the PowerPC@FPGA world (DCR part). > > >> I am not going to add it to my microblaze custodian tree. > >> If you like this patch please add it to u-boot-net tree or directly to > >> mainline. I like it ;) but unfortunately I have no custodian tree :( > > > > I was actually going to recommend that it go through the microblaze > > branch if it is primarily for microblaze targets. If you don't want > > it, then I think Stephan needs to work to convince you by making > > revisions. > > None can convince me that 1860 code lines which fulfill all u-boot rules > is better than origin well tested 800 code lines (and commercially used) > which break one u-boot rule. Why not? The currently submitted driver has changes undergone a long review process by different submitters and maintainers of U-Boot. This driver is ready for future use (ex. the new MII bus and PHY device abstraction, fully qualified register description for further extensions if needed). > I agree with rules but none can expect that I will assist and help to add > it to mainline. I don't want to have responsibility for that. > > BTW: Target is also ppc because there is DCR support. If the DCR support is a problem, I can split the patches and separate the DCR support. Currently the DCR related code is about 80 LOCs and already enclosed by CONFIG_XILINX_440 and CONFIG_XILINX_405. br, Stephan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [STATUS] v2012.04-rc1 is out
Hi everybody, after long struggeling we finally have a -rc1. Please help testing, so we can fix the remaining issues before the release, which I decided to shift to April 21, 2012. Thanks to all who helped. Please note: Any help with processing patch backlog, for example through the u-boot-staging tree, is more than welcome. Thanks in advance! 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 Nearly everyone is in favor of going to heaven but too many are hoping they'll live long enough to see an easing of the entrance requirements. Never appeal to a man's "better nature." he might not have one. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] How to distinguish between the Linux kernel version above 3.0
Dear list, On the http://www.kernel.org/ , there are three stable version:3.0 ,3.1,and 3.2. Linux like crazy has introduced a new version.Present's edition naming method is as if different with 2.x. What do these editions have to distinguish? Best regards, Xu Yang ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] How to distinguish between the Linux kernel version above 3.0
On Friday 30 March 2012 21:53:23 徐阳 wrote: > On the http://www.kernel.org/ , there are three stable version:3.0 ,3.1,and > 3.2. > Linux like crazy has introduced a new version.Present's edition naming > method is as if different with 2.x. > What do these editions have to distinguish? this list is for u-boot, not linux. please seek help elsewhere. like the linux list. -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Malloc: Fix -Wundef warnings
On Thursday 29 March 2012 15:28:15 Marek Vasut wrote: > In file included from arch/arm/lib/board.c:43:0: > include/malloc.h:490:5: warning: "HAVE_MMAP" is not defined [-Wundef] > include/malloc.h:590:5: warning: "HAVE_USR_INCLUDE_MALLOC_H" is not defined > [-Wundef] include/malloc.h:757:5: warning: "HAVE_MMAP" is not defined > [-Wundef] how much of the tree warns with -Wundef ? with older code bases, i tend to find this sort of a useless flag. -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] How to distinguish between the Linux kernel version above 3.0
head Makefile On Sat, Mar 31, 2012 at 9:53 AM, 徐阳 wrote: > Dear list, > On the http://www.kernel.org/ , there are three stable version:3.0 > ,3.1,and > 3.2. > Linux like crazy has introduced a new version.Present's edition naming > method is as if different with 2.x. > What do these editions have to distinguish? > > > > Best regards, > Xu Yang > > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot > > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] v2012.04-rc1 is out
On 31.03.2012 01:40, Wolfgang Denk wrote: Hi everybody, after long struggeling we finally have a -rc1. :) Please help testing, so we can fix the remaining issues before the release, which I decided to shift to April 21, 2012. Thanks to all who helped. Please note: Any help with processing patch backlog, for example through the u-boot-staging tree, is more than welcome. Thanks in advance! It would be nice to get the following two patches into the final release: http://patchwork.ozlabs.org/patch/145515/ http://patchwork.ozlabs.org/patch/136789/ Many thanks Dirk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
