From: Bradey H. <br...@gm...> - 2010-03-14 07:30:39
|
I ran into a problem when trying to program a binary image to flash at 0xc0000000--"flash write_bank" worked, but "flash write_image failed": > flash write_bank 0 redboot.bin 0 not enough working area available(requested 32768, free 32672) wrote 167564 bytes from file redboot.bin to flash bank 0 at offset 0x00000000 in 9.593578s (17.057 kb/s) > flash write_image erase redboot.bin 0xc0000000 bin auto erase enabled Argument overflow image.base_address option value ('0xc0000000') is not valid Command handler execution failed in procedure 'flash' called at file "command.c", line 650 called at file "command.c", line 361 After digging into it a bit, I found that the offset argument to flash write_image is saved in image.base_address, which is an int; the COMMAND_PARSE_NUMBER() call was failing because the (unsigned) argument was overflowing a (signed) int. This is an issue with the etm image and xscale trace_image commands as well. Using unsigned int as the image.base_address type worked for me, since binary images don't have a start address, but it should really be a signed offset for images that do contain a start address, so I changed it to long long. I didn't add a check for overflow when adding image.base_address to the image/section start address--that's possible now, so I assumed if it was necessary it would already be there. Patch with commit message is attached; comments and corrections welcome. Patch is against 0.4.0, but I can rediff against head if it doesn't apply cleanly. - Bradey |