Thiemo Seufer wrote:
> 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).
Thanks, I'll introduce this config option to add the above 'jal kernel_entry'.
Our build system already takes care of doing the objcopy as well as
combining a rootfs, etc. so I'd rather not change the makefile if you
have no objections.
> > > > > > + /*
> > > > > > * 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 thought without the .fill that the kernel_entry function would be at
the start of text. Apparently not, a quick test shows a crash with both
the jal and .fill removed.
> > 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.
Thanks for clarifying,
Marc