Re: [U-Boot] i.MX6: Add hdmidet command
On 20/02/2013 02:21, Eric Nelson wrote:
> On 02/19/2013 06:19 PM, Otavio Salvador wrote:
>> On Tue, Feb 19, 2013 at 10:16 PM, Eric Nelson
>> wrote:
>>> On 02/19/2013 05:42 PM, Otavio Salvador wrote:
On Tue, Feb 19, 2013 at 8:03 PM, Eric Nelson
wrote:
>
> Hi Otavio,
>
>
> On 02/19/2013 01:30 PM, Otavio Salvador wrote:
>>
>>
>> On Tue, Feb 19, 2013 at 5:12 PM, Eric Nelson
>> wrote:
>>>
>>>
>>> Hi Stefano,
>>>
>>> This seems to have gotten lost in the shuffle.
>>>
>>> It's showing as "Changes requested" in Patchwork:
>>>
>>>http://patchwork.ozlabs.org/patch/186280/
>>>
>>> Is there something you'd like changed?
>>>
>>> Please advise,
>>
>>
>>
>> I'd say to use space between the '+' as done in other code.
>>
>
> I must be dense.
>
> Which '+' needs a space?
It seems usually when dealing with offsets we have ' + '. Personally I
think it is clear to read too. But it's not my call so it is up to you
and Stefano.
>>> Gotcha.
>>>
>>> You mean here:
>>>
>>> +{
>>> + u8 reg = __raw_readb(HDMI_ARB_BASE_ADDR+HDMI_PHY_STAT0);
>>> ^
>>>
>>> That's the trouble with commenting on the patchwork link...
>>
>> Yes; a space between both macros.
>>
>
> And a run through checkpatch...
>
> I am dense today.
>
Right, sorry for late answer - it is only to fix checkpatch warning,
nothing more. I wll then apply it
Best regards,
Stefano
--
=
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 00/11] *** SUBJECT HERE ***
Hi Wolfgang, On Tue, Feb 19, 2013 at 6:14 PM, Wolfgang Denk wrote: > Dear Sonic Zhang, > > please provide a useful Subject: line - "*** SUBJECT HERE ***" is not > exactly helpful. > > In message <1361257266-3722-1-git-send-email-sonic@gmail.com> you wrote: >> >> The v2 patches >> 1) fix most checkpatch issues mentioned by Wolfgang > > Hm... I'm sorry, but this information is not really helpful. So it > seems you decided not to fix all issues, but you don't tell us which > ones you ignored, or why. > > I still see thousands of lines over 80 characters, > plus a number of > trailing statements should be on next line, > code indent should use tabs where possible, > do not add new typedefs, > Whitespace before semicolon, > warnings and errors. > > Please fix these!! > Sorry, I forget to check the serial patch after fixing the unreadable port muxing code. But, where is the "Whitespace before semicolon"? my checkpatch.pl doesn't report this issue. >> 2) remove unrelated dma structure change patch >> 3) replace unreable macro in dma and uart structures with normal types. >> 4) replace unreable macro in uart peripheral portmux configuration with >> clear inline function. >> 5) clean up and merge redundant #ifdef's >> 6) spearate declarations and code by a blankline >> 7) remove the values for variables in blackfin config headers whose values >> are useless >> 8) replace run-time variable with new macro when adding 4M byte CPLB entries. > > Please provide a more detailed list which review comments you > processed, and which you decided to ignore, and why. > > Please provide a more detailed list which review comments you > processed, and which you decided to ignore, and why. > > Note: this history of changes is supposed to be (also) in the patches > itself, not (only) in the cover letter. > OK. I will put all change logs into the patches respectively. Regards, Sonic ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/9 v9] EXYNOS5: TMU: Add driver for Thermal Management Unit
Dear Akshay,
On 06/02/13 22:18, Akshay Saraswat wrote:
> Adding Exynos Thermal Management Unit driver to monitor SOC
> temperature and take actions corresponding to states of TMU.
>
> Signed-off-by: Akshay Saraswat
> Acked-by: Simon Glass
> ---
> Changes since v8:
> - None.
>
> arch/arm/include/asm/arch-exynos/exynos-tmu.h | 58 +
> drivers/power/Makefile|1 +
> drivers/power/exynos-tmu.c| 302
> +
> include/tmu.h | 46
> 4 files changed, 407 insertions(+)
> create mode 100644 arch/arm/include/asm/arch-exynos/exynos-tmu.h
> create mode 100644 drivers/power/exynos-tmu.c
> create mode 100644 include/tmu.h
>
> diff --git a/arch/arm/include/asm/arch-exynos/exynos-tmu.h
> b/arch/arm/include/asm/arch-exynos/exynos-tmu.h
> new file mode 100644
> index 000..c79a520
> --- /dev/null
> +++ b/arch/arm/include/asm/arch-exynos/exynos-tmu.h
just tmu.h please.
> @@ -0,0 +1,58 @@
> +/*
> + * Copyright (c) 2012 Samsung Electronics Co., Ltd.
> + * http://www.samsung.com
> + * Akshay Saraswat
> + *
> + * EXYNOS - Thermal Management Unit
> + *
> + * 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 version 2 as
> + * published by the Free Software Foundation.
> + * 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_TMU_H
> +#define __ASM_ARCH_TMU_H
> +
> +struct tmu_reg {
is it for exynos5? or exynos4? or both?
> + unsigned triminfo;
> + unsigned rsvd1;
> + unsigned rsvd2;
> + unsigned rsvd3;
> + unsigned rsvd4;
> + unsigned triminfo_control;
> + unsigned rsvd5;
> + unsigned rsvd6;
> + unsigned tmu_control;
> + unsigned rsvd7;
> + unsigned tmu_status;
> + unsigned sampling_internal;
> + unsigned counter_value0;
> + unsigned counter_value1;
> + unsigned rsvd8;
> + unsigned rsvd9;
> + unsigned current_temp;
> + unsigned rsvd10;
> + unsigned rsvd11;
> + unsigned rsvd12;
> + unsigned threshold_temp_rise;
> + unsigned threshold_temp_fall;
> + unsigned rsvd13;
> + unsigned rsvd14;
> + unsigned past_temp3_0;
> + unsigned past_temp7_4;
> + unsigned past_temp11_8;
> + unsigned past_temp15_12;
> + unsigned inten;
> + unsigned intstat;
> + unsigned intclear;
> + unsigned rsvd15;
> + unsigned emul_con;
> +};
> +#endif /* __ASM_ARCH_THERMAL_H */
> diff --git a/drivers/power/Makefile b/drivers/power/Makefile
> index 8c71901..1dac16a 100644
> --- a/drivers/power/Makefile
> +++ b/drivers/power/Makefile
> @@ -25,6 +25,7 @@ include $(TOPDIR)/config.mk
>
> LIB := $(obj)libpower.o
>
> +COBJS-$(CONFIG_EXYNOS_TMU) += exynos-tmu.o
> COBJS-$(CONFIG_FTPMU010_POWER) += ftpmu010.o
> COBJS-$(CONFIG_TPS6586X_POWER) += tps6586x.o
> COBJS-$(CONFIG_TWL4030_POWER)+= twl4030.o
> diff --git a/drivers/power/exynos-tmu.c b/drivers/power/exynos-tmu.c
> new file mode 100644
> index 000..b010883
> --- /dev/null
> +++ b/drivers/power/exynos-tmu.c
> @@ -0,0 +1,302 @@
> +/*
> + * Copyright (c) 2012 Samsung Electronics Co., Ltd.
> + * http://www.samsung.com
> + * Akshay Saraswat
> + *
> + * EXYNOS - Thermal Management Unit
> + *
> + * 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 version 2 as
> + * published by the Free Software Foundation.
> + * 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
> +
> +#define TRIMINFO_RELOAD 1
> +#define CORE_EN 1
> +
> +#define INTEN_RISE0 1
> +#define INTEN_RISE1 (1 << 4)
> +#define INTEN_RISE2 (1 << 8)
> +#define INTEN_FALL0 (1 << 16)
> +#define INTEN_FALL1 (1 << 20)
> +#define INTEN_FALL2 (1 << 24)
> +
> +#define TRIM_INFO_MASK 0xff
> +
> +#define INTCLEAR_RISE0 1
> +#define INTCLEAR_RISE1 (1 << 4)
> +#define INTCLEAR_RISE2 (1 << 8)
> +#define INTCLEAR_FALL0 (1 << 16)
> +#define INTCLEAR_FALL1 (1 << 20)
> +#define INTCLEAR_FALL2 (1 << 24)
> +#define INTCLEARALL (INTCLEAR_RISE0 | INTCLEAR_RISE1 | \
> + INTCLEAR_RISE2 | INTCLEAR_FALL0 | \
Re: [U-Boot] [PATCH 2/9 v9] EXYNOS5: Implement board_poweroff for Thermal Management Unit
Dear Akshay,
On 06/02/13 22:18, Akshay Saraswat wrote:
> Adding API in power for system shutdown when tripping value is reached
> in Exynos Thermal Management Unit.
>
> Signed-off-by: Akshay Saraswat
> Acked-by: Simon Glass
> ---
> Changes since v8:
> - None.
>
> arch/arm/cpu/armv7/exynos/power.c| 15 +++
> arch/arm/include/asm/arch-exynos/power.h |1 +
> 2 files changed, 16 insertions(+)
>
> diff --git a/arch/arm/cpu/armv7/exynos/power.c
> b/arch/arm/cpu/armv7/exynos/power.c
> index d4bce6d..73f764e 100644
> --- a/arch/arm/cpu/armv7/exynos/power.c
> +++ b/arch/arm/cpu/armv7/exynos/power.c
> @@ -95,3 +95,18 @@ void set_dp_phy_ctrl(unsigned int enable)
> if (cpu_is_exynos5())
> exynos5_dp_phy_control(enable);
> }
> +
> +/*
> + * This function never returns.
> + * When called this function makes system hang and PAD driving value high
> + * which in turn makes system power down.
> + */
> +void board_poweroff(void)
> +{
> + struct exynos5_power *power =
> + (struct exynos5_power *)samsung_get_base_power();
> +
> + clrbits_le32(&power->ps_hold_control, POWER_PS_HOLD_CONTROL_DATA_HIGH);
> +
> + hang();
> +}
We can use set_ps_hold_ctrl function with little modification.
Could you please check this?
Thanks,
Minkyu Kang.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/9 v9] EXYNOS5: TMU: Add TMU init and status check
On 06/02/13 22:18, Akshay Saraswat wrote:
> This adds call to tmu_init() and TMU boot time analysis
> for the SoC temperature threshold breach.
>
> Signed-off-by: Akshay Saraswat
> Acked-by: Simon Glass
> ---
> Changes since v8:
> - None.
>
> board/samsung/smdk5250/smdk5250.c | 35 +++
> 1 file changed, 35 insertions(+)
>
> diff --git a/board/samsung/smdk5250/smdk5250.c
> b/board/samsung/smdk5250/smdk5250.c
> index 7a5f132..7b9a8c5 100644
> --- a/board/samsung/smdk5250/smdk5250.c
> +++ b/board/samsung/smdk5250/smdk5250.c
> @@ -35,9 +35,35 @@
> #include
> #include
> #include
> +#include
>
> DECLARE_GLOBAL_DATA_PTR;
>
> +#if defined CONFIG_EXYNOS_TMU
> +/*
> + * Boot Time Thermal Analysis for SoC temperature threshold breach
> + */
> +void boot_temp_check(void)
static?
> +{
> + int temp;
> +
> + switch (tmu_monitor(&temp)) {
> + case TMU_STATUS_TRIPPED:
> + puts("EXYNOS_TMU: TRIPPING! Device power going down ...\n");
> + board_poweroff();
> + break;
> + case TMU_STATUS_WARNING:
> + puts("EXYNOS_TMU: WARNING! Temperature very high\n");
> + break;
> + case TMU_STATUS_NORMAL:
> + break;
no action? then please remove it.
> + case TMU_STATUS_INIT:
is it unknown state?
> + default:
> + debug("Unknown TMU state\n");
> + }
> +}
> +#endif
> +
> #ifdef CONFIG_USB_EHCI_EXYNOS
> int board_usb_vbus_init(void)
> {
> @@ -57,6 +83,15 @@ int board_usb_vbus_init(void)
> int board_init(void)
> {
> gd->bd->bi_boot_params = (PHYS_SDRAM_1 + 0x100UL);
> +
> +#if defined CONFIG_EXYNOS_TMU
> + if (tmu_init(gd->fdt_blob)) {
> + debug("%s: Failed to init TMU\n", __func__);
> + return -1;
> + }
> + boot_temp_check();
> +#endif
> +
> #ifdef CONFIG_EXYNOS_SPI
> spi_init();
> #endif
>
Thanks,
Minkyu Kang.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 8/9 v9] EXYNOS5: TMU: Add hardware tripping
Dear Akshay,
On 06/02/13 22:18, Akshay Saraswat wrote:
> This adds hardware tripping at 110 degrees celsius which must enable
> forced system shutdown in case TMU fails to power off.
>
> Signed-off-by: Akshay Saraswat
> Acked-by: Simon Glass
> ---
> Changes since v8:
> - None.
>
> arch/arm/cpu/armv7/exynos/power.c| 10 ++
> arch/arm/include/asm/arch-exynos/power.h |5 +
> drivers/power/exynos-tmu.c | 25 -
> 3 files changed, 35 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm/cpu/armv7/exynos/power.c
> b/arch/arm/cpu/armv7/exynos/power.c
> index 73f764e..234c9f4 100644
> --- a/arch/arm/cpu/armv7/exynos/power.c
> +++ b/arch/arm/cpu/armv7/exynos/power.c
> @@ -96,6 +96,16 @@ void set_dp_phy_ctrl(unsigned int enable)
> exynos5_dp_phy_control(enable);
> }
>
> +/* Enables hardware tripping to power off the system when TMU fails */
> +void power_enable_hw_thermal_trip(void)
please change function name to set_hw_thermal_trip.
and this function should consider exynos4 also.
please refer other functions.
> +{
> + struct exynos5_power *power =
> + (struct exynos5_power *)samsung_get_base_power();
> +
> + /* PS_HOLD_CONTROL register ENABLE_HW_TRIP bit*/
> + setbits_le32(&power->ps_hold_control, POWER_ENABLE_HW_TRIP);
> +}
> +
> /*
> * This function never returns.
> * When called this function makes system hang and PAD driving value high
> diff --git a/arch/arm/include/asm/arch-exynos/power.h
> b/arch/arm/include/asm/arch-exynos/power.h
> index 7463036..034774f 100644
> --- a/arch/arm/include/asm/arch-exynos/power.h
> +++ b/arch/arm/include/asm/arch-exynos/power.h
> @@ -857,6 +857,9 @@ void set_mipi_phy_ctrl(unsigned int dev_index, unsigned
> int enable);
>
> void set_usbhost_phy_ctrl(unsigned int enable);
>
> +/* Enables hardware tripping to power off the system when TMU fails */
> +void power_enable_hw_thermal_trip(void);
> +
> #define POWER_USB_HOST_PHY_CTRL_EN (1 << 0)
> #define POWER_USB_HOST_PHY_CTRL_DISABLE (0 << 0)
>
> @@ -864,5 +867,7 @@ void set_dp_phy_ctrl(unsigned int enable);
>
> #define EXYNOS_DP_PHY_ENABLE (1 << 0)
> #define POWER_PS_HOLD_CONTROL_DATA_HIGH (1 << 8)
> +#define POWER_ENABLE_HW_TRIP (1UL << 31)
> +
please remove extra space.
>
> #endif
> diff --git a/drivers/power/exynos-tmu.c b/drivers/power/exynos-tmu.c
> index b010883..5885ce7 100644
> --- a/drivers/power/exynos-tmu.c
> +++ b/drivers/power/exynos-tmu.c
> @@ -22,9 +22,11 @@
> #include
> #include
> #include
> +#include
>
> #define TRIMINFO_RELOAD 1
> #define CORE_EN 1
> +#define THERM_TRIP_EN(1 << 12)
>
> #define INTEN_RISE0 1
> #define INTEN_RISE1 (1 << 4)
> @@ -55,6 +57,8 @@ struct temperature_params {
> unsigned int start_warning;
> /* temperature threshold CPU tripping */
> unsigned int start_tripping;
> + /* temperature threshold for HW tripping */
> + unsigned int hardware_tripping;
> };
>
> /* Pre-defined values and thresholds for calibration of current temperature
> */
> @@ -195,6 +199,9 @@ int get_tmu_fdt_values(struct tmu_info *info, const void
> *blob)
> info->data.ts.start_tripping = fdtdec_get_int(blob,
> node, "samsung,start-tripping", -1);
> error |= info->data.ts.start_tripping;
> + info->data.ts.hardware_tripping = fdtdec_get_int(blob,
> + node, "samsung,hw-tripping", -1);
> + error |= info->data.ts.hardware_tripping;
> info->data.efuse_min_value = fdtdec_get_int(blob,
> node, "samsung,efuse-min-value", -1);
> error |= info->data.efuse_min_value;
> @@ -228,7 +235,7 @@ int get_tmu_fdt_values(struct tmu_info *info, const void
> *blob)
> void tmu_setup_parameters(struct tmu_info *info)
> {
> unsigned int te_code, con;
> - unsigned int warning_code, trip_code;
> + unsigned int warning_code, trip_code, hwtrip_code;
> unsigned int cooling_temp;
> unsigned int rising_value;
> struct tmu_data *data = &info->data;
> @@ -252,9 +259,14 @@ void tmu_setup_parameters(struct tmu_info *info)
> + info->te1 - info->dc_value;
> trip_code = data->ts.start_tripping
> + info->te1 - info->dc_value;
> + hwtrip_code = data->ts.hardware_tripping
> + + info->te1 - info->dc_value;
> +
> cooling_temp = 0;
>
> - rising_value = ((warning_code << 8) | (trip_code << 16));
> + rising_value = ((warning_code << 8) |
> + (trip_code << 16) |
> + (hwtrip_code << 24));
>
> /* Set interrupt level */
> writel(rising_value, ®->threshold_temp_rise);
> @@ -274,12 +286,15 @@ void tmu_setup_parameters(struct tmu_info *info)
>
> /* TMU core enable */
[U-Boot] [PATCH v3 09/11] Blackfin: spi: add bf6xx spi driver
From: Scott Jiang Spi driver for bf60x is different from old one, so implement a new driver for it. Fix all checkpatch issues memtioned by Wolfgang. Signed-off-by: Scott Jiang Signed-off-by: Sonic Zhang Signed-off-by: Bob Liu --- .../blackfin/include/asm/mach-common/bits/spi6xx.h | 240 +++ drivers/spi/Makefile |1 + drivers/spi/bfin_spi6xx.c | 308 3 files changed, 549 insertions(+), 0 deletions(-) create mode 100644 arch/blackfin/include/asm/mach-common/bits/spi6xx.h create mode 100644 drivers/spi/bfin_spi6xx.c diff --git a/arch/blackfin/include/asm/mach-common/bits/spi6xx.h b/arch/blackfin/include/asm/mach-common/bits/spi6xx.h new file mode 100644 index 000..3368712 --- /dev/null +++ b/arch/blackfin/include/asm/mach-common/bits/spi6xx.h @@ -0,0 +1,240 @@ +/* + * Analog Devices bfin_spi3 controller driver + * + * Copyright (c) 2011 Analog Devices Inc. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * 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., 675 Mass Ave, Cambridge, MA 02139, USA. + */ + +#ifndef _SPI_CHANNEL_H_ +#define _SPI_CHANNEL_H_ + +#include + +/* SPI_CONTROL */ +#define SPI_CTL_EN 0x0001 /* Enable */ +#define SPI_CTL_MSTR0x0002 /* Master/Slave */ +#define SPI_CTL_PSSE0x0004 /* controls modf error in master mode */ +#define SPI_CTL_ODM 0x0008 /* Open Drain Mode */ +#define SPI_CTL_CPHA0x0010 /* Clock Phase */ +#define SPI_CTL_CPOL0x0020 /* Clock Polarity */ +#define SPI_CTL_ASSEL 0x0040 /* Slave Select Pin Control */ +#define SPI_CTL_SELST 0x0080 /* Slave Select Polarity in transfers */ +#define SPI_CTL_EMISO 0x0100 /*Enable MISO */ +#define SPI_CTL_SIZE0x0600 /*Word Transfer Size */ +#define SPI_CTL_SIZE08 0x /*SIZE: 8 bits */ +#define SPI_CTL_SIZE16 0x0200 /*SIZE: 16 bits */ +#define SPI_CTL_SIZE32 0x0400 /*SIZE: 32 bits */ +#define SPI_CTL_LSBF0x1000 /*LSB First */ +#define SPI_CTL_FCEN0x2000 /*Flow-Control Enable */ +#define SPI_CTL_FCCH0x4000 /*Flow-Control Channel Selection */ +#define SPI_CTL_FCPL0x8000 /*Flow-Control Polarity */ +#define SPI_CTL_FCWM0x0003 /*Flow-Control Water-Mark */ +#define SPI_CTL_FIFO0 0x /*FCWM: Tx empty or Rx Full */ +#define SPI_CTL_FIFO1 0x0001 /*FCWM: Tx empty or Rx full (>=75%) */ +#define SPI_CTL_FIFO2 0x0002 /*FCWM: Tx empty or Rx full (>=50%) */ +#define SPI_CTL_FMODE 0x0004 /*Fast-mode Enable */ +#define SPI_CTL_MIOM0x0030 /*Multiple I/O Mode */ +#define SPI_CTL_MIO_DIS 0x /*MIOM: Disable */ +#define SPI_CTL_MIO_DUAL0x0010 /*MIOM: Enable DIOM (Dual I/O Mode) */ +#define SPI_CTL_MIO_QUAD0x0020 /*MIOM: Enable QUAD (Quad SPI Mode) */ +#define SPI_CTL_SOSI0x0040 /*Start on MOSI */ +/* SPI_RX_CONTROL */ +#define SPI_RXCTL_REN 0x0001 /*Receive Channel Enable */ +#define SPI_RXCTL_RTI 0x0004 /*Receive Transfer Initiate */ +#define SPI_RXCTL_RWCEN 0x0008 /*Receive Word Counter Enable */ +#define SPI_RXCTL_RDR 0x0070 /*Receive Data Request */ +#define SPI_RXCTL_RDR_DIS 0x /*RDR: Disabled */ +#define SPI_RXCTL_RDR_NE0x0010 /*RDR: RFIFO not empty */ +#define SPI_RXCTL_RDR_250x0020 /*RDR: RFIFO 25% full */ +#define SPI_RXCTL_RDR_500x0030 /*RDR: RFIFO 50% full */ +#define SPI_RXCTL_RDR_750x0040 /*RDR: RFIFO 75% full */ +#define SPI_RXCTL_RDR_FULL 0x0050 /*RDR: RFIFO full */ +#define SPI_RXCTL_RDO 0x0100 /*Receive Data Over-Run */ +#define SPI_RXCTL_RRWM 0x3000 /*FIFO Regular Water-Mark */ +#define SPI_RXCTL_RWM_0 0x /*RRWM: RFIFO Empty */ +#define SPI_RXCTL_RWM_250x1000 /*RRWM: RFIFO 25% full */ +#define SPI_RXCTL_RWM_500x2000 /*RRWM: RFIFO 50% full */ +#define SPI_RXCTL_RWM_750x3000 /*RRWM: RFIFO 75% full */ +#define SPI_RXCTL_RUWM 0x0007 /*FIFO Urgent Water-Mark */ +#define SPI_RXCTL_UWM_DIS 0x /*RUWM: Disabled */ +#define SPI_RXCTL_UWM_250x0001 /*RUWM: RFIFO 25% full */ +#define SPI_RXCTL_UWM_500x0002 /*RUWM: RFIFO 50% full */ +#define SPI_RXCTL_UWM_750x0003 /*RUWM: RFIFO 75% full */ +#define SPI_RXCTL_UWM_FULL 0x0004 /*RUWM: RFIFO full */ +/* SPI_TX_CONTROL */ +#define SP
[U-Boot] [PATCH v3 10/11] Blackfin: bf60x: add hw watchdog support
From: Bob Liu
Signed-off-by: Bob Liu
Signed-off-by: Sonic Zhang
---
arch/blackfin/cpu/initcode.c | 13 +
arch/blackfin/cpu/start.S |2 ++
include/configs/bf609-ezkit.h |1 +
3 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/arch/blackfin/cpu/initcode.c b/arch/blackfin/cpu/initcode.c
index e304d3e..374fe6d 100644
--- a/arch/blackfin/cpu/initcode.c
+++ b/arch/blackfin/cpu/initcode.c
@@ -461,8 +461,21 @@ program_early_devices(ADI_BOOT_DATA *bs, uint *sdivB, uint
*divB, uint *vcoB)
*/
if (CONFIG_BFIN_BOOT_MODE != BFIN_BOOT_BYPASS) {
serial_putc('e');
+#ifdef __ADSPBF60x__
+ bfin_write_SEC_GCTL(0x2);
+ SSYNC();
+ bfin_write_SEC_FCTL(0xc1);
+ bfin_write_SEC_SCTL(2, bfin_read_SEC_SCTL(2) | 0x6);
+
+ bfin_write_SEC_CCTL(0x2);
+ SSYNC();
+ bfin_write_SEC_GCTL(0x1);
+ bfin_write_SEC_CCTL(0x1);
+#endif
bfin_write_WDOG_CNT(MSEC_TO_SCLK(CONFIG_HW_WATCHDOG_TIMEOUT_INITCODE));
+#if CONFIG_BFIN_BOOT_MODE != BFIN_BOOT_UART
bfin_write_WDOG_CTL(0);
+#endif
serial_putc('f');
}
#endif
diff --git a/arch/blackfin/cpu/start.S b/arch/blackfin/cpu/start.S
index 90b4d1a..7155fc8 100644
--- a/arch/blackfin/cpu/start.S
+++ b/arch/blackfin/cpu/start.S
@@ -65,6 +65,7 @@ ENTRY(_start)
p5.h = HI(COREMMR_BASE);
#ifdef CONFIG_HW_WATCHDOG
+#ifndef __ADSPBF60x__
# ifndef CONFIG_HW_WATCHDOG_TIMEOUT_START
# define CONFIG_HW_WATCHDOG_TIMEOUT_START 5000
# endif
@@ -78,6 +79,7 @@ ENTRY(_start)
/* fire up the watchdog - R0.L above needs to be 0x */
W[p4 + (WDOG_CTL - SYSMMR_BASE)] = r0;
#endif
+#endif
/* Turn on the serial for debugging the init process */
serial_early_init
diff --git a/include/configs/bf609-ezkit.h b/include/configs/bf609-ezkit.h
index 6dffab8..02149fa 100644
--- a/include/configs/bf609-ezkit.h
+++ b/include/configs/bf609-ezkit.h
@@ -63,6 +63,7 @@
#define CONFIG_SYS_MONITOR_LEN (768 * 1024)
#define CONFIG_SYS_MALLOC_LEN (512 * 1024)
+#define CONFIG_HW_WATCHDOG
/*
* Network Settings
*/
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 03/11] Blackfin: bf60x: add serial support
From: Sonic Zhang
Add serial for bf60x.
Fix issues in Wolfgang's feedback:
1) Replace unreable macro in uart structures with normal types.
2) Replace unreable macro in uart peripheral portmux configuration with
clear inline function.
3) Fix all checkpatch issues
Signed-off-by: Sonic Zhang
Signed-off-by: Bob Liu
---
arch/blackfin/cpu/serial.c | 81 +++--
arch/blackfin/cpu/serial.h | 222 +
arch/blackfin/cpu/serial1.h| 348
arch/blackfin/cpu/serial4.h| 161 +
arch/blackfin/include/asm/mach-bf533/BF531_def.h |1 +
arch/blackfin/include/asm/mach-bf561/BF561_def.h |1 +
arch/blackfin/include/asm/mach-common/bits/uart4.h | 66
7 files changed, 642 insertions(+), 238 deletions(-)
create mode 100644 arch/blackfin/cpu/serial1.h
create mode 100644 arch/blackfin/cpu/serial4.h
create mode 100644 arch/blackfin/include/asm/mach-common/bits/uart4.h
diff --git a/arch/blackfin/cpu/serial.c b/arch/blackfin/cpu/serial.c
index 64340ec..9847e9f 100644
--- a/arch/blackfin/cpu/serial.c
+++ b/arch/blackfin/cpu/serial.c
@@ -43,7 +43,6 @@
#include
#include
#include
-#include
DECLARE_GLOBAL_DATA_PTR;
@@ -52,8 +51,8 @@ DECLARE_GLOBAL_DATA_PTR;
#include "serial.h"
#ifdef CONFIG_DEBUG_SERIAL
-static uint16_t cached_lsr[256];
-static uint16_t cached_rbr[256];
+static uart_lsr_t cached_lsr[256];
+static uart_lsr_t cached_rbr[256];
static size_t cache_count;
/* The LSR is read-to-clear on some parts, so we have to make sure status
@@ -61,10 +60,10 @@ static size_t cache_count;
* works around anomaly 0599 at the same time by keeping a cumulative
* tally of all the status bits.
*/
-static uint16_t uart_lsr_save;
-static uint16_t uart_lsr_read(uint32_t uart_base)
+static uart_lsr_t uart_lsr_save;
+static uart_lsr_t uart_lsr_read(uint32_t uart_base)
{
- uint16_t lsr = bfin_read(&pUART->lsr);
+ uart_lsr_t lsr = _lsr_read(pUART);
uart_lsr_save |= (lsr & (OE|PE|FE|BI));
return lsr | uart_lsr_save;
}
@@ -72,20 +71,20 @@ static uint16_t uart_lsr_read(uint32_t uart_base)
static void uart_lsr_clear(uint32_t uart_base)
{
uart_lsr_save = 0;
- bfin_write(&pUART->lsr, bfin_read(&pUART->lsr) | -1);
+ _lsr_write(pUART, -1);
}
#else
/* When debugging is disabled, we only care about the DR bit, so if other
* bits get set/cleared, we don't really care since we don't read them
* anyways (and thus anomaly 0599 is irrelevant).
*/
-static inline uint16_t uart_lsr_read(uint32_t uart_base)
+static inline uart_lsr_t uart_lsr_read(uint32_t uart_base)
{
- return bfin_read(&pUART->lsr);
+ return _lsr_read(pUART);
}
static void uart_lsr_clear(uint32_t uart_base)
{
- bfin_write(&pUART->lsr, bfin_read(&pUART->lsr) | -1);
+ _lsr_write(pUART, -1);
}
#endif
@@ -127,20 +126,14 @@ static int uart_getc(uint32_t uart_base)
#ifdef CONFIG_DEBUG_SERIAL
/* grab & clear the LSR */
- uint16_t uart_lsr_val = uart_lsr_read(uart_base);
+ uart_lsr_t uart_lsr_val = uart_lsr_read(uart_base);
cached_lsr[cache_count] = uart_lsr_val;
cached_rbr[cache_count] = uart_rbr_val;
cache_count = (cache_count + 1) % ARRAY_SIZE(cached_lsr);
if (uart_lsr_val & (OE|PE|FE|BI)) {
- uint16_t dll, dlh;
printf("\n[SERIAL ERROR]\n");
- ACCESS_LATCH();
- dll = bfin_read(&pUART->dll);
- dlh = bfin_read(&pUART->dlh);
- ACCESS_PORT_IER();
- printf("\tDLL=0x%x DLH=0x%x\n", dll, dlh);
do {
--cache_count;
printf("\t%3zu: RBR=0x%02x LSR=0x%02x\n", cache_count,
@@ -160,6 +153,8 @@ static int uart_getc(uint32_t uart_base)
# define LOOP(x)
#endif
+#if BFIN_UART_HW_VER < 4
+
LOOP(
static void uart_loop(uint32_t uart_base, int state)
{
@@ -178,6 +173,28 @@ static void uart_loop(uint32_t uart_base, int state)
}
)
+#else
+
+LOOP(
+static void uart_loop(uint32_t uart_base, int state)
+{
+ u32 control;
+
+ /* Drain the TX fifo first so bytes don't come back */
+ while (!(uart_lsr_read(uart_base) & TEMT))
+ continue;
+
+ control = bfin_read(&pUART->control);
+ if (state)
+ control |= LOOP_ENA | MRTS;
+ else
+ control &= ~(LOOP_ENA | MRTS);
+ bfin_write(&pUART->control, control);
+}
+)
+
+#endif
+
#ifdef CONFIG_SYS_BFIN_UART
static void uart_puts(uint32_t uart_base, const char *s)
@@ -246,16 +263,16 @@ struct serial_device bfin_serial##n##_device = { \
LOOP(.loop = uart##n##_loop) \
};
-#ifdef UART0_DLL
+#ifdef UART0_RBR
DECL_BFIN_UART(0)
#endif
-#ifdef UART1_DLL
+#ifdef UART1_RBR
DECL_BFIN_UART(1)
#endif
-#ifdef UART2_DLL
+#ifdef UART2_RBR
DECL_BFIN_UART(2)
#endif
-#ifdef UART3_DLL
+#ifdef UART3_RBR
DE
[U-Boot] [PATCH v3 00/11] Add BF60x processor support to Blackfin architecture.
From: Sonic Zhang ADSP-BF60x is the new generation Blackfin® dual-core processor announced by Analog Devices in late March, 2012. This patch set adds BF60x processor support to Das U-Boot Blackfin architecture. For more information, see http://blackfin.uclinux.org . The v3 patches fix the review issues against v1 and v2 from Wolfgang. See the change log in each patches for details. Bob Liu (5): Blackfin: bf60x: new processor header files Blackfin: bf60x: add dma support Blackfin: bf60x: support big cplb page Blackfin: bf60x: add gpio support Blackfin: bf60x: add hw watchdog support Scott Jiang (1): Blackfin: spi: add bf6xx spi driver Sonic Zhang (4): Blackfin: bf60x: Port blackfin core architecture code to boot on bf60x. Blackfin: bf60x: add serial support blackfin: bf609: add board and headers files to support bf609 Blackfin: bf60x: add rsi/sdh support Steven Miao (1): Blackfin: bf60x: add resume from hibernate MAINTAINERS|3 +- arch/blackfin/cpu/cpu.c|4 +- arch/blackfin/cpu/gpio.c | 36 ++- arch/blackfin/cpu/initcode.c | 385 +++- arch/blackfin/cpu/initcode.h | 52 +++ arch/blackfin/cpu/reset.c |6 + arch/blackfin/cpu/serial.c | 81 +++-- arch/blackfin/cpu/serial.h | 222 +--- arch/blackfin/cpu/serial1.h| 348 ++ arch/blackfin/cpu/serial4.h| 161 arch/blackfin/cpu/start.S |2 + arch/blackfin/include/asm/blackfin_cdef.h |3 + arch/blackfin/include/asm/blackfin_def.h |5 + arch/blackfin/include/asm/blackfin_local.h |3 + arch/blackfin/include/asm/config-pre.h |4 + arch/blackfin/include/asm/cplb.h | 31 ++- arch/blackfin/include/asm/dma.h| 81 +++-- arch/blackfin/include/asm/gpio.h |2 +- arch/blackfin/include/asm/mach-bf533/BF531_def.h |1 + arch/blackfin/include/asm/mach-bf561/BF561_def.h |1 + arch/blackfin/include/asm/mach-bf609/BF609_cdef.h | 192 ++ arch/blackfin/include/asm/mach-bf609/BF609_def.h | 241 arch/blackfin/include/asm/mach-bf609/anomaly.h | 97 + arch/blackfin/include/asm/mach-bf609/def_local.h |5 + arch/blackfin/include/asm/mach-bf609/gpio.h| 151 arch/blackfin/include/asm/mach-bf609/portmux.h | 257 + arch/blackfin/include/asm/mach-bf609/ports.h | 103 ++ arch/blackfin/include/asm/mach-common/bits/cgu.h | 80 arch/blackfin/include/asm/mach-common/bits/dde.h | 88 + arch/blackfin/include/asm/mach-common/bits/dma.h | 54 +++- arch/blackfin/include/asm/mach-common/bits/mpu.h |6 +- arch/blackfin/include/asm/mach-common/bits/pll.h |5 + arch/blackfin/include/asm/mach-common/bits/sdh.h | 38 ++- .../blackfin/include/asm/mach-common/bits/spi6xx.h | 240 arch/blackfin/include/asm/mach-common/bits/uart4.h | 66 arch/blackfin/lib/board.c | 25 ++- arch/blackfin/lib/clocks.c | 112 +- arch/blackfin/lib/string.c | 97 +++--- board/bf609-ezkit/Makefile | 55 +++ board/bf609-ezkit/bf609-ezkit.c| 67 boards.cfg |1 + common/cmd_reginfo.c | 19 +- drivers/mmc/bfin_sdh.c | 68 +++- drivers/spi/Makefile |1 + drivers/spi/bfin_spi6xx.c | 308 include/configs/bf609-ezkit.h | 162 include/configs/bfin_adi_common.h | 12 +- 47 files changed, 3585 insertions(+), 396 deletions(-) create mode 100644 arch/blackfin/cpu/serial1.h create mode 100644 arch/blackfin/cpu/serial4.h create mode 100644 arch/blackfin/include/asm/mach-bf609/BF609_cdef.h create mode 100644 arch/blackfin/include/asm/mach-bf609/BF609_def.h create mode 100644 arch/blackfin/include/asm/mach-bf609/anomaly.h create mode 100644 arch/blackfin/include/asm/mach-bf609/def_local.h create mode 100644 arch/blackfin/include/asm/mach-bf609/gpio.h create mode 100644 arch/blackfin/include/asm/mach-bf609/portmux.h create mode 100644 arch/blackfin/include/asm/mach-bf609/ports.h create mode 100644 arch/blackfin/include/asm/mach-common/bits/cgu.h create mode 100644 arch/blackfin/include/asm/mach-common/bits/dde.h create mode 100644 arch/blackfin/include/asm/mach-common/bits/spi6xx.h create mode 100644 arch/blackfin/include/asm/mach-common/bits/uart4.h create mode 100644 board/bf609-ezkit/Makefile create mode 100644 board/bf
[U-Boot] [PATCH v3 07/11] blackfin: bf609: add board and headers files to support bf609
From: Sonic Zhang
Board and config header files for bf609-ezkit support.
Fix review issues from Wolfgang:
1) Fix all checkpatch issues except for cpu name bf609-0.0. It is used as the
link flags and is not an error.
2) Remove the values for variables in bf609 config headers whose values are
useless.
Signed-off-by: Bob Liu
Signed-off-by: Sonic Zhang
---
MAINTAINERS |3 +-
board/bf609-ezkit/Makefile| 55 +
board/bf609-ezkit/bf609-ezkit.c | 67 +++
boards.cfg|1 +
include/configs/bf609-ezkit.h | 161 +
include/configs/bfin_adi_common.h | 12 ++--
6 files changed, 292 insertions(+), 7 deletions(-)
create mode 100644 board/bf609-ezkit/Makefile
create mode 100644 board/bf609-ezkit/bf609-ezkit.c
create mode 100644 include/configs/bf609-ezkit.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 28c052d..76368cf 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1214,7 +1214,7 @@ Yoshihiro Shimoda
# Board CPU #
#
-Mike Frysinger
+Sonic Zhang
Blackfin Team
BF506F-EZKITBF506
@@ -1231,6 +1231,7 @@ Blackfin Team
BF538F-EZKITBF538
BF548-EZKIT BF548
BF561-EZKIT BF561
+ BF609-EZKIT BF609
M.Hasewinkel (MHA)
diff --git a/board/bf609-ezkit/Makefile b/board/bf609-ezkit/Makefile
new file mode 100644
index 000..0bb8fe6
--- /dev/null
+++ b/board/bf609-ezkit/Makefile
@@ -0,0 +1,55 @@
+#
+# U-boot - Makefile
+#
+# Copyright (c) 2005-2008 Analog Device Inc.
+#
+# (C) Copyright 2000-2006
+# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+# MA 02111-1307 USA
+#
+
+include $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(BOARD).o
+
+COBJS-y:= $(BOARD).o
+COBJS-$(CONFIG_BFIN_SOFT_SWITCH) += soft_switch.o
+
+SRCS := $(SOBJS-y:.o=.S) $(COBJS-y:.o=.c)
+OBJS := $(addprefix $(obj),$(COBJS-y))
+SOBJS := $(addprefix $(obj),$(SOBJS-y))
+
+$(LIB):$(obj).depend $(OBJS) $(SOBJS)
+ $(call cmd_link_o_target, $(OBJS) $(SOBJS))
+
+clean:
+ rm -f $(SOBJS) $(OBJS)
+
+distclean: clean
+ rm -f $(LIB) core *.bak $(obj).depend
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/board/bf609-ezkit/bf609-ezkit.c b/board/bf609-ezkit/bf609-ezkit.c
new file mode 100644
index 000..0388226
--- /dev/null
+++ b/board/bf609-ezkit/bf609-ezkit.c
@@ -0,0 +1,67 @@
+/*
+ * U-boot - main board file
+ *
+ * Copyright (c) 2008-2011 Analog Devices Inc.
+ *
+ * Licensed under the GPL-2 or later.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include "soft_switch.h"
+
+int checkboard(void)
+{
+ printf("Board: ADI BF609 EZ-Kit board\n");
+ printf(" Support: http://blackfin.uclinux.org/\n";);
+ return 0;
+}
+
+int board_early_init_f(void)
+{
+ static const unsigned short pins[] = {
+ P_A3, P_A4, P_A5, P_A6, P_A7, P_A8, P_A9, P_A10, P_A11, P_A12,
+ P_A13, P_A14, P_A15, P_A16, P_A17, P_A18, P_A19, P_A20, P_A21,
+ P_A22, P_A23, P_A24, P_A25, P_NORCK, 0,
+ };
+ peripheral_request_list(pins, "smc0");
+
+ return 0;
+}
+
+#ifdef CONFIG_DESIGNWARE_ETH
+int board_eth_init(bd_t *bis)
+{
+ int ret = 0;
+
+ if (CONFIG_DW_PORTS & 1) {
+ static const unsigned short pins[] = P_RMII0;
+ if (!peripheral_request_list(pins, "emac0"))
+ ret += designware_initialize(0, EMAC0_MACCFG, 1, 0);
+ }
+ if (CONFIG_DW_PORTS & 2) {
+ static const unsigned short pins[] = P_RMII1;
+ if (!peripheral_request_list(pins, "emac1"))
+ ret += designware_initialize(1, EMAC1_MACCFG, 1, 0);
+ }
+
+ return ret;
+}
+#endif
+
+#ifdef CONFIG_BFIN_SDH
+int board_mmc_init(bd_t *bis)
+{
+ return bfin_mmc_init(bis);
+}
+#endif
+
+/* m
[U-Boot] [PATCH v3 02/11] Blackfin: bf60x: Port blackfin core architecture code to boot on bf60x.
From: Sonic Zhang
Set up clocks, DDR controller, Nor flash controller, reboot,
serial port. Add new SPI boot modes.
Fix review issue form Wolfgang:
1) Fix all checkpatch issues.
2) Clean up and merge redundant #ifdef's.
3) Spearate declarations and code by a blankline.
Signed-off-by: Bob Liu
Signed-off-by: Sonic Zhang
---
arch/blackfin/cpu/cpu.c|4 +-
arch/blackfin/cpu/initcode.c | 326 ++--
arch/blackfin/cpu/initcode.h | 52 +
arch/blackfin/cpu/reset.c |6 +
arch/blackfin/include/asm/config-pre.h |4 +
arch/blackfin/lib/board.c |6 +
arch/blackfin/lib/clocks.c | 112 +--
common/cmd_reginfo.c | 19 ++-
8 files changed, 487 insertions(+), 42 deletions(-)
diff --git a/arch/blackfin/cpu/cpu.c b/arch/blackfin/cpu/cpu.c
index 6a0bcca..b9fdb07 100644
--- a/arch/blackfin/cpu/cpu.c
+++ b/arch/blackfin/cpu/cpu.c
@@ -68,7 +68,9 @@ void cpu_init_f(ulong bootflag, ulong loaded_from_ldr)
/* Reset upon a double exception rather than just hanging.
* Do not do bfin_read on SWRST as that will reset status bits.
*/
+# ifdef SWRST
bfin_write_SWRST(DOUBLE_FAULT);
+# endif
#endif
serial_early_puts("Board init flash\n");
@@ -92,7 +94,7 @@ int irq_init(void)
#elif defined(SICA_IMASK0)
bfin_write_SICA_IMASK0(0);
bfin_write_SICA_IMASK1(0);
-#else
+#elif defined(SIC_IMASK)
bfin_write_SIC_IMASK(0);
#endif
/* Set up a dummy NMI handler if needed. */
diff --git a/arch/blackfin/cpu/initcode.c b/arch/blackfin/cpu/initcode.c
index fb3a101..e304d3e 100644
--- a/arch/blackfin/cpu/initcode.c
+++ b/arch/blackfin/cpu/initcode.c
@@ -15,20 +15,141 @@
#include
#include
#include
-#include
-#include
-#include
#define BUG() while (1) { asm volatile("emuexcpt;"); }
#include "serial.h"
+#ifndef __ADSPBF60x__
+#include
+#include
+#else /* __ADSPBF60x__ */
+#include
+
+#define CONFIG_BFIN_GET_DCLK_M \
+ ((CONFIG_CLKIN_HZ*CONFIG_VCO_MULT)/(CONFIG_DCLK_DIV*100))
+
+#ifndef CONFIG_DMC_DDRCFG
+#if ((CONFIG_BFIN_GET_DCLK_M != 125) && \
+ (CONFIG_BFIN_GET_DCLK_M != 133) && \
+ (CONFIG_BFIN_GET_DCLK_M != 150) && \
+ (CONFIG_BFIN_GET_DCLK_M != 166) && \
+ (CONFIG_BFIN_GET_DCLK_M != 200) && \
+ (CONFIG_BFIN_GET_DCLK_M != 225) && \
+ (CONFIG_BFIN_GET_DCLK_M != 250))
+#error "DDR2 CLK must be in (125, 133, 150, 166, 200, 225, 250)MHz"
+#endif
+#endif
+
+/* DMC control bits */
+#define SRREQ 0x8
+
+/* DMC status bits */
+#define IDLE0x1
+#define MEMINITDONE 0x4
+#define SRACK 0x8
+#define PDACK 0x10
+#define DPDACK 0x20
+#define DLLCALDONE 0x2000
+#define PENDREF 0xF
+#define PHYRDPHASE 0xF0
+#define PHYRDPHASE_OFFSET 20
+
+/* DMC DLL control bits */
+#define DLLCALRDCNT 0xFF
+#define DATACYC_OFFSET 8
+
+struct ddr_config {
+ u32 ddr_clk;
+ u32 dmc_ddrctl;
+ u32 dmc_ddrcfg;
+ u32 dmc_ddrtr0;
+ u32 dmc_ddrtr1;
+ u32 dmc_ddrtr2;
+ u32 dmc_ddrmr;
+ u32 dmc_ddrmr1;
+};
+
+static struct ddr_config ddr_config_table[] = {
+ [0] = {
+ .ddr_clk= 125, /* 125MHz */
+ .dmc_ddrctl = 0x0904,
+ .dmc_ddrcfg = 0x0422,
+ .dmc_ddrtr0 = 0x20705212,
+ .dmc_ddrtr1 = 0x201003CF,
+ .dmc_ddrtr2 = 0x00320107,
+ .dmc_ddrmr = 0x0422,
+ .dmc_ddrmr1 = 0x4,
+ },
+ [1] = {
+ .ddr_clk= 133, /* 133MHz */
+ .dmc_ddrctl = 0x0904,
+ .dmc_ddrcfg = 0x0422,
+ .dmc_ddrtr0 = 0x20806313,
+ .dmc_ddrtr1 = 0x2013040D,
+ .dmc_ddrtr2 = 0x00320108,
+ .dmc_ddrmr = 0x0632,
+ .dmc_ddrmr1 = 0x4,
+ },
+ [2] = {
+ .ddr_clk= 150, /* 150MHz */
+ .dmc_ddrctl = 0x0904,
+ .dmc_ddrcfg = 0x0422,
+ .dmc_ddrtr0 = 0x20A07323,
+ .dmc_ddrtr1 = 0x20160492,
+ .dmc_ddrtr2 = 0x00320209,
+ .dmc_ddrmr = 0x0632,
+ .dmc_ddrmr1 = 0x4,
+ },
+ [3] = {
+ .ddr_clk= 166, /* 166MHz */
+ .dmc_ddrctl = 0x0904,
+ .dmc_ddrcfg = 0x0422,
+ .dmc_ddrtr0 = 0x20A07323,
+ .dmc_ddrtr1 = 0x2016050E,
+ .dmc_ddrtr2 = 0x00320209,
+ .dmc_ddrmr = 0x0632,
+ .dmc_ddrmr1 = 0x4,
+ },
+ [4] = {
+ .ddr_clk= 200, /* 200MHz */
+ .dmc_ddrctl = 0x0904,
+ .dmc_ddrcfg = 0x0422,
+ .dmc_ddrtr0 = 0x20a
Re: [U-Boot] [PATCH 2/2] EXYNOS5: Snow: Add a configuration file
Dear Rajeshwari, On 14/02/13 15:33, Rajeshwari Shinde wrote: > This patch adds the configuration file for Snow Board and > defines the same in boards.cfg. > > Signed-off-by: Rajeshwari Shinde > Acked-by: Simon Glass > --- > boards.cfg |1 + > include/configs/snow.h | 33 + Missing MAINTAINERS entry. > 2 files changed, 34 insertions(+), 0 deletions(-) > create mode 100644 include/configs/snow.h > > diff --git a/boards.cfg b/boards.cfg > index 0507a9c..c13519e 100644 > --- a/boards.cfg > +++ b/boards.cfg > @@ -286,6 +286,7 @@ s5p_goni arm armv7 goni >samsung > smdkc100 arm armv7 smdkc100 > samsungs5pc1xx > origenarm armv7 origen > samsungexynos > s5pc210_universalarm armv7 universal_c210 > samsungexynos > +snow arm armv7 smdk5250 > samsungexynos > smdk5250 arm armv7 smdk5250 > samsungexynos > smdkv310 arm armv7 smdkv310 > samsungexynos > tratsarm armv7 trats > samsungexynos > diff --git a/include/configs/snow.h b/include/configs/snow.h > new file mode 100644 > index 000..b8460fd > --- /dev/null > +++ b/include/configs/snow.h > @@ -0,0 +1,33 @@ > +/* > + * Copyright (C) 2013 Samsung Electronics > + * > + * Configuration settings for the SAMSUNG EXYNOS5 Snow board. > + * > + * 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 > + */ > + > +#ifndef __CONFIG_SNOW_H > +#define __CONFIG_SNOW_H > + > +#include > + > +#undef CONFIG_DEFAULT_DEVICE_TREE > +#define CONFIG_DEFAULT_DEVICE_TREE exynos5250-snow > + > +#endif /* __CONFIG_SNOW_H */ > Thanks, Minkyu Kang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 11/11] Blackfin: bf60x: add resume from hibernate
From: Steven Miao
Add Bf60x resume from hibernate support
Fix all checkpatch issues.
Signed-off-by: Steven Miao
Signed-off-by: Sonic Zhang
Signed-off-by: Bob Liu
---
arch/blackfin/cpu/initcode.c | 46 ++
1 files changed, 46 insertions(+), 0 deletions(-)
diff --git a/arch/blackfin/cpu/initcode.c b/arch/blackfin/cpu/initcode.c
index 374fe6d..bfd64a2 100644
--- a/arch/blackfin/cpu/initcode.c
+++ b/arch/blackfin/cpu/initcode.c
@@ -509,6 +509,11 @@ maybe_self_refresh(ADI_BOOT_DATA *bs)
return false;
#ifdef __ADSPBF60x__
+ /* resume from hibernate, return false let ddr initialize */
+ if ((bfin_read32(DPM0_STAT) & 0xF0) == 0x50) {
+ serial_putc('b');
+ return false;
+ }
#else /* __ADSPBF60x__ */
@@ -827,6 +832,7 @@ program_memory_controller(ADI_BOOT_DATA *bs, bool
put_into_srfs)
while (!(bfin_read_DMC0_STAT() & DLLCALDONE))
continue;
serial_putc('!');
+
#else /* __ADSPBF60x__ */
/* Program the external memory controller before we come out of
@@ -894,7 +900,46 @@ check_hibernation(ADI_BOOT_DATA *bs, u16 vr_ctl, bool
put_into_srfs)
return;
serial_putc('b');
+#ifdef __ADSPBF60x__
+ if (bfin_read32(DPM0_RESTORE0) != 0) {
+ uint32_t reg = bfin_read_DMC0_CTL();
+ reg &= ~0x8;
+ bfin_write_DMC0_CTL(reg);
+
+ while ((bfin_read_DMC0_STAT() & 0x8))
+ continue;
+ while (!(bfin_read_DMC0_STAT() & 0x1))
+ continue;
+ serial_putc('z');
+ uint32_t *hibernate_magic = bfin_read32(DPM0_RESTORE4);
+ SSYNC(); /* make sure memory controller is done */
+ if (hibernate_magic[0] == 0xDEADBEEF) {
+ serial_putc('c');
+ SSYNC();
+ bfin_write_EVT15(hibernate_magic[1]);
+ bfin_write_IMASK(EVT_IVG15);
+ __asm__ __volatile__ (
+ /* load reti early to avoid anomaly 281 */
+ "reti = %2;"
+ /* clear hibernate magic */
+ "[%0] = %1;"
+ /* load stack pointer */
+ "SP = [%0 + 8];"
+ /* lower ourselves from reset ivg to ivg15 */
+ "raise 15;"
+ "nop;nop;nop;"
+ "rti;"
+ :
+ : "p"(hibernate_magic),
+ "d"(0x2000 /* jump.s 0 */),
+ "d"(0xffa0)
+ );
+ }
+
+
+ }
+#else
/* Are we coming out of hibernate (suspend to memory) ?
* The memory layout is:
* 0x0: hibernate magic for anomaly 307 (0xDEADBEEF)
@@ -927,6 +972,7 @@ check_hibernation(ADI_BOOT_DATA *bs, u16 vr_ctl, bool
put_into_srfs)
}
serial_putc('d');
}
+#endif
serial_putc('e');
}
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 06/11] Blackfin: bf60x: add gpio support
From: Bob Liu
Signed-off-by: Bob Liu
Signed-off-by: Sonic Zhang
---
arch/blackfin/cpu/gpio.c| 36 +--
arch/blackfin/include/asm/gpio.h|2 +-
arch/blackfin/include/asm/mach-bf609/gpio.h | 151 +++
3 files changed, 181 insertions(+), 8 deletions(-)
create mode 100644 arch/blackfin/include/asm/mach-bf609/gpio.h
diff --git a/arch/blackfin/cpu/gpio.c b/arch/blackfin/cpu/gpio.c
index 5674d42..f684be5 100644
--- a/arch/blackfin/cpu/gpio.c
+++ b/arch/blackfin/cpu/gpio.c
@@ -66,6 +66,14 @@ static struct gpio_port_t * const gpio_array[] = {
(struct gpio_port_t *)PORTH_FER,
(struct gpio_port_t *)PORTI_FER,
(struct gpio_port_t *)PORTJ_FER,
+#elif defined(CONFIG_BF60x)
+ (struct gpio_port_t *)PORTA_FER,
+ (struct gpio_port_t *)PORTB_FER,
+ (struct gpio_port_t *)PORTC_FER,
+ (struct gpio_port_t *)PORTD_FER,
+ (struct gpio_port_t *)PORTE_FER,
+ (struct gpio_port_t *)PORTF_FER,
+ (struct gpio_port_t *)PORTG_FER,
#else
# error no gpio arrays defined
#endif
@@ -216,6 +224,12 @@ static void port_setup(unsigned gpio, unsigned short usage)
else
gpio_array[gpio_bank(gpio)]->port_fer |= gpio_bit(gpio);
SSYNC();
+#elif defined(CONFIG_BF60x)
+ if (usage == GPIO_USAGE)
+ gpio_array[gpio_bank(gpio)]->port_fer_clear = gpio_bit(gpio);
+ else
+ gpio_array[gpio_bank(gpio)]->port_fer_set = gpio_bit(gpio);
+ SSYNC();
#endif
}
@@ -290,7 +304,7 @@ static void portmux_setup(unsigned short per)
}
}
}
-#elif defined(CONFIG_BF54x)
+#elif defined(CONFIG_BF54x) || defined(CONFIG_BF60x)
inline void portmux_setup(unsigned short per)
{
u32 pmux;
@@ -330,7 +344,7 @@ inline void portmux_setup(unsigned short per)
# define portmux_setup(...) do { } while (0)
#endif
-#ifndef CONFIG_BF54x
+#if !defined(CONFIG_BF54x) && !defined(CONFIG_BF60x)
/***
*
* FUNCTIONS: Blackfin General Purpose Ports Access Functions
@@ -534,7 +548,7 @@ int peripheral_request(unsigned short per, const char
*label)
* be requested and used by several drivers
*/
-#ifdef CONFIG_BF54x
+#if defined(CONFIG_BF54x) || defined(CONFIG_BF60x)
if (!((per & P_MAYSHARE) && get_portmux(per) ==
P_FUNCT2MUX(per))) {
#else
if (!(per & P_MAYSHARE)) {
@@ -651,7 +665,7 @@ int bfin_gpio_request(unsigned gpio, const char *label)
gpio, get_label(gpio));
return -EBUSY;
}
-#ifndef CONFIG_BF54x
+#if !defined(CONFIG_BF54x) && !defined(CONFIG_BF60x)
else { /* Reset POLAR setting when acquiring a gpio for the first time
*/
set_gpio_polar(gpio, 0);
}
@@ -732,12 +746,16 @@ void bfin_special_gpio_free(unsigned gpio)
static inline void __bfin_gpio_direction_input(unsigned gpio)
{
-#ifdef CONFIG_BF54x
+#if defined(CONFIG_BF54x) || defined(CONFIG_BF60x)
gpio_array[gpio_bank(gpio)]->dir_clear = gpio_bit(gpio);
#else
gpio_array[gpio_bank(gpio)]->dir &= ~gpio_bit(gpio);
#endif
+#if defined(CONFIG_BF60x)
+ gpio_array[gpio_bank(gpio)]->inen_set = gpio_bit(gpio);
+#else
gpio_array[gpio_bank(gpio)]->inen |= gpio_bit(gpio);
+#endif
}
int bfin_gpio_direction_input(unsigned gpio)
@@ -785,9 +803,13 @@ int bfin_gpio_direction_output(unsigned gpio, int value)
local_irq_save(flags);
+#if defined(CONFIG_BF60x)
+ gpio_array[gpio_bank(gpio)]->inen_clear = gpio_bit(gpio);
+#else
gpio_array[gpio_bank(gpio)]->inen &= ~gpio_bit(gpio);
+#endif
gpio_set_value(gpio, value);
-#ifdef CONFIG_BF54x
+#if defined(CONFIG_BF54x) || defined(CONFIG_BF60x)
gpio_array[gpio_bank(gpio)]->dir_set = gpio_bit(gpio);
#else
gpio_array[gpio_bank(gpio)]->dir |= gpio_bit(gpio);
@@ -801,7 +823,7 @@ int bfin_gpio_direction_output(unsigned gpio, int value)
int bfin_gpio_get_value(unsigned gpio)
{
-#ifdef CONFIG_BF54x
+#if defined(CONFIG_BF54x) || defined(CONFIG_BF60x)
return (1 & (gpio_array[gpio_bank(gpio)]->data >> gpio_sub_n(gpio)));
#else
unsigned long flags;
diff --git a/arch/blackfin/include/asm/gpio.h b/arch/blackfin/include/asm/gpio.h
index 224688f..05131b5 100644
--- a/arch/blackfin/include/asm/gpio.h
+++ b/arch/blackfin/include/asm/gpio.h
@@ -68,7 +68,7 @@
#ifndef __ASSEMBLY__
-#ifndef CONFIG_BF54x
+#if !defined(CONFIG_BF54x) && !defined(CONFIG_BF60x)
void set_gpio_dir(unsigned, unsigned short);
void set_gpio_inen(unsigned, unsigned short);
void set_gpio_polar(unsigned, unsigned short);
diff --git a/arch/blackfin/include/asm/mach-bf609/gpio.h
b/arch/blackfin/include/asm/mach-bf609/gpio.h
new file mode 100644
index 000..e297bcc
--- /dev/null
+++ b/arch/blackfin/include/asm/mach-bf609/gpio.h
@@ -0,0 +1,151 @@
+/*
+ * Copyright (C) 2008 Analog Devices Inc.
+ * Licensed
[U-Boot] [PATCH v3 04/11] Blackfin: bf60x: add dma support
From: Bob Liu
Add dma support for bf60x.
Fix review issues from Wolfgang:
1) Fix all checkpatch issues.
2) Remove unrelated dma structure change to separate patch.
3) The DMA config MMR on BF60x is 32 bits while it is 16 bits on BF5xx.
The different type of config MMR is correct.
4) Replace unreable macro in dma structures with normal types.
Signed-off-by: Bob Liu
Signed-off-by: Sonic Zhang
---
arch/blackfin/include/asm/dma.h | 81 --
arch/blackfin/include/asm/mach-common/bits/dma.h | 54 +++-
arch/blackfin/lib/string.c | 97 --
3 files changed, 156 insertions(+), 76 deletions(-)
diff --git a/arch/blackfin/include/asm/dma.h b/arch/blackfin/include/asm/dma.h
index 21ff1cf..ef1db6e 100644
--- a/arch/blackfin/include/asm/dma.h
+++ b/arch/blackfin/include/asm/dma.h
@@ -8,7 +8,12 @@
#ifndef _BLACKFIN_DMA_H_
#define _BLACKFIN_DMA_H_
+#include
+#ifdef __ADSPBF60x__
+#include
+#else
#include
+#endif
struct dmasg_large {
void *next_desc_addr;
@@ -30,46 +35,70 @@ struct dmasg {
} __attribute__((packed));
struct dma_register {
+#ifdef __ADSPBF60x__
+ void *next_desc_ptr;/* DMA Next Descriptor Pointer register */
+ u32 start_addr; /* DMA Start address register */
+ u32 config; /* DMA Configuration register */
+
+ u32 x_count;/* DMA x_count register */
+ s32 x_modify; /* DMA x_modify register */
+ u32 y_count;/* DMA y_count register */
+ s32 y_modify; /* DMA y_modify register */
+ u32 __pad0[2];
+
+ void *curr_desc_ptr;/* DMA Curr Descriptor Pointer register */
+ void *prev_desc_ptr;/* DMA Prev Descriptor Pointer register */
+ void *curr_addr;/* DMA Current Address Pointer register */
+ u32 status; /* DMA irq status register */
+ u32 curr_x_count; /* DMA Current x-count register */
+ u32 curr_y_count; /* DMA Current y-count register */
+ u32 __pad1[2];
+
+ u32 bw_limit; /* DMA Bandwidth Limit Count */
+ u32 curr_bw_limit; /* DMA curr Bandwidth Limit Count */
+ u32 bw_monitor; /* DMA Bandwidth Monitor Count */
+ u32 curr_bw_monitor;/* DMA curr Bandwidth Monitor Count */
+#else
void *next_desc_ptr;/* DMA Next Descriptor Pointer register */
- unsigned long start_addr; /* DMA Start address register */
+ u32 start_addr; /* DMA Start address register */
- unsigned short cfg; /* DMA Configuration register */
- unsigned short dummy1; /* DMA Configuration register */
+ u16 config; /* DMA Configuration register */
+ u16 dummy1; /* DMA Configuration register */
- unsigned long reserved;
+ u32 reserved;
- unsigned short x_count; /* DMA x_count register */
- unsigned short dummy2;
+ u16 x_count;/* DMA x_count register */
+ u16 dummy2;
- short x_modify; /* DMA x_modify register */
- unsigned short dummy3;
+ s16 x_modify; /* DMA x_modify register */
+ u16 dummy3;
- unsigned short y_count; /* DMA y_count register */
- unsigned short dummy4;
+ u16 y_count;/* DMA y_count register */
+ u16 dummy4;
- short y_modify; /* DMA y_modify register */
- unsigned short dummy5;
+ s16 y_modify; /* DMA y_modify register */
+ u16 dummy5;
- void *curr_desc_ptr;/* DMA Current Descriptor Pointer
- register */
- unsigned long curr_addr_ptr;/* DMA Current Address Pointer
- register */
- unsigned short irq_status; /* DMA irq status register */
- unsigned short dummy6;
+ void *curr_desc_ptr;/* DMA Current Descriptor Pointer register */
- unsigned short peripheral_map; /* DMA peripheral map register */
- unsigned short dummy7;
+ u32 curr_addr_ptr; /* DMA Current Address Pointer register */
- unsigned short curr_x_count;/* DMA Current x-count register */
- unsigned short dummy8;
+ u16 status; /* DMA irq status register */
+ u16 dummy6;
- unsigned long reserved2;
+ u16 peripheral_map; /* DMA peripheral map register */
+ u16 dummy7;
- unsigned short curr_y_count;/* DMA Current y-count register */
- unsigned short dummy9;
+ u16 curr_x_count; /* DMA Current x-count register */
+ u16 dummy8;
- unsigned long reserved3;
+ u32 reserved2;
+ u16 curr_y_count; /* DMA Current y-count register */
+ u16 dummy9;
+
+ u32 reserved3;
+#endif
};
#endif
diff --git a/arch/blackfin/include/asm/mach-common/bits/dma.h
b/arch/blackfin/include/asm/mach-common/bits/
[U-Boot] [PATCH v3 05/11] Blackfin: bf60x: support big cplb page
From: Bob Liu
Bf60x support 16K, 64K, 16M and 64M cplb pages, this patch add support for them.
So that bf609-ezkit can use it's 128M memory.
Fix review issues from Wolfgang:
1) Fix all checkpatch issues.
2) Replace run-time variable with additional macros when adding 4M byte
CPLB entries.
Signed-off-by: Bob Liu
Signed-off-by: Sonic Zhang
---
arch/blackfin/include/asm/cplb.h | 31 +++
arch/blackfin/lib/board.c| 19 +--
2 files changed, 44 insertions(+), 6 deletions(-)
diff --git a/arch/blackfin/include/asm/cplb.h b/arch/blackfin/include/asm/cplb.h
index cc21e93..420380d 100644
--- a/arch/blackfin/include/asm/cplb.h
+++ b/arch/blackfin/include/asm/cplb.h
@@ -46,8 +46,13 @@
#define CPLB_IDOCACHE CPLB_INOCACHE | CPLB_L1_CHBL
/* Data Attibutes*/
-
-#define SDRAM_IGENERIC (PAGE_SIZE_4MB | CPLB_L1_CHBL | CPLB_USER_RD |
CPLB_VALID)
+#if defined(__ADSPBF60x__)
+#define SDRAM_IGENERIC (PAGE_SIZE_16MB | CPLB_L1_CHBL | \
+ CPLB_USER_RD | CPLB_VALID)
+#else
+#define SDRAM_IGENERIC (PAGE_SIZE_4MB | CPLB_L1_CHBL | \
+ CPLB_USER_RD | CPLB_VALID)
+#endif
#define SDRAM_IKERNEL (PAGE_SIZE_4MB | CPLB_L1_CHBL | CPLB_USER_RD |
CPLB_VALID | CPLB_LOCK)
#define L1_IMEMORY (PAGE_SIZE_1MB | CPLB_USER_RD | CPLB_VALID |
CPLB_LOCK)
#define SDRAM_INON_CHBL (PAGE_SIZE_4MB | CPLB_USER_RD | CPLB_VALID)
@@ -59,14 +64,32 @@
#endif
#ifdef CONFIG_DCACHE_WB/*Write Back Policy */
-#define SDRAM_DGENERIC (PAGE_SIZE_4MB | CPLB_L1_CHBL | CPLB_DIRTY |
CPLB_SUPV_WR | CPLB_USER_WR | CPLB_USER_RD | CPLB_VALID |
ANOMALY_05000158_WORKAROUND)
+#if defined(__ADSPBF60x__)
+#define SDRAM_DGENERIC (PAGE_SIZE_16MB | CPLB_L1_CHBL | CPLB_DIRTY | \
+ CPLB_SUPV_WR | CPLB_USER_WR | CPLB_USER_RD | \
+ CPLB_VALID | ANOMALY_05000158_WORKAROUND)
+#else
+#define SDRAM_DGENERIC (PAGE_SIZE_4MB | CPLB_L1_CHBL | CPLB_DIRTY | \
+ CPLB_SUPV_WR | CPLB_USER_WR | CPLB_USER_RD | \
+ CPLB_VALID | ANOMALY_05000158_WORKAROUND)
+#endif
#define SDRAM_DNON_CHBL (PAGE_SIZE_4MB | CPLB_DIRTY | CPLB_SUPV_WR |
CPLB_USER_RD | CPLB_USER_WR | CPLB_VALID | ANOMALY_05000158_WORKAROUND)
#define SDRAM_DKERNEL (PAGE_SIZE_4MB | CPLB_L1_CHBL | CPLB_USER_RD |
CPLB_USER_WR | CPLB_DIRTY | CPLB_SUPV_WR | CPLB_VALID | CPLB_LOCK |
ANOMALY_05000158_WORKAROUND)
#define L1_DMEMORY (PAGE_SIZE_4MB | CPLB_SUPV_WR | CPLB_USER_WR |
CPLB_USER_RD | CPLB_VALID | ANOMALY_05000158_WORKAROUND)
#define SDRAM_EBIU (PAGE_SIZE_4MB | CPLB_DIRTY | CPLB_USER_RD |
CPLB_USER_WR | CPLB_SUPV_WR | CPLB_VALID | ANOMALY_05000158_WORKAROUND)
#else /*Write Through */
-#define SDRAM_DGENERIC (PAGE_SIZE_4MB | CPLB_L1_CHBL | CPLB_WT |
CPLB_L1_AOW | CPLB_SUPV_WR | CPLB_USER_RD | CPLB_USER_WR | CPLB_VALID |
ANOMALY_05000158_WORKAROUND)
+#if defined(__ADSPBF60x__)
+#define SDRAM_DGENERIC (PAGE_SIZE_16MB | CPLB_L1_CHBL | CPLB_WT | \
+ CPLB_L1_AOW | CPLB_SUPV_WR | CPLB_USER_RD | \
+ CPLB_USER_WR | CPLB_VALID | \
+ ANOMALY_05000158_WORKAROUND)
+#else
+#define SDRAM_DGENERIC (PAGE_SIZE_4MB | CPLB_L1_CHBL | CPLB_WT | \
+ CPLB_L1_AOW | CPLB_SUPV_WR | CPLB_USER_RD | \
+ CPLB_USER_WR | CPLB_VALID | \
+ ANOMALY_05000158_WORKAROUND)
+#endif
#define SDRAM_DNON_CHBL (PAGE_SIZE_4MB | CPLB_WT | CPLB_L1_AOW |
CPLB_SUPV_WR | CPLB_USER_WR | CPLB_USER_RD | CPLB_VALID |
ANOMALY_05000158_WORKAROUND)
#define SDRAM_DKERNEL (PAGE_SIZE_4MB | CPLB_L1_CHBL | CPLB_WT |
CPLB_L1_AOW | CPLB_USER_RD | CPLB_SUPV_WR | CPLB_USER_WR | CPLB_VALID |
CPLB_LOCK | ANOMALY_05000158_WORKAROUND)
#define L1_DMEMORY (PAGE_SIZE_4MB | CPLB_SUPV_WR | CPLB_USER_WR |
CPLB_VALID | ANOMALY_05000158_WORKAROUND)
diff --git a/arch/blackfin/lib/board.c b/arch/blackfin/lib/board.c
index 098f685..288dc82 100644
--- a/arch/blackfin/lib/board.c
+++ b/arch/blackfin/lib/board.c
@@ -96,6 +96,13 @@ static void display_global_data(void)
#define CPLB_PAGE_SIZE (4 * 1024 * 1024)
#define CPLB_PAGE_MASK (~(CPLB_PAGE_SIZE - 1))
+#if defined(__ADSPBF60x__)
+#define CPLB_EX_PAGE_SIZE (16 * 1024 * 1024)
+#define CPLB_EX_PAGE_MASK (~(CPLB_EX_PAGE_SIZE - 1))
+#else
+#define CPLB_EX_PAGE_SIZE CPLB_PAGE_SIZE
+#define CPLB_EX_PAGE_MASK CPLB_PAGE_MASK
+#endif
void init_cplbtables(void)
{
volatile uint32_t *ICPLB_ADDR, *ICPLB_DATA;
@@ -127,6 +134,11 @@ void init_cplbtables(void)
icplb_add(0xFFA0, L1_IMEMORY);
dcplb_add(0xFF80, L1_DMEMORY);
++i;
+#if defined(__ADSPBF60x__)
+ icplb_add
[U-Boot] [PATCH v3 08/11] Blackfin: bf60x: add rsi/sdh support
From: Sonic Zhang Add rsi/sdh support for bf60x. Fix review issues from Wolfgang: 1) Fix all checkpatch issues. 2) Does't change funtion sdh_setup_data() to return void. It returns 0 at the end of this function. But, it may return UNUSABLE_ERR(-17) at the beginning if the data flags match MMC_DATA_WRITE. Signed-off-by: Sonic Zhang Signed-off-by: Bob Liu --- arch/blackfin/include/asm/mach-common/bits/sdh.h | 38 +++- drivers/mmc/bfin_sdh.c | 68 - 2 files changed, 88 insertions(+), 18 deletions(-) diff --git a/arch/blackfin/include/asm/mach-common/bits/sdh.h b/arch/blackfin/include/asm/mach-common/bits/sdh.h index 8c5dd33..1c60d4b 100644 --- a/arch/blackfin/include/asm/mach-common/bits/sdh.h +++ b/arch/blackfin/include/asm/mach-common/bits/sdh.h @@ -12,18 +12,35 @@ #define CMD_INT_E 0x100 /* Command Interrupt */ #defineCMD_PEND_E 0x200 /* Command Pending */ #define CMD_E 0x400 /* Command Enable */ +#ifdef RSI_BLKSZ +#define CMD_CRC_CHECK_D 0x800 /* CRC Check is disabled */ +#defineCMD_DATA0_BUSY 0x1000 /* Check Busy State on DATA0 */ +#endif /* Bit masks for SDH_PWR_CTL */ +#ifndef RSI_BLKSZ #definePWR_ON 0x3/* Power On */ #define SD_CMD_OD 0x40 /* Open Drain Output */ #define ROD_CTL 0x80 /* Rod Control */ +#endif /* Bit masks for SDH_CLK_CTL */ #defineCLKDIV 0xff /* MC_CLK Divisor */ #define CLK_E 0x100 /* MC_CLK Bus Clock Enable */ #define PWR_SV_E 0x200 /* Power Save Enable */ #define CLKDIV_BYPASS 0x400 /* Bypass Divisor */ -#define WIDE_BUS 0x800 /* Wide Bus Mode Enable */ +#define BUS_MODE_MASK 0x1800 /* Bus Mode Mask */ +#define STD_BUS_1 0x000 /* Standard Bus 1 bit mode */ +#defineWIDE_BUS_4 0x800 /* Wide Bus 4 bit mode */ +#defineBYTE_BUS_8 0x1000 /* Byte Bus 8 bit mode */ +#ifdef RSI_BLKSZ +#defineCARD_TYPE_MASK 0xe000 /* Card type mask */ +#define CARD_TYPE_OFFSET 13 /* Card type offset */ +#defineCARD_TYPE_SDIO 0 +#defineCARD_TYPE_eMMC 1 +#define CARD_TYPE_SD 2 +#define CARD_TYPE_CEATA 3 +#endif /* Bit masks for SDH_RESP_CMD */ #define RESP_CMD 0x3f /* Response Command */ @@ -33,7 +50,13 @@ #define DTX_DIR 0x2/* Data Transfer Direction */ #define DTX_MODE 0x4/* Data Transfer Mode */ #define DTX_DMA_E 0x8/* Data Transfer DMA Enable */ +#ifndef RSI_BLKSZ #define DTX_BLK_LGTH 0xf0 /* Data Transfer Block Length */ +#else + +/* Bit masks for SDH_BLK_SIZE */ +#define DTX_BLK_LGTH 0x1fff /* Data Transfer Block Length */ +#endif /* Bit masks for SDH_STATUS */ #define CMD_CRC_FAIL 0x1/* CMD CRC Fail */ @@ -102,10 +125,13 @@ /* Bit masks for SDH_E_STATUS */ #define SDIO_INT_DET 0x2/* SDIO Int Detected */ #define SD_CARD_DET 0x10 /* SD Card Detect */ +#define SD_CARD_BUSYMODE 0x8000 /* Card is in Busy mode */ +#define SD_CARD_SLPMODE 0x4000 /* Card in Sleep Mode */ +#define SD_CARD_READY 0x0002 /* Card Ready */ /* Bit masks for SDH_E_MASK */ #define SDIO_MSK 0x2/* Mask SDIO Int Detected */ -#define SCD_MSK 0x40 /* Mask Card Detect */ +#define SCD_MSK 0x10 /* Mask Card Detect */ /* Bit masks for SDH_CFG */ #define CLKS_EN 0x1/* Clocks Enable */ @@ -114,7 +140,15 @@ #defineSD_RST 0x10 /* SDMMC Reset */ #define PUP_SDDAT 0x20 /* Pull-up SD_DAT */ #definePUP_SDDAT3 0x40 /* Pull-up SD_DAT3 */ +#ifndef RSI_BLKSZ #define PD_SDDAT3 0x80 /* Pull-down SD_DAT3 */ +#else +#definePWR_ON 0x600 /* Power On */ +#define SD_CMD_OD 0x800 /* Open Drain Output */ +#define BOOT_EN 0x1000 /* Boot Enable */ +#define BOOT_MODE 0x2000 /* Alternate Boot Mode */ +#define BOOT_ACK_EN 0x4000 /* Boot ACK is expected */ +#endif /* Bit masks for SDH_RD_WAIT_EN */ #define RWR 0x1/* Read Wait Request */ diff --git a/drivers/mmc/bfin_sdh.c b/drivers/mmc/bfin_sdh.c index 8d59d46..f22429a 100644 --- a/drivers/mmc/bfin_sdh.c +++ b/drivers/mmc/bfin_sdh.c @@ -19,9 +19,7 @@ #include #include -#if defined(__ADSPBF50x__) || defined(__ADSPBF51x__) -# define bfin_read_SDH_PWR_CTL bfin_rea
[U-Boot] [PATCH 0/3] add libfdt bootz support and change nand partition table
This patch series implement following feature: - Add libfdt support - Add bootz support - Change nand partition table Bo Shen (1): ARM: at91: change nand flash table Nicolas Ferre (2): arm: at91/configs: add libfdt to configuration arm: at91/configs: add bootz to configuration include/configs/at91rm9200ek.h |3 +++ include/configs/at91sam9260ek.h| 21 - include/configs/at91sam9261ek.h| 19 +-- include/configs/at91sam9263ek.h| 20 include/configs/at91sam9m10g45ek.h | 17 + include/configs/at91sam9rlek.h |3 +++ include/configs/at91sam9x5ek.h | 12 +++- 7 files changed, 55 insertions(+), 40 deletions(-) -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/3] arm: at91/configs: add libfdt to configuration
From: Nicolas Ferre support to boot device tree Linux kernel Signed-off-by: Nicolas Ferre [Add libftd for at91rm9200, at91sam9263, at91sam9rl] Signed-off-by: Bo Shen --- include/configs/at91rm9200ek.h |2 ++ include/configs/at91sam9260ek.h |2 ++ include/configs/at91sam9263ek.h |2 ++ include/configs/at91sam9rlek.h |2 ++ 4 files changed, 8 insertions(+) diff --git a/include/configs/at91rm9200ek.h b/include/configs/at91rm9200ek.h index bf20065..4b526c2 100644 --- a/include/configs/at91rm9200ek.h +++ b/include/configs/at91rm9200ek.h @@ -75,6 +75,8 @@ #define CONFIG_BOARD_EARLY_INIT_F +#define CONFIG_OF_LIBFDT + /* * Memory Configuration */ diff --git a/include/configs/at91sam9260ek.h b/include/configs/at91sam9260ek.h index 02696b3..3db6cc8 100644 --- a/include/configs/at91sam9260ek.h +++ b/include/configs/at91sam9260ek.h @@ -62,6 +62,8 @@ #define CONFIG_BOARD_EARLY_INIT_F #define CONFIG_DISPLAY_CPUINFO +#define CONFIG_OF_LIBFDT + /* general purpose I/O */ #define CONFIG_ATMEL_LEGACY/* required until (g)pio is fixed */ #define CONFIG_AT91_GPIO diff --git a/include/configs/at91sam9263ek.h b/include/configs/at91sam9263ek.h index 3503822..005d1af 100644 --- a/include/configs/at91sam9263ek.h +++ b/include/configs/at91sam9263ek.h @@ -62,6 +62,8 @@ #define CONFIG_DISPLAY_CPUINFO +#define CONFIG_OF_LIBFDT + /* * Hardware drivers */ diff --git a/include/configs/at91sam9rlek.h b/include/configs/at91sam9rlek.h index 8178b32..be084b2 100644 --- a/include/configs/at91sam9rlek.h +++ b/include/configs/at91sam9rlek.h @@ -48,6 +48,8 @@ #define CONFIG_DISPLAY_CPUINFO +#define CONFIG_OF_LIBFDT + #define CONFIG_ATMEL_LEGACY #define CONFIG_AT91_GPIO 1 #define CONFIG_AT91_GPIO_PULLUP1 -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/3] ARM: at91: change nand flash table
Change nand flash partition tablke according to www.at91.com/linux4sam more information: http://www.at91.com/linux4sam/bin/view/Linux4SAM/GettingStarted#Linux4SAM_NandFlash_demo_Memory Signed-off-by: Bo Shen --- include/configs/at91sam9260ek.h| 18 +- include/configs/at91sam9261ek.h| 19 +-- include/configs/at91sam9263ek.h| 17 + include/configs/at91sam9m10g45ek.h | 16 include/configs/at91sam9x5ek.h | 11 ++- 5 files changed, 41 insertions(+), 40 deletions(-) diff --git a/include/configs/at91sam9260ek.h b/include/configs/at91sam9260ek.h index 392a818..ebcc69a 100644 --- a/include/configs/at91sam9260ek.h +++ b/include/configs/at91sam9260ek.h @@ -215,16 +215,16 @@ /* bootstrap + u-boot + env + linux in nandflash */ #define CONFIG_ENV_IS_IN_NAND 1 -#define CONFIG_ENV_OFFSET 0x6 -#define CONFIG_ENV_OFFSET_REDUND 0x8 +#define CONFIG_ENV_OFFSET 0xc +#define CONFIG_ENV_OFFSET_REDUND 0x10 #define CONFIG_ENV_SIZE0x2 /* 1 sector = 128 kB */ -#define CONFIG_BOOTCOMMAND "nand read 0x2200 0xA 0x20; bootm" -#define CONFIG_BOOTARGS"console=ttyS0,115200 " \ - "root=/dev/mtdblock5 " \ - "mtdparts=atmel_nand:128k(bootstrap)ro," \ - "256k(uboot)ro,128k(env1)ro," \ - "128k(env2)ro,2M(linux),-(root) " \ - "rw rootfstype=jffs2" +#define CONFIG_BOOTCOMMAND "nand read 0x2200 0x20 0x30; bootm" +#define CONFIG_BOOTARGS \ + "console=ttyS0,115200 earlyprintk " \ + "mtdparts=atmel_nand:256k(bootstrap)ro,512k(uboot)ro," \ + "256k(env),256k(env_redundant),256k(spare),"\ + "512k(dtb),6M(kernel)ro,-(rootfs) " \ + "root=/dev/mtdblock7 rw rootfstype=jffs2" #endif diff --git a/include/configs/at91sam9261ek.h b/include/configs/at91sam9261ek.h index 611e3e2..cabff9a 100644 --- a/include/configs/at91sam9261ek.h +++ b/include/configs/at91sam9261ek.h @@ -212,17 +212,16 @@ /* bootstrap + u-boot + env + linux in nandflash */ #define CONFIG_ENV_IS_IN_NAND -#define CONFIG_ENV_OFFSET 0x6 -#define CONFIG_ENV_OFFSET_REDUND 0x8 +#define CONFIG_ENV_OFFSET 0xc +#define CONFIG_ENV_OFFSET_REDUND 0x10 #define CONFIG_ENV_SIZE0x2 /* 1 sector = 128 kB */ -#define CONFIG_BOOTCOMMAND "nand read 0x2200 0xA 0x20; bootm" -#define CONFIG_BOOTARGS"console=ttyS0,115200 " \ - "root=/dev/mtdblock5 " \ - "mtdparts=atmel_nand:128k(bootstrap)ro," \ - "256k(uboot)ro,128k(env1)ro," \ - "128k(env2)ro,2M(linux),-(root) " \ - "rw rootfstype=jffs2" - +#define CONFIG_BOOTCOMMAND "nand read 0x2200 0x20 0x30; bootm" +#define CONFIG_BOOTARGS \ + "console=ttyS0,115200 earlyprintk " \ + "mtdparts=atmel_nand:256k(bootstrap)ro,512k(uboot)ro," \ + "256k(env),256k(env_redundant),256k(spare),"\ + "512k(dtb),6M(kernel)ro,-(rootfs) " \ + "root=/dev/mtdblock7 rw rootfstype=jffs2" #endif #define CONFIG_SYS_PROMPT "U-Boot> " diff --git a/include/configs/at91sam9263ek.h b/include/configs/at91sam9263ek.h index da2a931..1ab9c30 100644 --- a/include/configs/at91sam9263ek.h +++ b/include/configs/at91sam9263ek.h @@ -327,15 +327,16 @@ /* bootstrap + u-boot + env + linux in nandflash */ #define CONFIG_ENV_IS_IN_NAND 1 -#define CONFIG_ENV_OFFSET 0x6 -#define CONFIG_ENV_OFFSET_REDUND 0x8 +#define CONFIG_ENV_OFFSET 0xc +#define CONFIG_ENV_OFFSET_REDUND 0x10 #define CONFIG_ENV_SIZE0x2 /* 1 sector = 128 kB */ -#define CONFIG_BOOTCOMMAND "nand read 0x2200 0xA 0x20; bootm" -#define CONFIG_BOOTARGS"console=ttyS0,115200 " \ - "root=/dev/mtdblock5 " \ - "mtdparts=atmel_nand:128k(bootstrap)ro,256k(uboot)ro,128k(env1)ro,128k(env2)ro,2M(linux),-(root) " \ - "rw rootfstype=jffs2" - +#define CONFIG_BOOTCOMMAND "nand read 0x2200 0x20 0x30; bootm" +#define CONFIG_BOOTARGS \ + "console=ttyS0,115
[U-Boot] [PATCH 2/3] arm: at91/configs: add bootz to configuration
From: Nicolas Ferre Support to boot zImage Signed-off-by: Nicolas Ferre [Add bootz for at91rm9200, at91sam9263, at91sam9rl] Signed-off-by: Bo Shen --- include/configs/at91rm9200ek.h |1 + include/configs/at91sam9260ek.h|1 + include/configs/at91sam9263ek.h|1 + include/configs/at91sam9m10g45ek.h |1 + include/configs/at91sam9rlek.h |1 + include/configs/at91sam9x5ek.h |1 + 6 files changed, 6 insertions(+) diff --git a/include/configs/at91rm9200ek.h b/include/configs/at91rm9200ek.h index 4b526c2..7352113 100644 --- a/include/configs/at91rm9200ek.h +++ b/include/configs/at91rm9200ek.h @@ -75,6 +75,7 @@ #define CONFIG_BOARD_EARLY_INIT_F +#define CONFIG_CMD_BOOTZ #define CONFIG_OF_LIBFDT /* diff --git a/include/configs/at91sam9260ek.h b/include/configs/at91sam9260ek.h index 3db6cc8..392a818 100644 --- a/include/configs/at91sam9260ek.h +++ b/include/configs/at91sam9260ek.h @@ -62,6 +62,7 @@ #define CONFIG_BOARD_EARLY_INIT_F #define CONFIG_DISPLAY_CPUINFO +#define CONFIG_CMD_BOOTZ #define CONFIG_OF_LIBFDT /* general purpose I/O */ diff --git a/include/configs/at91sam9263ek.h b/include/configs/at91sam9263ek.h index 005d1af..da2a931 100644 --- a/include/configs/at91sam9263ek.h +++ b/include/configs/at91sam9263ek.h @@ -62,6 +62,7 @@ #define CONFIG_DISPLAY_CPUINFO +#define CONFIG_CMD_BOOTZ #define CONFIG_OF_LIBFDT /* diff --git a/include/configs/at91sam9m10g45ek.h b/include/configs/at91sam9m10g45ek.h index e988d81..f1a4db3 100644 --- a/include/configs/at91sam9m10g45ek.h +++ b/include/configs/at91sam9m10g45ek.h @@ -47,6 +47,7 @@ #define CONFIG_BOARD_EARLY_INIT_F #define CONFIG_DISPLAY_CPUINFO +#define CONFIG_CMD_BOOTZ #define CONFIG_OF_LIBFDT /* general purpose I/O */ diff --git a/include/configs/at91sam9rlek.h b/include/configs/at91sam9rlek.h index be084b2..aa359b1 100644 --- a/include/configs/at91sam9rlek.h +++ b/include/configs/at91sam9rlek.h @@ -48,6 +48,7 @@ #define CONFIG_DISPLAY_CPUINFO +#define CONFIG_CMD_BOOTZ #define CONFIG_OF_LIBFDT #define CONFIG_ATMEL_LEGACY diff --git a/include/configs/at91sam9x5ek.h b/include/configs/at91sam9x5ek.h index 6fac5ac..1bc56a5 100644 --- a/include/configs/at91sam9x5ek.h +++ b/include/configs/at91sam9x5ek.h @@ -42,6 +42,7 @@ #define CONFIG_BOARD_EARLY_INIT_F #define CONFIG_DISPLAY_CPUINFO +#define CONFIG_CMD_BOOTZ #define CONFIG_OF_LIBFDT /* general purpose I/O */ -- 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] usb: Add new command to set USB 2.0 port test modes
Hi Tom, This patch is not really target specific, it works on all platforms that support USB 2.0. I just wrapped it in a new config option because most people probably won't need it… it is only really useful for hardware verification, so I figured whoever needs it can hack in the config option himself. However, I could also just remove the #ifdef and activate it by default if you prefer that. No new code will get executed unless you type the new command, so it should not have any negative effect besides a negligible code size increase. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] SPI question
Hello, Veteran developer, new to Linux internals. I'm working with the BeagleBone and need three SPI ports. I'm now working to enable the second chip select on the second port. I need some basic information to get started. Is the port initialization done in u-boot or in the kernel? In beagle/beagle.h I found the pins nicely enumerated but that file is apparently for the BeagleBoard, as it doesn't get built during a bone build. If the initialization is done in u-boot, could someone suggest the file to look at? Thanks, John -- John DeArmond Tellico Plains, Occupied TN http://www.fluxeon.com <-- THE source for induction heaters http://www.neon-john.com<-- email from here http://www.johndearmond.com <-- Best damned Blog on the net PGP key: wwwkeys.pgp.net: BCB68D77 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] usb: Add new command to set USB 2.0 port test modes
I guess you are right about the bit rot, it makes more sense to keep this on so people notice when things break. I have compiled it for smdk5250 (though it's all common and EHCI code, so that should make no difference) and only measured a 1.1k increase in uncompressed code size (less than 0.3%). I will just resubmit this without the ifdefs. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] usb: Add new command to set USB 2.0 port test modes
This patch adds a new 'usb test' command, that will set a port to a USB
2.0 test mode (see USB 2.0 spec 7.1.20). It supports all five test modes
on both downstream hub ports and ordinary device's upstream ports. In
addition, it supports EHCI root hub ports.
Signed-off-by: Julius Werner
---
common/cmd_usb.c| 121 +++-
drivers/usb/host/ehci-hcd.c | 30 +++
include/usb_defs.h | 13 +
3 files changed, 130 insertions(+), 34 deletions(-)
diff --git a/common/cmd_usb.c b/common/cmd_usb.c
index dacdc2d..adc5f02 100644
--- a/common/cmd_usb.c
+++ b/common/cmd_usb.c
@@ -269,6 +269,22 @@ static void usb_display_config(struct usb_device *dev)
printf("\n");
}
+static struct usb_device *usb_find_device(int devnum)
+{
+ struct usb_device *dev;
+ int d;
+
+ for (d = 0; d < USB_MAX_DEVICE; d++) {
+ dev = usb_get_dev_index(d);
+ if (dev == NULL)
+ return NULL;
+ if (dev->devnum == devnum)
+ return dev;
+ }
+
+ return NULL;
+}
+
static inline char *portspeed(int speed)
{
if (speed == USB_SPEED_HIGH)
@@ -348,6 +364,66 @@ static void usb_show_tree(struct usb_device *dev)
usb_show_tree_graph(dev, &preamble[0]);
}
+static int usb_test(struct usb_device *dev, int port, char* arg)
+{
+ int mode;
+
+ if (port > dev->maxchild) {
+ printf("Device is no hub or does not have %d ports.\n", port);
+ return 1;
+ }
+
+ switch (arg[0]) {
+ case 'J':
+ case 'j':
+ printf("Setting Test_J mode");
+ mode = USB_TEST_MODE_J;
+ break;
+ case 'K':
+ case 'k':
+ printf("Setting Test_K mode");
+ mode = USB_TEST_MODE_K;
+ break;
+ case 'S':
+ case 's':
+ printf("Setting Test_SE0_NAK mode");
+ mode = USB_TEST_MODE_SE0_NAK;
+ break;
+ case 'P':
+ case 'p':
+ printf("Setting Test_Packet mode");
+ mode = USB_TEST_MODE_PACKET;
+ break;
+ case 'F':
+ case 'f':
+ printf("Setting Test_Force_Enable mode");
+ mode = USB_TEST_MODE_FORCE_ENABLE;
+ break;
+ default:
+ printf("Unrecognized test mode: %s\nAvailable modes: "
+ "J, K, S[E0_NAK], P[acket], F[orce_Enable]\n", arg);
+ return 1;
+ }
+
+ if (port)
+ printf(" on downstream facing port %d...\n", port);
+ else
+ printf(" on upstream facing port...\n");
+
+ if (usb_control_msg(dev, usb_sndctrlpipe(dev, 0), USB_REQ_SET_FEATURE,
+ port ? USB_RT_PORT : USB_RECIP_DEVICE,
+ port ? USB_PORT_FEAT_TEST : USB_FEAT_TEST,
+ (mode << 8) | port,
+ NULL, 0, USB_CNTL_TIMEOUT) == -1) {
+ printf("Error during SET_FEATURE.\n");
+ return 1;
+ } else {
+ printf("Test mode successfully set. Use 'usb start' "
+ "to return to normal operation.\n");
+ return 0;
+ }
+}
+
/**
* usb boot command intepreter. Derived from diskboot
@@ -441,17 +517,9 @@ static int do_usb(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
}
return 0;
} else {
- int d;
-
- i = simple_strtoul(argv[2], NULL, 16);
+ i = simple_strtoul(argv[2], NULL, 10);
printf("config for device %d\n", i);
- for (d = 0; d < USB_MAX_DEVICE; d++) {
- dev = usb_get_dev_index(d);
- if (dev == NULL)
- break;
- if (dev->devnum == i)
- break;
- }
+ dev = usb_find_device(i);
if (dev == NULL) {
printf("*** No device available ***\n");
return 0;
@@ -462,6 +530,18 @@ static int do_usb(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
}
return 0;
}
+ if (strncmp(argv[1], "test", 4) == 0) {
+ if (argc < 5)
+ return CMD_RET_USAGE;
+ i = simple_strtoul(argv[2], NULL, 10);
+ dev = usb_find_device(i);
+ if (dev == NULL) {
+ printf("Device %d does not exist.\n", i);
+ return 1;
+ }
+ i = simple_strtoul(argv[3]
[U-Boot] [U-Boot PATCH 1/1] am335x: cpsw: optimize cpsw_send to increase network performance
Before submitting packets to cpdma, phy status is updated on every packet
which leads to delay in packet send intern reduces the Ethernet performance.
Checking mdio status for each packet will reduce timetaken to send a packet
and there by increasing the Ethernet performance. With this the performance
is increased from 208KiB/s to 375KiB/s on EVMsk
Signed-off-by: Mugunthan V N
---
This patch is applicable for u-boot-ti git repo
drivers/net/cpsw.c | 20 ++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/drivers/net/cpsw.c b/drivers/net/cpsw.c
index db04795..93f8417 100644
--- a/drivers/net/cpsw.c
+++ b/drivers/net/cpsw.c
@@ -227,6 +227,9 @@ struct cpsw_priv {
struct cpsw_slave *slaves;
struct phy_device *phydev;
struct mii_dev *bus;
+
+ u32 mdio_link;
+ u32 phy_mask;
};
static inline int cpsw_ale_get_field(u32 *ale_entry, u32 start, u32 bits)
@@ -598,10 +601,21 @@ static int cpsw_update_link(struct cpsw_priv *priv)
for_each_slave(slave, priv)
cpsw_slave_update_link(slave, priv, &link);
-
+ priv->mdio_link = readl(&mdio_regs->link);
return link;
}
+static int cpsw_check_link(struct cpsw_priv *priv)
+{
+ u32 link = 0;
+
+ link = __raw_readl(&mdio_regs->link) & priv->phy_mask;
+ if ((link) && (link == priv->mdio_link))
+ return 1;
+
+ return cpsw_update_link(priv);
+}
+
static inline u32 cpsw_get_slave_port(struct cpsw_priv *priv, u32 slave_num)
{
if (priv->host_port == 0)
@@ -631,6 +645,8 @@ static void cpsw_slave_init(struct cpsw_slave *slave,
struct cpsw_priv *priv)
cpsw_ale_port_state(priv, slave_port, ALE_PORT_STATE_FORWARD);
cpsw_ale_add_mcast(priv, NetBcastAddr, 1 << slave_port);
+
+ priv->phy_mask |= 1 << slave->data->phy_id;
}
static struct cpdma_desc *cpdma_desc_alloc(struct cpsw_priv *priv)
@@ -862,7 +878,7 @@ static int cpsw_send(struct eth_device *dev, void *packet,
int length)
int len;
int timeout = CPDMA_TIMEOUT;
- if (!cpsw_update_link(priv))
+ if (!cpsw_check_link(priv))
return -EIO;
flush_dcache_range((unsigned long)packet,
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] imx6, spl and falcon boot
On Wed, Feb 20, 2013 at 12:19:12AM +0100, Jeroen Hofstee wrote : > > Do you have a link for the sources of opengl application? > Part of the challenge was that we didn't have access to the sources. It is a sample from vivante that is provided by freescale along with the proprietary driver. > So I can make some comparison (I might have some time this > weekend, just for the fun of it...) Or even later if opengl support > bites me... I have a ti / spl boot so might be interesting to compare. > Yeah, I wanted to test that on a pandaboard but I didn't have the time to finish. > Out of curiosity, do you have any numbers for QNX? > I didn't try that either. Regards, -- Alexandre Belloni ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] imx help
Dear wanxs, Please always Cc the mailing list and format your e-mails using plain text (no HTML). On Wednesday, February 20, 2013 5:41:40 AM, wanxuesong wrote: > Dear, > I use a board for i.mx53 core. > I build the u-boot download for denx,patch your patches,but have 2 > error(v7-13-19 and v7-14-19 patches). > What version do i checkout from mainline? Please use: git clone git://git.denx.de/u-boot-imx.git And apply on the master branch. > And I want boot my board from nandflash,how can i do? Use the u-boot-with-nand-spl.imx target. But this won't work for i.MX53 because an FCB header is required instead of the dummy 1024-byte header, but that's easy to change for some hacking. Marek Vasut is working on the i.MX53 NAND boot. He will soon provide an example board and something to generate the image with the FCB. Best regards, Benoît ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] another question!
Dear wanxs, On Wednesday, February 20, 2013 5:47:44 AM, wanxuesong wrote: > hi, > I have another question. > when i build a spl_nand u-boot, the program use the > drivers/mtd/nand/mxc_nand.h,but your patch file didn't create the file.How > can i get it?!!! It's in the patch set. Use "git apply". Best regards, Benoît ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] imx help
Dear Benoît Thébaudeau, > Dear wanxs, > > Please always Cc the mailing list and format your e-mails using plain text > (no HTML). > > On Wednesday, February 20, 2013 5:41:40 AM, wanxuesong wrote: > > Dear, > > I use a board for i.mx53 core. > > I build the u-boot download for denx,patch your patches,but have 2 > > error(v7-13-19 and v7-14-19 patches). > > What version do i checkout from mainline? > > Please use: > git clone git://git.denx.de/u-boot-imx.git > > And apply on the master branch. > > > And I want boot my board from nandflash,how can i do? > > Use the u-boot-with-nand-spl.imx target. But this won't work for i.MX53 > because an FCB header is required instead of the dummy 1024-byte header, > but that's easy to change for some hacking. > > Marek Vasut is working on the i.MX53 NAND boot. He will soon provide an > example board and something to generate the image with the FCB. I still haven't sorted my patches, it might take a bit more time. Till the end of the week or so I suspect. > Best regards, > Benoît Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] imx help
Dear Marek Vasut, On Wednesday, February 20, 2013 12:37:54 PM, Marek Vasut wrote: > Dear Benoît Thébaudeau, > > > Dear wanxs, > > > > Please always Cc the mailing list and format your e-mails using plain text > > (no HTML). > > > > On Wednesday, February 20, 2013 5:41:40 AM, wanxuesong wrote: > > > Dear, > > > I use a board for i.mx53 core. > > > I build the u-boot download for denx,patch your patches,but have 2 > > > error(v7-13-19 and v7-14-19 patches). > > > What version do i checkout from mainline? > > > > Please use: > > git clone git://git.denx.de/u-boot-imx.git > > > > And apply on the master branch. > > > > > And I want boot my board from nandflash,how can i do? > > > > Use the u-boot-with-nand-spl.imx target. But this won't work for i.MX53 > > because an FCB header is required instead of the dummy 1024-byte header, > > but that's easy to change for some hacking. > > > > Marek Vasut is working on the i.MX53 NAND boot. He will soon provide an > > example board and something to generate the image with the FCB. > > I still haven't sorted my patches, it might take a bit more time. Till the > end > of the week or so I suspect. That's fine for me. I will also post a v8 rebased on the latest u-boot-imx/master once Stefano has re-sync'ed it with u-boot/master. This v8 also adds a few patches to factorize the ARM relocate_code() from all start.S. Best regards, Benoît ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add Boundary Devices Nitrogen6X boards
Hi Eric, On Wednesday, February 20, 2013 12:01:15 AM, Eric Nelson wrote: > Hi Benoît, > > On 02/19/2013 03:31 PM, Benoît Thébaudeau wrote: > > On Tuesday, February 19, 2013 10:53:48 PM, Eric Nelson wrote: > >> On 02/19/2013 01:52 PM, Benoît Thébaudeau wrote: > >>> Hi Eric, > >>> > >>> On Tuesday, February 19, 2013 9:20:48 PM, Eric Nelson wrote: > >>> [--snip--] > diff --git a/board/boundary/nitrogen6x/1066mhz_4x128mx16.cfg > b/board/boundary/nitrogen6x/1066mhz_4x128mx16.cfg > new file mode 100644 > index 000..45b8879 > --- /dev/null > +++ b/board/boundary/nitrogen6x/1066mhz_4x128mx16.cfg > >>> [--snip--] > +DATA 4, MX6_MMDC_P0_MDPDC, 0x00020036 > +DATA 4, MX6_MMDC_P0_MDCFG0, 0x555B7974 > >>> ^A? > +DATA 4, MX6_MMDC_P0_MDCFG1, 0xDB538F64 > +DATA 4, MX6_MMDC_P0_MDCFG2, 0x01FF00DB > +DATA 4, MX6_MMDC_P0_MDRWD, 0x26D2 > +DATA 4, MX6_MMDC_P0_MDOR, 0x005B1023 > >>> ^A? > +DATA 4, MX6_MMDC_P0_MDOTC, 0x09444040 > +DATA 4, MX6_MMDC_P0_MDPDC, 0x00025576 > +DATA 4, MX6_MMDC_P0_MDASP, 0x0027 > +DATA 4, MX6_MMDC_P0_MDCTL, 0x831A > +DATA 4, MX6_MMDC_P0_MDSCR, 0x04088032 > +DATA 4, MX6_MMDC_P0_MDSCR, 0x8033 > +DATA 4, MX6_MMDC_P0_MDSCR, 0x00428031 > +DATA 4, MX6_MMDC_P0_MDSCR, 0x19308030 > +DATA 4, MX6_MMDC_P0_MDSCR, 0x04008040 > +DATA 4, MX6_MMDC_P0_MPZQHWCTRL, 0xA1390003 > +DATA 4, MX6_MMDC_P1_MPZQHWCTRL, 0xA1390003 > +DATA 4, MX6_MMDC_P0_MDREF, 0x5800 > +DATA 4, MX6_MMDC_P0_MPODTCTRL, 0x0007 > +DATA 4, MX6_MMDC_P1_MPODTCTRL, 0x0007 > +DATA 4, MX6_MMDC_P0_MPDGCTRL0, 0x42720306 > +DATA 4, MX6_MMDC_P0_MPDGCTRL1, 0x026F0266 > +DATA 4, MX6_MMDC_P1_MPDGCTRL0, 0x4273030A > +DATA 4, MX6_MMDC_P1_MPDGCTRL1, 0x02740240 > +DATA 4, MX6_MMDC_P0_MPRDDLCTL, 0x45393B3E > +DATA 4, MX6_MMDC_P1_MPRDDLCTL, 0x403A3747 > +DATA 4, MX6_MMDC_P0_MPWRDLCTL, 0x40434541 > +DATA 4, MX6_MMDC_P1_MPWRDLCTL, 0x473E4A3B > +DATA 4, MX6_MMDC_P0_MPWLDECTRL0, 0x0011000E > +DATA 4, MX6_MMDC_P0_MPWLDECTRL1, 0x000E001B > +DATA 4, MX6_MMDC_P1_MPWLDECTRL0, 0x00190015 > +DATA 4, MX6_MMDC_P1_MPWLDECTRL1, 0x00070018 > +DATA 4, MX6_MMDC_P0_MPMUR0, 0x0800 > +DATA 4, MX6_MMDC_P1_MPMUR0, 0x0800 > +DATA 4, MX6_MMDC_P0_MDSCR, 0x > +DATA 4, MX6_MMDC_P0_MAPSR, 0x00011006 > >>> [--snip--] > >>> > >>> tXS = tXPR = 170 ns -> 91 nCK -> 91 - 1 -> 0x5A. > >>> > >> > >> Thanks Benoît, > >> > >> I was going to bring this up in a separate thread. > >> > >> While working through the details of our 800MHz > >> variants (Solo, Dual-Lite), and x256mx16 variants, > >> I re-worked these numbers and it seems that we > >> have an off-by-one issue with those fields. > > > > Probably because it has been missed that the bit-field > > value is the number of clock cycles minus 1. > > > Right. All of these fields are plus 1. > > MDCFG0.tRFC > MDCFG0.tXS > MDOR.tXPR > > Since they're all in the same units, the requirements > are: > MDCFG0.tXS >= MDCFG0.tRFC + 10nS > and > MDOR.tXPR >= MDCFG0.tRFC + 10nS > > Since we operate at ~528MHz, each clock is less than > 2 nS, and we need 6 more clocks for each. > > >> According to the JEDEC spec and data sheets, > >> both tXS and tXPR should be 10nS greater than tRFC. > > > > Indeed, or more precisely, max(5 nCK, tRFC + 10 ns). > > > > Yep. I shortened because nothing approaches 5nCK. > > And note that this is the minimum spec, not the > target. > > >> Since the nominal clock for i.MX6 is 528MHz (1.89nS), > > > > I used 532 MHz because this is a more standard value, and I found several > > close > > different values in the documentation, so in the doubt, I chose the worst > > case. > > With 528 MHz, the bit-field value would be 0x59. > > > > Either way, we need 6 clocks to get > 10nS. > > >> this should be a delta of 6 clocks, not 5. > > > > Delta with what? > > > > Sorry. I meant the Delta between MDCFG0.tRFC and the > other two fields. OK, now I see what you mean and how you got these values. But I disagree. tXS(min) and tXPR(min) are defined by the JEDEC DDR3 specification as max(5 nCK, tRFC(min) + 10 ns). tRFC(min) is used here, not tRFC. Moreover, tXS and tXPR are timings depending on internal features of the RAM, not on external operations from the host processor. It's not as if they were the result of the combination of two external operations. E.g., see tXS on figures 14, 15 and 62 in JESD79-3F. Hence, tXS and tXPR should not be considered as tRFC(MMDC) + 10 ns, but really as tRFC(min) + 10 ns, i.e. a single 170 ns timing (for 2-Gib density) to be converted into a number of clock cycles. I don't feel like it's possible to interpret the specification in a different way. But perhaps I'm wrong. > >> This change should apply to mx6q_4x_mt41j128.cfg as well. > > > > Sure. > > >
Re: [U-Boot] [PATCH] Add Boundary Devices Nitrogen6X boards
Hi Eric, On Wednesday, February 20, 2013 1:05:04 PM, Benoît Thébaudeau wrote: > Hi Eric, > > On Wednesday, February 20, 2013 12:01:15 AM, Eric Nelson wrote: > > Hi Benoît, > > > > On 02/19/2013 03:31 PM, Benoît Thébaudeau wrote: > > > On Tuesday, February 19, 2013 10:53:48 PM, Eric Nelson wrote: > > >> On 02/19/2013 01:52 PM, Benoît Thébaudeau wrote: > > >>> Hi Eric, > > >>> > > >>> On Tuesday, February 19, 2013 9:20:48 PM, Eric Nelson wrote: > > >>> [--snip--] > > diff --git a/board/boundary/nitrogen6x/1066mhz_4x128mx16.cfg > > b/board/boundary/nitrogen6x/1066mhz_4x128mx16.cfg > > new file mode 100644 > > index 000..45b8879 > > --- /dev/null > > +++ b/board/boundary/nitrogen6x/1066mhz_4x128mx16.cfg > > >>> [--snip--] > > +DATA 4, MX6_MMDC_P0_MDPDC, 0x00020036 > > +DATA 4, MX6_MMDC_P0_MDCFG0, 0x555B7974 > > >>> ^A? > > +DATA 4, MX6_MMDC_P0_MDCFG1, 0xDB538F64 > > +DATA 4, MX6_MMDC_P0_MDCFG2, 0x01FF00DB > > +DATA 4, MX6_MMDC_P0_MDRWD, 0x26D2 > > +DATA 4, MX6_MMDC_P0_MDOR, 0x005B1023 > > >>> ^A? > > +DATA 4, MX6_MMDC_P0_MDOTC, 0x09444040 > > +DATA 4, MX6_MMDC_P0_MDPDC, 0x00025576 > > +DATA 4, MX6_MMDC_P0_MDASP, 0x0027 > > +DATA 4, MX6_MMDC_P0_MDCTL, 0x831A > > +DATA 4, MX6_MMDC_P0_MDSCR, 0x04088032 > > +DATA 4, MX6_MMDC_P0_MDSCR, 0x8033 > > +DATA 4, MX6_MMDC_P0_MDSCR, 0x00428031 > > +DATA 4, MX6_MMDC_P0_MDSCR, 0x19308030 > > +DATA 4, MX6_MMDC_P0_MDSCR, 0x04008040 > > +DATA 4, MX6_MMDC_P0_MPZQHWCTRL, 0xA1390003 > > +DATA 4, MX6_MMDC_P1_MPZQHWCTRL, 0xA1390003 > > +DATA 4, MX6_MMDC_P0_MDREF, 0x5800 > > +DATA 4, MX6_MMDC_P0_MPODTCTRL, 0x0007 > > +DATA 4, MX6_MMDC_P1_MPODTCTRL, 0x0007 > > +DATA 4, MX6_MMDC_P0_MPDGCTRL0, 0x42720306 > > +DATA 4, MX6_MMDC_P0_MPDGCTRL1, 0x026F0266 > > +DATA 4, MX6_MMDC_P1_MPDGCTRL0, 0x4273030A > > +DATA 4, MX6_MMDC_P1_MPDGCTRL1, 0x02740240 > > +DATA 4, MX6_MMDC_P0_MPRDDLCTL, 0x45393B3E > > +DATA 4, MX6_MMDC_P1_MPRDDLCTL, 0x403A3747 > > +DATA 4, MX6_MMDC_P0_MPWRDLCTL, 0x40434541 > > +DATA 4, MX6_MMDC_P1_MPWRDLCTL, 0x473E4A3B > > +DATA 4, MX6_MMDC_P0_MPWLDECTRL0, 0x0011000E > > +DATA 4, MX6_MMDC_P0_MPWLDECTRL1, 0x000E001B > > +DATA 4, MX6_MMDC_P1_MPWLDECTRL0, 0x00190015 > > +DATA 4, MX6_MMDC_P1_MPWLDECTRL1, 0x00070018 > > +DATA 4, MX6_MMDC_P0_MPMUR0, 0x0800 > > +DATA 4, MX6_MMDC_P1_MPMUR0, 0x0800 > > +DATA 4, MX6_MMDC_P0_MDSCR, 0x > > +DATA 4, MX6_MMDC_P0_MAPSR, 0x00011006 > > >>> [--snip--] > > >>> > > >>> tXS = tXPR = 170 ns -> 91 nCK -> 91 - 1 -> 0x5A. > > >>> > > >> > > >> Thanks Benoît, > > >> > > >> I was going to bring this up in a separate thread. > > >> > > >> While working through the details of our 800MHz > > >> variants (Solo, Dual-Lite), and x256mx16 variants, > > >> I re-worked these numbers and it seems that we > > >> have an off-by-one issue with those fields. > > > > > > Probably because it has been missed that the bit-field > > > value is the number of clock cycles minus 1. > > > > > Right. All of these fields are plus 1. > > > > MDCFG0.tRFC > > MDCFG0.tXS > > MDOR.tXPR > > > > Since they're all in the same units, the requirements > > are: > > MDCFG0.tXS >= MDCFG0.tRFC + 10nS > > and > > MDOR.tXPR >= MDCFG0.tRFC + 10nS > > > > Since we operate at ~528MHz, each clock is less than > > 2 nS, and we need 6 more clocks for each. > > > > >> According to the JEDEC spec and data sheets, > > >> both tXS and tXPR should be 10nS greater than tRFC. > > > > > > Indeed, or more precisely, max(5 nCK, tRFC + 10 ns). > > > > > > > Yep. I shortened because nothing approaches 5nCK. > > > > And note that this is the minimum spec, not the > > target. > > > > >> Since the nominal clock for i.MX6 is 528MHz (1.89nS), > > > > > > I used 532 MHz because this is a more standard value, and I found several > > > close > > > different values in the documentation, so in the doubt, I chose the worst > > > case. > > > With 528 MHz, the bit-field value would be 0x59. > > > > > > > Either way, we need 6 clocks to get > 10nS. > > > > >> this should be a delta of 6 clocks, not 5. > > > > > > Delta with what? > > > > > > > Sorry. I meant the Delta between MDCFG0.tRFC and the > > other two fields. > > OK, now I see what you mean and how you got these values. But I disagree. > > tXS(min) and tXPR(min) are defined by the JEDEC DDR3 specification as > max(5 nCK, tRFC(min) + 10 ns). tRFC(min) is used here, not tRFC. > > Moreover, tXS and tXPR are timings depending on internal features of the RAM, > not on external operations from the host processor. It's not as if they were > the > result of the combination of two external operations. E.g., see tXS on > figures > 14, 15 and 62 in JESD79-3F. I don't know if that's clear enough, but here I mean that
Re: [U-Boot] M29EW flash is detected as 0xFF
On 18.02.2013 10:57, Jagan Teki wrote: > I have a 16MB, M29EW flash on target boards. > > I got the below info, while probing the flash. > > Bank # 1: CFI conformant flash (8 x 8) Size: 64 MB in 512 Sectors > AMD Standard command set, Manufacturer ID: 0xFF, Device ID: 0xFF > Erase timeout: 4096 ms, write timeout: 2 ms > Buffer write timeout: 5 ms, buffer size: 1024 bytes > > Since the Manu.ID of this flash is 0x89, it got detected as 0xFF. > > Does u-boot code have a support for M29EW flash..? I'm pretty sure, yes. Which U-Boot version are you using? Most likely its an older version. Your problem reminds me about this commit: Author: Philippe De Muyter 2010-08-10 16:54:52 Committer: Stefan Roese 2010-08-18 09:09:00 Parent: 2e97394a6d07a36dfc139b7b98b12e452b5bd8dc (cfi_flash: flinfo: allow user interrupt in flash print info fn) Child: 70084df7125a0b67de707b82ec67adfdc35c (cfi_flash: Cleanup flash_print_info()) Branches: many (98) Follows: v2010.06 Precedes: v2010.09-rc1 Fix printing & reading of 16-bit CFI device identifiers Fix reading and printing of CFI flashes 16-bit devices identifiers Nowadays CFI flashes have a 16-bit device identifier. U-boot still print them and read them as if they were only 8-bit wide. Fix that. Before: Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x1B After: Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x881B So please update to the latest version and try again. Best regards, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] ARM: bootm: allow skipping fdt memory node fixup
On 02/19/2013 05:14 PM, Wolfgang Denk wrote: > Dear Rob Herring, > > In message <5123e311.1070...@gmail.com> you wrote: >> [snip] >> What I would really prefer to do is like powerpc where platforms >> override this if they need the fixup and the default behavior is no >> fixup. But that would require knowing which platforms do and don't need >> the fixup. It only going to get harder to change that. > > Normally we use get_ramsize() to check / verify the amount of > available RAM. And on PPC, we nearly always set the ram size in the > DT. I don't know why you think the default was no fixup; this is not > true. It's the other way round. No it is not. The fixup is in bootm.c for all of arm, yet appears in all the board/soc files for powerpc. It may be nearly always fixed up because every platform duplicates the fixup code, but it is not the default. It is a per platform decision on powerpc and it is not on arm. $ git grep fixup_memory arch/arm/lib/bootm.c:static int fixup_memory_node(void *blob) arch/arm/lib/bootm.c: return fdt_fixup_memory_banks(blob, start, size, CONFIG_NR_DRAM_BANKS); arch/arm/lib/bootm.c: fixup_memory_node(*of_flat_tree); arch/powerpc/cpu/74xx_7xx/cpu.c:fdt_fixup_memory(blob, (u64)bd->bi_memstart, (u64)bd->bi_memsize); arch/powerpc/cpu/mpc512x/cpu.c: fdt_fixup_memory(blob, (u64)bd->bi_memstart, (u64)bd->bi_memsize); arch/powerpc/cpu/mpc5xxx/cpu.c: fdt_fixup_memory(blob, (u64)bd->bi_memstart, (u64)bd->bi_memsize); arch/powerpc/cpu/mpc8260/cpu.c: fdt_fixup_memory(blob, (u64)bd->bi_memstart, (u64)bd->bi_memsize); arch/powerpc/cpu/mpc83xx/fdt.c: fdt_fixup_memory(blob, (u64)bd->bi_memstart, (u64)bd->bi_memsize); arch/powerpc/cpu/mpc85xx/fdt.c: fdt_fixup_memory(blob, (u64)bd->bi_memstart, (u64)bd->bi_memsize); arch/powerpc/cpu/mpc86xx/fdt.c: fdt_fixup_memory(blob, (u64)bd->bi_memstart, (u64)bd->bi_memsize); arch/powerpc/cpu/mpc8xx/fdt.c: fdt_fixup_memory(blob, (u64)bd->bi_memstart, (u64)bd->bi_memsize); arch/powerpc/cpu/ppc4xx/fdt.c: fdt_fixup_memory(blob, (u64)bd->bi_memstart, (u64)bd->bi_memsize); board/exmeritus/hww1u1a/hww1u1a.c: fdt_fixup_memory(blob, (u64)base, (u64)size); board/freescale/bsc9131rdb/bsc9131rdb.c:fdt_fixup_memory(blob, (u64)base, (u64)size); board/freescale/corenet_ds/corenet_ds.c:fdt_fixup_memory(blob, (u64)base, (u64)size); board/freescale/mpc7448hpc2/mpc7448hpc2.c: fdt_fixup_memory(blob, (u64)bd->bi_memstart, (u64)bd->bi_memsize); board/freescale/mpc8572ds/mpc8572ds.c: fdt_fixup_memory(blob, (u64)base, (u64)size); board/freescale/p1010rdb/p1010rdb.c:fdt_fixup_memory(blob, (u64)base, (u64)size); board/freescale/p1022ds/p1022ds.c: fdt_fixup_memory(blob, (u64)base, (u64)size); board/freescale/p1023rds/p1023rds.c:fdt_fixup_memory(blob, (u64)base, (u64)size); board/freescale/p1_p2_rdb/p1_p2_rdb.c: fdt_fixup_memory(blob, (u64)base, (u64)size); board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c:fdt_fixup_memory(blob, (u64)base, (u64)size); board/freescale/p2020come/p2020come.c: fdt_fixup_memory(blob, (u64)base, (u64)size); board/freescale/p2020ds/p2020ds.c: fdt_fixup_memory(blob, (u64)base, (u64)size); board/freescale/p2041rdb/p2041rdb.c:fdt_fixup_memory(blob, (u64)base, (u64)size); board/freescale/t4qds/t4qds.c: fdt_fixup_memory(blob, (u64)base, (u64)size); board/ipek01/ipek01.c: fdt_fixup_memory (blob, (u64) bd->bi_memstart, (u64) bd->bi_memsize); board/pdm360ng/pdm360ng.c: fdt_fixup_memory(blob, (u64)bd->bi_memstart, (u64)bd->bi_memsize); common/cmd_fdt.c: err = fdt_fixup_memory(working_fdt, addr, size); common/fdt_support.c:int fdt_fixup_memory_banks(void *blob, u64 start[], u64 size[], int banks) common/fdt_support.c:int fdt_fixup_memory(void *blob, u64 start, u64 size) common/fdt_support.c: return fdt_fixup_memory_banks(blob, &start, &size, 1); include/fdt_support.h:int fdt_fixup_memory(void *blob, u64 start, u64 size); include/fdt_support.h:int fdt_fixup_memory_banks(void *blob, u64 start[], u64 size[], int banks); >>> Actually you are reaching here a point where it seems necessary that >>> U-Boot itself is able to read the DT to configure itself correctly, >>> i. e. the memory size information it holds should then also be >>> extracted from the DT. >> >> I thought about doing this. That's really an orthogonal issue. The >> problem is you cannot adjust the amount of memory u-boot uses to be >> different than the amount of RAM in the /memory node. If you adjust the >> size in u-boot, the adjusted size is passed to the kernel no matter what. >> >> There's issues with LPAE systems having >4GB of RAM as all the size and >> address values are 32-bit. This could be fixed, but I'm not sure there >> is much value in u-boot knowing about memory above 4GB as it can't >> really access all of it and it would be purely informational. > > Well, let's face it - no matter what you do, if the RAM sizes as used > in U-Boot and in Linux differ, at least one of these
Re: [U-Boot] [PATCH 2/4] omap5_evm: Enable CONFIG_CMD_BOOTZ
On Wednesday 20 February 2013 02:48 AM, Tom Rini wrote: With v3.9 and later of the Linux Kernel defaulting to multi-platform images with omap2plus_defconfig, uImage isn't builtable anymore by default. Add CONFIG_CMD_BOOTZ so that we can still boot something the kernel spits out. Cc: Sricharan R Signed-off-by: Tom Rini --- include/configs/omap5_evm.h |1 + 1 file changed, 1 insertion(+) diff --git a/include/configs/omap5_evm.h b/include/configs/omap5_evm.h index 623da77..85ea88b 100644 --- a/include/configs/omap5_evm.h +++ b/include/configs/omap5_evm.h @@ -55,6 +55,7 @@ #define CONFIG_MISC_INIT_R #define CONFIG_OF_LIBFDT +#define CONFIG_CMD_BOOTZ Reviewed-by: R Sricharan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add Boundary Devices Nitrogen6X boards
Hi Benoît, On 02/20/2013 06:28 AM, Benoît Thébaudeau wrote: Hi Eric, On Wednesday, February 20, 2013 1:05:04 PM, Benoît Thébaudeau wrote: Hi Eric, On Wednesday, February 20, 2013 12:01:15 AM, Eric Nelson wrote: Hi Benoît, On 02/19/2013 03:31 PM, Benoît Thébaudeau wrote: On Tuesday, February 19, 2013 10:53:48 PM, Eric Nelson wrote: On 02/19/2013 01:52 PM, Benoît Thébaudeau wrote: Hi Eric, On Tuesday, February 19, 2013 9:20:48 PM, Eric Nelson wrote: [--snip--] diff --git a/board/boundary/nitrogen6x/1066mhz_4x128mx16.cfg b/board/boundary/nitrogen6x/1066mhz_4x128mx16.cfg new file mode 100644 index 000..45b8879 --- /dev/null +++ b/board/boundary/nitrogen6x/1066mhz_4x128mx16.cfg [--snip--] +DATA 4, MX6_MMDC_P0_MDPDC, 0x00020036 +DATA 4, MX6_MMDC_P0_MDCFG0, 0x555B7974 ^A? +DATA 4, MX6_MMDC_P0_MDCFG1, 0xDB538F64 +DATA 4, MX6_MMDC_P0_MDCFG2, 0x01FF00DB +DATA 4, MX6_MMDC_P0_MDRWD, 0x26D2 +DATA 4, MX6_MMDC_P0_MDOR, 0x005B1023 ^A? +DATA 4, MX6_MMDC_P0_MDOTC, 0x09444040 +DATA 4, MX6_MMDC_P0_MDPDC, 0x00025576 [--snip--] tXS = tXPR = 170 ns -> 91 nCK -> 91 - 1 -> 0x5A. Thanks Benoît, I was going to bring this up in a separate thread. While working through the details of our 800MHz variants (Solo, Dual-Lite), and x256mx16 variants, I re-worked these numbers and it seems that we have an off-by-one issue with those fields. Probably because it has been missed that the bit-field > value is the number of clock cycles minus 1. Right. All of these fields are plus 1. MDCFG0.tRFC MDCFG0.tXS MDOR.tXPR Since they're all in the same units, the requirements are: MDCFG0.tXS >= MDCFG0.tRFC + 10nS and MDOR.tXPR >= MDCFG0.tRFC + 10nS Since we operate at ~528MHz, each clock is less than 2 nS, and we need 6 more clocks for each. According to the JEDEC spec and data sheets, both tXS and tXPR should be 10nS greater than tRFC. Indeed, or more precisely, max(5 nCK, tRFC + 10 ns). Yep. I shortened because nothing approaches 5nCK. And note that this is the minimum spec, not the target. Since the nominal clock for i.MX6 is 528MHz (1.89nS), I used 532 MHz because this is a more standard value, and I found several close different values in the documentation, so in the doubt, I chose the worst case. With 528 MHz, the bit-field value would be 0x59. Either way, we need 6 clocks to get > 10nS. this should be a delta of 6 clocks, not 5. Delta with what? Sorry. I meant the Delta between MDCFG0.tRFC and the other two fields. OK, now I see what you mean and how you got these values. But I disagree. tXS(min) and tXPR(min) are defined by the JEDEC DDR3 specification as max(5 nCK, tRFC(min) + 10 ns). tRFC(min) is used here, not tRFC. Moreover, tXS and tXPR are timings depending on internal features of the RAM, not on external operations from the host processor. It's not as if they were the result of the combination of two external operations. E.g., see tXS on figures 14, 15 and 62 in JESD79-3F. I don't know if that's clear enough, but here I mean that tXS and tXPR are intrinsic RAM timings, and that there is no way tRFC(MMDC) can interfere with either tXS/XPR(DDR3) or tXS/XPR(MMDC), so there is no reason to take tRFC(MMDC) into account to determine tXS or tXPR. Only tRFC(min) should be used here. You're right of course. And this description was very clear. We don't communicate __our__ tRFC to the device, so there's no reason our tRFC couldn't be higher than tXS/XPR. Hence, tXS and tXPR should not be considered as tRFC(MMDC) + 10 ns, but really as tRFC(min) + 10 ns, i.e. a single 170 ns timing (for 2-Gib density) to be converted into a number of clock cycles. I don't feel like it's possible to interpret the specification in a different way. But perhaps I'm wrong. I also have no evidence of failures because of these settings and will drop the +1 in a V2 patch set. Thanks again for your detailed review. Regards, Eric ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] omap4_common: Enable CONFIG_CMD_BOOTZ
Hi, On Wednesday 20 February 2013 02:48 AM, Tom Rini wrote: With v3.9 and later of the Linux Kernel defaulting to multi-platform images with omap2plus_defconfig, uImage isn't builtable anymore by default. Add CONFIG_CMD_BOOTZ so that we can still boot something the kernel spits out. Cc: Sricharan R Signed-off-by: Tom Rini --- include/configs/omap4_common.h |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/configs/omap4_common.h b/include/configs/omap4_common.h index 180cb24..6ae6a0f 100644 --- a/include/configs/omap4_common.h +++ b/include/configs/omap4_common.h @@ -52,7 +52,7 @@ #define CONFIG_MISC_INIT_R #define CONFIG_OF_LIBFDT 1 - +#define CONFIG_CMD_BOOTZ Reviewed-by: R Sricharan Regards, Sricharan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] ARM: bootm: allow skipping fdt memory node fixup
Dear Rob,
In message <20130219231428.44c8a200...@gemini.denx.de> I wrote:
>
> > There is no such way defined to flag that and I'm not going to invent
> > one. It's not that the memory node is immutable, but the default should
> > not be "needs fixups". No one puts purposely wrong data in their DT. So
> > therefore all data should be immutable? What happens when we need to
> > fixup immutable data?
>
> There is for example the "status" property, which can take the values
> "okay" or "disabled". This is used in other places for not so
> unsimilar purposes.
Actually it's even much simpler than that.
If you look for example at PPC, you will see many memory nodes in the
DTB that look like this one (this example is from
arch/powerpc/boot/dts/canyonlands.dts):
memory {
device_type = "memory";
reg = <0x 0x 0x>; /* Filled in by
U-Boot */
};
I. e. the DT provides only dummy values.
How about checking for these - if the DT contains such dummy entries,
U-Boot will insert valid data; if the DT already contains real data,
these take preference? [And if the latter differ from what U-Boot
thinks is correct, then a big fat warning should be issued!]
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
God made the integers; all else is the work of Man. - Kronecker
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Memory timings for SABRE Lite/SABRE SD
Hi all, While investigating some CPU Frequency scaling issues on the latest i.MX6DQ silicon, we discovered that the memory timings in mx6q_4x_mt41j128.cfg. In particular, these values of MX6_MMDC_Px_MPWLDECTRLy are wrong for SABRE Lite and probably SABRE SD. DATA 4 0x021b080c 0x001F001F DATA 4 0x021b0810 0x001F001F DATA 4 0x021b480c 0x00440044 DATA 4 0x021b4810 0x00440044 These are write-leveling delay lines, and our calibration showed measured values in the range of 0x7..0x1b for these fields. The 0x44 values are shown in AN4467.pdf as an example of what might be used in a fly-by topology. http://cache.freescale.com/files/32bit/doc/app_note/AN4467.pdf The SABRE Lite design doesn't use fly-by, and I suspect that SABRE SD doesn't either. When adding Nitrogen6x support, we went through an extensive calibration process on a large set of boards, but the values above showed the greatest variance from mx6q_4x_mt41j128.cfg. Also note that in the 2009.08 code base, these values are set to 0x1f for SABRE SD, which appears not to be a measured delay, but is much more sane. http://git.freescale.com/git/cgit.cgi/imx/uboot-imx.git/tree/board/freescale/mx6q_sabresd/flash_header.S?h=imx_v2009.08_1.1.0#n248 In that code base, SABRE Lite appears wrong: http://git.freescale.com/git/cgit.cgi/imx/uboot-imx.git/tree/board/freescale/mx6q_sabrelite/flash_header.S?h=imx_v2009.08_1.1.0#n161 Regards, Eric ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add Boundary Devices Nitrogen6X boards
Dear Eric Nelson,
In message <1361305248-24598-1-git-send-email-eric.nel...@boundarydevices.com>
you wrote:
> +static int detect_hdmi(struct display_info_t const *dev)
> +{
> + return __raw_readb(HDMI_ARB_BASE_ADDR+HDMI_PHY_STAT0) & HDMI_PHY_HPD;
...
> + reg = __raw_readb(
> + HDMI_ARB_BASE_ADDR
> + +HDMI_PHY_CONF0);
etc. etc.
NAK!! We do not allow device access through base address plus offset
notation. Please use a proper C Struct to access thes device.
Also, are you absolutely sure that the __raw_* accessors are the right
thing to use here? Are you really sure no memory barriers etc. are
needed here?
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
The heart is not a logical organ.
-- Dr. Janet Wallace, "The Deadly Years", stardate 3479.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Possible GPL violation
Dear Mateusz, In message <5123e16b.1060...@gmail.com> you wrote: > > Is there anyone that can support me with enforcing GPL compliance on > company that ships product with binary u-boot? Or did that in the past? We can try. > They're "made" (branded is probably better word) by local companies, and > my guess is that most of them is violating GPL. Guesses are not good enough in such legal affairs. > I can't do much myself (except for nagging them for source code), as > it's not my copyrights that they're infringing. So did you contact the vendor and ask for the source code? And did they answer, and what exactly? 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 Contrary to popular belief, thinking does not cause brain damage. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] ARM: bootm: allow skipping fdt memory node fixup
On Tue, Feb 19, 2013 at 02:39:45PM -0600, Rob Herring wrote: > On 02/19/2013 01:26 PM, Wolfgang Denk wrote: [snip] > > I dislike this. If you want to make a property of your device tree > > "immutable", then you should mark it there as such. Instead of > > removing the code here, U-Boot should then check for such a property > > and leave the value unchanged. > > There is no such way defined to flag that and I'm not going to invent > one. It's not that the memory node is immutable, but the default should > not be "needs fixups". No one puts purposely wrong data in their DT. So > therefore all data should be immutable? What happens when we need to > fixup immutable data? It's not so simple. The first DTs I checked are the am335x ones and I see they hardcode to 256MB which isn't right, but no one has caught this since it's blindly fixed up. So as Wolfgang suggests next, we might need to go with replacing on 0x0 entries and warning when they don't match what U-Boot has detected. -- 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] env: fix "env ask" command
The "env ask" traditionally uses a somewhat awkward syntax:
env ask name [message ...] [size]
So far, when a mesage was given, you always also had to enter a size.
If you forgot to do that, the command would terminate without any
indication of the problem.
To avoid incompatible changes of the interface, we now check the last
argument if it can be converted into a decimal number. If this is the
case, we assume it is a size; otherwise we treat it as part of the
message.
Also, add a space after the message fore easier reading,
and clean up help mesage.
Signed-off-by: Wolfgang Denk
---
common/cmd_nvedit.c | 56 +++--
1 file changed, 29 insertions(+), 27 deletions(-)
diff --git a/common/cmd_nvedit.c b/common/cmd_nvedit.c
index 7633f0c..5f30f86 100644
--- a/common/cmd_nvedit.c
+++ b/common/cmd_nvedit.c
@@ -325,41 +325,50 @@ static int do_env_set(cmd_tbl_t *cmdtp, int flag, int
argc, char * const argv[])
int do_env_ask(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
{
char message[CONFIG_SYS_CBSIZE];
- int size = CONFIG_SYS_CBSIZE - 1;
- int i, len, pos;
+ int i, len, pos, size;
char *local_args[4];
+ char *endptr;
local_args[0] = argv[0];
local_args[1] = argv[1];
local_args[2] = NULL;
local_args[3] = NULL;
- /* Check the syntax */
- switch (argc) {
- case 1:
+ /*
+* Check the syntax:
+*
+* env_ask envname [message1 ...] [size]
+*/
+ if (argc == 1)
return CMD_RET_USAGE;
- case 2: /* env_ask envname */
- sprintf(message, "Please enter '%s':", argv[1]);
- break;
-
- case 3: /* env_ask envname size */
- sprintf(message, "Please enter '%s':", argv[1]);
- size = simple_strtoul(argv[2], NULL, 10);
- break;
-
- default:/* env_ask envname message1 ... messagen size */
- for (i = 2, pos = 0; i < argc - 1; i++) {
+ /*
+* We test the last argument if it can be converted
+* into a decimal number. If yes, we assume it's
+* the size. Otherwise we echo it as part of the
+* message.
+*/
+ i = simple_strtoul(argv[argc - 1], &endptr, 10);
+ if (*endptr != '\0') { /* no size */
+ size = CONFIG_SYS_CBSIZE - 1;
+ } else {/* size given */
+ size = i;
+ --argc;
+ }
+
+ if (argc <= 2) {
+ sprintf(message, "Please enter '%s': ", argv[1]);
+ } else {
+ /* env_ask envname message1 ... messagen [size] */
+ for (i = 2, pos = 0; i < argc; i++) {
if (pos)
message[pos++] = ' ';
strcpy(message + pos, argv[i]);
pos += strlen(argv[i]);
}
-
+ message[pos++] = ' ';
message[pos] = '\0';
- size = simple_strtoul(argv[argc - 1], NULL, 10);
- break;
}
if (size >= CONFIG_SYS_CBSIZE)
@@ -1168,14 +1177,7 @@ U_BOOT_CMD(
askenv, CONFIG_SYS_MAXARGS, 1, do_env_ask,
"get environment variables from stdin",
"name [message] [size]\n"
- "- get environment variable 'name' from stdin (max 'size' chars)\n"
- "askenv name\n"
- "- get environment variable 'name' from stdin\n"
- "askenv name size\n"
- "- get environment variable 'name' from stdin (max 'size' chars)\n"
- "askenv name [message] size\n"
- "- display 'message' string and get environment variable 'name'"
- "from stdin (max 'size' chars)"
+ "- get environment variable 'name' from stdin (max 'size' chars)"
);
#endif
--
1.7.11.7
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] serial/ns16550: don't generate functions for undefined ports
On Fri, Jan 18, 2013 at 03:42:16PM -, Scott Wood wrote: > This saved 640 bytes on MPC8536DS (a board with two of the six > ports defined). > > Signed-off-by: Scott Wood Applied to u-boot/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] malloc: make malloc_bin_reloc static
On Mon, Jan 21, 2013 at 09:10:38PM -, Gabor Juhos wrote:
> On architectures where manual relocation
> is needed, the 'malloc_bin_reloc' function
> must be called after 'mem_malloc_init'.
>
> Make the 'malloc_bin_reloc' function static
> and call it directly from 'mem_malloc_init'
> instead of calling that from board_init_{r,f}
> functions of the affected architectures.
>
> Signed-off-by: Gabor Juhos
> Cc: Wolfgang Denk
> Cc: Andreas Bie??mann
> Cc: Jason Jin
> Cc: Macpaul Lin
> Cc: Daniel Hellstrom
> Cc: Daniel Schwierzeck
Applied to u-boot/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] [U-Boot, 1/2, V2] SF: Add driver for Gigabyte device GD25LQ and GD25Q64B
On Tue, Jan 22, 2013 at 08:30:18PM -, Rajeshwari Shinde wrote: > This patch adds driver for the gigabyte devices > GD25LQ and GD25Q64B required for Snow Board. > > Signed-off-by: Rajeshwari Shinde > Acked-by: Simon Glass Reviewed-by: Tom Rini Both parts of the series can go via u-boot-samsung and then u-boot-arm, 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] common: cmd_bdinfo: Fix bdinfo to show all MACs for Microblaze and ARM
On Wed, Jan 23, 2013 at 01:23:02AM -, Michal Simek wrote: > - Show all ethernet MACs in the system. > - Show current ethernet device > > Signed-off-by: Michal Simek Applied to u-boot/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] [U-Boot,1/2] vsprintf: add ustrtoll function
On Sun, Jan 27, 2013 at 10:59:24PM -, Piotr Wilczek wrote: > Add 'ustrtoull' function to convert size from string (ex: 1GiB) > to unsigned long long type > > Signed-off-by: Piotr Wilczek > Signed-off-by: Kyungmin Park For the series, applied to u-boot/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] [U-Boot, v2] MAKEALL: add support for per architecture toolchains
On Tue, Jan 29, 2013 at 02:34:58PM -, Allen Martin wrote: > Add support for per architecture CROSS_COMPILE toolchain definitions > via CROSS_COMPILE_ARCH where "ARCH" is any of the supported u-boot > architectures. This allows building every supported u-boot board in a > single pass of MAKEALL. > > Signed-off-by: Allen Martin > Acked-by: Simon Glass > Reviewed-by: Stephen Warren Applied to u-boot/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] fw_env.config: Correct "fw_saveenv" to "fw_setenv".
On Thu, Jan 31, 2013 at 02:06:40AM -, Robert P. J. Day wrote: > Fix a comment in the fw_env.config file, no functional change. > > Signed-off-by: Robert P. J. Day Applied to u-boot/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] [U-Boot, v3] cmd_mem.c: Fix some typoes, no functional changes
On Sun, Feb 03, 2013 at 02:29:54AM -, Robert P. J. Day wrote: > Signed-off-by: Robert P. J. Day Applied to u-boot/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] cmd_load.c: Add #endif comments to reduce confusion
On Sun, Feb 03, 2013 at 05:46:13AM -, Robert P. J. Day wrote: > Signed-off-by: Robert P. J. Day Applied to u-boot/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] cmd_elf:Fix broken bootvx command
On Mon, Feb 04, 2013 at 09:37:11AM -, Reinhard Arlt wrote: > commit d2d6bdaaef5f7eb39551e2288164b710021125fd > Author: Reinhard Arlt > Date: Mon Feb 4 19:45:16 2013 +0100 > > Fix broken bootvx command. > > Signed-off-by: Reinhard Arlt Applied to u-boot/master with a fixup to the commit message, 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] [U-Boot, 1/3] gpio: Build the da8xx_gpio code for the davinci644x device
On Thu, Feb 07, 2013 at 11:41:01PM -, Holger Hans Peter Freyther wrote: > The differences include the number of GPIOs and that one is > not required to set the pinmux on request. > > Signed-off-by: Holger Hans Peter Freyther For the series, applied to u-boot/master, thanks! (I checked with Albert on IRC quick and he's OK with 1 TI ARM specific patch and 2 generics going to master directly). -- 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 v4 4/4] Tegra: MMC: Add DT support to MMC driver for all T20 boards
Stephen,
On Thu, Feb 14, 2013 at 4:12 PM, Stephen Warren wrote:
> On 02/14/2013 02:04 PM, Tom Warren wrote:
>> tegra_mmc_init() now parses the DT info for bus width, WP/CD GPIOs, etc.
>> Tested on Seaboard, fully functional.
>>
>> Tamonten boards (medcom-wide, plutux, and tec) use a different/new
>> dtsi file w/common settings.
>
>> diff --git a/drivers/mmc/tegra_mmc.c b/drivers/mmc/tegra_mmc.c
>
>> @@ -515,44 +483,47 @@ static int mmc_core_init(struct mmc *mmc)
>> int tegra_mmc_getcd(struct mmc *mmc)
>> {
>> struct mmc_host *host = (struct mmc_host *)mmc->priv;
>> + debug("%s called, host->cd_gpio = 0x%08X\n", __func__,
>> + (unsigned)&host->cd_gpio);
>
> That last line should be:
>
> host->cd_gpio.gpio;
>
> The case is because it's a struct address, not the GPIO you want to print.
Actually, I did want to print the address of the cd_gpio struct, so I
could look at it from the cmd line w/md and/or w/JTAG.
But I'll just remove the debug printf entirely, since it was only
useful early on.
>
>> +static int do_mmc_init(int dev_index)
>
>> - if (host->pwr_gpio >= 0) {
>> + if (fdt_gpio_isvalid(&host->pwr_gpio)) {
>> sprintf(gpusage, "SD/MMC%d PWR", dev_index);
>> - gpio_request(host->pwr_gpio, gpusage);
>> - gpio_direction_output(host->pwr_gpio, 1);
>> + gpio_request(host->pwr_gpio.gpio, gpusage);
>> + fdtdec_set_gpio(&host->pwr_gpio, 1);
>
> That change completely removes the call to gpio_direction_output;
> fdtdec_set_gpio() doesn't do that. This is the cause of the problem on
> PAZ00, and Harmony.
OK, cool. Good catch. I thought the fdtdec_xxx_gpio calls did it all,
but now I see that they don't.
>
>> - if (host->cd_gpio >= 0) {
>> + if (fdt_gpio_isvalid(&host->cd_gpio)) {
>> sprintf(gpusage, "SD/MMC%d CD", dev_index);
>> - gpio_request(host->cd_gpio, gpusage);
>> - gpio_direction_input(host->cd_gpio);
>> + gpio_request(host->cd_gpio.gpio, gpusage);
>> + card_det = fdtdec_get_gpio(&host->cd_gpio);
>
> Similarly, this change removes the call to gpio_direction_input();
> fdtdec_get_gpio() just reads the GPIO's value and is pointless here.
No, not pointless - I was checking the CD pin state and printing it
out during debug. But it's not of much interest to anyone but me at
this point, so I'll remove the card_det lines.
>
> I'll go retest all the boards after fixing that...
Thanks
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 4/4] Tegra: MMC: Add DT support to MMCdriver for all T20 boards
Marc/Stephen,
On Fri, Feb 15, 2013 at 9:42 AM, Marc Dietrich wrote:
> Stephen,
>
> On Thursday 14 February 2013 16:12:42 Stephen Warren wrote:
>> On 02/14/2013 02:04 PM, Tom Warren wrote:
>> > tegra_mmc_init() now parses the DT info for bus width, WP/CD GPIOs, etc.
>> > Tested on Seaboard, fully functional.
>> >
>> > Tamonten boards (medcom-wide, plutux, and tec) use a different/new
>> > dtsi file w/common settings.
>> >
>> > diff --git a/drivers/mmc/tegra_mmc.c b/drivers/mmc/tegra_mmc.c
>> >
>> > @@ -515,44 +483,47 @@ static int mmc_core_init(struct mmc *mmc)
>> >
>> > int tegra_mmc_getcd(struct mmc *mmc)
>> > {
>> >
>> > struct mmc_host *host = (struct mmc_host *)mmc->priv;
>> >
>> > + debug("%s called, host->cd_gpio = 0x%08X\n", __func__,
>> > + (unsigned)&host->cd_gpio);
>>
>> That last line should be:
>>
>> host->cd_gpio.gpio;
>>
>> The case is because it's a struct address, not the GPIO you want to print.
>>
>> > +static int do_mmc_init(int dev_index)
>> >
>> > - if (host->pwr_gpio >= 0) {
>> > + if (fdt_gpio_isvalid(&host->pwr_gpio)) {
>> >
>> > sprintf(gpusage, "SD/MMC%d PWR", dev_index);
>> >
>> > - gpio_request(host->pwr_gpio, gpusage);
>> > - gpio_direction_output(host->pwr_gpio, 1);
>> > + gpio_request(host->pwr_gpio.gpio, gpusage);
>> > + fdtdec_set_gpio(&host->pwr_gpio, 1);
>>
>> That change completely removes the call to gpio_direction_output;
>> fdtdec_set_gpio() doesn't do that. This is the cause of the problem on
>> PAZ00, and Harmony.
>>
>> > - if (host->cd_gpio >= 0) {
>> > + if (fdt_gpio_isvalid(&host->cd_gpio)) {
>> >
>> > sprintf(gpusage, "SD/MMC%d CD", dev_index);
>> >
>> > - gpio_request(host->cd_gpio, gpusage);
>> > - gpio_direction_input(host->cd_gpio);
>> > + gpio_request(host->cd_gpio.gpio, gpusage);
>> > + card_det = fdtdec_get_gpio(&host->cd_gpio);
>>
>> Similarly, this change removes the call to gpio_direction_input();
>> fdtdec_get_gpio() just reads the GPIO's value and is pointless here.
>>
>> I'll go retest all the boards after fixing that...
>
> yup - with these changes, everything is fine again on PAZ00.
>
Thanks, guys. I'll roll out a v5 patchset later today.
Tom
> Marc
>
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 4/4] Tegra: MMC: Add DT support to MMC driver for all T20 boards
Andy,
On Mon, Feb 18, 2013 at 4:10 PM, Andy Fleming wrote:
>
>
>
> On Thu, Feb 14, 2013 at 3:04 PM, Tom Warren
> wrote:
>>
>> tegra_mmc_init() now parses the DT info for bus width, WP/CD GPIOs, etc.
>> Tested on Seaboard, fully functional.
>>
>> Tamonten boards (medcom-wide, plutux, and tec) use a different/new
>> dtsi file w/common settings.
>>
>> Signed-off-by: Tom Warren
>> Signed-off-by: Thierry Reding
>> ---
>> v2:
>> - all boards now call tegra_mmc_init once, w/no params
>> - count MMC controllers, not aliases
>> - AD boards (medcom/plutux/tec) use common tegra20-tamonten.dtsi
>> v3:
>> - move any power init inside board's pin_mux_mmc function, and/or
>> create pin_mux_mmc function if necessary.
>> - move board_mmc_init out of each board file and into ../common/board.c
>> v4:
>> - remove #ifdef CONFIG_TEGRA_MMC from trimslice.c
>> - fix minor whitespace issue in board/nvidia/common/board.c
>> - remove marking of used node_list entries in MMC driver, not needed
>>
>
>
>>
>> diff --git a/drivers/mmc/tegra_mmc.c b/drivers/mmc/tegra_mmc.c
>> index d749ab0..918a98d 100644
>> --- a/drivers/mmc/tegra_mmc.c
>> +++ b/drivers/mmc/tegra_mmc.c
>> @@ -21,6 +21,7 @@
>>
>> #include
>> #include
>> +#include
>> #include
>> #include
>> #include
>> @@ -28,54 +29,23 @@
>> #include
>> #include
>>
>> -/* support 4 mmc hosts */
>> -struct mmc mmc_dev[4];
>> -struct mmc_host mmc_host[4];
>> +DECLARE_GLOBAL_DATA_PTR;
>>
>> +struct mmc mmc_dev[MAX_HOSTS];
>> +struct mmc_host mmc_host[MAX_HOSTS];
>>
>> -/**
>> - * Get the host address and peripheral ID for a device. Devices are
>> numbered
>> - * from 0 to 3.
>> - *
>> - * @param host Structure to fill in (base, reg, mmc_id)
>> - * @param dev_indexDevice index (0-3)
>> - */
>> -static void tegra_get_setup(struct mmc_host *host, int dev_index)
>> -{
>> - debug("tegra_get_setup: dev_index = %d\n", dev_index);
>> -
>> - switch (dev_index) {
>> - case 1:
>> - host->base = TEGRA_SDMMC3_BASE;
>> - host->mmc_id = PERIPH_ID_SDMMC3;
>> - break;
>> - case 2:
>> - host->base = TEGRA_SDMMC2_BASE;
>> - host->mmc_id = PERIPH_ID_SDMMC2;
>> - break;
>> - case 3:
>> - host->base = TEGRA_SDMMC1_BASE;
>> - host->mmc_id = PERIPH_ID_SDMMC1;
>> - break;
>> - case 0:
>> - default:
>> - host->base = TEGRA_SDMMC4_BASE;
>> - host->mmc_id = PERIPH_ID_SDMMC4;
>> - break;
>> - }
>> -
>> - host->reg = (struct tegra_mmc *)host->base;
>> -}
>> +#ifndef CONFIG_OF_CONTROL
>> +#error "Please enable device tree support to use this driver"
>> +#endif
>>
>> static void mmc_prepare_data(struct mmc_host *host, struct mmc_data
>> *data,
>> struct bounce_buffer *bbstate)
>> {
>> unsigned char ctrl;
>>
>> -
>> - debug("buf: %p (%p), data->blocks: %u, data->blocksize: %u\n",
>> - bbstate->bounce_buffer, bbstate->user_buffer,
>> data->blocks,
>> - data->blocksize);
>> + debug("%s: buf: %p (%p), data->blocks: %u, data->blocksize: %u\n",
>> + __func__, bbstate->bounce_buffer, bbstate->user_buffer,
>> + data->blocks, data->blocksize);
>
>
>
> This patch is FULL of these changes. It makes it almost impossible to
> identify the substantive changes to this code. In the future, please put
> changes to debug output in a separate patch, unless it directly applies to
> the relevant change. Also, I note that you didn't mention the fact that you
> reworked all the debug() calls to prefix with the function name in your
> patch description.
I can move the debug changes to a separate patch, no problem. I added
the function name prefix because, in some cases, the hard-coded string
didn't identify the function correctly (someone moved or renamed the
function during a feature add/rewrite (bounce buffer, etc.) and didn't
update the debug printf string). So I thought it best to add the
function name to each debug printf, making it easier to identify where
the info was coming from. I'll add a comment about that to the new
patch, too. Thanks.
>
>>
>> +/*
>> + * Process a list of nodes, adding them to our list of SDMMC ports.
>> + *
>> + * @param blob fdt blob
>> + * @param node_list list of nodes to process (any <=0 are ignored)
>> + * @param count number of nodes to process
>> + * @return 0 if ok, -1 on error
>> + */
>> +static int process_nodes(const void *blob, int node_list[], int count)
>> +{
>> + struct mmc_host *host;
>> + int i, node;
>> +
>> + debug("%s: count = %d\n", __func__, count);
>> +
>> + /* build mmc_host[] for each controller */
>> + for (i = 0; i < count; i++) {
>> + node = node_list[i];
>> + if (node <= 0)
>> + continue;
>> +
>> + host = &mmc_host[i]
Re: [U-Boot] [PATCH] Add Boundary Devices Nitrogen6X boards
Hi Wolfgang,
On 02/20/2013 07:20 AM, Wolfgang Denk wrote:
Dear Eric Nelson,
In message <1361305248-24598-1-git-send-email-eric.nel...@boundarydevices.com>
you wrote:
+static int detect_hdmi(struct display_info_t const *dev)
+{
+ return __raw_readb(HDMI_ARB_BASE_ADDR+HDMI_PHY_STAT0) & HDMI_PHY_HPD;
...
+ reg = __raw_readb(
+ HDMI_ARB_BASE_ADDR
+ +HDMI_PHY_CONF0);
etc. etc.
NAK!! We do not allow device access through base address plus offset
notation. Please use a proper C Struct to access thes device.
This tells me that there's other breakage here. In particular,
this usage follows the lead of drivers/video/ipu_common.c and
the detect code is also present in mx6qsabrelite.c:
http://git.denx.de/u-boot.git/?p=u-boot.git;a=blob;f=board/freescale/mx6qsabrelite/mx6qsabrelite.c;h=f010d0c60d25734d2b81579b6d2806d365a415e6;hb=HEAD#l456
Also, are you absolutely sure that the __raw_* accessors are the right
thing to use here? Are you really sure no memory barriers etc. are
needed here?
Good catch. readb() would be more appropriate, though this particular
register is unlikely to produce a different value.
Regards,
Eric
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPI question
On Tue, Feb 19, 2013 at 5:12 PM, NeonJohn wrote: > Hello, > > Veteran developer, new to Linux internals. I'm working with the > BeagleBone and need three SPI ports. I'm now working to enable the > second chip select on the second port. I need some basic information to > get started. > > Is the port initialization done in u-boot or in the kernel? I haven't yet used the Beagle Bone (though I have one on my desk), but I have used SPI on a Blackfin target with U-Boot and Linux. On that target, the Blackfin's built-in first-stage bootloader uses SPI to load U-Boot into memory from flash and runs it. U-Boot then reads the Linux kernel image into RAM from the SPI flash and boots it. Those things probably don't apply in your case, unless your flash uses an SPI interface. Then everything else SPI related is done in Linux. Specifically there is a "board" file where the peripherals are set up. On my target there is both a hardware-assisted SPI bus with several attached chips and a "bitbanged" SPI bus. Those buses (including the pin assignments) are set up in the board file and the peripherals are attached to the buses and assigned chip select pins. I don't know if those things are handled the same way for the Beagle Bone or not; I use a custom Linux distribution for Blackfin that may work differently. This is straying off topic for the U-Boot list, but if you want more info about how it works on my target, email me directly. Steve -- Steve Strobel Link Communications, Inc. 1035 Cerise Rd Billings, MT 59101-7378 (406) 245-5002 ext 102 (406) 245-4889 (fax) WWW: http://www.link-comm.com MailTo:steve.stro...@link-comm.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 16/21] hash: Add a flag to support saving hashes in the environment
Some hashing commands permit saving the hash in an environment variable,
and verifying a hash from there. But the crc32 command does not support
this. In order to permit crc32 to use the generic hashing infrastructure,
add a flag to select which behaviour to use.
Signed-off-by: Simon Glass
---
Changes in v2:
- Add new patch to control saving hashes in the environment
common/cmd_hash.c| 8 +++---
common/cmd_sha1sum.c | 6 ++---
common/hash.c| 69 +++-
include/hash.h | 9 +--
4 files changed, 66 insertions(+), 26 deletions(-)
diff --git a/common/cmd_hash.c b/common/cmd_hash.c
index eb6a338..8c03b5c 100644
--- a/common/cmd_hash.c
+++ b/common/cmd_hash.c
@@ -30,22 +30,22 @@
static int do_hash(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
{
#ifdef CONFIG_HASH_VERIFY
- int verify = 0;
+ int flags = HASH_FLAG_ENV;
if (argc < 4)
return CMD_RET_USAGE;
if (!strcmp(argv[1], "-v")) {
- verify = 1;
+ flags |= HASH_FLAG_VERIFY;
argc--;
argv++;
}
#else
- const int verify = 0;
+ const int flags = HASH_FLAG_ENV;
#endif
/* Move forward to 'algorithm' parameter */
argc--;
argv++;
- return hash_command(*argv, verify, cmdtp, flag, argc - 1, argv + 1);
+ return hash_command(*argv, flags, cmdtp, flag, argc - 1, argv + 1);
}
#ifdef CONFIG_HASH_VERIFY
diff --git a/common/cmd_sha1sum.c b/common/cmd_sha1sum.c
index fe927ab..9f08629 100644
--- a/common/cmd_sha1sum.c
+++ b/common/cmd_sha1sum.c
@@ -31,7 +31,7 @@
int do_sha1sum(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
{
- int verify = 0;
+ int flags = HASH_FLAG_ENV;
int ac;
char * const *av;
@@ -42,13 +42,13 @@ int do_sha1sum(cmd_tbl_t *cmdtp, int flag, int argc, char *
const argv[])
ac = argc - 1;
#ifdef CONFIG_SHA1SUM_VERIFY
if (strcmp(*av, "-v") == 0) {
- verify = 1;
+ flags |= HASH_FLAG_VERIFY;
av++;
ac--;
}
#endif
- return hash_command("sha1", verify, cmdtp, flag, ac, av);
+ return hash_command("sha1", flags, cmdtp, flag, ac, av);
}
#ifdef CONFIG_SHA1SUM_VERIFY
diff --git a/common/hash.c b/common/hash.c
index e3a6e43..021c4d9 100644
--- a/common/hash.c
+++ b/common/hash.c
@@ -58,19 +58,31 @@ static struct hash_algo hash_algo[] = {
* @algo: Hash algorithm being used
* @sum: Hash digest (algo->digest_size bytes)
* @dest: Destination, interpreted as a hex address if it starts
- * with * or otherwise as an environment variable.
+ * with * (or allow_env_vars is 0) or otherwise as an
+ * environment variable.
+ * @allow_env_vars:non-zero to permit storing the result to an
+ * variable environment
*/
static void store_result(struct hash_algo *algo, const u8 *sum,
-const char *dest)
+const char *dest, int allow_env_vars)
{
unsigned int i;
+ int env_var = 0;
- if (*dest == '*') {
- u8 *ptr;
+ /*
+* If environment variables are allowed, then we assume that 'dest'
+* is an environment variable, unless it starts with *, in which
+* case we assume it is an address. If not allowed, it ia always an
+* address. This is to support the crc32 command.
+*/
+ if (allow_env_vars) {
+ if (*dest == '*')
+ dest++;
+ else
+ env_var = 1;
+ }
- ptr = (u8 *)simple_strtoul(dest + 1, NULL, 16);
- memcpy(ptr, sum, algo->digest_size);
- } else {
+ if (env_var) {
char str_output[HASH_MAX_DIGEST_SIZE * 2 + 1];
char *str_ptr = str_output;
@@ -80,6 +92,11 @@ static void store_result(struct hash_algo *algo, const u8
*sum,
}
str_ptr = '\0';
setenv(dest, str_output);
+ } else {
+ u8 *ptr;
+
+ ptr = (u8 *)simple_strtoul(dest, NULL, 16);
+ memcpy(ptr, sum, algo->digest_size);
}
}
@@ -94,14 +111,28 @@ static void store_result(struct hash_algo *algo, const u8
*sum,
* Otherwise we assume it is an environment variable, and
* look up its value (it must contain a hex digest).
* @vsum: Returns binary digest value (algo->digest_size bytes)
+ * @allow_env_vars:non-zero to permit storing the result to an environment
+ * variable. If 0 then verify_str is assumed to be an
+ * address, and the * prefix is not expected.
* @return 0 if ok, non-zero on error
*/
-static int parse_verify_sum(struct has
[U-Boot] [PATCH v2 21/21] sandbox: Allow hash functions to work correctly
Use map_sysmem() so that hashing is possible on sandbox.
Signed-off-by: Simon Glass
---
Changes in v2:
- Rebase on top of earlier patches
common/hash.c | 24
1 file changed, 16 insertions(+), 8 deletions(-)
diff --git a/common/hash.c b/common/hash.c
index 984cbe4..1c33ef7 100644
--- a/common/hash.c
+++ b/common/hash.c
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
/*
* These are the hash algorithms we support. Chips which support accelerated
@@ -112,10 +113,13 @@ static void store_result(struct hash_algo *algo, const u8
*sum,
str_ptr = '\0';
setenv(dest, str_output);
} else {
- u8 *ptr;
+ ulong addr;
+ void *buf;
- ptr = (u8 *)simple_strtoul(dest, NULL, 16);
- memcpy(ptr, sum, algo->digest_size);
+ addr = simple_strtoul(dest, NULL, 16);
+ buf = map_sysmem(addr, algo->digest_size);
+ memcpy(buf, sum, algo->digest_size);
+ unmap_sysmem(buf);
}
}
@@ -149,10 +153,12 @@ static int parse_verify_sum(struct hash_algo *algo, char
*verify_str, u8 *vsum,
}
if (env_var) {
- u8 *ptr;
+ ulong addr;
+ void *buf;
- ptr = (u8 *)simple_strtoul(verify_str, NULL, 16);
- memcpy(vsum, ptr, algo->digest_size);
+ addr = simple_strtoul(verify_str, NULL, 16);
+ buf = map_sysmem(addr, algo->digest_size);
+ memcpy(vsum, buf, algo->digest_size);
} else {
unsigned int i;
char *vsum_str;
@@ -223,6 +229,7 @@ int hash_command(const char *algo_name, int flags,
cmd_tbl_t *cmdtp, int flag,
struct hash_algo *algo;
u8 output[HASH_MAX_DIGEST_SIZE];
u8 vsum[HASH_MAX_DIGEST_SIZE];
+ void *buf;
algo = find_hash_algo(algo_name);
if (!algo) {
@@ -236,8 +243,9 @@ int hash_command(const char *algo_name, int flags,
cmd_tbl_t *cmdtp, int flag,
return 1;
}
- algo->hash_func_ws((const unsigned char *)addr, len, output,
- algo->chunk_size);
+ buf = map_sysmem(addr, len);
+ algo->hash_func_ws(buf, len, output, algo->chunk_size);
+ unmap_sysmem(buf);
/* Try to avoid code bloat when verify is not needed */
#ifdef CONFIG_HASH_VERIFY
--
1.8.1.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] imx6, spl and falcon boot
On 02/19/2013 02:26 PM, Alexandre Belloni wrote: Hi Eric, On Tue, Feb 19, 2013 at 09:33:58AM -0700, Eric Nelson wrote : Whoosh seems pretty compelling with such a small code base. Does it really boot faster though? Do you have any numbers for TTP (Time-to-penguin) on a SABRE Lite or SABRE SD? I don't exactly have that number but I believe you can go under 100ms. If you have a look at my presentation at ELCE [1] or that video on youtube [2], we basically are able too boot an start an openGL application under 600ms from reset. But that is a lot of self advertising, we can continue to discuss that off the ML if you want. [1] http://www.elinux.org/images/d/d1/Alexandre_Belloni_boottime_optimizations.pdf [2] https://www.youtube.com/watch?v=KPU4_QVPFZ0 Self advertisement or not, this is cool. Great job Alexandre! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 16/20] Roll crc32 into hash infrastructure
Hi Tom, On Mon, Feb 18, 2013 at 2:45 PM, Tom Rini wrote: > On Mon, Feb 18, 2013 at 09:06:01AM -0800, Simon Glass wrote: >> Hi Wolfgang, >> >> On Mon, Feb 18, 2013 at 3:35 AM, Wolfgang Denk wrote: >> > Dear Tom, >> > >> > In message <51216721.1010...@ti.com> you wrote: >> >> >> >> There's another thread I don't have yet (and I don't have this one in >> >> gmail yet even). But, I am OK with custodians using their repos, but >> >> not the master branch, for unrelated but otherwise good patches. I'm >> >> also fine with patchwork bundles. I suppose we could use the staging >> >> repository for these changes instead. >> > >> > What I mostly object about there is that these patches would go into >> > mainline basicly unreviewed, as patch submission and pull request is >> > all done from a single person, with no other feedback on the patches >> > at all. And this affects a lot of common code... >> > >> > Actually, I see this change when pulling u-boot-x86.git/master: >> > >> > -> bloat-o-meter u-boot-before u-boot >> >> What board is this please? >> >> Some specific notes here - I think it boils down to moving crc32 into >> the hash framework. This adds some overhead, but has a few benefits. > > So you're going to v2 this part? I have just sent 3 v2 patches to the mailing list. There is a new patch 16 to be inserted before this patch, an updated version of this patch, and an updated version of the final patch in the series (which was number 20 and is now number 21). I have ended up just using #ifdef to remove most of the hash code if only crc32 is in use. It's not particularly elegant but I was not able to significantly reduce the code size impact any other way. Please take a look at it and see what you think. Just in case it is useful, I have pushed a new 'us-mem3' branch to x86, but this is not for pulling (it has not been through patchwork), just for testing / comparison. I will be away until Monday so probably no further response from me until then. Regards, Simon > > -- > Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 17/21] Roll crc32 into hash infrastructure
Add the CRC32 algorithm to the list of available hashes, and make
the crc32 command use hash_command(). Add a new crc32_wd_buf() to
make this possible, which puts its result in a buffer rather than
returning it as a 32-bit value.
Note: For some boards the hash command is not enabled, neither
are sha1, sha256 or the verify option. In this case the full
hash implementation adds about 500 bytes of overhead. So as a
special case, we use #ifdef to select very simple bahviour in
that case. The justification for this is that it is currently
a very common case (virtually all boards enable crc32 but only
some enable more advanced features).
Signed-off-by: Simon Glass
---
Changes in v2:
- Rewrite crc32 support in hash to improve code size
common/cmd_mem.c | 75 --
common/hash.c| 111 ++-
include/hash.h | 2 +-
include/u-boot/crc.h | 11 +
lib/crc32.c | 9 +
5 files changed, 102 insertions(+), 106 deletions(-)
diff --git a/common/cmd_mem.c b/common/cmd_mem.c
index f67cd15..150a428 100644
--- a/common/cmd_mem.c
+++ b/common/cmd_mem.c
@@ -32,6 +32,7 @@
#ifdef CONFIG_HAS_DATAFLASH
#include
#endif
+#include
#include
#include
#include
@@ -1096,89 +1097,27 @@ mod_mem(cmd_tbl_t *cmdtp, int incrflag, int flag, int
argc, char * const argv[])
#ifdef CONFIG_CMD_CRC32
-#ifndef CONFIG_CRC32_VERIFY
-
static int do_mem_crc(cmd_tbl_t *cmdtp, int flag, int argc, char * const
argv[])
{
- ulong addr, length;
- ulong crc;
- ulong *ptr;
-
- if (argc < 3)
- return CMD_RET_USAGE;
-
- addr = simple_strtoul (argv[1], NULL, 16);
- addr += base_address;
-
- length = simple_strtoul (argv[2], NULL, 16);
-
- crc = crc32_wd (0, (const uchar *) addr, length, CHUNKSZ_CRC32);
-
- printf ("CRC32 for %08lx ... %08lx ==> %08lx\n",
- addr, addr + length - 1, crc);
-
- if (argc > 3) {
- ptr = (ulong *) simple_strtoul (argv[3], NULL, 16);
- *ptr = crc;
- }
-
- return 0;
-}
-
-#else /* CONFIG_CRC32_VERIFY */
-
-int do_mem_crc (cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
-{
- ulong addr, length;
- ulong crc;
- ulong *ptr;
- ulong vcrc;
- int verify;
+ int flags = 0;
int ac;
char * const *av;
- if (argc < 3) {
-usage:
+ if (argc < 3)
return CMD_RET_USAGE;
- }
av = argv + 1;
ac = argc - 1;
+#ifdef CONFIG_HASH_VERIFY
if (strcmp(*av, "-v") == 0) {
- verify = 1;
+ flags |= HASH_FLAG_VERIFY;
av++;
ac--;
- if (ac < 3)
- goto usage;
- } else
- verify = 0;
-
- addr = simple_strtoul(*av++, NULL, 16);
- addr += base_address;
- length = simple_strtoul(*av++, NULL, 16);
-
- crc = crc32_wd (0, (const uchar *) addr, length, CHUNKSZ_CRC32);
-
- if (!verify) {
- printf ("CRC32 for %08lx ... %08lx ==> %08lx\n",
- addr, addr + length - 1, crc);
- if (ac > 2) {
- ptr = (ulong *) simple_strtoul (*av++, NULL, 16);
- *ptr = crc;
- }
- } else {
- vcrc = simple_strtoul(*av++, NULL, 16);
- if (vcrc != crc) {
- printf ("CRC32 for %08lx ... %08lx ==> %08lx != %08lx
** ERROR **\n",
- addr, addr + length - 1, crc, vcrc);
- return 1;
- }
}
+#endif
- return 0;
-
+ return hash_command("crc32", flags, cmdtp, flag, ac, av);
}
-#endif /* CONFIG_CRC32_VERIFY */
#endif
diff --git a/common/hash.c b/common/hash.c
index 021c4d9..984cbe4 100644
--- a/common/hash.c
+++ b/common/hash.c
@@ -41,6 +41,7 @@ static struct hash_algo hash_algo[] = {
sha1_csum_wd,
CHUNKSZ_SHA1,
},
+#define MULTI_HASH
#endif
#ifdef CONFIG_SHA256
{
@@ -49,9 +50,27 @@ static struct hash_algo hash_algo[] = {
sha256_csum_wd,
CHUNKSZ_SHA256,
},
+#define MULTI_HASH
#endif
+ {
+ "CRC32",
+ 4,
+ crc32_wd_buf,
+ CHUNKSZ_CRC32,
+ },
};
+#if defined(CONFIG_HASH_VERIFY) || defined(CONFIG_CMD_HASH)
+#define MULTI_HASH
+#endif
+
+/* Try to minimize code size for boards that don't want much hashing */
+#ifdef MULTI_HASH
+#define multi_hash() 1
+#else
+#define multi_hash() 0
+#endif
+
/**
* store_result: Store the resulting sum to an address or variable
*
@@ -192,10 +211,7 @@ static void show_hash(struct hash_algo *algo, ulong addr,
ulong len,
int hash_command(const char *algo_name, int flags, cmd_tbl_t *cmdtp, int flag,
int argc, char *
Re: [U-Boot] M29EW flash is detected as 0xFF
Hi Stefan, On Wed, Feb 20, 2013 at 7:27 PM, Stefan Roese wrote: > On 18.02.2013 10:57, Jagan Teki wrote: >> I have a 16MB, M29EW flash on target boards. >> >> I got the below info, while probing the flash. >> >> Bank # 1: CFI conformant flash (8 x 8) Size: 64 MB in 512 Sectors >> AMD Standard command set, Manufacturer ID: 0xFF, Device ID: 0xFF >> Erase timeout: 4096 ms, write timeout: 2 ms >> Buffer write timeout: 5 ms, buffer size: 1024 bytes >> >> Since the Manu.ID of this flash is 0x89, it got detected as 0xFF. >> >> Does u-boot code have a support for M29EW flash..? > > I'm pretty sure, yes. Which U-Boot version are you using? Most likely > its an older version. Your problem reminds me about this commit: > > Author: Philippe De Muyter 2010-08-10 16:54:52 > Committer: Stefan Roese 2010-08-18 09:09:00 > Parent: 2e97394a6d07a36dfc139b7b98b12e452b5bd8dc (cfi_flash: flinfo: > allow user interrupt in flash print info fn) > Child: 70084df7125a0b67de707b82ec67adfdc35c (cfi_flash: Cleanup > flash_print_info()) > Branches: many (98) > Follows: v2010.06 > Precedes: v2010.09-rc1 > > Fix printing & reading of 16-bit CFI device identifiers > > Fix reading and printing of CFI flashes 16-bit devices identifiers > > Nowadays CFI flashes have a 16-bit device identifier. U-boot still > print them and read them as if they were only 8-bit wide. Fix that. > Before: > Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x1B > After: > Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x881B > > So please update to the latest version and try again. Sorry for not intimating the version I used, actually I am using the latest u-boot version 2013.01.01 Below link the head commit for cfi_flash.c http://git.denx.de/?p=u-boot.git;a=commit;h=d2af028db3f75390f56f018e16c0f269521e07c5 I am not sure whats wrong with code for detecting the m/c ID. Please let me know your inputs. Thanks, Jagan. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] M29EW flash is detected as 0xFF
On Wed, Feb 20, 2013 at 10:55 PM, Jagan Teki wrote: > Hi Stefan, > > On Wed, Feb 20, 2013 at 7:27 PM, Stefan Roese wrote: >> On 18.02.2013 10:57, Jagan Teki wrote: >>> I have a 16MB, M29EW flash on target boards. >>> >>> I got the below info, while probing the flash. >>> >>> Bank # 1: CFI conformant flash (8 x 8) Size: 64 MB in 512 Sectors >>> AMD Standard command set, Manufacturer ID: 0xFF, Device ID: 0xFF >>> Erase timeout: 4096 ms, write timeout: 2 ms >>> Buffer write timeout: 5 ms, buffer size: 1024 bytes >>> >>> Since the Manu.ID of this flash is 0x89, it got detected as 0xFF. >>> >>> Does u-boot code have a support for M29EW flash..? >> >> I'm pretty sure, yes. Which U-Boot version are you using? Most likely >> its an older version. Your problem reminds me about this commit: >> >> Author: Philippe De Muyter 2010-08-10 16:54:52 >> Committer: Stefan Roese 2010-08-18 09:09:00 >> Parent: 2e97394a6d07a36dfc139b7b98b12e452b5bd8dc (cfi_flash: flinfo: >> allow user interrupt in flash print info fn) >> Child: 70084df7125a0b67de707b82ec67adfdc35c (cfi_flash: Cleanup >> flash_print_info()) >> Branches: many (98) >> Follows: v2010.06 >> Precedes: v2010.09-rc1 >> >> Fix printing & reading of 16-bit CFI device identifiers >> >> Fix reading and printing of CFI flashes 16-bit devices identifiers >> >> Nowadays CFI flashes have a 16-bit device identifier. U-boot still >> print them and read them as if they were only 8-bit wide. Fix that. >> Before: >> Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x1B >> After: >> Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x881B >> >> So please update to the latest version and try again. > > Sorry for not intimating the version I used, actually I am using the > latest u-boot version 2013.01.01 > Below link the head commit for cfi_flash.c > http://git.denx.de/?p=u-boot.git;a=commit;h=d2af028db3f75390f56f018e16c0f269521e07c5 > > I am not sure whats wrong with code for detecting the m/c ID. > > Please let me know your inputs. > > Thanks, > Jagan. For your information, I am using below configs for my nor setup. #define CONFIG_SYS_FLASH_BASE 0xE200 # define CONFIG_SYS_FLASH_SIZE (16 * 1024 * 1024) # define CONFIG_SYS_MAX_FLASH_BANKS 1 # define CONFIG_SYS_MAX_FLASH_SECT 512 # define CONFIG_SYS_FLASH_ERASE_TOUT 1000 # define CONFIG_SYS_FLASH_WRITE_TOUT 5000 # define CONFIG_FLASH_SHOW_PROGRESS 10 # define CONFIG_SYS_FLASH_CFI # undef CONFIG_SYS_FLASH_EMPTY_INFO # define CONFIG_FLASH_CFI_DRIVER # undef CONFIG_SYS_FLASH_PROTECTION /* don't use hardware protection */ # define CONFIG_SYS_FLASH_USE_BUFFER_WRITE /* use buffered writes (20x faster) */ Please let me know, if am wrong with any settings.. Thanks, Jagan. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/3] Tegra: fdt: Add/enhance sdhci (mmc) nodes for all T20 DT files
Lucas/Stephen/etc. On Fri, Feb 15, 2013 at 4:58 AM, Lucas Stach wrote: > Am Donnerstag, den 14.02.2013, 13:24 -0700 schrieb Stephen Warren: > [...] >> >> >> >> The one issue with this is that only newer versions of dtc support the >> >> -i option. The version packaged with most distros won't support it. >> >> That'll mean something like "MAKEALL -a arm" is going to fail for a lot >> >> of people without some kind of explicit action (i.e. manually installing >> >> a newer version of dtc). >> >> >> >> That's why I suggested switching from /include/ to #include, and adding >> >> the include path to the cpp command rather than dtc. >> > >> > I tried using '#include, and added the 2 dts paths to the DTS_CPPFLAGS >> > so gcc could find the files, but I got a 'couldn't open >> > 'skeleton.dtsi' error. I didn't want to change tegra20.dtsi to >> > #include "skeleton.dtsi', and all the other board dts files to >> > #include ARCH_CPU_DTS, just so we can support the common tamonten >> > dtsi, so I went back to the DTC include path changes. >> >> I think that's exactly where we should end up though. It's certainly the >> way the kernel is also heading. >> >> Right now, the Avionic Design boards might be the only place this >> problem crops up, but as we support more features on Cardhu, we'll hit >> exactly the same issue, so have to solve it there too. >> > Right now the AD boards might be the only ones with this problem, but it > will certainly hit the Toradex Tegra designs also. > > I'm planning on doing support for the Colibri Evaluation Carrier for the > next release cycle. So I need to split up the DTS between Colibri and > Carrier board, same as is done in the Linux Kernel dts. >> > There was talk at one time of putting an up-to-date DTC binary in the >> > U-Boot tools area so everyone would have a consistent level of DT >> > support. >> >> I think Wolfgang nak'd that. >> >> With the small number of boards using DT at this time, I >> > think we can live with letting people know where to find the latest >> > DTC release until then. >> >> But he also nak'd the idea of relying on a newer dtc:-( >> >> I think we had better raise the question again. > > Yes, this has to be resolved one way or the other. > > OK, I'll change all of the Tegra .DTS an .DTSI files to use #include "xyz", and put the include path in the DTS_CPPFLAGS in dts/Makefile instead of adding the include path to the DTC tool. This'll be in v5 of the patchset. Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4] imls: Add support to list images in NAND device
On 02/19/2013 09:37:23 PM, Vipin Kumar wrote:
On 2/20/2013 6:45 AM, Scott Wood wrote:
On 12/17/2012 02:32:48 AM, Vipin Kumar wrote:
+#if defined(CONFIG_CMD_IMLS_NAND)
+static int nand_imls_legacyimage(nand_info_t *nand, int nand_dev,
loff_t off,
+ size_t len)
+{
+ void *imgdata;
+ int ret;
+
+ imgdata = malloc(len);
+ if (!imgdata) {
+ printf("May be a Legacy Image at NAND device %d offset
%08llX:\n",
+ nand_dev, off);
+ printf(" Low memory(cannot allocate memory for
image)\n");
+ return -ENOMEM;
+ }
So, it looks like any reasonably-sized kernel image is going to hit
this out-of-memory condition given how unreasonably small U-Boot
malloc
heaps generally are.
Yes, that's right. And it is a pity
I think I'll apply this anyway, as it is still helpful, but a future
enhancement could be to do a streaming read of the image to verify the
CRC.
As a side note, running this showed U-Boot itself as "may be a legacy
image"... it seems that for some reason all the ppc arches start with
the uImage header, but otherwise aren't valid uImages.
This "may be a legacy image" print is when we have successfully
copied and validated the 64 byte mkimage header and are not able to
allocate the memory from heap for the image data. What it means is
that although the whole image might be a good "Legacy image" but we
can not guarantee because we have not yet validated the dcrc.
Thats why this print "May be a legacy image"
Sure, that comment was meant as "hmm, powerpc is doing something weird"
rather than anything wrong with this patch.
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] M29EW flash is detected as 0xFF
Hi Jagan, On 20.02.2013 18:25, Jagan Teki wrote: >> So please update to the latest version and try again. > > Sorry for not intimating the version I used, actually I am using the > latest u-boot version 2013.01.01 > Below link the head commit for cfi_flash.c > http://git.denx.de/?p=u-boot.git;a=commit;h=d2af028db3f75390f56f018e16c0f269521e07c5 > > I am not sure whats wrong with code for detecting the m/c ID. > > Please let me know your inputs. This reminds me of a still pending problem with 8-bit flash chips. Could you perhaps give this patch a try? http://patchwork.ozlabs.org/patch/140863/ Not sure if it still applies clean. But it seemed to fix a problem with 8-bit bus flash chips. Thanks, Stefan -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: off...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] MMC - Error detected in status(0x208100)!
Hi Rommel, On Thu, Jan 31, 2013 at 8:14 AM, Rommel Custodio wrote: > Dear Jagannadha, > >>Jagannadha Sutradharudu Teki xilinx.com> > writes: > >> >> Hi Andy, >> >> The latest patch "mmc: Properly determine maximum supported bus width" >> (sha1: 7798f6dbd5e1a3030ed81a81da5dfb57c3307cac) is causing some error status > issue on >> zynq platform with MMC Plus cards. >> >> Here the out what I get with inclusion of this patch on u-boot tree. >> zynq-uboot> mmcinfo >> Error detected in status(0x208100)! >> Device: zynq_sdhci >> Manufacturer ID: 1e >> OEM: >> Name: MMC >> Tran Speed: 5200 >> Rd Block Len: 512 >> MMC version 4.0 >> High Capacity: No >> Capacity: 1.9 GiB >> Bus Width: 4-bit >> >> When I revert this path, I am unable to see the status error. >> zynq-uboot> mmcinfo >> Device: zynq_sdhci >> Manufacturer ID: 1e >> OEM: >> Name: MMC >> Tran Speed: 5200 >> Rd Block Len: 512 >> MMC version 4.0 >> High Capacity: No >> Capacity: 1.9 GiB >> Bus Width: 12-bit >> >> I think the above one is also a buggy as my controller is unable to support > 12-bit bus width.? >> > > I've been using the latest u-boot (v2013.01) on ML507 with a custom SDHCI IP. > No > problems detected with this patch. > > The output of both patched and unpatched u-boot seems to be correct. Except > for > the Data CRC Error (bit 21) in the patched version. > > Several things to check: > > 1) Verify the controller settings on both patched and unpatched u-boot. The > printf()s are just prints some IPs (like the one I'm using) don't allow > changing > the register value on some conditions (ie during CMD_INHIBIT and/or > DAT_INHIBIT). This would make the printf()s look correct but the actual > register > value is incorrect. > > 2) Try lowering your SDCLK (ie 25Mhz High-speed mode). > > 3) Try disabling High-speed mode (which limits you to 25MHz Legacy mode). I tried by minimizing the clock to 25Mhz as an argument of add_sdhci(). but still I am getting the similar issue. Please let me know your inputs. Thanks, Jagan. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 1/4] fdt: Add dts/dtsi arch & board include paths to DTS_CPPFLAGS
This allows the use of '#include "xyz"' in the dts/dtsi file which helps the C preprocessor find common dtsi include files. Signed-off-by: Tom Warren --- v4: new v5: Add dts/dtsi paths to DTS_CPPFLAGS instead of DTC command line dts/Makefile |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/dts/Makefile b/dts/Makefile index 922c78c..6f36153 100644 --- a/dts/Makefile +++ b/dts/Makefile @@ -38,7 +38,8 @@ Please define CONFIG_ARCH_DEVICE_TREE)) # We preprocess the device tree file provide a useful define DTS_CPPFLAGS := -x assembler-with-cpp \ -DARCH_CPU_DTS=\"$(SRCTREE)/arch/$(ARCH)/dts/$(CONFIG_ARCH_DEVICE_TREE).dtsi\" \ - -DBOARD_DTS=\"$(SRCTREE)/board/$(VENDOR)/$(BOARD)/dts/$(DEVICE_TREE).dts\" + -DBOARD_DTS=\"$(SRCTREE)/board/$(VENDOR)/$(BOARD)/dts/$(DEVICE_TREE).dts\" \ + -I$(SRCTREE)/board/$(VENDOR)/dts -I$(SRCTREE)/arch/$(ARCH)/dts all: $(obj).depend $(LIB) -- 1.7.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 0/4] Tegra: MMC: Add DT support for MMC to T20 boards
This patchset adds device-tree support to the Tegra MMC driver. All device config is done via properties in the DT files instead of hard-coded config options/function arguments. I've tested this on my Seaboard and everything works fine, including card detect. For the other T20 boards, I've used the Linux kernel DTS files for the sdhci nodes where there wasn't one already, or expanded the info that was already there. Everything builds fine, but I haven't tested anything but Seaboard. v2: Changes as per Stephen's & Simon's review v3: Changes as per Stephen/Lucas/Thierry/Simon's feedback v4: Additional changes as per Stephen/Lucas/Thierry/Simon v5: Additional changes as per Stephen/Lucas/Andy Tom Warren (4): fdt: add dts/dtsi arch & board include paths to DTS_CPPFLAGS Tegra: fdt: tamonten: Add common tamonten.dtsi file from linux Tegra: fdt: Add/enhance sdhci (mmc) nodes for all T20 DT files Tegra: MMC: Add DT support to MMC driver for all T20 boards arch/arm/dts/tegra114.dtsi|2 +- arch/arm/dts/tegra20.dtsi | 18 +- arch/arm/dts/tegra30.dtsi |2 +- arch/arm/include/asm/arch-tegra/mmc.h |2 +- arch/arm/include/asm/arch-tegra/tegra_mmc.h | 13 +- board/avionic-design/common/tamonten.c| 19 +- board/avionic-design/dts/tegra20-medcom-wide.dts |3 +- board/avionic-design/dts/tegra20-plutux.dts |3 +- board/avionic-design/dts/tegra20-tamonten.dtsi| 489 + board/avionic-design/dts/tegra20-tec.dts |3 +- board/compal/dts/tegra20-paz00.dts| 21 +- board/compal/paz00/paz00.c| 26 +- board/compulab/dts/tegra20-trimslice.dts | 16 +- board/compulab/trimslice/trimslice.c | 23 +- board/nvidia/common/board.c | 25 + board/nvidia/dts/tegra114-dalmore.dts |2 +- board/nvidia/dts/tegra20-harmony.dts | 20 +- board/nvidia/dts/tegra20-seaboard.dts | 12 +- board/nvidia/dts/tegra20-ventana.dts | 17 +- board/nvidia/dts/tegra20-whistler.dts | 15 +- board/nvidia/dts/tegra30-cardhu.dts |2 +- board/nvidia/harmony/harmony.c| 26 +- board/nvidia/seaboard/seaboard.c | 25 +- board/nvidia/whistler/whistler.c | 30 +- board/toradex/colibri_t20_iris/colibri_t20_iris.c | 11 +- board/toradex/dts/tegra20-colibri_t20_iris.dts|9 +- drivers/mmc/tegra_mmc.c | 179 +--- dts/Makefile |3 +- include/fdtdec.h |1 + lib/fdtdec.c |1 + 30 files changed, 785 insertions(+), 233 deletions(-) create mode 100644 board/avionic-design/dts/tegra20-tamonten.dtsi ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 2/4] Tegra: fdt: tamonten: Add common tamonten.dtsi file from linux
Tamonten boards (medcom-wide, plutux, and tec) use a different/new
dtsi file w/common settings.
Signed-off-by: Tom Warren
Acked-by: Thierry Reding
---
v3: new
v4: no change
v5: change /include/ to #include
board/avionic-design/dts/tegra20-tamonten.dtsi | 489
1 files changed, 489 insertions(+), 0 deletions(-)
create mode 100644 board/avionic-design/dts/tegra20-tamonten.dtsi
diff --git a/board/avionic-design/dts/tegra20-tamonten.dtsi
b/board/avionic-design/dts/tegra20-tamonten.dtsi
new file mode 100644
index 000..073ac04
--- /dev/null
+++ b/board/avionic-design/dts/tegra20-tamonten.dtsi
@@ -0,0 +1,489 @@
+#include ARCH_CPU_DTS
+
+/ {
+ model = "Avionic Design Tamonten SOM";
+ compatible = "ad,tamonten", "nvidia,tegra20";
+
+ memory {
+ reg = <0x 0x2000>;
+ };
+
+ host1x {
+ hdmi {
+ vdd-supply = <&hdmi_vdd_reg>;
+ pll-supply = <&hdmi_pll_reg>;
+
+ nvidia,ddc-i2c-bus = <&hdmi_ddc>;
+ nvidia,hpd-gpio = <&gpio 111 0>; /* PN7 */
+ };
+ };
+
+ pinmux {
+ pinctrl-names = "default";
+ pinctrl-0 = <&state_default>;
+
+ state_default: pinmux {
+ ata {
+ nvidia,pins = "ata";
+ nvidia,function = "ide";
+ };
+ atb {
+ nvidia,pins = "atb", "gma", "gme";
+ nvidia,function = "sdio4";
+ };
+ atc {
+ nvidia,pins = "atc";
+ nvidia,function = "nand";
+ };
+ atd {
+ nvidia,pins = "atd", "ate", "gmb", "gmd", "gpu",
+ "spia", "spib", "spic";
+ nvidia,function = "gmi";
+ };
+ cdev1 {
+ nvidia,pins = "cdev1";
+ nvidia,function = "plla_out";
+ };
+ cdev2 {
+ nvidia,pins = "cdev2";
+ nvidia,function = "pllp_out4";
+ };
+ crtp {
+ nvidia,pins = "crtp";
+ nvidia,function = "crt";
+ };
+ csus {
+ nvidia,pins = "csus";
+ nvidia,function = "vi_sensor_clk";
+ };
+ dap1 {
+ nvidia,pins = "dap1";
+ nvidia,function = "dap1";
+ };
+ dap2 {
+ nvidia,pins = "dap2";
+ nvidia,function = "dap2";
+ };
+ dap3 {
+ nvidia,pins = "dap3";
+ nvidia,function = "dap3";
+ };
+ dap4 {
+ nvidia,pins = "dap4";
+ nvidia,function = "dap4";
+ };
+ dta {
+ nvidia,pins = "dta", "dtd";
+ nvidia,function = "sdio2";
+ };
+ dtb {
+ nvidia,pins = "dtb", "dtc", "dte";
+ nvidia,function = "rsvd1";
+ };
+ dtf {
+ nvidia,pins = "dtf";
+ nvidia,function = "i2c3";
+ };
+ gmc {
+ nvidia,pins = "gmc";
+ nvidia,function = "uartd";
+ };
+ gpu7 {
+ nvidia,pins = "gpu7";
+ nvidia,function = "rtck";
+ };
+ gpv {
+ nvidia,pins = "gpv", "slxa", "slxk";
+ nvidia,function = "pcie";
+ };
+ hdint {
+ nvidia,pins = "hdint";
+ nvidia,function = "hdmi";
+ };
+ i2cp {
+ nvidia,pins = "i2cp";
+ nvidia,function = "i2cp";
+ };
+ irrx {
+ nvidia,pins = "irrx", "irtx";
+ nvidia,fun
[U-Boot] [PATCH v5 3/4] Tegra: fdt: Add/enhance sdhci (mmc) nodes for all T20 DT files
Linux dts files were used for those boards that didn't already
have sdhci info populated. Tamonten has their own dtsi file with
common sdhci nodes (sourced from Linux).
Signed-off-by: Tom Warren
Tested-by: Thierry Reding
---
v2:
- cleanup comments in dts files/match w/kernel files
- add sdhci aliases in all dts files
- use tegra20-tamonten.dtsi from the kernel for AD boards
v3:
- include tamonten.dtsi file directly in AD dts files
- fix Seaboard power-gpios flags
- add cd-gpios for Colibri T20 Iris
- add include paths to DTC command
v4:
- move dts Makefile change to separate patch
v5:
- change /include/ to #include, allows C preprocessor to find files
arch/arm/dts/tegra114.dtsi |2 +-
arch/arm/dts/tegra20.dtsi| 18 +-
arch/arm/dts/tegra30.dtsi|2 +-
board/avionic-design/dts/tegra20-medcom-wide.dts |3 ++-
board/avionic-design/dts/tegra20-plutux.dts |3 ++-
board/avionic-design/dts/tegra20-tec.dts |3 ++-
board/compal/dts/tegra20-paz00.dts | 21 ++---
board/compulab/dts/tegra20-trimslice.dts | 16 +++-
board/nvidia/dts/tegra114-dalmore.dts|2 +-
board/nvidia/dts/tegra20-harmony.dts | 20 +++-
board/nvidia/dts/tegra20-seaboard.dts| 12
board/nvidia/dts/tegra20-ventana.dts | 17 -
board/nvidia/dts/tegra20-whistler.dts| 15 ++-
board/nvidia/dts/tegra30-cardhu.dts |2 +-
board/toradex/dts/tegra20-colibri_t20_iris.dts |9 -
15 files changed, 121 insertions(+), 24 deletions(-)
diff --git a/arch/arm/dts/tegra114.dtsi b/arch/arm/dts/tegra114.dtsi
index d06cd12..ee08962 100644
--- a/arch/arm/dts/tegra114.dtsi
+++ b/arch/arm/dts/tegra114.dtsi
@@ -1,4 +1,4 @@
-/include/ "skeleton.dtsi"
+#include "skeleton.dtsi"
/ {
compatible = "nvidia,tegra114";
diff --git a/arch/arm/dts/tegra20.dtsi b/arch/arm/dts/tegra20.dtsi
index 9a89685..3805750 100644
--- a/arch/arm/dts/tegra20.dtsi
+++ b/arch/arm/dts/tegra20.dtsi
@@ -1,4 +1,4 @@
-/include/ "skeleton.dtsi"
+#include "skeleton.dtsi"
/ {
compatible = "nvidia,tegra20";
@@ -318,24 +318,32 @@
sdhci@c800 {
compatible = "nvidia,tegra20-sdhci";
reg = <0xc800 0x200>;
- interrupts = < 46 >;
+ interrupts = <0 14 0x04>;
+ clocks = <&tegra_car 14>;
+ status = "disabled";
};
sdhci@c8000200 {
compatible = "nvidia,tegra20-sdhci";
reg = <0xc8000200 0x200>;
- interrupts = < 47 >;
+ interrupts = <0 15 0x04>;
+ clocks = <&tegra_car 9>;
+ status = "disabled";
};
sdhci@c8000400 {
compatible = "nvidia,tegra20-sdhci";
reg = <0xc8000400 0x200>;
- interrupts = < 51 >;
+ interrupts = <0 19 0x04>;
+ clocks = <&tegra_car 69>;
+ status = "disabled";
};
sdhci@c8000600 {
compatible = "nvidia,tegra20-sdhci";
reg = <0xc8000600 0x200>;
- interrupts = < 63 >;
+ interrupts = <0 31 0x04>;
+ clocks = <&tegra_car 15>;
+ status = "disabled";
};
};
diff --git a/arch/arm/dts/tegra30.dtsi b/arch/arm/dts/tegra30.dtsi
index 7b8126f..561c617 100644
--- a/arch/arm/dts/tegra30.dtsi
+++ b/arch/arm/dts/tegra30.dtsi
@@ -1,4 +1,4 @@
-/include/ "skeleton.dtsi"
+#include "skeleton.dtsi"
/ {
compatible = "nvidia,tegra30";
diff --git a/board/avionic-design/dts/tegra20-medcom-wide.dts
b/board/avionic-design/dts/tegra20-medcom-wide.dts
index e46afbe..a9a07f9 100644
--- a/board/avionic-design/dts/tegra20-medcom-wide.dts
+++ b/board/avionic-design/dts/tegra20-medcom-wide.dts
@@ -1,6 +1,6 @@
/dts-v1/;
-/include/ ARCH_CPU_DTS
+#include "tegra20-tamonten.dtsi"
/ {
model = "Avionic Design Medcom-Wide";
@@ -8,6 +8,7 @@
aliases {
usb0 = "/usb@c5008000";
+ sdhci0 = "/sdhci@c8000600";
};
memory {
diff --git a/board/avionic-design/dts/tegra20-plutux.dts
b/board/avionic-design/dts/tegra20-plutux.dts
index 3e6cce0..20016f2 100644
--- a/board/avionic-design/dts/tegra20-plutux.dts
+++ b/board/avionic-design/dts/tegra20-plutux.dts
@@ -1,6 +1,6 @@
/dts-v1/;
-/include/ ARCH_CPU_DTS
+#include "tegra20-tamonten.dtsi"
/ {
model = "Avionic Design Plutux";
@@ -8,6 +8,7 @@
aliases {
usb0 = "/usb@c5008000";
+ sdhci0 = "/sdhci@c8000600";
};
memory {
diff --git a/board/avionic-design/dts/tegra20-tec.dts
b/board/avionic-design/dts/tegra20-tec.dts
index bf3ff1d..1d7cf89 100644
--- a/board/avionic-design/dts/tegra20-tec.dts
+++ b/b
[U-Boot] [PATCH v5 4/4] Tegra: MMC: Add DT support to MMC driver for all T20 boards
tegra_mmc_init() now parses the DT info for bus width, WP/CD GPIOs, etc.
Tested on Seaboard, fully functional.
Tamonten boards (medcom-wide, plutux, and tec) use a different/new
dtsi file w/common settings.
Signed-off-by: Tom Warren
Signed-off-by: Thierry Reding
---
v2:
- all boards now call tegra_mmc_init once, w/no params
- count MMC controllers, not aliases
- AD boards (medcom/plutux/tec) use common tegra20-tamonten.dtsi
v3:
- move any power init inside board's pin_mux_mmc function, and/or
create pin_mux_mmc function if necessary.
- move board_mmc_init out of each board file and into ../common/board.c
v4:
- remove #ifdef CONFIG_TEGRA_MMC from trimslice.c
- fix minor whitespace issue in board/nvidia/common/board.c
- remove marking of used node_list entries in MMC driver, not needed
v5:
- restore previous debug statements, remove any new ones
- fix pwr_gpio/cd_gpio initialization in do_mmc_init
- update copyright to 2013
arch/arm/include/asm/arch-tegra/mmc.h |2 +-
arch/arm/include/asm/arch-tegra/tegra_mmc.h | 13 +-
board/avionic-design/common/tamonten.c| 19 +--
board/compal/paz00/paz00.c| 26 +---
board/compulab/trimslice/trimslice.c | 23 +---
board/nvidia/common/board.c | 25 +++
board/nvidia/harmony/harmony.c| 26 +---
board/nvidia/seaboard/seaboard.c | 25 +---
board/nvidia/whistler/whistler.c | 30 +---
board/toradex/colibri_t20_iris/colibri_t20_iris.c | 11 +-
drivers/mmc/tegra_mmc.c | 179 ++---
include/fdtdec.h |1 +
lib/fdtdec.c |1 +
13 files changed, 173 insertions(+), 208 deletions(-)
diff --git a/arch/arm/include/asm/arch-tegra/mmc.h
b/arch/arm/include/asm/arch-tegra/mmc.h
index 5c95047..71ad407 100644
--- a/arch/arm/include/asm/arch-tegra/mmc.h
+++ b/arch/arm/include/asm/arch-tegra/mmc.h
@@ -22,6 +22,6 @@
#ifndef _TEGRA_MMC_H_
#define _TEGRA_MMC_H_
-int tegra_mmc_init(int dev_index, int bus_width, int pwr_gpio, int cd_gpio);
+void tegra_mmc_init(void);
#endif /* _TEGRA_MMC_H_ */
diff --git a/arch/arm/include/asm/arch-tegra/tegra_mmc.h
b/arch/arm/include/asm/arch-tegra/tegra_mmc.h
index dd746ca..bd18f5f 100644
--- a/arch/arm/include/asm/arch-tegra/tegra_mmc.h
+++ b/arch/arm/include/asm/arch-tegra/tegra_mmc.h
@@ -27,6 +27,8 @@
#define TEGRA_SDMMC3_BASE 0xC8000400
#define TEGRA_SDMMC4_BASE 0xC8000600
+#define MAX_HOSTS 4 /* Max number of 'hosts'/controllers */
+
#ifndef __ASSEMBLY__
struct tegra_mmc {
unsigned intsysad; /* _SYSTEM_ADDRESS_0 */
@@ -119,12 +121,15 @@ struct tegra_mmc {
struct mmc_host {
struct tegra_mmc *reg;
+ int id; /* device id/number, 0-3 */
+ int enabled;/* 1 to enable, 0 to disable */
+ int width; /* Bus Width, 1, 4 or 8 */
+ enum periph_id mmc_id; /* Peripheral ID: PERIPH_ID_... */
+ struct fdt_gpio_state cd_gpio; /* Change Detect GPIO */
+ struct fdt_gpio_state pwr_gpio; /* Power GPIO */
+ struct fdt_gpio_state wp_gpio; /* Write Protect GPIO */
unsigned int version; /* SDHCI spec. version */
unsigned int clock; /* Current clock (MHz) */
- unsigned int base; /* Base address, SDMMC1/2/3/4 */
- enum periph_id mmc_id; /* Peripheral ID: PERIPH_ID_... */
- int pwr_gpio; /* Power GPIO */
- int cd_gpio;/* Change Detect GPIO */
};
#endif /* __ASSEMBLY__ */
diff --git a/board/avionic-design/common/tamonten.c
b/board/avionic-design/common/tamonten.c
index e6a932e..ea95e43 100644
--- a/board/avionic-design/common/tamonten.c
+++ b/board/avionic-design/common/tamonten.c
@@ -33,13 +33,8 @@
#include
#include
#include
-#include
#include
#include
-#ifdef CONFIG_TEGRA_MMC
-#include
-#endif
-
#ifdef CONFIG_BOARD_EARLY_INIT_F
void gpio_early_init(void)
@@ -54,7 +49,7 @@ void gpio_early_init(void)
* Routine: pin_mux_mmc
* Description: setup the pin muxes/tristate values for the SDMMC(s)
*/
-static void pin_mux_mmc(void)
+void pin_mux_mmc(void)
{
funcmux_select(PERIPH_ID_SDMMC4, FUNCMUX_SDMMC4_ATB_GMA_GME_8_BIT);
/* for write-protect GPIO PI6 */
@@ -62,16 +57,4 @@ static void pin_mux_mmc(void)
/* for CD GPIO PH2 */
pinmux_tristate_disable(PINGRP_ATD);
}
-
-/* this is a weak define that we are overriding */
-int board_mmc_init(bd_t *bd)
-{
- /* Enable muxes, etc. for SDMMC controllers */
- pin_mux_mmc();
-
- /* init dev 0, SD slot, with 4-bit bus */
- tegra_mmc_init(0, 4, GPIO_PI6, GPIO_PH2);
-
- return 0;
-}
#endif
diff --git a/board/compal/paz00/paz00.c b/board/compal/paz00/paz00.c
index 1447f47..d6e5c37 100644
--- a/board/compal/paz00/paz00.c
+++ b/board/
Re: [U-Boot] [PATCH 1/2] ARM: bootm: allow skipping fdt memory node fixup
> "Tom" == Tom Rini writes: Hi, Tom> It's not so simple. The first DTs I checked are the am335x ones Tom> and I see they hardcode to 256MB which isn't right, but no one has Tom> caught this since it's blindly fixed up. So as Wolfgang suggests Tom> next, we might need to go with replacing on 0x0 entries and Tom> warning when they don't match what U-Boot has detected. It is correct for the (classic) beaglebone. This also hits people using appended dtb unless they have CONFIG_ARM_ATAG_DTB_COMPAT enabled (which the probably do though). -- Bye, Peter Korsgaard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] ARM: bootm: allow skipping fdt memory node fixup
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/20/2013 04:55 PM, Peter Korsgaard wrote: >> "Tom" == Tom Rini writes: > > Hi, > > Tom> It's not so simple. The first DTs I checked are the am335x > ones Tom> and I see they hardcode to 256MB which isn't right, but > no one has Tom> caught this since it's blindly fixed up. So as > Wolfgang suggests Tom> next, we might need to go with replacing on > 0x0 entries and Tom> warning when they don't match what U-Boot has > detected. > > It is correct for the (classic) beaglebone. This also hits people > using appended dtb unless they have CONFIG_ARM_ATAG_DTB_COMPAT > enabled (which the probably do though). So yes, there are some cases where 256MB is the right value. But we always know dynamically how much we have, so we don't need to hard-code even in that case. And once we do change the behaviour, the appeneded tree hack shouldn't be relevant anyhow :) - -- Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRJUqnAAoJENk4IS6UOR1WAmgQALOHeh+p9aRLT+Hb0ZjpJk0c XGJzCO1EpdNpQBsgPxI2AzhPEHsVHgcdzXmzljHS4ukPWDbqihM4j7o9OHjuxAGY +8Yebw/E/1F7+wKXy013/3QFbl9mdd1OpTU95xarnaoe4+dP5pfa+Q/kH5mrc0U2 xiA4kDmInityA/DUuEP4d8mhnLQyn11CKS/LPKdT40HUGDk6ffzkmUCYEHBpwk11 QN7w6icIGE9JrMsQUOPir7CNDZsNCbeAtB8+gpStHxL63cHqxAh9R3yFyUc2uVHo 5NNkc71R0qLIrKMTbDjIfm1soTEWP94ob6VVPQafqSC7wQrK5r+2DNg9I7dN7xIr js5Y/BBbPuUZfMWiNWiyF+ONuoNNrz1+iLm9iLdaJajf5EuBQN/qUzNGKFTCsLne nR6cR0x/Ow+rN1TDmnSvmS845XUDK2qLY5nSthKieuFtoDY88j6VpR4ZO7+B6sSa 9MVx6LV8SO4USewl1FIpXoe6KC2AjdSK2rJN5i2SSQD6uxYzPCfBKezG7gi8Mfua v4M9W/jDU/avXo861XLeKgcZx0zA7PHxDhqgZDVbFs3QH3eobzZHGog001vM6mvr dEdUGxu0dVF9ocbF/2F6XxdMVxt2CK7ddbGCZy5V1R6ZCvOVZetCbQao8GB7ZqLU LMZf4b3iDGdrOfM57n5m =8tud -END PGP SIGNATURE- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Spansion S29GL128S support for environmental variables
Hi Everyone, I am working on uboot porting for Coldfire board M5272C3. I have 2 Spansion S29GL128S flash. I am able to run the uboot in target board (M5272C3). My problem is: a. I try to store my environment variable to flash and verify through BDM port that variable is written correctly . But once I reset by power cycling the board, it takes all the default environmental variables. I am confused is it that Spansion S26GL128S is not supported properly b/c I am not able to retrieve them after power up. Is it the problem with read routine or something I am missing? Please help me out with this. Thanks in advance ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Possible GPL violation
Dear Wolfgang, On 20.02.2013 15:24, Wolfgang Denk wrote: They're "made" (branded is probably better word) by local companies, and my guess is that most of them is violating GPL. Guesses are not good enough in such legal affairs. I know, that's why I'm not asking for help with "all" devices, just the one I have. I can't do much myself (except for nagging them for source code), as it's not my copyrights that they're infringing. So did you contact the vendor and ask for the source code? And did they answer, and what exactly? 10.2012 - I filled "generic" support form asking for sources of U-Boot, no reply. ~01.2013 - I called their tech-support, asking for sources. Of course guys didn't understood what I was asking for, but gave me e-mail to person that should be able to help me. 01.2013 - I send email to that person, no reply. end of 01.2013 - I called tech-support again, and was transferred to person I emailed earlier - and tried to explain that to comply with GPL they should provide me with sources on request. I'm not sure if he understood me, but was supposed to check it and get back to me. Of course he didn't. Perhaps it's my fault that in e-mails I didn't explained that they're obliged to provide me the sources (due to GPL) - that's why tomorrow I will try again to call and (if it fails) write them big email with quotes from GPL. If you have better ideas (I can go directly to their office, or send regular mail) - please share them, as you have way more experience with legal stuff than I do. Regards, Mateusz ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 3/4] Tegra: fdt: Add/enhance sdhci (mmc) nodes for all T20 DT files
On 02/20/2013 02:05 PM, Tom Warren wrote:
> Linux dts files were used for those boards that didn't already
> have sdhci info populated. Tamonten has their own dtsi file with
> common sdhci nodes (sourced from Linux).
So this patch now does a two unrelated things:
a) Switches from /include/ to #include.
b) A bunch of changes for the SDHCI properties.
Those should really be separate patches.
> diff --git a/board/compal/dts/tegra20-paz00.dts
> b/board/compal/dts/tegra20-paz00.dts
> -/include/ ARCH_CPU_DTS
> +#include ARCH_CPU_DTS
I think we should get rid of ARCH_CPU_DTS too. The only reason it ever
existed was because we were using dtc's include processing and had to
work around some issue with that (I can't remember exactly what, but
Simon will). Now that we're using cpp's include processing, we can
simply write:
#include "tegra20.dtsi".
> diff --git a/board/nvidia/dts/tegra20-seaboard.dts
> b/board/nvidia/dts/tegra20-seaboard.dts
> /memreserve/ 0x1c00 0x0400;
Unrelated to this series, but we should remove that line. It's unlikely
to be remotely correct.
> sdhci@c8000400 {
> + status = "okay";
> cd-gpios = <&gpio 69 0>; /* gpio PI5 */
> wp-gpios = <&gpio 57 0>; /* gpio PH1 */
> power-gpios = <&gpio 70 0>; /* gpio PI6 */
> + bus-width = <4>;
> };
In an earlier version of these patches, I think you'd made the cd-gpios
flags be "3" not "0", and I'd pointed out that doesn't match the
kernel's. It turns out that on most (if not all) boards, cd-gpios should
actually be marked active-low, so the flags should likely be "1" (not 3;
bit 1 isn't defined to mean anything). This is true for all the NVIDIA
boards, and Paz00 and TrimSlice. Joseph Lo is waiting for confirmation
from Thierry and Lucas on their boards before re-spinning the patch to
update them too.
See:
http://www.spinics.net/lists/linux-mmc/msg19134.html
http://www.spinics.net/lists/linux-mmc/msg19139.html
> diff --git a/board/nvidia/dts/tegra30-cardhu.dts
> b/board/nvidia/dts/tegra30-cardhu.dts
> /memreserve/ 0x1c00 0x0400;
Same here, except that value is definitely always incorrect; memory
starts at 0x8000 on Tegra30, so that range never matches memory.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 0/4] Tegra: MMC: Add DT support for MMC to T20 boards
On 02/20/2013 02:05 PM, Tom Warren wrote: > This patchset adds device-tree support to the Tegra MMC driver. > All device config is done via properties in the DT files instead > of hard-coded config options/function arguments. > > I've tested this on my Seaboard and everything works fine, > including card detect. For the other T20 boards, I've used > the Linux kernel DTS files for the sdhci nodes where there > wasn't one already, or expanded the info that was already > there. Everything builds fine, but I haven't tested anything > but Seaboard. The series, Tested-by: Stephen Warren (On Harmony only, which was one of the 2 problematic boards for v4) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 3/4] Tegra: fdt: Add/enhance sdhci (mmc) nodes for all T20 DT files
Stephen,
On Wed, Feb 20, 2013 at 3:35 PM, Stephen Warren wrote:
> On 02/20/2013 02:05 PM, Tom Warren wrote:
>> Linux dts files were used for those boards that didn't already
>> have sdhci info populated. Tamonten has their own dtsi file with
>> common sdhci nodes (sourced from Linux).
>
> So this patch now does a two unrelated things:
>
> a) Switches from /include/ to #include.
> b) A bunch of changes for the SDHCI properties.
>
> Those should really be separate patches.
I'll split 'em.
>
>> diff --git a/board/compal/dts/tegra20-paz00.dts
>> b/board/compal/dts/tegra20-paz00.dts
>
>> -/include/ ARCH_CPU_DTS
>> +#include ARCH_CPU_DTS
>
> I think we should get rid of ARCH_CPU_DTS too. The only reason it ever
> existed was because we were using dtc's include processing and had to
> work around some issue with that (I can't remember exactly what, but
> Simon will). Now that we're using cpp's include processing, we can
> simply write:
>
> #include "tegra20.dtsi".
That can be done later in a dts include file cleanup patch for all the
DT builds/files. What is there now works fine.
>
>> diff --git a/board/nvidia/dts/tegra20-seaboard.dts
>> b/board/nvidia/dts/tegra20-seaboard.dts
>
>> /memreserve/ 0x1c00 0x0400;
>
> Unrelated to this series, but we should remove that line. It's unlikely
> to be remotely correct.
Yep, saw those (tegra30, too), but didn't want to fix 'em here. I'll
do it in a separate patch later.
>
>> sdhci@c8000400 {
>> + status = "okay";
>> cd-gpios = <&gpio 69 0>; /* gpio PI5 */
>> wp-gpios = <&gpio 57 0>; /* gpio PH1 */
>> power-gpios = <&gpio 70 0>; /* gpio PI6 */
>> + bus-width = <4>;
>> };
>
> In an earlier version of these patches, I think you'd made the cd-gpios
> flags be "3" not "0", and I'd pointed out that doesn't match the
> kernel's. It turns out that on most (if not all) boards, cd-gpios should
> actually be marked active-low, so the flags should likely be "1" (not 3;
> bit 1 isn't defined to mean anything). This is true for all the NVIDIA
> boards, and Paz00 and TrimSlice. Joseph Lo is waiting for confirmation
> from Thierry and Lucas on their boards before re-spinning the patch to
> update them too.
Card-detect works fine (at least, on Seaboard). There never was an
earlier version with cd-gpios flags with anything other than 0. It was
power-gpios for Seaboard that had its flags set to 3 in a ChromeOS
version of U-Boot that I originally copied the DT sdhci info from, and
I've fixed that.
>
> See:
> http://www.spinics.net/lists/linux-mmc/msg19134.html
> http://www.spinics.net/lists/linux-mmc/msg19139.html
>
>> diff --git a/board/nvidia/dts/tegra30-cardhu.dts
>> b/board/nvidia/dts/tegra30-cardhu.dts
>
>> /memreserve/ 0x1c00 0x0400;
>
> Same here, except that value is definitely always incorrect; memory
> starts at 0x8000 on Tegra30, so that range never matches memory.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 3/4] Tegra: fdt: Add/enhance sdhci (mmc) nodes for all T20 DT files
On 02/20/2013 04:01 PM, Tom Warren wrote:
> Stephen,
>
> On Wed, Feb 20, 2013 at 3:35 PM, Stephen Warren wrote:
>> On 02/20/2013 02:05 PM, Tom Warren wrote:
>>> Linux dts files were used for those boards that didn't already
>>> have sdhci info populated. Tamonten has their own dtsi file with
>>> common sdhci nodes (sourced from Linux).
>>
>> So this patch now does a two unrelated things:
>>
>> a) Switches from /include/ to #include.
>> b) A bunch of changes for the SDHCI properties.
>>
>> Those should really be separate patches.
> I'll split 'em.
>
>>
>>> diff --git a/board/compal/dts/tegra20-paz00.dts
>>> b/board/compal/dts/tegra20-paz00.dts
>>
>>> -/include/ ARCH_CPU_DTS
>>> +#include ARCH_CPU_DTS
>>
>> I think we should get rid of ARCH_CPU_DTS too. The only reason it ever
>> existed was because we were using dtc's include processing and had to
>> work around some issue with that (I can't remember exactly what, but
>> Simon will). Now that we're using cpp's include processing, we can
>> simply write:
>>
>> #include "tegra20.dtsi".
> That can be done later in a dts include file cleanup patch for all the
> DT builds/files. What is there now works fine.
Sigh. But if you're using cpp now, then removing the use of ARCH_CPU_DTS
is logically part of that.
I agree it works now, but it's far more important to get it right than
just make it work.
>>> diff --git a/board/nvidia/dts/tegra20-seaboard.dts
>>> b/board/nvidia/dts/tegra20-seaboard.dts
>>
>>> /memreserve/ 0x1c00 0x0400;
>>
>> Unrelated to this series, but we should remove that line. It's unlikely
>> to be remotely correct.
> Yep, saw those (tegra30, too), but didn't want to fix 'em here. I'll
> do it in a separate patch later.
>
>>
>>> sdhci@c8000400 {
>>> + status = "okay";
>>> cd-gpios = <&gpio 69 0>; /* gpio PI5 */
>>> wp-gpios = <&gpio 57 0>; /* gpio PH1 */
>>> power-gpios = <&gpio 70 0>; /* gpio PI6 */
>>> + bus-width = <4>;
>>> };
>>
>> In an earlier version of these patches, I think you'd made the cd-gpios
>> flags be "3" not "0", and I'd pointed out that doesn't match the
>> kernel's. It turns out that on most (if not all) boards, cd-gpios should
>> actually be marked active-low, so the flags should likely be "1" (not 3;
>> bit 1 isn't defined to mean anything). This is true for all the NVIDIA
>> boards, and Paz00 and TrimSlice. Joseph Lo is waiting for confirmation
>> from Thierry and Lucas on their boards before re-spinning the patch to
>> update them too.
>
> Card-detect works fine (at least, on Seaboard).
That's likely because nothing in the code actually uses the GPIO flags
field, but rather assumes that the GPIO is active low.
We should still correct this error in the DT so that what the DT asserts
is true actually is true.
> There never was an
> earlier version with cd-gpios flags with anything other than 0. It was
> power-gpios for Seaboard that had its flags set to 3 in a ChromeOS
> version of U-Boot that I originally copied the DT sdhci info from, and
> I've fixed that.
Ah, OK.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] common: cmd_sata: Fix usage text for 'sata init'
From: Fabio Estevam Currently sata usage text prints a double 'sata' for the init command. MX53LOCO U-Boot > sata sata - SATA sub system Usage: sata sata init - init SATA sub system sata info - show available SATA devices sata device [dev] - show or set current device sata part [dev] - print partition table sata read addr blk# cnt sata write addr blk# cnt Remove the extra 'sata' from the 'sata init' line. Signed-off-by: Fabio Estevam --- common/cmd_sata.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/common/cmd_sata.c b/common/cmd_sata.c index b401bd1..8d57285 100644 --- a/common/cmd_sata.c +++ b/common/cmd_sata.c @@ -196,7 +196,7 @@ static int do_sata(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) U_BOOT_CMD( sata, 5, 1, do_sata, "SATA sub system", - "sata init - init SATA sub system\n" + "init - init SATA sub system\n" "sata info - show available SATA devices\n" "sata device [dev] - show or set current device\n" "sata part [dev] - print partition table\n" -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC] Kbuild support for ARM FIT images
Hello, I've been spinning some work-in-progress patches for FIT build support in the kernel. With the move to multiplatform support on OMAP, I feel it is a good time to add FIT support, also looking at the proliferating number of dtbs, as it is a nice way Currently the following is what I envision the way it will work: - New "uImage-fit" target in $(boot)/ which is made to depend on "dtbs" target - Changes to dtbs target to output a $(srctree)/.tmp_list_dtbs listing the full paths to all the dtbs built - A new script "mkfitsrc.sh" that spits out an ITS to $(srctree)/.tmp_its . The above tmp file is passed - For each dtb, a new "device tree" node is created in the ITS - For each dtb, a new "configuration" node is created in the ITS - mkimage is called on the ITS sources to output the kernel image. (TODO: to use mkuboot.sh) I have yet to do some boot time tests, as I don't have my board now and don't want to post something that doesn't work. But all this has been build-tested. Any comments on this approach? Is it better to merge mkfitsrc.sh with mkuboot.sh? Regards, Joel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 00/11] *** SUBJECT HERE ***
On Wed, Feb 20, 2013 at 04:36:21PM +0800, Sonic Zhang wrote: > Hi Wolfgang, > > On Tue, Feb 19, 2013 at 6:14 PM, Wolfgang Denk wrote: > > Dear Sonic Zhang, > > > > please provide a useful Subject: line - "*** SUBJECT HERE ***" is not > > exactly helpful. > > > > In message <1361257266-3722-1-git-send-email-sonic@gmail.com> you wrote: > >> > >> The v2 patches > >> 1) fix most checkpatch issues mentioned by Wolfgang > > > > Hm... I'm sorry, but this information is not really helpful. So it > > seems you decided not to fix all issues, but you don't tell us which > > ones you ignored, or why. > > > > I still see thousands of lines over 80 characters, > > plus a number of > > trailing statements should be on next line, > > code indent should use tabs where possible, > > do not add new typedefs, > > Whitespace before semicolon, > > warnings and errors. > > > > Please fix these!! > > > > Sorry, I forget to check the serial patch after fixing the unreadable > port muxing code. > But, where is the "Whitespace before semicolon"? my checkpatch.pl > doesn't report this issue. > > >> 2) remove unrelated dma structure change patch > >> 3) replace unreable macro in dma and uart structures with normal types. > >> 4) replace unreable macro in uart peripheral portmux configuration with > >> clear inline function. > >> 5) clean up and merge redundant #ifdef's > >> 6) spearate declarations and code by a blankline > >> 7) remove the values for variables in blackfin config headers whose values > >> are useless > >> 8) replace run-time variable with new macro when adding 4M byte CPLB > >> entries. > > > > Please provide a more detailed list which review comments you > > processed, and which you decided to ignore, and why. > > > > Please provide a more detailed list which review comments you > > processed, and which you decided to ignore, and why. > > > > Note: this history of changes is supposed to be (also) in the patches > > itself, not (only) in the cover letter. > > > > OK. I will put all change logs into the patches respectively. Making use of patman (see tools/patman) can help both in that it will generate the emails for you, based on you adding the right information to your commits, and it will run the same checkpatch that Wolfgang is running as well. -- 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/3] ARM: at91: change nand flash table
On Wed, Feb 20, 2013 at 06:16:25PM +0800, Bo Shen wrote: > Change nand flash partition tablke according to www.at91.com/linux4sam > > more information: > http://www.at91.com/linux4sam/bin/view/Linux4SAM/GettingStarted#Linux4SAM_NandFlash_demo_Memory > > Signed-off-by: Bo Shen Question. Is there a reason to not being doing the MTDIDS / MTDPARTS and adding CONFIG_CMD_MTDPARTS ? Doing that should also "just" enable the nand info to be passed in the device tree. -- 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] [RFC] Kbuild support for ARM FIT images
On 02/20/2013 06:37 PM, Joel A Fernandes wrote:
> Hello,
> I've been spinning some work-in-progress patches for FIT build support
> in the kernel.
> With the move to multiplatform support on OMAP, I feel it is a good
> time to add FIT support, also looking at the proliferating number of
> dtbs, as it is a nice way
To my mind, FIT is pointless. And forcing the kernel build process to
create bootloader-specific files doesn't seem like a good idea. Doing so
would require pulling in even more outside tools into the kernel build flow.
All you need is to copy the zImage and any relevant .dtb files into
/boot, and have U-Boot load the relevant .dtb file by constructing the
filename as roughly ${soc}-${board}.dtb, then use the bootz command to
boot it. You can have a completely generic boot.scr (or built-in script).
Note: Not all (many?) U-Boot support FIT anyway, so you'd need to flash
a new U-Boot to support FIT, so you may as well just flash a new U-Boot
that implements the ${soc} and ${board} variables instead. IIRC, there
may also be a ${boardname} or similar that's like ${board}, but
represents the runtime-detected board for when one U-Boot build actually
supports multiple different boards.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2 V2] EXYNOS5: Add initial DTS file for Snow.
This patch adds the DTS file for Snow Board.
Signed-off-by: Rajeshwari Shinde
Acked-by: Simon Glass
---
Changes in V2:
- None
board/samsung/dts/exynos5250-snow.dts | 69 +
1 files changed, 69 insertions(+), 0 deletions(-)
create mode 100644 board/samsung/dts/exynos5250-snow.dts
diff --git a/board/samsung/dts/exynos5250-snow.dts
b/board/samsung/dts/exynos5250-snow.dts
new file mode 100644
index 000..360d3bd
--- /dev/null
+++ b/board/samsung/dts/exynos5250-snow.dts
@@ -0,0 +1,69 @@
+/*
+ * SAMSUNG Snow board device tree source
+ *
+ * Copyright (c) 2012 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+*/
+
+/dts-v1/;
+/include/ ARCH_CPU_DTS
+
+/ {
+ model = "Google Snow";
+ compatible = "google,snow", "samsung,exynos5250";
+
+ aliases {
+ i2c0 = "/i2c@12c6";
+ i2c1 = "/i2c@12c7";
+ i2c2 = "/i2c@12c8";
+ i2c3 = "/i2c@12c9";
+ i2c4 = "/i2c@12ca";
+ i2c5 = "/i2c@12cb";
+ i2c6 = "/i2c@12cc";
+ i2c7 = "/i2c@12cd";
+ spi0 = "/spi@12d2";
+ spi1 = "/spi@12d3";
+ spi2 = "/spi@12d4";
+ spi3 = "/spi@131a";
+ spi4 = "/spi@131b";
+ };
+
+ sromc@1225 {
+ bank = <1>;
+ srom-timing = <1 9 12 1 6 1 1>;
+ width = <2>;
+ lan@500 {
+ compatible = "smsc,lan9215", "smsc,lan";
+ reg = <0x500 0x100>;
+ phy-mode = "mii";
+ };
+ };
+
+ sound@12d6 {
+ samsung,i2s-epll-clock-frequency = <19200>;
+ samsung,i2s-sampling-rate = <48000>;
+ samsung,i2s-bits-per-sample = <16>;
+ samsung,i2s-channels = <2>;
+ samsung,i2s-lr-clk-framesize = <256>;
+ samsung,i2s-bit-clk-framesize = <32>;
+ samsung,codec-type = "max98095";
+ };
+
+ i2c@12cd {
+ soundcodec@22 {
+ reg = <0x22>;
+ compatible = "maxim,max98095-codec";
+ };
+ };
+
+ i2c@12c6 {
+ pmic@9 {
+ reg = <0x9>;
+ compatible = "maxim,max77686_pmic";
+ };
+ };
+};
--
1.7.4.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/2 V2] EXYNOS5: SNOW: Add initial dts and config file
This patch set adds initial dts and configuration file for snow. Changes in V2: - Added Maintainer. Rajeshwari Shinde (2): EXYNOS5: Add initial DTS file for Snow. EXYNOS5: Snow: Add a configuration file MAINTAINERS |4 ++ board/samsung/dts/exynos5250-snow.dts | 69 + boards.cfg|1 + include/configs/snow.h| 33 4 files changed, 107 insertions(+), 0 deletions(-) create mode 100644 board/samsung/dts/exynos5250-snow.dts create mode 100644 include/configs/snow.h -- 1.7.4.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2 V2] EXYNOS5: Snow: Add a configuration file
This patch adds the configuration file for Snow Board and defines the same in boards.cfg. Signed-off-by: Rajeshwari Shinde --- Changes in V2: - Added Maintainer MAINTAINERS|4 boards.cfg |1 + include/configs/snow.h | 33 + 3 files changed, 38 insertions(+), 0 deletions(-) create mode 100644 include/configs/snow.h diff --git a/MAINTAINERS b/MAINTAINERS index 45e2dd4..5fc5b4d 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -736,6 +736,10 @@ Chander Kashyap SMDKV310ARM ARMV7 (EXYNOS4210 SoC) SMDK5250ARM ARMV7 (EXYNOS5250 SoC) +Rajeshwari Shinde + + snowARM ARMV7 (EXYNOS5250 SoC) + Lukasz Majewski trats ARM ARMV7 (EXYNOS4210 SoC) diff --git a/boards.cfg b/boards.cfg index b1319aa..54357eb 100644 --- a/boards.cfg +++ b/boards.cfg @@ -286,6 +286,7 @@ s5p_goni arm armv7 goni samsung smdkc100 arm armv7 smdkc100 samsungs5pc1xx origen arm armv7 origen samsungexynos s5pc210_universalarm armv7 universal_c210 samsungexynos +snowarm armv7 smdk5250 samsungexynos smdk5250arm armv7 smdk5250 samsungexynos smdkv310arm armv7 smdkv310 samsungexynos tratsarm armv7 trats samsungexynos diff --git a/include/configs/snow.h b/include/configs/snow.h new file mode 100644 index 000..b8460fd --- /dev/null +++ b/include/configs/snow.h @@ -0,0 +1,33 @@ +/* + * Copyright (C) 2013 Samsung Electronics + * + * Configuration settings for the SAMSUNG EXYNOS5 Snow board. + * + * 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 + */ + +#ifndef __CONFIG_SNOW_H +#define __CONFIG_SNOW_H + +#include + +#undef CONFIG_DEFAULT_DEVICE_TREE +#define CONFIG_DEFAULT_DEVICE_TREE exynos5250-snow + +#endif /* __CONFIG_SNOW_H */ -- 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 3/3] ARM: at91: change nand flash table
Hi Tom, On 2/21/2013 10:05, Tom Rini wrote: On Wed, Feb 20, 2013 at 06:16:25PM +0800, Bo Shen wrote: Change nand flash partition tablke according to www.at91.com/linux4sam more information: http://www.at91.com/linux4sam/bin/view/Linux4SAM/GettingStarted#Linux4SAM_NandFlash_demo_Memory Signed-off-by: Bo Shen Question. Is there a reason to not being doing the MTDIDS / MTDPARTS and adding CONFIG_CMD_MTDPARTS ? Yes, MTDIDS/MTDPARTS is missing, however, we can set mtdids and mtdpart environment to use mtdparts command. (Maybe this is not a good idea, will consider to add MTDIDS / MTDPARTS later, not in this patch series.) Doing that should also "just" enable the nand info to be passed in the device tree. I am not fully understand this. You means add MTDIDS / MTDPARTS, it can automatically pass the nand info to device tree, not through the command line, am I right? Best Regards, Bo Shen ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
