On Fri, 4 Feb 2011, Tony Lindgren wrote:
> * Nicolas Pitre <nico@xxxxxxxxxxx> [110203 19:32]:
> > On Thu, 3 Feb 2011, Tony Lindgren wrote:
> >
> > > This way we can have the debug-macro.S be common for omap1 and omap2+
> > > and get sensible error messages booting the wrong zImage with
> > > CONFIG_AUTO_ZRELADDR selected. Note that this does not seem to work
> > > with u-boot and uImage.
> ...
>
> > Gaaaaah! This is horrible.
>
> -ENOREGISTERS :)
>
> > OK, you do want to store data in memory, right? So the best way to
> > always be position independent, even cross section, is to do the
> > following (inspired by RMK's trick in the p2v series):
> >
> > .data
> >
> > foo: .word 0 @ value for sput
> > .word 0 @ value for nik
> >
> > .text
> >
> > bar: .word .
> > .word foo
> >
> > sputnik:
> >
> > adr r0, bar @ get relative address of bar
> > ldr r1, [r0] @ get absolute address of bar
> > sub r1, r1, r0 @ difference between abs and rel address
> > ldr r0, [r0, #4] @ get absolute address of foo
> > sub r0, r0, r1 @ turn that into a relative address
> >
> > ldmia r0, {r1, r2} @ retrieve sput and nik
> > add r0, r1, r2
> > mov pc, lr
> >
> > This code is totally position independent, so it works whether or not
> > the MMU is active. Therefore a similar technique in your macro (you
> > could even put it into a macro for it) would allow you to get rid of the
> > mrc and test for MMU active, get rid of the #ifdef, and not be limited
> > to a 128 MB mask, etc. And it is just one word longer than your
> > shortest version i.e. 2 constants + 5 instructions vs 4 instructions + 2
> > literal pool entries.
>
> I think if we keep the address of the memory location in rx instead of
> the port address value, then this could be done.
>
> That would limit all the trickery to inituart only. Then addruart and
> busyuart could just do ldr from the memory location to get the port
> data without any trickery.
Just create a get_config_ptr macro or similar and the trickery will be
nicely encapsulated. You'd have:
.macro get_config_ptr ptr, tmp
b 9002f
.align
9001: .long .
.long uart_param_storage
9002: adr \ptr, 9001b
ldr \tmp, [\ptr]
sub \tmp, \tmp, \ptr
ldr \ptr, [\ptr, #4]
sub \ptr, \ptr, \tmp
.endm
.macro addruart rp, rv
get_config_ptr \rv
ldr \rp, [\rv]
ldr \rv, [\rv, #4]
.endm
And for the other macros, you get the hardware address to use already,
but you can still use get_config_ptr for extra config values you
need if necessary.
> In that case the mapping of IO space for the serial port in head.S
> would have to be changed as that relies on rx containing the port
> IO address..
Yes, and I'm not sure if it is worth changing that at this point when it
is possible to do it without introducing such a change which would
affect all machines again.
Nicolas
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
