linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [RFC] arm: Defer lookup of machine_type and vet of atags to setup.c
@ 2011-01-11  2:15 Grant Likely
  2011-01-11  3:19 ` Nicolas Pitre
  2011-01-11 10:40 ` Russell King - ARM Linux
  0 siblings, 2 replies; 15+ messages in thread
From: Grant Likely @ 2011-01-11  2:15 UTC (permalink / raw)
  To: Russell King, linux-kernel, linux-arm-kernel
  Cc: Catalin Marinas, Jeremy Kerr, Nicolas Pitre

Since the debug macros no longer depend on the machine type
information, both the machine type lookup and the atags vetting can be
deferred to setup_arch() in setup.c which simplifies the code
somewhat.

This patch removes both __machine_type_lookup and __vet_atags() from
head.S.  The atags vetting is moved to setup_arch().  machine_type
lookup is already called from setup_machine() in addition to where it
was called from head.S.

I've tried to preserve the existing behaviour in this patch so the
extra atags vetting is only using when CONFIG_MMU is selected.  I may
be being overly cautious, and if so then it is probably possible to
simplify the code further.

Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---

Hi Russell,

I'm not sure if this is a valid change or not, but from what I can
tell it looks like machine and atag processing no longer needs
to be handled as early as head.S.  Please take a look and let me know
what you think.

I've boot tested this on Tegra and versatile qemu, but that's about
it.

Thanks,
g.

 arch/arm/kernel/head-common.S |   35 -----------------------------------
 arch/arm/kernel/head.S        |    5 -----
 arch/arm/kernel/setup.c       |   16 ++++++++++++++++
 3 files changed, 16 insertions(+), 40 deletions(-)

diff --git a/arch/arm/kernel/head-common.S b/arch/arm/kernel/head-common.S
index bbecaac..7956a48 100644
--- a/arch/arm/kernel/head-common.S
+++ b/arch/arm/kernel/head-common.S
@@ -11,10 +11,6 @@
  *
  */
 
-#define ATAG_CORE 0x54410001
-#define ATAG_CORE_SIZE ((2*4 + 3*4) >> 2)
-#define ATAG_CORE_SIZE_EMPTY ((2*4) >> 2)
-
 /*
  * Exception handling.  Something went wrong and we can't proceed.  We
  * ought to tell the user, but since we don't have any guarantee that
@@ -101,37 +97,6 @@ __lookup_machine_type_data:
 	.long	__arch_info_end
 	.size	__lookup_machine_type_data, . - __lookup_machine_type_data
 
-/* Determine validity of the r2 atags pointer.  The heuristic requires
- * that the pointer be aligned, in the first 16k of physical RAM and
- * that the ATAG_CORE marker is first and present.  Future revisions
- * of this function may be more lenient with the physical address and
- * may also be able to move the ATAGS block if necessary.
- *
- * r8  = machinfo
- *
- * Returns:
- *  r2 either valid atags pointer, or zero
- *  r5, r6 corrupted
- */
-__vet_atags:
-	tst	r2, #0x3			@ aligned?
-	bne	1f
-
-	ldr	r5, [r2, #0]			@ is first tag ATAG_CORE?
-	cmp	r5, #ATAG_CORE_SIZE
-	cmpne	r5, #ATAG_CORE_SIZE_EMPTY
-	bne	1f
-	ldr	r5, [r2, #4]
-	ldr	r6, =ATAG_CORE
-	cmp	r5, r6
-	bne	1f
-
-	mov	pc, lr				@ atag pointer is ok
-
-1:	mov	r2, #0
-	mov	pc, lr
-ENDPROC(__vet_atags)
-
 /*
  * The following fragment of code is executed with the MMU on in MMU mode,
  * and uses absolute addresses; this is not position independent.
diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S
index 6bd82d2..9c0e938 100644
--- a/arch/arm/kernel/head.S
+++ b/arch/arm/kernel/head.S
@@ -87,11 +87,6 @@ ENTRY(stext)
 	movs	r10, r5				@ invalid processor (r5=0)?
  THUMB( it	eq )		@ force fixup-able long branch encoding
 	beq	__error_p			@ yes, error 'p'
-	bl	__lookup_machine_type		@ r5=machinfo
-	movs	r8, r5				@ invalid machine (r5=0)?
- THUMB( it	eq )		@ force fixup-able long branch encoding
-	beq	__error_a			@ yes, error 'a'
-	bl	__vet_atags
 #ifdef CONFIG_SMP_ON_UP
 	bl	__fixup_smp
 #endif
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 336f14e..cd28089 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -814,6 +814,22 @@ void __init setup_arch(char **cmdline_p)
 	if (mdesc->soft_reboot)
 		reboot_setup("s");
 
+#if defined(CONFIG_MMU)
+	/*
+	 * Determine validity of the atags pointer.  The heuristic requires
+	 * that the pointer be aligned, and that the ATAG_CORE marker is
+	 * first and present.
+	 */
+	if (__atags_pointer & 0x3)
+		__atags_pointer = 0;
+	if (__atags_pointer) {
+		struct tag *t = phys_to_virt(__atags_pointer);
+		if ((t->hdr.size != tag_size(tag_core)) &&
+		    (t->hdr.size != sizeof(struct tag_header)) &&
+		    (t->hdr.tag != ATAG_CORE))
+			__atags_pointer = 0;
+	}
+#endif
 	if (__atags_pointer)
 		tags = phys_to_virt(__atags_pointer);
 	else if (mdesc->boot_params)


^ permalink raw reply related	[flat|nested] 15+ messages in thread

* Re: [RFC] arm: Defer lookup of machine_type and vet of atags to setup.c
  2011-01-11  2:15 [RFC] arm: Defer lookup of machine_type and vet of atags to setup.c Grant Likely
@ 2011-01-11  3:19 ` Nicolas Pitre
  2011-01-11  5:21   ` Grant Likely
  2011-01-11 10:40 ` Russell King - ARM Linux
  1 sibling, 1 reply; 15+ messages in thread
From: Nicolas Pitre @ 2011-01-11  3:19 UTC (permalink / raw)
  To: Grant Likely
  Cc: Russell King, linux-kernel, linux-arm-kernel, Catalin Marinas,
	Jeremy Kerr

On Mon, 10 Jan 2011, Grant Likely wrote:

> Since the debug macros no longer depend on the machine type
> information, both the machine type lookup and the atags vetting can be
> deferred to setup_arch() in setup.c which simplifies the code
> somewhat.
> 
> This patch removes both __machine_type_lookup and __vet_atags() from
> head.S.  The atags vetting is moved to setup_arch().  machine_type
> lookup is already called from setup_machine() in addition to where it
> was called from head.S.

While at it, you could also remove the code for __lookup_machine_type, 
lookup_machine_type and __error_a, replacing that with a C 
implementation living in setup.c instead.  If this code is not called 
from head.S anymore, there is no reason to keep it there any longer.


Nicolas

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [RFC] arm: Defer lookup of machine_type and vet of atags to setup.c
  2011-01-11  3:19 ` Nicolas Pitre
@ 2011-01-11  5:21   ` Grant Likely
  0 siblings, 0 replies; 15+ messages in thread
From: Grant Likely @ 2011-01-11  5:21 UTC (permalink / raw)
  To: Nicolas Pitre
  Cc: Russell King, linux-kernel, linux-arm-kernel, Catalin Marinas,
	Jeremy Kerr

On Mon, Jan 10, 2011 at 8:19 PM, Nicolas Pitre <nico@fluxnic.net> wrote:
> On Mon, 10 Jan 2011, Grant Likely wrote:
>
>> Since the debug macros no longer depend on the machine type
>> information, both the machine type lookup and the atags vetting can be
>> deferred to setup_arch() in setup.c which simplifies the code
>> somewhat.
>>
>> This patch removes both __machine_type_lookup and __vet_atags() from
>> head.S.  The atags vetting is moved to setup_arch().  machine_type
>> lookup is already called from setup_machine() in addition to where it
>> was called from head.S.
>
> While at it, you could also remove the code for __lookup_machine_type,
> lookup_machine_type and __error_a, replacing that with a C
> implementation living in setup.c instead.  If this code is not called
> from head.S anymore, there is no reason to keep it there any longer.

Certainly.  I'll draft that up as a separate patch and post it tomorrow.

g.

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [RFC] arm: Defer lookup of machine_type and vet of atags to setup.c
  2011-01-11  2:15 [RFC] arm: Defer lookup of machine_type and vet of atags to setup.c Grant Likely
  2011-01-11  3:19 ` Nicolas Pitre
@ 2011-01-11 10:40 ` Russell King - ARM Linux
  2011-01-11 15:36   ` Grant Likely
  1 sibling, 1 reply; 15+ messages in thread
From: Russell King - ARM Linux @ 2011-01-11 10:40 UTC (permalink / raw)
  To: Grant Likely
  Cc: linux-kernel, linux-arm-kernel, Catalin Marinas, Jeremy Kerr,
	Nicolas Pitre

On Mon, Jan 10, 2011 at 07:15:53PM -0700, Grant Likely wrote:
> diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S
> index 6bd82d2..9c0e938 100644
> --- a/arch/arm/kernel/head.S
> +++ b/arch/arm/kernel/head.S
> @@ -87,11 +87,6 @@ ENTRY(stext)
>  	movs	r10, r5				@ invalid processor (r5=0)?
>   THUMB( it	eq )		@ force fixup-able long branch encoding
>  	beq	__error_p			@ yes, error 'p'
> -	bl	__lookup_machine_type		@ r5=machinfo
> -	movs	r8, r5				@ invalid machine (r5=0)?
> - THUMB( it	eq )		@ force fixup-able long branch encoding
> -	beq	__error_a			@ yes, error 'a'
> -	bl	__vet_atags
>  #ifdef CONFIG_SMP_ON_UP
>  	bl	__fixup_smp
>  #endif

Don't forget to update the comments as well - there's two of them.

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [RFC] arm: Defer lookup of machine_type and vet of atags to setup.c
  2011-01-11 10:40 ` Russell King - ARM Linux
@ 2011-01-11 15:36   ` Grant Likely
  2011-01-11 15:48     ` Russell King - ARM Linux
  0 siblings, 1 reply; 15+ messages in thread
From: Grant Likely @ 2011-01-11 15:36 UTC (permalink / raw)
  To: Russell King - ARM Linux
  Cc: linux-kernel, linux-arm-kernel, Catalin Marinas, Jeremy Kerr,
	Nicolas Pitre

On Tue, Jan 11, 2011 at 10:40:51AM +0000, Russell King - ARM Linux wrote:
> On Mon, Jan 10, 2011 at 07:15:53PM -0700, Grant Likely wrote:
> > diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S
> > index 6bd82d2..9c0e938 100644
> > --- a/arch/arm/kernel/head.S
> > +++ b/arch/arm/kernel/head.S
> > @@ -87,11 +87,6 @@ ENTRY(stext)
> >  	movs	r10, r5				@ invalid processor (r5=0)?
> >   THUMB( it	eq )		@ force fixup-able long branch encoding
> >  	beq	__error_p			@ yes, error 'p'
> > -	bl	__lookup_machine_type		@ r5=machinfo
> > -	movs	r8, r5				@ invalid machine (r5=0)?
> > - THUMB( it	eq )		@ force fixup-able long branch encoding
> > -	beq	__error_a			@ yes, error 'a'
> > -	bl	__vet_atags
> >  #ifdef CONFIG_SMP_ON_UP
> >  	bl	__fixup_smp
> >  #endif
> 
> Don't forget to update the comments as well - there's two of them.

I'm not entirely clear on what you're referring to here.  Are you
talking about the secondary cpu entry point?  I've fixed up that
comment now as well as a s/__lookup_machine_type/__lookup_processor_type/
typo right before the call to __enable_mmu.

I've also removed the machine type lookup from head-nommu.S and I'll
repost the patch later today.

Thanks for the review,
g.


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [RFC] arm: Defer lookup of machine_type and vet of atags to setup.c
  2011-01-11 15:36   ` Grant Likely
@ 2011-01-11 15:48     ` Russell King - ARM Linux
  2011-01-12 15:46       ` Grant Likely
  0 siblings, 1 reply; 15+ messages in thread
From: Russell King - ARM Linux @ 2011-01-11 15:48 UTC (permalink / raw)
  To: Grant Likely
  Cc: linux-kernel, linux-arm-kernel, Catalin Marinas, Jeremy Kerr,
	Nicolas Pitre

On Tue, Jan 11, 2011 at 08:36:30AM -0700, Grant Likely wrote:
> On Tue, Jan 11, 2011 at 10:40:51AM +0000, Russell King - ARM Linux wrote:
> > On Mon, Jan 10, 2011 at 07:15:53PM -0700, Grant Likely wrote:
> > > diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S
> > > index 6bd82d2..9c0e938 100644
> > > --- a/arch/arm/kernel/head.S
> > > +++ b/arch/arm/kernel/head.S
> > > @@ -87,11 +87,6 @@ ENTRY(stext)
> > >  	movs	r10, r5				@ invalid processor (r5=0)?
> > >   THUMB( it	eq )		@ force fixup-able long branch encoding
> > >  	beq	__error_p			@ yes, error 'p'
> > > -	bl	__lookup_machine_type		@ r5=machinfo
> > > -	movs	r8, r5				@ invalid machine (r5=0)?
> > > - THUMB( it	eq )		@ force fixup-able long branch encoding
> > > -	beq	__error_a			@ yes, error 'a'
> > > -	bl	__vet_atags
> > >  #ifdef CONFIG_SMP_ON_UP
> > >  	bl	__fixup_smp
> > >  #endif
> > 
> > Don't forget to update the comments as well - there's two of them.
> 
> I'm not entirely clear on what you're referring to here.  Are you
> talking about the secondary cpu entry point?  I've fixed up that
> comment now as well as a s/__lookup_machine_type/__lookup_processor_type/
> typo right before the call to __enable_mmu.

In the above code, __lookup_machine_type is called, which to be
consistent with __lookup_processor_type, returns its value in r5.  This
is then copied to r8, which is the only point that r8 is initialized.

The remainder of the code used to make use of r8 to load various fields
from the machine record, and so there's a couple of comments indicating
that this is the case.  These comments are left behind after your patch
and so are misleading.

Shall I assume that you've already searched the head*.S files to make
sure that r8 isn't used before you removed its initialization? ;-)

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [RFC] arm: Defer lookup of machine_type and vet of atags to setup.c
  2011-01-11 15:48     ` Russell King - ARM Linux
@ 2011-01-12 15:46       ` Grant Likely
  2011-01-12 15:52         ` Russell King - ARM Linux
  0 siblings, 1 reply; 15+ messages in thread
From: Grant Likely @ 2011-01-12 15:46 UTC (permalink / raw)
  To: Russell King - ARM Linux
  Cc: linux-kernel, linux-arm-kernel, Catalin Marinas, Jeremy Kerr,
	Nicolas Pitre

On Tue, Jan 11, 2011 at 8:48 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Tue, Jan 11, 2011 at 08:36:30AM -0700, Grant Likely wrote:
>> On Tue, Jan 11, 2011 at 10:40:51AM +0000, Russell King - ARM Linux wrote:
>> > On Mon, Jan 10, 2011 at 07:15:53PM -0700, Grant Likely wrote:
>> > > diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S
>> > > index 6bd82d2..9c0e938 100644
>> > > --- a/arch/arm/kernel/head.S
>> > > +++ b/arch/arm/kernel/head.S
>> > > @@ -87,11 +87,6 @@ ENTRY(stext)
>> > >   movs    r10, r5                         @ invalid processor (r5=0)?
>> > >   THUMB( it       eq )            @ force fixup-able long branch encoding
>> > >   beq     __error_p                       @ yes, error 'p'
>> > > - bl      __lookup_machine_type           @ r5=machinfo
>> > > - movs    r8, r5                          @ invalid machine (r5=0)?
>> > > - THUMB( it       eq )            @ force fixup-able long branch encoding
>> > > - beq     __error_a                       @ yes, error 'a'
>> > > - bl      __vet_atags
>> > >  #ifdef CONFIG_SMP_ON_UP
>> > >   bl      __fixup_smp
>> > >  #endif
>> >
>> > Don't forget to update the comments as well - there's two of them.
>>
>> I'm not entirely clear on what you're referring to here.  Are you
>> talking about the secondary cpu entry point?  I've fixed up that
>> comment now as well as a s/__lookup_machine_type/__lookup_processor_type/
>> typo right before the call to __enable_mmu.
>
> In the above code, __lookup_machine_type is called, which to be
> consistent with __lookup_processor_type, returns its value in r5.  This
> is then copied to r8, which is the only point that r8 is initialized.
>
> The remainder of the code used to make use of r8 to load various fields
> from the machine record, and so there's a couple of comments indicating
> that this is the case.  These comments are left behind after your patch
> and so are misleading.

Ah, right.  I'll clean those up.

> Shall I assume that you've already searched the head*.S files to make
> sure that r8 isn't used before you removed its initialization? ;-)

Yup!

Looks like I've hit a hiccup though.  When I remove the first call to
__lookup_machine_type, then it is only called after the MMU is turned
on and the kernel is no longer able to output the list of configured
machine ids when it doesn't recognize the value in r1 (tested with
qemu versatile emulation).  I'm still investigating, so I'll defer
reposting the patch until I've got this issue solved.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [RFC] arm: Defer lookup of machine_type and vet of atags to setup.c
  2011-01-12 15:46       ` Grant Likely
@ 2011-01-12 15:52         ` Russell King - ARM Linux
  2011-01-12 16:24           ` Grant Likely
  0 siblings, 1 reply; 15+ messages in thread
From: Russell King - ARM Linux @ 2011-01-12 15:52 UTC (permalink / raw)
  To: Grant Likely
  Cc: linux-kernel, linux-arm-kernel, Catalin Marinas, Jeremy Kerr,
	Nicolas Pitre

On Wed, Jan 12, 2011 at 08:46:44AM -0700, Grant Likely wrote:
> Looks like I've hit a hiccup though.  When I remove the first call to
> __lookup_machine_type, then it is only called after the MMU is turned
> on and the kernel is no longer able to output the list of configured
> machine ids when it doesn't recognize the value in r1 (tested with
> qemu versatile emulation).  I'm still investigating, so I'll defer
> reposting the patch until I've got this issue solved.

It only does this when DEBUG_LL is enabled - at which point you have
printascii, printhex8, etc available (although there's no prototype
for them.)

You could use snprintf() to format a message and then use printascii()
(conditional on CONFIG_DEBUG_LL as the existing code does) as well as
printk("%s", buffer).  That means if you have a debugger you can dump
the kernel ring buffer and see the message, or see it via the serial
port/debugging channel if DEBUG_LL is enabled.

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [RFC] arm: Defer lookup of machine_type and vet of atags to setup.c
  2011-01-12 15:52         ` Russell King - ARM Linux
@ 2011-01-12 16:24           ` Grant Likely
  2011-01-12 16:32             ` Russell King - ARM Linux
  2011-01-12 16:53             ` Nicolas Pitre
  0 siblings, 2 replies; 15+ messages in thread
From: Grant Likely @ 2011-01-12 16:24 UTC (permalink / raw)
  To: Russell King - ARM Linux
  Cc: linux-kernel, linux-arm-kernel, Catalin Marinas, Jeremy Kerr,
	Nicolas Pitre

On Wed, Jan 12, 2011 at 8:52 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Wed, Jan 12, 2011 at 08:46:44AM -0700, Grant Likely wrote:
>> Looks like I've hit a hiccup though.  When I remove the first call to
>> __lookup_machine_type, then it is only called after the MMU is turned
>> on and the kernel is no longer able to output the list of configured
>> machine ids when it doesn't recognize the value in r1 (tested with
>> qemu versatile emulation).  I'm still investigating, so I'll defer
>> reposting the patch until I've got this issue solved.
>
> It only does this when DEBUG_LL is enabled - at which point you have
> printascii, printhex8, etc available (although there's no prototype
> for them.)
>
> You could use snprintf() to format a message and then use printascii()
> (conditional on CONFIG_DEBUG_LL as the existing code does) as well as
> printk("%s", buffer).  That means if you have a debugger you can dump
> the kernel ring buffer and see the message, or see it via the serial
> port/debugging channel if DEBUG_LL is enabled.

Actually it looks like the real problem is that the mmu has been
turned on, but the virtual mappings for devices have not yet been
established, and so the debug macros aren't using a valid address.
I'm using printk to get output into the ring buffer in my patch to
rework lookup_machine_type() in C, and that does indeed output to the
ring buffer, but the kernel cannot spit stuff out the serial port.

It looks like I'd need to get past paging_init() in order to get
ll_debug working between turning on the mmu and paging_init(), but
paging_init() needs the mdesc pointer, and the whole point of the
error message is that the mdesc pointer is unknown!  I don't see any
code that sets up a debug mapping of the uart before paging_init time.
 I could try to implement something like that, but it is looking to be
more complicated than it is worth when the current code works just
fine.

Let me know if I've missed something, but I think I should drop the
removal of __lookup_machine_type from head.S from my patch.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [RFC] arm: Defer lookup of machine_type and vet of atags to setup.c
  2011-01-12 16:24           ` Grant Likely
@ 2011-01-12 16:32             ` Russell King - ARM Linux
  2011-01-12 16:53             ` Nicolas Pitre
  1 sibling, 0 replies; 15+ messages in thread
From: Russell King - ARM Linux @ 2011-01-12 16:32 UTC (permalink / raw)
  To: Grant Likely
  Cc: linux-kernel, linux-arm-kernel, Catalin Marinas, Jeremy Kerr,
	Nicolas Pitre

On Wed, Jan 12, 2011 at 09:24:34AM -0700, Grant Likely wrote:
> Actually it looks like the real problem is that the mmu has been
> turned on, but the virtual mappings for devices have not yet been
> established, and so the debug macros aren't using a valid address.

They should be, as they're valid for use from assembly prior to MMU
turn-on, assembly after MMU turn-on and C code.

If CONFIG_DEBUG_LL is enabled, create_page_tables() should be setting
up the necessary initial mappings for printascii() to work.

Maybe the efforts to unify that stuff ended up breaking the printascii
debugging mechanism, and we now require a new debugging mechanism to
debug the printascii debugging mechanism... :-P

I've used it on Versatile Express during the last week and it did work
right from before setup_arch() was called.

> It looks like I'd need to get past paging_init() in order to get
> ll_debug working between turning on the mmu and paging_init(), but
> paging_init() needs the mdesc pointer, and the whole point of the
> error message is that the mdesc pointer is unknown!  I don't see any
> code that sets up a debug mapping of the uart before paging_init time.

See the #ifdef CONFIG_DEBUG_LL section in create_page_tables in head.S

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [RFC] arm: Defer lookup of machine_type and vet of atags to setup.c
  2011-01-12 16:24           ` Grant Likely
  2011-01-12 16:32             ` Russell King - ARM Linux
@ 2011-01-12 16:53             ` Nicolas Pitre
  2011-01-12 17:16               ` Grant Likely
  1 sibling, 1 reply; 15+ messages in thread
From: Nicolas Pitre @ 2011-01-12 16:53 UTC (permalink / raw)
  To: Grant Likely
  Cc: Russell King - ARM Linux, linux-kernel, linux-arm-kernel,
	Catalin Marinas, Jeremy Kerr

On Wed, 12 Jan 2011, Grant Likely wrote:

> Actually it looks like the real problem is that the mmu has been
> turned on, but the virtual mappings for devices have not yet been
> established, and so the debug macros aren't using a valid address.

A temporary virtual mapping should be there -- look for addruart in 
head.S.

> I'm using printk to get output into the ring buffer in my patch to
> rework lookup_machine_type() in C, and that does indeed output to the
> ring buffer, but the kernel cannot spit stuff out the serial port.
> 
> It looks like I'd need to get past paging_init() in order to get
> ll_debug working between turning on the mmu and paging_init(), but
> paging_init() needs the mdesc pointer, and the whole point of the
> error message is that the mdesc pointer is unknown!  I don't see any
> code that sets up a debug mapping of the uart before paging_init time.

See above.

>  I could try to implement something like that, but it is looking to be
> more complicated than it is worth when the current code works just
> fine.

My bet is that there is a bug with the current code that you are 
exposing.

> Let me know if I've missed something, but I think I should drop the
> removal of __lookup_machine_type from head.S from my patch.

It's not the location of that code which is a problem.  Even if you 
leave that code in place, you want to call it later and I bet that the 
display would be broken even if __lookup_machine_type doesn't move.


Nicolas

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [RFC] arm: Defer lookup of machine_type and vet of atags to setup.c
  2011-01-12 16:53             ` Nicolas Pitre
@ 2011-01-12 17:16               ` Grant Likely
  2011-01-12 17:25                 ` Russell King - ARM Linux
  0 siblings, 1 reply; 15+ messages in thread
From: Grant Likely @ 2011-01-12 17:16 UTC (permalink / raw)
  To: Nicolas Pitre
  Cc: Russell King - ARM Linux, linux-kernel, linux-arm-kernel,
	Catalin Marinas, Jeremy Kerr

On Wed, Jan 12, 2011 at 9:53 AM, Nicolas Pitre <nico@fluxnic.net> wrote:
> On Wed, 12 Jan 2011, Grant Likely wrote:
>
>> Actually it looks like the real problem is that the mmu has been
>> turned on, but the virtual mappings for devices have not yet been
>> established, and so the debug macros aren't using a valid address.
>
> A temporary virtual mapping should be there -- look for addruart in
> head.S.

Hi Russell and Nicolas,

Oops, yes all the early debug stuff works fine.  Stupid human trick on
my end, but I've sorted it out now.  Thanks for the help.  I'll have
patches to post later today.

g.

>
>> I'm using printk to get output into the ring buffer in my patch to
>> rework lookup_machine_type() in C, and that does indeed output to the
>> ring buffer, but the kernel cannot spit stuff out the serial port.
>>
>> It looks like I'd need to get past paging_init() in order to get
>> ll_debug working between turning on the mmu and paging_init(), but
>> paging_init() needs the mdesc pointer, and the whole point of the
>> error message is that the mdesc pointer is unknown!  I don't see any
>> code that sets up a debug mapping of the uart before paging_init time.
>
> See above.
>
>>  I could try to implement something like that, but it is looking to be
>> more complicated than it is worth when the current code works just
>> fine.
>
> My bet is that there is a bug with the current code that you are
> exposing.
>
>> Let me know if I've missed something, but I think I should drop the
>> removal of __lookup_machine_type from head.S from my patch.
>
> It's not the location of that code which is a problem.  Even if you
> leave that code in place, you want to call it later and I bet that the
> display would be broken even if __lookup_machine_type doesn't move.
>
>
> Nicolas
>



-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [RFC] arm: Defer lookup of machine_type and vet of atags to setup.c
  2011-01-12 17:16               ` Grant Likely
@ 2011-01-12 17:25                 ` Russell King - ARM Linux
  2011-01-12 17:49                   ` Grant Likely
  0 siblings, 1 reply; 15+ messages in thread
From: Russell King - ARM Linux @ 2011-01-12 17:25 UTC (permalink / raw)
  To: Grant Likely
  Cc: Nicolas Pitre, linux-kernel, linux-arm-kernel, Catalin Marinas,
	Jeremy Kerr

On Wed, Jan 12, 2011 at 10:16:44AM -0700, Grant Likely wrote:
> On Wed, Jan 12, 2011 at 9:53 AM, Nicolas Pitre <nico@fluxnic.net> wrote:
> > On Wed, 12 Jan 2011, Grant Likely wrote:
> >
> >> Actually it looks like the real problem is that the mmu has been
> >> turned on, but the virtual mappings for devices have not yet been
> >> established, and so the debug macros aren't using a valid address.
> >
> > A temporary virtual mapping should be there -- look for addruart in
> > head.S.
> 
> Hi Russell and Nicolas,
> 
> Oops, yes all the early debug stuff works fine.  Stupid human trick on
> my end, but I've sorted it out now.  Thanks for the help.  I'll have
> patches to post later today.

I just hacked this up, and on Versatile (real hardware) it produces
the below for an invalid r1 value - and of course works for a proper r1
value.

Uncompressing Linux... done, booting the kernel.

Error: unrecognized/unsupported machine ID (r1 = 0x00123456).

Available machine support:

ID (hex)        NAME
00000183        ARM-Versatile PB
0000025e        ARM-Versatile AB

Please check your kernel config and/or bootloader.

diff --git a/arch/arm/kernel/head-common.S b/arch/arm/kernel/head-common.S
index bbecaac..c84b57d 100644
--- a/arch/arm/kernel/head-common.S
+++ b/arch/arm/kernel/head-common.S
@@ -25,81 +25,6 @@
  * machine ID for example).
  */
 	__HEAD
-__error_a:
-#ifdef CONFIG_DEBUG_LL
-	mov	r4, r1				@ preserve machine ID
-	adr	r0, str_a1
-	bl	printascii
-	mov	r0, r4
-	bl	printhex8
-	adr	r0, str_a2
-	bl	printascii
-	adr	r3, __lookup_machine_type_data
-	ldmia	r3, {r4, r5, r6}		@ get machine desc list
-	sub	r4, r3, r4			@ get offset between virt&phys
-	add	r5, r5, r4			@ convert virt addresses to
-	add	r6, r6, r4			@ physical address space
-1:	ldr	r0, [r5, #MACHINFO_TYPE]	@ get machine type
-	bl	printhex8
-	mov	r0, #'\t'
-	bl	printch
-	ldr     r0, [r5, #MACHINFO_NAME]	@ get machine name
-	add	r0, r0, r4
-	bl	printascii
-	mov	r0, #'\n'
-	bl	printch
-	add	r5, r5, #SIZEOF_MACHINE_DESC	@ next machine_desc
-	cmp	r5, r6
-	blo	1b
-	adr	r0, str_a3
-	bl	printascii
-	b	__error
-ENDPROC(__error_a)
-
-str_a1:	.asciz	"\nError: unrecognized/unsupported machine ID (r1 = 0x"
-str_a2:	.asciz	").\n\nAvailable machine support:\n\nID (hex)\tNAME\n"
-str_a3:	.asciz	"\nPlease check your kernel config and/or bootloader.\n"
-	.align
-#endif
-
-/*
- * Lookup machine architecture in the linker-build list of architectures.
- * Note that we can't use the absolute addresses for the __arch_info
- * lists since we aren't running with the MMU on (and therefore, we are
- * not in the correct address space).  We have to calculate the offset.
- *
- *  r1 = machine architecture number
- * Returns:
- *  r3, r4, r6 corrupted
- *  r5 = mach_info pointer in physical address space
- */
-__lookup_machine_type:
-	adr	r3, __lookup_machine_type_data
-	ldmia	r3, {r4, r5, r6}
-	sub	r3, r3, r4			@ get offset between virt&phys
-	add	r5, r5, r3			@ convert virt addresses to
-	add	r6, r6, r3			@ physical address space
-1:	ldr	r3, [r5, #MACHINFO_TYPE]	@ get machine type
-	teq	r3, r1				@ matches loader number?
-	beq	2f				@ found
-	add	r5, r5, #SIZEOF_MACHINE_DESC	@ next machine_desc
-	cmp	r5, r6
-	blo	1b
-	mov	r5, #0				@ unknown machine
-2:	mov	pc, lr
-ENDPROC(__lookup_machine_type)
-
-/*
- * Look in arch/arm/kernel/arch.[ch] for information about the
- * __arch_info structures.
- */
-	.align	2
-	.type	__lookup_machine_type_data, %object
-__lookup_machine_type_data:
-	.long	.
-	.long	__arch_info_begin
-	.long	__arch_info_end
-	.size	__lookup_machine_type_data, . - __lookup_machine_type_data
 
 /* Determine validity of the r2 atags pointer.  The heuristic requires
  * that the pointer be aligned, in the first 16k of physical RAM and
@@ -107,8 +32,6 @@ __lookup_machine_type_data:
  * of this function may be more lenient with the physical address and
  * may also be able to move the ATAGS block if necessary.
  *
- * r8  = machinfo
- *
  * Returns:
  *  r2 either valid atags pointer, or zero
  *  r5, r6 corrupted
@@ -183,17 +106,6 @@ __mmap_switched_data:
 	.size	__mmap_switched_data, . - __mmap_switched_data
 
 /*
- * This provides a C-API version of __lookup_machine_type
- */
-ENTRY(lookup_machine_type)
-	stmfd	sp!, {r4 - r6, lr}
-	mov	r1, r0
-	bl	__lookup_machine_type
-	mov	r0, r5
-	ldmfd	sp!, {r4 - r6, pc}
-ENDPROC(lookup_machine_type)
-
-/*
  * This provides a C-API version of __lookup_processor_type
  */
 ENTRY(lookup_processor_type)
diff --git a/arch/arm/kernel/head-nommu.S b/arch/arm/kernel/head-nommu.S
index 814ce1a..6b1e0ad 100644
--- a/arch/arm/kernel/head-nommu.S
+++ b/arch/arm/kernel/head-nommu.S
@@ -44,9 +44,6 @@ ENTRY(stext)
 	bl	__lookup_processor_type		@ r5=procinfo r9=cpuid
 	movs	r10, r5				@ invalid processor (r5=0)?
 	beq	__error_p				@ yes, error 'p'
-	bl	__lookup_machine_type		@ r5=machinfo
-	movs	r8, r5				@ invalid machine (r5=0)?
-	beq	__error_a			@ yes, error 'a'
 
 	adr	lr, BSYM(__after_proc_init)	@ return (PIC) address
  ARM(	add	pc, r10, #PROCINFO_INITFUNC	)
diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S
index 06aed19..084db6c 100644
--- a/arch/arm/kernel/head.S
+++ b/arch/arm/kernel/head.S
@@ -87,14 +87,10 @@ ENTRY(stext)
 	movs	r10, r5				@ invalid processor (r5=0)?
  THUMB( it	eq )		@ force fixup-able long branch encoding
 	beq	__error_p			@ yes, error 'p'
-	bl	__lookup_machine_type		@ r5=machinfo
-	movs	r8, r5				@ invalid machine (r5=0)?
- THUMB( it	eq )		@ force fixup-able long branch encoding
-	beq	__error_a			@ yes, error 'a'
 
 	/*
 	 * r1 = machine no, r2 = atags,
-	 * r8 = machinfo, r9 = cpuid, r10 = procinfo
+	 * r9 = cpuid, r10 = procinfo
 	 */
 	bl	__vet_atags
 #ifdef CONFIG_SMP_ON_UP
@@ -108,7 +104,7 @@ ENTRY(stext)
 	/*
 	 * The following calls CPU specific code in a position independent
 	 * manner.  See arch/arm/mm/proc-*.S for details.  r10 = base of
-	 * xxx_proc_info structure selected by __lookup_machine_type
+	 * xxx_proc_info structure selected by __lookup_processor_type
 	 * above.  On return, the CPU will be ready for the MMU to be
 	 * turned on, and r0 will hold the CPU control register value.
 	 */
@@ -127,7 +123,6 @@ ENDPROC(stext)
  * amount which are required to get the kernel running, which
  * generally means mapping in the kernel code.
  *
- * r8  = machinfo
  * r9  = cpuid
  * r10 = procinfo
  *
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 7c5499d..eb952a7 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -308,7 +308,44 @@ static void __init cacheid_init(void)
  * already provide the required functionality.
  */
 extern struct proc_info_list *lookup_processor_type(unsigned int);
-extern struct machine_desc *lookup_machine_type(unsigned int);
+
+static void __init early_print(const char *str, ...)
+{
+	extern void printascii(const char *);
+	char buf[256];
+	va_list ap;
+
+	va_start(ap, str);
+	vsnprintf(buf, sizeof(buf), str, ap);
+	va_end(ap);
+
+#ifdef CONFIG_DEBUG_LL
+	printascii(buf);
+#endif
+	printk("%s", buf);
+}
+
+static struct machine_desc * __init lookup_machine_type(unsigned int type)
+{
+	extern struct machine_desc __arch_info_begin[], __arch_info_end[];
+	struct machine_desc *p;
+
+	for (p = __arch_info_begin; p < __arch_info_end; p++)
+		if (type == p->nr)
+			return p;
+
+	early_print("\n"
+		"Error: unrecognized/unsupported machine ID (r1 = 0x%08x).\n\n"
+		"Available machine support:\n\nID (hex)\tNAME\n", type);
+
+	for (p = __arch_info_begin; p < __arch_info_end; p++)
+		early_print("%08x\t%s\n", p->nr, p->name);
+
+	early_print("\nPlease check your kernel config and/or bootloader.\n");
+
+	while (true)
+		/* can't use cpu_relax() here as it may require MMU setup */;
+}
 
 static void __init feat_v6_fixup(void)
 {


^ permalink raw reply related	[flat|nested] 15+ messages in thread

* Re: [RFC] arm: Defer lookup of machine_type and vet of atags to setup.c
  2011-01-12 17:25                 ` Russell King - ARM Linux
@ 2011-01-12 17:49                   ` Grant Likely
  2011-02-07 15:55                     ` Tony Lindgren
  0 siblings, 1 reply; 15+ messages in thread
From: Grant Likely @ 2011-01-12 17:49 UTC (permalink / raw)
  To: Russell King - ARM Linux
  Cc: Nicolas Pitre, linux-kernel, linux-arm-kernel, Catalin Marinas,
	Jeremy Kerr

On Wed, Jan 12, 2011 at 10:25 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Wed, Jan 12, 2011 at 10:16:44AM -0700, Grant Likely wrote:
>> On Wed, Jan 12, 2011 at 9:53 AM, Nicolas Pitre <nico@fluxnic.net> wrote:
>> > On Wed, 12 Jan 2011, Grant Likely wrote:
>> >
>> >> Actually it looks like the real problem is that the mmu has been
>> >> turned on, but the virtual mappings for devices have not yet been
>> >> established, and so the debug macros aren't using a valid address.
>> >
>> > A temporary virtual mapping should be there -- look for addruart in
>> > head.S.
>>
>> Hi Russell and Nicolas,
>>
>> Oops, yes all the early debug stuff works fine.  Stupid human trick on
>> my end, but I've sorted it out now.  Thanks for the help.  I'll have
>> patches to post later today.
>
> I just hacked this up, and on Versatile (real hardware) it produces
> the below for an invalid r1 value - and of course works for a proper r1
> value.

Heh, that look pretty close to identical to what I was just about to send.

Acked-by: Grant Likely <grant.likely@secretlab.ca>

I'll send the updated atags patch rebased and retested on top of this one.

g.

>
> Uncompressing Linux... done, booting the kernel.
>
> Error: unrecognized/unsupported machine ID (r1 = 0x00123456).
>
> Available machine support:
>
> ID (hex)        NAME
> 00000183        ARM-Versatile PB
> 0000025e        ARM-Versatile AB
>
> Please check your kernel config and/or bootloader.
>
> diff --git a/arch/arm/kernel/head-common.S b/arch/arm/kernel/head-common.S
> index bbecaac..c84b57d 100644
> --- a/arch/arm/kernel/head-common.S
> +++ b/arch/arm/kernel/head-common.S
> @@ -25,81 +25,6 @@
>  * machine ID for example).
>  */
>        __HEAD
> -__error_a:
> -#ifdef CONFIG_DEBUG_LL
> -       mov     r4, r1                          @ preserve machine ID
> -       adr     r0, str_a1
> -       bl      printascii
> -       mov     r0, r4
> -       bl      printhex8
> -       adr     r0, str_a2
> -       bl      printascii
> -       adr     r3, __lookup_machine_type_data
> -       ldmia   r3, {r4, r5, r6}                @ get machine desc list
> -       sub     r4, r3, r4                      @ get offset between virt&phys
> -       add     r5, r5, r4                      @ convert virt addresses to
> -       add     r6, r6, r4                      @ physical address space
> -1:     ldr     r0, [r5, #MACHINFO_TYPE]        @ get machine type
> -       bl      printhex8
> -       mov     r0, #'\t'
> -       bl      printch
> -       ldr     r0, [r5, #MACHINFO_NAME]        @ get machine name
> -       add     r0, r0, r4
> -       bl      printascii
> -       mov     r0, #'\n'
> -       bl      printch
> -       add     r5, r5, #SIZEOF_MACHINE_DESC    @ next machine_desc
> -       cmp     r5, r6
> -       blo     1b
> -       adr     r0, str_a3
> -       bl      printascii
> -       b       __error
> -ENDPROC(__error_a)
> -
> -str_a1:        .asciz  "\nError: unrecognized/unsupported machine ID (r1 = 0x"
> -str_a2:        .asciz  ").\n\nAvailable machine support:\n\nID (hex)\tNAME\n"
> -str_a3:        .asciz  "\nPlease check your kernel config and/or bootloader.\n"
> -       .align
> -#endif
> -
> -/*
> - * Lookup machine architecture in the linker-build list of architectures.
> - * Note that we can't use the absolute addresses for the __arch_info
> - * lists since we aren't running with the MMU on (and therefore, we are
> - * not in the correct address space).  We have to calculate the offset.
> - *
> - *  r1 = machine architecture number
> - * Returns:
> - *  r3, r4, r6 corrupted
> - *  r5 = mach_info pointer in physical address space
> - */
> -__lookup_machine_type:
> -       adr     r3, __lookup_machine_type_data
> -       ldmia   r3, {r4, r5, r6}
> -       sub     r3, r3, r4                      @ get offset between virt&phys
> -       add     r5, r5, r3                      @ convert virt addresses to
> -       add     r6, r6, r3                      @ physical address space
> -1:     ldr     r3, [r5, #MACHINFO_TYPE]        @ get machine type
> -       teq     r3, r1                          @ matches loader number?
> -       beq     2f                              @ found
> -       add     r5, r5, #SIZEOF_MACHINE_DESC    @ next machine_desc
> -       cmp     r5, r6
> -       blo     1b
> -       mov     r5, #0                          @ unknown machine
> -2:     mov     pc, lr
> -ENDPROC(__lookup_machine_type)
> -
> -/*
> - * Look in arch/arm/kernel/arch.[ch] for information about the
> - * __arch_info structures.
> - */
> -       .align  2
> -       .type   __lookup_machine_type_data, %object
> -__lookup_machine_type_data:
> -       .long   .
> -       .long   __arch_info_begin
> -       .long   __arch_info_end
> -       .size   __lookup_machine_type_data, . - __lookup_machine_type_data
>
>  /* Determine validity of the r2 atags pointer.  The heuristic requires
>  * that the pointer be aligned, in the first 16k of physical RAM and
> @@ -107,8 +32,6 @@ __lookup_machine_type_data:
>  * of this function may be more lenient with the physical address and
>  * may also be able to move the ATAGS block if necessary.
>  *
> - * r8  = machinfo
> - *
>  * Returns:
>  *  r2 either valid atags pointer, or zero
>  *  r5, r6 corrupted
> @@ -183,17 +106,6 @@ __mmap_switched_data:
>        .size   __mmap_switched_data, . - __mmap_switched_data
>
>  /*
> - * This provides a C-API version of __lookup_machine_type
> - */
> -ENTRY(lookup_machine_type)
> -       stmfd   sp!, {r4 - r6, lr}
> -       mov     r1, r0
> -       bl      __lookup_machine_type
> -       mov     r0, r5
> -       ldmfd   sp!, {r4 - r6, pc}
> -ENDPROC(lookup_machine_type)
> -
> -/*
>  * This provides a C-API version of __lookup_processor_type
>  */
>  ENTRY(lookup_processor_type)
> diff --git a/arch/arm/kernel/head-nommu.S b/arch/arm/kernel/head-nommu.S
> index 814ce1a..6b1e0ad 100644
> --- a/arch/arm/kernel/head-nommu.S
> +++ b/arch/arm/kernel/head-nommu.S
> @@ -44,9 +44,6 @@ ENTRY(stext)
>        bl      __lookup_processor_type         @ r5=procinfo r9=cpuid
>        movs    r10, r5                         @ invalid processor (r5=0)?
>        beq     __error_p                               @ yes, error 'p'
> -       bl      __lookup_machine_type           @ r5=machinfo
> -       movs    r8, r5                          @ invalid machine (r5=0)?
> -       beq     __error_a                       @ yes, error 'a'
>
>        adr     lr, BSYM(__after_proc_init)     @ return (PIC) address
>  ARM(  add     pc, r10, #PROCINFO_INITFUNC     )
> diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S
> index 06aed19..084db6c 100644
> --- a/arch/arm/kernel/head.S
> +++ b/arch/arm/kernel/head.S
> @@ -87,14 +87,10 @@ ENTRY(stext)
>        movs    r10, r5                         @ invalid processor (r5=0)?
>  THUMB( it     eq )            @ force fixup-able long branch encoding
>        beq     __error_p                       @ yes, error 'p'
> -       bl      __lookup_machine_type           @ r5=machinfo
> -       movs    r8, r5                          @ invalid machine (r5=0)?
> - THUMB( it     eq )            @ force fixup-able long branch encoding
> -       beq     __error_a                       @ yes, error 'a'
>
>        /*
>         * r1 = machine no, r2 = atags,
> -        * r8 = machinfo, r9 = cpuid, r10 = procinfo
> +        * r9 = cpuid, r10 = procinfo
>         */
>        bl      __vet_atags
>  #ifdef CONFIG_SMP_ON_UP
> @@ -108,7 +104,7 @@ ENTRY(stext)
>        /*
>         * The following calls CPU specific code in a position independent
>         * manner.  See arch/arm/mm/proc-*.S for details.  r10 = base of
> -        * xxx_proc_info structure selected by __lookup_machine_type
> +        * xxx_proc_info structure selected by __lookup_processor_type
>         * above.  On return, the CPU will be ready for the MMU to be
>         * turned on, and r0 will hold the CPU control register value.
>         */
> @@ -127,7 +123,6 @@ ENDPROC(stext)
>  * amount which are required to get the kernel running, which
>  * generally means mapping in the kernel code.
>  *
> - * r8  = machinfo
>  * r9  = cpuid
>  * r10 = procinfo
>  *
> diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
> index 7c5499d..eb952a7 100644
> --- a/arch/arm/kernel/setup.c
> +++ b/arch/arm/kernel/setup.c
> @@ -308,7 +308,44 @@ static void __init cacheid_init(void)
>  * already provide the required functionality.
>  */
>  extern struct proc_info_list *lookup_processor_type(unsigned int);
> -extern struct machine_desc *lookup_machine_type(unsigned int);
> +
> +static void __init early_print(const char *str, ...)
> +{
> +       extern void printascii(const char *);
> +       char buf[256];
> +       va_list ap;
> +
> +       va_start(ap, str);
> +       vsnprintf(buf, sizeof(buf), str, ap);
> +       va_end(ap);
> +
> +#ifdef CONFIG_DEBUG_LL
> +       printascii(buf);
> +#endif
> +       printk("%s", buf);
> +}
> +
> +static struct machine_desc * __init lookup_machine_type(unsigned int type)
> +{
> +       extern struct machine_desc __arch_info_begin[], __arch_info_end[];
> +       struct machine_desc *p;
> +
> +       for (p = __arch_info_begin; p < __arch_info_end; p++)
> +               if (type == p->nr)
> +                       return p;
> +
> +       early_print("\n"
> +               "Error: unrecognized/unsupported machine ID (r1 = 0x%08x).\n\n"
> +               "Available machine support:\n\nID (hex)\tNAME\n", type);
> +
> +       for (p = __arch_info_begin; p < __arch_info_end; p++)
> +               early_print("%08x\t%s\n", p->nr, p->name);
> +
> +       early_print("\nPlease check your kernel config and/or bootloader.\n");
> +
> +       while (true)
> +               /* can't use cpu_relax() here as it may require MMU setup */;
> +}
>
>  static void __init feat_v6_fixup(void)
>  {
>
>



-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [RFC] arm: Defer lookup of machine_type and vet of atags to setup.c
  2011-01-12 17:49                   ` Grant Likely
@ 2011-02-07 15:55                     ` Tony Lindgren
  0 siblings, 0 replies; 15+ messages in thread
From: Tony Lindgren @ 2011-02-07 15:55 UTC (permalink / raw)
  To: Grant Likely
  Cc: Russell King - ARM Linux, Nicolas Pitre, linux-kernel,
	linux-arm-kernel, Catalin Marinas, Jeremy Kerr

* Grant Likely <grant.likely@secretlab.ca> [110112 09:48]:
> On Wed, Jan 12, 2011 at 10:25 AM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > On Wed, Jan 12, 2011 at 10:16:44AM -0700, Grant Likely wrote:
> >> On Wed, Jan 12, 2011 at 9:53 AM, Nicolas Pitre <nico@fluxnic.net> wrote:
> >> > On Wed, 12 Jan 2011, Grant Likely wrote:
> >> >
> >> >> Actually it looks like the real problem is that the mmu has been
> >> >> turned on, but the virtual mappings for devices have not yet been
> >> >> established, and so the debug macros aren't using a valid address.
> >> >
> >> > A temporary virtual mapping should be there -- look for addruart in
> >> > head.S.
> >>
> >> Hi Russell and Nicolas,
> >>
> >> Oops, yes all the early debug stuff works fine.  Stupid human trick on
> >> my end, but I've sorted it out now.  Thanks for the help.  I'll have
> >> patches to post later today.
> >
> > I just hacked this up, and on Versatile (real hardware) it produces
> > the below for an invalid r1 value - and of course works for a proper r1
> > value.
> 
> Heh, that look pretty close to identical to what I was just about to send.
> 
> Acked-by: Grant Likely <grant.likely@secretlab.ca>

Tested-by: Tony Lindgren <tony@atomide.com>

^ permalink raw reply	[flat|nested] 15+ messages in thread

end of thread, other threads:[~2011-02-07 15:56 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-01-11  2:15 [RFC] arm: Defer lookup of machine_type and vet of atags to setup.c Grant Likely
2011-01-11  3:19 ` Nicolas Pitre
2011-01-11  5:21   ` Grant Likely
2011-01-11 10:40 ` Russell King - ARM Linux
2011-01-11 15:36   ` Grant Likely
2011-01-11 15:48     ` Russell King - ARM Linux
2011-01-12 15:46       ` Grant Likely
2011-01-12 15:52         ` Russell King - ARM Linux
2011-01-12 16:24           ` Grant Likely
2011-01-12 16:32             ` Russell King - ARM Linux
2011-01-12 16:53             ` Nicolas Pitre
2011-01-12 17:16               ` Grant Likely
2011-01-12 17:25                 ` Russell King - ARM Linux
2011-01-12 17:49                   ` Grant Likely
2011-02-07 15:55                     ` Tony Lindgren

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