[U-Boot-Users] [PATCH] MACOSX support
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);
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.
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
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
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
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
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.
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
participants (5)
-
Aubrey Li -
Leonid -
Robin Getz -
Timur Tabi -
Wolfgang Denk