Re: [U-Boot] [PATCH] arm: ea20: Change macro from BOARD_LATE_INIT to CONFIG_BOARD_LATE_INIT
Le 19/04/2012 08:44, Albert ARIBAUD a écrit : Hi Nobuhiro Iwamatsu, Le 18/04/2012 04:41, Nobuhiro Iwamatsu a écrit : With almost all the architecture and board BOARD_LATE_INIT does not use. CONFIG_BOARD_LATE_INIT is used instead. This changed CONFIG_BOARD_LATE_INIT from BOARD_LATE_INIT. I think the commit message above is redundant with the commit summary, especially for a trivial one-line change. Can you just post a V2 patch with the same code change and commit summary, but without the commit message? ... actually, you could apply this to all your elementary patches re BOARD_LATE_INIT, and then submit them in a single patch set. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: ea20: Change macro from BOARD_LATE_INIT to CONFIG_BOARD_LATE_INIT
Hi Nobuhiro Iwamatsu, Le 18/04/2012 04:41, Nobuhiro Iwamatsu a écrit : With almost all the architecture and board BOARD_LATE_INIT does not use. CONFIG_BOARD_LATE_INIT is used instead. This changed CONFIG_BOARD_LATE_INIT from BOARD_LATE_INIT. I think the commit message above is redundant with the commit summary, especially for a trivial one-line change. Can you just post a V2 patch with the same code change and commit summary, but without the commit message? Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] fix IDE_BUS(dev) macro
Hi Dave, Le 18/04/2012 23:37, David Purdy a écrit : On Tue, Apr 17, 2012 at 2:06 PM, Luka Perkov wrote: IDE_BUS assumes that each bus has two devices and thus returns the first bus even when the second one should be probed. Signed-off-by: Simon Baatz Tested-by: Luka Perkov --- Simon discovered this while adding support for new board IB NAS6210. More info can be found here: http://lists.denx.de/pipermail/u-boot/2012-April/122525.html When this is commited I will do a coding style cleanup. There are tabs after few "#define" parts in include/ide.h. include/ide.h |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/ide.h b/include/ide.h index 8ecc9dd..385e909 100644 --- a/include/ide.h +++ b/include/ide.h @@ -24,7 +24,7 @@ #ifndef_IDE_H Simon, Luka, Prafulla, etal, I've tested this out on the Seagate GoFlex Net (Kirkwood) device, which also has dual SATA ports, and it resolved the long-standing (and irritating) bug/unwanted-feature that required us to boot from _only_ the right side port. I would guess that other Kirkwood dual-SATA-port boxes would be happier because of this, as well. Nice catch, Simon. Not my main area of expertise here, but I am not sure how this plays on Marvell non-kirkwood platforms (e.g., orion5x). ISTR it is not the first time we deal with the whole IDE number of bus / number of ports [ / useable ports ] issue, and we may be running in circles here, fixing one platform and breaking another. I'll try this on EDMiniV2 in the coming days, and let people know the results in this thread. regards, Dave Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2] fs/fat: align disk buffers on cache line to enable DMA and cache
On 27.03.2012 18:28, Dirk Behme wrote:
On 27.03.2012 16:20, Anatolij Gustschin wrote:
Hello Dirk,
On Sat, 24 Mar 2012 08:18:38 +0100
Dirk Behme wrote:
On 13.03.2012 02:24, Eric Nelson wrote:
On 03/04/2012 02:46 PM, Eric Nelson wrote:
Signed-off-by: Eric Nelson
Acked-by: Mike Frysinger
---
fs/fat/fat.c | 14 --
1 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/fs/fat/fat.c b/fs/fat/fat.c
index 1f95eb4..f3c48bb 100644
--- a/fs/fat/fat.c
+++ b/fs/fat/fat.c
@@ -31,6 +31,8 @@
#include
#include
#include
+#include
+#include
/*
* Convert a string to lowercase.
@@ -62,7 +64,7 @@ static int disk_read(__u32 block, __u32 nr_blocks,
void *buf)
int fat_register_device (block_dev_desc_t * dev_desc, int part_no)
{
- unsigned char buffer[dev_desc->blksz];
+ ALLOC_CACHE_ALIGN_BUFFER(unsigned char, buffer, dev_desc->blksz);
>
Hi Wolfgang,
Have you had a chance to review this patch? Is there another
maintainer for fs/fat?
Please let me know if you need this updated.
There's another patch that was acked by Mike but is otherwise
lingering here:
http://lists.denx.de/pipermail/u-boot/2012-March/119309.html
Both of these are needed before enabling the data cache on i.MX6 when
using
the FAT filesystem.
Anybody likes to comment/apply this patch?
Both, this patch and the patch referenced by the above link were
submitted when the merge window was closed. So, the patches will
probably be applied to next when rc1 is out, unless Wolfgang
decides to accept them for coming release.
Ok, thanks!
Do we have a -next branch for stuff like this, then?
There should be a -next from Wolfgang for
http://patchwork.ozlabs.org/patch/144462/
http://patchwork.ozlabs.org/patch/151799/
now :)
Best regards
Dirk
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] e1000e : Set Receive Threshold granularity to number of
Dear Ruchika Gupta, In message <1334834928-27157-1-git-send-email-ruchika.gu...@freescale.com> you wrote: > In RXDCTL register, WTHRESH controls the write back of processed receive > descriptors. WTHRESH controls the write back of processed receive > descriptors. ... Please fix both the Subject (which is truncated and too long anyway) and the commit message (which is redundant). 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 Microsoft Multitasking: several applications can crash at the same time. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] e1000e : Set Receive Threshold granularity to number of
In RXDCTL register, WTHRESH controls the write back of processed receive
descriptors. WTHRESH controls the write back of processed receive
descriptors. This threshold refers to the number of receive
descriptors in the Ethernet controllers on-chip buffer which are
ready to be written back to host memory. In the absence of
external events (explicit flushes), the write back occurs only after
more than WTHRESH descriptors are available for write back.
A value of WTHRESH can be in either cache line units, or based on
number of descriptors based on RXDCTL.GRAN. By default it is set to
cache line granularoty.
In e1000e driver, receive descriptor queue is configured such that
hardware can add only 1 descriptor at a time. So the WTHRESH granularity
should be set to single descriptor. This would ensure that every time
controller fills a Rx descriptor, it is flushed to host memory.
This change fixes timeout which was seen when tftping large files.
Signed-off-by: Ruchika Gupta
Signed-off-by: Vakul Garg
Acked-by: Roy Zang
---
drivers/net/e1000.c | 10 ++
drivers/net/e1000.h |1 +
2 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/drivers/net/e1000.c b/drivers/net/e1000.c
index 98145bc..1f3c2b0 100644
--- a/drivers/net/e1000.c
+++ b/drivers/net/e1000.c
@@ -1703,6 +1703,16 @@ e1000_init_hw(struct eth_device *nic)
E1000_WRITE_REG(hw, TXDCTL, ctrl);
}
+ /* Set the receive descriptor write back policy */
+
+ if (hw->mac_type >= e1000_82571) {
+ ctrl = E1000_READ_REG(hw, RXDCTL);
+ ctrl =
+ (ctrl & ~E1000_RXDCTL_WTHRESH) |
+ E1000_RXDCTL_FULL_RX_DESC_WB;
+ E1000_WRITE_REG(hw, RXDCTL, ctrl);
+ }
+
switch (hw->mac_type) {
default:
break;
diff --git a/drivers/net/e1000.h b/drivers/net/e1000.h
index 720d8c6..cdb0e36 100644
--- a/drivers/net/e1000.h
+++ b/drivers/net/e1000.h
@@ -1518,6 +1518,7 @@ struct e1000_hw {
#define E1000_RXDCTL_HTHRESH 0x3F00/* RXDCTL Host Threshold */
#define E1000_RXDCTL_WTHRESH 0x003F/* RXDCTL Writeback Threshold */
#define E1000_RXDCTL_GRAN0x0100/* RXDCTL Granularity */
+#define E1000_RXDCTL_FULL_RX_DESC_WB 0x0101/* GRAN=1, WTHRESH=1 */
/* Transmit Descriptor Control */
#define E1000_TXDCTL_PTHRESH 0x003F/* TXDCTL Prefetch Threshold */
--
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] powerpc/85xx: Add USB device-tree fixup for various platforms
> -Original Message- > From: Andy Fleming [mailto:aflem...@gmail.com] > Sent: Thursday, April 19, 2012 2:17 AM > To: Mehresh Ramneek-B31383 > Cc: u-boot@lists.denx.de; Fleming Andy-AFLEMING > Subject: Re: [U-Boot] [PATCH] powerpc/85xx: Add USB device-tree fixup for > various platforms > > On Mon, Mar 26, 2012 at 9:15 AM, Ramneek Mehresh > > wrote: > > Add USB device-tree fixup for following platforms: > > MPC8536DS, P1022DS, P1023RDS, P2020COME, P2020DS, P2041RDB, P3060QDS > > > > Signed-off-by: Ramneek Mehresh > > --- > > diff --git a/board/freescale/p2020come/p2020come.c > > b/board/freescale/p2020come/p2020come.c > > index 8cf7bee..ce78016 100644 > > --- a/board/freescale/p2020come/p2020come.c > > +++ b/board/freescale/p2020come/p2020come.c > > @@ -1,5 +1,5 @@ > > /* > > - * Copyright 2009 Freescale Semiconductor, Inc. > > + * Copyright 2009,2012 Freescale Semiconductor, Inc. > > * > > * See file CREDITS for list of people who contributed to this > > * project. > > @@ -282,6 +282,10 @@ void ft_board_setup(void *blob, bd_t *bd) > > > > fdt_fixup_memory(blob, (u64)base, (u64)size); > > > > +#ifdef CONFIG_HAS_FSL_DR_USB > > + fdt_fixup_dr_usb(blob, bd); > > +#endif > > + > > fdt_fixup_dr_usb(blob, bd); > > > Umm I don't think this is right. :) Thanks for pointing out ... will correct ... - Ramneek ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH][v2]powerpc/85xx: Add USB device-tree fixup for various platforms
Add USB device-tree fixup for following platforms: MPC8536DS, P1022DS, P1023RDS, P2020COME, P2020DS, P2041RDB, P3060QDS Signed-off-by: Ramneek Mehresh --- Changes for v2: - removed extra call to fdt_fixup_dr_usb() outside CONFIG_HAS_FSL_DR_USB macro for p2020come board/freescale/mpc8536ds/mpc8536ds.c |7 ++- board/freescale/p1022ds/p1022ds.c |6 +- board/freescale/p1023rds/p1023rds.c |6 +- board/freescale/p2020come/p2020come.c |4 +++- board/freescale/p2020ds/p2020ds.c |6 +- board/freescale/p2041rdb/p2041rdb.c |6 +- board/freescale/p3060qds/p3060qds.c |6 +- include/configs/MPC8536DS.h |5 - include/configs/P1022DS.h |5 - include/configs/P1023RDS.h|5 - include/configs/P2020COME.h |6 -- include/configs/P2020DS.h |5 - include/configs/P2041RDB.h|8 +++- include/configs/corenet_ds.h |8 ++-- 14 files changed, 67 insertions(+), 16 deletions(-) diff --git a/board/freescale/mpc8536ds/mpc8536ds.c b/board/freescale/mpc8536ds/mpc8536ds.c index c9f85c8..fb20192 100644 --- a/board/freescale/mpc8536ds/mpc8536ds.c +++ b/board/freescale/mpc8536ds/mpc8536ds.c @@ -1,5 +1,5 @@ /* - * Copyright 2008-2010, 2011 Freescale Semiconductor, Inc. + * Copyright 2008-2012 Freescale Semiconductor, Inc. * * See file CREDITS for list of people who contributed to this * project. @@ -295,5 +295,10 @@ void ft_board_setup(void *blob, bd_t *bd) #ifdef CONFIG_FSL_SGMII_RISER fsl_sgmii_riser_fdt_fixup(blob); #endif + +#ifdef CONFIG_HAS_FSL_MPH_USB + fdt_fixup_dr_usb(blob, bd); +#endif + } #endif diff --git a/board/freescale/p1022ds/p1022ds.c b/board/freescale/p1022ds/p1022ds.c index 456d9b0..f9ba1f8 100644 --- a/board/freescale/p1022ds/p1022ds.c +++ b/board/freescale/p1022ds/p1022ds.c @@ -1,5 +1,5 @@ /* - * Copyright 2010-2011 Freescale Semiconductor, Inc. + * Copyright 2010-2012 Freescale Semiconductor, Inc. * Authors: Srikanth Srinivasan * Timur Tabi * @@ -341,6 +341,10 @@ void ft_board_setup(void *blob, bd_t *bd) fdt_fixup_memory(blob, (u64)base, (u64)size); +#ifdef CONFIG_HAS_FSL_DR_USB + fdt_fixup_dr_usb(blob, bd); +#endif + FT_FSL_PCI_SETUP; #ifdef CONFIG_FSL_SGMII_RISER diff --git a/board/freescale/p1023rds/p1023rds.c b/board/freescale/p1023rds/p1023rds.c index 546819c..2f87583 100644 --- a/board/freescale/p1023rds/p1023rds.c +++ b/board/freescale/p1023rds/p1023rds.c @@ -1,5 +1,5 @@ /* - * Copyright 2010-2011 Freescale Semiconductor, Inc. + * Copyright 2010-2012 Freescale Semiconductor, Inc. * * Authors: Roy Zang * Chunhe Lan @@ -197,6 +197,10 @@ void ft_board_setup(void *blob, bd_t *bd) fdt_fixup_memory(blob, (u64)base, (u64)size); +#ifdef CONFIG_HAS_FSL_DR_USB + fdt_fixup_dr_usb(blob, bd); +#endif + fdt_fixup_fman_ethernet(blob); } #endif diff --git a/board/freescale/p2020come/p2020come.c b/board/freescale/p2020come/p2020come.c index 8cf7bee..ba4ef87 100644 --- a/board/freescale/p2020come/p2020come.c +++ b/board/freescale/p2020come/p2020come.c @@ -1,5 +1,5 @@ /* - * Copyright 2009 Freescale Semiconductor, Inc. + * Copyright 2009,2012 Freescale Semiconductor, Inc. * * See file CREDITS for list of people who contributed to this * project. @@ -282,6 +282,8 @@ void ft_board_setup(void *blob, bd_t *bd) fdt_fixup_memory(blob, (u64)base, (u64)size); +#ifdef CONFIG_HAS_FSL_DR_USB fdt_fixup_dr_usb(blob, bd); +#endif } #endif diff --git a/board/freescale/p2020ds/p2020ds.c b/board/freescale/p2020ds/p2020ds.c index d3af6cf..d9465f9 100644 --- a/board/freescale/p2020ds/p2020ds.c +++ b/board/freescale/p2020ds/p2020ds.c @@ -1,5 +1,5 @@ /* - * Copyright 2007-2011 Freescale Semiconductor, Inc. + * Copyright 2007-2012 Freescale Semiconductor, Inc. * * See file CREDITS for list of people who contributed to this * project. @@ -261,6 +261,10 @@ void ft_board_setup(void *blob, bd_t *bd) fdt_fixup_memory(blob, (u64)base, (u64)size); +#ifdef CONFIG_HAS_FSL_DR_USB + fdt_fixup_dr_usb(blob, bd); +#endif + FT_FSL_PCI_SETUP; #ifdef CONFIG_FSL_SGMII_RISER diff --git a/board/freescale/p2041rdb/p2041rdb.c b/board/freescale/p2041rdb/p2041rdb.c index 1f6a34b..51c4310 100644 --- a/board/freescale/p2041rdb/p2041rdb.c +++ b/board/freescale/p2041rdb/p2041rdb.c @@ -1,5 +1,5 @@ /* - * Copyright 2011 Freescale Semiconductor, Inc. + * Copyright 2011,2012 Freescale Semiconductor, Inc. * * See file CREDITS for list of people who contributed to this * project. @@ -215,6 +215,10 @@ void ft_board_setup(void *blob, bd_t *bd) fdt_fixup_memory(blob, (u64)base, (u64)size); +#if defined(CONFIG_HAS_FSL_DR_USB) || defined(CONFIG_HAS_FSL_MPH_USB) + fdt_fixup_dr_usb(blob, bd); +#endif + #ifdef CONFIG_PCI pci_of_setup(blob, bd); #end
Re: [U-Boot] [STATUS] v2012.04-rc2 and -rc3 are out
On 18.04.2012 23:10, Wolfgang Denk wrote: Hi everybody, sorry, I forgot to announce the 2012.04-rc2 pre-release two days ago, so I will atleast announce that we have v2012.04-rc3 now. Thanks :) Please help testing, so we can fix the remaining issues before the release, which I still want to push out April 21, 2012. Thanks to all who helped. Please make sure that all your important bug fixes have been included! http://patchwork.ozlabs.org/patch/145515/ Thanks Dirk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] usb showed wrong device count
Hi folks, After patch: usb: Add support for multiple-LUN mass storage devices The usb device count isn't correct. bfin> usb start (Re)start USB... USB: scanning bus for devices... 1 USB Device(s) found scanning bus for storage devices... max USB Storage Device reached: 5 stopping 5 Storage Device(s) found bfin> It used to be: bfin> usb start (Re)start USB... USB: scanning bus for devices... 1 USB Device(s) found scanning bus for storage devices... 1 USB Device(s) found bfin> Any idea? thanks. -- Regards, --Bob ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/usb: fix bug of CPU halt when missing USB PHY clock
Dear Andy Fleming, > Pinging you on this, again. Also, I've now moved the patch to Marek's > queue, instead of mine. Thanks! Did the FSL silicon team respond already? > > On Sun, Feb 26, 2012 at 8:44 PM, Liu Shengzhou-B36685 > > wrote: > >> -Original Message- > >> From: Marek Vasut [mailto:ma...@denx.de] > >> Sent: Monday, February 27, 2012 7:13 AM > >> To: u-boot@lists.denx.de > >> Cc: Liu Shengzhou-B36685 > >> Subject: Re: [U-Boot] [PATCH] powerpc/usb: fix bug of CPU halt when > >> missing USB PHY clock > >> > >> > when missing USB PHY clock and issuing "usb start" at u-boot prompt, > >> > writing to or_portsc register will cause CPU halt. We should check > >> > USBGP[PHY_CLK_VALID] bit at the first time in ehci_hcd_init() to > >> > >> avoid > >> > >> > CPU hang in this case. > >> > > >> > Signed-off-by: Shengzhou Liu > >> > --- > >> > drivers/usb/host/ehci-fsl.c | 22 +++--- > >> > 1 files changed, 19 insertions(+), 3 deletions(-) > >> > >> Hi, > >> > >> what's the status of this patch/patchset? > >> > >> Thanks > >> M > > > > Currently we found that usb CTRL_PHY_CLK_VALID bit breaks on P1022 > > platform, which not contains this bit. - P1023/P3041/P5020 etc, have > > this bit > > - P3060/4080/PSC913x do have this bit, but not mentioned in RM. > > - P1022(perhaps and other) has no this bit > > I'm waiting for the response from FSL silicon team to confirm whether > > there is other platform not including this bit or not, so this patch > > maybe have to be pending until I get confirmation. > > > > Thanks, > > Shengzhou > > > > > > ___ > > U-Boot mailing list > > U-Boot@lists.denx.de > > http://lists.denx.de/mailman/listinfo/u-boot Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/usb: fix bug of CPU halt when missing USB PHY clock
Pinging you on this, again. Also, I've now moved the patch to Marek's queue, instead of mine. On Sun, Feb 26, 2012 at 8:44 PM, Liu Shengzhou-B36685 wrote: > >> -Original Message- >> From: Marek Vasut [mailto:ma...@denx.de] >> Sent: Monday, February 27, 2012 7:13 AM >> To: u-boot@lists.denx.de >> Cc: Liu Shengzhou-B36685 >> Subject: Re: [U-Boot] [PATCH] powerpc/usb: fix bug of CPU halt when >> missing USB PHY clock >> >> > when missing USB PHY clock and issuing "usb start" at u-boot prompt, >> > writing to or_portsc register will cause CPU halt. We should check >> > USBGP[PHY_CLK_VALID] bit at the first time in ehci_hcd_init() to >> avoid >> > CPU hang in this case. >> > >> > Signed-off-by: Shengzhou Liu >> > --- >> > drivers/usb/host/ehci-fsl.c | 22 +++--- >> > 1 files changed, 19 insertions(+), 3 deletions(-) >> > >> Hi, >> >> what's the status of this patch/patchset? >> >> Thanks >> M > > Currently we found that usb CTRL_PHY_CLK_VALID bit breaks on P1022 platform, > which not contains this bit. > - P1023/P3041/P5020 etc, have this bit > - P3060/4080/PSC913x do have this bit, but not mentioned in RM. > - P1022(perhaps and other) has no this bit > I'm waiting for the response from FSL silicon team to confirm whether there > is other platform > not including this bit or not, so this patch maybe have to be pending until I > get confirmation. > > Thanks, > Shengzhou > > > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] tegra2: move tegra2 SoC code to arch/arm/cpu/tegra2-common
In preparation for splitting out the armv4t code from tegra2, move the
tegra2 SoC code to arch/arm/cpu/tegra2-common. This code will be
compiled armv4t for the arm7tdmi and armv7 for the cortex A9.
Signed-off-by: Allen Martin
---
Resending this with "git format-patch -M" to make it more readable
and removing cover letter
This is part of an upcoming patch set to move all armv4t code out of
tegra2 u-boot and put it into an SPL, but I wanted to get some early
feedback on this patch. This moves most of the tegra2 SoC code from
arch/arm/cpu/armv7 to a new directory arch/arm/cpu/tegra2-common.
This code will be shared between the armv7 and armv4t builds of
tegra2.
Makefile |3 +
arch/arm/cpu/armv7/tegra2/Makefile | 12 +
arch/arm/cpu/tegra2-common/Makefile| 56
.../arm/cpu/{armv7/tegra2 => tegra2-common}/ap20.c |0
.../arm/cpu/{armv7/tegra2 => tegra2-common}/ap20.h |0
.../cpu/{armv7/tegra2 => tegra2-common}/board.c|0
.../cpu/{armv7/tegra2 => tegra2-common}/clock.c|0
.../cpu/{armv7/tegra2 => tegra2-common}/funcmux.c |0
.../tegra2 => tegra2-common}/lowlevel_init.S |0
.../cpu/{armv7/tegra2 => tegra2-common}/pinmux.c |0
.../cpu/{armv7/tegra2 => tegra2-common}/sys_info.c |0
.../cpu/{armv7/tegra2 => tegra2-common}/timer.c|0
spl/Makefile |4 ++
13 files changed, 65 insertions(+), 10 deletions(-)
create mode 100644 arch/arm/cpu/tegra2-common/Makefile
rename arch/arm/cpu/{armv7/tegra2 => tegra2-common}/ap20.c (100%)
rename arch/arm/cpu/{armv7/tegra2 => tegra2-common}/ap20.h (100%)
rename arch/arm/cpu/{armv7/tegra2 => tegra2-common}/board.c (100%)
rename arch/arm/cpu/{armv7/tegra2 => tegra2-common}/clock.c (100%)
rename arch/arm/cpu/{armv7/tegra2 => tegra2-common}/funcmux.c (100%)
rename arch/arm/cpu/{armv7/tegra2 => tegra2-common}/lowlevel_init.S (100%)
rename arch/arm/cpu/{armv7/tegra2 => tegra2-common}/pinmux.c (100%)
rename arch/arm/cpu/{armv7/tegra2 => tegra2-common}/sys_info.c (100%)
rename arch/arm/cpu/{armv7/tegra2 => tegra2-common}/timer.c (100%)
diff --git a/Makefile b/Makefile
index 4ddf8d6..6639de0 100644
--- a/Makefile
+++ b/Makefile
@@ -319,6 +319,9 @@ endif
ifeq ($(SOC),exynos)
LIBS += $(CPUDIR)/s5p-common/libs5p-common.o
endif
+ifeq ($(SOC),tegra2)
+LIBS += $(OBJTREE)/arch/$(ARCH)/cpu/$(SOC)-common/lib$(SOC)-common.o
+endif
LIBS := $(addprefix $(obj),$(sort $(LIBS)))
.PHONY : $(LIBS)
diff --git a/arch/arm/cpu/armv7/tegra2/Makefile
b/arch/arm/cpu/armv7/tegra2/Makefile
index e9ac6c9..34452c4 100644
--- a/arch/arm/cpu/armv7/tegra2/Makefile
+++ b/arch/arm/cpu/armv7/tegra2/Makefile
@@ -22,23 +22,15 @@
# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
# MA 02111-1307 USA
#
-
-# The AVP is ARMv4T architecture so we must use special compiler
-# flags for any startup files it might use.
-CFLAGS_arch/arm/cpu/armv7/tegra2/ap20.o += -march=armv4t
-CFLAGS_arch/arm/cpu/armv7/tegra2/clock.o += -march=armv4t
-
include $(TOPDIR)/config.mk
LIB= $(obj)lib$(SOC).o
-SOBJS := lowlevel_init.o
-COBJS-y:= ap20.o board.o clock.o funcmux.o pinmux.o sys_info.o timer.o
COBJS-$(CONFIG_USB_EHCI_TEGRA) += usb.o
COBJS := $(COBJS-y)
-SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)
-OBJS := $(addprefix $(obj),$(COBJS) $(SOBJS))
+SRCS := $(COBJS:.o=.c)
+OBJS := $(addprefix $(obj),$(COBJS))
all:$(obj).depend $(LIB)
diff --git a/arch/arm/cpu/tegra2-common/Makefile
b/arch/arm/cpu/tegra2-common/Makefile
new file mode 100644
index 000..8de59cf
--- /dev/null
+++ b/arch/arm/cpu/tegra2-common/Makefile
@@ -0,0 +1,56 @@
+#
+# (C) Copyright 2010,2011 Nvidia Corporation.
+#
+# (C) Copyright 2000-2008
+# 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
+
+# The AVP is ARMv4T architecture so we must use special compiler
+# flags for any startup files it might use.
+CFLAGS_arch/arm/cpu/tegra2-common/ap20.o += -march=armv4t
+CFLAGS_arch/arm/cpu/tegra2-common/clock.o += -march=armv4t
+
+LIB= $(obj)lib$(SOC)-common.o
+
+SOBJS += lowlevel_init.o
+COBJS-y
Re: [U-Boot] nboot won't boot my uImage
> -Original Message- > From: u-boot-boun...@lists.denx.de [mailto:u-boot- > boun...@lists.denx.de] On Behalf Of Bishop, Mark > Sent: Wednesday, April 18, 2012 5:28 PM > To: u-boot@lists.denx.de > Subject: [U-Boot] nboot won't boot my uImage > > I can download my kernel uImage and flash it into NAND and then 'boot' > and it works. > *sigh* Fat fingered an extra 0 in the address and the reason why it boots at all is because the tftp download address and the bootm address are the same. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] nboot won't boot my uImage
I can download my kernel uImage and flash it into NAND and then 'boot' and it works. bfin> tftp 0x100 10.100.42.29:uImage.3 bfin> nand erase 0x8 0x80 bfin> nand write 0x100 0x8 0x80 Going to verify the image: bfin> nand read 0x200 0x8 $(filesize) bfin> iminfo 0x200 ## Checking Image at 0200 ... Legacy image found Image Name: bf548-0.2-3.0.8-ADI-2011R1-dirty Created: 2012-04-15 23:30:18 UTC Image Type: Blackfin Linux Kernel Image (gzip compressed) Data Size:5218920 Bytes = 5 MiB Load Address: 1000 Entry Point: 0026de3c Verifying Checksum ... OK bfin> And then I can boot: bfin> boot Loading from nand0, offset 0x80 ** Unknown image type ## Booting kernel from Legacy Image at 0100 ... Image Name: bf548-0.2-3.0.8-ADI-2011R1-dirty .. And if I do a soft reset I can still boot, every time. But when I cycle the power I get this: . Hit any key to stop autoboot: 0 Loading from nand0, offset 0x80 ** Unknown image type Wrong Image Format for bootm command ERROR: can't get kernel image! bfin> my boot command is: nandboot=nboot 0x200 0 0x80;run nandargs;bootm Any ideas? This used to work :) without failure until I updated uboot from an older version to something a bit more recent. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] fix IDE_BUS(dev) macro
On Tue, Apr 17, 2012 at 2:06 PM, Luka Perkov wrote: > IDE_BUS assumes that each bus has two devices and thus returns the first > bus even when the second one should be probed. > > Signed-off-by: Simon Baatz > Tested-by: Luka Perkov > --- > > Simon discovered this while adding support for new board IB NAS6210. > > More info can be found here: > > http://lists.denx.de/pipermail/u-boot/2012-April/122525.html > > When this is commited I will do a coding style cleanup. There are tabs > after few "#define" parts in include/ide.h. > > include/ide.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/include/ide.h b/include/ide.h > index 8ecc9dd..385e909 100644 > --- a/include/ide.h > +++ b/include/ide.h > @@ -24,7 +24,7 @@ > #ifndef _IDE_H Simon, Luka, Prafulla, etal, I've tested this out on the Seagate GoFlex Net (Kirkwood) device, which also has dual SATA ports, and it resolved the long-standing (and irritating) bug/unwanted-feature that required us to boot from _only_ the right side port. I would guess that other Kirkwood dual-SATA-port boxes would be happier because of this, as well. Nice catch, Simon. regards, Dave ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PULL] u-boot-staging/ma...@denx.de :: FOR u-boot/-next
Dear Marek Vasut, In message <201204060455.17359.ma...@denx.de> you wrote: > The following changes since commit c008b6f6dd6b8965e9a7654ffbce75bb9ff7a3b5: > > Prepare v2012.04-rc1 (2012-03-31 00:13:05 +0200) > > are available in the git repository at: > > git://git.denx.de/u-boot-staging.git ma...@denx.de > > for you to fetch changes up to c98167f1df33c6273355050fc0dbbdb73aec51ea: > > MIPS: start.S: refactor reset and exception vector setup (2012-03-31 > 22:51:57 > +0200) > > > Daniel Schwierzeck (6): > MIPS: board.c: fix init of flash data in bd_info > MIPS: add register definition for EBase register > MIPS: make cache operation mode configurable in dcache_enable() > MIPS: add header file for generic GPIO API > MIPS: extend cache initialization for recent MIPS CPU cores > MIPS: start.S: refactor reset and exception vector setup > > README |5 + > arch/mips/cpu/mips32/cache.S | 16 +++- > arch/mips/cpu/mips32/start.S | 204 > ++ > arch/mips/include/asm/gpio.h | 13 +++ > arch/mips/include/asm/mipsregs.h | 20 > arch/mips/lib/board.c|8 +- > 6 files changed, 112 insertions(+), 154 deletions(-) > create mode 100644 arch/mips/include/asm/gpio.h Applied to "next", 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 "What if" is a trademark of Hewlett Packard, so stop using it in your sentences without permission, or risk being sued. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [STATUS] v2012.04-rc2 and -rc3 are out
Hi everybody, sorry, I forgot to announce the 2012.04-rc2 pre-release two days ago, so I will atleast announce that we have v2012.04-rc3 now. Please help testing, so we can fix the remaining issues before the release, which I still want to push out April 21, 2012. Thanks to all who helped. Please make sure that all your important bug fixes have been included! I will also start a "next" branch now, so if you have anything pending there, please feel free to send pull requests for "next" ! Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de There is a time in the tides of men, Which, taken at its flood, leads on to success. On the other hand, don't count on it. - T. K. Lawson ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/85xx: Add USB device-tree fixup for various platforms
On Mon, Mar 26, 2012 at 9:15 AM, Ramneek Mehresh wrote: > Add USB device-tree fixup for following platforms: > MPC8536DS, P1022DS, P1023RDS, P2020COME, P2020DS, P2041RDB, P3060QDS > > Signed-off-by: Ramneek Mehresh > --- > diff --git a/board/freescale/p2020come/p2020come.c > b/board/freescale/p2020come/p2020come.c > index 8cf7bee..ce78016 100644 > --- a/board/freescale/p2020come/p2020come.c > +++ b/board/freescale/p2020come/p2020come.c > @@ -1,5 +1,5 @@ > /* > - * Copyright 2009 Freescale Semiconductor, Inc. > + * Copyright 2009,2012 Freescale Semiconductor, Inc. > * > * See file CREDITS for list of people who contributed to this > * project. > @@ -282,6 +282,10 @@ void ft_board_setup(void *blob, bd_t *bd) > > fdt_fixup_memory(blob, (u64)base, (u64)size); > > +#ifdef CONFIG_HAS_FSL_DR_USB > + fdt_fixup_dr_usb(blob, bd); > +#endif > + > fdt_fixup_dr_usb(blob, bd); Umm I don't think this is right. :) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-sh
Dear Nobuhiro Iwamatsu, In message you wrote: > Dear Wolfgang Denk, > > Please pull some fixes for v2012.04. > > The following changes since commit f5cdc11775c4b7fdbf52a6dd2f463d329804ab11= > : > > Prepare v2012.04-rc2; minor Coding Style cleanup (2012-04-16 23:13:51 +020= > 0) > > are available in the git repository at: > > git://git.denx.de/u-boot-sh.git master > > for you to fetch changes up to 77fe6e773af762676f4f30f646caa160e39a0bcc: > > sh: ecovec: Change macro from BOARD_LATE_INIT to > CONFIG_BOARD_LATE_INIT (2012-04-18 11:16:46 +0900) > > > Nobuhiro Iwamatsu (1): > sh: ecovec: Change macro from BOARD_LATE_INIT to CONFIG_BOARD_LATE_INI= > T > > Phil Edworthy (1): > sh: Fix rsk7264 pin setup for on-board ethernet > > board/renesas/rsk7264/lowlevel_init.S |2 +- > include/configs/ecovec.h |2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de A modem is a baudy house. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request (additional): u-boot-arm/master
Dear Albert ARIBAUD, In message <4f8d762c.5020...@aribaud.net> you wrote: > Hi Wolfgang, > > The following changes since commit f5cdc11775c4b7fdbf52a6dd2f463d329804ab11: > >Prepare v2012.04-rc2; minor Coding Style cleanup (2012-04-16 23:13:51 > +0200) > > are available in the git repository at: >git://git.denx.de/u-boot-arm master > > Dirk Behme (1): >i.MX6: arm2: Add AXI cache and Qos setting > > board/freescale/mx6qarm2/imximage.cfg |6 ++ > 1 files changed, 6 insertions(+), 0 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de "No problem is so formidable that you can't walk away from it." - C. Schulz ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] Preventing overriding of serverip when set in environment by user
Dear Chase, In message <7d46e86ec0a8354091174257b2fed10138dd6...@dlee12.ent.ti.com> you wrote: > > Sorry, I didn't mean I was talking about the code on the router. I meant I > was using the router as my DHCP server for my Linux host and my development > board. Cab you please restrict your line length to some 70 characters or so? Thanks. Well, when it's your box, then why don't you configure the DHCP server correctly? > First, thanks for your response. What I am trying to fix is that I > have a development board that is connected to my Linux host using a > Linksys WRT54G2 router. That particular router is returning a setting > in DHCP that points to the Linksys router itself as the server. In > this case I want my serverip to point to my Linux host which is > running a TFTP server. As mentioned, all you have to do is to configure your DHCP server correctly. It is perfectly normal to use different servers for DHCP and TFTP. All you have to do is to configure the "next-server" parameter in DHCP to point to the TFTP server > Other routers such as a Trendnet WRLS-N300 do not exhibit this > problem so this seems to be an issue with the DHCP response on the > Linksys router. ... This is a configuration option for the DHCP server. > ... However, thinking about this my reasoning was that if > a user were to take the time to set a value for serverip in their > u-boot environment then the network router should not override that Who says it was the user who set this variable? It could as well be the result from a previous call to DHCP which returned different results (for example, because there is a pool of DHCP servers). > setting. I think of this as who should be the authority in the > system. If the user has specified a setting shouldn't that have more > authority than the default setup of the DHCP server, since the user > should be more knowledgeable about their particular configuration? There is a pretty clear definition here: trhe documentation says that the DHCP command may set a certain number of (documented!) environment variables. If you think you want to ignore any of these settings, then just make sure to set these to the values you like after running the DHCP command, thus ignoring the DHCP settings. This can be done with 2 lines of trivial scripting and does not require any code changes (see my previous message). > As for fixing the DHCP server configuration I see two cases where > this can be an issue: > > 1. In the case of this Linksys router I found no option allowing me > to change the DHCP server configuration other than to change what > range of addresses it provides. So this would lead to needing to Are you absolutely sure that the Linksys router does not support the "next-server" parameter in it's configuration? > modify the router firmware. 2. What about an environment with a > shared DHCP server, where often times you may want the default value > of the DHCP server for 95% of your use cases, but a particular user > may want to override this setting. Then just ognore the resuylts returnd by the DHCP server. It is all at your hands. Nobody forces you to use the address returned by the DHCP call for your TFTP downloads. > The goal of this patch was to enable user's to override the DHCP > server setting by taking a pro-active action of defining serverip. In But this is wrong, as you cannot know how the nvironment variable got set, and if it actually contains a usable value. DHCP is _supposed_ to overwrite this variable with a valid setting. Ofcourse, it is up to you if you use these results, or if you ignore them. > server could provide a value if it was configured this way. Again, it > is all back to who should have ultimate authority in the system. But, It is the user who has this authority. Which is exactly why I will not accept this patch - it would implement some policy which you think fits for your purposes - but it does not fit in general. > I can also understand your position in that if I asked the DHCP > server for information I should honor the information it gives me, > and if the DHCP server is giving bad information then fix the server > (which may not always be possible/practical). It would always be > possible to work around this by turning autoload off and then > changing the bootcmd to do: > > dhcp; setenv serverip xxx.xxx.xxx.xxx; tftp > > Would that be our recommendation? Yes, indeed. If you want to ignore the server reply, then please do this explicitly. 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 Let the programmers be many and the managers few -- then all will be productive. -- Geoffrey James, "The Tao of Programming" ___ U-Boot mailing list U-Boot@lists.denx.de http://l
Re: [U-Boot] [RFC] Preventing overriding of serverip when set in environment by user
Dear Peter Barada,
In message <4f8ee1e1.1060...@logicpd.com> you wrote:
>
> > What exactly _are_ you trying to fix? What is wrong with using the
> > DHCP server supplied address? If it is incorrect, you should fix your
> > DHCP server configuration.
> I have the same type of problem.
>
> In my case our company controls the DHCP server that hands out addresses
> for the network, but I want to use a *local* TFTP server (the one on my
> development machine). I can't modify the DHCP server so if I use "dhcp"
> to get and address u-boot also overwrites serverip. At home my FiOS
If you know the DHCP server provides an address you don;t want to use,
and if you know the address that you want to use, then why don't you
just use it?
Something like:
=> setenv tftpserverip 192.168.12.34
=> setenv autoload no
=> dhcp
=> setenv ipaddr ${tftpserverip}
=> tftp ...
?
> Would an option to dhcp (i.e. one that tells it to *only* modify ipaddr)
> suffice? Or would it be better to provide an entirely a new command that
> optionally updates the variables in the environment be better? Then
> users have the option of using "dhcp" as is, or for environments like
> mine (and apparently Chase) can just get an IP address and go from there...
Why make it complicated when a few simple commands are sufficient?
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Where would we be without rhetorical questions?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] Preventing overriding of serverip when set in environment by user
> -Original Message- > From: Wolfgang Denk [mailto:w...@denx.de] > Sent: Wednesday, April 18, 2012 10:28 AM > To: Maupin, Chase > Cc: u-boot@lists.denx.de; Rini, Tom > Subject: Re: [U-Boot] [RFC] Preventing overriding of serverip when > set in environment by user > > Dear "Maupin, Chase", > > In message > <7d46e86ec0a8354091174257b2fed10138dd6...@dlee12.ent.ti.com> you > wrote: > > > > I recently was trying out a Linksys WRT54G2 V1 router and > > Thi sis out-of-tree code, so we cannot help much - we hav eno idea > which modifications they made to the code. > > > So the net effect was that the dhcp server in this router was > > providing information in its response packet that was overriding > the > > setting I had programmed. I dug into the u-boot code a little and > > This is normal, and intended. If you run DHCP, the information > returned from the server is put in the respective environment > variables. That's how it works. > > Note however, that of course this will not change the persistent > copy > of the environment - to do that, you would have to run "saveenv". > > > The first was to set CONFIG_BOOTP_SERVERIP in my board config > file. > > I discarded this because this would seem to make me always ignore > the > > serverip setting from the DHCP server, and it seemed likely that > > there were cases where you would want this. > > I don;t understand your description here, but indeed, putting > CONFIG_BOOTP_SERVERIP in the config file almost never makes sense, > and > it is definitly not acceptable for mainline. > > > The second was to check if the serverip was already set in the > > environment and if so then not override that value with the one > in > > the response from the DHCP server. The below patch snippet does > this > > This is not what is supposed to happen. You are breaking regular > functionality this way. > > > Is this the proper way to fix this issue and the right location > to > > make the change? The overall goal was to make sure that if I > > specified a particular serverip that I wanted to use, then the > DHCP > > server should not be changing that. > > No, this is not an acceptable patch. > > What exactly _are_ you trying to fix? What is wrong with using the > DHCP server supplied address? If it is incorrect, you should fix > your > DHCP server configuration. > I can see your point. Why treat serverip any different than the ipaddr returned from the DHCP server? I guess this can be worked around by resetting serverip between the dhcp command and the tftp command (using autoload off). Or I can take the approach I am currently using which is to put the linksys router away and buy a cheap trendnet router that doesn't do this :) > 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 > You may call me by my name, Wirth, or by my value, Worth. > - Nicklaus Wirth ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] fatls/fatload for NAND (partition)
On 04/18/2012 01:22 PM, peterlu wrote: > > Has anyone tried/incorporated the use of the FAT tools to access NAND > storage? I know one can use fatls on usb and mmc (which are "boot" > devices), but it seems natural that one should be able to use the FAT tools > on NAND as well, perhaps through some pseudo-device (that maps to some NAND > partition(s)). This would allow Linux to set up some mtd partition(s) as > vfat and U-boot to get to the same partition(s) as well. You would need a flash translation layer in between the FAT filesystem and raw NAND. Any reason not to use ubifs instead? -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] fatls/fatload for NAND (partition)
Has anyone tried/incorporated the use of the FAT tools to access NAND storage? I know one can use fatls on usb and mmc (which are "boot" devices), but it seems natural that one should be able to use the FAT tools on NAND as well, perhaps through some pseudo-device (that maps to some NAND partition(s)). This would allow Linux to set up some mtd partition(s) as vfat and U-boot to get to the same partition(s) as well. Thanks for any input. PL -- View this message in context: http://old.nabble.com/fatls-fatload-for-NAND-%28partition%29-tp33709724p33709724.html Sent from the Uboot - Users mailing list archive at Nabble.com. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/1] tegra2: move tegra2 SoC code to arch/arm/cpu/tegra2-common
This is part of an upcoming patch set to move all armv4t code out of tegra2 u-boot and put it into an SPL, but I wanted to get some early feedback on this patch. This moves most of the tegra2 SoC code from arch/arm/cpu/armv7 to a new directory arch/arm/cpu/tegra2-common. This code will be shared between the armv7 and armv4t builds of tegra2. -Allen nvpublic ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 7/9] imx: esdhc: Needed to use in imx-regs.h defined address
On 18.04.2012 19:27, Timo Ketola wrote: But if the board configuration file in include/configs is the correct place to include it, I shall then find the obstacle on that approach... Ok, including asm/arch/imx-regs.h in board configuration file *and* asm/types.h in asm/arch/imx-regs.h file seems to make build happy. This would be the right fix then? -- Timo ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/9] imx: nand: Support flash based BBT
On 04/18/2012 02:57 AM, Timo Ketola wrote: > +#ifdef CONFIG_SYS_NAND_USE_FLASH_BBT > + > + this->options = NAND_USE_FLASH_BBT; > + this->bbt_td = &bbt_main_descr; > + this->bbt_md = &bbt_mirror_descr; > + > +#endif Remove those blank lines, and use |= for options like is done with NAND_BUSWIDTH_16. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 7/9] imx: esdhc: Needed to use in imx-regs.h defined address
On 18.04.2012 18:05, Stefano Babic wrote: On 18/04/2012 13:05, Timo Ketola wrote: Stefano Babic wrote: Timo Ketola wrote: PPC seems to use a predefined macro from asm/immap_8xxx.h files. Where is that file included? It is a different way. The board configuration file includes the register description file, so for example immap_86xx.h, immap_85xx.h, Where? I don't see an example. For PPC86xx I can see at least: arch/powerpc/cpu/mpc86xx/mpc8641_serdes.c:#include arch/powerpc/cpu/mpc86xx/mpc8610_serdes.c:#include board/freescale/mpc8610hpcd/mpc8610hpcd.c:#include board/freescale/mpc8641hpcn/mpc8641hpcn.c:#include Yes, I saw those but when you said that board configuration file includes those, I thought that you meant the header files in include/configs. But I see them included in common.h. Should there be also imx-regs? Seems to work if I do so. No, this is wrong. ... Then I tried to include imx-regs.h in fsl_esdhc.c and 'MAKEALL -a arm' was happy. Maybe the right fix is to include imx-regs in common.h? No. common.h, as the name suggests, is for all architectures, not only for i.MX. We cannot fix i:MX and break other boards. But why PPC register description files are included there then? For example line 87: #ifdef CONFIG_MPC86xx #include #include #endif Is that deprecated? And how would adding imx file with the same logic break other boards? I mean, putting there: #if defined(CONFIG_MX25) || defined(CONFIG_MX31) || ... #include #endif But if the board configuration file in include/configs is the correct place to include it, I shall then find the obstacle on that approach... -- Timo ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] PowerPC: Change -fpic flag to -fPIC flag in the config.mk
On 04/17/2012 09:44 PM, Chunhe Lan wrote: > The -fPIC/-fpic flag belongs with -mrelocatable. The -fpic flag can > limit the size of the GOT and produce smaller binaries, so it causes > some GOT entries to be lost in the gcc 4.6 version. But -fPIC flag > allows the maximum possible size of the GOT entries. > > However, currently -mrelocatable promotes -fpic flag to -fPIC flag. > > This reverts that portion of the > commit 33ee4c92339ee386662c0ee2d221098c5cc8b07e. > > Signed-off-by: Chunhe Lan Please provide a better description, not something partially copied from the commit message that you're partially reverting. If -mrelocatable promotes -fpic to -fPIC how does this change have any effect? One has to go back to the commit message of 33ee4c to see that this was a bug that was fixed in GCC 4.6, so it's no longer "currently" doing that. What is the limit for -fpic? Do we get errors if we overflow, or does the toolchain silently generate a bad image (sounds like a bug if the latter)? What target are you seeing problems with? Also, when (partially) reverting a patch, please include at least the subject line of the patch in addition to the SHA-1, and CC the author of the patch. -Scott > --- > arch/powerpc/config.mk |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/arch/powerpc/config.mk b/arch/powerpc/config.mk > index a307154..7c14ff6 100644 > --- a/arch/powerpc/config.mk > +++ b/arch/powerpc/config.mk > @@ -25,7 +25,7 @@ CROSS_COMPILE ?= ppc_8xx- > > CONFIG_STANDALONE_LOAD_ADDR ?= 0x4 > LDFLAGS_FINAL += --gc-sections > -PLATFORM_RELFLAGS += -fpic -mrelocatable -ffunction-sections -fdata-sections > +PLATFORM_RELFLAGS += -fPIC -mrelocatable -ffunction-sections -fdata-sections > PLATFORM_CPPFLAGS += -DCONFIG_PPC -D__powerpc__ > PLATFORM_LDFLAGS += -n > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] Preventing overriding of serverip when set in environment by user
On 04/18/2012 11:28 AM, Wolfgang Denk wrote: > >> Is this the proper way to fix this issue and the right location to >> make the change? The overall goal was to make sure that if I >> specified a particular serverip that I wanted to use, then the DHCP >> server should not be changing that. > No, this is not an acceptable patch. > > What exactly _are_ you trying to fix? What is wrong with using the > DHCP server supplied address? If it is incorrect, you should fix your > DHCP server configuration. I have the same type of problem. In my case our company controls the DHCP server that hands out addresses for the network, but I want to use a *local* TFTP server (the one on my development machine). I can't modify the DHCP server so if I use "dhcp" to get and address u-boot also overwrites serverip. At home my FiOS router has a DHCP server (that I can't modify since its closed and is needed to provide addresses to my TV set top box) that provides addresses for my network, and has the same problem... Would an option to dhcp (i.e. one that tells it to *only* modify ipaddr) suffice? Or would it be better to provide an entirely a new command that optionally updates the variables in the environment be better? Then users have the option of using "dhcp" as is, or for environments like mine (and apparently Chase) can just get an IP address and go from there... -- Peter Barada peter.bar...@logicpd.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] Preventing overriding of serverip when set in environment by user
Dear "Maupin, Chase", In message <7d46e86ec0a8354091174257b2fed10138dd6...@dlee12.ent.ti.com> you wrote: > > I recently was trying out a Linksys WRT54G2 V1 router and Thi sis out-of-tree code, so we cannot help much - we hav eno idea which modifications they made to the code. > So the net effect was that the dhcp server in this router was > providing information in its response packet that was overriding the > setting I had programmed. I dug into the u-boot code a little and This is normal, and intended. If you run DHCP, the information returned from the server is put in the respective environment variables. That's how it works. Note however, that of course this will not change the persistent copy of the environment - to do that, you would have to run "saveenv". > The first was to set CONFIG_BOOTP_SERVERIP in my board config file. > I discarded this because this would seem to make me always ignore the > serverip setting from the DHCP server, and it seemed likely that > there were cases where you would want this. I don;t understand your description here, but indeed, putting CONFIG_BOOTP_SERVERIP in the config file almost never makes sense, and it is definitly not acceptable for mainline. > The second was to check if the serverip was already set in the > environment and if so then not override that value with the one in > the response from the DHCP server. The below patch snippet does this This is not what is supposed to happen. You are breaking regular functionality this way. > Is this the proper way to fix this issue and the right location to > make the change? The overall goal was to make sure that if I > specified a particular serverip that I wanted to use, then the DHCP > server should not be changing that. No, this is not an acceptable patch. What exactly _are_ you trying to fix? What is wrong with using the DHCP server supplied address? If it is incorrect, you should fix your DHCP server configuration. 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 You may call me by my name, Wirth, or by my value, Worth. - Nicklaus Wirth ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 2/3] usb:gadget:composite: Support for composite at gadget.h
Add device data pointer to the USB gadget's device struct.
Wrapper for extracting usb_gadget from Linux's usb device
Signed-off-by: Lukasz Majewski
Signed-off-by: Kyungmin Park
Cc: Marek Vasut
---
include/linux/usb/gadget.h |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
index 275cb5f..eba865e 100644
--- a/include/linux/usb/gadget.h
+++ b/include/linux/usb/gadget.h
@@ -411,6 +411,7 @@ struct usb_gadget_ops {
struct device {
void*driver_data; /* data private to the driver */
+ void*device_data; /* data private to the device */
};
/**
@@ -481,6 +482,11 @@ static inline void *get_gadget_data(struct usb_gadget
*gadget)
return gadget->dev.driver_data;
}
+static inline struct usb_gadget *dev_to_usb_gadget(struct device *dev)
+{
+ return container_of(dev, struct usb_gadget, dev);
+}
+
/* iterates the non-control endpoints; 'tmp' is a struct usb_ep pointer */
#define gadget_for_each_ep(tmp, gadget) \
list_for_each_entry(tmp, &(gadget)->ep_list, ep_list)
--
1.7.2.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 1/3] usb:gadget:composite USB composite gadget support
USB Composite gadget implementation for u-boot. It builds on top
of USB UDC drivers.
This commit is based on following files from Linux Kernel v2.6.36:
./include/linux/usb/composite.h
./drivers/usb/gadget/composite.c
SHA1: d187abb9a83e6c6b6e9f2ca17962bdeafb4bc903
Signed-off-by: Lukasz Majewski
Signed-off-by: Kyungmin Park
Cc: Marek Vasut
---
drivers/usb/gadget/composite.c | 1082 +++
include/linux/usb/composite.h | 350 +
include/usb/lin_gadget_compat.h | 24 +-
3 files changed, 1454 insertions(+), 2 deletions(-)
create mode 100644 drivers/usb/gadget/composite.c
create mode 100644 include/linux/usb/composite.h
diff --git a/drivers/usb/gadget/composite.c b/drivers/usb/gadget/composite.c
new file mode 100644
index 000..905077d
--- /dev/null
+++ b/drivers/usb/gadget/composite.c
@@ -0,0 +1,1082 @@
+/*
+ * composite.c - infrastructure for Composite USB Gadgets
+ *
+ * Copyright (C) 2006-2008 David Brownell
+ * U-boot porting: Lukasz Majewski
+ *
+ * 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
+ */
+#undef DEBUG
+
+#include
+#include
+
+#define USB_BUFSIZ 4096
+
+static struct usb_composite_driver *composite;
+
+/**
+ * usb_add_function() - add a function to a configuration
+ * @config: the configuration
+ * @function: the function being added
+ * Context: single threaded during gadget setup
+ *
+ * After initialization, each configuration must have one or more
+ * functions added to it. Adding a function involves calling its @bind()
+ * method to allocate resources such as interface and string identifiers
+ * and endpoints.
+ *
+ * This function returns the value of the function's bind(), which is
+ * zero for success else a negative errno value.
+ */
+int usb_add_function(struct usb_configuration *config,
+ struct usb_function *function)
+{
+ int value = -EINVAL;
+
+ debug("adding '%s'/%p to config '%s'/%p\n",
+ function->name, function,
+ config->label, config);
+
+ if (!function->set_alt || !function->disable)
+ goto done;
+
+ function->config = config;
+ list_add_tail(&function->list, &config->functions);
+
+ if (function->bind) {
+ value = function->bind(config, function);
+ if (value < 0) {
+ list_del(&function->list);
+ function->config = NULL;
+ }
+ } else
+ value = 0;
+
+ if (!config->fullspeed && function->descriptors)
+ config->fullspeed = 1;
+ if (!config->highspeed && function->hs_descriptors)
+ config->highspeed = 1;
+
+done:
+ if (value)
+ debug("adding '%s'/%p --> %d\n",
+ function->name, function, value);
+ return value;
+}
+
+/**
+ * usb_function_deactivate - prevent function and gadget enumeration
+ * @function: the function that isn't yet ready to respond
+ *
+ * Blocks response of the gadget driver to host enumeration by
+ * preventing the data line pullup from being activated. This is
+ * normally called during @bind() processing to change from the
+ * initial "ready to respond" state, or when a required resource
+ * becomes available.
+ *
+ * For example, drivers that serve as a passthrough to a userspace
+ * daemon can block enumeration unless that daemon (such as an OBEX,
+ * MTP, or print server) is ready to handle host requests.
+ *
+ * Not all systems support software control of their USB peripheral
+ * data pullups.
+ *
+ * Returns zero on success, else negative errno.
+ */
+int usb_function_deactivate(struct usb_function *function)
+{
+ struct usb_composite_dev*cdev = function->config->cdev;
+ int status = 0;
+
+ if (cdev->deactivations == 0)
+ status = usb_gadget_disconnect(cdev->gadget);
+ if (status == 0)
+ cdev->deactivations++;
+
+ return status;
+}
+
+/**
+ * usb_function_activate - allow function and gadget enumeration
+ * @function: function on which usb_function_activate() was called
+ *
+ * Reverses effect of usb_function_deactivate(). If no more functions
+ * are delaying their activation, the gadget driver will respond to
+ *
[U-Boot] [PATCH v4 3/3] usb:udc:samsung Add functions for storing private gadget data in UDC driver
This commit adds support for storing private data to Samsung's UDC
driver. This data is afterward used by usb gadget.
Signed-off-by: Lukasz Majewski
Signed-off-by: Kyungmin Park
Cc: Marek Vasut
---
drivers/usb/gadget/s3c_udc_otg.c | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/gadget/s3c_udc_otg.c b/drivers/usb/gadget/s3c_udc_otg.c
index f7f7b54..925d2f2 100644
--- a/drivers/usb/gadget/s3c_udc_otg.c
+++ b/drivers/usb/gadget/s3c_udc_otg.c
@@ -133,6 +133,18 @@ static void nuke(struct s3c_ep *ep, int status);
static int s3c_udc_set_halt(struct usb_ep *_ep, int value);
static void s3c_udc_set_nak(struct s3c_ep *ep);
+void set_udc_gadget_private_data(void *p)
+{
+ DEBUG_SETUP("%s: the_controller: 0x%p, p: 0x%p\n", __func__,
+ the_controller, p);
+ the_controller->gadget.dev.device_data = p;
+}
+
+void *get_udc_gadget_private_data(struct usb_gadget *gadget)
+{
+ return gadget->dev.device_data;
+}
+
static struct usb_ep_ops s3c_ep_ops = {
.enable = s3c_ep_enable,
.disable = s3c_ep_disable,
--
1.7.2.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 0/3] usb:gadget:composite: Support for composite gadget framework
This patch set provides support for composite gadget framework.
Files from Linux kernel (2.6.36) - namely composite.{c|h} have been
ported to u-boot.
Code supporting this framework has been added to gadget.h and Samsung's
UDC driver as well.
---
Changes for v2:
- Squash the kernel files with u-boot compatibility layer.
- Removal of dead/kernel specific code.
- Comments corrected according to u-boot coding style.
- Two separate patches regarding gadget.h file squashed together.
Changes for v3:
- Remove unlikely function call
- Code indentation fixup
Changes for v4:
- Move variables definition to function beginning
- CaMeL case declaration fixed
Lukasz Majewski (3):
usb:gadget:composite USB composite gadget support
usb:gadget:composite: Support for composite at gadget.h
usb:udc:samsung Add functions for storing private gadget data in UDC
driver
drivers/usb/gadget/composite.c | 1082 ++
drivers/usb/gadget/s3c_udc_otg.c | 12 +
include/linux/usb/composite.h| 350
include/linux/usb/gadget.h |6 +
include/usb/lin_gadget_compat.h | 24 +-
5 files changed, 1472 insertions(+), 2 deletions(-)
create mode 100644 drivers/usb/gadget/composite.c
create mode 100644 include/linux/usb/composite.h
--
1.7.2.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 7/9] imx: esdhc: Needed to use in imx-regs.h defined address
On 18/04/2012 13:05, Timo Ketola wrote: >> >> fsl_esdhc.c includes config.h. If your board configuration file includes >> imx-regs.h, as most i.MX boards do, the file is automatically included, >> I suppose. > > I tried that but then: > > .../u-boot-imx/build-exe4026/include/asm/arch/imx-regs.h:43:2: error: > expected specifier-qualifier-list before ‘u32’ > > when compiling > > arch/arm/cpu/arm926ejs/cpu.o Well, I have not said that there cannot be other issues. At first glance you must include asm/types.h, in cpu.c or in imx-regs.h. >>> PPC seems to use a predefined macro from asm/immap_8xxx.h files. Where >>> is that file included? >> >> It is a different way. The board configuration file includes the >> register description file, so for example immap_86xx.h, immap_85xx.h, > > Where? I don't see an example. For PPC86xx I can see at least: arch/powerpc/cpu/mpc86xx/mpc8641_serdes.c:#include arch/powerpc/cpu/mpc86xx/mpc8610_serdes.c:#include board/freescale/mpc8610hpcd/mpc8610hpcd.c:#include board/freescale/mpc8641hpcn/mpc8641hpcn.c:#include > But I see them included in common.h. > Should there be also imx-regs? Seems to work if I do so. No, this is wrong. > >> or >> imx-regs.h, and defines CONFIG_SYS_FSL_ESDHC_ADDR using its own specific >> macro, if any, for example: >> >> #define CONFIG_SYS_FSL_ESDHC_ADDR CONFIG_SYS_MPC85xx_ESDHC_ADDR >> >> Why is it not enough for you to set in your board configuration file: >> >> #define CONFIG_SYS_FSL_ESDHC_ADDR IMX_MMC_SDHC1_BASE > > I tried also exactly that, but then: > > fsl_esdhc.c:544:20: error: ‘IMX_MMC_SDHC1_BASE’ undeclared (first use in > this function) ...then imx-regs.h was not included... > > fsl_esdhc.c seems not to see imx-regs.h file. > > Then I tried to include imx-regs.h in fsl_esdhc.c and 'MAKEALL -a arm' > was happy. > > Maybe the right fix is to include imx-regs in common.h? No. common.h, as the name suggests, is for all architectures, not only for i.MX. We cannot fix i:MX and break other boards. 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] [RFC] Preventing overriding of serverip when set in environment by user
All,
I recently was trying out a Linksys WRT54G2 V1 router and encountered a strange
behaviour where the dhcp server on the router was overriding the serverip
setting I had in my u-boot environment. The behaviour looked like:
1. Boot by board and set my serverip using "setenv serverip 192.168.1.101"
2. printenv shows my serverip as 192.168.1.101
3. Do a dhcp command. In the output I noticed the server it was trying to
transfer my file from was 192.168.1.1 which is the router.
4. cancel the dhcp and do a printenv
5. serverip is not set to 192.168.1.1 in my environment
So the net effect was that the dhcp server in this router was providing
information in its response packet that was overriding the setting I had
programmed. I dug into the u-boot code a little and found two ways to work
around this.
The first was to set CONFIG_BOOTP_SERVERIP in my board config file. I
discarded this because this would seem to make me always ignore the serverip
setting from the DHCP server, and it seemed likely that there were cases where
you would want this.
The second was to check if the serverip was already set in the environment and
if so then not override that value with the one in the response from the DHCP
server. The below patch snippet does this (NOTE: I based this on my 2011.09
tree but it is close to the master branch in this function except for the use
of __maybe_unused).
net/bootp.c | 10 +-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/net/bootp.c b/net/bootp.c
index a003c42..186a7ac 100644
--- a/net/bootp.c
+++ b/net/bootp.c
@@ -106,11 +106,19 @@ static int BootpCheckPkt(uchar *pkt, unsigned dest,
unsigned src, unsigned len)
static void BootpCopyNetParams(Bootp_t *bp)
{
IPaddr_t tmp_ip;
+ IPaddr_t tmp_serverip;
NetCopyIP(&NetOurIP, &bp->bp_yiaddr);
#if !defined(CONFIG_BOOTP_SERVERIP)
NetCopyIP(&tmp_ip, &bp->bp_siaddr);
- if (tmp_ip != 0)
+
+ /* Check if the serverip variable is set. If so then do not set
+ NetServerIP which will result in overwriting the serverip variable
+ in the environment.
+*/
+ tmp_serverip = getenv_IPaddr("serverip");
+
+ if (!tmp_serverip && (tmp_ip != 0))
NetCopyIP(&NetServerIP, &bp->bp_siaddr);
memcpy (NetServerEther, ((Ethernet_t *)NetRxPacket)->et_src, 6);
#endif
--
1.7.0.4
I tested the above patch with the same linksys router and in the case where I
had done a setenv serverip xxx.xxx.xxx.xxx it was not overridden by the DHCP
server settings. If I had not set serverip then it was set to the DHCP server
setting.
Is this the proper way to fix this issue and the right location to make the
change? The overall goal was to make sure that if I specified a particular
serverip that I wanted to use, then the DHCP server should not be changing that.
Sincerely,
Chase Maupin
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] FW: I want to use Barebox
Dear Dirk Behme, In message <4f8e999f.8060...@de.bosch.com> you wrote: > > Oh, indeed, looking into git we have a v2012.04-rc2 :) > > Have I missed the release mail? No - I did not manage to send one yet. [Don't have much to write, either.] Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de There are always alternatives. -- Spock, "The Galileo Seven", stardate 2822.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mmc: Fix warning if CONFIG_MMC_TRACE is enabled
Dear Dirk Behme,
> On 31.03.2012 20:35, Marek Vasut wrote:
> > Dear Dirk Behme,
> >
> >> Fix the warning
> >>
> >> mmc.c: In function 'mmc_send_cmd':
> >> mmc.c:87: warning: assignment from incompatible pointer type
> >>
> >> in case CONFIG_MMC_TRACE is enabled.
> >>
> >> Signed-off-by: Dirk Behme
> >> CC: Andy Fleming
I'd be glad to see it in ... Andy?
> >> ---
> >
> > Acked-by: Marek Vasut
> >
> > Acked-by: Simon Glass
> >
> >> drivers/mmc/mmc.c |2 +-
> >> 1 files changed, 1 insertions(+), 1 deletions(-)
> >>
> >> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
> >> index 21665ec..881b5c0 100644
> >> --- a/drivers/mmc/mmc.c
> >> +++ b/drivers/mmc/mmc.c
> >> @@ -84,7 +84,7 @@ int mmc_send_cmd(struct mmc *mmc, struct mmc_cmd *cmd,
> >> struct mmc_data *data) for (i = 0; i < 4; i++) {
> >>
> >>int j;
> >>printf("\t\t\t\t\t%03d - ", i*4);
> >>
> >> - ptr = &cmd->response[i];
> >> + ptr = (u8 *)&cmd->response[i];
> >>
> >>ptr += 3;
> >>for (j = 0; j < 4; j++)
> >>
> >>printf("%02X ", *ptr--);
>
> Who could help to still get this into 2012.04?
>
> Many thanks,
>
> Dirk
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] i.MX6: Add ANATOP regulator init
2012/4/13 Dirk Behme :
> Init the core regulator voltage to 1.2V. This is required for the correct
> functioning of the GPU and when the ARM LDO is set to 1.225V. This is a
> workaround to fix some memory clock jitter.
>
> Note: This should be but can't be done in the DCD. The bootloader
> prevents access to the ANATOP registers.
>
> Signed-off-by: Dirk Behme
> CC: Jason Chen
> CC: Jason Liu
> CC: Ranjani Vaidyanathan
> CC: Stefano Babic
> CC: Fabio Estevam
> ---
> arch/arm/cpu/armv7/mx6/soc.c | 16
> 1 files changed, 16 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/cpu/armv7/mx6/soc.c b/arch/arm/cpu/armv7/mx6/soc.c
> index 543b2cc..957ea34 100644
> --- a/arch/arm/cpu/armv7/mx6/soc.c
> +++ b/arch/arm/cpu/armv7/mx6/soc.c
> @@ -77,10 +77,26 @@ void init_aips(void)
> writel(0x, &aips2->opacr4);
> }
>
> +static void init_anatop_reg(void)
> +{
> + struct anatop_regs *anatop = (struct anatop_regs *)ANATOP_BASE_ADDR;
> + int reg = readl(&anatop->reg_core);
> +
> + /*
> + * Increase the VDDSOC to 1.2V
> + * Mask out the REG_CORE[22:18] bits (REG2_TRIG)
> + * and set them to 1.2V (0.7V + 0x14 * 0.025V)
> + */
> + reg = (reg & ~(0x1F << 18)) | (0x14 << 18);
> + writel(reg, &anatop->reg_core);
> +}
> +
> int arch_cpu_init(void)
> {
> init_aips();
>
> + init_anatop_reg();
> +
> return 0;
> }
> #endif
Acked-by:Jason Liu
> --
> 1.7.0.4
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 7/9] imx: esdhc: Needed to use in imx-regs.h defined address
On 18.04.2012 13:30, Stefano Babic wrote: On 18/04/2012 11:11, Timo Ketola wrote: Ok, I was afraid about something like that and tried first to include it in board configuration but that broke something else (at least arm926ejs didn't compile any more). By the way, why do you need it if you do not use that macro ? I use it in my board (support of which I'm preparing to send) configuration file and I think it is annoying to write a literal constant there which is already defined in imx-regs.h. fsl_esdhc.c includes config.h. If your board configuration file includes imx-regs.h, as most i.MX boards do, the file is automatically included, I suppose. I tried that but then: .../u-boot-imx/build-exe4026/include/asm/arch/imx-regs.h:43:2: error: expected specifier-qualifier-list before ‘u32’ when compiling arch/arm/cpu/arm926ejs/cpu.o PPC seems to use a predefined macro from asm/immap_8xxx.h files. Where is that file included? It is a different way. The board configuration file includes the register description file, so for example immap_86xx.h, immap_85xx.h, Where? I don't see an example. But I see them included in common.h. Should there be also imx-regs? Seems to work if I do so. or imx-regs.h, and defines CONFIG_SYS_FSL_ESDHC_ADDR using its own specific macro, if any, for example: #define CONFIG_SYS_FSL_ESDHC_ADDR CONFIG_SYS_MPC85xx_ESDHC_ADDR Why is it not enough for you to set in your board configuration file: #define CONFIG_SYS_FSL_ESDHC_ADDR IMX_MMC_SDHC1_BASE I tried also exactly that, but then: fsl_esdhc.c:544:20: error: ‘IMX_MMC_SDHC1_BASE’ undeclared (first use in this function) fsl_esdhc.c seems not to see imx-regs.h file. Then I tried to include imx-regs.h in fsl_esdhc.c and 'MAKEALL -a arm' was happy. Maybe the right fix is to include imx-regs in common.h? What would be the right expression for #ifdef? -- Timo ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mmc: Fix warning if CONFIG_MMC_TRACE is enabled
On 31.03.2012 20:35, Marek Vasut wrote:
Dear Dirk Behme,
Fix the warning
mmc.c: In function 'mmc_send_cmd':
mmc.c:87: warning: assignment from incompatible pointer type
in case CONFIG_MMC_TRACE is enabled.
Signed-off-by: Dirk Behme
CC: Andy Fleming
---
Acked-by: Marek Vasut
> Acked-by: Simon Glass
drivers/mmc/mmc.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index 21665ec..881b5c0 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -84,7 +84,7 @@ int mmc_send_cmd(struct mmc *mmc, struct mmc_cmd *cmd,
struct mmc_data *data) for (i = 0; i < 4; i++) {
int j;
printf("\t\t\t\t\t%03d - ", i*4);
- ptr = &cmd->response[i];
+ ptr = (u8 *)&cmd->response[i];
ptr += 3;
for (j = 0; j < 4; j++)
printf("%02X ", *ptr--);
Who could help to still get this into 2012.04?
Many thanks,
Dirk
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] i.MX2: Support splash screen
On 18/04/2012 10:54, Timo Ketola wrote:
> Signed-off-by: Timo Ketola
> ---
> arch/arm/include/asm/arch-mx25/imx-regs.h | 29 +
> drivers/video/Makefile|1 +
> drivers/video/mx2fb.c | 92
> +
> include/lcd.h | 21 ++-
> include/mx2fb.h | 39
> 5 files changed, 181 insertions(+), 1 deletions(-)
> create mode 100644 drivers/video/mx2fb.c
> create mode 100644 include/mx2fb.h
Hi Timo,
I forward your patch to Anatolji. He is the video maintainer.
>
> diff --git a/arch/arm/include/asm/arch-mx25/imx-regs.h
> b/arch/arm/include/asm/arch-mx25/imx-regs.h
> index 7f9449b..af5b42e 100644
> --- a/arch/arm/include/asm/arch-mx25/imx-regs.h
> +++ b/arch/arm/include/asm/arch-mx25/imx-regs.h
> @@ -167,6 +167,35 @@ struct aips_regs {
> u32 mpr_8_15;
> };
>
> +struct lcdc_regs {
> + u32 lssar;
> + u32 lsr;
> + u32 lvpwr;
> + u32 lcpr;
> + u32 lcwhb;
> + u32 lccmr;
> + u32 lpcr;
> + u32 lhcr;
> + u32 lvcr;
> + u32 lpor;
> + u32 lscr;
> + u32 lpccr;
> + u32 ldcr;
> + u32 lrmcr;
> + u32 licr;
> + u32 lier;
> + u32 lisr;
> + u32 pad0[3];
> + u32 lgwsar;
> + u32 lgwsr;
> + u32 lgwvpwr;
> + u32 lgwpor;
> + u32 lgwpr;
> + u32 pad1[0x200 - 25];
> + u32 bglut[0x100];
> + u32 gwlut[0x100];
> +};
> +
> #endif
>
> /* AIPS 1 */
> diff --git a/drivers/video/Makefile b/drivers/video/Makefile
> index 6252f6a..e047471 100644
> --- a/drivers/video/Makefile
> +++ b/drivers/video/Makefile
> @@ -36,6 +36,7 @@ COBJS-$(CONFIG_VIDEO_CT69000) += ct69000.o videomodes.o
> COBJS-$(CONFIG_VIDEO_DA8XX) += da8xx-fb.o videomodes.o
> COBJS-$(CONFIG_VIDEO_MB862xx) += mb862xx.o videomodes.o
> COBJS-$(CONFIG_VIDEO_MB86R0xGDC) += mb86r0xgdc.o videomodes.o
> +COBJS-$(CONFIG_VIDEO_MX2) += mx2fb.o
> COBJS-$(CONFIG_VIDEO_MX3) += mx3fb.o videomodes.o
> COBJS-$(CONFIG_VIDEO_MX5) += mxc_ipuv3_fb.o ipu_common.o ipu_disp.o
> COBJS-$(CONFIG_VIDEO_OMAP3) += omap3_dss.o videomodes.o
> diff --git a/drivers/video/mx2fb.c b/drivers/video/mx2fb.c
> new file mode 100644
> index 000..9ee4a3e
IMHO it is better if you use the video API instead of the old LCD
interface, that means using CONFIG_VIDEO. You have then to implement a
video_hw_init() function for your initialisation. I think there are
advantages doing that, and recently some drivers moved to this API, for
example the driver for i.MX3 (mx3fb.c).
>
> diff --git a/include/mx2fb.h b/include/mx2fb.h
> new file mode 100644
> index 000..1f16a61
> --- /dev/null
> +++ b/include/mx2fb.h
> @@ -0,0 +1,39 @@
> +/*
> + * Copyright 2004-2009 Freescale Semiconductor, Inc. All Rights Reserved.
> + */
> +
> +/*
> + * The code contained herein is licensed under the GNU General Public
> + * License. You may obtain a copy of the GNU General Public License
> + * Version 2 or later at the following locations:
> + *
> + * http://www.opensource.org/licenses/gpl-license.html
> + * http://www.gnu.org/copyleft/gpl.html
> + */
The header is not correct, I think - it does not set explicitely under
which license version is published this code, only where it is possible
to get a GPLv2 or later. Please substitute this header with a full
explained license header, as you can see generally in u-boot files.
Best regards,
Stefano Babic
--
=
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] i.MX6: Add ANATOP regulator init
On 13.04.2012 10:00, Dirk Behme wrote:
Init the core regulator voltage to 1.2V. This is required for the correct
functioning of the GPU and when the ARM LDO is set to 1.225V. This is a
workaround to fix some memory clock jitter.
Note: This should be but can't be done in the DCD. The bootloader
prevents access to the ANATOP registers.
Signed-off-by: Dirk Behme
CC: Jason Chen
CC: Jason Liu
CC: Ranjani Vaidyanathan
CC: Stefano Babic
CC: Fabio Estevam
---
arch/arm/cpu/armv7/mx6/soc.c | 16
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/arch/arm/cpu/armv7/mx6/soc.c b/arch/arm/cpu/armv7/mx6/soc.c
index 543b2cc..957ea34 100644
--- a/arch/arm/cpu/armv7/mx6/soc.c
+++ b/arch/arm/cpu/armv7/mx6/soc.c
@@ -77,10 +77,26 @@ void init_aips(void)
writel(0x, &aips2->opacr4);
}
+static void init_anatop_reg(void)
+{
+ struct anatop_regs *anatop = (struct anatop_regs *)ANATOP_BASE_ADDR;
+ int reg = readl(&anatop->reg_core);
+
+ /*
+* Increase the VDDSOC to 1.2V
+* Mask out the REG_CORE[22:18] bits (REG2_TRIG)
+* and set them to 1.2V (0.7V + 0x14 * 0.025V)
+*/
+ reg = (reg & ~(0x1F << 18)) | (0x14 << 18);
+ writel(reg, &anatop->reg_core);
+}
+
int arch_cpu_init(void)
{
init_aips();
+ init_anatop_reg();
+
return 0;
}
#endif
Any comments on this?
Many thanks
Dirk
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/9] i.MX25: esdhc: Add mxc_get_clock infrastructure
On 18.04.2012 12:23, Wolfgang Denk wrote: Dear "Timo Ketola", In message<1334735852-23415-2-git-send-email-t...@exertus.fi> you wrote: Defining CONFIG_FSL_ESDHC brings in a call to get_clocks, so let's implement get_clocks function. This is how it seems to be implemented elsewhere. ... ... I understand this is a (eventually modified ?) reposting of patches you posted before. Yes in this case it is mandatory not only to mark this in the Subject, Ok, how to do that I learned just now. but also to provide a detailled change log (below the "---" line); see http://www.denx.de/wiki/view/U-Boot/Patches#Sending_updated_patch_versions I tried to provide that in the 0/x message but do you mean that I should provide it separately for every single patch? I see that your reference asks just that. I was in impression that 'git send-email' (alone) would do the right thing but it doesn't give me opportunity to edit actual patch messages, only the cover letter. And I saw many examples of people putting the log in the cover letter. So how do people do that? 'git format-patch' then manually edit patch files, then send them with 'git send-email'? I'm not going to try to find out which review comments you have included, and what you changed to do so; sorry, but I don;t have that much time. So do I have to reference review comments somehow? Please consider the whole patch series ignored. Ok -- Timo ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] FW: I want to use Barebox
Dear Wolfgang, On 18.04.2012 11:52, Wolfgang Denk wrote: ... U-Boot history since: commits f4eb545..f5cdc11 (=v2012.04-rc2) Totally off-topic in this thread, but: Oh, indeed, looking into git we have a v2012.04-rc2 :) Have I missed the release mail? Best regards Dirk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 6/9] imx: usb: There is no such register
On 18/04/2012 11:15, Timo Ketola wrote: > On 18.04.2012 12:05, Stefano Babic wrote: >> As far as I can see, only MX31 and MX25 boards are using this file. >> Other i.MX have its own initialization file. So #if defined(CONFIG_MX31) >> || defined(CONFIG_MX25) is always true. > > So, would it be OK to remove this check altogether? Yes, I think so - if the file is compiled only by i.MX25 or i.MX31 boards, it makes no sense. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 7/9] imx: esdhc: Needed to use in imx-regs.h defined address
On 18/04/2012 11:11, Timo Ketola wrote: > > Ok, I was afraid about something like that and tried first to include it > in board configuration but that broke something else (at least arm926ejs > didn't compile any more). > >> By the way, why do you need it if you do not use that macro ? > > I use it in my board (support of which I'm preparing to send) > configuration file and I think it is annoying to write a literal > constant there which is already defined in imx-regs.h. fsl_esdhc.c includes config.h. If your board configuration file includes imx-regs.h, as most i.MX boards do, the file is automatically included, I suppose. > > PPC seems to use a predefined macro from asm/immap_8xxx.h files. Where > is that file included? It is a different way. The board configuration file includes the register description file, so for example immap_86xx.h, immap_85xx.h, or imx-regs.h, and defines CONFIG_SYS_FSL_ESDHC_ADDR using its own specific macro, if any, for example: #define CONFIG_SYS_FSL_ESDHC_ADDR CONFIG_SYS_MPC85xx_ESDHC_ADDR Why is it not enough for you to set in your board configuration file: #define CONFIG_SYS_FSL_ESDHC_ADDR IMX_MMC_SDHC1_BASE Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] PowerPC: Change -fpic flag to -fPIC flag in the config.mk
>
>
>
> Wolfgang Denk wrote:
> > Dear Chunhe Lan,
> >
> > In message <1334719161-3500-1-git-send-email-chunhe@freescale.com>
> > you wrote:
> >> The -fPIC/-fpic flag belongs with -mrelocatable. The -fpic flag can
> >> limit the size of the GOT and produce smaller binaries, so it causes
> >> some GOT entries to be lost in the gcc 4.6 version. But -fPIC flag
> >> allows the maximum possible size of the GOT entries.
> >>
> >> However, currently -mrelocatable promotes -fpic flag to -fPIC flag.
Not in newer gcc's. I added this to gcc some time ago and I think
it got into gcc 4.6.
> >>
> >> This reverts that portion of the
> >> commit 33ee4c92339ee386662c0ee2d221098c5cc8b07e.
> >
> > As you state yourself, your modification has the negative impact of
> > increasing the image size. What would be the benefits of it?
> >
> > Are you trying to fix any specific problem? Which one? I am not aware
> > of any related isses for any of the mainline PowerPC systems...
> Yes, I have fixed the booting issue of nand u-boot of
> P1010/P1022/P1023/P2020 with this patch.
>
> When use gcc 4.5 version, produce the size of u-boot-nand.bin to be
> same with -fpic or -fPIC.
> The u-boot-nand.bin is OK.
>
> But when use gcc 4.6 version, produce the size of u-boot-nand.bin to
> be different with -fpic or -fPIC.
> The some GOT entries of u-boot-nand.bin are lost with -fpic(because
> limit the size), so
> u-boot-nand.bin hangs when booting. But use -fPIC, the
> u-boot-nand.bin is OK.
Your linker file is buggy I think. I found u-boot-nand_spl.lds, is that the one?
Check out that files reloc part:
.reloc : {
_GOT2_TABLE_ = .;
KEEP(*(.got2))
_FIXUP_TABLE_ = .;
KEEP(*(.fixup))
}
__got2_entries = (_FIXUP_TABLE_ - _GOT2_TABLE_) >> 2;
__fixup_entries = (. - _FIXUP_TABLE_) >> 2;
Compare that with(from u-boot.lds):
.reloc :
{
_GOT2_TABLE_ = .;
KEEP(*(.got2))
KEEP(*(.got))
PROVIDE(_GLOBAL_OFFSET_TABLE_ = . + 4);
_FIXUP_TABLE_ = .;
KEEP(*(.fixup))
}
__got2_entries = ((_GLOBAL_OFFSET_TABLE_ - _GOT2_TABLE_) >> 2) - 1;
__fixup_entries = (. - _FIXUP_TABLE_) >> 2;
You may have to look at start.S for nand too
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] FW: I want to use Barebox
Dear Andy, In message you wrote: > > > - How often a patches committed to the public repository > > - What is the patch review procedure - Has it changed recently? Why? > >do _you_ think it is a good procedure? > > - How many people are actively contributing - Is there are large enough > >core contribution team that you believe can support you going forward > > - What level of support can you expect from the community both now and in > >the future > > - Are there any clear policies (either explicit or implicit). For exampl> > > e, > >U-Boot has a policy of not introducing board-breaking changes unless > >there is a really good reason. Also, U-Boot questions patches that > >cause code/data size increases for arches/boards which do not benifit > >from a particular new feature > > Looking at the two choices side by side, these appear to be equal. This Actually this is an area where you can collect objective, unbiased information from a number of data sources. Each of them alone is probably subject to error or misinterpretation, but together they give a pretty clear picture. 1) Commit statistics; these are trivial to get from the respective git repositories using the "git-dm" tool by Jonathan Corbet (see http://repo.or.cz/w/git-dm.git). Here one should pay attention that up to and including U-Boot v1.2.0 (commit f4eb545, dated Sun Jan 7 00:13:11 2007) both trees share a common history, so let's look at this separately: Common history: commits 0b666f8..f4eb545 2154 csets from 38 developers 8 employers found A total of 1919992 lines added, 279294 removed (delta 1640698) U-Boot history since: commits f4eb545..f5cdc11 (=v2012.04-rc2) 12648 csets from 647 developers 54 employers found A total of 1632473 lines added, 1132225 removed (delta 500248) BareBox history since: commits f4eb545..6a0ab1d (2012-04-14) 4346 csets from 72 developers 6 employers found A total of 458345 lines added, 1404718 removed (delta -946373) It has to be pointed out that the inital phase of Barebox is probably a bit untypic as it consisted mainly of large removals of major parts of U-Boot code, so let's also have a look at a somewhat shorter period - we skip the period where BareBox was using SVN and start with the first git commit (bc1e507, 2007-07-05 21:23:42). For U-Boot we chose a close date: commit f1152f8 (2007-07-06 02:50:19) U-Boot history since: commits f1152f8..f5cdc11 12212 csets from 630 developers 52 employers found A total of 1531006 lines added, 1099069 removed (delta 431937) Barebox history since: commits bc1e507..6a0ab1d 3657 csets from 72 developers 6 employers found A total of 377290 lines added, 865712 removed (delta -488422) So in the last ~5 years (since 2007-07-05 = 1748 days) we get these numbers: U-Boot BareBox ratio Commits 12212 36573.3 Developers 630 72 8.8 Employers 52 6 8.7 add per day 876 216 4.1 rm per day 629 495 1.3 chg per day +247-279 As you can see, U-Boot has a significantly bigger community (both in terms of developers and contributing companies). Development is faster, too. 2) Project statistics at ohloh.net: compare http://www.ohloh.net/p/u-boot versus http://www.ohloh.net/p/barebox Note: this comparison is in favour of the BareBox project, as it includes all the common history up to and including commit f4eb545 (U-Boot release v1.2.0). 3) Mailing list statistics: compare http://lists.denx.de/pipermail/u-boot/ versus http://lists.infradead.org/pipermail/barebox/ For the period of October 2009 (when the BareBox mailing list was started) until today we see: U-Boot: total 57.3 MiB gzipped text = 1893 KiB/month Barebox: total 7.08 MiB gzipped text = 234 KiB/month Also, compare http://dir.gmane.org/gmane.comp.boot-loaders.u-boot versus http://dir.gmane.org/gmane.comp.boot-loaders.barebox For U-Boot see also: http://gmane.org/details.php?group=gmane.comp.boot-loaders.u-boot [http://gmane.org/details.php?group=gmane.comp.boot-loaders.barebox does not give much information.] > is one of those areas, however, that no one can be 100% sure about for > the next 5-10 years. Barebox may overtake U-Boot just like U-Boot did > for RedBoot. Or some other bootloader may take the center stage. This > is an unknown risk that has to be owned by the company that chooses to > adopt any third party code. This is true. Prediction is always difficult. On the other hand, U-Boot is a de-facto standard in the embedded industry; we currently support 990 board configurations in mainline (not counting the many, many out-of-tree vendor ports). This indicates a pretty high
Re: [U-Boot] [U-Boot-Users] How to pass MAC address to linux kernel?
Dear Jayakumar A, Please restrict your line length to some 70 characters or so. Thanks. In message <3d423a5438408c4ea43da95d38f9989b7c9b6ed...@exchindmail.patni.com> you wrote: > > I was going through the mail chain of "passing MAC address to Linux kernel > "( http://www.mail-archive.com/u-boot-users@lists.sourceforge.net/msg09312. > html) and found you could be of great help in helping our issue. This information is 4 years old and obsolete. > We wish to set the ipaddress on the ARM-9 board retrieving from a particula > r file and start the network services: If you are talk about "retrieve from a file" you probably mean under Linux? That should be trivial to implement. In U-Boot, we use the environment to store MAC addresses. > We are using FreeScaleArm9 board and to statically set the system we have f > lashed the kernel(linux-2.6.31) on NAND Flash with DHCP off. > As per ltib settings it says: to have static ip-settings, either set the ip > -address while configuring LTIB or change in the file /etc/rc.d/rc.conf. This is all Linux stuff and off topic here. Also, LTIB is Freesale's code, so please ask Freescale support about it. > If you could please share some information regarding the static -ip setting > s and starting network serives it should be of great help. It is totally unclear to me what you are actually asking 0 it seems you confuse MAC and IP addresses at a pretty much fundamental level. In any case, you appear to refer to Linux configuration, which is off topic 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 Living on Earth may be expensive, but it includes an annual free trip around the Sun. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] i.MX2: Support splash screen
Dear "Timo Ketola", In message <1334739261-7812-2-git-send-email-t...@exertus.fi> you wrote: > Signed-off-by: Timo Ketola > --- > arch/arm/include/asm/arch-mx25/imx-regs.h | 29 + > drivers/video/Makefile|1 + > drivers/video/mx2fb.c | 92 > + > include/lcd.h | 21 ++- > include/mx2fb.h | 39 > 5 files changed, 181 insertions(+), 1 deletions(-) > create mode 100644 drivers/video/mx2fb.c > create mode 100644 include/mx2fb.h NAK, because proper attribution is missing. See http://www.denx.de/wiki/view/U-Boot/Patches#Attributing_Code_Copyrights_Sign 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 greatest warriors are the ones who fight for peace." - Holly Near ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/1] i.MX2: Support splash screen
Dear "Timo Ketola", In message <1334739261-7812-1-git-send-email-t...@exertus.fi> you wrote: > I based this on the work here: > > http://www.imxdev.org/wiki/index.php?title=I.MX25_PDK_U-boot_SplashScreen This information belongs (with greater detail) into the commit message. 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 day-to-day travails of the IBM programmer are so amusing to most of us who are fortunate enough never to have been one - like watching Charlie Chaplin trying to cook a shoe. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/9] i.MX25: esdhc: Add mxc_get_clock infrastructure
Dear "Timo Ketola", In message <1334735852-23415-2-git-send-email-t...@exertus.fi> you wrote: > Defining CONFIG_FSL_ESDHC brings in a call to get_clocks, so let's implement > get_clocks function. This is how it seems to be implemented elsewhere. > > Signed-off-by: Timo Ketola > --- > arch/arm/cpu/arm926ejs/mx25/generic.c | 27 +++ > arch/arm/include/asm/arch-mx25/clock.h | 23 +++ > 2 files changed, 50 insertions(+), 0 deletions(-) > > diff --git a/arch/arm/cpu/arm926ejs/mx25/generic.c > b/arch/arm/cpu/arm926ejs/mx25/generic.c ... I understand this is a (eventually modified ?) reposting of patches you posted before. in this case it is mandatory not only to mark this in the Subject, but also to provide a detailled change log (below the "---" line); see http://www.denx.de/wiki/view/U-Boot/Patches#Sending_updated_patch_versions I'm not going to try to find out which review comments you have included, and what you changed to do so; sorry, but I don;t have that much time. Please consider the whole patch series ignored. 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 "It is easier to port a shell than a shell script." - Larry Wall ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] PowerPC: Change -fpic flag to -fPIC flag in the config.mk
Dear Chunhe Lan, In message <4f8e6e06.3060...@freescale.com> you wrote: > > > As you state yourself, your modification has the negative impact of > > increasing the image size. What would be the benefits of it? > > > > Are you trying to fix any specific problem? Which one? I am not aware > > of any related isses for any of the mainline PowerPC systems... > Yes, I have fixed the booting issue of nand u-boot of > P1010/P1022/P1023/P2020 with this patch. What exactly is "the booting issue" you mention here? Are you referring to any messages previously posted here? Which? > But when use gcc 4.6 version, produce the size of u-boot-nand.bin to > be different with -fpic or -fPIC. > The some GOT entries of u-boot-nand.bin are lost with -fpic(because > limit the size), so > u-boot-nand.bin hangs when booting. But use -fPIC, the > u-boot-nand.bin is OK. What do you mean "GOT entries ... are lost"? Are there any error messages? If yes, what exactly are these? If not, then this has to be considered a serious bug in either the compiler and the linker, and it should be fixed there rather than being papered over. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de I think it's a new feature. Don't tell anyone it was an accident. :-) -- Larry Wall on s/foo/bar/eieio in <10...@jpl-devvax.jpl.nasa.gov> ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 6/9] imx: usb: There is no such register
On 18.04.2012 12:05, Stefano Babic wrote: As far as I can see, only MX31 and MX25 boards are using this file. Other i.MX have its own initialization file. So #if defined(CONFIG_MX31) || defined(CONFIG_MX25) is always true. So, would it be OK to remove this check altogether? However, where is this code ? In current u-boot I see only #if defined(CONFIG_MX31) at this line. Is it your patch correct ? My previous patch 5 touched that one. - setbits_le32(&ehci->control, USB_EN); - As far as I can see, it tries to overwrite a capability register, that is for our luck read-only. Good catch ! Thanks. -- Timo ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] PowerPC: Change -fpic flag to -fPIC flag in the config.mk
Wolfgang Denk wrote: Dear Chunhe Lan, In message <1334719161-3500-1-git-send-email-chunhe@freescale.com> you wrote: The -fPIC/-fpic flag belongs with -mrelocatable. The -fpic flag can limit the size of the GOT and produce smaller binaries, so it causes some GOT entries to be lost in the gcc 4.6 version. But -fPIC flag allows the maximum possible size of the GOT entries. However, currently -mrelocatable promotes -fpic flag to -fPIC flag. This reverts that portion of the commit 33ee4c92339ee386662c0ee2d221098c5cc8b07e. As you state yourself, your modification has the negative impact of increasing the image size. What would be the benefits of it? Are you trying to fix any specific problem? Which one? I am not aware of any related isses for any of the mainline PowerPC systems... Yes, I have fixed the booting issue of nand u-boot of P1010/P1022/P1023/P2020 with this patch. When use gcc 4.5 version, produce the size of u-boot-nand.bin to be same with -fpic or -fPIC. The u-boot-nand.bin is OK. But when use gcc 4.6 version, produce the size of u-boot-nand.bin to be different with -fpic or -fPIC. The some GOT entries of u-boot-nand.bin are lost with -fpic(because limit the size), so u-boot-nand.bin hangs when booting. But use -fPIC, the u-boot-nand.bin is OK. And this patch reverts that portion of the commit 33ee4c92339ee386662c0ee2d221098c5cc8b07e. Thanks, Chunhe Best regards, Wolfgang Denk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 7/9] imx: esdhc: Needed to use in imx-regs.h defined address
On 18.04.2012 11:43, Stefano Babic wrote: On 18/04/2012 09:57, Timo Ketola wrote: One might want to define CONFIG_SYS_FSL_ESDHC_ADDR with the macro already define in imx-regs.h, e.g. with IMX_MMC_SDHC1_BASE. Then the header must be included here. ... diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c ... +#include NAK. There is a good reason to avoid it. The fsl_esdhc driver is common to both i.MX and PowerPc architecture, and of course PowerPC have not imx-regs.h. And CONFIG_SYS_FSL_ESDHC_ADDR cannot be set by a macro in imx-regs.h, because it is different on PowerPC. Ok, I was afraid about something like that and tried first to include it in board configuration but that broke something else (at least arm926ejs didn't compile any more). By the way, why do you need it if you do not use that macro ? I use it in my board (support of which I'm preparing to send) configuration file and I think it is annoying to write a literal constant there which is already defined in imx-regs.h. PPC seems to use a predefined macro from asm/immap_8xxx.h files. Where is that file included? -- Timo ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 6/9] imx: usb: There is no such register
On 18/04/2012 09:57, Timo Ketola wrote: > The reference manual of i.MX25 (nor i.MX31) does not define such register. > This seems to access read only UH2_CAPLENGTH register (if > CONFIG_MXC_USB_PORT is zero). > > Signed-off-by: Timo Ketola Hi Timo, > --- > drivers/usb/host/ehci-mxc.c |2 -- > 1 files changed, 0 insertions(+), 2 deletions(-) > > diff --git a/drivers/usb/host/ehci-mxc.c b/drivers/usb/host/ehci-mxc.c > index 65f40a4..6f4df58 100644 > --- a/drivers/usb/host/ehci-mxc.c > +++ b/drivers/usb/host/ehci-mxc.c > @@ -126,8 +126,6 @@ int ehci_hcd_init(void) > HC_LENGTH(ehci_readl(&hccr->cr_capbase))); > setbits_le32(&ehci->usbmode, CM_HOST); > #if defined(CONFIG_MX31) || defined(CONFIG_MX25) As far as I can see, only MX31 and MX25 boards are using this file. Other i.MX have its own initialization file. So #if defined(CONFIG_MX31) || defined(CONFIG_MX25) is always true. However, where is this code ? In current u-boot I see only #if defined(CONFIG_MX31) at this line. Is it your patch correct ? > - setbits_le32(&ehci->control, USB_EN); > - As far as I can see, it tries to overwrite a capability register, that is for our luck read-only. Good catch ! Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] i.MX2: Support splash screen
Signed-off-by: Timo Ketola
---
arch/arm/include/asm/arch-mx25/imx-regs.h | 29 +
drivers/video/Makefile|1 +
drivers/video/mx2fb.c | 92 +
include/lcd.h | 21 ++-
include/mx2fb.h | 39
5 files changed, 181 insertions(+), 1 deletions(-)
create mode 100644 drivers/video/mx2fb.c
create mode 100644 include/mx2fb.h
diff --git a/arch/arm/include/asm/arch-mx25/imx-regs.h
b/arch/arm/include/asm/arch-mx25/imx-regs.h
index 7f9449b..af5b42e 100644
--- a/arch/arm/include/asm/arch-mx25/imx-regs.h
+++ b/arch/arm/include/asm/arch-mx25/imx-regs.h
@@ -167,6 +167,35 @@ struct aips_regs {
u32 mpr_8_15;
};
+struct lcdc_regs {
+ u32 lssar;
+ u32 lsr;
+ u32 lvpwr;
+ u32 lcpr;
+ u32 lcwhb;
+ u32 lccmr;
+ u32 lpcr;
+ u32 lhcr;
+ u32 lvcr;
+ u32 lpor;
+ u32 lscr;
+ u32 lpccr;
+ u32 ldcr;
+ u32 lrmcr;
+ u32 licr;
+ u32 lier;
+ u32 lisr;
+ u32 pad0[3];
+ u32 lgwsar;
+ u32 lgwsr;
+ u32 lgwvpwr;
+ u32 lgwpor;
+ u32 lgwpr;
+ u32 pad1[0x200 - 25];
+ u32 bglut[0x100];
+ u32 gwlut[0x100];
+};
+
#endif
/* AIPS 1 */
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index 6252f6a..e047471 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -36,6 +36,7 @@ COBJS-$(CONFIG_VIDEO_CT69000) += ct69000.o videomodes.o
COBJS-$(CONFIG_VIDEO_DA8XX) += da8xx-fb.o videomodes.o
COBJS-$(CONFIG_VIDEO_MB862xx) += mb862xx.o videomodes.o
COBJS-$(CONFIG_VIDEO_MB86R0xGDC) += mb86r0xgdc.o videomodes.o
+COBJS-$(CONFIG_VIDEO_MX2) += mx2fb.o
COBJS-$(CONFIG_VIDEO_MX3) += mx3fb.o videomodes.o
COBJS-$(CONFIG_VIDEO_MX5) += mxc_ipuv3_fb.o ipu_common.o ipu_disp.o
COBJS-$(CONFIG_VIDEO_OMAP3) += omap3_dss.o videomodes.o
diff --git a/drivers/video/mx2fb.c b/drivers/video/mx2fb.c
new file mode 100644
index 000..9ee4a3e
--- /dev/null
+++ b/drivers/video/mx2fb.c
@@ -0,0 +1,92 @@
+#include
+#include
+#include
+#include
+#include
+#include
+
+#if !defined(LCD_BPP) || LCD_BPP != LCD_COLOR16
+
+#error Only 16bpp is supported
+
+#endif
+
+DECLARE_GLOBAL_DATA_PTR;
+
+void *lcd_base;/* Start of framebuffer memory */
+void *lcd_console_address; /* Start of console buffer */
+
+int lcd_line_length;
+int lcd_color_fg;
+int lcd_color_bg;
+
+short console_col;
+short console_row;
+
+
+void lcd_initcolregs(void)
+{
+}
+
+void lcd_setcolreg(ushort regno, ushort red, ushort green, ushort blue)
+{
+}
+
+void lcd_enable(void)
+{
+}
+
+void lcd_disable(void)
+{
+}
+
+void lcd_panel_disable(void)
+{
+}
+
+void lcd_ctrl_init(void *lcdbase)
+{
+ u32 ccm_ipg_cg, pcr;
+ struct lcdc_regs *lcdc = (struct lcdc_regs *)IMX_LCDC_BASE;
+ struct ccm_regs *ccm = (struct ccm_regs *)IMX_CCM_BASE;
+
+ writel(gd->fb_base, &lcdc->lssar);
+ writel(panel_info.vl_col >> 4 << 20 | panel_info.vl_row, &lcdc->lsr);
+ writel(panel_info.vl_col / 2, &lcdc->lvpwr);
+ if (panel_info.vl_bpix != 4)
+ printf("Unsupported color depth (%d), only 16bpp supported\n",
+ NBITS(panel_info.vl_bpix));
+ pcr = LCDC_LPCR | 5 << 25;
+
+ if (panel_info.vl_sync & FB_SYNC_CLK_LAT_FALL)
+ pcr |= 0x0020;
+ if (panel_info.vl_sync & FB_SYNC_DATA_INVERT)
+ pcr |= 0x0100;
+ if (panel_info.vl_sync & FB_SYNC_SHARP_MODE)
+ pcr |= 0x0040;
+ if (panel_info.vl_sync & FB_SYNC_OE_LOW_ACT)
+ pcr |= 0x0010;
+
+ pcr |= LCDC_LPCR_PCD;
+
+ writel(pcr, &lcdc->lpcr);
+ writel((panel_info.vl_hsync - 1) << 26 |
+ (panel_info.vl_right_margin - 1) << 8 |
+ (panel_info.vl_left_margin - 3),
+ &lcdc->lhcr);
+ writel(panel_info.vl_vsync << 26 |
+ panel_info.vl_lower_margin << 8 |
+ panel_info.vl_upper_margin,
+ &lcdc->lvcr);
+ writel(LCDC_LSCR, &lcdc->lscr);
+ writel(LCDC_LRMCR, &lcdc->lrmcr);
+ writel(LCDC_LDCR, &lcdc->ldcr);
+ writel(LCDC_LPCCR, &lcdc->lpccr);
+
+ /* Off and on clock gating
+ FIXME: Why *off* and on; What side effects does it have? */
+ ccm_ipg_cg = readl(&ccm->cgr1);
+
+ writel(ccm_ipg_cg & 0xDFFF, &ccm->cgr1);
+ writel(ccm_ipg_cg | 0x2000, &ccm->cgr1);
+}
diff --git a/include/lcd.h b/include/lcd.h
index d95feeb..a5eeb53 100644
--- a/include/lcd.h
+++ b/include/lcd.h
@@ -183,6 +183,25 @@ typedef struct vidinfo {
u_long mmio; /* Memory mapped registers */
} vidinfo_t;
+#elif defined(CONFIG_VIDEO_MX2)
+
+struct vidinfo {
+ ushort vl_row; /* resolution in x */
+ ushort vl_col;
[U-Boot] [PATCH 0/1] i.MX2: Support splash screen
I based this on the work here: http://www.imxdev.org/wiki/index.php?title=I.MX25_PDK_U-boot_SplashScreen ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 7/9] imx: esdhc: Needed to use in imx-regs.h defined address
On 18/04/2012 09:57, Timo Ketola wrote: > One might want to define CONFIG_SYS_FSL_ESDHC_ADDR with the macro already > define in imx-regs.h, e.g. with IMX_MMC_SDHC1_BASE. Then the header must be > included here. > > Signed-off-by: Timo Ketola > --- > drivers/mmc/fsl_esdhc.c |1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c > index a2f35e3..5ada747 100644 > --- a/drivers/mmc/fsl_esdhc.c > +++ b/drivers/mmc/fsl_esdhc.c > @@ -36,6 +36,7 @@ > #include > #include > #include > +#include > NAK. There is a good reason to avoid it. The fsl_esdhc driver is common to both i.MX and PowerPc architecture, and of course PowerPC have not imx-regs.h. And CONFIG_SYS_FSL_ESDHC_ADDR cannot be set by a macro in imx-regs.h, because it is different on PowerPC. By the way, why do you need it if you do not use that macro ? Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/8 v3] i.MX25: Miscellaneus fixes
On 18/04/2012 09:57, Timo Ketola wrote: > These are the fixes I needed to do to get my board going. > Hi Timo, > Changes in v3: > - Dropped old patch number 8 "imx: nand: Don't invent new..." > - Changed the subject of patch 4 > - Changed the BBT pattern offsets (patch 4); They are now zero > as in Linux You must change the subject of the patch and introduce an enumeration. Your patchset should start with "[PATCH V3". This can easy automatically done by "git format-patch" with --subject-prefix "PATCH V3". Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/8 v3] i.MX25: Miscellaneus fixes
Hi, Please, don't get confused about the subject lines which suggest that I sent nine patches. At the last second I dropped the last patch and decided to send it separately. Stefano, did you get the "[PATCH 0/8 v3]..." message as a CC. I don't see you in CC list in the bounce I got myself and yet I have your address in .git/config *and* I see you in my following messages. I don't understand... -- Timo ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 8/9] imx: Add u-boot.imx as target for ARM9 i.MX SOCs
Signed-off-by: Timo Ketola --- arch/arm/cpu/arm926ejs/config.mk |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/arch/arm/cpu/arm926ejs/config.mk b/arch/arm/cpu/arm926ejs/config.mk index ffb2e6c..6a3a1bb 100644 --- a/arch/arm/cpu/arm926ejs/config.mk +++ b/arch/arm/cpu/arm926ejs/config.mk @@ -31,3 +31,9 @@ PLATFORM_CPPFLAGS += -march=armv5te # = PF_RELFLAGS_SLB_AT := $(call cc-option,-mshort-load-bytes,$(call cc-option,-malignment-traps,)) PLATFORM_RELFLAGS += $(PF_RELFLAGS_SLB_AT) + +ifneq ($(CONFIG_IMX_CONFIG),) + +ALL-y += $(obj)u-boot.imx + +endif -- 1.7.5.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 7/9] imx: esdhc: Needed to use in imx-regs.h defined address
One might want to define CONFIG_SYS_FSL_ESDHC_ADDR with the macro already define in imx-regs.h, e.g. with IMX_MMC_SDHC1_BASE. Then the header must be included here. Signed-off-by: Timo Ketola --- drivers/mmc/fsl_esdhc.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c index a2f35e3..5ada747 100644 --- a/drivers/mmc/fsl_esdhc.c +++ b/drivers/mmc/fsl_esdhc.c @@ -36,6 +36,7 @@ #include #include #include +#include DECLARE_GLOBAL_DATA_PTR; -- 1.7.5.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 6/9] imx: usb: There is no such register
The reference manual of i.MX25 (nor i.MX31) does not define such register. This seems to access read only UH2_CAPLENGTH register (if CONFIG_MXC_USB_PORT is zero). Signed-off-by: Timo Ketola --- drivers/usb/host/ehci-mxc.c |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/drivers/usb/host/ehci-mxc.c b/drivers/usb/host/ehci-mxc.c index 65f40a4..6f4df58 100644 --- a/drivers/usb/host/ehci-mxc.c +++ b/drivers/usb/host/ehci-mxc.c @@ -126,8 +126,6 @@ int ehci_hcd_init(void) HC_LENGTH(ehci_readl(&hccr->cr_capbase))); setbits_le32(&ehci->usbmode, CM_HOST); #if defined(CONFIG_MX31) || defined(CONFIG_MX25) - setbits_le32(&ehci->control, USB_EN); - __raw_writel(CONFIG_MXC_USB_PORTSC, &ehci->portsc); #endif mxc_set_usbcontrol(CONFIG_MXC_USB_PORT, CONFIG_MXC_USB_FLAGS); -- 1.7.5.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 5/9] i.MX25: This architecture has almost the same USB-controller as i.MX31
Signed-off-by: Timo Ketola --- drivers/usb/host/ehci-mxc.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/usb/host/ehci-mxc.c b/drivers/usb/host/ehci-mxc.c index 61dbccd..65f40a4 100644 --- a/drivers/usb/host/ehci-mxc.c +++ b/drivers/usb/host/ehci-mxc.c @@ -125,7 +125,7 @@ int ehci_hcd_init(void) hcor = (struct ehci_hcor *)((uint32_t) hccr + HC_LENGTH(ehci_readl(&hccr->cr_capbase))); setbits_le32(&ehci->usbmode, CM_HOST); -#ifdef CONFIG_MX31 +#if defined(CONFIG_MX31) || defined(CONFIG_MX25) setbits_le32(&ehci->control, USB_EN); __raw_writel(CONFIG_MXC_USB_PORTSC, &ehci->portsc); -- 1.7.5.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/9] imx: nand: Support flash based BBT
Signed-off-by: Timo Ketola
---
drivers/mtd/nand/mxc_nand.c | 35 +++
1 files changed, 35 insertions(+), 0 deletions(-)
diff --git a/drivers/mtd/nand/mxc_nand.c b/drivers/mtd/nand/mxc_nand.c
index 35e89a0..d97e7c3 100644
--- a/drivers/mtd/nand/mxc_nand.c
+++ b/drivers/mtd/nand/mxc_nand.c
@@ -1302,12 +1302,47 @@ static void mxc_setup_config1(void)
#define mxc_setup_config1()
#endif
+#ifdef CONFIG_SYS_NAND_USE_FLASH_BBT
+
+static u8 bbt_pattern[] = {'B', 'b', 't', '0' };
+static u8 mirror_pattern[] = {'1', 't', 'b', 'B' };
+
+static struct nand_bbt_descr bbt_main_descr = {
+ .options = NAND_BBT_LASTBLOCK | NAND_BBT_CREATE | NAND_BBT_WRITE |
+ NAND_BBT_2BIT | NAND_BBT_VERSION | NAND_BBT_PERCHIP,
+ .offs = 0,
+ .len = 4,
+ .veroffs = 4,
+ .maxblocks = 4,
+ .pattern = bbt_pattern,
+};
+
+static struct nand_bbt_descr bbt_mirror_descr = {
+ .options = NAND_BBT_LASTBLOCK | NAND_BBT_CREATE | NAND_BBT_WRITE |
+ NAND_BBT_2BIT | NAND_BBT_VERSION | NAND_BBT_PERCHIP,
+ .offs = 0,
+ .len = 4,
+ .veroffs = 4,
+ .maxblocks = 4,
+ .pattern = mirror_pattern,
+};
+
+#endif
+
int board_nand_init(struct nand_chip *this)
{
struct mtd_info *mtd;
uint16_t tmp;
int err = 0;
+#ifdef CONFIG_SYS_NAND_USE_FLASH_BBT
+
+ this->options = NAND_USE_FLASH_BBT;
+ this->bbt_td = &bbt_main_descr;
+ this->bbt_md = &bbt_mirror_descr;
+
+#endif
+
/* structures must be linked */
mtd = &host->mtd;
mtd->priv = this;
--
1.7.5.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/9] imx: fec: Resolve speed before configuring gasket
Gasket needs a different configuration for 10BaseT than for higher speeds.
Signed-off-by: Timo Ketola
---
drivers/net/fec_mxc.c | 43 ---
1 files changed, 24 insertions(+), 19 deletions(-)
diff --git a/drivers/net/fec_mxc.c b/drivers/net/fec_mxc.c
index 824a199..48a69d4 100644
--- a/drivers/net/fec_mxc.c
+++ b/drivers/net/fec_mxc.c
@@ -440,6 +440,22 @@ static int fec_open(struct eth_device *edev)
*/
writel(readl(&fec->eth->ecntrl) | FEC_ECNTRL_ETHER_EN,
&fec->eth->ecntrl);
+#ifdef CONFIG_PHYLIB
+ if (!fec->phydev)
+ fec_eth_phy_config(edev);
+ if (fec->phydev) {
+ /* Start up the PHY */
+ phy_startup(fec->phydev);
+ speed = fec->phydev->speed;
+ } else {
+ speed = _100BASET;
+ }
+#else
+ miiphy_wait_aneg(edev);
+ speed = miiphy_speed(edev->name, fec->phy_id);
+ miiphy_duplex(edev->name, fec->phy_id);
+#endif
+
#if defined(CONFIG_MX25) || defined(CONFIG_MX53)
udelay(100);
/*
@@ -453,9 +469,14 @@ static int fec_open(struct eth_device *edev)
while (readw(&fec->eth->miigsk_enr) & MIIGSK_ENR_READY)
udelay(2);
-#if !defined(CONFIG_MII)
- /* configure gasket for RMII, 50 MHz, no loopback, and no echo */
- writew(MIIGSK_CFGR_IF_MODE_RMII, &fec->eth->miigsk_cfgr);
+#if defined(CONFIG_RMII)
+ if (speed != _10BASET)
+ /* configure gasket for RMII, 50MHz, no loopback, and no echo */
+ writew(MIIGSK_CFGR_IF_MODE_RMII, &fec->eth->miigsk_cfgr);
+ else
+ /* configure gasket for RMII, 5MHz, no loopback, and no echo */
+ writew(MIIGSK_CFGR_IF_MODE_RMII | MIIGSK_CFGR_FRCONT,
+ &fec->eth->miigsk_cfgr);
#else
/* configure gasket for MII, no loopback, and no echo */
writew(MIIGSK_CFGR_IF_MODE_MII, &fec->eth->miigsk_cfgr);
@@ -474,22 +495,6 @@ static int fec_open(struct eth_device *edev)
}
#endif
-#ifdef CONFIG_PHYLIB
- if (!fec->phydev)
- fec_eth_phy_config(edev);
- if (fec->phydev) {
- /* Start up the PHY */
- phy_startup(fec->phydev);
- speed = fec->phydev->speed;
- } else {
- speed = _100BASET;
- }
-#else
- miiphy_wait_aneg(edev);
- speed = miiphy_speed(edev->name, fec->phy_id);
- miiphy_duplex(edev->name, fec->phy_id);
-#endif
-
#ifdef FEC_QUIRK_ENET_MAC
{
u32 ecr = readl(&fec->eth->ecntrl) & ~FEC_ECNTRL_SPEED;
--
1.7.5.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/9] i.MX25: This architecture has a GPIO4 too
Signed-off-by: Timo Ketola
---
drivers/gpio/mxc_gpio.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/gpio/mxc_gpio.c b/drivers/gpio/mxc_gpio.c
index df6..3e94ac3 100644
--- a/drivers/gpio/mxc_gpio.c
+++ b/drivers/gpio/mxc_gpio.c
@@ -40,7 +40,8 @@ static unsigned long gpio_ports[] = {
[0] = GPIO1_BASE_ADDR,
[1] = GPIO2_BASE_ADDR,
[2] = GPIO3_BASE_ADDR,
-#if defined(CONFIG_MX51) || defined(CONFIG_MX53) || defined(CONFIG_MX6Q)
+#if defined(CONFIG_MX25) || defined(CONFIG_MX51) || defined(CONFIG_MX53) || \
+ defined(CONFIG_MX6Q)
[3] = GPIO4_BASE_ADDR,
#endif
#if defined(CONFIG_MX53) || defined(CONFIG_MX6Q)
--
1.7.5.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/9] i.MX25: esdhc: Add mxc_get_clock infrastructure
Defining CONFIG_FSL_ESDHC brings in a call to get_clocks, so let's implement
get_clocks function. This is how it seems to be implemented elsewhere.
Signed-off-by: Timo Ketola
---
arch/arm/cpu/arm926ejs/mx25/generic.c | 27 +++
arch/arm/include/asm/arch-mx25/clock.h | 23 +++
2 files changed, 50 insertions(+), 0 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/mx25/generic.c
b/arch/arm/cpu/arm926ejs/mx25/generic.c
index 9cadb7c..8b07dae 100644
--- a/arch/arm/cpu/arm926ejs/mx25/generic.c
+++ b/arch/arm/cpu/arm926ejs/mx25/generic.c
@@ -28,10 +28,15 @@
#include
#include
#include
+#include
#ifdef CONFIG_MXC_MMC
#include
#endif
+#ifdef CONFIG_FSL_ESDHC
+DECLARE_GLOBAL_DATA_PTR;
+#endif
+
/*
* get the system pll clock in Hz
*
@@ -105,6 +110,20 @@ ulong imx_get_perclk(int clk)
return lldiv(fref, div);
}
+unsigned int mxc_get_clock(enum mxc_clock clk)
+{
+ if (clk >= MXC_CLK_NUM)
+ return -1;
+ switch (clk) {
+ case MXC_ARM_CLK:
+ return imx_get_armclk();
+ case MXC_FEC_CLK:
+ return imx_get_ahbclk();
+ default:
+ return imx_get_perclk(clk);
+ }
+}
+
u32 get_cpu_rev(void)
{
u32 srev;
@@ -182,6 +201,14 @@ int cpu_eth_init(bd_t *bis)
#endif
}
+int get_clocks(void)
+{
+#ifdef CONFIG_FSL_ESDHC
+ gd->sdhc_clk = mxc_get_clock(MXC_ESDHC_CLK);
+#endif
+ return 0;
+}
+
/*
* Initializes on-chip MMC controllers.
* to override, implement board_mmc_init()
diff --git a/arch/arm/include/asm/arch-mx25/clock.h
b/arch/arm/include/asm/arch-mx25/clock.h
index c59f588..0f47eaf 100644
--- a/arch/arm/include/asm/arch-mx25/clock.h
+++ b/arch/arm/include/asm/arch-mx25/clock.h
@@ -26,11 +26,34 @@
#ifndef __ASM_ARCH_CLOCK_H
#define __ASM_ARCH_CLOCK_H
+enum mxc_clock {
+ MXC_CSI_CLK,
+ MXC_EPIT_CLK,
+ MXC_ESAI_CLK,
+ MXC_ESDHC1_CLK,
+ MXC_ESDHC2_CLK,
+ MXC_GPT_CLK,
+ MXC_I2C_CLK,
+ MXC_LCDC_CLK,
+ MXC_NFC_CLK,
+ MXC_OWIRE_CLK,
+ MXC_PWM_CLK,
+ MXC_SIM1_CLK,
+ MXC_SIM2_CLK,
+ MXC_SSI1_CLK,
+ MXC_SSI2_CLK,
+ MXC_UART_CLK,
+ MXC_ARM_CLK,
+ MXC_FEC_CLK,
+ MXC_CLK_NUM
+};
+
ulong imx_get_perclk(int clk);
ulong imx_get_ahbclk(void);
#define imx_get_uartclk() imx_get_perclk(15)
#define imx_get_fecclk() (imx_get_ahbclk()/2)
+unsigned int mxc_get_clock(enum mxc_clock clk);
#endif /* __ASM_ARCH_CLOCK_H */
--
1.7.5.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/8 v3] i.MX25: Miscellaneus fixes
These are the fixes I needed to do to get my board going. Changes in v3: - Dropped old patch number 8 "imx: nand: Don't invent new..." - Changed the subject of patch 4 - Changed the BBT pattern offsets (patch 4); They are now zero as in Linux Changes in v2: - Rebased to u-boot-imx next - Patch 2: Fixed too long lines - Patch 3: Try not to break Gbit ether Changed configuration option putting gasket into RMII mode to CONFIG_RMII I'm not too sure how this should be done. CONFIG_MII is normally used for this but its original purpose was to enable MII *management* interface, I think... - Patch 9: Add .imx target in the spirit of commit 303838 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: ea20: Change macro from BOARD_LATE_INIT to CONFIG_BOARD_LATE_INIT
On 18/04/2012 04:41, Nobuhiro Iwamatsu wrote:
> With almost all the architecture and board BOARD_LATE_INIT does not use.
> CONFIG_BOARD_LATE_INIT is used instead.
> This changed CONFIG_BOARD_LATE_INIT from BOARD_LATE_INIT.
>
> Signed-off-by: Nobuhiro Iwamatsu
> CC: Stefano Babic
> ---
> board/davinci/ea20/ea20.c |4 ++--
> include/configs/ea20.h|2 +-
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/board/davinci/ea20/ea20.c b/board/davinci/ea20/ea20.c
> index 43632c2..7e00040 100644
> --- a/board/davinci/ea20/ea20.c
> +++ b/board/davinci/ea20/ea20.c
> @@ -272,7 +272,7 @@ int board_init(void)
> return 0;
> }
>
> -#ifdef BOARD_LATE_INIT
> +#ifdef CONFIG_BOARD_LATE_INIT
>
> int board_late_init(void)
> {
> @@ -287,7 +287,7 @@ int board_late_init(void)
>
> return 0;
> }
> -#endif /* BOARD_LATE_INIT */
> +#endif /* CONFIG_BOARD_LATE_INIT */
>
> #ifdef CONFIG_DRIVER_TI_EMAC
>
> diff --git a/include/configs/ea20.h b/include/configs/ea20.h
> index e059b30..2c44ddb 100644
> --- a/include/configs/ea20.h
> +++ b/include/configs/ea20.h
> @@ -31,7 +31,7 @@
> #define CONFIG_SYS_USE_NAND
> #define CONFIG_DRIVER_TI_EMAC_USE_RMII
> #define CONFIG_BOARD_EARLY_INIT_F
> -#define BOARD_LATE_INIT
> +#define CONFIG_BOARD_LATE_INIT
> #define CONFIG_VIDEO
> #define CONFIG_PREBOOT
>
Acked-by: Stefano Babic
Thanks,
Stefano Babic
--
=
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mmc:fix Call mmc_init() when executing mmc_get_dev()
Hi, Minkyu
> Hi Lukasz,
>
> On 3 April 2012 23:24, Lukasz Majewski wrote:
> > This code adds call to mmc_init(), for partition related commands
> > (e.g. fatls, fatinfo etc.).
> >
> > It is safe to call mmc_init() multiple times since mmc->has_init
> > flag prevents from multiple initialization.
> >
> > The FAT related code calls get_dev high level method and then uses
> > elements from mmc->block_dev, which is uninitialized until the
> > mmc_init (and thereof mmc_startup) is called.
> >
> > This problem appears on boards, which don't use mmc as the default
> > place for envs
> >
> > Signed-off-by: Lukasz Majewski
> > Signed-off-by: Kyungmin Park
> > Cc: Andy Fleming
> >
> > ---
> > Test HW:
> > - GONI S5PC110
> > - Universal C210 (Exynos4)
> > ---
> > drivers/mmc/mmc.c | 6 +-
> > 1 files changed, 5 insertions(+), 1 deletions(-)
> >
> > diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
> > index 618960e..1fa90e7 100644
> > --- a/drivers/mmc/mmc.c
> > +++ b/drivers/mmc/mmc.c
> > @@ -1305,8 +1305,12 @@ int mmc_register(struct mmc *mmc)
> > block_dev_desc_t *mmc_get_dev(int dev)
> > {
> > struct mmc *mmc = find_mmc_device(dev);
> > + if (mmc) {
> > + mmc_init(mmc);
> > + return &mmc->block_dev;
> > + }
> >
> > - return mmc ? &mmc->block_dev : NULL;
> > + return NULL;
> > }
> > #endif
> >
>
> I think
>
> if (!mmc)
> return NULL;
>
> mmc_init(mmc);
> return &mmc->block_dev;
>
> is better.
> How you think?
Yes, it seems also more readable for me.
But anyway Andy shall express his opinion.
--
Best regards,
Lukasz Majewski
Samsung Poland R&D Center
Platform Group
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] PowerPC: Change -fpic flag to -fPIC flag in the config.mk
Dear Chunhe Lan, In message <4f8e5f11.4020...@freescale.com> you wrote: > > > > http://lists.denx.de/mailman/listinfo/u-boot
