linuxsh-dev

Re: [linuxsh-dev] epson card e09

[stephan k. <sk...@sy...>]

fabio giovagnini wrote:

> Were you able to boot with sh-ipl+g and sh-lilo?

these are the next steps on my list. until now i am able to run my own
sbr which loads stuff from cf and starts it.
 
> If  I'll know somthing I'll write to you.

i'll do so too.

stephan knabe
mailto: sk...@sy...

Re: [linuxsh-dev] epson card e09

[fabio g. <fg...@ti...>]

I'm trying too.
Were you able to boot with sh-ipl+g and sh-lilo?

If  I'll know somthing I'll write to you.

Regards.
 
----- Original Message ----- 
From: "stephan knabe" <sk...@sy...>
To: <lin...@li...>
Sent: Tuesday, November 20, 2001 12:03 PM
Subject: [linuxsh-dev] epson card e09


> Hi everybody,
> I try to use Linux on a Epson Card E09 with the Epson Card-E09A
> evaluation board.
> the E09A-card uses a sh7709a, the board has different companion-chips
> for other hardware (16550 compatible, ne2000, etc.).
> 
> has anybody some experiences with that?
> 
> after a few weeks of learning by coding, i am able to run some code
> instead of the original wince-sbr.
> it is stored on a compact flash pcmcia-card, i can read now. i also can
> access a serial connection (16550).
> 
> what has to be done to get a linux kernel running (i already use a
> cross-toolchain ?
> what kernel (and what patches) i recommended ?
> what do i have to write by my own (initialisations, etc.) ?
> are there some documentations about this (i.e. about boot-loaders and
> the booting-process)?
> 
> 
> stephan knabe
> mailto: sk...@sy...
> 
> _______________________________________________
> linuxsh-dev mailing list
> lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsh-dev
> 

[linuxsh-dev] epson card e09

[stephan k. <sk...@sy...>]

Hi everybody,
I try to use Linux on a Epson Card E09 with the Epson Card-E09A
evaluation board.
the E09A-card uses a sh7709a, the board has different companion-chips
for other hardware (16550 compatible, ne2000, etc.).

has anybody some experiences with that?

after a few weeks of learning by coding, i am able to run some code
instead of the original wince-sbr.
it is stored on a compact flash pcmcia-card, i can read now. i also can
access a serial connection (16550).

what has to be done to get a linux kernel running (i already use a
cross-toolchain ?
what kernel (and what patches) i recommended ?
what do i have to write by my own (initialisations, etc.) ?
are there some documentations about this (i.e. about boot-loaders and
the booting-process)?


stephan knabe
mailto: sk...@sy...

[linuxsh-dev] New in the group

[Fabio G. <fg...@ti...>]

Hi everybody.

I'm Fabio Giovagnini from Italy and I'd like to begin the porting of LinuxSH 
to Epson SHCard, a sh-3 7709A based card.
So I have some questions:
1) in linuxsh.sourceforge.net I can find CVS-web with:
 	kernel/ 
	linux/ 
	linuxsh-web/ 
	sh-boot/ 

Could anyone describe the meaning of these ones (kernel is the shlinux 
kernel, if I understand good);

2) If I execute:
	cvs -d:pserver:ano...@cv...:/cvsroot/linuxsh login 	
		<enter>	
	 cvs -z3 -d:pserver:ano...@cv...:/cvsroot/linuxsh 		
		co kernel
		<enter>

Am I sure to get the latest CVS linux Sh kernel ?

3) Is the How To at http://linuxsh.sourceforge.net/docs/building-source.php3 
the latest one about buliding linux SH from scratch ?

4) Is anyone using the SED 1355 framebuffer device?

5) Can I use the gcc-core 3.0.1 the compile the kernel?

Thanks a lot.

Ing. Fabio Giovagnini
Embedded solution manager
WALBRO TDD.
fg...@ti...

[linuxsh-dev] Re: [linux-sh:01999] New Drop-In Tree

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

Jeremy Siegel wrote:
> 
> Hi folks,
> 
> After conferring with Paul Mundt, who pulled down a tarball of
> the CVS repository for me, I've generated a new tarball for the
> linux drop-in tree by simply pruning the old kernel module.

  Sounds good.

Greg.
-- 
the price of civilisation today is a courageous willingness to prevail,
with force, if necessary, against whatever vicious and uncomprehending
enemies try to strike it down.	   - Roger Sandall, The Age, 28Sep2001.

[linuxsh-dev] New Drop-In Tree

[Jeremy S. <js...@mv...>]

Hi folks,

After conferring with Paul Mundt, who pulled down a tarball of
the CVS repository for me, I've generated a new tarball for the
linux drop-in tree by simply pruning the old kernel module.  It
preserves all the history, including Attic directories for SH in
arch and asm.  As a project admin, Paul will send SourceForge
a request to (a) move the current linux module to linux-old,
and (b) untar the new linux module.  After that's done I'll add
the scripts and and the AGAINST file (and then try an update
to 2.4.14, but more on that later.)

If anyone has a serious problem with this, yell ASAP...

--Jeremy Siegel

[linuxsh-dev] SuperH SH-5

[Boyd M. <boy...@st...>]

SuperH, Inc. would like to announce the availability of the the SuperH
64 bit RISC Series Architecture Manuals. These define the architecture,
instruction sets and implementation details for the SH-5 CPU core.

The SH-5 is the first 64-bit architecture in the SuperH series and
follows on from the popular 32 bit SH-4 implemented by Hitachi and
STMicroelectronics in their range of microcontrollers. The SH-4 and SH-5
CPU cores are now owned by SuperH, Inc. and licenced to various vendors
(including ST and Hitachi) who will announce their own implementations
of the SH-4 and SH-5.

The manuals released are:
SH-5 CPU Core, Volume 1: Architecture
SH-5 CPU Core, Volume 2: SHMedia
SH-5 CPU Core, Volume 3: SHcompact
SH-5 CPU Core, Volume 4: Implementation

The first 3 volumes specify the generic CPU architecture. This includes
the instruction set architecture (ISA) and the mechanisms used for CPU
control and configuration. These volumes describe the properties of the
architecture which are independent of implementation.
Properties specific to the first implementation are described separately
in the fourth volume.

The CPU architecture does not include descriptions of system features
such as the system bus, physical memory system, on-chip peripherals and
external interfaces. Also, it does not include descriptions of debug
features such as watch-points, tracing and monitoring. These are
described in a separate set of documents entitled SH-5 System
Architecture which are not yet available.

The architecture provides two instruction sets, called SHmedia and
SHcompact, with mechanisms to switch between them.

The SHmedia instruction set represents instructions using a fixed-length
32-bit encoding. SHmedia is used where optimal performance is required,
or to access CPU system control and configuration mechanisms.
SHmedia delivers high multimedia performance for integer,“packed
arithmetic/SIMD” and floating point operations.
It can perform powerful parallel executions on 8-, 16- and 32-bit
objects, and easily mixes scalar and multimedia operations.

The SHcompact instruction set represents instructions using a
fixed-length 16-bit encoding. SHcompact provides user-mode
instruction-level compatibility with previous implementations of the
SuperH architecture. SHcompact is used where code density or
compatibility is required. SHcompact mode is generally used to reduce
the storage requirements of code that is not especially time critical.

The manuals are now available directly from SuperH via e-mail
(contact in...@su... to request a set).

-------------------------------------------------
Boyd Moffat
SuperH, Inc.
2430 Aztec West, Almondsbury, Bristol, BS32 4AQ.
Tel: (+44) 1454 462697, Fax: (+44) 1454 462701
e-mail: boyd.moffat at superh.com
-------------------------------------------------

Re: [linuxsh-dev] Tree Management Questions

[Jeremy S. <js...@mv...>]

Mitch Davis wrote:

> Greg Banks wrote:
> >
> > Jeremy Siegel wrote:
> > > [...] drop-in trees could be made by simply copying the kernel module
> > > and deleting all the files that weren't needed,[...]
> >
> >   That would be a *really* good idea if we had shell access to
> > the CVS machine at sourceforge.  I don't (offhand) know of a way
> > to copy or remove entire ,v files remotely, but I'd be happy to
> > have someone explain it to me.
>
> I believe the only method is via a support request to sourceforge.
> So as to make things absolutely unambiguous, it might be possible
> to make a shell script containing rm(1)s that they can run after
> cd(1)ing to the relevant repository directory.

So one of the project admins has to make the request?  A diff of
the latest kernel and linux modules produces 1458 lines starting
with "Only in kernel", i.e. files/directories that should be pruned.
I don't know much about CVS repository management; I'd guess
the script would be something like:

    mv linux linux-tmp
    cp -r kernel linux
    rm -rf kernel/.cvsignore
    rm -rf kernel/.gdbinit-dmida
    rm  -rf kernel/.gdbinit-sesh3
    ... (et cetera, et cetera) ...
    rm -rf kernel/scripts/usb
    rm -rf kernel/scripts/ver_linux

Then using normal procedures an admin (or anyone) could add
scripts/tree*link.sh, make the linux-2_4-branch, add the tags,
add the AGAINST-* files, then make the appropriate changes
to ChangeLog and kernel/ksyms.c based on linux-tmp. (The
latter is the only code difference between the branches, but
doesn't seem like it's really needed?)  Then linux-tmp can
be removed, and eventually kernel, w/o (as much) loss of
history.

Do we need a vote or something?  I don't feel that strongly
about whether we should do it or not, but I DO feel that if we
are going to do it, it should be soon... and I'd certainly feel a
lot more comfortable killing the kernel module if I knew the
history were still accessible.

--Jeremy Siegel

Re: [linuxsh-dev] stable SH4 environment

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

Bryan Rittmeyer wrote:
 > Please merge the following patch with your
 > gcc-sh-linux_3.0.1-12.diff.gz:

Thanks.  Will do for 3.0.2.

 > I think my patch improves C++ support in gcc-sh4, and
 > makes it behave more like gcc-3.0 on i386...

Actually, I don't use the result of libstdc++.so (or a) with this
package.  I used the one generated when building native compiler.

Anyway, that's good to have consistent configuration.
-- 

Re: [linuxsh-dev] stable SH4 environment

[Bryan R. <br...@ix...>]

Hello NIIBE-san,

Please merge the following patch with your
gcc-sh-linux_3.0.1-12.diff.gz:

--- gcc-sh-linux-3.0.1/debian/rules-orig        Mon Nov 12 20:15:49 2001
+++ gcc-sh-linux-3.0.1/debian/rules     Mon Nov 12 20:16:02 2001
@@ -45,7 +45,9 @@
                 --disable-nls \
 
--with-gxx-include-dir=\$${prefix}/$(@:build-%=%)/include/g++-v3 \
                 --with-system-zlib \
-               --with-headers=/usr/$(@:build-%=%)/include
+               --with-headers=/usr/$(@:build-%=%)/include \
+               --enable-threads=posix \
+               --enable-long-long
         $(MAKE) -C $(@:build-%=%) all-gcc all-target-libstdc++-v3 
all-target-libobjc
         touch $@

explanation:

--enable-long-long turns on some long long features in libstdc++
--enable-threads=posix enables thread-safe C++ exception handling

both are used in debian's i386 gcc-3.0 package:

Reading specs from /usr/lib/gcc-lib/i386-linux/3.0.2/specs
Configured with: ../src/configure -v 
--enable-languages=c,c++,java,f77,proto,objc --prefix=/usr 
--infodir=/share/info --mandir=/share/man --enable-shared --with-gnu-as 
--with-gnu-ld --with-system-zlib --enable-long-long --enable-nls 
--without-included-gettext --disable-checking --enable-threads=posix 
--enable-java-gc=boehm --with-cpp-install-dir=bin --enable-objc-gc 
i386-linux
Thread model: posix
gcc version 3.0.2 20010922 (Debian prerelease)

I think my patch improves C++ support in gcc-sh4, and
makes it behave more like gcc-3.0 on i386...

Regards,

-Bryan

NIIBE Yutaka wrote:
> It's kitchen sink (all is included) patch for Debian.  I don't have
> time to explain each pieces.  For that, please see gcc-patches mailing
> list archive.

-- 
Bryan Rittmeyer
mailto:br...@ix...

Re: [linuxsh-dev] Tree Management Questions

[Jeremy S. <js...@mv...>]

"M. R. Brown" wrote:

> No objections, but with your last suggestion (below) it seems that you
> probably would want to wait until we "retrofit" the drop-in tree.

I'll put the stuff in the way I have been; as long as the trees all remain
pretty much in sync (actually, as long as "kernel" doesn't fall behind)
any "retrofit" will not be affected.  (The relief of having it checked in
at all is greater than the burden of doing multiple check-ins!)

> I guess my preference would be to commit to branch and then merge back with
> HEAD, it seems we can do that until we either decide to start moving files
> around in HEAD, or 2.5 hits the streets, whichever comes first.

Seems the way to go when trees separate and you want to move deltas
between branches with CVS doing most of the work!  (As long as they
remain basically the same, I'll probably check both in independently,
and do my own copying and editing.)

> > (4) Chatting with one of our architects here (Marcus, I think you
> > know Gilbert?) about the drop-in trees, I mentioned that I'd asked
> > for the old kernel tree to stay for history purposes since the new
> > linux modules believe last month was the dawn of time.  He thought
> > the drop-in trees could be made by simply copying the kernel module
> > and deleting all the files that weren't needed, resulting in the same
> > (pruned) tree [though with different actual version numbers inside]
> > but with all the old history.  Any thoughts on the value of that?
>
> Wow, that's a great idea!  I've been a bit scarce in the LinuxSH world as
> I'm busy working on a project for MV, but I should at least have some time
> this weekend to complete that, unless you (or someone else) would like to
> get to it before then.

I'll defer to you -- I'm not familiar enough with repository management
to believe I could do it safely.  In the meantime I'll treat all three modules
identically w.r.t. changes so as not to introduce any new differences into
the works.

Thanks!
  --Jeremy

Re: [linuxsh-dev] Tree Management Questions

[David W. <dw...@in...>]

mj...@al... said:
>  Been there.  If a change doesn't scratch Linus' itch, he can be a bit
> of a black hole.  Alan might be a better bet than Linus. 

Linus is usually reasonably good about taking MTD code changes. The main 
problem is that I'm crap at actually getting round to _sending_ them :)


--
dwmw2

Re: [linuxsh-dev] Tree Management Questions

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

Greg Banks wrote:
> 
> Jeremy Siegel wrote:
> >
> > [...]I don't mind just
> > waiting in this case for the changes to percolate from David to Linus
> > to SH...
> 
>   I think that would probably be the worst solution.

Been there.  If a change doesn't scratch Linus' itch, he can
be a bit of a black hole.  Alan might be a better bet than Linus.

> > [...] drop-in trees could be made by simply copying the kernel module
> > and deleting all the files that weren't needed,[...]
> 
>   That would be a *really* good idea if we had shell access to
> the CVS machine at sourceforge.  I don't (offhand) know of a way
> to copy or remove entire ,v files remotely, but I'd be happy to
> have someone explain it to me.

I believe the only method is via a support request to sourceforge.
So as to make things absolutely unambiguous, it might be possible
to make a shell script containing rm(1)s that they can run after
cd(1)ing to the relevant repository directory.

Regards,

Mitch.
-- 
The GPL is a lot like an alligator snout.  You can hold it shut
with one hand, but if you stick your head in it bites like hell.
mailto:mj...@al...                       - Nathan Myers

[linuxsh-dev] Holiday Gifts! Cartoon Character Jewelry from Jewelryanimations.com

[jewelryanimations <bc...@qw...>]

<HTML>
<HEAD>
  <META NAME="GENERATOR" CONTENT="Adobe PageMill 3.0 Win">
  <TITLE>Holiday Gifts! Cartoon Character Jewelry from Jewelryanimations.com</TITLE>
</HEAD>
<BODY BGCOLOR="#ffffff">

<TABLE WIDTH="541" BORDER="0" CELLSPACING="0" CELLPADDING="0"
HEIGHT="767">
  <TR>
    <TD WIDTH="2%" HEIGHT="347">
    &nbsp;</TD>
    <TD WIDTH="85%" HEIGHT="347">
    <MAP NAME="catbannerMap1">
    <AREA SHAPE="rect" COORDS="80,340,438,358" HREF="http://www.jewelryanimations.com/shippop.html">
    <AREA SHAPE="rect" COORDS="63,0,444,48" HREF="http://www.jewelryanimations.com/">
</MAP><IMG SRC="http://www.jewelryanimations.com/images/catbanner.gif"
    ALIGN="BOTTOM" BORDER="0" USEMAP="#catbannerMap1" ISMAP>
</TD>
    <TD WIDTH="13%" HEIGHT="347">
    &nbsp;</TD>
  </TR>
  <TR>
    <TD WIDTH="2%" HEIGHT="378">
    &nbsp;</TD>
    <TD WIDTH="85%" HEIGHT="378">
    <P><CENTER><IMG SRC="http://www.jewelryanimations.com/images/yellowspace.gif"
    WIDTH="492" HEIGHT="20" ALIGN="BOTTOM" BORDER="0" NATURALSIZEFLAG="0"><TABLE
    WIDTH="493" BORDER="0" CELLSPACING="0" CELLPADDING="0" HEIGHT="151">

      <TR>
        <TD WIDTH="100%" BGCOLOR="#fff99d" HEIGHT="150">
        <P><CENTER><TABLE WIDTH="468" BORDER="0" CELLSPACING="0" CELLPADDING="0"
        HEIGHT="448">
          <TR>
            <TD WIDTH="62%" HEIGHT="182">
            <P><B><I><FONT COLOR="#ff0000">Delightful gifts, delivered right
            to your door!</FONT></I></B></P>

            <P><B>Reasonably priced, and absolutely charming character jewelry!
            Perfect for your office party, &quot;Secret Santa&quot; or stocking
            stuffers. <A HREF="http://www.jewelryanimations.com/disnyall.html">Disney</A>,
            <A HREF="http://www.jewelryanimations.com/warnerall.html">Warner
            Bros.</A>, <A HREF="http://www.jewelryanimations.com/seussall.html">Dr.
            Seuss</A>, <A HREF="http://www.jewelryanimations.com/allgarfield.html">Garfield</A>,
            <A HREF="http://www.jewelryanimations.com/miscall.html">Grimmy</A>,
            and more. Designed and handcrafted in Colorado, jewelryanimations has been
            setting the standard in Cartoon Character jewelry for more than
            a decade.</B></TD>
            <TD WIDTH="4%" HEIGHT="182">
            &nbsp;</TD>
            <TD WIDTH="34%" BGCOLOR="#000099" HEIGHT="182">
            <P><CENTER>&nbsp;<A HREF="http://www.jewelryanimations.com/"><IMG
            SRC="http://www.jewelryanimations.com/images/sorcpewtauct3.jpg"
            ALIGN="MIDDLE" BORDER="0"></A></CENTER></P>

            <P><CENTER><FONT COLOR="#ffffff" SIZE="-1">Character Pins, Pendants,
            &amp; Earrings in 14K, Sterling, &amp; Pewter!</FONT></CENTER></TD>
          </TR>
          <TR>
            <TD COLSPAN="3">
            <P>&nbsp;</P>

            <P><B><I><FONT COLOR="#ff0000">Let us take the stress out of
            your Holiday season!</FONT></I></B></P>

            <P><B><FONT COLOR="#000000">Ordering from us is easy! Click the
            link below to shop. Browse our online store, and use the convenient
            &quot;shopping cart&quot; to select your purchases. We accept
            Checks, Money Orders, and Credit Cards (via Paypal). Have your
            order shipped to you, or specify a recipient and we will ship
            directly to them! Our flexible shipping options assure you a safe and
            worry-free shopping experience.<BR>
            </FONT></B><FONT COLOR="#fff99d">x</FONT></TD>

          </TR>
          <TR>
            <TD COLSPAN="3" HEIGHT="61">
            <P><CENTER><A HREF="http://www.jewelryanimations.com/"><IMG
            SRC="http://www.jewelryanimations.com/images/jasbnnr.gif" ALIGN="TOP"
            BORDER="0"></A></CENTER></TD>
          </TR>
        </TABLE></CENTER></P>

        <P><CENTER><IMG SRC="http://www.jewelryanimations.com/images/toonbar.gif"
        ALIGN="BOTTOM" BORDER="0"></CENTER></TD>
      </TR>
    </TABLE><IMG SRC="http://www.jewelryanimations.com/images/blankbar.gif"
    ALIGN="BOTTOM" BORDER="0"></CENTER></TD>
    <TD WIDTH="13%" HEIGHT="378">
    &nbsp;</TD>
  </TR>
  <TR>
    <TD WIDTH="2%" HEIGHT="41">
    &nbsp;</TD>
    <TD WIDTH="85%" HEIGHT="41">
    <P><CENTER><FONT SIZE="-2" FACE="Arial"><A HREF="https://www.paypal.com/verified/pal=sa...@je..."><IMG
    SRC="http://www.jewelryanimations.com/images/paypallogo2.gif" WIDTH="192" HEIGHT="36" ALIGN="BOTTOM"
    BORDER="0" NATURALSIZEFLAG="3"></A><BR>
    &COPY;2001 jewelryanimations.com
    </P>

    <P>&nbsp;</P>

    </BLOCKQUOTE></CENTER>
</TD>
    <TD WIDTH="13%" HEIGHT="41"></TD>
  </TR>
</TABLE>

</BODY>
</HTML>

Re: [linuxsh-dev] Tree Management Questions

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

Jeremy Siegel wrote:
> 
> (1) Of the four files to be changed, two aren't in the drop-in tree yet.
> I'm assuming we expect to regularly add/drop files in common areas as
> SH development proceeds,[...]

  I'm certainly expecting that.

> (2) The MTD files are maintained by David in his own CVS; he'd like
> versions in SH (or kernel.org) trees to keep keywords unchanged for
> easy comparison with his tree. [...]

  I have no objection to -ko on MTD source files.  The $Id$ should
really come from the master CVS for the source file; perhaps MR
can add something along these lines to the dev doc?

> [...]I don't mind just
> waiting in this case for the changes to percolate from David to Linus
> to SH...

  I think that would probably be the worst solution.

> [...] (kernel, linux:HEAD,
> linux:linux-2_4-branch) [...] and I don't want to be the one to start the
> disconnect. 

  For "linux:HEAD" vs "linux:linux-2_4-branch", the timing is Linus' job ;-)

  As to whether you should spend time updating "kernel", that depends
on Niibe-san.

> [...] drop-in trees could be made by simply copying the kernel module
> and deleting all the files that weren't needed,[...]

  That would be a *really* good idea if we had shell access to
the CVS machine at sourceforge.  I don't (offhand) know of a way
to copy or remove entire ,v files remotely, but I'd be happy to
have someone explain it to me.

Greg.
-- 
the price of civilisation today is a courageous willingness to prevail,
with force, if necessary, against whatever vicious and uncomprehending
enemies try to strike it down.	   - Roger Sandall, The Age, 28Sep2001.

Re: [linuxsh-dev] Tree Management Questions

[M. R. B. <mr...@0x...>]

* Jeremy Siegel <js...@mv...> on Wed, Nov 07, 2001:

>=20
> (1) Of the four files to be changed, two aren't in the drop-in tree yet.
> I'm assuming we expect to regularly add/drop files in common areas as
> SH development proceeds, then gets put in kernel.org (or vice-versa,
> if SH lags and then catches up).
>=20

Yes.

> (2) The MTD files are maintained by David in his own CVS; he'd like
> versions in SH (or kernel.org) trees to keep keywords unchanged for
> easy comparison with his tree.  Our old kernel module had -ko on all
> the mtd files to do this, but I don't think the drop-in does; I will add =
it
> for these files (and the new ones for (1) above).  [How and when to
> do this should probably be covered in the developer document?]
>=20

Hmm, I wasn't around back then so I wasn't aware of the keyword
preservation.  There is a document (which still lives on linuxsh.org) that
describes how to import new kernel releases, but it was never really
followed ... which is the main reason it's hard to track the CVS source
versions.

> Any objections to these?  If it's a serious problem, I don't mind just
> waiting in this case for the changes to percolate from David to Linus
> to SH... but certainly we need to be able to do these things smoothly.
>=20

No objections, but with your last suggestion (below) it seems that you
probably would want to wait until we "retrofit" the drop-in tree.

> (3) In the past few weeks I've checked in some changes; in each
> case I've changed all three development lines (kernel, linux:HEAD,
> linux:linux-2_4-branch) -- mainly because they're all pretty much
> the same at this point, and I don't want to be the one to start the
> disconnect.  Is that ok?  I don't think there have been many other
> changes (which might be helpful for the next item).
>=20

I guess my preference would be to commit to branch and then merge back with
HEAD, it seems we can do that until we either decide to start moving files
around in HEAD, or 2.5 hits the streets, whichever comes first.

> (4) Chatting with one of our architects here (Marcus, I think you
> know Gilbert?) about the drop-in trees, I mentioned that I'd asked
> for the old kernel tree to stay for history purposes since the new
> linux modules believe last month was the dawn of time.  He thought
> the drop-in trees could be made by simply copying the kernel module
> and deleting all the files that weren't needed, resulting in the same
> (pruned) tree [though with different actual version numbers inside]
> but with all the old history.  Any thoughts on the value of that?
>=20

Wow, that's a great idea!  I've been a bit scarce in the LinuxSH world as
I'm busy working on a project for MV, but I should at least have some time
this weekend to complete that, unless you (or someone else) would like to
get to it before then.

M. R.

[linuxsh-dev] Holiday Gifts! Cartoon Character Jewelry from Jewelryanimations.com

[<dr_...@je...>]

<HTML>
<HEAD>
  <META NAME="GENERATOR" CONTENT="Adobe PageMill 3.0 Win">
  <TITLE>Holiday Gifts! Cartoon Character Jewelry from Jewelryanimations.com</TITLE>
</HEAD>
<BODY BGCOLOR="#ffffff">

<TABLE WIDTH="541" BORDER="0" CELLSPACING="0" CELLPADDING="0"
HEIGHT="767">
  <TR>
    <TD WIDTH="2%" HEIGHT="347">
    &nbsp;</TD>
    <TD WIDTH="85%" HEIGHT="347">
    <MAP NAME="catbannerMap1">
    <AREA SHAPE="rect" COORDS="80,340,438,358" HREF="http://www.jewelryanimations.com/shippop.html">
    <AREA SHAPE="rect" COORDS="63,0,444,48" HREF="http://www.jewelryanimations.com/">
</MAP><IMG SRC="http://www.jewelryanimations.com/images/catbanner.gif"
    ALIGN="BOTTOM" BORDER="0" USEMAP="#catbannerMap1" ISMAP>
</TD>
    <TD WIDTH="13%" HEIGHT="347">
    &nbsp;</TD>
  </TR>
  <TR>
    <TD WIDTH="2%" HEIGHT="378">
    &nbsp;</TD>
    <TD WIDTH="85%" HEIGHT="378">
    <P><CENTER><IMG SRC="http://www.jewelryanimations.com/images/yellowspace.gif"
    WIDTH="492" HEIGHT="20" ALIGN="BOTTOM" BORDER="0" NATURALSIZEFLAG="0"><TABLE
    WIDTH="493" BORDER="0" CELLSPACING="0" CELLPADDING="0" HEIGHT="151">

      <TR>
        <TD WIDTH="100%" BGCOLOR="#fff99d" HEIGHT="150">
        <P><CENTER><TABLE WIDTH="468" BORDER="0" CELLSPACING="0" CELLPADDING="0"
        HEIGHT="448">
          <TR>
            <TD WIDTH="62%" HEIGHT="182">
            <P><B><I><FONT COLOR="#ff0000">Delightful gifts, delivered right
            to your door!</FONT></I></B></P>

            <P><B>Reasonably priced, and absolutely charming character jewelry!
            Perfect for your office party, &quot;Secret Santa&quot; or stocking
            stuffers. <A HREF="http://www.jewelryanimations.com/disnyall.html">Disney</A>,
            <A HREF="http://www.jewelryanimations.com/warnerall.html">Warner
            Bros.</A>, <A HREF="http://www.jewelryanimations.com/seussall.html">Dr.
            Seuss</A>, <A HREF="http://www.jewelryanimations.com/allgarfield.html">Garfield</A>,
            <A HREF="http://www.jewelryanimations.com/miscall.html">Grimmy</A>,
            and more. Designed and handcrafted in Colorado, jewelryanimations has been
            setting the standard in Cartoon Character jewelry for more than
            a decade.</B></TD>
            <TD WIDTH="4%" HEIGHT="182">
            &nbsp;</TD>
            <TD WIDTH="34%" BGCOLOR="#000099" HEIGHT="182">
            <P><CENTER>&nbsp;<A HREF="http://www.jewelryanimations.com/"><IMG
            SRC="http://www.jewelryanimations.com/images/sorcpewtauct3.jpg"
            ALIGN="MIDDLE" BORDER="0"></A></CENTER></P>

            <P><CENTER><FONT COLOR="#ffffff" SIZE="-1">Character Pins, Pendants,
            &amp; Earrings in 14K, Sterling, &amp; Pewter!</FONT></CENTER></TD>
          </TR>
          <TR>
            <TD COLSPAN="3">
            <P>&nbsp;</P>

            <P><B><I><FONT COLOR="#ff0000">Let us take the stress out of
            your Holiday season!</FONT></I></B></P>

            <P><B><FONT COLOR="#000000">Ordering from us is easy! Click the
            link below to shop. Browse our online store, and use the convenient
            &quot;shopping cart&quot; to select your purchases. We accept
            Checks, Money Orders, and Credit Cards (via Paypal). Have your
            order shipped to you, or specify a recipient and we will ship
            directly to them! Our flexible shipping options assure you a safe and
            worry-free shopping experience.<BR>
            </FONT></B><FONT COLOR="#fff99d">x</FONT></TD>

          </TR>
          <TR>
            <TD COLSPAN="3" HEIGHT="61">
            <P><CENTER><A HREF="http://www.jewelryanimations.com/"><IMG
            SRC="http://www.jewelryanimations.com/images/jasbnnr.gif" ALIGN="TOP"
            BORDER="0"></A></CENTER></TD>
          </TR>
        </TABLE></CENTER></P>

        <P><CENTER><IMG SRC="http://www.jewelryanimations.com/images/toonbar.gif"
        ALIGN="BOTTOM" BORDER="0"></CENTER></TD>
      </TR>
    </TABLE><IMG SRC="http://www.jewelryanimations.com/images/blankbar.gif"
    ALIGN="BOTTOM" BORDER="0"></CENTER></TD>
    <TD WIDTH="13%" HEIGHT="378">
    &nbsp;</TD>
  </TR>
  <TR>
    <TD WIDTH="2%" HEIGHT="41">
    &nbsp;</TD>
    <TD WIDTH="85%" HEIGHT="41">
    <P><CENTER><FONT SIZE="-2" FACE="Arial"><A HREF="https://www.paypal.com/verified/pal=sa...@je..."><IMG
    SRC="http://www.jewelryanimations.com/images/paypallogo2.gif" WIDTH="192" HEIGHT="36" ALIGN="BOTTOM"
    BORDER="0" NATURALSIZEFLAG="3"></A><BR>
    &COPY;2001 jewelryanimations.com
    </P>

    <P>&nbsp;</P>

    </BLOCKQUOTE></CENTER>
</TD>
    <TD WIDTH="13%" HEIGHT="41"></TD>
  </TR>
</TABLE>

</BODY>
</HTML>

[linuxsh-dev] Tree Management Questions

[Jeremy S. <js...@mv...>]

I've got several questions regarding management of our CVS trees,
which I haven't seen covered in any how-to-use description.  If I've
simply missed stuff in a document somewhere, please let me know.

(The context for this is that I've recently made some changes to mtd
files with dwmw2's blessing, and wanted to put them in our tree, so
this kind of details what I think I'll be doing... but here's your chance
to correct me if I'm going to do anything horribly wrong!)

(1) Of the four files to be changed, two aren't in the drop-in tree yet.
I'm assuming we expect to regularly add/drop files in common areas as
SH development proceeds, then gets put in kernel.org (or vice-versa,
if SH lags and then catches up).

(2) The MTD files are maintained by David in his own CVS; he'd like
versions in SH (or kernel.org) trees to keep keywords unchanged for
easy comparison with his tree.  Our old kernel module had -ko on all
the mtd files to do this, but I don't think the drop-in does; I will add it
for these files (and the new ones for (1) above).  [How and when to
do this should probably be covered in the developer document?]

Any objections to these?  If it's a serious problem, I don't mind just
waiting in this case for the changes to percolate from David to Linus
to SH... but certainly we need to be able to do these things smoothly.

(3) In the past few weeks I've checked in some changes; in each
case I've changed all three development lines (kernel, linux:HEAD,
linux:linux-2_4-branch) -- mainly because they're all pretty much
the same at this point, and I don't want to be the one to start the
disconnect.  Is that ok?  I don't think there have been many other
changes (which might be helpful for the next item).

(4) Chatting with one of our architects here (Marcus, I think you
know Gilbert?) about the drop-in trees, I mentioned that I'd asked
for the old kernel tree to stay for history purposes since the new
linux modules believe last month was the dawn of time.  He thought
the drop-in trees could be made by simply copying the kernel module
and deleting all the files that weren't needed, resulting in the same
(pruned) tree [though with different actual version numbers inside]
but with all the old history.  Any thoughts on the value of that?

Well, that's all for now...

--Jeremy Siegel

[linuxsh-dev] MTD for SolutionEngine

[Jeremy S. <js...@mv...>]

David et. al.,

Wanting to use your drivers/mtd/maps/solutionengine.c without
having to use redboot, I tried changing it to allow SE selection
w/o redboot partitioning, but only an optional read-only reserve
area at the bottom of flash (e.g. for sh-ipl+g or other boot code.)

I tested various config selections, but haven't done much with
modules before and may have missed obvious stuff; also had to
change some addresses I assume were typos, but maybe I've
misunderstood something about the purpose of the file...

Anyway, the corresponding patch for maps/solutionengine.c and
maps/Config.in is attached; does it look ok to check in?

Also: I reserved 64K by default, which forces the next partition
to be read-only; rather than change it to 128K I added code to
adjust flexible partitions to erasesize alignment, and left that
in the patch.  Could this be done automatically somehow by the
MTD code?  I experimented with adding such code as an option
and have attached that as well, though I'm not suggesting that
go into the SH tree... just an example of a requested extension
to the internal MTD interface.

Thanks,
  --Jeremy Siegel

[linuxsh-dev] stat64 endian patch

[Jeremy S. <js...@mv...>]

Hi folks,

Found a patch I forgot to check in... nobody objected when
the email went out two months ago, just sending it again in
case someone tells me something has changed.

Basically, stat64 in the kernel (include/asm-sh/stat.h) does
not match glibc (sysdeps/unix/sysv/linux/bits/stat.h?) when
compiled big-endian; this patch makes the kernel consistent
with the library definition either way.

--Jeremy Siegel

--- stat.h      2001/03/27 21:41:27     1.1
+++ stat.h      2001/08/07 00:57:41     1.2
@@ -42,8 +42,16 @@
  * insane amounts of padding around dev_t's.
  */
 struct stat64 {
+#if defined(__BIG_ENDIAN__)
+       unsigned char   __pad0b[6];
        unsigned short  st_dev;
-       unsigned char   __pad0[10];
+#elif defined(__LITTLE_ENDIAN__)
+       unsigned short  st_dev;
+       unsigned char   __pad0b[6];
+#else
+#error Must know endian to build stat64 structure!
+#endif
+       unsigned char   __pad0[4];

        unsigned long   st_ino;
        unsigned int    st_mode;
@@ -52,14 +60,25 @@
        unsigned long   st_uid;
        unsigned long   st_gid;

+#if defined(__BIG_ENDIAN__)
+       unsigned char   __pad3b[6];
+       unsigned short  st_rdev;
+#else /* Must be little */
        unsigned short  st_rdev;
-       unsigned char   __pad3[10];
+       unsigned char   __pad3b[6];
+#endif
+       unsigned char   __pad3[4];

        long long       st_size;
        unsigned long   st_blksize;

+#if defined(__BIG_ENDIAN__)
+       unsigned long   __pad4;         /* Future possible st_blocks hi
bits */
+       unsigned long   st_blocks;      /* Number 512-byte blocks
allocated. */
+#else /* Must be little */
        unsigned long   st_blocks;      /* Number 512-byte blocks
allocated. */
-       unsigned long   __pad4;         /* future possible st_blocks high
bits */
+       unsigned long   __pad4;         /* Future possible st_blocks hi
bits */
+#endif

        unsigned long   st_atime;
        unsigned long   __pad5;

[linuxsh-dev] Re: SH-PCI Config Question

[Jeremy S. <js...@mv...>]

David Woodhouse wrote:

> > Any reason NOT to expose this config option?
>
> None. It's only hidden because, as with the CONFIG_MEMORY_SIZE defaults, I
> didn't want to change anything I couldn't test - so the new code was only
> enabled for the (unmerged) platform I was working on at the time, and turned
> off for all boards in the CVS tree.  The reason I merged it even though it
> was as yet unused was because I expected that someone else would need it.

Thanks -- I'll assume that means I'm free to check in the change...

> BTW, I had problems with the 7729 board I was playing with - if I enabled
> writeback caching for P1, the board would lock up hard under load.
> Changing P1 to writethrough made it survive. I don't think that's a bug in
> the cache management code - I was beginning to suspect hardware. Have you
> seen anything similar?

No... but we haven't really loaded recent code.  (So I should say, "not yet"!)
[Of course, from that description I'd kind of suspect hardware too...]

Thanks,
  --Jeremy Siegel

[linuxsh-dev] Re: SH-PCI Config Question

[David W. <dw...@ca...>]

js...@mv... said:
>  From what I know about the SH, external memory accessible by a PCI
> master would always be non-coherent with the on-chip copy-back cache
> (i.e. except for memory referenced via P2 (uncachable) which should be
> obtained from pci_alloc_consistent()).  Did I miss some SH bus pins
> that allow snooping or something?

> Any reason NOT to expose this config option?

None. It's only hidden because, as with the CONFIG_MEMORY_SIZE defaults, I
didn't want to change anything I couldn't test - so the new code was only
enabled for the (unmerged) platform I was working on at the time, and turned
off for all boards in the CVS tree.  The reason I merged it even though it
was as yet unused was because I expected that someone else would need it.

(That platform support really ought to be going public quite soon, I believe.)

BTW, I had problems with the 7729 board I was playing with - if I enabled 
writeback caching for P1, the board would lock up hard under load. 
Changing P1 to writethrough made it survive. I don't think that's a bug in 
the cache management code - I was beginning to suspect hardware. Have you 
seen anything similar?

--
dwmw2

[linuxsh-dev] SH-PCI Config Question

[Jeremy S. <js...@mv...>]

Hi,

To get pcnet32.c to work on the SH7751 Solution Engine, I've been
turning on the CONFIG_SH_PCIDMA_NONCOHERENT option. But
since that is silently defined as 'n' by the default config.in, it would
seem that having to set it is unexpected; am I doing something wrong?
Does the driver need modification to flush cache directly rather than
calling pci_map_single()? Or is this another allocation space issue
like David Mckay referred to a couple weeks ago?

From what I know about the SH, external memory accessible by a PCI
master would always be non-coherent with the on-chip copy-back
cache (i.e. except for memory referenced via P2 (uncachable) which
should be obtained from pci_alloc_consistent()).  Did I miss some SH
bus pins that allow snooping or something?

Any reason NOT to expose this config option?

Thanks,
  --Jeremy Siegel

[linuxsh-dev] CVS tree failures

[Jeremy S. <js...@mv...>]

Building the latest CVS source (2.4.13-pre2) for the 7751 Solution Engine
gets
(1) a compile error in io_7751se.c, and (2) a link error in
drivers/pci/pci.c.  Unless
there are objections, I will check in the following patch:

diff -Nur kernel/arch/sh/kernel/io_7751se.c
sh7751/arch/sh/kernel/io_7751se.c
--- kernel/arch/sh/kernel/io_7751se.c Mon Oct 29 14:14:28 2001
+++ sh7751/arch/sh/kernel/io_7751se.c Mon Oct 29 14:16:03 2001
@@ -17,7 +17,7 @@
 #include <asm/hitachi_7751se.h>
 #include <asm/addrspace.h>

-#include <asm/pci.h>
+#include <linux/pci.h>
 #include <asm/pci-sh7751.h>

 #if 0
diff -Nur kernel/include/asm-sh/pci.h sh7751/include/asm-sh/pci.h
--- kernel/include/asm-sh/pci.h Mon Oct 29 14:15:13 2001
+++ sh7751/include/asm-sh/pci.h Mon Oct 29 14:18:03 2001
@@ -196,6 +196,11 @@
  return 1;
 }

+/* Not supporting more than 32-bit PCI bus addresses now, but
+ * must satisfy references to this function.  Change if needed.
+ */
+#define pci_dac_dma_supported(pci_dev, mask) (0)
+
 /* Return the index of the PCI controller for device PDEV. */
 #define pci_controller_num(PDEV) (0)

[linuxsh-dev] Kernel Command Line

[Jeremy S. <js...@mv...>]

A couple months ago, I proposed adding a configurable command line to
the SH kernel, w/o the whole parameter block and with no assumptions
about the bootloader; Niibe responded that a different way based on an
earlier proposal by David Woodhouse was preferable.  At the time I set
it aside to do other things, but now I'd like to respond and try to
justify my proposal a bit better (or at least how I think about it...)

[Note: I've reordered some of Niibe's comments to combine my answers.]

> > Rather than the entire parameter block we copy only the kernel command

> > line, made configurable (with a copy in misc.c itself so zImage is
still
> > built w/o the empty_zero_page).  This allows kernel config to force
the
> > command line regardless of the bootloader, or to not have one and
depend
> > on the bootloader as now.  (Or to use sh-ipl+g to load w/o having to
set
> > up the command line using gdb commands.)
>
> I think it's good idea to have hard-coded default parameters, and make
> them configurable.  I don't think it's good to "force" the parameters.
> It should be overridden at run-time.

> How about following?
>
>   (a) Introduce parameter block something like David Woodhouse
suggested.
>   (b) Provide the config option to build "zImage + parameter block",
>       say, zImage+parms, and provide options for default paremeters
>       to build parameters block.
>
> Users can use zImage+parms with no boot loader, use zImage with boot
> loader, or use zImage+parms with boot loader which may override params
> at run-time.

I'm not sure that the bootloader should be able to trump the kernel in
all cases; isn't it sort of a coin toss?  I can always build the kernel
w/o a cmdline and it'll use whatever the bootloader says.  Having said
that, I'll admit that I'm not very familiar with available bootloaders
and their capabilities; I've only been using ethboot, or S-record serial
download.  (I also rebuild the kernel regularly, so redoing the config
and recompiling some files isn't a big deal here; admittedly that may be
a bad way to look at it.)  [And if the boot loader can override params
at runtime, why use the zImage with no params option?]

One concern is that expressed by David in his original proposal and
patch for the parameter block: compatibility with boot loaders.  If I
understood David's patch, the zImage expects the loader to overwrite its
beginning part and jump to its start, which will copy that beginning to
the correct place.  If the loader doesn't know to do that, it may try
executing the parameter block which will just jump to the image; but if
the loader (now incorrectly) put parameters at _text, the zImage can't
tell and will ignore them, right?

The point was made that it's easy to change the boot loaders, but I'm
always uncomfortable with the need to couple separate pieces of SW more
closely... I know this isn't much better, but at least with the kernel
forcing you'd have a kernel that behaves consistently across different
bootloaders and bootloader versions.  If you build a kernel w/o the
forcing, you get bootloader parameters, consistent with your current
behavior.

Also, I've been working only with the command line string.  Seems to me
that's the easiest way to configure, and it's real flexible; one param
and you can set all kinds of things without needing lots of config
options.  (Of course, this may just be laziness on my part.)

A final point is that I think ppc has command line configuration which
kind of works like this (and maybe arm)?

> Besides, for the implementation of default parameters for zImage,
> I think it could be implemented the file(s) under arch/sh/boot/.
>
> > --- kernel/arch/sh/kernel/head.S Fri Jul 27 04:48:29 2001
> > +++ test/arch/sh/kernel/head.S Tue Sep  4 14:13:49 2001
>
> I think touching beyond arch/sh/boot/ is irrelevant for this purpose.

I assume you meant that touching arch/sh/kernel is irrelevant... one
thing I liked about this though is that it produces a vmlinux which has
the command line in it, not just a zImage -- so, for example, using gdb
with sh-ipl+g and doing a "load" I didn't have to use a .gdbinit to put
in the command line string (but could if desired, of course.)  But of
course this isn't really necessary.

Is any of this convincing?

Thanks,
  --Jeremy Siegel