linuxsh-dev

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

[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

[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] Various tool patches - should the be put on sourceforge?

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

Hi Stuart,

Nice to hear from you again.

Stuart Menefy wrote:
> 
> Linux. What I was planning to ask him to do was put together a set of
> SRPM's for common tools, suitable for cross compilation.

This is a great idea.  It's especially hard for new people to
know where to go; having SRPMS would be a great step forward.

> I was thinking
> of using the MontaVista HardHat Linux distribution as a starting
> point, as this has already addressed the cross compilation problem,
> and is a reasonably distribution.

Recently I downloaded Niibe-san's "Chiyonofuji" distribution (which
is very nice to have - it has saved me a lot of time, thank you
Niibe-san!).  But I do not have the ability to rebuild some
of the software.  Basing it on something like the HardHat Linux
distribution (I have no objection to this particular one) and
making the source available for recompilation sounds like a great
way to go.

> Obviously we'd make these SRPMs (and RPMs?) available via SourceForge.

A nice idea.  Greg and I would be very happy to look after these,
if no-one else wants to.  SF is well-connected and the disk
space is free! :-)

> For things like this I'm assuming we don't want to add the source to
> CVS, as the number of changes should be small and contained, but I'm
> open to suggestions.

I think packages which have components which are extremely
SuperH-specific (like the boot-loader/gdb stub, the kernel and the
toolchain and maybe some X stuff) are good candidates for putting
into CVS.  Changes made to other packages are more likely to
require just some platform-generic tweaking to autoconf-type
mechanisms.  These don't need CVS' power and can be done as
patches.

We could create a patch category for each package that needed
patching, and use this to hold the patches until they have been
accepted by the original maintainer of the package and/or the
person doing the SuperH versions.

> What do you think? Is this worth doing?

Very much so, thanks a lot.  If you would like me to help, please
let me know.

Regards,

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

Re: [linuxsh-dev] Various tool patches - should the be put on sourceforge?

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

Folks

I agree we need to do something about this. At the moment everybody
is building their own tools, making the necessary configuration and
Makefile changes themselves. Some people are kindly making their
patches available, but it a hassle finding the origional files, making
the patches, and working out how to build it.

I've got an engineer starting here next week who has been earmarked for
Linux. What I was planning to ask him to do was put together a set of
SRPM's for common tools, suitable for cross compilation. I was thinking
of using the MontaVista HardHat Linux distribution as a starting
point, as this has already addressed the cross compilation problem, and
is a reasonably distribution.

Obviously we'd make these SRPMs (and RPMs?) available via SourceForge.
For things like this I'm assuming we don't want to add the source to 
CVS, as the number of changes should be small and contained, but I'm
open to suggestions.

What do you think? Is this worth doing? If so I'd welcome any patches
people already have, and we'll start the production line next week.

Cheers

Stuart

On Jul 28,  3:51pm, js...@re... wrote:
> Subject: [linuxsh-dev] Various tool patches - should the be put on sourcef
> 
> 
> I have a few patches for various tools that I could upload on
> sourceforge if it would be of help to anyone. I think they are all
> originally from Yutaka, but updated to newer tool packages.
> 
> ash-linux-0.2
> modutils-2.3.12
> ncurses-5.1
> pcmcia-cs-3.1.19
> 
> Let me know.
> 
> Cheers,
> Jesper
> 
> _______________________________________________
> linuxsh-dev mailing list
> lin...@li...
> http://lists.sourceforge.net/mailman/listinfo/linuxsh-dev
>-- End of excerpt from js...@re...

[linuxsh-dev] Various tool patches - should the be put on sourceforge?

[Jesper S. <js...@re...>]

I have a few patches for various tools that I could upload on
sourceforge if it would be of help to anyone. I think they are all
originally from Yutaka, but updated to newer tool packages.

ash-linux-0.2
modutils-2.3.12
ncurses-5.1
pcmcia-cs-3.1.19

Let me know.

Cheers,
Jesper

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

[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

Re: [linuxsh-dev] SH7707 patch made available on sourceforge

[Jesper S. <js...@re...>]

>>>>> "NIIBE" == NIIBE Yutaka <gn...@ch...> writes:

NIIBE> Basically, I don't think many option is good thing (if we have
NIIBE> the way to distingush in runtime, we shoud do that), but
NIIBE> supporting many chip is good thing.  Let's go for that.

I agree - it would be nice to be able to determine the CPU type at
run-time, possibly with some coarse grain config options to allow
selecting between SH3/SH4/?? (in the interest of reducing code size).

At the moment I'm trying to write a PCMCIA driver for the 7707's PCC
module, but I don't actually know how to correctly check for the
presence of that module - I don't remember seeing anything like
a chip/module revision register in the SH docs.

Jesper

[linuxsh-dev] SH7707 patch made available on sourceforge

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

Welcome to the development.  Nice to see.

I've looked through your change, it's sane.  I think that the main
change is IRQ dispatcher, isn't it?  Other change would be helpful for
the information of 7707.

Basically, I don't think many option is good thing (if we have the way
to distingush in runtime, we shoud do that), but supporting many chip
is good thing.  Let's go for that.

Thanks for your work.
-- 

[linuxsh-dev] SH7707 patch made available on sourceforge

[Jesper S. <js...@re...>]

Hi there,

I've just uploaded a patch to the sourceforge patch manager which adds
SH7707 support.

The patch is relative to the 2000.07.20 sources, so I'm not sure it'll
apply cleanly. I will get time to fix it up in a few days if that's
not the case.

Cheers,
Jesper

[linuxsh-dev] .cvsignore diff

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

==================
Press release:

Melbourne, Australia: In what has been described as "a major
boost to the Linux kernel's core functionality", a patch was
released today which tells CVS which generated files to ignore.

By hiding those files which are not relevant, the so-called
".cvsignore" patch will allow users of the advanced
"cvs diff -u" command to easily tell which files
they've actually changed.

A spokesman for LinuxSH, Mr. Security Porpoise, was quoted as
saying "this is a red-letter day for the Linux on SuperH project".
A spokesman for Microsoft could not be contacted.

==================

Seriously folks, this patch will make your CVS ups and CVS diffs
cleaner when doing it in a directory from which you've compiled.
These .cvsignore files cover unique files in each dir, but not
the sort of files that occur in many many dirs, such as
.depend or .o.flags files.  Hiding these additional files is
best done with the CVSIGNORE environment variable, eg,

  export CVSIGNORE=".depend .hdepend .*.o.flags .*.a.flags"

The combination of this patch and this env var setting will
make for a clean cvs up or cvs diff if you've not changed any
source files.

Regards,

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

Re: [linuxsh-dev] BIOS call related changes

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

NIIBE Yutaka wrote:
> 
> Following changes is needed when I use zImage with BIOS (no GDB debug
> feature enabled).
> 
> --------------------------
> 2000-07-22  NIIBE Yutaka  <gn...@m1...>
> 
>         * arch/sh/kernel/entry.S (debug_trap, debug_kernel):
>         #ifdef/#endif change, this is needed for SH BIOS call too.
> 
>         * arch/sh/boot/compressed/head.S (init_sr): Set Block=0,
>         so that we can use BIOS call.
> 
> Index: arch/sh/boot/compressed/head.S
> ===================================================================
> RCS file: /cvsroot/linuxsh/kernel/arch/sh/boot/compressed/head.S,v
> retrieving revision 1.2
> diff -u -r1.2 head.S
> --- arch/sh/boot/compressed/head.S      2000/05/22 09:41:30     1.2
> +++ arch/sh/boot/compressed/head.S      2000/07/22 04:15:25
> @@ -10,6 +10,9 @@
> 
>         .global startup
>  startup:
> +       /* Load initial status register */
> +       mov.l   init_sr, r1
> +       ldc     r1, sr
> 
>         /* First clear BSS */
>         mov.l   end_addr, r1
> @@ -20,10 +23,6 @@
>         cmp/eq  r1,r2
>         bf      l1
> 
> -       /* Load initial status register */
> -       mov.l   init_sr, r1
> -       ldc     r1, sr
> -
>         /* Set the initial pointer. */
>         mov.l   init_stack_addr, r0
>         mov.l   @r0, r15
> @@ -44,7 +43,7 @@
>  end_addr:
>         .long   _end
>  init_sr:
> -       .long   0x50000000      /* Privileged mode, Bank=0, Block=1, I3-I0=0 */
> +       .long   0x40000000      /* Privileged mode, Bank=0, Block=0, I3-I0=0 */

  Yep, obvious really, surprised it worked at all before ;-)

> ===================================================================
> RCS file: /cvsroot/linuxsh/kernel/arch/sh/kernel/entry.S,v
> retrieving revision 1.15
> diff -u -r1.15 entry.S
> --- arch/sh/kernel/entry.S      2000/07/21 18:06:52     1.15
> +++ arch/sh/kernel/entry.S      2000/07/22 04:15:25
> @@ -182,7 +182,7 @@
>  1:     .long   SYMBOL_NAME(do_page_fault)
>  2:     .long   MMU_TEA
> 
> -#ifdef CONFIG_DEBUG_KERNEL_WITH_GDB_STUB
> +#if defined(CONFIG_DEBUG_KERNEL_WITH_GDB_STUB) || defined(CONFIG_SH_STANDARD_BIOS)
>         .align  2
>         /* Unwind the stack and jmp to the debug entry */
>  debug_kernel:
> @@ -224,7 +224,7 @@
> 
>         .align  2
>  debug_trap:
> -#ifdef CONFIG_DEBUG_KERNEL_WITH_GDB_STUB
> +#if defined(CONFIG_DEBUG_KERNEL_WITH_GDB_STUB) || defined(CONFIG_SH_STANDARD_BIOS)
>         mov     #SR, $r0

  Oops, my mistake, I should have changed these to be

#ifdef CONFIG_SH_STANDARD_BIOS

  which handles both cases (as CONFIG_DEBUG_KERNEL_WITH_GDB_STUB is
not supposed to be defined unless CONFIG_SH_STANDARD_BIOS is defined).



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.

[linuxsh-dev] BIOS call related changes

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

Following changes is needed when I use zImage with BIOS (no GDB debug
feature enabled).

--------------------------
2000-07-22  NIIBE Yutaka  <gn...@m1...>

	* arch/sh/kernel/entry.S (debug_trap, debug_kernel):
	#ifdef/#endif change, this is needed for SH BIOS call too.

	* arch/sh/boot/compressed/head.S (init_sr): Set Block=0, 
	so that we can use BIOS call.

Index: arch/sh/boot/compressed/head.S
===================================================================
RCS file: /cvsroot/linuxsh/kernel/arch/sh/boot/compressed/head.S,v
retrieving revision 1.2
diff -u -r1.2 head.S
--- arch/sh/boot/compressed/head.S	2000/05/22 09:41:30	1.2
+++ arch/sh/boot/compressed/head.S	2000/07/22 04:15:25
@@ -10,6 +10,9 @@
 
 	.global	startup
 startup:
+	/* Load initial status register */
+	mov.l   init_sr, r1
+	ldc     r1, sr
 
 	/* First clear BSS */
 	mov.l	end_addr, r1
@@ -20,10 +23,6 @@
 	cmp/eq	r1,r2
 	bf	l1
 
-	/* Load initial status register */
-	mov.l   init_sr, r1
-	ldc     r1, sr
-	
 	/* Set the initial pointer. */
 	mov.l	init_stack_addr, r0
 	mov.l	@r0, r15
@@ -44,7 +43,7 @@
 end_addr:
 	.long	_end
 init_sr:
-	.long	0x50000000	/* Privileged mode, Bank=0, Block=1, I3-I0=0 */
+	.long	0x40000000	/* Privileged mode, Bank=0, Block=0, I3-I0=0 */
 init_stack_addr:
 	.long	stack_start
 decompress_kernel_addr:
cvs server: Diffing arch/sh/kernel
Index: arch/sh/kernel/entry.S
===================================================================
RCS file: /cvsroot/linuxsh/kernel/arch/sh/kernel/entry.S,v
retrieving revision 1.15
diff -u -r1.15 entry.S
--- arch/sh/kernel/entry.S	2000/07/21 18:06:52	1.15
+++ arch/sh/kernel/entry.S	2000/07/22 04:15:25
@@ -182,7 +182,7 @@
 1:	.long	SYMBOL_NAME(do_page_fault)
 2:	.long	MMU_TEA
 
-#ifdef CONFIG_DEBUG_KERNEL_WITH_GDB_STUB
+#if defined(CONFIG_DEBUG_KERNEL_WITH_GDB_STUB) || defined(CONFIG_SH_STANDARD_BIOS)
 	.align	2
 	/* Unwind the stack and jmp to the debug entry */
 debug_kernel:
@@ -224,7 +224,7 @@
 
 	.align	2
 debug_trap:	
-#ifdef CONFIG_DEBUG_KERNEL_WITH_GDB_STUB
+#if defined(CONFIG_DEBUG_KERNEL_WITH_GDB_STUB) || defined(CONFIG_SH_STANDARD_BIOS)
 	mov	#SR, $r0
 	mov.l	@($r0,$r15), $r0	! get status register
 	shll	$r0
@@ -674,7 +674,7 @@
 	tst	$k1, $k0
 	mov.l	4f, $k1
 	bf/s	9f		! FPU is not enabled, no need to save it
-	mov	$r15, $k0	! save original stack to k0
+	 mov	$r15, $k0	! save original stack to k0
 	! FPU is enabled, save it
 	! /* XXX: Need to save another bank of FPU if all FPU feature is used */
 	! /* Currently it's not the case for GCC (only udivsi3_i4, divsi3_i4) */

Re: [linuxsh-dev] Assorted patches for Linux kernel, and the stub.

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

Mitch Davis wrote:
> 
> I have now checked these changes in, except for the changes in
> kernel/arch/sh/kernel.  CVS has left a lock there that needs
> clearing before the checkin can proceed.  (I've asked the
> SourceForge people to fix it).

Hello everybody,

The problem has been fixed, and the files checked in.  It is
no longer necessary to apply the patch I sent out yesterday.

Regards,

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

Re: [linuxsh-dev] sh_console_unregister

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

NIIBE Yutaka wrote:
> 
> I'm preparing the update patch (to mainstream).  To avoid the changes
> small, I'd like to apply following changes for console handling.
> 
> I assume that EARLY_PRINTK feature is for SH serial console only,

  Well, yes and no. Its for delegating printk() to the BIOS, which
at the moment happens to mean serial console only.  But the BIOS
mechanism is more general, and can be applied to (say) a framebuffer
console.

> so
> it's OK to place calling unregister routine at SCI driver.

  Actually that's where I put it originally ;-)  I then moved it to
console_init() when I realised I would probably be working with a
framebuffer console in a few weeks' time.

> Yes, if someone extend the BIOS to support other serial chiip, this
> is not good.  But until that time, I think this is good thing.

  Sure, but that time is rapidly approaching.

> I just thought that the smaller patch is the better. 

  Yes.

> I don't think
> this is the solution.

  It's certainly not the solution today.  It will probably become a
solution soon.  It's a tough decision given the current state of
mainstream kernel development.

> I think that "early printk" feature could be generalized to generic
> issue (not specific to SuperH).  Say, serial console on x86 could
> also have the feature.  Let's go further.

  Yes, in fact I stole the name from CONFIG_IA64_EARLY_PRINTK which
I believe prints to a VGA console.  Trouble is, while the concept
is generic the implementation is very system-specific.


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] sh_console_unregister

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

Mitch Davis wrote:
 > BTW the patch in your message add the line "rio_init".  Did I
 > accidentally remove that when resolving the conflict?  (Hope not)

It's _me_ who have accidentally removed the line.

I just thought that the smaller patch is the better.  I don't think
this is the solution.

I think that "early printk" feature could be generalized to generic
issue (not specific to SuperH).  Say, serial console on x86 could
also have the feature.  Let's go further.
-- 

Re: [linuxsh-dev] sh_console_unregister

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

NIIBE Yutaka wrote:
> 
> I'm preparing the update patch (to mainstream).  To avoid the changes
> small, I'd like to apply following changes for console handling.
> 
> I assume that EARLY_PRINTK feature is for SH serial console only, so
> it's OK to place calling unregister routine at SCI driver.
> 
> Yes, if someone extend the BIOS to support other serial chiip, this
> is not good.  But until that time, I think this is good thing.

Hi Niibe-san,

There is already heaps of platform-specific stuff in tty_io.c.
In fact, from the time we wrote that code, to the time I checked
it in, someone else from some other project (ARM Linux I think)
had made a change and caused a conflict in that spot.  It seems
that's the place people put things like this.

> Yes, if someone extend the BIOS to support other serial chiip, this
> is not good.  But until that time, I think this is good thing.

Or maybe it's not even a serial port.  I have a backlit 40 char
by 2 line LCD display I'm trying to connect, and I want to modify
the stub to use this instead of the serial output.  If the
early printk unregister is put into sh-sci.c, this is more
difficult.

It's only a few lines, and it's surrounded by other very platform-
specific registrations.  The call is yours, but I would prefer
to see it stay in tty_io.c.

BTW the patch in your message add the line "rio_init".  Did I
accidentally remove that when resolving the conflict?  (Hope not)

Regards,

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

[linuxsh-dev] Memory map for loading kernel

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

NIIBE Yutaka wrote:
 > I'd like to reserve 64KB for the second storage loader (see the patch
 > below).  I think that Takeshi cares...

I've found that LILO require more.  One more 1KB please.
-- 

[linuxsh-dev] sh_console_unregister

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

I'm preparing the update patch (to mainstream).  To avoid the changes
small, I'd like to apply following changes for console handling.

I assume that EARLY_PRINTK feature is for SH serial console only, so
it's OK to place calling unregister routine at SCI driver.

Yes, if someone extend the BIOS to support other serial chiip, this
is not good.  But until that time, I think this is good thing.


2000-07-21  NIIBE Yutaka  <gn...@m1...>

	* drivers/char/tty_io.c (console_init): Don't call
	sh_console_unregister.

	* drivers/char/sh-sci.c (sci_console_init): Call
	sh_console_unregister here, instead.

Index: drivers/char/sh-sci.c
===================================================================
RCS file: /cvsroot/linuxsh/kernel/drivers/char/sh-sci.c,v
retrieving revision 1.13
diff -u -r1.13 sh-sci.c
--- drivers/char/sh-sci.c	2000/07/20 16:01:45	1.13
+++ drivers/char/sh-sci.c	2000/07/21 02:53:06
@@ -1099,8 +1099,18 @@
  *	Register console.
  */
 
+#ifdef CONFIG_SH_EARLY_PRINTK
+extern void sh_console_unregister (void);
+#endif
+
 void __init sci_console_init(void)
 {
 	register_console(&sercons);
+#ifdef CONFIG_SH_EARLY_PRINTK
+	/* Now that the real console is available, unregister the one we
+	 * used while first booting.
+	 */
+	sh_console_unregister();
+#endif
 }
 #endif /* CONFIG_SERIAL_CONSOLE */
Index: drivers/char/tty_io.c
===================================================================
RCS file: /cvsroot/linuxsh/kernel/drivers/char/tty_io.c,v
retrieving revision 1.10
diff -u -r1.10 tty_io.c
--- drivers/char/tty_io.c	2000/07/20 13:26:48	1.10
+++ drivers/char/tty_io.c	2000/07/21 02:53:07
@@ -102,9 +102,7 @@
 #ifdef CONFIG_VT
 extern void con_init_devfs (void);
 #endif
-#ifdef CONFIG_SH_EARLY_PRINTK
-extern void sh_console_unregister (void);
-#endif
+extern int rio_init(void);
 
 #define CONSOLE_DEV MKDEV(TTY_MAJOR,0)
 #define TTY_DEV MKDEV(TTYAUX_MAJOR,0)
@@ -2186,12 +2184,6 @@
 #endif
 #if defined(CONFIG_SH_SCI)
 	sci_console_init();
-#endif
-#ifdef CONFIG_SH_EARLY_PRINTK
-    /* Now that the real console is available, unregister the one we
-     * used while first booting.
-     */
-    sh_console_unregister();
 #endif
 #endif
 #ifdef CONFIG_3215

Re: [linuxsh-dev] Debianized packages of GNU tool chain

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

> As you know, I have maintained Debianized packages of them at
> ftp://ftp.m17n.org/pub/linux-sh/debian/.  Now I have built newer
> packages whose target is 'sh-linux-gnu', and they will be
> avaiable there soon.

I've uploaded.  Following packages are now available:

	binutils-sh-linux-gnu-000218.000615-1
	gcc-sh-linux-gnu-2.95.2.000615-1
	gcc-sh-linux-gnu-2.95.2.000228-1
	gdb-sh-linux-gnu-4.18.000615-1
	glibc-shl-linux-gnu-2.1.3.000515-1


NIIBE Yutaka wrote in the article "[linux-sh:00850] Re: compiling glibc-2.1.3":
> Takuzo O'hara wrote:
>  > Hello, I have got very similar problem as Ebihara's.
> 
> Umm... I believe that this is the issues on binutils on CVS.
> If you can't wait it to be fixed, please get it from ftp.m17n.org.
>   ftp://ftp.m17n.org/pub/super-h/bimutils-000218-000519.diff.gz
> 				binutils-0218.tar.bz2

It seemed that we could not build glibc-2.1.3 with the newest
gcc-core from CVS yet.  I've built glibc with older
gcc(2.95.2.000228).  This might not the problem of binutils, but
that of gcc-core.

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

Re: [linuxsh-dev] Assorted patches for Linux kernel, and the stub.

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

Mitch Davis wrote:
 > Please note that it is NOT the purpose of this patch to run the
 > kernel in the uncached P2 area (A0000000) - with this patch, the
 > kernel is still linked against and will still run in the cached
 > P1 area (80000000).  This patch only changes where the kernel is
 > loaded by a stub.
[...]
 > The problem we have faced a number of times was that kernel
 > downloading was not successful - even small programs would sometimes
 > not load properly.  (I had this problem at HP too, but not
 > involving Linux or our toolchain).  We traced this to the bootloader
 > not flushing the cache after the load.
 > 
 > As you know, using the "AT" linker directive makes it possible
 > link a program to run at a certain address (in this case, 80000000)
 > but be loaded at another address.  (In this case, A0000000).
 > Doing this ALWAYS fixed our problems.

OK, I didn't understand the issues, now have understood.  I don't
understand stub hits this problem, as it disables caches.

If there's problem, it's the bug of stub, I think.

I think that what you should change is the loader (stub or other).
Yes, you can work around the problem with this patch, but I don't
think this is solution.  If I were at the problem, I fix the loader so
that it flush the cache at the point needed.  For GDB stub (with cache
enabled), the point would be continue command handling where we need
to flush data cache so that instruction loaded from memory works fine.

 > And also, the details of flushing the cache are rather
 > processor-specific, something it would be best to keep out of the
 > stub.

Please look at the code, it already has the cache flushing code, as
breakpoints need this.

My point is: kernel image (vmlinux) is not just for the environment of
GDB stub (with cache enabled).  It could be used as other loader, used
by building zImage, or used when we wrote it into Flash ROM.  I think
that it's better not introducing other artifact here.
-- 

[linuxsh-dev] Ptrace

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

Hi David, 

David Mckay wrote:
 > Is anybody doing any work on ptrace and strace? I know that much of it has 
 > been implemented, but I can't seem to get gdb to debug user programs. 
 > 
 > I was going to start looking at this in the near future, but I don't want 
 > to duplicate work anybody else is doing.

That'll be certainly great contribution.  When I merged Kaz'
implementation, I couldn't finish all of them.  It sometimes work on
SH-3, it doesn't work for SH-4, yet.

I don't have time hacking on this these days.  Please go ahead.
-- 

Re: [linuxsh-dev] Assorted patches for Linux kernel, and the stub.

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

NIIBE Yutaka wrote:
> 
> Mitch Davis wrote:
>  > As Greg indicated in his earlier email, here are the diffs we
>  > have been working on.  There's a patch for the kernel code, and
>  > a patch for the stub.
> 
>  > x  Link script sets Load Memory Addresses so that kernel image
>  >    load bypasses the cache, to avoid cache problems.
> 
> No, this is backward.  If you have any problems, please send us bug
> report.  The changes like this just paper the bugs, and hide them.
> It's not the solution.  Major problem is it loses performance.
> Besides, I don't know the problem around cache issues, which is
> solved with this change.

Hi Niibe-san,

Please note that it is NOT the purpose of this patch to run the
kernel in the uncached P2 area (A0000000) - with this patch, the
kernel is still linked against and will still run in the cached
P1 area (80000000).  This patch only changes where the kernel is
loaded by a stub.

Running the kernel in the P2 area would surely compromise 
performance, and would indeed be a bad fix for a cache-related
problem! :-)

The problem we have faced a number of times was that kernel
downloading was not successful - even small programs would sometimes
not load properly.  (I had this problem at HP too, but not
involving Linux or our toolchain).  We traced this to the bootloader
not flushing the cache after the load.

As you know, using the "AT" linker directive makes it possible
link a program to run at a certain address (in this case, 80000000)
but be loaded at another address.  (In this case, A0000000).
Doing this ALWAYS fixed our problems.

> It seems for me that what to change is GDB stub, if needed.

It would be possible to change the stub so it has explicit code
to flush the cache after a transfer.  But the stub does not
know whether gdb on the host is sending a program, or setting
a variable.  Should it flush the whole cache every time
a variable is set?  Is it safe to do so without the kernel
knowing?  And also, the details of flushing the cache
are rather processor-specific, something it would be best to
keep out of the stub.

The other solution would be for the stub to mask incoming data so
they fall in the P2 area.  But I think this will not only 
mislead people, but may cause cache consistency problems
half-way through the run, because the variable is set past the
cached copy.

IMO, changing the Linux link file is a better way of determining
how the stub puts a loaded program into memory, and it avoids
these other problems.

Yes, storing into P2 will be a little slower than storing into
P1, but I believe the delay in waiting for data from a serial port
will be several orders of magnitude slower, so there won't be
any noticeable performance hit when loading the kernel.  (And
as I mentioned, none when running it).

Well, that's how we've been looking at it, but I'm only a beginner
with these things.  What do you think?  Would you prefer to see the
problem solved in another way?  Is there some issue which will
bite us with this approach, which we are not seeing?

I look forward to hearing your opinion.

Regards,

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

Re: [linuxsh-dev] Assorted patches for Linux kernel, and the stub.

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

NIIBE Yutaka wrote:
> 
> Mitch Davis wrote:
>  > As Greg indicated in his earlier email, here are the diffs we
>  > have been working on.  There's a patch for the kernel code, and
>  > a patch for the stub.
>
> Well done.  Please check them (except the Load Memory Addresses thing)
> in.  

Hello everyone,

I have now checked these changes in, except for the changes in
kernel/arch/sh/kernel.  CVS has left a lock there that needs 
clearing before the checkin can proceed.  (I've asked the
SourceForge people to fix it).

So as to not leave people with an uncompilable kernel, I am
attaching the changes from kernel/arch/sh/kernel in a patch
file.  Until the lock issue is resolved, please use this patch
to get a good copy of the most recent kernel source.

(Sorry about this necessary inconvenience)

Regards,

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