linuxsh-dev

[linuxsh-dev] Back from the dead

[Stuart M. <Stu...@st...>]

Folks

Sorry about having been 'off-line' for so long, a trip to France and a
small mountain of other work over the last few weeks has been keeping
me otherwise engaged.

Anyway, I've just uploaded a couple of patches to the patch manager
which you may be interested in. They are both fairly large (100K and
250K respectivly), which is why I'm not including them here.

The first patch is probably the one most people will be interested in.
It's primary aim is to add support for 'generic' kernels, i.e. a single
kernel which can be booted onto multiple machines. At the moment its
main focus is on the board/machine level aspects of this, so all the
SolutionEngine/HP600/Overdrive #ifdefs have now been removed from the
code.

However it doesn't cover:
 - endianness
	I don't propose to do anything about this!
 - instruction set: SH3/SH4
	this could be done, I think, but I've yet to convince myself
	that gcc generated code for an SH3 will always run on an SH4
 - sub-architectue: 7708/9/20, 7750/1 (caches, uarts etc)
	this should not be too difficult now the basic structure is
	in place
 - where the kernel executes from and where RAM starts
	could be covered by running the kernel from P3 if we think it
	is worth doing, but will almost certainly require some assistance
	from the boot loader.

The changes have been modelled on the Alpha way of handling this, so
there should be virtually no code size or performance penalty for
building a machine specific kernel, and while the generic kernel is
inevitabley going to be slightly slower and larger, its not a major
change.

The machine is selected from the command line, for example:
  sh_mv=solutionengine
If the machine is not recognised then it defaulst to 'unknown', which
provides support for on-chip peripherials only.

If you want a little more detail, have a look in:
   Documentation/sh/new-machine.txt

There are also some 'incidental' changes which are included, which are
worth pointing out:
 - marking an interrupt as type IPR, without calling set_ipr_data, caused
   the IRQ probing code to crash, so make_ipr_data now takes the extra
   parameters set_ipr_data used to.
 - record number of chars sent and received on SCI(F)
 - a bug fix to the TCP/IP checksumming code for when the src and/or
   destination addresses are misaligned.

The second patch adds PCI support for the Overdrive. Because this is
now so large (mainly becuause of a big FPG program) I've moved all
Overdrive related files into a separate directory. As this is probably
only a temporary measure (this is only needed for prototype boards), I
suggest we don't try and get this directory included in the mainstream
sources yet. Everything will build quite happily with it missing.

Note I've not been able to test on anything other than SH4 SolutionEngine
and Overdrive, so I'd welcome some comments from people with other
hardware, in particular HP600.

Anyway, see what you think, any comments, please let me know.

Stuart

[linuxsh-dev] Back from the dead

[NIIBE Y. <gn...@ch...>]

Hello Stuart, 

Nice to see you again.

Stuart Menefy wrote:
 > The first patch is probably the one most people will be interested in.
 > It's primary aim is to add support for 'generic' kernels, i.e. a single
 > kernel which can be booted onto multiple machines. At the moment its
 > main focus is on the board/machine level aspects of this, so all the
 > SolutionEngine/HP600/Overdrive #ifdefs have now been removed from the
 > code.
[...]
 > The machine is selected from the command line, for example:
 >   sh_mv=solutionengine
 > If the machine is not recognised then it defaulst to 'unknown', which
 > provides support for on-chip peripherials only.

I like it.  You've changed the meaning of 'generic' into runtime thing
(so far, it means 'non-specific').  This is great.

 > There are also some 'incidental' changes which are included, which are
 > worth pointing out:
 >  - marking an interrupt as type IPR, without calling set_ipr_data, caused
 >    the IRQ probing code to crash, so make_ipr_data now takes the extra
 >    parameters set_ipr_data used to.
 >  - record number of chars sent and received on SCI(F)
 >  - a bug fix to the TCP/IP checksumming code for when the src and/or
 >    destination addresses are misaligned.

Last one, the checksum code is really needed.  Takeshi and/or Sugioka-san
would thank you. :-)

And when I will find time, I'd like to enhance HERTBEAT feature you've
introduced, so that it will use BIOS interface.

 > The second patch adds PCI support for the Overdrive. Because this is
 > now so large (mainly becuause of a big FPG program) I've moved all
 > Overdrive related files into a separate directory. As this is probably
 > only a temporary measure (this is only needed for prototype boards), I
 > suggest we don't try and get this directory included in the mainstream
 > sources yet. Everything will build quite happily with it missing.

OK.

Could you please check all of them in?  Then, I'll merge Jesper's 7707
change over that.
-- 

Re: [linuxsh-dev] Back from the dead

[Stuart M. <Stu...@st...>]

On Jul 28, 10:09am, gn...@ch... wrote:
> Subject: [linuxsh-dev] Back from the dead
> 
> Hello Stuart, 
> 
> Nice to see you again.

Its good to be back!

> Could you please check all of them in?  Then, I'll merge Jesper's 7707
> change over that.

Done.

Stuart

Re: [linuxsh-dev] Back from the dead

[YAEGASHI T. <yae...@ma...>]

Hello Stuart, nice to see you again.

>> Could you please check all of them in?  Then, I'll merge Jesper's 7707
>> change over that.
>
>Done.

Hmm, there were so big changes.  I've hunted some bugs for HP600.

I think that io_hd64461.[ch] are a kind of generic I/O routines
for the system using HD64461 and should be used under
CONFIG_SH_HP600 for now.  I'll create new files as io_hp600.[ch]
if needed in future.

Patches are attached.  They also include changes mainly for
HP600.  Niibe-san, please check them in when they are approved.
I cannot access the repository from the company.

--
YAEGASHI Takeshi <yae...@ma...>

Re: [linuxsh-dev] Back from the dead

[NIIBE Y. <gn...@ch...>]

YAEGASHI Takeshi wrote:
 > Patches are attached.  They also include changes mainly for
 > HP600.  Niibe-san, please check them in when they are approved.
 > I cannot access the repository from the company.

Done.

Also added Jesper's SH7707 changes, and cosmetic changes to make it
compile.

I think that we should support I/O for "unknown" (bare) machine.
Currently, there's no I/O support for "unknown" board.  This is kind
of backward.

I'm thinking adding BIOS call to get I/O offset and interface type
and such.
-- 

Re: [linuxsh-dev] Back from the dead

[Stuart M. <Stu...@st...>]

Yaegashi-san

> Hmm, there were so big changes.  I've hunted some bugs for HP600.

Thanks for doing this. I did my best not to break it, but was
probably inevitable that I would!

> I think that io_hd64461.[ch] are a kind of generic I/O routines
> for the system using HD64461 and should be used under
> CONFIG_SH_HP600 for now.  I'll create new files as io_hp600.[ch]
> if needed in future.

I think with support chips like this, it is hard to distinguish what is
machine specific and what is chip specific, especially when there is
only one example of such a machine! But I agree, it is useful to have
as a reference point for a machine with no other I/O requirements.

I'll probably need to add support for the HD64465 at some point in the
next few months, and hope to be able to use the HD64461 code as a
starting point, so we'll see what happens then.

Stuart

[linuxsh-dev] Re: Back from the dead

[Tomoyoshi A. <as...@us...>]

Hello Stuart-san and all.

On Tue, 1 Aug 2000 18:26:55 +0100
Stuart Menefy <Stu...@st...> wrote:

> 
> I'll probably need to add support for the HD64465 at some point in the
> next few months, and hope to be able to use the HD64461 code as a
> starting point, so we'll see what happens then.
> 
> Stuart
> 

I'm Tomoyoshi ASANO.
I'm working at Lineo.

We ported linuxsh cvs code for HSA ASPEN/TAHOE board
last month.

The ASPEN board has a SH7750 and the TAHOE board which 
is the dauther board of ASEPN has a HD64465.
So we have some codes for HD64465.

Do you plan to wrok for the same board?

I want to provide these codes for HSA ASPEN/TAHOE board.
But I don't know how to marge the code to cvs well.
Please give me suggestion to do it.

But the current linuxsh cvs code is changed around I/O and
interrupt recently, so I have not fixed it yet.

And I'm busy this week and the next week.
I hope do it at the last of this month.

Tom
--

Re: [linuxsh-dev] Re: Back from the dead

[Stuart M. <Stu...@st...>]

Asano-san

I suddenly remembered I'd forgotten to reply to you.

No, the board we will be working on with the HD64465 is not the Hitachi
board, but a propritary one. With a bit of luck our board designers will
have followed the Hitachi recomendations, and everything should be mapped
at the same addreses as the Hitachi board, so we shouldn't have too many
problems. However there is other stuff on the board such as PCI which
takes up quite a bit of address space, so it may have been moved. We
shall see...

The interrupt and IO changes in the kernel sources should be complete now,
as far as I am concerned (appart from combining isa_port2addr and port2addr
in the machine vector), so now would probably be a good oportunity to get
this sort of change in.

You may want to have a look at the document I added in
  kernel/Documentation/sh/new-machine.txt
for an overview of how the new system works. 

How you integerate this probably depends on how similar the code is to
that for the HD64461. If they are pretty similar, I would be
inclined to make the current HD64461 configuration option more generic,
and only distinguish the two devices when you have to. 

If all else fails, please post your patches, and if nobody else has done
so, I'll have a go at integrating them when I get the hardware.

Which devices are you supporting on the HD64465? In particular are you
supporting USB? This looked kind of tricky when reading through the
manual.

Stuart


On Aug 2, 11:42am, as...@us... wrote:
> Subject: [linuxsh-dev] Re: Back from the dead
> 
> Hello Stuart-san and all.
> 
> On Tue, 1 Aug 2000 18:26:55 +0100
> Stuart Menefy <Stu...@st...> wrote:
> 
> > 
> > I'll probably need to add support for the HD64465 at some point in the
> > next few months, and hope to be able to use the HD64461 code as a
> > starting point, so we'll see what happens then.
> > 
> > Stuart
> > 
> 
> I'm Tomoyoshi ASANO.
> I'm working at Lineo.
> 
> We ported linuxsh cvs code for HSA ASPEN/TAHOE board
> last month.
> 
> The ASPEN board has a SH7750 and the TAHOE board which 
> is the dauther board of ASEPN has a HD64465.
> So we have some codes for HD64465.
> 
> Do you plan to wrok for the same board?
> 
> I want to provide these codes for HSA ASPEN/TAHOE board.
> But I don't know how to marge the code to cvs well.
> Please give me suggestion to do it.
> 
> But the current linuxsh cvs code is changed around I/O and
> interrupt recently, so I have not fixed it yet.
> 
> And I'm busy this week and the next week.
> I hope do it at the last of this month.
> 
> Tom
> --
> 
> 
> _______________________________________________
> linuxsh-dev mailing list
> lin...@li...
> http://lists.sourceforge.net/mailman/listinfo/linuxsh-dev
>-- End of excerpt from as...@us...

Re: [linuxsh-dev] Back from the dead

[Mitch D. <mj...@al...>]

NIIBE Yutaka wrote:
> 
> I think that we should support I/O for "unknown" (bare) machine.
> Currently, there's no I/O support for "unknown" board.  This is kind
> of backward.
> 
> I'm thinking adding BIOS call to get I/O offset and interface type
> and such.

Excellent.  Then the job of getting the kernel to work on a new
board would be reduced to writing the correct BIOS self-description
routines.

Regards,

Mitch.
--
mailto:mj...@al... | Certified Linux Evangelist!

Re: [linuxsh-dev] Back from the dead

[Stuart M. <Stu...@st...>]

Folks

> I think that we should support I/O for "unknown" (bare) machine.
> Currently, there's no I/O support for "unknown" board.  This is kind
> of backward.

I'm not sure. My thinking was that for a really unknown machine (i.e.
one which is not yet specifically supported) because you don't know
where any off-chip peripherials are it was better to not attempt any
I/O at all....

> I'm thinking adding BIOS call to get I/O offset and interface type
> and such.

...however if we can pass extra information into the kernel (BIOS
and/or command line), then it makes sense to support it.

[Time passes, several attempts to put what I'm thinking into words fail.]

Its easier to do it than try and explain it. See what you think about
the attached patches.

The sh_mv command line option now takes two parameters, the I/O base
address, and whether to enable memory mapped I/O. For example:
  sh_mv=unknown,0xa8000000,1

Stuart

Re: [linuxsh-dev] Back from the dead

[NIIBE Y. <gn...@ch...>]

Stuart Menefy wrote:
 > Its easier to do it than try and explain it. See what you think about
 > the attached patches.
 > 
 > The sh_mv command line option now takes two parameters, the I/O base
 > address, and whether to enable memory mapped I/O. For example:
 >   sh_mv=unknown,0xa8000000,1

Great.  That's the one I wanted.

When people try to port the kernel to their own board __at the first
time__, they have nothing.  With the patch like you made, people just
could try it out.  That's great value, I think.
-- 

Re: [linuxsh-dev] Back from the dead

[NIIBE Y. <gn...@ch...>]

Stuart, I needed following one-liner patch to use the command line:

	sh_mv=unknown,a4000000,1

for my board (CqREEK SH-4 with ISA/ATA Bridge).

I'm not sure why we have both of mv_port2addr and mv_isa_port2addr.
One is enough, isn't it?  I think that in/out is for ISA(-like)
interface.

--- arch/sh/kernel/io_generic.c	Wed Aug  2 18:06:36 2000
+++ arch/sh/kernel/io_generic.c.new	Wed Aug  2 17:26:23 2000
@@ -23,7 +23,7 @@
 #define DUMMY_READ_AREA6	  0xba000000
 #endif
 
-#define PORT2ADDR(x) (sh_mv.mv_port2addr(x))
+#define PORT2ADDR(x) (sh_mv.mv_isa_port2addr(x))
 
 unsigned long generic_io_base;
 

Re: [linuxsh-dev] Back from the dead

[Stuart M. <Stu...@st...>]

Niibe-san

Thanks for this. I wasn't able to test it before I posted as my
SolutionEngine has just been fried (the power supply was accidently
changed from 5V to 9V) and the Overdrive only has PCI I/O.

When I first did this work I only had one port2addr function. However I
got a bit confused by the code in the SolutionEngine io_se.c. There
appears to be different handling for PCMCIA I/O addresses (which doesn't
look finished...) and I/O to the SMSC SuperIO controller. I've never
played with PCMCIA, so don't really understand the issues, and kept
to two separate for this reason. If there is no good reason for this, 
great, I'll re-combine them.

Stuart

On Aug 2,  6:17pm, gn...@ch... wrote:
> Subject: Re: [linuxsh-dev] Back from the dead
> 
> Stuart, I needed following one-liner patch to use the command line:
> 
> 	sh_mv=unknown,a4000000,1
> 
> for my board (CqREEK SH-4 with ISA/ATA Bridge).
> 
> I'm not sure why we have both of mv_port2addr and mv_isa_port2addr.
> One is enough, isn't it?  I think that in/out is for ISA(-like)
> interface.
> 
> --- arch/sh/kernel/io_generic.c	Wed Aug  2 18:06:36 2000
> +++ arch/sh/kernel/io_generic.c.new	Wed Aug  2 17:26:23 2000
> @@ -23,7 +23,7 @@
>  #define DUMMY_READ_AREA6	  0xba000000
>  #endif
>  
> -#define PORT2ADDR(x) (sh_mv.mv_port2addr(x))
> +#define PORT2ADDR(x) (sh_mv.mv_isa_port2addr(x))
>  
>  unsigned long generic_io_base;
>  
> 
> _______________________________________________
> linuxsh-dev mailing list
> lin...@li...
> http://lists.sourceforge.net/mailman/listinfo/linuxsh-dev
>-- End of excerpt from gn...@ch...

Re: [linuxsh-dev] Back from the dead

[NIIBE Y. <gn...@ch...>]

Stuart Menefy wrote:
 > If there is no good reason for this, great, I'll re-combine them.

AFAIK, there's no good reason here.  Please go ahead.

Besides, I think that it is better to use some linker magic for
`all_vecs' handling.  Currently, when people want to add another
system, he has to touch setup.c for the inclusion.  I think that we
can add our own ELF section for the machine vector, then all that he
need is adding the specific file and modify Makefile.  No need to
touch other files.  Sounds good?
-- 

Re: [linuxsh-dev] Back from the dead

[NIIBE Y. <gn...@ch...>]

NIIBE Yutaka wrote:
 > Besides, I think that it is better to use some linker magic for
 > `all_vecs' handling.  Currently, when people want to add another
 > system, he has to touch setup.c for the inclusion.  I think that we
 > can add our own ELF section for the machine vector, then all that he
 > need is adding the specific file and modify Makefile.  No need to
 > touch other files.  Sounds good?

Like this one.  Any comments are appreciated.  If it's OK, I will add
ChangeLog entries and commit this over the changes by Stuart.

Index: arch/sh/vmlinux.lds.S
===================================================================
RCS file: /cvsroot/linuxsh/kernel/arch/sh/vmlinux.lds.S,v
retrieving revision 1.5
diff -u -r1.5 vmlinux.lds.S
--- arch/sh/vmlinux.lds.S	2000/07/20 06:50:06	1.5
+++ arch/sh/vmlinux.lds.S	2000/08/03 08:11:21
@@ -61,6 +61,9 @@
   __initcall_start = .;
   .initcall.init : { *(.initcall.init) }
   __initcall_end = .;
+  __machvec_start = .;
+  .machvec.init : { *(.machvec.init) }
+  __machvec_end = .;
   . = ALIGN(4096);
   __init_end = .;
 
Index: include/asm-sh/machvec_init.h
===================================================================
RCS file: /cvsroot/linuxsh/kernel/include/asm-sh/machvec_init.h,v
retrieving revision 1.1
diff -u -r1.1 machvec_init.h
--- include/asm-sh/machvec_init.h	2000/07/31 12:31:12	1.1
+++ include/asm-sh/machvec_init.h	2000/08/03 08:11:30
@@ -26,11 +26,15 @@
  * alias this one vector to alpha_mv, so no copy is needed.
  *
  * Upshot: set __initdata to nothing for non-GENERIC kernels.
+ *
+ * Note we do the same thing for the UNKNOWN kernel, as we need to write
+ * to the machine vector while setting it up.
  */
 
-#ifdef CONFIG_SH_GENERIC
+#if defined(CONFIG_SH_GENERIC) || defined(CONFIG_SH_UNKNOWN)
 #define __initmv __initdata
 #define ALIAS_MV(x)
+#define REGISTER_MV(x) long pointer_to_##x __attribute__((unused,__section__ (".machvec.init"))) = (long)&mv_##x;
 #else
 #define __initmv
 
@@ -44,6 +48,7 @@
 #define ALIAS_MV(system) \
   asm(".global sh_mv\nsh_mv = mv_"#system );
 #endif
+#define REGISTER_MV(x)
 #endif /* GENERIC */
 
 #endif /* __SH_MACHVEC_INIT_H */
Index: arch/sh/kernel/mach_hp600.c
===================================================================
RCS file: /cvsroot/linuxsh/kernel/arch/sh/kernel/mach_hp600.c,v
retrieving revision 1.3
diff -u -r1.3 mach_hp600.c
--- arch/sh/kernel/mach_hp600.c	2000/08/01 03:18:38	1.3
+++ arch/sh/kernel/mach_hp600.c	2000/08/03 08:11:21
@@ -61,3 +61,4 @@
 	mv_hw_hd64461:		1,
 };
 ALIAS_MV(hp600)
+REGISTER_MV(hp600)
Index: arch/sh/kernel/mach_se.c
===================================================================
RCS file: /cvsroot/linuxsh/kernel/arch/sh/kernel/mach_se.c,v
retrieving revision 1.1
diff -u -r1.1 mach_se.c
--- arch/sh/kernel/mach_se.c	2000/07/31 12:30:17	1.1
+++ arch/sh/kernel/mach_se.c	2000/08/03 08:11:21
@@ -78,3 +78,4 @@
 	mv_hw_se:		1,
 };
 ALIAS_MV(se)
+REGISTER_MV(se)
Index: arch/sh/kernel/mach_unknown.c
===================================================================
RCS file: /cvsroot/linuxsh/kernel/arch/sh/kernel/mach_unknown.c,v
retrieving revision 1.1
diff -u -r1.1 mach_unknown.c
--- arch/sh/kernel/mach_unknown.c	2000/07/31 12:30:36	1.1
+++ arch/sh/kernel/mach_unknown.c	2000/08/03 08:11:21
@@ -66,3 +66,4 @@
 	mv_isa_port2addr:	unknown_isa_port2addr,
 };
 ALIAS_MV(unknown)
+REGISTER_MV(unknown)
Index: arch/sh/kernel/setup.c
===================================================================
RCS file: /cvsroot/linuxsh/kernel/arch/sh/kernel/setup.c,v
retrieving revision 1.10
diff -u -r1.10 setup.c
--- arch/sh/kernel/setup.c	2000/08/01 03:18:38	1.10
+++ arch/sh/kernel/setup.c	2000/08/03 08:11:21
@@ -63,16 +64,6 @@
 extern int root_mountflags;
 extern int _text, _etext, _edata, _end;
 
-/* __attribute__(weak) doesn't appear to do anything */
-#define WEAK(X) \
-	extern struct sh_machine_vector X; \
-	asm(".weak "#X)
-
-WEAK(mv_unknown);
-WEAK(mv_hp600);
-WEAK(mv_od);
-WEAK(mv_se);
-
 #define MV_NAME_SIZE 32
 
 static struct sh_machine_vector* __init get_mv_byname(const char* name);
@@ -426,14 +471,11 @@
 struct sh_machine_vector* __init get_mv_byname(const char* name)
 {
 	extern int strcasecmp(const char *, const char *);
-	static struct sh_machine_vector *all_vecs[] __initlocaldata =
-	{
-		&mv_hp600,
-		&mv_od,
-		&mv_se,
-	};
+	extern long __machvec_start, __machvec_end;
+	struct sh_machine_vector **all_vecs =
+		(struct sh_machine_vector **)&__machvec_start;
 
-	int i, n = sizeof(all_vecs)/sizeof(*all_vecs);
+	int i, n = (&__machvec_end - &__machvec_start);
 
 	for (i = 0; i < n; ++i) {
 		struct sh_machine_vector *mv = all_vecs[i];
Index: arch/sh/overdrive/mach.c
===================================================================
RCS file: /cvsroot/linuxsh/kernel/arch/sh/overdrive/mach.c,v
retrieving revision 1.1
diff -u -r1.1 mach.c
--- arch/sh/overdrive/mach.c	2000/07/31 12:38:20	1.1
+++ arch/sh/overdrive/mach.c	2000/08/03 08:11:21
@@ -71,3 +71,4 @@
 };
 
 ALIAS_MV(od)
+REGISTER_MV(od)

Re: [linuxsh-dev] Back from the dead

[NIIBE Y. <gn...@ch...>]

Updated.

2000-08-04  NIIBE Yutaka  <gn...@m1...>

	Machvec support.
	* arch/sh/kernel/setup.c: Remove WEAK references.
	(get_mv_byname): Use .macvec.init. section.
	* include/asm-sh/machvec_init.h (__initmv): Use
	.macvec.init. section.
	* arch/sh/vmlinux.lds.S (.machvec.init): Added new section for
	Machine Vector.

Index: arch/sh/vmlinux.lds.S
===================================================================
RCS file: /cvsroot/linuxsh/kernel/arch/sh/vmlinux.lds.S,v
retrieving revision 1.5
diff -u -r1.5 vmlinux.lds.S
--- arch/sh/vmlinux.lds.S	2000/07/20 06:50:06	1.5
+++ arch/sh/vmlinux.lds.S	2000/08/04 03:14:22
@@ -61,6 +61,9 @@
   __initcall_start = .;
   .initcall.init : { *(.initcall.init) }
   __initcall_end = .;
+  __machvec_start = .;
+  .machvec.init : { *(.machvec.init) }
+  __machvec_end = .;
   . = ALIGN(4096);
   __init_end = .;
 
Index: arch/sh/kernel/setup.c
===================================================================
RCS file: /cvsroot/linuxsh/kernel/arch/sh/kernel/setup.c,v
retrieving revision 1.10
diff -u -r1.10 setup.c
--- arch/sh/kernel/setup.c	2000/08/01 03:18:38	1.10
+++ arch/sh/kernel/setup.c	2000/08/04 03:14:23
@@ -63,16 +64,6 @@
 extern int root_mountflags;
 extern int _text, _etext, _edata, _end;
 
-/* __attribute__(weak) doesn't appear to do anything */
-#define WEAK(X) \
-	extern struct sh_machine_vector X; \
-	asm(".weak "#X)
-
-WEAK(mv_unknown);
-WEAK(mv_hp600);
-WEAK(mv_od);
-WEAK(mv_se);
-
 #define MV_NAME_SIZE 32
 
 static struct sh_machine_vector* __init get_mv_byname(const char* name);
@@ -426,17 +471,16 @@
 struct sh_machine_vector* __init get_mv_byname(const char* name)
 {
 	extern int strcasecmp(const char *, const char *);
-	static struct sh_machine_vector *all_vecs[] __initlocaldata =
-	{
-		&mv_hp600,
-		&mv_od,
-		&mv_se,
-	};
-
-	int i, n = sizeof(all_vecs)/sizeof(*all_vecs);
+	extern long __machvec_start, __machvec_end;
+	struct sh_machine_vector *all_vecs =
+		(struct sh_machine_vector *)&__machvec_start;
+
+	int i, n = ((unsigned long)&__machvec_end
+		    - (unsigned long)&__machvec_start)/
+		sizeof(struct sh_machine_vector);
 
 	for (i = 0; i < n; ++i) {
-		struct sh_machine_vector *mv = all_vecs[i];
+		struct sh_machine_vector *mv = &all_vecs[i];
 		if (mv == NULL)
 			continue;
 		if (strcasecmp(name, mv->mv_name) == 0) {
Index: include/asm-sh/machvec_init.h
===================================================================
RCS file: /cvsroot/linuxsh/kernel/include/asm-sh/machvec_init.h,v
retrieving revision 1.1
diff -u -r1.1 machvec_init.h
--- include/asm-sh/machvec_init.h	2000/07/31 12:31:12	1.1
+++ include/asm-sh/machvec_init.h	2000/08/04 03:14:34
@@ -26,10 +26,13 @@
  * alias this one vector to alpha_mv, so no copy is needed.
  *
  * Upshot: set __initdata to nothing for non-GENERIC kernels.
+ *
+ * Note we do the same thing for the UNKNOWN kernel, as we need to write
+ * to the machine vector while setting it up.
  */
 
-#ifdef CONFIG_SH_GENERIC
-#define __initmv __initdata
+#if defined(CONFIG_SH_GENERIC) || defined(CONFIG_SH_UNKNOWN)
+#define __initmv __attribute__((unused,__section__ (".machvec.init")))
 #define ALIAS_MV(x)
 #else
 #define __initmv

Re: [linuxsh-dev] Back from the dead

[Greg B. <gn...@al...>]

NIIBE Yutaka wrote:
> 
> NIIBE Yutaka wrote:
>  > Besides, I think that it is better to use some linker magic for
>  > `all_vecs' handling.  [...]
> 
> Like this one.  Any comments are appreciated.  If it's OK, I will add
> ChangeLog entries and commit this over the changes by Stuart.
> 
> +  .machvec.init : { *(.machvec.init) }

  I like it.  Scales better than all_vecs and is consistent with
all the other linker magic tricks in the kernel.

Greg.
-- 
Fight spam http://www.caube.org.au/
If it's a choice between being a paranoid, hyper-suspicious global
village
idiot, or a gullible, mega-trusting sheep, I don't look good in mint
sauce. 
 - jd, slashdot, 11Feb2000.

Re: [linuxsh-dev] Back from the dead

[Stuart M. <Stu...@st...>]

Looks good to me.
Go for it.

Stuart

On Aug 3,  5:19pm, gn...@ch... wrote:
> Subject: Re: [linuxsh-dev] Back from the dead
> 
> NIIBE Yutaka wrote:
>  > Besides, I think that it is better to use some linker magic for
>  > `all_vecs' handling.  Currently, when people want to add another
>  > system, he has to touch setup.c for the inclusion.  I think that we
>  > can add our own ELF section for the machine vector, then all that he
>  > need is adding the specific file and modify Makefile.  No need to
>  > touch other files.  Sounds good?
> 
> Like this one.  Any comments are appreciated.  If it's OK, I will add
> ChangeLog entries and commit this over the changes by Stuart.
> 
> Index: arch/sh/vmlinux.lds.S
> ===================================================================
> RCS file: /cvsroot/linuxsh/kernel/arch/sh/vmlinux.lds.S,v
> retrieving revision 1.5
> diff -u -r1.5 vmlinux.lds.S
> --- arch/sh/vmlinux.lds.S	2000/07/20 06:50:06	1.5
> +++ arch/sh/vmlinux.lds.S	2000/08/03 08:11:21
> @@ -61,6 +61,9 @@
>    __initcall_start = .;
>    .initcall.init : { *(.initcall.init) }
>    __initcall_end = .;
> +  __machvec_start = .;
> +  .machvec.init : { *(.machvec.init) }
> +  __machvec_end = .;
>    . = ALIGN(4096);
>    __init_end = .;
>  
> Index: include/asm-sh/machvec_init.h
> ===================================================================
> RCS file: /cvsroot/linuxsh/kernel/include/asm-sh/machvec_init.h,v
> retrieving revision 1.1
> diff -u -r1.1 machvec_init.h
> --- include/asm-sh/machvec_init.h	2000/07/31 12:31:12	1.1
> +++ include/asm-sh/machvec_init.h	2000/08/03 08:11:30
> @@ -26,11 +26,15 @@
>   * alias this one vector to alpha_mv, so no copy is needed.
>   *
>   * Upshot: set __initdata to nothing for non-GENERIC kernels.
> + *
> + * Note we do the same thing for the UNKNOWN kernel, as we need to write
> + * to the machine vector while setting it up.
>   */
>  
> -#ifdef CONFIG_SH_GENERIC
> +#if defined(CONFIG_SH_GENERIC) || defined(CONFIG_SH_UNKNOWN)
>  #define __initmv __initdata
>  #define ALIAS_MV(x)
> +#define REGISTER_MV(x) long pointer_to_##x __attribute__((unused,__section__ (".machvec.init"))) = (long)&mv_##x;
>  #else
>  #define __initmv
>  
> @@ -44,6 +48,7 @@
>  #define ALIAS_MV(system) \
>    asm(".global sh_mv\nsh_mv = mv_"#system );
>  #endif
> +#define REGISTER_MV(x)
>  #endif /* GENERIC */
>  
>  #endif /* __SH_MACHVEC_INIT_H */
> Index: arch/sh/kernel/mach_hp600.c
> ===================================================================
> RCS file: /cvsroot/linuxsh/kernel/arch/sh/kernel/mach_hp600.c,v
> retrieving revision 1.3
> diff -u -r1.3 mach_hp600.c
> --- arch/sh/kernel/mach_hp600.c	2000/08/01 03:18:38	1.3
> +++ arch/sh/kernel/mach_hp600.c	2000/08/03 08:11:21
> @@ -61,3 +61,4 @@
>  	mv_hw_hd64461:		1,
>  };
>  ALIAS_MV(hp600)
> +REGISTER_MV(hp600)
> Index: arch/sh/kernel/mach_se.c
> ===================================================================
> RCS file: /cvsroot/linuxsh/kernel/arch/sh/kernel/mach_se.c,v
> retrieving revision 1.1
> diff -u -r1.1 mach_se.c
> --- arch/sh/kernel/mach_se.c	2000/07/31 12:30:17	1.1
> +++ arch/sh/kernel/mach_se.c	2000/08/03 08:11:21
> @@ -78,3 +78,4 @@
>  	mv_hw_se:		1,
>  };
>  ALIAS_MV(se)
> +REGISTER_MV(se)
> Index: arch/sh/kernel/mach_unknown.c
> ===================================================================
> RCS file: /cvsroot/linuxsh/kernel/arch/sh/kernel/mach_unknown.c,v
> retrieving revision 1.1
> diff -u -r1.1 mach_unknown.c
> --- arch/sh/kernel/mach_unknown.c	2000/07/31 12:30:36	1.1
> +++ arch/sh/kernel/mach_unknown.c	2000/08/03 08:11:21
> @@ -66,3 +66,4 @@
>  	mv_isa_port2addr:	unknown_isa_port2addr,
>  };
>  ALIAS_MV(unknown)
> +REGISTER_MV(unknown)
> Index: arch/sh/kernel/setup.c
> ===================================================================
> RCS file: /cvsroot/linuxsh/kernel/arch/sh/kernel/setup.c,v
> retrieving revision 1.10
> diff -u -r1.10 setup.c
> --- arch/sh/kernel/setup.c	2000/08/01 03:18:38	1.10
> +++ arch/sh/kernel/setup.c	2000/08/03 08:11:21
> @@ -63,16 +64,6 @@
>  extern int root_mountflags;
>  extern int _text, _etext, _edata, _end;
>  
> -/* __attribute__(weak) doesn't appear to do anything */
> -#define WEAK(X) \
> -	extern struct sh_machine_vector X; \
> -	asm(".weak "#X)
> -
> -WEAK(mv_unknown);
> -WEAK(mv_hp600);
> -WEAK(mv_od);
> -WEAK(mv_se);
> -
>  #define MV_NAME_SIZE 32
>  
>  static struct sh_machine_vector* __init get_mv_byname(const char* name);
> @@ -426,14 +471,11 @@
>  struct sh_machine_vector* __init get_mv_byname(const char* name)
>  {
>  	extern int strcasecmp(const char *, const char *);
> -	static struct sh_machine_vector *all_vecs[] __initlocaldata =
> -	{
> -		&mv_hp600,
> -		&mv_od,
> -		&mv_se,
> -	};
> +	extern long __machvec_start, __machvec_end;
> +	struct sh_machine_vector **all_vecs =
> +		(struct sh_machine_vector **)&__machvec_start;
>  
> -	int i, n = sizeof(all_vecs)/sizeof(*all_vecs);
> +	int i, n = (&__machvec_end - &__machvec_start);
>  
>  	for (i = 0; i < n; ++i) {
>  		struct sh_machine_vector *mv = all_vecs[i];
> Index: arch/sh/overdrive/mach.c
> ===================================================================
> RCS file: /cvsroot/linuxsh/kernel/arch/sh/overdrive/mach.c,v
> retrieving revision 1.1
> diff -u -r1.1 mach.c
> --- arch/sh/overdrive/mach.c	2000/07/31 12:38:20	1.1
> +++ arch/sh/overdrive/mach.c	2000/08/03 08:11:21
> @@ -71,3 +71,4 @@
>  };
>  
>  ALIAS_MV(od)
> +REGISTER_MV(od)
> 
> _______________________________________________
> linuxsh-dev mailing list
> lin...@li...
> http://lists.sourceforge.net/mailman/listinfo/linuxsh-dev
>-- End of excerpt from gn...@ch...