From HenrySimmons17 at netzero.net  Sat Mar  1 02:14:14 2003
From: HenrySimmons17 at netzero.net (HenrySimmons17)
Date: Fri, 28 Feb 2003 23:14:14 -0800
Subject: [uClinux-dev] UCLINUX for PALM
References: <Pine.GSO.4.33.0302111240390.25930-100000@compserv1> <015801c2d222$ca8f38a0$ffc5fea9@henry133> <3E50444D.4010600@tbc.net> <004901c2d64e$13223fc0$ffc5fea9@henry133> <3E50E9DE.7050801@tbc.net> <000201c2d6d6$0d03e660$ffc5fea9@henry133> <3E524F5D.8020206@tbc.net> <000201c2d770$e5711e60$ffc5fea9@henry133> <3E5EB086.1070108@tbc.net> <000201c2dee8$065974a0$ffc5fea9@henry133> <3E5FE502.1060106@tbc.net>
Message-ID: <000201c2dfc2$762ceb60$ffc5fea9@henry133>

You are looking to see how your registers are configured
so you can set FFFFF116
 in vendors/3com/palm-loader/PalmLoader.c.
correctly.
Set up debugger again  running in shortcut ..1 mode.
type att
type dm fffff116
It will look approximately like this:
dm fffff116
FFFFF116: 3A 81 00 60 00 00 00 00   00 00 00
the first 4 characters is the register setting. I my case it's 3A81.
Setting them in hex is 0x3a81.
The value you read from the debugger you replace (in 2 places in hex) in the
file:
vendors/3com/palm-loader/PalmLoader.c.
example:
asm volatile (" movew #0x3a81, 0xfffff116");
Henry
From: Michael F. Sharp <mikes at tbc.net>out
To: <uclinux-dev at uclinux.org>
Sent: Friday, February 28, 2003 2:38 PM
Subject: Re: [uClinux-dev] UCLINUX for PALM


> Henry,
> Thanks for the link to the debugger. Since I don't know what I'm looking
> at here, I'll show you what I see when I get the debugger up and running
> with Palm IIIc running in shortcut . 1 mode, and when I type att at the
> Debugger window. Hope this helps..... if there is anything particular I
> need to do with the debugger to get you more information, let me know :)
>
> Cheers,
> Mike





From Thomas.Eschenbacher at gmx.de  Sat Mar  1 03:47:22 2003
From: Thomas.Eschenbacher at gmx.de (Thomas Eschenbacher)
Date: Sat, 01 Mar 2003 09:47:22 +0100
Subject: [uClinux-dev] nfs mount question
In-Reply-To: <3E603857.7E97D22@on-go.com>
References: <3E603857.7E97D22@on-go.com>
Message-ID: <3E60739A.2060207@gmx.de>

thomas chen wrote:
> [...]
> mount -t nfs 192.168.1.200:/home /usr
> 
> if first complain that mount is older than the kernel?
> and then NFS complain mount did not pass remote address?
> 
> did i miss something

Maybe you need to specify the nfs version in the command line. That
parameter should be in the man page of mount (nfsver=... or similar).

Additionally, I always mount with the options "-o nolock,noac"
which removes the need for a running portmap and locking.

hope this helps,
Thomas
-- 
________________________________________________________________________
Thomas Eschenbacher <Thomas.Eschenbacher at gmx.de> [LANG=de_DE | en_EN]



From eauth at softsys.co.at  Sat Mar  1 04:15:39 2003
From: eauth at softsys.co.at (Erwin Authried)
Date: Sat, 1 Mar 2003 10:15:39 +0100
Subject: [uClinux-dev] nfs mount question
In-Reply-To: <3E603857.7E97D22@on-go.com>
Message-ID: <CBEPKHHODMBKHCMLAGBMAEJPCCAA.eauth@softsys.co.at>


> -----Ursprungliche Nachricht-----
> Von: uclinux-dev-admin at uclinux.org
> [mailto:uclinux-dev-admin at uclinux.org]Im Auftrag von thomas chen
> Gesendet: Samstag, 01. Marz 2003 05:35
> An: uclinux-dev at uclinux.org
> Betreff: [uClinux-dev] nfs mount question
>
>
>
> how do you mount nfs from an embedded target
>
> i have busybox mount
>
> when i did
>
> mount -t nfs 192.168.1.200:/home /usr
>
> if first complain that mount is older than the kernel?
> and then NFS complain mount did not pass remote address?
>
> did i miss something
>

On uclinux:
- CONFIG_NFS_FS must be enabled
- uClibc must be compiled with the RPC library support.
- Busybox must be compiled with NFS support.

On the host:
- CONFIG_NFSD and CONFIG_SUNRPC must be enabled. I think the *_V3 stuff must
be disabled.

Some people said that portmap must run on uClinux. I found that it works
without that too, you just get a few error messages when the fs is mounted.

Regards,
Erwin



From andersen at codepoet.org  Sat Mar  1 04:25:27 2003
From: andersen at codepoet.org (Erik Andersen)
Date: Sat, 1 Mar 2003 02:25:27 -0700
Subject: [uClinux-dev] nfs mount question
In-Reply-To: <CBEPKHHODMBKHCMLAGBMAEJPCCAA.eauth@softsys.co.at>
References: <3E603857.7E97D22@on-go.com> <CBEPKHHODMBKHCMLAGBMAEJPCCAA.eauth@softsys.co.at>
Message-ID: <20030301092527.GA10598@codepoet.org>

On Sat Mar 01, 2003 at 10:15:39AM +0100, Erwin Authried wrote:
> On uclinux:
> - CONFIG_NFS_FS must be enabled
> - uClibc must be compiled with the RPC library support.
> - Busybox must be compiled with NFS support.

BTW, I've got a patch I need to commit to Busybox that will allow
you to do NFS mounts directly, without needing to enable RPC
support in uClibc.  It should save quite a lot of space...

 -Erik

--
Erik B. Andersen             http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--


From woodyds77 at yahoo.co.uk  Sat Mar  1 07:29:08 2003
From: woodyds77 at yahoo.co.uk (=?iso-8859-1?q?flupke=20flopke?=)
Date: Sat, 1 Mar 2003 12:29:08 +0000 (GMT)
Subject: [uClinux-dev] How to config Samba on uClinux
In-Reply-To: <20030228125152.47780.qmail@web20707.mail.yahoo.com>
Message-ID: <20030301122908.65005.qmail@web20705.mail.yahoo.com>


Hi
I have still a few questions. 
1. My smb.conf file, in which directory does I put
him? And what do you mean with "smb.conf for host name
and group, remember that here hostname must match the
one in /etc/rc."

2. Does I have to make my own passwd file? And so,
where must I make him (put him)?

I have running samba on my linux PC without any
problem. But in uClinux it's so different! 
For example:
After compiling my uClinux kernel for the dragon.
(make clean,make menuconfig, make dep, make)

I go to the directory /romfs and put my own
directory's in it with my smb.conf file( 
/usr/local/samba/lib). Then I do: make. 
When I boot this kernel I see my smb.conf file. 
I start nmbd but he doesn't apear in my running
processes! 

Thanks for helping a newbie and for your time.
 Wouter De Smedt
 Last year student




---------------------------------
With Yahoo! Mail you can get a bigger mailbox -- choose a size that fits your needs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20030301/68e396dc/attachment.html>

From masterkristof at yahoo.com  Sat Mar  1 08:08:59 2003
From: masterkristof at yahoo.com (Kristof Bruyninckx)
Date: Sat, 1 Mar 2003 05:08:59 -0800 (PST)
Subject: [uClinux-dev] compiling error's after making changes to support ATAPI
Message-ID: <20030301130859.31191.qmail@web11001.mail.yahoo.com>

Hi,

I've rebuilded my toolchain to include the folowing
patch:
http://www.uclinux.org/ports/coldfire/gcc-2.95.3-m68k-zext.patch
 Then I made the following adjustments to get rid of
some  errors I got when I inculded ATAPI cd rom
support:

1. linux-2.4.x/inlude/linux/genhd.h:
fixup:
     remove the two unsigned in struct hd_struct

2. drivers/ide/ide-proc.c : unknow enum item for
ide_acorn

here I deleted line 718 in the /proc.c where acorn was
located.

3. drivers/ide/ide-probe.c : obvious error at
hwif->hw.io_ports where 
hw. missed.

and here I included hw in line 725 of ide-probe.c so
this line became:
Out_byte(0x08,HWF > hw.io.ports [IDE_CONTROLS_OFFSET];

now after I had done all this the compiling errors of
the ide support stopped. But now the problem is that I
am gething errors because I include ISO 9660 support.
(see attachement error7.txt). But when I don't include
  ISO 9660 support I again get errors.And when I try
to compile a default kernel I get exactly the same
errors as when I do not include ISO 9660 support.(see
attachement error8.txt)
Does anyone know how to fix these errors?? Any advice
or tips are very welkom.

yours truly and hoping for a reply,

kristof  

=====


__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: erorrs7.txt
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20030301/ef40cea3/attachment.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: error8.txt
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20030301/ef40cea3/attachment-0001.txt>

From richard.klingler at violasystems.com  Sat Mar  1 08:18:50 2003
From: richard.klingler at violasystems.com (Richard Klingler)
Date: Sat,  1 Mar 2003 15:18:50 +0200
Subject: [uClinux-dev] compiling error's after making changes to support ATAPI
In-Reply-To: <20030301130859.31191.qmail@web11001.mail.yahoo.com>
Message-ID: <r01050400-1024-57C53C244BE811D7BC7D00039387ACB6@[10.0.1.2]>

Hi (o;

> rock.c:311: structure has no member named `__times'
> rock.c:330: structure has no member named `__link'

Change them to "times" and "link" (o;


Rick


Richard Klingler             mail: richard.klingler at violasystems.com
Viola Systems Ltd.           http://www.violasystems.com/
Lemmink?isenkatu 32          phon: +358 (0)201 226 226
20520 Turku, Finland         mobile: +358 (0)40 748 4711


From masterkristof at yahoo.com  Sat Mar  1 08:52:26 2003
From: masterkristof at yahoo.com (Kristof Bruyninckx)
Date: Sat, 1 Mar 2003 05:52:26 -0800 (PST)
Subject: [uClinux-dev] compiling error's after making changes to support ATAPI
In-Reply-To: <r01050400-1024-57C53C244BE811D7BC7D00039387ACB6@[10.0.1.2]>
Message-ID: <20030301135226.90814.qmail@web11002.mail.yahoo.com>

hi,

ok I've done what you adviced and I also changed line
435 it seemed to have the same error report as line
330. so  I changed __line there to line. And these
errors are gone. But not completly. the errors I am
getting now are these.

yours truly and hoping for a reply

kristof




--- Richard Klingler
<richard.klingler at violasystems.com> wrote:
> Hi (o;
> 
> > rock.c:311: structure has no member named
> `__times'
> > rock.c:330: structure has no member named `__link'
> 
> Change them to "times" and "link" (o;
> 
> 
> Rick
> 
> 
> Richard Klingler             mail:
> richard.klingler at violasystems.com
> Viola Systems Ltd.          
> http://www.violasystems.com/
> Lemmink?isenkatu 32          phon: +358 (0)201 226
> 226
> 20520 Turku, Finland         mobile: +358 (0)40 748
> 4711
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
>
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org

=====


__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: error11.txt
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20030301/b3c7ec95/attachment.txt>

From richard.klingler at violasystems.com  Sat Mar  1 09:09:47 2003
From: richard.klingler at violasystems.com (Richard Klingler)
Date: Sat,  1 Mar 2003 16:09:47 +0200
Subject: [uClinux-dev] compiling error's after making changes to support ATAPI
In-Reply-To: <20030301135226.90814.qmail@web11002.mail.yahoo.com>
Message-ID: <r01050400-1024-761D9FDC4BEF11D7BC7D00039387ACB6@[10.0.1.2]>

Hi

> fs/fs.o: In function `isofs_lookup':
> /uClinux-dist/linux-2.4.x/fs/isofs/namei.c:171: undefined reference to 
> `phys_to_virt'

Never saw this (o;


Rick



Richard Klingler             mail: richard.klingler at violasystems.com
Viola Systems Ltd.           http://www.violasystems.com/
Lemmink?isenkatu 32          phon: +358 (0)201 226 226
20520 Turku, Finland         mobile: +358 (0)40 748 4711


From tchen at on-go.com  Sat Mar  1 11:17:38 2003
From: tchen at on-go.com (thomas chen)
Date: Sat, 01 Mar 2003 11:17:38 -0500
Subject: [uClinux-dev] compiling error's after making changes to support 
 ATAPI
References: <r01050400-1024-761D9FDC4BEF11D7BC7D00039387ACB6@[10.0.1.2]>
Message-ID: <3E60DD22.B1E2ED38@on-go.com>


thanks... i had everything except turning on mount/nfs option

however.. now i am getting
rpc timeout error?
and
nfs: mount did not pass remote address


what could this be?


Erwin Authried wrote:
> 
> > -----Ursprungliche Nachricht-----
> > Von: uclinux-dev-admin at uclinux.org
> > [mailto:uclinux-dev-admin at uclinux.org]Im Auftrag von thomas chen
> > Gesendet: Samstag, 01. Marz 2003 05:35
> > An: uclinux-dev at uclinux.org
> > Betreff: [uClinux-dev] nfs mount question
> >
> >
> >
> > how do you mount nfs from an embedded target
> >
> > i have busybox mount
> >
> > when i did
> >
> > mount -t nfs 192.168.1.200:/home /usr
> >
> > if first complain that mount is older than the kernel?
> > and then NFS complain mount did not pass remote address?
> >
> > did i miss something
> >
> 
> On uclinux:
> - CONFIG_NFS_FS must be enabled
> - uClibc must be compiled with the RPC library support.
> - Busybox must be compiled with NFS support.
> 
> On the host:
> - CONFIG_NFSD and CONFIG_SUNRPC must be enabled. I think the *_V3 stuff must
> be disabled.
> 
> Some people said that portmap must run on uClinux. I found that it works
> without that too, you just get a few error messages when the fs is mounted.
> 
> Regards,
> Erwin
> 
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org


From david.coldfire at tiscali.co.uk  Sat Mar  1 11:51:11 2003
From: david.coldfire at tiscali.co.uk (David Anderson)
Date: Sat, 1 Mar 2003 16:51:11 -0000
Subject: [uClinux-dev] Offtopic: uClinux engineering work wanted....
Message-ID: <NGBBIPJEALHLKCKNJMHKIEDHCCAA.david.coldfire@tiscali.co.uk>

Hello folks,

I'm looking for contract development work in the uCLinux field. I'm
specifically familiar with the Coldfire family of processors, and can design
device drivers, boot loaders, flash programmer, application code etc. for
networked, serial comms, and control/instrumentation type products. General
C and assembler language programming. Good hardware design knowledge.

I would either tender or agree an hourly rate with any potential client(s),
and perform all development work in the U.K. .

David J.Anderson, B.Sc(Eng), MIEE.

mailto:david.anderson at devandes.com
----------------------------------
David Anderson, Church Hatch
22 Market Place, Ringwood.
Hants. U.K. BH24 1AW
tel ( mobile) : 0775-2446520
--------------------------



From tchen at on-go.com  Sat Mar  1 16:42:54 2003
From: tchen at on-go.com (thomas chen)
Date: Sat, 01 Mar 2003 16:42:54 -0500
Subject: [uClinux-dev] structure size ????
Message-ID: <3E61295E.9689D758@on-go.com>

i have a structure that is 10 bytes long... on the target side
(arm) arm-elf-gcc expand that to multiple of 4, ie 12 bytes...
but on the intel pc side, it is still 10 bytes...  any way to pack
the structure but without violating the arm alignment problem...
ie if the structure is 9 byte long, i want to pack it to 10 instead
of just 9....

thanks


From staskh at attbi.com  Sat Mar  1 21:53:24 2003
From: staskh at attbi.com (Stas Khirman)
Date: Sat, 1 Mar 2003 18:53:24 -0800
Subject: [uClinux-dev] ARM Toolchain For Cygwin HOWTO?
References: <3E61295E.9689D758@on-go.com>
Message-ID: <002e01c2e066$e5974fa0$663da8c0@Staslap>

If I remember correctly, a while ago someone publish in this list an
excellent HOWTO build ARM toolchain for Cygwin ( and RH) environment.
Unfortunately., I can't find this past mail. Does someone have a pointer to
it ( or pointer to any other similar HOWTOs)

Thank you
Stas



From jokyman at sina.com  Sat Mar  1 22:06:34 2003
From: jokyman at sina.com (Thierry Zhong)
Date: Sun, 2 Mar 2003 11:6:34 +0800
Subject: [uClinux-dev] ARM Toolchain For Cygwin HOWTO?
Message-ID: <200303020302.h2232jF13449@uclinux.org>

Stas Khirman,???

You can go to the searchable maillist or use google to search for it.

======= 2003-03-01 18:53:00 ????????=======

>If I remember correctly, a while ago someone publish in this list an
>excellent HOWTO build ARM toolchain for Cygwin ( and RH) environment.
>Unfortunately., I can't find this past mail. Does someone have a pointer to
>it ( or pointer to any other similar HOWTOs)
>
>Thank you
>Stas
>
>_______________________________________________
>uClinux-dev mailing list
>uClinux-dev at uclinux.org
>http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
>This message was resent by uclinux-dev at uclinux.org

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

?????????
??
 
				 
????????Thierry Zhong
????????jokyman at sina.com
??????????2003-03-02






From mikes at tbc.net  Sat Mar  1 22:02:21 2003
From: mikes at tbc.net (Michael F. Sharp)
Date: Sat, 01 Mar 2003 21:02:21 -0600
Subject: [uClinux-dev] UCLINUX for PALM
References: <Pine.GSO.4.33.0302111240390.25930-100000@compserv1> <015801c2d222$ca8f38a0$ffc5fea9@henry133> <3E50444D.4010600@tbc.net> <004901c2d64e$13223fc0$ffc5fea9@henry133> <3E50E9DE.7050801@tbc.net> <000201c2d6d6$0d03e660$ffc5fea9@henry133> <3E524F5D.8020206@tbc.net> <000201c2d770$e5711e60$ffc5fea9@henry133> <3E5EB086.1070108@tbc.net> <000201c2dee8$065974a0$ffc5fea9@henry133> <3E5FE502.1060106@tbc.net> <000201c2dfc2$762ceb60$ffc5fea9@henry133>
Message-ID: <3E61743D.6000901@tbc.net>

Henry,
I got the debugger fired up, and typed in the commands, which yielded:

3e8f

I put this into line 140 of Palmloader.c, and compiled the kernel.

Well, as luck would have it, the uClinux.prc didn't boot, but....
I got a few different results. Here they are:

The PDA displayed the usual:
Lacking resources
95 pages in 0x05f000 bytes]!
Ordering pages...

then locked up with a fatal exception. One thing though, I noticed that 
I could do a software reset from uClinux.prc this time, instead of a 
hardware reset. I feel as though I'm a step closer to getting this to work.

I ran the same getup on POSE just to see what was going on... which was 
pretty much the same thing, however, if I clicked "Continue", POSE got 
past the error of writing to location ...116, and went on to say:

Palm loader just wrote to 0x00053992, which is the storage heap. 
Applications should use the special Palm OS functions for this purpose.

I'm beggining to think that there's nothing wrong with the actual 
uClinux kernel itself, just a problem with how Palmloader.c is 
configured. Is there any documentation an Palmloader.c? I wonder if I'm 
punching in the correct numbers in the correct lines of code? Could you 
send a copy of your Palmloader.c for me to examine? Thanks in advance =)

Cheers,
Mike

HenrySimmons17 wrote:
> You are looking to see how your registers are configured
> so you can set FFFFF116 in vendors/3com/palm-loader/PalmLoader.c.
> correctly. Set up debugger again  running in shortcut ..1 mode.
> type att
> type dm fffff116
> It will look approximately like this:
> dm fffff116
> FFFFF116: 3A 81 00 60 00 00 00 00   00 00 00
> the first 4 characters is the register setting. I my case it's 3A81.
> Setting them in hex is 0x3a81.
> The value you read from the debugger you replace (in 2 places in hex) in the
> file:
> vendors/3com/palm-loader/PalmLoader.c.
> example:
> asm volatile (" movew #0x3a81, 0xfffff116");



From staskh at attbi.com  Sat Mar  1 22:59:10 2003
From: staskh at attbi.com (Stas Khirman)
Date: Sat, 1 Mar 2003 19:59:10 -0800
Subject: [uClinux-dev] ARM Toolchain For Cygwin HOWTO?
References: <200303020302.h2232jF13449@uclinux.org>
Message-ID: <02ea01c2e070$14caf700$663da8c0@Staslap>

Certainly, Goggle a great help, but in this case I'm getting over thousand
references and I need a reference to a specific mail - I hope someone
remember it.

Sorry for disturbance...


----- Original Message -----
From: "Thierry Zhong" <jokyman at sina.com>
To: <uclinux-dev at uclinux.org>
Sent: Saturday, March 01, 2003 7:00 PM
Subject: Re: [uClinux-dev] ARM Toolchain For Cygwin HOWTO?


Stas Khirman,???

You can go to the searchable maillist or use google to search for it.

======= 2003-03-01 18:53:00 ????????=======

>If I remember correctly, a while ago someone publish in this list an
>excellent HOWTO build ARM toolchain for Cygwin ( and RH) environment.
>Unfortunately., I can't find this past mail. Does someone have a pointer to
>it ( or pointer to any other similar HOWTOs)
>
>Thank you
>Stas
>
>_______________________________________________
>uClinux-dev mailing list
>uClinux-dev at uclinux.org
>http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
>This message was resent by uclinux-dev at uclinux.org

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


?????????
??


????????Thierry Zhong
????????jokyman at sina.com
??????????2003-03-02




_______________________________________________
uClinux-dev mailing list
uClinux-dev at uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev at uclinux.org



From HenrySimmons17 at netzero.net  Sat Mar  1 23:28:35 2003
From: HenrySimmons17 at netzero.net (HenrySimmons17)
Date: Sat, 1 Mar 2003 20:28:35 -0800
Subject: [uClinux-dev] UCLINUX for PALM
References: <Pine.GSO.4.33.0302111240390.25930-100000@compserv1> <015801c2d222$ca8f38a0$ffc5fea9@henry133> <3E50444D.4010600@tbc.net> <004901c2d64e$13223fc0$ffc5fea9@henry133> <3E50E9DE.7050801@tbc.net> <000201c2d6d6$0d03e660$ffc5fea9@henry133> <3E524F5D.8020206@tbc.net> <000201c2d770$e5711e60$ffc5fea9@henry133> <3E5EB086.1070108@tbc.net> <000201c2dee8$065974a0$ffc5fea9@henry133> <3E5FE502.1060106@tbc.net> <000201c2dfc2$762ceb60$ffc5fea9@henry133> <3E61743D.6000901@tbc.net>
Message-ID: <000201c2e074$63483560$ffc5fea9@henry133>

Hello Michael

I don't know of any documentation for PalmLoader.c.
This is one have seen.
http://www.uclinux.org/pub/uClinux/archive/subject.html#4820
The reason you can do a soft reset is it has not got to jmp 800
in PalmLoader.c which start execution of the kernel.
jmp 800 is START_KERNEL in crt0_ram.s
Do this:
Changes in vendors/3com/palm-loader/Palmloader.c
Change line to read: asm volatile("movew #0x068f,0xfffff116");

change line to read: asm volatile("movew #0x2700, %sr; moveal 0x7ffff0,
%ssp");
change line to read: asm volatile("movew #0x068f, 0xfffff116");

Put 0x068f in 2 places in PalmLoader.c also notice in the line above reads
0x7FFFF0, %ssp.
This is change from 0x1FFFF0, &ssp. This set the stack pointer.
Henry
----- Original Message -----
From: Michael F. Sharp <mikes at tbc.net>
To: <uclinux-dev at uclinux.org>
Sent: Saturday, March 01, 2003 7:02 PM
Subject: Re: [uClinux-dev] UCLINUX for PALM


> Henry,
> I got the debugger fired up, and typed in the commands, which yielded:
> 3e8f
> I put this into line 140 of Palmloader.c, and compiled the kernel.
> I got a few different results. Here they are:
> Lacking resources
> 95 pages in 0x05f000 bytes]!
> Ordering pages...
>
> then locked up with a fatal exception



From staskh at attbi.com  Sat Mar  1 23:40:52 2003
From: staskh at attbi.com (Stas Khirman)
Date: Sat, 1 Mar 2003 20:40:52 -0800
Subject: [uClinux-dev] ucLinux for ADM5106
Message-ID: <067d01c2e075$e88486b0$663da8c0@Staslap>

Hi,

Did someone already port ucLinux to ADM5106 or CX84200 "network processor"
( ARM7TDMI core + fast Ethernet switch) ??

Any information is highly appreciated!!

Stas



From HenrySimmons17 at netzero.net  Sat Mar  1 23:44:11 2003
From: HenrySimmons17 at netzero.net (HenrySimmons17)
Date: Sat, 1 Mar 2003 20:44:11 -0800
Subject: [uClinux-dev] Hang on first call to sti()
References: <r01050400-1023-6D057E4A3D1411D7961100039387ACB6@[10.0.1.2]><002401c2d15e$38 9c65e0$0b0b15ac@hulsker.net><000401c2d176$f4dd86e0$ffc5fea9@henry133><000d01c2d1a4$b34b6660$0b0b15ac@hulsker.net> <015901c2d222$cbfef540$ffc5fea9@henry133>  <1045006845.19334.23.camel@adams> <1046275500.27011.51.camel@localhost.localdomain>
Message-ID: <001701c2e076$6b3b3400$ffc5fea9@henry133>

Hello Ryan 
2 places you will find these answers:
in uClinux distribution in file:
linux/arch/m68knommu/platform/68EZ328/ucsimm/crt0_ram.S
Motorola MC68EZ328 User's Manual.
There is an ezample code for the setup.
Henry
----- Original Message ----- 
From: Ryan Hulsker <rhulsker at emergentsolutions.ca>
To: <uclinux-dev at uclinux.org>
Sent: Wednesday, February 26, 2003 8:04 AM
Subject: [uClinux-dev] Hang on first call to sti()


> 
>   I have finally started to make some progress with my Dragonball
> board.  I now have the dram working and tested, and my kernel boots all
> the way up to the first call to sti() and then hangs.
> 
>   I have a feeling that I am generating an interrupt during my setup
> that I am not clearing properly before the kernel starts.  Below are my
> setup brecords.  I'm wondering if someone can see what I am doing wrong.
> 
>   I am also wondering what are the minimum hardware requirements for the
> kernel to run properly.  My brecord setup disables the RTC/Watchdog etc,
> but I am pretty sure that the OS needs some sort of regular interrupt to
> keep it going.  I am assuming that it is done with the RTC/GPT causing
> an interrupt at the jiffies rate or something.  But what exactly are the
> parameters?
> 
>   My board is just a 68EZ328 with 8M dram, no rom or flash.  I have been
> using the ucsimm build, modified to my needs.
> 
> 
> Thanks,
> Ryan Hulsker





From jokyman at sina.com  Sun Mar  2 00:11:44 2003
From: jokyman at sina.com (thierry)
Date: Sun, 2 Mar 2003 13:11:44 +0800
Subject: [uClinux-dev] ARM Toolchain For Cygwin HOWTO?
Message-ID: <200303020509.h2259JF15169@uclinux.org>

Hi,Stas Khirman

There's a search engine for uclinux maillist.
You can use that to find the mail.

>Certainly, Goggle a great help, but in this case I'm getting over thousand
>references and I need a reference to a specific mail - I hope someone
>remember it.
>
>Sorry for disturbance...
>
>
>----- Original Message -----
>From: "Thierry Zhong" <jokyman at sina.com>
>To: <uclinux-dev at uclinux.org>
>Sent: Saturday, March 01, 2003 7:00 PM
>Subject: Re: [uClinux-dev] ARM Toolchain For Cygwin HOWTO?
>
>
>Stas Khirman,???
>
>You can go to the searchable maillist or use google to search for it.
>
>======= 2003-03-01 18:53:00 ????????=======
>
>>If I remember correctly, a while ago someone publish in this list an
>>excellent HOWTO build ARM toolchain for Cygwin ( and RH) environment.
>>Unfortunately., I can't find this past mail. Does someone have a pointer to
>>it ( or pointer to any other similar HOWTOs)
>>
>>Thank you
>>Stas
>>
>>_______________________________________________
>>uClinux-dev mailing list
>>uClinux-dev at uclinux.org
>>http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
>>This message was resent by uclinux-dev at uclinux.org
>
>= = = = = = = = = = = = = = = = = = = =
>
>
>?????????
>??
>
>
>????????Thierry Zhong
>????????jokyman at sina.com
>??????????2003-03-02
>
>
>
>
>_______________________________________________
>uClinux-dev mailing list
>uClinux-dev at uclinux.org
>http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
>This message was resent by uclinux-dev at uclinux.org
>
>_______________________________________________
>uClinux-dev mailing list
>uClinux-dev at uclinux.org
>http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
>This message was resent by uclinux-dev at uclinux.org
>
>
>.

Best Regards!				 
????????thierry
????????jokyman at sina.com
??????????2003-03-02







From jokyman at sina.com  Sun Mar  2 00:17:53 2003
From: jokyman at sina.com (thierry)
Date: Sun, 2 Mar 2003 13:17:53 +0800
Subject: [uClinux-dev] Hang on first call to sti()
Message-ID: <200303020515.h225FRF15513@uclinux.org>

Hello Ryan 

Do you use 2.0 or 2.4 kernel?
Which file is your first call to sti() in?
>
>> 
>>   I have finally started to make some progress with my Dragonball
>> board.  I now have the dram working and tested, and my kernel boots all
>> the way up to the first call to sti() and then hangs.
>> 
>>   I have a feeling that I am generating an interrupt during my setup
>> that I am not clearing properly before the kernel starts.  Below are my
>> setup brecords.  I'm wondering if someone can see what I am doing wrong.
>> 
>>   I am also wondering what are the minimum hardware requirements for the
>> kernel to run properly.  My brecord setup disables the RTC/Watchdog etc,
>> but I am pretty sure that the OS needs some sort of regular interrupt to
>> keep it going.  I am assuming that it is done with the RTC/GPT causing
>> an interrupt at the jiffies rate or something.  But what exactly are the
>> parameters?
>> 
>>   My board is just a 68EZ328 with 8M dram, no rom or flash.  I have been
>> using the ucsimm build, modified to my needs.
>> 
>> 
>> Thanks,
>> Ryan Hulsker
>
>
>
>_______________________________________________
>uClinux-dev mailing list
>uClinux-dev at uclinux.org
>http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
>This message was resent by uclinux-dev at uclinux.org
>
>
>.

Best Regards!				 
????????thierry
????????jokyman at sina.com
??????????2003-03-02







From mikes at tbc.net  Sun Mar  2 00:12:54 2003
From: mikes at tbc.net (Michael F. Sharp)
Date: Sat, 01 Mar 2003 23:12:54 -0600
Subject: [uClinux-dev] UCLINUX for PALM
References: <Pine.GSO.4.33.0302111240390.25930-100000@compserv1> <015801c2d222$ca8f38a0$ffc5fea9@henry133> <3E50444D.4010600@tbc.net> <004901c2d64e$13223fc0$ffc5fea9@henry133> <3E50E9DE.7050801@tbc.net> <000201c2d6d6$0d03e660$ffc5fea9@henry133> <3E524F5D.8020206@tbc.net> <000201c2d770$e5711e60$ffc5fea9@henry133> <3E5EB086.1070108@tbc.net> <000201c2dee8$065974a0$ffc5fea9@henry133> <3E5FE502.1060106@tbc.net> <000201c2dfc2$762ceb60$ffc5fea9@henry133> <3E61743D.6000901@tbc.net> <000201c2e074$63483560$ffc5fea9@henry133>
Message-ID: <3E6192D6.60204@tbc.net>

Henry,

Interesting results!

When I booted the uClinux on the PDA, it went obout ordering pages, and 
then "froze". Well, not really for sure, but at any rate the PDA didn't 
respond, but didn't crash either. I waited for a few more minutes to see 
if anything else would boot, but after 3-4 minutes, I assumed uClinux 
was going as far as it could on my PDA.

Other interesting observation:
Upon resetting the PDA, I noticed that the PDA got erased... all, 
including uClinux.prc, but the not the ROM, which tells me that 
something may have worked right, but without any confirmation of an X 
window on the screen, I'm not for sure.

Isn't there an option for hooking up the PDA to a terminal or something 
while it boots, so I can watch the boot process? I'm thinking it has 
something to do with the Pilot Console option, but not for sure.

Thanks for all of your help so far =)

-Mike

HenrySimmons17 wrote:
> jmp 800 is START_KERNEL in crt0_ram.s
> Do this:
> Changes in vendors/3com/palm-loader/Palmloader.c
> Change line to read: asm volatile("movew #0x068f,0xfffff116");
> 
> change line to read: asm volatile("movew #0x2700, %sr; moveal 0x7ffff0,
> %ssp");
> change line to read: asm volatile("movew #0x068f, 0xfffff116");
> 
> Put 0x068f in 2 places in PalmLoader.c also notice in the line above reads
> 0x7FFFF0, %ssp.
> This is change from 0x1FFFF0, &ssp. This set the stack pointer.




From HenrySimmons17 at netzero.net  Sun Mar  2 01:10:17 2003
From: HenrySimmons17 at netzero.net (HenrySimmons17)
Date: Sat, 1 Mar 2003 22:10:17 -0800
Subject: [uClinux-dev] UCLINUX for PALM
References: <Pine.GSO.4.33.0302111240390.25930-100000@compserv1> <015801c2d222$ca8f38a0$ffc5fea9@henry133> <3E50444D.4010600@tbc.net> <004901c2d64e$13223fc0$ffc5fea9@henry133> <3E50E9DE.7050801@tbc.net> <000201c2d6d6$0d03e660$ffc5fea9@henry133> <3E524F5D.8020206@tbc.net> <000201c2d770$e5711e60$ffc5fea9@henry133> <3E5EB086.1070108@tbc.net> <000201c2dee8$065974a0$ffc5fea9@henry133> <3E5FE502.1060106@tbc.net> <000201c2dfc2$762ceb60$ffc5fea9@henry133> <3E61743D.6000901@tbc.net> <000201c2e074$63483560$ffc5fea9@henry133> <3E6192D6.60204@tbc.net>
Message-ID: <002a01c2e082$999a6d00$ffc5fea9@henry133>

Hello Michael
Since you did not get any messages from the PalmOS that is great. 
What has happen is the PalmLoader.c has loaded the uClinux startup
code --crt0_ram.S--- and executed the jmp 800 line. Now the 
kernel is trying to run. The next step is you are looking for the uClinux
Penguin. Check your make Xconfig setup:
the following 3 must be set to  "Y" or "y"..
CONFIG_CONSOLE   (Y/n)  y
CONFIG_FRAMEBUFFER  (Y/n) y
CONFIG_PILOT_CONSOLE  (Y/n) y
See below.
Henry

From: Michael F. Sharp <mikes at tbc.net>
To: <uclinux-dev at uclinux.org>
Sent: Saturday, March 01, 2003 9:12 PM
Subject: Re: [uClinux-dev] UCLINUX for PALM


> Interesting results!
> 
> When I booted the uClinux on the PDA, it went obout ordering pages, and 
> then "froze". Well, not really for sure, but at any rate the PDA didn't 
> respond, but didn't crash either. I waited for a few more minutes to see 
> if anything else would boot, but after 3-4 minutes, I assumed uClinux 
> was going as far as it could on my PDA.
> 
> Other interesting observation:
> Upon resetting the PDA, I noticed that the PDA got erased... all, 
> including uClinux.prc, but the not the ROM, which tells me that 
> something may have worked right, but without any confirmation of an X 
> window on the screen, I'm not for sure.
> 
> Isn't there an option for hooking up the PDA to a terminal or something 
> while it boots, so I can watch the boot process? I'm thinking it has 
> something to do with the Pilot Console option, but not for sure.
Yes but I could not get it working on my m500. Try minicom or Hyperterminal
at 9600 baud 8N1 settings.

>Thanks for all of your help so far =)

>Mike





From sanbhat at globaledgesoft.com  Sun Mar  2 06:13:42 2003
From: sanbhat at globaledgesoft.com (Santosh Bhat)
Date: Sun, 2 Mar 2003 16:43:42 +0530
Subject: [uClinux-dev] Change the memory map !
References: <E7E6D7E596DA514DA7C5FFCD2C777F9F2093BC@NCWAEX01.Netro-Corp.com>
Message-ID: <00e101c2e0ac$c8a44240$800210ac@16.2.63.ges1>

Hi Yadong thanx for your reply. But I didnot follow the content of your
mail. Can u be little more descriptive on this ? Thanx for the help/
Regards
Santosh Bhat
----- Original Message -----
From: "YaDong Wang" <YaDongW at netro-corp.com>
To: <uclinux-dev at uclinux.org>
Sent: Friday, February 28, 2003 12:55 AM
Subject: RE: [uClinux-dev] Change the memory map !


> Hi,
> The samsung 4510 processor can not change the vector location (at address
0x0). After boot up from flash (base address 0),
> you need swap the Chip select register between the Flash and SDRAM to
re-map SDRAM into 0 based address. That is what I did in our EVB board. (see
www.espd-inc.com)
>
> Hope this help.
>
> Yadong Wang
>
>
>
> -----Original Message-----
> From: David McCullough [mailto:davidm at snapgear.com]
> Sent: Wednesday, February 26, 2003 9:19 PM
> To: uclinux-dev at uclinux.org
> Subject: Re: [uClinux-dev] Change the memory map !
>
>
>
> Jivin Santosh Bhat lays it down ...
> > Hi List ,
> > I am porting the ARM7tdmi core on to Samsung processor.My ram is
@0xc000000
> > and the flash is at 0x00 . Can please any one tell me what are the
> > modifications i need to do in the source tree in order to execute . I
have
> > made sure the DRAM_BASE address is properly configured to 0xc000000 and
> > specified it is 8 mb, and also the flash start address as 0x0.
>
> You probably want PAGE_OFFSET to point to 0xc000000 as well,  if it
> doesn't do this automatically,
>
> Cheers,
> Davidm
>
> --
> David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
> davidm at snapgear.com  Fx: +61 7 3891 3630  Custom Embedded Solutions +
Security
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org
>
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org
>



From tchen at on-go.com  Sun Mar  2 11:08:37 2003
From: tchen at on-go.com (Thomas Chen)
Date: Sun, 02 Mar 2003 08:08:37 -0800
Subject: [uClinux-dev] Hang on first call to sti()
In-Reply-To: <001701c2e076$6b3b3400$ffc5fea9@henry133>
Message-ID: <BA876C85.8C7C%tchen@on-go.com>


this sounds like when you do a sti, you already have one or more
than one pending interrupts..... and somehow they are not being
cleared properly???  i would check interrupt pending registers
to see what is going on before the sti interruption

on 3/1/03 8:44 PM, HenrySimmons17 at HenrySimmons17 at netzero.net wrote:

> Hello Ryan 
> 2 places you will find these answers:
> in uClinux distribution in file:
> linux/arch/m68knommu/platform/68EZ328/ucsimm/crt0_ram.S
> Motorola MC68EZ328 User's Manual.
> There is an ezample code for the setup.
> Henry
> ----- Original Message -----
> From: Ryan Hulsker <rhulsker at emergentsolutions.ca>
> To: <uclinux-dev at uclinux.org>
> Sent: Wednesday, February 26, 2003 8:04 AM
> Subject: [uClinux-dev] Hang on first call to sti()
> 
> 
>> 
>> I have finally started to make some progress with my Dragonball
>> board.  I now have the dram working and tested, and my kernel boots all
>> the way up to the first call to sti() and then hangs.
>> 
>> I have a feeling that I am generating an interrupt during my setup
>> that I am not clearing properly before the kernel starts.  Below are my
>> setup brecords.  I'm wondering if someone can see what I am doing wrong.
>> 
>> I am also wondering what are the minimum hardware requirements for the
>> kernel to run properly.  My brecord setup disables the RTC/Watchdog etc,
>> but I am pretty sure that the OS needs some sort of regular interrupt to
>> keep it going.  I am assuming that it is done with the RTC/GPT causing
>> an interrupt at the jiffies rate or something.  But what exactly are the
>> parameters?
>> 
>> My board is just a 68EZ328 with 8M dram, no rom or flash.  I have been
>> using the ucsimm build, modified to my needs.
>> 
>> 
>> Thanks,
>> Ryan Hulsker
> 
> 
> 
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org
> 



From mikes at tbc.net  Sun Mar  2 16:17:31 2003
From: mikes at tbc.net (Michael F. Sharp)
Date: Sun, 02 Mar 2003 15:17:31 -0600
Subject: [uClinux-dev] UCLINUX for PALM
References: <Pine.GSO.4.33.0302111240390.25930-100000@compserv1> <015801c2d222$ca8f38a0$ffc5fea9@henry133> <3E50444D.4010600@tbc.net> <004901c2d64e$13223fc0$ffc5fea9@henry133> <3E50E9DE.7050801@tbc.net> <000201c2d6d6$0d03e660$ffc5fea9@henry133> <3E524F5D.8020206@tbc.net> <000201c2d770$e5711e60$ffc5fea9@henry133> <3E5EB086.1070108@tbc.net> <000201c2dee8$065974a0$ffc5fea9@henry133> <3E5FE502.1060106@tbc.net> <000201c2dfc2$762ceb60$ffc5fea9@henry133> <3E61743D.6000901@tbc.net> <000201c2e074$63483560$ffc5fea9@henry133> <3E6192D6.60204@tbc.net> <002a01c2e082$999a6d00$ffc5fea9@henry133>
Message-ID: <3E6274EB.7020605@tbc.net>

Henry,
Well, I recompiled the kernel again, this time with all three options 
below. I fired up minicom /dev/ttyS0, but didn't see any activity while 
uClinux was ordering pages. I had to hard reset the PDA to get it 
operational again. Minicom was indeed configured correctly, because I 
can see Hotsync sending "garbage" when I attempted to "Hotsync" with 
Minicom - so that part, I know is working.

Where do we go from here? Seems as though uClinux is ordering pages, 
wonder if I have the RAM/ROM configuration set up properly? I'm pretty 
sure that the Palm IIIc has 2M ROM and 8M RAM. What numbers do I need to 
verify for this?

Thanks,
Mike

HenrySimmons17 wrote:
> Hello Michael
> Since you did not get any messages from the PalmOS that is great. 
> What has happen is the PalmLoader.c has loaded the uClinux startup
> code --crt0_ram.S--- and executed the jmp 800 line. Now the 
> kernel is trying to run. The next step is you are looking for the uClinux
> Penguin. Check your make Xconfig setup:
> the following 3 must be set to  "Y" or "y"..
> CONFIG_CONSOLE   (Y/n)  y
> CONFIG_FRAMEBUFFER  (Y/n) y
> CONFIG_PILOT_CONSOLE  (Y/n) y




From davidm at snapgear.com  Sun Mar  2 19:34:06 2003
From: davidm at snapgear.com (David McCullough)
Date: Mon, 3 Mar 2003 10:34:06 +1000
Subject: [uClinux-dev] setjmp / floatpoint
In-Reply-To: <3E5FD386.518FB5F7@on-go.com>
References: <3E5FD386.518FB5F7@on-go.com>
Message-ID: <20030303003406.GC17327@beast.internal.moreton.com.au>

Jivin thomas chen lays it down ...
> 
> recently there was a copy of setjmp change applied to cvs
> 
> uClibc/libc/sysdeps/linux/arm/setjmp.S
> 
> i dont think the change is right?  there are two 
> sub r0, r0, #48 
> 
> there should only be one????
> 
> can someone review this?

Yep,  the first should have been an add,  I messed it up some
how from the orginal patch, sorry :-) The fixed version is checked
in now,

Cheers,
Davidm

-- 
David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
davidm at snapgear.com  Fx: +61 7 3891 3630  Custom Embedded Solutions + Security


From davidm at snapgear.com  Sun Mar  2 20:07:09 2003
From: davidm at snapgear.com (David McCullough)
Date: Mon, 3 Mar 2003 11:07:09 +1000
Subject: [uClinux-dev] UCLINUX for PALM
In-Reply-To: <001b01c2df42$376b2700$ffc5fea9@henry133>
References: <Pine.GSO.4.33.0302070159150.23746-100000@compserv1> <000201c2cfbe$943f2fa0$ffc5fea9@henry133> <20030209232255.GA28757@beast.internal.moreton.com.au> <000701c2d0aa$a7f0f780$ffc5fea9@henry133> <20030210030607.GA4753@beast.internal.moreton.com.au> <001b01c2df42$376b2700$ffc5fea9@henry133>
Message-ID: <20030303010709.GF17327@beast.internal.moreton.com.au>

Jivin HenrySimmons17 lays it down ...
> Hello David
> I finally got the prompt />
> The problem was the console kept defaulting to ttyS0 and I was
>  not using a serial console. I was using the console on the
>  Palm m500 (CONFIG_PILOT_CONSOLE). When I added 
> the statement  : tty0:linux:/bin/sh
> into the file: PalmIIIx/inittab
> it worked. I then removed the statement from PalmIIIx/inittab
> & modified the Makefile in vendors/3com/PalmIIIx as follows:
> case "$(LINUXDIR)" in \
>  *2.0.*) ;; \
>  *) echo "tty0:linux:/bin/sh" >> $(ROMFSDIR)/etc/inittab ;; \
>  esac
> and it worked. This change also can be merge into the distro.

I usually run my IIIx without the fancy console this the current setup :-)

What would be good is if you could make a vendors/3com/m500 directory that
does exactly what you want and send it to me and I will add it in untouched.
Just copy the PalmIIIx directory with your mods.

What would also be good is if we can make the changes needed to PalmLoader.c
work on all platforms.  Perhaps read the XX register first,  add some
bits then write it ?

Cheers,
Davidm

-- 
David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
davidm at snapgear.com  Fx: +61 7 3891 3630  Custom Embedded Solutions + Security


From jwilliams at itee.uq.edu.au  Sun Mar  2 20:22:54 2003
From: jwilliams at itee.uq.edu.au (John Williams)
Date: Mon, 03 Mar 2003 11:22:54 +1000
Subject: [uClinux-dev] microblaze update
Message-ID: <3E62AE6E.7060502@itee.uq.edu.au>

Hi folks,

Just a newsflash - as of half an hour ago I have a compiled and linked 
kernel, and am single stepping through the startup procedures in gdb 
attached to a software simulator!

Now for a couple of weeks buried in the debugger... :)  And maybe, one 
day, booting some hardware!

Cheers,

John



From tchen at on-go.com  Sun Mar  2 23:43:41 2003
From: tchen at on-go.com (Thomas Chen)
Date: Sun, 02 Mar 2003 20:43:41 -0800
Subject: [uClinux-dev] setjmp / floatpoint
In-Reply-To: <20030303003406.GC17327@beast.internal.moreton.com.au>
Message-ID: <BA881D7D.8C8E%tchen@on-go.com>

thanks.... that was crashing my ppp

also... one more question

who sets this __UCLIBC_HAS_SOFT_FLOAT__ symbol???

the earlier version was __SOFTFP__

is this symbol related to a new version of toolchain? because
my version -msoft-float does not seem to create this symbol

thanks


on 3/2/03 4:34 PM, David McCullough at davidm at snapgear.com wrote:

> 
> Jivin thomas chen lays it down ...
>> 
>> recently there was a copy of setjmp change applied to cvs
>> 
>> uClibc/libc/sysdeps/linux/arm/setjmp.S
>> 
>> i dont think the change is right?  there are two
>> sub r0, r0, #48 
>> 
>> there should only be one????
>> 
>> can someone review this?
> 
> Yep,  the first should have been an add,  I messed it up some
> how from the orginal patch, sorry :-) The fixed version is checked
> in now,
> 
> Cheers,
> Davidm



From davidm at snapgear.com  Sun Mar  2 21:15:40 2003
From: davidm at snapgear.com (David McCullough)
Date: Mon, 3 Mar 2003 12:15:40 +1000
Subject: [uClinux-dev] setjmp / floatpoint
In-Reply-To: <BA881D7D.8C8E%tchen@on-go.com>
References: <20030303003406.GC17327@beast.internal.moreton.com.au> <BA881D7D.8C8E%tchen@on-go.com>
Message-ID: <20030303021540.GA23852@beast.internal.moreton.com.au>

Jivin Thomas Chen lays it down ...
> 
> thanks.... that was crashing my ppp
> 
> also... one more question
> 
> who sets this __UCLIBC_HAS_SOFT_FLOAT__ symbol???
> 
> the earlier version was __SOFTFP__
> 
> is this symbol related to a new version of toolchain? because
> my version -msoft-float does not seem to create this symbol

The uClibc config file does this.  Look through uClibc/.config
or the one in your vendors directory,

Cheers,
Davidm

-- 
David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
davidm at snapgear.com  Fx: +61 7 3891 3630  Custom Embedded Solutions + Security


From petero at cvs.com.au  Sun Mar  2 22:11:32 2003
From: petero at cvs.com.au (Peter Ogilvy)
Date: Mon, 3 Mar 2003 14:11:32 +1100
Subject: [uClinux-dev] structure size ????
In-Reply-To: <3E61295E.9689D758@on-go.com>
References: <3E61295E.9689D758@on-go.com>
Message-ID: <200303031411.32739.petero@cvs.com.au>

Hi Thomas,

I had to solve this a little while ago, you might want to
look in the archive for the subject

 Platform independant structs

There was a couple of suggestions made, which fit different
circumstances. The solution I used is below.

Below is an example of a struct which is padded so all the data
is on four byte boundaries. The __attribute((packed)) ensures
that there is no additional padding added by the compiler.

Since pad1 and pad2 may not be correctly aligned (depending
on where the code is running) you cant use them. You have to
chose the padding size so the data can be accessed on both
platforms.

Hope this helps

typedef struct
{
    __u32 data1;
    __u8 data2; 
    __u8 pad1;    // padding to preservefour byte alignment dont use
    __u16 pad2;
    __u32 data3;
}
__attribute((packed)) your_struct;


thomas chen wrote:
> i have a structure that is 10 bytes long... on the target side
> (arm) arm-elf-gcc expand that to multiple of 4, ie 12 bytes...
> but on the intel pc side, it is still 10 bytes...  any way to pack
> the structure but without violating the arm alignment problem...
> ie if the structure is 9 byte long, i want to pack it to 10 instead
> of just 9....
>
> thanks
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org



From sy_wu at dlink.com.tw  Sun Mar  2 22:16:04 2003
From: sy_wu at dlink.com.tw (sy_wu at dlink.com.tw)
Date: Mon, 3 Mar 2003 11:16:04 +0800
Subject: [uClinux-dev] About uClinux for MIPS release
Message-ID: <OFA16ECA53.8288D5C9-ON48256CDE.00103901@dlink.com.tw>

Hi,

It worked by changing the LOADADDR value, thank you!

I'd like to port it to another MIPS board(R3000), could you give me some
advice where to begin?

Best Regards,
SY



                                                                                                                                        
                      "qiulm"                                                                                                           
                      <qiulm at xiptech.com        To:       <uclinux-dev at uclinux.org>                                                     
                      >                         cc:                                                                                     
                      Sent by:                  Subject:  Re: [uClinux-dev] About uClinux for MIPS release                              
                      uclinux-dev-admin@                                                                                                
                      uclinux.org                                                                                                       
                                                                                                                                        
                                                                                                                                        
                      2003/02/28 05:12                                                                                                  
                      PM                                                                                                                
                      Please respond to                                                                                                 
                      uclinux-dev                                                                                                       
                                                                                                                                        
                                                                                                                                        




Hi,

1. Had you loaded xipos.config in menuconfig before you built uClinux
kernel? (will select the suitable config options)
2. What's the number of LOADADDR in arch/mipsnommu/Makefile

...
# XIPOS mips simulator
ifdef CONFIG_SIMULATOR
CORE_FILES += arch/mipsnommu/simulator/simulator.o
SUBDIRS  += arch/mipsnommu/simulator
LOADADDR := 0x80102000
                            ^^^^^^^^^
...
In patch, this value is 0x80002000. In fact, it can be any legal address.
But it must be identical  with the parameter in shortcut.

Best regards
qiulm



----- Original Message -----
From: <sy_wu at dlink.com.tw>
To: <uclinux-dev at uclinux.org>
Sent: Thursday, February 27, 2003 6:03 PM
Subject: Re: [uClinux-dev] About uClinux for MIPS release


>
> Hi,
>
> I use the patch from your web site, and followed the steps in the porting
> document.
> 1. Build toolchain
> 2. Rebuild patched uclibc
> 3. Install romfs.tar.gz
> 4. Build patched uClinux for MIPS
> Then I got one uclinux.bin, and put it to c:\xiptech to run.  But nothing
> showed in the screen.
> You mentioned I might use wrong base address when liking kernel, did I
miss
> something?
> I didn't do anything related to the base address setting.
>
> Best Regards,
> SY
>
>
>
>
>                       "qiulm"
>                       <qiulm at xiptech.com        To:
<uclinux-dev at uclinux.org>
>                       >                         cc:
>                       Sent by:                  Subject:  Re:
[uClinux-dev] About uClinux for MIPS release
>                       uclinux-dev-admin@
>                       uclinux.org
>
>
>                       2003/02/27 02:43
>                       PM
>                       Please respond to
>                       uclinux-dev
>
>
>
>
>
>
> Hi,
>
> When you talking about the source code, do you mean the patch on our web
> site? If the answer is yes, the demo kernel is compiled from the same
> source. What's the matter when executing the kernel you compiled? Is
there
> any messages from the simulator's console? Is it possible that you use
the
> wrong base address when linking the kernel?
>
> Please give me more details. I will try my best to help.
>
> Best regards
> qiulm
>
> ----- Original Message -----
> From: <sy_wu at dlink.com.tw>
> To: <uclinux-dev at uclinux.org>
> Sent: Thursday, February 27, 2003 1:06 PM
> Subject: [uClinux-dev] About uClinux for MIPS release
>
>
> > Hi,
> >
> > I tried the uClinux for MIPS release from Xiptech.  And I think it's
> really
> > a nice work,
> > especially the MIPS simulator for testing without hardware.
> >
> > And here's one question to Liming:
> > I can run the demo version of the uclinux kernel image, but I cannot
get
> it
> > work by compiling
> > it from the source.  Is the demo kernel image compiled from the same
> source
> > in the download site?
> >
> > Best Regards,
> > SY
> > _______________________________________________
> > uClinux-dev mailing list
> > uClinux-dev at uclinux.org
> > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> > This message was resent by uclinux-dev at uclinux.org
> >
>
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org
>
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org
>

_______________________________________________
uClinux-dev mailing list
uClinux-dev at uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev at uclinux.org



From tchen at on-go.com  Sun Mar  2 23:01:29 2003
From: tchen at on-go.com (thomas chen)
Date: Sun, 02 Mar 2003 23:01:29 -0500
Subject: [uClinux-dev] setjmp / floatpoint
References: <20030303003406.GC17327@beast.internal.moreton.com.au> <BA881D7D.8C8E%tchen@on-go.com> <20030303021540.GA23852@beast.internal.moreton.com.au>
Message-ID: <3E62D399.8664BBFD@on-go.com>

dave... i am not quite sure what you mean....

in 
vendor/xxx/yyy/config.uClibc

there is a definition for 
HAS_FLOATING_POINT = true

and in 
uClinux/uClibc/Makefile

if $(HAS_FLOATING_POINT) == true
then
	echo #define __UCLIBC_HAS_FLOAT__ >> include/bits/uClibc_config.h

however,  there is nothing for __UCLIBC_HAS_SOFT_FLOAT__

the problem then in setjmp.S

#if	defined __UCLIBC_HAS_FLOAT__ and !defined __UCLIBC_HAS_SOFT_FLOAT__
....  <we dont want to get here since we really have no hardware
floating
point>

#endif

clearly the issue seem to be __UCLIBC_HAS_SOFT_FLOAT__ should be defined
some where...  ?????



David McCullough wrote:
> 
> Jivin Thomas Chen lays it down ...
> >
> > thanks.... that was crashing my ppp
> >
> > also... one more question
> >
> > who sets this __UCLIBC_HAS_SOFT_FLOAT__ symbol???
> >
> > the earlier version was __SOFTFP__
> >
> > is this symbol related to a new version of toolchain? because
> > my version -msoft-float does not seem to create this symbol
> 
> The uClibc config file does this.  Look through uClibc/.config
> or the one in your vendors directory,
> 
> Cheers,
> Davidm
> 
> --
> David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
> davidm at snapgear.com  Fx: +61 7 3891 3630  Custom Embedded Solutions + Security
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org


From tchen at on-go.com  Mon Mar  3 02:25:49 2003
From: tchen at on-go.com (Thomas Chen)
Date: Sun, 02 Mar 2003 23:25:49 -0800
Subject: [uClinux-dev] structure size ????
In-Reply-To: <200303031411.32739.petero@cvs.com.au>
Message-ID: <BA88437D.8C9C%tchen@on-go.com>

well.... i saw the archive, but i actually want something
"in between"....

the fact that my target is an architecture that the alignemnt
has to be on 16 bit, i was looking for somethign that would
pad the structure to 16 bit boundry...

the closest thing that came to it is
 -mstructure-pad-boundry =

but that can only be value of 8 or 32.... not 16... so i
was wondering what it could be???  your suggestion is good
but it require software writer to be "architecture aware"...
and be very conciencious about the structure definition,
some of the stuff i work with is third party, and i have
no easy way to check every existing structure... was hoping
a compiler option to do that dirty work for me...!!!



on 3/2/03 7:11 PM, Peter Ogilvy at petero at cvs.com.au wrote:

> Hi Thomas,
> 
> I had to solve this a little while ago, you might want to
> look in the archive for the subject
> 
> Platform independant structs
> 
> There was a couple of suggestions made, which fit different
> circumstances. The solution I used is below.
> 
> Below is an example of a struct which is padded so all the data
> is on four byte boundaries. The __attribute((packed)) ensures
> that there is no additional padding added by the compiler.
> 
> Since pad1 and pad2 may not be correctly aligned (depending
> on where the code is running) you cant use them. You have to
> chose the padding size so the data can be accessed on both
> platforms.
> 
> Hope this helps
> 
> typedef struct
> {
> __u32 data1;
> __u8 data2; 
> __u8 pad1;    // padding to preservefour byte alignment dont use
> __u16 pad2;
> __u32 data3;
> }
> __attribute((packed)) your_struct;
> 
> 
> thomas chen wrote:
>> i have a structure that is 10 bytes long... on the target side
>> (arm) arm-elf-gcc expand that to multiple of 4, ie 12 bytes...
>> but on the intel pc side, it is still 10 bytes...  any way to pack
>> the structure but without violating the arm alignment problem...
>> ie if the structure is 9 byte long, i want to pack it to 10 instead
>> of just 9....
>> 
>> thanks
>> _______________________________________________
>> uClinux-dev mailing list
>> uClinux-dev at uclinux.org
>> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
>> This message was resent by uclinux-dev at uclinux.org
> 
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org
> 



From miles at lsi.nec.co.jp  Mon Mar  3 00:41:21 2003
From: miles at lsi.nec.co.jp (Miles Bader)
Date: 03 Mar 2003 14:41:21 +0900
Subject: [uClinux-dev] Re: structure size ????
In-Reply-To: <BA88437D.8C9C%tchen@on-go.com>
References: <BA88437D.8C9C%tchen@on-go.com>
Message-ID: <buou1elvwfy.fsf@mcspd15.ucom.lsi.nec.co.jp>

Why not pad every field to 32-bits?  It'll waste a bit of space, but
probably save a lot of headaches...

-Miles
-- 
Love is a snowmobile racing across the tundra.  Suddenly it flips over,
pinning you underneath.  At night the ice weasels come.  --Nietzsche


From gerg at snapgear.com  Mon Mar  3 00:58:13 2003
From: gerg at snapgear.com (Greg Ungerer)
Date: Mon, 03 Mar 2003 15:58:13 +1000
Subject: [uClinux-dev] compiling error's after making changes to support
 ATAPI
In-Reply-To: <20030301130859.31191.qmail@web11001.mail.yahoo.com>
References: <20030301130859.31191.qmail@web11001.mail.yahoo.com>
Message-ID: <3E62EEF5.2080704@snapgear.com>

Hi Kristof,

Kristof Bruyninckx wrote:
> now after I had done all this the compiling errors of
> the ide support stopped. But now the problem is that I
> am gething errors because I include ISO 9660 support.
> (see attachement error7.txt). But when I don't include
>   ISO 9660 support I again get errors.And when I try
> to compile a default kernel I get exactly the same
> errors as when I do not include ISO 9660 support.(see
> attachement error8.txt)
> Does anyone know how to fix these errors?? Any advice
> or tips are very welkom.
> 
> [snip]
> m68k-elf-gcc -m5307 -DCONFIG_COLDFIRE -Os -g -fomit-frame-pointer  -Dlinux -D__linux__ -Dunix -D__uClinux__ -DEMBED -I/uClinux-dist/lib/libc/include -I/uClinux-dist/lib/libm -I/uClinux-dist -fno-builtin -msep-data -I/uClinux-dist/linux-2.4.x/include -Wl,-elf2flt -o boa alias.o auth.o boa.o cgi.o cgi_header.o config.o get.o hash.o log.o nls.o pipe.o queue.o read.o request.o response.o signals.o timestamp.o util.o -lcrypt -L/uClinux-dist/lib/libc/. -L/uClinux-dist/lib/libc/lib -L/uClinux-dist/lib/libm -L/uClinux-dist/lib/libnet -L/uClinux-dist/lib/libdes -L/uClinux-dist/lib/libpcap -L/uClinux-dist/lib/zlib -L/uClinux-dist/lib/libssl -lc
> /usr/local/m68k-elf/bin/ld.real: cannot open crt0.o: No such file or directory

This looks like a problem related to your rebuild of the tool chain.
Do the crt0.o files exits in /usr/local/m68k-elf/lib?

If you do something like "find /usr/local/m68k-elf/lib -name crt0.o"
then you should see:

/usr/local/m68k-elf/lib/m68000/msep-data/crt0.o
/usr/local/m68k-elf/lib/m68000/mid-shared-library/crt0.o
/usr/local/m68k-elf/lib/m68000/crt0.o
/usr/local/m68k-elf/lib/m5200/msep-data/crt0.o
/usr/local/m68k-elf/lib/m5200/mid-shared-library/crt0.o
/usr/local/m68k-elf/lib/m5200/crt0.o
/usr/local/m68k-elf/lib/m5307/msep-data/crt0.o
/usr/local/m68k-elf/lib/m5307/mid-shared-library/crt0.o
/usr/local/m68k-elf/lib/m5307/crt0.o
/usr/local/m68k-elf/lib/mcpu32/msep-data/crt0.o
/usr/local/m68k-elf/lib/mcpu32/crt0.o
/usr/local/m68k-elf/lib/msoft-float/crt0.o
/usr/local/m68k-elf/lib/crt0.o

Regards
Greg



------------------------------------------------------------------------
Greg Ungerer  --  Chief Software Wizard        EMAIL:  gerg at snapgear.com
SnapGear Pty Ltd                               PHONE:    +61 7 3435 2888
825 Stanley St,                                  FAX:    +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia              WEB:   www.SnapGear.com



From davidm at snapgear.com  Mon Mar  3 02:18:11 2003
From: davidm at snapgear.com (David McCullough)
Date: Mon, 3 Mar 2003 17:18:11 +1000
Subject: [uClinux-dev] setjmp / floatpoint
In-Reply-To: <3E62D399.8664BBFD@on-go.com>
References: <20030303003406.GC17327@beast.internal.moreton.com.au> <BA881D7D.8C8E%tchen@on-go.com> <20030303021540.GA23852@beast.internal.moreton.com.au> <3E62D399.8664BBFD@on-go.com>
Message-ID: <20030303071811.GA22937@beast.internal.moreton.com.au>

Jivin thomas chen lays it down ...
> 
> dave... i am not quite sure what you mean....
> 
> in 
> vendor/xxx/yyy/config.uClibc
> 
> there is a definition for 
> HAS_FLOATING_POINT = true

Ok,  I was working on the latest dist which has a newer uClibc and it's
configs have something like:

	UCLIBC_HAS_SOFT_FLOAT=y

Defined in them.  I cannot remember where this was done in the older
uClibc.

[...]
> clearly the issue seem to be __UCLIBC_HAS_SOFT_FLOAT__ should be defined
> some where...  ?????


Yes,  the compiler doesn't do that though so it must be in the uClibc
area somewhere.  Otherwise just hardcode it until you move to a newer
dist,  you could add the define to your config.arch,

Cheers,
Davidm

-- 
David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
davidm at snapgear.com  Fx: +61 7 3891 3630  Custom Embedded Solutions + Security


From frederic.dubois at synchronic.fr  Mon Mar  3 03:01:24 2003
From: frederic.dubois at synchronic.fr (=?iso-8859-1?Q?Fr=E9deric_DUBOIS?=)
Date: Mon, 3 Mar 2003 09:01:24 +0100 
Subject: [uClinux-dev] structure size ????
Message-ID: <1132153BE85ED411B37A0000B4A7D87DCD3D@SERVEUR21>

But.. why do you want your structs be aligned the same way on both
platforms? To be sent over a networking link?

> -----Message d'origine-----
> De : Thomas Chen [mailto:tchen at on-go.com]
> Envoy? : lun. 3 mars 2003 08:26
> ? : uclinux-dev at uclinux.org
> Objet : Re: [uClinux-dev] structure size ????
> 
> 
> 
> well.... i saw the archive, but i actually want something
> "in between"....
> 
> the fact that my target is an architecture that the alignemnt
> has to be on 16 bit, i was looking for somethign that would
> pad the structure to 16 bit boundry...
> 
> the closest thing that came to it is
>  -mstructure-pad-boundry =
> 
> but that can only be value of 8 or 32.... not 16... so i
> was wondering what it could be???  your suggestion is good
> but it require software writer to be "architecture aware"...
> and be very conciencious about the structure definition,
> some of the stuff i work with is third party, and i have
> no easy way to check every existing structure... was hoping
> a compiler option to do that dirty work for me...!!!
> 
> 
> 
> on 3/2/03 7:11 PM, Peter Ogilvy at petero at cvs.com.au wrote:
> 
> > Hi Thomas,
> > 
> > I had to solve this a little while ago, you might want to
> > look in the archive for the subject
> > 
> > Platform independant structs
> > 
> > There was a couple of suggestions made, which fit different
> > circumstances. The solution I used is below.
> > 
> > Below is an example of a struct which is padded so all the data
> > is on four byte boundaries. The __attribute((packed)) ensures
> > that there is no additional padding added by the compiler.
> > 
> > Since pad1 and pad2 may not be correctly aligned (depending
> > on where the code is running) you cant use them. You have to
> > chose the padding size so the data can be accessed on both
> > platforms.
> > 
> > Hope this helps
> > 
> > typedef struct
> > {
> > __u32 data1;
> > __u8 data2; 
> > __u8 pad1;    // padding to preservefour byte alignment dont use
> > __u16 pad2;
> > __u32 data3;
> > }
> > __attribute((packed)) your_struct;
> > 
> > 
> > thomas chen wrote:
> >> i have a structure that is 10 bytes long... on the target side
> >> (arm) arm-elf-gcc expand that to multiple of 4, ie 12 bytes...
> >> but on the intel pc side, it is still 10 bytes...  any way to pack
> >> the structure but without violating the arm alignment problem...
> >> ie if the structure is 9 byte long, i want to pack it to 10 instead
> >> of just 9....
> >> 
> >> thanks
> >> _______________________________________________
> >> uClinux-dev mailing list
> >> uClinux-dev at uclinux.org
> >> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> >> This message was resent by uclinux-dev at uclinux.org
> > 
> > _______________________________________________
> > uClinux-dev mailing list
> > uClinux-dev at uclinux.org
> > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> > This message was resent by uclinux-dev at uclinux.org
> > 
> 
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org
> 


From eepaul at peoplemail.com.cn  Mon Mar  3 03:29:17 2003
From: eepaul at peoplemail.com.cn (Paul)
Date: Mon, 3 Mar 2003 16:29:17 +0800
Subject: [uClinux-dev] Is there any chance that uClinux lose an interrupt???
Message-ID: <004101c2e15e$fce66c10$38370d0a@paulp4>

Hi:
   My mpu is 5272.

   Every 30ms,my cmos image sensor interrupts 5272 through INT3# pin of
5272.

   Is there any chance that uClinux lose an interrupt??

    I mean that if cmos sensor interrupts 5272 N times,my ISR is called M
times and M<N.

    Is that possible?


Regards
Paul






From Nemanja.Popov at micronasnit.com  Mon Mar  3 03:50:46 2003
From: Nemanja.Popov at micronasnit.com (Nemanja Popov)
Date: Mon, 3 Mar 2003 09:50:46 +0100
Subject: [uClinux-dev] elf2flt - mips
References: <BPEAJKEMJECCJAIKNOMPCEBECMAA.yhlin@viosoft.com> <013a01c2df0c$37281310$e000a8c0@micronasnit.com> <005a01c2df14$6699f160$6301a8c0@qiulm> <001301c2df45$c890de70$e000a8c0@micronasnit.com>
Message-ID: <002301c2e161$fcd17d20$e000a8c0@micronasnit.com>

Does anyone have some example exe and in bFLT (and source) format for big
endian MIPS. It woult help me as a reference for porting of elf2flt for
MIPS.

Nemanja

> > Please use PIC code when compile, then the R_MIPS_LO16, R_MIPS_HI16 and
> > R_MIPS_26 relocatins won't show up.
>
> Nothing helps. I still get info that realocations 4, 5 and 6 are not
> resolved (R_MIPS_HI16, R_MIPS_LO16, R_MIPS_26 ). Is it normal? (I think
not)
> Kernel tryes to load my /bin/init (actually it is "Hello world") which is
> built with
> info that relocs are not resolved, and then hangs.
>
> Is there problem in uClibc-0.9.15. How should I built it. Is there
anything
> that is not ordinary and I should pay attention on that.
> Can someone write to me the exact gcc/ld command line(s) to get FLAT
format.
> Kernel tryes to load my /bin/init (actually it is "Hello world") which is
> built with
> info that relocs are not resolved, and then hangs.




From markchan at airvast.com  Mon Mar  3 06:11:32 2003
From: markchan at airvast.com (=?big5?B?bWFya2NoYW644rHmtm0=?=)
Date: Mon, 3 Mar 2003 19:11:32 +0800 
Subject: [uClinux-dev] __divs3 error
Message-ID: <1C1D5AFCBD2AF6448EB623FC5EEAE5C37EA932@dns.airvast.com>

Dear all,
 
    I use arm-elf-gcc v2.95.3 and suffer some '__divs3' error.   I dump the
list of libgcc.a and find
there has '_divs3' but no '__divs3' inside.    How I can solve it ?   Get
new libgcc.a or add options
to ld or ...   Thanks.
 
 
Reading specs from /opt/uClinux/lib/gcc-lib/arm-elf/2.95.3/specs
gcc version 2.95.3 20010315 (release)
 
flash.o: In function `nand_read':
flash.o(.text+0x1ec4): undefined reference to `__udivsi3'
flash.o: In function `nand_write':
flash.o(.text+0x201c): undefined reference to `__udivsi3'
make[1]: *** [api] Error 1
make: *** [all] Error 2

 
Mark Chan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20030303/ffe7d2c7/attachment.html>

From fgiovag at tin.it  Mon Mar  3 06:12:54 2003
From: fgiovag at tin.it (Fabio Giovagnini)
Date: Mon, 3 Mar 2003 12:12:54 +0100
Subject: [uClinux-dev] structure size ????
In-Reply-To: <1132153BE85ED411B37A0000B4A7D87DCD3D@SERVEUR21>
References: <1132153BE85ED411B37A0000B4A7D87DCD3D@SERVEUR21>
Message-ID: <200303031212.54940.fgiovag@tin.it>

According my knowledge there are two aspects:
1) the alignment capability of yuor microprocessor. You should know if you can 
align a word to an odd address or if you can align a long word to an address 
that isn't multiple of 4. On my microcprocessor (hitachi h8300h,h8s, sh2,sh3) 
this is not possible so you cannot align:
struct _uuu {
	usigned long a1;
	unsigned char a2;
	unsigned short a3;
} uuu;
because a3c in on an odd address and for my micro it is not allowed;

2) soem version of gcc have a bug about the use of __attribute__((packed)). 
The behaviour changes if you write:
struct _uuu {
	usigned long a1;
	unsigned char a2;
	unsigned short a3;
} uuu __attribute__((packed)); // works

typedef struct _uuu {
	usigned long a1;
	unsigned char a2;
	unsigned short a3;
} uuu __attribute__((packed)) uuu_t; // I'm not sure but I suppose it works

typedef struct _uuu {
	usigned long a1;
	unsigned char a2;
	unsigned short a3;
} uuu uuu_t __attribute__((packed)) ; // I'm pretty sure it doesn't works


Regards.

Alle 09:01, luned? 3 marzo 2003, Fr?deric DUBOIS ha scritto:
> But.. why do you want your structs be aligned the same way on both
> platforms? To be sent over a networking link?
>
> > -----Message d'origine-----
> > De : Thomas Chen [mailto:tchen at on-go.com]
> > Envoy? : lun. 3 mars 2003 08:26
> > ? : uclinux-dev at uclinux.org
> > Objet : Re: [uClinux-dev] structure size ????
> >
> >
> >
> > well.... i saw the archive, but i actually want something
> > "in between"....
> >
> > the fact that my target is an architecture that the alignemnt
> > has to be on 16 bit, i was looking for somethign that would
> > pad the structure to 16 bit boundry...
> >
> > the closest thing that came to it is
> >  -mstructure-pad-boundry =
> >
> > but that can only be value of 8 or 32.... not 16... so i
> > was wondering what it could be???  your suggestion is good
> > but it require software writer to be "architecture aware"...
> > and be very conciencious about the structure definition,
> > some of the stuff i work with is third party, and i have
> > no easy way to check every existing structure... was hoping
> > a compiler option to do that dirty work for me...!!!
> >
> > on 3/2/03 7:11 PM, Peter Ogilvy at petero at cvs.com.au wrote:
> > > Hi Thomas,
> > >
> > > I had to solve this a little while ago, you might want to
> > > look in the archive for the subject
> > >
> > > Platform independant structs
> > >
> > > There was a couple of suggestions made, which fit different
> > > circumstances. The solution I used is below.
> > >
> > > Below is an example of a struct which is padded so all the data
> > > is on four byte boundaries. The __attribute((packed)) ensures
> > > that there is no additional padding added by the compiler.
> > >
> > > Since pad1 and pad2 may not be correctly aligned (depending
> > > on where the code is running) you cant use them. You have to
> > > chose the padding size so the data can be accessed on both
> > > platforms.
> > >
> > > Hope this helps
> > >
> > > typedef struct
> > > {
> > > __u32 data1;
> > > __u8 data2;
> > > __u8 pad1;    // padding to preservefour byte alignment dont use
> > > __u16 pad2;
> > > __u32 data3;
> > > }
> > > __attribute((packed)) your_struct;
> > >
> > > thomas chen wrote:
> > >> i have a structure that is 10 bytes long... on the target side
> > >> (arm) arm-elf-gcc expand that to multiple of 4, ie 12 bytes...
> > >> but on the intel pc side, it is still 10 bytes...  any way to pack
> > >> the structure but without violating the arm alignment problem...
> > >> ie if the structure is 9 byte long, i want to pack it to 10 instead
> > >> of just 9....
> > >>
> > >> thanks
> > >> _______________________________________________
> > >> uClinux-dev mailing list
> > >> uClinux-dev at uclinux.org
> > >> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> > >> This message was resent by uclinux-dev at uclinux.org
> > >
> > > _______________________________________________
> > > uClinux-dev mailing list
> > > uClinux-dev at uclinux.org
> > > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> > > This message was resent by uclinux-dev at uclinux.org
> >
> > _______________________________________________
> > uClinux-dev mailing list
> > uClinux-dev at uclinux.org
> > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> > This message was resent by uclinux-dev at uclinux.org
>
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org



From eauth at softsys.co.at  Mon Mar  3 07:46:38 2003
From: eauth at softsys.co.at (Erwin Authried)
Date: 03 Mar 2003 13:46:38 +0100
Subject: [uClinux-dev] structure size ????
In-Reply-To: <200303031212.54940.fgiovag@tin.it>
References: <1132153BE85ED411B37A0000B4A7D87DCD3D@SERVEUR21> 
	<200303031212.54940.fgiovag@tin.it>
Message-ID: <1046695598.14806.7.camel@justakiss>

Am Mon, 2003-03-03 um 12.12 schrieb Fabio Giovagnini:
> According my knowledge there are two aspects:
> 1) the alignment capability of yuor microprocessor. You should know if you can 
> align a word to an odd address or if you can align a long word to an address 
> that isn't multiple of 4. On my microcprocessor (hitachi h8300h,h8s, sh2,sh3) 
> this is not possible so you cannot align:
> struct _uuu {
> 	usigned long a1;
> 	unsigned char a2;
> 	unsigned short a3;
> } uuu;
> because a3c in on an odd address and for my micro it is not allowed;
> 
If you use the packed attribute, it is the compilers task to take care
about acess on unaligned adresses. The compiler will generate the
necessary byte access and shift instructions. I don't know about the
hitachi, but if there is code generated that makes a 16-bit access on an
odd address, then it's probably either a gcc bug or some architecture
specific option thats missing. At least for the ARM7TDMI, it works fine
with gcc-2.95.3. 

Regards,
Erwin




From tchen at on-go.com  Mon Mar  3 11:26:06 2003
From: tchen at on-go.com (Thomas Chen)
Date: Mon, 03 Mar 2003 08:26:06 -0800
Subject: [uClinux-dev] structure size ????
In-Reply-To: <1046695598.14806.7.camel@justakiss>
Message-ID: <BA88C21E.8CC0%tchen@on-go.com>

a lot of interesting discussion on this... but my original question
was: is there any way to tell compiler (for arm7tdmi) to align
on 16 bit boundry instead of 32 ???

thanks


on 3/3/03 4:46 AM, Erwin Authried at eauth at softsys.co.at wrote:

> Am Mon, 2003-03-03 um 12.12 schrieb Fabio Giovagnini:
>> According my knowledge there are two aspects:
>> 1) the alignment capability of yuor microprocessor. You should know if you
>> can 
>> align a word to an odd address or if you can align a long word to an address
>> that isn't multiple of 4. On my microcprocessor (hitachi h8300h,h8s, sh2,sh3)
>> this is not possible so you cannot align:
>> struct _uuu {
>> usigned long a1;
>> unsigned char a2;
>> unsigned short a3;
>> } uuu;
>> because a3c in on an odd address and for my micro it is not allowed;
>> 
> If you use the packed attribute, it is the compilers task to take care
> about acess on unaligned adresses. The compiler will generate the
> necessary byte access and shift instructions. I don't know about the
> hitachi, but if there is code generated that makes a 16-bit access on an
> odd address, then it's probably either a gcc bug or some architecture
> specific option thats missing. At least for the ARM7TDMI, it works fine
> with gcc-2.95.3. 
> 
> Regards,
> Erwin
> 
> 
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org
> 



From chri at infis.univ.trieste.it  Mon Mar  3 08:53:01 2003
From: chri at infis.univ.trieste.it (Christian Pellegrin)
Date: Mon, 3 Mar 2003 14:53:01 +0100 (CET)
Subject: [uClinux-dev] structure size ????
In-Reply-To: <BA88C21E.8CC0%tchen@on-go.com>
References: <BA88C21E.8CC0%tchen@on-go.com>
Message-ID: <Pine.LNX.4.53.0303031448350.11680@sole.infis.univ.trieste.it>


On Mon, 3 Mar 2003, Thomas Chen wrote:

> 
> a lot of interesting discussion on this... but my original question
> was: is there any way to tell compiler (for arm7tdmi) to align
> on 16 bit boundry instead of 32 ???
> 

Look for the __attribute__ to gcc (in the info manual under compiler 
extension, variabile attribute). There is an attribute called alligned 
that should do the trick. I cut&paste some words from there ....

HTH,
Bye!

`aligned (ALIGNMENT)'
     This attribute specifies a minimum alignment for the variable or
     structure field, measured in bytes.  For example, the declaration:

          int x __attribute__ ((aligned (16))) = 0;

     causes the compiler to allocate the global variable `x' on a
     16-byte boundary.  On a 68040, this could be used in conjunction
     with an `asm' expression to access the `move16' instruction which
     requires 16-byte aligned operands.

     You can also specify the alignment of structure fields.  For
     example, to create a double-word aligned `int' pair, you could
     write:

          struct foo { int x[2] __attribute__ ((aligned (8))); };

     This is an alternative to creating a union with a `double' member
     that forces the union to be double-word aligned.

     As in the preceding examples, you can explicitly specify the
     alignment (in bytes) that you wish the compiler to use for a given
     variable or structure field.  Alternatively, you can leave out the
     alignment factor and just ask the compiler to align a variable or
     field to the maximum useful alignment for the target machine you
     are compiling for.  For example, you could write:

          short array[3] __attribute__ ((aligned));



From chri at infis.univ.trieste.it  Mon Mar  3 09:32:26 2003
From: chri at infis.univ.trieste.it (Christian Pellegrin)
Date: Mon, 3 Mar 2003 15:32:26 +0100 (CET)
Subject: [uClinux-dev] structure size ????
In-Reply-To: <Pine.LNX.4.53.0303031448350.11680@sole.infis.univ.trieste.it>
References: <BA88C21E.8CC0%tchen@on-go.com> <Pine.LNX.4.53.0303031448350.11680@sole.infis.univ.trieste.it>
Message-ID: <Pine.LNX.4.53.0303031532000.11680@sole.infis.univ.trieste.it>


On Mon, 3 Mar 2003, Christian Pellegrin wrote:

> 
> 
> On Mon, 3 Mar 2003, Thomas Chen wrote:
> 
> > 
> > a lot of interesting discussion on this... but my original question
> > was: is there any way to tell compiler (for arm7tdmi) to align
> > on 16 bit boundry instead of 32 ???
> > 
> 
> Look for the __attribute__ to gcc (in the info manual under compiler 
> extension, variabile attribute). There is an attribute called alligned 
> that should do the trick. I cut&paste some words from there ....
> 

sorry I guess that I said a stupid thing .... 16 < 32 :-)

Bye!


From shuliang at itri.org.tw  Sun Mar  2 11:05:45 2003
From: shuliang at itri.org.tw (Shu-Liang Lee)
Date: Mon, 3 Mar 2003 00:05:45 +0800
Subject: [uClinux-dev] About the uClinux-dist-20030226.tar.gz, user_only error
Message-ID: <004b01c2e0d5$983dd480$cd67608c@mediaworks>

Dear sirs:
 
I download the uCLinux distribution uClinux-dist-20030226.tar.gz, and
make
 
make menuconfig
> Samsung/4510
> linux-2.4.x
> uClib
> others I choice the default setting
 
make lib_only => ok!
make user_only => I got a error show below...why...
 
[ ! -d "user" ] || make ARCH=armnommu CROSS_COMPILE=arm-elf- -C user
make[1]: Entering directory `/usr/temp/user'
for i in /usr/temp/vendors/Samsung/4510B/. boa busybox dhcpcd-new ftp
games inetd init login ping ramimage route sash telnet telnetd ; do
make -C $i || exit  ; done
make[2]: Entering directory `/usr/temp/vendors/Samsung/4510B'
make[2]: Nothing to be done for `clean'.
make[2]: Leaving directory `/usr/temp/vendors/Samsung/4510B'
make[2]: Entering directory `/usr/temp/user/boa'
for i in src ; do make -C $i all || exit ; done
make[3]: Entering directory `/usr/temp/user/boa/src'
arm-elf-gcc   -g -fomit-frame-pointer   -Dlinux -D__linux__ -Dunix
-D__uClinux__ -DEMBED -I/usr/temp/lib/uClibc/include
-I/usr/temp/lib/libm -I/usr/temp -fno-builtin -nostartfiles
-I/usr/temp/linux-2.4.x/include -DOLD_CONFIG_PASSWORDS   -c -o auth.o
auth.c
auth.c:36: crypt_old.h: No such file or directory
make[3]: *** [auth.o] Error 1
make[3]: Leaving directory `/usr/temp/user/boa/src'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/usr/temp/user/boa'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/usr/temp/user'
make: *** [user_only] Error 2

p.s 
 
It seems like it can not find the crypt_old.h and I find it in the ...
/lib/libcrypt_old/crypt_old.h
 
1) I do not know why it has this kind of errors, this is a
distribution...?
2) where I can add the include path to the Makefile and how do I do?
like -I/lib/libcrypt_old/
 
regards,
ShuLiang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20030303/558391fc/attachment.html>

From MichaelT at systemexcelerator.com  Mon Mar  3 10:38:44 2003
From: MichaelT at systemexcelerator.com (Michael Tanenhaus)
Date: Mon, 03 Mar 2003 10:38:44 -0500
Subject: [uClinux-dev] Blackfin Status
Message-ID: <se6330dd.067@mail.systemexcelerator.com>

I noticed some discussion of a Blackfin port to uClinux... searchs of
the net show build paths and instructions for download that imply it was
out there at some point. What is the status here? Is the software
available for download? 
 
We currently are using DSPOS/Fusion to power our two DSP/Gig Ethernet
DAP, but are always looking into future/next steps for design.
 
 
 
Michael J. Tanenhaus
Director of Technical Operations
System Excelerator, Inc.
http://www.systemexcelerator.com
410-721-7116
Cell: 410-703-5441
Fax: 410-721-6894
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20030303/bf00c80f/attachment.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: Michael Tanenhaus.vcf
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20030303/bf00c80f/attachment.ksh>

From mathieu-rousseau at ifrance.com  Mon Mar  3 11:39:07 2003
From: mathieu-rousseau at ifrance.com (Mathieu Rousseau)
Date: Mon, 3 Mar 2003 17:39:07 +0100
Subject: [uClinux-dev] Eb55 boot problems.
Message-ID: <20030303173907.5bdb3424.mathieu-rousseau@ifrance.com>

Hi all.

It's my first message here and I post because i'm very stuck in running my uClinux on my Atmel/eb55 board.
So my board has 256KB RAM at 0x02000000 address 
and 1MB user Flash 

I successfully compiled the tools (with some changes in the build script found on arm-elf-tools folder of uClinux/pub download area).

I successfully compiled my kernel...

So now i get an 600KB linux.bin image. I downloaded it at 0x01100000 address (user area) via my windows flash downloader. I don't know how to download image via arm-elf-insight (5.3).

Anyway, nothing is written on the serial port (i expected some boot informations).

As I don't know how to make it run, download it on my board and boot it, I'd like some help...

thanks

Mathieu Rousseau
_____________________________________________________________________
GRAND JEU SMS : Pour gagner un NOKIA 7650, envoyez le mot IF au 61321
(prix d'un SMS + 0.35 euro). Un SMS vous dira si vous avez gagn?.
R?glement : http://www.ifrance.com/_reloc/sign.sms



From philwil at earthlink.net  Mon Mar  3 12:00:38 2003
From: philwil at earthlink.net (Phil Wilshire)
Date: Mon, 03 Mar 2003 12:00:38 -0500
Subject: [uClinux-dev] uClinux Training Workshop Ottawa March 25-28th.
Message-ID: <3E638A36.BECFF2B2@earthlink.net>

Hi All,

Once again, please forgive the commercial.

I am planning another uClinux workshop, this time in Ottawa Canada.

Dates are March 25th - 28th 2003.

This will be very similar in content to the Munich Workshop and will feature both
ARM and Coldfire development targets.

The class is designed to be of interest to both beginners and experienced developers.

Key topics include:

  * Working with the toolchain
  * Debugging using BDM and JTAG
  * Simulators
  * Kernel API and interface 
  * System Calls
  * Kernel Boot Sequence
  * Working with Flash Memory
  * Simple Bootloaders
  * Modules and Device Drivers 
  * Using Interrupts
  * Power Management
  * Embedded Hard Real Time
  * Working with User Code
  * Configuring and using Boa
  * Threads

Please contact me if you are interested in attending this class.
regards,
  Phil Wilshire




-- 
SDCS -- System Design & Consulting Services LLC, http://www.sysdcs.com
** Embedded Linux Training **  email me for details  
630 Springhouse Sq., Leesburg VA 20175 t: 703 669 9766 f: 703 669 9768


From tchen at on-go.com  Mon Mar  3 12:35:02 2003
From: tchen at on-go.com (thomas chen)
Date: Mon, 03 Mar 2003 12:35:02 -0500
Subject: [uClinux-dev] memory allocation / task space....
Message-ID: <3E639246.E597334E@on-go.com>

in my application, i spawn (vfork) a child process to do some work
(over and over again).... and after a while... i got an message
from kernel

"Unable to allocate RAM for process data"

and the memory map seems to be a bit fragmented...

51 * 4kb
19* 8kb
12 * 16kb
1 * 32kb
1 * 64kb
1 * 128kb
= 772kb



is there anyway to have some kind of "de-fragmentation" for 
space????  is there anyway to keep the process in ram instead
of being loaded/reallocated from romfs???

thanks


From sdeepa69 at yahoo.com  Mon Mar  3 15:44:52 2003
From: sdeepa69 at yahoo.com (Deepa Sivasankarane)
Date: Mon, 3 Mar 2003 12:44:52 -0800 (PST)
Subject: [uClinux-dev] m68knommu - entry.S
Message-ID: <20030303204452.91768.qmail@web80407.mail.yahoo.com>

Hi,

A different stack  is used to service a system call
within another system call ISR ?

SAVE_SWITCH_STACK and RESTORE_SWITCH_STACK  ?


thanx.
Deepa

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com


From Amit.Lubovsky at infineon.com  Mon Mar  3 15:48:41 2003
From: Amit.Lubovsky at infineon.com (Amit.Lubovsky at infineon.com)
Date: Mon, 3 Mar 2003 21:48:41 +0100 
Subject: [uClinux-dev] AMD - Am29LV160B
Message-ID: <04C8EDC5AE3FD611ABE40002B39CF69B07F2DB@ntah901e.savan.com>

Hi,

Has anyone used the mtd device with the AMD
Am29LV160B chips? They are 16 Megabit (2M x 8-Bit/1M x 16-Bit) chips
and are CFI-compatible.

I work with kernel 2.4.6 and am trying to detect 4MB,
2 x16 bit devices in parallel (32 bit access) at address 0,


I have mapped the physical addresses in drivers/mtd/maps/purple.c

...
#define WINDOW_ADDR 0xb0000000
#define WINDOW_SIZE 0x400000
#define BUSWIDTH 2

static struct mtd_partition easyport_partitions[]={
            { name: "boot partition",
              offset: 0,
              size: 0x100000 },
            { name: "partition 1",
              offset: 0x100000,
              size: 0x100000 },
            { name: "partition 2",
              size: 0x200000,
              offset: 0x200000 }
};




Here are the options I use:

option #1
----------
# Memory Technology Devices (MTD)
#
CONFIG_MTD=y
CONFIG_MTD_PARTITIONS=y
CONFIG_MTD_CHAR=y
CONFIG_MTD_BLOCK=y

# RAM/ROM/Flash chip drivers
#
CONFIG_MTD_CFI=y
CONFIG_MTD_CFI_AMDSTD=y

# Mapping drivers for chip access
#
#
CONFIG_MTD_PURPLE=y

For the first option I get:
---------------------------
purple flash device: 400000 at b0000000
purple_map.map_priv_1=0xb0000000
-----------------> FLASH #2
--------------------------->file: chipreg.c name=cfi drv=8020c970
-----------@@@@@@@@@@ CFIDEV_BUSWIDTH_2 CFIDEV_INTERLEAVE_1
--------########## func: cfi_probe_chip CFI_DEVICETYPE_X16
-----------@@@@@@@@@@ CFIDEV_BUSWIDTH_2 CFIDEV_INTERLEAVE_2
--------########## func: cfi_probe_chip CFI_DEVICETYPE_X8
--------########## func: cfi_probe_chip CFI_DEVICETYPE_X16
--------------> file: cfi_probe.c func: cfi_cfi_probe index=-1
Physically mapped flash: Found no CFI device at location zero
--------------> file: cfi_probe.c  cfi=0
mymtd=0x00000000


option #2
----------
# Memory Technology Devices (MTD)
#
CONFIG_MTD=y
CONFIG_MTD_PARTITIONS=y
CONFIG_MTD_CHAR=y
CONFIG_MTD_BLOCK=y

# RAM/ROM/Flash chip drivers
#
CONFIG_MTD_CFI=y
CONFIG_MTD_CFI_ADV_OPTIONS=y
CONFIG_MTD_CFI_NOSWAP=y
CONFIG_MTD_CFI_GEOMETRY=y
CONFIG_MTD_CFI_B4=y
CONFIG_MTD_CFI_I2=y
CONFIG_MTD_CFI_AMDSTD=y

#
# Mapping drivers for chip access
#
CONFIG_MTD_PURPLE=y

for option #2 I get:
--------------------

purple flash device: 400000 at b0000000
purple_map.map_priv_1=0xb0000000
--------------------------->file: chipreg.c name=cfi drv=8020a970
cfi_probe called with unsupported buswidth 2
--------------> file: cfi_probe.c func: cfi_cfi_probe index=-1
Physically mapped flash: Found no CFI device at location zero
--------------> file: cfi_probe.c  cfi=0
mymtd=0x00000000

Any help would be appreciated.

Thanks,
Amit.



From richard.klingler at violasystems.com  Mon Mar  3 16:00:45 2003
From: richard.klingler at violasystems.com (Richard Klingler)
Date: Mon, 3 Mar 2003 23:00:45 +0200
Subject: [uClinux-dev] AMD - Am29LV160B
In-Reply-To: 04C8EDC5AE3FD611ABE40002B39CF69B07F2DB@ntah901e.savan.com
Message-ID: <000001c2e1c7$f98aa630$0401000a@home>


-----Original Message-----
From: Amit.Lubovsky at infineon.com [mailto:Amit.Lubovsky at infineon.com] 
Sent: Montag, 3. M?rz 2003 22:48
To: uclinux-dev at uclinux.org
Subject: [uClinux-dev] AMD - Am29LV160B


Hi,

Has anyone used the mtd device with the AMD
Am29LV160B chips? They are 16 Megabit (2M x 8-Bit/1M x 16-Bit) chips
and are CFI-compatible.

I work with kernel 2.4.6 and am trying to detect 4MB,
2 x16 bit devices in parallel (32 bit access) at address 0,


I have mapped the physical addresses in drivers/mtd/maps/purple.c

..
#define WINDOW_ADDR 0xb0000000
#define WINDOW_SIZE 0x400000
#define BUSWIDTH 2

Ehhm...

I use one 16-bit flash and also have "BUSWIDTH 2" (o;


Rick






From tchen at on-go.com  Mon Mar  3 16:40:45 2003
From: tchen at on-go.com (thomas chen)
Date: Mon, 03 Mar 2003 16:40:45 -0500
Subject: [uClinux-dev] running out of memory OR NOT???
Message-ID: <3E63CBDD.E5CEE474@on-go.com>

i am getting this message

Allocation of length 160522 from process 33 failed
Buffer memory:      356kB
Cache memory:     1192kB
Free pages:         436kB (     0kB HighMem)
Zone:DMA freepages:     0kB min:     0kB low:     0kB high:     0kB
Zone:Normal freepages:   436kB min:    80kB low:   160kB high:   240kB
Zone:HighMem freepages:     0kB min:     0kB low:     0kB high:     0kB
( Active: 310, inactive: 77, free: 109 )
= 0kB)
43*4kB 11*8kB 1*16kB 1*32kB 0*64kB 1*128kB 0*256kB 0*512kB 0*1024kB
0*2048kB = 436kB)
= 0kB)
Unable to allocate RAM for process data, errno 0
munmap of non-mmaped memory by process 33 (task) 002c66d0

but then program task continues to run???? after the message and seems
to work
just fine

is this a right message? what is happening there???

thanks....


From bkuhn at metrowerks.com  Mon Mar  3 16:44:08 2003
From: bkuhn at metrowerks.com (Bernhard Kuhn)
Date: Mon, 03 Mar 2003 22:44:08 +0100
Subject: [uClinux-dev] AMD - Am29LV160B
References: <04C8EDC5AE3FD611ABE40002B39CF69B07F2DB@ntah901e.savan.com>
Message-ID: <3E63CCA8.7000202@metrowerks.com>

Amit.Lubovsky at infineon.com wrote:

> 2 x16 bit devices in parallel (32 bit access) at address 0,

In this case, i guess you need to apply BUSWIDTH 4 in the
mapping driver and then

   Memory Technology Devices (MTD)  ---> RAM/ROM/Flash chip drivers

should look like this:

   ? ?    [*]   Common Flash Interface (CFI) support
   ? ?    [ ]   CFI Virtual erase regions (EXPERIMENTAL) (NEW)
   ? ?    [*]   CFI Advanced configuration options (NEW)
   ? ?    (NO) Flash cmd/query data swapping
   ? ?    [*]   Specific CFI Flash geometry selection (NEW)
   ? ?    [ ]     Support  8-bit buswidth (NEW)
   ? ?    [ ]     Support 16-bit buswidth (NEW)
   ? ?    [*]     Support 32-bit buswidth (NEW)
   ? ?    [ ]     Support 1-chip flash interleave (NEW)
   ? ?    [*]     Support 2-chip flash interleave (NEW)
   ? ?    [ ]     Support 4-chip flash interleave (NEW)
   ? ?    [ ]     CFI support for Intel/Sharp Basic/Extended Commands
   ? ?    [*]     CFI support for AMD/Fujitsu Standard Commands

And maybe you need to change "Flash cmd/query data swapping"
because auf endianess issues.

hope that helps ...

Bernhard



From bkuhn at metrowerks.com  Mon Mar  3 17:13:19 2003
From: bkuhn at metrowerks.com (Bernhard Kuhn)
Date: Mon, 03 Mar 2003 23:13:19 +0100
Subject: [uClinux-dev] running out of memory OR NOT???
References: <3E63CBDD.E5CEE474@on-go.com>
Message-ID: <3E63D37F.8020807@metrowerks.com>

thomas chen wrote:

> Allocation of length 160522 from process 33 failed
[...]
> 43*4kB 11*8kB 1*16kB 1*32kB 0*64kB 1*128kB 0*256kB 0*512kB 0*1024kB
> 0*2048kB = 436kB)

You application tries to allocate 160 KiB of memory, but the biggest
contiguous junk of memory left at that moment is only 128 KiB.

> but then program task continues to run????

malloc() returns with an error value - you need to decide in
your application what needs to be done, then.

 > after the message and seems to work  just fine

Maybe your application doesn't use the newly allocated memory? :-)

Bernhard




From tchen at on-go.com  Mon Mar  3 20:55:07 2003
From: tchen at on-go.com (Thomas Chen)
Date: Mon, 03 Mar 2003 17:55:07 -0800
Subject: [uClinux-dev] running out of memory OR NOT???
In-Reply-To: <3E63D37F.8020807@metrowerks.com>
Message-ID: <BA89477B.8CF7%tchen@on-go.com>

Hmmm... the program does not allocate any memory?

this is happening when process A is vforking process B
(process B is the program task)....

i thought the kernel is trying to allocate space for the task?



on 3/3/03 2:13 PM, Bernhard Kuhn at bkuhn at metrowerks.com wrote:

> thomas chen wrote:
> 
>> Allocation of length 160522 from process 33 failed
> [...]
>> 43*4kB 11*8kB 1*16kB 1*32kB 0*64kB 1*128kB 0*256kB 0*512kB 0*1024kB
>> 0*2048kB = 436kB)
> 
> You application tries to allocate 160 KiB of memory, but the biggest
> contiguous junk of memory left at that moment is only 128 KiB.
> 
>> but then program task continues to run????
> 
> malloc() returns with an error value - you need to decide in
> your application what needs to be done, then.
> 
>> after the message and seems to work  just fine
> 
> Maybe your application doesn't use the newly allocated memory? :-)
> 
> Bernhard
> 
> 
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org
> 



From davidm at snapgear.com  Mon Mar  3 18:32:35 2003
From: davidm at snapgear.com (David McCullough)
Date: Tue, 4 Mar 2003 09:32:35 +1000
Subject: [uClinux-dev] About the uClinux-dist-20030226.tar.gz, user_only error
In-Reply-To: <004b01c2e0d5$983dd480$cd67608c@mediaworks>
References: <004b01c2e0d5$983dd480$cd67608c@mediaworks>
Message-ID: <20030303233235.GA8672@beast.internal.moreton.com.au>

Jivin Shu-Liang Lee lays it down ...
> Dear sirs:
>  
> I download the uCLinux distribution uClinux-dist-20030226.tar.gz, and
> make
>  
> make menuconfig
> > Samsung/4510
> > linux-2.4.x
> > uClib
> > others I choice the default setting
>  
> make lib_only => ok!
> make user_only => I got a error show below...why...


There is some infor missing from the config.arch file,  attached is the
patch needed.

Cheers,
Davidm

-- 
David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
davidm at snapgear.com  Fx: +61 7 3891 3630  Custom Embedded Solutions + Security
-------------- next part --------------
Index: vendors/config/armnommu/config.arch
===================================================================
RCS file: /cvs/sw/new-wave/vendors/config/armnommu/config.arch,v
retrieving revision 1.1
diff -u -r1.1 config.arch
--- vendors/config/armnommu/config.arch	24 Feb 2003 23:55:05 -0000	1.1
+++ vendors/config/armnommu/config.arch	3 Mar 2003 23:22:14 -0000
@@ -149,6 +149,7 @@
 	INCPCAP = -I$(ROOTDIR)/lib/libpcap
 	INCSSL  = -I$(ROOTDIR)/lib/libssl/include
 	INCVEND = -I$(ROOTDIR)/vendors/include
+	INCCRYPTOLD = -I$(ROOTDIR)/lib/libcrypt_old
 
   ifdef CONFIG_USER_DEBUG
 	CFLAGS  :=  $($(UOPT),$(UOPT),-O1) -g
@@ -159,7 +160,7 @@
 	CFLAGS  += $(CPUFLAGS)
 	CFLAGS  += $(VENDOR_CFLAGS)
 	CFLAGS  += -Dlinux -D__linux__ -Dunix -D__uClinux__ -DEMBED
-	CFLAGS  += $(INCLIBC) $(INCLIBM)
+	CFLAGS  += $(INCLIBC) $(INCLIBM) $(INCCRYPTOLD)
 	CFLAGS  += -I$(ROOTDIR)
 	CFLAGS  += -fno-builtin
 	CFLAGS  += -nostartfiles

From davidm at snapgear.com  Mon Mar  3 18:43:08 2003
From: davidm at snapgear.com (David McCullough)
Date: Tue, 4 Mar 2003 09:43:08 +1000
Subject: [uClinux-dev] memory allocation / task space....
In-Reply-To: <3E639246.E597334E@on-go.com>
References: <3E639246.E597334E@on-go.com>
Message-ID: <20030303234308.GD8672@beast.internal.moreton.com.au>

Jivin thomas chen lays it down ...
> 
> in my application, i spawn (vfork) a child process to do some work
> (over and over again).... and after a while... i got an message
> from kernel
> 
> "Unable to allocate RAM for process data"
> 
> and the memory map seems to be a bit fragmented...
> 
> 51 * 4kb
> 19* 8kb
> 12 * 16kb
> 1 * 32kb
> 1 * 64kb
> 1 * 128kb
> = 772kb
> 
> is there anyway to have some kind of "de-fragmentation" for 
> space????  is there anyway to keep the process in ram instead
> of being loaded/reallocated from romfs???

Yes,  it's called XIP,  if you platform supports it you can dramatically
reduce your RAM requirements (arm and m68k both do it),

Cheers,
Davidm

-- 
David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
davidm at snapgear.com  Fx: +61 7 3891 3630  Custom Embedded Solutions + Security


From selvam at sesl.global.sharp.co.jp  Mon Mar  3 19:33:08 2003
From: selvam at sesl.global.sharp.co.jp (Selvam)
Date: Tue, 4 Mar 2003 08:33:08 +0800
Subject: [uClinux-dev] toolchain config ?
In-Reply-To: <3E62EEF5.2080704@snapgear.com>
References: <20030301130859.31191.qmail@web11001.mail.yahoo.com>
 <3E62EEF5.2080704@snapgear.com>
Message-ID: <03030408330800.00946@KSLINUXPC>

I'm trying to recompile the arm-ucLinux kernel 
worked partially by ex-staffs. I'm able to run make clean 
and make dep. However when I'm run "make"
(or make zImage) I'm getting the following errors:

----------------------------------------
[root at KSLINUXPC linux]# make zImage
arm-uclinux-gcc -D__KERNEL__ -I/home/tulika/linux/include -Wall 
-Wstrict-prototypes -O2 ?-fno-strict-aliasing -fno-common -pipe -g -DNO_MM 
-mapcs-32 ?-mtune=arm7tdmi -mshort-load-bytes -msoft-float -g ?-c -o 
init/main.o init/main.c
arm-uclinux-gcc: installation problem, cannot exec `cc1': No such file or 
directory
as: unrecognized option `-mapcs-32'
<command line>: warning: "system" re-asserted
make: *** [init/main.o] Error 1
[root at KSLINUXPC linux]# make Image
arm-uclinux-gcc -D__KERNEL__ -I/home/tulika/linux/include -Wall 
-Wstrict-prototypes -O2 ?-fno-strict-aliasing -fno-common -pipe -g -DNO_MM 
-mapcs-32 ?-mtune=arm7tdmi -mshort-load-bytes -msoft-float -g ?-c -o 
init/main.o init/main.c
arm-uclinux-gcc: installation problem, cannot exec `cc1': No such file or 
directory
as: unrecognized option `-mapcs-32'
<command line>: warning: "system" re-asserted
make: *** [init/main.o] Error 1
------------------------------------

I believe it's something to do with toolchain configuration,
but not exatly sure what it is ?

thanks
SELVAM



From philwil at earthlink.net  Mon Mar  3 19:47:09 2003
From: philwil at earthlink.net (Phil Wilshire)
Date: Mon, 03 Mar 2003 19:47:09 -0500
Subject: [uClinux-dev] toolchain config ?
References: <20030301130859.31191.qmail@web11001.mail.yahoo.com>
	 <3E62EEF5.2080704@snapgear.com> <03030408330800.00946@KSLINUXPC>
Message-ID: <3E63F78D.712E15A0@earthlink.net>

Hi Selvam,
This looks like a path problem.
Make sure that the correct path to the arm-uclinux-??? tools is in your
PATH environment.

for example...

export PATH=/usr/local/uclinux/bin:$PATH

regards
  Phil Wilshire

Selvam wrote:
> 
> I'm trying to recompile the arm-ucLinux kernel
> worked partially by ex-staffs. I'm able to run make clean
> and make dep. However when I'm run "make"
> (or make zImage) I'm getting the following errors:
> 
> ----------------------------------------
> [root at KSLINUXPC linux]# make zImage
> arm-uclinux-gcc -D__KERNEL__ -I/home/tulika/linux/include -Wall
> -Wstrict-prototypes -O2  -fno-strict-aliasing -fno-common -pipe -g -DNO_MM
> -mapcs-32  -mtune=arm7tdmi -mshort-load-bytes -msoft-float -g  -c -o
> init/main.o init/main.c
> arm-uclinux-gcc: installation problem, cannot exec `cc1': No such file or
> directory
> as: unrecognized option `-mapcs-32'
> <command line>: warning: "system" re-asserted
> make: *** [init/main.o] Error 1
> [root at KSLINUXPC linux]# make Image
> arm-uclinux-gcc -D__KERNEL__ -I/home/tulika/linux/include -Wall
> -Wstrict-prototypes -O2  -fno-strict-aliasing -fno-common -pipe -g -DNO_MM
> -mapcs-32  -mtune=arm7tdmi -mshort-load-bytes -msoft-float -g  -c -o
> init/main.o init/main.c
> arm-uclinux-gcc: installation problem, cannot exec `cc1': No such file or
> directory
> as: unrecognized option `-mapcs-32'
> <command line>: warning: "system" re-asserted
> make: *** [init/main.o] Error 1
> ------------------------------------
> 
> I believe it's something to do with toolchain configuration,
> but not exatly sure what it is ?
> 
> thanks
> SELVAM
> 
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org

-- 
SDCS -- System Design & Consulting Services LLC, http://www.sysdcs.com
** Embedded Linux Training **  email me for details  
630 Springhouse Sq., Leesburg VA 20175 t: 703 669 9766 f: 703 669 9768


From mathieu-rousseau at ifrance.com  Mon Mar  3 21:01:03 2003
From: mathieu-rousseau at ifrance.com (Mathieu Rousseau)
Date: Tue, 4 Mar 2003 03:01:03 +0100
Subject: [uClinux-dev] uClinux-dist-20030226.tar.gz : user_only errors (other)
Message-ID: <20030304030103.191f0863.mathieu-rousseau@ifrance.com>

Hi

I try to compile it but it fails. I applied the pacth that David McCullough sent today about missing stuff.

make menuconfig
Atmel/AT91
linux-2.0.x
uC-libc
change settings for my card:
add M55800 card support (eb55 with 256KB ram, 1MB user flash)
base address for DRAM: 0x02000000
amount of DRAM: 00040000
Base address for flash: 0x01000000
amount of flash: 00100000
EBI: y  (hum... i don't know if i must check this on but seems to be the way to initialize address. someone can tell me if i'm wrong or not).
boot from flash: y

i let the other stuff as configured.

make lib_only: ok

make user_only fails, error message below.

Can you help me.


error message:
---------------------------------------------------------------
boa.elf2flt: In function `main':
/opt/temp/uClinux-dist/user/boa/src/boa.c:192: undefined reference to `__ntohl'
/opt/temp/uClinux-dist/user/boa/src/boa.c:193: undefined reference to `__ntohs'
boa.elf2flt: In function `get_sock_request':
/opt/temp/uClinux-dist/user/boa/src/request.c:838: undefined reference to `__ntohs'
collect2: ld returned 1 exit status
make[3]: *** [boa] Error 1
make[3]: Leaving directory `/opt/temp/uClinux-dist/user/boa/src'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/opt/temp/uClinux-dist/user/boa'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/opt/temp/uClinux-dist/user'
make: *** [user_only] Error 2
----------------------------------------------------------------

_____________________________________________________________________
Envie de discuter en "live" avec vos amis ? T?l?charger MSN Messenger
http://www.ifrance.com/_reloc/m la 1?re messagerie instantan?e de France



From hnmem at 163.com  Mon Mar  3 20:47:30 2003
From: hnmem at 163.com (hn)
Date: Tue, 4 Mar 2003 9:47:30 +0800
Subject: [uClinux-dev] Help on ide 5307/ints.c(47): default irq handler vec=165 [0xa5]
Message-ID: <20030304014854.F047A1D0B0EC0@sm204.163.com>

hi,all,
	Is  info like:
    ../5307/ints.c(47): default irq handler vec=165 [0xa5]
    a nightmare  that persists on Coldfire families?
   Similiar discussion has been seen many times, but no explicit answer found.

I am using a 5249 board and running uClinux(20020927 version,2.4.x kernel) on it,
Everything works fine until I type reboot (sash):
/> reboot
unmounting /home
flushing ide devices: hda
Restarting system.

..

Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 50MHz system bus speed for PIO modes; override with idebus=xx
./5307/ints.c(47): default irq handler vec=165 [0xa5]
./5307/ints.c(47): default irq handler vec=165 [0xa5]
./5307/ints.c(47): default irq handler vec=165 [0xa5]
./5307/ints.c(47): default irq handler vec=165 [0xa5]

..

But if I reset the board by pressing the reset button of by BDM tools, the system boots up with no problem, what's wrong ?reboot code?or ide driver?
Thanks .

Best Regards.
			hn
									2003-03-04






From miles at lsi.nec.co.jp  Mon Mar  3 21:27:46 2003
From: miles at lsi.nec.co.jp (Miles Bader)
Date: 04 Mar 2003 11:27:46 +0900
Subject: [uClinux-dev] Re: gdbserver relocation?
In-Reply-To: <3E5A3E20.5040706@redhat.com>
References: <buok7fqqdzi.fsf@mcspd15.ucom.lsi.nec.co.jp>
	<20030224142831.GB24793@nevyn.them.org>
	<20030224152608.GB2206@gnu.org> <3E5A3E20.5040706@redhat.com>
Message-ID: <buoheaj3ly5.fsf@mcspd15.ucom.lsi.nec.co.jp>

Andrew Cagney <ac131313 at redhat.com> writes:
> I suspect you want to send something back using qOffsets.

Yes, that's exactly what I needed.

What do you think of the following patch (I added the `handle_query'
target callback, and then provided a linux-low.c implementation)?

-Miles


Patch:


-------------- next part --------------
A non-text attachment was scrubbed...
Name: gdb-5.3-qoffsets-20030304.patch
Type: text/x-patch
Size: 3424 bytes
Desc: gdb-5.3-qoffsets-20030304.patch
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20030304/a316d290/attachment.patch>
-------------- next part --------------


-- 
I'm beginning to think that life is just one long Yoko Ono album; no rhyme
or reason, just a lot of incoherent shrieks and then it's over.  --Ian Wolff

From miles at lsi.nec.co.jp  Mon Mar  3 22:41:59 2003
From: miles at lsi.nec.co.jp (Miles Bader)
Date: 04 Mar 2003 12:41:59 +0900
Subject: [uClinux-dev] Re: gdbserver relocation?
In-Reply-To: <20030304030318.GB31172@nevyn.them.org>
References: <buok7fqqdzi.fsf@mcspd15.ucom.lsi.nec.co.jp>
	<20030224142831.GB24793@nevyn.them.org>
	<20030224152608.GB2206@gnu.org> <3E5A3E20.5040706@redhat.com>
	<buoheaj3ly5.fsf@mcspd15.ucom.lsi.nec.co.jp>
	<20030304030318.GB31172@nevyn.them.org>
Message-ID: <buo8yvv3iig.fsf@mcspd15.ucom.lsi.nec.co.jp>

Daniel Jacobowitz <drow at mvista.com> writes:
> > What do you think of the following patch (I added the `handle_query'
> > target callback, and then provided a linux-low.c implementation)?
> 
> It looks reasonable to me.  Do you have GDB copyright papers on file?

I don't think so; ac131313 sent me a form to do this, which I CC'd to
the FSF a week ago or so, but I haven't received any reply yet (I will
certainly sign an assignment, but it may take a while to get a copyright
disclaimer from my work).

> Hmm, this only works if the executable is linked at 0 with data right
> after text.  Is that the case for all/most uClinux targets?

Yes, so far as I know.

Also, so far there's no standardization of the ptrace PT_TEXT_ADDR &c
macros; I justed added them to the v850 implementation.  The m68knommu
target uses hardwired numeric constants for the same functionality, but
hopefully the maintainers will add defines so this implementation will
work on it (gerg?  davidm?).

-Miles
-- 
Saa, shall we dance?  (from a dance-class advertisement)


From HenrySimmons17 at netzero.net  Mon Mar  3 22:46:45 2003
From: HenrySimmons17 at netzero.net (HenrySimmons17)
Date: Mon, 3 Mar 2003 19:46:45 -0800
Subject: [uClinux-dev] UCLINUX for PALM
References: <Pine.GSO.4.33.0302111240390.25930-100000@compserv1> <015801c2d222$ca8f38a0$ffc5fea9@henry133> <3E50444D.4010600@tbc.net> <004901c2d64e$13223fc0$ffc5fea9@henry133> <3E50E9DE.7050801@tbc.net> <000201c2d6d6$0d03e660$ffc5fea9@henry133> <3E524F5D.8020206@tbc.net> <000201c2d770$e5711e60$ffc5fea9@henry133> <3E5EB086.1070108@tbc.net> <000201c2dee8$065974a0$ffc5fea9@henry133> <3E5FE502.1060106@tbc.net> <000201c2dfc2$762ceb60$ffc5fea9@henry133> <3E61743D.6000901@tbc.net> <000201c2e074$63483560$ffc5fea9@henry133> <3E6192D6.60204@tbc.net> <002a01c2e082$999a6d00$ffc5fea9@henry133> <3E6274EB.7020605@tbc.net>
Message-ID: <000201c2e200$dcab81e0$ffc5fea9@henry133>

Hello Mike
uClinux is trying to run that is why you have to hard reset.
Check the following files: 
 In file: linux/arch/m68knommu/platform/68EZ328/PalmV/ram.ld
 Chane to read:
 ram  :   ORIGIN =  0x00000800,  LENGTH =  0x00800000 - 0x00000800
 eram :  ORIGIN =  0x00800000,  LENGTH =  0
 
 In file: linux/arch/m68kn0mmu/platform/68EZ328/PalmV/crt0_ram.S
      Just below  DEBUG( 'B );
Change the line:    moveal #0x001ffff0, %ssp
Change to:           moveal #0x007ffff0,  %ssp
Add line:              move.l #0x00800000, %a0
Add line:              move.l  %a0, _ramend
Henry

> Well, I recompiled the kernel again, this time with all three options 
> below. I fired up minicom /dev/ttyS0, but didn't see any activity while 
> uClinux was ordering pages. I had to hard reset the PDA to get it 
> operational again. Minicom was indeed configured correctly, because I 
> can see Hotsync sending "garbage" when I attempted to "Hotsync" with 
> Minicom - so that part, I know is working.
> 
> Where do we go from here? Seems as though uClinux is ordering pages, 
> wonder if I have the RAM/ROM configuration set up properly? I'm pretty 
> sure that the Palm IIIc has 2M ROM and 8M RAM. What numbers do I need to 
> verify for this?
> 
> Thanks,
> Mike




From HenrySimmons17 at netzero.net  Mon Mar  3 23:21:11 2003
From: HenrySimmons17 at netzero.net (HenrySimmons17)
Date: Mon, 3 Mar 2003 20:21:11 -0800
Subject: [uClinux-dev] UCLINUX for PALM
References: <Pine.GSO.4.33.0302070159150.23746-100000@compserv1> <000201c2cfbe$943f2fa0$ffc5fea9@henry133> <20030209232255.GA28757@beast.internal.moreton.com.au> <000701c2d0aa$a7f0f780$ffc5fea9@henry133> <20030210030607.GA4753@beast.internal.moreton.com.au> <001b01c2df42$376b2700$ffc5fea9@henry133> <20030303010709.GF17327@beast.internal.moreton.com.au>
Message-ID: <000201c2e205$b337fd20$ffc5fea9@henry133>

Hello Davidm...
> Jivin HenrySimmons17 lays it down ...
> > Hello David
> > I finally got the prompt />
> > The problem was the console kept defaulting to ttyS0 and I was
> >  not using a serial console. I was using the console on the
> >  Palm m500 (CONFIG_PILOT_CONSOLE). When I added
> > the statement  : tty0:linux:/bin/sh
> > into the file: PalmIIIx/inittab
> > it worked. I then removed the statement from PalmIIIx/inittab
> > & modified the Makefile in vendors/3com/PalmIIIx as follows:
> > case "$(LINUXDIR)" in \
> >  *2.0.*) ;; \
> >  *) echo "tty0:linux:/bin/sh" >> $(ROMFSDIR)/etc/inittab ;; \
> >  esac
> > and it worked. This change also can be merge into the distro.
>
> I usually run my IIIx without the fancy console this the current setup :-)
How do you do this?

> What would be good is if you could make a vendors/3com/m500 directory that
> does exactly what you want and send it to me and I will add it in
untouched.
> Just copy the PalmIIIx directory with your mods.
OK will do.

> What would also be good is if we can make the changes needed to
PalmLoader.c
> work on all platforms.  Perhaps read the XX register first,  add some
> bits then write it ?
OK will do.

Henry



From morgenckl at sinaman.com  Mon Mar  3 22:58:23 2003
From: morgenckl at sinaman.com (=?big5?B?bW9yZ2VuY2ts?=)
Date: Tue, 4 Mar 2003 11:58:23 +0800
Subject: [uClinux-dev] =?big5?B?W3VDbGludXgtZGV2XSBVTlNDUklCTEU=?=
Message-ID: <20030304035823.17550.qmail@pop3.sina.com.hk>


MorgenCKL


==================================================================
????????  http://sinamail.sina.com.hk

Intel Pentium 4 Processor - the centre of your digital world 
http://it.sina.com.hk/special/intel




From mathieu-rousseau at ifrance.com  Tue Mar  4 01:13:52 2003
From: mathieu-rousseau at ifrance.com (Mathieu Rousseau)
Date: Tue, 4 Mar 2003 07:13:52 +0100
Subject: [uClinux-dev] eb55 arm-elf-tools compilation
Message-ID: <20030304071352.07cdd077.mathieu-rousseau@ifrance.com>

hi

I have eb55 atmel card.

I use the build-uclinux-tools.sh shell script to compile my tool chain. i had some problems with it...
First using the last uClibc from CVS seemed to be a bad idea, it goes further with the uClibc.tar.gz that ewe can find in www.uclinux.org/pub/arm-elf-tools/ ...
The problem is i got problem with uClibc/extra/Configs/Config.arm options. I read the Config.cross.arm.uclinux one and there is some options that seemed to be interesting to put on for mmuless card.
Still i got stuck in compilation because of the UNIX98PTY_ONLY option:
when this option is enabled i got an error message (see at end of mail).
when it's disabled, it compiles but i don't know if it's good to do that. Will my serial port work for my compiled kernel or apps?

anyone has any clue?

thanks

Mathieu Rousseau


error message:
------------------------------------------------------------------------
ptsname.c:84: #error "UNIX98PTY_ONLY enabled but TIOCGPTN ioctl not supported by your kernel."
ptsname.c: In function `ptsname_r':
ptsname.c:69: warning: unused variable `ptyno'
make[2]: *** [ptsname.o] Error 1
------------------------------------------------------------------------
_____________________________________________________________________
Envie de discuter en "live" avec vos amis ? T?l?charger MSN Messenger
http://www.ifrance.com/_reloc/m la 1?re messagerie instantan?e de France



From mattw at lineo.com  Tue Mar  4 00:53:05 2003
From: mattw at lineo.com (Matt Waddel)
Date: Mon, 03 Mar 2003 22:53:05 -0700
Subject: [uClinux-dev] elf2flt porting questions
Message-ID: <3E643F41.3090901@lineo.com>

Hi All,

I am trying to port the elf2flt code to a new architecure
and I have some questions.

1) Are uClinux relocations limited to 4 bytes by the
operating system?  The following statement emits an error
when a 2 byte relocation is encountered, but 2 byte
relocations are used in the blackfin processor. (R_huimm16
and R_luimm16)  Is it ok to allow a sym_reloc_size of 2?

    /* Calculate the sym address ourselves.  */
    sym_reloc_size = bfd_get_reloc_size(q->howto);
    if (sym_reloc_size != 4) {
        printf("ERROR: bad reloc size=%d for symbol=%s\n",
                sym_reloc_size, sym_name);
        rc = -1;
        continue;
        }

2) Since there has been a some activity recently on the
uClinux mailing list about the elf2flt conversion, how is
the best way to determine if this is working correctly in
a new system?  Any troubleshooting tips would be
appreciated.

3) I get errors and the build dies during the creation of
the .gdb file.  I have commented out the .gdb file creation,
but could this be repaired by adding the stabs sections to
the linker script?

TIA.
Matt



From selvam at sesl.global.sharp.co.jp  Tue Mar  4 01:02:10 2003
From: selvam at sesl.global.sharp.co.jp (Selvam)
Date: Tue, 4 Mar 2003 14:02:10 +0800
Subject: [uClinux-dev] toolchain config ?
In-Reply-To: <3E63F78D.712E15A0@earthlink.net>
References: <20030301130859.31191.qmail@web11001.mail.yahoo.com>
 <03030408330800.00946@KSLINUXPC> <3E63F78D.712E15A0@earthlink.net>
Message-ID: <03030414021001.00946@KSLINUXPC>

Hi Phil, thanks.

I included the PATH for toolchain.
"make" went a little further but stopped with almost the same error.

------------------------------------
[root at KSLINUXPC linux]# make
dnsdomainname: Unknown host
arm-uclinux-gcc -D__KERNEL__ -I/home/tulika/linux/include -Wall 
-Wstrict-prototypes -O2  -fno-strict-aliasing -fno-common -pipe -g -DNO_MM 
-mapcs-32  -mtune=arm7tdmi -mshort-load-bytes -msoft-float -g 
-DUTS_MACHINE='"armnommu"' -c -o init/version.o init/version.c
arm-uclinux-gcc: installation problem, cannot exec `cc1': No such file or 
directory
<command line>: warning: "system" re-asserted
as: unrecognized option `-mapcs-32'
make: *** [init/version.o] Error 1
------------------------------------


On Tuesday 04 March 2003 08:47, Phil Wilshire wrote:
> Hi Selvam,
> This looks like a path problem.
> Make sure that the correct path to the arm-uclinux-??? tools is in your
> PATH environment.
>
> for example...
>
> export PATH=/usr/local/uclinux/bin:$PATH
>
> regards
>   Phil Wilshire
>
> Selvam wrote:
> > I'm trying to recompile the arm-ucLinux kernel
> > worked partially by ex-staffs. I'm able to run make clean
> > and make dep. However when I'm run "make"
> > (or make zImage) I'm getting the following errors:
> >
> > ----------------------------------------
> > [root at KSLINUXPC linux]# make zImage
> > arm-uclinux-gcc -D__KERNEL__ -I/home/tulika/linux/include -Wall
> > -Wstrict-prototypes -O2  -fno-strict-aliasing -fno-common -pipe -g
> > -DNO_MM -mapcs-32  -mtune=arm7tdmi -mshort-load-bytes -msoft-float -g  -c
> > -o init/main.o init/main.c
> > arm-uclinux-gcc: installation problem, cannot exec `cc1': No such file or
> > directory
> > as: unrecognized option `-mapcs-32'
> > <command line>: warning: "system" re-asserted
> > make: *** [init/main.o] Error 1
> > [root at KSLINUXPC linux]# make Image
> > arm-uclinux-gcc -D__KERNEL__ -I/home/tulika/linux/include -Wall
> > -Wstrict-prototypes -O2  -fno-strict-aliasing -fno-common -pipe -g
> > -DNO_MM -mapcs-32  -mtune=arm7tdmi -mshort-load-bytes -msoft-float -g  -c
> > -o init/main.o init/main.c
> > arm-uclinux-gcc: installation problem, cannot exec `cc1': No such file or
> > directory
> > as: unrecognized option `-mapcs-32'
> > <command line>: warning: "system" re-asserted
> > make: *** [init/main.o] Error 1
> > ------------------------------------
> >
> > I believe it's something to do with toolchain configuration,
> > but not exatly sure what it is ?
> >
> > thanks
> > SELVAM
> >
> > _______________________________________________
> > uClinux-dev mailing list
> > uClinux-dev at uclinux.org
> > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> > This message was resent by uclinux-dev at uclinux.org

-- 
**********************************************
SELVAM KANNIAH
TECHNOLOGY DEVELOPMENT CENTRE
SHARP ELECTRONICS (S) PTE. LTD.
TEL: 62771623, FAX: 62713855
e-mail: selvam at sesl.global.sharp.co.jp
***********************************************



From jwilliams at itee.uq.edu.au  Tue Mar  4 02:09:40 2003
From: jwilliams at itee.uq.edu.au (John Willlams)
Date: Tue, 4 Mar 2003 17:09:40 +1000
Subject: [uClinux-dev] toolchain config ?
Message-ID: <001701c2e21d$07051de0$0307a8c0@john.qut.edu.au>

Hi Selvam

>I included the PATH for toolchain.
>"make" went a little further but stopped with almost the same error.

the error message says it's looking for cc1, so find this program on your
dev system, and try adding that directory to the path as well.

find / -name 'cc1' -print

the find command is your friend :)

(if cc1 really isn't there then you have a truly broken toolchain, try
reinstalling ).

Cheers,

john



From gerg at snapgear.com  Tue Mar  4 02:24:33 2003
From: gerg at snapgear.com (Greg Ungerer)
Date: Tue, 04 Mar 2003 17:24:33 +1000
Subject: [uClinux-dev] elf2flt porting questions
In-Reply-To: <3E643F41.3090901@lineo.com>
References: <3E643F41.3090901@lineo.com>
Message-ID: <3E6454B1.6080803@snapgear.com>

Hi Matt,

Matt Waddel wrote:
> I am trying to port the elf2flt code to a new architecure
> and I have some questions.
> 
> 1) Are uClinux relocations limited to 4 bytes by the
> operating system?

No. That is just the most common size by far.
This is very much architecture dependant.


>  The following statement emits an error
> when a 2 byte relocation is encountered, but 2 byte
> relocations are used in the blackfin processor. (R_huimm16
> and R_luimm16)  Is it ok to allow a sym_reloc_size of 2?
> 
>    /* Calculate the sym address ourselves.  */
>    sym_reloc_size = bfd_get_reloc_size(q->howto);
>    if (sym_reloc_size != 4) {
>        printf("ERROR: bad reloc size=%d for symbol=%s\n",
>                sym_reloc_size, sym_name);
>        rc = -1;
>        continue;
>        }

Ahh, I see. Looking at this I think this is a throw back
to the original m68k elf2flt. I don't think this check
should be done for all architectures...


> 2) Since there has been a some activity recently on the
> uClinux mailing list about the elf2flt conversion, how is
> the best way to determine if this is working correctly in
> a new system?  Any troubleshooting tips would be
> appreciated.

Start small :-)
I would suggest constructing some very simple test cases.
A single system call (write is a good one) for example.
You pretty much need to manually check that your relocation
is being performed as expected.

Make sure you check relocatable values inside instructions too,
if your architecture does that. The sparc support in elf2flt
and linux-2.0.x/binfmt_flat.c is an example of this.


> 3) I get errors and the build dies during the creation of
> the .gdb file.  I have commented out the .gdb file creation,
> but could this be repaired by adding the stabs sections to
> the linker script?

Hmm, I would not have thought so. What are the errors?

Regards
Greg


------------------------------------------------------------------------
Greg Ungerer  --  Chief Software Wizard        EMAIL:  gerg at snapgear.com
SnapGear Pty Ltd                               PHONE:    +61 7 3435 2888
825 Stanley St,                                  FAX:    +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia              WEB:   www.SnapGear.com



From gerg at snapgear.com  Tue Mar  4 02:26:27 2003
From: gerg at snapgear.com (Greg Ungerer)
Date: Tue, 04 Mar 2003 17:26:27 +1000
Subject: [uClinux-dev] Re: gdbserver relocation?
In-Reply-To: <buo8yvv3iig.fsf@mcspd15.ucom.lsi.nec.co.jp>
References: <buok7fqqdzi.fsf@mcspd15.ucom.lsi.nec.co.jp>	<20030224142831.GB24793@nevyn.them.org>	<20030224152608.GB2206@gnu.org> <3E5A3E20.5040706@redhat.com>	<buoheaj3ly5.fsf@mcspd15.ucom.lsi.nec.co.jp>	<20030304030318.GB31172@nevyn.them.org> <buo8yvv3iig.fsf@mcspd15.ucom.lsi.nec.co.jp>
Message-ID: <3E645523.4050001@snapgear.com>

Hi Miles,

Miles Bader wrote:
> Also, so far there's no standardization of the ptrace PT_TEXT_ADDR &c
> macros; I justed added them to the v850 implementation.  The m68knommu
> target uses hardwired numeric constants for the same functionality, but
> hopefully the maintainers will add defines so this implementation will
> work on it (gerg?  davidm?).

Sure, we can do this.

Regards
Greg


------------------------------------------------------------------------
Greg Ungerer  --  Chief Software Wizard        EMAIL:  gerg at snapgear.com
SnapGear Pty Ltd                               PHONE:    +61 7 3435 2888
825 Stanley St,                                  FAX:    +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia              WEB:   www.SnapGear.com



From chri at infis.univ.trieste.it  Tue Mar  4 02:54:59 2003
From: chri at infis.univ.trieste.it (Christian Pellegrin)
Date: Tue, 4 Mar 2003 08:54:59 +0100 (CET)
Subject: [uClinux-dev] Eb55 boot problems.
In-Reply-To: <20030303173907.5bdb3424.mathieu-rousseau@ifrance.com>
References: <20030303173907.5bdb3424.mathieu-rousseau@ifrance.com>
Message-ID: <Pine.LNX.4.53.0303040853280.13181@sole.infis.univ.trieste.it>

Hi, have a look at http://www.ascensit.com/developers/atmel_eb55/main.php3

I don't see much hope in running an useful uClinux in only 256kb ram. good
luck anyway!

Bye!



From heiko.degenhardt at sentec-elektronik.de  Tue Mar  4 03:20:09 2003
From: heiko.degenhardt at sentec-elektronik.de (Heiko Degenhardt)
Date: Tue, 4 Mar 2003 09:20:09 +0100
Subject: [uClinux-dev] Problems with beta uClinux-dist?
Message-ID: <20030304092009.C16963@www2.sentec-elektronik.de>

Hi all,

I have a problem with the current beta uClinux-dist.
I test the dist with our 5272 based board, and/or with a M5272C3
board. I just do a "make menuconfig" and leave everything at the
default values. Then I do a "make dep;make 2>&1 |tee errs".
Everything compiles fine. I can download the image.
But if I try to start it, the process stops after
"Freeing unused kernel memory: 24k freed (0xd0000 - 0xd5000)"
(there is no error message or something. It just "hangs" there).

I have the following environment:
Dist:
http://www.uclinux.org/pub/uClinux/dist/uClinux-dist-20030226.tar.gz
Toolchain:
http://www.uclinux.org/pub/uClinux/m68k-elf-tools/m68k-elf-tools-20020410.tar.gz
Host:
Debian Woody.

If I debug the start process with m68k-bdm-elf-gdb I see that it
somehow hangs in "schedule" (I didn't debug in detail, actually,
so that is just a "fist shot").

Greg told me that he can compile and run images for the M5272C3
without any problems, so I think I may have an alignment problem?
An indication for that might be the warning
"process.c:50: warning: alignment of `init_task_union' is greater
than maximum object file alignment. Using 16."
in my errs file.
So I want to ask if someone of you with an M5272C3 board could test
that dist, and see if there are any problems?
Could a wrong alignment cause such behavior?

Thanks a lot for your help.
Rgds.
Heiko.



From davidm at snapgear.com  Tue Mar  4 04:23:01 2003
From: davidm at snapgear.com (David McCullough)
Date: Tue, 4 Mar 2003 19:23:01 +1000
Subject: [uClinux-dev] UCLINUX for PALM
In-Reply-To: <000201c2e205$b337fd20$ffc5fea9@henry133>
References: <Pine.GSO.4.33.0302070159150.23746-100000@compserv1> <000201c2cfbe$943f2fa0$ffc5fea9@henry133> <20030209232255.GA28757@beast.internal.moreton.com.au> <000701c2d0aa$a7f0f780$ffc5fea9@henry133> <20030210030607.GA4753@beast.internal.moreton.com.au> <001b01c2df42$376b2700$ffc5fea9@henry133> <20030303010709.GF17327@beast.internal.moreton.com.au> <000201c2e205$b337fd20$ffc5fea9@henry133>
Message-ID: <20030304092301.GA5007@beast.internal.moreton.com.au>

Jivin HenrySimmons17 lays it down ...
> Hello Davidm...
> > Jivin HenrySimmons17 lays it down ...
> > > Hello David
> > > I finally got the prompt />
> > > The problem was the console kept defaulting to ttyS0 and I was
> > >  not using a serial console. I was using the console on the
> > >  Palm m500 (CONFIG_PILOT_CONSOLE). When I added
> > > the statement  : tty0:linux:/bin/sh
> > > into the file: PalmIIIx/inittab
> > > it worked. I then removed the statement from PalmIIIx/inittab
> > > & modified the Makefile in vendors/3com/PalmIIIx as follows:
> > > case "$(LINUXDIR)" in \
> > >  *2.0.*) ;; \
> > >  *) echo "tty0:linux:/bin/sh" >> $(ROMFSDIR)/etc/inittab ;; \
> > >  esac
> > > and it worked. This change also can be merge into the distro.
> >
> > I usually run my IIIx without the fancy console this the current setup :-)
> How do you do this?

Serial console on ttyS0.  I load the image down at 57600,  switch to
9600 and then run PalmLoader to boot uClinux.

> > What would be good is if you could make a vendors/3com/m500 directory that
> > does exactly what you want and send it to me and I will add it in
> untouched.
> > Just copy the PalmIIIx directory with your mods.
> OK will do.

Thanks,

> > What would also be good is if we can make the changes needed to
> PalmLoader.c
> > work on all platforms.  Perhaps read the XX register first,  add some
> > bits then write it ?
> OK will do.

I don't know if it's possible so don't beat your head on it ;-)

Cheers,
Davidm

-- 
David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
davidm at snapgear.com  Fx: +61 7 3891 3630  Custom Embedded Solutions + Security


From fgiovag at tin.it  Tue Mar  4 04:18:36 2003
From: fgiovag at tin.it (Fabio Giovagnini)
Date: Tue, 4 Mar 2003 10:18:36 +0100
Subject: [uClinux-dev] structure size ????
In-Reply-To: <BA88C21E.8CC0%tchen@on-go.com>
References: <BA88C21E.8CC0%tchen@on-go.com>
Message-ID: <200303041018.36653.fgiovag@tin.it>

Yes, __attribute__((aligned(2))) (check the sintax)

Regards

Alle 17:26, luned? 3 marzo 2003, Thomas Chen ha scritto:
> a lot of interesting discussion on this... but my original question
> was: is there any way to tell compiler (for arm7tdmi) to align
> on 16 bit boundry instead of 32 ???
>
> thanks
>
> on 3/3/03 4:46 AM, Erwin Authried at eauth at softsys.co.at wrote:
> > Am Mon, 2003-03-03 um 12.12 schrieb Fabio Giovagnini:
> >> According my knowledge there are two aspects:
> >> 1) the alignment capability of yuor microprocessor. You should know if
> >> you can
> >> align a word to an odd address or if you can align a long word to an
> >> address that isn't multiple of 4. On my microcprocessor (hitachi
> >> h8300h,h8s, sh2,sh3) this is not possible so you cannot align:
> >> struct _uuu {
> >> usigned long a1;
> >> unsigned char a2;
> >> unsigned short a3;
> >> } uuu;
> >> because a3c in on an odd address and for my micro it is not allowed;
> >
> > If you use the packed attribute, it is the compilers task to take care
> > about acess on unaligned adresses. The compiler will generate the
> > necessary byte access and shift instructions. I don't know about the
> > hitachi, but if there is code generated that makes a 16-bit access on an
> > odd address, then it's probably either a gcc bug or some architecture
> > specific option thats missing. At least for the ARM7TDMI, it works fine
> > with gcc-2.95.3.
> >
> > Regards,
> > Erwin
> >
> >
> > _______________________________________________
> > uClinux-dev mailing list
> > uClinux-dev at uclinux.org
> > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> > This message was resent by uclinux-dev at uclinux.org
>
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org



From bluetoothloo at lycos.com  Tue Mar  4 04:19:57 2003
From: bluetoothloo at lycos.com (Murat Loo)
Date: Tue, 04 Mar 2003 11:19:57 +0200
Subject: [uClinux-dev] Boot from Rom Patch + Memory problems
Message-ID: <EABOBLECAEMELDAA@mailcity.com>

Hi,

I've patched uClinux with the boot from rom patch. However when I've compiled the kernel I've get the following error:
m68k-elf-objcopy -O binary /uClinux-dist/linux-2.4.x/linux \
  /uClinux-dist/images/linux.bin
BFD: Warning: Writing section `.text' to huge (ie negative) file offset 0xffe200
00.
m68k-elf-objcopy: /uClinux-dist/images/linux.bin: File truncated

What is going wrong here?

Another problem is with the memory alloction. For example lets say that I've run a simple program (no memory leaks in the program i.e a hello world program) that takes 30KB memory. when the program terminates it is expected to return the 30KB memory back. However only a small amount of memory or nothing is returned. The allocated memory is never freed so the system runs out of memory quickly and kernel panics. How can we expilictly call the garbage collector? Or what can we do so that the memory is returned correctly?


_____________________________________________________________
Get 25MB, POP3, Spam Filtering with LYCOS MAIL PLUS for $19.95/year.
http://login.mail.lycos.com/brandPage.shtml?pageId=plus&ref=lmtplus


From Amit.Lubovsky at infineon.com  Tue Mar  4 04:29:11 2003
From: Amit.Lubovsky at infineon.com (Amit.Lubovsky at infineon.com)
Date: Tue, 4 Mar 2003 10:29:11 +0100 
Subject: [uClinux-dev] AMD - Am29LV160B
Message-ID: <04C8EDC5AE3FD611ABE40002B39CF69B07F2DF@ntah901e.savan.com>


 Thanks,
I have applied BUSWIDTH 4 in the mapping driver and my

	Memory Technology Devices (MTD)  ---> RAM/ROM/Flash chip drivers

looks like:

    	 [*]   Common Flash Interface (CFI) support                       x
x   
  x x    [ ]   CFI Virtual erase regions (EXPERIMENTAL)                   x
x   
  x x    [*]   CFI Advanced configuration options                         x
x   
  x x    (BIG_ENDIAN_BYTE) Flash cmd/query data swapping                  x
x   
  x x    [*]   Specific CFI Flash geometry selection                      x
x   
  x x    [ ]     Support  8-bit buswidth                                  x
x   
  x x    [ ]     Support 16-bit buswidth                                  x
x   
  x x    [*]     Support 32-bit buswidth                                  x
x   
  x x    [ ]     Support 1-chip flash interleave                          x
x   
  x x    [*]     Support 2-chip flash interleave                          x
x   
  x x    [ ]     Support 4-chip flash interleave                          x
x   
  x x    [ ]     CFI support for Intel/Sharp Basic/Extended Commands      x
x   
  x x    [*]     CFI support for AMD/Fujitsu Standard Commands            x
x   
  x x    [ ]   AMD compatible flash chip support (non-CFI)                x
x   
  x x    [ ]   pre-CFI Sharp chip support                                 x
x   
  x x    [ ]   Support for RAM chips in bus mapping                       x
x   
  x x    [ ]   Support for ROM chips in bus mapping                       x
x   
  
I have allso tried the no swap, but still get :
	"Physically mapped flash: Found no CFI device at location zero"

( I run in big endian mode),

attached is the mapping driver I use.

Any other ideas?
Thanks,
Amit.



-----Original Message-----
From: Bernhard Kuhn
To: uclinux-dev at uclinux.org
Sent: 3/3/2003 11:44 PM
Subject: Re: [uClinux-dev] AMD - Am29LV160B

Amit.Lubovsky at infineon.com wrote:

> 2 x16 bit devices in parallel (32 bit access) at address 0,

In this case, i guess you need to apply BUSWIDTH 4 in the
mapping driver and then

   Memory Technology Devices (MTD)  ---> RAM/ROM/Flash chip drivers

should look like this:

   ? ?    [*]   Common Flash Interface (CFI) support
   ? ?    [ ]   CFI Virtual erase regions (EXPERIMENTAL) (NEW)
   ? ?    [*]   CFI Advanced configuration options (NEW)
   ? ?    (NO) Flash cmd/query data swapping
   ? ?    [*]   Specific CFI Flash geometry selection (NEW)
   ? ?    [ ]     Support  8-bit buswidth (NEW)
   ? ?    [ ]     Support 16-bit buswidth (NEW)
   ? ?    [*]     Support 32-bit buswidth (NEW)
   ? ?    [ ]     Support 1-chip flash interleave (NEW)
   ? ?    [*]     Support 2-chip flash interleave (NEW)
   ? ?    [ ]     Support 4-chip flash interleave (NEW)
   ? ?    [ ]     CFI support for Intel/Sharp Basic/Extended Commands
   ? ?    [*]     CFI support for AMD/Fujitsu Standard Commands

And maybe you need to change "Flash cmd/query data swapping"
because auf endianess issues.

hope that helps ...

Bernhard

_______________________________________________
uClinux-dev mailing list
uClinux-dev at uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev at uclinux.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: purple.c
Type: application/octet-stream
Size: 3241 bytes
Desc: not available
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20030304/68ced0c3/attachment.obj>

From davidm at snapgear.com  Tue Mar  4 05:11:36 2003
From: davidm at snapgear.com (David McCullough)
Date: Tue, 4 Mar 2003 20:11:36 +1000
Subject: [uClinux-dev] Problems with beta uClinux-dist?
In-Reply-To: <20030304092009.C16963@www2.sentec-elektronik.de>
References: <20030304092009.C16963@www2.sentec-elektronik.de>
Message-ID: <20030304101136.GA5048@beast.internal.moreton.com.au>

Jivin Heiko Degenhardt lays it down ...
> Hi all,
> 
> I have a problem with the current beta uClinux-dist.
> I test the dist with our 5272 based board, and/or with a M5272C3
> board. I just do a "make menuconfig" and leave everything at the
> default values. Then I do a "make dep;make 2>&1 |tee errs".
> Everything compiles fine. I can download the image.
> But if I try to start it, the process stops after
> "Freeing unused kernel memory: 24k freed (0xd0000 - 0xd5000)"
> (there is no error message or something. It just "hangs" there).
> 
> I have the following environment:
> Dist:
> http://www.uclinux.org/pub/uClinux/dist/uClinux-dist-20030226.tar.gz
> Toolchain:
> http://www.uclinux.org/pub/uClinux/m68k-elf-tools/m68k-elf-tools-20020410.tar.gz
> Host:
> Debian Woody.
> 
> If I debug the start process with m68k-bdm-elf-gdb I see that it
> somehow hangs in "schedule" (I didn't debug in detail, actually,
> so that is just a "fist shot").

This is right where is runs init.  Turn on DEBUG in
linux-2.4.x/fs/binfmt_flat.c so you can see when it runs
various programs.

You should check that the init/console support is turned on in the user
config.

> Greg told me that he can compile and run images for the M5272C3
> without any problems, so I think I may have an alignment problem?

Unlikely,  but possible.  DEBUG in the flat loader will help to work out
what is failing.  Greg tests and runs on all the Mot boards so I would
be confident that it runs on his board ;-)

> An indication for that might be the warning
> "process.c:50: warning: alignment of `init_task_union' is greater
> than maximum object file alignment. Using 16."
> in my errs file.

This is normal and happens on all m68k builds to my knowledge.

> So I want to ask if someone of you with an M5272C3 board could test
> that dist, and see if there are any problems?
> Could a wrong alignment cause such behavior?

Check the console setting and get back to us with the DEBUG from the
flat loader and we'll see what we can find :-)

Cheers,
Davidm

-- 
David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
davidm at snapgear.com  Fx: +61 7 3891 3630  Custom Embedded Solutions + Security


From manigandanv at myw.ltindia.com  Tue Mar  4 05:41:34 2003
From: manigandanv at myw.ltindia.com (Manigandan.V)
Date: Tue, 4 Mar 2003 16:11:34 +0530
Subject: [uClinux-dev] Boot from Rom Patch + Memory problems
References: <EABOBLECAEMELDAA@mailcity.com>
Message-ID: <002d01c2e23a$a04bd4e0$1e06a8c0@emsysdom>

I guess that your rom.ld is having problem .Can you post your rom.ld

> I've patched uClinux with the boot from rom patch. However when I've
compiled the kernel I've get the following error:
> m68k-elf-objcopy -O binary /uClinux-dist/linux-2.4.x/linux \
>   /uClinux-dist/images/linux.bin
> BFD: Warning: Writing section `.text' to huge (ie negative) file offset
0xffe200
> 00.
> m68k-elf-objcopy: /uClinux-dist/images/linux.bin: File truncated
>
> What is going wrong here?

Regards,
Mani




From bkuhn at metrowerks.com  Tue Mar  4 06:40:08 2003
From: bkuhn at metrowerks.com (Bernhard Kuhn)
Date: Tue, 04 Mar 2003 12:40:08 +0100
Subject: [uClinux-dev] AMD - Am29LV160B
References: <04C8EDC5AE3FD611ABE40002B39CF69B07F2DF@ntah901e.savan.com>
Message-ID: <3E649098.1060601@metrowerks.com>

Amit.Lubovsky at infineon.com wrote:

>   x x    (BIG_ENDIAN_BYTE) Flash cmd/query data swapping                  x

Maybe you need to try other variants, as well, i.e. little
endian: you never know from which side they are looking
at it :-)

If this doesn't work, then you need to go deeper
into the cfi driver probe code. Another option
would be that i send you a preliminary patch
of the new kernel. Maybe things works better,
there ...

Bernhard





From mathieu-rousseau at ifrance.com  Tue Mar  4 08:02:26 2003
From: mathieu-rousseau at ifrance.com (Mathieu Rousseau)
Date: Tue, 4 Mar 2003 14:02:26 +0100
Subject: [uClinux-dev] Eb55 boot problems.
In-Reply-To: <Pine.LNX.4.53.0303040853280.13181@sole.infis.univ.trieste.it>
References: <20030303173907.5bdb3424.mathieu-rousseau@ifrance.com>
	<Pine.LNX.4.53.0303040853280.13181@sole.infis.univ.trieste.it>
Message-ID: <20030304140226.21a94b02.mathieu-rousseau@ifrance.com>

Hi thanks

I already saw this, not very very much information. but anyway, i want to run uClinux from from, theorically it's possible, right? But at boot will it recopy completly in RAM? if yes, sure i can't run uClinux, but if execution is from the flash, i think it's possible.

what do you think?

thanks

Mathieu Rousseau


On Tue, 4 Mar 2003 08:54:59 +0100 (CET)
Christian Pellegrin <chri at infis.univ.trieste.it> wrote:

> 
> Hi, have a look at http://www.ascensit.com/developers/atmel_eb55/main.php3
> 
> I don't see much hope in running an useful uClinux in only 256kb ram. good
> luck anyway!
> 
> Bye!
> 
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org
> _____________________________________________________________________
> GRAND JEU SMS : Pour gagner un NOKIA 7650, envoyez le mot IF au 61321
> (prix d'un SMS + 0.35 euro). Un SMS vous dira si vous avez gagn_.
> R_glement : http://www.ifrance.com/_reloc/sign.sms
_____________________________________________________________________
Envie de discuter en "live" avec vos amis ? T?l?charger MSN Messenger
http://www.ifrance.com/_reloc/m la 1?re messagerie instantan?e de France



From davidm at snapgear.com  Tue Mar  4 07:29:30 2003
From: davidm at snapgear.com (David McCullough)
Date: Tue, 4 Mar 2003 22:29:30 +1000
Subject: [uClinux-dev] uClinux-dist-20030226.tar.gz : user_only errors (other)
In-Reply-To: <20030304030103.191f0863.mathieu-rousseau@ifrance.com>
References: <20030304030103.191f0863.mathieu-rousseau@ifrance.com>
Message-ID: <20030304122930.GA1243@beast.internal.moreton.com.au>


Jivin Mathieu Rousseau lays it down ...
> Hi
> 
> I try to compile it but it fails. I applied the pacth that David McCullough sent today about missing stuff.
> 
> make menuconfig
> Atmel/AT91
> linux-2.0.x
> uC-libc
> change settings for my card:
> add M55800 card support (eb55 with 256KB ram, 1MB user flash)
> base address for DRAM: 0x02000000
> amount of DRAM: 00040000
> Base address for flash: 0x01000000
> amount of flash: 00100000
> EBI: y  (hum... i don't know if i must check this on but seems to be the way to initialize address. someone can tell me if i'm wrong or not).
> boot from flash: y
> 
> i let the other stuff as configured.
> 
> make lib_only: ok
> 
> make user_only fails, error message below.
> 
> Can you help me.

Here is another patch to fix up the optimisations so taht inlines work,

Cheers,
Davidm

-- 
David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
davidm at snapgear.com  Fx: +61 7 3891 3630  Custom Embedded Solutions + Security
-------------- next part --------------
Index: vendors/config/armnommu/config.arch
===================================================================
RCS file: /cvs/sw/new-wave/vendors/config/armnommu/config.arch,v
retrieving revision 1.2
diff -u -r1.2 config.arch
--- vendors/config/armnommu/config.arch	3 Mar 2003 23:23:57 -0000	1.2
+++ vendors/config/armnommu/config.arch	4 Mar 2003 12:18:16 -0000
@@ -152,9 +152,9 @@
 	INCCRYPTOLD = -I$(ROOTDIR)/lib/libcrypt_old
 
   ifdef CONFIG_USER_DEBUG
-	CFLAGS  :=  $($(UOPT),$(UOPT),-O1) -g
+	CFLAGS  :=  $(if $(UOPT),$(UOPT),-O1) -g
   else
-	CFLAGS  :=  $($(UOPT),$(UOPT),-O2) -g -fomit-frame-pointer
+	CFLAGS  :=  $(if $(UOPT),$(UOPT),-O2) -g -fomit-frame-pointer
   endif
 
 	CFLAGS  += $(CPUFLAGS)

From chri at infis.univ.trieste.it  Tue Mar  4 08:20:57 2003
From: chri at infis.univ.trieste.it (Christian Pellegrin)
Date: Tue, 4 Mar 2003 14:20:57 +0100 (CET)
Subject: [uClinux-dev] Eb55 boot problems.
In-Reply-To: <20030304140226.21a94b02.mathieu-rousseau@ifrance.com>
References: <20030303173907.5bdb3424.mathieu-rousseau@ifrance.com>
 <Pine.LNX.4.53.0303040853280.13181@sole.infis.univ.trieste.it>
 <20030304140226.21a94b02.mathieu-rousseau@ifrance.com>
Message-ID: <Pine.LNX.4.53.0303041408540.16780@sole.infis.univ.trieste.it>


On Tue, 4 Mar 2003, Mathieu Rousseau wrote:

> Hi thanks
> 
> I already saw this, not very very much information. but anyway, i want to run uClinux from from, theorically it's possible, right? But at boot will it recopy completly in RAM? if yes, sure i can't run uClinux, but if execution is from the flash, i think it's possible.
> 
> what do you think?
> 

Well you can take a 2.0 kernel and have a look at how much stuff has to be
in ram (take the difference _end - _etext in System.map). Then you need to
account for the heap memory for the kernel and there must be something
left for user space applications ..... there won't be much memory left I
guess.  Linux is wonderful but for very low footprint I would prefer eCos
(I run it with great satisfaction (with lwIP for TCP/IP) on an eb40a with
only 256kb internal SRAM).

Bye!


From eauth at softsys.co.at  Tue Mar  4 08:40:09 2003
From: eauth at softsys.co.at (Erwin Authried)
Date: 04 Mar 2003 14:40:09 +0100
Subject: [uClinux-dev] Eb55 boot problems.
In-Reply-To: <20030304140226.21a94b02.mathieu-rousseau@ifrance.com>
References: <20030303173907.5bdb3424.mathieu-rousseau@ifrance.com>
	<Pine.LNX.4.53.0303040853280.13181@sole.infis.univ.trieste.it> 
	<20030304140226.21a94b02.mathieu-rousseau@ifrance.com>
Message-ID: <1046785209.14806.138.camel@justakiss>

To run uClinux from flash, you will need a link script. The 2.0 kernel
from cvs.uclinux.org doesn't have one, I think. I have done that for the
EB01 and the EB63 quite a long time ago, have a look at 
cvs.home.at/kernel/include/asm-armnommu/arch-eb01/rom.ld to see how its
done. Be aware that the kernel source there is not maintained anymore
for quite a long time since I have moved to 2.4.

Regards,
Erwin

Am Die, 2003-03-04 um 14.02 schrieb Mathieu Rousseau:
> Hi thanks
> 
> I already saw this, not very very much information. but anyway, i want to run uClinux from from, theorically it's possible, right? But at boot will it recopy completly in RAM? if yes, sure i can't run uClinux, but if execution is from the flash, i think it's possible.
> 
> what do you think?
> 
> thanks
> 
> Mathieu Rousseau
> 
> 
> On Tue, 4 Mar 2003 08:54:59 +0100 (CET)
> Christian Pellegrin <chri at infis.univ.trieste.it> wrote:
> 
> > 
> > Hi, have a look at http://www.ascensit.com/developers/atmel_eb55/main.php3
> > 
> > I don't see much hope in running an useful uClinux in only 256kb ram. good
> > luck anyway!
> > 
> > Bye!
> > 
> > _______________________________________________
> > uClinux-dev mailing list
> > uClinux-dev at uclinux.org
> > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> > This message was resent by uclinux-dev at uclinux.org
> > _____________________________________________________________________
> > GRAND JEU SMS : Pour gagner un NOKIA 7650, envoyez le mot IF au 61321
> > (prix d'un SMS + 0.35 euro). Un SMS vous dira si vous avez gagn_.
> > R_glement : http://www.ifrance.com/_reloc/sign.sms
> _____________________________________________________________________
> Envie de discuter en "live" avec vos amis ? T?l?charger MSN Messenger
> http://www.ifrance.com/_reloc/m la 1?re messagerie instantan?e de France
> 
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org
> 




From mathieu-rousseau at ifrance.com  Tue Mar  4 09:47:47 2003
From: mathieu-rousseau at ifrance.com (Mathieu Rousseau)
Date: Tue, 4 Mar 2003 15:47:47 +0100
Subject: [uClinux-dev] Eb55 boot problems.
In-Reply-To: <Pine.LNX.4.53.0303041408540.16780@sole.infis.univ.trieste.it>
References: <20030303173907.5bdb3424.mathieu-rousseau@ifrance.com>
	<Pine.LNX.4.53.0303040853280.13181@sole.infis.univ.trieste.it>
	<20030304140226.21a94b02.mathieu-rousseau@ifrance.com>
	<Pine.LNX.4.53.0303041408540.16780@sole.infis.univ.trieste.it>
Message-ID: <20030304154747.1524d0db.mathieu-rousseau@ifrance.com>

ok, so i cannot just make uClinux run from flash, it needs SRAM...
it needs some stuff to be in ram...

and another question... I have my image.bin, i just put it in flash and it should work right?

thanks

Mathieu Rousseau


On Tue, 4 Mar 2003 14:20:57 +0100 (CET)
Christian Pellegrin <chri at infis.univ.trieste.it> wrote:

> 
> 
> On Tue, 4 Mar 2003, Mathieu Rousseau wrote:
> 
> > Hi thanks
> > 
> > I already saw this, not very very much information. but anyway, i want to run uClinux from from, theorically it's possible, right? But at boot will it recopy completly in RAM? if yes, sure i can't run uClinux, but if execution is from the flash, i think it's possible.
> > 
> > what do you think?
> > 
> 
> Well you can take a 2.0 kernel and have a look at how much stuff has to be
> in ram (take the difference _end - _etext in System.map). Then you need to
> account for the heap memory for the kernel and there must be something
> left for user space applications ..... there won't be much memory left I
> guess.  Linux is wonderful but for very low footprint I would prefer eCos
> (I run it with great satisfaction (with lwIP for TCP/IP) on an eb40a with
> only 256kb internal SRAM).
> 
> Bye!
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org
> _____________________________________________________________________
> Envie de discuter en "live" avec vos amis ? T_l_charger MSN Messenger
> http://www.ifrance.com/_reloc/m la 1_re messagerie instantan_e de France
_____________________________________________________________________
GRAND JEU SMS : Pour gagner un NOKIA 7650, envoyez le mot IF au 61321
(prix d'un SMS + 0.35 euro). Un SMS vous dira si vous avez gagn?.
R?glement : http://www.ifrance.com/_reloc/sign.sms



From jonny at 1409.org  Tue Mar  4 09:09:14 2003
From: jonny at 1409.org (Johann Hanne)
Date: Tue, 4 Mar 2003 15:09:14 +0100 (CET)
Subject: [uClinux-dev] Samsung S3C4510B JTAG tools?
In-Reply-To: <Pine.LNX.4.44.0212221905100.12210-100000@dh3mb.ampr.org>
Message-ID: <Pine.LNX.4.44.0303041449310.2393-100000@dh3mb.ampr.org>

Hi all,

I've asked for help with putting uClinux on a s3c4510b based DSL router 
some time ago. The good news is that I have an working JTAG connection 
now, i.e. I can write a meg or so to 0x8000 and then read it back without 
any errors. I've used the arm-boot package from
http://kabel.home.at:5880/cgi-bin/viewcvs.cgi/arm-boot/
and the JTAG interface circuit from
http://jtag-arm9.sourceforge.net/circuit.txt

The bad news is that I still can't boot uClinux as I still don't have any 
possibility to write to the flash via JTAG. Maybe it's better to start 
it from RAM first and trying the flash thing later. So I have some 
questions as I need to get the s3c4510b into some defined state (as 
I expected, writing the ram-image to 0x8000 and sending an execution 
instruction for that address doesn't work):
- Is there a clean way to "stop" the s3c4510b from executing anything?
  (if I start an JTAG write operation it seems to stop anyway, but I've
  no idea if that leaves the cpu in a sane state)
- How can I map the RAM (4 MB) to 0x0 and the flash (1 MB) to 0x1000000?
  (my idea is to write the image to the upper 2 MB of the RAM and then
  start it with the rom=0x... kernel parameter)
- How can I initialize the board to a state uClinux will successfully
  boot from?

Thanks in advance for any hints...

Cheers, Jonny <jonny at 1409.org>



From mathieu-rousseau at ifrance.com  Tue Mar  4 09:54:01 2003
From: mathieu-rousseau at ifrance.com (Mathieu Rousseau)
Date: Tue, 4 Mar 2003 15:54:01 +0100
Subject: [uClinux-dev] Eb55 boot problems.
In-Reply-To: <1046785209.14806.138.camel@justakiss>
References: <20030303173907.5bdb3424.mathieu-rousseau@ifrance.com>
	<Pine.LNX.4.53.0303040853280.13181@sole.infis.univ.trieste.it>
	<20030304140226.21a94b02.mathieu-rousseau@ifrance.com>
	<1046785209.14806.138.camel@justakiss>
Message-ID: <20030304155401.16ee04c0.mathieu-rousseau@ifrance.com>

Thanks, i'll take a look at this.

Is my eb55 board supported by kernel 2.4 ?
I did not find any options to specify it while configuring it.

Thanks

Mathieu Rousseau


On 04 Mar 2003 14:40:09 +0100
Erwin Authried <eauth at softsys.co.at> wrote:

> To run uClinux from flash, you will need a link script. The 2.0 kernel
> from cvs.uclinux.org doesn't have one, I think. I have done that for the
> EB01 and the EB63 quite a long time ago, have a look at 
> cvs.home.at/kernel/include/asm-armnommu/arch-eb01/rom.ld to see how its
> done. Be aware that the kernel source there is not maintained anymore
> for quite a long time since I have moved to 2.4.
> 
> Regards,
> Erwin
> 
> Am Die, 2003-03-04 um 14.02 schrieb Mathieu Rousseau:
> > Hi thanks
> > 
> > I already saw this, not very very much information. but anyway, i want to run uClinux from from, theorically it's possible, right? But at boot will it recopy completly in RAM? if yes, sure i can't run uClinux, but if execution is from the flash, i think it's possible.
> > 
> > what do you think?
> > 
> > thanks
> > 
> > Mathieu Rousseau
> > 
> > 
> > On Tue, 4 Mar 2003 08:54:59 +0100 (CET)
> > Christian Pellegrin <chri at infis.univ.trieste.it> wrote:
> > 
> > > 
> > > Hi, have a look at http://www.ascensit.com/developers/atmel_eb55/main.php3
> > > 
> > > I don't see much hope in running an useful uClinux in only 256kb ram. good
> > > luck anyway!
> > > 
> > > Bye!
> > > 
> > > _______________________________________________
> > > uClinux-dev mailing list
> > > uClinux-dev at uclinux.org
> > > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> > > This message was resent by uclinux-dev at uclinux.org
> > > _____________________________________________________________________
> > > GRAND JEU SMS : Pour gagner un NOKIA 7650, envoyez le mot IF au 61321
> > > (prix d'un SMS + 0.35 euro). Un SMS vous dira si vous avez gagn_.
> > > R_glement : http://www.ifrance.com/_reloc/sign.sms
> > _____________________________________________________________________
> > Envie de discuter en "live" avec vos amis ? T?l?charger MSN Messenger
> > http://www.ifrance.com/_reloc/m la 1?re messagerie instantan?e de France
> > 
> > _______________________________________________
> > uClinux-dev mailing list
> > uClinux-dev at uclinux.org
> > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> > This message was resent by uclinux-dev at uclinux.org
> > 
> 
> 
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org
> _____________________________________________________________________
> GRAND JEU SMS : Pour gagner un NOKIA 7650, envoyez le mot IF au 61321
> (prix d'un SMS + 0.35 euro). Un SMS vous dira si vous avez gagn?.
> R?glement : http://www.ifrance.com/_reloc/sign.sms
_____________________________________________________________________
Envie de discuter en "live" avec vos amis ? T?l?charger MSN Messenger
http://www.ifrance.com/_reloc/m la 1?re messagerie instantan?e de France



From bkc at murkworks.com  Tue Mar  4 09:20:57 2003
From: bkc at murkworks.com (Brad Clements)
Date: Tue, 04 Mar 2003 09:20:57 -0500
Subject: [uClinux-dev] uClinux Training Workshop Ottawa March 25-28th.
In-Reply-To: <3E638A36.BECFF2B2@earthlink.net>
Message-ID: <3E646CE0.20514.8E8D087B@localhost>

What is the cost of attendence at the workshop?

What time will you start and end each day? I'm within commute distance of Ottawa.



-- 
Brad Clements,                bkc at murkworks.com   (315)268-1000
http://www.murkworks.com                          (315)268-9812 Fax
http://www.wecanstopspam.org/                   AOL-IM: BKClements



From jeff at ArcturusNetworks.com  Tue Mar  4 09:13:34 2003
From: jeff at ArcturusNetworks.com (D. Jeff Dionne)
Date: Tue, 4 Mar 2003 09:13:34 -0500
Subject: [uClinux-dev] elf2flt porting questions
In-Reply-To: <3E6454B1.6080803@snapgear.com>
Message-ID: <7BFBCAAC-4E4B-11D7-ABBE-000A27E368C4@ArcturusNetworks.com>

On Tuesday, March 4, 2003, at 02:24 AM, Greg Ungerer wrote:

> Hi Matt,
>
> Matt Waddel wrote:
>> I am trying to port the elf2flt code to a new architecure
>> and I have some questions.
>> 1) Are uClinux relocations limited to 4 bytes by the
>> operating system?
>
> No. That is just the most common size by far.
> This is very much architecture dependant.

There is likely a difference between the size BFD uses to
store the relocation in it's data structures and the size of
the relocation itself.  For instance, on SPARC there are
relocations which are 30 bits (you can't have an instruction
on anything but a long boundary anyway, so...).  But BFD
has to use 4 bytes for them so this test passes.

>>  The following statement emits an error
>> when a 2 byte relocation is encountered, but 2 byte
>> relocations are used in the blackfin processor. (R_huimm16
>> and R_luimm16)  Is it ok to allow a sym_reloc_size of 2?
>>    /* Calculate the sym address ourselves.  */
>>    sym_reloc_size = bfd_get_reloc_size(q->howto);
>>    if (sym_reloc_size != 4) {
>>        printf("ERROR: bad reloc size=%d for symbol=%s\n",
>>                sym_reloc_size, sym_name);
>>        rc = -1;
>>        continue;
>>        }
>
> Ahh, I see. Looking at this I think this is a throw back
> to the original m68k elf2flt. I don't think this check
> should be done for all architectures...

Could be even before that, back to obj-res for the Palm Pilot,
but who knows.  I can't see any need for this really because the
type is checked per architecture since you need multiple strategies
for (many of) the types of reloc emitted.  Watch out for relocations
split across multiple instructions... gcc has a habit of reordering them
in the instruction stream and it can be a pain.  If you have 16 bit
relocations, you may have a simmilar problem on BlackFIN (with
the other half of the reloc'd address), otherwise it might be a
relative offset.  In any case, a 16 bit offset will require you to come
up with a strategy to deal with it which is different than anything
that is there I would think.  Note that elf2flt and binfmt_flat in the
kernel are very interdepandant, you need to work on both at the
same time.

>> 2) Since there has been a some activity recently on the
>> uClinux mailing list about the elf2flt conversion, how is
>> the best way to determine if this is working correctly in
>> a new system?  Any troubleshooting tips would be
>> appreciated.
>
> Start small :-)
> I would suggest constructing some very simple test cases.
> A single system call (write is a good one) for example.
> You pretty much need to manually check that your relocation
> is being performed as expected.

Yes, in every possible case.  There can be more too, if your gcc
emits instructions which make an assumption that can't be relocated.
Generally speaking, this is more (or perhaps only) a problem when
trying to use XIP instead of load time relocations.

> Make sure you check relocatable values inside instructions too,
> if your architecture does that. The sparc support in elf2flt
> and linux-2.0.x/binfmt_flat.c is an example of this.

It's a RISCy thing ;^)  Ugly, really.  Gotta love those 32 bit
fixed length instructions with 22bit/10bit split relocs...

>> 3) I get errors and the build dies during the creation of
>> the .gdb file.  I have commented out the .gdb file creation,
>> but could this be repaired by adding the stabs sections to
>> the linker script?
>
> Hmm, I would not have thought so. What are the errors?

Make sure you understand how the multiple passes through
ld are used, or it will be impossible to calculate the right relocation
values!  A fully relocatable link (ld -r) throws away information,
for instance.

Cheers,
J.

> Regards
> Greg
>
>
> ----------------------------------------------------------------------- 
> -
> Greg Ungerer  --  Chief Software Wizard        EMAIL:   
> gerg at snapgear.com
> SnapGear Pty Ltd                               PHONE:    +61 7 3435  
> 2888
> 825 Stanley St,                                  FAX:    +61 7 3891  
> 3630
> Woolloongabba, QLD, 4102, Australia              WEB:    
> www.SnapGear.com
>
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org



From chri at infis.univ.trieste.it  Tue Mar  4 09:39:34 2003
From: chri at infis.univ.trieste.it (Christian Pellegrin)
Date: Tue, 4 Mar 2003 15:39:34 +0100 (CET)
Subject: [uClinux-dev] Eb55 boot problems.
In-Reply-To: <20030304154747.1524d0db.mathieu-rousseau@ifrance.com>
References: <20030303173907.5bdb3424.mathieu-rousseau@ifrance.com>
 <Pine.LNX.4.53.0303040853280.13181@sole.infis.univ.trieste.it>
 <20030304140226.21a94b02.mathieu-rousseau@ifrance.com>
 <Pine.LNX.4.53.0303041408540.16780@sole.infis.univ.trieste.it>
 <20030304154747.1524d0db.mathieu-rousseau@ifrance.com>
Message-ID: <Pine.LNX.4.53.0303041530480.16780@sole.infis.univ.trieste.it>


On Tue, 4 Mar 2003, Mathieu Rousseau wrote:

> ok, so i cannot just make uClinux run from flash, it needs SRAM...
> it needs some stuff to be in ram...

the text segment can be in flash, data, bss and kernel heap no. more or 
less the same for user application (if you are using XIP but AFAIK it's 
only in uclinux 2.4 (but I may be wrong) which i really bigger).

> 
> and another question... I have my image.bin, i just put it in flash and it should work right?
> 

well the bootloader should copy the data segment to ram, zero bss and 
setup the memory map known to Linux. Have a look at head-arm-atmel.S if 
this is supported or if the whole kernel needs to be in ram. 

Bye!


From bluetoothloo at lycos.com  Tue Mar  4 09:58:29 2003
From: bluetoothloo at lycos.com (Murat Loo)
Date: Tue, 04 Mar 2003 16:58:29 +0200
Subject: [uClinux-dev] Boot from Rom Patch + Memory problems
Message-ID: <APIMNIBDCGHMOBAA@mailcity.com>

Here is the rom.ld

Thanks.

MEMORY {
	rom    : ORIGIN = 0xffe40000, LENGTH = 0x1c0000
	ram    : ORIGIN = 0x20000, LENGTH = 0x3e0000
}

SECTIONS {

	.text : {
		_stext = . ;
	        	*(.text)
		. = ALIGN(0x4) ;
			*(.text.*)
		. = ALIGN(0x4) ;
			*(.exitcall.exit)
		. = ALIGN(0x4) ;
			*(.kstrtab)

		. = ALIGN(16);          /* Exception table              */
		__start___ex_table = . ;
			*(__ex_table)
		__stop___ex_table = . ;

		__start___ksymtab = . ;  /* Kernel symbol table          */
			*(__ksymtab)
		__stop___ksymtab = . ;

		. = ALIGN(0x4);
		_etext = . ;
		__data_rom_start = . ;
	} > rom

	.data : {
		_sdata = ALIGN(0x4) ;
		__data_start = . ;

		. = ALIGN(0x4) ;
			*(.rodata)
		. = ALIGN(0x4) ;
        		*(.data)
		. = ALIGN(0x4) ;
			*(.data.*)

		. = ALIGN(0x4);
		__setup_start = . ;
			*(.setup.init)
		__setup_end = . ;

		. = ALIGN(0x4);
		__initcall_start = .;
			*(.initcall.init)
		__initcall_end = . ;

		. = ALIGN(0x2000) ;
        		*(.data.init_task)
		. = ALIGN(0x2000) ;

		_edata = ALIGN(0x4) ;
	} > ram

	.bss : {
		_sbss = ALIGN(0x4) ;
			*(.bss)
		. = ALIGN(0x4) ;
			*(COMMON)
		_ebss = ALIGN(0x4) ;
		_end = ALIGN(0x4) ;
	} > ram
}


 
--

On Tue, 4 Mar 2003 16:11:34   
 Manigandan.V wrote:
>I guess that your rom.ld is having problem .Can you post your rom.ld
>
>> I've patched uClinux with the boot from rom patch. However when I've
>compiled the kernel I've get the following error:
>> m68k-elf-objcopy -O binary /uClinux-dist/linux-2.4.x/linux \
>>   /uClinux-dist/images/linux.bin
>> BFD: Warning: Writing section `.text' to huge (ie negative) file offset
>0xffe200
>> 00.
>> m68k-elf-objcopy: /uClinux-dist/images/linux.bin: File truncated
>>
>> What is going wrong here?
>
>Regards,
>Mani
>
>
>_______________________________________________
>uClinux-dev mailing list
>uClinux-dev at uclinux.org
>http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
>This message was resent by uclinux-dev at uclinux.org
>


_____________________________________________________________
Get 25MB, POP3, Spam Filtering with LYCOS MAIL PLUS for $19.95/year.
http://login.mail.lycos.com/brandPage.shtml?pageId=plus&ref=lmtplus


From chri at infis.univ.trieste.it  Tue Mar  4 10:21:35 2003
From: chri at infis.univ.trieste.it (Christian Pellegrin)
Date: Tue, 4 Mar 2003 16:21:35 +0100 (CET)
Subject: [uClinux-dev] Eb55 boot problems.
In-Reply-To: <20030304155401.16ee04c0.mathieu-rousseau@ifrance.com>
References: <20030303173907.5bdb3424.mathieu-rousseau@ifrance.com>
 <Pine.LNX.4.53.0303040853280.13181@sole.infis.univ.trieste.it>
 <20030304140226.21a94b02.mathieu-rousseau@ifrance.com> <1046785209.14806.138.camel@justakiss>
 <20030304155401.16ee04c0.mathieu-rousseau@ifrance.com>
Message-ID: <Pine.LNX.4.53.0303041618560.16780@sole.infis.univ.trieste.it>


On Tue, 4 Mar 2003, Mathieu Rousseau wrote:

> Thanks, i'll take a look at this.
> 
> Is my eb55 board supported by kernel 2.4 ?
> I did not find any options to specify it while configuring it.
> 

I did the support for the 2.0 kernel, AFAIK 2.4 is not supported. My board 
only had 1MB of SRAM which is too little (IMHO) for decent 2.4 
developement. If someday I find a ram expansion (which is IMHO far to 
expensive as sold by Atmel) I'll try to do it.

Bye!


From mikes at tbc.net  Tue Mar  4 10:30:29 2003
From: mikes at tbc.net (Michael F. Sharp)
Date: Tue, 04 Mar 2003 09:30:29 -0600
Subject: [uClinux-dev] UCLINUX for PALM
References: <Pine.GSO.4.33.0302111240390.25930-100000@compserv1> <015801c2d222$ca8f38a0$ffc5fea9@henry133> <3E50444D.4010600@tbc.net> <004901c2d64e$13223fc0$ffc5fea9@henry133> <3E50E9DE.7050801@tbc.net> <000201c2d6d6$0d03e660$ffc5fea9@henry133> <3E524F5D.8020206@tbc.net> <000201c2d770$e5711e60$ffc5fea9@henry133> <3E5EB086.1070108@tbc.net> <000201c2dee8$065974a0$ffc5fea9@henry133> <3E5FE502.1060106@tbc.net> <000201c2dfc2$762ceb60$ffc5fea9@henry133> <3E61743D.6000901@tbc.net> <000201c2e074$63483560$ffc5fea9@henry133> <3E6192D6.60204@tbc.net> <002a01c2e082$999a6d00$ffc5fea9@henry133> <3E6274EB.7020605@tbc.net> <000201c2e200$dcab81e0$ffc5fea9@henry133>
Message-ID: <3E64C695.10806@tbc.net>

Henry,
I rechecked, and all is correct, but still can't boot. I've made the 
following observations though:

in vendors/3com/palm-loader/Palmloader.c

asm volatile (" movew #0x068f, 0xfffff116")
PDA locked, hard reset to restore, memory lost

asm volatile (" movew #0x3a81, 0xfffff116")
PDA locked, soft reset to restore, no memory loss

asm volatile (" movew #0x3e8F, 0xfffff116")
Fatal exception, hard reset to restore, memory lost


Results at 0x3a81 (from VZ) look the most promising so far... Is there a 
range of memory locations I can try in Palmloader.c? Any suggestions?

Cheers,
Mike

HenrySimmons17 wrote:
> Hello Mike
> uClinux is trying to run that is why you have to hard reset.
> Check the following files: 
>  In file: linux/arch/m68knommu/platform/68EZ328/PalmV/ram.ld
>  Chane to read:
>  ram  :   ORIGIN =  0x00000800,  LENGTH =  0x00800000 - 0x00000800
>  eram :  ORIGIN =  0x00800000,  LENGTH =  0
>  
>  In file: linux/arch/m68kn0mmu/platform/68EZ328/PalmV/crt0_ram.S
>       Just below  DEBUG( 'B );
> Change the line:    moveal #0x001ffff0, %ssp
> Change to:           moveal #0x007ffff0,  %ssp
> Add line:              move.l #0x00800000, %a0
> Add line:              move.l  %a0, _ramend




From philwil at earthlink.net  Tue Mar  4 10:25:10 2003
From: philwil at earthlink.net (Phil Wilshire)
Date: Tue, 04 Mar 2003 10:25:10 -0500
Subject: [uClinux-dev] uClinux Training Workshop Ottawa March 25-28th.
References: <3E646CE0.20514.8E8D087B@localhost>
Message-ID: <3E64C556.72CBBAEF@earthlink.net>

Hi Brad,

Thanks for your interest in this class.

If I remember correctly, you were trying to get python ported to uClinux 
How did this go ?

Anyway the course outline (attached) will be very similar to the one I used in Munich this year.

I am going to concentrate on 5272 and Arm based systems.

The cost is $1695.00 US for the 4 days.

Please let me know if you need any more information.

best regards
  Phil Wilshire


Brad Clements wrote:
> 
> What is the cost of attendence at the workshop?
> 
> What time will you start and end each day? I'm within commute distance of Ottawa.
> 
> --
> Brad Clements,                bkc at murkworks.com   (315)268-1000
> http://www.murkworks.com                          (315)268-9812 Fax
> http://www.wecanstopspam.org/                   AOL-IM: BKClements
> 
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org

-- 
SDCS -- System Design & Consulting Services LLC, http://www.sysdcs.com
** Embedded Linux Training **  email me for details  
630 Springhouse Sq., Leesburg VA 20175 t: 703 669 9766 f: 703 669 9768
-------------- next part --------------
SDCS uClinux Munich Workshop.




Target Systems 

   AT91 ArmTwister 2M FLash 8M Ram
   SnapGear Lite 5272 2M Flash 4M Ram
   uCDimm   VZ328 or 5272 2M FLash  8M Ram


This is an overview of topics covered in the workshop.
Phil Wilshire and Erwin Authried are continually developing more interesting
material to add to the course.


Hours 9.00 : 5:30 each day with a break for lunch.



Part 1

      Linux Basics 
            Linux Basics: Section Objectives 
            Linux Overview 
            Linux Versions 
            Linux Learning 
            Users 
            Setting Paths 
            Networking 
            Xwindows 
            Editors 
            Getting help 

      Cheat Sheets 
            System Essentials 
            Basic Commands 
            Login and Passwords 
            Users and Accounts 
            Advanced Commands 

      Linux System Tools 
            Shell 
            Make 
            Tar 
            Patch and Diff 
            CVS 
            RPM 

      Linux Installation Notes 
            Disk Partitions 
            File System Basics 
            Basic Networking 



Part 2

      uClinux Toolchain 
            Toolchain: Section Objectives 
            Toolchain Installation 
            Toolchain components 
            Toolchain component examples 
            Toolchain Linker 
            Library components 
            Kernel File Loader 
            Start File .. CRT0 (m68k) 
            Start File .. CRT0 (arm) 
            Flat file Linker 
            eXecute In Place 
            Shared Libraries (M68K only )

      The Linux System 
            Linux System: Section Objectives 
            How Linux Works 
            Kernel Communications 
            System Calls (ARM) 
            System Calls (m68k) 
            Kernel Communications - drivers 
            Kernel Communications - /proc 
            Kernel Communications - libraries 
            Root File System 
            Memory Management 

Part 3

      Debugging 
            Debug: Section Objectives 
            Introduction to GDB 
            A GDB example 
            Introduction to DDD 
            Using DDD 
            Creating the BDM driver 
            Creating a cross debugger 
            Using the BDM debugger 
            BDM debugger in user space 
            Introduction to JTAG
            Debugging Arm with JTAG 
	    Introduction ot GDB Server

      Simulators 
            Simulators:Section Objectives 
            Simulator Overview 
            Arm Simulator 
            M68k Simulator 
            M68k Profiling 

Part 4

      uClinux Development 
            App Development: Section Objectives 
            M68k Development 
            Arm Development 
            Applications Build 

      Vendor Settings and CVS 
            Vendor Settings: Section Objectives 
            Saving Configurations 
            A New Vendor Tree 
            Adding User Apps 
            Using CVS 

      uClinux Development-Using Busybox 
            Busybox: Section Objectives 
            System Core Components 
            Adding Busybox 
            Lab: Busybox Config 

      uClinux Advanced Code Samples 
            Simple Init task 
            Http Web Server 
            Http Web Server Details 
            Setjmp and Signals 


       Midori Development Tree
           Intro to Midori
           Using Midori
           Adding Packages 
           

Part 5

      The uClinux Kernel Startup 
            Section Objectives 
            Typical System Boot and Startup 
            Kernel Boot m68k 
            Kernel Boot arm AT91 
            Kernel Init m68k 
            Kernel Init arm 
            System Init 

      The uClinux Kernel configure and build 
            Kernel Configure: Section Objectives 
            System Setup 
            System Configuration 
            Kernel Configuration Options 

      The Target System 
            Target System: Section Objectives 
            Terminal Access 
            uCdimm Boot loader 
            5272 Memory Layout 
            AT91 Memory Layout 
            AT91 Hardware Definitions 
            5272 Hardware Definitions 
            5307 Hardware Definitions 

      uClinux Target System Setup 
            Target Setup: Section Objectives 
            System Deployment 
            System Deployment Lab 
            uCdimm System Setup 
            AT91 System Setup 

Part 6


      Kernel Modules 
            Section Objectives 
            Kernel Modules, Introduction 
            Module User Level Functions 
            Module Compilation 
            Module Symbols 
            Module Versions 
            Module Parameters 
            Modules in 2.4 Kernels 
            Module Deployment 
            Module Lab 

      Basic Device Driver Programming 
            Section Objectives 
            Device Drivers 
            Device Driver Picture 
            Device Classes 
            The /dev directory 
            Major/Minor Numbers 
            Registering a Device 
            A Basic Device Driver 
            Fops Table 
            Data Read/Write 
            Transferring Data 

      Example Device Driver 
            Section Objectives 
            Simple Char Mode Driver 
            Simple Char Mode Driver Lab 

      Proc File System 
            Section Objectives 
            Proc File System 
            Creating a Proc Entry 
            Creating a Proc Dir Entry 
            Proc Lab 
            Creating a Proc Write Entry 
            Proc Lab 

      Extending The Kernel Build 
            Section Objectives 
            Kernel Modification Introduction 
            The Kernel Build Process 
            The Kernel Config Process 
            Adding the driver into kernel (SnapGear) 
            

Part 7

      Extended Device Driver 
            Section Objectives 
            Critical Areas 
            Critical Areas Lab 
            Critical Areas Review 
            Blocking I/O 
            Blocking Code 
            Adding an IOCTL interface 
            Example IOCTL interface 
            Adding a poll interface 
            Example poll interface 
            Adding a mmap interface 
            Example mmap interface 

      Using Interrupts 
            Section Objectives 
            Interrupts Overview 
            m68k Interrupts 
            ARM Interrupts 
            ARM irq vectors 
            Interrupt Registration 
            Interrupt Servicing 
            Interrupt Actions 
            Interrupt Lab 


Part 8

      Posix Threads 
            Posix Threads: Section Objectives 
            Using Posix Threads 
            Lab: Posix Threads 
            Posix Threads Questions 

      Using ppp 
            Using ppp: Section Objectives 
            Using ppp 

      Using Flash Memory 
            Flash Memory: Section Objectives 
            Flash Overview 
            Blkmem driver 
            MTD driver 
            JFFS and JFFS 2 Drivers
            Flash Lab

      Power Management 
            Power Management: Section Objectives 
            Power Management Overview 
            PM Core 
            Using SYSCTL 
            Entering sleep 
            Waking up 

      Boa Webserver 
            Boa: Section Objectives 
            Boa Overview 
            Boa Config 
            Boa Lab 
            Boa CGI 
            Boa CGI Lab 

      Hard Real Time (not for all targets)
            Adding Hard Real Time 





From hamilton at SEDSystems.ca  Tue Mar  4 11:04:08 2003
From: hamilton at SEDSystems.ca (Kendrick Hamilton)
Date: Tue, 4 Mar 2003 10:04:08 -0600 (CST)
Subject: [uClinux-dev] BDM driver for 5407
Message-ID: <Pine.LNX.4.44.0303041003230.18735-100000@sw-55.sedsystems.ca>

Does anybody know where to get a BDM driver for an 5407 processor?
TIA
Kendrick



From hamilton at SEDSystems.ca  Tue Mar  4 11:28:22 2003
From: hamilton at SEDSystems.ca (Kendrick Hamilton)
Date: Tue, 4 Mar 2003 10:28:22 -0600 (CST)
Subject: [uClinux-dev] bdm driver for 5407
Message-ID: <Pine.LNX.4.44.0303041027080.1131-100000@sw-55.sedsystems.ca>

Never mind my message about needing a bdm driver for a 5407, I found out 
what the problem was. The cable on the bdm was not connected properly and 
causing errors.

-- 
Kendrick Hamilton E.I.T.
SED Systems, a division of Calian Ltd.
18 Innovation Blvd.
PO Box 1464
Saskatoon, Saskatchewan
Canada
S7N 3R1

Hamilton at sedsystems.ca
Tel: (306) 933-1453
Fax: (306) 933-1486



From bkc at murkworks.com  Tue Mar  4 11:50:23 2003
From: bkc at murkworks.com (Brad Clements)
Date: Tue, 04 Mar 2003 11:50:23 -0500
Subject: [uClinux-dev] uClinux Training Workshop Ottawa March 25-28th.
In-Reply-To: <3E646CE0.20514.8E8D087B@localhost>
References: <3E638A36.BECFF2B2@earthlink.net>
Message-ID: <3E648FE6.24820.8F15D910@localhost>

Sorry, this post misfired and went to the list instead of directly to the party I wanted it to 
go to.

On 4 Mar 2003 at 9:20, Brad Clements wrote:

From:           	"Brad Clements" <bkc at murkworks.com>
Organization:   	MurkWorks, Incorporated.
To:             	uclinux-dev at uclinux.org
Date sent:      	Tue, 04 Mar 2003 09:20:57 -0500
Subject:        	Re: [uClinux-dev] uClinux Training Workshop Ottawa March 25-28th.
Priority:       	normal
Send reply to:  	uclinux-dev at uclinux.org
	<mailto:uclinux-dev-request at uclinux.org?subject=subscribe>
	<mailto:uclinux-dev-request at uclinux.org?subject=unsubscribe>

> What is the cost of attendence at the workshop?
> 
> What time will you start and end each day? I'm within commute distance of
> Ottawa.
> 
> 
> 
> -- 
> Brad Clements,                bkc at murkworks.com   (315)268-1000
> http://www.murkworks.com                          (315)268-9812 Fax
> http://www.wecanstopspam.org/                   AOL-IM: BKClements
> 
> 


-- 
Brad Clements,                bkc at murkworks.com   (315)268-1000
http://www.murkworks.com                          (315)268-9812 Fax
http://www.wecanstopspam.org/                   AOL-IM: BKClements



From m.calo at ctsgroup.it  Tue Mar  4 11:53:18 2003
From: m.calo at ctsgroup.it (=?iso-8859-1?Q?Cal=F2_Massimo?=)
Date: Tue, 4 Mar 2003 17:53:18 +0100
Subject: [uClinux-dev] FrameBuffer for MCF5272
Message-ID: <004601c2e26e$8ec2db90$e10106c0@Massimo>

Hi All,

    does anybody have any information about using framebuffer on a MCF5272 based board?

Thanks!

Massimo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20030304/490705b5/attachment.html>

From ac131313 at redhat.com  Tue Mar  4 11:29:55 2003
From: ac131313 at redhat.com (Andrew Cagney)
Date: Tue, 04 Mar 2003 11:29:55 -0500
Subject: [uClinux-dev] Re: gdbserver relocation?
References: <buok7fqqdzi.fsf@mcspd15.ucom.lsi.nec.co.jp>	<20030224142831.GB24793@nevyn.them.org>	<20030224152608.GB2206@gnu.org> <3E5A3E20.5040706@redhat.com>	<buoheaj3ly5.fsf@mcspd15.ucom.lsi.nec.co.jp>	<20030304030318.GB31172@nevyn.them.org> <buo8yvv3iig.fsf@mcspd15.ucom.lsi.nec.co.jp>
Message-ID: <3E64D483.5000902@redhat.com>

> Daniel Jacobowitz <drow at mvista.com> writes:
> 
>> > What do you think of the following patch (I added the `handle_query'
>> > target callback, and then provided a linux-low.c implementation)?
> 
>> 
>> It looks reasonable to me.  Do you have GDB copyright papers on file?
> 
> 
> I don't think so; ac131313 sent me a form to do this, which I CC'd to
> the FSF a week ago or so, but I haven't received any reply yet (I will
> certainly sign an assignment, but it may take a while to get a copyright
> disclaimer from my work).

It's a legal process and as such can take a little time.  Once the paper 
work is resolved, can you please submit this patch to 
gdb-patches at sources.redhat.com

Andrew




From mathieu-rousseau at ifrance.com  Tue Mar  4 13:38:51 2003
From: mathieu-rousseau at ifrance.com (Mathieu Rousseau)
Date: Tue, 4 Mar 2003 19:38:51 +0100
Subject: [uClinux-dev] Eb55 boot problems.
In-Reply-To: <Pine.LNX.4.53.0303041615330.16780@sole.infis.univ.trieste.it>
References: <20030303173907.5bdb3424.mathieu-rousseau@ifrance.com>
	<Pine.LNX.4.53.0303040853280.13181@sole.infis.univ.trieste.it>
	<20030304140226.21a94b02.mathieu-rousseau@ifrance.com>
	<Pine.LNX.4.53.0303041408540.16780@sole.infis.univ.trieste.it>
	<20030304154747.1524d0db.mathieu-rousseau@ifrance.com>
	<Pine.LNX.4.53.0303041530480.16780@sole.infis.univ.trieste.it>
	<20030304164115.0f4ed8cd.mathieu-rousseau@ifrance.com>
	<Pine.LNX.4.53.0303041615330.16780@sole.infis.univ.trieste.it>
Message-ID: <20030304193851.5037b55d.mathieu-rousseau@ifrance.com>

I looked at Erwin linker script in order to run uClinux from arm. And it look for a .bss file. 
anyway, i never had .bss file after i compile...
I stil don't understand very well the process to run uClinux on my board...




On Tue, 4 Mar 2003 16:18:36 +0100 (CET)
Christian Pellegrin <chri at infis.univ.trieste.it> wrote:

> 
> 
> On Tue, 4 Mar 2003, Mathieu Rousseau wrote:
> 
> > what is bbs?
> > 
> 
> bbs is bulettin board system, I gues you meant bss: block started by 
> symbol. Is the segment of a program data that is not initialized.
> 
> Bye!
> 
> _____________________________________________________________________
> Envie de discuter en "live" avec vos amis ? T_l_charger MSN Messenger
> http://www.ifrance.com/_reloc/m la 1_re messagerie instantan_e de France
_____________________________________________________________________
GRAND JEU SMS : Pour gagner un NOKIA 7650, envoyez le mot IF au 61321
(prix d'un SMS + 0.35 euro). Un SMS vous dira si vous avez gagn?.
R?glement : http://www.ifrance.com/_reloc/sign.sms



From Thomas.Eschenbacher at gmx.de  Tue Mar  4 14:02:00 2003
From: Thomas.Eschenbacher at gmx.de (Thomas Eschenbacher)
Date: Tue, 04 Mar 2003 20:02:00 +0100
Subject: [uClinux-dev] problem understanding bootmem allocation
Message-ID: <3E64F828.8070303@gmx.de>

Hi,

I need some help in understanding the bootmem allocation subsystem. Is
there some documentation available or should I just ask on this list?

We still have problems in getting the memory setup right, so I decided
to start making the bootmem stuff more "generic" so that it also works
with different memory setups and not only for me.

The ideal case should be that init, text, data and bss can be whereever
they want and DRAM at any other area, maybe overlapping with any
combination of the segments listed before.

The state now is that things do not work when DRAM_START is at zero and
the code is somewhere above. Setting PAGE_OFFSET to 64kB did not help
(I'm running on armnommu, kernel 2.4 from CVS), it's just not enough.

Just as an example:
in arch/armnommu/mm/init.c, function "reserve_node_zero" the call to

reserve_bootmem_node(pgdat, __pa(&_stext), &_end - &_stext);

fails terribly, because _end is the end of .bss and thus below our
kernel code at _stext => the resulting size is negative!!!

I split this up into four calls:
------------------------------------------
reserve_bootmem_node(pgdat, __pa(&__init_begin), &__init_end - 
__init_begin);
reserve_bootmem_node(pgdat, __pa(&_text),  &_etext - &_text);
reserve_bootmem_node(pgdat, __pa(&__data_start), &__data_end - 
&__data_start);
reserve_bootmem_node(pgdat, __pa(&__bss_start), &__bss_end - &__bss_start);
------------------------------------------

and defined some missing symbols like __data_start in the linker script.
Is that okay?


I also have problems with the following call to reserve_bootmem_node, as
seen in mmnommu/bootmem.c. It calls "reserve_bootmem_core(pgdat->bdata,
physaddr, size);" - but pgdat->bdata is a NULL pointer! What goes wrong
here???

thanks,
    Thomas
-- 
________________________________________________________________________
Thomas Eschenbacher <Thomas.Eschenbacher at gmx.de> [LANG=de_DE | en_EN]



From tchen at on-go.com  Tue Mar  4 15:21:40 2003
From: tchen at on-go.com (thomas chen)
Date: Tue, 04 Mar 2003 15:21:40 -0500
Subject: [uClinux-dev] problem understanding bootmem allocation
References: <3E64F828.8070303@gmx.de>
Message-ID: <3E650AD4.2F459268@on-go.com>

i had the same problem a while back.... i just looked at how i did
that...

in arch/armnommu/mm/init.c

i did 
reserve_bootmem_node(pgdat, 0, &_end)

instead of 
reserve_bootmem_node(pgdat, &_text, &_end)

since _text is where TEXTADDR is... (for me 0x1000 above those
vectores)... this change will reserve everything below 0x1000
also, otherwise, if your RAM is configured to start from 0,
memory allocation somewhere would return 0 as the starting addres
of the block, but the calling program would think it is NULL...

sorry... i did not take good note and this is all i can remember, but
it does work for me since... (but this was done a while back)



Thomas Eschenbacher wrote:
> 
> Hi,
> 
> I need some help in understanding the bootmem allocation subsystem. Is
> there some documentation available or should I just ask on this list?
> 
> We still have problems in getting the memory setup right, so I decided
> to start making the bootmem stuff more "generic" so that it also works
> with different memory setups and not only for me.
> 
> The ideal case should be that init, text, data and bss can be whereever
> they want and DRAM at any other area, maybe overlapping with any
> combination of the segments listed before.
> 
> The state now is that things do not work when DRAM_START is at zero and
> the code is somewhere above. Setting PAGE_OFFSET to 64kB did not help
> (I'm running on armnommu, kernel 2.4 from CVS), it's just not enough.
> 
> Just as an example:
> in arch/armnommu/mm/init.c, function "reserve_node_zero" the call to
> 
> reserve_bootmem_node(pgdat, __pa(&_stext), &_end - &_stext);
> 
> fails terribly, because _end is the end of .bss and thus below our
> kernel code at _stext => the resulting size is negative!!!
> 
> I split this up into four calls:
> ------------------------------------------
> reserve_bootmem_node(pgdat, __pa(&__init_begin), &__init_end -
> __init_begin);
> reserve_bootmem_node(pgdat, __pa(&_text),  &_etext - &_text);
> reserve_bootmem_node(pgdat, __pa(&__data_start), &__data_end -
> &__data_start);
> reserve_bootmem_node(pgdat, __pa(&__bss_start), &__bss_end - &__bss_start);
> ------------------------------------------
> 
> and defined some missing symbols like __data_start in the linker script.
> Is that okay?
> 
> I also have problems with the following call to reserve_bootmem_node, as
> seen in mmnommu/bootmem.c. It calls "reserve_bootmem_core(pgdat->bdata,
> physaddr, size);" - but pgdat->bdata is a NULL pointer! What goes wrong
> here???
> 
> thanks,
>     Thomas
> --
> ________________________________________________________________________
> Thomas Eschenbacher <Thomas.Eschenbacher at gmx.de> [LANG=de_DE | en_EN]
> 
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org


From kjell at cablescan.com  Tue Mar  4 16:31:22 2003
From: kjell at cablescan.com (Kjell Uddeborg)
Date: Tue, 4 Mar 2003 13:31:22 -0800
Subject: [uClinux-dev] Problems mounting a JFFS2 file system
Message-ID: <GGEOICAJEIILOOCMGNKMMEBEDGAA.kjell@cablescan.com>

Hi,

I'm having some problems mounting a JFFS2 file system. I'm using uClinux kernel 2.4 on a Motorola M5249C3 board.

I think that I have all MTD stuff configured correctly and I can erase the device /dev/mtd1 with no problem, see screen dump:

-----------------------------
/> eraseall /dev/mtd1
MTD_open
MTD_ioctl
 0raTsiDng_ 6i4 oKicbyttel @
 1raTsiDng_ 6i4 oKicbyttel @
 2raTsiDng_ 6i4 oKicbyttel @
 3raTsiDng_ 6i4 oKicbyttel @
 4raTsiDng_ 6i4 oKicbyttel @
 5raTsiDng_ 6i4 oKicbyttel @
 6raTsiDng_ 6i4 oKicbyttel @
 7raTsiDng_ 6i4 oKicbyttel @
 8raTsiDng_ 6i4 oKicbyttel @
 9raTsiDng_ 6i4 oKicbyttel @
 araTsiDng_ 6i4 oKicbyttel @
 braTsiDng_ 6i4 oKicbyttel @
 craTsiDng_ 6i4 oKicbyttel @
 draTsiDng_ 6i4 oKicbyttel @
 eraTsiDng_ 6i4 oKicbyttel @
 fraTsiDng_ 6i4 oKicbyttel @
@ raTseDd _10c24l Koibsytee 
  0 -- 100% complete.       
-----------------------------

As you can see I have all the debug outputs turned on. Looks to me that the command completed successfully.

The problem occurs when I try to mount the JFFS2 file system, see screen dump:

-----------------------------
/> mount -t jffs2 /dev/mtdblock1 /mnt/jffs2
arena open of 1 failed!
mount: Mounting /dev/mtdblock1 on /mnt/jffs2 failed: No such device 
pid 28: failed 256
-----------------------------

The /dev/mtdblock1 is exists, see this partial listing on /dev:

-----------------------------
/> ls -l /dev
.
.
crw-------  1 0        0         90,   0  Jan 01 1970  mtd0
crw-------  1 0        0         90,   2  Jan 01 1970  mtd1
crw-------  1 0        0         90,   4  Jan 01 1970  mtd2
crw-------  1 0        0         90,   6  Jan 01 1970  mtd3
brw-------  1 0        0         31,   0  Jan 01 1970  mtdblock0
brw-------  1 0        0         31,   1  Jan 01 1970  mtdblock1
brw-------  1 0        0         31,   2  Jan 01 1970  mtdblock2
brw-------  1 0        0         31,   3  Jan 01 1970  mtdblock3
crw-------  1 0        0         90,   1  Jan 01 1970  mtdr0
crw-------  1 0        0         90,   3  Jan 01 1970  mtdr1
crw-------  1 0        0         90,   5  Jan 01 1970  mtdr2
crw-------  1 0        0         90,   7  Jan 01 1970  mtdr3
.
.
-----------------------------

If you have any thoughts of what could be causing this problem please send me a note.

Thanks for your help,
Kjell Uddeborg
Cablescan



From espin at idiom.com  Tue Mar  4 16:57:03 2003
From: espin at idiom.com (Geoffrey Espin)
Date: Tue, 4 Mar 2003 13:57:03 -0800
Subject: [uClinux-dev] AMD - Am29LV160B
In-Reply-To: <3E649098.1060601@metrowerks.com>
References: <04C8EDC5AE3FD611ABE40002B39CF69B07F2DF@ntah901e.savan.com> <3E649098.1060601@metrowerks.com>
Message-ID: <20030304215703.GA9664@idiom.com>

Amit.Lubovsky at infineon.com wrote:

> >  x x    (BIG_ENDIAN_BYTE) Flash cmd/query data swapping                  x
> Maybe you need to try other variants, as well, i.e. little
> endian: you never know from which side they are looking
> at it :-)

You're sure its just the "B" part?  Not B3?

I had to write my own driver for the Intel 28F160B3.  It is NOT CFI
compliant.  This code also is verified for the 28F320B3 part.  Only
tested on a Conexant ARM plaform.

Geoff
--
Geoffrey Espin
espin at idiom.com
-------------- next part --------------
diff -b -Naur linux-2.4.20/drivers/mtd/devices/Config.in working/linux/drivers/mtd/devices/Config.in
--- linux-2.4.20/drivers/mtd/devices/Config.in	Thu Nov 28 15:53:13 2002
+++ working/linux/drivers/mtd/devices/Config.in	Sun Dec 22 06:03:15 2002
@@ -10,6 +10,12 @@
    bool '    PMC551 256M DRAM Bugfix' CONFIG_MTD_PMC551_BUGFIX
    bool '    PMC551 Debugging' CONFIG_MTD_PMC551_DEBUG
 fi
+## XXX
+if [ "$CONFIG_ARCH_CX821XX" = "y" ]; then
+  dep_tristate '  Conexant 28F160/28F320 B3 flash driver' CONFIG_MTD_CONEXANT_FLASH
+$CONFIG_MTD
+fi
+
 if [ "$CONFIG_DECSTATION" = "y" ]; then
    dep_tristate '  DEC MS02-NV NVRAM module support' CONFIG_MTD_MS02NV $CONFIG_MTD $CONFIG_DECSTATION
 fi
diff -b -Naur linux-2.4.20/drivers/mtd/devices/Makefile working/linux/drivers/mtd/devices/Makefile
--- linux-2.4.20/drivers/mtd/devices/Makefile	Thu Nov 28 15:53:13 2002
+++ working/linux/drivers/mtd/devices/Makefile	Sun Dec 22 06:04:10 2002
@@ -22,5 +22,7 @@
 obj-$(CONFIG_MTD_MTDRAM)	+= mtdram.o
 obj-$(CONFIG_MTD_LART)		+= lart.o
 obj-$(CONFIG_MTD_BLKMTD)	+= blkmtd.o
+obj-$(CONFIG_MTD_CONEXANT_FLASH)+= conexant-flash.o
+
 
 include $(TOPDIR)/Rules.make
diff -b -Naur linux-2.4.20/drivers/mtd/devices/conexant-flash.c working/linux/drivers/mtd/devices/conexant-flash.c
--- linux-2.4.20/drivers/mtd/devices/conexant-flash.c	Wed Dec 31 16:00:00 1969
+++ working/linux/drivers/mtd/devices/conexant-flash.c	Sun Dec 22 06:01:37 2002
@@ -0,0 +1,697 @@
+/*
+ * MTD driver for the 28F160B3 Flash Memory (non-CFI) on Conexant.
+ *
+ * Author: Geoffrey Espin based on work by...
+ *         Abraham vd Merwe <abraham at 2d3d.co.za>
+ *
+ * Copyright (c) 2001, 2d3D, Inc.
+ *
+ * This code is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * References:
+ *
+ *    [1] 3 Volt Fast Boot Block Flash Memory" Intel Datasheet
+ *           - Order Number: 290644-005
+ *           - January 2000
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/types.h>
+#include <linux/version.h>
+#include <linux/errno.h>
+#include <linux/mtd/mtd.h>
+#include <linux/mtd/partitions.h>
+
+#ifndef CONFIG_CHIP_CX82100
+#error This is for CONEXANT architecture only
+#endif
+
+static char module_name[] = "conexant-flash";
+
+#define xCONEXANT_DEBUG 1 /* debugging */
+
+// XXX ESPIN FIX/CHECK! for 28F320 PART
+//
+/*
+ * These values is specific to 28Fxxxx3 flash memory.
+ * See section 2.3.1 in "3 Volt Fast Boot Block Flash Memory" Intel Datasheet
+ */
+#define FLASH_BLOCKSIZE_PARAM		(8 * 1024)	// 8K
+#define FLASH_NUMBLOCKS_PARAM		8		// same for 16m & 32m
+
+/*
+ * These values is specific to 28Fxxxx3 flash memory.
+ * See section 2.3.2 in "3 Volt Fast Boot Block Flash Memory" Intel Datasheet
+ */
+#define FLASH_BLOCKSIZE_MAIN		(64 * 1024)	// 64K
+#define FLASH_NUMBLOCKS_16m_MAIN	31
+#define FLASH_NUMBLOCKS_32m_MAIN	(31+32)
+
+#define FLASH_TOTAL_16m_SIZE		((FLASH_NUMBLOCKS_16m_MAIN * 64 * 1024) + (8 * 8 * 1024))
+#define FLASH_TOTAL_32m_SIZE		((FLASH_NUMBLOCKS_32m_MAIN * 64 * 1024) + (8 * 8 * 1024))
+
+#define _WIDTH		u16		/* code could break if changed */
+#define BUSWIDTH	2		/* code could break if changed */
+#define FLASH_OFFSET	0x00400000	/* base of flash */
+#define	READBW	read16			/* read8/read32 */
+#define	WRITEBW	write16			/* write8/write32 */
+
+/*
+ * See section 4.0 in "3 Volt Fast Boot Block Flash Memory" Intel Datasheet
+ */
+#define READ_ARRAY		(_WIDTH)0x00FF00FF	/* Read Array/Reset */
+#define READ_ID_CODES		(_WIDTH)0x00900090	/* Read Identifier Codes */
+#define ERASE_SETUP		(_WIDTH)0x00200020	/* Block Erase */
+#define ERASE_CONFIRM		(_WIDTH)0x00D000D0	/* Block Erase and Program Resume */
+#define PGM_SETUP		(_WIDTH)0x00400040	/* Program */
+#define STATUS_READ		(_WIDTH)0x00700070	/* Read Status Register */
+#define STATUS_CLEAR		(_WIDTH)0x00500050	/* Clear Status Register */
+#define STATUS_BUSY		(_WIDTH)0x00800080	/* Write State Machine Status (WSMS) */
+#define STATUS_ERASE_ERR	(_WIDTH)0x00200020	/* Erase Status (ES) */
+#define STATUS_PGM_ERR		(_WIDTH)0x00100010	/* Program Status (PS) */
+
+/*
+ * See section 4.2 in "3 Volt Fast Boot Block Flash Memory" Intel Datasheet
+ */
+#define FLASH_MANUFACTURER		(_WIDTH)0x00890089
+#define xFLASH_DEVICE_16mbit_TOP	(_WIDTH)0x88f388f3	// F3
+#define xFLASH_DEVICE_16mbit_BOTTOM	(_WIDTH)0x88f488f4	// F3
+
+								// 28F160
+#define FLASH_DEVICE_16mbit_TOP		(_WIDTH)0x88908890	// B3 untested?
+#define FLASH_DEVICE_16mbit_BOTTOM	(_WIDTH)0x88918891	// B3 BA90
+								// 28F320
+#define FLASH_DEVICE_32mbit_TOP		(_WIDTH)0x88968896	// B3 untested?
+#define FLASH_DEVICE_32mbit_BOTTOM	(_WIDTH)0x88978897	// B3 BC90
+
+static int conexant_size_bottom = -1;
+
+/******************************************************************************/
+
+
+static __u8
+read8(__u32 offset)
+{
+	__u8 data = *(volatile __u8 *) (FLASH_OFFSET + offset);
+#ifdef CONEXANT_DEBUG
+#if CONEXANT_DEBUG > 1
+	printk("%s(): 0x%.8x -> 0x%.2x\n", __FUNCTION__, FLASH_OFFSET + offset, data);
+#endif
+#endif
+	return (data);
+}
+
+static __u16
+read16(__u32 offset)
+{
+	__u16 data = *(volatile __u16 *) (FLASH_OFFSET + offset);
+#ifdef CONEXANT_DEBUG
+#if CONEXANT_DEBUG > 1
+	printk("%s(): 0x%.8x -> 0x%.8x\n", __FUNCTION__, FLASH_OFFSET + offset, data);
+#endif
+#endif
+	return (data);
+}
+
+static void
+write16(__u16 x, __u32 offset)
+{
+	*(__u16 *) (FLASH_OFFSET + offset) = x;
+#ifdef CONEXANT_DEBUG
+#if CONEXANT_DEBUG > 1
+	printk("%s(): 0x%.8x <- 0x%.8x\n", __FUNCTION__, FLASH_OFFSET + offset, x);
+#endif
+#endif
+}
+
+/*****************************************************************************/
+
+/*
+ * Probe for 16mbit flash memory without doing too much damage.
+ *
+ * Returns 1 if we found 16mbit flash memory, 0 otherwise.
+ */
+static int
+flash_probe(void)
+{
+	_WIDTH manufacturer, devtype;
+
+	/* setup "Read Identifier Codes" mode */
+	WRITEBW(READ_ID_CODES, 0x0 * BUSWIDTH);
+
+	/* probe U2. U2/U3 returns the same data since the first 3 */
+	/* address lines is mangled in the same way */
+
+	manufacturer = READBW (0x0 * BUSWIDTH);
+	devtype = READBW (0x1 * BUSWIDTH);
+
+	/* put the flash back into command mode */
+	WRITEBW(READ_ARRAY, 0x0 * BUSWIDTH);
+
+	if (manufacturer == FLASH_MANUFACTURER) {
+		if (devtype == FLASH_DEVICE_16mbit_TOP)
+			conexant_size_bottom = 0x0;
+		else if (devtype == FLASH_DEVICE_16mbit_BOTTOM)
+			conexant_size_bottom = 0x1;
+		else if (devtype == FLASH_DEVICE_32mbit_TOP)
+			conexant_size_bottom = 0x2;
+		else if (devtype == FLASH_DEVICE_32mbit_BOTTOM)
+			conexant_size_bottom = 0x3;
+	}
+	printk("MFR %#x (%#x) DEV %#x (%#x,%#x,%#x,%#x) %s-boot %s\n", manufacturer,
+		FLASH_MANUFACTURER, devtype,
+		FLASH_DEVICE_16mbit_TOP, FLASH_DEVICE_16mbit_BOTTOM,
+		FLASH_DEVICE_32mbit_TOP, FLASH_DEVICE_32mbit_BOTTOM,
+		(conexant_size_bottom & 0x1) ? "bottom" : "top",
+		(conexant_size_bottom & 0x2) ? "4M" : "2M"
+		);
+
+	if (conexant_size_bottom == -1)
+		return 0;
+
+	return 1;
+}
+
+/*
+ * Erase one block of flash memory at offset ``offset'' which is any
+ * address within the block which should be erased.
+ *
+ * Returns 1 if successful, 0 otherwise.
+ */
+static inline int
+erase_block(__u32 offset)
+{
+	int status;
+
+#ifdef CONEXANT_DEBUG
+	printk("%s(): 0x%.8x\n", __FUNCTION__, offset);
+#endif
+
+	/* erase and confirm */
+	WRITEBW(ERASE_SETUP, offset);
+	WRITEBW(ERASE_CONFIRM, offset);
+
+	/* wait for block erase to finish */
+	do {
+		WRITEBW(STATUS_READ, offset);
+		status = READBW(offset);
+	}
+	while ((~status & STATUS_BUSY) != 0);
+
+	/* put the flash back into command mode */
+	WRITEBW(READ_ARRAY, offset);
+
+	/* was the erase successfull? */
+	if ((status & STATUS_ERASE_ERR)) {
+		printk(KERN_WARNING "%s: erase error at address 0x%.8x.\n",
+		       module_name, offset);
+		return (0);
+	}
+
+	return (1);
+}
+
+static int
+flash_erase(struct mtd_info *mtd, struct erase_info *instr)
+{
+	__u32 addr, len;
+	int i, first;
+
+#ifdef CONEXANT_DEBUG
+	printk("%s(addr = 0x%.8x, len = %d)\n", __FUNCTION__, instr->addr,
+	       instr->len);
+#endif
+
+	/* sanity checks */
+	if (instr->addr + instr->len > mtd->size)
+		return (-EINVAL);
+
+	/*
+	   * check that both start and end of the requested erase are
+	   * aligned with the erasesize at the appropriate addresses.
+	   *
+	   * skip all erase regions which are ended before the start of
+	   * the requested erase. Actually, to save on the calculations,
+	   * we skip to the first erase region which starts after the
+	   * start of the requested erase, and then go back one.
+	 */
+	for (i = 0;
+	     i < mtd->numeraseregions
+	     && instr->addr >= mtd->eraseregions[i].offset; i++) ;
+	i--;
+
+	/*
+	   * ok, now i is pointing at the erase region in which this
+	   * erase request starts. Check the start of the requested
+	   * erase range is aligned with the erase size which is in
+	   * effect here.
+	 */
+	if (instr->addr & (mtd->eraseregions[i].erasesize - 1))
+		return (-EINVAL);
+
+	/* Remember the erase region we start on */
+	first = i;
+
+	/*
+	   * next, check that the end of the requested erase is aligned
+	   * with the erase region at that address.
+	   *
+	   * as before, drop back one to point at the region in which
+	   * the address actually falls
+	 */
+	for (;
+	     i < mtd->numeraseregions
+	     && instr->addr + instr->len >= mtd->eraseregions[i].offset; i++) ;
+	i--;
+
+	/* is the end aligned on a block boundary? */
+	if ((instr->addr + instr->len) & (mtd->eraseregions[i].erasesize - 1))
+		return (-EINVAL);
+
+	addr = instr->addr;
+	len = instr->len;
+
+	i = first;
+
+	/* now erase those blocks */
+	while (len) {
+		if (!erase_block(addr)) {
+			instr->state = MTD_ERASE_FAILED;
+			return (-EIO);
+		}
+
+		addr += mtd->eraseregions[i].erasesize;
+		len -= mtd->eraseregions[i].erasesize;
+
+		if (addr ==
+		    mtd->eraseregions[i].offset +
+		    (mtd->eraseregions[i].erasesize *
+		     mtd->eraseregions[i].numblocks))
+			i++;
+	}
+
+	instr->state = MTD_ERASE_DONE;
+	if (instr->callback)
+		instr->callback(instr);
+
+	return (0);
+}
+
+static int
+flash_read(struct mtd_info *mtd, loff_t from, size_t len, size_t * retlen,
+	   u_char * buf)
+{
+#ifdef CONEXANT_DEBUG
+	printk("%s(from = 0x%.8x, len = %d)\n", __FUNCTION__, (__u32) from,
+	       len);
+#endif
+
+	/* sanity checks */
+	if (!len)
+		return (0);
+	if (from + len > mtd->size)
+		return (-EINVAL);
+
+	/* we always read len bytes */
+	*retlen = len;
+
+	/* first, we read bytes until we reach a dword boundary */
+	if (from & (BUSWIDTH - 1)) {
+		int gap = BUSWIDTH - (from & (BUSWIDTH - 1));
+
+		while (len && gap--)
+			*buf++ = read8(from++), len--;
+	}
+
+	/* now we read dwords until we reach a non-dword boundary */
+	while (len >= BUSWIDTH) {
+		*((_WIDTH *) buf) = READBW(from);
+
+		buf += BUSWIDTH;
+		from += BUSWIDTH;
+		len -= BUSWIDTH;
+	}
+
+	/* top up the last unaligned bytes */
+	if (len & (BUSWIDTH - 1))
+		while (len--)
+			*buf++ = read8(from++);
+
+	return (0);
+}
+
+/*
+ * Write one dword ``x'' to flash memory at offset ``offset''. ``offset''
+ * must be 32 bits, i.e. it must be on a dword boundary.
+ *
+ * Returns 1 if successful, 0 otherwise.
+ */
+static inline int
+write_dword(__u32 offset, _WIDTH x)
+{
+	_WIDTH status;
+
+#ifdef CONEXANT_DEBUG
+#if CONEXANT_DEBUG > 1
+	printk("%s(): 0x%.8x <- 0x%.8x\n", __FUNCTION__, offset, x);
+#endif
+#endif
+
+	/* setup writing */
+	WRITEBW(PGM_SETUP, offset);
+
+	/* write the data */
+	WRITEBW(x, offset);
+
+	/* wait for the write to finish */
+	do {
+		WRITEBW(STATUS_READ, offset);
+		status = READBW(offset);
+	}
+	while ((~status & STATUS_BUSY) != 0);
+
+	/* put the flash back into command mode */
+	WRITEBW(READ_ARRAY, offset);
+
+	/* was the write successfull? */
+	if ((status & STATUS_PGM_ERR) || READBW(offset) != x) {
+		printk(KERN_WARNING "%s: write error at address 0x%.8x.\n",
+		       module_name, offset);
+		return (0);
+	}
+
+	return (1);
+}
+
+static int
+flash_write(struct mtd_info *mtd, loff_t to, size_t len, size_t * retlen,
+	    const u_char * buf)
+{
+	__u8 tmp[4];
+	int i, n;
+
+#ifdef CONEXANT_DEBUG
+	printk("%s(to = 0x%.8x, len = %d)\n", __FUNCTION__, (__u32) to, len);
+#endif
+
+	*retlen = 0;
+
+	/* sanity checks */
+	if (!len)
+		return (0);
+	if (to + len > mtd->size)
+		return (-EINVAL);
+
+	/* first, we write a 0xFF.... padded byte until we reach a dword boundary */
+	if (to & (BUSWIDTH - 1)) {
+		__u32 aligned = to & ~(BUSWIDTH - 1);
+		int gap = to - aligned;
+
+		i = n = 0;
+
+		while (gap--)
+			tmp[i++] = 0xFF;
+		while (len && i < BUSWIDTH)
+			tmp[i++] = buf[n++], len--;
+		while (i < BUSWIDTH)
+			tmp[i++] = 0xFF;
+
+		if (!write_dword(aligned, *((_WIDTH *) tmp)))
+			return (-EIO);
+
+		to += n;
+		buf += n;
+		*retlen += n;
+	}
+
+	/* now we write dwords until we reach a non-dword boundary */
+	while (len >= BUSWIDTH) {
+		if (!write_dword(to, *((_WIDTH *) buf)))
+			return (-EIO);
+
+		to += BUSWIDTH;
+		buf += BUSWIDTH;
+		*retlen += BUSWIDTH;
+		len -= BUSWIDTH;
+	}
+
+	/* top up the last unaligned bytes, padded with 0xFF.... */
+	if (len & (BUSWIDTH - 1)) {
+		i = n = 0;
+
+		while (len--)
+			tmp[i++] = buf[n++];
+		while (i < BUSWIDTH)
+			tmp[i++] = 0xFF;
+
+		if (!write_dword(to, *((_WIDTH *) tmp)))
+			return (-EIO);
+
+		*retlen += n;
+	}
+
+	return (0);
+}
+
+static void flash_sync(struct mtd_info *mtd)
+{
+	        /* Nothing to see here */
+}
+
+/******************************************************************************/
+
+#define NB_OF(x) (sizeof (x) / sizeof ((x)[0]))
+
+static struct mtd_info conexant_mtd;
+
+// XXX ESPIN FIX/CHECK!
+static struct mtd_erase_region_info erase_regions_32tb[] = {
+	/* main blocks */
+	{
+		offset:		0x00000000,
+		erasesize:	64 * 1024,
+		numblocks:	31
+	},
+	/* parameter blocks */
+	{
+		offset:		0x00000000 + 31 * (64 * 1024),
+		erasesize:	8 * 1024,
+		numblocks:	8
+	}
+};
+
+static struct mtd_erase_region_info erase_regions_16bb[] = {
+	/* parameter blocks */
+	{
+		offset:		0x00000000,
+		erasesize:	8 * 1024,
+		numblocks:	8
+	},
+	/* main blocks */
+	{
+		offset:		0x00000000 + 8 * (8 * 1024),
+		erasesize:	64 * 1024,
+		numblocks:	31
+	}
+};
+
+static struct mtd_erase_region_info erase_regions_16tb[] = {
+	/* main blocks */
+	{
+		offset:		0x00000000,
+		erasesize:	64 * 1024,
+		numblocks:	31
+	},
+	/* parameter blocks */
+	{
+		offset:		0x00000000 + 31 * (64 * 1024),
+		erasesize:	8 * 1024,
+		numblocks:	8
+	}
+};
+
+static struct mtd_erase_region_info erase_regions_32bb[] = {
+	/* parameter blocks */
+	{
+		offset:		0x00000000,
+		erasesize:	8 * 1024,
+		numblocks:	8
+	},
+	/* main blocks */
+	{
+		offset:		0x00000000 + 8 * (8 * 1024),
+		erasesize:	64 * 1024,
+		numblocks:	31
+	}
+};
+
+#ifdef CONFIG_MTD_PARTITIONS
+static struct mtd_partition conexant_partitions[] = {
+	{
+		name:       "bootloader+kernel",
+		size:       0x00100000,	/* 1MB */
+		offset:     0,
+		mask_flags: 0		// set MTD_WRITEABLE if want readonly
+	},
+#if 0
+	{
+		name:	    "params",
+		size:	    0x00100000,	/* ? */
+		offset:	    MTDPART_OFS_APPEND,
+		mask_flags: MTD_WRITEABLE
+	},
+#endif
+	{
+		name:	   "romfs",
+		//size:	    MTDPART_SIZ_FULL,	/* 1MB */
+		//offset:	    MTDPART_OFS_APPEND,
+		size:       0x00100000,	/* 1MB */
+		offset:	    0x00100000,	/* 1MB */
+		mask_flags: 0		// set MTD_WRITEABLE if want readonly
+	}
+};
+#endif
+
+int __init
+conexant_flash_init(void)
+{
+	int result;
+
+	memset(&conexant_mtd, 0, sizeof (conexant_mtd));
+
+	printk("%s: probing for Conexant 28F160/320B3 flash.\n", module_name);
+
+	if (!flash_probe()) {
+		printk(KERN_WARNING "%s: Found no flash device.\n",
+		       module_name);
+		return (-ENXIO);
+	}
+
+	// map->fldrv = &mapram_chipdrv;
+	// mtd->priv = map;
+
+	conexant_mtd.name = module_name;
+	conexant_mtd.type = MTD_NORFLASH;
+	conexant_mtd.flags = MTD_CAP_NORFLASH;
+	conexant_mtd.size = ((conexant_size_bottom & 0x2) == 0) ?
+				FLASH_TOTAL_16m_SIZE : FLASH_TOTAL_32m_SIZE;
+	conexant_mtd.erasesize = FLASH_BLOCKSIZE_MAIN;
+
+	if (conexant_size_bottom == 0x0) {
+		conexant_mtd.numeraseregions = NB_OF(erase_regions_16tb);
+		conexant_mtd.eraseregions = erase_regions_16tb;
+	} else if (conexant_size_bottom == 0x01) {
+		conexant_mtd.numeraseregions = NB_OF(erase_regions_16bb);
+		conexant_mtd.eraseregions = erase_regions_16bb;
+	} else if (conexant_size_bottom == 0x02) {
+		conexant_mtd.numeraseregions = NB_OF(erase_regions_32tb);
+		conexant_mtd.eraseregions = erase_regions_32tb;
+	} else if (conexant_size_bottom == 0x03) {
+		conexant_mtd.numeraseregions = NB_OF(erase_regions_32bb);
+		conexant_mtd.eraseregions = erase_regions_32bb;
+	} else {
+		printk (__FUNCTION__ ": conexant chip unknown!\n");
+		return (-ENXIO);
+	}
+
+	conexant_mtd.module = THIS_MODULE;
+	conexant_mtd.erase = flash_erase;
+	conexant_mtd.read = flash_read;
+	conexant_mtd.write = flash_write;
+	conexant_mtd.sync = flash_sync;
+
+#ifdef CONEXANT_DEBUG
+	printk("mtd.name = %s\n"
+	       "mtd.size = 0x%.8x (%uM)\n"
+	       "mtd.erasesize = 0x%.8x (%uK)\n"
+	       "mtd.numeraseregions = %d\n",
+	       conexant_mtd.name,
+	       conexant_mtd.size, conexant_mtd.size / (1024 * 1024),
+	       conexant_mtd.erasesize, conexant_mtd.erasesize / 1024, conexant_mtd.numeraseregions);
+
+	if (conexant_mtd.numeraseregions)
+		{
+		int ix;
+		for (ix = 0; ix < conexant_mtd.numeraseregions; ix++)
+			printk("\n\n"
+			       "mtd.eraseregions[%d].offset = 0x%.8x\n"
+			       "mtd.eraseregions[%d].erasesize = 0x%.8x (%uK)\n"
+			       "mtd.eraseregions[%d].numblocks = %d\n",
+			       ix, conexant_mtd.eraseregions[ix].offset,
+			       ix, conexant_mtd.eraseregions[ix].erasesize,
+			       conexant_mtd.eraseregions[ix].erasesize / 1024,
+			       ix, conexant_mtd.eraseregions[ix].numblocks);
+		}
+#endif
+
+#ifdef CONFIG_MTD_PARTITIONS
+	result = add_mtd_partitions(&conexant_mtd, conexant_partitions,
+			       NB_OF(conexant_partitions));
+#else
+	result = add_mtd_device(&conexant_mtd);
+#endif
+
+#ifdef CONEXANT_DEBUG
+	printk("mtd.name = %s\n"
+	       "mtd.size = 0x%.8x (%uM)\n"
+	       "mtd.erasesize = 0x%.8x (%uK)\n"
+	       "mtd.numeraseregions = %d\n",
+	       conexant_mtd.name,
+	       conexant_mtd.size, conexant_mtd.size / (1024 * 1024),
+	       conexant_mtd.erasesize, conexant_mtd.erasesize / 1024, conexant_mtd.numeraseregions);
+
+	if (conexant_mtd.numeraseregions)
+		{
+		int ix;
+		for (ix = 0; ix < conexant_mtd.numeraseregions; ix++)
+			printk("\n\n"
+			       "mtd.eraseregions[%d].offset = 0x%.8x\n"
+			       "mtd.eraseregions[%d].erasesize = 0x%.8x (%uK)\n"
+			       "mtd.eraseregions[%d].numblocks = %d\n",
+			       ix, conexant_mtd.eraseregions[ix].offset,
+			       ix, conexant_mtd.eraseregions[ix].erasesize,
+			       conexant_mtd.eraseregions[ix].erasesize / 1024,
+			       ix, conexant_mtd.eraseregions[ix].numblocks);
+		}
+
+#ifdef CONFIG_MTD_PARTITIONS
+	{
+	int ix;
+	printk("\npartitions = %d\n", NB_OF(conexant_partitions));
+
+	for (ix = 0; ix < NB_OF(conexant_partitions); ix++)
+		printk("\n\n"
+		       "conexant_partitions[%d].name = %s\n"
+		       "conexant_partitions[%d].offset = 0x%.8x\n"
+		       "conexant_partitions[%d].size = 0x%.8x (%uK)\n",
+		       ix, conexant_partitions[ix].name,
+		       ix, conexant_partitions[ix].offset,
+		       ix, conexant_partitions[ix].size,
+		       conexant_partitions[ix].size / 1024);
+	}
+#endif // CONFIG_MTD_PARTITIONS
+#endif // CONEXANT_DEBUG
+
+	return (result);
+}
+
+void __exit
+conexant_flash_exit(void)
+{
+#ifdef CONFIG_MTD_PARTITIONS
+	del_mtd_partitions(&conexant_mtd);
+#endif
+//	del_mtd_device(&conexant_mtd);
+}
+
+module_init(conexant_flash_init);
+module_exit(conexant_flash_exit);
+
+//MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Geoffrey Espin <espin at idiom.com>");
+MODULE_DESCRIPTION
+    ("MTD driver for Intel 28F160B3 on Conexant board (derived from LART)");
+

From sdeepa69 at yahoo.com  Tue Mar  4 17:07:39 2003
From: sdeepa69 at yahoo.com (Deepa Sivasankarane)
Date: Tue, 4 Mar 2003 14:07:39 -0800 (PST)
Subject: [uClinux-dev] system_call: entry.S - Please reply
Message-ID: <20030304220739.40225.qmail@web80408.mail.yahoo.com>


Hi,

   In m68knommu/platform/5307/entry.S,  return values of system_call/syscall_trace

are in %d0. 

movel %d3,%a0
 jbsr %a0@
 movel %d0,%sp@(LD0)  | save the return value

 

Where does one specify that the return value of all system calls is in %d0 ?

 

Thanx in advance,

regards,

Deepa



---------------------------------
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20030304/e4486f51/attachment.html>

From philwil at earthlink.net  Tue Mar  4 17:17:24 2003
From: philwil at earthlink.net (Phil Wilshire)
Date: Tue, 04 Mar 2003 17:17:24 -0500
Subject: [uClinux-dev] Problems mounting a JFFS2 file system
References: <GGEOICAJEIILOOCMGNKMMEBEDGAA.kjell@cablescan.com>
Message-ID: <3E6525F4.B0187408@earthlink.net>

Hi Kjell
Could you do a 
cat /proc/mtd 
so that we can check your mtd partitions.

jffs2 needs quite a large number of sectors ( 5 for GC )

try the same with regular jffs.


regards
  Phil Wilshire

Kjell Uddeborg wrote:
> 
> Hi,
> 
> I'm having some problems mounting a JFFS2 file system. I'm using uClinux kernel 2.4 on a Motorola M5249C3 board.
> 
> I think that I have all MTD stuff configured correctly and I can erase the device /dev/mtd1 with no problem, see screen dump:
> 
> -----------------------------
> /> eraseall /dev/mtd1
> MTD_open
> MTD_ioctl
>  0raTsiDng_ 6i4 oKicbyttel @
>  1raTsiDng_ 6i4 oKicbyttel @
>  2raTsiDng_ 6i4 oKicbyttel @
>  3raTsiDng_ 6i4 oKicbyttel @
>  4raTsiDng_ 6i4 oKicbyttel @
>  5raTsiDng_ 6i4 oKicbyttel @
>  6raTsiDng_ 6i4 oKicbyttel @
>  7raTsiDng_ 6i4 oKicbyttel @
>  8raTsiDng_ 6i4 oKicbyttel @
>  9raTsiDng_ 6i4 oKicbyttel @
>  araTsiDng_ 6i4 oKicbyttel @
>  braTsiDng_ 6i4 oKicbyttel @
>  craTsiDng_ 6i4 oKicbyttel @
>  draTsiDng_ 6i4 oKicbyttel @
>  eraTsiDng_ 6i4 oKicbyttel @
>  fraTsiDng_ 6i4 oKicbyttel @
> @ raTseDd _10c24l Koibsytee
>   0 -- 100% complete.
> -----------------------------
> 
> As you can see I have all the debug outputs turned on. Looks to me that the command completed successfully.
> 
> The problem occurs when I try to mount the JFFS2 file system, see screen dump:
> 
> -----------------------------
> /> mount -t jffs2 /dev/mtdblock1 /mnt/jffs2
> arena open of 1 failed!
> mount: Mounting /dev/mtdblock1 on /mnt/jffs2 failed: No such device
> pid 28: failed 256
> -----------------------------
> 
> The /dev/mtdblock1 is exists, see this partial listing on /dev:
> 
> -----------------------------
> /> ls -l /dev
> .
> .
> crw-------  1 0        0         90,   0  Jan 01 1970  mtd0
> crw-------  1 0        0         90,   2  Jan 01 1970  mtd1
> crw-------  1 0        0         90,   4  Jan 01 1970  mtd2
> crw-------  1 0        0         90,   6  Jan 01 1970  mtd3
> brw-------  1 0        0         31,   0  Jan 01 1970  mtdblock0
> brw-------  1 0        0         31,   1  Jan 01 1970  mtdblock1
> brw-------  1 0        0         31,   2  Jan 01 1970  mtdblock2
> brw-------  1 0        0         31,   3  Jan 01 1970  mtdblock3
> crw-------  1 0        0         90,   1  Jan 01 1970  mtdr0
> crw-------  1 0        0         90,   3  Jan 01 1970  mtdr1
> crw-------  1 0        0         90,   5  Jan 01 1970  mtdr2
> crw-------  1 0        0         90,   7  Jan 01 1970  mtdr3
> .
> .
> -----------------------------
> 
> If you have any thoughts of what could be causing this problem please send me a note.
> 
> Thanks for your help,
> Kjell Uddeborg
> Cablescan
> 
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org

-- 
SDCS -- System Design & Consulting Services LLC, http://www.sysdcs.com
** Embedded Linux Training **  email me for details  
630 Springhouse Sq., Leesburg VA 20175 t: 703 669 9766 f: 703 669 9768


From sdeepa69 at yahoo.com  Tue Mar  4 18:21:52 2003
From: sdeepa69 at yahoo.com (Deepa Sivasankarane)
Date: Tue, 4 Mar 2003 15:21:52 -0800 (PST)
Subject: [uClinux-dev] system_call: entry.S - Please reply
Message-ID: <20030304232152.83247.qmail@web80407.mail.yahoo.com>


Hi,

   In m68knommu/platform/5307/entry.S,  return values of system_call/syscall_trace

are in %d0. 

movel %d3,%a0
 jbsr %a0@
 movel %d0,%sp@(LD0)  | save the return value

 

Where does one specify that the return value of all system calls is in %d0 ?

 

Thanx in advance,

regards,

Deepa



---------------------------------
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20030304/63135cb8/attachment.html>

From gerg at snapgear.com  Tue Mar  4 18:56:50 2003
From: gerg at snapgear.com (Greg Ungerer)
Date: Wed, 05 Mar 2003 09:56:50 +1000
Subject: [uClinux-dev] Help on ide 5307/ints.c(47): default irq handler
 vec=165 [0xa5]
In-Reply-To: <20030304014854.F047A1D0B0EC0@sm204.163.com>
References: <20030304014854.F047A1D0B0EC0@sm204.163.com>
Message-ID: <3E653D42.2020803@snapgear.com>

Hi Hn

hn wrote:
> 	Is  info like:
>     ../5307/ints.c(47): default irq handler vec=165 [0xa5]
>     a nightmare  that persists on Coldfire families?

Uhh?  I very rarely see this, generally only when I have a bug.
And I deal with a _lot_ of different ColdFire hardware...


>    Similiar discussion has been seen many times, but no explicit answer found.

There is always an answer, and it will depend on exactly which
vector is the problem. I just don't see this discussed very
often here.


> I am using a 5249 board and running uClinux(20020927 version,2.4.x kernel) on it,
> Everything works fine until I type reboot (sash):
> /> reboot
> unmounting /home
> flushing ide devices: hda
> Restarting system.
> 
> ..
> 
> Uniform Multi-Platform E-IDE driver Revision: 6.31
> ide: Assuming 50MHz system bus speed for PIO modes; override with idebus=xx
> ./5307/ints.c(47): default irq handler vec=165 [0xa5]
> ./5307/ints.c(47): default irq handler vec=165 [0xa5]
> ./5307/ints.c(47): default irq handler vec=165 [0xa5]
> ./5307/ints.c(47): default irq handler vec=165 [0xa5]

Looks like the ide driver is enabling the IDE driver interrupt
source before it has done a request_irq() on the vector. Apply
the attached patch to linux-2.4.x/include/asm-m68knommu/ide.h.
It moves the request_irq() call to before enabling the IDE
interrupts.



> But if I reset the board by pressing the reset button of by BDM tools, the system boots up with no problem, what's wrong ?reboot code?or ide driver?
> Thanks .

This will always make all interrupts go away, since it is
forcing a real hardware reset. Normal reboot doesn't do a
hardware reset (at least not on ColdFire platforms), it just
restarts the system from the boot vector.

Regards
Greg


------------------------------------------------------------------------
Greg Ungerer  --  Chief Software Wizard        EMAIL:  gerg at snapgear.com
SnapGear Pty Ltd                               PHONE:    +61 7 3435 2888
825 Stanley St,                                  FAX:    +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia              WEB:   www.SnapGear.com
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ide.patch
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20030305/d1d48b3c/attachment.ksh>

From gerg at snapgear.com  Tue Mar  4 19:24:07 2003
From: gerg at snapgear.com (Greg Ungerer)
Date: Wed, 05 Mar 2003 10:24:07 +1000
Subject: [uClinux-dev] system_call: entry.S - Please reply
In-Reply-To: <20030304232152.83247.qmail@web80407.mail.yahoo.com>
References: <20030304232152.83247.qmail@web80407.mail.yahoo.com>
Message-ID: <3E6543A7.3040308@snapgear.com>

Hi Deepa,

Deepa Sivasankarane wrote:
>    In m68knommu/platform/5307/entry.S,  return values of 
> system_call/syscall_trace
> 
> are in %d0. 
> 
> movel %d3,%a0
>  jbsr %a0@
>  movel %d0,%sp@(LD0)  | save the return value 
> 
> Where does one specify that the return value of all system calls is in %d0 ?

Exactly what are you asking?

It is explicitly coded in this entry.S file and in the libc library
system call stubs that %d0 contains the return value. There is no
single place it is specified. It is a convention that the kernel
and library must follow for it to work.

Regards
Greg



------------------------------------------------------------------------
Greg Ungerer  --  Chief Software Wizard        EMAIL:  gerg at snapgear.com
SnapGear Pty Ltd                               PHONE:    +61 7 3435 2888
825 Stanley St,                                  FAX:    +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia              WEB:   www.SnapGear.com



From HenrySimmons17 at netzero.net  Tue Mar  4 22:09:25 2003
From: HenrySimmons17 at netzero.net (HenrySimmons17)
Date: Tue, 4 Mar 2003 19:09:25 -0800
Subject: [uClinux-dev] UCLINUX for PALM
References: <Pine.GSO.4.33.0302111240390.25930-100000@compserv1> <015801c2d222$ca8f38a0$ffc5fea9@henry133> <3E50444D.4010600@tbc.net> <004901c2d64e$13223fc0$ffc5fea9@henry133> <3E50E9DE.7050801@tbc.net> <000201c2d6d6$0d03e660$ffc5fea9@henry133> <3E524F5D.8020206@tbc.net> <000201c2d770$e5711e60$ffc5fea9@henry133> <3E5EB086.1070108@tbc.net> <000201c2dee8$065974a0$ffc5fea9@henry133> <3E5FE502.1060106@tbc.net> <000201c2dfc2$762ceb60$ffc5fea9@henry133> <3E61743D.6000901@tbc.net> <000201c2e074$63483560$ffc5fea9@henry133> <3E6192D6.60204@tbc.net> <002a01c2e082$999a6d00$ffc5fea9@henry133> <3E6274EB.7020605@tbc.net> <000201c2e200$dcab81e0$ffc5fea9@henry133> <3E64C695.10806@tbc.net>
Message-ID: <000201c2e2c4$cc1fd1e0$ffc5fea9@henry133>

Hello Michael...
> Henry,
> I rechecked, and all is correct, but still can't boot. I've made the
> following observations though:
> in vendors/3com/palm-loader/Palmloader.c
> asm volatile (" movew #0x068f, 0xfffff116")
> PDA locked, hard reset to restore, memory lost
This is the one you want set. It is the same as ucsimm.
Take a look at ucsimm in both vendors/3com & platform/M68EZ328
directories The PDA does not lockup. When uClinux begins
to run/trying to run it then takes control of the microprocessor. The
microprocessor
is no longer under the PalmOS control. When ever you can do
a soft reset then the microprocessor continues to
remain under the PalmOS control & uClinux has not not gotten to start_kernel
in linux/init/main.c. You should at lease see the penguin on the Palm.
> Results at 0x3a81 (from VZ) look the most promising so far... Is there a
> range of memory locations I can try in Palmloader.c? Any suggestions?
No you set it according to the user manual for a specific memory.
That is what your PalmOS did..You are very close.The error is in either
PalmLoader.c or crt0_ram.S or ram.ld or your configuration.
E-mail me HenrySimmons17 at netzero.net  the 4 files:
PalmLoader.c, 3com/PalmIIIx/config.linux, crt0_ram.S, & ram.ld
I will rebuild my dist. and look at you files.
Henry






From manigandanv at myw.ltindia.com  Tue Mar  4 23:37:27 2003
From: manigandanv at myw.ltindia.com (Manigandan.V)
Date: Wed, 5 Mar 2003 10:07:27 +0530
Subject: [uClinux-dev] Boot from Rom Patch + Memory problems
References: <APIMNIBDCGHMOBAA@mailcity.com>
Message-ID: <005801c2e2d0$ed2cb400$1e06a8c0@emsysdom>

Well,your rom.ld is almost right except data section .
you have to add   AT(__data_rom_start) at the begining of data section (see
changes below)

Regards,
Mani

> Here is the rom.ld
>
> Thanks.
>
> MEMORY {
> rom    : ORIGIN = 0xffe40000, LENGTH = 0x1c0000
> ram    : ORIGIN = 0x20000, LENGTH = 0x3e0000
> }
>
> SECTIONS {
>
> .text : {
> _stext = . ;
>         *(.text)
> . = ALIGN(0x4) ;
> *(.text.*)
> . = ALIGN(0x4) ;
> *(.exitcall.exit)
> . = ALIGN(0x4) ;
> *(.kstrtab)
>
> . = ALIGN(16);          /* Exception table              */
> __start___ex_table = . ;
> *(__ex_table)
> __stop___ex_table = . ;
>
> __start___ksymtab = . ;  /* Kernel symbol table          */
> *(__ksymtab)
> __stop___ksymtab = . ;
>
> . = ALIGN(0x4);
> _etext = . ;
> __data_rom_start = . ;
> } > rom
>
> .data : AT(__data_rom_start) { /******Add this *******/
> _sdata = ALIGN(0x4) ;
> __data_start = . ;
>
> . = ALIGN(0x4) ;
> *(.rodata)
> . = ALIGN(0x4) ;
>         *(.data)
> . = ALIGN(0x4) ;
> *(.data.*)
>
> . = ALIGN(0x4);
> __setup_start = . ;
> *(.setup.init)
> __setup_end = . ;
>
> . = ALIGN(0x4);
> __initcall_start = .;
> *(.initcall.init)
> __initcall_end = . ;
>
> . = ALIGN(0x2000) ;
>         *(.data.init_task)
> . = ALIGN(0x2000) ;
>
> _edata = ALIGN(0x4) ;
> } > ram
>
> .bss : {
> _sbss = ALIGN(0x4) ;
> *(.bss)
> . = ALIGN(0x4) ;
> *(COMMON)
> _ebss = ALIGN(0x4) ;
> _end = ALIGN(0x4) ;
> } > ram
> }
>
>
>
> --
>
> On Tue, 4 Mar 2003 16:11:34
>  Manigandan.V wrote:
> >I guess that your rom.ld is having problem .Can you post your rom.ld
> >
> >> I've patched uClinux with the boot from rom patch. However when I've
> >compiled the kernel I've get the following error:
> >> m68k-elf-objcopy -O binary /uClinux-dist/linux-2.4.x/linux \
> >>   /uClinux-dist/images/linux.bin
> >> BFD: Warning: Writing section `.text' to huge (ie negative) file offset
> >0xffe200
> >> 00.
> >> m68k-elf-objcopy: /uClinux-dist/images/linux.bin: File truncated
> >>
> >> What is going wrong here?
> >
> >Regards,
> >Mani
> >
> >
> >_______________________________________________
> >uClinux-dev mailing list
> >uClinux-dev at uclinux.org
> >http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> >This message was resent by uclinux-dev at uclinux.org
> >
>
>
> _____________________________________________________________
> Get 25MB, POP3, Spam Filtering with LYCOS MAIL PLUS for $19.95/year.
> http://login.mail.lycos.com/brandPage.shtml?pageId=plus&ref=lmtplus
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org



From gerg at snapgear.com  Wed Mar  5 00:59:54 2003
From: gerg at snapgear.com (Greg Ungerer)
Date: Wed, 05 Mar 2003 15:59:54 +1000
Subject: [uClinux-dev] uClinux-dist-20030305 released
Message-ID: <3E65925A.1090102@snapgear.com>

Hi All,

The latest uClinux-dist package is now officially released.
You can get it at the usual place:

   http://www.uclinux.org/pub/uClinux/dist

You can also get it using CVS from cvs.uclinux.org.

It includes:

. linux-2.4.20 kernel
. linux-2.0.39 kernel
. uClibc-0.9.19
. uC-libc (old)
. glibc (only for VM processor targets)
. ~150 application packages

Direct support for more than a dozen processor families,
including m68k (683xx), Motorola ColdFire, ARM (from many
vendors), NEC v850, Hitachi H8, OPENrisc, i960, sparc (LEON).
And also now build support for full VM processors such as
x86 (AMD SC520, VIA C3), Hitachi (SH3, SH4) and Intel XSCALE
(IXP425).

There is now over 50 pre built configurations for boards.
Also I have started a set of HOWTO documents in the top
level Documentation directory that describe for each board
type how to load and run code.

Please send any bug reports and patches...

Enjoy!

Regards
Greg


------------------------------------------------------------------------
Greg Ungerer  --  Chief Software Wizard        EMAIL:  gerg at snapgear.com
SnapGear Pty Ltd                               PHONE:    +61 7 3435 2888
825 Stanley St,                                  FAX:    +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia              WEB:   www.SnapGear.com



From louiss at cat.co.za  Wed Mar  5 01:56:05 2003
From: louiss at cat.co.za (Louis Swart)
Date: Wed, 5 Mar 2003 08:56:05 +0200
Subject: [uClinux-dev] Kernel compile stopped working.
Message-ID: <028f01c2e2e4$4b4db580$1946a8c0@cat.co.za>

My kernel compile stopped working, now only gives me the error below:

[root at Linux-Test-PC1 uClinux-dist]# make dep
make ARCH= CROSS_COMPILE= -C linux-2.0.x dep
make[1]: Entering directory `/usr/src/uClinux-dist/linux-2.0.x'
Makefile:198: arch//Makefile: No such file or directory
make[1]: *** No rule to make target `arch//Makefile'.  Stop.
make[1]: Leaving directory `/usr/src/uClinux-dist/linux-2.0.x'
make: *** [dep] Error 2
[root at Linux-Test-PC1 uClinux-dist]# 

I tried removing the uCLinux and unpacking it again but it did not help.

What am I to do?

Thanks,

Louis.




From heiko.degenhardt at sentec-elektronik.de  Wed Mar  5 01:24:37 2003
From: heiko.degenhardt at sentec-elektronik.de (Heiko Degenhardt)
Date: Wed, 5 Mar 2003 07:24:37 +0100
Subject: [uClinux-dev] FrameBuffer for MCF5272
In-Reply-To: <004601c2e26e$8ec2db90$e10106c0@Massimo>; from m.calo@ctsgroup.it on Tue, Mar 04, 2003 at 05:53:18PM +0100
References: <004601c2e26e$8ec2db90$e10106c0@Massimo>
Message-ID: <20030305072437.A20908@www2.sentec-elektronik.de>

Hi Cal?, 

* On Tue, Mar 04, 2003 at 05:53:18PM +0100, Cal? Massimo wrote:
>     does anybody have any information about using framebuffer on a
> MCF5272 based board?

yes. I've made a framebuffer driver (uClinux kernel 2.4.x, MCF5272
based board) for an Epson S1D13706. It works, actually, so I can
play ntetris on microwindows now. ;)

I haven't really finished that work, currently. I have to check
everything again, clean up the source, document it etc. This may
take me some weeks, because I currently have to do some other stuff.

If you are interested, and can't wait until I get everything into
cvs, I could send you my changed files.

Rgds.
Heiko.



From heiko.degenhardt at sentec-elektronik.de  Wed Mar  5 01:34:12 2003
From: heiko.degenhardt at sentec-elektronik.de (Heiko Degenhardt)
Date: Wed, 5 Mar 2003 07:34:12 +0100
Subject: [uClinux-dev] Problems with beta uClinux-dist?
In-Reply-To: <20030304101136.GA5048@beast.internal.moreton.com.au>; from davidm@snapgear.com on Tue, Mar 04, 2003 at 08:11:36PM +1000
References: <20030304092009.C16963@www2.sentec-elektronik.de> <20030304101136.GA5048@beast.internal.moreton.com.au>
Message-ID: <20030305073412.B20908@www2.sentec-elektronik.de>

Hi David, 

* On Tue, Mar 04, 2003 at 08:11:36PM +1000, David McCullough wrote:
> Jivin Heiko Degenhardt lays it down ...
> > But if I try to start it, the process stops after
> > "Freeing unused kernel memory: 24k freed (0xd0000 - 0xd5000)"
> > (there is no error message or something. It just "hangs" there).
...
> > 
> > If I debug the start process with m68k-bdm-elf-gdb I see that it
> > somehow hangs in "schedule" (I didn't debug in detail, actually,
> > so that is just a "fist shot").
> 
> This is right where is runs init.

ack.

> Turn on DEBUG in linux-2.4.x/fs/binfmt_flat.c so you can see when
> it runs various programs.

Ok, I'll do that.

> You should check that the init/console support is turned on in the
> user config.

I think it is, because I compile with the default settings for
the M5272C3. But, shure, I check that again.

> > Greg told me that he can compile and run images for the M5272C3
> > without any problems, so I think I may have an alignment
> > problem?
> 
> Unlikely, but possible.  DEBUG in the flat loader will help to
> work out what is failing.

Ok.

> Greg tests and runs on all the Mot boards so I would be confident
> that it runs on his board ;-)

I'm shure he does!
My problem is: If I download the same dist, use the same toolchain,
compile with the same (default) values for the board, but get
different results, there is definitely a problem somewhere here.
So I wanted to ask some others with the M5272C3 to check if they
have the problem, too. If they don't have, I can be shure that
it is my working environment.

> > An indication for that might be the warning "process.c:50:
> > warning: alignment of `init_task_union' is greater than maximum
> > object file alignment. Using 16." in my errs file.
> 
> This is normal and happens on all m68k builds to my knowledge.

Oh, ok. Thanks for that info!

> > So I want to ask if someone of you with an M5272C3 board could
> > test that dist, and see if there are any problems?  Could a
> > wrong alignment cause such behavior?
> 
> Check the console setting and get back to us with the DEBUG from
> the flat loader and we'll see what we can find :-)

:)
Ok, thanks for the help, David! I'll try that out now, and be back
later.

Rgds.
Heiko.



From heiko.degenhardt at sentec-elektronik.de  Wed Mar  5 03:01:34 2003
From: heiko.degenhardt at sentec-elektronik.de (Heiko Degenhardt)
Date: Wed, 5 Mar 2003 09:01:34 +0100
Subject: [uClinux-dev] Kernel compile stopped working.
In-Reply-To: <028f01c2e2e4$4b4db580$1946a8c0@cat.co.za>; from louiss@cat.co.za on Wed, Mar 05, 2003 at 08:56:05AM +0200
References: <028f01c2e2e4$4b4db580$1946a8c0@cat.co.za>
Message-ID: <20030305090134.A21206@www2.sentec-elektronik.de>

Hi Louis, 

* On Wed, Mar 05, 2003 at 08:56:05AM +0200, Louis Swart wrote:
> My kernel compile stopped working, now only gives me the error below:
> 
> [root at Linux-Test-PC1 uClinux-dist]# make dep
> make ARCH= CROSS_COMPILE= -C linux-2.0.x dep
> make[1]: Entering directory `/usr/src/uClinux-dist/linux-2.0.x'
> Makefile:198: arch//Makefile: No such file or directory
> make[1]: *** No rule to make target `arch//Makefile'.  Stop.
> make[1]: Leaving directory `/usr/src/uClinux-dist/linux-2.0.x'
> make: *** [dep] Error 2
> [root at Linux-Test-PC1 uClinux-dist]# 

cauld you be a bit more specific? What distribution are you using?
What did you do after unpacking it? Does this happen with a fresh
unpacked uClinux-dist? The ARCH and CROSS_COMPILE build variables
are not set.
Did you do a "make menuconfig" (or "make xconfig") and choose your
target board?

Rgds.
Heiko.


From m.calo at ctsgroup.it  Wed Mar  5 03:26:55 2003
From: m.calo at ctsgroup.it (=?iso-8859-1?Q?Cal=F2_Massimo?=)
Date: Wed, 5 Mar 2003 09:26:55 +0100
Subject: [uClinux-dev] FrameBuffer for MCF5272
References: <004601c2e26e$8ec2db90$e10106c0@Massimo> <20030305072437.A20908@www2.sentec-elektronik.de>
Message-ID: <000a01c2e2f0$fb6ba740$e10106c0@Massimo>

Hi Heiko,

    please send me your changed files, It would be very nice to see what you
did.

Can you send me some information obout the display hardware and how you
integretd it with MCF5272 ?

My e-mail is : m.calo at ctsgroup.it

Thanks!

Massimo.

----- Original Message -----
From: "Heiko Degenhardt" <heiko.degenhardt at sentec-elektronik.de>
To: <uclinux-dev at uclinux.org>
Sent: Wednesday, March 05, 2003 7:24 AM
Subject: Re: [uClinux-dev] FrameBuffer for MCF5272


> Hi Cal?,
>
> * On Tue, Mar 04, 2003 at 05:53:18PM +0100, Cal? Massimo wrote:
> >     does anybody have any information about using framebuffer on a
> > MCF5272 based board?
>
> yes. I've made a framebuffer driver (uClinux kernel 2.4.x, MCF5272
> based board) for an Epson S1D13706. It works, actually, so I can
> play ntetris on microwindows now. ;)
>
> I haven't really finished that work, currently. I have to check
> everything again, clean up the source, document it etc. This may
> take me some weeks, because I currently have to do some other stuff.
>
> If you are interested, and can't wait until I get everything into
> cvs, I could send you my changed files.
>
> Rgds.
> Heiko.
>
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org



From thierry.strudel at st.com  Wed Mar  5 04:10:24 2003
From: thierry.strudel at st.com (Thierry STRUDEL)
Date: Wed, 05 Mar 2003 10:10:24 +0100
Subject: [uClinux-dev] Pbs running busybox
Message-ID: <3E65BF00.3010207@st.com>

Hello,

I've ported Linux 2.5.55 to a home made MMU-less platform, and now I'm having problems to run busybox:

busybox has been compiled using the uCLibc. Init does the execve of /bin/sh which appends to be msh.
Everything works fine up to this point, I'm able to enter a command (ls) so msh is forking using the `vfork' syscall (called in the `forkexec' function), the child process is created and scheduled so we come back in the son context on the father stack.
But the child is not doing the `execve' call, then the child is doing a couple of syscalls and the calls the `rexecve' function which then calls `execve'. So the child is changing the father stack ! The `execve' is done, ls runs ok and the child exit but when the father comes back it returns from the vfork frame and then take the return address from the stack and return after the `rexecve' done by the child !! which ends in exit :-(

What is wrong in my implementation, how things does work on other platform running busybox ?

Thanks for your help

Thierry STRUDEL



From m.calo at ctsgroup.it  Wed Mar  5 04:23:13 2003
From: m.calo at ctsgroup.it (=?iso-8859-1?Q?Cal=F2_Massimo?=)
Date: Wed, 5 Mar 2003 10:23:13 +0100
Subject: [uClinux-dev] FrameBuffer for MCF5272
References: <004601c2e26e$8ec2db90$e10106c0@Massimo> <20030305072437.A20908@www2.sentec-elektronik.de>
Message-ID: <002501c2e2f8$d8bc48a0$e10106c0@Massimo>

Hi Heiko,

    can you also tell me how much does your hardware (S1D13706 + display)
cost ?

Which display are you using ?

Thanks !

Massimo

----- Original Message -----
From: "Heiko Degenhardt" <heiko.degenhardt at sentec-elektronik.de>
To: <uclinux-dev at uclinux.org>
Sent: Wednesday, March 05, 2003 7:24 AM
Subject: Re: [uClinux-dev] FrameBuffer for MCF5272


> Hi Cal?,
>
> * On Tue, Mar 04, 2003 at 05:53:18PM +0100, Cal? Massimo wrote:
> >     does anybody have any information about using framebuffer on a
> > MCF5272 based board?
>
> yes. I've made a framebuffer driver (uClinux kernel 2.4.x, MCF5272
> based board) for an Epson S1D13706. It works, actually, so I can
> play ntetris on microwindows now. ;)
>
> I haven't really finished that work, currently. I have to check
> everything again, clean up the source, document it etc. This may
> take me some weeks, because I currently have to do some other stuff.
>
> If you are interested, and can't wait until I get everything into
> cvs, I could send you my changed files.
>
> Rgds.
> Heiko.
>
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org



From louiss at cat.co.za  Wed Mar  5 05:19:33 2003
From: louiss at cat.co.za (Louis Swart)
Date: Wed, 5 Mar 2003 12:19:33 +0200
Subject: [uClinux-dev] Kernel compile stopped working.
References: <028f01c2e2e4$4b4db580$1946a8c0@cat.co.za> <20030305090134.A21206@www2.sentec-elektronik.de>
Message-ID: <029c01c2e300$b9d5b1d0$1946a8c0@cat.co.za>

I think I see the problem, still not sure how to fix it?
After "make menuconfig" I see the following:

*** End of Linux kernel configuration.
bash: Saving: command not found
<-------------------------------
*** Check the top-level Makefile for additional configuration.
*** Next, you must run 'make dep'.

config/setconfig: line 216: ln: command not found
<-------------------------------
[root at Linux-Test-PC1 uClinux-dist]#

It seems that the path to the commands are lost.
How do I fix this?

I wrote the rest before I saw what I wrote above, you may ignore it.
----------------------------------------------------------------------------
--------------
> What distribution are you using?
cd /
tar xvzf /my_path/m68k-elf-tools-20020410.tar.gz

cd /usr/src/
tar xvzf /my_path/uClinux-dist-20020927.tar.gz

I believe this is correct and is all that is required?
----------------------------------------------------------------------------
--------------
> What did you do after unpacking it?
Did a "make xconfig".
(Motorola/M5272C3) Vendor/Product
(linux-2.4.x) Kernel Version
(uC-libc) Libc Version
[*] Default all settings (lose changes)
----------------------------------------------------------------------------
--------------
> Does this happen with a fresh unpacked uClinux-dist?
Yes, I deleted it after it stopped working and unpacked a new one, still the
same result.
Also reboot ed the box. Also deleted, I think part of, the tool chain and
unpacked it again.
----------------------------------------------------------------------------
--------------
> The ARCH and CROSS_COMPILE build variables
> are not set.
OK, why would they get lost?
Who sets them up in the first place?
How do I set them again?
----------------------------------------------------------------------------
--------------
> Did you do a "make menuconfig" (or "make xconfig") and choose your
> target board?
Yes, tried both.
----------------------------------------------------------------------------
--------------

----- Original Message -----
From: "Heiko Degenhardt" <heiko.degenhardt at sentec-elektronik.de>
To: <uclinux-dev at uclinux.org>
Sent: Wednesday,05 March 2003 10:01
Subject: Re: [uClinux-dev] Kernel compile stopped working.


> Hi Louis,
>
> * On Wed, Mar 05, 2003 at 08:56:05AM +0200, Louis Swart wrote:
> > My kernel compile stopped working, now only gives me the error below:
> >
> > [root at Linux-Test-PC1 uClinux-dist]# make dep
> > make ARCH= CROSS_COMPILE= -C linux-2.0.x dep
> > make[1]: Entering directory `/usr/src/uClinux-dist/linux-2.0.x'
> > Makefile:198: arch//Makefile: No such file or directory
> > make[1]: *** No rule to make target `arch//Makefile'.  Stop.
> > make[1]: Leaving directory `/usr/src/uClinux-dist/linux-2.0.x'
> > make: *** [dep] Error 2
> > [root at Linux-Test-PC1 uClinux-dist]#
>
> cauld you be a bit more specific? What distribution are you using?
> What did you do after unpacking it? Does this happen with a fresh
> unpacked uClinux-dist? The ARCH and CROSS_COMPILE build variables
> are not set.
> Did you do a "make menuconfig" (or "make xconfig") and choose your
> target board?
>
> Rgds.
> Heiko.
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org
>



From davidm at snapgear.com  Wed Mar  5 05:46:10 2003
From: davidm at snapgear.com (David McCullough)
Date: Wed, 5 Mar 2003 20:46:10 +1000
Subject: [uClinux-dev] Pbs running busybox
In-Reply-To: <3E65BF00.3010207@st.com>
References: <3E65BF00.3010207@st.com>
Message-ID: <20030305104610.GA27269@beast.internal.moreton.com.au>

Jivin Thierry STRUDEL lays it down ...
> Hello,
> 
> I've ported Linux 2.5.55 to a home made MMU-less platform, and now I'm 
> having problems to run busybox:
> 
> busybox has been compiled using the uCLibc. Init does the execve of /bin/sh 
> which appends to be msh.
> Everything works fine up to this point, I'm able to enter a command (ls) so 
> msh is forking using the `vfork' syscall (called in the `forkexec' 
> function), the child process is created and scheduled so we come back in 
> the son context on the father stack.
> But the child is not doing the `execve' call, then the child is doing a 
> couple of syscalls and the calls the `rexecve' function which then calls 
> `execve'. So the child is changing the father stack ! The `execve' is done, 
> ls runs ok and the child exit but when the father comes back it returns 
> from the vfork frame and then take the return address from the stack and 
> return after the `rexecve' done by the child !! which ends in exit :-(

Try using the minix shell from the uClinux-dist,  it's in user/sh.
I haven't played with the busybox version but I know a lot of things
have been fixed in the dist version.

> What is wrong in my implementation, how things does work on other platform 
> running busybox ?

A lot of platforms run the sash shell.  It is a great shell to get
started with as it is so simple.  Perhaps you should give it a go,

Cheers,
Davidm

-- 
David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
davidm at snapgear.com  Fx: +61 7 3891 3630  Custom Embedded Solutions + Security


From heiko.degenhardt at sentec-elektronik.de  Wed Mar  5 05:48:51 2003
From: heiko.degenhardt at sentec-elektronik.de (Heiko Degenhardt)
Date: Wed, 5 Mar 2003 11:48:51 +0100
Subject: [uClinux-dev] FrameBuffer for MCF5272
In-Reply-To: <000a01c2e2f0$fb6ba740$e10106c0@Massimo>; from m.calo@ctsgroup.it on Wed, Mar 05, 2003 at 09:26:55AM +0100
References: <004601c2e26e$8ec2db90$e10106c0@Massimo> <20030305072437.A20908@www2.sentec-elektronik.de> <000a01c2e2f0$fb6ba740$e10106c0@Massimo>
Message-ID: <20030305114851.A21779@www2.sentec-elektronik.de>

Hi Cal?, 

* On Wed, Mar 05, 2003 at 09:26:55AM +0100, Cal? Massimo wrote:
> please send me your changed files, It would be very nice to
> see what you did.

I'll send you the information off-list.

Rgds.
Heiko.



From nrobles at robotiker.es  Wed Mar  5 06:51:51 2003
From: nrobles at robotiker.es (Natalia Robles Lopez)
Date: Wed, 5 Mar 2003 12:51:51 +0100
Subject: [uClinux-dev] Cross-compiling GSMLIB for ARM7TDMI
Message-ID: <OFB529D8BF.1D0A7E35-ONC1256CE0.00408FA0@robotiker.es>

Hello,

I need to cross-complie the libraries gsmlib for my target (ARM7TDMI),
Has anyone suceed in this aim or at least tried??
I would thank you any kind of help. Which are the modifications I have to
do in the Makefile??

Thanks in advance,
Natalia




Natalia Robles Lopez
Dpto. de Wireless / Wireless Dept.
ROBOTIKER, Corporaci?n Tecnol?gica TECNALIA.
Parque Tecnol?gico, Edificio 202. E-48170 Zamudio (Bizkaia) (SPAIN).
Tel:  (34) 94 600 22 66. Fax: (34) 94 600 22 99
nrobles at robotiker.es, www.robotiker.com

"Este correo electr?nico contiene informaci?n privada que puede estar
legalmente protegida, parcial o totalmente. Es s?lo para uso del
destinatario al que est? dirigido. Si ha recibido este mensaje por error,
le rogamos que lo notifique al remitente del email y que adem?s borre de su
sistema el mensaje as? como todas sus copias, incluyendo las posibles
copias del mismo en su disco duro, y se abstenga de usar, revelar,
distribuir a terceros, imprimir o copiar ninguna de las partes de este
mensaje".
"Mezu elektroniko honek informazio pribatua du, partzialki edo osorik legez
babestuta egon daitekeena. Bidali nahi zaion hartzaileak erabiltzeko
bakarrik da. Mezu hau hutsegite baten ondorioz jaso baduzu, mesedez,
mezuaren igorleari jakinaraztea eta mezua eta horren kopia guztiak
ezabatzea eskatzen dizugu, disko gogorrean izan ditzakezunak barne. Eta,
orobat, ez erabili mezu honen zatirik, ez eta erakutsi, beste pertsona
batzuei banatu, inprimatu edo berridatzi ere".
"This e-mail contains proprietary information some or all of which may be
legally protected. It is for sole use of the intended recipient only. If
you have received this message by mistake, you are requested to notify the
e-mail sender and erase both the message and any copies from your system,
including hard disk copies.  You are further requested to refrain from
using, distributing to third parties, printing or making copies of any
parts of this message".




From Mile.Davidovic at micronasnit.com  Wed Mar  5 08:16:54 2003
From: Mile.Davidovic at micronasnit.com (Mile Davidovic)
Date: Wed, 5 Mar 2003 14:16:54 +0100
Subject: [uClinux-dev] elf2flt and mips nommu again
Message-ID: <20030305141654.3e25e0ad.Mile.Davidovic@micronasnit.com>

Hi all

I am trying to port elf2flt for MIPS without MMU but I have trouble 
with general picture about handling relocations. 

Mr. Qiulm from xipotech said that if use PIC code then R_MIPS_LO16, R_MIPS_HI16 and R_MIPS_26 won't show up. 

My question is: is it enough to have DOPIC=y in .config file uclibc?
Dumped crt0.o saw that we still have R_MIPS_HI16, R_MIPS_LO16 and R_MIPS_26 relocations. 

Disassembly of section .text:
00000000 <__start>:
   0:	0000f821 	move	ra,zero
   4:	8fa40000 	lw	a0,0(sp)
   8:	27a50004 	addiu	a1,sp,4
   c:	24860001 	addiu	a2,a0,1
  10:	00063080 	sll	a2,a2,0x2
  14:	00c53020 	add	a2,a2,a1
  18:	3c070000 	lui	a3,0x0
			18: R_MIPS_HI16	_init
  1c:	24e70000 	addiu	a3,a3,0
			1c: R_MIPS_LO16	_init
  20:	27bdffe8 	addiu	sp,sp,-24
  24:	3c020000 	lui	v0,0x0
			24: R_MIPS_HI16	_fini
  28:	24420000 	addiu	v0,v0,0
			28: R_MIPS_LO16	_fini
  2c:	0c000000 	jal	0 <__start>
			2c: R_MIPS_26	__uClibc_main
  30:	afa20010 	sw	v0,16(sp)
  34:	27bd0018 	addiu	sp,sp,24

When I set -Wa,-KPIC in compiler command line options, to pass assembler -KPIC, I got next crt0 dump:
00000000 <__start>:
   0:	0000f821 	move	ra,zero
   4:	8fa40000 	lw	a0,0(sp)
   8:	27a50004 	addiu	a1,sp,4
   c:	24860001 	addiu	a2,a0,1
  10:	00063080 	sll	a2,a2,0x2
  14:	00c53020 	add	a2,a2,a1
  18:	8f870000 	lw	a3,0(gp)
			18: R_MIPS_GOT16	_init
  1c:	27bdffe8 	addiu	sp,sp,-24
  20:	8f820000 	lw	v0,0(gp)
			20: R_MIPS_GOT16	_fini
  24:	00000000 	nop
  28:	afa20010 	sw	v0,16(sp)
  2c:	8f990000 	lw	t9,0(gp)
			2c: R_MIPS_CALL16	__uClibc_main
  30:	00000000 	nop
  34:	0320f809 	jalr	t9
  38:	00000000 	nop
  3c:	27bd0018 	addiu	sp,sp,24

When I set -Wa,--mebedded-pic or -mebedded-pic I got same result:
00000000 <__start>:
   0:	0000f821 	move	ra,zero
   4:	8fa40000 	lw	a0,0(sp)
   8:	27a50004 	addiu	a1,sp,4
   c:	24860001 	addiu	a2,a0,1
  10:	00063080 	sll	a2,a2,0x2
  14:	00c53020 	add	a2,a2,a1
  18:	27870000 	addiu	a3,gp,0
			18: R_MIPS_GPREL16	_init
  1c:	27bdffe8 	addiu	sp,sp,-24
  20:	27820000 	addiu	v0,gp,0
			20: R_MIPS_GPREL16	_fini
  24:	0411ffff 	bal	24 <__start+0x24>
			24: R_MIPS_GNU_REL16_S2	__uClibc_main
  28:	afa20010 	sw	v0,16(sp)
  2c:	27bd0018 	addiu	sp,sp,24

My question are: what combination is correct? Do I have to recompile
all uclibc with these options? 

Another question is: what relocations ld-elf2flt script handle?

>From xipotech site I downloaded elf2flt. In this elf2flt I saw sample
of R_MIPS_32 relocation:

case R_MIPS_32:
	//sym_vma = bfd_section_vma(abs_bfd, sym_section);
	//section_vma = sym_vma;
	sym_vma = section_vma;
	relocation_needed = 1;
	break;

from mr. YH Lin <yhlin at viosoft.com> I saw:
case R_MIPS_32:
	relocation_needed = 1;
	sym_vma = bfd_section_vma(abs_bfd, sym_section);
	sym_addr += ((sym_vma + q->addend) & q->howto->dst_mask);
	break;

In MIPS ABI for R_MIPS_32 calculation is: S + A, but I am confused
with & q->howto->dst_mask part;

>From MIPS abi I read something like this (page 81), for R_MIPS_26:

if symboll is local then  (((A<<2) | (P & 0xf0000000) + S) >> 2
if symboll is extern then (sign_extend(A<<2) + S) >> 2

where is A addend and P represents the place (section offset or address) of the storage unit being relocated (computed using r_offset).

That relocation exist in crt0.o for 
My questions are:
How I can determine is symbol local or extern?
How I can calculate P?

TIA
Mile



From heiko.degenhardt at sentec-elektronik.de  Wed Mar  5 07:33:37 2003
From: heiko.degenhardt at sentec-elektronik.de (Heiko Degenhardt)
Date: Wed, 5 Mar 2003 13:33:37 +0100
Subject: [uClinux-dev] Kernel compile stopped working.
In-Reply-To: <029c01c2e300$b9d5b1d0$1946a8c0@cat.co.za>; from louiss@cat.co.za on Wed, Mar 05, 2003 at 12:19:33PM +0200
References: <028f01c2e2e4$4b4db580$1946a8c0@cat.co.za> <20030305090134.A21206@www2.sentec-elektronik.de> <029c01c2e300$b9d5b1d0$1946a8c0@cat.co.za>
Message-ID: <20030305133337.A22060@www2.sentec-elektronik.de>

Hi Louis, 

* On Wed, Mar 05, 2003 at 12:19:33PM +0200, Louis Swart wrote:
> I think I see the problem, still not sure how to fix it?
> After "make menuconfig" I see the following:
> 
> *** End of Linux kernel configuration.
> bash: Saving: command not found

hm. Sounds strange.
Is it possible that the line endings of your Makefiles etc. could be
wrong? That can happen if you transfer them via FTP in the wrong
mode or copy them from a Windows system?

> *** Check the top-level Makefile for additional configuration.
> *** Next, you must run 'make dep'.
> 
> config/setconfig: line 216: ln: command not found

There seem to be problems with your path.
Do an "echo $PATH". It should look as

/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games

or something.

> [root at Linux-Test-PC1 uClinux-dist]#
> 
> It seems that the path to the commands are lost.
> How do I fix this?

In a bash shall you could do

export PATH=/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games

and try again.

Then copy the toolchain to / and unpack it:

cp m68k-elf-tools-20020410.tar.gz /
cd /
tar -zxvf m68k-elf-tools-20020410.tar.gz

Then you go to your working directory, and unpack the dist:

cd
cd uClinux
(remove the old one with "rm -rf uClinux-dist")
tar -zxvf uClinux-dist-20020927.tar.gz

Then build a new image:
cd uClinux-dist
make menuconfig
(select the M5272C3 and leave everything else at the default
values)
make dep
make

If that doesn't fix the problem, please email me the errors
and I'll try to help you further.

Rgds.
Heiko.



From richard.klingler at violasystems.com  Wed Mar  5 09:01:14 2003
From: richard.klingler at violasystems.com (Richard Klingler)
Date: Wed,  5 Mar 2003 16:01:14 +0200
Subject: [uClinux-dev] Kernel compile stopped working.
In-Reply-To: <029c01c2e300$b9d5b1d0$1946a8c0@cat.co.za>
Message-ID: <r01050400-1024-EDB4F81E4F1211D78E5800039387ACB6@[10.0.1.2]>

> config/setconfig: line 216: ln: command not found
> <-------------------------------
> [root at Linux-Test-PC1 uClinux-dist]#
> 

Hmm...any reason to be root for compiling?

Normally there are two different PATH sets for regular
user and for root...


What does "which ln" tells you?


Rick


Richard Klingler             mail: richard.klingler at violasystems.com
Viola Systems Ltd.           http://www.violasystems.com/
Lemmink?isenkatu 32          phon: +358 (0)201 226 226
20520 Turku, Finland         mobile: +358 (0)40 748 4711


From masterkristof at yahoo.com  Wed Mar  5 09:34:14 2003
From: masterkristof at yahoo.com (Kristof Bruyninckx)
Date: Wed, 5 Mar 2003 06:34:14 -0800 (PST)
Subject: [uClinux-dev] Toolchain error
In-Reply-To: <r01050400-1024-EDB4F81E4F1211D78E5800039387ACB6@[10.0.1.2]>
Message-ID: <20030305143414.4346.qmail@web11005.mail.yahoo.com>

hi,

Whe I recompile my toolchain I'm getting the following
message in stage 3:
m68k-elf-gcc command not found
It compiles further without any error's but this
mighrt be the reason that when I now compile a default
kernel in gives the following error's.(see
attachement). Does anyone know what could be wrong
when I compile my toolchain??
Any advice or tips are very welkom.

yours truly and hoping for a reply

kristof

__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: errordefault.txt
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20030305/c5d8b989/attachment.txt>

From roope.anttinen at indagon.com  Wed Mar  5 10:15:19 2003
From: roope.anttinen at indagon.com (Roope Anttinen)
Date: 05 Mar 2003 17:15:19 +0200
Subject: [uClinux-dev] probelm with BIG numbers
Message-ID: <1046877322.1921.7.camel@tossu>

Hi,

some code here...

unsigned long long int foo = 83;
printf("16: %llu", foo<<16);
printf("24: %llu", foo<<24);
printf("30: %llu", foo<<30);
printf("32: %llu", foo<<32);

that results to:
16: 5439488
24: 1392508928
30: 3221225472
32: 0

krhm... what's happening here???
architecture is uCdimm 63vz328

/Roope






From louiss at cat.co.za  Wed Mar  5 10:21:53 2003
From: louiss at cat.co.za (Louis Swart)
Date: Wed, 5 Mar 2003 17:21:53 +0200
Subject: [uClinux-dev] Kernel compile stopped working.
References: <r01050400-1024-EDB4F81E4F1211D78E5800039387ACB6@[10.0.1.2]>
Message-ID: <031b01c2e32a$f4128060$1946a8c0@cat.co.za>

> Hmm...any reason to be root for compiling?
[louis at Linux-Test-PC1 uClinux-dist]$ make menuconfig
config/mkconfig > config.in
/bin/sh: line 1: config.in: Permission denied
make: *** [config.in] Error 1
[louis at Linux-Test-PC1 uClinux-dist]$

> What does "which ln" tells you?
[louis at Linux-Test-PC1 uClinux-dist]$ which ln
/usr/bin/which: no ln in
(/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:/home/louis/b
in)
[louis at Linux-Test-PC1 uClinux-dist]$





From richard.klingler at violasystems.com  Wed Mar  5 10:37:22 2003
From: richard.klingler at violasystems.com (Richard Klingler)
Date: Wed,  5 Mar 2003 17:37:22 +0200
Subject: [uClinux-dev] probelm with BIG numbers
In-Reply-To: <1046877322.1921.7.camel@tossu>
Message-ID: <r01050400-1024-5BFD81124F2011D78E5800039387ACB6@[10.0.1.2]>

> Hi,
> 
> some code here...
> 
> unsigned long long int foo = 83;
> printf("16: %llu", foo<<16);
> printf("24: %llu", foo<<24);
> printf("30: %llu", foo<<30);
> printf("32: %llu", foo<<32);
> 
> that results to:
> 16: 5439488
> 24: 1392508928
> 30: 3221225472
> 32: 0
> 

Do you have "HAS_LONG_LONG = true" in uClibc?


Rick


Richard Klingler             mail: richard.klingler at violasystems.com
Viola Systems Ltd.           http://www.violasystems.com/
Lemmink?isenkatu 32          phon: +358 (0)201 226 226
20520 Turku, Finland         mobile: +358 (0)40 748 4711


From cc_3rdproject at yahoo.com  Wed Mar  5 10:37:48 2003
From: cc_3rdproject at yahoo.com (Dan Galway, James Gilbrook)
Date: Wed, 5 Mar 2003 07:37:48 -0800 (PST)
Subject: [uClinux-dev] FrameBuffer for MCF5272
Message-ID: <20030305153748.61465.qmail@web21108.mail.yahoo.com>


Hi,

We are doing a final project for a computer engineering course and this uClinux post is quite similar to what we are trying to implement.  We are using an Epson S1D13505 LCD/CRT controller IC (which seems to have support for uClinux built-in).  The controller will be used with an NEC NL6448AC33-13 10.4" TFT display.

Currently we are designing boards.. and Heiko, if you had the time, it would be informative to hear if there are any cautions or advice you'd have in working with the Epson display controller.  We assume it is feasible to get this controller up and running under uClinux and Microwindows, but we could find no information on people  who have done this.

Any insight would be greatly appreciated!  (from anyone who has a minute to spare)

Regards,
Dan Galway

Conestoga College - Kitchener, Ontario, Canada


----- Original Message -----
From: "Heiko Degenhardt" <heiko.degenhardt at sentec-elektronik.de>
To: <uclinux-dev at uclinux.org>
Sent: Wednesday, March 05, 2003 7:24 AM
Subject: Re: [uClinux-dev] FrameBuffer for MCF5272


> Hi Cal?,
>
> * On Tue, Mar 04, 2003 at 05:53:18PM +0100, Cal? Massimo wrote:
> >     does anybody have any information about using framebuffer on a
> > MCF5272 based board?
>
> yes. I've made a framebuffer driver (uClinux kernel 2.4.x, MCF5272
> based board) for an Epson S1D13706. It works, actually, so I can
> play ntetris on microwindows now. ;)
>
> I haven't really finished that work, currently. I have to check
> everything again, clean up the source, document it etc. This may
> take me some weeks, because I currently have to do some other stuff.
>
> If you are interested, and can't wait until I get everything into
> cvs, I could send you my changed files.
>
> Rgds.
> Heiko.




---------------------------------
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, and more
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20030305/fbb36295/attachment.html>

From richard.klingler at violasystems.com  Wed Mar  5 10:51:30 2003
From: richard.klingler at violasystems.com (Richard Klingler)
Date: Wed,  5 Mar 2003 17:51:30 +0200
Subject: [uClinux-dev] Kernel compile stopped working.
In-Reply-To: <031b01c2e32a$f4128060$1946a8c0@cat.co.za>
Message-ID: <r01050400-1024-5534DCCA4F2211D78E5800039387ACB6@[10.0.1.2]>

> > Hmm...any reason to be root for compiling?
> [louis at Linux-Test-PC1 uClinux-dist]$ make menuconfig
> config/mkconfig > config.in
> /bin/sh: line 1: config.in: Permission denied
> make: *** [config.in] Error 1
> [louis at Linux-Test-PC1 uClinux-dist]$

There is no reason to install uClinux tree as root (o;

> 
> > What does "which ln" tells you?
> [louis at Linux-Test-PC1 uClinux-dist]$ which ln
> /usr/bin/which: no ln in
> (/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:/home/louis/b
> in)
> [louis at Linux-Test-PC1 uClinux-dist]$

Strange linux you have though...

ln should be either "/bin/ln" for Linux/BSD or "/usr/bin/ln" for Solaris...

Think you're missing some vital packages (o;


Rick


Richard Klingler             mail: richard.klingler at violasystems.com
Viola Systems Ltd.           http://www.violasystems.com/
Lemmink?isenkatu 32          phon: +358 (0)201 226 226
20520 Turku, Finland         mobile: +358 (0)40 748 4711


From tchen at on-go.com  Wed Mar  5 10:47:20 2003
From: tchen at on-go.com (thomas chen)
Date: Wed, 05 Mar 2003 10:47:20 -0500
Subject: [uClinux-dev] Toolchain error
References: <20030305143414.4346.qmail@web11005.mail.yahoo.com>
Message-ID: <3E661C08.3DB0C594@on-go.com>

check your PATH environment

should be set to where the m68k-elf-gcc is ...

in my arm case i have to

PATH=/opt/arm-tool-build/bin:$PATH;export PATH



Kristof Bruyninckx wrote:
> 
> hi,
> 
> Whe I recompile my toolchain I'm getting the following
> message in stage 3:
> m68k-elf-gcc command not found
> It compiles further without any error's but this
> mighrt be the reason that when I now compile a default
> kernel in gives the following error's.(see
> attachement). Does anyone know what could be wrong
> when I compile my toolchain??
> Any advice or tips are very welkom.
> 
> yours truly and hoping for a reply
> 
> kristof
> 
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Tax Center - forms, calculators, tips, more
> http://taxes.yahoo.com/
> 
>   ------------------------------------------------------------------------
> cd ..
> b/libc/include -I/uClinux-dist/lib/libm -I/uClinux-dist -fno-builtin -msep-data -I/uClinux-dist/linux-2.4.x/include   -c -o nls.o nls.c
> m68k-elf-gcc -m5307 -DCONFIG_COLDFIRE -Os -g -fomit-frame-pointer  -Dlinux -D__linux__ -Dunix -D__uClinux__ -DEMBED -I/uClinux-dist/lib/libc/include -I/uClinux-dist/lib/libm -I/uClinux-dist -fno-builtin -msep-data -I/uClinux-dist/linux-2.4.x/include   -c -o pipe.o pipe.c
> m68k-elf-gcc -m5307 -DCONFIG_COLDFIRE -Os -g -fomit-frame-pointer  -Dlinux -D__linux__ -Dunix -D__uClinux__ -DEMBED -I/uClinux-dist/lib/libc/include -I/uClinux-dist/lib/libm -I/uClinux-dist -fno-builtin -msep-data -I/uClinux-dist/linux-2.4.x/include   -c -o queue.o queue.c
> m68k-elf-gcc -m5307 -DCONFIG_COLDFIRE -Os -g -fomit-frame-pointer  -Dlinux -D__linux__ -Dunix -D__uClinux__ -DEMBED -I/uClinux-dist/lib/libc/include -I/uClinux-dist/lib/libm -I/uClinux-dist -fno-builtin -msep-data -I/uClinux-dist/linux-2.4.x/include   -c -o read.o read.c
> m68k-elf-gcc -m5307 -DCONFIG_COLDFIRE -Os -g -fomit-frame-pointer  -Dlinux -D__linux__ -Dunix -D__uClinux__ -DEMBED -I/uClinux-dist/lib/libc/include -I/uClinux-dist/lib/libm -I/uClinux-dist -fno-builtin -msep-data -I/uClinux-dist/linux-2.4.x/include   -c -o request.o
> request.c
> m68k-elf-gcc -m5307 -DCONFIG_COLDFIRE -Os -g -fomit-frame-pointer  -Dlinux -D__linux__ -Dunix -D__uClinux__ -DEMBED -I/uClinux-dist/lib/libc/include -I/uClinux-dist/lib/libm -I/uClinux-dist -fno-builtin -msep-data -I/uClinux-dist/linux-2.4.x/include   -c -o response.o response.c
> m68k-elf-gcc -m5307 -DCONFIG_COLDFIRE -Os -g -fomit-frame-pointer  -Dlinux -D__linux__ -Dunix -D__uClinux__ -DEMBED -I/uClinux-dist/lib/libc/include -I/uClinux-dist/lib/libm -I/uClinux-dist -fno-builtin -msep-data -I/uClinux-dist/linux-2.4.x/include   -c -o signals.o
> signals.c
> m68k-elf-gcc -m5307 -DCONFIG_COLDFIRE -Os -g -fomit-frame-pointer  -Dlinux -D__linux__ -Dunix -D__uClinux__ -DEMBED -I/uClinux-dist/lib/libc/include -I/uClinux-dist/lib/libm -I/uClinux-dist -fno-builtin -msep-data -I/uClinux-dist/linux-2.4.x/include   -c -o timestamp.o timestamp.c
> m68k-elf-gcc -m5307 -DCONFIG_COLDFIRE -Os -g -fomit-frame-pointer  -Dlinux -D__linux__ -Dunix -D__uClinux__ -DEMBED -I/uClinux-dist/lib/libc/include -I/uClinux-dist/lib/libm -I/uClinux-dist -fno-builtin -msep-data -I/uClinux-dist/linux-2.4.x/include   -c -o util.o util.c
> m68k-elf-gcc -m5307 -DCONFIG_COLDFIRE -Os -g -fomit-frame-pointer  -Dlinux -D__linux__ -Dunix -D__uClinux__ -DEMBED -I/uClinux-dist/lib/libc/include -I/uClinux-dist/lib/libm -I/uClinux-dist -fno-builtin -msep-data -I/uClinux-dist/linux-2.4.x/include -Wl,-elf2flt -o boa alias.o auth.o boa.o cgi.o cgi_header.o config.o get.o hash.o log.o nls.o pipe.o queue.o read.o request.o response.o signals.o timestamp.o util.o -lcrypt -L/uClinux-dist/lib/libc/. -L/uClinux-dist/lib/libc/lib -L/uClinux-dist/lib/libm -L/uClinux-dist/lib/libnet -L/uClinux-dist/lib/libdes -L/uClinux-dist/lib/libpcap -L/uClinux-dist/lib/zlib -L/uClinux-dist/lib/libssl -lc
> /usr/local/m68k-elf/bin/ld.real: cannot open crt0.o: No such file or directory
> collect2: ld returned 1 exit status
> make[3]: *** [boa] Error 1
> make[3]: Leaving directory `/uClinux-dist/user/boa/src'
> make[2]: *** [all] Error 2
> make[2]: Leaving directory `/uClinux-dist/user/boa'
> make[1]: *** [all] Error 2
> make[1]: Leaving directory `/uClinux-dist/user'
> make: *** [subdirs] Error 1


From thierry.strudel at st.com  Wed Mar  5 10:55:08 2003
From: thierry.strudel at st.com (Thierry STRUDEL)
Date: Wed, 05 Mar 2003 16:55:08 +0100
Subject: [uClinux-dev] Pbs running busybox
References: <3E65BF00.3010207@st.com> <H000027a00e32aa3.1046862930.gnx009@MHS>
Message-ID: <3E661DDC.6000701@st.com>

Hi David,

busybox does work, it was a uCLibc porting problem, the way the syscall were implemented was doing a call so the Link Register was taken from the stack which was altered by the child. It is mandatory not to perform any call so that the return is done using the kernel restored LR and not the one taken from the stack.

Thierry

davidm at snapgear.com a ?crit:
> 
> Try using the minix shell from the uClinux-dist,  it's in user/sh.
> I haven't played with the busybox version but I know a lot of things
> have been fixed in the dist version.
> 
> 
>>What is wrong in my implementation, how things does work on other platform 
>>running busybox ?
> 
> 
> A lot of platforms run the sash shell.  It is a great shell to get
> started with as it is so simple.  Perhaps you should give it a go,
> 
> Cheers,
> Davidm
> 



From roope.anttinen at indagon.com  Wed Mar  5 12:20:23 2003
From: roope.anttinen at indagon.com (Roope Anttinen)
Date: 05 Mar 2003 19:20:23 +0200
Subject: [uClinux-dev] probelm with BIG numbers
In-Reply-To: <r01050400-1024-5BFD81124F2011D78E5800039387ACB6@[10.0.1.2]>
References: <r01050400-1024-5BFD81124F2011D78E5800039387ACB6@[10.0.1.2]>
Message-ID: <1046884826.1922.13.camel@tossu>

Haven't checked that but this works anyway

long long int moduleid = atoll(identification);
..where that identification is a c string containig "358505201234". So I
assume that long long int support is in place.


On Wed, 2003-03-05 at 17:37, Richard Klingler wrote:
> > Hi,
> > 
> > some code here...
> > 
> > unsigned long long int foo = 83;
> > printf("16: %llu", foo<<16);
> > printf("24: %llu", foo<<24);
> > printf("30: %llu", foo<<30);
> > printf("32: %llu", foo<<32);
> > 
> > that results to:
> > 16: 5439488
> > 24: 1392508928
> > 30: 3221225472
> > 32: 0
> > 
> 
> Do you have "HAS_LONG_LONG = true" in uClibc?
> 
> 
> Rick
> 
> 
> Richard Klingler             mail: richard.klingler at violasystems.com
> Viola Systems Ltd.           http://www.violasystems.com/
> Lemmink?isenkatu 32          phon: +358 (0)201 226 226
> 20520 Turku, Finland         mobile: +358 (0)40 748 4711
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org




From kjell at cablescan.com  Wed Mar  5 12:48:03 2003
From: kjell at cablescan.com (Kjell Uddeborg)
Date: Wed, 5 Mar 2003 09:48:03 -0800
Subject: [uClinux-dev] Problems mounting a JFFS2 file system
In-Reply-To: <3E6525F4.B0187408@earthlink.net>
Message-ID: <GGEOICAJEIILOOCMGNKMMECKDGAA.kjell@cablescan.com>

Hi Phil,

Thanks for your reply. I think I know what is going on now. It's related to running both blkmem and MTD at the same time. Both the /dev/mtdblock devices and the /dev/rom devices have the same major device ID. I will try to fix the problem by changing the device ID for the mtdblocks.

The /proc/mtd file looks like this:

  /> cat /proc/mtd
  dev:    size   erasesize  name
  mtd0: 000c0000 00010000 "kernel (768K)"
  mtd1: 00100000 00010000 "rootfs (1024K)"
  mtd2: 00002000 00002000 "environment (8K)"

It's interesting what you say about the garbage collection. Looks like the sector size is 64k. Five sectors would be 320k. Do you know if this means that you have to have this much space free for the garbage collection or it it's enough that your partition is of this size or greater. Is it possible to change the sector size?

Thanks for your help,
Kjell Uddeborg



-----Original Message-----
From: uclinux-dev-admin at uclinux.org
[mailto:uclinux-dev-admin at uclinux.org]On Behalf Of Phil Wilshire
Sent: Tuesday, March 04, 2003 2:17 PM
To: uclinux-dev at uclinux.org
Subject: Re: [uClinux-dev] Problems mounting a JFFS2 file system


Hi Kjell
Could you do a 
cat /proc/mtd 
so that we can check your mtd partitions.

jffs2 needs quite a large number of sectors ( 5 for GC )

try the same with regular jffs.


regards
  Phil Wilshire

Kjell Uddeborg wrote:
> 
> Hi,
> 
> I'm having some problems mounting a JFFS2 file system. I'm using uClinux kernel 2.4 on a Motorola M5249C3 board.
> 
> I think that I have all MTD stuff configured correctly and I can erase the device /dev/mtd1 with no problem, see screen dump:
> 
> -----------------------------
> /> eraseall /dev/mtd1
> MTD_open
> MTD_ioctl
>  0raTsiDng_ 6i4 oKicbyttel @
>  1raTsiDng_ 6i4 oKicbyttel @
>  2raTsiDng_ 6i4 oKicbyttel @
>  3raTsiDng_ 6i4 oKicbyttel @
>  4raTsiDng_ 6i4 oKicbyttel @
>  5raTsiDng_ 6i4 oKicbyttel @
>  6raTsiDng_ 6i4 oKicbyttel @
>  7raTsiDng_ 6i4 oKicbyttel @
>  8raTsiDng_ 6i4 oKicbyttel @
>  9raTsiDng_ 6i4 oKicbyttel @
>  araTsiDng_ 6i4 oKicbyttel @
>  braTsiDng_ 6i4 oKicbyttel @
>  craTsiDng_ 6i4 oKicbyttel @
>  draTsiDng_ 6i4 oKicbyttel @
>  eraTsiDng_ 6i4 oKicbyttel @
>  fraTsiDng_ 6i4 oKicbyttel @
> @ raTseDd _10c24l Koibsytee
>   0 -- 100% complete.
> -----------------------------
> 
> As you can see I have all the debug outputs turned on. Looks to me that the command completed successfully.
> 
> The problem occurs when I try to mount the JFFS2 file system, see screen dump:
> 
> -----------------------------
> /> mount -t jffs2 /dev/mtdblock1 /mnt/jffs2
> arena open of 1 failed!
> mount: Mounting /dev/mtdblock1 on /mnt/jffs2 failed: No such device
> pid 28: failed 256
> -----------------------------
> 
> The /dev/mtdblock1 is exists, see this partial listing on /dev:
> 
> -----------------------------
> /> ls -l /dev
> .
> .
> crw-------  1 0        0         90,   0  Jan 01 1970  mtd0
> crw-------  1 0        0         90,   2  Jan 01 1970  mtd1
> crw-------  1 0        0         90,   4  Jan 01 1970  mtd2
> crw-------  1 0        0         90,   6  Jan 01 1970  mtd3
> brw-------  1 0        0         31,   0  Jan 01 1970  mtdblock0
> brw-------  1 0        0         31,   1  Jan 01 1970  mtdblock1
> brw-------  1 0        0         31,   2  Jan 01 1970  mtdblock2
> brw-------  1 0        0         31,   3  Jan 01 1970  mtdblock3
> crw-------  1 0        0         90,   1  Jan 01 1970  mtdr0
> crw-------  1 0        0         90,   3  Jan 01 1970  mtdr1
> crw-------  1 0        0         90,   5  Jan 01 1970  mtdr2
> crw-------  1 0        0         90,   7  Jan 01 1970  mtdr3
> .
> .
> -----------------------------
> 
> If you have any thoughts of what could be causing this problem please send me a note.
> 
> Thanks for your help,
> Kjell Uddeborg
> Cablescan
> 
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org

-- 
SDCS -- System Design & Consulting Services LLC, http://www.sysdcs.com
** Embedded Linux Training **  email me for details  
630 Springhouse Sq., Leesburg VA 20175 t: 703 669 9766 f: 703 669 9768
_______________________________________________
uClinux-dev mailing list
uClinux-dev at uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev at uclinux.org



From philwil at earthlink.net  Wed Mar  5 13:05:18 2003
From: philwil at earthlink.net (Phil Wilshire)
Date: Wed, 05 Mar 2003 13:05:18 -0500
Subject: [uClinux-dev] Problems mounting a JFFS2 file system
References: <GGEOICAJEIILOOCMGNKMMECKDGAA.kjell@cablescan.com>
Message-ID: <3E663C5E.2D5AC402@earthlink.net>

Hi Kjell,
The sector size is fixed by the Flash Chip.
Jff2 requires the 5 sectors. Jffs uses less space.

You should be able to work without blkmem.
I have an article on uCdot about that.

http://www.ucdot.org/article.pl?sid=03/01/11/1049210&mode=thread

best regards
  Phil Wilshire



Kjell Uddeborg wrote:
> 
> Hi Phil,
> 
> Thanks for your reply. I think I know what is going on now. It's related to running both blkmem and MTD at the same time. Both the /dev/mtdblock devices and the /dev/rom devices have the same major device ID. I will try to fix the problem by changing the device ID for the mtdblocks.
> 
> The /proc/mtd file looks like this:
> 
>   /> cat /proc/mtd
>   dev:    size   erasesize  name
>   mtd0: 000c0000 00010000 "kernel (768K)"
>   mtd1: 00100000 00010000 "rootfs (1024K)"
>   mtd2: 00002000 00002000 "environment (8K)"
> 
> It's interesting what you say about the garbage collection. Looks like the sector size is 64k. Five sectors would be 320k. Do you know if this means that you have to have this much space free for the garbage collection or it it's enough that your partition is of this size or greater. Is it possible to change the sector size?
> 
> Thanks for your help,
> Kjell Uddeborg
> 
> -----Original Message-----
> From: uclinux-dev-admin at uclinux.org
> [mailto:uclinux-dev-admin at uclinux.org]On Behalf Of Phil Wilshire
> Sent: Tuesday, March 04, 2003 2:17 PM
> To: uclinux-dev at uclinux.org
> Subject: Re: [uClinux-dev] Problems mounting a JFFS2 file system
> 
> Hi Kjell
> Could you do a
> cat /proc/mtd
> so that we can check your mtd partitions.
> 
> jffs2 needs quite a large number of sectors ( 5 for GC )
> 
> try the same with regular jffs.
> 
> regards
>   Phil Wilshire
> 
> Kjell Uddeborg wrote:
> >
> > Hi,
> >
> > I'm having some problems mounting a JFFS2 file system. I'm using uClinux kernel 2.4 on a Motorola M5249C3 board.
> >
> > I think that I have all MTD stuff configured correctly and I can erase the device /dev/mtd1 with no problem, see screen dump:
> >
> > -----------------------------
> > /> eraseall /dev/mtd1
> > MTD_open
> > MTD_ioctl
> >  0raTsiDng_ 6i4 oKicbyttel @
> >  1raTsiDng_ 6i4 oKicbyttel @
> >  2raTsiDng_ 6i4 oKicbyttel @
> >  3raTsiDng_ 6i4 oKicbyttel @
> >  4raTsiDng_ 6i4 oKicbyttel @
> >  5raTsiDng_ 6i4 oKicbyttel @
> >  6raTsiDng_ 6i4 oKicbyttel @
> >  7raTsiDng_ 6i4 oKicbyttel @
> >  8raTsiDng_ 6i4 oKicbyttel @
> >  9raTsiDng_ 6i4 oKicbyttel @
> >  araTsiDng_ 6i4 oKicbyttel @
> >  braTsiDng_ 6i4 oKicbyttel @
> >  craTsiDng_ 6i4 oKicbyttel @
> >  draTsiDng_ 6i4 oKicbyttel @
> >  eraTsiDng_ 6i4 oKicbyttel @
> >  fraTsiDng_ 6i4 oKicbyttel @
> > @ raTseDd _10c24l Koibsytee
> >   0 -- 100% complete.
> > -----------------------------
> >
> > As you can see I have all the debug outputs turned on. Looks to me that the command completed successfully.
> >
> > The problem occurs when I try to mount the JFFS2 file system, see screen dump:
> >
> > -----------------------------
> > /> mount -t jffs2 /dev/mtdblock1 /mnt/jffs2
> > arena open of 1 failed!
> > mount: Mounting /dev/mtdblock1 on /mnt/jffs2 failed: No such device
> > pid 28: failed 256
> > -----------------------------
> >
> > The /dev/mtdblock1 is exists, see this partial listing on /dev:
> >
> > -----------------------------
> > /> ls -l /dev
> > .
> > .
> > crw-------  1 0        0         90,   0  Jan 01 1970  mtd0
> > crw-------  1 0        0         90,   2  Jan 01 1970  mtd1
> > crw-------  1 0        0         90,   4  Jan 01 1970  mtd2
> > crw-------  1 0        0         90,   6  Jan 01 1970  mtd3
> > brw-------  1 0        0         31,   0  Jan 01 1970  mtdblock0
> > brw-------  1 0        0         31,   1  Jan 01 1970  mtdblock1
> > brw-------  1 0        0         31,   2  Jan 01 1970  mtdblock2
> > brw-------  1 0        0         31,   3  Jan 01 1970  mtdblock3
> > crw-------  1 0        0         90,   1  Jan 01 1970  mtdr0
> > crw-------  1 0        0         90,   3  Jan 01 1970  mtdr1
> > crw-------  1 0        0         90,   5  Jan 01 1970  mtdr2
> > crw-------  1 0        0         90,   7  Jan 01 1970  mtdr3
> > .
> > .
> > -----------------------------
> >
> > If you have any thoughts of what could be causing this problem please send me a note.
> >
> > Thanks for your help,
> > Kjell Uddeborg
> > Cablescan
> >
> > _______________________________________________
> > uClinux-dev mailing list
> > uClinux-dev at uclinux.org
> > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> > This message was resent by uclinux-dev at uclinux.org
> 
> --
> SDCS -- System Design & Consulting Services LLC, http://www.sysdcs.com
> ** Embedded Linux Training **  email me for details
> 630 Springhouse Sq., Leesburg VA 20175 t: 703 669 9766 f: 703 669 9768
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org
> 
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org

-- 
SDCS -- System Design & Consulting Services LLC, http://www.sysdcs.com
** Embedded Linux Training **  email me for details  
630 Springhouse Sq., Leesburg VA 20175 t: 703 669 9766 f: 703 669 9768


From richard.klingler at violasystems.com  Wed Mar  5 13:21:16 2003
From: richard.klingler at violasystems.com (Richard Klingler)
Date: Wed,  5 Mar 2003 20:21:16 +0200
Subject: [uClinux-dev] probelm with BIG numbers
In-Reply-To: <1046884826.1922.13.camel@tossu>
Message-ID: <r01050400-1024-414FA2974F3711D78E5800039387ACB6@[10.0.1.2]>

> Haven't checked that but this works anyway
> 
> long long int moduleid = atoll(identification);
> ...where that identification is a c string containig "358505201234". So I
> assume that long long int support is in place.
> 

HAS_LONG_LONG defines the behaviour of math functions (I guess ;o)
and atoll has nothing to do with math...

Works perfect...

# null
16: 5439488
24: 1392508928
30: 89120571392
32: 356482285568


Rick


Richard Klingler             mail: richard.klingler at violasystems.com
Viola Systems Ltd.           http://www.violasystems.com/
Lemmink?isenkatu 32          phon: +358 (0)201 226 226
20520 Turku, Finland         mobile: +358 (0)40 748 4711


From g.menie at wanadoo.fr  Wed Mar  5 14:20:46 2003
From: g.menie at wanadoo.fr (Georges Menie)
Date: 05 Mar 2003 20:20:46 +0100
Subject: [uClinux-dev] mc68328digi.h for uclinux2.4.x
Message-ID: <1046892047.1477.13.camel@troca>

I'm starting to work on a touchscreen driver for my 68VZ328 board, I
want to reuse the existing mc68328digi driver but the CVS repository for
uClinux.2.4.x does not contains linux-2.4.x/include/linux/mc68328digi.h.

there is a linux-2.4.X/drivers/char/mc68328digi.h but the c file
includes <linux/mc68628digi.h> and the .h in drivers/char seems to be a
leftover from a previous version, the driver does not compile with it.

I did copy the linux/mc68328digi.h from uClinux-2.0.x and had to modify
it a bit before compiling successfully the driver.

Does anybody knows if there is a uClinux-2.4.x version of this file ? 

The change I made were enough to compile, but may be the 2.4 version has
more changes which are necessary to make it work... I can't test it as
my hardware is diffferent. I would like to have a 'stable' base before
starting to adapt the driver.

Regards,
Georges





From roope.anttinen at indagon.com  Wed Mar  5 14:21:26 2003
From: roope.anttinen at indagon.com (Roope Anttinen)
Date: 05 Mar 2003 21:21:26 +0200
Subject: [uClinux-dev] probelm with BIG numbers
In-Reply-To: <r01050400-1024-414FA2974F3711D78E5800039387ACB6@[10.0.1.2]>
References: <r01050400-1024-414FA2974F3711D78E5800039387ACB6@[10.0.1.2]>
Message-ID: <1046892090.1913.0.camel@tossu>

Hmmm.. where it is defined then?? Tell me, TELL ME :D

/Roope

On Wed, 2003-03-05 at 20:21, Richard Klingler wrote:
> > Haven't checked that but this works anyway
> > 
> > long long int moduleid = atoll(identification);
> > ...where that identification is a c string containig "358505201234". So I
> > assume that long long int support is in place.
> > 
> 
> HAS_LONG_LONG defines the behaviour of math functions (I guess ;o)
> and atoll has nothing to do with math...
> 
> Works perfect...
> 
> # null
> 16: 5439488
> 24: 1392508928
> 30: 89120571392
> 32: 356482285568
> 
> 
> Rick
> 
> 
> Richard Klingler             mail: richard.klingler at violasystems.com
> Viola Systems Ltd.           http://www.violasystems.com/
> Lemmink?isenkatu 32          phon: +358 (0)201 226 226
> 20520 Turku, Finland         mobile: +358 (0)40 748 4711
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org




From mark_mcchrystal at yahoo.com  Wed Mar  5 14:32:34 2003
From: mark_mcchrystal at yahoo.com (Mark McChrystal)
Date: Wed, 5 Mar 2003 11:32:34 -0800 (PST)
Subject: [uClinux-dev] mc68328digi.h for uclinux2.4.x
In-Reply-To: <1046892047.1477.13.camel@troca>
Message-ID: <20030305193234.839.qmail@web14303.mail.yahoo.com>

This was working for uClinux 2.4.x on the VZ328 at one
time I think . . . .
You might want to look at:
http://www.cse.unsw.edu.au/~danielp/uclinux/patches/


Mark
--- Georges Menie <g.menie at wanadoo.fr> wrote:
> I'm starting to work on a touchscreen driver for my
> 68VZ328 board, I
> want to reuse the existing mc68328digi driver but
> the CVS repository for
> uClinux.2.4.x does not contains
> linux-2.4.x/include/linux/mc68328digi.h.
> 
> there is a linux-2.4.X/drivers/char/mc68328digi.h
> but the c file
> includes <linux/mc68628digi.h> and the .h in
> drivers/char seems to be a
> leftover from a previous version, the driver does
> not compile with it.
> 
> I did copy the linux/mc68328digi.h from
> uClinux-2.0.x and had to modify
> it a bit before compiling successfully the driver.
> 
> Does anybody knows if there is a uClinux-2.4.x
> version of this file ? 
> 
> The change I made were enough to compile, but may be
> the 2.4 version has
> more changes which are necessary to make it work...
> I can't test it as
> my hardware is diffferent. I would like to have a
> 'stable' base before
> starting to adapt the driver.
> 
> Regards,
> Georges
> 
> 
> 
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
>
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org


__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/


From roope.anttinen at indagon.com  Wed Mar  5 15:03:43 2003
From: roope.anttinen at indagon.com (Roope Anttinen)
Date: 05 Mar 2003 22:03:43 +0200
Subject: [uClinux-dev] probelm with BIG numbers
In-Reply-To: <1046884826.1922.13.camel@tossu>
References: <r01050400-1024-5BFD81124F2011D78E5800039387ACB6@[10.0.1.2]> 
	<1046884826.1922.13.camel@tossu>
Message-ID: <1046894627.1913.5.camel@tossu>

Damn...
from uClibs/Config
HAS_LONG_LONG = true

so, yes I have it defined :(
More strange...

unsigned long long llInt = 22022;
if((83 << 32) ==0) printf ("ZERO\n");
else printf("NON ZERO\n");
llInt += 38<<32;
printf("foo: %llu\n", llInt);

prints out:
NON ZERO
foo: 22022

..so I have found something thats not zero, not supposed to be zero, but
behaves like a zero ???


On Wed, 2003-03-05 at 19:20, Roope Anttinen wrote:
> Haven't checked that but this works anyway
> 
> long long int moduleid = atoll(identification);
> ..where that identification is a c string containig "358505201234". So I
> assume that long long int support is in place.
> 
> 
> On Wed, 2003-03-05 at 17:37, Richard Klingler wrote:
> > > Hi,
> > > 
> > > some code here...
> > > 
> > > unsigned long long int foo = 83;
> > > printf("16: %llu", foo<<16);
> > > printf("24: %llu", foo<<24);
> > > printf("30: %llu", foo<<30);
> > > printf("32: %llu", foo<<32);
> > > 
> > > that results to:
> > > 16: 5439488
> > > 24: 1392508928
> > > 30: 3221225472
> > > 32: 0
> > > 
> > 
> > Do you have "HAS_LONG_LONG = true" in uClibc?
> > 
> > 
> > Rick
> > 
> > 
> > Richard Klingler             mail: richard.klingler at violasystems.com
> > Viola Systems Ltd.           http://www.violasystems.com/
> > Lemmink?isenkatu 32          phon: +358 (0)201 226 226
> > 20520 Turku, Finland         mobile: +358 (0)40 748 4711
> > _______________________________________________
> > uClinux-dev mailing list
> > uClinux-dev at uclinux.org
> > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> > This message was resent by uclinux-dev at uclinux.org
> 
> 
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org




From HenrySimmons17 at netzero.net  Wed Mar  5 15:07:53 2003
From: HenrySimmons17 at netzero.net (HenrySimmons17)
Date: Wed, 5 Mar 2003 12:07:53 -0800
Subject: [uClinux-dev] Re: [uclinux-dev]UCLINUX for PALM
Message-ID: <004001c2e352$e85c9440$ffc5fea9@henry133>

 Hello Mike....
 I believe these changes should do it. 
 In make xconfig or make config:
 > # General setup
 > CONFIG_CONSOLE=y
 > CONFIG_FRAMEBUFFER=y
 > # CONFIG_PILOT_CONSOLE is not set        
This need to be set to "=y" .  This is what give you a console on the Palm.
To get a serial console, a console on Minicom or Hyperterminal set:
CONFIG_CONSOLE=n
In file vendors/3com/Palm-loader/PalmLoader.c 
> printf("Ordering image pages...\n");
>           asm volatile ("movew #0x3a81, 0xfffff116");     
>           asm volatile ("movew #0x2700, %sr");
#0x3a81 is for  VZ328. Set this to #0x068f  for EZ328  
>           asm volatile ("movew #0x2700, %sr; moveal #0x7ffff0, %ssp");
>           asm volatile ("movew #0x3a81, 0xfffff116"); 
Same here,  #0x3a81 is for VZ328. Set this to #0x068f   
Henry 



From g.menie at wanadoo.fr  Wed Mar  5 15:55:10 2003
From: g.menie at wanadoo.fr (Georges Menie)
Date: 05 Mar 2003 21:55:10 +0100
Subject: [uClinux-dev] mc68328digi.h for uclinux2.4.x
In-Reply-To: <20030305193234.839.qmail@web14303.mail.yahoo.com>
References: <20030305193234.839.qmail@web14303.mail.yahoo.com>
Message-ID: <1046897711.1477.37.camel@troca>

Thanks for the link, the touchscreen patch seems to be the origin of
what's is in CVS, and the patch contains the wrong .h :-0

drivers/char/mc68328digi.h define a struct mc68328_params which was used
by the .c in its version 1.1 (from cvs linux-2.0.x tree history)
committed back in 1998...

the .c has been completely rewritten since its version 1.2, and the
header was moved from drivers/char to include/linux when the .c reached
its version 1.4 (2.0.x tree).

I am going to drop a note to Daniel to see if he still have the new .h

Regards,
Georges

On Wed, 2003-03-05 at 20:32, Mark McChrystal wrote:
> This was working for uClinux 2.4.x on the VZ328 at one
> time I think . . . .
> You might want to look at:
> http://www.cse.unsw.edu.au/~danielp/uclinux/patches/
> 
> 
> Mark
> --- Georges Menie <g.menie at wanadoo.fr> wrote:
> > I'm starting to work on a touchscreen driver for my
> > 68VZ328 board, I
> > want to reuse the existing mc68328digi driver but
> > the CVS repository for
> > uClinux.2.4.x does not contains
> > linux-2.4.x/include/linux/mc68328digi.h.
> > 
> > there is a linux-2.4.X/drivers/char/mc68328digi.h
> > but the c file
> > includes <linux/mc68628digi.h> and the .h in
> > drivers/char seems to be a
> > leftover from a previous version, the driver does
> > not compile with it.
> > 
> > I did copy the linux/mc68328digi.h from
> > uClinux-2.0.x and had to modify
> > it a bit before compiling successfully the driver.
> > 
> > Does anybody knows if there is a uClinux-2.4.x
> > version of this file ? 
> > 
> > The change I made were enough to compile, but may be
> > the 2.4 version has
> > more changes which are necessary to make it work...
> > I can't test it as
> > my hardware is diffferent. I would like to have a
> > 'stable' base before
> > starting to adapt the driver.
> > 
> > Regards,
> > Georges
> > 
> > 
> > 
> > _______________________________________________
> > uClinux-dev mailing list
> > uClinux-dev at uclinux.org
> >
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> > This message was resent by uclinux-dev at uclinux.org
> 
> 
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Tax Center - forms, calculators, tips, more
> http://taxes.yahoo.com/
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org
> 




From rgegusch at mf.tu-berlin.de  Wed Mar  5 08:19:03 2003
From: rgegusch at mf.tu-berlin.de (Rene Gegusch)
Date: Wed, 5 Mar 2003 14:19:03 +0100
Subject: [uClinux-dev] FTP Server on the 5272 board
Message-ID: <200303051419.03570.rgegusch@mf.tu-berlin.de>

Well, I am trying to implement a ftp server on the uClinux system.
finding the discussion mails of february and wonder if someone get a working 
result.
I don not really need authentification, so I would also be happy with 
anonymous ftp. Actually tried to compile anonftp.

I would be pleased. about any help!





From bas at acter.ch  Wed Mar  5 11:23:41 2003
From: bas at acter.ch (Tarkan Bas)
Date: Wed, 05 Mar 2003 17:23:41 +0100
Subject: [uClinux-dev] coldfire pio driver
References: <r01050400-1024-EDB4F81E4F1211D78E5800039387ACB6@[10.0.1.2]>
Message-ID: <3E66248D.37F1169F@acter.ch>

Dear all,

I am searching for a pio driver for coldfire MCF5249 (i.e for led and
button control). Does  any char driver exist allready which I can use as
a pio driver!

regards,

Tarkan


From jwilliams at itee.uq.edu.au  Wed Mar  5 17:05:19 2003
From: jwilliams at itee.uq.edu.au (John Williams)
Date: Thu, 06 Mar 2003 08:05:19 +1000
Subject: [uClinux-dev] FTP Server on the 5272 board
In-Reply-To: <200303051419.03570.rgegusch@mf.tu-berlin.de>
References: <200303051419.03570.rgegusch@mf.tu-berlin.de>
Message-ID: <3E66749F.90106@itee.uq.edu.au>

Rene Gegusch wrote:
> Well, I am trying to implement a ftp server on the uClinux system.
> finding the discussion mails of february and wonder if someone get a working 
> result.
> I don not really need authentification, so I would also be happy with 
> anonymous ftp. Actually tried to compile anonftp.
> 
> I would be pleased. about any help!

I seem to recall that tftp (trivial FTP) now works "off the shelf" in 
uClinux.  I'm not sure whether 2.0.x or 2.4.x though, see the Feb. 
discussion to make sure.  I think you'd just have to select it as one of 
the networking apps to build/install in the kernel configuration process.

If you can't find it let me know and I'll try to find the ugly hacked 
version that I put together last year.

Once you get tftpd compiled, setting up a tftp server is pretty simple. 
  Google around for a bit and you should find something.

Regards,

John



From ron at fial.com  Wed Mar  5 17:46:16 2003
From: ron at fial.com (Ron Fial)
Date: Wed, 05 Mar 2003 14:46:16 -0800
Subject: [uClinux-dev] coldfire pio driver
Message-ID: <3.0.32.20030305144616.01eb0bd0@klickitat.fial.com>

If this is for an embedded project, and there is only one program that will be setting and clearing the PIO port bits, then you can just do a direct read and write to the port data direction registers and to the port I/O-pins register.    This should take under 1 hour to implement.   It is best to keep an RAM variable 'image' of the port pins, change that, and write it out.

If you have two or more programs that use the port, but each uses different pins, then a simple semaphore arangement could be used to prevent simultaneous read/writes by two programs at the same time.  This might take an afternoon depending on how you do the mutex stuff.  You would probably read/modify/write the pins to reduce the need for 'shared' variables between the programs.

If you need interrupt handlers for high-speed read/analyze/write of port pins, then you really need a kernel driver with a simple open, close, ioctl and init routine, along with the proper /dev/pio node with a major and minor device number.  Figure 1-2 days if you have experience writing kernel drivers (this is a very simple driver).  Figure 1-2 weeks if you have never written a kernel driver before and need to buy Rubini's book  ("Linux Device Drivers, 2nd edition".    I think I have found the chapters available to read on the web, tho.   It is an excellent book.  Look around in /Linux-x.x.x/drivers/char for good examples of character oriented (not block-oriented) drivers.

If you have a budget to spend, and need the driver quickly, I', sure someone on the list would be able to quote you a price to create such a driver for you -- maybe even for free just for the experience. 
   Good Luck,
   Ron Fial


  At 05:23 PM 3/5/2003 +0100, you wrote:
>Dear all,
>
>I am searching for a pio driver for coldfire MCF5249 (i.e for led and
>button control). Does  any char driver exist allready which I can use as
>a pio driver!
>
>regards,
>
>Tarkan
>_______________________________________________
>uClinux-dev mailing list
>uClinux-dev at uclinux.org
>http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
>This message was resent by uclinux-dev at uclinux.org
>
>


From rhulsker at emergentsolutions.ca  Wed Mar  5 18:36:11 2003
From: rhulsker at emergentsolutions.ca (Ryan Hulsker)
Date: 05 Mar 2003 16:36:11 -0700
Subject: [uClinux-dev] RAM only filesystem
In-Reply-To: <3.0.32.20030305144616.01eb0bd0@klickitat.fial.com>
References: <3.0.32.20030305144616.01eb0bd0@klickitat.fial.com>
Message-ID: <1046907371.996.24.camel@adams>

	I have a board that successfully boots a uclinux kernel (2.4.19).  This
board has only 8M ram, and now I am trying to figure out how to get
ROMFS to work with it in RAM.

	Where does the system look for the ROMFS?  I am cat-ing it onto the end
of my kernel image, but this puts it in RAM right where my BSS section
is and therefore it gets overwitten by my crt.S.

	In a rom based system, where the romfs is cat-ed onto the end of the
kernel image, the file system image would end up starting at the end of
the DATA section.  Is this where it looks for the image?

	Any light that anyone could shine on this for a newbie would be much
appreciated.

Thanks


Ryan Hulsker



From tzengym at ms8.hinet.net  Wed Mar  5 18:29:33 2003
From: tzengym at ms8.hinet.net (Tonny Tzeng)
Date: Thu, 6 Mar 2003 07:29:33 +0800
Subject: [uClinux-dev] FTP Server on the 5272 board
References: <200303051419.03570.rgegusch@mf.tu-berlin.de>
Message-ID: <000201c2e371$9e6194c0$4e14fea9@Tonny.Lab>

In my case, the ftpd from GNU inetutils works properly with inetd.

Regards,
Tonny
----- Original Message -----
> Well, I am trying to implement a ftp server on the uClinux system.
> finding the discussion mails of february and wonder if someone get a
working
> result.
> I don not really need authentification, so I would also be happy with
> anonymous ftp. Actually tried to compile anonftp.
>
> I would be pleased. about any help!





From gerg at snapgear.com  Wed Mar  5 19:17:29 2003
From: gerg at snapgear.com (Greg Ungerer)
Date: Thu, 06 Mar 2003 10:17:29 +1000
Subject: [uClinux-dev] RAM only filesystem
In-Reply-To: <1046907371.996.24.camel@adams>
References: <3.0.32.20030305144616.01eb0bd0@klickitat.fial.com> <1046907371.996.24.camel@adams>
Message-ID: <3E669399.8070808@snapgear.com>

Hi Ryan,

Ryan Hulsker wrote:
> 	I have a board that successfully boots a uclinux kernel (2.4.19).  This
> board has only 8M ram, and now I am trying to figure out how to get
> ROMFS to work with it in RAM.
> 
> 	Where does the system look for the ROMFS?

This is done different ways on different architectures/boards.
Look at the mess of code in drivers/block/blkmem.c that deal
with this. It ain't pretty :-(


>  I am cat-ing it onto the end
> of my kernel image, but this puts it in RAM right where my BSS section
> is and therefore it gets overwitten by my crt.S.

This is a pretty common setup. With this setup normally you
have code in your crt startup code that moves the ROMfs before
setting the bss to 0. Look at any of the ColdFire crt0_ram.S
files, they all do this. For example:

   ~/linux-2.4.x/arch/m68knommu/platform/5272/Motorola/crt0_ram.S


> 	In a rom based system, where the romfs is cat-ed onto the end of the
> kernel image, the file system image would end up starting at the end of
> the DATA section.  Is this where it looks for the image?

It can be.

Typically for the all RAM setup your crt0 startup code moves
the ROMfs to after the bss. Blkmem looks here for it then.

Regards
Greg


------------------------------------------------------------------------
Greg Ungerer  --  Chief Software Wizard        EMAIL:  gerg at snapgear.com
SnapGear Pty Ltd                               PHONE:    +61 7 3435 2888
825 Stanley St,                                  FAX:    +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia              WEB:   www.SnapGear.com



From manigandanv at myw.ltindia.com  Wed Mar  5 23:48:56 2003
From: manigandanv at myw.ltindia.com (Manigandan.V)
Date: Thu, 6 Mar 2003 10:18:56 +0530
Subject: [uClinux-dev] FTP Server on the 5272 board
References: <200303051419.03570.rgegusch@mf.tu-berlin.de> <000201c2e371$9e6194c0$4e14fea9@Tonny.Lab>
Message-ID: <006901c2e39b$b1ee0f80$1e06a8c0@emsysdom>

Hi,

> > Well, I am trying to implement a ftp server on the uClinux system.
> > finding the discussion mails of february and wonder if someone get a
> working
> > result.
> > I don not really need authentification, so I would also be happy with
> > anonymous ftp. Actually tried to compile anonftp.
anonftp is a good choice for your purpose .

> > I would be pleased. about any help!
Are you getting any compile time error ? What is your problem in using
anonftp ?




From louiss at cat.co.za  Thu Mar  6 02:14:11 2003
From: louiss at cat.co.za (Louis Swart)
Date: Thu, 6 Mar 2003 09:14:11 +0200
Subject: [uClinux-dev] Kernel compile stopped working.
References: <r01050400-1024-5534DCCA4F2211D78E5800039387ACB6@[10.0.1.2]>
Message-ID: <036001c2e3af$fc7911d0$1946a8c0@cat.co.za>

Something terrible seem to have gone wrong with my Linux installation.
I am going to re-install Linux. 

I have learnt my lesson, do not work as root!!!

Thank you for your support.

Louis.





From lars-ake.ekstrand at intellicom.se  Thu Mar  6 03:21:58 2003
From: lars-ake.ekstrand at intellicom.se (=?iso-8859-1?Q?Lars-=C5ke_Ekstrand?=)
Date: Thu, 6 Mar 2003 09:21:58 +0100
Subject: [uClinux-dev] FTP Server on the 5272 board
Message-ID: <BC03D160581F7A4E92710FC238282411167809@ici-mail.intellicom.se>

Hi,

There seems to be a ftp server in the new uClinux dist. At least there is a directory called user/ftpd. I just downloaded the dist so I haven't checked it further yet. Anyone who knows anything about this ftp daemon?

/Regards
Lars-Ake


-----Original Message-----
From: Rene Gegusch [mailto:rgegusch at mf.tu-berlin.de] 
Sent: den 5 mars 2003 14:19
To: uclinux-dev at uclinux.org
Subject: [uClinux-dev] FTP Server on the 5272 board


Well, I am trying to implement a ftp server on the uClinux system. finding the discussion mails of february and wonder if someone get a working 
result.
I don not really need authentification, so I would also be happy with 
anonymous ftp. Actually tried to compile anonftp.

I would be pleased. about any help!



_______________________________________________
uClinux-dev mailing list
uClinux-dev at uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev at uclinux.org


From jwilliams at itee.uq.edu.au  Thu Mar  6 04:39:15 2003
From: jwilliams at itee.uq.edu.au (John Willlams)
Date: Thu, 6 Mar 2003 19:39:15 +1000
Subject: [uClinux-dev] Kernel compile stopped working.
Message-ID: <000d01c2e3c4$4f87f300$0307a8c0@john.qut.edu.au>

>I have learnt my lesson, do not work as root!!!

A painful but vital lesson..

You will have better luck next time I'm sure :)


From n.ferre at i2e.fr  Thu Mar  6 05:33:26 2003
From: n.ferre at i2e.fr (Nicolas Ferre)
Date: Thu, 6 Mar 2003 11:33:26 +0100
Subject: [uClinux-dev] Tiny filesystem in ramdisk
Message-ID: <000001c2e3cb$d2a79720$0e01a8c0@i2e.fr>

Hi,

I would like to use a tiny filesystem in my ramdisk. I use this ramdisk
with flatfsd to store my config files.

The mtd device where I want to put my flatfsd is 8k big... So I'd like
a  ~8k ramdisk filesystem to map my mtd device.

Is it possible to create a 8k ext2 filesystem ? (the mke2fs complains when I
try to)

Shall I use another filesystem ? (minix, fat ?)

Thanks,
--
Nicolas Ferre, Software Engineer
@work : n.ferre at i2e.fr : http://www.i2e.fr : +33 4 42 60 70 76
@home : nferre at free.fr : http://nferre.free.fr



From roope.anttinen at indagon.com  Thu Mar  6 06:12:53 2003
From: roope.anttinen at indagon.com (Roope Anttinen)
Date: 06 Mar 2003 13:12:53 +0200
Subject: [uClinux-dev] problem with big numbers continues... HELP!
Message-ID: <1046949176.1913.12.camel@tossu>

Hi,

this is really strange... I've got 500 pcs of uCdimm's waiting to be
deployed but this is a showstopper. I just have to use 64bit integer
there and here's the results I've got with uClinux-dist-20020927 and
m68k-elf-tools-20020410, with HAVE_LONG_LONG defined in uClibc/Config:

test.c:


#include <stdio.h>

int main(void)
{
  unsigned long long llInt = 83;
  printf("16: %llu\n", llInt<<16);
  printf("30: %llu\n", llInt<<30);
  printf("32: %llu\n", llInt<<32);
  llInt = 22022;
  if((83ll << 32) ==0) printf ("ZERO\n");
  else printf("NON ZERO\n");
  llInt += 38ll<<32;
  printf("foo: %llu\n", llInt);
  return 0;
}


# /mnt/test.gdb
16: 5439488
30: 3221225472
32: 0
NON ZERO
foo: 22022

and the same program compiled on my Linux workstation:

ranttine at tossu:~/src/module/module> ./test
16: 5439488
30: 89120571392
32: 356482285568
NON ZERO
foo: 163208779270





From richard.klingler at violasystems.com  Thu Mar  6 06:33:10 2003
From: richard.klingler at violasystems.com (Richard Klingler)
Date: Thu,  6 Mar 2003 13:33:10 +0200
Subject: [uClinux-dev] problem with big numbers continues... HELP!
In-Reply-To: <1046949176.1913.12.camel@tossu>
Message-ID: <r01050400-1024-690C27D04FC711D7ADFD00039387ACB6@[10.0.1.2]>

> Hi,
> 
> this is really strange... I've got 500 pcs of uCdimm's waiting to be
> deployed but this is a showstopper. I just have to use 64bit integer
> there and here's the results I've got with uClinux-dist-20020927 and
> m68k-elf-tools-20020410, with HAVE_LONG_LONG defined in uClibc/Config:
> 
> 
> # /mnt/test.gdb
> 16: 5439488
> 30: 3221225472
> 32: 0
> NON ZERO
> foo: 22022
> 

And the same on our Coldfire DIMM and distribution:

# null
16: 5439488
30: 89120571392
32: 356482285568
NON ZERO
foo: 163208779270


(o;

What are all the other options you have set in uClibc/Config?


Rick


Richard Klingler             mail: richard.klingler at violasystems.com
Viola Systems Ltd.           http://www.violasystems.com/
Lemmink?isenkatu 32          phon: +358 (0)201 226 226
20520 Turku, Finland         mobile: +358 (0)40 748 4711


From roope.anttinen at indagon.com  Thu Mar  6 06:46:39 2003
From: roope.anttinen at indagon.com (Roope Anttinen)
Date: 06 Mar 2003 13:46:39 +0200
Subject: [uClinux-dev] BIG numbers more info...
Message-ID: <1046951202.1913.22.camel@tossu>

OK... here's some more code:


#include <stdio.h>
#include <stdlib.h>

int main(void)
{
  unsigned long long llInt = 83;
  char str_long[40] = "358505772769";
  printf("16: %llu\n", llInt<<16);
  printf("30: %llu\n", llInt<<30);
  printf("32: %llu\n", llInt<<32);
  llInt = 22022;
  if((83ll << 32) ==0) printf ("ZERO\n");
  else printf("NON ZERO\n");
  llInt += 38ll<<32;
  printf("foo: %llu\n", llInt);
  printf("foo: %llu\n", (llInt/100000));
  llInt = atoll(str_long);
  printf("str: %llu\n", llInt );
  printf("str: %llu\n", (llInt/100000) );
  return 0;
}

on Linux workstation:

ranttine at tossu:~/src/module/module> ./test.exe
16: 5439488
30: 89120571392
32: 356482285568
NON ZERO
foo: 163208779270
foo: 1632087
str: 358505772769
str: 3585057

on uCdimm:

# /mnt/test.gdb
16: 5439488
30: 3221225472
32: 0
NON ZERO
foo: 22022
foo: 1632087
str: 2023487201
str: 3585057

..so it looks like it can handle these long long values, but just can't
print 'em out... OK, I think I can now work my way around this by making
my own string handling function, but it would be nice to be able to use
just the normal library funcions.

And, BTW I use the old uc-libc... can't use uClibc, because it has way
too unreliable signal handling.

/Roope




From andersen at codepoet.org  Thu Mar  6 07:03:10 2003
From: andersen at codepoet.org (Erik Andersen)
Date: Thu, 6 Mar 2003 05:03:10 -0700
Subject: [uClinux-dev] BIG numbers more info...
In-Reply-To: <1046951202.1913.22.camel@tossu>
References: <1046951202.1913.22.camel@tossu>
Message-ID: <20030306120310.GA26422@codepoet.org>

On Thu Mar 06, 2003 at 01:46:39PM +0200, Roope Anttinen wrote:
> And, BTW I use the old uc-libc... can't use uClibc, because it has way
> too unreliable signal handling.

Can you please provide me with an example showing unreliable 
signal handling in uClibc 0.9.19?

 -Erik

--
Erik B. Andersen             http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--


From philwil at earthlink.net  Thu Mar  6 07:31:22 2003
From: philwil at earthlink.net (Phil Wilshire)
Date: Thu, 06 Mar 2003 07:31:22 -0500
Subject: [uClinux-dev] Tiny filesystem in ramdisk
References: <000001c2e3cb$d2a79720$0e01a8c0@i2e.fr>
Message-ID: <3E673F9A.6B32325B@earthlink.net>

Hi Nicolas
Ramfs should do this for you

Here is an example from one of my /etc/rc's
===================================
#!/bin/sh                                                                       
mount -t proc proc /proc                                                        

# the old way
#/sbin/expand /ramfs.img /dev/ram0                                              
#mount -t ext2 /dev/ram0 /var                                                   

# Now use this instead                                                              
mount -t ramfs ramfs /var                                                       
======================================

regards
  Phil Wilshire

Nicolas Ferre wrote:
> 
> Hi,
> 
> I would like to use a tiny filesystem in my ramdisk. I use this ramdisk
> with flatfsd to store my config files.
> 
> The mtd device where I want to put my flatfsd is 8k big... So I'd like
> a  ~8k ramdisk filesystem to map my mtd device.
> 
> Is it possible to create a 8k ext2 filesystem ? (the mke2fs complains when I
> try to)
> 
> Shall I use another filesystem ? (minix, fat ?)
> 
> Thanks,
> --
> Nicolas Ferre, Software Engineer
> @work : n.ferre at i2e.fr : http://www.i2e.fr : +33 4 42 60 70 76
> @home : nferre at free.fr : http://nferre.free.fr
> 
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org

-- 
SDCS -- System Design & Consulting Services LLC, http://www.sysdcs.com
** Embedded Linux Training **  email me for details  
630 Springhouse Sq., Leesburg VA 20175 t: 703 669 9766 f: 703 669 9768


From philippe.ney at smartdata.ch  Thu Mar  6 09:11:54 2003
From: philippe.ney at smartdata.ch (Philippe Ney)
Date: Thu, 6 Mar 2003 15:11:54 +0100
Subject: [uClinux-dev] mc68328digi.h for uclinux2.4.x
In-Reply-To: <1046892047.1477.13.camel@troca>
References: <1046892047.1477.13.camel@troca>
Message-ID: <20030306151154.7ea04fdc.philippe.ney@smartdata.ch>

> I'm starting to work on a touchscreen driver for my 68VZ328 board, I
> want to reuse the existing mc68328digi driver but the CVS repository for
> uClinux.2.4.x does not contains linux-2.4.x/include/linux/mc68328digi.h.
> 
> there is a linux-2.4.X/drivers/char/mc68328digi.h but the c file
> includes <linux/mc68628digi.h> and the .h in drivers/char seems to be a
> leftover from a previous version, the driver does not compile with it.
> 
> I did copy the linux/mc68328digi.h from uClinux-2.0.x and had to modify
> it a bit before compiling successfully the driver.
> 
> Does anybody knows if there is a uClinux-2.4.x version of this file ? 
> 
> The change I made were enough to compile, but may be the 2.4 version has
> more changes which are necessary to make it work... I can't test it as
> my hardware is diffferent. I would like to have a 'stable' base before
> starting to adapt the driver.

Hi,

When I wrote the driver, the current kernel was the 2.0.38 one.
I remember having added some beginning of a support for 2.2 kernels.
But as I haven't use uClinux in its 2.4 kernel version, and nobody
seems to contribute in the driver, I haven't done efforts to port it.

I saw later that 'Daniel Potts <danielp at cse.unsw.edu.au>' made the job.

I'm happy seeing that the touch screen driver is not dead :)

If you have questions, feel free to ask me. I'll do my best to answer.
-philippe


From bas at acter.ch  Thu Mar  6 03:04:51 2003
From: bas at acter.ch (Tarkan Bas)
Date: Thu, 06 Mar 2003 09:04:51 +0100
Subject: [uClinux-dev] coldfire pio driver
References: <3.0.32.20030305144616.01eb0bd0@klickitat.fial.com>
Message-ID: <3E670123.B24A0BEA@acter.ch>

Hi Ron,

Ron Fial wrote:
> 
> If this is for an embedded project, and there is only one program that will be setting and clearing the PIO port bits, then you can just do a direct read and write to the port data direction registers and to the port I/O-pins register.    This should take under 1 hour to implement.   It is best to keep an RAM variable 'image' of the port pins, change that, and write it out.
> 
> If you have two or more programs that use the port, but each uses different pins, then a simple semaphore arangement could be used to prevent simultaneous read/writes by two programs at the same time.  This might take an afternoon depending on how you do the mutex stuff.  You would probably read/modify/write the pins to reduce the need for 'shared' variables between the programs.
> 
> If you need interrupt handlers for high-speed read/analyze/write of port pins, then you really need a kernel driver with a simple open, close, ioctl and init routine, along with the proper /dev/pio node with a major and minor device number.  Figure 1-2 days if you have experience writing kernel drivers (this is a very simple driver).  Figure 1-2 weeks if you have never written a kernel driver before and need to buy Rubini's book  ("Linux Device Drivers, 2nd edition".    I think I have found the chapters available to read on the web, tho.   It is an excellent book.  Look around in /Linux-x.x.x/drivers/char for good examples of character oriented (not block-oriented) drivers.

this is actually what I want. A kernel driver with interrupt handlers
for coldfire M5249. I found a T6963 driver (as far as I see it can be
used in pio mode, too) in config.in file in /Linux-x.x.x/drivers/char
directory but no .c file for that driver. Maybe this could be what I
want. does someone know where is the C-file for T6963 driver.????

> 
> If you have a budget to spend, and need the driver quickly, I', sure someone on the list would be able to quote you a price to create such a driver for you -- maybe even for free just for the experience.
>    Good Luck,
>    Ron Fial


Thanks for advice. 

regards,

Tarkan
> 
>   At 05:23 PM 3/5/2003 +0100, you wrote:
> >Dear all,
> >
> >I am searching for a pio driver for coldfire MCF5249 (i.e for led and
> >button control). Does  any char driver exist allready which I can use as
> >a pio driver!
> >
> >regards,
> >
> >Tarkan
> >_______________________________________________
> >uClinux-dev mailing list
> >uClinux-dev at uclinux.org
> >http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> >This message was resent by uclinux-dev at uclinux.org
> >
> >
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org


From munikn at myw.ltindia.com  Thu Mar  6 21:12:05 2003
From: munikn at myw.ltindia.com (munix)
Date: Thu, 6 Mar 2003 18:12:05 -0800 (Pacific Standard Time)
Subject: [uClinux-dev] #pragma pack()
References: <20030306120310.GA26422@codepoet.org>
Message-ID: <3E67FFF5.000001.50499@munix>

HI ALL,

Can any one help me out abt how "#pragma pack()" works in uclinux , and how
to go abt to use it...
I want ot use it, to pack the structure from padding
Iam getting compilation error.

Thanx in advance
Munix



-------Original Message-------

From: uclinux-dev at uclinux.org
Date: Thursday, March 06, 2003 04:23:06 AM
To: Roope Anttinen
Cc: uClinux-dev
Subject: Re: [uClinux-dev] BIG numbers more info...

On Thu Mar 06, 2003 at 01:46:39PM +0200, Roope Anttinen wrote:
> And, BTW I use the old uc-libc... can't use uClibc, because it has way
> too unreliable signal handling.

Can you please provide me with an example showing unreliable 
signal handling in uClibc 0.9.19?

-Erik

--
Erik B. Andersen http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--
_______________________________________________
uClinux-dev mailing list
uClinux-dev at uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev at uclinux.org
. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20030306/77340a99/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: IMSTP.gif
Type: image/gif
Size: 494 bytes
Desc: not available
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20030306/77340a99/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2377_img.jpg
Type: image/jpeg
Size: 16756 bytes
Desc: not available
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20030306/77340a99/attachment.jpg>

From sanbhat at globaledgesoft.com  Thu Mar  6 09:47:46 2003
From: sanbhat at globaledgesoft.com (Santosh Bhat)
Date: Thu, 6 Mar 2003 20:17:46 +0530
Subject: [uClinux-dev] GDB enabled Make
References: <1046951202.1913.22.camel@tossu>
Message-ID: <012001c2e3ef$5a241c00$800210ac@16.2.63.ges1>

Hi List ,
I am trying to debug the ARM7 core . I have a 8 mb ram . when I compile the
code with debug enabled (without any applications ) it is coming up to 13-14
mb of which i will not be able to download in to my RAM . Is there any way ,
selectively I can choose the files of which i want to debug , enable only
those with -g so that I'll be able to debug from the source ???
If yes which are the dependencies/Make files i will have to examine ??

Any help/pointer on this is appreciated.
Regards
Santosh Bhat



From munikn at myw.ltindia.com  Thu Mar  6 22:07:50 2003
From: munikn at myw.ltindia.com (munix)
Date: Thu, 6 Mar 2003 19:07:50 -0800 (Pacific Standard Time)
Subject: [uClinux-dev] #pragma pack() in user mode
References: <1046951202.1913.22.camel@tossu>
Message-ID: <3E680D06.000004.50499@munix>



HI ALL,

Can any one help me out abt how "#pragma pack()" works in uclinux , and how
to go abt to use it... in user mode
I want ot use it, to pack the structure from padding
Iam getting compilation error.

Thanx in advance
Munix


-------Original Message-------

From: uclinux-dev at uclinux.org
Date: Thursday, March 06, 2003 03:58:21 AM
To: uClinux-dev
Subject: [uClinux-dev] BIG numbers more info...

OK... here's some more code:


#include <stdio.h>
#include <stdlib.h>

int main(void)
{
unsigned long long llInt = 83;
char str_long[40] = "358505772769";
printf("16: %llu\n", llInt<<16);
printf("30: %llu\n", llInt<<30);
printf("32: %llu\n", llInt<<32);
llInt = 22022;
if((83ll << 32) ==0) printf ("ZERO\n");
else printf("NON ZERO\n");
llInt += 38ll<<32;
printf("foo: %llu\n", llInt);
printf("foo: %llu\n", (llInt/100000));
llInt = atoll(str_long);
printf("str: %llu\n", llInt );
printf("str: %llu\n", (llInt/100000) );
return 0;
}

on Linux workstation:

ranttine at tossu:~/src/module/module> ./test.exe
16: 5439488
30: 89120571392
32: 356482285568
NON ZERO
foo: 163208779270
foo: 1632087
str: 358505772769
str: 3585057

on uCdimm:

# /mnt/test.gdb
16: 5439488
30: 3221225472
32: 0
NON ZERO
foo: 22022
foo: 1632087
str: 2023487201
str: 3585057

...so it looks like it can handle these long long values, but just can't
print 'em out... OK, I think I can now work my way around this by making
my own string handling function, but it would be nice to be able to use
just the normal library funcions.

And, BTW I use the old uc-libc... can't use uClibc, because it has way
too unreliable signal handling.

/Roope


_______________________________________________
uClinux-dev mailing list
uClinux-dev at uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev at uclinux.org
. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20030306/bc27ca09/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: IMSTP.gif
Type: image/gif
Size: 494 bytes
Desc: not available
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20030306/bc27ca09/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2377_img.jpg
Type: image/jpeg
Size: 16756 bytes
Desc: not available
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20030306/bc27ca09/attachment.jpg>

From richard.klingler at violasystems.com  Thu Mar  6 09:59:04 2003
From: richard.klingler at violasystems.com (Richard Klingler)
Date: Thu,  6 Mar 2003 16:59:04 +0200
Subject: [uClinux-dev] coldfire pio driver
In-Reply-To: <3E670123.B24A0BEA@acter.ch>
Message-ID: <r01050400-1024-2CAE85044FE411D7ADFD00039387ACB6@[10.0.1.2]>

> this is actually what I want. A kernel driver with interrupt handlers
> for coldfire M5249. I found a T6963 driver (as far as I see it can be
> used in pio mode, too) in config.in file in /Linux-x.x.x/drivers/char
> directory but no .c file for that driver. Maybe this could be what I
> want. does someone know where is the C-file for T6963 driver.????

1. You didn't look into 2.0.x....otherwise you would have found it (o;

2. Isn't a framebuffer device a little overkill to use as base for
   a simple GPIO driver with interrupts?



Rick (o;


Richard Klingler             mail: richard.klingler at violasystems.com
Viola Systems Ltd.           http://www.violasystems.com/
Lemmink?isenkatu 32          phon: +358 (0)201 226 226
20520 Turku, Finland         mobile: +358 (0)40 748 4711


From hamilton at SEDSystems.ca  Thu Mar  6 10:07:45 2003
From: hamilton at SEDSystems.ca (Kendrick Hamilton)
Date: Thu, 6 Mar 2003 09:07:45 -0600 (Canada Central Standard Time)
Subject: [uClinux-dev] #pragma pack()
In-Reply-To: <3E67FFF5.000001.50499@munix>
Message-ID: <Pine.WNT.4.44.0303060906300.99-100000@sw-55.sedsystems.ca>

Have you looked at the gcc web page? Try
struct foo
{
	short x;
	short y;
} __attribute__((packed));
 It is something like this.
Kendrick


On Thu, 6 Mar 2003, munix wrote:

> HI ALL,
>
> Can any one help me out abt how "#pragma pack()" works in uclinux , and how
> to go abt to use it...
> I want ot use it, to pack the structure from padding
> Iam getting compilation error.
>
> Thanx in advance
> Munix
>
>
>
> -------Original Message-------
>
> From: uclinux-dev at uclinux.org
> Date: Thursday, March 06, 2003 04:23:06 AM
> To: Roope Anttinen
> Cc: uClinux-dev
> Subject: Re: [uClinux-dev] BIG numbers more info...
>
> On Thu Mar 06, 2003 at 01:46:39PM +0200, Roope Anttinen wrote:
> > And, BTW I use the old uc-libc... can't use uClibc, because it has way
> > too unreliable signal handling.
>
> Can you please provide me with an example showing unreliable
> signal handling in uClibc 0.9.19?
>
> -Erik
>
> --
> Erik B. Andersen http://codepoet-consulting.com/
> --This message was written using 73% post-consumer electrons--
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org
> .



From heiko.degenhardt at sentec-elektronik.de  Thu Mar  6 10:06:45 2003
From: heiko.degenhardt at sentec-elektronik.de (Heiko Degenhardt)
Date: Thu, 6 Mar 2003 16:06:45 +0100
Subject: [uClinux-dev] uClinux-dist-20030305 released
In-Reply-To: <3E65925A.1090102@snapgear.com>; from gerg@snapgear.com on Wed, Mar 05, 2003 at 03:59:54PM +1000
References: <3E65925A.1090102@snapgear.com>
Message-ID: <20030306160645.B26921@www2.sentec-elektronik.de>

Hi Greg, 

* On Wed, Mar 05, 2003 at 03:59:54PM +1000, Greg Ungerer wrote:
> 
> The latest uClinux-dist package is now officially released.
> You can get it at the usual place:
> 
>    http://www.uclinux.org/pub/uClinux/dist

just to keep you informed:
The new distribution compiles and runs without any problems as well
on my M5272C3 as on our COBRA5272.
I'll try to find the differences between this release and the pre,
may be I can find the problem somewhere.

Thanks again for your work with the dist!

Rgds.
Heiko.



From richard.klingler at violasystems.com  Thu Mar  6 10:42:46 2003
From: richard.klingler at violasystems.com (Richard Klingler)
Date: Thu,  6 Mar 2003 17:42:46 +0200
Subject: [uClinux-dev] #pragma pack() in user mode
In-Reply-To: <3E680D06.000004.50499@munix>
Message-ID: <r01050400-1024-477E704F4FEA11D7ADFD00039387ACB6@[10.0.1.2]>

Can you please use a "real" email client that doesn't fill
our mailboxes with pictures of palm trees?

> 
> 
> 

> 
> 
HI ALL,
> 
> 

> 
> 
Can any one help me out abt how "#pragma pack()" works in uclinux , and how
> 
to go abt to use it... in user mode
> 
> 
I want ot use it, to pack the structure from padding
> 
> 
Iam getting compilation error.
> 
> 

> 
> 
Thanx in advance
> 
> 
Munix
> 

Richard Klingler             mail: richard.klingler at violasystems.com
Viola Systems Ltd.           http://www.violasystems.com/
Lemmink?isenkatu 32          phon: +358 (0)201 226 226
20520 Turku, Finland         mobile: +358 (0)40 748 4711


From rhulsker at emergentsolutions.ca  Thu Mar  6 10:56:35 2003
From: rhulsker at emergentsolutions.ca (Ryan Hulsker)
Date: 06 Mar 2003 08:56:35 -0700
Subject: [uClinux-dev] RAM only filesystem
In-Reply-To: <3E669399.8070808@snapgear.com>
References: <3.0.32.20030305144616.01eb0bd0@klickitat.fial.com>
	<1046907371.996.24.camel@adams>  <3E669399.8070808@snapgear.com>
Message-ID: <1046966195.24356.9.camel@adams>

Greg,
	Thanks for your help, you pointed me in the right direction and I
managed to get it working.

> Look at the mess of code in drivers/block/blkmem.c that deal
> with this. It ain't pretty :-(

	Wow, you are not kidding.  Do you think there is any way to clean this
stuff up, or is this just one of those things that has to be hard coded
like that.  I'm just wondering if there might be a way to generalize
that setup a little more, and maybe use a command line argument to start
it off or something.

> >  I am cat-ing it onto the end
> > of my kernel image, but this puts it in RAM right where my BSS section
> > is and therefore it gets overwitten by my crt.S.
> 
> This is a pretty common setup. With this setup normally you
> have code in your crt startup code that moves the ROMfs before
> setting the bss to 0. Look at any of the ColdFire crt0_ram.S
> files, they all do this. For example:
> 
>    ~/linux-2.4.x/arch/m68knommu/platform/5272/Motorola/crt0_ram.S

	This really helped me out a lot.  All this time I have been seeing
these references to CAT_ROMARRAY and I could't quite put my finger on
what that meant, and then while I was looking at blkmem.c all of a
sudden it hit me....DOH!!!

Thanks again.

Ryan Hulsker





From philwil at earthlink.net  Thu Mar  6 10:51:01 2003
From: philwil at earthlink.net (Phil Wilshire)
Date: Thu, 06 Mar 2003 10:51:01 -0500
Subject: [uClinux-dev] GDB enabled Make
References: <1046951202.1913.22.camel@tossu> <012001c2e3ef$5a241c00$800210ac@16.2.63.ges1>
Message-ID: <3E676E65.83D7F26B@earthlink.net>

Hi Santosh,
I am not sure how you are downloading to the target system but
The inclusion of the debug information in the output file does not mean that
the actual system you load to the target system is the same size.

The same goes for the user apps. The .gdb or .elf files may be larget but the 
flat files are the same size.

use arm-elf-objdump -h linux 
typical results shown


Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .init         0000a000  01000000  01000000  00008000  2**5
                  CONTENTS, ALLOC, LOAD, CODE
  1 .text         0023a2c8  0100a000  0100a000  00012000  2**5
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  2 .data         0000964c  01246000  01246000  0024e000  2**5
                  CONTENTS, ALLOC, LOAD, DATA
  3 .bss          00022350  0124f660  0124f660  00257660  2**5
                  ALLOC
  
regards
  Phil Wilshire



Santosh Bhat wrote:
> 
> Hi List ,
> I am trying to debug the ARM7 core . I have a 8 mb ram . when I compile the
> code with debug enabled (without any applications ) it is coming up to 13-14
> mb of which i will not be able to download in to my RAM . Is there any way ,
> selectively I can choose the files of which i want to debug , enable only
> those with -g so that I'll be able to debug from the source ???
> If yes which are the dependencies/Make files i will have to examine ??
> 
> Any help/pointer on this is appreciated.
> Regards
> Santosh Bhat
> 
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org

-- 
SDCS -- System Design & Consulting Services LLC, http://www.sysdcs.com
** Embedded Linux Training **  email me for details  
630 Springhouse Sq., Leesburg VA 20175 t: 703 669 9766 f: 703 669 9768


From HenrySimmons17 at netzero.net  Thu Mar  6 14:08:56 2003
From: HenrySimmons17 at netzero.net (HenrySimmons17)
Date: Thu, 6 Mar 2003 11:08:56 -0800
Subject: [uClinux-dev] Thumbpad keyboard driver
Message-ID: <000001c2e414$09683ba0$ffc5fea9@henry133>

I want to use the Targus Thumbpad keyboard 
on a Palm m500 with uClinux-2.0.x. 
Where can I get  a driver for it and how do I set this up.
Thanks,
Henry






From HenrySimmons17 at netzero.net  Thu Mar  6 15:16:57 2003
From: HenrySimmons17 at netzero.net (HenrySimmons17)
Date: Thu, 6 Mar 2003 12:16:57 -0800
Subject: [uClinux-dev] UCLINUX for PALM
References: <Pine.GSO.4.33.0302070159150.23746-100000@compserv1> <000201c2cfbe$943f2fa0$ffc5fea9@henry133> <20030209232255.GA28757@beast.internal.moreton.com.au> <000701c2d0aa$a7f0f780$ffc5fea9@henry133> <20030210030607.GA4753@beast.internal.moreton.com.au> <001b01c2df42$376b2700$ffc5fea9@henry133> <20030303010709.GF17327@beast.internal.moreton.com.au> <000201c2e205$b337fd20$ffc5fea9@henry133> <20030304092301.GA5007@beast.internal.moreton.com.au>
Message-ID: <000201c2e41d$8eed5c20$ffc5fea9@henry133>

Hello Davidm....
> > > I usually run my IIIx without the fancy console this the current setup
:-)
> > How do you do this?
>
> Serial console on ttyS0.  I load the image down at 57600,  switch to
> 9600 and then run PalmLoader to boot uClinux.
I believe I see it. How do the kernel know to run the serial console?
Did you put a statement in inittab or what?
Henry




From jive74 at gsmbox.it  Thu Mar  6 16:54:20 2003
From: jive74 at gsmbox.it (Giovanni Casoli)
Date: Thu, 6 Mar 2003 21:54:20 +0000 (UTC)
Subject: [uClinux-dev] structure size ????
In-Reply-To: <3E61295E.9689D758@on-go.com>
Message-ID: <Pine.LNX.4.44.0303021941430.855-100000@swodniw.jive>


On Sat, 1 Mar 2003, thomas chen wrote:

> i have a structure that is 10 bytes long... on the target side
> (arm) arm-elf-gcc expand that to multiple of 4, ie 12 bytes...
> but on the intel pc side, it is still 10 bytes...  any way to pack
> the structure but without violating the arm alignment problem...
> ie if the structure is 9 byte long, i want to pack it to 10 instead
> of just 9....
>
> thanks
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org
>

Try declaring everything volatile (members and structure self): it should
work.

Regards

Giovanni Casoli




From g.menie at wanadoo.fr  Thu Mar  6 15:59:06 2003
From: g.menie at wanadoo.fr (Georges Menie)
Date: 06 Mar 2003 21:59:06 +0100
Subject: [uClinux-dev] mc68328digi.h for uclinux2.4.x
In-Reply-To: <20030306151154.7ea04fdc.philippe.ney@smartdata.ch>
References: <1046892047.1477.13.camel@troca> 
	<20030306151154.7ea04fdc.philippe.ney@smartdata.ch>
Message-ID: <1046984347.1362.12.camel@troca>

On Thu, 2003-03-06 at 15:11, Philippe Ney wrote:
> > I'm starting to work on a touchscreen driver for my 68VZ328 board, I
> > want to reuse the existing mc68328digi driver but the CVS repository for
> > uClinux.2.4.x does not contains linux-2.4.x/include/linux/mc68328digi.h.
> > 
> > there is a linux-2.4.X/drivers/char/mc68328digi.h but the c file
> > includes <linux/mc68628digi.h> and the .h in drivers/char seems to be a
> > leftover from a previous version, the driver does not compile with it.
> > 
> > I did copy the linux/mc68328digi.h from uClinux-2.0.x and had to modify
> > it a bit before compiling successfully the driver.
> > 
> > Does anybody knows if there is a uClinux-2.4.x version of this file ? 
> > 
> > The change I made were enough to compile, but may be the 2.4 version has
> > more changes which are necessary to make it work... I can't test it as
> > my hardware is diffferent. I would like to have a 'stable' base before
> > starting to adapt the driver.
> 
> Hi,
> 
> When I wrote the driver, the current kernel was the 2.0.38 one.
> I remember having added some beginning of a support for 2.2 kernels.
> But as I haven't use uClinux in its 2.4 kernel version, and nobody
> seems to contribute in the driver, I haven't done efforts to port it.
> 
> I saw later that 'Daniel Potts <danielp at cse.unsw.edu.au>' made the job.

yes, and he sent me the missing header, it is now in CVS. I'm going to
diff the 2.0 releases one by one and integrate the latest changes to the
2.4. Then start adapting the driver for my hardware.

> I'm happy seeing that the touch screen driver is not dead :)
> 
> If you have questions, feel free to ask me. I'll do my best to answer.

thank you, there is plenty of usefull comments in the source, that is
already helping a lot...

Georges



From sdeepa69 at yahoo.com  Thu Mar  6 16:46:03 2003
From: sdeepa69 at yahoo.com (Deepa Sivasankarane)
Date: Thu, 6 Mar 2003 13:46:03 -0800 (PST)
Subject: [uClinux-dev] system_call: entry.S - Please reply
In-Reply-To: <3E6543A7.3040308@snapgear.com>
Message-ID: <20030306214603.77431.qmail@web80405.mail.yahoo.com>


Could u please tell me what the "libc system call stub" files are , for m68knommu ?
Thanx,
regards,
Deepa
 Greg Ungerer <gerg at snapgear.com> wrote:Hi Deepa,

Deepa Sivasankarane wrote:
> In m68knommu/platform/5307/entry.S, return values of 
> system_call/syscall_trace
> 
> are in %d0. 
> 
> movel %d3,%a0
> jbsr %a0@
> movel %d0,%sp@(LD0) | save the return value 
> 
> Where does one specify that the return value of all system calls is in %d0 ?

Exactly what are you asking?

It is explicitly coded in this entry.S file and in the libc library
system call stubs that %d0 contains the return value. There is no
single place it is specified. It is a convention that the kernel
and library must follow for it to work.

Regards
Greg



------------------------------------------------------------------------
Greg Ungerer -- Chief Software Wizard EMAIL: gerg at snapgear.com
SnapGear Pty Ltd PHONE: +61 7 3435 2888
825 Stanley St, FAX: +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia WEB: www.SnapGear.com

_______________________________________________
uClinux-dev mailing list
uClinux-dev at uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev at uclinux.org


---------------------------------
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20030306/e08e027e/attachment.html>

From jwilliams at itee.uq.edu.au  Thu Mar  6 18:27:44 2003
From: jwilliams at itee.uq.edu.au (John Williams)
Date: Fri, 07 Mar 2003 09:27:44 +1000
Subject: [uClinux-dev] system_call: entry.S - Please reply
In-Reply-To: <20030306214603.77431.qmail@web80405.mail.yahoo.com>
References: <20030306214603.77431.qmail@web80405.mail.yahoo.com>
Message-ID: <3E67D970.3040902@itee.uq.edu.au>

Deepa Sivasankarane wrote:
> Could u please tell me what the "libc system call stub" files are , for 
> m68knommu ?

For user mode programs, such as 'ls', 'ps', and all the usual command 
line Un*x utilities, as well as application software, access to kernel 
capabilities and data structures (such as the file system, or memory) is 
provided via system calls.  User programs are not permitted to call the 
kernel directly, instead they must use wrapper (stub) functions.  For 
example, when you write a C program and say

FILE *myfile=fopen("filename.txt", "wt");

The 'fopen' function is provided by the C libraries, also known as 
"libc".  In the libraries, there is a wrapper function ("call stub") 
that gets the parameters necessary, then makes the actual system call 
via the macros defined in unistd.h.  This also explains why, as a rule, 
you can't call libc functions from within the kernel (Un*x gurus, is 
this correct?).

It sounds like you really need to find yourself a good book about the 
linux kernel.  I can recommend two books from O'Reailly - "Understanding 
the Linux Kernel", by Bovet & Cesati, and "Linux Device Drivers" by 
Rubini and Corbet.  There's also a fair bit of info out there on the 
internet, if you look hard enough.

Regards,

John



From davidm at snapgear.com  Thu Mar  6 18:57:17 2003
From: davidm at snapgear.com (David McCullough)
Date: Fri, 7 Mar 2003 09:57:17 +1000
Subject: [uClinux-dev] UCLINUX for PALM
In-Reply-To: <000201c2e41d$8eed5c20$ffc5fea9@henry133>
References: <Pine.GSO.4.33.0302070159150.23746-100000@compserv1> <000201c2cfbe$943f2fa0$ffc5fea9@henry133> <20030209232255.GA28757@beast.internal.moreton.com.au> <000701c2d0aa$a7f0f780$ffc5fea9@henry133> <20030210030607.GA4753@beast.internal.moreton.com.au> <001b01c2df42$376b2700$ffc5fea9@henry133> <20030303010709.GF17327@beast.internal.moreton.com.au> <000201c2e205$b337fd20$ffc5fea9@henry133> <20030304092301.GA5007@beast.internal.moreton.com.au> <000201c2e41d$8eed5c20$ffc5fea9@henry133>
Message-ID: <20030306235717.GC29475@beast.internal.moreton.com.au>

Jivin HenrySimmons17 lays it down ...
> Hello Davidm....
> > > > I usually run my IIIx without the fancy console this the current setup
> :-)
> > > How do you do this?
> >
> > Serial console on ttyS0.  I load the image down at 57600,  switch to
> > 9600 and then run PalmLoader to boot uClinux.
>
> I believe I see it. How do the kernel know to run the serial console?
> Did you put a statement in inittab or what?
> Henry

The console is automatically on (IIRC) and the CONFIG_USER_INIT_CONSOLE_SH
option tell init to auto add and entry for a sh on the serial port,

If you take the PalmIIIx config exactly as is you should have it,

Cheers,
Davidm

-- 
David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
davidm at snapgear.com  Fx: +61 7 3891 3630  Custom Embedded Solutions + Security


From gerg at snapgear.com  Thu Mar  6 19:15:06 2003
From: gerg at snapgear.com (Greg Ungerer)
Date: Fri, 07 Mar 2003 10:15:06 +1000
Subject: [uClinux-dev] RAM only filesystem
In-Reply-To: <1046966195.24356.9.camel@adams>
References: <3.0.32.20030305144616.01eb0bd0@klickitat.fial.com>	<1046907371.996.24.camel@adams>  <3E669399.8070808@snapgear.com> <1046966195.24356.9.camel@adams>
Message-ID: <3E67E48A.7090406@snapgear.com>

Hi Ryan,

Ryan Hulsker wrote:
> Greg,
> 	Thanks for your help, you pointed me in the right direction and I
> managed to get it working.
> 
>>Look at the mess of code in drivers/block/blkmem.c that deal
>>with this. It ain't pretty :-(
> 
> 
> 	Wow, you are not kidding.  Do you think there is any way to clean this
> stuff up, or is this just one of those things that has to be hard coded
> like that.  I'm just wondering if there might be a way to generalize
> that setup a little more, and maybe use a command line argument to start
> it off or something.

I am sure it could be cleaned up. Nobody much has had any interrest
in doing it though...

Moving forward most people are switching to using the MTD drivers,
its whole framework is more general. You can have specific map files
that absract this sort of setup out into its own code.

Regards
Greg


------------------------------------------------------------------------
Greg Ungerer  --  Chief Software Wizard        EMAIL:  gerg at snapgear.com
SnapGear Pty Ltd                               PHONE:    +61 7 3435 2888
825 Stanley St,                                  FAX:    +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia              WEB:   www.SnapGear.com



From gerg at snapgear.com  Thu Mar  6 19:22:19 2003
From: gerg at snapgear.com (Greg Ungerer)
Date: Fri, 07 Mar 2003 10:22:19 +1000
Subject: [uClinux-dev] FTP Server on the 5272 board
In-Reply-To: <BC03D160581F7A4E92710FC238282411167809@ici-mail.intellicom.se>
References: <BC03D160581F7A4E92710FC238282411167809@ici-mail.intellicom.se>
Message-ID: <3E67E63B.4000308@snapgear.com>

Hi Lars-Ake,

Lars-?ke Ekstrand wrote:
> There seems to be a ftp server in the new uClinux dist. At least there is a directory called user/ftpd. I just downloaded the dist so I haven't checked it further yet. Anyone who knows anything about this ftp daemon?

I have used it on VM targets with glibc, not sure if its
default setup is going to build against uClibc or uC-libc.
Shouldn't be too hard to get working with these though.

Regards
Greg



------------------------------------------------------------------------
Greg Ungerer  --  Chief Software Wizard        EMAIL:  gerg at snapgear.com
SnapGear Pty Ltd                               PHONE:    +61 7 3435 2888
825 Stanley St,                                  FAX:    +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia              WEB:   www.SnapGear.com



From gerg at snapgear.com  Thu Mar  6 19:34:55 2003
From: gerg at snapgear.com (Greg Ungerer)
Date: Fri, 07 Mar 2003 10:34:55 +1000
Subject: [uClinux-dev] system_call: entry.S - Please reply
In-Reply-To: <20030306214603.77431.qmail@web80405.mail.yahoo.com>
References: <20030306214603.77431.qmail@web80405.mail.yahoo.com>
Message-ID: <3E67E92F.50303@snapgear.com>

Hi Deepa,

Deepa Sivasankarane wrote:
> Could u please tell me what the "libc system call stub" files are , for 
> m68knommu ?

 from the kernel:

uClinux-2.4.x/include/asm-m68knommu/unistd.h


In older uC-libc:

uClinux-dist/lib/libc/sysdeps/*.S
uClinux-dist/lib/libc/sysdeps/m68k/sysdep.h


Or in uClibc:

uClibc/libc/sysdeps/linux/common/syscalls.c


Regards
Greg



------------------------------------------------------------------------
Greg Ungerer  --  Chief Software Wizard        EMAIL:  gerg at snapgear.com
SnapGear Pty Ltd                               PHONE:    +61 7 3435 2888
825 Stanley St,                                  FAX:    +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia              WEB:   www.SnapGear.com



From rebackhua at seu.edu.cn  Thu Mar  6 20:44:29 2003
From: rebackhua at seu.edu.cn (zhouhua)
Date: Fri, 7 Mar 2003 09:44:29 +0800
Subject: [uClinux-dev] problem about communication between processes
Message-ID: <00a201c2e44b$17db66d0$d10aa8c0@rebackhua>

Hi:
    I tried to communicate between two processes. I used pipe. It worked in uClinux. But if I use shared memory, it failed.
    I used shmctl shmget and shmptr functions. I don't know whether there is better way to exchange data between two processes. Could somebody tell me? Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20030307/e7b468ae/attachment.html>

From HenrySimmons17 at netzero.net  Thu Mar  6 20:41:37 2003
From: HenrySimmons17 at netzero.net (HenrySimmons17)
Date: Thu, 6 Mar 2003 17:41:37 -0800
Subject: [uClinux-dev] UCLINUX for PALM
References: <Pine.GSO.4.33.0302070159150.23746-100000@compserv1> <000201c2cfbe$943f2fa0$ffc5fea9@henry133> <20030209232255.GA28757@beast.internal.moreton.com.au> <000701c2d0aa$a7f0f780$ffc5fea9@henry133> <20030210030607.GA4753@beast.internal.moreton.com.au> <001b01c2df42$376b2700$ffc5fea9@henry133> <20030303010709.GF17327@beast.internal.moreton.com.au> <000201c2e205$b337fd20$ffc5fea9@henry133> <20030304092301.GA5007@beast.internal.moreton.com.au> <000201c2e41d$8eed5c20$ffc5fea9@henry133> <20030306235717.GC29475@beast.internal.moreton.com.au>
Message-ID: <000201c2e44c$19f92140$ffc5fea9@henry133>

Hello Davidm...
Thanks
Henry
> > > > > I usually run my IIIx without the fancy console this the current
setup
> > :-)
> > > > How do you do this?
> > >
> > > Serial console on ttyS0.  I load the image down at 57600,  switch to
> > > 9600 and then run PalmLoader to boot uClinux.
> >
> > I believe I see it. How do the kernel know to run the serial console?
> > Did you put a statement in inittab or what?
> > Henry
>
> The console is automatically on (IIRC) and the CONFIG_USER_INIT_CONSOLE_SH
> option tell init to auto add and entry for a sh on the serial port,
>
> If you take the PalmIIIx config exactly as is you should have it,
>
> Cheers,
> Davidm




From sanbhat at globaledgesoft.com  Fri Mar  7 00:18:48 2003
From: sanbhat at globaledgesoft.com (Santosh Bhat)
Date: Fri, 7 Mar 2003 10:48:48 +0530
Subject: [uClinux-dev] GDB enabled Make
References: <1046951202.1913.22.camel@tossu> <012001c2e3ef$5a241c00$800210ac@16.2.63.ges1> <3E676E65.83D7F26B@earthlink.net>
Message-ID: <019501c2e469$08c93be0$800210ac@16.2.63.ges1>

Hi Phil , I am using the Jtag , abatron to debug the code.Now the problem
what i am facing is to debug the assembly files. Since I have not included
the enable-debug option in the make config(which increase the size to 14-15
mb) , i am just able to get the object dump and I'll have to execute from
that.I am debugging the entry-armv.S .

I wanted to know is there any way , through which I can enable the debug
option for few related files , so taht i'll be able to debug along with the
code , than just debugging the dumped code.

How is the debugging of thease codes done by you and others any tip faqs on
this ??

Any help pointer on this is appreciated.
Thanx in advance for the help.
Regards
Santosh
----- Original Message -----
From: "Phil Wilshire" <philwil at earthlink.net>
To: <uclinux-dev at uclinux.org>
Sent: Thursday, March 06, 2003 9:21 PM
Subject: Re: [uClinux-dev] GDB enabled Make


> Hi Santosh,
> I am not sure how you are downloading to the target system but
> The inclusion of the debug information in the output file does not mean
that
> the actual system you load to the target system is the same size.
>
> The same goes for the user apps. The .gdb or .elf files may be larget but
the
> flat files are the same size.
>
> use arm-elf-objdump -h linux
> typical results shown
>
>
> Sections:
> Idx Name          Size      VMA       LMA       File off  Algn
>   0 .init         0000a000  01000000  01000000  00008000  2**5
>                   CONTENTS, ALLOC, LOAD, CODE
>   1 .text         0023a2c8  0100a000  0100a000  00012000  2**5
>                   CONTENTS, ALLOC, LOAD, READONLY, CODE
>   2 .data         0000964c  01246000  01246000  0024e000  2**5
>                   CONTENTS, ALLOC, LOAD, DATA
>   3 .bss          00022350  0124f660  0124f660  00257660  2**5
>                   ALLOC
>
> regards
>   Phil Wilshire
>
>
>
> Santosh Bhat wrote:
> >
> > Hi List ,
> > I am trying to debug the ARM7 core . I have a 8 mb ram . when I compile
the
> > code with debug enabled (without any applications ) it is coming up to
13-14
> > mb of which i will not be able to download in to my RAM . Is there any
way ,
> > selectively I can choose the files of which i want to debug , enable
only
> > those with -g so that I'll be able to debug from the source ???
> > If yes which are the dependencies/Make files i will have to examine ??
> >
> > Any help/pointer on this is appreciated.
> > Regards
> > Santosh Bhat
> >
> > _______________________________________________
> > uClinux-dev mailing list
> > uClinux-dev at uclinux.org
> > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> > This message was resent by uclinux-dev at uclinux.org
>
> --
> SDCS -- System Design & Consulting Services LLC, http://www.sysdcs.com
> ** Embedded Linux Training **  email me for details
> 630 Springhouse Sq., Leesburg VA 20175 t: 703 669 9766 f: 703 669 9768
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org
>



From fred.liu at motorola.com  Fri Mar  7 02:40:13 2003
From: fred.liu at motorola.com (Liu Fred-a18596)
Date: Fri, 7 Mar 2003 15:40:13 +0800 
Subject: [uClinux-dev] Is there a driver for FlexCAN in mcf5282?
Message-ID: <89DEFCC5DB33D411A27F00508BCF8A820BEBFE31@ZCH07EXM05.corp.mot.com>

Hi, greetings,
 
Is there a driver for FlexCAN in mcf5282?
 
Thanks,
Fred
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20030307/a478c469/attachment.html>

From fgiovag at tin.it  Fri Mar  7 03:03:04 2003
From: fgiovag at tin.it (Fabio Giovagnini)
Date: Fri, 7 Mar 2003 09:03:04 +0100
Subject: [uClinux-dev] structure size ????
In-Reply-To: <Pine.LNX.4.44.0303021941430.855-100000@swodniw.jive>
References: <Pine.LNX.4.44.0303021941430.855-100000@swodniw.jive>
Message-ID: <200303070903.05199.fgiovag@tin.it>

use __attribute__((packed,aligned(2)))

Let me know if it works.

Regards.

Alle 22:54, gioved? 6 marzo 2003, Giovanni Casoli ha scritto:
> On Sat, 1 Mar 2003, thomas chen wrote:
> > i have a structure that is 10 bytes long... on the target side
> > (arm) arm-elf-gcc expand that to multiple of 4, ie 12 bytes...
> > but on the intel pc side, it is still 10 bytes...  any way to pack
> > the structure but without violating the arm alignment problem...
> > ie if the structure is 9 byte long, i want to pack it to 10 instead
> > of just 9....
> >
> > thanks
> > _______________________________________________
> > uClinux-dev mailing list
> > uClinux-dev at uclinux.org
> > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> > This message was resent by uclinux-dev at uclinux.org
>
> Try declaring everything volatile (members and structure self): it should
> work.
>
> Regards
>
> Giovanni Casoli
>
>
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org



From rgegusch at mf.tu-berlin.de  Fri Mar  7 04:49:02 2003
From: rgegusch at mf.tu-berlin.de (Rene Gegusch)
Date: Fri, 7 Mar 2003 10:49:02 +0100
Subject: [uClinux-dev] FTP Server on the 5272 board
In-Reply-To: <3E66749F.90106@itee.uq.edu.au>
References: <200303051419.03570.rgegusch@mf.tu-berlin.de> <3E66749F.90106@itee.uq.edu.au>
Message-ID: <200303071049.02117.rgegusch@mf.tu-berlin.de>

Thank you, but I am not really interessted in a tftp server. By the way, the 
tftpd is already included in my uClinux distribution.
What about the new uClinux version and the included ftp server?
does it work?

Am Mittwoch, 5. M?rz 2003 23:05 schrieb John Williams:
> Rene Gegusch wrote:
> > Well, I am trying to implement a ftp server on the uClinux system.
> > finding the discussion mails of february and wonder if someone get a
> > working result.
> > I don not really need authentification, so I would also be happy with
> > anonymous ftp. Actually tried to compile anonftp.
> >
> > I would be pleased. about any help!
>
> I seem to recall that tftp (trivial FTP) now works "off the shelf" in
> uClinux.  I'm not sure whether 2.0.x or 2.4.x though, see the Feb.
> discussion to make sure.  I think you'd just have to select it as one of
> the networking apps to build/install in the kernel configuration process.
>
> If you can't find it let me know and I'll try to find the ugly hacked
> version that I put together last year.
>
> Once you get tftpd compiled, setting up a tftp server is pretty simple.
>   Google around for a bit and you should find something.
>
> Regards,
>
> John
>
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org




From n.ferre at i2e.fr  Fri Mar  7 04:53:56 2003
From: n.ferre at i2e.fr (Nicolas Ferre)
Date: Fri, 7 Mar 2003 10:53:56 +0100
Subject: [uClinux-dev] Tiny filesystem in ramdisk
In-Reply-To: <3E673F9A.6B32325B@earthlink.net>
Message-ID: <000001c2e48f$78e190a0$0e01a8c0@i2e.fr>

Hi,

> Ramfs should do this for you

> mount -t ramfs ramfs /var                                     

Yes, it seems quite easy to use...

My main hesitation in using it is that it has no size control option.
I have a look at tmpfs but it does not seems to be available under
uClinux does not it ? too bad...

Thanks for your help,

-- 
Nicolas Ferre, Software Engineer
@work : n.ferre at i2e.fr : http://www.i2e.fr : +33 4 42 60 70 76
@home : nferre at free.fr : http://nferre.free.fr


From rgegusch at mf.tu-berlin.de  Fri Mar  7 07:43:20 2003
From: rgegusch at mf.tu-berlin.de (Rene Gegusch)
Date: Fri, 7 Mar 2003 13:43:20 +0100
Subject: [uClinux-dev] FTPD on a 5272 system
In-Reply-To: <200303051419.03570.rgegusch@mf.tu-berlin.de>
References: <200303051419.03570.rgegusch@mf.tu-berlin.de>
Message-ID: <200303071343.20395.rgegusch@mf.tu-berlin.de>

first of all, I want to meantion that I did not checked the new distribution, 
because the download takes too long this day.

As many of you I am also interested in a ftp server for the coldfire 5272 
system. However, some of you seem already to use one on their system, their 
was also a link on the uclinux.net site before february.
As I understand, there are finally two ftp servers sucessfully compiled and 
running: anonftpd and pureftpd. But where are those projects?
Wouldn't it be a way to give those who don't know how to manage it the source 
and makefiles?
Some do have problems setting makefiles correctly for the mk68elf compiler. 
Please help us. :)

TFTPD = Tiny FTPD is not a solution for my case.



From rgegusch at mf.tu-berlin.de  Fri Mar  7 08:00:20 2003
From: rgegusch at mf.tu-berlin.de (Rene Gegusch)
Date: Fri, 7 Mar 2003 14:00:20 +0100
Subject: [uClinux-dev] FTP Server on the 5272 board
In-Reply-To: <BC03D160581F7A4E92710FC238282411167809@ici-mail.intellicom.se>
References: <BC03D160581F7A4E92710FC238282411167809@ici-mail.intellicom.se>
Message-ID: <200303071400.21002.rgegusch@mf.tu-berlin.de>

Thank you for the information.
It confusses me, that the download of the new distribution does not have it as 
you told us.
My distribution file has a size of about 105mb, seems to be OK, doesn't it?
But there is no user directory in it and I feel a little bit bad now.
I am also thankfull of mailing me the ftpd server :)

Thanx

Am Donnerstag, 6. M?rz 2003 09:21 schrieb Lars-?ke Ekstrand:
> Hi,
>
> There seems to be a ftp server in the new uClinux dist. At least there is a
> directory called user/ftpd. I just downloaded the dist so I haven't checked
> it further yet. Anyone who knows anything about this ftp daemon?
>
> /Regards
> Lars-Ake
>
>
> -----Original Message-----
> From: Rene Gegusch [mailto:rgegusch at mf.tu-berlin.de]
> Sent: den 5 mars 2003 14:19
> To: uclinux-dev at uclinux.org
> Subject: [uClinux-dev] FTP Server on the 5272 board
>
>
> Well, I am trying to implement a ftp server on the uClinux system. finding
> the discussion mails of february and wonder if someone get a working
> result.
> I don not really need authentification, so I would also be happy with
> anonymous ftp. Actually tried to compile anonftp.
>
> I would be pleased. about any help!
>
>
>
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was
> resent by uclinux-dev at uclinux.org
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org




From philwil at earthlink.net  Fri Mar  7 07:55:56 2003
From: philwil at earthlink.net (Phil Wilshire)
Date: Fri, 07 Mar 2003 07:55:56 -0500
Subject: [uClinux-dev] GDB enabled Make
References: <1046951202.1913.22.camel@tossu> <012001c2e3ef$5a241c00$800210ac@16.2.63.ges1> <3E676E65.83D7F26B@earthlink.net> <019501c2e469$08c93be0$800210ac@16.2.63.ges1>
Message-ID: <3E6896DC.687C5C58@earthlink.net>

HI Santoosh,
I tend not to depend on debuggers fro these sort of problems.

I isolate the test case and use flashing leds or serial port output to see what I am doing.

You can also use the technique of putting numbers into locations or even using a memory buffer to
drop printk data into.

I agree that sometimes this may take longet than using a proper debugger.

Lets see wht the others say.

  regards
     Phil

Santosh Bhat wrote:
> 
> Hi Phil , I am using the Jtag , abatron to debug the code.Now the problem
> what i am facing is to debug the assembly files. Since I have not included
> the enable-debug option in the make config(which increase the size to 14-15
> mb) , i am just able to get the object dump and I'll have to execute from
> that.I am debugging the entry-armv.S .
> 
> I wanted to know is there any way , through which I can enable the debug
> option for few related files , so taht i'll be able to debug along with the
> code , than just debugging the dumped code.
> 
> How is the debugging of thease codes done by you and others any tip faqs on
> this ??
> 
> Any help pointer on this is appreciated.
> Thanx in advance for the help.
> Regards
> Santosh
> ----- Original Message -----
> From: "Phil Wilshire" <philwil at earthlink.net>
> To: <uclinux-dev at uclinux.org>
> Sent: Thursday, March 06, 2003 9:21 PM
> Subject: Re: [uClinux-dev] GDB enabled Make
> 
> > Hi Santosh,
> > I am not sure how you are downloading to the target system but
> > The inclusion of the debug information in the output file does not mean
> that
> > the actual system you load to the target system is the same size.
> >
> > The same goes for the user apps. The .gdb or .elf files may be larget but
> the
> > flat files are the same size.
> >
> > use arm-elf-objdump -h linux
> > typical results shown
> >
> >
> > Sections:
> > Idx Name          Size      VMA       LMA       File off  Algn
> >   0 .init         0000a000  01000000  01000000  00008000  2**5
> >                   CONTENTS, ALLOC, LOAD, CODE
> >   1 .text         0023a2c8  0100a000  0100a000  00012000  2**5
> >                   CONTENTS, ALLOC, LOAD, READONLY, CODE
> >   2 .data         0000964c  01246000  01246000  0024e000  2**5
> >                   CONTENTS, ALLOC, LOAD, DATA
> >   3 .bss          00022350  0124f660  0124f660  00257660  2**5
> >                   ALLOC
> >
> > regards
> >   Phil Wilshire
> >
> >
> >
> > Santosh Bhat wrote:
> > >
> > > Hi List ,
> > > I am trying to debug the ARM7 core . I have a 8 mb ram . when I compile
> the
> > > code with debug enabled (without any applications ) it is coming up to
> 13-14
> > > mb of which i will not be able to download in to my RAM . Is there any
> way ,
> > > selectively I can choose the files of which i want to debug , enable
> only
> > > those with -g so that I'll be able to debug from the source ???
> > > If yes which are the dependencies/Make files i will have to examine ??
> > >
> > > Any help/pointer on this is appreciated.
> > > Regards
> > > Santosh Bhat
> > >
> > > _______________________________________________
> > > uClinux-dev mailing list
> > > uClinux-dev at uclinux.org
> > > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> > > This message was resent by uclinux-dev at uclinux.org
> >
> > --
> > SDCS -- System Design & Consulting Services LLC, http://www.sysdcs.com
> > ** Embedded Linux Training **  email me for details
> > 630 Springhouse Sq., Leesburg VA 20175 t: 703 669 9766 f: 703 669 9768
> > _______________________________________________
> > uClinux-dev mailing list
> > uClinux-dev at uclinux.org
> > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> > This message was resent by uclinux-dev at uclinux.org
> >
> 
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org

-- 
SDCS -- System Design & Consulting Services LLC, http://www.sysdcs.com
** Embedded Linux Training **  email me for details  
630 Springhouse Sq., Leesburg VA 20175 t: 703 669 9766 f: 703 669 9768


From gerg at snapgear.com  Fri Mar  7 08:44:11 2003
From: gerg at snapgear.com (Greg Ungerer)
Date: Fri, 07 Mar 2003 23:44:11 +1000
Subject: [uClinux-dev] FTP Server on the 5272 board
In-Reply-To: <200303071400.21002.rgegusch@mf.tu-berlin.de>
References: <BC03D160581F7A4E92710FC238282411167809@ici-mail.intellicom.se> <200303071400.21002.rgegusch@mf.tu-berlin.de>
Message-ID: <3E68A22B.9050901@snapgear.com>

Hi Rene,

Rene Gegusch wrote:
> Thank you for the information.
> It confusses me, that the download of the new distribution does not have it as 
> you told us.
> My distribution file has a size of about 105mb, seems to be OK, doesn't it?

The latest distribution definately contains a uClinux-dist/user/ftpd
directory. If you don't have one then either you don't have the latest
distribution or it is corrupted.

Regards
Greg



------------------------------------------------------------------------
Greg Ungerer  --  Chief Software Wizard        EMAIL:  gerg at snapgear.com
SnapGear Pty Ltd                               PHONE:    +61 7 3435 2888
825 Stanley St,                                  FAX:    +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia              WEB:   www.SnapGear.com



From bas at acter.ch  Fri Mar  7 03:41:15 2003
From: bas at acter.ch (Tarkan Bas)
Date: Fri, 07 Mar 2003 09:41:15 +0100
Subject: [uClinux-dev] coldfire pio driver
References: <r01050400-1024-2CAE85044FE411D7ADFD00039387ACB6@[10.0.1.2]>
Message-ID: <3E685B2B.780AD95D@acter.ch>

Richard Klingler wrote:
> 
> > this is actually what I want. A kernel driver with interrupt handlers
> > for coldfire M5249. I found a T6963 driver (as far as I see it can be
> > used in pio mode, too) in config.in file in /Linux-x.x.x/drivers/char
> > directory but no .c file for that driver. Maybe this could be what I
> > want. does someone know where is the C-file for T6963 driver.????
> 
> 1. You didn't look into 2.0.x....otherwise you would have found it (o;
you are right! I am working with kernel 2.4
> 
> 2. Isn't a framebuffer device a little overkill to use as base for
>    a simple GPIO driver with interrupts?

It seem to be so. I'll take another char driver file as base for gpio
driver.

thanks

Tarkan
> 
> Rick (o;
> 
> Richard Klingler             mail: richard.klingler at violasystems.com
> Viola Systems Ltd.           http://www.violasystems.com/
> Lemmink?isenkatu 32          phon: +358 (0)201 226 226
> 20520 Turku, Finland         mobile: +358 (0)40 748 4711
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org


From hamilton at SEDSystems.ca  Fri Mar  7 09:33:54 2003
From: hamilton at SEDSystems.ca (Kendrick Hamilton)
Date: Fri, 7 Mar 2003 08:33:54 -0600 (Canada Central Standard Time)
Subject: [uClinux-dev] problem about communication between processes
In-Reply-To: <00a201c2e44b$17db66d0$d10aa8c0@rebackhua>
Message-ID: <Pine.WNT.4.44.0303070833280.219-100000@sw-55.sedsystems.ca>

Shared memory does not work in the 2.0.x kernel. It may work in the 2.4.x
kernel.

On Fri, 7 Mar 2003, zhouhua wrote:

> Hi:
>     I tried to communicate between two processes. I used pipe. It worked in uClinux. But if I use shared memory, it failed.
>     I used shmctl shmget and shmptr functions. I don't know whether there is better way to exchange data between two processes. Could somebody tell me? Thanks.
>



From kadionik at enseirb.fr  Fri Mar  7 10:12:58 2003
From: kadionik at enseirb.fr (Patrice Kadionik)
Date: Fri, 07 Mar 2003 16:12:58 +0100
Subject: [uClinux-dev] How to use SNMPD
In-Reply-To: <3E262AA8.4C8806CC@earthlink.net>
References: <03b501c2bc68$0e33c650$8301a8c0@asic.net> <3E25229F.E14BD9FD@enseirb.fr> <3E262AA8.4C8806CC@earthlink.net>
Message-ID: <3E68B6FA.5050605@enseirb.fr>

Hi Phil,

I finished the translation in english language of my article on SNMP and 
uclinux...it's available on line here :
http://www.enseirb.fr/~kadionik/embedded/snmp/english/net-snmp_english.html

Yes, you may use it in your training. Perhaps we can do a material 
exchange...I have written some exercices on this theme for practical 
exercices on uclinux for my students... I'll can give you it...I'm 
interested by your formation...:
SDCS uClinux Munich Workshop.

Target Systems

   AT91 ArmTwister 2M FLash 8M Ram
   SnapGear Lite 5272 2M Flash 4M Ram
   uCDimm   VZ328 or 5272 2M FLash  8M Ram


This is an overview of topics covered in the workshop.
Phil Wilshire and Erwin Authried are continually developing more interesting
material to add to the course.


in order to complete mine... My course on embedded systems and uclinux 
is online in my web page....

sincerely Yours;
Pat.



Phil Wilshire wrote:

>HI Patrice,
>If I have time to do the translation and if you are in agreement I would
>like to include this page 
>( translated into english ) in my training.
>
>Would you agree to my doing this ???
>
>This is a very nice article.
>
>If you agree I'll post it on uCdot as well.
>
>Your name will remain as the author.
>
>I'll pass approval of teh translation to you.
>
>best regards
>Phil Wilshire
>
>
>Patrice Kadionik wrote:
>  
>
>>Hi lee
>>
>>I've done an article on NET-SNMP in Linux Magazine, a french magazine on Linux...
>>You have a HOWTO in it for Linux and ?Clinux.
>>It's here (in french language) :
>>http://www.enseirb.fr/~kadionik/embedded/snmp/net-snmp.html
>>you have my examples online too :-) (for linux and ?Clinux)
>>
>>pat.
>>
>>Lee CHang Soo wrote:
>>
>>    
>>
>>>Dear Evenryone.
>>>
>>>I'l like to use "snmpd" registered in userland.
>>>But I can't find useful reference book for using snmpd in linux(uClinux environment)
>>>Could you introduce some useful reference guide for snmpd in linux?
>>>
>>>Thanks in advance
>>>//////////////////////////////////
>>>LEE CHANG SOO
>>>cslee at glotrex.co.kr
>>>Senior Engineering Manager,
>>>GLOTREX Corp. Seoul, Korea
>>>www.glotrex.co.kr
>>>TEL) 82-2-2142-1704
>>>FAX) 82-2-2142-1710
>>>MOB) 82-16-368-2916
>>>//////////////////////////////////
>>>_______________________________________________
>>>uClinux-dev mailing list
>>>uClinux-dev at uclinux.org
>>>http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
>>>This message was resent by uclinux-dev at uclinux.org
>>>      
>>>
>>--
>>Patrice Kadionik. F6KQH / F4CUQ
>>-----------
>>
>>+---------------------------------------------------------------------+
>>+"Tout doit etre aussi simple que possible, pas seulement plus simple"+
>>+---------------------------------------------------------------------+
>>+ Patrice Kadionik                http://www.enseirb.fr/~kadionik     +
>>+ ENSEIRB                         fax   : +33 5.56.37.20.23           +
>>+ PO BOX 99                       voice : +33 5.56.84.23.47           +
>>+ 33402 TALENCE Cedex             http://www.enseirb.fr               +
>>+ FRANCE                          mailto:kadionik at enseirb.fr          +
>>+---------------------------------------------------------------------+
>>
>>_______________________________________________
>>uClinux-dev mailing list
>>uClinux-dev at uclinux.org
>>http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
>>This message was resent by uclinux-dev at uclinux.org
>>    
>>
>
>  
>


-- 
Patrice Kadionik. F6KQH / F4CUQ
-----------

+---------------------------------------------------------------------+
+"Tout doit etre aussi simple que possible, pas seulement plus simple"+
+---------------------------------------------------------------------+
+ Patrice Kadionik                http://www.enseirb.fr/~kadionik     +
+ ENSEIRB                         fax   : +33 5.56.37.20.23           +
+ PO BOX 99                       voice : +33 5.56.84.23.47           +
+ 33402 TALENCE Cedex             http://www.enseirb.fr               +
+ FRANCE                          mailto:kadionik at enseirb.fr          +
+---------------------------------------------------------------------+




From kadionik at enseirb.fr  Fri Mar  7 10:21:10 2003
From: kadionik at enseirb.fr (Patrice Kadionik)
Date: Fri, 07 Mar 2003 16:21:10 +0100
Subject: [uClinux-dev] How to use SNMPD
In-Reply-To: <3E262AA8.4C8806CC@earthlink.net>
References: <03b501c2bc68$0e33c650$8301a8c0@asic.net> <3E25229F.E14BD9FD@enseirb.fr> <3E262AA8.4C8806CC@earthlink.net>
Message-ID: <3E68B8E6.4010506@enseirb.fr>

Phil,
I've posted my article to ucdot.org...
cheers;
pat
Phil Wilshire wrote:

>HI Patrice,
>If I have time to do the translation and if you are in agreement I would
>like to include this page 
>( translated into english ) in my training.
>
>Would you agree to my doing this ???
>
>This is a very nice article.
>
>If you agree I'll post it on uCdot as well.
>
>Your name will remain as the author.
>
>I'll pass approval of teh translation to you.
>
>best regards
>Phil Wilshire
>
>
>Patrice Kadionik wrote:
>  
>
>>Hi lee
>>
>>I've done an article on NET-SNMP in Linux Magazine, a french magazine on Linux...
>>You have a HOWTO in it for Linux and ?Clinux.
>>It's here (in french language) :
>>http://www.enseirb.fr/~kadionik/embedded/snmp/net-snmp.html
>>you have my examples online too :-) (for linux and ?Clinux)
>>
>>pat.
>>
>>Lee CHang Soo wrote:
>>
>>    
>>
>>>Dear Evenryone.
>>>
>>>I'l like to use "snmpd" registered in userland.
>>>But I can't find useful reference book for using snmpd in linux(uClinux environment)
>>>Could you introduce some useful reference guide for snmpd in linux?
>>>
>>>Thanks in advance
>>>//////////////////////////////////
>>>LEE CHANG SOO
>>>cslee at glotrex.co.kr
>>>Senior Engineering Manager,
>>>GLOTREX Corp. Seoul, Korea
>>>www.glotrex.co.kr
>>>TEL) 82-2-2142-1704
>>>FAX) 82-2-2142-1710
>>>MOB) 82-16-368-2916
>>>//////////////////////////////////
>>>_______________________________________________
>>>uClinux-dev mailing list
>>>uClinux-dev at uclinux.org
>>>http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
>>>This message was resent by uclinux-dev at uclinux.org
>>>      
>>>
>>--
>>Patrice Kadionik. F6KQH / F4CUQ
>>-----------
>>
>>+---------------------------------------------------------------------+
>>+"Tout doit etre aussi simple que possible, pas seulement plus simple"+
>>+---------------------------------------------------------------------+
>>+ Patrice Kadionik                http://www.enseirb.fr/~kadionik     +
>>+ ENSEIRB                         fax   : +33 5.56.37.20.23           +
>>+ PO BOX 99                       voice : +33 5.56.84.23.47           +
>>+ 33402 TALENCE Cedex             http://www.enseirb.fr               +
>>+ FRANCE                          mailto:kadionik at enseirb.fr          +
>>+---------------------------------------------------------------------+
>>
>>_______________________________________________
>>uClinux-dev mailing list
>>uClinux-dev at uclinux.org
>>http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
>>This message was resent by uclinux-dev at uclinux.org
>>    
>>
>
>  
>


-- 
Patrice Kadionik. F6KQH / F4CUQ
-----------

+---------------------------------------------------------------------+
+"Tout doit etre aussi simple que possible, pas seulement plus simple"+
+---------------------------------------------------------------------+
+ Patrice Kadionik                http://www.enseirb.fr/~kadionik     +
+ ENSEIRB                         fax   : +33 5.56.37.20.23           +
+ PO BOX 99                       voice : +33 5.56.84.23.47           +
+ 33402 TALENCE Cedex             http://www.enseirb.fr               +
+ FRANCE                          mailto:kadionik at enseirb.fr          +
+---------------------------------------------------------------------+




From philwil at earthlink.net  Fri Mar  7 10:36:11 2003
From: philwil at earthlink.net (Phil Wilshire)
Date: Fri, 07 Mar 2003 10:36:11 -0500
Subject: [uClinux-dev] How to use SNMPD
References: <03b501c2bc68$0e33c650$8301a8c0@asic.net> <3E25229F.E14BD9FD@enseirb.fr> <3E262AA8.4C8806CC@earthlink.net> <3E68B8E6.4010506@enseirb.fr>
Message-ID: <3E68BC6B.4EC5EEC@earthlink.net>

HI Patrice
Great job
Thanks

  regards
      Phil

Patrice Kadionik wrote:
> 
> Phil,
> I've posted my article to ucdot.org...
> cheers;
> pat
> Phil Wilshire wrote:
> 
> >HI Patrice,
> >If I have time to do the translation and if you are in agreement I would
> >like to include this page
> >( translated into english ) in my training.
> >
> >Would you agree to my doing this ???
> >
> >This is a very nice article.
> >
> >If you agree I'll post it on uCdot as well.
> >
> >Your name will remain as the author.
> >
> >I'll pass approval of teh translation to you.
> >
> >best regards
> >Phil Wilshire
> >
> >
> >Patrice Kadionik wrote:
> >
> >
> >>Hi lee
> >>
> >>I've done an article on NET-SNMP in Linux Magazine, a french magazine on Linux...
> >>You have a HOWTO in it for Linux and ?Clinux.
> >>It's here (in french language) :
> >>http://www.enseirb.fr/~kadionik/embedded/snmp/net-snmp.html
> >>you have my examples online too :-) (for linux and ?Clinux)
> >>
> >>pat.
> >>
> >>Lee CHang Soo wrote:
> >>
> >>
> >>
> >>>Dear Evenryone.
> >>>
> >>>I'l like to use "snmpd" registered in userland.
> >>>But I can't find useful reference book for using snmpd in linux(uClinux environment)
> >>>Could you introduce some useful reference guide for snmpd in linux?
> >>>
> >>>Thanks in advance
> >>>//////////////////////////////////
> >>>LEE CHANG SOO
> >>>cslee at glotrex.co.kr
> >>>Senior Engineering Manager,
> >>>GLOTREX Corp. Seoul, Korea
> >>>www.glotrex.co.kr
> >>>TEL) 82-2-2142-1704
> >>>FAX) 82-2-2142-1710
> >>>MOB) 82-16-368-2916
> >>>//////////////////////////////////
> >>>_______________________________________________
> >>>uClinux-dev mailing list
> >>>uClinux-dev at uclinux.org
> >>>http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> >>>This message was resent by uclinux-dev at uclinux.org
> >>>
> >>>
> >>--
> >>Patrice Kadionik. F6KQH / F4CUQ
> >>-----------
> >>
> >>+---------------------------------------------------------------------+
> >>+"Tout doit etre aussi simple que possible, pas seulement plus simple"+
> >>+---------------------------------------------------------------------+
> >>+ Patrice Kadionik                http://www.enseirb.fr/~kadionik     +
> >>+ ENSEIRB                         fax   : +33 5.56.37.20.23           +
> >>+ PO BOX 99                       voice : +33 5.56.84.23.47           +
> >>+ 33402 TALENCE Cedex             http://www.enseirb.fr               +
> >>+ FRANCE                          mailto:kadionik at enseirb.fr          +
> >>+---------------------------------------------------------------------+
> >>
> >>_______________________________________________
> >>uClinux-dev mailing list
> >>uClinux-dev at uclinux.org
> >>http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> >>This message was resent by uclinux-dev at uclinux.org
> >>
> >>
> >
> >
> >
> 
> --
> Patrice Kadionik. F6KQH / F4CUQ
> -----------
> 
> +---------------------------------------------------------------------+
> +"Tout doit etre aussi simple que possible, pas seulement plus simple"+
> +---------------------------------------------------------------------+
> + Patrice Kadionik                http://www.enseirb.fr/~kadionik     +
> + ENSEIRB                         fax   : +33 5.56.37.20.23           +
> + PO BOX 99                       voice : +33 5.56.84.23.47           +
> + 33402 TALENCE Cedex             http://www.enseirb.fr               +
> + FRANCE                          mailto:kadionik at enseirb.fr          +
> +---------------------------------------------------------------------+
> 
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org

-- 
SDCS -- System Design & Consulting Services LLC, http://www.sysdcs.com
** Embedded Linux Training **  email me for details  
630 Springhouse Sq., Leesburg VA 20175 t: 703 669 9766 f: 703 669 9768


From HenrySimmons17 at netzero.net  Fri Mar  7 12:43:59 2003
From: HenrySimmons17 at netzero.net (HenrySimmons17)
Date: Fri, 7 Mar 2003 09:43:59 -0800
Subject: [uClinux-dev] UCLINUX for PALM
References: <Pine.GSO.4.33.0303070438060.4078-100000@sbpub1>
Message-ID: <000001c2e4d1$608f5860$ffc5fea9@henry133>

Hello Sumit...
Sumit wrote...
> I have compiled the uclinux for m125 with 8MB RAM and 4MB ROM with the
> changes which you told me earlier to make in 3-4 files. Now I am trying to
> download it on Plam via hotsynch, it got downloaded. But when I started
> booting the uClinux kernel, it shows me the penguin image and then nothing
> else goes. What can be the reason ?

Note: Console support  (CONFIG_CONSOLE)   [ Y/n? ] y
          Frame buffer  (CONFIG_FRAMEBUFFER)  [ Y/n? ] y
          Pilot console  (CONFIG_PILOT_CONSOLE)  [Y/n? ] y

If you are using make xconfig  these are under General support.
        Console support y
        Frame buffer y
        Pilot console y
In either case all 3 must be set to Y.
Henry



From stuartm at connecttech.com  Fri Mar  7 15:21:19 2003
From: stuartm at connecttech.com (Stuart MacDonald)
Date: Fri, 7 Mar 2003 15:21:19 -0500
Subject: from the archives + questions about fec.c: Re: [uClinux-dev] coldfire fec.c ethernet driver
References: <r01050400-1021-A15DB804D75F11D6B03300039387ACB6@[10.0.1.2]>
Message-ID: <044401c2e4e7$1d73c5a0$294b82ce@connecttech.com>

From: "Richard Klingler" <richard.klingler at violasystems.com>
Sent: October 4, 2002 1:07 a
> > Richard Klingler wrote:
> > > The coldfire ethernet driver registers the PHY interrupt before
> > > it detects a valid PHY (o;
> > >
> > > So IRQ66 (INT2) is always bound to fec.c even the PHY is of type
> > "unknown".
> > >
> > > What you think Greg? Is it safe to just enable the IRQ66
> > > inside "mii_discover_phy3" ?
> >
> > I think that is good. (In fact it is definately better to not
> > enable the IRQ until then :-)
>
> Here is the patch against the latest CVS source (o;
> It moves the IRQ registering (M5272) into "mii_discover_phy3".
> I don't know about the other supported CPU's (o;

The M5272 user manual states that it's best to use the mii interrupt
to ensure that the mii interface doesn't munge itself. Since the phy
detection uses the interface, shouldn't the interrupt be enabled
first? OTOH, even with it enabled I don't see any interrupts happening
as a result of the phy detection, so I guess it's not necessary.

I'm having problems getting the phy detection code to recognise our
LXT972A. I've moved the interrupt and icrp references (we've got the
mii interrupt on INT3 instead of INT2). I've checked that the mii
commands are built properly. What seems to happen is that garbage is
read from the phy. If anyone has any insight, I'd appreciate it.

Using 20020927, and tools 20020410. Searched the list archive, found
nothing relevant, except the thread I'm replying to.

One question: apparently our phy is phy # 0xb. Neither the phy data
sheet or the CPU data sheet states how a phy's "address" is
determined. Is that a funtion of the hardwiring?

..Stu




From hamilton at SEDSystems.ca  Fri Mar  7 15:29:01 2003
From: hamilton at SEDSystems.ca (Kendrick Hamilton)
Date: Fri, 7 Mar 2003 14:29:01 -0600 (CST)
Subject: [uClinux-dev] Xilnx CPLD problems
Message-ID: <Pine.LNX.4.44.0303071422450.2095-100000@sw-55.sedsystems.ca>

I am using Xilinx webpack tools to compile verilog CPLD code for a CPLD on 
a new board we are building. Unfortunately the tools are recognizing that 
I am using flip-flops in the design but optimizing them away. The 
behaviour model works correctly but the post synthesis model does not 
work. If anybody has any suggestion, they would be much appreciated.

I know that this is not the best forum but I thought I would send out a 
request for help here because I am sure there are people on this list that 
know about this. 

TIA
-- 
Kendrick Hamilton E.I.T.
SED Systems, a division of Calian Ltd.
18 Innovation Blvd.
PO Box 1464
Saskatoon, Saskatchewan
Canada
S7N 3R1

Hamilton at sedsystems.ca
Tel: (306) 933-1453
Fax: (306) 933-1486



From tchen at on-go.com  Fri Mar  7 16:48:43 2003
From: tchen at on-go.com (thomas chen)
Date: Fri, 07 Mar 2003 16:48:43 -0500
Subject: [uClinux-dev] Xilnx CPLD problems
References: <Pine.LNX.4.44.0303071422450.2095-100000@sw-55.sedsystems.ca>
Message-ID: <3E6913BB.FAE632F3@on-go.com>

which fammily are you using

XC9500 family???

Kendrick Hamilton wrote:
> 
> I am using Xilinx webpack tools to compile verilog CPLD code for a CPLD on
> a new board we are building. Unfortunately the tools are recognizing that
> I am using flip-flops in the design but optimizing them away. The
> behaviour model works correctly but the post synthesis model does not
> work. If anybody has any suggestion, they would be much appreciated.
> 
> I know that this is not the best forum but I thought I would send out a
> request for help here because I am sure there are people on this list that
> know about this.
> 
> TIA
> --
> Kendrick Hamilton E.I.T.
> SED Systems, a division of Calian Ltd.
> 18 Innovation Blvd.
> PO Box 1464
> Saskatoon, Saskatchewan
> Canada
> S7N 3R1
> 
> Hamilton at sedsystems.ca
> Tel: (306) 933-1453
> Fax: (306) 933-1486
> 
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org


From hamilton at SEDSystems.ca  Fri Mar  7 16:57:25 2003
From: hamilton at SEDSystems.ca (Kendrick Hamilton)
Date: Fri, 7 Mar 2003 15:57:25 -0600 (CST)
Subject: [uClinux-dev] Xilnx CPLD problems
In-Reply-To: <3E6913BB.FAE632F3@on-go.com>
Message-ID: <Pine.LNX.4.44.0303071556110.2614-100000@sw-55.sedsystems.ca>

I am using an XC9572XL.
Kendrick

On Fri, 7 Mar 2003, thomas chen wrote:

> 
> which fammily are you using
> 
> XC9500 family???
> 
> Kendrick Hamilton wrote:
> > 
> > I am using Xilinx webpack tools to compile verilog CPLD code for a CPLD on
> > a new board we are building. Unfortunately the tools are recognizing that
> > I am using flip-flops in the design but optimizing them away. The
> > behaviour model works correctly but the post synthesis model does not
> > work. If anybody has any suggestion, they would be much appreciated.
> > 
> > I know that this is not the best forum but I thought I would send out a
> > request for help here because I am sure there are people on this list that
> > know about this.
> > 
> > TIA
> > --
> > Kendrick Hamilton E.I.T.
> > SED Systems, a division of Calian Ltd.
> > 18 Innovation Blvd.
> > PO Box 1464
> > Saskatoon, Saskatchewan
> > Canada
> > S7N 3R1
> > 
> > Hamilton at sedsystems.ca
> > Tel: (306) 933-1453
> > Fax: (306) 933-1486
> > 



From tchen at on-go.com  Fri Mar  7 17:30:13 2003
From: tchen at on-go.com (thomas chen)
Date: Fri, 07 Mar 2003 17:30:13 -0500
Subject: [uClinux-dev] Xilnx CPLD problems
References: <Pine.LNX.4.44.0303071556110.2614-100000@sw-55.sedsystems.ca>
Message-ID: <3E691D75.71280367@on-go.com>

are you using Ver 4 or Ver 5 of WebPack?  (but we better do this offline
since it is not related to uclinux)

Kendrick Hamilton wrote:
> 
> I am using an XC9572XL.
> Kendrick
> 
> On Fri, 7 Mar 2003, thomas chen wrote:
> 
> >
> > which fammily are you using
> >
> > XC9500 family???
> >
> > Kendrick Hamilton wrote:
> > >
> > > I am using Xilinx webpack tools to compile verilog CPLD code for a CPLD on
> > > a new board we are building. Unfortunately the tools are recognizing that
> > > I am using flip-flops in the design but optimizing them away. The
> > > behaviour model works correctly but the post synthesis model does not
> > > work. If anybody has any suggestion, they would be much appreciated.
> > >
> > > I know that this is not the best forum but I thought I would send out a
> > > request for help here because I am sure there are people on this list that
> > > know about this.
> > >
> > > TIA
> > > --
> > > Kendrick Hamilton E.I.T.
> > > SED Systems, a division of Calian Ltd.
> > > 18 Innovation Blvd.
> > > PO Box 1464
> > > Saskatoon, Saskatchewan
> > > Canada
> > > S7N 3R1
> > >
> > > Hamilton at sedsystems.ca
> > > Tel: (306) 933-1453
> > > Fax: (306) 933-1486
> > >
> 
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org


From westcose at nologin.org  Fri Mar  7 09:55:46 2003
From: westcose at nologin.org (Brian Cavenah)
Date: Fri, 7 Mar 2003 06:55:46 -0800
Subject: [uClinux-dev] uClinux/embedded software IRC channel??
Message-ID: <20030307145546.GA2026@nologin.org>

Does anybody know if there is a uClinux and/or embedded systems type irc
channel?  


From richard.klingler at violasystems.com  Sat Mar  8 02:46:02 2003
From: richard.klingler at violasystems.com (Richard Klingler)
Date: Sat,  8 Mar 2003 09:46:02 +0200
Subject: [uClinux-dev] uClinux/embedded software IRC channel??
In-Reply-To: <20030307145546.GA2026@nologin.org>
Message-ID: <r01050400-1024-040077B9513A11D7AF1700039387ACB6@[10.0.1.2]>

> Does anybody know if there is a uClinux and/or embedded systems type irc
> channel?  

I've setup one...seems that most people aren't familiar
with irc at all *gg or even with UNIX (o;

    #uclinux @ irc.uclinux.net

Rick

If more people would join it would be a really helpful place..
although it looks that in many countries DSL isn't common (o;


Richard Klingler             mail: richard.klingler at violasystems.com
Viola Systems Ltd.           http://www.violasystems.com/
Lemmink?isenkatu 32          phon: +358 (0)201 226 226
20520 Turku, Finland         mobile: +358 (0)40 748 4711


From richard.klingler at violasystems.com  Sat Mar  8 06:04:04 2003
From: richard.klingler at violasystems.com (Richard Klingler)
Date: Sat,  8 Mar 2003 13:04:04 +0200
Subject: [uClinux-dev] bootloader environment
In-Reply-To: <r01050400-1024-040077B9513A11D7AF1700039387ACB6@[10.0.1.2]>
Message-ID: <r01050400-1024-ACE62AFB515511D7AF1700039387ACB6@[10.0.1.2]>

Good afternoon...(o;


Someone needs to access bootloader environment in uClinux?


Wrote some really small proc handler which gives
dynamically all environments defined in ppcboot
and u-boot as individual files under /proc:

# ls -l proc/viola
-rw-r--r--    1 0        0               0 Jan  1 00:31 baudrate
-rw-r--r--    1 0        0               0 Jan  1 00:31 bootcmd
-rw-r--r--    1 0        0               0 Jan  1 00:31 bootdelay
-rw-r--r--    1 0        0               0 Jan  1 00:31 ethaddr
-rw-r--r--    1 0        0               0 Jan  1 00:31 filesize
-rw-r--r--    1 0        0               0 Jan  1 00:31 gatewayip
-rw-r--r--    1 0        0               0 Jan  1 00:31 hostname
-rw-r--r--    1 0        0               0 Jan  1 00:31 ipaddr
-rw-r--r--    1 0        0               0 Jan  1 00:31 loadaddr
-rw-r--r--    1 0        0               0 Jan  1 00:31 netmask
-rw-r--r--    1 0        0               0 Jan  1 00:31 serverip
-rw-r--r--    1 0        0               0 Jan  1 00:31 stderr
-rw-r--r--    1 0        0               0 Jan  1 00:31 stdin
-rw-r--r--    1 0        0               0 Jan  1 00:31 stdout


So configuring ethernet is just like:

ifconfig eth0 `cat /proc/viola/ipaddr` netmask `cat /proc/viola/netmask` up


Rick
(maybe time to submit an article, but it's so easy to do ;o)

Richard Klingler             mail: richard.klingler at violasystems.com
Viola Systems Ltd.           http://www.violasystems.com/
Lemmink?isenkatu 32          phon: +358 (0)201 226 226
20520 Turku, Finland         mobile: +358 (0)40 748 4711


From gerg at snapgear.com  Sat Mar  8 08:06:01 2003
From: gerg at snapgear.com (Greg Ungerer)
Date: Sat, 08 Mar 2003 23:06:01 +1000
Subject: [uClinux-dev] Re: from the archives + questions about fec.c: Re: [uClinux-dev]
 coldfire fec.c ethernet driver
In-Reply-To: <044401c2e4e7$1d73c5a0$294b82ce@connecttech.com>
References: <r01050400-1021-A15DB804D75F11D6B03300039387ACB6@[10.0.1.2]> <044401c2e4e7$1d73c5a0$294b82ce@connecttech.com>
Message-ID: <3E69EAB9.9040503@snapgear.com>

Hi Stuart,

Stuart MacDonald wrote:
> The M5272 user manual states that it's best to use the mii interrupt
> to ensure that the mii interface doesn't munge itself. Since the phy
> detection uses the interface, shouldn't the interrupt be enabled
> first? OTOH, even with it enabled I don't see any interrupts happening
> as a result of the phy detection, so I guess it's not necessary.

I have not seen any phy interrupts generated during detection.
And I have used a few different 5272 based boards with different
phys.

The real problem is if you don't have a real phy on the other side
(for example you have a switch/hub). Then there is no interrupt
line to tie too, and many board layoust don't pull it high if
not used. You very easily get spurious interrupts...


> I'm having problems getting the phy detection code to recognise our
> LXT972A. I've moved the interrupt and icrp references (we've got the
> mii interrupt on INT3 instead of INT2). I've checked that the mii
> commands are built properly. What seems to happen is that garbage is
> read from the phy. If anyone has any insight, I'd appreciate it.

Is this known working hardware, or a new board/design?


> Using 20020927, and tools 20020410. Searched the list archive, found
> nothing relevant, except the thread I'm replying to.

Get the latest fec.c (and fec.h) from cvs, cvs.uclinux.org.
Or it is also in the newst dist, uClinux-dist-20030305.

Regards
Greg


------------------------------------------------------------------------
Greg Ungerer  --  Chief Software Wizard        EMAIL:  gerg at snapgear.com
SnapGear Pty Ltd                               PHONE:    +61 7 3435 2888
825 Stanley St,                                  FAX:    +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia              WEB:   www.SnapGear.com



From tchen at on-go.com  Sat Mar  8 13:58:13 2003
From: tchen at on-go.com (Thomas Chen)
Date: Sat, 08 Mar 2003 10:58:13 -0800
Subject: [uClinux-dev] fast IP packet routing
Message-ID: <BA8F7D45.8EDD%tchen@on-go.com>

if i want to have all ethernet traffic routed thru the
serial port (ppp), what options do i need to turn on
(like ip forwarding???) in uclinux?
also, does uclinux have some kind of fast packet routing
from one interface to another without having to go up
all the way in protocol stack?

thanks
tom



From tchen at on-go.com  Sat Mar  8 19:23:54 2003
From: tchen at on-go.com (Thomas Chen)
Date: Sat, 08 Mar 2003 16:23:54 -0800
Subject: [uClinux-dev] bootloader environment
In-Reply-To: <r01050400-1024-ACE62AFB515511D7AF1700039387ACB6@[10.0.1.2]>
Message-ID: <BA8FC999.8EE7%tchen@on-go.com>

richard

that seem pretty cool idea...
but what shell are you running that you can do `cat ...` ???

i wonder if you can even do a "echo xxxxx > /proc/viola/buadrate

to change the config for the next reboot???





on 3/8/03 3:04 AM, Richard Klingler at richard.klingler at violasystems.com
wrote:

> Good afternoon...(o;
> 
> 
> Someone needs to access bootloader environment in uClinux?
> 
> 
> Wrote some really small proc handler which gives
> dynamically all environments defined in ppcboot
> and u-boot as individual files under /proc:
> 
> # ls -l proc/viola
> -rw-r--r--    1 0        0               0 Jan  1 00:31 baudrate
> -rw-r--r--    1 0        0               0 Jan  1 00:31 bootcmd
> -rw-r--r--    1 0        0               0 Jan  1 00:31 bootdelay
> -rw-r--r--    1 0        0               0 Jan  1 00:31 ethaddr
> -rw-r--r--    1 0        0               0 Jan  1 00:31 filesize
> -rw-r--r--    1 0        0               0 Jan  1 00:31 gatewayip
> -rw-r--r--    1 0        0               0 Jan  1 00:31 hostname
> -rw-r--r--    1 0        0               0 Jan  1 00:31 ipaddr
> -rw-r--r--    1 0        0               0 Jan  1 00:31 loadaddr
> -rw-r--r--    1 0        0               0 Jan  1 00:31 netmask
> -rw-r--r--    1 0        0               0 Jan  1 00:31 serverip
> -rw-r--r--    1 0        0               0 Jan  1 00:31 stderr
> -rw-r--r--    1 0        0               0 Jan  1 00:31 stdin
> -rw-r--r--    1 0        0               0 Jan  1 00:31 stdout
> 
> 
> So configuring ethernet is just like:
> 
> ifconfig eth0 `cat /proc/viola/ipaddr` netmask `cat /proc/viola/netmask` up
> 
> 
> Rick
> (maybe time to submit an article, but it's so easy to do ;o)
> 
> Richard Klingler             mail: richard.klingler at violasystems.com
> Viola Systems Ltd.           http://www.violasystems.com/
> Lemmink?isenkatu 32          phon: +358 (0)201 226 226
> 20520 Turku, Finland         mobile: +358 (0)40 748 4711
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org
> 



From richard.klingler at violasystems.com  Sat Mar  8 16:59:56 2003
From: richard.klingler at violasystems.com (Richard Klingler)
Date: Sat,  8 Mar 2003 23:59:56 +0200
Subject: [uClinux-dev] bootloader environment
In-Reply-To: <BA8FC999.8EE7%tchen@on-go.com>
Message-ID: <r01050400-1024-4C7274E451B111D7AF1700039387ACB6@[10.0.1.2]>

> 
> richard
> 
> that seem pretty cool idea...
> but what shell are you running that you can do `cat ...` ???
> 

Minix shell of curse (o;

> i wonder if you can even do a "echo xxxxx > /proc/viola/buadrate
> 
> to change the config for the next reboot???
> 

That's what I'm working on....but not for regular flash...
uses QSPI though (o;

Rick


Richard Klingler             mail: richard.klingler at violasystems.com
Viola Systems Ltd.           http://www.violasystems.com/
Lemmink?isenkatu 32          phon: +358 (0)201 226 226
20520 Turku, Finland         mobile: +358 (0)40 748 4711


From tchen at on-go.com  Sat Mar  8 21:36:40 2003
From: tchen at on-go.com (thomas chen)
Date: Sat, 08 Mar 2003 21:36:40 -0500
Subject: [uClinux-dev] bootloader environment
References: <r01050400-1024-4C7274E451B111D7AF1700039387ACB6@[10.0.1.2]>
Message-ID: <3E6AA8B8.3C23D358@on-go.com>

that would be nice... but are you doing something special?
i thought /proc is a read-only system, but i think if you can
use echo to write out to the configuration, that would be so much
easier...

so what is the trick?  ppcboot store the configruation in bunch
of contingous strings... (at least my version does that?...)


Richard Klingler wrote:
> 
> >
> > richard
> >
> > that seem pretty cool idea...
> > but what shell are you running that you can do `cat ...` ???
> >
> 
> Minix shell of curse (o;
> 
> > i wonder if you can even do a "echo xxxxx > /proc/viola/buadrate
> >
> > to change the config for the next reboot???
> >
> 
> That's what I'm working on....but not for regular flash...
> uses QSPI though (o;
> 
> Rick
> 
> Richard Klingler             mail: richard.klingler at violasystems.com
> Viola Systems Ltd.           http://www.violasystems.com/
> Lemmink?isenkatu 32          phon: +358 (0)201 226 226
> 20520 Turku, Finland         mobile: +358 (0)40 748 4711
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org


From tchen at on-go.com  Sat Mar  8 21:54:37 2003
From: tchen at on-go.com (thomas chen)
Date: Sat, 08 Mar 2003 21:54:37 -0500
Subject: [uClinux-dev] MINIX shell and BUSYbox
Message-ID: <3E6AACED.D605A37D@on-go.com>

is busy box only available for SASH?
i just tried configuring MINUX shell and suddenly nothing work...

since i do not have any regular shell commands enabled and all using
busybox... i assume it is related to busybox in minix-shell?

thanks


From tongcd at neusoft.com  Sat Mar  8 22:31:08 2003
From: tongcd at neusoft.com (ChangDa Tong)
Date: Sun, 09 Mar 2003 11:31:08 +0800
Subject: [uClinux-dev] direct func call
Message-ID: <001001c2e5ec$54cf0090$b51ea8c0@tongcd>

Hello
The question troubles me most, Hope anyone could give a hit
I got a client and server function running under uClinux 2.0.38 , in order to reduce communication cost
I design the client to fetch the address of a function that in server, then call it on the client side 
directly instead of using socket, it is ok but if this contain a free(ptr), the ptr(global) is malloced on the startup of
server process, after the free call , a error message occur:
    munmap of non-mmaped memory by process 10 (client): 00045238
I know call directly is not a good idea, but i need this way to impove performance, Can you give me some idea?
Thanks you and soryy for my poor english
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20030309/4d5a612c/attachment.html>

From philwil at earthlink.net  Sat Mar  8 22:37:35 2003
From: philwil at earthlink.net (Phil Wilshire)
Date: Sat, 08 Mar 2003 22:37:35 -0500
Subject: [uClinux-dev] direct func call
References: <001001c2e5ec$54cf0090$b51ea8c0@tongcd>
Message-ID: <3E6AB6FF.8AF61B55@earthlink.net>

HI
You will probably have to show us some code example so that we can see what you are trying to do.

regards
  Phil Wilshire

> ChangDa Tong wrote:
> 
> Hello
> The question troubles me most, Hope anyone could give a hit
> I got a client and server function running under uClinux 2.0.38 , in order to reduce communication cost
> I design the client to fetch the address of a function that in server, then call it on the client side
> directly instead of using socket, it is ok but if this contain a free(ptr), the ptr(global) is malloced on the startup of
> server process, after the free call , a error message occur:
>     munmap of non-mmaped memory by process 10 (client): 00045238
> I know call directly is not a good idea, but i need this way to impove performance, Can you give me some idea?
> Thanks you and soryy for my poor english

-- 
SDCS -- System Design & Consulting Services LLC, http://www.sysdcs.com
** Embedded Linux Training **  email me for details  
630 Springhouse Sq., Leesburg VA 20175 t: 703 669 9766 f: 703 669 9768


From tongcd at neusoft.com  Sat Mar  8 23:18:24 2003
From: tongcd at neusoft.com (ChangDa Tong)
Date: Sun, 09 Mar 2003 12:18:24 +0800
Subject: [uClinux-dev] directly call
Message-ID: <003301c2e5f2$ef8c2260$b51ea8c0@tongcd>

here is the code , by using socket , the server side tell client the
address of its function "b"
then the client call it directly.(Up to now , there is only one client
and server, later i will
using lock to control race condition, for the server contail global
variable)
Without considering concurrency problem, Is there other problems
introduce by this way("direct call") that I havn't not known?(besides
this malloc problem)
//---------------snap of
client.c ----------------------------------------------------
int (*test)(void);
int main( )
{
 un_sock = socket(AF_UNIX, SOCK_STREAM, 0);
 if(un_sock == -1)
  perror("open socket fail");

 sckt.sun_family = AF_UNIX;
        strncpy(sckt.sun_path, GR_NAMED_SOCKET, sizeof(sckt.sun_path));

 size = sizeof(sckt);
 ret = connect(un_sock, (struct sockaddr *) &sckt, size);
 if(ret == 0)
  fprintf(stderr, "connect succeed\n");
 else
  fprintf(stderr, "connect fail");

 size = write(un_sock, "iii", 3);
 bzero(buf,16);
 fprintf(stderr, "read sock\n");
/
 size = read(un_sock, (void *)&address, 4);
 fprintf(stderr, "%X\n",address);

 test = address;
 (*test)();
}
//------------------------------here is
server.c----------------------------
#define GR_NAMED_SOCKET "/var/.nano-X"

char *ptr= NULL;
int un_sock;

int b(void)
{
 fprintf(stderr, "Hello\n");
 if(ptr){
  fprintf(stderr, "%s: free ptr once", __FUNCTION__);
  free(ptr);
  ptr = NULL;
 }
 return 0;
}

void
GsAcceptClient(void)
{
        unsigned int i, address;
        struct sockaddr_un sckt;
 char buf[16];
        socklen_t size = sizeof(sckt);

        if((i = accept(un_sock, (struct sockaddr *) &sckt, &size))
== -1) {
                fprintf(stderr,"accept fail");
                return;
        }
 address = b;
 fprintf(stderr, "return address to client\n");
        write(i, (void *)&address, 4);
}

int main()
{
 struct sockaddr_un sckt;

 ptr = malloc(20);
 un_sock = socket(AF_UNIX, SOCK_STREAM, 0);
 if(un_sock == -1)
  perror("open socket fail");

 sckt.sun_family = AF_UNIX;
        strncpy(sckt.sun_path, GR_NAMED_SOCKET, sizeof(sckt.sun_path));

 fprintf(stderr, "Address:%p", b);

 if(bind(un_sock, (struct sockaddr *) &sckt, SUN_LEN(&sckt)) < 0)
                return -1;

        /* Start listening on the socket: */
        if(listen(un_sock, 5) == -1)
                return -1;
 GsAcceptClient();
 sleep(2);
 if(ptr){
  printf("S:ptr not null!\n");
  free(ptr);
  ptr = NULL;
 }
 fprintf(stderr, "S:exit\n");
}





From richard.klingler at violasystems.com  Sun Mar  9 04:05:11 2003
From: richard.klingler at violasystems.com (Richard Klingler)
Date: Sun,  9 Mar 2003 11:05:11 +0200
Subject: [uClinux-dev] bootloader environment
In-Reply-To: <3E6AA8B8.3C23D358@on-go.com>
Message-ID: <r01050400-1024-3BB67054520E11D7A1D500039387ACB6@[10.0.1.2]>

> 
> that would be nice... but are you doing something special?
> i thought /proc is a read-only system, but i think if you can
> use echo to write out to the configuration, that would be so much
> easier...
> 

Nothing special...you just create entries with mode 0644 and
register a read/write proc to it...

If a directory has no "write" flag it doesn't mean that
you can't write to a file inside this directory...


> so what is the trick?  ppcboot store the configruation in bunch
> of contingous strings... (at least my version does that?...)
> 

That's how it is...but the strings are "\0" terminated (o;


Rick


Richard Klingler             mail: richard.klingler at violasystems.com
Viola Systems Ltd.           http://www.violasystems.com/
Lemmink?isenkatu 32          phon: +358 (0)201 226 226
20520 Turku, Finland         mobile: +358 (0)40 748 4711


From eauth at softsys.co.at  Sun Mar  9 05:50:25 2003
From: eauth at softsys.co.at (Erwin Authried)
Date: Sun, 9 Mar 2003 11:50:25 +0100
Subject: [uClinux-dev] bootloader environment
In-Reply-To: <r01050400-1024-4C7274E451B111D7AF1700039387ACB6@[10.0.1.2]>
Message-ID: <CBEPKHHODMBKHCMLAGBMCEKECCAA.eauth@softsys.co.at>

> -----Urspr?ngliche Nachricht-----
> Von: uclinux-dev-admin at uclinux.org
> [mailto:uclinux-dev-admin at uclinux.org]Im Auftrag von Richard Klingler
> Gesendet: Samstag, 08. M?rz 2003 23:00
> An: uclinux-dev at uclinux.org
> Betreff: Re: [uClinux-dev] bootloader environment
>
>
> >
> > richard
> >
> > that seem pretty cool idea...
> > but what shell are you running that you can do `cat ...` ???
> >
>
> Minix shell of curse (o;
>
I tried command substitution with the Minix shell, but somehow it doesn't
seem to work. As far as I remember, the shell always exits when there is a
cmd substitution. Which version do you use?

Regards,
Erwin



From richard.klingler at violasystems.com  Sun Mar  9 07:14:33 2003
From: richard.klingler at violasystems.com (Richard Klingler)
Date: Sun,  9 Mar 2003 14:14:33 +0200
Subject: [uClinux-dev] bootloader environment
In-Reply-To: <CBEPKHHODMBKHCMLAGBMCEKECCAA.eauth@softsys.co.at>
Message-ID: <r01050400-1024-B01F3C1C522811D7A1D500039387ACB6@[10.0.1.2]>

Hi Erwin...

Version? Doesn't show up....it's from the 200209 distribution...

Rick

> > >
> > > richard
> > >
> > > that seem pretty cool idea...
> > > but what shell are you running that you can do `cat ...` ???
> > >
> >
> > Minix shell of curse (o;
> >
> I tried command substitution with the Minix shell, but somehow it doesn't
> seem to work. As far as I remember, the shell always exits when there is a
> cmd substitution. Which version do you use?
> 
> Regards,
> Erwin
> 


From philwil at earthlink.net  Sun Mar  9 08:29:39 2003
From: philwil at earthlink.net (Phil Wilshire)
Date: Sun, 09 Mar 2003 08:29:39 -0500
Subject: [uClinux-dev] directly call
References: <003301c2e5f2$ef8c2260$b51ea8c0@tongcd>
Message-ID: <3E6B41C3.5355B028@earthlink.net>

HI ChangDa,
I can think of many reasons why this is NOT A GOOD IDEA.

I have only taken a quick look at the code but ..

If it works at all it will only work on MMUless systems.
And ptr will possibly only be valid in the context of the server executable.

If you want to send some data to the client to process the 
"b" routine be present in both executables and all the data that it operates on be transferred through the socket.

You need to think carefully about this design.


regards

Phil Wilshire


ChangDa Tong wrote:
> 
> here is the code , by using socket , the server side tell client the
> address of its function "b"
> then the client call it directly.(Up to now , there is only one client
> and server, later i will
> using lock to control race condition, for the server contail global
> variable)
> Without considering concurrency problem, Is there other problems
> introduce by this way("direct call") that I havn't not known?(besides
> this malloc problem)
> //---------------snap of
> client.c ----------------------------------------------------
> int (*test)(void);
> int main( )
> {
>  un_sock = socket(AF_UNIX, SOCK_STREAM, 0);
>  if(un_sock == -1)
>   perror("open socket fail");
> 
>  sckt.sun_family = AF_UNIX;
>         strncpy(sckt.sun_path, GR_NAMED_SOCKET, sizeof(sckt.sun_path));
> 
>  size = sizeof(sckt);
>  ret = connect(un_sock, (struct sockaddr *) &sckt, size);
>  if(ret == 0)
>   fprintf(stderr, "connect succeed\n");
>  else
>   fprintf(stderr, "connect fail");
> 
>  size = write(un_sock, "iii", 3);
>  bzero(buf,16);
>  fprintf(stderr, "read sock\n");
> /
>  size = read(un_sock, (void *)&address, 4);
>  fprintf(stderr, "%X\n",address);
> 
>  test = address;
>  (*test)();
> }
> //------------------------------here is
> server.c----------------------------
> #define GR_NAMED_SOCKET "/var/.nano-X"
> 
> char *ptr= NULL;
> int un_sock;
> 
> int b(void)
> {
>  fprintf(stderr, "Hello\n");
>  if(ptr){
>   fprintf(stderr, "%s: free ptr once", __FUNCTION__);
>   free(ptr);
>   ptr = NULL;
>  }
>  return 0;
> }
> 
> void
> GsAcceptClient(void)
> {
>         unsigned int i, address;
>         struct sockaddr_un sckt;
>  char buf[16];
>         socklen_t size = sizeof(sckt);
> 
>         if((i = accept(un_sock, (struct sockaddr *) &sckt, &size))
> == -1) {
>                 fprintf(stderr,"accept fail");
>                 return;
>         }
>  address = b;
>  fprintf(stderr, "return address to client\n");
>         write(i, (void *)&address, 4);
> }
> 
> int main()
> {
>  struct sockaddr_un sckt;
> 
>  ptr = malloc(20);
>  un_sock = socket(AF_UNIX, SOCK_STREAM, 0);
>  if(un_sock == -1)
>   perror("open socket fail");
> 
>  sckt.sun_family = AF_UNIX;
>         strncpy(sckt.sun_path, GR_NAMED_SOCKET, sizeof(sckt.sun_path));
> 
>  fprintf(stderr, "Address:%p", b);
> 
>  if(bind(un_sock, (struct sockaddr *) &sckt, SUN_LEN(&sckt)) < 0)
>                 return -1;
> 
>         /* Start listening on the socket: */
>         if(listen(un_sock, 5) == -1)
>                 return -1;
>  GsAcceptClient();
>  sleep(2);
>  if(ptr){
>   printf("S:ptr not null!\n");
>   free(ptr);
>   ptr = NULL;
>  }
>  fprintf(stderr, "S:exit\n");
> }
> 
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org

-- 
SDCS -- System Design & Consulting Services LLC, http://www.sysdcs.com
** Embedded Linux Training **  email me for details  
630 Springhouse Sq., Leesburg VA 20175 t: 703 669 9766 f: 703 669 9768


From jim at thelemkes.ca  Sun Mar  9 11:56:48 2003
From: jim at thelemkes.ca (James Lemke)
Date: 09 Mar 2003 11:56:48 -0500
Subject: [uClinux-dev] building for PalmOS -- strstr() args
Message-ID: <1047229008.21858.354.camel@mast.thelemkes.ca>

I'm using a RHL 8.0 workstation to build.  In uclinuxgcc-kit-160899/ I
type make and eventually get the following messages:
gcc -c -g -O2 -I. -I./../include  ./dummy.c 2>/dev/null
make[2]: *** [dummy.o] Error 1
make[2]: Leaving directory
`/work/uclinux/uclinuxgcc-kit-160899/binutils-2.9.1.kernel/libiberty'
make[1]: *** [all-libiberty] Error 2
make[1]: Leaving directory
`/work/uclinux/uclinuxgcc-kit-160899/binutils-2.9.1.kernel'
make: *** [/work/gnu/bin/m68k-coff-as] Error 2

Re-executing the compile, I find the following error msg:
[jim at mast libiberty]$ gcc -c -g -O2 -I. -I./../include  ./dummy.c
In file included from dummy.c:46:
functions.def: In function `main':
functions.def:38: too few arguments to function `strstr'

Functions.def defines strstr with no args, but /usr/include/string.h
disagrees.

Can anybody shed some light on this?

TIA,
Jim.

-- 
Jim Lemke   jim at TheLemkes.ca   Barrie, Ontario
1986 Concours, COG #2637    1992 ST1100, STOC #3750
Those who dance are considered insane
by those who can't hear the music.  George Carlin



From mikes at tbc.net  Sun Mar  9 14:04:14 2003
From: mikes at tbc.net (Michael F. Sharp)
Date: Sun, 09 Mar 2003 13:04:14 -0600
Subject: [uClinux-dev] uClinux for Palm IIIc
Message-ID: <3E6B902E.7000103@tbc.net>

Would anybody be interested in started a new thread "uClinux for Palm 
IIIc" ? It seems that there has been quite a few people who have tried 
to port uClinux to the Palm IIIc without success.

The purpose of creating this thread would be to make future searches for 
the matter a lot easier.

If interested, I would like to start the thread by suggesting that we 
have a look at uClinux-dist/vendors/3com/palm-loader/PalmLoader.c

HenrySimmons and DavidM have been most helpful with suggestions so far 
for modifications to make to config.linux-2.0.x, crt0_ram.S, ram.ld, and 
the uClinux-dist/vendors/3com/PalmIIIx/Makefile.

Is there anybody on the list that is intimately familiar with the EZ328 
internals? Register 0xfffff116 has been a subject of discussion from 
time to time, but I think that is just the tip of the iceberg.

I have some machine language and C programming skills to offer.

Open to suggestions...

-Mike





From mikes at tbc.net  Sun Mar  9 19:47:39 2003
From: mikes at tbc.net (Michael F. Sharp)
Date: Sun, 09 Mar 2003 18:47:39 -0600
Subject: [uClinux-dev] uClinux for Palm IIIc
References: <3E6B902E.7000103@tbc.net>
Message-ID: <3E6BE0AB.9060109@tbc.net>

Interesting bit of information from 
http://www.linuxda.com/support/techfaqs.html#Q38

38. I have a Palm IIIc, and was wondering why there seems to be a lack 
of Linux ports for the Palm III and Palm IIIc? I can see memory 
limitations being a problem for the Palm III, being that it has only 2M 
of RAM, but what about the IIIc? The IIIc has a full 8M of RAM to work 
with. How hard is it to take the kernel source, and modify it for the 
Palm IIIc? What would I need to do to make it work?

The Palm IIIc uses a LCD controller from Epson for the color display. 
The register and initialization settings are different. You have to 
change those settings. The Epson LCD controller driver has to be ported 
as well. If you have any projects concerning the porting to IIIc, you 
can contact our sales department at sales at linuxda.com



From jim at thelemkes.ca  Sun Mar  9 21:43:11 2003
From: jim at thelemkes.ca (James Lemke)
Date: 09 Mar 2003 21:43:11 -0500
Subject: [uClinux-dev] building for PalmOS -- strstr() args
In-Reply-To: <1047229008.21858.354.camel@mast.thelemkes.ca>
References: <1047229008.21858.354.camel@mast.thelemkes.ca>
Message-ID: <1047264192.21858.372.camel@mast.thelemkes.ca>

On Sun, 2003-03-09 at 11:56, James Lemke wrote:
> I'm using a RHL 8.0 workstation to build.  In uclinuxgcc-kit-160899/ I
> type make and eventually get the following messages:

I should report that searching the archives for a similar question led
me to the following link.  I now have uCLinux running in xcopilot.
http://www.ucdot.org/article.pl?sid=02/09/03/1357255

-- 
Jim Lemke   jim at TheLemkes.ca   Barrie, Ontario
1986 Concours, COG #2637    1992 ST1100, STOC #3750
Those who dance are considered insane
by those who can't hear the music.  George Carlin



From mikes at tbc.net  Sun Mar  9 22:26:09 2003
From: mikes at tbc.net (Michael F. Sharp)
Date: Sun, 09 Mar 2003 21:26:09 -0600
Subject: [uClinux-dev] uClinux for Palm IIIc
References: <3E6B902E.7000103@tbc.net> <3E6BE0AB.9060109@tbc.net>
Message-ID: <3E6C05D1.2080609@tbc.net>

Also found:

http://www.ms-n.org/DataSheets/Epson/sed1375_e.pdf

This is the technical doc for the LCD controller. Would the 80k embedded 
  memory overlap the RAM? If so, this could be one reason why uClinux 
isn't booting properly. Comments?

-Mike

Michael F. Sharp wrote:
> Interesting bit of information from 
> http://www.linuxda.com/support/techfaqs.html#Q38
> 
> 38. I have a Palm IIIc, and was wondering why there seems to be a lack 





From rgegusch at mf.tu-berlin.de  Mon Mar 10 04:58:50 2003
From: rgegusch at mf.tu-berlin.de (Rene Gegusch)
Date: Mon, 10 Mar 2003 10:58:50 +0100
Subject: [uClinux-dev] FTP Server on the 5272 board
In-Reply-To: <3E68A22B.9050901@snapgear.com>
References: <BC03D160581F7A4E92710FC238282411167809@ici-mail.intellicom.se> <200303071400.21002.rgegusch@mf.tu-berlin.de> <3E68A22B.9050901@snapgear.com>
Message-ID: <200303101058.50986.rgegusch@mf.tu-berlin.de>

You were right. My downloaded file was corrupted. Thank you to KDE, which did 
not mentioned that!
Anyway, i just started to try to compile the new distribution for my Arcturus 
uCdimm 5272 system, but compiler very fast ended compilation with an error.<
<make dep> works fine, but on the next step <make> not so.
It stops with an missing rule error...
make[2]: changing to directory
?/home/rgegusch/test/uClinux-dist/linux-2.4.x/arch/m68knommu/platform/5272?
make[2]: *** no rule available for target ?/crt0_ram.S?,
  need of ?/crt0_ram.o?, to create.  End.
(Compiler messages translated to English by myself)

does anyone knows, what there is wrong?
I am not one of those kernel hacking freaks, originally had the plan to 
compile the ftpd server, shipped with this distribution, but failed to 
compile it because of missing PATH definitions.

However, I need help!




Am Freitag, 7. M?rz 2003 14:44 schrieb Greg Ungerer:
> Hi Rene,
>
> Rene Gegusch wrote:
> > Thank you for the information.
> > It confusses me, that the download of the new distribution does not have
> > it as you told us.
> > My distribution file has a size of about 105mb, seems to be OK, doesn't
> > it?
>
> The latest distribution definately contains a uClinux-dist/user/ftpd
> directory. If you don't have one then either you don't have the latest
> distribution or it is corrupted.
>
> Regards
> Greg
>
>
>
> ------------------------------------------------------------------------
> Greg Ungerer  --  Chief Software Wizard        EMAIL:  gerg at snapgear.com
> SnapGear Pty Ltd                               PHONE:    +61 7 3435 2888
> 825 Stanley St,                                  FAX:    +61 7 3891 3630
> Woolloongabba, QLD, 4102, Australia              WEB:   www.SnapGear.com
>
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org




From rgegusch at mf.tu-berlin.de  Mon Mar 10 05:09:30 2003
From: rgegusch at mf.tu-berlin.de (Rene Gegusch)
Date: Mon, 10 Mar 2003 11:09:30 +0100
Subject: [uClinux-dev] the ftpd server in the new distribution
In-Reply-To: <200303071400.21002.rgegusch@mf.tu-berlin.de>
References: <BC03D160581F7A4E92710FC238282411167809@ici-mail.intellicom.se> <200303071400.21002.rgegusch@mf.tu-berlin.de>
Message-ID: <200303101109.30207.rgegusch@mf.tu-berlin.de>

Well, it is great that there is one included, but does anyone can tell me how 
to use it, except what the short --help option says?



From roope.anttinen at indagon.com  Mon Mar 10 06:00:34 2003
From: roope.anttinen at indagon.com (Roope Anttinen)
Date: 10 Mar 2003 13:00:34 +0200
Subject: [uClinux-dev] ip masquarade support
Message-ID: <1047294038.1923.5.camel@tossu>

On latest distribudion (20030305), with uCdimm:

m68k-elf-gcc -fno-builtin -DNO_CACHE -D__KERNEL__
-I/home/ranttine/src/uClinux/Playground/uClinux-dist.new/linux-2.4.x/include  -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -DNO_MM -DNO_FPU -DNO_CACHE -m68000 -D__ELF__ -DMAGIC_ROM_PTR -DNO_FORGET -DUTS_SYSNAME="uClinux" -D__linux__   -nostdinc -iwithprefix include -DKBUILD_BASENAME=af_packet  -c -o af_packet.o af_packet.c
af_packet.c: In function `packet_mm_open':
af_packet.c:1578: structure has no member named `vm_file'
af_packet.c: In function `packet_mm_close':
af_packet.c:1589: structure has no member named `vm_file'
af_packet.c: At top level:
af_packet.c:1598: variable `packet_mmap_ops' has initializer but
incomplete type
af_packet.c:1599: unknown field `open' specified in initializer
af_packet.c:1599: warning: excess elements in struct initializer
af_packet.c:1599: warning: (near initialization for `packet_mmap_ops')
af_packet.c:1600: unknown field `close' specified in initializer
af_packet.c:1600: warning: excess elements in struct initializer
af_packet.c:1600: warning: (near initialization for `packet_mmap_ops')
af_packet.c: In function `packet_mmap':
af_packet.c:1753: structure has no member named `vm_pgoff'
af_packet.c:1770: structure has no member named `vm_page_prot'
af_packet.c:1774: structure has no member named `vm_ops'
make[4]: *** [af_packet.o] Error 1





From roope.anttinen at indagon.com  Mon Mar 10 06:38:52 2003
From: roope.anttinen at indagon.com (Roope Anttinen)
Date: 10 Mar 2003 13:38:52 +0200
Subject: [uClinux-dev] ip masquarade support
In-Reply-To: <1047294038.1923.5.camel@tossu>
References: <1047294038.1923.5.camel@tossu>
Message-ID: <1047296336.1923.9.camel@tossu>

OK, got it compiled by removing support for mmapped io. But now when
booting:

...
cs89x0:cs89x0_probe(0xffe0)
cs89x0: Setting up uCcs8900 Chip Select & IRQ ioaddr = 0xFFE0
eth7: cs8920 rev A found at 0xffe0 
cs89x0 media RJ-45, IRQ 20, programmed I/O, MAC 00:06:3b:00:01:43
cs89x0_probe1() successful
Blkmem copyright 1998,1999 D. Jeff Dionne
Blkmem copyright 1998 Kenneth Albanowski
Blkmem 1 disk images:
0: 10CF4730-10DF472F [VIRTUAL 10CF4730-10DF472F] (RO)
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
PPP generic driver version 2.4.2
PPP Deflate Compression module registered
PPP BSD Compression module registered
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 512 bind 512)
ip_conntrack version 2.1 (48 buckets, 384 max) - 316 bytes per conntrack
ip_tables: (C) 2000-2002 Netfilter core team
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
VFS: Mounted root (romfs filesystem) readonly.
eth0: using half-duplex 10Base-T (RJ-45)
Welcome to
          ____ _  _*** UNASSIGNED RESERVED 12 ***   FORMAT=2
Current process id is 7
BAD KERNEL TRAP: 00000000
PC: [<0002fa05>]
SR: 2035  SP: 000b3d7e  a2: 000dec34
d0: 00000000    d1: 00000000    d2: 00000000    d3: 00000000
d4: 0002fa05    d5: 000485b4    a0: 000dec74    a1: 00000000
Process sh (pid: 7, stackpage=000b3000)
Frame format=2 instr addr=200010c9
Stack from 000b3db6:
        da720000 00000000 00000000 00000004 85b40000 0000000b 3f100013
70500003
        744c0013 7050000b 3f100040 00000000 00000000 0002fa05 000485b4
00000000
        000ddb94 00000000 0000000b 3e4410c9 fb88000b 3f100000 00000004
85b40000
        00000004 ce480000 00000000 00010000 00000013 70fc0013 70500000
0bb80013
        705010c9 b5aa0013 7050000d db80000b 3e8410c9 f74e000b 3f100000
00000004
        85b40000 00000013 70500013 70fc0004 980810c7 b6da0000 0000000b
3efc10c7
Call Trace:
Code: *** UNASSIGNED RESERVED 12 ***   FORMAT=3
Current process id is 7
BAD KERNEL TRAP: 00000000
PC: [<0002fa05>]
SR: 3035  SP: 000b3c54  a2: 000b3ffe
d0: 00000000    d1: 00001430    d2: 000b4002    d3: 00000000
d4: 10d21d68    d5: 000b4000    a0: 00000000    a1: 0002fa05
Process sh (pid: 7, stackpage=000b3000)
Frame format=3 eff addr=271410c1
Stack from 000b3c8c:
        24f40000 00000000 00000002 fa050004 85b410c1 7ed0000b 3d7e10c1
2888000b
        3d7e0002 1173000b 223c0000 0007000b 300010c1 7ed0000b 3d7e10c1
25c60002
        10ae000b 3d7e0000 00000002 10940000 0007000d ec340003 744c10c1
260a000b
        3d7e0000 0000000b 3d220000 00060000 00000003 825c10c1 51280000
0044000b
        3d220000 10c2601a 00003574 ba2e8ba3 00000000 00080000 00040000
00040013
        70000000 00080000 00040000 0004000d ec340003 744c000d db8010c1
59a40000
Call Trace:
        [<10c2601a>] [<10c9da72>] [<10c9fb88>] [<10c9b5aa>]
        [<10c9f74e>] [<10c7b6da>] [<10c7b6da>] [<10c75118>]
        [<10c7b6da>] [<10c753b2>] [<10c7b6da>] [<10c7b53c>]
        [<10c7b6da>] [<10c708fa>] [<10c70994>] [<10c70a7a>]
        [<10c1af44>] [<10c13e1a>]
Code: *** UNASSIGNED RESERVED 12 ***   FORMAT=3
Current process id is 7

...etc...

On Mon, 2003-03-10 at 13:00, Roope Anttinen wrote:
> On latest distribudion (20030305), with uCdimm:
> 
> m68k-elf-gcc -fno-builtin -DNO_CACHE -D__KERNEL__
> -I/home/ranttine/src/uClinux/Playground/uClinux-dist.new/linux-2.4.x/include  -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -DNO_MM -DNO_FPU -DNO_CACHE -m68000 -D__ELF__ -DMAGIC_ROM_PTR -DNO_FORGET -DUTS_SYSNAME="uClinux" -D__linux__   -nostdinc -iwithprefix include -DKBUILD_BASENAME=af_packet  -c -o af_packet.o af_packet.c
> af_packet.c: In function `packet_mm_open':
> af_packet.c:1578: structure has no member named `vm_file'
> af_packet.c: In function `packet_mm_close':
> af_packet.c:1589: structure has no member named `vm_file'
> af_packet.c: At top level:
> af_packet.c:1598: variable `packet_mmap_ops' has initializer but
> incomplete type
> af_packet.c:1599: unknown field `open' specified in initializer
> af_packet.c:1599: warning: excess elements in struct initializer
> af_packet.c:1599: warning: (near initialization for `packet_mmap_ops')
> af_packet.c:1600: unknown field `close' specified in initializer
> af_packet.c:1600: warning: excess elements in struct initializer
> af_packet.c:1600: warning: (near initialization for `packet_mmap_ops')
> af_packet.c: In function `packet_mmap':
> af_packet.c:1753: structure has no member named `vm_pgoff'
> af_packet.c:1770: structure has no member named `vm_page_prot'
> af_packet.c:1774: structure has no member named `vm_ops'
> make[4]: *** [af_packet.o] Error 1
> 
> 
> 
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org




From richard.klingler at violasystems.com  Mon Mar 10 06:48:14 2003
From: richard.klingler at violasystems.com (Richard Klingler)
Date: Mon, 10 Mar 2003 13:48:14 +0200
Subject: [uClinux-dev] ip masquarade support
In-Reply-To: <1047296336.1923.9.camel@tossu>
Message-ID: <r01050400-1024-2D5C797152EE11D794AB00039387ACB6@[10.0.1.2]>

> BAD KERNEL TRAP: 00000000
> PC: [<0002fa05>]
> SR: 2035  SP: 000b3d7e  a2: 000dec34
> d0: 00000000    d1: 00000000    d2: 00000000    d3: 00000000
> d4: 0002fa05    d5: 000485b4    a0: 000dec74    a1: 00000000

Just look what routine is causing this at address 2fa05....


Rick


Richard Klingler             mail: richard.klingler at violasystems.com
Viola Systems Ltd.           http://www.violasystems.com/
Lemmink?isenkatu 32          phon: +358 (0)201 226 226
20520 Turku, Finland         mobile: +358 (0)40 748 4711


From gerg at snapgear.com  Mon Mar 10 07:41:07 2003
From: gerg at snapgear.com (Greg Ungerer)
Date: Mon, 10 Mar 2003 22:41:07 +1000
Subject: [uClinux-dev] FTP Server on the 5272 board
In-Reply-To: <200303101058.50986.rgegusch@mf.tu-berlin.de>
References: <BC03D160581F7A4E92710FC238282411167809@ici-mail.intellicom.se> <200303071400.21002.rgegusch@mf.tu-berlin.de> <3E68A22B.9050901@snapgear.com> <200303101058.50986.rgegusch@mf.tu-berlin.de>
Message-ID: <3E6C87E3.6010604@snapgear.com>

Hi Rene,

Rene Gegusch wrote:
> You were right. My downloaded file was corrupted. Thank you to KDE, which did 
> not mentioned that!
> Anyway, i just started to try to compile the new distribution for my Arcturus 
> uCdimm 5272 system, but compiler very fast ended compilation with an error.<
> <make dep> works fine, but on the next step <make> not so.
> It stops with an missing rule error...
> make[2]: changing to directory
> ?/home/rgegusch/test/uClinux-dist/linux-2.4.x/arch/m68knommu/platform/5272?
> make[2]: *** no rule available for target ?/crt0_ram.S?,
>   need of ?/crt0_ram.o?, to create.  End.

Unfortunately the guys at Arcturus have not commited their uC5272
linux-2.4.x kernel support to the CVS yet. So the low level files
(for example the above mentioned crt0_ram.S) are not there. Which
means they are not in the uClinux-dist either.

If you have a source CD from Arcturus for the uC5272 then you
would have those files. You could just pull them out and merge
them. Will probably be a little bit of mucking around to get it
all together, compiling and working.

Regards
Greg




> (Compiler messages translated to English by myself)
> 
> does anyone knows, what there is wrong?
> I am not one of those kernel hacking freaks, originally had the plan to 
> compile the ftpd server, shipped with this distribution, but failed to 
> compile it because of missing PATH definitions.
> 
> However, I need help!
> 
> 
> 
> 
> Am Freitag, 7. M?rz 2003 14:44 schrieb Greg Ungerer:
> 
>>Hi Rene,
>>
>>Rene Gegusch wrote:
>>
>>>Thank you for the information.
>>>It confusses me, that the download of the new distribution does not have
>>>it as you told us.
>>>My distribution file has a size of about 105mb, seems to be OK, doesn't
>>>it?
>>
>>The latest distribution definately contains a uClinux-dist/user/ftpd
>>directory. If you don't have one then either you don't have the latest
>>distribution or it is corrupted.
>>
>>Regards
>>Greg
>>

------------------------------------------------------------------------
Greg Ungerer  --  Chief Software Wizard        EMAIL:  gerg at snapgear.com
SnapGear Pty Ltd                               PHONE:    +61 7 3435 2888
825 Stanley St,                                  FAX:    +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia              WEB:   www.SnapGear.com



From roope.anttinen at indagon.com  Mon Mar 10 07:56:11 2003
From: roope.anttinen at indagon.com (Roope Anttinen)
Date: 10 Mar 2003 14:56:11 +0200
Subject: [uClinux-dev] ip masquarade support
In-Reply-To: <r01050400-1024-2D5C797152EE11D794AB00039387ACB6@[10.0.1.2]>
References: <r01050400-1024-2D5C797152EE11D794AB00039387ACB6@[10.0.1.2]>
Message-ID: <1047300974.1923.11.camel@tossu>

krhm... uh... how? :)

/Roope

On Mon, 2003-03-10 at 13:48, Richard Klingler wrote:
> > BAD KERNEL TRAP: 00000000
> > PC: [<0002fa05>]
> > SR: 2035  SP: 000b3d7e  a2: 000dec34
> > d0: 00000000    d1: 00000000    d2: 00000000    d3: 00000000
> > d4: 0002fa05    d5: 000485b4    a0: 000dec74    a1: 00000000
> 
> Just look what routine is causing this at address 2fa05....
> 
> 
> Rick
> 
> 
> Richard Klingler             mail: richard.klingler at violasystems.com
> Viola Systems Ltd.           http://www.violasystems.com/
> Lemmink?isenkatu 32          phon: +358 (0)201 226 226
> 20520 Turku, Finland         mobile: +358 (0)40 748 4711
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org




From rgegusch at mf.tu-berlin.de  Mon Mar 10 08:17:10 2003
From: rgegusch at mf.tu-berlin.de (Rene Gegusch)
Date: Mon, 10 Mar 2003 14:17:10 +0100
Subject: [uClinux-dev] FTP Server Compiling Problems (Arcturus 5272)
In-Reply-To: <200303101109.30207.rgegusch@mf.tu-berlin.de>
References: <BC03D160581F7A4E92710FC238282411167809@ici-mail.intellicom.se> <200303071400.21002.rgegusch@mf.tu-berlin.de> <200303101109.30207.rgegusch@mf.tu-berlin.de>
Message-ID: <200303101417.10843.rgegusch@mf.tu-berlin.de>

I tried it on...

because of my troubles with compiling the new distribution, I decided to add 
the FTPD directory to my "old" distribution and add there the new 
application.
Should work, don't? It doesn't work better at all.

Here the error message:
In file included from auth.c:10:
crypt.h:33: conflicting types for `crypt'
/home/rgegusch/development/uClinux-coldfire/lib/libc/include/unistd.h:26: 
previous declaration of `crypt'
In file included from auth.c:12:
/usr/local/lib/gcc-lib/m68k-elf/2.95.3/../../../../m68k-elf/sys-include/shadow.h:58: 
parse error before `__THROW'
[...]
 parse error before `__THROW'
/usr/local/lib/gcc-lib/m68k-elf/2.95.3/../../../../m68k-elf/sys-include/shadow.h:101: 
warning: data definition has no type or storage class
auth.c: In function `auth_user':
auth.c:105: warning: assignment makes pointer from integer without a cast
auth.c: In function `auth_pass':
auth.c:156: warning: passing arg 1 of `crypt' discards qualifiers from pointer 
target type
auth.c: In function `sgetcred':
auth.c:189: warning: assignment makes pointer from integer without a cast

Does anyone have any help for me or a "stand-alone" Makefile?

Thank you



From richard.klingler at violasystems.com  Mon Mar 10 08:20:22 2003
From: richard.klingler at violasystems.com (Richard Klingler)
Date: Mon, 10 Mar 2003 15:20:22 +0200
Subject: [uClinux-dev] ip masquarade support
In-Reply-To: <1047300974.1923.11.camel@tossu>
Message-ID: <r01050400-1024-0C0E584552FB11D79D8200039387ACB6@[10.0.1.2]>

> krhm... uh... how? :)
> 
> /Roope
> 

Discussed many times (o;

Here you go:

    http://www.uclinux.net/phpBB2/viewtopic.php?t=7


enjoy
Rick


Richard Klingler             mail: richard.klingler at violasystems.com
Viola Systems Ltd.           http://www.violasystems.com/
Lemmink?isenkatu 32          phon: +358 (0)201 226 226
20520 Turku, Finland         mobile: +358 (0)40 748 4711


From mirco.cremasco at informacitta.it  Mon Mar 10 08:41:55 2003
From: mirco.cremasco at informacitta.it (mirco cremasco)
Date: Mon, 10 Mar 2003 14:41:55 +0100
Subject: [uClinux-dev] Compiling apps
References: <00d901c2c197$2d46eac0$c900a8c0@yeti> <3E2EA181.CD538F6C@enseirb.fr>
Message-ID: <3E6C9623.9090605@informacitta.it>

How to compile an application without adding it to the uClinux 
distribution tree??
I've tryed to compiling including vendors/config/m68knommu/config.arch 
(with some modifications) in my own Makefile but I get the following 
message:
...
fpgaio.elf2flt(.text+0x8): undefined reference to '__uClibc_main'
...

Any suggestions??
Thanks
Mirco



From philwil at earthlink.net  Mon Mar 10 08:21:33 2003
From: philwil at earthlink.net (Phil Wilshire)
Date: Mon, 10 Mar 2003 08:21:33 -0500
Subject: [uClinux-dev] ip masquarade support
References: <r01050400-1024-2D5C797152EE11D794AB00039387ACB6@[10.0.1.2]> <1047300974.1923.11.camel@tossu>
Message-ID: <3E6C915D.8D5B563@earthlink.net>

Hi Roope 

try one of these

m68k-elf-nm linux | grep 2fa05

m68k-elf-objdump -d linux | grep 2fa05

  regards
  Phil

> 
> krhm... uh... how? :)
> 
> /Roope
> 
> On Mon, 2003-03-10 at 13:48, Richard Klingler wrote:
> > > BAD KERNEL TRAP: 00000000
> > > PC: [<0002fa05>]
> > > SR: 2035  SP: 000b3d7e  a2: 000dec34
> > > d0: 00000000    d1: 00000000    d2: 00000000    d3: 00000000
> > > d4: 0002fa05    d5: 000485b4    a0: 000dec74    a1: 00000000
> >
> > Just look what routine is causing this at address 2fa05....
> >
> >
> > Rick
> >
> >
> > Richard Klingler             mail: richard.klingler at violasystems.com
> > Viola Systems Ltd.           http://www.violasystems.com/
> > Lemmink?isenkatu 32          phon: +358 (0)201 226 226
> > 20520 Turku, Finland         mobile: +358 (0)40 748 4711
> > _______________________________________________
> > uClinux-dev mailing list
> > uClinux-dev at uclinux.org
> > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> > This message was resent by uclinux-dev at uclinux.org
> 
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org

-- 
SDCS -- System Design & Consulting Services LLC, http://www.sysdcs.com
** Embedded Linux Training **  email me for details  
630 Springhouse Sq., Leesburg VA 20175 t: 703 669 9766 f: 703 669 9768


From rgegusch at mf.tu-berlin.de  Mon Mar 10 08:43:05 2003
From: rgegusch at mf.tu-berlin.de (Rene Gegusch)
Date: Mon, 10 Mar 2003 14:43:05 +0100
Subject: [uClinux-dev] FTP Server on the 5272 board
In-Reply-To: <3E6C87E3.6010604@snapgear.com>
References: <BC03D160581F7A4E92710FC238282411167809@ici-mail.intellicom.se> <200303101058.50986.rgegusch@mf.tu-berlin.de> <3E6C87E3.6010604@snapgear.com>
Message-ID: <200303101443.05403.rgegusch@mf.tu-berlin.de>

If I understand you, there are files missing to compile the project correctly. 
I do have the CD and I already checked for the mentioned crt0_ram.S file, 
which is there and the same as in my Arcturus Version.
So, what shall I looking for?

Am Montag, 10. M?rz 2003 13:41 schrieb Greg Ungerer:
> Hi Rene,
>
> Rene Gegusch wrote:
> > You were right. My downloaded file was corrupted. Thank you to KDE, which
> > did not mentioned that!
> > Anyway, i just started to try to compile the new distribution for my
> > Arcturus uCdimm 5272 system, but compiler very fast ended compilation
> > with an error.< <make dep> works fine, but on the next step <make> not
> > so.
> > It stops with an missing rule error...
> > make[2]: changing to directory
> > ?/home/rgegusch/test/uClinux-dist/linux-2.4.x/arch/m68knommu/platform/527
> >2? make[2]: *** no rule available for target ?/crt0_ram.S?,
> >   need of ?/crt0_ram.o?, to create.  End.
>
> Unfortunately the guys at Arcturus have not commited their uC5272
> linux-2.4.x kernel support to the CVS yet. So the low level files
> (for example the above mentioned crt0_ram.S) are not there. Which
> means they are not in the uClinux-dist either.
>
> If you have a source CD from Arcturus for the uC5272 then you
> would have those files. You could just pull them out and merge
> them. Will probably be a little bit of mucking around to get it
> all together, compiling and working.
>
> Regards
> Greg
>
> > (Compiler messages translated to English by myself)
> >
> > does anyone knows, what there is wrong?
> > I am not one of those kernel hacking freaks, originally had the plan to
> > compile the ftpd server, shipped with this distribution, but failed to
> > compile it because of missing PATH definitions.
> >
> > However, I need help!
> >
> > Am Freitag, 7. M?rz 2003 14:44 schrieb Greg Ungerer:
> >>Hi Rene,
> >>
> >>Rene Gegusch wrote:
> >>>Thank you for the information.
> >>>It confusses me, that the download of the new distribution does not have
> >>>it as you told us.
> >>>My distribution file has a size of about 105mb, seems to be OK, doesn't
> >>>it?
> >>
> >>The latest distribution definately contains a uClinux-dist/user/ftpd
> >>directory. If you don't have one then either you don't have the latest
> >>distribution or it is corrupted.
> >>
> >>Regards
> >>Greg
>
> ------------------------------------------------------------------------
> Greg Ungerer  --  Chief Software Wizard        EMAIL:  gerg at snapgear.com
> SnapGear Pty Ltd                               PHONE:    +61 7 3435 2888
> 825 Stanley St,                                  FAX:    +61 7 3891 3630
> Woolloongabba, QLD, 4102, Australia              WEB:   www.SnapGear.com
>
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org




From Mile.Davidovic at micronasnit.com  Mon Mar 10 09:00:59 2003
From: Mile.Davidovic at micronasnit.com (Mile Davidovic)
Date: Mon, 10 Mar 2003 15:00:59 +0100
Subject: [uClinux-dev] mips and elf2flt again
Message-ID: <20030310150059.51817ad0.Mile.Davidovic@micronasnit.com>

Hi people

I made simple "hello world" programm, and try to make flt executabile format. Platform is mips without MMU.

mips-linux-elf-gcc -fPIC -c test.c
mips-linux-elf-ld -d -r test.tmp crt0.o test.o libc.a
mips-linux-elf-ld -T elf2flt.ld -Ur -o test.elf test.tmp
mips-linux-elf-ld -T elf2flt.ld -o test.gdb test.tmp
elf2flt -r -o test.flt test.elf

In test.elf, I have next relocations: R_MIPS_26, R_MIPS_GPREL_16, R_MIPS_HI16 and R_MIPS_LO16.
I modified elf2flt to support these relocations, this is sample for R_MIPS_GPREL16 relocations:

case R_MIPS_GPREL16:
	relocation_needed = 1;
	gp0 = _bfd_get_gp_value(rel_bfd);
	gp = _bfd_get_gp_value(abs_bfd);					
	sym_vma = bfd_section_vma(abs_bfd, sym_section);				
	if ((*(q->sym_ptr_ptr))->flags & BSF_LOCAL) 
		sym_addr += ((q->addend + sym_vma + gp0 - gp) & q->howto->dst_mask);
	else 	
  	   sym_addr += ((q->addend + sym_vma + gp) & q->howto->dst_mask);
	
break;

Do I have to change/do something else? When I try to use this program in uCLinux I got next
output, it look like this little program try to alloc 4M ??? 
...
Calibrating delay loop... 107.72 BogoMIPS
Memory: 6040k/8192k available (722k kernel code, 2152k reserved, 128k data,
40k init, 0k highmem)
Dentry cache hash table entries: 1024 (order: 1, 8192 bytes)
Inode cache hash table entries: 512 (order: 0, 4096 bytes)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes)
Page-cache hash table entries: 2048 (order: 1, 8192 bytes)
Checking for 'wait' instruction...  unavailable.
POSIX conformance testing by UNIFIX
...
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
RAMDISK: romfs filesystem found at block 0
RAMDISK: Loading 66 blocks [1 disk] into ram disk... |/-\|done.
VFS: Mounted root (romfs filesystem) readonly.
Freeing unused kernel memory: 40k freed
BINFMT_FLAT: Loading file: /sbin/init
Allocation of length 4199194 from process 1 failed
Buffer memory:       12kB
Cache memory:       60kB
Free pages:        5796kB (     0kB HighMem)
Zone:DMA freepages:     0kB min:     0kB low:     0kB high:     0kB
Zone:Normal freepages:  5796kB min:    80kB low:   160kB high:   240kB
Zone:HighMem freepages:     0kB min:     0kB low:     0kB high:     0kB
( Active: 3, inactive: 15, free: 1449 )
= 0kB)
1*4kB 0*8kB 0*16kB 1*32kB 0*64kB 1*128kB 0*256kB 1*512kB 1*1024kB 0*2048kB
1*4096kB = 5796kB)
= 0kB)
Unable to allocate RAM for process text/data, errno 12

TIA
Mile



From gerg at snapgear.com  Mon Mar 10 09:42:38 2003
From: gerg at snapgear.com (Greg Ungerer)
Date: Tue, 11 Mar 2003 00:42:38 +1000
Subject: [uClinux-dev] FTP Server on the 5272 board
In-Reply-To: <200303101443.05403.rgegusch@mf.tu-berlin.de>
References: <BC03D160581F7A4E92710FC238282411167809@ici-mail.intellicom.se> <200303101058.50986.rgegusch@mf.tu-berlin.de> <3E6C87E3.6010604@snapgear.com> <200303101443.05403.rgegusch@mf.tu-berlin.de>
Message-ID: <3E6CA45E.5090903@snapgear.com>

Hi Rene,

Rene Gegusch wrote:
> If I understand you, there are files missing to compile the project correctly. 
> I do have the CD and I already checked for the mentioned crt0_ram.S file, 
> which is there and the same as in my Arcturus Version.
> So, what shall I looking for?

If your target is the uC5272 (which I assume from your error output)
then you need the files under:

   linux-2.4.x/arch/m68knommu/platform/5272/uC5272

which are not at cvs.uclinux.org and so not in uClinux-dist.

You will also need to update the arch/m68knommu/config.in and
Boards.mk files, which also do not contain options for uC5272.

Regards
Greg




> Am Montag, 10. M?rz 2003 13:41 schrieb Greg Ungerer:
> 
>>Hi Rene,
>>
>>Rene Gegusch wrote:
>>
>>>You were right. My downloaded file was corrupted. Thank you to KDE, which
>>>did not mentioned that!
>>>Anyway, i just started to try to compile the new distribution for my
>>>Arcturus uCdimm 5272 system, but compiler very fast ended compilation
>>>with an error.< <make dep> works fine, but on the next step <make> not
>>>so.
>>>It stops with an missing rule error...
>>>make[2]: changing to directory
>>>?/home/rgegusch/test/uClinux-dist/linux-2.4.x/arch/m68knommu/platform/527
>>>2? make[2]: *** no rule available for target ?/crt0_ram.S?,
>>>  need of ?/crt0_ram.o?, to create.  End.
>>
>>Unfortunately the guys at Arcturus have not commited their uC5272
>>linux-2.4.x kernel support to the CVS yet. So the low level files
>>(for example the above mentioned crt0_ram.S) are not there. Which
>>means they are not in the uClinux-dist either.
>>
>>If you have a source CD from Arcturus for the uC5272 then you
>>would have those files. You could just pull them out and merge
>>them. Will probably be a little bit of mucking around to get it
>>all together, compiling and working.
>>
>>Regards
>>Greg
>>
>>
>>>(Compiler messages translated to English by myself)
>>>
>>>does anyone knows, what there is wrong?
>>>I am not one of those kernel hacking freaks, originally had the plan to
>>>compile the ftpd server, shipped with this distribution, but failed to
>>>compile it because of missing PATH definitions.
>>>
>>>However, I need help!
>>>
>>>Am Freitag, 7. M?rz 2003 14:44 schrieb Greg Ungerer:
>>>
>>>>Hi Rene,
>>>>
>>>>Rene Gegusch wrote:
>>>>
>>>>>Thank you for the information.
>>>>>It confusses me, that the download of the new distribution does not have
>>>>>it as you told us.
>>>>>My distribution file has a size of about 105mb, seems to be OK, doesn't
>>>>>it?
>>>>
>>>>The latest distribution definately contains a uClinux-dist/user/ftpd
>>>>directory. If you don't have one then either you don't have the latest
>>>>distribution or it is corrupted.
>>>>
>>>>Regards
>>>>Greg
>>
>>------------------------------------------------------------------------
>>Greg Ungerer  --  Chief Software Wizard        EMAIL:  gerg at snapgear.com
>>SnapGear Pty Ltd                               PHONE:    +61 7 3435 2888
>>825 Stanley St,                                  FAX:    +61 7 3891 3630
>>Woolloongabba, QLD, 4102, Australia              WEB:   www.SnapGear.com
>>
>>_______________________________________________
>>uClinux-dev mailing list
>>uClinux-dev at uclinux.org
>>http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
>>This message was resent by uclinux-dev at uclinux.org
> 
> 
> 
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org
> 


-- 
------------------------------------------------------------------------
Greg Ungerer  --  Chief Software Wizard        EMAIL:  gerg at snapgear.com
SnapGear Pty Ltd                               PHONE:    +61 7 3435 2888
825 Stanley St,                                  FAX:    +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia              WEB:   www.SnapGear.com



From shred at wanadoo.fr  Mon Mar 10 09:36:51 2003
From: shred at wanadoo.fr (laurent van cauwelaert)
Date: Mon, 10 Mar 2003 15:36:51 +0100
Subject: [uClinux-dev] Compiling apps
References: <00d901c2c197$2d46eac0$c900a8c0@yeti> <3E2EA181.CD538F6C@enseirb.fr> <3E6C9623.9090605@informacitta.it>
Message-ID: <000901c2e712$7d38feb0$db00a8c0@lvancw2k>

bah t'as forcement un avis ...

ca t'embete ? ca t'embete pas ? tu preferes qu'on reste un
peu sur paris et qu'on achete quand meme ou tu preferes attendre ?

----- Original Message ----- 
From: "mirco cremasco" <mirco.cremasco at informacitta.it>
To: <uclinux-dev at uclinux.org>
Sent: Monday, March 10, 2003 2:41 PM
Subject: [uClinux-dev] Compiling apps


> How to compile an application without adding it to the uClinux 
> distribution tree??
> I've tryed to compiling including vendors/config/m68knommu/config.arch 
> (with some modifications) in my own Makefile but I get the following 
> message:
> ...
> fpgaio.elf2flt(.text+0x8): undefined reference to '__uClibc_main'
> ...
> 
> Any suggestions??
> Thanks
> Mirco
> 
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org



From heiko.degenhardt at sentec-elektronik.de  Mon Mar 10 09:31:31 2003
From: heiko.degenhardt at sentec-elektronik.de (Heiko Degenhardt)
Date: Mon, 10 Mar 2003 15:31:31 +0100
Subject: [uClinux-dev] mini_httpd, thttpd on uClinux/coldfire?
Message-ID: <20030310153131.A3398@www2.sentec-elektronik.de>

Hi list,

I would like to ask if someone of you has some experiences with
other webserver of the uClinux-dist than boa, eg. with mini_httpd or
thttpd on coldfire based eval board? Do they run on for instance a
M5249C3 board? I need a small webserver that can user
authentification and (may be later) https.

If someone here has some tips or things to look for, I would be
really interested.

Thanks for your help!
Rgds.
Heiko.



From m.calo at ctsgroup.it  Mon Mar 10 10:23:30 2003
From: m.calo at ctsgroup.it (=?iso-8859-1?Q?Cal=F2_Massimo?=)
Date: Mon, 10 Mar 2003 16:23:30 +0100
Subject: [uClinux-dev] Compiling apps
References: <00d901c2c197$2d46eac0$c900a8c0@yeti> <3E2EA181.CD538F6C@enseirb.fr> <3E6C9623.9090605@informacitta.it>
Message-ID: <004501c2e719$050c3540$e10106c0@Massimo>

Mirco,

    this makefile is for compiling an application running on MCF5272C3.

Ciao,

Massimo.

----- Original Message ----- 
From: "mirco cremasco" <mirco.cremasco at informacitta.it>
To: <uclinux-dev at uclinux.org>
Sent: Monday, March 10, 2003 2:41 PM
Subject: [uClinux-dev] Compiling apps


> How to compile an application without adding it to the uClinux 
> distribution tree??
> I've tryed to compiling including vendors/config/m68knommu/config.arch 
> (with some modifications) in my own Makefile but I get the following 
> message:
> ...
> fpgaio.elf2flt(.text+0x8): undefined reference to '__uClibc_main'
> ...
> 
> Any suggestions??
> Thanks
> Mirco
> 
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: makefile
Type: application/octet-stream
Size: 1521 bytes
Desc: not available
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20030310/93662cdc/attachment.obj>

From roope.anttinen at indagon.com  Mon Mar 10 10:29:47 2003
From: roope.anttinen at indagon.com (Roope Anttinen)
Date: 10 Mar 2003 17:29:47 +0200
Subject: [uClinux-dev] ip masquarade support
In-Reply-To: <3E6C915D.8D5B563@earthlink.net>
References: <r01050400-1024-2D5C797152EE11D794AB00039387ACB6@[10.0.1.2]>
	<1047300974.1923.11.camel@tossu>  <3E6C915D.8D5B563@earthlink.net>
Message-ID: <1047310189.2039.4.camel@tossu>

Doesn't return a thing... really weird

/Roope

On Mon, 2003-03-10 at 15:21, Phil Wilshire wrote:
> Hi Roope 
> 
> try one of these
> 
> m68k-elf-nm linux | grep 2fa05
> 
> m68k-elf-objdump -d linux | grep 2fa05
> 
>   regards
>   Phil
> 
> > 
> > krhm... uh... how? :)
> > 
> > /Roope
> > 
> > On Mon, 2003-03-10 at 13:48, Richard Klingler wrote:
> > > > BAD KERNEL TRAP: 00000000
> > > > PC: [<0002fa05>]
> > > > SR: 2035  SP: 000b3d7e  a2: 000dec34
> > > > d0: 00000000    d1: 00000000    d2: 00000000    d3: 00000000
> > > > d4: 0002fa05    d5: 000485b4    a0: 000dec74    a1: 00000000
> > >
> > > Just look what routine is causing this at address 2fa05....
> > >
> > >
> > > Rick
> > >
> > >
> > > Richard Klingler             mail: richard.klingler at violasystems.com
> > > Viola Systems Ltd.           http://www.violasystems.com/
> > > Lemmink?isenkatu 32          phon: +358 (0)201 226 226
> > > 20520 Turku, Finland         mobile: +358 (0)40 748 4711
> > > _______________________________________________
> > > uClinux-dev mailing list
> > > uClinux-dev at uclinux.org
> > > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> > > This message was resent by uclinux-dev at uclinux.org
> > 
> > _______________________________________________
> > uClinux-dev mailing list
> > uClinux-dev at uclinux.org
> > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> > This message was resent by uclinux-dev at uclinux.org
> 
> -- 
> SDCS -- System Design & Consulting Services LLC, http://www.sysdcs.com
> ** Embedded Linux Training **  email me for details  
> 630 Springhouse Sq., Leesburg VA 20175 t: 703 669 9766 f: 703 669 9768
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org




From mirco.cremasco at informacitta.it  Mon Mar 10 11:19:17 2003
From: mirco.cremasco at informacitta.it (mirco cremasco)
Date: Mon, 10 Mar 2003 17:19:17 +0100
Subject: [uClinux-dev] Compiling apps
References: <00d901c2c197$2d46eac0$c900a8c0@yeti> <3E2EA181.CD538F6C@enseirb.fr> <3E6C9623.9090605@informacitta.it>
Message-ID: <3E6CBB05.6080601@informacitta.it>


mirco cremasco wrote:

> How to compile an application without adding it to the uClinux 
> distribution tree??
> I've tryed to compiling including vendors/config/m68knommu/config.arch 
> (with some modifications) in my own Makefile but I get the following 
> message:
> ...
> fpgaio.elf2flt(.text+0x8): undefined reference to '__uClibc_main'
> ...
>
> Any suggestions??
> Thanks
> Mirco
>
Sorry for the stupid question, I've found by myself...
I'll report how I made so others newbies (like me) can find it with google.

My steps:
1) cp vendors/config/m68knommu/config.arch mysrc/config
2) edit config adding at the beginnig:
CONFIG_VENDOR=Motorola
CONFIG_PRODUCT=M5272C3
CONFIG_LINUXDIR=linux-2.4.x
CONFIG_LIBCDIR=uClibc
CONFIG_LANGUAGE=
CONFIG_USER_DEBUG=y
CPUFLAGS  = -m5307 -fomit-frame-pointer
VENDOR_CFLAGS = -DCONFIG_COLDFIRE -lc
UCLINUX_BUILD_USER =y

LINUXDIR = $(CONFIG_LINUXDIR)
LIBCDIR  = $(CONFIG_LIBCDIR)
ROOTDIR  = ~/uClinux-dist
PATH     := $(PATH):$(ROOTDIR)/tools
HOSTCC   = unset GCC_EXEC_PREFIX; cc
IMAGEDIR = $(ROOTDIR)/images
ROMFSDIR = $(ROOTDIR)/romfs
ROMFSINST= $(ROOTDIR)/tools/romfs-inst.sh
SCRIPTSDIR = $(ROOTDIR)/config/scripts
TFTPDIR    = /tftpboot

3) Edit a Makefile:

include config

EXEC = myapp
OBJS = myapp.o

all: $(EXEC)

$(EXEC): $(OBJS)
    $(CC) $(LDFLAGS) -o $@ $(OBJS) -lc

romfs:
    $(ROMFSINST) /bin/$(EXEC)

clean:
    -rm -f $(EXEC) *.elf *.gdb *.o




Bye
Mirco Cremasco



From napo at napo.ch  Mon Mar 10 11:53:37 2003
From: napo at napo.ch (Napoletano Daniel)
Date: Mon, 10 Mar 2003 17:53:37 +0100
Subject: [uClinux-dev] FTP Server Compiling Problems (Arcturus 5272)
References: <BC03D160581F7A4E92710FC238282411167809@ici-mail.intellicom.se> <200303071400.21002.rgegusch@mf.tu-berlin.de> <200303101109.30207.rgegusch@mf.tu-berlin.de> <200303101417.10843.rgegusch@mf.tu-berlin.de>
Message-ID: <005901c2e725$9b596b10$7a8844c0@19268136122>

Try to add the -lcryp or $(LIBCRYPT) directive to your Makefile.
Like $(CC) $(LDFLAGS) -o XXXX  $(LIBCRYPT) $(LDLIBS)
Regards Daniel

----- Original Message -----
From: "Rene Gegusch" <rgegusch at mf.tu-berlin.de>
To: <uclinux-dev at uclinux.org>
Sent: Monday, March 10, 2003 2:17 PM
Subject: [uClinux-dev] FTP Server Compiling Problems (Arcturus 5272)


> I tried it on...
>
> because of my troubles with compiling the new distribution, I decided to
add
> the FTPD directory to my "old" distribution and add there the new
> application.
> Should work, don't? It doesn't work better at all.
>
> Here the error message:
> In file included from auth.c:10:
> crypt.h:33: conflicting types for `crypt'
> /home/rgegusch/development/uClinux-coldfire/lib/libc/include/unistd.h:26:
> previous declaration of `crypt'
> In file included from auth.c:12:
>
/usr/local/lib/gcc-lib/m68k-elf/2.95.3/../../../../m68k-elf/sys-include/shad
ow.h:58:
> parse error before `__THROW'
> [...]
>  parse error before `__THROW'
>
/usr/local/lib/gcc-lib/m68k-elf/2.95.3/../../../../m68k-elf/sys-include/shad
ow.h:101:
> warning: data definition has no type or storage class
> auth.c: In function `auth_user':
> auth.c:105: warning: assignment makes pointer from integer without a cast
> auth.c: In function `auth_pass':
> auth.c:156: warning: passing arg 1 of `crypt' discards qualifiers from
pointer
> target type
> auth.c: In function `sgetcred':
> auth.c:189: warning: assignment makes pointer from integer without a cast
>
> Does anyone have any help for me or a "stand-alone" Makefile?
>
> Thank you
>
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org



From matthewn at snapgear.com  Mon Mar 10 13:39:45 2003
From: matthewn at snapgear.com (Matthew Natalier)
Date: Tue, 11 Mar 2003 04:39:45 +1000
Subject: [uClinux-dev] ip masquarade support
In-Reply-To: <1047310189.2039.4.camel@tossu>
References: <r01050400-1024-2D5C797152EE11D794AB00039387ACB6@[10.0.1.2]> <1047300974.1923.11.camel@tossu> <3E6C915D.8D5B563@earthlink.net> <1047310189.2039.4.camel@tossu>
Message-ID: <20030310183945.GA10450@liberation.internal.moreton.com.au>

Roope,

Try doing the following:

m68k-elf-nm -v linux > output.txt 2>&1

Then vi output.txt and look for what function 2fa05 appears in.  This
will hopefully point you to the source of the problem.  

nm will only list the address of functions within an object file, not 
the addresses of instructions.  The -v option causes nm to list the 
symbols in order which makes it easier to find where 2fa05 appears in 
your kernel file.

The objdump should have worked though, and is suspicious that it didn't.
Try using a -D rather than a -d.  This will get objdump to dissassemble
everything.

BTW is it valid on your architecture to have an instruction at an odd
address?

Cheers

Matt

Roope Anttinen wrote:
> Doesn't return a thing... really weird
> 
> /Roope
> 
> On Mon, 2003-03-10 at 15:21, Phil Wilshire wrote:
> > Hi Roope 
> > 
> > try one of these
> > 
> > m68k-elf-nm linux | grep 2fa05
> > 
> > m68k-elf-objdump -d linux | grep 2fa05
> > 
> >   regards
> >   Phil
> > 
> > > 
> > > krhm... uh... how? :)
> > > 
> > > /Roope
> > > 
> > > On Mon, 2003-03-10 at 13:48, Richard Klingler wrote:
> > > > > BAD KERNEL TRAP: 00000000
> > > > > PC: [<0002fa05>]
> > > > > SR: 2035  SP: 000b3d7e  a2: 000dec34
> > > > > d0: 00000000    d1: 00000000    d2: 00000000    d3: 00000000
> > > > > d4: 0002fa05    d5: 000485b4    a0: 000dec74    a1: 00000000
> > > >
> > > > Just look what routine is causing this at address 2fa05....
> > > >
> > > >
> > > > Rick
> > > >
> > > >
> > > > Richard Klingler             mail: richard.klingler at violasystems.com
> > > > Viola Systems Ltd.           http://www.violasystems.com/
> > > > Lemmink?isenkatu 32          phon: +358 (0)201 226 226
> > > > 20520 Turku, Finland         mobile: +358 (0)40 748 4711
> > > > _______________________________________________
> > > > uClinux-dev mailing list
> > > > uClinux-dev at uclinux.org
> > > > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> > > > This message was resent by uclinux-dev at uclinux.org
> > > 
> > > _______________________________________________
> > > uClinux-dev mailing list
> > > uClinux-dev at uclinux.org
> > > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> > > This message was resent by uclinux-dev at uclinux.org
> > 
> > -- 
> > SDCS -- System Design & Consulting Services LLC, http://www.sysdcs.com
> > ** Embedded Linux Training **  email me for details  
> > 630 Springhouse Sq., Leesburg VA 20175 t: 703 669 9766 f: 703 669 9768
> > _______________________________________________
> > uClinux-dev mailing list
> > uClinux-dev at uclinux.org
> > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> > This message was resent by uclinux-dev at uclinux.org
> 
> 
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org

-- 
Matthew Natalier
Systems Programmer
p: +61 7 3435 2805
f: +61 7 3891 3630
matthewn at SnapGear.com
http://www.SnapGear.com/
--
SnapGear
Custom Embedded Solutions
Security Appliances



From matthewn at snapgear.com  Mon Mar 10 13:52:48 2003
From: matthewn at snapgear.com (Matthew Natalier)
Date: Tue, 11 Mar 2003 04:52:48 +1000
Subject: [uClinux-dev] mini_httpd, thttpd on uClinux/coldfire?
In-Reply-To: <20030310153131.A3398@www2.sentec-elektronik.de>
References: <20030310153131.A3398@www2.sentec-elektronik.de>
Message-ID: <20030310185248.GC10450@liberation.internal.moreton.com.au>

Hi Heiko,

Is there any reason not to use boa?  It is reasonably small, supports
authentication and ssl (thanks to SnapGear).

If you want a small web server with ssl then you are probably out of
luck.  OpenSSL causes anything it is linked statically against to get 
really large.  I don't have any figures handy, but I seem to remember
boa growing by ~400k when it included ssl support.

Cheers

Matt

Heiko Degenhardt wrote:
> Hi list,
> 
> I would like to ask if someone of you has some experiences with
> other webserver of the uClinux-dist than boa, eg. with mini_httpd or
> thttpd on coldfire based eval board? Do they run on for instance a
> M5249C3 board? I need a small webserver that can user
> authentification and (may be later) https.
> 
> If someone here has some tips or things to look for, I would be
> really interested.
> 
> Thanks for your help!
> Rgds.
> Heiko.
> 
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org

-- 
Matthew Natalier
Systems Programmer
p: +61 7 3435 2805
f: +61 7 3891 3630
matthewn at SnapGear.com
http://www.SnapGear.com/
--
SnapGear
Custom Embedded Solutions
Security Appliances



From sdeepa69 at yahoo.com  Mon Mar 10 14:37:44 2003
From: sdeepa69 at yahoo.com (Deepa Sivasankarane)
Date: Mon, 10 Mar 2003 11:37:44 -0800 (PST)
Subject: [uClinux-dev] asm/signal.h
Message-ID: <20030310193744.29163.qmail@web80406.mail.yahoo.com>


Hi,

  NSIG (total no.  of signals is 32 for most processors).   I suppose we can

have signals more than 32,  ?  or should it adhere to Linux std of 32 signals ?

 

Thanx in advance,

Deepa



---------------------------------
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20030310/b9ab0e5a/attachment.html>

From tendim at tendim.cjb.net  Mon Mar 10 14:41:28 2003
From: tendim at tendim.cjb.net (patrick)
Date: Mon, 10 Mar 2003 14:41:28 -0500 (EST)
Subject: [uClinux-dev] uClinux and Dynamic Loading on Motorola Dragonball
Message-ID: <Pine.NEB.4.44.0303101441140.6384-100000@vex.net>

Hello.

I am currently trying to port an application to uClinux that uses
plug in modules, treated as dynamically loaded libraries (with the usual
dlopen(), dlerror(), etc. commands).

However, I've found that uClinux, or at least my current version, does not
have support for shared libraries; which I thought it did!

Is there any way to get shared (and dynamic) library support?  I've seen
that there are other uClinux versions (2.4.x versions) and newer uClibc
versions.  Would any of these help me out?

In the absense of this, does anybody have any suggestions as to how I can
have multiple functions with the same name; akin to having methods of
classes, but in C?  I could modify my technique to compile each 'plug-in'
module statically, but I would like to keep the API the same; each module
has an API it constrains itself to.

Many thanks!

Patrick Pritchard





From roope.anttinen at indagon.com  Mon Mar 10 15:34:37 2003
From: roope.anttinen at indagon.com (Roope Anttinen)
Date: 10 Mar 2003 22:34:37 +0200
Subject: [uClinux-dev] ip masquarade support
In-Reply-To: <20030310183945.GA10450@liberation.internal.moreton.com.au>
References: <r01050400-1024-2D5C797152EE11D794AB00039387ACB6@[10.0.1.2]>
	<1047300974.1923.11.camel@tossu> <3E6C915D.8D5B563@earthlink.net>
	<1047310189.2039.4.camel@tossu> 
	<20030310183945.GA10450@liberation.internal.moreton.com.au>
Message-ID: <1047328481.1930.2.camel@tossu>

Hi Matthew,

On Mon, 2003-03-10 at 20:39, Matthew Natalier wrote:
> Roope,
> 
> Try doing the following:
> 
> m68k-elf-nm -v linux > output.txt 2>&1
> 
> Then vi output.txt and look for what function 2fa05 appears in.  This
> will hopefully point you to the source of the problem.  

Did that but that particular 2fa05 doesn't exist in the output :(

> BTW is it valid on your architecture to have an instruction at an odd
> address?

IMHO it looks like it tries to jump into non existend address for some
reason and that's why the kernel dies.

> > > > > > BAD KERNEL TRAP: 00000000
> > > > > > PC: [<0002fa05>]
> > > > > > SR: 2035  SP: 000b3d7e  a2: 000dec34
> > > > > > d0: 00000000    d1: 00000000    d2: 00000000    d3: 00000000
> > > > > > d4: 0002fa05    d5: 000485b4    a0: 000dec74    a1: 00000000

/Roope




From richard.klingler at violasystems.com  Mon Mar 10 15:54:44 2003
From: richard.klingler at violasystems.com (Richard Klingler)
Date: Mon, 10 Mar 2003 22:54:44 +0200
Subject: [uClinux-dev] ip masquarade support
In-Reply-To: <1047328481.1930.2.camel@tossu>
Message-ID: <r01050400-1024-8616DDC0533A11D79D8200039387ACB6@[10.0.1.2]>

Try disassemling the whole image and look with a text editor
in which routine the address range lies...

Rick



> Hi Matthew,
> 
> On Mon, 2003-03-10 at 20:39, Matthew Natalier wrote:
> > Roope,
> > 
> > Try doing the following:
> > 
> > m68k-elf-nm -v linux > output.txt 2>&1
> > 
> > Then vi output.txt and look for what function 2fa05 appears in.  This
> > will hopefully point you to the source of the problem.  
> 
> Did that but that particular 2fa05 doesn't exist in the output :(
> 
> > BTW is it valid on your architecture to have an instruction at an odd
> > address?
> 
> IMHO it looks like it tries to jump into non existend address for some
> reason and that's why the kernel dies.
> 
> > > > > > > BAD KERNEL TRAP: 00000000
> > > > > > > PC: [<0002fa05>]
> > > > > > > SR: 2035  SP: 000b3d7e  a2: 000dec34
> > > > > > > d0: 00000000    d1: 00000000    d2: 00000000    d3: 00000000
> > > > > > > d4: 0002fa05    d5: 000485b4    a0: 000dec74    a1: 00000000
> 
> /Roope
> 
> 
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org
> 

Richard Klingler             mail: richard.klingler at violasystems.com
Viola Systems Ltd.           http://www.violasystems.com/
Lemmink?isenkatu 32          phon: +358 (0)201 226 226
20520 Turku, Finland         mobile: +358 (0)40 748 4711


From uClinux at muellerhydraulik.de  Mon Mar 10 16:24:07 2003
From: uClinux at muellerhydraulik.de (Jurgen Mueller)
Date: Mon, 10 Mar 2003 22:24:07 +0100
Subject: AW: [uClinux-dev] MINIX shell and BUSYbox
In-Reply-To: <3E6AACED.D605A37D@on-go.com>
Message-ID: <000501c2e74b$685acda0$7700a8c0@gandalf>

Hi Thomas,

I'm using MINIX Shell and Busybox on am Motorola Coldfire processor and I
don't have any problems.
SASH has some bulit in commands like cd, ls, ... You have to enable these
commands in Buysbox.
What are your problems? Compiling or runtime problems?

Regards

Juergen

-----Urspr?ngliche Nachricht-----
Von: uclinux-dev-admin at uclinux.org [mailto:uclinux-dev-admin at uclinux.org] Im
Auftrag von thomas chen
Gesendet: Sonntag, 9. M?rz 2003 03:55
An: uclinux-dev at uclinux.org
Betreff: [uClinux-dev] MINIX shell and BUSYbox

is busy box only available for SASH?
i just tried configuring MINUX shell and suddenly nothing work...

since i do not have any regular shell commands enabled and all using
busybox... i assume it is related to busybox in minix-shell?

thanks
_______________________________________________
uClinux-dev mailing list
uClinux-dev at uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev at uclinux.org




From uClinux at muellerhydraulik.de  Mon Mar 10 16:39:45 2003
From: uClinux at muellerhydraulik.de (Jurgen Mueller)
Date: Mon, 10 Mar 2003 22:39:45 +0100
Subject: AW: [uClinux-dev] uClinux and Dynamic Loading on Motorola Dragonball
In-Reply-To: <Pine.NEB.4.44.0303101441140.6384-100000@vex.net>
Message-ID: <000601c2e74d$987d9420$7700a8c0@gandalf>

Hi Patrick.

I think you can find some information at:

http://mailman.uclinux.org/pipermail/uclinux-dev/2002-July/009666.html


Is it possible that you are using function pointers. You only need to
initialize the pointer with the right function somwhere in an init routine.
Is this what you are searching for?

Regards

Juergen



-----Urspr?ngliche Nachricht-----
Von: uclinux-dev-admin at uclinux.org [mailto:uclinux-dev-admin at uclinux.org] Im
Auftrag von patrick
Gesendet: Montag, 10. M?rz 2003 20:41
An: uClinux-dev at uclinux.org
Betreff: [uClinux-dev] uClinux and Dynamic Loading on Motorola Dragonball

Hello.

I am currently trying to port an application to uClinux that uses
plug in modules, treated as dynamically loaded libraries (with the usual
dlopen(), dlerror(), etc. commands).

However, I've found that uClinux, or at least my current version, does not
have support for shared libraries; which I thought it did!

Is there any way to get shared (and dynamic) library support?  I've seen
that there are other uClinux versions (2.4.x versions) and newer uClibc
versions.  Would any of these help me out?

In the absense of this, does anybody have any suggestions as to how I can
have multiple functions with the same name; akin to having methods of
classes, but in C?  I could modify my technique to compile each 'plug-in'
module statically, but I would like to keep the API the same; each module
has an API it constrains itself to.

Many thanks!

Patrick Pritchard



_______________________________________________
uClinux-dev mailing list
uClinux-dev at uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev at uclinux.org




From KimK at UniqueSys.com  Mon Mar 10 16:37:07 2003
From: KimK at UniqueSys.com (Kim Klaiman)
Date: Mon, 10 Mar 2003 16:37:07 -0500
Subject: [uClinux-dev] MINIX shell and BUSYbox
Message-ID: <13A2053F3416D411935500508BC5D9580194623F@ubsexch01.uniquesys.com>

I used both minix and sash shell. Using minix shell I only had one problem:
during the booting, some commands did not work when executed from etc/rc.
After the booting was completed, everything worked fine. I needed some
commands executed during the booting, so I switched to sash shell.

Kim Klaiman

-----Original Message-----
From: Jurgen Mueller [mailto:uClinux at muellerhydraulik.de]
Sent: Monday, March 10, 2003 4:24 PM
To: uclinux-dev at uclinux.org
Subject: AW: [uClinux-dev] MINIX shell and BUSYbox


Hi Thomas,

I'm using MINIX Shell and Busybox on am Motorola Coldfire processor and I
don't have any problems.
SASH has some bulit in commands like cd, ls, ... You have to enable these
commands in Buysbox.
What are your problems? Compiling or runtime problems?

Regards

Juergen

-----Urspr?ngliche Nachricht-----
Von: uclinux-dev-admin at uclinux.org [mailto:uclinux-dev-admin at uclinux.org] Im
Auftrag von thomas chen
Gesendet: Sonntag, 9. M?rz 2003 03:55
An: uclinux-dev at uclinux.org
Betreff: [uClinux-dev] MINIX shell and BUSYbox

is busy box only available for SASH?
i just tried configuring MINUX shell and suddenly nothing work...

since i do not have any regular shell commands enabled and all using
busybox... i assume it is related to busybox in minix-shell?

thanks
_______________________________________________
uClinux-dev mailing list
uClinux-dev at uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev at uclinux.org


_______________________________________________
uClinux-dev mailing list
uClinux-dev at uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev at uclinux.org


From tchen at on-go.com  Mon Mar 10 17:14:46 2003
From: tchen at on-go.com (thomas chen)
Date: Mon, 10 Mar 2003 17:14:46 -0500
Subject: [uClinux-dev] MINIX shell and BUSYbox
References: <13A2053F3416D411935500508BC5D9580194623F@ubsexch01.uniquesys.com>
Message-ID: <3E6D0E56.5F1EDB76@on-go.com>


that is exactly my problem... all my commands are done in the /etc/rc

thats why i thought something went wrong..... 
stuff like cd, mkdir  are all failing

Kim Klaiman wrote:
> 
> I used both minix and sash shell. Using minix shell I only had one problem:
> during the booting, some commands did not work when executed from etc/rc.
> After the booting was completed, everything worked fine. I needed some
> commands executed during the booting, so I switched to sash shell.
> 
> Kim Klaiman
> 
> -----Original Message-----
> From: Jurgen Mueller [mailto:uClinux at muellerhydraulik.de]
> Sent: Monday, March 10, 2003 4:24 PM
> To: uclinux-dev at uclinux.org
> Subject: AW: [uClinux-dev] MINIX shell and BUSYbox
> 
> Hi Thomas,
> 
> I'm using MINIX Shell and Busybox on am Motorola Coldfire processor and I
> don't have any problems.
> SASH has some bulit in commands like cd, ls, ... You have to enable these
> commands in Buysbox.
> What are your problems? Compiling or runtime problems?
> 
> Regards
> 
> Juergen
> 
> -----Urspr?ngliche Nachricht-----
> Von: uclinux-dev-admin at uclinux.org [mailto:uclinux-dev-admin at uclinux.org] Im
> Auftrag von thomas chen
> Gesendet: Sonntag, 9. M?rz 2003 03:55
> An: uclinux-dev at uclinux.org
> Betreff: [uClinux-dev] MINIX shell and BUSYbox
> 
> is busy box only available for SASH?
> i just tried configuring MINUX shell and suddenly nothing work...
> 
> since i do not have any regular shell commands enabled and all using
> busybox... i assume it is related to busybox in minix-shell?
> 
> thanks
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org
> 
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org


From tendim at tendim.cjb.net  Mon Mar 10 18:29:34 2003
From: tendim at tendim.cjb.net (patrick)
Date: Mon, 10 Mar 2003 18:29:34 -0500 (EST)
Subject: AW: [uClinux-dev] uClinux and Dynamic Loading on Motorola
 Dragonball
In-Reply-To: <000601c2e74d$987d9420$7700a8c0@gandalf>
Message-ID: <Pine.NEB.4.44.0303101828380.15550-100000@vex.net>

Hello.

On Mon, 10 Mar 2003, Jurgen Mueller wrote:

> I think you can find some information at:
>
> http://mailman.uclinux.org/pipermail/uclinux-dev/2002-July/009666.html

Yes, I came upon this last week when looking for info.  However, it
referes to 2.4.x kernels, and I am using 2.0.x.  Hm.

Time to move this to another thread.  :)  thanks for the info Jurgen.

-patrick



From tendim at tendim.cjb.net  Mon Mar 10 18:30:19 2003
From: tendim at tendim.cjb.net (patrick)
Date: Mon, 10 Mar 2003 18:30:19 -0500 (EST)
Subject: [uClinux-dev] uCdimm with 2.4.x Kernel
Message-ID: <Pine.NEB.4.44.0303101829360.15550-100000@vex.net>

Hello.

Has anybody managed to get a 2.4.x Kernel and toolchains up and running?
If so, can you please tell me how?  I would like to try to get it running
for shared libraries, which I need for my application.

Thank you.

-Patrick

patrick at tendim.cjb.net
"It's simple, overspecialize and you breed in weakness."
 --Ghost in the Shell




From gevans at vigilhealth.com  Mon Mar 10 18:37:41 2003
From: gevans at vigilhealth.com (Greg Evans)
Date: Mon, 10 Mar 2003 15:37:41 -0800
Subject: [uClinux-dev] Colilo hangs
Message-ID: <001601c2e75e$22881180$0814a8c0@vigilhealth.com>

Hi,

I have been working with the M5272C3 development board with uClinux-dist 20020927. I want to have Motorola's DBUG left in flash at 0xFFE00000 and install Colilo at 0xFFF00000. Using CF FLASHER, I programmed flash with colilo.bin file starting at 0xFFF00000. Next I programmed flash with a compressed file of image.bin (uclinux-dist) located at address 0xFFF40000 (note: I am using the M5272C3-1MB file for Colilo). Both binaries are programmed without any errors.

I ran dbug and tried "go fff00000". I received an illegal instruction error. If I "di fff00000" in dbug I noticed that the code does not actually start until 0xFFF00400 with a "nop". When I tried "go fff00400" dbug hangs and the only way to gain control is to reset the board.

How can I get Colilo to work with the M5272C3?

Thanks,

Greg Evans
gevans at vigilhealth.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20030310/f921c7e2/attachment.html>

From sdeepa69 at yahoo.com  Mon Mar 10 18:58:49 2003
From: sdeepa69 at yahoo.com (Deepa Sivasankarane)
Date: Mon, 10 Mar 2003 15:58:49 -0800 (PST)
Subject: [uClinux-dev] (no subject)
Message-ID: <20030310235849.7276.qmail@web80405.mail.yahoo.com>


Hi folks,

    Could someone please point me to documentation regarding "architecture specific kernel interfaces" ?  The asm/  stuff..

 

thanx a bunch,

regards,

Deepa



---------------------------------
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20030310/1169265b/attachment.html>

From HenrySimmons17 at netzero.net  Mon Mar 10 19:30:54 2003
From: HenrySimmons17 at netzero.net (HenrySimmons17)
Date: Mon, 10 Mar 2003 16:30:54 -0800
Subject: [uClinux-dev] Colilo hangs
References: <001601c2e75e$22881180$0814a8c0@vigilhealth.com>
Message-ID: <000201c2e765$adeb7e40$ffc5fea9@henry133>

Hello Greg...
What I do is install Colilo at 0xffe20000, install the compress kernel at
0xffe30000.
Then call colilo: go ffe20400.
Henry
> I have been working with the M5272C3 development board with uClinux-dist
20020927. I want to have Motorola's DBUG left in flash at 0xFFE00000 and
install Colilo at 0xFFF00000. Using CF FLASHER, I programmed flash with
colilo.bin file starting at 0xFFF00000. Next I programmed flash with a
compressed file of image.bin (uclinux-dist) located at address 0xFFF40000
(note: I am using the M5272C3-1MB file for Colilo). Both binaries are
programmed without any errors.
>
> I ran dbug and tried "go fff00000". I received an illegal instruction
error. If I "di fff00000" in dbug I noticed that the code does not actually
start until 0xFFF00400 with a "nop". When I tried "go fff00400" dbug hangs
and the only way to gain control is to reset the board.
>
> How can I get Colilo to work with the M5272C3?
>
> Thanks,
>
> Greg Evans
> gevans at vigilhealth.com
>



From rebackhua at seu.edu.cn  Mon Mar 10 19:28:18 2003
From: rebackhua at seu.edu.cn (zhouhua)
Date: Tue, 11 Mar 2003 08:28:18 +0800
Subject: [uClinux-dev] Re: Compiling apps
References: <20030310134901.22237.61081.Mailman@geekcreek.net>
Message-ID: <001301c2e765$1d23e500$d10aa8c0@rebackhua>

> 
> Message: 14
> Date: Mon, 10 Mar 2003 14:41:55 +0100
> From: mirco cremasco <mirco.cremasco at informacitta.it>
> To: uclinux-dev at uclinux.org
> Subject: [uClinux-dev] Compiling apps
> Reply-To: uclinux-dev at uclinux.org
> 
> How to compile an application without adding it to the uClinux 
> distribution tree??
> I've tryed to compiling including vendors/config/m68knommu/config.arch 
> (with some modifications) in my own Makefile but I get the following 
> message:
> ...
> fpgaio.elf2flt(.text+0x8): undefined reference to '__uClibc_main'
> ...
> 
> Any suggestions??
> Thanks
> Mirco
> 
> 
undefined reference may be a kind error of linkage. 
I met it because I did not use appropriate libraries or there sequence.



From tchen at on-go.com  Mon Mar 10 23:06:48 2003
From: tchen at on-go.com (Thomas Chen)
Date: Mon, 10 Mar 2003 20:06:48 -0800
Subject: [uClinux-dev] (no subject)
In-Reply-To: <20030310235849.7276.qmail@web80405.mail.yahoo.com>
Message-ID: <BA92A0D8.8F8D%tchen@on-go.com>


imho, the best place to look is the users-guide from the processor
manufacturer...
that would give you a fairly good idea about the architecture

on 3/10/03 3:58 PM, Deepa Sivasankarane at sdeepa69 at yahoo.com wrote:


Hi folks, 

   Could someone please point me to documentation regarding "architecture
specific kernel interfaces" ?  The asm/  stuff..



thanx a bunch, 

regards, 

Deepa





Do you Yahoo!?
Yahoo! Mail Plus 
<http://rd.yahoo.com/mail/mailsig/*http://mailplus.yahoo.com>  - Powerful.
Affordable. Sign up now
<http://rd.yahoo.com/mail/mailsig/*http://mailplus.yahoo.com>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20030310/45d601fd/attachment.html>

From philwil at earthlink.net  Mon Mar 10 23:26:22 2003
From: philwil at earthlink.net (Phil Wilshire)
Date: Mon, 10 Mar 2003 23:26:22 -0500
Subject: AW: [uClinux-dev] uClinux and Dynamic Loading on Motorola Dragonball
References: <000601c2e74d$987d9420$7700a8c0@gandalf>
Message-ID: <3E6D656E.C732BE23@earthlink.net>

Patrick,

Take a look at busybox.
This uses a multifunction binary 
There are many links under different names to the same executable.
The executable looks at arg0 to determine name under which it was called and then
performs the appropiate function.

I know this sounds simple but it is not too hard to do.

regards
  Phil Wilshire



Jurgen Mueller wrote:
> 
> Hi Patrick.
> 
> I think you can find some information at:
> 
> http://mailman.uclinux.org/pipermail/uclinux-dev/2002-July/009666.html
> 
> Is it possible that you are using function pointers. You only need to
> initialize the pointer with the right function somwhere in an init routine.
> Is this what you are searching for?
> 
> Regards
> 
> Juergen
> 
> -----Urspr?ngliche Nachricht-----
> Von: uclinux-dev-admin at uclinux.org [mailto:uclinux-dev-admin at uclinux.org] Im
> Auftrag von patrick
> Gesendet: Montag, 10. M?rz 2003 20:41
> An: uClinux-dev at uclinux.org
> Betreff: [uClinux-dev] uClinux and Dynamic Loading on Motorola Dragonball
> 
> Hello.
> 
> I am currently trying to port an application to uClinux that uses
> plug in modules, treated as dynamically loaded libraries (with the usual
> dlopen(), dlerror(), etc. commands).
> 
> However, I've found that uClinux, or at least my current version, does not
> have support for shared libraries; which I thought it did!
> 
> Is there any way to get shared (and dynamic) library support?  I've seen
> that there are other uClinux versions (2.4.x versions) and newer uClibc
> versions.  Would any of these help me out?
> 
> In the absense of this, does anybody have any suggestions as to how I can
> have multiple functions with the same name; akin to having methods of
> classes, but in C?  I could modify my technique to compile each 'plug-in'
> module statically, but I would like to keep the API the same; each module
> has an API it constrains itself to.
> 
> Many thanks!
> 
> Patrick Pritchard
> 
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org
> 
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org

-- 
SDCS -- System Design & Consulting Services LLC, http://www.sysdcs.com
** Embedded Linux Training **  email me for details  
630 Springhouse Sq., Leesburg VA 20175 t: 703 669 9766 f: 703 669 9768


From jwilliams at itee.uq.edu.au  Mon Mar 10 23:53:00 2003
From: jwilliams at itee.uq.edu.au (John Williams)
Date: Tue, 11 Mar 2003 14:53:00 +1000
Subject: [uClinux-dev] kernel versioning (version.h)
Message-ID: <3E6D6BAC.1020408@itee.uq.edu.au>

Hi there,

Does anybody know a painless way to disable the "auto-touch" that 
happens on either version.h or compiler.h?

My toolchain running under Cygwin is very slow and I'm sick of waiting 
for version.c to recompile every time I make a change in one of my 
arch-specific sources and rerun "make linux".

I tried commenting out some of the rules under compiler.h and version.h 
in /linux-2.4.x/Makefile, but that seemed to make it worse, forcing a 
full kernel recompile each time!

Thanks,

John



From pavangs at myw.ltindia.com  Tue Mar 11 01:31:32 2003
From: pavangs at myw.ltindia.com (Pavan G S)
Date: Tue, 11 Mar 2003 12:01:32 +0530
Subject: [uClinux-dev] problem with read aheads in a block device driver
Message-ID: <se6dd039.080@EMAIL>

Hi all,
I'am writing a block device driver on a uclinux platform.
whenever a read is performed, if the address range goes beyond the
range of device address i'am performing an end_request(0) which is
issuing a message "i/o error::end_request(0)" and the 
request function is again called....sometimes 4 times, sometimes 8
times, etc i.e what i reckon is that it is performing read ahead inspite
of initialising read_ahead[] to zero.
how to stop the request function from being called once i find its
crossing the range?
Thanks in advance,
Pavan


From heiko.degenhardt at sentec-elektronik.de  Tue Mar 11 01:47:17 2003
From: heiko.degenhardt at sentec-elektronik.de (Heiko Degenhardt)
Date: Tue, 11 Mar 2003 07:47:17 +0100
Subject: [uClinux-dev] mini_httpd, thttpd on uClinux/coldfire?
In-Reply-To: <20030310185248.GC10450@liberation.internal.moreton.com.au>; from matthewn@snapgear.com on Tue, Mar 11, 2003 at 04:52:48AM +1000
References: <20030310153131.A3398@www2.sentec-elektronik.de> <20030310185248.GC10450@liberation.internal.moreton.com.au>
Message-ID: <20030311074717.A6204@www2.sentec-elektronik.de>

Hi Matt, 

* On Tue, Mar 11, 2003 at 04:52:48AM +1000, Matthew Natalier wrote:
> Is there any reason not to use boa?  It is reasonably small, supports
> authentication and ssl (thanks to SnapGear).

oh, thanks for that hint! I didn't noticed that boa can do that
(that is the problem with not looking into the source but in the
internet. I read on the (shure a bit outdated) website at 
http://www.acme.com/software/thttpd/benchmarks.html,
and concluded that boa would not be the right thing).

> If you want a small web server with ssl then you are probably out of
> luck.  OpenSSL causes anything it is linked statically against to get 
> really large.  I don't have any figures handy, but I seem to remember
> boa growing by ~400k when it included ssl support.

Yes, I read about the openssl stuff on the list. It will be the
decision of the customer. If they want it, they'll get it. ;)

Thanks again for your help!
Rgds.
Heiko.



From jwilliams at itee.uq.edu.au  Tue Mar 11 01:57:34 2003
From: jwilliams at itee.uq.edu.au (John Williams)
Date: Tue, 11 Mar 2003 16:57:34 +1000
Subject: [uClinux-dev] init_mem_alloc and PAGE_OFFSET
Message-ID: <3E6D88DE.6010407@itee.uq.edu.au>

Hi folks,

My port is based on the v850, so Miles you might be able to help here :)

Basically, where should PAGE_OFFSET point in a uclinux system?

On my dev board I only have 1MB of SRAM, arbitrarily mapped from 
0xFFE00000 -> 0xFFEFFFFF  .  I know this isn't enough for a production 
system, but my bare kernel image is only about 500K so I should be OK 
for a little while.

I have a little debug stub/bootloader in on-chip memory (0x0000 -> 
0x1FFF) that grabs a kernel image over the serial port and initialises 
all the segments etc in their appropriate places.

Anyway so the kernel loads into RAM at FFE00000, and after several hours 
of frustrating debugging I found that the init_mem_alloc function is 
stomping on a significant portion of my kernel image :(  sometimes, 
having an MMU would be nice!

I think it's all to do with how I set the PAGE_OFFSET macro.

Currently I take a leaf out of the v850 book and set PAGE_OFFSET to the 
start of external RAM, however I think because my entire kernel is 
living there, that's causing the problem... where should PAGE_OFFSET 
point in a uclinux system?  At the end of the kernel image?

My revised interpretation is that it should point to the first page of 
"allocateable" memory, is that right?  Should I maybe add a symbol to 
the link script so I can easily determine where the kernel (and ROMFS 
etc) ends, then round up to the nearest page boundary?

Any general principles I should apply here?

Thanks,

John



From heiko.degenhardt at sentec-elektronik.de  Tue Mar 11 02:31:47 2003
From: heiko.degenhardt at sentec-elektronik.de (Heiko Degenhardt)
Date: Tue, 11 Mar 2003 08:31:47 +0100
Subject: [uClinux-dev] Colilo hangs
In-Reply-To: <001601c2e75e$22881180$0814a8c0@vigilhealth.com>; from gevans@vigilhealth.com on Mon, Mar 10, 2003 at 03:37:41PM -0800
References: <001601c2e75e$22881180$0814a8c0@vigilhealth.com>
Message-ID: <20030311083147.B6204@www2.sentec-elektronik.de>

Hi Greg,

* On Mon, Mar 10, 2003 at 03:37:41PM -0800, Greg Evans wrote:
> I have been working with the M5272C3 development board with
> uClinux-dist 20020927. I want to have Motorola's DBUG left in
> flash at 0xFFE00000 and install Colilo at 0xFFF00000. Using CF
> FLASHER, I programmed flash with colilo.bin file starting at
> 0xFFF00000. Next I programmed flash with a compressed file of
> image.bin (uclinux-dist) located at address 0xFFF40000 (note: I am
> using the M5272C3-1MB file for Colilo).

I don't know something about the M5272C3-1MB file, but your setup is
quiet comparable to our setup of colilo (MCF5272 based board, too).

> Both binaries are programmed without any errors.

Ok.

> How can I get Colilo to work with the M5272C3?

We do it the following way: We want to boot either colilo/uClinux or
dBUG, debending on a jumper on our board (I think on the C3 board it
is jumper 13).
We build colilo for the 0xFFE00000 range.
Than we flash the image to 0xFFF00000, and the (compressed) uClinux
image at 0xFFF40000 (the adresses, the image size etc. are adjusted
in main.c).

You can see the firs two words that the Coldfire looks up after
booting in dBUG:

dBUG> md fff00000
FFF00000:  0000 0000 FFE0 0400 FFE0 046C FFE0 046C...

The "FFE0 0400" is the initial program counter. There you'll find
the startup code of colilo:

dBUG> dis fff00400
FFF00400: 4E71                 NOP
FFF00402: 46FC 2700            MOVE      #0x2700,SR
FFF00406: 203C FFE0 0000       MOVE.L    #0xFFE00000,D0
FFF0040C: 4E7B 0801            MOVEC     D0,VBR                                
...

(I had to use fff00400 as address, because this will be the address
0xFFE00400 if we boot from the other flash sector).

That doesn't answer your question why the colilo doesn't start
with "go fff00400" (may be this has something to do with the register
setup of dBUG and colilo, or it starts the image and then dies or
whatever). But I think that wouldn't be the default way to
start it anyway.

May be you should try to do the following:
- Enable the CONFIG_UI and BOOTDEBUG in the Makefile
- Build colilo for the adress 0xffe00000
- Flash it to 0xfff00000 (with JP 13 set between pins 1 and 2)
- Set JP 13 between pins 2 and 3
- Reset the board

Now you should see the colilo prompt. If so you can play with
it to load the image etc. If not you seem to have a problem with
the colilo binary itself.

If you have further questions, please email me and I'll try to help
you further.

Rgds.
Heiko.




From miles at lsi.nec.co.jp  Tue Mar 11 03:28:02 2003
From: miles at lsi.nec.co.jp (Miles Bader)
Date: 11 Mar 2003 17:28:02 +0900
Subject: [uClinux-dev] Re: init_mem_alloc and PAGE_OFFSET
In-Reply-To: <3E6D88DE.6010407@itee.uq.edu.au>
References: <3E6D88DE.6010407@itee.uq.edu.au>
Message-ID: <buovfyqqpd9.fsf@mcspd15.ucom.lsi.nec.co.jp>

John Williams <jwilliams at itee.uq.edu.au> writes:
> Basically, where should PAGE_OFFSET point in a uclinux system?
...
> My revised interpretation is that it should point to the first page of 
> "allocateable" memory, is that right?

That's exactly right (to the best of the my knowledge).

> Should I maybe add a symbol to the link script so I can easily
> determine where the kernel (and ROMFS etc) ends, then round up to the
> nearest page boundary?

I have some vague memory that it must be known at compile-time, but I
can't find anything immediately that would suggest this, so perhaps I'm
simply mis-remembering.

I do find the following comment in my own code, though, so a
page-boundary is probably not good enough:

	/* The allocator is very picky about the address of the first
	   allocatable page -- it must be at least as aligned as the
	   maximum allocation -- so try to detect cases where it will get
	   confused and signal them at compile time (this is a common
	   problem when porting to a new platform with ).  There is a
	   similar runtime check in free_area_init_core.  */
   #if ((PAGE_OFFSET >> PAGE_SHIFT) & ((1UL << (MAX_ORDER - 1)) - 1))
   #error MAX_ORDER is too large for given PAGE_OFFSET (use CONFIG_FORCE_MAX_ZONEORDER to change it)
   #endif

-Miles
-- 
Saa, shall we dance?  (from a dance-class advertisement)


From roope.anttinen at indagon.com  Tue Mar 11 03:32:41 2003
From: roope.anttinen at indagon.com (Roope Anttinen)
Date: 11 Mar 2003 10:32:41 +0200
Subject: [uClinux-dev] ip masquarade support
In-Reply-To: <r01050400-1024-8616DDC0533A11D79D8200039387ACB6@[10.0.1.2]>
References: <r01050400-1024-8616DDC0533A11D79D8200039387ACB6@[10.0.1.2]>
Message-ID: <1047371564.1924.5.camel@tossu>

Started all over with as stripped image as possible which does basically
nothing more than boots...

Here we go:
uClinux/MC68VZ328
uCdimm by Lineo, Inc. <www.lineo.com>
M68VZ328 support by Evan Stawnyczy <e at lineo.ca>
Flat model support (C) 1998,1999 Kenneth Albanowski, D. Jeff Dionne
On node 0 totalpages: 1536
zone(0): 0 pages.
zone(1): 1536 pages.
zone(2): 0 pages.
Kernel command line: 
Calibrating delay loop... 3.28 BogoMIPS
Memory available: 5644k/6016k RAM, 0k/0k ROM (712k kernel code, 289k
data)
Dentry cache hash table entries: 1024 (order: 1, 8192 bytes)
Inode cache hash table entries: 512 (order: 0, 4096 bytes)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes)
Page-cache hash table entries: 2048 (order: 1, 8192 bytes)
POSIX conformance testing by UNIFIX
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
Starting kswapd
pty: 256 Unix98 ptys configured
MC68328 serial driver version 1.00
ttyS0 at 0xfffff900 (irq = 2) is a builtin MC68328 UART
ttyS1 at 0xfffff910 (irq = 12) is a builtin MC68328 UART
cs89x0:cs89x0_probe(0x0)
cs89x0: Setting up uCcs8900 Chip Select & IRQ ioaddr = 0x10000300
cs89x0.c: v2.4.3-pre1 Russell Nelson <nelson at crynwr.com>, Andrew Morton
<andrew>
eth0: cs8900 rev J found at 0x10000300 
cs89x0 media RJ-45, IRQ 20, programmed I/O, MAC 00:06:3b:00:00:62
cs89x0_probe1() successful
cs89x0:cs89x0_probe(0xffe0)
cs89x0: Setting up uCcs8900 Chip Select & IRQ ioaddr = 0xFFE0
eth1: cs8920 rev ` found at 0xffe0 
cs89x0 media RJ-45, IRQ 20, programmed I/O, MAC 00:06:3b:00:00:62
cs89x0_probe1() successful
cs89x0:cs89x0_probe(0xffe0)
cs89x0: Setting up uCcs8900 Chip Select & IRQ ioaddr = 0xFFE0
eth2: cs8900 rev A found at 0xffe0 
cs89x0 media RJ-45, IRQ 20, programmed I/O, MAC 00:06:3b:00:00:62
cs89x0_probe1() successful
cs89x0:cs89x0_probe(0xffe0)
cs89x0: Setting up uCcs8900 Chip Select & IRQ ioaddr = 0xFFE0
eth3: cs8920 rev A found at 0xffe0 
cs89x0 media RJ-45, IRQ 20, programmed I/O, MAC 00:06:3b:00:00:62
cs89x0_probe1() successful
cs89x0:cs89x0_probe(0xffe0)
cs89x0: Setting up uCcs8900 Chip Select & IRQ ioaddr = 0xFFE0
eth4: cs8900 rev A found at 0xffe0 
cs89x0 media RJ-45, IRQ 20, programmed I/O, MAC 00:06:3b:00:00:62
cs89x0_probe1() successful
cs89x0:cs89x0_probe(0xffe0)
cs89x0: Setting up uCcs8900 Chip Select & IRQ ioaddr = 0xFFE0
eth5: cs8920 rev A found at 0xffe0 
cs89x0 media RJ-45, IRQ 20, programmed I/O, MAC 00:06:3b:00:00:62
cs89x0_probe1() successful
cs89x0:cs89x0_probe(0xffe0)
cs89x0: Setting up uCcs8900 Chip Select & IRQ ioaddr = 0xFFE0
eth6: cs8900 rev A found at 0xffe0 
cs89x0 media RJ-45, IRQ 20, programmed I/O, MAC 00:06:3b:00:00:62
cs89x0_probe1() successful
cs89x0:cs89x0_probe(0xffe0)
cs89x0: Setting up uCcs8900 Chip Select & IRQ ioaddr = 0xFFE0
eth7: cs8920 rev A found at 0xffe0 
cs89x0 media RJ-45, IRQ 20, programmed I/O, MAC 00:06:3b:00:00:62
cs89x0_probe1() successful
Blkmem copyright 1998,1999 D. Jeff Dionne
Blkmem copyright 1998 Kenneth Albanowski
Blkmem 1 disk images:
0: 10CF47E8-10DD43E7 [VIRTUAL 10CF47E8-10DD43E7] (RO)
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
PPP generic driver version 2.4.2
PPP Deflate Compression module registered
PPP BSD Compression module registered
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 512 bind 512)
ip_conntrack version 2.1 (48 buckets, 384 max) - 316 bytes per conntrack
ip_tables: (C) 2000-2002 Netfilter core team
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
VFS: Mounted root (romfs filesystem) readonly.
eth0: 10Base-T (RJ-45) has no cable
eth0: using half-duplex 10Base-T (RJ-45)
Welcome to
          ____ _  _
         /  __| ||_|                 
    _   _| |  | | _ ____  _   _  _  _ 
   | | | | |  | || |  _ \| | | |\ \/ /
   | |_| | |__| || | | | | |_| |/    \
   |  ___\____|_||_|_| |_|\____|\_/\_/
   | |
   |_|

For further information check:
http://www.uclinux.org/

..ok stays up. Then I plug in the ethernet cable and OOOPS!

*** UNASSIGNED RESERVED 12 ***   FORMAT=2
Current process id is 0
BAD KERNEL TRAP: 00000000
PC: [<0002f7df>]
SR: 2035  SP: 00050cc4  a2: 000dec34
d0: 00000000    d1: 00000000    d2: 00000000    d3: 00000000
d4: 0002f7df    d5: 00048414    a0: 000dec74    a1: 00000000
Process swapper (pid: 0, stackpage=0004ff60)
Frame format=2 instr addr=200010c9
Stack from 00050cfc:
        d4860000 00000000 00000000 00000004 84140000 00000005 0e560011
c0500003
        72ac0011 c0500005 0e560044 00000000 00000000 0002f7df 00048414
00000000
        000ddb94 00000000 00000005 0d8a10c9 f59c0005 0e560000 00000004
84140000
        00000004 cc680000 00000000 00010000 00000011 c0fc0011 c0500000
0bb80011
        c05010c9 b5aa0011 c050000d db800005 0dca10c9 f1620005 0e560000
00000004
        84140000 00000011 c0500011 c0fc0004 966810c7 b6da0000 00000005
0e4210c7
Call Trace:
        [<10c11e28>] [<10c11e52>] [<10c104d6>] [<10cb6d72>]
        [<10c1048e>]


Found that 2f7df from the linux image:

0002a560 d npindex_to_ethertype
0002bc20 d rtm_min
0002bc40 d rta_max
0002be22 d prio2band
0002dbd7 D timer_bug_msg
0002f7df d nulldevname.1221
000326ce d border
00032872 d mark.174
00032876 d inflate_copyright

and 

> grep -r nulldevname *
net/ipv4/netfilter/ip_tables.c: static const char nulldevname[IFNAMSIZ]
= { 0 };
net/ipv4/netfilter/ip_tables.c: indev = in ? in->name : nulldevname;
net/ipv4/netfilter/ip_tables.c: outdev = out ? out->name : nulldevname;
Binary file net/ipv4/netfilter/ip_tables.o matches
net/ipv4/netfilter/arp_tables.c:        static const char
nulldevname[IFNAMSIZ] = { 0 };
net/ipv4/netfilter/arp_tables.c:        indev = in ? in->name :
nulldevname;
net/ipv4/netfilter/arp_tables.c:        outdev = out ? out->name :
nulldevname;
Binary file net/ipv4/netfilter/netfilter.o matches
net/ipv6/netfilter/ip6_tables.c:        static const char
nulldevname[IFNAMSIZ] = { 0 };
net/ipv6/netfilter/ip6_tables.c:        indev = in ? in->name :
nulldevname;
net/ipv6/netfilter/ip6_tables.c:        outdev = out ? out->name :
nulldevname;
Binary file net/network.o matches

So, what now??

/Roope




From leachbj at bouncycastle.org  Tue Mar 11 04:18:17 2003
From: leachbj at bouncycastle.org (Bernard Leach)
Date: 11 Mar 2003 10:18:17 +0100
Subject: [uClinux-dev] init_mem_alloc and PAGE_OFFSET
In-Reply-To: <3E6D88DE.6010407@itee.uq.edu.au>
References: <3E6D88DE.6010407@itee.uq.edu.au>
Message-ID: <1047374296.1945.8.camel@localhost>

On Tue, 2003-03-11 at 07:57, John Williams wrote:
> Hi folks,
> 
> My port is based on the v850, so Miles you might be able to help here :)
> 
> Basically, where should PAGE_OFFSET point in a uclinux system?

It should point to the start of your RAM.  The memory initialisation
should ensure that any required portions of your RAM that are in-use
before the real memory allocator gets started are reserved.  On the ARM
system I am using it reserves the entire kernel space during startup and
then once the kernel has initialised it free's some of that up (the
_init sections).

Things may be different on your platform but I'd be surprised if the
general principles were different.

As to your problem with the memory allocation stomping on the kernel
where exactly does that occur?

cheers,
bernard.




From jwilliams at itee.uq.edu.au  Tue Mar 11 06:25:33 2003
From: jwilliams at itee.uq.edu.au (John Willlams)
Date: Tue, 11 Mar 2003 21:25:33 +1000
Subject: [uClinux-dev] init_mem_alloc and PAGE_OFFSET
Message-ID: <001601c2e7c0$fd823060$0307a8c0@john.qut.edu.au>

Hi Bernard,

[snip Q about FRAME_OFFSET]

>It should point to the start of your RAM.  The memory initialisation
>should ensure that any required portions of your RAM that are in-use
>before the real memory allocator gets started are reserved.  On the ARM
>system I am using it reserves the entire kernel space during startup and
>then once the kernel has initialised it free's some of that up (the
>_init sections).

Aah, so that explains the use of the _init section!  So the kernel can give
it back after startup... very clever.

>Things may be different on your platform but I'd be surprised if the
>general principles were different.

Thanks Bernard, I think you've given me what I was looking for.

>As to your problem with the memory allocation stomping on the kernel
>where exactly does that occur?

I don't remember precisely (I'm @ home at the moment), but it's one of the
early init_XX functions called in start_kernel() - init_mem perhaps, or
something similar.  The code in question actually lives in
/arch/microblaze/kernel, which I pilfered from Miles Bader's excellent v850
code.

I'll get back into it tomorrow morning and have another go.

Thanks again,

John



From heiko.degenhardt at sentec-elektronik.de  Tue Mar 11 06:30:31 2003
From: heiko.degenhardt at sentec-elektronik.de (Heiko Degenhardt)
Date: Tue, 11 Mar 2003 12:30:31 +0100
Subject: [uClinux-dev] FrameBuffer for MCF5272
In-Reply-To: <20030305153748.61465.qmail@web21108.mail.yahoo.com>; from cc_3rdproject@yahoo.com on Wed, Mar 05, 2003 at 07:37:48AM -0800
References: <20030305153748.61465.qmail@web21108.mail.yahoo.com>
Message-ID: <20030311123031.A6870@www2.sentec-elektronik.de>

Hi Dan, 

* On Wed, Mar 05, 2003 at 07:37:48AM -0800, Dan Galway, James
* Gilbrook wrote:
> We are doing a final project for a computer engineering course and
> this uClinux post is quite similar to what we are trying to
> implement.

sorry that my answer is a bit late. But theres a whole lot to do
currently...

> We are using an Epson S1D13505 LCD/CRT controller IC
> (which seems to have support for uClinux built-in).

What do you mean with "built-in"?
I know there are drivers for the S1D controllers for "normal" Linux,
but at least with that one for the 13706 we had no luck to use it
for uClinux.

> The controller will be used with an NEC NL6448AC33-13 10.4" TFT
> display.

Hm. Don't know that display. We use a Kyocera KCS057QV1AJ-G23
(1/4 VGA, 8 bit color STN).

> Currently we are designing boards.. and Heiko, if you had the
> time, it would be informative to hear if there are any cautions or
> advice you'd have in working with the Epson display controller.
> We assume it is feasible to get this controller up and running
> under uClinux and Microwindows, but we could find no information
> on people  who have done this.

Ok. I'll try to remember some of the problems we had.

- Be very careful what display you use! See if your choosed display
  is made for doing such a task, where you have to plug and unplug
  the cable very often etc.!
- Allways ensure that you have the latest data sheets (and erata
  sheets) for all components, as the Coldfire, the LCD controller,
  the display etc.
- Pay attention to the used /CS. On our board we had to use a pull
  up resistor (4.7k) to get it working corrctly, but that depends on
  your specific layout (in our case the /CS is driven).
- We use the Generic#1 interface, but with some corrections
- You have to connect the config pins (in our case CNF[7:0] to suit
  your needs.
  We use:
  CNF[2:0]  = 011 Generic#1 interface
  CNF[3]    = 1   GPIO pins are inputs at PWR ON
  CNF[4]    = 1   Big Endian bus interface
  CNF[5]    = 1   /Wait is active high
  CNF[7:6]  = 01  BCLK is 1/2 CLKI
- We had some trouble getting the /WE0 and /WE1 line connected
  correctly (there was a mistake in the coldfire data sheet).
  We now use /BS1 and /BS0 as input for the logic that drives 
  /WE0 and /WE1.
- Set up the /CS as needed (in your bootloader or in your
  crt0_ram.S. We have:
   // set up CS1:
   move.l   #0x40000201, %d0
   move.l   %d0, (MCF_MBAR + MCFSIM_CSBR1)
   move.l   #0xfff000fc, %d0
   move.l   %d0, (MCF_MBAR + MCFSIM_CSOR1)
   // enable /TA at PB5:
   move.l   #0x55554555, %d0
   move.l   %d0, (MCF_MBAR + MCFSIM_PBCNT)
  (as you see we use /TA for that chip select, no waitstates).

Now some more general rules for the design of such a board:
- Ensure that the data lines are not too small, eg. 12mil minimum
- Layout the power supply lines as big as possible
- The lines to the display should be as short as possible
  (the cable that came with our display were to long, too).

The steps we followed were:
- Get the hardware layouted and everything connected
- Do some measurements if the board and the controller work as
  required (voltage levels and currents are as expected)
- Do some small software tests, for instance with m68k-bdm-elf-gdb
  or Motorolas dBUG. That means: Try to read the version register,
  try to write some registers, try to access the graphic memory etc.
  (this way you can for instance check if your address and data lines
  are connected correctly. We found a mistake in the data sheet of
  another display we used by testing that).
- Write some small test programs for the initialization of the whole
  thing, to read/write the registers, to read/write/fill the memory
  etc.
- Implement the framebuffer driver. In our case that meant:
  Creation of:
   linux-2.4.x/drivers/video/s1d13706fb.c
   linux-2.4.x/drivers/video/s1d13706fb.h
  Changing of:
   linux-2.4.x/drivers/video/Makefile
   linux-2.4.x/drivers/video/fbmem.c
   linux-2.4.x/arch/m68knommu/config.in
   linux-2.4.x/arch/m68knommu/platform/5272/senTec/crt0_ram.S
   vendors/senTec/COBRA5272/config.linux-2.4.x
  (I wanted to clean up the whole thing a bit before I would send
  the patches to Greg to get it into CVS. But I'll have not enough
  time in the next month to do that. So if you are interested I
  would just send you my "pre" stuff).
- Adjust the Microwindows stuff a bit to get it compiled under
  uClinux and to use the new driver.
  
REMARK: I'm not shure if everything we did is correct or doesn't
destroy something! All I can tell is that it run on our board during
an exibition some weeks ago without problems!
It's allso possible that I forgot some steps that we did. Please
only use the above as some hints, not as guidelines!

If you have further questions please let me know.
Rgds.
Heiko.



From davidm at snapgear.com  Tue Mar 11 06:32:35 2003
From: davidm at snapgear.com (David McCullough)
Date: Tue, 11 Mar 2003 21:32:35 +1000
Subject: [uClinux-dev] init_mem_alloc and PAGE_OFFSET
In-Reply-To: <1047374296.1945.8.camel@localhost>
References: <3E6D88DE.6010407@itee.uq.edu.au> <1047374296.1945.8.camel@localhost>
Message-ID: <20030311113235.GA26877@beast.internal.moreton.com.au>

Jivin Bernard Leach lays it down ...
> On Tue, 2003-03-11 at 07:57, John Williams wrote:
> > Hi folks,
> > 
> > My port is based on the v850, so Miles you might be able to help here :)
> > 
> > Basically, where should PAGE_OFFSET point in a uclinux system?
> 
> It should point to the start of your RAM.  The memory initialisation
> should ensure that any required portions of your RAM that are in-use
> before the real memory allocator gets started are reserved.  On the ARM
> system I am using it reserves the entire kernel space during startup and
> then once the kernel has initialised it free's some of that up (the
> _init sections).
> 
> Things may be different on your platform but I'd be surprised if the
> general principles were different.

AFAIK these principles are the same on every platform.

> As to your problem with the memory allocation stomping on the kernel
> where exactly does that occur?

It sounds like you are not reserving the kernel memory correctly at
bootmem_init time.  You need to reserve:
	
	* the kernel text (if in RAM), data & bss
	* the kernel allocator bitmap
	* the romfs if it is in RAM

That generally covers it all, m68k/arm are also good working examples to
look at,

Cheers,
Davidm

-- 
David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
davidm at snapgear.com  Fx: +61 7 3891 3630  Custom Embedded Solutions + Security


From hans at wilmers.no  Tue Mar 11 07:30:07 2003
From: hans at wilmers.no (Hans Wilmers)
Date: Tue, 11 Mar 2003 13:30:07 +0100
Subject: [uClinux-dev] uCdimm with 2.4.x Kernel
In-Reply-To: <Pine.NEB.4.44.0303101829360.15550-100000@vex.net>
References: <Pine.NEB.4.44.0303101829360.15550-100000@vex.net>
Message-ID: <200303111330.07688.hans@wilmers.no>

Hi,
I am using uCdimm 68VZ328, and the 2.4.19 kernel worked for me out of the box 
with uClinux-dist-20020927 and the precompiled toolchain 
m68k-elf-tools-20020410 .

You may need to adapt the scheduler initialisation, if you need a precise 
system time. This was discussed several times in this list.

I never used shared libraries, though.
If you get them working on 68VZ328, please tell the list!

I didn't get the time to test the new kernel distribution, but chances are 
that it works right out of the box too.

Regards
Hans


On Tuesday 11 March 2003 00:30, patrick wrote:
> Hello.
>
> Has anybody managed to get a 2.4.x Kernel and toolchains up and running?
> If so, can you please tell me how?  I would like to try to get it running
> for shared libraries, which I need for my application.
>
> Thank you.
>
> -Patrick
>
> patrick at tendim.cjb.net
> "It's simple, overspecialize and you breed in weakness."
>  --Ghost in the Shell
>
>
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org



From tendim at tendim.cjb.net  Tue Mar 11 08:47:26 2003
From: tendim at tendim.cjb.net (patrick)
Date: Tue, 11 Mar 2003 08:47:26 -0500 (EST)
Subject: AW: [uClinux-dev] uClinux and Dynamic Loading on Motorola
 Dragonball
In-Reply-To: <3E6D656E.C732BE23@earthlink.net>
Message-ID: <Pine.NEB.4.44.0303110844030.21116-100000@vex.net>

Hi Phil.

On Mon, 10 Mar 2003, Phil Wilshire wrote:

> The executable looks at arg0 to determine name under which it was called and then
> performs the appropiate function.

I'm not sure how this would help though.  Here's my problem:

- I have a server application that uses plug in modules
- Each module conforms to an API -- there are a certain number of
functions that it *must* have
- On load, I use dlopen with RTLD_NOW
- I use dlsym() to find all of the functions listed in the API and obtain
pointers to them
- Each of the function pointers are stored in a struct
- When the server runs, I simply run the pointer:
	(*(struct->fcn_ptr))(arg1, ...)

-Patrick



From tendim at tendim.cjb.net  Tue Mar 11 09:00:01 2003
From: tendim at tendim.cjb.net (patrick)
Date: Tue, 11 Mar 2003 09:00:01 -0500 (EST)
Subject: [uClinux-dev] uCdimm with 2.4.x Kernel
In-Reply-To: <200303111330.07688.hans@wilmers.no>
Message-ID: <Pine.NEB.4.44.0303110859340.21726-100000@vex.net>

On Tue, 11 Mar 2003, Hans Wilmers wrote:

> I am using uCdimm 68VZ328, and the 2.4.19 kernel worked for me out of the box
> with uClinux-dist-20020927 and the precompiled toolchain
> m68k-elf-tools-20020410 .

This is promising!  All of my stuff is at home right now, but I'll be
working on this tonight or tomorrow.  I'll keep the group updated on my
progress.

-Patrick


>
> You may need to adapt the scheduler initialisation, if you need a precise
> system time. This was discussed several times in this list.
>
> I never used shared libraries, though.
> If you get them working on 68VZ328, please tell the list!
>
> I didn't get the time to test the new kernel distribution, but chances are
> that it works right out of the box too.
>
> Regards
> Hans
>
>
> On Tuesday 11 March 2003 00:30, patrick wrote:
> > Hello.
> >
> > Has anybody managed to get a 2.4.x Kernel and toolchains up and running?
> > If so, can you please tell me how?  I would like to try to get it running
> > for shared libraries, which I need for my application.
> >
> > Thank you.
> >
> > -Patrick
> >
> > patrick at tendim.cjb.net
> > "It's simple, overspecialize and you breed in weakness."
> >  --Ghost in the Shell
> >
> >
> > _______________________________________________
> > uClinux-dev mailing list
> > uClinux-dev at uclinux.org
> > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> > This message was resent by uclinux-dev at uclinux.org
>
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org
>

patrick at tendim.cjb.net
"It's simple, overspecialize and you breed in weakness."
 --Ghost in the Shell




From matthewn at snapgear.com  Tue Mar 11 09:13:11 2003
From: matthewn at snapgear.com (Matthew Natalier)
Date: Wed, 12 Mar 2003 00:13:11 +1000
Subject: AW: [uClinux-dev] uClinux and Dynamic Loading on Motorola Dragonball
In-Reply-To: <Pine.NEB.4.44.0303110844030.21116-100000@vex.net>
References: <3E6D656E.C732BE23@earthlink.net> <Pine.NEB.4.44.0303110844030.21116-100000@vex.net>
Message-ID: <20030311141311.GB22936@liberation.internal.moreton.com.au>

patrick wrote:
> 
> I'm not sure how this would help though.  Here's my problem:
> 
> - I have a server application that uses plug in modules
> - Each module conforms to an API -- there are a certain number of
> functions that it *must* have
Ouch.  Lot's of apps do this, and they are a pain for use in uClinux.
user/iptables does this, but also shows a way of getting around it.

> - On load, I use dlopen with RTLD_NOW
> - I use dlsym() to find all of the functions listed in the API and obtain
> pointers to them
This is not supported in uClinux.  Actually I believe there was some
shared library work which worked towards this, but I haven't seen it
released under the GPL.

> - Each of the function pointers are stored in a struct
> - When the server runs, I simply run the pointer:
> 	(*(struct->fcn_ptr))(arg1, ...)
> 
I think the easiest method for getting something like this to work would
be to have each lib statically link into your app.

Declare the public functions as static.

Add an "init" function to each of your libraries which does nothing besides 
register the api.

Look in user/iptables/extensions/initext.c and iptables generally for
how this might work.  Particularly have a look at the init functions in
user/iptables/extensions.

If you want to be able to determine things dynamically, that gets more
complicated.

Cheers

Matt

> -Patrick
> 
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org

-- 
Matthew Natalier
Systems Programmer
p: +61 7 3435 2805
f: +61 7 3891 3630
matthewn at SnapGear.com
http://www.SnapGear.com/
--
SnapGear
Custom Embedded Solutions
Security Appliances



From tchen at on-go.com  Tue Mar 11 12:33:08 2003
From: tchen at on-go.com (Thomas Chen)
Date: Tue, 11 Mar 2003 09:33:08 -0800
Subject: [uClinux-dev] driver initialization sequence control
Message-ID: <BA935DD4.8FC4%tchen@on-go.com>

is there any way to control the initialization of
the drivers... ie... in each driver, the init is defined
and stored in the table, but i would like to find out
anyway to control the sequence of the initialization
calls???

thanks


tom



From richard.klingler at violasystems.com  Tue Mar 11 11:18:04 2003
From: richard.klingler at violasystems.com (Richard Klingler)
Date: Tue, 11 Mar 2003 18:18:04 +0200
Subject: [uClinux-dev] new bootloader
In-Reply-To: <BA935DD4.8FC4%tchen@on-go.com>
Message-ID: <r01050400-1024-09C5BAB953DD11D7A99600039387ACB6@[10.0.1.2]>

Evening (o;

Finally got some spare time to test the u-boot-0.2.0
Coldfire port (o;

Looks promising...


U-Boot 0.2.0 (Mar 11 2003 - 17:55:00)
Viola Systems Arctic Board
Adapted by richard at uclinux.net

Calling init code at: 003e4562...
MOTOROLA Coldfire MCF5272
Calling init code at: 003eb55c...
Viola Systems Oy Arctic Board
         http://www.violasystems.com/
Calling init code at: 003e47ba...
DRAM:   4 MB
Initialized init_fnc_ptr...
length = 00015650...
FLASH:  4 MB
*** Warning - bad CRC, using default environment

In:    serial
Out:   serial
Err:   serial
Arctic> version

U-Boot 0.2.0 (Mar 11 2003 - 17:55:00)
Viola Systems Arctic Board
Adapted by richard at uclinux.net
Arctic> 


Rick


Richard Klingler             mail: richard.klingler at violasystems.com
Viola Systems Ltd.           http://www.violasystems.com/
Lemmink?isenkatu 32          phon: +358 (0)201 226 226
20520 Turku, Finland         mobile: +358 (0)40 748 4711


From tendim at tendim.cjb.net  Tue Mar 11 11:30:38 2003
From: tendim at tendim.cjb.net (patrick)
Date: Tue, 11 Mar 2003 11:30:38 -0500 (EST)
Subject: AW: [uClinux-dev] uClinux and Dynamic Loading on Motorola
 Dragonball
In-Reply-To: <20030311141311.GB22936@liberation.internal.moreton.com.au>
Message-ID: <Pine.NEB.4.44.0303111128540.27075-100000@vex.net>

On Wed, 12 Mar 2003, Matthew Natalier wrote:

> Ouch.  Lot's of apps do this, and they are a pain for use in uClinux.
> user/iptables does this, but also shows a way of getting around it.
>
> I think the easiest method for getting something like this to work would
> be to have each lib statically link into your app.
>
> Declare the public functions as static.
>
> Add an "init" function to each of your libraries which does nothing besides
> register the api.

Is this the way that user/iptables does it?  I'm not at home now, so I
can't look at the code.  But it does seem promising, and only requires
minor modifiations to my API.  Thanks!

> If you want to be able to determine things dynamically, that gets more
> complicated.

This was the plan, but keeping the modularity of the system is my main
objective.  If that requires recompiling things, I can work around it --
as long as I can keep stuff separate.

Best,
Patrick

patrick at tendim.cjb.net
"It's simple, overspecialize and you breed in weakness."
 --Ghost in the Shell




From lars.segerlund at comsys.se  Tue Mar 11 12:13:57 2003
From: lars.segerlund at comsys.se (Lars Segerlund)
Date: Tue, 11 Mar 2003 18:13:57 +0100
Subject: [uClinux-dev] new bootloader
In-Reply-To: <r01050400-1024-09C5BAB953DD11D7A99600039387ACB6@[10.0.1.2]>
References: <r01050400-1024-09C5BAB953DD11D7A99600039387ACB6@[10.0.1.2]>
Message-ID: <3E6E1955.4050809@comsys.se>

  Where did you find the port ? I searched for the u-boot coldfire a 
while ago and didn't find anything usable ?

  / regards, Lars Segerlund.

Richard Klingler wrote:
> Evening (o;
> 
> Finally got some spare time to test the u-boot-0.2.0
> Coldfire port (o;
> 
> Looks promising...
> 
> 
> U-Boot 0.2.0 (Mar 11 2003 - 17:55:00)
> Viola Systems Arctic Board
> Adapted by richard at uclinux.net
> 
> Calling init code at: 003e4562...
> MOTOROLA Coldfire MCF5272
> Calling init code at: 003eb55c...
> Viola Systems Oy Arctic Board
>          http://www.violasystems.com/
> Calling init code at: 003e47ba...
> DRAM:   4 MB
> Initialized init_fnc_ptr...
> length = 00015650...
> FLASH:  4 MB
> *** Warning - bad CRC, using default environment
> 
> In:    serial
> Out:   serial
> Err:   serial
> Arctic> version
> 
> U-Boot 0.2.0 (Mar 11 2003 - 17:55:00)
> Viola Systems Arctic Board
> Adapted by richard at uclinux.net
> Arctic> 
> 
> 
> Rick
> 
> 
> Richard Klingler             mail: richard.klingler at violasystems.com
> Viola Systems Ltd.           http://www.violasystems.com/
> Lemmink?isenkatu 32          phon: +358 (0)201 226 226
> 20520 Turku, Finland         mobile: +358 (0)40 748 4711
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org
> 



From richard.klingler at violasystems.com  Tue Mar 11 12:55:49 2003
From: richard.klingler at violasystems.com (Richard Klingler)
Date: Tue, 11 Mar 2003 19:55:49 +0200
Subject: [uClinux-dev] new bootloader
In-Reply-To: <3E6E1955.4050809@comsys.se>
Message-ID: <r01050400-1024-B1CE368A53EA11D7A99600039387ACB6@[10.0.1.2]>

> 
>   Where did you find the port ? I searched for the u-boot coldfire a 
> while ago and didn't find anything usable ?
> 
>   / regards, Lars Segerlund.
> 
> > U-Boot 0.2.0 (Mar 11 2003 - 17:55:00)
> > Viola Systems Arctic Board
> > Adapted by richard at uclinux.net

Doesn't show this my name and the company name I work for? (o;


Rick


Richard Klingler             mail: richard.klingler at violasystems.com
Viola Systems Ltd.           http://www.violasystems.com/
Lemmink?isenkatu 32          phon: +358 (0)201 226 226
20520 Turku, Finland         mobile: +358 (0)40 748 4711


From gevans at vigilhealth.com  Tue Mar 11 13:44:52 2003
From: gevans at vigilhealth.com (Greg Evans)
Date: Tue, 11 Mar 2003 10:44:52 -0800
Subject: [uClinux-dev] Colilo hangs
References: <001601c2e75e$22881180$0814a8c0@vigilhealth.com>
 <20030311083147.B6204@www2.sentec-elektronik.de>
Message-ID: <000901c2e7fe$4fbfe240$0814a8c0@vigilhealth.com>

Thanks for getting back to me so quickly. I followed your instructions and I
still could not get Colilo to boot on reset. The one thing that was
bothering me was that whether I had JP13 on the M5272C3 board configured for
pins 1-2 or pins 2-3, DBUG always booted. I looked through the M5272C3
User's Manual and sure enough JP13 was mentionned as the jumper for this
very application. It's not that I doubted Motorola, but I took a look at the
board and noticed that there was a table scribed on the underside of the
pcb. There, I found that JP5 is used to switch between booting from
0xFFE00000 and 0xFFF00000 (Hmmm documentation error!). Anyways, I switch JP5
from pins 1-2 to 2-3 and reset the board. What do you know -- the Colilo
prompt came up!!!!

Just in case there is someone out there who may have the same problem: do
not forget to check your board. Mine is a DigitalDNA from Motorola RE10795B
Rev. 2.2. If yours is the same make and you are experiencing the same
problem, then chances are JP5 is the jumper you want.

Greg Evans
gevans at vigilhealth.com


----- Original Message -----
From: "Heiko Degenhardt" <heiko.degenhardt at sentec-elektronik.de>
To: <uclinux-dev at uclinux.org>
Sent: Monday, March 10, 2003 11:31 PM
Subject: Re: [uClinux-dev] Colilo hangs


> Hi Greg,
>
> * On Mon, Mar 10, 2003 at 03:37:41PM -0800, Greg Evans wrote:
> > I have been working with the M5272C3 development board with
> > uClinux-dist 20020927. I want to have Motorola's DBUG left in
> > flash at 0xFFE00000 and install Colilo at 0xFFF00000. Using CF
> > FLASHER, I programmed flash with colilo.bin file starting at
> > 0xFFF00000. Next I programmed flash with a compressed file of
> > image.bin (uclinux-dist) located at address 0xFFF40000 (note: I am
> > using the M5272C3-1MB file for Colilo).
>
> I don't know something about the M5272C3-1MB file, but your setup is
> quiet comparable to our setup of colilo (MCF5272 based board, too).
>
> > Both binaries are programmed without any errors.
>
> Ok.
>
> > How can I get Colilo to work with the M5272C3?
>
> We do it the following way: We want to boot either colilo/uClinux or
> dBUG, debending on a jumper on our board (I think on the C3 board it
> is jumper 13).
> We build colilo for the 0xFFE00000 range.
> Than we flash the image to 0xFFF00000, and the (compressed) uClinux
> image at 0xFFF40000 (the adresses, the image size etc. are adjusted
> in main.c).
>
> You can see the firs two words that the Coldfire looks up after
> booting in dBUG:
>
> dBUG> md fff00000
> FFF00000:  0000 0000 FFE0 0400 FFE0 046C FFE0 046C...
>
> The "FFE0 0400" is the initial program counter. There you'll find
> the startup code of colilo:
>
> dBUG> dis fff00400
> FFF00400: 4E71                 NOP
> FFF00402: 46FC 2700            MOVE      #0x2700,SR
> FFF00406: 203C FFE0 0000       MOVE.L    #0xFFE00000,D0
> FFF0040C: 4E7B 0801            MOVEC     D0,VBR
> ...
>
> (I had to use fff00400 as address, because this will be the address
> 0xFFE00400 if we boot from the other flash sector).
>
> That doesn't answer your question why the colilo doesn't start
> with "go fff00400" (may be this has something to do with the register
> setup of dBUG and colilo, or it starts the image and then dies or
> whatever). But I think that wouldn't be the default way to
> start it anyway.
>
> May be you should try to do the following:
> - Enable the CONFIG_UI and BOOTDEBUG in the Makefile
> - Build colilo for the adress 0xffe00000
> - Flash it to 0xfff00000 (with JP 13 set between pins 1 and 2)
> - Set JP 13 between pins 2 and 3
> - Reset the board
>
> Now you should see the colilo prompt. If so you can play with
> it to load the image etc. If not you seem to have a problem with
> the colilo binary itself.
>
> If you have further questions, please email me and I'll try to help
> you further.
>
> Rgds.
> Heiko.
>
>
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org
>



From lars.segerlund at comsys.se  Tue Mar 11 13:51:17 2003
From: lars.segerlund at comsys.se (Lars Segerlund)
Date: Tue, 11 Mar 2003 19:51:17 +0100
Subject: [uClinux-dev] new bootloader
In-Reply-To: <r01050400-1024-B1CE368A53EA11D7A99600039387ACB6@[10.0.1.2]>
References: <r01050400-1024-B1CE368A53EA11D7A99600039387ACB6@[10.0.1.2]>
Message-ID: <3E6E3025.9010105@comsys.se>

  Sorry, my ability to infer information was not enough in this care ;-D

  / thanks, Lars Segerlund.

Richard Klingler wrote:
>>  Where did you find the port ? I searched for the u-boot coldfire a 
>>while ago and didn't find anything usable ?
>>
>>  / regards, Lars Segerlund.
>>
>>
>>>U-Boot 0.2.0 (Mar 11 2003 - 17:55:00)
>>>Viola Systems Arctic Board
>>>Adapted by richard at uclinux.net
> 
> 
> Doesn't show this my name and the company name I work for? (o;
> 
> 
> Rick
> 
> 
> Richard Klingler             mail: richard.klingler at violasystems.com
> Viola Systems Ltd.           http://www.violasystems.com/
> Lemmink?isenkatu 32          phon: +358 (0)201 226 226
> 20520 Turku, Finland         mobile: +358 (0)40 748 4711
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org
> 



From makiniaa at yahoo.es  Tue Mar 11 13:59:01 2003
From: makiniaa at yahoo.es (=?iso-8859-1?q?Ignacio=20Uria?=)
Date: Tue, 11 Mar 2003 19:59:01 +0100 (CET)
Subject: [uClinux-dev] cross compiling (gsmlib)
Message-ID: <20030311185901.27965.qmail@web14506.mail.yahoo.com>

Hello,

I'm trying to cross-compile gsmlib:

          http://www.pxh.de/fs/gsmlib/

for an ARM7TDMI,which is running uclinux.What kind of
modifications should I do to get the libraries
compiled? Has anyone tried it? 

I need use the croos compiling for this arquitecture.

I have done it:

export CC=arm-uclinux-gcc
export CXX=arm-uclinux-c++
./configure --host =arm-uclinux --build=i386-linux

We also have made a few modifications in:

 /scripts/config.sub

in order to get the system host type recognized. 

The error write in config.log is:

configure:8004: error: cannot run test program while
cross compiling

Any advice is welcome!!


___________________________________________________
Yahoo! Messenger - Nueva versi?n GRATIS
Super Webcam, voz, caritas animadas, y m?s...
http://messenger.yahoo.es


From justin at tmq.com.au  Tue Mar 11 01:19:49 2003
From: justin at tmq.com.au (Justin Clacherty)
Date: 11 Mar 2003 16:19:49 +1000
Subject: [uClinux-dev] bdm driver installation failing
Message-ID: <1047363594.1785.11.camel@rhianna.tmq.com.au>

Hi,

I'm trying to set up debugging through the bdm in gdb.  I've installed
the bdm driver but when I run chk /dev/bdmcf0 the driver seems to be
failing to connect to the target.  I turned on debugging and it looks
like it is failing when it tries to read a register on the target. 
Below is the command I am using and its output, along with the relevant
output in /var/log/messages.  I'm using the P&E Micro wiggler that came
with our Motorola M5272C3 development board.  Does anyone know what I
might be doing wrong?

The commands I'm using with the output...

[justin at rhianna test]$ ./chk -d 4 /dev/bdmcf0
Driver Ver : 2.a
Processor  : Coldfire
Interface  : P&E Coldfire
Reading CSR failed: Invalid target command
[justin at rhianna test]$

/var/log/messages

Mar 11 15:57:32 rhianna kernel:  cf_pe_read_sysreg - Reg:0xf failed with
cmd 0x2d80, err = 217
Mar 11 15:57:32 rhianna kernel: debugFlag now 4
Mar 11 15:57:32 rhianna kernel: BDMioctl cmd:0x8004421e
Mar 11 15:57:32 rhianna kernel: BDMioctl cmd:0x8004421f
Mar 11 15:57:32 rhianna kernel: BDMioctl cmd:0x80044220
Mar 11 15:57:32 rhianna kernel: BDMioctl cmd:0x4201
Mar 11 15:57:32 rhianna kernel:  cf_pe_reset_chip
Mar 11 15:57:33 rhianna kernel: BDMioctl cmd:0xc0084215
Mar 11 15:57:33 rhianna kernel:  cf_pe_get_direct_status -- Status:0x0,
sr:0x7e
Mar 11 15:57:33 rhianna kernel:  cf_pe_serial_clock -- send 0x2d80 
receive 0x1ffff
Mar 11 15:57:33 rhianna kernel:  cf_pe_serial_clock -- failure NVC, send
0x2d80 receive 0x1ffff
Mar 11 15:57:33 rhianna kernel:  cf_pe_read_sysreg - Reg:0xf failed with
cmd 0x2d80, err = 217
Mar 11 15:57:33 rhianna kernel: BDMioctl cmd:0x40044207
Mar 11 15:57:33 rhianna kernel: debugFlag now 0


Regards,
Justin.




From davidm at snapgear.com  Tue Mar 11 18:18:39 2003
From: davidm at snapgear.com (David McCullough)
Date: Wed, 12 Mar 2003 09:18:39 +1000
Subject: [uClinux-dev] uCdimm with 2.4.x Kernel
In-Reply-To: <200303111330.07688.hans@wilmers.no>
References: <Pine.NEB.4.44.0303101829360.15550-100000@vex.net> <200303111330.07688.hans@wilmers.no>
Message-ID: <20030311231839.GA8696@beast.internal.moreton.com.au>

Jivin Hans Wilmers lays it down ...
> Hi,
> I am using uCdimm 68VZ328, and the 2.4.19 kernel worked for me out of the box 
> with uClinux-dist-20020927 and the precompiled toolchain 
> m68k-elf-tools-20020410 .
> 
> You may need to adapt the scheduler initialisation, if you need a precise 
> system time. This was discussed several times in this list.
> 
> I never used shared libraries, though.
> If you get them working on 68VZ328, please tell the list!

shared libraries should work fine.  They already work on Xcopilot and
the 68VZ328 uses the same compiler options.

The new dist (20030305) will have this turned on by default for most 68k
targets,  a few explicity disable it in their config.arch,  mainly
because I didn't want to break anyones setup ;-).


> I didn't get the time to test the new kernel distribution, but chances are 
> that it works right out of the box too.

I hope so,  let us know if it doesn't,

Cheers,
Davidm

-- 
David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
davidm at snapgear.com  Fx: +61 7 3891 3630  Custom Embedded Solutions + Security


From jwilliams at itee.uq.edu.au  Tue Mar 11 18:57:05 2003
From: jwilliams at itee.uq.edu.au (John Williams)
Date: Wed, 12 Mar 2003 09:57:05 +1000
Subject: [uClinux-dev] init_mem_alloc and PAGE_OFFSET
In-Reply-To: <20030311113235.GA26877@beast.internal.moreton.com.au>
References: <3E6D88DE.6010407@itee.uq.edu.au> <1047374296.1945.8.camel@localhost> <20030311113235.GA26877@beast.internal.moreton.com.au>
Message-ID: <3E6E77D1.4080609@itee.uq.edu.au>

Hi folks,

OK I solved the problem - the kram_start symbol was placed at the wrong 
spot in my link script.  I moved it to the beginning of my text segment 
(which sits at 0xFFE00000, the start of physical ram), relinked the 
kernel, and now I'm up and running again.

In doing this I found the potential for a quite subtle bug.  kram_start 
must not be set to less than ram_start.  This seems obvious now, but in 
my first naive attempt I set kram_start to 0x00000, thinking it would 
prevent the kernel from trying to allocate memory lower than the start 
of physical memory (ram_start).  This caused the 
reserve_bootmem(kram_start, kram_len) calls to munge the memory bitmap. 
  Might be worth adding some sanity checks in the XXX_bootmem functions.

It's very exciting, I got as far as calibrate_delay() (even after the 
first call to sti()) before the board hung again.. back to the 
debugger!!  uClinux on Microblaze is not far away now!

Thanks all for your help.

John



From selvam at sesl.global.sharp.co.jp  Tue Mar 11 20:11:46 2003
From: selvam at sesl.global.sharp.co.jp (Selvam)
Date: Wed, 12 Mar 2003 09:11:46 +0800
Subject: [uClinux-dev] Problem opening console
In-Reply-To: <1047371564.1924.5.camel@tossu>
References: <r01050400-1024-8616DDC0533A11D79D8200039387ACB6@[10.0.1.2]>
 <1047371564.1924.5.camel@tossu>
Message-ID: <03031209114601.07024@localhost>

Hi, I've problem opening the console device  

init() , main.c
 ------------------------------------------------------------
 if (open("/dev/console", O_RDWR, 0) < 0)
 ? ? ? ? printk("Warning: unable to open an initial console.\n");
 -------------------------------------------------------------
When the above line executes I get  junk chars printed on my console. 
No error opening the console. 

Subsequently when the following line executed,
I get continous junk output and certain processes got killed (PID 12, 20
sometimes 30).

-----------------------------------------
 if (execute_command)
 	execve(execute_command,argv_init,envp_init);
 execve("/sbin/init",argv_init,envp_init);
 execve("/etc/init",argv_init,envp_init);
 execve("/bin/init",argv_init,envp_init);
 execve("/bin/sh",argv_init,envp_init);
--------------------------------------------

I've no idea what's really wrong. Appreciate any help from you guys.

thanks
Selvam.



From selvam at sesl.global.sharp.co.jp  Tue Mar 11 20:20:53 2003
From: selvam at sesl.global.sharp.co.jp (Selvam)
Date: Wed, 12 Mar 2003 09:20:53 +0800
Subject: [uClinux-dev] cross compiling (gsmlib)
In-Reply-To: <20030311185901.27965.qmail@web14506.mail.yahoo.com>
References: <20030311185901.27965.qmail@web14506.mail.yahoo.com>
Message-ID: <03031209205302.07024@localhost>

Take a look at my Makefile. I'm compiling uclinux for ARM7TDMI.



On Wednesday 12 March 2003 02:59, Ignacio Uria wrote:
> Hello,
>
> I'm trying to cross-compile gsmlib:
>
>           http://www.pxh.de/fs/gsmlib/
>
> for an ARM7TDMI,which is running uclinux.What kind of
> modifications should I do to get the libraries
> compiled? Has anyone tried it?
>
> I need use the croos compiling for this arquitecture.
>
> I have done it:
>
> export CC=arm-uclinux-gcc
> export CXX=arm-uclinux-c++
> ./configure --host =arm-uclinux --build=i386-linux
>
> We also have made a few modifications in:
>
>  /scripts/config.sub
>
> in order to get the system host type recognized.
>
> The error write in config.log is:
>
> configure:8004: error: cannot run test program while
> cross compiling
>
> Any advice is welcome!!
>
>
> ___________________________________________________
> Yahoo! Messenger - Nueva versi?n GRATIS
> Super Webcam, voz, caritas animadas, y m?s...
> http://messenger.yahoo.es
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org
-------------- next part --------------
VERSION = 2
PATCHLEVEL = 4
SUBLEVEL = 4
EXTRAVERSION = .0pre0

KERNELRELEASE=$(VERSION).$(PATCHLEVEL).$(SUBLEVEL)$(EXTRAVERSION)

# ARCH := armnommu
# ARCH := m68knommu
ARCH := armnommu

CONFIG_SHELL := $(shell if [ -x "$$BASH" ]; then echo $$BASH; \
	  else if [ -x /bin/bash ]; then echo /bin/bash; \
	  else echo sh; fi ; fi)
TOPDIR	:= $(shell /bin/pwd)

HPATH   	= $(TOPDIR)/include
FINDHPATH	= $(HPATH)/asm $(HPATH)/linux $(HPATH)/scsi $(HPATH)/net
LINDIR 		= /home/tulika/linux
ROMDIR		= /home/tulika/usr.20010706/src/apps

HOSTCC  	= unset GCC_EXEC_PREFIX; gcc
HOSTCFLAGS	= -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer

# Selvam: Printing for DEBUG purpose
# test:
#	@echo TOPDIR is $(TOPDIR)
#	@echo FINDPATH is $(FINDPATH)
#	@echo HPATH is $(HPATH)

# CROSS_COMPILE 	= m68k-elf-
# CROSS_COMPILE 	= arm-linux-
CROSS_COMPILE 	= arm-uclinux-

#
# Include the make variables (CC, etc...)
#

AS		= $(CROSS_COMPILE)as
LD		= $(CROSS_COMPILE)ld
CC		= $(CROSS_COMPILE)gcc
CPP		= $(CC) -E
AR		= $(CROSS_COMPILE)ar
NM		= $(CROSS_COMPILE)nm
STRIP		= $(CROSS_COMPILE)strip
OBJCOPY		= $(CROSS_COMPILE)objcopy
OBJDUMP		= $(CROSS_COMPILE)objdump
MAKEFILES	= $(TOPDIR)/.config
GENKSYMS	= /sbin/genksyms
DEPMOD		= /sbin/depmod
MODFLAGS	= -DMODULE
CFLAGS_KERNEL	= -g
PERL		= perl

export	VERSION PATCHLEVEL SUBLEVEL EXTRAVERSION KERNELRELEASE ARCH \
	CONFIG_SHELL TOPDIR HPATH HOSTCC HOSTCFLAGS CROSS_COMPILE AS LD CC \
	CPP AR NM STRIP OBJCOPY OBJDUMP MAKE MAKEFILES GENKSYMS MODFLAGS PERL

.PHONY: dummy

all:	do-it-all

#
# Make "config" the default target if there is no configuration file or
# "depend" the target if there is no top-level dependency information.
#

ifeq (.config,$(wildcard .config))
include .config
ifeq (.depend,$(wildcard .depend))
include .depend
ifndef CONFIG_UCLINUX
	LINUX=vmlinux
else
	LINUX=linux
endif
do-it-all:	Version $(LINUX)
else
CONFIGURATION = depend
do-it-all:	depend
endif
else
CONFIGURATION = config
do-it-all:	config
endif

#
# INSTALL_PATH specifies where to place the updated kernel and system map
# images.  Uncomment if you want to place them anywhere other than root.
#

#export	INSTALL_PATH=/boot

#
# INSTALL_MOD_PATH specifies a prefix to MODLIB for module directory
# relocations required by build roots.  This is not defined in the
# makefile but the arguement can be passed to make if needed.
#

MODLIB	:= $(INSTALL_MOD_PATH)/lib/modules/$(KERNELRELEASE)
export MODLIB

#
# standard CFLAGS
#

CPPFLAGS := -D__KERNEL__ -I$(HPATH)

ifndef CONFIG_FULLDEBUG
CFLAGS := $(CPPFLAGS) -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing
else
CFLAGS := $(CPPFLAGS) -Wall -Wstrict-prototypes -O1 -g -fno-strict-aliasing
endif
AFLAGS := -D__ASSEMBLY__ $(CPPFLAGS)

#
# ROOT_DEV specifies the default root-device when making the image.
# This can be either FLOPPY, CURRENT, /dev/xxxx or empty, in which case
# the default of FLOPPY is used by 'build'.
# This is i386 specific.
#

export ROOT_DEV = CURRENT
#	@echo ********** AFTER ROOT_DEV*************
#
# If you want to preset the SVGA mode, uncomment the next line and
# set SVGA_MODE to whatever number you want.
# Set it to -DSVGA_MODE=NORMAL_VGA if you just want the EGA/VGA mode.
# The number is the same as you would ordinarily press at bootup.
# This is i386 specific.
#

export SVGA_MODE = -DSVGA_MODE=NORMAL_VGA

#
# If you want the RAM disk device, define this to be the size in blocks.
# This is i386 specific.
#

#export RAMDISK = -DRAMDISK=512

CORE_FILES	=kernel/kernel.o fs/fs.o ipc/ipc.o
NETWORKS	=net/network.o
DRIVERS		=drivers/block/block.o \
		 drivers/char/char.o \
		 drivers/misc/misc.o \
		 drivers/net/net.o \
		 drivers/media/media.o
LIBS		=$(TOPDIR)/lib/lib.a
SUBDIRS		=kernel drivers fs net ipc lib

ifndef CONFIG_UCLINUX
	CORE_FILES += mm/mm.o
	SUBDIRS    += mm
else
	CORE_FILES += mmnommu/mmnommu.o
	SUBDIRS    += mmnommu
endif

DRIVERS-n :=
DRIVERS-y :=
DRIVERS-m :=
DRIVERS-  :=

DRIVERS-$(CONFIG_PARPORT) += drivers/parport/driver.o
DRIVERS-$(CONFIG_AGP) += drivers/char/agp/agp.o
DRIVERS-$(CONFIG_DRM) += drivers/char/drm/drm.o
DRIVERS-$(CONFIG_NUBUS) += drivers/nubus/nubus.a
DRIVERS-$(CONFIG_ISDN) += drivers/isdn/isdn.a
DRIVERS-$(CONFIG_NET_FC) += drivers/net/fc/fc.o
DRIVERS-$(CONFIG_APPLETALK) += drivers/net/appletalk/appletalk.o
DRIVERS-$(CONFIG_TR) += drivers/net/tokenring/tr.o
DRIVERS-$(CONFIG_WAN) += drivers/net/wan/wan.o
DRIVERS-$(CONFIG_ARCNET) += drivers/net/arcnet/arcnetdrv.o
DRIVERS-$(CONFIG_ATM) += drivers/atm/atm.o
DRIVERS-$(CONFIG_IDE) += drivers/ide/idedriver.o
DRIVERS-$(CONFIG_SCSI) += drivers/scsi/scsidrv.o
DRIVERS-$(CONFIG_SCSI_AIC7XXX) += drivers/scsi/aic7xxx/aic7xxx_drv.o
DRIVERS-$(CONFIG_IEEE1394) += drivers/ieee1394/ieee1394drv.o

ifneq ($(CONFIG_CD_NO_IDESCSI)$(CONFIG_BLK_DEV_IDECD)$(CONFIG_BLK_DEV_SR)$(CONFIG_PARIDE_PCD),)
DRIVERS-y += drivers/cdrom/driver.o
endif

DRIVERS-$(CONFIG_SSI) += drivers/ssi/ssi.o
DRIVERS-$(CONFIG_SOUND) += drivers/sound/sounddrivers.o
DRIVERS-$(CONFIG_PCI) += drivers/pci/driver.o
DRIVERS-$(CONFIG_MTD) += drivers/mtd/mtdlink.o
DRIVERS-$(CONFIG_PCMCIA) += drivers/pcmcia/pcmcia.o
DRIVERS-$(CONFIG_PCMCIA_NETCARD) += drivers/net/pcmcia/pcmcia_net.o
DRIVERS-$(CONFIG_PCMCIA_CHRDEV) += drivers/char/pcmcia/pcmcia_char.o
DRIVERS-$(CONFIG_DIO) += drivers/dio/dio.a
DRIVERS-$(CONFIG_SBUS) += drivers/sbus/sbus_all.o
DRIVERS-$(CONFIG_ZORRO) += drivers/zorro/driver.o
DRIVERS-$(CONFIG_FC4) += drivers/fc4/fc4.a
DRIVERS-$(CONFIG_ALL_PPC) += drivers/macintosh/macintosh.o
DRIVERS-$(CONFIG_MAC) += drivers/macintosh/macintosh.o
DRIVERS-$(CONFIG_ISAPNP) += drivers/pnp/pnp.o
DRIVERS-$(CONFIG_SGI_IP22) += drivers/sgi/sgi.a
DRIVERS-$(CONFIG_VT) += drivers/video/video.o
DRIVERS-$(CONFIG_PARIDE) += drivers/block/paride/paride.a
DRIVERS-$(CONFIG_HAMRADIO) += drivers/net/hamradio/hamradio.o
DRIVERS-$(CONFIG_TC) += drivers/tc/tc.a
DRIVERS-$(CONFIG_USB) += drivers/usb/usbdrv.o
DRIVERS-$(CONFIG_INPUT) += drivers/input/inputdrv.o
DRIVERS-$(CONFIG_I2O) += drivers/i2o/i2o.o
DRIVERS-$(CONFIG_IRDA) += drivers/net/irda/irda.o
DRIVERS-$(CONFIG_I2C) += drivers/i2c/i2c.o
DRIVERS-$(CONFIG_PHONE) += drivers/telephony/telephony.o
DRIVERS-$(CONFIG_ACPI) += drivers/acpi/acpi.o
DRIVERS-$(CONFIG_MD) += drivers/md/mddev.o

DRIVERS += $(DRIVERS-y)


# files removed with 'make clean'
CLEAN_FILES = \
	kernel/ksyms.lst include/linux/compile.h \
	$(LINUX) System.map \
	.tmp* \
	drivers/char/consolemap_deftbl.c drivers/video/promcon_tbl.c \
	drivers/char/conmakehash \
	drivers/char/drm/*-mod.c \
	drivers/pci/devlist.h drivers/pci/classlist.h drivers/pci/gen-devlist \
	drivers/zorro/devlist.h drivers/zorro/gen-devlist \
	drivers/sound/bin2hex drivers/sound/hex2hex \
	drivers/atm/fore200e_mkfirm drivers/atm/{pca,sba}*{.bin,.bin1,.bin2} \
	net/khttpd/make_times_h \
	net/khttpd/times.h \
	submenu*
# directories removed with 'make clean'
CLEAN_DIRS = \
	modules

# files removed with 'make mrproper'
MRPROPER_FILES = \
	include/linux/autoconf.h include/linux/version.h \
	drivers/net/hamradio/soundmodem/sm_tbl_{afsk1200,afsk2666,fsk9600}.h \
	drivers/net/hamradio/soundmodem/sm_tbl_{hapn4800,psk4800}.h \
	drivers/net/hamradio/soundmodem/sm_tbl_{afsk2400_7,afsk2400_8}.h \
	drivers/net/hamradio/soundmodem/gentbl \
	drivers/sound/*_boot.h drivers/sound/.*.boot \
	drivers/sound/msndinit.c \
	drivers/sound/msndperm.c \
	drivers/sound/pndsperm.c \
	drivers/sound/pndspini.c \
	drivers/atm/fore200e_*_fw.c drivers/atm/.fore200e_*.fw \
	.version .config* config.in config.old \
	scripts/tkparse scripts/kconfig.tk scripts/kconfig.tmp \
	scripts/lxdialog/*.o scripts/lxdialog/lxdialog \
	.menuconfig.log \
	include/asm \
	.hdepend scripts/mkdep scripts/split-include scripts/docproc \
	$(TOPDIR)/include/linux/modversions.h
# directories removed with 'make mrproper'
MRPROPER_DIRS = \
	include/config \
	$(TOPDIR)/include/linux/modules

include arch/$(ARCH)/Makefile

export	CPPFLAGS CFLAGS AFLAGS

export	NETWORKS DRIVERS LIBS HEAD LDFLAGS LINKFLAGS MAKEBOOT ASFLAGS

Version: dummy
	@rm -f include/linux/compile.h

boot: $(LINUX)
	@$(MAKE) CFLAGS="$(CFLAGS) $(CFLAGS_KERNEL)" -C arch/$(ARCH)/boot

$(LINUX): $(CONFIGURATION) init/main.o init/version.o linuxsubdirs
	$(LD) -v $(LINKFLAGS) $(HEAD) init/main.o init/version.o \
		--start-group \
		$(CORE_FILES) \
		$(DRIVERS) \
		$(NETWORKS) \
		$(LIBS) \
		--end-group \
		-o $(LINUX)
	$(NM) $(LINUX) | grep -v '\(compiled\)\|\(\.o$$\)\|\( [aUw] \)\|\(\.\.ng$$\)\|\(LASH[RL]DI\)' | sort > System.map


symlinks:
	rm -f include/asm
	( cd include ; ln -sf asm-$(ARCH) asm)
	@if [ ! -d include/linux/modules ]; then \
		mkdir include/linux/modules; \
	fi

oldconfig: symlinks
	$(CONFIG_SHELL) scripts/Configure -d arch/$(ARCH)/config.in

xconfig: symlinks
	$(MAKE) -C scripts kconfig.tk
	wish -f scripts/kconfig.tk

menuconfig: include/linux/version.h symlinks
	$(MAKE) -C scripts/lxdialog all
	$(CONFIG_SHELL) scripts/Menuconfig arch/$(ARCH)/config.in

config: symlinks
	$(CONFIG_SHELL) scripts/Configure arch/$(ARCH)/config.in

include/config/MARKER: scripts/split-include include/linux/autoconf.h
	scripts/split-include include/linux/autoconf.h include/config
	@ touch include/config/MARKER

linuxsubdirs: $(patsubst %, _dir_%, $(SUBDIRS))

$(patsubst %, _dir_%, $(SUBDIRS)) : dummy include/linux/version.h include/config/MARKER
	$(MAKE) CFLAGS="$(CFLAGS) $(CFLAGS_KERNEL)" -C $(patsubst _dir_%, %, $@)

$(TOPDIR)/include/linux/version.h: include/linux/version.h
$(TOPDIR)/include/linux/compile.h: include/linux/compile.h

newversion:
	@if [ ! -f .version ]; then \
		echo 1 > .version; \
	else \
		expr 0`cat .version` + 1 > .version; \
	fi

include/linux/compile.h: $(CONFIGURATION) include/linux/version.h newversion
	@echo -n \#define UTS_VERSION \"\#`cat .version` > .ver
	@if [ -n "$(CONFIG_SMP)" ] ; then echo -n " SMP" >> .ver; fi
	@if [ -f .name ]; then  echo -n \-`cat .name` >> .ver; fi
	@echo ' '`date`'"' >> .ver
	@echo \#define LINUX_COMPILE_TIME \"`date +%T`\" >> .ver
	@echo \#define LINUX_COMPILE_BY \"`whoami`\" >> .ver
	@echo \#define LINUX_COMPILE_HOST \"`hostname`\" >> .ver
	@if [ -x /bin/dnsdomainname ]; then \
	   echo \#define LINUX_COMPILE_DOMAIN \"`dnsdomainname`\"; \
	 elif [ -x /bin/domainname ]; then \
	   echo \#define LINUX_COMPILE_DOMAIN \"`domainname`\"; \
	 else \
	   echo \#define LINUX_COMPILE_DOMAIN ; \
	 fi >> .ver
	@echo \#define LINUX_COMPILER \"`$(CC) $(CFLAGS) -v 2>&1 | tail -1`\" >> .ver
	@mv -f .ver $@

include/linux/version.h: ./Makefile
	@echo \#define UTS_RELEASE \"$(KERNELRELEASE)\" > .ver
	@echo \#define LINUX_VERSION_CODE `expr $(VERSION) \\* 65536 + $(PATCHLEVEL) \\* 256 + $(SUBLEVEL)` >> .ver
	@echo '#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c))' >>.ver
	@mv -f .ver $@

init/version.o: init/version.c include/linux/compile.h include/config/MARKER
	$(CC) $(CFLAGS) $(CFLAGS_KERNEL) -DUTS_MACHINE='"$(ARCH)"' -c -o init/version.o init/version.c

init/main.o: init/main.c include/config/MARKER
	$(CC) $(CFLAGS) $(CFLAGS_KERNEL) $(PROFILING) -c -o $*.o $<

fs lib mm ipc kernel drivers net: dummy
	$(MAKE) CFLAGS="$(CFLAGS) $(CFLAGS_KERNEL)" $(subst $@, _dir_$@, $@)

TAGS: dummy
	etags `find include/asm-$(ARCH) -name '*.h'`
	find include -type d \( -name "asm-*" -o -name config \) -prune -o -name '*.h' -print | xargs etags -a
	find $(SUBDIRS) init -name '*.c' | xargs etags -a

# Exuberant ctags works better with -I
tags: dummy
	CTAGSF=`ctags --version | grep -i exuberant >/dev/null && echo "-I __initdata,__exitdata,EXPORT_SYMBOL,EXPORT_SYMBOL_NOVERS"`; \
	ctags $$CTAGSF `find include/asm-$(ARCH) -name '*.h'` && \
	find include -type d \( -name "asm-*" -o -name config \) -prune -o -name '*.h' -print | xargs ctags $$CTAGSF -a && \
	find $(SUBDIRS) init -name '*.c' | xargs ctags $$CTAGSF -a

ifdef CONFIG_MODULES
ifdef CONFIG_MODVERSIONS
MODFLAGS += -DMODVERSIONS -include $(HPATH)/linux/modversions.h
endif

.PHONY: modules
modules: $(patsubst %, _mod_%, $(SUBDIRS))

.PHONY: $(patsubst %, _mod_%, $(SUBDIRS))
$(patsubst %, _mod_%, $(SUBDIRS)) : include/linux/version.h include/config/MARKER
	$(MAKE) -C $(patsubst _mod_%, %, $@) CFLAGS="$(CFLAGS) $(MODFLAGS)" MAKING_MODULES=1 modules

.PHONY: modules_install
modules_install: _modinst_ $(patsubst %, _modinst_%, $(SUBDIRS)) _modinst_post

.PHONY: _modinst_
_modinst_:
	@rm -rf $(MODLIB)/kernel
	@rm -f $(MODLIB)/build
	@mkdir -p $(MODLIB)/kernel
	@ln -s $(TOPDIR) $(MODLIB)/build

# If System.map exists, run depmod.  This deliberately does not have a
# dependency on System.map since that would run the dependency tree on
# vmlinux.  This depmod is only for convenience to give the initial
# boot a modules.dep even before / is mounted read-write.  However the
# boot script depmod is the master version.
ifeq "$(strip $(INSTALL_MOD_PATH))" ""
depmod_opts	:=
else
depmod_opts	:= -b $(INSTALL_MOD_PATH) -r
endif
.PHONY: _modinst_post
_modinst_post: _modinst_post_pcmcia
	if [ -r System.map ]; then $(DEPMOD) -ae -F System.map $(depmod_opts) $(KERNELRELEASE); fi

# Backwards compatibilty symlinks for people still using old versions
# of pcmcia-cs with hard coded pathnames on insmod.  Remove
# _modinst_post_pcmcia for kernel 2.4.1.
.PHONY: _modinst_post_pcmcia
_modinst_post_pcmcia:
	cd $(MODLIB); \
	mkdir -p pcmcia; \
	find kernel -path '*/pcmcia/*' -name '*.o' | xargs -i -r ln -sf ../{} pcmcia

.PHONY: $(patsubst %, _modinst_%, $(SUBDIRS))
$(patsubst %, _modinst_%, $(SUBDIRS)) :
	$(MAKE) -C $(patsubst _modinst_%, %, $@) modules_install

# modules disabled....

else
modules modules_install: dummy
	@echo
	@echo "The present kernel configuration has modules disabled."
	@echo "Type 'make config' and enable loadable module support."
	@echo "Then build a kernel with module support enabled."
	@echo
	@exit 1
endif

clean:	archclean
	find . \( -name '*.[oas]' -o -name core -o -name '.*.flags' \) -type f -print \
		| grep -v lxdialog/ | xargs rm -f
	rm -f $(CLEAN_FILES)
	rm -rf $(CLEAN_DIRS)
	$(MAKE) -C Documentation/DocBook clean

mrproper: clean archmrproper
	find . \( -size 0 -o -name .depend \) -type f -print | xargs rm -f
	rm -f $(MRPROPER_FILES)
	rm -rf $(MRPROPER_DIRS)
	$(MAKE) -C Documentation/DocBook mrproper

distclean: mrproper
	rm -f core `find . \( -name '*.orig' -o -name '*.rej' -o -name '*~' \
		-o -name '*.bak' -o -name '#*#' -o -name '.*.orig' \
		-o -name '.*.rej' -o -name '.SUMS' -o -size 0 \) -print` TAGS tags

backup: mrproper
	cd .. && tar cf - linux/ | gzip -9 > backup.gz
	sync

sgmldocs: 
	chmod 755 $(TOPDIR)/scripts/docgen
	chmod 755 $(TOPDIR)/scripts/gen-all-syms
	chmod 755 $(TOPDIR)/scripts/kernel-doc
	$(MAKE) -C $(TOPDIR)/Documentation/DocBook books

psdocs: sgmldocs
	$(MAKE) -C Documentation/DocBook ps

pdfdocs: sgmldocs
	$(MAKE) -C Documentation/DocBook pdf

htmldocs: sgmldocs
	$(MAKE) -C Documentation/DocBook html

sums:
	find . -type f -print | sort | xargs sum > .SUMS


dep-files: scripts/mkdep archdep include/linux/version.h
	scripts/mkdep -- init/*.c > .depend
	scripts/mkdep -- `find $(FINDHPATH) -name SCCS -prune -o -follow -name \*.h ! -name modversions.h -print` > .hdepend
	$(MAKE) $(patsubst %,_sfdep_%,$(SUBDIRS)) _FASTDEP_ALL_SUB_DIRS="$(SUBDIRS)"
ifdef CONFIG_MODVERSIONS
	$(MAKE) update-modverfile
endif

ifdef CONFIG_MODVERSIONS
MODVERFILE := $(TOPDIR)/include/linux/modversions.h
else
MODVERFILE :=
endif
export	MODVERFILE

depend dep: dep-files

checkconfig:
	find * -name '*.[hcS]' -type f -print | sort | xargs $(PERL) -w scripts/checkconfig.pl

checkhelp:
	find * -name [cC]onfig.in -print | sort | xargs $(PERL) -w scripts/checkhelp.pl

checkincludes:
	find * -name '*.[hcS]' -type f -print | sort | xargs $(PERL) -w scripts/checkincludes.pl

ifdef CONFIGURATION
..$(CONFIGURATION):
	@echo
	@echo "You have a bad or nonexistent" .$(CONFIGURATION) ": running 'make" $(CONFIGURATION)"'"
	@echo
	$(MAKE) $(CONFIGURATION)
	@echo
	@echo "Successful. Try re-making (ignore the error that follows)"
	@echo
	exit 1

#dummy: ..$(CONFIGURATION)
dummy:

else

dummy:

endif

include Rules.make

#
# This generates dependencies for the .h files.
#

scripts/mkdep: scripts/mkdep.c
	$(HOSTCC) $(HOSTCFLAGS) -o scripts/mkdep scripts/mkdep.c

scripts/split-include: scripts/split-include.c
	$(HOSTCC) $(HOSTCFLAGS) -o scripts/split-include scripts/split-include.c

From miles at lsi.nec.co.jp  Tue Mar 11 20:41:48 2003
From: miles at lsi.nec.co.jp (Miles Bader)
Date: 12 Mar 2003 10:41:48 +0900
Subject: [uClinux-dev] Re: init_mem_alloc and PAGE_OFFSET
In-Reply-To: <1047374296.1945.8.camel@localhost>
References: <3E6D88DE.6010407@itee.uq.edu.au>
	<1047374296.1945.8.camel@localhost>
Message-ID: <buoisupico3.fsf@mcspd15.ucom.lsi.nec.co.jp>

Bernard Leach <leachbj at bouncycastle.org> writes:
> It should point to the start of your RAM.  The memory initialisation
> should ensure that any required portions of your RAM that are in-use
> before the real memory allocator gets started are reserved.  On the ARM
> system I am using it reserves the entire kernel space during startup and
> then once the kernel has initialised it free's some of that up (the
> _init sections).

This is generally the way it's done, but I don't think there's any
reason that the kernel itself must be within that space, at least on a
uClinux system.  [I've occasionally built systems where I stick the
kernel in a wierd bit of RAM off to the side, with PAGE_OFFSET pointing
to the (later) start of a bigger RAM area.]

-Miles
-- 
A zen-buddhist walked into a pizza shop and
said, "Make me one with everything."


From miles at lsi.nec.co.jp  Tue Mar 11 20:48:18 2003
From: miles at lsi.nec.co.jp (Miles Bader)
Date: 12 Mar 2003 10:48:18 +0900
Subject: [uClinux-dev] Re: init_mem_alloc and PAGE_OFFSET
In-Reply-To: <001601c2e7c0$fd823060$0307a8c0@john.qut.edu.au>
References: <001601c2e7c0$fd823060$0307a8c0@john.qut.edu.au>
Message-ID: <buoel5dicd9.fsf@mcspd15.ucom.lsi.nec.co.jp>

"John Willlams" <jwilliams at itee.uq.edu.au> writes:
> I don't remember precisely (I'm @ home at the moment), but it's one of the
> early init_XX functions called in start_kernel() - init_mem perhaps, or
> something similar.  The code in question actually lives in
> /arch/microblaze/kernel, which I pilfered from Miles Bader's excellent v850
> code.

Actually if you're using something similar to my code, you'll note that
in `init_bootmem_alloc,' it will look for symbols called _kram_start
and _kram_end, and if found, reserve that memory.  Here's the relevant
bits chopped out of the v850 port:

   /* `kram' is only used if the kernel uses part of normal user RAM.  */
   extern char _kram_start __attribute__ ((__weak__));
   extern char _kram_end __attribute__ ((__weak__));
   ...
   static void __init
   init_bootmem_alloc (unsigned long ram_start, unsigned long ram_len)
   {
           ...
           /* The part of the kernel that's in the same managed RAM space
              used for general allocation.  */
           unsigned long kram_start = (unsigned long)&_kram_start;
           unsigned long kram_end = (unsigned long)&_kram_end;
           ...
           if (kram_end > kram_start)
                   /* Reserve the RAM part of the kernel's address space, so it
                      doesn't get allocated.  */
                   reserve_bootmem (kram_start, kram_end - kram_start);
           ...
   }

I always define _kram_start and _kram_end in the linker script. 

[init_bootmem_alloc also reserves some other areas such as the
interrupt vectors (if ram starts at 0), and the bootmem bitmap itself,
and if then if `mach_reserve_bootmem' is defined, calls that as well to
reserve platform-specific areas]

-Miles
-- 
"I distrust a research person who is always obviously busy on a task."
   --Robert Frosch, VP, GM Research


From mikes at tbc.net  Tue Mar 11 20:47:11 2003
From: mikes at tbc.net (Michael F. Sharp)
Date: Tue, 11 Mar 2003 19:47:11 -0600
Subject: [uClinux-dev] uClinux for Palm IIIc - Color Console support? (Please Read)
References: <3E6B902E.7000103@tbc.net> <3E6BE0AB.9060109@tbc.net> <3E6C05D1.2080609@tbc.net>
Message-ID: <3E6E919F.1090907@tbc.net>

Hi all,
HenrySimmons17 and I have a pretty good idea why uClinux won't boot on 
the Palm IIIc. uClinux hangs short of building the screen because it 
needs a color console driver. Before Henry and I waste too many brain 
cells reinventing the wheel, can anybody tell me whether or not color 
has been supported so far with uClinux? If not, we could use some 
support here. There are linux color drivers available at:

http://www.erd.epson.com/vdc/RelSoft/1375/linux/13705linux.zip

 From Epson's site:
http://www.erd.epson.com/vdc/html/contents/S1D13705.htm

If anybody on the list can give us a little assistance, it would be a 
plus. Not only that, uClinux would finally have a little color ;-)

Any help, suggestions, comments, code, etc, etc, welcomed =-)

-Mike



From yangyajun at hisense.cngb.com  Tue Mar 11 20:53:16 2003
From: yangyajun at hisense.cngb.com (=?gb2312?B?0e7Rx778?=)
Date: Wed, 12 Mar 2003 09:53:16 +0800
Subject: [uClinux-dev] A MTD question
Message-ID: <001401c2e83a$27ae3270$5422a8c0@LocalHost>

Hi,all
    I want to use jff2 in my uClinux,so I selected MTD support in kernel.but when I make ,
it returned an error when it goes to "mtd-utils" directory,said that there lost a library file named "libssl".I went to uClinux/lib,It is true that there is no file or directory "libssl".
    What should I do?
   
    Any help? Thank you very much! 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20030312/383526ec/attachment.html>

From davidm at snapgear.com  Tue Mar 11 21:26:03 2003
From: davidm at snapgear.com (David McCullough)
Date: Wed, 12 Mar 2003 12:26:03 +1000
Subject: [uClinux-dev] Problem opening console
In-Reply-To: <03031209114601.07024@localhost>
References: <r01050400-1024-8616DDC0533A11D79D8200039387ACB6@[10.0.1.2]> <1047371564.1924.5.camel@tossu> <03031209114601.07024@localhost>
Message-ID: <20030312022603.GA7674@beast.internal.moreton.com.au>

Jivin Selvam lays it down ...
> Hi, I've problem opening the console device  
> 
> init() , main.c
>  ------------------------------------------------------------
>  if (open("/dev/console", O_RDWR, 0) < 0)
>  ? ? ? ? printk("Warning: unable to open an initial console.\n");
>  -------------------------------------------------------------
> When the above line executes I get  junk chars printed on my console. 
> No error opening the console. 

Check you baud rate,  it may have changed when init opened the console.
9600 is a good try.


> Subsequently when the following line executed,
> I get continous junk output and certain processes got killed (PID 12, 20
> sometimes 30).
> 
> -----------------------------------------
>  if (execute_command)
>  	execve(execute_command,argv_init,envp_init);
>  execve("/sbin/init",argv_init,envp_init);
>  execve("/etc/init",argv_init,envp_init);
>  execve("/bin/init",argv_init,envp_init);
>  execve("/bin/sh",argv_init,envp_init);
> --------------------------------------------
> 
> I've no idea what's really wrong. Appreciate any help from you guys.

If it doesn't look like a baudrate problem (ie., you can read some of the
output) then I suspect your serial driver is unhappy,

Cheers,
Davidm

-- 
David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
davidm at snapgear.com  Fx: +61 7 3891 3630  Custom Embedded Solutions + Security


From k.ji at cn.metrologic.com  Tue Mar 11 22:04:59 2003
From: k.ji at cn.metrologic.com (Karl(Kai) Ji)
Date: Wed, 12 Mar 2003 11:04:59 +0800
Subject: [uClinux-dev] after discovery is done, ircomm stuck in hw_sto
	 pped =1
Message-ID: <01448C8B0D53D411B83B005004A5BB6E7202D3@ER>

Then I just got IrDA module inside VZ working.  Previous patch should not
set PRESEL bit @NIPR2. 

Karl


-----Original Message-----
From: Karl(Kai) Ji [mailto:k.ji at cn.metrologic.com]
Sent: 2003?2?21? 11:46
To: 'uclinux-dev at uclinux.org'
Subject: RE: [uClinux-dev] after discovery is done, ircomm stuck in hw_sto
pped =1

Thanks Markus.

I figured this out.  That is caused by mis-configured dongle.  IRDA stack
works very well.

Regards,
Karl


-----Original Message-----
From: Markus Pietrek [mailto:maillist at fsforth.de]
Sent: 2003?2?20? 16:26
To: uclinux-dev at uclinux.org
Subject: Re: [uClinux-dev] after discovery is done, ircomm stuck in hw_sto
pped =1

Hi

> Thanks.  I will make a try.   Just now, I turn the debug level to zero,
but
> it does not work.
> Some messages say "IrLAP, no activity on link!"

I wouldn't worry about that. Without having analyzed the error message, I
think it is telling us that IrLAP is idle.

Bye,
--
Markus Pietrek
FS Forth-Systeme GmbH
Phone: +49 (7667) 908 145,  FAX +49 (7667) 908 221


_______________________________________________
uClinux-dev mailing list
uClinux-dev at uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev at uclinux.org
_______________________________________________
uClinux-dev mailing list
uClinux-dev at uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev at uclinux.org


From davidm at snapgear.com  Tue Mar 11 22:45:59 2003
From: davidm at snapgear.com (David McCullough)
Date: Wed, 12 Mar 2003 13:45:59 +1000
Subject: [uClinux-dev] uClinux for Palm IIIc - Color Console support? (Please Read)
In-Reply-To: <3E6E919F.1090907@tbc.net>
References: <3E6B902E.7000103@tbc.net> <3E6BE0AB.9060109@tbc.net> <3E6C05D1.2080609@tbc.net> <3E6E919F.1090907@tbc.net>
Message-ID: <20030312034559.GA9954@beast.internal.moreton.com.au>

Jivin Michael F. Sharp lays it down ...
> Hi all,
> HenrySimmons17 and I have a pretty good idea why uClinux won't boot on 
> the Palm IIIc. uClinux hangs short of building the screen because it 
> needs a color console driver. Before Henry and I waste too many brain 

You could prove this by removing all the screen code and just booting on
the serial port.  It will at least save doing all the console work only
to find it's not the problem ;-)

Also it will give you a working base and a lot more encouragement :-)

Cheers,
Davidm

-- 
David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
davidm at snapgear.com  Fx: +61 7 3891 3630  Custom Embedded Solutions + Security


From petero at cvs.com.au  Wed Mar 12 01:47:52 2003
From: petero at cvs.com.au (Peter Ogilvy)
Date: Wed, 12 Mar 2003 17:47:52 +1100
Subject: [uClinux-dev] A MTD question
In-Reply-To: <001401c2e83a$27ae3270$5422a8c0@LocalHost>
References: <001401c2e83a$27ae3270$5422a8c0@LocalHost>
Message-ID: <200303121747.52002.petero@cvs.com.au>

Hi,

I seem to remember reading somewhere that the SSL library is not
included in the dist because of potential problems exporting
encryption code. You have to find it yourself and add it.

Hope this helps,

Peter

??? wrote:
> Hi,all
>     I want to use jff2 in my uClinux,so I selected MTD support in
> kernel.but when I make ,
 it returned an error when it goes to "mtd-utils"
> directory,said that there lost a library file named "libssl".I went to
> uClinux/lib,It is true that there is no file or directory "libssl". What
> should I do?
>    
>     Any help? Thank you very much! 



From uClinux at muellerhydraulik.de  Wed Mar 12 03:01:09 2003
From: uClinux at muellerhydraulik.de (Juergen Mueller)
Date: Wed, 12 Mar 2003 09:01:09 +0100
Subject: AW: [uClinux-dev] new bootloader
In-Reply-To: <r01050400-1024-09C5BAB953DD11D7A99600039387ACB6@[10.0.1.2]>
Message-ID: <000b01c2e86d$91264980$7700a8c0@gandalf>

Hi Richard,

I'm using colilo on a MCF5272 system. Are there any advatages in U-Boot?
In that case I would be very interested in testing it on my system.

Juergen

-----Urspr?ngliche Nachricht-----
Von: uclinux-dev-admin at uclinux.org [mailto:uclinux-dev-admin at uclinux.org] Im
Auftrag von Richard Klingler
Gesendet: Dienstag, 11. M?rz 2003 17:18
An: uclinux-dev at uclinux.org
Betreff: [uClinux-dev] new bootloader

Evening (o;

Finally got some spare time to test the u-boot-0.2.0
Coldfire port (o;

Looks promising...


U-Boot 0.2.0 (Mar 11 2003 - 17:55:00)
Viola Systems Arctic Board
Adapted by richard at uclinux.net

Calling init code at: 003e4562...
MOTOROLA Coldfire MCF5272
Calling init code at: 003eb55c...
Viola Systems Oy Arctic Board
         http://www.violasystems.com/
Calling init code at: 003e47ba...
DRAM:   4 MB
Initialized init_fnc_ptr...
length = 00015650...
FLASH:  4 MB
*** Warning - bad CRC, using default environment

In:    serial
Out:   serial
Err:   serial
Arctic> version

U-Boot 0.2.0 (Mar 11 2003 - 17:55:00)
Viola Systems Arctic Board
Adapted by richard at uclinux.net
Arctic> 


Rick


Richard Klingler             mail: richard.klingler at violasystems.com
Viola Systems Ltd.           http://www.violasystems.com/
Lemmink?isenkatu 32          phon: +358 (0)201 226 226
20520 Turku, Finland         mobile: +358 (0)40 748 4711
_______________________________________________
uClinux-dev mailing list
uClinux-dev at uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev at uclinux.org




From richard.klingler at violasystems.com  Wed Mar 12 03:10:46 2003
From: richard.klingler at violasystems.com (Richard Klingler)
Date: Wed, 12 Mar 2003 10:10:46 +0200
Subject: AW: [uClinux-dev] new bootloader
In-Reply-To: <000b01c2e86d$91264980$7700a8c0@gandalf>
Message-ID: <r01050400-1024-2136CA8F546211D7AEEB00039387ACB6@[10.0.1.2]>

> Hi Richard,
> 
> I'm using colilo on a MCF5272 system. Are there any advatages in U-Boot?
> In that case I would be very interested in testing it on my system.
> 

Never used CoLiLo (and never will probably ;o) in...
So I can't actually compare (o;


Rick


Richard Klingler             mail: richard.klingler at violasystems.com
Viola Systems Ltd.           http://www.violasystems.com/
Lemmink?isenkatu 32          phon: +358 (0)201 226 226
20520 Turku, Finland         mobile: +358 (0)40 748 4711


From maillist at fsforth.de  Wed Mar 12 03:40:10 2003
From: maillist at fsforth.de (Markus Pietrek)
Date: Wed, 12 Mar 2003 09:40:10 +0100
Subject: [uClinux-dev] driver initialization sequence control
In-Reply-To: <BA935DD4.8FC4%tchen@on-go.com>
References: <BA935DD4.8FC4%tchen@on-go.com>
Message-ID: <200303120940.10451.maillist@fsforth.de>

Hi Thomas,

> is there any way to control the initialization of
> the drivers... ie... in each driver, the init is defined
> and stored in the table, but i would like to find out
> anyway to control the sequence of the initialization
> calls???

If I remember correctly a jumptable of the _init functions is placed in an ELF 
section. Perhaps by modifying this table afterwards or when linking you are 
able to preset an order?

Bye,

-- 
Markus Pietrek
FS Forth-Systeme GmbH
Phone: +49 (7667) 908 145,  FAX +49 (7667) 908 221




From selvam at sesl.global.sharp.co.jp  Wed Mar 12 03:55:59 2003
From: selvam at sesl.global.sharp.co.jp (Selvam)
Date: Wed, 12 Mar 2003 16:55:59 +0800
Subject: [uClinux-dev] Problem opening console
In-Reply-To: <20030312022603.GA7674@beast.internal.moreton.com.au>
References: <r01050400-1024-8616DDC0533A11D79D8200039387ACB6@[10.0.1.2]>
 <03031209114601.07024@localhost>
 <20030312022603.GA7674@beast.internal.moreton.com.au>
Message-ID: <03031216555901.24953@localhost>

David, I just checked the console_init section seems ok. 
I'm actually getting the console output correct until the
init() opens /dev/console.  You can take a look at  the 
output.

thanks
Selvam.

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

Welcome to the LH79531 Linux port.
Linux version 2.4.4.0pre0 (root at localhost) (gcc version 2.96 20000519 
(experimental)) #573 Wed Mar 12 16:03:01 SGT 2003
Processor: ARM/SHARP ARM 7 revision 0
Architecture: LH7953X
On node 0 totalpages: 5120
zone(0): 5120 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: root=/dev/rom0
Console: colour dummy device 80x30
Calibrating delay loop... 9.72 BogoMIPS
Memory: 20MB = 20MB total
Memory: 20120KB available (833K code, 1049969K data, 44K init)
Dentry-cache hash table entries: 4096 (order: 3, 32768 bytes)
Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes)
Page-cache hash table entries: 8192 (order: 3, 32768 bytes)
Inode-cache hash table entries: 2048 (order: 2, 16384 bytes)
VFS: Diskquotas version dquot_6.4.0 initialized
POSIX conformance testing by UNIFIX
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
 Configuring PIO registers..
Console: switching to colour frame buffer device 30x40
codec_main_init:Entered
hardware_patch:Entered
hardware_patch:LEAVING FUNCTION
peripherals_power_on:Entered
peripherals_power_on:LEAVING FUNCTION
FnGenerateDspPwm0: config PWM0 for 12.27MHZ clock base on 50MHZ System Clock
FnGenerateDspPwm0: LEAVING FUNCTION
Entered InitPIOCodec: PIO settings for Codec device
InitPIOCodec: LEAVIN FUNCTION
Entered InitCodec: Codec initialization routine
Entered InitCodecDMA: DMA for CODEC
Registration of the codec device driver Successful
Request irq successful for Codec device
block: queued sectors max/low 13266kB/4422kB, 64 slots per queue
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
Starting kswapd v1.8
Blkmem copyright 1998,1999 D. Jeff Dionne
Blkmem copyright 1998 Kenneth Albanowski
Blkmem 1 disk images:
0: 1800000-1A7FFFF [VIRTUAL 1800000-1A7FFFF] (RO)
loop: loaded (max 8 devices)
ttyS00 at 0x0000 (irq = 9)
ttyS01 at 0x0000 (irq = 10)
ttyS02 at 0x0000 (irq = 11)
ADS7846 generic module installed
Configuring TOUCH PANEL REG
ads7846 touch screen driver initialized
PPP generic driver version 2.4.1
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)
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
wrong magic
VFS: Mounted root (romfs filesystem) readonly.
$^A^A^R
^A^A^R
^A^A  @@^@@H^@ ^@ ^@ $^@ 
$$^@^@^@^@^@^@^@^@^@^@P^@^@^@^@@^B^@^H^@^@^@?^@^E^@^@^@^A$^@
@^@ ^@^A^HB^@.^B^@a@^@^@.^@^@ .^@^L  ^F^@^@^R
^P      ^@^@^@ Mountingb^A^@^A^@^@^B.^@^EH^E^@^@^@^@`^@ 
^@^B^@..^PA^B"..^B@^A^B^B^@^P^@@^@^@    Q^@ proc on /proc
^@T^@^@^P^@^H!^B^A ^E@^@^@$^@^B" ^A^@^@^B^@B^@^@^@^@Expand.^@^@.@^P^@^@ (^@^B 
^A^E^@^H at B^A@@P^@^L?.^@. ^@^@^P^@^@.
^PP"^T^B^@^@^@^H  ^BA^@^H^@^B^B@^@!@^@^@^@ ^B^@ ^@^@^B^@^@A^@^B 
^@^@^@^@B^@^H^B^P^B
A^H@^H^@^R
^@^A?^P^@^@^@^@^P$^@^P^@^@^@^AD^A ^@^@ (^@
^@^@^@" ^@@^B .^R
^B . at .^@^@^@^A ^@( ^@^@^@.^B^@^H!^@.^H.^P5^@^@^@^@.@^@^@
! .@^@^Bb^@ .^@^@^T^@^P ^@^@^A^A ^@^E 
^@^@^@.^@.^F.^A^P^@B^@@H^@^@^@^B^@^@^@^@^@.^H  ^P@$ 
.^@^@^@^@^B^E^@^@^@(^B@^@^L^B^@^@^@^@?^@^@^@^H^@^H^@^A^@^P^@^A^H^@^@^E.^@.^@@^@$@^@^@...^A^@^@bH^@^@^A^@A^@^@^R
A^@^@^A.^B^A^@.^@^@.^@^@^@.^K^P^A^@I^P^F.^@*.^@.^B@? !^@^@^H^@^@^P .^@^P^@@@ 
. $

^@@4^@.^H^@*^H@^A^@^B.^@^@^A^P^B.`^@^A^H^@^H@^@^B^@@^P ^@^@^@^@^B^P 
.^@@..^@^@^A^@ @%^@^H^@^F^@^@^AP^@^@^@^B^@@^@@^P^@^@.^@ 
^@@^@@H"^P%^@@^@@.@^@^@^@^@.^@^@^@(^H^P^@A^TA^@Q^@^@.(.^@.^@^@^@P^@!^@^@^@P^@P^P^@ 
^@^@0.!h^@
 .^@^@^@^@0 ^H^@^@4^@^P^@^B^R
 .^@^@^@^@0 ^H^@^@4^@^P^@^B^B^@.^@^@^@
^@^PB^@^@.^"@^P ^@^@^@^H^@^A^P^@(^@^@^@ ^B^@^@^B^T^@^@^@^@^L 
^H^@^@^BD^E^@^P^B.^@4^@^P^@@^@A^@.A.^H^B^@.^@^T^@Q 
^@^H^B^@^B^P^B^@^B^@@^@^@^@^@^@^@^E^@.J^@^@^B`*^H^@^@^@^@..^@^B`^E^T^@^A^B$^@^@^P^@^@.^A^@D@^@^@ 
^@^@P^@^@^@^@^H^@^@^@^@^@^H^@^T^@^H^@(^@^@R.^P^P^@^@^P^@^@^@4?^@.^@^@^P^@^T^@^@P^P^H^@^@4!%^@^@^@^@)^@^@^B^H^A^@A^@^@^@^@^@^@^@ 
^@.^@@^@@@".@^H^@^H.@^T "      ^@P^@^@^P^@$^@^@^@^@(^@.T^H.^@^P^R
^@^P^@$^@^@^@^@(^@.T^H.^@^PQ^F^@^@.^@^@^@^@^@.^X^A.^@^P^@^P^A^@^T^@^L.^F^AD^@@. 
^@`^@H^@@^@^@^@^H^B^F^@@^@^@^@^B.^@  ^@"^@^@..0^@D?. .^F^@.^H(
^@A@^@^@@^P^B^@^BT^B.^H^@?^H.^@^@^F^H^^@.^@^@^@^@^@@@^@^@^P^@^@^A^@^E^L^@^@^@@.^B^@^@.^P^@^H^F.^@^A^@^@ 
^BB^@@@^@^@^@^@.. at 0^T^@^@@ ..^P.  
^@^@^@^L?^@^@^@^H^@^H^@B^T.^@^T^L^@^@^@^@^@@.^@. ^@^@^@^@
@^@@^@^@.^@^@^A^@ ^P^@P^H. `^L^@@.^@^@^@@.^@^A^B^@@D^@^@^@^B^R
@^@^@.^@^@^A^@ ^P^@P^H. `^L^@@.^@^@^@@.^@^A^B^@@D^@^@^@^B ^H    ^PH^@@^@^H^B 
^HX^@^@^@^@@F@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^P.^@^@@^@H^AH ^@^HB^@J^@  ^B^@^@^@^B^@^@^H^B^A^@^T!^@
^@
^@H^H^@@^@.^@^@^B^@.^@.^B^@^@^H^@^H&^@A^A^@^@^@^@^@^A^T^@^@^T^@^T^B^P 
^@^@^P^H^@^@^BP4^@^@^A^@^A^B      
^@.^@^@^A^@^P^B^@^@^@^T^@^H^@^@^@^@.^B^@."^P@^@^F(^@^@.^@Q^T^@0^@^L ^H 
?^@^@^@ ^@^@^@. ^@^H^@.^@^@^
---------------------------------------------------------------


On Wednesday 12 March 2003 10:26, David McCullough wrote:
> Jivin Selvam lays it down ...
>
> > Hi, I've problem opening the console device
> >
> > init() , main.c
> >  ------------------------------------------------------------
> >  if (open("/dev/console", O_RDWR, 0) < 0)
> >  ? ? ? ? printk("Warning: unable to open an initial console.\n");
> >  -------------------------------------------------------------
> > When the above line executes I get  junk chars printed on my console.
> > No error opening the console.
>
> Check you baud rate,  it may have changed when init opened the console.
> 9600 is a good try.
>
> > Subsequently when the following line executed,
> > I get continous junk output and certain processes got killed (PID 12, 20
> > sometimes 30).
> >
> > -----------------------------------------
> >  if (execute_command)
> >  	execve(execute_command,argv_init,envp_init);
> >  execve("/sbin/init",argv_init,envp_init);
> >  execve("/etc/init",argv_init,envp_init);
> >  execve("/bin/init",argv_init,envp_init);
> >  execve("/bin/sh",argv_init,envp_init);
> > --------------------------------------------
> >
> > I've no idea what's really wrong. Appreciate any help from you guys.
>
> If it doesn't look like a baudrate problem (ie., you can read some of the
> output) then I suspect your serial driver is unhappy,
>
> Cheers,
> Davidm



From richard.klingler at violasystems.com  Wed Mar 12 04:24:15 2003
From: richard.klingler at violasystems.com (Richard Klingler)
Date: Wed, 12 Mar 2003 11:24:15 +0200
Subject: [uClinux-dev] Problem opening console
In-Reply-To: <03031216555901.24953@localhost>
Message-ID: <r01050400-1024-64D2897D546C11D7AEEB00039387ACB6@[10.0.1.2]>

> David, I just checked the console_init section seems ok. 
> I'm actually getting the console output correct until the
> init() opens /dev/console.  You can take a look at  the 
> output.
> 

There is no console before init opens it...

What you see during booting is just plain direct calls to
the serial driver.


Rick


Richard Klingler             mail: richard.klingler at violasystems.com
Viola Systems Ltd.           http://www.violasystems.com/
Lemmink?isenkatu 32          phon: +358 (0)201 226 226
20520 Turku, Finland         mobile: +358 (0)40 748 4711


From rgegusch at mf.tu-berlin.de  Wed Mar 12 04:53:30 2003
From: rgegusch at mf.tu-berlin.de (Rene Gegusch)
Date: Wed, 12 Mar 2003 10:53:30 +0100
Subject: [uClinux-dev] FTP Server Compiling Problems (Arcturus 5272)
In-Reply-To: <005901c2e725$9b596b10$7a8844c0@19268136122>
References: <BC03D160581F7A4E92710FC238282411167809@ici-mail.intellicom.se> <200303101417.10843.rgegusch@mf.tu-berlin.de> <005901c2e725$9b596b10$7a8844c0@19268136122>
Message-ID: <200303121053.30599.rgegusch@mf.tu-berlin.de>

Thank you first, but I think it is already added.
I am using the Makefiles included with the ftpd in the newest distribution


Am Montag, 10. M?rz 2003 17:53 schrieb Napoletano Daniel:
> Try to add the -lcryp or $(LIBCRYPT) directive to your Makefile.
> Like $(CC) $(LDFLAGS) -o XXXX  $(LIBCRYPT) $(LDLIBS)
> Regards Daniel
>
> ----- Original Message -----
> From: "Rene Gegusch" <rgegusch at mf.tu-berlin.de>
> To: <uclinux-dev at uclinux.org>
> Sent: Monday, March 10, 2003 2:17 PM
> Subject: [uClinux-dev] FTP Server Compiling Problems (Arcturus 5272)
>
> > I tried it on...
> >
> > because of my troubles with compiling the new distribution, I decided to
>
> add
>
> > the FTPD directory to my "old" distribution and add there the new
> > application.
> > Should work, don't? It doesn't work better at all.
> >
> > Here the error message:
> > In file included from auth.c:10:
> > crypt.h:33: conflicting types for `crypt'
> > /home/rgegusch/development/uClinux-coldfire/lib/libc/include/unistd.h:26:
> > previous declaration of `crypt'
> > In file included from auth.c:12:
>
> /usr/local/lib/gcc-lib/m68k-elf/2.95.3/../../../../m68k-elf/sys-include/sha
>d
>
> ow.h:58:
> > parse error before `__THROW'
> > [...]
> >  parse error before `__THROW'
>
> /usr/local/lib/gcc-lib/m68k-elf/2.95.3/../../../../m68k-elf/sys-include/sha
>d
>
> ow.h:101:
> > warning: data definition has no type or storage class
> > auth.c: In function `auth_user':
> > auth.c:105: warning: assignment makes pointer from integer without a cast
> > auth.c: In function `auth_pass':
> > auth.c:156: warning: passing arg 1 of `crypt' discards qualifiers from
>
> pointer
>
> > target type
> > auth.c: In function `sgetcred':
> > auth.c:189: warning: assignment makes pointer from integer without a cast
> >
> > Does anyone have any help for me or a "stand-alone" Makefile?
> >
> > Thank you
> >
> > _______________________________________________
> > uClinux-dev mailing list
> > uClinux-dev at uclinux.org
> > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> > This message was resent by uclinux-dev at uclinux.org
>
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org




From s.smejkal at centerfunk.at  Wed Mar 12 05:05:55 2003
From: s.smejkal at centerfunk.at (Sascha Smejkal)
Date: Wed, 12 Mar 2003 11:05:55 +0100
Subject: [uClinux-dev] bdm driver installation failing
References: <1047363594.1785.11.camel@rhianna.tmq.com.au>
Message-ID: <3E6F0683.9090806@centerfunk.at>

Hi,

I had also trouble using BDM but can't remember the error message.
The reason was, that the parallel port of the mainboard produced traffic on 
the parallel port no matter what I configured in the bios. Used a PCI parallel 
port card and it worked for me.

Bye Sascha Smejkal

Justin Clacherty schrieb:
> Hi,
> 
> I'm trying to set up debugging through the bdm in gdb.  I've installed
> the bdm driver but when I run chk /dev/bdmcf0 the driver seems to be
> failing to connect to the target.  I turned on debugging and it looks
> like it is failing when it tries to read a register on the target. 
> Below is the command I am using and its output, along with the relevant
> output in /var/log/messages.  I'm using the P&E Micro wiggler that came
> with our Motorola M5272C3 development board.  Does anyone know what I
> might be doing wrong?
> 
> The commands I'm using with the output...
> 
> [justin at rhianna test]$ ./chk -d 4 /dev/bdmcf0
> Driver Ver : 2.a
> Processor  : Coldfire
> Interface  : P&E Coldfire
> Reading CSR failed: Invalid target command
> [justin at rhianna test]$
> 
> /var/log/messages
> 
> Mar 11 15:57:32 rhianna kernel:  cf_pe_read_sysreg - Reg:0xf failed with
> cmd 0x2d80, err = 217
> Mar 11 15:57:32 rhianna kernel: debugFlag now 4
> Mar 11 15:57:32 rhianna kernel: BDMioctl cmd:0x8004421e
> Mar 11 15:57:32 rhianna kernel: BDMioctl cmd:0x8004421f
> Mar 11 15:57:32 rhianna kernel: BDMioctl cmd:0x80044220
> Mar 11 15:57:32 rhianna kernel: BDMioctl cmd:0x4201
> Mar 11 15:57:32 rhianna kernel:  cf_pe_reset_chip
> Mar 11 15:57:33 rhianna kernel: BDMioctl cmd:0xc0084215
> Mar 11 15:57:33 rhianna kernel:  cf_pe_get_direct_status -- Status:0x0,
> sr:0x7e
> Mar 11 15:57:33 rhianna kernel:  cf_pe_serial_clock -- send 0x2d80 
> receive 0x1ffff
> Mar 11 15:57:33 rhianna kernel:  cf_pe_serial_clock -- failure NVC, send
> 0x2d80 receive 0x1ffff
> Mar 11 15:57:33 rhianna kernel:  cf_pe_read_sysreg - Reg:0xf failed with
> cmd 0x2d80, err = 217
> Mar 11 15:57:33 rhianna kernel: BDMioctl cmd:0x40044207
> Mar 11 15:57:33 rhianna kernel: debugFlag now 0
> 
> 
> Regards,
> Justin.
> 
> 
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org




From maillist at fsforth.de  Wed Mar 12 05:50:02 2003
From: maillist at fsforth.de (Markus Pietrek)
Date: Wed, 12 Mar 2003 11:50:02 +0100
Subject: [uClinux-dev] "wrong zone alignment" warning and &_end_kernel in 2.4.20
Message-ID: <200303121150.02036.maillist@fsforth.de>

Hi folks,

when booting uClinux-2.4.20 on a NetARM+50 or NS7520 (armnommu) I receive the 
kernel warning "BUG: wrong zone alignment, it will crash". The code for this 
warning is in mmnommu/page_alloc.c

void __init free_area_init_core(int nid, pg_data_t *pgdat, struct page **gmap,
	unsigned long *zones_size, unsigned long zone_start_paddr, 
	unsigned long *zholes_size, struct page *lmem_map)
...
		if ((zone_start_paddr >> PAGE_SHIFT) & (zone_required_alignment-1))
			printk("BUG: wrong zone alignment, it will crash %x %x %x %x\n", 
zone_start_paddr, PAGE_SHIFT, zone_required_alignment, MAX_ORDER );
...

The zone 1 is starting directly after the kernel, which is located at 0x0.

zone_start_paddr == PAGE_OFFSET == &_end_kernel == 1376256
PAGE_SHIFT == 12
MAX_ORDER == 10
zone_required_alignment == 0x1ff

I don't understand the reason of this function. But to get rid of this message 
I would have to align _end_kernel at a 2MB boundary, wasting 600kb memory. 
Are there other, better ways?

Best regards,

-- 
Markus Pietrek
FS Forth-Systeme GmbH
Phone: +49 (7667) 908 145,  FAX +49 (7667) 908 221




From leachbj at bouncycastle.org  Wed Mar 12 05:59:24 2003
From: leachbj at bouncycastle.org (Bernard Leach)
Date: 12 Mar 2003 11:59:24 +0100
Subject: [uClinux-dev] "wrong zone alignment" warning and &_end_kernel
	in 2.4.20
In-Reply-To: <200303121150.02036.maillist@fsforth.de>
References: <200303121150.02036.maillist@fsforth.de>
Message-ID: <1047466764.1941.32.camel@localhost>

Hi Marcus,

I had the same problem when PAGE_OFFSET was (incorrectly :) set to
_end_kernel.  It should really be set to the start of your ram.  The
kernel automatically reserves the kernel address space during startup.

If you have other "special" regions of memory to reserve take a look at
reserve_node_zero in arch/armnommu/mm/init.c.  I use that function to
reserve the first 8k for remapping to 0x0 for the interrupt vectors &
handlers.

cheers,
bern.

On Wed, 2003-03-12 at 11:50, Markus Pietrek wrote:
> Hi folks,
> 
> when booting uClinux-2.4.20 on a NetARM+50 or NS7520 (armnommu) I receive the 
> kernel warning "BUG: wrong zone alignment, it will crash". The code for this 
> warning is in mmnommu/page_alloc.c
> 
> void __init free_area_init_core(int nid, pg_data_t *pgdat, struct page **gmap,
> 	unsigned long *zones_size, unsigned long zone_start_paddr, 
> 	unsigned long *zholes_size, struct page *lmem_map)
> ...
> 		if ((zone_start_paddr >> PAGE_SHIFT) & (zone_required_alignment-1))
> 			printk("BUG: wrong zone alignment, it will crash %x %x %x %x\n", 
> zone_start_paddr, PAGE_SHIFT, zone_required_alignment, MAX_ORDER );
> ...
> 
> The zone 1 is starting directly after the kernel, which is located at 0x0.
> 
> zone_start_paddr == PAGE_OFFSET == &_end_kernel == 1376256
> PAGE_SHIFT == 12
> MAX_ORDER == 10
> zone_required_alignment == 0x1ff
> 
> I don't understand the reason of this function. But to get rid of this message 
> I would have to align _end_kernel at a 2MB boundary, wasting 600kb memory. 
> Are there other, better ways?
> 
> Best regards,



From rgegusch at mf.tu-berlin.de  Wed Mar 12 06:14:24 2003
From: rgegusch at mf.tu-berlin.de (Rene Gegusch)
Date: Wed, 12 Mar 2003 12:14:24 +0100
Subject: [uClinux-dev] FTP Server on the 5272 board
Message-ID: <200303121214.24152.rgegusch@mf.tu-berlin.de>

once again without the attachment
OK, I followed your instructions and added the uC5272 directory, furthermore
 I added several uC5272 informations to the arch/m68knommu/config.in and
 Boards.mk files. Before I tried to replace them with the ones from the
 Arcturus Distribution. Finally I got the same error and this made me sad.
 Added the arch/m68knommu/config.in and Boards.mk files as an attachement.
 Maybe I misunderstood there somehting.
The .old files are the origin Arcturus ones.
I also attached the uC5272 files for your CVS directory.

Still thankful for further help
Rene

Am Montag, 10. M?rz 2003 15:42 schrieb Greg Ungerer:
> Hi Rene,
>
> Rene Gegusch wrote:
> > If I understand you, there are files missing to compile the project
> > correctly. I do have the CD and I already checked for the mentioned
> > crt0_ram.S file, which is there and the same as in my Arcturus Version.
> > So, what shall I looking for?
>
> If your target is the uC5272 (which I assume from your error output)
> then you need the files under:
>
>    linux-2.4.x/arch/m68knommu/platform/5272/uC5272
>
> which are not at cvs.uclinux.org and so not in uClinux-dist.
>
> You will also need to update the arch/m68knommu/config.in and
> Boards.mk files, which also do not contain options for uC5272.
>
> Regards
> Greg
>
> > Am Montag, 10. M?rz 2003 13:41 schrieb Greg Ungerer:
> >>Hi Rene,
> >>
> >>Rene Gegusch wrote:
> >>>You were right. My downloaded file was corrupted. Thank you to KDE,
> >>> which did not mentioned that!
> >>>Anyway, i just started to try to compile the new distribution for my
> >>>Arcturus uCdimm 5272 system, but compiler very fast ended compilation
> >>>with an error.< <make dep> works fine, but on the next step <make> not
> >>>so.
> >>>It stops with an missing rule error...
> >>>make[2]: changing to directory
> >>>?/home/rgegusch/test/uClinux-dist/linux-2.4.x/arch/m68knommu/platform/52
> >>>7 2? make[2]: *** no rule available for target ?/crt0_ram.S?,
> >>>  need of ?/crt0_ram.o?, to create.  End.
> >>
> >>Unfortunately the guys at Arcturus have not commited their uC5272
> >>linux-2.4.x kernel support to the CVS yet. So the low level files
> >>(for example the above mentioned crt0_ram.S) are not there. Which
> >>means they are not in the uClinux-dist either.
> >>
> >>If you have a source CD from Arcturus for the uC5272 then you
> >>would have those files. You could just pull them out and merge
> >>them. Will probably be a little bit of mucking around to get it
> >>all together, compiling and working.
> >>
> >>Regards
> >>Greg
> >>
> >>>(Compiler messages translated to English by myself)
> >>>
> >>>does anyone knows, what there is wrong?
> >>>I am not one of those kernel hacking freaks, originally had the plan to
> >>>compile the ftpd server, shipped with this distribution, but failed to
> >>>compile it because of missing PATH definitions.
> >>>
> >>>However, I need help!
> >>>
> >>>Am Freitag, 7. M?rz 2003 14:44 schrieb Greg Ungerer:
> >>>>Hi Rene,
> >>>>
> >>>>Rene Gegusch wrote:
> >>>>>Thank you for the information.
> >>>>>It confusses me, that the download of the new distribution does not
> >>>>> have it as you told us.
> >>>>>My distribution file has a size of about 105mb, seems to be OK,
> >>>>> doesn't it?
> >>>>
> >>>>The latest distribution definately contains a uClinux-dist/user/ftpd
> >>>>directory. If you don't have one then either you don't have the latest
> >>>>distribution or it is corrupted.
> >>>>
> >>>>Regards
> >>>>Greg
> >>
> >>------------------------------------------------------------------------
> >>Greg Ungerer  --  Chief Software Wizard        EMAIL:  gerg at snapgear.com
> >>SnapGear Pty Ltd                               PHONE:    +61 7 3435 2888
> >>825 Stanley St,                                  FAX:    +61 7 3891 3630
> >>Woolloongabba, QLD, 4102, Australia              WEB:   www.SnapGear.com
> >>
> >>_______________________________________________
> >>uClinux-dev mailing list
> >>uClinux-dev at uclinux.org
> >>http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> >>This message was resent by uclinux-dev at uclinux.org
> >
> > _______________________________________________
> > uClinux-dev mailing list
> > uClinux-dev at uclinux.org
> > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> > This message was resent by uclinux-dev at uclinux.org

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





From heiko.degenhardt at sentec-elektronik.de  Wed Mar 12 06:10:33 2003
From: heiko.degenhardt at sentec-elektronik.de (Heiko Degenhardt)
Date: Wed, 12 Mar 2003 12:10:33 +0100
Subject: [uClinux-dev] bdm driver installation failing
In-Reply-To: <1047363594.1785.11.camel@rhianna.tmq.com.au>; from justin@tmq.com.au on Tue, Mar 11, 2003 at 04:19:49PM +1000
References: <1047363594.1785.11.camel@rhianna.tmq.com.au>
Message-ID: <20030312121033.A11315@www2.sentec-elektronik.de>

Hi Justin, 

* On Tue, Mar 11, 2003 at 04:19:49PM +1000, Justin Clacherty wrote:
> I'm trying to set up debugging through the bdm in gdb.  I've installed
> the bdm driver but when I run chk /dev/bdmcf0 the driver seems to be
> failing to connect to the target.

I've never seen that kind of error.
May be some things you could check are:
- Check if you bdm cable is working fine, for instance with the
  CFFlasher utility of Motorola (that is for windows).
- See if the parallel port in your bios is set to normal mode (or
  EPP should work, I think)
- See if no other process is using the parallel port, too (I don't
  know if that really matters, but in my case it seemde to help
  to unload all lp stuff)
- Check if your kernel is using APIC or such things. I really had
  problems with APIC enabled (not with the parallel port, but with
  other interrupt driven cards, eg. RTL8139).
- Check that "PnP OS" is disabled in your bios.
- Do you see any messages while modprobe'ing the bdm driver?

I'm using Debian Woody with kernel 2.4.20 currently.

I don't think that this hints will really help you, but just to be
shure...

Rgds.
Heiko.



From eauth at softsys.co.at  Wed Mar 12 06:36:43 2003
From: eauth at softsys.co.at (Erwin Authried)
Date: 12 Mar 2003 12:36:43 +0100
Subject: [uClinux-dev] driver initialization sequence control
In-Reply-To: <BA935DD4.8FC4%tchen@on-go.com>
References: <BA935DD4.8FC4%tchen@on-go.com>
Message-ID: <1047469004.6247.15.camel@justakiss>

Hi Thomas,

you can do that by making sure that your makefiles link the objects in
the right order. This is ugly, but the whole kernel depends on these
subtle issues with link order. 

Regards,
Erwin

Am Die, 2003-03-11 um 18.33 schrieb Thomas Chen:
> is there any way to control the initialization of
> the drivers... ie... in each driver, the init is defined
> and stored in the table, but i would like to find out
> anyway to control the sequence of the initialization
> calls???
> 
> thanks
> 
> 
> tom
> 




From vadim at 7chips.com  Wed Mar 12 07:11:41 2003
From: vadim at 7chips.com (Vadim Lebedev)
Date: Wed, 12 Mar 2003 13:11:41 +0100
Subject: [uClinux-dev] for JEENI users
Message-ID: <200303121211.h2CCBcJ10197@goldunix1001.propagation.net>

Hello

When debugging remote arm targets using  devices such as JEENI  from epitools 
the semihosting function slows execution by the target of SWI instruction 
nearly 100-fold.  This is especially annoying when you try to debug  linux 
kernel on the target as it uses SWI to implement system calls.  
The attached patch adds a set rdisemihosting {on/off/1/0/true/false} command 
to the gdb which allows one to enable or disable semihosting suppport.
the command shoud be executed before target rdi ....  command
The patch is against gdb 5.3 but i think will apply to older versions cleanly 
too.


Enjoy
Vadim
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gdb-rdi-semihosting.patch
Type: text/x-diff
Size: 2174 bytes
Desc: not available
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20030312/ddc9943a/attachment.bin>

From m.calo at ctsgroup.it  Wed Mar 12 08:55:51 2003
From: m.calo at ctsgroup.it (=?iso-8859-1?Q?Massimo_Cal=F2?=)
Date: Wed, 12 Mar 2003 14:55:51 +0100
Subject: [uClinux-dev] Colilo hangs
References: <001601c2e75e$22881180$0814a8c0@vigilhealth.com> <20030311083147.B6204@www2.sentec-elektronik.de> <000901c2e7fe$4fbfe240$0814a8c0@vigilhealth.com>
Message-ID: <005b01c2e89f$186806f0$e10106c0@Massimo>

Greg,

    I hope this can help you :

http://www.uclinux.org/~bkuhn/Platforms/Coldfire/tarifa/20011119/

Ciao,

    Massimo

----- Original Message -----
From: "Greg Evans" <gevans at vigilhealth.com>
To: <uclinux-dev at uclinux.org>
Sent: Tuesday, March 11, 2003 7:44 PM
Subject: Re: [uClinux-dev] Colilo hangs


> Thanks for getting back to me so quickly. I followed your instructions and
I
> still could not get Colilo to boot on reset. The one thing that was
> bothering me was that whether I had JP13 on the M5272C3 board configured
for
> pins 1-2 or pins 2-3, DBUG always booted. I looked through the M5272C3
> User's Manual and sure enough JP13 was mentionned as the jumper for this
> very application. It's not that I doubted Motorola, but I took a look at
the
> board and noticed that there was a table scribed on the underside of the
> pcb. There, I found that JP5 is used to switch between booting from
> 0xFFE00000 and 0xFFF00000 (Hmmm documentation error!). Anyways, I switch
JP5
> from pins 1-2 to 2-3 and reset the board. What do you know -- the Colilo
> prompt came up!!!!
>
> Just in case there is someone out there who may have the same problem: do
> not forget to check your board. Mine is a DigitalDNA from Motorola
RE10795B
> Rev. 2.2. If yours is the same make and you are experiencing the same
> problem, then chances are JP5 is the jumper you want.
>
> Greg Evans
> gevans at vigilhealth.com
>
>
> ----- Original Message -----
> From: "Heiko Degenhardt" <heiko.degenhardt at sentec-elektronik.de>
> To: <uclinux-dev at uclinux.org>
> Sent: Monday, March 10, 2003 11:31 PM
> Subject: Re: [uClinux-dev] Colilo hangs
>
>
> > Hi Greg,
> >
> > * On Mon, Mar 10, 2003 at 03:37:41PM -0800, Greg Evans wrote:
> > > I have been working with the M5272C3 development board with
> > > uClinux-dist 20020927. I want to have Motorola's DBUG left in
> > > flash at 0xFFE00000 and install Colilo at 0xFFF00000. Using CF
> > > FLASHER, I programmed flash with colilo.bin file starting at
> > > 0xFFF00000. Next I programmed flash with a compressed file of
> > > image.bin (uclinux-dist) located at address 0xFFF40000 (note: I am
> > > using the M5272C3-1MB file for Colilo).
> >
> > I don't know something about the M5272C3-1MB file, but your setup is
> > quiet comparable to our setup of colilo (MCF5272 based board, too).
> >
> > > Both binaries are programmed without any errors.
> >
> > Ok.
> >
> > > How can I get Colilo to work with the M5272C3?
> >
> > We do it the following way: We want to boot either colilo/uClinux or
> > dBUG, debending on a jumper on our board (I think on the C3 board it
> > is jumper 13).
> > We build colilo for the 0xFFE00000 range.
> > Than we flash the image to 0xFFF00000, and the (compressed) uClinux
> > image at 0xFFF40000 (the adresses, the image size etc. are adjusted
> > in main.c).
> >
> > You can see the firs two words that the Coldfire looks up after
> > booting in dBUG:
> >
> > dBUG> md fff00000
> > FFF00000:  0000 0000 FFE0 0400 FFE0 046C FFE0 046C...
> >
> > The "FFE0 0400" is the initial program counter. There you'll find
> > the startup code of colilo:
> >
> > dBUG> dis fff00400
> > FFF00400: 4E71                 NOP
> > FFF00402: 46FC 2700            MOVE      #0x2700,SR
> > FFF00406: 203C FFE0 0000       MOVE.L    #0xFFE00000,D0
> > FFF0040C: 4E7B 0801            MOVEC     D0,VBR
> > ...
> >
> > (I had to use fff00400 as address, because this will be the address
> > 0xFFE00400 if we boot from the other flash sector).
> >
> > That doesn't answer your question why the colilo doesn't start
> > with "go fff00400" (may be this has something to do with the register
> > setup of dBUG and colilo, or it starts the image and then dies or
> > whatever). But I think that wouldn't be the default way to
> > start it anyway.
> >
> > May be you should try to do the following:
> > - Enable the CONFIG_UI and BOOTDEBUG in the Makefile
> > - Build colilo for the adress 0xffe00000
> > - Flash it to 0xfff00000 (with JP 13 set between pins 1 and 2)
> > - Set JP 13 between pins 2 and 3
> > - Reset the board
> >
> > Now you should see the colilo prompt. If so you can play with
> > it to load the image etc. If not you seem to have a problem with
> > the colilo binary itself.
> >
> > If you have further questions, please email me and I'll try to help
> > you further.
> >
> > Rgds.
> > Heiko.
> >
> >
> > _______________________________________________
> > uClinux-dev mailing list
> > uClinux-dev at uclinux.org
> > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> > This message was resent by uclinux-dev at uclinux.org
> >
>
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org



From eauth at softsys.co.at  Wed Mar 12 09:10:01 2003
From: eauth at softsys.co.at (Erwin Authried)
Date: 12 Mar 2003 15:10:01 +0100
Subject: [uClinux-dev] "wrong zone alignment" warning and &_end_kernel
	in 2.4.20
In-Reply-To: <200303121150.02036.maillist@fsforth.de>
References: <200303121150.02036.maillist@fsforth.de>
Message-ID: <1047478201.7170.175.camel@justakiss>

Am Mit, 2003-03-12 um 11.50 schrieb Markus Pietrek:
> Hi folks,
> 
> when booting uClinux-2.4.20 on a NetARM+50 or NS7520 (armnommu) I receive the 
> kernel warning "BUG: wrong zone alignment, it will crash". The code for this 
> warning is in mmnommu/page_alloc.c
> 
> void __init free_area_init_core(int nid, pg_data_t *pgdat, struct page **gmap,
> 	unsigned long *zones_size, unsigned long zone_start_paddr, 
> 	unsigned long *zholes_size, struct page *lmem_map)
> ...
> 		if ((zone_start_paddr >> PAGE_SHIFT) & (zone_required_alignment-1))
> 			printk("BUG: wrong zone alignment, it will crash %x %x %x %x\n", 
> zone_start_paddr, PAGE_SHIFT, zone_required_alignment, MAX_ORDER );
> ...
> 
> The zone 1 is starting directly after the kernel, which is located at 0x0.
> 
> zone_start_paddr == PAGE_OFFSET == &_end_kernel == 1376256
> PAGE_SHIFT == 12
> MAX_ORDER == 10
> zone_required_alignment == 0x1ff
> 
> I don't understand the reason of this function. But to get rid of this message 
> I would have to align _end_kernel at a 2MB boundary, wasting 600kb memory. 
> Are there other, better ways?
> 
Let the memory start at location zero instead. This wastes only a small
amount of memory for the page table entries, on the other hand it allows
to reuse the memory of the init section (free_initmem()). The alignment
is required for the buddy allocator, you should take the warning
serious.

Regards,
Erwin
 



From mikes at tbc.net  Wed Mar 12 10:34:51 2003
From: mikes at tbc.net (Michael F. Sharp)
Date: Wed, 12 Mar 2003 09:34:51 -0600
Subject: [uClinux-dev] uClinux for Palm IIIc - Color Console support?
 (Please Read)
References: <3E6B902E.7000103@tbc.net> <3E6BE0AB.9060109@tbc.net> <3E6C05D1.2080609@tbc.net> <3E6E919F.1090907@tbc.net> <20030312034559.GA9954@beast.internal.moreton.com.au>
Message-ID: <3E6F539B.6090308@tbc.net>

David,
Sounds like a good idea.... actually, I tried turning off all of the 
console options, ( Frame buffer and Pilot Cosole were grayed out...), 
even turned off MicroWindows and uClinux complained about a kernel panic 
then, do_unblank_screen.

I see your point, though: Make uClinux work on the PDA, w/o video, only 
working through a serial port. That way we know the platform works....

Any suggestions on how to make a "video-less" kernel for a PDA?

-Mike
David McCullough wrote:
> You could prove this by removing all the screen code and just booting on
> the serial port.  It will at least save doing all the console work only
> to find it's not the problem ;-)
> 
> Also it will give you a working base and a lot more encouragement :-)





From jeff.carr at eng.nciaccess.com  Wed Mar 12 11:04:18 2003
From: jeff.carr at eng.nciaccess.com (Jeff Carr)
Date: 12 Mar 2003 10:04:18 -0600
Subject: [uClinux-dev] bdm driver installation failing
In-Reply-To: <1047363594.1785.11.camel@rhianna.tmq.com.au>
References: <1047363594.1785.11.camel@rhianna.tmq.com.au>
Message-ID: <1047485058.2882.8.camel@jcwork>

Try loading and unloading the parport and lp modules before you load the
bdm one. 

insmod parport
insmod lp
rmmod lp
rmmod parport_pc
rmmod parport
insmod bdm

Goodluck,
Jeff

On Tue, 2003-03-11 at 00:19, Justin Clacherty wrote:
> Hi,
> 
> I'm trying to set up debugging through the bdm in gdb.  I've installed
> the bdm driver but when I run chk /dev/bdmcf0 the driver seems to be
> failing to connect to the target.  I turned on debugging and it looks
> like it is failing when it tries to read a register on the target. 
> Below is the command I am using and its output, along with the relevant
> output in /var/log/messages.  I'm using the P&E Micro wiggler that came
> with our Motorola M5272C3 development board.  Does anyone know what I
> might be doing wrong?
> 
> The commands I'm using with the output...
> 
> [justin at rhianna test]$ ./chk -d 4 /dev/bdmcf0
> Driver Ver : 2.a
> Processor  : Coldfire
> Interface  : P&E Coldfire
> Reading CSR failed: Invalid target command
> [justin at rhianna test]$
> 
> /var/log/messages
> 
> Mar 11 15:57:32 rhianna kernel:  cf_pe_read_sysreg - Reg:0xf failed with
> cmd 0x2d80, err = 217
> Mar 11 15:57:32 rhianna kernel: debugFlag now 4
> Mar 11 15:57:32 rhianna kernel: BDMioctl cmd:0x8004421e
> Mar 11 15:57:32 rhianna kernel: BDMioctl cmd:0x8004421f
> Mar 11 15:57:32 rhianna kernel: BDMioctl cmd:0x80044220
> Mar 11 15:57:32 rhianna kernel: BDMioctl cmd:0x4201
> Mar 11 15:57:32 rhianna kernel:  cf_pe_reset_chip
> Mar 11 15:57:33 rhianna kernel: BDMioctl cmd:0xc0084215
> Mar 11 15:57:33 rhianna kernel:  cf_pe_get_direct_status -- Status:0x0,
> sr:0x7e
> Mar 11 15:57:33 rhianna kernel:  cf_pe_serial_clock -- send 0x2d80 
> receive 0x1ffff
> Mar 11 15:57:33 rhianna kernel:  cf_pe_serial_clock -- failure NVC, send
> 0x2d80 receive 0x1ffff
> Mar 11 15:57:33 rhianna kernel:  cf_pe_read_sysreg - Reg:0xf failed with
> cmd 0x2d80, err = 217
> Mar 11 15:57:33 rhianna kernel: BDMioctl cmd:0x40044207
> Mar 11 15:57:33 rhianna kernel: debugFlag now 0
> 
> 
> Regards,
> Justin.
> 
> 
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20030312/47a9db0e/attachment.sig>

From vladimir.vorobyov at iss.org.ua  Wed Mar 12 11:41:46 2003
From: vladimir.vorobyov at iss.org.ua (Vladimir Vorobyov)
Date: Wed, 12 Mar 2003 18:41:46 +0200
Subject: [uClinux-dev] mcfserial and h/w flow control
References: <OF63F11C9E.8965FD1C-ON85256CD1.006DAAC0@EQUINOX.COM> <3E530C8E.9020709@snapgear.com>
Message-ID: <002201c2e8b6$46130a20$01000001@vladimir>

Hi,

Does mcfserial.c support h/w flow control and if yes, what is happening in
the following example:

I have a low data rate modem connected to the second serial port (ttyS1) of
my board and I use tip to connect to remote modem.
Serial port speed is higher than modem speed and after some time modem's
buffer becomes full and modem negates CTR signal.
As I anderstand terminal program (tip) should stop its transmission.
What does the driver (mcfserial) do in this case ? Does it inform upper
layer (tty or terminal app.) about it ? How ?
As I see from the source code the driver doesn't handle CTS state change. Am
I wrong ?

p.s. I work with M5407C3 and with the latest distr of uClinux/tools.

Regards,
Vladimir.



From David.Gelhar at Dartmouth.EDU  Wed Mar 12 13:42:52 2003
From: David.Gelhar at Dartmouth.EDU (David E. Gelhar)
Date: Wed, 12 Mar 2003 13:42:52 -0500
Subject: [uClinux-dev] ip masquarade support
In-Reply-To: <1047371564.1924.5.camel@tossu>
Message-ID: <6E931152-54BA-11D7-ADF6-00039359F448@dartmouth.edu>

On Tuesday, March 11, 2003, at 03:32 AM, Roope Anttinen wrote:

> Started all over with as stripped image as possible which does 
> basically
> nothing more than boots...


One thing I noticed in your output  is that cs89x0_probe is "finding" 
lots of bogus ethernet interfaces. The ioaddr of "0xFFE0" is supposed 
to mean "don't probe". The same thing was happening to me with a 
uCsimm; although it wasn't resulting in crashes. I don't know if this 
is the cause of your problem, but it probably can't be good to have 
these bogus ethernet devices running.

This appears to be caused by some added ARM code in drivers/net/Space.c 
that always calls cs89x0_probe for eth1..eth7 (if CONFIG_CS89x0) in the 
arch-specific probes section, while the generic isa_probes section will 
not probe for interfaces with a base addr of 0xFFE0.

The obvious patch to that is to not call the arm-specific probes on a 
non-ARM architecture:


diff -c -r1.4 -r1.5
*** Space.c     12 Mar 2003 18:19:22 -0000      1.4
--- Space.c     12 Mar 2003 18:25:45 -0000      1.5
***************
*** 397,402 ****
--- 397,405 ----
         {NULL, 0},
   };

+ /* probing for cs89x0 unconditionally (not checking for "noprobe" 
addr of 0xffe0)
+    causes trouble on uCsimm; don't do ARM probes on non-ARM arch */
+ #ifdef        CONFIG_ARM
   static struct devprobe arm_probes[] __initdata = {
   #ifdef  CONFIG_ETH_S3C4530
           {s3c_probe, 0},                         /* S3C4530      */
***************
*** 408,416 ****
           {cs89x0_probe, 0},
   #endif

-
           {NULL, 0},
   };

   /*
    * Unified ethernet device probe, segmented per architecture and
--- 411,419 ----
           {cs89x0_probe, 0},
   #endif

           {NULL, 0},
   };
+ #endif

   /*
    * Unified ethernet device probe, segmented per architecture and
***************
*** 436,443 ****
--- 439,448 ----
                 return 0;
         if (probe_list(dev, mips_probes) == 0)
                 return 0;
+ #ifdef  CONFIG_ARM
         if (probe_list(dev, arm_probes) == 0)
                 return 0;
+ #endif
         if (probe_list(dev, sgi_probes) == 0)
                 return 0;
         if (probe_list(dev, eisa_probes) == 0)


On Tuesday, March 11, 2003, at 03:32 AM, Roope Anttinen wrote:
>
> cs89x0:cs89x0_probe(0x0)
> cs89x0: Setting up uCcs8900 Chip Select & IRQ ioaddr = 0x10000300
> cs89x0.c: v2.4.3-pre1 Russell Nelson <nelson at crynwr.com>, Andrew Morton
> <andrew>
> eth0: cs8900 rev J found at 0x10000300
> cs89x0 media RJ-45, IRQ 20, programmed I/O, MAC 00:06:3b:00:00:62
> cs89x0_probe1() successful
> cs89x0:cs89x0_probe(0xffe0)
> cs89x0: Setting up uCcs8900 Chip Select & IRQ ioaddr = 0xFFE0
> eth1: cs8920 rev ` found at 0xffe0
> cs89x0 media RJ-45, IRQ 20, programmed I/O, MAC 00:06:3b:00:00:62
> cs89x0_probe1() successful
> cs89x0:cs89x0_probe(0xffe0)
> cs89x0: Setting up uCcs8900 Chip Select & IRQ ioaddr = 0xFFE0
> eth2: cs8900 rev A found at 0xffe0
> cs89x0 media RJ-45, IRQ 20, programmed I/O, MAC 00:06:3b:00:00:62
> cs89x0_probe1() successful
> cs89x0:cs89x0_probe(0xffe0)
> cs89x0: Setting up uCcs8900 Chip Select & IRQ ioaddr = 0xFFE0
> eth3: cs8920 rev A found at 0xffe0
> cs89x0 media RJ-45, IRQ 20, programmed I/O, MAC 00:06:3b:00:00:62
> cs89x0_probe1() successful
> cs89x0:cs89x0_probe(0xffe0)
> cs89x0: Setting up uCcs8900 Chip Select & IRQ ioaddr = 0xFFE0
> eth4: cs8900 rev A found at 0xffe0
> cs89x0 media RJ-45, IRQ 20, programmed I/O, MAC 00:06:3b:00:00:62
> cs89x0_probe1() successful
> cs89x0:cs89x0_probe(0xffe0)
> cs89x0: Setting up uCcs8900 Chip Select & IRQ ioaddr = 0xFFE0
> eth5: cs8920 rev A found at 0xffe0
> cs89x0 media RJ-45, IRQ 20, programmed I/O, MAC 00:06:3b:00:00:62
> cs89x0_probe1() successful
> cs89x0:cs89x0_probe(0xffe0)
> cs89x0: Setting up uCcs8900 Chip Select & IRQ ioaddr = 0xFFE0
> eth6: cs8900 rev A found at 0xffe0
> cs89x0 media RJ-45, IRQ 20, programmed I/O, MAC 00:06:3b:00:00:62
> cs89x0_probe1() successful
> cs89x0:cs89x0_probe(0xffe0)
> cs89x0: Setting up uCcs8900 Chip Select & IRQ ioaddr = 0xFFE0
> eth7: cs8920 rev A found at 0xffe0
> cs89x0 media RJ-45, IRQ 20, programmed I/O, MAC 00:06:3b:00:00:62
> cs89x0_probe1() successful



From F.Ferlemann at identecsolutions.de  Wed Mar 12 05:35:54 2003
From: F.Ferlemann at identecsolutions.de (Frieder Ferlemann)
Date: Wed, 12 Mar 2003 11:35:54 +0100
Subject: [uClinux-dev] bdm driver installation failing
References: <1047363594.1785.11.camel@rhianna.tmq.com.au> <3E6F0683.9090806@centerfunk.at>
Message-ID: <3E6F0D8A.1D4B9FCE@identecsolutions.de>

Sascha Smejkal schrieb:
> I had also trouble using BDM but can't remember the error message.
> The reason was, that the parallel port of the mainboard produced traffic on
> the parallel port no matter what I configured in the bios. Used a PCI parallel
> port card and it worked for me.

Have you checked that the printer port is not in use?
I remove (rmmod) the following modules:

#> lsmod

parport_pc             27784   1  (autoclean)
lp                      6848   0  (autoclean)
parport                25056   1  (autoclean) [parport_pc lp]



regards,

Frieder


From rgegusch at mf.tu-berlin.de  Wed Mar 12 05:38:53 2003
From: rgegusch at mf.tu-berlin.de (Rene Gegusch)
Date: Wed, 12 Mar 2003 11:38:53 +0100
Subject: [uClinux-dev] FTP Server on the 5272 board
In-Reply-To: <3E6CA45E.5090903@snapgear.com>
References: <BC03D160581F7A4E92710FC238282411167809@ici-mail.intellicom.se> <200303101443.05403.rgegusch@mf.tu-berlin.de> <3E6CA45E.5090903@snapgear.com>
Message-ID: <200303121138.53342.rgegusch@mf.tu-berlin.de>

OK, I followed your instructions and added the uC5272 directory, furthermore I 
added several uC5272 informations to the arch/m68knommu/config.in and
Boards.mk files. Before I tried to replace them with the ones from the 
Arcturus Distribution. Finally I got the same error and this made me sad.
Added the arch/m68knommu/config.in and Boards.mk files as an attachement. 
Maybe I misunderstood there somehting.
The .old files are the origin Arcturus ones.
I also attached the uC5272 files for your CVS directory.

Still thankful for further help
Rene


Am Montag, 10. M?rz 2003 15:42 schrieb Greg Ungerer:
> Hi Rene,
>
> Rene Gegusch wrote:
> > If I understand you, there are files missing to compile the project
> > correctly. I do have the CD and I already checked for the mentioned
> > crt0_ram.S file, which is there and the same as in my Arcturus Version.
> > So, what shall I looking for?
>
> If your target is the uC5272 (which I assume from your error output)
> then you need the files under:
>
>    linux-2.4.x/arch/m68knommu/platform/5272/uC5272
>
> which are not at cvs.uclinux.org and so not in uClinux-dist.
>
> You will also need to update the arch/m68knommu/config.in and
> Boards.mk files, which also do not contain options for uC5272.
>
> Regards
> Greg
>
> > Am Montag, 10. M?rz 2003 13:41 schrieb Greg Ungerer:
> >>Hi Rene,
> >>
> >>Rene Gegusch wrote:
> >>>You were right. My downloaded file was corrupted. Thank you to KDE,
> >>> which did not mentioned that!
> >>>Anyway, i just started to try to compile the new distribution for my
> >>>Arcturus uCdimm 5272 system, but compiler very fast ended compilation
> >>>with an error.< <make dep> works fine, but on the next step <make> not
> >>>so.
> >>>It stops with an missing rule error...
> >>>make[2]: changing to directory
> >>>?/home/rgegusch/test/uClinux-dist/linux-2.4.x/arch/m68knommu/platform/52
> >>>7 2? make[2]: *** no rule available for target ?/crt0_ram.S?,
> >>>  need of ?/crt0_ram.o?, to create.  End.
> >>
> >>Unfortunately the guys at Arcturus have not commited their uC5272
> >>linux-2.4.x kernel support to the CVS yet. So the low level files
> >>(for example the above mentioned crt0_ram.S) are not there. Which
> >>means they are not in the uClinux-dist either.
> >>
> >>If you have a source CD from Arcturus for the uC5272 then you
> >>would have those files. You could just pull them out and merge
> >>them. Will probably be a little bit of mucking around to get it
> >>all together, compiling and working.
> >>
> >>Regards
> >>Greg
> >>
> >>>(Compiler messages translated to English by myself)
> >>>
> >>>does anyone knows, what there is wrong?
> >>>I am not one of those kernel hacking freaks, originally had the plan to
> >>>compile the ftpd server, shipped with this distribution, but failed to
> >>>compile it because of missing PATH definitions.
> >>>
> >>>However, I need help!
> >>>
> >>>Am Freitag, 7. M?rz 2003 14:44 schrieb Greg Ungerer:
> >>>>Hi Rene,
> >>>>
> >>>>Rene Gegusch wrote:
> >>>>>Thank you for the information.
> >>>>>It confusses me, that the download of the new distribution does not
> >>>>> have it as you told us.
> >>>>>My distribution file has a size of about 105mb, seems to be OK,
> >>>>> doesn't it?
> >>>>
> >>>>The latest distribution definately contains a uClinux-dist/user/ftpd
> >>>>directory. If you don't have one then either you don't have the latest
> >>>>distribution or it is corrupted.
> >>>>
> >>>>Regards
> >>>>Greg
> >>
> >>------------------------------------------------------------------------
> >>Greg Ungerer  --  Chief Software Wizard        EMAIL:  gerg at snapgear.com
> >>SnapGear Pty Ltd                               PHONE:    +61 7 3435 2888
> >>825 Stanley St,                                  FAX:    +61 7 3891 3630
> >>Woolloongabba, QLD, 4102, Australia              WEB:   www.SnapGear.com
> >>
> >>_______________________________________________
> >>uClinux-dev mailing list
> >>uClinux-dev at uclinux.org
> >>http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> >>This message was resent by uclinux-dev at uclinux.org
> >
> > _______________________________________________
> > uClinux-dev mailing list
> > uClinux-dev at uclinux.org
> > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> > This message was resent by uclinux-dev at uclinux.org
-------------- next part --------------
# Put definitions for platforms and boards in here.

ifdef CONFIG_M68328
PLATFORM := 68328
ifdef CONFIG_PILOT
BOARD := pilot
endif
endif

ifdef CONFIG_M68EZ328
PLATFORM := 68EZ328
ifdef CONFIG_PILOT
BOARD := PalmV
endif
ifdef CONFIG_UCSIMM
BOARD := ucsimm
endif
ifdef CONFIG_ALMA_ANS
BOARD := alma_ans
endif
ifdef CONFIG_M68EZ328ADS
BOARD := ads
endif
endif

#(es)
ifdef CONFIG_M68VZ328
PLATFORM := 68VZ328
ifdef CONFIG_UCDIMM
BOARD := ucdimm
endif
ifdef CONFIG_DRAGEN2
BOARD := de2
endif
ifdef CONFIG_DRAGONIXVZ
BOARD := dragonixvz
endif
endif
#(/es)

ifdef CONFIG_M68332
PLATFORM := 68332
endif

ifdef CONFIG_M68EN302
PLATFORM := 68EN302
endif

ifdef CONFIG_M68360
PLATFORM := 68360
BOARD :=uCquicc
endif

ifdef CONFIG_M5204
PLATFORM := 5204
BOARD := SBC5204
endif

ifdef CONFIG_M5206
PLATFORM := 5206
BOARD := ARNEWSH
endif

ifdef CONFIG_M5206e
PLATFORM := 5206e
ifdef CONFIG_MOTOROLA
BOARD := MOTOROLA
endif
ifdef CONFIG_ELITE
BOARD := eLITE
endif
ifdef CONFIG_NETtel
BOARD := NETtel
endif
ifdef CONFIG_TELOS
BOARD := toolvox
endif
ifdef CONFIG_CFV240
BOARD := CFV240
endif
endif

ifdef CONFIG_M5249
PLATFORM := 5249
ifdef CONFIG_MOTOROLA
BOARD := MOTOROLA
endif
endif

ifdef CONFIG_M5272
PLATFORM := 5272
ifdef CONFIG_MOTOROLA
BOARD := MOTOROLA
endif
ifdef CONFIG_NETtel
BOARD := NETtel
endif
ifdef CONFIG_SE1100
BOARD := SE1100
endif
ifdef CONFIG_GILBARCONAP
BOARD := NAP
endif
ifdef CONFIG_senTec
BOARD := senTec
endif
endif

ifdef CONFIG_M5307
PLATFORM := 5307
ifdef CONFIG_ARNEWSH
BOARD := ARNEWSH
endif
ifdef CONFIG_NETtel
BOARD := NETtel
endif
ifdef CONFIG_eLIA
BOARD := eLIA
endif
ifdef CONFIG_DISKtel
BOARD := DISKtel
endif
ifdef CONFIG_SECUREEDGEMP3
BOARD := MP3
endif
ifdef CONFIG_MOTOROLA
BOARD := MOTOROLA
endif
ifdef CONFIG_CLEOPATRA
BOARD := CLEOPATRA
endif
endif

ifdef CONFIG_M5407
PLATFORM := 5407
ifdef CONFIG_MOTOROLA
BOARD := MOTOROLA
endif
ifdef CONFIG_CLEOPATRA
BOARD := CLEOPATRA
endif
endif

export BOARD
export PLATFORM

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Boards.mk.old
Type: application/x-trash
Size: 1784 bytes
Desc: not available
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20030312/7268cee6/attachment.old>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: config.in.old
Type: application/x-trash
Size: 14222 bytes
Desc: not available
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20030312/7268cee6/attachment-0001.old>
-------------- next part --------------
#############################################################################
#
# For a description of the syntax of this configuration file,
# see Documentation/kbuild/config-language.txt.
#
# based mainly on the arch/i386/config.in and bit of the 2.0, m68knommu
# config.in
#
#############################################################################

mainmenu_name 'uClinux/68k (w/o MMU) Kernel Configuration'

define_bool CONFIG_UCLINUX y
define_bool CONFIG_UID16 y
define_bool CONFIG_RWSEM_GENERIC_SPINLOCK y
define_bool CONFIG_RWSEM_XCHGADD_ALGORITHM n

#############################################################################

mainmenu_option next_comment
comment 'Code maturity level options'
bool 'Prompt for development and/or incomplete code/drivers' CONFIG_EXPERIMENTAL
endmenu

#############################################################################

mainmenu_option next_comment
comment 'Loadable module support'
bool 'Enable loadable module support' CONFIG_MODULES
if [ "$CONFIG_MODULES" = "y" ]; then
   bool '  Set version information on all module symbols' CONFIG_MODVERSIONS
   bool '  Kernel module loader' CONFIG_KMOD
fi
endmenu

#############################################################################

mainmenu_option next_comment
comment 'Processor type and features'

choice 'CPU' \
	"MC68000	CONFIG_M68000 \
	 MC68EN302	CONFIG_M68EN302 \
	 MC68328	CONFIG_M68328 \
         MC68EZ328	CONFIG_M68EZ328 \
	 MC68VZ328	CONFIG_M68VZ328 \
	 MC68332	CONFIG_M68332 \
	 MC68360	CONFIG_M68360 \
	 MCF5204	CONFIG_M5204 \
	 MCF5206	CONFIG_M5206 \
         MCF5206e	CONFIG_M5206e \
	 MCF5249	CONFIG_M5249 \
	 MCF5272	CONFIG_M5272 \
         MCF5307	CONFIG_M5307 \
	 MCF5407	CONFIG_M5407" M68EZ328

if [ "$CONFIG_M5204" = "y" -o \
     "$CONFIG_M5206" = "y" -o \
     "$CONFIG_M5206e" = "y" -o \
     "$CONFIG_M5249" = "y" -o \
     "$CONFIG_M5272" = "y" -o \
     "$CONFIG_M5307" = "y" -o \
     "$CONFIG_M5407" = "y" ]; then
	define_bool CONFIG_COLDFIRE y
fi
if [ "$CONFIG_M68360" = "y" ]; then
	define_bool CONFIG_360QUICC y
fi

choice 'CPU CLOCK Frequency' \
	" AUTO	CONFIG_CLOCK_AUTO \
	 11MHz	CONFIG_CLOCK_11MHz \
	 16MHz	CONFIG_CLOCK_16MHz \
	 20MHz	CONFIG_CLOCK_20MHz \
	 24MHz	CONFIG_CLOCK_24MHz \
	 25MHz	CONFIG_CLOCK_25MHz \
	 33MHz	CONFIG_CLOCK_33MHz \
	 40MHz	CONFIG_CLOCK_40MHz \
	 45MHz	CONFIG_CLOCK_45MHz \
	 48MHz	CONFIG_CLOCK_48MHz \
	 50MHz	CONFIG_CLOCK_50MHz \
	 54MHz	CONFIG_CLOCK_54MHz \
	 60MHz	CONFIG_CLOCK_60MHz \
	 66MHz	CONFIG_CLOCK_66MHz \
	 70MHz	CONFIG_CLOCK_70MHz \
	 140MHz	CONFIG_CLOCK_140MHz" AUTO

if [ "$CONFIG_M5307" = "y" ]; then
	bool 'Old mask 5307 (1H55J) silicon' CONFIG_OLDMASK
fi

comment 'Platform'

if [ "$CONFIG_M68328" = "y" -o \
     "$CONFIG_M68EZ328" = "y" -o \
     "$CONFIG_M68VZ328" = "y" ]; then
	bool 'Simulate vectorized exceptions (debugging user apps on 68000)' CONFIG_PSEUDO_EXCEPTION_VECTOR
fi

if [ "$CONFIG_M68328" = "y" ]; then
	bool 'Pilot 1000/5000, PalmPilot Personal/Pro, or PalmIII support' CONFIG_PILOT3
	if [ "$CONFIG_PILOT3" = "y" ]; then
		bool '  (X)Copilot support' CONFIG_XCOPILOT_BUGS
		bool '  Compile kernel as ELF - if your GCC is ELF-GCC' CONFIG_KERNEL_ELF
		bool '  Display memory usage on Pilot screen' CONFIG_PILOT_MEMORY_DISPLAY
		bool '  Pilot console' CONFIG_PILOT_CONSOLE
	fi
fi

if [ "$CONFIG_M68EZ328" = "y" ]; then
	bool 'Motorola M68EZ328ADS board support' CONFIG_M68EZ328ADS
	bool 'ALMA Electronics board support' CONFIG_ALMA_ANS
	bool 'uCsimm module support' CONFIG_UCSIMM
	bool 'PalmV support' CONFIG_PILOT5
	bool 'Use RTC as system timer' CONFIG_M68EZ328_USE_RTC
fi

if [ "$CONFIG_M68VZ328" = "y" ]; then
	bool 'uCdimm module support' CONFIG_UCDIMM
	bool 'Dragon Engine II board support' CONFIG_DRAGEN2
	bool 'Dragonix VZ' CONFIG_DRAGONIXVZ
fi

if [ "$CONFIG_UCSIMM" = "y" -o "$CONFIG_UCDIMM" = "y" -o "$CONFIG_DRAGEN2" = "y" ]; then
	bool '  Allow user to access IO directly' CONFIG_DIRECT_IO_ACCESS
fi

if [ "$CONFIG_UCSIMM" = "y" -o "$CONFIG_UCDIMM" = "y" -o "$CONFIG_DRAGEN2" = "y" -o "$CONFIG_DRAGONIXVZ" = "y" ]; then
	bool '  Initialize LCD' CONFIG_INIT_LCD
fi

if [ "$CONFIG_UCSIMM" = "y" -o "$CONFIG_UCDIMM" = "y" -o "$CONFIG_DRAGEN2" = "y" ]; then
	int '  Memory reservation (MB)' CONFIG_MEMORY_RESERVE 0
fi

if [ "$CONFIG_DRAGONIXVZ" = "y" ]; then
	bool 'Enable JTAG-FPGA programmer' CONFIG_DRAGONIXVZ_JTAGFPGA
	if [ "$CONFIG_DRAGONIXVZ_JTAGFPGA" = "y" ]; then
	choice 'FPGA type' \
		"EP1K30	CONFIG_FPGA1K30 \
		EP1K50	CONFIG_FPGA1K50" EP1K30
	fi
	bool '2 waitstates for flash' CONFIG_FLASH2WS
	bool 'Use 128HZ RTC scheduler instead of 100HZ timer1' CONFIG_DRAGONXBALL_USE_RTC
fi

if [ "$CONFIG_M68EN302" = "y" ]; then
	bool 'Aplio Pro' CONFIG_APLIO_PRO
	bool 'Aplio Entrecote' CONFIG_APLIO_ENTRECOTE
fi

if [ "$CONFIG_M68332" = "y" ]; then
	bool 'SHGLCore support' CONFIG_SHGLCORE
	if [ "$CONFIG_SHGLCORE" = "y" ]; then
		bool '  2Meg SHGLCore' CONFIG_SHGLCORE_2MEG
	fi
fi

if [ "$CONFIG_M68360" = "y" ]; then
	bool 'Lineo uCquicc board support' CONFIG_UCQUICC
fi

if [ "$CONFIG_M5206" = "y" ]; then
	bool 'Arnewsh 5206 board support' CONFIG_ARN5206
fi

if [ "$CONFIG_M5206e" = "y" ]; then
	bool 'Motorola M5206eC3 board support' CONFIG_M5206eC3
	bool 'Motorola eLITE-5206e board support' CONFIG_ELITE
	if [ "$CONFIG_ELITE" = "y" ]; then
		bool '  SRAM only eLITE-5206e support' CONFIG_SMALL
	fi
	bool 'Telos Omnia ToolVox board support' CONFIG_TELOS
        bool 'Netburner CFV2-40 board support' CONFIG_CFV240
fi

if [ "$CONFIG_M5249" = "y" ]; then
	bool 'Motorola M5249C3 board support' CONFIG_M5249C3
fi

if [ "$CONFIG_M5272" = "y" ]; then
	bool 'Motorola M5272C3 board support' CONFIG_M5272C3
	bool 'SecureEdge SE1100 board support' CONFIG_SE1100
	
	define_bool CONFIG_COLDFIRE y
	bool 'Motorola M5272C3 board support' CONFIG_MOTOROLA
	bool 'SnapGear/SecureEdge/NETtel board support' CONFIG_NETtel
	dep_bool '  Reset switch support' CONFIG_RESETSWITCH $CONFIG_NETtel
	bool 'Marconi/NAP board support' CONFIG_MARCONINAP
	bool 'Arcturus Networks uC5272 dimm board support' CONFIG_BOARD_UC5272
	bool 'ROMFS image not RAM resident' CONFIG_ROMFS_FROM_ROM
	
	bool 'senTec COBRA5272 board support' CONFIG_senTec
	if [ "$CONFIG_M5272C3" = "y" ]; then
		bool 'Support for PPCboot environment variables' CONFIG_PPCBOOT
	fi




fi

if [ "$CONFIG_M5307" = "y" ]; then
	bool 'Arnewsh 5307 board support' CONFIG_ARN5307
	bool 'Motorola M5307C3 board support' CONFIG_M5307C3
	bool 'Motorola M5307C3 (Cadre-III) board support' CONFIG_CADRE3
	bool 'eLIA board support' CONFIG_eLIA
	bool 'DISKtel board support' CONFIG_DISKtel
	bool 'SecureEdge MP3 board support' CONFIG_SECUREEDGEMP3
fi

if [ "$CONFIG_M5407" = "y" ]; then
	bool 'Motorola M5407C3 board support' CONFIG_M5407C3
fi

if [ "$CONFIG_M5307" = "y" -o \
     "$CONFIG_M5407" = "y" ]; then
	bool 'Feith CLEOPATRA board support' CONFIG_CLEOPATRA
fi

if [ "$CONFIG_M5206e" = "y" -o \
     "$CONFIG_M5272" = "y" -o \
	 
     "$CONFIG_BOARD_UC5272" = "y" ]; then
	#   define_bool CONFIG_UCBOOTSTRAP y
	#   echo -n " define_bool '[*] Use uCbootstrap calls' " >>MCmenu
		bool       'Use uCbootstrap calls' CONFIG_UCBOOTSTRAP

     "$CONFIG_M5307" = "y" ]; then
	bool 'SecureEdge/NETtel board support' CONFIG_NETtel
	bool 'SnapGear router board support' CONFIG_SNAPGEAR
	bool '  ROMFS image not RAM resident' CONFIG_ROMFS_FROM_ROM
fi

if [ "$CONFIG_PILOT3" = "y" -o \
     "$CONFIG_PILOT5" = "y" ]; then
	define_bool CONFIG_PILOT y
fi
if [ "$CONFIG_APLIO_PRO" = "y" -o "$CONFIG_APLIO_ENTRECOTE" = "y" ]; then
	define_bool CONFIG_APLIO y
fi
if [ "$CONFIG_ARN5206" = "y" -o \
     "$CONFIG_ARN5307" = "y" ]; then
	define_bool CONFIG_ARNEWSH y
fi
if [ "$CONFIG_M5206eC3" = "y" -o \
     "$CONFIG_M5249C3" = "y" -o \
     "$CONFIG_M5272C3" = "y" -o \
     "$CONFIG_M5307C3" = "y" -o \
     "$CONFIG_M5407C3" = "y" ]; then
	define_bool CONFIG_MOTOROLA y
fi

choice 'RAM size' \
	"AUTO	CONFIG_RAMAUTO \
	  4MB	CONFIG_RAM4MB \
	  8MB	CONFIG_RAM8MB \
	 16MB	CONFIG_RAM16MB \
	 32MB	CONFIG_RAM32MB" AUTO
choice 'RAM bit width' \
	" AUTO	CONFIG_AUTOBIT \
	  8bit	CONFIG_RAM8BIT \
	 16bit	CONFIG_RAM16BIT \
	 32bit	CONFIG_RAM32bit" AUTO

choice 'Kernel executes from' \
	"RAM	CONFIG_RAMKERNEL \
	 ROM	CONFIG_ROMKERNEL \
	 HIMEM  CONFIG_HIMEMKERNEL" ROM

endmenu

#############################################################################

mainmenu_option next_comment
comment 'General setup'

bool 'Networking support' CONFIG_NET
bool 'SGI Visual Workstation support' CONFIG_VISWS
if [ "$CONFIG_VISWS" = "y" ]; then
   define_bool CONFIG_X86_VISWS_APIC y
   define_bool CONFIG_X86_LOCAL_APIC y
   define_bool CONFIG_PCI y
else
   if [ "$CONFIG_SMP" = "y" ]; then
      define_bool CONFIG_X86_IO_APIC y
      define_bool CONFIG_X86_LOCAL_APIC y
   fi
   bool 'PCI support' CONFIG_PCI
   if [ "$CONFIG_PCI" = "y" ]; then
      choice '  PCI access mode' \
	"BIOS		CONFIG_PCI_GOBIOS	\
	 Direct		CONFIG_PCI_GODIRECT	\
	 Any		CONFIG_PCI_GOANY"	Any
      if [ "$CONFIG_PCI_GOBIOS" = "y" -o "$CONFIG_PCI_GOANY" = "y" ]; then
         define_bool CONFIG_PCI_BIOS y
      fi
      if [ "$CONFIG_PCI_GODIRECT" = "y" -o "$CONFIG_PCI_GOANY" = "y" ]; then
         define_bool CONFIG_PCI_DIRECT y
      fi
   fi
fi

source drivers/pci/Config.in

if [ "$CONFIG_VISWS" != "y" ]; then
   bool 'MCA support' CONFIG_MCA
fi

bool 'Support for hot-pluggable devices' CONFIG_HOTPLUG

if [ "$CONFIG_HOTPLUG" = "y" ] ; then
   source drivers/pcmcia/Config.in
else
   define_bool CONFIG_PCMCIA n
fi

bool 'System V IPC' CONFIG_SYSVIPC
bool 'BSD Process Accounting' CONFIG_BSD_PROCESS_ACCT
bool 'Sysctl support' CONFIG_SYSCTL
if [ "$CONFIG_PROC_FS" = "y" ]; then
   choice 'Kernel core (/proc/kcore) format' \
	"ELF		CONFIG_KCORE_ELF	\
	 A.OUT		CONFIG_KCORE_AOUT" ELF
fi
tristate 'Kernel support for flat binaries' CONFIG_BINFMT_FLAT
if [ "$CONFIG_BINFMT_FLAT" != "n" ]; then
   bool '    Enable ZFLAT support' CONFIG_BINFMT_ZFLAT
   bool '    Enable shared FLAT support' CONFIG_BINFMT_SHARED_FLAT
fi
tristate 'Kernel support for a.out binaries' CONFIG_BINFMT_AOUT
tristate 'Kernel support for ELF binaries' CONFIG_BINFMT_ELF
tristate 'Kernel support for MISC binaries' CONFIG_BINFMT_MISC

bool 'Power Management support' CONFIG_PM

dep_bool '  ACPI support' CONFIG_ACPI $CONFIG_PM
if [ "$CONFIG_ACPI" != "n" ]; then
   if [ "$CONFIG_EXPERIMENTAL" = "y" ]; then
      bool '    ACPI interpreter (EXPERIMENTAL)' CONFIG_ACPI_INTERPRETER
      bool '    Enter S1 for sleep (EXPERIMENTAL)' CONFIG_ACPI_S1_SLEEP
   fi
fi

if [ "$CONFIG_UCSIMM" = "y" -o "$CONFIG_UCDIMM" = "y" ]; then
   dep_bool '  Doze sleep mode only (clocks running)' CONFIG_PM_DOZE_ONLY $CONFIG_PM
   dep_bool '  Wake up on power button (IRQ3)' CONFIG_PM_POWER_BUTTON_IRQ3 $CONFIG_PM
   dep_bool '  Support user level pm_helper (/sbin/pm_helper)' CONFIG_PM_HELPER $CONFIG_PM
fi

dep_tristate '  Advanced Power Management BIOS support' CONFIG_APM $CONFIG_PM
if [ "$CONFIG_APM" != "n" ]; then
   bool '    Ignore USER SUSPEND' CONFIG_APM_IGNORE_USER_SUSPEND
   bool '    Enable PM at boot time' CONFIG_APM_DO_ENABLE
   bool '    Make CPU Idle calls when idle' CONFIG_APM_CPU_IDLE
   bool '    Enable console blanking using APM' CONFIG_APM_DISPLAY_BLANK
   bool '    RTC stores time in GMT' CONFIG_APM_RTC_IS_GMT
   bool '    Allow interrupts during APM BIOS calls' CONFIG_APM_ALLOW_INTS
   bool '    Use real mode APM BIOS call to power off' CONFIG_APM_REAL_MODE_POWER_OFF
fi

endmenu

#############################################################################

source drivers/mtd/Config.in

source drivers/parport/Config.in

source drivers/pnp/Config.in

source drivers/block/Config.in

if [ "$CONFIG_NET" = "y" ]; then
   source net/Config.in
fi

source drivers/telephony/Config.in

#############################################################################

mainmenu_option next_comment
comment 'ATA/IDE/MFM/RLL support'

tristate 'ATA/IDE/MFM/RLL support' CONFIG_IDE

if [ "$CONFIG_IDE" != "n" ]; then
  source drivers/ide/Config.in
else
  define_bool CONFIG_BLK_DEV_IDE_MODES n
  define_bool CONFIG_BLK_DEV_HD n
fi
endmenu

#############################################################################

mainmenu_option next_comment
comment 'SCSI support'

tristate 'SCSI support' CONFIG_SCSI

if [ "$CONFIG_SCSI" != "n" ]; then
   source drivers/scsi/Config.in
fi
endmenu

#############################################################################

source drivers/ieee1394/Config.in

source drivers/message/i2o/Config.in

if [ "$CONFIG_NET" = "y" ]; then
   mainmenu_option next_comment
   comment 'Network device support'

   bool 'Network device support' CONFIG_NETDEVICES
   if [ "$CONFIG_NETDEVICES" = "y" ]; then
      source drivers/net/Config.in
      if [ "$CONFIG_ATM" = "y" ]; then
         source drivers/atm/Config.in
      fi
   fi
   endmenu
fi

source net/ax25/Config.in

source net/irda/Config.in

#############################################################################

mainmenu_option next_comment
comment 'ISDN subsystem'
if [ "$CONFIG_NET" != "n" ]; then
   tristate 'ISDN support' CONFIG_ISDN
   if [ "$CONFIG_ISDN" != "n" ]; then
      source drivers/isdn/Config.in
   fi
fi
endmenu

#############################################################################

mainmenu_option next_comment
comment 'Old CD-ROM drivers (not SCSI, not IDE)'

bool 'Support non-SCSI/IDE/ATAPI CDROM drives' CONFIG_CD_NO_IDESCSI
if [ "$CONFIG_CD_NO_IDESCSI" != "n" ]; then
   source drivers/cdrom/Config.in
fi
endmenu

#############################################################################

source drivers/char/Config.in


#source drivers/misc/Config.in

source fs/Config.in

if [ "$CONFIG_VT" = "y" ]; then
   mainmenu_option next_comment
   comment 'Console drivers'
   bool 'VGA text console' CONFIG_VGA_CONSOLE
   bool 'Video mode selection support' CONFIG_VIDEO_SELECT
   if [ "$CONFIG_EXPERIMENTAL" = "y" ]; then
      tristate 'MDA text console (dual-headed) (EXPERIMENTAL)' CONFIG_MDA_CONSOLE
      source drivers/video/Config.in
   fi
   endmenu
fi

#############################################################################

mainmenu_option next_comment
comment 'Sound'

tristate 'Sound card support' CONFIG_SOUND
if [ "$CONFIG_SOUND" != "n" ]; then
   source drivers/sound/Config.in
fi
endmenu

#############################################################################

source drivers/usb/Config.in

#############################################################################

mainmenu_option next_comment
comment 'Kernel hacking'

bool 'Full Symbolic/Source Debugging support' CONFIG_FULLDEBUG
#bool 'Debug kmalloc/kfree' CONFIG_DEBUG_MALLOC
bool 'Magic SysRq key' CONFIG_MAGIC_SYSRQ
if [ "$CONFIG_EXPERIMENTAL" = "y" ]; then
	bool 'Non power-of-2 kernel allocator (EXPERIMENTAL)' CONFIG_CONTIGUOUS_PAGE_ALLOC
	dep_bool '  include /proc/mem_map' CONFIG_MEM_MAP $CONFIG_CONTIGUOUS_PAGE_ALLOC
fi

bool 'Kernel profiling support' CONFIG_PROFILE
if [ "$CONFIG_PROFILE" = "y" ]; then
  int ' Profile shift count' CONFIG_PROFILE_SHIFT 2
  bool 'Use fast second timer for profiling' CONFIG_HIGHPROFILE
fi

if [ "$CONFIG_COLDFIRE" = "y" ]; then
	bool 'Panic/Dump to FLASH' CONFIG_DUMPTOFLASH
fi

bool 'Suppress Kernel BUG Messages' CONFIG_NO_KERNEL_MSG

bool 'Reduce kernel task size to 1 page' CONFIG_SMALL_TASKS

if [ "$CONFIG_EXPERIMENTAL" = "y" -a "$CONFIG_COLDFIRE" = "y" -a "$CONFIG_FULLDEBUG" = "n" ]; then
    bool 'Disable BDM signals' CONFIG_BDM_DISABLE
fi

bool 'Compiled-in Kernel Boot Parameter' CONFIG_BOOTPARAM
if [ "$CONFIG_BOOTPARAM" = "y" ]; then
  string 'Kernel Boot Parameter' CONFIG_BOOTPARAM_STRING ""
fi

endmenu


#############################################################################

source lib/Config.in

#############################################################################
-------------- next part --------------
A non-text attachment was scrubbed...
Name: uC5272.tar
Type: application/x-tar
Size: 20480 bytes
Desc: not available
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20030312/7268cee6/attachment.tar>

From davidm at snapgear.com  Wed Mar 12 17:24:06 2003
From: davidm at snapgear.com (David McCullough)
Date: Thu, 13 Mar 2003 08:24:06 +1000
Subject: [uClinux-dev] uClinux for Palm IIIc - Color Console support? (Please Read)
In-Reply-To: <3E6F539B.6090308@tbc.net>
References: <3E6B902E.7000103@tbc.net> <3E6BE0AB.9060109@tbc.net> <3E6C05D1.2080609@tbc.net> <3E6E919F.1090907@tbc.net> <20030312034559.GA9954@beast.internal.moreton.com.au> <3E6F539B.6090308@tbc.net>
Message-ID: <20030312222406.GA16798@beast.internal.moreton.com.au>

Jivin Michael F. Sharp lays it down ...
> David,
> Sounds like a good idea.... actually, I tried turning off all of the 
> console options, ( Frame buffer and Pilot Cosole were grayed out...), 
> even turned off MicroWindows and uClinux complained about a kernel panic 
> then, do_unblank_screen.
> 
> I see your point, though: Make uClinux work on the PDA, w/o video, only 
> working through a serial port. That way we know the platform works....
> 
> Any suggestions on how to make a "video-less" kernel for a PDA?


Turn off CONFIG_CONSOLE, CONFIG_FRAMEBUFFER and CONFIG_PILOT_CONSOLE.

Turn on CONFIG_68328_SERIAL.

Find anything in crt0.S that messes with the video adaptor and #ifdef
it out (I don't know the video registers but they should be easy to
spot once you do).

It might be useful to do a practice run on Xcopilot and get rid of the
penguin and make sure the serial port gives you a shell.  Better still
you could modify the Xcopilot code to error out if you access the video
at all.

Cheers,
Davidm

-- 
David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
davidm at snapgear.com  Fx: +61 7 3891 3630  Custom Embedded Solutions + Security


From stuartm at connecttech.com  Wed Mar 12 17:28:52 2003
From: stuartm at connecttech.com (Stuart MacDonald)
Date: Wed, 12 Mar 2003 17:28:52 -0500
Subject: [uClinux-dev] Daemonize a process
Message-ID: <025801c2e8e6$c2fd56a0$294b82ce@connecttech.com>

The classic sequence of:

fork();
setsid();
fork();

doesn't work in uClinux because vfork blocks the parent until an _exit
or execve().

What I end up with is two D state processes (zombies) and the final
child still parented by its real parent instead of init.

I've checked a number of /user apps, but haven't found one that wants
to do the same thing, so no example code to follow.

Am I missing a simple solution, or is this just not possible until
uClinux gets fork()? If so, what's required to get fork working? The
comment in arch/m68knommu/kernel/process.c states that it almost
works, but doesn't specify which bit is failing.

..Stu




From hamilton at sedsystems.ca  Wed Mar 12 17:34:57 2003
From: hamilton at sedsystems.ca (Kendrick Hamilton)
Date: Wed, 12 Mar 2003 16:34:57 -0600 (Canada Central Standard Time)
Subject: [uClinux-dev] Daemonize a process
In-Reply-To: <025801c2e8e6$c2fd56a0$294b82ce@connecttech.com>
Message-ID: <Pine.WNT.4.44.0303121631290.258-100000@sw-55.sedsystems.ca>

A simple way to daemonize a process:
	my_process&
This runs the process in the background.
Another way is to start the process is to use /etc/inittab.

On Wed, 12 Mar 2003, Stuart MacDonald wrote:

> The classic sequence of:
>
> fork();
> setsid();
> fork();
>
> doesn't work in uClinux because vfork blocks the parent until an _exit
> or execve().
>
> What I end up with is two D state processes (zombies) and the final
> child still parented by its real parent instead of init.
>
> I've checked a number of /user apps, but haven't found one that wants
> to do the same thing, so no example code to follow.
>
> Am I missing a simple solution, or is this just not possible until
> uClinux gets fork()? If so, what's required to get fork working? The
> comment in arch/m68knommu/kernel/process.c states that it almost
> works, but doesn't specify which bit is failing.
>
> ..Stu
>
>
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org
>



From davidm at snapgear.com  Wed Mar 12 18:02:11 2003
From: davidm at snapgear.com (David McCullough)
Date: Thu, 13 Mar 2003 09:02:11 +1000
Subject: [uClinux-dev] Daemonize a process
In-Reply-To: <025801c2e8e6$c2fd56a0$294b82ce@connecttech.com>
References: <025801c2e8e6$c2fd56a0$294b82ce@connecttech.com>
Message-ID: <20030312230211.GB16830@beast.internal.moreton.com.au>

Jivin Stuart MacDonald lays it down ...
> The classic sequence of:
> 
> fork();
> setsid();
> fork();
> 
> doesn't work in uClinux because vfork blocks the parent until an _exit
> or execve().
> 
> What I end up with is two D state processes (zombies) and the final
> child still parented by its real parent instead of init.
> 
> I've checked a number of /user apps, but haven't found one that wants
> to do the same thing, so no example code to follow.


There are a couple of ways to achieve this:

* have init start your daemon

* have your daemon exec itself with a special option to become a daemon.


> Am I missing a simple solution, or is this just not possible until
> uClinux gets fork()? If so, what's required to get fork working? The
> comment in arch/m68knommu/kernel/process.c states that it almost
> works, but doesn't specify which bit is failing.

fork on uClinux is not possible.  It gives a short term impression of
working, before your system dies horribly.  It cannot be fixed in any
practical way and you can find all the reasons why in the uClinux-dev
archives :-)

Cheers,
Davidm

-- 
David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
davidm at snapgear.com  Fx: +61 7 3891 3630  Custom Embedded Solutions + Security


From robertd at vantagecontrols.com  Wed Mar 12 18:44:25 2003
From: robertd at vantagecontrols.com (Robert Daniels)
Date: Wed, 12 Mar 2003 16:44:25 -0700
Subject: [uClinux-dev] Daemonize a process
In-Reply-To: <20030312230211.GB16830@beast.internal.moreton.com.au>
Message-ID: <004701c2e8f1$54590e00$660ba8c0@robertd>

You might want to check the code for smbmount for an example of an
application that does the daemonize thing.  It's under
user/samba/source/client/smbmount.c.  It was modified to not call its
own daemonize function and instead, it will go into a loop where it will
kill its parent (most likely your shell) and keep running.  It's a
little annoying if you do this from a telnet session, but if you do it
from the default console, it just restarts the main shell.  I don't know
if this will work in your situation or not.  I modified this code to use
a goofy version of daemonize in which I use vfork and execv to spawn off
a daemon process.  The trick here is to make sure you don't recursively
daemonize, which I accomplished by snooping the /proc filesystem.

Robert

-----Original Message-----
From: uclinux-dev-admin at uclinux.org
[mailto:uclinux-dev-admin at uclinux.org] On Behalf Of David McCullough
Sent: Wednesday, March 12, 2003 4:02 PM
To: uclinux-dev at uclinux.org
Subject: Re: [uClinux-dev] Daemonize a process


Jivin Stuart MacDonald lays it down ...
> The classic sequence of:
> 
> fork();
> setsid();
> fork();
> 
> doesn't work in uClinux because vfork blocks the parent until an _exit
> or execve().
> 
> What I end up with is two D state processes (zombies) and the final
> child still parented by its real parent instead of init.
> 
> I've checked a number of /user apps, but haven't found one that wants
> to do the same thing, so no example code to follow.


There are a couple of ways to achieve this:

* have init start your daemon

* have your daemon exec itself with a special option to become a daemon.


> Am I missing a simple solution, or is this just not possible until
> uClinux gets fork()? If so, what's required to get fork working? The
> comment in arch/m68knommu/kernel/process.c states that it almost
> works, but doesn't specify which bit is failing.

fork on uClinux is not possible.  It gives a short term impression of
working, before your system dies horribly.  It cannot be fixed in any
practical way and you can find all the reasons why in the uClinux-dev
archives :-)

Cheers,
Davidm

-- 
David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
davidm at snapgear.com  Fx: +61 7 3891 3630  Custom Embedded Solutions +
Security
_______________________________________________
uClinux-dev mailing list
uClinux-dev at uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev at uclinux.org



From justin at tmq.com.au  Wed Mar 12 18:57:23 2003
From: justin at tmq.com.au (Justin Clacherty)
Date: 13 Mar 2003 09:57:23 +1000
Subject: [uClinux-dev] bdm driver installation failing
In-Reply-To: <1047485058.2882.8.camel@jcwork>
References: <1047485058.2882.8.camel@jcwork>
Message-ID: <1047513447.1084.5.camel@rhianna.tmq.com.au>

I've already done this.  Originally I was having a problem where the
driver would report that the /dev/bdmcf0 resource is busy, this was
because the install of linux I am running had lp, parport, adn
parport_pc running (still does from boot).  I do the rmmod after I boot
up (haven't got around to finding out how to get it to never load).

I know it isn't a hardware issue as I tested debugging under W2K using
the Metrowerks tools.  The interesting thing is that when I connect the
debugger under linux, the leds on the board seem to flicker, this does
not happen under windows, it is as though something is writing to the
parallel port (presumably resetting the board continuously).

Justin.

On Thu, 2003-03-13 at 02:04, Jeff Carr wrote:
> Try loading and unloading the parport and lp modules before you load the
> bdm one. 
> 
> insmod parport
> insmod lp
> rmmod lp
> rmmod parport_pc
> rmmod parport
> insmod bdm
> 
> Goodluck,
> Jeff
> 
> On Tue, 2003-03-11 at 00:19, Justin Clacherty wrote:
> > Hi,
> > 
> > I'm trying to set up debugging through the bdm in gdb.  I've installed
> > the bdm driver but when I run chk /dev/bdmcf0 the driver seems to be
> > failing to connect to the target.  I turned on debugging and it looks
> > like it is failing when it tries to read a register on the target. 
> > Below is the command I am using and its output, along with the
> relevant
> > output in /var/log/messages.  I'm using the P&E Micro wiggler that
> came
> > with our Motorola M5272C3 development board.  Does anyone know what I
> > might be doing wrong?
> > 
> > The commands I'm using with the output...
> > 
> > [justin at rhianna test]$ ./chk -d 4 /dev/bdmcf0
> > Driver Ver : 2.a
> > Processor  : Coldfire
> > Interface  : P&E Coldfire
> > Reading CSR failed: Invalid target command
> > [justin at rhianna test]$
> > 
> > /var/log/messages
> > 
> > Mar 11 15:57:32 rhianna kernel:  cf_pe_read_sysreg - Reg:0xf failed
> with
> > cmd 0x2d80, err = 217
> > Mar 11 15:57:32 rhianna kernel: debugFlag now 4
> > Mar 11 15:57:32 rhianna kernel: BDMioctl cmd:0x8004421e
> > Mar 11 15:57:32 rhianna kernel: BDMioctl cmd:0x8004421f
> > Mar 11 15:57:32 rhianna kernel: BDMioctl cmd:0x80044220
> > Mar 11 15:57:32 rhianna kernel: BDMioctl cmd:0x4201
> > Mar 11 15:57:32 rhianna kernel:  cf_pe_reset_chip
> > Mar 11 15:57:33 rhianna kernel: BDMioctl cmd:0xc0084215
> > Mar 11 15:57:33 rhianna kernel:  cf_pe_get_direct_status --
> Status:0x0,
> > sr:0x7e
> > Mar 11 15:57:33 rhianna kernel:  cf_pe_serial_clock -- send 0x2d80 
> > receive 0x1ffff
> > Mar 11 15:57:33 rhianna kernel:  cf_pe_serial_clock -- failure NVC,
> send
> > 0x2d80 receive 0x1ffff
> > Mar 11 15:57:33 rhianna kernel:  cf_pe_read_sysreg - Reg:0xf failed
> with
> > cmd 0x2d80, err = 217
> > Mar 11 15:57:33 rhianna kernel: BDMioctl cmd:0x40044207
> > Mar 11 15:57:33 rhianna kernel: debugFlag now 0
> > 
> > 
> > Regards,
> > Justin.
> > 
> > 
> > _______________________________________________
> > uClinux-dev mailing list
> > uClinux-dev at uclinux.org
> > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> > This message was resent by uclinux-dev at uclinux.org
> > 




From seawinding at 21cn.com  Wed Mar 12 19:45:59 2003
From: seawinding at 21cn.com (seawinding)
Date: Thu, 13 Mar 2003 8:45:59 +0800
Subject: [uClinux-dev] re:subscribe linux
Message-ID: <uR969686915758.06379@send3.inner-21cn.com>

uclinux-dev?

????????seawinding
????????seawinding at 21cn.com
??????????2003-03-13





From jeff.carr at eng.nciaccess.com  Wed Mar 12 19:46:53 2003
From: jeff.carr at eng.nciaccess.com (Jeff Carr)
Date: 12 Mar 2003 18:46:53 -0600
Subject: [uClinux-dev] bdm driver installation failing
In-Reply-To: <1047513447.1084.5.camel@rhianna.tmq.com.au>
References: <1047485058.2882.8.camel@jcwork>
	 <1047513447.1084.5.camel@rhianna.tmq.com.au>
Message-ID: <1047516413.2879.200.camel@jcwork>

Strange... Good luck with it, I'd try a different model BDM if you have
one. I use a P&E's rev F.
Jeff

On Wed, 2003-03-12 at 17:57, Justin Clacherty wrote:
> I've already done this.  Originally I was having a problem where the
> driver would report that the /dev/bdmcf0 resource is busy, this was
> because the install of linux I am running had lp, parport, adn
> parport_pc running (still does from boot).  I do the rmmod after I boot
> up (haven't got around to finding out how to get it to never load).
> 
> I know it isn't a hardware issue as I tested debugging under W2K using
> the Metrowerks tools.  The interesting thing is that when I connect the
> debugger under linux, the leds on the board seem to flicker, this does
> not happen under windows, it is as though something is writing to the
> parallel port (presumably resetting the board continuously).
> 
> Justin.
> 
> On Thu, 2003-03-13 at 02:04, Jeff Carr wrote:
> > Try loading and unloading the parport and lp modules before you load the
> > bdm one. 
> > 
> > insmod parport
> > insmod lp
> > rmmod lp
> > rmmod parport_pc
> > rmmod parport
> > insmod bdm
> > 
> > Goodluck,
> > Jeff
> > 
> > On Tue, 2003-03-11 at 00:19, Justin Clacherty wrote:
> > > Hi,
> > > 
> > > I'm trying to set up debugging through the bdm in gdb.  I've installed
> > > the bdm driver but when I run chk /dev/bdmcf0 the driver seems to be
> > > failing to connect to the target.  I turned on debugging and it looks
> > > like it is failing when it tries to read a register on the target. 
> > > Below is the command I am using and its output, along with the
> > relevant
> > > output in /var/log/messages.  I'm using the P&E Micro wiggler that
> > came
> > > with our Motorola M5272C3 development board.  Does anyone know what I
> > > might be doing wrong?
> > > 
> > > The commands I'm using with the output...
> > > 
> > > [justin at rhianna test]$ ./chk -d 4 /dev/bdmcf0
> > > Driver Ver : 2.a
> > > Processor  : Coldfire
> > > Interface  : P&E Coldfire
> > > Reading CSR failed: Invalid target command
> > > [justin at rhianna test]$
> > > 
> > > /var/log/messages
> > > 
> > > Mar 11 15:57:32 rhianna kernel:  cf_pe_read_sysreg - Reg:0xf failed
> > with
> > > cmd 0x2d80, err = 217
> > > Mar 11 15:57:32 rhianna kernel: debugFlag now 4
> > > Mar 11 15:57:32 rhianna kernel: BDMioctl cmd:0x8004421e
> > > Mar 11 15:57:32 rhianna kernel: BDMioctl cmd:0x8004421f
> > > Mar 11 15:57:32 rhianna kernel: BDMioctl cmd:0x80044220
> > > Mar 11 15:57:32 rhianna kernel: BDMioctl cmd:0x4201
> > > Mar 11 15:57:32 rhianna kernel:  cf_pe_reset_chip
> > > Mar 11 15:57:33 rhianna kernel: BDMioctl cmd:0xc0084215
> > > Mar 11 15:57:33 rhianna kernel:  cf_pe_get_direct_status --
> > Status:0x0,
> > > sr:0x7e
> > > Mar 11 15:57:33 rhianna kernel:  cf_pe_serial_clock -- send 0x2d80 
> > > receive 0x1ffff
> > > Mar 11 15:57:33 rhianna kernel:  cf_pe_serial_clock -- failure NVC,
> > send
> > > 0x2d80 receive 0x1ffff
> > > Mar 11 15:57:33 rhianna kernel:  cf_pe_read_sysreg - Reg:0xf failed
> > with
> > > cmd 0x2d80, err = 217
> > > Mar 11 15:57:33 rhianna kernel: BDMioctl cmd:0x40044207
> > > Mar 11 15:57:33 rhianna kernel: debugFlag now 0
> > > 
> > > 
> > > Regards,
> > > Justin.
> > > 
> > > 
> > > _______________________________________________
> > > uClinux-dev mailing list
> > > uClinux-dev at uclinux.org
> > > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> > > This message was resent by uclinux-dev at uclinux.org
> > > 
> 
> 
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20030312/6b0a3329/attachment.sig>

From yangyajun at hisense.cngb.com  Wed Mar 12 20:07:42 2003
From: yangyajun at hisense.cngb.com (=?gb2312?B?0e7Rx778?=)
Date: Thu, 13 Mar 2003 09:07:42 +0800
Subject: [uClinux-dev] A MTD question
References: <001401c2e83a$27ae3270$5422a8c0@LocalHost> <200303121747.52002.petero@cvs.com.au>
Message-ID: <008f01c2e8fc$f376ffa0$5422a8c0@LocalHost>

Thank you ,Peter.

----- Original Message ----- 
From: "Peter Ogilvy" <petero at cvs.com.au>
To: <uclinux-dev at uclinux.org>
Sent: Wednesday, March 12, 2003 2:47 PM
Subject: Re: [uClinux-dev] A MTD question


Hi,

I seem to remember reading somewhere that the SSL library is not
included in the dist because of potential problems exporting
encryption code. You have to find it yourself and add it.

Hope this helps,

Peter

??? wrote:
> Hi,all
>     I want to use jff2 in my uClinux,so I selected MTD support in
> kernel.but when I make ,
 it returned an error when it goes to "mtd-utils"
> directory,said that there lost a library file named "libssl".I went to
> uClinux/lib,It is true that there is no file or directory "libssl". What
> should I do?
>    
>     Any help? Thank you very much! 

_______________________________________________
uClinux-dev mailing list
uClinux-dev at uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev at uclinux.org


From jwilliams at itee.uq.edu.au  Wed Mar 12 22:15:40 2003
From: jwilliams at itee.uq.edu.au (John Williams)
Date: Thu, 13 Mar 2003 13:15:40 +1000
Subject: [uClinux-dev] uclinux and RTLinux / RTAI
Message-ID: <3E6FF7DC.7090708@itee.uq.edu.au>

Hi,

Can anybody give me a run-down on the status of known uClinux/RTLinux 
projects?

There is a working RTLinux patch for uClinux 2.0.x, for the m68k 
Dragonball at https://courseware.vt.edu/users/binoy/4984/project1.html.

Since then things have diverged significantly!  There is now an RTLinux 
patch onto standard linux 2.4.19, with most of the changes occurring in 
/arch/i386/kernel (what a surprise!).

The uClinux mailing list archive has some discussions from Bernard Kuhn 
about impending release of RTLinux for a later kernel version, but I 
never saw any more on it.  Bernard, are you still out there?  SnapGear 
and Arcturus were also potential suspects!

Before we go and commit resources to this, can anybody cast any more 
light on the situation?  Options seem to be hack vs port, ie:

(1) Hack RTL uClinux patch 2.0.x up to work on uClinux 2.4.19

(2) Port RTL 2.4.19 across to uClinux 2.4.19.

Comments anyone?

Regards,

John



From davidm at snapgear.com  Wed Mar 12 22:41:43 2003
From: davidm at snapgear.com (David McCullough)
Date: Thu, 13 Mar 2003 13:41:43 +1000
Subject: [uClinux-dev] uclinux and RTLinux / RTAI
In-Reply-To: <3E6FF7DC.7090708@itee.uq.edu.au>
References: <3E6FF7DC.7090708@itee.uq.edu.au>
Message-ID: <20030313034143.GA16457@beast.internal.moreton.com.au>

Jivin John Williams lays it down ...
> Hi,
> 
> Can anybody give me a run-down on the status of known uClinux/RTLinux 
> projects?
> 
> There is a working RTLinux patch for uClinux 2.0.x, for the m68k 
> Dragonball at https://courseware.vt.edu/users/binoy/4984/project1.html.
> 
> Since then things have diverged significantly!  There is now an RTLinux 
> patch onto standard linux 2.4.19, with most of the changes occurring in 
> /arch/i386/kernel (what a surprise!).
> 
> The uClinux mailing list archive has some discussions from Bernard Kuhn 
> about impending release of RTLinux for a later kernel version, but I 
> never saw any more on it.  Bernard, are you still out there?  SnapGear 
> and Arcturus were also potential suspects!


We (as in SnapGear) haven't played with RT-linux at all to date, so no
chance of anything coming from us in te hnear future ;-).


> Before we go and commit resources to this, can anybody cast any more 
> light on the situation?  Options seem to be hack vs port, ie:
> 
> (1) Hack RTL uClinux patch 2.0.x up to work on uClinux 2.4.19
> 
> (2) Port RTL 2.4.19 across to uClinux 2.4.19.

I would have thought 2 with reference to 1 would be the way to go.

Cheers,
Davidm

-- 
David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
davidm at snapgear.com  Fx: +61 7 3891 3630  Custom Embedded Solutions + Security


From tendim at tendim.cjb.net  Thu Mar 13 01:14:00 2003
From: tendim at tendim.cjb.net (patrick)
Date: Thu, 13 Mar 2003 01:14:00 -0500 (EST)
Subject: [uClinux-dev] Problems compiling for uCdimm
Message-ID: <Pine.NEB.4.44.0303130109370.26292-100000@vex.net>

Hello.

I have been experiencing problems compiling uClinux-dist-20030305.tar.gz
with m68k-elf-tools-20020410.tar.gz.

I've followed the instructions, done a "make menuconfig" and "make dep"
and proceed to do "make", after making sure that I have selected the
proper manufacturer for my board (Arcturus).  However, I consistently get
the following message:

m68k-elf-gcc: Internal compiler error: program cc1 got fatal signal 11
.. and a bunch of make[x]: messages ..

Now, the thing is, that if I issue a "make" after the "crash" the
compilation picks up where it left off, and keeps going.

So I want to know, what *is* signal 11?  How can I avoid it?  Since the
error occurs in different files (and when I re-issue the "make", the file
that crashed last time compiles without problems), I'm thinking it is
something with my setup.

I'm doing this on an AMD K6-233 w/ 42 MB RAM, and 256 MB of swap space,
under Linux 2.4.17 (from Redhat 7.2).  I know that this is pushing the
machine to the limit, but it is the only Intel based machine I have at
the moment ot develop on!  :(  (And all binaries I've found so far are for
Intel).

Thanks for any help ppl can give me.

-Patrick

patrick at tendim.cjb.net
"It's simple, overspecialize and you breed in weakness."
 --Ghost in the Shell




From heiko.degenhardt at sentec-elektronik.de  Thu Mar 13 02:07:39 2003
From: heiko.degenhardt at sentec-elektronik.de (Heiko Degenhardt)
Date: Thu, 13 Mar 2003 08:07:39 +0100
Subject: [uClinux-dev] Problems compiling for uCdimm
In-Reply-To: <Pine.NEB.4.44.0303130109370.26292-100000@vex.net>; from tendim@tendim.cjb.net on Thu, Mar 13, 2003 at 01:14:00AM -0500
References: <Pine.NEB.4.44.0303130109370.26292-100000@vex.net>
Message-ID: <20030313080739.B14655@www2.sentec-elektronik.de>

Hi Patrick, 

* On Thu, Mar 13, 2003 at 01:14:00AM -0500, patrick wrote:
> m68k-elf-gcc: Internal compiler error: program cc1 got fatal signal 11
> .. and a bunch of make[x]: messages ..
> 
> Now, the thing is, that if I issue a "make" after the "crash" the
> compilation picks up where it left off, and keeps going.

that the make picks up where it left off is normal. Make sees what
it has done allready, and what it has to do next. That's one of the 
advantages of the make suit.

For the signal 11 I would recommend http://www.bitwizard.nl/sig11/.
In most cases where I got that problem it was caused by bad
hardware. One hint in that direction would be if the sig 11 occurs
allways at different stages of the process.

Rgds.
Heiko.



From selvam at sesl.global.sharp.co.jp  Thu Mar 13 02:58:12 2003
From: selvam at sesl.global.sharp.co.jp (Selvam)
Date: Thu, 13 Mar 2003 15:58:12 +0800
Subject: [uClinux-dev] Problem opening console
In-Reply-To: <r01050400-1024-64D2897D546C11D7AEEB00039387ACB6@[10.0.1.2]>
References: <r01050400-1024-64D2897D546C11D7AEEB00039387ACB6@[10.0.1.2]>
Message-ID: <03031315581200.24943@localhost>

Richard I'm still getting some lines printed correctly in between 
the junk chars. So I don't think it's the baud rate. 

-------------------------------------------------------
Mountingb^A^@^A^@^@^B.^@^EH^E^@^@^@^@`^@ 
^@^B^@..^PA^B"..^B@^A^B^B^@^P^@@^@^@ ? ?Q^@ proc on /proc
-------------------------------------------------------

thanks
Selvam.


On Wednesday 12 March 2003 17:24, Richard Klingler wrote:
> > David, I just checked the console_init section seems ok.
> > I'm actually getting the console output correct until the
> > init() opens /dev/console.  You can take a look at  the
> > output.
>
> There is no console before init opens it...
>
> What you see during booting is just plain direct calls to
> the serial driver.
>
>
> Rick
>
>
> Richard Klingler             mail: richard.klingler at violasystems.com
> Viola Systems Ltd.           http://www.violasystems.com/
> Lemmink?isenkatu 32          phon: +358 (0)201 226 226
> 20520 Turku, Finland         mobile: +358 (0)40 748 4711
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org



From maillist at fsforth.de  Thu Mar 13 03:01:22 2003
From: maillist at fsforth.de (Markus Pietrek)
Date: Thu, 13 Mar 2003 09:01:22 +0100
Subject: [uClinux-dev] Daemonize a process
In-Reply-To: <Pine.WNT.4.44.0303121631290.258-100000@sw-55.sedsystems.ca>
References: <Pine.WNT.4.44.0303121631290.258-100000@sw-55.sedsystems.ca>
Message-ID: <200303130901.22965.maillist@fsforth.de>

Hi

> A simple way to daemonize a process:
> 	my_process&

This is not actually a daemon. What happens, if you close the terminal or 
console? As my_process belongs to the same process group as the shell 
connected to the terminal, my_process is killed, too. Even close(0-2) doesn't 
help. This doesn't happen to a daemon.

> This runs the process in the background.
> Another way is to start the process is to use /etc/inittab.

But what if you want to start the daemon only in case some drivers have been 
loaded? Or some jumpers/switches have been set?

Bye,

-- 
Markus Pietrek
FS Forth-Systeme GmbH
Phone: +49 (7667) 908 145,  FAX +49 (7667) 908 221




From cw_ni at dlink.com.tw  Thu Mar 13 03:34:34 2003
From: cw_ni at dlink.com.tw (cw_ni at dlink.com.tw)
Date: Thu, 13 Mar 2003 16:34:34 +0800
Subject: [uClinux-dev] kernel BUG at slab.c:1141!
Message-ID: <OFCA760F10.20366A4A-ON48256CE8.002E825E@dlink.com.tw>

Hello all: ^_^
   Here I got a problem with the error message "kernel BUG at slab.c:
1141!"
   I use __backtrace to trace back the source of this problem.
   It is from the call of kmalloc() in my driver.
   I am sure that  my usage of kmalloc is correct.
   What is the reason ? Please give me some suggestions about this. :p
   The kernel version I use is 2.4.17pre.
      Best regards.
            ChengWu.


From parywu at seed.net.tw  Thu Mar 13 03:56:06 2003
From: parywu at seed.net.tw (Pary WU)
Date: Thu, 13 Mar 2003 16:56:06 +0800
Subject: [uClinux-dev] arm-elf toolchain under Cygwin
Message-ID: <004801c2e93e$624a5d00$3a0aa8c0@j3.com.tw>

Dear all:
 I've built the toolchain under Cygwin 1.3.10, and it is based on the sources downloaded from uclinux.org.
Files:
binutils-2.10-full.patch
binutils-2.10.tar.bz2
build-uclinux-tools-cygwin.sh (patched by me)
elf2flt-20020731-cygwin.patch (patched by me)
elf2flt-20020731.tar.gz
gcc-2.95.3-arm-mlib.patch
gcc-2.95.3-arm-pic.patch
gcc-2.95.3-arm-pic.patch2
gcc-2.95.3-full.patch
gcc-2.95.3-sigset.patch
gcc-2.95.3.tar.gz
gdb-5.0.tar.bz2
genromfs-0.5.1.tar.gz
uClibc.tar.gz

Steps:
1) copy all files to a base directory
2) uncompress `elf2flt' and patch it:
tar xzvf elf2fl5-20020731.tar.gz
patch -p0 elf2flt-20020731-cygwin.patch
3)execute the script to build:
./build-uclinux-tools-cygwin.sh build
(this costed about 4 to 5 hours in my machine)
4)then, that's it; and you could pack the toolchain:
./build-uclinux-tools-cygwin.sh tar

I'll upload the two patch files if anyone needs it.

Sincerely.
--
Pary All Rough Yet.
parywu at seed.net.tw
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20030313/2862d720/attachment.html>

From roope.anttinen at indagon.com  Thu Mar 13 04:18:32 2003
From: roope.anttinen at indagon.com (Roope Anttinen)
Date: 13 Mar 2003 11:18:32 +0200
Subject: [uClinux-dev] Daemonize a process
In-Reply-To: <200303130901.22965.maillist@fsforth.de>
References: <Pine.WNT.4.44.0303121631290.258-100000@sw-55.sedsystems.ca> 
	<200303130901.22965.maillist@fsforth.de>
Message-ID: <1047547115.1966.2.camel@tossu>

Try something like this. Fairly standard stuff but I haven't tried this
is uClinux so it might need some modifications.

int daemonize()
{
    int fd;
    pid_t pid;

    pid = fork();

    switch (pid) {
    case -1:
        return -1;
    case 0:
        break;
    default:
        _exit(pid);
    }

    if (setsid() == -1)
        return -1;
    chdir("/");
    fd = open(_PATH_DEVNULL, O_RDWR, 0);
    if (fd != -1) {
        dup2(fd, STDIN_FILENO);
        dup2(fd, STDOUT_FILENO);
        dup2(fd, STDERR_FILENO);
        if (fd > 2)
            close(fd);
    }
    return 0;
}

/Roope

On Thu, 2003-03-13 at 10:01, Markus Pietrek wrote:
> Hi
> 
> > A simple way to daemonize a process:
> > 	my_process&
> 
> This is not actually a daemon. What happens, if you close the terminal or 
> console? As my_process belongs to the same process group as the shell 
> connected to the terminal, my_process is killed, too. Even close(0-2) doesn't 
> help. This doesn't happen to a daemon.
> 
> > This runs the process in the background.
> > Another way is to start the process is to use /etc/inittab.
> 
> But what if you want to start the daemon only in case some drivers have been 
> loaded? Or some jumpers/switches have been set?
> 
> Bye,
> 
> -- 
> Markus Pietrek
> FS Forth-Systeme GmbH
> Phone: +49 (7667) 908 145,  FAX +49 (7667) 908 221
> 
> 
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org




From roope.anttinen at indagon.com  Thu Mar 13 04:23:01 2003
From: roope.anttinen at indagon.com (Roope Anttinen)
Date: 13 Mar 2003 11:23:01 +0200
Subject: [uClinux-dev] ip masquarade support
In-Reply-To: <6E931152-54BA-11D7-ADF6-00039359F448@dartmouth.edu>
References: <6E931152-54BA-11D7-ADF6-00039359F448@dartmouth.edu>
Message-ID: <1047547388.1965.7.camel@tossu>

Tried that but it didn't help :(
I now compiled the ip-tables stuff as modules.
insmod ip_tables went ok but when inserting iptable_filter module...
BANG - kernel crashes:

*** UNASSIGNED RESERVED 12 ***   FORMAT=2
Current process id is 23
BAD KERNEL TRAP: 00000000
PC: [<00101f37>]
SR: 2035  SP: 0011bcd2  a2: 0056215c
d0: 00000000    d1: 00000000    d2: 00000000    d3: 10c7e900
d4: 00101f37    d5: 00000000    a0: 0056218c    a1: 00000000
Process telnetd (pid: 23, stackpage=0011b000)
Frame format=2 instr addr=20000010
Stack from 0011bd0a:
        018c0004 8b9010c7 e9320004 79240000 00000000 00030011 bdfc0011
bde810c7
        e9320000 00000000 00200022 00000000 00000000 00047924 00101f37
00000000
        0010d080 00000000 00000011 bdec0010 d8de0011 bdfc0000 00030000
00000004
        79240010 dcc20000 000010c7 51180000 00030011 bdfc0000 00000004
792410c7
        e9320000 00000004 79240000 00030000 00000000 00000000 00020003
67bc10c7
        53b20004 8b900011 bdfc0000 00030000 00000004 79240011 bde810c7
e9320000

On Wed, 2003-03-12 at 20:42, David E. Gelhar wrote:
> 
> On Tuesday, March 11, 2003, at 03:32 AM, Roope Anttinen wrote:
> 
> > Started all over with as stripped image as possible which does 
> > basically
> > nothing more than boots...
> 
> 
> One thing I noticed in your output  is that cs89x0_probe is "finding" 
> lots of bogus ethernet interfaces. The ioaddr of "0xFFE0" is supposed 
> to mean "don't probe". The same thing was happening to me with a 
> uCsimm; although it wasn't resulting in crashes. I don't know if this 
> is the cause of your problem, but it probably can't be good to have 
> these bogus ethernet devices running.
> 
> This appears to be caused by some added ARM code in drivers/net/Space.c 
> that always calls cs89x0_probe for eth1..eth7 (if CONFIG_CS89x0) in the 
> arch-specific probes section, while the generic isa_probes section will 
> not probe for interfaces with a base addr of 0xFFE0.
> 
> The obvious patch to that is to not call the arm-specific probes on a 
> non-ARM architecture:




From lars.segerlund at comsys.se  Thu Mar 13 04:53:57 2003
From: lars.segerlund at comsys.se (Lars Segerlund)
Date: Thu, 13 Mar 2003 10:53:57 +0100
Subject: [uClinux-dev] realtime scheduling...
Message-ID: <3E705535.5050405@comsys.se>

  I am hacking away at my small realtime scheduler which works with 
uclinux, and wanted some opinions as for if the functionality would be 
sufficient for most users that need this kind of functionality.

  Basicly it runs some stuff on the NMI and the 'heavy' tasks on linux 
regular interrupts, it can hit a 15 ns window for the code to be run ( 
first instruction ) on the MC5246C3 developement board, and most of it 
should be easily portable to other architectures and constraints, ( 
single timer, multiple timers ). ( also I have some work left on 
verifying the behaviour of sti cli in the drivers and kernel, ie. 
estimating worst case for the linux interrupt parts ).

  The main restriction is that it collects taskt to be scheduled and 
schedules these in a 'batch', after this batch has been proccessed it 
cannot schedule anything which should run before the last starting point 
of the batch, so my question is if this is acceptable ?

  Also it doesn't handle periodic scheduling of tasks, ( it's easily 
implemented though but I don't need it for now ) since I am using it for 
dynamic scheduling of prioritized realtime routines.

  does this sound ok ? or is there any part which sould be included 
before I do a first release of the code ?

  I was thinking of calling it uCRT and post it here first, if this 
would be ok with everybody ?

  Also I don't think I can commit to supporting it forever for reasons 
about employement and such, so if nothing else it would be a nice 
example if someone needs this.

  All comments welcome, and I hope this is not 'out of topic'.

  / regards, Lars Segerlund.



From s.smejkal at centerfunk.at  Thu Mar 13 05:16:16 2003
From: s.smejkal at centerfunk.at (Sascha Smejkal)
Date: Thu, 13 Mar 2003 11:16:16 +0100
Subject: [uClinux-dev] bdm driver installation failing
References: <1047485058.2882.8.camel@jcwork> <1047513447.1084.5.camel@rhianna.tmq.com.au>
Message-ID: <3E705A70.2010506@centerfunk.at>

Hi Justin!

That's exactly the behavior I've described in my mail before. I forgott to 
mention that under Windoze the parallel port behaves correctly, but under 
linux it tries to send data over the lines even after unloading all parallel 
port modules. Looks like the motherboard chip set isn't initialized correctly.

Bye Sascha

Justin Clacherty schrieb:
> I've already done this.  Originally I was having a problem where the
> driver would report that the /dev/bdmcf0 resource is busy, this was
> because the install of linux I am running had lp, parport, adn
> parport_pc running (still does from boot).  I do the rmmod after I boot
> up (haven't got around to finding out how to get it to never load).
> 
> I know it isn't a hardware issue as I tested debugging under W2K using
> the Metrowerks tools.  The interesting thing is that when I connect the
> debugger under linux, the leds on the board seem to flicker, this does
> not happen under windows, it is as though something is writing to the
> parallel port (presumably resetting the board continuously).
> 
> Justin.
> 
> On Thu, 2003-03-13 at 02:04, Jeff Carr wrote:
> 
>>Try loading and unloading the parport and lp modules before you load the
>>bdm one. 
>>
>>insmod parport
>>insmod lp
>>rmmod lp
>>rmmod parport_pc
>>rmmod parport
>>insmod bdm
>>
>>Goodluck,
>>Jeff
>>
>>On Tue, 2003-03-11 at 00:19, Justin Clacherty wrote:
>>
>>>Hi,
>>>
>>>I'm trying to set up debugging through the bdm in gdb.  I've installed
>>>the bdm driver but when I run chk /dev/bdmcf0 the driver seems to be
>>>failing to connect to the target.  I turned on debugging and it looks
>>>like it is failing when it tries to read a register on the target. 
>>>Below is the command I am using and its output, along with the
>>
>>relevant
>>
>>>output in /var/log/messages.  I'm using the P&E Micro wiggler that
>>
>>came
>>
>>>with our Motorola M5272C3 development board.  Does anyone know what I
>>>might be doing wrong?
>>>
>>>The commands I'm using with the output...
>>>
>>>[justin at rhianna test]$ ./chk -d 4 /dev/bdmcf0
>>>Driver Ver : 2.a
>>>Processor  : Coldfire
>>>Interface  : P&E Coldfire
>>>Reading CSR failed: Invalid target command
>>>[justin at rhianna test]$
>>>
>>>/var/log/messages
>>>
>>>Mar 11 15:57:32 rhianna kernel:  cf_pe_read_sysreg - Reg:0xf failed
>>
>>with
>>
>>>cmd 0x2d80, err = 217
>>>Mar 11 15:57:32 rhianna kernel: debugFlag now 4
>>>Mar 11 15:57:32 rhianna kernel: BDMioctl cmd:0x8004421e
>>>Mar 11 15:57:32 rhianna kernel: BDMioctl cmd:0x8004421f
>>>Mar 11 15:57:32 rhianna kernel: BDMioctl cmd:0x80044220
>>>Mar 11 15:57:32 rhianna kernel: BDMioctl cmd:0x4201
>>>Mar 11 15:57:32 rhianna kernel:  cf_pe_reset_chip
>>>Mar 11 15:57:33 rhianna kernel: BDMioctl cmd:0xc0084215
>>>Mar 11 15:57:33 rhianna kernel:  cf_pe_get_direct_status --
>>
>>Status:0x0,
>>
>>>sr:0x7e
>>>Mar 11 15:57:33 rhianna kernel:  cf_pe_serial_clock -- send 0x2d80 
>>>receive 0x1ffff
>>>Mar 11 15:57:33 rhianna kernel:  cf_pe_serial_clock -- failure NVC,
>>
>>send
>>
>>>0x2d80 receive 0x1ffff
>>>Mar 11 15:57:33 rhianna kernel:  cf_pe_read_sysreg - Reg:0xf failed
>>
>>with
>>
>>>cmd 0x2d80, err = 217
>>>Mar 11 15:57:33 rhianna kernel: BDMioctl cmd:0x40044207
>>>Mar 11 15:57:33 rhianna kernel: debugFlag now 0
>>>
>>>
>>>Regards,
>>>Justin.
>>>
>>>
>>>_______________________________________________
>>>uClinux-dev mailing list
>>>uClinux-dev at uclinux.org
>>>http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
>>>This message was resent by uclinux-dev at uclinux.org
>>>
>>
> 
> 
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org




From davidm at snapgear.com  Thu Mar 13 05:36:51 2003
From: davidm at snapgear.com (David McCullough)
Date: Thu, 13 Mar 2003 20:36:51 +1000
Subject: [uClinux-dev] kernel BUG at slab.c:1141!
In-Reply-To: <OFCA760F10.20366A4A-ON48256CE8.002E825E@dlink.com.tw>
References: <OFCA760F10.20366A4A-ON48256CE8.002E825E@dlink.com.tw>
Message-ID: <20030313103651.GB17803@beast.internal.moreton.com.au>

Jivin cw_ni at dlink.com.tw lays it down ...
> 
> Hello all: ^_^
>    Here I got a problem with the error message "kernel BUG at slab.c:
> 1141!"
>    I use __backtrace to trace back the source of this problem.
>    It is from the call of kmalloc() in my driver.
>    I am sure that  my usage of kmalloc is correct.
>    What is the reason ? Please give me some suggestions about this. :p
>    The kernel version I use is 2.4.17pre.

Most likely memory corruption or an incorrectly setup memory map, look
at why you get the BUG error,  then work out which part got corrupted.
Once you have that you may see a pattern or be able to break point on
changes to that address and find the error,

Cheers,
Davidm

-- 
David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
davidm at snapgear.com  Fx: +61 7 3891 3630  Custom Embedded Solutions + Security


From schaeferd at gmx.de  Thu Mar 13 07:25:53 2003
From: schaeferd at gmx.de (Dirk Schaefer)
Date: Thu, 13 Mar 2003 13:25:53 +0100
Subject: [uClinux-dev] IXP225 (ARM7TDMI core) problem.
Message-ID: <20030313132553.C16190@janus.hrz.tu-chemnitz.de>

Hello!

As a student I have get kernel 2.4 working on an embedded system with a IXP225. As a first step I tried to run a normal binary under 2.2. The problem is now, after compiling and linking it to uclibc 0.9.19 the binary does not seem to produce any output (a simple "hello world" program). Now I tried to get the gdbserver (gdb 5.3) working to see what is wrong but I was not able to compile it. So does anybody have a working gdbserver binary (flatted) which I could use? It would be a big help finding out what is going on. 

And a second question: I had a look to the uclinux distribution. But I can not find any support for ARM7TDMI. Is there any support for this platform (on uclinux.org I only found support for 2.2) because I don't want to invent the wheel twice...

Thanks 
Dirk Schaefer


From bkuhn at metrowerks.com  Thu Mar 13 07:33:50 2003
From: bkuhn at metrowerks.com (Bernhard Kuhn)
Date: Thu, 13 Mar 2003 13:33:50 +0100
Subject: [uClinux-dev] uclinux and RTLinux / RTAI
References: <3E6FF7DC.7090708@itee.uq.edu.au>
Message-ID: <3E707AAE.8090908@metrowerks.com>

John Williams wrote:

> The uClinux mailing list archive has some discussions from Bernard Kuhn 
> about impending release of RTLinux for a later kernel version, but I 
> never saw any more on it.

RTAI for Coldfire (5272) has been integrated into the official
RTAI-24.1.10 tree.

Some older versions and application notes can be found at:

http://www.uclinux.org/~bkuhn/Platforms/Coldfire/tarifa/20020227/README
http://www.uclinux.org/~bkuhn/Platforms/Coldfire/tarifa/20020413/README

Bernhard



From maillist at fsforth.de  Thu Mar 13 08:01:48 2003
From: maillist at fsforth.de (Markus Pietrek)
Date: Thu, 13 Mar 2003 14:01:48 +0100
Subject: [uClinux-dev] Daemonize a process
In-Reply-To: <1047547115.1966.2.camel@tossu>
References: <Pine.WNT.4.44.0303121631290.258-100000@sw-55.sedsystems.ca> <200303130901.22965.maillist@fsforth.de> <1047547115.1966.2.camel@tossu>
Message-ID: <200303131401.48557.maillist@fsforth.de>

Hi Roope,

> Try something like this. Fairly standard stuff but I haven't tried this
> is uClinux so it might need some modifications.

Thanks for your answer. I'm sorry, but I should have emphasized only the issue 
that background processes are not the same as daemons and where the caveats 
are (as I'm aware of them - sometimes I'm just too quick with the send 
button).

But all googlers will be happy about your answer, won't they? :-)

Bye,

-- 
Markus Pietrek
FS Forth-Systeme GmbH
Phone: +49 (7667) 908 145,  FAX +49 (7667) 908 221




From maillist at fsforth.de  Thu Mar 13 08:05:24 2003
From: maillist at fsforth.de (Markus Pietrek)
Date: Thu, 13 Mar 2003 14:05:24 +0100
Subject: [uClinux-dev] "wrong zone alignment" warning and &_end_kernel in 2.4.20
In-Reply-To: <1047466764.1941.32.camel@localhost>
References: <200303121150.02036.maillist@fsforth.de> <1047466764.1941.32.camel@localhost>
Message-ID: <200303131405.24723.maillist@fsforth.de>

Hi Ben,

> I had the same problem when PAGE_OFFSET was (incorrectly :) set to
> _end_kernel.  It should really be set to the start of your ram.  The
> kernel automatically reserves the kernel address space during startup.
>
> If you have other "special" regions of memory to reserve take a look at
> reserve_node_zero in arch/armnommu/mm/init.c.  I use that function to
> reserve the first 8k for remapping to 0x0 for the interrupt vectors &
> handlers.

Thanks, that was it. Modifying PAGE_OFFSET and PHYS_OFFSET to be 0x0, 
adjusting the linker script and ensuring that _end is still the _end of the 
kernel and reserving the bootloader code from 0-_stext.

Best regards,

-- 
Markus Pietrek
FS Forth-Systeme GmbH
Phone: +49 (7667) 908 145,  FAX +49 (7667) 908 221




From philwil at earthlink.net  Thu Mar 13 08:31:04 2003
From: philwil at earthlink.net (Phil Wilshire)
Date: Thu, 13 Mar 2003 08:31:04 -0500
Subject: [uClinux-dev] ip masquarade support
References: <6E931152-54BA-11D7-ADF6-00039359F448@dartmouth.edu> <1047547388.1965.7.camel@tossu>
Message-ID: <3E708817.7EB1BCC9@earthlink.net>

Hi Roope,
Sorry that you are having some difficulties here.

One ppossible reason for the insmod crash is the need for more stack space in the insmod program.
try 
flthdr -s 20000 insmod ( or busybox)

best regards
  Phil Wilshire



Roope Anttinen wrote:
> 
> Tried that but it didn't help :(
> I now compiled the ip-tables stuff as modules.
> insmod ip_tables went ok but when inserting iptable_filter module...
> BANG - kernel crashes:
> 
> *** UNASSIGNED RESERVED 12 ***   FORMAT=2
> Current process id is 23
> BAD KERNEL TRAP: 00000000
> PC: [<00101f37>]
> SR: 2035  SP: 0011bcd2  a2: 0056215c
> d0: 00000000    d1: 00000000    d2: 00000000    d3: 10c7e900
> d4: 00101f37    d5: 00000000    a0: 0056218c    a1: 00000000
> Process telnetd (pid: 23, stackpage=0011b000)
> Frame format=2 instr addr=20000010
> Stack from 0011bd0a:
>         018c0004 8b9010c7 e9320004 79240000 00000000 00030011 bdfc0011
> bde810c7
>         e9320000 00000000 00200022 00000000 00000000 00047924 00101f37
> 00000000
>         0010d080 00000000 00000011 bdec0010 d8de0011 bdfc0000 00030000
> 00000004
>         79240010 dcc20000 000010c7 51180000 00030011 bdfc0000 00000004
> 792410c7
>         e9320000 00000004 79240000 00030000 00000000 00000000 00020003
> 67bc10c7
>         53b20004 8b900011 bdfc0000 00030000 00000004 79240011 bde810c7
> e9320000
> 
> On Wed, 2003-03-12 at 20:42, David E. Gelhar wrote:
> >
> > On Tuesday, March 11, 2003, at 03:32 AM, Roope Anttinen wrote:
> >
> > > Started all over with as stripped image as possible which does
> > > basically
> > > nothing more than boots...
> >
> >
> > One thing I noticed in your output  is that cs89x0_probe is "finding"
> > lots of bogus ethernet interfaces. The ioaddr of "0xFFE0" is supposed
> > to mean "don't probe". The same thing was happening to me with a
> > uCsimm; although it wasn't resulting in crashes. I don't know if this
> > is the cause of your problem, but it probably can't be good to have
> > these bogus ethernet devices running.
> >
> > This appears to be caused by some added ARM code in drivers/net/Space.c
> > that always calls cs89x0_probe for eth1..eth7 (if CONFIG_CS89x0) in the
> > arch-specific probes section, while the generic isa_probes section will
> > not probe for interfaces with a base addr of 0xFFE0.
> >
> > The obvious patch to that is to not call the arm-specific probes on a
> > non-ARM architecture:
> 
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org

-- 
SDCS -- System Design & Consulting Services LLC, http://www.sysdcs.com
** Embedded Linux Training **  email me for details  
630 Springhouse Sq., Leesburg VA 20175 t: 703 669 9766 f: 703 669 9768


From hamilton at sedsystems.ca  Thu Mar 13 09:25:13 2003
From: hamilton at sedsystems.ca (Kendrick Hamilton)
Date: Thu, 13 Mar 2003 08:25:13 -0600 (Canada Central Standard Time)
Subject: [uClinux-dev] Daemonize a process
In-Reply-To: <200303130901.22965.maillist@fsforth.de>
Message-ID: <Pine.WNT.4.44.0303130821050.253-100000@sw-55.sedsystems.ca>

If I remember correctly, the reason why your process is killed is because
it recevies a signal (hang up I think). The default hang up signal action
for a process is to abort the process. You can change the signal handler
so it ignores the hang up signal. There may be a few other signal handlers
you may need to alter. Look at man 7 signal.
Kendrick


On Thu, 13 Mar 2003, Markus Pietrek wrote:

> Hi
>
> > A simple way to daemonize a process:
> > 	my_process&
>
> This is not actually a daemon. What happens, if you close the terminal or
> console? As my_process belongs to the same process group as the shell
> connected to the terminal, my_process is killed, too. Even close(0-2) doesn't
> help. This doesn't happen to a daemon.
>
> > This runs the process in the background.
> > Another way is to start the process is to use /etc/inittab.
>
> But what if you want to start the daemon only in case some drivers have been
> loaded? Or some jumpers/switches have been set?
>
> Bye,
>
> --
> Markus Pietrek
> FS Forth-Systeme GmbH
> Phone: +49 (7667) 908 145,  FAX +49 (7667) 908 221
>
>
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org
>



From roope.anttinen at indagon.com  Thu Mar 13 09:40:33 2003
From: roope.anttinen at indagon.com (Roope Anttinen)
Date: 13 Mar 2003 16:40:33 +0200
Subject: [uClinux-dev] ip masquarade support
In-Reply-To: <3E708817.7EB1BCC9@earthlink.net>
References: <6E931152-54BA-11D7-ADF6-00039359F448@dartmouth.edu>
	<1047547388.1965.7.camel@tossu>  <3E708817.7EB1BCC9@earthlink.net>
Message-ID: <1047566436.1965.15.camel@tossu>

It does the same thing even without insmod (if that ip-filter stuff is
compiled in the kernel).. stays up fine until I plug in the ethernet
cable so it receives the first packet -> CRASH

On Thu, 2003-03-13 at 15:31, Phil Wilshire wrote:
> Hi Roope,
> Sorry that you are having some difficulties here.
> 
> One ppossible reason for the insmod crash is the need for more stack space in the insmod program.
> try 
> flthdr -s 20000 insmod ( or busybox)
> 
> best regards
>   Phil Wilshire
> 
> 
> 
> Roope Anttinen wrote:
> > 
> > Tried that but it didn't help :(
> > I now compiled the ip-tables stuff as modules.
> > insmod ip_tables went ok but when inserting iptable_filter module...
> > BANG - kernel crashes:
> > 
> > *** UNASSIGNED RESERVED 12 ***   FORMAT=2
> > Current process id is 23
> > BAD KERNEL TRAP: 00000000
> > PC: [<00101f37>]
> > SR: 2035  SP: 0011bcd2  a2: 0056215c
> > d0: 00000000    d1: 00000000    d2: 00000000    d3: 10c7e900
> > d4: 00101f37    d5: 00000000    a0: 0056218c    a1: 00000000
> > Process telnetd (pid: 23, stackpage=0011b000)
> > Frame format=2 instr addr=20000010
> > Stack from 0011bd0a:
> >         018c0004 8b9010c7 e9320004 79240000 00000000 00030011 bdfc0011
> > bde810c7
> >         e9320000 00000000 00200022 00000000 00000000 00047924 00101f37
> > 00000000
> >         0010d080 00000000 00000011 bdec0010 d8de0011 bdfc0000 00030000
> > 00000004
> >         79240010 dcc20000 000010c7 51180000 00030011 bdfc0000 00000004
> > 792410c7
> >         e9320000 00000004 79240000 00030000 00000000 00000000 00020003
> > 67bc10c7
> >         53b20004 8b900011 bdfc0000 00030000 00000004 79240011 bde810c7
> > e9320000
> > 
> > On Wed, 2003-03-12 at 20:42, David E. Gelhar wrote:
> > >
> > > On Tuesday, March 11, 2003, at 03:32 AM, Roope Anttinen wrote:
> > >
> > > > Started all over with as stripped image as possible which does
> > > > basically
> > > > nothing more than boots...
> > >
> > >
> > > One thing I noticed in your output  is that cs89x0_probe is "finding"
> > > lots of bogus ethernet interfaces. The ioaddr of "0xFFE0" is supposed
> > > to mean "don't probe". The same thing was happening to me with a
> > > uCsimm; although it wasn't resulting in crashes. I don't know if this
> > > is the cause of your problem, but it probably can't be good to have
> > > these bogus ethernet devices running.
> > >
> > > This appears to be caused by some added ARM code in drivers/net/Space.c
> > > that always calls cs89x0_probe for eth1..eth7 (if CONFIG_CS89x0) in the
> > > arch-specific probes section, while the generic isa_probes section will
> > > not probe for interfaces with a base addr of 0xFFE0.
> > >
> > > The obvious patch to that is to not call the arm-specific probes on a
> > > non-ARM architecture:
> > 
> > _______________________________________________
> > uClinux-dev mailing list
> > uClinux-dev at uclinux.org
> > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> > This message was resent by uclinux-dev at uclinux.org
> 
> -- 
> SDCS -- System Design & Consulting Services LLC, http://www.sysdcs.com
> ** Embedded Linux Training **  email me for details  
> 630 Springhouse Sq., Leesburg VA 20175 t: 703 669 9766 f: 703 669 9768
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org




From stuartm at connecttech.com  Thu Mar 13 10:24:38 2003
From: stuartm at connecttech.com (Stuart MacDonald)
Date: Thu, 13 Mar 2003 10:24:38 -0500
Subject: [uClinux-dev] Daemonize a process
References: <Pine.WNT.4.44.0303121631290.258-100000@sw-55.sedsystems.ca>
Message-ID: <029b01c2e974$a97fd340$294b82ce@connecttech.com>

From: "Kendrick Hamilton" <hamilton at sedsystems.ca>
> A simple way to daemonize a process:
> my_process&
> This runs the process in the background.

As pointed out elsethread, that is a background process not a daemon.
Logging out kills a background process, but not a daemon.

> Another way is to start the process is to use /etc/inittab.

*If* starting from inittab is useful. In some cases it's not. I want
to be able to run a daemon on demand from the command line.

Thanks for the response.

..Stu




From stuartm at connecttech.com  Thu Mar 13 10:26:25 2003
From: stuartm at connecttech.com (Stuart MacDonald)
Date: Thu, 13 Mar 2003 10:26:25 -0500
Subject: [uClinux-dev] Daemonize a process
References: <025801c2e8e6$c2fd56a0$294b82ce@connecttech.com> <20030312230211.GB16830@beast.internal.moreton.com.au>
Message-ID: <02a101c2e974$e95f24c0$294b82ce@connecttech.com>

From: "David McCullough" <davidm at snapgear.com>
> There are a couple of ways to achieve this:
> * have init start your daemon

Not general enough. I need to be able to do this from the command
line.

> * have your daemon exec itself with a special option to become a daemon.

The "special option" involves exactly the code I talk about in my
original post; the code that uses fork that doesn't work on uClinux.

> fork on uClinux is not possible.  It gives a short term impression of
> working, before your system dies horribly.  It cannot be fixed in any
> practical way and you can find all the reasons why in the uClinux-dev
> archives :-)

I'll have a look at the archives. I'd searched them for info on
daemonising, but not on fixing fork.

..Stu




From stuartm at connecttech.com  Thu Mar 13 10:34:46 2003
From: stuartm at connecttech.com (Stuart MacDonald)
Date: Thu, 13 Mar 2003 10:34:46 -0500
Subject: [uClinux-dev] Daemonize a process
References: <004701c2e8f1$54590e00$660ba8c0@robertd>
Message-ID: <02a701c2e976$13f17840$294b82ce@connecttech.com>

From: "Robert Daniels" <robertd at vantagecontrols.com>
> You might want to check the code for smbmount for an example of an
> application that does the daemonize thing.  It's under
> user/samba/source/client/smbmount.c.  It was modified to not call its
> own daemonize function and instead, it will go into a loop where it will
> kill its parent (most likely your shell) and keep running.  It's a

I just now looked at that. The standard daemonise sequence is
#ifndef EMBED, and the vfork sequence execve's smbmnt. This is likely
the code path I'll have to use, but I don't see where it kills off its
parent process.

> if this will work in your situation or not.  I modified this code to use
> a goofy version of daemonize in which I use vfork and execv to spawn off
> a daemon process.  The trick here is to make sure you don't recursively
> daemonize, which I accomplished by snooping the /proc filesystem.

I also don't see the snooping. Could you point out line #s? I'm using
uClinux-dist-20020927 ATM, but also have -20030305 handy.

..Stu




From stuartm at connecttech.com  Thu Mar 13 10:38:59 2003
From: stuartm at connecttech.com (Stuart MacDonald)
Date: Thu, 13 Mar 2003 10:38:59 -0500
Subject: [uClinux-dev] Daemonize a process
References: <Pine.WNT.4.44.0303121631290.258-100000@sw-55.sedsystems.ca> <200303130901.22965.maillist@fsforth.de> <1047547115.1966.2.camel@tossu>
Message-ID: <02af01c2e976$aaabe540$294b82ce@connecttech.com>

From: "Roope Anttinen" <roope.anttinen at indagon.com>
> Try something like this. Fairly standard stuff but I haven't tried this
> is uClinux so it might need some modifications.

As I mentioned in my original post, this does not work properly.

> int daemonize()
> {
>     int fd;
>     pid_t pid;
>
>     pid = fork();
>
>     switch (pid) {
>     case -1:
>         return -1;
>     case 0:

The child runs, gets to this line and continues with the setsid below.

>         break;
>     default:

The parent is blocked waiting for the child to _exit() or execve(),
and does not reach the line below until that happens. This leaves the
parent process in the D state, and AFAICanTell, also does not detach
the daemon from the controlling tty, meaning that when one logs out,
the process is killed.

>         _exit(pid);
>     }
>
>     if (setsid() == -1)
>         return -1;
>     chdir("/");
>     fd = open(_PATH_DEVNULL, O_RDWR, 0);
>     if (fd != -1) {
>         dup2(fd, STDIN_FILENO);
>         dup2(fd, STDOUT_FILENO);
>         dup2(fd, STDERR_FILENO);
>         if (fd > 2)
>             close(fd);
>     }
>     return 0;
> }

..Stu




From tchen at on-go.com  Thu Mar 13 10:38:43 2003
From: tchen at on-go.com (thomas chen)
Date: Thu, 13 Mar 2003 10:38:43 -0500
Subject: [uClinux-dev] ip masquarade support
References: <6E931152-54BA-11D7-ADF6-00039359F448@dartmouth.edu>
		<1047547388.1965.7.camel@tossu>  <3E708817.7EB1BCC9@earthlink.net> <1047566436.1965.15.camel@tossu>
Message-ID: <3E70A603.AA107ECE@on-go.com>

does it work fine if you boot the system with cable in and can you 
access the network?



Roope Anttinen wrote:
> 
> It does the same thing even without insmod (if that ip-filter stuff is
> compiled in the kernel).. stays up fine until I plug in the ethernet
> cable so it receives the first packet -> CRASH
> 
> On Thu, 2003-03-13 at 15:31, Phil Wilshire wrote:
> > Hi Roope,
> > Sorry that you are having some difficulties here.
> >
> > One ppossible reason for the insmod crash is the need for more stack space in the insmod program.
> > try
> > flthdr -s 20000 insmod ( or busybox)
> >
> > best regards
> >   Phil Wilshire
> >
> >
> >
> > Roope Anttinen wrote:
> > >
> > > Tried that but it didn't help :(
> > > I now compiled the ip-tables stuff as modules.
> > > insmod ip_tables went ok but when inserting iptable_filter module...
> > > BANG - kernel crashes:
> > >
> > > *** UNASSIGNED RESERVED 12 ***   FORMAT=2
> > > Current process id is 23
> > > BAD KERNEL TRAP: 00000000
> > > PC: [<00101f37>]
> > > SR: 2035  SP: 0011bcd2  a2: 0056215c
> > > d0: 00000000    d1: 00000000    d2: 00000000    d3: 10c7e900
> > > d4: 00101f37    d5: 00000000    a0: 0056218c    a1: 00000000
> > > Process telnetd (pid: 23, stackpage=0011b000)
> > > Frame format=2 instr addr=20000010
> > > Stack from 0011bd0a:
> > >         018c0004 8b9010c7 e9320004 79240000 00000000 00030011 bdfc0011
> > > bde810c7
> > >         e9320000 00000000 00200022 00000000 00000000 00047924 00101f37
> > > 00000000
> > >         0010d080 00000000 00000011 bdec0010 d8de0011 bdfc0000 00030000
> > > 00000004
> > >         79240010 dcc20000 000010c7 51180000 00030011 bdfc0000 00000004
> > > 792410c7
> > >         e9320000 00000004 79240000 00030000 00000000 00000000 00020003
> > > 67bc10c7
> > >         53b20004 8b900011 bdfc0000 00030000 00000004 79240011 bde810c7
> > > e9320000
> > >
> > > On Wed, 2003-03-12 at 20:42, David E. Gelhar wrote:
> > > >
> > > > On Tuesday, March 11, 2003, at 03:32 AM, Roope Anttinen wrote:
> > > >
> > > > > Started all over with as stripped image as possible which does
> > > > > basically
> > > > > nothing more than boots...
> > > >
> > > >
> > > > One thing I noticed in your output  is that cs89x0_probe is "finding"
> > > > lots of bogus ethernet interfaces. The ioaddr of "0xFFE0" is supposed
> > > > to mean "don't probe". The same thing was happening to me with a
> > > > uCsimm; although it wasn't resulting in crashes. I don't know if this
> > > > is the cause of your problem, but it probably can't be good to have
> > > > these bogus ethernet devices running.
> > > >
> > > > This appears to be caused by some added ARM code in drivers/net/Space.c
> > > > that always calls cs89x0_probe for eth1..eth7 (if CONFIG_CS89x0) in the
> > > > arch-specific probes section, while the generic isa_probes section will
> > > > not probe for interfaces with a base addr of 0xFFE0.
> > > >
> > > > The obvious patch to that is to not call the arm-specific probes on a
> > > > non-ARM architecture:
> > >
> > > _______________________________________________
> > > uClinux-dev mailing list
> > > uClinux-dev at uclinux.org
> > > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> > > This message was resent by uclinux-dev at uclinux.org
> >
> > --
> > SDCS -- System Design & Consulting Services LLC, http://www.sysdcs.com
> > ** Embedded Linux Training **  email me for details
> > 630 Springhouse Sq., Leesburg VA 20175 t: 703 669 9766 f: 703 669 9768
> > _______________________________________________
> > uClinux-dev mailing list
> > uClinux-dev at uclinux.org
> > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> > This message was resent by uclinux-dev at uclinux.org
> 
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org


From stuartm at connecttech.com  Thu Mar 13 10:43:32 2003
From: stuartm at connecttech.com (Stuart MacDonald)
Date: Thu, 13 Mar 2003 10:43:32 -0500
Subject: [uClinux-dev] Daemonize a process
References: <Pine.WNT.4.44.0303130821050.253-100000@sw-55.sedsystems.ca>
Message-ID: <02b701c2e977$4d9b5240$294b82ce@connecttech.com>

From: "Kendrick Hamilton" <hamilton at sedsystems.ca>
> If I remember correctly, the reason why your process is killed is because
> it recevies a signal (hang up I think). The default hang up signal action
> for a process is to abort the process. You can change the signal handler
> so it ignores the hang up signal. There may be a few other signal handlers
> you may need to alter. Look at man 7 signal.

A process dies when you log out because all processes under your
shell are killed as part of the death of the shell. Ignoring signals,
or attempting to handle them does not change this fact.

I believe the actual sequence is the process gets a SIGTERM and then
a SIGKILL. KILL is not catchable or ignorable.

In any case, this is why daemonisation is handy; it severs the
connection between the process and your shell, often reparenting
itself so that init is its parent instead. When you log out, the
process is no longer part of your shell's children/process group, and
is not sent SIGTERM/KILL.

..Stu




From roope.anttinen at indagon.com  Thu Mar 13 11:12:44 2003
From: roope.anttinen at indagon.com (Roope Anttinen)
Date: 13 Mar 2003 18:12:44 +0200
Subject: [uClinux-dev] Daemonize a process
In-Reply-To: <02a101c2e974$e95f24c0$294b82ce@connecttech.com>
References: <025801c2e8e6$c2fd56a0$294b82ce@connecttech.com>
	<20030312230211.GB16830@beast.internal.moreton.com.au> 
	<02a101c2e974$e95f24c0$294b82ce@connecttech.com>
Message-ID: <1047571967.1966.17.camel@tossu>

I believe you can use the code snipped I posted with just replacing the
fork call there with vfork

/Roope

On Thu, 2003-03-13 at 17:26, Stuart MacDonald wrote:
> From: "David McCullough" <davidm at snapgear.com>
> > There are a couple of ways to achieve this:
> > * have init start your daemon
> 
> Not general enough. I need to be able to do this from the command
> line.
> 
> > * have your daemon exec itself with a special option to become a daemon.
> 
> The "special option" involves exactly the code I talk about in my
> original post; the code that uses fork that doesn't work on uClinux.
> 
> > fork on uClinux is not possible.  It gives a short term impression of
> > working, before your system dies horribly.  It cannot be fixed in any
> > practical way and you can find all the reasons why in the uClinux-dev
> > archives :-)
> 
> I'll have a look at the archives. I'd searched them for info on
> daemonising, but not on fixing fork.
> 
> ..Stu
> 
> 
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org




From robertd at vantagecontrols.com  Thu Mar 13 11:23:26 2003
From: robertd at vantagecontrols.com (Robert Daniels)
Date: Thu, 13 Mar 2003 09:23:26 -0700
Subject: [uClinux-dev] Daemonize a process
In-Reply-To: <02a701c2e976$13f17840$294b82ce@connecttech.com>
Message-ID: <004d01c2e97c$e3d83890$660ba8c0@robertd>

Yeah, I never submitted my "fixes" to this since what is there works.
I'll just attach my version of smbmount.c and you can check it out.
This version has my own version of daemonize which seems to work fine
for smbmount, and could maybe be adapted to your use.  It is dependant
on the /proc file system which might not be good, and it seems that it
could use argv[0] instead of a hardcoded "/smbmount" or "smbmount".
Since this is based on vfork, it's tough to just put it anywhere in your
code since it runs your program again starting from the beginning,
but... better than nothing maybe.

Robert Daniels

-----Original Message-----
From: uclinux-dev-admin at uclinux.org
[mailto:uclinux-dev-admin at uclinux.org] On Behalf Of Stuart MacDonald
Sent: Thursday, March 13, 2003 8:35 AM
To: uclinux-dev at uclinux.org
Subject: Re: [uClinux-dev] Daemonize a process

From: "Robert Daniels" <robertd at vantagecontrols.com>
> You might want to check the code for smbmount for an example of an
> application that does the daemonize thing.  It's under
> user/samba/source/client/smbmount.c.  It was modified to not call its
> own daemonize function and instead, it will go into a loop where it
will
> kill its parent (most likely your shell) and keep running.  It's a

I just now looked at that. The standard daemonise sequence is
#ifndef EMBED, and the vfork sequence execve's smbmnt. This is likely
the code path I'll have to use, but I don't see where it kills off its
parent process.

> if this will work in your situation or not.  I modified this code to
use
> a goofy version of daemonize in which I use vfork and execv to spawn
off
> a daemon process.  The trick here is to make sure you don't
recursively
> daemonize, which I accomplished by snooping the /proc filesystem.

I also don't see the snooping. Could you point out line #s? I'm using
uClinux-dist-20020927 ATM, but also have -20030305 handy.

..Stu


_______________________________________________
uClinux-dev mailing list
uClinux-dev at uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev at uclinux.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smbmount.c
Type: application/octet-stream
Size: 18516 bytes
Desc: not available
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20030313/c9fe6f7e/attachment.obj>

From mikes at tbc.net  Thu Mar 13 11:55:49 2003
From: mikes at tbc.net (Michael F. Sharp)
Date: Thu, 13 Mar 2003 10:55:49 -0600
Subject: [uClinux-dev] uClinux for Palm IIIc - Palmloader Analysis
References: <3E6B902E.7000103@tbc.net>
Message-ID: <3E70B815.1080007@tbc.net>

Hi all,
In my relentless pursuit to get uClinux to boot on my Palm IIIc, I have 
made yet more discoveries. I put in some comments to Palmloader.c, and 
got as far as "Booting code..." Beyond that point, the PDA freezes. I 
wait at least 2 minutes before resets as well. Below is the code... if 
anybody can suggest a value for jmp, I'll give it a try.

Also, interesting note: Though the Palm IIIc is claimed to have 2M ROM, 
and 8M RAM, only 7.7M are avilable in RAM. So, I adjusted my values in 
PalmLoader.c, (see 0x75cff0 ( 7.7M - 16 )) crt0_ram.S, and ram.ld (see 
0x0075d000 ( 7.7M ))  accordingly. I'll just post the changes, no sense 
in uploading what we already know ;-)

Cheers,
Mike

**** /uClinux-dist/vendors/3com/palm-loader/PalmLoader.c: (Start line 
118 ) ****

printf("%d pages in 0x%.6lx bytes\n",i,(long)i*(long)4096);
printf("Ordering image pages...\n");
asm volatile ("movew #0x069d, 0xfffff116");
asm volatile ("movew #0x2700, %sr");
printf("Done...\n"); <--- Added comment
ptr = (void *)0;
for (i=0; blk[i]; i++) {
   for (j=i+1; blk[j]; j++) {
     if (blk[j] < blk[i]) {
       /* wrong order... swap */
       MC(tmp, blk[j], 4096);
       MC(blk[j], blk[i], 4096);
       MC(blk[i], tmp, 4096);
       ptr = blk[j];
       blk[j] = blk[i];
       blk[i] = ptr;
     }
   }
}
// printf("Done\n"); <--- Added comment

/* Ok!  Ints off, move the boot code to 0x400 and jump */
printf("Booting Code...\n"); <--- Added comment
asm volatile ("movew #0x2700, %sr; moveal #0x75cff0, %ssp");
printf("movew #0x2700...\n"); <---- Never make it to here...
asm volatile ("movew #0x069d, 0xfffff116");
printf("movew #0x069d... Booting done?...\n"); <--- Added comment
MC((void *)0x400, blk[0], 4096);
MC((void *)0x000, (void *) blk, 1024);
printf("jmp 0x800 next...\n"); <--- Added comment
asm volatile ("movel #0, %a0; jmp 0x800");
printf("Building Forms...\n"); <--- Added comment
}

**** 
/uClinux-dist/linux-2.0.x/arch/m68knommu/platform/68EZ328/PalmV/crt0_ram.S: 
(Start line 116 ) ****

#endif

	DEBUG('B');

	moveal	#0x007ffff0, %ssp
	move.l #0x0075d000, %a0
	move.l  %a0, _ramend
	moveal	#__bss_start, %a0
	moveal	#__bss_end, %a1

	/* Copy 0 to %a0 until %a0 >= %a1 */

**** 
/uClinux-dist/linux-2.0.x/arch/m68knommu/platform/68EZ328/PalmV/ram.ld 
(Start line 1 ) ****

MEMORY
	{
	romvec : ORIGIN = 0x10c10000, LENGTH = 0x00000400
	flash  : ORIGIN = 0x10c10400, LENGTH = 0x00200000 - 0x00010400
	eflash : ORIGIN = 0x10e00000, LENGTH = 0
	ramvec : ORIGIN = 0x00000000, LENGTH = 0x00000400
	bvec   : ORIGIN = 0x00000400, LENGTH = 0x00000400
	ram    : ORIGIN = 0x00000800, LENGTH = 0x0075d000 - 0x00000800
	eram   : ORIGIN = 0x0075d000, LENGTH = 0
	}



From stuartm at connecttech.com  Thu Mar 13 12:33:50 2003
From: stuartm at connecttech.com (Stuart MacDonald)
Date: Thu, 13 Mar 2003 12:33:50 -0500
Subject: [uClinux-dev] Daemonize a process
References: <004d01c2e97c$e3d83890$660ba8c0@robertd>
Message-ID: <030201c2e986$b5e57b00$294b82ce@connecttech.com>

From: "Robert Daniels" <robertd at vantagecontrols.com>
> Yeah, I never submitted my "fixes" to this since what is there works.
> I'll just attach my version of smbmount.c and you can check it out.
> This version has my own version of daemonize which seems to work fine
> for smbmount, and could maybe be adapted to your use.  It is dependant
> on the /proc file system which might not be good, and it seems that it
> could use argv[0] instead of a hardcoded "/smbmount" or "smbmount".
> Since this is based on vfork, it's tough to just put it anywhere in your
> code since it runs your program again starting from the beginning,
> but... better than nothing maybe.

Nifty. I'd thought of writing the daemon as a recursive app but I'd
been thinking the stopping condition would be passed as argv[1]; the
/proc snooping is an interesting twist.

Fortunately for me the code that wants to be forked is already fairly
separated out; it's faster and easier for me to chop up the daemon
into a few smaller apps and use vfork(); execve(); instead.

..Stu




From andersen at codepoet.org  Thu Mar 13 12:41:03 2003
From: andersen at codepoet.org (Erik Andersen)
Date: Thu, 13 Mar 2003 10:41:03 -0700
Subject: [uClinux-dev] Daemonize a process
In-Reply-To: <1047547115.1966.2.camel@tossu>
References: <Pine.WNT.4.44.0303121631290.258-100000@sw-55.sedsystems.ca> <200303130901.22965.maillist@fsforth.de> <1047547115.1966.2.camel@tossu>
Message-ID: <20030313174102.GA16028@codepoet.org>

On Thu Mar 13, 2003 at 11:18:32AM +0200, Roope Anttinen wrote:
> Try something like this. Fairly standard stuff but I haven't tried this
> is uClinux so it might need some modifications.
> 
> int daemonize()
> {
>     int fd;
>     pid_t pid;
> 
>     pid = fork();

You cannot use fork() under uClinux.

 -Erik

--
Erik B. Andersen             http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--


From mparker at TheRNDGroup.com  Thu Mar 13 13:57:35 2003
From: mparker at TheRNDGroup.com (Marshall M. Parker)
Date: Thu, 13 Mar 2003 13:57:35 -0500
Subject: [uClinux-dev] raw serial data...
Message-ID: <0136362BB121814AA94DF907D1638346123153@RNDSVR01.rnd-group.com>

I am sending raw data out my serial port and minicom ignores data bytes
that are 0x00.  Is there a terminal emulator program out there that can
capture raw data.  I need to support raw-ASCII.  All 255 bytes.  Any
hints?
 
Minicom, Telix - Do not work.  Both loose 0x00.
Hyperterminal - Does not work.  0x18 confuses it and causes it to
erroneously read 0x18 multiple times even thought it is not sent.
 
Procomm - ?
 
Thanks
Marshall Parker, the RND Group.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20030313/a61b2226/attachment.html>

From cea at pacific.net.au  Thu Mar 13 14:15:05 2003
From: cea at pacific.net.au (Chris Alfred)
Date: Fri, 14 Mar 2003 06:15:05 +1100
Subject: [uClinux-dev] realtime scheduling...
References: <3E705535.5050405@comsys.se>
Message-ID: <001501c2e994$db0d9fd0$0100a8c0@kythera>

>   Basicly it runs some stuff on the NMI and the 'heavy' tasks on linux 
> regular interrupts, it can hit a 15 ns window for the code to be run ( 
> first instruction ) on the MC5246C3 developement board

Wow! What is the delay from NMI to the code to run.

. Chris Alfred - Engineering Consultant
. p: +61 (2) 9566 4470
. m: 0417 687 437
. cea at pacific.net.au




From tchen at on-go.com  Thu Mar 13 14:45:50 2003
From: tchen at on-go.com (thomas chen)
Date: Thu, 13 Mar 2003 14:45:50 -0500
Subject: [uClinux-dev] raw serial data...
References: <0136362BB121814AA94DF907D1638346123153@RNDSVR01.rnd-group.com>
Message-ID: <3E70DFEE.FAB567E9@on-go.com>

http://www.taltech.com/TALtech_web/news/breakout.htm

this is a very useful tool for me over the years


From roope.anttinen at indagon.com  Thu Mar 13 15:21:55 2003
From: roope.anttinen at indagon.com (Roope Anttinen)
Date: 13 Mar 2003 22:21:55 +0200
Subject: [uClinux-dev] ip masquarade support
In-Reply-To: <3E70A603.AA107ECE@on-go.com>
References: <6E931152-54BA-11D7-ADF6-00039359F448@dartmouth.edu>
	<1047547388.1965.7.camel@tossu>  <3E708817.7EB1BCC9@earthlink.net>
	<1047566436.1965.15.camel@tossu>  <3E70A603.AA107ECE@on-go.com>
Message-ID: <1047586919.1979.0.camel@tossu>

No, if I boot it with cable connected it crashes right away.

/Roope

On Thu, 2003-03-13 at 17:38, thomas chen wrote:
> 
> does it work fine if you boot the system with cable in and can you 
> access the network?
> 
> 
> 
> Roope Anttinen wrote:
> > 
> > It does the same thing even without insmod (if that ip-filter stuff is
> > compiled in the kernel).. stays up fine until I plug in the ethernet
> > cable so it receives the first packet -> CRASH
> > 
> > On Thu, 2003-03-13 at 15:31, Phil Wilshire wrote:
> > > Hi Roope,
> > > Sorry that you are having some difficulties here.
> > >
> > > One ppossible reason for the insmod crash is the need for more stack space in the insmod program.
> > > try
> > > flthdr -s 20000 insmod ( or busybox)
> > >
> > > best regards
> > >   Phil Wilshire
> > >
> > >
> > >
> > > Roope Anttinen wrote:
> > > >
> > > > Tried that but it didn't help :(
> > > > I now compiled the ip-tables stuff as modules.
> > > > insmod ip_tables went ok but when inserting iptable_filter module...
> > > > BANG - kernel crashes:
> > > >
> > > > *** UNASSIGNED RESERVED 12 ***   FORMAT=2
> > > > Current process id is 23
> > > > BAD KERNEL TRAP: 00000000
> > > > PC: [<00101f37>]
> > > > SR: 2035  SP: 0011bcd2  a2: 0056215c
> > > > d0: 00000000    d1: 00000000    d2: 00000000    d3: 10c7e900
> > > > d4: 00101f37    d5: 00000000    a0: 0056218c    a1: 00000000
> > > > Process telnetd (pid: 23, stackpage=0011b000)
> > > > Frame format=2 instr addr=20000010
> > > > Stack from 0011bd0a:
> > > >         018c0004 8b9010c7 e9320004 79240000 00000000 00030011 bdfc0011
> > > > bde810c7
> > > >         e9320000 00000000 00200022 00000000 00000000 00047924 00101f37
> > > > 00000000
> > > >         0010d080 00000000 00000011 bdec0010 d8de0011 bdfc0000 00030000
> > > > 00000004
> > > >         79240010 dcc20000 000010c7 51180000 00030011 bdfc0000 00000004
> > > > 792410c7
> > > >         e9320000 00000004 79240000 00030000 00000000 00000000 00020003
> > > > 67bc10c7
> > > >         53b20004 8b900011 bdfc0000 00030000 00000004 79240011 bde810c7
> > > > e9320000
> > > >
> > > > On Wed, 2003-03-12 at 20:42, David E. Gelhar wrote:
> > > > >
> > > > > On Tuesday, March 11, 2003, at 03:32 AM, Roope Anttinen wrote:
> > > > >
> > > > > > Started all over with as stripped image as possible which does
> > > > > > basically
> > > > > > nothing more than boots...
> > > > >
> > > > >
> > > > > One thing I noticed in your output  is that cs89x0_probe is "finding"
> > > > > lots of bogus ethernet interfaces. The ioaddr of "0xFFE0" is supposed
> > > > > to mean "don't probe". The same thing was happening to me with a
> > > > > uCsimm; although it wasn't resulting in crashes. I don't know if this
> > > > > is the cause of your problem, but it probably can't be good to have
> > > > > these bogus ethernet devices running.
> > > > >
> > > > > This appears to be caused by some added ARM code in drivers/net/Space.c
> > > > > that always calls cs89x0_probe for eth1..eth7 (if CONFIG_CS89x0) in the
> > > > > arch-specific probes section, while the generic isa_probes section will
> > > > > not probe for interfaces with a base addr of 0xFFE0.
> > > > >
> > > > > The obvious patch to that is to not call the arm-specific probes on a
> > > > > non-ARM architecture:
> > > >
> > > > _______________________________________________
> > > > uClinux-dev mailing list
> > > > uClinux-dev at uclinux.org
> > > > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> > > > This message was resent by uclinux-dev at uclinux.org
> > >
> > > --
> > > SDCS -- System Design & Consulting Services LLC, http://www.sysdcs.com
> > > ** Embedded Linux Training **  email me for details
> > > 630 Springhouse Sq., Leesburg VA 20175 t: 703 669 9766 f: 703 669 9768
> > > _______________________________________________
> > > uClinux-dev mailing list
> > > uClinux-dev at uclinux.org
> > > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> > > This message was resent by uclinux-dev at uclinux.org
> > 
> > _______________________________________________
> > uClinux-dev mailing list
> > uClinux-dev at uclinux.org
> > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> > This message was resent by uclinux-dev at uclinux.org
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org




From jwilliams at itee.uq.edu.au  Thu Mar 13 16:20:34 2003
From: jwilliams at itee.uq.edu.au (John Williams)
Date: Fri, 14 Mar 2003 07:20:34 +1000
Subject: [uClinux-dev] uclinux and RTLinux / RTAI
In-Reply-To: <3E707AAE.8090908@metrowerks.com>
References: <3E6FF7DC.7090708@itee.uq.edu.au> <3E707AAE.8090908@metrowerks.com>
Message-ID: <3E70F622.2020305@itee.uq.edu.au>

Bernhard Kuhn wrote:
> John Williams wrote:
> 
>> The uClinux mailing list archive has some discussions from Bernard 
>> Kuhn about impending release of RTLinux for a later kernel version, 
>> but I never saw any more on it.
> 
> 
> RTAI for Coldfire (5272) has been integrated into the official
> RTAI-24.1.10 tree.
> 
> Some older versions and application notes can be found at:
> 
> http://www.uclinux.org/~bkuhn/Platforms/Coldfire/tarifa/20020227/README
> http://www.uclinux.org/~bkuhn/Platforms/Coldfire/tarifa/20020413/README
> 

Excellent, thanks Bernhard!

John



From paulv at ipsdev.com  Thu Mar 13 16:30:10 2003
From: paulv at ipsdev.com (Paul)
Date: Thu, 13 Mar 2003 16:30:10 -0500
Subject: [uClinux-dev] XIP on i386
Message-ID: <012f01c2e9a7$b9975c70$d2c8c8c8@ipsserver.ips>

Forgive me but this is my first experience with digging into the linux kernel, any help is greatly appreciated.

I have a Monarch Paxar 6037 (www.paxar.com) with strict memory requirements.

640k ram
~820k rom

all I need is telnet functionality, as a dumb terminal (using an 802.11 wireless card). I have been evaluating uClinux as an alternative os for it. the memory is too small for normal linux kernel, and I found eXecute In Place. One person posted to another forum somewhere (the where and the who elude me at the moment) that claims to have a XIP kernel running from ROM with the .text (I belive) segment in the RAM, taking up ~120k. XIP is perfect for my needs, but I cannot find any documentation for compiling an XIP kernel for i386. 

Can someone tell me how I can compile for XIP?

Thanks greatly

Paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20030313/0b75d774/attachment.html>

From jwilliams at itee.uq.edu.au  Thu Mar 13 16:51:20 2003
From: jwilliams at itee.uq.edu.au (John Williams)
Date: Fri, 14 Mar 2003 07:51:20 +1000
Subject: [uClinux-dev] realtime scheduling...
In-Reply-To: <3E705535.5050405@comsys.se>
References: <3E705535.5050405@comsys.se>
Message-ID: <3E70FD58.5030202@itee.uq.edu.au>

Hi Lars,

Lars Segerlund wrote:

>  Basicly it runs some stuff on the NMI and the 'heavy' tasks on linux 
> regular interrupts, it can hit a 15 ns window for the code to be run ( 
> first instruction ) on the MC5246C3 developement board, and most of it 
> should be easily portable to other architectures and constraints, ( 
> single timer, multiple timers ). ( also I have some work left on 
> verifying the behaviour of sti cli in the drivers and kernel, ie. 
> estimating worst case for the linux interrupt parts ).

That's an interesting idea... Could it handle, say, interrupts from 
realtime hardware other than the clock?  What I'm thinking is a DSP type 
system, where you have an ADC needing real-time servicing.  If you could 
attach it to the NMI (as well as the NMI clock), the handler reads the 
data off the device, puts it in a shared memory FIFO, to be processed by 
a regular uclinux process when next convenient.

Thinking about doing this on microblaze, which is a softcore (ah, 
infinitely flexible hardware! :) - two separate interrupt controllers on 
the INT and NMI ports of the microprocessor, and two timers.  one timer 
drives the NMI (real time) scheduler, the other drives the uclinux 
scheduler.

Hardware that needs real time servicing hangs off the NMI int 
controller, everything else (network controllers, UARTs etc) uses the 
regular intc.  Could be very interesting.

Cheers,

John




From crystalandy at etang.com  Thu Mar 13 03:48:49 2003
From: crystalandy at etang.com (Crystalandy)
Date: Thu, 13 Mar 2003 16:48:49 +0800 (CST)
Subject: [uClinux-dev] =?gb2312?B?ZXJyb3Ig?=
Message-ID: <3E7045F1.000001.09166@webmta1>

I selected the option SYSTEM V IPC and then compile uclinux, 
but the error about vm_area_struct were generated. 
it shows that the members vm_file,vm_ops....have not been 
defined in the structure vm_area_struct. 

how to solove it then? 


regards, 
andy 


























-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20030313/34f68bb4/attachment.html>

From philwil at earthlink.net  Thu Mar 13 19:11:54 2003
From: philwil at earthlink.net (Phil Wilshire)
Date: Thu, 13 Mar 2003 19:11:54 -0500
Subject: [uClinux-dev] raw serial data...
References: <0136362BB121814AA94DF907D1638346123153@RNDSVR01.rnd-group.com>
Message-ID: <3E711E4A.FA3B2610@earthlink.net>

Hi Marshall

Will this work...

cat /dev/ttyS0 > myfile

emacs myfile
hexdump myfile

.. regards

  Phil

> 
> I am sending raw data out my serial port and minicom ignores data bytes that are 0x00.  Is there a
> terminal emulator program out there that can capture raw data.  I need to support raw-ASCII.  All
> 255 bytes.  Any hints?
> 
>  
> 
> Minicom, Telix - Do not work.  Both loose 0x00.
> 
> Hyperterminal - Does not work.  0x18 confuses it and causes it to erroneously read 0x18 multiple
> times even thought it is not sent.
> 
>  
> 
> Procomm - ?
> 
>  
> 
> Thanks
> 
> Marshall Parker, the RND Group.

-- 
SDCS -- System Design & Consulting Services LLC, http://www.sysdcs.com
** Embedded Linux Training **  email me for details  
630 Springhouse Sq., Leesburg VA 20175 t: 703 669 9766 f: 703 669 9768


From davidm at snapgear.com  Thu Mar 13 20:14:28 2003
From: davidm at snapgear.com (David McCullough)
Date: Fri, 14 Mar 2003 11:14:28 +1000
Subject: [uClinux-dev] XIP on i386
In-Reply-To: <012f01c2e9a7$b9975c70$d2c8c8c8@ipsserver.ips>
References: <012f01c2e9a7$b9975c70$d2c8c8c8@ipsserver.ips>
Message-ID: <20030314011428.GC21172@beast.internal.moreton.com.au>

Jivin Paul lays it down ...
> Forgive me but this is my first experience with digging into the
> linux kernel, any help is greatly appreciated.
> 
> I have a Monarch Paxar 6037 (www.paxar.com) with strict memory requirements.
> 
> 640k ram
> ~820k rom
> 
> all I need is telnet functionality, as a dumb terminal (using an 802.11
> wireless card). I have been evaluating uClinux as an alternative os for it.
> the memory is too small for normal linux kernel, and I found eXecute In
> Place. One person posted to another forum somewhere (the where and the who
> elude me at the moment) that claims to have a XIP kernel running from ROM
> with the .text (I belive) segment in the RAM, taking up ~120k. XIP is
> perfect for my needs, but I cannot find any documentation for compiling>
> an XIP kernel for i386. 
> 
> Can someone tell me how I can compile for XIP?

You need to make some changes to the linker script for the final link
stage of linux.

You need to:

1) put the .text section into ROM where it will execute.  This means
   adding a rom section in the linker script that is located at the 
   address of the ROM.

2) put the .data/.bss sections into RAM,  most likely at the start.

3) make a binary image which takes the .text section and concatenates
   the data/bss info on the end,  then program that into ROM at the
   address you located it at in 1 above.

4) Modify the kernel startup (head.S or crt0.S) to copy the data/bss
   from ROM into RAM before doing anything else.

5) Get your boot loader to start the kernel in ROM.

About the only thing to watch is the init sections,  as they are usually
in the text segement and are freed later.   They cannot be freed if the
are in ROM.

There are quite a few examples in the uClinux tree of ROM based kernels.
The uCsimm uses a ROM kernel by default IIRC and can also do a RAM
kernel,

Cheers,
Davidm

-- 
David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
davidm at snapgear.com  Fx: +61 7 3891 3630  Custom Embedded Solutions + Security


From selvam at sesl.global.sharp.co.jp  Thu Mar 13 20:13:39 2003
From: selvam at sesl.global.sharp.co.jp (Selvam)
Date: Fri, 14 Mar 2003 09:13:39 +0800
Subject: [uClinux-dev] open("/dev/console"...
In-Reply-To: <03031315581200.24943@localhost>
References: <r01050400-1024-64D2897D546C11D7AEEB00039387ACB6@[10.0.1.2]>
 <03031315581200.24943@localhost>
Message-ID: <03031409133900.01385@localhost>

Hi, can anyone explain what happens when 

open("/dev/console".....  executed. 

When this line runs I'm getting a lot of junk chars continuously 
put on my console (minicom). What should I check in console.c.

Appreciate any help.

thanks
Selvam


> On Thursday 13 March 2003 15:58, Selvam wrote:
> Richard I'm still getting some lines printed correctly in between
> the junk chars. So I don't think it's the baud rate.
>
> -------------------------------------------------------
> Mountingb^A^@^A^@^@^B.^@^EH^E^@^@^@^@`^@
> ^@^B^@..^PA^B"..^B@^A^B^B^@^P^@@^@^@ ? ?Q^@ proc on /proc
> -------------------------------------------------------
>
> thanks
> Selvam.
>
> On Wednesday 12 March 2003 17:24, Richard Klingler wrote:
> > > David, I just checked the console_init section seems ok.
> > > I'm actually getting the console output correct until the
> > > init() opens /dev/console.  You can take a look at  the
> > > output.
> >
> > There is no console before init opens it...
> >
> > What you see during booting is just plain direct calls to
> > the serial driver.
> >
> >
> > Rick
> >
> >
> > Richard Klingler             mail: richard.klingler at violasystems.com
> > Viola Systems Ltd.           http://www.violasystems.com/
> > Lemmink?isenkatu 32          phon: +358 (0)201 226 226
> > 20520 Turku, Finland         mobile: +358 (0)40 748 4711
> > _______________________________________________
> > uClinux-dev mailing list
> > uClinux-dev at uclinux.org
> > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> > This message was resent by uclinux-dev at uclinux.org
>
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org



From jokyman at sina.com  Thu Mar 13 20:49:14 2003
From: jokyman at sina.com (thierry)
Date: Fri, 14 Mar 2003 9:49:14 +0800
Subject: [uClinux-dev] XIP on i386
Message-ID: <200303140205.h2E25DF11543@uclinux.org>

Paul???? 

You can choose "execute from rom" in config.
I think that will do.

======== 2003-03-13 16:30:00 ???????? ========

Forgive me but this is my first experience with digging into the linux kernel, any help is greatly appreciated.
 
I have a Monarch Paxar 6037 (www.paxar.com) with strict memory requirements.
 
640k ram
~820k rom
 
all I need is telnet functionality, as a dumb terminal (using an 802.11 wireless card). I have been evaluating uClinux as an alternative os for it. the memory is too small for normal linux kernel, and I found eXecute In Place. One person posted to another forum somewhere (the where and the who elude me at the moment) that claims to have a XIP kernel running from ROM with the .text (I belive) segment in the RAM, taking up ~120k. XIP is perfect for my needs, but I cannot find any documentation for compiling an XIP kernel for i386. 
 
Can someone tell me how I can compile for XIP?
 
Thanks greatly
 
Paul

= = = = = = = = = = = = = = = = = = = = = = 
?????????
??

??????????????thierry
??????????????jokyman at sina.com
?????????????????2003-03-14
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20030314/f93aea29/attachment.html>

From Fabrice_Gautier at sdesigns.com  Thu Mar 13 21:30:43 2003
From: Fabrice_Gautier at sdesigns.com (Fabrice Gautier)
Date: Thu, 13 Mar 2003 18:30:43 -0800
Subject: [uClinux-dev] How to load kernel modules in C
Message-ID: <9F77D654ED40B74CA79E5A60B97A087B04243F@sd-exchange.sdesigns.com>

Hi,

Is there somewhere some non-GPL C code to load a kernel module ? 

Right now I'm calling an external insmod program (busybox) to load a kernel
module but i would like to include the C functions that does that directly
in my program. But since busybox is GPL i cannot just take the busybox
insmod code and include it in this non-GPL program.

So i'm looking for either:
a) Some code with a friendly license (like a BSD or similar).
b) Some documentation that explains the kernel API used to load a module. (I
could look at the busybox code, to understand the kernel APIs, but i feel
the result would probably be too much like the GPL code, and be considered a
derviative work...)

Thanks

-- 
Fabrice Gautier, 
Fabrice_Gautier at sdesigns.com


From manigandanv at myw.ltindia.com  Thu Mar 13 23:34:47 2003
From: manigandanv at myw.ltindia.com (Manigandan.V)
Date: Fri, 14 Mar 2003 10:04:47 +0530
Subject: [uClinux-dev] uclinux and RTLinux / RTAI
References: <3E6FF7DC.7090708@itee.uq.edu.au> <3E707AAE.8090908@metrowerks.com> <3E70F622.2020305@itee.uq.edu.au>
Message-ID: <003e01c2e9e3$0b6dfa00$1e06a8c0@emsysdom>

Any news about RTLinux port for uClinux ??(linux-2.4.x)

Regards,
Mani

> Bernhard Kuhn wrote:
> > John Williams wrote:
> > 
> >> The uClinux mailing list archive has some discussions from Bernard 
> >> Kuhn about impending release of RTLinux for a later kernel version, 
> >> but I never saw any more on it.
> > 
> > 
> > RTAI for Coldfire (5272) has been integrated into the official
> > RTAI-24.1.10 tree.
> > 
> > Some older versions and application notes can be found at:
> > 
> > http://www.uclinux.org/~bkuhn/Platforms/Coldfire/tarifa/20020227/README
> > http://www.uclinux.org/~bkuhn/Platforms/Coldfire/tarifa/20020413/README
> > 
> 
> Excellent, thanks Bernhard!
> 
> John
> 
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org



From jwilliams at itee.uq.edu.au  Fri Mar 14 00:16:57 2003
From: jwilliams at itee.uq.edu.au (John Williams)
Date: Fri, 14 Mar 2003 15:16:57 +1000
Subject: [uClinux-dev] uclinux and RTLinux / RTAI
In-Reply-To: <003e01c2e9e3$0b6dfa00$1e06a8c0@emsysdom>
References: <3E6FF7DC.7090708@itee.uq.edu.au> <3E707AAE.8090908@metrowerks.com> <3E70F622.2020305@itee.uq.edu.au> <003e01c2e9e3$0b6dfa00$1e06a8c0@emsysdom>
Message-ID: <3E7165C9.50601@itee.uq.edu.au>

Manigandan.V wrote:
> Any news about RTLinux port for uClinux ??(linux-2.4.x)

Not yet.  I haven't checked with FSMLabs yet though (makers of RTLinux).

John



From tendim at tendim.cjb.net  Fri Mar 14 00:25:04 2003
From: tendim at tendim.cjb.net (patrick)
Date: Fri, 14 Mar 2003 00:25:04 -0500 (EST)
Subject: [uClinux-dev] Problems compiling m68k-elf toolchain
Message-ID: <Pine.NEB.4.44.0303140006160.22132-100000@vex.net>

Hi.

I have been trying to compile the m68k-elf toolchain on my PowerPC system,
which runs Linux/PPC, created from Linux From Scratch, using gcc-3.2.

I downloaded the source files found at
http://www.uclinux.org/pub/uClinux/m68k-elf-tools, as well as the latest
elf2flt and uClinux-2.0.x from cvs.uclinux.org.

For uClibc, I downloaded the one found at
http://www.uclinux.org/pub/uClinux/m68k-elf-tools, and modified
uClibc/extra/Configs/Config.m68k so that the line reading UNIX98PTY_ONLY
was false instead of the default TRUE.  (If I did not do this, then uClibc
would not compile at all.)

Now, during Stage 6 I get the following error:

/home/tendim/uClinux/m68k-elf-tools/tools-20020410/m68k-elf-gcc/gcc/xgcc -B/home/tendim/uClinux/m68k-elf-tools/tools-20020410/m68k-elf-gcc/gcc/ -B/home/tendim/bin/uClinux/m68k-elf/bin/ -c -I/home/tendim/include -L/home/tendim/lib -I/home/tendim/include -L/home/tendim/lib -I/home/tendim/include -L/home/tendim/lib  -I. -I../../../gcc-2.95.3/libio ../../../gcc-2.95.3/libio/filedoalloc.c
In file included from ../../../gcc-2.95.3/libio/libio.h:30,
                 from ../../../gcc-2.95.3/libio/iolibio.h:1,
                 from ../../../gcc-2.95.3/libio/libioP.h:47,
                 from ../../../gcc-2.95.3/libio/filedoalloc.c:45:
_G_config.h:33: parse error before `_G_fpos_t'
_G_config.h:33: warning: data definition has no type or storage class
In file included from ../../../gcc-2.95.3/libio/libioP.h:47,
                 from ../../../gcc-2.95.3/libio/filedoalloc.c:45:
../../../gcc-2.95.3/libio/iolibio.h:13: parse error before `_G_fpos_t'
../../../gcc-2.95.3/libio/iolibio.h:18: parse error before `*'
make[1]: *** [filedoalloc.o] Error 1
make[1]: Leaving directory `/home/tendim/uClinux/m68k-elf-tools/tools-20020410/m68k-elf-gcc/m68k-elf/libio'
make: *** [all-target-libio] Error 2

Does anybody know what is wrong?  I tried a seperate compile using uClibc
from cvs (just in case uClibc was causing the problem..) but that gave me
Makefile problems in the uClibc stage (sorry, I don't have the error
off hand).

Thanks for any help.

-Patrick

patrick at tendim.cjb.net
"It's simple, overspecialize and you breed in weakness."
 --Ghost in the Shell




From davidm at snapgear.com  Fri Mar 14 00:56:42 2003
From: davidm at snapgear.com (David McCullough)
Date: Fri, 14 Mar 2003 15:56:42 +1000
Subject: [uClinux-dev] Problems compiling m68k-elf toolchain
In-Reply-To: <Pine.NEB.4.44.0303140006160.22132-100000@vex.net>
References: <Pine.NEB.4.44.0303140006160.22132-100000@vex.net>
Message-ID: <20030314055642.GA14490@beast.internal.moreton.com.au>

Jivin patrick lays it down ...
> Hi.
> 
> I have been trying to compile the m68k-elf toolchain on my PowerPC system,
> which runs Linux/PPC, created from Linux From Scratch, using gcc-3.2.
> 
> I downloaded the source files found at
> http://www.uclinux.org/pub/uClinux/m68k-elf-tools, as well as the latest
> elf2flt and uClinux-2.0.x from cvs.uclinux.org.
> 
> For uClibc, I downloaded the one found at
> http://www.uclinux.org/pub/uClinux/m68k-elf-tools, and modified
> uClibc/extra/Configs/Config.m68k so that the line reading UNIX98PTY_ONLY
> was false instead of the default TRUE.  (If I did not do this, then uClibc
> would not compile at all.)
> 
> Now, during Stage 6 I get the following error:
> 
> /home/tendim/uClinux/m68k-elf-tools/tools-20020410/m68k-elf-gcc/gcc/xgcc -B/home/tendim/uClinux/m68k-elf-tools/tools-20020410/m68k-elf-gcc/gcc/ -B/home/tendim/bin/uClinux/m68k-elf/bin/ -c -I/home/tendim/include -L/home/tendim/lib -I/home/tendim/include -L/home/tendim/lib -I/home/tendim/include -L/home/tendim/lib  -I. -I../../../gcc-2.95.3/libio ../../../gcc-2.95.3/libio/filedoalloc.c
> In file included from ../../../gcc-2.95.3/libio/libio.h:30,
>                  from ../../../gcc-2.95.3/libio/iolibio.h:1,
>                  from ../../../gcc-2.95.3/libio/libioP.h:47,
>                  from ../../../gcc-2.95.3/libio/filedoalloc.c:45:
> _G_config.h:33: parse error before `_G_fpos_t'
> _G_config.h:33: warning: data definition has no type or storage class
> In file included from ../../../gcc-2.95.3/libio/libioP.h:47,
>                  from ../../../gcc-2.95.3/libio/filedoalloc.c:45:
> ../../../gcc-2.95.3/libio/iolibio.h:13: parse error before `_G_fpos_t'
> ../../../gcc-2.95.3/libio/iolibio.h:18: parse error before `*'
> make[1]: *** [filedoalloc.o] Error 1
> make[1]: Leaving directory `/home/tendim/uClinux/m68k-elf-tools/tools-20020410/m68k-elf-gcc/m68k-elf/libio'
> make: *** [all-target-libio] Error 2


I have only seen this error when using the latest uClibc from CVS.  If
you are using the uClibc.tar that is included with the m68k-elf-tools
you should not see this error.

Make sure you modify the build-uclinux-tools.sh to use the uClibc from
that tarball included with the tools.


> Does anybody know what is wrong?  I tried a seperate compile using uClibc
> from cvs (just in case uClibc was causing the problem..) but that gave me
> Makefile problems in the uClibc stage (sorry, I don't have the error
> off hand).

I am just about done on a new script/tools release,  you might like to
hold off a day or so for that if you can,

Cheers,
Davidm

-- 
David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
davidm at snapgear.com  Fx: +61 7 3891 3630  Custom Embedded Solutions + Security


From manigandanv at myw.ltindia.com  Fri Mar 14 01:04:32 2003
From: manigandanv at myw.ltindia.com (Manigandan.V)
Date: Fri, 14 Mar 2003 11:34:32 +0530
Subject: [uClinux-dev] uclinux and RTLinux / RTAI
References: <3E6FF7DC.7090708@itee.uq.edu.au> <3E707AAE.8090908@metrowerks.com> <3E70F622.2020305@itee.uq.edu.au> <003e01c2e9e3$0b6dfa00$1e06a8c0@emsysdom> <3E7165C9.50601@itee.uq.edu.au>
Message-ID: <000b01c2e9ef$94c095e0$1e06a8c0@emsysdom>

Well, but uCsimm archives shows that there are some ports of RTLinux
available for uClinux ?
http://www.uclinux.org/pub/uCsimm/archive/0367.html

But I could not get any such patch there .Has some one used it ?

Regards,
Mani

> Manigandan.V wrote:
> > Any news about RTLinux port for uClinux ??(linux-2.4.x)
>
> Not yet.  I haven't checked with FSMLabs yet though (makers of RTLinux).
>
> John




From tendim at tendim.cjb.net  Fri Mar 14 01:04:10 2003
From: tendim at tendim.cjb.net (patrick)
Date: Fri, 14 Mar 2003 01:04:10 -0500 (EST)
Subject: [uClinux-dev] Problems compiling m68k-elf toolchain
In-Reply-To: <20030314055642.GA14490@beast.internal.moreton.com.au>
Message-ID: <Pine.NEB.4.44.0303140059580.23939-100000@vex.net>

On Fri, 14 Mar 2003, David McCullough wrote:

> I have only seen this error when using the latest uClibc from CVS.  If
> you are using the uClibc.tar that is included with the m68k-elf-tools
> you should not see this error.

Nope, that was the uClibc.tar I was using.  However, I was using the
latest 2.0.x from CVS.

When I tried using the CVS uClibc received Makefile errors.

> Make sure you modify the build-uclinux-tools.sh to use the uClibc from
> that tarball included with the tools.

Yup, did that.  I actually just untared the archive into the directory.  I
also made symlinks for the kernel and elf2flt.

> I am just about done on a new script/tools release,  you might like to
> hold off a day or so for that if you can,

This would be great.  Would it be off of the latest CVS stuff?  Will the
script be put in CVS?

I am currently trying to compile with a 2.4.x kernel instead, I'll let the
list know if that works properly.  It is currently in Stage 4 with no
problems yet.

patrick at tendim.cjb.net
"It's simple, overspecialize and you breed in weakness."
 --Ghost in the Shell




From lars.segerlund at comsys.se  Fri Mar 14 02:15:45 2003
From: lars.segerlund at comsys.se (Lars Segerlund)
Date: Fri, 14 Mar 2003 08:15:45 +0100
Subject: [uClinux-dev] realtime scheduling...
In-Reply-To: <001501c2e994$db0d9fd0$0100a8c0@kythera>
References: <3E705535.5050405@comsys.se> <001501c2e994$db0d9fd0$0100a8c0@kythera>
Message-ID: <3E7181A1.6010905@comsys.se>

  Well I haven't measured 'exactly' yet, but it's the time for the 
interrupt to occur, ( 4 words on stack, + some cycles ), but it's 
constant since I'm running in the internal SRAM of the coldfire ( got 
some macros and a set of code to copy stuff in there ).

  My best current guess is about 6-8 clock ticks, however i do 
compensate for this which means that I can hit the 15 ns ( +-7 ns ) 
window for a
desired instruction to occur in.

  In other words, it's the same as coding an interrupt on the raw 
hardware, this way of scheduling doesn't incur any overhead at all in 
this respect.

  I got a call along the lines :

  sch_reg( *func(), type, ... , off )

  where off is the number of cycles to 'preschedule' on. This works 
since i schedule them in batches, with a call like :

  sch_sch( batch )

  where batch in an integer telling how many of the 'registered' 
interrupts to schedule, 8 or all if ZERO ).

  the 15 ns is from the clock running at 70 MHz.

  / Lars Segerlund.

Chris Alfred wrote:
>>  Basicly it runs some stuff on the NMI and the 'heavy' tasks on linux 
>>regular interrupts, it can hit a 15 ns window for the code to be run ( 
>>first instruction ) on the MC5246C3 developement board
> 
> 
> Wow! What is the delay from NMI to the code to run.
> 
> . Chris Alfred - Engineering Consultant
> . p: +61 (2) 9566 4470
> . m: 0417 687 437
> . cea at pacific.net.au
> 
> 
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org
> 



From lars.segerlund at comsys.se  Fri Mar 14 02:31:49 2003
From: lars.segerlund at comsys.se (Lars Segerlund)
Date: Fri, 14 Mar 2003 08:31:49 +0100
Subject: [uClinux-dev] realtime scheduling...
In-Reply-To: <3E70FD58.5030202@itee.uq.edu.au>
References: <3E705535.5050405@comsys.se> <3E70FD58.5030202@itee.uq.edu.au>
Message-ID: <3E718565.1050804@comsys.se>

  Hmm, yes it can handle that, but I don't really understand why ? I 
think I am missing something, since you have an interrupt from an 
external source, you don't need to schedule that event, or do you mean 
if it can schedule an 'linux interrupt' at a lower priority later ? This 
it can do.

  It can schedule new events from the interrupts that occur, some small 
limitations but not much( due to stacka and such but it can be fixed ).

  Perhaps you could lose your NMI clock ? Since it sounds like you only 
need the NMI for the external interrupt ? And could schedule realtime on 
the highest system priority ?

  I also have a 'data dump' device, which act's like a buffer between a 
realtime process and a linux character device, so it looks like a fifo 
but is not. I wrote this since I needed to dump 15 MB/s from a 
industrial PC system to disk, and it would allow me to dump in eccess of 
  100 MB/s to /dev/null while the system was running a quite heavy 
realtime task, I used RT-Linux which was not up to the task, at 1 - 1.5 
MB/s through it's 'rt-fifo's' it barfed.

  If you put these together It would be possible to couple the execution 
of user code to the dumping of data from the realtime part, this makes 
some assumptions but it sounds simple.

John Williams wrote:
> Hi Lars,
> 
> Lars Segerlund wrote:
> 
>>  Basicly it runs some stuff on the NMI and the 'heavy' tasks on linux 
>> regular interrupts, it can hit a 15 ns window for the code to be run ( 
>> first instruction ) on the MC5246C3 developement board, and most of it 
>> should be easily portable to other architectures and constraints, ( 
>> single timer, multiple timers ). ( also I have some work left on 
>> verifying the behaviour of sti cli in the drivers and kernel, ie. 
>> estimating worst case for the linux interrupt parts ).
> 
> 
> That's an interesting idea... Could it handle, say, interrupts from 
> realtime hardware other than the clock?  What I'm thinking is a DSP type 
> system, where you have an ADC needing real-time servicing.  If you could 
> attach it to the NMI (as well as the NMI clock), the handler reads the 
> data off the device, puts it in a shared memory FIFO, to be processed by 
> a regular uclinux process when next convenient.
> 
> Thinking about doing this on microblaze, which is a softcore (ah, 
> infinitely flexible hardware! :) - two separate interrupt controllers on 
> the INT and NMI ports of the microprocessor, and two timers.  one timer 
> drives the NMI (real time) scheduler, the other drives the uclinux 
> scheduler.
> 
> Hardware that needs real time servicing hangs off the NMI int 
> controller, everything else (network controllers, UARTs etc) uses the 
> regular intc.  Could be very interesting.
> 
> Cheers,
> 
> John
> 
> 
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org
> 



From li_juntang at hotmail.com  Fri Mar 14 02:43:26 2003
From: li_juntang at hotmail.com (Juntang)
Date: Fri, 14 Mar 2003 15:43:26 +0800
Subject: [uClinux-dev] generic bus device driver  under uClinux kernel 2.0.38 running on M5272C3
Message-ID: <OE69Eb2kptfUohvxU2q0000006e@hotmail.com>

Hi,
    
    We have connected a generic bus peripheral to M5272C3, directly via data bus, address bus and 
control lines. The generic bus device has read-enable and write-enable pins, but hasn't any chip-
select pin.
    At present, we need to write a driver for this generic bus device. However, we haven't any 
experience for driver programming. Does anybody can give us some clews or referential drivers?

TIA
Juntang


From frederic.dubois at synchronic.fr  Fri Mar 14 03:04:38 2003
From: frederic.dubois at synchronic.fr (=?utf-8?B?RnLDqWRlcmljIERVQk9JUw==?=)
Date: Fri, 14 Mar 2003 09:04:38 +0100
Subject: [uClinux-dev] =?utf-8?B?UkU6IFt1Q2xpbnV4LWRldl0gZ2VuZXJpYyBidXMgZGV2aWNlIGRy?= 	=?utf-8?B?aXZlciAgdW5kZXIgdUNsaW51eCBrZXJuZWwgMi4wLjM4IHJ1bm5pbmcgb24g?= 	=?utf-8?B?TTUyNzJDMw==?=
Message-ID: <1132153BE85ED411B37A0000B4A7D87DCD52@SERVEUR21>

There is:
http://linux.interpuntonet.it/doc/linuxdriver2/index.html

> -----Message d'origine-----
> De?: Juntang [mailto:li_juntang at hotmail.com]
> Envoy??: ven. 14 mars 2003 08:43
> ??: uclinux-dev at uclinux.org
> Objet?: [uClinux-dev] generic bus device driver under uClinux 
> kernel 2.0.38 running on M5272C3
> 
> 
> Hi,
>     
>     We have connected a generic bus peripheral to M5272C3, 
> directly via data bus, address bus and 
> control lines. The generic bus device has read-enable and 
> write-enable pins, but hasn't any chip-
> select pin.
>     At present, we need to write a driver for this generic 
> bus device. However, we haven't any 
> experience for driver programming. Does anybody can give us 
> some clews or referential drivers?
> 
> TIA
> Juntang
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org
> 


From selvam at sesl.global.sharp.co.jp  Fri Mar 14 03:05:02 2003
From: selvam at sesl.global.sharp.co.jp (Selvam)
Date: Fri, 14 Mar 2003 16:05:02 +0800
Subject: [uClinux-dev] where to specify location of romdisk
In-Reply-To: <9F77D654ED40B74CA79E5A60B97A087B04243F@sd-exchange.sdesigns.com>
References: <9F77D654ED40B74CA79E5A60B97A087B04243F@sd-exchange.sdesigns.com>
Message-ID: <03031416050200.08862@localhost>

Hi, in which file should I specify the location of romdisk image 
loaded to the RAM.  My RAM physical address 0x40000000
is being re-mapped to 0x0. May I know how this is done and in which 
file.

thanks
Selvam.



From davidm at snapgear.com  Fri Mar 14 03:10:13 2003
From: davidm at snapgear.com (David McCullough)
Date: Fri, 14 Mar 2003 18:10:13 +1000
Subject: [uClinux-dev] Problems compiling m68k-elf toolchain
In-Reply-To: <Pine.NEB.4.44.0303140059580.23939-100000@vex.net>
References: <20030314055642.GA14490@beast.internal.moreton.com.au> <Pine.NEB.4.44.0303140059580.23939-100000@vex.net>
Message-ID: <20030314081013.GA28190@beast.internal.moreton.com.au>

Jivin patrick lays it down ...
> On Fri, 14 Mar 2003, David McCullough wrote:
> 
> > I have only seen this error when using the latest uClibc from CVS.  If
> > you are using the uClibc.tar that is included with the m68k-elf-tools
> > you should not see this error.
> 
> Nope, that was the uClibc.tar I was using.  However, I was using the
> latest 2.0.x from CVS.


All I can think is that it's something to do with 2.0 ?
I normally use 2.4 headers.


> When I tried using the CVS uClibc received Makefile errors.
> 
> > Make sure you modify the build-uclinux-tools.sh to use the uClibc from
> > that tarball included with the tools.
> 
> Yup, did that.  I actually just untared the archive into the directory.  I
> also made symlinks for the kernel and elf2flt.


No idea,  plenty of others have used it so I know it must be something
with your system/configuration I just can't think what.

> > I am just about done on a new script/tools release,  you might like to
> > hold off a day or so for that if you can,
> 
> This would be great.  Would it be off of the latest CVS stuff?  Will the

Basically,  it will be off the uClinux-dist uClibc for now at least but
it is uClibc-0.9.19 and it shouldn't be hard to use the CVS version.

> script be put in CVS?


It's just a file on it's own and doesn't really fit anywhere.  It will
be on the uClinux-elf-tools page like the rest.


> I am currently trying to compile with a 2.4.x kernel instead, I'll let the
> list know if that works properly.  It is currently in Stage 4 with no
> problems yet.

Its stage6?  the C++ stage that usually shows up the problems.  libio is
the main offender,

If you only want compilers and intend using the uClinux-dist for libs
etc then you can manually finish the stage6 build ignoring errors when
they occur,  touch the STAGE6 file and run "./build-uclinux-tools.sh cont"
to finish the remaining stages and you should have a working toolchain,

Cheers,
Davidm

-- 
David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
davidm at snapgear.com  Fx: +61 7 3891 3630  Custom Embedded Solutions + Security


From rgegusch at mf.tu-berlin.de  Fri Mar 14 03:58:23 2003
From: rgegusch at mf.tu-berlin.de (Rene Gegusch)
Date: Fri, 14 Mar 2003 09:58:23 +0100
Subject: [uClinux-dev] FTPD (FTP Server)
In-Reply-To: <200303121138.53342.rgegusch@mf.tu-berlin.de>
References: <BC03D160581F7A4E92710FC238282411167809@ici-mail.intellicom.se> <3E6CA45E.5090903@snapgear.com> <200303121138.53342.rgegusch@mf.tu-berlin.de>
Message-ID: <200303140958.23873.rgegusch@mf.tu-berlin.de>

Does anyone already did it to compile the ftpd?
Maybe for a uC5272 system?
I am finally out of ideas what I could do...

Here a short list of my tries:
1) compiling alone --> missing definitions etc.
2) added it to my uC5272 Arcturus directory and tried to compile it by a 
complete system compilation --> failed, because of redefinitions,  failed 
because of errors in i.e. shadow.h of my cross-compiler (m68k-elf) libary, 
etc.
3) compiling the latest distribution for the uC5272 system --> error because 
there was nor rule for crt0_ram.S in directory 
/linux-2.4.x/arch/m68knommu/platform/5272
4) edited the latest distribution with hints of Greg Unger to fit it for the 
uC5272 and compiled it --> failed... same error


I am thankful about any hint, information or experience you will give me

Rene



From rgegusch at mf.tu-berlin.de  Fri Mar 14 04:05:08 2003
From: rgegusch at mf.tu-berlin.de (Rene Gegusch)
Date: Fri, 14 Mar 2003 10:05:08 +0100
Subject: [uClinux-dev] Problems compiling for uCdimm
In-Reply-To: <Pine.NEB.4.44.0303130109370.26292-100000@vex.net>
References: <Pine.NEB.4.44.0303130109370.26292-100000@vex.net>
Message-ID: <200303141005.08262.rgegusch@mf.tu-berlin.de>

I don't think that your machine power causes this error :)

Which board are you using?
I am using the Arcturus uC5272 board and also have problems to compile the 
latest distribution.
Greg Ungerer told me, that this is regular, because of missing platform 
informations regarding my board.
Arcturus does not share their files with the CVS directory. A guy from 
Arcturus also asked me, what there is the big difference, when I asked for a 
new distribution ready to compile for my system. This is a poor answer.

This is what Greg Ungerer told me:
If your target is the uC5272 (which I assume from your error output)
then you need the files under:

   linux-2.4.x/arch/m68knommu/platform/5272/uC5272

which are not at cvs.uclinux.org and so not in uClinux-dist.

You will also need to update the arch/m68knommu/config.in and
Boards.mk files, which also do not contain options for uC5272.


Well, I tried it, but failed. There is no rule for crt0_ram.S... and I 
couldn't find out what there is wrong or different to the distribution 
Arcturus shipped with the development board.

Also see my other entries in the mailing list..

Rene



Am Donnerstag, 13. M?rz 2003 07:14 schrieb patrick:
> Hello.
>
> I have been experiencing problems compiling uClinux-dist-20030305.tar.gz
> with m68k-elf-tools-20020410.tar.gz.
>
> I've followed the instructions, done a "make menuconfig" and "make dep"
> and proceed to do "make", after making sure that I have selected the
> proper manufacturer for my board (Arcturus).  However, I consistently get
> the following message:
>
> m68k-elf-gcc: Internal compiler error: program cc1 got fatal signal 11
> .. and a bunch of make[x]: messages ..
>
> Now, the thing is, that if I issue a "make" after the "crash" the
> compilation picks up where it left off, and keeps going.
>
> So I want to know, what *is* signal 11?  How can I avoid it?  Since the
> error occurs in different files (and when I re-issue the "make", the file
> that crashed last time compiles without problems), I'm thinking it is
> something with my setup.
>
> I'm doing this on an AMD K6-233 w/ 42 MB RAM, and 256 MB of swap space,
> under Linux 2.4.17 (from Redhat 7.2).  I know that this is pushing the
> machine to the limit, but it is the only Intel based machine I have at
> the moment ot develop on!  :(  (And all binaries I've found so far are for
> Intel).
>
> Thanks for any help ppl can give me.
>
> -Patrick
>
> patrick at tendim.cjb.net
> "It's simple, overspecialize and you breed in weakness."
>  --Ghost in the Shell
>
>
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org




From jwilliams at itee.uq.edu.au  Fri Mar 14 04:24:31 2003
From: jwilliams at itee.uq.edu.au (John Willlams)
Date: Fri, 14 Mar 2003 19:24:31 +1000
Subject: [uClinux-dev] uclinux and RTLinux / RTAI
Message-ID: <001401c2ea0b$858ac840$0307a8c0@john.qut.edu.au>

>Well, but uCsimm archives shows that there are some ports of RTLinux
>available for uClinux ?
>http://www.uclinux.org/pub/uCsimm/archive/0367.html
>
>But I could not get any such patch there .Has some one used it ?

That's from before my time :) , but I suspect it's the 2.0.x patch.  Have a
look at the message I posted on this subject a few days ago, it has links to
an patch for the 2.0.x kernel on Dragonball (ucsimm).

That's the only RT/uClinux "ready-to-go" patch that I've found so far.

Regards,
John



From jwilliams at itee.uq.edu.au  Fri Mar 14 04:35:17 2003
From: jwilliams at itee.uq.edu.au (John Willlams)
Date: Fri, 14 Mar 2003 19:35:17 +1000
Subject: [uClinux-dev] realtime scheduling...
Message-ID: <003d01c2ea0d$a9c61280$0307a8c0@john.qut.edu.au>

Hi Lars,

>  Hmm, yes it can handle that, but I don't really understand why ? I
>think I am missing something, since you have an interrupt from an
>external source, you don't need to schedule that event, or do you mean
>if it can schedule an 'linux interrupt' at a lower priority later ? This
>it can do.

I was thinking it might be good to put a big wall between the real-time and
non real-time aspects of a system (and application).  So, by hanging
everything truly "real-time" off the NMI (using a 2nd interrupt controller),
and everying related to uClinux of the maskable interrupts, the two can be
pretty much completely ignorant of each other (except for a data tunnel from
one side of the wall to the other).

The recent discussions about RTLinux patches, then patching the patches for
uclinux, and so on, gives me headaches just thinking about it.  Every new
parallel branch in the source is a maintenence nightmare.  The absence of
RTLinux support for uClinux2.4 makes me think there must be a better,
cleaner way to add RT support without hacking into the bowels of uClinux.

The other thing is that since I'm living in the land of reconfigurable
computing on FPGAs, so it's very easy for me to say "ah just add another
interrupt controller, then create a FIFO peripheral to allow communication",
and so on.   Whether it's easy to do may be another matter! :)

Sorry if I'm not being very clear, it's just a lot of random ideas at the
moment, slowly forming into shape!

John



From lars.segerlund at comsys.se  Fri Mar 14 05:20:12 2003
From: lars.segerlund at comsys.se (Lars Segerlund)
Date: Fri, 14 Mar 2003 11:20:12 +0100
Subject: [uClinux-dev] realtime scheduling...
In-Reply-To: <003d01c2ea0d$a9c61280$0307a8c0@john.qut.edu.au>
References: <003d01c2ea0d$a9c61280$0307a8c0@john.qut.edu.au>
Message-ID: <3E71ACDC.8000005@comsys.se>

  Sounds reasonable, it's what I'm using it for :-) .. also it's not 
that much of a hazzle since it's a module at the moment.

  As fo rRT-Linux I'm not much of a fan of it since I have used it, if I 
had a choice today I would use RTAI ...

  RT-Linux was buggy and unstable ... IMHO .

  / Lars

John Willlams wrote:
> Hi Lars,
> 
> 
>> Hmm, yes it can handle that, but I don't really understand why ? I
>>think I am missing something, since you have an interrupt from an
>>external source, you don't need to schedule that event, or do you mean
>>if it can schedule an 'linux interrupt' at a lower priority later ? This
>>it can do.
> 
> 
> I was thinking it might be good to put a big wall between the real-time and
> non real-time aspects of a system (and application).  So, by hanging
> everything truly "real-time" off the NMI (using a 2nd interrupt controller),
> and everying related to uClinux of the maskable interrupts, the two can be
> pretty much completely ignorant of each other (except for a data tunnel from
> one side of the wall to the other).
> 
> The recent discussions about RTLinux patches, then patching the patches for
> uclinux, and so on, gives me headaches just thinking about it.  Every new
> parallel branch in the source is a maintenence nightmare.  The absence of
> RTLinux support for uClinux2.4 makes me think there must be a better,
> cleaner way to add RT support without hacking into the bowels of uClinux.
> 
> The other thing is that since I'm living in the land of reconfigurable
> computing on FPGAs, so it's very easy for me to say "ah just add another
> interrupt controller, then create a FIFO peripheral to allow communication",
> and so on.   Whether it's easy to do may be another matter! :)
> 
> Sorry if I'm not being very clear, it's just a lot of random ideas at the
> moment, slowly forming into shape!
> 
> John
> 
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org
> 



From pong_dragon at sinaman.com  Fri Mar 14 05:25:25 2003
From: pong_dragon at sinaman.com (=?big5?B?cG9uZ19kcmFnb24=?=)
Date: Fri, 14 Mar 2003 18:25:25 +0800
Subject: [uClinux-dev] =?big5?B?aG93IGNhbiBkaXNwbGF5IGNoYXIgb24gTENEIGF0IDY4RVozMjg=?=
Message-ID: <20030314182525.117.qmail@hk.sina.com.hk>

Hi all,
I could initial the 320X240 LCD and displayed bootlogo. But how can I display char on LCD. I am using uCsimm/68ez328, uClinux 2.0.38 provided by my university. Could anyone help me (emergency), it is better has program code as reference.
Thanks!!! 
Dragon Lee
==========================================================================================
????????????????$0.68 - http://phonecard.sina.com.hk/
?????????? - http://finance.sina.com.hk/seminar/bossible_2003/1005.html
???????? -
http://redirection.sina.com.hk/wsi/mail-WSI/www.wsi.edu.hk/special.htm




From hamilton at sedsystems.ca  Fri Mar 14 09:25:12 2003
From: hamilton at sedsystems.ca (Kendrick Hamilton)
Date: Fri, 14 Mar 2003 08:25:12 -0600 (Canada Central Standard Time)
Subject: [uClinux-dev] How to load kernel modules in C
In-Reply-To: <9F77D654ED40B74CA79E5A60B97A087B04243F@sd-exchange.sdesigns.com>
Message-ID: <Pine.WNT.4.44.0303140822050.233-100000@sw-55.sedsystems.ca>

Fabrice,
	all you need to do is use the system function call.

	system("/sbin/insmod mymodule");
This will vfork and exec a shell which then executes the insmod. If you
want to eliminate the shell startup from the code, do the vfork and exec
in your program.
Kendrick

On Thu, 13 Mar 2003, Fabrice Gautier wrote:

> Hi,
>
> Is there somewhere some non-GPL C code to load a kernel module ?
>
> Right now I'm calling an external insmod program (busybox) to load a kernel
> module but i would like to include the C functions that does that directly
> in my program. But since busybox is GPL i cannot just take the busybox
> insmod code and include it in this non-GPL program.
>
> So i'm looking for either:
> a) Some code with a friendly license (like a BSD or similar).
> b) Some documentation that explains the kernel API used to load a module. (I
> could look at the busybox code, to understand the kernel APIs, but i feel
> the result would probably be too much like the GPL code, and be considered a
> derviative work...)
>
> Thanks
>
> --
> Fabrice Gautier,
> Fabrice_Gautier at sdesigns.com
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org
>



From amit_bhor at hotpop.com  Fri Mar 14 11:28:14 2003
From: amit_bhor at hotpop.com (amit bhor)
Date: Fri, 14 Mar 2003 21:58:14 +0530
Subject: [uClinux-dev] kernel BUG at slab.c:1141!
In-Reply-To: <OFCA760F10.20366A4A-ON48256CE8.002E825E@dlink.com.tw>
References: <OFCA760F10.20366A4A-ON48256CE8.002E825E@dlink.com.tw>
Message-ID: <oprl09dcaaetswoi@smtp.hotpop.com>

On Thu, 13 Mar 2003 16:34:34 +0800, <cw_ni at dlink.com.tw> wrote:

>
> Hello all: ^_^
> Here I got a problem with the error message "kernel BUG at slab.c:
> 1141!"
> I use __backtrace to trace back the source of this problem.
> It is from the call of kmalloc() in my driver.
> I am sure that  my usage of kmalloc is correct.
> What is the reason ? Please give me some suggestions about this. :p
> The kernel version I use is 2.4.17pre.
> Best regards.
> ChengWu.

Check that your mode(GFP_ATOMIC , GFP_KERNEL , etc ) in kmalloc is right

Amit. 


From amit_bhor at hotpop.com  Fri Mar 14 11:36:30 2003
From: amit_bhor at hotpop.com (amit bhor)
Date: Fri, 14 Mar 2003 22:06:30 +0530
Subject: [uClinux-dev] SAVE_STACK_SWITCH in system call.
Message-ID: <oprl09q4weetswoi@smtp.hotpop.com>

hi,

I was looking through the uClinux m68k code and i see a SAVE_STACK_SWITCH 
before every system call. I thought the whole idea was to not save the 
scratch registers (callee saved). Am i right here ? I am looking at 
TOPDIR/arch/m68knommu/platform/68328/entry.S.

Thanks,
Amit 


From espin at idiom.com  Fri Mar 14 12:07:27 2003
From: espin at idiom.com (Geoffrey Espin)
Date: Fri, 14 Mar 2003 09:07:27 -0800
Subject: [uClinux-dev] realtime scheduling...
In-Reply-To: <3E71ACDC.8000005@comsys.se>
References: <003d01c2ea0d$a9c61280$0307a8c0@john.qut.edu.au> <3E71ACDC.8000005@comsys.se>
Message-ID: <20030314170727.GA42670@idiom.com>

On Fri, Mar 14, 2003 at 11:20:12AM +0100, Lars Segerlund wrote:
>  As fo rRT-Linux I'm not much of a fan of it since I have used it, if I 
> had a choice today I would use RTAI ...

That was the conclusion of a recent article at:

	http://www.linuxdevices.com/articles/AT6416763926.html

by Axis on ETRAX.

Geoff


From bkuhn at metrowerks.com  Fri Mar 14 12:56:16 2003
From: bkuhn at metrowerks.com (Bernhard Kuhn)
Date: Fri, 14 Mar 2003 18:56:16 +0100
Subject: [uClinux-dev] uclinux and RTLinux / RTAI
References: <3E6FF7DC.7090708@itee.uq.edu.au> <3E707AAE.8090908@metrowerks.com> <3E70F622.2020305@itee.uq.edu.au> <003e01c2e9e3$0b6dfa00$1e06a8c0@emsysdom>
Message-ID: <3E7217C0.906@metrowerks.com>

Manigandan.V wrote:
> Any news about RTLinux port for uClinux ??(linux-2.4.x)

No. What's wrong about RTAI?

Bernhard



From tendim at tendim.cjb.net  Fri Mar 14 13:01:15 2003
From: tendim at tendim.cjb.net (patrick)
Date: Fri, 14 Mar 2003 13:01:15 -0500 (EST)
Subject: [uClinux-dev] Problems compiling m68k-elf toolchain
In-Reply-To: <20030314081013.GA28190@beast.internal.moreton.com.au>
Message-ID: <Pine.NEB.4.44.0303141252130.24160-100000@vex.net>

On Fri, 14 Mar 2003, David McCullough wrote:

> All I can think is that it's something to do with 2.0 ?
> I normally use 2.4 headers.

Well, I just tried 2.4, and still problems.  :(  See below.

> No idea,  plenty of others have used it so I know it must be something
> with your system/configuration I just can't think what.

Yes, I've realized.  I've been trying to think of what is in my
"distribution" versus others.  Since I've only compiled from scratch all
of my things, everything should be the "latest and greatest".

> Its stage6?  the C++ stage that usually shows up the problems.  libio is
> the main offender,

Correct.  My last error showed:

In file included from ../../../gcc-2.95.3/libio/libio.h:30,
                 from ../../../gcc-2.95.3/libio/iolibio.h:1,
                 from ../../../gcc-2.95.3/libio/libioP.h:47,
                 from ../../../gcc-2.95.3/libio/filedoalloc.c:45:
_G_config.h:33: parse error before `_G_fpos_t'
_G_config.h:33: warning: data definition has no type or storage class
In file included from ../../../gcc-2.95.3/libio/libioP.h:47,
                 from ../../../gcc-2.95.3/libio/filedoalloc.c:45:
../../../gcc-2.95.3/libio/iolibio.h:13: parse error before `_G_fpos_t'
../../../gcc-2.95.3/libio/iolibio.h:18: parse error before `*'
make[1]: *** [filedoalloc.o] Error 1
make[1]: Leaving directory
`/usr/src/uClinux/m68k-elf-tools/tools-20020410/m68k-elf-gcc/m68k-elf/libio'
make: *** [all-target-libio] Error 2

I'm now trying to compile without c++ to see what happens.

Patrick M Pritchard <tendim at tendim.cjb.net>
University of Toronto Blue Sky Solar
Telemetry Systems Project Manager



From tendim at tendim.cjb.net  Fri Mar 14 13:04:52 2003
From: tendim at tendim.cjb.net (patrick)
Date: Fri, 14 Mar 2003 13:04:52 -0500 (EST)
Subject: [uClinux-dev] Problems compiling for uCdimm
In-Reply-To: <200303141005.08262.rgegusch@mf.tu-berlin.de>
Message-ID: <Pine.NEB.4.44.0303141302090.24160-100000@vex.net>

On Fri, 14 Mar 2003, Rene Gegusch wrote:

> I don't think that your machine power causes this error :)

Well, machine horsepower.  :)  The little machine I was using would place
the compile process on the running queue indefinately due to lack of RAM.
:(  Even with 256 MB of swap.

>
> Which board are you using?
> I am using the Arcturus uC5272 board and also have problems to compile the
> latest distribution.

Which isthe uC5272?  I'm using the uCevolution, also by Arcturus,
revision 1.1.

> which are not at cvs.uclinux.org and so not in uClinux-dist.

Have you tried contactint support at arcturusnetworks.com directly for the
files?

Patrick Pritchard <patrick at tendim.cjb.net>
University of Toronto Blue Sky Solar
Telemetry Systems Project Manager



From david.coldfire at tiscali.co.uk  Fri Mar 14 13:09:56 2003
From: david.coldfire at tiscali.co.uk (David Anderson)
Date: Fri, 14 Mar 2003 18:09:56 -0000
Subject: [uClinux-dev] Engineer available now for uClinux work
Message-ID: <NGBBIPJEALHLKCKNJMHKGEHHCCAA.david.coldfire@tiscali.co.uk>

Hello all,

Just a quick message informing of my availability for application, device
driver and other uCLinux contract work. Available immediately. United
Kingdom based.

David J.Anderson, B.Sc(Eng), MIEE.

mailto:david.anderson at devandes.com
----------------------------------
David Anderson Designs.
Suite 19, Church Hatch
22 Market Place, Ringwood.
Hants. U.K. BH24 1AW
tel: +44 (0)1425-461-112
--------------------------




From KimK at UniqueSys.com  Fri Mar 14 14:10:14 2003
From: KimK at UniqueSys.com (Kim Klaiman)
Date: Fri, 14 Mar 2003 14:10:14 -0500
Subject: [uClinux-dev] C++ compilation error
Message-ID: <13A2053F3416D411935500508BC5D95801946241@ubsexch01.uniquesys.com>

I'm trying to compile C++ applications for MC68360 target using m68k-elf-gcc
(or m68k-elf-g++) compiler. 
I'm getting the following errors:

/usrnew/kim/68360/new_h/new:32: `operator new' takes type `size_t' as first
parameter
/usrnew/kim/68360/new_h/new:33: `operator new' takes type `size_t' as first
parameter
/usrnew/kim/68360/new_h/new:36: `operator new' takes type `size_t' as first
parameter
/usrnew/kim/68360/new_h/new:37: `operator new' takes type `size_t' as first
parameter
/usrnew/kim/68360/new_h/new:42: `operator new' takes type `size_t' as first
parameter
/usrnew/kim/68360/new_h/new:43: `operator new' takes type `size_t' as first
parameter

Any ideas?

Kim Klaiman
Senior Software Engineer
Unique Broadband Systems



From sdeepa69 at yahoo.com  Fri Mar 14 14:22:20 2003
From: sdeepa69 at yahoo.com (Deepa Sivasankarane)
Date: Fri, 14 Mar 2003 11:22:20 -0800 (PST)
Subject: [uClinux-dev] SAVE_STACK_SWITCH in system call.
In-Reply-To: <oprl09q4weetswoi@smtp.hotpop.com>
Message-ID: <20030314192220.77945.qmail@web80402.mail.yahoo.com>


Hi,
  This is the extended stack (switch_stack: asm-m68knommu/include/ptrace.h)
that gets saved, after pt_regs (SAVE_ALL),  
before calling signal handlers or  context switching (within system_call handler).
 
Deepa
 amit bhor <amit_bhor at hotpop.com> wrote:hi,

I was looking through the uClinux m68k code and i see a SAVE_STACK_SWITCH 
before every system call. I thought the whole idea was to not save the 
scratch registers (callee saved). Am i right here ? I am looking at 
TOPDIR/arch/m68knommu/platform/68328/entry.S.

Thanks,
Amit 
_______________________________________________
uClinux-dev mailing list
uClinux-dev at uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev at uclinux.org


---------------------------------
Do you Yahoo!?
Yahoo! Web Hosting - establish your business online
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20030314/1d25cd14/attachment.html>

From hamilton at sedsystems.ca  Fri Mar 14 14:42:05 2003
From: hamilton at sedsystems.ca (Kendrick Hamilton)
Date: Fri, 14 Mar 2003 13:42:05 -0600 (Canada Central Standard Time)
Subject: [uClinux-dev] C++ compilation error
In-Reply-To: <13A2053F3416D411935500508BC5D95801946241@ubsexch01.uniquesys.com>
Message-ID: <Pine.WNT.4.44.0303141341320.226-100000@sw-55.sedsystems.ca>

Can you show use the code it is complaining about. (also make sure you use
m68k-elf-g++).

On Fri, 14 Mar 2003, Kim Klaiman wrote:

> I'm trying to compile C++ applications for MC68360 target using m68k-elf-gcc
> (or m68k-elf-g++) compiler.
> I'm getting the following errors:
>
> /usrnew/kim/68360/new_h/new:32: `operator new' takes type `size_t' as first
> parameter
> /usrnew/kim/68360/new_h/new:33: `operator new' takes type `size_t' as first
> parameter
> /usrnew/kim/68360/new_h/new:36: `operator new' takes type `size_t' as first
> parameter
> /usrnew/kim/68360/new_h/new:37: `operator new' takes type `size_t' as first
> parameter
> /usrnew/kim/68360/new_h/new:42: `operator new' takes type `size_t' as first
> parameter
> /usrnew/kim/68360/new_h/new:43: `operator new' takes type `size_t' as first
> parameter
>
> Any ideas?
>
> Kim Klaiman
> Senior Software Engineer
> Unique Broadband Systems
>
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org
>



From sdeepa69 at yahoo.com  Fri Mar 14 14:52:39 2003
From: sdeepa69 at yahoo.com (Deepa Sivasankarane)
Date: Fri, 14 Mar 2003 11:52:39 -0800 (PST)
Subject: [uClinux-dev] user stack
Message-ID: <20030314195239.44314.qmail@web80401.mail.yahoo.com>


Hi,

    In m68knommu/entry.S, the following check for interrupt from user:

#define SAVE_ALL      \
 move #0x2700,%sr;  /* disable intrs */ \
 btst #5,%sp@(2);  /* from user? */ \
 bnes 6f;   /* no, skip */

Could someone please tell me which register is checked at sp at 2 ?

Thanx,

Deepa

 



---------------------------------
Do you Yahoo!?
Yahoo! Web Hosting - establish your business online
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20030314/21cff7d6/attachment.html>

From KimK at UniqueSys.com  Fri Mar 14 15:05:42 2003
From: KimK at UniqueSys.com (Kim Klaiman)
Date: Fri, 14 Mar 2003 15:05:42 -0500
Subject: [uClinux-dev] C++ compilation error
Message-ID: <13A2053F3416D411935500508BC5D95801946242@ubsexch01.uniquesys.com>

The code in /usrnew/kim/68360/new_h/new looks like this:

#pragma interface "new"
#include <stddef.h>
#include <exception>

extern "C++" {

#if 0
namespace std {
#endif

  class bad_alloc : public exception {
  public:
    virtual const char* what() const throw() { return "bad_alloc"; }
  };

  struct nothrow_t {};
  extern const nothrow_t nothrow;
  typedef void (*new_handler)();
  new_handler set_new_handler (new_handler);

#if 0
} // namespace std
#endif

// replaceable signatures
void *operator new (size_t) throw (std::bad_alloc);         (line 32)
void *operator new[] (size_t) throw (std::bad_alloc);
void operator delete (void *) throw();
void operator delete[] (void *) throw();
void *operator new (size_t, const nothrow_t&) throw();
void *operator new[] (size_t, const nothrow_t&) throw();
void operator delete (void *, const nothrow_t&) throw();
void operator delete[] (void *, const nothrow_t&) throw();

// default placement versions of operator new
inline void *operator new(size_t, void *place) throw() { return place; }
(line 42)
inline void *operator new[](size_t, void *place) throw() { return place; }
} // extern "C++"

#endif


-----Original Message-----
From: Kendrick Hamilton [mailto:hamilton at sedsystems.ca]
Sent: Friday, March 14, 2003 2:42 PM
To: 'uclinux-dev at uclinux.org'
Subject: Re: [uClinux-dev] C++ compilation error


Can you show use the code it is complaining about. (also make sure you use
m68k-elf-g++).

On Fri, 14 Mar 2003, Kim Klaiman wrote:

> I'm trying to compile C++ applications for MC68360 target using
m68k-elf-gcc
> (or m68k-elf-g++) compiler.
> I'm getting the following errors:
>
> /usrnew/kim/68360/new_h/new:32: `operator new' takes type `size_t' as
first
> parameter
> /usrnew/kim/68360/new_h/new:33: `operator new' takes type `size_t' as
first
> parameter
> /usrnew/kim/68360/new_h/new:36: `operator new' takes type `size_t' as
first
> parameter
> /usrnew/kim/68360/new_h/new:37: `operator new' takes type `size_t' as
first
> parameter
> /usrnew/kim/68360/new_h/new:42: `operator new' takes type `size_t' as
first
> parameter
> /usrnew/kim/68360/new_h/new:43: `operator new' takes type `size_t' as
first
> parameter
>
> Any ideas?
>
> Kim Klaiman
> Senior Software Engineer
> Unique Broadband Systems
>
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org
>

_______________________________________________
uClinux-dev mailing list
uClinux-dev at uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev at uclinux.org


From amit_bhor at hotpop.com  Fri Mar 14 16:05:36 2003
From: amit_bhor at hotpop.com (amit bhor)
Date: Sat, 15 Mar 2003 02:35:36 +0530
Subject: [uClinux-dev] user stack
In-Reply-To: <20030314195239.44314.qmail@web80401.mail.yahoo.com>
References: <20030314195239.44314.qmail@web80401.mail.yahoo.com>
Message-ID: <oprl1l7moletswoi@smtp.hotpop.com>

Hi,

I would guess its seeing the status register of the inerrupted control flow 
(process / kernel) that was interrupted. This along with the PC is pushed 
by the control unit on interrupt. More specifically the state (13th) bit in 
the status word is being checked there.

Amit,

On Fri, 14 Mar 2003 11:52:39 -0800 (PST), Deepa Sivasankarane 
<sdeepa69 at yahoo.com> wrote:

>
> Hi,
>
> In m68knommu/entry.S, the following check for interrupt from user:
>
> #define SAVE_ALL      \
> move #0x2700,%sr;  /* disable intrs */ \
> btst #5,%sp@(2);  /* from user? */ \
> bnes 6f;   /* no, skip */
>
> Could someone please tell me which register is checked at sp at 2 ?
>
> Thanx,
>
> Deepa
>
>
>
>
>
> ---------------------------------
> Do you Yahoo!?
> Yahoo! Web Hosting - establish your business online





From amit_bhor at hotpop.com  Fri Mar 14 16:12:48 2003
From: amit_bhor at hotpop.com (amit bhor)
Date: Sat, 15 Mar 2003 02:42:48 +0530
Subject: [uClinux-dev] SAVE_STACK_SWITCH in system call.
In-Reply-To: <20030314192220.77945.qmail@web80402.mail.yahoo.com>
References: <20030314192220.77945.qmail@web80402.mail.yahoo.com>
Message-ID: <oprl1mjmb0etswoi@smtp.hotpop.com>

On Fri, 14 Mar 2003 11:22:20 -0800 (PST), Deepa Sivasankarane 
<sdeepa69 at yahoo.com> wrote:

>
> Hi,
> This is the extended stack (switch_stack: asm-m68knommu/include/ptrace.h)
> that gets saved, after pt_regs (SAVE_ALL),  before calling signal 
> handlers or  context switching (within system_call handler).

But in the system call , if and when it sleeps , these registers will be 
saved anyways(in SWITCH_TO() ). Like i said, i thought the whole idea was 
to *not save* registers that C functions save. So as long as you dont use 
these registers in your system call handler,there should not be a need to 
save them unless you actually sleep.
 Amit,

> Deepa
> amit bhor <amit_bhor at hotpop.com> wrote:hi,
>
> I was looking through the uClinux m68k code and i see a SAVE_STACK_SWITCH 
> before every system call. I thought the whole idea was to not save the 
> scratch registers (callee saved). Am i right here ? I am looking at 
> TOPDIR/arch/m68knommu/platform/68328/entry.S.
>
> Thanks,
> Amit _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org
>
>
> ---------------------------------
> Do you Yahoo!?
> Yahoo! Web Hosting - establish your business online





From g.menie at wanadoo.fr  Fri Mar 14 17:29:05 2003
From: g.menie at wanadoo.fr (Georges Menie)
Date: 14 Mar 2003 23:29:05 +0100
Subject: [uClinux-dev] Daemonize a process
In-Reply-To: <02af01c2e976$aaabe540$294b82ce@connecttech.com>
References: <Pine.WNT.4.44.0303121631290.258-100000@sw-55.sedsystems.ca>
	<200303130901.22965.maillist@fsforth.de> <1047547115.1966.2.camel@tossu> 
	<02af01c2e976$aaabe540$294b82ce@connecttech.com>
Message-ID: <1047680946.1137.17.camel@troca>

On Thu, 2003-03-13 at 16:38, Stuart MacDonald wrote:
> From: "Roope Anttinen" <roope.anttinen at indagon.com>
> > Try something like this. Fairly standard stuff but I haven't tried this
> > is uClinux so it might need some modifications.
> 
> As I mentioned in my original post, this does not work properly.
> 
> > int daemonize()
> > {
> >     int fd;
> >     pid_t pid;
> >
> >     pid = fork();
> >
> >     switch (pid) {
> >     case -1:
> >         return -1;
> >     case 0:
> 
> The child runs, gets to this line and continues with the setsid below.
> 
> >         break;
> >     default:
> 
> The parent is blocked waiting for the child to _exit() or execve(),
> and does not reach the line below until that happens. This leaves the
> parent process in the D state, and AFAICanTell, also does not detach
> the daemon from the controlling tty, meaning that when one logs out,
> the process is killed.

what about this the following code ?
I tried it on my board, and it seems to work ok,
I don't know if the signal() are needed or not...

I used a trick with the execve name and the commandline
name of the process to avoid vfork loop, the program
name is messmgr but the forked process gets a name
with a 'd' happened at the end...

the controlling terminal is reset, so one can exit the shell which was
used to start the daemon.

#define EXEC_FULLPATHNAME "/usr/local/bin/messmgr"

int main(int argc, char *argv[])
{
	int fd, pid;
	char *av[] = { "messmgrd", NULL }; /* real basename + 'd' */
	extern char **environ;
	
	chdir("/");
	umask(0);
	setpgrp();
	for (fd = 0; fd < getdtablesize(); ++fd)
		close(fd);
	if ((fd=open("/dev/tty", O_RDWR)) >= 0) {
		(void) ioctl(fd, TIOCNOTTY, (char *)0);
		(void) close(fd);
	}
	signal(SIGHUP, SIG_IGN);
	signal(SIGTTOU, SIG_IGN);
	signal(SIGTTIN, SIG_IGN);
	signal(SIGTSTP, SIG_IGN);

	openlog(argv[0],LOG_CONS|LOG_PID,LOG_DAEMON);

	if (strcmp(argv[0], av[0])) {
		if ((pid = vfork()) == 0) {
			execve(EXEC_FULLPATHNAME, av, environ);
			syslog(LOG_DEBUG,"exec failed\n");
		} else if(pid < 0) {
			syslog(LOG_DEBUG,"fork failed\n");
		}
		_exit(0);
	}

	return do_something();
}




From Fabrice_Gautier at sdesigns.com  Fri Mar 14 17:57:17 2003
From: Fabrice_Gautier at sdesigns.com (Fabrice Gautier)
Date: Fri, 14 Mar 2003 14:57:17 -0800
Subject: [uClinux-dev] How to load kernel modules in C
Message-ID: <9F77D654ED40B74CA79E5A60B97A087B042442@sd-exchange.sdesigns.com>

Thats what i'm already doing. But i want to eliminate the external program.

-- 
Fabrice Gautier, 
Fabrice_Gautier at sdesigns.com


> -----Original Message-----
> From: Kendrick Hamilton [mailto:hamilton at sedsystems.ca]
> Sent: Friday, March 14, 2003 6:25 AM
> To: Uclinux-Dev (E-mail)
> Subject: Re: [uClinux-dev] How to load kernel modules in C
> 
> 
> Fabrice,
> 	all you need to do is use the system function call.
> 
> 	system("/sbin/insmod mymodule");
> This will vfork and exec a shell which then executes the 
> insmod. If you
> want to eliminate the shell startup from the code, do the 
> vfork and exec
> in your program.
> Kendrick
> 
> On Thu, 13 Mar 2003, Fabrice Gautier wrote:
> 
> > Hi,
> >
> > Is there somewhere some non-GPL C code to load a kernel module ?
> >
> > Right now I'm calling an external insmod program (busybox) 
> to load a kernel
> > module but i would like to include the C functions that 
> does that directly
> > in my program. But since busybox is GPL i cannot just take 
> the busybox
> > insmod code and include it in this non-GPL program.
> >
> > So i'm looking for either:
> > a) Some code with a friendly license (like a BSD or similar).
> > b) Some documentation that explains the kernel API used to 
> load a module. (I
> > could look at the busybox code, to understand the kernel 
> APIs, but i feel
> > the result would probably be too much like the GPL code, 
> and be considered a
> > derviative work...)
> >
> > Thanks
> >
> > --
> > Fabrice Gautier,
> > Fabrice_Gautier at sdesigns.com
> > _______________________________________________
> > uClinux-dev mailing list
> > uClinux-dev at uclinux.org
> > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> > This message was resent by uclinux-dev at uclinux.org
> >
> 
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org
> 



From jwilliams at itee.uq.edu.au  Fri Mar 14 18:48:49 2003
From: jwilliams at itee.uq.edu.au (John Willlams)
Date: Sat, 15 Mar 2003 09:48:49 +1000
Subject: [uClinux-dev] realtime scheduling...
Message-ID: <002a01c2ea84$4343e1a0$0307a8c0@john.qut.edu.au>

Hi Geoff,

From: Geoffrey Espin <espin at idiom.com>
>That was the conclusion of a recent article at:
>
> http://www.linuxdevices.com/articles/AT6416763926.html
>
>by Axis on ETRAX.

Thanks for that - interesting reading, particularly the comparison table.

John





From laili at interepoch.com.tw  Thu Mar 13 22:44:09 2003
From: laili at interepoch.com.tw (=?big5?B?p/Ug8bA=?=)
Date: Fri, 14 Mar 2003 11:44:09 +0800
Subject: [uClinux-dev] net-snmp in embedded system
Message-ID: <02c701c2e9db$f85f4ce0$88a8a8c0@lai>

hi all:

I am a engineer in InterEpoch in Taiwan , this is web's url of my company www.interepoch.com.tw.
I want to add SNMP agent in our wireless lan AP product, so i deside to used NET-SNMP.
But the snmpd file size is about 800kbyte witch is too large for our embedded platform (4MB flash memory).
i try to reduse NET-SNMP code size in many ways such as removing snmpv3 ,debugging msg, 
app ( we dont need in agent product)..., only reduse 40kbyte.

how can i reduse  NET-SNMP size ? 

thank you.

lai li
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20030314/0ae15ca1/attachment.html>

From juanbaromance at yahoo.es  Fri Mar 14 05:30:10 2003
From: juanbaromance at yahoo.es (=?iso-8859-1?q?juanba=20romance=20gallego?=)
Date: Fri, 14 Mar 2003 11:30:10 +0100 (CET)
Subject: [uClinux-dev] MCF5282 Development
Message-ID: <20030314103010.2748.qmail@web40911.mail.yahoo.com>

Hi, we are starting to design a project using the new
5282 ColdFire processor, uCLinux-2.4 version will be
used. I would like to know which tasks, drivers,
kernel porting are currently on-going for the chipset
periphericals, core and so forth, and how this work
is/will/could be time scheduled

Uhmm up today we have been working with the MCF5206,
now our design is being reviewed from many points of
view. Our local distributor has adviced us to upgrade
to this new one CF. Our io-interface requirements are
really hard, i.e. From our p.o.v. the CAN bus
interface is mandatory, we map up to two i82527 CAN
interfaces for the old design, other interfaces
are/will be used.

Have someone any information about?

Thanks in advanced



=====
Juanba Romance

___________________________________________________
Yahoo! Messenger - Nueva versi?n GRATIS
Super Webcam, voz, caritas animadas, y m?s...
http://messenger.yahoo.es


From capt_jerry5 at hotmail.com  Fri Mar 14 08:08:08 2003
From: capt_jerry5 at hotmail.com (Jerry O'Brien)
Date: Fri, 14 Mar 2003 13:08:08 +0000
Subject: [uClinux-dev] ARM7/Integrator port pointers
Message-ID: <BAY2-F153aEQxRBvuUq000644ea@hotmail.com>

Hi folks,

I hope this isn't too much of a FAQ.  I've checked all the docs on 
uclinux.org, and I've also read all the past archives of this list.

However, I'm stuck trying to get a version of uclinux to compile on an 
ARM7/Integrator platform.

I'm familiar with Linux on various platforms (x86, SPARC, PPC), and happy in 
kernel development esp. drivers. I also am happy to build an ARM 
cross-compiler and binutils.

However, I'm unsure what kernel I'm best starting with for a uclinux patch.  
I need a 2.4 kernel, since i have an existing PCI device I want to get 
working on the Integrator.

Any hints or tips to starting points? I tried looking at the wirespeed.com 
and aplio.fr sites, but they both appear dead...

I know this has probably been done by you folks many times, and you are 
probably fed up of answering this faq, but I hope a reply from the list will 
save me heaps of time.

Has this been successfully done before? I don't have an MMU, so I cannot use 
the standard ARM-Linux kernel.

Kindest Regds,
Jerry.

_________________________________________________________________
It's fast, it's easy and it's free. Get MSN Messenger today! 
http://messenger.msn.co.uk



From fwmiller at cornfed.com  Fri Mar 14 21:34:14 2003
From: fwmiller at cornfed.com (Frank W. Miller)
Date: Fri, 14 Mar 2003 21:34:14 -0500
Subject: [uClinux-dev] Help with Motorola 68vz328ads eval board
Message-ID: <3E729126.5010303@cornfed.com>

Greetings,

I've been blessed with a Motorola 68VZ328ADS Eval Board that includes a 
monochrome 320x240 LCD with Touch Panel Interface.  I've done a bit of 
development with it using the Metrowerks tools during the eval period 
but I'd really prefer to do my development using Linux.  I was hoping I 
might find some guidance here.  This board is the eval system that 
mirrors most closely the Palm systems.  I believe it can run Palm OS if 
loaded correctly.  Anyway, I need help with aquiring the right gcc based 
development tools, a bootloader, and debugger if possible.

Many thanks in advance,
FM

Frank W. Miller
fwmiller at cornfed.com



From stevelin at avalent.com  Fri Mar 14 23:25:47 2003
From: stevelin at avalent.com (Steve S Lin)
Date: Fri, 14 Mar 2003 20:25:47 -0800
Subject: [uClinux-dev] ARM7/Integrator port pointers
References: <BAY2-F153aEQxRBvuUq000644ea@hotmail.com>
Message-ID: <01cc01c2eaaa$f6e92690$a801a8c0@stevesvaio>

Hi Jerry,

Just download from the uclinux distribution instead of patching for a quick
jumpstart (it contains 2.4.20uc kernel now already patched)
http://www.uclinux.org/pub/uClinux/dist/

Then grab the precompiled toolchain from here:
http://www.uclinux.org/pub/uClinux/m68k-elf-tools/arm-elf-tools-20011219.tar
.gz

And you're ready to start building. You'll need to configure for your
particular board-- I'm not sure if its already been added to the dist, but
if not just add to $PATH/uClinux-dist/vendors/<vendor_name>/<platform_name>.

I think there was a HOW-TO on this a while back ago, but (hopefully) it
shouldn't be too bad provided you have the programmer's manual for the
board. Happy hacking!

            --Steve

----- Original Message -----
From: "Jerry O'Brien" <capt_jerry5 at hotmail.com>
To: <uclinux-dev at uclinux.org>
Cc: <capt_jerry at hotmail.com>
Sent: Friday, March 14, 2003 5:08 AM
Subject: [uClinux-dev] ARM7/Integrator port pointers


> Hi folks,
>
> I hope this isn't too much of a FAQ.  I've checked all the docs on
> uclinux.org, and I've also read all the past archives of this list.
>
> However, I'm stuck trying to get a version of uclinux to compile on an
> ARM7/Integrator platform.
>
> I'm familiar with Linux on various platforms (x86, SPARC, PPC), and happy
in
> kernel development esp. drivers. I also am happy to build an ARM
> cross-compiler and binutils.
>
> However, I'm unsure what kernel I'm best starting with for a uclinux
patch.
> I need a 2.4 kernel, since i have an existing PCI device I want to get
> working on the Integrator.
>
> Any hints or tips to starting points? I tried looking at the wirespeed.com
> and aplio.fr sites, but they both appear dead...
>
> I know this has probably been done by you folks many times, and you are
> probably fed up of answering this faq, but I hope a reply from the list
will
> save me heaps of time.
>
> Has this been successfully done before? I don't have an MMU, so I cannot
use
> the standard ARM-Linux kernel.
>
> Kindest Regds,
> Jerry.
>
> _________________________________________________________________
> It's fast, it's easy and it's free. Get MSN Messenger today!
> http://messenger.msn.co.uk
>
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org
>



From yangyajun at hisense.cngb.com  Sat Mar 15 02:01:01 2003
From: yangyajun at hisense.cngb.com (=?gb2312?B?0e7Rx778?=)
Date: Sat, 15 Mar 2003 15:01:01 +0800
Subject: [uClinux-dev] MTD and jffs question?
Message-ID: <001d01c2eac0$a3990490$542289c0@LocalHost>

Hi,all
   I want to use jffs on my 5272 board,I used MTD. I created a partition on my
 AMD 29lv16 flash,and mknod a inode under /dev:
                   mtd0 b 30 0 
When the board boot ,it shows that the partition is created successfully.but 
when I run:
         mount -t jffs /dev/mtd0 /mnt
It return errors like that:
         mount:Mounting /dev/mtd0 on /mnt failed:Unknown error 6
I go to /proc and run:
           cat mtd
It  returns:
          dev:        size     erasesize       name 
          mtd0      00200000   00010000      "jffs (2M)"   

And when I run:
          cat devices
Under "Block devices",it only shows:
          1  ramdisk
          31 Blkmem
There is no mtd.(I use  blkmem to support Romfs at the same time)

What should I do? 
Any help is appreciated!

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20030315/add6f18b/attachment.html>

From sjchen_seu at hotmail.com  Sat Mar 15 02:46:43 2003
From: sjchen_seu at hotmail.com (Chen sj)
Date: Sat, 15 Mar 2003 15:46:43 +0800
Subject: [uClinux-dev] net-snmp in embedded system
Message-ID: <F147k69RKLpgTFur2iz000003f4@hotmail.com>

An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20030315/b73e5be2/attachment.html>

From eauth at softsys.co.at  Sat Mar 15 03:53:26 2003
From: eauth at softsys.co.at (Erwin Authried)
Date: Sat, 15 Mar 2003 09:53:26 +0100
Subject: [uClinux-dev] MTD and jffs question?
In-Reply-To: <001d01c2eac0$a3990490$542289c0@LocalHost>
Message-ID: <CBEPKHHODMBKHCMLAGBMKEKECCAA.eauth@softsys.co.at>

Hi,
there should be no need to use blkmem anymore. Use MTD's mtdblock_ro driver
instead. You will need a device node mtdblock0. mtd0 is usually used as the
name of the character device.
     @mtdblock0,b,31,0
Mount with:
    mount -t jffs /dev/mtdblock0 /mnt

jffs doesn't actually use the block driver, it's just used as a handle for
the MTD device.

Regards,
Erwin
  -----Urspr?ngliche Nachricht-----
  Von: uclinux-dev-admin at uclinux.org
[mailto:uclinux-dev-admin at uclinux.org]Im Auftrag von ???
  Gesendet: Samstag, 15. M?rz 2003 08:01
  An: uclinux-dev at uclinux.org
  Betreff: [uClinux-dev] MTD and jffs question?


  Hi,all
     I want to use jffs on my 5272 board,I used MTD. I created a partition
on my
   AMD 29lv16 flash,and mknod a inode under /dev:
                     mtd0 b 30 0
  When the board boot ,it shows that the partition is created
successfully.but
  when I run:
           mount -t jffs /dev/mtd0 /mnt
  It return errors like that:
           mount:Mounting /dev/mtd0 on /mnt failed:Unknown error 6
  I go to /proc and run:
             cat mtd
  It  returns:
            dev:        size     erasesize       name
            mtd0      00200000   00010000      "jffs (2M)"

  And when I run:
            cat devices
  Under "Block devices",it only shows:
            1  ramdisk
            31 Blkmem
  There is no mtd.(I use  blkmem to support Romfs at the same time)

  What should I do?
  Any help is appreciated!

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20030315/de76549c/attachment.html>

From yangyajun at hisense.cngb.com  Sat Mar 15 04:28:06 2003
From: yangyajun at hisense.cngb.com (=?gb2312?B?0e7Rx778?=)
Date: Sat, 15 Mar 2003 17:28:06 +0800
Subject: [uClinux-dev] MTD and jffs question?
References: <CBEPKHHODMBKHCMLAGBMKEKECCAA.eauth@softsys.co.at>
Message-ID: <001101c2ead5$2fecb1d0$542289c0@LocalHost>

   I use blkmem to support romfs for my first flash on my board(myboard have two flashes,and I want to use the first onet to support romfs to hold my kernel,and the second onet to support jffs to hold my data).
  Why there is no mtd device under /proc/devices? Does it have any effect to support jffs?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20030315/072c66de/attachment.html>

From g.menie at wanadoo.fr  Sat Mar 15 04:53:04 2003
From: g.menie at wanadoo.fr (Georges Menie)
Date: 15 Mar 2003 10:53:04 +0100
Subject: [uClinux-dev] Help with Motorola 68vz328ads eval board
In-Reply-To: <3E729126.5010303@cornfed.com>
References: <3E729126.5010303@cornfed.com>
Message-ID: <1047721984.514.23.camel@troca>

On Sat, 2003-03-15 at 03:34, Frank W. Miller wrote:
> 
> Greetings,
> 
> I've been blessed with a Motorola 68VZ328ADS Eval Board that includes a 
> monochrome 320x240 LCD with Touch Panel Interface.  I've done a bit of 
> development with it using the Metrowerks tools during the eval period 
> but I'd really prefer to do my development using Linux.  I was hoping I 
> might find some guidance here.  This board is the eval system that 
> mirrors most closely the Palm systems.  I believe it can run Palm OS if 
> loaded correctly.  Anyway, I need help with aquiring the right gcc based 
> development tools, a bootloader, and debugger if possible.

You will find at: http://www.uclinux.org/pub/uClinux/dist/
the gcc devlopment tool and the full source distribution of uClinux.
It contains a kernel 2.0.x environment with Palm support and a kernel
2.4.x environment with 3 different 68vz328 board support. I did not try
Palm support but the 68VZ628 is well supported. You might have to choose
the closest board environment and start modify the files to build and
run an image for your board.

Important directories are:

board specific build environment
uClinux-dist/vendors/*/* 

kernel files (startup code and memory layout):
uClinux-dist/linux-2.0.x/arch/m68knommu/platform/* or
uClinux-dist/linux-2.4.x/arch/m68knommu/platform/68VZ328/*

k2.0 does not contains a vz328 directory but it variuos palm support
files. Look at the files in both kernel, decide which kernel you are
going to use, then start modify the files. When you will have a working
image, consider creating a new platform, there is a HOW-TO doc in
uClinux-dist/Documentation about adding a new platform.

Regards,
Georges




From rgegusch at mf.tu-berlin.de  Sat Mar 15 07:03:12 2003
From: rgegusch at mf.tu-berlin.de (Rene Gegusch)
Date: Sat, 15 Mar 2003 13:03:12 +0100
Subject: [uClinux-dev] Problems compiling for uCdimm
In-Reply-To: <Pine.NEB.4.44.0303141302090.24160-100000@vex.net>
References: <Pine.NEB.4.44.0303141302090.24160-100000@vex.net>
Message-ID: <200303151303.12309.rgegusch@mf.tu-berlin.de>

I think we are using the same board. I do have the uCevolution developer board 
and using the uCdimm5272 which is using a MOTOROLA Coldfire 5272 Processor.

Regarding your question towards Arcturus:
I do have contact to one special guy there...


Am Freitag, 14. M?rz 2003 19:04 schrieb patrick:
> On Fri, 14 Mar 2003, Rene Gegusch wrote:
> > I don't think that your machine power causes this error :)
>
> Well, machine horsepower.  :)  The little machine I was using would place
> the compile process on the running queue indefinately due to lack of RAM.
>
> :(  Even with 256 MB of swap.
> :
> > Which board are you using?
> > I am using the Arcturus uC5272 board and also have problems to compile
> > the latest distribution.
>
> Which isthe uC5272?  I'm using the uCevolution, also by Arcturus,
> revision 1.1.
>
> > which are not at cvs.uclinux.org and so not in uClinux-dist.
>
> Have you tried contactint support at arcturusnetworks.com directly for the
> files?
>
> Patrick Pritchard <patrick at tendim.cjb.net>
> University of Toronto Blue Sky Solar
> Telemetry Systems Project Manager
>
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org




From eepaul at peoplemail.com.cn  Sat Mar 15 07:27:09 2003
From: eepaul at peoplemail.com.cn (Paul)
Date: Sat, 15 Mar 2003 20:27:09 +0800
Subject: [uClinux-dev] uClinux for 5272 did _not_ make use of 4K local memory of 5272???
References: <01448C8B0D53D411B83B005004A5BB6E7202D3@ER>
Message-ID: <000701c2eaee$3d73a3e0$a88c00a8@fdpl>

Hi:
    I read some source code of uClinux for 5272.
    I think uClinux did not use 5272's 4k local memory. Is that true??

   
Regards
Paul



From davidm at snapgear.com  Sat Mar 15 07:38:41 2003
From: davidm at snapgear.com (David McCullough)
Date: Sat, 15 Mar 2003 22:38:41 +1000
Subject: [uClinux-dev] Problems compiling m68k-elf toolchain
In-Reply-To: <Pine.NEB.4.44.0303141252130.24160-100000@vex.net>
References: <20030314081013.GA28190@beast.internal.moreton.com.au> <Pine.NEB.4.44.0303141252130.24160-100000@vex.net>
Message-ID: <20030315123841.GB14525@beast.internal.moreton.com.au>

Jivin patrick lays it down ...
> > Its stage6?  the C++ stage that usually shows up the problems.  libio is
> > the main offender,
> 
> Correct.  My last error showed:
> 
> In file included from ../../../gcc-2.95.3/libio/libio.h:30,
>                  from ../../../gcc-2.95.3/libio/iolibio.h:1,
>                  from ../../../gcc-2.95.3/libio/libioP.h:47,
>                  from ../../../gcc-2.95.3/libio/filedoalloc.c:45:
> _G_config.h:33: parse error before `_G_fpos_t'
> _G_config.h:33: warning: data definition has no type or storage class
> In file included from ../../../gcc-2.95.3/libio/libioP.h:47,
>                  from ../../../gcc-2.95.3/libio/filedoalloc.c:45:
> ../../../gcc-2.95.3/libio/iolibio.h:13: parse error before `_G_fpos_t'
> ../../../gcc-2.95.3/libio/iolibio.h:18: parse error before `*'
> make[1]: *** [filedoalloc.o] Error 1
> make[1]: Leaving directory
> `/usr/src/uClinux/m68k-elf-tools/tools-20020410/m68k-elf-gcc/m68k-elf/libio'
> make: *** [all-target-libio] Error 2

Just to be absolutely sure you are using this uClibc tarball for the
uClibc sources:

http://www.uclinux.org/pub/uClinux/m68k-elf-tools/tools-20020410/uClibc.tar.gz

Any other uClibc is unlikely to work :-)

Cheers,
Davidm

-- 
David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
davidm at snapgear.com  Fx: +61 7 3891 3630  Custom Embedded Solutions + Security


From davidm at snapgear.com  Sat Mar 15 08:00:50 2003
From: davidm at snapgear.com (David McCullough)
Date: Sat, 15 Mar 2003 23:00:50 +1000
Subject: [uClinux-dev] uclinux-elf-tools-20030314 released
Message-ID: <20030315130050.GC14525@beast.internal.moreton.com.au>

Hi all,

I have put up a new release of the uClinux-elf-tools ARM and m68k toolchains
on uClinux.org:

	http://www.uclinux.org/pub/uClinux/m68k-elf-tools/

This release uses STLport for C++ support, uClibc-0.9.19 with pthreads
and full XIP/non-XIP applications on m68k and ARM. It still provides flat
format shared libraries for the m68k tool chain, the arm folks will have
to wait a while longer yet. The latest ARMulator and a working
m68k-bdm-elf-gdb are included. The binary package is now a self
extracting script so that it can take care of cleaning up from previous
installations which is critical to a working toolchain. 

Quite a lot of changes in this one so let me know if you encounter any
problems using,  compiling, or installing the tools.  Be sure to read
the README-20030314 for more info,

Cheers,
Davidm

-- 
David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
davidm at snapgear.com  Fx: +61 7 3891 3630  Custom Embedded Solutions + Security


From richard.klingler at violasystems.com  Sat Mar 15 08:09:20 2003
From: richard.klingler at violasystems.com (Richard Klingler)
Date: Sat, 15 Mar 2003 15:09:20 +0200
Subject: [uClinux-dev] uClinux for 5272 did _not_ make use of 4K local memory of 5272???
In-Reply-To: <000701c2eaee$3d73a3e0$a88c00a8@fdpl>
Message-ID: <r01050400-1024-55E66C2456E711D7A40700039387ACB6@[10.0.1.2]>

> Hi:
>     I read some source code of uClinux for 5272.
>     I think uClinux did not use 5272's 4k local memory. Is that true??
> 

In my case it does (o;

Well...you can map some of your code into SRAM for faster execution...


Rick



Richard Klingler             mail: richard.klingler at violasystems.com
Viola Systems Ltd.           http://www.violasystems.com/
Lemmink?isenkatu 32          phon: +358 (0)201 226 226
20520 Turku, Finland         mobile: +358 (0)40 748 4711


From davidm at snapgear.com  Sat Mar 15 09:00:32 2003
From: davidm at snapgear.com (David McCullough)
Date: Sun, 16 Mar 2003 00:00:32 +1000
Subject: [uClinux-dev] Re: uclinux-elf-tools-20030314 released
In-Reply-To: <3E732EBA.35486AFA@pandora.be>
References: <20030315130050.GC14525@beast.internal.moreton.com.au> <3E732EBA.35486AFA@pandora.be>
Message-ID: <20030315140032.GA14615@beast.internal.moreton.com.au>

Jivin Patrick Pelgrims lays it down ...
> Is the script to re-build the complete toolschain included David ?

Yes,  everything I used to build them is included,  the script is called
build-uclinux-elf-tools.sh,  look under:

	http://www.uclinux.org/pub/uClinux/m68k-elf-tools/tools-20030314/

let me know if there is anything missing,

Cheers,
Davidm


> David McCullough wrote:
> 
> > Hi all,
> >
> > I have put up a new release of the uClinux-elf-tools ARM and m68k toolchains
> > on uClinux.org:
> >
> >         http://www.uclinux.org/pub/uClinux/m68k-elf-tools/
> >
> > This release uses STLport for C++ support, uClibc-0.9.19 with pthreads
> > and full XIP/non-XIP applications on m68k and ARM. It still provides flat
> > format shared libraries for the m68k tool chain, the arm folks will have
> > to wait a while longer yet. The latest ARMulator and a working
> > m68k-bdm-elf-gdb are included. The binary package is now a self
> > extracting script so that it can take care of cleaning up from previous
> > installations which is critical to a working toolchain.
> >
> > Quite a lot of changes in this one so let me know if you encounter any
> > problems using,  compiling, or installing the tools.  Be sure to read
> > the README-20030314 for more info,
> >
> > Cheers,
> > Davidm

-- 
David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
davidm at snapgear.com  Fx: +61 7 3891 3630  Custom Embedded Solutions + Security


From masterkristof at yahoo.com  Sat Mar 15 09:10:40 2003
From: masterkristof at yahoo.com (Kristof Bruyninckx)
Date: Sat, 15 Mar 2003 06:10:40 -0800 (PST)
Subject: [uClinux-dev] Re: Cdrom support??
Message-ID: <20030315141040.54888.qmail@web11002.mail.yahoo.com>

--- Kristof Bruyninckx <masterkristof at yahoo.com>
wrote:
> Hi everybody,
> 
> I left the kernel 2.4.x for what it is for the
> moment (I always got errors when I included the
cdrom support and ISO 9660) and started trying with
the 2.0.x version and everything compiles (included
cdrom support and iso 9660) without an error I already
mounted a Hard
Drive to the MC5249C3 with some MP3 files and I can
play them.A bit fuzzy but it works. But what I am not
able to do is to mount my CDROM.When I do mount the
cdrom as device hda I get the following errors:
(see attach)
 
know I think these are normal because I'm trying to
mount a cdrom while this is for a Hard drive. But
during booting my bord sees this as hda. And I can't
find the right device for it in the dir DEV.
So my guess would be to make the device in this
directory DEV on the pc and do MAKE again. But now
my question is could this be correct and how do I do
this? I already tried to chanche hda with mknod but
i did not work or I have done something wrong? 
> 
> Yours truly and hoping for a reply,
> 
> A learning student of Denayer college,
> 
> 
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Web Hosting - establish your business online
> http://webhosting.yahoo.com> hda: irq timeout:
status=0x50
> hda: irq timeout: status=0x50
> hda: irq timeout: status=0x50
> hda: irq timeout: status=0x50
> hda: ATAPI reset complete
> hda: irq timeout: status=0x00
> hda: irq timeout: status=0x00
> hda: irq timeout: status=0x00
> hda: irq timeout: status=0x00
> hda: ATAPI reset complete
> hda: irq timeout: status=0x00
> end_request: I/O error, dev 03:00, sector 0
> hda: irq timeout: status=0x00
> hda: irq timeout: status=0x00
> hda: irq timeout: status=0x00


__________________________________________________
Do you Yahoo!?
Yahoo! Web Hosting - establish your business online
http://webhosting.yahoo.com


From cheluvi at yahoo.com  Fri Mar 14 23:59:32 2003
From: cheluvi at yahoo.com (v.nagasrinivas)
Date: Sat, 15 Mar 2003 10:29:32 +0530
Subject: [uClinux-dev] net-snmp in embedded system
References: <02c701c2e9db$f85f4ce0$88a8a8c0@lai>
Message-ID: <3E72B334.DD0A6200@yahoo.com>

HI,

             I have downloaded the net-snmp latest and compiled and
installed and check the
snmpd      .....................showing 101k ( everything on i686
machine...)
and these figures are without doing flthdr running etc....

So the memories of net-snmp installed files also i put here...

from this when you take only     /sbin/snmpd ------------101k
I don't the involvement of libfiles   as /lib showing --------9.1M (i
think without these also the net-snmp runs..)
and the mibs files total finally depends on you which one do you need to
supply for the customer..

---combining the stds mibs and your private mibs total...that never
follows the

following figure...
Could you give more information for analysation..........

Thanks,
srinivas.



cheluvi at srinivas:~/net-snmp/sbin$ ls -lh
total 272k
-rwxr-xr-x    1 cheluvi  cheluvi      101k Mar 15 09:59 snmpd
-rwxr-xr-x    1 cheluvi  cheluvi      160k Mar 15 09:59 snmptrapd
cheluvi at srinivas:~/net-snmp/sbin$

--------------------------------------------------
cheluvi at srinivas:~/net-snmp$ du -ch
116k ./include/net-snmp/system
8.0k ./include/net-snmp/machine
356k ./include/net-snmp/library
172k ./include/net-snmp/agent
744k ./include/net-snmp
748k ./include
1.2M ./bin
9.1M ./lib
276k ./sbin
24k ./share/snmp/snmpconf-data/snmp-data
36k ./share/snmp/snmpconf-data/snmpd-data
16k ./share/snmp/snmpconf-data/snmptrapd-data
80k ./share/snmp/snmpconf-data
1.2M ./share/snmp/mibs
1.3M ./share/snmp
1.3M ./share
108k ./man/man1
420k ./man/man3
64k ./man/man5
20k ./man/man8
616k ./man
13M .
13M total
cheluvi at srinivas:~/net-snmp$
----------------------------------------------------------------------


?? ?? wrote:

> hi all: I am a engineer in InterEpoch in Taiwan , this is web's url of
> my company www.interepoch.com.tw.I want to add SNMP agent in our
> wireless lan AP product, so i deside to used NET-SNMP.But the snmpd
> file size is about 800kbyte witch is too large for our embedded
> platform (4MB flash memory).i try to reduse NET-SNMP code size in many
> ways such as removing snmpv3 ,debugging msg,app ( we dont need in
> agent product)..., only reduse 40kbyte. how can i reduse  NET-SNMP
> size ? thank you. lai li
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20030315/516854fc/attachment.html>

From patrick.pelgrims at pandora.be  Sat Mar 15 08:46:34 2003
From: patrick.pelgrims at pandora.be (Patrick Pelgrims)
Date: Sat, 15 Mar 2003 14:46:34 +0100
Subject: [uClinux-dev] Re: uclinux-elf-tools-20030314 released
References: <20030315130050.GC14525@beast.internal.moreton.com.au>
Message-ID: <3E732EBA.35486AFA@pandora.be>

Is the script to re-build the complete toolschain included David ?

Greatings,

P. Pelgrims

David McCullough wrote:

> Hi all,
>
> I have put up a new release of the uClinux-elf-tools ARM and m68k toolchains
> on uClinux.org:
>
>         http://www.uclinux.org/pub/uClinux/m68k-elf-tools/
>
> This release uses STLport for C++ support, uClibc-0.9.19 with pthreads
> and full XIP/non-XIP applications on m68k and ARM. It still provides flat
> format shared libraries for the m68k tool chain, the arm folks will have
> to wait a while longer yet. The latest ARMulator and a working
> m68k-bdm-elf-gdb are included. The binary package is now a self
> extracting script so that it can take care of cleaning up from previous
> installations which is critical to a working toolchain.
>
> Quite a lot of changes in this one so let me know if you encounter any
> problems using,  compiling, or installing the tools.  Be sure to read
> the README-20030314 for more info,
>
> Cheers,
> Davidm
>
> --
> David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
> davidm at snapgear.com  Fx: +61 7 3891 3630  Custom Embedded Solutions + Security
>
> ________________________________________________________________________
> ColdFire Discussion List
> See: <http://www.WildRice.com/ColdFire/>




From tchen at on-go.com  Sat Mar 15 16:08:00 2003
From: tchen at on-go.com (thomas chen)
Date: Sat, 15 Mar 2003 16:08:00 -0500
Subject: [uClinux-dev] uclinux-elf-tools-20030314 released
References: <20030315130050.GC14525@beast.internal.moreton.com.au>
Message-ID: <3E739630.CD603AC5@on-go.com>

since uclinux 2.4.20 just came out... is there correlation between
2.4.20 and the new tool chain.... ie do you need new tool chain in order
to get the 2.4.20 to work or vice versa?

just curious


David McCullough wrote:
> 
> Hi all,
> 
> I have put up a new release of the uClinux-elf-tools ARM and m68k toolchains
> on uClinux.org:
> 
>         http://www.uclinux.org/pub/uClinux/m68k-elf-tools/
> 
> This release uses STLport for C++ support, uClibc-0.9.19 with pthreads
> and full XIP/non-XIP applications on m68k and ARM. It still provides flat
> format shared libraries for the m68k tool chain, the arm folks will have
> to wait a while longer yet. The latest ARMulator and a working
> m68k-bdm-elf-gdb are included. The binary package is now a self
> extracting script so that it can take care of cleaning up from previous
> installations which is critical to a working toolchain.
> 
> Quite a lot of changes in this one so let me know if you encounter any
> problems using,  compiling, or installing the tools.  Be sure to read
> the README-20030314 for more info,
> 
> Cheers,
> Davidm
> 
> --
> David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
> davidm at snapgear.com  Fx: +61 7 3891 3630  Custom Embedded Solutions + Security
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org


From tendim at tendim.cjb.net  Sat Mar 15 18:05:12 2003
From: tendim at tendim.cjb.net (patrick)
Date: Sat, 15 Mar 2003 18:05:12 -0500 (EST)
Subject: [uClinux-dev] Problems compiling m68k-elf toolchain
In-Reply-To: <20030315123841.GB14525@beast.internal.moreton.com.au>
Message-ID: <Pine.NEB.4.44.0303151800280.24160-100000@vex.net>

On Sat, 15 Mar 2003, David McCullough wrote:

> Just to be absolutely sure you are using this uClibc tarball for the
> uClibc sources:
>
> http://www.uclinux.org/pub/uClinux/m68k-elf-tools/tools-20020410/uClibc.tar.gz
>
> Any other uClibc is unlikely to work :-)

Yes.  I tried using the CVS uClibc as well as the one you just listed, but
both fail.  Again, this is all with latest CVS 2.0.x and 2.4.x kernel.

-patrick

>
> Cheers,
> Davidm
>
> --
> David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
> davidm at snapgear.com  Fx: +61 7 3891 3630  Custom Embedded Solutions + Security
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org
>

Patrick Pritchard <patrick at tendim.cjb.net>
University of Toronto Blue Sky Solar
Telemetry Systems Project Manager



From davidm at snapgear.com  Sat Mar 15 18:23:09 2003
From: davidm at snapgear.com (David McCullough)
Date: Sun, 16 Mar 2003 09:23:09 +1000
Subject: [uClinux-dev] uclinux-elf-tools-20030314 released
In-Reply-To: <3E739630.CD603AC5@on-go.com>
References: <20030315130050.GC14525@beast.internal.moreton.com.au> <3E739630.CD603AC5@on-go.com>
Message-ID: <20030315232308.GA23312@beast.internal.moreton.com.au>

Jivin thomas chen lays it down ...
> 
> since uclinux 2.4.20 just came out... is there correlation between
> 2.4.20 and the new tool chain.... ie do you need new tool chain in order
> to get the 2.4.20 to work or vice versa?

Absolutely not.   The old tool chains is what we have been using until
now without any problems.

This is really just to fix some bugs in the setup, clean up problems with
pthread and XIP,  and also to improve the C++ support for both platforms,

If you are happy with what you have then there is no need to change :-)

Cheers,
Davidm

-- 
David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
davidm at snapgear.com  Fx: +61 7 3891 3630  Custom Embedded Solutions + Security


From davidm at snapgear.com  Sat Mar 15 18:31:14 2003
From: davidm at snapgear.com (David McCullough)
Date: Sun, 16 Mar 2003 09:31:14 +1000
Subject: [uClinux-dev] Problems compiling m68k-elf toolchain
In-Reply-To: <Pine.NEB.4.44.0303151800280.24160-100000@vex.net>
References: <20030315123841.GB14525@beast.internal.moreton.com.au> <Pine.NEB.4.44.0303151800280.24160-100000@vex.net>
Message-ID: <20030315233114.GD23312@beast.internal.moreton.com.au>

Jivin patrick lays it down ...
> On Sat, 15 Mar 2003, David McCullough wrote:
> 
> > Just to be absolutely sure you are using this uClibc tarball for the
> > uClibc sources:
> >
> > http://www.uclinux.org/pub/uClinux/m68k-elf-tools/tools-20020410/uClibc.tar.gz
> >
> > Any other uClibc is unlikely to work :-)
> 
> Yes.  I tried using the CVS uClibc as well as the one you just listed, but
> both fail.  Again, this is all with latest CVS 2.0.x and 2.4.x kernel.

The only thing I can think of is that it is somehow getting headers from
somewhere it shouldn't.  No idea where or how though.

Try the new build script (20030314) and see how that goes, it doesn't
use libio/libstdc++ from the compiler any more,

Cheers,
Davidm

-- 
David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
davidm at snapgear.com  Fx: +61 7 3891 3630  Custom Embedded Solutions + Security


From tchen at on-go.com  Sat Mar 15 20:15:57 2003
From: tchen at on-go.com (thomas chen)
Date: Sat, 15 Mar 2003 20:15:57 -0500
Subject: [uClinux-dev] BOA question
Message-ID: <3E73D04D.D5F8031A@on-go.com>

i tried to get boa running under uclinux

it is failing for "no such user nobody"

in default boa.conf

there is 

user nobody
group nogroup

should this be changed? or should a user directory be created
called nobody?

thanks


From fwmiller at cornfed.com  Sat Mar 15 20:46:26 2003
From: fwmiller at cornfed.com (Frank W. Miller)
Date: Sat, 15 Mar 2003 20:46:26 -0500
Subject: [uClinux-dev] Help with Motorola 68vz328ads eval board
In-Reply-To: <1047721984.514.23.camel@troca>
References: <3E729126.5010303@cornfed.com> <1047721984.514.23.camel@troca>
Message-ID: <3E73D772.6020708@cornfed.com>

Ok, I'm on my way.  I've got a toolchain (the latest m68k-elf) and the
full source distribution, both of which I have installed and built 
successfully.
I picked the ucdimm platform to build first since I think its probably the
closest to what I've got on the 68VZ328ADS.  The problem now is,
how do I boot the kernel on the board?  I've got a serial connection but
I need some kind of program to load it onto the target.  Does anyone
know where something like this exists?  I've have a DOS program called
bbugv.exe but that won't run (at least I don't know how to make it run)
under Linux.  Can anyone help me with booting this kernel?

Thanks,
FM


Frank W. Miller
fwmiller at cornfed.com


Georges Menie wrote:

>On Sat, 2003-03-15 at 03:34, Frank W. Miller wrote:
>  
>
>>Greetings,
>>
>>I've been blessed with a Motorola 68VZ328ADS Eval Board that includes a 
>>monochrome 320x240 LCD with Touch Panel Interface.  I've done a bit of 
>>development with it using the Metrowerks tools during the eval period 
>>but I'd really prefer to do my development using Linux.  I was hoping I 
>>might find some guidance here.  This board is the eval system that 
>>mirrors most closely the Palm systems.  I believe it can run Palm OS if 
>>loaded correctly.  Anyway, I need help with aquiring the right gcc based 
>>development tools, a bootloader, and debugger if possible.
>>    
>>
>
>You will find at: http://www.uclinux.org/pub/uClinux/dist/
>the gcc devlopment tool and the full source distribution of uClinux.
>It contains a kernel 2.0.x environment with Palm support and a kernel
>2.4.x environment with 3 different 68vz328 board support. I did not try
>Palm support but the 68VZ628 is well supported. You might have to choose
>the closest board environment and start modify the files to build and
>run an image for your board.
>
>Important directories are:
>
>board specific build environment
>uClinux-dist/vendors/*/* 
>
>kernel files (startup code and memory layout):
>uClinux-dist/linux-2.0.x/arch/m68knommu/platform/* or
>uClinux-dist/linux-2.4.x/arch/m68knommu/platform/68VZ328/*
>
>k2.0 does not contains a vz328 directory but it variuos palm support
>files. Look at the files in both kernel, decide which kernel you are
>going to use, then start modify the files. When you will have a working
>image, consider creating a new platform, there is a HOW-TO doc in
>uClinux-dist/Documentation about adding a new platform.
>
>Regards,
>Georges
>
>
>_______________________________________________
>uClinux-dev mailing list
>uClinux-dev at uclinux.org
>http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
>This message was resent by uclinux-dev at uclinux.org
>
>  
>




From bluetoothloo at lycos.com  Sun Mar 16 05:22:11 2003
From: bluetoothloo at lycos.com (Murat Loo)
Date: Sun, 16 Mar 2003 12:22:11 +0200
Subject: [uClinux-dev] m5727c3 ethernet question
Message-ID: <JBJKIJHDIIOPODAA@mailcity.com>

Hi,

I've been hepply using the ethernet driver for for Coldfire boards. Then "something" happened and now I can't use any networked enabled appilcation(telnet, nfs, ftp, ping...) because they can't connect. Yesterday after uclinux booted, I've typed the ifconfig eth0 <ip> command and then I've tried to ping the board. The ping didn't work at first but after some time it worked and I was able mount the nfs server. Then I've added the ifconfig command to /etc/rc and rebooted the board, the ethernet interface worked. But today,  when I ping the board from another machine, ping says XXX trasfer XXX lost %100 loss. I'm not able to mount the nfs server.
Here is the output of the ifconfig command
eth0      Link encap:Ethernet  HWaddr 6B:16:CA:B2:C0:24
          inet addr:139.179.13.100  Bcast:139.179.255.255 Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:557412 errors:1 dropped:0 overruns:0 frame:1
          TX packets:117 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          Base address:0x840
The rx packets count increases evertime I give the ifconfig command.
What may be the problem here? 





_____________________________________________________________
Get 25MB, POP3, Spam Filtering with LYCOS MAIL PLUS for $19.95/year.
http://login.mail.lycos.com/brandPage.shtml?pageId=plus&ref=lmtplus


From richard.klingler at violasystems.com  Sun Mar 16 05:40:09 2003
From: richard.klingler at violasystems.com (Richard Klingler)
Date: Sun, 16 Mar 2003 12:40:09 +0200
Subject: [uClinux-dev] m5727c3 ethernet question
In-Reply-To: <JBJKIJHDIIOPODAA@mailcity.com>
Message-ID: <r01050400-1024-A92BF990579B11D7B11700039387ACB6@[10.0.1.2]>

> eth0      Link encap:Ethernet  HWaddr 6B:16:CA:B2:C0:24
>           inet addr:139.179.13.100  Bcast:139.179.255.255 Mask:255.255.255.0
>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>           RX packets:557412 errors:1 dropped:0 overruns:0 frame:1
>           TX packets:117 errors:0 dropped:0 overruns:0 carrier:0
>           collisions:0 txqueuelen:100
>           Base address:0x840

Your ethernet address looks wrong...where do you set it?

Also the broadcast is set wrong because it still believes
there is classful routing in the world...


Rick


Richard Klingler             mail: richard.klingler at violasystems.com
Viola Systems Ltd.           http://www.violasystems.com/
Lemmink?isenkatu 32          phon: +358 (0)201 226 226
20520 Turku, Finland         mobile: +358 (0)40 748 4711


From g.menie at wanadoo.fr  Sun Mar 16 05:44:30 2003
From: g.menie at wanadoo.fr (Georges Menie)
Date: 16 Mar 2003 11:44:30 +0100
Subject: [uClinux-dev] Help with Motorola 68vz328ads eval board
In-Reply-To: <3E73D772.6020708@cornfed.com>
References: <3E729126.5010303@cornfed.com> <1047721984.514.23.camel@troca> 
	<3E73D772.6020708@cornfed.com>
Message-ID: <1047811470.493.32.camel@troca>

On Sun, 2003-03-16 at 02:46, Frank W. Miller wrote:
> 
> Ok, I'm on my way.  I've got a toolchain (the latest m68k-elf) and the
> full source distribution, both of which I have installed and built 
> successfully.
> I picked the ucdimm platform to build first since I think its probably the
> closest to what I've got on the 68VZ328ADS.  The problem now is,
> how do I boot the kernel on the board?  I've got a serial connection but
> I need some kind of program to load it onto the target.  Does anyone
> know where something like this exists?  I've have a DOS program called
> bbugv.exe but that won't run (at least I don't know how to make it run)
> under Linux.  Can anyone help me with booting this kernel?
> 
> Thanks,
> FM

good, you pass the first ring ;-)
before uploading and running image.bin, check your
linux-x.x.x/System.map file, all the address there should be existing
RAM address on your board, if not, then modify the linker script
(xxx.ld) to locate everything in RAM.
IMHO, the easiest way is to choose the option to run the kernel from ROM
and to change the corresponding linker script (rom.ld probably) to map
everything in RAM (reserve the upper part of RAM like if it were ROM...)
for example, if you have 8MB SDRAM, set the 2 upper MB as 'rom' in the
linker script and the first 6MB as 'ram'. recompile everything.

the address to upload would be the beginning of the 'rom' section,
and the address to start the image would be specified by the symbol
_start (or _stext maybe) in the System.map file.

Another important point is board initialization, check the crt0xxx.S
file to see if it contains all the necessary steps to initialize your
board.

then you have to find a way to upload the generated image.bin file, can
you use xmodem ? I don't know bbugv, but I think some others do use
it...

what kernel did you choose 2.0 or 2.4 ?

Regards,
Georges

> Georges Menie wrote:
> 
> >On Sat, 2003-03-15 at 03:34, Frank W. Miller wrote:
> >  
> >
> >>Greetings,
> >>
> >>I've been blessed with a Motorola 68VZ328ADS Eval Board that includes a 
> >>monochrome 320x240 LCD with Touch Panel Interface.  I've done a bit of 
> >>development with it using the Metrowerks tools during the eval period 
> >>but I'd really prefer to do my development using Linux.  I was hoping I 
> >>might find some guidance here.  This board is the eval system that 
> >>mirrors most closely the Palm systems.  I believe it can run Palm OS if 
> >>loaded correctly.  Anyway, I need help with aquiring the right gcc based 
> >>development tools, a bootloader, and debugger if possible.
> >>    
> >>
> >
> >You will find at: http://www.uclinux.org/pub/uClinux/dist/
> >the gcc devlopment tool and the full source distribution of uClinux.
> >It contains a kernel 2.0.x environment with Palm support and a kernel
> >2.4.x environment with 3 different 68vz328 board support. I did not try
> >Palm support but the 68VZ628 is well supported. You might have to choose
> >the closest board environment and start modify the files to build and
> >run an image for your board.
> >
> >Important directories are:
> >
> >board specific build environment
> >uClinux-dist/vendors/*/* 
> >
> >kernel files (startup code and memory layout):
> >uClinux-dist/linux-2.0.x/arch/m68knommu/platform/* or
> >uClinux-dist/linux-2.4.x/arch/m68knommu/platform/68VZ328/*
> >
> >k2.0 does not contains a vz328 directory but it variuos palm support
> >files. Look at the files in both kernel, decide which kernel you are
> >going to use, then start modify the files. When you will have a working
> >image, consider creating a new platform, there is a HOW-TO doc in
> >uClinux-dist/Documentation about adding a new platform.
> >
> >Regards,
> >Georges




From bluetoothloo at lycos.com  Sun Mar 16 07:13:50 2003
From: bluetoothloo at lycos.com (Murat Loo)
Date: Sun, 16 Mar 2003 14:13:50 +0200
Subject: [uClinux-dev] m5727c3 ethernet question
Message-ID: <INOJBPIPPJEAPDAA@mailcity.com>

 I don't set this address anywhere? So how can I set it? thankx.
--

On Sun, 16 Mar 2003 12:40:09  
 Richard Klingler wrote:
>> eth0      Link encap:Ethernet  HWaddr 6B:16:CA:B2:C0:24
>>           inet addr:139.179.13.100  Bcast:139.179.255.255 Mask:255.255.255.0
>>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>>           RX packets:557412 errors:1 dropped:0 overruns:0 frame:1
>>           TX packets:117 errors:0 dropped:0 overruns:0 carrier:0
>>           collisions:0 txqueuelen:100
>>           Base address:0x840
>
>Your ethernet address looks wrong...where do you set it?
>
>Also the broadcast is set wrong because it still believes
>there is classful routing in the world...
>
>
>Rick
>
>
>Richard Klingler             mail: richard.klingler at violasystems.com
>Viola Systems Ltd.           http://www.violasystems.com/
>Lemmink?isenkatu 32          phon: +358 (0)201 226 226
>20520 Turku, Finland         mobile: +358 (0)40 748 4711
>_______________________________________________
>uClinux-dev mailing list
>uClinux-dev at uclinux.org
>http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
>This message was resent by uclinux-dev at uclinux.org
>


_____________________________________________________________
Get 25MB, POP3, Spam Filtering with LYCOS MAIL PLUS for $19.95/year.
http://login.mail.lycos.com/brandPage.shtml?pageId=plus&ref=lmtplus


From richard.klingler at violasystems.com  Sun Mar 16 07:26:54 2003
From: richard.klingler at violasystems.com (Richard Klingler)
Date: Sun, 16 Mar 2003 14:26:54 +0200
Subject: [uClinux-dev] m5727c3 ethernet question
In-Reply-To: <INOJBPIPPJEAPDAA@mailcity.com>
Message-ID: <r01050400-1024-9280E87257AA11D7B11700039387ACB6@[10.0.1.2]>

>  I don't set this address anywhere? So how can I set it? thankx.
> --
> 

This was a long thread few weeks ago on this mailing list...


Check the archive (o;


Rick


Richard Klingler             mail: richard.klingler at violasystems.com
Viola Systems Ltd.           http://www.violasystems.com/
Lemmink?isenkatu 32          phon: +358 (0)201 226 226
20520 Turku, Finland         mobile: +358 (0)40 748 4711


From gerg at snapgear.com  Sun Mar 16 07:45:29 2003
From: gerg at snapgear.com (Greg Ungerer)
Date: Sun, 16 Mar 2003 22:45:29 +1000
Subject: [uClinux-dev] Re: Cdrom support??
In-Reply-To: <20030315140230.83788.qmail@web11005.mail.yahoo.com>
References: <20030315140230.83788.qmail@web11005.mail.yahoo.com>
Message-ID: <3E7471E9.8000009@snapgear.com>

Hi Kristof,

Kristof Bruyninckx wrote:
> I left the kernel 2.4.x for what it is for the moment
> and started trying with teh 2.0.x version and
> everything compiles (included cdrom support and iso
> 9660) without an error I already mounted a Hard Drive
> to the MC5249C3 with some MP3 files and I can play
> them.A bit fuzzy but it works. But what I am not able
> to do is to mount my CDROM.When I do mount the cdrom
> as device hda I get the following errors:
> (see attach)
> 
> know I think these are normal because I'm trying to
> mount a cdrom while this is for a Hard drive.  But
> during booting my bord sees this as hda. And I can't
> find the right device for it in the dir DEV.
> So my guess would be to make the device in this
> directory DEV on the pc and do MAKE again. But now my
> question is could this be correct and how do I do
> this? I already tried to chanche hda with mknod but i
> did not work or I have done something wrong? 

/dev/hda is the right device if you have a CDROM attached
as well. The type of ATA device does not matter, the device
name is only a name, it is the uderlying major/minor
numbers that matter.

Are you getting any interrupts from the device?
Check "cat /proc/interrupts".

Regards
Greg


------------------------------------------------------------------------
Greg Ungerer  --  Chief Software Wizard        EMAIL:  gerg at snapgear.com
SnapGear Pty Ltd                               PHONE:    +61 7 3435 2888
825 Stanley St,                                  FAX:    +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia              WEB:   www.SnapGear.com



From gerg at snapgear.com  Sun Mar 16 07:49:38 2003
From: gerg at snapgear.com (Greg Ungerer)
Date: Sun, 16 Mar 2003 22:49:38 +1000
Subject: [uClinux-dev] Re: MCF5282 Development
In-Reply-To: <1047641662.2536.2.camel@tau>
References: <1047641662.2536.2.camel@tau>
Message-ID: <3E7472E2.1070206@snapgear.com>

Hi Juanba,

juanba wrote:
> Hi, we are starting to design a project using the new
> 5282 ColdFire processor, uCLinux-2.4 version will be
> used. 
> I would like to know which tasks, drivers, kernel porting are currently
> on-going for the 5282 chipset periphericals, core and so forth, and how
> this work is/will/could be time scheduled

I am working on the 5282 port right now. I don't expect
it to take too long to get the basic uClinux system
running. I only plan on supporting the serial and
ethernet devices with drivers.

Regards
Greg



------------------------------------------------------------------------
Greg Ungerer  --  Chief Software Wizard        EMAIL:  gerg at snapgear.com
SnapGear Pty Ltd                               PHONE:    +61 7 3435 2888
825 Stanley St,                                  FAX:    +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia              WEB:   www.SnapGear.com



From David.Gelhar at Dartmouth.EDU  Sun Mar 16 09:03:25 2003
From: David.Gelhar at Dartmouth.EDU (David E. Gelhar)
Date: Sun, 16 Mar 2003 09:03:25 -0500
Subject: [uClinux-dev] Help with Motorola 68vz328ads eval board
In-Reply-To: <3E73D772.6020708@cornfed.com>
Message-ID: <0E647CB9-57B8-11D7-9E67-00039359F448@dartmouth.edu>

I've used a 68SZ328ADS board, which I suspect will be similar but with 
a different CPU version (SZ instead of VZ).

To download code over the serial port, put the CPU into bootstrap mode 
(on the SZ ADS board, switch S2-8 does this). In bootstrap mode, the 
CPU accepts "b-record" format files, which are a simple text 
address/contents format. The board probably came with an "init.b" file 
that sets up the hardware (chip selects etc.).

For downloading, instead of the DOS program, I'm using a kermit script 
"bbug" by Vladimir Gurevich (see 
http://www.uclinux.org/pub/uClinux/archive/0116.html). It's meant for 
the 68EZ328ADS board, so you may have to tweak baud rate settings for 
your board.

The kernel build process generates an "image.bin" (kernel+romfs); you 
can turn that into a b-record file to be downloaded to the board with a 
simple perl script like this: (assuming your loader map is set up to 
build a himem kernel to be loaded at romvec=0x01000000;  
flash=0x01000400)

#!/usr/bin/perl

# Convert a raw binary file into b-record format for download
# default download address is 0x10000000
#

$offset = 0x01000000;

open IN, "-";

while(1) {
         $len = read(IN, $buf, 16);      # 16-byte lines
         last if ($len <= 0);
         printf "%08X%02X", $offset, $len;
         $offset += $len;
         for ($i = 0; $i < $len; ++$i) {
             printf "%02X", ord(substr($buf, $i, 1));
         }
         printf "\n";
}


The sequence of bbug commands goes something like:

init
load init.b
load image.b
start 01000400

On Saturday, March 15, 2003, at 08:46 PM, Frank W. Miller wrote:

>
> Ok, I'm on my way.  I've got a toolchain (the latest m68k-elf) and the
> full source distribution, both of which I have installed and built 
> successfully.
> I picked the ucdimm platform to build first since I think its probably 
> the
> closest to what I've got on the 68VZ328ADS.  The problem now is,
> how do I boot the kernel on the board?  I've got a serial connection 
> but
> I need some kind of program to load it onto the target.  Does anyone
> know where something like this exists?  I've have a DOS program called
> bbugv.exe but that won't run (at least I don't know how to make it run)
> under Linux.  Can anyone help me with booting this kernel?
>
> Thanks,
> FM
>
>
> Frank W. Miller
> fwmiller at cornfed.com
>



From fwmiller at cornfed.com  Sun Mar 16 09:28:30 2003
From: fwmiller at cornfed.com (Frank W. Miller)
Date: Sun, 16 Mar 2003 09:28:30 -0500
Subject: [uClinux-dev] Help with Motorola 68vz328ads eval board
In-Reply-To: <1047811470.493.32.camel@troca>
References: <3E729126.5010303@cornfed.com> <1047721984.514.23.camel@troca> 	<3E73D772.6020708@cornfed.com> <1047811470.493.32.camel@troca>
Message-ID: <3E748A0E.4000402@cornfed.com>

>
>
>what kernel did you choose 2.0 or 2.4 ?
>
>  
>
2.4.X.  I believe thats the default for the ucdimm platform.

FM

Frank W. Miller
fwmiller at cornfed.com



From fwmiller at cornfed.com  Sun Mar 16 09:43:40 2003
From: fwmiller at cornfed.com (Frank W. Miller)
Date: Sun, 16 Mar 2003 09:43:40 -0500
Subject: [uClinux-dev] Help with Motorola 68vz328ads eval board
In-Reply-To: <0E647CB9-57B8-11D7-9E67-00039359F448@dartmouth.edu>
References: <0E647CB9-57B8-11D7-9E67-00039359F448@dartmouth.edu>
Message-ID: <3E748D9C.8020408@cornfed.com>

Fantastic information!  I'll have to take it one step at a time with you 
tho...

David E. Gelhar wrote:

> I've used a 68SZ328ADS board, which I suspect will be similar but with 
> a different CPU version (SZ instead of VZ).
>
> To download code over the serial port, put the CPU into bootstrap mod


There are a few other differences.  I have a document from Motorola that 
details all the specifics.  They made some register changes and such.  
I'll probably bang my head against these as I go.

> e (on the SZ ADS board, switch S2-8 does this). In bootstrap mode, the 
> CPU accepts "b-record" format files, which are a simple text 
> address/contents format. The board probably came with an "init.b" file 
> that sets up the hardware (chip selects etc.).


OK, my User Doc does talk about the DIP switches but it does not include 
a "bootstrap" mode (at least they're not calling it that).  There are 
four positions quoted there (which I'll try all four positions probably 
with the procedure you mention below).  The first two are for the 
Metrowerks monitor and the second two are for the SDS monitor.  I'm 
assuming both these monitors are built into the firmware on the board 
and you can select which boots up.  The two options for each monitor 
appear only to switch the UART used to communicate with the host.  Just 
for grins, here are the switch positions:

S1 10111111 S2 10111000 Metrowerks monitor on UART1
S1 11011111 S2 10111100 Metrowerks monitor on UART2
S1 10111111 S2 10111010 SDS monitor UART1
S1 11011111 S2 10111110 SDS monitor UART2

Now that I'm looking at it, S2-8 is always set to 0 in these 
configurations, let me also try setting that to one as you suggested...

FM

Frank W. Miller
fwmiller at cornfed.com




From gerg at snapgear.com  Sun Mar 16 20:41:20 2003
From: gerg at snapgear.com (Greg Ungerer)
Date: Mon, 17 Mar 2003 11:41:20 +1000
Subject: [uClinux-dev] FTP Server on the 5272 board
In-Reply-To: <200303121138.53342.rgegusch@mf.tu-berlin.de>
References: <BC03D160581F7A4E92710FC238282411167809@ici-mail.intellicom.se> <200303101443.05403.rgegusch@mf.tu-berlin.de> <3E6CA45E.5090903@snapgear.com> <200303121138.53342.rgegusch@mf.tu-berlin.de>
Message-ID: <3E7527C0.2010500@snapgear.com>

Hi Rene,

Sorry for the slow response, I have been away the last few days.

Rene Gegusch wrote:
> OK, I followed your instructions and added the uC5272 directory, furthermore I 
> added several uC5272 informations to the arch/m68knommu/config.in and
> Boards.mk files. Before I tried to replace them with the ones from the 
> Arcturus Distribution.

You didn't take the uC5272 definitions from the original Arctururs
Boards.mk into your new one.


> Finally I got the same error and this made me sad.

Fixup your Boards.mk, do another "make xconfig" and
try again. Let me know what errors you hit after this.


> Added the arch/m68knommu/config.in and Boards.mk files as an attachement. 
> Maybe I misunderstood there somehting.
> The .old files are the origin Arcturus ones.
> I also attached the uC5272 files for your CVS directory.

Thanks. I have put these in the public CVS at cvs.uclinux.org.
You can get the new Boards.mk and config.in from there if
you want.

Regards
Greg



------------------------------------------------------------------------
Greg Ungerer  --  Chief Software Wizard        EMAIL:  gerg at snapgear.com
SnapGear Pty Ltd                               PHONE:    +61 7 3435 2888
825 Stanley St,                                  FAX:    +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia              WEB:   www.SnapGear.com



From miles at lsi.nec.co.jp  Sun Mar 16 20:41:15 2003
From: miles at lsi.nec.co.jp (Miles Bader)
Date: 17 Mar 2003 10:41:15 +0900
Subject: [uClinux-dev] Re: realtime scheduling...
In-Reply-To: <003d01c2ea0d$a9c61280$0307a8c0@john.qut.edu.au>
References: <003d01c2ea0d$a9c61280$0307a8c0@john.qut.edu.au>
Message-ID: <buou1e2wz0k.fsf@mcspd15.ucom.lsi.nec.co.jp>

"John Willlams" <jwilliams at itee.uq.edu.au> writes:
> I was thinking it might be good to put a big wall between the real-time and
> non real-time aspects of a system (and application).  So, by hanging
> everything truly "real-time" off the NMI (using a 2nd interrupt controller),
> and everying related to uClinux of the maskable interrupts, the two can be
> pretty much completely ignorant of each other (except for a data tunnel from
> one side of the wall to the other).

Someone posted to the LKML about an interesting RT technique they're using
for linux, which is to basically have all interrupts go to an underlying
super-nano-pico-thing who's job is basically only to distribute interrupts,
using a priority-sorted queue of willing interrupt handlees.  The kernel's
low-level interrupt ops (sti, cli, etc) are replaced by equivalent `put the
kernel in the interrupt queue' and `remove the kernel from the interrupt
queue' calls to the super-nano-pico-thing [or perhaps they just toggle a
bit somewhere so they're fast].

Anything that has to be RT can then be stuck into the interrupt-handlee-
queue at a higher priority than the kernel, which will allow it to
completely ignore the kernel -- it will get any interrupts it wants with no
delay.

This technique seemed very cool compared to a conventional
`RT scheduler underneath linux', since:

 (1) The super-nano-pico-thing is _extremely_ simple and light, since it's
     not a scheduler at all, and has no concept of anything except
     interrupts and handlers (i.e., it doesn't have to think about
     `processes' or anything).  Thus it's likely to be very fast and robust.

 (2) The modifications to linux were very minor, since the underlying RT
     stuff looks to linux like just some sort of slightly odd interrupt
     controller.

 (3) I think it also managed to avoid some patents held by the RT-linux guys.

[Does anyone remember the name of this stuff?]

Sorry if this is all old-hat to everyone (I'm not a RT guy)!

-Miles
-- 
Suburbia: where they tear out the trees and then name streets after them.


From laili at interepoch.com.tw  Sun Mar 16 20:50:44 2003
From: laili at interepoch.com.tw (? ?)
Date: Mon, 17 Mar 2003 09:50:44 +0800
Subject: [uClinux-dev] net-snmp in embedded system
References: <02c701c2e9db$f85f4ce0$88a8a8c0@lai> <3E72B334.DD0A6200@yahoo.com>
Message-ID: <003401c2ec27$9fea7e60$88a8a8c0@lai>

the snmpd dose not work without many libs, i use ldd command to check snmpd ,it depends on many libs.

[root at MMI .libs]# ldd ./snmpd 
        libnetsnmpagent.so.5 => /usr/local/lib/libnetsnmpagent.so.5 (0x40013000)
        libnetsnmpmibs.so.5 => /usr/local/lib/libnetsnmpmibs.so.5 (0x40025000)
        libnetsnmphelpers.so.5 => /usr/local/lib/libnetsnmphelpers.so.5 (0x40041000)
        libnetsnmp.so.5 => /usr/local/lib/libnetsnmp.so.5 (0x4004c000)
        libdl.so.2 => /lib/libdl.so.2 (0x400ac000)
        libm.so.6 => /lib/i686/libm.so.6 (0x400af000)
        libc.so.6 => /lib/i686/libc.so.6 (0x42000000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)





  ----- Original Message ----- 
  From: v.nagasrinivas 
  To: laili at interepoch.com.tw ; uclinux-dev at uclinux.org 
  Sent: Saturday, March 15, 2003 12:59 PM
  Subject: Re: [uClinux-dev] net-snmp in embedded system


  HI, 
               I have downloaded the net-snmp latest and compiled and installed and check the 
  snmpd      .....................showing 101k ( everything on i686 machine...) 
  and these figures are without doing flthdr running etc.... 

  So the memories of net-snmp installed files also i put here... 

  From this when you take only     /sbin/snmpd ------------101k 
  I don't the involvement of libfiles   as /lib showing --------9.1M (i think without these also the net-snmp runs..) 
  and the mibs files total finally depends on you which one do you need to supply for the customer.. 
                                                                              ---combining the stds mibs and your private mibs total...that never follows the 
                                                                                     following figure... 
  Could you give more information for analysation.......... 

  Thanks, 
  srinivas. 
    
    

  cheluvi at srinivas:~/net-snmp/sbin$ ls -lh 
  total 272k 
  -rwxr-xr-x    1 cheluvi  cheluvi      101k Mar 15 09:59 snmpd 
  -rwxr-xr-x    1 cheluvi  cheluvi      160k Mar 15 09:59 snmptrapd 
  cheluvi at srinivas:~/net-snmp/sbin$ 

  -------------------------------------------------- 
  cheluvi at srinivas:~/net-snmp$ du -ch 
  116k ./include/net-snmp/system 
  8.0k ./include/net-snmp/machine 
  356k ./include/net-snmp/library 
  172k ./include/net-snmp/agent 
  744k ./include/net-snmp 
  748k ./include 
  1.2M ./bin 
  9.1M ./lib 
  276k ./sbin 
  24k ./share/snmp/snmpconf-data/snmp-data 
  36k ./share/snmp/snmpconf-data/snmpd-data 
  16k ./share/snmp/snmpconf-data/snmptrapd-data 
  80k ./share/snmp/snmpconf-data 
  1.2M ./share/snmp/mibs 
  1.3M ./share/snmp 
  1.3M ./share 
  108k ./man/man1 
  420k ./man/man3 
  64k ./man/man5 
  20k ./man/man8 
  616k ./man 
  13M . 
  13M total 
  cheluvi at srinivas:~/net-snmp$ 
  ---------------------------------------------------------------------- 
    

  ?? ?? wrote: 

    hi all: I am a engineer in InterEpoch in Taiwan , this is web's url of my company www.interepoch.com.tw.I want to add SNMP agent in our wireless lan AP product, so i deside to used NET-SNMP.But the snmpd file size is about 800kbyte witch is too large for our embedded platform (4MB flash memory).i try to reduse NET-SNMP code size in many ways such as removing snmpv3 ,debugging msg,app ( we dont need in agent product)..., only reduse 40kbyte. how can i reduse  NET-SNMP size ? thank you. lai li
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20030317/9b89689d/attachment.html>

From laili at interepoch.com.tw  Sun Mar 16 21:00:29 2003
From: laili at interepoch.com.tw (=?gb2312?B?wO4g8lE=?=)
Date: Mon, 17 Mar 2003 10:00:29 +0800
Subject: [uClinux-dev] net-snmp in embedded system
References: <F147k69RKLpgTFur2iz000003f4@hotmail.com>
Message-ID: <004a01c2ec28$fc5a0480$88a8a8c0@lai>

From: Chen sj 
  To: uclinux-dev at uclinux.org 
  Sent: Saturday, March 15, 2003 3:46 PM
  Subject: Re: [uClinux-dev] net-snmp in embedded system


  Hi,

  Could you give me the following info:

  1.  your  CPU type

  MIPS R4000, little endian.

  2. NET-SNMP binary files you have cut short.

  the net-snmp's snmpd is depends on many libs, witch includes agent ,mib, snmp..., the snmp lib is vary large.

  so  i want to cut short snmp lib .

  3. what do you want to have in the embeded systems

  I just want an tiny SNMP agent.

  sincerely,

  sjChen


  thank u so mouch :)

  lai li


  >From: "?? ??" 
  >Reply-To: uclinux-dev at uclinux.org 
  >To: 
  >Subject: [uClinux-dev] net-snmp in embedded system 
  >Date: Fri, 14 Mar 2003 11:44:09 +0800 
  > 
  >hi all: 
  > 
  >I am a engineer in InterEpoch in Taiwan , this is web's url of my company www.interepoch.com.tw. 
  >I want to add SNMP agent in our wireless lan AP product, so i deside to used NET-SNMP. 
  >But the snmpd file size is about 800kbyte witch is too large for our embedded platform (4MB flash memory). 
  >i try to reduse NET-SNMP code size in many ways such as removing snmpv3 ,debugging msg, 
  >app ( we dont need in agent product)..., only reduse 40kbyte. 
  > 
  >how can i reduse NET-SNMP size ? 
  > 
  >thank you. 
  > 
  >lai li 


------------------------------------------------------------------------------
  ?????????????????????????????? MSN Hotmail _______________________________________________ uClinux-dev mailing list uClinux-dev at uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev at uclinux.org 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20030317/323df1d5/attachment.html>

From stuartm at connecttech.com  Sun Mar 16 21:12:23 2003
From: stuartm at connecttech.com (Stuart MacDonald)
Date: Sun, 16 Mar 2003 21:12:23 -0500
Subject: [uClinux-dev] Daemonize a process
References: <004d01c2e97c$e3d83890$660ba8c0@robertd> <030201c2e986$b5e57b00$294b82ce@connecttech.com>
Message-ID: <087d01c2ec2a$a5b0bc80$294b82ce@connecttech.com>

From: "Stuart MacDonald" <stuartm at connecttech.com>
> From: "Robert Daniels" <robertd at vantagecontrols.com>
> > Yeah, I never submitted my "fixes" to this since what is there works.
> > I'll just attach my version of smbmount.c and you can check it out.
> > This version has my own version of daemonize which seems to work fine
> > for smbmount, and could maybe be adapted to your use.  It is dependant
> > on the /proc file system which might not be good, and it seems that it
> > could use argv[0] instead of a hardcoded "/smbmount" or "smbmount".
> > Since this is based on vfork, it's tough to just put it anywhere in your
> > code since it runs your program again starting from the beginning,
> > but... better than nothing maybe.
>
> Nifty. I'd thought of writing the daemon as a recursive app but I'd
> been thinking the stopping condition would be passed as argv[1]; the
> /proc snooping is an interesting twist.
>
> Fortunately for me the code that wants to be forked is already fairly
> separated out; it's faster and easier for me to chop up the daemon
> into a few smaller apps and use vfork(); execve(); instead.

For the archives: Robert's code from elsewhere in this thread works,
and is reasonably easy to implement. It does depend on /proc, but then
so do other things like ps.

..Stu




From stuartm at connecttech.com  Sun Mar 16 21:10:50 2003
From: stuartm at connecttech.com (Stuart MacDonald)
Date: Sun, 16 Mar 2003 21:10:50 -0500
Subject: [uClinux-dev] raw serial data...
References: <0136362BB121814AA94DF907D1638346123153@RNDSVR01.rnd-group.com>
Message-ID: <086d01c2ec2a$6edaa680$294b82ce@connecttech.com>

From: "Marshall M. Parker" <mparker at TheRNDGroup.com>
> I am sending raw data out my serial port and minicom ignores data bytes
> that are 0x00.  Is there a terminal emulator program out there that can
> capture raw data.  I need to support raw-ASCII.  All 255 bytes.  Any
> hints?

Can you write your own? Or do you need real terminal support?
Compiling an app to open a serial port, set raw mode and read from it
isn't that hard. I can send you off list my app that does it.

..Stu

--
We make multiport serial boards.
<http://www.connecttech.com>
(800) 426-8979




From fwmiller at cornfed.com  Sun Mar 16 23:16:57 2003
From: fwmiller at cornfed.com (Frank W. Miller)
Date: Sun, 16 Mar 2003 23:16:57 -0500
Subject: [uClinux-dev] Help with Motorola 68vz328ads eval board
In-Reply-To: <1047811470.493.32.camel@troca>
References: <3E729126.5010303@cornfed.com> <1047721984.514.23.camel@troca> 	<3E73D772.6020708@cornfed.com> <1047811470.493.32.camel@troca>
Message-ID: <3E754C39.6010306@cornfed.com>

Okie doke, I got kermit and the bbug script and they appear to be 
working.  I tried to download the stock ucdimm image (after converting 
with the Perl script to a b-record file) and no go.  I downloaded the 
init.b and that worked ok.  It appears to just set a bunch of value into 
registers that I'm assuming do some basic configuration of the system 
elements.

>before uploading and running image.bin, check your
>linux-x.x.x/System.map file, all the address there should be existing
>RAM address on your board, if not, then modify the linker script
>(xxx.ld) to locate everything in RAM.
>IMHO, the easiest way is to choose the option to run the kernel from ROM
>and to change the corresponding linker script (rom.ld probably) to map
>everything in RAM (reserve the upper part of RAM like if it were ROM...)
>for example, if you have 8MB SDRAM, set the 2 upper MB as 'rom' in the
>linker script and the first 6MB as 'ram'. recompile everything.
>
>the address to upload would be the beginning of the 'rom' section,
>and the address to start the image would be specified by the symbol
>_start (or _stext maybe) in the System.map file.
>
>  
>
I looked at System.map and it appears that all the text is being placed 
at 0x1000000 which is way beyond the end of physical memory (8 Mbytes).  
I noticed that the image.brec (converted image.bin) is 4066682 bytes.  
I'll need to probably used the upper 4 Mbytes for the kernel on this 
first pass.  I'll work on slimming it down later.  One question is how 
much of the b-record file actually ends up in memory, maybe I'll need 
less.  Anyway, I went to 
linux-2.4.X/arch/m68knommu/platform/68VZ328/ucdimm and found rom.ld.  I 
hope this is the file that you are referring to for my initial 
platform?  So, now to the question.  To do what you suggest, how do I 
change this file?  It looks like this:

MEMORY
    {
    romvec: ORIGIN = 0x10c10000, LENGTH = 0x00000400
    flash: ORIGIN = 0x10c10400, LENGTH = 0x001fec00
    eflash: ORIGIN = 0x10d00000, LENGTH = 0
    ramvec: ORIGIN = 0x00000000, LENGTH = 1024
    ram: ORIGIN = 0x00020000, LENGTH = 0x00800000 - 0x00020000
    eram: ORIGIN = 0x00800000, LENGTH = 0
    }

INCLUDE arch/m68knommu/platform/68VZ328/ucdimm/fixed.ld

Do I shift romvec and ram?

FM


Frank W. Miller
fwmiller at cornfed.com




From haensse at swissembedded.com  Mon Mar 17 00:33:37 2003
From: haensse at swissembedded.com (Daniel Haensse)
Date: Mon, 17 Mar 2003 06:33:37 +0100
Subject: AW: [uClinux-dev] new bootloader
In-Reply-To: <r01050400-1024-2136CA8F546211D7AEEB00039387ACB6@[10.0.1.2]>
References: <r01050400-1024-2136CA8F546211D7AEEB00039387ACB6@[10.0.1.2]>
Message-ID: <200303170633.37802.haensse@swissembedded.com>

Hi Rick,

what it the memory size of U-Boot on a coldfire? As we will need to waste 
2x64kb Blocks for the FPGA Code we might also fit a larger bootloader there.

regard

Dani

Am Mittwoch, 12. M?rz 2003 09.10 schrieb Richard Klingler:
> > Hi Richard,
> >
> > I'm using colilo on a MCF5272 system. Are there any advatages in U-Boot?
> > In that case I would be very interested in testing it on my system.
>
> Never used CoLiLo (and never will probably ;o) in...
> So I can't actually compare (o;
>
>
> Rick



From andersen at codepoet.org  Mon Mar 17 01:28:13 2003
From: andersen at codepoet.org (Erik Andersen)
Date: Sun, 16 Mar 2003 23:28:13 -0700
Subject: [uClinux-dev] Re: realtime scheduling...
In-Reply-To: <buou1e2wz0k.fsf@mcspd15.ucom.lsi.nec.co.jp>
References: <003d01c2ea0d$a9c61280$0307a8c0@john.qut.edu.au> <buou1e2wz0k.fsf@mcspd15.ucom.lsi.nec.co.jp>
Message-ID: <20030317062813.GA5642@codepoet.org>

On Mon Mar 17, 2003 at 10:41:15AM +0900, Miles Bader wrote:
> Someone posted to the LKML about an interesting RT technique they're using
> for linux, which is to basically have all interrupts go to an underlying
> super-nano-pico-thing who's job is basically only to distribute interrupts,
> using a priority-sorted queue of willing interrupt handlees.  The kernel's
> low-level interrupt ops (sti, cli, etc) are replaced by equivalent `put the
> kernel in the interrupt queue' and `remove the kernel from the interrupt
> queue' calls to the super-nano-pico-thing [or perhaps they just toggle a
> bit somewhere so they're fast].

I believe you are thinking of Adeos:
    http://www.nongnu.org/adeos/

as originally described by Karim Yaghmour here:
    http://www.opersys.com/ftp/pub/Adeos/adeos.pdf

 -Erik

--
Erik B. Andersen             http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--


From richard.klingler at violasystems.com  Mon Mar 17 02:00:57 2003
From: richard.klingler at violasystems.com (Richard Klingler)
Date: Mon, 17 Mar 2003 09:00:57 +0200
Subject: AW: [uClinux-dev] new bootloader
In-Reply-To: <200303170633.37802.haensse@swissembedded.com>
Message-ID: <r01050400-1024-342604FC584611D7B97500039387ACB6@[10.0.1.2]>

> Hi Rick,
> 
> what it the memory size of U-Boot on a coldfire? As we will need to waste 
> 2x64kb Blocks for the FPGA Code we might also fit a larger bootloader there.
> 

Gruezi Dani...

Around same size as ppcboot...depends what features you compile in...

With standard features:

-rwxr-xr-x    1 klingler users       72148 Mar 12 09:53 u-boot.bin


Rick


Richard Klingler             mail: richard.klingler at violasystems.com
Viola Systems Ltd.           http://www.violasystems.com/
Lemmink?isenkatu 32          phon: +358 (0)201 226 226
20520 Turku, Finland         mobile: +358 (0)40 748 4711


From rgegusch at mf.tu-berlin.de  Mon Mar 17 04:30:16 2003
From: rgegusch at mf.tu-berlin.de (Rene Gegusch)
Date: Mon, 17 Mar 2003 10:30:16 +0100
Subject: [uClinux-dev] FTP Server on the 5272 board
In-Reply-To: <3E7527C0.2010500@snapgear.com>
References: <BC03D160581F7A4E92710FC238282411167809@ici-mail.intellicom.se> <200303121138.53342.rgegusch@mf.tu-berlin.de> <3E7527C0.2010500@snapgear.com>
Message-ID: <200303171030.16441.rgegusch@mf.tu-berlin.de>

OK, here is my report about my latest work:

first of all I reset everything, so that I had the exact distribution 
V.No.030305
then I downloaded the linux2.4 cvs directory and replaced in my uCLinux 
directory the mk68noemmu directory with the one from cvs

started make xconfig and reset every cahnges to default, then added ftp to it.
wondering that this time there was an extra question during default settings 
(in console):
Arcturus Networks uC5272 dimm board support (CONFIG_BOARD_UC5272) [N/y/?] 
(NEW)
Answer: y
make dep went on without any errors, but make gave me this error:
m68k-elf-gcc -fno-builtin -nostdinc -D__KERNEL__ 
-I/home/rgegusch/test/coldfire/uClinux-dist-patched/linux-2.4.x/include  
-Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common 
-fomit-frame-pointer -I/usr/local/lib/gcc-lib/m68k-elf/2.95.3/./include -pipe 
-DNO_MM -DNO_FPU -m5307 -Wa,-S -Wa,-m5307 -D__ELF__ -DMAGIC_ROM_PTR 
-DUTS_SYSNAME="uClinux" -D__linux__ -O1   -nostdinc -iwithprefix include 
-DKBUILD_BASENAME=fec  -c -o fec.o fec.c
fec.c: In function `fec_enet_init':
fec.c:1676: `fec_hwaddr' undeclared (first use in this function)
fec.c:1676: (Each undeclared identifier is reported only once
fec.c:1676: for each function it appears in.)
make[4]: *** [fec.o] Fehler 1
make[4]: Verlassen des Verzeichnisses Verzeichnis 
?/home/rgegusch/test/coldfire/uClinux-dist-patched/linux-2.4.x/drivers/net?
make[3]: *** [first_rule] Fehler 2
make[3]: Verlassen des Verzeichnisses Verzeichnis 
?/home/rgegusch/test/coldfire/uClinux-dist-patched/linux-2.4.x/drivers/net?
make[2]: *** [_subdir_net] Fehler 2
make[2]: Verlassen des Verzeichnisses Verzeichnis 
?/home/rgegusch/test/coldfire/uClinux-dist-patched/linux-2.4.x/drivers?
make[1]: *** [_dir_drivers] Fehler 2
make[1]: Verlassen des Verzeichnisses Verzeichnis 
?/home/rgegusch/test/coldfire/uClinux-dist-patched/linux-2.4.x?
make: *** [linux] Fehler 1

Well, this time there is a new kind of error... great :(

I will try on to patch the latest distribution with the Arcturus distribution 
regarding boards.mk and config.in file... during waiting for answer

Regards
Rene




Am Montag, 17. M?rz 2003 02:41 schrieb Greg Ungerer:
> Hi Rene,
>
> Sorry for the slow response, I have been away the last few days.
>
> Rene Gegusch wrote:
> > OK, I followed your instructions and added the uC5272 directory,
> > furthermore I added several uC5272 informations to the
> > arch/m68knommu/config.in and Boards.mk files. Before I tried to replace
> > them with the ones from the Arcturus Distribution.
>
> You didn't take the uC5272 definitions from the original Arctururs
> Boards.mk into your new one.
>
> > Finally I got the same error and this made me sad.
>
> Fixup your Boards.mk, do another "make xconfig" and
> try again. Let me know what errors you hit after this.
>
> > Added the arch/m68knommu/config.in and Boards.mk files as an attachement.
> > Maybe I misunderstood there somehting.
> > The .old files are the origin Arcturus ones.
> > I also attached the uC5272 files for your CVS directory.
>
> Thanks. I have put these in the public CVS at cvs.uclinux.org.
> You can get the new Boards.mk and config.in from there if
> you want.
>
> Regards
> Greg
>
>
>
> ------------------------------------------------------------------------
> Greg Ungerer  --  Chief Software Wizard        EMAIL:  gerg at snapgear.com
> SnapGear Pty Ltd                               PHONE:    +61 7 3435 2888
> 825 Stanley St,                                  FAX:    +61 7 3891 3630
> Woolloongabba, QLD, 4102, Australia              WEB:   www.SnapGear.com
>
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org




From selvam at sesl.global.sharp.co.jp  Mon Mar 17 05:00:29 2003
From: selvam at sesl.global.sharp.co.jp (Selvam)
Date: Mon, 17 Mar 2003 18:00:29 +0800
Subject: [uClinux-dev] no shell prompt
In-Reply-To: <200303170633.37802.haensse@swissembedded.com>
References: <r01050400-1024-2136CA8F546211D7AEEB00039387ACB6@[10.0.1.2]>
 <200303170633.37802.haensse@swissembedded.com>
Message-ID: <03031718002901.01459@localhost>

Hi, my uclinux seems booting well, but I don't get the shell 
prompt. When I do printf() in init.c (\sbin\init)  it's not printed 
in my console anymore. What should I do to ensure my 
printf() output goes to console. 


thanks
Selvam



From giovanni.casoli at atengineering.it  Mon Mar 17 06:09:29 2003
From: giovanni.casoli at atengineering.it (Giovanni Casoli)
Date: Mon, 17 Mar 2003 12:09:29 +0100
Subject: [uClinux-dev] web browser
Message-ID: <200303171209.29919.giovanni.casoli@atengineering.it>

Hi all,
   I am trying to find a good candidate web browser to be ported to uClinux. I 
considered two alternatives of already existing projects:

1) dillo
    on the pc this browser is very quick, but has at least three
    disadvantages: 
        it is gtk+-based, and porting of gtk on uClinux seems quite difficult
        beacause of a lot lacking features of uClibc, which are required by
        glib and by all the (many) libraries which depend on it.

        the version of gtk+ it is based on is 1.2, so uClinux would 
        be supposed to run an X-server, which doesn't seem to be 
        a good idea (IMHO); nano-X api is not so compatible with 
        the xlib's one. The solution would be that of porting to gtk+ 2.0
        (which can directly write on the linux framebuffer),
        but this again seems not to be trivial, because of a lot of
        api incompatibilities between the two vesions of the library.

        is not so powerful, by now, since it does not support style sheets
        and frames.

2) viewml:
        this browser is microwindows-based and supports frames and
        javascript. However it has a couple of disadvantages:
       
           it is quite slow, even on the pc;

           the frames support seems to be broken: the program crashes
           (on the pc) while trying to open a page with frames.

           Furthermore, a considerable deal of the code is written in C++,
           and I dont't know how the cross-compiler behaves with this
           language.

The third alternative would be that of writing a new browser from scratch,
but this has obvious disadvantages :).

Did someone face the same problem before I did?

Best wishes

Giovanni Casoli



From lars.segerlund at comsys.se  Mon Mar 17 06:39:35 2003
From: lars.segerlund at comsys.se (Lars Segerlund)
Date: Mon, 17 Mar 2003 12:39:35 +0100
Subject: [uClinux-dev] web browser
In-Reply-To: <200303171209.29919.giovanni.casoli@atengineering.it>
References: <200303171209.29919.giovanni.casoli@atengineering.it>
Message-ID: <3E75B3F7.8020703@comsys.se>

  Dillo is embeddable, and gtk 2.0 support is on it's way ( alledgedly ).
  So dillo can render to any bitmap, thus it should be easy to do for 
the framebuffer.

/ regards, Lars Segerlund.


Giovanni Casoli wrote:
> Hi all,
>    I am trying to find a good candidate web browser to be ported to uClinux. I 
> considered two alternatives of already existing projects:
> 
> 1) dillo
>     on the pc this browser is very quick, but has at least three
>     disadvantages: 
>         it is gtk+-based, and porting of gtk on uClinux seems quite difficult
>         beacause of a lot lacking features of uClibc, which are required by
>         glib and by all the (many) libraries which depend on it.
> 
>         the version of gtk+ it is based on is 1.2, so uClinux would 
>         be supposed to run an X-server, which doesn't seem to be 
>         a good idea (IMHO); nano-X api is not so compatible with 
>         the xlib's one. The solution would be that of porting to gtk+ 2.0
>         (which can directly write on the linux framebuffer),
>         but this again seems not to be trivial, because of a lot of
>         api incompatibilities between the two vesions of the library.
> 
>         is not so powerful, by now, since it does not support style sheets
>         and frames.
> 
> 2) viewml:
>         this browser is microwindows-based and supports frames and
>         javascript. However it has a couple of disadvantages:
>        
>            it is quite slow, even on the pc;
> 
>            the frames support seems to be broken: the program crashes
>            (on the pc) while trying to open a page with frames.
> 
>            Furthermore, a considerable deal of the code is written in C++,
>            and I dont't know how the cross-compiler behaves with this
>            language.
> 
> The third alternative would be that of writing a new browser from scratch,
> but this has obvious disadvantages :).
> 
> Did someone face the same problem before I did?
> 
> Best wishes
> 
> Giovanni Casoli
> 
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org
> 



From bkuhn at metrowerks.com  Mon Mar 17 06:40:31 2003
From: bkuhn at metrowerks.com (Bernhard Kuhn)
Date: Mon, 17 Mar 2003 12:40:31 +0100
Subject: [uClinux-dev] Re: realtime scheduling...
References: <003d01c2ea0d$a9c61280$0307a8c0@john.qut.edu.au> <buou1e2wz0k.fsf@mcspd15.ucom.lsi.nec.co.jp>
Message-ID: <3E75B42F.20700@metrowerks.com>

Miles Bader wrote:

> [Does anyone remember the name of this stuff?]

I guess you are talking about ADEOS?

ADEOS has already been integrated into RTAI (x86 only,
afair). Besides hard real time aspects, the most funny
thing about ADEOS is that it could be used to run several
instances of the same or even different operating
systems, i.e. you could have 1x RTEMS and 2x uClinux
running on the same hardware to seperate real time and
security relevant environments.

BTW.:
A standard/uClinux Linux kernel is not that bad
concerning hard real time interrupt processing: i recently
carefully reviewed the interupt processing on a MIPS
uClinux kernel (on that level, there is no significant
difference to an MMU-full system) and if you have enough
discipline to provide a bottom-half (tasklet) for each
driver, then the worst case interrupt latency meassured is
arround 20 microseconds (2 microseconds in idle mode and 5
microseconds under ping-flood condition). On an embedded
system that has a defined driver setup, it's only a minor
engineering effort to implement tasklets for drivers in
use. The situation is certainly different for PC based
hard real time processing since the carefully achieved
low interrupt latency very likely will be lost by
just adding some network card.

For a "real" RTOS, the worst case probably is somewhere at
5 to 10 microseconds, but this is IMHO not a realy
significant improvement: usual deadlines for automatisation
applications is arround 50-100 microseconds (YMMV).
During the code review, i have recognized that the
scheduler is invoked with interrupts disabled when
coming back from interupt processing. I'm not sure why
this needs to be done since all relevant resources
in the scheduler are already spinlock protected
(maybe it's just a functional bug in the assembly code).
Anyway: on a usual uClinux system, you probably don't
have more that 20 processes running, so rescheduling
shouldn't cause too much latencies.

Comments?

Bernhard



From yangyajun at hisense.cngb.com  Mon Mar 17 06:51:09 2003
From: yangyajun at hisense.cngb.com (=?gb2312?B?0e7Rx778?=)
Date: Mon, 17 Mar 2003 19:51:09 +0800
Subject: [uClinux-dev] a busybox question
Message-ID: <002001c2ec7b$80aab980$542289c0@LocalHost>

Hi,all


      I want to modify the source code of mount.c in busybox to find out where the problem of my file system's is .But when I look up mount.c in busybox,I find that the function "mount()" declare as follows:
    extern int mount ()
So I do not know where to find the source code of the function "mount()".

Can anyone tell me where or how to find the source code of the function "mount()"? 
Thank you very much!
  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20030317/53dd67c5/attachment.html>

From davidm at snapgear.com  Mon Mar 17 07:19:01 2003
From: davidm at snapgear.com (David McCullough)
Date: Mon, 17 Mar 2003 22:19:01 +1000
Subject: [uClinux-dev] a busybox question
In-Reply-To: <002001c2ec7b$80aab980$542289c0@LocalHost>
References: <002001c2ec7b$80aab980$542289c0@LocalHost>
Message-ID: <20030317121901.GA13476@beast.internal.moreton.com.au>

Jivin ?????? lays it down ...
> Hi,all
> 
>       I want to modify the source code of mount.c in busybox to find out where the problem of my file system's is .But when I look up mount.c in busybox,I find that the function "mount()" declare as follows:
>     extern int mount ()
> So I do not know where to find the source code of the function "mount()".
> 
> Can anyone tell me where or how to find the source code of the function "mount()"? 

mount is a system call (man 2 mount),

You will find the bulk of it implementation in the kernel,  look for
sys_mount for your platform.

Cheers,
Davidm

-- 
David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
davidm at snapgear.com  Fx: +61 7 3891 3630  Custom Embedded Solutions + Security


From rgegusch at mf.tu-berlin.de  Mon Mar 17 07:34:59 2003
From: rgegusch at mf.tu-berlin.de (Rene Gegusch)
Date: Mon, 17 Mar 2003 13:34:59 +0100
Subject: [uClinux-dev] FTP Server on the 5272 board
In-Reply-To: <3E7527C0.2010500@snapgear.com>
References: <BC03D160581F7A4E92710FC238282411167809@ici-mail.intellicom.se> <200303121138.53342.rgegusch@mf.tu-berlin.de> <3E7527C0.2010500@snapgear.com>
Message-ID: <200303171334.59758.rgegusch@mf.tu-berlin.de>

I finally tried to solve the mentioned problem (see my last mail) by 
exchanging the single files with the one from the Arcturus version.
I did not see there a needing of changes in this files, but there is one.
However, this idea came very fast, when I got another error in a different 
file und drivers/net. So, I tried to exchange the /net dorectory with the one 
from the Arcturus distribution and got another linking error.
Well, I stopped for this time wih this code hacking. Unfortunally I do not 
really know much about this code there and did not wanted to hack in the 
mentioned files.
Decided to go on with waiting for help...

Am Montag, 17. M?rz 2003 02:41 schrieb Greg Ungerer:
> Hi Rene,
>
> Sorry for the slow response, I have been away the last few days.
>
> Rene Gegusch wrote:
> > OK, I followed your instructions and added the uC5272 directory,
> > furthermore I added several uC5272 informations to the
> > arch/m68knommu/config.in and Boards.mk files. Before I tried to replace
> > them with the ones from the Arcturus Distribution.
>
> You didn't take the uC5272 definitions from the original Arctururs
> Boards.mk into your new one.
>
> > Finally I got the same error and this made me sad.
>
> Fixup your Boards.mk, do another "make xconfig" and
> try again. Let me know what errors you hit after this.
>
> > Added the arch/m68knommu/config.in and Boards.mk files as an attachement.
> > Maybe I misunderstood there somehting.
> > The .old files are the origin Arcturus ones.
> > I also attached the uC5272 files for your CVS directory.
>
> Thanks. I have put these in the public CVS at cvs.uclinux.org.
> You can get the new Boards.mk and config.in from there if
> you want.
>
> Regards
> Greg
>
>
>
> ------------------------------------------------------------------------
> Greg Ungerer  --  Chief Software Wizard        EMAIL:  gerg at snapgear.com
> SnapGear Pty Ltd                               PHONE:    +61 7 3435 2888
> 825 Stanley St,                                  FAX:    +61 7 3891 3630
> Woolloongabba, QLD, 4102, Australia              WEB:   www.SnapGear.com
>
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org




From heiko.degenhardt at sentec-elektronik.de  Mon Mar 17 08:03:33 2003
From: heiko.degenhardt at sentec-elektronik.de (Heiko Degenhardt)
Date: Mon, 17 Mar 2003 14:03:33 +0100
Subject: [uClinux-dev] FTP Server on the 5272 board
In-Reply-To: <200303171030.16441.rgegusch@mf.tu-berlin.de>; from rgegusch@mf.tu-berlin.de on Mon, Mar 17, 2003 at 10:30:16AM +0100
References: <BC03D160581F7A4E92710FC238282411167809@ici-mail.intellicom.se> <200303121138.53342.rgegusch@mf.tu-berlin.de> <3E7527C0.2010500@snapgear.com> <200303171030.16441.rgegusch@mf.tu-berlin.de>
Message-ID: <20030317140333.B24710@www2.sentec-elektronik.de>

Hi Rene, 

I don't know if it is really a help for your situation, but you
could have a look at Documentation/Adding-Platforms-HOWTO in the
uClinux dist to get an understanding what has to be where in the
platform specific files.

I wouldn't replace the whole m68knommu dir with the one from cvs,
but rather check what changed in the needed files (you could use
"diff -Naur file-old file-new" to find the changes, for instance).
Then change only the needed stuff for your arch.

May be this helps.
Rgds.
Heiko.



From mrossell at ya.com  Mon Mar 17 09:44:44 2003
From: mrossell at ya.com (Marc Rossell Taberner)
Date: Mon, 17 Mar 2003 15:44:44 +0100
Subject: [uClinux-dev] Write to flash memory & Colilo configuration
Message-ID: <000801c2ec93$c03ce880$0500a8c0@optimusserie6>

Hi,
I have a M5272C3 board, which are connected to a Texas Instruments DSP in order to reproduce audio. 
I want to record some music files in flash memory with the aim of reproduce it in a determinated time.
Can anybody explain me the options for record in flash memory? There exist some comands, like netflash, flashw, flash... 
I want to change the file with remote access, comunicating with the board by telnet.
Which is the best option?
I need MTD support or blkmem?

In the other hand, which address I must used in order to put system image, if this image isn't compress, using bootloader Colilo?
Nowadays, I'm working using the following configuration:
0xffe00000 --> Bootloader Colilo
0xffe40000 --> Image.bin.gz     (uClinux compress)
But if I used uncompressed image, system doesn't boot. Any modifications are need in Colilo?

Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20030317/d0171d5a/attachment.html>

From Steven.Merrifield at ge.com  Sun Mar 16 17:05:41 2003
From: Steven.Merrifield at ge.com (Merrifield, Steven (IndSys, GE Interlogix))
Date: Mon, 17 Mar 2003 09:05:41 +1100
Subject: [uClinux-dev] BOA question
Message-ID: <2A11A7E1B8057041A41671CD1DA0AE111D60DE@MELMLVEM01.e2k.ad.ge.com>

You generally won't have users on an embedded system, so I use root:

user 0
group 0

steve


> -----Original Message-----
> From: thomas chen [mailto:tchen at on-go.com]
> Sent: Sunday, 16 March 2003 11:16
> To: uclinux-dev at uclinux.org
> Subject: [uClinux-dev] BOA question
> 
> 
> i tried to get boa running under uclinux
> 
> it is failing for "no such user nobody"
> 
> in default boa.conf
> 
> there is 
> 
> user nobody
> group nogroup
> 
> should this be changed? or should a user directory be created
> called nobody?
> 
> thanks
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org
> 


From wuwyw at 163.com  Sun Mar 16 22:30:23 2003
From: wuwyw at 163.com (wuwyw)
Date: Mon, 17 Mar 2003 11:30:23 +0800 (CST)
Subject: [uClinux-dev] (no subject)
Message-ID: <3E75414F.00003D.13792@bj221.163.com>

Hi,
I want to port uClinux 2.4.x(ROM Core) to my MC68ez328 board, which has 4M
SDRAM and 2M FLASH.
 I only modified rom.ld (to suit my memory map) and crt0_rom.S( to set some register .
My rom.ld ;MEMORY
	{
	romvec : ORIGIN = 0x01000000, LENGTH = 0x00400
	flash  : ORIGIN = 0x01000400, LENGTH = 0x011fffff - 0x00400
	eflash : ORIGIN = 0x011fffff, LENGTH = 1
	ramvec : ORIGIN = 0x00000000, LENGTH = 1024
	ram    : ORIGIN = 0x00000400, LENGTH = 0x003fffff - 0x400
	eram   : ORIGIN = 0x003fffff, LENGTH = 1
	}

SECTIONS
{
  .romvec :
	{
	_flashstart = . ;
	_romvec = . ;
	__rom_start = . ;
	} > romvec

  .text :
	{
	_stext = . ;
        	*(.text)
	. = ALIGN(0x10) ;
		*(.text.*)
	. = ALIGN(0x10) ;
		*(.exitcall.exit)
	. = ALIGN(0x10) ;
		*(.kstrtab)
	. = ALIGN(16);          /* Exception table              */
	__start___ex_table = .;
		*(__ex_table)
	__stop___ex_table = .;

        __start___ksymtab = .;  /* Kernel symbol table          */
		 *(__ksymtab)
	__stop___ksymtab = .;

	. = ALIGN(0x10) ;
	_etext = . ;
	__data_rom_start = ALIGN(4) ;
        } > flash

  .eflash :
	{
	_flashend = . ;
	} > eflash

  .ramvec :
	{
	__ram_start = . ;
	__ramvec = . ;
	} > ramvec

  .data :
	{
	. = ALIGN(0x4) ;
	_sdata = . ;
	__data_start = . ;

	. = ALIGN(0x4) ;
		*(.rodata)
	. = ALIGN(0x4) ;
		*(.data)
	. = ALIGN(0x4) ;
		*(.data.*)

	. = ALIGN(0x4) ;
	__setup_start = .;
		*(.setup.init)
	. = ALIGN(0x4) ;
	__setup_end = .;

	. = ALIGN(0x4) ;
	__initcall_start = .;
		*(.initcall.init)
	. = ALIGN(0x4) ;
	__initcall_end = .;

	/*. = ALIGN(0x2000) ;*/
		*(.data.init_task)
	. = ALIGN(0x10) ;

	_edata = . ;

        } > ram

  .bss :
        {
	. = ALIGN(0x10) ;
	_sbss = . ;
		*(.bss)
	. = ALIGN(0x10) ;
		*(COMMON)
	. = ALIGN(0x10) ;
	_ebss = . ;
	_end = . ;
	} > ram

  .eram :
	{
	__ramend = . ;
	} > eram
}
my crt0_rom.S;
#include <linux/config.h>

	.global _start
	.global _stext

	.global _rambase
	.global _ramvec
	.global _ramstart
	.global _ramend

#ifdef CONFIG_INIT_LCD
	.global splash_bits
#endif

	.data

/*
 *      Set up the usable of RAM stuff. Size of RAM is determined then
 *      an initial stack set up at the end.
 */
.align 4
_ramvec:
.long   0
_rambase:
.long   0
_ramstart:
.long   0
_ramend:
.long   0

/*ifdef CONFIG_INIT_LCD*/
splash_bits:
#include "bootlogo.rh"
/*#endif*/

	.text
_start:
_stext:	/*movew	#0x2700,%sr*/

	nop
	/* Init like the MOT ADS board.  Check this first */
	moveb	#0x00,   0xfffffb0b	/* Watchdog off */
	moveb	#0x10,   0xfffff000	/* SCR */

	movew   #0x2400, 0xfffff200	/* PLLCR */
	movew   #0x0123, 0xfffff202	/*	 PLLFSR */

	moveb	#0x00,   0xfffff40b	/* enable chip select */
	moveb	#0x00,   0xfffff423	 /*enable /DWE */
	moveb	#0x08,   0xfffffd0d	/* disable hardmap */
	moveb	#0x07,   0xfffffd0e	/* level 7 interrupt clear */

        movew   #0x0800, 0xfffff100     /* FLASH at 0x10C00000 */
        movew   #0x8000, 0xfffff102     /*  */
        movew   #0x0187, 0xfffff110     /* 4Meg, 16bit, enable, 3ws */
	movew   #0x0187, 0xfffff112     /*  */

        movew   #0x8f00, 0xfffffc00     /* DRAM configuration */
        movew   #0x9667, 0xfffffc02     /* DRAM control - *DWE Enable*/
        movew   #0x0000, 0xfffff106     /* DRAM at 0x00000000 */
        movew   #0x028D, 0xfffff116     /* 8Meg, 16bit, enable, 0ws */
        movew   #0x0000, 0xfffff104     /*  */
        movew   #0x028D, 0xfffff114     /*  */


	movew   #0x0808, 0xfffff420
	movew   #0x8007, 0xfffff422
	movew   #0x0061, 0xfffff42a
	movew   #0x619e, 0xfffff428

	moveb	#0x40,   0xfffff300	/* IVR */
	movel	#0x007FFFFF, %d0	/* IMR */
	movel	%d0,     0xfffff304

	moveb   0xfffff42b, %d0
	andb    #0xe0,   %d0
	moveb   %d0,     0xfffff42b

	moveb	#0x08,   0xfffff907	/* Ignore CTS */
	movew	#0x010b, 0xfffff902	/* BAUD to 9600 */
	movew	#0xe100, 0xfffff900	/* enable */

	moveb   #0,      0xfffffA27	/* LCKCON - LCD is off */

#ifdef CONFIG_INIT_LCD
	moveb	#0x61,0xfffff428	/*Select For OUTPUT*/
	movew 	#0x0060,0xfffff42a	/*Select For Internal Operation*/
	movew   #0x0340,0xfffffa36	/*Set The Contrast*/
	movel	#splash_bits, 0xfffffA00 /* LSSA */
	moveb	#0x0a,    0xfffffA05	/* LVPW */
	movew	#0x00a0,  0xFFFFFa08	/* LXMAX */
	movew	#0x00a0,  0xFFFFFa0a	/* LYMAX */
	moveb	#00,      0xfffffa29	/* LBAR */
	moveb	#00,      0xfffffa25	/* LPXCD */
	moveb	#0x08,   0xFFFFFa20	/* LPICF */
	moveb	#0x00,   0xFFFFFA21	/* -ve pol */
	moveb	#0x8f,   0xfffffA27	/* LCKCON */
	movew	#0xff00, 0xfffff412	/* LCD pins */
	movel   #0x023d3c0a,0xfffff430

#endif
	moveal  #_ramend-0x10 ,%sp
	/*moveal  #__ramend-CONFIG_MEMORY_RESERVE*0x100000 - 0x10, %sp*/
	movew   #0x2700 ,%sr

	moveq   #13, %d7                /* '\r' */
        jsr putc

        moveq   #10, %d7                /* '\n' */
        jsr putc

        moveq   #65, %d7                /* 'A' */
        jsr putc

	movew	#32767,%d0 /*#32767, %d0   PLL settle wait loop */
L0:	subq	#1, %d0
	bne	L0
	moveq	#66, %d7
	jsr	putc


	/* Copy data segment from ROM to RAM */
	moveal	/*#__data_rom_start*/ #0x01078800, %a0
	moveal	#_sdata, %a1
	moveal	#_edata, %a2
	moveq	#67, %d7
	jsr	putc


	/* Copy %a0 to %a1 until %a1 == %a2 */
LD1:	movel	%a0 at +, %d0   /*a1 at +*/
        movel   %d0,%a1 at +
	cmpal	%a1, %a2
	bhi	LD1
	moveq	#68, %d7
	jsr	putc

	moveal	#_sbss, %a0
	moveal	#_ebss, %a1
	/* Copy 0 to %a0 until %a0 == %a1 */

L1:
	clrl	%a0 at +
	cmpal	%a0, %a1
	bhi	L1

	moveq	#69, %d7
	jsr	putc

        movel   #_sdata, %d0
        movel   %d0,    _rambase
        movel   #_ebss,  %d0
        movel   %d0,    _ramstart

	movel	#__ramend-CONFIG_MEMORY_RESERVE*0x100000 ,%d0
	movel	%d0,	_ramend
	movel	#__ramvec,	%d0
	movel	%d0,	_ramvec

      /*  pea 0
	pea env
	pea %sp@(4)
	pea 0 
	moveq	#70, %d7
	jsr	putc*/
/*
 * load the current task pointer and stack
 */
    
        lea     init_task_union,%a0
        movel   %a0, _current_task
        lea     0x2000(%a0),%sp
	
	moveq   #13, %d7                /* '\r' */
        jsr putc

        moveq   #10, %d7                /* '\n' */
        jsr putc

/* print HHTECH: while flashing the light */
#if 1 
prn:	


	movew   #0x0061,   0xfffff42a
        movew   #0x61ff,   0xfffff428
        nop
        nop
	nop

        moveq   #72, %d7   /* HHTECH */
        jsr     putc

        movew   #0x0061,   0xfffff42a
        movew   #0x61fe,   0xfffff428
        nop
        nop
	nop  

        moveq   #72, %d7
        jsr     putc

        movew   #0x0061,   0xfffff42a
        movew   #0x61df,   0xfffff428
	nop
        nop
	nop

        moveq   #84, %d7
        jsr     putc

       /* Light act */

	movew   #0x0061,   0xfffff42a
        movew   #0x61bf,   0xfffff428
        nop
	nop

        moveq   #69, %d7
        jsr     putc

        movew   #0x0061,   0xfffff42a
        movew   #0x61be,   0xfffff428
        nop
	nop

        moveq   #67, %d7
        jsr     putc
        moveq   #72, %d7
        jsr     putc
        moveq   #58, %d7   /* ':' */
        jsr     putc
   
#endif



lp:	jsr	start_kernel
        jmp lp
 /*bra ,1b*/
_exit:

	jmp	_exit


putc:
	moveb	%d7,0xfffff907
pclp:
	movew	0xfffff906, %d7
	andw	#0x2000, %d7
	beq	pclp   /*1b*/
	rts

	.data
env:
	.long	0
	.text
but print "ABCDE" 
ABCDE :
XXXX
:(
Then stop.
Should I modify the instruction in crt0_rom.S and rom.ld anyway?



thanks,
                                         wu
                                      wuwyw at 163.net


=============================================================
????VIP???????? ????????????????????          http://vip.163.com/
??????????????????????????????                  http://vip.163.com/lover/new_love.jsp
???????????????????????? ??????????????            http://dating.163.com/



From cheluvi at yahoo.com  Sun Mar 16 23:49:24 2003
From: cheluvi at yahoo.com (v.nagasrinivas)
Date: Mon, 17 Mar 2003 10:19:24 +0530
Subject: [uClinux-dev] net-snmp in embedded system
References: <02c701c2e9db$f85f4ce0$88a8a8c0@lai> <3E72B334.DD0A6200@yahoo.com> <003401c2ec27$9fea7e60$88a8a8c0@lai>
Message-ID: <3E7553D3.812729C6@yahoo.com>

Ie.,  right, it needs the libraries......
When you sum of all the total comes around in Megs...

I have read some time back an article of floppy based router works..
http://www.linuxrouter.org/LRP-Package-HOWTO.shtml
Will give a concept any of required package to be put in .tar.gz form...

and load through a form of script or program dynamically unzip and untar

place the binaries in the respective areas of file system which already
in RAM
from your flash which definitely serves the memory space requirement ..

But here one more point also require..when ever the snmp daemon to be
started on startup  the same scipt should be run automatically .......

Could this idea work out..?????

because i have downloaded the net-snmp.lrp meant for linux router
project which is of 567 K
the untarred and the  occupying harddisk space is of 13Meg...


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

cheluvi at srinivas:~$ du -ch net-snmp
116k net-snmp/include/net-snmp/system
8.0k net-snmp/include/net-snmp/machine
356k net-snmp/include/net-snmp/library
172k net-snmp/include/net-snmp/agent
744k net-snmp/include/net-snmp
748k net-snmp/include
1.2M net-snmp/bin
9.1M net-snmp/lib
276k net-snmp/sbin
24k net-snmp/share/snmp/snmpconf-data/snmp-data
36k net-snmp/share/snmp/snmpconf-data/snmpd-data
16k net-snmp/share/snmp/snmpconf-data/snmptrapd-data
80k net-snmp/share/snmp/snmpconf-data
1.2M net-snmp/share/snmp/mibs
1.3M net-snmp/share/snmp
1.3M net-snmp/share
108k net-snmp/man/man1
420k net-snmp/man/man3
64k net-snmp/man/man5
20k net-snmp/man/man8
616k net-snmp/man
13M net-snmp
13M total ---------------------------------Occupying this much of
space......



Thanks
srinivas.











? ? wrote:

>  the snmpd dose not work without many libs, i use ldd command to check
> snmpd ,it depends on many libs. [root at MMI .libs]# ldd ./snmpd
>         libnetsnmpagent.so.5 => /usr/local/lib/libnetsnmpagent.so.5
> (0x40013000)
>         libnetsnmpmibs.so.5 => /usr/local/lib/libnetsnmpmibs.so.5
> (0x40025000)
>         libnetsnmphelpers.so.5 =>
> /usr/local/lib/libnetsnmphelpers.so.5 (0x40041000)
>         libnetsnmp.so.5 => /usr/local/lib/libnetsnmp.so.5 (0x4004c000)
>
>         libdl.so.2 => /lib/libdl.so.2 (0x400ac000)
>         libm.so.6 => /lib/i686/libm.so.6 (0x400af000)
>         libc.so.6 => /lib/i686/libc.so.6 (0x42000000)
>         /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
>
>      ----- Original Message -----
>      From: v.nagasrinivas
>      To: laili at interepoch.com.tw ; uclinux-dev at uclinux.org
>      Sent: Saturday, March 15, 2003 12:59 PM
>      Subject: Re: [uClinux-dev] net-snmp in embedded system
>       HI,
>
>                   I have downloaded the net-snmp latest and
>      compiled and installed and check the
>      snmpd      .....................showing 101k ( everything on
>      i686 machine...)
>      and these figures are without doing flthdr running etc....
>
>      So the memories of net-snmp installed files also i put
>      here...
>
>      From this when you take only     /sbin/snmpd
>      ------------101k
>      I don't the involvement of libfiles   as /lib showing
>      --------9.1M (i think without these also the net-snmp
>      runs..)
>      and the mibs files total finally depends on you which one do
>      you need to supply for the customer..
>
>                                            ---combining the stds
>      mibs and your private mibs total...that never follows the
>
>                               following figure...
>      Could you give more information for analysation..........
>
>      Thanks,
>      srinivas.
>
>
>
>      cheluvi at srinivas:~/net-snmp/sbin$ ls -lh
>      total 272k
>      -rwxr-xr-x    1 cheluvi  cheluvi      101k Mar 15 09:59
>      snmpd
>      -rwxr-xr-x    1 cheluvi  cheluvi      160k Mar 15 09:59
>      snmptrapd
>      cheluvi at srinivas:~/net-snmp/sbin$
>
>      --------------------------------------------------
>      cheluvi at srinivas:~/net-snmp$ du -ch
>      116k ./include/net-snmp/system
>      8.0k ./include/net-snmp/machine
>      356k ./include/net-snmp/library
>      172k ./include/net-snmp/agent
>      744k ./include/net-snmp
>      748k ./include
>      1.2M ./bin
>      9.1M ./lib
>      276k ./sbin
>      24k ./share/snmp/snmpconf-data/snmp-data
>      36k ./share/snmp/snmpconf-data/snmpd-data
>      16k ./share/snmp/snmpconf-data/snmptrapd-data
>      80k ./share/snmp/snmpconf-data
>      1.2M ./share/snmp/mibs
>      1.3M ./share/snmp
>      1.3M ./share
>      108k ./man/man1
>      420k ./man/man3
>      64k ./man/man5
>      20k ./man/man8
>      616k ./man
>      13M .
>      13M total
>      cheluvi at srinivas:~/net-snmp$
>      ----------------------------
>      -----------------------------------------
>
>
>      ?? ?? wrote:
>
>     > hi all: I am a engineer in InterEpoch in Taiwan , this is
>     > web's url of my company www.interepoch.com.tw.I want to
>     > add SNMP agent in our wireless lan AP product, so i deside
>     > to used NET-SNMP.But the snmpd file size is about 800kbyte
>     > witch is too large for our embedded platform (4MB flash
>     > memory).i try to reduse NET-SNMP code size in many ways
>     > such as removing snmpv3 ,debugging msg,app ( we dont need
>     > in agent product)..., only reduse 40kbyte. how can i
>     > reduse  NET-SNMP size ? thank you. lai li
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20030317/588edb57/attachment.html>

From gravert at wtal.de  Mon Mar 17 10:59:44 2003
From: gravert at wtal.de (gravert at wtal.de)
Date: Mon, 17 Mar 2003 16:59:44 +0100
Subject: [uClinux-dev] missing 51 Dhry 2.1 MIPS on M5272C3
Message-ID: <20030317165944.A7711@wtal.de>

Hi all,

i'm a newbie with unclinux and the coldfire hardware.

First time i got uclinux up and running on my M5272C3,
i included and run the dhrystone 2.1 benchmark taken from ~/user/dhrystone.

I expect about 60 MIPS but what I measured is
17507.0 dhrystones which is aquivalent to 9 Mips.

Where are these missing 51 MIPS, has anyone an idea ?
What mistake have i done, or has Motorola a different understanding
about MIPS and Dhrystones ?

best regards
bodo


From m.calo at ctsgroup.it  Mon Mar 17 11:57:16 2003
From: m.calo at ctsgroup.it (=?iso-8859-1?Q?Massimo_Cal=F2?=)
Date: Mon, 17 Mar 2003 17:57:16 +0100
Subject: [uClinux-dev] Distribution 20030305 bigger Kernel Image
Message-ID: <002201c2eca6$44961d10$e10106c0@Massimo>

Hi All,

    I have downloaded the last Distribution (20030305).

I have configured the kernel (make menuconfig) with the same options that I had configured the kernel with the previous distribution.

Last Distribution Kernel image Size          :    2072572 bytes

Previous Distribution Kernel image Size    :    1788440 bytes

The Last Distribution Kernel image is 277Kb bigger then the Previous.

Is it right?

Thanks!

Massimo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20030317/be5e2d1d/attachment.html>

From bkuhn at metrowerks.com  Mon Mar 17 06:40:31 2003
From: bkuhn at metrowerks.com (Bernhard Kuhn)
Date: Mon, 17 Mar 2003 12:40:31 +0100
Subject: [uClinux-dev] Re: realtime scheduling...
References: <003d01c2ea0d$a9c61280$0307a8c0@john.qut.edu.au> <buou1e2wz0k.fsf@mcspd15.ucom.lsi.nec.co.jp>
Message-ID: <3E75B42F.20700@metrowerks.com>

Miles Bader wrote:

> [Does anyone remember the name of this stuff?]

I guess you are talking about ADEOS?

ADEOS has already been integrated into RTAI (x86 only,
afair). Besides hard real time aspects, the most funny
thing about ADEOS is that it could be used to run several
instances of the same or even different operating
systems, i.e. you could have 1x RTEMS and 2x uClinux
running on the same hardware to seperate real time and
security relevant environments.

BTW.:
A standard/uClinux Linux kernel is not that bad
concerning hard real time interrupt processing: i recently
carefully reviewed the interupt processing on a MIPS
uClinux kernel (on that level, there is no significant
difference to an MMU-full system) and if you have enough
discipline to provide a bottom-half (tasklet) for each
driver, then the worst case interrupt latency meassured is
arround 20 microseconds (2 microseconds in idle mode and 5
microseconds under ping-flood condition). On an embedded
system that has a defined driver setup, it's only a minor
engineering effort to implement tasklets for drivers in
use. The situation is certainly different for PC based
hard real time processing since the carefully achieved
low interrupt latency very likely will be lost by
just adding some network card.

For a "real" RTOS, the worst case probably is somewhere at
5 to 10 microseconds, but this is IMHO not a realy
significant improvement: usual deadlines for automatisation
applications is arround 50-100 microseconds (YMMV).
During the code review, i have recognized that the
scheduler is invoked with interrupts disabled when
coming back from interupt processing. I'm not sure why
this needs to be done since all relevant resources
in the scheduler are already spinlock protected
(maybe it's just a functional bug in the assembly code).
Anyway: on a usual uClinux system, you probably don't
have more that 20 processes running, so rescheduling
shouldn't cause too much latencies.

Comments?

Bernhard


_______________________________________________
RTAI mailing list
RTAI at rtai.org
https://mail.rtai.org/cgi-bin/mailman/listinfo/rtai



From siddons at bnl.gov  Mon Mar 17 14:33:29 2003
From: siddons at bnl.gov (D. Peter Siddons)
Date: Mon, 17 Mar 2003 14:33:29 -0500
Subject: [uClinux-dev] uCdimm login
Message-ID: <3E762309.8060404@bnl.gov>

Hi all,
    I just downloaded the latest tools (20030314) and dist (20030305). I 
took the default configuration, except I chose the Arcturus uCdimm 
target. Everything built fine, and the system boots to a login: prompt. 
However, it rejects the standard root/uClinux login/password. The 
default setup uses uClibc. I remember that the crypt lib is different 
between uC-libc and uClibc, so I tried both of the supplied password in 
vendors/Arcturus/uCdimm. Neither responded. Any suggestions?

BTW, the screen message says:

uCdimm login: root
Password:
ERROR: failed to

and then the login: prompt again.

Pete.

-- 
-----------------
D. Peter Siddons
National Synchrotron Light Source, Bldg. 725D
Brookhaven National Laboratory
Upton
New York 11973
Email: siddons at bnl.gov



From g.menie at wanadoo.fr  Mon Mar 17 14:54:20 2003
From: g.menie at wanadoo.fr (Georges Menie)
Date: 17 Mar 2003 20:54:20 +0100
Subject: [uClinux-dev] Help with Motorola 68vz328ads eval board
In-Reply-To: <3E754C39.6010306@cornfed.com>
References: <3E729126.5010303@cornfed.com> <1047721984.514.23.camel@troca>
	<3E73D772.6020708@cornfed.com> <1047811470.493.32.camel@troca> 
	<3E754C39.6010306@cornfed.com>
Message-ID: <1047930861.1308.19.camel@troca>

On Mon, 2003-03-17 at 05:16, Frank W. Miller wrote:
> 
> Okie doke, I got kermit and the bbug script and they appear to be 
> working.  I tried to download the stock ucdimm image (after converting 
> with the Perl script to a b-record file) and no go.  I downloaded the 
> init.b and that worked ok.  It appears to just set a bunch of value into 
> registers that I'm assuming do some basic configuration of the system 
> elements.
> 
> >before uploading and running image.bin, check your
> >linux-x.x.x/System.map file, all the address there should be existing
> >RAM address on your board, if not, then modify the linker script
> >(xxx.ld) to locate everything in RAM.
> >IMHO, the easiest way is to choose the option to run the kernel from ROM
> >and to change the corresponding linker script (rom.ld probably) to map
> >everything in RAM (reserve the upper part of RAM like if it were ROM...)
> >for example, if you have 8MB SDRAM, set the 2 upper MB as 'rom' in the
> >linker script and the first 6MB as 'ram'. recompile everything.
> >
> >the address to upload would be the beginning of the 'rom' section,
> >and the address to start the image would be specified by the symbol
> >_start (or _stext maybe) in the System.map file.
> >
> >  
> >
> I looked at System.map and it appears that all the text is being placed 
> at 0x1000000 which is way beyond the end of physical memory (8 Mbytes).  
> I noticed that the image.brec (converted image.bin) is 4066682 bytes.  
> I'll need to probably used the upper 4 Mbytes for the kernel on this 
> first pass.  I'll work on slimming it down later.  One question is how 
> much of the b-record file actually ends up in memory, maybe I'll need 
> less.  Anyway, I went to 
> linux-2.4.X/arch/m68knommu/platform/68VZ328/ucdimm and found rom.ld.  I 
> hope this is the file that you are referring to for my initial 
> platform?  So, now to the question.  To do what you suggest, how do I 
> change this file?  It looks like this:
> 
> MEMORY
>     {
>     romvec: ORIGIN = 0x10c10000, LENGTH = 0x00000400
>     flash: ORIGIN = 0x10c10400, LENGTH = 0x001fec00
>     eflash: ORIGIN = 0x10d00000, LENGTH = 0
>     ramvec: ORIGIN = 0x00000000, LENGTH = 1024
>     ram: ORIGIN = 0x00020000, LENGTH = 0x00800000 - 0x00020000
>     eram: ORIGIN = 0x00800000, LENGTH = 0
>     }
> 
> INCLUDE arch/m68knommu/platform/68VZ328/ucdimm/fixed.ld
> 
> Do I shift romvec and ram?

yes, here is what i'm using for my board (you may have a look at the de2
subdir in .../platform/68VZ328, in the file himem.ld)

  romvec : ORIGIN = 0x00600000, LENGTH = 1k
  flash  : ORIGIN = 0x00600400, LENGTH = 2M - 1k
  eflash : ORIGIN = 0x00800000, LENGTH = 0
  ramvec : ORIGIN = 0x00000000, LENGTH = 1k
  ram    : ORIGIN = 0x00000400, LENGTH = 6M - 1k
  eram   : ORIGIN = 0x00600000, LENGTH = 0

ramvec, ram and eram should define the rw memory map used by uClinux,
romvec, flash and eflash define the ro part. the above example is for
8MB SDRAM mapped from 0 to 0x00800000, this setting should give you an
upload address of 0x00600000 and a run address of 0x00600400, if you
need to reserve 4Mb then adjust the adresses.

When I started to port uClinux on my board, I did not need 4Mb for the
initial image to run, 2Mb were enough, but try with 4Mb and check the
generated image.bin size, it contains the kernel + the initial root file
system which are to be loaded in the rom part.

Regards,
Georges




From g.menie at wanadoo.fr  Mon Mar 17 15:25:23 2003
From: g.menie at wanadoo.fr (Georges Menie)
Date: 17 Mar 2003 21:25:23 +0100
Subject: [uClinux-dev] (no subject)
In-Reply-To: <3E75414F.00003D.13792@bj221.163.com>
References: <3E75414F.00003D.13792@bj221.163.com>
Message-ID: <1047932724.1287.39.camel@troca>

On Mon, 2003-03-17 at 04:30, wuwyw wrote:
> Hi,
[part removed]

> but print "ABCDE" 
> ABCDE :
> XXXX
> :(
> Then stop.
> Should I modify the instruction in crt0_rom.S and rom.ld anyway?

yes, you are on the right track, ABCDE is displayed from the crt0 code,
so you can check what part of the crt0 were ok, it seems the call
jsr     start_kernel
did not go far...
the stack seems ok, check your generated System.map (in linux-2.4.x/) to
find the address of start_kernel and check the whole memory map also...

you could try to map everything in SDRAM (see other thread),
until you have something running and go back to a flash based image.

Regards,
Georges



From David.Gelhar at Dartmouth.EDU  Mon Mar 17 15:28:56 2003
From: David.Gelhar at Dartmouth.EDU (David E. Gelhar)
Date: Mon, 17 Mar 2003 15:28:56 -0500
Subject: [uClinux-dev] Help with Motorola 68vz328ads eval board
In-Reply-To: <3E754C39.6010306@cornfed.com>
Message-ID: <13F257D0-58B7-11D7-B9E6-00039359F448@dartmouth.edu>

--- You wrote:
I looked at System.map and it appears that all the text is being placed
at 0x1000000 which is way beyond the end of physical memory (8 Mbytes).
I noticed that the image.brec (converted image.bin) is 4066682 bytes.
I'll need to probably used the upper 4 Mbytes for the kernel on this
first pass.  I'll work on slimming it down later.  One question is how
much of the b-record file actually ends up in memory, maybe I'll need
less.  Anyway, I went to
linux-2.4.X/arch/m68knommu/platform/68VZ328/ucdimm and found rom.ld.  I
hope this is the file that you are referring to for my initial
platform?  So, now to the question.  To do what you suggest, how do I
change this file?  It looks like this:

MEMORY
     {
     romvec: ORIGIN = 0x10c10000, LENGTH = 0x00000400
     flash: ORIGIN = 0x10c10400, LENGTH = 0x001fec00
     eflash: ORIGIN = 0x10d00000, LENGTH = 0
     ramvec: ORIGIN = 0x00000000, LENGTH = 1024
     ram: ORIGIN = 0x00020000, LENGTH = 0x00800000 - 0x00020000
     eram: ORIGIN = 0x00800000, LENGTH = 0
     }

INCLUDE arch/m68knommu/platform/68VZ328/ucdimm/fixed.ld

Do I shift romvec and ram?

FM
--- end of quote ---

Here's the map I'm using on the 68sz328ads.

MEMORY
         {
/* configure to load into memory at 0x01000000 (sdram bank1, assuming 
default
   memory map for the ads board) "romvec" and "flash" sections are in 
this
   part of memory. First 16MB of memory are usable as OS RAM. */
         romvec : ORIGIN = 0x01000000, LENGTH = 0x00000400
         flash  : ORIGIN = 0x01000400, LENGTH = 0x01000000 - 0x00000400
         eflash : ORIGIN = 0x02000000, LENGTH = 0
         ramvec : ORIGIN = 0x00000000, LENGTH = 0x00000400
/* 0x400 - 0x20000 unused */
         ram    : ORIGIN = 0x00020000, LENGTH = 0x01000000 - 0x00020000
         eram   : ORIGIN = 0x01000000, LENGTH = 0
         }

INCLUDE arch/m68knommu/platform/68SZ328/ads/fixed.ld


This board 32MB of ram, so I'm loading the kernel into high memory at 
0x01000000 (16MB). If your board has only 8MB of ram, you'll have to 
adjust. Maybe load your kernel at 4MB (romvec=0x00400000). "romvec" is 
the download address; don't forget to fix your b-record perl script to 
use that offset -- i.e., the first byte of "image.bin" should get 
downloaded into memory at 0x00400000. "flash" is the starting address; 
jump there to boot the kernel.

"eflash" and "eram" mark the end of the "flash" and "ram" sections 
respectively; when you change the origin/length of "flash" or "ram", 
don't forget to make the corresponding change to "eflash"/"eram"

--- You wrote:
I noticed that the image.brec (converted image.bin) is 4066682 bytes.
I'll need to probably used the upper 4 Mbytes for the kernel on this
first pass.
--- end of quote ---

The b-record file is very large because everything is ASCII text for 
the download, but the amount of space it actually takes up in memory is 
much less; it's the size of image.bin that you should be looking at.



From g.menie at wanadoo.fr  Mon Mar 17 15:39:38 2003
From: g.menie at wanadoo.fr (Georges Menie)
Date: 17 Mar 2003 21:39:38 +0100
Subject: [uClinux-dev] uCdimm login
In-Reply-To: <3E762309.8060404@bnl.gov>
References: <3E762309.8060404@bnl.gov>
Message-ID: <1047933579.1287.54.camel@troca>

On Mon, 2003-03-17 at 20:33, D. Peter Siddons wrote:
> Hi all,
>     I just downloaded the latest tools (20030314) and dist (20030305). I 
> took the default configuration, except I chose the Arcturus uCdimm 
> target. Everything built fine, and the system boots to a login: prompt. 
> However, it rejects the standard root/uClinux login/password. The 
> default setup uses uClibc. I remember that the crypt lib is different 
> between uC-libc and uClibc, so I tried both of the supplied password in 
> vendors/Arcturus/uCdimm. Neither responded. Any suggestions?
> 
> BTW, the screen message says:
> 
> uCdimm login: root
> Password:
> ERROR: failed to
> 
> and then the login: prompt again.
> 

the location (and name) of the passwd file has changed,

go to the vendors/Arcturus/UCdimm subdir and edit
the Makefile, change :

        if [ -f passwd.$(LIBCDIR) ]; then \
                $(ROMFSINST) passwd.$(LIBCDIR) /etc/passwd; \
        else \
                $(ROMFSINST) /etc/passwd; \
        fi

to 

        if [ -f config.$(LIBCDIR) ]; then \
                $(ROMFSINST) config.$(LIBCDIR) /etc/config/config; \
        else \
                $(ROMFSINST) /etc/config/config; \
        fi


and add etc/config on the ROMFS_DIRS line (near the top of the file)
like this:

ROMFS_DIRS = bin dev etc home lib mnt proc usr var \
             home/httpd home/httpd/cgi-bin etc/config

then do:
make romfs
make image

you should be all set...

FYI: the new option behind this is CONFIG_USER_OLD_PASSWORDS
it is active by default but the passwd filename was changed, I assume
this is to make room for a real passwd file (and associated
functions)...

Regards,
Georges



From philwil at earthlink.net  Mon Mar 17 11:06:33 2003
From: philwil at earthlink.net (Phil Wilshire)
Date: Mon, 17 Mar 2003 11:06:33 -0500
Subject: [uClinux-dev] uCdimm login
References: <3E762309.8060404@bnl.gov>
Message-ID: <3E75F289.B06A1790@earthlink.net>

HI
The password may not be the problem here.

I modify the login.c file to print out the password.

Looking at the code extract make sure that 
you can read /etc/passwd on the target system.

Here is an untested code extract to show you what the password should be.



        gotpwd = getpass("Password: ");
        realpwd = getrealpass(PATH_PASSWD);
        if (gotpwd && realpwd) {     
            printf(" password is %s\n",crypt(gotpwd, realpwd));


Here is the error message.
I suspect that you are not able to read the passwd file.

char *getrealpass(char *pfile)
{
        static char     tmpline[128];
        FILE            *fp;
        char            *spass;
        int             len;

        if ((fp = fopen(pfile, "r")) == NULL) {
                fprintf(stderr, "ERROR: failed to open(%s), errno=%d \n",
                        pfile, errno);
                return((char *) NULL);
        }

regards
  Phil Wilshire

"D. Peter Siddons" wrote:
> 
> Hi all,
>     I just downloaded the latest tools (20030314) and dist (20030305). I
> took the default configuration, except I chose the Arcturus uCdimm
> target. Everything built fine, and the system boots to a login: prompt.
> However, it rejects the standard root/uClinux login/password. The
> default setup uses uClibc. I remember that the crypt lib is different
> between uC-libc and uClibc, so I tried both of the supplied password in
> vendors/Arcturus/uCdimm. Neither responded. Any suggestions?
> 
> BTW, the screen message says:
> 
> uCdimm login: root
> Password:
> ERROR: failed to
> 
> and then the login: prompt again.
> 
> Pete.
> 
> --
> -----------------
> D. Peter Siddons
> National Synchrotron Light Source, Bldg. 725D
> Brookhaven National Laboratory
> Upton
> New York 11973
> Email: siddons at bnl.gov
> 
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org

-- 
SDCS -- System Design & Consulting Services LLC, http://www.sysdcs.com
** Embedded Linux Training **  email me for details  
630 Springhouse Sq., Leesburg VA 20175 t: 703 669 9766 f: 703 669 9768


From gevans at vigilhealth.com  Mon Mar 17 17:57:35 2003
From: gevans at vigilhealth.com (Greg Evans)
Date: Mon, 17 Mar 2003 14:57:35 -0800
Subject: [uClinux-dev] Berkeley DB
Message-ID: <000c01c2ecd8$9a171410$0814a8c0@vigilhealth.com>

Hello,

I have been looking for a good embedded database to use with the M5272C3. Has anyone ever used Berkeley DB with uClinux?

Thanks,

Greg Evans
Computer Engineering Technologist
gevans at vigilhealth.com

Vigil Health Management
www.vigil.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20030317/7427499a/attachment.html>

From davidm at snapgear.com  Mon Mar 17 18:12:54 2003
From: davidm at snapgear.com (David McCullough)
Date: Tue, 18 Mar 2003 09:12:54 +1000
Subject: [uClinux-dev] uCdimm login
In-Reply-To: <1047933579.1287.54.camel@troca>
References: <3E762309.8060404@bnl.gov> <1047933579.1287.54.camel@troca>
Message-ID: <20030317231254.GA19066@beast.internal.moreton.com.au>


Jivin Georges Menie lays it down ...
> On Mon, 2003-03-17 at 20:33, D. Peter Siddons wrote:
> > Hi all,
> >     I just downloaded the latest tools (20030314) and dist (20030305). I 
> > took the default configuration, except I chose the Arcturus uCdimm 
> > target. Everything built fine, and the system boots to a login: prompt. 
> > However, it rejects the standard root/uClinux login/password. The 
> > default setup uses uClibc. I remember that the crypt lib is different 
> > between uC-libc and uClibc, so I tried both of the supplied password in 
> > vendors/Arcturus/uCdimm. Neither responded. Any suggestions?
> > 
> > BTW, the screen message says:
> > 
> > uCdimm login: root
> > Password:
> > ERROR: failed to
> > 
> > and then the login: prompt again.
> > 
> 
> the location (and name) of the passwd file has changed,
> 
> go to the vendors/Arcturus/UCdimm subdir and edit
> the Makefile, change :
> 
>         if [ -f passwd.$(LIBCDIR) ]; then \
>                 $(ROMFSINST) passwd.$(LIBCDIR) /etc/passwd; \
>         else \
>                 $(ROMFSINST) /etc/passwd; \
>         fi
> 
> to 
> 
>         if [ -f config.$(LIBCDIR) ]; then \
>                 $(ROMFSINST) config.$(LIBCDIR) /etc/config/config; \
>         else \
>                 $(ROMFSINST) /etc/config/config; \
>         fi
> 
> 
> and add etc/config on the ROMFS_DIRS line (near the top of the file)
> like this:
> 
> ROMFS_DIRS = bin dev etc home lib mnt proc usr var \
>              home/httpd home/httpd/cgi-bin etc/config
> 
> then do:
> make romfs
> make image
> 
> you should be all set...
> 
> FYI: the new option behind this is CONFIG_USER_OLD_PASSWORDS
> it is active by default but the passwd filename was changed, I assume
> this is to make room for a real passwd file (and associated
> functions)...

This is a bug we introduced :-(

CONFIG_USER_OLD_PASSWORDS is only supposed to mean that we use
the old broken uC-libc crypt.  It is not supposed to change the location
of the password file.  /etc/config/config is only supposed to be used when
CONFIG_USER_FLATFSD_FLATFSD is selected.

So the code in login is sort of incorrect :-)

If you look at the login code though it still checks in /etc/passwd:

	gotpwd = getpass("Password: ");
	realpwd = getrealpass(user);
	#ifdef OLD_CONFIG_PASSWORDS
	if (realpwd == NULL)
		realpwd = getoldpass(PATH_OLD_PASSWD);
	#endif

getrealXXXX uses getpwnam which should be looking in /etc/passwd,
though with uClibc this will need to be a properly formatted passwd file.

I have attached what I think is the most appropriate patch for now.  It
also fixes boa authentication if you were using it in the same way.

Cheers,
Davidm

PS.
	remember to undo your Makefile changes ;-)

-- 
David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
davidm at snapgear.com  Fx: +61 7 3891 3630  Custom Embedded Solutions + Security
-------------- next part --------------
Index: user/login/login.c
===================================================================
RCS file: /cvs/sw/new-wave/user/login/login.c,v
retrieving revision 1.20
diff -u -r1.20 login.c
--- user/login/login.c	4 Feb 2003 04:36:07 -0000	1.20
+++ user/login/login.c	17 Mar 2003 23:06:58 -0000
@@ -34,8 +34,10 @@
 
 /*****************************************************************************/
 
-#ifdef OLD_CONFIG_PASSWORDS
+#ifdef CONFIG_USER_FLATFSD_FLATFSD
 #define PATH_OLD_PASSWD	"/etc/config/config"
+#else
+#define PATH_OLD_PASSWD	"/etc/passwd"
 #endif
 
 /* Delay bad password exit.
Index: user/boa/src/config.c
===================================================================
RCS file: /cvs/sw/new-wave/user/boa/src/config.c,v
retrieving revision 1.11
diff -u -r1.11 config.c
--- user/boa/src/config.c	4 Nov 2002 05:52:14 -0000	1.11
+++ user/boa/src/config.c	17 Mar 2003 23:06:58 -0000
@@ -459,7 +459,11 @@
 		char temps[256], *p;
 		FILE *fp;
 
+#ifdef CONFIG_USER_FLATFSD_FLATFSD
 		fp = fopen("/etc/config/config", "r");
+#else
+		fp = fopen("/etc/passwd", "r");
+#endif
 		*auth_old_password = '\0';
 		if (fp != NULL) {
 			while (fgets(temps, 256, fp) != NULL) {

From davidm at snapgear.com  Mon Mar 17 18:36:24 2003
From: davidm at snapgear.com (David McCullough)
Date: Tue, 18 Mar 2003 09:36:24 +1000
Subject: [uClinux-dev] Distribution 20030305 bigger Kernel Image
In-Reply-To: <002201c2eca6$44961d10$e10106c0@Massimo>
References: <002201c2eca6$44961d10$e10106c0@Massimo>
Message-ID: <20030317233624.GA20975@beast.internal.moreton.com.au>

Jivin Massimo Cal? lays it down ...
> Hi All,
> 
>     I have downloaded the last Distribution (20030305).
> 
> I have configured the kernel (make menuconfig) with the same options that I had configured the kernel with the previous distribution.
> 
> Last Distribution Kernel image Size          :    2072572 bytes
> 
> Previous Distribution Kernel image Size    :    1788440 bytes
> 
> The Last Distribution Kernel image is 277Kb bigger then the Previous.
> 
> Is it right?

Yep,  the networking and a number of other areas in the 2.4.20 kernel
have grown in size.  If you go through the config options you may be
able trim it down.

Either way thats a big kernel,  what platform are you building for ?
What do you have configured in your kernel ?

Cheers,
Davidm

-- 
David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
davidm at snapgear.com  Fx: +61 7 3891 3630  Custom Embedded Solutions + Security


From philwil at earthlink.net  Mon Mar 17 18:26:40 2003
From: philwil at earthlink.net (Phil Wilshire)
Date: Mon, 17 Mar 2003 18:26:40 -0500
Subject: [uClinux-dev] Berkeley DB
References: <000c01c2ecd8$9a171410$0814a8c0@vigilhealth.com>
Message-ID: <3E7659B0.BF3E19D8@earthlink.net>

HI Greg,

One solution I have found is to use 
a MySql client on the Embedded System connected to a 
"proper" server on a full Linux system.

This assumes continual contact via ethernet ( or Wireless ).


regards
  Phil Wilshire




> Greg Evans wrote:
> 
> Hello,
> 
> I have been looking for a good embedded database to use with the M5272C3. Has anyone ever used Berkeley DB with uClinux?
> 
> Thanks,
> 
> Greg Evans
> Computer Engineering Technologist
> gevans at vigilhealth.com
> 
> Vigil Health Management
> www.vigil.com

-- 
SDCS -- System Design & Consulting Services LLC, http://www.sysdcs.com
** Embedded Linux Training **  email me for details  
630 Springhouse Sq., Leesburg VA 20175 t: 703 669 9766 f: 703 669 9768


From gerg at snapgear.com  Mon Mar 17 19:34:06 2003
From: gerg at snapgear.com (Greg Ungerer)
Date: Tue, 18 Mar 2003 10:34:06 +1000
Subject: [uClinux-dev] FTP Server on the 5272 board
In-Reply-To: <200303171030.16441.rgegusch@mf.tu-berlin.de>
References: <BC03D160581F7A4E92710FC238282411167809@ici-mail.intellicom.se> <200303121138.53342.rgegusch@mf.tu-berlin.de> <3E7527C0.2010500@snapgear.com> <200303171030.16441.rgegusch@mf.tu-berlin.de>
Message-ID: <3E76697E.1060507@snapgear.com>

Hi Rene,

Rene Gegusch wrote:
> make dep went on without any errors, but make gave me this error:
> m68k-elf-gcc -fno-builtin -nostdinc -D__KERNEL__ 
> -I/home/rgegusch/test/coldfire/uClinux-dist-patched/linux-2.4.x/include  
> -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common 
> -fomit-frame-pointer -I/usr/local/lib/gcc-lib/m68k-elf/2.95.3/./include -pipe 
> -DNO_MM -DNO_FPU -m5307 -Wa,-S -Wa,-m5307 -D__ELF__ -DMAGIC_ROM_PTR 
> -DUTS_SYSNAME="uClinux" -D__linux__ -O1   -nostdinc -iwithprefix include 
> -DKBUILD_BASENAME=fec  -c -o fec.o fec.c
> fec.c: In function `fec_enet_init':
> fec.c:1676: `fec_hwaddr' undeclared (first use in this function)
> fec.c:1676: (Each undeclared identifier is reported only once
> fec.c:1676: for each function it appears in.)

OK, this looks like a real bug in the current fec.c driver.

Change lines 96-104 to be:

     #if defined(CONFIG_BOARD_UC5272)
     unsigned char    fec_hwaddr[6] = { 0x00, 0xd0, 0xcf, 0x00, 0x00, 
0x72 };
     #elif defined(CONFIG_M5272)
     static volatile fec_t   *fec_hwp = (volatile fec_t *) (MCF_MBAR + 
0x840);
     static ushort           my_enet_addr[] = { 0x00d0, 0xcf00, 0x0072 };
     #else
     static volatile fec_t   *fec_hwp = &(((immap_t 
*)IMAP_ADDR)->im_cpm.cp_fec)
     static ushort           my_enet_addr[3];
     #endif /* CONFIG_M5272 */

This is probably not exactly what Arcturus intended here, since
it is hard coding the MAC address. But it should get you compiling,
and it will work on a single unit.

Regards
Greg


------------------------------------------------------------------------
Greg Ungerer  --  Chief Software Wizard        EMAIL:  gerg at snapgear.com
SnapGear Pty Ltd                               PHONE:    +61 7 3435 2888
825 Stanley St,                                  FAX:    +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia              WEB:   www.SnapGear.com



From tendim at tendim.cjb.net  Mon Mar 17 20:40:55 2003
From: tendim at tendim.cjb.net (patrick)
Date: Mon, 17 Mar 2003 20:40:55 -0500 (EST)
Subject: [uClinux-dev] A slight problem with uClinux-dist-20030305.tar.gz
Message-ID: <Pine.NEB.4.44.0303172037460.22978-100000@vex.net>

Hi.

I've found a slight problem with uClinux-dist-20030305.tar.gz that isn't
at all fatal but a bit of an inconvienience.

The file

	uClibc/extra/config/conf

is included in the archive.  When you go to begin the build process, it
finds the conf executable and does not remake it.  However, the executble
is for i386 (I believe), so for non i386 systems the build process halts
when it tries to execute it.

The problem can easily be remedied by 'rm'ing the offending file and
remaking it:

	cd uClibc/extra/config
	rm conf
	make conf

which recompiles the proper file.  :)

As I said, nothing major, but an inconvienience for those of us who start
the build process, come back an hour later and find that it halted
half-way through.  :(

-Patrick

Patrick Pritchard <patrick at tendim.cjb.net>
University of Toronto Blue Sky Solar
Telemetry Systems Project Manager



From sjchen_seu at hotmail.com  Mon Mar 17 20:43:01 2003
From: sjchen_seu at hotmail.com (Chen sj)
Date: Tue, 18 Mar 2003 09:43:01 +0800
Subject: [uClinux-dev] net-snmp in embedded system
Message-ID: <F143eVwrblZz02H67yR00000083@hotmail.com>

An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20030318/66df0bd0/attachment.html>

From selvam at sesl.global.sharp.co.jp  Mon Mar 17 21:11:03 2003
From: selvam at sesl.global.sharp.co.jp (Selvam)
Date: Tue, 18 Mar 2003 10:11:03 +0800
Subject: [uClinux-dev] console output where it goes ?
In-Reply-To: <03031718002901.01459@localhost>
References: <r01050400-1024-2136CA8F546211D7AEEB00039387ACB6@[10.0.1.2]>
 <200303170633.37802.haensse@swissembedded.com>
 <03031718002901.01459@localhost>
Message-ID: <03031810110300.01482@localhost>

Hi, my uclinux seems booting well, but I don't get the shell
prompt. When I do printf() in init.c (\sbin\init)  it's not printed
in my console. I belive that the console device are opened properly but the 
output goes somewhere else. Appreciate if you guys can explain me,
what should I do to ensure my console output goes to serial port.
Or point me to some relevant documents.
I've  enabled "console on serial port" in .config. 


thanks
Selvam



From davidm at snapgear.com  Mon Mar 17 21:19:31 2003
From: davidm at snapgear.com (David McCullough)
Date: Tue, 18 Mar 2003 12:19:31 +1000
Subject: [uClinux-dev] A slight problem with uClinux-dist-20030305.tar.gz
In-Reply-To: <Pine.NEB.4.44.0303172037460.22978-100000@vex.net>
References: <Pine.NEB.4.44.0303172037460.22978-100000@vex.net>
Message-ID: <20030318021931.GA26971@beast.internal.moreton.com.au>


Jivin patrick lays it down ...
> Hi.
> 
> I've found a slight problem with uClinux-dist-20030305.tar.gz that isn't
> at all fatal but a bit of an inconvienience.
> 
> The file
> 
> 	uClibc/extra/config/conf
> 
> is included in the archive.  When you go to begin the build process, it
> finds the conf executable and does not remake it.  However, the executble
> is for i386 (I believe), so for non i386 systems the build process halts
> when it tries to execute it.
> 
> The problem can easily be remedied by 'rm'ing the offending file and
> remaking it:
> 
> 	cd uClibc/extra/config
> 	rm conf
> 	make conf
> 
> which recompiles the proper file.  :)
> 
> As I said, nothing major, but an inconvienience for those of us who start
> the build process, come back an hour later and find that it halted
> half-way through.  :(

Thanks for the bug report, here is a patch,

Cheers,
Davidm

-- 
David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
davidm at snapgear.com  Fx: +61 7 3891 3630  Custom Embedded Solutions + Security
-------------- next part --------------
Index: uClibc/Makefile
===================================================================
RCS file: /cvs/sw/uClibc/Makefile,v
retrieving revision 1.16
diff -u -r1.16 Makefile
--- uClibc/Makefile	3 Mar 2003 02:37:04 -0000	1.16
+++ uClibc/Makefile	18 Mar 2003 02:14:50 -0000
@@ -389,6 +389,7 @@
 	$(MAKE) -C libc/sysdeps/linux/common clean
 	$(MAKE) -C extra/gcc-uClibc clean
 	$(MAKE) -C extra/locale clean
+	$(MAKE) -C extra/config clean
 	@set -e; \
 	for i in `(cd $(TOPDIR)/libc/sysdeps/linux/common/sys; ls *.h)` ; do \
 		rm -f include/sys/$$i; \

From lnys.tw at yahoo.com.tw  Mon Mar 17 22:56:25 2003
From: lnys.tw at yahoo.com.tw (=?big5?q?lnys.tw?=)
Date: Tue, 18 Mar 2003 11:56:25 +0800 (CST)
Subject: [uClinux-dev] uClinux kernel with ramdisk FS can work?
Message-ID: <20030318035625.13432.qmail@web16508.mail.tpe.yahoo.com>

Hi all,

I'm a newbie with unclinux. I can run uClinux kernel
with romfs FS on Samsung 4510 eval board well. But
now, I want to change romfs FS (root) to ramdisk FS
and I fail. (like linux booting with compressed
ramdisk on x86 platform). I check the related
discussions on this mail list before and can't find
the answer to boot uClinux kernel with ramdisk FS
correctly. So I want to ask if it is hard to boot
uClinux with ramdisk FS (I mean need modify a lot of
code or architecture)? Or I miss something (I disable
blkmem driver and enable initial RAM disk (initrd)
support and add fixup function codes to set up ramdisk
start address and size in arch.c)?

my booting output as follows :

Linux version 2.4.20-uc0 (lnys at miracle.avamax.com)
(gcc version 2.95.3 20010315
(release)(ColdFire patches - 20010318 from
http://fiddes.net/coldfire/)(-msep-da
ta patches)) #295 Mon Mar 17 17:53:31 CST 2003
Processor: Samsung S3C4510B revision 6
Architecture: SNDS100
On node 0 totalpages: 4096
zone(0): 0 pages.
zone(1): 4096 pages.
zone(2): 0 pages.
Kernel command line: root=/dev/ram0
Calibrating delay loop... 3.30 BogoMIPS
Memory: 16MB = 16MB total
Memory: 15052KB available (879K code, 197K data, 44K
init)
Dentry cache hash table entries: 2048 (order: 2, 16384
bytes)
Inode cache hash table entries: 1024 (order: 1, 8192
bytes)
Mount-cache hash table entries: 512 (order: 0, 4096
bytes)
Buffer-cache hash table entries: 1024 (order: 0, 4096
bytes)
Page-cache hash table entries: 4096 (order: 2, 16384
bytes)
POSIX conformance testing by UNIFIX
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society
NET3.039
Initializing RT netlink socket
ttyS00 at 0x3ffd000 (irq = 5) is a S3C4510B
ttyS01 at 0x3ffe000 (irq = 7) is a S3C4510B
RAMDISK driver initialized: 16 RAM disks of 2048K size
1024 blocksize
loop: loaded (max 8 devices)
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)
RAMDISK: Compressed image found at block 0
Freeing initrd memory: 3072K
VFS: Mounted root (ext2 filesystem).
Freeing init memory: 44K
Warning: unable to open an initial console.
Kernel panic: Attempted to kill init!


-----------------------------------------------------------------
??? Yahoo!??
??????? - ????????????
http://fate.yahoo.com.tw/


From justin at tmq.com.au  Tue Mar 18 01:38:57 2003
From: justin at tmq.com.au (Justin Clacherty)
Date: 18 Mar 2003 16:38:57 +1000
Subject: [uClinux-dev] uclinux-elf-tools-20030314 released
In-Reply-To: <20030315130050.GC14525@beast.internal.moreton.com.au>
References: <20030315130050.GC14525@beast.internal.moreton.com.au>
Message-ID: <1047969542.16340.5.camel@rhianna.tmq.com.au>

The binaries package doesn't seem to include libiostream.a or libio.a is
there any particular reason for that?

Justin.



From lars.segerlund at comsys.se  Tue Mar 18 02:12:49 2003
From: lars.segerlund at comsys.se (Lars Segerlund)
Date: Tue, 18 Mar 2003 08:12:49 +0100
Subject: [uClinux-dev] Berkeley DB
In-Reply-To: <000c01c2ecd8$9a171410$0814a8c0@vigilhealth.com>
References: <000c01c2ecd8$9a171410$0814a8c0@vigilhealth.com>
Message-ID: <3E76C6F1.9020109@comsys.se>

  I haven't used it on uClinux, however it should be easily embeddable, 
I think they ( www.sleepycat.org ( com ?)) have some documentation about 
it. Also good choice !

  / regards, Lars Segerlund.

Greg Evans wrote:
> Hello,
>  
> I have been looking for a good embedded database to use with the 
> M5272C3. Has anyone ever used Berkeley DB with uClinux?
>  
> Thanks,
>  
> Greg Evans
> Computer Engineering Technologist
> gevans at vigilhealth.com <mailto:gevans at vigilhealth.com>
> 
> Vigil Health Management
> www.vigil.com <http://www.vigil.com>



From m.calo at ctsgroup.it  Tue Mar 18 02:51:19 2003
From: m.calo at ctsgroup.it (=?iso-8859-1?Q?Massimo_Cal=F2?=)
Date: Tue, 18 Mar 2003 08:51:19 +0100
Subject: [uClinux-dev] Distribution 20030305 bigger Kernel Image
References: <002201c2eca6$44961d10$e10106c0@Massimo> <20030317233624.GA20975@beast.internal.moreton.com.au>
Message-ID: <002f01c2ed23$2b060bd0$e10106c0@Massimo>

Hi David,

    I'm compiling for MCF5272C3, I have added to the default options the
following :

Kernel    :
                    Loadable Module Support
                    Memory Tecnology Devices (MTD)
                    Character Devices    --->    Standard/Generic Serial
Support
                    File System    --->    JFFS2

User       :
                    Flash Tools    --->    mtd-utils    :    eraseall
                    Network Application    --->    portmap
                    Busy Box    --->    dd , insmod, lsmod, rmmod, mount,
umount

If you confirm that the new kernel is bigger then the old one, I will
eliminate some of the default options

that I don't use to reduce the kernel image.

Thanks.

Massimo


----- Original Message -----
From: "David McCullough" <davidm at snapgear.com>
To: <uclinux-dev at uclinux.org>
Sent: Tuesday, March 18, 2003 12:36 AM
Subject: Re: [uClinux-dev] Distribution 20030305 bigger Kernel Image


>
> Jivin Massimo Cal? lays it down ...
> > Hi All,
> >
> >     I have downloaded the last Distribution (20030305).
> >
> > I have configured the kernel (make menuconfig) with the same options
that I had configured the kernel with the previous distribution.
> >
> > Last Distribution Kernel image Size          :    2072572 bytes
> >
> > Previous Distribution Kernel image Size    :    1788440 bytes
> >
> > The Last Distribution Kernel image is 277Kb bigger then the Previous.
> >
> > Is it right?
>
> Yep,  the networking and a number of other areas in the 2.4.20 kernel
> have grown in size.  If you go through the config options you may be
> able trim it down.
>
> Either way thats a big kernel,  what platform are you building for ?
> What do you have configured in your kernel ?
>
> Cheers,
> Davidm
>
> --
> David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
> davidm at snapgear.com  Fx: +61 7 3891 3630  Custom Embedded Solutions +
Security
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org



From paul.mcgougan at braintree.com.au  Tue Mar 18 02:54:58 2003
From: paul.mcgougan at braintree.com.au (Paul McGougan)
Date: Tue, 18 Mar 2003 17:54:58 +1000
Subject: [uClinux-dev] Timer bug in all m68knommu architectures
Message-ID: <NEBBJMBCKDIPNFGEIHANGEPMDEAA.paul.mcgougan@braintree.com.au>

I've come across a timer bug that I believe affects at least all m68knommu
architectures, although I have only experimentally proven it on the 5272.

It is evident when using the gettimeofday system call, which on-calls the
function do_gettimeofday which is show next.

void do_gettimeofday(struct timeval *tv)
{
    extern volatile unsigned long wall_jiffies;
    unsigned long flags;
    unsigned long usec, sec, lost;

    read_lock_irqsave(&xtime_lock, flags);
    usec = mach_gettimeoffset ? mach_gettimeoffset() : 0;
    lost = jiffies - wall_jiffies;
    if (lost)
        usec += lost * (1000000/HZ);
    sec = xtime.tv_sec;
    usec += xtime.tv_usec;
    read_unlock_irqrestore(&xtime_lock, flags);

    while (usec >= 1000000) {
        usec -= 1000000;
        sec++;
    }

    tv->tv_sec = sec;
    tv->tv_usec = usec;
}

The flow of this function is designed so that:
1. do_gettimeofday is called
2. read_lock_irqsave is acquired and interrupts are locally disabled
3. The timer up-count is read from the relevant timer register
4. Our local time structure is calculated from the kernel xtime variable
plus the time differences due to any pending timer bottom halves (i.e. the
lost variable) and the upcount we previously read.

The problem is shown when the following sequence occurs:
1. do_gettimeofday is called
2. read_lock_irqsave is acquired and interrupts are locally disabled
***
2A. The relevant timer now reaches its terminal upcount and in hardware is
restarted (back at 0). Interrupts are disabled so jiffies does not get
incremented before the calculation of lost.
***
3. The timer up-count is read from the relevant timer register
4. Our local structure is calculated from the kernel xtime variable plus the
time difference due to any pending timer bottom halves (i.e. the lost
variable) and the upcount we previously read.

The problem is that the upcount register has reset to zero, but our
calculations were based on a jiffies value from before the timer is
restarted, i.e. very large.

The result is that if you issue calls to gettimeofday at a high resolution
you will sometimes get the famous "time apparently going backwards" problem
as can be shown here:

Curr: 943920148.230002  Last: 943920148.239752
Curr: 943920148.570005  Last: 943920148.579755
Curr: 943920148.900000  Last: 943920148.909751
Curr: 943920149.240003  Last: 943920149.249753
Curr: 943920149.930002  Last: 943920149.939752
Curr: 943920150.270005  Last: 943920150.279755
Curr: 943920150.600001  Last: 943920150.609751

These have happened because the Current time value is actually incorrect.
For example, the first one 943920148.230002, should really have returned
943920148.240002.

I have attached a patch that can be applied to the latest uClinux-dist (i.e.
uClinux-dist-20030305). It only patches the 2.4.x kernel tree. It applies a
platform specific time code fix for the 5272. I believe that a similar fix
should be simple enough for the other m68knommu chips, but I don't have
enough knowledge of those architectures to produce them.

Paul McGougan
Braintree Communications
-------------- next part --------------
A non-text attachment was scrubbed...
Name: uClinux-dist-20030305.timer.problem.patch
Type: application/octet-stream
Size: 1106 bytes
Desc: not available
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20030318/47355fab/attachment.obj>

From haensse at swissembedded.com  Tue Mar 18 12:19:52 2003
From: haensse at swissembedded.com (Daniel Haensse)
Date: Tue, 18 Mar 2003 17:19:52 GMT
Subject: AW: [uClinux-dev] new bootloader
Message-ID: <200303181719.JAA12589@homepageserver.com>

> Gruezi Dani...
:-)
 
> Around same size as ppcboot...depends what features you compile in...
> 
> With standard features:
> 
> -rwxr-xr-x    1 klingler users       72148 Mar 12 09:53 u-boot.bin

That is a lot, it would mean that we need a third 64kb block for the 
bootloader. I'll stay at the idea to modify georges tftpnative to the Dragonix 
and add the FPGA programming stuff to it. It is very slim.

Dani




From davidm at snapgear.com  Tue Mar 18 06:56:55 2003
From: davidm at snapgear.com (David McCullough)
Date: Tue, 18 Mar 2003 21:56:55 +1000
Subject: [uClinux-dev] uclinux-elf-tools-20030314 released
In-Reply-To: <1047969542.16340.5.camel@rhianna.tmq.com.au>
References: <20030315130050.GC14525@beast.internal.moreton.com.au> <1047969542.16340.5.camel@rhianna.tmq.com.au>
Message-ID: <20030318115655.GB8398@beast.internal.moreton.com.au>

Jivin Justin Clacherty lays it down ...
> The binaries package doesn't seem to include libiostream.a or libio.a is
> there any particular reason for that?

Is there any reason your need them ?

The libstdc++ provides iostream support and I think the headers + this
take care of most standard C++ requirements.

Part of reason for switching to STLport was the impossible header file
issues trying to build libio and friends against uClibc.

I am very interested in hearing of any reasons why this is a bad idea
because I really have no opinion on the matter :-)

Cheers,
Davidm

-- 
David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
davidm at snapgear.com  Fx: +61 7 3891 3630  Custom Embedded Solutions + Security


From davidm at snapgear.com  Tue Mar 18 07:04:10 2003
From: davidm at snapgear.com (David McCullough)
Date: Tue, 18 Mar 2003 22:04:10 +1000
Subject: [uClinux-dev] Distribution 20030305 bigger Kernel Image
In-Reply-To: <002f01c2ed23$2b060bd0$e10106c0@Massimo>
References: <002201c2eca6$44961d10$e10106c0@Massimo> <20030317233624.GA20975@beast.internal.moreton.com.au> <002f01c2ed23$2b060bd0$e10106c0@Massimo>
Message-ID: <20030318120410.GC8398@beast.internal.moreton.com.au>

Jivin Massimo Cal? lays it down ...
> Hi David,
> 
>     I'm compiling for MCF5272C3, I have added to the default options the
> following :
> 
> Kernel    :
>                     Loadable Module Support
>                     Memory Tecnology Devices (MTD)
>                     Character Devices    --->    Standard/Generic Serial
> Support
>                     File System    --->    JFFS2
> 
> User       :
>                     Flash Tools    --->    mtd-utils    :    eraseall
>                     Network Application    --->    portmap
>                     Busy Box    --->    dd , insmod, lsmod, rmmod, mount,
> umount
> 
> If you confirm that the new kernel is bigger then the old one, I will
> eliminate some of the default options

It is definately bigger.  We have a 5272 based product that we are
keeping at 2.4.17 because it doesn't have enough RAM/ROM to take on
the later kernels.

If you have the two kernels handy you could check out their sizes using
m68k-elf-size and possible even 'm68k-elf-nm -v' and try and see where
the extra resources have gone.  You never know,  you might find
something bogus that can be cleaned up :-)

Cheers,
Davidm


-- 
David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
davidm at snapgear.com  Fx: +61 7 3891 3630  Custom Embedded Solutions + Security


From maillist at fsforth.de  Tue Mar 18 08:44:31 2003
From: maillist at fsforth.de (Markus Pietrek)
Date: Tue, 18 Mar 2003 14:44:31 +0100
Subject: [uClinux-dev] Bug in drivers/mtd/chips/cfi_cmdset_0002.c for AMD flash chips writing
Message-ID: <200303181444.31386.maillist@fsforth.de>

Hi folks,

I have located a timing issue on the cfi_cmdset_0002.c (uClinux-2.4.20). On 
the UNC20 (NetSilicon NS7520 based ARM with AM29LV641 CFI flash chips) 
writing data to an erased the flash ("cp xxx /dev/mtd/4) seemed to caused 
data corruption

---
# cp /nfs/linux2.bin /dev/mtd/4
Last is a0e7, datum is 5f4c
---

Actually the data was written well but the function 
cfi_cmdset_0002.c:do_write_oneword() is using an incorrect data polling 
algorithm and not the one suggested by AMD (according to the 
Am29LV640D/Am29LV641D manual, Publication#22366), producing timeouts (Instead 
of testing only bit#7 for busy/ready it compared the whole datum. But that is 
available only much later or after an unlock).

Perhaps someone can check the attached patch for cfi_cmdset_0002.c, fixing 
write and erase to use the recommended algorithm, and check it in into the 
uClinux CVS repository as I don't have any write accesses.

Best regards,


-- 
Markus Pietrek
FS Forth-Systeme GmbH
Phone: +49 (7667) 908 145,  FAX +49 (7667) 908 221

-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch_mtd
Type: text/x-diff
Size: 3785 bytes
Desc: not available
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20030318/74795638/attachment.bin>

From bkuhn at metrowerks.com  Mon Mar 17 21:53:21 2003
From: bkuhn at metrowerks.com (Bernhard Kuhn)
Date: Tue, 18 Mar 2003 03:53:21 +0100
Subject: [uClinux-dev] "Improoved" config.in for user space applications
Message-ID: <3E768A21.2000400@metrowerks.com>


Hi everybody.

I tried the latest uClinux-distro (20030305) and it works
great so far! The only thing i'm partly not feeling
comfortable with is the "flat" user space application
selection. I have attached a modified config/config.in
that groups commands that belong to a single sub-directory.
I tested this file with as many built options that compiled
on my current platform.

Just in case it may be usefull to somebody ...

best regards

Bernhard


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: config.in
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20030318/44e5c433/attachment.ksh>

From StephanChiu at itri.org.tw  Tue Mar 18 03:40:52 2003
From: StephanChiu at itri.org.tw (StephanChiu)
Date: Tue, 18 Mar 2003 16:40:52 +0800
Subject: [uClinux-dev] Big endian uClinux 2.4 for ARM7TDMI?
Message-ID: <007001c2ed2a$15f48170$6367608c@ccl.itri.org.tw>

Did anyone try the uClinux-Samsung-dist-20020927eb.tar.gz package from Mac?
I think the package is patched by David M's patch.
Dutring the kernel config, I check the "Generating Big Endian Code" option that enables the CONFIG_CPU_BIG_ENDIAN.
But, I failed in final step, make.
Did someone meet the problem or just work it out?
Here is my error message, Hope this helps...
-------------------------------------------------------
/opt/uClinux/arm-elf/bin/gld: _divsi3.o: compiled for a little endian system and target is big endian
File in wrong format: failed to merge target specific data of file /opt/uClinux/
lib/gcc-lib/arm-elf/2.95.3/libgcc.a(_divsi3.o)
/opt/uClinux/arm-elf/bin/gld: _modsi3.o: compiled for a little endian system and target is big endian
File in wrong format: failed to merge target specific data of file /opt/uClinux/
lib/gcc-lib/arm-elf/2.95.3/libgcc.a(_modsi3.o)
/opt/uClinux/arm-elf/bin/gld: _udivsi3.o: compiled for a little endian system and target is big endian
File in wrong format: failed to merge target specific data of file /opt/uClinux/
lib/gcc-lib/arm-elf/2.95.3/libgcc.a(_udivsi3.o)
/opt/uClinux/arm-elf/bin/gld: _umodsi3.o: compiled for a little endian system and target is big endian
File in wrong format: failed to merge target specific data of file /opt/uClinux/
lib/gcc-lib/arm-elf/2.95.3/libgcc.a(_umodsi3.o)
make[1]: *** [linux] Error 1
make[1]: Leaving directory `/root/20020927_eb/uClinux-dist/linux-2.4.x'
make: *** [linux] Error 1

Cheers,
Stephan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20030318/0afad905/attachment.html>

From F.Ferlemann at identecsolutions.de  Tue Mar 18 04:11:04 2003
From: F.Ferlemann at identecsolutions.de (Frieder Ferlemann)
Date: Tue, 18 Mar 2003 10:11:04 +0100
Subject: [uClinux-dev] Distribution 20030305 bigger Kernel Image
References: <002201c2eca6$44961d10$e10106c0@Massimo>
Message-ID: <3E76E2A8.559BE31C@identecsolutions.de>

Hi,

> I have configured the kernel (make menuconfig) with the same options that I had configured the kernel with the previous distribution.
> 
> Last Distribution Kernel image Size          :    2072572 bytes
> 
> Previous Distribution Kernel image Size    :    1788440 bytes
> 
> The Last Distribution Kernel image is 277Kb bigger then the Previous.

It probably is not the size of the kernel itself.

Save a copy of ls -l romfs/bin and then switch 
back to uC-Libc in the Target Platform Selection 
(your config will be defaulted when switching).


Frieder



btw: "kernel image" != "image downloaded to the target"


From tchen at on-go.com  Tue Mar 18 10:13:15 2003
From: tchen at on-go.com (thomas chen)
Date: Tue, 18 Mar 2003 10:13:15 -0500
Subject: [uClinux-dev] irattach.... is this utility available in uclinux? (for irda)
Message-ID: <3E77378B.5778A3F5@on-go.com>

thanks
tom


From jv at access-music.de  Tue Mar 18 11:03:43 2003
From: jv at access-music.de (Jay Vaughan)
Date: Tue, 18 Mar 2003 17:03:43 +0100
Subject: [uClinux-dev] Problem with uclinux-dist-20030305
Message-ID: <a05111b00ba9cf22d31ca@[10.0.1.240]>

Out of the box, the uclinux-dist-20030305, configured plain vanilla 
for MCF5272 (Motorola Eval board), produces this error when compiling 
the threaddemos:

---------------------------------------------
dev_j:/opt/uClinux-dist # make user/threaddemos_only
[ ! -d "user/threaddemos" ] || make ARCH=m68knommu 
CROSS_COMPILE=m68k-elf- -C user/threaddemos
make[1]: Entering directory `/opt/uClinux-dist/user/threaddemos'
m68k-elf-gcc -m5307 -DCONFIG_COLDFIRE  -o thdm thdm.o
/usr/local/m68k-elf/lib/m5307/crt0.o: In function `_start':
/usr/local/m68k-elf/lib/m5307/crt0.o(.text+0x8): undefined reference 
to `__uClibc_main'
thdm.o: In function `thread_code':
/opt/uClinux-dist/user/threaddemos/thdm.c:12: undefined reference to 
`_current_shared_library_a5_offset_'
/opt/uClinux-dist/user/threaddemos/thdm.c:16: undefined reference to 
`sched_yield'
/opt/uClinux-dist/user/threaddemos/thdm.c:18: undefined reference to 
`pthread_exit'
thdm.o: In function `main':
/opt/uClinux-dist/user/threaddemos/thdm.c:22: undefined reference to 
`_current_shared_library_a5_offset_'
/opt/uClinux-dist/user/threaddemos/thdm.c:31: undefined reference to 
`pthread_create'
/opt/uClinux-dist/user/threaddemos/thdm.c:33: undefined reference to `sleep'
/opt/uClinux-dist/user/threaddemos/thdm.c:36: undefined reference to 
`pthread_join'
/opt/uClinux-dist/user/threaddemos/thdm.c:38: undefined reference to `printf'
/usr/local/lib/gcc-lib/m68k-elf/2.95.3/m5307/libgcc.a(__main.o): In 
function `__do_global_ctors':
/home/davidm/work/uclinux-elf-tools/m68k-elf-gcc/gcc/../../gcc-2.95.3/gcc/libgcc2.c(.text+0x36): 
undefined reference to `__CTOR_LIST__'
/home/davidm/work/uclinux-elf-tools/m68k-elf-gcc/gcc/../../gcc-2.95.3/gcc/libgcc2.c(.text+0x4c): 
undefined reference to `__CTOR_LIST__'
/home/davidm/work/uclinux-elf-tools/m68k-elf-gcc/gcc/../../gcc-2.95.3/gcc/libgcc2.c(.text+0x54): 
undefined reference to `__CTOR_LIST__'
/usr/local/lib/gcc-lib/m68k-elf/2.95.3/m5307/libgcc.a(__main.o): In 
function `__do_global_dtors':
/home/davidm/work/uclinux-elf-tools/m68k-elf-gcc/gcc/../../gcc-2.95.3/gcc/libgcc2.c(.data+0x0): 
undefined reference to `__DTOR_LIST__'
collect2: ld returned 1 exit status
make[1]: *** [thdm] Error 1
make[1]: Leaving directory `/opt/uClinux-dist/user/threaddemos'
make: *** [user/threaddemos_only] Error 2
dev_j:/opt/uClinux-dist #
--------------------------------------------------------------

Working POSIX threads on 5272 has *always* been a pain in the ass for 
me, as far as uClinux is concerned.  One of these days, the -dist 
releases will *just work* for libpthreads/m5272, but until then I'm 
compelled to be stupid about it and just ask you guys, since there 
always seem to be hidden gotchas.

Maybe I've just not configured something properly with this release, 
but what I did was a) download the tarball, b) make menuconfig to set 
things up exactly as I had them in my older (-20030226) uClinux 
system, c) 'make dep ; make' ...

Seems to me one of the big reasons for this release was to make 
libpthread available for 5272 users wanting to take advantage of the 
XIP fixes also done as part of the m68k-elf-tools-20030314.sh 
release, but alas ... threads are *still* broken, config-wise, with 
this -dist.

It would appear, anyway.  Please correct me if I'm completely missing 
something ...


-- 

;

Jay Vaughan
r&d>>music:technology:synthesizers - www.access-music.de/


From mleslie at arcturusnetworks.com  Tue Mar 18 11:24:17 2003
From: mleslie at arcturusnetworks.com (Michael Leslie)
Date: Tue, 18 Mar 2003 11:24:17 -0500 (EST)
Subject: [uClinux-dev] Timer bug in all m68knommu architectures
In-Reply-To: <NEBBJMBCKDIPNFGEIHANGEPMDEAA.paul.mcgougan@braintree.com.au>
Message-ID: <Pine.LNX.4.21.0303181109110.17007-100000@trinity.arcturusnetworks.com>


On Tue, 18 Mar 2003, Paul McGougan wrote:
> 
> I've come across a timer bug that I believe affects at least all m68knommu
> architectures, although I have only experimentally proven it on the 5272.
> 


Mr. McGougan,

Neat fix. I've come across the same problem but I assume much worse.
I assume that I can miss jiffy interrupts for more reasons than just the
gettime; interrupt disables are all over the kernel. I also assume I can
miss more than one at a time (I've seen three to five in
quick experiments, under heavy interrupt load). The technique I'm
currently working on is roughly this: I run a second timer at a lower
resolution (10x) in free-run mode, which is restarted by the jiffy
ISR. When I run coldfire_tick(), I simply check my low-res counter to see
how many jiffy interrupts I have missed, and set missed_jiffies for
correction upstream.

I could post bits and pieces if you think they would be helpful. I'll
hold off submitting a complete patch for now because I've applied the
nanotime patch against an older kernel, which reaches far and wide all
over the kernel.

But the missed_jiffies correction code could be used separately, I
believe.


Regards,
Michael Leslie
<mleslie at arcturusnetworks.com>




From stefano.costa at bluewind.it  Tue Mar 18 11:21:05 2003
From: stefano.costa at bluewind.it (Stefano Costa)
Date: Tue, 18 Mar 2003 17:21:05 +0100
Subject: [uClinux-dev] Mounting root fs as NFS
Message-ID: <3E775581.867.1ECA4E4@localhost>

Hello,

we're successfully using the latest uClinux distribution on a 
Coldafire-based board. To speed up development, I was trying to 
enable NFS-mounted root fs, and it seems to work. Now I need to 
understand if creating a real rootfs directories tree can be 
performed by the same Makefile that builds the Kernel+Apps system. As 
far as I understand, the "romfs" directory contains the root fs tree 
ready to be "packed" up in the image later transferred to FLASH. Does 
anything similar already exist for directly building a ready-to-be-
mounted root fs (with /dev properly built etc.) or should I do this 
manually?
bye-

--
:: Bluewind :: Stefano Costa
:: Embedded Systems Design
www.bluewind.it
Mobile +39 335 6565749




From m.calo at ctsgroup.it  Tue Mar 18 11:48:59 2003
From: m.calo at ctsgroup.it (=?iso-8859-1?Q?Massimo_Cal=F2?=)
Date: Tue, 18 Mar 2003 17:48:59 +0100
Subject: [uClinux-dev] Distribution 20030305 bigger Kernel Image
References: <002201c2eca6$44961d10$e10106c0@Massimo> <3E76E2A8.559BE31C@identecsolutions.de>
Message-ID: <001701c2ed6e$46430ce0$e10106c0@Massimo>

Hi Frieder,

    I have compiled the kernel with uC-Libc and it is OK : the size is like
the old distribution.

I have compiled the new Distribution 20030305 with the new
m68k-elf-tool-20030314 but

I have the following message error :


NEW/uClinux-dist/lib/libdes -L/home/motorola/uClinux-dist-NEW/uClinux-dist/l
ib/libaes -L/home/motorola/uClinux-dist-NEW/uClinux-dist/lib/libpcap -L/home
/motorola/uClinux-dist-NEW/uClinux-dist/lib/libssl -L/home/motorola/uClinux-
dist-NEW/uClinux-dist/lib/libcrypt_old -L/home/motorola/uClinux-dist-NEW/uCl
inux-dist/lib/libsnapgear++ -L/home/motorola/uClinux-dist-NEW/uClinux-dist/l
ib/libsnapgear -L/home/motorola/uClinux-dist-NEW/uClinux-dist/lib/zlib -lz -
lc
mkfs.jffs2.elf2flt: In function `create_target_filesystem':
/home/motorola/uClinux-dist-NEW/uClinux-dist/user/mtd-utils/mkfs.jffs2.c:999
: undefined reference to `__xpg_basename'
/home/motorola/uClinux-dist-NEW/uClinux-dist/user/mtd-utils/mkfs.jffs2.c:101
0: undefined reference to `__xpg_basename'
collect2: ld returned 1 exit status
make[2]: *** [mkfs.jffs2] Error 1
make[2]: Leaving directory
`/home/motorola/uClinux-dist-NEW/uClinux-dist/user/mtd-utils'
make[1]: *** [all] Error 2
make[1]: Leaving directory
`/home/motorola/uClinux-dist-NEW/uClinux-dist/user'
make: *** [subdirs] Error 1
[root at uclinux uClinux-dist]#



Can you help me ?

Massimo


----- Original Message -----
From: "Frieder Ferlemann" <F.Ferlemann at identecsolutions.de>
To: <uclinux-dev at uclinux.org>
Sent: Tuesday, March 18, 2003 10:11 AM
Subject: Re: [uClinux-dev] Distribution 20030305 bigger Kernel Image


> Hi,
>
> > I have configured the kernel (make menuconfig) with the same options
that I had configured the kernel with the previous distribution.
> >
> > Last Distribution Kernel image Size          :    2072572 bytes
> >
> > Previous Distribution Kernel image Size    :    1788440 bytes
> >
> > The Last Distribution Kernel image is 277Kb bigger then the Previous.
>
> It probably is not the size of the kernel itself.
>
> Save a copy of ls -l romfs/bin and then switch
> back to uC-Libc in the Target Platform Selection
> (your config will be defaulted when switching).
>
>
> Frieder
>
>
>
> btw: "kernel image" != "image downloaded to the target"
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org



From AnChizhik at ekmail.com  Tue Mar 18 11:44:27 2003
From: AnChizhik at ekmail.com (Chizhik, Andrew)
Date: Tue, 18 Mar 2003 11:44:27 -0500
Subject: [uClinux-dev] Problem "make"ing uClinux
Message-ID: <b395e8de3ad7a94b2a51e5eb2dbcb9323e774f24@mail.ekmail.com>

Hi everybody.

I'm using Cygwin and uClinux-20020927. When I do a make for, say, the
default configuration for the M5407C3, everything works wonderfuly. However,
if I change the CPU type to MC68360 (which is what I need), make fails with
the following errors:

m68k-elf-ld -T arch/m68knommu/platform/68360/uCquicc/ram.ld
arch/m68knommu/platform/68360/uCquicc/crt0_ram.o init/main.o init/version.o
\
	--start-group \
	arch/m68knommu/kernel/kernel.o arch/m68knommu/mm/mm.o
arch/m68knommu/platform/68360/platform.o kernel/kernel.o mmnommu/mmnommu.o
fs/fs.o ipc/ipc.o \
	 drivers/char/char.o drivers/block/block.o drivers/misc/misc.o
drivers/net/net.o drivers/media/media.o drivers/video/video.o \
	net/network.o \
	/home/Administrator/uClinux-dist/linux-2.4.x/lib/lib.a
arch/m68knommu/lib/lib.a
/usr/local/lib/gcc-lib/m68k-elf/2.95.3/./m68000/libgcc.a \
	--end-group \
	-o linux
arch/m68knommu/kernel/kernel.o: In function `show_regs':
/home/Administrator/uClinux-dist/linux-2.4.x/arch/m68knommu/kernel/process.c
:125: undefined reference to `sw_usp'
arch/m68knommu/kernel/kernel.o: In function `m68k_vfork':
/home/Administrator/uClinux-dist/linux-2.4.x/arch/m68knommu/kernel/process.c
:198: undefined reference to `sw_usp'
arch/m68knommu/kernel/kernel.o: In function `m68k_clone':
/home/Administrator/uClinux-dist/linux-2.4.x/include/asm/processor.h:25:
undefined reference to `sw_usp'
arch/m68knommu/kernel/kernel.o: In function `dump_thread':
/home/Administrator/uClinux-dist/linux-2.4.x/arch/m68knommu/kernel/process.c
:307: undefined reference to `sw_usp'
fs/fs.o: In function `proc_pid_stat':
/home/Administrator/uClinux-dist/linux-2.4.x/include/asm/processor.h:25:
undefined reference to `sw_usp'
make[1]: *** [linux] Error 1
make[1]: Leaving directory `/home/Administrator/uClinux-dist/linux-2.4.x'
make: *** [linux] Error 1

Looking at the lines mentioned here, there is no "sw_usp" there. For
example, line 125 in process.c reads:
printk("USP: %081x\n", rdusp());

I assume the problem lies in the call to rdusp(). What does that function
do? What do these errors mean?

Andrew Chizhik 


From himba at siol.net  Tue Mar 18 12:09:22 2003
From: himba at siol.net (himba)
Date: Tue, 18 Mar 2003 18:09:22 +0100
Subject: [uClinux-dev] usb on h8/300h
Message-ID: <3E7752C2.5040903@siol.net>

hello


i haven't really started using anything yet (mcu or OS), but would like 
to use  h8/300h (h8-3062) mcu and usb host from cypress sl811hs. it can 
do host as well as slave function of usb device!
neat. i will be using it for reading usb flash disks...

how is it with ucLinux and usb?
is usb stack implemented already?
device support?

i can get usb host drivers for sl811sh for linux from cypress...

regards, himba



From g.menie at wanadoo.fr  Tue Mar 18 13:36:20 2003
From: g.menie at wanadoo.fr (Georges Menie)
Date: 18 Mar 2003 19:36:20 +0100
Subject: [uClinux-dev] uCdimm login
In-Reply-To: <20030317231254.GA19066@beast.internal.moreton.com.au>
References: <3E762309.8060404@bnl.gov> <1047933579.1287.54.camel@troca> 
	<20030317231254.GA19066@beast.internal.moreton.com.au>
Message-ID: <1048012581.1703.4.camel@troca>

On Tue, 2003-03-18 at 00:12, David McCullough wrote:
> 
> Jivin Georges Menie lays it down ...
> > FYI: the new option behind this is CONFIG_USER_OLD_PASSWORDS
> > it is active by default but the passwd filename was changed, I assume
> > this is to make room for a real passwd file (and associated
> > functions)...
> 
> This is a bug we introduced :-(

ok, next time you need someone to find nice explanation for a newly
discovered bug, you know who to ask...
:-)

Georges



From himba at siol.net  Tue Mar 18 15:00:21 2003
From: himba at siol.net (himba)
Date: Tue, 18 Mar 2003 21:00:21 +0100
Subject: [uClinux-dev] h8 board
Message-ID: <3E777AD5.40403@siol.net>

hello,
what do you think about this devel borad? is it possible to run ucLinux 
on it?

http://www.nuhorizons.com/services/development/Hitachi/Boardinabag.html

maybe there would be a need for some additional ramflash upgrade.

regards, himba



From richard.klingler at violasystems.com  Tue Mar 18 15:16:55 2003
From: richard.klingler at violasystems.com (Richard Klingler)
Date: Tue, 18 Mar 2003 22:16:55 +0200
Subject: [uClinux-dev] h8 board
In-Reply-To: <3E777AD5.40403@siol.net>
Message-ID: <r01050400-1024-906A1324597E11D7A42C00039387ACB6@[10.0.1.2]>

> hello,
> what do you think about this devel borad? is it possible to run ucLinux 
> on it?
> 
> http://www.nuhorizons.com/services/development/Hitachi/Boardinabag.html
> 
> maybe there would be a need for some additional ramflash upgrade.
> 

Nope...as I see it is a 16-bit CPU...


Rick


Richard Klingler             mail: richard.klingler at violasystems.com
Viola Systems Ltd.           http://www.violasystems.com/
Lemmink?isenkatu 32          phon: +358 (0)201 226 226
20520 Turku, Finland         mobile: +358 (0)40 748 4711


From himba at siol.net  Tue Mar 18 15:56:47 2003
From: himba at siol.net (himba)
Date: Tue, 18 Mar 2003 21:56:47 +0100
Subject: [uClinux-dev] h8 board
References: <r01050400-1024-906A1324597E11D7A42C00039387ACB6@[10.0.1.2]>
Message-ID: <3E77880F.7040402@siol.net>

i'm sorry for not specifing about using ucLinux for h8/300H hitachi family.
i've seen some web pages about the project.

h8s and h8/300h share the same core, right? 16-bit. it is possible to 
run uclinux on those. further, h8/tiny is somekind of "enhanced" - as 
stated in their docs - h8/300h. thus running uclinux on it shouldn't be 
a problem...

or am i wrong?

Richard Klingler wrote:

>>hello,
>>what do you think about this devel borad? is it possible to run ucLinux 
>>on it?
>>
>>http://www.nuhorizons.com/services/development/Hitachi/Boardinabag.html
>>
>>maybe there would be a need for some additional ramflash upgrade.
>>
>>    
>>
>
>Nope...as I see it is a 16-bit CPU...
>
>
>Rick
>
>
>Richard Klingler             mail: richard.klingler at violasystems.com
>Viola Systems Ltd.           http://www.violasystems.com/
>Lemmink?isenkatu 32          phon: +358 (0)201 226 226
>20520 Turku, Finland         mobile: +358 (0)40 748 4711
>_______________________________________________
>uClinux-dev mailing list
>uClinux-dev at uclinux.org
>http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
>This message was resent by uclinux-dev at uclinux.org
>
>  
>




From richard.klingler at violasystems.com  Tue Mar 18 16:16:44 2003
From: richard.klingler at violasystems.com (Richard Klingler)
Date: Tue, 18 Mar 2003 23:16:44 +0200
Subject: [uClinux-dev] h8 board
In-Reply-To: <3E77880F.7040402@siol.net>
Message-ID: <r01050400-1024-EC01E903598611D7A42C00039387ACB6@[10.0.1.2]>

> i'm sorry for not specifing about using ucLinux for h8/300H hitachi family.
> i've seen some web pages about the project.
> 
> h8s and h8/300h share the same core, right? 16-bit. it is possible to 
> run uclinux on those. further, h8/tiny is somekind of "enhanced" - as 
> stated in their docs - h8/300h. thus running uclinux on it shouldn't be 
> a problem...
> 

Please read the datasheet next time (o;

This LSI has an H8/300H CPU with an internal 32-bit architecture that is upward-compatible with the H8/300CPU, and supports only normal mode, which has a 64-kbyte address space.


Never saw any uClinux which could fit onto 64kbytes...(o;

As told before...there is no 16-bit (uC)linux version and never will.


Rick


Richard Klingler             mail: richard.klingler at violasystems.com
Viola Systems Ltd.           http://www.violasystems.com/
Lemmink?isenkatu 32          phon: +358 (0)201 226 226
20520 Turku, Finland         mobile: +358 (0)40 748 4711


From philipn at engarts.com  Tue Mar 18 16:46:22 2003
From: philipn at engarts.com (Philip Nye)
Date: Tue, 18 Mar 2003 21:46:22 -0000
Subject: [uClinux-dev] h8 board
References: <r01050400-1024-906A1324597E11D7A42C00039387ACB6@[10.0.1.2]> <3E77880F.7040402@siol.net>
Message-ID: <001701c2ed97$d1479850$131010ac@aldebaran>

> From: "himba" <himba at siol.net>
>
> i'm sorry for not specifing about using ucLinux for h8/300H hitachi
family.
> i've seen some web pages about the project.
>
> h8s and h8/300h share the same core, right? 16-bit. it is possible to
> run uclinux on those. further, h8/tiny is somekind of "enhanced" - as
> stated in their docs - h8/300h. thus running uclinux on it shouldn't be
> a problem...

The H8/3664 on the board you pointed to does not have an external bus. You
will not get uClinux into the 32k of flash and 2k of RAM on the h8/3664. In
general the h8/tiny series are intended for "tiny" applications and whiole
they may have a fairly powerful core, they do not have the advanced
capabilities of the larger more general purpose h8s parts.

The h8s is not the same core as the h8/300h it is more advanced - though
backward compatible. While the bigger parts would probably run uClinux, I
don't think they are ldeally suited - although they are great for rather
lower level stuff.

You could contact the gnu-h8 mailing list for more info - or try downloading
and reading the datasheets!

Philip



From jwilliams at itee.uq.edu.au  Tue Mar 18 16:46:59 2003
From: jwilliams at itee.uq.edu.au (John Williams)
Date: Wed, 19 Mar 2003 07:46:59 +1000
Subject: [uClinux-dev] Problem "make"ing uClinux
In-Reply-To: <b395e8de3ad7a94b2a51e5eb2dbcb9323e774f24@mail.ekmail.com>
References: <b395e8de3ad7a94b2a51e5eb2dbcb9323e774f24@mail.ekmail.com>
Message-ID: <3E7793D3.8080403@itee.uq.edu.au>

Hi Andrew,

Chizhik, Andrew wrote:
> Looking at the lines mentioned here, there is no "sw_usp" there. For
> example, line 125 in process.c reads:
> printk("USP: %081x\n", rdusp());

> I assume the problem lies in the call to rdusp(). What does that function
> do? What do these errors mean?

sw_usp is a location in kernel memory where the User Stack Pointer 
(hence the name "usp") is saved upon entry to the kernel.  This is 
because the 5307 has no concept of a user/supervisor stack pointer.

To that end, rdusp() is probably a macro, defined in 
/include/asm-m68knommu somewhere.  Ah yes, there it is, an inline 
function defined in processor.h


extern inline unsigned long rdusp(void) {
#ifdef CONFIG_COLDFIRE
         extern unsigned int     sw_usp;
         return(sw_usp);
#else
         unsigned long usp;

         __asm__ __volatile__("move %/usp,%0" : "=a" (usp));
         return usp;
#endif
}

It looks like the configuration for your platform is defining 
CONFIG_COLDFIRE, when perhaps it shouldn't.  I'm no m68k expert - does 
the 68360 have hardware user/supervisor stack pointers, or is it 
emulated in /platform/XXX/entry.S ?  In /platform/5307/entry.S you can 
see how the sw_usp is used on entry /exit to the kernel.

Sorry this is not a solution, just some expanatory stuff.  The 
coldfire/m68k experts should have more for details for you!

Regards,

John



From tchen at on-go.com  Tue Mar 18 17:05:42 2003
From: tchen at on-go.com (thomas chen)
Date: Tue, 18 Mar 2003 17:05:42 -0500
Subject: [uClinux-dev] what is the equivalent of "alias" in sash ?
Message-ID: <3E779836.B41DE343@on-go.com>

is there an alias command for sash???

i am trying to do this

alias tty-ldisc-11 irtty
alias char-major-161 ircomm-tty

and there is no way to do alias in my target?

thanks

tom


From hamilton at sedsystems.ca  Tue Mar 18 17:10:02 2003
From: hamilton at sedsystems.ca (Kendrick Hamilton)
Date: Tue, 18 Mar 2003 16:10:02 -0600 (Canada Central Standard Time)
Subject: [uClinux-dev] Problem "make"ing uClinux
In-Reply-To: <3E7793D3.8080403@itee.uq.edu.au>
Message-ID: <Pine.WNT.4.44.0303181608340.201-100000@sw-55.sedsystems.ca>

I noticed that you are using the 2.4 68360 kernel. Is somebody monitoring
this to  check for things like this?
You might want to try the 2.0.x kernel. I know that it works.
KGH


On Wed, 19 Mar 2003, John Williams wrote:

> Hi Andrew,
>
> Chizhik, Andrew wrote:
> > Looking at the lines mentioned here, there is no "sw_usp" there. For
> > example, line 125 in process.c reads:
> > printk("USP: %081x\n", rdusp());
>
> > I assume the problem lies in the call to rdusp(). What does that function
> > do? What do these errors mean?
>
> sw_usp is a location in kernel memory where the User Stack Pointer
> (hence the name "usp") is saved upon entry to the kernel.  This is
> because the 5307 has no concept of a user/supervisor stack pointer.
>
> To that end, rdusp() is probably a macro, defined in
> /include/asm-m68knommu somewhere.  Ah yes, there it is, an inline
> function defined in processor.h
>
>
> extern inline unsigned long rdusp(void) {
> #ifdef CONFIG_COLDFIRE
>          extern unsigned int     sw_usp;
>          return(sw_usp);
> #else
>          unsigned long usp;
>
>          __asm__ __volatile__("move %/usp,%0" : "=a" (usp));
>          return usp;
> #endif
> }
>
> It looks like the configuration for your platform is defining
> CONFIG_COLDFIRE, when perhaps it shouldn't.  I'm no m68k expert - does
> the 68360 have hardware user/supervisor stack pointers, or is it
> emulated in /platform/XXX/entry.S ?  In /platform/5307/entry.S you can
> see how the sw_usp is used on entry /exit to the kernel.
>
> Sorry this is not a solution, just some expanatory stuff.  The
> coldfire/m68k experts should have more for details for you!
>
> Regards,
>
> John
>
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org
>



From hamilton at sedsystems.ca  Tue Mar 18 17:26:01 2003
From: hamilton at sedsystems.ca (Kendrick Hamilton)
Date: Tue, 18 Mar 2003 16:26:01 -0600 (CST)
Subject: [uClinux-dev] gdbinit script
Message-ID: <Pine.LNX.4.44.0303181625250.1158-100000@sw-55.sedsystems.ca>

Can somebody email me a .gdbinit script for a coldfire 5407 using the bdm.
TIA,
Kendrick


-- 
Kendrick Hamilton E.I.T.
SED Systems, a division of Calian Ltd.
18 Innovation Blvd.
PO Box 1464
Saskatoon, Saskatchewan
Canada
S7N 3R1

Hamilton at sedsystems.ca
Tel: (306) 933-1453
Fax: (306) 933-1486



From himba at siol.net  Tue Mar 18 17:34:58 2003
From: himba at siol.net (himba)
Date: Tue, 18 Mar 2003 23:34:58 +0100
Subject: [uClinux-dev] h8 board
References: <r01050400-1024-EC01E903598611D7A42C00039387ACB6@[10.0.1.2]>
Message-ID: <3E779F12.3090304@siol.net>

thanks
you're right.
i'm totaly new to hitachi mcu. and bad luck - there are like tons of 
same ic numbers and specs. never had the time to even settle for good 
read of one. will do later :)


regards,himba

Richard Klingler wrote:

>>i'm sorry for not specifing about using ucLinux for h8/300H hitachi family.
>>i've seen some web pages about the project.
>>
>>h8s and h8/300h share the same core, right? 16-bit. it is possible to 
>>run uclinux on those. further, h8/tiny is somekind of "enhanced" - as 
>>stated in their docs - h8/300h. thus running uclinux on it shouldn't be 
>>a problem...
>>
>>    
>>
>
>Please read the datasheet next time (o;
>
>This LSI has an H8/300H CPU with an internal 32-bit architecture that is upward-compatible with the H8/300CPU, and supports only normal mode, which has a 64-kbyte address space.
>
>
>Never saw any uClinux which could fit onto 64kbytes...(o;
>
>As told before...there is no 16-bit (uC)linux version and never will.
>
>
>Rick
>
>
>Richard Klingler             mail: richard.klingler at violasystems.com
>Viola Systems Ltd.           http://www.violasystems.com/
>Lemmink?isenkatu 32          phon: +358 (0)201 226 226
>20520 Turku, Finland         mobile: +358 (0)40 748 4711
>_______________________________________________
>uClinux-dev mailing list
>uClinux-dev at uclinux.org
>http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
>This message was resent by uclinux-dev at uclinux.org
>
>  
>




From davidm at snapgear.com  Tue Mar 18 17:48:58 2003
From: davidm at snapgear.com (David McCullough)
Date: Wed, 19 Mar 2003 08:48:58 +1000
Subject: [uClinux-dev] gdbinit script
In-Reply-To: <Pine.LNX.4.44.0303181625250.1158-100000@sw-55.sedsystems.ca>
References: <Pine.LNX.4.44.0303181625250.1158-100000@sw-55.sedsystems.ca>
Message-ID: <20030318224858.GA29356@beast.internal.moreton.com.au>

Jivin Kendrick Hamilton lays it down ...
> Can somebody email me a .gdbinit script for a coldfire 5407 using the bdm.

In the distro,  look under tools/misc/5407.gdb

Cheers,
Davidm

-- 
David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
davidm at snapgear.com  Fx: +61 7 3891 3630  Custom Embedded Solutions + Security


From scott at sthoward.com  Tue Mar 18 17:46:18 2003
From: scott at sthoward.com (Scott Howard)
Date: Tue, 18 Mar 2003 14:46:18 -0800
Subject: [uClinux-dev] h8 board
References: <r01050400-1024-EC01E903598611D7A42C00039387ACB6@[10.0.1.2]>
Message-ID: <3E77A1BA.8050602@sthoward.com>

The H8 has a 16-bit data bus, a 24-bit address bus and 32-bit registers 
- one of everything!! :-)

This CPU is definitely capable of running uclinux. There is already a 
port of uclinux to the H8/300H architecture. Have a look at the 
following link:

http://homepage2.nifty.com/ysato/uClinux-H8/index.en.html

I believe it's already in CVS at uclinux.org.

Regards,

Scott

Richard Klingler wrote:

>>i'm sorry for not specifing about using ucLinux for h8/300H hitachi family.
>>i've seen some web pages about the project.
>>
>>h8s and h8/300h share the same core, right? 16-bit. it is possible to 
>>run uclinux on those. further, h8/tiny is somekind of "enhanced" - as 
>>stated in their docs - h8/300h. thus running uclinux on it shouldn't be 
>>a problem...
>>
>>
> 
> Please read the datasheet next time (o;
> 
> This LSI has an H8/300H CPU with an internal 32-bit architecture that is upward-compatible with the H8/300CPU, and supports only normal mode, which has a 64-kbyte address space.
> 
> 
> Never saw any uClinux which could fit onto 64kbytes...(o;
> 
> As told before...there is no 16-bit (uC)linux version and never will.
> 
> 
> Rick
> 
> 
> Richard Klingler             mail: richard.klingler at violasystems.com
> Viola Systems Ltd.           http://www.violasystems.com/
> Lemmink?isenkatu 32          phon: +358 (0)201 226 226
> 20520 Turku, Finland         mobile: +358 (0)40 748 4711
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org
> 
> 





From scott at sthoward.com  Tue Mar 18 17:48:47 2003
From: scott at sthoward.com (Scott Howard)
Date: Tue, 18 Mar 2003 14:48:47 -0800
Subject: [uClinux-dev] h8 board
References: <r01050400-1024-EC01E903598611D7A42C00039387ACB6@[10.0.1.2]>
 <3E77A1BA.8050602@sthoward.com>
Message-ID: <3E77A24F.4060408@sthoward.com>

I should point out however, that you are correct in saying that uclinux 
will not run on this particular derivative of H8; its flash and RAM 
sizes are too small, by at least one order of magnitude.

Regards,

Scott

Scott Howard wrote:

> The H8 has a 16-bit data bus, a 24-bit address bus and 32-bit registers 
> - one of everything!! :-)
> 
> This CPU is definitely capable of running uclinux. There is already a 
> port of uclinux to the H8/300H architecture. Have a look at the 
> following link:
> 
> http://homepage2.nifty.com/ysato/uClinux-H8/index.en.html
> 
> I believe it's already in CVS at uclinux.org.
> 
> Regards,
> 
> Scott
> 
> Richard Klingler wrote:
> 
>>> i'm sorry for not specifing about using ucLinux for h8/300H hitachi 
>>> family.
>>> i've seen some web pages about the project.
>>>
>>> h8s and h8/300h share the same core, right? 16-bit. it is possible to 
>>> run uclinux on those. further, h8/tiny is somekind of "enhanced" - as 
>>> stated in their docs - h8/300h. thus running uclinux on it shouldn't 
>>> be a problem...
>>>
>>>
>>
>> Please read the datasheet next time (o;
>>
>> This LSI has an H8/300H CPU with an internal 32-bit architecture that 
>> is upward-compatible with the H8/300CPU, and supports only normal 
>> mode, which has a 64-kbyte address space.
>>
>>
>> Never saw any uClinux which could fit onto 64kbytes...(o;
>>
>> As told before...there is no 16-bit (uC)linux version and never will.
>>
>>
>> Rick
>>
>>
>> Richard Klingler             mail: richard.klingler at violasystems.com
>> Viola Systems Ltd.           http://www.violasystems.com/
>> Lemmink?isenkatu 32          phon: +358 (0)201 226 226
>> 20520 Turku, Finland         mobile: +358 (0)40 748 4711
>> _______________________________________________
>> uClinux-dev mailing list
>> uClinux-dev at uclinux.org
>> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
>> This message was resent by uclinux-dev at uclinux.org
>>
>>
> 
> 





From philwil at earthlink.net  Tue Mar 18 17:46:04 2003
From: philwil at earthlink.net (Phil Wilshire)
Date: Tue, 18 Mar 2003 17:46:04 -0500
Subject: [uClinux-dev] what is the equivalent of "alias" in sash ?
References: <3E779836.B41DE343@on-go.com>
Message-ID: <3E77A1AC.59C3B90B@earthlink.net>

Hi Thomas,
I presume that you are trying to do this for
IrDA.

I bypassed all of the autoload options and manually installed 
the required modules.
irattach will attmpt to fork for each module load.


this means that you done need the modules set up in this manner.

regards
  Phil Wilshire


thomas chen wrote:
> 
> is there an alias command for sash???
> 
> i am trying to do this
> 
> alias tty-ldisc-11 irtty
> alias char-major-161 ircomm-tty
> 
> and there is no way to do alias in my target?
> 
> thanks
> 
> tom
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org

-- 
SDCS -- System Design & Consulting Services LLC, http://www.sysdcs.com
** Embedded Linux Training **  email me for details  
630 Springhouse Sq., Leesburg VA 20175 t: 703 669 9766 f: 703 669 9768


From davidm at snapgear.com  Tue Mar 18 18:39:28 2003
From: davidm at snapgear.com (David McCullough)
Date: Wed, 19 Mar 2003 09:39:28 +1000
Subject: [uClinux-dev] Problem with uclinux-dist-20030305
In-Reply-To: <a05111b00ba9cf22d31ca@[10.0.1.240]>
References: <a05111b00ba9cf22d31ca@[10.0.1.240]>
Message-ID: <20030318233928.GA3203@beast.internal.moreton.com.au>


Jivin Jay Vaughan lays it down ...
> Out of the box, the uclinux-dist-20030305, configured plain vanilla 
> for MCF5272 (Motorola Eval board), produces this error when compiling 
> the threaddemos:
...
> Working POSIX threads on 5272 has *always* been a pain in the ass for 
> me, as far as uClinux is concerned.  One of these days, the -dist 
> releases will *just work* for libpthreads/m5272, but until then I'm 
> compelled to be stupid about it and just ask you guys, since there 
> always seem to be hidden gotchas.
> 
> Maybe I've just not configured something properly with this release, 
> but what I did was a) download the tarball, b) make menuconfig to set 
> things up exactly as I had them in my older (-20030226) uClinux 
> system, c) 'make dep ; make' ...
> 
> Seems to me one of the big reasons for this release was to make 
> libpthread available for 5272 users wanting to take advantage of the 
> XIP fixes also done as part of the m68k-elf-tools-20030314.sh 
> release, but alas ... threads are *still* broken, config-wise, with 
> this -dist.
> 
> It would appear, anyway.  Please correct me if I'm completely missing 
> something ...

Every thing in the tree is working for pthreads,  but not all platforms
have had it enabled (ie., we haven't tested it specifically).

The reason pthreads isn't working for you is that it isn't enabled in the
uClibc config.

Here is a patch for the dist the fixes the Mot configs and also a small
problem with the top level Makefile which is needed when you are
switching platforms a lot ;-)

make clean,  make config and force defaults, make dep, make and you
should have a full pthreads 5272.  Then you can be the first to test it ;-)

Cheers,
Davidm

-- 
David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
davidm at snapgear.com  Fx: +61 7 3891 3630  Custom Embedded Solutions + Security
-------------- next part --------------
Index: uClinux-dist/Makefile
===================================================================
RCS file: /cvs/sw/new-wave/Makefile,v
retrieving revision 1.77
retrieving revision 1.80
diff -u -r1.77 -r1.80
--- uClinux-dist/Makefile	22 Jan 2003 07:04:30 -0000	1.77
+++ uClinux-dist/Makefile	18 Mar 2003 05:09:35 -0000	1.80
@@ -163,6 +163,7 @@
 	@$(MAKE) oldconfig_linux
 	@$(MAKE) oldconfig_modules
 	@$(MAKE) oldconfig_config
+	@$(MAKE) oldconfig_uClibc
 	@config/setconfig final
 
 .PHONY: modules
@@ -207,6 +208,8 @@
 	[ ! -d modules ] || $(MAKEARCH) -C modules oldconfig
 oldconfig_linux:
 	$(MAKEARCH_KERNEL) -C $(LINUXDIR) oldconfig
+oldconfig_uClibc:
+	[ -z "$(findstring uClibc,$(LIBCDIR))" ] || $(MAKEARCH) -C $(LIBCDIR) oldconfig
 
 ############################################################################
 #
@@ -271,12 +274,14 @@
 real_clean mrproper: clean
 	-$(MAKEARCH_KERNEL) -C $(LINUXDIR) mrproper
 	-$(MAKEARCH) -C config clean
+	-$(MAKEARCH) -C uClibc distclean
 	rm -rf romfs config.in config.arch config.tk images
 	rm -f modules/config.tk
 	rm -rf .config .config.old .oldconfig autoconf.h
 
 distclean: mrproper
 	-$(MAKEARCH_KERNEL) -C $(LINUXDIR) distclean
+	-rm -f user/tinylogin/applet_source_list user/tinylogin/config.h
 
 %_only:
 	[ ! -d "$(@:_only=)" ] || $(MAKEARCH) -C $(@:_only=)
Index: uClinux-dist/vendors/Motorola/M5249C3/config.uClibc
===================================================================
RCS file: /cvs/sw/new-wave/vendors/Motorola/M5249C3/config.uClibc,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- uClinux-dist/vendors/Motorola/M5249C3/config.uClibc	25 Feb 2003 01:21:55 -0000	1.4
+++ uClinux-dist/vendors/Motorola/M5249C3/config.uClibc	18 Mar 2003 23:01:48 -0000	1.5
@@ -23,7 +23,7 @@
 #
 # DOPIC is not set
 UCLIBC_CTOR_DTOR=y
-# UCLIBC_HAS_THREADS is not set
+UCLIBC_HAS_THREADS=y
 UCLIBC_HAS_LFS=y
 MALLOC=y
 # MALLOC_930716 is not set
Index: uClinux-dist/vendors/Motorola/M5272C3/config.uClibc
===================================================================
RCS file: /cvs/sw/new-wave/vendors/Motorola/M5272C3/config.uClibc,v
retrieving revision 1.4
retrieving revision 1.6
diff -u -r1.4 -r1.6
--- uClinux-dist/vendors/Motorola/M5272C3/config.uClibc	25 Feb 2003 01:21:55 -0000	1.4
+++ uClinux-dist/vendors/Motorola/M5272C3/config.uClibc	18 Mar 2003 23:01:48 -0000	1.6
@@ -23,7 +23,7 @@
 #
 # DOPIC is not set
 UCLIBC_CTOR_DTOR=y
-# UCLIBC_HAS_THREADS is not set
+UCLIBC_HAS_THREADS=y
 UCLIBC_HAS_LFS=y
 MALLOC=y
 # MALLOC_930716 is not set
@@ -59,3 +59,4 @@
 # DODEBUG is not set
 # DOASSERTS is not set
 # UCLIBC_MALLOC_DEBUGGING is not set
+

From gerg at snapgear.com  Tue Mar 18 19:11:28 2003
From: gerg at snapgear.com (Greg Ungerer)
Date: Wed, 19 Mar 2003 10:11:28 +1000
Subject: [uClinux-dev] h8 board
In-Reply-To: <3E779F12.3090304@siol.net>
References: <r01050400-1024-EC01E903598611D7A42C00039387ACB6@[10.0.1.2]> <3E779F12.3090304@siol.net>
Message-ID: <3E77B5B0.9020205@snapgear.com>

Hi Himba,

himba wrote:
> thanks
> you're right.
> i'm totaly new to hitachi mcu. and bad luck - there are like tons of 
> same ic numbers and specs. never had the time to even settle for good 
> read of one. will do later :)

Quite a good number of H8/300 devices are supported in the
uClinux 2.0.x and 2.4.x kernels. from the arch/h8300/config.in
I can see:

      H8/3002
      H8/3006,3007,gdb_simulator
      H8/3044,3045,3046,3047,3048,3052
      H8/3065,3066,3067,3068,3069

For sepcifics have a look at Yoshinori Sato's pages at:

  http://homepage2.nifty.com/ysato/uClinux-H8/index.en.html

Regards
Greg



> Richard Klingler wrote:
> 
>>> i'm sorry for not specifing about using ucLinux for h8/300H hitachi 
>>> family.
>>> i've seen some web pages about the project.
>>>
>>> h8s and h8/300h share the same core, right? 16-bit. it is possible to 
>>> run uclinux on those. further, h8/tiny is somekind of "enhanced" - as 
>>> stated in their docs - h8/300h. thus running uclinux on it shouldn't 
>>> be a problem...
>>>
>>>   
>>
>>
>> Please read the datasheet next time (o;
>>
>> This LSI has an H8/300H CPU with an internal 32-bit architecture that 
>> is upward-compatible with the H8/300CPU, and supports only normal 
>> mode, which has a 64-kbyte address space.
>>
>>
>> Never saw any uClinux which could fit onto 64kbytes...(o;
>>
>> As told before...there is no 16-bit (uC)linux version and never will.
>>
>>
>> Rick
>>
>>
>> Richard Klingler             mail: richard.klingler at violasystems.com
>> Viola Systems Ltd.           http://www.violasystems.com/
>> Lemmink?isenkatu 32          phon: +358 (0)201 226 226
>> 20520 Turku, Finland         mobile: +358 (0)40 748 4711
>> _______________________________________________
>> uClinux-dev mailing list
>> uClinux-dev at uclinux.org
>> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
>> This message was resent by uclinux-dev at uclinux.org
>>
>>  
>>
> 
> 
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org
> 

-- 
------------------------------------------------------------------------
Greg Ungerer  --  Chief Software Wizard        EMAIL:  gerg at snapgear.com
SnapGear Pty Ltd                               PHONE:    +61 7 3435 2888
825 Stanley St,                                  FAX:    +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia              WEB:   www.SnapGear.com



From tchen at on-go.com  Tue Mar 18 22:22:10 2003
From: tchen at on-go.com (Thomas Chen)
Date: Tue, 18 Mar 2003 19:22:10 -0800
Subject: [uClinux-dev] what is the equivalent of "alias" in sash ?
In-Reply-To: <3E77A1AC.59C3B90B@earthlink.net>
Message-ID: <BA9D2261.92F2%tchen@on-go.com>

thanks

yes, i am trying it for irda, and irattach does fork several times
(ie, ps shows several irattach tasks)...
and ifconfig has an irda entry....

but when i try to run ppp on top of ircomm0, it does not work
and i though perhaps it is this because i have

mknod ircomm c 161 0

and

irattach /dev/ttyS1 -d xxx &

but ircomm0 entierh my pda see each other


on 3/18/03 2:46 PM, Phil Wilshire at philwil at earthlink.net wrote:

> Hi Thomas,
> I presume that you are trying to do this for
> IrDA.
> 
> I bypassed all of the autoload options and manually installed
> the required modules.
> irattach will attmpt to fork for each module load.
> 
> 
> this means that you done need the modules set up in this manner.
> 
> regards
> Phil Wilshire
> 
> 
> thomas chen wrote:
>> 
>> is there an alias command for sash???
>> 
>> i am trying to do this
>> 
>> alias tty-ldisc-11 irtty
>> alias char-major-161 ircomm-tty
>> 
>> and there is no way to do alias in my target?
>> 
>> thanks
>> 
>> tom
>> _______________________________________________
>> uClinux-dev mailing list
>> uClinux-dev at uclinux.org
>> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
>> This message was resent by uclinux-dev at uclinux.org



From gerg at snapgear.com  Tue Mar 18 19:20:00 2003
From: gerg at snapgear.com (Greg Ungerer)
Date: Wed, 19 Mar 2003 10:20:00 +1000
Subject: [uClinux-dev] Problem "make"ing uClinux
In-Reply-To: <3E7793D3.8080403@itee.uq.edu.au>
References: <b395e8de3ad7a94b2a51e5eb2dbcb9323e774f24@mail.ekmail.com> <3E7793D3.8080403@itee.uq.edu.au>
Message-ID: <3E77B7B0.807@snapgear.com>

Hi Andrew, John,

John Williams wrote:
> Chizhik, Andrew wrote:
>> Looking at the lines mentioned here, there is no "sw_usp" there. For
>> example, line 125 in process.c reads:
>> printk("USP: %081x\n", rdusp());
[snip]
> It looks like the configuration for your platform is defining 
> CONFIG_COLDFIRE, when perhaps it shouldn't.  I'm no m68k expert - does 
> the 68360 have hardware user/supervisor stack pointers, or is it 
> emulated in /platform/XXX/entry.S ?  In /platform/5307/entry.S you can 
> see how the sw_usp is used on entry /exit to the kernel.

The 68360 has hardware usp and ksp, so you don't need the
sw_usp. Andrew it looks like your config is a little screwed
up. Did you do a "make clean" and "make dep" after changing
your configuration?

Regards
Greg


------------------------------------------------------------------------
Greg Ungerer  --  Chief Software Wizard        EMAIL:  gerg at snapgear.com
SnapGear Pty Ltd                               PHONE:    +61 7 3435 2888
825 Stanley St,                                  FAX:    +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia              WEB:   www.SnapGear.com



From bkc at murkworks.com  Tue Mar 18 20:34:37 2003
From: bkc at murkworks.com (Brad Clements)
Date: Tue, 18 Mar 2003 20:34:37 -0500
Subject: [uClinux-dev] dist 20030305 doesn't build for Arcturus uC5272
In-Reply-To: <20030317231254.GA19066@beast.internal.moreton.com.au>
References: <1047933579.1287.54.camel@troca>
Message-ID: <3E777F83.15773.24BAC4D1@localhost>

Before diving in to "fix" I just want to confirm that no one else has tried and succeeded 
building a basic kernel for the Arcturus uC5272

I selected the board, and left all other settings as defaults. Make dep; make and get 
this:

make[2]: Entering directory `/var/local/src/uClinux-dist/linux-2.4.x/arch/m68knommu/platform/5272'
make[2]: *** No rule to make target `/crt0_ram.S', needed by `/crt0_ram.o'.  Stop.
make[2]: Leaving directory `/var/local/src/uClinux-dist/linux-2.4.x/arch/m68knommu/platform/5272'
make[1]: *** [_dir_arch/m68knommu/platform/5272] Error 2
make[1]: Leaving directory `/var/local/src/uClinux-dist/linux-2.4.x'
make: *** [linux] Error 1



The Arcturus uC5272 didn't work with previous dists either, probably because they just 
hadn't submitted the necessary patches. 

I just wanted to see if anyone else had this problem before I "dive in".

I see other 5272 users on the list using this dist, so .. maybe it's just my luck.

--  here's some things I've tried tinkering with tonight before sending this, based on my 
previously "working" dist (feb 2002 that came with Arcturus CD)

Snooping linux-2.4.x/arch/Boards.mk, I see I had this in my previous dist

#ifdef CONFIG_M5272
<snip>

ifdef CONFIG_BOARD_UC5272
BOARD := uC5272
endif

I also see I that in my "working" dist I have a

uClinux-coldfire/linux-2.4.x/arch/m68knommu/platform/5272/uC5272

With the necessary files:

total 40
drwxr-xr-x    2 bkc      bkc          4096 Jan 29 10:15 ./
drwxr-xr-x    5 bkc      bkc          4096 Jan 29 10:15 ../
-rw-rw-r--    1 bkc      bkc          1812 Jan 29 10:15 crt0_ram.o
-rw-r--r--    1 bkc      bkc          3882 Mar 26  2002 crt0_ram.S
-rw-r--r--    1 bkc      bkc          3158 Mar 26  2002 crt0_rom.S
-rw-r--r--    1 bkc      bkc          4615 Mar 26  2002 .gdbinit
-rw-r--r--    1 bkc      bkc          1569 Oct 31 14:59 ram.ld
-rw-r--r--    1 bkc      bkc            22 Jan 30 18:30 romfs.default.ld
-rw-r--r--    1 bkc      bkc            22 Jan 30 18:30 romfs.ld


Guess I'll copy these..
	
also need to edit config.in and add

        bool 'Arcturus Networks uC5272 dimm board support' CONFIG_BOARD_UC5272

added this to vendors/Arcturus/uC5272/config.linux-2.4.x

CONFIG_BOARD_UC5272=y


Now this is starting to smell bad. I'm beginning to think that my previous "fix" for this 
wasn't correct.

After all this, BOARDS still isn't being set correctly. :-(




-- 
Brad Clements,                bkc at murkworks.com   (315)268-1000
http://www.murkworks.com                          (315)268-9812 Fax
http://www.wecanstopspam.org/                   AOL-IM: BKClements



From spudmonkey at racsa.co.cr  Tue Mar 18 21:17:54 2003
From: spudmonkey at racsa.co.cr (spudmonkey at racsa.co.cr)
Date: Tue, 18 Mar 2003 19:17:54 -0700
Subject: [uClinux-dev] h8 board
Message-ID: <7761d77734dd.7734dd7761d7@racsa.co.cr>

Here is another H8 uClinux site (and a source for an H8S/2148 board): 
http://www.azpower.com/H8-uClinux/

Greg Nutt

> Date: Tue, 18 Mar 2003 14:46:18 -0800
> From: Scott Howard <scott at sthoward.com>
> Subject: Re: [uClinux-dev] h8 board
> To: uclinux-dev at uclinux.org
> Reply-To: uclinux-dev at uclinux.org
> 
> The H8 has a 16-bit data bus, a 24-bit address bus and 32-bit 
> registers 
> - one of everything!! :-)
> 
> This CPU is definitely capable of running uclinux. There is 
> already a 
> port of uclinux to the H8/300H architecture. Have a look at the 
> following link:
> 
> http://homepage2.nifty.com/ysato/uClinux-H8/index.en.html
> 
> I believe it's already in CVS at uclinux.org.
> 
> Regards,
> 
> Scott
> 
> Richard Klingler wrote:
> 
> >>i'm sorry for not specifing about using ucLinux for h8/300H 
> hitachi family.
> >>i've seen some web pages about the project.
> >>
> >>h8s and h8/300h share the same core, right? 16-bit. it is 
> possible to 
> >>run uclinux on those. further, h8/tiny is somekind of "enhanced" 
> - as 
> >>stated in their docs - h8/300h. thus running uclinux on it 
> shouldn't be 
> >>a problem...
> >>
> >>
> > 
> > Please read the datasheet next time (o;
> > 
> > This LSI has an H8/300H CPU with an internal 32-bit architecture 
> that is upward-compatible with the H8/300CPU, and supports only 
> normal mode, which has a 64-kbyte address space.
> > 
> > 
> > Never saw any uClinux which could fit onto 64kbytes...(o;
> > 
> > As told before...there is no 16-bit (uC)linux version and never 
> will.> 
> > 
> > Rick
> > 
> > 
> > Richard Klingler             mail: richard.klingler at violasystems.com
> > Viola Systems Ltd.           http://www.violasystems.com/
> > Lemmink?isenkatu 32          phon: +358 (0)201 226 226
> > 20520 Turku, Finland         mobile: +358 (0)40 748 4711
> > _______________________________________________
> > uClinux-dev mailing list
> > uClinux-dev at uclinux.org
> > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> > This message was resent by uclinux-dev at uclinux.org
> > 
> > 
> 
> 
> 
> 




From ryanc at intrapower.com.au  Tue Mar 18 21:20:55 2003
From: ryanc at intrapower.com.au (Ryan Crouch)
Date: Wed, 19 Mar 2003 12:20:55 +1000
Subject: [uClinux-dev] Interactive Telnet Script
Message-ID: <39FC60B5F73B7A4095083E853E9878350A0A04@ip-fm1.intrapower.com.au>

Hello all,
I need to automate a telnet session via a script of some sort in order
to control a router device plugged into the uClinux machine. Has anyone
successfully created an interactive telnet script using chat/expect or
anything similar? 

-Ryan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20030319/2cbd05c0/attachment.html>

From sanbhat at globaledgesoft.com  Tue Mar 18 22:34:32 2003
From: sanbhat at globaledgesoft.com (Santosh Bhat)
Date: Wed, 19 Mar 2003 09:04:32 +0530
Subject: [uClinux-dev] Big endian uClinux 2.4 for ARM7TDMI?
References: <007001c2ed2a$15f48170$6367608c@ccl.itri.org.tw>
Message-ID: <029c01c2edc8$7478a160$800210ac@16.2.63.ges1>

Hi Stephan , I am able to generate the big endian code . I have sent a couple of patches to do that also (most of it from David M ) please dig through the mailing list to get the right patch and the detailed build step there , 
Cheers
Santosh Bat
  ----- Original Message ----- 
  From: StephanChiu 
  To: uclinux-dev at uclinux.org 
  Sent: Tuesday, March 18, 2003 2:10 PM
  Subject: [uClinux-dev] Big endian uClinux 2.4 for ARM7TDMI?


  Did anyone try the uClinux-Samsung-dist-20020927eb.tar.gz package from Mac?
  I think the package is patched by David M's patch.
  Dutring the kernel config, I check the "Generating Big Endian Code" option that enables the CONFIG_CPU_BIG_ENDIAN.
  But, I failed in final step, make.
  Did someone meet the problem or just work it out?
  Here is my error message, Hope this helps...
  -------------------------------------------------------
  /opt/uClinux/arm-elf/bin/gld: _divsi3.o: compiled for a little endian system and target is big endian
  File in wrong format: failed to merge target specific data of file /opt/uClinux/
  lib/gcc-lib/arm-elf/2.95.3/libgcc.a(_divsi3.o)
  /opt/uClinux/arm-elf/bin/gld: _modsi3.o: compiled for a little endian system and target is big endian
  File in wrong format: failed to merge target specific data of file /opt/uClinux/
  lib/gcc-lib/arm-elf/2.95.3/libgcc.a(_modsi3.o)
  /opt/uClinux/arm-elf/bin/gld: _udivsi3.o: compiled for a little endian system and target is big endian
  File in wrong format: failed to merge target specific data of file /opt/uClinux/
  lib/gcc-lib/arm-elf/2.95.3/libgcc.a(_udivsi3.o)
  /opt/uClinux/arm-elf/bin/gld: _umodsi3.o: compiled for a little endian system and target is big endian
  File in wrong format: failed to merge target specific data of file /opt/uClinux/
  lib/gcc-lib/arm-elf/2.95.3/libgcc.a(_umodsi3.o)
  make[1]: *** [linux] Error 1
  make[1]: Leaving directory `/root/20020927_eb/uClinux-dist/linux-2.4.x'
  make: *** [linux] Error 1
   
  Cheers,
  Stephan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20030319/6349403b/attachment.html>

From justin at tmq.com.au  Tue Mar 18 23:16:30 2003
From: justin at tmq.com.au (Justin Clacherty)
Date: 19 Mar 2003 14:16:30 +1000
Subject: [uClinux-dev] uclinux-elf-tools-20030314 released
In-Reply-To: <20030318115655.GB8398@beast.internal.moreton.com.au>
References: <20030315130050.GC14525@beast.internal.moreton.com.au>
	<1047969542.16340.5.camel@rhianna.tmq.com.au> 
	<20030318115655.GB8398@beast.internal.moreton.com.au>
Message-ID: <1048047395.1088.16.camel@rhianna.tmq.com.au>

On Tue, 2003-03-18 at 21:56, David McCullough wrote:
> Is there any reason your need them ?

Not really, I think I need to engage the brain before mailing to the
list...I didn't think anything of the fact that STL was now in
there...doh!

Now off to find out why our rather small test app is compiling to a 480k
binary...

Justin




From tongcd at neusoft.com  Wed Mar 19 00:06:12 2003
From: tongcd at neusoft.com (ChangDa Tong)
Date: Wed, 19 Mar 2003 13:06:12 +0800
Subject: [uClinux-dev] about nommu or mmu
Message-ID: <003e01c2edd5$44d10080$b51ea8c0@tongcd>

We know uClinux is designed for nommu processor. From hardware point of
view, I know little advantage of the nommu cpu over the mmu's.Perhaps
include less power assumption, a little benfit of speed, less price and
what more?
I mean if more and more cpu used in the embedded device have a mmu,
could uclinux have less usage? Could the nommu cpu's is used less in the
near future? Maybe this affect  the spreadness of uclinux. Could anyone
show some facts that nommu processor is hard to be repleace the nommu
ones?
Thank you for commenting on this.(I didn't find debate about this
subject in the archieve)




From jwilliams at itee.uq.edu.au  Wed Mar 19 00:44:41 2003
From: jwilliams at itee.uq.edu.au (John Williams)
Date: Wed, 19 Mar 2003 15:44:41 +1000
Subject: [uClinux-dev] about nommu or mmu
In-Reply-To: <003e01c2edd5$44d10080$b51ea8c0@tongcd>
References: <003e01c2edd5$44d10080$b51ea8c0@tongcd>
Message-ID: <3E7803C9.7080902@itee.uq.edu.au>

ChangDa Tong wrote:

> I mean if more and more cpu used in the embedded device have a mmu,
> could uclinux have less usage? Could the nommu cpu's is used less in the
> near future? Maybe this affect  the spreadness of uclinux. Could anyone
> show some facts that nommu processor is hard to be repleace the nommu
> ones?

An interesting question, which could be subtitled "The future of uClinux".

To get the ball rolling, you might speculate that uClinux will just go 
deeper and deeper embedded.  At the coal face it will always be the 
struggle of getting the necessary performance from the cheapest piece of 
hardware that will do the job.

When the processors used in a network router (like SnapGear's stuff) can 
"afford" an MMU, then they would probably upgrade to regular linux.

However, by that time, even smaller, cheaper and faster no-mmu 
processors will exist, and they will be embedded in your internet-ready 
toaster.  Then, by the time the toaster manufacturer upgrades to proper 
linux, maybe you'll run uClinux in your internet enabled wrist watch, or 
the microchip embedded in your skull that reminds you to take out the 
garbage and feed the cat.  I can see it now, tattoos reading "uClinux 
inside"!

Of course I'm being a bit silly, but the "ubiquitous computing" folks 
will need an OS, and uClinux might well be it.

Remember that in the early days IBM (or so the story goes) predicted the 
global market for "computers" as being upper bounded somewhere around 
10.  Oh, and Bill Gates said no-one would ever need more than 640K of RAM.

Cheers,

John



From yangyajun at hisense.cngb.com  Wed Mar 19 01:09:23 2003
From: yangyajun at hisense.cngb.com (=?gb2312?B?0e7Rx778?=)
Date: Wed, 19 Mar 2003 14:09:23 +0800
Subject: [uClinux-dev] A fool question:what directory is the root of the kernel tree
Message-ID: <002401c2edde$16d4c280$542289c0@LocalHost>

      Can anyone help me?
      Thank you very much!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20030319/7b30cd40/attachment.html>

From gerg at snapgear.com  Wed Mar 19 01:37:23 2003
From: gerg at snapgear.com (Greg Ungerer)
Date: Wed, 19 Mar 2003 16:37:23 +1000
Subject: [uClinux-dev] dist 20030305 doesn't build for Arcturus uC5272
In-Reply-To: <3E777F83.15773.24BAC4D1@localhost>
References: <1047933579.1287.54.camel@troca> <3E777F83.15773.24BAC4D1@localhost>
Message-ID: <3E781023.5070107@snapgear.com>

Hi Brad,

Brad Clements wrote:
> Before diving in to "fix" I just want to confirm that no one else has tried and succeeded 
> building a basic kernel for the Arcturus uC5272

This has been talked about a bit recently on this list...


> I selected the board, and left all other settings as defaults. Make dep; make and get 
> this:
> 
> make[2]: Entering directory `/var/local/src/uClinux-dist/linux-2.4.x/arch/m68knommu/platform/5272'
> make[2]: *** No rule to make target `/crt0_ram.S', needed by `/crt0_ram.o'.  Stop.
> make[2]: Leaving directory `/var/local/src/uClinux-dist/linux-2.4.x/arch/m68knommu/platform/5272'
> make[1]: *** [_dir_arch/m68knommu/platform/5272] Error 2
> make[1]: Leaving directory `/var/local/src/uClinux-dist/linux-2.4.x'
> make: *** [linux] Error 1

This is a known limitation in the 20030305 uClinux-dist (and in
fact in all previous dist releases too). The missing code had
never been put into CVS.



> The Arcturus uC5272 didn't work with previous dists either, probably because they just 
> hadn't submitted the necessary patches. 

Exactly.


> I just wanted to see if anyone else had this problem before I "dive in".

The code is now in CVS (as of a couple of days ago). If you want
all those missing files, and a few updated ones then get uClinux-2.4.x
from cvs.uclinux.org. There may still be one open issue with the
FEC driver, but the rest of the code should be all there now.

Regards
Greg



------------------------------------------------------------------------
Greg Ungerer  --  Chief Software Wizard        EMAIL:  gerg at snapgear.com
SnapGear Pty Ltd                               PHONE:    +61 7 3435 2888
825 Stanley St,                                  FAX:    +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia              WEB:   www.SnapGear.com



From gerg at snapgear.com  Wed Mar 19 01:41:30 2003
From: gerg at snapgear.com (Greg Ungerer)
Date: Wed, 19 Mar 2003 16:41:30 +1000
Subject: [uClinux-dev] uClinux kernel with ramdisk FS can work?
In-Reply-To: <20030318035625.13432.qmail@web16508.mail.tpe.yahoo.com>
References: <20030318035625.13432.qmail@web16508.mail.tpe.yahoo.com>
Message-ID: <3E78111A.3050701@snapgear.com>

Hi,

lnys.tw wrote:
> I'm a newbie with unclinux. I can run uClinux kernel
> with romfs FS on Samsung 4510 eval board well. But
> now, I want to change romfs FS (root) to ramdisk FS
> and I fail. (like linux booting with compressed
> ramdisk on x86 platform).

Are you using an EXT2 filesystem on a ramdisk?


> I check the related
> discussions on this mail list before and can't find
> the answer to boot uClinux kernel with ramdisk FS
> correctly. So I want to ask if it is hard to boot
> uClinux with ramdisk FS (I mean need modify a lot of
> code or architecture)?

I have done it with uClinux on the ColdFire CPU's.
Wasn't all that difficult to get setup and working.


> Or I miss something (I disable
> blkmem driver and enable initial RAM disk (initrd)
> support and add fixup function codes to set up ramdisk
> start address and size in arch.c)?

That is right.


> my booting output as follows :
> 
> Linux version 2.4.20-uc0 (lnys at miracle.avamax.com)
[snip]
> RAMDISK: Compressed image found at block 0
> Freeing initrd memory: 3072K
> VFS: Mounted root (ext2 filesystem).
> Freeing init memory: 44K
> Warning: unable to open an initial console.
> Kernel panic: Attempted to kill init!

This usually indicates that your devices nodes are
missing or not created correctly. How do you package
up your root ext2 filesystem?

Regards
Greg


------------------------------------------------------------------------
Greg Ungerer  --  Chief Software Wizard        EMAIL:  gerg at snapgear.com
SnapGear Pty Ltd                               PHONE:    +61 7 3435 2888
825 Stanley St,                                  FAX:    +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia              WEB:   www.SnapGear.com



From selvam at sesl.global.sharp.co.jp  Wed Mar 19 01:56:54 2003
From: selvam at sesl.global.sharp.co.jp (Selvam)
Date: Wed, 19 Mar 2003 14:56:54 +0800
Subject: [uClinux-dev] Help please.....
In-Reply-To: <03031810110300.01482@localhost>
References: <r01050400-1024-2136CA8F546211D7AEEB00039387ACB6@[10.0.1.2]>
 <03031718002901.01459@localhost> <03031810110300.01482@localhost>
Message-ID: <03031914565402.20752@localhost>

Hi, my uclinux seems booting well, but I don't get the shell
prompt. When I do printf() in init.c (\sbin\init)  it's not printed
in my serial console. I belive that the console device are opened properly 
but the output goes somewhere else. 

Appreciate if you guys can explain me,
what should I do to ensure my console output goes to serial port.
Or point me to some relevant documents.
I've  enabled "console on serial port" in .config.


thanks
Selvam



From richard.klingler at violasystems.com  Wed Mar 19 02:19:38 2003
From: richard.klingler at violasystems.com (Richard Klingler)
Date: Wed, 19 Mar 2003 09:19:38 +0200
Subject: [uClinux-dev] Help please.....
In-Reply-To: <03031914565402.20752@localhost>
Message-ID: <r01050400-1024-251EBABA59DB11D785CF00039387ACB6@[10.0.1.2]>

> Hi, my uclinux seems booting well, but I don't get the shell
> prompt. When I do printf() in init.c (\sbin\init)  it's not printed
> in my serial console. I belive that the console device are opened properly 
> but the output goes somewhere else. 
> 

Never say "seems" (o;

How do you know that your console is open?

Can you telnet in?


Some more info from your side would be needed here like
bootup messages and what system you're using...and not
"seems to boot" (o;


Rick


Richard Klingler             mail: richard.klingler at violasystems.com
Viola Systems Ltd.           http://www.violasystems.com/
Lemmink?isenkatu 32          phon: +358 (0)201 226 226
20520 Turku, Finland         mobile: +358 (0)40 748 4711


From himba at siol.net  Wed Mar 19 02:31:04 2003
From: himba at siol.net (himba)
Date: Wed, 19 Mar 2003 08:31:04 +0100
Subject: [uClinux-dev] h8 board
References: <7761d77734dd.7734dd7761d7@racsa.co.cr>
Message-ID: <3E781CB8.1050207@siol.net>

i've seen both pages

http://www.azpower.com/H8-uClinux/
and
http://homepage2.nifty.com/ysato/uClinux-H8/index.en.html

i looked at the uclinux uClinux-2.4.x/arch/h8300/config.in on CVS and  didn't find h8-3062? it doesn't work?

regards, himba

spudmonkey at racsa.co.cr wrote:

>Here is another H8 uClinux site (and a source for an H8S/2148 board): 
>http://www.azpower.com/H8-uClinux/
>
>Greg Nutt
>
>  
>
>>Date: Tue, 18 Mar 2003 14:46:18 -0800
>>From: Scott Howard <scott at sthoward.com>
>>Subject: Re: [uClinux-dev] h8 board
>>To: uclinux-dev at uclinux.org
>>Reply-To: uclinux-dev at uclinux.org
>>
>>The H8 has a 16-bit data bus, a 24-bit address bus and 32-bit 
>>registers 
>>- one of everything!! :-)
>>
>>This CPU is definitely capable of running uclinux. There is 
>>already a 
>>port of uclinux to the H8/300H architecture. Have a look at the 
>>following link:
>>
>>http://homepage2.nifty.com/ysato/uClinux-H8/index.en.html
>>
>>I believe it's already in CVS at uclinux.org.
>>
>>Regards,
>>
>>Scott
>>
>>Richard Klingler wrote:
>>
>>    
>>
>>>>i'm sorry for not specifing about using ucLinux for h8/300H 
>>>>        
>>>>
>>hitachi family.
>>    
>>
>>>>i've seen some web pages about the project.
>>>>
>>>>h8s and h8/300h share the same core, right? 16-bit. it is 
>>>>        
>>>>
>>possible to 
>>    
>>
>>>>run uclinux on those. further, h8/tiny is somekind of "enhanced" 
>>>>        
>>>>
>>- as 
>>    
>>
>>>>stated in their docs - h8/300h. thus running uclinux on it 
>>>>        
>>>>
>>shouldn't be 
>>    
>>
>>>>a problem...
>>>>
>>>>
>>>>        
>>>>
>>>Please read the datasheet next time (o;
>>>
>>>This LSI has an H8/300H CPU with an internal 32-bit architecture 
>>>      
>>>
>>that is upward-compatible with the H8/300CPU, and supports only 
>>normal mode, which has a 64-kbyte address space.
>>    
>>
>>>Never saw any uClinux which could fit onto 64kbytes...(o;
>>>
>>>As told before...there is no 16-bit (uC)linux version and never 
>>>      
>>>
>>will.> 
>>    
>>
>>>Rick
>>>
>>>
>>>Richard Klingler             mail: richard.klingler at violasystems.com
>>>Viola Systems Ltd.           http://www.violasystems.com/
>>>Lemmink?isenkatu 32          phon: +358 (0)201 226 226
>>>20520 Turku, Finland         mobile: +358 (0)40 748 4711
>>>_______________________________________________
>>>uClinux-dev mailing list
>>>uClinux-dev at uclinux.org
>>>http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
>>>This message was resent by uclinux-dev at uclinux.org
>>>
>>>
>>>      
>>>
>>
>>
>>    
>>
>
>
>_______________________________________________
>uClinux-dev mailing list
>uClinux-dev at uclinux.org
>http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
>This message was resent by uclinux-dev at uclinux.org
>
>  
>




From guanzhengming at tsinghua.org.cn  Wed Mar 19 02:41:28 2003
From: guanzhengming at tsinghua.org.cn (¹Ùá¿Ã÷)
Date: Wed, 19 Mar 2003 15:41:28 +0800
Subject: [uClinux-dev] about kernal and user program,need your help!
Message-ID: <200303190739.h2J7dLF22610@uclinux.org>

hi all!
I am a newbie to uclinux
I have a coldfire5272 platform which can run uclinux,my kernel is uclinux2.0.
I was puzzled by some questions for a long time.please give me some 
advises ,anyway,thanks.
the questions are following:
1.my kernel is compiled to imaged.bin,which is including linux.bin and
romfs.img.The kernel is run from flash,this is my rom.ld
MEMORY {
	/* make room for VECBASE(0x400) and STACK(0x1000) */
	ram    : ORIGIN = 0x0000400, LENGTH = 0x1000000 - 0x0400
	/* rom (flash) actually starts at 0xffe00000, but linux can co-exist
	   with the shipping product as an alternative boot mode. */
	rom : ORIGIN = 0xffc00000, LENGTH = 0x400000 
}

SECTIONS {
	
        .text :AT(_eromtext){
                _stext = . ;
                 _sdata = . ;
                __data_start = . ;
                *(.text)
                _etext = ALIGN(0x4) ;
                *(.rodata)
                *(.data)
                _edata = ALIGN(0x4) ;
        } > ram

	.bss BLOCK(0x4) : {
		_sbss = . ;
		*(.bss)
		*(COMMON)
		_ebss = ALIGN(0x4) ;
		_end = ALIGN(0x4) ;

	} > ram


        .romvec :{
                _romvec = .;
                *(.romvec)
	} > rom

	.romtext 0xffc00400:{
                _eromvec = ALIGN(0x4);
                _romtext = ALIGN(0x4);
                *(.romtext)
                _eromtext = ALIGN(0x4);
                __data_rom_start = ALIGN(0x4) ;
        } > rom

/*        .data : AT(__data_rom_start) {
                _sdata = . ;
                __data_start = . ;
                *(.rodata)
                *(.data)
                _edata = ALIGN(0x4) ;
        } > ram
*/
}
it means copy the .text and .data from flash to sdram and run.
my first question is how the romfs.img work in the memory?
does it controled by kernel ? what is the memory allocation to the romfs?
2.if i have compiled a user program.
then how the executable file is loaded into the ram?how can i guarantee
the user program doesn't crash the kernel and others user program.
the code,data,stack of the kernel and user programs,i want know all of these's
map
but how can i know?
3,i have look my user.ld.
it define MEMORY {
        flatmem : ORIGIN = 0x0, LENGTH = 0x100000
}
.text,.data,.bss,all of these are>flatmem
i am doubt,in rom.ld the{ ram    : ORIGIN = 0x0000400, LENGTH = 0x1000000 -
0x0400}
from 0x0000400,there are kernel's code and data,
and the user's code and data are placed in 0x0 ,too
aren't they crashed?
need you help,thank you very much!
                                     regards
   Jimmy




From davidm at snapgear.com  Wed Mar 19 02:43:14 2003
From: davidm at snapgear.com (David McCullough)
Date: Wed, 19 Mar 2003 17:43:14 +1000
Subject: [uClinux-dev] Big endian uClinux 2.4 for ARM7TDMI?
In-Reply-To: <029c01c2edc8$7478a160$800210ac@16.2.63.ges1>
References: <007001c2ed2a$15f48170$6367608c@ccl.itri.org.tw> <029c01c2edc8$7478a160$800210ac@16.2.63.ges1>
Message-ID: <20030319074314.GA9877@beast.internal.moreton.com.au>

Hi Guys,

If you get the latest uClinux-dist:

	http://www.uclinux.org/pub/uClinux/dist/

it has all the stuff from the ARMulator page:

	http://www.uclinux.org/pub/uClinux/utilities/armulator/

The latest tools from:

	http://www.uclinux.org/pub/uClinux/arm-elf-tools

should have all the needed big-endian support as well.  So the only
thing missing will be any SamSung bits.  from the errors below I would
say that your compiler has not be properly configured for big-endian
support, you could just try the tools mentioned above and see if they
fix it,

Cheers,
Davidm


Jivin Santosh Bhat lays it down ...
> Hi Stephan , I am able to generate the big endian code . I have sent a couple of patches to do that also (most of it from David M ) please dig through the mailing list to get the right patch and the detailed build step there , 
> Cheers
> Santosh Bat
>   ----- Original Message ----- 
>   From: StephanChiu 
>   To: uclinux-dev at uclinux.org 
>   Sent: Tuesday, March 18, 2003 2:10 PM
>   Subject: [uClinux-dev] Big endian uClinux 2.4 for ARM7TDMI?
> 
> 
>   Did anyone try the uClinux-Samsung-dist-20020927eb.tar.gz package from Mac?
>   I think the package is patched by David M's patch.
>   Dutring the kernel config, I check the "Generating Big Endian Code" option that enables the CONFIG_CPU_BIG_ENDIAN.
>   But, I failed in final step, make.
>   Did someone meet the problem or just work it out?
>   Here is my error message, Hope this helps...
>   -------------------------------------------------------
>   /opt/uClinux/arm-elf/bin/gld: _divsi3.o: compiled for a little endian system and target is big endian
>   File in wrong format: failed to merge target specific data of file /opt/uClinux/
>   lib/gcc-lib/arm-elf/2.95.3/libgcc.a(_divsi3.o)
>   /opt/uClinux/arm-elf/bin/gld: _modsi3.o: compiled for a little endian system and target is big endian
>   File in wrong format: failed to merge target specific data of file /opt/uClinux/
>   lib/gcc-lib/arm-elf/2.95.3/libgcc.a(_modsi3.o)
>   /opt/uClinux/arm-elf/bin/gld: _udivsi3.o: compiled for a little endian system and target is big endian
>   File in wrong format: failed to merge target specific data of file /opt/uClinux/
>   lib/gcc-lib/arm-elf/2.95.3/libgcc.a(_udivsi3.o)
>   /opt/uClinux/arm-elf/bin/gld: _umodsi3.o: compiled for a little endian system and target is big endian
>   File in wrong format: failed to merge target specific data of file /opt/uClinux/
>   lib/gcc-lib/arm-elf/2.95.3/libgcc.a(_umodsi3.o)
>   make[1]: *** [linux] Error 1
>   make[1]: Leaving directory `/root/20020927_eb/uClinux-dist/linux-2.4.x'
>   make: *** [linux] Error 1
>    
>   Cheers,
>   Stephan

-- 
David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
davidm at snapgear.com  Fx: +61 7 3891 3630  Custom Embedded Solutions + Security


From davidm at snapgear.com  Wed Mar 19 02:53:09 2003
From: davidm at snapgear.com (David McCullough)
Date: Wed, 19 Mar 2003 17:53:09 +1000
Subject: [uClinux-dev] uclinux-elf-tools-20030314 released
In-Reply-To: <1048047395.1088.16.camel@rhianna.tmq.com.au>
References: <20030315130050.GC14525@beast.internal.moreton.com.au> <1047969542.16340.5.camel@rhianna.tmq.com.au> <20030318115655.GB8398@beast.internal.moreton.com.au> <1048047395.1088.16.camel@rhianna.tmq.com.au>
Message-ID: <20030319075309.GC9877@beast.internal.moreton.com.au>

Jivin Justin Clacherty lays it down ...
> On Tue, 2003-03-18 at 21:56, David McCullough wrote:
> > Is there any reason your need them ?
> 
> Not really, I think I need to engage the brain before mailing to the
> list...I didn't think anything of the fact that STL was now in
> there...doh!
> 
> Now off to find out why our rather small test app is compiling to a 480k
> binary...

Ok,  this is a disadvantage of STLport.  It appears to be much bigger than
the older gcc based libs :-(

A simple hello world used to be around 110K,  now it's closer to 400K.
I suspect on a descent sized app that the difference in size will be
less.

Of course,  with STLport being much easier to work with, it should be
easy to make it an m68k shared lib.  This would reduce the cost if you
have multiple C++ apps.

I would be very interested if you can figure out why it is much bigger.
I haven't had time to see if the size can be reduced by splitting up
files into multiple .o's or some other trick,  I suspect you are pulling
in most of STLport's libstdc++ with any app :-(

Cheers,
Davidm

-- 
David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
davidm at snapgear.com  Fx: +61 7 3891 3630  Custom Embedded Solutions + Security


From justin at tmq.com.au  Wed Mar 19 02:48:00 2003
From: justin at tmq.com.au (Justin Clacherty)
Date: 19 Mar 2003 17:48:00 +1000
Subject: [uClinux-dev] trouble compiling shared libraries
Message-ID: <1048060085.1088.23.camel@rhianna.tmq.com.au>

Hi,

I'm having some trouble getting something to compile as a shared
library.  Can anyone see what I'm doing wrong?  Here is the command that
my makefile spits out along with the first few error messages.

m68k-elf-g++ -shared -fPIC -O2 -Wall -D_REENTRANT -I../../
-I/usr/local/include/ -m5307 -msep-data -D__UCLINUX__ -DTARGET -o
libserialwrapper.so SerialWrapper.o NMEASerialWrapper.o
/usr/local/m68k-elf/bin/ld.real: warning: cannot find entry symbol
_start; defaulting to
80000074
SerialWrapper.o: In function `LibSerial::SerialWrapper::Open(char const
*)':
SerialWrapper.o(.text+0xd6): undefined reference to `open'
SerialWrapper.o(.text+0xec): undefined reference to `tcgetattr'

Justin.





From hnmem at 163.com  Wed Mar 19 02:51:28 2003
From: hnmem at 163.com (hn)
Date: Wed, 19 Mar 2003 15:51:28 +0800
Subject: [uClinux-dev] Problem with uclinux-dist-20030305
Message-ID: <20030319075237.9BAEF1D63D2F3@sm212.163.com>

Hi,
Great thanks to Greg for your reply about the reboot (5307/ints.c) problem(but I missed the mail, and found the reply by searching the maillist on WEB, how could this happen! :( bug of the maillist??)
You are absolutely right: 
The only problem is that the soft reboot does not do a real hard reset of all the peripherals.

New problem report-->
the latest uclinux-dist-20030305 is tested not working for the MCF5249C3,
could not pass the IDE probe and go dead there!
..
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 50MHz system bus speed for PIO modes; override with idebus=xx
hda: probing with STATUS(0x58) instead of ALTSTATUS(0xff)
hda: IC35L040AVER07-0, ATA DISK drive
hdb: probing with STATUS(0x00) instead of ALTSTATUS(0xff)
ide0 at 50000020 on irq 0x000000a5
hda: 80418240 sectors (41174 MB) w/1916KiB Cache, CHS=79780/16/63
Partition check:
 hda: [PTBL] [5005/255/63] hda1
..

>Jivin Jay Vaughan lays it down ...
>> Out of the box, the uclinux-dist-20030305, configured plain vanilla 
>> for MCF5272 (Motorola Eval board), produces this error when compiling 
>> the threaddemos:
>...
>> Working POSIX threads on 5272 has *always* been a pain in the ass for 
>> me, as far as uClinux is concerned.  One of these days, the -dist 
>> releases will *just work* for libpthreads/m5272, but until then I'm 
>> compelled to be stupid about it and just ask you guys, since there 
>> always seem to be hidden gotchas.
>> 
>> Maybe I've just not configured something properly with this release, 
>> but what I did was a) download the tarball, b) make menuconfig to set 
>> things up exactly as I had them in my older (-20030226) uClinux 
>> system, c) 'make dep ; make' ...
>> 
>> Seems to me one of the big reasons for this release was to make 
>> libpthread available for 5272 users wanting to take advantage of the 
>> XIP fixes also done as part of the m68k-elf-tools-20030314.sh 
>> release, but alas ... threads are *still* broken, config-wise, with 
>> this -dist.
>> 
>> It would appear, anyway.  Please correct me if I'm completely missing 
>> something ...
>
>Every thing in the tree is working for pthreads,  but not all platforms
>have had it enabled (ie., we haven't tested it specifically).
>
>The reason pthreads isn't working for you is that it isn't enabled in the
>uClibc config.
>
>Here is a patch for the dist the fixes the Mot configs and also a small
>problem with the top level Makefile which is needed when you are
>switching platforms a lot ;-)
>
>make clean,  make config and force defaults, make dep, make and you
>should have a full pthreads 5272.  Then you can be the first to test it ;-)
>
>Cheers,
>Davidm
>
>-- 
>David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
>davidm at snapgear.com  Fx: +61 7 3891 3630  Custom Embedded Solutions + Security




From maillist at fsforth.de  Wed Mar 19 03:03:20 2003
From: maillist at fsforth.de (Markus Pietrek)
Date: Wed, 19 Mar 2003 09:03:20 +0100
Subject: [uClinux-dev] irattach.... is this utility available in uclinux? (for irda)
In-Reply-To: <3E77378B.5778A3F5@on-go.com>
References: <3E77378B.5778A3F5@on-go.com>
Message-ID: <200303190903.20154.maillist@fsforth.de>

Hi Thomas,

I have attached some patches for the irda-utils-0.9.15 to make them run with 
uClibc-0.9.19 and our homebrew irda dongle. Note that I have also modified 
irattach.c:dongle_list, so you would like want to take the original ones (or 
have only a look at the differences). Just overwrite the original files with 
the patches in this archive.

Assuming you have setup the kernel correctly you can follow any standard irda 
configuration (sorry I don't have a link at hand :-( ).

Hope that helps,

-- 
Markus Pietrek
FS Forth-Systeme GmbH
Phone: +49 (7667) 908 145,  FAX +49 (7667) 908 221

-------------- next part --------------
A non-text attachment was scrubbed...
Name: irda-utils-0.9.15.patch.tar.gz
Type: application/x-tgz
Size: 10455 bytes
Desc: not available
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20030319/468127c1/attachment.bin>

From maillist at fsforth.de  Wed Mar 19 03:07:40 2003
From: maillist at fsforth.de (Markus Pietrek)
Date: Wed, 19 Mar 2003 09:07:40 +0100
Subject: [uClinux-dev] Mounting root fs as NFS
In-Reply-To: <3E775581.867.1ECA4E4@localhost>
References: <3E775581.867.1ECA4E4@localhost>
Message-ID: <200303190907.40689.maillist@fsforth.de>

Hi Stefano,

> we're successfully using the latest uClinux distribution on a
> Coldafire-based board. To speed up development, I was trying to
> enable NFS-mounted root fs, and it seems to work. Now I need to
> understand if creating a real rootfs directories tree can be
> performed by the same Makefile that builds the Kernel+Apps system. As

My toplevel Makefile is able to create a rootfs suitable for nfsroot and 
CRAMFS, so I think romfs should be possible, too.

Process like this

o build kernel
o build apps
o copy kernel, apps and configuration files to /exports/nfsroot like you want 
to have them placed
o build the cramfs with /exports/nfsroot as base
o configure the kernel to take either host:/exports/nfsroot or cramfs as root
o export /exports/nfsroot for NFS

> anything similar already exist for directly building a ready-to-be-
> mounted root fs (with /dev properly built etc.) or should I do this
> manually?

Try to use devfs, it makes life easier.

Bye,

-- 
Markus Pietrek
FS Forth-Systeme GmbH
Phone: +49 (7667) 908 145,  FAX +49 (7667) 908 221




From maillist at fsforth.de  Wed Mar 19 03:10:32 2003
From: maillist at fsforth.de (Markus Pietrek)
Date: Wed, 19 Mar 2003 09:10:32 +0100
Subject: [uClinux-dev] Interactive Telnet Script
In-Reply-To: <39FC60B5F73B7A4095083E853E9878350A0A04@ip-fm1.intrapower.com.au>
References: <39FC60B5F73B7A4095083E853E9878350A0A04@ip-fm1.intrapower.com.au>
Message-ID: <200303190910.32597.maillist@fsforth.de>

On Wednesday 19 March 2003 03:20, Ryan Crouch wrote:
> Hello all,
> I need to automate a telnet session via a script of some sort in order
> to control a router device plugged into the uClinux machine. Has anyone
> successfully created an interactive telnet script using chat/expect or
> anything similar?

Of course. "man expect" will print you a lot of hints under the section "SEE 
ALSO"

I have attached you an example that I used to download a kernel image into my 
targets RAM with a BDI2000 box. The script worked most times.

Bye,

-- 
Markus Pietrek
FS Forth-Systeme GmbH
Phone: +49 (7667) 908 145,  FAX +49 (7667) 908 221

-------------- next part --------------
A non-text attachment was scrubbed...
Name: run_bdi.tcl
Type: text/x-tcl
Size: 541 bytes
Desc: not available
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20030319/3ceab28b/attachment.tcl>

From jv at access-music.de  Wed Mar 19 03:56:16 2003
From: jv at access-music.de (Jay Vaughan)
Date: Wed, 19 Mar 2003 09:56:16 +0100
Subject: [uClinux-dev] A fool question:what directory is the root of
 the kernel tree
In-Reply-To: <002401c2edde$16d4c280$542289c0@LocalHost>
References: <002401c2edde$16d4c280$542289c0@LocalHost>
Message-ID: <a05111b11ba9de06e82d0@[10.0.1.240]>

>       Can anyone help me?
>       Thank you very much!


Assuming you're using /opt/uClinux-dist/, it'll be:

/opt/uClinux-dist/linux-2.4.x/

or:

/opt/uClinux-dist/linux-2.0.x/

You may have a symbolic link from /opt/uClinux-dist/linux -> either 
one of these, I don't know ... seems like in some vendor-supplied 
distributions, this link is made for localized tweaks... though on 
this point, I am not certain.

-- 

;

Jay Vaughan
r&d>>music:technology:synthesizers - www.access-music.de/


From jv at access-music.de  Wed Mar 19 04:10:06 2003
From: jv at access-music.de (Jay Vaughan)
Date: Wed, 19 Mar 2003 10:10:06 +0100
Subject: [uClinux-dev] Problem with uclinux-dist-20030305
In-Reply-To: <20030318233928.GA3203@beast.internal.moreton.com.au>
References: <a05111b00ba9cf22d31ca@[10.0.1.240]>
 <20030318233928.GA3203@beast.internal.moreton.com.au>
Message-ID: <a05111b12ba9de209e319@[10.0.1.240]>

>Every thing in the tree is working for pthreads,  but not all platforms
>have had it enabled (ie., we haven't tested it specifically).
>

Ah, I see.  Please consider me an avid test-target for the 5272 
platform, then.  I'm using these eval boards as general purpose lab 
tools, so I like to stay current with things, and for me portability 
is key...

>Here is a patch for the dist the fixes the Mot configs and also a small
>problem with the top level Makefile which is needed when you are
>switching platforms a lot ;-)
>

Thanks very much!!

Incidentally, this patch arrived garbled.  Is it normal to have so 
many "^M"'s in your patch files - I thought these were just 
stock-standard plaintext files, usually?  I ran 'dos2unix -c Mac' on 
it, seemed to fix it, but not everyone has this ...

>make clean,  make config and force defaults, make dep, make and you
>should have a full pthreads 5272.  Then you can be the first to test it ;-)

Please consider me first in line for any future 5272-related testing 
of stuff that will make uClinux-dist better organized for everyone!

-- 

;

Jay Vaughan
r&d>>music:technology:synthesizers - www.access-music.de/


From mg.sivam at gdatech.co.in  Wed Mar 19 04:10:13 2003
From: mg.sivam at gdatech.co.in (sivam)
Date: Wed, 19 Mar 2003 14:40:13 +0530
Subject: [uClinux-dev] Bootloader for 5249C3....
References: <1048060085.1088.23.camel@rhianna.tmq.com.au>
Message-ID: <002901c2edf7$5ad70060$929858ca@gdaserver>

Hello All,

Can anyone please provide me a sample bootloader for my Coldfire 5249 chip
?.  Is it possible for me to use the ARM GDB to debug the same ?. Please
help me on this regard.

Thanks and Regards
sivam


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.462 / Virus Database: 261 - Release Date: 3/13/2003




From rgegusch at mf.tu-berlin.de  Wed Mar 19 04:40:56 2003
From: rgegusch at mf.tu-berlin.de (Rene Gegusch)
Date: Wed, 19 Mar 2003 10:40:56 +0100
Subject: [uClinux-dev] FTP Server on the 5272 board
In-Reply-To: <3E76697E.1060507@snapgear.com>
References: <BC03D160581F7A4E92710FC238282411167809@ici-mail.intellicom.se> <200303171030.16441.rgegusch@mf.tu-berlin.de> <3E76697E.1060507@snapgear.com>
Message-ID: <200303191040.56583.rgegusch@mf.tu-berlin.de>

Thanks for you help, but look at this new error :(

fec.c:97: parse error before character 0240
fec.c: In function `fec_enet_mii':
fec.c:672: `fec_hwp' undeclared (first use in this function)
fec.c:672: (Each undeclared identifier is reported only once
fec.c:672: for each function it appears in.)
fec.c:667: warning: `ep' might be used uninitialized in this function
fec.c: In function `mii_queue':
fec.c:719: `fec_hwp' undeclared (first use in this function)
fec.c: In function `mii_discover_phy':
fec.c:1394: `fec_hwp' undeclared (first use in this function)
fec.c:1390: warning: `fecp' might be used uninitialized in this function
fec.c: In function `set_multicast_list':
fec.c:1490: `fec_hwp' undeclared (first use in this function)
fec.c:1484: warning: `ep' might be used uninitialized in this function
fec.c: In function `fec_set_mac_address':
fec.c:1558: `fec_hwp' undeclared (first use in this function)
fec.c:1571: `my_enet_addr' undeclared (first use in this function)
fec.c: In function `fec_enet_init':
fec.c:1632: `fec_hwp' undeclared (first use in this function)
fec.c:1653: `my_enet_addr' undeclared (first use in this function)
fec.c:1677: `fec_hwaddr' undeclared (first use in this function)
fec.c:1591: warning: `fecp' might be used uninitialized in this function
fec.c:1592: warning: `eap' might be used uninitialized in this function
fec.c: In function `fec_restart':
fec.c:1914: `fec_hwp' undeclared (first use in this function)
fec.c:1938: `my_enet_addr' undeclared (first use in this function)
fec.c:1909: warning: `eap' might be used uninitialized in this function
fec.c:1911: warning: `fecp' might be used uninitialized in this function
fec.c: In function `fec_stop':
fec.c:2042: `fec_hwp' undeclared (first use in this function)
fec.c:2039: warning: `fecp' might be used uninitialized in this function
make[4]: *** [fec.o] Fehler 1
make[4]: Verlassen des Verzeichnisses Verzeichnis 
?/home/rgegusch/test/coldfire/uClinux-dist-patched/linux-2.4.x/drivers/net?
make[3]: *** [first_rule] Fehler 2
make[3]: Verlassen des Verzeichnisses Verzeichnis 
?/home/rgegusch/test/coldfire/uClinux-dist-patched/linux-2.4.x/drivers/net?
make[2]: *** [_subdir_net] Fehler 2
make[2]: Verlassen des Verzeichnisses Verzeichnis 
?/home/rgegusch/test/coldfire/uClinux-dist-patched/linux-2.4.x/drivers?
make[1]: *** [_dir_drivers] Fehler 2
make[1]: Verlassen des Verzeichnisses Verzeichnis 
?/home/rgegusch/test/coldfire/uClinux-dist-patched/linux-2.4.x?
make: *** [linux] Fehler 1

By the way, it is important to use my uC5272 in a network. I don't really know 
what you were meaning with the hard coded MAC adress, but if it works with 
one unit in a network, this might be OK.


Am Dienstag, 18. M?rz 2003 01:34 schrieb Greg Ungerer:
> Hi Rene,
>
> Rene Gegusch wrote:
> > make dep went on without any errors, but make gave me this error:
> > m68k-elf-gcc -fno-builtin -nostdinc -D__KERNEL__
> > -I/home/rgegusch/test/coldfire/uClinux-dist-patched/linux-2.4.x/include
> > -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing
> > -fno-common -fomit-frame-pointer
> > -I/usr/local/lib/gcc-lib/m68k-elf/2.95.3/./include -pipe -DNO_MM -DNO_FPU
> > -m5307 -Wa,-S -Wa,-m5307 -D__ELF__ -DMAGIC_ROM_PTR
> > -DUTS_SYSNAME="uClinux" -D__linux__ -O1   -nostdinc -iwithprefix include
> > -DKBUILD_BASENAME=fec  -c -o fec.o fec.c
> > fec.c: In function `fec_enet_init':
> > fec.c:1676: `fec_hwaddr' undeclared (first use in this function)
> > fec.c:1676: (Each undeclared identifier is reported only once
> > fec.c:1676: for each function it appears in.)
>
> OK, this looks like a real bug in the current fec.c driver.
>
> Change lines 96-104 to be:
>
>      #if defined(CONFIG_BOARD_UC5272)
>      unsigned char    fec_hwaddr[6] = { 0x00, 0xd0, 0xcf, 0x00, 0x00,
> 0x72 };
>      #elif defined(CONFIG_M5272)
>      static volatile fec_t   *fec_hwp = (volatile fec_t *) (MCF_MBAR +
> 0x840);
>      static ushort           my_enet_addr[] = { 0x00d0, 0xcf00, 0x0072 };
>      #else
>      static volatile fec_t   *fec_hwp = &(((immap_t
> *)IMAP_ADDR)->im_cpm.cp_fec)
>      static ushort           my_enet_addr[3];
>      #endif /* CONFIG_M5272 */
>
> This is probably not exactly what Arcturus intended here, since
> it is hard coding the MAC address. But it should get you compiling,
> and it will work on a single unit.
>
> Regards
> Greg
>
>
> ------------------------------------------------------------------------
> Greg Ungerer  --  Chief Software Wizard        EMAIL:  gerg at snapgear.com
> SnapGear Pty Ltd                               PHONE:    +61 7 3435 2888
> 825 Stanley St,                                  FAX:    +61 7 3891 3630
> Woolloongabba, QLD, 4102, Australia              WEB:   www.SnapGear.com
>
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org




From rgegusch at mf.tu-berlin.de  Wed Mar 19 05:03:01 2003
From: rgegusch at mf.tu-berlin.de (Rene Gegusch)
Date: Wed, 19 Mar 2003 11:03:01 +0100
Subject: [uClinux-dev] FTP Server on the 5272 board
In-Reply-To: <3E76697E.1060507@snapgear.com>
References: <BC03D160581F7A4E92710FC238282411167809@ici-mail.intellicom.se> <200303171030.16441.rgegusch@mf.tu-berlin.de> <3E76697E.1060507@snapgear.com>
Message-ID: <200303191103.01514.rgegusch@mf.tu-berlin.de>

I tried to add the definition of fec_hwp to the uC5272 define part in line 97 
(fec.c) by copying the first definition of the M5272 into it.
	//Adding to avoid error of missing declaration of fec_hwp
	static volatile fec_t *fec_hwp = (volatile fec_t *) (MCF_MBAR + 0x840);

This time there was following error:
fec.c: In function `fec_set_mac_address':
fec.c:1572: `my_enet_addr' undeclared (first use in this function)
fec.c:1572: (Each undeclared identifier is reported only once
fec.c:1572: for each function it appears in.)
fec.c: In function `fec_enet_init':
fec.c:1654: `my_enet_addr' undeclared (first use in this function)
fec.c:1593: warning: `eap' might be used uninitialized in this function
fec.c: In function `fec_restart':
fec.c:1939: `my_enet_addr' undeclared (first use in this function)
fec.c:1910: warning: `eap' might be used uninitialized in this function
make[4]: *** [fec.o] Fehler 1

Looks like there are now all other variables missing, declarded under M5272, 
but not in uC5272... :(
I would like to add those easily into it, but because I do not really know for 
what they are it would be only poor hacking. I didn't really wanted to do 
this!

this is what I finally add in line 98:
	//Adding to avoid error of missing declaration of fec_hwp and my_enet_hddr[3]
	static volatile fec_t *fec_hwp = (volatile fec_t *) (MCF_MBAR + 0x840);
	static ushort my_enet_addr[3];

fec.c compiled now with no errors, but another module didn't accepted my 
hackings... (what a surprise)
Take a look at this:

In file included from uCcs8900.c:69:
/home/rgegusch/test/coldfire/uClinux-dist-patched/linux-2.4.x/include/linux/malloc.h:4: 
warning: #warning linux/malloc.h is deprecated, use linux/slab.h instead.
uCcs8900.c:318: #error MAC address is not defined
uCcs8900.c:111: warning: `cs8900_irq_map' defined but not used
uCcs8900.c:652: warning: `cs8900_interrupt' defined but not used
make[4]: *** [uCcs8900.o] Fehler 1


Regards,
Rene


Am Dienstag, 18. M?rz 2003 01:34 schrieb Greg Ungerer:
> Hi Rene,
>
> Rene Gegusch wrote:
> > make dep went on without any errors, but make gave me this error:
> > m68k-elf-gcc -fno-builtin -nostdinc -D__KERNEL__
> > -I/home/rgegusch/test/coldfire/uClinux-dist-patched/linux-2.4.x/include
> > -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing
> > -fno-common -fomit-frame-pointer
> > -I/usr/local/lib/gcc-lib/m68k-elf/2.95.3/./include -pipe -DNO_MM -DNO_FPU
> > -m5307 -Wa,-S -Wa,-m5307 -D__ELF__ -DMAGIC_ROM_PTR
> > -DUTS_SYSNAME="uClinux" -D__linux__ -O1   -nostdinc -iwithprefix include
> > -DKBUILD_BASENAME=fec  -c -o fec.o fec.c
> > fec.c: In function `fec_enet_init':
> > fec.c:1676: `fec_hwaddr' undeclared (first use in this function)
> > fec.c:1676: (Each undeclared identifier is reported only once
> > fec.c:1676: for each function it appears in.)
>
> OK, this looks like a real bug in the current fec.c driver.
>
> Change lines 96-104 to be:
>
>      #if defined(CONFIG_BOARD_UC5272)
>      unsigned char    fec_hwaddr[6] = { 0x00, 0xd0, 0xcf, 0x00, 0x00,
> 0x72 };
>      #elif defined(CONFIG_M5272)
>      static volatile fec_t   *fec_hwp = (volatile fec_t *) (MCF_MBAR +
> 0x840);
>      static ushort           my_enet_addr[] = { 0x00d0, 0xcf00, 0x0072 };
>      #else
>      static volatile fec_t   *fec_hwp = &(((immap_t
> *)IMAP_ADDR)->im_cpm.cp_fec)
>      static ushort           my_enet_addr[3];
>      #endif /* CONFIG_M5272 */
>
> This is probably not exactly what Arcturus intended here, since
> it is hard coding the MAC address. But it should get you compiling,
> and it will work on a single unit.
>
> Regards
> Greg
>
>
> ------------------------------------------------------------------------
> Greg Ungerer  --  Chief Software Wizard        EMAIL:  gerg at snapgear.com
> SnapGear Pty Ltd                               PHONE:    +61 7 3435 2888
> 825 Stanley St,                                  FAX:    +61 7 3891 3630
> Woolloongabba, QLD, 4102, Australia              WEB:   www.SnapGear.com
>
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org




From masterkristof at yahoo.com  Wed Mar 19 05:48:21 2003
From: masterkristof at yahoo.com (Kristof Bruyninckx)
Date: Wed, 19 Mar 2003 02:48:21 -0800 (PST)
Subject: [uClinux-dev] Fwd: ISO9660 compiling error
Message-ID: <20030319104821.5621.qmail@web11005.mail.yahoo.com>


Note: forwarded message attached.


__________________________________________________
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com
-------------- next part --------------
An embedded message was scrubbed...
From: Kristof Bruyninckx <masterkristof at yahoo.com>
Subject: ISO9660 compiling error
Date: Wed, 19 Mar 2003 01:45:17 -0800 (PST)
Size: 5675
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20030319/98df01f7/attachment.mht>

From rgegusch at mf.tu-berlin.de  Wed Mar 19 04:46:58 2003
From: rgegusch at mf.tu-berlin.de (Rene Gegusch)
Date: Wed, 19 Mar 2003 10:46:58 +0100
Subject: [uClinux-dev] dist 20030305 doesn't build for Arcturus uC5272
In-Reply-To: <3E777F83.15773.24BAC4D1@localhost>
References: <1047933579.1287.54.camel@troca> <3E777F83.15773.24BAC4D1@localhost>
Message-ID: <200303191046.58384.rgegusch@mf.tu-berlin.de>

Hi Brad,

I am still trying to build a kernel for my uC5272 board and still get new 
problems. Seems to be a hard work. My first intention is to get a ftp-server 
for the system and was really happy surprised to see, that there is one 
included in the 030305 distribution... until I realized, that it is a hard 
way to compile it.
First of all, I got the same error like you, then tried to add the ftpd to my 
Arcturus distribution - failed. Maybe you check out and can give me your 
ideas to it.
Finally I am working now with help of Greg patching the distribution for the 
uC5272 board. I also already gave the missing files to the CVS, which 
Arcturus forget to do...
Would be great if you will join us to patch or better hack the distribution 
for the uC5272 :)

Rene



Am Mittwoch, 19. M?rz 2003 02:34 schrieb Brad Clements:
> Before diving in to "fix" I just want to confirm that no one else has tried
> and succeeded building a basic kernel for the Arcturus uC5272
>
> I selected the board, and left all other settings as defaults. Make dep;
> make and get this:
>
> make[2]: Entering directory
> `/var/local/src/uClinux-dist/linux-2.4.x/arch/m68knommu/platform/5272'
> make[2]: *** No rule to make target `/crt0_ram.S', needed by `/crt0_ram.o'.
>  Stop. make[2]: Leaving directory
> `/var/local/src/uClinux-dist/linux-2.4.x/arch/m68knommu/platform/5272'
> make[1]: *** [_dir_arch/m68knommu/platform/5272] Error 2
> make[1]: Leaving directory `/var/local/src/uClinux-dist/linux-2.4.x'
> make: *** [linux] Error 1
>
>
>
> The Arcturus uC5272 didn't work with previous dists either, probably
> because they just hadn't submitted the necessary patches.
>
> I just wanted to see if anyone else had this problem before I "dive in".
>
> I see other 5272 users on the list using this dist, so .. maybe it's just
> my luck.
>
> --  here's some things I've tried tinkering with tonight before sending
> this, based on my previously "working" dist (feb 2002 that came with
> Arcturus CD)
>
> Snooping linux-2.4.x/arch/Boards.mk, I see I had this in my previous dist
>
> #ifdef CONFIG_M5272
> <snip>
>
> ifdef CONFIG_BOARD_UC5272
> BOARD := uC5272
> endif
>
> I also see I that in my "working" dist I have a
>
> uClinux-coldfire/linux-2.4.x/arch/m68knommu/platform/5272/uC5272
>
> With the necessary files:
>
> total 40
> drwxr-xr-x    2 bkc      bkc          4096 Jan 29 10:15 ./
> drwxr-xr-x    5 bkc      bkc          4096 Jan 29 10:15 ../
> -rw-rw-r--    1 bkc      bkc          1812 Jan 29 10:15 crt0_ram.o
> -rw-r--r--    1 bkc      bkc          3882 Mar 26  2002 crt0_ram.S
> -rw-r--r--    1 bkc      bkc          3158 Mar 26  2002 crt0_rom.S
> -rw-r--r--    1 bkc      bkc          4615 Mar 26  2002 .gdbinit
> -rw-r--r--    1 bkc      bkc          1569 Oct 31 14:59 ram.ld
> -rw-r--r--    1 bkc      bkc            22 Jan 30 18:30 romfs.default.ld
> -rw-r--r--    1 bkc      bkc            22 Jan 30 18:30 romfs.ld
>
>
> Guess I'll copy these..
>
> also need to edit config.in and add
>
>         bool 'Arcturus Networks uC5272 dimm board support'
> CONFIG_BOARD_UC5272
>
> added this to vendors/Arcturus/uC5272/config.linux-2.4.x
>
> CONFIG_BOARD_UC5272=y
>
>
> Now this is starting to smell bad. I'm beginning to think that my previous
> "fix" for this wasn't correct.
>
> After all this, BOARDS still isn't being set correctly. :-(




From masterkristof at yahoo.com  Wed Mar 19 04:45:17 2003
From: masterkristof at yahoo.com (Kristof Bruyninckx)
Date: Wed, 19 Mar 2003 01:45:17 -0800 (PST)
Subject: [uClinux-dev] ISO9660 compiling error
Message-ID: <20030319094517.87481.qmail@web11002.mail.yahoo.com>

Hi,

when I compile my uClinux kernel 2.4.x and include
CDROM support and in the filesystem ISO9660 support
then I'm always getting the following error.(see
attachement). Does anybody know how to solve this
error??

yours truly and hoping or a reply,

kristof

__________________________________________________
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2.4.xerror
Type: application/octet-stream
Size: 3287 bytes
Desc: 2.4.xerror
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20030319/a8cd59e6/attachment.obj>

From rgegusch at mf.tu-berlin.de  Wed Mar 19 05:16:41 2003
From: rgegusch at mf.tu-berlin.de (Rene Gegusch)
Date: Wed, 19 Mar 2003 11:16:41 +0100
Subject: [uClinux-dev] irattach.... is this utility available in uclinux? (for irda)
In-Reply-To: <200303190903.20154.maillist@fsforth.de>
References: <3E77378B.5778A3F5@on-go.com> <200303190903.20154.maillist@fsforth.de>
Message-ID: <200303191116.41013.rgegusch@mf.tu-berlin.de>

What kind of selfmade dongle do you have?
Are you also able to communicate via IrComm ?
This was one of my past intentions - I finally stopped the work, even I 
managed to add the IrComm protocoll in my kernel. The final problem was, that 
I would had needed a fork command that isn't available in this way on a 
noemmu system...
Finally I took an active dongle from Actisys and communicate via a standard 
3-wire serial interface. Works fine, but was expensive (if you don't compare 
the time you waste for patching/hacking)
I am unsing the uC5272 board


Am Mittwoch, 19. M?rz 2003 09:03 schrieb Markus Pietrek:
> Hi Thomas,
>
> I have attached some patches for the irda-utils-0.9.15 to make them run
> with uClibc-0.9.19 and our homebrew irda dongle. Note that I have also
> modified irattach.c:dongle_list, so you would like want to take the
> original ones (or have only a look at the differences). Just overwrite the
> original files with the patches in this archive.
>
> Assuming you have setup the kernel correctly you can follow any standard
> irda configuration (sorry I don't have a link at hand :-( ).
>
> Hope that helps,




From yangyajun at hisense.cngb.com  Wed Mar 19 04:49:55 2003
From: yangyajun at hisense.cngb.com (=?gb2312?B?0e7Rx778?=)
Date: Wed, 19 Mar 2003 17:49:55 +0800
Subject: [uClinux-dev] How to confirm the mtd device has been added successfully? I need your help!
Message-ID: <007001c2edfc$e85f33d0$542289c0@LocalHost>

    I want to support jffs on my 5272 board.  I use mtd and create two partitons. But I can't mount it successfully.  I guess that the mtd device have not benn added successfully. So I go to /proc and find that in /proc/devices, there is no mtd device's info.  In /proc/mtd ,there are two mtd devices---two partitions's info.

    Have my mtd devices been added successfully?

I need your help!

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20030319/cd030003/attachment.html>

From rgegusch at mf.tu-berlin.de  Wed Mar 19 05:28:29 2003
From: rgegusch at mf.tu-berlin.de (Rene Gegusch)
Date: Wed, 19 Mar 2003 11:28:29 +0100
Subject: [uClinux-dev] irattach.... is this utility available in uclinux? (for irda)
In-Reply-To: <200303190903.20154.maillist@fsforth.de>
References: <3E77378B.5778A3F5@on-go.com> <200303190903.20154.maillist@fsforth.de>
Message-ID: <200303191128.29713.rgegusch@mf.tu-berlin.de>

Hi Markus,

I am really interessted which board you are using.
I forget to mention, that we had to realize, that our serial port is actually 
just a 3 wire (RX,TX,GND) version, so not a complete serial port with all 9 
wires and so all controll signals. Unfortunally we had would had to add those 
signals via parallel ports to use a standard passiv dongle like the Actisys 
L220+ to use on the uC5272.

Rene
TU Berlin

Am Mittwoch, 19. M?rz 2003 09:03 schrieb Markus Pietrek:
> Hi Thomas,
>
> I have attached some patches for the irda-utils-0.9.15 to make them run
> with uClibc-0.9.19 and our homebrew irda dongle. Note that I have also
> modified irattach.c:dongle_list, so you would like want to take the
> original ones (or have only a look at the differences). Just overwrite the
> original files with the patches in this archive.
>
> Assuming you have setup the kernel correctly you can follow any standard
> irda configuration (sorry I don't have a link at hand :-( ).
>
> Hope that helps,




From frederic.dubois at synchronic.fr  Wed Mar 19 03:32:33 2003
From: frederic.dubois at synchronic.fr (=?iso-8859-1?Q?Fr=E9deric_DUBOIS?=)
Date: Wed, 19 Mar 2003 09:32:33 +0100
Subject: [uClinux-dev] about nommu or mmu
Message-ID: <1132153BE85ED411B37A0000B4A7D87DCD5D@SERVEUR21>


> -----Message d'origine-----
> De : John Williams [mailto:jwilliams at itee.uq.edu.au]
> Envoy? : mer. 19 mars 2003 06:45
> ? : uclinux-dev at uclinux.org
> Objet : Re: [uClinux-dev] about nommu or mmu
> 
> 
> ChangDa Tong wrote:
> 
> > I mean if more and more cpu used in the embedded device have a mmu,
> > could uclinux have less usage? Could the nommu cpu's is 
> used less in the
> > near future? Maybe this affect  the spreadness of uclinux. 
> Could anyone
> > show some facts that nommu processor is hard to be repleace 
> the nommu
> > ones?

Maybe we could add on to the credit of nommu chips, easier to program - at
least compared with what I've seen from Intel's.

> 
> An interesting question, which could be subtitled "The future 
> of uClinux".
> 
> To get the ball rolling, you might speculate that uClinux 
> will just go 
> deeper and deeper embedded.  At the coal face it will always be the 
> struggle of getting the necessary performance from the 
> cheapest piece of 
> hardware that will do the job.
> 
> When the processors used in a network router (like SnapGear's 
> stuff) can 
> "afford" an MMU, then they would probably upgrade to regular linux.
> 
> However, by that time, even smaller, cheaper and faster no-mmu 
> processors will exist, and they will be embedded in your 
> internet-ready 
> toaster.  Then, by the time the toaster manufacturer upgrades 
> to proper 
> linux, maybe you'll run uClinux in your internet enabled 
> wrist watch, or 
> the microchip embedded in your skull that reminds you to take out the 
> garbage and feed the cat.  I can see it now, tattoos reading "uClinux 
> inside"!
> 

My cat is already featured with a built-in reminder. When he is hungry he
says: Meew!

> Of course I'm being a bit silly, but the "ubiquitous computing" folks 
> will need an OS, and uClinux might well be it.
> 
> Remember that in the early days IBM (or so the story goes) 
> predicted the 
> global market for "computers" as being upper bounded somewhere around 
> 10.  Oh, and Bill Gates said no-one would ever need more than 
> 640K of RAM.
> 

Well, 20 years ago people were doing things different than today - and for
these things even 64K was enough. There were no GUI, few backward
compatibility requirements, etc. and it happens to be to some extend the
same situation for embedded devices.
In our embedded world there are many kernels which fit into a bunch of
Kilobytes and do their job without mmu, and this is perfect for small, low
cost embedded devices.
Motorola and co. are marketing processors at mid range between
microcontroler and microprocessor and it seems that uClinux is one of the OS
able to fully operate them.

> Cheers,
> 
> John
> 


From rgegusch at mf.tu-berlin.de  Wed Mar 19 07:28:42 2003
From: rgegusch at mf.tu-berlin.de (Rene Gegusch)
Date: Wed, 19 Mar 2003 13:28:42 +0100
Subject: [uClinux-dev] dist 20030305 doesn't build for Arcturus uC5272
In-Reply-To: <3E777F83.15773.24BAC4D1@localhost>
References: <1047933579.1287.54.camel@troca> <3E777F83.15773.24BAC4D1@localhost>
Message-ID: <200303191328.42912.rgegusch@mf.tu-berlin.de>

OK, my work went on...

after I edited fec.c and it compiled without errors I got this error message 
regarding missing MAC adress.
I wondered a little bit around, because in line 302 of uCcs8900.c there is 
this comment:
/* dev->dev_addr[0] through dev->dev_addr[6] holds the mac address
this array contains 7 fields???
however, I "hard encoded" my 6 hex-digit MAC adress of my uC5272 into this 
array from [0]..[5]. So what about [6]? Didn't care about it.
By the way:
Everyone who ask for his MAC adress of his uC5272:
on my board there is a sticker on the CPU with both MAC adresses. I believe 
the first one is for the 100MBit port. If someone has further details let me 
know.

So, uCcs8900.c looks from line 312 on like this:
#elif defined (CONFIG_BOARD_UCLINKII) || \
      defined (CONFIG_BOARD_EVS3C4530LII) || \
      defined (CONFIG_BOARD_EVS3C4530HEI)
      memcpy(dev->dev_addr, get_MAC_address("dev1"), 6);
#elif defined (CONFIG_BOARD_UC5272)
	//hard encoded MAC address
	dev->dev_addr[0] = 0x00;
	dev->dev_addr[1] = 0x06;
	dev->dev_addr[2] = 0x3B;
	dev->dev_addr[3] = 0x00;
	dev->dev_addr[4] = 0x03;
	dev->dev_addr[5] = 0x85;
#else
#error	    MAC address is not defined
#endif

Compiling seems to work fine now, for a few second, till the next problem. :(
now I get this error message:

/tmp/ccsdN6uK.s: Assembler messages:
/tmp/ccsdN6uK.s:246: Error: invalid instruction for this architecture; needs 
68000 or higher -- statement `oriw #0x2700,%sp@' ignored
make[2]: *** [himemloader.o] Fehler 1

this is a little bit overhead for me... so, does anyone has an idea how to fix 
this?



Am Mittwoch, 19. M?rz 2003 02:34 schrieb Brad Clements:
> Before diving in to "fix" I just want to confirm that no one else has tried
> and succeeded building a basic kernel for the Arcturus uC5272
>
> I selected the board, and left all other settings as defaults. Make dep;
> make and get this:
>
> make[2]: Entering directory
> `/var/local/src/uClinux-dist/linux-2.4.x/arch/m68knommu/platform/5272'
> make[2]: *** No rule to make target `/crt0_ram.S', needed by `/crt0_ram.o'.
>  Stop. make[2]: Leaving directory
> `/var/local/src/uClinux-dist/linux-2.4.x/arch/m68knommu/platform/5272'
> make[1]: *** [_dir_arch/m68knommu/platform/5272] Error 2
> make[1]: Leaving directory `/var/local/src/uClinux-dist/linux-2.4.x'
> make: *** [linux] Error 1
>
>
>
> The Arcturus uC5272 didn't work with previous dists either, probably
> because they just hadn't submitted the necessary patches.
>
> I just wanted to see if anyone else had this problem before I "dive in".
>
> I see other 5272 users on the list using this dist, so .. maybe it's just
> my luck.
>
> --  here's some things I've tried tinkering with tonight before sending
> this, based on my previously "working" dist (feb 2002 that came with
> Arcturus CD)
>
> Snooping linux-2.4.x/arch/Boards.mk, I see I had this in my previous dist
>
> #ifdef CONFIG_M5272
> <snip>
>
> ifdef CONFIG_BOARD_UC5272
> BOARD := uC5272
> endif
>
> I also see I that in my "working" dist I have a
>
> uClinux-coldfire/linux-2.4.x/arch/m68knommu/platform/5272/uC5272
>
> With the necessary files:
>
> total 40
> drwxr-xr-x    2 bkc      bkc          4096 Jan 29 10:15 ./
> drwxr-xr-x    5 bkc      bkc          4096 Jan 29 10:15 ../
> -rw-rw-r--    1 bkc      bkc          1812 Jan 29 10:15 crt0_ram.o
> -rw-r--r--    1 bkc      bkc          3882 Mar 26  2002 crt0_ram.S
> -rw-r--r--    1 bkc      bkc          3158 Mar 26  2002 crt0_rom.S
> -rw-r--r--    1 bkc      bkc          4615 Mar 26  2002 .gdbinit
> -rw-r--r--    1 bkc      bkc          1569 Oct 31 14:59 ram.ld
> -rw-r--r--    1 bkc      bkc            22 Jan 30 18:30 romfs.default.ld
> -rw-r--r--    1 bkc      bkc            22 Jan 30 18:30 romfs.ld
>
>
> Guess I'll copy these..
>
> also need to edit config.in and add
>
>         bool 'Arcturus Networks uC5272 dimm board support'
> CONFIG_BOARD_UC5272
>
> added this to vendors/Arcturus/uC5272/config.linux-2.4.x
>
> CONFIG_BOARD_UC5272=y
>
>
> Now this is starting to smell bad. I'm beginning to think that my previous
> "fix" for this wasn't correct.
>
> After all this, BOARDS still isn't being set correctly. :-(




From stefano.costa at bluewind.it  Wed Mar 19 07:30:14 2003
From: stefano.costa at bluewind.it (Stefano Costa)
Date: Wed, 19 Mar 2003 13:30:14 +0100
Subject: [uClinux-dev] Re: Mounting root fs as NFS
In-Reply-To: <20030319101423.25397.68349.Mailman@geekcreek.net>
Message-ID: <3E7870E6.30943.1001F8F@localhost>

On 19 Mar 2003 at 5:14, Markus Pietrek wrote:

> From: Markus Pietrek <maillist at fsforth.de>
> To: uclinux-dev at uclinux.org
> Subject: Re: [uClinux-dev] Mounting root fs as NFS
> Date: Wed, 19 Mar 2003 09:07:40 +0100
> Reply-To: uclinux-dev at uclinux.org
> 
> Hi Stefano,
> 
> > we're successfully using the latest uClinux distri