Processing of command line mem=32M

Processing of command line mem=32M

[Raghunandan Dhongadi]

Hello All,

I have Linux kernel 2.6.14-7 for OMAP2430 SDP board. The SDP has 128MB
of SDRAM memory. I want to share the 128MB into 64MB for ARM core and
64MB for DSP core.
I am giving the kernel command line parameter "mem=64M" but with this
the boot process
stops at "Uncompressing Kernel".

But if I give a minimum of "mem=113M" it boots fine. Wanted to know
where does the processing of command line parameters happen and what
could be the issue ?

Warm Regards,
Raghu

RE: Processing of command line mem=32M

[Woodruff, Richard]

[-- Attachment #1: Type: text/plain, Size: 1339 bytes --]

That is an issue I've heard about a few times.  I looked at it a couple
of weeks back and generated an initial band aid patch which should work,
then a very large patch.  I expect it will take a little time for these
to make there way back onto the ftp site.  Give this a try...

Regards,
Richard W.

> -----Original Message-----
> From: linux-omap-open-source-bounces@linux.omap.com
[mailto:linux-omap-
> open-source-bounces@linux.omap.com] On Behalf Of Raghunandan Dhongadi
> Sent: Friday, January 12, 2007 5:07 AM
> To: linux-omap-open-source@linux.omap.com
> Subject: Processing of command line mem=32M
> 
> Hello All,
> 
> I have Linux kernel 2.6.14-7 for OMAP2430 SDP board. The SDP has 128MB
> of SDRAM memory. I want to share the 128MB into 64MB for ARM core and
> 64MB for DSP core.
> I am giving the kernel command line parameter "mem=64M" but with this
> the boot process
> stops at "Uncompressing Kernel".
> 
> But if I give a minimum of "mem=113M" it boots fine. Wanted to know
> where does the processing of command line parameters happen and what
> could be the issue ?
> 
> Warm Regards,
> Raghu
> _______________________________________________
> Linux-omap-open-source mailing list
> Linux-omap-open-source@linux.omap.com
> http://linux.omap.com/mailman/listinfo/linux-omap-open-source

[-- Attachment #2: fix.diff --]
[-- Type: application/octet-stream, Size: 2949 bytes --]

diff -purN 2.6_kernel/arch/arm/mm/blockops.c 2.6_kernel-fix/arch/arm/mm/blockops.c
--- 2.6_kernel/arch/arm/mm/blockops.c	2006-08-24 16:25:42.000000000 -0500
+++ 2.6_kernel-fix/arch/arm/mm/blockops.c	2006-12-12 09:33:51.000000000 -0600
@@ -68,7 +68,7 @@ blk_dma_inv_range_harvard(unsigned long 
 	"tst	r0, %0								\n\
 	mcrne	p15, 0, r0, c7, c10, 1		@ clean D line			\n\
 	tst	r1, %0								\n\
-	mcrne	p15, 0, r1, c7, c10, 1		@ clean D line			\n\
+	mcrne	p15, 0, r1, c7, c14, 1		@ clean & invalidate D line	\n\
 	sub	r1, r1, #1							\n\
 	.word	0xec401f06	@ mcrr	p15, 0, r1, r0, c6, 0	@ blocking	\n\
 	mov	r0, #0								\n\
@@ -87,7 +87,8 @@ static void __attribute__((naked))
 blk_dma_clean_range(unsigned long start, unsigned long end)
 {
 	asm(
-	".word	0xec401f0c	@ mcrr	p15, 0, r1, r0, c12, 0	@ blocking	\n\
+	"sub r1,r1,#1 \n\
+	.word	0xec401f0c	@ mcrr	p15, 0, r1, r0, c12, 0	@ blocking	\n\
 	mov	r0, #0								\n\
 	mcr	p15, 0, r0, c7, c10, 4		@ drain write buffer		\n\
 	mov	pc, lr");
@@ -102,7 +103,10 @@ static void __attribute__((naked))
 blk_dma_flush_range(unsigned long start, unsigned long end)
 {
 	asm(
-	".word	0xec401f0e	@ mcrr	p15, 0, r1, r0, c14, 0	@ blocking	\n\
+	"sub	r1, r1, #1	\n\
+	.word	0xec401f0e	@ mcrr	p15, 0, r1, r0, c14, 0	@ blocking	\n\
+	mov	r0, #0								\n\
+	mcr	p15, 0, r0, c7, c10, 4		@ drain write buffer		\n\
 	mov	pc, lr");
 }
 
diff -purN 2.6_kernel/arch/arm/mm/proc-v6.S 2.6_kernel-fix/arch/arm/mm/proc-v6.S
--- 2.6_kernel/arch/arm/mm/proc-v6.S	2006-08-24 16:26:04.000000000 -0500
+++ 2.6_kernel-fix/arch/arm/mm/proc-v6.S	2006-12-11 15:34:14.000000000 -0600
@@ -209,11 +209,19 @@ __v6_setup:
 	orr	r0, r0, #(0xf << 20)
 	mcr	p15, 0, r0, c1, c0, 2		@ Enable full access to VFP
 #endif
+	ldr	r5, =0x4107b360			@ id for ARM1136 r0pX
+	mrc	p15, 0, r0, c0, c0, 0		@ get processor id
+	bic	r0, r0, #0xf			@ mask out part bits [3:0]
+	teq	r0, r5				@ check for the faulty core
+	mrceq	p15, 0, r0, c1, c0, 1		@ load aux control reg
+	orreq	r0, r0, #0x80000000		@ set bit 31
+	mcreq	p15, 0, r0, c1, c0, 1		@ write aux control reg
 	mrc	p15, 0, r0, c1, c0, 0		@ read control register
 	ldr	r5, v6_cr1_clear		@ get mask for bits to clear
 	bic	r0, r0, r5			@ clear bits them
 	ldr	r5, v6_cr1_set			@ get mask for bits to set
 	orr	r0, r0, r5			@ set them
+	orreq	r0, r0, #0x00200000		@ set the FI bit
 	mov	pc, lr				@ return to head.S:__ret
 
 	/*
diff -purN 2.6_kernel/include/asm-arm/tlbflush.h 2.6_kernel-fix/include/asm-arm/tlbflush.h
--- 2.6_kernel/include/asm-arm/tlbflush.h	2006-01-31 00:52:07.000000000 -0600
+++ 2.6_kernel-fix/include/asm-arm/tlbflush.h	2006-12-12 09:42:36.000000000 -0600
@@ -340,6 +340,8 @@ static inline void local_flush_tlb_kerne
 		asm("mcr%? p15, 0, %0, c8, c6, 1" : : "r" (kaddr));
 	if (tlb_flag(TLB_V6_I_PAGE))
 		asm("mcr%? p15, 0, %0, c8, c5, 1" : : "r" (kaddr));
+
+	asm("mcr p15, 0, %0, c7, c10, 4" :: "r" (zero)); /* fix 2.6.16 - barrier to ensure completion */
 }
 
 /*

[-- Attachment #3: Type: text/plain, Size: 0 bytes --]

Re: Processing of command line mem=32M

[Luís Vitório Cargnini]

It looks simple, allocate all memory normally to ARM during boot, in
execution time make an MMAP in DSPGateway in 64 Mb, and that is, a 64 Mb of
area to DSP, that could be accessed by ARM too.

On 1/12/07, Raghunandan Dhongadi <dk.raghu@gmail.com> wrote:
>
> Hello All,
>
> I have Linux kernel 2.6.14-7 for OMAP2430 SDP board. The SDP has 128MB
> of SDRAM memory. I want to share the 128MB into 64MB for ARM core and
> 64MB for DSP core.
> I am giving the kernel command line parameter "mem=64M" but with this
> the boot process
> stops at "Uncompressing Kernel".
>
> But if I give a minimum of "mem=113M" it boots fine. Wanted to know
> where does the processing of command line parameters happen and what
> could be the issue ?
>
> Warm Regards,
> Raghu
> _______________________________________________
> Linux-omap-open-source mailing list
> Linux-omap-open-source@linux.omap.com
> http://linux.omap.com/mailman/listinfo/linux-omap-open-source
>



-- 
------------------------------------------------------------------------------
Thanks && Regards
Msc. Bsc. Luís Vitório Cargnini
IEEE Member
Mastering Degree student @ PUC-RS
Electrical Engineer Faculty
Ipiranga Avenue, 6681 – Building 30
P.O. Box: 90619-900 – Porto Alegre/RS
Phone: +55 51 3320 3500  extension: 7696
---------------------------------------------------------------------------------

RE: Processing of command line mem=32M

[Woodruff, Richard]

Yes, what you said is true but not his point.

If he gives the command argument mem=xyz the system does not boot.  This is because of an off by one in a call to an mcr which generates a fatal error.

Regards,
Richard W.

> It looks simple, allocate all memory normally to ARM during boot, in
> execution time make an MMAP in DSPGateway in 64 Mb, and that is, a 64 Mb
> of
> area to DSP, that could be accessed by ARM too.
> 
> On 1/12/07, Raghunandan Dhongadi <dk.raghu@gmail.com> wrote:
> >
> > Hello All,
> >
> > I have Linux kernel 2.6.14-7 for OMAP2430 SDP board. The SDP has 128MB
> > of SDRAM memory. I want to share the 128MB into 64MB for ARM core and
> > 64MB for DSP core.
> > I am giving the kernel command line parameter "mem=64M" but with this
> > the boot process
> > stops at "Uncompressing Kernel".
> >
> > But if I give a minimum of "mem=113M" it boots fine. Wanted to know
> > where does the processing of command line parameters happen and what
> > could be the issue ?
> >
> > Warm Regards,
> > Raghu
> > _______________________________________________
> > Linux-omap-open-source mailing list
> > Linux-omap-open-source@linux.omap.com
> > http://linux.omap.com/mailman/listinfo/linux-omap-open-source
> >
> 
> 
> 
> --
> --------------------------------------------------------------------------
> ----
> Thanks && Regards
> Msc. Bsc. Luís Vitório Cargnini
> IEEE Member
> Mastering Degree student @ PUC-RS
> Electrical Engineer Faculty
> Ipiranga Avenue, 6681 - Building 30
> P.O. Box: 90619-900 - Porto Alegre/RS
> Phone: +55 51 3320 3500  extension: 7696
> --------------------------------------------------------------------------
> -------
> _______________________________________________
> Linux-omap-open-source mailing list
> Linux-omap-open-source@linux.omap.com
> http://linux.omap.com/mailman/listinfo/linux-omap-open-source