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