Re: [U-Boot] u-boot build error [from v2013.01 onwards]
Hi Vikram, On Sun, Jan 27, 2013 at 9:24 AM, Vikram Narayanan wrote: > On 1/27/2013 7:10 AM, Jagan Teki wrote: >> This error occurred for all boards in the u-boot, I have used >> arm-none-linux-gnueabi- xtool for versatilepb board. >> I saw this issue specially from 2013.01 on-wards. > > Can you check your host setup once? > > Below is the output from my setup. I don't see any error. > > $ git describe > v2013.01 > $ make ARCH=arm versatilepb_config > Configuring for versatilepb - Board: versatile, Options: ARCH_VERSATILE_PB > $ lsb_release -a > No LSB modules are available. > Distributor ID: Ubuntu > Description:Ubuntu 11.04 > Release:11.04 > Codename: natty Here is my LSB host settings Mr.J> lsb_release -a LSB Version: :core-4.0-amd64:core-4.0-ia32:core-4.0-noarch:graphics-4.0-amd64:graphics-4.0-ia32:graphics-4.0-noarch:printing-4.0-amd64:printing-4.0-ia32:printing-4.0-noarch Distributor ID: RedHatEnterpriseClient Description:Red Hat Enterprise Linux Client release 5.6 (Tikanga) Release:5.6 Codename: Tikanga I am getting same error irrespective any board. Does v2013.01 release builds depends on any perl versions Mr.J> perl -v This is perl, v5.8.5 built for x86_64-linux Thanks, Jagan. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Possible MMC subsystem bug
I'll need to double-check the spec, but I believe the BUSY bit has the opposite meaning of common sense. On Jan 26, 2013, at 22:32, "Marek Vasut" wrote: > Hi Andy, > > I was going through the MMC code, trying to get Phison 8007 SD-to-NAND bridge > working (don't ask please, this chip's sole existence defies any logic). > > So, I found the following code and I was wondering if the following patch is > not > needed. Maybe my brain is just giving up though. Give it some thought please > and > let me know, thanks! > > diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c > index 72e8ce6..94926ca 100644 > --- a/drivers/mmc/mmc.c > +++ b/drivers/mmc/mmc.c > @@ -475,8 +474,11 @@ static int sd_send_op_cond(struct mmc *mmc) >if (err) >return err; > > + if (!(cmd.response[0] & OCR_BUSY)) > + break; > + >udelay(1000); > - } while ((!(cmd.response[0] & OCR_BUSY)) && timeout--); > + } while (timeout--); > >if (timeout <= 0) >return UNUSABLE_ERR; > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Possible MMC subsystem bug
Dear Fleming Andy-AFLEMING, > I'll need to double-check the spec, but I believe the BUSY bit has the > opposite meaning of common sense. I tihnk my brain is maybe just giving up really ... I think the code is right after some quick poking through the spec. > On Jan 26, 2013, at 22:32, "Marek Vasut" wrote: > > Hi Andy, > > > > I was going through the MMC code, trying to get Phison 8007 SD-to-NAND > > bridge working (don't ask please, this chip's sole existence defies any > > logic). > > > > So, I found the following code and I was wondering if the following patch > > is not needed. Maybe my brain is just giving up though. Give it some > > thought please and let me know, thanks! > > > > diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c > > index 72e8ce6..94926ca 100644 > > --- a/drivers/mmc/mmc.c > > +++ b/drivers/mmc/mmc.c > > @@ -475,8 +474,11 @@ static int sd_send_op_cond(struct mmc *mmc) > > > >if (err) > > > >return err; > > > > + if (!(cmd.response[0] & OCR_BUSY)) > > + break; > > + > > > >udelay(1000); > > > > - } while ((!(cmd.response[0] & OCR_BUSY)) && timeout--); > > + } while (timeout--); > > > >if (timeout <= 0) > > > >return UNUSABLE_ERR; Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Possible MMC subsystem bug
Hi Andy, I was going through the MMC code, trying to get Phison 8007 SD-to-NAND bridge working (don't ask please, this chip's sole existence defies any logic). So, I found the following code and I was wondering if the following patch is not needed. Maybe my brain is just giving up though. Give it some thought please and let me know, thanks! diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c index 72e8ce6..94926ca 100644 --- a/drivers/mmc/mmc.c +++ b/drivers/mmc/mmc.c @@ -475,8 +474,11 @@ static int sd_send_op_cond(struct mmc *mmc) if (err) return err; + if (!(cmd.response[0] & OCR_BUSY)) + break; + udelay(1000); - } while ((!(cmd.response[0] & OCR_BUSY)) && timeout--); + } while (timeout--); if (timeout <= 0) return UNUSABLE_ERR; ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot build error [from v2013.01 onwards]
On 1/27/2013 7:10 AM, Jagan Teki wrote: > This error occurred for all boards in the u-boot, I have used > arm-none-linux-gnueabi- xtool for versatilepb board. > I saw this issue specially from 2013.01 on-wards. Can you check your host setup once? Below is the output from my setup. I don't see any error. $ git describe v2013.01 $ make ARCH=arm versatilepb_config Configuring for versatilepb - Board: versatile, Options: ARCH_VERSATILE_PB $ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description:Ubuntu 11.04 Release:11.04 Codename: natty ~Vikram ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot build error [from v2013.01 onwards]
Hi Albert On Sat, Jan 26, 2013 at 9:40 PM, Albert ARIBAUD wrote: > Hi Jagan, > > On Sat, 26 Jan 2013 18:34:56 +0530, Jagan Teki > wrote: > >> Hi, >> >> I am getting below error while configuring any board in the u-boot. >> >> bash> make versatilepb_config >> Makefile:597: *** missing `endif'. Stop. >> >> Host setup: >> >> Processor: x86_64 >> OS: Red Hat Enterprise Linux Client release 5.6 >> u-boot version: v2013.01 >> >> Request for any help. > > Can you indicate which target you are building, with which command line > exactly, and which toolchain you are using? This error occurred for all boards in the u-boot, I have used arm-none-linux-gnueabi- xtool for versatilepb board. I saw this issue specially from 2013.01 on-wards. Thanks, Jagan. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] mx23: Enable bit 24 of HW_DRAM_CTL08 as did in imx-bootlets
Dear Otavio Salvador,
What does "bit 24" mean and what impact does it have? Commit message is
missing.
Also, I don't see patch 3/3
> Signed-off-by: Otavio Salvador
> ---
> arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c
> b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c index 836e636..a9efd87 100644
> --- a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c
> +++ b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c
> @@ -90,7 +90,7 @@ static uint32_t dram_vals[] = {
> #elif defined(CONFIG_MX23)
> 0x01010001, 0x00010100, 0x01000101, 0x0001,
> 0x0101, 0x, 0x0001, 0x0101,
> - 0x, 0x0001, 0x07000200, 0x00070202,
> + 0x0100, 0x0001, 0x07000200, 0x00070202,
> 0x0202, 0x04040a01, 0x0201, 0x0204,
> 0x0200, 0x19000f08, 0x0d0d, 0x02021313,
> 0x02061521, 0x000a, 0x00080008, 0x00200020,
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] mxs: Use SoC agnostic configuration option for power switch setting
Dear Otavio Salvador,
> The power switch option is compatible with i.MX23 and i.MX28 so the
> configration option needs to reflect it. We choose
> 'CONFIG_SPL_MXS_PSWITCH_WAIT' for the option name.
The Subject should be "Rename CONFIG_SPL_MX28_PSWITCH_WAIT to
CONFIG_SPL_MXS_PSWITCH_WAIT" or something
> Signed-off-by: Otavio Salvador
> ---
> arch/arm/cpu/arm926ejs/mxs/mxs_init.h | 2 +-
> arch/arm/cpu/arm926ejs/mxs/spl_power_init.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/cpu/arm926ejs/mxs/mxs_init.h
> b/arch/arm/cpu/arm926ejs/mxs/mxs_init.h index 2ddc5bc..084def5 100644
> --- a/arch/arm/cpu/arm926ejs/mxs/mxs_init.h
> +++ b/arch/arm/cpu/arm926ejs/mxs/mxs_init.h
> @@ -30,7 +30,7 @@ void early_delay(int delay);
>
> void mxs_power_init(void);
>
> -#ifdef CONFIG_SPL_MX28_PSWITCH_WAIT
> +#ifdef CONFIG_SPL_MXS_PSWITCH_WAIT
> void mxs_power_wait_pswitch(void);
> #else
> static inline void mxs_power_wait_pswitch(void) { }
> diff --git a/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c
> b/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c index e9d6302..287c698
> 100644
> --- a/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c
> +++ b/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c
> @@ -921,7 +921,7 @@ void mxs_power_init(void)
> early_delay(1000);
> }
>
> -#ifdef CONFIG_SPL_MX28_PSWITCH_WAIT
> +#ifdef CONFIG_SPL_MXS_PSWITCH_WAIT
> void mxs_power_wait_pswitch(void)
> {
> struct mxs_power_regs *power_regs =
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 V5 10/10] EXYNOS5: I2C: Added FDT and non-FDT support for I2C
Hi Amar,
On Tue, Jan 22, 2013 at 12:43 AM, Amar wrote:
> This patch adds FDT and non-FDT support for I2C, and initialise
> the I2C channels.
>
> Signed-off-by: Amar
> ---
> Changes since V4:
> New patch.
>
> drivers/i2c/s3c24x0_i2c.c | 13 +++--
> 1 file changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/i2c/s3c24x0_i2c.c b/drivers/i2c/s3c24x0_i2c.c
> index 769a2ba..f2a035c 100644
> --- a/drivers/i2c/s3c24x0_i2c.c
> +++ b/drivers/i2c/s3c24x0_i2c.c
> @@ -524,11 +524,12 @@ int i2c_write(uchar chip, uint addr, int alen, uchar
> *buffer, int len)
> len) != 0);
> }
>
> -#ifdef CONFIG_OF_CONTROL
> void board_i2c_init(const void *blob)
> {
> + int i;
> +#ifdef CONFIG_OF_CONTROL
> int node_list[CONFIG_MAX_I2C_NUM];
> - int count, i;
> + int count;
>
> count = fdtdec_find_aliases_for_id(blob, "i2c",
> COMPAT_SAMSUNG_S3C2440_I2C, node_list,
> @@ -548,8 +549,16 @@ void board_i2c_init(const void *blob)
> bus->bus_num = i2c_busses++;
> exynos_pinmux_config(bus->id, 0);
> }
> +#else
> + for (i = 0; i < CONFIG_MAX_I2C_NUM; i++) {
> + exynos_pinmux_config((PERIPH_ID_I2C0 + i),
> + PINMUX_FLAG_NONE);
> + }
> +#endif
> + i2c_init(CONFIG_SYS_I2C_SPEED, CONFIG_SYS_I2C_SLAVE);
I suggest this goes up one line, since it shouldn't be needed in the
FDT case, right?
> }
>
> +#ifdef CONFIG_OF_CONTROL
> static struct s3c24x0_i2c_bus *get_bus(unsigned int bus_idx)
> {
> if (bus_idx < i2c_busses)
> --
> 1.8.0
>
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V5 09/10] COMMON: MMC: Command to support EMMC booting and to resize EMMC boot partition
Hi Amar,
On Tue, Jan 22, 2013 at 12:43 AM, Amar wrote:
> This patch adds commands to access(open/close) and resize boot partitions on
> EMMC.
Acked-by: Simon Glass
(Minor nit below)
>
> Signed-off-by: Amar
> ---
> Changes since V1:
> 1)Combined the common piece of code between 'open' and 'close'
> operations.
>
> Changes since V2:
> 1)Updation of commit message and resubmition of proper patch set.
>
> Changes since V3:
> No change.
>
> Changes since V4:
> 1)Added a new funtion boot_part_access() to combine the common parts
> of
> 'mmc open' and 'mmc close' functionalities.
> 2)Used the generic function "mmc_boot_part_access()" instead of
> two functions "mmc_boot_open()" and "mmc_boot_close()". By doing so
> user
> can specify which boot partition to be accessed (opened / closed).
>
> common/cmd_mmc.c | 98
> +++-
> 1 file changed, 97 insertions(+), 1 deletion(-)
>
> diff --git a/common/cmd_mmc.c b/common/cmd_mmc.c
> index 7dacd51..d036d34 100644
> --- a/common/cmd_mmc.c
> +++ b/common/cmd_mmc.c
> @@ -147,6 +147,31 @@ U_BOOT_CMD(
> "- display info of the current MMC device"
> );
>
> +static int boot_part_access(struct mmc *mmc, u32 ack, u32 part_num, u32
> access)
> +{
> + int err;
> + err = mmc_boot_part_access(mmc, ack, part_num, access);
> +
> + if ((err == 0) && (access != 0)) {
> + printf("\t\t\t!!!Notice!!!\n");
> + printf("!You must close EMMC boot Partition after all"
> + "images are written\n");
> + printf("!EMMC boot partition has continuity at image"
> + "writing time.\n");
> + printf("!So, Do not close boot partition, Before, all"
> + "images are written.\n");
So, do not close the boot partition before all images are written
> + return 0;
> + } else if ((err == 0) && (access == 0))
> + return 0;
> + else if ((err != 0) && (access != 0)) {
> + printf("EMMC boot partition-%d OPEN Failed.\n", part_num);
> + return 1;
> + } else {
> + printf("EMMC boot partition-%d CLOSE Failed.\n", part_num);
> + return 1;
> + }
> +}
> +
> static int do_mmcops(cmd_tbl_t *cmdtp, int flag, int argc, char * const
> argv[])
> {
> enum mmc_state state;
> @@ -248,6 +273,71 @@ static int do_mmcops(cmd_tbl_t *cmdtp, int flag, int
> argc, char * const argv[])
> curr_device, mmc->part_num);
>
> return 0;
> + } else if ((strcmp(argv[1], "open") == 0) ||
> + (strcmp(argv[1], "close") == 0)) {
> + int dev;
> + struct mmc *mmc;
> + u32 ack, part_num, access = 0;
> +
> + if (argc == 4) {
> + dev = simple_strtoul(argv[2], NULL, 10);
> + part_num = simple_strtoul(argv[3], NULL, 10);
> + } else
> + return CMD_RET_USAGE;
> +
> + mmc = find_mmc_device(dev);
> + if (!mmc) {
> + printf("no mmc device at slot %x\n", dev);
> + return 1;
> + }
> +
> + if (IS_SD(mmc)) {
> + printf("SD device cannot be opened/closed\n");
> + return 1;
> + }
> +
> + if ((part_num <= 0) || (part_num > MMC_NUM_BOOT_PARTITION)) {
> + printf("Invalid boot partition number:\n");
> + printf("Boot partition number cannot be <= 0\n");
> + printf("EMMC44 supports only 2 boot partitions\n");
> + return 1;
> + }
> +
> + if (strcmp(argv[1], "open") == 0)
> + access = part_num; /* enable R/W access to boot part*/
> + if (strcmp(argv[1], "close") == 0)
> + access = 0; /* No access to boot partition */
> +
> + /* acknowledge to be sent during boot operation */
> + ack = 1;
> + return boot_part_access(mmc, ack, part_num, access);
> +
> + } else if (strcmp(argv[1], "bootpart") == 0) {
> + int dev;
> + dev = simple_strtoul(argv[2], NULL, 10);
> +
> + u32 bootsize = simple_strtoul(argv[3], NULL, 10);
> + u32 rpmbsize = simple_strtoul(argv[4], NULL, 10);
> + struct mmc *mmc = find_mmc_device(dev);
> + if (!mmc) {
> + printf("no mmc device at slot %x\n", dev);
> + return 1;
> + }
> +
> + if (IS_SD(mmc)) {
> + printf("It is not a EMMC devic
Re: [U-Boot] [PATCH V5 08/10] SMDK5250: Enable EMMC booting
On Tue, Jan 22, 2013 at 12:43 AM, Amar wrote:
> This patch adds support for EMMC booting on SMDK5250.
>
> Signed-off-by: Amar
Acked-by: Simon Glass
> ---
> Changes since V1:
> 1)Updated spl_boot.c file to maintain irom pointer table
> instead of using the #define values defined in header file.
>
> Changes since V2:
> 1)Updation of commit message and resubmition of proper patch set.
>
> Changes since V3:
> No change.
>
> Changes since V4:
> 1)The function get_irom_func(int index) has been added to avoid
> type casting at many places.
> 2)The changes to file arch/arm/include/asm/arch-exynos/clk.h are
> included in this patch file.
>
> arch/arm/include/asm/arch-exynos/clk.h | 3 ++
> board/samsung/smdk5250/clock_init.c| 15 ++
> board/samsung/smdk5250/clock_init.h| 5
> board/samsung/smdk5250/spl_boot.c | 52
> ++
> 4 files changed, 69 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm/include/asm/arch-exynos/clk.h
> b/arch/arm/include/asm/arch-exynos/clk.h
> index 1935b0b..a4d5b4e 100644
> --- a/arch/arm/include/asm/arch-exynos/clk.h
> +++ b/arch/arm/include/asm/arch-exynos/clk.h
> @@ -29,6 +29,9 @@
> #define VPLL 4
> #define BPLL 5
>
> +#define FSYS1_MMC0_DIV_MASK0xff0f
> +#define FSYS1_MMC0_DIV_VAL 0x0701
> +
> unsigned long get_pll_clk(int pllreg);
> unsigned long get_arm_clk(void);
> unsigned long get_i2c_clk(void);
> diff --git a/board/samsung/smdk5250/clock_init.c
> b/board/samsung/smdk5250/clock_init.c
> index c009ae5..154993c 100644
> --- a/board/samsung/smdk5250/clock_init.c
> +++ b/board/samsung/smdk5250/clock_init.c
> @@ -28,6 +28,7 @@
> #include
> #include
> #include
> +#include
>
> #include "clock_init.h"
> #include "setup.h"
> @@ -664,3 +665,17 @@ void clock_init_dp_clock(void)
> /* We run DP at 267 Mhz */
> setbits_le32(&clk->div_disp1_0, CLK_DIV_DISP1_0_FIMD1);
> }
> +
> +/*
> + * Set clock divisor value for booting from EMMC.
> + * Set DWMMC channel-0 clk div to operate mmc0 device at 50MHz.
> + */
> +void emmc_boot_clk_div_set(void)
> +{
> + struct exynos5_clock *clk = (struct exynos5_clock
> *)EXYNOS5_CLOCK_BASE;
> + unsigned int div_mmc;
> +
> + div_mmc = readl((unsigned int) &clk->div_fsys1) &
> ~FSYS1_MMC0_DIV_MASK;
> + div_mmc |= FSYS1_MMC0_DIV_VAL;
> + writel(div_mmc, (unsigned int) &clk->div_fsys1);
> +}
> diff --git a/board/samsung/smdk5250/clock_init.h
> b/board/samsung/smdk5250/clock_init.h
> index f751bcb..20a1d47 100644
> --- a/board/samsung/smdk5250/clock_init.h
> +++ b/board/samsung/smdk5250/clock_init.h
> @@ -146,4 +146,9 @@ struct mem_timings *clock_get_mem_timings(void);
> * Initialize clock for the device
> */
> void system_clock_init(void);
> +
> +/*
> + * Set clock divisor value for booting from EMMC.
> + */
> +void emmc_boot_clk_div_set(void);
> #endif
> diff --git a/board/samsung/smdk5250/spl_boot.c
> b/board/samsung/smdk5250/spl_boot.c
> index d8f3c1e..4ddbd4a 100644
> --- a/board/samsung/smdk5250/spl_boot.c
> +++ b/board/samsung/smdk5250/spl_boot.c
> @@ -23,15 +23,42 @@
> #include
> #include
>
> +#include
> +#include
> +#include
> +
> +#include "clock_init.h"
> +
> +/* Index into irom ptr table */
> +enum index {
> + MMC_INDEX,
> + EMMC44_INDEX,
> + EMMC44_END_INDEX,
> + SPI_INDEX,
> +};
> +
> +/* IROM Function Pointers Table */
> +u32 irom_ptr_table[] = {
> + [MMC_INDEX] = 0x02020030, /* iROM Function Pointer-SDMMC boot */
> + [EMMC44_INDEX] = 0x02020044,/* iROM Function Pointer-EMMC4.4
> boot*/
> + [EMMC44_END_INDEX] = 0x02020048,/* iROM Function Pointer
> + -EMMC4.4 end boot operation */
> + [SPI_INDEX] = 0x02020058, /* iROM Function Pointer-SPI boot */
> + };
> +
> enum boot_mode {
> BOOT_MODE_MMC = 4,
> BOOT_MODE_SERIAL = 20,
> + BOOT_MODE_EMMC = 8, /* EMMC4.4 */
> /* Boot based on Operating Mode pin settings */
> BOOT_MODE_OM = 32,
> BOOT_MODE_USB, /* Boot using USB download */
> };
>
> - typedef u32 (*spi_copy_func_t)(u32 offset, u32 nblock, u32 dst);
> +void *get_irom_func(int index)
> +{
> + return (void *) *(u32 *)irom_ptr_table[index];
> +}
>
> /*
> * Copy U-boot from mmc to RAM:
> @@ -40,23 +67,36 @@ enum boot_mode {
> */
> void copy_uboot_to_ram(void)
> {
> - spi_copy_func_t spi_copy;
> enum boot_mode bootmode;
> - u32 (*copy_bl2)(u32, u32, u32);
> -
> + u32 (*spi_copy)(u32 offset, u32 nblock, u32 dst);
> + u32 (*copy_bl2)(u32 offset, u32 nblock, u32 dst);
> + u32 (*copy_bl2_from_emmc)(u32 nblock, u32 dst);
> + void (*end_bootop_from_emmc)(void);
> + /* read Operation Mode ststus register to find the bootmode */
> bootmode = readl(EXYNOS5_POWER_BASE) & OM_STAT;
>
> switch (bootmode) {
Re: [U-Boot] [PATCH V5 07/10] MMC: APIs to support resize of EMMC boot partition
Hi Amar,
On Tue, Jan 22, 2013 at 12:43 AM, Amar wrote:
> This patch adds APIs to access(open / close) and to resize boot partiton of
> EMMC.
>
> Signed-off-by: Amar
> ---
> Changes since V1:
> New patch.
>
> Changes since V2:
> 1)Updation of commit message and resubmition of proper patch set.
>
> Changes since V3:
> No change.
>
> Changes since V4:
> 1)Replaced the functions mmc_boot_open() & mmc_boot_close() with a
> single function mmc_boot_part_access().
>
> drivers/mmc/mmc.c | 117
> ++
> include/mmc.h | 24 +++
> 2 files changed, 141 insertions(+)
>
> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
> index 72e8ce6..c152934 100644
> --- a/drivers/mmc/mmc.c
> +++ b/drivers/mmc/mmc.c
> @@ -1327,3 +1327,120 @@ int mmc_initialize(bd_t *bis)
>
> return 0;
> }
> +
> +int mmc_boot_partition_size_change(struct mmc *mmc, unsigned long bootsize,
> + unsigned long rpmbsize)
> +{
> + int err;
> + struct mmc_cmd cmd;
> +
> + /* Only use this command for raw EMMC moviNAND */
> + /* Enter backdoor mode */
Should probably join these two comments.
> + cmd.cmdidx = MMC_CMD_RES_MAN;
> + cmd.resp_type = MMC_RSP_R1b;
> + cmd.cmdarg = MMC_CMD62_ARG1;
> +
> + err = mmc_send_cmd(mmc, &cmd, NULL);
> + if (err) {
> + debug("mmc_boot_partition_size_change: Error1 = %d\n", err);
> + return err;
> + }
> +
> + /* Boot partition changing mode */
> + cmd.cmdidx = MMC_CMD_RES_MAN;
> + cmd.resp_type = MMC_RSP_R1b;
> + cmd.cmdarg = MMC_CMD62_ARG2;
> +
> + err = mmc_send_cmd(mmc, &cmd, NULL);
> + if (err) {
> + debug("mmc_boot_partition_size_change: Error2 = %d\n", err);
> + return err;
> + }
> + /* boot partition size is multiple of 128KB */
> + bootsize = ((bootsize*1024)/128);
space around * and /
plus remove outer ()
> +
> + /* Arg: boot partition size */
> + cmd.cmdidx = MMC_CMD_RES_MAN;
> + cmd.resp_type = MMC_RSP_R1b;
> + cmd.cmdarg = bootsize;
> +
> + err = mmc_send_cmd(mmc, &cmd, NULL);
> + if (err) {
> + debug("mmc_boot_partition_size_change: Error3 = %d\n", err);
> + return err;
> + }
> + /* RPMB partition size is multiple of 128KB */
> + rpmbsize = ((rpmbsize*1024)/128);
and here
> + /* Arg: RPMB partition size */
> + cmd.cmdidx = MMC_CMD_RES_MAN;
> + cmd.resp_type = MMC_RSP_R1b;
> + cmd.cmdarg = rpmbsize;
> +
> + err = mmc_send_cmd(mmc, &cmd, NULL);
> + if (err) {
> + debug("mmc_boot_partition_size_change: Error4 = %d\n", err);
> + return err;
> + }
> + return 0;
> +}
> +
> +/* This function shall form and send the commands to open / close the
/*
* This function...
> + * boot partition specified by user.
> + *
> + * ack: 0x0 - No boot acknowledge sent (default)
> + * 0x1 - Boot acknowledge sent during boot operation
> + * part_num: User selects boot data that will be sent to master
> + * 0x0 - Device not boot enabled (default)
> + * 0x1 - Boot partition 1 enabled for boot
> + * 0x2 - Boot partition 2 enabled for boot
> + * access: User selects partitions to access
> + * 0x0 : No access to boot partition (default)
> + * 0x1 : R/W boot partition 1
> + * 0x2 : R/W boot partition 2
> + * 0x3 : R/W Replay Protected Memory Block (RPMB)
> + */
> +int mmc_boot_part_access(struct mmc *mmc, u32 ack, u32 part_num, u32 access)
> +{
> + int err;
> + struct mmc_cmd cmd;
> +
> + /* Boot ack enable, boot partition enable , boot partition access */
> + cmd.cmdidx = MMC_CMD_SWITCH;
> + cmd.resp_type = MMC_RSP_R1b;
> +
> + cmd.cmdarg = (MMC_SWITCH_MODE_WRITE_BYTE << 24 |
> + EXT_CSD_PART_CONF << 16 |
> + (EXT_CSD_BOOT_ACK(ack) |
> + EXT_CSD_BOOT_PART_NUM(part_num) |
> + EXT_CSD_PARTITION_ACCESS(access)) << 8);
You can remove outer (). Might be nice to put () around the << sub-expressions:
cmd.cmdarg = (MMC_SWITCH_MODE_WRITE_BYTE << 24) |
(EXT_CSD_PART_CONF << 16) |
> +
> + err = mmc_send_cmd(mmc, &cmd, NULL);
> + if (err) {
> + if (access) {
> + debug("mmc boot partition#%d open failure:"
> + "Error1 = %d\n", part_num, err);
> + } else {
> + debug("mmc boot partition#%d close failure:"
> + "Error = %d\n", part_num, err);
> + }
> + return err;
> + }
> +
> + if (access) {
> + /* 4bit transfer mode at booting time. */
> + cmd.cmdidx = MMC_CMD_SWITCH;
> +
Re: [U-Boot] [PATCH V5 06/10] SMDK5250: Initialise and Enable DWMMC, support FDT and non-FDT
Hi Amar,
On Tue, Jan 22, 2013 at 12:43 AM, Amar wrote:
> This patch enables and initialises DWMMC for SMDK5250.
> Supports both FDT and non-FDT. This patch creates a new file
> 'exynos5-dt.c' meant for FDT support.
> exynos5-dt.c: This file shall contain all code which supports FDT.
> Any addition of FDT support for any module needs to be
> added in this file.
> smdk5250.c: This file shall contain the code which supports
> non-FDT.
> version. Any addition of non-FDT support for any
> module
> needs to be added in this file.
> May be, the file smdk5250.c can be removed in near
> future
> when non-FDT is not required.
>
> The Makefile is updated to compile only one of the files
> exynos5-dt.c / smdk5250.c based on FDT configuration.
>
> NOTE:
> Please note that all additions corresponding to FDT need to be added into the
> file exynos5-dt.c.
> At same time if non-FDT support is required then add the corresponding
> updations into smdk5250.c.
>
> Signed-off-by: Amar
This looks OK to me. It could perhaps be separated into a patch to
create the exynos5-dt.c file, and a separate one to enable the mmc,
but I think this is fine.
I am a little concerned at the possible code duplication between
smdk250.c and exynos5-dt.c - if this becomes a problem later perhaps
you could create a common file for things like board_uart_init().
Acked-by: Simon Glass
> ---
> Changes since V1:
> 1)A new file 'exynos5-dt.c' is created meant for FDT support
> 2)Makefile is updated to compile only one of the files
> exynos5-dt.c / smdk5250.c based on FDT configuration
>
> Changes since V2:
> 1)Updation of commit message and resubmition of proper patch set.
>
> Changes since V3:
> No change.
>
> Changes since V4:
> 1)Replaced the function call 'exynos_dwmmc_init(0, 8);' with the
> function exynos_dwmmc_add_port() in smdk5250.c.
> 2)dram_init() is updated to use for loop to compute the ram size.
> 3)dram_init_banksize() is updated to use for loop to initialise
> the dram bank size.
> 4)board_uart_init() is updated to use for loop to initialise UARTS.
> 5)In non-FDT case NULL is passed as parameter to board_i2c_init().
>
> board/samsung/smdk5250/Makefile | 4 +
> board/samsung/smdk5250/exynos5-dt.c | 211
>
> board/samsung/smdk5250/smdk5250.c | 170 ++---
> include/configs/exynos5250-dt.h | 6 +
> 4 files changed, 279 insertions(+), 112 deletions(-)
> create mode 100644 board/samsung/smdk5250/exynos5-dt.c
>
> diff --git a/board/samsung/smdk5250/Makefile b/board/samsung/smdk5250/Makefile
> index 47c6a5a..ecca9f3 100644
> --- a/board/samsung/smdk5250/Makefile
> +++ b/board/samsung/smdk5250/Makefile
> @@ -32,8 +32,12 @@ COBJS+= tzpc_init.o
> COBJS += smdk5250_spl.o
>
> ifndef CONFIG_SPL_BUILD
> +ifdef CONFIG_OF_CONTROL
> +COBJS += exynos5-dt.o
> +else
> COBJS += smdk5250.o
> endif
> +endif
>
> ifdef CONFIG_SPL_BUILD
> COBJS += spl_boot.o
> diff --git a/board/samsung/smdk5250/exynos5-dt.c
> b/board/samsung/smdk5250/exynos5-dt.c
> new file mode 100644
> index 000..a4b0e10
> --- /dev/null
> +++ b/board/samsung/smdk5250/exynos5-dt.c
> @@ -0,0 +1,211 @@
> +/*
> + * Copyright (C) 2012 Samsung Electronics
> + *
> + * 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
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +DECLARE_GLOBAL_DATA_PTR;
> +
> +int board_init(void)
> +{
> + gd->bd->bi_boot_params = (PHYS_SDRAM_1 + 0x100UL);
> +#ifdef CONFIG_EXYNOS_SPI
> + spi_init();
> +#endif
> + return 0;
> +}
> +
> +int dram_init(void)
> +{
> + int i;
> + u32 addr;
> +
> + for (i = 0; i < CONFIG_NR_DRAM_BANKS; i++) {
> + addr = CONFIG_SYS_SDRAM_BASE + (i * SDRAM_BANK_SIZE);
> + gd->ram_size += get_ram_size((long *)addr, SDRAM_B
Re: [U-Boot] [PATCH V5 05/10] EXYNOS5: DWMMC: Initialise the local variable to avoid unwanted results.
On Tue, Jan 22, 2013 at 12:43 AM, Amar wrote: > This patch initialises the local variable 'shift' to zero. > The uninitialised local variable 'shift' had garbage value and was > resulting in unwnated results in the functions exynos5_get_mmc_clk() > and exynos4_get_mmc_clk(). > > Signed-off-by: Amar Acked-by: Simon Glass > --- > Changes since V1: > 1)Updated the function exynos5_mmc_set_clk_div() to receive > 'device_i'd as input parameter instead of 'index'. > > Changes since V2: > 1)Updation of commit message and resubmition of proper patch set. > > Changes since V3: > 1)Removed the new API exynos5_mmc_set_clk_div() from clock.c, > because existing API set_mmc_clk() can be used to set mmc clock. > > Changes since V4: > 1)Updated the subject line to reflect the changes present in this > patch. > 2)Changes of the file arch/arm/include/asm/arch-exynos/clk.h which > were present in this patch, have been moved out of this patch. > > arch/arm/cpu/armv7/exynos/clock.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/arch/arm/cpu/armv7/exynos/clock.c > b/arch/arm/cpu/armv7/exynos/clock.c > index 956427c..edce21c 100644 > --- a/arch/arm/cpu/armv7/exynos/clock.c > +++ b/arch/arm/cpu/armv7/exynos/clock.c > @@ -490,7 +490,7 @@ static unsigned long exynos4_get_mmc_clk(int dev_index) > (struct exynos4_clock *)samsung_get_base_clock(); > unsigned long uclk, sclk; > unsigned int sel, ratio, pre_ratio; > - int shift; > + int shift = 0; > > sel = readl(&clk->src_fsys); > sel = (sel >> (dev_index << 2)) & 0xf; > @@ -539,7 +539,7 @@ static unsigned long exynos5_get_mmc_clk(int dev_index) > (struct exynos5_clock *)samsung_get_base_clock(); > unsigned long uclk, sclk; > unsigned int sel, ratio, pre_ratio; > - int shift; > + int shift = 0; > > sel = readl(&clk->src_fsys); > sel = (sel >> (dev_index << 2)) & 0xf; > -- > 1.8.0 > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V5 04/10] EXYNOS5: DWMMC: Added FDT support for DWMMC
Hi,
On Tue, Jan 22, 2013 at 12:43 AM, Amar wrote:
> This patch adds FDT support for DWMMC, by reading the DWMMC node data
> from the device tree and initialising DWMMC channels as per data
> obtained from the node.
>
> Signed-off-by: Vivek Gautam
> Signed-off-by: Amar
Acked-by: Simon Glass
See below for nit/question.
> ---
> Changes since V1:
> 1)Updated code to have same signature for the function
> exynos_dwmci_init() for both FDT and non-FDT versions.
> 2)Updated code to pass device_id parameter to the function
> exynos5_mmc_set_clk_div() instead of index.
> 3)Updated code to decode the value of "samsung,width" from FDT.
> 4)Channel index is computed instead of getting from FDT.
>
> Changes since V2:
> 1)Updation of commit message and resubmition of proper patch set.
>
> Changes since V3:
> 1)Replaced the new function exynos5_mmc_set_clk_div() with the
> existing function set_mmc_clk(). set_mmc_clk() will do the purpose.
> 2)Computation of FSYS block clock divisor (pre-ratio) is added.
>
> Changes since V4:
> 1)Replaced "unsigned int exynos_dwmmc_init(int index, int bus_width)"
> with
> int exynos_dwmci_add_port(int, u32, inth, u32)
> i)exynos_dwmmc_add_port() will be used by non-FDT boards.
> ii)In FDT case, exynos_dwmmc_init(const void *blob) will use
> exynos_dwmmc_add_port() for every channel enabled in device
> node.
> 2)Changed the computation method of mmc clock divisor.
> 3)Updated exynos_dwmmc_init() to compute the 'clksel_val' within the
> function.
>
> arch/arm/include/asm/arch-exynos/dwmmc.h | 11 +--
> drivers/mmc/exynos_dw_mmc.c | 127
> ---
> include/dwmmc.h | 3 +
> 3 files changed, 124 insertions(+), 17 deletions(-)
>
> diff --git a/arch/arm/include/asm/arch-exynos/dwmmc.h
> b/arch/arm/include/asm/arch-exynos/dwmmc.h
> index 8acdf9b..3b147b8 100644
> --- a/arch/arm/include/asm/arch-exynos/dwmmc.h
> +++ b/arch/arm/include/asm/arch-exynos/dwmmc.h
> @@ -27,10 +27,7 @@
> #define DWMCI_SET_DRV_CLK(x) ((x) << 16)
> #define DWMCI_SET_DIV_RATIO(x) ((x) << 24)
>
> -int exynos_dwmci_init(u32 regbase, int bus_width, int index);
> -
> -static inline unsigned int exynos_dwmmc_init(int index, int bus_width)
> -{
> - unsigned int base = samsung_get_base_mmc() + (0x1 * index);
> - return exynos_dwmci_init(base, bus_width, index);
> -}
> +#ifdef CONFIG_OF_CONTROL
> +int exynos_dwmmc_init(const void *blob);
> +#endif
> +int exynos_dwmci_add_port(int index, u32 regbase, int bus_width, u32 clksel);
> diff --git a/drivers/mmc/exynos_dw_mmc.c b/drivers/mmc/exynos_dw_mmc.c
> index 72a31b7..1d09e56 100644
> --- a/drivers/mmc/exynos_dw_mmc.c
> +++ b/drivers/mmc/exynos_dw_mmc.c
> @@ -19,39 +19,146 @@
> */
>
> #include
> -#include
> #include
> +#include
> +#include
> +#include
> #include
> #include
> +#include
>
> -static char *EXYNOS_NAME = "EXYNOS DWMMC";
> +#defineDWMMC_MAX_CH_NUM4
> +#defineDWMMC_MAX_FREQ 5200
> +#defineDWMMC_MIN_FREQ 40
> +#defineDWMMC_MMC0_CLKSEL_VAL 0x03030001
> +#defineDWMMC_MMC2_CLKSEL_VAL 0x03020001
>
> +/*
> + * Function used as callback function to initialise the
> + * CLKSEL register for every mmc channel.
> + */
> static void exynos_dwmci_clksel(struct dwmci_host *host)
> {
> - u32 val;
> - val = DWMCI_SET_SAMPLE_CLK(DWMCI_SHIFT_0) |
> - DWMCI_SET_DRV_CLK(DWMCI_SHIFT_0) | DWMCI_SET_DIV_RATIO(0);
> + dwmci_writel(host, DWMCI_CLKSEL, host->clksel_val);
> +}
>
> - dwmci_writel(host, DWMCI_CLKSEL, val);
> +unsigned int exynos_dwmci_get_clk(int dev_index)
> +{
> + return get_mmc_clk(dev_index);
> }
>
> -int exynos_dwmci_init(u32 regbase, int bus_width, int index)
> +/*
> + * This function adds the mmc channel to be registered with mmc core.
> + * index - mmc channel number.
> + * regbase - register base address of mmc channel specified in 'index'.
> + * bus_width - operating bus width of mmc channel specified in 'index'.
> + * clksel -value to be written into CLKSEL register in case of FDT.
> + * NULL in case od non-FDT.
> + */
> +int exynos_dwmci_add_port(int index, u32 regbase, int bus_width, u32 clksel)
> {
> struct dwmci_host *host = NULL;
> + unsigned int div;
> + unsigned long freq, sclk;
> host = malloc(sizeof(struct dwmci_host));
> if (!host) {
> printf("dwmci_host malloc fail!\n");
> return 1;
> }
> + /* request mmc clock vlaue of 50MHz. */
> + freq = 5000;
Should this be 52MHz?
> + sclk = get_mmc_clk(index);
> + div = DIV_ROUND_UP(sclk, freq);
> + /* set the clock divisor for mmc */
> + set_mmc_clk(index
Re: [U-Boot] [PATCH 3/3 V2] EXYNOS5: GPIO: Enable GPIO Command for EXYNOS5
Hi Rajeshwari,
On Wed, Jan 23, 2013 at 2:48 AM, Rajeshwari Shinde
wrote:
> This patch enables GPIO Command for EXYNOS5.
> Function has been added to asm/gpio.h to decode the
> input gpio name to gpio number.
> example: gpio set gpa00
> GPIO_INPUT in cmd_gpio.c has been modified to
> GPIO_DIRECTION_INPUT as GPIO_INPUT is alraedy defined in
> exynos5 and leading to a error.
>
> Signed-off-by: Rajeshwari Shinde
Great to see this - some comments below.
> ---
> Chnages in V2:
> - New patch
> arch/arm/include/asm/arch-exynos/gpio.h | 88
> +++
> common/cmd_gpio.c |6 +-
> include/configs/exynos5250-dt.h |1 +
> 3 files changed, 92 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/include/asm/arch-exynos/gpio.h
> b/arch/arm/include/asm/arch-exynos/gpio.h
> index af882dd..66e4a8e 100644
> --- a/arch/arm/include/asm/arch-exynos/gpio.h
> +++ b/arch/arm/include/asm/arch-exynos/gpio.h
> @@ -657,6 +657,94 @@ static inline unsigned int s5p_gpio_part_max(int nr)
> void gpio_cfg_pin(int gpio, int cfg);
> void gpio_set_pull(int gpio, int mode);
> void gpio_set_drv(int gpio, int mode);
> +
> +#include
> +
> +static inline int name_to_gpio(const char *name)
> +{
> + int num;
> +
> + name++;
> +
> + if (*name == 'p') {
> + ++name;
> +
> + switch (*name) {
> + case 'a':
> + name++;
> + num = simple_strtoul(name, NULL, 8);
> + num = GPIO_A00 + num;
> + break;
> + case 'b':
> + name++;
> + num = simple_strtoul(name, NULL, 8);
> + num = GPIO_B00 + num;
> + break;
> + case 'c':
> + name++;
> + num = simple_strtoul(name, NULL, 10);
> + if (num >= 40)
> + num = GPIO_C40 + (num - 40);
> + else {
> + num = simple_strtoul(name, NULL, 8);
> + num = GPIO_C00 + num;
> + }
> + break;
> + case 'd':
> + name++;
> + num = simple_strtoul(name, NULL, 8);
> + num = GPIO_D00 + num;
> + break;
> + case 'y':
> + name++;
> + num = simple_strtoul(name, NULL, 8);
> + num = GPIO_Y00 + num;
> + break;
> + case 'x':
> + name++;
> + num = simple_strtoul(name, NULL, 8);
> + num = GPIO_X00 + num;
> + break;
> + case 'e':
> + name++;
> + num = simple_strtoul(name, NULL, 8);
> + num = GPIO_E00 + num;
> + break;
> + case 'f':
> + name++;
> + num = simple_strtoul(name, NULL, 8);
> + num = GPIO_F00 + num;
> + break;
> + case 'g':
> + name++;
> + num = simple_strtoul(name, NULL, 8);
> + num = GPIO_G00 + num;
> + break;
> + case 'h':
> + name++;
> + num = simple_strtoul(name, NULL, 8);
> + num = GPIO_H00 + num;
> + break;
> + case 'v':
> + name++;
> + num = simple_strtoul(name, NULL, 8);
> + num = GPIO_V00 + num;
> + break;
> + case 'z':
> + name++;
> + num = simple_strtoul(name, NULL, 8);
> + num = GPIO_Z0 + num;
> + break;
> + default:
It seems like you need a table (C struct) containing the GPIO letter
and the associated GPIO_... value. Then this code could become a for()
loop to search for the match. This would reduce code duplication. 'c'
would presumable still be a special case.
> + return -1;
> + }
> + } else
> + return -1;
> +
> + return num;
> +}
> +
> +#define name_to_gpio(n) name_to_gpio(n)
> #endif
>
> /* Pin configurations */
> diff --git a/common/cmd_gpio.c b/common/cmd_gpio.c
> index 47eee89..450e6d1 100644
> --- a/common/cmd_gpio.c
> +++ b/common/cmd_gpio.c
> @@ -16,7 +16,7 @@
> #endif
>
> enum gpio_cmd {
> - GPIO_INPUT,
> + GPIO_DIRECTION_INPUT,
Actually I think it is exynos that should change - perhaps put an
EXYNOS prefix on that one.
> GPIO_SET,
> GPIO_CLEAR,
> GPIO_TOGGLE,
Re: [U-Boot] [PATCH 2/3 V2] EXYNOS5: Add gpio pin numbering feature
Hi,
On Wed, Jan 23, 2013 at 2:48 AM, Rajeshwari Shinde
wrote:
> This patch adds support for gpio pin numbering support on EXYNOS5
> pinmux.
>
> Signed-off-by: Leela Krishna Amudala
> Signed-off-by: Rajeshwari Shinde
> ---
> Changes in V2:
> - none.
> arch/arm/cpu/armv7/exynos/pinmux.c | 148 +
> arch/arm/include/asm/arch-exynos/gpio.h | 360
> ++-
> 2 files changed, 413 insertions(+), 95 deletions(-)
>
> diff --git a/arch/arm/include/asm/arch-exynos/gpio.h
> b/arch/arm/include/asm/arch-exynos/gpio.h
> index cfe1024..af882dd 100644
> --- a/arch/arm/include/asm/arch-exynos/gpio.h
> +++ b/arch/arm/include/asm/arch-exynos/gpio.h
> @@ -272,15 +272,355 @@ void s5p_gpio_set_rate(struct s5p_gpio_bank *bank, int
> gpio, int mode);
> - EXYNOS5_GPIO_PART3_BASE) / sizeof(struct s5p_gpio_bank)) \
> * GPIO_PER_BANK) + pin) + EXYNOS5_GPIO_PART2_MAX)
>
> +/* A list of valid GPIO numbers for the asm-generic/gpio.h interface */
> +enum exynos5_gpio_pin {
> + /* GPIO_PART1_STARTS */
> + GPIO_A00,
> + GPIO_A01,
> + GPIO_A02,
> + GPIO_A03,
[snip]
> + GPIO_V44,
> + GPIO_V45,
> + GPIO_V46,
> + GPIO_V47,
> +
> + /* GPIO_PART4_STARTS */
> + GPIO_PART3_MAX,
> + GPIO_Z0 = GPIO_PART3_MAX,
> + GPIO_Z1,
> + GPIO_Z2,
> + GPIO_Z3,
> + GPIO_Z4,
> + GPIO_Z5,
> + GPIO_Z6,
> + GPIO_MAX_PORT
> +};
> +
> static inline unsigned int s5p_gpio_base(int nr)
> {
> if (cpu_is_exynos5()) {
> - if (nr < EXYNOS5_GPIO_PART1_MAX)
> + if (nr < GPIO_PART1_MAX)
> return EXYNOS5_GPIO_PART1_BASE;
> - else if (nr < EXYNOS5_GPIO_PART2_MAX)
> + else if (nr < GPIO_PART2_MAX)
> return EXYNOS5_GPIO_PART2_BASE;
> - else
> + else if (nr < GPIO_PART3_MAX)
> return EXYNOS5_GPIO_PART3_BASE;
> + else
> + return EXYNOS5_GPIO_PART4_BASE;
>
> } else if (cpu_is_exynos4()) {
> if (nr < EXYNOS4_GPIO_PART1_MAX)
> @@ -295,12 +635,14 @@ static inline unsigned int s5p_gpio_base(int nr)
> static inline unsigned int s5p_gpio_part_max(int nr)
> {
> if (cpu_is_exynos5()) {
> - if (nr < EXYNOS5_GPIO_PART1_MAX)
> + if (nr < GPIO_PART1_MAX)
> return 0;
> - else if (nr < EXYNOS5_GPIO_PART2_MAX)
> - return EXYNOS5_GPIO_PART1_MAX;
> + else if (nr < GPIO_PART2_MAX)
> + return GPIO_PART1_MAX;
> + else if (nr < GPIO_PART3_MAX)
> + return GPIO_PART2_MAX;
> else
> - return EXYNOS5_GPIO_PART2_MAX;
> + return GPIO_PART3_MAX;
>
> } else if (cpu_is_exynos4()) {
> if (nr < EXYNOS4_GPIO_PART1_MAX)
> @@ -311,6 +653,10 @@ static inline unsigned int s5p_gpio_part_max(int nr)
>
> return 0;
> }
Do these functions need to be inline in the header file, or could they
move to the GPIO driver?
> +
> +void gpio_cfg_pin(int gpio, int cfg);
> +void gpio_set_pull(int gpio, int mode);
> +void gpio_set_drv(int gpio, int mode);
> #endif
>
> /* Pin configurations */
> --
> 1.7.4.4
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3 V2] S5P: GPIO: Add generic pin numbering API's
Hi Rajeshwari,
On Wed, Jan 23, 2013 at 2:48 AM, Rajeshwari Shinde
wrote:
> This patch adds API's to set config, drive and pull factor in
> gpio pin mumbering feature.
nit: numbering
>
> Signed-off-by: Rajeshawari Shinde
Acked-by: Simon Glass
> ---
> Changes in V2:
> - none.
> drivers/gpio/s5p_gpio.c | 18 ++
> 1 files changed, 18 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/gpio/s5p_gpio.c b/drivers/gpio/s5p_gpio.c
> index 656bf4a..a53bdca 100644
> --- a/drivers/gpio/s5p_gpio.c
> +++ b/drivers/gpio/s5p_gpio.c
> @@ -196,3 +196,21 @@ int gpio_set_value(unsigned gpio, int value)
>
> return 0;
> }
> +
> +void gpio_set_pull(int gpio, int mode)
> +{
> + s5p_gpio_set_pull(s5p_gpio_get_bank(gpio),
> + s5p_gpio_get_pin(gpio), mode);
> +}
> +
> +void gpio_set_drv(int gpio, int mode)
> +{
> + s5p_gpio_set_drv(s5p_gpio_get_bank(gpio),
> + s5p_gpio_get_pin(gpio), mode);
> +}
> +
> +void gpio_cfg_pin(int gpio, int cfg)
> +{
> + s5p_gpio_cfg_pin(s5p_gpio_get_bank(gpio),
> + s5p_gpio_get_pin(gpio), cfg);
> +}
> --
> 1.7.4.4
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 9/9 v6] EXYNOS5: FDT: Add a H/W-trip member to TMU node
Hi Akshay,
On Thu, Jan 24, 2013 at 4:24 AM, Akshay Saraswat wrote:
> This adds a member to TMU FDT node for providing hardware
> tripping temperature threshold.
>
> Signed-off-by: Akshay Saraswat
> ---
> Changes since v5:
> - New patch.
>
> board/samsung/dts/exynos5250-smdk5250.dts |1 +
> doc/device-tree-bindings/exynos/tmu.txt |5 -
> 2 files changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/board/samsung/dts/exynos5250-smdk5250.dts
> b/board/samsung/dts/exynos5250-smdk5250.dts
> index 00dac40..1c2d52d 100644
> --- a/board/samsung/dts/exynos5250-smdk5250.dts
> +++ b/board/samsung/dts/exynos5250-smdk5250.dts
> @@ -72,6 +72,7 @@
> samsung,max-temp= <125>;
> samsung,start-warning = <95>;
> samsung,start-tripping = <105>;
> + samsung,hw-tripping = <110>;
> samsung,efuse-min-value = <40>;
> samsung,efuse-value = <55>;
> samsung,efuse-max-value = <100>;
> diff --git a/doc/device-tree-bindings/exynos/tmu.txt
> b/doc/device-tree-bindings/exynos/tmu.txt
> index 779b01c..424395e 100644
> --- a/doc/device-tree-bindings/exynos/tmu.txt
> +++ b/doc/device-tree-bindings/exynos/tmu.txt
> @@ -13,7 +13,9 @@ Required properties:
> - samsung,max-temp : Maximum temperature value (125 degree celsius)
> - Current temperature of SoC should be less than this value.
> - samsung,start-warning : Temperature at which TMU starts giving warning
> (degree celsius)
> - - samsung,start-tripping : Temperature at which system will trip and
> shutdown (degree celsius)
> + - samsung,start-tripping : Temperature at which TMU shutdowns the system
> (degree celsius)
s/shutdowns/shuts down/
> + - samsung,hw-tripping : Temperature at which hardware tripping should happen
> + in case TMU fails to poweroff (degree celsius)
maybe two words 'power off'
> - samsung,efuse-min-value : SOC efuse min value (Constant 40)
> - efuse-value should be more than this value.
> - samsung,efuse-value : SOC actual efuse value (Literal value)
> @@ -38,6 +40,7 @@ tmu@1006 {
> samsung,max-temp = <125>;
> samsung,start-warning = <95>;
> samsung,start-tripping = <105>;
> + samsung,hw-tripping = <110>;
> samsung,efuse-min-value = <40>;
> samsung,efuse-value = <55>;
> samsung,efuse-max-value = <100>;
> --
> 1.7.9.5
>
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 8/9 v6] EXYNOS5: TMU: Add hardware tripping
On Thu, Jan 24, 2013 at 4:24 AM, Akshay Saraswat wrote: > This adds hardware tripping at 110 degrees celsius which must enable > forced system shutdown in case TMU fails to poweroff. > > Signed-off-by: Akshay Saraswat Acked-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/3] mx23evk: Adjust DRAM control register to use full 128MB of RAM
Signed-off-by: Otavio Salvador
---
board/freescale/mx23evk/spl_boot.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/board/freescale/mx23evk/spl_boot.c
b/board/freescale/mx23evk/spl_boot.c
index 6007433..b6f4e7e 100644
--- a/board/freescale/mx23evk/spl_boot.c
+++ b/board/freescale/mx23evk/spl_boot.c
@@ -98,6 +98,16 @@ const iomux_cfg_t iomux_setup[] = {
(MXS_PAD_4MA | MXS_PAD_3V3 | MXS_PAD_NOPULL),
};
+#define HW_DRAM_CTL14 (0x38 >> 2)
+#define CS_MAP 0x3
+#define INTAREF0x2
+#define HW_DRAM_CTL14_CONFIG (INTAREF << 8 | CS_MAP)
+
+void mxs_adjust_memory_params(uint32_t *dram_vals)
+{
+ dram_vals[HW_DRAM_CTL14] = HW_DRAM_CTL14_CONFIG;
+}
+
void board_init_ll(void)
{
mxs_common_spl_init(iomux_setup, ARRAY_SIZE(iomux_setup));
--
1.8.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/3] mx23: Enable bit 24 of HW_DRAM_CTL08 as did in imx-bootlets
Signed-off-by: Otavio Salvador
---
arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c
b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c
index 836e636..a9efd87 100644
--- a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c
+++ b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c
@@ -90,7 +90,7 @@ static uint32_t dram_vals[] = {
#elif defined(CONFIG_MX23)
0x01010001, 0x00010100, 0x01000101, 0x0001,
0x0101, 0x, 0x0001, 0x0101,
- 0x, 0x0001, 0x07000200, 0x00070202,
+ 0x0100, 0x0001, 0x07000200, 0x00070202,
0x0202, 0x04040a01, 0x0201, 0x0204,
0x0200, 0x19000f08, 0x0d0d, 0x02021313,
0x02061521, 0x000a, 0x00080008, 0x00200020,
--
1.8.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/3] mxs: Use SoC agnostic configuration option for power switch setting
The power switch option is compatible with i.MX23 and i.MX28 so the
configration option needs to reflect it. We choose
'CONFIG_SPL_MXS_PSWITCH_WAIT' for the option name.
Signed-off-by: Otavio Salvador
---
arch/arm/cpu/arm926ejs/mxs/mxs_init.h | 2 +-
arch/arm/cpu/arm926ejs/mxs/spl_power_init.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/mxs/mxs_init.h
b/arch/arm/cpu/arm926ejs/mxs/mxs_init.h
index 2ddc5bc..084def5 100644
--- a/arch/arm/cpu/arm926ejs/mxs/mxs_init.h
+++ b/arch/arm/cpu/arm926ejs/mxs/mxs_init.h
@@ -30,7 +30,7 @@ void early_delay(int delay);
void mxs_power_init(void);
-#ifdef CONFIG_SPL_MX28_PSWITCH_WAIT
+#ifdef CONFIG_SPL_MXS_PSWITCH_WAIT
void mxs_power_wait_pswitch(void);
#else
static inline void mxs_power_wait_pswitch(void) { }
diff --git a/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c
b/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c
index e9d6302..287c698 100644
--- a/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c
+++ b/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c
@@ -921,7 +921,7 @@ void mxs_power_init(void)
early_delay(1000);
}
-#ifdef CONFIG_SPL_MX28_PSWITCH_WAIT
+#ifdef CONFIG_SPL_MXS_PSWITCH_WAIT
void mxs_power_wait_pswitch(void)
{
struct mxs_power_regs *power_regs =
--
1.8.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mxs: mxsboot: Add support for SD card generation for i.MX23
Dear Otavio Salvador, > On Sat, Jan 26, 2013 at 3:03 PM, Marek Vasut wrote: > > Dear Otavio Salvador, > > > > Putting Stefano on Cc, why is he omitted? > > > >> On Fri, Jan 25, 2013 at 10:40 AM, Marek Vasut wrote: > >> >> On Thu, Jan 24, 2013 at 4:31 PM, Otavio Salvador > >> >> > >> >> wrote: > >> >> > I prefer to have this as is and share documentation with mx28. The > >> >> > NAND ought to be done providing same interface so one doc for it > >> >> > all. I think change it in next version is wrong and confuse users. > >> >> > >> >> Ping? > >> >> > >> >> We won't be able to get rid of mxsboot for NAND use-case so I'd > >> >> prefer to have it for SD as well. For me it does not matter much as > >> >> I use OE and it automates it all; but for ordinary user it is > >> >> important to it to be consistent so all 'mxs' SoC would work same > >> >> way from user point of view. > >> >> > >> >> If we find a better way of doing things in future we can base on this > >> >> and improve it later but please let's get it in and move forward... > >> > > >> > Does my proposed patch not work for you? (the one which shifts the > >> > bootstream payload to block 4 in partition 1) > >> > >> I gave it a try today. > >> > >> And it works for mx23evk; I did not test it in mx28. > >> > >> So what is the plan? I did not check the NAND format yet to know if it > >> is the same between mx28 and mx23 but I do want the machines merged as > >> soon as possible so people can play with it and find bugs. > > > > The plan is to: > > 1) Figure out what's with MX23 -- did you place FSL supp. ticket already? > > I contacted someone internal which is trying to find it out. Please fill a support ticket. > > 2) If 1) fails, try my patch on mx28 (since mx23 ignores it anyway and we > > can't figure out why?) > > I'd prefer to go with 2 in meanwhile. Could you please prepare a patch for > it? Fabio, can you test on mx28 please? 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] mxs: mxsboot: Add support for SD card generation for i.MX23
On Sat, Jan 26, 2013 at 3:03 PM, Marek Vasut wrote: > Dear Otavio Salvador, > > Putting Stefano on Cc, why is he omitted? > >> On Fri, Jan 25, 2013 at 10:40 AM, Marek Vasut wrote: >> >> On Thu, Jan 24, 2013 at 4:31 PM, Otavio Salvador >> >> >> >> wrote: >> >> > I prefer to have this as is and share documentation with mx28. The >> >> > NAND ought to be done providing same interface so one doc for it all. >> >> > I think change it in next version is wrong and confuse users. >> >> >> >> Ping? >> >> >> >> We won't be able to get rid of mxsboot for NAND use-case so I'd prefer >> >> to have it for SD as well. For me it does not matter much as I use OE >> >> and it automates it all; but for ordinary user it is important to it >> >> to be consistent so all 'mxs' SoC would work same way from user point >> >> of view. >> >> >> >> If we find a better way of doing things in future we can base on this >> >> and improve it later but please let's get it in and move forward... >> > >> > Does my proposed patch not work for you? (the one which shifts the >> > bootstream payload to block 4 in partition 1) >> >> I gave it a try today. >> >> And it works for mx23evk; I did not test it in mx28. >> >> So what is the plan? I did not check the NAND format yet to know if it >> is the same between mx28 and mx23 but I do want the machines merged as >> soon as possible so people can play with it and find bugs. > > The plan is to: > 1) Figure out what's with MX23 -- did you place FSL supp. ticket already? I contacted someone internal which is trying to find it out. > 2) If 1) fails, try my patch on mx28 (since mx23 ignores it anyway and we > can't > figure out why?) I'd prefer to go with 2 in meanwhile. Could you please prepare a patch for it? -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1 v3] console: USB: KBD: Fix incorrect autoboot timeout
Dear Wolfgang Denk, > Dear Marek Vasut, > > In message <201301260417.54768.ma...@denx.de> you wrote: > > > Autoboot timeout defined by CONFIG_BOOTDELAY will not be accurate if > > > CONFIG_USB_KEYBOARD and CONFIG_SYS_USB_EVENT_POLL are defined in > > > configuration file and when tstc() function for checking key pressed > > > takes longer time than 10 ms (e.g., 50 ms) to finish. > > > > > > Signed-off-by: Jim Lin > > > > Applied to u-boot-usb > > This is common code, and essentially unrelated to USB. It should go > through Tom, not through the USB repo. Either way is fine by me. Maybe the usb: tag should be removed then too. 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] mxs: mxsboot: Add support for SD card generation for i.MX23
Dear Otavio Salvador, Putting Stefano on Cc, why is he omitted? > On Fri, Jan 25, 2013 at 10:40 AM, Marek Vasut wrote: > >> On Thu, Jan 24, 2013 at 4:31 PM, Otavio Salvador > >> > >> wrote: > >> > I prefer to have this as is and share documentation with mx28. The > >> > NAND ought to be done providing same interface so one doc for it all. > >> > I think change it in next version is wrong and confuse users. > >> > >> Ping? > >> > >> We won't be able to get rid of mxsboot for NAND use-case so I'd prefer > >> to have it for SD as well. For me it does not matter much as I use OE > >> and it automates it all; but for ordinary user it is important to it > >> to be consistent so all 'mxs' SoC would work same way from user point > >> of view. > >> > >> If we find a better way of doing things in future we can base on this > >> and improve it later but please let's get it in and move forward... > > > > Does my proposed patch not work for you? (the one which shifts the > > bootstream payload to block 4 in partition 1) > > I gave it a try today. > > And it works for mx23evk; I did not test it in mx28. > > So what is the plan? I did not check the NAND format yet to know if it > is the same between mx28 and mx23 but I do want the machines merged as > soon as possible so people can play with it and find bugs. The plan is to: 1) Figure out what's with MX23 -- did you place FSL supp. ticket already? 2) If 1) fails, try my patch on mx28 (since mx23 ignores it anyway and we can't figure out why?) 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 02/10] lcd, tegra: remove unused cursor functions
Hello Tom, On 01/25/2013 10:18 PM, Tom Warren wrote: Jeroen, How will this all go in? Do you expect Anatolij to take it in via the main repo (u-boot.git/master)? I am not sure I understand exactly what you mean, but yes there are some conflicts awaiting. 2 pending drivers and another lcd cleanup patch. And yes I think it is easier to rebase those then to rebase this and Wolfgang's patch (if that is what you're asking), since the variables are deleted step by step. So simply not adding them is easier then getting rid of them again. The other lcd cleanup is smaller. I don't know how much trouble the board config changes will cause. To not break the pending drivers a new version of http://patchwork.ozlabs.org/patch/212378/ is needed though, since it does not apply after this patch set. Since that patch contains 2 lines, that should be easy (or can be manually merged by Anatolij). But it is up to Anatolij, how this actually goes in and to which branch. Regards, Jeroen ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot build error [from v2013.01 onwards]
Hi Jagan, On Sat, 26 Jan 2013 18:34:56 +0530, Jagan Teki wrote: > Hi, > > I am getting below error while configuring any board in the u-boot. > > bash> make versatilepb_config > Makefile:597: *** missing `endif'. Stop. > > Host setup: > > Processor: x86_64 > OS: Red Hat Enterprise Linux Client release 5.6 > u-boot version: v2013.01 > > Request for any help. Can you indicate which target you are building, with which command line exactly, and which toolchain you are using? > Thanks, > Jagan. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] a couple questions about CONFIG_SYS_LONGHELP
Hi Robert, On Sat, 26 Jan 2013 07:37:45 -0500 (EST), "Robert P. J. Day" wrote: > On Sat, 26 Jan 2013, Albert ARIBAUD wrote: > > > Hi Robert, > > > > On Sat, 26 Jan 2013 07:11:18 -0500 (EST), "Robert P. J. Day" > > wrote: > > > > > On Sat, 26 Jan 2013, Albert ARIBAUD wrote: > > > > > > > Hi Robert, > > > > > > > > On Sat, 26 Jan 2013 06:38:51 -0500 (EST), "Robert P. J. Day" > > > > wrote: > > > > > > ... snip ... > > > > > > > > and second, i'm not sure how to read this out of cmd_pci.c: > > > > > > > > > > = start > > > > > > > > > > #ifdef CONFIG_SYS_LONGHELP > > > > > static char pci_help_text[] = > > > > > "[bus] [long]\n" > > > > > "- short or long list of PCI devices on bus 'bus'\n" > > > > > #ifdef CONFIG_CMD_PCI_ENUM > > > > > "pci enum\n" > > > > > "- re-enumerate PCI buses\n" > > > > > #endif > > > > > "pci header b.d.f\n" > > > > > "- show header of PCI device 'bus.device.function'\n" > > > > > "pci display[.b, .w, .l] b.d.f [address] [# of objects]\n" > > > > > "- display PCI configuration space (CFG)\n" > > > > > "pci next[.b, .w, .l] b.d.f address\n" > > > > > "- modify, read and keep CFG address\n" > > > > > "pci modify[.b, .w, .l] b.d.f address\n" > > > > > "- modify, auto increment CFG address\n" > > > > > "pci write[.b, .w, .l] b.d.f address value\n" > > > > > "- write to CFG address"; > > > > > #endif > > > > > > > > > > U_BOOT_CMD( > > > > > pci,5, 1, do_pci, > > > > > "list and access PCI Configuration Space", pci_help_text > > > > > ); > > > > > > > > > > = end > > > > > > > > > > note how, if CONFIG_SYS_LONGHELP is defined, the symbol > > > > > "pci_help_text" is created as the text, but its *usage* just below in > > > > > the U_BOOT_CMD macro is *outside* of that preprocessor check. how > > > > > would that work if CONFIG_SYS_LONGHELP is undefined? not at my dev > > > > > host right this minute so i can't test, but it just looks ... weird. > > > > > > > > Probably would not work. Submit a fix. :) > > > > > > there appears to be a number of common/cmd_*.c files that have that > > > structure: > > > > > > $ grep "ifdef.*CONFIG_SYS_LONGHELP" cmd*.c > > > cmd_bootm.c:#ifdef CONFIG_SYS_LONGHELP > > > cmd_bootm.c:#ifdef CONFIG_SYS_LONGHELP > > > cmd_fdt.c:#ifdef CONFIG_SYS_LONGHELP > > > cmd_help.c:#ifdef CONFIG_SYS_LONGHELP > > > cmd_i2c.c:#ifdef CONFIG_SYS_LONGHELP > > > cmd_mp.c:#ifdef CONFIG_SYS_LONGHELP > > > cmd_mtdparts.c:#ifdef CONFIG_SYS_LONGHELP > > > cmd_nand.c:#ifdef CONFIG_SYS_LONGHELP > > > cmd_nvedit.c:#ifdef CONFIG_SYS_LONGHELP > > > cmd_pci.c:#ifdef CONFIG_SYS_LONGHELP > > > cmd_source.c:#ifdef CONFIG_SYS_LONGHELP > > > cmd_ximg.c:#ifdef CONFIG_SYS_LONGHELP > > > $ > > > > > > so it's not just one file. > > > > The grep above just shows that there are files have conditionally > > compiled code for CONFIG_SYS_LONGHELP; however it does not show per > > se that these files wound not compile without it. > > i'm aware of that -- but i manually examined some of the files > above, and all of the ones i looked at had the same "issue" as > cmd_pci.c. the grep command was not meant as proof, i just used it as > a guide for which files i wanted to look at more closely, and i see > the same problem with all of them. so someone higher up the food > chain than me can decide if this is something worth addressing. Actually there is no such hierarchical decision process where decision to fix would come from some 'upper layer' -- which simply does not exist as such in U-Boot. Decision comes from whoever feels something has to be changed, and these persons just submit a patch or patch-set which embodies their change. At this point board maintainers or custodians, or plain readers on the list too, may comment the submission and request changes; and custodians and maintainers can NAK it if it is wrong or had dead code or does not match the overall design or some other technical reason ; but submitting in the first place requires no authorization. > rday Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Want to study U-Boot code
Dear Javier Martinez Canillas, In message you wrote: > > There is no documentation that can replace the source code itself, remember > that a good documentation shouldn't say how thinks are made (for that > you have the code) > but why things were made in a certain way and the design decisions behind > that. ...and at least the most important design rules are documented on the U-Boot web page... 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 average woman would rather have beauty than brains, because the average man can see better than he can think. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mxs: mxsboot: Add support for SD card generation for i.MX23
On Fri, Jan 25, 2013 at 10:40 AM, Marek Vasut wrote: >> On Thu, Jan 24, 2013 at 4:31 PM, Otavio Salvador >> wrote: >> > I prefer to have this as is and share documentation with mx28. The >> > NAND ought to be done providing same interface so one doc for it all. >> > I think change it in next version is wrong and confuse users. >> >> Ping? >> >> We won't be able to get rid of mxsboot for NAND use-case so I'd prefer >> to have it for SD as well. For me it does not matter much as I use OE >> and it automates it all; but for ordinary user it is important to it >> to be consistent so all 'mxs' SoC would work same way from user point >> of view. >> >> If we find a better way of doing things in future we can base on this >> and improve it later but please let's get it in and move forward... > > Does my proposed patch not work for you? (the one which shifts the bootstream > payload to block 4 in partition 1) I gave it a try today. And it works for mx23evk; I did not test it in mx28. So what is the plan? I did not check the NAND format yet to know if it is the same between mx28 and mx23 but I do want the machines merged as soon as possible so people can play with it and find bugs. -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] net: nfs: add dynamic wait period
2012/12/11 Matthias Brugger :
> This patch tackles the time out problem which leads to break the
> boot process, when loading file over nfs. The patch does two things.
>
> First of all, we just ignore messages that arrive with a rpc_id smaller
> then the client id. We just interpret this messages as answers to
> formaly timed out messages.
>
> Second, when a time out occurs we double the time to wait, so that we
> do not stress the server resending the last message.
Any comment on the patch?
>
> Signed-off-by: Matthias Brugger
> ---
> net/nfs.c | 73
> +++--
> 1 file changed, 52 insertions(+), 21 deletions(-)
>
> diff --git a/net/nfs.c b/net/nfs.c
> index 7f2393f..84aeda1 100644
> --- a/net/nfs.c
> +++ b/net/nfs.c
> @@ -37,10 +37,14 @@
> # define NFS_TIMEOUT CONFIG_NFS_TIMEOUT
> #endif
>
> +#define NFS_RPC_ERR1
> +#define NFS_RPC_DROP 124
> +
> static int fs_mounted;
> static unsigned long rpc_id;
> static int nfs_offset = -1;
> static int nfs_len;
> +static ulong nfs_timeout = NFS_TIMEOUT;
>
> static char dirfh[NFS_FHSIZE]; /* file handle of directory */
> static char filefh[NFS_FHSIZE]; /* file handle of kernel image */
> @@ -399,8 +403,10 @@ rpc_lookup_reply(int prog, uchar *pkt, unsigned len)
>
> debug("%s\n", __func__);
>
> - if (ntohl(rpc_pkt.u.reply.id) != rpc_id)
> - return -1;
> + if (ntohl(rpc_pkt.u.reply.id) > rpc_id)
> + return -NFS_RPC_ERR;
> + else if (ntohl(rpc_pkt.u.reply.id) < rpc_id)
> + return -NFS_RPC_DROP;
>
> if (rpc_pkt.u.reply.rstatus ||
> rpc_pkt.u.reply.verifier ||
> @@ -428,8 +434,10 @@ nfs_mount_reply(uchar *pkt, unsigned len)
>
> memcpy((unsigned char *)&rpc_pkt, pkt, len);
>
> - if (ntohl(rpc_pkt.u.reply.id) != rpc_id)
> - return -1;
> + if (ntohl(rpc_pkt.u.reply.id) > rpc_id)
> + return -NFS_RPC_ERR;
> + else if (ntohl(rpc_pkt.u.reply.id) < rpc_id)
> + return -NFS_RPC_DROP;
>
> if (rpc_pkt.u.reply.rstatus ||
> rpc_pkt.u.reply.verifier ||
> @@ -452,8 +460,10 @@ nfs_umountall_reply(uchar *pkt, unsigned len)
>
> memcpy((unsigned char *)&rpc_pkt, pkt, len);
>
> - if (ntohl(rpc_pkt.u.reply.id) != rpc_id)
> - return -1;
> + if (ntohl(rpc_pkt.u.reply.id) > rpc_id)
> + return -NFS_RPC_ERR;
> + else if (ntohl(rpc_pkt.u.reply.id) < rpc_id)
> + return -NFS_RPC_DROP;
>
> if (rpc_pkt.u.reply.rstatus ||
> rpc_pkt.u.reply.verifier ||
> @@ -475,8 +485,10 @@ nfs_lookup_reply(uchar *pkt, unsigned len)
>
> memcpy((unsigned char *)&rpc_pkt, pkt, len);
>
> - if (ntohl(rpc_pkt.u.reply.id) != rpc_id)
> - return -1;
> + if (ntohl(rpc_pkt.u.reply.id) > rpc_id)
> + return -NFS_RPC_ERR;
> + else if (ntohl(rpc_pkt.u.reply.id) < rpc_id)
> + return -NFS_RPC_DROP;
>
> if (rpc_pkt.u.reply.rstatus ||
> rpc_pkt.u.reply.verifier ||
> @@ -499,8 +511,10 @@ nfs_readlink_reply(uchar *pkt, unsigned len)
>
> memcpy((unsigned char *)&rpc_pkt, pkt, len);
>
> - if (ntohl(rpc_pkt.u.reply.id) != rpc_id)
> - return -1;
> + if (ntohl(rpc_pkt.u.reply.id) > rpc_id)
> + return -NFS_RPC_ERR;
> + else if (ntohl(rpc_pkt.u.reply.id) < rpc_id)
> + return -NFS_RPC_DROP;
>
> if (rpc_pkt.u.reply.rstatus ||
> rpc_pkt.u.reply.verifier ||
> @@ -534,8 +548,10 @@ nfs_read_reply(uchar *pkt, unsigned len)
>
> memcpy((uchar *)&rpc_pkt, pkt, sizeof(rpc_pkt.u.reply));
>
> - if (ntohl(rpc_pkt.u.reply.id) != rpc_id)
> - return -1;
> + if (ntohl(rpc_pkt.u.reply.id) > rpc_id)
> + return -NFS_RPC_ERR;
> + else if (ntohl(rpc_pkt.u.reply.id) < rpc_id)
> + return -NFS_RPC_DROP;
>
> if (rpc_pkt.u.reply.rstatus ||
> rpc_pkt.u.reply.verifier ||
> @@ -574,7 +590,7 @@ NfsTimeout(void)
> NetStartAgain();
> } else {
> puts("T ");
> - NetSetTimeout(NFS_TIMEOUT, NfsTimeout);
> + NetSetTimeout(nfs_timeout + NFS_TIMEOUT * NfsTimeoutCount,
> NfsTimeout);
> NfsSend();
> }
> }
> @@ -583,6 +599,7 @@ static void
> NfsHandler(uchar *pkt, unsigned dest, IPaddr_t sip, unsigned src, unsigned
> len)
> {
> int rlen;
> + int reply;
>
> debug("%s\n", __func__);
>
> @@ -591,19 +608,24 @@ NfsHandler(uchar *pkt, unsigned dest, IPaddr_t sip,
> unsigned src, unsigned len)
>
> switch (NfsState) {
> case STATE_PRCLOOKUP_PROG_MOUNT_REQ:
> - rpc_lookup_reply(PROG_MOUNT, pkt, len);
> + if (rpc_lookup_reply(PROG_MOUNT, pkt, len) == -NFS_RPC_DROP)
> + break;
> NfsState = STATE_PRCLOOKUP_PR
Re: [U-Boot] Want to study U-Boot code
On Sat, Jan 26, 2013 at 2:07 PM, Woody Wu wrote: > 在 2013-1-26 AM5:27，"Robert P. J. Day" 写道： >> >> On Fri, 25 Jan 2013, Wolfgang Denk wrote: >> >> > Dear Woody Wu, >> > >> > In message c5y...@mail.gmail.com> you wrote: >> > > >> > > I want to firstly get a picture to basically understand how u-boot >> > > work, especially on an ARM9 based board. I think not everyone who >> > > want to understand u-boot has to read the full code. Thank. >> > >> > This depends on your definition of "understanding". On a highlevel, >> > you might start with reaing and digesting the manual, eventually >> > trying out how U-Boot works on some (real or emulated) board. >> >> if i can jump in, a good way to start playing is to configure and >> build for the "sandbox" architecture so you can run it on your x86 >> system. for the benefit of a couple friends, i whipped together a >> wiki page for that here: >> >> http://www.crashcourse.ca/wiki/index.php/U-Boot_sandbox >> >> very simple but enough to get you started, and you can match up >> running the commands with the underlying code. >> >> rday > > Sandbox looks amazing! Thanks share me with this info. But i still > wondering that if u-boot doesnt have any book or document explaining how it > work and how it organized, how pepople can join its development? > Hello Woody, I recommend you to start with the README file since it gives you a high level overview of U-Boot and some very good specifics too. Since you are asking about U-Boot source code organization specifically, you can take a look at the "Directory Hierarchy" section of the README file. But as others stated before, you should first narrow your search to an area that interests you. I found that "scratching your own itch" is the best way to learn. There is no documentation that can replace the source code itself, remember that a good documentation shouldn't say how thinks are made (for that you have the code) but why things were made in a certain way and the design decisions behind that. Finally, if you think that the documentation is not enough, feel free to send patches to improve that :-) As Confusios said "I heard and I forget. I see and I remember. I do and I understand" Hope it helps, Javier ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] OMAP3: igep00x0: fix a build warning on IGEP boards
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/26/2013 07:18 AM, Javier Martinez Canillas wrote: > commit b689cd5 OMAP3: use a single board file for IGEP devices > > introduced the following build warning: > > igep00x0.h:168:24: warning: backslash-newline at end of file > [enabled by default] > > This patch fixes the issue. > > Signed-off-by: Javier Martinez Canillas > Applied to u-boot-ti/master, thanks! - -- Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRA91OAAoJENk4IS6UOR1WkK0QAIAiz5KHO1UQZVJXuTtsAulX XtOAfmlEIKeFvGuAe1MWgXF7dnzODK+kfjZiZV8KW28xTp43EPi5V9i4yQtwGY67 GiYg+kL4VGBbLFCy2/taCe4S8oK1GC4kARxPjM/K371JqXvoXkpJcsRUllvmNvKy a/CYNSWwRXc7Y2izHBHoc3/hVSiVYMVsqBZiklb5Sj/X+znxL+P8NE4Q6tS/erCa W1wN7wAXNhZlGcZWyqL9fxjT1ex3sTfred8nsGh71UfWV8SYvMz8dkdVXFmhTFH3 E9HyYy4RrDnszdhGO0Wv6sKzRUKyXJQyqUkFOfRAKm+KzyPNzgThEtl034RTwgY6 8IwD5k/A1/o2WmDIVGPtodNUWaI23RzynhU9yafRWigCbN9VMUNJnBu4cftceomX DQjwgAZy4UqCFrvL67HNgRTdBzozYFeeOj3WkZWIfVMMBAntaNIbffoSwPdtnyD7 BWDJuu/QCul1y6q3XQd1YvefdswykChW7Sfe9gXMS7c4PMcfBDexcubBzU4KQz8G YpXf0nFkDdkeeZ37NfPSZl4d+ebFYvmyFL16S0KHcwY/gjA9iu1XEHbUOaPMv4Gs 18hc1uq72LbjELM+lHzbbt/92G9YqxyBTLAAiOCNUSYQ0LSoVB5fZXFsZOoK+tTN PaXiZTi0OlS31TOxXvAV =ZUp2 -END PGP SIGNATURE- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/5] lcd: add option for board specific splash screen preparation
Hello Igor,
On 01/25/2013 07:45 AM, Igor Grinberg wrote:
On 01/25/13 00:34, Jeroen Hofstee wrote:
Hello Igor,
On 01/24/2013 09:35 AM, Igor Grinberg wrote:
On 01/24/13 00:13, Jeroen Hofstee wrote:
Hello Nikita,
On 01/23/2013 09:31 AM, Nikita Kiryanov wrote:
On 01/21/2013 09:14 PM, Jeroen Hofstee wrote:
mmm, I am not so sure I agree that loading a bitmap in lcd_enable is
a _problem_, while loading it in show logo and requiring a CONFIG_* is
_natural_.
Well, it is a problem. If we don't respect the abstractions we create
then things like function names become meaningless. A function called
"lcd_enable" should do just that- enable lcd. Not load stuff from
storage to memory or manipulate BMPs.
my point is that lcd_clear will e.g. call lcd_logo. Although I haven't tested
it,
it seems you're make a side effect of a function only called once a side effect
of another function (which could be called multiple times). So you make things
even worse (loading an bitmap while the function is just named to display it).
So what's your point? Do you think we should add a splash screen specific
callback inside the board.c U-Boot boot flow?
no.
Please, be more specific, as both approaches are not suitable according
to what was said above...
lets see, drv_lcd_init calls lcd_init. which does
lcd_ctrl_init(lcdbase);
lcd_is_enabled = 1;
lcd_clear();
lcd_enable();
After this patch, lcd_clear calls lcd_logo which calls
board_splash_screen_prepare in its turn.
That said, lcd_clear() calls lcd_logo()...
This is the real source of confusion here - the side effect,
and not the fact that lcd_logo() calls the board_splash_screen_prepare()...
Being that a problem not directly related to Nikita's patch set, I don't
think we should delay it any further.
In my mind this
still leaves allot of side effects. If you want to prepare
for displaying and not have it as a side effect of a function
which is named to do something else, it should be in
between lcd_ctrl_init and lcd_clear in my mind.
I think not, lcd_logo() fits perfectly for loading the splash screen.
The fact that lcd_logo() is called from lcd_clear(), IMO,
would be the one that should be dealt with if you want to remove the
confusion ("the side effect"). But that is not related to Nikita's
patch set.
Given that I now know that lcd_enable is not an alternative to this
patch, but adding a callback is the only method to load a bitmap
and have it shown, I understand now that this patch is not just a
formal / cleanup change, but adds an actually missing feature.
So I am fine with having it inside lcd_logo.
btw, I think, loading the image in lcd_enable() won't even work
since lcd_enable is actually before lcd_clear. Scanning some
boards which load in lcd_enable, they seem to call bmp_display
manually. So that makes this patch no longer optional, but is
actually required and is an improvement
Ok. So we agree that this can't be done in lcd_enable().
yes.
I'd like to hear Anatolij's opinion on this.
yes, me too. I like the __weak far more than requiring a CONFIG_to
enable a callback. I cannot think of a reason why these __weak
functions cannot be documented. So that's up to Anatolij.
Usually, I also like the __weak approach, but this time the intention was
to document the feature and hopefully stop the lcd_*() API abuse.
Regards,
Jeroen
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1 v3] console: USB: KBD: Fix incorrect autoboot timeout
Dear Marek Vasut, In message <201301260417.54768.ma...@denx.de> you wrote: > > > Autoboot timeout defined by CONFIG_BOOTDELAY will not be accurate if > > CONFIG_USB_KEYBOARD and CONFIG_SYS_USB_EVENT_POLL are defined in > > configuration file and when tstc() function for checking key pressed > > takes longer time than 10 ms (e.g., 50 ms) to finish. > > > > Signed-off-by: Jim Lin > > Applied to u-boot-usb This is common code, and essentially unrelated to USB. It should go through Tom, not through the USB repo. 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 Alan Turing thought about criteria to settle the question of whether machines can think, a question of which we now know that it is about as relevant as the question of whether submarines can swim. -- Edsger Dijkstra ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Want to study U-Boot code
在 2013-1-26 AM5:27，"Robert P. J. Day" 写道： > > On Fri, 25 Jan 2013, Wolfgang Denk wrote: > > > Dear Woody Wu, > > > > In message you wrote: > > > > > > I want to firstly get a picture to basically understand how u-boot > > > work, especially on an ARM9 based board. I think not everyone who > > > want to understand u-boot has to read the full code. Thank. > > > > This depends on your definition of "understanding". On a highlevel, > > you might start with reaing and digesting the manual, eventually > > trying out how U-Boot works on some (real or emulated) board. > > if i can jump in, a good way to start playing is to configure and > build for the "sandbox" architecture so you can run it on your x86 > system. for the benefit of a couple friends, i whipped together a > wiki page for that here: > > http://www.crashcourse.ca/wiki/index.php/U-Boot_sandbox > > very simple but enough to get you started, and you can match up > running the commands with the underlying code. > > rday Sandbox looks amazing! Thanks share me with this info. But i still wondering that if u-boot doesnt have any book or document explaining how it work and how it organized, how pepople can join its development? > > -- > > > Robert P. J. Day Ottawa, Ontario, CANADA > http://crashcourse.ca > > Twitter: http://twitter.com/rpjday > LinkedIn: http://ca.linkedin.com/in/rpjday > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] u-boot build error [from v2013.01 onwards]
Hi, I am getting below error while configuring any board in the u-boot. bash> make versatilepb_config Makefile:597: *** missing `endif'. Stop. Host setup: Processor: x86_64 OS: Red Hat Enterprise Linux Client release 5.6 u-boot version: v2013.01 Request for any help. Thanks, Jagan. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v6 2/2] board: add support for amcore board
Add support for Sysam AMCORE mcf5307 (coldfire) based board.
Signed-off-by: Angelo Dureghello
Cc: Jason Jin
---
Changes for v2:
- None
Changes for v3:
- Fix code format issues
Changes for v4:
- Add MAINTAINERS file entry
- Remove all unnecessary blank lines
- Add get_ram_size in sdram init
- Reuse already existing sdram test routine
- Remove custom flash.c, used std mtd/CFI driver
Changes for v5:
- Fix MAINTAINERS bad sorted entry
- Fix incorrect indentation
- Remove #undef where not needed
- Fix CONFIG_SYS_SDRAM_SIZE to be in bytes
Changes for v6:
- Remove still some #undef not needed in amcore.h
- Remove custom sdram test routine
---
MAINTAINERS|4 +
board/sysam/amcore/Makefile| 43 ++
board/sysam/amcore/amcore.c| 123
board/sysam/amcore/config.mk | 23 +++
board/sysam/amcore/u-boot.lds | 101 ++
boards.cfg |1 +
include/configs/amcore.h | 206 +++
7 files changed, 501 insertions(+), 0 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 28c052d..f3a6d39 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -149,6 +149,10 @@ Wolfgang Denk
PCIPPC2 MPC750
PCIPPC6 MPC750
+Angelo Dureghello
+
+amcore mcf5307
+
Phil Edworthy
rsk7264 SH7264
diff --git a/board/sysam/amcore/Makefile b/board/sysam/amcore/Makefile
new file mode 100644
index 000..1fd25a8
--- /dev/null
+++ b/board/sysam/amcore/Makefile
@@ -0,0 +1,43 @@
+#
+# Copyright (c) 2011 Angelo Dureghello
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+# MA 02111-1307 USA
+#
+
+include $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(BOARD).o
+
+COBJS = $(BOARD).o
+
+SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)
+OBJS := $(addprefix $(obj),$(COBJS))
+SOBJS := $(addprefix $(obj),$(SOBJS))
+
+$(LIB):$(obj).depend $(OBJS)
+ $(call cmd_link_o_target, $(OBJS))
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/board/sysam/amcore/amcore.c b/board/sysam/amcore/amcore.c
new file mode 100644
index 000..a665570
--- /dev/null
+++ b/board/sysam/amcore/amcore.c
@@ -0,0 +1,123 @@
+/*
+ * Copyright (c) 2012 Angelo Dureghello
+ *
+ * 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
+ *
+ * Copy memory testdram() from sandburst/common/sb_common.c
+ */
+
+#include
+#include
+#include
+
+void init_lcd(void)
+{
+ /*
+* board can have a K0108 lcd connected on the parallel port,
+* wired as below:
+*
+* fc cpu P0 P1 P2 P3 P4 P5 P6 P7 P10 P11 P12 P13 P14
+* lcd D0 D1 D2 D3 D4 D5 D6 D7 CS1 CS2 RW DI E
+*
+* Starting up setting lines in high impedance
+*/
+ sim_t *sim = (sim_t *)(MMAP_SIM);
+
+ out_be16(&sim->par, 0x300);
+
+ gpio_t *gpio = (gpio_t *)(MMAP_GPIO);
+
+ out_be16(&gpio->paddr, 0xfcff);
+ out_be16(&gpio->padat, 0x0c00);
+}
+
+int checkboard(void)
+{
+ puts("Board: ");
+ puts("AMCORE v.001(alpha)\n");
+
+ init_lcd();
+
+ return 0;
+}
+
+/*
+ * in initdram we are here executing from flash
+ * case 1:
+ * is with no ACR/flash cache enabled
+ * nop = 40ns (scope measured)
+ */
+void fudelay(int usec)
+{
+ while (usec--)
+
Re: [U-Boot] a couple questions about CONFIG_SYS_LONGHELP
On Sat, 26 Jan 2013, Albert ARIBAUD wrote: > Hi Robert, > > On Sat, 26 Jan 2013 07:11:18 -0500 (EST), "Robert P. J. Day" > wrote: > > > On Sat, 26 Jan 2013, Albert ARIBAUD wrote: > > > > > Hi Robert, > > > > > > On Sat, 26 Jan 2013 06:38:51 -0500 (EST), "Robert P. J. Day" > > > wrote: > > > > ... snip ... > > > > > > and second, i'm not sure how to read this out of cmd_pci.c: > > > > > > > > = start > > > > > > > > #ifdef CONFIG_SYS_LONGHELP > > > > static char pci_help_text[] = > > > > "[bus] [long]\n" > > > > "- short or long list of PCI devices on bus 'bus'\n" > > > > #ifdef CONFIG_CMD_PCI_ENUM > > > > "pci enum\n" > > > > "- re-enumerate PCI buses\n" > > > > #endif > > > > "pci header b.d.f\n" > > > > "- show header of PCI device 'bus.device.function'\n" > > > > "pci display[.b, .w, .l] b.d.f [address] [# of objects]\n" > > > > "- display PCI configuration space (CFG)\n" > > > > "pci next[.b, .w, .l] b.d.f address\n" > > > > "- modify, read and keep CFG address\n" > > > > "pci modify[.b, .w, .l] b.d.f address\n" > > > > "- modify, auto increment CFG address\n" > > > > "pci write[.b, .w, .l] b.d.f address value\n" > > > > "- write to CFG address"; > > > > #endif > > > > > > > > U_BOOT_CMD( > > > > pci,5, 1, do_pci, > > > > "list and access PCI Configuration Space", pci_help_text > > > > ); > > > > > > > > = end > > > > > > > > note how, if CONFIG_SYS_LONGHELP is defined, the symbol > > > > "pci_help_text" is created as the text, but its *usage* just below in > > > > the U_BOOT_CMD macro is *outside* of that preprocessor check. how > > > > would that work if CONFIG_SYS_LONGHELP is undefined? not at my dev > > > > host right this minute so i can't test, but it just looks ... weird. > > > > > > Probably would not work. Submit a fix. :) > > > > there appears to be a number of common/cmd_*.c files that have that > > structure: > > > > $ grep "ifdef.*CONFIG_SYS_LONGHELP" cmd*.c > > cmd_bootm.c:#ifdef CONFIG_SYS_LONGHELP > > cmd_bootm.c:#ifdef CONFIG_SYS_LONGHELP > > cmd_fdt.c:#ifdef CONFIG_SYS_LONGHELP > > cmd_help.c:#ifdef CONFIG_SYS_LONGHELP > > cmd_i2c.c:#ifdef CONFIG_SYS_LONGHELP > > cmd_mp.c:#ifdef CONFIG_SYS_LONGHELP > > cmd_mtdparts.c:#ifdef CONFIG_SYS_LONGHELP > > cmd_nand.c:#ifdef CONFIG_SYS_LONGHELP > > cmd_nvedit.c:#ifdef CONFIG_SYS_LONGHELP > > cmd_pci.c:#ifdef CONFIG_SYS_LONGHELP > > cmd_source.c:#ifdef CONFIG_SYS_LONGHELP > > cmd_ximg.c:#ifdef CONFIG_SYS_LONGHELP > > $ > > > > so it's not just one file. > > The grep above just shows that there are files have conditionally > compiled code for CONFIG_SYS_LONGHELP; however it does not show per > se that these files wound not compile without it. i'm aware of that -- but i manually examined some of the files above, and all of the ones i looked at had the same "issue" as cmd_pci.c. the grep command was not meant as proof, i just used it as a guide for which files i wanted to look at more closely, and i see the same problem with all of them. so someone higher up the food chain than me can decide if this is something worth addressing. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] cmd_usb.c: Make usb help info consistent for "start".
On Sat, 26 Jan 2013, Robert P. J. Day wrote: > > Make USB help info for "start" subcommand consistent with other USB > subcommands. ACK, never mind, i just remembered that the first character string of the long help automatically gets the command name prepended. apologies. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] a couple questions about CONFIG_SYS_LONGHELP
Hi Robert, On Sat, 26 Jan 2013 07:11:18 -0500 (EST), "Robert P. J. Day" wrote: > On Sat, 26 Jan 2013, Albert ARIBAUD wrote: > > > Hi Robert, > > > > On Sat, 26 Jan 2013 06:38:51 -0500 (EST), "Robert P. J. Day" > > wrote: > > ... snip ... > > > > and second, i'm not sure how to read this out of cmd_pci.c: > > > > > > = start > > > > > > #ifdef CONFIG_SYS_LONGHELP > > > static char pci_help_text[] = > > > "[bus] [long]\n" > > > "- short or long list of PCI devices on bus 'bus'\n" > > > #ifdef CONFIG_CMD_PCI_ENUM > > > "pci enum\n" > > > "- re-enumerate PCI buses\n" > > > #endif > > > "pci header b.d.f\n" > > > "- show header of PCI device 'bus.device.function'\n" > > > "pci display[.b, .w, .l] b.d.f [address] [# of objects]\n" > > > "- display PCI configuration space (CFG)\n" > > > "pci next[.b, .w, .l] b.d.f address\n" > > > "- modify, read and keep CFG address\n" > > > "pci modify[.b, .w, .l] b.d.f address\n" > > > "- modify, auto increment CFG address\n" > > > "pci write[.b, .w, .l] b.d.f address value\n" > > > "- write to CFG address"; > > > #endif > > > > > > U_BOOT_CMD( > > > pci,5, 1, do_pci, > > > "list and access PCI Configuration Space", pci_help_text > > > ); > > > > > > = end > > > > > > note how, if CONFIG_SYS_LONGHELP is defined, the symbol > > > "pci_help_text" is created as the text, but its *usage* just below in > > > the U_BOOT_CMD macro is *outside* of that preprocessor check. how > > > would that work if CONFIG_SYS_LONGHELP is undefined? not at my dev > > > host right this minute so i can't test, but it just looks ... weird. > > > > Probably would not work. Submit a fix. :) > > there appears to be a number of common/cmd_*.c files that have that > structure: > > $ grep "ifdef.*CONFIG_SYS_LONGHELP" cmd*.c > cmd_bootm.c:#ifdef CONFIG_SYS_LONGHELP > cmd_bootm.c:#ifdef CONFIG_SYS_LONGHELP > cmd_fdt.c:#ifdef CONFIG_SYS_LONGHELP > cmd_help.c:#ifdef CONFIG_SYS_LONGHELP > cmd_i2c.c:#ifdef CONFIG_SYS_LONGHELP > cmd_mp.c:#ifdef CONFIG_SYS_LONGHELP > cmd_mtdparts.c:#ifdef CONFIG_SYS_LONGHELP > cmd_nand.c:#ifdef CONFIG_SYS_LONGHELP > cmd_nvedit.c:#ifdef CONFIG_SYS_LONGHELP > cmd_pci.c:#ifdef CONFIG_SYS_LONGHELP > cmd_source.c:#ifdef CONFIG_SYS_LONGHELP > cmd_ximg.c:#ifdef CONFIG_SYS_LONGHELP > $ > > so it's not just one file. The grep above just shows that there are files have conditionally compiled code for CONFIG_SYS_LONGHELP; however it does not show per se that these files wound not compile without it. Even assuming some of these files would not build without CONFIG_SYS_LONGHELP (cmd_pci.c is already proven not to), at least for ARM (an architecture for which I frequently build all targets) no target fails with an undefined variable, which implies that no target uses any of those files without defining CONFIG_SYS_LONGHELP. My conclusion is: if you need to build one or more targets without CONFIG_SYS_LONGHELP and it fails in some cmd_*.c file, then submit a patch that fixes the cmd_*.c files and undefines CONFIG_SYS_LONGHELP in the include/configs/*.h header files for those targets. > rday Amicalement, -- Albert. ___ 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 Sat, Jan 26, 2013 at 11:55 AM, Albert ARIBAUD
wrote:
> Hi Tom,
>
> On Fri, 25 Jan 2013 17:13:43 -0500, Tom Rini wrote:
>
>> Hello,
>>
>> The following changes since commit 7cb70a34b976e68f6348ea0718780e8f38901482:
>>
>> fdt: fix dts preprocessor options (2013-01-17 09:07:59 -0700)
>>
>> are available in the git repository at:
>>
>> git://git.denx.de/u-boot-ti.git master
>>
>> for you to fetch changes up to e25a6b504bb0c6e7a3a20cc0d2afacb6d88d29b1:
>>
>> AM335X: Set fdt_high for AM335X devices to enable booting with Device Tree
>> (2013-01-25 17:10:43 -0500)
>>
>>
>> Javier Martinez Canillas (3):
>> OMAP3: use a single board file for IGEP devices
>> OMAP3: igep00x0: add boot status GPIO LED
>> omap4: allow the use of a plain text env file instead boot scripts
>>
>> Jeff Lance (1):
>> Add DDR3 support for AM335x-EVM (Version 1.5A)
>>
>> Lars Poeschel (3):
>> am33xx: add a pulldown macro to pinmux config
>> pcm051: Add support for Phytec phyCORE-AM335x
>> am335x: display msg when reading MAC from efuse
>>
>> hvaib...@ti.com (1):
>> AM335X: Set fdt_high for AM335X devices to enable booting with Device
>> Tree
>>
>> MAINTAINERS|3 +
>> arch/arm/include/asm/arch-am33xx/ddr_defs.h| 34 +++
>> arch/arm/include/asm/arch-am33xx/mux.h |3 +-
>> board/isee/igep0020/igep0020.h | 151 --
>> board/isee/igep0030/Makefile | 43 ---
>> board/isee/igep0030/igep0030.c | 117
>> board/isee/{igep0020 => igep00x0}/Makefile |2 +-
>> .../{igep0020/igep0020.c => igep00x0/igep00x0.c} | 51 +++-
>> .../{igep0030/igep0030.h => igep00x0/igep00x0.h} | 35 ++-
>> board/phytec/pcm051/Makefile | 46 +++
>> board/phytec/pcm051/board.c| 266 +
>> board/phytec/pcm051/board.h| 33 +++
>> board/phytec/pcm051/mux.c | 133 +
>> board/ti/am335x/board.c| 43 ++-
>> boards.cfg |9 +-
>> include/configs/am335x_evm.h |1 +
>> include/configs/igep00x0.h |5 +
>> include/configs/omap4_common.h | 17 +-
>> include/configs/pcm051.h | 301
>>
>> 19 files changed, 951 insertions(+), 342 deletions(-)
>> delete mode 100644 board/isee/igep0020/igep0020.h
>> delete mode 100644 board/isee/igep0030/Makefile
>> delete mode 100644 board/isee/igep0030/igep0030.c
>> rename board/isee/{igep0020 => igep00x0}/Makefile (98%)
>> rename board/isee/{igep0020/igep0020.c => igep00x0/igep00x0.c} (86%)
>> rename board/isee/{igep0030/igep0030.h => igep00x0/igep00x0.h} (93%)
>> create mode 100644 board/phytec/pcm051/Makefile
>> create mode 100644 board/phytec/pcm051/board.c
>> create mode 100644 board/phytec/pcm051/board.h
>> create mode 100644 board/phytec/pcm051/mux.c
>> create mode 100644 include/configs/pcm051.h
>
> Tested with ELDK5.3, this PR introduces warnings in 5 boards.
>
> pcm051 (introduced by 372d1d9367265e2ca698f82197ad657567c405f9):
>
> mux.c:66:30: warning: 'gpio0_7_pin_mux' defined but not used
> [-Wunused-variable]
>
> igep0020, igem0020_nand, igep0030, igep0030_nand (introduced by
> b689cd584c17b985e15744c24710d5ad34a450b0):
>
> igep00x0.h:168:24: warning: backslash-newline at end of file [enabled
> by default]
>
> Commit authors CC:ed.
>
> Amicalement,
> --
> Albert.
Hi Albert,
I didn't see the warning until now, sorry for being so carelessly. In
the future I'll always check for warnings before sending patches.
I already sent a patch to fix this which btw is just this one-liner:
diff --git a/board/isee/igep00x0/igep00x0.h b/board/isee/igep00x0/igep00x0.h
index 3a84335..ea1e9ac 100644
--- a/board/isee/igep00x0/igep00x0.h
+++ b/board/isee/igep00x0/igep00x0.h
@@ -167,4 +167,4 @@ static void setup_net_chip(void);
#define MUX_IGEP0030() \
MUX_VAL(CP(UART1_TX), (IDIS | PTD | DIS | M0)) /* UART1_TX */\
- MUX_VAL(CP(UART1_RX), (IEN | PTD | DIS | M0)) /* UART1_RX */\
+ MUX_VAL(CP(UART1_RX), (IEN | PTD | DIS | M0)) /* UART1_RX */
Thanks a lot and sorry for the inconvenience.
Best regards,
Javier
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/1] OMAP3: igep00x0: fix a build warning on IGEP boards
commit b689cd5 OMAP3: use a single board file for IGEP devices introduced the following build warning: igep00x0.h:168:24: warning: backslash-newline at end of file [enabled by default] This patch fixes the issue. Signed-off-by: Javier Martinez Canillas --- board/isee/igep00x0/igep00x0.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/board/isee/igep00x0/igep00x0.h b/board/isee/igep00x0/igep00x0.h index 3a84335..ea1e9ac 100644 --- a/board/isee/igep00x0/igep00x0.h +++ b/board/isee/igep00x0/igep00x0.h @@ -167,4 +167,4 @@ static void setup_net_chip(void); #define MUX_IGEP0030() \ MUX_VAL(CP(UART1_TX), (IDIS | PTD | DIS | M0)) /* UART1_TX */\ - MUX_VAL(CP(UART1_RX), (IEN | PTD | DIS | M0)) /* UART1_RX */\ + MUX_VAL(CP(UART1_RX), (IEN | PTD | DIS | M0)) /* UART1_RX */ -- 1.7.7.6 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] a couple questions about CONFIG_SYS_LONGHELP
On Sat, 26 Jan 2013, Albert ARIBAUD wrote: > Hi Robert, > > On Sat, 26 Jan 2013 06:38:51 -0500 (EST), "Robert P. J. Day" > wrote: ... snip ... > > and second, i'm not sure how to read this out of cmd_pci.c: > > > > = start > > > > #ifdef CONFIG_SYS_LONGHELP > > static char pci_help_text[] = > > "[bus] [long]\n" > > "- short or long list of PCI devices on bus 'bus'\n" > > #ifdef CONFIG_CMD_PCI_ENUM > > "pci enum\n" > > "- re-enumerate PCI buses\n" > > #endif > > "pci header b.d.f\n" > > "- show header of PCI device 'bus.device.function'\n" > > "pci display[.b, .w, .l] b.d.f [address] [# of objects]\n" > > "- display PCI configuration space (CFG)\n" > > "pci next[.b, .w, .l] b.d.f address\n" > > "- modify, read and keep CFG address\n" > > "pci modify[.b, .w, .l] b.d.f address\n" > > "- modify, auto increment CFG address\n" > > "pci write[.b, .w, .l] b.d.f address value\n" > > "- write to CFG address"; > > #endif > > > > U_BOOT_CMD( > > pci,5, 1, do_pci, > > "list and access PCI Configuration Space", pci_help_text > > ); > > > > = end > > > > note how, if CONFIG_SYS_LONGHELP is defined, the symbol > > "pci_help_text" is created as the text, but its *usage* just below in > > the U_BOOT_CMD macro is *outside* of that preprocessor check. how > > would that work if CONFIG_SYS_LONGHELP is undefined? not at my dev > > host right this minute so i can't test, but it just looks ... weird. > > Probably would not work. Submit a fix. :) there appears to be a number of common/cmd_*.c files that have that structure: $ grep "ifdef.*CONFIG_SYS_LONGHELP" cmd*.c cmd_bootm.c:#ifdef CONFIG_SYS_LONGHELP cmd_bootm.c:#ifdef CONFIG_SYS_LONGHELP cmd_fdt.c:#ifdef CONFIG_SYS_LONGHELP cmd_help.c:#ifdef CONFIG_SYS_LONGHELP cmd_i2c.c:#ifdef CONFIG_SYS_LONGHELP cmd_mp.c:#ifdef CONFIG_SYS_LONGHELP cmd_mtdparts.c:#ifdef CONFIG_SYS_LONGHELP cmd_nand.c:#ifdef CONFIG_SYS_LONGHELP cmd_nvedit.c:#ifdef CONFIG_SYS_LONGHELP cmd_pci.c:#ifdef CONFIG_SYS_LONGHELP cmd_source.c:#ifdef CONFIG_SYS_LONGHELP cmd_ximg.c:#ifdef CONFIG_SYS_LONGHELP $ so it's not just one file. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] a couple questions about CONFIG_SYS_LONGHELP
Hi Robert, On Sat, 26 Jan 2013 06:38:51 -0500 (EST), "Robert P. J. Day" wrote: > > first, is there any need for so many header files to define the > macro CONFIG_SYS_LONGHELP individually? a quick count of how many > u-boot source files do just that: > > $ grep -r "define.*CONFIG_SYS_LONGHELP" * | wc -l > 479 > $ > > is it really necessary for almost 500 source files to each define that > macro? Yes, is is, because each target should decide individually if they want to embed the long help, which costs space and time, two valuable resources in embedded development. > and second, i'm not sure how to read this out of cmd_pci.c: > > = start > > #ifdef CONFIG_SYS_LONGHELP > static char pci_help_text[] = > "[bus] [long]\n" > "- short or long list of PCI devices on bus 'bus'\n" > #ifdef CONFIG_CMD_PCI_ENUM > "pci enum\n" > "- re-enumerate PCI buses\n" > #endif > "pci header b.d.f\n" > "- show header of PCI device 'bus.device.function'\n" > "pci display[.b, .w, .l] b.d.f [address] [# of objects]\n" > "- display PCI configuration space (CFG)\n" > "pci next[.b, .w, .l] b.d.f address\n" > "- modify, read and keep CFG address\n" > "pci modify[.b, .w, .l] b.d.f address\n" > "- modify, auto increment CFG address\n" > "pci write[.b, .w, .l] b.d.f address value\n" > "- write to CFG address"; > #endif > > U_BOOT_CMD( > pci,5, 1, do_pci, > "list and access PCI Configuration Space", pci_help_text > ); > > = end > > note how, if CONFIG_SYS_LONGHELP is defined, the symbol > "pci_help_text" is created as the text, but its *usage* just below in > the U_BOOT_CMD macro is *outside* of that preprocessor check. how > would that work if CONFIG_SYS_LONGHELP is undefined? not at my dev > host right this minute so i can't test, but it just looks ... weird. Probably would not work. Submit a fix. :) > rday Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] a couple questions about CONFIG_SYS_LONGHELP
first, is there any need for so many header files to define the macro CONFIG_SYS_LONGHELP individually? a quick count of how many u-boot source files do just that: $ grep -r "define.*CONFIG_SYS_LONGHELP" * | wc -l 479 $ is it really necessary for almost 500 source files to each define that macro? and second, i'm not sure how to read this out of cmd_pci.c: = start #ifdef CONFIG_SYS_LONGHELP static char pci_help_text[] = "[bus] [long]\n" "- short or long list of PCI devices on bus 'bus'\n" #ifdef CONFIG_CMD_PCI_ENUM "pci enum\n" "- re-enumerate PCI buses\n" #endif "pci header b.d.f\n" "- show header of PCI device 'bus.device.function'\n" "pci display[.b, .w, .l] b.d.f [address] [# of objects]\n" "- display PCI configuration space (CFG)\n" "pci next[.b, .w, .l] b.d.f address\n" "- modify, read and keep CFG address\n" "pci modify[.b, .w, .l] b.d.f address\n" "- modify, auto increment CFG address\n" "pci write[.b, .w, .l] b.d.f address value\n" "- write to CFG address"; #endif U_BOOT_CMD( pci,5, 1, do_pci, "list and access PCI Configuration Space", pci_help_text ); = end note how, if CONFIG_SYS_LONGHELP is defined, the symbol "pci_help_text" is created as the text, but its *usage* just below in the U_BOOT_CMD macro is *outside* of that preprocessor check. how would that work if CONFIG_SYS_LONGHELP is undefined? not at my dev host right this minute so i can't test, but it just looks ... weird. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] cmd_usb.c: Make usb help info consistent for "start".
Make USB help info for "start" subcommand consistent with other USB subcommands. Signed-off-by: Robert P. J. Day --- unless there's something different about the "start" subcommand, this would seem to make sense for consistency. diff --git a/common/cmd_usb.c b/common/cmd_usb.c index dacdc2d..f04ee73 100644 --- a/common/cmd_usb.c +++ b/common/cmd_usb.c @@ -575,7 +575,7 @@ static int do_usb(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) U_BOOT_CMD( usb,5, 1, do_usb, "USB sub-system", - "start - start (scan) USB controller\n" + "usb start - start (scan) USB controller\n" "usb reset - reset (rescan) USB controller\n" "usb stop [f] - stop USB [f]=force stop\n" "usb tree - show USB device tree\n" @@ -601,7 +601,7 @@ U_BOOT_CMD( U_BOOT_CMD( usb,5, 1, do_usb, "USB sub-system", - "start - start (scan) USB controller\n" + "usb start - start (scan) USB controller\n" "usb reset - reset (rescan) USB controller\n" "usb tree - show USB device tree\n" "usb info [dev] - show available USB devices" rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tegra: fdt: add back missing host1x node
Hi Allen, On Fri, 25 Jan 2013 16:51:09 -0800, Allen Martin wrote: > Hi Albert, would it be possible for you to apply this directly to your > u-boot-arm repository? It fixes a regression introduced by my > previous patch: > > b7723f3 tegra: fdt: sort dts files > > So I wanted to make sure it gets applied before that previous patch > makes it to u-boot/master, and Tom's not ready to do another tegra > pull request yet. > > -Allen Actually, I did not take Tom's PR as it caused some warnings. Maybe your fix can get in the TI tree before a fixed PR is sent out? Amicalement, -- Albert. ___ 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
Hi Tom,
On Fri, 25 Jan 2013 17:13:43 -0500, Tom Rini wrote:
> Hello,
>
> The following changes since commit 7cb70a34b976e68f6348ea0718780e8f38901482:
>
> fdt: fix dts preprocessor options (2013-01-17 09:07:59 -0700)
>
> are available in the git repository at:
>
> git://git.denx.de/u-boot-ti.git master
>
> for you to fetch changes up to e25a6b504bb0c6e7a3a20cc0d2afacb6d88d29b1:
>
> AM335X: Set fdt_high for AM335X devices to enable booting with Device Tree
> (2013-01-25 17:10:43 -0500)
>
>
> Javier Martinez Canillas (3):
> OMAP3: use a single board file for IGEP devices
> OMAP3: igep00x0: add boot status GPIO LED
> omap4: allow the use of a plain text env file instead boot scripts
>
> Jeff Lance (1):
> Add DDR3 support for AM335x-EVM (Version 1.5A)
>
> Lars Poeschel (3):
> am33xx: add a pulldown macro to pinmux config
> pcm051: Add support for Phytec phyCORE-AM335x
> am335x: display msg when reading MAC from efuse
>
> hvaib...@ti.com (1):
> AM335X: Set fdt_high for AM335X devices to enable booting with Device
> Tree
>
> MAINTAINERS|3 +
> arch/arm/include/asm/arch-am33xx/ddr_defs.h| 34 +++
> arch/arm/include/asm/arch-am33xx/mux.h |3 +-
> board/isee/igep0020/igep0020.h | 151 --
> board/isee/igep0030/Makefile | 43 ---
> board/isee/igep0030/igep0030.c | 117
> board/isee/{igep0020 => igep00x0}/Makefile |2 +-
> .../{igep0020/igep0020.c => igep00x0/igep00x0.c} | 51 +++-
> .../{igep0030/igep0030.h => igep00x0/igep00x0.h} | 35 ++-
> board/phytec/pcm051/Makefile | 46 +++
> board/phytec/pcm051/board.c| 266 +
> board/phytec/pcm051/board.h| 33 +++
> board/phytec/pcm051/mux.c | 133 +
> board/ti/am335x/board.c| 43 ++-
> boards.cfg |9 +-
> include/configs/am335x_evm.h |1 +
> include/configs/igep00x0.h |5 +
> include/configs/omap4_common.h | 17 +-
> include/configs/pcm051.h | 301
>
> 19 files changed, 951 insertions(+), 342 deletions(-)
> delete mode 100644 board/isee/igep0020/igep0020.h
> delete mode 100644 board/isee/igep0030/Makefile
> delete mode 100644 board/isee/igep0030/igep0030.c
> rename board/isee/{igep0020 => igep00x0}/Makefile (98%)
> rename board/isee/{igep0020/igep0020.c => igep00x0/igep00x0.c} (86%)
> rename board/isee/{igep0030/igep0030.h => igep00x0/igep00x0.h} (93%)
> create mode 100644 board/phytec/pcm051/Makefile
> create mode 100644 board/phytec/pcm051/board.c
> create mode 100644 board/phytec/pcm051/board.h
> create mode 100644 board/phytec/pcm051/mux.c
> create mode 100644 include/configs/pcm051.h
Tested with ELDK5.3, this PR introduces warnings in 5 boards.
pcm051 (introduced by 372d1d9367265e2ca698f82197ad657567c405f9):
mux.c:66:30: warning: 'gpio0_7_pin_mux' defined but not used
[-Wunused-variable]
igep0020, igem0020_nand, igep0030, igep0030_nand (introduced by
b689cd584c17b985e15744c24710d5ad34a450b0):
igep00x0.h:168:24: warning: backslash-newline at end of file [enabled
by default]
Commit authors CC:ed.
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
