Re: [U-Boot] Standalone API

2010-11-07 Thread Dennis Ruffer
 From: u-boot-boun...@lists.denx.de [mailto:u-boot-
 boun...@lists.denx.de] On Behalf Of Andrew Holt (SE)
 Is there a list, or header file containing prototypes of the U-Boot
 facilities that a standalone can make use of ? If so can somebody
 please direct me to it
 
 Regards,
 Andrew
 P.S. Also can somebody just responds anyway as a test.  I'm not sure
 that my messages are getting out there.

Did you read doc/README.standalone?

DaR


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


Re: [U-Boot] Standalone API

2010-11-07 Thread Dennis Ruffer
Replies inline below...

 -Original Message-
 From: Andrew Holt (SE) [mailto:andrew.h...@electrans.com]
 Sent: Sunday, November 07, 2010 12:44 PM
 To: Dennis Ruffer
 Cc: 'U-Boot List'
 Subject: Re: [U-Boot] Standalone API
 
 Hi,
 
 I hadn't, but I will, Thanks.
 
 I did find include/exports.h

That's where the document points you to anyway.

 Another question would be, I guess exports.h holds a subset of routines
 that 'could' be called by a standalone.  Is there a list of potential
 candidates ?

If it's not in exports.h you can't call it, but you can add anything that
follows the rules.

 Can you give me any guidance with regard to implementing the U-Boot API
 on SuperH ?

Not really.  I'm working on ARM and I haven't even written a standalone
program myself yet.  I've simply looked at it enough to have a good idea how
to do it and I was working with a standalone program that someone else had
written which didn't use any calls into uboot.  So, I know it's possible.

 What are the licences implications of a standalone calling these things
 ?

I'm not a lawyer, but I imagine that if you call u-boot routines, you still
have to comply with their license.

 Thanks for your help, it's good to know there is somebody out there :)

My impression is that most are in the far east, so I suspected you might not
get many replies until tomorrow.

I'm not really one of the official maintainers, but they might be able to
help you on a SuperH.

DaR

 Regards,
 Andrew
 
 On 7 Nov 2010, at 15:53, Dennis Ruffer wrote:
 
  From: u-boot-boun...@lists.denx.de [mailto:u-boot-
  boun...@lists.denx.de] On Behalf Of Andrew Holt (SE)
  Is there a list, or header file containing prototypes of the U-Boot
  facilities that a standalone can make use of ? If so can somebody
  please direct me to it
 
  Regards,
  Andrew
  P.S. Also can somebody just responds anyway as a test.  I'm not sure
  that my messages are getting out there.
 
  Did you read doc/README.standalone?
 
  DaR
 
 
 
 =
 Andrew Holt
 Senior Software Engineer
 
 Email: andrew.h...@electrans.com
 
 Questions are a burden to others; answers a prison for oneself.
 =
 
 


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


Re: [U-Boot] u-boot-2010.03 build errors with USE_PRIVATE_LIBGCC=yes option

2010-07-15 Thread Dennis Ruffer
 -Original Message-
 From: u-boot-boun...@lists.denx.de [mailto:u-boot-
 boun...@lists.denx.de] On Behalf Of Wolfgang Denk
 Sent: Thursday, July 15, 2010 10:58 AM
 To: Vipin KUMAR
 Cc: u-boot@lists.denx.de; Shiraz HASHIM
 Subject: Re: [U-Boot] u-boot-2010.03 build errors with
 USE_PRIVATE_LIBGCC=yes option
 
 Dear Vipin KUMAR,
 
 In message 4c3eecdb.7000...@st.com you wrote:
 
  Since this option -msoft-float is passed from arch/arm/cpu/config.mk,
 and it
  is common for all arm configurations. Is there a good way to pass -
 mhard-float..
 
 Why would you want to do that? We don't use any FP code in U-Boot
 anyway.

We have actually seen issues with the post memory tests using the -mfpu=neon
and -ftree-vectorize under gcc 4.4.1.  So, I would be very careful with FP
flags until someone figures out how to fix the 64-bit access operators that
the memory test uses.

DaR

 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
 When you say I wrote a program that crashed  Windows,  people  just
 stare  at you blankly and say Hey, I got those with the system, *for
 free*.- Linus Torvalds in 3itc77$...@ninurta.fer.uni-lj.si
 ___
 U-Boot mailing list
 U-Boot@lists.denx.de
 http://lists.denx.de/mailman/listinfo/u-boot

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


Re: [U-Boot] Endless loop in cmd_log.c?

2010-05-06 Thread Dennis Ruffer
Not sure why this hasn't come through in my 3 earlier attempts...

Let me try a different email address...

I am trying to implement CONFIG_LOGBUFFER and CONFIG_CMD_LOG on our ARM
systems and I seem to have run into an endless loop.  With loglevel=5 so we
still see our console output, the printf at the end of logbuff_printk
appears to create an endless loop.

I had to replace that line with serial_puts(msg);

Have I missed some other solution or do the systems that use this never set
logbuffer higher than default_message_loglevel?

DaR


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


Re: [U-Boot] Endless loop in cmd_log.c?

2010-05-06 Thread Dennis Ruffer
Oh, sorry.  I have the option turned on to send me my postings, but I have not 
gotten them. ;(

Sorry for spamming the list!

DaR

 -Original Message-
 From: Peter Tyser [mailto:pty...@xes-inc.com]
 Sent: Thursday, May 06, 2010 9:22 AM
 To: Dennis Ruffer
 Cc: 'Wolfgang Denk'; u-boot@lists.denx.de
 Subject: Re: [U-Boot] Endless loop in cmd_log.c?
 
 Hi Dennis,
 
 On Thu, 2010-05-06 at 09:03 -0700, Dennis Ruffer wrote:
  Not sure why this hasn't come through in my 3 earlier attempts...
 
  Let me try a different email address...
 
  I am trying to implement CONFIG_LOGBUFFER and CONFIG_CMD_LOG on our
 ARM
  systems and I seem to have run into an endless loop.  With loglevel=5
 so we
  still see our console output, the printf at the end of logbuff_printk
  appears to create an endless loop.
 
  I had to replace that line with serial_puts(msg);
 
  Have I missed some other solution or do the systems that use this
 never set
  logbuffer higher than default_message_loglevel?
 
 It has been coming through.  4 times now.  Give people some time to
 respond. http://lists.denx.de/pipermail/u-boot/2010-May/071107.html
 
 Best,
 Peter

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


Re: [U-Boot] Endless loop in cmd_log.c?

2010-05-06 Thread Dennis Ruffer
Peter, reply inline below...

 -Original Message-
 From: Peter Tyser [mailto:pty...@xes-inc.com]
 Sent: Thursday, May 06, 2010 4:27 PM
 To: Dennis Ruffer
 Cc: u-boot@lists.denx.de
 Subject: Re: [U-Boot] Endless loop in cmd_log.c?
 
 Hi Dennis,
 
 On Wed, 2010-05-05 at 12:22 -0700, Dennis Ruffer wrote:
  I am trying to implement CONFIG_LOGBUFFER and CONFIG_CMD_LOG on our
 ARM
  systems and I seem to have run into an endless loop.  With loglevel=5
 so we
  still see our console output, the printf at the end of logbuff_printk
  appears to create an endless loop.
 
  I had to replace that line with serial_puts(msg);
 
  Have I missed some other solution or do the systems that use this
 never set
  logbuffer higher than default_message_loglevel?
 
 I see the same issue you describe when enabling CONFIG_LOGBUFFER.  It
 looks like only a few boards have CONFIG_LOGBUFFER enabled, and many of
 them also have CONFIG_SYS_CONSOLE_IS_IN_ENV defined.  When
 CONFIG_SYS_CONSOLE_IS_IN_ENV is defined I believe the behavior is
 changed so that the the  stdout/stderr/stdin values are read from the
 environment, with a default fallback of 'serial'.
 
 My guess is most of the boards with CONFIG_LOGBUFFER defined have their
 'stdout' value set to 'serial', so they don't actually utilize the
 logbuffer, and thus don't run into the issue you found.
 
 In any case, I think its a bug and your suggested workaround sounds
 good
 to me.  Have any interest in submitting a patch to fix it?
 
 Best,
 Peter

I'm hoping to get setup to submit patches eventually, but I'm not there yet and 
it's not on my critical path at the moment.  I'm just glad to hear I hadn't 
missed some critical setup piece.

Thanks for verifying it!

DaR


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


[U-Boot] Endless loop in cmd_log.c?

2010-05-05 Thread Dennis Ruffer
I am trying to implement CONFIG_LOGBUFFER and CONFIG_CMD_LOG on our ARM
systems and I seem to have run into an endless loop.  With loglevel=5 so we
still see our console output, the printf at the end of logbuff_printk
appears to create an endless loop.

I had to replace that line with serial_puts(msg);

Have I missed some other solution or do the systems that use this never set
logbuffer higher than default_message_loglevel?

DaR


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


[U-Boot] Endless loop in cmd_log.c?

2010-05-05 Thread Dennis Ruffer
I am trying to implement CONFIG_LOGBUFFER and CONFIG_CMD_LOG on our ARM
systems and I seem to have run into an endless loop.  With loglevel=5 so we
still see our console output, the printf at the end of logbuff_printk
appears to create an endless loop.

I had to replace that line with serial_puts(msg);

Have I missed some other solution or do the systems that use this never set
logbuffer higher than default_message_loglevel?

DaR


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


Re: [U-Boot] Endless loop in cmd_log.c?

2010-05-05 Thread Dennis Ruffer
Not sure why this hasn't come through in my 2 earlier attempts...

I am trying to implement CONFIG_LOGBUFFER and CONFIG_CMD_LOG on our ARM
systems and I seem to have run into an endless loop.  With loglevel=5 so we
still see our console output, the printf at the end of logbuff_printk
appears to create an endless loop.

I had to replace that line with serial_puts(msg);

Have I missed some other solution or do the systems that use this never set
logbuffer higher than default_message_loglevel?

DaR


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