linuxsh-dev

[linuxsh-dev] SCI error handling

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

YAEGASHI Takeshi wrote:
 > Attached patch adds error handling to SCI.  Tested on SH-4 and
 > HP690.
[...]
 > Any comments?  I would check it in later.

Good job.  Two comments:

(1) Why do you set TEI handler?  It's not worth to add it for XXX_IRQ
    macros and the interrupt vectors, as we never use TEI interrupt in
    the driver.  The driver is not the specification of the SCI, it's
    the software which _use_ SCI.  If needed, people could get
    hardware manual.  Just add for BRI is enough, I think.

(2) Break handling
    I think that we could find break condition with SCI when some
    error occurs.  Then, call break handling routine.  Isn't it
    possible?
-- 

[linuxsh-dev] SCI error handling

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

Hello,

Attached patch adds error handling to SCI.  Tested on SH-4 and
HP690.

Unfortunately I cannot yet say that it behaves properly to all
the possible errors.  Anyway, BRI of SCIF handler was urgently
needed, because only one BRI crashed the kernel with the
repeated message such as "unexpected IRQ trap at vector 2a".

Any comments?  I would check it in later.

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

Re: [linuxsh-dev] RedBoot monitor - there's your tftp

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

>>>>> "YAEGASHI" == YAEGASHI Takeshi <yae...@ma...> writes:

YAEGASHI> I've already considered eCos since I'd thought about TFTP
YAEGASHI> boot.  An initial port for CqREEK SH-4(done by
YAEGASHI> ry...@at...) currently works fine on my own SH-7750
YAEGASHI> board (I was glad to see your name in eCos' sources :->).

eCos is my bread'n'butter :)

YAEGASHI> But I found it had only one diagnostic serial console and I
YAEGASHI> needed to port or write device drivers by myself, which
YAEGASHI> might be a little hard for me.  By eCos I plan to support
YAEGASHI> SCI/F of SH-4(interrupt driven driver), SMC91C96 Ethernet,
YAEGASHI> and possibly framebuffer and keyboard(as a diagnostic
YAEGASHI> console).

For the serial drivers you should be able to use the existing SCI and
SCIF drivers. As for the others, you'll have to write drivers yourself.

>> But now that you are bringing up TFTP boot capabilities, I thought
>> I would let you know about RedBoot. It only supports a single
>> PCMCIA netcard at the moment, but more are bound to follow.

YAEGASHI> Please let me know of them when released.

I'm sure they'll be announced on the eCos developer's list. 

YAEGASHI> BTW, I don't know about RedBoot, where I should go to get
YAEGASHI> it?

It's in the latest CVS repository. Please refer to the (preliminary)
documentation for further info.

Jesper

Re: [linuxsh-dev] BUG fix for VMALLOC-ed page

[Greg B. <gb...@po...>]

NIIBE Yutaka wrote:
> 
> My point is __not__:
>         BIOS should set PCMCIA, kernel should not know about it.
> 
> But:
>         If there're "wired" TLB entries, it's safe and better not
>         to destroy them.
> 
> Most likely case is booting from ATA-card or Compact Flash, and
> running on the file system on the card as if it's real ATA drive.  In
> that case, BIOS enables MMU and sets a wired entry for I/O access.

  Ok now I get it, when you boot from a PCMCIA medium you can't afford
to touch the TLB entries that are being used to load your kernel/initrd.
Duh.  I had the "boot from onboard FLASH" scenario wedged firmly in my
mind for some reason.

Greg.
-- 
These are my opinions not PPIs.

[linuxsh-dev] fix sh-sci

[SUGIOKA T. <su...@it...>]

Index: ChangeLog
===================================================================
RCS file: /cvsroot/linuxsh/kernel/ChangeLog,v
retrieving revision 1.90
diff -u -r1.90 ChangeLog
--- ChangeLog	2000/09/04 00:42:16	1.90
+++ ChangeLog	2000/09/04 11:08:42
@@ -1,3 +1,9 @@
+2000-09-04  SUGIOKA Toshinobu  <su...@it...>
+
+	* drivers/char/sh-sci.h (SCIF_ORER): Added.
+	* drivers/char/sh-sci.c (sci_er_interrupt): Handle overrun error for SH-4 SCIF.
+	(sci_set_baud): Set SCSMR bit0,1(clock select) every time.
+
 2000-09-04  NIIBE Yutaka  <gn...@m1...>
 
 	* arch/sh/mm/cache.c (cache_init): Re-initialize the cache system,

Index: drivers/char/sh-sci.c
===================================================================
RCS file: /cvsroot/linuxsh/kernel/drivers/char/sh-sci.c,v
retrieving revision 1.19
diff -u -r1.19 sh-sci.c
--- drivers/char/sh-sci.c	2000/08/28 08:49:36	1.19
+++ drivers/char/sh-sci.c	2000/09/04 10:50:05
@@ -344,6 +344,8 @@
 		if(t >= 256) {
 			sci_out(port, SCSMR, (sci_in(port, SCSMR) & ~3) | 1);
 			t >>= 2;
+		} else {
+			sci_out(port, SCSMR, sci_in(port, SCSMR) & ~3);
 		}
 		sci_out(port, SCBRR, t);
 		udelay((1000000+(baud-1)) / baud); /* Wait one bit interval */
@@ -582,6 +584,12 @@
 	/* Handle errors */
 	if (sci_in(port, SCxSR) & SCxSR_ERRORS(port))
 		sci_out(port, SCxSR, SCxSR_ERROR_CLEAR(port));
+
+#if defined(CONFIG_CPU_SUBTYPE_SH7750)
+	/* Handle SCIF overrun error */
+	if (port->type == PORT_SCIF && (ctrl_inw(SCLSR2) & SCIF_ORER) != 0)
+		ctrl_outw(0, SCLSR2);
+#endif
 
 	/* Kick the transmission */
 	sci_tx_interrupt(irq, ptr, regs);
Index: drivers/char/sh-sci.h
===================================================================
RCS file: /cvsroot/linuxsh/kernel/drivers/char/sh-sci.h,v
retrieving revision 1.15
diff -u -r1.15 sh-sci.h
--- drivers/char/sh-sci.h	2000/08/28 08:49:36	1.15
+++ drivers/char/sh-sci.h	2000/09/04 10:50:06
@@ -54,6 +54,7 @@
 # define SCSPTR1 0xffe0001c /* 8  bit SCI */
 # define SCSPTR2 0xFFE80020 /* 16 bit SCIF */
 # define SCLSR2  0xFFE80024 /* 16 bit SCIF */
+# define SCIF_ORER 0x0001   /* overrun error bit */
 # define SCSCR_INIT(port) (((port)->type == PORT_SCI) ? \
 	0x30 /* TIE=0,RIE=0,TE=1,RE=1 */ : \
 	0x38 /* TIE=0,RIE=0,TE=1,RE=1,REIE=1 */ )
----
SUGIOKA Toshinobu

Re: [linuxsh-dev] BUG fix for VMALLOC-ed page

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

My point is __not__:
	BIOS should set PCMCIA, kernel should not know about it.

But:
	If there're "wired" TLB entries, it's safe and better not
	to destroy them.

Most likely case is booting from ATA-card or Compact Flash, and
running on the file system on the card as if it's real ATA drive.  In
that case, BIOS enables MMU and sets a wired entry for I/O access.
-- 

Re: [linuxsh-dev] RedBoot monitor - there's your tftp

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

Hello Jesper,

In the article <ot1...@th...>,
Jesper Skov <js...@re...> wrote:

> We (as in the eCos/RedBoot engineers) have been plotting on trying to
> persuade you to try out RedBoot on your platforms. It is already
> ported to Hitachi's EDK7708 and the CqREEK 7708 and porting it to
> other platforms should not be too painful (I'm somewhat biased from
> having worked with it so long, but most people should be able to write
> a port in a week or two).

I've already considered eCos since I'd thought about TFTP boot.
An initial port for CqREEK SH-4(done by ry...@at...)
currently works fine on my own SH-7750 board (I was glad to see
your name in eCos' sources :->).

But I found it had only one diagnostic serial console and I
needed to port or write device drivers by myself, which might be
a little hard for me.  By eCos I plan to support SCI/F of
SH-4(interrupt driven driver), SMC91C96 Ethernet, and possibly
framebuffer and keyboard(as a diagnostic console).


> However, seeing as I'm still working on fleshing out the porting
> documentation (http://sources.redhat.com/ecos/docs-latest/porting/),
> and the RedBoot documentation is still a bit rough, asking anyone to
> try out eCos/RedBoot has seemed a little premature.

I think so.  Full documentation is desirable.


> But now that you are bringing up TFTP boot capabilities, I thought I
> would let you know about RedBoot. It only supports a single PCMCIA
> netcard at the moment, but more are bound to follow.

Please let me know of them when released.

BTW, I don't know about RedBoot, where I should go to get it?

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

Re: [linuxsh-dev] BUG fix for VMALLOC-ed page

[Greg B. <gb...@po...>]

NIIBE Yutaka wrote:
> 
> SH-4 TLB has feature to "wire" the entry (never been flush out, kind
> of executive class seat).

  ;-)

>  It could be used for accesssing Area 5 or
> Area 6 as PCMCIA. 

  Yep.

> I think that it's fair enough to allocate wired
> entries for PCMCIA.

  If you're using PCMCIA, yes.  But the BIOS does not (in general)
know whether the kernel will want to use the PCMCIA space, e.g. if 
no cards are inserted, or all cards are removed after boot.  In that
case you've got perhaps 6 ( cards * common, attribute, and I/O) TLB
entries out of a system total of 64 sitting around doing nothing while
the kernel is fielding extra page faults because the TLB is missed
slightly more often.

>  If accessing I/O would cause TLB-miss, it's hard
> for device drivers writer to implement routines.  Most drivers are
> not ready, I guess, and not required to be so.

  Good point, it might do bad things to timing I guess.

  But couldn't the PCMCIA TLB entries be wired into the TLB as a side
effect of the driver calling CardServices(RequestIO,) ?  I assume this
somehow trickles down into modifying TLB entries, because PCMCIA drivers can
request the mappings to be 8 or 16 bit which needs to be reflected in
the SA bits.

> When some machine designer implements hardware initialization routine
> in BIOS to enable "wired" TLB entries, we should not ignore these
> entries.  We should be conservative here.
> 
> I think that there're certainly such cases, it's very similar to BSC
> setting.

  So the idea is, instead of just writing a known value to MMUCR you
first check and preserve the URB bits, thus giving the BIOS the opportunity
to hardcode some TLB entries for ever?

> 
> This is our point.  See?

  Well I think I understand the reasoning now, but I'm still not sure I agree.

Greg.
-- 
These are my opinions not PPIs.

Re: [linuxsh-dev] BUG fix for VMALLOC-ed page

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

With SH-4, we need TLB to access PCMCIA, specifically, SA-bits and
TC-bit is needed.  Please look at the hardware manual for the
description of PTEA register and SA-bits and TC-bit of TLB.
-- 

Re: [linuxsh-dev] BUG fix for VMALLOC-ed page

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

SH-4 TLB has feature to "wire" the entry (never been flush out, kind
of executive class seat).  It could be used for accesssing Area 5 or
Area 6 as PCMCIA.  I think that it's fair enough to allocate wired
entries for PCMCIA.  If accessing I/O would cause TLB-miss, it's hard
for device drivers writer to implement routines.  Most drivers are
not ready, I guess, and not required to be so.

When some machine designer implements hardware initialization routine
in BIOS to enable "wired" TLB entries, we should not ignore these
entries.  We should be conservative here.

I think that there're certainly such cases, it's very similar to BSC
setting.

This is our point.  See?
-- 

[linuxsh-dev] RedBoot monitor - there's your tftp

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

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

NIIBE> * boot from net (TFTP?)

<advocate>

I'm doing this at the moment - using the eCos based Red Hat embedded
monitor called 'RedBoot'.

eCos information can be found here: 
http://sources.redhat.com/ecos/
and preliminary RedBoot information is available off this page:
http://sources.redhat.com/ecos/docs-latest/

The monitor also provides flash programming (assuming the board
supports it) and GDB debugging, and has provision for the early printk
magic (but that hasn't been wired up yet for the calls used by
Linux/SH). There's also some issues with argument passing that need to
be sorted out.



We (as in the eCos/RedBoot engineers) have been plotting on trying to
persuade you to try out RedBoot on your platforms. It is already
ported to Hitachi's EDK7708 and the CqREEK 7708 and porting it to
other platforms should not be too painful (I'm somewhat biased from
having worked with it so long, but most people should be able to write
a port in a week or two).

However, seeing as I'm still working on fleshing out the porting
documentation (http://sources.redhat.com/ecos/docs-latest/porting/),
and the RedBoot documentation is still a bit rough, asking anyone to
try out eCos/RedBoot has seemed a little premature.

But now that you are bringing up TFTP boot capabilities, I thought I
would let you know about RedBoot. It only supports a single PCMCIA
netcard at the moment, but more are bound to follow.

</advocate>

Cheers,
Jesper

Re: [linuxsh-dev] BUG fix for VMALLOC-ed page

[Greg B. <gb...@po...>]

NIIBE Yutaka wrote:
> 
>  > > * freeze/snapshot feature ---> dump .data & .bss, reload, kick the driver...
>  >
>  >   Sorry, I don't understand what this means.
> 
> You know, some nortebook computer has the feature of "Hibernation",
> let the RAM image go into the disk.  This entry is for that.
  
  Is that .data and .bss (and stack) of all processes and the kernel?
That would be a very useful feature, especially if you could power down
all modules and put the processor into Standby mode.

>  > > * PCMCIA(SH-4) TLB wiring, conservative TLB initialization
>  >
>  >   And this?
> 
> To use PCMCIA feature on SH-4, we need to use MMU, because some bits
> are assigned to the bit on TLB to access PCMCIA (area 5 and 6).

  Yes, the C (cached) and WT (write-through) bits.

>  We
> think that such initialization of the specific hardware (the bus) is
> the job of initialization routine (BIOS).

  Within reason.  For example, you don't expect the BIOS to handle
interrupts, so that part of the initialisation is done by the kernel
itself.  So the BIOS doesn't do everything necessary to initialise.

>  Currently, the kernel
> assumes BIOS doesn't use MMU and flush out all the TLB on boot, which
> is not good.

  I think flushing all TLB entries on boot is a good idea, because it
puts the TLB into a known good state.  Otherwise the kernel has to somehow
figure out which TLB entries are "good" and which are possibly left over
from earlier kernel or BIOS mappings and should be thrown away.  If you're
going to go to that much effort you might as well re-construct the TLB
from scratch, it will be safer.

  Perhaps a better approach would be to just add PTEs for the PCMCIA
space to the kernel PGD, so they can be loaded into the TLB as necessary
using the usual page-fault mechanism.  Or am I missing something important?

>  >   Yes!  BTW can you explain the current status of binutils & glibc -- is
>  > libc.so supposed to link with current versions or am I doing something wrong?
> 
> For Binutils and GCC, the changes are already incorporated into
> current development repository.  Now we need to test and check again.

  Ok.

>  >   I noticed the absence of any mention of cache problems in the list -- does
>  > this mean they've all been solved?
> 
> I think that I've done the fix.  Next, we need to keep up the transition
> of the development kernel, please look at Documentation/cachetlb.txt in
> test8-pre1.

  Ok, I'll take a look at that.


Greg.
-- 
These are my opinions not PPIs.

[linuxsh-dev] BUG fix for VMALLOC-ed page

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

NIIBE Yutaka wrote:
 > ------- TODO 2000-09-03

* More generic kernel (1) --- Relocate on boot

Let build vmlinux.o which remains relocation for symbols.
Then, let the loader fix-up the relocations, with the information
where the MEMORY_START begins.

* More generic kernel (2) --- Detect the difference between SH7708 and SH7707/9

Check at check_bugs if 0xA4000000 has same value of INTEVT.  If it's
the same, it might be SH7707/SH7709.  Fix-up entry.S.
-- 

Re: [linuxsh-dev] BUG fix for VMALLOC-ed page

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

Greg Banks wrote:
 > > * x86 emulation
 > 
 >   Why?

It's easy to make ISA bridge.  However, some ISA board (or PCI board)
has initialization program written in x86.  For example, most ISA VGA
adapter has ROM with the board, and we can't use it.  Well, low
priority, though.

 > > * freeze/snapshot feature ---> dump .data & .bss, reload, kick the driver...
 > 
 >   Sorry, I don't understand what this means.

You know, some nortebook computer has the feature of "Hibernation", 
let the RAM image go into the disk.  This entry is for that.

 > > * MTD device enhancement, optimize flash write
 > 
 >   Could you please explain this?

Takeshi Yaegashi is using MTD intensively, and he found that
it's need more tweak, especially for "write" operation.

 > > * PCMCIA(SH-4) TLB wiring, conservative TLB initialization
 > 
 >   And this?

To use PCMCIA feature on SH-4, we need to use MMU, because some bits
are assigned to the bit on TLB to access PCMCIA (area 5 and 6).  We
think that such initialization of the specific hardware (the bus) is
the job of initialization routine (BIOS).  Currently, the kernel
assumes BIOS doesn't use MMU and flush out all the TLB on boot, which
is not good.

 >   Yes!  BTW can you explain the current status of binutils & glibc -- is
 > libc.so supposed to link with current versions or am I doing something wrong?

For Binutils and GCC, the changes are already incorporated into
current development repository.  Now we need to test and check again.

 >   I noticed the absence of any mention of cache problems in the list -- does
 > this mean they've all been solved?

I think that I've done the fix.  Next, we need to keep up the transition
of the development kernel, please look at Documentation/cachetlb.txt in
test8-pre1.
-- 

Re: [linuxsh-dev] BUG fix for VMALLOC-ed page

[SUGIOKA T. <su...@it...>]

At 10:53 00/09/05 +1100, Greg Banks wrote:
>NIIBE Yutaka wrote:
>> 
>> Sugioka-san pointed me that there's a problem using lsmod, and it caused
>> by vmalloced page.  Here's the patch.  Basically, we set "SH" bit on PTE
>> for the vmalloced pages.
>
>  Looks ok to me.  So let me guess -- lsmod was causing an oops because a
>page vmalloc()ed in the insmod process context was not mapped for the
>lsmod process context because the vmalloc()ed PTEs weren't marked shared?
>

I guessed,
interrupt handler in the kernel module loaded by insmod should be executed 
in no-context. and other part of the module is shared by all process.
so ASID should not be used by MMU in kernel modules.
otherwise unnecessary TLB entry may be used by modules.

I'm not so sure, but oops would not be caused by modules, because 
__do_page_fault1()
should find proper TLB entry and then do_page_fault() is not executed.
----
SUGIOKA Toshinobu

Re: [linuxsh-dev] BUG fix for VMALLOC-ed page

[Greg B. <gb...@po...>]

NIIBE Yutaka wrote:
> 
> Sugioka-san pointed me that there's a problem using lsmod, and it caused
> by vmalloced page.  Here's the patch.  Basically, we set "SH" bit on PTE
> for the vmalloced pages.

  Looks ok to me.  So let me guess -- lsmod was causing an oops because a
page vmalloc()ed in the insmod process context was not mapped for the
lsmod process context because the vmalloc()ed PTEs weren't marked shared?

> 
> Besides, here's the list of TODO, which is the result of the meeting
> in Japan (Kaz, Toshinobu, Toshiharu, Takashi & Takeshi).

  Good work, guys.

> 
> ------- TODO 2000-09-03
> * Implement shutdown, reboot
>   ---> BIOS call? Jump to 0xa0000000?

  Good idea, I've been thinking of doing it myself (because I'm sick of
reaching over to the board to push the reset button when I could just type
`reboot').  I'd prefer a BIOS call (or three, one each for machine_halt()
machine_power_down() and machine_reboot()), so that the BIOS can do special
hardware-specific things before shutting down or rebooting.

> 
> * Implement profile functionality: arch/sh/time.c

  Yes, this needs to be done.

> 
> * Implement /dev/rtc with SH's RTC

  Good.

> * x86 emulation

  Why?

> * SH emulation by x86

  This would be a nice feature in the medium-to-long term, so that
you could build an entire cross-development platform without actual
hardware.

> * freeze/snapshot feature ---> dump .data & .bss, reload, kick the driver...

  Sorry, I don't understand what this means.

> * MTD device enhancement, optimize flash write

  Could you please explain this?

> * PCMCIA(SH-4) TLB wiring, conservative TLB initialization

  And this?

> * boot from net (TFTP?)

  That would be nice.  It would be great to be able to put sh-ipl into
a mode where it used DHCP and TFTP to download kernel and initrd images;
that would really speed up kernel development compared to uploading via
serial or futzing about with IDE.

> * toolchain + glibc once again with standard GNU

  Yes!  BTW can you explain the current status of binutils & glibc -- is
libc.so supposed to link with current versions or am I doing something wrong?

> * USB

  This would be good in the medium term.


  I noticed the absence of any mention of cache problems in the list -- does
this mean they've all been solved?

  I also noticed no power management.  As a significant proportion of SH
machines are handhelds, I would have thought this would be important.

  You didn't mention any prioritisation, so I'll feel free to suggest some.
From most to least important:

 *  toolchain/glibc
 *  cache problems
 *  RTC
 *  power management
 *  BIOS shutdown
 *  boot from net
 *  USB
 *  SH emulation


Greg.
-- 
These are my opinions not PPIs.

[linuxsh-dev] BUG fix for VMALLOC-ed page

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

Sugioka-san pointed me that there's a problem using lsmod, and it caused
by vmalloced page.  Here's the patch.  Basically, we set "SH" bit on PTE
for the vmalloced pages.

Besides, here's the list of TODO, which is the result of the meeting
in Japan (Kaz, Toshinobu, Toshiharu, Takashi & Takeshi).

------- TODO 2000-09-03
* Implement shutdown, reboot
  ---> BIOS call? Jump to 0xa0000000?

* Implement profile functionality: arch/sh/time.c

* Implement /dev/rtc with SH's RTC

* Merge of floppy driver

* Kernel PGD optimization

* kernel math emulation
* x86 emulation
* SH emulation by x86
* freeze/snapshot feature ---> dump .data & .bss, reload, kick the driver...
* MTD device enhancement, optimize flash write
* PCMCIA(SH-4) TLB wiring, conservative TLB initialization
* boot from CDROM
* boot from net (TFTP?)
* toolchain + glibc once again with standard GNU
* USB
* PCI
------------

----------------------
2000-09-03  NIIBE Yutaka  <gn...@m1...>

	* include/asm-sh/pgtable.h (_PAGE_PRESENT): Use hardware V-bit.
	(_PAGE_U0_SHARED): New macro to implement user space shared page.
	(_PAGE_HW_SHARED): We need this hardware setting.
	(_PAGE_FLAGS_HARDWARE_DEFAULT): Removed.
	(_PAGE_FLAGS_HARDWARE_MASK): Include SZ-bit, SH-bit and WT-bit.
	(_PAGE_FLAGS_HARD): Hardware PTE flags setting (for SZ=4KB).
	(_PAGE_SHARED): Use U0_SHARED for SH-4, HW_SHARED for SH-3, because 
	there's alias issue on SH-4.
	(PAGE_NONE, PAGE_SHARED, PAGE_COPY, PAGE_READONLY, PAGE_KERNEL,
	PAGE_KERNEL_RO): Includd _PAGE_FLAGS_HARD.

	(PAGE_KERNEL, PAGE_KERNEL_RO): Include _PAGE_HW_SHARED.

	(_PAGE_ACCESSED, _PAGE_PROTNONE): Layout changed.
	(SWP_TYPE, SWP_OFFSET, SWP_ENTRY): Likewise.

	* arch/sh/mm/fault.c (update_mmu_cache): Don't OR the hardware value
	to PTE.  It's now already included.

Index: arch/sh/mm/fault.c
===================================================================
RCS file: /cvsroot/linuxsh/kernel/arch/sh/mm/fault.c,v
retrieving revision 1.20
diff -u -r1.20 fault.c
--- arch/sh/mm/fault.c	2000/09/01 01:11:25	1.20
+++ arch/sh/mm/fault.c	2000/09/03 03:04:40
@@ -326,7 +326,6 @@
 	/* Set PTEL register */
 	pteval = pte_val(pte);
 	pteval &= _PAGE_FLAGS_HARDWARE_MASK; /* drop software flags */
-	pteval |= _PAGE_FLAGS_HARDWARE_DEFAULT; /* add default flags */
 	ctrl_outl(pteval, MMU_PTEL);
 
 	/* Load the TLB */
Index: include/asm-sh/pgtable.h
===================================================================
RCS file: /cvsroot/linuxsh/kernel/include/asm-sh/pgtable.h,v
retrieving revision 1.9
diff -u -r1.9 pgtable.h
--- include/asm-sh/pgtable.h	2000/09/01 01:11:25	1.9
+++ include/asm-sh/pgtable.h	2000/09/03 03:04:41
@@ -92,41 +92,40 @@
 #define VMALLOC_VMADDR(x) ((unsigned long)(x))
 #define VMALLOC_END	P4SEG
 
-#define _PAGE_PRESENT	0x001  /* software: page is present */
-#define _PAGE_ACCESSED	0x002  /* software: page referenced */
+/*			0x001     WT-bit on SH-4, 0 on SH-3 */
+#define _PAGE_HW_SHARED	0x002  /* SH-bit  : page is shared among processes */
 #define _PAGE_DIRTY	0x004  /* D-bit   : page changed */
 #define _PAGE_CACHABLE	0x008  /* C-bit   : cachable */
-/*		 	0x010     SZ-bit  : size of page */
+/*			0x010     SZ0-bit : Size of page */
 #define _PAGE_RW	0x020  /* PR0-bit : write access allowed */
 #define _PAGE_USER	0x040  /* PR1-bit : user space access allowed */
-#define _PAGE_PROTNONE	0x080  /* software: if not present */
-/*			0x100     V-bit   : page is valid */
-#define _PAGE_SHARED    0x200  /* software: page is shared */
-/*			0x400     can be used as software flag */
-/*			0x800     can be used as software flag */
+/*			0x080     SZ1-bit : Size of page (on SH-4) */
+#define _PAGE_PRESENT	0x100  /* V-bit   : page is valid */
+#define _PAGE_PROTNONE	0x200  /* software: if not present  */
+#define _PAGE_ACCESSED 	0x400  /* software: page referenced */
+#define _PAGE_U0_SHARED 0x800  /* software: page is shared in user space */
 
-#if defined(__sh3__)
 /* Mask which drop software flags */
-#define _PAGE_FLAGS_HARDWARE_MASK	0x1ffff06c
-/* Flags defalult: SZ=1 (4k-byte), C=0 (non-cachable), SH=0 (not shared) */
-#define _PAGE_FLAGS_HARDWARE_DEFAULT	0x00000110
+#define _PAGE_FLAGS_HARDWARE_MASK	0x1ffff1ff
+/* Hardware flags: SZ=1 (4k-byte) */
+#define _PAGE_FLAGS_HARD		0x00000010
+
+#if defined(__sh3__)
+#define _PAGE_SHARED	_PAGE_HW_SHARED
 #elif defined(__SH4__)
-/* Mask which drops software flags */
-#define _PAGE_FLAGS_HARDWARE_MASK	0x1ffff06c
-/* Flags defalult: SZ=01 (4k-byte), C=0 (non-cachable), SH=0 (not shared), WT=0 */
-#define _PAGE_FLAGS_HARDWARE_DEFAULT	0x00000110
+#define _PAGE_SHARED	_PAGE_U0_SHARED
 #endif
 
 #define _PAGE_TABLE	(_PAGE_PRESENT | _PAGE_RW | _PAGE_USER | _PAGE_ACCESSED | _PAGE_DIRTY)
 #define _KERNPG_TABLE	(_PAGE_PRESENT | _PAGE_RW | _PAGE_ACCESSED | _PAGE_DIRTY)
 #define _PAGE_CHG_MASK	(PTE_MASK | _PAGE_ACCESSED | _PAGE_CACHABLE | _PAGE_DIRTY | _PAGE_SHARED)
 
-#define PAGE_NONE	__pgprot(_PAGE_PROTNONE | _PAGE_CACHABLE |_PAGE_ACCESSED)
-#define PAGE_SHARED	__pgprot(_PAGE_PRESENT | _PAGE_RW | _PAGE_USER | _PAGE_CACHABLE |_PAGE_ACCESSED | _PAGE_SHARED)
-#define PAGE_COPY	__pgprot(_PAGE_PRESENT | _PAGE_USER | _PAGE_CACHABLE | _PAGE_ACCESSED)
-#define PAGE_READONLY	__pgprot(_PAGE_PRESENT | _PAGE_USER | _PAGE_CACHABLE | _PAGE_ACCESSED)
-#define PAGE_KERNEL	__pgprot(_PAGE_PRESENT | _PAGE_RW | _PAGE_CACHABLE | _PAGE_DIRTY | _PAGE_ACCESSED)
-#define PAGE_KERNEL_RO	__pgprot(_PAGE_PRESENT | _PAGE_CACHABLE | _PAGE_DIRTY | _PAGE_ACCESSED)
+#define PAGE_NONE	__pgprot(_PAGE_PROTNONE | _PAGE_CACHABLE |_PAGE_ACCESSED | _PAGE_FLAGS_HARD)
+#define PAGE_SHARED	__pgprot(_PAGE_PRESENT | _PAGE_RW | _PAGE_USER | _PAGE_CACHABLE |_PAGE_ACCESSED | _PAGE_SHARED | _PAGE_FLAGS_HARD)
+#define PAGE_COPY	__pgprot(_PAGE_PRESENT | _PAGE_USER | _PAGE_CACHABLE | _PAGE_ACCESSED | _PAGE_FLAGS_HARD)
+#define PAGE_READONLY	__pgprot(_PAGE_PRESENT | _PAGE_USER | _PAGE_CACHABLE | _PAGE_ACCESSED | _PAGE_FLAGS_HARD)
+#define PAGE_KERNEL	__pgprot(_PAGE_PRESENT | _PAGE_RW | _PAGE_CACHABLE | _PAGE_DIRTY | _PAGE_ACCESSED | _PAGE_HW_SHARED | _PAGE_FLAGS_HARD)
+#define PAGE_KERNEL_RO	__pgprot(_PAGE_PRESENT | _PAGE_CACHABLE | _PAGE_DIRTY | _PAGE_ACCESSED | _PAGE_HW_SHARED | _PAGE_FLAGS_HARD)
 
 /*
  * As i386 and MIPS, SuperH can't do page protection for execute, and
@@ -245,11 +244,15 @@
 			     unsigned long address, pte_t pte);
 
 /* Encode and de-code a swap entry */
-#define SWP_TYPE(x)			(((x).val >> 1) & 0x3f)
-#define SWP_OFFSET(x)			((x).val >> 8)
-#define SWP_ENTRY(type, offset)		((swp_entry_t) { ((type) << 1) | ((offset) << 8) })
-#define pte_to_swp_entry(pte)		((swp_entry_t) { pte_val(pte) })
-#define swp_entry_to_pte(x)		((pte_t) { (x).val })
+/*
+ * NOTE: We should set ZEROs at the position of _PAGE_PRESENT
+ *       and _PAGE_PROTONOE bits
+ */
+#define SWP_TYPE(x)		((x).val & 0xff)
+#define SWP_OFFSET(x)		((x).val >> 10)
+#define SWP_ENTRY(type, offset)	((swp_entry_t) { (type) | ((offset) << 10) })
+#define pte_to_swp_entry(pte)	((swp_entry_t) { pte_val(pte) })
+#define swp_entry_to_pte(x)	((pte_t) { (x).val })
 
 #define module_map      vmalloc
 #define module_unmap    vfree

Re: [linuxsh-dev] GDB web page

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

Greg

Many thanks for the comments.

On Sep 1,  4:43pm, gb...@po... wrote:
> Subject: Re: [linuxsh-dev] GDB web page
> Stuart Menefy wrote:
>   Your documentation is very good...easy to read, accurate and up-to-date.
> Well, mostly, I've got a few comments (see below).  Actually I was wondering
> if I could basically subsume large chunks of it into the FAQ (with full credit
> of course!) ?  The idea is that someone could print out the FAQ and have
> almost all the info they need in one document.  Given the current state of
> the FAQ it needs a major clue-transfusion.

Feel free to use it. I agree it would be great to have an 'all in one
place' description of how to get started, but I'm not sure a FAQ is the
right place. If we can use the web pages as more of a tutorial, or a
getting started guide, then the FAQ would only need to contain pointers
to these, or pieces of information which don't fit cleanly elsewhere.

Plus I object to copying things on principle, as I always forget to
update one of the copies!

> 
>   Anyway, my comments on gdb.php:
> 
> 1.  "Note 'GDB Stub kernel debug' and 'Early printk support' are mutually
>      exclusive."  AFAICT this is not true, at least it's not supposed to be.
>      If something in the code or doco suggests that, I need to fix it!

That was just my experience. With both enabled I was getting plain
text in the middle of GDB messages, causing the CRCs to be wrong, and
GDB on the host ignored the message.

> 2.   In the 3rd-last paragraph, it talks about the stub detaching from 
>      the host gdb.  Perhaps it might be a good idea to mention the
>      message gdb gives, which is probably quite confusing for newbies.

Good point, I'll add something.

Thanks

Stuart

Re: [linuxsh-dev] GDB web page

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

>>>>> "Greg" == Greg Banks <gb...@po...> writes:
Greg>   BTW when building a debugging kernel, has anyone tried
Greg> removing the -fomit-frame-pointer flag from the compile?  I
Greg> believe this will enable gdb to show a kernel stack trace.  The
Greg> ARM port has a config variable, CONFIG_FRAME_POINTER, to do
Greg> this.


I have the below in my Makefile:

# Strip -fomit-frame-pointer and add -g when compiling with GDB support
ifeq ($(CONFIG_DEBUG_KERNEL_WITH_GDB_STUB),y)
CFLAGS := $(CPPFLAGS) -Wall -Wstrict-prototypes -O1 -g
endif


If built with -fomit-frame-pointer GDB crashes in a second when it
tries to unwind the stack for its own clueless purposes.

Jesper

Re: [linuxsh-dev] GDB web page

[Greg B. <gb...@po...>]

Stuart Menefy wrote:
> 
> Folks
> 
> I've added a few pages to the web site describing how to use GDB to boot
> and debug a target system.
> 
> They should appear at:
>   http://linuxsh.sourceforge.net/docs/gdb.php3
> 
> (Greg, is there any way to kick the web site building process?)

  Sort of.  You can run the ~gnb/bin/update-web shell script, but
because of the cheap&nasty way I wrote it there some problems with
permissions if anyone other than me does it.  Fixing this is somewhere
on the TODO list...

> 
> Any comments welcome.
> 

  Your documentation is very good...easy to read, accurate and up-to-date.
Well, mostly, I've got a few comments (see below).  Actually I was wondering
if I could basically subsume large chunks of it into the FAQ (with full credit
of course!) ?  The idea is that someone could print out the FAQ and have
almost all the info they need in one document.  Given the current state of
the FAQ it needs a major clue-transfusion.

  Anyway, my comments on gdb.php:

1.  "Note 'GDB Stub kernel debug' and 'Early printk support' are mutually
     exclusive."  AFAICT this is not true, at least it's not supposed to be.
     If something in the code or doco suggests that, I need to fix it!

2.   In the 3rd-last paragraph, it talks about the stub detaching from 
     the host gdb.  Perhaps it might be a good idea to mention the
     message gdb gives, which is probably quite confusing for newbies.

  BTW when building a debugging kernel, has anyone tried removing the
-fomit-frame-pointer flag from the compile?  I believe this will enable
gdb to show a kernel stack trace.  The ARM port has a config variable,
CONFIG_FRAME_POINTER, to do this.

Greg.
-- 
These are my opinions not PPIs.

Re: [linuxsh-dev] Fix bad fault handling

[<su...@it...>]

At 10:14 00/09/01 +0900, NIIBE Yutaka wrote:

>Besides, Sugioka-san, could I ask your cooperation too?  I think that
>you have qualified talent to hack on the CVS.

Thanks. I will join you with pleasure.

[linuxsh-dev] Fix bad fault handling

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

Jesper Skov wrote:
 > +2000-08-31  Jesper Skov  <js...@re...>
 > +
 > +	* arch/sh/mm/fault.c (__do_page_fault): Fixed bug that caused
 > +	infinite cycle of faults when writing to a page for the first time.
 > +

Thanks, installed.  The typo one too.

Jesper, if you don't mind, please get write privilege of CVS.

Besides, Sugioka-san, could I ask your cooperation too?  I think that
you have qualified talent to hack on the CVS.
-- 

[linuxsh-dev] GDB web page

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

Folks

I've added a few pages to the web site describing how to use GDB to boot
and debug a target system.

They should appear at:
  http://linuxsh.sourceforge.net/docs/gdb.php3

(Greg, is there any way to kick the web site building process?)

Any comments welcome.

Stuart

[linuxsh-dev] Fix typo

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

diff -urN --exclude-from=/home/jskov/lib/diff-excludes -P /opt/RH-linuxsh/devo/l
inux/linux-sh/include/asm-sh/pgtable.h ./include/asm-sh/pgtable.h
--- /opt/RH-linuxsh/devo/linux/linux-sh/include/asm-sh/pgtable.h        Wed Aug 
30 16:47:01 2000
+++ ./include/asm-sh/pgtable.h  Mon Aug 14 11:36:57 2000
@@ -130,7 +130,7 @@
 
 /*
  * As i386 and MIPS, SuperH can't do page protection for execute, and
- * considers that the same are read.  Also, write permissions imply
+ * considers that the same as a read.  Also, write permissions imply
  * read permissions. This is the closest we can get..  
  */
 

[linuxsh-dev] Fix bad fault handling

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

--- ../../../RH-STAMPED/kernel/ChangeLog	Wed Aug 30 11:18:29 2000
+++ ChangeLog	Thu Aug 31 12:40:59 2000
@@ -1,3 +1,8 @@
+2000-08-31  Jesper Skov  <js...@re...>
+
+	* arch/sh/mm/fault.c (__do_page_fault): Fixed bug that caused
+	infinite cycle of faults when writing to a page for the first time.
+
 2000-08-30  NIIBE Yutaka  <gn...@m1...>
 
 	* arch/sh/kernel/head.S: Move the alignment expression before .text
--- ../../../RH-STAMPED/kernel/arch/sh/mm/fault.c	Mon Aug 21 10:56:34 2000
+++ arch/sh/mm/fault.c	Thu Aug 31 12:36:38 2000
@@ -261,7 +261,7 @@
 		return 1;
 
 	if (writeaccess)
-		pte_mkdirty(entry);
+		entry = pte_mkdirty(entry);
 	entry = pte_mkyoung(entry);
 #if defined(__SH4__)
 	/*