Single binary kernel for all i.MX

Single binary kernel for all i.MX

[Sascha Hauer]

Hi all,

We are talking about a single kernel for longer now, here is something
to test for the ones interested:

git://git.pengutronix.de/git/imx/linux-2.6.git imx-single-kernel

Compiling the imx_defconfig will result in a kernel which works
i.MX21, i.MX27, i.MX31, i.MX35 and i.MX51 (not tested on i.MX21).
i.MX1 does not work mainly because the kernel build will use some ARMv5
and later instructions.
The branch is based on the patches recently posted. It contains some
hacks, so it still needs to be worked on.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Single binary kernel for all i.MX

[Baruch Siach]

Hi Sascha,

On Fri, Nov 05, 2010 at 01:18:00PM +0100, Sascha Hauer wrote:
> We are talking about a single kernel for longer now, here is something
> to test for the ones interested:
> 
> git://git.pengutronix.de/git/imx/linux-2.6.git imx-single-kernel
> 
> Compiling the imx_defconfig will result in a kernel which works
> i.MX21, i.MX27, i.MX31, i.MX35 and i.MX51 (not tested on i.MX21).
> i.MX1 does not work mainly because the kernel build will use some ARMv5
> and later instructions.

What is blocking i.MX25 from being included?

baruch

> The branch is based on the patches recently posted. It contains some
> hacks, so it still needs to be worked on.
> 
> Sascha

-- 
                                                     ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -

Single binary kernel for all i.MX

[Sascha Hauer]

On Fri, Nov 05, 2010 at 02:29:46PM +0200, Baruch Siach wrote:
> Hi Sascha,
> 
> On Fri, Nov 05, 2010 at 01:18:00PM +0100, Sascha Hauer wrote:
> > We are talking about a single kernel for longer now, here is something
> > to test for the ones interested:
> > 
> > git://git.pengutronix.de/git/imx/linux-2.6.git imx-single-kernel
> > 
> > Compiling the imx_defconfig will result in a kernel which works
> > i.MX21, i.MX27, i.MX31, i.MX35 and i.MX51 (not tested on i.MX21).
> > i.MX1 does not work mainly because the kernel build will use some ARMv5
> > and later instructions.
> 
> What is blocking i.MX25 from being included?

It is. I just forgot to mention.

Sascha


-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Single binary kernel for all i.MX

[Eric Miao]

On Fri, Nov 5, 2010 at 8:31 PM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> On Fri, Nov 05, 2010 at 02:29:46PM +0200, Baruch Siach wrote:
>> Hi Sascha,
>>
>> On Fri, Nov 05, 2010 at 01:18:00PM +0100, Sascha Hauer wrote:
>> > We are talking about a single kernel for longer now, here is something
>> > to test for the ones interested:
>> >
>> > git://git.pengutronix.de/git/imx/linux-2.6.git imx-single-kernel
>> >
>> > Compiling the imx_defconfig will result in a kernel which works
>> > i.MX21, i.MX27, i.MX31, i.MX35 and i.MX51 (not tested on i.MX21).
>> > i.MX1 does not work mainly because the kernel build will use some ARMv5
>> > and later instructions.
>>
>> What is blocking i.MX25 from being included?
>
> It is. I just forgot to mention.

Hrm... the imx series is placing all header files in
arch/arm/plat-mxc/include/plat
instead of within each mach-*. Most other sub-arch doesn't behave like that at
this moment and getting them built together ain't easy.

BTW, did you get it tested on different boards, I'd be interested to see what
could be the potential issues at run-time.

>
> Sascha
>
>
> --
> Pengutronix e.K. ? ? ? ? ? ? ? ? ? ? ? ? ? | ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> Industrial Linux Solutions ? ? ? ? ? ? ? ? | http://www.pengutronix.de/ ?|
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 ? ?|
> Amtsgericht Hildesheim, HRA 2686 ? ? ? ? ? | Fax: ? +49-5121-206917-5555 |
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>

Single binary kernel for all i.MX

[Sascha Hauer]

Hi Eric,

On Sat, Nov 06, 2010 at 02:59:02AM +0800, Eric Miao wrote:
> On Fri, Nov 5, 2010 at 8:31 PM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> > On Fri, Nov 05, 2010 at 02:29:46PM +0200, Baruch Siach wrote:
> >> Hi Sascha,
> >>
> >> On Fri, Nov 05, 2010 at 01:18:00PM +0100, Sascha Hauer wrote:
> >> > We are talking about a single kernel for longer now, here is something
> >> > to test for the ones interested:
> >> >
> >> > git://git.pengutronix.de/git/imx/linux-2.6.git imx-single-kernel
> >> >
> >> > Compiling the imx_defconfig will result in a kernel which works
> >> > i.MX21, i.MX27, i.MX31, i.MX35 and i.MX51 (not tested on i.MX21).
> >> > i.MX1 does not work mainly because the kernel build will use some ARMv5
> >> > and later instructions.
> >>
> >> What is blocking i.MX25 from being included?
> >
> > It is. I just forgot to mention.
> 
> Hrm... the imx series is placing all header files in
> arch/arm/plat-mxc/include/plat
> instead of within each mach-*. Most other sub-arch doesn't behave like that at
> this moment and getting them built together ain't easy.

Indeed I had to move back one header file under mach-imx/include/mach
back to plat-mxc/include/mach.

> 
> BTW, did you get it tested on different boards, I'd be interested to see what
> could be the potential issues at run-time.

I only booted up a root nfs on different boards and was happy that it
worked so far. I have no experience with kernels supporting v5/v6/v7 in
a single binary. Has anybody tried this before? At least the defconfigs
don't show an example for this.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Single binary kernel for all i.MX

[Shawn Guo]

Hi Sascha,

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*?

Thanks.


On Fri, Nov 5, 2010 at 8:18 PM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> Hi all,
>
> We are talking about a single kernel for longer now, here is something
> to test for the ones interested:
>
> git://git.pengutronix.de/git/imx/linux-2.6.git imx-single-kernel
>
> Compiling the imx_defconfig will result in a kernel which works
> i.MX21, i.MX27, i.MX31, i.MX35 and i.MX51 (not tested on i.MX21).
> i.MX1 does not work mainly because the kernel build will use some ARMv5
> and later instructions.
> The branch is based on the patches recently posted. It contains some
> hacks, so it still needs to be worked on.
>
> Sascha
>
> --
> Pengutronix e.K. ? ? ? ? ? ? ? ? ? ? ? ? ? | ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> Industrial Linux Solutions ? ? ? ? ? ? ? ? | http://www.pengutronix.de/ ?|
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 ? ?|
> Amtsgericht Hildesheim, HRA 2686 ? ? ? ? ? | Fax: ? +49-5121-206917-5555 |
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>



-- 
Regards,
Shawn

Single binary kernel for all i.MX

[Uwe Kleine-König]

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

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

Single binary kernel for all i.MX

[Gadiyar, Anand]

2010/11/12 Uwe Kleine-K?nig <u.kleine-koenig@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

- Anand

Single binary kernel for all i.MX

[Uwe Kleine-König]

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@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.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

Single binary kernel for all i.MX

[Nicolas Pitre]

On Fri, 12 Nov 2010, Gadiyar, Anand wrote:

> 2010/11/12 Uwe Kleine-K?nig <u.kleine-koenig@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.

Sure, but that mechanism is really too complicated for what is supposed 
to be a barebone debugging facility.  If you have it on OMAP and it has 
been debugged already then fine. I don't encourage others to necessarily 
do the same though.


Nicolas

Single binary kernel for all i.MX

[Nicolas Pitre]

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@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