[PATCH 2/4] omap: Make uncompress code and DEBUG_LL code generic, v2

[Pandita, Vikram]

Tony

>-----Original Message-----
>From: Tony Lindgren [mailto:tony at atomide.com]
>Sent: Friday, January 22, 2010 3:11 PM
>To: Pandita, Vikram
>Cc: Russell King - ARM Linux; linux-arm-kernel at lists.infradead.org; linux-omap at vger.kernel.org
>Subject: Re: [PATCH 2/4] omap: Make uncompress code and DEBUG_LL code generic, v2
>
>* Pandita, Vikram <vikram.pandita at ti.com> [100122 12:56]:
>>
>>
>> >-----Original Message-----
>> >From: Tony Lindgren [mailto:tony at atomide.com]
>> >Sent: Friday, January 22, 2010 2:55 PM
>> >To: Pandita, Vikram
>> >Cc: Russell King - ARM Linux; linux-arm-kernel at lists.infradead.org; linux-omap at vger.kernel.org
>> >Subject: Re: [PATCH 2/4] omap: Make uncompress code and DEBUG_LL code generic, v2
>> >
>> >* Pandita, Vikram <vikram.pandita at ti.com> [100122 06:46]:
>> >> >
>> >> >OK, I've added that too, but for mach-omap2 only. I've also
>> >> >added an experimental zoom2/3 support.
>> >> >
>> >> >Care to take try it out and see what happens on a zoom?
>> >>
>> >> Test on zoom3 failed with multi-omap branch.
>> >> Debugging the same, should have a zoom correction patch out today.
>> >
>> >Heh OK. I just pushed more updates into the multi-omap branch
>> >if you want to try to boot zoom2/zoom3 using the same .config.
>>
>> Refreshed my tree and I don't see your patches yet.
>
>Takes a few minutes to get mirrored from master.kernel.org..

Yes I tried with new branch and zoom2/3 does not work.
Root cause: 
There is a very basic issue in low level code.

We are allowed to create only one Physical to Virtual mapping using MACHINE_START() phys_io and io_pg_offst of size 0x100000(1MB).

Now for zoom2/3 we need to do following:
MACHINE_START(OMAP_ZOOM3, "OMAP Zoom3 board")
-       .phys_io        = 0x48000000,
-       .io_pg_offst    = ((0xfa000000) >> 18) & 0xfffc,
+       .phys_io        = 0x1000000, /*ZOOM_UART_BASE*/
+       .io_pg_offst    = ((0xfb000000) >> 18) & 0xfffc, /*ZOOM_UART_VIRT*/
        .boot_params    = 0x80000100,
        .map_io         = omap_zoom_map_io,
        .init_irq       = omap_zoom_init_irq,

This will create mapping:
0x1000000 <-> 0xfb000000 of 1MB

Now that leaves the phy address 0x4800000 omap register mapping, unmapped.

So the code to get scratchpad contents will abort:
arch/arm/mach-omap2/include/mach/debug-macro.S
	moveq   \rx, #0x48000000        @ physical base address
	movne   \rx, #0xfa000000        @ virtual base
	orr     \rx, \rx, #0x0006a000   @ uart1 on omap2/3/4


This seems to be a basic limitation of low level code and I have not clue how to circumvent this.
Thoughts?

Regards,
Vikram