Single binary kernel for all i.MX

Nicolas Pitre nico at fluxnic.net
Sat Nov 13 10:30:01 EST 2010


On Fri, 12 Nov 2010, Uwe Kleine-König wrote:

> Hi Anand,
> 
> On Fri, Nov 12, 2010 at 10:59:33PM +0530, Gadiyar, Anand wrote:
> > 2010/11/12 Uwe Kleine-König <u.kleine-koenig at pengutronix.de>:
> > > Hi Shawn,
> > >
> > > On Fri, Nov 12, 2010 at 11:40:41PM +0800, Shawn Guo wrote:
> > >> I'm studying at the implementation.  Can you please help me understand
> > >> how "addruart" in plat-mxc/include/mach/debug-macro.S works for single
> > >> image?
> > >>
> > >>         .macro  addruart, rp, rv
> > >>         ldr     \rp, =UART_PADDR        @ physical
> > >>         ldr     \rv, =UART_VADDR        @ virtual
> > >>         .endm
> > >>
> > >> We have this macro to get physical base address of UART.  However
> > >> UART_PADDR is defined as MX?_UART1_BASE_ADDR depending on
> > >> CONFIG_ARCH_MX*.  When all CONFIG_ARCH_MX* get defined in single image
> > >> case, how does UART_PADDR work for all CONFIG_ARCH_MX*?
> > > In a kernel that supports more than one SoC, DEBUG_LL won't work.  This
> > > is generally OK, because DEBUG_LL is only needed when bringing up a
> > > machine.  Therefor you can use a tailored kernel that only supports your
> > > shiny new machine.
> > >
> > > Uwe
> > >
> > 
> > Hi Uwe,
> > 
> > OMAP does have this working. For example, we can boot a single kernel image
> > on OMAP2, OMAP3 and OMAP4 today, and we have DEBUG_LL working for
> > sure on the last two - probably also on OMAP2.
> > 
> > I'm not exactly sure how this mechanism works, but for every new machine we
> > add, we usually add an entry in arch/arm/plat-omap/include/plat/uncompress.h
> You're mixing things up, mach/uncompress.h is for the Uncompressing
> Linux message when booting a zImage, mach/debug-macro.S is for DEBUG_LL
> and used to get debug messages out of the serial interface (usually).
> 
> The former will work for a multi-soc-imx-image, the latter probably not.

... and my previous comment applies to the later.


Nicolas


More information about the linux-arm-kernel mailing list