* Single binary kernel for all i.MX @ 2010-11-05 12:18 Sascha Hauer 2010-11-05 12:29 ` Baruch Siach 2010-11-12 15:40 ` Shawn Guo 0 siblings, 2 replies; 11+ messages in thread From: Sascha Hauer @ 2010-11-05 12:18 UTC (permalink / raw) To: linux-arm-kernel 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 | ^ permalink raw reply [flat|nested] 11+ messages in thread
* Single binary kernel for all i.MX 2010-11-05 12:18 Single binary kernel for all i.MX Sascha Hauer @ 2010-11-05 12:29 ` Baruch Siach 2010-11-05 12:31 ` Sascha Hauer 2010-11-12 15:40 ` Shawn Guo 1 sibling, 1 reply; 11+ messages in thread From: Baruch Siach @ 2010-11-05 12:29 UTC (permalink / raw) To: linux-arm-kernel 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 - ^ permalink raw reply [flat|nested] 11+ messages in thread
* Single binary kernel for all i.MX 2010-11-05 12:29 ` Baruch Siach @ 2010-11-05 12:31 ` Sascha Hauer 2010-11-05 18:59 ` Eric Miao 0 siblings, 1 reply; 11+ messages in thread From: Sascha Hauer @ 2010-11-05 12:31 UTC (permalink / raw) To: linux-arm-kernel 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 | ^ permalink raw reply [flat|nested] 11+ messages in thread
* Single binary kernel for all i.MX 2010-11-05 12:31 ` Sascha Hauer @ 2010-11-05 18:59 ` Eric Miao 2010-11-07 11:34 ` Sascha Hauer 0 siblings, 1 reply; 11+ messages in thread From: Eric Miao @ 2010-11-05 18:59 UTC (permalink / raw) To: linux-arm-kernel 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 > ^ permalink raw reply [flat|nested] 11+ messages in thread
* Single binary kernel for all i.MX 2010-11-05 18:59 ` Eric Miao @ 2010-11-07 11:34 ` Sascha Hauer 0 siblings, 0 replies; 11+ messages in thread From: Sascha Hauer @ 2010-11-07 11:34 UTC (permalink / raw) To: linux-arm-kernel 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 | ^ permalink raw reply [flat|nested] 11+ messages in thread
* Single binary kernel for all i.MX 2010-11-05 12:18 Single binary kernel for all i.MX Sascha Hauer 2010-11-05 12:29 ` Baruch Siach @ 2010-11-12 15:40 ` Shawn Guo 2010-11-12 15:53 ` Uwe Kleine-König 1 sibling, 1 reply; 11+ messages in thread From: Shawn Guo @ 2010-11-12 15:40 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Single binary kernel for all i.MX 2010-11-12 15:40 ` Shawn Guo @ 2010-11-12 15:53 ` Uwe Kleine-König 2010-11-12 17:29 ` Gadiyar, Anand 0 siblings, 1 reply; 11+ messages in thread From: Uwe Kleine-König @ 2010-11-12 15:53 UTC (permalink / raw) To: linux-arm-kernel 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/ | ^ permalink raw reply [flat|nested] 11+ messages in thread
* Single binary kernel for all i.MX 2010-11-12 15:53 ` Uwe Kleine-König @ 2010-11-12 17:29 ` Gadiyar, Anand 2010-11-12 18:50 ` Uwe Kleine-König 2010-11-13 15:26 ` Nicolas Pitre 0 siblings, 2 replies; 11+ messages in thread From: Gadiyar, Anand @ 2010-11-12 17:29 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Single binary kernel for all i.MX 2010-11-12 17:29 ` Gadiyar, Anand @ 2010-11-12 18:50 ` Uwe Kleine-König 2010-11-13 15:30 ` Nicolas Pitre 2010-11-13 15:26 ` Nicolas Pitre 1 sibling, 1 reply; 11+ messages in thread From: Uwe Kleine-König @ 2010-11-12 18:50 UTC (permalink / raw) To: linux-arm-kernel 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/ | ^ permalink raw reply [flat|nested] 11+ messages in thread
* Single binary kernel for all i.MX 2010-11-12 18:50 ` Uwe Kleine-König @ 2010-11-13 15:30 ` Nicolas Pitre 0 siblings, 0 replies; 11+ messages in thread From: Nicolas Pitre @ 2010-11-13 15:30 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Single binary kernel for all i.MX 2010-11-12 17:29 ` Gadiyar, Anand 2010-11-12 18:50 ` Uwe Kleine-König @ 2010-11-13 15:26 ` Nicolas Pitre 1 sibling, 0 replies; 11+ messages in thread From: Nicolas Pitre @ 2010-11-13 15:26 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2010-11-13 15:30 UTC | newest] Thread overview: 11+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2010-11-05 12:18 Single binary kernel for all i.MX Sascha Hauer 2010-11-05 12:29 ` Baruch Siach 2010-11-05 12:31 ` Sascha Hauer 2010-11-05 18:59 ` Eric Miao 2010-11-07 11:34 ` Sascha Hauer 2010-11-12 15:40 ` Shawn Guo 2010-11-12 15:53 ` Uwe Kleine-König 2010-11-12 17:29 ` Gadiyar, Anand 2010-11-12 18:50 ` Uwe Kleine-König 2010-11-13 15:30 ` Nicolas Pitre 2010-11-13 15:26 ` Nicolas Pitre
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).