linux-mips
[Top] [All Lists]

Re: [PATCH 2/5] mips: PMC MSP71xx mips common

To: Thiemo Seufer <ths@networkno.de>
Subject: Re: [PATCH 2/5] mips: PMC MSP71xx mips common
From: Marc St-Jean <Marc_St-Jean@pmc-sierra.com>
Date: Tue, 27 Feb 2007 09:59:51 -0800
Cc: Andrew Sharp <tigerand@gmail.com>, linux-mips@linux-mips.org
Original-recipient: rfc822;linux-mips@linux-mips.org
Sender: linux-mips-bounce@linux-mips.org
User-agent: Thunderbird 1.5.0.9 (X11/20061206)

Thiemo Seufer wrote:
> Marc St-Jean wrote:
> [snip]
>  > >  > +#ifdef CONFIG_PMC_MSP
>  > >  > +     jal     kernel_entry
>  > >  > +#else
> 
> Maybe introduce a CONFIG_BOOT_RAW (and use it in arch/mips/Makefile
> to objcopy the kernel to a raw binary).
> 
>  > >  > +     /*
>  > >  >        * Reserved space for exception handlers.
>  > >  >        * Necessary for machines which link their kernels at KSEG0.
>  > >  >        */
>  > >  >       .fill   0x400
>  > >  > +#endif /* CONFIG_PMC_MSP */
>  > >
>  > > This is getting kind of ugly.  There are a whole lot of config choices
>  > > that need to use the 'j kernel_entry'.  Do they all have to have their
>  > > own?  I'm not sure what the best way is to handle them all.
>  >
>  > I agree but don't know the best way to handle this. I could introduce a
>  > SYS_NO_EXEPT_FILL or similar flag but this seems excessive.
>  >
>  > Any other ideas from arch/mips folks?
> 
> Something like
> 
> #if LOADADDR == 0xffffffff80000000
>         .fill   0x400
> #endif
> 
> but by defining an appropriate name in arch/mips/Makefile instead of
> externalizing the load-y/LOADADDR there.

Thanks for the suggestions Thiemo.

We only need one of these solutions and I think the second one is cleaner.
I do have a few questions before respinning the patch:

1. Why do you want to create another name, wouldn't there be less confusion
and chance for errors by reusing LOADADDR and ensuring it's the same as what
the linker script uses?

2. Looking at arch/mips/Makefile there are many boards not using
0xffffffff80000000. If we introduce this check it seems that all of these
boards will have their _stext changed and it'll affect their "jump" address
from monitor/boot scripts?

Marc

<Prev in Thread] Current Thread [Next in Thread>