[U-Boot-Users] [PATCH] MACOSX support

[U-Boot-Users] [PATCH] MACOSX support

[Aubrey Li]

The following patch fixes compilation issue on macosx

Singed-off-by: Marc Hoffman <Marc.Hoffman@analog.com>
Signed-off-by: Aubrey Li <aubrey.adi@gmail.com>
---
 tools/mkimage.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/mkimage.c b/tools/mkimage.c
index 416e658..2125130 100644
--- a/tools/mkimage.c
+++ b/tools/mkimage.c
@@ -446,7 +446,7 @@ NXTARG:		;
 	}

 	/* We're a bit of paranoid */
-#if defined(_POSIX_SYNCHRONIZED_IO) && !defined(__sun__) &&
!defined(__FreeBSD__)
+#if defined(_POSIX_SYNCHRONIZED_IO) && !defined(__sun__) &&
!defined(__FreeBSD__) && !defined(__APPLE__)
 	(void) fdatasync (ifd);
 #else
 	(void) fsync (ifd);
@@ -496,7 +496,7 @@ NXTARG:		;
 	(void) munmap((void *)ptr, sbuf.st_size);

 	/* We're a bit of paranoid */
-#if defined(_POSIX_SYNCHRONIZED_IO) && !defined(__sun__) &&
!defined(__FreeBSD__)
+#if defined(_POSIX_SYNCHRONIZED_IO) && !defined(__sun__) &&
!defined(__FreeBSD__) && !defined(__APPLE__)
 	(void) fdatasync (ifd);
 #else
 	(void) fsync (ifd);
-- 
1.5.0.6

-Aubrey

[U-Boot-Users] Non-Board specific patches - how to handle? Was: [PATCH] MACOSX support

[Robin Getz]

On Fri 20 Apr 2007 12:20, Aubrey Li pondered:
> The following patch fixes compilation issue on macosx
>
> Singed-off-by: Marc Hoffman <Marc.Hoffman@analog.com>
> Signed-off-by: Aubrey Li <aubrey.adi@gmail.com>
> ---
>  tools/mkimage.c |    4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/tools/mkimage.c b/tools/mkimage.c
> index 416e658..2125130 100644
> --- a/tools/mkimage.c
> +++ b/tools/mkimage.c
> @@ -446,7 +446,7 @@ NXTARG:		;
>  	}
>
>  	/* We're a bit of paranoid */
> -#if defined(_POSIX_SYNCHRONIZED_IO) && !defined(__sun__) &&
> !defined(__FreeBSD__)
> +#if defined(_POSIX_SYNCHRONIZED_IO) && !defined(__sun__) &&
> !defined(__FreeBSD__) && !defined(__APPLE__)
>  	(void) fdatasync (ifd);
>  #else
>  	(void) fsync (ifd);
> @@ -496,7 +496,7 @@ NXTARG:		;
>  	(void) munmap((void *)ptr, sbuf.st_size);
>
>  	/* We're a bit of paranoid */
> -#if defined(_POSIX_SYNCHRONIZED_IO) && !defined(__sun__) &&
> !defined(__FreeBSD__)
> +#if defined(_POSIX_SYNCHRONIZED_IO) && !defined(__sun__) &&
> !defined(__FreeBSD__) && !defined(__APPLE__)
>  	(void) fdatasync (ifd);
>  #else
>  	(void) fsync (ifd);

Wolfgang:

How would you like to handle patches like this?

Should an arch maintainer put it in their git tree, and push you the change - 
(even though it is common code) or is a patch to the mailing list the best 
way to handle?

Thanks.

[U-Boot-Users] Non-Board specific patches - how to handle? Was: [PATCH] MACOSX support

[Wolfgang Denk]

Dear Robin,

in message <200705111804.30232.rgetz@blackfin.uclinux.org> you wrote:
>
...
> > --- a/tools/mkimage.c
> > +++ b/tools/mkimage.c
> > @@ -446,7 +446,7 @@ NXTARG:		;
> >  	}
> >
> >  	/* We're a bit of paranoid */
> > -#if defined(_POSIX_SYNCHRONIZED_IO) && !defined(__sun__) &&
> > !defined(__FreeBSD__)
    ^^^^^^^^ linewrap
> > +#if defined(_POSIX_SYNCHRONIZED_IO) && !defined(__sun__) &&
> > !defined(__FreeBSD__) && !defined(__APPLE__)
    ^^^^^^^^ linewrap
> >  	(void) fdatasync (ifd);
> >  #else
> >  	(void) fsync (ifd);
> > @@ -496,7 +496,7 @@ NXTARG:		;
> >  	(void) munmap((void *)ptr, sbuf.st_size);
> >
> >  	/* We're a bit of paranoid */
> > -#if defined(_POSIX_SYNCHRONIZED_IO) && !defined(__sun__) &&
> > !defined(__FreeBSD__)
    ^^^^^^^^ linewrap
> > +#if defined(_POSIX_SYNCHRONIZED_IO) && !defined(__sun__) &&
> > !defined(__FreeBSD__) && !defined(__APPLE__)
    ^^^^^^^^ linewrap
> >  	(void) fdatasync (ifd);
> >  #else
> >  	(void) fsync (ifd);
...
> How would you like to handle patches like this?

Well, of course we reject such a patch, as it does not apply to any
code after being linewrapped by a broken / misconfigured mailer.

[But I guess this was not exactly your question :-) ]

> Should an arch maintainer put it in their git tree, and push you the change - 
> (even though it is common code) or is a patch to the mailing list the best 
> way to handle?

The "official" approach is that ALL patches get posted to the mailing
list, from where the respective custodian will pick it up.  I  intend
to  be  the  "ragpicker"  to  collect all items that are left. At the
moment this still suffers from a working patch tracking  system,  but
this is in the works (I know, I promised this too often already).

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,    CEO: 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: wd at denx.de
A Perl script is correct if it's halfway readable and  gets  the  job
done before your boss fires you.
                       - L. Wall & R. L. Schwartz, _Programming Perl_

[U-Boot-Users] Non-Board specific patches - how to handle? Was: [PATCH] MACOSX support

[Robin Getz]

On Fri 11 May 2007 18:37, Wolfgang Denk pondered:
> Dear Robin,
> > How would you like to handle patches like this?
>
> Well, of course we reject such a patch, as it does not apply to any
> code after being linewrapped by a broken / misconfigured mailer.

I saw my mailer mangled it, but I didn't notice it was because Aubrey's was 
messed up first. I guess that is the fun of sending patches via a web 
interface like gmail... :)

Aubrey - can you resend via a mailer that will not mangle the longer lines on 
Monday? Thx.

> [But I guess this was not exactly your question :-) ]
>
> > Should an arch maintainer put it in their git tree, and push you the
> > change - (even though it is common code) or is a patch to the mailing
> > list the best way to handle?
>
> The "official" approach is that ALL patches get posted to the mailing
> list, from where the respective custodian will pick it up.  I  intend
> to  be  the  "ragpicker"  to  collect all items that are left. At the
> moment this still suffers from a working patch tracking  system,  but
> this is in the works (I know, I promised this too often already).

No problem - I know that you/we all are busy, and everyone working all with 
the same rules makes things go faster...

Have a good weekend.
-Robin

[U-Boot-Users] "ERROR : memory not allocated" during HUSH script execution.

[Leonid]

Hi:

I have set of HUSH scripts running on u-boot 1.2.0. I'm using them for
testing. Scripts are rather complicated with some level of nesting where
one script can call other scripts (via "autoscr"). "setenv" command is
also used actively.

In certain point execution always fails because of memory allocation
failure (see screenshot in the bottom).

Of course, I don't expect somebody to resolve my particular scripting
problem; my question is of more general nature. I would like to ask
people, actively using HUSH shell, to share their information regarding
whether there are some known issues with HUSH or setenv.

May be, somebody has a patch to fix/replace/improve HUSH (which lacks
many functions anyway) and that can be very helpful as well.

Thanks,

Leonid.

LEDs Test............Success
Module ID............Success
DRAM Test............Success
Flash Test............Success
GPIO  Test.......
.................................
.................................Success
ETH LOOPBACK Test...Success
CAN GPIO Test...Success
MIL-1553 Test.......Success
Diagnostics Cycle 1 Complete
Succeeded: 8/8
Failed: 0/8
cycle_rc=0xffee
LEDs Test............Success
Module ID............Success
DRAM Test............Success
Flash Test............Success
GPIO  Test.......
.................................
.................................Success
ETH LOOPBACK Test...Success
CAN GPIO Test...Success
MIL-1553 Test.......Success
Diagnostics Cycle 2 Complete
Succeeded: 8/8
Failed: 0/8
cycle_rc=0xffee
LEDs Test............Success
Module ID............Success
DRAM Test............Success
Flash Test............Success
GPIO  Test.......
ERROR : memory not allocated

[U-Boot-Users] "ERROR : memory not allocated" during HUSH script execution.

[Wolfgang Denk]

In message <406A31B117F2734987636D6CCC93EE3C017B9A45@ehost011-3.exch011.intermedia.net> you wrote:
> 
> I have set of HUSH scripts running on u-boot 1.2.0. I'm using them for
> testing. Scripts are rather complicated with some level of nesting where
> one script can call other scripts (via "autoscr"). "setenv" command is
> also used actively.
> 
> In certain point execution always fails because of memory allocation
> failure (see screenshot in the bottom).

Well, even the tiniest check with the source  code  would  have  con-
firmed  what you could expect from the "ERROR : memory not allocated"
error message: malloc() resp. realloc() return error codes.

This sounds not really unlikely when you try running nested shell
scripts, which may need to allocate some data.

> Of course, I don't expect somebody to resolve my particular scripting
> problem; my question is of more general nature. I would like to ask

Well, but the solution is trivial: increase the size  of  the  malloc
arena  in  your board config file. Many boards define this as 128 kB,
which is enough for standard use in most cases, but in your case more
is needed.

> people, actively using HUSH shell, to share their information regarding
> whether there are some known issues with HUSH or setenv.

There are two completely separate topice.

"setenv" is a native U-Boot feature. I don't know of  any  issues  in
terms  of  memory  allocation, especially as "setenv" itself does not
allocate any new memory.

> May be, somebody has a patch to fix/replace/improve HUSH (which lacks
> many functions anyway) and that can be very helpful as well.

The hush shell is borrowed from the BusyBox project; you  might  want
to raise your concerns there.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,    CEO: 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: wd at denx.de
Change is the essential process of all existence.
	-- Spock, "Let That Be Your Last Battlefield",
	   stardate 5730.2

[U-Boot-Users] Non-Board specific patches - how to handle? Was: [PATCH] MACOSX support

[Timur Tabi]

Robin Getz wrote:

> I saw my mailer mangled it, but I didn't notice it was because Aubrey's was 
> messed up first. I guess that is the fun of sending patches via a web 
> interface like gmail... :)
> 
> Aubrey - can you resend via a mailer that will not mangle the longer lines on 
> Monday? Thx.

You could also use git-send-email to mail the patches.  It might take some experimentation 
to get the parameters right, but once you have it down, it's a lot easier than sending 
attachments via a mailer.

-- 
Timur Tabi
Linux Kernel Developer @ Freescale

[U-Boot-Users] Non-Board specific patches - how to handle? Was: [PATCH] MACOSX support

[Wolfgang Denk]

In message <464897A3.1040909@freescale.com> you wrote:
>
> You could also use git-send-email to mail the patches.  It might take some experimentation 
> to get the parameters right, but once you have it down, it's a lot easier than sending 
> attachments via a mailer.

This may, or may not, help. In some companies they are running MTAs
that cripple messages even if the sender's MUA works fine.

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: wd at denx.de
Lispers are among  the  best  grads  of  the  Sweep-It-Under-Someone-
Else's-Carpet  School of Simulated Simplicity. [Was that sufficiently
incendiary? :-)]  - Larry Wall in <1992Jan10.201804.11926@netlabs.com