date:20100813

Hi Jocke,

  Instead of always performing an autoneg, check if the PHY
  already has a link and if it matches one of the requested
  modes. Initially only 100MbFD is optimized this way.

 Isn't it about time that we think about _not_ stopping the ethernet
 device after every transaction?

 Hi Detlev

 UEC does this already, my patch was to address the initial delay
 you get for the first transaction. Now my PHY based boards gets the link
 up just as quick as Fixed PHY for the first transaction.

Forgive me to not look into this any deeper, but do I understand you
correctly that you do this by essentially no-oping the eth_halt()
function?  Isn't this then effectively violating what net.c expects the
device to do?

I was thinking that net.c itself should not do this continous start/stop
thing as it has problems on many interfaces.  On one ARM machine I've
again seen problems with the MAC address programming because the
eth_halt() resets the controller and so it forgets its address again.
Also the USB-CDC example where the _whole interface_ on the host side is
being torn down after each tftp transfer prompts me to think along this
line.

So in effect I guess my response was rather a ping to Ben, sorry for
that ;)

Cheers
  Detlev

-- 
Peace of mind isn't at all superficial to technical work.  It's the
whole thing.   That which  produces it is good work  and that which
destroys it is bad work.
-- Robert M. Pirsig
--
DENX Software Engineering GmbH,  MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2] TI: DaVinci DA850 EVM: support passing device speed grade information to kernel

Hi Nori,

  The TI DA850/OMAP-L138/AM18x EVM can be populated with devices
  of different speed grades.
 
  The maximum speed the chip can support can only be determined from
  the label on the package (not software readable).
 
  Introduce a method to pass the speed grade information to kernel
  using ATAG_REVISION. The kernel uses this information to determine
  the maximum speed reachable using cpufreq.

 Do I understand you correctly that you _misuses_ an atag defined to
 carry the revision of a CPU to carry the maximum allowed clock
 frequency?

 The EVM can be populated with devices of different speed grades and this
 patch treats those as different revisions of the EVM. Why would this be
 treated as a misuse of ATAG_REVISION?

A revision for me is attached to certain bugs/problems which we may need
to work around in software.  Think about something like we can enable
caching only on rev2 CPUs.  For all I know, the ATAG_REVISION tag seems
to capture this aspect.  The maximum speed of a CPU is orthogonal for
me, i.e. there can still be a fast and a slow rev 1 CPU but still we
cannot enable cache.  Do you see my point?  If you want to express a
maximum speed, then use an ATAG which supports such a usage.  Reading
the name ATAG_REVISION in code I would _never_ think that this
transports the maximum clock frequency.

  Is this really a good idea?  I can easily imagine different
 CPU revisions with different maximum clock frequencies.  How will you
 handle that?

 I don't think I understood you. This patch _is_ meant to handle
 different revisions of DA850 EVMs populated with DA850 devices
 of differing speed grades.

I hope I explained my point better this time.

  Note that U-Boot itself does not set the CPU rate. The CPU
  speed is setup by a primary bootloader (UBL). The rate setup
  by UBL could be different from the maximum speed grade of the
  device.

 I do not understand how the UBL gets to set the _U-Boot_ environment
 variable maxspeed.  Can you please explain how this is done?

 UBL does not (cannot) set the maxspeed variable. The user of U-Boot is
 expected to set it based on what he sees on the packaging. Alternately
 he can also change the U-Boot configuration file and re-build U-Boot.
 UBL will setup the board to work at the common frequency of 300 MHz.

I see, so please write in the documentation that the user is supposed to
set this variable correctly for his chip.  I did not read this from the
text.

  Signed-off-by: Sekhar Nori nsek...@ti.com
  ---
  v2: removed unnecessary logical OR while constructing revision value
 
   board/davinci/da8xxevm/da850evm.c |   38 
  +
   include/configs/da850evm.h|1 +
   2 files changed, 39 insertions(+), 0 deletions(-)
 
  diff --git a/board/davinci/da8xxevm/da850evm.c 
  b/board/davinci/da8xxevm/da850evm.c
  index eeb456c..0eb3608 100644
  --- a/board/davinci/da8xxevm/da850evm.c
  +++ b/board/davinci/da8xxevm/da850evm.c
  @@ -70,6 +70,44 @@ static const struct lpsc_resource lpsc[] = {
  { DAVINCI_LPSC_GPIO },
   };
 
  +#ifndef CONFIG_DA850_EVM_MAX_SPEED
  +#define CONFIG_DA850_EVM_MAX_SPEED 30
  +#endif
  +
  +/*
  + * get_board_rev() - setup to pass kernel board revision information
  + * Returns:
  + * bit[0-3]Maximum speed supported by the DA850/OMAP-L138/AM18x 
  part
  + * 0 - 300 MHz
  + * 1 - 372 MHz
  + * 2 - 408 MHz
  + * 3 - 456 MHz

 The description says it returns bit[0-3] which may seem that those
 canstants are encoded by a single bit each, whereas the code uses
 integer values.  Change either the comment or the code.

 [0-3] usually indicates the range the range 0 to 3. Do you have
 suggestions on how else this might be documented?

As I said, bit[0-3] denotes the 4 bits 0-3, i.e. a range from 0-15.
(In this context the numbers below would actually translate into
individual bits.)  Just drop this bit[0-3] and it is clear.

 Moreover I do not like that you call the variable maxpseed but
 interpret the value in kHz.  Maybe the variable should be called
 maxspeed_khz?

 I am hoping the documentation promised in the response above
 will help clarify its usage. I wanted to keep the variable name
 short.

Shortness is a worthwhile goal but clearness even more so.  Those 4
characters would prevent anyone from ever looking into the documentation
on deciding what unit the value is in.  Personally I believe this is
worth it.  I still remember old times when the Linux kernel for PowerPC
switched from its interpretation of clock frequencies from hz to mhz and
the many support questions it generated

Cheers
  Detlev

-- 
Of course my password is the same as my pet's name
My macaw's name was Q47pY!3 and I change it every 90 days
-- Trevor Linton
--
DENX Software Engineering GmbH,  MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax:

Re: [U-Boot] [PATCH 3/8] USB-CDC: Linux-like debug printout

Hi Remy,

No, it does not.
DEBUG is defined as dev_err and dev_err is defined as printf.
Anyway I can change it.

On 08/12/2010 10:33 PM, Remy Bohmer wrote:
 @@ -37,8 +37,10 @@
  #define dev_err(x, stuff...) printf(stuff)
  #define dev_dbg dev_err
  #define dev_warn dev_err
 -#define DEBUG dev_err
 -#define VDEBUG DEBUG
 +#define WARN INFO
 +#define ERROR INFO
 +#define DEBUG INFO
 
 This switches DEBUG logging on by default. This is not wanted.
 Can you please change that?
 
 Kind regards,
 
 Remy


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

Re: [U-Boot] [PATCH 3/8] USB-CDC: Linux-like debug printout

Hi,

2010/8/13 Vitaly Kuzmichev vkuzmic...@mvista.com:
 Hi Remy,

 No, it does not.
 DEBUG is defined as dev_err and dev_err is defined as printf.
 Anyway I can change it.

Please do not top-post!

 On 08/12/2010 10:33 PM, Remy Bohmer wrote:
 @@ -37,8 +37,10 @@
  #define dev_err(x, stuff...) printf(stuff)
  #define dev_dbg dev_err
  #define dev_warn dev_err
 -#define DEBUG dev_err
 -#define VDEBUG DEBUG
 +#define WARN INFO
 +#define ERROR INFO
 +#define DEBUG INFO

 This switches DEBUG logging on by default. This is not wanted.
 Can you please change that?

 No, it does not.

Well, I see with this patch much more debug logging then without it...
Hmm, it seems that you replaced all use of dprintf (which is trashed)
by DEBUG()...

 Anyway I can change it.

please do, DEBUG logging should not be on by default...

Kind regards,

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

Re: [U-Boot] [PATCH 0/8] USB: gadget: fix porting bugs

Hi Remy,

On 08/12/2010 10:37 PM, Remy Bohmer wrote:
 Hi,
 
 2) Add lost 'qmult' definition for High Speed devices
 
 Stefano, which version of this fix do you prefer? It seems there are
 now 2 patches fixing the same thing...
 

If I were you I would take my patch for 2 reasons:
1) more accurate comment (this is not OTG-related)
2) it is configurable as it was in the kernel

As alternative way I can add Stefano's signature in the patch. I like
this idea :)
What do you think, Stefano?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 3/8] USB-CDC: Linux-like debug printout

Vitaly Kuzmichev wrote:
 Take debug printout macros back from linux-2.6.27 and make them more
 useful and more compatible.
 
 Signed-off-by: Vitaly Kuzmichev vkuzmic...@mvista.com
 ---
  drivers/usb/gadget/ether.c |   65 
 +++-
  1 files changed, 34 insertions(+), 31 deletions(-)
 

Hi Vitaly,

a general comment. In u-boot is DEBUG generally defined to activate the
output, as you see in a lot of drivers. It should not be changed as
meanining in a single driver.

However, it seems more consistent to apply the comment sent by Reinhard:

http://lists.denx.de/pipermail/u-boot/2010-August/075346.html

debug() is already provided in u-boot, it makes sense not to add another
slightly modification of a debug output.

Best regards,
Stefano

-- 
=
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] [PATCH 0/8] USB: gadget: fix porting bugs

Vitaly Kuzmichev wrote:
 If I were you I would take my patch for 2 reasons:
 1) more accurate comment (this is not OTG-related)
 2) it is configurable as it was in the kernel
 
 As alternative way I can add Stefano's signature in the patch. I like
 this idea :)
 What do you think, Stefano?
 

Hi Vitaly,

I have already agreed about the patch. Your patch makes qmult
configurable, and there is no side-effects to replace mine.

Stefano

-- 
=
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] [PATCH 2/3] Connect the AT91 UDC to USB CDC-ethernet support

Hi,

 3. I did not follow the whole USB patches, my concern is
 what touches AT91, but please explain to me what for we need
 a board under u-boot to be a USB device. Since u-boot per se
 is not multitasking how is the traffic handled while
 at the command prompt?

There is no traffic handled while at the command prompt. It behaves
just like any other 'normal' network adapter.
So, it brings up a USB connection once you start a network action like
a ping or tftp command. Once that completes the link is brought down
again.

 Which leads to:
 4. Which hardware did you test that on, and what device
 functionality?

Within the series you can see that it was created for the Atmel
at91sam9261-ek kit.

Kind regards,

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

Re: [U-Boot] [PATCH 2/3] Connect the AT91 UDC to USB CDC-ethernet support

Hi Wolfgang,

2010/8/12 Wolfgang Denk w...@denx.de:
 Dear Remy Bohmer,

 In message aanlkti=z0sx9yrxgh-_ogcpduxhyrhadnerhvvbon...@mail.gmail.com you 
 wrote:

  Use struct access for SoC registers. Offset adressing is depreciated. See
  the
  struct in my at91_dbgu.h. Use readl/writel to access the hardware.

 Most of the code is copied from Linux. Do you really think we should
 rewrite it all?

 Indeed. Using I/O accessors is mandatory in U-Boot.

Ok, but here ends the goal for easy synching with the kernel. In that
case we can write our own USB gadget layer

 Indeed, but again, it is copied from Linux...

 Maybe we can do it better?

As mentioned: we can, but I did not want to at the time of writing that code.

 This file is copied from Linux. That was the goal of this port; to be
 able to integrate new devices and fixes easier in the future. It was
 not our goal to make it nicer compared to Linux. If the comments are
 wrong, I would suggest to fix it in Linux first after which we
 integrate it in U-boot.

 Come on.  Here a bit statistics:

 - diff -u linux/drivers/usb/gadget/at91_udc.c 
 u-boot/drivers/usb/gadget/at91_udc.c | wc -l
 1057
 - wc -l linux/drivers/usb/gadget/at91_udc.c 
 u_boot/drivers/usb/gadget/at91_udc.c
  1908 linux/drivers/usb/gadget/at91_udc.c
  1553 u-boot/drivers/usb/gadget/at91_udc.c

 There are so many lines changed already in the code that claoming
 This file is copied from Linux. does not make much sense any more.

Well, it is derived from 2.6.27, not latest git.
True, there are differences, but mostly it is a strip down of the
original code( /proc support is removed for example)
And I also noticed that the file can be synced to Linux more than it
currently is...

 And many of the code changes are to the worse actually.

 For example:

        -       ep-is_in = usb_endpoint_dir_in(desc);
        +       ep-is_in = (desc-bEndpointAddress  USB_DIR_IN) != 0;

This was NOT the case in 2.6.27. So, it is not worse compared to 2.6.27...

  Does this mean the system is dead and would need a watchdog or reset
  button to come alive again?

 Yep, if that happens things are really broken...

 So broken that you cannot get back to the command line interpreter?
 Really?

If malloc is broken, I consider that reason enough for hang/reboot...

  +       // terminer chaque requete dans la queue
 
  C++ comment in unknown language ;)?

 Linux code...

 And that justifies it all.

No, but please look at the overall goal here. It was the goal to use
the Linux code as much as-is, and to allow easy merging new driver
code in the future. Everything can be made better, but in that case I
would prefer to first make the origin better, and port that back to
U-boot.


Further, I am not planning to rewrite the code to the struct based
register access _right now_, since the struct based access mechanism
is somehow work in progress that is not finalised yet
(CONFIG_AT91_LEGACY is still defined for at91sam9261ek). I am not
going to shoot on a moving duck. Also because you mention that
at91_dbgu.h patches float around that  are not in mainline yet. I will
probably clean it up later when things are stabilised.

So, if you prefer I can drop patch 2/3 and 3/3 from the series, since
those are only needed to prove that patch 1/3 works and to have at
least 1 board in U-boot that make use of the USB-CDC-ECM gadget
layer... I expect that there will be other boards soon that will use
it, since others are working on it right now.

Kind regards,

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

Re: [U-Boot] [PATCH] USB-CDC: wrong ep status used

Hi Sergei,

On 08/12/2010 09:05 PM, Sergei Shtylyov wrote:
 Hello.
 
 Stefano Babic wrote:
 
 We get oops here!
 
 Agree, and the issue is not related to this patch, I missed to correct
 it, thanks. If no one complains, I will send a single patch to fix both
 problems (wrong ep status + null pointer access).
 
Looks like Vitaly has done the same already:
 
Yes, but I have not seen Stefano's comment when sent.

Stefano,
I would like to add you 'signed-off' in this patch because I took this
part from your patch:
-   usb_ep_free_request (gadget-ep0, dev-req);
+   usb_ep_free_request (dev-status_ep, dev-req);

Do you allow me to add your signature?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] USB-CDC: wrong ep status used

Vitaly Kuzmichev wrote:
 Hi Sergei,
 
 On 08/12/2010 09:05 PM, Sergei Shtylyov wrote:
 Hello.

 Stefano Babic wrote:

 We get oops here!
 Agree, and the issue is not related to this patch, I missed to correct
 it, thanks. If no one complains, I will send a single patch to fix both
 problems (wrong ep status + null pointer access).
Looks like Vitaly has done the same already:

 Yes, but I have not seen Stefano's comment when sent.
 
 Stefano,
 I would like to add you 'signed-off' in this patch because I took this
 part from your patch:
 - usb_ep_free_request (gadget-ep0, dev-req);
 + usb_ep_free_request (dev-status_ep, dev-req);
 
 Do you allow me to add your signature?
 

Yes, of course !

Stefano

-- 
=
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] [PATCH v2] TI: DaVinci DA850 EVM: support passing device speed grade information to kernel

2010-08-13 Thread Nori, Sekhar

Hi Detlev,

On Fri, Aug 13, 2010 at 14:00:21, Detlev Zundel wrote:

A revision for me is attached to certain bugs/problems which we may need
to work around in software. Think about something like we can enable
caching only on rev2 CPUs. For all I know, the ATAG_REVISION tag seems
to capture this aspect.

We will most likely end up using this aspect of ATAG_REVISION as further
revisions of the EVM appear.

The maximum speed of a CPU is orthogonal for
me, i.e. there can still be a fast and a slow rev 1 CPU

Note that we are not taking about CPU being fast or slow at a given point
of time. We are talking about whether the cpu on the board can support a
given rate. It means that the silicon has been characterized (and probably
priced) differently. So you can actually treat it as a different CPU revision.
In fact, all of these speed graded parts are sold separately with different
datasheets. Please see the 375 and 456 AM1x parts:

http://focus.ti.com/paramsearch/docs/parametricsearch.tsp?family=dspsectionId=2tabId=2641familyId=1877paramCriteria=no

and the 300 MHz OMAP-L1x parts:

http://focus.ti.com/paramsearch/docs/parametricsearch.tsp?family=dspsectionId=2tabId=2231familyId=1621paramCriteria=no

Moreover, CPU revision only occupies bits 0-3 of the ATAG_REVISION.
As you mention the rest of the bits can be used to mark other changes in the
EVMs (bug fixes etc).

but still we
cannot enable cache. Do you see my point?

No, let me know if the above explanation clarifies the topic for you.

I hope I explained my point better this time.

Yes, but I am still unconvinced ATAG_REVISION is not suitable for this
purpose.

Note that U-Boot itself does not set the CPU rate. The CPU
speed is setup by a primary bootloader (UBL). The rate setup
by UBL could be different from the maximum speed grade of the
device.

I do not understand how the UBL gets to set the _U-Boot_ environment
variable maxspeed. Can you please explain how this is done?

UBL does not (cannot) set the maxspeed variable. The user of U-Boot is
expected to set it based on what he sees on the packaging. Alternately
he can also change the U-Boot configuration file and re-build U-Boot.
UBL will setup the board to work at the common frequency of 300 MHz.

I see, so please write in the documentation that the user is supposed to
set this variable correctly for his chip. I did not read this from the
text.

Sure, I can include this in the commit text and in the README I promised.

+
+/*
+ * get_board_rev() - setup to pass kernel board revision information
+ * Returns:
+ * bit[0-3]Maximum speed supported by the DA850/OMAP-L138/AM18x
part
+ * 0 - 300 MHz
+ * 1 - 372 MHz
+ * 2 - 408 MHz
+ * 3 - 456 MHz

The description says it returns bit[0-3] which may seem that those
canstants are encoded by a single bit each, whereas the code uses
integer values. Change either the comment or the code.

[0-3] usually indicates the range the range 0 to 3. Do you have
suggestions on how else this might be documented?

As I said, bit[0-3] denotes the 4 bits 0-3, i.e. a range from 0-15.
(In this context the numbers below would actually translate into
individual bits.) Just drop this bit[0-3] and it is clear.

Why would dropping bit[0-3] make anything clear? As I mentioned
above other bits can be used in future to determine other aspects
of board revision. May be I can add that information. Is the following
more clear?

/*
* get_board_rev() - setup to pass kernel board revision information
* Returns:
* bit[0-3] Maximum speed supported by the DA850/OMAP-L138/AM18x
part
* 0 - 300 MHz
* 1 - 372 MHz
* 2 - 408 MHz
* 3 - 456 MHz
* bit[4-31]Reserved (unused for now)
*/

Moreover I do not like that you call the variable maxpseed but
interpret the value in kHz. Maybe the variable should be called
maxspeed_khz?

I am hoping the documentation promised in the response above
will help clarify its usage. I wanted to keep the variable name
short.

Shortness is a worthwhile goal but clearness even more so. Those 4
characters would prevent anyone from ever looking into the documentation
on deciding what unit the value is in. Personally I believe this is
worth it.

I see. Let me toss between this and specifying the speed in HZ and leaving
the variable as is. I guess you would be OK both ways?

Thanks,
Sekhar

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

Re: [U-Boot] [PATCH 1/2] mmc: omap3: make local symbols static

2010-08-13 Thread Grazvydas Ignotas

 Unfortunately the patches didn't apply cleanly, but the fixes were
 simple.  I have the modified patches in the omap4-next-upstream branch
 of my repo for convenience:

 http://www.sakoman.com/cgi-bin/gitweb.cgi?p=u-
 boot.git;a=shortlog;h=refs/heads/omap4-next-upstream

 Regards,

 Steve

 I have added to u-boot-ti master.

 The e-mail address in the signed-off-by was incorrect.
 I believe using at is not allowed.

 I manually edited. I'll send a pull request to Wolfgang.

Looking good, thanks Steve and Sandeep!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 00/26] arm: add full relocation / cache support

Dear Magnus Lilja,

In message 4c645e51.6020...@gmail.com you wrote:
 Dear Wolfgang Denk,
 
  The plan is as follows:
  
  I will pull this stuff into the next branch about one week after I
  released rc1. I intend to keep this CONFIG_SYS_ARM_WITHOUT_RELOC
  feature for a full release cycle. Early in the next branch for the
  following release it will be removed. Any boards that are not yet
  converted then will break. If the breakage does not get fixed by
  board maintainers or interested users, we will remove these obviously
  unmaintained boards, then.
 
 I thought the standard way was that when someone makes a change he's
 responsible for updating all code that's affected by the change.

Yes, that's the standard way.

But this is a non-standard situation: the change cannot be
implemented without knowledge about and not verified without access
to the hardware.  We depend on the help of the board maintainers
and/or users.

 Anyway, I hope that either you or Heiko Schocher ping all the
 maintainers of affected boards. If I was one, I would certainly

We can only try to Cc: those who are listed in the MAINTAINERS file.
There are some orphaned boards for which it is not clear if anybody
still cares about these, or who.

 easily miss this (don't read all mail, only scan the subject lines).

Well, you would probably notice when your board does not build any
more ? ;-)

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
I came home the other night and tried to open the door  with  my  car
keys...and  the  building started up. So I took it out for a drive. A
cop pulled me over for speeding. He asked me where I  live...  Right
here.- Steven Wright
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] OMAP3: remove unused config macros

2010-08-13 Thread Grazvydas Ignotas

Another ping for this old patch.. This still applies cleanly, and I
have verified those macros are unused by those boards. There were no
objections so far, and Steve ACKed it.

On Wed, Jun 9, 2010 at 12:30 AM, Paulraj, Sandeep s-paul...@ti.com wrote:
 Just a ping.
 Sandeep, maybe you could pick this? Those defines are mostly dead code.

 Not pushed yet.

 I have cc'ed all the concerned board maintainers in case they have an 
 objection.



 On Thu, Apr 29, 2010 at 5:19 PM, Grazvydas Ignotas nota...@gmail.com
 wrote:
  Most OMAP3 boards have various flash related macros in their configs
  that are either not referenced anywhere in the code or are used by
  drivers that are not enabled. Remove them.
 
  Signed-off-by: Grazvydas Ignotas nota...@gmail.com
  ---
   include/configs/omap3_beagle.h  |   18 --
   include/configs/omap3_evm.h     |   18 --
   include/configs/omap3_overo.h   |   18 --
   include/configs/omap3_pandora.h |   20 
   include/configs/omap3_sdp3430.h |    7 ---
   include/configs/omap3_zoom1.h   |   18 --
   include/configs/omap3_zoom2.h   |   10 --
   7 files changed, 0 insertions(+), 109 deletions(-)
 
  diff --git a/include/configs/omap3_beagle.h
 b/include/configs/omap3_beagle.h
  index 08d79ac..f8266b1 100644
  --- a/include/configs/omap3_beagle.h
  +++ b/include/configs/omap3_beagle.h
  @@ -291,9 +291,6 @@
   #define PISMO1_NAND_SIZE               GPMC_SIZE_128M
   #define PISMO1_ONEN_SIZE               GPMC_SIZE_128M
 
  -#define CONFIG_SYS_MAX_FLASH_SECT      520     /* max number of sectors
 on */
  -                                               /* one chip */
  -#define CONFIG_SYS_MAX_FLASH_BANKS     2       /* max number of flash
 banks */
   #define CONFIG_SYS_MONITOR_LEN         (256  10)     /* Reserve 2
 sectors */
 
   #define CONFIG_SYS_FLASH_BASE          boot_flash_base
  @@ -310,21 +307,6 @@
   #define CONFIG_ENV_OFFSET              boot_flash_off
   #define CONFIG_ENV_ADDR                        SMNAND_ENV_OFFSET
 
  -/*-
 --
  - * CFI FLASH driver setup
  - */
  -/* timeout values are in ticks */
  -#define CONFIG_SYS_FLASH_ERASE_TOUT    (100 * CONFIG_SYS_HZ)
  -#define CONFIG_SYS_FLASH_WRITE_TOUT    (100 * CONFIG_SYS_HZ)
  -
  -/* Flash banks JFFS2 should use */
  -#define CONFIG_SYS_MAX_MTD_BANKS       (CONFIG_SYS_MAX_FLASH_BANKS + \
  -                                       CONFIG_SYS_MAX_NAND_DEVICE)
  -#define CONFIG_SYS_JFFS2_MEM_NAND
  -/* use flash_info[2] */
  -#define CONFIG_SYS_JFFS2_FIRST_BANK    CONFIG_SYS_MAX_FLASH_BANKS
  -#define CONFIG_SYS_JFFS2_NUM_BANKS     1
  -
   #ifndef __ASSEMBLY__
   extern unsigned int boot_flash_base;
   extern volatile unsigned int boot_flash_env_addr;
  diff --git a/include/configs/omap3_evm.h b/include/configs/omap3_evm.h
  index 0d99f7d..39eb4b5 100644
  --- a/include/configs/omap3_evm.h
  +++ b/include/configs/omap3_evm.h
  @@ -295,9 +295,6 @@
   #define PISMO1_NAND_SIZE               GPMC_SIZE_128M
   #define PISMO1_ONEN_SIZE               GPMC_SIZE_128M
 
  -#define CONFIG_SYS_MAX_FLASH_SECT      520     /* max number of sectors
 */
  -                                               /* on one chip */
  -#define CONFIG_SYS_MAX_FLASH_BANKS     2       /* max number of flash
 banks */
   #define CONFIG_SYS_MONITOR_LEN         (256  10)     /* Reserve 2
 sectors */
 
   #define CONFIG_SYS_FLASH_BASE          boot_flash_base
  @@ -314,21 +311,6 @@
   #define CONFIG_ENV_OFFSET              boot_flash_off
   #define CONFIG_ENV_ADDR                        boot_flash_env_addr
 
  -/*-
 --
  - * CFI FLASH driver setup
  - */
  -/* timeout values are in ticks */
  -#define CONFIG_SYS_FLASH_ERASE_TOUT    (100 * CONFIG_SYS_HZ)
  -#define CONFIG_SYS_FLASH_WRITE_TOUT    (100 * CONFIG_SYS_HZ)
  -
  -/* Flash banks JFFS2 should use */
  -#define CONFIG_SYS_MAX_MTD_BANKS       (CONFIG_SYS_MAX_FLASH_BANKS + \
  -                                       CONFIG_SYS_MAX_NAND_DEVICE)
  -#define CONFIG_SYS_JFFS2_MEM_NAND
  -/* use flash_info[2] */
  -#define CONFIG_SYS_JFFS2_FIRST_BANK    CONFIG_SYS_MAX_FLASH_BANKS
  -#define CONFIG_SYS_JFFS2_NUM_BANKS     1
  -
   #ifndef __ASSEMBLY__
   extern unsigned int boot_flash_base;
   extern volatile unsigned int boot_flash_env_addr;
  diff --git a/include/configs/omap3_overo.h
 b/include/configs/omap3_overo.h
  index a43500b..b5b2dbe 100644
  --- a/include/configs/omap3_overo.h
  +++ b/include/configs/omap3_overo.h
  @@ -260,9 +260,6 @@
   #define PISMO1_NAND_SIZE               GPMC_SIZE_128M
   #define PISMO1_ONEN_SIZE               GPMC_SIZE_128M
 
  -#define CONFIG_SYS_MAX_FLASH_SECT      520     /* max number of sectors
 on */
  -                                               /* one chip */
  -#define CONFIG_SYS_MAX_FLASH_BANKS     2       /* max number of flash

Re: [U-Boot] Please pull u-boot-cfi-flash/master

Dear Stefan Roese,

In message 201008130936.19599...@denx.de you wrote:
 
 On Thursday 12 August 2010 23:04:55 Wolfgang Denk wrote:
   Kim Phillips (1):
 cfi_flash: flinfo: allow user interrupt in flash print info fn
  
  Sorry, this patch got a NAK from me. The code needs fixing (actually
  the existing code should be fixed first, then Kim can add his patch).
 
 Would you accept an add-on patch that fixes this issue (I already have such a 
 patch here). I just spotted a minor formatting problem with Kim's patch which 
 I'm fixing in my add-on patch as well.

Yes, that's OK with me.

 Just let me know and I'll send the add-on patch to the list.

Thanks.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Gewöhnlich glaubt der Mensch,  wenn er nur Worte hört,  es müsse sich
dabei doch auch was denken lassen. -- Goethe, Faust I
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 3/8] USB-CDC: Linux-like debug printout

Dear Remy Bohmer,

In message aanlkti=gnfzr6wt-rj6clfekugghhpjudbj1vftar...@mail.gmail.com you 
wrote:
 
  +#define WARN INFO
  +#define ERROR INFO
  +#define DEBUG INFO
 
  This switches DEBUG logging on by default. This is not wanted.
  Can you please change that?
 
  No, it does not.
 
 Well, I see with this patch much more debug logging then without it...
 Hmm, it seems that you replaced all use of dprintf (which is trashed)
 by DEBUG()...
 
  Anyway I can change it.
 
 please do, DEBUG logging should not be on by default...

DEBUG is already a well-defined name. Any different use of the same
name will result in the patches being rejected.

Please fix this!

I also object against names like WARN, ERROR and INFO. They are just
too dangerous.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
You are an excellent tactician, Captain. You let your second in  com-
mand attack while you sit and watch for weakness.
-- Khan Noonian Singh, Space Seed, stardate 3141.9
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2a] AT91: add SD/MMC support

2010-08-13 Thread asc0


Hello! I have successfully applied your patch on a AT91SAM9G20 cpu and it
reads the correct CID  CSD info.
At the end of initialization the bread function fails with the following
error:

mmc: bread failed, status = 0040c0e5, card status = 0900

Does someone else received this error or have a hint on this error message?

Thanks,
  Alex
-- 
View this message in context: 
http://old.nabble.com/-U-Boot---PATCH--AT91SAM9260-9XE%3A-add-support-for-MultiMedia-Card-Interface-%28MCI%29-tp29068839p29427373.html
Sent from the Uboot - Users mailing list archive at Nabble.com.

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

Re: [U-Boot] [PATCH 3/8] USB-CDC: Linux-like debug printout

Hi Sergei,

Sergei Shtylyov wrote:
 -printf (enable %s -- %d\n,
 +DEBUG(dev, enable %s -- %d\n,
 
   Well, I think the coding style shouldbe consistent -- you either leave
 the space before ( or remove it. And as U-Boot seems to follow the Linux
 coding style now, it seems better to remove the space.

Well, I would say: either leave the space before ( or remove it from
EVERYWHERE.
I think that the last thing should be done as a separate patch.
So I would like to keep the coding style that is in this file.


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

Re: [U-Boot] [PATCH 2/3] Connect the AT91 UDC to USB CDC-ethernet support

Dear Remy Bohmer,

In message aanlktinv_4m6cfvzgd+off1cinzuwejhiutdd9rpf...@mail.gmail.com you 
wrote:
 
  There are so many lines changed already in the code that claoming
  This file is copied from Linux. does not make much sense any more.
 
 Well, it is derived from 2.6.27, not latest git.
 True, there are differences, but mostly it is a strip down of the
 original code( /proc support is removed for example)
 And I also noticed that the file can be synced to Linux more than it
 currently is...

Well, if your argument is true that the current code can easily be
kept in sync with Linux, then why is it already 8 kernel releases old?

How about syncing it with Linux, before adding it to U-Boot?

  Yep, if that happens things are really broken...
 
  So broken that you cannot get back to the command line interpreter?
  Really?
 
 If malloc is broken, I consider that reason enough for hang/reboot...

That's not a good idea.  Please fix.

  And that justifies it all.
 
 No, but please look at the overall goal here. It was the goal to use
 the Linux code as much as-is, and to allow easy merging new driver
 code in the future. Everything can be made better, but in that case I
 would prefer to first make the origin better, and port that back to
 U-boot.

Well, the origin has improved by 8 kernel releases since.

Would it make sense to update?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
A witty saying proves nothing, but saying  something  pointless  gets
people's attention.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] usb: musb: only write CLRDATATOG when appropriate

2010-08-13 Thread Sergei Shtylyov

Hello.

Remy Bohmer wrote:

 Mike Frysinger wrote:
 --- a/drivers/usb/musb/musb_hcd.c
 +++ b/drivers/usb/musb/musb_hcd.c
} else {
 -   if (!toggle)
 -   writew(MUSB_RXCSR_CLRDATATOG, musbr-rxcsr);
 -   else {
 +   if (!toggle) {
 +   csr = readw(musbr-txcsr);
 +   if (csr  MUSB_TXCSR_MODE)
 +   csr = MUSB_RXCSR_CLRDATATOG;

   Clearing RXCSR when FIFO is in TX mode?

I meant to say clearing RX toggle.

 unless i missed something, that is what Linux is doing.

 Can Linux be wrong too?

 musb_host.c:musb_rx_reinit()
csr = musb_readw(ep-regs, MUSB_RXCSR);
if (csr  MUSB_RXCSR_RXPKTRDY)
WARNING(rx%d, packet/%d ready?\n, ep-epnum,
musb_readw(ep-regs, MUSB_RXCOUNT));

csr = musb_readw(ep-regs, MUSB_TXCSR);
if (csr  MUSB_TXCSR_MODE)
musb_h_flush_rxfifo(ep, MUSB_RXCSR_CLRDATATOG);
else
musb_h_flush_rxfifo(ep, 0);

 although i see that i need to also extend the MUSB_TXCSR_MODE define
 for Blackfin musb ports in u-boot.  but this shouldnt affect
 non-Blackfin musb ports.  i'll send a sep patch for that.
 -mike

 Sergei, do you agree that I apply this patch?

Well, if it's based on the Linux code... although it still does look 
wrong... I don't know. :-)

 Kind regards,

 Remy

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

Re: [U-Boot] [PATCH v2] TI: DaVinci DA850 EVM: support passing device speed grade information to kernel

Hi Nori,

We will most likely end up using this aspect of ATAG_REVISION as further
revisions of the EVM appear.

The maximum speed of a CPU is orthogonal for
me, i.e. there can still be a fast and a slow rev 1 CPU

Well yes, you _can_ treat that as a revision, but certainly I would
not understand what you mean. A CPU revision for me is connected to the
physical chip mask on the CPU (i.e. what goes into the manufacturing
process) and the maximum allowed operating frequency is a property of an
individual chip possibly only detected by actual measurements (what
comes out of manufacturing). I never heard people talk about
_functionally equivalent_ CPUs with different graded operating
frequencies as different revisions, but YMMV.

In fact, all of these speed graded parts are sold separately with different
datasheets. Please see the 375 and 456 AM1x parts:

http://focus.ti.com/paramsearch/docs/parametricsearch.tsp?family=dspsectionId=2tabId=2641familyId=1877paramCriteria=no

They surely have differnet part numbers and this is perfectly fine.

But let's take a look at your first link. I see two parts here with
different allowed frequencies: AM1806-375 and AM1806-456. _Both_ links
lead to the same page with these datasheets:

AM1806 ARM Microprocessor (Rev. B) (PDF 1431 KB) 03 May 2010
AM1806 Silicon Errata Silicon Revision 2.0 (PDF 66 KB) 12 Mar 2010

So I cannot follow your differnet datasheets here. Also the usage of
revision here is not coupled to any operating frequency.

Moreover, CPU revision only occupies bits 0-3 of the ATAG_REVISION.
As you mention the rest of the bits can be used to mark other changes in the
EVMs (bug fixes etc).

but still we cannot enable cache. Do you see my point?

No, let me know if the above explanation clarifies the topic for you.

I hope I explained my point better this time.

Yes, but I am still unconvinced ATAG_REVISION is not suitable for this
purpose.

When writing code which should also be maintainable by other people it
is a good idea to consider common expectations also of other people.

+
+/*
+ * get_board_rev() - setup to pass kernel board revision information
+ * Returns:
+ * bit[0-3]Maximum speed supported by the
DA850/OMAP-L138/AM18x part
+ * 0 - 300 MHz
+ * 1 - 372 MHz
+ * 2 - 408 MHz
+ * 3 - 456 MHz

The description says it returns bit[0-3] which may seem that those
canstants are encoded by a single bit each, whereas the code uses
integer values. Change either the comment or the code.

[0-3] usually indicates the range the range 0 to 3. Do you have
suggestions on how else this might be documented?

As I said, bit[0-3] denotes the 4 bits 0-3, i.e. a range from 0-15.
(In this context the numbers below would actually translate into
individual bits.) Just drop this bit[0-3] and it is clear.

Let me try to reformulate the ambiguity that I see here - when a
documentation tells that bit[0-3] is used, then I would really expect
something like 0001 - xx 0010 - yy ; 0100 - zz. If I don't see
this and read 0 - xx; 1 - yy; 2 - zz; 3 - aa on first read I would
interpret this as bit 0 - xx; bit 1 - yy; bit 2 - zz; bit 3 - aa which
is obviously _not_ what you do.

Moreover I do not like that you call the variable maxpseed but
interpret the value in kHz. Maybe the variable should be called
maxspeed_khz?

I am hoping the documentation promised in the response above
will help clarify its usage. I wanted to keep the variable name
short.

I see. Let me toss between this and specifying the

[U-Boot] [PATCH] cfi_flash: Cleanup flash_print_info()

2010-08-13 Thread Stefan Roese

This patch does the following:

- Extract code to detect if sector is erased into function
  sector_erased().
- Because of this, we don't have variable declarations inside the
  sector loop in flash_print_info()
- Change return to break in the if (ctrlc()) statement:
  This fixes a problem with the resulting output. Before this
  patch the output was:

  Sector Start Addresses:
  FC00FC02FC04   =

  With this patch it is now:

  Sector Start Addresses:
  FC00FC02FC04
  =

Signed-off-by: Stefan Roese s...@denx.de
Cc: Kim Phillips kim.phill...@freescale.com
Cc: Wolfgang Denk w...@denx.de
---
 drivers/mtd/cfi_flash.c |   51 --
 1 files changed, 27 insertions(+), 24 deletions(-)

diff --git a/drivers/mtd/cfi_flash.c b/drivers/mtd/cfi_flash.c
index 2157c02..1191ef0 100644
--- a/drivers/mtd/cfi_flash.c
+++ b/drivers/mtd/cfi_flash.c
@@ -1096,8 +1096,30 @@ int flash_erase (flash_info_t * info, int s_first, int 
s_last)
return rcode;
 }
 
-/*---
- */
+#ifdef CONFIG_SYS_FLASH_EMPTY_INFO
+static int sector_erased(flash_info_t *info, int i)
+{
+   int k;
+   int size;
+   volatile unsigned long *flash;
+
+   /*
+* Check if whole sector is erased
+*/
+   size = flash_sector_size(info, i);
+   flash = (volatile unsigned long *) info-start[i];
+   /* divide by 4 for longword access */
+   size = size  2;
+
+   for (k = 0; k  size; k++) {
+   if (*flash++ != 0x)
+   return 0;   /* not erased */
+   }
+
+   return 1;   /* erased */
+}
+#endif /* CONFIG_SYS_FLASH_EMPTY_INFO */
+
 void flash_print_info (flash_info_t * info)
 {
int i;
@@ -1162,33 +1184,14 @@ void flash_print_info (flash_info_t * info)
puts (\n  Sector Start Addresses:);
for (i = 0; i  info-sector_count; ++i) {
if (ctrlc())
-   return;
+   break;
if ((i % 5) == 0)
-   printf (\n);
+   putc('\n');
 #ifdef CONFIG_SYS_FLASH_EMPTY_INFO
-   int k;
-   int size;
-   int erased;
-   volatile unsigned long *flash;
-
-   /*
-* Check if whole sector is erased
-*/
-   size = flash_sector_size(info, i);
-   erased = 1;
-   flash = (volatile unsigned long *) info-start[i];
-   size = size  2;   /* divide by 4 for longword access */
-   for (k = 0; k  size; k++) {
-   if (*flash++ != 0x) {
-   erased = 0;
-   break;
-   }
-   }
-
/* print empty and read-only info */
printf (  %08lX %c %s ,
info-start[i],
-   erased ? 'E' : ' ',
+   sector_erased(info, i) ? 'E' : ' ',
info-protect[i] ? RO :   );
 #else  /* ! CONFIG_SYS_FLASH_EMPTY_INFO */
printf (  %08lX   %s ,
-- 
1.7.2.1

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

Re: [U-Boot] [PATCH 3/8] USB-CDC: Linux-like debug printout

2010-08-13 Thread Sergei Shtylyov

Hello.

Vitaly Kuzmichev wrote:

 -printf (enable %s -- %d\n,
 +DEBUG(dev, enable %s -- %d\n,

   Well, I think the coding style shouldbe consistent -- you either leave
 the space before ( or remove it. And as U-Boot seems to follow the Linux
 coding style now, it seems better to remove the space.

 Well, I would say: either leave the space before ( or remove it from
 EVERYWHERE.
 I think that the last thing should be done as a separate patch.
 So I would like to keep the coding style that is in this file.

Which you've failed to do so far. ;-)

 Best regards,
 Vitaly.

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

Re: [U-Boot] [PATCH 2/3] Connect the AT91 UDC to USB CDC-ethernet support

Dear Remy Bohmer,
 3. I did not follow the whole USB patches, my concern is
 what touches AT91, but please explain to me what for we need
 a board under u-boot to be a USB device. Since u-boot per se
 is not multitasking how is the traffic handled while
 at the command prompt?
 
 There is no traffic handled while at the command prompt. It behaves
 just like any other 'normal' network adapter.
 So, it brings up a USB connection once you start a network action like
 a ping or tftp command. Once that completes the link is brought down
 again.

If I understand the procedure correctly now, its as follows:

Any client network command on u-boot's command prompt like ping, dhcp, tftp
etc. will 'up' the USB Device...
The host to which it is connected to will happily discover and enumerate
a network adapter with MAC and IP addresses...
And the host will be the server for that command...

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

Re: [U-Boot] [PATCH v2 2/3] avr32: Use uncached() macro to get an address for SDRAM init

Hi Haavard,

 Detlev Zundel d...@denx.de wrote:
 So this patch replaces a construct which seems to be valid over all
 architectures by a construct which is only used in avr32, right?  It
 also deletes the explicit statement that such a mapping is not needed
 any further.

 Problem is that in order to make the CFI driver work on avr32, we need
 to change the map_physmem() macro to return the physical address
 unchanged.

I see.  And I presume you cannot tell the situation apart inside
map_physmem?

 Isn't this a step backward?  Can't you put the functionality inside the
 map function and leave the unmap a noop?

 I agree it's a step backward, but since the previous flamewar didn't
 get us anywhere, I decided to go for a compromise this time. At least
 this small architecture-specific kludge is localized to
 architecture-specific code.

 The map_physmem() macro currently does exactly the same thing as the
 uncached() macro, and the unmap is a noop, but the next patch changes
 it in order to fix the CFI driver. If the next patch is applied without
 this patch being applied first, the SDRAM driver will do cached
 accesses during initialization, and that may cause the initialization
 to fail.

Why not include a note to this extent into the git commit message?  This
would be a great help for other people to later understand why this
change has been done the backward way that it was.

Cheers
  Detlev

-- 
vi vi vi - the roman numeral of the beast.
--
DENX Software Engineering GmbH,  MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/3] Connect the AT91 UDC to USB CDC-ethernet support

Hi,

2010/8/13 Reinhard Meyer u-b...@emk-elektronik.de:
 Dear Remy Bohmer,

 3. I did not follow the whole USB patches, my concern is
 what touches AT91, but please explain to me what for we need
 a board under u-boot to be a USB device. Since u-boot per se
 is not multitasking how is the traffic handled while
 at the command prompt?

 There is no traffic handled while at the command prompt. It behaves
 just like any other 'normal' network adapter.
 So, it brings up a USB connection once you start a network action like
 a ping or tftp command. Once that completes the link is brought down
 again.

 If I understand the procedure correctly now, its as follows:

 Any client network command on u-boot's command prompt like ping, dhcp, tftp
 etc. will 'up' the USB Device...
 The host to which it is connected to will happily discover and enumerate
 a network adapter with MAC and IP addresses...

Correct.

 And the host will be the server for that command...

The procedure is initiated by U-boot, since that one is pulling the D+
resistor up and down.
Network traffic is of course bidirectional, so U-boot can initiate a
TFTP transfer when it is up.

Kind regards,

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

Re: [U-Boot] [PATCH v2a] AT91: add SD/MMC support

asc0 wrote:
 Hello! I have successfully applied your patch on a AT91SAM9G20 cpu and it
 reads the correct CID  CSD info.
 At the end of initialization the bread function fails with the following
 error:
 
 mmc: bread failed, status = 0040c0e5, card status = 0900
 
 Does someone else received this error or have a hint on this error message?

a) it works fine on ATNGW100 and AT91SAM9XE-EK. Have you tried other cards?
The driver will not work with SDHC cards or cards that do not allow partial 
reads.
Maybe supply us here with the CID and CSD output from the driver.

b) that driver has become obsolete now... A few days ago I managed to get the 
mmc
framework based driver originally by Rob Emanuele running. That one can deal 
with
large cards (still have to test that, a 32GB card is in the mail to me). During
the weekend I might post a first patch of that to the list.

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

Re: [U-Boot] [PATCH 2/3] Connect the AT91 UDC to USB CDC-ethernet support

Hi Wolfgang,

2010/8/13 Wolfgang Denk w...@denx.de:
 Dear Remy Bohmer,

 Well, if your argument is true that the current code can easily be
 kept in sync with Linux, then why is it already 8 kernel releases old?

Because it lives already for a real long time in the u-boot-usb tree
with no requests on the ML about this subject.
Nobody ever showed interest on the ML, so that did not convince me to
put any effort in it to push it further. (Why put a lot of time in
something if nobody wants it?) Recently there finally seems to be
interest, so now it is time to do something useful with it.

 How about syncing it with Linux, before adding it to U-Boot?

Can be done, but first collect the review comments to figure out how
much time it will take to make it U-boot suitable and find out if we
need to fork anyway... From functional point of view I see no reason
yet to upgrade.

  Yep, if that happens things are really broken...
 
  So broken that you cannot get back to the command line interpreter?
  Really?

 If malloc is broken, I consider that reason enough for hang/reboot...

 That's not a good idea.  Please fix.

Fix what?
If runtime a condition is detected that should _never_ _ever_ happen
(like malloc does not work properly for some reason), which would even
make Linux OOPS or panic may not result in a hang() on U-boot?
In that case I can remove the hang() and consider if it never
happened. Maybe even the code will reach the prompt, but there will be
no guarantees...
I personally consider that worse compared to tell the user that
something serious has gone wrong...

Kind regards,

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

Re: [U-Boot] [PATCH 3/8] USB-CDC: Linux-like debug printout

Hi,

 DEBUG is already a well-defined name. Any different use of the same
 name will result in the patches being rejected.

 Please fix this!

 I also object against names like WARN, ERROR and INFO. They are just
 too dangerous.

Agree.

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

Re: [U-Boot] [PATCH] Fix typo inside atmel_mci driver

2010-08-13 Thread Claudio Mignanti

2010/8/7 Reinhard Meyer reinhard.me...@emk-elektronik.de:
 Wolfgang Denk wrote:

 Dear Claudio Mignanti,

 In message aanlktikknw19u8yiqokqye-wxjuo4b8rwqo-ibpa1...@mail.gmail.com
 you wrote:


 The function get_mci_clk_rate is used inside atmel_mci driver
  but never defined. Fix this typo.


 Thats NOT a typo. The current atmel_mci.c is for AVR32 ONLY.


 With the proposed patch I successfully use this driver on at91sam9g20!
Probabily they share the same mci controller I don't know, I want only
report this experience.

U-Boot 2009.08 (Dec 22 2009 - 13:15:07)

CPU: AT91SAM9G20
Crystal frequency:   18.432 MHz
CPU clock:  396.288 MHz
Master clock :  132.096 MHz
DRAM:  64 MB
DataFlash:AT45DB642
Nb pages:   8192
Page Size:   1056
Size= 8650752 bytes

u-boot mmc init
mmc: setting clock 15 Hz, block size 512
mmc: clock 15 too low; setting CLKDIV to 255
Manufacturer ID:   1B
OEM/Application ID:534D
Product name:  UD
Product Revision:  1.0
Product Serial Number: 3550481429
Manufacturing Date:07/10
SD Card detected (RCA 45928)
CSD data: 32002f00 000195f5 feb6df33 0009a5fc
CSD structure version:   1.0
MMC System Spec version: 0
Card command classes:5f5
Read block length:   512

Supports partial reads
Write block length:  512
Does not support partial writes
Supports group WP:  16
Card capacity:  510132224 bytes
File format:0/0
Write protection:
mmc: Using 3145728 cycles data timeout (DTOR=0x73)
mmc: setting clock 500 Hz, block size 512
.mmc1 is available
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2a] AT91: add SD/MMC support

2010-08-13 Thread Schleifer, Alexander

Thanks for your reply...

The CID part is:
mmc: response: 1a50514d 53202020 1018301a ec007b8b
Manufacturer ID:   1A
OEM/Application ID:5051
Product name:  MS
Product Revision:  1.0
Product Serial Number: 405805804
Manufacturing Date:07/11

The CSD part is:
mmc: response: 005e0032 5f5983cf edb6ff87 9640003f
raw CSD data: 005e0032 5f5983cf edb6ff87 9640003f
Read block length: 512
  (Supports partial reads)
Card capacity: 244 Mbytes
Warning: Using maximum data timeout
mmc: Using 983040 cycles data timeout (DTOR=0x7f)
...
MCI_DTOR = 007f
...
mmc: bread failed, status = 0040c0e5, card status = 0900
...

The maximum data timeout is set hard-coded for testing purposes because the 
bread status has the DTOE bit set.
I have also tried a 2GB SD card (no SDHC) with the same error and status code.

Best regards,
Alexander

-Original Message-
From: Reinhard Meyer [mailto:u-b...@emk-elektronik.de] 
Sent: Friday, August 13, 2010 1:17 PM
To: Schleifer, Alexander
Cc: u-boot@lists.denx.de
Subject: Re: [U-Boot] [PATCH v2a] AT91: add SD/MMC support

asc0 wrote:
 Hello! I have successfully applied your patch on a AT91SAM9G20 cpu and 
 it reads the correct CID  CSD info.
 At the end of initialization the bread function fails with the 
 following
 error:
 
 mmc: bread failed, status = 0040c0e5, card status = 0900
 
 Does someone else received this error or have a hint on this error message?

a) it works fine on ATNGW100 and AT91SAM9XE-EK. Have you tried other cards?
The driver will not work with SDHC cards or cards that do not allow partial 
reads.
Maybe supply us here with the CID and CSD output from the driver.

b) that driver has become obsolete now... A few days ago I managed to get the 
mmc framework based driver originally by Rob Emanuele running. That one can 
deal with large cards (still have to test that, a 32GB card is in the mail to 
me). During the weekend I might post a first patch of that to the list.

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

Re: [U-Boot] [PATCH v2 2/3] avr32: Use uncached() macro to get an address for SDRAM init

2010-08-13 Thread Haavard Skinnemoen

Detlev Zundel d...@denx.de wrote:
  Problem is that in order to make the CFI driver work on avr32, we need
  to change the map_physmem() macro to return the physical address
  unchanged.
 
 I see.  And I presume you cannot tell the situation apart inside
 map_physmem?

I don't think so. How do you propose we do that?

  The map_physmem() macro currently does exactly the same thing as the
  uncached() macro, and the unmap is a noop, but the next patch changes
  it in order to fix the CFI driver. If the next patch is applied without
  this patch being applied first, the SDRAM driver will do cached
  accesses during initialization, and that may cause the initialization
  to fail.
 
 Why not include a note to this extent into the git commit message?  This
 would be a great help for other people to later understand why this
 change has been done the backward way that it was.

The commit message already contains this:

The paging system which is required to set up caching properties has not
yet been initialized when the SDRAM is initialized. So when the
map_physmem() function is converted to return the physical address
unchanged, the SDRAM initialization will break on some boards.

which is essentially the same thing, isn't it?

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

[U-Boot] [PATCH v2 3/8] USB-CDC: Use native debug printout macros

Replace Linux-like debug printout macros by native ones.

Signed-off-by: Vitaly Kuzmichev vkuzmic...@mvista.com
---
 drivers/usb/gadget/ether.c |   99 ---
 1 files changed, 46 insertions(+), 53 deletions(-)

diff --git a/drivers/usb/gadget/ether.c b/drivers/usb/gadget/ether.c
index a07738f..c287ec2 100644
--- a/drivers/usb/gadget/ether.c
+++ b/drivers/usb/gadget/ether.c
@@ -20,6 +20,9 @@
  * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
  */
 
+#define DEBUG
+#undef DEBUG
+
 #include common.h
 #include asm/errno.h
 #include linux/usb/ch9.h
@@ -31,14 +34,7 @@
 #include gadget_chips.h
 
 #define USB_NET_NAME usb0
-#define dprintf(x, ...)
-#undef INFO
-#define INFO(x, s...)  printf(s)
-#define dev_err(x, stuff...) printf(stuff)
-#define dev_dbg dev_err
-#define dev_warn dev_err
-#define DEBUG dev_err
-#define VDEBUG DEBUG
+
 #define atomic_read
 extern struct platform_data brd;
 #define spin_lock(x)
@@ -769,7 +765,7 @@ set_ether_config (struct eth_dev *dev, gfp_t gfp_flags)
 
result = usb_ep_enable (dev-status_ep, dev-status);
if (result != 0) {
-   printf (enable %s -- %d\n,
+   debug(enable %s -- %d\n,
dev-status_ep-name, result);
goto done;
}
@@ -789,14 +785,14 @@ set_ether_config (struct eth_dev *dev, gfp_t gfp_flags)
if (!cdc_active(dev)) {
result = usb_ep_enable (dev-in_ep, dev-in);
if (result != 0) {
-   printf (enable %s -- %d\n,
+   debug(enable %s -- %d\n,
dev-in_ep-name, result);
goto done;
}
 
result = usb_ep_enable (dev-out_ep, dev-out);
if (result != 0) {
-   printf (enable %s -- %d\n,
+   debug(enable %s -- %d\n,
dev-out_ep-name, result);
goto done;
}
@@ -827,6 +823,8 @@ static void eth_reset_config (struct eth_dev *dev)
if (dev-config == 0)
return;
 
+   debug(%s\n, __func__);
+
/* disable endpoints, forcing (synchronous) completion of
 * pending i/o.  then free the requests.
 */
@@ -864,7 +862,7 @@ static int eth_set_config (struct eth_dev *dev, unsigned 
number, gfp_t gfp_flags
 dev-config
 dev-tx_qlen != 0) {
/* tx fifo is full, but we can't clear it...*/
-   INFO (dev, can't change configurations\n);
+   error(can't change configurations);
return -ESPIPE;
}
eth_reset_config (dev);
@@ -901,7 +899,7 @@ static int eth_set_config (struct eth_dev *dev, unsigned 
number, gfp_t gfp_flags
}
 
dev-config = number;
-   INFO (dev, %s speed config #%d: %d mA, %s, using %s\n,
+   printf(%s speed config #%d: %d mA, %s, using %s\n,
speed, number, power, driver_desc,
(cdc_active(dev)? CDC Ethernet
: CDC Ethernet Subset));
@@ -941,11 +939,11 @@ static void eth_status_complete (struct usb_ep *ep, 
struct usb_request *req)
 
req-length = STATUS_BYTECOUNT;
value = usb_ep_queue (ep, req, GFP_ATOMIC);
-   dprintf (send SPEED_CHANGE -- %d\n, value);
+   debug(send SPEED_CHANGE -- %d\n, value);
if (value == 0)
return;
} else if (value != -ECONNRESET) {
-   dprintf(event %02x -- %d\n,
+   debug(event %02x -- %d\n,
event-bNotificationType, value);
if (event-bNotificationType==
USB_CDC_NOTIFY_SPEED_CHANGE)
@@ -991,7 +989,7 @@ static void issue_start_status (struct eth_dev *dev)
 
value = usb_ep_queue (dev-status_ep, req, GFP_ATOMIC);
if (value  0)
-   printf (status buf queue -- %d\n, value);
+   debug(status buf queue -- %d\n, value);
 }
 
 #endif
@@ -1001,8 +999,7 @@ static void issue_start_status (struct eth_dev *dev)
 static void eth_setup_complete (struct usb_ep *ep, struct usb_request *req)
 {
if (req-status || req-actual != req-length)
-   dprintf  (/*(struct eth_dev *) ep-driver_data*/
-   setup complete -- %d, %d/%d\n,
+   debug(setup complete -- %d, %d/%d\n,
req-status, req-actual, req-length);
 }
 
@@ -1029,7 +1026,7 @@ eth_setup (struct usb_gadget *gadget, const struct 
usb_ctrlrequest *ctrl)
 * while config change events may enable network traffic.
 */
 
-   dprintf(eth_setup:...\n);
+   debug(%s\n, __func__);

Re: [U-Boot] [PATCH v2 2/3] avr32: Use uncached() macro to get an address for SDRAM init

Hi Haavard,

 Detlev Zundel d...@denx.de wrote:
  Problem is that in order to make the CFI driver work on avr32, we need
  to change the map_physmem() macro to return the physical address
  unchanged.
 
 I see.  And I presume you cannot tell the situation apart inside
 map_physmem?

 I don't think so. How do you propose we do that?

I don't know, that's why I'm asking.  

Let's take a step back and please excuse my ignorant question - why
exactly does the CFI driver need the physical address unchanged?  Isn't
the real constraint that the address requested by CFI is uncached?  Why
can't this be done by map_physmem()?

  The map_physmem() macro currently does exactly the same thing as the
  uncached() macro, and the unmap is a noop, but the next patch changes
  it in order to fix the CFI driver. If the next patch is applied without
  this patch being applied first, the SDRAM driver will do cached
  accesses during initialization, and that may cause the initialization
  to fail.
 
 Why not include a note to this extent into the git commit message?  This
 would be a great help for other people to later understand why this
 change has been done the backward way that it was.

 The commit message already contains this:

 The paging system which is required to set up caching properties has not
 yet been initialized when the SDRAM is initialized. So when the
 map_physmem() function is converted to return the physical address
 unchanged, the SDRAM initialization will break on some boards.

 which is essentially the same thing, isn't it?

For me this is not the same - it does not include a word why the change
which you agree looks backward is something that we want to do.  For
me something like this would give me more information:

  Unfortunately we cannot make map_physmem()/unmap_physmem() on the
  AVR32 platform work with the CFI driver as it works on other
  platforms. [I don't understand why this is the case, so your
  explanation would go here ;) ] To still fix the issue we deliberately
  replace these generic routines by AVR32 specific routines.  If someone
  can fix this using the generic patterns, patches are welcome.

I believe that good docmumentation should include such pro- and con
reasoning so that code changes can be comprehended even after the fact.

Cheers
  Detlev

-- 
Emacs seems a more likely candidate  to contain a mail system than the
mail system to contain an Emacs, so this is the way it was done.
-- Bernard S. Greenberg
--
DENX Software Engineering GmbH,  MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2 4/8] USB-CDC: Correct freeing usb requests

Fix in_ep and out_ep confusion (rx_req was allocated from out_ep, not
from in_ep) and add lost dev-req freeing.

Signed-off-by: Vitaly Kuzmichev vkuzmic...@mvista.com
---
 drivers/usb/gadget/ether.c |9 +++--
 1 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/gadget/ether.c b/drivers/usb/gadget/ether.c
index c287ec2..19a63de 100644
--- a/drivers/usb/gadget/ether.c
+++ b/drivers/usb/gadget/ether.c
@@ -839,7 +839,7 @@ static void eth_reset_config (struct eth_dev *dev)
if (dev-out) {
usb_ep_disable (dev-out_ep);
if (dev-rx_req) {
-   usb_ep_free_request (dev-in_ep, dev-rx_req);
+   usb_ep_free_request (dev-out_ep, dev-rx_req);
dev-rx_req=NULL;
}
}
@@ -1424,6 +1424,11 @@ static void eth_unbind (struct usb_gadget *gadget)
 
debug(%s...\n, __func__);
 
+   /* we've already been disconnected ... no i/o is active */
+   if (dev-req) {
+   usb_ep_free_request (gadget-ep0, dev-req);
+   dev-req = NULL;
+   }
if (dev-stat_req) {
usb_ep_free_request (dev-status_ep, dev-stat_req);
dev-stat_req = NULL;
@@ -1435,7 +1440,7 @@ static void eth_unbind (struct usb_gadget *gadget)
}
 
if (dev-rx_req) {
-   usb_ep_free_request (dev-in_ep, dev-rx_req);
+   usb_ep_free_request (dev-out_ep, dev-rx_req);
dev-rx_req=NULL;
}
 
-- 
1.7.1.1

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

[U-Boot] [PATCH v2 5/8] USB-CDC: Replace 'strcpy' by 'strlcpy'

Replace 'strcpy' by more safe 'strlcpy' that is implemented in ether.c

Signed-off-by: Vitaly Kuzmichev vkuzmic...@mvista.com
---
 drivers/usb/gadget/ether.c |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/gadget/ether.c b/drivers/usb/gadget/ether.c
index 19a63de..65f3ff9 100644
--- a/drivers/usb/gadget/ether.c
+++ b/drivers/usb/gadget/ether.c
@@ -1591,12 +1591,12 @@ static int eth_bind(struct usb_gadget *gadget)
if (bcdDevice)
device_desc.bcdDevice = cpu_to_le16(bcdDevice);
if (iManufacturer)
-   strcpy (manufacturer, iManufacturer);
+   strlcpy (manufacturer, iManufacturer, sizeof manufacturer);
if (iProduct)
-   strcpy (product_desc, iProduct);
+   strlcpy (product_desc, iProduct, sizeof product_desc);
if (iSerialNumber) {
device_desc.iSerialNumber = STRING_SERIALNUMBER,
-   strcpy(serial_number, iSerialNumber);
+   strlcpy(serial_number, iSerialNumber, sizeof serial_number);
}
 
/* all we really need is bulk IN/OUT */
-- 
1.7.1.1

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

[U-Boot] [PATCH v2 6/8] USB-CDC: Correct stat_req initialization

Fix possible oops on stat_req-buf initialization and fix ep0 and
status_ep confusion (last one is just intended for stat_req keeping).

Signed-off-by: Vitaly Kuzmichev vkuzmic...@mvista.com
Signed-off-by: Stefano Babic sba...@denx.de
---
 drivers/usb/gadget/ether.c |7 +++
 1 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/gadget/ether.c b/drivers/usb/gadget/ether.c
index 65f3ff9..03d8f0b 100644
--- a/drivers/usb/gadget/ether.c
+++ b/drivers/usb/gadget/ether.c
@@ -1729,14 +1729,13 @@ autoconf_fail:
/* ... and maybe likewise for status transfer */
 #if defined(DEV_CONFIG_CDC)
if (dev-status_ep) {
-   dev-stat_req = usb_ep_alloc_request(gadget-ep0, GFP_KERNEL);
-   dev-stat_req-buf = status_req;
+   dev-stat_req = usb_ep_alloc_request(dev-status_ep, 
GFP_KERNEL);
if (!dev-stat_req) {
-   dev-stat_req-buf=NULL;
-   usb_ep_free_request (gadget-ep0, dev-req);
+   usb_ep_free_request (dev-status_ep, dev-req);
 
goto fail;
}
+   dev-stat_req-buf = status_req;
dev-stat_req-context = NULL;
}
 #endif
-- 
1.7.1.1

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

Re: [U-Boot] [PATCH v2 3/8] USB-CDC: Use native debug printout macros

2010-08-13 Thread Rogan Dawes

On 2010/08/13 2:57 PM, Vitaly Kuzmichev wrote:
 Replace Linux-like debug printout macros by native ones.

 Signed-off-by: Vitaly Kuzmichevvkuzmic...@mvista.com
 ---
   drivers/usb/gadget/ether.c |   99 
 ---
   1 files changed, 46 insertions(+), 53 deletions(-)

 diff --git a/drivers/usb/gadget/ether.c b/drivers/usb/gadget/ether.c
 index a07738f..c287ec2 100644
 --- a/drivers/usb/gadget/ether.c
 +++ b/drivers/usb/gadget/ether.c
 @@ -20,6 +20,9 @@
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
*/

 +#define DEBUG
 +#undef DEBUG
 +

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

[U-Boot] [PATCH v2 7/8] USB-CDC: ethernet error path potential oops fix

Fix potential oops on rare error path.
The patch is based on commit e7b13ec9235b9fded90f826ceeb8c34548631351
(done by David Brownell davi...@pacbell.net) from linux-2.6.git.

Description of the issue taken from linux kernel bugzilla:
(https://bugzilla.kernel.org/show_bug.cgi?id=9594)

The potential error can be tracked down as follows:

(1) line 807: let the second conjunct on the if statment be false
meaning dev-status_ep is null. This means the if evaluates
to false.

follow thru the code until...

(2) line 808: usb_ep_disable(dev-status_ep) passes in a null argument,
however usb_ep_disable cannot handle that:

(from include/linux/usb/gadget.h)
191 static inline int
192 usb_ep_disable (struct usb_ep *ep)
193 {
194 return ep-ops-disable (ep);
195 }

--

Signed-off-by: Vitaly Kuzmichev vkuzmic...@mvista.com
---
 drivers/usb/gadget/ether.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/usb/gadget/ether.c b/drivers/usb/gadget/ether.c
index 03d8f0b..62dd008 100644
--- a/drivers/usb/gadget/ether.c
+++ b/drivers/usb/gadget/ether.c
@@ -804,7 +804,7 @@ done:
 
/* on error, disable any endpoints  */
if (result  0) {
-   if (!subset_active(dev))
+   if (!subset_active(dev)  dev-status_ep)
(void) usb_ep_disable (dev-status_ep);
dev-status = NULL;
(void) usb_ep_disable (dev-in_ep);
-- 
1.7.1.1

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

[U-Boot] [PATCH v2 8/8] USB-CDC: change simple_strtol to simple_strtoul

The patch is based on commit bb9496c6f7e853e5d4edd5397c9d45f1968d623c
(done by Julia Lawall ju...@diku.dk) from linux-2.6.git.

Since num is unsigned, it would seem better to use simple_strtoul that
simple_strtol.

Signed-off-by: Vitaly Kuzmichev vkuzmic...@mvista.com
---
 drivers/usb/gadget/epautoconf.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/usb/gadget/epautoconf.c b/drivers/usb/gadget/epautoconf.c
index c7fad39..e11cc20 100644
--- a/drivers/usb/gadget/epautoconf.c
+++ b/drivers/usb/gadget/epautoconf.c
@@ -156,7 +156,7 @@ ep_matches (
 
/* report address */
if (isdigit (ep-name [2])) {
-   u8  num = simple_strtol (ep-name [2], NULL, 10);
+   u8  num = simple_strtoul (ep-name [2], NULL, 10);
desc-bEndpointAddress |= num;
 #ifdef MANY_ENDPOINTS
} else if (desc-bEndpointAddress  USB_DIR_IN) {
-- 
1.7.1.1

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

Re: [U-Boot] [PATCH v2 3/8] USB-CDC: Use native debug printout macros

Hi,

Rogan Dawes wrote:
 +#define DEBUG
 +#undef DEBUG
 +
 
 Eh?

Such thing is used to let someone know that this driver supports debug
output through native U-Boot macros. So one need to comment #undef to
compile ether.c with debug messages.
There are at least 67 files in U-Boot that use such construction.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] [TESTING] da8xx: fixup ARM relocation support

2010-08-13 Thread Ben Gardiner

Split the existing dram_init for da8xx when ARM reloc is enabled, like the
changes to arch/arm/cpu/arm926ejs/orion5x/dram.c in
0f234d263b17ccf1b8fd776eb8c15b7cdb27a887 by Heiko Schocher h...@denx.de.

Without these changes gd-ram_size is '0' which leads to incorrect relocation
when CONFIG_SYS_ARM_WITHOUT_RELOC is defined and the board does not boot.

We use get_ram_size to dynamically calculate the available RAM because it runs
on different board version with different ram, as suggested by Heiko in private
communication.

Tested on a da850evm with 128M of DDR2 installed; with both
CONFIG_SYS_ARM_WITHOUT_RELOC defined and undefined.

Signed-off-by: Ben Gardiner bengardi...@nanometrics.ca
---
 board/davinci/common/misc.c |   17 +
 include/configs/da850evm.h  |1 +
 2 files changed, 18 insertions(+), 0 deletions(-)

diff --git a/board/davinci/common/misc.c b/board/davinci/common/misc.c
index 25ca326..e8acefe 100644
--- a/board/davinci/common/misc.c
+++ b/board/davinci/common/misc.c
@@ -33,6 +33,7 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
+#if defined(CONFIG_SYS_ARM_WITHOUT_RELOC)
 int dram_init(void)
 {
gd-bd-bi_dram[0].start = PHYS_SDRAM_1;
@@ -40,6 +41,22 @@ int dram_init(void)
 
return(0);
 }
+#else
+int dram_init(void)
+{
+   /* dram_init must store complete ramsize in gd-ram_size */
+   gd-ram_size = get_ram_size(
+   (volatile void *)CONFIG_SYS_SDRAM_BASE,
+   CONFIG_MAX_RAM_BANK_SIZE);
+   return(0);
+}
+
+void dram_init_banksize (void)
+{
+   gd-bd-bi_dram[0].start = CONFIG_SYS_SDRAM_BASE;
+   gd-bd-bi_dram[0].size = gd-ram_size;
+}
+#endif
 
 #ifdef CONFIG_DRIVER_TI_EMAC
 
diff --git a/include/configs/da850evm.h b/include/configs/da850evm.h
index 016a21e..c929f6b 100644
--- a/include/configs/da850evm.h
+++ b/include/configs/da850evm.h
@@ -47,6 +47,7 @@
 #define CONFIG_SYS_GBL_DATA_SIZE   128 /* reserved for initial data */
 #define PHYS_SDRAM_1   DAVINCI_DDR_EMIF_DATA_BASE /* DDR Start */
 #define PHYS_SDRAM_1_SIZE  (64  20) /* SDRAM size 64MB */
+#define CONFIG_MAX_RAM_BANK_SIZE (512  20) /*DDR2 Data region maximum size 
from SPRS586*/
 
 /* memtest start addr */
 #define CONFIG_SYS_MEMTEST_START   (PHYS_SDRAM_1 + 0x200)
-- 
1.7.0.4

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

Re: [U-Boot] [PATCH] UEC PHY: Speed up initial PHY neg.

2010-08-13 Thread Joakim Tjernlund

Detlev Zundel d...@denx.de wrote on 2010/08/13 10:20:46:

 Hi Jocke,

   Instead of always performing an autoneg, check if the PHY
   already has a link and if it matches one of the requested
   modes. Initially only 100MbFD is optimized this way.
 
  Isn't it about time that we think about _not_ stopping the ethernet
  device after every transaction?
 
  Hi Detlev
 
  UEC does this already, my patch was to address the initial delay
  you get for the first transaction. Now my PHY based boards gets the link
  up just as quick as Fixed PHY for the first transaction.

 Forgive me to not look into this any deeper, but do I understand you
 correctly that you do this by essentially no-oping the eth_halt()
 function?  Isn't this then effectively violating what net.c expects the
 device to do?

uec_halt stops the controller as it should. Uec forces an auto_neg
cycle on the PHY the first it is called, after that it just uses
the result from the first auto neg.
My patch simply skip the auto neg. pass iff the PHY already has
a link and duplexspeed already matches what uec wants.

Jocke

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

Re: [U-Boot] [PATCH v2 3/8] USB-CDC: Use native debug printout macros


Vitaly Kuzmichev wrote:
 There are at least 67 files in U-Boot that use such construction.
I was wrong.
I calculated for linux/drivers directory.
Actually 13 for u-boot.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 3/8] USB-CDC: Use native debug printout macros

Vitaly Kuzmichev wrote:
 Hi,
 
 Rogan Dawes wrote:
 +#define DEBUG
 +#undef DEBUG
 +
 Eh?
 
 Such thing is used to let someone know that this driver supports debug
 output through native U-Boot macros. So one need to comment #undef to
 compile ether.c with debug messages.
 There are at least 67 files in U-Boot that use such construction.

Well, but probably it is better to remove both lines. In the rest of
u-boot, DEBUG is neither set or unset - you see only #ifdef DEBUG or
#ifndef DEBUG. You have found the examples how we should not do...

If you want to remember how to set the debug output, it should be enough
to add a comments with to enable the debugging, define DEBUG before
common.h or something like that. I vote to remove only the two lines...

Best regards,
Stefano

-- 
=
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 v2] [TESTING] da8xx: fixup ARM relocation support

2010-08-13 Thread Ben Gardiner

Split the existing dram_init for da8xx when ARM reloc is enabled, like the
changes to arch/arm/cpu/arm926ejs/orion5x/dram.c in
0f234d263b17ccf1b8fd776eb8c15b7cdb27a887 by Heiko Schocher h...@denx.de.

Without these changes gd-ram_size is '0' which leads to incorrect relocation
when CONFIG_SYS_ARM_WITHOUT_RELOC is defined and the board does not boot.

We use get_ram_size to dynamically calculate the available RAM because it runs
on different board version with different ram, as suggested by Heiko in private
communication.

Tested on a da850evm with 128M of DDR2 installed; with both
CONFIG_SYS_ARM_WITHOUT_RELOC defined and undefined.

Signed-off-by: Ben Gardiner bengardi...@nanometrics.ca
---
This patch is submitted for the arm-reloc-and-cache-support branch of 
git://git.denx.de/u-boot-testing.git

V2:
 * added Nori Sehkar to the to: list
 * indicated for which branch of testing this patch is submitted.

 board/davinci/common/misc.c |   17 +
 include/configs/da850evm.h  |1 +
 2 files changed, 18 insertions(+), 0 deletions(-)

diff --git a/board/davinci/common/misc.c b/board/davinci/common/misc.c
index 25ca326..e8acefe 100644
--- a/board/davinci/common/misc.c
+++ b/board/davinci/common/misc.c
@@ -33,6 +33,7 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
+#if defined(CONFIG_SYS_ARM_WITHOUT_RELOC)
 int dram_init(void)
 {
gd-bd-bi_dram[0].start = PHYS_SDRAM_1;
@@ -40,6 +41,22 @@ int dram_init(void)
 
return(0);
 }
+#else
+int dram_init(void)
+{
+   /* dram_init must store complete ramsize in gd-ram_size */
+   gd-ram_size = get_ram_size(
+   (volatile void *)CONFIG_SYS_SDRAM_BASE,
+   CONFIG_MAX_RAM_BANK_SIZE);
+   return(0);
+}
+
+void dram_init_banksize (void)
+{
+   gd-bd-bi_dram[0].start = CONFIG_SYS_SDRAM_BASE;
+   gd-bd-bi_dram[0].size = gd-ram_size;
+}
+#endif
 
 #ifdef CONFIG_DRIVER_TI_EMAC
 
diff --git a/include/configs/da850evm.h b/include/configs/da850evm.h
index 016a21e..c929f6b 100644
--- a/include/configs/da850evm.h
+++ b/include/configs/da850evm.h
@@ -47,6 +47,7 @@
 #define CONFIG_SYS_GBL_DATA_SIZE   128 /* reserved for initial data */
 #define PHYS_SDRAM_1   DAVINCI_DDR_EMIF_DATA_BASE /* DDR Start */
 #define PHYS_SDRAM_1_SIZE  (64  20) /* SDRAM size 64MB */
+#define CONFIG_MAX_RAM_BANK_SIZE (512  20) /*DDR2 Data region maximum size 
from SPRS586*/
 
 /* memtest start addr */
 #define CONFIG_SYS_MEMTEST_START   (PHYS_SDRAM_1 + 0x200)
-- 
1.7.0.4

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

Re: [U-Boot] [PATCH v2 3/8] USB-CDC: Use native debug printout macros

Hi Stefano,

Stefano Babic wrote:
 If you want to remember how to set the debug output, it should be enough
 to add a comments with to enable the debugging, define DEBUG before
 common.h or something like that. I vote to remove only the two lines...

Would not it be better to make one of the following?
1)
#if 0
#define DEBUG
#endif

2)
#ifdef CONFIG_USB_ETH_DEBUG
#define DEBUG
#endif
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] mirror u-boot on github

2010-08-13 Thread Ben Gardiner

On Thu, Aug 12, 2010 at 4:06 PM, Wolfgang Denk w...@denx.de wrote:
 [...] certainly not going to do it. Their ToS are not acceptable to me.

 For example: E2. Prices of all Services, including but not limited
 to monthly subscription plan fees to the Service, are subject to
 change upon 30 days notice from us. Such notice may be provided at
 any time by posting the changes to the GitHub Site (github.com) or
 the Service itself. I understand that github may run your project
 for free until you put enough effort in it that losing it would be
 painful, and then they could decide that the service is no loger
 free, but they charge you $$$ for it. All they have to do is posting
 the changes to the GitHub Site (github.com) or the Service itself.
 That means chances are good that you don't even notice such change in
 time. They have your e-mail addresses - why don't they actively
 notify about such changes?

 G11 might be another reason not to use github. Better not use them for
 a project which receives any better interest than average.

I must admit that I didn't really consider the ramifications of the
terms of service at github -- you make a couple good points there.

 In message aanlktinwdrkfow1wlziw2vc8mu7cqymdmw1qqeln6...@mail.gmail.com you 
 wrote:
 The mirror on github would not be a replacement for the custodian
 trees[3] but it can be a useful starting point for staging long
 patches. Forks of github repos are easy to create and can be public
 right away meaning a long patch series can be easy for the custodians
 to pull and easy for testers to pull.

 I want to keep with the requirement that all patches have to go
 through a single channel where everybody can take part in the
 reviewing preocess even in early phases - i. e. postings on the
 mailing list. git-am makes it trivial enough to apply such patches.

Yes I totally agree. Please allow me to clarify that I do not want to
stop patches being sent to the ML.

'git am' works fine for me also -- once the patches are downloaded
from the mailing list. It is the downloading process with which I
currently have trouble. I'll focus on streamlining that part of my
process so that I can work as the rest of the u-boot developers do.

 But, given their current ToS, I will not work with github in any way.

Thank you for taking the time to read through their ToS and for
considering my request. I appreciate you sharing your interpretation
of github's ToS.

Best Regards,
Ben Gardiner

---
Nanometrics Inc.
http://www.nanometrics.ca
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 3/8] USB-CDC: Use native debug printout macros

2010-08-13 Thread Rogan Dawes

On 2010/08/13 3:40 PM, Vitaly Kuzmichev wrote:
 Hi Stefano,

 Stefano Babic wrote:
 If you want to remember how to set the debug output, it should be enough
 to add a comments with to enable the debugging, define DEBUG before
 common.h or something like that. I vote to remove only the two lines...

 Would not it be better to make one of the following?
 1)
 #if 0
 #define DEBUG
 #endif

 2)
 #ifdef CONFIG_USB_ETH_DEBUG
 #define DEBUG
 #endif

Personally, I like option 2, as it means that I have less need to touch 
general code when trying to debug my board.

I can just define that in my board config. Although, that could lead to 
a proliferation of *_DEBUG defines, which may or may not be documented.

Perhaps without the CONFIG_ part, and people who are trying to debug 
their boards need to read the code anyway to determine what debugging 
can be enabled?

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

[U-Boot] NetConsole and network API

Hi all,

I have seen an issue using netconsole and I am asking myself if there is
a problem in the actual concept of a network interface in u-boot.

I admit soon I have not used a normal network controller, but I ran
NetConsole on Ethernet over USB. However, I have checked with other
network drivers  (smc9111.c, for example) and I can imagine there are
similar problems.

The assumption we have is that any network command is atomic.
Any network command initializes the interface, uses it (eth_send(), ..)
and at the end deactivates the interface (eth_halt()). This makes an
application as netconsole simply unusable, because it is not thinkable
that after any message the interface is put in a down state. Not only,
it makes impossible to use network commands as TFTP inside netconsole,
because they try to initialize the same interface that netconsole uses.

Of course, in my case things get even worse. After any network command,
the eth_halt() callback is called, making the interface disappearing on
the host side. And any time the host starts to enumerate again the
interface, setting MAC, etc.

Well, I have fixed this issue avoiding the interface is initialized or
stopped after each command, but it seems this is a general problem. I
see in other drivers that the phy is set or stop after each command, and
this should generate the same problems I noted with USB.

My main question to the ML is, independently from the particular problem
on my target, if we should change the actual concept. For example, if we
provide to stop all devices only before booting an OS, but leaving them
alive after the first initialization. I understand that this generate
other issues (as u-boot cannot recognize that a cable was removed and
inserted again), but it makes the system usable in other circumstances.

Any thought about this ?

Best regards,
Stefano Babic

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

Re: [U-Boot] [PATCH 2/3] Connect the AT91 UDC to USB CDC-ethernet support

Dear Remy Bohmer,

In message aanlkti=er+5zty_s0he8qr460qntehxs1izsfntop...@mail.gmail.com you 
wrote:
 
   So broken that you cannot get back to the command line interpreter?
   Really?
 
  If malloc is broken, I consider that reason enough for hang/reboot...
 
  That's not a good idea. =A0Please fix.
 
 Fix what?
 If runtime a condition is detected that should _never_ _ever_ happen
 (like malloc does not work properly for some reason), which would even
 make Linux OOPS or panic may not result in a hang() on U-boot?

malloc() is not broken, it just has not enough resources to fulfil
your request. That does not mean that the rest of the system (which
does not make any such requests) would not be able to continue.

 In that case I can remove the hang() and consider if it never
 happened. Maybe even the code will reach the prompt, but there will be
 no guarantees...

Fail the running command with appropriate error message and returen
code, but do not decide for the user if he is able and willing to
continue.

 I personally consider that worse compared to tell the user that
 something serious has gone wrong...

Of course we have to issue appropriate error messages and return
codes, but there is no need to halt the system.

You stop your car, but you don't (usually) take it to a knacker's
yard when there is a flat tire.



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
Respect is a rational process
-- McCoy, The Galileo Seven, stardate 2822.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 3/8] USB-CDC: Use native debug printout macros

Dear Vitaly Kuzmichev,

In message 1281704276-29115-1-git-send-email-vkuzmic...@mvista.com you wrote:
 Replace Linux-like debug printout macros by native ones.
 
 Signed-off-by: Vitaly Kuzmichev vkuzmic...@mvista.com
 ---
  drivers/usb/gadget/ether.c |   99 ---
  1 files changed, 46 insertions(+), 53 deletions(-)
 
 diff --git a/drivers/usb/gadget/ether.c b/drivers/usb/gadget/ether.c
 index a07738f..c287ec2 100644
 --- a/drivers/usb/gadget/ether.c
 +++ b/drivers/usb/gadget/ether.c
 @@ -20,6 +20,9 @@
   * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
   */
  
 +#define DEBUG
 +#undef DEBUG
 +

NAK. Please remove this dead 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
Every program has at least one bug and can be shortened by  at  least
one  instruction  --  from  which,  by induction, one can deduce that
every program can be reduced to one instruction which doesn't work.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 3/8] USB-CDC: Use native debug printout macros

Dear Vitaly Kuzmichev,

In message 4c6544b9.3000...@mvista.com you wrote:
 
  +#define DEBUG
  +#undef DEBUG
  +
  
  Eh?
 
 Such thing is used to let someone know that this driver supports debug
 output through native U-Boot macros. So one need to comment #undef to
 compile ether.c with debug messages.
 There are at least 67 files in U-Boot that use such construction.

Patches to clean up these are welcome.

I will NAK this whenever I see it.

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
PLEASE NOTE: Some Quantum Physics Theories Suggest That When the Con-
sumer Is Not Directly Observing This Product, It May Cease  to  Exist
or Will Exist Only in a Vague and Undetermined State.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 3/8] USB-CDC: Use native debug printout macros

Dear Vitaly Kuzmichev,

In message 4c654b30.9060...@mvista.com you wrote:
 Hi Stefano,
 
 Stefano Babic wrote:
  If you want to remember how to set the debug output, it should be enough
  to add a comments with to enable the debugging, define DEBUG before
  common.h or something like that. I vote to remove only the two lines...
 
 Would not it be better to make one of the following?
 1)
 #if 0
 #define DEBUG
 #endif
 
 2)
 #ifdef CONFIG_USB_ETH_DEBUG
 #define DEBUG
 #endif

NAK.

It is so trivial o #define DEBUG (either in the file or on the command
line) that thhere is zero need for any clever wrappers around this.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Behind every great man, there is a woman -- urging him on.
-- Harry Mudd, I, Mudd, stardate 4513.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 3/8] USB-CDC: Use native debug printout macros

Vitaly Kuzmichev wrote:
 Hi Stefano,


Hi Vitaly,

 Stefano Babic wrote:
 If you want to remember how to set the debug output, it should be enough
 to add a comments with to enable the debugging, define DEBUG before
 common.h or something like that. I vote to remove only the two lines...
 
 Would not it be better to make one of the following?
 1)
 #if 0
 #define DEBUG
 #endif

However, this is seen as dead code. As this one, my preferance is to set
only a comment (I see several files in u-boot with such a comment, for
example arch/arm/lib/board.c).

 
 2)
 #ifdef CONFIG_USB_ETH_DEBUG
 #define DEBUG
 #endif

It is ok, but it generates another new CONFIG_ switch, that is unusable
for the rest of u-boot. I agree that in u-boot there is a lot of
different and local functions to setup, and probably a general mechanism
should be better defined. However, setting #define DEBUG before any
include files is quite usual. I do not like to set a CONFIG_ switch only
for debug purpose, as in the delivered system all debug output should be
turned off.

Best regards,
Stefano

-- 
=
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] [PATCH 00/26] arm: add full relocation / cache support

2010-08-13 Thread Shinya Kuribayashi

On 8/13/10 5:17 AM, Wolfgang Denk wrote:
 http://elinux.org/CELF_Project_Proposal/Rework_ARM_architecture_support_in_U-Boot

 Yes, this is the one.
[snip[
 If you read the thread you can see that both Heikos tests and other
 testers who tried that code see dramatic speed improvements due to
 enabling the cache; in addition to that we win all the flexibility of
 RAM usage we are used to from other architectures.

Thanks, I'll think about it
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 3/8] USB-CDC: Use native debug printout macros

2010-08-13 Thread Sergei Shtylyov

Hello.

Vitaly Kuzmichev wrote:

 Rogan Dawes wrote:

 +#define DEBUG
 +#undef DEBUG
 +

 Eh?

 Such thing is used to let someone know that this driver supports debug
 output through native U-Boot macros. So one need to comment #undef to
 compile ether.c with debug messages.
 There are at least 67 files in U-Boot that use such construction.

I'd suggest leaving just #undef DEBUG (which can be edited into #define 
DEBUG if desired)...

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

[U-Boot] [PATCH] MX51: Update responsible for mx51evk

Signed-off-by: Stefano Babic sba...@denx.de
---
 MAINTAINERS |5 +
 1 files changed, 1 insertions(+), 4 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 4b91b0f..6699393 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -152,10 +152,6 @@ Dave Ellis d...@sixnetio.com
 
SXNI855TMPC8xx
 
-Fred Fan fanyef...@gmail.com
-
-   mx51evk i.MX51
-
 Thomas Frieden thom...@hyperion-entertainment.com
 
AmigaOneG3SEMPC7xx
@@ -549,6 +545,7 @@ Stefano Babic sba...@denx.de
 
polaris xscale
trizepsiv   xscale
+   mx51evk i.MX51
 
 Dirk Behme dirk.be...@gmail.com
 
-- 
1.6.3.3

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

[U-Boot] [RFC][PATCH 1/3] DDR2: Support new JEDEC DDR2 SPD 1.3 spec

2010-08-13 Thread Kyle Moffett

The new DDR2 SPD spec is backwards-compatible with the old one, but
there are DIMMs which are being produced which have new SPD version
fields that fail to work with U-boot.

To make the code a bit more readable, we add some human-readable
SPD_DIMM_TYPE_* constants.

Signed-off-by: Kyle Moffett kyle.d.moff...@boeing.com
---
 common/ddr_spd.c   |4 ++--
 cpu/mpc8xxx/ddr/ddr2_dimm_params.c |   30 ++
 2 files changed, 24 insertions(+), 10 deletions(-)

diff --git a/common/ddr_spd.c b/common/ddr_spd.c
index c058e4f..f7a482e 100644
--- a/common/ddr_spd.c
+++ b/common/ddr_spd.c
@@ -18,9 +18,9 @@ spd_check(const u8 *buf, u8 spd_rev, u8 spd_cksum)
 
/*
 * Check SPD revision supported
-* Rev 1.2 or less supported by this code
+* Rev 1.3 or less supported by this code
 */
-   if (spd_rev  0x12) {
+   if (spd_rev  0x13) {
printf(SPD revision %02X not supported by this code\n,
   spd_rev);
return 1;
diff --git a/cpu/mpc8xxx/ddr/ddr2_dimm_params.c 
b/cpu/mpc8xxx/ddr/ddr2_dimm_params.c
index d9d0fa7..2d40a60 100644
--- a/cpu/mpc8xxx/ddr/ddr2_dimm_params.c
+++ b/cpu/mpc8xxx/ddr/ddr2_dimm_params.c
@@ -9,6 +9,17 @@
 #include common.h
 #include asm/fsl_ddr_sdram.h
 
+/* These are all the types defined by the JEDEC DDR2 SPD 1.3 spec */
+#define SPD_DIMM_TYPE_UNDEFINED0x00
+#define SPD_DIMM_TYPE_RDIMM0x01
+#define SPD_DIMM_TYPE_UDIMM0x02
+#define SPD_DIMM_TYPE_SO_DIMM  0x04
+#define SPD_DIMM_TYPE_72B_SO_CDIMM 0x06
+#define SPD_DIMM_TYPE_72B_SO_RDIMM 0x07
+#define SPD_DIMM_TYPE_MICRO_DIMM   0x08
+#define SPD_DIMM_TYPE_MINI_RDIMM   0x10
+#define SPD_DIMM_TYPE_MINI_UDIMM   0x20
+
 #include ddr.h
 /*
  * Calculate the Density of each Physical Rank.
@@ -250,20 +261,23 @@ ddr_compute_dimm_parameters(const ddr2_spd_eeprom_t *spd,
pdimm-primary_sdram_width = spd-primw;
pdimm-ec_sdram_width = spd-ecw;
 
-   /* FIXME: what about registered SO-DIMM? */
+   /* These are all the types defined by the JEDEC DDR2 SPD 1.3 spec */
switch (spd-dimm_type) {
-   case 0x01:  /* RDIMM */
-   case 0x10:  /* Mini-RDIMM */
-   pdimm-registered_dimm = 1; /* register buffered */
+   case SPD_DIMM_TYPE_RDIMM:
+   case SPD_DIMM_TYPE_72B_SO_RDIMM:
+   case SPD_DIMM_TYPE_MINI_RDIMM:
+   /* Registered/buffered DIMMs */
+   pdimm-registered_dimm = 1;
break;
 
-   case 0x02:  /* UDIMM */
-   case 0x04:  /* SO-DIMM */
-   case 0x08:  /* Micro-DIMM */
-   case 0x20:  /* Mini-UDIMM */
+   case SPD_DIMM_TYPE_UDIMM:
+   case SPD_DIMM_TYPE_SO_DIMM:
+   case SPD_DIMM_TYPE_MICRO_DIMM:
+   case SPD_DIMM_TYPE_MINI_UDIMM:
pdimm-registered_dimm = 0; /* unbuffered */
break;
 
+   case SPD_DIMM_TYPE_72B_SO_CDIMM:
default:
printf(unknown dimm_type 0x%02X\n, spd-dimm_type);
return 1;
-- 
1.7.1

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

[U-Boot] [RFC] Board support patches for the eXMeritus HWW-1U-1A devices

2010-08-13 Thread Kyle Moffett

Hello all!

This is my first U-Boot submission, so my apologies if there are any coding
style or conventions issues.  Please let me know and I'll get them fixed up
shortly.

In addition, these patches were based on v2010.03 and I realize that the
upstream may have diverged a bit since then.  Please let me know what
GIT version I should rebase these patches on for future submissions.

The eXMeritus HWW-1U-1A unit is a DO-160-certified 13lb 1U chassis
with 3 independent TEMPEST zones.  Two independent P2020 computers may
be found inside each zone.  Complete hardware support is included.

There are a couple preliminary patches to common code, but basically
everything else is limited to our own board-support code.

I look forward to your comments and criticisms!

Cheers,
Kyle Moffett

--
Overall diffstat below:
 MAKEALL   |2 +
 Makefile  |4 +
 board/exmeritus/hww-1u-1a/Makefile|   54 +++
 board/exmeritus/hww-1u-1a/config.mk   |   31 ++
 board/exmeritus/hww-1u-1a/ddr.c   |  136 +++
 board/exmeritus/hww-1u-1a/gpios.h |  131 ++
 board/exmeritus/hww-1u-1a/hww-1u-1a.c |  697 +
 board/exmeritus/hww-1u-1a/law.c   |   40 ++
 board/exmeritus/hww-1u-1a/tlb.c   |   93 +
 common/ddr_spd.c  |4 +-
 cpu/mpc85xx/cpu.c |7 +-
 cpu/mpc8xxx/ddr/ddr2_dimm_params.c|   30 +-
 drivers/net/e1000.c   |7 +
 include/configs/HWW_1U_1A.h   |  478 ++
 14 files changed, 1702 insertions(+), 12 deletions(-)

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

[U-Boot] [RFC][PATCH 2/3] e1000: Intel 82571EB: Don't wait for MNG cycle on unmanaged chips

2010-08-13 Thread Kyle Moffett

The Intel 82571EB chipset can be used in an unmanaged configuration as a
fast dual-port Gig-E controller.  Unfortunately a board consturcted that
way would fail to correctly come up because the driver polls for the
completion of a management cycle that will never occur.

To resolve this problem, we disable the poll and error return on chips
whose EEPROMS indicate no management.  As a protection against
misconfigured chipsets, we still delay for the entire management poll
timeout.

Signed-off-by: Kyle Moffett kyle.d.moff...@boeing.com
---
 drivers/net/e1000.c |7 +++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/drivers/net/e1000.c b/drivers/net/e1000.c
index 2825342..c9677b4 100644
--- a/drivers/net/e1000.c
+++ b/drivers/net/e1000.c
@@ -4266,6 +4266,13 @@ e1000_get_phy_cfg_done(struct e1000_hw *hw)
/* Fall Through */
case e1000_82571:
case e1000_82572:
+   /* Don't bother polling the management regs if unmanaged */
+   if (!e1000_check_mng_mode(hw)) {
+   DEBUGOUT(Unmanaged chip... skipping MNG polling\n);
+   mdelay(timeout);
+   return 0;
+   }
+
while (timeout) {
if (E1000_READ_REG(hw, EEMNGCTL)  cfg_mask)
break;
-- 
1.7.1

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

Re: [U-Boot] [PATCH] Fix typo inside atmel_mci driver

Claudio Mignanti wrote:
 2010/8/7 Reinhard Meyer reinhard.me...@emk-elektronik.de:
 Wolfgang Denk wrote:
 Dear Claudio Mignanti,

 In message aanlktikknw19u8yiqokqye-wxjuo4b8rwqo-ibpa1...@mail.gmail.com
 you wrote:

 The function get_mci_clk_rate is used inside atmel_mci driver
  but never defined. Fix this typo.

 Thats NOT a typo. The current atmel_mci.c is for AVR32 ONLY.
 
  With the proposed patch I successfully use this driver on at91sam9g20!
 Probabily they share the same mci controller I don't know, I want only
 report this experience.

NAK. That will break the driver for AVR32.

The correct way is to add get_mci_clk_rate() to clk.h:

diff --git a/arch/arm/include/asm/arch-at91/clk.h 
b/arch/arm/include/asm/arch-at91/clk.h
index f642dd9..457e6c9 100644
--- a/arch/arm/include/asm/arch-at91/clk.h
+++ b/arch/arm/include/asm/arch-at91/clk.h
@@ -59,5 +59,10 @@ static inline unsigned long get_twi_clk_rate(unsigned int 
dev_id)
return get_mck_clk_rate();
  }

+static inline unsigned long get_mci_clk_rate(void)
+{
+   return get_mck_clk_rate();
+}
+
  int at91_clock_init(unsigned long main_clock);
  #endif /* __ASM_ARM_ARCH_CLK_H__ */

On AVR32 there is no MCK and each peripherals' clock can be prescaled 
individually.
Its just that the current AT91 have all clocks the same.

Best Regards,
Reinhard

PS: that driver will soon become obsolete, because a new, mmc framework based 
driver
is in the mold already.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2a] AT91: add SD/MMC support

Dear Schleifer, Alexander,
 Thanks for your reply...
 
 The CID part is:
 mmc: response: 1a50514d 53202020 1018301a ec007b8b
 Manufacturer ID:   1A
 OEM/Application ID:5051
 Product name:  MS
 Product Revision:  1.0
 Product Serial Number: 405805804
 Manufacturing Date:07/11
 
 The CSD part is:
 mmc: response: 005e0032 5f5983cf edb6ff87 9640003f
 raw CSD data: 005e0032 5f5983cf edb6ff87 9640003f
 Read block length: 512
   (Supports partial reads)
 Card capacity: 244 Mbytes
 Warning: Using maximum data timeout
 mmc: Using 983040 cycles data timeout (DTOR=0x7f)

I miss the clock messages here. Whats the MCK and which divider is calculated?

 mmc: bread failed, status = 0040c0e5, card status = 0900
0040c0e5=
DTOE=1(data time out error)
TXBUFE=1
RXBUFF=1(rx buffer full)
and other bits

That seems to me like some timing problem, or a hardware problem,
where reading data with slow clock (used to get CID/CSD) works,
but reading at several MHz (depending on card) does not work.
Besides the clock calculation in this driver rounds the divider
down, so on a typical system a 25MHz card will receive a 48 MHz
clock instead of a 24 MHz. I figured this out while testing the
new driver...

If you really want to bother with this now old driver use this
excerpt from the new driver:

debug(mci: bus_hz is %u, setting clock %u Hz, block size %u\n,
bus_hz, hz, blklen);
if (hz  0) {
/* find lowest clkdiv yielding a rate = than requested */
for (clkdiv=0; clkdiv255; clkdiv++) {
if ((bus_hz / (clkdiv+1) / 2) = hz)
break;
}
}
printf(mci: setting clock %u Hz, block size %u\n,
(bus_hz / (clkdiv+1)) / 2, blklen);

If you have two days patience, wait for the new driver, I will be
most happy to have a tester ;)

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

Re: [U-Boot] [PATCH] env_nand: return error when no device is found

2010-08-13 Thread Scott Wood

On Wed, Aug 11, 2010 at 11:42:26PM -0400, Mike Frysinger wrote:
 Currently, if there is an error probing the NAND chip and the env is based
 in NAND, the readenv() function will use a NULL function pointer and thus
 jump to address 0.
 
 Here I just check for a non-zero value of blocksize as that shouldn't be
 zero when a valid device is found, but perhaps there is a better way for
 someone familiar with the NAND internals to suggest.
 
 Signed-off-by: Mike Frysinger vap...@gentoo.org
 ---
  common/env_nand.c |2 ++
  1 files changed, 2 insertions(+), 0 deletions(-)

Applied to u-boot-nand-flash.

-Scott

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

Re: [U-Boot] NetConsole and network API

2010-08-13 Thread Joe Hershberger

On Fri, Aug 13, 2010 at 8:52 AM, Stefano Babic sba...@denx.de wrote:
 My main question to the ML is, independently from the particular problem
 on my target, if we should change the actual concept. For example, if we
 provide to stop all devices only before booting an OS, but leaving them
 alive after the first initialization. I understand that this generate
 other issues (as u-boot cannot recognize that a cable was removed and
 inserted again), but it makes the system usable in other circumstances.

I've run into the same issue and patched net.c a bit to improve the
behavior of the NetConsole use case.  It's a surgical change, though,
not a fundamental change to how the network subsystem works.  Only if
using NetConsole do you get this behavior.  And even if using other
network operations with NetConsole, those other operations mostly
maintain their current behavior.

I'll post the patch at some point in the next month or so when I can
get the time to extract it and test it on modern u-boot.

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

Re: [U-Boot] [PATCH 1/8] USB-CDC: Restuct USB gadget Makefile

Hi,

2010/8/12 Vitaly Kuzmichev vkuzmic...@mvista.com:
 Prohibit simultaneous usage of both old and new gadget stacks and
 allow UDC drivers to be dependent on CONFIG_USB_ETHER.

 Signed-off-by: Vitaly Kuzmichev vkuzmic...@mvista.com
 ---
  drivers/usb/gadget/Makefile |    9 ++---
  1 files changed, 6 insertions(+), 3 deletions(-)

Applied to u-boot-usb/cdc branch.
Thanks.

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

Re: [U-Boot] TFTP timeout issue while downloading the linux kernel in openpxa vpac270 u-boot source code

2010-08-13 Thread Marek Vasut

Dne Pá 13. srpna 2010 12:27:12 StephenPaulraj Chinnadurai-ERS,HCLTech napsal(a):
 Dear Marek,
 
YOU DROPPED THE MAILING LIST AGAIN !! HOW MANY TIMES DO I HAVE TO TELL YOU TO 
KEEP IT CCED ?!

 Even if I assign 0x1234 to MSC2 I am getting the same timeout problem.

Because 0x1234 is 16 bit bus ... dont you use 32bit bus to that card ?
 
 Can you suggest me some other solution?
 
 Is this problem because of static memory configuration?
 
Check the bus with a scope I guess, that should give you some ideas.

 Where should I concentrate for the solution, whether in net/tftp.c file or
 in drivers/net/smc9.c file?

You can enable debuging output in the smc9 driver.
 
 Kindly guide me to come out the problem.
 
 Thanks and Regards
 Stephen Paulraj C
 
 HCL Technologies Ltd.
 D-12, Sidco Industrial Estate,
 Ambattur, Chennai -58
 Tel: +91 44  42004800 Extn: 2319
 Mob:+91 9962583934
 www.hcl.in
 
 -Original Message-
 From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On
 Behalf Of Marek Vasut Sent: Thursday, August 12, 2010 11:05 PM
 To: StephenPaulraj Chinnadurai-ERS,HCLTech
 Cc: u-boot@lists.denx.de
 Subject: Re: [U-Boot] TFTP timeout issue while downloading the linux kernel
 in openpxa vpac270 u-boot source code
 
 Dne Čt 12. srpna 2010 19:11:29 StephenPaulraj Chinnadurai-ERS,HCLTech 
napsal(a):
  Hello Marek,
  
  I am using a customize board which has PXA270 controller.  SMCS
  LAN91C111Ii-NU is connected to the static memory 4 (nCS4).
 
 I see, so it's not vpac270 bug.
 
  I have defined following macro value in the include/configs/myboard.h
  file.
  
  #define CONFIG_SYS_GPDR2_VAL0x70DF3FFF
  GPIO 80 is configured as output
  
  #define CONFIG_SYS_GPSR2_VAL0x1001 /*nCS4*/
  GPIO 80 is set
 
 You don't really need to configure these if you then set it to AF2.
 
  #define CONFIG_SYS_GAFR2_U_VAL  0x1504A176
  Alternate function 2 is selected for GPIO 80
  
  #define CONFIG_SYS_MSC2_VAL 0xB884
 
 Zylonite 300 uses value 0x3c for the SMC9 in the corresponding part of
 MSCx register in original Marvell sources, Zylonite320 uses 0x123c ...
 maybe you should review the MSCx configuration here. For pxa27x, I guess
 it might be something like 0x123c too.
 
 From the log below, it really seems the ethernet chip is choking.
 
 Cheers
 
  RT4 = 4  Variable Latency I/O (VLIO)
  
  ROM4 Bus Width
  0 = 32 Bits
  
  RDF4 = 8
  
  RDN4 = 8
  
  RRR4 = 3
  
  RBUFF4 = 1 Faster device
  
  #define CONFIG_SMC9
  #define CONFIG_SMC9_BASE0x1300 /*nCS4*/
  #define CONFIG_SMC_USE_32_BIT
  #undef  CONFIG_SMC_9_EXT_PHY
  
  
  Ethernet controller is working fine. I can able to ping the machines
  connected to the network.
  
  tftpboot command is also working fine, I can able to download the
  u-boot.bin to SDRAM.
  
  But I have issue in downloading bigger files (zImage which is 2.5 MB) to
  the SDRAM. I am getting the following timeout messages and the download
  is not getting completed.
  
  Loading: *T T T T T T T T T T T T T T T T T T T T
  Retry count exceeded; starting again
  
  Please help me to come out of this issue.
  
  Kindly find the complete log below:
  
  __
  
  
  U-Boot 2010.06-rc1 (Aug 13 2010 - 09:11:31)
  
  
  DRAM:  128 MiB
  
  Flash: 64 MiB
  
  In:serial
  
  Out:   serial
  
  Err:   serial
  
  Net:   SMC9-0
  
  Hit any key to stop autoboot:  2 ___ 0
  
  MDT-Boot print
  
  bootargs=console=tty0 console=ttyS1, root=/dev/sda1 rootdelay=15
  
  bootcmd=if mmc init  fatload mmc 0 0xa000 uImage; then bootm
  0xa000; fi; if usb reset  fatload usb 0 0xa000 uImage; then
  bootm 0xa000; fi; bootm 0x15;
  
  bootdelay=2
  
  baudrate=115200
  
  ethaddr=00:00:70:26:1E:01
  
  netmask=255.255.255.0
  
  ethact=SMC9-0
  
  ipaddr=10.100.144.42
  
  serverip=10.100.144.245
  
  gatewayip=10.100.144.255
  
  stdin=serial
  
  stdout=serial
  
  stderr=serial
  
  
  Environment size: 445/32764 bytes
  
  MDT-Boot ping 10.100.144.245
  
  SMC9: MAC 00:00:70:26:1e:01
  
  Using SMC9-0 device
  
  host 10.100.144.245 is alive
  
  MDT-Boot tftp a300 u-boot.bin
  
  SMC9: MAC 00:00:70:26:1e:01
  
  Using SMC9-0 device
  
  TFTP from server 10.100.144.245; our IP address is 10.100.144.42
  
  Filename 'u-boot.bin'.
  
  Load address: 0xa300
  
  Loading: *_
  
  done
  
  Bytes transferred = 335280 (51db0 hex)
  
  MDT-Boot tftp a300 zImage
  
  SMC9: MAC 00:00:70:26:1e:01
  
  Using SMC9-0 device
  
  TFTP from server 10.100.144.245; our IP address is 10.100.144.42
  
  Filename 'zImage'.
  
  Load address: 0xa300
  
  Loading: *_T T T T T T T T T T T T T T T T T T T T
  
  Retry count exceeded; starting again
  
  SMC9: MAC 00:00:70:26:1e:01
  
  Using SMC9-0 device
  
  TFTP from server 10.100.144.245; our IP address is 10.100.144.42
  
  Filename 'zImage'.
  
  Load address: 0xa300
  
  Loading: *_###T ##T

Re: [U-Boot] [PATCH 2/8] USB-CDC: Add lost 'qmult' definition

Hi,

2010/8/12 Vitaly Kuzmichev vkuzmic...@mvista.com:
 Add lost 'qmult' definition for High Speed devices and make it
 configurable through CONFIG_USB_ETH_QMULT.

 Signed-off-by: Vitaly Kuzmichev vkuzmic...@mvista.com
 ---
  drivers/usb/gadget/ether.c |    6 ++
  1 files changed, 6 insertions(+), 0 deletions(-)

Applied to u-boot-usb/cdc branch.
Thanks.

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

Re: [U-Boot] [PATCH v2 3/8] USB-CDC: Use native debug printout macros

Hi,

2010/8/13 Vitaly Kuzmichev vkuzmic...@mvista.com:
 Replace Linux-like debug printout macros by native ones.

 Signed-off-by: Vitaly Kuzmichev vkuzmic...@mvista.com
 ---
  drivers/usb/gadget/ether.c |   99 ---
  1 files changed, 46 insertions(+), 53 deletions(-)

 diff --git a/drivers/usb/gadget/ether.c b/drivers/usb/gadget/ether.c
 index a07738f..c287ec2 100644
 --- a/drivers/usb/gadget/ether.c
 +++ b/drivers/usb/gadget/ether.c
 @@ -20,6 +20,9 @@
  * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
  */

 +#define DEBUG
 +#undef DEBUG

Applied to u-boot-usb/cdc branch after removing ' #define DEBUG' as
Sergei suggested.
Thanks.

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

Re: [U-Boot] [PATCH v2 5/8] USB-CDC: Replace 'strcpy' by 'strlcpy'

Hi,

2010/8/13 Vitaly Kuzmichev vkuzmic...@mvista.com:
 Replace 'strcpy' by more safe 'strlcpy' that is implemented in ether.c

 Signed-off-by: Vitaly Kuzmichev vkuzmic...@mvista.com
 ---
  drivers/usb/gadget/ether.c |    6 +++---
  1 files changed, 3 insertions(+), 3 deletions(-)


Applied to u-boot-usb/cdc branch.
Thanks.

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

Re: [U-Boot] [PATCH v2 4/8] USB-CDC: Correct freeing usb requests

Hi,

2010/8/13 Vitaly Kuzmichev vkuzmic...@mvista.com:
 Fix in_ep and out_ep confusion (rx_req was allocated from out_ep, not
 from in_ep) and add lost dev-req freeing.

 Signed-off-by: Vitaly Kuzmichev vkuzmic...@mvista.com
 ---
  drivers/usb/gadget/ether.c |    9 +++--
  1 files changed, 7 insertions(+), 2 deletions(-)

Applied to u-boot-usb/cdc branch.
Thanks.

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

Re: [U-Boot] [PATCH v2 6/8] USB-CDC: Correct stat_req initialization

Hi,

2010/8/13 Vitaly Kuzmichev vkuzmic...@mvista.com:
 Fix possible oops on stat_req-buf initialization and fix ep0 and
 status_ep confusion (last one is just intended for stat_req keeping).

 Signed-off-by: Vitaly Kuzmichev vkuzmic...@mvista.com
 Signed-off-by: Stefano Babic sba...@denx.de
 ---
  drivers/usb/gadget/ether.c |    7 +++
  1 files changed, 3 insertions(+), 4 deletions(-)


Applied to u-boot-usb/cdc branch.
Thanks.

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

Re: [U-Boot] [PATCH v2 8/8] USB-CDC: change simple_strtol to simple_strtoul

Hi,

2010/8/13 Vitaly Kuzmichev vkuzmic...@mvista.com:
 The patch is based on commit bb9496c6f7e853e5d4edd5397c9d45f1968d623c
 (done by Julia Lawall ju...@diku.dk) from linux-2.6.git.

 Since num is unsigned, it would seem better to use simple_strtoul that
 simple_strtol.

 Signed-off-by: Vitaly Kuzmichev vkuzmic...@mvista.com
 ---
  drivers/usb/gadget/epautoconf.c |    2 +-

Applied to u-boot-usb/cdc branch.
Thanks.

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

Re: [U-Boot] [PATCH v2 3/8] USB-CDC: Use native debug printout macros

Dear Stefano Babic,

In message 4c6557c5.4000...@denx.de you wrote:

 It is ok, but it generates another new CONFIG_ switch, that is unusable
 for the rest of u-boot. I agree that in u-boot there is a lot of
 different and local functions to setup, and probably a general mechanism
 should be better defined. However, setting #define DEBUG before any
 include files is quite usual. I do not like to set a CONFIG_ switch only
 for debug purpose, as in the delivered system all debug output should be
 turned off.

We already have such a general mechanism, the problem is just that
people ignore it and re-invent the wheel.

We have debug(), debugX(), error(), and BUG_ON().

What exactly seems to be missing?

Note that when using constants as level argument in debugX() the
compiler can even optimize away non-relevant code.

I remember we had a similar discussion in the past, which resulted
that I accepted to have debugX() added - yet how many files use it?
2 (in words: TWO)!

So before we add even more debug utilities someone has to bring up
really good arguments to convince me.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Where shall I begin, please your Majesty? he asked. Begin  at  the
beginning,  the  King said, gravely, and go on till you come to the
end: then stop.- Alice's Adventures in Wonderland, Lewis Carroll
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 3/8] USB-CDC: Use native debug printout macros

Dear Sergei Shtylyov,

In message 4c6558d4.9070...@mvista.com you wrote:
 
 I'd suggest leaving just #undef DEBUG (which can be edited into #define 
 DEBUG if desired)...

Don't you listen?  Remove that, completely, please!

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
Commitment, n.:  Commitment can be illustrated by a breakfast
of ham and eggs. The chicken was involved, the pig was committed.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 3/8] USB-CDC: Use native debug printout macros

Dear Remy Bohmer,

In message aanlktikbeesekkuaecpzbwm3ramjkjcpkk=ykrnhw...@mail.gmail.com you 
wrote:
 
  +#define DEBUG
  +#undef DEBUG
 
 Applied to u-boot-usb/cdc branch after removing ' #define DEBUG' as
 Sergei suggested.

NAK. Please also remove the dead and completely needless #undef DEBUG
as well.

Thanks.


Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
If the odds are a million to one against something occuring,  chances
are 50-50 it will.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 3/8] USB-CDC: Use native debug printout macros

Hi,

2010/8/13 Wolfgang Denk w...@denx.de:
 Dear Remy Bohmer,

 In message aanlktikbeesekkuaecpzbwm3ramjkjcpkk=ykrnhw...@mail.gmail.com you 
 wrote:

  +#define DEBUG
  +#undef DEBUG

 Applied to u-boot-usb/cdc branch after removing ' #define DEBUG' as
 Sergei suggested.

 NAK. Please also remove the dead and completely needless #undef DEBUG
 as well.

Done!

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

Re: [U-Boot] handling of bad blocks in nand

2010-08-13 Thread Grant Edwards

On 2010-07-09, Scott Wood scottw...@freescale.com wrote:
 On Fri, Jul 09, 2010 at 08:56:40AM -0400, Ben Gardiner wrote:

 If you are putting an MTD filesystem in that partition then the
 filesystem itself will take care of bad blocks that might occur in
 the partition during runtime. During the flash programming of this
 filesystem using nand write.jffs2 (or .e) will skip bad blocks that
 might occur in the partition.
 
 If you are putting an image (kernel or initrd) into the partition then
 the 'nand read.e' and 'nand write.e' (as well as mtd-utils nandwrite)
 will handle bad blocks by skipping over them.

 On any recent u-boot, the .jffs2/.e/.i suffixes are maintained for
 compatibility only -- bad block skipping is now the default behavior.

I'm using 1.3.4 (that's what's supported by Atmel).  While that's the
current released version, it appears to be over two years old?

I've been reading nand flash docs and source code for a while now, and
I must admit the more I read the more questions I have.

 1) Is there any documentation for the nand commands?
 
There's nothing in the manual, and doc/README.nand appears to be
incomplete, and self-contradictory.  [There's no mention at all of
.e or .i, and there are contradictory descriptions for .jffs2.]

 2) Are the behaviors of .jffs2, .e, and .i the same? (It
appears so from the source code.) If not how do they differ?

 3) In the 1.3.4 source code, there are lots of instances where there
are boolean flags with names like jffs2.  AFAICT those flags
have nothing to do with the JFFS2 filesystem, but simply control
whether or not bad flash blocks are skipped during read/write
operations.  Am I reading the code correctly?

 4) If in a custom command, I want to read/write a large block of data
to/from nand flash while skipping bad blocks what functions do I
call?  Right now I'm doing something like this:

  nand_info[0].read(nand_info+0, offset, sizeof(buffer), len, buffer)

  nand_info[0].write(nand_info+0, offset, bytecount, len, buffer)

but, I have a feeling that's not right (though it seems to work, I
suspect it's not going to skip bad blocks).

-- 
Grant Edwards   grant.b.edwardsYow! Hello, GORRY-O!!
  at   I'm a GENIUS from HARVARD!!
  gmail.com

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

[U-Boot] [PATCH 02/7] ARMV7: OMAP: add convenience function to set TWL4030 regulator voltages

This patch adds a function to allow one to easily set the target
voltage for the TWL4030 regulators.  It also modifies the existing
code to use this new function.  Applicable definitions are moved
out of the driver file and into the header file so that they are
generally accessible

Signed-off-by: Steve Sakoman st...@sakoman.com
---
 drivers/power/twl4030.c |   69 --
 include/twl4030.h   |   14 +
 2 files changed, 44 insertions(+), 39 deletions(-)

diff --git a/drivers/power/twl4030.c b/drivers/power/twl4030.c
index eb066cb..1a54089 100644
--- a/drivers/power/twl4030.c
+++ b/drivers/power/twl4030.c
@@ -59,57 +59,48 @@ void twl4030_power_reset_init(void)
}
 }
 
-
 /*
- * Power Init
+ * Set Device Group and Voltage
  */
-#define DEV_GRP_P1 0x20
-#define VAUX3_VSEL_28  0x03
-#define DEV_GRP_ALL0xE0
-#define VPLL2_VSEL_18  0x05
-#define VDAC_VSEL_18   0x03
+void twl4030_pmrecv_vsel_cfg(u8 vsel_reg, u8 vsel_val,
+   u8 dev_grp, u8 dev_grp_sel)
+{
+   /* Select the Device Group */
+   twl4030_i2c_write_u8(TWL4030_CHIP_PM_RECEIVER, dev_grp_sel,
+   dev_grp);
+
+   /* Select the Voltage */
+   twl4030_i2c_write_u8(TWL4030_CHIP_PM_RECEIVER, vsel_val,
+   vsel_reg);
+}
 
 void twl4030_power_init(void)
 {
-   unsigned char byte;
-
/* set VAUX3 to 2.8V */
-   byte = DEV_GRP_P1;
-   twl4030_i2c_write_u8(TWL4030_CHIP_PM_RECEIVER, byte,
-TWL4030_PM_RECEIVER_VAUX3_DEV_GRP);
-   byte = VAUX3_VSEL_28;
-   twl4030_i2c_write_u8(TWL4030_CHIP_PM_RECEIVER, byte,
-TWL4030_PM_RECEIVER_VAUX3_DEDICATED);
+   twl4030_pmrecv_vsel_cfg(TWL4030_PM_RECEIVER_VAUX3_DEDICATED,
+   TWL4030_PM_RECEIVER_VAUX3_VSEL_28,
+   TWL4030_PM_RECEIVER_VAUX3_DEV_GRP,
+   TWL4030_PM_RECEIVER_DEV_GRP_P1);
 
/* set VPLL2 to 1.8V */
-   byte = DEV_GRP_ALL;
-   twl4030_i2c_write_u8(TWL4030_CHIP_PM_RECEIVER, byte,
-TWL4030_PM_RECEIVER_VPLL2_DEV_GRP);
-   byte = VPLL2_VSEL_18;
-   twl4030_i2c_write_u8(TWL4030_CHIP_PM_RECEIVER, byte,
-TWL4030_PM_RECEIVER_VPLL2_DEDICATED);
+   twl4030_pmrecv_vsel_cfg(TWL4030_PM_RECEIVER_VPLL2_DEDICATED,
+   TWL4030_PM_RECEIVER_VPLL2_VSEL_18,
+   TWL4030_PM_RECEIVER_VPLL2_DEV_GRP,
+   TWL4030_PM_RECEIVER_DEV_GRP_ALL);
 
/* set VDAC to 1.8V */
-   byte = DEV_GRP_P1;
-   twl4030_i2c_write_u8(TWL4030_CHIP_PM_RECEIVER, byte,
-TWL4030_PM_RECEIVER_VDAC_DEV_GRP);
-   byte = VDAC_VSEL_18;
-   twl4030_i2c_write_u8(TWL4030_CHIP_PM_RECEIVER, byte,
-TWL4030_PM_RECEIVER_VDAC_DEDICATED);
+   twl4030_pmrecv_vsel_cfg(TWL4030_PM_RECEIVER_VDAC_DEDICATED,
+   TWL4030_PM_RECEIVER_VDAC_VSEL_18,
+   TWL4030_PM_RECEIVER_VDAC_DEV_GRP,
+   TWL4030_PM_RECEIVER_DEV_GRP_P1);
 }
 
-#define VMMC1_VSEL_30  0x02
-
 void twl4030_power_mmc_init(void)
 {
-   unsigned char byte;
-
-   byte = DEV_GRP_P1;
-   twl4030_i2c_write_u8(TWL4030_CHIP_PM_RECEIVER, byte,
-TWL4030_PM_RECEIVER_VMMC1_DEV_GRP);
-
-   /* 3 Volts */
-   byte = VMMC1_VSEL_30;
-   twl4030_i2c_write_u8(TWL4030_CHIP_PM_RECEIVER, byte,
-TWL4030_PM_RECEIVER_VMMC1_DEDICATED);
+   /* Set VMMC1 to 3 Volts */
+   twl4030_pmrecv_vsel_cfg(TWL4030_PM_RECEIVER_VMMC1_DEDICATED,
+   TWL4030_PM_RECEIVER_VMMC1_VSEL_30,
+   TWL4030_PM_RECEIVER_VMMC1_DEV_GRP,
+   TWL4030_PM_RECEIVER_DEV_GRP_P1);
 }
+
diff --git a/include/twl4030.h b/include/twl4030.h
index 2b2f5ae..930c285 100644
--- a/include/twl4030.h
+++ b/include/twl4030.h
@@ -304,6 +304,17 @@
 #define TWL4030_PM_RECEIVER_MAINREF_TYPE   0xF0
 #define TWL4030_PM_RECEIVER_MAINREF_REMAP  0xF1
 
+/* Voltage Selection in PM Receiver Module */
+#define TWL4030_PM_RECEIVER_VAUX2_VSEL_18  0x05
+#define TWL4030_PM_RECEIVER_VAUX3_VSEL_28  0x03
+#define TWL4030_PM_RECEIVER_VPLL2_VSEL_18  0x05
+#define TWL4030_PM_RECEIVER_VDAC_VSEL_18   0x03
+#define TWL4030_PM_RECEIVER_VMMC1_VSEL_30  0x02
+
+/* Device Selection in PM Receiver Module */
+#define TWL4030_PM_RECEIVER_DEV_GRP_P1 0x20
+#define TWL4030_PM_RECEIVER_DEV_GRP_ALL0xE0
+
 /* LED */
 #define TWL4030_LED_LEDEN  0xEE
 #define TWL4030_LED_LEDEN_LEDAON   (1  0)
@@ -500,6

[U-Boot] [PATCH 03/7] ARMV7: OMAP: Enable input driver on Overo's MMC1_CLK and MMC3_CLK pinmux setup

This patch modifies the pinmux setup for MMC1_CLK and MMC3_CLK to enable
the input driver.  MMC2_CLK was already properly configured.

Signed-off-by: Steve Sakoman st...@sakoman.com
---
 board/overo/overo.h |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/board/overo/overo.h b/board/overo/overo.h
index 1873523..fff43da 100644
--- a/board/overo/overo.h
+++ b/board/overo/overo.h
@@ -200,7 +200,7 @@ const omap3_sysinfo sysinfo = {
MUX_VAL(CP(MCBSP2_DR),  (IEN  | PTD | DIS | M0)) /*McBSP2_DR*/\
MUX_VAL(CP(MCBSP2_DX),  (IDIS | PTD | DIS | M0)) /*McBSP2_DX*/\
  /*Expansion card */\
-   MUX_VAL(CP(MMC1_CLK),   (IDIS | PTU | EN  | M0)) /*MMC1_CLK*/\
+   MUX_VAL(CP(MMC1_CLK),   (IEN  | PTU | EN  | M0)) /*MMC1_CLK*/\
MUX_VAL(CP(MMC1_CMD),   (IEN  | PTU | EN  | M0)) /*MMC1_CMD*/\
MUX_VAL(CP(MMC1_DAT0),  (IEN  | PTU | EN  | M0)) /*MMC1_DAT0*/\
MUX_VAL(CP(MMC1_DAT1),  (IEN  | PTU | EN  | M0)) /*MMC1_DAT1*/\
@@ -301,7 +301,7 @@ const omap3_sysinfo sysinfo = {
MUX_VAL(CP(SYS_OFF_MODE),   (IEN  | PTD | DIS | M0)) 
/*SYS_OFF_MODE*/\
MUX_VAL(CP(SYS_CLKOUT1),(IEN  | PTD | DIS | M0)) 
/*SYS_CLKOUT1*/\
MUX_VAL(CP(SYS_CLKOUT2),(IEN  | PTU | EN  | M4)) /*GPIO_186*/\
-   MUX_VAL(CP(ETK_CLK_ES2),(IDIS | PTU | EN  | M2)) /*MMC3_CLK*/\
+   MUX_VAL(CP(ETK_CLK_ES2),(IEN  | PTU | EN  | M2)) /*MMC3_CLK*/\
MUX_VAL(CP(ETK_CTL_ES2),(IEN  | PTU | EN  | M2)) /*MMC3_CMD*/\
MUX_VAL(CP(ETK_D0_ES2), (IEN  | PTU | EN  | M4)) /*GPIO_14*/\
MUX_VAL(CP(ETK_D1_ES2), (IEN  | PTD | EN  | M4)) /*GPIO_15 - 
X_GATE*/\
-- 
1.7.0.4

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

[U-Boot] [PATCH 01/7] ARMV7: OMAP: Move syslib.c to omap-common since it can be shared by OMAP3 and OMAP4

The functions in syslib.c can be shared, so this patch moves it from
cpu/omap3 to cpu/omap-common

Signed-off-by: Steve Sakoman st...@sakoman.com
---
 arch/arm/cpu/armv7/omap-common/Makefile|2 ++
 arch/arm/cpu/armv7/{omap3 = omap-common}/syslib.c |2 --
 arch/arm/cpu/armv7/omap3/Makefile  |1 -
 arch/arm/include/asm/arch-omap4/sys_proto.h|3 +++
 4 files changed, 5 insertions(+), 3 deletions(-)
 rename arch/arm/cpu/armv7/{omap3 = omap-common}/syslib.c (97%)

diff --git a/arch/arm/cpu/armv7/omap-common/Makefile 
b/arch/arm/cpu/armv7/omap-common/Makefile
index 3a4a304..caee726 100644
--- a/arch/arm/cpu/armv7/omap-common/Makefile
+++ b/arch/arm/cpu/armv7/omap-common/Makefile
@@ -26,7 +26,9 @@ include $(TOPDIR)/config.mk
 LIB= $(obj)libomap-common.a
 
 SOBJS  := reset.o
+
 COBJS  := timer.o
+COBJS  += syslib.o
 
 SRCS   := $(SOBJS:.o=.S) $(COBJS:.o=.c)
 OBJS   := $(addprefix $(obj),$(SOBJS) $(COBJS))
diff --git a/arch/arm/cpu/armv7/omap3/syslib.c 
b/arch/arm/cpu/armv7/omap-common/syslib.c
similarity index 97%
rename from arch/arm/cpu/armv7/omap3/syslib.c
rename to arch/arm/cpu/armv7/omap-common/syslib.c
index 9ced495..f9ed9a3 100644
--- a/arch/arm/cpu/armv7/omap3/syslib.c
+++ b/arch/arm/cpu/armv7/omap-common/syslib.c
@@ -23,8 +23,6 @@
 
 #include common.h
 #include asm/io.h
-#include asm/arch/mem.h
-#include asm/arch/clocks.h
 #include asm/arch/sys_proto.h
 
 /
diff --git a/arch/arm/cpu/armv7/omap3/Makefile 
b/arch/arm/cpu/armv7/omap3/Makefile
index 79ae267..95526d6 100644
--- a/arch/arm/cpu/armv7/omap3/Makefile
+++ b/arch/arm/cpu/armv7/omap3/Makefile
@@ -32,7 +32,6 @@ COBJS += board.o
 COBJS  += clock.o
 COBJS  += gpio.o
 COBJS  += mem.o
-COBJS  += syslib.o
 COBJS  += sys_info.o
 
 COBJS-$(CONFIG_EMIF4)  += emif4.o
diff --git a/arch/arm/include/asm/arch-omap4/sys_proto.h 
b/arch/arm/include/asm/arch-omap4/sys_proto.h
index ad0c640..4813e9e 100644
--- a/arch/arm/include/asm/arch-omap4/sys_proto.h
+++ b/arch/arm/include/asm/arch-omap4/sys_proto.h
@@ -33,6 +33,9 @@ void watchdog_init(void);
 u32 get_device_type(void);
 void invalidate_dcache(u32);
 void set_muxconf_regs(void);
+void sr32(void *, u32, u32, u32);
+u32 wait_on_value(u32, u32, void *, u32);
+void sdelay(unsigned long);
 
 extern const struct omap_sysinfo sysinfo;
 
-- 
1.7.0.4

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

[U-Boot] [PATCH 04/7] ARMV7: OMAP: Add mpurate boot arg for Overo and Beagle

Allows one to set the processor clock rate via setenv mpurate 720 for example

Default is set to a safe 500 Mhz.

Signed-off-by: Steve Sakoman st...@sakoman.com
---
 include/configs/omap3_beagle.h |3 +++
 include/configs/omap3_overo.h  |3 +++
 2 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/include/configs/omap3_beagle.h b/include/configs/omap3_beagle.h
index ae5a791..e7cd93b 100644
--- a/include/configs/omap3_beagle.h
+++ b/include/configs/omap3_beagle.h
@@ -183,6 +183,7 @@
loadaddr=0x8200\0 \
usbtty=cdc_acm\0 \
console=ttyS2,115200n8\0 \
+   mpurate=500\0 \
vram=12M\0 \
dvimode=1024x768mr...@60\0 \
defaultdisplay=dvi\0 \
@@ -191,6 +192,7 @@
nandroot=/dev/mtdblock4 rw\0 \
nandrootfstype=jffs2\0 \
mmcargs=setenv bootargs console=${console}  \
+   mpurate=${mpurate}  \
vram=${vram}  \
omapfb.mode=dvi:${dvimode}  \
omapfb.debug=y  \
@@ -198,6 +200,7 @@
root=${mmcroot}  \
rootfstype=${mmcrootfstype}\0 \
nandargs=setenv bootargs console=${console}  \
+   mpurate=${mpurate}  \
vram=${vram}  \
omapfb.mode=dvi:${dvimode}  \
omapfb.debug=y  \
diff --git a/include/configs/omap3_overo.h b/include/configs/omap3_overo.h
index 3a3b389..ca90786 100644
--- a/include/configs/omap3_overo.h
+++ b/include/configs/omap3_overo.h
@@ -153,6 +153,7 @@
 #define CONFIG_EXTRA_ENV_SETTINGS \
loadaddr=0x8200\0 \
console=ttyS2,115200n8\0 \
+   mpurate=500\0 \
vram=12M\0 \
dvimode=1024x768mr...@60\0 \
defaultdisplay=dvi\0 \
@@ -161,6 +162,7 @@
nandroot=/dev/mtdblock4 rw\0 \
nandrootfstype=jffs2\0 \
mmcargs=setenv bootargs console=${console}  \
+   mpurate=${mpurate}  \
vram=${vram}  \
omapfb.mode=dvi:${dvimode}  \
omapfb.debug=y  \
@@ -168,6 +170,7 @@
root=${mmcroot}  \
rootfstype=${mmcrootfstype}\0 \
nandargs=setenv bootargs console=${console}  \
+   mpurate=${mpurate}  \
vram=${vram}  \
omapfb.mode=dvi:${dvimode}  \
omapfb.debug=y  \
-- 
1.7.0.4

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

[U-Boot] [PATCH 05/7] ARMV7: OMAP: Add board revision detection for Overo

The latest Overo COM modules encode their revision number on
GPIOs 115, 113, and 112.  All boards to date have no pullups on these pins
and hence appear as revision 0.

This patch reads and prints the revision information.

Signed-off-by: Steve Sakoman st...@sakoman.com
---
 board/overo/overo.c |   32 
 board/overo/overo.h |6 +++---
 2 files changed, 35 insertions(+), 3 deletions(-)

diff --git a/board/overo/overo.c b/board/overo/overo.c
index e85be7d..1c7087b 100644
--- a/board/overo/overo.c
+++ b/board/overo/overo.c
@@ -61,6 +61,37 @@ int board_init(void)
 }
 
 /*
+ * Routine: get_board_revision
+ * Description: Returns the board revision
+ */
+int get_board_revision(void)
+{
+   int revision;
+
+   if (!omap_request_gpio(112) 
+   !omap_request_gpio(113) 
+   !omap_request_gpio(115)) {
+
+   omap_set_gpio_direction(112, 1);
+   omap_set_gpio_direction(113, 1);
+   omap_set_gpio_direction(115, 1);
+
+   revision = omap_get_gpio_datain(115)  2 |
+  omap_get_gpio_datain(113)  1 |
+  omap_get_gpio_datain(112);
+
+   omap_free_gpio(112);
+   omap_free_gpio(113);
+   omap_free_gpio(115);
+   } else {
+   printf(Error: unable to acquire board revision GPIOs\n);
+   revision = -1;
+   }
+
+   return revision;
+}
+
+/*
  * Routine: misc_init_r
  * Description: Configure board specific parts
  */
@@ -73,6 +104,7 @@ int misc_init_r(void)
setup_net_chip();
 #endif
 
+   printf(Board revision: %d\n, get_board_revision());
dieid_num_r();
 
return 0;
diff --git a/board/overo/overo.h b/board/overo/overo.h
index fff43da..a4e49b9 100644
--- a/board/overo/overo.h
+++ b/board/overo/overo.h
@@ -189,11 +189,11 @@ const omap3_sysinfo sysinfo = {
MUX_VAL(CP(CAM_XCLKB),  (IDIS | PTD | DIS | M0)) /*CAM_XCLKB*/\
MUX_VAL(CP(CAM_WEN),(IEN  | PTD | DIS | M0)) /*CAM_WEN*/\
MUX_VAL(CP(CAM_STROBE), (IDIS | PTD | DIS | M0)) /*CAM_STROBE*/\
-   MUX_VAL(CP(CSI2_DX0),   (IEN  | PTD | DIS | M0)) /*CSI2_DX0*/\
-   MUX_VAL(CP(CSI2_DY0),   (IEN  | PTD | DIS | M0)) /*CSI2_DY0*/\
+   MUX_VAL(CP(CSI2_DX0),   (IEN  | PTD | EN  | M4)) /*GPIO_112*/\
+   MUX_VAL(CP(CSI2_DY0),   (IEN  | PTD | EN  | M4)) /*GPIO_113*/\
MUX_VAL(CP(CSI2_DX1),   (IEN  | PTD | EN  | M4)) /*GPIO_114*/\
 /* - 
PEN_DOWN*/\
-   MUX_VAL(CP(CSI2_DY1),   (IEN  | PTU | EN  | M4)) /*GPIO_115*/\
+   MUX_VAL(CP(CSI2_DY1),   (IEN  | PTD | EN  | M4)) /*GPIO_115*/\
  /*Audio Interface */\
MUX_VAL(CP(MCBSP2_FSX), (IEN  | PTD | DIS | M0)) /*McBSP2_FSX*/\
MUX_VAL(CP(MCBSP2_CLKX),(IEN  | PTD | DIS | M0)) 
/*McBSP2_CLKX*/\
-- 
1.7.0.4

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

[U-Boot] [PATCH 06/7] ARMV7: OMAP: Add detection and support for Beagle C4 revision

This patch enhances the revision detection function and adds
support for the C4 revision.  The board revision is printed
and approriate revision specific setup is done automatically.

Signed-off-by: Steve Sakoman st...@sakoman.com
---
 board/ti/beagle/beagle.c |   90 +++---
 board/ti/beagle/beagle.h |7 +++-
 2 files changed, 58 insertions(+), 39 deletions(-)

diff --git a/board/ti/beagle/beagle.c b/board/ti/beagle/beagle.c
index 3b4c9e7..ec95ad0 100644
--- a/board/ti/beagle/beagle.c
+++ b/board/ti/beagle/beagle.c
@@ -38,8 +38,6 @@
 #include asm/mach-types.h
 #include beagle.h
 
-static int beagle_revision_c;
-
 /*
  * Routine: board_init
  * Description: Early hardware init.
@@ -58,43 +56,40 @@ int board_init(void)
 }
 
 /*
- * Routine: beagle_get_revision
- * Description: Return the revision of the BeagleBoard this code is running on.
- *  If it is a revision Ax/Bx board, this function returns 0,
- *  on a revision C board you will get a 1.
+ * Routine: get_board_revision
+ * Description: Detect if we are running on a Beagle revision Ax/Bx,
+ * C1/2/3, or C4. This can be done by reading
+ * the level of GPIO173, GPIO172 and GPIO171. This should
+ * result in
+ * GPIO173, GPIO172, GPIO171: 1 1 1 = Ax/Bx
+ * GPIO173, GPIO172, GPIO171: 1 1 0 = C1/2/3
+ * GPIO173, GPIO172, GPIO171: 1 0 1 = C4
  */
-int beagle_get_revision(void)
+int get_board_revision(void)
 {
-   return beagle_revision_c;
-}
+   int revision;
 
-/*
- * Routine: beagle_identify
- * Description: Detect if we are running on a Beagle revision Ax/Bx or
- *  Cx. This can be done by GPIO_171. If this is low, we are
- *  running on a revision C board.
- */
-void beagle_identify(void)
-{
-   beagle_revision_c = 0;
-   if (!omap_request_gpio(171)) {
-   unsigned int val;
+   if (!omap_request_gpio(171) 
+   !omap_request_gpio(172) 
+   !omap_request_gpio(173)) {
 
omap_set_gpio_direction(171, 1);
-   val = omap_get_gpio_datain(171);
-   omap_free_gpio(171);
+   omap_set_gpio_direction(172, 1);
+   omap_set_gpio_direction(173, 1);
 
-   if (val)
-   beagle_revision_c = 0;
-   else
-   beagle_revision_c = 1;
+   revision = omap_get_gpio_datain(173)  2 |
+  omap_get_gpio_datain(172)  1 |
+  omap_get_gpio_datain(171);
+
+   omap_free_gpio(171);
+   omap_free_gpio(172);
+   omap_free_gpio(173);
+   } else {
+   printf(Error: unable to acquire board revision GPIOs\n);
+   revision = -1;
}
 
-   printf(Board revision );
-   if (beagle_revision_c)
-   printf(C\n);
-   else
-   printf(Ax/Bx\n);
+   return revision;
 }
 
 /*
@@ -106,6 +101,33 @@ int misc_init_r(void)
struct gpio *gpio5_base = (struct gpio *)OMAP34XX_GPIO5_BASE;
struct gpio *gpio6_base = (struct gpio *)OMAP34XX_GPIO6_BASE;
 
+   switch (get_board_revision()) {
+   case REVISION_AXBX:
+   printf(Beagle Rev Ax/Bx\n);
+   setenv(beaglerev, AxBx);
+   setenv(mpurate, 600);
+   break;
+   case REVISION_CX:
+   printf(Beagle Rev C1/C2/C3\n);
+   setenv(beaglerev, Cx);
+   setenv(mpurate, 600);
+   MUX_BEAGLE_C();
+   break;
+   case REVISION_C4:
+   printf(Beagle Rev C4\n);
+   setenv(beaglerev, Cx);
+   setenv(mpurate, 720);
+   MUX_BEAGLE_C();
+   /* Set VAUX2 to 1.8V for EHCI PHY */
+   twl4030_pmrecv_vsel_cfg(TWL4030_PM_RECEIVER_VAUX2_DEDICATED,
+   TWL4030_PM_RECEIVER_VAUX2_VSEL_18,
+   TWL4030_PM_RECEIVER_VAUX2_DEV_GRP,
+   TWL4030_PM_RECEIVER_DEV_GRP_P1);
+   break;
+   default:
+   printf(Beagle unknown 0x%02x\n, get_board_revision());
+   }
+
twl4030_power_init();
twl4030_led_init(TWL4030_LED_LEDEN_LEDAON | TWL4030_LED_LEDEN_LEDBON);
 
@@ -120,8 +142,6 @@ int misc_init_r(void)
writel(GPIO31 | GPIO30 | GPIO29 | GPIO28 | GPIO22 | GPIO21 |
GPIO15 | GPIO14 | GPIO13 | GPIO12, gpio5_base-setdataout);
 
-   beagle_identify();
-
dieid_num_r();
 
return 0;
@@ -136,8 +156,4 @@ int misc_init_r(void)
 void set_muxconf_regs(void)
 {
MUX_BEAGLE();
-
-   if (beagle_revision_c) {
-   MUX_BEAGLE_C();
-   }
 }
diff --git a/board/ti/beagle/beagle.h b/board/ti/beagle/beagle.h
index 7fe6275..e5f380c 100644
--- a/board/ti/beagle/beagle.h
+++ b/board/ti/beagle/beagle.h
@@ -33,7

[U-Boot] [PATCH 07/7] ARMV7: OMAP: Configure Overo's second network chip

Confiures GPMC timings for both chips and also configures pinmux
for GPIO_65, which is used as the interrupt signal for the second chip

Signed-off-by: Scott Ellis sc...@jumpnowtek.com
Signed-off-by: Steve Sakoman st...@sakoman.com
---
 board/overo/overo.c |   26 ++
 board/overo/overo.h |2 +-
 2 files changed, 19 insertions(+), 9 deletions(-)

diff --git a/board/overo/overo.c b/board/overo/overo.c
index 1c7087b..4a60917 100644
--- a/board/overo/overo.c
+++ b/board/overo/overo.c
@@ -43,6 +43,17 @@
 static void setup_net_chip(void);
 #endif
 
+/* GPMC definitions for LAN9221 chips on Tobi expansion boards */
+static const u32 gpmc_lan_config[] = {
+NET_LAN9221_GPMC_CONFIG1,
+NET_LAN9221_GPMC_CONFIG2,
+NET_LAN9221_GPMC_CONFIG3,
+NET_LAN9221_GPMC_CONFIG4,
+NET_LAN9221_GPMC_CONFIG5,
+NET_LAN9221_GPMC_CONFIG6,
+/*CONFIG7- computed as params */
+};
+
 /*
  * Routine: board_init
  * Description: Early hardware init.
@@ -131,14 +142,13 @@ static void setup_net_chip(void)
 {
struct ctrl *ctrl_base = (struct ctrl *)OMAP34XX_CTRL_BASE;
 
-   /* Configure GPMC registers */
-   writel(NET_LAN9221_GPMC_CONFIG1, gpmc_cfg-cs[5].config1);
-   writel(NET_LAN9221_GPMC_CONFIG2, gpmc_cfg-cs[5].config2);
-   writel(NET_LAN9221_GPMC_CONFIG3, gpmc_cfg-cs[5].config3);
-   writel(NET_LAN9221_GPMC_CONFIG4, gpmc_cfg-cs[5].config4);
-   writel(NET_LAN9221_GPMC_CONFIG5, gpmc_cfg-cs[5].config5);
-   writel(NET_LAN9221_GPMC_CONFIG6, gpmc_cfg-cs[5].config6);
-   writel(NET_LAN9221_GPMC_CONFIG7, gpmc_cfg-cs[5].config7);
+   /* first lan chip */
+   enable_gpmc_cs_config(gpmc_lan_config, gpmc_cfg-cs[5], 0x2C00,
+   GPMC_SIZE_16M);
+
+   /* second lan chip */
+   enable_gpmc_cs_config(gpmc_lan_config, gpmc_cfg-cs[4], 0x2B00,
+   GPMC_SIZE_16M);
 
/* Enable off mode for NWE in PADCONF_GPMC_NWE register */
writew(readw(ctrl_base -gpmc_nwe) | 0x0E00, ctrl_base-gpmc_nwe);
diff --git a/board/overo/overo.h b/board/overo/overo.h
index a4e49b9..2744ffe 100644
--- a/board/overo/overo.h
+++ b/board/overo/overo.h
@@ -138,7 +138,7 @@ const omap3_sysinfo sysinfo = {
MUX_VAL(CP(GPMC_WAIT1), (IEN  | PTU | EN  | M0)) /*GPMC_WAIT1*/\
MUX_VAL(CP(GPMC_WAIT2), (IEN  | PTU | EN  | M4)) /*GPIO_64*/\
 /* - 
SMSC911X_NRES*/\
-   MUX_VAL(CP(GPMC_WAIT3), (IEN  | PTU | EN  | M0)) /*GPMC_nCS3*/\
+   MUX_VAL(CP(GPMC_WAIT3), (IEN  | PTU | DIS | M4)) /*GPIO_65*/\
  /*DSS*/\
MUX_VAL(CP(DSS_PCLK),   (IDIS | PTD | DIS | M0)) /*DSS_PCLK*/\
MUX_VAL(CP(DSS_HSYNC),  (IDIS | PTD | DIS | M0)) /*DSS_HSYNC*/\
-- 
1.7.0.4

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

[U-Boot] [PATCH 00/7] ARMV7: OMAP3: Board updates for Beagle and Overo