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

[Tony Lindgren <tony@atomide.com>]

* Pandita, Vikram <vikram.pandita@ti.com> [100122 15:08]:
> Tony
> 
> >-----Original Message-----
> >From: Tony Lindgren [mailto:tony@atomide.com]
> >Sent: Friday, January 22, 2010 3:11 PM
> >To: Pandita, Vikram
> >Cc: Russell King - ARM Linux; linux-arm-kernel@lists.infradead.org; linux-omap@vger.kernel.org
> >Subject: Re: [PATCH 2/4] omap: Make uncompress code and DEBUG_LL code generic, v2
> >
> >* Pandita, Vikram <vikram.pandita@ti.com> [100122 12:56]:
> >>
> >>
> >> >-----Original Message-----
> >> >From: Tony Lindgren [mailto:tony@atomide.com]
> >> >Sent: Friday, January 22, 2010 2:55 PM
> >> >To: Pandita, Vikram
> >> >Cc: Russell King - ARM Linux; linux-arm-kernel@lists.infradead.org; linux-omap@vger.kernel.org
> >> >Subject: Re: [PATCH 2/4] omap: Make uncompress code and DEBUG_LL code generic, v2
> >> >
> >> >* Pandita, Vikram <vikram.pandita@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.

Right, we really need 0x48000000 mapped :)
 
> 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?

Please take a look at arch/arm/kernel/head.S where you can add
the extra mapping early on.

Hmm, I wonder if we cand nowadays do the extra mapping for zoom
external uart in arch/arm/kernel/early_printk.c?

Are you getting anything out of the zoom uart before MMU is
enabled?

To test this you can temporarily break your kernel by commenting
out the start_kernel line in head-common.S. Then the code falls
through to __error_p and prints out a processor error..

Regards,

Tony