[U-Boot] Please pull u-boot-x86.git
Hi Tom,
This series includes the sandbox map_sysmem() feature, and gets the memory and hashing functions running on sandbox to allow testing/code coverage. I have run it through buildman and it seems clean, with the proviso that I don't have fully-working toolchains for all architectures.
The following changes since commit 9f024f62e4604274a23213dcee30016092e32e7b:
Merge branch 'fixes' of git://git.denx.de/u-boot-mips (2013-02-15 12:23:42 -0500)
are available in the git repository at:
git://git.denx.de/u-boot-x86.git master
for you to fetch changes up to d76bd1c2d5e75db16b239bd2d4a642673974e250:
sandbox: Allow hash functions to work correctly (2013-02-15 16:06:06 -0800)
---------------------------------------------------------------- Allen Martin (1): sandbox: fix compiler warning
Simon Glass (19): Tidy up error checking and fix bug in hash command Update print_buffer() to use const sandbox: Add un/map_sysmen() to deal with sandbox's ram_buf sandbox: Change memory commands to use map_physmem Split out the memory tests into separate functions Use common mtest iteration counting Fix mtest indenting Bring mtest putc() into common code Reduce casting in mtest Update set_working_fdt_addr() to use setenv_addr() common: Use new numeric setenv functions drivers: Use new numeric setenv functions net: Use new numeric setenv functions image: Use crc header file instead of C prototypes Roll crc32 into hash infrastructure sandbox: config: Enable hash functions and mtest Move CONFIG_SYS_MEMTEST_SCRATCH #ifdef to top of file sandbox: Update mtest to fix crashes sandbox: Allow hash functions to work correctly
Taylor Hutt (1): sandbox: Improve sandbox serial port keyboard interface
README | 9 + arch/sandbox/config.mk | 1 + arch/sandbox/cpu/os.c | 8 + arch/sandbox/cpu/start.c | 3 + arch/sandbox/include/asm/io.h | 10 + common/cmd_bootm.c | 11 +- common/cmd_cbfs.c | 4 +- common/cmd_cramfs.c | 4 +- common/cmd_fdos.c | 4 +- common/cmd_fdt.c | 11 +- common/cmd_hash.c | 4 + common/cmd_jffs2.c | 4 +- common/cmd_load.c | 12 +- common/cmd_mem.c | 798 +++++++++++++++++++++--------------------- common/cmd_mtdparts.c | 4 +- common/cmd_nand.c | 12 +- common/cmd_nvedit.c | 11 +- common/cmd_reiser.c | 4 +- common/cmd_setexpr.c | 39 ++- common/cmd_unzip.c | 4 +- common/cmd_ximg.c | 7 +- common/cmd_zfs.c | 3 +- common/cmd_zip.c | 4 +- common/hash.c | 31 +- common/image.c | 4 +- drivers/net/fm/fm.c | 4 +- drivers/serial/sandbox.c | 44 ++- fs/fs.c | 4 +- fs/ubifs/ubifs.c | 4 +- include/common.h | 29 +- include/configs/sandbox.h | 9 +- include/hash.h | 2 +- include/os.h | 10 + include/u-boot/crc.h | 11 + lib/crc32.c | 9 + lib/display_options.c | 3 +- net/net.c | 8 +- 37 files changed, 615 insertions(+), 528 deletions(-)
Regards, Simon
Dear Simon Glass,
In message CAPnjgZ2P6sBDXiwXW2TeCdjADMhkN5iNBGrpZbtvwMqUtYVVxA@mail.gmail.com you wrote:
Hi Tom,
This series includes the sandbox map_sysmem() feature, and gets the memory and hashing functions running on sandbox to allow testing/code coverage. I have run it through buildman and it seems clean, with the proviso that I don't have fully-working toolchains for all architectures.
NAK. It is not correct to push changes that affect global code through a arch-specific custodian tree, especially if the submitter of the patche(es) is identical to the custodian of the very tree, and even more so if there have been not ANY independent Acked-by: or at least Tested-by: messages.
This is NOT how the peer review process is supposed to work!!
Especially as a custodian you must not do such things.
Best regards,
Wolfgang Denk
Hi Wolfgang,
On Sun, Feb 17, 2013 at 12:58 PM, Wolfgang Denk wd@denx.de wrote:
Dear Simon Glass,
In message CAPnjgZ2P6sBDXiwXW2TeCdjADMhkN5iNBGrpZbtvwMqUtYVVxA@mail.gmail.com you wrote:
Hi Tom,
This series includes the sandbox map_sysmem() feature, and gets the memory and hashing functions running on sandbox to allow testing/code coverage. I have run it through buildman and it seems clean, with the proviso that I don't have fully-working toolchains for all architectures.
NAK. It is not correct to push changes that affect global code through a arch-specific custodian tree, especially if the submitter of the patche(es) is identical to the custodian of the very tree, and even more so if there have been not ANY independent Acked-by: or at least Tested-by: messages.
This is NOT how the peer review process is supposed to work!!
Especially as a custodian you must not do such things.
OK, I was not quite sure what to do, so may have misunderstood Tom's instructions - there is a short thread here http://comments.gmane.org/gmane.comp.boot-loaders.u-boot/153342
I have created a patchwork bundle instead.
http://patchwork.ozlabs.org/bundle/sjg/sandbox-mem/
Only one patch was Acked, so it could certainly use a few more eyes. However, it has been on the list for nearly two months, and I feel that applying things too close to the next release doesn't give people a lot of time to find problems.
Regards, Simon
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@denx.de Pray to God, but keep rowing to shore. - Russian Proverb
On Sun, Feb 17, 2013 at 01:32:58PM -0800, Simon Glass wrote:
Hi Wolfgang,
On Sun, Feb 17, 2013 at 12:58 PM, Wolfgang Denk wd@denx.de wrote:
Dear Simon Glass,
In message CAPnjgZ2P6sBDXiwXW2TeCdjADMhkN5iNBGrpZbtvwMqUtYVVxA@mail.gmail.com you wrote:
Hi Tom,
This series includes the sandbox map_sysmem() feature, and gets the memory and hashing functions running on sandbox to allow testing/code coverage. I have run it through buildman and it seems clean, with the proviso that I don't have fully-working toolchains for all architectures.
NAK. It is not correct to push changes that affect global code through a arch-specific custodian tree, especially if the submitter of the patche(es) is identical to the custodian of the very tree, and even more so if there have been not ANY independent Acked-by: or at least Tested-by: messages.
This is NOT how the peer review process is supposed to work!!
Especially as a custodian you must not do such things.
OK, I was not quite sure what to do, so may have misunderstood Tom's instructions - there is a short thread here http://comments.gmane.org/gmane.comp.boot-loaders.u-boot/153342
I have created a patchwork bundle instead.
OK, I thought I said, but maybe I didn't, I'm OK with re-using the tree, but _not_ the master branch, u-boot-x86/sandbox would have been fine.
On Mon, Feb 18, 2013 at 7:52 PM, Tom Rini trini@ti.com wrote:
OK, I thought I said, but maybe I didn't, I'm OK with re-using the tree, but _not_ the master branch, u-boot-x86/sandbox would have been fine.
Personally I'd prefer another tree as done for other custodians. It makes life of new developers easier.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 02/18/2013 06:30 PM, Otavio Salvador wrote:
On Mon, Feb 18, 2013 at 7:52 PM, Tom Rini trini@ti.com wrote:
OK, I thought I said, but maybe I didn't, I'm OK with re-using the tree, but _not_ the master branch, u-boot-x86/sandbox would have been fine.
Personally I'd prefer another tree as done for other custodians. It makes life of new developers easier.
It doesn't scale, however. If I had my wish and we were starting this afresh, I'd go with user repositories rather than subject repositories. Using Simon as the example, I don't think he needs one for sandbox, one for patman (and other tools) and one for x86. I'd rather pull .../sjc/for-trini/x86-whatever-vs-something.
- -- Tom
On Mon, Feb 18, 2013 at 8:45 PM, Tom Rini trini@ti.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 02/18/2013 06:30 PM, Otavio Salvador wrote:
On Mon, Feb 18, 2013 at 7:52 PM, Tom Rini trini@ti.com wrote:
OK, I thought I said, but maybe I didn't, I'm OK with re-using the tree, but _not_ the master branch, u-boot-x86/sandbox would have been fine.
Personally I'd prefer another tree as done for other custodians. It makes life of new developers easier.
It doesn't scale, however. If I had my wish and we were starting this afresh, I'd go with user repositories rather than subject repositories. Using Simon as the example, I don't think he needs one for sandbox, one for patman (and other tools) and one for x86. I'd rather pull .../sjc/for-trini/x86-whatever-vs-something.
The hassle to send to separated branches is the same for different remotes; what concerns me is a new developer to try to find patman or sandbox pending patches and do not realize it is at x86 tree. This is confusing.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 02/18/2013 06:48 PM, Otavio Salvador wrote:
On Mon, Feb 18, 2013 at 8:45 PM, Tom Rini trini@ti.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 02/18/2013 06:30 PM, Otavio Salvador wrote:
On Mon, Feb 18, 2013 at 7:52 PM, Tom Rini trini@ti.com wrote:
OK, I thought I said, but maybe I didn't, I'm OK with re-using the tree, but _not_ the master branch, u-boot-x86/sandbox would have been fine.
Personally I'd prefer another tree as done for other custodians. It makes life of new developers easier.
It doesn't scale, however. If I had my wish and we were starting this afresh, I'd go with user repositories rather than subject repositories. Using Simon as the example, I don't think he needs one for sandbox, one for patman (and other tools) and one for x86. I'd rather pull .../sjc/for-trini/x86-whatever-vs-something.
The hassle to send to separated branches is the same for different remotes; what concerns me is a new developer to try to find patman or sandbox pending patches and do not realize it is at x86 tree. This is confusing.
It's not that great in kernel-land, I agree. But at least for U-Boot I hope we would be able to keep the number, and possibly as/more importantly, the time trees are not in master (or next) but have good things in them.
- -- Tom
Hi Tom,
On Mon, Feb 18, 2013 at 2:52 PM, Tom Rini trini@ti.com wrote:
On Sun, Feb 17, 2013 at 01:32:58PM -0800, Simon Glass wrote:
Hi Wolfgang,
On Sun, Feb 17, 2013 at 12:58 PM, Wolfgang Denk wd@denx.de wrote:
Dear Simon Glass,
In message CAPnjgZ2P6sBDXiwXW2TeCdjADMhkN5iNBGrpZbtvwMqUtYVVxA@mail.gmail.com you wrote:
Hi Tom,
This series includes the sandbox map_sysmem() feature, and gets the memory and hashing functions running on sandbox to allow testing/code coverage. I have run it through buildman and it seems clean, with the proviso that I don't have fully-working toolchains for all architectures.
NAK. It is not correct to push changes that affect global code through a arch-specific custodian tree, especially if the submitter of the patche(es) is identical to the custodian of the very tree, and even more so if there have been not ANY independent Acked-by: or at least Tested-by: messages.
This is NOT how the peer review process is supposed to work!!
Especially as a custodian you must not do such things.
OK, I was not quite sure what to do, so may have misunderstood Tom's instructions - there is a short thread here http://comments.gmane.org/gmane.comp.boot-loaders.u-boot/153342
I have created a patchwork bundle instead.
OK, I thought I said, but maybe I didn't, I'm OK with re-using the tree, but _not_ the master branch, u-boot-x86/sandbox would have been fine.
Yes, you said "toss it into a branch in u-boot-x86.git". It did cross my mind to use something other than master, but I wasn't sure if that was OK in U-Boot. I know for next time.
Regards, Simon
-- Tom
Hi Tom,
I have pulled the latest series into a branch in the x86 tree. You can also get it from patchwork. If you are happy with it, please see below. I haven't seen any comments for a few days.
The following changes since commit 47104c37de076e2be35ae1b3d144614f4d24a766:
MAKEALL: add support for per architecture toolchains (2013-02-20 09:40:34 -0500)
are available in the git repository at:
git://git.denx.de/u-boot-x86.git mem
for you to fetch changes up to dc63c7ccecee7b22fdc06f2c9d62d53bd5511b00:
hash: Use lower case for hash algorithm names (2013-02-27 13:13:16 -0800)
---------------------------------------------------------------- Allen Martin (1): sandbox: fix compiler warning
Simon Glass (21): Tidy up error checking and fix bug in hash command Update print_buffer() to use const sandbox: Add un/map_sysmen() to deal with sandbox's ram_buf sandbox: Change memory commands to use map_physmem Split out the memory tests into separate functions Use common mtest iteration counting Fix mtest indenting Bring mtest putc() into common code Reduce casting in mtest Update set_working_fdt_addr() to use setenv_addr() common: Use new numeric setenv functions fs: Use new numeric setenv functions net: Use new numeric setenv functions image: Use crc header file instead of C prototypes hash: Add a flag to support saving hashes in the environment Roll crc32 into hash infrastructure sandbox: config: Enable hash functions and mtest Move CONFIG_SYS_MEMTEST_SCRATCH #ifdef to top of file sandbox: Update mtest to fix crashes sandbox: Allow hash functions to work correctly hash: Use lower case for hash algorithm names
Taylor Hutt (1): sandbox: Improve sandbox serial port keyboard interface
README | 9 + arch/sandbox/config.mk | 1 + arch/sandbox/cpu/os.c | 8 + arch/sandbox/cpu/start.c | 3 + arch/sandbox/include/asm/io.h | 10 + common/cmd_bootm.c | 11 +- common/cmd_cbfs.c | 4 +- common/cmd_cramfs.c | 4 +- common/cmd_fdos.c | 4 +- common/cmd_fdt.c | 11 +- common/cmd_hash.c | 14 +- common/cmd_jffs2.c | 4 +- common/cmd_load.c | 12 +- common/cmd_mem.c | 798 +++++++++++++++++++++--------------------- common/cmd_mtdparts.c | 4 +- common/cmd_nand.c | 12 +- common/cmd_nvedit.c | 11 +- common/cmd_reiser.c | 4 +- common/cmd_setexpr.c | 39 ++- common/cmd_sha1sum.c | 6 +- common/cmd_unzip.c | 4 +- common/cmd_ximg.c | 7 +- common/cmd_zfs.c | 3 +- common/cmd_zip.c | 4 +- common/hash.c | 194 +++++++--- common/image.c | 4 +- drivers/net/fm/fm.c | 4 +- drivers/serial/sandbox.c | 44 ++- fs/fs.c | 4 +- fs/ubifs/ubifs.c | 4 +- include/common.h | 29 +- include/configs/sandbox.h | 9 +- include/hash.h | 13 +- include/os.h | 10 + include/u-boot/crc.h | 11 + lib/crc32.c | 9 + lib/display_options.c | 3 +- net/net.c | 8 +- 38 files changed, 750 insertions(+), 583 deletions(-)
Regards, Simon
On Mon, Feb 18, 2013 at 9:22 PM, Simon Glass sjg@chromium.org wrote:
Hi Tom,
On Mon, Feb 18, 2013 at 2:52 PM, Tom Rini trini@ti.com wrote:
On Sun, Feb 17, 2013 at 01:32:58PM -0800, Simon Glass wrote:
Hi Wolfgang,
On Sun, Feb 17, 2013 at 12:58 PM, Wolfgang Denk wd@denx.de wrote:
Dear Simon Glass,
In message CAPnjgZ2P6sBDXiwXW2TeCdjADMhkN5iNBGrpZbtvwMqUtYVVxA@mail.gmail.com you wrote:
Hi Tom,
This series includes the sandbox map_sysmem() feature, and gets the memory and hashing functions running on sandbox to allow testing/code coverage. I have run it through buildman and it seems clean, with the proviso that I don't have fully-working toolchains for all architectures.
NAK. It is not correct to push changes that affect global code through a arch-specific custodian tree, especially if the submitter of the patche(es) is identical to the custodian of the very tree, and even more so if there have been not ANY independent Acked-by: or at least Tested-by: messages.
This is NOT how the peer review process is supposed to work!!
Especially as a custodian you must not do such things.
OK, I was not quite sure what to do, so may have misunderstood Tom's instructions - there is a short thread here http://comments.gmane.org/gmane.comp.boot-loaders.u-boot/153342
I have created a patchwork bundle instead.
OK, I thought I said, but maybe I didn't, I'm OK with re-using the tree, but _not_ the master branch, u-boot-x86/sandbox would have been fine.
Yes, you said "toss it into a branch in u-boot-x86.git". It did cross my mind to use something other than master, but I wasn't sure if that was OK in U-Boot. I know for next time.
Regards, Simon
-- Tom
On Wed, Feb 27, 2013 at 01:18:23PM -0800, Simon Glass wrote:
Hi Tom,
I have pulled the latest series into a branch in the x86 tree. You can also get it from patchwork. If you are happy with it, please see below. I haven't seen any comments for a few days.
OK, building with ELDK4.2 for a number of ARM boards such as igep0030: cmd_mem.c: In function 'do_mem_mtest': cmd_mem.c:979: warning: passing argument 1 of 'unmap_sysmem' discards qualifiers from pointer target type cmd_mem.c:980: warning: passing argument 1 of 'unmap_sysmem' discards qualifiers from pointer target type
Please fix and re-submit, thanks.
Hi Tom,
On Thu, Feb 28, 2013 at 3:00 PM, Tom Rini trini@ti.com wrote:
On Wed, Feb 27, 2013 at 01:18:23PM -0800, Simon Glass wrote:
Hi Tom,
I have pulled the latest series into a branch in the x86 tree. You can also get it from patchwork. If you are happy with it, please see below. I haven't seen any comments for a few days.
OK, building with ELDK4.2 for a number of ARM boards such as igep0030: cmd_mem.c: In function 'do_mem_mtest': cmd_mem.c:979: warning: passing argument 1 of 'unmap_sysmem' discards qualifiers from pointer target type cmd_mem.c:980: warning: passing argument 1 of 'unmap_sysmem' discards qualifiers from pointer target type
Strange - there is even an explicit cast,. But mine is gcc 4.4.1 so may be a bit later. I could just remove those two lines since they are only there for semantic correctness and compile to nothing anyway. But I will track down that tool chain and see if I can work out a fix.
Regards, Simon
Please fix and re-submit, thanks.
-- Tom
Hi Tom,
On Thu, Feb 28, 2013 at 4:22 PM, Simon Glass sjg@chromium.org wrote:
Hi Tom,
On Thu, Feb 28, 2013 at 3:00 PM, Tom Rini trini@ti.com wrote:
On Wed, Feb 27, 2013 at 01:18:23PM -0800, Simon Glass wrote:
Hi Tom,
I have pulled the latest series into a branch in the x86 tree. You can also get it from patchwork. If you are happy with it, please see below. I haven't seen any comments for a few days.
OK, building with ELDK4.2 for a number of ARM boards such as igep0030: cmd_mem.c: In function 'do_mem_mtest': cmd_mem.c:979: warning: passing argument 1 of 'unmap_sysmem' discards qualifiers from pointer target type cmd_mem.c:980: warning: passing argument 1 of 'unmap_sysmem' discards qualifiers from pointer target type
Strange - there is even an explicit cast,. But mine is gcc 4.4.1 so may be a bit later. I could just remove those two lines since they are only there for semantic correctness and compile to nothing anyway. But I will track down that tool chain and see if I can work out a fix.
OK I have repeated this - it seems that the compiler does not like a direct 'cast away' of volatile in a function argument. I have added a work-around, and sent out an updated patch 20. You can either pull this in from patchwork, or I have updated the pull information below.
Rather ominously this might mean that I need to start building with multiple tool chains for each architecture. I was rather hoping to avoid that...
Thanks for spotting it.
Regards, Simon
Please fix and re-submit, thanks.
The following changes since commit a1eac57a2001ecf86a46f520cd85ef8e9c8b3687:
common/env_nand.c: calculate crc only when readenv was OK (2013-02-22 19:59:53 -0600)
are available in the git repository at:
git://git.denx.de/u-boot-x86.git mem
for you to fetch changes up to 218da0f35f4b5e5bf13d3dba6d975d4d5d65516f:
hash: Use lower case for hash algorithm names (2013-02-28 19:49:13 -0800)
---------------------------------------------------------------- Allen Martin (1): sandbox: fix compiler warning
Simon Glass (21): Tidy up error checking and fix bug in hash command Update print_buffer() to use const sandbox: Add un/map_sysmen() to deal with sandbox's ram_buf sandbox: Change memory commands to use map_physmem Split out the memory tests into separate functions Use common mtest iteration counting Fix mtest indenting Bring mtest putc() into common code Reduce casting in mtest Update set_working_fdt_addr() to use setenv_addr() common: Use new numeric setenv functions fs: Use new numeric setenv functions net: Use new numeric setenv functions image: Use crc header file instead of C prototypes hash: Add a flag to support saving hashes in the environment Roll crc32 into hash infrastructure sandbox: config: Enable hash functions and mtest Move CONFIG_SYS_MEMTEST_SCRATCH #ifdef to top of file sandbox: Update mtest to fix crashes sandbox: Allow hash functions to work correctly hash: Use lower case for hash algorithm names
Taylor Hutt (1): sandbox: Improve sandbox serial port keyboard interface
README | 9 + arch/sandbox/config.mk | 1 + arch/sandbox/cpu/os.c | 8 + arch/sandbox/cpu/start.c | 3 + arch/sandbox/include/asm/io.h | 10 + common/cmd_bootm.c | 11 +- common/cmd_cbfs.c | 4 +- common/cmd_cramfs.c | 4 +- common/cmd_fdos.c | 4 +- common/cmd_fdt.c | 11 +- common/cmd_hash.c | 14 +- common/cmd_jffs2.c | 4 +- common/cmd_load.c | 12 +- common/cmd_mem.c | 809 ++++++++++++++++++++++++++++++++-------------------------------- common/cmd_mtdparts.c | 4 +- common/cmd_nand.c | 12 +- common/cmd_nvedit.c | 11 +- common/cmd_reiser.c | 4 +- common/cmd_setexpr.c | 39 +++- common/cmd_sha1sum.c | 6 +- common/cmd_unzip.c | 4 +- common/cmd_ximg.c | 7 +- common/cmd_zfs.c | 3 +- common/cmd_zip.c | 4 +- common/hash.c | 194 +++++++++++----- common/image.c | 4 +- drivers/net/fm/fm.c | 4 +- drivers/serial/sandbox.c | 44 +++- fs/fs.c | 4 +- fs/ubifs/ubifs.c | 4 +- include/common.h | 29 ++- include/configs/sandbox.h | 9 +- include/hash.h | 13 +- include/os.h | 10 + include/u-boot/crc.h | 11 + lib/crc32.c | 9 + lib/display_options.c | 3 +- net/net.c | 8 +- 38 files changed, 761 insertions(+), 583 deletions(-)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 02/28/2013 10:55 PM, Simon Glass wrote:
Hi Tom,
On Thu, Feb 28, 2013 at 4:22 PM, Simon Glass sjg@chromium.org wrote:
Hi Tom,
On Thu, Feb 28, 2013 at 3:00 PM, Tom Rini trini@ti.com wrote:
On Wed, Feb 27, 2013 at 01:18:23PM -0800, Simon Glass wrote:
Hi Tom,
I have pulled the latest series into a branch in the x86 tree. You can also get it from patchwork. If you are happy with it, please see below. I haven't seen any comments for a few days.
OK, building with ELDK4.2 for a number of ARM boards such as igep0030: cmd_mem.c: In function 'do_mem_mtest': cmd_mem.c:979: warning: passing argument 1 of 'unmap_sysmem' discards qualifiers from pointer target type cmd_mem.c:980: warning: passing argument 1 of 'unmap_sysmem' discards qualifiers from pointer target type
Strange - there is even an explicit cast,. But mine is gcc 4.4.1 so may be a bit later. I could just remove those two lines since they are only there for semantic correctness and compile to nothing anyway. But I will track down that tool chain and see if I can work out a fix.
OK I have repeated this - it seems that the compiler does not like a direct 'cast away' of volatile in a function argument. I have added a work-around, and sent out an updated patch 20. You can either pull this in from patchwork, or I have updated the pull information below.
Thanks, I'll give it a day or two in public before re-pulling.
Rather ominously this might mean that I need to start building with multiple tool chains for each architecture. I was rather hoping to avoid that...
Thanks for spotting it.
Sadly, it's a must. ELDK4.2 is the oldest toolchain we support, but we do support it for ARM (except when THUMB is required, those fail gracefully tho). My build loops include ELDK4.2/arm, ELDK5.2/arm and whatever Linaro PPA has up, for ARM (and eldk5.2 for powerpc).
- -- Tom
On Thu, Feb 28, 2013 at 07:55:39PM -0800, Simon Glass wrote:
[snip]
The following changes since commit a1eac57a2001ecf86a46f520cd85ef8e9c8b3687:
common/env_nand.c: calculate crc only when readenv was OK (2013-02-22 19:59:53 -0600)
are available in the git repository at:
git://git.denx.de/u-boot-x86.git mem
for you to fetch changes up to 218da0f35f4b5e5bf13d3dba6d975d4d5d65516f:
hash: Use lower case for hash algorithm names (2013-02-28 19:49:13 -0800)
Allen Martin (1): sandbox: fix compiler warning
Simon Glass (21): Tidy up error checking and fix bug in hash command Update print_buffer() to use const sandbox: Add un/map_sysmen() to deal with sandbox's ram_buf sandbox: Change memory commands to use map_physmem Split out the memory tests into separate functions Use common mtest iteration counting Fix mtest indenting Bring mtest putc() into common code Reduce casting in mtest Update set_working_fdt_addr() to use setenv_addr() common: Use new numeric setenv functions fs: Use new numeric setenv functions net: Use new numeric setenv functions image: Use crc header file instead of C prototypes hash: Add a flag to support saving hashes in the environment Roll crc32 into hash infrastructure sandbox: config: Enable hash functions and mtest Move CONFIG_SYS_MEMTEST_SCRATCH #ifdef to top of file sandbox: Update mtest to fix crashes sandbox: Allow hash functions to work correctly hash: Use lower case for hash algorithm names
Taylor Hutt (1): sandbox: Improve sandbox serial port keyboard interface
README | 9 + arch/sandbox/config.mk | 1 + arch/sandbox/cpu/os.c | 8 + arch/sandbox/cpu/start.c | 3 + arch/sandbox/include/asm/io.h | 10 + common/cmd_bootm.c | 11 +- common/cmd_cbfs.c | 4 +- common/cmd_cramfs.c | 4 +- common/cmd_fdos.c | 4 +- common/cmd_fdt.c | 11 +- common/cmd_hash.c | 14 +- common/cmd_jffs2.c | 4 +- common/cmd_load.c | 12 +- common/cmd_mem.c | 809 ++++++++++++++++++++++++++++++++-------------------------------- common/cmd_mtdparts.c | 4 +- common/cmd_nand.c | 12 +- common/cmd_nvedit.c | 11 +- common/cmd_reiser.c | 4 +- common/cmd_setexpr.c | 39 +++- common/cmd_sha1sum.c | 6 +- common/cmd_unzip.c | 4 +- common/cmd_ximg.c | 7 +- common/cmd_zfs.c | 3 +- common/cmd_zip.c | 4 +- common/hash.c | 194 +++++++++++----- common/image.c | 4 +- drivers/net/fm/fm.c | 4 +- drivers/serial/sandbox.c | 44 +++- fs/fs.c | 4 +- fs/ubifs/ubifs.c | 4 +- include/common.h | 29 ++- include/configs/sandbox.h | 9 +- include/hash.h | 13 +- include/os.h | 10 + include/u-boot/crc.h | 11 + lib/crc32.c | 9 + lib/display_options.c | 3 +- net/net.c | 8 +- 38 files changed, 761 insertions(+), 583 deletions(-)
Applied to u-boot/master, thanks!
participants (4)
-
Otavio Salvador -
Simon Glass -
Tom Rini -
Wolfgang Denk