linuxsh-dev

[linuxsh-dev] Problem with pthread mutex

[Lew G. <le...@se...>]

Hi,

I have run into a problem using pthread_mutex.  When two threads try to lock
the same mutex, one of them blocks, but never wakes up when the other
releases the lock.

We are using glibc-2.2.2, having followed the instructions for building the
cross-development tools from this mailing list.

Has anyone else encountered similar problems?

-Lewis Girod

Re: [linuxsh-dev] Dreamcast U.S. Version

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

* NIIBE Yutaka <gn...@m1...> on Sun, Mar 11, 2001:

> I'm in Bay Area now (untill 14th).  I bought Dreamcast U.S. version
> ($100) and "MadCatz" Keyboard adapter ($15) at Fry's in Sunnyvale.  I
> tried CD-R by Yaegashi, it boots and works fine.
> 
> BTW, we've talked the release of Dreamcast cable with FFII people last
> week (in Japan).  Basically, we got consensus.  We'll proceed leagal
> procedure, and Dreamcast drivers will be released.  I don't know how 
> much time it takes though.
> -- 
>

Um, just to let you know, the LinuxDC project is alive and well at
linuxdc.org.  As I write this I'm finishing up ethernet support (I'm
playing with NFS now) and FB drivers are already there.  Maple will
probably be added sometime next week.

All code that I write (or anyone else in linuxdc) is covered under the 
GPL and "assigned" to the LinuxDC project.  What type of "legal"
procedures are you talking about?  Please, spare me the tired, 
"Sega won't sanction it", this is built from entirely free info and 
tools, which IMHO has nothing to do with Sega :)

Feel free to checkout CVS and have a look, or join our mailing lists.  I'd
be interested in hearing your and Yaegashi's ideas on driver development.

M. R.

[linuxsh-dev] Dreamcast U.S. Version

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

I'm in Bay Area now (untill 14th).  I bought Dreamcast U.S. version
($100) and "MadCatz" Keyboard adapter ($15) at Fry's in Sunnyvale.  I
tried CD-R by Yaegashi, it boots and works fine.

BTW, we've talked the release of Dreamcast cable with FFII people last
week (in Japan).  Basically, we got consensus.  We'll proceed leagal
procedure, and Dreamcast drivers will be released.  I don't know how 
much time it takes though.
-- 

Re: [linuxsh-dev] modutils patch for 2.4. kernel

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

At 12:34 01/03/09 +0530, Santosh Eraniose <sa...@so...> wrote:
>Hello,

Hi

>Where can I get the SH patch for modutils for 2.4.0 test 11 kernel

Please check
http://www.sh-linux.org/rpm-index/sh3/modutils-2.3.24-1.sh3.html

you can get binary rpm, or source rpm there.

----
SUGIOKA Toshinobu

[linuxsh-dev] modutils patch for 2.4. kernel

[Santosh E. <sa...@so...>]

Hello,
Where can I get the SH patch for modutils for 2.4.0 test 11 kernel

There was a mention about David Mckay's patch for modutils 2.3.7,
earlier in the list but I could not locate it.
Only Kojima san's patch for modutils-2.1.121-sh-991130.diff.gz
But I understand that this does not work for 2.4 kernel.

Thanks
Santosh

[linuxsh-dev] Re: problem about gcc

[kaz K. <kk...@rr...>]

Hi,

leg...@ya... wrote:
> hey , 
>    in the gcc ,the file gcc/config/sh/sh.h have 
> 
>  #define TARGET_DEFAULT  (SH3_BIT|SH2_BIT|LITTLE_ENDIAN_BIT) 
> 
> i don't think it 's suitable . because when i use the gcc to compile the
> program for sh2 ( -m2 )  . in the code , it produce the instruction
> "shad"  , it is a instruction for sh3 . 
>  so i change it to 
> 
> #define TARGET_DEFAULT  (0) 
> 
> just as it is in the standard gcc-2.95.2.

Which non-standard gcc-2.95.2 you are talking about?
I can't find such problem in our patch to gcc-2.95.2, though
any patches to gcc-2.95.2 may be obsolete now.

> but the problem is when i use this gcc to compile the program , it has
> error 
>
> (.text+0x694): undefined reference to `__ashiftrt_r4_8'
> (.text+0x774): undefined reference to `__ashiftrt_r4_8'  
> 
> anybody has the advice about it , i will appreciate in advance.

You could check easily that __ashiftrt_r4_8 is defined or not in
your libgcc.a by using cross nm. If not, it seems that your gcc has
configuration problems. In that case, check your gcc/config/sh/t-linux
or gcc/config/sh/t-sh (this depends how you configure gcc) includes
a line like

LIB1ASMFUNCS = _ashiftrt _ashiftrt_n _ashiftlt _lshiftrt _movstr \

or not. (Or just try the newer gcc

ftp.m17n.org:/pub/super-h/testing/gcc-core-20001120.tar.gz
ftp.m17n.org:/pub/super-h/testing/gcc-20001120.diff.gz

though I don't use it with -m2 at all. Is there someone who does it
already?)

	kaz

[linuxsh-dev] problem about gcc

[Henry <leg...@ya...>]

hey , 
   in the gcc ,the file gcc/config/sh/sh.h have 

 #define TARGET_DEFAULT  (SH3_BIT|SH2_BIT|LITTLE_ENDIAN_BIT) 

i don't think it 's suitable . because when i use the gcc to compile the
program for sh2 ( -m2 )  . in the code , it produce the instruction
"shad"  , it is a instruction for sh3 . 
 so i change it to 

#define TARGET_DEFAULT  (0) 

just as it is in the standard gcc-2.95.2.
but the problem is when i use this gcc to compile the program , it has
error 

(.text+0x694): undefined reference to `__ashiftrt_r4_8'
(.text+0x774): undefined reference to `__ashiftrt_r4_8'  

anybody has the advice about it , i will appreciate in advance.


Cheers        
                      Henry.

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

[linuxsh-dev] test

[Henry <leg...@ya...>]

sorry ,just a test!

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

Re: [linuxsh-dev] glibc-2.2

[David H. <dho...@ca...>]

> This could be a gcc problem. I am having problems with shared libraries
> in the latest gcc 3.0 branch. Shared libraries appear to work fine with
> gcc 2.97 (20001120).

It's a binutils problem... libbfd doesn't handle RELA-type ELF relocations
properly and so bad binaries are produced. Some binutils person is currently
supposed to be sorting it out.

David

Re: [linuxsh-dev] glibc-2.2

[M. R. B. <ma...@uw...>]

On Tue, 6 Mar 2001, Denis Dowling wrote:

> "M. R. Brown" wrote:
> > 
> > I've built glibc-2.2 via the instructions on the LinuxSH page, and by
> > patching the requisite files (I used Niibe's debian patches as a guide).
> > The build process is smooth, no problems there.  However, when I boot
> > using the newly-installed libraries and dynamic linker, I get segmentation
> > faults everytime I run a dynamically-linked program.  I'm able to boot my
> > system using a statically-linked bash.
> > 
> > Just to test, I substituted Niibe's debian glibc-2.2 (from base), and
> > dynamically-linked programs worked perfectly.  I'm guessing it's a problem
> > buried in libc, because just swapping out ld-linux.so.2 ran the program,
> > but my system soon ran out of memory within libc.
> > 
> > So I'm curious, is there another build method for glibc (like which one
> > did you use Niibe?).  Oh yeah, I'm using a gcc as of yesterday :), maybe
> > my gcc is just broken?
> 
> This could be a gcc problem. I am having problems with shared libraries
> in the latest gcc 3.0 branch. Shared libraries appear to work fine with
> gcc 2.97 (20001120).
>

Ok, I've built glibc-2.2 with gcc-20001120 and still no-go.  This time
around, instead of a segfault I'm just getting "out of memory" errors from
the kernel.  Like I said, statically-linked programs are fine, so now it's
a problem with ld-2.2.so or my build process (or glibc target which is
sh4), because the glibc from NIIBE's distro works fine, and now I'm using
the same compiler and patches... 

Just to test, I have a static ls as "ls" and a dynamically-linked ls as
"dynls":

[from dmesg output]
Memory: 10700k/16384k available (1011k kernel code, 5684k reserved, 52k
data, 52k init)
Dentry-cache hash table entries: 2048 (order: 2, 16384 bytes)
Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes)
Page-cache hash table entries: 4096 (order: 2, 16384 bytes)
Inode-cache hash table entries: 1024 (order: 1, 8192 bytes)

[...]

block: queued sectors max/low 7000kB/2333kB, 64 slots per queue
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
RAMDISK: Compressed image found at block 0
Freeing initrd memory: 4096k freed

[...]

Freeing unused kernel memory: 52k freed
 init-2.03# 
init-2.03# ls
bin  dev  lib
init-2.03# dynls
Out of Memory: Killed process 8 (dynls).
Terminated

Has anyone come across this or am I missing something obvious :)?

M. R.

Re: [linuxsh-dev] glibc-2.2

[Denis D. <ddo...@po...>]

"M. R. Brown" wrote:
> 
> I've built glibc-2.2 via the instructions on the LinuxSH page, and by
> patching the requisite files (I used Niibe's debian patches as a guide).
> The build process is smooth, no problems there.  However, when I boot
> using the newly-installed libraries and dynamic linker, I get segmentation
> faults everytime I run a dynamically-linked program.  I'm able to boot my
> system using a statically-linked bash.
> 
> Just to test, I substituted Niibe's debian glibc-2.2 (from base), and
> dynamically-linked programs worked perfectly.  I'm guessing it's a problem
> buried in libc, because just swapping out ld-linux.so.2 ran the program,
> but my system soon ran out of memory within libc.
> 
> So I'm curious, is there another build method for glibc (like which one
> did you use Niibe?).  Oh yeah, I'm using a gcc as of yesterday :), maybe
> my gcc is just broken?

This could be a gcc problem. I am having problems with shared libraries
in the latest gcc 3.0 branch. Shared libraries appear to work fine with
gcc 2.97 (20001120).

Regard,
Denis.

[linuxsh-dev] glibc-2.2

[M. R. B. <ma...@uw...>]

I've built glibc-2.2 via the instructions on the LinuxSH page, and by
patching the requisite files (I used Niibe's debian patches as a guide).
The build process is smooth, no problems there.  However, when I boot
using the newly-installed libraries and dynamic linker, I get segmentation
faults everytime I run a dynamically-linked program.  I'm able to boot my
system using a statically-linked bash.

Just to test, I substituted Niibe's debian glibc-2.2 (from base), and
dynamically-linked programs worked perfectly.  I'm guessing it's a problem
buried in libc, because just swapping out ld-linux.so.2 ran the program,
but my system soon ran out of memory within libc.

So I'm curious, is there another build method for glibc (like which one
did you use Niibe?).  Oh yeah, I'm using a gcc as of yesterday :), maybe
my gcc is just broken?

M. R.

[linuxsh-dev] [PATCH] kernel_thread fix

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

Philipp Rumpf wrote:
 > I think there's an obvious bug in the current kernel_thread code:

Thanks.  You're right.  It seems that I've misunderstood that the
immediate value were sign-extended for "tst", which is not correct.
We didn't see the bug, because PID is young enough to be under 0xff.

And removing the "NOTE" is also good.  It's no longer valid statement
with real clone implementation, I think.

Will commit soon.
-- 

[linuxsh-dev] [PATCH] kernel_thread fix

[Philipp R. <pr...@ma...>]

I think there's an obvious bug in the current kernel_thread code:


--- linuxsh/kernel/arch/sh/kernel/process.c	Fri Feb 23 21:43:00 2001
+++ linux-aero/arch/sh/kernel/process.c	Sat Mar  3 19:30:37 2001
@@ -138,11 +138,6 @@
 
 /*
  * This is the mechanism for creating a new kernel thread.
- *
- * NOTE! Only a kernel-only process(ie the swapper or direct descendants
- * who haven't done an "execve()") should use this: it will work within
- * a system call from a "real" process, but the process memory space will
- * not be free'd until both the parent and the child have exited.
  */
 int kernel_thread(int (*fn)(void *), void * arg, unsigned long flags)
 {	/* Don't use this in BL=1(cli).  Or else, CPU resets! */
@@ -154,7 +149,7 @@
 	register unsigned long __sc9 __asm__ ("r9") = (long) fn;
 
 	__asm__("trapa	#0x12\n\t" 	/* Linux/SH system call */
-		"tst	#0xff, r0\n\t"	/* child or parent? */
+		"tst	r0, r0\n\t"	/* child or parent? */
 		"bf	1f\n\t"		/* parent - jump */
 		"jsr	@r9\n\t"	/* call fn */
 		" mov	r8, r4\n\t"	/* push argument */

Did I miss anything ?

Re: [linuxsh-dev] Handling multiple interrupts

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

"M. R. Brown" wrote:
> 

G'day

> Does anyone know a nice, clean way (or not so clean) to handle multiple
> incoming interrupts from within controller-specific (e.g. setup_xxx.c)
> code?  irq_demux() doesn't cut it as it only returns one int per IRQ (but
> I receive at least one normal int and two NMIs per IRQ), and even if I
> wanted to queue ints within irq_demux, the semantics wouldn't work as I
> have no pt_regs structure with which to call handle_IRQ_event.
> 
> Reading other archs and linuxsh sources didn't help, has anyone had to
> deal with this?
> 

  I had to muck about with IRQ handling to get PCMCIA working right.
It seems to me there's a fairly strong assumption in the code that
one hardware IRQ = one software IRQ handler called.   This assumption
seems to break when interrupt muxing hardware is used, but actually
it doesn't because of the way muxes work.  What normally happens with
muxed IRQ is:

1.  mux hardware gets interrupt from module A
2.  mux hw gets interrupt from module B
3.  mux hardware sends IRQ to CPU by asserting its IRQ line
4.  CPU services IRQ. Linux masks the IRQ line from the mux
    (through the hw_interrupt_type) and calls irq_demux()
5.  irq_demux() reads a register from the mux, sees
    that module A has generated an interrupt, clears that
    bit in the register, and returns the (virtual) IRQ number
    for module A.
6.  Linux calls registered handlers for the module A IRQ number.
7.  Linux unmasks the IRQ line from the mux (again through
    hw_interrupt_type)
8.  The mux at this point knows that the interrupt from module
    A has been serviced by the CPU, but that another interrupt
    from module B is still pending, so it has kept the IRQ line
    to the CPU asserted.  This immediately triggers another IRQ
    in the CPU.
9.  Linux repeats steps 4-7, this time dispatching registered
    handlers for the virtual IRQ number for module B.
10. The mux has now had both interrupts serviced and finally
    de-asserts its IRQ line to the CPU, so its all over.

  In other words, this relies on the interrupt mux hardware
being able to sensibly store state for its various modules,
which is a fairly basic requirement.  The above sequence
describes how the interrupt controller in the HD64465
companion chip works.

  If you have some hardware that behaves differently, you
might need to do something different; otherwise you can use
the existing Linux arrangement.  Certainly by setting up your
own hw_interrupt_type and irq_demux() you can do all sorts
of clever things, but the question is: do you need to?

  Can you explain a bit more about your setup?

Greg.  
-- 
These are my opinions not PPIs.

[linuxsh-dev] Handling multiple interrupts

[M. R. B. <ma...@uw...>]

Does anyone know a nice, clean way (or not so clean) to handle multiple
incoming interrupts from within controller-specific (e.g. setup_xxx.c)
code?  irq_demux() doesn't cut it as it only returns one int per IRQ (but
I receive at least one normal int and two NMIs per IRQ), and even if I
wanted to queue ints within irq_demux, the semantics wouldn't work as I
have no pt_regs structure with which to call handle_IRQ_event.

Reading other archs and linuxsh sources didn't help, has anyone had to
deal with this?

M. R.

Re: [linuxsh-dev] SH-4 RTC

[Philipp R. <pr...@pa...>]

On Sun, Feb 18, 2001 at 12:22:23PM +0900, NIIBE Yutaka wrote:
> If it's true, we need to fix our RTC related code.  Could you please
> check your CPU?  How about chips by ST?

This doesn't seem to happen on my SH-4 (SH7750 clocked at 128 MHz)

[linuxsh-dev] calibrate delay loop & jiffies

[Studencki P. <Paw...@er...>]

Hi,

could someone explain a problem with jiffies? Where are they counted on?
I've seen some code in arch/sh/kernel/time.c about this, but no jiffies
variable exactly. I compared files time.c from kernel 2.4.0 with older
2.3.99 and there some modifications in new kernels, so these could be a
reason of problems with jiffies, do they depend on platform?

The problem with printf has been solved...ok...perhaps not solved, but I
found a reason:
in driver/char/n_tty.c, function write_chan calls schedule(), after that the
programm stops, it means: I don't see printf outputs any more. 
I hope, if I repare jiffies stuff, I'll also get working schedule() in
write_chan.

Perhaps has someone faced same problem? Or has any idea about jiffies?

regards
Pawel

RE: [linuxsh-dev] new kernel, new-old problems

[Studencki P. <Paw...@er...>]

Hello, it's me again...

I'm not sure, but I hope, I find the reason of my problems...
I didn't mentioned in last mail, that I delete 'calibrate_delay();' from
init/main.c
It's not a solution, but after that kernel was going on. the problem is,
values of jiffies is const. I'm not a kernel hacker, (jiffies is art of time
counter - all I know) and I really have no idea, what caused this
behaviour!?

void __init calibrate_delay(void)
{
        unsigned long ticks, loopbit;
        int lps_precision = LPS_PREC;

        loops_per_sec = (1<<12);

        printk("Calibrating delay loop... ");

        while (loops_per_sec <<= 1) {
                /* wait for "start of" clock tick */
                ticks = jiffies;
                printk("before sub while\n");
                while (ticks == jiffies)           <======= jiffies hasn't
been changed !!!!
                 /* nothing */;
                /* Go ..   */
                ticks = jiffies;

Second thing (perhaps it's related to calibrate delay loop)
With a kernel 2.4.0, I get:			with 2.3.99-pre7:
CPU clock: 75.17MHz				same CPU
Bus clock: 25.05MHz				no info about bus
Module clock: 25.05MHz				Module 75.18 MHz !!!!
Interval = 62648					Interval 187965

with 2.3.99-pre7 everything works OK.

could it be a cause of all other problems or it's not important?
How can I correct these values?

I would be grateful for any help
Pawel



> Short description:
> software: kernel-2.4.0-test11, glibc-2.2.2
> hardware: SH0079, SH3, debug with SCI
> 
> I created this devices in folder /dev
> 
> drwxr-xr-x   2 root     root         1024 Feb 23 17:42 .
> drwxr-xr-x  10 root     root         1024 Feb 22 11:57 ..
> lrwxrwxrwx   1 root     root            6 Feb 23 17:42 
> console -> ttySC0
> crwxrwxrwx   1 root     root       1,   2 Feb 22 13:51 kmem
> crwxrwxrwx   1 root     root     255, 255 Feb 22 13:51 log
> crwxrwxrwx   1 root     root       1,   1 Feb 22 13:51 mem
> crwxrwxrwx   1 root     root       1,   3 Feb 22 13:51 null
> lrwxrwxrwx   1 root     root            4 Feb 22 13:52 ram -> ram0
> brwxrwxrwx   1 root     root       1,   0 Feb 22 13:50 ram0
> crwxrwxrwx   1 root     root       5,   0 Feb 22 14:49 tty
> crwxrwxrwx   1 root     root     204,   8 Feb 22 13:56 ttySC0
> --------------------------------------------------------------
> --------------
> 
> as INIT program I'm starting:
> 
> --------------------------------------------------------------
> --------------
> -----
> 
> #include<stdio.h>
> #include<sys/types.h>
> #include<fcntl.h>
> int main (void)
> {
> int i,fd;
> 
>         for(fd=0;;fd++)
>         {
> 
>         printf("hello %d \n",fd);
> 
>         }
> fflush(NULL);
> 
> return 1;
> }
> --------------------------------------------------------------
> --------------
> 
> so I get following boot messages on my terminal:
> 
> --------------------------------------------------------------
> --------------
> -
> 
> Linux version 2.4.0-test11 (root@capella) (gcc version 2.97 20001120
> (experiment
> al)) #190 Fri Feb 23 17:44:50 MET 2001
> On node 0 totalpages: 4096
> zone(0): 4096 pages.
> zone(1): 0 pages.
> zone(2): 0 pages.
> Kernel command line: console=ttySC0,38400
> SH RTC: invalid value, resetting to 1 Jan 2000
> CPU clock: 75.17MHz
> Bus clock: 25.05MHz
> Module clock: 25.05MHz
> Interval = 62650
> Memory: 14216k/16384k available (648k kernel code, 2168k 
> reserved, 24k data,
> 28k
>  init)
> Dentry-cache hash table entries: 2048 (order: 2, 16384 bytes)
> Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes)
> Page-cache hash table entries: 4096 (order: 2, 16384 bytes)
> Inode-cache hash table entries: 1024 (order: 1, 8192 bytes)
> CPU: SH7707/SH7708/SH7709
> POSIX conformance testing by UNIFIX
> Linux NET4.0 for Linux 2.4
> Based upon Swansea University Computer Society NET3.039
> Starting kswapd v1.8
> RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
> RAMDISK: ext2 filesystem found at block 0
> RAMDISK: Loading 1024 blocks [1 disk] into ram disk... done.
> Freeing initrd memory: 1024k freed
> SuperH SCI(F) driver initialized
> ttySC0 at 0xfffffe80 is a SCI
> ttySC1 at 0xa4000150 is a SCIF
> ttySC2 at 0xa4000140 is a SCIF
> NET4: Linux TCP/IP 1.0 for NET4.0
> IP Protocols: ICMP, UDP, TCP
> IP: routing cache hash table of 512 buckets, 4Kbytes
> TCP: Hash tables configured (established 1024 bind 1024)
> VFS: Mounted root (ext2 filesystem).
> Freeing unused kernel memory: 28k freed
> sci open
> set real termios
> baud - 38400
> sci open
> baud - 38400
> *** Before INIT ***
> Hello world
> Hello world 2
> hello 0
> hello 1
> hello 2
> hello 3
> hello 4
> hello 5
> [...]
> hello 17
> hello 18
> hello 19
> hello 20
> hello 21
> hello 22
> hello 23
> hello 24
> 
> ----------------------------------------------------------------------
> 
> as you can see, my program stops at "hello 24" . I don't know 
> why :) That's
> perhaps stupid, but I'm tring last days to get the reason of this
> behaviour...
> Serial console transmits only a certain number of chars or 
> console works
> properly only certain period???
> 
> with older kernels I had the same problem,nearly the 
> same...Once, my program
> was to short (5 steps in "for" loop), so it has been 
> "killed", before he
> could send all strings to console.
> But this time, the loop is endless!
> could this a problem with glibc-2.2.2? my next step will be 
> change the Glibc
> to older one...
> but perhaps could you advice me something??
> 
> have a nice weekend
> Pawel
> 
> _______________________________________________
> linuxsh-dev mailing list
> lin...@li...
> http://lists.sourceforge.net/lists/listinfo/linuxsh-dev
> 

[linuxsh-dev] new kernel, new-old problems

[Studencki P. <Paw...@er...>]

Hello everybody,


I really don't, how it's possible, that I'm still getting the same errors as
with older kernels and libs...I thougth, I know these tricks and problem
reasons...that's naturally not true :)

Short description:
software: kernel-2.4.0-test11, glibc-2.2.2
hardware: SH0079, SH3, debug with SCI

I created this devices in folder /dev

drwxr-xr-x   2 root     root         1024 Feb 23 17:42 .
drwxr-xr-x  10 root     root         1024 Feb 22 11:57 ..
lrwxrwxrwx   1 root     root            6 Feb 23 17:42 console -> ttySC0
crwxrwxrwx   1 root     root       1,   2 Feb 22 13:51 kmem
crwxrwxrwx   1 root     root     255, 255 Feb 22 13:51 log
crwxrwxrwx   1 root     root       1,   1 Feb 22 13:51 mem
crwxrwxrwx   1 root     root       1,   3 Feb 22 13:51 null
lrwxrwxrwx   1 root     root            4 Feb 22 13:52 ram -> ram0
brwxrwxrwx   1 root     root       1,   0 Feb 22 13:50 ram0
crwxrwxrwx   1 root     root       5,   0 Feb 22 14:49 tty
crwxrwxrwx   1 root     root     204,   8 Feb 22 13:56 ttySC0
----------------------------------------------------------------------------

as INIT program I'm starting:

----------------------------------------------------------------------------
-----

#include<stdio.h>
#include<sys/types.h>
#include<fcntl.h>
int main (void)
{
int i,fd;

        for(fd=0;;fd++)
        {

        printf("hello %d \n",fd);

        }
fflush(NULL);

return 1;
}
----------------------------------------------------------------------------

so I get following boot messages on my terminal:

----------------------------------------------------------------------------
-

Linux version 2.4.0-test11 (root@capella) (gcc version 2.97 20001120
(experiment
al)) #190 Fri Feb 23 17:44:50 MET 2001
On node 0 totalpages: 4096
zone(0): 4096 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: console=ttySC0,38400
SH RTC: invalid value, resetting to 1 Jan 2000
CPU clock: 75.17MHz
Bus clock: 25.05MHz
Module clock: 25.05MHz
Interval = 62650
Memory: 14216k/16384k available (648k kernel code, 2168k reserved, 24k data,
28k
 init)
Dentry-cache hash table entries: 2048 (order: 2, 16384 bytes)
Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes)
Page-cache hash table entries: 4096 (order: 2, 16384 bytes)
Inode-cache hash table entries: 1024 (order: 1, 8192 bytes)
CPU: SH7707/SH7708/SH7709
POSIX conformance testing by UNIFIX
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Starting kswapd v1.8
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
RAMDISK: ext2 filesystem found at block 0
RAMDISK: Loading 1024 blocks [1 disk] into ram disk... done.
Freeing initrd memory: 1024k freed
SuperH SCI(F) driver initialized
ttySC0 at 0xfffffe80 is a SCI
ttySC1 at 0xa4000150 is a SCIF
ttySC2 at 0xa4000140 is a SCIF
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 1024 bind 1024)
VFS: Mounted root (ext2 filesystem).
Freeing unused kernel memory: 28k freed
sci open
set real termios
baud - 38400
sci open
baud - 38400
*** Before INIT ***
Hello world
Hello world 2
hello 0
hello 1
hello 2
hello 3
hello 4
hello 5
[...]
hello 17
hello 18
hello 19
hello 20
hello 21
hello 22
hello 23
hello 24

----------------------------------------------------------------------

as you can see, my program stops at "hello 24" . I don't know why :) That's
perhaps stupid, but I'm tring last days to get the reason of this
behaviour...
Serial console transmits only a certain number of chars or console works
properly only certain period???

with older kernels I had the same problem,nearly the same...Once, my program
was to short (5 steps in "for" loop), so it has been "killed", before he
could send all strings to console.
But this time, the loop is endless!
could this a problem with glibc-2.2.2? my next step will be change the Glibc
to older one...
but perhaps could you advice me something??

have a nice weekend
Pawel

Re: [linuxsh-dev] HD64461 & PCMCIA

[Mitch D. <md...@po...>]

Studencki Pawel wrote:
> 
> > Hey you're welcome.  All the very best!
> >
> > I personally think it would be good to see if you could get either
> > Jesper's or Greg's card stuff ported and going.  It might not take
> > too long, and it will be a better option in the long run.

Pawel, note you've quoted mail I sent you in private.

> Is ide bios necessary for working with ide-FlashDisks?

We are using SanDisk 20mb ATA flashdisk cards, which look like IDE disks.
We don't use anything BIOS-related - it's all in the ide-* kernel modules.

Regards,

Mitch.
--
mailto:mj...@al...
mailto:md...@po...

Re: [linuxsh-dev] HD64461 & PCMCIA

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

Studencki Pawel wrote:
> Is ide bios necessary for working with ide-FlashDisks? 

  No.

> If I use a WinCE
> bootloader, I can't work with gdb sh-stub

  The IDE support in sh-ipl is only for booting from IDE devices.
Once you're in Linux that isn't used anymore.

> (on my SH board, network interface
> (with PCMCIA card) doesn't work and download with serial interface (gdb)
> takes to much time, with WinCE I can use parallel port but without ide
> bios).

  The best thing about getting a PCMCIA network card working, is that
afterward you can "scp" programs and kernel modules to the target ;-)

Greg.
-- 
These are my opinions not PPIs.

RE: [linuxsh-dev] HD64461 & PCMCIA

[Studencki P. <Paw...@er...>]

Hello :)

> Hey you're welcome.  All the very best!
> 
> I personally think it would be good to see if you could get either
> Jesper's or Greg's card stuff ported and going.  It might not take
> too long, and it will be a better option in the long run.

Yeah, I think you absolutely right :)
Thanks to Greg's tips and pcmcia how-to for developers (!) I get the general
idea, how it should be working. I try to compile Jesper's socket driver,
pcmcia_core.o, device drivers for ne2000.
we will see :)
Is ide bios necessary for working with ide-FlashDisks? If I use a WinCE
bootloader, I can't work with gdb sh-stub (on my SH board, network interface
(with PCMCIA card) doesn't work and download with serial interface (gdb)
takes to much time, with WinCE I can use parallel port but without ide
bios).

regards
Pawel

Re: [linuxsh-dev] GNU CVS gcc -- fixup for -m4-nofpu

[M. R. B. <ma...@uw...>]

On Tue, 20 Feb 2001, Bryan Rittmeyer wrote:

> Hmmm... Well, even with the patches I posted previously, I'm having
> trouble building the Linux kernel (2.4.1 out of LinuxSH CVS)... the
> problem is with our old friends __sdivsi3_i4, __udivsi3_i4, __udivsi3
> and __sdivsi3. They are preventing linkage because they're undefined.
> Any idea how to fix this problem?
>

Heh, those four have caused me many headaches :).  Here's what I know
(from the gcc sources):

Each of those funtions represent integer divide code ... they're all
defined in gcc/config/sh/lib1funcs.asm.  Each of these routines are
conditionally compiled into libgcc based on the cppspecs that define those
architecture macros (__SH4__, __SH4_SINGLE__, __SH4_SINGLE_ONLY__) because
most of them (except for two which are there for compatibility) are pure
floating-point. 

In your previous post you said you were configuring gcc with
--disable-multilib.  Well, the sh-linux-gnu Makefile fragment (t-linux) 
overrides the standard t-sh fragment which allows for a -m4-nofpu version
of libgcc (I don't know if this would resolve those references).  Is there
a reason why you're disabling multilib?  The default flags from the specs
in linux.h specify compiling for an SH3 (everything defaults to -m3),
which would explain why those FP routines aren't pulled into libgcc.a.
So, you either want to leave multilib enabled, or change the defaults in
linux.h to generate code for the SH4 (my patches do this).

I hope I was somewhat coherent bacause it's late where I am and I'm
working on a few things at once :)
 
M. R.

RE: [linuxsh-dev] HD64461 & PCMCIA

[Studencki P. <Paw...@er...>]

> Hi Pawel,
> 
> It seems I've found it.
> 
  http://semiconductor.hitachi.com/products/pdf/h1cth005d1.pdf

> This was after a LOT of digging.  

thanks a lot Mitch! :)


regards 
Pawel