Re: [U-Boot] [PATCH v2] Marvell MV88E61XX Switch Driver support

[Norbert van Bolhuis]

Hi Prafulla,

We have a custom designed board with the M88E6185 and M88E6131
switch. The u-boot patches are very usefull, even though I already
finished some code to initialize the switches.

In our application it's more easy to "fully" provision the switches
when the linux kernel is up and running.
So I wonder:
Is "M88E61XX switch driver support" planned for the linux kernel ?
In other words: is there any chance similar patches will be
released for the linux kernel any time soon ?

---
N. van Bolhuis.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Interrupt handlers in u-boot

[prathika]

hi all,
i got the interrupt handler working for SPI Receive in PPC 440 using 
install_hdlr().
Now i am trying to enable the External IRQ0 in my stand alone 
application. I am trying to detect the positive of the interrupt pulse, 
so i wrote corresponding bit to the UIC0_PR  and UIC0_EN register and 
also calling the install_hdlr().
but still it detects the zero state at the IRQ0 pin and always executes 
the interrupt handler.
when i read back the DCRs UIC0 enable and polarity registers using my 
application, the control word is fine.
but when i read using uboot commands getdcr in command window, the 
status of both enable and polarity registers are not enabled for IRQ0.
when i try to set the corresponding bit for IRQ0 using setdcr, it gives 
me message, "Masking bogus interrupt for 0x17"
where am i going wrong.Some one please help.
Thanks in advance.

Thanks & Regards,
Prathika R.

Stefan Roese wrote:
> On Wednesday 08 April 2009, prathika wrote:
>> I am working on u-boot 1.1.6 version for PowerPC 440.
> 
> First of all. v1.1.6 is really old. I suggest that you use the current 
> (latest) version instead.
> 
>> I am using the 
>> hello world application from the examples folder.
>> I had no issues in loading and executing it.
>> Now I have enabled SPI interrupt in the application. I have written for
>> SPI loopback.
>> My issue is, as there is no interrupt handler defined for the SPI in
>> uboot, whenever i execute my application,
>> it says "Masking bogus interrupt for Vector 0x08". I am calling
>> "install_irq_handler" function for assigning my own interrupt handler
>> for SPI as part of my application itself.
>> I can understand that, there is no exclusive handler for SPI in uboot,
>> so it is disabling the SPI interrupt and printing the BOGUS INTERRUPT
>> message.
>> Now how do I get rid of this and have my own interrupt handler??
> 
> You just need to install you "own" interrupt handler. This is done via 
> install_hdlr(). See examples/interrupt.c.
> 
> Best regards,
> Stefan
> 
> =
> DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: off...@denx.de
> =
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] USB EHCI driver

[Michael Trimarchi]

Hi,

Gupta Maneesh-B18878 wrote:
> Hi Francesco,
>
> Could you make any progress?
>
> Regards
> Maneesh
>  
>
>   
>> -Original Message-
>> From: u-boot-boun...@lists.denx.de 
>> [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Michael Trimarchi
>> Sent: Monday, March 23, 2009 2:46 PM
>> To: Rendine Francesco
>> Cc: u-boot@lists.denx.de
>> Subject: Re: [U-Boot] USB EHCI driver
>>
>> Hi,
>>
>> Rendine Francesco wrote:
>> 
>>> Hi,
>>>
>>> I've already tried that define, but nothing is changed...
>>> What can I see in the USB driver to resolve issue?
>>>
>>> Thanks.
>>>
>>> -Original Message-
>>> From: Michael Trimarchi [mailto:trimar...@gandalf.sssup.it]
>>> Sent: Fri 3/20/2009 9:36 AM
>>> To: Rendine Francesco
>>> Cc: u-boot@lists.denx.de
>>> Subject: Re: [U-Boot] USB EHCI driver
>>>
>>> Hi,
>>>
>>> FrancescoVT wrote:
>>>   
 usb_control_msg: request: 0x6, requesttype: 0x80, value 
 
>> 0x100 index 
>> 
 0x0 length 0x40 dev=1ffebb08, pipe=8883, buffer=1f9a671a, 
 length=64, req=1ffea214
 req=6 (0x6), type=128 (0x80), value=256 (0x100), index=0 
 
>> EHCI fail 
>> 
 timeout STD_ASS reset
 usb_new_device: usb_get_descriptor() failed
  
 
>>> #define CONFIG_LEGACY_USB_INIT_SEQ
>>>
>>> Michael
>>>
>>>
>>>
>>>   
>> Sorry I can't help you without the board :( and now I don't 
>> have another board to test to verify it. I'm working on 
>> android, and some migor issue.
>>
>> Michael
>> ___
>> U-Boot mailing list
>> U-Boot@lists.denx.de
>> http://lists.denx.de/mailman/listinfo/u-boot
>>
>>
>> 
>
>   
I don't ask anymore because I'm busy, BTW good question

Michael
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Which U-Boot releases have Device Tree support

[Wolfgang Denk]

Dear Peter Barada,

In message <1239250418.4414.72.ca...@blackhole> you wrote:
> On Wed, 2009-04-08 at 22:40 -0400, cmfai...@rockwellcollins.com wrote:
> > We bought a MPC8360E-RDK development kit to develop applications under 
> > MontaVista CGE5.0. We were toldby the consultant whose doing our board LSP 
> > that the U-Boot version that came with the development kit did not have 
> > device tree support. The consultant upgraded the U-Boot to a version that 
> > has device tree support, but he says he doesn't have the source code for 
> > the U-Boot version. I need the source to make certain updates.
> > 
> > Which U-Boot version can I download that has device tree support?
> 
> If you've registered your MPC8360E-RDK with Logic, you should be able to
> login to the Logic website and download the entire LTIB source that
> includes a version of u-boot with full source/patches that fully support
> dealing with device tree binary (dtb) files, and also includes a kernel
> for the MPC8360E-RDK, and the build process generates an appropriate
> device tree binary for the board...

On the other hand there is zero reason to stick with such an
out-of-tree port when the board is supported in mainline.

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
Conquest is easy. Control is not.
-- Kirk, "Mirror, Mirror", stardate unknown
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] use of C99

[Wolfgang Denk]

Dear Pink Boy,

In message <139940.41801...@web31807.mail.mud.yahoo.com> you wrote:
> 
> Um...  my feeling is that if one is going to declare a variable
> inside a #ifdef then that variable ought to be called something
> like
> 
>   int indx_CONFIG_COOL_FEATURE
> 
> and
> 
>   u32 indx_CONFIG_HOT_FEATURE

Then please read the Coding Style about how to chose variable names.

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
Imitation is the sincerest form of plagarism.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Interrupt handlers in u-boot

[prathika]

hi,
Thanks for that reply.I am right away checking those functions 
install_hdlr() and free_hdlr()..will get back about the results in few 
minutes..

Thanks & Regards,
Prathika R

Stefan Roese wrote:
> On Wednesday 08 April 2009, prathika wrote:
>> I am working on u-boot 1.1.6 version for PowerPC 440.
> 
> First of all. v1.1.6 is really old. I suggest that you use the current 
> (latest) version instead.
> 
>> I am using the 
>> hello world application from the examples folder.
>> I had no issues in loading and executing it.
>> Now I have enabled SPI interrupt in the application. I have written for
>> SPI loopback.
>> My issue is, as there is no interrupt handler defined for the SPI in
>> uboot, whenever i execute my application,
>> it says "Masking bogus interrupt for Vector 0x08". I am calling
>> "install_irq_handler" function for assigning my own interrupt handler
>> for SPI as part of my application itself.
>> I can understand that, there is no exclusive handler for SPI in uboot,
>> so it is disabling the SPI interrupt and printing the BOGUS INTERRUPT
>> message.
>> Now how do I get rid of this and have my own interrupt handler??
> 
> You just need to install you "own" interrupt handler. This is done via 
> install_hdlr(). See examples/interrupt.c.
> 
> Best regards,
> Stefan
> 
> =
> DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: off...@denx.de
> =
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] USB EHCI driver

[Gupta Maneesh-B18878]

Hi Francesco,

Could you make any progress?

Regards
Maneesh
 

> -Original Message-
> From: u-boot-boun...@lists.denx.de 
> [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Michael Trimarchi
> Sent: Monday, March 23, 2009 2:46 PM
> To: Rendine Francesco
> Cc: u-boot@lists.denx.de
> Subject: Re: [U-Boot] USB EHCI driver
> 
> Hi,
> 
> Rendine Francesco wrote:
> >
> > Hi,
> >
> > I've already tried that define, but nothing is changed...
> > What can I see in the USB driver to resolve issue?
> >
> > Thanks.
> >
> > -Original Message-
> > From: Michael Trimarchi [mailto:trimar...@gandalf.sssup.it]
> > Sent: Fri 3/20/2009 9:36 AM
> > To: Rendine Francesco
> > Cc: u-boot@lists.denx.de
> > Subject: Re: [U-Boot] USB EHCI driver
> >
> > Hi,
> >
> > FrancescoVT wrote:
> > > usb_control_msg: request: 0x6, requesttype: 0x80, value 
> 0x100 index 
> > > 0x0 length 0x40 dev=1ffebb08, pipe=8883, buffer=1f9a671a, 
> > > length=64, req=1ffea214
> > > req=6 (0x6), type=128 (0x80), value=256 (0x100), index=0 
> EHCI fail 
> > > timeout STD_ASS reset
> > > usb_new_device: usb_get_descriptor() failed
> > >  
> > #define CONFIG_LEGACY_USB_INIT_SEQ
> >
> > Michael
> >
> >
> >
> Sorry I can't help you without the board :( and now I don't 
> have another board to test to verify it. I'm working on 
> android, and some migor issue.
> 
> Michael
> ___
> 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] use of C99

[Kumar Gala]

I'm glad to see I started this week's flame thread :)

- k
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Which U-Boot releases have Device Tree support

[Kumar Gala]

On Apr 8, 2009, at 11:13 PM, Peter Barada wrote:

> On Wed, 2009-04-08 at 22:40 -0400, cmfai...@rockwellcollins.com wrote:
>> We bought a MPC8360E-RDK development kit to develop applications  
>> under
>> MontaVista CGE5.0. We were toldby the consultant whose doing our  
>> board LSP
>> that the U-Boot version that came with the development kit did not  
>> have
>> device tree support. The consultant upgraded the U-Boot to a  
>> version that
>> has device tree support, but he says he doesn't have the source  
>> code for
>> the U-Boot version. I need the source to make certain updates.
>>
>> Which U-Boot version can I download that has device tree support?
>
> If you've registered your MPC8360E-RDK with Logic, you should be  
> able to
> login to the Logic website and download the entire LTIB source that
> includes a version of u-boot with full source/patches that fully  
> support
> dealing with device tree binary (dtb) files, and also includes a  
> kernel
> for the MPC8360E-RDK, and the build process generates an appropriate
> device tree binary for the board...

Additionally any recent u-boot (v2009.03) and kernel (v2.6.29) have in  
tree support for the RDK board.

- k
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Which U-Boot releases have Device Tree support

[Peter Barada]

On Wed, 2009-04-08 at 22:40 -0400, cmfai...@rockwellcollins.com wrote:
> We bought a MPC8360E-RDK development kit to develop applications under 
> MontaVista CGE5.0. We were toldby the consultant whose doing our board LSP 
> that the U-Boot version that came with the development kit did not have 
> device tree support. The consultant upgraded the U-Boot to a version that 
> has device tree support, but he says he doesn't have the source code for 
> the U-Boot version. I need the source to make certain updates.
> 
> Which U-Boot version can I download that has device tree support?

If you've registered your MPC8360E-RDK with Logic, you should be able to
login to the Logic website and download the entire LTIB source that
includes a version of u-boot with full source/patches that fully support
dealing with device tree binary (dtb) files, and also includes a kernel
for the MPC8360E-RDK, and the build process generates an appropriate
device tree binary for the board...

-- 
Peter Barada 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 3/3] smc911x: do net reset the chip if no EEPROM is connected

[Mike Frysinger]

On Wednesday 08 April 2009 20:08:38 Daniel Mack wrote:
> On Wed, Apr 08, 2009 at 06:00:40PM -0400, Mike Frysinger wrote:
> > On Wednesday 08 April 2009 07:23:39 Daniel Mack wrote:
> > > On boards without EEPROMs, don't reset the chip on U-Boot's exit so
> > > that the MAC set by environment settings can be used by the OS later.
> >
> > that isnt how the MAC is passed to the OS ... this change is incorrect
> >
> > the OS must be able to get the MAC address regardless of the state of the
> > network controller
>
> Not if the MAC is stored in the volatile smc911x registers. Issuing a
> soft reset flushes these values - if U-Boot does that, the OS has no
> change getting them.

then either your u-boot or your OS is misconfigured and you need to fix that.  
as clearly stated in docs/README.enetaddr, the environment is the place where 
mac addresses live when there is no dedicated storage (like an eeprom).

ignoring that, the mac address doesnt magically get programmed.  if no network 
operation was initiated, then the part wouldnt have been programmed anyways, 
so you're still left with an OS that cant get itself functional.

> That's what I saw here and it is also stated in the datasheet.

sounds like the driver and hardware is operating correctly then
-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] Which U-Boot releases have Device Tree support

[Jerry Van Baren]

cmfai...@rockwellcollins.com wrote:
> We bought a MPC8360E-RDK development kit to develop applications under 
> MontaVista CGE5.0. We were toldby the consultant whose doing our board LSP 
> that the U-Boot version that came with the development kit did not have 
> device tree support. The consultant upgraded the U-Boot to a version that 
> has device tree support, but he says he doesn't have the source code for 
> the U-Boot version. I need the source to make certain updates.
> 
> Which U-Boot version can I download that has device tree support?
> 
> Thanks.

Hi Christopher,

The tip of the tree is the best.  The mpc8360erdk is supported.  If you 
want a released version, the latest is v2009.03.
   

Best regards,
gvb
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Which U-Boot releases have Device Tree support

[cmfairfa]

We bought a MPC8360E-RDK development kit to develop applications under 
MontaVista CGE5.0. We were toldby the consultant whose doing our board LSP 
that the U-Boot version that came with the development kit did not have 
device tree support. The consultant upgraded the U-Boot to a version that 
has device tree support, but he says he doesn't have the source code for 
the U-Boot version. I need the source to make certain updates.

Which U-Boot version can I download that has device tree support?

Thanks.



Christopher M. Fairfax
Sr. Software Engineer
Rockwell Collins
+1 540-428-3344
+1 540-428-3301
cmfai...@rockwellcollins.com
This message contains PRIVILEGED AND PROPRIETARY INFORMATION intended 
solely for the use of the addressee(s) named above.  Any disclosure, 
distribution, copying or use of the information by others is strictly 
prohibited.  If you have received this message in error, please advise the 
sender by immediate reply and delete the original message.  Thank you. ___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] use of C99

[Jerry Van Baren]

Pink Boy wrote:

[snip]

> Pops out of hole, looks at shadow, 6 more weeks till we ship...
> 
> Um...  my feeling is that if one is going to declare a variable
> inside a #ifdef then that variable ought to be called something
> like
> 
>   int indx_CONFIG_COOL_FEATURE
> 
> and
> 
>   u32 indx_CONFIG_HOT_FEATURE
> 
> Matt Harper
> Tehama Wireless

Ewww.  Quoting from Documentation/CodingStyle:


 Chapter 4: Naming

C is a Spartan language, and so should your naming be.  Unlike Modula-2
and Pascal programmers, C programmers do not use cute names like
ThisVariableIsATemporaryCounter.  A C programmer would call that
variable "tmp", which is much easier to write, and not the least more
difficult to understand.

[snip]

LOCAL variable names should be short, and to the point.  If you have
some random integer loop counter, it should probably be called "i".
Calling it "loop_counter" is non-productive, if there is no chance of it
being mis-understood.  Similarly, "tmp" can be just about any type of
variable that is used to hold a temporary value.

If you are afraid to mix up your local variable names, you have another
problem, which is called the function-growth-hormone-imbalance syndrome.
See chapter 6 (Functions).


Best regards,
gvb
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] use of C99

[Pink Boy]

Premi, Sanjeev sez,

> I was referring to declaring variable within #ifdefs with
> belief that
> use will be contained.
> 
> e.g.
> #ifdef CONFIG_COOL_FEATURE
>  int i;
>   int* ptr ;
>   ...
>   ...
> #endif
> 
> ...
> ... 2 screenful down; in same function...
> ...
> 
> #ifdef CONFIG_HOT_FEATURE
>  u32 i;
>   void* ptr;
>   ...
>   ...
> #endif
> 
> Maybe for sometime the usage seems contained. Until someone
> decides to have both the COOL and HOT feature.

Pops out of hole, looks at shadow, 6 more weeks till we ship...

Um...  my feeling is that if one is going to declare a variable
inside a #ifdef then that variable ought to be called something
like

  int indx_CONFIG_COOL_FEATURE

and

  u32 indx_CONFIG_HOT_FEATURE

Matt Harper
Tehama Wireless

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 3/3] smc911x: do net reset the chip if no EEPROM is connected

[Daniel Mack]

On Wed, Apr 08, 2009 at 06:00:40PM -0400, Mike Frysinger wrote:
> On Wednesday 08 April 2009 07:23:39 Daniel Mack wrote:
> > On boards without EEPROMs, don't reset the chip on U-Boot's exit so that
> > the MAC set by environment settings can be used by the OS later.
> 
> that isnt how the MAC is passed to the OS ... this change is incorrect
> 
> the OS must be able to get the MAC address regardless of the state of the 
> network controller

Not if the MAC is stored in the volatile smc911x registers. Issuing a
soft reset flushes these values - if U-Boot does that, the OS has no
change getting them.

That's what I saw here and it is also stated in the datasheet.

Daniel

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] use of C99

[Scott Wood]

Larry Johnson wrote:
> Kumar Gala wrote:
>> I was wondering if there was any reason we avoid C99 features in u- 
>> boot source.
> 
> Maybe the best reason is that the Linux kernel avoids them, 

Linux has a lot more inertia than a smaller project such as u-boot.

> and staying consistent with the Linux coding style saves a lot of time and
> headaches.  IMO, this is worth the occasional clumsiness that results.

Code seems to flow from Linux to u-boot more than the reverse -- I don't 
see much of a problem with being more permissive.

> BTW, the Linux kernel does not avoid all C99 features.  For example, it
> relies heavily on named initialization of structs.  However, AFAICT, it
> shuns those C99 feature that originated in C++.

I suspect that has more to do with people's feelings toward C++ than any 
  unbiased assessment of the merits of the features.

-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] use of C99

[Larry Johnson]

Kumar Gala wrote:
> I was wondering if there was any reason we avoid C99 features in u- 
> boot source.

Maybe the best reason is that the Linux kernel avoids them, and staying
consistent with the Linux coding style saves a lot of time and
headaches.  IMO, this is worth the occasional clumsiness that results.

BTW, the Linux kernel does not avoid all C99 features.  For example, it
relies heavily on named initialization of structs.  However, AFAICT, it
shuns those C99 feature that originated in C++.

Best regards,
Larry



___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2] Marvell MV88E61XX Switch Driver support

[Ben Warren]

Hi Prafulla,
Prafulla Wadaskar wrote:
> Chips supprted:-
> 1. 88E6161 6 port gbe swtich with 5 integrated PHYs
> 2. 88E6165 6 port gbe swtich with 5 integrated PHYs
> Note: This driver is supported and tested against
> kirkwood egiga interface, other interfaces can be added
>
> Contributors:
> Yotam Admon 
> Michael Blostein 
> Reviewed by: Ronen Shitrit 
> Signed-off-by: Prafulla Wadaskar 
> ---
> Changelog:-
> v2: updated as per review comments by Wolfgand Denk
> removed other two drivers form earlier patch
> debug_prints removed
> driver moved to drivers/net/
>  
>  drivers/net/Makefile|1 +
>  drivers/net/mv88e61xx.c |  291 
> +++
>  2 files changed, 292 insertions(+), 0 deletions(-)
>  create mode 100644 drivers/net/mv88e61xx.c
>
> diff --git a/drivers/net/Makefile b/drivers/net/Makefile
> index f0c5654..7482327 100644
> --- a/drivers/net/Makefile
> +++ b/drivers/net/Makefile
> @@ -47,6 +47,7 @@ COBJS-$(CONFIG_MACB) += macb.o
>  COBJS-$(CONFIG_MCFFEC) += mcffec.o mcfmii.o
>  COBJS-$(CONFIG_MPC5xxx_FEC) += mpc5xxx_fec.o
>  COBJS-$(CONFIG_MPC512x_FEC) += mpc512x_fec.o
> +COBJS-$(CONFIG_SWITCH_MV88E61XX) += mv88e61xx.o
>   
Please change this to CONFIG_MV88E61XX_SWITCH
>  COBJS-$(CONFIG_NATSEMI) += natsemi.o
>  COBJS-$(CONFIG_DRIVER_NE2000) += ne2000.o ne2000_base.o
>  COBJS-$(CONFIG_DRIVER_AX88796L) += ax88796.o ne2000_base.o
> diff --git a/drivers/net/mv88e61xx.c b/drivers/net/mv88e61xx.c
> new file mode 100644
> index 000..8167919
> --- /dev/null
> +++ b/drivers/net/mv88e61xx.c
> @@ -0,0 +1,291 @@
> +/*
> + * (C) Copyright 2009
> + * Marvell Semiconductor 
> + * Prafulla Wadaskar 
> + *
> + * 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., 51 Franklin Street, Fifth Floor, Boston,
> + * MA 02110-1301 USA
> + */
> +
> +#include 
> +
> +#if defined (CONFIG_SWITCH_MV88E61XX)
>   
This is not needed - the makefile takes care of the conditional compilation
> +
> +/* Enabled ports can be enabled in board header file */
> +#if defined (CONFIG_MV88E61XX_ENABLED_PORTS)
> +#define MV88E61XX_ENABLED_PORTS CONFIG_MV88E61XX_ENABLED_PORTS
> +#else
> +#define MV88E61XX_ENABLED_PORTS (BIT0 | BIT1 | BIT2 | \
> + BIT3 | BIT4 | BIT5)
> +#endif
> +
> +#if defined (CONFIG_88E6161)
> +#define MV88E61XX_NAME   "88E6161"
> +#elif defined (CONFIG_88E6165)
> +#define MV88E61XX_NAME   "88E6165"
> +#else
> +#define MV88E61XX_NAME   "88E61XX"
> +#endif
> +
>   
There doesn't appear to be any code difference between the different 
chips.  What's the point of differentiating them here?  If it is 
meaningful, you should at least #warning if none of the known-about 
variants is mentioned.
> +#define MV88E61XX_PHY_TIMEOUT10
> +#define MV88E61XX_MAX_PORTS_NUM  0x6
> +/* CPU port can be configured in board header file */
> +#if defined (CONFIG_MV88E61XX_CPU_PORT)
> +#define MV88E61XX_CPU_PORT   CONFIG_MV88E61XX_CPU_PORT
> +#else
> +#define MV88E61XX_CPU_PORT   0x5
> +#endif
> +
> +#define MV88E61XX_PRT_STS_REG0x1
> +#define MV88E61XX_PRT_CTRL_REG   0x4
> +#define MV88E61XX_PRT_VMAP_REG   0x6
> +#define MV88E61XX_PRT_VID_REG0x7
> +
> +#define MV88E61XX_PRT_OFST   0x10
> +#define MV88E61XX_PHY_CMD0x18
> +#define MV88E61XX_PHY_DATA   0x19
> +#define MV88E61XX_GLOBAL2_REG_DEVADR 0x1C
> +
> +#ifdef CONFIG_KIRKWOOD_EGIGA
> +#define smi_wr_reg   eth_smi_reg_write
> +#define smi_rd_reg   eth_smi_reg_read
> +#else /* add new interface above this */
> +#error Unsupported interface
> +#endif
> +
>   
Please find a better way to do this.  Board-specific code doesn't belong 
in a driver.
> +/* Chip Address mode
> + * The Switch support two modes of operation
> + * 1. single chip mode and
> + * 2. Multi-chip mode
> + * Refer chip documentation for more details
> + *
> + * By default single chip mode is configured
> + * multichip mode operation can be configured in board header
> + */
> +#ifndef CONFIG_MV88E61XX_MULTICHIP_ADRMODE
> +#define mv88e61xx_wr_phy smi_wr_reg
> +#define mv88e61xx_rd_phy smi_rd_reg
> +#else
> +void mv88e61xx_wr_phy(u32 port, u32 phy_adr, u3

Re: [U-Boot] [PATCH v2] Marvell MV88E61XX Switch Driver support

[Andy Fleming]

On Wed, Apr 8, 2009 at 1:30 PM, Prafulla Wadaskar  wrote:
> --- /dev/null
> +++ b/drivers/net/mv88e61xx.c
> @@ -0,0 +1,291 @@
> +/*
> + * (C) Copyright 2009
> + * Marvell Semiconductor 
> + * Prafulla Wadaskar 
> + *
> + * 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., 51 Franklin Street, Fifth Floor, Boston,
> + * MA 02110-1301 USA
> + */
> +
> +#include 
> +
> +#if defined (CONFIG_SWITCH_MV88E61XX)
> +
> +/* Enabled ports can be enabled in board header file */
> +#if defined (CONFIG_MV88E61XX_ENABLED_PORTS)
> +#define MV88E61XX_ENABLED_PORTS CONFIG_MV88E61XX_ENABLED_PORTS
> +#else
> +#define MV88E61XX_ENABLED_PORTS (BIT0 | BIT1 | BIT2 | \
> +                                 BIT3 | BIT4 | BIT5)
> +#endif
> +
> +#if defined (CONFIG_88E6161)
> +#define MV88E61XX_NAME                 "88E6161"
> +#elif defined (CONFIG_88E6165)
> +#define MV88E61XX_NAME                 "88E6165"
> +#else
> +#define MV88E61XX_NAME                 "88E61XX"
> +#endif


Is this discoverable at runtime?  What if there's a system that
supports using multiple different types of MV88E61xx?  I know it's a
bit of a crazy idea, but board designers like to screw around with
software developers like that.


> +
> +#define MV88E61XX_PHY_TIMEOUT          10
> +#define MV88E61XX_MAX_PORTS_NUM                0x6

Is this a limitation of the 88e61xx architecture, or just the max
number on all of the currently shipping versions?

> +
> +#ifdef CONFIG_KIRKWOOD_EGIGA
> +#define smi_wr_reg     eth_smi_reg_write
> +#define smi_rd_reg     eth_smi_reg_read
> +#else /* add new interface above this */
> +#error Unsupported interface
> +#endif

This sort of thing is discouraged.  Why does this driver need to know
about the ethernet controller?  Perhaps function pointers are needed?

Andy
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] use of C99

[Scott Wood]

Wolfgang Denk wrote:
> Dear Timur Tabi,
> 
> In message <49dd290a.9010...@freescale.com> you wrote:
>> It's like complaining to someone who has a car that you only have a
>> bicycle and you have to commute 20 miles to get to work.  The person who
>> has a car is obviously going to tell you that your life will be easier
>> if you get a car also.
> 
> The person with the bicycle might ask you  why  you  require  him  to
> contribute  to air pollution and climate changes and all these things
> when you could as well put the target he has to reach just 200 meters
> from his home. Not everything that can be done is a good thing to do.

Indeed, having the variable declaration close by to where it's used 
*does* make things easier. :-)

-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] use of C99

[Wolfgang Denk]

Dear Timur Tabi,

In message <49dd290a.9010...@freescale.com> you wrote:
> 
> It's like complaining to someone who has a car that you only have a
> bicycle and you have to commute 20 miles to get to work.  The person who
> has a car is obviously going to tell you that your life will be easier
> if you get a car also.

The person with the bicycle might ask you  why  you  require  him  to
contribute  to air pollution and climate changes and all these things
when you could as well put the target he has to reach just 200 meters
from his home. Not everything that can be done is a good thing to do.

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
Computers are not intelligent.  They only think they are.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] use of C99

[Timur Tabi]

Graeme Russ wrote:

> What if _MY_ favourite editor doesn't. 

The point I'm trying to make is that I have tools at my disposal that
make certain tasks easier for me, allowing me to alter my coding style
and get the best of both worlds.

> Or what if I don't have access to
> it because I'm looking at the code at work, or on a friends computer?

Then it will be more difficult for you.  I have this problem sometimes.
 That's why I try to avoid using another tool as much as possible.

It's like complaining to someone who has a car that you only have a
bicycle and you have to commute 20 miles to get to work.  The person who
has a car is obviously going to tell you that your life will be easier
if you get a car also.

-- 
Timur Tabi
Linux kernel developer at Freescale
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] use of C99

[Graeme Russ]

On Thu, Apr 9, 2009 at 7:38 AM, Timur Tabi  wrote:
> Wolfgang Denk wrote:
>
>> Bear with an old man like me. I am used to the habit that variables
>> get decleared at the begin of a block, not in the middle of it. When
>> searching for the declaration of a variable, I find it a major PITA if
>> I have to scan the whole source file instea dof just looking at the
>> first few lines of a block.

I'll second that

>
> This is why I use an advanced programmer's editor that brings me to the
> definition of the variable under the cursor with a single keystroke.
>

What if _MY_ favourite editor doesn't. Or what if I don't have access to
it because I'm looking at the code at work, or on a friends computer?

>> Not the compiler, but humans like me. I have just a small  window  of
>> lines  I  can  really  focus  on,  and  the  smaller  a block of code
>> (including the needed variable declarations), the easier  I  get  the
>> impression I understand it.

That is the key - half the time #ifdef COOL_FEATURE in the middle of a
function really means that the feature needs to be put in another
function

>
> In this case, it would be easier for you if the variable were declared
> next to the code that uses it.

True and correct, but it can often be done so in another function

>
>>> This is what we do today, and I think it's ugly.
>>
>> It is ugly, but much less ugly than variable declarations right in the
>> middle of 200 lines of code.

200 lines of code is much more ugly


Regards,

Graeme
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2] Marvell MV88E61XX Switch Driver support

[Wolfgang Denk]

Dear Andrew Dyer,

In message  you 
wrote:
>
> > v2: updated as per review comments by Wolfgand Denk
> 
> It's always good to spell the name of the guy with commit access right :-)

He. I'm not Russell King.

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 is a test of the Emergency Broadcast System. If this had been an
actual emergency, do you really think we'd stick around to tell you?"
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2] Marvell MV88E61XX Switch Driver support

[Andrew Dyer]

On Wed, Apr 8, 2009 at 1:30 PM, Prafulla Wadaskar  wrote:
> Chips supprted:-
> 1. 88E6161 6 port gbe swtich with 5 integrated PHYs
> 2. 88E6165 6 port gbe swtich with 5 integrated PHYs
> Note: This driver is supported and tested against
> kirkwood egiga interface, other interfaces can be added

We are going to be using this chip in a project, so I'm happy to see
this code come by :-)  A few comments sprinkled around below.

>
> Contributors:
> Yotam Admon 
> Michael Blostein 
> Reviewed by: Ronen Shitrit 
> Signed-off-by: Prafulla Wadaskar 
> ---
> Changelog:-
> v2: updated as per review comments by Wolfgand Denk

It's always good to spell the name of the guy with commit access right :-)

> removed other two drivers form earlier patch
> debug_prints removed
> driver moved to drivers/net/
>
>  drivers/net/Makefile    |    1 +
>  drivers/net/mv88e61xx.c |  291 
> +++
>  2 files changed, 292 insertions(+), 0 deletions(-)
>  create mode 100644 drivers/net/mv88e61xx.c
>
> diff --git a/drivers/net/Makefile b/drivers/net/Makefile
> index f0c5654..7482327 100644
> --- a/drivers/net/Makefile
> +++ b/drivers/net/Makefile
> @@ -47,6 +47,7 @@ COBJS-$(CONFIG_MACB) += macb.o
>  COBJS-$(CONFIG_MCFFEC) += mcffec.o mcfmii.o
>  COBJS-$(CONFIG_MPC5xxx_FEC) += mpc5xxx_fec.o
>  COBJS-$(CONFIG_MPC512x_FEC) += mpc512x_fec.o
> +COBJS-$(CONFIG_SWITCH_MV88E61XX) += mv88e61xx.o
>  COBJS-$(CONFIG_NATSEMI) += natsemi.o
>  COBJS-$(CONFIG_DRIVER_NE2000) += ne2000.o ne2000_base.o
>  COBJS-$(CONFIG_DRIVER_AX88796L) += ax88796.o ne2000_base.o
> diff --git a/drivers/net/mv88e61xx.c b/drivers/net/mv88e61xx.c
> new file mode 100644
> index 000..8167919
> --- /dev/null
> +++ b/drivers/net/mv88e61xx.c
> @@ -0,0 +1,291 @@
> +/*
> + * (C) Copyright 2009
> + * Marvell Semiconductor 
> + * Prafulla Wadaskar 
> + *
> + * 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., 51 Franklin Street, Fifth Floor, Boston,
> + * MA 02110-1301 USA
> + */
> +
> +#include 
> +
> +#if defined (CONFIG_SWITCH_MV88E61XX)
> +
> +/* Enabled ports can be enabled in board header file */
> +#if defined (CONFIG_MV88E61XX_ENABLED_PORTS)
> +#define MV88E61XX_ENABLED_PORTS CONFIG_MV88E61XX_ENABLED_PORTS
> +#else
> +#define MV88E61XX_ENABLED_PORTS (BIT0 | BIT1 | BIT2 | \
> +                                 BIT3 | BIT4 | BIT5)
> +#endif
> +
> +#if defined (CONFIG_88E6161)
> +#define MV88E61XX_NAME                 "88E6161"
> +#elif defined (CONFIG_88E6165)
> +#define MV88E61XX_NAME                 "88E6165"
> +#else
> +#define MV88E61XX_NAME                 "88E61XX"
> +#endif
> +
> +#define MV88E61XX_PHY_TIMEOUT          10
> +#define MV88E61XX_MAX_PORTS_NUM                0x6
> +/* CPU port can be configured in board header file */
> +#if defined (CONFIG_MV88E61XX_CPU_PORT)
> +#define MV88E61XX_CPU_PORT             CONFIG_MV88E61XX_CPU_PORT
> +#else
> +#define MV88E61XX_CPU_PORT             0x5
> +#endif
> +
> +#define MV88E61XX_PRT_STS_REG          0x1
> +#define MV88E61XX_PRT_CTRL_REG         0x4
> +#define MV88E61XX_PRT_VMAP_REG         0x6
> +#define MV88E61XX_PRT_VID_REG          0x7
> +
> +#define MV88E61XX_PRT_OFST             0x10
> +#define MV88E61XX_PHY_CMD              0x18
> +#define MV88E61XX_PHY_DATA             0x19
> +#define MV88E61XX_GLOBAL2_REG_DEVADR   0x1C
> +
> +#ifdef CONFIG_KIRKWOOD_EGIGA
> +#define smi_wr_reg     eth_smi_reg_write
> +#define smi_rd_reg     eth_smi_reg_read
> +#else /* add new interface above this */
> +#error Unsupported interface
> +#endif

As far as I understand it, "SMI" for the 88E6161 is really just the
physical MII layer with some changes in the register definitions.
Would it not make more sense to use the existing u-boot miiphy code in
common/miiphyutil.c to define the access functions?  This allows for
platform code to register mii access functions and gets platform
specific stuff like this out of the driver.

> +
> +/* Chip Address mode
> + * The Switch support two modes of operation
> + * 1. single chip mode and
> + * 2. Multi-chip mode
> + * Refer chip documentation for more details
> + *
> + * By default single chip mode is configured
> + * multichip mode operation can be configured in board header
> + */
> +#ifndef CONFIG_MV88E61XX_MULTICHIP_ADRMODE
> +#define 

Re: [U-Boot] use of C99

[Scott Wood]

Wolfgang Denk wrote:
> It is ugly, but much less ugly than variable declarations right in the
> middle of 200 lines of code.

200-line functions are ugly no matter what variable declaration style 
you use. :-)

-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] use of C99

[Scott Wood]

Timur Tabi wrote:
> Scott Wood wrote:
> 
>> It frees the variable up for later such blocks to use.  As does 
>> declaring iterators inside a for loop, but I guess that's forbidden as 
>> well. :-)
> 
> I'm not sure whether we want to allow the same variable to be defined
> more than once, even with the same type, inside a function.

What's wrong with this:?

for (i = 0; i < n; i++) {
int j;
...
}

for (i = 0; i < m; i++) {
int j;
...
}

>> Chances are it will allocate all stack space for all variables up front, 
>> regardless of where they're declared.
> 
> Yes, but it many cases it won't allocate any stack space at all because
> it will just keep the variable in a register.  My point was that if a
> variable is defined later in a function, then it's more likely to have
> limited scope, so the compiler will be more likely to use a register
> instead of stack to store it.

I don't think it will make a difference.  The compiler knows what the 
lifetime of the variable is, regardless of where you declare it.

-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 3/3] smc911x: do net reset the chip if no EEPROM is connected

[Mike Frysinger]

On Wednesday 08 April 2009 07:23:39 Daniel Mack wrote:
> On boards without EEPROMs, don't reset the chip on U-Boot's exit so that
> the MAC set by environment settings can be used by the OS later.

that isnt how the MAC is passed to the OS ... this change is incorrect

the OS must be able to get the MAC address regardless of the state of the 
network controller
-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] Multiple device support -- sorry state :(

[ksi]

On Wed, 8 Apr 2009, Robert Schwebel wrote:

> On Wed, Apr 08, 2009 at 02:25:57PM -0700, k...@koi8.net wrote:
> > > OK, thanks. Cloning now :)
> > 
> > OK, got a look at it. Looks promising but it is in very early stage
> yet... I
> > wouldn't say in pre-conception stage, but definitely on a very
> beginning of
> > the first trimester :)
> 
> Well, you are free to send patches. We use it mainly for ARM systems
> which happen to be flash based (NAND, NOR), without PCI. So what was
> implemented was what we needed. No reason for you not to send us your
> favourite and fancy new features :-)

Sure I will :) Ah, ARM, my old love, still remeber that talk -- ldmia,
stmfd... Romantic times, eh...

> > I have the first prototype of MPC8548E-based big motherboard sitting
> > on my desk right now and it is in full bringup stage. All the hardware
> > is checked, bunch of smoked parts replaced and fixed, all clocks are
> > ticking, CPU fetching etc.
> > 
> > I will definitely join V2 development but for now I'll probably make a
> > huge set of horrible hacks over V1 to test everything and get my
> > revision 2 started. Then I will be able to work on U-Boot V2 while my
> > revision 2 is made (schematic rework, re-layout, PCB, missing parts
> > sourcing, assembly etc.)
> 
> Go ahead, we definitely are looking forward to more community
> contribution.

OK, I probably will. V1, IMHO, is beyond repair; I even contemplated forking
off my own...

---
**
*  k...@homeKOI8 Net  < >  The impossible we do immediately.  *
*  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
**
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2] Marvell MV88F6281GTW_GE Board support

[Mike Frysinger]

On Wednesday 08 April 2009 12:18:11 Prafulla Wadaskar wrote:
> From: prafulla_wadaskar 

this part should be fixed as well
-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] use of C99

[Timur Tabi]

Wolfgang Denk wrote:

> Bear with an old man like me. I am used to the habit that variables
> get decleared at the begin of a block, not in the middle of it. When
> searching for the declaration of a variable, I find it a major PITA if
> I have to scan the whole source file instea dof just looking at the
> first few lines of a block.

This is why I use an advanced programmer's editor that brings me to the
definition of the variable under the cursor with a single keystroke.

> Not the compiler, but humans like me. I have just a small  window  of
> lines  I  can  really  focus  on,  and  the  smaller  a block of code
> (including the needed variable declarations), the easier  I  get  the
> impression I understand it.

In this case, it would be easier for you if the variable were declared
next to the code that uses it.

>> This is what we do today, and I think it's ugly.
> 
> It is ugly, but much less ugly than variable declarations right in the
> middle of 200 lines of code.

This is where I disagree.

-- 
Timur Tabi
Linux kernel developer at Freescale
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Multiple device support -- sorry state :(

[Robert Schwebel]

On Wed, Apr 08, 2009 at 02:25:57PM -0700, k...@koi8.net wrote:
> > OK, thanks. Cloning now :)
> 
> OK, got a look at it. Looks promising but it is in very early stage yet... I
> wouldn't say in pre-conception stage, but definitely on a very beginning of
> the first trimester :)

Well, you are free to send patches. We use it mainly for ARM systems
which happen to be flash based (NAND, NOR), without PCI. So what was
implemented was what we needed. No reason for you not to send us your
favourite and fancy new features :-)

> I have the first prototype of MPC8548E-based big motherboard sitting
> on my desk right now and it is in full bringup stage. All the hardware
> is checked, bunch of smoked parts replaced and fixed, all clocks are
> ticking, CPU fetching etc.
> 
> I will definitely join V2 development but for now I'll probably make a
> huge set of horrible hacks over V1 to test everything and get my
> revision 2 started. Then I will be able to work on U-Boot V2 while my
> revision 2 is made (schematic rework, re-layout, PCB, missing parts
> sourcing, assembly etc.)

Go ahead, we definitely are looking forward to more community
contribution.

rsc
-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] use of C99

[Timur Tabi]

Premi, Sanjeev wrote:

> Maybe for sometime the usage seems contained. Until someone decides to have
> both the COOL and HOT feature.

And that's why I said that U-Boot can allow in-function variable
declarations, but all variables must have unique names.  The only
exception to that rule can be variables declared at the top of iterators.

That's just my two cents.

-- 
Timur Tabi
Linux kernel developer at Freescale
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] use of C99

[Wolfgang Denk]

Dear Timur Tabi,

In message  you 
wrote:
> 
> I don't see what's wrong with that.  The advantage is that the
> variable is close to where it's being used, so that you can see the
> context more easily.

Bear with an old man like me. I am used to the habit that variables
get decleared at the begin of a block, not in the middle of it. When
searching for the declaration of a variable, I find it a major PITA if
I have to scan the whole source file instea dof just looking at the
first few lines of a block.

> I don't see what the value is of limiting the lifetime of the
> variable.  The compiler isn't going to use that as a hint, anyway.

Not the compiler, but humans like me. I have just a small  window  of
lines  I  can  really  focus  on,  and  the  smaller  a block of code
(including the needed variable declarations), the easier  I  get  the
impression I understand it.

> It's just going to use this for syntax checking.  If you define and
> initialize a variable at the top of the function, but don't use that
> variable until a hundred lines later, the compiler is going to
> initialize the variable when it's first used, not when the function is
> first entered.  Chances are it's not even going to define stack space
> for it.

Keep in mind that we don't write the code for the compiler, but for
the human being that comes after us and that has to maintain that
code.

> > #ifdef CONFIG_COOL_FEATURE
> >{
> >u32 myvarrocks = foo * bar * bar;
> >
> >gd->neato = myvarrocks
> >}
> > #endif
> >
> > Is this an acceptable compromise?
>
> This is what we do today, and I think it's ugly.

It is ugly, but much less ugly than variable declarations right in the
middle of 200 lines of code.

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
At the source of every error which is blamed on the computer you will
find at least two human errors, including the error of blaming it  on
the computer.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] use of C99

[Wolfgang Denk]

Dear Jerry Van Baren,

In message <49dcff1d.6080...@ge.com> you wrote:
> 
> If I'm not confused, I've seen block-local u-boot variables, has the 
> advantages of being more distinctive and limits the lifetime of the 
> variable.
> 
> #ifdef CONFIG_COOL_FEATURE
>   {
>   u32 myvarrocks = foo * bar * bar;
> 
>   gd->neato = myvarrocks
>   }
> #endif
> 
> Is this an acceptable compromise?

Yes, if really necessary, this can be done.

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
Of all the things I've lost, I miss my mind the most.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] use of C99

[Premi, Sanjeev]

> -Original Message-
> From: Ben Warren [mailto:biggerbadder...@gmail.com] 
> Sent: Thursday, April 09, 2009 2:33 AM
> To: Premi, Sanjeev
> Cc: Timur Tabi; Jerry Van Baren; U-Boot-Users ML; Kumar Gala
> Subject: Re: [U-Boot] use of C99
> 
> Premi, Sanjeev wrote:
> >> -Original Message-
> >> From: u-boot-boun...@lists.denx.de 
> >> [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Timur Tabi
> >> Sent: Thursday, April 09, 2009 1:55 AM
> >> To: Jerry Van Baren
> >> Cc: U-Boot-Users ML; Kumar Gala
> >> Subject: Re: [U-Boot] use of C99
> >>
> >> On Wed, Apr 8, 2009 at 2:46 PM, Jerry Van Baren 
> >>  wrote:
> >>
> >> 
> >>> ACK.  I don't expect to see variables spring into life in 
> >>>   
> >> the middle of
> >> 
> >>> nowhere.
> >>>   
> >> I don't see what's wrong with that.  The advantage is that the
> >> variable is close to where it's being used, so that you can see the
> >> context more easily.
> >>
> >> 
> >>> If I'm not confused, I've seen block-local u-boot 
> variables, has the
> >>> advantages of being more distinctive and limits the 
> lifetime of the
> >>> variable.
> >>>   
> >> I don't see what the value is of limiting the lifetime of the
> >> variable.  The compiler isn't going to use that as a hint, anyway.
> >> It's just going to use this for syntax checking.  If you define and
> >> initialize a variable at the top of the function, but 
> don't use that
> >> variable until a hundred lines later, the compiler is going to
> >> initialize the variable when it's first used, not when the 
> function is
> >> first entered.  Chances are it's not even going to define 
> stack space
> >> for it. 
> >> 
> >
> > One of the biggest problem is uncontrolled variable definitions that
> > gets even nasty when variables have same names with different types;
> > though under different set of #ifdefs. Quite possible for commonly
> > used variable names - i, ptr, tmp, etc.
> >
> >   
> I'm showing extreme ignorance here, but does C99 let you do this?
> 
> for (int i = 0; i < x ; i++) ?

That's much better contained than declaring in a ifdef. 

> Doing a lot of C++ has rotted my brain, but this is one thing I like.

I love C++; still avoid declare as you go.
Iterators (as you mention above) are only exception.

~sanjeev
> 
> regards,
> Ben
> 
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] use of C99

[Premi, Sanjeev]

> -Original Message-
> From: Timur Tabi [mailto:ti...@freescale.com] 
> Sent: Thursday, April 09, 2009 2:28 AM
> To: Premi, Sanjeev
> Cc: Jerry Van Baren; U-Boot-Users ML; Kumar Gala
> Subject: Re: [U-Boot] use of C99
> 
> Premi, Sanjeev wrote:
> 
> > One of the biggest problem is uncontrolled variable definitions that
> > gets even nasty when variables have same names with different types;
> > though under different set of #ifdefs. Quite possible for commonly
> > used variable names - i, ptr, tmp, etc.
> 
> Then let's just say that if you're going to define a variable in the
> middle of a function, it can't have the same name as another 
> variable in
> that function.
> 
> > I feel, here, ifdefs provide a false sense of 'enclosure' 
> with possibility
> > of frequent breaches - in code (while implementing) and in 
> simple reading 
> > (for understanding).
> 
> Sorry, I don't understand what you're talking about.  The #ifdefs are
> used to enable feature-specific code on platforms that have 
> that feature.

I was referring to declaring variable within #ifdefs with belief that
use will be contained.

e.g.
#ifdef CONFIG_COOL_FEATURE
int i;
  int* ptr ;
  ...
  ...
#endif

...
... 2 screenful down; in same function...
...

#ifdef CONFIG_HOT_FEATURE
u32 i;
  void* ptr;
  ...
  ...
#endif

Maybe for sometime the usage seems contained. Until someone decides to have
both the COOL and HOT feature.

~sanjeev
> 
> -- 
> Timur Tabi
> Linux kernel developer at Freescale
> 
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Multiple device support -- sorry state :(

[ksi]

On Wed, 8 Apr 2009, k...@koi8.net wrote:

> On Wed, 8 Apr 2009, Robert Schwebel wrote:
> 
> > On Wed, Apr 08, 2009 at 01:18:45PM -0700, k...@koi8.net wrote:
> > > > I suppose you didn't look in the right place. We don't even have
> > support
> > > > for i2c and spi in v2 :-)
> > >
> > > Ah, that's that forked one! Sorry, my bad... I thought about the new
> > version
> > > of a legacy one that just shuffled source files to put device
> drivers
> > under
> > > devices/*...
> > >
> > > Can you tell me where it lives to clone the repository? I'd rather
> > give up
> > > on v1 entirely because it is not going anywhere...
> > 
> > git clone git://www.denx.de/git/u-boot-v2
> > 
> > > Do you have a separate mailing list for v2?
> > 
> > No, just use this one. As long as the traffic keeps low, I suppose
> there
> > is no need for a separate list. However, it's probably a good idea to
> > have Sascha on Cc: :-)
> 
> OK, thanks. Cloning now :)

OK, got a look at it. Looks promising but it is in very early stage yet... I
wouldn't say in pre-conception stage, but definitely on a very beginning of
the first trimester :)

I have the first prototype of MPC8548E-based big motherboard sitting on my
desk right now and it is in full bringup stage. All the hardware is checked,
bunch of smoked parts replaced and fixed, all clocks are ticking, CPU
fetching etc.

I will definitely join V2 development but for now I'll probably make a huge
set of horrible hacks over V1 to test everything and get my revision 2
started. Then I will be able to work on U-Boot V2 while my revision 2 is
made (schematic rework, re-layout, PCB, missing parts sourcing, assembly
etc.)

---
**
*  k...@homeKOI8 Net  < >  The impossible we do immediately.  *
*  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
**
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Multiple device support -- sorry state :(

[ksi]

On Wed, 8 Apr 2009, Robert Schwebel wrote:

> On Wed, Apr 08, 2009 at 01:18:45PM -0700, k...@koi8.net wrote:
> > > I suppose you didn't look in the right place. We don't even have
> support
> > > for i2c and spi in v2 :-)
> >
> > Ah, that's that forked one! Sorry, my bad... I thought about the new
> version
> > of a legacy one that just shuffled source files to put device drivers
> under
> > devices/*...
> >
> > Can you tell me where it lives to clone the repository? I'd rather
> give up
> > on v1 entirely because it is not going anywhere...
> 
> git clone git://www.denx.de/git/u-boot-v2
> 
> > Do you have a separate mailing list for v2?
> 
> No, just use this one. As long as the traffic keeps low, I suppose there
> is no need for a separate list. However, it's probably a good idea to
> have Sascha on Cc: :-)

OK, thanks. Cloning now :)

---
**
*  k...@homeKOI8 Net  < >  The impossible we do immediately.  *
*  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
**
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] use of C99

[Ben Warren]

Premi, Sanjeev wrote:
>> -Original Message-
>> From: u-boot-boun...@lists.denx.de 
>> [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Timur Tabi
>> Sent: Thursday, April 09, 2009 1:55 AM
>> To: Jerry Van Baren
>> Cc: U-Boot-Users ML; Kumar Gala
>> Subject: Re: [U-Boot] use of C99
>>
>> On Wed, Apr 8, 2009 at 2:46 PM, Jerry Van Baren 
>>  wrote:
>>
>> 
>>> ACK.  I don't expect to see variables spring into life in 
>>>   
>> the middle of
>> 
>>> nowhere.
>>>   
>> I don't see what's wrong with that.  The advantage is that the
>> variable is close to where it's being used, so that you can see the
>> context more easily.
>>
>> 
>>> If I'm not confused, I've seen block-local u-boot variables, has the
>>> advantages of being more distinctive and limits the lifetime of the
>>> variable.
>>>   
>> I don't see what the value is of limiting the lifetime of the
>> variable.  The compiler isn't going to use that as a hint, anyway.
>> It's just going to use this for syntax checking.  If you define and
>> initialize a variable at the top of the function, but don't use that
>> variable until a hundred lines later, the compiler is going to
>> initialize the variable when it's first used, not when the function is
>> first entered.  Chances are it's not even going to define stack space
>> for it. 
>> 
>
> One of the biggest problem is uncontrolled variable definitions that
> gets even nasty when variables have same names with different types;
> though under different set of #ifdefs. Quite possible for commonly
> used variable names - i, ptr, tmp, etc.
>
>   
I'm showing extreme ignorance here, but does C99 let you do this?

for (int i = 0; i < x ; i++) ?

Doing a lot of C++ has rotted my brain, but this is one thing I like.

regards,
Ben
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] use of C99

[Timur Tabi]

Scott Wood wrote:

> It frees the variable up for later such blocks to use.  As does 
> declaring iterators inside a for loop, but I guess that's forbidden as 
> well. :-)

I'm not sure whether we want to allow the same variable to be defined
more than once, even with the same type, inside a function.

> Chances are it will allocate all stack space for all variables up front, 
> regardless of where they're declared.

Yes, but it many cases it won't allocate any stack space at all because
it will just keep the variable in a register.  My point was that if a
variable is defined later in a function, then it's more likely to have
limited scope, so the compiler will be more likely to use a register
instead of stack to store it.

>> This is what we do today, and I think it's ugly.
> 
> Yes.  But not as ugly as having two #ifdef blocks.

Agreed, but I don't consider it to be much of a compromise.

-- 
Timur Tabi
Linux kernel developer at Freescale
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] use of C99

[Timur Tabi]

Premi, Sanjeev wrote:

> One of the biggest problem is uncontrolled variable definitions that
> gets even nasty when variables have same names with different types;
> though under different set of #ifdefs. Quite possible for commonly
> used variable names - i, ptr, tmp, etc.

Then let's just say that if you're going to define a variable in the
middle of a function, it can't have the same name as another variable in
that function.

> I feel, here, ifdefs provide a false sense of 'enclosure' with possibility
> of frequent breaches - in code (while implementing) and in simple reading 
> (for understanding).

Sorry, I don't understand what you're talking about.  The #ifdefs are
used to enable feature-specific code on platforms that have that feature.

-- 
Timur Tabi
Linux kernel developer at Freescale
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] use of C99

[Scott Wood]

Timur Tabi wrote:
> On Wed, Apr 8, 2009 at 2:46 PM, Jerry Van Baren  
> wrote:
> 
>> ACK.  I don't expect to see variables spring into life in the middle of
>> nowhere.
> 
> I don't see what's wrong with that.  The advantage is that the
> variable is close to where it's being used, so that you can see the
> context more easily.

Agreed.  In many cases it reduces clutter by eliminating the need for 
separate declaration and assignment.

> I don't see what the value is of limiting the lifetime of the
> variable. 

It frees the variable up for later such blocks to use.  As does 
declaring iterators inside a for loop, but I guess that's forbidden as 
well. :-)

> It's just going to use this for syntax checking.  If you define and
> initialize a variable at the top of the function, but don't use that
> variable until a hundred lines later, the compiler is going to
> initialize the variable when it's first used, not when the function is
> first entered.  Chances are it's not even going to define stack space
> for it.

Chances are it will allocate all stack space for all variables up front, 
regardless of where they're declared.

>> #ifdef CONFIG_COOL_FEATURE
>>{
>>u32 myvarrocks = foo * bar * bar;
>>
>>gd->neato = myvarrocks
>>}
>> #endif
>>
>> Is this an acceptable compromise?
> 
> This is what we do today, and I think it's ugly.

Yes.  But not as ugly as having two #ifdef blocks.

-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] use of C99

[Premi, Sanjeev]

> -Original Message-
> From: u-boot-boun...@lists.denx.de 
> [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Timur Tabi
> Sent: Thursday, April 09, 2009 1:55 AM
> To: Jerry Van Baren
> Cc: U-Boot-Users ML; Kumar Gala
> Subject: Re: [U-Boot] use of C99
> 
> On Wed, Apr 8, 2009 at 2:46 PM, Jerry Van Baren 
>  wrote:
> 
> > ACK.  I don't expect to see variables spring into life in 
> the middle of
> > nowhere.
> 
> I don't see what's wrong with that.  The advantage is that the
> variable is close to where it's being used, so that you can see the
> context more easily.
> 
> > If I'm not confused, I've seen block-local u-boot variables, has the
> > advantages of being more distinctive and limits the lifetime of the
> > variable.
> 
> I don't see what the value is of limiting the lifetime of the
> variable.  The compiler isn't going to use that as a hint, anyway.
> It's just going to use this for syntax checking.  If you define and
> initialize a variable at the top of the function, but don't use that
> variable until a hundred lines later, the compiler is going to
> initialize the variable when it's first used, not when the function is
> first entered.  Chances are it's not even going to define stack space
> for it. 

One of the biggest problem is uncontrolled variable definitions that
gets even nasty when variables have same names with different types;
though under different set of #ifdefs. Quite possible for commonly
used variable names - i, ptr, tmp, etc.

I feel, here, ifdefs provide a false sense of 'enclosure' with possibility
of frequent breaches - in code (while implementing) and in simple reading 
(for understanding).

~sanjeev

> > #ifdef CONFIG_COOL_FEATURE
> >        {
> >                u32 myvarrocks = foo * bar * bar;
> >
> >                gd->neato = myvarrocks
> >        }
> > #endif
> >
> > Is this an acceptable compromise?
> 
> This is what we do today, and I think it's ugly.
> 
> -- 
> Timur Tabi
> Linux kernel developer at Freescale
> ___
> 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] Multiple device support -- sorry state :(

[Robert Schwebel]

On Wed, Apr 08, 2009 at 01:18:45PM -0700, k...@koi8.net wrote:
> > I suppose you didn't look in the right place. We don't even have support
> > for i2c and spi in v2 :-)
>
> Ah, that's that forked one! Sorry, my bad... I thought about the new version
> of a legacy one that just shuffled source files to put device drivers under
> devices/*...
>
> Can you tell me where it lives to clone the repository? I'd rather give up
> on v1 entirely because it is not going anywhere...

git clone git://www.denx.de/git/u-boot-v2

> Do you have a separate mailing list for v2?

No, just use this one. As long as the traffic keeps low, I suppose there
is no need for a separate list. However, it's probably a good idea to
have Sascha on Cc: :-)

rsc
-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Query: console.c

[Premi, Sanjeev]

Hi,

While browsing common/console.c, I found 2 banners:

-  U-Boot INITIAL CONSOLE-NOT COMPATIBLE FUNCTIONS
-  U-Boot INITIAL CONSOLE-COMPATIBLE FUNCTION

What does this indicate?

One first pass, I also appeared that some functionality is duplicated
e.g. serial_puts, puts, serial_printf, printf, et.

Is there a specific reason for it?

Best regards,
Sanjeev
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] use of C99

[Timur Tabi]

On Wed, Apr 8, 2009 at 2:46 PM, Jerry Van Baren  wrote:

> ACK.  I don't expect to see variables spring into life in the middle of
> nowhere.

I don't see what's wrong with that.  The advantage is that the
variable is close to where it's being used, so that you can see the
context more easily.

> If I'm not confused, I've seen block-local u-boot variables, has the
> advantages of being more distinctive and limits the lifetime of the
> variable.

I don't see what the value is of limiting the lifetime of the
variable.  The compiler isn't going to use that as a hint, anyway.
It's just going to use this for syntax checking.  If you define and
initialize a variable at the top of the function, but don't use that
variable until a hundred lines later, the compiler is going to
initialize the variable when it's first used, not when the function is
first entered.  Chances are it's not even going to define stack space
for it.

> #ifdef CONFIG_COOL_FEATURE
>        {
>                u32 myvarrocks = foo * bar * bar;
>
>                gd->neato = myvarrocks
>        }
> #endif
>
> Is this an acceptable compromise?

This is what we do today, and I think it's ugly.

-- 
Timur Tabi
Linux kernel developer at Freescale
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Multiple device support -- sorry state :(

[ksi]

On Wed, 8 Apr 2009, Robert Schwebel wrote:

> On Wed, Apr 08, 2009 at 12:25:16PM -0700, k...@koi8.net wrote:
> > On Wed, 8 Apr 2009, Jerry Van Baren wrote:
> > 
> > > k...@koi8.net wrote:
> > > > OK, this is _NOT_ just multiple I2C adapters... The entire thing
> is
> > > > fundamentally broken.
> > > > 
> > > > One supposed to have _THE_ device and only this device is somehow
> > > supported.
> > > > 
> > > > Now it is USB. Each and every USB driver exports the same set of
> > > functions,
> > > > submit_XXX_msg(...) That means there can be one and only one USB
> > > device in
> > > > the system.
> > > 
> > > [snip the badly scorched spot ;-)]
> > > 
> > > > USB keyboard is another grand kludge deserving its own chapter...
> As
> > > of now
> > > > one can only switch to it from command line because USB is not
> even
> > > > initialized until do_usb() from cmd_usb.c is called... What if we
> do
> > > NOT
> > > > have a serial console at all?
> > > 
> > > Dumb question because I have not looked seriously at the v2 fork of
> > > u-boot:
> > > how does the v2 fork handle this?  Better?  Since the v2 fork uses
> (or
> > > is
> > > close to) the linux driver model, I would expect it to be better.
> > 
> > Nothing's changed here...
> > 
> > And that is _NOT_ just USB, it is everywhere -- I2C, SPI, etc. It is
> stiff,
> > inflexible, everything written in stone and that stone is permanently
> set in
> > concrete.
> 
> I suppose you didn't look in the right place. We don't even have support
> for i2c and spi in v2 :-)

Ah, that's that forked one! Sorry, my bad... I thought about the new version
of a legacy one that just shuffled source files to put device drivers under
devices/*...

Can you tell me where it lives to clone the repository? I'd rather give up
on v1 entirely because it is not going anywhere...

Do you have a separate mailing list for v2?

---
**
*  k...@homeKOI8 Net  < >  The impossible we do immediately.  *
*  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
**
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Multiple device support -- sorry state :(

[Robert Schwebel]

On Wed, Apr 08, 2009 at 12:25:16PM -0700, k...@koi8.net wrote:
> On Wed, 8 Apr 2009, Jerry Van Baren wrote:
> 
> > k...@koi8.net wrote:
> > > OK, this is _NOT_ just multiple I2C adapters... The entire thing is
> > > fundamentally broken.
> > > 
> > > One supposed to have _THE_ device and only this device is somehow
> > supported.
> > > 
> > > Now it is USB. Each and every USB driver exports the same set of
> > functions,
> > > submit_XXX_msg(...) That means there can be one and only one USB
> > device in
> > > the system.
> > 
> > [snip the badly scorched spot ;-)]
> > 
> > > USB keyboard is another grand kludge deserving its own chapter... As
> > of now
> > > one can only switch to it from command line because USB is not even
> > > initialized until do_usb() from cmd_usb.c is called... What if we do
> > NOT
> > > have a serial console at all?
> > 
> > Dumb question because I have not looked seriously at the v2 fork of
> > u-boot:
> > how does the v2 fork handle this?  Better?  Since the v2 fork uses (or
> > is
> > close to) the linux driver model, I would expect it to be better.
> 
> Nothing's changed here...
> 
> And that is _NOT_ just USB, it is everywhere -- I2C, SPI, etc. It is stiff,
> inflexible, everything written in stone and that stone is permanently set in
> concrete.

I suppose you didn't look in the right place. We don't even have support
for i2c and spi in v2 :-)

rsc
-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Multiple device support -- sorry state :(

[Robert Schwebel]

Hi Jerry,

On Wed, Apr 08, 2009 at 03:19:19PM -0400, Jerry Van Baren wrote:
> k...@koi8.net wrote:
> > OK, this is _NOT_ just multiple I2C adapters... The entire thing is
> > fundamentally broken.
> >
> > One supposed to have _THE_ device and only this device is somehow supported.
> >
> > Now it is USB. Each and every USB driver exports the same set of functions,
> > submit_XXX_msg(...) That means there can be one and only one USB device in
> > the system.
>
> [snip the badly scorched spot ;-)]
>
> > USB keyboard is another grand kludge deserving its own chapter... As of now
> > one can only switch to it from command line because USB is not even
> > initialized until do_usb() from cmd_usb.c is called... What if we do NOT
> > have a serial console at all?
>
> Dumb question because I have not looked seriously at the v2 fork of
> u-boot: how does the v2 fork handle this? Better? Since the v2 fork
> uses (or is close to) the linux driver model, I would expect it to be
> better.

Right, we use something close to the driver model, so no problem with
that in v2 land. Other than linux, we have per-device parameters.

Example, with a freshly checked out tree:

  r...@thebe:u-boot-v2$ make sandbox_defconfig
  r...@thebe:u-boot-v2$ make
  r...@thebe:u-boot-v2$ ./scripts/ubootenv -s -p 0x1 examples/environment/ 
env.bin

That gets you an u-boot-v2 (user mode u-boot) plus the example
environment.

Let's start it:

  r...@thebe:u-boot-v2-denx$ ./uboot -e env.bin
  add file env.bin()


  U-Boot 2.0.0-rc8-00084-g97568fd (Apr  8 2009 - 21:54:30)

  Board: sandbox
  Malloc space: 0xb761f008 -> 0xb7e1f008 (size  8 MB)
  Open /dev/env0 Function not implemented
  running /env/bin/init...
  not found
  uboot:/

Let's check which devices we have:

  uboot:/ devinfo
  devices:
  |env0
  |console0
  |mem
  |eth0
  |filesystem: /
  |filesystem: /dev

  drivers:
 console
   cfi_flash
 mem
 ram
 rom
  cramfs
   ramfs
   devfs
hostfile

Let's check what parameters are there:

  uboot:/ devinfo /dev/console0
  base  : 0x
  size  : 0x
  driver: console

  no info available for console0
  Parameters:
active = ioe

So you can have as many devices as you want, plus each device has parameters
attached to it, so it's completely object oriented, without any global variable
crap.

rsc
-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] use of C99

[Jerry Van Baren]

Hi Wolfgang,

Wolfgang Denk wrote:
> Dear Kumar Gala,
> 
> In message <4a0b9aaa-4714-4c27-84a7-22fce4d91...@freescale.com> you wrote:
>> I was wondering if there was any reason we avoid C99 features in u- 
>> boot source.
>>
>> Specifically the ability to declare variables in the middle of  
>> functions.
> 
> One reason is that I consider such code extremely ugly and hard to
> read and understand.

ACK.  I don't expect to see variables spring into life in the middle of 
nowhere.

>> There are a slew of places that we have something like:
> ...
>> #ifdef CONFIG_COOL_FEATURE
>>  u32 myvarrocks = foo * bar * bar;
>>
>>  gd->neato = myvarrocks
>> #endif
> 
> It would be even better to avoid such #ifdef's, or at least the need
> for such special local variables.

Sometimes (often?) that is impossible.

> Best regards,
> 
> Wolfgang Denk

If I'm not confused, I've seen block-local u-boot variables, has the 
advantages of being more distinctive and limits the lifetime of the 
variable.

#ifdef CONFIG_COOL_FEATURE
{
u32 myvarrocks = foo * bar * bar;

gd->neato = myvarrocks
}
#endif

Is this an acceptable compromise?

Best regards,
gvb
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] use of C99

[Wolfgang Denk]

Dear Kumar Gala,

In message <4a0b9aaa-4714-4c27-84a7-22fce4d91...@freescale.com> you wrote:
> I was wondering if there was any reason we avoid C99 features in u- 
> boot source.
> 
> Specifically the ability to declare variables in the middle of  
> functions.

One reason is that I consider such code extremely ugly and hard to
read and understand.

> There are a slew of places that we have something like:
...
> #ifdef CONFIG_COOL_FEATURE
>   u32 myvarrocks = foo * bar * bar;
> 
>   gd->neato = myvarrocks
> #endif

It would be even better to avoid such #ifdef's, or at least the need
for such special local variables.

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
Life is a process, not a principle, a mystery  to  be  lived,  not  a
problem to be solved. - Gerard Straub, television producer and author
(stolen from Frank Herbert??)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Multiple device support -- sorry state :(

[ksi]

On Wed, 8 Apr 2009, Jerry Van Baren wrote:

> k...@koi8.net wrote:
> > OK, this is _NOT_ just multiple I2C adapters... The entire thing is
> > fundamentally broken.
> > 
> > One supposed to have _THE_ device and only this device is somehow
> supported.
> > 
> > Now it is USB. Each and every USB driver exports the same set of
> functions,
> > submit_XXX_msg(...) That means there can be one and only one USB
> device in
> > the system.
> 
> [snip the badly scorched spot ;-)]
> 
> > USB keyboard is another grand kludge deserving its own chapter... As
> of now
> > one can only switch to it from command line because USB is not even
> > initialized until do_usb() from cmd_usb.c is called... What if we do
> NOT
> > have a serial console at all?
> 
> Dumb question because I have not looked seriously at the v2 fork of
> u-boot:
> how does the v2 fork handle this?  Better?  Since the v2 fork uses (or
> is
> close to) the linux driver model, I would expect it to be better.

Nothing's changed here...

And that is _NOT_ just USB, it is everywhere -- I2C, SPI, etc. It is stiff,
inflexible, everything written in stone and that stone is permanently set in
concrete.

---
**
*  k...@homeKOI8 Net  < >  The impossible we do immediately.  *
*  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
**
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Data cache breaks U-Boot on ARM

[Wolfgang Denk]

Dear Drasko,

in message <5ec3d7930904080854k2db159d3rc889ce80a8d0b...@mail.gmail.com> you 
wrote:
>
> > Umm... is it correct to assume that you do not use USB on your system
> > (resp. did not test USB yet) ?
> 
> It is corrrect, no USB used.

Do you have USB on your board, so you can test it? I'm interested  if
USB  still  works  for you with DCache on. Our experience is that you
either have caches on *or* working USB on ARM, but this might be just
a single case, so I'm interestedin other experiences.

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
Heavier than air flying machines are impossible.
-- Lord Kelvin, President, Royal Society, c. 1895
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Multiple device support -- sorry state :(

[Jerry Van Baren]

k...@koi8.net wrote:
> OK, this is _NOT_ just multiple I2C adapters... The entire thing is
> fundamentally broken.
> 
> One supposed to have _THE_ device and only this device is somehow supported.
> 
> Now it is USB. Each and every USB driver exports the same set of functions,
> submit_XXX_msg(...) That means there can be one and only one USB device in
> the system.

[snip the badly scorched spot ;-)]

> USB keyboard is another grand kludge deserving its own chapter... As of now
> one can only switch to it from command line because USB is not even
> initialized until do_usb() from cmd_usb.c is called... What if we do NOT
> have a serial console at all?

Dumb question because I have not looked seriously at the v2 fork of 
u-boot: how does the v2 fork handle this?  Better?  Since the v2 fork 
uses (or is close to) the linux driver model, I would expect it to be 
better.

Best regards,
gvb
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Multiple device support -- sorry state :(

[ksi]

OK, this is _NOT_ just multiple I2C adapters... The entire thing is
fundamentally broken.

One supposed to have _THE_ device and only this device is somehow supported.

Now it is USB. Each and every USB driver exports the same set of functions,
submit_XXX_msg(...) That means there can be one and only one USB device in
the system.

Let's take e.g. widely used ISP1563 PCI USB controller. It has _TWO_ OHCI
controllers. Existing usb_ohci.c code only supports one. That means that one
can only use odd numbered ports (1 and 3) for any USB devices. Ports 2 and 4
are not usable at all. Not just together with odd numbered ones but even
_INSTEAD_ of those.

But wait, there is more... This very same controller also has a 4-port EHCI
controller for USB 2.0 support. This is not supported at all because
usb_ehci_pci.c is a mere stub that does NOT support _ANY_ PCI EHCI
controller. But it would not do any good if it did support ISP1563 -- there
should be one and only one USB controller, _THE_ USB controller... EHCI
driver, usb_ehci_core.c exports exactly the same submit_XXX_msg() set of
function so it can _NOT_ coexist with anything else.

So what's the choice? Let's say we somehow made that usb_ehci_pci.c stub in
a real driver and got ISP1563 (or _ANY_ other USB2.0 PCI adapter) recognized
and initialized. This hypothetically gives us all 4 ports because all 4 are
supported by EHCI vs. only 2 by OHCI. Would it do any good? The answer is
_NO_.

EHCI does _NOT_ support slower USB1.X ports so one can _NOT_ hook his e.g.
USB keyboard to EHCI controller. It is only for hi-speed devices. USB2.0
controller actually consists of an EHCI and set of slower USB1.X controllers
that share the same USB pins. If a connected device supports high speed,
EHCI is used. If it does NOT support high speed, driver should made EHCI
controller to give up ownership of that particular USB port to OHCI (or
whatever it is) and pass control to OHCI driver. That is how USB works.

Now we suddenly have _THREE_ USB controllers while our software only
supports one. And that is _NOT_ some exotic situation with multiple chips or
other strange design -- e.g. MPC8548 does NOT have a built-in USB controller
so I added a single PCI chip to provide for a USB interface.

One can recommend using only the first OHCI controller in U-Boot somehow
tolerating it being painfully slow with storage devices etc. and limited
with what ports can be used but that is also _NOT_ a solution... OHCI only
allows for 2 ports and in our case they are both already used (KBD + MOUSE.)
Sure we don't need a mouse in U-Boot but we _DO_ need it to be connected
anyways because we boot full-blown Fedora with X that uses mouse. That means
we do NOT have any USB ports available for storage or anything else...

USB keyboard is another grand kludge deserving its own chapter... As of now
one can only switch to it from command line because USB is not even
initialized until do_usb() from cmd_usb.c is called... What if we do NOT
have a serial console at all?

Grrr...

---
**
*  k...@homeKOI8 Net  < >  The impossible we do immediately.  *
*  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
**
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] use of C99

[Kumar Gala]

I was wondering if there was any reason we avoid C99 features in u- 
boot source.

Specifically the ability to declare variables in the middle of  
functions.

There are a slew of places that we have something like:

foobar()
{
...

#ifdef CONFIG_COOL_FEATURE
u32 myvarrocks;
#endif

...

#ifdef CONFIG_COOL_FEATURE
myvarrocks = foo * bar * bar;

gd->neato = myvarrocks
#endif


it would be nice to just have:

foobar()
{

...

#ifdef CONFIG_COOL_FEATURE
u32 myvarrocks = foo * bar * bar;

gd->neato = myvarrocks
#endif

- k
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [resolved] UBIFS - Reading superblock error

[DATACOM - Mallmann]

Stefan Roese wrote:
> Hi Marcelo,
>
> On Tuesday 31 March 2009, DATACOM - Mallmann wrote:
>   
>> I'm trying to use UBI and UBIFS over a nand device. I want to create a
>> mtd partition in u-boot (with ubi part command), save a ubifs image
>> (with mkfs.ubifs), mount and load it with ubifs commands.
>> 
>
> The easiest way to write an UBIFS image in U-Boot is to generate an UBI image 
> with includes the UBIFS volume. This is done after "mkfs.ubifs" using 
> the "ubinize" command. This creates an UBI image which can be written to 
> FLASH via the "normal" commands ("cp.b" for NOR, "nand write" for NAND).
>
> Here a link for some background:
>
> http://www.linux-mtd.infradead.org/faq/ubifs.html#L_mkfubifs
>
> 
>
>   
>> By
>> the way, is a volume created in u-boot able to be used in linux kernel
>> in read-write mode?
>> 
>
> Sure. You can write an UBIFS image in U-Boot and use it read-only here. And 
> later in Linux you can mount it read-write and write to it. Next time in 
> U-Boot you will see the changes.
>
> Best regards,
> Stefan
>
> =
> DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: off...@denx.de
> =
>
>   
Hi Stefan,

Thanks a lot for the tip. It works fine and pretty fast, like I
expected. =D

-- 
Marcelo MALLMANN Dias

DATACOM
Av.França,735-Porto Alegre,RS-90230-220
Fone 3358.1332
Fax  3358.0101
Site: www.datacom.ind.br
e-mail: mallm...@datacom.ind.br

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] dtb merge

[Jerry Van Baren]

Hi Andre,

Andre Schwarz wrote:
> Any ideas on how to merge device tree binaries from slave devices ?
> 
> Having a PowerPC based board with various extension boards on e.g. the 
> local bus with each board having some kind of PROM device (I2C, SPI 
> etc.) containing a dtb ... is it possible to merge this into the 
> existing boards dtb into the local bus node ?

Yes.

> Is it already working - have I missed it ?

No - no.

> If not - is someone thinking/working on it ?

We have thought about it, nobody is working on it that I am aware of.

> Any suggestions on how to do it ?

See limited thoughts in
   

4. Proposed additional fdt commands

 * merge - merge two trees. Need a conflict resolution: source tree 
#1 has priority?
   o David Gibson has talked about creating a "graft" function 
for libfdt.

Link to David's "graft" function thoughts:
   


> Regards,
> 
> Andre

Best regards,
gvb
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] dtb merge

[Andre Schwarz]

Any ideas on how to merge device tree binaries from slave devices ?

Having a PowerPC based board with various extension boards on e.g. the 
local bus with each board having some kind of PROM device (I2C, SPI 
etc.) containing a dtb ... is it possible to merge this into the 
existing boards dtb into the local bus node ?

Is it already working - have I missed it ?

If not - is someone thinking/working on it ?

Any suggestions on how to do it ?



Regards,

Andre

MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschäftsführer: 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

Re: [U-Boot] Data cache breaks U-Boot on ARM

[Drasko DRASKOVIC]

On Wed, Apr 8, 2009 at 5:00 PM, Wolfgang Denk  wrote:

> Great. Maybe you want to post your patches so others can benefit from
> that acchievement, too?

It will be my pleasure, so I will take a look how can I make a usefull patch
as soon as I clean the code.

>
> Umm... is it correct to assume that you do not use USB on your system
> (resp. did not test USB yet) ?

It is corrrect, no USB used.

Best Regards,
Drasko DRASKOVIC
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Data cache breaks U-Boot on ARM

[Wolfgang Denk]

Dear Drasko,

in message <5ec3d7930904080651g5328ad12g3df2f28ae340...@mail.gmail.com> you 
wrote:
>
> Thank you very much for your time and help. With the pointers and examples
> you gave I corrected the code (it was problem of DCaching perpiheral device
> registers region, as you pointed out), and now it works fine and fast (after
> more than one week of torture)!

Great. Maybe you want to post your patches so others can benefit from
that acchievement, too?

Umm... is it correct to assume that you do not use USB on your system
(resp. did not test USB yet) ?

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
Accident: A condition in which presence of mind is good, but  absence
of body is better.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Data cache breaks U-Boot on ARM

[Drasko DRASKOVIC]

On Wed, Apr 8, 2009 at 2:44 PM, Wolfgang Denk  wrote:

> Dear Drasko,
>
> >please post U-Boot related questions on the mailing list
>
>
Hi Wolfgang,
sorry for sending e-mail to your private adress, it was metter of "reply"
and not "reply to all". Sorry for the misstake.

>
> > Please see http://en.wikipedia.org/wiki/Memory_barrier

Thank you very much for your time and help. With the pointers and examples
you gave I corrected the code (it was problem of DCaching perpiheral device
registers region, as you pointed out), and now it works fine and fast (after
more than one week of torture)!

Best regards,
Drasko DRASKOVIC
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2] Marvell MV88E61XX Switch Driver support

[Prafulla Wadaskar]

Chips supprted:-
1. 88E6161 6 port gbe swtich with 5 integrated PHYs
2. 88E6165 6 port gbe swtich with 5 integrated PHYs
Note: This driver is supported and tested against
kirkwood egiga interface, other interfaces can be added

Contributors:
Yotam Admon 
Michael Blostein 
Signed-off-by: Prafulla Wadaskar 
---
Changelog:-
v2: updated as per review comments by Wolfgand Denk
removed other two drivers form earlier patch
debug_prints removed
driver moved to drivers/net/
 
 drivers/net/Makefile|1 +
 drivers/net/mv88e61xx.c |  291 +++
 2 files changed, 292 insertions(+), 0 deletions(-)
 create mode 100644 drivers/net/mv88e61xx.c

diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index f0c5654..7482327 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -47,6 +47,7 @@ COBJS-$(CONFIG_MACB) += macb.o
 COBJS-$(CONFIG_MCFFEC) += mcffec.o mcfmii.o
 COBJS-$(CONFIG_MPC5xxx_FEC) += mpc5xxx_fec.o
 COBJS-$(CONFIG_MPC512x_FEC) += mpc512x_fec.o
+COBJS-$(CONFIG_SWITCH_MV88E61XX) += mv88e61xx.o
 COBJS-$(CONFIG_NATSEMI) += natsemi.o
 COBJS-$(CONFIG_DRIVER_NE2000) += ne2000.o ne2000_base.o
 COBJS-$(CONFIG_DRIVER_AX88796L) += ax88796.o ne2000_base.o
diff --git a/drivers/net/mv88e61xx.c b/drivers/net/mv88e61xx.c
new file mode 100644
index 000..8167919
--- /dev/null
+++ b/drivers/net/mv88e61xx.c
@@ -0,0 +1,291 @@
+/*
+ * (C) Copyright 2009
+ * Marvell Semiconductor 
+ * Prafulla Wadaskar 
+ *
+ * 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., 51 Franklin Street, Fifth Floor, Boston,
+ * MA 02110-1301 USA
+ */
+
+#include 
+
+#if defined (CONFIG_SWITCH_MV88E61XX)
+
+/* Enabled ports can be enabled in board header file */
+#if defined (CONFIG_MV88E61XX_ENABLED_PORTS)
+#define MV88E61XX_ENABLED_PORTS CONFIG_MV88E61XX_ENABLED_PORTS
+#else
+#define MV88E61XX_ENABLED_PORTS (BIT0 | BIT1 | BIT2 | \
+ BIT3 | BIT4 | BIT5)
+#endif
+
+#if defined (CONFIG_88E6161)
+#define MV88E61XX_NAME "88E6161"
+#elif defined (CONFIG_88E6165)
+#define MV88E61XX_NAME "88E6165"
+#else
+#define MV88E61XX_NAME "88E61XX"
+#endif
+
+#define MV88E61XX_PHY_TIMEOUT  10
+#define MV88E61XX_MAX_PORTS_NUM0x6
+/* CPU port can be configured in board header file */
+#if defined (CONFIG_MV88E61XX_CPU_PORT)
+#define MV88E61XX_CPU_PORT CONFIG_MV88E61XX_CPU_PORT
+#else
+#define MV88E61XX_CPU_PORT 0x5
+#endif
+
+#define MV88E61XX_PRT_STS_REG  0x1
+#define MV88E61XX_PRT_CTRL_REG 0x4
+#define MV88E61XX_PRT_VMAP_REG 0x6
+#define MV88E61XX_PRT_VID_REG  0x7
+
+#define MV88E61XX_PRT_OFST 0x10
+#define MV88E61XX_PHY_CMD  0x18
+#define MV88E61XX_PHY_DATA 0x19
+#define MV88E61XX_GLOBAL2_REG_DEVADR   0x1C
+
+#ifdef CONFIG_KIRKWOOD_EGIGA
+#define smi_wr_reg eth_smi_reg_write
+#define smi_rd_reg eth_smi_reg_read
+#else /* add new interface above this */
+#error Unsupported interface
+#endif
+
+/* Chip Address mode
+ * The Switch support two modes of operation
+ * 1. single chip mode and
+ * 2. Multi-chip mode
+ * Refer chip documentation for more details
+ *
+ * By default single chip mode is configured
+ * multichip mode operation can be configured in board header
+ */
+#ifndef CONFIG_MV88E61XX_MULTICHIP_ADRMODE
+#define mv88e61xx_wr_phy smi_wr_reg
+#define mv88e61xx_rd_phy smi_rd_reg
+#else
+void mv88e61xx_wr_phy(u32 port, u32 phy_adr, u32 reg_ofs, u16 data)
+{
+   u16 reg;
+   u32 smi_dev_addr;
+
+   smi_dev_addr = KW_REG_READ(KW_ETH_PHY_ADDR_REG(port));
+   do {
+   smi_rd_reg(port, smi_dev_addr, 0x0, ®);
+   } while ((reg & BIT15));
+   /* Poll till SMIBusy bit is clear */
+   smi_wr_reg(port, smi_dev_addr, 0x1, data);
+   /* Write data to Switch indirect data register */
+   smi_wr_reg(port, smi_dev_addr, 0x0,
+  reg_ofs | (phy_adr << 5) | BIT10 | BIT12 | BIT15);
+   /* Write command to Switch indirect command register (write) */
+}
+
+void mv88e61xx_rd_phy(u32 port, u32 phy_adr, u32 reg_ofs, u16 * data)
+{
+   u16 reg;
+   u32 smi_dev_addr;
+
+   smi_dev_addr = KW_REG_READ(KW_ETH_PHY_ADDR_REG(port));
+   do {
+   smi_rd_reg(por

[U-Boot] Ping on Coldfire patch status

[Richard Retanubun]

Hi John,

Just wanted to ping on the status of the Coldfire patches I submitted, I 
noticed the submission window is closed on 2009.06 :)

http://www.nabble.com/-U-Boot---PATCH--Coldfire-M5271%3A-Activate-u-boot-system-timer-interrupt.-td22729407.html#a22729407
http://www.nabble.com/-U-Boot---PATCH--Coldfire%3A-interrupts%3A-Add-watchdog-auto-reset-to-dtimer_interrupt-td22629836.html#a22629836
http://www.nabble.com/-U-Boot---PATCH--Coldfire%3A-cleanup-compiler-warning-for-lib-m68k-unused-variables.-td22665336.html#a22665336
http://www.nabble.com/-U-Boot---PATCH--Coldfire%3A-I2C%3A-Update-I2CFDR-frequency-divider-0x0E-value-from-192-to-204-td22583796.html#a22583796

Thanks for your time

- Richard
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] porting u-boot and linux for ARM9 on WinXP

[ranjan.dash1]

Hi Guys,

I have few querries.

1> I want to port u-boot and linux for ARM9 architecture on Wndows XP.
is it possible?
2> If yes, please let me know how.
3> and also let me know which ARM toolchain I would use, and from where
I wud download the kernel source tree?
4> How to unzip on windows XP (tar,.bz2 files)

Kindly find some time for reolve it.

With Regards
Ranjan

Please do not print this email unless it is absolutely necessary.

The information contained in this electronic message and any attachments to 
this message are intended for the exclusive use of the addressee(s) and may 
contain proprietary, confidential or privileged information. If you are not the 
intended recipient, you should not disseminate, distribute or copy this e-mail. 
Please notify the sender immediately and destroy all copies of this message and 
any attachments.

WARNING: Computer viruses can be transmitted via email. The recipient should 
check this email and any attachments for the presence of viruses. The company 
accepts no liability for any damage caused by any virus transmitted by this 
email.

www.wipro.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Interrupt handlers in u-boot

[Stefan Roese]

On Wednesday 08 April 2009, prathika wrote:
> I am working on u-boot 1.1.6 version for PowerPC 440.

First of all. v1.1.6 is really old. I suggest that you use the current 
(latest) version instead.

> I am using the 
> hello world application from the examples folder.
> I had no issues in loading and executing it.
> Now I have enabled SPI interrupt in the application. I have written for
> SPI loopback.
> My issue is, as there is no interrupt handler defined for the SPI in
> uboot, whenever i execute my application,
> it says "Masking bogus interrupt for Vector 0x08". I am calling
> "install_irq_handler" function for assigning my own interrupt handler
> for SPI as part of my application itself.
> I can understand that, there is no exclusive handler for SPI in uboot,
> so it is disabling the SPI interrupt and printing the BOGUS INTERRUPT
> message.
> Now how do I get rid of this and have my own interrupt handler??

You just need to install you "own" interrupt handler. This is done via 
install_hdlr(). See examples/interrupt.c.

Best regards,
Stefan

=
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: off...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 3/3] smc911x: do net reset the chip if no EEPROM is connected

[Daniel Mack]

On boards without EEPROMs, don't reset the chip on U-Boot's exit so that
the MAC set by environment settings can be used by the OS later.

Signed-off-by: Daniel Mack 
Cc: Sascha Hauer 
---
 drivers/net/smc911x.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/drivers/net/smc911x.c b/drivers/net/smc911x.c
index 8c9a2a8..f777ae9 100644
--- a/drivers/net/smc911x.c
+++ b/drivers/net/smc911x.c
@@ -225,7 +225,9 @@ int eth_send(volatile void *packet, int length)
 
 void eth_halt(void)
 {
+#ifndef CONFIG_DRIVER_SMC911X_NO_EEPROM
smc911x_reset();
+#endif
 }
 
 int eth_rx(void)
-- 
1.6.2.1

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 1/3] smc911x: write back the manually set MAC address

[Daniel Mack]

If the MAX address is given by the environment, write it back to the
hardware.

Signed-off-by: Daniel Mack 
Cc: Sascha Hauer 
---
 drivers/net/smc911x.c |9 +++--
 1 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/net/smc911x.c b/drivers/net/smc911x.c
index 30f2dc2..8c9a2a8 100644
--- a/drivers/net/smc911x.c
+++ b/drivers/net/smc911x.c
@@ -41,8 +41,13 @@ static int smx911x_handle_mac_address(bd_t *bd)
unsigned long addrh, addrl;
uchar m[6];
 
-   /* if the environment has a valid mac address then use it */
-   if (!eth_getenv_enetaddr("ethaddr", m)) {
+   if (eth_getenv_enetaddr("ethaddr", m)) {
+   /* if the environment has a valid mac address then use it */
+   addrl = m[0] | (m[1] << 8) | (m[2] << 16) | (m[3] << 24);
+   addrh = m[4] | (m[5] << 8);
+   smc911x_set_mac_csr(ADDRL, addrl);
+   smc911x_set_mac_csr(ADDRH, addrh);
+   } else {
/* if not, try to get one from the eeprom */
addrh = smc911x_get_mac_csr(ADDRH);
addrl = smc911x_get_mac_csr(ADDRL);
-- 
1.6.2.1

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 2/3] smc911x: add support for LAN9220

[Daniel Mack]

Signed-off-by: Daniel Mack 
Cc: Sascha Hauer 
---
 drivers/net/smc911x.h |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/drivers/net/smc911x.h b/drivers/net/smc911x.h
index 80d2ce0..2b01cf5 100644
--- a/drivers/net/smc911x.h
+++ b/drivers/net/smc911x.h
@@ -382,6 +382,7 @@ static inline void smc911x_reg_write(u32 addr, u32 val)
 #define CHIP_9216  0x116a
 #define CHIP_9217  0x117a
 #define CHIP_9218  0x118a
+#define CHIP_9220  0x9220
 
 struct chip_id {
u16 id;
@@ -398,6 +399,7 @@ static const struct chip_id chip_ids[] =  {
{ CHIP_9216, "LAN9216" },
{ CHIP_9217, "LAN9217" },
{ CHIP_9218, "LAN9218" },
+   { CHIP_9220, "LAN9220" },
{ 0, NULL },
 };
 
-- 
1.6.2.1

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Uboot on Realview_pb11MPcore, Using Mpcore onchip timer, access onchip private memory region.

[Zheng.Wang]

Hello Dear,

I am porting Uboot to our platform which is similiar to Realview_pb11MPcore, 
with the difference in Timer : Using the ARM11 MPcore onchip timer instead of 
offchip SP804 Timer.  As a result, i have to access the MPCore private memory 
region.

According to the ARM11MPcore Technical Reference Manual,  I can access the 
private memory region by using pins PERIPHBASE[18:0], which is 19 bits. I shift 
the PERIPHBASE 13 bits to the right then plus the 13 bits offset for the Onchip 
timer, use this address to modify the CONFIG_SYS_TIMERBASE macro in 
realview_pb.h.

But when I initialize the Uboot, it just halted with nothing in the console.( 
If I dont use such addresses, the system wont halt but come to the stand that 
timer cannot downcount: Hit any key to stop autoboot:  2 )

Is there anyone know if it is the right way to access MPCore private memory 
region?

BR,

George

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Interrupt handlers in u-boot

[prathika]

Hi,
I am working on u-boot 1.1.6 version for PowerPC 440.I am using the 
hello world application from the examples folder.
I had no issues in loading and executing it.
Now I have enabled SPI interrupt in the application. I have written for 
SPI loopback.
My issue is, as there is no interrupt handler defined for the SPI in 
uboot, whenever i execute my application,
it says "Masking bogus interrupt for Vector 0x08". I am calling 
"install_irq_handler" function for assigning my own interrupt handler 
for SPI as part of my application itself.
I can understand that, there is no exclusive handler for SPI in uboot, 
so it is disabling the SPI interrupt and printing the BOGUS INTERRUPT 
message.
Now how do I get rid of this and have my own interrupt handler??
Some one please help.
Thanks all in advance.

Thanks & Regards,
Prathika R
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2] Marvell MV88F6281GTW_GE Board support

[Prafulla Wadaskar]

From: prafulla_wadaskar 

This is Marvell's 88F6281_A0 based custom board developed
for wireless access point product

This patch is tested for-
1. Boot from DRAM/SPI flash/NFS
2. File transfer using tftp and loadb
3. SPI flash read/write/erase
4. Booting Linux kernel and RFS from SPI flash
Note: doImage utility needed to convert u-boot.bin to 
u-boot-spiflash.bin, DRAM configuration will be part of
this utility

Reviewed-by: Ronen Shitrit 
Signed-off-by: Prafulla Wadaskar 
---
Changelog
v2: updated as per first review comments by Wolfgang Denk
debug_prints updated to debug

 MAKEALL |1 +
 Makefile|3 +
 board/Marvell/mv88f6281gtw_ge/Makefile  |   52 +++
 board/Marvell/mv88f6281gtw_ge/config.mk |   25 +++
 board/Marvell/mv88f6281gtw_ge/mv88f6281gtw_ge.c |  118 ++
 board/Marvell/mv88f6281gtw_ge/u-boot.lds|   53 +++
 include/configs/mv88f6281gtw_ge.h   |  185 +++
 7 files changed, 437 insertions(+), 0 deletions(-)
 create mode 100644 board/Marvell/mv88f6281gtw_ge/Makefile
 create mode 100644 board/Marvell/mv88f6281gtw_ge/config.mk
 create mode 100644 board/Marvell/mv88f6281gtw_ge/mv88f6281gtw_ge.c
 create mode 100644 board/Marvell/mv88f6281gtw_ge/u-boot.lds
 create mode 100644 include/configs/mv88f6281gtw_ge.h

diff --git a/MAKEALL b/MAKEALL
index e4eb42b..1caf81d 100755
--- a/MAKEALL
+++ b/MAKEALL
@@ -504,6 +504,7 @@ LIST_ARM9=" \
cp946es \
cp966   \
lpd7a400\
+   mv88f6281gtw_ge \
mx1ads  \
mx1fs2  \
netstar \
diff --git a/Makefile b/Makefile
index d2c7c3f..709e4be 100644
--- a/Makefile
+++ b/Makefile
@@ -2792,6 +2792,9 @@ lpd7a400_config \
 lpd7a404_config:   unconfig
@$(MKCONFIG) $(@:_config=) arm lh7a40x lpd7a40x
 
+mv88f6281gtw_ge_config: unconfig
+   @$(MKCONFIG) $(@:_config=) arm arm926ejs $(@:_config=) Marvell kirkwood
+
 mx1ads_config  :   unconfig
@$(MKCONFIG) $(@:_config=) arm arm920t mx1ads NULL imx
 
diff --git a/board/Marvell/mv88f6281gtw_ge/Makefile 
b/board/Marvell/mv88f6281gtw_ge/Makefile
new file mode 100644
index 000..1b8cc6f
--- /dev/null
+++ b/board/Marvell/mv88f6281gtw_ge/Makefile
@@ -0,0 +1,52 @@
+#
+# (C) Copyright 2009
+# Marvell Semiconductor 
+# Prafulla Wadaskar 
+#
+# 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., 51 Franklin Street, Fifth Floor, Boston,
+# MA 02110-1301 USA
+#
+
+include $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(BOARD).a
+
+COBJS  := mv88f6281gtw_ge.o
+COBJS  += ../common/mv88e61xx.o
+
+SRCS   := $(SOBJS:.o=.S) $(COBJS:.o=.c)
+OBJS   := $(addprefix $(obj),$(COBJS))
+SOBJS  := $(addprefix $(obj),$(SOBJS))
+
+$(LIB):$(obj).depend $(OBJS) $(SOBJS)
+   $(AR) $(ARFLAGS) $@ $(OBJS) $(SOBJS)
+
+clean:
+   rm -f $(SOBJS) $(OBJS)
+
+distclean: clean
+   rm -f $(LIB) core *.bak .depend
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/board/Marvell/mv88f6281gtw_ge/config.mk 
b/board/Marvell/mv88f6281gtw_ge/config.mk
new file mode 100644
index 000..fb29a1b
--- /dev/null
+++ b/board/Marvell/mv88f6281gtw_ge/config.mk
@@ -0,0 +1,25 @@
+#
+# (C) Copyright 2009
+# Marvell Semiconductor 
+# Prafulla Wadaskar 
+#
+# 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
+# F

Re: [U-Boot] Multiple Flash devices

[Mike Frysinger]

On Wednesday 08 April 2009 05:48:19 Ravula Kishor wrote:
> I have a NOR Flash used as a boot flash (16MB) and a NAND flash (128MB)to
> store kernel/rfs on coldfire based custom board . The u-boot is running out
> of NOR flash but I have problems in enabling NAND support from u-boot. Need
> clarity on couple of definitions in the board configuration file.
>
> CFG_FLASH_SIZE :
> CFG_MAX_FLASH_BANKS:
> CFG_FLASH_BANKS_LIST :

these defines have nothing to do with NAND
-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

[U-Boot] Multiple Flash devices

[Ravula Kishor]

I have a NOR Flash used as a boot flash (16MB) and a NAND flash (128MB)to store 
kernel/rfs on coldfire based custom board . The u-boot is running out of NOR 
flash but I have problems in enabling NAND support from u-boot. Need clarity on 
couple of definitions in the board configuration file.

CFG_FLASH_SIZE : 
Should it include both NOR+NAND size

CFG_MAX_FLASH_BANKS: 
If there are two flash devices, is it correct to give as 2. Is NAND flash 
identified as a seperate Bank.

CFG_FLASH_BANKS_LIST :
Should it include both Flash base addresses.

Welcome any other pointers when working with both NOR/NAND Flash.

Thanks in adv.

//Kishor



  
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Booting kernel from jffs2

[Rams Subramanian]

Currently, I have two partitions one for U- Boot and the rest for
application(kernel + application)

Total 16MB  Flash

1MB U Boot
15MB "JFFS2" Application

The U boot loads the kernel from jffs2 using fsload and the system works
fine.  Sometimes, during software upgrade,  the problem comes when jffs2 is
almost full, the files could not be deleted to freeup space because of jffs2
limitation.  The entire partition needs to be reflashed which is not a
practical solution .
Is there any better way to recover from this failure situation where we can
boot a minimum kernel and can format the jffs2 partition and copy the
application image?

On Tue, Apr 7, 2009 at 2:26 PM, Wolfgang Denk  wrote:

> Dear Rams Subramanian,
>
> In message <4e031cb50904070515u797beb03o23ad89c15362c...@mail.gmail.com>
> you wrote:
> >
> > I have an requirement to have three partitions in the Flash
> > 1. U Boot
> > 2. JFFS2(GoldenImage) (Mininum Kernel Image )
> > 3. JFFS2(Application Image) (Kernel + Application)
> > The idea of Golden image is to use this partition to boot in case the
> > application image fails after software upgrade due to corruption of the
> > filesystem in this partition if any during upgrade.  When the system is
> up
> > with Golden image, partition 3 can be updated.
> > Is this method feasible.  Kindly let me know if you have better ideas or
> > suggestions?
>
> Yes, this is possible (actually, it's trivial).
>
> Without knowing your exact requirements and restrictions it's
> difficult to recommend better ideas...
>
> 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
> "Stupidity, like virtue, is its own reward" - William E. Davidsen
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] ppc4xx: Fixup chip-selects in dtb for NAND-booting Sequoia

[Stefan Roese]

Currently the NOR & NAND support in Linux only works for the "standard"
Sequoia, the version booting for NOR flash. The NAND-booting version
has the chip-selects swapped. Here the chip-select mappings:

"Standard" NOR-booting version:
CS0 NOR
CS3 NAND

NAND-booting version:
CS0 NAND
CS3 NOR

With this path the dtb gets fixed-up, so that the correct chip-select
numbers are patched in the dtb enabling correct NOR & NAND support
in Linux on the NAND-booting Sequoia version.

Signed-off-by: Stefan Roese 
---
 board/amcc/sequoia/sequoia.c |   58 -
 1 files changed, 56 insertions(+), 2 deletions(-)

diff --git a/board/amcc/sequoia/sequoia.c b/board/amcc/sequoia/sequoia.c
index d6668e2..e824b8f 100644
--- a/board/amcc/sequoia/sequoia.c
+++ b/board/amcc/sequoia/sequoia.c
@@ -1,5 +1,5 @@
 /*
- * (C) Copyright 2006-2007
+ * (C) Copyright 2006-2009
  * Stefan Roese, DENX Software Engineering, s...@denx.de.
  *
  * (C) Copyright 2006
@@ -35,7 +35,8 @@ DECLARE_GLOBAL_DATA_PTR;
 
 extern flash_info_t flash_info[CONFIG_SYS_MAX_FLASH_BANKS]; /* info for FLASH 
chips */
 
-ulong flash_get_size (ulong base, int banknum);
+extern void __ft_board_setup(void *blob, bd_t *bd);
+ulong flash_get_size(ulong base, int banknum);
 
 int board_early_init_f(void)
 {
@@ -513,3 +514,56 @@ int post_hotkeys_pressed(void)
return 0;   /* No hotkeys supported */
 }
 #endif /* CONFIG_POST */
+
+#if defined(CONFIG_NAND_U_BOOT)
+/*
+ * On NAND-booting sequoia, we need to patch the chips select numbers
+ * in the dtb (CS0 - NAND, CS3 - NOR)
+ */
+void ft_board_setup(void *blob, bd_t *bd)
+{
+   int rc;
+   int len;
+   int nodeoffset;
+   struct fdt_property *prop;
+   u32 *reg;
+   char path[32];
+
+   /* First do common fdt setup */
+   __ft_board_setup(blob, bd);
+
+   /* And now configure NOR chip select to 3 instead of 0 */
+   strcpy(path, "/plb/opb/ebc/nor_fl...@0,0");
+   nodeoffset = fdt_path_offset(blob, path);
+   prop = fdt_get_property_w(blob, nodeoffset, "reg", &len);
+   if (prop == NULL) {
+   printf("Unable to update NOR chip select for NAND booting\n");
+   return;
+   }
+   reg = (u32 *)&prop->data[0];
+   reg[0] = 3;
+   rc = fdt_find_and_setprop(blob, path, "reg", reg, 3 * sizeof(u32), 1);
+   if (rc) {
+   printf("Unable to update property NOR mappings, err=%s\n",
+  fdt_strerror(rc));
+   return;
+   }
+
+   /* And now configure NAND chip select to 0 instead of 3 */
+   strcpy(path, "/plb/opb/ebc/n...@3,0");
+   nodeoffset = fdt_path_offset(blob, path);
+   prop = fdt_get_property_w(blob, nodeoffset, "reg", &len);
+   if (prop == NULL) {
+   printf("Unable to update NDFC chip select for NAND booting\n");
+   return;
+   }
+   reg = (u32 *)&prop->data[0];
+   reg[0] = 0;
+   rc = fdt_find_and_setprop(blob, path, "reg", reg, 3 * sizeof(u32), 1);
+   if (rc) {
+   printf("Unable to update property NDFC mappings, err=%s\n",
+  fdt_strerror(rc));
+   return;
+   }
+}
+#endif /* CONFIG_NAND_U_BOOT */
-- 
1.6.2.2

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] how to build u-boot environment

[ong]

Hi,

May i know how to build the u-boot environment for my board?
Whats the different  below. I would like to know how to build u-boot 
environment. As i know its different with u-boot.bin.

make distclean
make at91sam9263ek_config
make CROSS_COMPILE=

make distclean
make at91sam9263ek_dataflash_cs0_config
make CROSS_COMPILE=
/Ong
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] udelay/udelay_masked problems

[Po-Yu Chuang]

Hi E Robertson,

2009/4/8 E Robertson :
> Hi all,
> Is their a problem using udelay in board_init functions?
> When I do this on my at91, arm926ejs board, it seems to be in an endless loop.
> I thought this was a timer issue but I only have this problem with
> board init and not in the drivers.
> Does anyone have any ideas?
I guess the reason is:

start_armboot() in lib_arm/board.c
invokes board_init() in board/atmel//.c
before interrupt_init() in cpu/arm926ejs/interrupts.c
which invokes timer_init() in cpu/arm926ejs/at91/timer.c.

That means timer_init() is called later than your board_init()

> Is timer_init a arch specific call or should it be board specific for arm?
I have no idea either.

regards,
Po-Yu chuang
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Help about a simplified bootloader.

[os user]

On Wed, Apr 8, 2009 at 2:42 PM, Shankar Ganesh  wrote:
>
>
> On Tue, Apr 7, 2009 at 11:02 AM, os user  wrote:
>>
>> Hi,
>>
>> The data in NAND chip(linux kernel and RootFS)  is the same when
>> booting linux from U-Boot and from the simple loader. :-(
>>
>> On Sat, Apr 4, 2009 at 12:53 AM, Scott Wood 
>> wrote:
>> > On Fri, Apr 03, 2009 at 02:44:03PM +0800, os user wrote:
>> >> I want to boot linux by a simplified bootloader. I use Atmel's ARM
>> >> chip (AT91SAM9RL64EK board). Now, I can boot linux with my small
>> >> program. The small program will parse the image generaed by "mkimage"
>> >> and copy the kernel bianry from NAND flash to SDRAM, construct the tag
>> >> list, disable I/D cache, disable interrupt and then jump to kernel
>> >> entry point. The system can startup, but when accessing rootfile
>> >> system(the rootfile system was also in the NAND chip), a lot of CRC
>> >> errors were found. See below,
>> >> mtd->read(0x1fb2c bytes from 0x1804d4) returned ECC error
>> >> mtd->read(0x1fa38 bytes from 0x3e05c8) returned ECC error
>> >> mtd->read(0x1f7dc bytes from 0x7c0824) returned ECC error
>> >> jffs2_scan_inode_node(): CRC failed on node at 0x007c37a4: Read
>> >> 0xd9b2bc33, calculated 0xda4805c1
>> >>
>> >> and sometimes the sytem even crashed when R/W filesystem.
>> >>
>> >> But with the same linux kernel and rootfile system, if I use U-Boot to
>> >> boot linux, everything seems OK.
>> >>
>> >> Can anyone tell is there any trick that's related with linux NAND
>> >> driver in U-Boot? Or any suggestion to help me moving on?
>
> How about ECC calculation ? is it h/w  (GPMC) or s/w ECC ?
>

I used software ECC.

I don't think this problem is related to ECC calculation. As metioned
before, I used the same OS kernel image and root filesystem
image(JFFS2). Both are stored in NAND flash. For the good case,
Atmel's bootstrap code will launch U-Boot, and U-Boot will copy kernel
image from NAND chip to SDRAM, build tag list, do some clean
job(diable interrupt, flush/disable cache), and then jump to kernel
entry point. If I follow this path, everything is OK. This means my
linux kernel(2.6.27) and root filesystem are OK.

But In my small loader(based on Atmel's bootstrap), I also copy kernel
image from NAND chip to SDRAM, build tag list, do some clean
job(diable interrupt, flush/disable cache), and then jump to kernel
entry point. The kernel image can be decompressed without any error
and can startup sometimes. But I can see a lot of errors complained by
MTD layer. And sometimes, the system even crashed.

Hope to receive your suggestions, Thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot