[U-Boot] [PATCH v3] arm: Kirkwood: add SYSRSTn Duration Counter Support
This feature can be used to trigger special command "sysrstcmd" using
reset key long press event and environment variable "sysrstdelay" is set
(useful for reset to factory or manufacturing mode execution)
Kirkwood SoC implements a hardware-based SYSRSTn duration counter.
When SYSRSTn is asserted low, a SYSRSTn duration counter is running.
The counter value is stored in the SYSRSTn Length Counter Register
The counter is based on the 25-MHz reference clock (40ns)
It is a 29-bit counter, yielding a maximum counting duration of
2^29/25 MHz (21.4 seconds). When the counter reach its maximum value,
it remains at this value until counter reset is triggered by setting
bit 31 of KW_REG_SYSRST_CNT
Implementation:
Upon long reset assertion (> ${sysrstdelay} in secs) sysrstcmd will be
executed if pre-defined in environment variables.
This feature will be disabled if "sysrstdelay" variable is unset.
for-ex.
setenv sysrst_cmd "echo starting factory reset;
nand erase 0xa 0x2;
echo finish ed sysrst command;"
will erase particular nand sector if triggered by this event
Signed-off-by: Prafulla Wadaskar
---
Change log:
v2: updated as per review feedback for v1
bug fix in the previous post (V2) fixed
v2 repost:
I am sorry for previous post v2, pls ignore it, this is the right patch for the
same
v3: updated as per review feedback for v2
all possible messages termed as debug
cpu/arm926ejs/kirkwood/cpu.c| 75 +++
include/asm-arm/arch-kirkwood/cpu.h |2 +
2 files changed, 77 insertions(+), 0 deletions(-)
diff --git a/cpu/arm926ejs/kirkwood/cpu.c b/cpu/arm926ejs/kirkwood/cpu.c
index 795a739..3b978e2 100644
--- a/cpu/arm926ejs/kirkwood/cpu.c
+++ b/cpu/arm926ejs/kirkwood/cpu.c
@@ -195,6 +195,78 @@ int kw_config_mpp(u32 mpp0_7, u32 mpp8_15, u32 mpp16_23,
u32 mpp24_31,
return 0;
}
+/*
+ * SYSRSTn Duration Counter Support
+ *
+ * Kirkwood SoC implements a hardware-based SYSRSTn duration counter.
+ * When SYSRSTn is asserted low, a SYSRSTn duration counter is running.
+ * The SYSRSTn duration counter is useful for implementing a manufacturer
+ * or factory reset. Upon a long reset assertion that is greater than a
+ * pre-configured environment variable value for sysrstdelay,
+ * The counter value is stored in the SYSRSTn Length Counter Register
+ * The counter is based on the 25-MHz reference clock (40ns)
+ * It is a 29-bit counter, yielding a maximum counting duration of
+ * 2^29/25 MHz (21.4 seconds). When the counter reach its maximum value,
+ * it remains at this value until counter reset is triggered by setting
+ * bit 31 of KW_REG_SYSRST_CNT
+ */
+static void kw_sysrst_action(void)
+{
+ int ret;
+ char *s = getenv("sysrstcmd");
+
+ if (!s) {
+ debug("Error.. %s failed, check sysrstcmd\n",
+ __FUNCTION__);
+ return;
+ }
+
+ debug("Starting %s process...\n", __FUNCTION__);
+#if !defined(CONFIG_SYS_HUSH_PARSER)
+ ret = run_command (s, 0);
+#else
+ ret = parse_string_outer(s, FLAG_PARSE_SEMICOLON
+ | FLAG_EXIT_FROM_LOOP);
+#endif
+ if (ret < 0)
+ debug("Error.. %s failed\n", __FUNCTION__);
+ else
+ debug("%s process finished\n", __FUNCTION__);
+}
+
+static void kw_sysrst_check(void)
+{
+ u32 sysrst_cnt, sysrst_dly;
+ char *s;
+
+ /*
+* no action if sysrstdelay environment variable is not defined
+*/
+ s = getenv("sysrstdelay");
+ if (s == NULL)
+ return;
+
+ /* read sysrstdelay value */
+ sysrst_dly = (u32) simple_strtoul(s, NULL, 10);
+
+ /* read SysRst Length counter register (bits 28:0) */
+ sysrst_cnt = (0x1fff & readl(KW_REG_SYSRST_CNT));
+ debug("H/w Rst hold time: %d.%d secs\n",
+ sysrst_cnt / SYSRST_CNT_1SEC_VAL,
+ sysrst_cnt % SYSRST_CNT_1SEC_VAL);
+
+ /* clear the counter for next valid read*/
+ writel(1 << 31, KW_REG_SYSRST_CNT);
+
+ /*
+* sysrst_action:
+* if H/w Reset key is pressed and hold for time
+* more than sysrst_dly in seconds
+*/
+ if (sysrst_cnt >= SYSRST_CNT_1SEC_VAL * sysrst_dly)
+ kw_sysrst_action();
+}
+
#if defined(CONFIG_DISPLAY_CPUINFO)
int print_cpuinfo(void)
{
@@ -298,6 +370,9 @@ int arch_misc_init(void)
temp = get_cr();
set_cr(temp & ~CR_V);
+ /* checks and execute resset to factory event */
+ kw_sysrst_check();
+
return 0;
}
#endif /* CONFIG_ARCH_MISC_INIT */
diff --git a/include/asm-arm/arch-kirkwood/cpu.h
b/include/asm-arm/arch-kirkwood/cpu.h
index d1440af..b3022a3 100644
--- a/include/asm-arm/arch-kirkwood/cpu.h
+++ b/include/asm-arm/arch-kirkwood/cpu.h
@@ -36,6 +36,8 @@
((_x ? KW_EGIGA0_BASE : KW_EGIGA1_BASE) + 0x44c)
#define KW_REG_DEVICE_ID (KW_MPP_BASE + 0x
Re: [U-Boot] [PATCH v2][repost] arm: Kirkwood: add SYSRSTn Duration Counter Support
> -Original Message-
> From: Wolfgang Denk [mailto:w...@denx.de]
> Sent: Thursday, August 20, 2009 3:08 PM
> To: Prafulla Wadaskar
> Cc: u-boot@lists.denx.de; Ashish Karkare; Prabhanjan Sarnaik;
> Ronen Shitrit
> Subject: Re: [U-Boot] [PATCH v2][repost] arm: Kirkwood: add
> SYSRSTn Duration Counter Support
>
> Dear Prafulla Wadaskar,
>
> In message
> <73173d32e9439e4abb5151606c3e19e202e3915...@sc-vexch1.marvell.
> com> you wrote:
> >
> > > > + if (!s) {
> > > > + printf("Error.. %s failed, check sysrstcmd\n",
> > > > + __FUNCTION__);
> > > > + return;
> > >
> > > Why is this considered an error? I think it is perfectly
> legal to not
> > > define this environment variable. For example, it is also
> no error to
> > > set "bootdelay" and not define "bootcmd". I think we
> should implement
> > > consistent behaviour.
> > It is similar with one difference- sysrstcmd is
> additionally gated with h/w trigger,
>
> Um... yes... agreed, but that's not actually so special. Consider for
> example the use of "altbootcmd" in connection with the boot
> count limit
> feature, or the "failbootcmd" which gets run in case of critical POST
> errors. None of these produce any such error messages. For consistency
> I recommend to remove this message here, too.
>
> > Secondly it is not as known as bootcmd, so it is always
> better to throw some error message.
> > This save some of developer's time and email exchanges :-)
>
> Well, for developers it may be useful during test - but it should not
> be present for regular users of the production version. Maybe you
> change it into a debug() ?
Agreed I will do this.
>
> ...
> > > > + sysrst_cnt = (0x1fff & readl(KW_REG_SYSRST_CNT));
> > > > + printf("H/w Rst hold time: %d.%d secs\n",
> > > > + sysrst_cnt / SYSRST_CNT_1SEC_VAL,
> > > > + sysrst_cnt % SYSRST_CNT_1SEC_VAL);
> > >
> > > This should be debvug(), too ?
> > Does it harm if we keep this info?
>
> Well, yes, it does. It adds output, which makes the boot process more
> noisy and addds to the boot time. And normally none of the end users
> will actually ever look at this information.
That's understood but only in case sysrstdelay is defined which is not default
case :-)
>
> > It is just like "cpu name, speed etc".
>
> Well, this _is_ information which the end users regularly check and
> pay attention to.
>
> > SysRST is a feature provided by h/w that we are supporting,
> > It may help users who are willing to use this feature
> > Any way it is gated by "sysrstdelay"
> > So I think we must keep this print alive
>
> Really? What is the advantage for the enduser to know if he pressed
> the button for 5.1 or 5.3 seconds?
No, I mean it is useful in case of 4.9 or 5.1 :-)
>
> Please make it a debug().
Should I? even though by default it will not show up :-)
Regards..
Prafulla . .
>
> 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
> "...this does not mean that some of us should not want, in a rather
> dispassionate sort of way, to put a bullet through csh's head."
>- Larry Wall in <1992aug6.221512.5...@netlabs.com>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] 83xx and LCRR setting
Hello Kim, Kim Phillips schrieb: > On Tue, 18 Aug 2009 15:23:47 +0200 > Heiko Schocher wrote: > >> Hello Kim, > > Hello Heiko, sorry for the late reply, > >> I actually work on an u-boot mpc8321 port (mostly identical with the kmeter1 >> port already in mainline), and I have to set the LCRR (Clock Ratio Register >> Reference Manual 10.3.1.14). As I see in >> >> cpu/mpc83xx/cpu_init.c cpu_init_f() >> >> this is done while running from flash. Hmm... the Reference manual >> says in chapter 10.3.1.14 page 474: >> >> NOTE >> For proper operation of the system, this register setting must not be altered >> while local bus memories or devices are being accessed. Special care needs >> to be taken when running instructions from an local bus controller memory. >> >> Hmm... >> >> On my board (and for example on the MPC832XEMDS) the flash is connected >> to the localbus ... and this register setting is done, while >> running from flash ... Hmm.. is this safe? > > yeah, I'm not quite sure how that works myself! I stumbled over this, just because I didn;t set this LCRR_DBYP bit, which the CPU sets after a reset, so what Do you think about this patch? 832x, LCRR: change only the valid bits for this register Signed-off-by: Heiko Schocher --- cpu/mpc83xx/cpu_init.c|6 ++ include/asm-ppc/fsl_lbc.h |4 2 files changed, 10 insertions(+), 0 deletions(-) diff --git a/cpu/mpc83xx/cpu_init.c b/cpu/mpc83xx/cpu_init.c index ea4f2af..b5f64a8 100644 --- a/cpu/mpc83xx/cpu_init.c +++ b/cpu/mpc83xx/cpu_init.c @@ -193,8 +193,14 @@ void cpu_init_f (volatile immap_t * im) */ im->reset.rmr = (RMR_CSRE & (1lbus.lcrr & LCRR_MASK) | \ + (CONFIG_SYS_LCRR & ~LCRR_MASK); +#else /* LCRR - Clock Ratio Register (10.3.1.16) */ im->lbus.lcrr = CONFIG_SYS_LCRR; +#endif /* Enable Time Base & Decrimenter ( so we will have udelay() )*/ im->sysconf.spcr |= SPCR_TBEN; diff --git a/include/asm-ppc/fsl_lbc.h b/include/asm-ppc/fsl_lbc.h index a28082e..2c7a94b 100644 --- a/include/asm-ppc/fsl_lbc.h +++ b/include/asm-ppc/fsl_lbc.h @@ -315,6 +315,10 @@ #define LCRR_CLKDIV_4 0x0004 #define LCRR_CLKDIV_8 0x0008 +#if defined(CONFIG_MPC832x) +#define LCRR_MASK 0xFFFCFFF0 +#endif + /* LTEDR - Transfer Error Check Disable Register */ #define LTEDR_BMD 0x8000 /* Bus monitor disable */ -- 1.6.0.6 -- 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 1/1 v2][Net] Convert CS8900 Ethernet driver to CONFIG_NET_MULTI API
Dear Ben Warren,
In message you
wrote:
>
> I looked at a disassembly of this code and it looked like it should work.
> In this case, the base offset of the device is in r2 (0x07000300) and the
> code does store operations on this +#4 and +#6, which were the offsets in
> the original. I guess it would be useful to printf something like:
>
> printf("addr = %#08x\n", &priv->regs->txcmd) just to make sure it's
> 0x07000304.
>
> Other than that, I'm stumped. I'll review the code again to see if anything
> jumps out.
Hm... adding this patch:
diff --git a/drivers/net/cs8900.c b/drivers/net/cs8900.c
index 5b9c4cb..0f86c39 100644
--- a/drivers/net/cs8900.c
+++ b/drivers/net/cs8900.c
@@ -215,6 +215,11 @@ static int cs8900_send(struct eth_device *dev,
struct cs8900_priv *priv = (struct cs8900_priv *)(dev->priv);
retry:
+ printf("priv=%#08x regs=%#08x txcmd=%#08x\n",
+ (unsigned int)priv,
+ (unsigned int)(priv->regs),
+ (unsigned int)(&priv->regs->txcmd));
+
/* initiate a transmit sequence */
writel(PP_TxCmd_TxStart_Full, &priv->regs->txcmd);
writel(length, &priv->regs->txlen);
And testing on the mx31ads board I get this:
=> run load
Using CS8900-0 device
TFTP from server 192.168.1.1; our IP address is 192.168.20.9
Filename 'mx31ads/u-boot.bin'.
Load address: 0x8080
Loading: priv=0x87ed8100 regs=0xb4020300 txcmd=0xb4020304
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
On the subject of C program indentation: "In My Egotistical Opinion,
most people's C programs should be indented six feet downward and
covered with dirt." - Blair P. Houghton
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH "mkimage" branch] tools/mkimage: fix compiler warnings, use "const"
> -Original Message- > From: Wolfgang Denk [mailto:w...@denx.de] > Sent: Thursday, August 20, 2009 2:58 PM > To: Prafulla Wadaskar > Cc: u-boot@lists.denx.de > Subject: Re: [U-Boot] [PATCH "mkimage" branch] tools/mkimage: > fix compiler warnings, use "const" > > Dear Prafulla, > > In message > <73173d32e9439e4abb5151606c3e19e202e3915...@sc-vexch1.marvell. > com> you wrote: > > > > > This fixes some compiler warnings: > > > tools/default_image.c:141: warning: initialization from > > > incompatible pointer type > > > tools/fit_image.c:202: warning: initialization from > > > incompatible pointer type > > > and changes to code to use "const" attributes in a few > places where > > > it's appropriate. > > > > 99% of the changes in this patch is to add const attributes. > > Yes, indeed. > > > Can you pls explain here- how useful it is to add const. > > Well, adding "const" where appropriate is definitely a good thing, as > it const augments data-hiding and encapsulation and allows the > compiler to check for (and prevent!) unintended modification of data > structures, i. e. for programming errors. Also, it helps the compiler > for better optimization. Ack > > > Or do it make more sense just to fix the warnings in > respective functions? > > I have posted a patch for the same > > I did not see any patch form you addressing these warnings? It's in my mailq :-(, I will repost it just FYI Regards.. Prafulla . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Porting to Broadcom BCM7038 (Hermes board)
> > All the tasks you mention here are performed by U-Boot. U-Boot _is_ > the boot loader. Right, I'm just having trouble getting to grips with the code flow, the start.S in the CPU is the initial entry point, at what point does that hand over to U-Boot? Any chance you could give me a brief overview of the code flow? In particular where the code I need to write fits in with the boot process, i.e. where I need to interface with U-Boot. Once I've got a better idea of how U-Boot boots, I should be able to get started at least. -- Regards, Peter Belm ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2][repost] arm: Kirkwood: add SYSRSTn Duration Counter Support
> -Original Message- > From: Jean-Christophe PLAGNIOL-VILLARD [mailto:plagn...@jcrosoft.com] > Sent: Thursday, August 20, 2009 10:50 AM > To: Prafulla Wadaskar > Cc: u-boot@lists.denx.de; Ashish Karkare; Prabhanjan Sarnaik; > Ronen Shitrit > Subject: Re: [U-Boot] [PATCH v2][repost] arm: Kirkwood: add > SYSRSTn Duration Counter Support > > > > > Signed-off-by: Prafulla Wadaskar > > > > --- > > > > Change log: > > > > v2: updated as per review feedback for v1 > > > > bug fix in the previous post (V2) fixed > > > ok > > > > > > but I think make optionnal will be better > > Hi Jean > > Thanks.. > > I didn't understod what you want to say here, can you pls explain? > the patch is fine for I but I think we may create a CONFIG_ somethink > to enable it only if the use want it and do not impact the U-Boot size > otherwise Okay I got it WE can do this but, There are just two APIs, overall size impact is not much (<100 bytes max). And this is very useful feature. So can we make it by default enabled? Regards... Prafulla .. > > Best Regards, > J. > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Porting to Broadcom BCM7038 (Hermes board)
Dear Peter Belm, In message <574bb010908200229m7da12930s39f7bc40a2384...@mail.gmail.com> you wrote: > > > That's not quite correct. IIRC, the "purple" board also uses a 64bit > > MIPS processor (5Kc). So it's "just" anothe rnew board port. > > The core in the BCM7038 is a 5Kf, I'm not sure how the minor revision > effects something like UBoot, would any registers be different? As for it Well, _all_ hardware differences affect U-Boot. You will need a really detailed understanding of the processor and your board. > being 64bit, the current bootloader is being compiled with a 32bit version > of mipsel-uclibc-gcc, so it runs 32bit code fine. Would this be easier, or Right. That's what we do in case of the "purple" board, too. > does the fact it's a 64bit processor mean there's other changes which need > to be taken into account in UBoot? This obviously depends on your hardware design. We cannot answer this question. > Ok I think I get it now, in the cpu directory goes the code specific for > bringing up the cpu, using the cache, etc. So the board directory would > contain code for accessing the flash, init'ing memory, etc. And drivers > would go into drivers/ as you said. Assuming you use standard flash chips, no code to access the flash should co to the board directory. You should use the existing standard drivers instead. > There's one fundamental thing I still need to get sorted in my head, what > exactly is the role of UBoot? Is it just there to assist in creating a > bootloader? So the cpu code would do the main bringup, board specific code U-Boot _is_ the boot loader. > would init the memory then use drivers provided by UBoot to access what it > needs to load the kernel, then calls code in UBoot to start it? Or does > UBoot perform a more invasive role than that? All the tasks you mention here are performed by U-Boot. U-Boot _is_ the boot loader. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Microsoft Multitasking: several applications can crash at the same time. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3]: arm:kirkwood Define kirkwood phy address magic number
> -Original Message- > From: u-boot-boun...@lists.denx.de > [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Simon Kagstrom > Sent: Thursday, August 20, 2009 1:42 PM > Cc: U-Boot ML > Subject: [U-Boot] [PATCH 1/3]: arm:kirkwood Define kirkwood > phy address magic number > > Signed-off-by: Simon Kagstrom > --- > drivers/net/kirkwood_egiga.c | 14 ++ > 1 files changed, 10 insertions(+), 4 deletions(-) > > diff --git a/drivers/net/kirkwood_egiga.c > b/drivers/net/kirkwood_egiga.c > index f31fefc..065e335 100644 > --- a/drivers/net/kirkwood_egiga.c > +++ b/drivers/net/kirkwood_egiga.c > @@ -38,6 +38,8 @@ > #include > #include "kirkwood_egiga.h" > > +#define KIRKWOOD_PHY_ADR_REQUEST 0xee define this in header file Basically this is needed in drivers/net/phy/mv88e61xx.c for multi chip support in this case we need to define this in include/miiphy.h. which conflicts with other phy address definition, that's why not done earlier It makes more sense to add APIs miiphy_read/write_phyadr to miiutils Regards.. Prafulla . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2][repost] arm: Kirkwood: add SYSRSTn Duration Counter Support
Dear Prafulla Wadaskar,
In message <73173d32e9439e4abb5151606c3e19e202e3915...@sc-vexch1.marvell.com>
you wrote:
>
> > > + if (!s) {
> > > + printf("Error.. %s failed, check sysrstcmd\n",
> > > + __FUNCTION__);
> > > + return;
> >
> > Why is this considered an error? I think it is perfectly legal to not
> > define this environment variable. For example, it is also no error to
> > set "bootdelay" and not define "bootcmd". I think we should implement
> > consistent behaviour.
> It is similar with one difference- sysrstcmd is additionally gated with h/w
> trigger,
Um... yes... agreed, but that's not actually so special. Consider for
example the use of "altbootcmd" in connection with the boot count limit
feature, or the "failbootcmd" which gets run in case of critical POST
errors. None of these produce any such error messages. For consistency
I recommend to remove this message here, too.
> Secondly it is not as known as bootcmd, so it is always better to throw some
> error message.
> This save some of developer's time and email exchanges :-)
Well, for developers it may be useful during test - but it should not
be present for regular users of the production version. Maybe you
change it into a debug() ?
...
> > > + sysrst_cnt = (0x1fff & readl(KW_REG_SYSRST_CNT));
> > > + printf("H/w Rst hold time: %d.%d secs\n",
> > > + sysrst_cnt / SYSRST_CNT_1SEC_VAL,
> > > + sysrst_cnt % SYSRST_CNT_1SEC_VAL);
> >
> > This should be debvug(), too ?
> Does it harm if we keep this info?
Well, yes, it does. It adds output, which makes the boot process more
noisy and addds to the boot time. And normally none of the end users
will actually ever look at this information.
> It is just like "cpu name, speed etc".
Well, this _is_ information which the end users regularly check and
pay attention to.
> SysRST is a feature provided by h/w that we are supporting,
> It may help users who are willing to use this feature
> Any way it is gated by "sysrstdelay"
> So I think we must keep this print alive
Really? What is the advantage for the enduser to know if he pressed
the button for 5.1 or 5.3 seconds?
Please make it a debug().
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
"...this does not mean that some of us should not want, in a rather
dispassionate sort of way, to put a bullet through csh's head."
- Larry Wall in <1992aug6.221512.5...@netlabs.com>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Porting to Broadcom BCM7038 (Hermes board)
> > > Not quite. A quick check reveals that the bcm7038 is a r5000 based > > mips64 bit at heart (I'm a little confused here, there seem to be also > > 32bit r5000?). So not only will you be doing a new cpu port (level 2), > > but really a new architecture , i.e. mips64 - so you enter the game at > > level 3 ;) > > That's not quite correct. IIRC, the "purple" board also uses a 64bit > MIPS processor (5Kc). So it's "just" anothe rnew board port. > The core in the BCM7038 is a 5Kf, I'm not sure how the minor revision effects something like UBoot, would any registers be different? As for it being 64bit, the current bootloader is being compiled with a 32bit version of mipsel-uclibc-gcc, so it runs 32bit code fine. Would this be easier, or does the fact it's a 64bit processor mean there's other changes which need to be taken into account in UBoot? And of course there is a number of companies who are specialized in > performing such ports, um... I'd prefer to perform this port myself (if possible!) it's no fun being a hobbiest when you get someone else to do all your work. SATA drivers will go below drivers/block, but yes, this is the theory. Ok I think I get it now, in the cpu directory goes the code specific for bringing up the cpu, using the cache, etc. So the board directory would contain code for accessing the flash, init'ing memory, etc. And drivers would go into drivers/ as you said. There's one fundamental thing I still need to get sorted in my head, what exactly is the role of UBoot? Is it just there to assist in creating a bootloader? So the cpu code would do the main bringup, board specific code would init the memory then use drivers provided by UBoot to access what it needs to load the kernel, then calls code in UBoot to start it? Or does UBoot perform a more invasive role than that? Thank you for your help so far. -- Regards, Peter Belm ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH "mkimage" branch] tools/mkimage: fix compiler warnings, use "const"
Dear Prafulla, In message <73173d32e9439e4abb5151606c3e19e202e3915...@sc-vexch1.marvell.com> you wrote: > > > This fixes some compiler warnings: > > tools/default_image.c:141: warning: initialization from > > incompatible pointer type > > tools/fit_image.c:202: warning: initialization from > > incompatible pointer type > > and changes to code to use "const" attributes in a few places where > > it's appropriate. > > 99% of the changes in this patch is to add const attributes. Yes, indeed. > Can you pls explain here- how useful it is to add const. Well, adding "const" where appropriate is definitely a good thing, as it const augments data-hiding and encapsulation and allows the compiler to check for (and prevent!) unintended modification of data structures, i. e. for programming errors. Also, it helps the compiler for better optimization. > Or do it make more sense just to fix the warnings in respective functions? > I have posted a patch for the same I did not see any patch form you addressing these warnings? My "const"-adding patch was the more or less direct result of getting rid of the warnings without using additional type casts. I think using const is a good thing. I am aware that it sometimes becomes painful, and some consider it a waste of time. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de God made machine language; all the rest is the work of man. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] [repost]: arm: kirkwood: See to it that sent data is 8-byte aligned
> -Original Message-
> From: u-boot-boun...@lists.denx.de
> [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Simon Kagstrom
> Sent: Thursday, August 20, 2009 1:44 PM
> To: U-Boot ML
> Subject: [U-Boot] [PATCH 3/3] [repost]: arm: kirkwood: See to
> it that sent data is 8-byte aligned
>
> U-boot might use non-8-byte-aligned addresses for sending data, which
> the kwgbe_send doesn't accept (bootp does this for me). This patch
> copies the data to be sent to a malloced temporary buffer if it is
> non-aligned.
> diff --git a/drivers/net/kirkwood_egiga.h
> b/drivers/net/kirkwood_egiga.h
> index 9c893d1..16d5214 100644
> --- a/drivers/net/kirkwood_egiga.h
> +++ b/drivers/net/kirkwood_egiga.h
> @@ -499,6 +499,7 @@ struct kwgbe_device {
> struct kwgbe_rxdesc *p_rxdesc;
> struct kwgbe_rxdesc *p_rxdesc_curr;
> u8 *p_rxbuf;
> + u8 *p_aligned_txbuf;
> };
>
> #endif /* __EGIGA_H__ */
> --
> 1.6.0.4
>
Ack,
Technically this patch is okay,
Unless we all agree this to be done in low level drivers :-)
Regards..
Prafulla . .
> ___
> 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 1/3] mpc83xx: tqm8349 - remove pci & flash window conflict
Dear Kim Phillips, In message <20090819200321.a0900c41.kim.phill...@freescale.com> you wrote: > commit 9993e196da707a0a1cd4584f1fcef12382c1c144 "mpc83xx: convert all > remaining boards over to 83XX_GENERIC_PCI" remapped pci windows on > tqm834x to make it more consistent with the other 83xx boards. During > that time however, the author failed to realize that FLASH_BASE was > occupying the same range as what PCI1_MEM_BASE was being assigned. > > Signed-off-by: Kim Phillips > --- > WD, if you have time, please test - I don't have a tqm834x board. TIA. > > include/configs/TQM834x.h |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) Tested-by: Wolfgang Denk I can verify that the original problem (non working flash support) gets fixed by this patch: without the patch: U-Boot 2009.06-00513-g982adfc (Jul 24 2009 - 15:42:41) MPC83XX Reset Status: External/Internal Soft, External/Internal Hard CPU: e300c1, MPC8349E, Rev: 1.1 at 533.328 MHz, CSB: 266.664 MHz Board: TQM834x PCI1: 32 bit, 33 MHz I2C: ready DRAM: 256 MB FLASH: ## Unknown FLASH on Bank 1 - Size = 0x0200 = 0 MB 32 MB PCI: Bus Dev VenId DevId Class Int 00 0b 104c ac55 0607 ff 00 0b 104c ac55 0607 ff DTT: 1 is 27 C Net: TSEC0, TSEC1 ... with the patch: U-Boot 2009.08-rc2-00026-g5c023da (Aug 20 2009 - 10:41:53) MPC83XX Reset Status: External/Internal Soft, External/Internal Hard CPU: e300c1, MPC8349E, Rev: 1.1 at 533.328 MHz, CSB: 266.664 MHz Board: TQM834x PCI1: 32 bit, 33 MHz I2C: ready DRAM: 256 MB FLASH: 32 MB PCI: Bus Dev VenId DevId Class Int 00 0b 104c ac55 0607 ff 00 0b 104c ac55 0607 ff DTT: 1 is 34 C Net: TSEC0, TSEC1 ... But I have a question (unrelated to this patch): With recent versions of U-Boot I see unstable network behaviour: => run load TSEC0: No link. TSEC1: No link. => run load Speed: 1000, full duplex Using TSEC0 device TFTP from server 192.168.1.1; our IP address is 192.168.205.1 Filename 'tqm834x/u-boot.bin'. Load address: 0x20 Loading: ##Got error 4 done Bytes transferred = 253376 (3ddc0 hex) => run load Speed: 1000, full duplex Using TSEC0 device TFTP from server 192.168.1.1; our IP address is 192.168.205.1 Filename 'tqm834x/u-boot.bin'. Load address: 0x20 Loading: #Got error 4 #Got error 4 Got error 4 T T done Bytes transferred = 253376 (3ddc0 hex) => run load Speed: 1000, full duplex Using TSEC0 device TFTP from server 192.168.1.1; our IP address is 192.168.205.1 Filename 'tqm834x/u-boot.bin'. Load address: 0x20 Loading: ###Got error 4 #Got error 4 Got error 4 Got error 4 #Got error 4 # done Bytes transferred = 253376 (3ddc0 hex) Do you have any idea what might go wrong here? [Sorry, I didn't find time yet to try bisecting this, but maybe this rings a bell to you?] 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 EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2][repost] arm: Kirkwood: add SYSRSTn Duration Counter Support
> -Original Message-
> From: Wolfgang Denk [mailto:w...@denx.de]
> Sent: Wednesday, August 19, 2009 12:50 PM
> To: Prafulla Wadaskar
> Cc: u-boot@lists.denx.de; Ashish Karkare; Prabhanjan Sarnaik;
> Ronen Shitrit
> Subject: Re: [U-Boot] [PATCH v2][repost] arm: Kirkwood: add
> SYSRSTn Duration Counter Support
>
> Dear Prafulla Wadaskar,
>
> In message
> <1250679240-17557-1-git-send-email-prafu...@marvell.com> you wrote:
> > I am sorry for previous post v2, pls ignore it, this is the
> right patch for the same
>
> This comment does not belong to the commit message. Please move below
> the "---" line.
Okay I will add this in my next post
>
> > This feature can be used to trigger special command
> "sysrstcmd" using
> > reset key long press event and environment variable
> "sysrstdelay" is set
> > (useful for reset to factory or manufacturing mode execution)
> >
> > Kirkwood SoC implements a hardware-based SYSRSTn duration counter.
> > When SYSRSTn is asserted low, a SYSRSTn duration counter is running.
> > The counter value is stored in the SYSRSTn Length Counter Register
> > The counter is based on the 25-MHz reference clock (40ns)
> > It is a 29-bit counter, yielding a maximum counting duration of
> > 2^29/25 MHz (21.4 seconds). When the counter reach its
> maximum value,
> > it remains at this value until counter reset is triggered by setting
> > bit 31 of KW_REG_SYSRST_CNT
> >
> > Implementation:
> > Upon long reset assertion (> ${sysrstdleay} in secs)
> sysrstcmd will be
>
> That's a typo, it's "sysrstdelay", right? Please fix while we are at
> it.
Thanks.. I will take care
>
> > +static void kw_sysrst_action(void)
> > +{
> > + int ret;
> > + char *s = getenv("sysrstcmd");
> > +
> > + if (!s) {
> > + printf("Error.. %s failed, check sysrstcmd\n",
> > + __FUNCTION__);
> > + return;
>
> Why is this considered an error? I think it is perfectly legal to not
> define this environment variable. For example, it is also no error to
> set "bootdelay" and not define "bootcmd". I think we should implement
> consistent behaviour.
It is similar with one difference- sysrstcmd is additionally gated with h/w
trigger,
Secondly it is not as known as bootcmd, so it is always better to throw some
error message.
This save some of developer's time and email exchanges :-)
>
> > + }
> > +
> > + printf("Starting %s process...\n", __FUNCTION__);
>
> This should be a debug(), I think. Don't produce too much output.
>
> > + if (ret < 0)
> > + printf("Error.. %s failed\n", __FUNCTION__);
> > + else
> > + printf("%s process finished\n", __FUNCTION__);
>
> Ditto - please turn into debug().
Okay no issues..I will do it
>
> > +
> > +static void kw_sysrst_check(void)
> > +{
> > + u32 sysrst_cnt, sysrst_dly;
> > + char *s;
> > +
> > + /*
> > +* no action if sysrstdelay environment variable is not defined
> > +*/
> > + s = getenv("sysrstdelay");
> > + if (s == NULL)
> > + return;
> > +
> > + /* read sysrstdelay value */
> > + sysrst_dly = (u32) simple_strtoul(s, NULL, 10);
> > +
> > + /* read SysRst Length counter register (bits 28:0) */
> > + sysrst_cnt = (0x1fff & readl(KW_REG_SYSRST_CNT));
> > + printf("H/w Rst hold time: %d.%d secs\n",
> > + sysrst_cnt / SYSRST_CNT_1SEC_VAL,
> > + sysrst_cnt % SYSRST_CNT_1SEC_VAL);
>
> This should be debvug(), too ?
Does it harm if we keep this info?
It is just like "cpu name, speed etc".
SysRST is a feature provided by h/w that we are supporting,
It may help users who are willing to use this feature
Any way it is gated by "sysrstdelay"
So I think we must keep this print alive
Regards..
Prafulla . .
>
>
> 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 a person (a) is poorly, (b) receives treatment intended to make
> him better, and (c) gets better, then no power of reasoning known to
> medical science can convince him that it may not have been the
> treatment that restored his health.
> - Sir Peter Medawar, The Art of the Soluble
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Adding support for DevKit8000
On Thu, Aug 20, 2009 at 12:19 AM, Jean-Christophe
PLAGNIOL-VILLARD wrote:
>> board/omap3/devkit8000/Makefile | 52 +
>> board/omap3/devkit8000/config.mk| 35
>> board/omap3/devkit8000/devkit8000.c | 124
>> board/omap3/devkit8000/devkit8000.h | 373
>> +++
> no need board are allow in board/omap3
> please create your own vendor dirent or just put it in board/
What do you mean with that?
On Thu, Aug 20, 2009 at 7:18 AM, Jean-Christophe
PLAGNIOL-VILLARD wrote:
>> >> +void reset_phy(void)
>> >> +{
>> >> + eth_init(gd->bd);
>> >> +}
>> > NACK
>> > the net need to be init only when you use it
>>
>> The kernel will try to use the already (temporally) programmed MAC address.
>> I always init it because that way no kernel hack for the MAC address
>> is required.
>> Is it ok if I add a comment?
> no sorry
> this will be also nack by Wolfgang
> to program the mac you need to create a initramfs in your kernel wich generate
> the same thing or read the content of the U-Boot env via fw_printenv
> and use ifconfig hw ether
ok, I think this will break nfsroot.
I don't think it's possible to init ethernet with a initramfs before
mounting the rootfs.
There are several boards doing the same because of nfsroot:
board/ronetix/pm9261/pm9261.c
board/ronetix/pm9263/pm9263.c
board/afeb9260/afeb9260.c
board/atmel/at91cap9adk/at91cap9adk.c
board/atmel/at91sam9260ek/at91sam9260ek.c
board/atmel/at91sam9261ek/at91sam9261ek.c
board/atmel/at91sam9263ek/at91sam9263ek.c
board/atmel/at91sam9m10g45ek/at91sam9m10g45ek.c
Is there any command to call eth_init() in a script?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 4/4]: Define test_and_set_bit and test_and_clear bit for ARM
Needed for (e.g.) ubifs support to work.
Signed-off-by: Simon Kagstrom
---
include/asm-arm/bitops.h | 27 ---
1 files changed, 24 insertions(+), 3 deletions(-)
diff --git a/include/asm-arm/bitops.h b/include/asm-arm/bitops.h
index b3a9578..b62ff90 100644
--- a/include/asm-arm/bitops.h
+++ b/include/asm-arm/bitops.h
@@ -18,6 +18,7 @@
#ifdef __KERNEL__
#include
+#include
#define smp_mb__before_clear_bit() do { } while (0)
#define smp_mb__after_clear_bit() do { } while (0)
@@ -55,8 +56,6 @@ static inline void __change_bit(int nr, volatile void *addr)
*p ^= mask;
}
-extern int test_and_set_bit(int nr, volatile void * addr);
-
static inline int __test_and_set_bit(int nr, volatile void *addr)
{
unsigned long mask = BIT_MASK(nr);
@@ -67,7 +66,17 @@ static inline int __test_and_set_bit(int nr, volatile void
*addr)
return (old & mask) != 0;
}
-extern int test_and_clear_bit(int nr, volatile void * addr);
+static inline int test_and_set_bit(int nr, volatile void * addr)
+{
+ unsigned long flags;
+ int out;
+
+ local_irq_save(flags);
+ out = __test_and_set_bit(nr, addr);
+ local_irq_restore(flags);
+
+ return out;
+}
static inline int __test_and_clear_bit(int nr, volatile void *addr)
{
@@ -79,6 +88,18 @@ static inline int __test_and_clear_bit(int nr, volatile void
*addr)
return (old & mask) != 0;
}
+static inline int test_and_clear_bit(int nr, volatile void * addr)
+{
+ unsigned long flags;
+ int out;
+
+ local_irq_save(flags);
+ out = __test_and_clear_bit(nr, addr);
+ local_irq_restore(flags);
+
+ return out;
+}
+
extern int test_and_change_bit(int nr, volatile void * addr);
static inline int __test_and_change_bit(int nr, volatile void *addr)
--
1.6.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 3/4]: Define ffs/fls for all architectures
UBIFS requires fls(), which is not defined for arm (and some other
architectures) and this patch adds it. The implementation is taken from
Linux and is generic. ffs() is also defined for those that miss it.
v2: Unify code style (empty line between ffs/fls)
Signed-off-by: Simon Kagstrom
---
include/asm-arm/bitops.h|4
include/asm-avr32/bitops.h |4
include/asm-i386/bitops.h |2 ++
include/asm-m68k/bitops.h |2 ++
include/asm-microblaze/bitops.h |2 ++
include/asm-mips/bitops.h |2 ++
include/asm-nios/bitops.h |5 -
include/asm-nios2/bitops.h |5 -
include/asm-sh/bitops.h |2 ++
include/asm-sparc/bitops.h |4
include/linux/bitops.h | 37 +
11 files changed, 67 insertions(+), 2 deletions(-)
diff --git a/include/asm-arm/bitops.h b/include/asm-arm/bitops.h
index 04ae68c..b3a9578 100644
--- a/include/asm-arm/bitops.h
+++ b/include/asm-arm/bitops.h
@@ -17,6 +17,8 @@
#ifdef __KERNEL__
+#include
+
#define smp_mb__before_clear_bit() do { } while (0)
#define smp_mb__after_clear_bit() do { } while (0)
@@ -126,6 +128,8 @@ static inline unsigned long ffz(unsigned long word)
#define ffs(x) generic_ffs(x)
+#define fls(x) generic_fls(x)
+
/*
* hweightN: returns the hamming weight (i.e. the number
* of bits set) of a N-bit word
diff --git a/include/asm-avr32/bitops.h b/include/asm-avr32/bitops.h
index b1cf2fb..5fa20e2 100644
--- a/include/asm-avr32/bitops.h
+++ b/include/asm-avr32/bitops.h
@@ -26,4 +26,8 @@
#define __clear_bit(nr, addr) generic_clear_bit(nr, addr)
+#define ffs(x) generic_ffs(x)
+
+#define fls(x) generic_fls(x)
+
#endif /* __ASM_AVR32_BITOPS_H */
diff --git a/include/asm-i386/bitops.h b/include/asm-i386/bitops.h
index b768e20..71c2256 100644
--- a/include/asm-i386/bitops.h
+++ b/include/asm-i386/bitops.h
@@ -350,6 +350,8 @@ static __inline__ int ffs(int x)
return r+1;
}
+#define fls(x) generic_fls(x)
+
/**
* hweightN - returns the hamming weight of a N-bit word
* @x: the word to weigh
diff --git a/include/asm-m68k/bitops.h b/include/asm-m68k/bitops.h
index fb472e6..a38a62a 100644
--- a/include/asm-m68k/bitops.h
+++ b/include/asm-m68k/bitops.h
@@ -56,6 +56,8 @@ extern __inline__ int ffs(int x)
}
#define __ffs(x) (ffs(x) - 1)
+#define fls(x) generic_fls(x)
+
#endif /* __KERNEL__ */
#endif /* _M68K_BITOPS_H */
diff --git a/include/asm-microblaze/bitops.h b/include/asm-microblaze/bitops.h
index 04ea020..e277ab8 100644
--- a/include/asm-microblaze/bitops.h
+++ b/include/asm-microblaze/bitops.h
@@ -266,6 +266,8 @@ found_middle:
#define ffs(x) generic_ffs(x)
+#define fls(x) generic_fls(x)
+
/*
* hweightN: returns the hamming weight (i.e. the number
* of bits set) of a N-bit word
diff --git a/include/asm-mips/bitops.h b/include/asm-mips/bitops.h
index 659ac9d..76b9baa 100644
--- a/include/asm-mips/bitops.h
+++ b/include/asm-mips/bitops.h
@@ -716,6 +716,8 @@ static __inline__ unsigned long ffz(unsigned long word)
#define ffs(x) generic_ffs(x)
+#define fls(x) generic_fls(x)
+
/*
* hweightN - returns the hamming weight of a N-bit word
* @x: the word to weigh
diff --git a/include/asm-nios/bitops.h b/include/asm-nios/bitops.h
index 76c52c2..33714c4 100644
--- a/include/asm-nios/bitops.h
+++ b/include/asm-nios/bitops.h
@@ -32,7 +32,10 @@ extern void change_bit(unsigned long nr, volatile void
*addr);
extern int test_and_set_bit(int nr, volatile void * a);
extern int test_and_change_bit(int nr, volatile void * addr);
extern int test_bit(int nr, volatile void * a);
-extern int ffs(int i);
+
+#define ffs(x) generic_ffs(x)
+
+#define fls(x) generic_fls(x)
#define __set_bit(nr, addr) generic_set_bit(nr, addr)
diff --git a/include/asm-nios2/bitops.h b/include/asm-nios2/bitops.h
index da04b40..1fac52c 100644
--- a/include/asm-nios2/bitops.h
+++ b/include/asm-nios2/bitops.h
@@ -32,7 +32,10 @@ extern void change_bit(unsigned long nr, volatile void
*addr);
extern int test_and_set_bit(int nr, volatile void * a);
extern int test_and_change_bit(int nr, volatile void * addr);
extern int test_bit(int nr, volatile void * a);
-extern int ffs(int i);
+
+#define ffs(x) generic_ffs(x)
+
+#define fls(x) generic_fls(x)
#define __set_bit(nr, addr) generic_set_bit(nr, addr)
diff --git a/include/asm-sh/bitops.h b/include/asm-sh/bitops.h
index f102e7e..8021455 100644
--- a/include/asm-sh/bitops.h
+++ b/include/asm-sh/bitops.h
@@ -147,6 +147,8 @@ static inline int ffs (int x)
return r;
}
+#define fls(x) generic_fls(x)
+
#define __set_bit(nr, addr) generic_set_bit(nr, addr)
#define __clear_bit(nr, addr) generic_clear_bit(nr, addr)
diff --git a/include/asm-sparc/bitops.h b/include/asm-sparc/bitops.h
index b1bcb53..942029f 100644
--- a/include/asm-sparc/bitops.h
+++ b/include/asm-sparc/bitops.h
@@ -30,4 +30,8 @@
#define __clear_bit(nr, addr) generic_clear_bit(nr, addr)
+
[U-Boot] [PATCH v2 2/4]: Make arm bitops endianness-independent
Bring over the bitop implementations from the Linux
include/asm-generic/bitops/non-atomic.h to provide
endianness-independence.
Signed-off-by: Simon Kagstrom
---
include/asm-arm/bitops.h | 45 +++--
1 files changed, 27 insertions(+), 18 deletions(-)
diff --git a/include/asm-arm/bitops.h b/include/asm-arm/bitops.h
index 4b8bab2..04ae68c 100644
--- a/include/asm-arm/bitops.h
+++ b/include/asm-arm/bitops.h
@@ -27,57 +27,66 @@ extern void set_bit(int nr, volatile void * addr);
static inline void __set_bit(int nr, volatile void *addr)
{
- ((unsigned char *) addr)[nr >> 3] |= (1U << (nr & 7));
+ unsigned long mask = BIT_MASK(nr);
+ unsigned long *p = ((unsigned long *)addr) + BIT_WORD(nr);
+
+ *p |= mask;
}
extern void clear_bit(int nr, volatile void * addr);
static inline void __clear_bit(int nr, volatile void *addr)
{
- ((unsigned char *) addr)[nr >> 3] &= ~(1U << (nr & 7));
+ unsigned long mask = BIT_MASK(nr);
+ unsigned long *p = ((unsigned long *)addr) + BIT_WORD(nr);
+
+ *p &= ~mask;
}
extern void change_bit(int nr, volatile void * addr);
static inline void __change_bit(int nr, volatile void *addr)
{
- ((unsigned char *) addr)[nr >> 3] ^= (1U << (nr & 7));
+ unsigned long mask = BIT_MASK(nr);
+ unsigned long *p = ((unsigned long *)addr) + BIT_WORD(nr);
+
+ *p ^= mask;
}
extern int test_and_set_bit(int nr, volatile void * addr);
static inline int __test_and_set_bit(int nr, volatile void *addr)
{
- unsigned int mask = 1 << (nr & 7);
- unsigned int oldval;
+ unsigned long mask = BIT_MASK(nr);
+ unsigned long *p = ((unsigned long *)addr) + BIT_WORD(nr);
+ unsigned long old = *p;
- oldval = ((unsigned char *) addr)[nr >> 3];
- ((unsigned char *) addr)[nr >> 3] = oldval | mask;
- return oldval & mask;
+ *p = old | mask;
+ return (old & mask) != 0;
}
extern int test_and_clear_bit(int nr, volatile void * addr);
static inline int __test_and_clear_bit(int nr, volatile void *addr)
{
- unsigned int mask = 1 << (nr & 7);
- unsigned int oldval;
+ unsigned long mask = BIT_MASK(nr);
+ unsigned long *p = ((unsigned long *)addr) + BIT_WORD(nr);
+ unsigned long old = *p;
- oldval = ((unsigned char *) addr)[nr >> 3];
- ((unsigned char *) addr)[nr >> 3] = oldval & ~mask;
- return oldval & mask;
+ *p = old & ~mask;
+ return (old & mask) != 0;
}
extern int test_and_change_bit(int nr, volatile void * addr);
static inline int __test_and_change_bit(int nr, volatile void *addr)
{
- unsigned int mask = 1 << (nr & 7);
- unsigned int oldval;
+ unsigned long mask = BIT_MASK(nr);
+ unsigned long *p = ((unsigned long *)addr) + BIT_WORD(nr);
+ unsigned long old = *p;
- oldval = ((unsigned char *) addr)[nr >> 3];
- ((unsigned char *) addr)[nr >> 3] = oldval ^ mask;
- return oldval & mask;
+ *p = old ^ mask;
+ return (old & mask) != 0;
}
extern int find_first_zero_bit(void * addr, unsigned size);
--
1.6.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/4]: Move __set/clear_bit from ubifs.h to bitops.h
__set_bit and __clear_bit are defined in ubifs.h as well as in
asm/include/bitops.h for some architectures. This patch moves
the generic implementation to include/linux/bitops.h and uses
that unless it's defined by the architecture.
v2: Unify code style (newline between __set_bit and __clear_bit)
v3: Move BIT_MASK and BIT_WORD above the include of asm/bitops.h
Signed-off-by: Simon Kagstrom
---
fs/ubifs/ubifs.h | 32
include/asm-avr32/bitops.h |4
include/asm-m68k/bitops.h |4
include/asm-nios/bitops.h |4
include/asm-nios2/bitops.h |4
include/asm-ppc/bitops.h |4
include/asm-sh/bitops.h|5 +
include/asm-sparc/bitops.h |4
include/linux/bitops.h | 29 +
9 files changed, 58 insertions(+), 32 deletions(-)
diff --git a/fs/ubifs/ubifs.h b/fs/ubifs/ubifs.h
index 43865aa..06772af 100644
--- a/fs/ubifs/ubifs.h
+++ b/fs/ubifs/ubifs.h
@@ -449,38 +449,6 @@ static inline ino_t parent_ino(struct dentry *dentry)
return res;
}
-/* linux/include/linux/bitops.h */
-
-#define BIT_MASK(nr) (1UL << ((nr) % BITS_PER_LONG))
-#define BIT_WORD(nr) ((nr) / BITS_PER_LONG)
-
-/* linux/include/asm-generic/bitops/non-atomic.h */
-
-/**
- * __set_bit - Set a bit in memory
- * @nr: the bit to set
- * @addr: the address to start counting from
- *
- * Unlike set_bit(), this function is non-atomic and may be reordered.
- * If it's called on the same region of memory simultaneously, the effect
- * may be that only one operation succeeds.
- */
-static inline void __set_bit(int nr, volatile unsigned long *addr)
-{
- unsigned long mask = BIT_MASK(nr);
- unsigned long *p = ((unsigned long *)addr) + BIT_WORD(nr);
-
- *p |= mask;
-}
-
-static inline void __clear_bit(int nr, volatile unsigned long *addr)
-{
- unsigned long mask = BIT_MASK(nr);
- unsigned long *p = ((unsigned long *)addr) + BIT_WORD(nr);
-
- *p &= ~mask;
-}
-
/* debug.c */
#define DEFINE_SPINLOCK(...)
diff --git a/include/asm-avr32/bitops.h b/include/asm-avr32/bitops.h
index f15fd46..b1cf2fb 100644
--- a/include/asm-avr32/bitops.h
+++ b/include/asm-avr32/bitops.h
@@ -22,4 +22,8 @@
#ifndef __ASM_AVR32_BITOPS_H
#define __ASM_AVR32_BITOPS_H
+#define __set_bit(nr, addr) generic_set_bit(nr, addr)
+
+#define __clear_bit(nr, addr) generic_clear_bit(nr, addr)
+
#endif /* __ASM_AVR32_BITOPS_H */
diff --git a/include/asm-m68k/bitops.h b/include/asm-m68k/bitops.h
index 0f9e8ab..fb472e6 100644
--- a/include/asm-m68k/bitops.h
+++ b/include/asm-m68k/bitops.h
@@ -15,6 +15,10 @@ extern int test_and_set_bit(int nr, volatile void *addr);
extern int test_and_clear_bit(int nr, volatile void *addr);
extern int test_and_change_bit(int nr, volatile void *addr);
+#define __set_bit(nr, addr) generic_set_bit(nr, addr)
+
+#define __clear_bit(nr, addr) generic_clear_bit(nr, addr)
+
#ifdef __KERNEL__
/*
diff --git a/include/asm-nios/bitops.h b/include/asm-nios/bitops.h
index 7744212..76c52c2 100644
--- a/include/asm-nios/bitops.h
+++ b/include/asm-nios/bitops.h
@@ -34,4 +34,8 @@ extern int test_and_change_bit(int nr, volatile void * addr);
extern int test_bit(int nr, volatile void * a);
extern int ffs(int i);
+#define __set_bit(nr, addr) generic_set_bit(nr, addr)
+
+#define __clear_bit(nr, addr) generic_clear_bit(nr, addr)
+
#endif /* _ASM_NIOS_BITOPS_H */
diff --git a/include/asm-nios2/bitops.h b/include/asm-nios2/bitops.h
index e6c1a85..da04b40 100644
--- a/include/asm-nios2/bitops.h
+++ b/include/asm-nios2/bitops.h
@@ -34,4 +34,8 @@ extern int test_and_change_bit(int nr, volatile void * addr);
extern int test_bit(int nr, volatile void * a);
extern int ffs(int i);
+#define __set_bit(nr, addr) generic_set_bit(nr, addr)
+
+#define __clear_bit(nr, addr) generic_clear_bit(nr, addr)
+
#endif /* __ASM_NIOS2_BITOPS_H */
diff --git a/include/asm-ppc/bitops.h b/include/asm-ppc/bitops.h
index daa66cf..fd7f599 100644
--- a/include/asm-ppc/bitops.h
+++ b/include/asm-ppc/bitops.h
@@ -144,6 +144,10 @@ extern __inline__ int test_and_change_bit(int nr, volatile
void *addr)
}
#endif /* __INLINE_BITOPS */
+#define __set_bit(nr, addr) generic_set_bit(nr, addr)
+
+#define __clear_bit(nr, addr) generic_clear_bit(nr, addr)
+
extern __inline__ int test_bit(int nr, __const__ volatile void *addr)
{
__const__ unsigned int *p = (__const__ unsigned int *) addr;
diff --git a/include/asm-sh/bitops.h b/include/asm-sh/bitops.h
index 410fba4..f102e7e 100644
--- a/include/asm-sh/bitops.h
+++ b/include/asm-sh/bitops.h
@@ -146,6 +146,11 @@ static inline int ffs (int x)
}
return r;
}
+
+#define __set_bit(nr, addr) generic_set_bit(nr, addr)
+
+#define __clear_bit(nr, addr) generic_clear_bit(nr, addr)
+
#endif /* __KERNEL__ */
#endif /* __ASM_SH_BITOPS_H */
diff --git a/include/asm-sparc/bitops.h b/include/asm-sparc/bitops.h
index ceb39f2..b1bcb53 100644
--- a/inclu
[U-Boot] [PATCH v2 0/4]: bitops cleanup and fixes
Hi again! This patch series is an update to "[PATCH 0/4]: bitops cleanup and fixes": http://article.gmane.org/gmane.comp.boot-loaders.u-boot/66184 and contains the patches which were not accepted. The patches are: 0001-Move-__set-clear_bit-from-ubifs.h-to-bitops.h.patch - Code style updates. I chose to not create asm-generic/include/bitops/ (Jean-Christophes comment) since I feel that should go together with a larger restructuring. - Updated to put BIT_MASK above the include of asm/bitops.h 0002-Make-arm-bitops-endianness-independent.patch - New patch which takes on the endianeess issue in arm bitops 0003-Define-ffs-fls-for-all-architectures.patch - Code style updates (Wolfgangs comment). 0004-Define-test_and_set_bit-and-test_and_clear-bit-for-A.patch - Defines test_and_set_bit etc for ARM. Uses the non-atomic __test_and_set_bit. remove-dupliace-cr.patch was accepted into the u-boot-arm tree, so I'm not reposting it. // Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4]: Define ffs/fls for all architectures
On Thu, 20 Aug 2009 01:11:09 +0200 Jean-Christophe PLAGNIOL-VILLARD wrote: > On 11:13 Tue 18 Aug , Simon Kagstrom wrote: > > Define ffs/fls for all architectures > > > > UBIFS requires fls(), which is not defined for arm (and some other > > architectures) and this patch adds it. The implementation is taken from > > Linux and is generic. ffs() is also defined for those that miss it. > > > > v2: Unify code style (empty line between ffs/fls) > please this > > > > Signed-off-by: Simon Kagstrom > > --- > here I didn't add that myself - it's git format-patch that put it there. // Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH "mkimage" branch] tools/mkimage: fix compiler warnings, use "const"
> -Original Message-
> From: u-boot-boun...@lists.denx.de
> [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Wolfgang Denk
> Sent: Wednesday, August 19, 2009 3:24 PM
> To: u-boot@lists.denx.de
> Subject: [U-Boot] [PATCH "mkimage" branch] tools/mkimage: fix
> compiler warnings, use "const"
>
> This fixes some compiler warnings:
> tools/default_image.c:141: warning: initialization from
> incompatible pointer type
> tools/fit_image.c:202: warning: initialization from
> incompatible pointer type
> and changes to code to use "const" attributes in a few places where
> it's appropriate.
Dear Wolfgang
99% of the changes in this patch is to add const attributes.
Can you pls explain here- how useful it is to add const.
Or do it make more sense just to fix the warnings in respective functions?
I have posted a patch for the same
For ex.
Regards..
Prafulla . .
>
> Signed-off-by: Wolfgang Denk
> ---
> common/image.c | 39 ---
> include/image.h | 34 +-
> tools/mkimage.h |2 +-
> 3 files changed, 38 insertions(+), 37 deletions(-)
>
> diff --git a/common/image.c b/common/image.c
> index e22c974..f3dd647 100644
> --- a/common/image.c
> +++ b/common/image.c
> @@ -65,7 +65,7 @@ extern int do_bdinfo(cmd_tbl_t *cmdtp, int
> flag, int argc, char *argv[]);
>
> DECLARE_GLOBAL_DATA_PTR;
>
> -static image_header_t* image_get_ramdisk (ulong rd_addr,
> uint8_t arch,
> +static const image_header_t* image_get_ramdisk (ulong
> rd_addr, uint8_t arch,
> int verify);
> #else
> #include "mkimage.h"
> @@ -166,7 +166,7 @@ static void genimg_print_time (time_t timestamp);
>
> /*
> /
> /* Legacy format routines */
>
> /*
> /
> -int image_check_hcrc (image_header_t *hdr)
> +int image_check_hcrc (const image_header_t *hdr)
> {
> ulong hcrc;
> ulong len = image_get_header_size ();
> @@ -181,7 +181,7 @@ int image_check_hcrc (image_header_t *hdr)
> return (hcrc == image_get_hcrc (hdr));
> }
>
> -int image_check_dcrc (image_header_t *hdr)
> +int image_check_dcrc (const image_header_t *hdr)
> {
> ulong data = image_get_data (hdr);
> ulong len = image_get_data_size (hdr);
> @@ -203,7 +203,7 @@ int image_check_dcrc (image_header_t *hdr)
> * returns:
> * number of components
> */
> -ulong image_multi_count (image_header_t *hdr)
> +ulong image_multi_count (const image_header_t *hdr)
> {
> ulong i, count = 0;
> uint32_t *size;
> @@ -236,7 +236,7 @@ ulong image_multi_count (image_header_t *hdr)
> * data address and size of the component, if idx is valid
> * 0 in data and len, if idx is out of range
> */
> -void image_multi_getimg (image_header_t *hdr, ulong idx,
> +void image_multi_getimg (const image_header_t *hdr, ulong idx,
> ulong *data, ulong *len)
> {
> int i;
> @@ -272,7 +272,7 @@ void image_multi_getimg (image_header_t
> *hdr, ulong idx,
> }
> }
>
> -static void image_print_type (image_header_t *hdr)
> +static void image_print_type (const image_header_t *hdr)
> {
> const char *os, *arch, *type, *comp;
>
> @@ -286,7 +286,7 @@ static void image_print_type (image_header_t *hdr)
>
> /**
> * image_print_contents - prints out the contents of the
> legacy format image
> - * @hdr: pointer to the legacy format image header
> + * @ptr: pointer to the legacy format image header
> * @p: pointer to prefix string
> *
> * image_print_contents() formats a multi line legacy image
> contents description.
> @@ -296,8 +296,9 @@ static void image_print_type (image_header_t *hdr)
> * returns:
> * no returned results
> */
> -void image_print_contents (image_header_t *hdr)
> +void image_print_contents (const void *ptr)
> {
> + const image_header_t *hdr = (const image_header_t *)ptr;
> const char *p;
>
> #ifdef USE_HOSTCC
> @@ -363,10 +364,10 @@ void image_print_contents (image_header_t *hdr)
> * pointer to a ramdisk image header, if image was found
> and valid
> * otherwise, return NULL
> */
> -static image_header_t* image_get_ramdisk (ulong rd_addr,
> uint8_t arch,
> +static const image_header_t *image_get_ramdisk (ulong
> rd_addr, uint8_t arch,
> int verify)
> {
> - image_header_t *rd_hdr = (image_header_t *)rd_addr;
> + const image_header_t *rd_hdr = (const image_header_t *)rd_addr;
>
> if (!image_check_magic (rd_hdr)) {
> puts ("Bad Magic Number\n");
> @@ -628,13 +629,13 @@ int genimg_get_comp_id (const char *name)
> */
> int genimg_get_format (void *img_addr)
> {
> - ulong format = IMAGE_FORMAT_INVALID;
> - image_header_t *hdr;
> + ulong format = IMAGE_FORMAT_INVALID;
> + const im
Re: [U-Boot] [PATCH] arm:kirkwood See to it that sent data is 8-byte aligned
> -Original Message- > From: Jean-Christophe PLAGNIOL-VILLARD [mailto:plagn...@jcrosoft.com] > Sent: Thursday, August 20, 2009 4:07 AM > To: Simon Kagstrom > Cc: Prafulla Wadaskar; U-Boot ML; Prabhanjan Sarnaik; Ashish Karkare > Subject: Re: [U-Boot] [PATCH] arm:kirkwood See to it that > sent data is 8-byte aligned > > On 12:48 Tue 18 Aug , Simon Kagstrom wrote: > > Thanks for the review Prafulla! > > > > On Tue, 18 Aug 2009 03:12:07 -0700 > > Prafulla Wadaskar wrote: > > > > > > v2: Malloc send buffer (comment from Stefan Roese) > > > Malloc will always be an overhead. > > > > It's only allocated once (the first time a non-aligned buffer is > > passed), so the overhead is minimal. > > > > > I strongly recommend- we should pass aligned buffers from > upper layers > > > to avoid such rework in all low level drivers, (few are already > > > aligned). > > > > We could put the same fix in eth_send instead. Then the > issue is really > > just how we know what alignment requirement to go for. I guess one > > could add a field to the eth_device structure to store this and then > > fixup all drivers to supply this. > > > > If the rest of you thinks this is a good idea, I can cook > up a patch. > > Opinions? > some drivers would also have the possibility to have multiple > receive buffer > specially when you use dma > so IMHO it make more sense to let each drivers handle it itself In that case it makes more sense to implement this even for rx path too in upper layer. We should always push common functionalities to upper layers And this is very generic need for any driver that uses dma for transfers Regards.. Prafulla . . > > Best Regards, > J. > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] AT91: Add support for blue_LED_* and add coloured_LED_init to at91/led.c
On Thu, Aug 20, 2009 at 02:00:45AM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote : > On 10:49 Tue 18 Aug , Albin Tonnerre wrote: > > On Tue, Aug 18, 2009 at 12:51:48AM +0200, Jean-Christophe PLAGNIOL-VILLARD > > wrote : > > > no please take a look on the other LED thread > > > > Would you please provide a pointer to this thread ? THe only one remotely > > related I can find is > > http://lists.denx.de/pipermail/u-boot/2009-May/052160.html, and you did not > > participate in this one ... > I've as I'm the one who ask Daniel Gorsulowski to base his new code (this > patch) > against Ulf precedent patch and as other people have done the same comment as > I will do > no need to repeat it Ok, so I'm really confused now. This patch does exactly what you're arguing against in the rest of your mail, and you still don't provide a pointer to Ulf's patch. Would you mind *explaining* to me what your plan is? I just can't get it. Regards, -- Albin Tonnerre, Free Electrons Kernel, drivers and embedded Linux development, consulting, training and support. http://free-electrons.com signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Weird issues with u-boot on Microblaze
Hi, > I've been trying to bring up a vanilla kernel on an XUPV5-LX110T board, > and have been having all sorts of odd issues with U-Boot. For example, > if I try to enable FIT image support (as noted on > http://www.monstr.eu/wiki/doku.php?id=uboot:uboot ), I get > CONFIG_BOOTMAPSZ undefined. I've also had to edit image.h to get the > thing to compile. > > image.c: In function ‘boot_get_fdt’: > > image.c:1510: error: ‘bootm_headers_t’ has no member named ‘fit_hdr_fdt’ > > image.c:1511: error: ‘bootm_headers_t’ has no member named ‘fit_uname_fdt’ > > image.c:1512: error: ‘bootm_headers_t’ has no member named > ‘fit_noffset_fdt’ > > the fix: edit image.h (line 221): > #if defined(CONFIG_OF_LIBFDT) /* WAS: CONFIG_PPC */ FIT support is not in mainline u-boot. Only in my testing repository. > > If I fix that and try to load a FIT image with a kernel and device-tree, > the bootm command completely ignores the device tree; unfortunately, Yes the same thing as with FIT. Not in mainline yet. Simple no time. But I have patches in my tree and I want to send them to next merge open window. > I > don't have a log of this on hand, because now even image loading has > broken somehow. For example, fatls ace 0 gives " 131074 . ", and > attempting DHCP boot results in a spew of "ARP Retry count exceeded; > starting again" -- retry count exceeded, despite it never having tried > even once? I'll test it. > > I've attached a log of the console output under both conditions, as well > as the config.mk and xparameters.h under microblaze_generic; for some > reason, the given U-Boot BSP assumes 100MHz, despite the board using > 125MHz. Does anyone have advice for getting u-boot to work on this board? > I have fix for u-boot bsp which fix it. The same issue is for uart16550. I am going to update my git repo at http://git.monstr.eu/git/gitweb.cgi There will be updated u-boot bsp too. Thanks, Michal > Thanks in advance for any help. > > > > > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot -- Michal Simek, Ing. (M.Eng) w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/ Microblaze U-BOOT custodian ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/3] [repost]: arm: kirkwood: See to it that sent data is 8-byte aligned
U-boot might use non-8-byte-aligned addresses for sending data, which
the kwgbe_send doesn't accept (bootp does this for me). This patch
copies the data to be sent to a malloced temporary buffer if it is
non-aligned.
v2: Malloc send buffer
v3: No need to use jumbo frames, use 1518 bytes buffer instead
v4: Correct alignment passed to memalign (should be 8!),
allocate buffer at initialization(), use PKTSIZE_ALIGN
Signed-off-by: Simon Kagstrom
---
drivers/net/kirkwood_egiga.c | 21 +
drivers/net/kirkwood_egiga.h |1 +
2 files changed, 18 insertions(+), 4 deletions(-)
diff --git a/drivers/net/kirkwood_egiga.c b/drivers/net/kirkwood_egiga.c
index 9f36633..479035d 100644
--- a/drivers/net/kirkwood_egiga.c
+++ b/drivers/net/kirkwood_egiga.c
@@ -500,18 +500,26 @@ static int kwgbe_send(struct eth_device *dev, volatile
void *dataptr,
struct kwgbe_device *dkwgbe = to_dkwgbe(dev);
struct kwgbe_registers *regs = dkwgbe->regs;
struct kwgbe_txdesc *p_txdesc = dkwgbe->p_txdesc;
+ void *p = (void *)dataptr;
u32 cmd_sts;
+ /* Copy buffer if it's misaligned */
if ((u32) dataptr & 0x07) {
- printf("Err..(%s) xmit dataptr not 64bit aligned\n",
- __FUNCTION__);
- return -1;
+ if (datasize > PKTSIZE_ALIGN) {
+ printf("Non-aligned data too large (%d)\n",
+ datasize);
+ return -1;
+ }
+
+ memcpy(dkwgbe->p_aligned_txbuf, p, datasize);
+ p = dkwgbe->p_aligned_txbuf;
}
+
p_txdesc->cmd_sts = KWGBE_ZERO_PADDING | KWGBE_GEN_CRC;
p_txdesc->cmd_sts |= KWGBE_TX_FIRST_DESC | KWGBE_TX_LAST_DESC;
p_txdesc->cmd_sts |= KWGBE_BUFFER_OWNED_BY_DMA;
p_txdesc->cmd_sts |= KWGBE_TX_EN_INTERRUPT;
- p_txdesc->buf_ptr = (u8 *) dataptr;
+ p_txdesc->buf_ptr = (u8 *) p;
p_txdesc->byte_cnt = datasize;
/* Apply send command using zeroth RXUQ */
@@ -628,8 +636,13 @@ int kirkwood_egiga_initialize(bd_t * bis)
* PKTSIZE_ALIGN + 1)))
goto error3;
+ if (!(dkwgbe->p_aligned_txbuf = memalign(8, PKTSIZE_ALIGN)))
+ goto error4;
+
if (!(dkwgbe->p_txdesc = (struct kwgbe_txdesc *)
memalign(PKTALIGN, sizeof(struct kwgbe_txdesc) + 1))) {
+ free(dkwgbe->p_aligned_txbuf);
+ error4:
free(dkwgbe->p_rxbuf);
error3:
free(dkwgbe->p_rxdesc);
diff --git a/drivers/net/kirkwood_egiga.h b/drivers/net/kirkwood_egiga.h
index 9c893d1..16d5214 100644
--- a/drivers/net/kirkwood_egiga.h
+++ b/drivers/net/kirkwood_egiga.h
@@ -499,6 +499,7 @@ struct kwgbe_device {
struct kwgbe_rxdesc *p_rxdesc;
struct kwgbe_rxdesc *p_rxdesc_curr;
u8 *p_rxbuf;
+ u8 *p_aligned_txbuf;
};
#endif /* __EGIGA_H__ */
--
1.6.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/3]: Wait for the link to come up on kirkwood network init
This patch makes the device wait for up to 5 seconds for the link to
come up, similar to what many of the other network drivers do. This
avoids confusing situations where, e.g., a tftp fails when initiated
early after U-boot has started (before the link has come up).
v2: Remove function name from printout
Signed-off-by: Simon Kagstrom
---
drivers/net/kirkwood_egiga.c | 20 ++--
1 files changed, 14 insertions(+), 6 deletions(-)
diff --git a/drivers/net/kirkwood_egiga.c b/drivers/net/kirkwood_egiga.c
index 065e335..9f36633 100644
--- a/drivers/net/kirkwood_egiga.c
+++ b/drivers/net/kirkwood_egiga.c
@@ -400,6 +400,7 @@ static int kwgbe_init(struct eth_device *dev)
{
struct kwgbe_device *dkwgbe = to_dkwgbe(dev);
struct kwgbe_registers *regs = dkwgbe->regs;
+ int i;
/* setup RX rings */
kwgbe_init_rx_desc_ring(dkwgbe);
@@ -447,13 +448,20 @@ static int kwgbe_init(struct eth_device *dev)
#if (defined (CONFIG_MII) || defined (CONFIG_CMD_MII)) \
&& defined (CONFIG_SYS_FAULT_ECHO_LINK_DOWN)
- u16 phyadr;
- miiphy_read(dev->name, KIRKWOOD_PHY_ADR_REQUEST,
- KIRKWOOD_PHY_ADR_REQUEST, &phyadr);
- if (!miiphy_link(dev->name, phyadr)) {
- printf("%s: No link on %s\n", __FUNCTION__, dev->name);
- return -1;
+ /* Wait up to 5s for the link status */
+ for (i = 0; i < 5; i++) {
+ u16 phyadr;
+
+ miiphy_read(dev->name, KIRKWOOD_PHY_ADR_REQUEST,
+ KIRKWOOD_PHY_ADR_REQUEST, &phyadr);
+ /* Return if we get link up */
+ if (miiphy_link(dev->name, phyadr))
+ return 0;
+ udelay(100);
}
+
+ printf("No link on %s\n", dev->name);
+ return -1;
#endif
return 0;
}
--
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/3]: arm:kirkwood Define kirkwood phy address magic number
Signed-off-by: Simon Kagstrom
---
drivers/net/kirkwood_egiga.c | 14 ++
1 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/net/kirkwood_egiga.c b/drivers/net/kirkwood_egiga.c
index f31fefc..065e335 100644
--- a/drivers/net/kirkwood_egiga.c
+++ b/drivers/net/kirkwood_egiga.c
@@ -38,6 +38,8 @@
#include
#include "kirkwood_egiga.h"
+#define KIRKWOOD_PHY_ADR_REQUEST 0xee
+
/*
* smi_reg_read - miiphy_read callback function.
*
@@ -52,7 +54,8 @@ static int smi_reg_read(char *devname, u8 phy_adr, u8
reg_ofs, u16 * data)
u32 timeout;
/* Phyadr read request */
- if (phy_adr == 0xEE && reg_ofs == 0xEE) {
+ if (phy_adr == KIRKWOOD_PHY_ADR_REQUEST &&
+ reg_ofs == KIRKWOOD_PHY_ADR_REQUEST) {
/* */
*data = (u16) (KWGBEREG_RD(regs->phyadr) & PHYADR_MASK);
return 0;
@@ -127,7 +130,8 @@ static int smi_reg_write(char *devname, u8 phy_adr, u8
reg_ofs, u16 data)
u32 timeout;
/* Phyadr write request*/
- if (phy_adr == 0xEE && reg_ofs == 0xEE) {
+ if (phy_adr == KIRKWOOD_PHY_ADR_REQUEST &&
+ reg_ofs == KIRKWOOD_PHY_ADR_REQUEST) {
KWGBEREG_WR(regs->phyadr, data);
return 0;
}
@@ -444,7 +448,8 @@ static int kwgbe_init(struct eth_device *dev)
#if (defined (CONFIG_MII) || defined (CONFIG_CMD_MII)) \
&& defined (CONFIG_SYS_FAULT_ECHO_LINK_DOWN)
u16 phyadr;
- miiphy_read(dev->name, 0xEE, 0xEE, &phyadr);
+ miiphy_read(dev->name, KIRKWOOD_PHY_ADR_REQUEST,
+ KIRKWOOD_PHY_ADR_REQUEST, &phyadr);
if (!miiphy_link(dev->name, phyadr)) {
printf("%s: No link on %s\n", __FUNCTION__, dev->name);
return -1;
@@ -670,7 +675,8 @@ int kirkwood_egiga_initialize(bd_t * bis)
#if defined(CONFIG_MII) || defined(CONFIG_CMD_MII)
miiphy_register(dev->name, smi_reg_read, smi_reg_write);
/* Set phy address of the port */
- miiphy_write(dev->name, 0xEE, 0xEE, PHY_BASE_ADR + devnum);
+ miiphy_write(dev->name, KIRKWOOD_PHY_ADR_REQUEST,
+ KIRKWOOD_PHY_ADR_REQUEST, PHY_BASE_ADR +
devnum);
#endif
}
return 0;
--
1.6.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/3]: arm:Kirkwood network driver fixes
Hi! Three patches to fix various network driver issues on kirkwood. Patch 3 is a repost of the patch sent earlier today which is rebased on top of the other two. // Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm:kirkwood Wait for the link to come up on kirkwood network init
On Wed, 19 Aug 2009 10:08:02 -0700
Ben Warren wrote:
> > - u16 phyadr;
> > - miiphy_read(dev->name, 0xEE, 0xEE, &phyadr);
> > - if (!miiphy_link(dev->name, phyadr)) {
> > - printf("%s: No link on %s\n", __FUNCTION__, dev->name);
> >
> Please use __func__ instead. It's defined in C99, while __FUNCTION__
> isn't (or so I've read)
I'll remove the function name part completely.
> > - return -1;
> > + /* Wait up to 5s for the link status */
> > + for (i = 0; i < 5; i++) {
> > + u16 phyadr;
> >
> Please put this variable declaration outside of the 'for' loop
> > + miiphy_read(dev->name, 0xEE, 0xEE, &phyadr);
> >
> What does '0xEE' mean? I know you didn't write it, but magic numbers
> are bad.
Good question. After looking around a bit, I end up in smi_reg_read in
the same file:
static int smi_reg_read(char *devname, u8 phy_adr, u8 reg_ofs, u16 * data)
{
[...]
/* Phyadr read request */
if (phy_adr == 0xEE && reg_ofs == 0xEE) {
/* */
*data = (u16) (KWGBEREG_RD(regs->phyadr) & PHYADR_MASK);
return 0;
[...]
}
which is registered for the PHY reads with miiphy_register. So it's a
file-local magic number. I'll cook up another patch which adresses this.
// Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4] arm: kirkwood: See to it that sent data is 8-byte aligned
U-boot might use non-8-byte-aligned addresses for sending data, which
the kwgbe_send doesn't accept (bootp does this for me). This patch
copies the data to be sent to a malloced temporary buffer if it is
non-aligned.
v2: Malloc send buffer
v3: No need to use jumbo frames, use 1518 bytes buffer instead
v4: Correct alignment passed to memalign (should be 8!),
allocate buffer at initialization(), use PKTSIZE_ALIGN
Signed-off-by: Simon Kagstrom
---
drivers/net/kirkwood_egiga.c | 21 +
drivers/net/kirkwood_egiga.h |1 +
2 files changed, 18 insertions(+), 4 deletions(-)
diff --git a/drivers/net/kirkwood_egiga.c b/drivers/net/kirkwood_egiga.c
index 9ac9c1f..008c5dd 100644
--- a/drivers/net/kirkwood_egiga.c
+++ b/drivers/net/kirkwood_egiga.c
@@ -494,18 +494,26 @@ static int kwgbe_send(struct eth_device *dev, volatile
void *dataptr,
struct kwgbe_device *dkwgbe = to_dkwgbe(dev);
struct kwgbe_registers *regs = dkwgbe->regs;
struct kwgbe_txdesc *p_txdesc = dkwgbe->p_txdesc;
+ void *p = (void *)dataptr;
u32 cmd_sts;
+ /* Copy buffer if it's misaligned */
if ((u32) dataptr & 0x07) {
- printf("Err..(%s) xmit dataptr not 64bit aligned\n",
- __FUNCTION__);
- return -1;
+ if (datasize > PKTSIZE_ALIGN) {
+ printf("Non-aligned data too large (%d)\n",
+ datasize);
+ return -1;
+ }
+
+ memcpy(dkwgbe->p_aligned_txbuf, p, datasize);
+ p = dkwgbe->p_aligned_txbuf;
}
+
p_txdesc->cmd_sts = KWGBE_ZERO_PADDING | KWGBE_GEN_CRC;
p_txdesc->cmd_sts |= KWGBE_TX_FIRST_DESC | KWGBE_TX_LAST_DESC;
p_txdesc->cmd_sts |= KWGBE_BUFFER_OWNED_BY_DMA;
p_txdesc->cmd_sts |= KWGBE_TX_EN_INTERRUPT;
- p_txdesc->buf_ptr = (u8 *) dataptr;
+ p_txdesc->buf_ptr = (u8 *) p;
p_txdesc->byte_cnt = datasize;
/* Apply send command using zeroth RXUQ */
@@ -622,8 +630,13 @@ int kirkwood_egiga_initialize(bd_t * bis)
* PKTSIZE_ALIGN + 1)))
goto error3;
+ if (!(dkwgbe->p_aligned_txbuf = memalign(8, PKTSIZE_ALIGN)))
+ goto error4;
+
if (!(dkwgbe->p_txdesc = (struct kwgbe_txdesc *)
memalign(PKTALIGN, sizeof(struct kwgbe_txdesc) + 1))) {
+ free(dkwgbe->p_aligned_txbuf);
+ error4:
free(dkwgbe->p_rxbuf);
error3:
free(dkwgbe->p_rxdesc);
diff --git a/drivers/net/kirkwood_egiga.h b/drivers/net/kirkwood_egiga.h
index 9c893d1..16d5214 100644
--- a/drivers/net/kirkwood_egiga.h
+++ b/drivers/net/kirkwood_egiga.h
@@ -499,6 +499,7 @@ struct kwgbe_device {
struct kwgbe_rxdesc *p_rxdesc;
struct kwgbe_rxdesc *p_rxdesc_curr;
u8 *p_rxbuf;
+ u8 *p_aligned_txbuf;
};
#endif /* __EGIGA_H__ */
--
1.6.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] e1000 Rx timeout with 82541ER
On Thu, 2009-08-20 at 10:36 +0800, Zang Roy-R61911 wrote: > > > -Original Message- > > From: Wolfgang Denk [mailto:w...@denx.de] > > Sent: Wednesday, August 19, 2009 7:58 AM > > To: André Schwarz > > Cc: Zang Roy-R61911; Ben Warren; U-Boot List > > Subject: Re: [U-Boot] e1000 Rx timeout with 82541ER > > > > Dear =?ISO-8859-1?Q?Andr=E9?= Schwarz, > > > > In message <1250683805.22118.22.ca...@swa-m460> you wrote: > > > > > > with latest e1000.c my 82541ER connected to a MPC5200 via PCI is no > > > longer working correctly - I get timeouts after few packets. After > > > having a quick look at the code changes it's obvious that I can't > > > figure out the problem quickly since there has been a lot > > of changes. > > > > Well, it should be straightforward to git-bisect this issue... > > > Could you help to send me the error log? > I do not have 82541ER card to try. ok - please give me some days. Hopefully I can send you some output/questions on tuesday. Regards, André > Thank.s > roy MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner, Hans-Joachim Reich ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
