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

[Thiemo Seufer <ths@networkno.de>]

Marc St-Jean wrote:
> 
> 
> 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.

You need both as they solve two independent problems. One is rerouting
the kernel entry, the other saves some space in the image.

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

LOADADDR is a short and thus bad name for a global symbol.

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

For targets with a raw binary kernel the assumption is that their
firmware jumps to the start of the image. The .fill translates to nops.

Targets which don't use 0x80000000 as load address don't need to
reserve space at the start for exception handlers.


Thiemo