Hi Joe, On Wed, 6 Nov 2013 09:18:53 -0700, Joe Kulikauskas <jkulikaus...@cardinalpeak.com> wrote:
> Hi, > > Rob, yes that's correct. > > To Albert's question: the disassembled instruction I had showed > LDR R3,ff0a0fc0 is load of r3 with address of the variable holding > the stack address; "this write" is the str which I've now copied in below. > IRQ_STACK_START_IN = gd->irq_sp + 8; > ff0a0fb0: e5992044 ldr r2, [r9, #68] ; 0x44 > ff0a0fb4: e2822008 add r2, r2, #8 > ff0a0fb8: e5832000 str r2, [r3] > > For my target, IIRC the write to flash caused problem in the flash > controller hardware, breaking further instruction fetches. On other > platforms the write to flash may fail silently. But the issue is that > interrupt_init() moving into board_init_f (i.e. before relocation) > generally just doesn't work right. > > Joe Thanks Rob and Joe for the clarification. Indeed interrupt_init() cannot execute before relocation as it sets globals. Further, interrupt_init() uses globals to communicate with start.S. This should be changed. I understand that is because the interrupt handlers actually set the interrupt stack when they are invoked -- and that is unnecessary; stacks should be set up as soon as their addresses are known. I'll revert the patch as soon as I finish getting the current PRs in. I have a start.S rewrite effort underway whcuh I should post soon. I'll add to it a change to the way stacks are initialized. Amicalement, -- Albert. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot