* Fixed kernel entry point suggestion
@ 2005-12-28 7:36 Adil Hafeez
2005-12-28 14:22 ` Dan Malek
0 siblings, 1 reply; 6+ messages in thread
From: Adil Hafeez @ 2005-12-28 7:36 UTC (permalink / raw)
To: linux-mips
[-- Attachment #1: Type: text/plain, Size: 320 bytes --]
Hi,
Everytime we add/remove a feature from kernel location of entry_point symbol
changes. As a result we 've to recompile bootloader with new entry_point
location. Adding a simply jump instruction to kernel_entry point in
head.Scan solve this problem. Why dont we make this change permanent
in kernel.
- Adil
[-- Attachment #2: Type: text/html, Size: 371 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Fixed kernel entry point suggestion
2005-12-28 7:36 Fixed kernel entry point suggestion Adil Hafeez
@ 2005-12-28 14:22 ` Dan Malek
2005-12-30 9:36 ` Adil Hafeez
0 siblings, 1 reply; 6+ messages in thread
From: Dan Malek @ 2005-12-28 14:22 UTC (permalink / raw)
To: Adil Hafeez; +Cc: linux-mips
On Dec 28, 2005, at 2:36 AM, Adil Hafeez wrote:
> Everytime we add/remove a feature from kernel location of entry_point
> symbol changes.
If you "wrap" the kernel image with a simple header and have a boot
loader
that understands this, or even understands the ELF header, or download
S-records (yuk) as most systems do, I guess it isn't necessary to fix
this.
I've been providing the compressed zImage patches for a long time that
solves
this, as well as the u-boot uImage patches. The process of building
these
images not only locates the proper entry point, but it provides
advantages
for embedded systems by creating smaller images and faster boot times.
> ..... Adding a simply jump instruction to kernel_entry point in
> head.S can solve this problem. Why dont we make this change permanent
> in kernel.
:-) It seems MIPS likes to be different from other architectures that
have
solved these irritating little details years ago :-) Submit a patch
and see
what happens, as just complaining on the list isn't likely to make it
happen.
Thanks.
-- Dan
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Fixed kernel entry point suggestion
2005-12-28 14:22 ` Dan Malek
@ 2005-12-30 9:36 ` Adil Hafeez
2005-12-30 9:47 ` Thiemo Seufer
0 siblings, 1 reply; 6+ messages in thread
From: Adil Hafeez @ 2005-12-30 9:36 UTC (permalink / raw)
To: Dan Malek; +Cc: linux-mips
[-- Attachment #1.1: Type: text/plain, Size: 1575 bytes --]
Hi Dan,
Here is the patch.
diff --git a/arch/mips/kernel/head.S b/arch/mips/kernel/head.S
index eebdaa2..a5e6d4e 100644
--- a/arch/mips/kernel/head.S
+++ b/arch/mips/kernel/head.S
@@ -28,6 +28,7 @@
#include <asm/mipsregs.h>
#include <asm/stackframe.h>
+ j kernel_entry
.text
/*
* Reserved space for exception handlers.
On 12/28/05, Dan Malek <dan@embeddedalley.com> wrote:
>
> On Dec 28, 2005, at 2:36 AM, Adil Hafeez wrote:
>
> > Everytime we add/remove a feature from kernel location of entry_point
> > symbol changes.
>
> If you "wrap" the kernel image with a simple header and have a boot
> loader
> that understands this, or even understands the ELF header, or download
> S-records (yuk) as most systems do, I guess it isn't necessary to fix
> this.
> I've been providing the compressed zImage patches for a long time that
> solves
> this, as well as the u-boot uImage patches. The process of building
> these
> images not only locates the proper entry point, but it provides
> advantages
> for embedded systems by creating smaller images and faster boot times.
>
> > ..... Adding a simply jump instruction to kernel_entry point in
> > head.S can solve this problem. Why dont we make this change permanent
> > in kernel.
>
> :-) It seems MIPS likes to be different from other architectures that
> have
> solved these irritating little details years ago :-) Submit a patch
> and see
> what happens, as just complaining on the list isn't likely to make it
> happen.
>
> Thanks.
>
> -- Dan
>
>
[-- Attachment #1.2: Type: text/html, Size: 2097 bytes --]
[-- Attachment #2: kernel_entry-fix.patch --]
[-- Type: text/plain, Size: 313 bytes --]
diff --git a/arch/mips/kernel/head.S b/arch/mips/kernel/head.S
index eebdaa2..a5e6d4e 100644
--- a/arch/mips/kernel/head.S
+++ b/arch/mips/kernel/head.S
@@ -28,6 +28,7 @@
#include <asm/mipsregs.h>
#include <asm/stackframe.h>
+ j kernel_entry
.text
/*
* Reserved space for exception handlers.
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: Fixed kernel entry point suggestion
2005-12-30 9:36 ` Adil Hafeez
@ 2005-12-30 9:47 ` Thiemo Seufer
2005-12-30 10:22 ` Adil Hafeez
0 siblings, 1 reply; 6+ messages in thread
From: Thiemo Seufer @ 2005-12-30 9:47 UTC (permalink / raw)
To: linux-mips
Adil Hafeez wrote:
> Hi Dan,
>
> Here is the patch.
>
> diff --git a/arch/mips/kernel/head.S b/arch/mips/kernel/head.S
> index eebdaa2..a5e6d4e 100644
> --- a/arch/mips/kernel/head.S
> +++ b/arch/mips/kernel/head.S
> @@ -28,6 +28,7 @@
> #include <asm/mipsregs.h>
> #include <asm/stackframe.h>
>
> + j kernel_entry
> .text
> /*
> * Reserved space for exception handlers.
But certainly not _before_ .text. Also, it shouldn't move the reserved
space, it would need "align" instead of "space" afterwards.
Thiemo
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Fixed kernel entry point suggestion
2005-12-30 9:47 ` Thiemo Seufer
@ 2005-12-30 10:22 ` Adil Hafeez
2005-12-30 21:04 ` Thiemo Seufer
0 siblings, 1 reply; 6+ messages in thread
From: Adil Hafeez @ 2005-12-30 10:22 UTC (permalink / raw)
To: linux-mips
[-- Attachment #1: Type: text/plain, Size: 1167 bytes --]
What about placing the jump instruction just after reserved space, like this
.text
/*
* Reserved space for exception handlers.
* Necessary for machines which link their kernels at KSEG0.
*/
.fill 0x400
/* The following two symbols are used for kernel profiling. */
EXPORT(stext)
EXPORT(_stext)
=> j kernel_entry
__INIT
I disassembled vmlinux binary and now jump instruction is placed after
reserved space
On 12/30/05, Thiemo Seufer <ths@networkno.de> wrote:
>
> Adil Hafeez wrote:
> > Hi Dan,
> >
> > Here is the patch.
> >
> > diff --git a/arch/mips/kernel/head.S b/arch/mips/kernel/head.S
> > index eebdaa2..a5e6d4e 100644
> > --- a/arch/mips/kernel/head.S
> > +++ b/arch/mips/kernel/head.S
> > @@ -28,6 +28,7 @@
> > #include <asm/mipsregs.h>
> > #include <asm/stackframe.h>
> >
> > + j kernel_entry
> > .text
> > /*
> > * Reserved space for exception handlers.
>
> But certainly not _before_ .text. Also, it shouldn't move the reserved
> space, it would need "align" instead of "space" afterwards.
>
>
> Thiemo
>
>
[-- Attachment #2: Type: text/html, Size: 2029 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Fixed kernel entry point suggestion
2005-12-30 10:22 ` Adil Hafeez
@ 2005-12-30 21:04 ` Thiemo Seufer
0 siblings, 0 replies; 6+ messages in thread
From: Thiemo Seufer @ 2005-12-30 21:04 UTC (permalink / raw)
To: Adil Hafeez; +Cc: linux-mips
Adil Hafeez wrote:
> What about placing the jump instruction just after reserved space, like this
>
> .text
> /*
> * Reserved space for exception handlers.
> * Necessary for machines which link their kernels at KSEG0.
> */
> .fill 0x400
>
> /* The following two symbols are used for kernel profiling. */
> EXPORT(stext)
> EXPORT(_stext)
> => j kernel_entry
> __INIT
>
> I disassembled vmlinux binary and now jump instruction is placed after
> reserved space
This only works iff the fill is done with NOPs. On a more general note,
it is usually considered to be the bootloader's job to find the correct
entry, not the kernel's one.
Thiemo
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2005-12-30 21:02 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-12-28 7:36 Fixed kernel entry point suggestion Adil Hafeez
2005-12-28 14:22 ` Dan Malek
2005-12-30 9:36 ` Adil Hafeez
2005-12-30 9:47 ` Thiemo Seufer
2005-12-30 10:22 ` Adil Hafeez
2005-12-30 21:04 ` Thiemo Seufer
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.