Re: [U-Boot] [PATCH u-boot-arm/next 1/2] OMAP3: igep00x0: Add config option to choose flash storage memory
Hi, 2012/7/17 Tom Rini : > On 07/16/2012 04:41 PM, Javier Martinez Canillas wrote: > > [snip] >> Runtime detection is possible reading the sysboot as you said (in fact >> this is how we do it in the kernel) but as Tom said I didn't find a >> common way to do this. I guess you can manually detect the NAND type >> and configure the GPMC registers on the board code but I didn't see >> other OMAP boards doing this. Instead I found other examples of boards >> using compile options to choose between memory types. >> >> Of course I will be more than glad if you have a better approach to >> solve this :-) > > The biggest problem is that today we don't have a way to read/write > environment to a dynamically detected backing store. I had an idea on > how to do this, but given the device model will also allow for this, > easier, that's the way to go. > > -- > Tom Cool, thanks for the explanations Tom. Javier, of course you have my :-) Acked-by: Enric Balletbo i Serra Cheers, Enric ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH u-boot-arm/next v2 1/1] OMAP3: igep00x0: add SPL support for IGEP-based boards
2012/7/17 Javier Martinez Canillas : > This patch adds SPL support for IGEP-based boards. > > Tested on an IGEPv2 Rev.C board with Micron NAND Flash memory. > > Signed-off-by: Javier Martinez Canillas > --- > > Changes since v1: > - CONFIG_SPL_MAX_SIZE should be 54 * 1024 instead of 45 * 1024 as > suggested by Tom Rini > > board/isee/igep0020/config.mk | 33 > board/isee/igep0020/igep0020.c | 34 - > board/isee/igep0030/config.mk | 33 > board/isee/igep0030/igep0030.c | 34 - > include/configs/igep00x0.h | 65 > > 5 files changed, 131 insertions(+), 68 deletions(-) > delete mode 100644 board/isee/igep0020/config.mk > delete mode 100644 board/isee/igep0030/config.mk > > diff --git a/board/isee/igep0020/config.mk b/board/isee/igep0020/config.mk > deleted file mode 100644 > index 7964621..000 > --- a/board/isee/igep0020/config.mk > +++ /dev/null > @@ -1,33 +0,0 @@ > -# > -# (C) Copyright 2009 > -# ISEE 2007 SL, > -# > -# IGEP0020 uses OMAP3 (ARM-CortexA8) cpu > -# see http://www.ti.com/ for more information on Texas Instruments > -# > -# 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 > -# > -# Physical Address: > -# 8000' (bank0) > -# A000/ (bank1) > -# Linux-Kernel is expected to be at 8000'8000, entry 8000'8000 > -# (mem base + reserved) > - > -# For use with external or internal boots. > -CONFIG_SYS_TEXT_BASE = 0x80008000 > diff --git a/board/isee/igep0020/igep0020.c b/board/isee/igep0020/igep0020.c > index 971e31b..40436d6 100644 > --- a/board/isee/igep0020/igep0020.c > +++ b/board/isee/igep0020/igep0020.c > @@ -58,6 +58,38 @@ int board_init(void) > return 0; > } > > +#ifdef CONFIG_SPL_BUILD > +/* > + * Routine: omap_rev_string > + * Description: For SPL builds output board rev > + */ > +void omap_rev_string(void) > +{ > +} > + > +/* > + * Routine: get_board_mem_timings > + * Description: If we use SPL then there is no x-loader nor config header > + * so we have to setup the DDR timings ourself on both banks. > + */ > +void get_board_mem_timings(u32 *mcfg, u32 *ctrla, u32 *ctrlb, u32 *rfr_ctrl, > + u32 *mr) > +{ > + *mr = MICRON_V_MR_165; > +#ifdef CONFIG_BOOT_NAND > + *mcfg = MICRON_V_MCFG_165(512 << 20); > + *ctrla = MICRON_V_ACTIMA_165; > + *ctrlb = MICRON_V_ACTIMB_165; > + *rfr_ctrl = SDP_3430_SDRC_RFR_CTRL_165MHz; > +#else > + *mcfg = NUMONYX_V_MCFG_165(512 << 20); > + *ctrla = NUMONYX_V_ACTIMA_165; > + *ctrlb = NUMONYX_V_ACTIMB_165; > + *rfr_ctrl = SDP_3430_SDRC_RFR_CTRL_165MHz; > +#endif > +} > +#endif > + > /* > * Routine: setup_net_chip > * Description: Setting up the configuration GPMC registers specific to the > @@ -91,7 +123,7 @@ static void setup_net_chip(void) > } > #endif > > -#ifdef CONFIG_GENERIC_MMC > +#if defined(CONFIG_GENERIC_MMC) && !defined(CONFIG_SPL_BUILD) > int board_mmc_init(bd_t *bis) > { > omap_mmc_init(0, 0, 0); > diff --git a/board/isee/igep0030/config.mk b/board/isee/igep0030/config.mk > deleted file mode 100644 > index 059a878..000 > --- a/board/isee/igep0030/config.mk > +++ /dev/null > @@ -1,33 +0,0 @@ > -# > -# (C) Copyright 2009 > -# ISEE 2007 SL, > -# > -# IGEP0030 uses OMAP3 (ARM-CortexA8) cpu > -# see http://www.ti.com/ for more information on Texas Instruments > -# > -# 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, >
[U-Boot] [PATCH] ppc: Create a stack frame for wait_ticks()
wait_ticks() calls get_ticks() without building a back chain which makes gdb unhappy when doing back trace. This can also cause improper memory accesses. Signed-off-by: Joakim Tjernlund --- arch/powerpc/lib/ticks.S |7 +-- 1 files changed, 5 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/lib/ticks.S b/arch/powerpc/lib/ticks.S index b8d25b7..1781039 100644 --- a/arch/powerpc/lib/ticks.S +++ b/arch/powerpc/lib/ticks.S @@ -47,7 +47,9 @@ get_ticks: */ .globl wait_ticks wait_ticks: - mflrr8 /* save link register */ + stwur1, -16(r1) + mflrr0 /* save link register */ + stw r0, 20(r1) /* Use r0 or GDB will be unhappy */ mr r7, r3 /* save tick count */ bl get_ticks /* Get start time */ @@ -61,5 +63,6 @@ wait_ticks: subfe. r3, r3, r6 bge 1b /* Loop until time expired */ - mtlrr8 /* restore link register */ + mtlrr0 /* restore link register */ + addir1,r1,16 blr -- 1.7.3.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] i.MX28: extend print_cpuinfo() to use chip information
On 16/07/2012 21:59, Otavio Salvador wrote: > The information now is gathered from HW_DIGCTL_CHIPID register and > includes the chip modem and revision on the output. > > Signed-off-by: Otavio Salvador > --- Applied to u-boot-imx, next branch, thanks. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 2/2] i.MX28: use a clear name for DDR2 initialization
On 16/07/2012 22:39, Otavio Salvador wrote: > The mx28 prefix has been added to the initialization data and function > so it is clear by which SoC it is used as i.MX233 will have a specific > one. > > Signed-off-by: Otavio Salvador > --- Hi Otavio, > arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c | 12 ++-- > 1 file changed, 6 insertions(+), 6 deletions(-) > > diff --git a/arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c > b/arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c > index e17a4d7..7317a97 100644 > --- a/arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c > +++ b/arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c > @@ -31,7 +31,7 @@ > > #include "mx28_init.h" > > -uint32_t dram_vals[] = { > +uint32_t mx28_dram_vals[] = { > 0x, 0x, 0x, 0x, > 0x, 0x, 0x, 0x, > 0x, 0x, 0x, 0x, > @@ -88,14 +88,14 @@ void __mx28_adjust_memory_params(uint32_t *dram_vals) > void mx28_adjust_memory_params(uint32_t *dram_vals) > __attribute__((weak, alias("__mx28_adjust_memory_params"))); Simply a general remark - I think we can discuss further when first patches forMX23 will be submitted. However, I think is a bad idea to specialize functions to a specific SOC. If a driver needs such as function, we will introduce some nasty #ifdef in driver code only to select which function must be called. And we duplicate this problem in all drivers. Instead of that, we could use the same general name. Where do we put mx23 code ? If we put it together with mx28 code (I mean in the same directory) we could extract specific SOC function from general files and use the mechanism provided by Makefile to compile the right one, for example: COBJS-$(CONFIG_MX28)+= spl_mem_mx28.o COBJS-$(CONFIG_MX23)+= spl_mem_mx23.o and spl_mem_init.c contains general code. Drivers call always the same function. Of course, this is only an example. At the moment, most mx28 function have the mx28_ prefix, but this is acceptable because up now the mx28 is the only one in this architecture. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] USB enumeration problem on iMX53 hardware
Dear all, I am working on adding support for Host USB on iMX53smd platform. The work is based on iMX53loco code which already support Host USB. Everything is working as it is supposed to. Different flash usb key are correctly enumerated and detected (and correctly manage by usb_storage module). Even usb to serial converters are correctly enumerated. But I have a problem with a 3G modem which is not correctly enumerated. In fact the enumeration does not detect anything as if no device was connected. But when linux is booted on the platform, this 3G modem is correctly enumerated by linux kernel. I added usb debug traces in u-boot. The traces show "Port 4 Status 101 Change 1" response to usb_control_msg call after the call to usb_hub_power_on when the usb flash key is used. When I use the 3G modem device, the response is Port 4 Status 100 Change 0 after the usb_hub_power_on. So it seems that the usb hub do not detect the 3G modem device (the flag USB_PORT_STAT_C_CONNECTION is correctly set in the response when using flash usb key but not set when I use the 3G modem). Again, the enumeration process for the 3G modem work correctly with the linux kernel, so I could reasonably think that there is not hardware problem on usb hub and 3G modem usb key. Does one of you has already encountered a similar problem and/or has an idea of what could cause this ? Gérald___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ARM: OMAP4: PANDA: Fix the broken tftp issue.
USB module pads are getting enabled under non-essential group which are not currently configured. But these will be required for tftp support. Commit 1a89a217f5c5ab3645c80c1247e8911a8b5ad491 ARM: OMAP4/5: Move USB pads to essential list. moved the usb related pads to the essential list, but mux file for PANDA was missed out. Adding it here to ensure TFTP works fine on OMAP4 panda boards. Tested this on OMAP4430 ES2.2, OMAP4460 ES1.1 PANDA boards. Signed-off-by: R Sricharan --- board/ti/panda/panda_mux_data.h | 44 +++ 1 file changed, 22 insertions(+), 22 deletions(-) diff --git a/board/ti/panda/panda_mux_data.h b/board/ti/panda/panda_mux_data.h index dc8b388..5939257 100644 --- a/board/ti/panda/panda_mux_data.h +++ b/board/ti/panda/panda_mux_data.h @@ -62,7 +62,26 @@ const struct pad_conf_entry core_padconf_array_essential[] = { {UART3_CTS_RCTX, (PTU | IEN | M0)},/* uart3_tx */ {UART3_RTS_SD, (M0)}, /* uart3_rts_sd */ {UART3_RX_IRRX, (IEN | M0)}, /* uart3_rx */ -{UART3_TX_IRTX, (M0)} /* uart3_tx */ +{UART3_TX_IRTX, (M0)}, /* uart3_tx */ +{USBB1_ULPITLL_CLK, (PTD | IEN | OFF_EN | OFF_PD | OFF_IN | M4)},/* usbb1_ulpiphy_clk */ +{USBB1_ULPITLL_STP, (OFF_EN | OFF_OUT_PTD | M4)}, /* usbb1_ulpiphy_stp */ +{USBB1_ULPITLL_DIR, (IEN | OFF_EN | OFF_PD | OFF_IN | M4)},/* usbb1_ulpiphy_dir */ +{USBB1_ULPITLL_NXT, (IEN | OFF_EN | OFF_PD | OFF_IN | M4)},/* usbb1_ulpiphy_nxt */ +{USBB1_ULPITLL_DAT0, (IEN | OFF_EN | OFF_PD | OFF_IN | M4)}, /* usbb1_ulpiphy_dat0 */ +{USBB1_ULPITLL_DAT1, (IEN | OFF_EN | OFF_PD | OFF_IN | M4)}, /* usbb1_ulpiphy_dat1 */ +{USBB1_ULPITLL_DAT2, (IEN | OFF_EN | OFF_PD | OFF_IN | M4)}, /* usbb1_ulpiphy_dat2 */ +{USBB1_ULPITLL_DAT3, (IEN | OFF_EN | OFF_PD | OFF_IN | M4)}, /* usbb1_ulpiphy_dat3 */ +{USBB1_ULPITLL_DAT4, (IEN | OFF_EN | OFF_PD | OFF_IN | M4)}, /* usbb1_ulpiphy_dat4 */ +{USBB1_ULPITLL_DAT5, (IEN | OFF_EN | OFF_PD | OFF_IN | M4)}, /* usbb1_ulpiphy_dat5 */ +{USBB1_ULPITLL_DAT6, (IEN | OFF_EN | OFF_PD | OFF_IN | M4)}, /* usbb1_ulpiphy_dat6 */ +{USBB1_ULPITLL_DAT7, (IEN | OFF_EN | OFF_PD | OFF_IN | M4)}, /* usbb1_ulpiphy_dat7 */ +{USBB1_HSIC_DATA, (IEN | OFF_EN | OFF_PD | OFF_IN | M0)}, /* usbb1_hsic_data */ +{USBB1_HSIC_STROBE, (IEN | OFF_EN | OFF_PD | OFF_IN | M0)},/* usbb1_hsic_strobe */ +{USBC1_ICUSB_DP, (IEN | M0)}, /* usbc1_icusb_dp */ +{USBC1_ICUSB_DM, (IEN | M0)}, /* usbc1_icusb_dm */ +{UNIPRO_TY2, (PTU | IEN | M3)},/* gpio_1 */ +{GPMC_WAIT1, (PTD | OFF_EN | OFF_PD | OFF_OUT_PTD | M3)}, /* gpio_62 */ +{FREF_CLK2_OUT, (PTU | IEN | M3)}, /* gpio_182 */ }; @@ -70,7 +89,8 @@ const struct pad_conf_entry wkup_padconf_array_essential[] = { {PAD1_SR_SCL, (PTU | IEN | M0)}, /* sr_scl */ {PAD0_SR_SDA, (PTU | IEN | M0)}, /* sr_sda */ -{PAD1_SYS_32K, (IEN | M0)} /* sys_32k */ +{PAD1_SYS_32K, (IEN | M0)}, /* sys_32k */ +{PAD0_FREF_CLK3_OUT, (M0)}, /* fref_clk3_out */ }; @@ -109,7 +129,6 @@ const struct pad_conf_entry core_padconf_array_non_essential[] = { {GPMC_NBE0_CLE, (M3)}, /* gpio_59 */ {GPMC_NBE1, (PTD | M3)},/* gpio_60 */ {GPMC_WAIT0, (PTU | IEN | M3)}, /* gpio_61 */ - {GPMC_WAIT1, (PTD | OFF_EN | OFF_PD | OFF_OUT_PTD | M3)}, /* gpio_62 */ {C2C_DATA11, (PTD | M3)}, /* gpio_100 */ {C2C_DATA12, (PTU | IEN | M3)}, /* gpio_101 */ {C2C_DATA13, (PTD | M3)}, /* gpio_102 */ @@ -136,22 +155,6 @@ const struct pad_conf_entry core_padconf_array_non_essential[] = { {CAM_SHUTTER, (OFF_EN | OFF_PD | OFF_OUT_PTD | M0)},/* cam_shutter */ {CAM_STROBE, (OFF_EN | OFF_PD | OFF_OUT_PTD | M0)}, /* cam_strobe */ {CAM_GLOBALRESET, (PTD | OFF_EN | OFF_PD | OFF_OUT_PTD | M3)}, /* gpio_83 */ - {USBB1_ULPITLL_CLK, (PTD | IEN | OFF_EN | OFF_PD | OFF_IN | M4)},/* usbb1_ulpiphy_clk */ - {USBB1_ULPITLL_STP, (OFF_EN | OFF_OUT_PTD | M4)}, /* usbb1_ulpiphy_stp */ - {USBB1_ULPITLL_DIR, (IEN | OFF_EN | OFF_PD | OFF_IN | M4)}, /* usbb1_ulpiphy_dir */ - {USBB1_ULPITLL_NXT, (IEN | OFF_EN | OFF_PD | OFF_IN | M4)}, /* usbb1_ulpiphy_nxt */ - {USBB1_ULPITLL_DAT0, (IEN | OFF_EN | OFF_PD | OFF_IN | M4)},/* usbb1_ulpiphy_dat0 */ - {USBB1_ULPITLL_DAT1, (IEN | OFF_EN | OFF_PD | OFF_IN | M4)},/* usbb1_ulpiphy_dat1 */ - {USBB1_ULPITLL_DAT2, (IEN | OFF_EN | OFF_PD | OFF_IN | M4)},/* usbb1_ulpiphy_dat2 */ -
Re: [U-Boot] Notes from the U-Boot BOF Meeting in Geneva 2012/07/12
On Tuesday 17 July 2012 01:11:01 Graeme Russ wrote: > > It was discussed whether to do some "automatic" merging of these > > per-custodian trees into a central next, but majority of people believed > > that the patch handling process should remain as unchanged as possible > > in sync with the "principle of least surprise". > > I agree that automatic merging is a 'Bad Thing(tm)'. But one thing I notice > (and I don't know if this is a recent thing) but there seems to be a case > of zero merge activity up to the closing of the merge window and then a > rash of merging just prior to the RCs. I favour a more continuous merge > strategy. I favored the automatic merging at the conference mainly because of one reason: To detect potential merge conflicts as early as possible. And send the result of this automated merge to the list (or a new list). In combination with (automated) nightly builds this not only catches merge conflicts but also build problems. All this should be pretty easy to automate. And it moves the detection of those problems closer to the submission of the patches. So we (and the original patch authors) don't have to figure out what the patch was all about weeks later. Just my 0.02$. :) 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-0 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] Notes from the U-Boot BOF Meeting in Geneva 2012/07/12
Hi Stefan, On 07/17/2012 08:37 PM, Stefan Roese wrote: > On Tuesday 17 July 2012 01:11:01 Graeme Russ wrote: >>> It was discussed whether to do some "automatic" merging of these >>> per-custodian trees into a central next, but majority of people believed >>> that the patch handling process should remain as unchanged as possible >>> in sync with the "principle of least surprise". >> >> I agree that automatic merging is a 'Bad Thing(tm)'. But one thing I notice >> (and I don't know if this is a recent thing) but there seems to be a case >> of zero merge activity up to the closing of the merge window and then a >> rash of merging just prior to the RCs. I favour a more continuous merge >> strategy. > > I favored the automatic merging at the conference mainly because of one > reason: > > To detect potential merge conflicts as early as possible. And send the result > of this automated merge to the list (or a new list). 100% agree with first sentence. Worried about how much extra traffic an auto-build would cause if it was mailing the list as well > In combination with (automated) nightly builds this not only catches merge > conflicts but also build problems. All this should be pretty easy to > automate. > And it moves the detection of those problems closer to the submission of the > patches. So we (and the original patch authors) don't have to figure out what > the patch was all about weeks later. I think U-Boot has reached the point that purely manual patch management is not longer cutting the mustard. Maybe it's time to seriously look at a gerrit + jenkins based solution? Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Notes from the U-Boot BOF Meeting in Geneva 2012/07/12
On 07/17/2012 10:10 PM, Graeme Russ wrote: > > Maybe it's time to seriously look at a gerrit + jenkins based solution? > Here's a good demo video: http://alblue.bandlem.com/2011/02/gerrit-git-review-with-jenkins-ci.html ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 2/2] i.MX28: use a clear name for DDR2 initialization
On Tue, Jul 17, 2012 at 6:15 AM, Stefano Babic wrote: > Simply a general remark - I think we can discuss further when first > patches for MX23 will be submitted. However, I think is a bad idea to > specialize functions to a specific SOC. If a driver needs such as > function, we will introduce some nasty #ifdef in driver code only to > select which function must be called. And we duplicate this problem in > all drivers. > > Instead of that, we could use the same general name. Where do we put > mx23 code ? If we put it together with mx28 code (I mean in the same > directory) we could extract specific SOC function from general files and > use the mechanism provided by Makefile to compile the right one, for > example: > > COBJS-$(CONFIG_MX28)+= spl_mem_mx28.o > COBJS-$(CONFIG_MX23)+= spl_mem_mx23.o > > and spl_mem_init.c contains general code. Drivers call always the same > function. Of course, this is only an example. At the moment, most mx28 > function have the mx28_ prefix, but this is acceptable because up now > the mx28 is the only one in this architecture. Agreed; I will check my current work in progress code and rework it this way. However this prefix change is highly desired as it is callmed m28 (looking as m28evk specific) instead of mx28. -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 2/2] i.MX28: use a clear name for DDR2 initialization
On 17/07/2012 14:16, Otavio Salvador wrote: > On Tue, Jul 17, 2012 at 6:15 AM, Stefano Babic wrote: >> Simply a general remark - I think we can discuss further when first >> patches for MX23 will be submitted. However, I think is a bad idea to >> specialize functions to a specific SOC. If a driver needs such as >> function, we will introduce some nasty #ifdef in driver code only to >> select which function must be called. And we duplicate this problem in >> all drivers. >> >> Instead of that, we could use the same general name. Where do we put >> mx23 code ? If we put it together with mx28 code (I mean in the same >> directory) we could extract specific SOC function from general files and >> use the mechanism provided by Makefile to compile the right one, for >> example: >> >> COBJS-$(CONFIG_MX28)+= spl_mem_mx28.o >> COBJS-$(CONFIG_MX23)+= spl_mem_mx23.o >> >> and spl_mem_init.c contains general code. Drivers call always the same >> function. Of course, this is only an example. At the moment, most mx28 >> function have the mx28_ prefix, but this is acceptable because up now >> the mx28 is the only one in this architecture. > > Agreed; I will check my current work in progress code and rework it > this way. However this prefix change is highly desired as it is > callmed m28 (looking as m28evk specific) instead of mx28. Yes, mx28 is a better name - if a prefix, it should be a SOC prefix, not a board name. But I noted : -uint32_t dram_vals[] = { +uint32_t mx28_dram_vals[] = { 0x, 0x, 0x, 0x, 0x, 0x, 0x, 0x, 0x, 0x, 0x, 0x, why is this structure not static ? Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 2/2] i.MX28: use a clear name for DDR2 initialization
On Tue, Jul 17, 2012 at 9:41 AM, Stefano Babic wrote: >> Agreed; I will check my current work in progress code and rework it >> this way. However this prefix change is highly desired as it is >> callmed m28 (looking as m28evk specific) instead of mx28. > > Yes, mx28 is a better name - if a prefix, it should be a SOC prefix, not > a board name. > > But I noted : > -uint32_t dram_vals[] = { > +uint32_t mx28_dram_vals[] = { > 0x, 0x, 0x, 0x, > 0x, 0x, 0x, 0x, > 0x, 0x, 0x, 0x, > > why is this structure not static ? Indeed; I will send a new patch for it. -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] nds32: split common cache access from cpu into lib
This commit does the following updates. 1. Split the common cache access from cpu.c into lib folder. 2. Rename the following cache api to adapt common.h - dcache_flush_rang -> flush_dcache_rang - icache_inval_range -> invalidate_icache_range 3. Add invalidate_dcache_range Signed-off-by: Macpaul Lin --- Changes for v2: - flush_dcache_range: merge two asm calls into a single asm volatile() block. - Replace __asm__ __volatile__ block into asm volatile() arch/nds32/cpu/n1213/ag101/cpu.c | 112 --- arch/nds32/cpu/n1213/ag102/cpu.c | 112 --- arch/nds32/lib/Makefile |2 +- arch/nds32/lib/cache.c | 157 ++ 4 files changed, 158 insertions(+), 225 deletions(-) create mode 100644 arch/nds32/lib/cache.c diff --git a/arch/nds32/cpu/n1213/ag101/cpu.c b/arch/nds32/cpu/n1213/ag101/cpu.c index c2636b1..a9991e7 100644 --- a/arch/nds32/cpu/n1213/ag101/cpu.c +++ b/arch/nds32/cpu/n1213/ag101/cpu.c @@ -82,115 +82,3 @@ int do_reset(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) /*NOTREACHED*/ } - -static inline unsigned long CACHE_LINE_SIZE(enum cache_t cache) -{ - if (cache == ICACHE) - return 8 << (((GET_ICM_CFG() & ICM_CFG_MSK_ISZ) \ - >> ICM_CFG_OFF_ISZ) - 1); - else - return 8 << (((GET_DCM_CFG() & DCM_CFG_MSK_DSZ) \ - >> DCM_CFG_OFF_DSZ) - 1); -} - -void dcache_flush_range(unsigned long start, unsigned long end) -{ - unsigned long line_size; - - line_size = CACHE_LINE_SIZE(DCACHE); - - while (end > start) { - __asm__ volatile ("\n\tcctl %0, L1D_VA_WB" : : "r"(start)); - __asm__ volatile ("\n\tcctl %0, L1D_VA_INVAL" : : "r"(start)); - start += line_size; - } -} - -void icache_inval_range(unsigned long start, unsigned long end) -{ - unsigned long line_size; - - line_size = CACHE_LINE_SIZE(ICACHE); - while (end > start) { - __asm__ volatile ("\n\tcctl %0, L1I_VA_INVAL" : : "r"(start)); - start += line_size; - } -} - -void flush_cache(unsigned long addr, unsigned long size) -{ - dcache_flush_range(addr, addr + size); - icache_inval_range(addr, addr + size); -} - -void icache_enable(void) -{ - __asm__ __volatile__ ( - "mfsr $p0, $mr8\n\t" - "ori$p0, $p0, 0x01\n\t" - "mtsr $p0, $mr8\n\t" - "isb\n\t" - ); -} - -void icache_disable(void) -{ - __asm__ __volatile__ ( - "mfsr $p0, $mr8\n\t" - "li $p1, ~0x01\n\t" - "and$p0, $p0, $p1\n\t" - "mtsr $p0, $mr8\n\t" - "isb\n\t" - ); -} - -int icache_status(void) -{ - int ret; - -__asm__ __volatile__ ( - "mfsr $p0, $mr8\n\t" - "andi %0, $p0, 0x01\n\t" - : "=r" (ret) - : - : "memory" - ); - -return ret; -} - -void dcache_enable(void) -{ -__asm__ __volatile__ ( - "mfsr $p0, $mr8\n\t" - "ori$p0, $p0, 0x02\n\t" - "mtsr $p0, $mr8\n\t" - "isb\n\t" - ); -} - -void dcache_disable(void) -{ -__asm__ __volatile__ ( - "mfsr $p0, $mr8\n\t" - "li $p1, ~0x02\n\t" - "and$p0, $p0, $p1\n\t" - "mtsr $p0, $mr8\n\t" - "isb\n\t" - ); -} - -int dcache_status(void) -{ - int ret; - - __asm__ __volatile__ ( - "mfsr $p0, $mr8\n\t" - "andi %0, $p0, 0x02\n\t" - : "=r" (ret) - : - : "memory" -); - -return ret; -} diff --git a/arch/nds32/cpu/n1213/ag102/cpu.c b/arch/nds32/cpu/n1213/ag102/cpu.c index ed88b52..252b69d 100644 --- a/arch/nds32/cpu/n1213/ag102/cpu.c +++ b/arch/nds32/cpu/n1213/ag102/cpu.c @@ -81,115 +81,3 @@ int do_reset(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) /*NOTREACHED*/ } - -static inline unsigned long CACHE_LINE_SIZE(enum cache_t cache) -{ - if (cache == ICACHE) - return 8 << (((GET_ICM_CFG() & ICM_CFG_MSK_ISZ) \ - >> ICM_CFG_OFF_ISZ) - 1); - else - return 8 << (((GET_DCM_CFG() & DCM_CFG_MSK_DSZ) \ - >> DCM_CFG_OFF_DSZ) - 1); -} - -void dcache_flush_range(unsigned long start, unsigned long end) -{ - unsigned long line_size; - - line_size = CACHE_LINE_SIZE(DCACHE); - - while (end > start) { - __asm__ volatile ("\n\tcctl %0, L1D_VA_WB" : : "r"(start)); - __asm__ volatile ("\n\tcctl %0, L1D_VA_INVAL" : : "r"(start)); - start += line_size; - } -} - -void icache_inval_range(un
[U-Boot] [PATCH v2] i.MX28: use a clear name for DDR2 initialization
The mx28 prefix has been added to the initialization data and function so it is clear by which SoC it is used as i.MX233 will have a specific one. While on that, we also change it to static. Signed-off-by: Otavio Salvador --- Changes in v2: - use static for the allocation of memory initialization matrix arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c b/arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c index e17a4d7..cca1316 100644 --- a/arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c +++ b/arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c @@ -31,7 +31,7 @@ #include "mx28_init.h" -uint32_t dram_vals[] = { +static uint32_t mx28_dram_vals[] = { 0x, 0x, 0x, 0x, 0x, 0x, 0x, 0x, 0x, 0x, 0x, 0x, @@ -88,14 +88,14 @@ void __mx28_adjust_memory_params(uint32_t *dram_vals) void mx28_adjust_memory_params(uint32_t *dram_vals) __attribute__((weak, alias("__mx28_adjust_memory_params"))); -void init_m28_200mhz_ddr2(void) +void init_mx28_200mhz_ddr2(void) { int i; - mx28_adjust_memory_params(dram_vals); + mx28_adjust_memory_params(mx28_dram_vals); - for (i = 0; i < ARRAY_SIZE(dram_vals); i++) - writel(dram_vals[i], MXS_DRAM_BASE + (4 * i)); + for (i = 0; i < ARRAY_SIZE(mx28_dram_vals); i++) + writel(mx28_dram_vals[i], MXS_DRAM_BASE + (4 * i)); } void mx28_mem_init_clock(void) @@ -230,7 +230,7 @@ void mx28_mem_init(void) /* Clear START bit from DRAM_CTL16 */ clrbits_le32(MXS_DRAM_BASE + 0x40, 1); - init_m28_200mhz_ddr2(); + init_mx28_200mhz_ddr2(); /* Clear SREFRESH bit from DRAM_CTL17 */ clrbits_le32(MXS_DRAM_BASE + 0x44, 1); -- 1.7.10.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/17] tegra: Add display driver and LCD support for Seaboard
On Sat, Jul 14, 2012 at 10:03:31AM +0200, Simon Glass wrote: > Hi Christian, > > On Thu, Apr 19, 2012 at 2:41 PM, Christian Kroehnert > wrote: > > On 15.01.2012 01:47, Simon Glass wrote: > >> > >> This series adds support for the Tegra2x's display peripheral. This > >> supports the LCD display on Seaboard and we use this to enable console > >> output in U-Boot on the LCD. > >> > >> Configuration is via the device tree. Proposed bindings are included > >> in this series. > >> > >> To improve performance two optimisations are offered: > >> > >> 1. The LCD frame buffer is cached, with the cache being flushed after > >> each call puts(). This dramatically increases performance (around 10x). > >> This requires a few additions to the ARM cache support. > >> > >> 2. The console supports scrolling in steps of more than 1 line. This > >> speeds up scrolling output considerably, particularly commands like > >> 'printenv' which display a lot of output. This requires a new CONFIG > >> and a change to the console_scrollup() function. > >> > >> > >> Mayuresh Kulkarni (1): > >>tegra: Enable display/lcd support on Seaboard > >> > >> Simon Glass (15): > >>fdt: Add function to look up a phandle's register address > >>fdt: Add header guard to fdtdec.h > >>fdt: Correct GPIO name access in fdtdec > >>tegra: Add display support to funcmux > >>tegra: fdt: Add LCD definitions for Tegra > >>tegra: Add support for PWFM > >>tegra: Add LCD driver > >>tegra: Add LCD support to Nvidia boards > >>arm: Add control over cachability of memory regions > >>lcd: Add CONFIG_ALIGN_LCD_TO_SECTION to align lcd for MMU > >>lcd: Add support for flushing LCD fb from dcache after update > >>tegra: Align LCD frame buffer to section boundary > >>tegra: Support control of cache settings for LCD > >>tegra: fdt: Add LCD definitions for Seaboard > >>lcd: Add CONSOLE_SCROLL_LINES option to speed console > >> > >> Wei Ni (1): > >>tegra: Add SOC support for display/lcd > >> > >> README | 16 + > >> arch/arm/cpu/armv7/cache_v7.c | 11 + > >> arch/arm/cpu/armv7/tegra2/Makefile |1 + > >> arch/arm/cpu/armv7/tegra2/display.c | 271 +++ > >> arch/arm/cpu/armv7/tegra2/funcmux.c | 39 ++ > >> arch/arm/cpu/armv7/tegra2/pwfm.c| 40 ++ > >> arch/arm/dts/tegra20.dtsi | 25 + > >> arch/arm/include/asm/arch-tegra2/dc.h | 544 > >> +++ > >> arch/arm/include/asm/arch-tegra2/display.h | 133 ++ > >> arch/arm/include/asm/arch-tegra2/pwfm.h | 54 +++ > >> arch/arm/include/asm/system.h | 30 ++ > >> arch/arm/lib/cache-cp15.c | 62 +++- > >> board/nvidia/common/board.c | 21 +- > >> board/nvidia/dts/tegra2-seaboard.dts| 21 + > >> common/cmd_echo.c |3 +- > >> common/lcd.c| 85 +++- > >> doc/device-tree-bindings/video/nvidia-video.txt | 92 > >> drivers/video/Makefile |1 + > >> drivers/video/tegra.c | 388 > >> include/configs/seaboard.h | 12 +- > >> include/configs/tegra2-common.h |1 + > >> include/fdtdec.h| 17 + > >> include/lcd.h | 11 + > >> lib/fdtdec.c| 15 +- > >> 24 files changed, 1862 insertions(+), 31 deletions(-) > >> create mode 100644 arch/arm/cpu/armv7/tegra2/display.c > >> create mode 100644 arch/arm/cpu/armv7/tegra2/pwfm.c > >> create mode 100644 arch/arm/include/asm/arch-tegra2/dc.h > >> create mode 100644 arch/arm/include/asm/arch-tegra2/display.h > >> create mode 100644 arch/arm/include/asm/arch-tegra2/pwfm.h > >> create mode 100644 doc/device-tree-bindings/video/nvidia-video.txt > >> create mode 100644 drivers/video/tegra.c > >> > > > > Hi Simon, > > > > I have added your patch sources manually into the "Prepare v2012.04-rc1 > > release", because I got errors at apply. Also I added a device tree source > > file for Harmony. > > > > I tested the device tree source file for Harmony and your patch sources on > > our Harmony hardware and generated a new patch file: > > > > http://poeggi.dotsec.net/nvidia/uboot-lvds-init-patch/0001-Add-display-driver-and-LCD-support-for-Harmony-board.patch > > > > I hope it's all okay, this my first patch release. > > > > In the display.c source file I implemented a bug fix, because I get garbled > > images on the LCD without this fix. > > I see this code: > > u32 m_value; > > m_value = readl(0x54202e04); > m_value &= ~0x2; > writel(m_value, 0x54202e04); > > What register are you actually writing here? I can't f
Re: [U-Boot] [PATCH V2 3/8] ehci-hcd.c, musb_core, usb.h: Add USB_DMA_MINALIGN define for cache alignment
Dear Marek, On Mon, Jul 16, 2012 at 2:47 PM, Marek Vasut wrote: > > > ok, I finally managed to fix it. Will post the patches in a few seconds. > > > So the link I sent you was true afterall ? :) > Not exactly ;) Actually I've already switched to another task but when I went to bed one idea came to my mind and I decided to try it. What was the problem? I'll pick the patches for -next though, unless we're > 100% > definitelly sure they won't break anything else. > It looks like the controller could stop at the second QH structure (the one we allocated on stack) on the end of transfer. So on the next function call it started with the incorrect QH if address of qh was changed. Regards, Ilya. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/7] HACK: rearrange link order for thumb
On Thu, Jul 12, 2012 at 11:45:18AM -0700, Albert ARIBAUD wrote: > Hi Graeme, > > On Tue, 10 Jul 2012 10:57:39 +1000, Graeme Russ wrote: > > Hi Allen > > > > On Tue, Jul 10, 2012 at 10:45 AM, Allen Martin wrote: > > > On Sat, Jul 07, 2012 at 03:15:36AM -0700, Albert ARIBAUD wrote: > > >> Hi Allen, > > >> > > >> On Fri, 6 Jul 2012 16:17:19 -0700, Allen Martin > > >> wrote: > > > > [snip] > > > > >> > And I forgot to mention, the code bloat from disabling the > > >> > optimization is about 400 bytes (185136 -> 185540), so it's not bad, > > >> > but it still seems a shame to disable all short branches because of > > >> > one misoptimized one. > > > > 0.2% be my calcs > > > > >> > > >> Can this not be limited to compiling the object files which are known to > > >> be > > >> sensitive to the problem? > > >> > > > > > > I understand this issue fairly well now. It's a known bug in the > > > assembler that has already been fixed: > > > > > > http://sourceware.org/bugzilla/show_bug.cgi?id=12532 > > > > > > It only impacts preembtable symbols, and since u-boot doesn't have any > > > dynamic loadable objects it's only explictly defined weak symbols that > > > should trigger the bug. > > > > > > I built a new toolchain with binutils 2.22 and verified the bug is no > > > longer present there, and -fno-optimize-sibling-calls is the correct > > > workaround for toolchains that do have the bug, so conditionally > > > disabling the optimization for binutils < 2.22 seems like the right > > > fix. > > > > > > I ran a quick scrub of the u-boot tree and there's 195 instances of > > > __attribute__((weak)) spread across 123 source files, so I think just > > > disabling optimization on the failing object files may be too fragile, > > > as code movement could cause others to crop up. > > > > Adding -fno-optimize-sibling-calls for binutils < 2.22 - 0.2% code size > > increase for people using slightly older tools > > > > Maintain the tweaking of a set of files - someone using binutils >= 2.22 > > adds __attribute__((weak)) to a single function and *BAM* three months > > later someone complains that something broke > > > > I vote option 1 > > > > I do wonder, though, if we should spit out warnings when applying > > workaraounds for older tool-chains? > > I am against this idea: this persistent warning will either worry or > anoy the reader, neither of which is good IMO. OTOH, when in the future > the workaround is removed because the toolchain version it fixes is > considered obsolete, *then* we shall add a warning to let developers > know that they use an *unsupported* binutils version. > > Meanwhile, we could mark the workaround with a FIXME note in the code, > for present and future U-Boot *developers* to notice and remember > what they should do with this workaround. :) I'm ok with either way, I added the warning at Graeme's suggestion. I'll send another patch series with a FIXME comment and the warning removed and let you guys fight it out :^) -Allen -- nvpublic ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v7 00/15] split tegra20 arm7 code into separate SPL
Allen, > -Original Message- > From: Allen Martin [mailto:amar...@nvidia.com] > Sent: Monday, July 16, 2012 4:02 PM > To: Tom Warren; swar...@wwwdotorg.org; s...@chromium.org; > thierry.red...@avionic-design.de > Cc: u-boot@lists.denx.de; Allen Martin > Subject: [PATCH v7 00/15] split tegra20 arm7 code into separate SPL > > This patch series fixes a long standing problem with the tegra20 u-boot > build. Tegra20 contains an ARM7TDMI boot processor and a Cortex A9 main > processor. Prior to this patch series this was accomplished by #ifdefing > out any armv7 code from the early boot sequence and creating a single binary > that runs on both both the ARM7TDMI and A9. This was very fragile as > changes to compiler options or any additions or rearranging of the early > boot code could add additional armv7 specific code causing it to fail on the > ARM7TDMI. > > This patch series pulls all the armv4t code out into a separate SPL that > does nothing more than initialize the A9 and transfer control to it. The > resultint SPL and armv7 u-boot are concatenated together into a single > image. > > This patch series is also available from: > git://github.com/arm000/u-boot.git > branch: tegra-spl-v7 > Applied to u-boot-tegra/next AOK, tested on my Seaboard AOK, so: Tested-by: Tom Warren Note that I was confused by the final binary name (u-boot-dtb-tegra.bin), since I'm used to flashing u-boot-dtb.bin. We need to come to a consensus about the final binary name for Tegra U-Boot (I'd thought we had, and that it would be u-boot-dtb.bin, since that's what most devs are used to looking for in Tegra builds). Also, one nit: I see the 2 sign-on strings (U-Boot SPL 2012.04.xxx, and then U-Boot 2012.04.xxx), separated by 2 lines. I think it'd look better if you had them one right after the other, i.e. eliminate the extra linefeeds. Tom > Changes: > v7: > - rebased to u-boot-tegra/next > - added Acks and Tested-Bys > v6: > - changed combined SPL/u-boot target names to u-boot-dtb-tegra.bin and u- > boot-nodtb-tegra.bin > - fixed regression introduced in v5 that caused git bisect to fail to > build at one of the patches > - fix USE_PRIVATE_LIBGCC for SPL build and enable it > - fix libtegra20-common.so link so it works if building with out of tree > OBJDIR > v5: > - added missing mkdir rules in all tegra20 board Makefiles that include > common code and changed them to be unconditional > - make new u-boot-dtb-t2.bin rule default for tegra20 and copy resulting > binary over u-boot.bin > v4: > - rebased to u-boot-tegra/next > - reordered entire patch series to preserve git bisect, verified build and > boot at each patch > - merged patches that add SPL config defines and removes duplicate code > from u-boot init, these have to go in atomically to preserve building at > each patch > - fixed compiler warnings introduced > - fixed blank line at end of file on cpu.c > - renamed u-boot.t2 to u-boot-t2.bin > - cleaned up config.mk generation in mkconfig to make it more readable > - added some text to clarify using arm720t code for arm7tdmi > - rearranged SPL memory map to make resulting SPL + u-boot image much > smaller > - removed separate PAD_TO define in favor of just using > CONFIG_SYS_TEXT_BASE > - moved warmboot_save_sdram_params() from dram_init() to board_init() > v3: > - git bisect still does not work across this series, I'm saving that for > the next revision, but I had enough changes that I wanted to get this out > for review > - expanded the tegra2 -> tegra20 rename to include functions/variables/ > defines > - rebased to u-boot-tegra/next > - removed some extra -march=armv4t flags, kept armv4t flags on > warmboot_avp since it's special > - removed bashisms from mkconfig > - renamed CONFIG_MACH_TEGRA_GENERIC to CONFIG_TEGRA > - moved SPL overrides to tegra2-common-post.h > - changed SPL base address to 0x108000, u-boot goes to 0x208000 > - moved warboot_save_sdram_params fix to separate patch > - remove USE_PRIVATE_LIBGCC from non SPL build > - expanded SPL support to all tegra20 boards, not just seaboard > v2: > - renamed tegra2 to tegra20 to match kernel and devicetree naming policy > - pulled all SPL related config overrides to a separate file to clean up > ifdefs from seabard.h > - rebased to TOT u-boot/master and fixed a bug related to init sequence > changes between this patch series and new EMC code > - made u-boot.t2 target work even if CONFIG_OF is disabled > - added back USE_PRIVATE_LIBGCC > > Allen Martin (15): > tegra20: rename tegra2 -> tegra20 > tegra20: move tegra20 SoC code to arch/arm/cpu/tegra20-common > tegra20: rename CONFIG_MACH_TEGRA_GENERIC > tegra20: tec: add tegra20-common-post.h > tegra20: make board mkdir commands unconditional > mkconfig: add support for SPL CPU > ARM: Fix arm720t SPL build > tegra20: remove timer_init from SPL build > ARM: add tegra20 support to arm720t > tegra20: add u-boot-*-tegra.bin targets >
Re: [U-Boot] [PATCH] mx6: Make pad name macro consistent with the datasheet
On 11/07/2012 08:39, Dirk Behme wrote: > On 07.07.2012 18:54, Stefano Babic wrote: >> On 15/06/2012 15:48, Ashok wrote: >>> >>> Hi Dirk, >>> Use the same name as defined in the datasheet. >>> DSP_CLK -> DISP_CLK >>> >>> Signed-off-by: Ashok Kumar Reddy Kourla >>> --- >> >> Applied to u-boot-imx, thanks. > > Hmm, this isn't part of v2012.07-rc1? Sorry if I missed something. It is not, I applied it after -rc1. Cheers, 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 0/17] tegra: Add display driver and LCD support for Seaboard
+Tom, Stephen On Tue, Jul 17, 2012 at 5:11 PM, Thierry Reding wrote: > On Sat, Jul 14, 2012 at 10:03:31AM +0200, Simon Glass wrote: >> Hi Christian, >> >> On Thu, Apr 19, 2012 at 2:41 PM, Christian Kroehnert >> wrote: >> > On 15.01.2012 01:47, Simon Glass wrote: >> >> >> >> This series adds support for the Tegra2x's display peripheral. This >> >> supports the LCD display on Seaboard and we use this to enable console >> >> output in U-Boot on the LCD. >> >> >> >> Configuration is via the device tree. Proposed bindings are included >> >> in this series. >> >> >> >> To improve performance two optimisations are offered: >> >> >> >> 1. The LCD frame buffer is cached, with the cache being flushed after >> >> each call puts(). This dramatically increases performance (around 10x). >> >> This requires a few additions to the ARM cache support. >> >> >> >> 2. The console supports scrolling in steps of more than 1 line. This >> >> speeds up scrolling output considerably, particularly commands like >> >> 'printenv' which display a lot of output. This requires a new CONFIG >> >> and a change to the console_scrollup() function. >> >> >> >> >> >> Mayuresh Kulkarni (1): >> >>tegra: Enable display/lcd support on Seaboard >> >> >> >> Simon Glass (15): >> >>fdt: Add function to look up a phandle's register address >> >>fdt: Add header guard to fdtdec.h >> >>fdt: Correct GPIO name access in fdtdec >> >>tegra: Add display support to funcmux >> >>tegra: fdt: Add LCD definitions for Tegra >> >>tegra: Add support for PWFM >> >>tegra: Add LCD driver >> >>tegra: Add LCD support to Nvidia boards >> >>arm: Add control over cachability of memory regions >> >>lcd: Add CONFIG_ALIGN_LCD_TO_SECTION to align lcd for MMU >> >>lcd: Add support for flushing LCD fb from dcache after update >> >>tegra: Align LCD frame buffer to section boundary >> >>tegra: Support control of cache settings for LCD >> >>tegra: fdt: Add LCD definitions for Seaboard >> >>lcd: Add CONSOLE_SCROLL_LINES option to speed console >> >> >> >> Wei Ni (1): >> >>tegra: Add SOC support for display/lcd >> >> >> >> README | 16 + >> >> arch/arm/cpu/armv7/cache_v7.c | 11 + >> >> arch/arm/cpu/armv7/tegra2/Makefile |1 + >> >> arch/arm/cpu/armv7/tegra2/display.c | 271 +++ >> >> arch/arm/cpu/armv7/tegra2/funcmux.c | 39 ++ >> >> arch/arm/cpu/armv7/tegra2/pwfm.c| 40 ++ >> >> arch/arm/dts/tegra20.dtsi | 25 + >> >> arch/arm/include/asm/arch-tegra2/dc.h | 544 >> >> +++ >> >> arch/arm/include/asm/arch-tegra2/display.h | 133 ++ >> >> arch/arm/include/asm/arch-tegra2/pwfm.h | 54 +++ >> >> arch/arm/include/asm/system.h | 30 ++ >> >> arch/arm/lib/cache-cp15.c | 62 +++- >> >> board/nvidia/common/board.c | 21 +- >> >> board/nvidia/dts/tegra2-seaboard.dts| 21 + >> >> common/cmd_echo.c |3 +- >> >> common/lcd.c| 85 +++- >> >> doc/device-tree-bindings/video/nvidia-video.txt | 92 >> >> drivers/video/Makefile |1 + >> >> drivers/video/tegra.c | 388 >> >> include/configs/seaboard.h | 12 +- >> >> include/configs/tegra2-common.h |1 + >> >> include/fdtdec.h| 17 + >> >> include/lcd.h | 11 + >> >> lib/fdtdec.c| 15 +- >> >> 24 files changed, 1862 insertions(+), 31 deletions(-) >> >> create mode 100644 arch/arm/cpu/armv7/tegra2/display.c >> >> create mode 100644 arch/arm/cpu/armv7/tegra2/pwfm.c >> >> create mode 100644 arch/arm/include/asm/arch-tegra2/dc.h >> >> create mode 100644 arch/arm/include/asm/arch-tegra2/display.h >> >> create mode 100644 arch/arm/include/asm/arch-tegra2/pwfm.h >> >> create mode 100644 doc/device-tree-bindings/video/nvidia-video.txt >> >> create mode 100644 drivers/video/tegra.c >> >> >> > >> > Hi Simon, >> > >> > I have added your patch sources manually into the "Prepare v2012.04-rc1 >> > release", because I got errors at apply. Also I added a device tree source >> > file for Harmony. >> > >> > I tested the device tree source file for Harmony and your patch sources on >> > our Harmony hardware and generated a new patch file: >> > >> > http://poeggi.dotsec.net/nvidia/uboot-lvds-init-patch/0001-Add-display-driver-and-LCD-support-for-Harmony-board.patch >> > >> > I hope it's all okay, this my first patch release. >> > >> > In the display.c source file I implemented a bug fix, because I get garbled >> > images on the LCD without this fix. >> >> I see this code: >> >> u3
Re: [U-Boot] Please pull u-boot-mmc.git
Dear Andy Fleming, In message <1342217893-5896-1-git-send-email-aflem...@freescale.com> you wrote: > Merge branch 'master' of git://git.denx.de/u-boot-i2c (2012-07-12 08:17= > :29 +0200) > > are available in the git repository at: > > git://www.denx.de/git/u-boot-mmc.git master > > Eric Nelson (1): > i.MX: fsl_esdhc: allow use with cache enabled. > > Jaehoon Chung (1): > mmc: remove the hard setting for tran_speed > > Jerry Huang (2): > SD/MMC: check the card status during erase operation > FSL/eSDHC: enable the clock to detect the SD card > > =C5=81ukasz Majewski (1): > mmc:fix Call mmc_init() when executing mmc_get_dev() > > drivers/mmc/fsl_esdhc.c | 20 +++- > drivers/mmc/mmc.c | 23 --- > 2 files changed, 35 insertions(+), 8 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Vulcans believe peace should not depend on force. -- Amanda, "Journey to Babel", stardate 3842.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-nios/master
Dear Thomas Chou, In message <5004c6ef.3060...@wytron.com.tw> you wrote: > On 04/24/2012 09:38 AM, thomas wrote: > > The following changes since commit 61ddce07f8b96c5df7d00466b4da9edaecb0eff1: > > > >sandbox: Use the new run_command() (2012-04-23 22:53:54 +0200) > > > > are available in the git repository at: > >git://git.denx.de/u-boot-nios.git master > > > > Thomas Chou (1): > >nios2: move gd and bd into BSS > > > > arch/nios2/lib/board.c | 12 +--- > > include/configs/nios2-generic.h | 12 > > 2 files changed, 9 insertions(+), 15 deletions(-) > > Dear Wolfgang, > > Please handle this pull request. It was missed. I have rebased it > against rc1. Thanks. Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Intuition, however illogical, is recognized as a command prerogative. -- Kirk, "Obsession", stardate 3620.7 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot