Re: [U-Boot] smc911x not functional on top of tree
On 09/16/2011 01:13 AM, Fabio Estevam wrote: > Hi Stefano, > > On Thu, Sep 15, 2011 at 5:21 PM, stefano babic wrote: > .. >>> Does anyone have smc911x working with the latest U-boot? >> >> I have now tested on a mx35pdk with Debug board. It has a SMC911x. It works: > > Thanks for testing! I tried it at home and it is working fine here. > > Maybe it was an issue at the company's network. Your network works better as your company's network. 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-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL boot modes
On Fri, Sep 16, 2011 at 1:11 AM, Joel A Fernandes wrote: > Hi Simon, > > Great work on the SPL patches for omap. I am getting a bit familiar > with this and earlier SPL work. > > Just one question about one of your patches I happen to notice [1], Sorry, I was referring to this patch: http://patchwork.ozlabs.org/patch/107431/ Thanks, Joel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] SPL boot modes
Hi Simon, Great work on the SPL patches for omap. I am getting a bit familiar with this and earlier SPL work. Just one question about one of your patches I happen to notice [1], why is there a SPL build for each different boot mode such as for NAND, MMC etc?. Wouldn't it be nicer to have a single SPL loader that tried different boot modes one after the other, something like what x-load already does? Are there are any challenges with this approach? Thanks! Joel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm, usb, davinci: make USBPHY_CTL register configurable
Hello Albert,
Albert ARIBAUD wrote:
> Hi all,
>
> Le 09/08/2011 07:05, Heiko Schocher a écrit :
>> Hello Remy,
>>
>> Remy Bohmer wrote:
>>> Hi,
>>>
>>> 2011/8/2 Heiko Schocher:
Define CONFIG_DV_USBPHY_CTL for setting the USB PHY control
register.
Signed-off-by: Heiko Schocher
cc: Sandeep Paulraj
cc: Remy Bohmer
---
drivers/usb/musb/davinci.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/musb/davinci.c b/drivers/usb/musb/davinci.c
index f56f2df..98c2c62 100644
--- a/drivers/usb/musb/davinci.c
+++ b/drivers/usb/musb/davinci.c
@@ -26,6 +26,10 @@
#include "davinci.h"
#include
+#if !defined(CONFIG_DV_USBPHY_CTL)
+#define CONFIG_DV_USBPHY_CTL (USBPHY_SESNDEN | USBPHY_VBDTCTEN)
+#endif
+
/* MUSB platform configuration */
struct musb_config musb_cfg = {
.regs = (struct musb_regs *)MENTOR_USB0_BASE,
@@ -50,7 +54,7 @@ static u8 phy_on(void)
writel(USBPHY_PHY24MHZ | USBPHY_SESNDEN |
USBPHY_VBDTCTEN, USBPHY_CTL_PADDR);
#else
- writel(USBPHY_SESNDEN | USBPHY_VBDTCTEN, USBPHY_CTL_PADDR);
+ writel(CONFIG_DV_USBPHY_CTL, USBPHY_CTL_PADDR);
#endif
timeout = musb_cfg.timeout;
>>>
>>> What does it fix, why do you want this?
>>
>> I posted the cam_enc_4xx board support. Now adding USB support, and I
>> have to configure this register as:
>>
>> #define CONFIG_DV_USBPHY_CTL (USBPHY_SESNDEN | USBPHY_VBDTCTEN | \
>> USBPHY_PHY24MHZ)
>>
>> so I need a possibility to configure this register ... and I could not
>> use DAVINCI_DM365EVM! (BTW: This define (so it seems to me) hides
>> board specific code, which should be cleaned up ... Sandeep?)
>>
>> bye,
>> Heiko
>
> No new reply on this since early august... Personally, I'd rather this
> patch came in a patchset where some other patch uses it.
Hmm.. Anyway I have to resend the cam_enc_4xx board port, as now the new
SPL Framework is in mainline, and my post used the old one. Also
I added in the meantime USB support for it, for which I needed this patch.
But actually I am wating for a new HW, so I can't test it ... and then
I post this patchset again with this patch in it! Can I add then your
"Acked-by" for this patch?
Thanks
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] net, davinci_emac: add KSZ8864 switch
Hello Mike, Mike Frysinger wrote: > On Thursday, September 15, 2011 01:36:09 Heiko Schocher wrote: >> --- /dev/null >> +++ b/arch/arm/cpu/arm926ejs/davinci/ksz8873.c >> >> +#ifdef CONFIG_DRIVER_TI_EMAC > > this file is only built when this is defined, so this is useless > >> +#ifdef CONFIG_CMD_NET > > building net drivers but not enabling CMD_NET is a config error. dont bother > checking this yourself. Post this change in a v2, thanks for the review! bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] mx31pdk: Change the prompt as per other i.MX boards
Change the prompt as done in other i.MX boards. Signed-off-by: Fabio Estevam --- include/configs/mx31pdk.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/include/configs/mx31pdk.h b/include/configs/mx31pdk.h index e77805c..7f91f67 100644 --- a/include/configs/mx31pdk.h +++ b/include/configs/mx31pdk.h @@ -123,7 +123,7 @@ * Miscellaneous configurable options */ #define CONFIG_SYS_LONGHELP/* undef to save memory */ -#define CONFIG_SYS_PROMPT "uboot> " +#define CONFIG_SYS_PROMPT "MX31PDK U-Boot > " #define CONFIG_SYS_CBSIZE 256 /* Console I/O Buffer Size */ /* Print Buffer Size */ #define CONFIG_SYS_PBSIZE (CONFIG_SYS_CBSIZE + \ -- 1.6.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] mx31pdk: Disable watchdog
When booting a mainline kernel on a mx31pdk the system gets getting resets from the watchdog. As the kernel has watchdog support, disable it from U-boot. Signed-off-by: Fabio Estevam --- include/configs/mx31pdk.h |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/include/configs/mx31pdk.h b/include/configs/mx31pdk.h index 1a5bdd1..e77805c 100644 --- a/include/configs/mx31pdk.h +++ b/include/configs/mx31pdk.h @@ -60,7 +60,6 @@ #define CONFIG_MXC_UART #define CONFIG_SYS_MX31_UART1 -#define CONFIG_HW_WATCHDOG #define CONFIG_MXC_GPIO #define CONFIG_HARD_SPI -- 1.6.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] ARM ISA/cpu/SoC code organization for cache and other functions
On Thu, Sep 15, 2011 at 07:10:49PM -0400, Jason wrote: > Albert, > > On Thu, Sep 15, 2011 at 11:42:12PM +0200, Albert ARIBAUD wrote: > > (re-posting cleaned up and outside any other discussion) > > > > This RFC is for discussing how cache operation functions should be > > managed in the ARM tree. > ... > > The source code implementation for ARM cache ops would be: > > > > - a header file declaring the ops as weak C functions for at least full > > cache flush, full cache invalidate, cache line flush and cache line > > invalidate; > > > > - SoC-specific, cpu-specific, and isa-specific definitions for these > > functions, in the form of C files. > > > > - a default implementation in a lib/ file. > > > > The object files shall be linked in decreasing precedence order, i.e. > > SoC file first, then cpu file, then isa file, then lib last, so that for > > each cache op, the weak symbol mechanism uses the most specific one. > > > > One possible organisation for files would be (switch to fixed size font) > > > > (isa) (cpu) SoC) > > arch/arm > > /armv5t/ > > cache-ops.c > > arm926ejs/ > >cache-ops.c > >orion5x/ > >cache-ops.c > > > > Plus of course arch/arm/lib/cache-ops.c. > > As a new-comer to the u-boot code, is there a difference between this > implementation and say, a struct of function pointers? eg the struct > would default to armv5t ops, and arm926ejs init could redefine, say, s/redefine/reassign/ > cache line invalidate. > > The reason I ask is that I think the struct of function pointers would > be easier for new folks to sort out with cscope, et al. Whereas, the > weak declarations with multiple implementations would muddy the waters > when learning the code. > > Am I missing something? What are the advantages of weak declarations > over redefined function pointers? > > thx, > > Jason. > ___ > 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 2/2 RESEND] SPL: Allow user to disable CPU support library
On Friday, September 16, 2011 12:57:44 AM Scott Wood wrote: > On 09/11/2011 11:03 PM, Marek Vasut wrote: > > Introduce CONFIG_SPL_NO_CPU_SUPPORT_CODE to avoid compiling the CPU > > support library. This can be useful on some setups. > > > > Signed-off-by: Marek Vasut > > Cc: Stefano Babic > > Cc: Wolfgang Denk > > Cc: Detlev Zundel > > Cc: Chander Kashyap > > But you didn't CC these... git send-email should handle those ? > > > --- > > > > spl/Makefile |7 ++- > > 1 files changed, 6 insertions(+), 1 deletions(-) > > > > diff --git a/spl/Makefile b/spl/Makefile > > index 56d8ea1..63d1a8a 100644 > > --- a/spl/Makefile > > +++ b/spl/Makefile > > @@ -20,6 +20,11 @@ export CONFIG_SPL_BUILD > > > > include $(TOPDIR)/config.mk > > > > +# In case we want to avoid the CPU support code, we need to define this: > > +ifndef CONFIG_SPL_NO_CPU_SUPPORT_CODE > > +SPL_CPU_SUPPORT_CODE := y > > +endif > > SPL should ideally contain nothing by default. Have options that say > what you do want to pull in, not what you don't want. You usually DO want to pull this in (because it contains vectoring code, really basic lowlevel init etc), there are only border cases where you do not want to do that and use your own. Cheers > > -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2] FEC: Allow multiple FECes
This patch allows user to register multiple FEC controllers. To preserve
compatibility with older boards, the mxcfec_register() call is still in place.
To use multiple controllers, new macro is in place, the mxcfec_register_multi(),
which takes more arguments. The syntax is:
mxcfec_register_multi(bd, FEC ID, FEC PHY ID on the MII bus, base address);
To disable the fecmxc_register() compatibility stuff, define the macro
CONFIG_FEC_MXC_MULTI. This will remove the requirement for defining IMX_FEC_BASE
and CONFIG_FEC_MXC_PHYADDR.
Signed-off-by: Marek Vasut
Cc: Ben Warren
Cc: Stefano Babic
Cc: Wolfgang Denk
Cc: Detlev Zundel
---
drivers/net/fec_mxc.c | 79 ++--
drivers/net/fec_mxc.h |2 +
include/netdev.h |2 +-
3 files changed, 52 insertions(+), 31 deletions(-)
V2: Adjust after recent netdev.h change bd6ce9d171b45465daa23bede5214100dd8b5eba
diff --git a/drivers/net/fec_mxc.c b/drivers/net/fec_mxc.c
index d448496..3c593aa 100644
--- a/drivers/net/fec_mxc.c
+++ b/drivers/net/fec_mxc.c
@@ -51,18 +51,6 @@ struct nbuf {
uint8_t head[16]; /**< MAC header(6 + 6 + 2) + 2(aligned) */
};
-struct fec_priv gfec = {
- .eth = (struct ethernet_regs *)IMX_FEC_BASE,
- .xcv_type = MII100,
- .rbd_base = NULL,
- .rbd_index = 0,
- .tbd_base = NULL,
- .tbd_index = 0,
- .bd= NULL,
- .rdb_ptr = NULL,
- .base_ptr = NULL,
-};
-
/*
* MII-interface related functions
*/
@@ -164,26 +152,27 @@ static int fec_miiphy_write(const char *dev, uint8_t
phyAddr, uint8_t regAddr,
static int miiphy_restart_aneg(struct eth_device *dev)
{
+ struct fec_priv *fec = (struct fec_priv *)dev->priv;
+
/*
* Wake up from sleep if necessary
* Reset PHY, then delay 300ns
*/
#ifdef CONFIG_MX27
- miiphy_write(dev->name, CONFIG_FEC_MXC_PHYADDR, MII_DCOUNTER, 0x00FF);
+ miiphy_write(dev->name, fec->phy_id, MII_DCOUNTER, 0x00FF);
#endif
- miiphy_write(dev->name, CONFIG_FEC_MXC_PHYADDR, MII_BMCR,
+ miiphy_write(dev->name, fec->phy_id, MII_BMCR,
BMCR_RESET);
udelay(1000);
/*
* Set the auto-negotiation advertisement register bits
*/
- miiphy_write(dev->name, CONFIG_FEC_MXC_PHYADDR, MII_ADVERTISE,
+ miiphy_write(dev->name, fec->phy_id, MII_ADVERTISE,
LPA_100FULL | LPA_100HALF | LPA_10FULL |
LPA_10HALF | PHY_ANLPAR_PSB_802_3);
- miiphy_write(dev->name, CONFIG_FEC_MXC_PHYADDR, MII_BMCR,
+ miiphy_write(dev->name, fec->phy_id, MII_BMCR,
BMCR_ANENABLE | BMCR_ANRESTART);
-
return 0;
}
@@ -191,6 +180,7 @@ static int miiphy_wait_aneg(struct eth_device *dev)
{
uint32_t start;
uint16_t status;
+ struct fec_priv *fec = (struct fec_priv *)dev->priv;
/*
* Wait for AN completion
@@ -202,7 +192,7 @@ static int miiphy_wait_aneg(struct eth_device *dev)
return -1;
}
- if (miiphy_read(dev->name, CONFIG_FEC_MXC_PHYADDR,
+ if (miiphy_read(dev->name, fec->phy_id,
MII_BMSR, &status)) {
printf("%s: Autonegotiation failed. status: 0x%04x\n",
dev->name, status);
@@ -390,8 +380,8 @@ static int fec_open(struct eth_device *edev)
#endif
miiphy_wait_aneg(edev);
- miiphy_speed(edev->name, CONFIG_FEC_MXC_PHYADDR);
- miiphy_duplex(edev->name, CONFIG_FEC_MXC_PHYADDR);
+ miiphy_speed(edev->name, fec->phy_id);
+ miiphy_duplex(edev->name, fec->phy_id);
/*
* Enable SmartDMA receive task
@@ -406,7 +396,9 @@ static int fec_init(struct eth_device *dev, bd_t* bd)
{
uint32_t base;
struct fec_priv *fec = (struct fec_priv *)dev->priv;
+ uint32_t mib_ptr = (uint32_t)&fec->eth->rmon_t_drop;
uint32_t rcntrl;
+ int i;
/* Initialize MAC address */
fec_set_hwaddr(dev);
@@ -477,9 +469,8 @@ static int fec_init(struct eth_device *dev, bd_t* bd)
/* clear MIB RAM */
- long *mib_ptr = (long *)(IMX_FEC_BASE + 0x200);
- while (mib_ptr <= (long *)(IMX_FEC_BASE + 0x2FC))
- *mib_ptr++ = 0;
+ for (i = mib_ptr; i <= mib_ptr + 0xfc; i += 4)
+ writel(0, i);
/* FIFO receive start register */
writel(0x520, &fec->eth->r_fstart);
@@ -513,7 +504,7 @@ static int fec_init(struct eth_device *dev, bd_t* bd)
*/
static void fec_halt(struct eth_device *dev)
{
- struct fec_priv *fec = &gfec;
+ struct fec_priv *fec = (struct fec_priv *)dev->priv;
int counter = 0x;
/*
@@ -694,19 +685,28 @@ static int fec_recv(struct eth_device *dev)
return len;
}
-static int fec_probe(bd_t *bd)
+static int fec_probe(bd_t *bd, int
Re: [U-Boot] smc911x not functional on top of tree
Hi Stefano, On Thu, Sep 15, 2011 at 5:21 PM, stefano babic wrote: .. >> Does anyone have smc911x working with the latest U-boot? > > I have now tested on a mx35pdk with Debug board. It has a SMC911x. It works: Thanks for testing! I tried it at home and it is working fine here. Maybe it was an issue at the company's network. Thanks, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] ARM ISA/cpu/SoC code organization for cache and other functions
Albert, On Thu, Sep 15, 2011 at 11:42:12PM +0200, Albert ARIBAUD wrote: > (re-posting cleaned up and outside any other discussion) > > This RFC is for discussing how cache operation functions should be > managed in the ARM tree. ... > The source code implementation for ARM cache ops would be: > > - a header file declaring the ops as weak C functions for at least full > cache flush, full cache invalidate, cache line flush and cache line > invalidate; > > - SoC-specific, cpu-specific, and isa-specific definitions for these > functions, in the form of C files. > > - a default implementation in a lib/ file. > > The object files shall be linked in decreasing precedence order, i.e. > SoC file first, then cpu file, then isa file, then lib last, so that for > each cache op, the weak symbol mechanism uses the most specific one. > > One possible organisation for files would be (switch to fixed size font) > > (isa) (cpu) SoC) > arch/arm > /armv5t/ > cache-ops.c > arm926ejs/ >cache-ops.c >orion5x/ >cache-ops.c > > Plus of course arch/arm/lib/cache-ops.c. As a new-comer to the u-boot code, is there a difference between this implementation and say, a struct of function pointers? eg the struct would default to armv5t ops, and arm926ejs init could redefine, say, cache line invalidate. The reason I ask is that I think the struct of function pointers would be easier for new folks to sort out with cscope, et al. Whereas, the weak declarations with multiple implementations would muddy the waters when learning the code. Am I missing something? What are the advantages of weak declarations over redefined function pointers? thx, Jason. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] SPL: Make path to start.S configurable
On Friday, September 16, 2011 12:54:26 AM Scott Wood wrote: > On 09/11/2011 10:56 PM, Marek Vasut wrote: > > Introduce CONFIG_SPL_START_S_PATH to configure path to start.S file. It's > > not always fitting to use CPU's start.S . > > > > Signed-off-by: Marek Vasut > > --- > > > > spl/Makefile | 10 -- > > 1 files changed, 8 insertions(+), 2 deletions(-) > > > > diff --git a/spl/Makefile b/spl/Makefile > > index 95ecce1..56d8ea1 100644 > > --- a/spl/Makefile > > +++ b/spl/Makefile > > @@ -26,7 +26,13 @@ obj := $(OBJTREE)/spl/ > > > > HAVE_VENDOR_COMMON_LIB := $(shell [ -f > > $(SRCTREE)/board/$(VENDOR)/common/Makefile ] \ > > > > && echo y || echo n) > > > > -START := $(CPUDIR)/start.o > > +ifdef CONFIG_SPL_START_S_PATH > > +START_PATH := $(subst ",,$(CONFIG_SPL_START_S_PATH)) > > +else > > +START_PATH := $(CPUDIR) > > +endif > > + > > +START := $(START_PATH)/start.o > > So you can override the path, but not the filename? What if I want to > have arch/.../cpu/.../start-nand-spl.o? > > How about: > > ifdef CONFIG_SPL_START_FILE > START := $(subst ",,$(CONFIG_SPL_START_FILE)) > else > START := $(CPUDIR)/start.o > endif > > START_PATH := $(dir $(START)) > > > LIBS-y += arch/$(ARCH)/lib/lib$(ARCH).o > > LIBS-y += $(CPUDIR)/lib$(CPU).o > > > > @@ -119,7 +125,7 @@ $(obj)u-boot-spl: depend $(START) $(LIBS) > > $(obj)u-boot-spl.lds > > > > $(GEN_UBOOT) > > > > $(START): depend > > > > - $(MAKE) -C $(SRCTREE)/$(CPUDIR) $@ > > + $(MAKE) -C $(SRCTREE)/$(START_PATH) $@ > > Yay recursive make. :-P Yea ... that's why that START_PATH is needed. We can of course have CONFIG_SPL_START_PATH and CONFIG_SPL_START_FILENAME, but I assume right now, this is enough and when needed, the other one can be added. > > -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2 RESEND] SPL: Allow user to disable CPU support library
On 09/11/2011 11:03 PM, Marek Vasut wrote: > Introduce CONFIG_SPL_NO_CPU_SUPPORT_CODE to avoid compiling the CPU support > library. This can be useful on some setups. > > Signed-off-by: Marek Vasut > Cc: Stefano Babic > Cc: Wolfgang Denk > Cc: Detlev Zundel > Cc: Chander Kashyap But you didn't CC these... > --- > spl/Makefile |7 ++- > 1 files changed, 6 insertions(+), 1 deletions(-) > > diff --git a/spl/Makefile b/spl/Makefile > index 56d8ea1..63d1a8a 100644 > --- a/spl/Makefile > +++ b/spl/Makefile > @@ -20,6 +20,11 @@ export CONFIG_SPL_BUILD > > include $(TOPDIR)/config.mk > > +# In case we want to avoid the CPU support code, we need to define this: > +ifndef CONFIG_SPL_NO_CPU_SUPPORT_CODE > +SPL_CPU_SUPPORT_CODE := y > +endif SPL should ideally contain nothing by default. Have options that say what you do want to pull in, not what you don't want. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] SPL: Make path to start.S configurable
On 09/11/2011 10:56 PM, Marek Vasut wrote: > Introduce CONFIG_SPL_START_S_PATH to configure path to start.S file. It's not > always fitting to use CPU's start.S . > > Signed-off-by: Marek Vasut > --- > spl/Makefile | 10 -- > 1 files changed, 8 insertions(+), 2 deletions(-) > > diff --git a/spl/Makefile b/spl/Makefile > index 95ecce1..56d8ea1 100644 > --- a/spl/Makefile > +++ b/spl/Makefile > @@ -26,7 +26,13 @@ obj := $(OBJTREE)/spl/ > HAVE_VENDOR_COMMON_LIB := $(shell [ -f > $(SRCTREE)/board/$(VENDOR)/common/Makefile ] \ > && echo y || echo n) > > -START := $(CPUDIR)/start.o > +ifdefCONFIG_SPL_START_S_PATH > +START_PATH := $(subst ",,$(CONFIG_SPL_START_S_PATH)) > +else > +START_PATH := $(CPUDIR) > +endif > + > +START := $(START_PATH)/start.o So you can override the path, but not the filename? What if I want to have arch/.../cpu/.../start-nand-spl.o? How about: ifdef CONFIG_SPL_START_FILE START := $(subst ",,$(CONFIG_SPL_START_FILE)) else START := $(CPUDIR)/start.o endif START_PATH := $(dir $(START)) > LIBS-y += arch/$(ARCH)/lib/lib$(ARCH).o > LIBS-y += $(CPUDIR)/lib$(CPU).o > @@ -119,7 +125,7 @@ $(obj)u-boot-spl: depend $(START) $(LIBS) > $(obj)u-boot-spl.lds > $(GEN_UBOOT) > > $(START):depend > - $(MAKE) -C $(SRCTREE)/$(CPUDIR) $@ > + $(MAKE) -C $(SRCTREE)/$(START_PATH) $@ Yay recursive make. :-P -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] environment in NAND
On 09/07/2011 04:34 AM, Arno Steffen wrote: > "# save > Saving Environment to NAND... > Erasing Nand... > Warning: Erase size 0x2000 smaller than one erase block 0x0002 > Erasing 0x0002 instead > Skipping bad block at 0x000c > > Writing to Nand... FAILED!" In newer versions of U-Boot this is a hard failure, not a warning. CONFIG_ENV_RANGE should probably be defaulting to CONFIG_ENV_SECT_SIZE, not CONFIG_ENV_SIZE -- that would eliminate this problem. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/p3060: Add SoC related support for P3060 platform
On Sep 15, 2011, at 9:43 AM, John Schmoller wrote: > Hello Kumar, > >> From: Shengzhou Liu >> >> Add P3060 SoC specific information:cores setup, LIODN setup, etc >> >> The P3060 SoC combines six e500mc Power Architecture processor cores >> with >> high-performance datapath acceleration architecture(DPAA), CoreNet >> fabric >> infrastructure, as well as network and peripheral interfaces. >> >> Signed-off-by: Shengzhou Liu >> Signed-off-by: Kumar Gala >> --- > > > >> +#elif defined(CONFIG_PPC_P3060) >> +#define CONFIG_MAX_CPUS 8 > > I admit that I don't know anything about the P3060, but from your commit log > above and Freescale standard naming conventions, shouldn't CONFIG_MAX_CPUS be > 6? > > Thanks, > John I was wondering if this was going to be noticed. I need to add a comment. The MAX_CPUS is the max(ID+1,# of cores). On P3060 the cores are # 0,1, 4, 5, 6, 7. - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC] ARM ISA/cpu/SoC code organization for cache and other functions
(re-posting cleaned up and outside any other discussion) This RFC is for discussing how cache operation functions should be managed in the ARM tree. ARM boards are frequently based on a SoC, itseff based on a processor (or cpu), itself based on an (instruction set) architecture, 'isa' for short. For instance, board edminiv2 is based on SoC orion5x which has an ARM926EJ-S processor/cpu, based on an ARMv5 isa. Cache operations are normally defined at the isa level and all processors, SoCs and boards based on an architecture should use this architecture's cache operations. However, some processors or SoCs may provide specialized instructions or instruction sequences for some cache operations, or may have a broken implementation for some other cache op. There is thus a need to be able to redefine some isa-defined cache ops with processor-specific ops, and also to redefine some isa- or processor-defined ops with SoC-specific ops. For instance, say some armv5 based cpu badly implements full flush but correctly implements cache line flush. The cpu code should then provide its own version of the full cache flush op, based on looping through the cache lines instead of the armv5 single coprocessor instruction. If, OTOH, a SoC has broken cache ops to the point that cache is unuseable, then it should have its cache disabled, which can be done through configuration options or by providing SoC-specific cache ops implementations that will emit appropriate messages instead of trying to exercize the faulty cache functionality. The source code implementation for ARM cache ops would be: - a header file declaring the ops as weak C functions for at least full cache flush, full cache invalidate, cache line flush and cache line invalidate; - SoC-specific, cpu-specific, and isa-specific definitions for these functions, in the form of C files. - a default implementation in a lib/ file. The object files shall be linked in decreasing precedence order, i.e. SoC file first, then cpu file, then isa file, then lib last, so that for each cache op, the weak symbol mechanism uses the most specific one. One possible organisation for files would be (switch to fixed size font) (isa) (cpu) SoC) arch/arm /armv5t/ cache-ops.c arm926ejs/ cache-ops.c orion5x/ cache-ops.c Plus of course arch/arm/lib/cache-ops.c. There was a proposal to put SoC families right below arch/arm, because members of such SoC families may have many common devices but different cpus. We already deal with the common devices by putting them in their correct location in U-Boot, e.g. the Ethernet controller of orion5x is in drivers/net/, but we don't deal with SoCs which exist in various CPU flavors. Comments more than welcome. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] smc911x not functional on top of tree
On Thursday, September 15, 2011 10:21:04 PM stefano babic wrote: > Am 15/09/2011 21:39, schrieb Fabio Estevam: > > Hi, > > Hi Fabio, > > > When using U-boot from top of tree I am not able to get networking to > > work on a mx31pdk: > > > > uboot> dhcp > > smc911x: detected LAN9217 controller > > smc911x: phy initialized > > smc911x: MAC 00:04:9f:00:8d:6e > > BOOTP broadcast 1 > > BOOTP broadcast 2 > > DHCP client bound to address 10.29.244.21 > > BOOTP broadcast 3 > > DHCP client bound to address 10.29.244.21 > > BOOTP broadcast 4 > > DHCP client bound to address 10.29.244.21 > > BOOTP broadcast 5 > > DHCP client bound to address 10.29.244.21 > > > > Retry count exceeded; starting again > > I see... > > > I haven't started debugging this, but would like to check first if > > this is a known issue. > > I have not heard about this issue. > > > Running v2011.06 makes networking to work fine. > > > > I have not enabled the caches on this board yet and I do see a warning > > in boot saying > > that caches are not enabled. > > I know the commit, the same warning appears on a lot of other boards. It > is only a remind that cache is not enabled because the drivers do not > work if cache is enabled (as th FEC driver, for example). I'm working on the FEC patch that allows it to work with caches actually. I have it ready, but it needs some polishing. > > > Does anyone have smc911x working with the latest U-boot? > > I have now tested on a mx35pdk with Debug board. It has a SMC911x. It > works: > > U-Boot 2011.09-rc1-00020-g56fa45d (Sep 15 2011 - 22:08:55) > > CPU: Freescale i.MX35 at 532 MHz > Board: MX35 PDK 2.0 i.MX35 2.0 [WDT] > I2C: ready > DRAM: 256 MiB > WARNING: Caches not enabled > Flash: 64 MiB > NAND: 2048 MiB > In:serial > Out: serial > Err: serial > Net: smc911x-0, FECWarning: failed to set MAC address > > Hit any key to stop autoboot: 0 > MX35 U-Boot > > > MX35 U-Boot > run load > smc911x: detected LAN9217 controller > smc911x: phy initialized > smc911x: MAC 00:04:9f:00:f4:99 > Using smc911x-0 device > TFTP from server 192.168.2.14; our IP address is 192.168.2.97 > Filename 'mx35pdk/u-boot.bin'. > Load address: 0x8080 > Loading: # > done > Bytes transferred = 248892 (3cc3c hex) > > Best regards, > Stefano Babic ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v6 1/4] gpio: Move common gpio.h to include/asm-generic
Le 15/09/2011 11:45, Wolfgang Denk a écrit : > Dear Kim, > > In message<20110913200803.4d76579c.kim.phill...@freescale.com> you wrote: >> >>> arch/arm/include/asm/gpio.h | 38 >>> +- >>> arch/powerpc/include/asm/gpio.h |2 ++ >>> include/asm-generic/gpio.h | 37 >>> + >>> 3 files changed, 40 insertions(+), 37 deletions(-) >>> create mode 100644 arch/powerpc/include/asm/gpio.h >>> create mode 100644 include/asm-generic/gpio.h >> >> applied 4 out of 4 patches. >> >> Wolfgang, technically this is a multi-domain patchseries, and I've >> overstepped my boundaries for the sake of expediency in adding the >> GPIO feature to 83xx-land. If this is a problem, and you'd like to >> apply patches 1 and 2 independently of mpc83xx, please let me know >> and I'll back the entire series off the mpc83xx tree. Fwiw, I >> build-tested a couple of ARM boards, including davinci. > > As this relates to ARM files, you need Albert's OK here, not mine. > [I put Albert on Cc:] Well, it relates to both ARM and PPC equally, but anyway... Acked-By: Albert ARIBAUD > Best regards, > > Wolfgang Denk Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] smc911x not functional on top of tree
Am 15/09/2011 21:39, schrieb Fabio Estevam: > Hi, > Hi Fabio, > When using U-boot from top of tree I am not able to get networking to > work on a mx31pdk: > > uboot> dhcp > smc911x: detected LAN9217 controller > smc911x: phy initialized > smc911x: MAC 00:04:9f:00:8d:6e > BOOTP broadcast 1 > BOOTP broadcast 2 > DHCP client bound to address 10.29.244.21 > BOOTP broadcast 3 > DHCP client bound to address 10.29.244.21 > BOOTP broadcast 4 > DHCP client bound to address 10.29.244.21 > BOOTP broadcast 5 > DHCP client bound to address 10.29.244.21 > > Retry count exceeded; starting again I see... > I haven't started debugging this, but would like to check first if > this is a known issue. I have not heard about this issue. > Running v2011.06 makes networking to work fine. > > I have not enabled the caches on this board yet and I do see a warning > in boot saying > that caches are not enabled. I know the commit, the same warning appears on a lot of other boards. It is only a remind that cache is not enabled because the drivers do not work if cache is enabled (as th FEC driver, for example). > Does anyone have smc911x working with the latest U-boot? I have now tested on a mx35pdk with Debug board. It has a SMC911x. It works: U-Boot 2011.09-rc1-00020-g56fa45d (Sep 15 2011 - 22:08:55) CPU: Freescale i.MX35 at 532 MHz Board: MX35 PDK 2.0 i.MX35 2.0 [WDT] I2C: ready DRAM: 256 MiB WARNING: Caches not enabled Flash: 64 MiB NAND: 2048 MiB In:serial Out: serial Err: serial Net: smc911x-0, FECWarning: failed to set MAC address Hit any key to stop autoboot: 0 MX35 U-Boot > MX35 U-Boot > run load smc911x: detected LAN9217 controller smc911x: phy initialized smc911x: MAC 00:04:9f:00:f4:99 Using smc911x-0 device TFTP from server 192.168.2.14; our IP address is 192.168.2.97 Filename 'mx35pdk/u-boot.bin'. Load address: 0x8080 Loading: # done Bytes transferred = 248892 (3cc3c hex) 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-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 3/4 v1] mvrtc: add fdt support.
On Thu, Sep 15, 2011 at 12:23:52PM -0700, Simon Glass wrote:
> On Thu, Sep 15, 2011 at 6:54 AM, Jason Cooper wrote:
> >
> > Signed-off-by: Jason Cooper
> > ---
> > common/fdt_decode.c | 1 +
> > drivers/rtc/mvrtc.c | 62
> > +++--
> > drivers/rtc/mvrtc.h | 7 +
> > include/fdt_decode.h | 1 +
> > 4 files changed, 68 insertions(+), 3 deletions(-)
> >
> > diff --git a/common/fdt_decode.c b/common/fdt_decode.c
> > index 0f13089..1a0dcf4 100644
> > --- a/common/fdt_decode.c
> > +++ b/common/fdt_decode.c
> > @@ -34,6 +34,7 @@
> > */
> > #define COMPAT(id, name) name
> > const char *compat_names[COMPAT_COUNT] = {
> > + COMPAT(MARVELL_KIRKWOOD_RTC, "marvell,kirkwood-rtc"),
> > };
> >
> > /**
> > diff --git a/drivers/rtc/mvrtc.c b/drivers/rtc/mvrtc.c
> > index ccc573a..ce2dc3d 100644
> > --- a/drivers/rtc/mvrtc.c
> > +++ b/drivers/rtc/mvrtc.c
> > @@ -28,18 +28,62 @@
> > #include
> > #include
> > #include
> > +#ifdef CONFIG_OF_CONTROL
> > +#include
> > +#endif
> > #include "mvrtc.h"
> >
> > +DECLARE_GLOBAL_DATA_PTR;
> > +
> > /* This RTC does not support century, so we assume 20 */
> > #define CENTURY 20
> >
> > +#ifndef CONFIG_OF_CONTROL
>
> Perhaps #ifdef and put the fdt code first?
Sure. For larger drivers, I'd prefer to see a separate file. eg:
mvgbe.c
mvgbe-dt.c
with mvgbe.h selecting _init() or _init_fdt() on CONFIG_OF_CONTROL. Not
sure, gotta think about it more.
> > +struct mvrtc_registers *mvrtc_get_config(void) {
> > + return (struct mvrtc_registers *)KW_RTC_BASE;
> > +}
> > +
> > +#else
> > +int fdt_decode_rtc(const void *blob, int node, struct fdt_rtc *config)
> > +{
> > + config->reg = get_addr(blob, node, "reg");
> > + config->enabled = get_is_enabled(blob, node, 0);
> > +
> > + return 0;
> > +}
> > +
> > +struct mvrtc_registers *mvrtc_get_config(void) {
> > + const void *blob = gd->blob;
> > + struct fdt_rtc config;
> > + int node;
> > + int index=0;
> > +
> > + node = fdt_decode_next_alias(blob, "rtc",
> > + COMPAT_MARVELL_KIRKWOOD_RTC, &index);
> > +
> > + if (node < 0)
> > + return NULL;
> > +
> > + if (fdt_decode_rtc(blob, node, &config))
> > + return NULL;
> > +
> > + return config.enabled ? (struct mvrtc_registers *)config.reg : NULL;
> > +}
> > +#endif
> > +
> > int rtc_get(struct rtc_time *t)
> > {
> > u32 time;
> > u32 date;
> > struct mvrtc_registers *mvrtc_regs;
> >
> > - mvrtc_regs = (struct mvrtc_registers *)KW_RTC_BASE;
> > + mvrtc_regs = mvrtc_get_config();
> > +#ifdef CONFIG_OF_CONTROL
> > + if (mvrtc_regs == NULL) {
> > + printf("Error decoding fdt for mvrtc.\n");
> > + return -1;
> > + }
> > +#endif
> >
> > /* read the time register */
> > time = readl(&mvrtc_regs->time);
> > @@ -79,7 +123,13 @@ int rtc_set(struct rtc_time *t)
> > u32 date = 0;
> > struct mvrtc_registers *mvrtc_regs;
> >
> > - mvrtc_regs = (struct mvrtc_registers *)KW_RTC_BASE;
> > + mvrtc_regs = mvrtc_get_config();
> > +#ifdef CONFIG_OF_CONTROL
> > + if (mvrtc_regs == NULL) {
> > + printf("Error decoding fdt for mvrtc.\n");
> > + return -1;
> > + }
> > +#endif
> >
> > /* check that this code isn't 80+ years old ;-) */
> > if ((t->tm_year / 100) != CENTURY)
> > @@ -111,7 +161,13 @@ void rtc_reset(void)
> > u32 sec;
> > struct mvrtc_registers *mvrtc_regs;
> >
> > - mvrtc_regs = (struct mvrtc_registers *)KW_RTC_BASE;
> > + mvrtc_regs = mvrtc_get_config();
> > +#ifdef CONFIG_OF_CONTROL
> > + if (mvrtc_regs == NULL) {
> > + printf("Error decoding fdt for mvrtc.\n");
> > + return;
> > + }
> > +#endif
> >
> > /* no init routine for this RTC needed, just check that it's working
> > */
>
> Hmm I think it would be better to decode the fdt once in init, and
> store it in your structure. It seems like you are doing it each time
> the driver is called.
Yes, it's a stupid/simple driver. There is definitely room for
optimization.
> > time = readl(&mvrtc_regs->time);
> > diff --git a/drivers/rtc/mvrtc.h b/drivers/rtc/mvrtc.h
> > index b9d5c6f..56b09f2 100644
> > --- a/drivers/rtc/mvrtc.h
> > +++ b/drivers/rtc/mvrtc.h
> > @@ -37,6 +37,13 @@ struct mvrtc_registers {
> > u32 date;
> > };
> >
> > +#ifdef CONFIG_OF_CONTROL
> > +struct fdt_rtc {
> > + addr_t reg; /* address of the registers */
> > + int enabled; /* 1 if enabled, 0 if disabled */
> > +};
>
> It seems to be that this structure should generally only be needed in
> the C file, so should perhaps go there.
true.
> > +#endif
> > +
> > /* time register */
> > #define MVRTC_SEC_SFT 0
> > #define MVRTC_SEC_MSK 0x7f
> > diff --git a/in
[U-Boot] Orphanage Home
Dear, We are private consultant in England Representing the interest of India Orphanage Home who is presently looking for a sincere representative in the USA/CANADA to enable good citizens who are contributing to reach them without stress. your kind respond is highly anticipated. Mr, Moss Kanga Tel: +44-871-315-5624 Member Barrister Finder United Kingdom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 4/4 v1] dreamplug: enable fdt
On Thu, Sep 15, 2011 at 12:25:36PM -0700, Simon Glass wrote:
> On Thu, Sep 15, 2011 at 6:54 AM, Jason Cooper wrote:
> >
> > Signed-off-by: Jason Cooper
> > ---
> > board/Marvell/dreamplug/kirkwood-dreamplug.dts | 12 +++
> > board/Marvell/dreamplug/kirkwood.dtsi | 25
> >
> > include/configs/dreamplug.h | 5
> > 3 files changed, 42 insertions(+), 0 deletions(-)
> > create mode 100644 board/Marvell/dreamplug/kirkwood-dreamplug.dts
> > create mode 100644 board/Marvell/dreamplug/kirkwood.dtsi
> >
> > diff --git a/board/Marvell/dreamplug/kirkwood-dreamplug.dts
> > b/board/Marvell/dreamplug/kirkwood-dreamplug.dts
> > new file mode 100644
> > index 000..eb900c3
> > --- /dev/null
> > +++ b/board/Marvell/dreamplug/kirkwood-dreamplug.dts
> > @@ -0,0 +1,12 @@
> > +/dts-v1/;
> > +
> > +/include/ "kirkwood.dtsi"
> > +
> > +/ {
> > + model = "Marvell Dreamplug";
> > + compatible = "marvell,dreamplug", "marvell,kirkwood";
> > +
> > + rtc@0xf1010300 {
> > + status = "ok";
> > + };
> > +};
> > diff --git a/board/Marvell/dreamplug/kirkwood.dtsi
> > b/board/Marvell/dreamplug/kirkwood.dtsi
> > new file mode 100644
> > index 000..15e52bd
> > --- /dev/null
> > +++ b/board/Marvell/dreamplug/kirkwood.dtsi
> > @@ -0,0 +1,25 @@
> > +/ {
> > + model = "Marvell Kirkwood";
> > + compatible = "marvell,kirkwood";
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > +
> > + cpus {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + cpu@0 {
> > + compatible = "arm,arm926ejs";
> > + reg = <0>;
> > + };
> > + };
> > +
> > + rtc@0xf1010300 {
> > + compatible = "marvell,kirkwood-rtc";
> > + reg = <0xf1010300 0x02>;
> > + status = "disabled";
> > + };
> > +
> > + aliases {
> > + rtc0 = "/rtc@0xf1010300";
> > + };
> > +};
> > diff --git a/include/configs/dreamplug.h b/include/configs/dreamplug.h
> > index 8d1b935..9960d35 100644
> > --- a/include/configs/dreamplug.h
> > +++ b/include/configs/dreamplug.h
> > @@ -50,6 +50,11 @@
> > #define CONFIG_MACH_TYPE MACH_TYPE_DREAMPLUG
> > #define CONFIG_SKIP_LOWLEVEL_INIT /* disable board lowlevel_init */
> >
> > +#define CONFIG_OF_EMBED
> > +#define CONFIG_DEFAULT_DEVICE_TREE "kirkwood-dreamplug"
>
> One of my experiments was to create this automatically from
> -.dts, so that this isn't needed explicitly. Is it
> better to require a CONFIG for this, or just use the expected name?
There is a large probability that users may roll their own dts files.
Until device-tree.git is a reality, I'd say keep it so users can specify
which dts file they want to build.
thx,
Jason.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 2/4 v1] fdt_decode: make more available.
On Thu, Sep 15, 2011 at 12:18:00PM -0700, Simon Glass wrote:
> On Thu, Sep 15, 2011 at 6:54 AM, Jason Cooper wrote:
> >
> > Signed-off-by: Jason Cooper
> > ---
> > common/fdt_decode.c | 11 +--
> > include/fdt_decode.h | 13 +
> > 2 files changed, 18 insertions(+), 6 deletions(-)
> >
> > diff --git a/common/fdt_decode.c b/common/fdt_decode.c
> > index cd7a071..0f13089 100644
> > --- a/common/fdt_decode.c
> > +++ b/common/fdt_decode.c
> > @@ -33,7 +33,7 @@
> > * turn this into a sparse list later, and keeps the ID with the name.
> > */
> > #define COMPAT(id, name) name
> > -static const char *compat_names[COMPAT_COUNT] = {
> > +const char *compat_names[COMPAT_COUNT] = {
> > };
> >
> > /**
> > @@ -43,7 +43,7 @@ static const char *compat_names[COMPAT_COUNT] = {
> > * @param name alias name to look up
> > * @return node offset if found, or an error code < 0 otherwise
> > */
> > -static int find_alias_node(const void *blob, const char *name)
> > +int find_alias_node(const void *blob, const char *name)
>
> If we are going to export these (which I agree we must if we are to
> move this code into drivers), then it should have the fdt_decode_
> prefix.
>
> Perhaps this is too verbose? I would be happy with
> fdtdec_find_alias_node() if that sounds better?
I like this.
> > {
> > const char *path;
> > int alias_node;
> > @@ -68,7 +68,7 @@ static int find_alias_node(const void *blob, const char
> > *name)
> > * @param prop_name name of property to find
> > * @return address, if found, or ADDR_T_NONE if not
> > */
> > -static addr_t get_addr(const void *blob, int node, const char *prop_name)
> > +addr_t get_addr(const void *blob, int node, const char *prop_name)
> > {
> > const addr_t *cell;
> > int len;
> > @@ -91,7 +91,7 @@ static addr_t get_addr(const void *blob, int node, const
> > char *prop_name)
> > * @param default_val default value to return if the property is not found
> > * @return integer value, if found, or default_val if not
> > */
> > -static s32 get_int(const void *blob, int node, const char *prop_name,
> > +s32 get_int(const void *blob, int node, const char *prop_name,
> > s32 default_val)
> > {
> > const s32 *cell;
> > @@ -115,7 +115,7 @@ static s32 get_int(const void *blob, int node, const
> > char *prop_name,
> > * @param default_val default value to return if no 'status' property
> > exists
> > * @return integer value 0/1, if found, or default_val if not
> > */
> > -static int get_is_enabled(const void *blob, int node, int default_val)
> > +int get_is_enabled(const void *blob, int node, int default_val)
> > {
> > const char *cell;
> >
> > @@ -160,4 +160,3 @@ int fdt_decode_next_alias(const void *blob, const char
> > *name,
> > return err;
> > return err ? -FDT_ERR_MISSING : node;
> > }
> > -
> > diff --git a/include/fdt_decode.h b/include/fdt_decode.h
> > index ba3c15b..4264e3b 100644
> > --- a/include/fdt_decode.h
> > +++ b/include/fdt_decode.h
> > @@ -19,6 +19,8 @@
> > * MA 02111-1307 USA
> > */
> >
> > +#ifndef _FDT_DECODE_H_
> > +#define _FDT_DECODE_H_
> >
> > /*
> > * This file contains convenience functions for decoding useful and
> > @@ -55,4 +57,15 @@ enum fdt_compat_id {
> > COMPAT_COUNT,
> > };
> >
> > +int find_alias_node(const void *blob, const char *name);
> > +addr_t get_addr(const void *blob, int node, const char *prop_name);
> > +s32 get_int(const void *blob, int node, const char *prop_name,
> > + s32 default_val);
> > +int get_is_enabled(const void *blob, int node, int default_val);
> > +enum fdt_compat_id fdt_decode_lookup(const void *blob, int node);
> > +int fdt_decode_next_compatible(const void *blob, int node,
> > + enum fdt_compat_id id);
> > +int fdt_decode_next_alias(const void *blob, const char *name,
> > + enum fdt_compat_id id, int *upto);
> >
> > +#endif
> > --
> > 1.7.0.4
> >
> >
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 0/4 v1] Use fdt to init mvrtc driver for dreamplug
On Thu, Sep 15, 2011 at 12:16:11PM -0700, Simon Glass wrote: > On Thu, Sep 15, 2011 at 6:54 AM, Jason Cooper wrote: > > To make this work, I applied v2 of Simon Glass' patch series (what this > > email is in reply to) against v2011.09-rc1. I then cherry picked my > > dreamplug board support patch. Last, I applied the following series. > > > > It works, although with CONFIG_OF_EMBED. I haven't tried _SEPARATE yet. > > Please do, as that is what we really want people to use. Ok. > > Some thoughts: ... > > 3.) Since mach names (dreamplug) and SoC names (kirkwood) are unique, > > should we put all .dts and .dtsi files in one dir? eg /dts ? This > > would facilitate migration to Grant Likely's device-tree.git > > whereever and whenever it lands. This is also similar to how Linux > > currently does it (arch/arm/boot/dts/) > > It does have advantages, although (hopefully) the number of files will > grow quite large. But bear in mind that people will create their own > .dtsi files, so we will need a strong naming convention there also > (always use the board prefix perhaps). Wouldn't they be creating their own board .dts files, that /include/s the SoC .dtsi? > If we want to be similar to Linux they should go in arch//dts, > but then we are putting board description files outside the board/ > structure, which doesn't seem right. The arch/arm/ subdir is supposed > to be for arch-specific code which is generic across boards. Remember > that the dts will include board things, not just SOC things. > > Clearly we don't want .dts files in boards/ and even boards/dts seems > odd since all the other files are in board/. Hmm I quite like > having them in board//dts. Funny, that's exactly what I did at first (board/Marvell/dts/) when creating this patchset. It failed to build, so I conformed just to get it working. So, board//dts/ feels natural. Must be right, then. ;-) I'm currently working on my second driver (mvgbe ethernet) and having a good time trying to find the interrupt controller for kirkwood. I'll try _SEPARATE after I get something testable for it. thx, Jason. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] smc911x not functional on top of tree
Hi, When using U-boot from top of tree I am not able to get networking to work on a mx31pdk: uboot> dhcp smc911x: detected LAN9217 controller smc911x: phy initialized smc911x: MAC 00:04:9f:00:8d:6e BOOTP broadcast 1 BOOTP broadcast 2 DHCP client bound to address 10.29.244.21 BOOTP broadcast 3 DHCP client bound to address 10.29.244.21 BOOTP broadcast 4 DHCP client bound to address 10.29.244.21 BOOTP broadcast 5 DHCP client bound to address 10.29.244.21 Retry count exceeded; starting again I haven't started debugging this, but would like to check first if this is a known issue. Running v2011.06 makes networking to work fine. I have not enabled the caches on this board yet and I do see a warning in boot saying that caches are not enabled. Does anyone have smc911x working with the latest U-boot? Thanks, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 4/4 v1] dreamplug: enable fdt
Hi Jason,
On Thu, Sep 15, 2011 at 6:54 AM, Jason Cooper wrote:
>
> Signed-off-by: Jason Cooper
> ---
> board/Marvell/dreamplug/kirkwood-dreamplug.dts | 12 +++
> board/Marvell/dreamplug/kirkwood.dtsi | 25
>
> include/configs/dreamplug.h | 5
> 3 files changed, 42 insertions(+), 0 deletions(-)
> create mode 100644 board/Marvell/dreamplug/kirkwood-dreamplug.dts
> create mode 100644 board/Marvell/dreamplug/kirkwood.dtsi
>
> diff --git a/board/Marvell/dreamplug/kirkwood-dreamplug.dts
> b/board/Marvell/dreamplug/kirkwood-dreamplug.dts
> new file mode 100644
> index 000..eb900c3
> --- /dev/null
> +++ b/board/Marvell/dreamplug/kirkwood-dreamplug.dts
> @@ -0,0 +1,12 @@
> +/dts-v1/;
> +
> +/include/ "kirkwood.dtsi"
> +
> +/ {
> + model = "Marvell Dreamplug";
> + compatible = "marvell,dreamplug", "marvell,kirkwood";
> +
> + rtc@0xf1010300 {
> + status = "ok";
> + };
> +};
> diff --git a/board/Marvell/dreamplug/kirkwood.dtsi
> b/board/Marvell/dreamplug/kirkwood.dtsi
> new file mode 100644
> index 000..15e52bd
> --- /dev/null
> +++ b/board/Marvell/dreamplug/kirkwood.dtsi
> @@ -0,0 +1,25 @@
> +/ {
> + model = "Marvell Kirkwood";
> + compatible = "marvell,kirkwood";
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + cpu@0 {
> + compatible = "arm,arm926ejs";
> + reg = <0>;
> + };
> + };
> +
> + rtc@0xf1010300 {
> + compatible = "marvell,kirkwood-rtc";
> + reg = <0xf1010300 0x02>;
> + status = "disabled";
> + };
> +
> + aliases {
> + rtc0 = "/rtc@0xf1010300";
> + };
> +};
> diff --git a/include/configs/dreamplug.h b/include/configs/dreamplug.h
> index 8d1b935..9960d35 100644
> --- a/include/configs/dreamplug.h
> +++ b/include/configs/dreamplug.h
> @@ -50,6 +50,11 @@
> #define CONFIG_MACH_TYPE MACH_TYPE_DREAMPLUG
> #define CONFIG_SKIP_LOWLEVEL_INIT /* disable board lowlevel_init */
>
> +#define CONFIG_OF_EMBED
> +#define CONFIG_DEFAULT_DEVICE_TREE "kirkwood-dreamplug"
One of my experiments was to create this automatically from
-.dts, so that this isn't needed explicitly. Is it
better to require a CONFIG for this, or just use the expected name?
Regards,
Simon
> +#define CONFIG_OF_CONTROL
> +#define CONFIG_OF_LIBFDT
> +
> /*
> * Commands configuration
> */
> --
> 1.7.0.4
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 3/4 v1] mvrtc: add fdt support.
Hi Jason,
On Thu, Sep 15, 2011 at 6:54 AM, Jason Cooper wrote:
>
> Signed-off-by: Jason Cooper
> ---
> common/fdt_decode.c | 1 +
> drivers/rtc/mvrtc.c | 62 +++--
> drivers/rtc/mvrtc.h | 7 +
> include/fdt_decode.h | 1 +
> 4 files changed, 68 insertions(+), 3 deletions(-)
>
> diff --git a/common/fdt_decode.c b/common/fdt_decode.c
> index 0f13089..1a0dcf4 100644
> --- a/common/fdt_decode.c
> +++ b/common/fdt_decode.c
> @@ -34,6 +34,7 @@
> */
> #define COMPAT(id, name) name
> const char *compat_names[COMPAT_COUNT] = {
> + COMPAT(MARVELL_KIRKWOOD_RTC, "marvell,kirkwood-rtc"),
> };
>
> /**
> diff --git a/drivers/rtc/mvrtc.c b/drivers/rtc/mvrtc.c
> index ccc573a..ce2dc3d 100644
> --- a/drivers/rtc/mvrtc.c
> +++ b/drivers/rtc/mvrtc.c
> @@ -28,18 +28,62 @@
> #include
> #include
> #include
> +#ifdef CONFIG_OF_CONTROL
> +#include
> +#endif
> #include "mvrtc.h"
>
> +DECLARE_GLOBAL_DATA_PTR;
> +
> /* This RTC does not support century, so we assume 20 */
> #define CENTURY 20
>
> +#ifndef CONFIG_OF_CONTROL
Perhaps #ifdef and put the fdt code first?
> +struct mvrtc_registers *mvrtc_get_config(void) {
> + return (struct mvrtc_registers *)KW_RTC_BASE;
> +}
> +
> +#else
> +int fdt_decode_rtc(const void *blob, int node, struct fdt_rtc *config)
> +{
> + config->reg = get_addr(blob, node, "reg");
> + config->enabled = get_is_enabled(blob, node, 0);
> +
> + return 0;
> +}
> +
> +struct mvrtc_registers *mvrtc_get_config(void) {
> + const void *blob = gd->blob;
> + struct fdt_rtc config;
> + int node;
> + int index=0;
> +
> + node = fdt_decode_next_alias(blob, "rtc",
> + COMPAT_MARVELL_KIRKWOOD_RTC, &index);
> +
> + if (node < 0)
> + return NULL;
> +
> + if (fdt_decode_rtc(blob, node, &config))
> + return NULL;
> +
> + return config.enabled ? (struct mvrtc_registers *)config.reg : NULL;
> +}
> +#endif
> +
> int rtc_get(struct rtc_time *t)
> {
> u32 time;
> u32 date;
> struct mvrtc_registers *mvrtc_regs;
>
> - mvrtc_regs = (struct mvrtc_registers *)KW_RTC_BASE;
> + mvrtc_regs = mvrtc_get_config();
> +#ifdef CONFIG_OF_CONTROL
> + if (mvrtc_regs == NULL) {
> + printf("Error decoding fdt for mvrtc.\n");
> + return -1;
> + }
> +#endif
>
> /* read the time register */
> time = readl(&mvrtc_regs->time);
> @@ -79,7 +123,13 @@ int rtc_set(struct rtc_time *t)
> u32 date = 0;
> struct mvrtc_registers *mvrtc_regs;
>
> - mvrtc_regs = (struct mvrtc_registers *)KW_RTC_BASE;
> + mvrtc_regs = mvrtc_get_config();
> +#ifdef CONFIG_OF_CONTROL
> + if (mvrtc_regs == NULL) {
> + printf("Error decoding fdt for mvrtc.\n");
> + return -1;
> + }
> +#endif
>
> /* check that this code isn't 80+ years old ;-) */
> if ((t->tm_year / 100) != CENTURY)
> @@ -111,7 +161,13 @@ void rtc_reset(void)
> u32 sec;
> struct mvrtc_registers *mvrtc_regs;
>
> - mvrtc_regs = (struct mvrtc_registers *)KW_RTC_BASE;
> + mvrtc_regs = mvrtc_get_config();
> +#ifdef CONFIG_OF_CONTROL
> + if (mvrtc_regs == NULL) {
> + printf("Error decoding fdt for mvrtc.\n");
> + return;
> + }
> +#endif
>
> /* no init routine for this RTC needed, just check that it's working */
Hmm I think it would be better to decode the fdt once in init, and
store it in your structure. It seems like you are doing it each time
the driver is called.
> time = readl(&mvrtc_regs->time);
> diff --git a/drivers/rtc/mvrtc.h b/drivers/rtc/mvrtc.h
> index b9d5c6f..56b09f2 100644
> --- a/drivers/rtc/mvrtc.h
> +++ b/drivers/rtc/mvrtc.h
> @@ -37,6 +37,13 @@ struct mvrtc_registers {
> u32 date;
> };
>
> +#ifdef CONFIG_OF_CONTROL
> +struct fdt_rtc {
> + addr_t reg; /* address of the registers */
> + int enabled; /* 1 if enabled, 0 if disabled */
> +};
It seems to be that this structure should generally only be needed in
the C file, so should perhaps go there.
> +#endif
> +
> /* time register */
> #define MVRTC_SEC_SFT 0
> #define MVRTC_SEC_MSK 0x7f
> diff --git a/include/fdt_decode.h b/include/fdt_decode.h
> index 4264e3b..f236643 100644
> --- a/include/fdt_decode.h
> +++ b/include/fdt_decode.h
> @@ -54,6 +54,7 @@ struct fdt_memory {
> */
> enum fdt_compat_id {
> COMPAT_UNKNOWN,
> + COMPAT_MARVELL_KIRKWOOD_RTC,
My cunning plan is that this can be some sort of driver ID and could
serve as a lead in to a unified device model (it provides a simple
enumeration of available drivers). However, perhaps we should discuss
this separately.
Regards,
Simon
> COMPAT_COUNT,
> };
>
> --
> 1.7.0.4
>
>
___
U-Boot mailing list
U-Boot@lists.
Re: [U-Boot] [RFC PATCH 2/4 v1] fdt_decode: make more available.
Hi Jason,
On Thu, Sep 15, 2011 at 6:54 AM, Jason Cooper wrote:
>
> Signed-off-by: Jason Cooper
> ---
> common/fdt_decode.c | 11 +--
> include/fdt_decode.h | 13 +
> 2 files changed, 18 insertions(+), 6 deletions(-)
>
> diff --git a/common/fdt_decode.c b/common/fdt_decode.c
> index cd7a071..0f13089 100644
> --- a/common/fdt_decode.c
> +++ b/common/fdt_decode.c
> @@ -33,7 +33,7 @@
> * turn this into a sparse list later, and keeps the ID with the name.
> */
> #define COMPAT(id, name) name
> -static const char *compat_names[COMPAT_COUNT] = {
> +const char *compat_names[COMPAT_COUNT] = {
> };
>
> /**
> @@ -43,7 +43,7 @@ static const char *compat_names[COMPAT_COUNT] = {
> * @param name alias name to look up
> * @return node offset if found, or an error code < 0 otherwise
> */
> -static int find_alias_node(const void *blob, const char *name)
> +int find_alias_node(const void *blob, const char *name)
If we are going to export these (which I agree we must if we are to
move this code into drivers), then it should have the fdt_decode_
prefix.
Perhaps this is too verbose? I would be happy with
fdtdec_find_alias_node() if that sounds better?
> {
> const char *path;
> int alias_node;
> @@ -68,7 +68,7 @@ static int find_alias_node(const void *blob, const char
> *name)
> * @param prop_name name of property to find
> * @return address, if found, or ADDR_T_NONE if not
> */
> -static addr_t get_addr(const void *blob, int node, const char *prop_name)
> +addr_t get_addr(const void *blob, int node, const char *prop_name)
> {
> const addr_t *cell;
> int len;
> @@ -91,7 +91,7 @@ static addr_t get_addr(const void *blob, int node, const
> char *prop_name)
> * @param default_val default value to return if the property is not found
> * @return integer value, if found, or default_val if not
> */
> -static s32 get_int(const void *blob, int node, const char *prop_name,
> +s32 get_int(const void *blob, int node, const char *prop_name,
> s32 default_val)
> {
> const s32 *cell;
> @@ -115,7 +115,7 @@ static s32 get_int(const void *blob, int node, const char
> *prop_name,
> * @param default_val default value to return if no 'status' property exists
> * @return integer value 0/1, if found, or default_val if not
> */
> -static int get_is_enabled(const void *blob, int node, int default_val)
> +int get_is_enabled(const void *blob, int node, int default_val)
> {
> const char *cell;
>
> @@ -160,4 +160,3 @@ int fdt_decode_next_alias(const void *blob, const char
> *name,
> return err;
> return err ? -FDT_ERR_MISSING : node;
> }
> -
> diff --git a/include/fdt_decode.h b/include/fdt_decode.h
> index ba3c15b..4264e3b 100644
> --- a/include/fdt_decode.h
> +++ b/include/fdt_decode.h
> @@ -19,6 +19,8 @@
> * MA 02111-1307 USA
> */
>
> +#ifndef _FDT_DECODE_H_
> +#define _FDT_DECODE_H_
>
> /*
> * This file contains convenience functions for decoding useful and
> @@ -55,4 +57,15 @@ enum fdt_compat_id {
> COMPAT_COUNT,
> };
>
> +int find_alias_node(const void *blob, const char *name);
> +addr_t get_addr(const void *blob, int node, const char *prop_name);
> +s32 get_int(const void *blob, int node, const char *prop_name,
> + s32 default_val);
> +int get_is_enabled(const void *blob, int node, int default_val);
> +enum fdt_compat_id fdt_decode_lookup(const void *blob, int node);
> +int fdt_decode_next_compatible(const void *blob, int node,
> + enum fdt_compat_id id);
> +int fdt_decode_next_alias(const void *blob, const char *name,
> + enum fdt_compat_id id, int *upto);
>
> +#endif
> --
> 1.7.0.4
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 0/4 v1] Use fdt to init mvrtc driver for dreamplug
Hi Jason, On Thu, Sep 15, 2011 at 6:54 AM, Jason Cooper wrote: > Simon, All, > > This patch series is my attempt to learn device tree with a driver I'm > familiar with. Also, to create a real, working example for fdt in U-boot. Great! > > To make this work, I applied v2 of Simon Glass' patch series (what this > email is in reply to) against v2011.09-rc1. I then cherry picked my > dreamplug board support patch. Last, I applied the following series. > > It works, although with CONFIG_OF_EMBED. I haven't tried _SEPARATE yet. Please do, as that is what we really want people to use. > > Some thoughts: > > 1.) 'kirkwood-dreamplug.dts' can be renamed 'dreamplug.dts'. Due to > machine_is_XXX 'dreamplug' will be unique, concise, and descriptive. > This requires changes to Simon Glass' patchset. > > 2.) The fdt files should be moved up one directory level, in the end, it > should look like: > > board/Marvell/armada100-dt.c > board/Marvell/armada100-dt.h > board/Marvell/armada100.dtsi > board/Marvell/dreamplug.dts > board/Marvell/gplugd.dts # this includes armada100.dtsi > board/Marvell/guruplug.dts > board/Marvell/kirkwood.dtsi > board/Marvell/kirkwood-dt.c > board/Marvell/kirkwood-dt.h > board/Marvell/openrd.dts > board/Marvell/sheevaplug.dts > ... > board/Marvell/.dts > > This also requires changes to Simon's patchset. Hmm I'm not sure about that - perhaps at least a dts subdirectory? > > 3.) Since mach names (dreamplug) and SoC names (kirkwood) are unique, > should we put all .dts and .dtsi files in one dir? eg /dts ? This > would facilitate migration to Grant Likely's device-tree.git > whereever and whenever it lands. This is also similar to how Linux > currently does it (arch/arm/boot/dts/) It does have advantages, although (hopefully) the number of files will grow quite large. But bear in mind that people will create their own .dtsi files, so we will need a strong naming convention there also (always use the board prefix perhaps). If we want to be similar to Linux they should go in arch//dts, but then we are putting board description files outside the board/ structure, which doesn't seem right. The arch/arm/ subdir is supposed to be for arch-specific code which is generic across boards. Remember that the dts will include board things, not just SOC things. Clearly we don't want .dts files in boards/ and even boards/dts seems odd since all the other files are in board/. Hmm I quite like having them in board//dts. Regards, Simon > > Jason Cooper (4): > fdt: remove i2c example code. > fdt_decode: make more available. > mvrtc: add fdt support. > dreamplug: enable fdt > > board/Marvell/dreamplug/kirkwood-dreamplug.dts | 12 + > board/Marvell/dreamplug/kirkwood.dtsi | 25 ++ > common/fdt_decode.c | 26 ++ > drivers/rtc/mvrtc.c | 62 ++- > drivers/rtc/mvrtc.h | 7 +++ > include/configs/dreamplug.h | 5 ++ > include/fdt_decode.h | 46 + > 7 files changed, 128 insertions(+), 55 deletions(-) > create mode 100644 board/Marvell/dreamplug/kirkwood-dreamplug.dts > create mode 100644 board/Marvell/dreamplug/kirkwood.dtsi > > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot-1.3.3 SMC91111 driver
On Thursday, September 15, 2011 03:53:02 PM Simon Schwarz wrote: > Hi, > > first thing would be to use a current U-Boot Version. This can be > obtained from: > http://www.denx.de/wiki/U-Boot/SourceCode Try not top-posting please. btw. the lowlevel init function also configures the hardware, maybe you should remove blob and replace it with uboot ... and use mainline version, like Simon suggested, 1.3.3 is _way_ too old. Cheers > > Regards > Simon > > On 09/15/2011 03:31 PM, Chaney Lee wrote: > > hello: > > > > I need your advise. > > I port the u-boot-1.3.3 to my PXA270 board??Every thing works well but > > the SMC9 dirver.I have aready config the config file like this: > > #define CONFIG_DRIVER_SMC9 1 > > #define CONFIG_SMC9_BASE0x1300 > > #define CONFIG_SMC9_EXT_PHY > > > > #define CONFIG_SMC_USE_32_BIT 1 > > > > Then I use PING command to my host and the minicom shows the host is not > > alive.But I am sure the host is right because I had PING the host ,which > > is in VMware. > > And after I turn on the DEBUG of SMC9.c to 5 ,I get the message.Here > > are part of them. > > > > SMC9: smc_hardware_send_packet > > SMC9: memory allocation, try 1 failed ... > > SMC9: memory allocation, try 2 failed ... > > SMC9: memory allocation, try 3 failed ... > > SMC9: memory allocation, try 4 failed ... > > SMC9: memory allocation, try 5 failed ... > > > > So how can I fix this problem?Can you give me some suggestions? > > ps:my u-boot run in RAM and boot from BLOB.Then the u-boot.bin skip the > > lowlevel_init function. > > > > Thank you ! > > > > > > > > > > ___ > > 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 mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tegra2: Enable data cache
On Thursday, September 15, 2011 13:30:09 Albert ARIBAUD wrote:
> I agree on the need and interest to support cache. I disagree on the way
> to get there. Turning cache off indiscriminately and hoping that board
> developers/maintainer turn their caches off will only lead to U-Boot
> failing in interesting ways and cluttering the mailing list with
> requests for help until someone figures out the cache is the culprit.
if code only works when cache is turned on, that usually means the code is
broken and is missing appropriate barriers/flushes. turning cache on doesnt
fix the underlying issue, it ignores it. ive seen this in the past with
Blackfin parts where our testers will do some operation with caches on, and
then try things with caches off, and trigger bugs in drivers due to missing
syncs but things work due to implicit timings with cache on.
> We have started outlining a solution (weak generic cache (non-)functions
> in arch/arm/lib/cache.c which only warn about cache not being enabled,
> and cpu/SoC/board specific versions that enable cache where it works.
which is causing the copy & paste i'm whining about
> We also have started discussing minimizing cache code copy -- admittedly
> spinned off a patch submission discussion, so it may have been missed,
> and I will repost the RFC in its own thread -- whereby the cache
> functions would be defined as weak function in the lib, and could be
> overriden by ISA-level function, which themselves could be overriden by
> CPU-level functions, and SoC (or even board) level functions could
> override them all.
i guess i did miss it. it doesnt matter to me how we get to the ultimate
destination ({I,D}CACHE_ON/etc...), just that ultimately the crappy/dead SoC's
are not bogging down the modern/maintained ones by forcing the common
implementation to suck.
-mike
signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tegra2: Enable data cache
Le 15/09/2011 18:31, Mike Frysinger a écrit :
> On Thursday, September 15, 2011 12:21:28 Albert ARIBAUD wrote:
>> Le 15/09/2011 05:03, Mike Frysinger a écrit :
>>> On Wednesday, September 14, 2011 11:13:40 Simon Glass wrote:
On Wed, Sep 14, 2011 at 6:10 AM, Aneesh V wrote:
>> not specific to your patch, but this seems kind of dumb to copy&
>> paste the same thing between all the arm sub arches/boards. why cant
>> the default enable_caches() look like this for arm:
>> void enable_caches(void)
>> {
>> #ifndef CONFIG_SYS_DCACHE_OFF
>> dcache_enable();
>> #endif
>> #ifndef CONFIG_SYS_ICACHE_OFF
>> icache_enable();
>> #endif
>> }
>
> That was how it was earlier. But then many boards were not cache ready
> and still didn't define CONFIG_SYS_DCACHE_OFF, so they were broken. So,
> the current situation is that the absence of CONFIG_SYS_DCACHE_OFF
> doesn't mean that the board is cache-ready.
>
> I like the suggestion made by Jason Liu, that of using
> CONFIG_SYS_DCACHE_ON instead. In the present situation ARM cpus that
> properly support cache handling seems to be in the minority, so
> CONFIG_SYS_DCACHE_ON may be more appropriate. But Wolfgang doesn't seem
> to like this.
My concern with this is that the situation will never improve. At
least this way there will be an incentive to sort things out, since
one day the cache enable code will be in arch/arm/lib/board.c. I hope
it is soon, but it will need more driver support first.
>>>
>>> right ... this sounds like the sort of thing that takes much longer than
>>> it should. i'm not the arm maintainer, but it seems like it'd have been
>>> better to add CONFIG_SYS_{I,D}CACHE_OFF to all the arm board configs and
>>> leave it up to the maintainers to turn off. then there'd be no
>>> duplication in core code and no long term migration need.
>>
>> Actually, the idea was rather to have the config options control whether
>> the code for caches is compiled or not, and the default code for caches
>> does nothing but emit a warning on the console, thereby persistently
>> nagging board msaintainers and developers to fix the issue -- whereas
>> adding CACHE_OFF on config files would not cause any message and may
>> cause the board to remain with caches off for as long as nobody
>> complains enough.
>
> runtime warnings are useful only if someone actually executes that code.
> build time warnings however are much more prominent.
>
>>> until that happens, CONFIG_SYS_{D,I}CACHE_ON sounds like a reasonable way
>>> to get things back under control.
>>
>> Nak. The right way is to make sure we have an ARM-wide default
>> implementation (in arch/arm/lib) that does nothing and warns on the
>> console about caches NOT being actually enabled, and cpu or SoC
>> implementations (e.g. in arch/arm/cpu/arm926ejs) that actually enable
>> caches on hardware on which it works.
>
> and now we're forced to copy& paste the same chunk of code everywhere for
> people who went through the effort to make things work. caches not working is
> a matter of the software not handling it, not the hardware being incapable of
> supporting things.
We are not forced to copy and paste -- see below (or see the RFC directly)
> the state of arm systems not supporting cache should be considered legacy
> cruft, not the default starting state. when people add new SoC's, they should
> be defaulting to using cache, and if they dont want it, they have to manually
> add to their board configs "turn it off".
I agree on the need and interest to support cache. I disagree on the way
to get there. Turning cache off indiscriminately and hoping that board
developers/maintainer turn their caches off will only lead to U-Boot
failing in interesting ways and cluttering the mailing list with
requests for help until someone figures out the cache is the culprit.
We have started outlining a solution (weak generic cache (non-)functions
in arch/arm/lib/cache.c which only warn about cache not being enabled,
and cpu/SoC/board specific versions that enable cache where it works.
We also have started discussing minimizing cache code copy -- admittedly
spinned off a patch submission discussion, so it may have been missed,
and I will repost the RFC in its own thread -- whereby the cache
functions would be defined as weak function in the lib, and could be
overriden by ISA-level function, which themselves could be overriden by
CPU-level functions, and SoC (or even board) level functions could
override them all.
So for those part of ARM boards which are all based on, say, an ISA for
which almost all CPUs share the same cache functionality, that
functionality would be in a single copy at the ISA level, with
exceptions for the relevant CPUs. And if a SoC is an exception to its
CPU, then only this SoC would have to override part or all of the
CPU-provided cache functions.
> -mike
Amicaleme
[U-Boot] [PATCH] pm9g45: init serial console before relocation
The early messages can be seen on the debug console.
Signed-off-by: Asen Chavdarov Dimov
---
board/ronetix/pm9g45/pm9g45.c | 14 +-
include/configs/pm9g45.h |1 +
2 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/board/ronetix/pm9g45/pm9g45.c b/board/ronetix/pm9g45/pm9g45.c
index f3374a4..08617ce 100644
--- a/board/ronetix/pm9g45/pm9g45.c
+++ b/board/ronetix/pm9g45/pm9g45.c
@@ -127,24 +127,28 @@ static void pm9g45_macb_hw_init(void)
}
#endif
-int board_init(void)
+int board_early_init_f(void)
{
struct at91_pmc *pmc = (struct at91_pmc *)ATMEL_BASE_PMC;
- /* Enable Ctrlc */
- console_init_f();
-
+ /* Enable clocks for all PIOs */
writel((1 << ATMEL_ID_PIOA) |
(1 << ATMEL_ID_PIOB) |
(1 << ATMEL_ID_PIOC) |
(1 << ATMEL_ID_PIODE), &pmc->pcer);
+ at91_seriald_hw_init();
+
+ return 0;
+}
+
+int board_init(void)
+{
/* arch number of AT91SAM9M10G45EK-Board */
gd->bd->bi_arch_number = MACH_TYPE_PM9G45;
/* adress of boot parameters */
gd->bd->bi_boot_params = PHYS_SDRAM + 0x100;
- at91_seriald_hw_init();
#ifdef CONFIG_CMD_NAND
pm9g45_nand_hw_init();
#endif
diff --git a/include/configs/pm9g45.h b/include/configs/pm9g45.h
index 672f663..e38fe93 100644
--- a/include/configs/pm9g45.h
+++ b/include/configs/pm9g45.h
@@ -54,6 +54,7 @@
#define CONFIG_INITRD_TAG 1
#define CONFIG_SKIP_LOWLEVEL_INIT
+#define CONFIG_BOARD_EARLY_INIT_F
/*
* Hardware drivers
--
1.7.4.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] pm9261: init serial console before relocation
The early messages can be seen on the debug console.
Signed-off-by: Asen Chavdarov Dimov
---
board/ronetix/pm9261/pm9261.c | 14 +-
include/configs/pm9261.h |1 +
2 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/board/ronetix/pm9261/pm9261.c b/board/ronetix/pm9261/pm9261.c
index 871b94a..e36391b 100644
--- a/board/ronetix/pm9261/pm9261.c
+++ b/board/ronetix/pm9261/pm9261.c
@@ -237,24 +237,28 @@ void lcd_show_board_info(void)
#endif /* CONFIG_LCD */
-int board_init(void)
+int board_early_init_f(void)
{
struct at91_pmc *pmc = (struct at91_pmc *)ATMEL_BASE_PMC;
- /* Enable Ctrlc */
- console_init_f();
-
+ /* Enable clocks for some PIOs */
writel(1 << ATMEL_ID_PIOA |
1 << ATMEL_ID_PIOC,
&pmc->pcer);
+ at91_seriald_hw_init();
+
+ return 0;
+}
+
+int board_init(void)
+{
/* arch number of PM9261-Board */
gd->bd->bi_arch_number = MACH_TYPE_PM9261;
/* adress of boot parameters */
gd->bd->bi_boot_params = PHYS_SDRAM + 0x100;
- at91_seriald_hw_init();
#ifdef CONFIG_CMD_NAND
pm9261_nand_hw_init();
#endif
diff --git a/include/configs/pm9261.h b/include/configs/pm9261.h
index 3a8b095..1d7abe7 100644
--- a/include/configs/pm9261.h
+++ b/include/configs/pm9261.h
@@ -158,6 +158,7 @@
#define CONFIG_INITRD_TAG 1
#undef CONFIG_SKIP_LOWLEVEL_INIT
+#define CONFIG_BOARD_EARLY_INIT_F
/*
* Hardware drivers
--
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] tegra2: Enable data cache
On Thursday, September 15, 2011 12:21:28 Albert ARIBAUD wrote:
> Le 15/09/2011 05:03, Mike Frysinger a écrit :
> > On Wednesday, September 14, 2011 11:13:40 Simon Glass wrote:
> >> On Wed, Sep 14, 2011 at 6:10 AM, Aneesh V wrote:
> not specific to your patch, but this seems kind of dumb to copy&
> paste the same thing between all the arm sub arches/boards. why cant
> the default enable_caches() look like this for arm:
> void enable_caches(void)
> {
> #ifndef CONFIG_SYS_DCACHE_OFF
> dcache_enable();
> #endif
> #ifndef CONFIG_SYS_ICACHE_OFF
> icache_enable();
> #endif
> }
> >>>
> >>> That was how it was earlier. But then many boards were not cache ready
> >>> and still didn't define CONFIG_SYS_DCACHE_OFF, so they were broken. So,
> >>> the current situation is that the absence of CONFIG_SYS_DCACHE_OFF
> >>> doesn't mean that the board is cache-ready.
> >>>
> >>> I like the suggestion made by Jason Liu, that of using
> >>> CONFIG_SYS_DCACHE_ON instead. In the present situation ARM cpus that
> >>> properly support cache handling seems to be in the minority, so
> >>> CONFIG_SYS_DCACHE_ON may be more appropriate. But Wolfgang doesn't seem
> >>> to like this.
> >>
> >> My concern with this is that the situation will never improve. At
> >> least this way there will be an incentive to sort things out, since
> >> one day the cache enable code will be in arch/arm/lib/board.c. I hope
> >> it is soon, but it will need more driver support first.
> >
> > right ... this sounds like the sort of thing that takes much longer than
> > it should. i'm not the arm maintainer, but it seems like it'd have been
> > better to add CONFIG_SYS_{I,D}CACHE_OFF to all the arm board configs and
> > leave it up to the maintainers to turn off. then there'd be no
> > duplication in core code and no long term migration need.
>
> Actually, the idea was rather to have the config options control whether
> the code for caches is compiled or not, and the default code for caches
> does nothing but emit a warning on the console, thereby persistently
> nagging board msaintainers and developers to fix the issue -- whereas
> adding CACHE_OFF on config files would not cause any message and may
> cause the board to remain with caches off for as long as nobody
> complains enough.
runtime warnings are useful only if someone actually executes that code.
build time warnings however are much more prominent.
> > until that happens, CONFIG_SYS_{D,I}CACHE_ON sounds like a reasonable way
> > to get things back under control.
>
> Nak. The right way is to make sure we have an ARM-wide default
> implementation (in arch/arm/lib) that does nothing and warns on the
> console about caches NOT being actually enabled, and cpu or SoC
> implementations (e.g. in arch/arm/cpu/arm926ejs) that actually enable
> caches on hardware on which it works.
and now we're forced to copy & paste the same chunk of code everywhere for
people who went through the effort to make things work. caches not working is
a matter of the software not handling it, not the hardware being incapable of
supporting things.
the state of arm systems not supporting cache should be considered legacy
cruft, not the default starting state. when people add new SoC's, they should
be defaulting to using cache, and if they dont want it, they have to manually
add to their board configs "turn it off".
-mike
signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tegra2: Enable data cache
Le 15/09/2011 05:03, Mike Frysinger a écrit :
> On Wednesday, September 14, 2011 11:13:40 Simon Glass wrote:
>> On Wed, Sep 14, 2011 at 6:10 AM, Aneesh V wrote:
not specific to your patch, but this seems kind of dumb to copy& paste
the same thing between all the arm sub arches/boards. why cant the
default enable_caches() look like this for arm:
void enable_caches(void)
{
#ifndef CONFIG_SYS_DCACHE_OFF
dcache_enable();
#endif
#ifndef CONFIG_SYS_ICACHE_OFF
icache_enable();
#endif
}
>>>
>>> That was how it was earlier. But then many boards were not cache ready
>>> and still didn't define CONFIG_SYS_DCACHE_OFF, so they were broken. So,
>>> the current situation is that the absence of CONFIG_SYS_DCACHE_OFF
>>> doesn't mean that the board is cache-ready.
>>>
>>> I like the suggestion made by Jason Liu, that of using
>>> CONFIG_SYS_DCACHE_ON instead. In the present situation ARM cpus that
>>> properly support cache handling seems to be in the minority, so
>>> CONFIG_SYS_DCACHE_ON may be more appropriate. But Wolfgang doesn't seem
>>> to like this.
>>
>> My concern with this is that the situation will never improve. At
>> least this way there will be an incentive to sort things out, since
>> one day the cache enable code will be in arch/arm/lib/board.c. I hope
>> it is soon, but it will need more driver support first.
>
> right ... this sounds like the sort of thing that takes much longer than it
> should. i'm not the arm maintainer, but it seems like it'd have been better
> to add CONFIG_SYS_{I,D}CACHE_OFF to all the arm board configs and leave it up
> to the maintainers to turn off. then there'd be no duplication in core code
> and no long term migration need.
Actually, the idea was rather to have the config options control whether
the code for caches is compiled or not, and the default code for caches
does nothing but emit a warning on the console, thereby persistently
nagging board msaintainers and developers to fix the issue -- whereas
adding CACHE_OFF on config files would not cause any message and may
cause the board to remain with caches off for as long as nobody
complains enough.
> until that happens, CONFIG_SYS_{D,I}CACHE_ON sounds like a reasonable way to
> get things back under control.
Nak. The right way is to make sure we have an ARM-wide default
implementation (in arch/arm/lib) that does nothing and warns on the
console about caches NOT being actually enabled, and cpu or SoC
implementations (e.g. in arch/arm/cpu/arm926ejs) that actually enable
caches on hardware on which it works.
> -mike
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm, usb, davinci: make USBPHY_CTL register configurable
Hi all,
Le 09/08/2011 07:05, Heiko Schocher a écrit :
> Hello Remy,
>
> Remy Bohmer wrote:
>> Hi,
>>
>> 2011/8/2 Heiko Schocher:
>>> Define CONFIG_DV_USBPHY_CTL for setting the USB PHY control
>>> register.
>>> Signed-off-by: Heiko Schocher
>>> cc: Sandeep Paulraj
>>> cc: Remy Bohmer
>>> ---
>>> drivers/usb/musb/davinci.c |6 +-
>>> 1 files changed, 5 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/drivers/usb/musb/davinci.c b/drivers/usb/musb/davinci.c
>>> index f56f2df..98c2c62 100644
>>> --- a/drivers/usb/musb/davinci.c
>>> +++ b/drivers/usb/musb/davinci.c
>>> @@ -26,6 +26,10 @@
>>> #include "davinci.h"
>>> #include
>>>
>>> +#if !defined(CONFIG_DV_USBPHY_CTL)
>>> +#define CONFIG_DV_USBPHY_CTL (USBPHY_SESNDEN | USBPHY_VBDTCTEN)
>>> +#endif
>>> +
>>> /* MUSB platform configuration */
>>> struct musb_config musb_cfg = {
>>> .regs = (struct musb_regs *)MENTOR_USB0_BASE,
>>> @@ -50,7 +54,7 @@ static u8 phy_on(void)
>>> writel(USBPHY_PHY24MHZ | USBPHY_SESNDEN |
>>> USBPHY_VBDTCTEN, USBPHY_CTL_PADDR);
>>> #else
>>> - writel(USBPHY_SESNDEN | USBPHY_VBDTCTEN, USBPHY_CTL_PADDR);
>>> + writel(CONFIG_DV_USBPHY_CTL, USBPHY_CTL_PADDR);
>>> #endif
>>> timeout = musb_cfg.timeout;
>>
>> What does it fix, why do you want this?
>
> I posted the cam_enc_4xx board support. Now adding USB support, and I
> have to configure this register as:
>
> #define CONFIG_DV_USBPHY_CTL (USBPHY_SESNDEN | USBPHY_VBDTCTEN | \
> USBPHY_PHY24MHZ)
>
> so I need a possibility to configure this register ... and I could not
> use DAVINCI_DM365EVM! (BTW: This define (so it seems to me) hides
> board specific code, which should be cleaned up ... Sandeep?)
>
> bye,
> Heiko
No new reply on this since early august... Personally, I'd rather this
patch came in a patchset where some other patch uses it.
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] net, davinci_emac: add KSZ8864 switch
On Thursday, September 15, 2011 01:36:09 Heiko Schocher wrote: > --- /dev/null > +++ b/arch/arm/cpu/arm926ejs/davinci/ksz8873.c > > +#ifdef CONFIG_DRIVER_TI_EMAC this file is only built when this is defined, so this is useless > +#ifdef CONFIG_CMD_NET building net drivers but not enabling CMD_NET is a config error. dont bother checking this yourself. -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/p3060: Add SoC related support for P3060 platform
Hello Kumar, > From: Shengzhou Liu > > Add P3060 SoC specific information:cores setup, LIODN setup, etc > > The P3060 SoC combines six e500mc Power Architecture processor cores > with > high-performance datapath acceleration architecture(DPAA), CoreNet > fabric > infrastructure, as well as network and peripheral interfaces. > > Signed-off-by: Shengzhou Liu > Signed-off-by: Kumar Gala > --- > +#elif defined(CONFIG_PPC_P3060) > +#define CONFIG_MAX_CPUS 8 I admit that I don't know anything about the P3060, but from your commit log above and Freescale standard naming conventions, shouldn't CONFIG_MAX_CPUS be 6? Thanks, John ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot for AMCC Sequoia Board (PPC440EPX) fails to boot for version 2009.11-rc1 onwards
Hi Stefan;
Here's an update on what I've discovered in 2 different areas (I am using an
older ELDK 4.1.4 for all this code) :
1) SW2 switch configurations that work on Sequoia board with 2011.06 U-boot and
some that don't since 2009.11-rc1.
2) Compiler error when accessing data from EHCI controller registers.
1 - Sequoia Board Configurations
The following first 4 SW2 dip switch settings will allow the latest 2011.06
U-Boot to run to the prompt (other settings there is no serial output). The
last 2 configs. produce no output 2009.11-rc1 onwards. SW2 has labels 4,3,2,1
and for config. IDs below OFF=0, ON=1. For example config. ID 5 has 4=OFF,
3=ON, 2=OFF, 1=ON. Frequencies (MHz) and boot strap option are shown:
Config. ID CPU PLB OPB EBC PCI BS-opt PCI-asyncComments
0 666 166 83 55 83 H I2C 66Boots with 2011.06
8 666 166 83 55 41 H I2C 33Boots with 2011.06
13 533 133 66 66 33 C EBC 33Boots with 2011.06
14 333 133 66 66 33 B EBC 33Boots with 2011.06
5 533 133 66 66 66 C EBC No output
2009.11-rc1 onwards
6 333 166 66 66 66 B EBC No output
2009.11-rc1 onwards
Note: Removing the 2 calls to ppc4xx_pci_sync_clock_config() in sequoia.c
allows configs. 5 & 6 to run as well. I have not pursued this any further as
config. 0 gives us a 66 Mhz PCI setting.
2 - Compiler error reading EHCI controller registers
I could not get EHCI devices (high-speed) to be detected on the Sequoia board
with the 2011.06 release. OHCI worked fine. I tracked it down to the use of
the HC_VERSION and HC_LENGTH macros used to extract the version and capability
length from the hccr->cr_capbase register at 0xE300. A clue was when I did
"usb reset" the version showed as "USB EHCI 0.10" instead of "USB EHCI 1.00".
This is because the code has taken the wrong 16 bits of the register. For this
controller the data reads as big endian if a 32-bit read is done. For 8 &
16-bit reads the data is returned little endian. For instance, this cr_capbase
reads as 0x0110 for a 32-bit read, but as "10 00 00 01" as 8-bit reads. At
the end of usb_low_level_init() in ehci-hcd.c it tries to extract the version
major number by reading 32 bits, then shifting right 16 bits then shifting 8
bits. My ELDK 4.1.4 compiler shortcuts this and just does an "lhz" 16-bit read
(even though the ehci_readl(x) has "volatile u32 *
") followed by an 8 bit shift. The 16-bit read gets 0x0010 instead. The
HC_LENGTH macro used in ehci_hcd_init() in ehci-ppc4xx.c had a similar shortcut
done trying to get the capability length and read the version bytes instead.
This caused all the "hcor" registers to only be shifted by 1 instead of by 0x10
thereby causing all those register accesses to be incorrect. The following Diff
outputs (changes are in ">" file) shows the changes we have made to correct the
problem - use of volatile and 32-bit operations. This could obviously cause
problems for any other code that sub-divides the 32-bit register values for
devices that behave the same way. Perhaps newer compilers have fixed this
problem.
# diff ehci-hcd.c /work/sandboxes/u-boot-2011.06_rel/drivers/usb/host/
800c800
< uint32_t reg;
---
> volatile uint32_t reg;
854,855c854,855
< reg = HC_VERSION(ehci_readl(&hccr->cr_capbase));
< printf("USB EHCI %x.%02x\n", reg >> 8, reg & 0xff);
---
> reg = ehci_readl(&hccr->cr_capbase);
> printf("USB EHCI %x.%02x\n", reg >> 24, (reg >> 16) & 0x00ff);
# diff ehci-ppc4xx.c /work/sandboxes/u-boot-2011.06_rel/drivers/usb/host/
33a34
> volatile uint32_t reg;
34a36
> reg = ehci_readl(&hccr->cr_capbase);
36c38
< HC_LENGTH(ehci_readl(&hccr->cr_capbase)));
---
> HC_LENGTH(reg));
Hope that is useful. Thanks for all the help.
Doug
-Original Message-
From: Stefan Roese [mailto:s...@denx.de]
Sent: Tuesday, September 13, 2011 4:11 AM
To: Hayes,Doug
Cc: U-Boot-Users
Subject: Re: [U-Boot] U-Boot for AMCC Sequoia Board (PPC440EPX) fails to boot
for version 2009.11-rc1 onwards
Doug,
On Friday 09 September 2011 22:04:51 Hayes,Doug wrote:
> I removed the same 2 calls from the latest U-Boot (2011.06) and it boots to
> U-Boot prompt as well. Not sure how to set the card to 33MHz, it may
> already start at 33MHz. The documentation on SW2 doesn't mention PCI
> settings (our current setting for SW2 is 4321:OFF,ON,OFF,ON?). We are
> using Bootstrap Option C which comes up at PCI 33 MHz then I assume is
> changed to 66MHz by SW?
Hmmm. I checked with exactly your configuration:
U-Boot 2011.06-00588-g49ea2e3 (Sep 09 2011 - 08:20:40)
CPU: AMCC PowerPC 440EPx Rev. A at 528 MHz (PLB=132 OPB=66 EBC=66 PCI=66
MHz)
Security/Ka
Re: [U-Boot] [PATCH 1/1] mmc: omap: enable high capacity
> > > > > >> > >> On Thu, Aug 25, 2011 at 7:46 AM, Balaji T K wrote: > >> > Enable high capacity to host capability. > >> > Fixes eMMC detection on boot from MMC/SD card. > >> > > >> > Signed-off-by: Balaji T K > >> > Signed-off-by: Aneesh V > >> > --- > >> > drivers/mmc/omap_hsmmc.c | 3 ++- > >> > 1 files changed, 2 insertions(+), 1 deletions(-) > >> > > >> > diff --git a/drivers/mmc/omap_hsmmc.c b/drivers/mmc/omap_hsmmc.c > >> > index ef12ecd..6627905 100644 > >> > --- a/drivers/mmc/omap_hsmmc.c > >> > +++ b/drivers/mmc/omap_hsmmc.c > >> > @@ -461,7 +461,8 @@ int omap_mmc_init(int dev_index) > >> > return 1; > >> > } > >> > mmc->voltages = MMC_VDD_32_33 | MMC_VDD_33_34 | > MMC_VDD_165_195; > >> > - mmc->host_caps = MMC_MODE_4BIT | MMC_MODE_HS_52MHz | > >> MMC_MODE_HS; > >> > + mmc->host_caps = MMC_MODE_4BIT | MMC_MODE_HS_52MHz | > MMC_MODE_HS > >> | > >> > + MMC_MODE_HC; > >> > > >> > mmc->f_min = 40; > >> > mmc->f_max = 5200; > >> > -- > >> > >> I tested a similar patch on a Tegra2 system, so: > >> > >> Acked-by: Simon Glass > >> > > > > If it is OK with Andy, I can apply this to u-boot-ti. > > > > --Sandeep > > > Hi Andy, > > I tested this on OMAP3 beagle board with 512MB and 4GB card. > mmc read and write is OK. Can you pull this patch ? Or please give an ACK, so that I can pull it into u-boot-ti. --Sandeep ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] mmc: omap: config VMMC, MMC1_PBIAS
Hi Andy,
This patch has been tested on OMAP3 beagle board and OMAP4 Blaze
mmc read and write is OK.
Do you have any comments on this patch?
--
Thanks and Regards,
Balaji T K
On Thu, Sep 8, 2011 at 10:04 PM, Balaji T K wrote:
> Config VMMC voltage to 3V for MMC/SD card slot
> and PBIAS settings needed for OMAP4
> Fixes MMC/SD detection on boot from eMMC.
>
> Signed-off-by: Balaji T K
> Signed-off-by: Aneesh V
> ---
> arch/arm/include/asm/arch-omap4/omap4.h | 8 +++-
> drivers/mmc/omap_hsmmc.c | 31
> ---
> drivers/power/twl6030.c | 7 +++
> include/configs/omap4_common.h | 2 ++
> include/configs/omap4_sdp4430.h | 2 ++
> include/twl6030.h | 3 +++
> 6 files changed, 49 insertions(+), 4 deletions(-)
>
> Index: u-boot/arch/arm/include/asm/arch-omap4/omap4.h
> ===
> --- u-boot.orig/arch/arm/include/asm/arch-omap4/omap4.h 2011-09-07
> 15:25:24.0 +0530
> +++ u-boot/arch/arm/include/asm/arch-omap4/omap4.h 2011-09-07
> 15:42:59.911624374 +0530
> @@ -125,6 +125,10 @@
> /* CONTROL_EFUSE_2 */
> #define CONTROL_EFUSE_2_NMOS_PMOS_PTV_CODE_1 0x00ffc000
>
> +#define MMC1_PWRDNZ (1 << 26)
> +#define MMC1_PBIASLITE_PWRDNZ (1 << 22)
> +#define MMC1_PBIASLITE_VMODE (1 << 21)
> +
> #ifndef __ASSEMBLY__
>
> struct s32ktimer {
> @@ -141,7 +145,9 @@ struct omap4_sys_ctrl_regs {
> unsigned int control_ldosram_iva_voltage_ctrl; /* 0x4A002320 */
> unsigned int control_ldosram_mpu_voltage_ctrl; /* 0x4A002324 */
> unsigned int control_ldosram_core_voltage_ctrl; /* 0x4A002328 */
> - unsigned int pad3[260341];
> + unsigned int pad3[260277];
> + unsigned int control_pbiaslite; /* 0x4A100600 */
> + unsigned int pad4[63];
> unsigned int control_efuse_1; /* 0x4A100700 */
> unsigned int control_efuse_2; /* 0x4A100704 */
> };
> Index: u-boot/drivers/mmc/omap_hsmmc.c
> ===
> --- u-boot.orig/drivers/mmc/omap_hsmmc.c 2011-09-07 15:25:56.0
> +0530
> +++ u-boot/drivers/mmc/omap_hsmmc.c 2011-09-08 17:42:05.506320837 +0530
> @@ -28,6 +28,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -38,7 +39,27 @@
> static int mmc_read_data(hsmmc_t *mmc_base, char *buf, unsigned int size);
> static int mmc_write_data(hsmmc_t *mmc_base, const char *buf, unsigned int
> siz);
> static struct mmc hsmmc_dev[2];
> -unsigned char mmc_board_init(hsmmc_t *mmc_base)
> +
> +#if defined(CONFIG_OMAP44XX) && defined(CONFIG_TWL6030_POWER)
> +static void omap4_vmmc_pbias_config(struct mmc *mmc)
> +{
> + u32 value = 0;
> + struct omap4_sys_ctrl_regs *const ctrl =
> + (struct omap4_sys_ctrl_regs *)SYSCTRL_GENERAL_CORE_BASE;
> +
> +
> + value = readl(&ctrl->control_pbiaslite);
> + value &= ~(MMC1_PBIASLITE_PWRDNZ | MMC1_PWRDNZ);
> + writel(value, &ctrl->control_pbiaslite);
> + /* set VMMC to 3V */
> + twl6030_power_mmc_init();
> + value = readl(&ctrl->control_pbiaslite);
> + value |= MMC1_PBIASLITE_VMODE | MMC1_PBIASLITE_PWRDNZ | MMC1_PWRDNZ;
> + writel(value, &ctrl->control_pbiaslite);
> +}
> +#endif
> +
> +unsigned char mmc_board_init(struct mmc *mmc)
> {
> #if defined(CONFIG_TWL4030_POWER)
> twl4030_power_mmc_init();
> @@ -67,7 +88,11 @@ unsigned char mmc_board_init(hsmmc_t *mm
> &prcm_base->iclken1_core);
> #endif
>
> -/* TODO add appropriate OMAP4 init - none currently necessary */
> +#if defined(CONFIG_OMAP44XX) && defined(CONFIG_TWL6030_POWER)
> + /* PBIAS config needed for MMC1 only */
> + if (mmc->block_dev.dev == 0)
> + omap4_vmmc_pbias_config(mmc);
> +#endif
>
> return 0;
> }
> @@ -108,7 +133,7 @@ static int mmc_init_setup(struct mmc *mm
> unsigned int dsor;
> ulong start;
>
> - mmc_board_init(mmc_base);
> + mmc_board_init(mmc);
>
> writel(readl(&mmc_base->sysconfig) | MMC_SOFTRESET,
> &mmc_base->sysconfig);
> Index: u-boot/drivers/power/twl6030.c
> ===
> --- u-boot.orig/drivers/power/twl6030.c 2011-09-07 15:23:59.0 +0530
> +++ u-boot/drivers/power/twl6030.c 2011-09-08 17:41:22.621998671 +0530
> @@ -182,6 +182,13 @@ void twl6030_init_battery_charging(void)
> return;
> }
>
> +void twl6030_power_mmc_init()
> +{
> + /* set voltage to 3.0 and turnon for APP */
> + twl6030_i2c_write_u8(TWL6030_CHIP_PM, 0x15, VMMC_CFG_VOLTATE);
> + twl6030_i2c_write_u8(TWL6030_CHIP_PM, 0x21, VMMC_CFG_STATE);
> +}
> +
> void twl6030_usb_device_settings()
> {
Re: [U-Boot] [PATCH 1/1] mmc: omap: enable high capacity
On Wed, Sep 14, 2011 at 7:43 PM, Paulraj, Sandeep wrote: > > >> >> On Thu, Aug 25, 2011 at 7:46 AM, Balaji T K wrote: >> > Enable high capacity to host capability. >> > Fixes eMMC detection on boot from MMC/SD card. >> > >> > Signed-off-by: Balaji T K >> > Signed-off-by: Aneesh V >> > --- >> > drivers/mmc/omap_hsmmc.c | 3 ++- >> > 1 files changed, 2 insertions(+), 1 deletions(-) >> > >> > diff --git a/drivers/mmc/omap_hsmmc.c b/drivers/mmc/omap_hsmmc.c >> > index ef12ecd..6627905 100644 >> > --- a/drivers/mmc/omap_hsmmc.c >> > +++ b/drivers/mmc/omap_hsmmc.c >> > @@ -461,7 +461,8 @@ int omap_mmc_init(int dev_index) >> > return 1; >> > } >> > mmc->voltages = MMC_VDD_32_33 | MMC_VDD_33_34 | MMC_VDD_165_195; >> > - mmc->host_caps = MMC_MODE_4BIT | MMC_MODE_HS_52MHz | >> MMC_MODE_HS; >> > + mmc->host_caps = MMC_MODE_4BIT | MMC_MODE_HS_52MHz | MMC_MODE_HS >> | >> > + MMC_MODE_HC; >> > >> > mmc->f_min = 40; >> > mmc->f_max = 5200; >> > -- >> >> I tested a similar patch on a Tegra2 system, so: >> >> Acked-by: Simon Glass >> > > If it is OK with Andy, I can apply this to u-boot-ti. > > --Sandeep > Hi Andy, I tested this on OMAP3 beagle board with 512MB and 4GB card. mmc read and write is OK. Can you pull this patch ? -- Thanks and Regards, Balaji T K ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3] net: axi_ethernet: Add driver to u-boot
Add axi_ethernet driver for little-endian Microblaze. RX/TX BDs and rxframe buffer are shared among all axi_ethernet MACs. Only one MAC can work in one time. Signed-off-by: Michal Simek --- v2: Fix cammelcase weirdness Create mdio_wait function with timeouts Synchronize debug messages Remove base address + offset notation -> use struct instead v3: Fix comments Add timeouts/delays to waiting loops Use in/out_be32 for dma accesses Setup return values for phy functions --- drivers/net/Makefile |1 + drivers/net/xilinx_axi_emac.c | 664 + include/netdev.h |2 + 3 files changed, 667 insertions(+), 0 deletions(-) create mode 100644 drivers/net/xilinx_axi_emac.c diff --git a/drivers/net/Makefile b/drivers/net/Makefile index 819b197..0489ffa 100644 --- a/drivers/net/Makefile +++ b/drivers/net/Makefile @@ -83,6 +83,7 @@ COBJS-$(CONFIG_TSEC_ENET) += tsec.o fsl_mdio.o COBJS-$(CONFIG_TSI108_ETH) += tsi108_eth.o COBJS-$(CONFIG_ULI526X) += uli526x.o COBJS-$(CONFIG_VSC7385_ENET) += vsc7385.o +COBJS-$(CONFIG_XILINX_AXIEMAC) += xilinx_axi_emac.o COBJS-$(CONFIG_XILINX_EMACLITE) += xilinx_emaclite.o COBJS := $(sort $(COBJS-y)) diff --git a/drivers/net/xilinx_axi_emac.c b/drivers/net/xilinx_axi_emac.c new file mode 100644 index 000..82e254b --- /dev/null +++ b/drivers/net/xilinx_axi_emac.c @@ -0,0 +1,664 @@ +/* + * Copyright (C) 2011 Michal Simek + * Copyright (C) 2011 PetaLogix + * Copyright (C) 2010 Xilinx, Inc. All rights reserved. + * + * See file CREDITS for list of people who contributed to this + * project. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; either version 2 of + * the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, + * MA 02111-1307 USA + */ + +#include +#include +#include +#include +#include +#include +#include + +#if !defined(CONFIG_PHYLIB) +# error AXI_ETHERNET requires PHYLIB +#endif + +/* Link setup */ +#define XAE_EMMC_LINKSPEED_MASK0xC000 /* Link speed */ +#define XAE_EMMC_LINKSPD_100x /* Link Speed mask for 10 Mbit */ +#define XAE_EMMC_LINKSPD_100 0x4000 /* Link Speed mask for 100 Mbit */ +#define XAE_EMMC_LINKSPD_1000 0x8000 /* Link Speed mask for 1000 Mbit */ + +/* Interrupt Status/Enable/Mask Registers bit definitions */ +#define XAE_INT_RXRJECT_MASK 0x0008 /* Rx frame rejected */ +#define XAE_INT_MGTRDY_MASK0x0080 /* MGT clock Lock */ + +/* Receive Configuration Word 1 (RCW1) Register bit definitions */ +#define XAE_RCW1_RX_MASK 0x1000 /* Receiver enable */ + +/* Transmitter Configuration (TC) Register bit definitions */ +#define XAE_TC_TX_MASK 0x1000 /* Transmitter enable */ + +#define XAE_UAW1_UNICASTADDR_MASK 0x + +/* MDIO Management Configuration (MC) Register bit definitions */ +#define XAE_MDIO_MC_MDIOEN_MASK0x0040 /* MII management enable*/ + +/* MDIO Management Control Register (MCR) Register bit definitions */ +#define XAE_MDIO_MCR_PHYAD_MASK0x1F00 /* Phy Address Mask */ +#define XAE_MDIO_MCR_PHYAD_SHIFT 24 /* Phy Address Shift */ +#define XAE_MDIO_MCR_REGAD_MASK0x001F /* Reg Address Mask */ +#define XAE_MDIO_MCR_REGAD_SHIFT 16 /* Reg Address Shift */ +#define XAE_MDIO_MCR_OP_READ_MASK 0x8000 /* Op Code Read Mask */ +#define XAE_MDIO_MCR_OP_WRITE_MASK 0x4000 /* Op Code Write Mask */ +#define XAE_MDIO_MCR_INITIATE_MASK 0x0800 /* Ready Mask */ +#define XAE_MDIO_MCR_READY_MASK0x0080 /* Ready Mask */ + +#define XAE_MDIO_DIV_DFT 29 /* Default MDIO clock divisor */ + +/* DMA macros */ +/* Bitmasks of XAXIDMA_CR_OFFSET register */ +#define XAXIDMA_CR_RUNSTOP_MASK0x0001 /* Start/stop DMA channel */ +#define XAXIDMA_CR_RESET_MASK 0x0004 /* Reset DMA engine */ + +/* Bitmasks of XAXIDMA_SR_OFFSET register */ +#define XAXIDMA_HALTED_MASK0x0001 /* DMA channel halted */ + +/* Bitmask for interrupts */ +#define XAXIDMA_IRQ_IOC_MASK 0x1000 /* Completion intr */ +#define XAXIDMA_IRQ_DELAY_MASK 0x2000 /* Delay interrupt */ +#define XAXIDMA_IRQ_ALL_MASK 0x7000 /* All interrupts */ + +/* Bitmasks of XAXIDMA_BD_CTRL_OFFSET register */ +#define XAXIDMA_BD_CTRL_TXSOF_MASK 0x0800 /* First tx packet */ +#define XAXIDMA_BD_CTRL_TXEOF_MASK
[U-Boot] [RFC PATCH 4/4 v1] dreamplug: enable fdt
Signed-off-by: Jason Cooper
---
board/Marvell/dreamplug/kirkwood-dreamplug.dts | 12 +++
board/Marvell/dreamplug/kirkwood.dtsi | 25
include/configs/dreamplug.h|5
3 files changed, 42 insertions(+), 0 deletions(-)
create mode 100644 board/Marvell/dreamplug/kirkwood-dreamplug.dts
create mode 100644 board/Marvell/dreamplug/kirkwood.dtsi
diff --git a/board/Marvell/dreamplug/kirkwood-dreamplug.dts
b/board/Marvell/dreamplug/kirkwood-dreamplug.dts
new file mode 100644
index 000..eb900c3
--- /dev/null
+++ b/board/Marvell/dreamplug/kirkwood-dreamplug.dts
@@ -0,0 +1,12 @@
+/dts-v1/;
+
+/include/ "kirkwood.dtsi"
+
+/ {
+ model = "Marvell Dreamplug";
+ compatible = "marvell,dreamplug", "marvell,kirkwood";
+
+ rtc@0xf1010300 {
+ status = "ok";
+ };
+};
diff --git a/board/Marvell/dreamplug/kirkwood.dtsi
b/board/Marvell/dreamplug/kirkwood.dtsi
new file mode 100644
index 000..15e52bd
--- /dev/null
+++ b/board/Marvell/dreamplug/kirkwood.dtsi
@@ -0,0 +1,25 @@
+/ {
+ model = "Marvell Kirkwood";
+ compatible = "marvell,kirkwood";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ cpu@0 {
+ compatible = "arm,arm926ejs";
+ reg = <0>;
+ };
+ };
+
+ rtc@0xf1010300 {
+ compatible = "marvell,kirkwood-rtc";
+ reg = <0xf1010300 0x02>;
+ status = "disabled";
+ };
+
+ aliases {
+ rtc0 = "/rtc@0xf1010300";
+ };
+};
diff --git a/include/configs/dreamplug.h b/include/configs/dreamplug.h
index 8d1b935..9960d35 100644
--- a/include/configs/dreamplug.h
+++ b/include/configs/dreamplug.h
@@ -50,6 +50,11 @@
#define CONFIG_MACH_TYPE MACH_TYPE_DREAMPLUG
#define CONFIG_SKIP_LOWLEVEL_INIT /* disable board lowlevel_init */
+#define CONFIG_OF_EMBED
+#define CONFIG_DEFAULT_DEVICE_TREE "kirkwood-dreamplug"
+#define CONFIG_OF_CONTROL
+#define CONFIG_OF_LIBFDT
+
/*
* Commands configuration
*/
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC PATCH 3/4 v1] mvrtc: add fdt support.
Signed-off-by: Jason Cooper
---
common/fdt_decode.c |1 +
drivers/rtc/mvrtc.c | 62 +++--
drivers/rtc/mvrtc.h |7 +
include/fdt_decode.h |1 +
4 files changed, 68 insertions(+), 3 deletions(-)
diff --git a/common/fdt_decode.c b/common/fdt_decode.c
index 0f13089..1a0dcf4 100644
--- a/common/fdt_decode.c
+++ b/common/fdt_decode.c
@@ -34,6 +34,7 @@
*/
#define COMPAT(id, name) name
const char *compat_names[COMPAT_COUNT] = {
+ COMPAT(MARVELL_KIRKWOOD_RTC, "marvell,kirkwood-rtc"),
};
/**
diff --git a/drivers/rtc/mvrtc.c b/drivers/rtc/mvrtc.c
index ccc573a..ce2dc3d 100644
--- a/drivers/rtc/mvrtc.c
+++ b/drivers/rtc/mvrtc.c
@@ -28,18 +28,62 @@
#include
#include
#include
+#ifdef CONFIG_OF_CONTROL
+#include
+#endif
#include "mvrtc.h"
+DECLARE_GLOBAL_DATA_PTR;
+
/* This RTC does not support century, so we assume 20 */
#define CENTURY 20
+#ifndef CONFIG_OF_CONTROL
+struct mvrtc_registers *mvrtc_get_config(void) {
+ return (struct mvrtc_registers *)KW_RTC_BASE;
+}
+
+#else
+int fdt_decode_rtc(const void *blob, int node, struct fdt_rtc *config)
+{
+ config->reg = get_addr(blob, node, "reg");
+ config->enabled = get_is_enabled(blob, node, 0);
+
+ return 0;
+}
+
+struct mvrtc_registers *mvrtc_get_config(void) {
+ const void *blob = gd->blob;
+ struct fdt_rtc config;
+ intnode;
+ intindex=0;
+
+ node = fdt_decode_next_alias(blob, "rtc",
+COMPAT_MARVELL_KIRKWOOD_RTC, &index);
+
+ if (node < 0)
+ return NULL;
+
+ if (fdt_decode_rtc(blob, node, &config))
+ return NULL;
+
+ return config.enabled ? (struct mvrtc_registers *)config.reg : NULL;
+}
+#endif
+
int rtc_get(struct rtc_time *t)
{
u32 time;
u32 date;
struct mvrtc_registers *mvrtc_regs;
- mvrtc_regs = (struct mvrtc_registers *)KW_RTC_BASE;
+ mvrtc_regs = mvrtc_get_config();
+#ifdef CONFIG_OF_CONTROL
+ if (mvrtc_regs == NULL) {
+ printf("Error decoding fdt for mvrtc.\n");
+ return -1;
+ }
+#endif
/* read the time register */
time = readl(&mvrtc_regs->time);
@@ -79,7 +123,13 @@ int rtc_set(struct rtc_time *t)
u32 date = 0;
struct mvrtc_registers *mvrtc_regs;
- mvrtc_regs = (struct mvrtc_registers *)KW_RTC_BASE;
+ mvrtc_regs = mvrtc_get_config();
+#ifdef CONFIG_OF_CONTROL
+ if (mvrtc_regs == NULL) {
+ printf("Error decoding fdt for mvrtc.\n");
+ return -1;
+ }
+#endif
/* check that this code isn't 80+ years old ;-) */
if ((t->tm_year / 100) != CENTURY)
@@ -111,7 +161,13 @@ void rtc_reset(void)
u32 sec;
struct mvrtc_registers *mvrtc_regs;
- mvrtc_regs = (struct mvrtc_registers *)KW_RTC_BASE;
+ mvrtc_regs = mvrtc_get_config();
+#ifdef CONFIG_OF_CONTROL
+ if (mvrtc_regs == NULL) {
+ printf("Error decoding fdt for mvrtc.\n");
+ return;
+ }
+#endif
/* no init routine for this RTC needed, just check that it's working */
time = readl(&mvrtc_regs->time);
diff --git a/drivers/rtc/mvrtc.h b/drivers/rtc/mvrtc.h
index b9d5c6f..56b09f2 100644
--- a/drivers/rtc/mvrtc.h
+++ b/drivers/rtc/mvrtc.h
@@ -37,6 +37,13 @@ struct mvrtc_registers {
u32 date;
};
+#ifdef CONFIG_OF_CONTROL
+struct fdt_rtc {
+ addr_t reg; /* address of the registers */
+ int enabled; /* 1 if enabled, 0 if disabled */
+};
+#endif
+
/* time register */
#define MVRTC_SEC_SFT 0
#define MVRTC_SEC_MSK 0x7f
diff --git a/include/fdt_decode.h b/include/fdt_decode.h
index 4264e3b..f236643 100644
--- a/include/fdt_decode.h
+++ b/include/fdt_decode.h
@@ -54,6 +54,7 @@ struct fdt_memory {
*/
enum fdt_compat_id {
COMPAT_UNKNOWN,
+ COMPAT_MARVELL_KIRKWOOD_RTC,
COMPAT_COUNT,
};
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC PATCH 1/4 v1] fdt: remove i2c example code.
Signed-off-by: Jason Cooper
---
common/fdt_decode.c | 14 --
include/fdt_decode.h | 32
2 files changed, 0 insertions(+), 46 deletions(-)
diff --git a/common/fdt_decode.c b/common/fdt_decode.c
index 9e8cf4d..cd7a071 100644
--- a/common/fdt_decode.c
+++ b/common/fdt_decode.c
@@ -34,7 +34,6 @@
*/
#define COMPAT(id, name) name
static const char *compat_names[COMPAT_COUNT] = {
- COMPAT(NVIDIA_TEGRA250_I2C, "nvidia,tegra250-i2c"),
};
/**
@@ -162,16 +161,3 @@ int fdt_decode_next_alias(const void *blob, const char
*name,
return err ? -FDT_ERR_MISSING : node;
}
-int fdt_decode_i2c(const void *blob, int node, struct fdt_i2c *config)
-{
- config->reg = (struct i2c_ctlr *)get_addr(blob, node, "reg");
- config->pinmux = get_int(blob, node, "pinmux", 0);
- config->speed = get_int(blob, node, "speed", 0);
- config->periph_id = get_int(blob, node, "periph-id", -1);
- config->enabled = get_is_enabled(blob, node, 0);
-
- if (config->periph_id == -1)
- return -FDT_ERR_MISSING;
-
- return 0;
-}
diff --git a/include/fdt_decode.h b/include/fdt_decode.h
index bdcdbba..ba3c15b 100644
--- a/include/fdt_decode.h
+++ b/include/fdt_decode.h
@@ -28,9 +28,6 @@
* changes to support FDT are minimized.
*/
-#include
-#include
-
/* A typedef for a physical address. We should move it to a generic place */
#ifdef CONFIG_PHYS_64BIT
typedef u64 addr_t;
@@ -55,36 +52,7 @@ struct fdt_memory {
*/
enum fdt_compat_id {
COMPAT_UNKNOWN,
- COMPAT_NVIDIA_TEGRA250_I2C, /* Tegra 250 i2c */
-
COMPAT_COUNT,
};
-/* Information about i2c controller */
-struct fdt_i2c {
- struct i2c_ctlr *reg; /* Address of controller registers */
- int pinmux; /* Which pin mux setting to use */
- u32 speed; /* Speed in KHz */
- enum periph_id periph_id; /* Peripheral ID for clock/pinmux */
- int enabled;/* 1 if enabled, 0 if disabled */
-};
-/**
- * Returns information from the FDT about an i2c controler. This function reads
- * out the following attributes:
- *
- * reg
- * enabled
- * pinmux
- * speed
- * periph-id
- *
- * @param blob FDT blob to use
- * @param node Node to read from
- * @param config structure to use to return information
- * @returns 0 on success, -ve on error, in which case config may or may not be
- * unchanged. If the node is present but expected data is
- * missing then this will generally return
- * -FDT_ERR_MISSING.
- */
-int fdt_decode_i2c(const void *blob, int node, struct fdt_i2c *config);
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC PATCH 2/4 v1] fdt_decode: make more available.
Signed-off-by: Jason Cooper
---
common/fdt_decode.c | 11 +--
include/fdt_decode.h | 13 +
2 files changed, 18 insertions(+), 6 deletions(-)
diff --git a/common/fdt_decode.c b/common/fdt_decode.c
index cd7a071..0f13089 100644
--- a/common/fdt_decode.c
+++ b/common/fdt_decode.c
@@ -33,7 +33,7 @@
* turn this into a sparse list later, and keeps the ID with the name.
*/
#define COMPAT(id, name) name
-static const char *compat_names[COMPAT_COUNT] = {
+const char *compat_names[COMPAT_COUNT] = {
};
/**
@@ -43,7 +43,7 @@ static const char *compat_names[COMPAT_COUNT] = {
* @param name alias name to look up
* @return node offset if found, or an error code < 0 otherwise
*/
-static int find_alias_node(const void *blob, const char *name)
+int find_alias_node(const void *blob, const char *name)
{
const char *path;
int alias_node;
@@ -68,7 +68,7 @@ static int find_alias_node(const void *blob, const char *name)
* @param prop_namename of property to find
* @return address, if found, or ADDR_T_NONE if not
*/
-static addr_t get_addr(const void *blob, int node, const char *prop_name)
+addr_t get_addr(const void *blob, int node, const char *prop_name)
{
const addr_t *cell;
int len;
@@ -91,7 +91,7 @@ static addr_t get_addr(const void *blob, int node, const char
*prop_name)
* @param default_val default value to return if the property is not found
* @return integer value, if found, or default_val if not
*/
-static s32 get_int(const void *blob, int node, const char *prop_name,
+s32 get_int(const void *blob, int node, const char *prop_name,
s32 default_val)
{
const s32 *cell;
@@ -115,7 +115,7 @@ static s32 get_int(const void *blob, int node, const char
*prop_name,
* @param default_val default value to return if no 'status' property exists
* @return integer value 0/1, if found, or default_val if not
*/
-static int get_is_enabled(const void *blob, int node, int default_val)
+int get_is_enabled(const void *blob, int node, int default_val)
{
const char *cell;
@@ -160,4 +160,3 @@ int fdt_decode_next_alias(const void *blob, const char
*name,
return err;
return err ? -FDT_ERR_MISSING : node;
}
-
diff --git a/include/fdt_decode.h b/include/fdt_decode.h
index ba3c15b..4264e3b 100644
--- a/include/fdt_decode.h
+++ b/include/fdt_decode.h
@@ -19,6 +19,8 @@
* MA 02111-1307 USA
*/
+#ifndef _FDT_DECODE_H_
+#define _FDT_DECODE_H_
/*
* This file contains convenience functions for decoding useful and
@@ -55,4 +57,15 @@ enum fdt_compat_id {
COMPAT_COUNT,
};
+int find_alias_node(const void *blob, const char *name);
+addr_t get_addr(const void *blob, int node, const char *prop_name);
+s32 get_int(const void *blob, int node, const char *prop_name,
+ s32 default_val);
+int get_is_enabled(const void *blob, int node, int default_val);
+enum fdt_compat_id fdt_decode_lookup(const void *blob, int node);
+int fdt_decode_next_compatible(const void *blob, int node,
+ enum fdt_compat_id id);
+int fdt_decode_next_alias(const void *blob, const char *name,
+ enum fdt_compat_id id, int *upto);
+#endif
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC PATCH 0/4 v1] Use fdt to init mvrtc driver for dreamplug
Simon, All, This patch series is my attempt to learn device tree with a driver I'm familiar with. Also, to create a real, working example for fdt in U-boot. To make this work, I applied v2 of Simon Glass' patch series (what this email is in reply to) against v2011.09-rc1. I then cherry picked my dreamplug board support patch. Last, I applied the following series. It works, although with CONFIG_OF_EMBED. I haven't tried _SEPARATE yet. Some thoughts: 1.) 'kirkwood-dreamplug.dts' can be renamed 'dreamplug.dts'. Due to machine_is_XXX 'dreamplug' will be unique, concise, and descriptive. This requires changes to Simon Glass' patchset. 2.) The fdt files should be moved up one directory level, in the end, it should look like: board/Marvell/armada100-dt.c board/Marvell/armada100-dt.h board/Marvell/armada100.dtsi board/Marvell/dreamplug.dts board/Marvell/gplugd.dts # this includes armada100.dtsi board/Marvell/guruplug.dts board/Marvell/kirkwood.dtsi board/Marvell/kirkwood-dt.c board/Marvell/kirkwood-dt.h board/Marvell/openrd.dts board/Marvell/sheevaplug.dts ... board/Marvell/.dts This also requires changes to Simon's patchset. 3.) Since mach names (dreamplug) and SoC names (kirkwood) are unique, should we put all .dts and .dtsi files in one dir? eg /dts ? This would facilitate migration to Grant Likely's device-tree.git whereever and whenever it lands. This is also similar to how Linux currently does it (arch/arm/boot/dts/) Jason Cooper (4): fdt: remove i2c example code. fdt_decode: make more available. mvrtc: add fdt support. dreamplug: enable fdt board/Marvell/dreamplug/kirkwood-dreamplug.dts | 12 + board/Marvell/dreamplug/kirkwood.dtsi | 25 ++ common/fdt_decode.c| 26 ++ drivers/rtc/mvrtc.c| 62 ++- drivers/rtc/mvrtc.h|7 +++ include/configs/dreamplug.h|5 ++ include/fdt_decode.h | 46 + 7 files changed, 128 insertions(+), 55 deletions(-) create mode 100644 board/Marvell/dreamplug/kirkwood-dreamplug.dts create mode 100644 board/Marvell/dreamplug/kirkwood.dtsi ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot-1.3.3 SMC91111 driver
Hi, first thing would be to use a current U-Boot Version. This can be obtained from: http://www.denx.de/wiki/U-Boot/SourceCode Regards Simon On 09/15/2011 03:31 PM, Chaney Lee wrote: > hello: > > I need your advise. > I port the u-boot-1.3.3 to my PXA270 board。Every thing works well but the > SMC9 dirver.I have aready config the config file like this: > #define CONFIG_DRIVER_SMC9 1 > #define CONFIG_SMC9_BASE0x1300 > #define CONFIG_SMC9_EXT_PHY > > #define CONFIG_SMC_USE_32_BIT 1 > Then I use PING command to my host and the minicom shows the host is not > alive.But I am sure the host is right because I had PING the host ,which is > in VMware. > And after I turn on the DEBUG of SMC9.c to 5 ,I get the message.Here > are part of them. > > SMC9: smc_hardware_send_packet > SMC9: memory allocation, try 1 failed ... > SMC9: memory allocation, try 2 failed ... > SMC9: memory allocation, try 3 failed ... > SMC9: memory allocation, try 4 failed ... > SMC9: memory allocation, try 5 failed ... > > So how can I fix this problem?Can you give me some suggestions? > ps:my u-boot run in RAM and boot from BLOB.Then the u-boot.bin skip the > lowlevel_init function. > > Thank you ! > > > > > ___ > 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 v4] serial: uartlite: Support for SERIAL_MULTI
Add support for SERIAL MULTI for uartlite.
Signed-off-by: Michal Simek
---
v2: Use in/out_be32 functions
v3: Clean coding style
v4: Simplify userial_ports array initialization
---
common/serial.c | 14
drivers/serial/serial_xuartlite.c | 134 -
include/serial.h |7 ++
3 files changed, 137 insertions(+), 18 deletions(-)
diff --git a/common/serial.c b/common/serial.c
index 995d268..df02fa5 100644
--- a/common/serial.c
+++ b/common/serial.c
@@ -108,6 +108,20 @@ void serial_initialize (void)
#if defined(CONFIG_SYS_BFIN_UART)
serial_register_bfin_uart();
#endif
+#if defined(CONFIG_XILINX_UARTLITE)
+# ifdef XILINX_UARTLITE_BASEADDR
+ serial_register(&uartlite_serial0_device);
+# endif /* XILINX_UARTLITE_BASEADDR */
+# ifdef XILINX_UARTLITE_BASEADDR1
+ serial_register(&uartlite_serial1_device);
+# endif /* XILINX_UARTLITE_BASEADDR1 */
+# ifdef XILINX_UARTLITE_BASEADDR2
+ serial_register(&uartlite_serial2_device);
+# endif /* XILINX_UARTLITE_BASEADDR2 */
+# ifdef XILINX_UARTLITE_BASEADDR3
+ serial_register(&uartlite_serial3_device);
+# endif /* XILINX_UARTLITE_BASEADDR3 */
+#endif /* CONFIG_XILINX_UARTLITE */
serial_assign (default_serial_console ()->name);
}
diff --git a/drivers/serial/serial_xuartlite.c
b/drivers/serial/serial_xuartlite.c
index 00d0eaa..9e272ef 100644
--- a/drivers/serial/serial_xuartlite.c
+++ b/drivers/serial/serial_xuartlite.c
@@ -25,20 +25,67 @@
*/
#include
+#include
#include
-
-#define RX_FIFO_OFFSET 0 /* receive FIFO, read only */
-#define TX_FIFO_OFFSET 4 /* transmit FIFO, write only */
-#define STATUS_REG_OFFSET 8 /* status register, read only */
+#include
+#include
#define SR_TX_FIFO_FULL0x08 /* transmit FIFO full */
#define SR_RX_FIFO_VALID_DATA 0x01 /* data in receive FIFO */
#define SR_RX_FIFO_FULL0x02 /* receive FIFO full */
-#define UARTLITE_STATUS(CONFIG_SERIAL_BASE + STATUS_REG_OFFSET)
-#define UARTLITE_TX_FIFO (CONFIG_SERIAL_BASE + TX_FIFO_OFFSET)
-#define UARTLITE_RX_FIFO (CONFIG_SERIAL_BASE + RX_FIFO_OFFSET)
+struct uartlite {
+ u32 rx_fifo;
+ u32 tx_fifo;
+ u32 status;
+};
+
+static struct uartlite *userial_ports[4] = {
+#ifdef XILINX_UARTLITE_BASEADDR
+ [0] = (struct uartlite *)XILINX_UARTLITE_BASEADDR,
+#endif
+#ifdef XILINX_UARTLITE_BASEADDR1
+ [1] = (struct uartlite *)XILINX_UARTLITE_BASEADDR1,
+#endif
+#ifdef XILINX_UARTLITE_BASEADDR2
+ [2] = (struct uartlite *)XILINX_UARTLITE_BASEADDR2,
+#endif
+#ifdef XILINX_UARTLITE_BASEADDR3
+ [3] = (struct uartlite *)XILINX_UARTLITE_BASEADDR3
+#endif
+};
+
+void uartlite_serial_putc(const char c, const int port)
+{
+ struct uartlite *regs = userial_ports[port];
+ if (c == '\n')
+ uartlite_serial_putc('\r', port);
+ while (in_be32(®s->status) & SR_TX_FIFO_FULL)
+ ;
+ out_be32(®s->tx_fifo, c & 0xff);
+}
+
+void uartlite_serial_puts(const char *s, const int port)
+{
+ while (*s)
+ uartlite_serial_putc(*s++, port);
+}
+
+int uartlite_serial_getc(const int port)
+{
+ struct uartlite *regs = userial_ports[port];
+ while (!(in_be32(®s->status) & SR_RX_FIFO_VALID_DATA))
+ ;
+ return in_be32(®s->rx_fifo) & 0xff;
+}
+
+int uartlite_serial_tstc(const int port)
+{
+ struct uartlite *regs = userial_ports[port];
+ return in_be32(®s->status) & SR_RX_FIFO_VALID_DATA;
+}
+#if !defined(CONFIG_SERIAL_MULTI)
int serial_init(void)
{
/* FIXME: Nothing for now. We should initialize fifo, etc */
@@ -52,26 +99,77 @@ void serial_setbrg(void)
void serial_putc(const char c)
{
- if (c == '\n')
- serial_putc('\r');
- while (in_be32((u32 *) UARTLITE_STATUS) & SR_TX_FIFO_FULL);
- out_be32((u32 *) UARTLITE_TX_FIFO, (unsigned char) (c & 0xff));
+ uartlite_serial_putc(c, 0);
}
-void serial_puts(const char * s)
+void serial_puts(const char *s)
{
- while (*s) {
- serial_putc(*s++);
- }
+ uartlite_serial_puts(s, 0);
}
int serial_getc(void)
{
- while (!(in_be32((u32 *) UARTLITE_STATUS) & SR_RX_FIFO_VALID_DATA));
- return in_be32((u32 *) UARTLITE_RX_FIFO) & 0xff;
+ return uartlite_serial_getc(0);
}
int serial_tstc(void)
{
- return (in_be32((u32 *) UARTLITE_STATUS) & SR_RX_FIFO_VALID_DATA);
+ return uartlite_serial_tstc(0);
+}
+#endif
+
+#if defined(CONFIG_SERIAL_MULTI)
+/* Multi serial device functions */
+#define DECLARE_ESERIAL_FUNCTIONS(port) \
+ int userial##port##_init(void) \
+ { return(0); } \
+ void userial##port##_setbrg(void) {} \
+ int userial##port##_getc(void) \
+ { return uartlite_serial_getc(port); } \
+ int userial##port##_tstc(void) \
+
[U-Boot] u-boot-1.3.3 SMC91111 driver
hello: I need your advise. I port the u-boot-1.3.3 to my PXA270 board。Every thing works well but the SMC9 dirver.I have aready config the config file like this: #define CONFIG_DRIVER_SMC9 1 #define CONFIG_SMC9_BASE0x1300 #define CONFIG_SMC9_EXT_PHY #define CONFIG_SMC_USE_32_BIT 1 Then I use PING command to my host and the minicom shows the host is not alive.But I am sure the host is right because I had PING the host ,which is in VMware. And after I turn on the DEBUG of SMC9.c to 5 ,I get the message.Here are part of them. SMC9: smc_hardware_send_packet SMC9: memory allocation, try 1 failed ... SMC9: memory allocation, try 2 failed ... SMC9: memory allocation, try 3 failed ... SMC9: memory allocation, try 4 failed ... SMC9: memory allocation, try 5 failed ... So how can I fix this problem?Can you give me some suggestions? ps:my u-boot run in RAM and boot from BLOB.Then the u-boot.bin skip the lowlevel_init function. Thank you ! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-arm/master
Dear Albert ARIBAUD, In message <4e705073.1090...@aribaud.net> you wrote: > Hi Wolfgang, > > The following changes since commit 6ceb0135f96d73063ffbaab5be7ce23933367388: > >Prepare v2011.09 (2011-09-11 21:31:04 +0200) > > are available in the git repository at: >git://git.denx.de/u-boot-arm.git master > > Aneesh V (4): >omap4: factor out common part from board config headers >omap4: make SDRAM init work for ES1.0 silicon >omap4: IO settings >omap4: fix pad configuration settings for SDP and Panda > > Fabio Estevam (2): >MX25: tx25: Fix build by making use of GPIO framework >MX25: tx25: Cleanup tx25.h config > > Howard D. Gray (1): >ARMV7: OMAP3: Add 37xx ESx revision numbers. > > Jason Kridner (1): >led: remove camel casing of led identifiers globally > > Joel A Fernandes (1): >OMAP: Add function to get state of a GPIO output > > Michael Jones (2): >ARMV7: OMAP: Write more than 1 byte at a time in i2c_write >ARMV7: OMAP: I2C driver: cosmetic: make checkpatch-compatible > > Nagabhushana Netagunte (3): >da830: modify the U-Boot prompt string >da830: enable SPI flash boot mode >da830: modify the MEMTEST start and end address > > Sandeep Paulraj (2): >OMAP3 Beagle: Minor config cleanup >DA830: Fix Build Warning > > Sanjeev Premi (4): >omap3: beagle: Fix build warning >omap: gpio: Use generic API >omap: gpio: generic changes after changing API >omap: gpio: Adapt board files to use generic API > > arch/arm/cpu/arm1176/start.S|2 +- > arch/arm/cpu/arm720t/start.S|2 +- > arch/arm/cpu/arm920t/ep93xx/led.c | 24 ++-- > arch/arm/cpu/arm920t/ep93xx/lowlevel_init.S | 10 +- > arch/arm/cpu/arm920t/start.S|2 +- > arch/arm/cpu/arm925t/start.S|2 +- > arch/arm/cpu/arm926ejs/at91/led.c | 12 +- > arch/arm/cpu/arm926ejs/start.S |2 +- > arch/arm/cpu/arm_intcm/start.S |2 +- > arch/arm/cpu/armv7/omap-common/gpio.c | 105 +-- > arch/arm/cpu/armv7/omap3/sys_info.c | 13 ++- > arch/arm/cpu/armv7/omap4/board.c| 62 ++ > arch/arm/cpu/armv7/omap4/clocks.c |5 +- > arch/arm/cpu/armv7/omap4/emif.c | 72 +-- > arch/arm/cpu/armv7/omap4/sdram_elpida.c | 24 ++-- > arch/arm/cpu/ixp/start.S|2 +- > arch/arm/cpu/s3c44b0/start.S|2 +- > arch/arm/include/asm/arch-omap3/omap3.h | 10 + > arch/arm/include/asm/arch-omap4/emif.h | 23 +-- > arch/arm/include/asm/arch-omap4/omap4.h | 45 - > arch/arm/include/asm/omap_gpio.h| 13 -- > arch/arm/lib/board.c| 32 ++-- > board/atmel/at91rm9200ek/led.c | 12 +- > board/cm_t35/leds.c | 10 +- > board/comelit/dig297/dig297.c | 12 +- > board/eukrea/cpu9260/led.c | 48 +++--- > board/isee/igep0020/igep0020.c | 12 +- > board/karo/tx25/tx25.c |1 + > board/logicpd/zoom2/debug_board.c | 10 +- > board/logicpd/zoom2/led.c | 66 > board/logicpd/zoom2/zoom2.c | 10 +- > board/overo/overo.c | 54 +++--- > board/ti/beagle/beagle.c| 44 ++-- > board/ti/beagle/led.c | 26 ++-- > board/ti/evm/evm.c | 12 +- > board/ti/panda/panda_mux_data.h | 41 ++-- > board/ti/sdp4430/sdp4430_mux_data.h |9 +- > common/cmd_led.c|8 +- > doc/README.omap3| 20 +- > drivers/i2c/omap24xx_i2c.c | 241 > +++- > include/configs/da830evm.h | 18 +- > include/configs/omap3_beagle.h |3 +- > include/configs/omap4_common.h | 275 > +++ > include/configs/omap4_panda.h | 244 > +--- > include/configs/omap4_sdp4430.h | 245 > +--- > include/configs/tx25.h | 16 +- > include/status_led.h| 32 ++-- > 47 files changed, 916 insertions(+), 1019 deletions(-) > create mode 100644 include/configs/omap4_common.h 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 If you think the problem is bad now, just wait until we've solved it. Epstein's Law
Re: [U-Boot] [PATCH 09/12] da850: read MAC address from I2C EEPROM on AM18xx EVM
Denk,
I comments are in-lined.
Regards,
Nag
On Tue, Aug 02, 2011 at 22:00:36, Wolfgang Denk wrote:
> Dear nagabhushana.netagu...@ti.com,
>
> In message <1312299792-16415-10-git-send-email-nagabhushana.netagu...@ti.com>
> you wrote:
> > From: Nagabhushana Netagunte
> >
> > The AM18xx EVM contains MAC address in I2C EEPROM compared
> > da850/omap-l138 Logic PD EVM which maintains in SPI flash. ...
>
> Sorry, I cannot parse this. Please reformulate.
>
> > if (!eth_getenv_enetaddr("ethaddr", enetaddr)) {
> > - /* Set Ethernet MAC address from EEPROM */
> > - ret = get_mac_addr_spi(addr);
> > - if (ret != 0)
> > - return -EINVAL;
> > + /* Read Ethernet MAC address from EEPROM */
> > + if (dvevm_read_mac_address(addr)) {
> > + /* Set Ethernet MAC address from EEPROM */
> > + davinci_sync_env_enetaddr(addr);
> > + } else {
> > + /* Set Ethernet MAC address from SPI flash */
> > + ret = get_mac_addr_spi(addr);
> > + if (ret != 0)
> > + return -EINVAL;
> > + }
>
> This is a pretty bad idea, as it will slow down booting and may cause
> undefined behaviour if anybody decides to put an EEPROm on a board where you
> assume there is none.
I understand the concern. I will introduce new config file based on board
(manufacturer). Then, based on configuration, can I access EEPROM to read MAC
address? OR do you think we should not read MAC address from EEPROM at all?
Your suggestions will be helpful.
>
> Please find a different way to test which board you have (or provide a
> separate configuration). Implement this test just once, in early init code,
> so that not each and every driver or feature as to test this himself again
> and again.
Since we can't figure out board type by any other means, I will try to
introduce new config files for each board type.
>
> 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
> "Spock, did you see the looks on their faces?"
> "Yes, Captain, a sort of vacant contentment."
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v6 1/4] gpio: Move common gpio.h to include/asm-generic
Dear Kim, In message <20110913200803.4d76579c.kim.phill...@freescale.com> you wrote: > > > arch/arm/include/asm/gpio.h | 38 > > +- > > arch/powerpc/include/asm/gpio.h |2 ++ > > include/asm-generic/gpio.h | 37 > > + > > 3 files changed, 40 insertions(+), 37 deletions(-) > > create mode 100644 arch/powerpc/include/asm/gpio.h > > create mode 100644 include/asm-generic/gpio.h > > applied 4 out of 4 patches. > > Wolfgang, technically this is a multi-domain patchseries, and I've > overstepped my boundaries for the sake of expediency in adding the > GPIO feature to 83xx-land. If this is a problem, and you'd like to > apply patches 1 and 2 independently of mpc83xx, please let me know > and I'll back the entire series off the mpc83xx tree. Fwiw, I > build-tested a couple of ARM boards, including davinci. As this relates to ARM files, you need Albert's OK here, not mine. [I put Albert on Cc:] 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's hard to think of you as the end result of millions of years of evolution. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] powerpc/p2041: set sysclk according to status of physical switch SW1
P2041RDB supports 3 sysclk frequencies, it's selected by SW1[6~8], software
need to read the SW1 status to decide what the sysclk needs.
SW1[8~6] : frequency
0 0 1 : 83.3MHz
0 1 0 : 100MHz
others: 66.667MHz
Signed-off-by: Shaohui Xie
---
board/freescale/p2041rdb/cpld.h |3 +++
board/freescale/p2041rdb/p2041rdb.c | 14 ++
include/configs/P2041RDB.h |5 -
3 files changed, 21 insertions(+), 1 deletions(-)
diff --git a/board/freescale/p2041rdb/cpld.h b/board/freescale/p2041rdb/cpld.h
index dcdb410..bece5dd 100644
--- a/board/freescale/p2041rdb/cpld.h
+++ b/board/freescale/p2041rdb/cpld.h
@@ -30,6 +30,7 @@ typedef struct cpld_data {
u8 serdes_mux; /* 0xc - Multiplexed pin Select Register */
u8 sw[1]; /* 0xd - SW2 Status */
u8 system_rst_default; /* 0xe - system reset to default register */
+ u8 sysclk_sw1; /* 0xf - sysclk configuration register */
} __attribute__ ((packed)) cpld_data_t;
#define SERDES_MUX_LANE_6_MASK 0x2
@@ -41,6 +42,8 @@ typedef struct cpld_data {
#define SERDES_MUX_LANE_D_MASK 0x8
#define SERDES_MUX_LANE_D_SHIFT3
#define CPLD_SWITCH_BANK_ENABLE0x40
+#define CPLD_SYSCLK_83 0x1 /* system clock 83.3MHz */
+#define CPLD_SYSCLK_1000x2 /* system clock 100MHz */
/* Pointer to the CPLD register set */
#define cpld ((cpld_data_t *)CPLD_BASE)
diff --git a/board/freescale/p2041rdb/p2041rdb.c
b/board/freescale/p2041rdb/p2041rdb.c
index 52269d3..8685a29 100644
--- a/board/freescale/p2041rdb/p2041rdb.c
+++ b/board/freescale/p2041rdb/p2041rdb.c
@@ -129,6 +129,20 @@ int board_early_init_r(void)
return 0;
}
+unsigned long get_board_sys_clk(unsigned long dummy)
+{
+ u8 sysclk_conf = CPLD_READ(sysclk_sw1);
+
+ switch (sysclk_conf & 0x7) {
+ case CPLD_SYSCLK_83:
+ return 8333;
+ case CPLD_SYSCLK_100:
+ return 1;
+ default:
+ return ;
+ }
+}
+
static const char *serdes_clock_to_string(u32 clock)
{
switch (clock) {
diff --git a/include/configs/P2041RDB.h b/include/configs/P2041RDB.h
index 638dbe7..382f1fc 100644
--- a/include/configs/P2041RDB.h
+++ b/include/configs/P2041RDB.h
@@ -102,7 +102,10 @@
#define CONFIG_ENV_SECT_SIZE0x2 /* 128K (one sector) */
#endif
-#define CONFIG_SYS_CLK_FREQ
+#ifndef __ASSEMBLY__
+unsigned long get_board_sys_clk(unsigned long dummy);
+#endif
+#define CONFIG_SYS_CLK_FREQget_board_sys_clk(0)
/*
* These can be toggled for performance analysis, otherwise use default.
--
1.6.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] powerpc/p2041: update cpld reset command according to CPLD 2.0
CPLD 2.0 provides a new register which bit[0] is set to '1' will reset board
with initializing the CPLD registers to default values. And add bit[6] of
register at offset 0x5 to use to enable flash bank selection .
Signed-off-by: Shaohui Xie
---
board/freescale/p2041rdb/cpld.c | 16 +---
board/freescale/p2041rdb/cpld.h |2 ++
2 files changed, 11 insertions(+), 7 deletions(-)
diff --git a/board/freescale/p2041rdb/cpld.c b/board/freescale/p2041rdb/cpld.c
index 8e1f46e..37b0ed5 100644
--- a/board/freescale/p2041rdb/cpld.c
+++ b/board/freescale/p2041rdb/cpld.c
@@ -53,7 +53,11 @@ void cpld_reset(void) __attribute__((weak,
alias("__cpld_reset")));
*/
void __cpld_set_altbank(void)
{
+ u8 reg5 = CPLD_READ(sw_ctl_on);
+
+ CPLD_WRITE(sw_ctl_on, reg5 | CPLD_SWITCH_BANK_ENABLE);
CPLD_WRITE(fbank_sel, 1);
+ CPLD_WRITE(system_rst, 1);
}
void cpld_set_altbank(void)
__attribute__((weak, alias("__cpld_set_altbank")));
@@ -61,12 +65,12 @@ void cpld_set_altbank(void)
/**
* Set the boot bank to the default bank
*/
-void __cpld_clear_altbank(void)
+void __cpld_set_defbank(void)
{
- CPLD_WRITE(fbank_sel, 0);
+ CPLD_WRITE(system_rst_default, 1);
}
-void cpld_clear_altbank(void)
- __attribute__((weak, alias("__cpld_clear_altbank")));
+void cpld_set_defbank(void)
+ __attribute__((weak, alias("__cpld_set_defbank")));
#ifdef DEBUG
static void cpld_dump_regs(void)
@@ -101,9 +105,7 @@ int cpld_cmd(cmd_tbl_t *cmdtp, int flag, int argc, char *
const argv[])
if (strcmp(argv[2], "altbank") == 0)
cpld_set_altbank();
else
- cpld_clear_altbank();
-
- cpld_reset();
+ cpld_set_defbank();
} else if (strcmp(argv[1], "watchdog") == 0) {
static char *period[8] = {"1ms", "10ms", "30ms", "disable",
"100ms", "1s", "10s", "60s"};
diff --git a/board/freescale/p2041rdb/cpld.h b/board/freescale/p2041rdb/cpld.h
index 3b24cb0..dcdb410 100644
--- a/board/freescale/p2041rdb/cpld.h
+++ b/board/freescale/p2041rdb/cpld.h
@@ -29,6 +29,7 @@ typedef struct cpld_data {
u8 fbank_sel; /* 0xb - Flash bank selection */
u8 serdes_mux; /* 0xc - Multiplexed pin Select Register */
u8 sw[1]; /* 0xd - SW2 Status */
+ u8 system_rst_default; /* 0xe - system reset to default register */
} __attribute__ ((packed)) cpld_data_t;
#define SERDES_MUX_LANE_6_MASK 0x2
@@ -39,6 +40,7 @@ typedef struct cpld_data {
#define SERDES_MUX_LANE_C_SHIFT2
#define SERDES_MUX_LANE_D_MASK 0x8
#define SERDES_MUX_LANE_D_SHIFT3
+#define CPLD_SWITCH_BANK_ENABLE0x40
/* Pointer to the CPLD register set */
#define cpld ((cpld_data_t *)CPLD_BASE)
--
1.6.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 8/8] arm, davinci: add support for am1808 based enbw_cmc board
Hello Igor,
Igor Grinberg wrote:
> Hi Heiko,
>
> On 09/15/11 08:59, Heiko Schocher wrote:
>> - booting from NOR Flash with direct boot method
>> - POST support
>> - LOGBUF support
>>
>> Signed-off-by: Heiko Schocher
>> Cc: Paulraj Sandeep
>> Cc: Albert ARIBAUD
>> ---
>
> [...]
>
>> diff --git a/board/enbw/enbw_cmc/enbw_cmc.c b/board/enbw/enbw_cmc/enbw_cmc.c
>> new file mode 100644
>> index 000..1b9ee67
>> --- /dev/null
>> +++ b/board/enbw/enbw_cmc/enbw_cmc.c
>
> [...]
>
>> +
>> +int board_init(void)
>> +{
>> +#ifndef CONFIG_USE_IRQ
>> +irq_init();
>> +#endif
>> +
>> +/* arch number of the board */
>> +gd->bd->bi_arch_number = 3585;
>
> There is a new standard option for assigning the machid.
> Now, this should be done in the board config file and the above two lines
> removed.
> Please, see the CONFIG_MACH_TYPE in the U-Boot documentation (README file).
Ah, thanks!
> [...]
>
>> diff --git a/include/configs/enbw_cmc.h b/include/configs/enbw_cmc.h
>> new file mode 100644
>> index 000..5de752f
>> --- /dev/null
>> +++ b/include/configs/enbw_cmc.h
>
> [...]
>
>> +/*
>> + * Board
>> + */
>> +#define CONFIG_DRIVER_TI_EMAC
>> +#define CONFIG_USE_NAND
>
> Consider adding here:
> #define MACH_TYPE_ENBW_CMC3585
> #define CONFIG_MACH_TYPE MACH_TYPE_ENBW_CMC
Yep! Change this for v2, thanks!
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 8/8] arm, davinci: add support for am1808 based enbw_cmc board
Hi Heiko,
On 09/15/11 08:59, Heiko Schocher wrote:
> - booting from NOR Flash with direct boot method
> - POST support
> - LOGBUF support
>
> Signed-off-by: Heiko Schocher
> Cc: Paulraj Sandeep
> Cc: Albert ARIBAUD
> ---
[...]
> diff --git a/board/enbw/enbw_cmc/enbw_cmc.c b/board/enbw/enbw_cmc/enbw_cmc.c
> new file mode 100644
> index 000..1b9ee67
> --- /dev/null
> +++ b/board/enbw/enbw_cmc/enbw_cmc.c
[...]
> +
> +int board_init(void)
> +{
> +#ifndef CONFIG_USE_IRQ
> + irq_init();
> +#endif
> +
> + /* arch number of the board */
> + gd->bd->bi_arch_number = 3585;
There is a new standard option for assigning the machid.
Now, this should be done in the board config file and the above two lines
removed.
Please, see the CONFIG_MACH_TYPE in the U-Boot documentation (README file).
[...]
> diff --git a/include/configs/enbw_cmc.h b/include/configs/enbw_cmc.h
> new file mode 100644
> index 000..5de752f
> --- /dev/null
> +++ b/include/configs/enbw_cmc.h
[...]
> +/*
> + * Board
> + */
> +#define CONFIG_DRIVER_TI_EMAC
> +#define CONFIG_USE_NAND
Consider adding here:
#define MACH_TYPE_ENBW_CMC 3585
#define CONFIG_MACH_TYPEMACH_TYPE_ENBW_CMC
[...]
--
Regards,
Igor.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
