Dear Ruben,
I don't understand why you are bringing this issue again. We have
already been discussing that quite a lot in our private conversation.
This is the normal behaviour of the objcopy tool. Following is the
excerpt from objcopy manual:
"When objcopy generates a raw binary file, it will essentially produce a
memory dump of the contents of the input object file. All symbols and
relocation information will be discarded. The memory dump will start at
the load address of the lowest section copied into the output file."
The way it is currently working is correct and there is no reason to
change it. People and companies working with that port have their
bulding scripts. I will not make an unjustified update that will break
their scripts.
If you really need a binary that should be loaded from 0x000 you need to
glue the remaining bytes yourself, using dd for example.
Best regards,
Piotr
W dniu 2012-11-03 22:05, R. Diez pisze:
Hi Piotr:
Regarding the addressing issues I'm having with "objcopy
--output-target=binary", where the reset address 0x100 is coming up as
the first byte (address 0x000) in the .bin file, please find
file:///home/rdiez/rdiez/orbuild/Repositories/ECOS/BinAddressIssue.patchattached
a patch to fix it for the RAM scenario (the most common one).
When building for ROM, you need to change the vector addresses in
vectors.S from 0x100 to 0xF0000100 and so on. Could you look into this?
I think it's just a matter of checking configuration settings
CYG_HAL_STARTUP and CYGHWR_MEMORY_LAYOUT and defining the vector
addresses accordingly.
Or do you know some other way to make objcopy start dumping at address
0, so that it pads with zeros as necessary and the reset vector lands
then at 0x100?
Thanks,
rdiez
_______________________________________________
OpenRISC mailing list
[email protected]
http://lists.openrisc.net/listinfo/openrisc
