Bug in cmd_bootm.c (byteorder)
Hi there,
IIUC then numbers in image headers (image_header_t) are stored in network byteorder. So when manipulating image headers on the target (i.e. overwriting ih_load) this has to be done in network byteorder.
I noticed a problem when passing a second argument to bootm
#> bootm 20500000 20400000
on an ARM platform.
The data from the my "ARM U-Boot Standalone Program (uncompressed)" was wrongly copied to 0x00004020!
So I suggest the following buxfix:
Index: common/cmd_bootm.c
===================================================================
RCS file: /cvsroot/u-boot/u-boot/common/cmd_bootm.c,v retrieving revision 1.42
cmd_bootm.c 10 Jun 2005 11:43:11 -0000 renamed from cmd_bootm.c 3 Apr 2005 21:11:18 -0000 1.42 +1 -1
@@ -261,7 +261,7 @@ name = "Standalone Application"; /* A second argument overwrites the load address */ if (argc > 2) { - hdr->ih_load = simple_strtoul(argv[2], NULL, 16); + hdr->ih_load = htonl(simple_strtoul(argv[2], NULL, 16)); } break; case IH_TYPE_KERNEL:
--
Steven
Quoted 4 lines · In message <[email protected]> you wrote:
IIUC then numbers in image headers (
image_header_t) are stored in network byteorder. So when manipulating image headers on the target (i.e. overwritingih_load) this has to be done in network byteorder.
You are right - well spotted.
Quoted 1 line
So I suggest the following buxfix:
Checked in locally, will push to public CVS asap.
Best regards,
Wolfgang Denk
Signature · 3 lines
Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de "Virtual" means never knowing where your next byte is coming from.