
Le 22/04/2011 14:45, Rogan Dawes a écrit :
On 2011/04/20 12:17 PM, Rogan Dawes wrote:
Now if I can just figure out how to write to my flash using OpenOCD, I can hopefully recover.
Regards,
Rogan
Phew! Thanks to Albert's sloflash utility, I was finally able to get something back into my flash, and get the board booting again. What a relief! :-D
Now I need to solve the problem of placing the _start code at the address of the reset vector, since I have 3 64kB sectors to play with, but one of them is 99% empty, other than the reset vector code which just jumps to _start.
And of course, a mainline u-boot will not fit into just 128kB.
Any thoughts on how to link u-boot to place _start or any other routine that can jump to _start at 0xffff0000?
I had this suggestion on IRC:
. = .; __u_boot_cmd_start = .; .u_boot_cmd : { *(.u_boot_cmd) } __u_boot_cmd_end = .; . = _start + 0x70000; .reset_vector_sect : { arch/arm/cpu/arm926ejs/start.o (.reset_vector_sect) *(.reset_vector_sect) } #include<asm-offsets.h> #include<config.h> #include<common.h> #include<version.h> .section ".reset_vector_sect",#alloc, #execinstr _reset_vector: b _start
Although I'm not sure how to interpret it :-)
Basically (the excepts are only a sketch of what is really needed) it amounts to manually mapping code sections, some at FFF80000 and some (the reset vectors first) at FFFF0000. It does not fill up the last sector at FFFF0000, not in this form at least, because the last sector would only contain the reset sector sections; you'd have to select other input sections to complement the reset vector ones. Plus, the generated binary would actually span the whole flash, from FFF80000 to FFFFxxxx, which is *huge*.
Regards,
Rogan
Amicalement,