[PATCH v3] ARM: xip: Use correct symbol for end of ROM marker

[Chris Brandt]

Hi Nicolas,

> Here's the patch with proper changelog, etc.  I don't have XIP
> capable hardware to test it with though.


I'm testing it now...but it's crashing.

I fired up GDB, so here the reason:


__v7_ca17mp_setup:
	mov	r10, #0
1:	adr	r0, __v7_setup_stack_ptr
r0=0x18213df4

	ldr	r12, [r0]
r12=0x10174cc

	add	r12, r12, r0			@ the local stack
r12=0x1922b2c0

	stmia	r12, {r1-r6, lr}		@ v7_invalidate_l1 touches r0-r6
	bl      v7_invalidate_l1


0x1922b2c0 is NOT RAM....it's nothing.


As point of reference, here's the memory map of my XIP system:
  Physical ROM address: 0x18000000 (I have my XIP kernel starting at 0x18200000)
  Physical RAM address: 0x20000000
  Virtual ROM  address: 0xBF0000000
  Virtual RAM  address: 0xC00000000


Basically, you made the same mistake that Magnus first did: You can't rely on the current PC address to obtain an address in physical RAM because the ROM virt-to-phys relationship is different than the RAM virt-to-phys relationship.

No matter how you look at it, this early in boot, the only 'thing' that really knows where physical RAM is located is PLAT_PHYS_OFFSET.

That's why both Magnus's an my patches (that I both tested) contain PLAT_PHYS_OFFSET.


The only other 'slight' piece of info would be the DTB pointer is still sitting in R2 from boot, and at least for my system, that is in RAM. However, the DTB could be in ROM if the user wanted it to be, and I also think that this code might run twice in a SMP system...so even R2 would not be reliable. So...forget I mentioned it...


I don't see any way around not having a "#ifdef XIP_KERNEL" statement in order to expose PLAT_PHYS_OFFSET so you can properly do your translation math.


Chris


ps, I will add that I appreciate your efforts with this.