Re: [U-Boot] [PATCH 1/5] mx53loco: Allow booting a zImage kernel
Am 25/10/2012 04:15, schrieb Fabio Estevam: > Hi Robert, > > On Thu, Oct 25, 2012 at 12:07 AM, Robert Nelson > wrote: > >> Fabio, >> >> Any thoughts on also enabling "define CONFIG_SUPPORT_RAW_INITRD" at >> the same time, otherwise you'd still have to run mkimage on the other >> half "initrd.img-$(uname -r)" when using booting an initramfs with >> your main kernel image.. > > Sure, no problem. We can enable CONFIG_SUPPORT_RAW_INITRD as well. > > Stefano, > > Should I enable CONFIG_SUPPORT_RAW_INITRD as part of the same patch > series or on a separate one? Your decision, both are fine with me. Regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] nds32: Change macro from BOARD_LATE_INIT to CONFIG_BOARD_LATE_INIT
Hi Tom, 2012/10/17 Tom Rini > On Tue, Apr 17, 2012 at 04:41:14PM -, Nobuhiro Iwamatsu wrote: > > > With almost all the architecture and board BOARD_LATE_INIT does not use. > > CONFIG_BOARD_LATE_INIT is used instead. > > This changed CONFIG_BOARD_LATE_INIT from BOARD_LATE_INIT. > > > > Signed-off-by: Nobuhiro Iwamatsu > > CC: Macpaul Lin > > Modified to apply again, applied to u-boot/master, thanks! > > This was strange. I didn' found the original patch in my mailbox of macp...@andestech.com. I guess I'd better to ask IT to figure out the problem. Anyway. Thanks Tom and Nobuhiron. :) -- Best regards, Macpaul Lin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Multiple stdin/out without CONFIG_CONSOLE_MUX?
Hi Stephen, On 10/25/2012 01:05 AM, Stephen Warren wrote: > > While looking into a CONFIG_CONSOLE_MUX-related issue, I noticed the > following: > > include/configs/u8500_href.h:136: "stdin=serial,usbtty\0" > include/configs/u8500_href.h:135: "stdout=serial,usbtty\0" > include/configs/snowball.h:180: "stdout=serial,usbtty\0" > > Those all include multiple devices in the stdin/stdout definitions. > However, those config files don't set CONFIG_CONSOLE_MUX. I assume this > causes usbtty to be ignored, and only serial used? > > Or perhaps U-Boot even fails to parse the variable at all, since > CONFIG_SYS_CONSOLE_IS_IN_ENV isn't set on those boards? Actually, there > are a few more boards with that problem: > >> include/configs/km/keymile-common.h:258: "stdout=serial\0" >> \ >> include/configs/MVBC_P.h:146:"stdout=serial\0" >> \ >> include/configs/MVBLM7.h:460:"stdout=serial\0" >> \ >> include/configs/MVSMR.h:129: "stdout=serial\0" >> \ >> include/configs/sandbox.h:91: >> "stdout=serial\0" \ >> include/configs/snowball.h:180: "stdout=serial,usbtty\0" >> \ >> include/configs/u8500_href.h:135:"stdout=serial,usbtty\0" >> \ I actually didn't get the point whats the problem here, but you are right our boards have stdin,stdout,stderr defined in their environment. It seems to be unneeded here. Maybe it is caused because we used CONFIG_CONSOLE_MUX in the past but the relevant code was dropped at some point. So we can remove these variables from our boards completely. Thanks for pointing out. Regards Holger ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-coldfire/master
> > Applied to u-boot/master. > [Jason Jin-R64188] Hi, Tom, Thanks a lot. > Where can I find a toolchain that supports 54418 CPUs? I had picked up > an m68k-uclinux toolchain from the uclinux project but that has 4 false > negatives (mismatch against libgcc on a few boards) and it doesn't > support 54418 CPUs. Thanks! > [Jason Jin-R64188] Please use the toolchain same with 54451/54455 cpu. We do not have a place to download the toolchain itself. You can try to get the toolchain through the Freescale ColdFire BSP ISO. Please refer to http://www.freescale.com/webapp/sps/site/overview.jsp?code=CW_BSP_COLDFIRE to download '2011 ColdFire Linux Maintenance BSP Release' and get the toolchain in the BSP. Thanks. Best Regards, Jason ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/2]ColdFire: Fix build errors for ColdFire M54418TWR boards
The following 2 patches fix the build error for the M54418TWR board. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2]ColdFire: Update the lds file for M54418TWR board.
The M54418TWR lds file need to update since commit:
8b493a52367623f36e628e4ab2cf8ee082b655e0
common: Discard the __u_boot_cmd section
The command declaration now uses the new LG-array method to generate
list of commands. Thus the __u_boot_cmd section is now superseded and
redundant and therefore can be removed. Also, remove externed symbols
associated with this section from include/command.h .
Signed-off-by: Jason Jin
---
board/freescale/m54418twr/u-boot.lds |8 +---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/board/freescale/m54418twr/u-boot.lds
b/board/freescale/m54418twr/u-boot.lds
index f341449..36a4c26 100644
--- a/board/freescale/m54418twr/u-boot.lds
+++ b/board/freescale/m54418twr/u-boot.lds
@@ -66,9 +66,11 @@ SECTIONS
PROVIDE (edata = .);
. = .;
- __u_boot_cmd_start = .;
- .u_boot_cmd : { *(.u_boot_cmd) }
- __u_boot_cmd_end = .;
+
+ . = ALIGN(4);
+ .u_boot_list : {
+ #include
+ }
. = .;
__start___ex_table = .;
--
1.6.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2]ColdFire: Remove save env in NAND support for M54418TWR board.
This patch remove the env saving in NAND as so far the NAND driver is not ported to the M54418TWR platform. Signed-off-by: Jason Jin --- include/configs/M54418TWR.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/include/configs/M54418TWR.h b/include/configs/M54418TWR.h index 6c96111..3be2f8e 100644 --- a/include/configs/M54418TWR.h +++ b/include/configs/M54418TWR.h @@ -350,7 +350,7 @@ #endif #if defined(CONFIG_SYS_NAND_BOOT) #define CONFIG_SYS_NO_FLASH -#define CONFIG_ENV_IS_IN_NAND 1 +#define CONFIG_ENV_IS_NOWHERE #define CONFIG_ENV_OFFSET 0x8 #define CONFIG_ENV_SIZE0x2 #define CONFIG_ENV_SECT_SIZE 0x2 -- 1.6.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 07/15] x86: Add functions to access MSRs
Graeme,
Reusing code from the Linux kernel is generally a great idea. However for
simplicity I'd rather have 25 lines than 870 lines for reading MSRs. It
seems a lot of code in those files doesn't really apply for u-boot
Stefan
On Tue, Oct 23, 2012 at 9:34 PM, Graeme Russ wrote:
> Hi Simon,
>
> On Wed, Oct 24, 2012 at 3:04 PM, Simon Glass wrote:
> > From: Stefan Reinauer
> >
> > Provide basic functions to access these registers.
>
> I really should have got my funk into gear and posted patches I
> created (on a side project) a long time ago :(
>
> Anyways - I implemented the same, but I just stole the code from the
> Linux kernel (3.1 to be exact) - I've attached my patch below (may not
> apply cleanly now)
>
> Regards,
>
> Graeme
>
> >
> > Signed-off-by: Stefan Reinauer
> > Signed-off-by: Simon Glass
> > ---
> > arch/x86/include/asm/msr.h | 25 +
> > 1 files changed, 25 insertions(+), 0 deletions(-)
> > create mode 100644 arch/x86/include/asm/msr.h
> >
> > diff --git a/arch/x86/include/asm/msr.h b/arch/x86/include/asm/msr.h
> > new file mode 100644
> > index 000..0a681d1
> > --- /dev/null
> > +++ b/arch/x86/include/asm/msr.h
> > @@ -0,0 +1,25 @@
> > +#ifndef CPU_X86_ASM_MSR_H
> > +#define CPU_X86_ASM_MSR_H
> > +
> > +static inline uint64_t rdmsr(unsigned index)
> > +{
> > + uint64_t result;
> > +
> > + asm volatile (
> > + "rdmsr"
> > + : "=A" (result)
> > + : "c" (index)
> > + );
> > + return result;
> > +}
> > +
> > +static inline void wrmsr(unsigned index, uint64_t msr)
> > +{
> > + asm volatile (
> > + "wrmsr"
> > + : /* No outputs */
> > + : "c" (index), "A" (msr)
> > + );
> > +}
> > +
> > +#endif /* CPU_X86_ASM_MSR_H */
> > --
> > 1.7.7.3
> >
>
> Zee Patch ;)
>
> x86: Import MSR/MTRR code from Linux
>
> Imported from Linux 3.1 with a few modifications to suit U-Boot
> ---
> arch/x86/include/asm/msr-index.h | 447
> ++
> arch/x86/include/asm/msr.h | 216 ++
> arch/x86/include/asm/mtrr.h | 203 +
> 3 files changed, 866 insertions(+), 0 deletions(-)
> create mode 100644 arch/x86/include/asm/msr-index.h
> create mode 100644 arch/x86/include/asm/msr.h
> create mode 100644 arch/x86/include/asm/mtrr.h
>
> diff --git a/arch/x86/include/asm/msr-index.h
> b/arch/x86/include/asm/msr-index.h
> new file mode 100644
> index 000..2d4a20a
> --- /dev/null
> +++ b/arch/x86/include/asm/msr-index.h
> @@ -0,0 +1,447 @@
> +#ifndef _ASM_X86_MSR_INDEX_H
> +#define _ASM_X86_MSR_INDEX_H
> +
> +/* CPU model specific register (MSR) numbers */
> +
> +/* x86-64 specific MSRs */
> +#define MSR_EFER 0xc080 /* extended feature register */
> +#define MSR_STAR 0xc081 /* legacy mode SYSCALL target */
> +#define MSR_LSTAR 0xc082 /* long mode SYSCALL target */
> +#define MSR_CSTAR 0xc083 /* compat mode SYSCALL target */
> +#define MSR_SYSCALL_MASK 0xc084 /* EFLAGS mask for syscall */
> +#define MSR_FS_BASE0xc100 /* 64bit FS base */
> +#define MSR_GS_BASE0xc101 /* 64bit GS base */
> +#define MSR_KERNEL_GS_BASE 0xc102 /* SwapGS GS shadow */
> +#define MSR_TSC_AUX0xc103 /* Auxiliary TSC */
> +
> +/* EFER bits: */
> +#define _EFER_SCE 0 /* SYSCALL/SYSRET */
> +#define _EFER_LME 8 /* Long mode enable */
> +#define _EFER_LMA 10 /* Long mode active (read-only) */
> +#define _EFER_NX 11 /* No execute enable */
> +#define _EFER_SVME 12 /* Enable virtualization */
> +#define _EFER_LMSLE13 /* Long Mode Segment Limit Enable */
> +#define _EFER_FFXSR14 /* Enable Fast FXSAVE/FXRSTOR */
> +
> +#define EFER_SCE (1<<_EFER_SCE)
> +#define EFER_LME (1<<_EFER_LME)
> +#define EFER_LMA (1<<_EFER_LMA)
> +#define EFER_NX(1<<_EFER_NX)
> +#define EFER_SVME (1<<_EFER_SVME)
> +#define EFER_LMSLE (1<<_EFER_LMSLE)
> +#define EFER_FFXSR (1<<_EFER_FFXSR)
> +
> +/* Intel MSRs. Some also available on other CPUs */
> +#define MSR_IA32_PERFCTR0 0x00c1
> +#define MSR_IA32_PERFCTR1 0x00c2
> +#define MSR_FSB_FREQ 0x00cd
> +
> +#define MSR_NHM_SNB_PKG_CST_CFG_CTL0x00e2
> +#define NHM_C3_AUTO_DEMOTE (1UL << 25)
> +#define NHM_C1_AUTO_DEMOTE (1UL << 26)
> +#define ATM_LNC_C6_AUTO_DEMOTE (1UL << 25)
> +
> +#define MSR_MTRRcap0x00fe
> +#define MSR_IA32_BBL_CR_CTL0x0119
> +#define MSR_IA32_BBL_CR_CTL3 0x011e
> +
> +#define MSR_IA32_SYSENTER_CS 0x0174
> +#define MSR_IA32_SYSENTER_ESP 0x0175
> +#define MSR_IA32_SYSENTER_EI
Re: [U-Boot] [PATCH] mx53loco: Add support for SEIKO 4.3'' WVGA panel
Am 23/10/2012 19:36, schrieb Fabio Estevam:
> Hi Stefano,
>
> On Sat, Oct 20, 2012 at 12:03 PM, Stefano Babic wrote:
>
>> What about to use a u-boot environment to select the display ? Could be
>> a better solution for you ? You can then have a single u-boot image
>> managing both displays. I did in this way for the mt_ventoux board
>> (board/mt_ventoux/mt_ventoux.c), maybe can this help ?
>
> Sounds good. I tried this approach.
>
> However, when I try to manipulate the env var I am not able to boot:
>
> U-Boot 2012.10-09480-g6b08fc3-dirty (Oct 23 2012 - 15:24:03)
>
> Board: MX53 LOCO
> I2C: ready
> DRAM: 1 GiB
> ...
>
> These are my simple changes (just to show the issue I am facing):
>
> --- a/board/freescale/mx53loco/mx53loco.c
> +++ b/board/freescale/mx53loco/mx53loco.c
> @@ -471,6 +471,18 @@ void lcd_iomux(void)
> void lcd_enable(void)
> {
> int ret = ipuv3_fb_init(&claa_wvga, 0, IPU_PIX_FMT_RGB565);
> + char *e;
> +
> + e = getenv("panel");
> +
> + if (e != NULL) {
> + if (strcmp(e, "claa") == 0)
> + printf("Panel is claa\n");
> +
> + if (strcmp(e, "seiko") == 0)
> + printf("Panel is seiko\n");
> + }
> +
> if (ret)
> printf("LCD cannot be configured: %d\n", ret);
> }
>
>
> Any ideas?
Yes, I thins is due to the fact that size for the framebuffer is
allocated before relocation. This was also a reason for me to migrate to
CONFIG_VIDEO instead of CONFIG_LCD.
>From board_init_f in arch/arm/lib/board.c:
#ifdef CONFIG_LCD
/* reserve memory for LCD display (always full pages) */
addr = lcd_setmem (addr);
gd->fb_base = addr;
#endif /* CONFIG_LCD */
This makes difficult to reserve the correct amount of memory because at
this point we cannot evaluate the environment. With CONFIG_VIDEO, memory
is allocated with malloc(), and in any case after relocation.
Best regards,
Stefano
>
> Thanks,
>
> Fabio Estevam
>
--
=
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 4/6] mic: Add support for mc34704
Am 23/10/2012 18:34, schrieb Fabio Estevam:
> Add the register layout for the MC34704 PMIC from Freescale.
>
> Signed-off-by: Fabio Estevam
> ---
> Changes since v2:
> - Pass FSL_PMIC_I2C_LENGTH
>
> drivers/misc/pmic_fsl.c |2 ++
> include/mc34704.h | 49
> +++
> 2 files changed, 51 insertions(+)
> create mode 100644 include/mc34704.h
>
> diff --git a/drivers/misc/pmic_fsl.c b/drivers/misc/pmic_fsl.c
> index 9d80b55..c8d4c8d 100644
> --- a/drivers/misc/pmic_fsl.c
> +++ b/drivers/misc/pmic_fsl.c
> @@ -28,6 +28,8 @@
>
> #if defined(CONFIG_PMIC_FSL_MC13892)
> #define FSL_PMIC_I2C_LENGTH 3
> +#elif defined(CONFIG_PMIC_FSL_MC34704)
> +#define FSL_PMIC_I2C_LENGTH 1
> #endif
I think this can break boards with MX3 where the MC13783 is used, and
where MC13892 is not set.
At the moment, MC34704 is the one that requires a short lenght. Maybe it
is better to set 3 as default:
#if defined(CONFIG_PMIC_FSL_MC34704)
#define FSL_PMIC_I2C_LENGTH 1
#else
#define FSL_PMIC_I2C_LENGTH 3
#endif
>
> #if defined(CONFIG_PMIC_SPI)
> diff --git a/include/mc34704.h b/include/mc34704.h
> new file mode 100644
> index 000..6611d54
> --- /dev/null
> +++ b/include/mc34704.h
> @@ -0,0 +1,49 @@
> +/*
> + * (C) Copyright 2012 Freescale Semiconductor, Inc.
> + *
> + * 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.
> + *
> + */
> +
> +#ifndef __MC34704_H__
> +#define __MC34704_H__
> +
> +enum {
> + MC34704_RESERVED0_REG = 0, /* 0x00 */
> + MC34704_GENERAL1_REG, /* 0x01 */
> + MC34704_GENERAL2_REG, /* 0x02 */
> + MC34704_GENERAL3_REG, /* 0x03 */
> + MC34704_RESERVED4_REG, /* 0x04 */
> + MC34704_VGSET2_REG, /* 0x05 */
> + MC34704_REG2SET1_REG, /* 0x06 */
> + MC34704_REG2SET2_REG, /* 0x07 */
> + MC34704_REG3SET1_REG, /* 0x08 */
> + MC34704_REG3SET2_REG, /* 0x09 */
> + MC34704_REG4SET1_REG, /* 0x0a */
> + MC34704_REG4SET2_REG, /* 0x0b */
> + MC34704_REG5SET1_REG, /* 0x0c */
> + MC34704_REG5SET2_REG, /* 0x0d */
> + MC34704_REG5SET3_REG, /* 0x0e */
> + MC34704_RESERVEDF_REG, /* 0x0f */
> + MC34704_RESERVED10_REG, /* 0x10 */
> + MC34704_RESERVED11_REG, /* 0x11 */
> + MC34704_RESERVED12_REG, /* 0x12 */
> + MC34704_FSW2SET_REG,/* 0x13 */
> + MC34704_RESERVED14_REG, /* 0x14 */
> + MC34704_REG8SET1_REG, /* 0x15 */
> + MC34704_REG8SET2_REG, /* 0x16 */
> + MC34704_REG8SET3_REG, /* 0x17 */
> + MC34704_FAULTS_REG, /* 0x18 */
> + MC34704_I2CSET1,/* 0x19 */
> + MC34704_NUM_OF_REGS,
> +};
> +
> +/* GENERAL2 register fields */
> +#define ONOFFE (1 << 0)
> +#define ONOFFD (1 << 1)
> +#define ALLOFF (1 << 4)
> +
> +#endif /* __MC34704_H__ */
>
--
=
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 4/6] mic: Add support for mc34704
Hi Stefano, On Thu, Oct 25, 2012 at 8:35 AM, Stefano Babic wrote: > I think this can break boards with MX3 where the MC13783 is used, and > where MC13892 is not set. mc13783 can only communicate via spi, not i2c, so this patch does not break mx3 + mc13783 case. Regards, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3 1/1] mx31/mx35/mx51/mx53/mx6: add watchdog
Am 23/10/2012 03:19, schrieb Troy Kisky: > Use a common watchdog driver for all these cpus. > > Signed-off-by: Troy Kisky > > --- Hi Troy, > +++ b/doc/README.watchdog > @@ -0,0 +1,29 @@ > +Watchdog driver general info > + > +CONFIG_HW_WATCHDOG > + This enables hw_watchdog_reset to be called during various loops, > + including waiting for a character on a serial port. But it > + does not also call hw_watchdog_init. Boards which want this > + enabled must call this function in their board file. This split > + is useful because some rom's enable the watchdog when downloading > + new code, so it must be serviced, but the board would rather it > + was off. And, it cannot always be turned off once on. > + > +CONFIG_WATCHDOG_TIMEOUT_MSECS > + Can be used to change the timeout for i.mx31/35/5x/6x. > + If not given, will default to maximum timeout. This would > + be 128000 msec for i.mx31/35/5x/6x. > + > +CONFIG_AT91SAM9_WATCHDOG > + Available for AT91SAM9 to service the watchdog. > + > +CONFIG_FTWDT010_WATCHDOG > + Available for FTWDT010 to service the watchdog. > + > +CONFIG_FTWDT010_HW_TIMEOUT > + Can be used to change the timeout for FTWDT010. > + > +CONFIG_IMX_WATCHDOG > + Available for i.mx31/35/5x/6x to service the watchdog. This is not > + automatically set because some boards (vision2) still need to define > + their own hw_watchdog_reset routine. Thanks for documenting also not i.MX drivers. > diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile > index 5579bf2..18768b7 100644 > --- a/drivers/watchdog/Makefile > +++ b/drivers/watchdog/Makefile > @@ -27,6 +27,9 @@ LIB := $(obj)libwatchdog.o > > COBJS-$(CONFIG_AT91SAM9_WATCHDOG) += at91sam9_wdt.o > COBJS-$(CONFIG_FTWDT010_WATCHDOG) += ftwdt010_wdt.o > +ifneq (,$(filter $(SOC), mx31 mx35 mx5 mx6)) > +COBJS-y += imx_watchdog.o > +endif IMHO I like this solution, also if this driver is always compiled independently if CONFIG_IMX_WATCHDOG is set, so to link the reset() function. In any case, there is not a bigger footprint because you protect watchdog code with the switch. Here my: Acked-by: Stefano Babic I will just wait a bit for further comment before merging. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx53loco: Add support for SEIKO 4.3'' WVGA panel
Hi Stefano, On Thu, Oct 25, 2012 at 8:28 AM, Stefano Babic wrote: > Yes, I thins is due to the fact that size for the framebuffer is > allocated before relocation. This was also a reason for me to migrate to > CONFIG_VIDEO instead of CONFIG_LCD. mx53loco.h defines CONFIG_VIDEO, not CONFIG_LCD. I am suspecting alignment/gcc issues: with a gcc4.4 I can boot into a prompt, but after typing any command and then "enter" the board crashes and reboot. With gcc4.7, then board hangs after the total RAM is displayed. Regards, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx53loco: Add support for SEIKO 4.3'' WVGA panel
Dear Fabio Estevam, CCing Albert. > Hi Stefano, > > On Thu, Oct 25, 2012 at 8:28 AM, Stefano Babic wrote: > > Yes, I thins is due to the fact that size for the framebuffer is > > allocated before relocation. This was also a reason for me to migrate to > > CONFIG_VIDEO instead of CONFIG_LCD. > > mx53loco.h defines CONFIG_VIDEO, not CONFIG_LCD. > > I am suspecting alignment/gcc issues: with a gcc4.4 I can boot into a > prompt, but after typing any command and then "enter" the board > crashes and reboot. > > With gcc4.7, then board hangs after the total RAM is displayed. > > Regards, > > Fabio Estevam 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/5] mx53loco: Allow booting a zImage kernel
On Thu, Oct 25, 2012 at 5:00 AM, Stefano Babic wrote: >> Should I enable CONFIG_SUPPORT_RAW_INITRD as part of the same patch >> series or on a separate one? > > Your decision, both are fine with me. Ok, then I prefer to keep this series as is. I will send a separate one for adding CONFIG_SUPPORT_RAW_INITRD only for mx53loco as requested by Robert. Regards, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/5] mx53loco: Allow booting a zImage kernel
Am 25/10/2012 13:16, schrieb Fabio Estevam: > On Thu, Oct 25, 2012 at 5:00 AM, Stefano Babic wrote: > >>> Should I enable CONFIG_SUPPORT_RAW_INITRD as part of the same patch >>> series or on a separate one? >> >> Your decision, both are fine with me. > > Ok, then I prefer to keep this series as is. > > I will send a separate one for adding CONFIG_SUPPORT_RAW_INITRD only > for mx53loco as requested by Robert. Ok, fine. This series is then ready to be merged. Regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 4/6] mic: Add support for mc34704
Am 25/10/2012 12:55, schrieb Fabio Estevam: > Hi Stefano, > > On Thu, Oct 25, 2012 at 8:35 AM, Stefano Babic wrote: > >> I think this can break boards with MX3 where the MC13783 is used, and >> where MC13892 is not set. > > mc13783 can only communicate via spi, not i2c, so this patch does not > break mx3 + mc13783 case. Thanks, I have not checked it - I have considered the MC13873 more similar to the MC13892 as it is ;-). Then the patch is ok for me. Acked-by: Stefano Babic Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 1/4] am33xx: Enable UART{1,2,3,4,5} clocks
If configured to use UART{1,2,3,4,5} such as on the Beaglebone RS232
cape or the am335x_evm daughterboard, enable the required clocks for
the UART in use.
Signed-off-by: Andrew Bradford
---
Changes from v3:
No changes
Changes from v2:
No changes
Changes from v1:
Also enable UART3 clocks
arch/arm/cpu/armv7/am33xx/clock.c | 35 +++
1 file changed, 35 insertions(+)
diff --git a/arch/arm/cpu/armv7/am33xx/clock.c
b/arch/arm/cpu/armv7/am33xx/clock.c
index 2b19506..b34f969 100644
--- a/arch/arm/cpu/armv7/am33xx/clock.c
+++ b/arch/arm/cpu/armv7/am33xx/clock.c
@@ -114,6 +114,41 @@ static void enable_per_clocks(void)
while (readl(&cmwkup->wkup_uart0ctrl) != PRCM_MOD_EN)
;
+ /* UART1 */
+#ifdef CONFIG_SERIAL2
+ writel(PRCM_MOD_EN, &cmper->uart1clkctrl);
+ while (readl(&cmper->uart1clkctrl) != PRCM_MOD_EN)
+ ;
+#endif /* CONFIG_SERIAL2 */
+
+ /* UART2 */
+#ifdef CONFIG_SERIAL3
+ writel(PRCM_MOD_EN, &cmper->uart2clkctrl);
+ while (readl(&cmper->uart2clkctrl) != PRCM_MOD_EN)
+ ;
+#endif /* CONFIG_SERIAL3 */
+
+ /* UART3 */
+#ifdef CONFIG_SERIAL4
+ writel(PRCM_MOD_EN, &cmper->uart3clkctrl);
+ while (readl(&cmper->uart3clkctrl) != PRCM_MOD_EN)
+ ;
+#endif /* CONFIG_SERIAL4 */
+
+ /* UART4 */
+#ifdef CONFIG_SERIAL5
+ writel(PRCM_MOD_EN, &cmper->uart4clkctrl);
+ while (readl(&cmper->uart4clkctrl) != PRCM_MOD_EN)
+ ;
+#endif /* CONFIG_SERIAL5 */
+
+ /* UART5 */
+#ifdef CONFIG_SERIAL6
+ writel(PRCM_MOD_EN, &cmper->uart5clkctrl);
+ while (readl(&cmper->uart5clkctrl) != PRCM_MOD_EN)
+ ;
+#endif /* CONFIG_SERIAL6 */
+
/* MMC0*/
writel(PRCM_MOD_EN, &cmper->mmc0clkctrl);
while (readl(&cmper->mmc0clkctrl) != PRCM_MOD_EN)
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 0/4] am335x_evm: Enable UART{1,2,3,4,5}
To support serial ports other than UART0 on am335x based systems like
the Beaglebone with the RS232 cape and am335x_evm with daughterboard.
Changes from v3:
* Patch 4/4 simplified further.
Changes from v2:
* Patch 4/4 cleaned up to define CONS_INDEX and SERIALX in the
target options.
Changes from v1:
* Reduced from 6 patches to 4.
* Reworked on Marek Vasut's serial changes.
* Added UART3 for am335x_evm profile 5.
Andrew Bradford (4):
am33xx: Enable UART{1,2,3,4,5} clocks
am33xx: Enable UART{1,2,3,4,5} pin-mux
serial: ns16550: Enable COM5 and COM6
am335x_evm: Enable use of UART{1,2,3,4,5}
arch/arm/cpu/armv7/am33xx/board.c| 17
arch/arm/cpu/armv7/am33xx/clock.c| 35 +
arch/arm/include/asm/arch-am33xx/sys_proto.h |7 +++-
board/ti/am335x/mux.c| 54 ++
boards.cfg |7 +++-
drivers/serial/serial_ns16550.c | 36 +++--
include/configs/am335x_evm.h | 12 +++---
7 files changed, 158 insertions(+), 10 deletions(-)
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 3/4] serial: ns16550: Enable COM5 and COM6
Increase the possible number of ns16550 serial devices from 4 to 6.
Signed-off-by: Andrew Bradford
---
Changes from v3:
No changes
Changes from v2:
No changes
Changes from v1:
Consolidation of patches 3, 4, and 5 on top of Marek Vasut's
recent serial changes.
drivers/serial/serial_ns16550.c | 36 +---
1 file changed, 33 insertions(+), 3 deletions(-)
diff --git a/drivers/serial/serial_ns16550.c b/drivers/serial/serial_ns16550.c
index b5d1248..5fb3841 100644
--- a/drivers/serial/serial_ns16550.c
+++ b/drivers/serial/serial_ns16550.c
@@ -34,7 +34,7 @@
DECLARE_GLOBAL_DATA_PTR;
#if !defined(CONFIG_CONS_INDEX)
-#elif (CONFIG_CONS_INDEX < 1) || (CONFIG_CONS_INDEX > 4)
+#elif (CONFIG_CONS_INDEX < 1) || (CONFIG_CONS_INDEX > 6)
#error "Invalid console index value."
#endif
@@ -46,12 +46,16 @@ DECLARE_GLOBAL_DATA_PTR;
#error "Console port 3 defined but not configured."
#elif CONFIG_CONS_INDEX == 4 && !defined(CONFIG_SYS_NS16550_COM4)
#error "Console port 4 defined but not configured."
+#elif CONFIG_CONS_INDEX == 5 && !defined(CONFIG_SYS_NS16550_COM5)
+#error "Console port 5 defined but not configured."
+#elif CONFIG_CONS_INDEX == 6 && !defined(CONFIG_SYS_NS16550_COM6)
+#error "Console port 6 defined but not configured."
#endif
/* Note: The port number specified in the functions is 1 based.
* the array is 0 based.
*/
-static NS16550_t serial_ports[4] = {
+static NS16550_t serial_ports[6] = {
#ifdef CONFIG_SYS_NS16550_COM1
(NS16550_t)CONFIG_SYS_NS16550_COM1,
#else
@@ -68,7 +72,17 @@ static NS16550_t serial_ports[4] = {
NULL,
#endif
#ifdef CONFIG_SYS_NS16550_COM4
- (NS16550_t)CONFIG_SYS_NS16550_COM4
+ (NS16550_t)CONFIG_SYS_NS16550_COM4,
+#else
+ NULL,
+#endif
+#ifdef CONFIG_SYS_NS16550_COM5
+ (NS16550_t)CONFIG_SYS_NS16550_COM5,
+#else
+ NULL,
+#endif
+#ifdef CONFIG_SYS_NS16550_COM6
+ (NS16550_t)CONFIG_SYS_NS16550_COM6
#else
NULL
#endif
@@ -231,6 +245,12 @@ struct serial_device eserial3_device =
DECLARE_ESERIAL_FUNCTIONS(4);
struct serial_device eserial4_device =
INIT_ESERIAL_STRUCTURE(4, "eserial3");
+DECLARE_ESERIAL_FUNCTIONS(5);
+struct serial_device eserial5_device =
+ INIT_ESERIAL_STRUCTURE(5, "eserial4");
+DECLARE_ESERIAL_FUNCTIONS(6);
+struct serial_device eserial6_device =
+ INIT_ESERIAL_STRUCTURE(6, "eserial5");
__weak struct serial_device *default_serial_console(void)
{
@@ -242,6 +262,10 @@ __weak struct serial_device *default_serial_console(void)
return &eserial3_device;
#elif CONFIG_CONS_INDEX == 4
return &eserial4_device;
+#elif CONFIG_CONS_INDEX == 5
+ return &eserial5_device;
+#elif CONFIG_CONS_INDEX == 6
+ return &eserial6_device;
#else
#error "Bad CONFIG_CONS_INDEX."
#endif
@@ -261,4 +285,10 @@ void ns16550_serial_initialize(void)
#if defined(CONFIG_SYS_NS16550_COM4)
serial_register(&eserial4_device);
#endif
+#if defined(CONFIG_SYS_NS16550_COM5)
+ serial_register(&eserial5_device);
+#endif
+#if defined(CONFIG_SYS_NS16550_COM6)
+ serial_register(&eserial6_device);
+#endif
}
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 2/4] am33xx: Enable UART{1,2,3,4,5} pin-mux
If configured to use UART{1,2,3,4,5} such as on the Beaglebone RS232
cape or on the am335x_evm daughterboard, enable the proper pin-muxing.
Signed-off-by: Andrew Bradford
---
Changes from v3:
No changes
Changes from v2:
No changes
Changes from v1:
Also enable UART3 pin mux
arch/arm/cpu/armv7/am33xx/board.c| 17
arch/arm/include/asm/arch-am33xx/sys_proto.h |7 +++-
board/ti/am335x/mux.c| 54 ++
3 files changed, 77 insertions(+), 1 deletion(-)
diff --git a/arch/arm/cpu/armv7/am33xx/board.c
b/arch/arm/cpu/armv7/am33xx/board.c
index 978b184..e324265 100644
--- a/arch/arm/cpu/armv7/am33xx/board.c
+++ b/arch/arm/cpu/armv7/am33xx/board.c
@@ -152,7 +152,24 @@ void s_init(void)
/* UART softreset */
u32 regVal;
+#ifdef CONFIG_SERIAL1
enable_uart0_pin_mux();
+#endif /* CONFIG_SERIAL1 */
+#ifdef CONFIG_SERIAL2
+ enable_uart1_pin_mux();
+#endif /* CONFIG_SERIAL2 */
+#ifdef CONFIG_SERIAL3
+ enable_uart2_pin_mux();
+#endif /* CONFIG_SERIAL3 */
+#ifdef CONFIG_SERIAL4
+ enable_uart3_pin_mux();
+#endif /* CONFIG_SERIAL4 */
+#ifdef CONFIG_SERIAL5
+ enable_uart4_pin_mux();
+#endif /* CONFIG_SERIAL5 */
+#ifdef CONFIG_SERIAL6
+ enable_uart5_pin_mux();
+#endif /* CONFIG_SERIAL6 */
regVal = readl(&uart_base->uartsyscfg);
regVal |= UART_RESET;
diff --git a/arch/arm/include/asm/arch-am33xx/sys_proto.h
b/arch/arm/include/asm/arch-am33xx/sys_proto.h
index 819ea65..3ef1ff2 100644
--- a/arch/arm/include/asm/arch-am33xx/sys_proto.h
+++ b/arch/arm/include/asm/arch-am33xx/sys_proto.h
@@ -53,11 +53,16 @@ void ddr_pll_config(unsigned int ddrpll_M);
/*
* We have three pin mux functions that must exist. We must be able to enable
- * uart0, for initial output and i2c0 to read the main EEPROM. We then have a
+ * a uart for initial output and i2c0 to read the main EEPROM. We then have a
* main pinmux function that can be overridden to enable all other pinmux that
* is required on the board.
*/
void enable_uart0_pin_mux(void);
+void enable_uart1_pin_mux(void);
+void enable_uart2_pin_mux(void);
+void enable_uart3_pin_mux(void);
+void enable_uart4_pin_mux(void);
+void enable_uart5_pin_mux(void);
void enable_i2c0_pin_mux(void);
void enable_board_pin_mux(struct am335x_baseboard_id *header);
#endif
diff --git a/board/ti/am335x/mux.c b/board/ti/am335x/mux.c
index 80becd5..82b5852 100644
--- a/board/ti/am335x/mux.c
+++ b/board/ti/am335x/mux.c
@@ -259,6 +259,36 @@ static struct module_pin_mux uart0_pin_mux[] = {
{-1},
};
+static struct module_pin_mux uart1_pin_mux[] = {
+ {OFFSET(uart1_rxd), (MODE(0) | PULLUP_EN | RXACTIVE)}, /* UART1_RXD */
+ {OFFSET(uart1_txd), (MODE(0) | PULLUDEN)}, /* UART1_TXD */
+ {-1},
+};
+
+static struct module_pin_mux uart2_pin_mux[] = {
+ {OFFSET(spi0_sclk), (MODE(1) | PULLUP_EN | RXACTIVE)}, /* UART2_RXD */
+ {OFFSET(spi0_d0), (MODE(1) | PULLUDEN)},/* UART2_TXD */
+ {-1},
+};
+
+static struct module_pin_mux uart3_pin_mux[] = {
+ {OFFSET(spi0_cs1), (MODE(1) | PULLUP_EN | RXACTIVE)}, /* UART3_RXD */
+ {OFFSET(ecap0_in_pwm0_out), (MODE(1) | PULLUDEN)}, /* UART3_TXD */
+ {-1},
+};
+
+static struct module_pin_mux uart4_pin_mux[] = {
+ {OFFSET(gpmc_wait0), (MODE(6) | PULLUP_EN | RXACTIVE)}, /* UART4_RXD */
+ {OFFSET(gpmc_wpn), (MODE(6) | PULLUDEN)}, /* UART4_TXD */
+ {-1},
+};
+
+static struct module_pin_mux uart5_pin_mux[] = {
+ {OFFSET(lcd_data9), (MODE(4) | PULLUP_EN | RXACTIVE)}, /* UART5_RXD */
+ {OFFSET(lcd_data8), (MODE(4) | PULLUDEN)}, /* UART5_TXD */
+ {-1},
+};
+
static struct module_pin_mux mmc0_pin_mux[] = {
{OFFSET(mmc0_dat3), (MODE(0) | RXACTIVE | PULLUP_EN)}, /* MMC0_DAT3 */
{OFFSET(mmc0_dat2), (MODE(0) | RXACTIVE | PULLUP_EN)}, /* MMC0_DAT2 */
@@ -381,6 +411,30 @@ void enable_uart0_pin_mux(void)
configure_module_pin_mux(uart0_pin_mux);
}
+void enable_uart1_pin_mux(void)
+{
+ configure_module_pin_mux(uart1_pin_mux);
+}
+
+void enable_uart2_pin_mux(void)
+{
+ configure_module_pin_mux(uart2_pin_mux);
+}
+
+void enable_uart3_pin_mux(void)
+{
+ configure_module_pin_mux(uart3_pin_mux);
+}
+
+void enable_uart4_pin_mux(void)
+{
+ configure_module_pin_mux(uart4_pin_mux);
+}
+
+void enable_uart5_pin_mux(void)
+{
+ configure_module_pin_mux(uart5_pin_mux);
+}
void enable_i2c0_pin_mux(void)
{
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 4/4] am335x_evm: Enable use of UART{1,2,3,4,5}
Add targets of am335x_evm_uart{1,2,3,4,5} to have serial input/output on
UART{1,2,3,4,5} for use with the Beaglebone RS232 cape, am335x_evm
daughterboard, and other custom configurations.
Modify target for am335x_evm to include SERIAL1 and CONS_INDEX=1
options in order to clarify UART selection requirements.
Signed-off-by: Andrew Bradford
---
Changes from v3:
All am335x_evm targets get SERIALX without a 1 and CONS_INDEX=X
defined in boards.cfg. am335x_evm.h no longer define any
CONFIG_SERIALX or CONFIG_CONS_INDEX.
Changes from v2:
Set CONS_INDEX and SERIALX in the target options instead of
using AM33XX_UART_SELECT resulting in an easier to read config.
Changes from v1:
Add UART3 target and register location.
boards.cfg |7 ++-
include/configs/am335x_evm.h | 12 +++-
2 files changed, 13 insertions(+), 6 deletions(-)
diff --git a/boards.cfg b/boards.cfg
index b14a08f..4047966 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -225,7 +225,12 @@ versatileqemuarm arm926ejs
versatile armltd
integratorap_cm946es arm arm946esintegrator
armltd - integratorap:CM946ES
integratorcp_cm946es arm arm946esintegrator
armltd - integratorcp:CM946ES
ca9x4_ct_vxp arm armv7 vexpressarmltd
-am335x_evm arm armv7 am335x ti
am33xx
+am335x_evm arm armv7 am335x ti
am33xx am335x_evm:SERIAL1,CONS_INDEX=1
+am335x_evm_uart1 arm armv7 am335x ti
am33xx am335x_evm:SERIAL2,CONS_INDEX=2
+am335x_evm_uart2 arm armv7 am335x ti
am33xx am335x_evm:SERIAL3,CONS_INDEX=3
+am335x_evm_uart3 arm armv7 am335x ti
am33xx am335x_evm:SERIAL4,CONS_INDEX=4
+am335x_evm_uart4 arm armv7 am335x ti
am33xx am335x_evm:SERIAL5,CONS_INDEX=5
+am335x_evm_uart5 arm armv7 am335x ti
am33xx am335x_evm:SERIAL6,CONS_INDEX=6
highbank arm armv7 highbank-
highbank
mx51_efikamx arm armv7 mx51_efikamx
genesi mx5
mx51_efikamx:MACH_TYPE=MACH_TYPE_MX51_EFIKAMX,IMX_CONFIG=board/genesi/mx51_efikamx/imximage_mx.cfg
mx51_efikasb arm armv7 mx51_efikamx
genesi mx5
mx51_efikamx:MACH_TYPE=MACH_TYPE_MX51_EFIKASB,IMX_CONFIG=board/genesi/mx51_efikamx/imximage_sb.cfg
diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h
index 339d4bd..e822d25 100644
--- a/include/configs/am335x_evm.h
+++ b/include/configs/am335x_evm.h
@@ -158,9 +158,15 @@
/* NS16550 Configuration */
#define CONFIG_SYS_NS16550
#define CONFIG_SYS_NS16550_SERIAL
+#define CONFIG_SERIAL_MULTI
#define CONFIG_SYS_NS16550_REG_SIZE(-4)
#define CONFIG_SYS_NS16550_CLK (4800)
#define CONFIG_SYS_NS16550_COM10x44e09000 /* Base EVM has
UART0 */
+#define CONFIG_SYS_NS16550_COM20x48022000 /* UART1 */
+#define CONFIG_SYS_NS16550_COM30x48024000 /* UART2 */
+#define CONFIG_SYS_NS16550_COM40x481a6000 /* UART3 */
+#define CONFIG_SYS_NS16550_COM50x481a8000 /* UART4 */
+#define CONFIG_SYS_NS16550_COM60x481aa000 /* UART5 */
/* I2C Configuration */
#define CONFIG_I2C
@@ -182,11 +188,7 @@
#define CONFIG_SYS_BAUDRATE_TABLE { 110, 300, 600, 1200, 2400, \
4800, 9600, 14400, 19200, 28800, 38400, 56000, 57600, 115200 }
-/*
- * select serial console configuration
- */
-#define CONFIG_SERIAL1 1
-#define CONFIG_CONS_INDEX 1
+#define CONFIG_ENV_OVERWRITE 1
#define CONFIG_SYS_CONSOLE_INFO_QUIET
#define CONFIG_ENV_IS_NOWHERE
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] USB detection
Dear All While board bring up in custom board iam getting below mentioned error I2C: ready DRAM: DDR: failed to read SPD from address I googled it but i am un able to rectify it.. Please resole ASAP manukumar ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Merging device trees at runtime for module-based systems
Dear Daniel, In message <5087b919.2010...@gmail.com> you wrote: > > So let's say we have n versions of the baseboard and m versions of the > module, we would much like to only prepare n + m files, instead of n * m > by pre-compiling every possible combination (some of which may actually > never occur 'in the wild'). What you are facing is a situation that 1) appears to be pretty common, and 2) has (AFAICT) not been truely satisfactory solved yet. > So my question is: is it possible to do that kind of assembly of a > number of files at runtime in U-Boot? I guess all it takes is merging a > number of trees together, right? I browsed through the APIs but couldn't > yet find an clear approach to that kind of problem. If not, what would > it take to add that functionality? I can probably help with the > implementation if someone tells me what would be the right way. I think it should be possible to overlay several DT images; ideally these would be strictly orthogonal, i. e. the newly loaded one would only add new properties, but I think it should be also no problem to define some latest-wins policy, i. e. in case of already existing properties the newly loaded ones would just overwrite the previous settings. I definitely can see the benefit of such a feature and would be happy if you could go forward and implement it. Thanks in advance. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de While money can't buy happiness, it certainly lets you choose your own form of misery. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Merging device trees at runtime for module-based systems
Hi Wolfgang, On 25.10.2012 14:44, Wolfgang Denk wrote: > In message <5087b919.2010...@gmail.com> you wrote: >> >> So let's say we have n versions of the baseboard and m versions of the >> module, we would much like to only prepare n + m files, instead of n * m >> by pre-compiling every possible combination (some of which may actually >> never occur 'in the wild'). > > What you are facing is a situation that > 1) appears to be pretty common, and > 2) has (AFAICT) not been truely satisfactory solved yet. > >> So my question is: is it possible to do that kind of assembly of a >> number of files at runtime in U-Boot? I guess all it takes is merging a >> number of trees together, right? I browsed through the APIs but couldn't >> yet find an clear approach to that kind of problem. If not, what would >> it take to add that functionality? I can probably help with the >> implementation if someone tells me what would be the right way. > > I think it should be possible to overlay several DT images; ideally > these would be strictly orthogonal, i. e. the newly loaded one would > only add new properties, but I think it should be also no problem to > define some latest-wins policy, i. e. in case of already existing > properties the newly loaded ones would just overwrite the previous > settings. Overwrites must be addressed in the first place. The most common example is that a more generic part (the module tree) registers all details about a peripheral up-front but then sets its status to 'disabled'. That way, the more specific part (the base board tree) can overwrite this property to 'okay' at wish to enable it and not care for the pre-defined details. This is also how we do things in our device-trees. > I definitely can see the benefit of such a feature and would be happy > if you could go forward and implement it. Ok then. I guess this should be something that can eventually be merged back into libfdt? Thanks, Daniel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] mx6qsabrelite: commands not recognized
Hi, Using the latest u-boot-imx tree, I am getting the following on a mx6qsabrelite: U-Boot 2012.10-09478-gab857f2 (Oct 25 2012 - 11:24:04) CPU: Freescale i.MX6Q rev1.0 at 792 MHz Reset cause: POR Board: MX6Q-Sabre Lite DRAM: 1 GiB MMC: FSL_SDHC: 0, FSL_SDHC: 1 auto-detected panel HDMI enable_hdmi: setup HDMI monitor Display: HDMI (1024x768) In:serial Out: serial Err: serial Net: FEC [PRIME] Warning: failed to set MAC address Hit any key to stop autoboot: 0 MX6QSABRELITE U-Boot > save Unknown command 'save' - try 'help' MX6QSABRELITE U-Boot > Basically no commands are recognized. Haven't started bisecting this yet, but just wanted to check if others see the same issue. Thanks, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] mx6qsabrelite: commands not recognized
Hi Fabio, On 10/25/2012 06:28 AM, Fabio Estevam wrote: Hi, Using the latest u-boot-imx tree, I am getting the following on a mx6qsabrelite: U-Boot 2012.10-09478-gab857f2 (Oct 25 2012 - 11:24:04) CPU: Freescale i.MX6Q rev1.0 at 792 MHz Reset cause: POR Board: MX6Q-Sabre Lite DRAM: 1 GiB MMC: FSL_SDHC: 0, FSL_SDHC: 1 auto-detected panel HDMI enable_hdmi: setup HDMI monitor Display: HDMI (1024x768) In:serial Out: serial Err: serial Net: FEC [PRIME] Warning: failed to set MAC address Hit any key to stop autoboot: 0 MX6QSABRELITE U-Boot> save Unknown command 'save' - try 'help' MX6QSABRELITE U-Boot> Basically no commands are recognized. Haven't started bisecting this yet, but just wanted to check if others see the same issue. You might want to check how you're programming this. I saw this issue when U-Boot first went above 256k (the SPI-NOR upgrade script only erased 0x4 bytes). I'll test later today. Regards, Eric ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] mx6qsabrelite: commands not recognized
Hi Fabio, On 10/25/2012 07:07 AM, Eric Nelson wrote: Hi Fabio, On 10/25/2012 06:28 AM, Fabio Estevam wrote: Hi, Using the latest u-boot-imx tree, I am getting the following on a mx6qsabrelite: U-Boot 2012.10-09478-gab857f2 (Oct 25 2012 - 11:24:04) Hit any key to stop autoboot: 0 MX6QSABRELITE U-Boot> save Unknown command 'save' - try 'help' MX6QSABRELITE U-Boot> Basically no commands are recognized. Haven't started bisecting this yet, but just wanted to check if others see the same issue. You might want to check how you're programming this. I saw this issue when U-Boot first went above 256k (the SPI-NOR upgrade script only erased 0x4 bytes). I'll test later today. Worked for me... U-Boot 2012.10-01993-gab857f2 (Oct 25 2012 - 08:00:14) CPU: Freescale i.MX6Q rev1.0 at 792 MHz Reset cause: POR Board: MX6Q-Sabre Lite DRAM: 1 GiB MMC: FSL_SDHC: 0, FSL_SDHC: 1 *** Warning - bad CRC, using default environment auto-detected panel HDMI enable_hdmi: setup HDMI monitor Display: HDMI (1024x768) In:serial Out: serial Err: serial Net: FEC [PRIME] Warning: FEC using MAC address from net device Hit any key to stop autoboot: 0 MX6QSABRELITE U-Boot > MX6QSABRELITE U-Boot > help ? - alias for 'help' base- print or set address offset bdinfo - print Board Info structure ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 10/32] include/command.h: sparse fix
On Tue, Oct 16, 2012 at 07:28:26PM -0500, Kim Phillips wrote: > __u_boot_cmd_* should be declared static, e.g.: > > cmd_mem.c:1142:1: warning: symbol '__u_boot_cmd_md' was not declared. Should > it be static? > cmd_mem.c:1149:1: warning: symbol '__u_boot_cmd_mm' was not declared. Should > it be static? > cmd_mem.c:1156:1: warning: symbol '__u_boot_cmd_nm' was not declared. Should > it be static? > cmd_mem.c:1162:1: warning: symbol '__u_boot_cmd_mw' was not declared. Should > it be static? > cmd_mem.c:1168:1: warning: symbol '__u_boot_cmd_cp' was not declared. Should > it be static? > cmd_mem.c:1174:1: warning: symbol '__u_boot_cmd_cmp' was not declared. Should > it be static? > cmd_mem.c:1184:1: warning: symbol '__u_boot_cmd_crc32' was not declared. > Should it be static? > cmd_mem.c:1203:1: warning: symbol '__u_boot_cmd_base' was not declared. > Should it be static? > cmd_mem.c:1210:1: warning: symbol '__u_boot_cmd_loop' was not declared. > Should it be static? > cmd_mem.c:1224:1: warning: symbol '__u_boot_cmd_mtest' was not declared. > Should it be static? > > Signed-off-by: Kim Phillips > --- > include/command.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/include/command.h b/include/command.h > index 1f06aa1..c051158 100644 > --- a/include/command.h > +++ b/include/command.h > @@ -174,7 +174,7 @@ int cmd_process(int flag, int argc, char * const argv[], > U_BOOT_CMD_MKENT_COMPLETE(name,maxargs,rep,cmd,usage,help,NULL) > > #define U_BOOT_CMD_COMPLETE(name,maxargs,rep,cmd,usage,help,comp) \ > - cmd_tbl_t __u_boot_cmd_##name Struct_Section = \ > + static cmd_tbl_t __u_boot_cmd_##name Struct_Section = \ > U_BOOT_CMD_MKENT_COMPLETE(name,maxargs,rep,cmd,usage,help,comp) > > #define U_BOOT_CMD(name,maxargs,rep,cmd,usage,help) \ I tried porting this change to the LG-arrays that are now in master and that resulted in no commands being available. Please re-do and test against master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/9 V3] SOUND: SAMSUNG: Add I2S driver
Hi,
On Mon, Oct 22, 2012 at 11:57 PM, Rajeshwari Shinde
wrote:
> This patch adds driver for I2S interface specific to samsung.
>
> Signed-off-by: R. Chandrasekar
> Signed-off-by: Rajeshwari Shinde
> ---
> Changes in V2:
> - renamed i2s.c to samsung-i2s.c.
> Changes in V3:
> - wave sine table removed and the same in calculated in a function.
This looks great. There are a few style nits that you might want to
correct, but:
Acked-by: Simon Glass
> Makefile|1 +
> drivers/sound/Makefile | 47 ++
> drivers/sound/samsung-i2s.c | 358
> +++
> drivers/sound/sound.c | 228 +++
> include/i2s.h | 127 +++
> include/sound.h | 62
> 6 files changed, 823 insertions(+), 0 deletions(-)
> create mode 100644 drivers/sound/Makefile
> create mode 100644 drivers/sound/samsung-i2s.c
> create mode 100644 drivers/sound/sound.c
> create mode 100644 include/i2s.h
> create mode 100644 include/sound.h
>
> diff --git a/Makefile b/Makefile
> index a40d4cc..f7d7f47 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -293,6 +293,7 @@ LIBS-y += arch/powerpc/cpu/mpc8xxx/lib8xxx.o
> endif
> LIBS-y += drivers/rtc/librtc.o
> LIBS-y += drivers/serial/libserial.o
> +LIBS-y += drivers/sound/libsound.o
> LIBS-$(CONFIG_GENERIC_LPC_TPM) += drivers/tpm/libtpm.o
> LIBS-y += drivers/twserial/libtws.o
> LIBS-y += drivers/usb/eth/libusb_eth.o
> diff --git a/drivers/sound/Makefile b/drivers/sound/Makefile
> new file mode 100644
> index 000..18ad2c9
> --- /dev/null
> +++ b/drivers/sound/Makefile
> @@ -0,0 +1,47 @@
> +#
> +# Copyright (C) 2012 Samsung Electronics
> +# R. Chandrasekar
> +#
> +# 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)libsound.o
> +
> +COBJS-$(CONFIG_SOUND) += sound.o
> +COBJS-$(CONFIG_I2S)+= samsung-i2s.o
> +
> +COBJS := $(COBJS-y)
> +SRCS := $(COBJS:.o=.c)
> +OBJS := $(addprefix $(obj),$(COBJS))
> +
> +all: $(LIB)
> +
> +$(LIB):$(obj).depend $(OBJS)
> + $(call cmd_link_o_target, $(OBJS))
> +
> +#
> +
> +# defines $(obj).depend target
> +include $(SRCTREE)/rules.mk
> +
> +sinclude $(obj).depend
> +
> +#
> diff --git a/drivers/sound/samsung-i2s.c b/drivers/sound/samsung-i2s.c
> new file mode 100644
> index 000..3ce0b59
> --- /dev/null
> +++ b/drivers/sound/samsung-i2s.c
> @@ -0,0 +1,358 @@
> +/*
> + * Copyright (C) 2012 Samsung Electronics
> + * R. Chandrasekar
> + *
> + * 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
> +
> +#define FIC_TX2COUNT(x)(((x) >> 24) & 0xf)
> +#define FIC_TX1COUNT(x)(((x) >> 16) & 0xf)
> +#define FIC_TXCOUNT(x) (((x) >> 8) & 0xf)
> +#define FIC_RXCOUNT(x) (((x) >> 0) & 0xf)
> +#define FICS_TXCOUNT(x)(((x) >> 8) & 0x7f)
> +
> +#define TIMEOUT_I2S_TX 100 /* i2s transfer timeout */
> +
> +/*
> + * Sets the frame size for I2S LR clock
> + *
> + * @param i2s_reg i2s regiter address
> + * @param rfs Frame Size
> + */
> +static void i2s_set_lr_framesize(struct i2s_reg *i2s_reg, unsigned int rfs)
> +{
> + unsigned int mod = readl(&i2s_reg->mod);
>
Re: [U-Boot] [PATCH 2/9 V3] SOUND: Add WM8994 codec
Hi, On Mon, Oct 22, 2012 at 11:57 PM, Rajeshwari Shinde wrote: > This patch adds driver for audio codec WM8994 > > Signed-off-by: R. Chandrasekar > Signed-off-by: Rajeshwari Shinde Acked-by: Simon Glass > --- > Changes in V2: > - None > Changes in V3: > - Incorporated comments from Simon Glass. Sometimes it is better to list the actual changes made. > drivers/sound/Makefile |1 + > drivers/sound/wm8994.c | 792 > ++ > drivers/sound/wm8994.h | 87 + > drivers/sound/wm8994_registers.h | 299 ++ > 4 files changed, 1179 insertions(+), 0 deletions(-) > create mode 100644 drivers/sound/wm8994.c > create mode 100644 drivers/sound/wm8994.h > create mode 100644 drivers/sound/wm8994_registers.h > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/9 V3] Sound: Add command for audio playback
On Mon, Oct 22, 2012 at 11:57 PM, Rajeshwari Shinde
wrote:
> This patch adds command to test audio playback.
> sound init - Initialises the audio subsystem (i2s and wm8994 codec)
> sound play - Plays predefined the audio data when specified length
> and frequency.
>
> Signed-off-by: Rajeshwari Shinde
Acked-by: Simon Glass
> ---
> Changes in V2:
> - None
> Changes in V3:
> - Incorporated comments from Simon Glass.
> common/Makefile|1 +
> common/cmd_sound.c | 96
>
> 2 files changed, 97 insertions(+), 0 deletions(-)
> create mode 100644 common/cmd_sound.c
>
> diff --git a/common/Makefile b/common/Makefile
> index 5442fbb..c0aa4a3 100644
> --- a/common/Makefile
> +++ b/common/Makefile
> @@ -74,6 +74,7 @@ COBJS-$(CONFIG_CMD_CONSOLE) += cmd_console.o
> COBJS-$(CONFIG_CMD_CPLBINFO) += cmd_cplbinfo.o
> COBJS-$(CONFIG_DATAFLASH_MMC_SELECT) += cmd_dataflash_mmc_mux.o
> COBJS-$(CONFIG_CMD_DATE) += cmd_date.o
> +COBJS-$(CONFIG_CMD_SOUND) += cmd_sound.o
> ifdef CONFIG_4xx
> COBJS-$(CONFIG_CMD_SETGETDCR) += cmd_dcr.o
> endif
> diff --git a/common/cmd_sound.c b/common/cmd_sound.c
> new file mode 100644
> index 000..459d1eb
> --- /dev/null
> +++ b/common/cmd_sound.c
> @@ -0,0 +1,96 @@
> +/*
> + * Copyright (C) 2012 Samsung Electronics
> + * Rajeshwari Shinde
> + *
> + * 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
> +
> +DECLARE_GLOBAL_DATA_PTR;
> +
> +/* Initilaise sound subsystem */
> +static int do_init(cmd_tbl_t *cmdtp, int flag, int argc, char *const argv[])
> +{
> + int ret;
> +
> + ret = sound_init();
> + if (ret) {
> + printf("Initialise Audio driver failed\n");
> + return CMD_RET_FAILURE;
> + }
> +
> + return 0;
> +}
> +
> +/* play sound from buffer */
> +static int do_play(cmd_tbl_t *cmdtp, int flag, int argc, char *const argv[])
> +{
> + int ret = 0;
> + int msec = 1000;
> + int freq = 400;
> +
> + if (argc > 1)
> + msec = simple_strtoul(argv[1], NULL, 10);
> + if (argc > 2)
> + freq = simple_strtoul(argv[2], NULL, 10);
> +
> + ret = sound_play(msec, freq);
> + if (ret) {
> + printf("play failed");
> + return CMD_RET_FAILURE;
> + }
> +
> + return 0;
> +}
> +
> +static cmd_tbl_t cmd_sound_sub[] = {
> + U_BOOT_CMD_MKENT(init, 0, 1, do_init, "", ""),
> + U_BOOT_CMD_MKENT(play, 2, 1, do_play, "", ""),
> +};
> +
> +/* process sound command */
> +static int do_sound(cmd_tbl_t *cmdtp, int flag, int argc, char *const argv[])
> +{
> + cmd_tbl_t *c;
> +
> + if (argc < 1)
> + return CMD_RET_USAGE;
> +
> + /* Strip off leading 'sound' command argument */
> + argc--;
> + argv++;
> +
> + c = find_cmd_tbl(argv[0], &cmd_sound_sub[0],
> ARRAY_SIZE(cmd_sound_sub));
> +
> + if (c)
> + return c->cmd(cmdtp, flag, argc, argv);
> + else
> + return CMD_RET_USAGE;
> +}
> +
> +U_BOOT_CMD(
> + sound, 4, 1, do_sound,
> + "sound sub-system",
> + "init - initialise the sound driver\n"
> + "sound play [len] [freq] - play a sound for len ms at freq hz\n"
> +);
> --
> 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 8/9 V3] EXYNOS: Add clock for I2S
On Mon, Oct 22, 2012 at 11:57 PM, Rajeshwari Shinde wrote: > This patch adds clock support for I2S > > Signed-off-by: R. Chandrasekar > Signed-off-by: Rajeshwari Shinde Acked-by: Simon Glass > --- > Changes in V2: > - None > Changes in V3: > - Changes clock function names as suggested by Minkyu Kang. > arch/arm/cpu/armv7/exynos/clock.c| 120 > ++ > arch/arm/include/asm/arch-exynos/clk.h |3 + > arch/arm/include/asm/arch-exynos/clock.h | 29 +++ > 3 files changed, 152 insertions(+), 0 deletions(-) > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/9 V3] EXYNOS5: Add Audio support
Hi, On Mon, Oct 22, 2012 at 11:57 PM, Rajeshwari Shinde wrote: > This patchset adds the audio support for EXYNOS5. > This patchset plays a predefined beep sound. > > Rajeshwari Shinde (9): > SOUND: SAMSUNG: Add I2S driver > SOUND: Add WM8994 codec > Sound: Add command for audio playback > EXYNOS: Add I2S registers > EXYNOS: Add parameters required by I2S > EXYNOS: Add pinmux for I2S > EXYNOS: Add I2S base address > EXYNOS: Add clock for I2S > SMDK5250: Enable Sound > > Changes in V2: > - renamed i2s.c to samsung-i2s.c. > - made exynos_i2s_config pinmux function static. > - corrected the commit message for "Enable sound" patch. > Changes in V3: > - Incorporated comments from Simon Glass and Minkyu Kang. I have been through this again and it seems good to me, thanks. > > Makefile|1 + > arch/arm/cpu/armv7/exynos/clock.c | 120 > arch/arm/cpu/armv7/exynos/pinmux.c | 13 + > arch/arm/include/asm/arch-exynos/clk.h |3 + > arch/arm/include/asm/arch-exynos/clock.h| 29 + > arch/arm/include/asm/arch-exynos/cpu.h |3 + > arch/arm/include/asm/arch-exynos/i2s-regs.h | 66 +++ > arch/arm/include/asm/arch-exynos/periph.h |1 + > arch/arm/include/asm/arch-exynos/sound.h| 44 ++ > common/Makefile |1 + > common/cmd_sound.c | 96 > drivers/sound/Makefile | 48 ++ > drivers/sound/samsung-i2s.c | 358 > drivers/sound/sound.c | 228 > drivers/sound/wm8994.c | 792 > +++ > drivers/sound/wm8994.h | 87 +++ > drivers/sound/wm8994_registers.h| 299 ++ > include/configs/smdk5250.h |8 + > include/i2s.h | 127 + > include/sound.h | 62 +++ > 20 files changed, 2386 insertions(+), 0 deletions(-) > create mode 100644 arch/arm/include/asm/arch-exynos/i2s-regs.h > create mode 100644 arch/arm/include/asm/arch-exynos/sound.h > create mode 100644 common/cmd_sound.c > create mode 100644 drivers/sound/Makefile > create mode 100644 drivers/sound/samsung-i2s.c > create mode 100644 drivers/sound/sound.c > create mode 100644 drivers/sound/wm8994.c > create mode 100644 drivers/sound/wm8994.h > create mode 100644 drivers/sound/wm8994_registers.h > create mode 100644 include/i2s.h > create mode 100644 include/sound.h > > -- > 1.7.4.4 > Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/6 V7] SPI: Add SPI Driver for EXYNOS.
Hi Hatim,
On Mon, Oct 22, 2012 at 4:52 AM, Hatim Ali wrote:
> From: Rajeshwari Shinde
>
> This patch adds SPI driver for EXYNOS.
>
> Signed-off-by: Simon Glass
> Signed-off-by: Padmavathi Venna
> Signed-off-by: Gabe Black
> Signed-off-by: Rajeshwari Shinde
> Signed-off-by: Hatim Ali
> Acked-by: Mike Frysinger
> Tested-by: jy0922.s...@samsung.com
Acked-by: Simon Glass
> ---
> Changes since V4:
> - Changed SPI bus frequency to 10 Mhz
> Changes since V5:
> - Incorporated changes by Minkyu Kang
> Changes since V6:
> - No Change
>
>
> diff --git a/arch/arm/include/asm/arch-exynos/spi.h
> b/arch/arm/include/asm/arch-exynos/spi.h
> new file mode 100644
> index 000..7cab1e9
> --- /dev/null
> +++ b/arch/arm/include/asm/arch-exynos/spi.h
> @@ -0,0 +1,78 @@
> +/*
> + * (C) Copyright 2012 SAMSUNG Electronics
> + * Padmavathi Venna
> + *
> + * 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
> + */
> +
> +#ifndef __ASM_ARCH_EXYNOS_COMMON_SPI_H_
> +#define __ASM_ARCH_EXYNOS_COMMON_SPI_H_
> +
> +#ifndef __ASSEMBLY__
> +
> +/* SPI peripheral register map; padded to 64KB */
> +struct exynos_spi {
> + unsigned intch_cfg; /* 0x00 */
> + unsigned char reserved0[4];
> + unsigned intmode_cfg; /* 0x08 */
> + unsigned intcs_reg; /* 0x0c */
> + unsigned char reserved1[4];
> + unsigned intspi_sts;/* 0x14 */
> + unsigned inttx_data;/* 0x18 */
> + unsigned intrx_data;/* 0x1c */
> + unsigned intpkt_cnt;/* 0x20 */
> + unsigned char reserved2[4];
> + unsigned char reserved3[4];
> + unsigned intfb_clk; /* 0x2c */
> + unsigned char padding[0xffd0];
> +};
> +
> +#define EXYNOS_SPI_MAX_FREQ5000
> +
> +#define SPI_TIMEOUT_MS 10
> +
> +/* SPI_CHCFG */
> +#define SPI_CH_HS_EN (1 << 6)
> +#define SPI_CH_RST (1 << 5)
> +#define SPI_SLAVE_MODE (1 << 4)
> +#define SPI_CH_CPOL_L (1 << 3)
> +#define SPI_CH_CPHA_B (1 << 2)
> +#define SPI_RX_CH_ON (1 << 1)
> +#define SPI_TX_CH_ON (1 << 0)
> +
> +/* SPI_MODECFG */
> +#define SPI_MODE_CH_WIDTH_WORD (0x2 << 29)
> +#define SPI_MODE_BUS_WIDTH_WORD(0x2 << 17)
> +
> +/* SPI_CSREG */
> +#define SPI_SLAVE_SIG_INACT(1 << 0)
> +
> +/* SPI_STS */
> +#define SPI_ST_TX_DONE (1 << 25)
> +#define SPI_FIFO_LVL_MASK 0x1ff
> +#define SPI_TX_LVL_OFFSET 6
> +#define SPI_RX_LVL_OFFSET 15
> +
> +/* Feedback Delay */
> +#define SPI_CLK_BYPASS (0 << 0)
> +#define SPI_FB_DELAY_90(1 << 0)
> +#define SPI_FB_DELAY_180 (2 << 0)
> +#define SPI_FB_DELAY_270 (3 << 0)
> +
> +/* Packet Count */
> +#define SPI_PACKET_CNT_EN (1 << 16)
> +
> +#endif /* __ASSEMBLY__ */
> +#endif
> diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
> index f0b82c6..824d357 100644
> --- a/drivers/spi/Makefile
> +++ b/drivers/spi/Makefile
> @@ -34,6 +34,7 @@ COBJS-$(CONFIG_BFIN_SPI) += bfin_spi.o
> COBJS-$(CONFIG_CF_SPI) += cf_spi.o
> COBJS-$(CONFIG_CF_QSPI) += cf_qspi.o
> COBJS-$(CONFIG_DAVINCI_SPI) += davinci_spi.o
> +COBJS-$(CONFIG_EXYNOS_SPI) += exynos_spi.o
> COBJS-$(CONFIG_KIRKWOOD_SPI) += kirkwood_spi.o
> COBJS-$(CONFIG_MPC52XX_SPI) += mpc52xx_spi.o
> COBJS-$(CONFIG_MPC8XXX_SPI) += mpc8xxx_spi.o
> diff --git a/drivers/spi/exynos_spi.c b/drivers/spi/exynos_spi.c
> new file mode 100644
> index 000..4ee774b
> --- /dev/null
> +++ b/drivers/spi/exynos_spi.c
> @@ -0,0 +1,366 @@
> +/*
> + * (C) Copyright 2012 SAMSUNG Electronics
> + * Padmavathi Venna
> + *
> + * 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.
> + *
Re: [U-Boot] [PATCH 1/6 V7] EXYNOS5: Add pinmux support for SPI
On Mon, Oct 22, 2012 at 4:52 AM, Hatim Ali wrote:
> From: Rajeshwari Shinde
>
> This patch adds pinmux support for SPI channels
>
> Signed-off-by: Rajeshwari Shinde
> Signed-off-by: Hatim Ali
Acked-by: Simon Glass
> ---
> Changes since v4:
> Fixed minor nits suggested by Simon Glass
> Changes since v5:
> No change
> Changes since v6:
> Incorporated review comments by Simon Glass & Minkyu Kang
>
> diff --git a/arch/arm/cpu/armv7/exynos/pinmux.c
> b/arch/arm/cpu/armv7/exynos/pinmux.c
> index 5796d56..3ecbf7d 100644
> --- a/arch/arm/cpu/armv7/exynos/pinmux.c
> +++ b/arch/arm/cpu/armv7/exynos/pinmux.c
> @@ -112,6 +112,7 @@ static int exynos5_mmc_config(int peripheral, int flags)
> s5p_gpio_set_pull(bank, i, GPIO_PULL_UP);
> s5p_gpio_set_drv(bank, i, GPIO_DRV_4X);
> }
> +
> return 0;
> }
>
> @@ -230,6 +231,49 @@ static void exynos5_i2c_config(int peripheral, int flags)
> }
> }
>
> +void exynos5_spi_config(int peripheral)
> +{
> + int cfg = 0, pin = 0, i;
> + struct s5p_gpio_bank *bank = NULL;
> + struct exynos5_gpio_part1 *gpio1 =
> + (struct exynos5_gpio_part1 *) samsung_get_base_gpio_part1();
> + struct exynos5_gpio_part2 *gpio2 =
> + (struct exynos5_gpio_part2 *) samsung_get_base_gpio_part2();
> +
> + switch (peripheral) {
> + case PERIPH_ID_SPI0:
> + bank = &gpio1->a2;
> + cfg = GPIO_FUNC(0x2);
> + pin = 0;
> + break;
> + case PERIPH_ID_SPI1:
> + bank = &gpio1->a2;
> + cfg = GPIO_FUNC(0x2);
> + pin = 4;
> + break;
> + case PERIPH_ID_SPI2:
> + bank = &gpio1->b1;
> + cfg = GPIO_FUNC(0x5);
> + pin = 1;
> + break;
> + case PERIPH_ID_SPI3:
> + bank = &gpio2->f1;
> + cfg = GPIO_FUNC(0x2);
> + pin = 0;
> + break;
> + case PERIPH_ID_SPI4:
> + for (i = 0; i < 2; i++) {
> + s5p_gpio_cfg_pin(&gpio2->f0, i + 2, GPIO_FUNC(0x4));
> + s5p_gpio_cfg_pin(&gpio2->e0, i + 4, GPIO_FUNC(0x4));
> + }
> + break;
> + }
> + if (peripheral != PERIPH_ID_SPI4) {
> + for (i = pin; i < pin + 4; i++)
> + s5p_gpio_cfg_pin(bank, i, cfg);
> + }
> +}
> +
> static int exynos5_pinmux_config(int peripheral, int flags)
> {
> switch (peripheral) {
> @@ -257,6 +301,13 @@ static int exynos5_pinmux_config(int peripheral, int
> flags)
> case PERIPH_ID_I2C7:
> exynos5_i2c_config(peripheral, flags);
> break;
> + case PERIPH_ID_SPI0:
> + case PERIPH_ID_SPI1:
> + case PERIPH_ID_SPI2:
> + case PERIPH_ID_SPI3:
> + case PERIPH_ID_SPI4:
> + exynos5_spi_config(peripheral);
> + break;
> default:
> debug("%s: invalid peripheral %d", __func__, peripheral);
> return -1;
> diff --git a/arch/arm/include/asm/arch-exynos/periph.h
> b/arch/arm/include/asm/arch-exynos/periph.h
> index 082611c..4054fb6 100644
> --- a/arch/arm/include/asm/arch-exynos/periph.h
> +++ b/arch/arm/include/asm/arch-exynos/periph.h
> @@ -44,6 +44,11 @@ enum periph_id {
> PERIPH_ID_SDMMC3,
> PERIPH_ID_SDMMC4,
> PERIPH_ID_SROMC,
> + PERIPH_ID_SPI0,
> + PERIPH_ID_SPI1,
> + PERIPH_ID_SPI2,
> + PERIPH_ID_SPI3,
> + PERIPH_ID_SPI4,
> PERIPH_ID_UART0,
> PERIPH_ID_UART1,
> PERIPH_ID_UART2,
> --
> 1.7.2.3
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/6 V7] EXYNOS: Add clock for SPI.
On Mon, Oct 22, 2012 at 4:52 AM, Hatim Ali wrote: > From: Rajeshwari Shinde > > This patch adds api to calculate and set the clock for SPI channels > > Signed-off-by: James Miller > Signed-off-by: Simon Glass > Signed-off-by: Rajeshwari Shinde > Signed-off-by: Hatim Ali Acked-by: Simon Glass > --- > Changes since v4: > Added Signed-off-by of James Miller > Changes since v5: > Incorporated review comments by Minkyu Kang > Changes since v6: > Based on the review by Minkyu Kang, moved the include periph.h define > to > clock.c file > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/6 V7] EXYNOS5: Enable SPI
On Mon, Oct 22, 2012 at 4:52 AM, Hatim Ali wrote:
> From: Rajeshwari Shinde
>
> This patch enables SPI driver for EXYNOS5.
>
> Signed-off-by: Rajeshwari Shinde
> Signed-off-by: Hatim Ali
Acked-by: Simon Glass
> ---
> Changes since v4:
> - Rebased on u-boot-samsung.git
> Changes since v5:
> No change
> Changes since v6:
> Removed unused define from the config file
>
>
> diff --git a/board/samsung/smdk5250/smdk5250.c
> b/board/samsung/smdk5250/smdk5250.c
> index a5816e4..069c9e8 100644
> --- a/board/samsung/smdk5250/smdk5250.c
> +++ b/board/samsung/smdk5250/smdk5250.c
> @@ -24,6 +24,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -63,6 +64,9 @@ static int smc9115_pre_init(void)
> int board_init(void)
> {
> gd->bd->bi_boot_params = (PHYS_SDRAM_1 + 0x100UL);
> +#ifdef CONFIG_EXYNOS_SPI
> + spi_init();
> +#endif
> return 0;
> }
>
> diff --git a/include/configs/smdk5250.h b/include/configs/smdk5250.h
> index 9e3b55b..604c61e 100644
> --- a/include/configs/smdk5250.h
> +++ b/include/configs/smdk5250.h
> @@ -164,7 +164,6 @@
> #undef CONFIG_CMD_IMLS
> #define CONFIG_IDENT_STRING" for SMDK5250"
>
> -#define CONFIG_ENV_IS_IN_MMC
> #define CONFIG_SYS_MMC_ENV_DEV 0
>
> #define CONFIG_SECURE_BL1_ONLY
> @@ -213,6 +212,27 @@
> #define CONFIG_ENV_SROM_BANK 1
> #endif /*CONFIG_CMD_NET*/
>
> +/* SPI */
> +#define CONFIG_ENV_IS_IN_SPI_FLASH
> +#define CONFIG_SPI_FLASH
> +
> +#ifdef CONFIG_SPI_FLASH
> +#define CONFIG_EXYNOS_SPI
> +#define CONFIG_CMD_SF
> +#define CONFIG_CMD_SPI
> +#define CONFIG_SPI_FLASH_WINBOND
> +#define CONFIG_SF_DEFAULT_MODE SPI_MODE_0
> +#define CONFIG_SF_DEFAULT_SPEED5000
> +#define EXYNOS5_SPI_NUM_CONTROLLERS5
> +#endif
> +
> +#ifdef CONFIG_ENV_IS_IN_SPI_FLASH
> +#define CONFIG_ENV_SPI_MODESPI_MODE_0
> +#define CONFIG_ENV_SECT_SIZE CONFIG_ENV_SIZE
> +#define CONFIG_ENV_SPI_BUS 1
> +#define CONFIG_ENV_SPI_MAX_HZ 5000
> +#endif
> +
> /* Enable PXE Support */
> #ifdef CONFIG_CMD_NET
> #define CONFIG_CMD_PXE
> --
> 1.7.2.3
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 6/6 V7] EXYNOS5: Enable SPI booting.
On Mon, Oct 22, 2012 at 4:52 AM, Hatim Ali wrote: > From: Rajeshwari Shinde > > This patch enables SPI Booting for EXYNOS5 > > Signed-off-by: Rajeshwari Shinde Acked-by: Simon Glass > --- > Changes since v4: > No Change > Changes since v5: > No Change > Changes since v6: > No Change > > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/6 V7] EXYNOS5: Enable SPI support
Hi Hatin, On Mon, Oct 22, 2012 at 4:52 AM, Hatim Ali wrote: > This patch set adds SPI driver for EXYNOS5 and enables same. > This patch set is based on latest Mainline u-boot.git tree. I have acked all of these. Regards, Simon > > Changes in V2: > - Correted the Commit message. > Changes in V3: > - Removed SPI_SLAVE Flag. > - Corrected warning messages. > Changes in V4: > - Rebased on mainline u-boot.git > - Incorporated review comments for SPI driver. > Changes in V5: > - Rebased on u-boot-samsung.git > - Incorporated review comments by Simon Glass > Changes in V6: > - Incorporated review comments by Minkyu Kang > Changes in V7: > - Incorporated review comments by Minkyu Kang & Simon Glass > > Rajeshwari Shinde (6): > EXYNOS5: Add pinmux support for SPI > EXYNOS: Add clock for SPI. > EXYNOS5: Add base address for SPI. > SPI: Add SPI Driver for EXYNOS. > EXYNOS5: Enable SPI > EXYNOS5: Enable SPI booting. > > arch/arm/cpu/armv7/exynos/clock.c | 125 ++ > arch/arm/cpu/armv7/exynos/pinmux.c| 51 > arch/arm/include/asm/arch-exynos/clk.h|2 +- > arch/arm/include/asm/arch-exynos/cpu.h|6 + > arch/arm/include/asm/arch-exynos/periph.h |5 + > arch/arm/include/asm/arch-exynos/spi.h| 78 ++ > board/samsung/smdk5250/Makefile |2 +- > board/samsung/smdk5250/mmc_boot.c | 58 - > board/samsung/smdk5250/smdk5250.c |4 + > board/samsung/smdk5250/spl_boot.c | 85 +++ > drivers/spi/Makefile |1 + > drivers/spi/exynos_spi.c | 366 > + > include/configs/smdk5250.h| 27 ++- > 13 files changed, 749 insertions(+), 61 deletions(-) > create mode 100644 arch/arm/include/asm/arch-exynos/spi.h > delete mode 100644 board/samsung/smdk5250/mmc_boot.c > create mode 100644 board/samsung/smdk5250/spl_boot.c > create mode 100644 drivers/spi/exynos_spi.c > > -- > 1.7.2.3 > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 13/32] common/misc: sparse fixes
On Tue, Oct 16, 2012 at 07:28:29PM -0500, Kim Phillips wrote: > command.c:44:38: error: bad constant expression > console.c:537:18: warning: symbol 'search_device' was not declared. Should it > be static? > dlmalloc.c:1468:2: warning: Using plain integer as NULL pointer > dlmalloc.c:1468:5: warning: Using plain integer as NULL pointer > dlmalloc.c:2176:12: warning: Using plain integer as NULL pointer > dlmalloc.c:2179:31: warning: Using plain integer as NULL pointer > dlmalloc.c:2382:14: warning: Using plain integer as NULL pointer > dlmalloc.c:2436:14: warning: Using plain integer as NULL pointer > dlmalloc.c:2582:31: warning: Using plain integer as NULL pointer > dlmalloc.c:2585:17: warning: Using plain integer as NULL pointer > dlmalloc.c:2646:14: warning: Using plain integer as NULL pointer > dlmalloc.c:2659:19: warning: Using plain integer as NULL pointer > dlmalloc.c:2692:19: warning: Using plain integer as NULL pointer > dlmalloc.c:2707:19: warning: Using plain integer as NULL pointer > dlmalloc.c:2708:14: warning: Using plain integer as NULL pointer > dlmalloc.c:2786:31: warning: Using plain integer as NULL pointer > dlmalloc.c:2801:12: warning: Using plain integer as NULL pointer > dlmalloc.c:2801:22: warning: Using plain integer as NULL pointer > dlmalloc.c:2926:27: warning: Using plain integer as NULL pointer > dlmalloc.c:2928:14: warning: Using plain integer as NULL pointer > dlmalloc.c:2929:12: warning: Using plain integer as NULL pointer > dlmalloc.c:3075:14: warning: Using plain integer as NULL pointer > hush.c:292:14: warning: symbol 'last_return_code' was not declared. Should it > be static? > hush.c:293:5: warning: symbol 'nesting_level' was not declared. Should it be > static? > hush.c:2175:20: warning: Using plain integer as NULL pointer > hush.c:2175:34: warning: Using plain integer as NULL pointer > hush.c:2210:41: warning: Using plain integer as NULL pointer > hush.c:2216:45: warning: Using plain integer as NULL pointer > hush.c:2249:25: warning: Using plain integer as NULL pointer > hush.c:2332:13: warning: symbol 'new_pipe' was not declared. Should it be > static? > hush.c:2390:5: warning: symbol 'reserved_word' was not declared. Should it be > static? > hush.c:2927:5: warning: symbol 'parse_stream' was not declared. Should it be > static? > hush.c:3127:6: warning: symbol 'mapset' was not declared. Should it be static? > hush.c:3133:6: warning: symbol 'update_ifs_map' was not declared. Should it > be static? > hush.c:3161:5: warning: symbol 'parse_stream_outer' was not declared. Should > it be static? > hush.c:3295:34: warning: Using plain integer as NULL pointer > hush.c:3631:5: warning: symbol 'do_showvar' was not declared. Should it be > static > image.c:1282:29: warning: Using plain integer as NULL pointer > image.c:1315:41: warning: Using plain integer as NULL pointer > image.c:1330:25: warning: Using plain integer as NULL pointer > image.c:1706:25: warning: Using plain integer as NULL pointer > main.c:510:10: warning: symbol 'hist_num' was not declared. Should it be > static? > main.c:512:5: warning: symbol 'hist_list' was not declared. Should it be > static? > main.c:513:6: warning: symbol 'hist_lines' was not declared. Should it be > static? > usb_storage.c:195:6: warning: symbol 'usb_show_progress' was not declared. > Should it be static? > usb_storage.c:440:48: warning: Using plain integer as NULL pointer > usb_storage.c:503:5: warning: symbol 'usb_stor_BBB_comdat' was not declared. > Should it be static? > usb_storage.c:551:5: warning: symbol 'usb_stor_CB_comdat' was not declared. > Should it be static? > usb_storage.c:629:55: warning: Using plain integer as NULL pointer > usb_storage.c:620:5: warning: symbol 'usb_stor_CBI_get_status' was not > declared. Should it be static? > usb_storage.c:675:43: warning: Using plain integer as NULL pointer > usb_storage.c:668:5: warning: symbol 'usb_stor_BBB_clear_endpt_stall' was not > declared. Should it be static? > usb_storage.c:679:5: warning: symbol 'usb_stor_BBB_transport' was not > declared. Should it be static? > usb_storage.c:801:5: warning: symbol 'usb_stor_CB_transport' was not > declared. Sh > xyzModem.c:104:1: warning: symbol 'CYGACC_COMM_IF_GETC_TIMEOUT' was not > declared. Should it be static? > xyzModem.c:122:1: warning: symbol 'CYGACC_COMM_IF_PUTC' was not declared. > Should it be static? > xyzModem.c:169:1: warning: symbol 'parse_num' was not declared. Should it be > stat > > note: hush.c's nesting_level deleted because not used. > > Signed-off-by: Kim Phillips This causes problems such as: $ uboot-build.sh netspace_lite_v2 Testing netspace_lite_v2 on -00399-gef44c78 Thu Oct 25 10:31:26 MST 2012 Configuring for netspace_lite_v2 - Board: lacie_kw, Options:NETSPACE_LITE_V2 console.c:537:26: error: static declaration of 'search_device' follows non-static declaration -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-B
Re: [U-Boot] [PATCH 01/32] include/linux/byteorder: import latest endian definitions from linux
On Tue, Oct 16, 2012 at 07:28:17PM -0500, Kim Phillips wrote: > u-boot's byteorder headers did not contain endianness attributions > for use with sparse, causing a lot of false positives. Import the > kernel's latest definitions, and enable them by including compiler.h > and types.h. They come with 'const' added for some swab functions, so > fix those up, too: > > include/linux/byteorder/big_endian.h:46:2: warning: passing argument 1 of > '__swab64p' discards 'const' qualifier from pointer target type [enabled by > default] > > Also, note: u-boot's historic __BYTE_ORDER definition has been > preserved (for the time being at least). > > Signed-off-by: Kim Phillips This causes: $ uboot-build.sh afeb9260 Testing afeb9260 on -00382-g8391387 Thu Oct 25 10:36:06 MST 2012 Configuring for afeb9260 board... textdata bss dec hex filename 1980345648 72652 276334 4376e afeb9260/u-boot macb.c:54:0: warning: "barrier" redefined [enabled by default] .../include/linux/compiler-gcc.h:12:0: note: this is the location of the previous definition -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 00/32] Initial sparse fix series
On Tue, Oct 16, 2012 at 07:28:16PM -0500, Kim Phillips wrote: > This 32-patch series only begins to address making u-boot source more > 'sparseable,' or sparse-clean, ultimately to catch type, address space, > and endianness mismatches and generally improve code quality. E.g., in this > initial dose whose main purpose is to reduce the output volume to workable > levels, a couple of endianness bugs are found and fixed in > of_bus_default_translate() and fdt_get_base_address(). See [PATCH 14/32] > common/fdt_support.c: sparse fixes. I want to repeat myself that I want to see sparse fixes come in. That said, I expect that for v2 you will have done MAKEALL -a $arch for every arch there's an ELDK 5.2.x toolchain for, at least, and there's no new problems popping up. If you like I can pastebin my MAKEALL wrapper that lets you tell it things like --arch arm --eldk-521 and it sets up the environment for the toolchain. I also needed to not apply patch 01/32 and so I can really only take 27 and 32 right now (I'll reply separately once I really do). -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] USB detection
Truncated CCs Hi, On 2012.10/25, Manukumar wrote: > Dear All > > While board bring up in custom board > iam getting below mentioned error > > I2C: ready > DRAM: DDR: failed to read SPD from address It seems you are using a DIMM for your memory (as opposed to directly soldered on the board). Simply put, DDR DIMMs have a small EEPROM which contains data about the device. You access the SPD EEPROM via an I2C address. If the DIMM detection code talks to this address and does not detect correct data, then you have the problem you are encountering. Since you are using a custom board, you should read your specs or ask your HW people about the correct SPD address. > > I googled it but i am un able to rectify it.. > Please resole ASAP > manukumar > All the best, RgC pgpgpFkXy88XO.pgp Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/6] serial: Reorder serial_assign()
Hi, On Mon, Oct 22, 2012 at 10:23 AM, Allen Martin wrote: > On Sat, Oct 20, 2012 at 01:19:00AM -0700, Marek Vasut wrote: >> Dear Allen Martin, >> >> [...] >> > >> > Hi Marek, the change to return value here broke serial output on >> > tegra. What I see is that the serial device name (s->name) is >> > "eserial0" as set by serial_ns16550.c, and the name passed in from the >> > stdout environment is "serial" so they don't match and it fails. This >> > always used to be ok because the return code didn't indicate failure >> > and iomux_doenv() would continue on happily, but now it causes >> > iomux_doenv() to fail and no printfs() work after that. >> > >> > Not sure what the right fix is, should stdout really be set to >> > "eserial0"? It seems "serial" should mean "the default serial device" >> > which for the normal case is the one and only device. >> >> Looking at the source, the obvious course of action is to fix iomux.c . >> > > I've been looking at this call to serial_assign() from iomux.c and I'm > not convinced this code does anything meaningful at all. It passes > the name of a struct stdio_dev device which serial_assign() then tries > to match against the registered struct serial_devices, which will > never match. > > What I don't understand is the case where you have a board that > actually has more than one physical serial port and how the mapping > from stdio_dev to serial_device happens. > > Also, looking at the code to cmd_nvedit, I think your change also broke > "setenv stdout" for boards that don't define CONFIG_CONSOLE_MUX. We > always have this on for tegra, so we don't go down this code path, but > it looks identical to the code in iomux.c Sorry if I missed it - what was the resolution here? Should we revert that change? Regards, Simon > > -Allen > -- > nvpublic > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3 1/5] ARM: fix u-boot.lds for -ffunction-sections/-fdata-sections
On Mon, Oct 22, 2012 at 9:19 AM, Stephen Warren wrote: > From: Stephen Warren > > When -ffunction-sections or -fdata-section are used, symbols are placed > into sections such as .data.eserial1_device and .bss.serial_current. > Update the linker script to explicitly include these. Without this > change (at least with my gcc-4.5.3 built using crosstool-ng), I see that > the sections do end up being included, but __bss_end__ gets set to the > same value as __bss_start. > > Signed-off-by: Stephen Warren > Acked-by: Allen Martin I tested this series on seaboard. Acked-by: Simon Glass Tested-by: Simon Glass Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3 2/5] ARM: enhance u-boot.lds to detect over-sized SPL
On Mon, Oct 22, 2012 at 10:52 AM, Tom Rini wrote: > On Mon, Oct 22, 2012 at 10:19:33AM -0600, Stephen Warren wrote: > >> From: Stephen Warren >> >> Add an ASSERT() to u-boot.lds to detect an SPL that doesn't fit within >> SPL_TEXT_BASE..SPL_MAX_SIZE. >> >> Different .lds files implement this check in two possible ways: >> 1) An ASSERT() like this >> 2) Defining a MEMORY region of size SPL_MAX_SIZE, and re-directing all >>linker output into that region. Since u-boot.lds is used for both >>SPL and main U-Boot, this would entail only sometimes defining a >>MEMORY region, and only sometimes performing that redirection, and >>hence option (1) was deemed much simpler, and hence implemented. >> >> Note that this causes build failures at least for NVIDIA Tegra Seaboard >> and Ventana. However, these are legitimate; the SPL doesn't fit within >> the required space, and this does cause runtime issues. >> >> Signed-off-by: Stephen Warren >> Acked-by: Simon Glass >> Acked-by: Allen Martin I tested this series on seaboard. Tested-by: Simon Glass > > This isn't quite what I envisoned at first (see > arch/arm/cpu/armv7/omap-common/u-boot-spl.lds) but I think for the > generic linker script, this is the least instrusive method. > > Acked-by: Tom Rini > > And since parts 1 and 2 are generic code, I've assigned them to Albert > in patchwork. It's his call if he wants to take them or have them all > come via the tegra tree. > > -- > Tom > > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3 3/5] ARM: tegra: derive CONFIG_SPL_MAX_SIZE instead of hard-coding it
On Mon, Oct 22, 2012 at 9:19 AM, Stephen Warren wrote: > From: Stephen Warren > > For Tegra, the SPL and main U-Boot are concatenated together to form a > single memory image. Hence, the maximum SPL size is the different in > TEXT_BASE for SPL and main U-Boot. Instead of manually calculating > SPL_MAX_SIZE based on those two TEXT_BASE, which can lead to errors if > one TEXT_BASE is changed without updating SPL_MAX_SIZE, simply perform > the calculation automatically. > > Signed-off-by: Stephen Warren > Acked-by: Simon Glass > Acked-by: Allen Martin I tested this series on seaboard. Tested-by: Simon Glass > --- > v3: No change. > v2: New patch. > --- > include/configs/tegra20-common.h |3 ++- > 1 files changed, 2 insertions(+), 1 deletions(-) > > diff --git a/include/configs/tegra20-common.h > b/include/configs/tegra20-common.h > index 70c5cfb..c0c93e5 100644 > --- a/include/configs/tegra20-common.h > +++ b/include/configs/tegra20-common.h > @@ -188,7 +188,8 @@ > #define CONFIG_SPL > #define CONFIG_SPL_NAND_SIMPLE > #define CONFIG_SPL_TEXT_BASE 0x00108000 > -#define CONFIG_SPL_MAX_SIZE0x4000 > +#define CONFIG_SPL_MAX_SIZE(CONFIG_SYS_TEXT_BASE - \ > + CONFIG_SPL_TEXT_BASE) > #define CONFIG_SYS_SPL_MALLOC_START0x0009 > #define CONFIG_SYS_SPL_MALLOC_SIZE 0x0001 > #define CONFIG_SPL_STACK 0x000c > -- > 1.7.0.4 > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3 4/5] ARM: tegra: select between Seaboard/Ventana at compile time
On Mon, Oct 22, 2012 at 9:19 AM, Stephen Warren wrote: > From: Stephen Warren > > Seaboard and Ventana are very similar boards, and so share the seaboard.c > board file. The one difference needed so far is detected at run-time by > calling machine_is_ventana(). This bloats the Ventana build with code > that is never used. Switch to detecting Ventana at compile time to remove > bloat. This shaves ~5K off the SPL size on Ventana, and makes the SPL fit > within the max size. > > Signed-off-by: Stephen Warren I tested this series on seaboard. Acked-by: Simon Glass Tested-by: Simon Glass > --- > v3: Combined back-to-back #ifdefs. > v2: New patch to replace modification of CONFIG_SYS_TEXT_BASE. > --- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3 5/5] ARM: tegra: don't request GPIO from Seaboard's SPL
Hi, On Mon, Oct 22, 2012 at 9:19 AM, Stephen Warren wrote: > From: Stephen Warren > > Seaboard has a GPIO that switches an external mux between Tegra's debug > UART and SPI flash. This is initialized from the SPL so that SPL debug > output can be seen. Simplify the code that does this, and don't actually > request the GPIO in the SPL; just program it. This saves ~4.5K from the > size of the SPL, mostly BSS due to the large gpio_names[] table that is > no longer required. This makes Seaboard's SPL fit within the current max > size. > > Signed-off-by: Stephen Warren > Acked-by: Simon Glass > Acked-by: Allen Martin I tested this series on seaboard. Tested-by: Simon Glass > --- > v3: No change. > v2: New patch to replace modification of CONFIG_SYS_TEXT_BASE. > --- ___ 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 Tue, Oct 23, 2012 at 11:19:29AM -0700, Tom Rini wrote: > Hello, > > The following changes since commit 39826f09978a0a7070999acc15babf88f03e4051: > > arm: fdt: Relocate fdt along with other data (2012-10-19 21:38:27 +0200) > > are available in the git repository at: > > git://git.denx.de/u-boot-ti.git master > > for you to fetch changes up to 6b943a40273f847a29586e6aa0e756f90d75f38f: > > am33xx: Add SPI SPL as an option (2012-10-23 08:34:10 -0700) This has been superseded by another request I will be sending shortly. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 04/20] scsi: Add function and env var to report number of scsi drives
From: Stefan Reinauer
Add a new function to find out the number of available SCSI disks. Also
set the 'scsidevs' environment variable after each scan.
Signed-off-by: Stefan Reinauer
Signed-off-by: Simon Glass
---
Changes in v2:
- Set 'scsidevs' environment variable to number of SCSI disks
README|3 +++
common/cmd_scsi.c |8
include/scsi.h|2 ++
3 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/README b/README
index 69da2b8..801772c 100644
--- a/README
+++ b/README
@@ -1039,6 +1039,9 @@ The following options need to be configured:
devices.
CONFIG_SYS_SCSI_SYM53C8XX_CCF to fix clock timing (80Mhz)
+The environment variable 'scsidevs' is set to the number of
+SCSI devices found during the last scan.
+
- NETWORK Support (PCI):
CONFIG_E1000
Support for Intel 8254x/8257x gigabit chips.
diff --git a/common/cmd_scsi.c b/common/cmd_scsi.c
index 30d8d12..5e7b480 100644
--- a/common/cmd_scsi.c
+++ b/common/cmd_scsi.c
@@ -182,6 +182,14 @@ removable:
scsi_curr_dev=0;
else
scsi_curr_dev = -1;
+
+ printf("Found %d device(s).\n", scsi_max_devs);
+ setenv("scsidevs", scsi_max_devs);
+}
+
+int scsi_get_disk_count(void)
+{
+ return scsi_max_devs;
}
#ifdef CONFIG_PCI
diff --git a/include/scsi.h b/include/scsi.h
index 89ae45f..9681d19 100644
--- a/include/scsi.h
+++ b/include/scsi.h
@@ -189,6 +189,8 @@ void scsi_low_level_init(int busdevfunc);
void scsi_init(void);
void scsi_scan(int mode);
+/** @return the number of scsi disks */
+int scsi_get_disk_count(void);
#define SCSI_IDENTIFY 0xC0 /* not used */
--
1.7.7.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Please pull u-boot-ti/master
Hello, The following changes since commit 39826f09978a0a7070999acc15babf88f03e4051: arm: fdt: Relocate fdt along with other data (2012-10-19 21:38:27 +0200) are available in the git repository at: git://git.denx.de/u-boot-ti.git master for you to fetch changes up to c7d35bef255dedb3ec3856982f042dde514676b0: am33xx/ddr_defs.h: rename DDR2/DDR3 defines to their actual part numbers (2012-10-25 11:31:38 -0700) Andrew Bradford (1): configs: Fix usage of mmc rescan Igor Grinberg (1): cm-t35: clean unused defines from config Joel A Fernandes (1): am33xx: Enable DDR3 for DDR3 version of beaglebone Pankaj Bharadiya (1): USB: musb_udc: Make musb_peri_rx_ep check for MUSB_RXCSR_RXPKTRDY Peter Korsgaard (7): omap3_spi: introduce CONFIG_OMAP3_SPI_D0_D1_SWAPPED am33xx/board.c: make wdtimer/uart_base static am33xx: move ti i2c baseboard header handling to board/ti/am335x/ am33xx/board: use cpu_mmc_init() for default mmc initialization am33xx: move generic parts of pinmux handling out from board/ti/am335x am33xx: support board specific ddr settings am33xx/ddr_defs.h: rename DDR2/DDR3 defines to their actual part numbers Stefano Babic (5): OMAP3: mt_ventoux: power on USB at startup OMAP3: updated pinmux and environment for new revision of mcx board OMAP3: mcx: updated to new hardware revision VIDEO: add macro to set LCD size for DSS driver OMAP3: add video support to the mcx board Tom Rini (2): omapimage: Add support for byteswapped SPI images am33xx: Add SPI SPL as an option Vaibhav Hiremath (1): am335x: Enable RTC 32K OSC clock arch/arm/cpu/armv7/am33xx/Makefile |1 + arch/arm/cpu/armv7/am33xx/board.c| 239 +--- arch/arm/cpu/armv7/am33xx/clock.c|6 + arch/arm/cpu/armv7/am33xx/config.mk |1 + arch/arm/cpu/armv7/am33xx/emif4.c| 114 +--- arch/arm/cpu/armv7/am33xx/mux.c | 33 +++ arch/arm/include/asm/arch-am33xx/cpu.h | 15 + arch/arm/include/asm/arch-am33xx/ddr_defs.h | 69 ++--- arch/arm/include/asm/arch-am33xx/hardware.h |4 + arch/arm/include/asm/arch-am33xx/mux.h | 261 ++ arch/arm/include/asm/arch-am33xx/spl.h |1 + arch/arm/include/asm/arch-am33xx/sys_proto.h | 27 -- arch/arm/include/asm/arch-omap3/dss.h|1 + board/htkw/mcx/mcx.c | 48 +++- board/htkw/mcx/mcx.h | 30 +- board/teejet/mt_ventoux/mt_ventoux.c |8 + board/ti/am335x/Makefile |1 + board/ti/am335x/board.c | 376 ++ board/ti/am335x/board.h | 49 board/ti/am335x/mux.c| 250 + drivers/spi/omap3_spi.c | 11 +- drivers/usb/musb/musb_udc.c | 11 +- include/configs/am335x_evm.h |9 +- include/configs/am3517_crane.h |2 +- include/configs/am3517_evm.h |2 +- include/configs/cm_t35.h | 14 +- include/configs/devkit8000.h |2 +- include/configs/igep00x0.h |2 +- include/configs/mcx.h| 31 ++- include/configs/mx28evk.h|2 +- include/configs/mx51evk.h|2 +- include/configs/mx53ard.h|2 +- include/configs/mx53evk.h|2 +- include/configs/mx53loco.h |2 +- include/configs/mx53smd.h|2 +- include/configs/mx6qarm2.h |2 +- include/configs/mx6qsabrelite.h |2 +- include/configs/omap3_beagle.h |2 +- include/configs/omap3_evm.h |2 +- include/configs/omap3_logic.h|2 +- include/configs/omap3_overo.h|2 +- include/configs/omap3_zoom1.h|2 +- include/configs/omap4_common.h |2 +- include/configs/omap5_evm.h |2 +- include/configs/tricorder.h |2 +- spl/Makefile |9 +- tools/omapimage.c| 83 -- 47 files changed, 998 insertions(+), 744 deletions(-) create mode 100644 arch/arm/cpu/armv7/am33xx/mux.c create mode 100644 arch/arm/include/asm/arch-am33xx/mux.h create mode 100644 board/ti/am335x/board.c create mode 100644 board/ti/am335x/board.h Thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4 V3] kerneldoc: Implant DocBook from Linux kernel
On Tue, Oct 23, 2012 at 04:03:29PM -0500, Andy Fleming wrote: > On Tue, Oct 23, 2012 at 3:58 PM, Tom Rini wrote: > > On Tue, Oct 23, 2012 at 02:56:58PM -0500, Andy Fleming wrote: > >> On Tue, Oct 23, 2012 at 2:30 AM, Marek Vasut wrote: > >> > Dear Andy Fleming, > >> > > >> > [...] > >> > > >> >> This patch makes it so that MAKEALL doesn't build silently anymore: > >> >> > >> >> > >> >> make[1]: Entering directory `/local/afleming/u-boot/doc/DocBook' > >> >> make[1]: Leaving directory `/local/afleming/u-boot/doc/DocBook' > >> >> > >> >> > >> >> Any ideas how we can fix that? > >> > > >> > I thought this was fixed, where do you see it? > >> > > >> > $ BUILD_DIR=/tmp/test ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- > >> > ./MAKEALL m28evk > >> > Configuring for m28evk board... > >> >textdata bss dec hex filename > >> > 4245797784 288876 721239 b0157 /tmp/test/u-boot > >> >6984 760 077441e40 /tmp/test/spl/u-boot-spl > >> > >> > >> Hmm, with the latest tree I get: > >> > >> [afleming@right u-boot (master)]$ ./MAKEALL P2020RDB_NAND > >> Configuring for P2020RDB_NAND - Board: P1_P2_RDB, Options: P2020RDB,NAND > >> make[1]: Entering directory `/local/afleming/u-boot/doc/DocBook' > >> make[1]: Leaving directory `/local/afleming/u-boot/doc/DocBook' > >>textdata bss dec hex filename > >> 399394 16752 267792 683938 a6fa2 ./build/P2020RDB_NAND/u-boot > > > > make --version ? > > GNU Make 3.81 OK, found it, posting a patch now. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] MAKEALL: Add -s to '${MAKE} tidy' section
When BUILD_NBUILDS is > 1 we run the tidy command. With the addition of
DocBook this now includes a -C doc/DocBook and a 'entering/leaving' pair
of messages happen. Since we don't want to see what's being cleaned
here, we can just invoke make -s like we do when building.
Signed-off-by: Tom Rini
---
MAKEALL |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAKEALL b/MAKEALL
index 63f8bef..84a5c92 100755
--- a/MAKEALL
+++ b/MAKEALL
@@ -640,7 +640,7 @@ build_target() {
fi
if [ $BUILD_MANY == 1 ] ; then
- ${MAKE} tidy
+ ${MAKE} -s tidy
if [ -s ${LOG_DIR}/${target}.ERR ] ; then
cp ${LOG_DIR}/${target}.ERR
${OUTPUT_PREFIX}/ERR/${target}
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 00/32] Initial sparse fix series
On Thu, 25 Oct 2012 10:46:54 -0700 Tom Rini wrote: > On Tue, Oct 16, 2012 at 07:28:16PM -0500, Kim Phillips wrote: > > > This 32-patch series only begins to address making u-boot source more > > 'sparseable,' or sparse-clean, ultimately to catch type, address space, > > and endianness mismatches and generally improve code quality. E.g., in this > > initial dose whose main purpose is to reduce the output volume to workable > > levels, a couple of endianness bugs are found and fixed in > > of_bus_default_translate() and fdt_get_base_address(). See [PATCH 14/32] > > common/fdt_support.c: sparse fixes. > > I want to repeat myself that I want to see sparse fixes come in. That > said, I expect that for v2 you will have done MAKEALL -a $arch for every > arch there's an ELDK 5.2.x toolchain for, at least, and there's no new so power, arm, and mips. > problems popping up. If you like I can pastebin my MAKEALL wrapper that > lets you tell it things like --arch arm --eldk-521 and it sets up the > environment for the toolchain. please do. > I also needed to not apply patch 01/32 and so I can really only take 27 > and 32 right now (I'll reply separately once I really do). that's fine, thanks. Kim ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] common/cmd_ext_common: measure throughput
On Wed, Oct 17, 2012 at 12:16:14PM +0200, Andreas Bie??mann wrote:
> Dear Wolfgang Denk,
>
> On 17.10.2012 12:05, Wolfgang Denk wrote:
> > Dear Andreas Bie??mann,
> >
> > In message <1350467910-2014-1-git-send-email-andreas.de...@googlemail.com>
> > you wrote:
> >> This patch adds time measurement and throughput calculation for the
> >> ext2load and
> >> ext4load commands.
> > ...
> >> + unsigned long time_start;
> > ...
> >> + time_start = get_timer(0);
> >>if (ext4fs_read((char *)addr, filelen) != filelen) {
> >>printf("** Unable to read \"%s\" from %s %d:%d **\n",
> >> filename, argv[1], dev, part);
> >>ext4fs_close();
> >>goto fail;
> >>}
> >> + time_start = get_timer(time_start);
> >
> > There, "time_start" is clearly a mis-nomer. How about
> > s/time_start/time/ ?
>
> sounds better, however this is a plane copy from Simons tftp measurement
> patch.
>
> >> + print_size(filelen / time_start * 1000, "/s");
> >
> > Does this give reasonable results for small files, say when loading a
> > 20 byte file ?
>
> Well, possible no:
>
> ---8<---
> U-Boot> ext2load mmc 0 1002 /etc/hosts
> Loading file "/etc/hosts" from mmc device 0:1
> 20 bytes read in 0 ms
> U-Boot> ext2load mmc 0 1002 /etc/shadow
> Loading file "/etc/shadow" from mmc device 0:1
> 95 bytes read in 0 ms
> U-Boot> ext2load mmc 0 1002 /etc/passwd
> Loading file "/etc/passwd" from mmc device 0:1
> 366 bytes read in 0 ms
> U-Boot> ext2load mmc 0 1002 /etc/services
> Loading file "/etc/services" from mmc device 0:1
> 18465 bytes read in 3 ms (5.9 MiB/s)
> U-Boot>
> --->8---
>
> But as you see extremely short transfers are omitted due to time
> difference of '0' (at least on my avr32 system here).
> The main aim for this patch was to measure performance gain of Josh Wu's
> gen_atmel_mci patch for multiple block access, hopefully this is useful
> for others.
> I would like to have some feedback how the measurement is for very small
> files on other systems. Then I could provide a v2 which uses another
> variable name for the time.
I'm fine with not giving a speed on <1 ms transactions. Lets see a v2
with the new variable name, thanks!
--
Tom
signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v9] [RFC] Add dmmalloc module for DM.
Hello Graeme,
On Thu, Oct 25, 2012 at 3:40 AM, Graeme Russ wrote:
>> diff --git a/arch/arm/include/asm/global_data.h
>> b/arch/arm/include/asm/global_data.h
>> index 2b9af93..9045829 100644
>> --- a/arch/arm/include/asm/global_data.h
>> +++ b/arch/arm/include/asm/global_data.h
>> @@ -82,6 +82,9 @@ typedef struct global_data {
>> unsigned long post_log_res; /* success of POST test */
>> unsigned long post_init_f_time; /* When post_init_f started */
>> #endif
>> +#ifdef CONFIG_SYS_EARLY_MALLOC
>> + void*early_heap;/* heap for early_malloc */
>> +#endif
>
> Why not early_heap_header *early_heap; ?
>
It might be.
Actually it is a good point because I am using 3 different ways of
dealing with addresses: 1) struct early_heap header * or struct
early_block_header * - I am using this when I want to access members
of the stucture or compute address past the structure (which is where
the heap or block starts); 2) phys_addr_t - which is plain integer and
I use this for simple computations when I do not want to worry about
pointer arithmetic; 3) void * when I have just plain address,
especially when I want to pass an addres among logical parts of the
mallocator or outside. This may a bit controversial and perhaps I
should replace it by specific strucutre pointers internally.
I am unable to decide: Should I remove struct early_heap_header from
dmmalloc.h making it publicly unavailable or should I rather change
the void * to struct early_heap_header * in the GD structure? What do
you think is better?
> diff --git a/common/Makefile b/common/Makefile
>> index fdfead7..bfb4d7a 100644
>> --- a/common/Makefile
>> +++ b/common/Makefile
>> @@ -209,6 +209,7 @@ COBJS-y += dlmalloc.o
>> COBJS-y += image.o
>> COBJS-y += memsize.o
>> COBJS-y += stdio.o
>> +COBJS-$(CONFIG_DM) += dmmalloc.o
>
> COBJS-$(CONFIG_SYS_EARLY_MALLOC) += dmmalloc.o ?
Oh yes, now it is redundant to #ifdef CONFIG_SYS_EARLY_MALLOC inside
the dmmalloc.c file. I had a plan to extend the dmmalloc.c file by
relocation routines and then it would make sense. But I will shufle
the code a bit in the v10 anyway and we will see if the #ifdefs can
still be reduced.
>> +
>> +#include /* for ROUND_UP */
>> +#include
>> +#include /* for gd_t and gd */
>> +#include /* for phys_addr_t and size_addt_t */
>> +
>> +#include
>> +#include
>> +
>> +#include
>> +
>> +DECLARE_GLOBAL_DATA_PTR;
>> +
>> +#ifdef CONFIG_SYS_EARLY_MALLOC
>
> If you use COBJS-$(CONFIG_SYS_EARLY_MALLOC) += dmmalloc.o in the Makefile,
> you can drop this #ifdef
Yes, that is redundant now.
>
>> +__weak struct early_heap_header *early_brk(size_t size)
>> +{
>> + struct early_heap_header *h;
>> + struct early_block_header *b;
>> +
>> + if (gd->early_heap != NULL)
>> + return NULL;
>> +
>> + h = (struct early_heap_header *)CONFIG_SYS_EARLY_HEAP_ADDR;
>> + b = (struct early_block_header *)(h + 1);
>
> Hmmm, does this really work? I would have thought:
>
> b = (struct early_block_header *)(h + sizeof(struct early_heap_header));
>
> but I could be mistaken
It seems that it works as it is (at least I wrote bunch of tests and I
inspected resulting heaps and it was all right). I believe that since
h is a pointer to the struct early_heap_header then pointer arithmetic
is in effect and h+1 actually means "next element in the array of
struct early_heap_header". Which is the address past the header that
equals beginning of the heap data block. (?)
>> +int early_malloc_active(void)
>> +{
>> + return ((gd->flags & GD_FLG_RELOC) != GD_FLG_RELOC);
>> +}
>
> I think we need another flag - GD_FLG_RELOC gets set before the permanent
> heap is initialised, so there is a window of opportunity where things may
> break
Well, as I wrote in the commit message - this is only a temporary
implementation. I suppose I am going to change this when we have more
coarse initialization flags wired into DM (which I believe we are
going to have it anyway). So now I am just working around "forward
dependency" here.
>
>> +
>> +void early_heap_dump(struct early_heap_header *h)
>> +{
>> + struct early_block_header *b;
>> +
>> + debug("heap: h=%p, h->size=%d\n", h, h->size);
>> +
>> + b = (struct early_block_header *)(h+1);
>> + while ((phys_addr_t)b + sizeof(struct early_block_header)
>> + < (phys_addr_t)h + h->size) {
>> + debug("block: h=%p h->size=%d b=%p b->size=%d
>> b->(used)=%d\n",
>> + h, h->size, b, BLOCK_SIZE(b->size),
>> + BLOCK_USED(b->size));
>> + assert(BLOCK_SIZE(b->size) > 0);
>> + b = (struct early_block_header *)((phys_addr_t)b +
>> + sizeof(struct early_block_header) +
>> + BLOCK_SIZE(b->size));
>> + }
>> + debug("--- heap dump end ---\n");
>> +}
>
> Nice touch, but could we just iterate thr
Re: [U-Boot] [PATCH 2/2] mmc: Split device init to decouple OCR-polling delay
Hi, On Sun, Oct 21, 2012 at 1:12 AM, RgC wrote: > Hi All, > > On 2012.10/20, Simon Glass wrote: >> From: Che-Liang Chiou >> >> Most of time that MMC driver spends on initializing a device is polling >> OCR (operation conditions register). To decouple this polling loop, >> device init is split into two parts: The first part fires the OCR query >> command, and the second part polls the result. So the caller is now no >> longer bound to the OCR-polling delay; he may fire the query, go >> somewhere and then come back later for the result. >> >> To use this, call mmc_set_preinit() on any device which needs this. >> >> This can save significant amounts of time on boot (e.g. 200ms) by >> hiding the MMC init time behind other init. >> > > Please note that this patch has a conflict with the patch from Kim Phillips' > [U-Boot,28/32] drivers/mmc/mmc.c: sparse fixes (191937 in patchworks) > > I had to apply this patch first before patching Kim's modifications which > succeeds with the hunk offsets adjusted. It builds OK with the eldk 5.2.1 > for powerpc. Will test these on an ml507 when I have time. Yes I found the same. In fact Kim's patches don't apply to master for me. co upstream/master Note: checking out 'upstream/master'. You are in 'detached HEAD' state. You can look around, make experimental changes and commit them, and you can discard any commits you make in this state without impacting any branches by performing another checkout. If you want to create a new branch to retain commits you create, you may do so (now or later) by using -b with the checkout command again. Example: git checkout -b new_branch_name HEAD is now at 186fc4d... ColdFire: Add Freescale MCF54418TWR ColdFire development board support ~/u> patch -p1 <~/Downloads/U-Boot-28-32-drivers-mmc-mmc.c-sparse-fixes.patch patching file drivers/mmc/mmc.c Hunk #1 succeeded at 47 with fuzz 2 (offset -87 lines). Hunk #2 succeeded at 109 (offset -92 lines). Hunk #3 succeeded at 153 (offset -92 lines). Hunk #4 succeeded at 346 (offset -92 lines). Hunk #5 succeeded at 417 (offset -92 lines). Hunk #6 succeeded at 438 (offset -92 lines). Hunk #7 succeeded at 503 (offset -92 lines). Hunk #8 succeeded at 567 (offset -92 lines). Hunk #9 succeeded at 589 (offset -92 lines). Hunk #10 succeeded at 611 (offset -92 lines). Hunk #11 succeeded at 681 (offset -92 lines). Hunk #12 succeeded at 702 (offset -92 lines). Hunk #13 succeeded at 841 (offset -92 lines). Hunk #14 succeeded at 859 (offset -92 lines). Hunk #15 succeeded at 1014 (offset -92 lines). Hunk #16 succeeded at 1149 (offset -92 lines). Regards, Simon > > Regards, > Rommel > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 00/32] Initial sparse fix series
On Thu, Oct 25, 2012 at 01:59:45PM -0500, Kim Phillips wrote: > On Thu, 25 Oct 2012 10:46:54 -0700 > Tom Rini wrote: > > > On Tue, Oct 16, 2012 at 07:28:16PM -0500, Kim Phillips wrote: > > > > > This 32-patch series only begins to address making u-boot source more > > > 'sparseable,' or sparse-clean, ultimately to catch type, address space, > > > and endianness mismatches and generally improve code quality. E.g., in > > > this > > > initial dose whose main purpose is to reduce the output volume to workable > > > levels, a couple of endianness bugs are found and fixed in > > > of_bus_default_translate() and fdt_get_base_address(). See [PATCH 14/32] > > > common/fdt_support.c: sparse fixes. > > > > I want to repeat myself that I want to see sparse fixes come in. That > > said, I expect that for v2 you will have done MAKEALL -a $arch for every > > arch there's an ELDK 5.2.x toolchain for, at least, and there's no new > > so power, arm, and mips. Correct. > > problems popping up. If you like I can pastebin my MAKEALL wrapper that > > lets you tell it things like --arch arm --eldk-521 and it sets up the > > environment for the toolchain. > > please do. http://pastebin.com/rkRSL2d3 has it now. It's a little clumsy at times, for example for not-arm (biased, sorry) you need to do uboot-build.sh --arch powerpc --eldk-521 --cpu mpc85xx so that it sets up for arch/powerpc, and then the toolchain and then re-sets itself for cpu/mpc85xx. arch/cpu/soc default to NCPUS=1 NBUILDS=`grep -c processor /proc/cpuinfo` and single board targets default to letting MAKEALL guess right. I'm pretty sure that even on the bigger boxes this is still right. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4 V3] kerneldoc: Implant DocBook from Linux kernel
Dear Tom Rini, [...] > > > make --version ? > > > > GNU Make 3.81 > > OK, found it, posting a patch now. What exactly did you find? I don't see this problem with make 3.81 . 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 3/6] serial: Reorder serial_assign()
Dear Simon Glass, > Hi, > > On Mon, Oct 22, 2012 at 10:23 AM, Allen Martin wrote: > > On Sat, Oct 20, 2012 at 01:19:00AM -0700, Marek Vasut wrote: > >> Dear Allen Martin, > >> > >> [...] > >> > >> > Hi Marek, the change to return value here broke serial output on > >> > tegra. What I see is that the serial device name (s->name) is > >> > "eserial0" as set by serial_ns16550.c, and the name passed in from the > >> > stdout environment is "serial" so they don't match and it fails. This > >> > always used to be ok because the return code didn't indicate failure > >> > and iomux_doenv() would continue on happily, but now it causes > >> > iomux_doenv() to fail and no printfs() work after that. > >> > > >> > Not sure what the right fix is, should stdout really be set to > >> > "eserial0"? It seems "serial" should mean "the default serial device" > >> > which for the normal case is the one and only device. > >> > >> Looking at the source, the obvious course of action is to fix iomux.c . > > > > I've been looking at this call to serial_assign() from iomux.c and I'm > > not convinced this code does anything meaningful at all. It passes > > the name of a struct stdio_dev device which serial_assign() then tries > > to match against the registered struct serial_devices, which will > > never match. > > > > What I don't understand is the case where you have a board that > > actually has more than one physical serial port and how the mapping > > from stdio_dev to serial_device happens. > > > > Also, looking at the code to cmd_nvedit, I think your change also broke > > "setenv stdout" for boards that don't define CONFIG_CONSOLE_MUX. We > > always have this on for tegra, so we don't go down this code path, but > > it looks identical to the code in iomux.c > > Sorry if I missed it - what was the resolution here? Should we revert > that change? Definitelly not. We should fix the iomux.c , possibly by flipping the inequation mark as a short term solution. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Merging device trees at runtime for module-based systems
Dear Daniel, In message <50893633.6070...@gmail.com> you wrote: > > Overwrites must be addressed in the first place. The most common example > is that a more generic part (the module tree) registers all details > about a peripheral up-front but then sets its status to 'disabled'. That > way, the more specific part (the base board tree) can overwrite this > property to 'okay' at wish to enable it and not care for the pre-defined > details. This is also how we do things in our device-trees. Agreed. > > I definitely can see the benefit of such a feature and would be happy > > if you could go forward and implement it. > > Ok then. I guess this should be something that can eventually be merged > back into libfdt? I can't speak for the FDT custodian, but I think this makes a lot of sense. 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 When the bosses talk about improving productivity, they are never talking about themselves. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/6] serial: Reorder serial_assign()
On Thu, Oct 25, 2012 at 12:03:47PM -0700, Marek Vasut wrote: > Dear Simon Glass, > > > Hi, > > > > On Mon, Oct 22, 2012 at 10:23 AM, Allen Martin wrote: > > > On Sat, Oct 20, 2012 at 01:19:00AM -0700, Marek Vasut wrote: > > >> Dear Allen Martin, > > >> > > >> [...] > > >> > > >> > Hi Marek, the change to return value here broke serial output on > > >> > tegra. What I see is that the serial device name (s->name) is > > >> > "eserial0" as set by serial_ns16550.c, and the name passed in from the > > >> > stdout environment is "serial" so they don't match and it fails. This > > >> > always used to be ok because the return code didn't indicate failure > > >> > and iomux_doenv() would continue on happily, but now it causes > > >> > iomux_doenv() to fail and no printfs() work after that. > > >> > > > >> > Not sure what the right fix is, should stdout really be set to > > >> > "eserial0"? It seems "serial" should mean "the default serial device" > > >> > which for the normal case is the one and only device. > > >> > > >> Looking at the source, the obvious course of action is to fix iomux.c . > > > > > > I've been looking at this call to serial_assign() from iomux.c and I'm > > > not convinced this code does anything meaningful at all. It passes > > > the name of a struct stdio_dev device which serial_assign() then tries > > > to match against the registered struct serial_devices, which will > > > never match. > > > > > > What I don't understand is the case where you have a board that > > > actually has more than one physical serial port and how the mapping > > > from stdio_dev to serial_device happens. > > > > > > Also, looking at the code to cmd_nvedit, I think your change also broke > > > "setenv stdout" for boards that don't define CONFIG_CONSOLE_MUX. We > > > always have this on for tegra, so we don't go down this code path, but > > > it looks identical to the code in iomux.c > > > > Sorry if I missed it - what was the resolution here? Should we revert > > that change? > > Definitelly not. We should fix the iomux.c , possibly by flipping the > inequation > mark as a short term solution. Adding Joe Hershberger to cc I think its safe to remove the call to serial_assign() altogether, as it's written now it will always fail. Reading through doc/driver-model/UDM-serial.txt the CONFIG_SERIAL_MULTI case should be handled transparently underneath iomux. The part that still not clear to me is what mechanism is supposed to be used to select the current serial port in a CONFIG_SERIAL_MULTI configuration? AFAICT the only caller of serial_assign() that actually passes the name of a serial device is in serial_initialize(): serial_assign(default_serial_console()->name); Should there be another environemnt variable that maps the stdio_dev "serial" to the current serial_device so you could do something like: ; get input from first serial port and USB keyboard # setenv serial eserial0 # setenv stdin serial,usbkbd ; get input from second serial port and USB keyboard # setenv serial eserial1 # setenv stdin seriak,usbkbd -Allen -- nvpublic ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, 2/6] fdt: Limit printed hex in fdt print and list commands
On Fri, Aug 17, 2012 at 10:34:36AM -, Joe Hershberger wrote: > Prevent printing the entire image in a itb. It is most likely unhelpful > to have the hex of the entire image scroll for minutes on your slow > serial console. > > Signed-off-by: Joe Hershberger This causes: $ uboot-build.sh sandboxTesting sandbox on -4-gf0a29d4 Thu Oct 25 13:59:03 MST 2012 Configuring for sandbox board... textdata bss dec hex filename 1402456332 28472 175049 2abc9 sandbox/u-boot cmd_fdt.c: In function 'print_data': cmd_fdt.c:679:32: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] cmd_fdt.c:691:32: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/6] serial: Reorder serial_assign()
Hi, On Thu, Oct 25, 2012 at 12:03 PM, Marek Vasut wrote: > Dear Simon Glass, > >> Hi, >> >> On Mon, Oct 22, 2012 at 10:23 AM, Allen Martin wrote: >> > On Sat, Oct 20, 2012 at 01:19:00AM -0700, Marek Vasut wrote: >> >> Dear Allen Martin, >> >> >> >> [...] >> >> >> >> > Hi Marek, the change to return value here broke serial output on >> >> > tegra. What I see is that the serial device name (s->name) is >> >> > "eserial0" as set by serial_ns16550.c, and the name passed in from the >> >> > stdout environment is "serial" so they don't match and it fails. This >> >> > always used to be ok because the return code didn't indicate failure >> >> > and iomux_doenv() would continue on happily, but now it causes >> >> > iomux_doenv() to fail and no printfs() work after that. >> >> > >> >> > Not sure what the right fix is, should stdout really be set to >> >> > "eserial0"? It seems "serial" should mean "the default serial device" >> >> > which for the normal case is the one and only device. >> >> >> >> Looking at the source, the obvious course of action is to fix iomux.c . >> > >> > I've been looking at this call to serial_assign() from iomux.c and I'm >> > not convinced this code does anything meaningful at all. It passes >> > the name of a struct stdio_dev device which serial_assign() then tries >> > to match against the registered struct serial_devices, which will >> > never match. >> > >> > What I don't understand is the case where you have a board that >> > actually has more than one physical serial port and how the mapping >> > from stdio_dev to serial_device happens. >> > >> > Also, looking at the code to cmd_nvedit, I think your change also broke >> > "setenv stdout" for boards that don't define CONFIG_CONSOLE_MUX. We >> > always have this on for tegra, so we don't go down this code path, but >> > it looks identical to the code in iomux.c >> >> Sorry if I missed it - what was the resolution here? Should we revert >> that change? > > Definitelly not. We should fix the iomux.c , possibly by flipping the > inequation > mark as a short term solution. OK that's fine. Is someone working on a patch? Regards, Simon > > Best regards, > Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot,3/6] fdt: Add get commands to fdt
On Fri, Aug 17, 2012 at 10:34:37AM -, Joe Hershberger wrote: > Add commands to access data in the fdt. This allows data from a dtb > or itb to be accessed from the shell scripts. > > Signed-off-by: Joe Hershberger This adds: $ uboot-build.sh sandbox Testing sandbox on -00386-g5e8f983 Thu Oct 25 14:07:28 MST 2012 Configuring for sandbox board... textdata bss dec hex filename 1431016424 28488 178013 2b75d sandbox/u-boot cmd_fdt.c: In function 'do_fdt': cmd_fdt.c:378:29: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/6] serial: Reorder serial_assign()
On Thu, Oct 25, 2012 at 02:02:55PM -0700, Simon Glass wrote: > Hi, > > On Thu, Oct 25, 2012 at 12:03 PM, Marek Vasut wrote: > > Dear Simon Glass, > > > >> Hi, > >> > >> On Mon, Oct 22, 2012 at 10:23 AM, Allen Martin wrote: > >> > On Sat, Oct 20, 2012 at 01:19:00AM -0700, Marek Vasut wrote: > >> >> Dear Allen Martin, > >> >> > >> >> [...] > >> >> > >> >> > Hi Marek, the change to return value here broke serial output on > >> >> > tegra. What I see is that the serial device name (s->name) is > >> >> > "eserial0" as set by serial_ns16550.c, and the name passed in from the > >> >> > stdout environment is "serial" so they don't match and it fails. This > >> >> > always used to be ok because the return code didn't indicate failure > >> >> > and iomux_doenv() would continue on happily, but now it causes > >> >> > iomux_doenv() to fail and no printfs() work after that. > >> >> > > >> >> > Not sure what the right fix is, should stdout really be set to > >> >> > "eserial0"? It seems "serial" should mean "the default serial device" > >> >> > which for the normal case is the one and only device. > >> >> > >> >> Looking at the source, the obvious course of action is to fix iomux.c . > >> > > >> > I've been looking at this call to serial_assign() from iomux.c and I'm > >> > not convinced this code does anything meaningful at all. It passes > >> > the name of a struct stdio_dev device which serial_assign() then tries > >> > to match against the registered struct serial_devices, which will > >> > never match. > >> > > >> > What I don't understand is the case where you have a board that > >> > actually has more than one physical serial port and how the mapping > >> > from stdio_dev to serial_device happens. > >> > > >> > Also, looking at the code to cmd_nvedit, I think your change also broke > >> > "setenv stdout" for boards that don't define CONFIG_CONSOLE_MUX. We > >> > always have this on for tegra, so we don't go down this code path, but > >> > it looks identical to the code in iomux.c > >> > >> Sorry if I missed it - what was the resolution here? Should we revert > >> that change? > > > > Definitelly not. We should fix the iomux.c , possibly by flipping the > > inequation > > mark as a short term solution. > > OK that's fine. Is someone working on a patch? > I'll send out my proposal for a patch. Unfortunately I don't have a board with multiple serial ports to correctly test CONFIG_SERIAL_MULTI -Allen -- nvpublic ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/6] serial: Reorder serial_assign()
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/25/12 14:19, Allen Martin wrote: > On Thu, Oct 25, 2012 at 02:02:55PM -0700, Simon Glass wrote: >> Hi, >> >> On Thu, Oct 25, 2012 at 12:03 PM, Marek Vasut >> wrote: >>> Dear Simon Glass, >>> Hi, On Mon, Oct 22, 2012 at 10:23 AM, Allen Martin wrote: > On Sat, Oct 20, 2012 at 01:19:00AM -0700, Marek Vasut > wrote: >> Dear Allen Martin, >> >> [...] >> >>> Hi Marek, the change to return value here broke serial >>> output on tegra. What I see is that the serial device >>> name (s->name) is "eserial0" as set by >>> serial_ns16550.c, and the name passed in from the >>> stdout environment is "serial" so they don't match and >>> it fails. This always used to be ok because the >>> return code didn't indicate failure and iomux_doenv() >>> would continue on happily, but now it causes >>> iomux_doenv() to fail and no printfs() work after >>> that. >>> >>> Not sure what the right fix is, should stdout really be >>> set to "eserial0"? It seems "serial" should mean "the >>> default serial device" which for the normal case is the >>> one and only device. >> >> Looking at the source, the obvious course of action is to >> fix iomux.c . > > I've been looking at this call to serial_assign() from > iomux.c and I'm not convinced this code does anything > meaningful at all. It passes the name of a struct > stdio_dev device which serial_assign() then tries to match > against the registered struct serial_devices, which will > never match. > > What I don't understand is the case where you have a board > that actually has more than one physical serial port and > how the mapping from stdio_dev to serial_device happens. > > Also, looking at the code to cmd_nvedit, I think your > change also broke "setenv stdout" for boards that don't > define CONFIG_CONSOLE_MUX. We always have this on for > tegra, so we don't go down this code path, but it looks > identical to the code in iomux.c Sorry if I missed it - what was the resolution here? Should we revert that change? >>> >>> Definitelly not. We should fix the iomux.c , possibly by >>> flipping the inequation mark as a short term solution. >> >> OK that's fine. Is someone working on a patch? >> > > I'll send out my proposal for a patch. Unfortunately I don't have > a board with multiple serial ports to correctly test > CONFIG_SERIAL_MULTI Andrew's recent set of patches for am335x means I do. If I follow correctly, you're describing the case where >1 port for a driver is known, we default to say 0 but want to use 1, via the env? - -- Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQIcBAEBAgAGBQJQia68AAoJENk4IS6UOR1W4NYP/jlbMsXtRojPz7FOVdVSUV+K OK3Pgzc0RD1LMREnHJGRrH42Y5k9s2op0eex/yRLGVjpdyQuM8MykvJ944pDihwX +0Rw8z3oNDg1IeB3R2cgwVCH5vBRGARxr/WdvCQc51uaMDZLwwWM3smHfTvDEeeJ bYIUH9JrAjkpq7DBYCSTq9FR91iJ7hMbLaJjULQaG4Fo64ZBG9A4Llf6+hotADEd 3rHrQN8mJNuYiUYmdbP3B94NNp9+hWXb6r10I8vj2Bb331tBqCHGPOWF4U2h9D2j AHofm8hj22SDTiXNR4SRfGSjqWqc8ZrocaoKxjBTnvlqxgN9+o/w+JNogCJcJ07y zNn73DdxiztgDvoRzWz7oYiI2jF5KGAXVjPRTkY6P5v8Ybh8QF+/CX3NaHjlO7GX VvK3s9AOMqyVz69EZX0OVnaL47WEaz21cG3pA2u595/5kNKrrEbUDEc6tNzLg+vy 5ah1P/g1kqNmKIgN4UtYSKCjCRA4vC5gHs4ixqhPw31aI54YnkbMq/y0SVhvd7Fk iBpsojMQnuHPwRNLtfffqKtkcSMuTxrk2U90KXMg9DSm3cOqPXZgFwfaZH8GXUAV W0Oo7QKpzgoEY4Qm0TjME2/BA/xGh7fBqiu3SAQuE89+w9rGEpQamCkuFFEKYKRt YjHt4C0QHEjwb4kqkINx =D41e -END PGP SIGNATURE- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/6] serial: Reorder serial_assign()
On Thu, Oct 25, 2012 at 02:27:24PM -0700, Tom Rini wrote: > * PGP Signed by an unknown key > > On 10/25/12 14:19, Allen Martin wrote: > > On Thu, Oct 25, 2012 at 02:02:55PM -0700, Simon Glass wrote: > >> Hi, > >> > >> On Thu, Oct 25, 2012 at 12:03 PM, Marek Vasut > >> wrote: > >>> Dear Simon Glass, > >>> > Hi, > > On Mon, Oct 22, 2012 at 10:23 AM, Allen Martin > wrote: > > On Sat, Oct 20, 2012 at 01:19:00AM -0700, Marek Vasut > > wrote: > >> Dear Allen Martin, > >> > >> [...] > >> > >>> Hi Marek, the change to return value here broke serial > >>> output on tegra. What I see is that the serial device > >>> name (s->name) is "eserial0" as set by > >>> serial_ns16550.c, and the name passed in from the > >>> stdout environment is "serial" so they don't match and > >>> it fails. This always used to be ok because the > >>> return code didn't indicate failure and iomux_doenv() > >>> would continue on happily, but now it causes > >>> iomux_doenv() to fail and no printfs() work after > >>> that. > >>> > >>> Not sure what the right fix is, should stdout really be > >>> set to "eserial0"? It seems "serial" should mean "the > >>> default serial device" which for the normal case is the > >>> one and only device. > >> > >> Looking at the source, the obvious course of action is to > >> fix iomux.c . > > > > I've been looking at this call to serial_assign() from > > iomux.c and I'm not convinced this code does anything > > meaningful at all. It passes the name of a struct > > stdio_dev device which serial_assign() then tries to match > > against the registered struct serial_devices, which will > > never match. > > > > What I don't understand is the case where you have a board > > that actually has more than one physical serial port and > > how the mapping from stdio_dev to serial_device happens. > > > > Also, looking at the code to cmd_nvedit, I think your > > change also broke "setenv stdout" for boards that don't > > define CONFIG_CONSOLE_MUX. We always have this on for > > tegra, so we don't go down this code path, but it looks > > identical to the code in iomux.c > > Sorry if I missed it - what was the resolution here? Should > we revert that change? > >>> > >>> Definitelly not. We should fix the iomux.c , possibly by > >>> flipping the inequation mark as a short term solution. > >> > >> OK that's fine. Is someone working on a patch? > >> > > > > I'll send out my proposal for a patch. Unfortunately I don't have > > a board with multiple serial ports to correctly test > > CONFIG_SERIAL_MULTI > > Andrew's recent set of patches for am335x means I do. If I follow > correctly, you're describing the case where >1 port for a driver is > known, we default to say 0 but want to use 1, via the env? Yes, exactly. I assume that's what the current calls to serial_assign() were supposed to be doing, but weren't. -Allen -- nvpublic ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/3] Bring in new I2C framework
Hi Heiko, On Mon, Oct 22, 2012 at 10:40 AM, Heiko Schocher wrote: > rebased/reworked the I2C multibus patches from Simon Glass found > here: > > http://www.mail-archive.com/u-boot@lists.denx.de/msg75530.html > > It seems the timing is coming, to bring this in mainline and > move boards over to the new i2c framework. As an example I > converted the soft-i2c driver (and all boards using it) to > the new framework, so this patchseries has to be tested > intensively, as I can check compile only ... I am very happy to see this, thank you. I have brought this in and tried to get it running for Tegra. A few points: 1. The methods in struct i2c_adapter should IMO be passed a struct i2c_adapter *, so they can determine which adapter is being accessed. Otherwise I can't see how they would know. 2. The init is a bit odd, in that we can call init() repeatedly. Perhaps that function should be renamed to reset, and the init should be used for calling just once at the start? 3. Rather than each device having to call i2c_get_bus_num() to find out what bus is referred to, why not just pass this information in? In fact the adapter pointer can serve for this. 4. So perhaps the i2c read/write functions should change from: int i2c_read(uchar chip, uint addr, int alen, uchar *buffer, int len) to: int i2c_read((struct i2c_adapter *adapter, uint addr, int alen, uchar *buffer, int len) Later, I wonder whether the concept of a 'current' i2c bus should be maintained by the command line interpreter, rather than the i2c system. Because to be honest, most of the drivers I see have to save the current bus number, set the current bus, do the operation, then set the bus back how they found it (to preserve whatever the user things is the current bus). Granted there is overhead with i2c muxes, but the i2c core can remember the state of these muxes and doesn't have to switch things until there has been a change since the last transaction. This last suggestion can be dealt with later, but I thought I would bring it up. Regards, Simon > > Cc: Simon Glass > Cc: Piotr Wilczek > > Heiko Schocher (3): > i2c: add i2c_core and prepare for new multibus support > i2c: common changes for multibus/multiadapter support > i2c, soft-i2c: switch to new multibus/multiadapter support > > README| 89 +++- > arch/arm/include/asm/global_data.h|3 + > arch/arm/lib/board.c | 15 +- > arch/avr32/include/asm/global_data.h |3 + > arch/blackfin/include/asm/global_data.h |4 +- > arch/blackfin/lib/board.c |7 + > arch/m68k/include/asm/global_data.h |3 + > arch/m68k/lib/board.c | 15 +- > arch/microblaze/include/asm/global_data.h |3 + > arch/mips/include/asm/global_data.h |3 + > arch/mips/lib/board.c |7 + > arch/nds32/include/asm/global_data.h |3 + > arch/nds32/lib/board.c| 10 +- > arch/nios2/include/asm/global_data.h |3 + > arch/powerpc/cpu/mpc8xx/video.c |4 + > arch/powerpc/include/asm/global_data.h|3 + > arch/powerpc/lib/board.c | 16 +- > arch/sh/include/asm/global_data.h |3 + > arch/sparc/include/asm/global_data.h |3 + > arch/x86/include/asm/global_data.h|3 + > board/BuS/eb_cpux9k2/cpux9k2.c|2 +- > board/BuS/vl_ma2sc/vl_ma2sc.c |2 +- > board/atc/atc.c |2 +- > board/bluewater/snapper9260/snapper9260.c |2 +- > board/cm5200/cm5200.c |4 +- > board/cpu86/cpu86.c |2 +- > board/cpu87/cpu87.c |2 +- > board/emk/top9000/top9000.c |8 +- > board/eukrea/cpuat91/cpuat91.c|2 +- > board/freescale/m52277evb/README |2 +- > board/freescale/m53017evb/README |2 +- > board/freescale/m5373evb/README |2 +- > board/freescale/m54455evb/README |2 +- > board/freescale/m547xevb/README |2 +- > board/ids8247/ids8247.c |2 +- > board/keymile/common/common.c |3 +- > board/keymile/common/ivm.c| 15 +- > board/keymile/km82xx/km82xx.c |2 +- > board/keymile/km_arm/km_arm.c |8 +- > board/lwmon/lwmon.c |2 +- > board/lwmon/pcmcia.c |4 +- > board/pm826/pm826.c |2 +- > board/pm828/pm828.c |2 +- > board/sacsng/ioconfig.h |2 +- > board/sandburst/karef/karef.c |1 - > board/siemens/SCM/scm.c |2 +- > board/tqc/tqm8260/tqm8260.c |2 +- > board/tqc/tqm8272/tqm8272.c |2 +- > board/tqc/tqm8272/tqm8272.h |2 +- > common/cmd_da
[U-Boot] [PATCH] serial: add environment control for SERIAL_MULTI
Add a new special environment variable "serial" that allows selection
of serial device when CONFIG_SERIAL_MULTI is defined. This replaces
the existing calls to serial_assign() from cmd_nvedit.c and iomux.c
that were not doing anything.
Signed-off-by: Allen Martin
---
common/cmd_nvedit.c |7 ++-
common/iomux.c | 10 --
doc/driver-model/UDM-serial.txt |5 +++--
3 files changed, 9 insertions(+), 13 deletions(-)
diff --git a/common/cmd_nvedit.c b/common/cmd_nvedit.c
index 1f9c674..d1ee07d 100644
--- a/common/cmd_nvedit.c
+++ b/common/cmd_nvedit.c
@@ -238,11 +238,16 @@ int env_check_apply(const char *name, const char *oldval,
/* Try assigning specified device */
if (console_assign(console, newval) < 0)
return 1;
+#endif /* CONFIG_CONSOLE_MUX */
+ }
+#ifdef CONFIG_SERIAL_MULTI
+ /* Check for serial redirection */
+ if (strcmp(name, "serial") == 0) {
if (serial_assign(newval) < 0)
return 1;
-#endif /* CONFIG_CONSOLE_MUX */
}
+#endif /* CONFIG_SERIAL_MULTI */
/*
* Some variables like "ethaddr" and "serial#" can be set only once and
diff --git a/common/iomux.c b/common/iomux.c
index dbc2312..6a75704 100644
--- a/common/iomux.c
+++ b/common/iomux.c
@@ -135,16 +135,6 @@ int iomux_doenv(const int console, const char *arg)
*/
if (console_assign(console, start[j]) < 0)
continue;
- /*
-* This was taken from common/cmd_nvedit.c.
-* This will never work because serial_assign() returns
-* 1 upon error, not -1.
-* This would almost always return an error anyway because
-* serial_assign() expects the name of a serial device, like
-* serial_smc, but the user generally only wants to set serial.
-*/
- if (serial_assign(start[j]) < 0)
- continue;
cons_set[cs_idx++] = dev;
}
free(console_args);
diff --git a/doc/driver-model/UDM-serial.txt b/doc/driver-model/UDM-serial.txt
index 9feb2e5..66f3e6b 100644
--- a/doc/driver-model/UDM-serial.txt
+++ b/doc/driver-model/UDM-serial.txt
@@ -26,8 +26,9 @@ and serial_setbrg() are often called from platform-dependent
places.
It's important to consider current implementation of CONFIG_SERIAL_MULTI
though.
This resides in common/serial.c and behaves as a multiplexer for serial ports.
This, by calling serial_assign(), allows user to switch I/O from one serial
port
-to another. Though the environmental variables "stdin", "stdout", "stderr"
-remain set to "serial".
+to another. The environment variable "serial" is used to select which of the
+serial ports is the currently active port. The environmental variables
+"stdin", "stdout", "stderr" remain set to "serial".
These variables are managed by the IOMUX. This resides in common/iomux.c and
manages all console input/output from U-Boot. For serial port, only one IOMUX
is
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] serial: add environment control for SERIAL_MULTI
Dear Allen Martin,
> Add a new special environment variable "serial" that allows selection
> of serial device when CONFIG_SERIAL_MULTI is defined. This replaces
> the existing calls to serial_assign() from cmd_nvedit.c and iomux.c
> that were not doing anything.
>
> Signed-off-by: Allen Martin
> ---
> common/cmd_nvedit.c |7 ++-
> common/iomux.c | 10 --
> doc/driver-model/UDM-serial.txt |5 +++--
> 3 files changed, 9 insertions(+), 13 deletions(-)
>
> diff --git a/common/cmd_nvedit.c b/common/cmd_nvedit.c
> index 1f9c674..d1ee07d 100644
> --- a/common/cmd_nvedit.c
> +++ b/common/cmd_nvedit.c
> @@ -238,11 +238,16 @@ int env_check_apply(const char *name, const char
> *oldval, /* Try assigning specified device */
> if (console_assign(console, newval) < 0)
> return 1;
> +#endif /* CONFIG_CONSOLE_MUX */
> + }
>
> +#ifdef CONFIG_SERIAL_MULTI
Drop this, it's default. There's no CONFIG_SERIAL_MULTI in the tree at all
anymore.
> + /* Check for serial redirection */
> + if (strcmp(name, "serial") == 0) {
> if (serial_assign(newval) < 0)
> return 1;
> -#endif /* CONFIG_CONSOLE_MUX */
> }
> +#endif /* CONFIG_SERIAL_MULTI */
>
> /*
>* Some variables like "ethaddr" and "serial#" can be set only once and
> diff --git a/common/iomux.c b/common/iomux.c
> index dbc2312..6a75704 100644
> --- a/common/iomux.c
> +++ b/common/iomux.c
> @@ -135,16 +135,6 @@ int iomux_doenv(const int console, const char *arg)
>*/
> if (console_assign(console, start[j]) < 0)
> continue;
> - /*
> - * This was taken from common/cmd_nvedit.c.
> - * This will never work because serial_assign() returns
> - * 1 upon error, not -1.
> - * This would almost always return an error anyway because
> - * serial_assign() expects the name of a serial device, like
> - * serial_smc, but the user generally only wants to set serial.
> - */
> - if (serial_assign(start[j]) < 0)
> - continue;
> cons_set[cs_idx++] = dev;
> }
> free(console_args);
> diff --git a/doc/driver-model/UDM-serial.txt
> b/doc/driver-model/UDM-serial.txt index 9feb2e5..66f3e6b 100644
> --- a/doc/driver-model/UDM-serial.txt
> +++ b/doc/driver-model/UDM-serial.txt
> @@ -26,8 +26,9 @@ and serial_setbrg() are often called from
> platform-dependent places. It's important to consider current
> implementation of CONFIG_SERIAL_MULTI though. This resides in
> common/serial.c and behaves as a multiplexer for serial ports. This, by
> calling serial_assign(), allows user to switch I/O from one serial port
> -to another. Though the environmental variables "stdin", "stdout",
> "stderr" -remain set to "serial".
> +to another. The environment variable "serial" is used to select which of
> the +serial ports is the currently active port. The environmental
> variables +"stdin", "stdout", "stderr" remain set to "serial".
>
> These variables are managed by the IOMUX. This resides in common/iomux.c
> and manages all console input/output from U-Boot. For serial port, only
> one IOMUX is
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] serial: add environment control for SERIAL_MULTI
On Thu, Oct 25, 2012 at 02:59:50PM -0700, Allen Martin wrote: > Add a new special environment variable "serial" that allows selection > of serial device when CONFIG_SERIAL_MULTI is defined. This replaces > the existing calls to serial_assign() from cmd_nvedit.c and iomux.c > that were not doing anything. > > Signed-off-by: Allen Martin Two things. First, should I or should I not need to have CONFIG_CONSOLE_MUX set? If I set it, adding serial=eserial3 to my default environment switches from eserial0 to eserial3 when we get to that point in the boot, otherwise I do have to manually setenv serial eserial3 for anything to happen. And the second thing, I can't get any output on the other UART, either way. It goes away from eserial0 but nothing ever shows up to eserial3 (the easiest one here to test). -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] serial: add environment control for SERIAL_MULTI
Hi Allen,
On Thu, Oct 25, 2012 at 4:59 PM, Allen Martin wrote:
> Add a new special environment variable "serial" that allows selection
> of serial device when CONFIG_SERIAL_MULTI is defined. This replaces
> the existing calls to serial_assign() from cmd_nvedit.c and iomux.c
> that were not doing anything.
>
> Signed-off-by: Allen Martin
> ---
> common/cmd_nvedit.c |7 ++-
> common/iomux.c | 10 --
> doc/driver-model/UDM-serial.txt |5 +++--
> 3 files changed, 9 insertions(+), 13 deletions(-)
>
> diff --git a/common/cmd_nvedit.c b/common/cmd_nvedit.c
> index 1f9c674..d1ee07d 100644
> --- a/common/cmd_nvedit.c
> +++ b/common/cmd_nvedit.c
> @@ -238,11 +238,16 @@ int env_check_apply(const char *name, const char
> *oldval,
> /* Try assigning specified device */
> if (console_assign(console, newval) < 0)
> return 1;
> +#endif /* CONFIG_CONSOLE_MUX */
> + }
>
> +#ifdef CONFIG_SERIAL_MULTI
> + /* Check for serial redirection */
> + if (strcmp(name, "serial") == 0) {
> if (serial_assign(newval) < 0)
> return 1;
> -#endif /* CONFIG_CONSOLE_MUX */
> }
> +#endif /* CONFIG_SERIAL_MULTI */
Changes to this directly conflict with the environment callback series
I sent out RFC (soon be be a real series). Can we hold off on this
until that happens?
> /*
> * Some variables like "ethaddr" and "serial#" can be set only once
> and
> diff --git a/common/iomux.c b/common/iomux.c
> index dbc2312..6a75704 100644
> --- a/common/iomux.c
> +++ b/common/iomux.c
> @@ -135,16 +135,6 @@ int iomux_doenv(const int console, const char *arg)
> */
> if (console_assign(console, start[j]) < 0)
> continue;
> - /*
> -* This was taken from common/cmd_nvedit.c.
> -* This will never work because serial_assign() returns
> -* 1 upon error, not -1.
> -* This would almost always return an error anyway because
> -* serial_assign() expects the name of a serial device, like
> -* serial_smc, but the user generally only wants to set
> serial.
> -*/
> - if (serial_assign(start[j]) < 0)
> - continue;
> cons_set[cs_idx++] = dev;
> }
> free(console_args);
> diff --git a/doc/driver-model/UDM-serial.txt b/doc/driver-model/UDM-serial.txt
> index 9feb2e5..66f3e6b 100644
> --- a/doc/driver-model/UDM-serial.txt
> +++ b/doc/driver-model/UDM-serial.txt
> @@ -26,8 +26,9 @@ and serial_setbrg() are often called from
> platform-dependent places.
> It's important to consider current implementation of CONFIG_SERIAL_MULTI
> though.
> This resides in common/serial.c and behaves as a multiplexer for serial
> ports.
> This, by calling serial_assign(), allows user to switch I/O from one serial
> port
> -to another. Though the environmental variables "stdin", "stdout", "stderr"
> -remain set to "serial".
> +to another. The environment variable "serial" is used to select which of the
> +serial ports is the currently active port. The environmental variables
> +"stdin", "stdout", "stderr" remain set to "serial".
>
> These variables are managed by the IOMUX. This resides in common/iomux.c and
> manages all console input/output from U-Boot. For serial port, only one
> IOMUX is
> --
> 1.7.10.4
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] powerpc/85xx: implement check for erratum A-004849 work-around
The work-around for erratum A-004849 ("CoreNet fabric (CCF) can exhibit a
deadlock under certain traffic patterns causing the system to hang") is
implemented via the PBI (pre-boot initialization code, typically attached
to the RCW binary). This is because the work-around is easier to implement
in PBI than in U-Boot itself.
It is still useful, however, for the 'errata' command to tell us whether
the work-around has been applied. For A-004849, we can do this by verifying
that the values in the specific registers that the work-around says to
update.
Signed-off-by: Timur Tabi
---
arch/powerpc/cpu/mpc85xx/cmd_errata.c | 63 +
arch/powerpc/include/asm/config_mpc85xx.h |3 +
2 files changed, 66 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/cpu/mpc85xx/cmd_errata.c
b/arch/powerpc/cpu/mpc85xx/cmd_errata.c
index 2be192d..ccfad56 100644
--- a/arch/powerpc/cpu/mpc85xx/cmd_errata.c
+++ b/arch/powerpc/cpu/mpc85xx/cmd_errata.c
@@ -25,6 +25,65 @@
#include
#include
+#ifdef CONFIG_SYS_FSL_ERRATUM_A004849
+/*
+ * This work-around is implemented in PBI, so just check to see if the
+ * work-around was actually applied. To do this, we check for specific data
+ * at specific addresses in DCSR.
+ *
+ * Array offsets[] contains a list of offsets within DCSR. According to the
+ * erratum document, the value at each offset should be 2.
+ */
+static void check_erratum_a4849(uint32_t svr)
+{
+ void __iomem *dcsr = (void *)CONFIG_SYS_DCSRBAR + 0xb;
+ unsigned int i;
+
+#if defined(CONFIG_PPC_P2041) || defined(CONFIG_PPC_P3041)
+ static const uint8_t offsets[] = {
+ 0x50, 0x54, 0x58, 0x90, 0x94, 0x98
+ };
+#endif
+#ifdef CONFIG_PPC_P4080
+ static const uint8_t offsets[] = {
+ 0x60, 0x64, 0x68, 0x6c, 0xa0, 0xa4, 0xa8, 0xac
+ };
+#endif
+ uint32_t x108; /* The value that should be at offset 0x108 */
+
+ for (i = 0; i < ARRAY_SIZE(offsets); i++) {
+ if (in_be32(dcsr + offsets[i]) != 2) {
+ printf("Work-around for Erratum A004849 is not
enabled\n");
+ return;
+ }
+ }
+
+#if defined(CONFIG_PPC_P2041) || defined(CONFIG_PPC_P3041)
+ x108 = 0x12;
+#endif
+
+#ifdef CONFIG_PPC_P4080
+ /*
+* For P4080, the erratum document says that the value at offset 0x108
+* should be 0x12 on rev2, or 0x1c on rev3.
+*/
+ if (SVR_MAJ(svr) == 2)
+ x108 = 0x12;
+ if (SVR_MAJ(svr) == 3)
+ x108 = 0x1c;
+#endif
+
+ if (in_be32(dcsr + 0x108) != x108) {
+ printf("Work-around for Erratum A004849 is not enabled\n");
+ return;
+ }
+
+ /* Everything matches, so the erratum work-around was applied */
+
+ printf("Work-around for Erratum A004849 enabled\n");
+}
+#endif
+
static int do_errata(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
{
#ifdef CONFIG_SYS_FSL_ERRATUM_NMG_CPU_A011
@@ -137,6 +196,10 @@ static int do_errata(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
#ifdef CONFIG_SYS_FSL_ERRATUM_A_004934
puts("Work-around for Erratum A004934 enabled\n");
#endif
+#ifdef CONFIG_SYS_FSL_ERRATUM_A004849
+ /* This work-around is implemented in PBI, so just check for it */
+ check_erratum_a4849(svr);
+#endif
return 0;
}
diff --git a/arch/powerpc/include/asm/config_mpc85xx.h
b/arch/powerpc/include/asm/config_mpc85xx.h
index 03baaee..3bde0f4 100644
--- a/arch/powerpc/include/asm/config_mpc85xx.h
+++ b/arch/powerpc/include/asm/config_mpc85xx.h
@@ -343,6 +343,7 @@
#define CONFIG_SYS_FSL_ERRATUM_A004510_SVR_REV20x11
#define CONFIG_SYS_FSL_CORENET_SNOOPVEC_COREONLY 0xf000
#define CONFIG_SYS_FSL_ERRATUM_SRIO_A004034
+#define CONFIG_SYS_FSL_ERRATUM_A004849
#elif defined(CONFIG_PPC_P3041)
#define CONFIG_SYS_FSL_QORIQ_CHASSIS1
@@ -375,6 +376,7 @@
#define CONFIG_SYS_FSL_ERRATUM_A004510_SVR_REV20x11
#define CONFIG_SYS_FSL_CORENET_SNOOPVEC_COREONLY 0xf000
#define CONFIG_SYS_FSL_ERRATUM_SRIO_A004034
+#define CONFIG_SYS_FSL_ERRATUM_A004849
#elif defined(CONFIG_PPC_P4080) /* also supports P4040 */
#define CONFIG_SYS_FSL_QORIQ_CHASSIS1
@@ -417,6 +419,7 @@
#define CONFIG_SYS_FSL_ERRATUM_A004510_SVR_REV 0x20
#define CONFIG_SYS_FSL_CORENET_SNOOPVEC_COREONLY 0xff00
#define CONFIG_SYS_FSL_ERRATUM_SRIO_A004034
+#define CONFIG_SYS_FSL_ERRATUM_A004849
#elif defined(CONFIG_PPC_P5020) /* also supports P5010 */
#define CONFIG_SYS_PPC64 /* 64-bit core */
--
1.7.3.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/6] serial: Reorder serial_assign()
Hi Allen, On Thu, Oct 25, 2012 at 4:19 PM, Allen Martin wrote: > On Thu, Oct 25, 2012 at 02:02:55PM -0700, Simon Glass wrote: >> Hi, >> >> On Thu, Oct 25, 2012 at 12:03 PM, Marek Vasut wrote: >> > Dear Simon Glass, >> > >> >> Hi, >> >> >> >> On Mon, Oct 22, 2012 at 10:23 AM, Allen Martin wrote: >> >> > On Sat, Oct 20, 2012 at 01:19:00AM -0700, Marek Vasut wrote: >> >> >> Dear Allen Martin, >> >> >> >> >> >> [...] >> >> >> >> >> >> > Hi Marek, the change to return value here broke serial output on >> >> >> > tegra. What I see is that the serial device name (s->name) is >> >> >> > "eserial0" as set by serial_ns16550.c, and the name passed in from >> >> >> > the >> >> >> > stdout environment is "serial" so they don't match and it fails. >> >> >> > This >> >> >> > always used to be ok because the return code didn't indicate failure >> >> >> > and iomux_doenv() would continue on happily, but now it causes >> >> >> > iomux_doenv() to fail and no printfs() work after that. >> >> >> > >> >> >> > Not sure what the right fix is, should stdout really be set to >> >> >> > "eserial0"? It seems "serial" should mean "the default serial >> >> >> > device" >> >> >> > which for the normal case is the one and only device. >> >> >> >> >> >> Looking at the source, the obvious course of action is to fix iomux.c . >> >> > >> >> > I've been looking at this call to serial_assign() from iomux.c and I'm >> >> > not convinced this code does anything meaningful at all. It passes >> >> > the name of a struct stdio_dev device which serial_assign() then tries >> >> > to match against the registered struct serial_devices, which will >> >> > never match. >> >> > >> >> > What I don't understand is the case where you have a board that >> >> > actually has more than one physical serial port and how the mapping >> >> > from stdio_dev to serial_device happens. >> >> > >> >> > Also, looking at the code to cmd_nvedit, I think your change also broke >> >> > "setenv stdout" for boards that don't define CONFIG_CONSOLE_MUX. We >> >> > always have this on for tegra, so we don't go down this code path, but >> >> > it looks identical to the code in iomux.c >> >> >> >> Sorry if I missed it - what was the resolution here? Should we revert >> >> that change? >> > >> > Definitelly not. We should fix the iomux.c , possibly by flipping the >> > inequation >> > mark as a short term solution. >> >> OK that's fine. Is someone working on a patch? >> > > I'll send out my proposal for a patch. Unfortunately I don't have a > board with multiple serial ports to correctly test CONFIG_SERIAL_MULTI One of the boards I'm working on does this (has more than one). At least before the serial rework from Marek, the stdout was either the serial device directly (each serial device was added as a console device as well) so the serial setting was redundant. You could just set them directly to the serial port (which is more flexible). I had two patches (not sent to ML before Marek made them highly conflicting) that take the opposite approach you were, since it preserves the flexibility. It removed the "serial" setting to each of the std* variables and instead sets it to the default serial device. I'll remake that patch on top of the new serial landscape sometime soon. -Joe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] serial: add environment control for SERIAL_MULTI
On 10/25/2012 03:59 PM, Allen Martin wrote: > Add a new special environment variable "serial" that allows selection > of serial device when CONFIG_SERIAL_MULTI is defined. This replaces > the existing calls to serial_assign() from cmd_nvedit.c and iomux.c > that were not doing anything. So I think this requires (for example) the following environment variables: stdout=serial serial=eserial0 Is it possible to allow the following instead: stdout=eserial0 That way, one could presumably set: stdout=eserial0,eserial3 and hence allow the use of multiple serial consoles? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] serial: add environment control for SERIAL_MULTI
On 10/25/2012 04:36 PM, Joe Hershberger wrote: > Hi Allen, > > On Thu, Oct 25, 2012 at 4:59 PM, Allen Martin wrote: >> Add a new special environment variable "serial" that allows selection >> of serial device when CONFIG_SERIAL_MULTI is defined. This replaces >> the existing calls to serial_assign() from cmd_nvedit.c and iomux.c >> that were not doing anything. ... > Changes to this directly conflict with the environment callback series > I sent out RFC (soon be be a real series). Can we hold off on this > until that happens? The problem here is that serial output on Tegra simply doesn't work (after some point in boot?) without this patch. It seems better to get everything working before adding new features doesn't it? Otherwise, if the environment callback stuff (or any other change right now) breaks something Tegra-specific, there would be no way to identify which change broke it. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] serial: add environment control for SERIAL_MULTI
Hi Stephen, On Thu, Oct 25, 2012 at 5:43 PM, Stephen Warren wrote: > On 10/25/2012 03:59 PM, Allen Martin wrote: >> Add a new special environment variable "serial" that allows selection >> of serial device when CONFIG_SERIAL_MULTI is defined. This replaces >> the existing calls to serial_assign() from cmd_nvedit.c and iomux.c >> that were not doing anything. > > So I think this requires (for example) the following environment variables: > > stdout=serial > serial=eserial0 > > Is it possible to allow the following instead: > > stdout=eserial0 This is precisely what the patch I had pre-Marek serial did. > That way, one could presumably set: > > stdout=eserial0,eserial3 Though it didn't allow this. -Joe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] serial: add environment control for SERIAL_MULTI
Hi Stephen, On Thu, Oct 25, 2012 at 5:45 PM, Stephen Warren wrote: > On 10/25/2012 04:36 PM, Joe Hershberger wrote: >> Hi Allen, >> >> On Thu, Oct 25, 2012 at 4:59 PM, Allen Martin wrote: >>> Add a new special environment variable "serial" that allows selection >>> of serial device when CONFIG_SERIAL_MULTI is defined. This replaces >>> the existing calls to serial_assign() from cmd_nvedit.c and iomux.c >>> that were not doing anything. > ... >> Changes to this directly conflict with the environment callback series >> I sent out RFC (soon be be a real series). Can we hold off on this >> until that happens? > > The problem here is that serial output on Tegra simply doesn't work > (after some point in boot?) without this patch. It seems better to get > everything working before adding new features doesn't it? Otherwise, if > the environment callback stuff (or any other change right now) breaks > something Tegra-specific, there would be no way to identify which change > broke it. Fair enough. However I don't think this patch is the right way to fix it. -Joe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] serial: add environment control for SERIAL_MULTI
On Thu, Oct 25, 2012 at 03:46:01PM -0700, Joe Hershberger wrote: > Hi Stephen, > > On Thu, Oct 25, 2012 at 5:43 PM, Stephen Warren wrote: > > On 10/25/2012 03:59 PM, Allen Martin wrote: > >> Add a new special environment variable "serial" that allows selection > >> of serial device when CONFIG_SERIAL_MULTI is defined. This replaces > >> the existing calls to serial_assign() from cmd_nvedit.c and iomux.c > >> that were not doing anything. > > > > So I think this requires (for example) the following environment variables: > > > > stdout=serial > > serial=eserial0 > > > > Is it possible to allow the following instead: > > > > stdout=eserial0 > > This is precisely what the patch I had pre-Marek serial did. In your patch would "stdout=serial" still work for case where there is only one serial port? I think it's important to try to preserve that to no be too disruptive. > > > That way, one could presumably set: > > > > stdout=eserial0,eserial3 > > Though it didn't allow this. > Shouldn't that be (nearly) transparent through iomux? -Allen -- nvpublic ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] serial: add environment control for SERIAL_MULTI
On Thu, Oct 25, 2012 at 03:47:09PM -0700, Joe Hershberger wrote: > Hi Stephen, > > On Thu, Oct 25, 2012 at 5:45 PM, Stephen Warren wrote: > > On 10/25/2012 04:36 PM, Joe Hershberger wrote: > >> Hi Allen, > >> > >> On Thu, Oct 25, 2012 at 4:59 PM, Allen Martin wrote: > >>> Add a new special environment variable "serial" that allows selection > >>> of serial device when CONFIG_SERIAL_MULTI is defined. This replaces > >>> the existing calls to serial_assign() from cmd_nvedit.c and iomux.c > >>> that were not doing anything. > > ... > >> Changes to this directly conflict with the environment callback series > >> I sent out RFC (soon be be a real series). Can we hold off on this > >> until that happens? > > > > The problem here is that serial output on Tegra simply doesn't work > > (after some point in boot?) without this patch. It seems better to get > > everything working before adding new features doesn't it? Otherwise, if > > the environment callback stuff (or any other change right now) breaks > > something Tegra-specific, there would be no way to identify which change > > broke it. > > Fair enough. However I don't think this patch is the right way to fix it. > Ok, would removing the existing calls to serial_assign() from iomux.c and cmd_nvedit.c be an ok first step? They don't appear to do anything useful right now and that would fix tegra and raspberry pi. -Allen -- nvpublic ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v9] [RFC] Add dmmalloc module for DM.
Hi Tomas,
On Fri, Oct 26, 2012 at 6:16 AM, Tomas Hlavacek wrote:
> Hello Graeme,
>
> On Thu, Oct 25, 2012 at 3:40 AM, Graeme Russ wrote:
>
>>> diff --git a/arch/arm/include/asm/global_data.h
>>> b/arch/arm/include/asm/global_data.h
>>> index 2b9af93..9045829 100644
>>> --- a/arch/arm/include/asm/global_data.h
>>> +++ b/arch/arm/include/asm/global_data.h
>>> @@ -82,6 +82,9 @@ typedef struct global_data {
>>> unsigned long post_log_res; /* success of POST test */
>>> unsigned long post_init_f_time; /* When post_init_f started */
>>> #endif
>>> +#ifdef CONFIG_SYS_EARLY_MALLOC
>>> + void*early_heap;/* heap for early_malloc */
>>> +#endif
>>
>> Why not early_heap_header *early_heap; ?
>>
>
> It might be.
>
> Actually it is a good point because I am using 3 different ways of
> dealing with addresses: 1) struct early_heap header * or struct
> early_block_header * - I am using this when I want to access members
> of the stucture or compute address past the structure (which is where
> the heap or block starts); 2) phys_addr_t - which is plain integer and
> I use this for simple computations when I do not want to worry about
> pointer arithmetic; 3) void * when I have just plain address,
> especially when I want to pass an addres among logical parts of the
> mallocator or outside. This may a bit controversial and perhaps I
> should replace it by specific strucutre pointers internally.
>
> I am unable to decide: Should I remove struct early_heap_header from
> dmmalloc.h making it publicly unavailable or should I rather change
> the void * to struct early_heap_header * in the GD structure? What do
> you think is better?
I think struct early_heap_header * in the GD structure is the better way to
go as that is exactly what it is.
[snip]
>>> + h = (struct early_heap_header *)CONFIG_SYS_EARLY_HEAP_ADDR;
>>> + b = (struct early_block_header *)(h + 1);
>>
>> Hmmm, does this really work? I would have thought:
>>
>> b = (struct early_block_header *)(h + sizeof(struct early_heap_header));
>>
>> but I could be mistaken
>
> It seems that it works as it is (at least I wrote bunch of tests and I
> inspected resulting heaps and it was all right). I believe that since
> h is a pointer to the struct early_heap_header then pointer arithmetic
> is in effect and h+1 actually means "next element in the array of
> struct early_heap_header". Which is the address past the header that
> equals beginning of the heap data block. (?)
As I said, I could be mistaken - it appears I am :)
>>> +int early_malloc_active(void)
>>> +{
>>> + return ((gd->flags & GD_FLG_RELOC) != GD_FLG_RELOC);
>>> +}
>>
>> I think we need another flag - GD_FLG_RELOC gets set before the permanent
>> heap is initialised, so there is a window of opportunity where things may
>> break
>
> Well, as I wrote in the commit message - this is only a temporary
> implementation. I suppose I am going to change this when we have more
> coarse initialization flags wired into DM (which I believe we are
> going to have it anyway). So now I am just working around "forward
> dependency" here.
>
>>
>>> +
>>> +void early_heap_dump(struct early_heap_header *h)
>>> +{
>>> + struct early_block_header *b;
>>> +
>>> + debug("heap: h=%p, h->size=%d\n", h, h->size);
>>> +
>>> + b = (struct early_block_header *)(h+1);
>>> + while ((phys_addr_t)b + sizeof(struct early_block_header)
>>> + < (phys_addr_t)h + h->size) {
>>> + debug("block: h=%p h->size=%d b=%p b->size=%d
>>> b->(used)=%d\n",
>>> + h, h->size, b, BLOCK_SIZE(b->size),
>>> + BLOCK_USED(b->size));
>>> + assert(BLOCK_SIZE(b->size) > 0);
>>> + b = (struct early_block_header *)((phys_addr_t)b +
>>> + sizeof(struct early_block_header) +
>>> + BLOCK_SIZE(b->size));
>>> + }
>>> + debug("--- heap dump end ---\n");
>>> +}
>>
>> Nice touch, but could we just iterate through all ealry heap chunks starting
>> from gd->early_heap?
>
> Or I can have two functions. One heap specific and one for all heaps.
> I think both might be useful when somebody needs to debug early_malloc
> or memory usage etc. in the early stage. Thanks.
True, just adding another function which iterates through the heaps and
calls this function would be fine.
[snip]
>>> +static inline void *dmrealloc(void *oldaddr, size_t bytes)
>>> +{
>>> +#ifdef CONFIG_SYS_EARLY_MALLOC
>>> + char *addr;
>>> + struct early_block_header *h;
>>> + if (early_malloc_active()) {
>>> + addr = dmmalloc(bytes);
>>> + if (addr == NULL)
>>> + return NULL;
>>> +
>>> + h = BLOCK_HEADER(oldaddr);
>>> + if (BLOCK_FREE(h->size))
>>> + return NULL;
>>> +
>>> + if (bytes > BLOCK_SIZE(h->siz
[U-Boot] [PATCH] usb: tegra: move Tegra EHCI implementation to correct place
Move the Tegra EHCI implementation to the correct directory in the tree.
This code is specific to the Tegra EHCI controller, not to the Tegra SoC
in general.
This is not just a move of the code, but also some small changes squashed in.
Most notable:
- removed some unneeded parameters from function calls, to make functions
more self contained
- decrease max controller count to 3, both Tegra 2 and 3 have at most 3
EHCI controllers, we can aleays increase this later if the need arises
- controllers only get activated at ehci_hcd_init time, not at board_usb_init,
which is the more obvious init point and saves time if you are not going
to use usb in your boot process at all
Signed-off-by: Lucas Stach
---
This patch is based on the u-boot-usb tree
I've tested this on the Colibri T20 platform with no functional regressions.
All 3 USB controllers (both UTMI and ULPI) work as before the change.
---
arch/arm/cpu/armv7/tegra20/Makefile| 2 -
.../tegra20/usb.c => drivers/usb/host/ehci-tegra.c | 210 +++--
2 Dateien geändert, 109 Zeilen hinzugefügt(+), 103 Zeilen entfernt(-)
rename arch/arm/cpu/armv7/tegra20/usb.c => drivers/usb/host/ehci-tegra.c (87%)
diff --git a/arch/arm/cpu/armv7/tegra20/Makefile
b/arch/arm/cpu/armv7/tegra20/Makefile
index 09a0314..2c4d5c9 100644
--- a/arch/arm/cpu/armv7/tegra20/Makefile
+++ b/arch/arm/cpu/armv7/tegra20/Makefile
@@ -27,8 +27,6 @@ include $(TOPDIR)/config.mk
LIB= $(obj)lib$(SOC).o
-COBJS-$(CONFIG_USB_EHCI_TEGRA) += usb.o
-
COBJS := $(COBJS-y)
SRCS := $(COBJS:.o=.c)
OBJS := $(addprefix $(obj),$(COBJS))
diff --git a/arch/arm/cpu/armv7/tegra20/usb.c b/drivers/usb/host/ehci-tegra.c
similarity index 87%
rename from arch/arm/cpu/armv7/tegra20/usb.c
rename to drivers/usb/host/ehci-tegra.c
index 1bccf2b..0646028 100644
--- a/arch/arm/cpu/armv7/tegra20/usb.c
+++ b/drivers/usb/host/ehci-tegra.c
@@ -1,6 +1,7 @@
/*
* Copyright (c) 2011 The Chromium OS Authors.
- * (C) Copyright 2010,2011 NVIDIA Corporation
+ * Copyright (c) 2009-2012 NVIDIA Corporation
+ * Copyright (c) 2012 Lucas Stach
*
* See file CREDITS for list of people who contributed to this
* project.
@@ -22,6 +23,12 @@
*/
#include
+#include
+#include
+#include
+#include
+
+#include
#include
#include
#include
@@ -29,12 +36,11 @@
#include
#include
#include
-#include
#include
#include
#include
-#include
-#include
+
+#include "ehci.h"
#ifdef CONFIG_USB_ULPI
#ifndef CONFIG_USB_ULPI_VIEWPORT
@@ -43,9 +49,7 @@
#endif
#endif
-enum {
- USB_PORTS_MAX = 4,/* Maximum ports we allow */
-};
+#define USB_PORTS_MAX 3 /* maximum number of ports we allow */
/* Parameters we need for USB */
enum {
@@ -146,6 +150,23 @@ static const u8 utmip_elastic_limit = 16;
/* UTMIP High Speed Sync Start Delay */
static const u8 utmip_hs_sync_start_delay = 9;
+/*
+ * A known hardware issue where Connect Status Change bit of PORTSC register
+ * of USB1 controller will be set after Port Reset.
+ * We have to clear it in order for later device enumeration to proceed.
+ * This ehci_powerup_fixup overrides the weak function ehci_powerup_fixup
+ * in "ehci-hcd.c".
+ */
+void ehci_powerup_fixup(uint32_t *status_reg, uint32_t *reg)
+{
+ mdelay(50);
+ if (((u32) status_reg & TEGRA_USB_ADDR_MASK) != TEGRA_USB1_BASE)
+ return;
+ /* For EHCI_PS_CSC to be cleared in ehci_hcd.c */
+ if (ehci_readl(status_reg) & EHCI_PS_CSC)
+ *reg |= EHCI_PS_CSC;
+}
+
/* Put the port into host mode */
static void set_host_mode(struct fdt_usb *config)
{
@@ -190,19 +211,15 @@ void usbf_reset_controller(struct fdt_usb *config, struct
usb_ctlr *usbctlr)
/* Enable the UTMIP PHY */
if (config->utmi)
setbits_le32(&usbctlr->susp_ctrl, UTMIP_PHY_ENB);
-
- /*
-* TODO: where do we take the USB1 out of reset? The old code would
-* take USB3 out of reset, but not USB1. This code doesn't do either.
-*/
}
/* set up the UTMI USB controller with the parameters provided */
-static int init_utmi_usb_controller(struct fdt_usb *config,
- struct usb_ctlr *usbctlr, const u32 timing[])
+static int init_utmi_usb_controller(struct fdt_usb *config)
{
u32 val;
int loop_count;
+ u32 *timing;
+ struct usb_ctlr *usbctlr = config->reg;
clock_enable(config->periph_id);
@@ -229,6 +246,8 @@ static int init_utmi_usb_controller(struct fdt_usb *config,
* PLL Delay CONFIGURATION settings. The following parameters control
* the bring up of the plls.
*/
+ timing = usb_pll[clock_get_osc_freq()];
+
val = readl(&usbctlr->utmip_misc_cfg1);
clrsetbits_le32(&val, UTMIP_PLLU_STABLE_COUNT_MASK,
timing[PARAM_STABLE_COUNT] << UTMIP_PLLU_STABLE_COUNT_SHIFT);
@@ -331,12 +350,12 @@ static int init_utmi_usb_controller(s
Re: [U-Boot] [PATCH] serial: add environment control for SERIAL_MULTI
Hi Allen, On Thu, Oct 25, 2012 at 5:50 PM, Allen Martin wrote: > On Thu, Oct 25, 2012 at 03:46:01PM -0700, Joe Hershberger wrote: >> Hi Stephen, >> >> On Thu, Oct 25, 2012 at 5:43 PM, Stephen Warren >> wrote: >> > On 10/25/2012 03:59 PM, Allen Martin wrote: >> >> Add a new special environment variable "serial" that allows selection >> >> of serial device when CONFIG_SERIAL_MULTI is defined. This replaces >> >> the existing calls to serial_assign() from cmd_nvedit.c and iomux.c >> >> that were not doing anything. >> > >> > So I think this requires (for example) the following environment variables: >> > >> > stdout=serial >> > serial=eserial0 >> > >> > Is it possible to allow the following instead: >> > >> > stdout=eserial0 >> >> This is precisely what the patch I had pre-Marek serial did. > > In your patch would "stdout=serial" still work for case where there is > only one serial port? I think it's important to try to preserve that > to no be too disruptive. It used to support stdout=serial based on not being CONFIG_SERIAL_MULTI. Now that that's gone, I'm guessing it would simply be based on only having one registered serial device. >> >> > That way, one could presumably set: >> > >> > stdout=eserial0,eserial3 >> >> Though it didn't allow this. >> > > Shouldn't that be (nearly) transparent through iomux? If that's what iomux does, then sure! I haven't used I/O mux on a device before. -Joe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] serial: add environment control for SERIAL_MULTI
Hi Allen, On Thu, Oct 25, 2012 at 5:53 PM, Allen Martin wrote: > On Thu, Oct 25, 2012 at 03:47:09PM -0700, Joe Hershberger wrote: >> Hi Stephen, >> >> On Thu, Oct 25, 2012 at 5:45 PM, Stephen Warren >> wrote: >> > On 10/25/2012 04:36 PM, Joe Hershberger wrote: >> >> Hi Allen, >> >> >> >> On Thu, Oct 25, 2012 at 4:59 PM, Allen Martin wrote: >> >>> Add a new special environment variable "serial" that allows selection >> >>> of serial device when CONFIG_SERIAL_MULTI is defined. This replaces >> >>> the existing calls to serial_assign() from cmd_nvedit.c and iomux.c >> >>> that were not doing anything. >> > ... >> >> Changes to this directly conflict with the environment callback series >> >> I sent out RFC (soon be be a real series). Can we hold off on this >> >> until that happens? >> > >> > The problem here is that serial output on Tegra simply doesn't work >> > (after some point in boot?) without this patch. It seems better to get >> > everything working before adding new features doesn't it? Otherwise, if >> > the environment callback stuff (or any other change right now) breaks >> > something Tegra-specific, there would be no way to identify which change >> > broke it. >> >> Fair enough. However I don't think this patch is the right way to fix it. >> > > Ok, would removing the existing calls to serial_assign() from iomux.c > and cmd_nvedit.c be an ok first step? They don't appear to do > anything useful right now and that would fix tegra and raspberry pi. I think that's fine to just remove those 2 calls. Seem like a good short-term solution. -Joe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] serial: add environment control for SERIAL_MULTI
On Thu, Oct 25, 2012 at 04:18:11PM -0700, Joe Hershberger wrote: > Hi Allen, > > On Thu, Oct 25, 2012 at 5:53 PM, Allen Martin wrote: > > On Thu, Oct 25, 2012 at 03:47:09PM -0700, Joe Hershberger wrote: > >> Hi Stephen, > >> > >> On Thu, Oct 25, 2012 at 5:45 PM, Stephen Warren > >> wrote: > >> > On 10/25/2012 04:36 PM, Joe Hershberger wrote: > >> >> Hi Allen, > >> >> > >> >> On Thu, Oct 25, 2012 at 4:59 PM, Allen Martin > >> >> wrote: > >> >>> Add a new special environment variable "serial" that allows selection > >> >>> of serial device when CONFIG_SERIAL_MULTI is defined. This replaces > >> >>> the existing calls to serial_assign() from cmd_nvedit.c and iomux.c > >> >>> that were not doing anything. > >> > ... > >> >> Changes to this directly conflict with the environment callback series > >> >> I sent out RFC (soon be be a real series). Can we hold off on this > >> >> until that happens? > >> > > >> > The problem here is that serial output on Tegra simply doesn't work > >> > (after some point in boot?) without this patch. It seems better to get > >> > everything working before adding new features doesn't it? Otherwise, if > >> > the environment callback stuff (or any other change right now) breaks > >> > something Tegra-specific, there would be no way to identify which change > >> > broke it. > >> > >> Fair enough. However I don't think this patch is the right way to fix it. > >> > > > > Ok, would removing the existing calls to serial_assign() from iomux.c > > and cmd_nvedit.c be an ok first step? They don't appear to do > > anything useful right now and that would fix tegra and raspberry pi. > > I think that's fine to just remove those 2 calls. Seem like a good > short-term solution. > Ok, I'll send out a patch for that now, thanks. -Allen -- nvpublic ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] serial: remove calls to serial_assign()
Remove calls to serial_assign() that are failing now that it returns a proper error code. This calls were not actually doing anything because they passed the name of a stdio_dev when a serial_device name is exptectd. Signed-off-by: Allen Martin --- common/cmd_nvedit.c |3 --- common/iomux.c | 10 -- 2 files changed, 13 deletions(-) diff --git a/common/cmd_nvedit.c b/common/cmd_nvedit.c index 1f9c674..68c38f4 100644 --- a/common/cmd_nvedit.c +++ b/common/cmd_nvedit.c @@ -238,9 +238,6 @@ int env_check_apply(const char *name, const char *oldval, /* Try assigning specified device */ if (console_assign(console, newval) < 0) return 1; - - if (serial_assign(newval) < 0) - return 1; #endif /* CONFIG_CONSOLE_MUX */ } diff --git a/common/iomux.c b/common/iomux.c index dbc2312..6a75704 100644 --- a/common/iomux.c +++ b/common/iomux.c @@ -135,16 +135,6 @@ int iomux_doenv(const int console, const char *arg) */ if (console_assign(console, start[j]) < 0) continue; - /* -* This was taken from common/cmd_nvedit.c. -* This will never work because serial_assign() returns -* 1 upon error, not -1. -* This would almost always return an error anyway because -* serial_assign() expects the name of a serial device, like -* serial_smc, but the user generally only wants to set serial. -*/ - if (serial_assign(start[j]) < 0) - continue; cons_set[cs_idx++] = dev; } free(console_args); -- 1.7.10.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] serial: remove calls to serial_assign()
Hi Allen, On Thu, Oct 25, 2012 at 6:30 PM, Allen Martin wrote: > Remove calls to serial_assign() that are failing now that it returns a > proper error code. This calls were not actually doing anything > because they passed the name of a stdio_dev when a serial_device name > is exptectd. > > Signed-off-by: Allen Martin > --- Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 02/19] scsi: Provide support for a list of AHCI controllers.
From: Vadim Bendebury
Many AHCI controllers are identical, the main (and often the
only) difference being the PCI Vendor ID/Device ID combination
reported by the device.
This change allows the config file to define a list of PCI vendor
ID/device ID pairs. The driver would scan the list and initialize
the first device it finds.
No actual multiple device list is introduced yet, this change
just add the framework.
Signed-off-by: Vadim Bendebury
Signed-off-by: Taylor Hutt
Signed-off-by: Simon Glass
---
Changes in v2:
- Use struct pci_device_id instead of defining new struct scsi_device
- Squash in CONFIG_PCI patch
common/cmd_scsi.c | 40 +++-
1 files changed, 35 insertions(+), 5 deletions(-)
diff --git a/common/cmd_scsi.c b/common/cmd_scsi.c
index 22d0119..5cb3390 100644
--- a/common/cmd_scsi.c
+++ b/common/cmd_scsi.c
@@ -34,6 +34,9 @@
#include
#include
+#ifdef CONFIG_SCSI_DEV_LIST
+#define SCSI_DEV_LIST CONFIG_SCSI_DEV_LIST
+#else
#ifdef CONFIG_SCSI_SYM53C8XX
#define SCSI_VEND_ID 0x1000
#ifndef CONFIG_SCSI_DEV_ID
@@ -49,8 +52,12 @@
#elif !defined(CONFIG_SCSI_AHCI_PLAT)
#error no scsi device defined
#endif
+#define SCSI_DEV_LIST {SCSI_VEND_ID, SCSI_DEV_ID}
+#endif
-
+#ifdef CONFIG_PCI
+DEFINE_PCI_DEVICE_TABLE(scsi_device_list) = { SCSI_DEV_LIST };
+#endif
static ccb tempccb;/* temporary scsi command buffer */
static unsigned char tempbuff[512]; /* temporary data buffer */
@@ -178,15 +185,38 @@ removable:
void scsi_init(void)
{
int busdevfunc;
+ int i;
+ /*
+* Find a device from the list, this driver will support a single
+* controller.
+*/
+ for (i = 0; i < ARRAY_SIZE(scsi_device_list); i++) {
+ /* get PCI Device ID */
+ busdevfunc = pci_find_device(scsi_device_list[i].scsi_vendor_id,
+scsi_device_list[i].scsi_dev_id,
+0);
+ if (busdevfunc != -1)
+ break;
+ }
- busdevfunc=pci_find_device(SCSI_VEND_ID,SCSI_DEV_ID,0); /* get PCI
Device ID */
- if(busdevfunc==-1) {
- printf("Error SCSI Controller (%04X,%04X) not
found\n",SCSI_VEND_ID,SCSI_DEV_ID);
+ if (busdevfunc == -1) {
+ printf("Error: SCSI Controller(s) ");
+ for (i = 0; i < ARRAY_SIZE(scsi_device_list); i++) {
+ printf("%04X:%04X ",
+ scsi_device_list[i].scsi_vendor_id,
+ scsi_device_list[i].scsi_dev_id);
+ }
+ printf("not found\n");
return;
}
#ifdef DEBUG
else {
- printf("SCSI Controller (%04X,%04X) found
(%d:%d:%d)\n",SCSI_VEND_ID,SCSI_DEV_ID,(busdevfunc>>16)&0xFF,(busdevfunc>>11)&0x1F,(busdevfunc>>8)&0x7);
+ printf("SCSI Controller (%04X,%04X) found (%d:%d:%d)\n",
+ scsi_device_list[i].scsi_vendor_id,
+ scsi_device_list[i].scsi_dev_id,
+ (busdevfunc >> 16) & 0xFF,
+ (busdevfunc >> 11) & 0x1F,
+ (busdevfunc >> 8) & 0x7);
}
#endif
scsi_low_level_init(busdevfunc);
--
1.7.7.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 02/19] scsi: Provide support for a list of AHCI controllers.
Hi Tom, On Thu, Oct 25, 2012 at 5:52 PM, Simon Glass wrote: > From: Vadim Bendebury > > Many AHCI controllers are identical, the main (and often the > only) difference being the PCI Vendor ID/Device ID combination > reported by the device. > > This change allows the config file to define a list of PCI vendor > ID/device ID pairs. The driver would scan the list and initialize > the first device it finds. > > No actual multiple device list is introduced yet, this change > just add the framework. > > Signed-off-by: Vadim Bendebury > Signed-off-by: Taylor Hutt > Signed-off-by: Simon Glass > --- > Changes in v2: > - Use struct pci_device_id instead of defining new struct scsi_device > - Squash in CONFIG_PCI patch Please note that I squashed in patch 13 of the series. I marked http://patchwork.ozlabs.org/patch/192521/ superseded in patchwork. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/14] fdt: Add various device tree utilities and features
This series contains a number of features related to CONFIG_OF_CONTROL, such as: - reading fdt values - reading configuration from the fdt - allowing the fdt to specify a boot command Abhilash Kesavan (2): fdt: Add function to get config int from device tree fdt: Add function for decoding multiple gpios globally available Che-Liang Chiou (2): fdt: Add fdtdec_get_uint64 to decode a 64-bit value from a property fdt: Load boot command from device tree Doug Anderson (1): fdt: Allow device tree to specify secure booting Gabe Black (3): fdt: Add function to read boolean property fdt: Tell the FDT library where the device tree is fdt: Add option to default to most compatible conf in a fit image Sean Paul (1): fdt: Add polarity-aware gpio functions to fdtdec Simon Glass (5): fdt: Add function to get a config string from device tree fdt: Add fdtdec_decode_region() to decode memory region fdt: Export fdtdec_find_alias_node() function fdt: Export fdtdec_lookup() and fix the name fdt: Set kernaddr if fdt indicates a kernel is present README | 11 + common/cmd_bootm.c | 11 + common/image.c | 127 common/main.c | 102 +- include/fdtdec.h | 121 + include/image.h|1 + lib/fdtdec.c | 107 +--- 7 files changed, 472 insertions(+), 8 deletions(-) -- 1.7.7.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 10/14] fdt: Load boot command from device tree
From: Che-Liang Chiou
Load boot command from /config/bootcmd of device tree if present.
Signed-off-by: Tom Wai-Hong Tam
Signed-off-by: Che-Liang Chiou
Signed-off-by: Simon Glass
---
common/main.c | 16 +++-
1 files changed, 15 insertions(+), 1 deletions(-)
diff --git a/common/main.c b/common/main.c
index 9507cec..23a68ee 100644
--- a/common/main.c
+++ b/common/main.c
@@ -30,6 +30,7 @@
#include
#include
#include
+#include
#include
#include
#ifdef CONFIG_MODEM_SUPPORT
@@ -40,6 +41,10 @@
#include
#endif
+#ifdef CONFIG_OF_CONTROL
+#include
+#endif
+
#include
#include
#include
@@ -284,7 +289,10 @@ void main_loop (void)
int rc = 1;
int flag;
#endif
-
+#if defined(CONFIG_BOOTDELAY) && (CONFIG_BOOTDELAY >= 0) && \
+ defined(CONFIG_OF_CONTROL)
+ char *env;
+#endif
#if defined(CONFIG_BOOTDELAY) && (CONFIG_BOOTDELAY >= 0)
char *s;
int bootdelay;
@@ -380,6 +388,12 @@ void main_loop (void)
else
#endif /* CONFIG_BOOTCOUNT_LIMIT */
s = getenv ("bootcmd");
+#ifdef CONFIG_OF_CONTROL
+ /* Allow the fdt to override the boot command */
+ env = fdtdec_get_config_string(gd->fdt_blob, "bootcmd");
+ if (env)
+ s = env;
+#endif /* CONFIG_OF_CONTROL */
debug ("### main_loop: bootcmd=\"%s\"\n", s ? s : "");
--
1.7.7.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 14/14] fdt: Set kernaddr if fdt indicates a kernel is present
If kernel-offset is specified in the fdt, set an environment variable
so that scripts can access the attached kernel.
This can be used by a packaging program to tell U-Boot about a kernel
that has been downloaded alongside U-Boot. The value in the fdt is
the offset of the kernel from the start of the U-Boot image, so we can
find it just by adding CONFIG_SYS_TEXT_BASE.
It is then fairly easy to put something like this in the environment
variables in the board header file:
"if test ${kernaddr} != \"\"; then "\
"echo \"Using bundled kernel\"; "\
"bootm ${kernaddr};" \
"fi; "\
/* rest of boot sequence follows here */
Signed-off-by: Simon Glass
---
common/main.c | 16
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/common/main.c b/common/main.c
index 03c63b4..3137b75 100644
--- a/common/main.c
+++ b/common/main.c
@@ -333,6 +333,20 @@ err:
hang();
}
+static void process_fdt_options(const void *blob)
+{
+ ulong addr;
+
+ /* Add an env variable to point to a kernel payload, if available */
+ addr = fdtdec_get_config_int(gd->fdt_blob, "kernel-offset", 0);
+ if (addr)
+ setenv_addr("kernaddr", (void *)(CONFIG_SYS_TEXT_BASE + addr));
+
+ /* Add an env variable to point to a root disk, if available */
+ addr = fdtdec_get_config_int(gd->fdt_blob, "rootdisk-offset", 0);
+ if (addr)
+ setenv_addr("rootaddr", (void *)(CONFIG_SYS_TEXT_BASE + addr));
+}
#endif /* CONFIG_OF_CONTROL */
@@ -451,6 +465,8 @@ void main_loop (void)
if (env)
s = env;
+ process_fdt_options(gd->fdt_blob);
+
/*
* If the bootsecure option was chosen, use secure_boot_cmd().
* Always use 'env' in this case, since bootsecure requres that the
--
1.7.7.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 13/14] fdt: Add option to default to most compatible conf in a fit image
From: Gabe Black
When booting a fit image with multiple configurations, the user either has to
specify which configuration to use explicitly, or there has to be a default
defined which is chosen automatically. This change adds an option to change
that behavior so that a configuration can be selected explicitly, or the
configuration which has the device tree that claims to be compatible with the
earliest item in U-Boot's device tree.
In other words, if U-Boot claimed to be compatible with A, B, and then C, and
the configurations claimed to be compatible with A, D and B, D and D, E, the
first configuration, A, D, would be chosen. Both the first and second
configurations match, but the first one matches a more specific entry in
U-Boot's device tree. The order in the kernel's device tree is ignored.
Signed-off-by: Gabe Black
Commit-Ready: Gabe Black
Signed-off-by: Simon Glass
---
README | 11 +
common/cmd_bootm.c | 11 +
common/image.c | 127
include/image.h|1 +
4 files changed, 150 insertions(+), 0 deletions(-)
diff --git a/README b/README
index 69da2b8..3912150 100644
--- a/README
+++ b/README
@@ -2582,6 +2582,17 @@ FIT uImage format:
-150 common/cmd_nand.c Incorrect FIT image format
151 common/cmd_nand.c FIT image format OK
+- FIT image support:
+ CONFIG_FIT
+ Enable support for the FIT uImage format.
+
+ CONFIG_FIT_BEST_MATCH
+ When no configuration is explicitly selected, default to the
+ one whose fdt's compatibility field best matches that of
+ U-Boot itself. A match is considered "best" if it matches the
+ most specific compatibility entry of U-Boot's fdt's root node.
+ The order of entries in the configuration's fdt is ignored.
+
- Standalone program support:
CONFIG_STANDALONE_LOAD_ADDR
diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
index 83fa5d7..4e6042c 100644
--- a/common/cmd_bootm.c
+++ b/common/cmd_bootm.c
@@ -949,8 +949,19 @@ static void *boot_get_kernel(cmd_tbl_t *cmdtp, int flag,
int argc,
* node
*/
bootstage_mark(BOOTSTAGE_ID_FIT_NO_UNIT_NAME);
+#ifdef CONFIG_FIT_BEST_MATCH
+ if (fit_uname_config)
+ cfg_noffset =
+ fit_conf_get_node(fit_hdr,
+ fit_uname_config);
+ else
+ cfg_noffset =
+ fit_conf_find_compat(fit_hdr,
+gd->fdt_blob);
+#else
cfg_noffset = fit_conf_get_node(fit_hdr,
fit_uname_config);
+#endif
if (cfg_noffset < 0) {
bootstage_error(BOOTSTAGE_ID_FIT_NO_UNIT_NAME);
return NULL;
diff --git a/common/image.c b/common/image.c
index 750a98b..8877395 100644
--- a/common/image.c
+++ b/common/image.c
@@ -3049,6 +3049,133 @@ int fit_check_format(const void *fit)
return 1;
}
+
+/**
+ * fit_conf_find_compat
+ * @fit: pointer to the FIT format image header
+ * @fdt: pointer to the device tree to compare against
+ *
+ * fit_conf_find_compat() attempts to find the configuration whose fdt is the
+ * most compatible with the passed in device tree.
+ *
+ * Example:
+ *
+ * / o image-tree
+ * |-o images
+ * | |-o fdt@1
+ * | |-o fdt@2
+ * |
+ * |-o configurations
+ * |-o config@1
+ * | |-fdt = fdt@1
+ * |
+ * |-o config@2
+ * |-fdt = fdt@2
+ *
+ * / o U-Boot fdt
+ * |-compatible = "foo,bar", "bim,bam"
+ *
+ * / o kernel fdt1
+ * |-compatible = "foo,bar",
+ *
+ * / o kernel fdt2
+ * |-compatible = "bim,bam", "baz,biz"
+ *
+ * Configuration 1 would be picked because the first string in U-Boot's
+ * compatible list, "foo,bar", matches a compatible string in the root of fdt1.
+ * "bim,bam" in fdt2 matches the second string which isn't as good as fdt1.
+ *
+ * returns:
+ * offset to the configuration to use if one was found
+ * -1 otherwise
+ */
+int fit_conf_find_compat(const void *fit, const void *fdt)
+{
+ int ndepth = 0;
+ int noffset, confs_noffset, images_noffset;
+ const void *fdt_compat;
+ int fdt_compat_len;
+ int best_match_offset = 0;
+ int best_match_pos = 0;
+
+ confs_noffset = fdt_path_offset(fit, FIT_CONFS_PATH);
+ images_noffset = fdt_path_offset(fit, FIT_IMAGES_PATH);
+ if (confs_noffset < 0 || images_noffset < 0) {
+ debug("Can't find configurations or images nodes.\n");
+ return -1;
+ }
+
+ fdt_compat = fdt_getprop(fdt, 0, "compatible", &fdt_compat_len);
+
[U-Boot] [PATCH 07/14] fdt: Add function to read boolean property
From: Gabe Black
Signed-off-by: Vincent Palatin
Commit-Ready: Vincent Palatin
Commit-Ready: Gabe Black
Signed-off-by: Simon Glass
---
include/fdtdec.h | 10 ++
lib/fdtdec.c | 14 ++
2 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/include/fdtdec.h b/include/fdtdec.h
index 3f1840c..82fdb99 100644
--- a/include/fdtdec.h
+++ b/include/fdtdec.h
@@ -408,6 +408,16 @@ int fdtdec_get_config_int(const void *blob, const char
*prop_name,
int default_val);
/**
+ * Look in the FDT for a config item with the given name
+ * and return whether it exists.
+ *
+ * @param blob FDT blob
+ * @param prop_nameproperty name to look up
+ * @return 1, if it exists, or 0 if not
+ */
+int fdtdec_get_config_bool(const void *blob, const char *prop_name);
+
+/**
* Look in the FDT for a config item with the given name and return its value
* as a string.
*
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index efe9afe..fbb2827 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -524,6 +524,20 @@ int fdtdec_get_config_int(const void *blob, const char
*prop_name,
return fdtdec_get_int(blob, config_node, prop_name, default_val);
}
+int fdtdec_get_config_bool(const void *blob, const char *prop_name)
+{
+ int config_node;
+ const void *prop;
+
+ debug("%s: %s\n", __func__, prop_name);
+ config_node = fdt_path_offset(blob, "/config");
+ if (config_node < 0)
+ return 0;
+ prop = fdt_get_property(blob, config_node, prop_name, NULL);
+
+ return prop != NULL;
+}
+
char *fdtdec_get_config_string(const void *blob, const char *prop_name)
{
const char *nodep;
--
1.7.7.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 11/14] fdt: Tell the FDT library where the device tree is
From: Gabe Black This change adds a call to set_working_fdt_addr near the end of u-boot initialization which tells the fdt command/library where the device tree is. This makes it possible to use the fdt command to look at the active device tree since otherwise there would be no way to know what address it was at to set things up manually. Signed-off-by: Gabe Black Signed-off-by: Simon Glass --- common/main.c |8 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/common/main.c b/common/main.c index 23a68ee..cf1b5f9 100644 --- a/common/main.c +++ b/common/main.c @@ -45,6 +45,10 @@ #include #endif +#ifdef CONFIG_OF_LIBFDT +#include +#endif /* CONFIG_OF_LIBFDT */ + #include #include #include @@ -418,6 +422,10 @@ void main_loop (void) #endif /* CONFIG_MENUKEY */ #endif /* CONFIG_BOOTDELAY */ +#if defined CONFIG_OF_CONTROL + set_working_fdt_addr((void *)gd->fdt_blob); +#endif /* CONFIG_OF_CONTROL */ + /* * Main Loop for Monitor Command Processing */ -- 1.7.7.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 12/14] fdt: Allow device tree to specify secure booting
From: Doug Anderson
When secure booting is chosen:
* The u-boot shell is never invoked during boot--we just do a simple
table lookup to find the command. This means we could even remove
the shell parsing from u-boot and still be able to boot.
* The boot command can't be interruped.
* Failure doesn't cause us to fall back to the shell.
Signed-off-by: Gabe Black
Signed-off-by: Doug Anderson
Signed-off-by: Simon Glass
---
common/main.c | 62 +
1 files changed, 62 insertions(+), 0 deletions(-)
diff --git a/common/main.c b/common/main.c
index cf1b5f9..03c63b4 100644
--- a/common/main.c
+++ b/common/main.c
@@ -283,6 +283,59 @@ int abortboot(int bootdelay)
# endif/* CONFIG_AUTOBOOT_KEYED */
#endif /* CONFIG_BOOTDELAY >= 0 */
+/*
+ * Runs the given boot command securely. Specifically:
+ * - Doesn't run the command with the shell (run_command or
parse_string_outer),
+ * since that's a lot of code surface that an attacker might exploit.
+ * Because of this, we don't do any argument parsing--the secure boot command
+ * has to be a full-fledged u-boot command.
+ * - Doesn't check for keypresses before booting, since that could be a
+ * security hole; also disables Ctrl-C.
+ * - Doesn't allow the command to return.
+ *
+ * Upon any failures, this function will drop into an infinite loop after
+ * printing the error message to console.
+ */
+
+#if defined(CONFIG_BOOTDELAY) && (CONFIG_BOOTDELAY >= 0) && \
+ defined(CONFIG_OF_CONTROL)
+static void secure_boot_cmd(char *cmd)
+{
+ cmd_tbl_t *cmdtp;
+ int rc;
+
+ if (!cmd) {
+ printf("## Error: Secure boot command not specified\n");
+ goto err;
+ }
+
+ /* Disable Ctrl-C just in case some command is used that checks it. */
+ disable_ctrlc(1);
+
+ /* Find the command directly. */
+ cmdtp = find_cmd(cmd);
+ if (!cmdtp) {
+ printf("## Error: \"%s\" not defined\n", cmd);
+ goto err;
+ }
+
+ /* Run the command, forcing no flags and faking argc and argv. */
+ rc = (cmdtp->cmd)(cmdtp, 0, 1, &cmd);
+
+ /* Shouldn't ever return from boot command. */
+ printf("## Error: \"%s\" returned (code %d)\n", cmd, rc);
+
+err:
+ /*
+* Not a whole lot to do here. Rebooting won't help much, since we'll
+* just end up right back here. Just loop.
+*/
+ hang();
+}
+
+#endif /* CONFIG_OF_CONTROL */
+
+
//
void main_loop (void)
@@ -397,6 +450,15 @@ void main_loop (void)
env = fdtdec_get_config_string(gd->fdt_blob, "bootcmd");
if (env)
s = env;
+
+ /*
+* If the bootsecure option was chosen, use secure_boot_cmd().
+* Always use 'env' in this case, since bootsecure requres that the
+* bootcmd was specified in the FDT too.
+*/
+ if (fdtdec_get_config_int(gd->fdt_blob, "bootsecure", 0))
+ secure_boot_cmd(env);
+
#endif /* CONFIG_OF_CONTROL */
debug ("### main_loop: bootcmd=\"%s\"\n", s ? s : "");
--
1.7.7.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 04/14] fdt: Add function for decoding multiple gpios globally available
From: Abhilash Kesavan
Samsung's SDHCI bindings require multiple gpios to be parsed and
configured at a time. Export the already available fdtdec_decode_gpios
for this purpose.
Signed-off-by: Abhilash Kesavan
Commit-Ready: Che-Liang Chiou
Signed-off-by: Simon Glass
---
include/fdtdec.h | 16
lib/fdtdec.c |5 ++---
2 files changed, 18 insertions(+), 3 deletions(-)
diff --git a/include/fdtdec.h b/include/fdtdec.h
index 341e6a1..e70714b 100644
--- a/include/fdtdec.h
+++ b/include/fdtdec.h
@@ -345,6 +345,22 @@ int fdtdec_decode_gpio(const void *blob, int node, const
char *prop_name,
struct fdt_gpio_state *gpio);
/**
+ * Decode a list of GPIOs from an FDT. This creates a list of GPIOs with no
+ * terminating item.
+ *
+ * @param blob FDT blob to use
+ * @param node Node to look at
+ * @param prop_nameNode property name
+ * @param gpio Array of gpio elements to fill from FDT. This will be
+ * untouched if either 0 or an error is returned
+ * @param max_countMaximum number of elements allowed
+ * @return number of GPIOs read if ok, -FDT_ERR_BADLAYOUT if max_count would
+ * be exceeded, or -FDT_ERR_NOTFOUND if the property is missing.
+ */
+int fdtdec_decode_gpios(const void *blob, int node, const char *prop_name,
+ struct fdt_gpio_state *gpio, int max_count);
+
+/**
* Set up a GPIO pin according to the provided gpio information. At present
this
* just requests the GPIO.
*
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index 5570972..32f03cc 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -426,9 +426,8 @@ int fdtdec_get_bool(const void *blob, int node, const char
*prop_name)
* @return number of GPIOs read if ok, -FDT_ERR_BADLAYOUT if max_count would
* be exceeded, or -FDT_ERR_NOTFOUND if the property is missing.
*/
-static int fdtdec_decode_gpios(const void *blob, int node,
- const char *prop_name, struct fdt_gpio_state *gpio,
- int max_count)
+int fdtdec_decode_gpios(const void *blob, int node, const char *prop_name,
+ struct fdt_gpio_state *gpio, int max_count)
{
const struct fdt_property *prop;
const u32 *cell;
--
1.7.7.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
