From miles at lsi.nec.co.jp  Mon Apr  1 01:56:45 2002
From: miles at lsi.nec.co.jp (Miles Bader)
Date: 01 Apr 2002 15:56:45 +0900
Subject: [uClinux-dev] Re: patch to add v850 support to busybox insmod
In-Reply-To: <3CA11E06.8040705@snapgear.com>
References: <buoy9gflv82.fsf@mcspd15.ucom.lsi.nec.co.jp>
	<3CA11E06.8040705@snapgear.com>
Message-ID: <buoelhz7vpu.fsf@mcspd15.ucom.lsi.nec.co.jp>

Greg Ungerer <gerg at snapgear.com> writes:
> Rolled into the uClinux-dist code.

Thanks!

Could you also apply this patch, which makes module parameters work:


-------------- next part --------------
A non-text attachment was scrubbed...
Name: busybox-insmod-v850-parms.patch
Type: text/x-patch
Size: 884 bytes
Desc: patch to make busybox insmod params work on the v850
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20020401/eab94809/attachment.patch>
-------------- next part --------------


-Miles
-- 
Fast, small, soon; pick any 2.

From andersen at codepoet.org  Mon Apr  1 02:32:39 2002
From: andersen at codepoet.org (Erik Andersen)
Date: Mon, 1 Apr 2002 00:32:39 -0700
Subject: [uClinux-dev] Re: [BusyBox] patch to add v850 support to busybox insmod
In-Reply-To: <buoy9gflv82.fsf@mcspd15.ucom.lsi.nec.co.jp>
References: <buoy9gflv82.fsf@mcspd15.ucom.lsi.nec.co.jp>
Message-ID: <20020401073239.GA12751@codepoet.org>

On Tue Mar 26, 2002 at 03:05:33PM +0900, Miles Bader wrote:
> Hi,
> 
> This patch adds support for the v850e processor to busybox's insmod
> program.  The patch is against busybox 0.60.0 from uClinux-dist-20020214.
> 
> Could you apply it?

Sure.  Will do.  Just been busy for the past week...

 -Erik

--
Erik B. Andersen             http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From miles at lsi.nec.co.jp  Mon Apr  1 03:38:05 2002
From: miles at lsi.nec.co.jp (Miles Bader)
Date: 01 Apr 2002 17:38:05 +0900
Subject: [uClinux-dev] Re: [BusyBox] patch to add v850 support to busybox insmod
In-Reply-To: <20020401073239.GA12751@codepoet.org>
References: <buoy9gflv82.fsf@mcspd15.ucom.lsi.nec.co.jp>
	<20020401073239.GA12751@codepoet.org>
Message-ID: <buo663b7r0y.fsf@mcspd15.ucom.lsi.nec.co.jp>

Erik Andersen <andersen at codepoet.org> writes:
> Sure.  Will do.  Just been busy for the past week...

Hi,

I sent a later patch (to busybox at busybox.net) that's against busybox-cvs,
which should be used isntead of the earlier patch (which is against the
busybox in uClinux-dist).

[or I can just apply it myself if you want, since I seem to have write
access to busybox-cvs]

Cheers,

-Miles
-- 
"Most attacks seem to take place at night, during a rainstorm, uphill,
 where four map sheets join."   -- Anon. British Officer in WW I
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From andersen at codepoet.org  Mon Apr  1 04:10:49 2002
From: andersen at codepoet.org (Erik Andersen)
Date: Mon, 1 Apr 2002 02:10:49 -0700
Subject: [uClinux-dev] Re: [BusyBox] patch to add v850 support to busybox insmod
In-Reply-To: <buo663b7r0y.fsf@mcspd15.ucom.lsi.nec.co.jp>
References: <buoy9gflv82.fsf@mcspd15.ucom.lsi.nec.co.jp> <20020401073239.GA12751@codepoet.org> <buo663b7r0y.fsf@mcspd15.ucom.lsi.nec.co.jp>
Message-ID: <20020401091049.GA13741@codepoet.org>

On Mon Apr 01, 2002 at 05:38:05PM +0900, Miles Bader wrote:
> Erik Andersen <andersen at codepoet.org> writes:
> > Sure.  Will do.  Just been busy for the past week...
> 
> Hi,
> 
> I sent a later patch (to busybox at busybox.net) that's against busybox-cvs,
> which should be used isntead of the earlier patch (which is against the
> busybox in uClinux-dist).

Ok.

> [or I can just apply it myself if you want, since I seem to have write
> access to busybox-cvs]

Yup, you do.  Feel free to commit the patch yourself then.  :)

 -Erik

--
Erik B. Andersen             http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From chenypg at hotmail.com  Mon Apr  1 05:03:25 2002
From: chenypg at hotmail.com (chen yp)
Date: Mon, 01 Apr 2002 10:03:25 +0000
Subject: [uClinux-dev] A question about MCF5272!
Message-ID: <F130voFOAmEaJswFCHO000074c7@hotmail.com>

    In my project, I need to use TA pin of 5272 to insert external wait 
states.
This pin is multiplexed with PB5. I have set Port B Control Register and 
Port B Direction Register to configure this pin to signal TA. I also set 
Chip Select Option Register and programming the wait state field to 0x1F. 
But when
I try to read of write data, it always appears errors. Can anyone tell me 
what's
the matter?


_________________________________________________________________
?????????????? MSN Messenger?
http://messenger.microsoft.com/cn

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From chicagozer at hotmail.com  Mon Apr  1 10:39:05 2002
From: chicagozer at hotmail.com (Jim)
Date: Mon, 1 Apr 2002 07:39:05 -0800
Subject: [uClinux-dev] Quick question about Multitasking
Message-ID: <OE378qF0gcMWrEInAdv00019d42@hotmail.com>

Hi all,

I picked up a Zaurus last week that runs ucLinux and I must say it is pretty cool. It is impressive to see Linux running so well on something so small!

I had a question about how the multitasking works w/o an MMU. The documentation says that vfork is used to mimic the functionality of fork. Can I assume that to launch multiple programs, you need to create a thread before calling vfork? (since vfork will block until the child dies?)

Jim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20020401/48b0db38/attachment.html>

From philwil at earthlink.net  Mon Apr  1 10:58:10 2002
From: philwil at earthlink.net (Phil Wilshire)
Date: Mon, 01 Apr 2002 10:58:10 -0500
Subject: [uClinux-dev] Quick question about Multitasking
References: <OE378qF0gcMWrEInAdv00019d42@hotmail.com>
Message-ID: <3CA88392.EB66B694@earthlink.net>

Hi Jim

The Zaurus has an MMU so no problems

Without an MMU you simply call vfork and then execve followed by _exit
to 
release the parent thread.

look in the inetd example in a UcLinux distribution..


regards
  Phil Wilshire


Jim wrote:
> 
> Hi all,
> 
> I picked up a Zaurus last week that runs ucLinux and I must say it is
> pretty cool. It is impressive to see Linux running so well on
> something so small!
> 
> I had a question about how the multitasking works w/o an MMU. The
> documentation says that vfork is used to mimic the functionality of
> fork. Can I assume that to launch multiple programs, you need to
> create a thread before calling vfork? (since vfork will block until
> the child dies?)
> 
> Jim
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From peco at microbotica.es  Mon Apr  1 11:12:50 2002
From: peco at microbotica.es (Juan =?ISO-8859-1?Q?Jos=E9?= 'Peco' San =?ISO-8859-1?Q?Mart=EDn?=)
Date: 01 Apr 2002 18:12:50 +0200
Subject: [uClinux-dev] Quick question about Multitasking
In-Reply-To: <3CA88392.EB66B694@earthlink.net>
References: <OE378qF0gcMWrEInAdv00019d42@hotmail.com> 
	<3CA88392.EB66B694@earthlink.net>
Message-ID: <1017677591.882.3.camel@mordor>


I'm confused...Zaurus runs uClinux or Linux Embedded of Lineo?


Peco.

On Mon, 2002-04-01 at 17:58, Phil Wilshire wrote:
> Hi Jim
> 
> The Zaurus has an MMU so no problems
> 
> Without an MMU you simply call vfork and then execve followed by _exit
> to 
> release the parent thread.
> 
> look in the inetd example in a UcLinux distribution..
> 
> 
> regards
>   Phil Wilshire
> 
> 
> Jim wrote:
> > 
> > Hi all,
> > 
> > I picked up a Zaurus last week that runs ucLinux and I must say it is
> > pretty cool. It is impressive to see Linux running so well on
> > something so small!
> > 
> > I had a question about how the multitasking works w/o an MMU. The
> > documentation says that vfork is used to mimic the functionality of
> > fork. Can I assume that to launch multiple programs, you need to
> > create a thread before calling vfork? (since vfork will block until
> > the child dies?)
> > 
> > Jim
> This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/
> 
-- 
Juan Jos? "Peco" San Mart?n	

Microb?tica, S.L
Mail: peco at microbotica.es
Web: www.microbotica.es

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From bkuhn at lineo.com  Mon Apr  1 14:00:24 2002
From: bkuhn at lineo.com (Bernhard Kuhn)
Date: Mon, 01 Apr 2002 21:00:24 +0200
Subject: [uClinux-dev] Quick question about Multitasking
References: <OE378qF0gcMWrEInAdv00019d42@hotmail.com> 
		<3CA88392.EB66B694@earthlink.net> <1017677591.882.3.camel@mordor>
Message-ID: <3CA8AE48.9A4F171A@lineo.com>

Juan Jos? 'Peco' San Mart?n schrieb:
> 
> I'm confused...Zaurus runs uClinux or Linux Embedded of Lineo?

The Sharp Zaurus SL5000D (and SL5500) is based on an StrongARM
and it comes pre-installed with the MMU-full version of Lineo's
Embedix. Earlier versions of the Zaurus are marketed since 1993
in far east. Maybe it is possible to run uClinux on those Zaurii ...

best regards

Bernhard

-- 
Bernhard Kuhn, Software Engineer, Lineo Inc. (Where Open Meets Smart)
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From RThornblad at utsci.com  Mon Apr  1 15:54:56 2002
From: RThornblad at utsci.com (Roger Thornblad)
Date: Mon, 1 Apr 2002 13:54:56 -0700 
Subject: [uClinux-dev] 5307 int vectors 64 - 255 Questions
Message-ID: <B8062940F5F9D8469E250780F3D2161807A2A1@usipub.utsci.com>


I've been reading the motorola manuals for the 5307.  The exception
processing section shows user defined interrupts from 64-255.

Does anyone know of an example of how you might use these? 

We've looked at the onboard serial port code and how it uses 224-225.
However, these interrupts still rely on the onboard UARTS to generate the
interrupt.

I know how to add the vector to the table and register the interrupt etc
etc.   The only thing I haven't been able to find is the means to initiate
the handler function.

Thanks,

Roger.


This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From hamilton at SEDSystems.ca  Mon Apr  1 16:24:12 2002
From: hamilton at SEDSystems.ca (Kendrick Hamilton)
Date: Mon, 1 Apr 2002 15:24:12 -0600 (CST)
Subject: [uClinux-dev] 5307 int vectors 64 - 255 Questions
In-Reply-To: <B8062940F5F9D8469E250780F3D2161807A2A1@usipub.utsci.com>
Message-ID: <Pine.LNX.4.44.0204011521130.1092-100000@sw-55.sedsystems.ca>

With the 68360, you use a peripheral that can put its interrupt number on
the data bus. The peripheral generates an interrupt then waits for a
signal. When it sees the signal, it puts its interrupt number on the
databus.

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

On Mon, 1 Apr 2002, Roger Thornblad wrote:

>
> I've been reading the motorola manuals for the 5307.  The exception
> processing section shows user defined interrupts from 64-255.
>
> Does anyone know of an example of how you might use these?
>
> We've looked at the onboard serial port code and how it uses 224-225.
> However, these interrupts still rely on the onboard UARTS to generate the
> interrupt.
>
> I know how to add the vector to the table and register the interrupt etc
> etc.   The only thing I haven't been able to find is the means to initiate
> the handler function.
>
> Thanks,
>
> Roger.
>
>
> This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/
>

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From SMerrifield at tecom.com.au  Mon Apr  1 18:16:18 2002
From: SMerrifield at tecom.com.au (Steven Merrifield)
Date: Tue, 2 Apr 2002 01:16:18 +0200 
Subject: [uClinux-dev] Very large images
Message-ID: <7FF1185EA0D3D511BC0500B0D0D0C24A1B5981@melexc01.ap.ilxi.net>

Hi Matt,

The latest distribution I have on hand is 20020214, and
building kernel 2.0.39 with the ELF tools does indeed
produce an image greater than 200M. Changing to a 2.4 
kernel, this does not happen.

steve

> -----Original Message-----
> From: Matt Bergeron [mailto:smackeron at caltech.edu]
> Sent: Friday, 29 March 2002 10:12
> To: uclinux-dev at uclinux.org
> Cc: smerrifield at tecom.com.au
> Subject: Re: [uClinux-dev] Very large images
> 
> 
> Hi,
> 
> Was this large images issue on the uCsimm ever resolved? I'm using 
> distribution 20020220 and trying to build a 2.0.39 kernel 
> with the ELF 
> toolchain, and getting an image over 200 MB in size. I'm getting the 
> exact same warning in the linker stage that Steven was. Is there a 
> problem with the distro?
> 
> Thanks,
> Matt
> 
> 
> On Sunday, October 21, 2001, at 05:10  PM, Steven Merrifield wrote:
> 
> > Hi all,
> >
> > I am still having problems getting the elf tools to create an image 
> > that is
> > less
> > than 200M. I am getting two warnings at the linker stage, 
> shown below. 
> > Is
> > the
> > last one due to a missing flag somewhere, and is it the cause of my 
> > problem?
> >
> > Using distribution 20010622, kernel 2.0.38, EZ328, elf, patched 
> > Rules.make
> > to
> > disable the coff tools.
> >
> > Thanks,
> > steve
> >
> > m68k-elf-ld -g -T arch/m68knommu/platform/68EZ328/ucsimm/rom.ld
> > arch/m68knommu/p
> > latform/68EZ328/ucsimm/crt0_rom.o init/main.o init/version.o \
> > arch/m68knommu/kernel/kernel.o arch/m68knommu/mm/mm.o
> > arch/m68knommu/platform/68
> > EZ328/platform.o kernel/kernel.o fs/fs.o ipc/ipc.o net/network.a
> > mmnommu/mm.o \
> > fs/filesystems.a \
> > drivers/block/block.a drivers/char/char.a drivers/net/net.a \
> > /win/uClinux-distribution/linux/lib/lib.a arch/m68knommu/lib/lib.a
> > `m68k-elf-gcc
> >  -g -D__KERNEL__ -I/win/uClinux-distribution/linux/include 
> -v 2>&1 | 
> > grep
> > specs
> > | sed -e "s/Reading specs from //" | sed -e 
> > s/specs/m68000\\\/libgcc.a/` -o
> > linu
> > x
> > /usr/local/bin/m68k-elf-ld.real: Warning: size of symbol 
> `irq2dev_map'
> > changed f
> > rom 4 to 128 in auto_irq.o
> > /usr/local/bin/m68k-elf-ld.real: warning: no memory region 
> specified for
> > section
> >  `.rodata'
> > m68k-elf-nm linux | grep -v '\(compiled\)\|\(\.o$\)\|\( a 
> \)' | sort >
> > System.ma
> > p
> >
> > This message resent by the uclinux-dev at uclinux.org list server 
> > http://www.uClinux.org/
> 
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From davidm at snapgear.com  Mon Apr  1 18:49:05 2002
From: davidm at snapgear.com (David McCullough)
Date: Tue, 2 Apr 2002 09:49:05 +1000
Subject: [uClinux-dev] Re: patch to add v850 support to busybox insmod
In-Reply-To: <buoelhz7vpu.fsf@mcspd15.ucom.lsi.nec.co.jp>; from miles@lsi.nec.co.jp on Mon, Apr 01, 2002 at 03:56:45PM +0900
References: <buoy9gflv82.fsf@mcspd15.ucom.lsi.nec.co.jp> <3CA11E06.8040705@snapgear.com> <buoelhz7vpu.fsf@mcspd15.ucom.lsi.nec.co.jp>
Message-ID: <20020402094905.A28357@beast.internal.moreton.com.au>


Jivin Miles Bader lays it down ...
> Greg Ungerer <gerg at snapgear.com> writes:
> > Rolled into the uClinux-dist code.
> 
> Thanks!
> 
> Could you also apply this patch, which makes module parameters work:

Applied,  thanks :-)

Cheers,
Davidm

-- 
David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
davidm at snapgear.com  Fx: +61 7 3891 3630  825 Stanley St., W'gabba QLD 4102, Oz
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From bruce at tele-ip.com  Mon Apr  1 21:03:01 2002
From: bruce at tele-ip.com (Bruce Paterson)
Date: Tue, 02 Apr 2002 12:03:01 +1000
Subject: [uClinux-dev] M68360: IRQ 68 from ttyS is not replaceable, LSR 
 security check engaged
References: <1481.1017139814@www20.rz2.gmx.net> <19098.1017298370@www51.gmx.net>
Message-ID: <3CA91155.C07F8732@tele-ip.com>

Joachim Schweidler wrote:
> 
> Hi all,
> 
> some months ago I got uclinux 2.0.38 up and running on an 68EN360 Board
> (SBS
> V360). Now I upgraded to Kernel 2.4.x and the kernel starts and comes till

I was working on this recently, but at present I've been moved to
something else so haven't
had the time to get back to it.
I sent in patches to convert the 2.4.x to use Kendrik's newer serial
driver (as written for 2.0.38), 
but against an earlier snapshot rather than cvs, so I don't know the
current status of the cvs
version.
I also modified the ethernet driver for the EN360 to be compatible with
the way the 2.4.x kernel
works, but haven't had a chance to debug it (it's not all the way
there).

Apologies I haven't managed to get things to a stable state, but the
ethernet bsp stuff in 2.4.x was
plain broken before, so starting from where I left off would save you a
lot of time !

Kendrik's serial driver dumps the old uart.c and enet.c files, so if
you're still using these
you have the old one.

-- 
Cheers,
Bruce
-------------------------------------------------------------------
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom
they are addressed. If you have received this email in error please
notify the system manager.

    /\\\/\\\/\\\    /   /      Bruce Paterson          
   /  \\\ \\\ \\\  /   /    Senior Design Engineer
  /   /\\\/\\\/\\\/   /   87 Peters Ave, Mulgrave, Vic, 3170
 /   /  \\\ \\\ \\\  /  PO Box 4112, Mulgrave, Vic, 3170, Australia
/   /    \\\/\\\ \\\/   Ph: +61 3 8561 4232   Fax: +61 3 9560 9055
      Tele-IP Ltd.      Email: bruce at tele-ip.com    Icq: #32015991
                        WWW:   http://www.tele-ip.com       VK3TJN
-------------------------------------------------------------------
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From pauli at snapgear.com  Mon Apr  1 23:54:42 2002
From: pauli at snapgear.com (pauli at snapgear.com)
Date: Tue, 02 Apr 2002 14:54:42 +1000
Subject: [uClinux-dev] Shared libraries
Message-ID: <200204020454.g324sghZ022317@skaro.internal.moreton.com.au>


Hi all,

If all goes well with our testing, our next ColdFire source tree cut will 
include shared libraries for the uClinux platform!  The methods used should 
carry over to other 68k based processors easily -- I'm aware of only one 
problem to do with signal handling.  This work should also carry over to other 
processors with surprisingly little effort as well.


I've implemented a modification of our existing execute in place code model
(-msep-data) to allow libraries to be shared amongst multiple applications.
This greatly reduces the size of those executables in the file system.  This in
turn reduces the final image size.  The overheads required to support these
shared libraries are very minimal and the modifications are relatively
clean.

A shared library can be constructed from any combination of object and
library files with only a few restrictions.  Each shared library is
capable of running initialisation and finalisation code -- via the CTORS
and DTORS mechanisms and additionally via a library specific main().
The only known restriction on shared libraries at this point is that the
environ global variable will not be initialised until the main program
has started its execution.  Libraries are initialised in a specific well
defined order that cannot be overridden on a per application basis.

The penalty for this code reuse is the carrying of the shared library's
entire data segment with all applications (e.g. our libc/libgcc
combination library requires 16kb of data segment).  Some of this data
space was previously required, although all of it would not be for any
single application.  An additional optimisation over our previous tool
chain releases allows read only data which does not contain relocations
to be placed into the shared text segment.  Previously such data lived
in the data segment.  This change will greatly reduce the requirement
to carry the full data segment of the libraries.

The shared libraries themselves are flat files and are pretty much
indistinguishable from normal executables.  No additional relocation and
run time linking information needs to be supplied.  Most importantly,
no symbol table wastage appears on the embedded platform, this overhead
is carried by the host system.

The implementation requires a small modification to gcc to set up data
segment pointers correctly.  The generated code is just as time and space
efficient as traditional PIC code is.  Other changes are required in the
flat file loader and in the build process.  Only the flat file loader
requires significant modifications and these changes should support
other platforms using the same method of shared library realisation.


The implementation produces a separate GOT and data segment for the
application and each shared library it uses.  These are all allocated
separately and accessed using the %a5 register (the standard PIC
data segment pointer register on the 68000).  The trick is to contain
pointers to the other data segments at known fixed offsets from the base
of each data segment.  Thus a function can load the pointer to its data
segment by loading from the appropriate offset from the base of any of
the allocated data segments.

In this implementation, each library is allocated a specific library
identification number and this number is used to determine the offset
used to locate its private data segment.  The main program is allocated
the identification of 0 just as if were a library.  Thus every procedure
can determine the location of its data segment and calls into and back
out of library routines will function properly and without restriction.

To handle cross references from a program to its libraries or from a
library to another library, another innovation is required.  Every library
is statically linked such that the top eight address bits correspond to
its identification number.  When the main program is linked, it refers to
these addresses directly.  The flat file loader in the kernel has the task
of unravelling these cross references.  Because the library identification
is included within the address it is possible to perform the necessary
relocations.  Additionally, due to the way we build programs, all
address references in a program are made either via the GOT or via an
initialised address in the data segment.  These are both located in the
private data segment of each library and program and thus the relocations
can be performed without disturbing the code (hence shared text segments
are preserved).  This method of handling relocations allows a program to
directly access data included inside a library (e.g. stdin), the kernel
loader transparently handles all of the inter-library cross references.

There are some limitations, none of which are severe.  Because each
library and application requires a GOT to access address information a
limit of 8192 globals and distinct procedures exists for each library
and application.  This is by no means a limitation on the size of data,
only the total number of distinct names.  It is important to note that
each library can have 8192 such entries in addition to the 8192 for
the main application.  In practice we've never needed even a quarter
of these entries and that was without shared libraries (i.e. using
-msep-data builds).

There is another limitation on the number of shared libraries available.
There is a fairly strict limit of 255 shared libraries imposed by the
compiler modifications.  This limit is system wide and will be troublesome
to overcome, although by no means impossible.  The kernel flat file
loader imposes a smaller limit on the number of shared libraries.
This is currently set to 3 and can be increased simply by changing a
#define in the flat file loader C file.  The reason this is set so low
is to reduce the overhead caused by having a larger number.  For n shared
libraries there is an overhead of 4n+4 bytes per data segment and with up
to n+1 data segments per application this quickly adds up.  Since a shared
library can be made up of any combination of object files and libraries,
this limit isn't so bad.  For example, our shared libc actually includes
both libc and libgcc (which has the compiler support routines).  A C++
application suite could define a second shared library which contains
all the C++ libraries rolled together.

Finally, there is a code size limitation due to the stealing of address
bits from the top of the relocation entries.  This limitation is 16
megabytes per library and application.  If your application grows
beyond this size, it will need to be split up into two or more pieces.
This limitation really couldn't be considered significant in the context
of an embedded environment :-)


Regards,

Pauli


This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From eric.bosch at fourtress.nl  Tue Apr  2 02:33:47 2002
From: eric.bosch at fourtress.nl (Eric Bosch (Fourtress))
Date: Tue, 2 Apr 2002 09:33:47 +0200
Subject: [uClinux-dev] Serial communication problem
Message-ID: <OHEGKBKJNDMIKNAMMKBMGECMCAAA.eric.bosch@fourtress.nl>

Hi all!

I have my console connected to my serial port and I saved this setting. Now
I can't communicate with my board (68EZ328) using a serial cable. I'm using
minicom as communication program.

Can someone help with this problem?

Thanks Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20020402/f6219b83/attachment.html>

From sheeliang at lit.org.sg  Tue Apr  2 03:46:46 2002
From: sheeliang at lit.org.sg (Chia Shee Liang)
Date: Tue, 2 Apr 2002 16:46:46 +0800
Subject: [uClinux-dev] Bootloader for ARM?
Message-ID: <20020402164646.A1145@localhost.localdomain>

I'm looking for a bootloader for ARM.

After a few months of tweaking, I've finally gotten the ARM7TDMI to work with
the Integrator AP. Almost everything works. Serial console works, PCI works, 
network card(pcnet32) works, networking works, root over NFS works, flash mtd 
works, JFFS2 on mtd works, JFFS2 as root works, boa webserver works. Basically,
I lack a good bootloader which can pass options to the kernel proper. What I'm 
doing now is simply copying the kernel image to RAM as-is and jumping to it.

Thanks!
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From tahir at snom.de  Tue Apr  2 03:47:58 2002
From: tahir at snom.de (Muhammad Usman Tahir)
Date: Tue, 2 Apr 2002 10:47:58 +0200
Subject: [uClinux-dev] Re: User Application: Permission denied.
References: <010801c1d670$19399590$2200a8c0@flamenco> <3CA47509.3000209@snapgear.com>
Message-ID: <011201c1da23$17305ac0$2200a8c0@flamenco>

Hi,

Here are the make commands in the Makefile for my_app in /user. SOURCE has
the c++ source and OBJ has the object files. This generates my_app (EXEC)
which I presume is a flat binary. I'm not using CONVERT as I don't have an
elf image because I used -elf2flt option with linker.

all: $(EXEC)

$(EXEC): $(OBJS)
 $(CC) $(CFLAGS) $(CPPFLAGS) -c $(SOURCE) -lstdc++ -lc -lgcc
 $(LD) $(LDFLAGS) -elf2flt -o $(EXEC) $(OBJS) $(LDLIBS)

I'll try flthdr and get back with more info. Can something be added (or
removed for that matter) from these make commands to make things a little
better?

Regards,
Usman.



----- Original Message -----
From: "Greg Ungerer" <gerg at snapgear.com>
To: "Coldfire CPU Discussion List" <ColdFire at WildRice.com>
Cc: <uclinux-dev at uclinux.org>
Sent: Friday, March 29, 2002 4:07 PM
Subject: [uClinux-dev] Re: User Application: Permission denied.


>
> Hi Usman,
>
> Muhammad Usman Tahir wrote:
>
> > I've an MCF 5206 system with 8MB RAM and having 2.0.38 uClinux kernel
> > running fine with basic apps like shell, dhcpcd etc. I've added  one of
my
> > applications in '/user/my_app' and it has been successfully compiled and
> > linked to generate a binary. I then modified 'rc' script to run this app
by
> > do_rc from init. On execution it says :
> >
> > Command: my_app
> > my_app: Permission denied.
> >
> > and then continues with the next item in 'rc'.
> >
> > I have checked all the permissions for the binary of my_app in the
> > 'romfs/bin' and have even forced it to be executable but the error
message
> > remains the same. I tried to copy the file attribs from the running
dhcpcd
> > app but still ended up with the same result.
> >
> > I should add here that I bypassed the generation of elf file while
> > compilation and linked to get a flat binary directly with -elf2flt
option in
> > m68k-elf-gcc. (I had lots of problems with elf2flt and searching through
the
> > archives I found this work around to what seems to be a common problem).
I
> > think this should not have caused any problem as long as I don't need an
elf
> > file for my_app, which I don't.
>
> Can you reply with what the exact command line was?
>
> Have you check that you really do have a FLAT format file?
> Hex dump the file and check that it has a valid looking header.
> You could use the "flthdr" program too to check if it is a valid
> FLAT file.
>
> > Any idea how I can get my_app really working without this message? Shall
I
> > try some other method to start my_app? Thanks in advance for the all the
> > help.
>
> Try running it from the command line.
>
> Regards
> Greg
>
>
> ------------------------------------------------------------------------
> Greg Ungerer  --  Chief Software Wizard        EMAIL:  gerg at snapgear.com
> SnapGear                                       PHONE:    +61 7 3279 1822
> 825 Stanley St,                                  FAX:    +61 7 3279 1820
> Woolloogabba, QLD, 4102, Australia               WEB:   www.snapgear.com
>
> This message resent by the uclinux-dev at uclinux.org list server
http://www.uClinux.org/

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From kumarkp at knowsys.net  Tue Apr  2 03:46:18 2002
From: kumarkp at knowsys.net (Prasanna Kumar K)
Date: Tue, 02 Apr 2002 14:16:18 +0530
Subject: [uClinux-dev] Serial communication problem
References: <OHEGKBKJNDMIKNAMMKBMGECMCAAA.eric.bosch@fourtress.nl>
Message-ID: <3CA96FDA.9060503@knowsys.net>

Hi Eric,
   
    With only this information, I doubt anyone would be able to help you!

    Check up your minicom settings. Baud rate, parity, flow control etc. 
Many a times the problem can be with the serial cable itself! To avoid 
confusion, make sure that your cable is working fine!

May be you have checked all these basic things..... but just wanted to 
remind you :-)

Regards,
:)Prasanna
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Eric Bosch (Fourtress) wrote:

> Hi all!
>
>  
>
> I have my console connected to my serial port and I saved this 
> setting. Now I can't communicate with my board (68EZ328) using a 
> serial cable. I'm using minicom as communication program.
>
>  
>
> Can someone help with this problem?
>
>  
>
> Thanks Eric
>


This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From eric.bosch at fourtress.nl  Tue Apr  2 04:06:04 2002
From: eric.bosch at fourtress.nl (Eric Bosch (Fourtress))
Date: Tue, 2 Apr 2002 11:06:04 +0200
Subject: [uClinux-dev] uCsimm problem - Newbie
Message-ID: <OHEGKBKJNDMIKNAMMKBMGECNCAAA.eric.bosch@fourtress.nl>

My host computer can not talk to the ucSimm board, does anyone have any
suggestion?


I already configured minicom terminal to talk at 9600 8N1, when I plugged
the
RS 232 to the board. Then I changed the CONSOLE environment variable with
the command setenv CONSOLE ttyS1. But now I can't communicatie with my
board? I don't see a prompt when I start minicom and reset the target.

Who helps a newbie?



Thanks Eric



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20020402/5f68f054/attachment.html>

From miles at lsi.nec.co.jp  Tue Apr  2 04:43:46 2002
From: miles at lsi.nec.co.jp (Miles Bader)
Date: 02 Apr 2002 18:43:46 +0900
Subject: [uClinux-dev] v850 patch
Message-ID: <buolmc6cu5p.fsf@mcspd15.ucom.lsi.nec.co.jp>

Hi, could you apply this patch:


-------------- next part --------------
A non-text attachment was scrubbed...
Name: uclinux-2.4-v850-20020402-dist.patch
Type: text/x-patch
Size: 2876 bytes
Desc: Patch to fix v850 interrupt lossage
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20020402/5927ed40/attachment.patch>
-------------- next part --------------


Thanks,

-Miles

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

From gmenie at akamai.com  Tue Apr  2 05:08:37 2002
From: gmenie at akamai.com (Menie, Georges)
Date: Tue, 2 Apr 2002 05:08:37 -0500 
Subject: [uClinux-dev] 68*328 time patch
Message-ID: <D447D880267ED5118F2A00D0B74A108B11E388@munich-ex1.munich.akamai.com>

Here is a patch which reactivate the lost_ticks
computation for the m68knommu arch. The patch should be
run against the linux-2.4.x module in CVS.
The lost ticks calculation allow for a more accurate
gettimeofday function call.

Greg, David, could you apply it ?

Regards,
Georges

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-time.txt
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20020402/09d2f1ae/attachment.txt>

From moh.shiha at ieee.org  Tue Apr  2 05:10:10 2002
From: moh.shiha at ieee.org (Mohamed Ali Shiha)
Date: Tue, 2 Apr 2002 12:10:10 +0200
Subject: [uClinux-dev] Serial communication problem
References: <OHEGKBKJNDMIKNAMMKBMGECMCAAA.eric.bosch@fourtress.nl>
Message-ID: <OE97Txek5KuxfWpmUxI0002ede7@hotmail.com>

Hi ,

First of all, you have to be sure that minicom is communicating with the same serial port that your board is connected to .. Then be sure that your minicom is set to the following:
no software/hardware control
8N1
115200 bps
Then if minicom doesn't communicate you have to write : "login" in minicom .... this should overcome any software problem ... otherwise , you have a haredware problem ..

Mohamed Shiha
  ----- Original Message ----- 
  From: Eric Bosch (Fourtress) 
  To: Uclinux-Dev at Uclinux. Org 
  Sent: Tuesday, April 02, 2002 9:33 AM
  Subject: [uClinux-dev] Serial communication problem


  Hi all!

  I have my console connected to my serial port and I saved this setting. Now I can't communicate with my board (68EZ328) using a serial cable. I'm using minicom as communication program.

  Can someone help with this problem?

  Thanks Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20020402/071a2b21/attachment.html>

From eric.bosch at fourtress.nl  Tue Apr  2 05:23:31 2002
From: eric.bosch at fourtress.nl (Eric Bosch (Fourtress))
Date: Tue, 2 Apr 2002 12:23:31 +0200
Subject: [uClinux-dev] Serial communication problem
In-Reply-To: <3CA96FDA.9060503@knowsys.net>
Message-ID: <OHEGKBKJNDMIKNAMMKBMOECNCAAA.eric.bosch@fourtress.nl>

Ok but,

I already configured minicom terminal to talk at 9600 8N1, when I plugged
the
RS 232 to the board. The serial port setup is configured: serial device:
dev/ttyS1 lockfile: /tmp and the hardware and software flow control: No.

So, I in the past (with this settings) I could communicatie and I saw the
bootloader prompt.

Then I changed the CONSOLE environment variable with the command: setenv
CONSOLE ttyS1. After that I start minicom again  but I don't see any
bootloader prompt when resetting the board. How I can't communicatie with my
board?

Thanks Eric

-----Oorspronkelijk bericht-----
Van: owner-uclinux-dev at uclinux.org
[mailto:owner-uclinux-dev at uclinux.org]Namens Prasanna Kumar K
Verzonden: dinsdag 2 april 2002 10:46
Aan: uclinux-dev at uclinux.org
Onderwerp: Re: [uClinux-dev] Serial communication problem


Hi Eric,

    With only this information, I doubt anyone would be able to help you!

    Check up your minicom settings. Baud rate, parity, flow control etc.
Many a times the problem can be with the serial cable itself! To avoid
confusion, make sure that your cable is working fine!

May be you have checked all these basic things..... but just wanted to
remind you :-)

Regards,
:)Prasanna
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Eric Bosch (Fourtress) wrote:

> Hi all!
>
>
>
> I have my console connected to my serial port and I saved this
> setting. Now I can't communicate with my board (68EZ328) using a
> serial cable. I'm using minicom as communication program.
>
>
>
> Can someone help with this problem?
>
>
>
> Thanks Eric
>


This message resent by the uclinux-dev at uclinux.org list server
http://www.uClinux.org/

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From peco at microbotica.es  Tue Apr  2 05:55:14 2002
From: peco at microbotica.es (Juan =?ISO-8859-1?Q?Jos=E9?= 'Peco' San =?ISO-8859-1?Q?Mart=EDn?=)
Date: 02 Apr 2002 12:55:14 +0200
Subject: [uClinux-dev] Serial communication problem
In-Reply-To: <OHEGKBKJNDMIKNAMMKBMOECNCAAA.eric.bosch@fourtress.nl>
References: <OHEGKBKJNDMIKNAMMKBMOECNCAAA.eric.bosch@fourtress.nl>
Message-ID: <1017744922.911.23.camel@mordor>

On Tue, 2002-04-02 at 12:23, Eric Bosch (Fourtress) wrote:
> Ok but,
> 
> I already configured minicom terminal to talk at 9600 8N1, when I plugged
> the
> RS 232 to the board. The serial port setup is configured: serial device:
> dev/ttyS1 lockfile: /tmp and the hardware and software flow control: No.
> 
> So, I in the past (with this settings) I could communicatie and I saw the
> bootloader prompt.
> 
> Then I changed the CONSOLE environment variable with the command: setenv
> CONSOLE ttyS1. After that I start minicom again  but I don't see any
> bootloader prompt when resetting the board. How I can't communicatie with my
> board?

Ok, it seems that you've changed the serial port of your uCsimm to
/dev/ttyS1 (com2) but, the problem is that the uCsimm haven't got it ;-)

The first solution (but may be the worst) is to make an ethernet
(TCP/IP)connection in order to set the enviroment variable to the right
value. Could you make a telnet to your uCsimm, couldn't you?
After that, you could use the Bootloader API, int setbenv(char *pair),
to establish the new value.

Anyway, I'm sure that we could find an easier solution.

Peco.

> 
> Thanks Eric
> 
> -----Oorspronkelijk bericht-----
> Van: owner-uclinux-dev at uclinux.org
> [mailto:owner-uclinux-dev at uclinux.org]Namens Prasanna Kumar K
> Verzonden: dinsdag 2 april 2002 10:46
> Aan: uclinux-dev at uclinux.org
> Onderwerp: Re: [uClinux-dev] Serial communication problem
> 
> 
> Hi Eric,
> 
>     With only this information, I doubt anyone would be able to help you!
> 
>     Check up your minicom settings. Baud rate, parity, flow control etc.
> Many a times the problem can be with the serial cable itself! To avoid
> confusion, make sure that your cable is working fine!
> 
> May be you have checked all these basic things..... but just wanted to
> remind you :-)
> 
> Regards,
> :)Prasanna
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> Eric Bosch (Fourtress) wrote:
> 
> > Hi all!
> >
> >
> >
> > I have my console connected to my serial port and I saved this
> > setting. Now I can't communicate with my board (68EZ328) using a
> > serial cable. I'm using minicom as communication program.
> >
> >
> >
> > Can someone help with this problem?
> >
> >
> >
> > Thanks Eric
> >
> 
> 
> This message resent by the uclinux-dev at uclinux.org list server
> http://www.uClinux.org/
> 
> This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/
> 
-- 
Juan Jos? "Peco" San Mart?n	

Microb?tica, S.L
Mail: peco at microbotica.es
Web: www.microbotica.es

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From stefan.jonsson at faltcom.se  Tue Apr  2 06:37:31 2002
From: stefan.jonsson at faltcom.se (Stefan Jonsson)
Date: Tue, 2 Apr 2002 13:37:31 +0200
Subject: [uClinux-dev] EB40+MEC, bootloader, gcc and more ...
Message-ID: <NGBBJKACILMHGKHMEHHLMEHMCAAA.stefan.jonsson@faltcom.se>

Hello list,

I have the EB40 + MEC01. I have managed to get contact with angel via gdb. I
have built a romfs with 2.4.x kernel from the "full source distribution". It
is very large though 2,1 MB. Is it possible to "split" it on the two flashes
on MEC (1MB + 2MB)?

* Otherwise, is there a simple way to choose what should be built in the
romfs? Where?
(since I don't need everything built in)

Anyway I do not know how to write it to the flash (on the MEC01 (from
linux)) and I was thinking about downloading to SRAM 2MB (on the MEC) and
test it from there (to begin with). Since I want to use 'load' in gdb I have
checked the .elf -file with "arm-elf-objdump -h linux" to see which address
it will be downloaded to ... 0x1000000 seems to be default.

* Is there a .ln-file somewhere to change the dl-address? (or whatever file
it might be)

* To be lazy, is it possible to use that "default address" and just map in
MEC memory on 0x1000000? (well, since it is possible, the question is
really: "how do I do that?")

* Since cs0/cs1 (the switch) gives default boot on the EB40, is it possible
to change somehow to boot on MEC (preferebly by not solder loose the flash
on the EB40)?

* Maybe modifying cstartup in the Atmel-bootloader and map MEC there is a
good solution?
(If I'm getting this correctly that would eliminate the problem of booting
from the MEC?)


I would greatly appreciate any help I can get on this.

Thank you!

Reagards,
Stefan Jonsson,
Student, University of Umea, Sweden.

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From eric.bosch at fourtress.nl  Tue Apr  2 07:09:37 2002
From: eric.bosch at fourtress.nl (Eric Bosch (Fourtress))
Date: Tue, 2 Apr 2002 14:09:37 +0200
Subject: [uClinux-dev] Serial communication problem
In-Reply-To: <1017744922.911.23.camel@mordor>
Message-ID: <OHEGKBKJNDMIKNAMMKBMEECPCAAA.eric.bosch@fourtress.nl>


Thanks Juan,

Thanks Juan,

But I can't make a telnet to my uCsimm. The IP adress of my uCsimm is
192.168.1.200 and I try at the command line of my terminal: telnet
192.168.1.200

Are there other solutions?



-----Oorspronkelijk bericht-----
Van: owner-uclinux-dev at uclinux.org
[mailto:owner-uclinux-dev at uclinux.org]Namens Juan Jos? 'Peco' San Mart?n
Verzonden: dinsdag 2 april 2002 12:55
Aan: uClinux
Onderwerp: RE: [uClinux-dev] Serial communication problem


On Tue, 2002-04-02 at 12:23, Eric Bosch (Fourtress) wrote:
> Ok but,
>
> I already configured minicom terminal to talk at 9600 8N1, when I plugged
> the
> RS 232 to the board. The serial port setup is configured: serial device:
> dev/ttyS1 lockfile: /tmp and the hardware and software flow control: No.
>
> So, I in the past (with this settings) I could communicatie and I saw the
> bootloader prompt.
>
> Then I changed the CONSOLE environment variable with the command: setenv
> CONSOLE ttyS1. After that I start minicom again  but I don't see any
> bootloader prompt when resetting the board. How I can't communicatie with
my
> board?

Ok, it seems that you've changed the serial port of your uCsimm to
/dev/ttyS1 (com2) but, the problem is that the uCsimm haven't got it ;-)

The first solution (but may be the worst) is to make an ethernet
(TCP/IP)connection in order to set the enviroment variable to the right
value. Could you make a telnet to your uCsimm, couldn't you?
After that, you could use the Bootloader API, int setbenv(char *pair),
to establish the new value.

Anyway, I'm sure that we could find an easier solution.

Peco.

>
> Thanks Eric
>
> -----Oorspronkelijk bericht-----
> Van: owner-uclinux-dev at uclinux.org
> [mailto:owner-uclinux-dev at uclinux.org]Namens Prasanna Kumar K
> Verzonden: dinsdag 2 april 2002 10:46
> Aan: uclinux-dev at uclinux.org
> Onderwerp: Re: [uClinux-dev] Serial communication problem
>
>
> Hi Eric,
>
>     With only this information, I doubt anyone would be able to help you!
>
>     Check up your minicom settings. Baud rate, parity, flow control etc.
> Many a times the problem can be with the serial cable itself! To avoid
> confusion, make sure that your cable is working fine!
>
> May be you have checked all these basic things..... but just wanted to
> remind you :-)
>
> Regards,
> :)Prasanna
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> Eric Bosch (Fourtress) wrote:
>
> > Hi all!
> >
> >
> >
> > I have my console connected to my serial port and I saved this
> > setting. Now I can't communicate with my board (68EZ328) using a
> > serial cable. I'm using minicom as communication program.
> >
> >
> >
> > Can someone help with this problem?
> >
> >
> >
> > Thanks Eric
> >
>
>
> This message resent by the uclinux-dev at uclinux.org list server
> http://www.uClinux.org/
>
> This message resent by the uclinux-dev at uclinux.org list server
http://www.uClinux.org/
>
--
Juan Jos? "Peco" San Mart?n

Microb?tica, S.L
Mail: peco at microbotica.es
Web: www.microbotica.es

This message resent by the uclinux-dev at uclinux.org list server
http://www.uClinux.org/

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From moh.shiha at ieee.org  Tue Apr  2 07:34:41 2002
From: moh.shiha at ieee.org (Mohamed Ali Shiha)
Date: Tue, 2 Apr 2002 14:34:41 +0200
Subject: [uClinux-dev] how to erase every thing on the flash .. ?
Message-ID: <OE52kEPF3cMnA0VYqMh0003debf@hotmail.com>

Dear all,

does any one have a program to just erase every thing on the Flash of a
68VZ328 board ... ?
I have a buggy bootloader caused corrupted kernel on the flash and I can not
download another one till now ... :(

Thanks and regards
Mohamed Shiha


This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From pengyi at baby.seiwa-ele.co.jp  Tue Apr  2 09:11:39 2002
From: pengyi at baby.seiwa-ele.co.jp (pengyi)
Date: Tue, 2 Apr 2002 23:11:39 +0900
Subject: [uClinux-dev] 68*328 time patch
References: <D447D880267ED5118F2A00D0B74A108B11E388@munich-ex1.munich.akamai.com>
Message-ID: <004201c1da50$526898f0$6601a8c0@PYNOTE6>

Hi Georges:
 I am excited to know what you did because I am puzzled about the
lost_ticks.
My arch. is ucsimm and would you please tell me what can I do to reactivate
the problem?
as you see the ucsimm is working under linux-2.0.38...

Thank you and best regards

Yi Peng
pengyi at seiwa-ele.co.jp

----- Original Message -----
From: "Menie, Georges" <gmenie at akamai.com>
To: <uclinux-dev at uclinux.org>
Sent: Tuesday, April 02, 2002 7:08 PM
Subject: [uClinux-dev] 68*328 time patch


> Here is a patch which reactivate the lost_ticks
> computation for the m68knommu arch. The patch should be
> run against the linux-2.4.x module in CVS.
> The lost ticks calculation allow for a more accurate
> gettimeofday function call.
>
> Greg, David, could you apply it ?
>
> Regards,
> Georges
>
>

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From hamilton at SEDSystems.ca  Tue Apr  2 09:42:13 2002
From: hamilton at SEDSystems.ca (Kendrick Hamilton)
Date: Tue, 2 Apr 2002 08:42:13 -0600 (CST)
Subject: [uClinux-dev] M68360: IRQ 68 from ttyS is not replaceable, LSR
  security check engaged
In-Reply-To: <3CA91155.C07F8732@tele-ip.com>
Message-ID: <Pine.LNX.4.44.0204020841090.2275-100000@sw-55.sedsystems.ca>


Hi,
	I found a bug in my serial driver (bad me). It occurs when you you
tell the serial driver to send breaks. I am working on fixing it now. I
will have a patch shortly.


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

On Tue, 2 Apr 2002, Bruce Paterson wrote:

> Joachim Schweidler wrote:
> >
> > Hi all,
> >
> > some months ago I got uclinux 2.0.38 up and running on an 68EN360 Board
> > (SBS
> > V360). Now I upgraded to Kernel 2.4.x and the kernel starts and comes till
>
> I was working on this recently, but at present I've been moved to
> something else so haven't
> had the time to get back to it.
> I sent in patches to convert the 2.4.x to use Kendrik's newer serial
> driver (as written for 2.0.38),
> but against an earlier snapshot rather than cvs, so I don't know the
> current status of the cvs
> version.
> I also modified the ethernet driver for the EN360 to be compatible with
> the way the 2.4.x kernel
> works, but haven't had a chance to debug it (it's not all the way
> there).
>
> Apologies I haven't managed to get things to a stable state, but the
> ethernet bsp stuff in 2.4.x was
> plain broken before, so starting from where I left off would save you a
> lot of time !
>
> Kendrik's serial driver dumps the old uart.c and enet.c files, so if
> you're still using these
> you have the old one.
>
> --
> Cheers,
> Bruce
> -------------------------------------------------------------------
> This email and any files transmitted with it are confidential and
> intended solely for the use of the individual or entity to whom
> they are addressed. If you have received this email in error please
> notify the system manager.
>
>     /\\\/\\\/\\\    /   /      Bruce Paterson
>    /  \\\ \\\ \\\  /   /    Senior Design Engineer
>   /   /\\\/\\\/\\\/   /   87 Peters Ave, Mulgrave, Vic, 3170
>  /   /  \\\ \\\ \\\  /  PO Box 4112, Mulgrave, Vic, 3170, Australia
> /   /    \\\/\\\ \\\/   Ph: +61 3 8561 4232   Fax: +61 3 9560 9055
>       Tele-IP Ltd.      Email: bruce at tele-ip.com    Icq: #32015991
>                         WWW:   http://www.tele-ip.com       VK3TJN
> -------------------------------------------------------------------
> This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/
>

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From gerg at snapgear.com  Tue Apr  2 10:37:51 2002
From: gerg at snapgear.com (Greg Ungerer)
Date: Wed, 03 Apr 2002 01:37:51 +1000
Subject: [uClinux-dev] Re: User Application: Permission denied.
References: <010801c1d670$19399590$2200a8c0@flamenco> <3CA47509.3000209@snapgear.com> <011201c1da23$17305ac0$2200a8c0@flamenco>
Message-ID: <3CA9D04F.1070505@snapgear.com>


Hi Usman,

Muhammad Usman Tahir wrote:
> Here are the make commands in the Makefile for my_app in /user. SOURCE has
> the c++ source and OBJ has the object files. This generates my_app (EXEC)
> which I presume is a flat binary. I'm not using CONVERT as I don't have an
> elf image because I used -elf2flt option with linker.
> 
> all: $(EXEC)
> 
> $(EXEC): $(OBJS)
>  $(CC) $(CFLAGS) $(CPPFLAGS) -c $(SOURCE) -lstdc++ -lc -lgcc
>  $(LD) $(LDFLAGS) -elf2flt -o $(EXEC) $(OBJS) $(LDLIBS)

Can you please send the actual output after running make though.
I would like to see what the command line actually being used is.


> I'll try flthdr and get back with more info. Can something be added (or
> removed for that matter) from these make commands to make things a little
> better?

For one thing, most user Makefiles do not directly use ld.
But rather rely on gcc to do the linking stage as well.
So the LDFLAGS is really meant for gcc, not ld.

Unless you correctly set the library path (using -L option)
I suspect you will not be finding stdc++ library either.

What are OBJS and SOURCE set to in your Makefile?
Most user Makefiles in the uClinux snapshots simply use:

     $(EXEC): $(OBJS)
         $(CC) $(LDFLAGS) -o $@ $(OBJS) $(LDLIBS)

You would prabably want something like:

     $(EXEC): $(OBJS)
	$(CC) $(LDFLAGS) -o $@ $(OBJS) $(LIBSTDCPP) $(LDLIBS)

Regards
Greg

------------------------------------------------------------------------
Greg Ungerer  --  Chief Software Wizard        EMAIL:  gerg at snapgear.com
SnapGear                                       PHONE:    +61 7 3279 1822
825 Stanley St,                                  FAX:    +61 7 3279 1820
Woolloogabba, QLD, 4102, Australia               WEB:   www.snapgear.com

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From gerg at snapgear.com  Tue Apr  2 10:55:42 2002
From: gerg at snapgear.com (Greg Ungerer)
Date: Wed, 03 Apr 2002 01:55:42 +1000
Subject: [uClinux-dev] 5307 int vectors 64 - 255 Questions
References: <B8062940F5F9D8469E250780F3D2161807A2A1@usipub.utsci.com>
Message-ID: <3CA9D47E.8050809@snapgear.com>


Hi Roger,

Roger Thornblad wrote:
> I've been reading the motorola manuals for the 5307.  The exception
> processing section shows user defined interrupts from 64-255.
> 
> Does anyone know of an example of how you might use these? 

Any peripheral device that is capable of generating interrupt
vectors can use these.


> We've looked at the onboard serial port code and how it uses 224-225.
> However, these interrupts still rely on the onboard UARTS to generate the
> interrupt.

They do, but the UARTS could be on a separate die, and the
vector mechanism would work just the same.


> I know how to add the vector to the table and register the interrupt etc
> etc.   The only thing I haven't been able to find is the means to initiate
> the handler function.

This is really done at the hardware level. The peripheral device
needs to be capable of driving an interrupt vector on the bus
(when asked to do so by the CPU!).

Regards
Greg

------------------------------------------------------------------------
Greg Ungerer  --  Chief Software Wizard        EMAIL:  gerg at snapgear.com
SnapGear                                       PHONE:    +61 7 3279 1822
825 Stanley St,                                  FAX:    +61 7 3279 1820
Woolloogabba, QLD, 4102, Australia               WEB:   www.snapgear.com

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From gerg at snapgear.com  Tue Apr  2 11:08:42 2002
From: gerg at snapgear.com (Greg Ungerer)
Date: Wed, 03 Apr 2002 02:08:42 +1000
Subject: [uClinux-dev] 68*328 time patch
References: <D447D880267ED5118F2A00D0B74A108B11E388@munich-ex1.munich.akamai.com>
Message-ID: <3CA9D78A.9060709@snapgear.com>


Hi Georges,

Menie, Georges wrote:
> Here is a patch which reactivate the lost_ticks
> computation for the m68knommu arch. The patch should be
> run against the linux-2.4.x module in CVS.
> The lost ticks calculation allow for a more accurate
> gettimeofday function call.
> 
> Greg, David, could you apply it ?

Applied.

Regards
Greg

------------------------------------------------------------------------
Greg Ungerer  --  Chief Software Wizard        EMAIL:  gerg at snapgear.com
SnapGear                                       PHONE:    +61 7 3279 1822
825 Stanley St,                                  FAX:    +61 7 3279 1820
Woolloogabba, QLD, 4102, Australia               WEB:   www.snapgear.com

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From julienb at actimage.fr  Tue Apr  2 11:44:49 2002
From: julienb at actimage.fr (Julien Boibessot)
Date: Tue, 2 Apr 2002 18:44:49 +0200
Subject: [uClinux-dev] 5272C3 dbug binaries
References: <D447D880267ED5118F2A00D0B74A108B11E388@munich-ex1.munich.akamai.com> <3CA9D78A.9060709@snapgear.com>
Message-ID: <001201c1da65$b45bc630$8947ec95@bruker.fr>

Hello !

does anyone can email me a binary file of dbug for Motorola/Tarifa 5272C3
devt board please ??
I've just killed mine...:-((

and I don't know how to regenerate it...

thanks
Julien


This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From RThornblad at utsci.com  Tue Apr  2 17:45:23 2002
From: RThornblad at utsci.com (Roger Thornblad)
Date: Tue, 2 Apr 2002 15:45:23 -0700 
Subject: [uClinux-dev] 5307 int vectors 64 - 255 Questions
Message-ID: <B8062940F5F9D8469E250780F3D2161807A2A5@usipub.utsci.com>

Greg, Kendrick,

Thanks for the responses.

What you're saying makes perfect sense.  

What I was *hoping* for was a way to generate the interrupt with a software
call.  I was looking at it kind of like the bottom half portions of drivers.
Have a simple ISR that handles the H/W IRQ line, figure out who it is and
then initiate the corresponding user int.  That way I could have identical
code running for (n) devices all with unique vectors and it's all under S/W
control (ie no H/W changes or mods).

The up side is we have to mod the H/W anyway so we will make the necessary
changes to let H/W provide the vector.  

The down side is it's going to take a little bit longer to get there,,,, so
it goes.

Later,

Roger.

-----Original Message-----
From: Greg Ungerer [mailto:gerg at snapgear.com]
Sent: Tuesday, April 02, 2002 8:56 AM
To: uclinux-dev at uclinux.org
Subject: Re: [uClinux-dev] 5307 int vectors 64 - 255 Questions



Hi Roger,

Roger Thornblad wrote:
> I've been reading the motorola manuals for the 5307.  The exception
> processing section shows user defined interrupts from 64-255.
> 
> Does anyone know of an example of how you might use these? 

Any peripheral device that is capable of generating interrupt
vectors can use these.


> We've looked at the onboard serial port code and how it uses 224-225.
> However, these interrupts still rely on the onboard UARTS to generate the
> interrupt.

They do, but the UARTS could be on a separate die, and the
vector mechanism would work just the same.


> I know how to add the vector to the table and register the interrupt etc
> etc.   The only thing I haven't been able to find is the means to initiate
> the handler function.

This is really done at the hardware level. The peripheral device
needs to be capable of driving an interrupt vector on the bus
(when asked to do so by the CPU!).

Regards
Greg

------------------------------------------------------------------------
Greg Ungerer  --  Chief Software Wizard        EMAIL:  gerg at snapgear.com
SnapGear                                       PHONE:    +61 7 3279 1822
825 Stanley St,                                  FAX:    +61 7 3279 1820
Woolloogabba, QLD, 4102, Australia               WEB:   www.snapgear.com

This message resent by the uclinux-dev at uclinux.org list server
http://www.uClinux.org/
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From bruce at tele-ip.com  Tue Apr  2 19:15:03 2002
From: bruce at tele-ip.com (Bruce Paterson)
Date: Wed, 03 Apr 2002 10:15:03 +1000
Subject: [uClinux-dev] 5307 int vectors 64 - 255 Questions
References: <B8062940F5F9D8469E250780F3D2161807A2A1@usipub.utsci.com> <3CA9D47E.8050809@snapgear.com>
Message-ID: <3CAA4987.987E0416@tele-ip.com>

Greg Ungerer wrote:
> 
> > Does anyone know of an example of how you might use these?
> 
> Any peripheral device that is capable of generating interrupt
> vectors can use these.

> This is really done at the hardware level. The peripheral device
> needs to be capable of driving an interrupt vector on the bus
> (when asked to do so by the CPU!).

Most periperals which can generate a vector have an Interrupt Vector
Register (IVR). You program this (often 8 bit) register with the base
vector you want for the device. The device may generate more than 1
vector
by modifying the lower bits for different interrupt reasons (usually
this
behaviour too is configurable).

-- 
Cheers,
Bruce
-------------------------------------------------------------------
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom
they are addressed. If you have received this email in error please
notify the system manager.

    /\\\/\\\/\\\    /   /      Bruce Paterson          
   /  \\\ \\\ \\\  /   /    Senior Design Engineer
  /   /\\\/\\\/\\\/   /   87 Peters Ave, Mulgrave, Vic, 3170
 /   /  \\\ \\\ \\\  /  PO Box 4112, Mulgrave, Vic, 3170, Australia
/   /    \\\/\\\ \\\/   Ph: +61 3 8561 4232   Fax: +61 3 9560 9055
      Tele-IP Ltd.      Email: bruce at tele-ip.com    Icq: #32015991
                        WWW:   http://www.tele-ip.com       VK3TJN
-------------------------------------------------------------------
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From davidm at snapgear.com  Tue Apr  2 19:45:56 2002
From: davidm at snapgear.com (David McCullough)
Date: Wed, 3 Apr 2002 10:45:56 +1000
Subject: [uClinux-dev] v850 patch
In-Reply-To: <buolmc6cu5p.fsf@mcspd15.ucom.lsi.nec.co.jp>; from miles@lsi.nec.co.jp on Tue, Apr 02, 2002 at 06:43:46PM +0900
References: <buolmc6cu5p.fsf@mcspd15.ucom.lsi.nec.co.jp>
Message-ID: <20020403104556.A20517@beast.internal.moreton.com.au>


Jivin Miles Bader lays it down ...
> Hi, could you apply this patch:

Applied,

Cheers,
Davidm


-- 
David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
davidm at snapgear.com  Fx: +61 7 3891 3630  825 Stanley St., W'gabba QLD 4102, Oz
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From tczhao at linpus.com.tw  Tue Apr  2 20:30:44 2002
From: tczhao at linpus.com.tw (zhaotc)
Date: Wed, 3 Apr 2002 09:30:44 +0800
Subject: [uClinux-dev] uClinux porting of MIPS
In-Reply-To: <3CA9D04F.1070505@snapgear.com>
References: <010801c1d670$19399590$2200a8c0@flamenco> <011201c1da23$17305ac0$2200a8c0@flamenco> <3CA9D04F.1070505@snapgear.com>
Message-ID: <02040309304402.01046@localhost.localdomain>

Hi, all
	I am now working for a MIPS porting of uClinux 2.4.17. I wander that if 
anybody else has done the same job too. Now I try to run a userland program 
in my uCLinux/MIPS embedded box. when I try to open a file by 

open("/dev/console", O_RDWR, 0 )

it jump to void fpu_emulator_init_fpu(void) of MIPS
and print:

Algorithmics/MIPS FPU Emulator v1.5

Who can tell me why?

Zhao, Tiecheng
Linpus, Shanghai
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From hamilton at SEDSystems.ca  Tue Apr  2 20:38:46 2002
From: hamilton at SEDSystems.ca (Kendrick Hamilton)
Date: Tue, 2 Apr 2002 19:38:46 -0600 (CST)
Subject: [uClinux-dev] 5307 int vectors 64 - 255 Questions
In-Reply-To: <B8062940F5F9D8469E250780F3D2161807A2A5@usipub.utsci.com>
Message-ID: <Pine.LNX.4.44.0204021936410.1262-100000@sw-55.sedsystems.ca>

Once you get the hardware mods done to support devices generating there
interrupts, then this is exactly what the operating system does for you.
Until then, you could setup some  code to create a table with interrupt
data and function pointers.


On Tue, 2 Apr 2002, Roger Thornblad wrote:

> Greg, Kendrick,
>
> Thanks for the responses.
>
> What you're saying makes perfect sense.
>
> What I was *hoping* for was a way to generate the interrupt with a software
> call.  I was looking at it kind of like the bottom half portions of drivers.
> Have a simple ISR that handles the H/W IRQ line, figure out who it is and
> then initiate the corresponding user int.  That way I could have identical
> code running for (n) devices all with unique vectors and it's all under S/W
> control (ie no H/W changes or mods).
>
> The up side is we have to mod the H/W anyway so we will make the necessary
> changes to let H/W provide the vector.
>
> The down side is it's going to take a little bit longer to get there,,,, so
> it goes.
>
> Later,
>
> Roger.
>
> -----Original Message-----
> From: Greg Ungerer [mailto:gerg at snapgear.com]
> Sent: Tuesday, April 02, 2002 8:56 AM
> To: uclinux-dev at uclinux.org
> Subject: Re: [uClinux-dev] 5307 int vectors 64 - 255 Questions
>
>
>
> Hi Roger,
>
> Roger Thornblad wrote:
> > I've been reading the motorola manuals for the 5307.  The exception
> > processing section shows user defined interrupts from 64-255.
> >
> > Does anyone know of an example of how you might use these?
>
> Any peripheral device that is capable of generating interrupt
> vectors can use these.
>
>
> > We've looked at the onboard serial port code and how it uses 224-225.
> > However, these interrupts still rely on the onboard UARTS to generate the
> > interrupt.
>
> They do, but the UARTS could be on a separate die, and the
> vector mechanism would work just the same.
>
>
> > I know how to add the vector to the table and register the interrupt etc
> > etc.   The only thing I haven't been able to find is the means to initiate
> > the handler function.
>
> This is really done at the hardware level. The peripheral device
> needs to be capable of driving an interrupt vector on the bus
> (when asked to do so by the CPU!).
>
> Regards
> Greg
>
> ------------------------------------------------------------------------
> Greg Ungerer  --  Chief Software Wizard        EMAIL:  gerg at snapgear.com
> SnapGear                                       PHONE:    +61 7 3279 1822
> 825 Stanley St,                                  FAX:    +61 7 3279 1820
> Woolloogabba, QLD, 4102, Australia               WEB:   www.snapgear.com
>
> This message resent by the uclinux-dev at uclinux.org list server
> http://www.uClinux.org/
> This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/
>

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From tczhao at linpus.com.tw  Tue Apr  2 23:56:10 2002
From: tczhao at linpus.com.tw (zhaotc)
Date: Wed, 3 Apr 2002 12:56:10 +0800
Subject: [uClinux-dev] uClinux porting of MIPS
In-Reply-To: <3CAA69FB.F60D8AB5@analog.com>
References: <010801c1d670$19399590$2200a8c0@flamenco> <02040309304402.01046@localhost.localdomain> <3CAA69FB.F60D8AB5@analog.com>
Message-ID: <02040312561000.02557@localhost.localdomain>

On Wednesday 03 April 2002 10:33 am, you wrote:
>
> I've been working on the same. I haven't made anything available yet
> to the community, because, well, the shell isn't stable. How far along
> have you gotten?
>
> Note that there's also MIPS support in the RTAI patches, and some
> people have claimed that the 2.4.17-uC distro already supports
> MMU-less MIPS machines. However, I haven't tried doing anything with
> RTAI yet, and have yet to find any clear evidence regarding any other
> support in the 2.4.17-uC code.

	Then, where I can down load RTAI pathes? I now find my porting of uClinux 
run untable sometime.  May be I can lean something from it. Can you tell me 
which processor you are porting on? My is AR2000 of ARTi. I bet you must know 
nothing about it. It is R3000.

Zhao Tiecheng
Linpus, Shanghai
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From Joachim.Schweidler at gmx.de  Wed Apr  3 01:55:52 2002
From: Joachim.Schweidler at gmx.de (Joachim Schweidler)
Date: Wed, 3 Apr 2002 08:55:52 +0200 (MEST)
Subject: [uClinux-dev] M68360: m68k_fork
Message-ID: <3078.1017816952@www33.gmx.net>

Hi,

I had a problem when starting init. I always got the error "init: fork
failed". After several hours I found that in m68k_fork "do_fork" is commented out
if there is no mmu. After removing the ifdef everything seems to work fine.
Whats the reason for commenting things out?

Joe

asmlinkage int m68k_fork(struct pt_regs *regs)
{
#ifdef NO_MM
	/* fork almost works,  enough to trick you into looking elsewhere :-( */
	return(-EINVAL);
#else
	return do_fork(SIGCHLD, rdusp(), regs, 0);
#endif
}


-- 
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From mt_wong at hongkong.com  Wed Apr  3 03:00:39 2002
From: mt_wong at hongkong.com (mt_wong at hongkong.com)
Date: Wed, 3 Apr 2002 16:00:39 +0800 (CST)
Subject: [uClinux-dev] Timer & interrupts
Message-ID: <A8979596839960.06873@mail0.hongkong.com>

Hello,

    I'm new to uCSimm, I have some problem concerning the timer and the interrupts.

    My problem is, I would like to get a clock signal from TI/O input and then count it. from the datasheets, it mentions that the timer can generate an interrupt. But I'm not familiar with interrupts on uClinux, could any one kindly show me some examples?

--
Edward Wong
----------------------------------------------
 ?w??????HongKong.com?l???t?? 
 Thank you for using hongkong.com Email system
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From eric.bosch at fourtress.nl  Wed Apr  3 03:38:15 2002
From: eric.bosch at fourtress.nl (Eric Bosch (Fourtress))
Date: Wed, 3 Apr 2002 10:38:15 +0200
Subject: [uClinux-dev] Network problems (I want to connect my host computer to uCsimm)
Message-ID: <OHEGKBKJNDMIKNAMMKBMOEDBCAAA.eric.bosch@fourtress.nl>

Hi all,

I want to make a NFS connection with my 68EZ328 board, but I can't ping it.
My computer has a crossover patch cable and a 3COM 3x59x network card. The
operating system is Linux Mandrake 8.1. (I can't use the serial connection,
because I set up a wrong environment variable in the uCsimm, so I must
connect by ethernet!)

The IP-address of the target is 192.168.1.200
The IP-address of the host computer is 192.168.1.11

The content of the /etc/exports file is:

 /home/eric/uclinux 192.168.1.200
 /home/eric/uclinux 192.168.1.11

The content of the /etc/hosts file is:

192.168.1.11    localhost.localdomain    localhost
192.168.1.200   uclinux.localdomain      uClinux

#loopback address
127.0.0.1       localhost.localdomain    localhost

The content of the /etc/hosts.allow file is:

portmap: 192.168.1.200
lockd: 192.168.1.200
rquotad: 192.168.1.200
statd: 192.168.1.200
mountd: 192.168.1.200

The content of the /etc/hosts.deny file is:

portmap:ALL

When I execute the command ifconfig eth0 the following information appears:

eth0    Link endcap: Ethernet    HWaddr    00:04:76:26:91:12
        inet addr:192.168.1.11   Bcast:192.168.1.255 Mask:255.255.255.0
        UP BROADCAST RUNNING MULTICAST MTU:1500     Metric:1
        RX packets:0 errors:0 dropped:0 overruns:0 frame:0
        TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
        collisions:0 txqueuelen:100
           ...
           ...

When I try to ping (ping 192.168.1.200) the target from the host computer,
the following message appears:

Destination Host Unreachable

Can anyone help me to solve my problem. I'am a newbie!

Thanks,

Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20020403/a7ce6d66/attachment.html>

From chri at infis.univ.trieste.it  Wed Apr  3 05:13:17 2002
From: chri at infis.univ.trieste.it (Christian Pellegrin)
Date: Wed, 3 Apr 2002 12:13:17 +0200 (CEST)
Subject: [uClinux-dev] Network problems (I want to connect my host computer
 to uCsimm)
In-Reply-To: <OHEGKBKJNDMIKNAMMKBMOEDBCAAA.eric.bosch@fourtress.nl>
Message-ID: <Pine.LNX.4.44.0204031210210.2812-100000@sole.infis.univ.trieste.it>

On Wed, 3 Apr 2002, Eric Bosch (Fourtress) wrote:

> operating system is Linux Mandrake 8.1. (I can't use the serial connection,
> because I set up a wrong environment variable in the uCsimm, so I must
> connect by ethernet!)
> 

AFAIK (basic uCsimm config I played with some time ago) you have to be on
serial console to type "go" to start linux and have networking. But 
hopefully I could be wrong :-)

Bye!

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From davidm at snapgear.com  Wed Apr  3 05:34:09 2002
From: davidm at snapgear.com (David McCullough)
Date: Wed, 3 Apr 2002 20:34:09 +1000
Subject: [uClinux-dev] M68360: m68k_fork
In-Reply-To: <3078.1017816952@www33.gmx.net>; from Joachim.Schweidler@gmx.de on Wed, Apr 03, 2002 at 08:55:52AM +0200
References: <3078.1017816952@www33.gmx.net>
Message-ID: <20020403203409.A27241@beast.internal.moreton.com.au>


Jivin Joachim Schweidler lays it down ...
> Hi,
> 
> I had a problem when starting init. I always got the error "init: fork
> failed". After several hours I found that in m68k_fork "do_fork" is commented out
> if there is no mmu. After removing the ifdef everything seems to work fine.
> Whats the reason for commenting things out?

Because it doesn't work :-)

For a NO_MM linux system you need to use vfork(),  you cannot use fork().
There are a lot of reasons why which have been discussed on this list in the
past.  Look through the archives if you want to know more,

Cheers,
Davidm

-- 
David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
davidm at snapgear.com  Fx: +61 7 3891 3630  825 Stanley St., W'gabba QLD 4102, Oz
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From fskivee at skynet.be  Wed Apr  3 05:08:25 2002
From: fskivee at skynet.be (Fabian =?iso-8859-1?q?Skiv=E9e?=)
Date: Wed, 3 Apr 2002 12:08:25 +0200
Subject: [uClinux-dev] Fwd: Crystal frequency ?
Message-ID: <200204031103.g33B35D09788@excalibur.skynet.be>


Hello,

	Which crystal frequency is used in the palm ? I have a palm m500, so I read
the MC68VZ328 datasheet and it say that the possible crystal frequencies are
32,768 Khz or 38,4 kHz. The frequency which is applied to the EXTAL pin is
given by :

	Cl = Cstray + Cdbvz + (C1*C2) / (C1 + C2)

	Could you tell me the values of the capacitances in the palm ? If someone
knows the value for a palm III and Palm Vx, I'm also interested.

	My aim is to configure the CGM to have a precise frequency and to use a
timer to have a periodical signal every 100 ms.

	Can someone help me to find these precise values ?

	Thanks

	Fabian Skiv?e

--

Skiv?e Fabian
[a] rue Petite Spinette 8, 4630 Soumagne, Belgium
[t] + 32 (0) 4 377 23 76
[g] + 32 (0) 498 62 47 03 (direct)
[e] fskivee at skynet.be
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From heiko.degenhardt at sentec-elektronik.de  Wed Apr  3 05:48:50 2002
From: heiko.degenhardt at sentec-elektronik.de (Heiko Degenhardt)
Date: Wed, 3 Apr 2002 12:48:50 +0200
Subject: [uClinux-dev] Network problems (I want to connect my host computer to uCsimm)
In-Reply-To: <OHEGKBKJNDMIKNAMMKBMOEDBCAAA.eric.bosch@fourtress.nl>; from eric.bosch@fourtress.nl on Wed, Apr 03, 2002 at 10:38:15AM +0200
References: <OHEGKBKJNDMIKNAMMKBMOEDBCAAA.eric.bosch@fourtress.nl>
Message-ID: <20020403124850.A22264@www2.sentec-elektronik.de>

Hi Eric, 

* On Wed, Apr 03, 2002 at 10:38:15AM +0200, Eric Bosch (Fourtress) wrote:
> I want to make a NFS connection with my 68EZ328 board, but I can't ping it.
> My computer has a crossover patch cable and a 3COM 3x59x network card.

The cable is ok? You have tested it with another pc?

> operating system is Linux Mandrake 8.1. (I can't use the serial connection,
> because I set up a wrong environment variable in the uCsimm, so I must
> connect by ethernet!)

Ok. But has has nothing to do with NFS, imho.
You just need a working tcp/ip connection, that means ping
has to work, and then you can use telnet to connect.
But we can look after the NFS problem, if you want:

> The IP-address of the target is 192.168.1.200
> The IP-address of the host computer is 192.168.1.11
> 
> The content of the /etc/exports file is:
> 
>  /home/eric/uclinux 192.168.1.200

That should be enaugh. Here (on my SuSE 7.2 box) I have:
/home/hede/uClinux \
 192.168.100.2(rw)

> The content of the /etc/hosts file is:
> 
> 192.168.1.11    localhost.localdomain    localhost
> 192.168.1.200   uclinux.localdomain      uClinux
> 
> #loopback address
> 127.0.0.1       localhost.localdomain    localhost

That seems to be ok, but should have no effekt on NFS
(because you give the IPs in /etc/exports).

> The content of the /etc/hosts.allow file is:
> ...
> The content of the /etc/hosts.deny file is:

I don't use any of that files. May be you should try
it without them at first...

> portmap:ALL

Imho this would deny every host that tries to use 
your portmapper. That's imho not what you want.

Ok. But you problem seems to be the basic tcp/ip setup.
 
> When I execute the command ifconfig eth0 the following information appears:
> 
> eth0    Link endcap: Ethernet    HWaddr    00:04:76:26:91:12
>         inet addr:192.168.1.11   Bcast:192.168.1.255 Mask:255.255.255.0
>         UP BROADCAST RUNNING MULTICAST MTU:1500     Metric:1
>         RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>         TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
>         collisions:0 txqueuelen:100
>            ...
>            ...

Ok.
Your client is running? It has his correct ip and netmask
(192.168.1.200/255.255.255.0)?

> When I try to ping (ping 192.168.1.200) the target from the host computer,
> the following message appears:
> 
> Destination Host Unreachable

Hm.
Could you please give me the output of the command
"route -n" on your host computer?
Could you install tcpdump, and see what is happening
on the interface? For me it looks as if your client
isn't set up correctly for tcp/ip.

As I said: You need ping to work to get the opportunity
to log in (for instance with telnet). To get ping both
sides have to be set up correct. You don't need NFS in
that stage, imho.

If you have more questions, please let me know.
Rgds.
Heiko.

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From Joachim.Schweidler at gmx.de  Wed Apr  3 06:53:43 2002
From: Joachim.Schweidler at gmx.de (Joachim Schweidler)
Date: Wed, 3 Apr 2002 13:53:43 +0200 (MEST)
Subject: [uClinux-dev] M68360: m68k_fork
References: <20020403203409.A27241@beast.internal.moreton.com.au>
Message-ID: <14590.1017834823@www57.gmx.net>

I downloaded the 2.4.x tree from CVS some weeks ago and it seems that in the
version I downloaded always calls the fork NOT vfork. So I changed the entry
for sys_fork in entry.S to sys_vfork and everything seems to work. Is there
a reason why fork is called in there or is it a bug ?

regards,
Joe

********************************
.data
ALIGN
SYMBOL_NAME_LABEL(sys_call_table)
	.long SYMBOL_NAME(sys_ni_syscall)	/* 0  -  old "setup()" system call*/
	.long SYMBOL_NAME(sys_exit)
	.long SYMBOL_NAME(sys_fork)   <<<---- 
	.long SYMBOL_NAME(sys_read)
...

********************************


> 
> Jivin Joachim Schweidler lays it down ...
> > Hi,
> > 
> > I had a problem when starting init. I always got the error "init: fork
> > failed". After several hours I found that in m68k_fork "do_fork" is
> commented out
> > if there is no mmu. After removing the ifdef everything seems to work
> fine.
> > Whats the reason for commenting things out?
> 
> Because it doesn't work :-)
> 
> For a NO_MM linux system you need to use vfork(),  you cannot use fork().
> There are a lot of reasons why which have been discussed on this list in
> the
> past.  Look through the archives if you want to know more,
> 
> Cheers,
> Davidm
> 
> -- 
> David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
> davidm at snapgear.com  Fx: +61 7 3891 3630  825 Stanley St., W'gabba QLD
> 4102, Oz
> This message resent by the uclinux-dev at uclinux.org list server
> http://www.uClinux.org/
> 

-- 
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From eric.bosch at fourtress.nl  Wed Apr  3 07:31:27 2002
From: eric.bosch at fourtress.nl (Eric Bosch (Fourtress))
Date: Wed, 3 Apr 2002 14:31:27 +0200
Subject: [uClinux-dev] Network problems (I want to connect my host computer to uCsimm)
In-Reply-To: <20020403124850.A22264@www2.sentec-elektronik.de>
Message-ID: <OHEGKBKJNDMIKNAMMKBMKEDDCAAA.eric.bosch@fourtress.nl>

Thanks Heiko for your answer,

The output of the route -n command is:

Destination    Gateway    Genmask        Flags Metric    Ref Use  Iface
192.168.1.0    0.0.0.0    255.255.255.0    U    0        0    0    eth0
127.0.0.0      0.0.0.0    255.0.0.0        U    0        0    0    lo

My client is a uc68EZ328 Microcontroller module and it has a serial and a
ethernet connection. I can't use this serial connection, because I set a
environment variable with the wrong value. Now is the serial port blocked
and so I must establish the ethernet connection to set the environment
variable with the right value. It is important for me to establish this
ethernet connection.

Ok, I have installed tcpdump and execute the command and it says:

tcpdump: listening on eth0

That is the only information I become from tcpdump, so my tcp/ip connection
isn't OK !

Do you have any suggestions or more entry's to solve this problem?

I hope that you can help me?

Thanks, Eric

-----Oorspronkelijk bericht-----
Van: owner-uclinux-dev at uclinux.org
[mailto:owner-uclinux-dev at uclinux.org]Namens Heiko Degenhardt
Verzonden: woensdag 3 april 2002 12:49
Aan: Uclinux-Dev at Uclinux. Org
Onderwerp: Re: [uClinux-dev] Network problems (I want to connect my host
computer to uCsimm)


Hi Eric,

* On Wed, Apr 03, 2002 at 10:38:15AM +0200, Eric Bosch (Fourtress) wrote:
> I want to make a NFS connection with my 68EZ328 board, but I can't ping
it.
> My computer has a crossover patch cable and a 3COM 3x59x network card.

The cable is ok? You have tested it with another pc?

> operating system is Linux Mandrake 8.1. (I can't use the serial
connection,
> because I set up a wrong environment variable in the uCsimm, so I must
> connect by ethernet!)

Ok. But has has nothing to do with NFS, imho.
You just need a working tcp/ip connection, that means ping
has to work, and then you can use telnet to connect.
But we can look after the NFS problem, if you want:

> The IP-address of the target is 192.168.1.200
> The IP-address of the host computer is 192.168.1.11
>
> The content of the /etc/exports file is:
>
>  /home/eric/uclinux 192.168.1.200

That should be enaugh. Here (on my SuSE 7.2 box) I have:
/home/hede/uClinux \
 192.168.100.2(rw)

> The content of the /etc/hosts file is:
>
> 192.168.1.11    localhost.localdomain    localhost
> 192.168.1.200   uclinux.localdomain      uClinux
>
> #loopback address
> 127.0.0.1       localhost.localdomain    localhost

That seems to be ok, but should have no effekt on NFS
(because you give the IPs in /etc/exports).

> The content of the /etc/hosts.allow file is:
> ...
> The content of the /etc/hosts.deny file is:

I don't use any of that files. May be you should try
it without them at first...

> portmap:ALL

Imho this would deny every host that tries to use
your portmapper. That's imho not what you want.

Ok. But you problem seems to be the basic tcp/ip setup.

> When I execute the command ifconfig eth0 the following information
appears:
>
> eth0    Link endcap: Ethernet    HWaddr    00:04:76:26:91:12
>         inet addr:192.168.1.11   Bcast:192.168.1.255 Mask:255.255.255.0
>         UP BROADCAST RUNNING MULTICAST MTU:1500     Metric:1
>         RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>         TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
>         collisions:0 txqueuelen:100
>            ...
>            ...

Ok.
Your client is running? It has his correct ip and netmask
(192.168.1.200/255.255.255.0)?

> When I try to ping (ping 192.168.1.200) the target from the host computer,
> the following message appears:
>
> Destination Host Unreachable

Hm.
Could you please give me the output of the command
"route -n" on your host computer?
Could you install tcpdump, and see what is happening
on the interface? For me it looks as if your client
isn't set up correctly for tcp/ip.

As I said: You need ping to work to get the opportunity
to log in (for instance with telnet). To get ping both
sides have to be set up correct. You don't need NFS in
that stage, imho.

If you have more questions, please let me know.
Rgds.
Heiko.

This message resent by the uclinux-dev at uclinux.org list server
http://www.uClinux.org/

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From davidm at snapgear.com  Wed Apr  3 07:54:41 2002
From: davidm at snapgear.com (David McCullough)
Date: Wed, 3 Apr 2002 22:54:41 +1000
Subject: [uClinux-dev] M68360: m68k_fork
In-Reply-To: <14590.1017834823@www57.gmx.net>; from Joachim.Schweidler@gmx.de on Wed, Apr 03, 2002 at 01:53:43PM +0200
References: <20020403203409.A27241@beast.internal.moreton.com.au> <14590.1017834823@www57.gmx.net>
Message-ID: <20020403225441.B30568@beast.internal.moreton.com.au>


Jivin Joachim Schweidler lays it down ...
> I downloaded the 2.4.x tree from CVS some weeks ago and it seems that in the
> version I downloaded always calls the fork NOT vfork. So I changed the entry
> for sys_fork in entry.S to sys_vfork and everything seems to work. Is there
> a reason why fork is called in there or is it a bug ?

Ok,  it sounds like you are running apps compiled for 2.0.

Under 2.0,  there was no vfork() system call so uClinux-2.0.x changed the
behaviour of fork() to be vfork().  Confusing but it worked.

Under 2.4 there is a vfork() system call.  Having fork() act like vfork()
was considered a bad idea,  so fork() was disabled to make it obvious that it
should not be used and that you needed to use vfork().

Most of the recent apps/libs deal with this fine.  You should look at the
uClinux-dist that supports both kernels with libs and apps all included.

Cheers,
Davidm

-- 
David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
davidm at snapgear.com  Fx: +61 7 3891 3630  825 Stanley St., W'gabba QLD 4102, Oz
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From Joachim.Schweidler at gmx.de  Wed Apr  3 08:57:20 2002
From: Joachim.Schweidler at gmx.de (Joachim Schweidler)
Date: Wed, 3 Apr 2002 15:57:20 +0200 (MEST)
Subject: [uClinux-dev] M68360: m68k_fork
References: <20020403225441.B30568@beast.internal.moreton.com.au>
Message-ID: <32362.1017842240@www57.gmx.net>

OK, sorry for asking all this questions that might have been asked before,
but as you said it's a little bit confusing. 

Thank you very much for the help,
Joe

> 
> Jivin Joachim Schweidler lays it down ...
> > I downloaded the 2.4.x tree from CVS some weeks ago and it seems that in
> the
> > version I downloaded always calls the fork NOT vfork. So I changed the
> entry
> > for sys_fork in entry.S to sys_vfork and everything seems to work. Is
> there
> > a reason why fork is called in there or is it a bug ?
> 
> Ok,  it sounds like you are running apps compiled for 2.0.
> 
> Under 2.0,  there was no vfork() system call so uClinux-2.0.x changed the
> behaviour of fork() to be vfork().  Confusing but it worked.
> 
> Under 2.4 there is a vfork() system call.  Having fork() act like vfork()
> was considered a bad idea,  so fork() was disabled to make it obvious that
> it
> should not be used and that you needed to use vfork().
> 
> Most of the recent apps/libs deal with this fine.  You should look at the
> uClinux-dist that supports both kernels with libs and apps all included.
> 
> Cheers,
> Davidm
> 
> -- 
> David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
> davidm at snapgear.com  Fx: +61 7 3891 3630  825 Stanley St., W'gabba QLD
> 4102, Oz
> This message resent by the uclinux-dev at uclinux.org list server
> http://www.uClinux.org/
> 

-- 
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From hamilton at SEDSystems.ca  Wed Apr  3 09:44:16 2002
From: hamilton at SEDSystems.ca (Kendrick Hamilton)
Date: Wed, 3 Apr 2002 08:44:16 -0600 (CST)
Subject: [uClinux-dev] M68360: m68k_fork
In-Reply-To: <20020403203409.A27241@beast.internal.moreton.com.au>
Message-ID: <Pine.LNX.4.44.0204030838490.1741-100000@sw-55.sedsystems.ca>

You should check that your library is calling vfork. We had an old version
of the library that would call fork when the user program called vfork.
The library checked to see if the operating system implemented vfork. If
it did not, when the user code called vfork, an actual fork would occur.
The library was not setup correctly so our calls to vfork were calling
fork and not working.
BTW. uClibc used to generate a compiler warning if fork was being used
with uClinux, does it still generate the warning?

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

On Wed, 3 Apr 2002, David McCullough wrote:

>
> Jivin Joachim Schweidler lays it down ...
> > Hi,
> >
> > I had a problem when starting init. I always got the error "init: fork
> > failed". After several hours I found that in m68k_fork "do_fork" is commented out
> > if there is no mmu. After removing the ifdef everything seems to work fine.
> > Whats the reason for commenting things out?
>
> Because it doesn't work :-)
>
> For a NO_MM linux system you need to use vfork(),  you cannot use fork().
> There are a lot of reasons why which have been discussed on this list in the
> past.  Look through the archives if you want to know more,
>
> Cheers,
> Davidm
>
> --
> David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
> davidm at snapgear.com  Fx: +61 7 3891 3630  825 Stanley St., W'gabba QLD 4102, Oz
> This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/
>

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From moh.shiha at ieee.org  Wed Apr  3 10:20:29 2002
From: moh.shiha at ieee.org (Mohamed Ali Shiha)
Date: Wed, 3 Apr 2002 17:20:29 +0200
Subject: [uClinux-dev] ftpd for MC68VZ328
Message-ID: <OE47vGSQb0SulnJ2IKk000164cb@hotmail.com>

Dear all,

does any one has an ftpd server for MC68VZ328 ... ?

Thanks and regards
Mohamed Shiha
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From gmenie at akamai.com  Wed Apr  3 10:28:07 2002
From: gmenie at akamai.com (Menie, Georges)
Date: Wed, 3 Apr 2002 10:28:07 -0500 
Subject: [uClinux-dev] 68*328 time patch
Message-ID: <D447D880267ED5118F2A00D0B74A108B11E399@munich-ex1.munich.akamai.com>

sorry for the late reply...

I am playing around with the time management in uClinux,
I saw that the original 2.4.x kernel did not have an acceptable
accuracy in time management. So far, here is what I did:

1) use a 128Hz timer instead of 100 Hz
the timer 1 setting with de 32768 clock is not able
to give 100 Hz ticks (it can give 99.9 or 100.2 HZ)
this can be achieved by editing
  linux-2.4.x/include/asm-m68knommu/param.h
to define the HZ constant to 128 for your board,
and the file
 linux-2.4.x/arch/m68knommu/platform/*/config.c
to edit the xxx_sched_init as follow (de2 example):

#define CLOCK_COMPARE (32768/HZ)

static void dragen2_sched_init(void (*timer_routine)(int, void *, struct
pt_regs *))
{
	/* disable timer 1 */
	TCTL = 0;

	/* set ISR */
	request_irq(TMR_IRQ_NUM, timer_routine, IRQ_FLG_LOCK, "timer",
NULL);

	/* Restart mode, Enable int, 32KHz */
	TCTL = TCTL_OM | TCTL_IRQEN | TCTL_CLKSOURCE_32KHZ;
	TPRER = 0;
	TCMP = CLOCK_COMPARE-1; 

	/* Enable timer 1 */
	TCTL |= TCTL_TEN;
}

2) there is a function in 2.4.x called gettimeoffset which was
returning 0 all the time in the current tree. this function helps
to keep the internal time up to date by returning the offset in
microsecs from the last clock tick. I did add it to the dragonengine
tree but it should work on any 68*328 platform using timer 1:

static unsigned long dragen2_gettimeoffset(void)
{
	unsigned long ticks, offset = 0;

	ticks = TCN;

	if (ticks > (CLOCK_COMPARE>>1)) {
		/* check for pending interrupt */
		if (ISR & (1<<TMR_IRQ_NUM))
			offset = 1000000/HZ;
	}

	ticks = CLOCK_COMPARE - ticks;
	ticks = (1000000/HZ * ticks) / CLOCK_COMPARE;

	return ticks + offset;
}
don't forget to initialize the mach_gettimeoffset function pointer too.

3) Then I saw that some code related to the gettimeofday syscall
was not activated, this is the lost_ticks modification in the file
linux-2.4.x/arch/m68knommu/kernel/time.c
see the patch I sent earlier named patch-time.txt

only the point 1) could apply for the 2.0.38 kernel, the others
are specific to 2.4.x.

The time of the day has a better accuracy now, the delay is less than
1 sec for 9 hours on my board, but I need to spend more time
to really measure it. I did it by just watching my clock,
and the board was idle most of the time, so it's not a proof.

regards,
Georges


> -----Original Message-----
> From: pengyi [mailto:pengyi at baby.seiwa-ele.co.jp]
> Sent: mardi 2 avril 2002 16:12
> To: gmenie at akamai.com
> Cc: uclinux-dev at uclinux.org
> Subject: Re: [uClinux-dev] 68*328 time patch
> 
> 
> Hi Georges:
>  I am excited to know what you did because I am puzzled about the
> lost_ticks.
> My arch. is ucsimm and would you please tell me what can I do 
> to reactivate
> the problem?
> as you see the ucsimm is working under linux-2.0.38...
> 
> Thank you and best regards
> 
> Yi Peng
> pengyi at seiwa-ele.co.jp
> 
> ----- Original Message -----
> From: "Menie, Georges" <gmenie at akamai.com>
> To: <uclinux-dev at uclinux.org>
> Sent: Tuesday, April 02, 2002 7:08 PM
> Subject: [uClinux-dev] 68*328 time patch
> 
> 
> > Here is a patch which reactivate the lost_ticks
> > computation for the m68knommu arch. The patch should be
> > run against the linux-2.4.x module in CVS.
> > The lost ticks calculation allow for a more accurate
> > gettimeofday function call.
> >
> > Greg, David, could you apply it ?
> >
> > Regards,
> > Georges
> >
> >
> 
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From Kal.Yacoub at Interlogixinc.com  Wed Apr  3 10:55:04 2002
From: Kal.Yacoub at Interlogixinc.com (Kal Yacoub)
Date: Wed, 3 Apr 2002 10:55:04 -0500 
Subject: [uClinux-dev] Example vfork() in the 68K
Message-ID: <2A1845F4CDE8D511B4400090279C703B299800@bctexc10.na.ilxi.net>

Hi,

I need to implement a process that could create three child processes at
different times. Would anyone points me to an example code or send it to me.
I am looking for the recommended way to implement a process that creates
three child process using vfork() and pass parameters to them. Thanks very
much.

Kal Yacoub
Caddx
A division of GE Interlogix, Inc.
791 Park of Commerce Blvd
Boca Raton, FL 33498
(561) 998-6273
kal.yacoub at interlogixinc.com

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From hamilton at SEDSystems.ca  Wed Apr  3 11:19:31 2002
From: hamilton at SEDSystems.ca (Kendrick Hamilton)
Date: Wed, 3 Apr 2002 10:19:31 -0600 (CST)
Subject: [uClinux-dev] Example vfork() in the 68K
In-Reply-To: <2A1845F4CDE8D511B4400090279C703B299800@bctexc10.na.ilxi.net>
Message-ID: <Pine.LNX.4.44.0204031014010.4310-100000@sw-55.sedsystems.ca>

I am currently looking at some code that does exactly that.
This is a c++ program that uses namespaces (that is why I am calling
::vfork and ::execl). All the variables passed into execl are char arrays.
Remeber the first argument to execl is the program to run, the second
argument is argv[0].

char const  sedsystems::sios::sdi::TemperatureSensor::_serialPortFlag[] =
	"-s";
char const  sedsystems::sios::sdi::TemperatureSensor::_FIFOPath[]   =
                    "/var/sios/own/";
char const  sedsystems::sios::sdi::TemperatureSensor::_pollProgram[]    =
                    "/sios/pollsensors";

	EAH_DEBUG("vforking a child");
        _childPID = ::vfork();
        if(_childPID < 0)
        {
            CleanUp();
            EAH_FATAL("Unable to vfork for child.");
        }

        if(_childPID == 0) // in child
        {
            ::execl(_pollProgram, _pollProgram,
                    _debugLevelFlag,    (const char *) eah::errorConfiguration,
                    _pathFlag,          _FIFOPath,
                    _timeOutFlag,       _serialPortTimeOut,
                    _dataRateFlag,      _serialPortDataRate,
                    _serialPortFlag,    _serialPort,
                    NULL);
            ::_exit(-1);
        }
        EAH_DEBUG("Parent program running again, child pid is %d",
		_childPID);




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

On Wed, 3 Apr 2002, Kal Yacoub wrote:

> Hi,
>
> I need to implement a process that could create three child processes at
> different times. Would anyone points me to an example code or send it to me.
> I am looking for the recommended way to implement a process that creates
> three child process using vfork() and pass parameters to them. Thanks very
> much.
>
> Kal Yacoub
> Caddx
> A division of GE Interlogix, Inc.
> 791 Park of Commerce Blvd
> Boca Raton, FL 33498
> (561) 998-6273
> kal.yacoub at interlogixinc.com
>
> This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/
>

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From konnow at web.de  Wed Apr  3 12:55:53 2002
From: konnow at web.de (konnow at web.de)
Date: Wed, 3 Apr 2002 19:55:53 +0200
Subject: [uClinux-dev] status of Net+ARM support?
Message-ID: <200204031755.g33Htnv05808@mailgate5.cinetic.de>

Hi all,

I wonder if someone could shed some light on the status of the Net+ARM support in 
uCLinux? I've found posting on this list (dated back from last summer) mentioning a 
port to 2.4.[46]. However, in the current uClinux distribution (20020306) as well as 
in the CVS I only found Net+ARM support in the 2.0.x trees.

Has the development stopped for this processor? Is anyone actually using it in 
combination with uCLinux? Is there any 2.4 code available elsewhere or is 2.0.x the 
only way to go? Please, point me in the right direction to start with.

Many thanks in advance.

Konrad

______________________________________________________________________________
100 MB gute Gr?nde! Jetzt anmelden und FreeMail-Speicher erweitern f?r
Sprach-, Fax- und Mailnachrichten unter http://club.web.de/?mc=021103

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From Subashk at ami.com  Wed Apr  3 13:56:43 2002
From: Subashk at ami.com (Subash Kalbarga)
Date: Wed, 3 Apr 2002 13:56:43 -0500 
Subject: [uClinux-dev] External 16550 UART on a coldifre 5272 based board
Message-ID: <8CCBDD5583C50E4196F012E79439B45C364644@atl-ms1.megatrends.com>

Hi all,
 
I have a coldfire based board(5272) but we have added an external UART
(16550) to the board.
 
What would the best approach be for getting a serial driver attach to this
 
I know that the Internal UART of the coldfire differs significantly from the
standard 16550.
 
Should I
A)    change mcfserial.c to accommodate this new serial port
B)     Change serial.c (default linux driver)  to handle this serial port? I
saw some provisions for Memory mapped addressing of registers etc in
serial.c
 
If anyone who has done this before can point me in the right direction, I
will be thankful. Any problems I should specifically look for and any
pitfalls?
 
Thanks in advance
Subash
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20020403/01373e2a/attachment.html>

From justin.wojdacki at analog.com  Wed Apr  3 14:38:40 2002
From: justin.wojdacki at analog.com (Justin Wojdacki)
Date: Wed, 03 Apr 2002 11:38:40 -0800
Subject: [uClinux-dev] uClinux porting of MIPS
References: <010801c1d670$19399590$2200a8c0@flamenco> <02040309304402.01046@localhost.localdomain> <3CAA69FB.F60D8AB5@analog.com> <02040312561000.02557@localhost.localdomain>
Message-ID: <3CAB5A40.14279B50@analog.com>

zhaotc wrote:
> 
> Then, where I can down load RTAI pathes? I now find my porting of uClinux
> run untable sometime.  May be I can lean something from it. Can you tell me
> which processor you are porting on? My is AR2000 of ARTi. I bet you must
> know nothing about it. It is R3000.
> 

Lexra LX4189. R3000-ish CPU. Recently hung out and left for dead by
Lexra as part of their settlement with MIPS Inc. (see
http://www.lexra.com/press/pr_011231.html). 

The RTAI homepage is http://mail.aero.polimi.it/~rtai/. 24.1.8 is the
newest version. 

-- 
-------------------------------------------------
Justin Wojdacki        
justin.wojdacki at analog.com         (408) 350-5032
Communications Processors Group -- Analog Devices
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From justin.wojdacki at analog.com  Wed Apr  3 14:46:14 2002
From: justin.wojdacki at analog.com (Justin Wojdacki)
Date: Wed, 03 Apr 2002 11:46:14 -0800
Subject: [uClinux-dev] Network problems (I want to connect my host computerto 
 uCsimm)
References: <Pine.LNX.4.44.0204031210210.2812-100000@sole.infis.univ.trieste.it>
Message-ID: <3CAB5C06.4872BA75@analog.com>

Christian Pellegrin wrote:
> 
> AFAIK (basic uCsimm config I played with some time ago) you have to be on
> serial console to type "go" to start linux and have networking. But
> hopefully I could be wrong :-)
> 

Well, you can rig it so that it will autoboot after n seconds, but
yeah, if it's straight out of the box, you have to type "go" on the
console.

-- 
-------------------------------------------------
Justin Wojdacki        
justin.wojdacki at analog.com         (408) 350-5032
Communications Processors Group -- Analog Devices
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From justin.wojdacki at analog.com  Wed Apr  3 14:59:49 2002
From: justin.wojdacki at analog.com (Justin Wojdacki)
Date: Wed, 03 Apr 2002 11:59:49 -0800
Subject: [uClinux-dev] External 16550 UART on a coldifre 5272 based board
References: <8CCBDD5583C50E4196F012E79439B45C364644@atl-ms1.megatrends.com>
Message-ID: <3CAB5F35.2276E661@analog.com>

> Should I
> 
> A)    change mcfserial.c to accommodate this new serial port
>
> B)     Change serial.c (default linux driver)  to handle this serial port?
> I saw some provisions for Memory mapped addressing of registers etc in
> serial.c
>
> If anyone who has done this before can point me in the right direction, I
> will be thankful. Any problems I should specifically look for and any
> pitfalls?
>

If you can make it a memory-mapped device, then you can add it to the
list of devices that drivers/char/serial.c will initialize by editing
include/asm-m68knommu/serial.h (which doesn't seem to exist, although
include/asm-m68k/serial.h does exist :( ). The structure layout used
is defined in include/linux/serialP.h (struct serial_state). 

Can't help you on the mcfserial.c side though. Sorry. :(

-- 
-------------------------------------------------
Justin Wojdacki        
justin.wojdacki at analog.com         (408) 350-5032
Communications Processors Group -- Analog Devices
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From szhang at tekdigitel.com  Wed Apr  3 17:39:43 2002
From: szhang at tekdigitel.com (Stella)
Date: Wed, 3 Apr 2002 17:39:43 -0500
Subject: [uClinux-dev] reset_timer() for AT91-ARM
Message-ID: <00a401c1db60$72e2e3e0$7d01a8c0@tekdigitel.com>

Hi, all

I am doing some porting work for our hardware platform.
And I noticed that in include/asm/arch/ time.h, there is 

extern __inline__ int reset_timer()
{
  struct atmel_timers* tt = (struct atmel_timers*) (TIMER_BASE);
  volatile struct  atmel_timer_channel* tc = &tt->chans[KERNEL_TIMER].ch;
  unsigned long v = tc->sr;
  return (1);
}

Does this function really reset the timer?

Anybody who is familiar with AT91-ARM, please give me some ideas.
I am using the source code from lineo.

thanks 

stella.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20020403/1a9636b8/attachment.html>

From uclinux at schoeldgen.de  Wed Apr  3 17:57:11 2002
From: uclinux at schoeldgen.de (Matthias Schoeldgen)
Date: Thu, 04 Apr 2002 00:57:11 +0200
Subject: [uClinux-dev] Timer & interrupts
References: <A8979596839960.06873@mail0.hongkong.com>
Message-ID: <3CAB88C6.BD10CE4B@schoeldgen.de>

mt_wong at hongkong.com wrote:
> 
> Hello,
> 
>     I'm new to uCSimm, I have some problem concerning the timer and the interrupts.
> 
>     My problem is, I would like to get a clock signal from TI/O input and then count it. from the datasheets, it mentions that the timer can generate an interrupt. But I'm not familiar with interrupts on uClinux, could any one kindly show me some examples?
> 
> --
> Edward Wong

Hi Edward !
I wrote a small driver for uClinux using interrupts from external pins. 
See http://www.schoeldgen.de/robot for the driver "speedy.c". 
Also remember to free the timer from scheduling task in linux, using
either Bernhard Kuhn's patch, or see the chnaged config.c , also on my
website .

Hope, that helps
Matthias
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From SMerrifield at tecom.com.au  Wed Apr  3 22:56:31 2002
From: SMerrifield at tecom.com.au (Steven Merrifield)
Date: Thu, 4 Apr 2002 05:56:31 +0200 
Subject: [uClinux-dev] Problem building uClibc-0.9.10 for m68k
Message-ID: <7FF1185EA0D3D511BC0500B0D0D0C24A1B59B4@melexc01.ap.ilxi.net>

Hi,

I've encountered a problem trying to build uClibc-0.9.10 for a m68k target.
Toolchain is m68k-elf-tools-20020218.tar.gz, kernel headers are 
from uClinux-distribution/linux-2.4.x

Problem as follows:

m68k-elf-gcc -Wall  -fno-builtin -c crti.S -o crti.o
cp crti.o ../../../../lib/
cp: cannot create regular file `../../../../lib/crti.o': No such file or
directory
make[4]: *** [crti.o] Error 1
make[4]: Leaving directory `/home/uClibc-0.9.10/libc/sysdeps/linux/common'


Fair enough, since the lib directory does not exist. I manually create
the directory from uClibc-0.9.10/ and try again:

make[4]: Entering directory `/home/uClibc-0.9.10/libc/sysdeps/linux/m68k'
m68k-elf-gcc -Wall  -fno-builtin -nostdinc  -nostdinc -I../../../../include 
-I/usr/local/lib/gcc-lib/m68k-elf/2.95.3/include -I. -D_LIBC
-Wa,--bitwise-or 
-I/home/uClinux-distribution/linux-2.4.x/include -DNDEBUG  -c __longjmp.S -o
__longjmp.o
../../../../include/bits/setjmp.h: Assembler messages:
../../../../include/bits/setjmp.h:25: Error: Unknown operator -- statement
`type
 int __dregs[7]' ignored
../../../../include/bits/setjmp.h:31: Error: Unknown operator -- statement
`int
*__aregs[6]' ignored


etc...


There are no problems building uClibc-0.9.9
steve
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From prasannark at future.futsoft.com  Thu Apr  4 01:10:42 2002
From: prasannark at future.futsoft.com (Prasanna Rao K)
Date: Thu, 4 Apr 2002 11:40:42 +0530
Subject: [uClinux-dev] Internal compiler error: program cc1 got fatal signal 3
In-Reply-To: <OHEGKBKJNDMIKNAMMKBMKEDDCAAA.eric.bosch@fourtress.nl>
Message-ID: <000001c1db9f$7405ba60$7606140a@future.futsoft.com>

Hi,

  We are getting the following error when we try to compile in arm cross
compiler on Windows 2000 for VxWorks.Any suggestions to remove this
compilation error?

 "nternal compiler error: program cc1 got fatal signal 3"

Prasanna

***************************************************************************
This message is proprietary to Future Software Limited (FSL) 
and is intended solely for the use of the individual to whom it
is addressed. It may contain  privileged or confidential information 
and should not be circulated or used for any purpose other than for 
what it is intended. 

If you have received this message in error, please notify the
originator immediately. If you are not the intended recipient,
you are notified that you are strictly prohibited from using,
copying, altering, or disclosing the contents of this message. 
FSL accepts no responsibility for loss or damage arising from 
the use of the information transmitted by this email including
damage from virus.
***************************************************************************
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From tczhao at linpus.com.tw  Thu Apr  4 01:39:05 2002
From: tczhao at linpus.com.tw (zhaotc)
Date: Thu, 4 Apr 2002 14:39:05 +0800
Subject: [uClinux-dev] uClinux porting of MIPS
In-Reply-To: <3CAB5A40.14279B50@analog.com>
References: <010801c1d670$19399590$2200a8c0@flamenco> <02040312561000.02557@localhost.localdomain> <3CAB5A40.14279B50@analog.com>
Message-ID: <02040414390501.27254@localhost.localdomain>

On Thursday 04 April 2002 03:38 am, you wrote:
> zhaotc wrote:
> > Then, where I can down load RTAI pathes? I now find my porting of uClinux
> > run untable sometime.  May be I can lean something from it. Can you tell
> > me which processor you are porting on? My is AR2000 of ARTi. I bet you
> > must know nothing about it. It is R3000.
>
> Lexra LX4189. R3000-ish CPU. Recently hung out and left for dead by
> Lexra as part of their settlement with MIPS Inc. (see
> http://www.lexra.com/press/pr_011231.html).
>
> The RTAI homepage is http://mail.aero.polimi.it/~rtai/. 24.1.8 is the
> newest version.
	Thank you!

	I do MIPS relocation in the way of modify bFLT file format merely       due 
to somebody told me MIPS gcc do PIC code very bad, and I feel a bit puzzle on 
how "elf2flt" works. So, in my box, all libs such as uClibc and  libgcc.a are 
no-PIC coded.  and only 4 kind of relocation types appear:
	R_MIPS_HI16, R_MIPS_LO16, R_MIPS_26, R_MIPS_32. 

	Now I try porting uClibc to my MIPS board, and it has print "Hello word !" . 
I feel very happy!

	for me.  It is my first porting of linux. In fact, I had known little about 
linux 5 month ago, even the simplist "ls " to search my file! I had been 
working in MS Windows and program COM with ATL. Linux   give me lot of fun 
and happiness. I think turn Linux from windows is worthy to  me. Even now, I 
still cannot use many fetures of linux. :P

	All, Who can tell me how to test my kernel and uClibc? I have no good idea 
but just use them and wait for bug appearing. 

Zhao, Tiecheng
Linpus, Shanghai
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From bruce at tele-ip.com  Thu Apr  4 02:04:42 2002
From: bruce at tele-ip.com (Bruce Paterson)
Date: Thu, 04 Apr 2002 17:04:42 +1000
Subject: [uClinux-dev] Re: Embedded Linux
References: <000001c1da05$c1f2a1c0$0300a8c0@client>
	 <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAAy2pZ8gkx1BG9yABQlQli4kKDAAAQAAAA9AMLs6VG1hGbOQACRAkInwEAAAAA@ncable.net.au>
	 <20020402210420.GB307@sammo.gnubies.com> <02040411050706.01335@badnote>
	 <20020403171226.C30359@bowtie.com.au> <3CABD99A.A515ED52@tele-ip.com> <20020403220838.I30359@bowtie.com.au>
Message-ID: <3CABFB0A.600C639F@tele-ip.com>

Can anyone help Rohan with SBC costs/availability (in australia if
possible)
(from another list).

rohan at bowtie.com.au wrote:
> 
> On Thu, Apr 04, 2002 at 02:42:02PM +1000, Bruce Paterson wrote:
> > rohan at bowtie.com.au wrote:
> > >
> > > > What are peoples opinions on the best starting point for an embedded solution?
> > > >
> > > > I'll probably have about 8 Meg. of flash to play with.
> >
> > > I'm curious what hardware you're playing with.  I'm starting to look at a
> > > low cost embedded linux machine,  I'm curious what people are finding/using
> > > out there.
> 
> The application I've got in mind doesn't need speed/power or a particularly
> large amount of storage/mem (currently running without struggling on a 386/4M).
> What is out there as the absolute baseline SBC/Embedded machine that will run
> Linux/uLinux and communicate over ethernet (what does it cost and who can I
> buy it from) the minimum I've seen so far has been around the US$200 mark
> for small quantities (not that I've looked too hard) which may not be
> ecconomical enough for my project.
> 
> > I have been working recently on embedded Linux for a 68EN360 (68k)
> > processor target.
> > A very basic early decision you need to make is whether your embedded
> > processor
> > will have an MMU or not.
> 
> > If it doesn't (eg. 68EN360, ARM, 68k, DSPs, etc.):
> > Your choice is uClinux, an MMU-less version of Linux.

-- 
Cheers,
Bruce
-------------------------------------------------------------------
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom
they are addressed. If you have received this email in error please
notify the system manager.

    /\\\/\\\/\\\    /   /      Bruce Paterson          
   /  \\\ \\\ \\\  /   /    Senior Design Engineer
  /   /\\\/\\\/\\\/   /   87 Peters Ave, Mulgrave, Vic, 3170
 /   /  \\\ \\\ \\\  /  PO Box 4112, Mulgrave, Vic, 3170, Australia
/   /    \\\/\\\ \\\/   Ph: +61 3 8561 4232   Fax: +61 3 9560 9055
      Tele-IP Ltd.      Email: bruce at tele-ip.com    Icq: #32015991
                        WWW:   http://www.tele-ip.com       VK3TJN
-------------------------------------------------------------------
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From davidm at snapgear.com  Thu Apr  4 02:38:08 2002
From: davidm at snapgear.com (David McCullough)
Date: Thu, 4 Apr 2002 17:38:08 +1000
Subject: [uClinux-dev] M68360: m68k_fork
In-Reply-To: <32362.1017842240@www57.gmx.net>; from Joachim.Schweidler@gmx.de on Wed, Apr 03, 2002 at 03:57:20PM +0200
References: <20020403225441.B30568@beast.internal.moreton.com.au> <32362.1017842240@www57.gmx.net>
Message-ID: <20020404173808.B31668@beast.internal.moreton.com.au>


Jivin Joachim Schweidler lays it down ...
> OK, sorry for asking all this questions that might have been asked before,
> but as you said it's a little bit confusing. 
> 
> Thank you very much for the help,

No problems :-)

Cheers,
Davidm

-- 
David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
davidm at snapgear.com  Fx: +61 7 3891 3630  825 Stanley St., W'gabba QLD 4102, Oz
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From andersen at codepoet.org  Thu Apr  4 03:40:08 2002
From: andersen at codepoet.org (Erik Andersen)
Date: Thu, 4 Apr 2002 01:40:08 -0700
Subject: [uClinux-dev] Problem building uClibc-0.9.10 for m68k
In-Reply-To: <7FF1185EA0D3D511BC0500B0D0D0C24A1B59B4@melexc01.ap.ilxi.net>
References: <7FF1185EA0D3D511BC0500B0D0D0C24A1B59B4@melexc01.ap.ilxi.net>
Message-ID: <20020404084007.GA3537@codepoet.org>

On Thu Apr 04, 2002 at 05:56:31AM +0200, Steven Merrifield wrote:
> Hi,
> 
> I've encountered a problem trying to build uClibc-0.9.10 for a m68k target.
> Toolchain is m68k-elf-tools-20020218.tar.gz, kernel headers are 
> from uClinux-distribution/linux-2.4.x
> 
> Problem as follows:

Mind giving the latest from CVS a try.  For the 0.9.10 release
the include/bits header files were massivly reworked, and as a
side effect, m68k's bits/setjmp.h got killed.  I restored it to 
what it was supposed to contain for m68k a couple of days ago...

 -Erik

--
Erik B. Andersen             http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From mathias.fritzson at mecel.se  Thu Apr  4 04:34:52 2002
From: mathias.fritzson at mecel.se (mathias.fritzson at mecel.se)
Date: Thu, 4 Apr 2002 11:34:52 +0200
Subject: [uClinux-dev] Ramdisk, romfs, etc..
Message-ID: <200204040933.g349X9A28992@<uclinux-dev@uclinux.org>clinux.org>

Hi

Mounting a filesystem in ram isn't too easy if you are a newbie like me..
I've tried a couple of things but how am I supposed to do?

Setup: All in ram exept the bootloader, we are loading everything into
memory though a BDM for now.

I'd like to see a working prompt soon =) this is why I do as I do..

The final working product will load the kernel from an memorymapped compact
flash card (Bootloader working) running (for now) a  FAT filesytem. We will
also try to mount our rootfilesystem from here..

But to reach a  prompt soon (there is a new micrcontroller port
(68336-'376) and new board support involved so we'd like to verify that the
port is working fast..) we decided to create a romfs and put it in ram to
get it all up and running. What do we need to succed with this? What we've
dome more exactly is to compile with romfs support and ramdisk support (do
we need a ramdisk ??).

Latest compile rendered this output (some homemade debug outputs...)

snip..
...
MC68332 serial driver version 1.00
ttyS0 is a builtin MC68332 UART
DEBUG: after chr_dev_init
Ramdisk driver initialized : 16 ramdisks of 4096K size
DEBUG: inside blkmem_init, sizeof(arena): 26, sizeof(struct arena_t): 26, arena[
0].address: 8524a0, arenas: 1
Blkmem copyright 1998,1999 D. Jeff Dionne
Blkmem copyright 1998 Kenneth Albanowski
Blkmem 1 disk images:
0: 8524A0-86289F (RO)
DEBUG: identify_ramdisk_image, fp->f_inode: 8fbe82, fp: 8fbd4a, buf: 875414 , si
ze: 200
RAMDISK: Couldn't find valid ramdisk image starting at 0.
VFS: Mounted root (romfs filesystem).
DEBUG: inside init (CONFIG_BLK_DEV_INITRD)
Unable to open an initial console.
DEBUG: trying to run init
DEBUG: do_rc
Failed to free page
Failed to free page
Failed to free page
...
snip...

We've included busybox and would like to use it as the shell.. Any special procedures involved to use busybox??

Any help is appreciated

TIA

/Mathias

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From julienb at actimage.fr  Thu Apr  4 04:53:43 2002
From: julienb at actimage.fr (Julien Boibessot)
Date: Thu, 4 Apr 2002 11:53:43 +0200
Subject: [uClinux-dev] 5272C3 dbug binaries
References: <D447D880267ED5118F2A00D0B74A108B11E388@munich-ex1.munich.akamai.com> <3CA9D78A.9060709@snapgear.com> <001201c1da65$b45bc630$8947ec95@bruker.fr>
Message-ID: <032c01c1dbbe$9b0c2c60$8947ec95@bruker.fr>

Hi !!

As I have accidentally erased my dBug in Flash on my devt board ( :-)) ),
I've tried to recompile it from the sources I got on Motorola web site......
It was easy to recompile it with Codewarrior but when I try with gnu tools,
I have some problems.....
It seems that the makefile was done for a Solaris Linux distrib.....

Does anyone have already manage to do a such recompilation with a x86 linux
distrib (suze for example) ???
Can you give me some clues ???

thanks !!!

Julien


----- Original Message -----
From: "Julien Boibessot" <julienb at actimage.fr>
To: <uclinux-dev at uclinux.org>
Sent: Tuesday, April 02, 2002 6:44 PM
Subject: [uClinux-dev] 5272C3 dbug binaries


> Hello !
>
> does anyone can email me a binary file of dbug for Motorola/Tarifa 5272C3
> devt board please ??
> I've just killed mine...:-((
>
> and I don't know how to regenerate it...
>
> thanks
> Julien
>
>
> This message resent by the uclinux-dev at uclinux.org list server
http://www.uClinux.org/
>

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From seclorum at mac.com  Thu Apr  4 04:47:04 2002
From: seclorum at mac.com (Jay Vaughan)
Date: Thu, 4 Apr 2002 17:47:04 +0800
Subject: [uClinux-dev] Problem building uClibc-0.9.10 for m68k
In-Reply-To: <20020404084007.GA3537@codepoet.org>
References: <7FF1185EA0D3D511BC0500B0D0D0C24A1B59B4@melexc01.ap.ilxi.net>
 <20020404084007.GA3537@codepoet.org>
Message-ID: <a05101503b8d1d17782dc@[10.0.1.2]>

>Mind giving the latest from CVS a try.  For the 0.9.10 release
>the include/bits header files were massivly reworked, and as a
>side effect, m68k's bits/setjmp.h got killed.  I restored it to
>what it was supposed to contain for m68k a couple of days ago...


BTW, what's the CVS for the latest uClinux-dist these days?  I'm 
working on MCF5272 ...

-- 
j.
--
jv - Jay Vaughan - jay at ampfea.org     - seclorum at mac.com
                  - jv at access-music.de - icq:454804
   ~... threads rolling, keep the threads rolling ...~
-------------------------------------------------------------
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From davidm at snapgear.com  Thu Apr  4 06:33:26 2002
From: davidm at snapgear.com (David McCullough)
Date: Thu, 4 Apr 2002 21:33:26 +1000
Subject: [uClinux-dev] Ramdisk, romfs, etc..
In-Reply-To: <200204040933.g349X9A28992@<uclinux-dev@uclinux.org>; from mathias.fritzson@mecel.se on Thu, Apr 04, 2002 at 11:34:52AM +0200
References: <200204040933.g349X9A28992@<uclinux-dev@uclinux.org>
Message-ID: <20020404213326.A937@beast.internal.moreton.com.au>


Jivin mathias.fritzson at mecel.se lays it down ...
> Hi
> 
> Mounting a filesystem in ram isn't too easy if you are a newbie like me..
> I've tried a couple of things but how am I supposed to do?
> 
> Setup: All in ram exept the bootloader, we are loading everything into
> memory though a BDM for now.
> 
> I'd like to see a working prompt soon =) this is why I do as I do..
> 
> The final working product will load the kernel from an memorymapped compact
> flash card (Bootloader working) running (for now) a  FAT filesytem. We will
> also try to mount our rootfilesystem from here..
> 
> But to reach a  prompt soon (there is a new micrcontroller port
> (68336-'376) and new board support involved so we'd like to verify that the
> port is working fast..) we decided to create a romfs and put it in ram to
> get it all up and running. What do we need to succed with this? What we've
> dome more exactly is to compile with romfs support and ramdisk support (do
> we need a ramdisk ??).


No you don't need a ramdisk,  but it's a very good idea to put /tmp and
/var/tmp on a ramdisk somewhere :-)


> Latest compile rendered this output (some homemade debug outputs...)
> 
> snip..
> ...
> MC68332 serial driver version 1.00
> ttyS0 is a builtin MC68332 UART
> DEBUG: after chr_dev_init
> Ramdisk driver initialized : 16 ramdisks of 4096K size
> DEBUG: inside blkmem_init, sizeof(arena): 26, sizeof(struct arena_t): 26, arena[
> 0].address: 8524a0, arenas: 1
> Blkmem copyright 1998,1999 D. Jeff Dionne
> Blkmem copyright 1998 Kenneth Albanowski
> Blkmem 1 disk images:
> 0: 8524A0-86289F (RO)
> DEBUG: identify_ramdisk_image, fp->f_inode: 8fbe82, fp: 8fbd4a, buf: 875414 , si
> ze: 200
> RAMDISK: Couldn't find valid ramdisk image starting at 0.
> VFS: Mounted root (romfs filesystem).
> DEBUG: inside init (CONFIG_BLK_DEV_INITRD)
> Unable to open an initial console.
> DEBUG: trying to run init
> DEBUG: do_rc
> Failed to free page
> Failed to free page
> Failed to free page
> ...
> snip...


Looks good,  found the romfs and mounted it.

"Unable to open an initial console" could point to a bad /dev dir in the
romfs.  You need to be sure that /dev is setup properly.  The uClinux-dist
has plenty of examples on doing this and adding your changes should not be
a very large task at all.  If you are using the symbolic device entries
(ie., @dev,c,N,M) make sure you are actually using the correct version
of genromfs (version 0.5.1 is good).

The "Failed to free page" errors are a big concern.  Make sure the memory
containing the romfs is reserved and not being allocated or re-used.

> We've included busybox and would like to use it as the shell..
> Any special procedures involved to use busybox??


Again the uClinux-dist has good busybox support on uClinux and takes care
of the setup for you.

Be careful with the shell's in busybox,  most are not suitable for uClinux.
The Minix shell is the only one I can think of that might work depending
on what busybox version you have.

To get the system going quickly I suggest you go with sash,  then more on
to something better if you need to.

Cheers,
Davidm

-- 
David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
davidm at snapgear.com  Fx: +61 7 3891 3630  825 Stanley St., W'gabba QLD 4102, Oz
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From mathias.fritzson at mecel.se  Thu Apr  4 07:34:51 2002
From: mathias.fritzson at mecel.se (mathias.fritzson at mecel.se)
Date: Thu, 4 Apr 2002 14:34:51 +0200
Subject: [uClinux-dev] Ramdisk, romfs, etc..
Message-ID: <200204041233.g34CX7A30253@<uclinux-dev@uclinux.org>clinux.org>



I think that my romfs tree might be of interest too..

Attatched...

(See attached file: romfstree.tar.gz)

Mathias Fritzson wrote:
>Hi
>
>Mounting a filesystem in ram isn't too easy if you are a newbie like me..
>I've tried a couple of things but how am I supposed to do?
>
>Setup: All in ram exept the bootloader, we are loading everything into
>memory though a BDM for now.
>
>I'd like to see a working prompt soon =) this is why I do as I do..
>
>The final working product will load the kernel from an memorymapped
compact
>flash card (Bootloader working) running (for now) a  FAT filesytem. We
will
>also try to mount our rootfilesystem from here..
>
>But to reach a  prompt soon (there is a new micrcontroller port
>(68336-'376) and new board support involved so we'd like to verify that
the
>port is working fast..) we decided to create a romfs and put it in ram to
>get it all up and running. What do we need to succed with this? What we've
>dome more exactly is to compile with romfs support and ramdisk support (do
>we need a ramdisk ??).
>
>Latest compile rendered this output (some homemade debug outputs...)
>
>snip..
>...
>MC68332 serial driver version 1.00
>ttyS0 is a builtin MC68332 UART
>DEBUG: after chr_dev_init
>Ramdisk driver initialized : 16 ramdisks of 4096K size
>DEBUG: inside blkmem_init, sizeof(arena): 26, sizeof(struct arena_t): 26,
arena[
>0].address: 8524a0, arenas: 1
>Blkmem copyright 1998,1999 D. Jeff Dionne
>Blkmem copyright 1998 Kenneth Albanowski
>Blkmem 1 disk images:
>0: 8524A0-86289F (RO)
>DEBUG: identify_ramdisk_image, fp->f_inode: 8fbe82, fp: 8fbd4a, buf:
875414 , si
>ze: 200
>RAMDISK: Couldn't find valid ramdisk image starting at 0.
>VFS: Mounted root (romfs filesystem).
>DEBUG: inside init (CONFIG_BLK_DEV_INITRD)
>Unable to open an initial console.
>DEBUG: trying to run init
>DEBUG: do_rc
>Failed to free page
>Failed to free page
>Failed to free page
>...
>snip...
>
>We've included busybox and would like to use it as the shell.. Any special
procedures involved to >use busybox??
>
>Any help is appreciated
>
>TIA
>
>/Mathias
>
>This message resent by the uclinux-dev at uclinux.org list server
http://www.uClinux.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: romfstree.tar.gz
Type: application/octet-stream
Size: 30769 bytes
Desc: not available
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20020404/87368d69/attachment.obj>

From gerg at snapgear.com  Thu Apr  4 08:06:03 2002
From: gerg at snapgear.com (Greg Ungerer)
Date: Thu, 04 Apr 2002 23:06:03 +1000
Subject: [uClinux-dev] External 16550 UART on a coldifre 5272 based board
References: <8CCBDD5583C50E4196F012E79439B45C364644@atl-ms1.megatrends.com>
Message-ID: <3CAC4FBB.1020608@snapgear.com>


Hi Subash,

Subash Kalbarga wrote:
> I have a coldfire based board(5272) but we have added an external UART 
> (16550) to the board.
>
> What would the best approach be for getting a serial driver attach to this
> 
> I know that the Internal UART of the coldfire differs significantly from 
> the standard 16550.
> 
> Should I
> 
> A)    change mcfserial.c to accommodate this new serial port
> 
> B)     Change serial.c (default linux driver)  to handle this serial 
> port? I saw some provisions for Memory mapped addressing of registers 
> etc in serial.c
> 
> If anyone who has done this before can point me in the right direction, 
> I will be thankful. Any problems I should specifically look for and any 
> pitfalls?

You should modify the serial.c driver. It is relatively easy to
convert for use on ColdFire hardware. The serial.c in the uClinux-2.0.x
tree (at ~/drivers/char/serial.c) already has ColdFire support in it.
Look for the CONFIG_COLDFIRE and CONFIG_NETtel defines in it.

Basically I modified the in/out functions to use memory mapped
addressing, and made some other small changes to allow for the slightly
different interrupt setup.

Regards
Greg


------------------------------------------------------------------------
Greg Ungerer  --  Chief Software Wizard        EMAIL:  gerg at snapgear.com
SnapGear                                       PHONE:    +61 7 3279 1822
825 Stanley St,                                  FAX:    +61 7 3279 1820
Woolloogabba, QLD, 4102, Australia               WEB:   www.snapgear.com

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From mathias.fritzson at mecel.se  Thu Apr  4 09:11:54 2002
From: mathias.fritzson at mecel.se (mathias.fritzson at mecel.se)
Date: Thu, 4 Apr 2002 16:11:54 +0200
Subject: [uClinux-dev] Ramdisk, romfs, etc..
Message-ID: <200204041410.g34EABA30925@<uclinux-dev@uclinux.org>clinux.org>



Davidm wrote:
>Jivin mathias.fritzson at mecel.se lays it down ...
>> Hi
>>
>> Mounting a filesystem in ram isn't too easy if you are a newbie like
me..
>> I've tried a couple of things but how am I supposed to do?
>>
>> Setup: All in ram exept the bootloader, we are loading everything into
>> memory though a BDM for now.
>>
>> I'd like to see a working prompt soon =) this is why I do as I do..
>>
>> The final working product will load the kernel from an memorymapped
compact
>> flash card (Bootloader working) running (for now) a  FAT filesytem. We
will
>> also try to mount our rootfilesystem from here..
>>
>> But to reach a  prompt soon (there is a new micrcontroller port
>> (68336-'376) and new board support involved so we'd like to verify that
the
>> port is working fast..) we decided to create a romfs and put it in ram
to
>> get it all up and running. What do we need to succed with this? What
we've
>> dome more exactly is to compile with romfs support and ramdisk support
(do
>> we need a ramdisk ??).
>
>
>No you don't need a ramdisk,  but it's a very good idea to put /tmp and
>/var/tmp on a ramdisk somewhere :-)
>
Ok, will have to research that area later then =)


>
>> Latest compile rendered this output (some homemade debug outputs...)
>>
>> snip..
>> ...
>> MC68332 serial driver version 1.00
>> ttyS0 is a builtin MC68332 UART
>> DEBUG: after chr_dev_init
>> Ramdisk driver initialized : 16 ramdisks of 4096K size
>> DEBUG: inside blkmem_init, sizeof(arena): 26, sizeof(struct arena_t):
26, arena[
>> 0].address: 8524a0, arenas: 1
>> Blkmem copyright 1998,1999 D. Jeff Dionne
>> Blkmem copyright 1998 Kenneth Albanowski
>> Blkmem 1 disk images:
>> 0: 8524A0-86289F (RO)
>> DEBUG: identify_ramdisk_image, fp->f_inode: 8fbe82, fp: 8fbd4a, buf:
875414 , si
>> ze: 200
>> RAMDISK: Couldn't find valid ramdisk image starting at 0.
>> VFS: Mounted root (romfs filesystem).
>> DEBUG: inside init (CONFIG_BLK_DEV_INITRD)
>> Unable to open an initial console.
>> DEBUG: trying to run init
>> DEBUG: do_rc
>> Failed to free page
>> Failed to free page
>> Failed to free page
>> ...
>> snip...
>
>
>Looks good,  found the romfs and mounted it.
>
>"Unable to open an initial console" could point to a bad /dev dir in the
>romfs.  You need to be sure that /dev is setup properly.  The uClinux-dist
>has plenty of examples on doing this and adding your changes should not be
>a very large task at all.  If you are using the symbolic device entries
>(ie., @dev,c,N,M) make sure you are actually using the correct version
>of genromfs (version 0.5.1 is good).

This is what I thought could be a problem... If you have a look in the
romfs tree in the reply I made to myself the devices are /dev/@tty,c,5,0
instead of what I suppose they should be (/dev/tty,c,5,0). The tools are
the latest m68k-elf-tools-20020218.tar.gz package running under
VMware/Debian 2.2.5, so we use genromfs 0.5.1..

>
>The "Failed to free page" errors are a big concern.  Make sure the memory
>containing the romfs is reserved and not being allocated or re-used.

How do I make sure this happens ?? There are some memory reserved during
the boot...

snip..
Memory available: 560k/1019k RAM, 512k/512k ROM (209k kernel code, 118k
data), 3
3 pages reserved (132k)
snip..

..but I assume those 132k aren't for the romfs =) i.e help a newbie to
reserve memory for the romfs..

Actually those "Failed to free page" just appeared this testrun the output
usually ends with the "DEBUG: do_rc"

>
>> We've included busybox and would like to use it as the shell..
>> Any special procedures involved to use busybox??
>
>
>Again the uClinux-dist has good busybox support on uClinux and takes care
>of the setup for you.
>
>Be careful with the shell's in busybox,  most are not suitable for
uClinux.
>The Minix shell is the only one I can think of that might work depending
>on what busybox version you have.
>
>To get the system going quickly I suggest you go with sash,  then more on
>to something better if you need to.

Thanks for the tip =)
>
>Cheers,
>Davidm
>
Thanks for the help so far =)

/Mathias

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From dsg at gesema.com  Thu Apr  4 10:09:01 2002
From: dsg at gesema.com (dsg at gesema.com)
Date: Thu, 4 Apr 2002 17:09:01 +0200
Subject: [uClinux-dev] status of Net+ARM support?
Message-ID: <200204041509.DCS04954@vmms5.verisignmail.com>

Hi Konrad
The uClinux port for NET+arm called NETLx is still
in progress. I dont know the status of suport from Linio.
But work on the 2.4 port and 2.5 is proceding in Sweden,
planed to be available to summer 2002. Because of buisiness
reconstructions work is done by Gesema for the moment but
Dan Stroberg
GESEMA

Address:           Phone: +46 171 58803
V. Myrskaren 43   Mobil: +46 70 7775268
S-746 91 Balsta   Email: dsg at gesema.com
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From ken at reasonability.net  Thu Apr  4 13:56:25 2002
From: ken at reasonability.net (Ken Treis)
Date: Thu, 04 Apr 2002 10:56:25 -0800
Subject: [uClinux-dev] Problem building uClibc-0.9.10 for m68k
References: <7FF1185EA0D3D511BC0500B0D0D0C24A1B59B4@melexc01.ap.ilxi.net> <20020404084007.GA3537@codepoet.org>
Message-ID: <3CACA1D9.8000500@reasonability.net>

An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20020404/7b94546f/attachment.html>

From justin.wojdacki at analog.com  Thu Apr  4 15:10:39 2002
From: justin.wojdacki at analog.com (Justin Wojdacki)
Date: Thu, 04 Apr 2002 12:10:39 -0800
Subject: [uClinux-dev] uClinux porting of MIPS
References: <010801c1d670$19399590$2200a8c0@flamenco> <02040312561000.02557@localhost.localdomain> <3CAB5A40.14279B50@analog.com> <02040414390501.27254@localhost.localdomain>
Message-ID: <3CACB33F.961F0048@analog.com>

zhaotc wrote:
> 
>         I do MIPS relocation in the way of modify bFLT file format
> merely due to somebody told me MIPS gcc do PIC code very bad, and I feel a
> bit puzzle on how "elf2flt" works. So, in my box, all libs such as uClibc
> and  libgcc.a are no-PIC coded.  and only 4 kind of relocation types appear:
>         R_MIPS_HI16, R_MIPS_LO16, R_MIPS_26, R_MIPS_32.
>

Hrm...What version of GCC are you using? Also note that ELF2FLT is
very M68K and ARM-oriented, so if you aren't familiar with those CPUs,
some of what's happening in ELF2FLT might confuse you.

> 
>         Now I try porting uClibc to my MIPS board, and it has print
> "Hello word !" . I feel very happy!
>

:) Such a simple program, and yet it fills one with so much
confidence. 

> 
>         for me.  It is my first porting of linux. In fact, I had known
> little about linux 5 month ago, even the simplist "ls " to search my file!
> I had been working in MS Windows and program COM with ATL. Linux   give me
> lot of fun and happiness. I think turn Linux from windows is worthy to  me.
> Even now, I still cannot use many fetures of linux. :P
>

Don't worry, a lot of people don't or can't use all the features of
Linux (much like Windows, *BSD, etc.). There's really too much there,
due to trying to fit it into all possible computing environments. 

> 
>         All, Who can tell me how to test my kernel and uClibc? I have no
> good idea but just use them and wait for bug appearing.
>

Write (or find) programs that give you good system call coverage.
That's the first real step to seeing if your port is stable. Linux
doesn't really seem to have a regression test suite that ships with it
that you can run (somebody please correct me if I'm wrong).

-- 
-------------------------------------------------
Justin Wojdacki        
justin.wojdacki at analog.com         (408) 350-5032
Communications Processors Group -- Analog Devices
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From justin.wojdacki at analog.com  Thu Apr  4 17:53:45 2002
From: justin.wojdacki at analog.com (Justin Wojdacki)
Date: Thu, 04 Apr 2002 14:53:45 -0800
Subject: [uClinux-dev] Re: Embedded Linux
References: <000001c1da05$c1f2a1c0$0300a8c0@client>
		 <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAAy2pZ8gkx1BG9yABQlQli4kKDAAAQAAAA9AMLs6VG1hGbOQACRAkInwEAAAAA@ncable.net.au>
		 <20020402210420.GB307@sammo.gnubies.com> <02040411050706.01335@badnote>
		 <20020403171226.C30359@bowtie.com.au> <3CABD99A.A515ED52@tele-ip.com> <20020403220838.I30359@bowtie.com.au> <3CABFB0A.600C639F@tele-ip.com>
Message-ID: <3CACD979.755C2A1@analog.com>

Bruce Paterson wrote:
> 
> Can anyone help Rohan with SBC costs/availability (in australia if
> possible)
> (from another list).
> 
> rohan at bowtie.com.au wrote:
> >
> >
> > The application I've got in mind doesn't need speed/power or a particularly
> > large amount of storage/mem (currently running without struggling on a 386/4M).
> > What is out there as the absolute baseline SBC/Embedded machine that will run
> > Linux/uLinux and communicate over ethernet (what does it cost and who can I
> > buy it from) the minimum I've seen so far has been around the US$200 mark
> > for small quantities (not that I've looked too hard) which may not be
> > ecconomical enough for my project.
> >

Check out http://www.compulab.co.il for some really cool (and small)
SBCs. They've been forced to discontinue their 486 line (supplier
discontinued the CPUs), but the 586 class stuff is really cheap. 

You may also want to dig through the links at http://www.pc104.com.

Any restrictions on CPU type? 

-- 
-------------------------------------------------
Justin Wojdacki        
justin.wojdacki at analog.com         (408) 350-5032
Communications Processors Group -- Analog Devices
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From tczhao at linpus.com.tw  Thu Apr  4 20:33:23 2002
From: tczhao at linpus.com.tw (zhaotc)
Date: Fri, 5 Apr 2002 09:33:23 +0800
Subject: [uClinux-dev] uClinux porting of MIPS
In-Reply-To: <3CACB33F.961F0048@analog.com>
References: <010801c1d670$19399590$2200a8c0@flamenco> <02040414390501.27254@localhost.localdomain> <3CACB33F.961F0048@analog.com>
Message-ID: <02040509332300.01160@localhost.localdomain>

On Friday 05 April 2002 04:10 am, you wrote:
> zhaotc wrote:
> >         I do MIPS relocation in the way of modify bFLT file format
> > merely due to somebody told me MIPS gcc do PIC code very bad, and I feel
> > a bit puzzle on how "elf2flt" works. So, in my box, all libs such as
> > uClibc and  libgcc.a are no-PIC coded.  and only 4 kind of relocation
> > types appear: R_MIPS_HI16, R_MIPS_LO16, R_MIPS_26, R_MIPS_32.
>
> Hrm...What version of GCC are you using? Also note that ELF2FLT is
> very M68K and ARM-oriented, so if you aren't familiar with those CPUs,
> some of what's happening in ELF2FLT might confuse you.

	My GCC version is 2.97, binutils is 2.1.91. 

>
> >         Now I try porting uClibc to my MIPS board, and it has print
> > "Hello word !" . I feel very happy!
> >
> :) Such a simple program, and yet it fills one with so much
>
> confidence.

	Yes, as a newbie of linux.:) I worked for this project for 3 month, and work 
10hr one day. At lest I see something run. I also work in L7205 Kernel 
porting for 2 month. Because there are many people working for it, it didn't 
waste me much time, what I do just write some device drivers. Now the L7205 
project has been transfor to other engineer in my  company. 
	
Zhao Tiecheng
Linpus, Shanghai
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From miles at lsi.nec.co.jp  Thu Apr  4 23:17:37 2002
From: miles at lsi.nec.co.jp (Miles Bader)
Date: 05 Apr 2002 13:17:37 +0900
Subject: [uClinux-dev] remove symlink in uClinux-dist?
Message-ID: <buo6636wzha.fsf@mcspd15.ucom.lsi.nec.co.jp>

In uClinux-dist-20020214, there's a symlink `user/traceroute/gnuc.h',
which the Makefile will regenerate automatically if it goes missing.

Do you think you could remove this in future distributions?  It's the
only symlink there, and causes a minor problem when I make my own
distributions (because I use `tar -h').

[Obviously this is not a big deal, as I can remove it myself, but I
figure it can't hurt to ask]

-Miles
-- 
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
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From davidm at snapgear.com  Fri Apr  5 00:51:47 2002
From: davidm at snapgear.com (David McCullough)
Date: Fri, 5 Apr 2002 15:51:47 +1000
Subject: [uClinux-dev] remove symlink in uClinux-dist?
In-Reply-To: <buo6636wzha.fsf@mcspd15.ucom.lsi.nec.co.jp>; from miles@lsi.nec.co.jp on Fri, Apr 05, 2002 at 01:17:37PM +0900
References: <buo6636wzha.fsf@mcspd15.ucom.lsi.nec.co.jp>
Message-ID: <20020405155147.A28712@beast.internal.moreton.com.au>


Jivin Miles Bader lays it down ...
> In uClinux-dist-20020214, there's a symlink `user/traceroute/gnuc.h',
> which the Makefile will regenerate automatically if it goes missing.
> 
> Do you think you could remove this in future distributions?  It's the
> only symlink there, and causes a minor problem when I make my own
> distributions (because I use `tar -h').
> 
> [Obviously this is not a big deal, as I can remove it myself, but I
> figure it can't hurt to ask]

Done,  just added it to the clean target which is run before the distro
is cut.

It was already a part of distclean,  but that doesn't fit well with the
distro,

Cheers,
Davidm

-- 
David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
davidm at snapgear.com  Fx: +61 7 3891 3630  825 Stanley St., W'gabba QLD 4102, Oz
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From stefan.jonsson at faltcom.se  Fri Apr  5 04:16:45 2002
From: stefan.jonsson at faltcom.se (Stefan Jonsson)
Date: Fri, 5 Apr 2002 11:16:45 +0200
Subject: [uClinux-dev] How start uClinux from a bootloader?
Message-ID: <NGBBJKACILMHGKHMEHHLCEIFCAAA.stefan.jonsson@faltcom.se>

Hello list,

I am usin EB40 + MEC01 and in order to not do any soldering on the EB40 I
have decided to not boot from the MEC:s flash. I am modifying the bootloader
from Atmel to set up the MEC (and putting in a flash programmer as well).
But then what? How do I actually start up uClinux after boot of the card? Do
I call for the linux-init-process or something? How is that done? I have
never done this before.

Regards,
Stefan Jonsson,
Student, University of Umea, Sweden.

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From arne.jonsson at i3micro.com  Fri Apr  5 04:42:16 2002
From: arne.jonsson at i3micro.com (Arne Jonsson)
Date: Fri, 05 Apr 2002 11:42:16 +0200
Subject: [uClinux-dev] One ethernet, dual IP addresses?
Message-ID: <3CAD7178.7A9982F1@i3micro.com>

Hello!

I know it's possible to have multiple IP addresses on
one interface in "plain" linux. This seems to be done
using modules and some ifconfig command.
The question is how to do this in an embedded system with
no module support and no shell where ifconfig can be run.
This is a nice feature to have if you want a "fallback"
IP address when something has gone wrong with your ordinary one.
Does anyone have any ideas, pointers ...
I'm using uClinux 2.0.38.

Best regards,
/Arne Jonsson
-- 
Arne Jonsson
i3 micro technology AB
Phone:+46-8-506 388 00
Fax:  +46-8-506 388 75
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From michiel.thuys at intersil.com  Fri Apr  5 05:07:12 2002
From: michiel.thuys at intersil.com (Thuys, Michiel)
Date: Fri, 5 Apr 2002 05:07:12 -0500
Subject: [uClinux-dev] One ethernet, dual IP addresses?
Message-ID: <716A7F62A194D41195AB001083FC3AE4B5E828@inlmx1.inl.intersil.com>

You can put aliases (eth0:0, eth0:1, etc.) on an interface to have multiple IP addresses. This is done via ifconfig, but is probably also possible with a few ioctls.

Michiel

> -----Original Message-----
> From: Arne Jonsson [mailto:arne.jonsson at i3micro.com]
> Sent: vrijdag 5 april 2002 11:42
> To: uclinux-dev at uclinux.org
> Subject: [uClinux-dev] One ethernet, dual IP addresses?
> 
> 
> Hello!
> 
> I know it's possible to have multiple IP addresses on
> one interface in "plain" linux. This seems to be done
> using modules and some ifconfig command.
> The question is how to do this in an embedded system with
> no module support and no shell where ifconfig can be run.
> This is a nice feature to have if you want a "fallback"
> IP address when something has gone wrong with your ordinary one.
> Does anyone have any ideas, pointers ...
> I'm using uClinux 2.0.38.
> 
> Best regards,
> /Arne Jonsson
> -- 
> Arne Jonsson
> i3 micro technology AB
> Phone:+46-8-506 388 00
> Fax:  +46-8-506 388 75
> This message resent by the uclinux-dev at uclinux.org list 
> server http://www.uClinux.org/
> 
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From arne.jonsson at i3micro.com  Fri Apr  5 05:37:57 2002
From: arne.jonsson at i3micro.com (Arne Jonsson)
Date: Fri, 05 Apr 2002 12:37:57 +0200
Subject: [uClinux-dev] One ethernet, dual IP addresses?
References: <716A7F62A194D41195AB001083FC3AE4B5E828@inlmx1.inl.intersil.com>
Message-ID: <3CAD7E85.66E53593@i3micro.com>

"Thuys, Michiel" wrote:
> 
> You can put aliases (eth0:0, eth0:1, etc.) on an interface to have multiple IP addresses. This is done via ifconfig, but is probably also possible with a few ioctls.
> 
> Michiel
Thank you for answering!
How do you figure out what ioctls to use?
Look at the ifconfig source code??

Best regards,
/Arne Jonsson

Arne Jonsson
i3 micro technology AB
Phone:+46-8-506 388 00
Fax:  +46-8-506 388 75
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From davidm at snapgear.com  Fri Apr  5 06:19:33 2002
From: davidm at snapgear.com (David McCullough)
Date: Fri, 5 Apr 2002 21:19:33 +1000
Subject: [uClinux-dev] One ethernet, dual IP addresses?
In-Reply-To: <3CAD7178.7A9982F1@i3micro.com>; from arne.jonsson@i3micro.com on Fri, Apr 05, 2002 at 11:42:16AM +0200
References: <3CAD7178.7A9982F1@i3micro.com>
Message-ID: <20020405211933.A22009@beast.internal.moreton.com.au>


Jivin Arne Jonsson lays it down ...
> Hello!
> 
> I know it's possible to have multiple IP addresses on
> one interface in "plain" linux. This seems to be done
> using modules and some ifconfig command.
> The question is how to do this in an embedded system with
> no module support and no shell where ifconfig can be run.
> This is a nice feature to have if you want a "fallback"
> IP address when something has gone wrong with your ordinary one.
> Does anyone have any ideas, pointers ...
> I'm using uClinux 2.0.38.

This is possible on uClinux using ifconfig and IP Aliasing,  you just
configure eth0:1 eth0:2 and so on.

You need to enable the kernel options to use this.

If you don't have ifconfig or a shell,  then you will need to look at how
ifconfig does it's thing and make whatever user program you have do that :-)

Cheers,
Davidm

-- 
David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
davidm at snapgear.com  Fx: +61 7 3891 3630  825 Stanley St., W'gabba QLD 4102, Oz
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From michiel.thuys at intersil.com  Fri Apr  5 06:11:19 2002
From: michiel.thuys at intersil.com (Thuys, Michiel)
Date: Fri, 5 Apr 2002 06:11:19 -0500
Subject: [uClinux-dev] One ethernet, dual IP addresses?
Message-ID: <716A7F62A194D41195AB001083FC3AE4B5E829@inlmx1.inl.intersil.com>

You can look at the ifconfig code. I would guess it's a SIOCSIFADDR call.

Michiel

> -----Original Message-----
> From: Arne Jonsson [mailto:arne.jonsson at i3micro.com]
> Sent: vrijdag 5 april 2002 12:38
> To: uclinux-dev at uclinux.org
> Subject: Re: [uClinux-dev] One ethernet, dual IP addresses?
> 
> 
> "Thuys, Michiel" wrote:
> > 
> > You can put aliases (eth0:0, eth0:1, etc.) on an interface 
> to have multiple IP addresses. This is done via ifconfig, but 
> is probably also possible with a few ioctls.
> > 
> > Michiel
> Thank you for answering!
> How do you figure out what ioctls to use?
> Look at the ifconfig source code??
> 
> Best regards,
> /Arne Jonsson
> 
> Arne Jonsson
> i3 micro technology AB
> Phone:+46-8-506 388 00
> Fax:  +46-8-506 388 75
> This message resent by the uclinux-dev at uclinux.org list 
> server http://www.uClinux.org/
> 
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From lgltoludo at yahoo.fr  Fri Apr  5 06:27:22 2002
From: lgltoludo at yahoo.fr (=?iso-8859-1?q?Ludo=20G.L.?=)
Date: Fri, 5 Apr 2002 13:27:22 +0200 (CEST)
Subject: [uClinux-dev] Problems in instaling devlopment tools for M5307C3
In-Reply-To: <3CAD7E85.66E53593@i3micro.com>
Message-ID: <20020405112722.30410.qmail@web20001.mail.yahoo.com>

[uClinux-dev]

Hello.

I'm a french student in Informatique. In order to
perform my studies, I need
to realise a project. So, I must power a embeded
system on the M5307C3 Motorola's
board (which function with a ColdFire ?processor).
I already try to install the uClinux OS on the board
but, I have problems when 
I want to install the devlopment tools on my PC
system.
Can you explain me how to process to install the uC
kernel and, it devlopement
tool, step to step (I probably have forgoten
something).
I have download, the files from your site
www.uclinux.org, but I still have 
problems to install them (I'm a novice in Linux
programing).
I have install m68k-elf-tools-20020218.tar.gz and
uClinux-dist-20011112.tar.gz too.

Who helps a newbie ?
                                                  
Ludovic GUILLET
                                                  
lgltoludo at yahoo.fr


Note:
-----
First, I do the "make xconfig"
Then, I do the "make dep"
and an error appears:(look at the end) 

[root at localhost uClinux-dist]# make dep
make -C linux dep
make[1]: Entre dans le r?pertoire
`/home/ludo/uClinux/uClinux-dist/linux'
echo Platform 5307 Board  Model ram
Platform 5307 Board Model ram
scripts/mkdep init/*.c > .tmpdepend
scripts/mkdep `find
/home/ludo/uClinux/uClinux-dist/linux/include/asm
/home/ludo/uClinux/uClinux-dist/linux/include/linux
/home/ludo/uClinux/uClinux-dist/linux/include/scsi
/home/ludo/uClinux/uClinux-dist/linux/include/net
-follow -name \*.h ! -name modversions.h -print` >
.hdepend
set -e; for i in arch/m68knommu/kernel
arch/m68knommu/mm arch/m68knommu/lib
arch/m68knommu/platform/5307 kernel drivers fs net ipc
lib mmnommu; do make -C $i fastdep; done
make[2]: Entre dans le r?pertoire
`/home/ludo/uClinux/uClinux-dist/linux/arch/m68knommu/kernel'
if [ -n "console.c ksyms.c process.c ptrace.c setup.c
sys_m68k.c time.c traps.c" ]; then \
/home/ludo/uClinux/uClinux-dist/linux/scripts/mkdep
*.[chS] > .depend; fi
make[2]: Quitte le r?pertoire
`/home/ludo/uClinux/uClinux-dist/linux/arch/m68knommu/kernel'
make[2]: Entre dans le r?pertoire
`/home/ludo/uClinux/uClinux-dist/linux/arch/m68knommu/mm'
if [ -n "fault.c init.c memory.c" ]; then \
/home/ludo/uClinux/uClinux-dist/linux/scripts/mkdep
*.[chS] > .depend; fi
make[2]: Quitte le r?pertoire
`/home/ludo/uClinux/uClinux-dist/linux/arch/m68knommu/mm'
make[2]: Entre dans le r?pertoire
`/home/ludo/uClinux/uClinux-dist/linux/arch/m68knommu/lib'
if [ -n "ashrdi3.c bzero.c checksum.c memcmp.c
memcpy.c memset.c semaphore.S" ]; then \
/home/ludo/uClinux/uClinux-dist/linux/scripts/mkdep
*.[chS] > .depend; fi
make[2]: Quitte le r?pertoire
`/home/ludo/uClinux/uClinux-dist/linux/arch/m68knommu/lib'
make[2]: Entre dans le r?pertoire
`/home/ludo/uClinux/uClinux-dist/linux/arch/m68knommu/platform/5307'
if [ -n "bios32.c config.c entry.S ints.c signal.c" ];
then \
/home/ludo/uClinux/uClinux-dist/linux/scripts/mkdep
*.[chS] > .depend; fi
make[2]: Quitte le r?pertoire
`/home/ludo/uClinux/uClinux-dist/linux/arch/m68knommu/platform/5307'
make[2]: Entre dans le r?pertoire
`/home/ludo/uClinux/uClinux-dist/linux/kernel'
m68k-elf-gcc -g -D__KERNEL__
-I/home/ludo/uClinux/uClinux-dist/linux/include -g
-Wall -Wstrict-prototypes -O1 -fno-strength-reduce
-I/include
-pipe -DNO_MM -DNO_FPU -m5307 -Wa,-S -D__ELF__
-DMAGIC_ROM_PTR  -DUTS_SYSNAME='"uClinux"' -E
-D__GENKSYMS__ ksyms.c | /sbin/genksyms
/home/ludo/uClinux/uClinux-dist/linux/include/linux/modules
      ------------------------------------- 
/bin/sh: m68k-elf-gcc: command not found
       ------------------------------------
make[2]: ***
[/home/ludo/uClinux/uClinux-dist/linux/include/linux/modules/ksyms.ver]
Erreur 139
make[2]: Quitte le r?pertoire
`/home/ludo/uClinux/uClinux-dist/linux/kernel'
make[1]: *** [dep-files] Erreur 2
make[1]: Quitte le r?pertoire
`/home/ludo/uClinux/uClinux-dist/linux'
make: *** [dep] Erreur 2
[root at localhost uClinux-dist]#



___________________________________________________________
Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en fran?ais !
Yahoo! Mail : http://fr.mail.yahoo.com
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From arne.jonsson at i3micro.com  Fri Apr  5 06:28:39 2002
From: arne.jonsson at i3micro.com (Arne Jonsson)
Date: Fri, 05 Apr 2002 13:28:39 +0200
Subject: [uClinux-dev] One ethernet, dual IP addresses?
References: <3CAD7178.7A9982F1@i3micro.com> <20020405211933.A22009@beast.internal.moreton.com.au>
Message-ID: <3CAD8A67.CD9853B0@i3micro.com>


> This is possible on uClinux using ifconfig and IP Aliasing,  you just
> configure eth0:1 eth0:2 and so on.
> 
> You need to enable the kernel options to use this.
> 
> If you don't have ifconfig or a shell,  then you will need to look at how
> ifconfig does it's thing and make whatever user program you have do that :-)
Thanks, I was afraid of that!! ;-)

Cheers, 
Arne Jonsson
---
i3 micro technology AB
Phone:+46-8-506 388 00
Fax:  +46-8-506 388 75
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From philwil at earthlink.net  Fri Apr  5 06:47:13 2002
From: philwil at earthlink.net (Phil Wilshire)
Date: Fri, 05 Apr 2002 06:47:13 -0500
Subject: [uClinux-dev] Problems in instaling devlopment tools for M5307C3
References: <20020405112722.30410.qmail@web20001.mail.yahoo.com>
Message-ID: <3CAD8EC1.B94C12F8@earthlink.net>

Hello Ludo.

Some help perhaps !!!

you need to install the tool chain as root under /


cd /
tar xvzf /pathtotools

then when you do a 

which m68k-elf-gcc

you should find it .


if this does not work make sure that your path includes
the directory holding m68k-elf-gcc

so if it is
/usr/local/bin/m68k-elf-gcc

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

may help

regards
   Phil Wilshire

"Ludo G.L." wrote:
> 
> [uClinux-dev]
> 
> Hello.
> 
> I'm a french student in Informatique. In order to
> perform my studies, I need
> to realise a project. So, I must power a embeded
> system on the M5307C3 Motorola's
> board (which function with a ColdFire ?processor).
> I already try to install the uClinux OS on the board
> but, I have problems when
> I want to install the devlopment tools on my PC
> system.
> Can you explain me how to process to install the uC
> kernel and, it devlopement
> tool, step to step (I probably have forgoten
> something).
> I have download, the files from your site
> www.uclinux.org, but I still have
> problems to install them (I'm a novice in Linux
> programing).
> I have install m68k-elf-tools-20020218.tar.gz and
> uClinux-dist-20011112.tar.gz too.
> 
> Who helps a newbie ?
> 
> Ludovic GUILLET
> 
> lgltoludo at yahoo.fr
> 
> Note:
> -----
> First, I do the "make xconfig"
> Then, I do the "make dep"
> and an error appears:(look at the end)
> 
> [root at localhost uClinux-dist]# make dep
> make -C linux dep
> make[1]: Entre dans le r?pertoire
> `/home/ludo/uClinux/uClinux-dist/linux'
> echo Platform 5307 Board  Model ram
> Platform 5307 Board Model ram
> scripts/mkdep init/*.c > .tmpdepend
> scripts/mkdep `find
> /home/ludo/uClinux/uClinux-dist/linux/include/asm
> /home/ludo/uClinux/uClinux-dist/linux/include/linux
> /home/ludo/uClinux/uClinux-dist/linux/include/scsi
> /home/ludo/uClinux/uClinux-dist/linux/include/net
> -follow -name \*.h ! -name modversions.h -print` >
> .hdepend
> set -e; for i in arch/m68knommu/kernel
> arch/m68knommu/mm arch/m68knommu/lib
> arch/m68knommu/platform/5307 kernel drivers fs net ipc
> lib mmnommu; do make -C $i fastdep; done
> make[2]: Entre dans le r?pertoire
> `/home/ludo/uClinux/uClinux-dist/linux/arch/m68knommu/kernel'
> if [ -n "console.c ksyms.c process.c ptrace.c setup.c
> sys_m68k.c time.c traps.c" ]; then \
> /home/ludo/uClinux/uClinux-dist/linux/scripts/mkdep
> *.[chS] > .depend; fi
> make[2]: Quitte le r?pertoire
> `/home/ludo/uClinux/uClinux-dist/linux/arch/m68knommu/kernel'
> make[2]: Entre dans le r?pertoire
> `/home/ludo/uClinux/uClinux-dist/linux/arch/m68knommu/mm'
> if [ -n "fault.c init.c memory.c" ]; then \
> /home/ludo/uClinux/uClinux-dist/linux/scripts/mkdep
> *.[chS] > .depend; fi
> make[2]: Quitte le r?pertoire
> `/home/ludo/uClinux/uClinux-dist/linux/arch/m68knommu/mm'
> make[2]: Entre dans le r?pertoire
> `/home/ludo/uClinux/uClinux-dist/linux/arch/m68knommu/lib'
> if [ -n "ashrdi3.c bzero.c checksum.c memcmp.c
> memcpy.c memset.c semaphore.S" ]; then \
> /home/ludo/uClinux/uClinux-dist/linux/scripts/mkdep
> *.[chS] > .depend; fi
> make[2]: Quitte le r?pertoire
> `/home/ludo/uClinux/uClinux-dist/linux/arch/m68knommu/lib'
> make[2]: Entre dans le r?pertoire
> `/home/ludo/uClinux/uClinux-dist/linux/arch/m68knommu/platform/5307'
> if [ -n "bios32.c config.c entry.S ints.c signal.c" ];
> then \
> /home/ludo/uClinux/uClinux-dist/linux/scripts/mkdep
> *.[chS] > .depend; fi
> make[2]: Quitte le r?pertoire
> `/home/ludo/uClinux/uClinux-dist/linux/arch/m68knommu/platform/5307'
> make[2]: Entre dans le r?pertoire
> `/home/ludo/uClinux/uClinux-dist/linux/kernel'
> m68k-elf-gcc -g -D__KERNEL__
> -I/home/ludo/uClinux/uClinux-dist/linux/include -g
> -Wall -Wstrict-prototypes -O1 -fno-strength-reduce
> -I/include
> -pipe -DNO_MM -DNO_FPU -m5307 -Wa,-S -D__ELF__
> -DMAGIC_ROM_PTR  -DUTS_SYSNAME='"uClinux"' -E
> -D__GENKSYMS__ ksyms.c | /sbin/genksyms
> /home/ludo/uClinux/uClinux-dist/linux/include/linux/modules
>       -------------------------------------
> /bin/sh: m68k-elf-gcc: command not found
>        ------------------------------------
> make[2]: ***
> [/home/ludo/uClinux/uClinux-dist/linux/include/linux/modules/ksyms.ver]
> Erreur 139
> make[2]: Quitte le r?pertoire
> `/home/ludo/uClinux/uClinux-dist/linux/kernel'
> make[1]: *** [dep-files] Erreur 2
> make[1]: Quitte le r?pertoire
> `/home/ludo/uClinux/uClinux-dist/linux'
> make: *** [dep] Erreur 2
> [root at localhost uClinux-dist]#
> 
> ___________________________________________________________
> Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en fran?ais !
> Yahoo! Mail : http://fr.mail.yahoo.com
> This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From eric.bosch at fourtress.nl  Fri Apr  5 06:58:34 2002
From: eric.bosch at fourtress.nl (Eric Bosch (Fourtress))
Date: Fri, 5 Apr 2002 13:58:34 +0200
Subject: [uClinux-dev] Newbie: How can I restore the old values of the image of uCsimm (MC68EZ328)
Message-ID: <OHEGKBKJNDMIKNAMMKBMKEEBCAAA.eric.bosch@fourtress.nl>

Hello all,

I'am a newbie and have a big problem. I have changed the settings of the COM
port of the uCsimm (MC68EZ328 dragonball board) in COM2 (/dev/ttyS1). But
the uCsimm has only COM1 (/dev/ttyS0). So when I restart minicom and I press
the reset button there isn't a connection. Before I changed the environment
variable in uCsimm it works OK. So I can't communicatie (serial) with the
dragonball board.

The most important question is: How can I restore the old values of the
image of the uCsimm.

Help me please the solve this big problem.

Rgds Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20020405/e5796ef6/attachment.html>

From eauth at softsys.co.at  Fri Apr  5 07:02:22 2002
From: eauth at softsys.co.at (Erwin Authried)
Date: Fri, 5 Apr 2002 14:02:22 +0200
Subject: [uClinux-dev] How start uClinux from a bootloader?
Message-ID: <01C1DCAA.82CFEBE0@smithwicks.softsys.co.at>

Stefan Jonsson[SMTP:stefan.jonsson at faltcom.se] wrote:
> Hello list,
> 
> I am usin EB40 + MEC01 and in order to not do any soldering on the EB40 I
> have decided to not boot from the MEC:s flash. I am modifying the bootloader
> from Atmel to set up the MEC (and putting in a flash programmer as well).

Why don't you place a jump into your onboard flash to jump to the additional flash? 
BTW, if you use the 2.4 kernel you can't (yet) run the kernel from flash without
additional modifications on the kernel. There are some variables located inside the 
kernel's address space. Let the flames roll in if I'm wrong.

> But then what? How do I actually start up uClinux after boot of the card? Do
> I call for the linux-init-process or something? How is that done? I have
> never done this before.
> 

Basically, you will need /sbin/init and /etc/rc. The kernel will look for init and execute it.
init will then call /etc/rc. I think an (empty) /etc/inittab is required too.

-Erwin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/ms-tnef
Size: 1934 bytes
Desc: not available
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20020405/a512f657/attachment.bin>

From davidm at snapgear.com  Fri Apr  5 07:25:38 2002
From: davidm at snapgear.com (David McCullough)
Date: Fri, 5 Apr 2002 22:25:38 +1000
Subject: [uClinux-dev] Problems in instaling devlopment tools for M5307C3
In-Reply-To: <20020405112722.30410.qmail@web20001.mail.yahoo.com>; from lgltoludo@yahoo.fr on Fri, Apr 05, 2002 at 01:27:22PM +0200
References: <3CAD7E85.66E53593@i3micro.com> <20020405112722.30410.qmail@web20001.mail.yahoo.com>
Message-ID: <20020405222538.A22372@beast.internal.moreton.com.au>


Jivin Ludo G.L. lays it down ...
> -DMAGIC_ROM_PTR  -DUTS_SYSNAME='"uClinux"' -E
> -D__GENKSYMS__ ksyms.c | /sbin/genksyms
> /home/ludo/uClinux/uClinux-dist/linux/include/linux/modules
>       ------------------------------------- 
> /bin/sh: m68k-elf-gcc: command not found
>        ------------------------------------
> make[2]: ***
> [/home/ludo/uClinux/uClinux-dist/linux/include/linux/modules/ksyms.ver]
> Erreur 139
> make[2]: Quitte le r?pertoire
> `/home/ludo/uClinux/uClinux-dist/linux/kernel'
> make[1]: *** [dep-files] Erreur 2
> make[1]: Quitte le r?pertoire
> `/home/ludo/uClinux/uClinux-dist/linux'
> make: *** [dep] Erreur 2
> [root at localhost uClinux-dist]#


Add /usr/local/bin to your path,  thats where the tools are:

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

Cheers,
Davidm

-- 
David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
davidm at snapgear.com  Fx: +61 7 3891 3630  825 Stanley St., W'gabba QLD 4102, Oz
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From mathias.fritzson at mecel.se  Fri Apr  5 07:57:21 2002
From: mathias.fritzson at mecel.se (mathias.fritzson at mecel.se)
Date: Fri, 5 Apr 2002 14:57:21 +0200
Subject: [uClinux-dev] Ramdisk, romfs, etc..
Message-ID: <200204051255.g35CtQA05995@<uclinux-dev@uclinux.org>clinux.org>



Done some more reaserch.. I believe that the romfs created is either
mounted
incorrect or corrupt. I added a simple file in the root and a few
directories
but those didn't open either..

So does anyone have a simple romfs image that I can test, compiled for a
683*
processor.. I'll append my romfs.img, got an init in /bin I'm not sure what
the effects from this romdisk are but it should be safe, no apps or
anything compiled into it..

Thanks once again

Regards

/Mathias

>Davidm wrote:
>>Jivin mathias.fritzson at mecel.se lays it down ...
>>> Hi
>>>
>>> Mounting a filesystem in ram isn't too easy if you are a newbie like
me..
>>> I've tried a couple of things but how am I supposed to do?
>>>
>>> Setup: All in ram exept the bootloader, we are loading everything into
>>> memory though a BDM for now.
>>>
>>> I'd like to see a working prompt soon =) this is why I do as I do..
>>>
>>> The final working product will load the kernel from an memorymapped
compact
>>> flash card (Bootloader working) running (for now) a  FAT filesytem. We
will
>>> also try to mount our rootfilesystem from here..
>>>
>>> But to reach a  prompt soon (there is a new micrcontroller port
>>> (68336-'376) and new board support involved so we'd like to verify that
the
>>> port is working fast..) we decided to create a romfs and put it in ram
to
>>> get it all up and running. What do we need to succed with this? What
we've
>>> dome more exactly is to compile with romfs support and ramdisk support
(do
>>> we need a ramdisk ??).
>>
>>
>>No you don't need a ramdisk,  but it's a very good idea to put /tmp and
>>/var/tmp on a ramdisk somewhere :-)
>>
>Ok, will have to research that area later then =)
>
>
>>
>>> Latest compile rendered this output (some homemade debug outputs...)
>>>
>>> snip..
>>> ...
>>> MC68332 serial driver version 1.00
>>> ttyS0 is a builtin MC68332 UART
>>> DEBUG: after chr_dev_init
>>> Ramdisk driver initialized : 16 ramdisks of 4096K size
>>> DEBUG: inside blkmem_init, sizeof(arena): 26, sizeof(struct arena_t):
26, arena[
>>> 0].address: 8524a0, arenas: 1
>>> Blkmem copyright 1998,1999 D. Jeff Dionne
>>> Blkmem copyright 1998 Kenneth Albanowski
>>> Blkmem 1 disk images:
>>> 0: 8524A0-86289F (RO)
>>> DEBUG: identify_ramdisk_image, fp->f_inode: 8fbe82, fp: 8fbd4a, buf:
875414 , si
>>> ze: 200
>>> RAMDISK: Couldn't find valid ramdisk image starting at 0.
>>> VFS: Mounted root (romfs filesystem).
>>> DEBUG: inside init (CONFIG_BLK_DEV_INITRD)
>>> Unable to open an initial console.
>>> DEBUG: trying to run init
>>> DEBUG: do_rc
>>> Failed to free page
>>> Failed to free page
>>> Failed to free page
>>> ...
>>> snip...
>>
>>
>>Looks good,  found the romfs and mounted it.
>>
>>"Unable to open an initial console" could point to a bad /dev dir in the
>>romfs.  You need to be sure that /dev is setup properly.  The
uClinux-dist
>>has plenty of examples on doing this and adding your changes should not
be
>>a very large task at all.  If you are using the symbolic device entries
>>(ie., @dev,c,N,M) make sure you are actually using the correct version
>>of genromfs (version 0.5.1 is good).
>
>This is what I thought could be a problem... If you have a look in the
>romfs tree in the reply I made to myself the devices are /dev/@tty,c,5,0
>instead of what I suppose they should be (/dev/tty,c,5,0). The tools are
>the latest m68k-elf-tools-20020218.tar.gz package running under
>VMware/Debian 2.2.5, so we use genromfs 0.5.1..
>
>>
>>The "Failed to free page" errors are a big concern.  Make sure the memory
>>containing the romfs is reserved and not being allocated or re-used.
>
>How do I make sure this happens ?? There are some memory reserved during
>the boot...
>
>snip..
>Memory available: 560k/1019k RAM, 512k/512k ROM (209k kernel code, 118k
>data), 3
>3 pages reserved (132k)
>snip..
>
>..but I assume those 132k aren't for the romfs =) i.e help a newbie to
>reserve memory for the romfs..
>
>Actually those "Failed to free page" just appeared this testrun the output
>usually ends with the "DEBUG: do_rc"
>
>>
>>> We've included busybox and would like to use it as the shell..
>>> Any special procedures involved to use busybox??
>>
>>
>>Again the uClinux-dist has good busybox support on uClinux and takes care
>>of the setup for you.
>>
>>Be careful with the shell's in busybox,  most are not suitable for
uClinux.
>>The Minix shell is the only one I can think of that might work depending
>>on what busybox version you have.
>>
>>To get the system going quickly I suggest you go with sash,  then more on
>>to something better if you need to.
>
>Thanks for the tip =)
>>
>>Cheers,
>>Davidm
>>
>Thanks for the help so far =)
>
>/Mathias

(See attached file: romfs.img)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: romfs.img
Type: application/octet-stream
Size: 66560 bytes
Desc: not available
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20020405/109fd7cd/attachment.obj>

From aran at iekey.nl  Fri Apr  5 08:40:39 2002
From: aran at iekey.nl (Aran Benner)
Date: Fri, 05 Apr 2002 15:40:39 +0200
Subject: [uClinux-dev] binary tools for Solaris
Message-ID: <3.0.6.32.20020405154039.007d3e30@iekey221>


This is probably an incredible newbie question, but is the binary toolchain
available on www.uclinux.org (m68k-elf-tools-20020218.tar.gz) suitable for
use on a Solaris (intel/8) development platform? 

I've downloaded a source snapshot and want to compile this for a M5272
system but I get various errors and have the feeling my cross-compiler and
other tools aren't installed correctly.

Any help would be greatly appreciated.

regards,

Aran Benner

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From davidm at snapgear.com  Fri Apr  5 09:16:19 2002
From: davidm at snapgear.com (David McCullough)
Date: Sat, 6 Apr 2002 00:16:19 +1000
Subject: [uClinux-dev] Ramdisk, romfs, etc..
In-Reply-To: <200204051255.g35CtQA05995@<uclinux-dev@uclinux.org>; from mathias.fritzson@mecel.se on Fri, Apr 05, 2002 at 02:57:21PM +0200
References: <200204051255.g35CtQA05995@<uclinux-dev@uclinux.org>
Message-ID: <20020406001619.B22532@beast.internal.moreton.com.au>


Jivin mathias.fritzson at mecel.se lays it down ...
> 
> 
> Done some more reaserch.. I believe that the romfs created is either
> mounted
> incorrect or corrupt. I added a simple file in the root and a few
> directories
> but those didn't open either..

A quick look at your romfs looked ok.  Make sure the genromfs you are using
is the one from the m68k-elf-tools (or similar).  A lot of systems (esp.
RedHat) have an older genromfs installed in /usr/bin that cannot handle the
'@' special files in /dev.  Run 'type genromfs' to see which one you are
using.

Which kernel (2.0/2.4) are you running ?

Look in the arch specific startup code for your platform and find where it
reserves the kernel memory.  Then check that your in-ram-romfs is inside
the reserved area.  Double check the last page (4k) as a round down can give
very interesting results.


> So does anyone have a simple romfs image that I can test, compiled for a
> 683*
> processor.. I'll append my romfs.img, got an init in /bin I'm not sure what
> the effects from this romdisk are but it should be safe, no apps or
> anything compiled into it..


Sorry,  don't have one of those, but someone on the list may :-)

Cheers,
Davidm

-- 
David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
davidm at snapgear.com  Fx: +61 7 3891 3630  825 Stanley St., W'gabba QLD 4102, Oz
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From gerg at snapgear.com  Fri Apr  5 09:24:34 2002
From: gerg at snapgear.com (Greg Ungerer)
Date: Sat, 06 Apr 2002 00:24:34 +1000
Subject: [uClinux-dev] uClinux support for the new Motorola 5249 ColdFire CPU
Message-ID: <3CADB3A2.9070001@snapgear.com>


Hi All,

I want to announce uClinux support for the new Motorola 5249
ColdFire CPU. Specifically on the Motorola M5249C3 development
board.

Currenty I have only patched 2.0.x uClinux, 2.4.x support to
follow soon. Code is CVS'ed at http://cvs.uclinux.org.
The next distribution snapshot will have full target support
for the M5249C3 board too.

The standard ColdFire peripherals are working, UART, timer,
interrupts. I have cranked the internal PLL up to 140MHz.
Everything looks good, this is a fast chip!

Couple of things still to do. The ethernet support is not fully
working yet, and there is no real support for the audio device.

Regards
Greg



------------------------------------------------------------------------
uClinux/COLDFIRE(m5249)
COLDFIRE port done by Greg Ungerer, gerg at snapgear.com
Flat model support (C) 1998,1999 Kenneth Albanowski, D. Jeff Dionne
Calibrating delay loop.. ok - 92.97 BogoMIPS
Memory available: 7196k/8192k RAM, 0k/0k ROM (414k kernel code, 165k data)
Swansea University Computer Society NET3.035 for Linux 2.0
NET3: Unix domain sockets 0.13 for Linux NET3.035.
Swansea University Computer Society TCP/IP for NET3.034
IP Protocols: ICMP, UDP, TCP
uClinux version 2.0.39.uc2 (gerg at goober) (gcc version 2.95.3 20010315 
(release)(ColdFire patches - 20010318 from 
http://fiddes.net/coldfire/)(-msep-data patches)) 130 Tue Mar 26 
16:11:26 EST 2002
ColdFire internal UART serial driver version 1.00
ttyS0 at 0x100001c0 (irq = 73) is a builtin ColdFire UART
ttyS1 at 0x10000200 (irq = 74) is a builtin ColdFire UART
Ramdisk driver initialized : 16 ramdisks of 4096K size
Blkmem copyright 1998,1999 D. Jeff Dionne
Blkmem copyright 1998 Kenneth Albanowski
Blkmem 1 disk images:
0: B10D0-DA4CF (RO)
PPP: version 2.3.8 (demand dialling)
TCP compression code copyright 1989 Regents of the University of California
PPP line discipline registered.
PPP MPPE compression registered
SLIP: version 0.8.4-NET3.019-NEWTTY (dynamic channels, max=256).
CSLIP: code copyright 1989 Regents of the University of California.
LAN91C111:smc_init_91C111
smc91111.c:v1.1 01/29/02 by Kendrick Hamilton (hamilton at sedsystems.ca)
eth0: SMC91C11xFD(rev:0) at 0x30000300 IRQ:166 MEMSIZE:8192b NOWAIT:0
	ADDR: 00:cf:52:49:c3:01
VFS: Mounted root (romfs filesystem) readonly.
Shell invoked to run file: /etc/rc
Command: hostname uClinux
Command: /bin/expand /etc/ramfs.img /dev/ram0
Command: mount -t proc proc /proc
Command: mount -t ext2 /dev/ram0 /var
Command: mkdir /var/tmp
Command: mkdir /var/log
Command: mkdir /var/run
Command: mkdir /var/lock
Command: #ifconfig lo 127.0.0.1
Command: #route add -net 127.0.0.0 netmask 255.0.0.0 lo
Command: #dhcpcd -p -a eth0 &
Command: cat /etc/motd
Welcome to
           ____ _  _
          /  __| ||_|
     _   _| |  | | _ ____  _   _  _  _
    | | | | |  | || |  _ \| | | |\ \/ /
    | |_| | |__| || | | | | |_| |/    \
    |  ___\____|_||_|_| |_|\____|\_/\_/
    | |
    |_|

For further information check:
http://www.uclinux.org/

Execution Finished, Exiting?
Sash command shell (version 1.1.1)
/>
/> cat /proc/cpuinfo
CPU: 
	COLDFIRE(m5249)
MMU: 
	none
FPU: 
	none
Clocking: 
139.4MHz
BogoMips: 
92.97
Calibration: 
46489600 loops
/>

------------------------------------------------------------------------
Greg Ungerer  --  Chief Software Wizard        EMAIL:  gerg at snapgear.com
SnapGear                                       PHONE:    +61 7 3279 1822
825 Stanley St,                                  FAX:    +61 7 3279 1820
Woolloogabba, QLD, 4102, Australia               WEB:   www.snapgear.com

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From hamilton at SEDSystems.ca  Fri Apr  5 09:44:41 2002
From: hamilton at SEDSystems.ca (Kendrick Hamilton)
Date: Fri, 5 Apr 2002 08:44:41 -0600 (Canada Central Standard Time)
Subject: [uClinux-dev] One ethernet, dual IP addresses?
In-Reply-To: <3CAD8A67.CD9853B0@i3micro.com>
Message-ID: <Pine.WNT.4.44.0204050842390.194-100000@sw-55.sedsystems.ca>

Hi,
	Is it possible to have two ethernet with one IP address. If one
ethernet detects the LAN has failed, the other ethernet takes over with
the same address (redundant LAN)?

TIA,
Kendrick

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From mathias.fritzson at mecel.se  Fri Apr  5 10:45:51 2002
From: mathias.fritzson at mecel.se (mathias.fritzson at mecel.se)
Date: Fri, 5 Apr 2002 17:45:51 +0200
Subject: [uClinux-dev] 
Message-ID: <200204051543.g35FhsA07747@<uclinux-dev@uclinux.org>clinux.org>

Thanks David

My mails doesn't show in the archive, seems odd..

>Jivin mathias.fritzson at mecel.se lays it down ...
>>
>>
>> Done some more reaserch.. I believe that the romfs created is either
>> mounted
>> incorrect or corrupt. I added a simple file in the root and a few
>> directories
>> but those didn't open either..
>
>
>A quick look at your romfs looked ok. Make sure the genromfs you are using
>is the one from the m68k-elf-tools (or similar). A lot of systems (esp.
>RedHat) have an older genromfs installed in /usr/bin that cannot handle the
>'@' special files in /dev. Run 'type genromfs' to see which one you are
>using.
>
Thank you for your time !

Got genromfs 0.5.1 running from /usr/local/bin/ the same directory as the m68k-elf-gcc
runs from.. So I think I got the right one especially since you got it working..

>
>Which kernel (2.0/2.4) are you running ?
>

2.0
(uClinux version 2.0.39.1 (Administrator at MEG-227) (gcc version 2.95.3 20010315 (release)
(ColdFire patches - 20010318 from http://fiddes.net/coldfire/)(-msep-data patches)) 382 Fri
Apr 5 17:23:33 2002)

I don't compile the kernel at the same machine as I compile the romfs.. It's an older version
of the tools that we compiled for cygwin, and we don't have time to recompile for every new
(great) release of the tools. But we have the possability to compile on the VMware box if
neccesary.

>
>Look in the arch specific startup code for your platform and find where it
>reserves the kernel memory. Then check that your in-ram-romfs is inside
>the reserved area. Double check the last page (4k) as a round down can give
>very interesting results.
>

I couldn't find the place in the code where the kernel reserves memory, but I made a test
and printed out the addresses of the reserved pages and I got the romfs inside the
reserved area. There are plenty of room in there romfs.img is 65k and the reserved space
is 132k so the last 4k should be safe I guess...

>
>
>> So does anyone have a simple romfs image that I can test, compiled for a
>> 683*
>> processor.. I'll append my romfs.img, got an init in /bin I'm not sure what
>> the effects from this romdisk are but it should be safe, no apps or
>> anything compiled into it..
>
>
>
>Sorry, don't have one of those, but someone on the list may :-)
>

Lets hope for that =)

Thanks once more..

Have a good weekend I will for sure =)

/Mathias



This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From justin.wojdacki at analog.com  Fri Apr  5 14:31:04 2002
From: justin.wojdacki at analog.com (Justin Wojdacki)
Date: Fri, 05 Apr 2002 11:31:04 -0800
Subject: [uClinux-dev] How start uClinux from a bootloader?
References: <NGBBJKACILMHGKHMEHHLCEIFCAAA.stefan.jonsson@faltcom.se>
Message-ID: <3CADFB78.C43A0B7@analog.com>

Stefan Jonsson wrote:
> 
> Hello list,
> 
> I am usin EB40 + MEC01 and in order to not do any soldering on the EB40 I
> have decided to not boot from the MEC:s flash. I am modifying the bootloader
> from Atmel to set up the MEC (and putting in a flash programmer as well).
> But then what? How do I actually start up uClinux after boot of the card? Do
> I call for the linux-init-process or something? How is that done? I have
> never done this before.
> 

Unless you're trying to XIP from flash, you'll want to copy the kernel
from flash to RAM. Then, you'll jump to the kernel entry point
(kernel_entry in MIPS, stext in ARM, startup_32 in i386, why it's
different across platforms, I don't know). The kernel will need to be
able to find a root filesystem (see drivers/block/blkmem.c for what
you need to setup a ROMFS partition). In that root filesystem, there
should be an /sbin/init program. That's about all you need (along with
some patience and some good debugging skills). 

-- 
-------------------------------------------------
Justin Wojdacki        
justin.wojdacki at analog.com         (408) 350-5032
Communications Processors Group -- Analog Devices
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From justin.wojdacki at analog.com  Fri Apr  5 14:36:27 2002
From: justin.wojdacki at analog.com (Justin Wojdacki)
Date: Fri, 05 Apr 2002 11:36:27 -0800
Subject: [uClinux-dev] binary tools for Solaris
References: <3.0.6.32.20020405154039.007d3e30@iekey221>
Message-ID: <3CADFCBB.E66B5A33@analog.com>

Aran Benner wrote:
> 
> This is probably an incredible newbie question, but is the binary toolchain
> available on www.uclinux.org (m68k-elf-tools-20020218.tar.gz) suitable for
> use on a Solaris (intel/8) development platform?
> 
> I've downloaded a source snapshot and want to compile this for a M5272
> system but I get various errors and have the feeling my cross-compiler and
> other tools aren't installed correctly.
> 
> Any help would be greatly appreciated.
> 
> regards,
> 
> Aran Benner
> 

The binaries are meant for Linux/x86. Don't know if Solaris/x86 has a
Linux emulation layer, but if it doesn't, you'll need to download the
source for the tools and build them yourself (give yourself a day for
this, maybe three if you haven't done it before).

What errors are you currently seeing? 

-- 
-------------------------------------------------
Justin Wojdacki        
justin.wojdacki at analog.com         (408) 350-5032
Communications Processors Group -- Analog Devices
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From sams2 at telusplanet.net  Fri Apr  5 17:17:46 2002
From: sams2 at telusplanet.net (Sam Saprunoff)
Date: Fri, 5 Apr 2002 15:17:46 -0700
Subject: [uClinux-dev] Unable to access www.uclinux.org/bkuhn archive
References: <3C9D01BC.E6618CC7@lineo.com> <004301c1d34d$9d5c50e0$b782fea9@sympatico.ca>
Message-ID: <00b001c1dcef$b69929b0$6fa0b8a1@DELL250GTO>

Good day Michael and everyone,

I have tried several times to access the archive location as given in your
previous post, but have been unable to do so.  Have you decided not to
archive Mr. Kuhn's info, or has it been relocated somewhere else?

Thanks in advance!

Cheers,

Sam

Sam Saprunoff
sams2 at telusplanet.net

S Squared Innovations Inc.
Edmonton, AB  Canada
Tel: (780) 944-1415
Fax: (780) 944-1861

----- Original Message -----
From: "Michael Durrant" <mdurrant at uclinux.org>
To: <uclinux-dev at uclinux.org>
Sent: Sunday, March 24, 2002 9:04 AM
Subject: Re: [uClinux-dev] [Announcement] Software archive closed down


> Bernhard et al.
>
> We should have the archive mirrored on www.uclinux.org
> in the next few days as www.uclinux.org/bkuhn
>
> --
> Michael
> mdurrant at uclinux.org
>
>
> ----- Original Message -----
> From: "Bernhard Kuhn" <bkuhn at lineo.com>
> To: <uclinux-dev at uclinux.org>
> Sent: Saturday, March 23, 2002 5:29 PM
> Subject: [uClinux-dev] [Announcement] Software archive closed down
>
>
> >
> > Hi Everybody!
> >
> > My former employer, the Institute of Real-Time Computer Systems,
> > thankfully provided me with write access to it's web server for
> > nearly three years since i quit. But now, the Institute has to
> > restrict the usage of it's resources for former employees.
> >
> > So i removed my Real Time Linux and uClinux software archives
> > from the server.
> >
> > I will try to find a new home for the archives and supply the
> > alternative URL. For those interessted in hosting the software
> > archives in the mean while may download them from
> >
> > http://www.rcs.ei.tum.de/~kuhn/realtime+uclinux.tar.bz2
> >
> > Hopefully the tarball will be still available 'til mid
> > of the next week before it gets deleted :-)
> >
> > best regards
> >
> > Bernhard
> >
> >
> >
> > --
> > Bernhard Kuhn, Software Engineer, Lineo Inc. (Where Open Meets Smart)
> > This message resent by the uclinux-dev at uclinux.org list server
> http://www.uClinux.org/
> >
>
> This message resent by the uclinux-dev at uclinux.org list server
http://www.uClinux.org/
>


This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From davidm at snapgear.com  Fri Apr  5 18:46:13 2002
From: davidm at snapgear.com (David McCullough)
Date: Sat, 6 Apr 2002 09:46:13 +1000
Subject: [uClinux-dev]
In-Reply-To: <200204051543.g35FhsA07747@<uclinux-dev@uclinux.org>; from mathias.fritzson@mecel.se on Fri, Apr 05, 2002 at 05:45:51PM +0200
References: <200204051543.g35FhsA07747@<uclinux-dev@uclinux.org>
Message-ID: <20020406094613.A24738@beast.internal.moreton.com.au>



Jivin mathias.fritzson at mecel.se lays it down ...
> Thanks David
> 
> My mails doesn't show in the archive, seems odd..

The archive may not be up to date or something.  I am seeing your replies
on the list which is all that should be required.

...
> I don't compile the kernel at the same machine as I compile the romfs.. It's an older version
> of the tools that we compiled for cygwin, and we don't have time to recompile for every new
> (great) release of the tools. But we have the possability to compile on the VMware box if
> neccesary.


if you are using new tools for the applications,  but an old kernel flat
loader you may have some problems there.

Make sure you get the latest binfmt_flat.c and flat.h and add them to your
kernel tree is you are using the latest tools to build applications.

Cheers,
Davidm

-- 
David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
davidm at snapgear.com  Fx: +61 7 3891 3630  825 Stanley St., W'gabba QLD 4102, Oz
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From justin.wojdacki at analog.com  Fri Apr  5 19:44:20 2002
From: justin.wojdacki at analog.com (Justin Wojdacki)
Date: Fri, 05 Apr 2002 16:44:20 -0800
Subject: [uClinux-dev] subtleties of vfork
Message-ID: <3CAE44E4.380E8996@analog.com>


Can someone describe to me exactly what is supposed to happen in a
vfork() in uCLinux? 

Does the child process execute in the same block of memory as the
parent? Or does it operate in a copy of it? And then what happens on a
subsequent exec()? 

What I'm seeing right now looks like the child is executing code from
the parent's address space, but it's state (stack pointer, etc.) lives
in a new process address range (including, in part, some invalid base
addresses).

-- 
-------------------------------------------------
Justin Wojdacki        
justin.wojdacki at analog.com         (408) 350-5032
Communications Processors Group -- Analog Devices
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From michael at michaelshiloh.com  Fri Apr  5 21:04:45 2002
From: michael at michaelshiloh.com (michael shiloh)
Date: Fri, 5 Apr 2002 18:04:45 -0800 (PST)
Subject: [uClinux-dev] where can i find m68k-palmos-coff-gcc
Message-ID: <Pine.LNX.4.33.0204051802210.11921-100000@magritte.magrittesystems.com>

hello,

dan trainor asked this in january, and i searched the
archive but saw no answer. i'm trying to build an
image for my palm5. my build fails at:

  make[2]: Entering directory
  `/opt/uClinux/uClinux-dist/vendors/3com/palm-loader'm68k-palmos-coff-gcc
  -c -O2 -static    PalmLoader.c
  make[2]: m68k-palmos-coff-gcc: Command not found

does anyone know where i can find this program?

much thanks in advance,
michael shiloh

-- 

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From mdurrant at uclinux.org  Fri Apr  5 22:10:43 2002
From: mdurrant at uclinux.org (Michael Durrant)
Date: Fri, 5 Apr 2002 22:10:43 -0500
Subject: [uClinux-dev] Unable to access www.uclinux.org/bkuhn archive
References: <3C9D01BC.E6618CC7@lineo.com> <004301c1d34d$9d5c50e0$b782fea9@sympatico.ca> <00b001c1dcef$b69929b0$6fa0b8a1@DELL250GTO>
Message-ID: <009701c1dd18$a5513200$7f82a8c0@sympatico.ca>

We have been in touch with Bernhard and the files should be up
very soon.   Either Bernhard or I will announce to the list when
the page is finally up.

Sorry for the delay
--
Michael


----- Original Message -----
From: "Sam Saprunoff" <sams2 at telusplanet.net>
To: <uclinux-dev at uclinux.org>
Sent: Friday, April 05, 2002 5:17 PM
Subject: [uClinux-dev] Unable to access www.uclinux.org/bkuhn archive


> Good day Michael and everyone,
>
> I have tried several times to access the archive location as given in your
> previous post, but have been unable to do so.  Have you decided not to
> archive Mr. Kuhn's info, or has it been relocated somewhere else?
>
> Thanks in advance!
>
> Cheers,
>
> Sam
>
> Sam Saprunoff
> sams2 at telusplanet.net
>
> S Squared Innovations Inc.
> Edmonton, AB  Canada
> Tel: (780) 944-1415
> Fax: (780) 944-1861
>
> ----- Original Message -----
> From: "Michael Durrant" <mdurrant at uclinux.org>
> To: <uclinux-dev at uclinux.org>
> Sent: Sunday, March 24, 2002 9:04 AM
> Subject: Re: [uClinux-dev] [Announcement] Software archive closed down
>
>
> > Bernhard et al.
> >
> > We should have the archive mirrored on www.uclinux.org
> > in the next few days as www.uclinux.org/bkuhn
> >
> > --
> > Michael
> > mdurrant at uclinux.org
> >
> >
> > ----- Original Message -----
> > From: "Bernhard Kuhn" <bkuhn at lineo.com>
> > To: <uclinux-dev at uclinux.org>
> > Sent: Saturday, March 23, 2002 5:29 PM
> > Subject: [uClinux-dev] [Announcement] Software archive closed down
> >
> >
> > >
> > > Hi Everybody!
> > >
> > > My former employer, the Institute of Real-Time Computer Systems,
> > > thankfully provided me with write access to it's web server for
> > > nearly three years since i quit. But now, the Institute has to
> > > restrict the usage of it's resources for former employees.
> > >
> > > So i removed my Real Time Linux and uClinux software archives
> > > from the server.
> > >
> > > I will try to find a new home for the archives and supply the
> > > alternative URL. For those interessted in hosting the software
> > > archives in the mean while may download them from
> > >
> > > http://www.rcs.ei.tum.de/~kuhn/realtime+uclinux.tar.bz2
> > >
> > > Hopefully the tarball will be still available 'til mid
> > > of the next week before it gets deleted :-)
> > >
> > > best regards
> > >
> > > Bernhard
> > >
> > >
> > >
> > > --
> > > Bernhard Kuhn, Software Engineer, Lineo Inc. (Where Open Meets Smart)
> > > This message resent by the uclinux-dev at uclinux.org list server
> > http://www.uClinux.org/
> > >
> >
> > This message resent by the uclinux-dev at uclinux.org list server
> http://www.uClinux.org/
> >
>
>
> This message resent by the uclinux-dev at uclinux.org list server
http://www.uClinux.org/
>

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From harmony2 at nownuri.net  Fri Apr  5 23:09:29 2002
From: harmony2 at nownuri.net (ÀÌÀ±±¸)
Date: Sat, 6 Apr 2002 13:09:29 +0900 (KST)
Subject: [uClinux-dev] uClinux port and device driver to TMS320DSC21
Message-ID: <200204060409.NAA11812@lion4.nownuri.net>

  Hi, I'm working on TMS320DSC21 with uClinux 2.4.0

  I downloaded the kernel from this site and installed toolchain.

  Now I succeed to boot.

  Now, I want to make the device drivers - LCD, audio, keypad and etc.

  However, I don't know what is the best starting point.

  Is there anybody who has any information?

  any information is welcome.

  Thank you.



--MIME Multi-part separator--

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From sams2 at telusplanet.net  Sat Apr  6 01:15:26 2002
From: sams2 at telusplanet.net (Sam Saprunoff)
Date: Fri, 5 Apr 2002 23:15:26 -0700
Subject: [uClinux-dev] Unable to access www.uclinux.org/bkuhn archive
References: <3C9D01BC.E6618CC7@lineo.com> <004301c1d34d$9d5c50e0$b782fea9@sympatico.ca> <00b001c1dcef$b69929b0$6fa0b8a1@DELL250GTO> <009701c1dd18$a5513200$7f82a8c0@sympatico.ca>
Message-ID: <003101c1dd32$71e2b230$6fa0b8a1@DELL250GTO>

Excellent!

Thanks for the update!

Cheers,

Sam


----- Original Message -----
From: "Michael Durrant" <mdurrant at uclinux.org>
To: <uclinux-dev at uclinux.org>
Sent: Friday, April 05, 2002 8:10 PM
Subject: Re: [uClinux-dev] Unable to access www.uclinux.org/bkuhn archive


> We have been in touch with Bernhard and the files should be up
> very soon.   Either Bernhard or I will announce to the list when
> the page is finally up.
>
> Sorry for the delay
> --
> Michael
>
>
> ----- Original Message -----
> From: "Sam Saprunoff" <sams2 at telusplanet.net>
> To: <uclinux-dev at uclinux.org>
> Sent: Friday, April 05, 2002 5:17 PM
> Subject: [uClinux-dev] Unable to access www.uclinux.org/bkuhn archive
>
>
> > Good day Michael and everyone,
> >
> > I have tried several times to access the archive location as given in
your
> > previous post, but have been unable to do so.  Have you decided not to
> > archive Mr. Kuhn's info, or has it been relocated somewhere else?
> >
> > Thanks in advance!
> >
> > Cheers,
> >
> > Sam
> >
> > Sam Saprunoff
> > sams2 at telusplanet.net
> >
> > S Squared Innovations Inc.
> > Edmonton, AB  Canada
> > Tel: (780) 944-1415
> > Fax: (780) 944-1861
> >
> > ----- Original Message -----
> > From: "Michael Durrant" <mdurrant at uclinux.org>
> > To: <uclinux-dev at uclinux.org>
> > Sent: Sunday, March 24, 2002 9:04 AM
> > Subject: Re: [uClinux-dev] [Announcement] Software archive closed down
> >
> >
> > > Bernhard et al.
> > >
> > > We should have the archive mirrored on www.uclinux.org
> > > in the next few days as www.uclinux.org/bkuhn
> > >
> > > --
> > > Michael
> > > mdurrant at uclinux.org
> > >
> > >
> > > ----- Original Message -----
> > > From: "Bernhard Kuhn" <bkuhn at lineo.com>
> > > To: <uclinux-dev at uclinux.org>
> > > Sent: Saturday, March 23, 2002 5:29 PM
> > > Subject: [uClinux-dev] [Announcement] Software archive closed down
> > >
> > >
> > > >
> > > > Hi Everybody!
> > > >
> > > > My former employer, the Institute of Real-Time Computer Systems,
> > > > thankfully provided me with write access to it's web server for
> > > > nearly three years since i quit. But now, the Institute has to
> > > > restrict the usage of it's resources for former employees.
> > > >
> > > > So i removed my Real Time Linux and uClinux software archives
> > > > from the server.
> > > >
> > > > I will try to find a new home for the archives and supply the
> > > > alternative URL. For those interessted in hosting the software
> > > > archives in the mean while may download them from
> > > >
> > > > http://www.rcs.ei.tum.de/~kuhn/realtime+uclinux.tar.bz2
> > > >
> > > > Hopefully the tarball will be still available 'til mid
> > > > of the next week before it gets deleted :-)
> > > >
> > > > best regards
> > > >
> > > > Bernhard
> > > >
> > > >
> > > >
> > > > --
> > > > Bernhard Kuhn, Software Engineer, Lineo Inc. (Where Open Meets
Smart)
> > > > This message resent by the uclinux-dev at uclinux.org list server
> > > http://www.uClinux.org/
> > > >
> > >
> > > This message resent by the uclinux-dev at uclinux.org list server
> > http://www.uClinux.org/
> > >
> >
> >
> > This message resent by the uclinux-dev at uclinux.org list server
> http://www.uClinux.org/
> >
>
> This message resent by the uclinux-dev at uclinux.org list server
http://www.uClinux.org/
>


This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From davidm at snapgear.com  Sat Apr  6 07:37:25 2002
From: davidm at snapgear.com (David McCullough)
Date: Sat, 6 Apr 2002 22:37:25 +1000
Subject: [uClinux-dev] subtleties of vfork
In-Reply-To: <3CAE44E4.380E8996@analog.com>; from justin.wojdacki@analog.com on Fri, Apr 05, 2002 at 04:44:20PM -0800
References: <3CAE44E4.380E8996@analog.com>
Message-ID: <20020406223725.A25711@beast.internal.moreton.com.au>


Jivin Justin Wojdacki lays it down ...
> 
> Can someone describe to me exactly what is supposed to happen in a
> vfork() in uCLinux? 
> 
> Does the child process execute in the same block of memory as the
> parent? Or does it operate in a copy of it? And then what happens on a
> subsequent exec()? 
> 
> What I'm seeing right now looks like the child is executing code from
> the parent's address space, but it's state (stack pointer, etc.) lives
> in a new process address range (including, in part, some invalid base
> addresses).

Child executes in the same memory and on the same stack.  The child 
cannot return from the current stack frame otherwise it will corrupt
the parents stack.

The man page for vfork covers the text-book parts of using vfork fairly well.

Cheers,
Davidm

-- 
David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
davidm at snapgear.com  Fx: +61 7 3891 3630  825 Stanley St., W'gabba QLD 4102, Oz
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From davidm at snapgear.com  Sat Apr  6 07:46:48 2002
From: davidm at snapgear.com (David McCullough)
Date: Sat, 6 Apr 2002 22:46:48 +1000
Subject: [uClinux-dev] where can i find m68k-palmos-coff-gcc
In-Reply-To: <Pine.LNX.4.33.0204051802210.11921-100000@magritte.magrittesystems.com>; from michael@michaelshiloh.com on Fri, Apr 05, 2002 at 06:04:45PM -0800
References: <Pine.LNX.4.33.0204051802210.11921-100000@magritte.magrittesystems.com>
Message-ID: <20020406224647.C25711@beast.internal.moreton.com.au>


Jivin michael shiloh lays it down ...
> hello,
> 
> dan trainor asked this in january, and i searched the
> archive but saw no answer. i'm trying to build an
> image for my palm5. my build fails at:
> 
>   make[2]: Entering directory
>   `/opt/uClinux/uClinux-dist/vendors/3com/palm-loader'm68k-palmos-coff-gcc
>   -c -O2 -static    PalmLoader.c
>   make[2]: m68k-palmos-coff-gcc: Command not found
> 
> does anyone know where i can find this program?

I found the copy I am using somehere on the web using google and following
my nose.  Have a look around and see how you go.  I don't seem to have the
original archive anymore,  but I could make one if you get desperate.

It's part of a gcc for palmos development,  it was not uClinux related in
any way,

Cheers,
Davidm

-- 
David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
davidm at snapgear.com  Fx: +61 7 3891 3630  825 Stanley St., W'gabba QLD 4102, Oz
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From moh.shiha at ieee.org  Sat Apr  6 10:45:10 2002
From: moh.shiha at ieee.org (Mohamed Ali Shiha)
Date: Sat, 6 Apr 2002 17:45:10 +0200
Subject: [uClinux-dev] Boa web server
Message-ID: <OE1123sllNY30kkZIhT0001b1cb@hotmail.com>

Dear all,

did some one try to compile Boa web server for MC68VZ328 ... ? ... I got a
message telling me that there is a problem in the header files included
...!!!
I am trying to do that with Netdimm SDK board that comes without the source
of Boa ...

Thanks
Mohamed Shiha
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From uclinux at schoeldgen.de  Sat Apr  6 13:24:49 2002
From: uclinux at schoeldgen.de (Matthias Schoeldgen)
Date: Sat, 06 Apr 2002 20:24:49 +0200
Subject: [uClinux-dev] Newbie: How can I restore the old values of the image 
 of uCsimm (MC68EZ328)
References: <OHEGKBKJNDMIKNAMMKBMKEEBCAAA.eric.bosch@fourtress.nl>
Message-ID: <3CAF3D71.569F884@schoeldgen.de>

> "Eric Bosch (Fourtress)" wrote:
> 
> Hello all,
> 
> I'am a newbie and have a big problem. I have changed the settings of
> the COM port of the uCsimm (MC68EZ328 dragonball board) in COM2
> (/dev/ttyS1). But the uCsimm has only COM1 (/dev/ttyS0). So when I
> restart minicom and I press the reset button there isn't a connection.
> Before I changed the environment variable in uCsimm it works OK. So I
> can't communicatie (serial) with the dragonball board.
> 
> The most important question is: How can I restore the old values of
> the image of the uCsimm.
> 
> Help me please the solve this big problem.
> 
> Rgds Eric

Hi Eric!
Big problem. I once had my environment variables setup in a way that
crashed my uCsimm, but these were not the CONSOLE variables, so I don't
know, if it will help you. Anyway, here's what I did (only for the brave-hearted):
1. Power down uCsimm.
2. Using a metallic pin or needle , bridge pin 1 and 2 on the RAM chip.
On my uCsimm it was a MT 4lc4m16R6.
3. Still bridging the pins, power up uCsimm. Remove the bridge.
4. My uCsimm encountered an adress error and dropped me to the
bootloader shell. Hopefully this will happen with yours, too.
5. Issue the "eraseenv" command.
6. Done...
In your case things lay a bit different, for you mixed up the CONSOLE.
If the above procedure doesn't work, I'm afraid there is no way except
asking Lineo to restore the flash.

Good luck
Matthias
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From mdurrant at uclinux.org  Sat Apr  6 13:54:09 2002
From: mdurrant at uclinux.org (Michael Durrant)
Date: Sat, 6 Apr 2002 13:54:09 -0500
Subject: [uClinux-dev] Newbie: How can I restore the old values of the image  of uCsimm (MC68EZ328)
References: <OHEGKBKJNDMIKNAMMKBMKEEBCAAA.eric.bosch@fourtress.nl> <3CAF3D71.569F884@schoeldgen.de>
Message-ID: <003a01c1dd9d$19753440$7f82a8c0@sympatico.ca>

Matthias is correct, this is a valid method to force your module back
into the shell via forcing an address bus error.  Take great care not to
damage the components (Memory/Flash/Processor).

--
Michael Durrant
Arcturus Networks Inc.

----- Original Message -----
From: "Matthias Schoeldgen" <uclinux at schoeldgen.de>
To: <uclinux-dev at uclinux.org>
Sent: Saturday, April 06, 2002 1:24 PM
Subject: Re: [uClinux-dev] Newbie: How can I restore the old values of the
image of uCsimm (MC68EZ328)


> > "Eric Bosch (Fourtress)" wrote:
> >
> > Hello all,
> >
> > I'am a newbie and have a big problem. I have changed the settings of
> > the COM port of the uCsimm (MC68EZ328 dragonball board) in COM2
> > (/dev/ttyS1). But the uCsimm has only COM1 (/dev/ttyS0). So when I
> > restart minicom and I press the reset button there isn't a connection.
> > Before I changed the environment variable in uCsimm it works OK. So I
> > can't communicatie (serial) with the dragonball board.
> >
> > The most important question is: How can I restore the old values of
> > the image of the uCsimm.
> >
> > Help me please the solve this big problem.
> >
> > Rgds Eric
>
> Hi Eric!
> Big problem. I once had my environment variables setup in a way that
> crashed my uCsimm, but these were not the CONSOLE variables, so I don't
> know, if it will help you. Anyway, here's what I did (only for the
brave-hearted):
> 1. Power down uCsimm.
> 2. Using a metallic pin or needle , bridge pin 1 and 2 on the RAM chip.
> On my uCsimm it was a MT 4lc4m16R6.
> 3. Still bridging the pins, power up uCsimm. Remove the bridge.
> 4. My uCsimm encountered an adress error and dropped me to the
> bootloader shell. Hopefully this will happen with yours, too.
> 5. Issue the "eraseenv" command.
> 6. Done...
> In your case things lay a bit different, for you mixed up the CONSOLE.
> If the above procedure doesn't work, I'm afraid there is no way except
> asking Lineo to restore the flash.
>
> Good luck
> Matthias
> This message resent by the uclinux-dev at uclinux.org list server
http://www.uClinux.org/
>

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From danielp at cse.unsw.edu.au  Sat Apr  6 19:50:32 2002
From: danielp at cse.unsw.edu.au (Daniel Potts)
Date: Sun, 7 Apr 2002 10:50:32 +1000 (EST)
Subject: [uClinux-dev] patch: Power management support for 68328 (ucsimm/ucdimm)
In-Reply-To: <003a01c1dd9d$19753440$7f82a8c0@sympatico.ca>
Message-ID: <Pine.OSF.4.44.0204071036180.12852-200000@paulaner.disy.cse.unsw.EDU.AU>

Hi,

Here is a patch to fairly recent cvs that provides power management
support for dragonball.

Here is a of modifications in the patch:
* 68328 serial ports put to sleep on suspend.
* cs89x00 put to sleep on suspend.
* support for sysctl /proc/sys/pm/suspend interface
    (echo >/proc/sys/pm/suspend)
* support for user level power management helper
* support for power button on IRQ3 (this is an example).
* config option for doze or full clock suspend (sleep mode).
* kernel idle thread doze mode (Mark McChrystal)

** Also fixes sleep line programming of the cs89x0 init code on ucDimm
    - not the same as ucSimm!

Thanks to Mark McChrystal for debugging on the ucsimm and other various
tidbits.

We didn't have too much luck with putting the ucsimm or ucdimm into deep
sleep. It appears that the RAM doesn't get correctly refreshed during this
time, no matter what settings we tried. I'd be interested to hear from
those with proper self-refresh/low power sdrams, to see if it works
better.

The cs89x0 modifications provide a good example for anyone else wanting to
add pm support to their device driver (also see
linux/Documentation/pm.txt).

Cheers,
Daniel



-------------- next part --------------
--- uClinux-2.4.x.orig/arch/m68knommu/config.in	Tue Apr  2 23:12:20 2002
+++ linux-2.4.x.orig.patched/arch/m68knommu/config.in	Wed Mar 27 23:39:16 2002
@@ -293,6 +286,12 @@
       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
diff -Naur uClinux-2.4.x.orig/arch/m68knommu/platform/68328/pm.c linux-2.4.x.orig.patched/arch/m68knommu/platform/68328/pm.c
--- uClinux-2.4.x.orig/arch/m68knommu/platform/68328/pm.c	Thu Jan  1 10:00:00 1970
+++ linux-2.4.x.orig.patched/arch/m68knommu/platform/68328/pm.c	Sun Apr  7 10:15:13 2002
@@ -0,0 +1,240 @@
+/* 
+ * 68328 Power Management Routines
+ * 
+ *  Copyright 2002 Daniel Potts <danielp at cse.unsw.edu.au>
+ *                 Embedded Systems, Co., LTD, Korea
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation; either version 2 of the License, or
+ *  (at your option) any later version.
+ */
+
+/*
+ *  Debug macros 
+ */
+#define DEBUG 1
+#ifdef DEBUG
+#  define DPRINTK(fmt, args...)	printk("%s: " fmt, __FUNCTION__ , ## args)
+#else
+#  define DPRINTK(fmt, args...)
+#endif
+
+
+#include <linux/config.h>
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/pm.h>
+#include <linux/sysctl.h>
+
+#include <linux/acpi.h> /* WARNING: included for CTL_ACPI and ACPI_S1_SLP_TYP */
+
+#ifdef CONFIG_M68328
+#include <asm/MC68328.h>
+#endif
+
+#ifdef CONFIG_M68EZ328
+#include <asm/MC68EZ328.h>
+#endif
+
+#ifdef CONFIG_M68VZ328
+#include <asm/MC68VZ328.h>
+#endif
+
+#include <linux/kmod.h>
+#include <linux/interrupt.h> /* for interrupt stuff (that shouldn't be here)*/
+#include <asm/irq.h>
+
+static unsigned long sleep_irq_mask = 0L; /* irqs to enable while in sleep mode */
+
+#if defined (CONFIG_68328_SERIAL)
+void shutdown_console(void);
+void startup_console(void);
+#endif
+
+void set_sleep_mask(unsigned long mask)
+{
+	sleep_irq_mask = mask;
+}
+
+static int cpu_suspend(void)
+{
+	unsigned long flags;
+	unsigned long imr_flags;
+
+	save_flags(flags);
+	cli();
+	imr_flags = IMR;
+
+#if defined (CONFIG_68328_SERIAL)
+	/* Console is shutdown here as a special device,
+	 * to ensure that the kernel will not hang trying to write to console.
+	 */
+	shutdown_console();
+#endif
+
+	/* write out sleep enabled interrupts */
+	IMR = ~(sleep_irq_mask);    
+
+#if defined (CONFIG_PM_DOZE_ONLY)
+	PCTRL = PCTRL_PCEN;
+#else
+	PLLCR |= PLLCR_DISPLL;
+	__asm__("stop #0x2000" : : : "cc");
+#endif
+
+	/* Resume normal operation */
+
+#if defined (CONFIG_68328_SERIAL)
+	startup_console();
+#endif
+
+	IMR = imr_flags;
+	restore_flags(flags);
+
+	return 0;
+}
+
+#if defined (CONFIG_PM_HELPER)
+
+static char pm_helper_path[128] = "/sbin/pm_helper";
+
+static void run_pm_helper(pm_request_t action)
+{
+	int r;
+	char *argv[3], *envp[3];
+
+	if (!pm_helper_path[0])
+		return;
+	if (!current->fs->root)
+		return;
+	if (action != PM_SUSPEND && action != PM_RESUME)
+		return;
+
+	argv[0] = pm_helper_path;
+	argv[1] = (action == PM_RESUME ? "resume" : "suspend");
+	argv[2] = 0;
+
+	/* minimal command environment */
+	envp[0] = "HOME=/tmp";
+	envp[1] = "PATH=/sbin:/bin:/usr/sbin:/usr/bin";
+	envp[2] = 0;
+
+	r = call_usermodehelper(argv[0], argv, envp);
+	if (r != 0)
+		printk("pm: user mode pm_helper returned %d\n", r);
+}
+
+/* 
+ * pm_suggest_suspend()
+ *
+ * This gets called elsewhere in the kernel when the system should be placed
+ * into suspend mode. For example, a power button handler.
+ * It calls the user level power management handler.
+ */
+int pm_suggest_suspend(void)
+{
+	run_pm_helper(PM_SUSPEND);
+	return 0;
+}
+#endif
+
+
+#if defined (CONFIG_SYSCTL)
+static int sysctl_pm_do_suspend(ctl_table *table, int write, struct file *filp,
+                  void *buffer, size_t *lenp)
+{
+	int r;
+
+	*lenp = 0;
+
+	DPRINTK("System attempting to suspend.\n");
+	r = pm_send_all(PM_SUSPEND, (void *)2);
+	if (r) {
+		return r;
+	}
+
+	r = cpu_suspend();
+
+	pm_send_all(PM_RESUME, (void *)0);
+#if defined (CONFIG_PM_HELPER)
+	run_pm_helper(PM_RESUME);
+#endif
+
+	DPRINTK("System resumed normal operation.\n");
+	return r;
+}
+
+
+static struct ctl_table pm_table[] = 
+{
+	{ACPI_S1_SLP_TYP, "suspend", NULL, 0, 0600, NULL, (proc_handler *)&sysctl_pm_do_suspend},
+#if defined (CONFIG_PM_HELPER)
+	{2, "pm_helper", pm_helper_path, sizeof(pm_helper_path), 0644, NULL, (proc_handler *)&proc_dostring},
+#endif
+	{0}
+};
+
+static struct ctl_table pm_dir_table[] =
+{
+	{CTL_ACPI, "pm", NULL, 0, 0555, pm_table},
+	{0}
+};
+
+
+/*
+ * Initialize power interface
+ */
+static int __init pm_init(void)
+{
+	printk("Power management driver for 68328, Daniel Potts <danielp at cse.unsw.edu.au>\n");
+
+	register_sysctl_table(pm_dir_table, 1);
+	return 0;
+}
+
+__initcall(pm_init);
+
+#endif /* CONFIG_SYSCTL */
+
+
+#if defined (CONFIG_PM_POWER_BUTTON_IRQ3)
+/* EXAMPLE power button handler:
+ *  Here we use IRQ3 as our wake up from sleep mode interrupt
+ */
+static void power_button_irq(int irq, void *dev_id, struct pt_regs *regs)
+{
+	unsigned long flags;
+
+	save_flags(flags);
+	cli();
+	
+	ISR |= ISR_IRQ3; /* ack edge interrupt */
+
+	restore_flags(flags);
+}
+
+static int __init power_button(void)
+{
+	int err;
+	
+	/* init interrupt section */
+	PDDIR &= ~PD_IRQ3;
+	PDSEL &= ~PD_IRQ3;
+	
+	ICR |= ICR_ET3;  /* edge sensitive */
+	ISR |= ISR_IRQ3; /* clear it */
+	
+	set_sleep_mask(IMR_MIRQ3);
+	
+	err = request_irq(IRQ3_IRQ_NUM, power_button_irq,
+			  IRQ_FLG_STD, "power button", NULL);
+	
+	if(err)
+		printk("power irq failed\n");
+	return 0;
+}
+
+__initcall(power_button);
+
+#endif /* CONFIG_PM_POWER_BUTTON_IRQ3 */
--- uClinux-2.4.x.orig/arch/m68knommu/platform/68EZ328/Makefile	Sun Mar  3 00:46:45 2002
+++ linux-2.4.x.orig.patched/arch/m68knommu/platform/68EZ328/Makefile	Wed Mar 27 23:16:05 2002
@@ -17,6 +17,8 @@
 O_TARGET := platform.o
 obj-y := entry.o config.o signal.o traps.o ints.o
 
+obj-$(CONFIG_PM) += pm.o
+
 $(BOARD)/crt0_$(MODEL).o: $(BOARD)/crt0_$(MODEL).S $(BOARD)/bootlogo.rh
 
 entry.o: entry.S m68k_defs.h
--- uClinux-2.4.x.orig/arch/m68knommu/platform/68VZ328/Makefile	Sun Mar  3 12:33:33 2002
+++ linux-2.4.x.orig.patched/arch/m68knommu/platform/68VZ328/Makefile	Wed Mar 27 23:16:01 2002
@@ -17,6 +17,8 @@
 O_TARGET := platform.o
 obj-y := entry.o config.o signal.o traps.o ints.o
 
+obj-$(CONFIG_PM) += pm.o
+
 $(BOARD)/crt0_$(MODEL).o: $(BOARD)/crt0_$(MODEL).S $(BOARD)/crt0_fixed.S $(BOARD)/bootlogo.rh
 
 entry.o: entry.S m68k_defs.h
--- uClinux-2.4.x.orig/arch/m68knommu/platform/68VZ328/ucdimm/ints.c	Tue Mar 26 20:33:12 2002
+++ linux-2.4.x.orig.patched/arch/m68knommu/platform/68VZ328/ucdimm/ints.c	Wed Mar 27 23:35:13 2002
@@ -351,3 +351,10 @@
 	mach_get_irq_list    = M68VZ328_get_irq_list;
 	mach_process_int     = M68VZ328_do_irq;
 }
+
+
+void init_irq_proc(void);
+void init_irq_proc(void)
+{
+        /* Insert /proc/irq driver here */
+}
--- uClinux-2.4.x.orig/drivers/char/68328serial.c	Sun Mar  3 12:34:03 2002
+++ linux-2.4.x.orig.patched/drivers/char/68328serial.c	Sun Apr  7 10:32:27 2002
@@ -7,6 +7,7 @@
  *
  * VZ Support/Fixes             Evan Stawnyczy <e at lineo.ca>
  * Multiple UART support        Daniel Potts <danielp at cse.unsw.edu.au>
+ * Power management support     Daniel Potts <danielp at cse.unsw.edu.au>
  */
  
 #include <asm/dbg.h>
@@ -28,6 +29,7 @@
 #include <linux/reboot.h>
 #include <linux/keyboard.h>
 #include <linux/init.h>
+#include <linux/pm.h>
 
 #include <asm/io.h>
 #include <asm/irq.h>
@@ -1444,7 +1446,58 @@
 	printk("MC68328 serial driver version 1.00\n");
 }
 
-volatile int test_done;
+#ifdef CONFIG_PM
+/* Serial Power management
+ *  The console (currently fixed at line 0) is a special case for power
+ *  management because the kernel is so chatty. The console will be 
+ *  explicitly disabled my our power manager as the last minute, so we won't
+ *  mess with it here.
+ */
+static struct pm_dev *serial_pm[NR_PORTS];
+
+static int serial_pm_callback(struct pm_dev *dev, pm_request_t request, void *data)
+{
+	struct m68k_serial *info = (struct m68k_serial *)dev->data;
+
+	if(info == NULL)
+		return -1;
+
+	/* special case for line 0 - pm restores it */
+	if(info->line == 0)
+		return 0; 
+
+	switch (request) {
+	case PM_SUSPEND:
+		shutdown(info);
+		break;
+
+	case PM_RESUME:
+		startup(info);
+		break;
+	}
+	return 0;
+}
+
+void shutdown_console(void)
+{
+	struct m68k_serial *info = &m68k_soft[0];
+
+	/* HACK: wait a bit for any pending printk's to be dumped */
+	{
+		int i = 10000;
+		while(i--);
+	}
+
+	shutdown(info);
+}
+
+void startup_console(void)
+{
+	struct m68k_serial *info = &m68k_soft[0];
+	startup(info);
+}
+#endif
+
 
 /* rs_init inits the driver */
 static int __init
@@ -1545,10 +1598,17 @@
 			    IRQ_FLG_STD,
 			    "M68328_UART", NULL))
                 panic("Unable to attach 68328 serial interrupt\n");
+#ifdef CONFIG_PM
+	    serial_pm[i] = pm_register(PM_SYS_DEV, PM_SYS_COM, serial_pm_callback);
+	    if (serial_pm[i])
+		    serial_pm[i]->data = info;
+#endif
 	}
 	restore_flags(flags);
 	return 0;
 }
+
+
 
 /*
  * register_serial and unregister_serial allows for serial ports to be
--- uClinux-2.4.x.orig/drivers/net/cs89x0.c	Tue Mar 26 20:33:40 2002
+++ linux-2.4.x.orig.patched/drivers/net/cs89x0.c	Sun Apr  7 10:26:11 2002
@@ -87,6 +87,10 @@
                     : Customized for use on uClinux & MC68EZ328 platforms.
  
   Evan Stawnyczy    : Customized for use on MC68VZ328 platform.
+
+  Daniel Potts      : uClinux sleep support, ucDimm
+  Mark McChrystal   : uClinux sleep support, ucSimm
+
 */
 
 /* Always include 'config.h' first in case the user wants to turn on
@@ -150,6 +154,7 @@
 #include <linux/netdevice.h>
 #include <linux/etherdevice.h>
 #include <linux/skbuff.h>
+#include <linux/pm.h>
 
 #include "cs89x0.h"
 
@@ -287,7 +292,11 @@
 __setup("cs89x0_dma=", dma_fn);
 #endif	/* !defined(MODULE) && (ALLOW_DMA != 0) */
 
-
+
+#ifdef CONFIG_PM
+static int cs89x0_in_use = 0;
+#endif
+
 /* Check for a network adaptor of this type, and return '0' iff one exists.
    If dev->base_addr == 0, probe all likely locations.
    If dev->base_addr == 1, always return failure.
@@ -407,6 +416,53 @@
 #endif /* NO_EPROM */
 
 
+#if defined(CONFIG_PM)
+
+static struct pm_dev *cs89x0_pm;
+
+/* cs89x0_pm_callback():
+ *
+ *  We don't actually suspend or resume here - that is left to the
+ *  net_open/close functions.
+ *  On PM_SUSPEND: we check that the connection is closed down. If it is, we
+ *  return success. PM_RESUME does nothing.
+ *  It is required that the user brings the connection down (perhaps via
+ *  a pm helper daemon)
+ */
+static int cs89x0_pm_callback(struct pm_dev *dev, pm_request_t request, void *data)
+{
+	struct net_device *cs_dev = (struct net_device *)dev->data;
+
+	switch (request) {
+	case PM_SUSPEND:
+		if (cs89x0_in_use) {
+			printk("cs89x00 connection still open, not sleeping\n");
+			return -EBUSY;
+		}
+
+#if defined(CONFIG_UCSIMM)
+		/* set sleep pin low */
+		*(volatile unsigned char *)0xfffff429 &= ~(0x01);
+		writereg(cs_dev, PP_SelfCTL, readreg(dev, PP_SelfCTL) & ~(AUTO_WAKEUP)); 
+#elif defined(CONFIG_UCDIMM)
+		*(volatile unsigned char *)0xfffff431 &= ~(0x08);
+#endif
+		writereg(cs_dev, PP_SelfCTL, readreg(dev, PP_SelfCTL) | SLEEP_ON);
+		break;
+	case PM_RESUME:
+#if defined (CONFIG_UCSIMM)
+		*(volatile unsigned short *)0xfffff429 |= 0x01; /* not sleeping */
+#elif defined(CONFIG_UCDIMM)
+		*(volatile unsigned char *)0xfffff431 |= (0x08);
+#endif
+		break;
+	}
+
+	return 0;
+}
+
+#endif
+
 /* This is the real probe routine.  Linux has a history of friendly device
    probes on the ISA bus.  A good device probes avoids doing writes, and
    verifies that the correct device exists and functions.
@@ -426,14 +482,19 @@
 #if defined( CONFIG_UCSIMM ) || defined(CONFIG_UCDIMM)
 #ifdef CONFIG_UCSIMM
 	printk("cs89x0: Setting up uCsimm CS8900 Chip Select & IRQ ioaddr = 0x%X\n",ioaddr);
-#else
-	printk("cs89x0: Setting up uCcs8900 Chip Select & IRQ ioaddr = 0x%X\n",ioaddr);
-#endif
 
 	/* set up the chip select */
 	*(volatile unsigned  char *)0xfffff42b |= 0x01; /* output /sleep */
 	*(volatile unsigned short *)0xfffff428 |= 0x0101; /* not sleeping */
 
+#else   /* UCDIMM */
+	printk("cs89x0: Setting up uCcs8900 Chip Select & IRQ ioaddr = 0x%X\n",ioaddr);
+
+	/* set up the chip select */
+	*(volatile unsigned char *)0xfffff430 |= 0x08;
+	*(volatile unsigned char *)0xfffff433 |= 0x08;
+	*(volatile unsigned char *)0xfffff431 |= (0x08); /* sleep */
+#endif
 	*(volatile unsigned  char *)0xfffff42b &= ~0x02; /* input irq5 */
 	*(volatile unsigned short *)0xfffff428 &= ~0x0202; /* irq5 fcn on */
 	
@@ -734,6 +795,11 @@
 	printk("\n");
 	if (net_debug)
 		printk("cs89x0_probe1() successful\n");
+#if defined (CONFIG_PM)
+	cs89x0_pm = pm_register(PM_SYS_DEV, PM_SYS_COM, cs89x0_pm_callback);
+	if (cs89x0_pm)
+		cs89x0_pm->data = dev;
+#endif
 	return 0;
 out2:
 	release_region(ioaddr & ~3, NETCARD_IO_EXTENT);
@@ -1383,6 +1449,9 @@
         netif_start_queue(dev);
 	if (net_debug > 1)
 		printk("cs89x0: net_open() succeeded\n");
+#ifdef CONFIG_PM
+	cs89x0_in_use = 1;
+#endif
 	return 0;
 bad_out:
 	return ret;
@@ -1633,6 +1702,10 @@
 		free_dma(dev->dma);
 		release_dma_buff(lp);
 	}
+#endif
+
+#if defined(CONFIG_PM)
+	cs89x0_in_use = 0;
 #endif
 
 	/* Update the statistics here. */

From SMerrifield at tecom.com.au  Sun Apr  7 18:58:45 2002
From: SMerrifield at tecom.com.au (Steven Merrifield)
Date: Mon, 8 Apr 2002 00:58:45 +0200 
Subject: [uClinux-dev] Boa web server
Message-ID: <7FF1185EA0D3D511BC0500B0D0D0C24A1B59D8@melexc01.ap.ilxi.net>

Hi,

Boa is included in the uClinux distribution, and incorporates
several patches to the "standard" boa source. I suggest you
try compiling this version rather than starting from scratch.

steve


> -----Original Message-----
> From: Mohamed Ali Shiha [mailto:moh.shiha at ieee.org]
> Sent: Sunday, 7 April 2002 1:45
> To: uClinux
> Subject: [uClinux-dev] Boa web server
> 
> 
> Dear all,
> 
> did some one try to compile Boa web server for MC68VZ328 ... 
> ? ... I got a
> message telling me that there is a problem in the header 
> files included
> ...!!!
> I am trying to do that with Netdimm SDK board that comes 
> without the source
> of Boa ...
> 
> Thanks
> Mohamed Shiha
> This message resent by the uclinux-dev at uclinux.org list 
> server http://www.uClinux.org/
> 
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From kj_lin at accton.com.tw  Sun Apr  7 22:37:24 2002
From: kj_lin at accton.com.tw (kj_lin at accton.com.tw)
Date: Mon, 8 Apr 2002 10:37:24 +0800
Subject: [uClinux-dev] uClinux porting of MIPS
Message-ID: <OFEFA70CFE.3261EF07-ON48256B95.000A37A4@accton.com.tw>


Hi,


Seldom MIPS topic discussed here.

I had ever ported uclinux+Microwin+Viewm on MIPS platform with gcc-2.96.

In fact, the most puzzle is the "elf2flt" tool during porting process.

I don't know how you convert ELF to your working FLAT format,

but my method is to modify the elf2flt source code based on the version for

ARM.

I had it supported for R_MIPS_HI16, R_MIPS_LO16, R_MIPS_CALL16,

R_MIPS_GOT16, R_MIPS_32 and R_MIPS_GPREL32.

Actually, using GLOBAL OFFSET TABLE, we only need to do recloation for

R_MIPS_32, R_MIPS_CALL16 & R_MIPS_GOT16 and to set the "_gp" to the correct

value in the "elf2flt.ld".

But i still don't know how to do relocation for R_MIPS_26 until now.



Best Regards,

KJ













                                                                                                            
                                                                                                            
                      zhaotc                    To:       uclinux-dev at uclinux.org                           
                      <tczhao at linpus.com        cc:                                                         
                      .tw>                      Subject:  Re: [uClinux-dev] uClinux porting of MIPS         
                      Sent by:                                                                              
                      owner-uclinux-dev@                                                                    
                      uclinux.org                                                                           
                                                                                                            
                                                                                                            
                      2002/04/05 09:33                                                                      
                      AM                                                                                    
                      Please respond to                                                                     
                      uclinux-dev                                                                           
                                                                                                            
                                                                                                            






On Friday 05 April 2002 04:10 am, you wrote:
> zhaotc wrote:
> >         I do MIPS relocation in the way of modify bFLT file format
> > merely due to somebody told me MIPS gcc do PIC code very bad, and I
feel
> > a bit puzzle on how "elf2flt" works. So, in my box, all libs such as
> > uClibc and  libgcc.a are no-PIC coded.  and only 4 kind of relocation
> > types appear: R_MIPS_HI16, R_MIPS_LO16, R_MIPS_26, R_MIPS_32.
>
> Hrm...What version of GCC are you using? Also note that ELF2FLT is
> very M68K and ARM-oriented, so if you aren't familiar with those CPUs,
> some of what's happening in ELF2FLT might confuse you.

             My GCC version is 2.97, binutils is 2.1.91.

>
> >         Now I try porting uClibc to my MIPS board, and it has print
> > "Hello word !" . I feel very happy!
> >
> :) Such a simple program, and yet it fills one with so much
>
> confidence.

             Yes, as a newbie of linux.:) I worked for this project for 3
month, and work
10hr one day. At lest I see something run. I also work in L7205 Kernel
porting for 2 month. Because there are many people working for it, it
didn't
waste me much time, what I do just write some device drivers. Now the L7205

project has been transfor to other engineer in my  company.

Zhao Tiecheng
Linpus, Shanghai
This message resent by the uclinux-dev at uclinux.org list server
http://www.uClinux.org/


This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From madhusudhan at knowsys.net  Mon Apr  8 01:20:45 2002
From: madhusudhan at knowsys.net (Madhusudhan)
Date: Mon, 8 Apr 2002 10:50:45 +0530
Subject: [uClinux-dev] uclinux 2.2-5 tarball
References: <OFEFA70CFE.3261EF07-ON48256B95.000A37A4@accton.com.tw>
Message-ID: <032a01c1debd$255076a0$5401a8c0@knowsys.net>

Hi
  can anybody tell me where can i find the uclinux-2.2.5 tar file. i am not able to find it in the CVS repository

regards

Madhusudhan M
Software Engineer
Knowledge Sytems Pvt Ltd
#470, East End Main Road,
9th Block Jayanagar,
Bangalore 560069.
Off 6545252/53
Res 6587680

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20020408/fcc9849e/attachment.html>

From gerg at snapgear.com  Mon Apr  8 02:07:15 2002
From: gerg at snapgear.com (Greg Ungerer)
Date: Mon, 08 Apr 2002 16:07:15 +1000
Subject: [uClinux-dev] uclinux 2.2-5 tarball
References: <OFEFA70CFE.3261EF07-ON48256B95.000A37A4@accton.com.tw> <032a01c1debd$255076a0$5401a8c0@knowsys.net>
Message-ID: <3CB13393.8080507@snapgear.com>


Hi Madhusudhan,

Madhusudhan wrote:

>   can anybody tell me where can i find the uclinux-2.2.5 tar file. i am 
> not able to find it in the CVS repository

There was never uClinux patches for 2.2 kernels.
Perhaps you are looking for some other version?

Regards
Greg

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

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From frastrilla at intelnet.es  Mon Apr  8 05:01:04 2002
From: frastrilla at intelnet.es (Francis Rastrilla AGud)
Date: Mon, 08 Apr 2002 11:01:04 +0200
Subject: [uClinux-dev] Problems with NFS mounts
Message-ID: <3CB15C50.50403@intelnet.es>

Dear all,

I'm working on a 68EZ328 based board with a 2.4.x kernel. 

Since nfs mounts need to use portmap I'm not able to run any application via a nfs mount.I get this behavoir from 20011112 distro .

I can mount my remote directory and even browse it, but when I try to tranfer or execute a file greater than 8k nfs-mount stops working and I get the following message:

nfs: server 192.0.3.101 not responding, still trying  
nfs: server 192.0.3.101 not responding, still trying

If the file is smaller than 8k everything works properly 

Is someone having the same problem?, Is portmap the problem?


Any information is welcome.

Thank you.






This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From securez at teleline.es  Mon Apr  8 05:17:07 2002
From: securez at teleline.es (Securez)
Date: Mon, 08 Apr 2002 11:17:07 +0200
Subject: [uClinux-dev] Problem with boa
Message-ID: <5.1.0.14.2.20020408111424.01f88280@pop3.iqc-services.com>

I compiled the boa server that comes with 2.4.17 distribution in uClinux, 
and i get this when i see the test page, every reload of the page get the 
same warning of the kernel.

munmap of non-mmaped memory by process 21 (boa): 021371bc
munmap of non-mmaped memory by process 21 (boa): 0213739c
munmap of non-mmaped memory by process 21 (boa): 0213739c
.....



This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From castet at firstlinux.net  Mon Apr  8 06:58:52 2002
From: castet at firstlinux.net (laurent castet)
Date: Mon, 8 Apr 2002 03:58:52 -0700 (PDT)
Subject: [uClinux-dev] uClinux port and device driver to TMS320DSC21
Message-ID: <20020408105852.78FEB36F9@sitemail.everyone.net>

An embedded and charset-unspecified text was scrubbed...
Name: not available
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20020408/efcb5ccc/attachment.ksh>

From julienb at actimage.fr  Mon Apr  8 07:21:07 2002
From: julienb at actimage.fr (Julien Boibessot)
Date: Mon, 8 Apr 2002 13:21:07 +0200
Subject: [uClinux-dev] Porting uClinux to our custom board.....
References: <5.1.0.14.2.20020408111424.01f88280@pop3.iqc-services.com>
Message-ID: <008801c1deef$7a3de030$8947ec95@bruker.fr>

Hi all !!

we have developed a custom board from MC5272C3 one.
We have the same peripherals (Flash, Ethernet, SDRAM, 2xSerial) plus custom
one (RTC, Sound Chip, Codec, SDCard.....). Our CPU frequency will be 40,96
Mhz.

My question is:
as our design is quite identical to 5272C3 one (only CPU frequency is
different), do we only need to change CPU_CLOCK variable to "port" uClinux
for our platform ???
If no, could someone give me clues about the additional work that should be
done ??? (I think we will have to modify SDRAM register too....Is it right
??)

Thanks !!

Julien


This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From davidm at snapgear.com  Mon Apr  8 07:36:10 2002
From: davidm at snapgear.com (David McCullough)
Date: Mon, 8 Apr 2002 21:36:10 +1000
Subject: [uClinux-dev] Problem with boa
In-Reply-To: <5.1.0.14.2.20020408111424.01f88280@pop3.iqc-services.com>; from securez@teleline.es on Mon, Apr 08, 2002 at 11:17:07AM +0200
References: <5.1.0.14.2.20020408111424.01f88280@pop3.iqc-services.com>
Message-ID: <20020408213610.A27194@beast.internal.moreton.com.au>


Jivin Securez lays it down ...
> I compiled the boa server that comes with 2.4.17 distribution in uClinux, 
> and i get this when i see the test page, every reload of the page get the 
> same warning of the kernel.
> 
> munmap of non-mmaped memory by process 21 (boa): 021371bc
> munmap of non-mmaped memory by process 21 (boa): 0213739c
> munmap of non-mmaped memory by process 21 (boa): 0213739c
> .....

It means that some part of boa is free'ing memory that it didn't allocate
or has already free'd.

I haven't seen this error from boa but it could be due to the way
it is being invoked.

If you have a kernel debugger,  the best way to find this is break point on
printk and then access the page.  From there you can bactrace into the
application and work out which call to free is the offender ;-)

Cheers,
Davidm

-- 
David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
davidm at snapgear.com  Fx: +61 7 3891 3630  825 Stanley St., W'gabba QLD 4102, Oz
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From davidm at snapgear.com  Mon Apr  8 07:44:13 2002
From: davidm at snapgear.com (David McCullough)
Date: Mon, 8 Apr 2002 21:44:13 +1000
Subject: [uClinux-dev] Problems with NFS mounts
In-Reply-To: <3CB15C50.50403@intelnet.es>; from frastrilla@intelnet.es on Mon, Apr 08, 2002 at 11:01:04AM +0200
References: <3CB15C50.50403@intelnet.es>
Message-ID: <20020408214413.B27194@beast.internal.moreton.com.au>


Jivin Francis Rastrilla AGud lays it down ...
> Dear all,
> 
> I'm working on a 68EZ328 based board with a 2.4.x kernel. 
> 
> Since nfs mounts need to use portmap I'm not able to run any
> application via a nfs mount.I get this behavoir from 20011112 distro .
> 
> I can mount my remote directory and even browse it, but when I try
> to tranfer or execute a file greater than 8k nfs-mount stops working
> and I get the following message:
> 
> nfs: server 192.0.3.101 not responding, still trying  
> nfs: server 192.0.3.101 not responding, still trying
> 
> If the file is smaller than 8k everything works properly 
> 
> Is someone having the same problem?, Is portmap the problem?

I don't believe this has anything to do with portmap.  If portmap wasn't
working the mounts would not work.

When I first played with NFS on the uCsimm using 2.4 it seemed that the
68EZ328 was a little too slow and the 2.4 network stack held interrupts
out a little too long and the network was getting HW overruns.

Many people has posted NFS mount options to work around this,  search
through the archives and you'll find them.  It involves using smaller
RX/TX buffers if I remember correctly,

Cheers,
Davidm

-- 
David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
davidm at snapgear.com  Fx: +61 7 3891 3630  825 Stanley St., W'gabba QLD 4102, Oz
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From lgltoludo at yahoo.fr  Mon Apr  8 08:20:32 2002
From: lgltoludo at yahoo.fr (=?iso-8859-1?q?Ludo=20G.L.?=)
Date: Mon, 8 Apr 2002 14:20:32 +0200 (CEST)
Subject: [uClinux-dev] Questions about uClinux and M5307C3
In-Reply-To: <058801c1dc9f$a3759f30$8947ec95@bruker.fr>
Message-ID: <20020408122032.811.qmail@web20002.mail.yahoo.com>

[uClinux-dev]

Hello everyone.

I work on the M5307C3 Motorola's board (which function
with a ColdFire ?processor).
And, I have a few questions :

* Which is the difference detwin "flat", "elf", and
"*.bin" ?
* Which version of the "m68k-elf-tools" do I have to
use (I will make my prog in C) ?
* How can I download an Image on the board (using the
serial port) with minicom ?
* Does uClinux (on M5307C3) suport the 2 serial ports
well ?
* Does uClinux (on M5307C3) suport the I/O ? And, if
yes, how can I program the I/O ?

Who re-helps a newbie ?
                                                  
Ludovic GUILLET
                                                  
lgltoludo at yahoo.fr

PS: For the ones who have answer my questions before I
said: "Thank-you"
    And for the ones who will answer: "Thank-you too"




___________________________________________________________
Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en fran?ais !
Yahoo! Mail : http://fr.mail.yahoo.com
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From mbarton at verifiber.com  Mon Apr  8 09:11:54 2002
From: mbarton at verifiber.com (Mark Barton)
Date: Mon, 8 Apr 2002 09:11:54 -0400
Subject: [uClinux-dev] Porting uClinux to our custom board.....
In-Reply-To: <008801c1deef$7a3de030$8947ec95@bruker.fr>
Message-ID: <000f01c1defe$f5163fa0$6501a8c0@sdlabbarton>

Julien,

We also developed a custom MC5272 board based on Motorola's Eval board and
was able to bring up uClinux fairly quickly. Most of the work was in the
bootloader, setting up the necessary registers required by uClinux and
dowloading uClinux to ram. If you have deviated from the memory map then you
will of course have to make the necessary changes, otherwise not much else
has to be done.

Mark


-----Original Message-----
From: owner-uclinux-dev at uclinux.org
[mailto:owner-uclinux-dev at uclinux.org]On Behalf Of Julien Boibessot
Sent: Monday, April 08, 2002 7:21 AM
To: uclinux-dev at uclinux.org
Subject: [uClinux-dev] Porting uClinux to our custom board.....


Hi all !!

we have developed a custom board from MC5272C3 one.
We have the same peripherals (Flash, Ethernet, SDRAM, 2xSerial) plus custom
one (RTC, Sound Chip, Codec, SDCard.....). Our CPU frequency will be 40,96
Mhz.

My question is:
as our design is quite identical to 5272C3 one (only CPU frequency is
different), do we only need to change CPU_CLOCK variable to "port" uClinux
for our platform ???
If no, could someone give me clues about the additional work that should be
done ??? (I think we will have to modify SDRAM register too....Is it right
??)

Thanks !!

Julien


This message resent by the uclinux-dev at uclinux.org list server
http://www.uClinux.org/

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From tczhao at linpus.com.tw  Mon Apr  8 09:11:06 2002
From: tczhao at linpus.com.tw (Zhao Tiecheng)
Date: Mon, 8 Apr 2002 21:11:06 +0800
Subject: [uClinux-dev] uClinux porting of MIPS
In-Reply-To: <OFEFA70CFE.3261EF07-ON48256B95.000A37A4@accton.com.tw>
References: <OFEFA70CFE.3261EF07-ON48256B95.000A37A4@accton.com.tw>
Message-ID: <02040821110602.07143@localhost.localdomain>

On Monday 08 April 2002 10:37 am, you wrote:
> Hi,
>
>
> Seldom MIPS topic discussed here.
>
> I had ever ported uclinux+Microwin+Viewm on MIPS platform with gcc-2.96.
>
> In fact, the most puzzle is the "elf2flt" tool during porting process.
>
> I don't know how you convert ELF to your working FLAT format,
>
> but my method is to modify the elf2flt source code based on the version for
>
> ARM.
>
> I had it supported for R_MIPS_HI16, R_MIPS_LO16, R_MIPS_CALL16,
>
> R_MIPS_GOT16, R_MIPS_32 and R_MIPS_GPREL32.
>
> Actually, using GLOBAL OFFSET TABLE, we only need to do recloation for
>
> R_MIPS_32, R_MIPS_CALL16 & R_MIPS_GOT16 and to set the "_gp" to the correct
>
> value in the "elf2flt.ld".

	But how to set "_gp " ? I puzzle in MIPS CPU on gp very much!

>
> But i still don't know how to do relocation for R_MIPS_26 until now.

	in R_MIPS_26, the low 28 bit of a  address is right shfit 2 bit, then became 
the low 26 bit of a code. if you want relocate it, you should first get the 
low 26 bit of a code, then lift shfit 2 bit, add new offset, get the 28bit of 
the new value, right shfit it 2 bit and write back. 26 bit relocation is the 
jump shorter than 256M long, so the high 4 is usless. CPU think the high 4 
bit is same as PC. 


Zhao Tiecheng
Linpus, Shanghai
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From vinayak at ionicmicro.com  Mon Apr  8 10:50:24 2002
From: vinayak at ionicmicro.com (Vinayak Kore)
Date: Mon, 8 Apr 2002 20:20:24 +0530
Subject: [uClinux-dev] Problem while using kernal version 2.4
Message-ID: <01C1DF3A.D1445C60@VINAYAKA_98>

Hi Everybody,

I have installed ucLinux source on linux 7.2 machine. I have downloaded uClinux-dist-20020306.tar.gz & unzipped it. As given in instructions for compiling, I could do make xconfig, make dep & make with kernal version 2.0.x. But if I select kernal version 2.4.x, make xconfig goes through & make dep gives the following error message -

/tmp/cchGVhlx.s:Assembler messages:
/tmp/cchGVhlx.s:30:warning:Unrecognized .section attribute:want a, w, x
/tmp/cchGVhlx.s:30:warning:Unrecognized .section attribute:want a, w, x
/tmp/cchGVhlx.s:30:Error:Rest of line ignored. First ignored charactor is ','

Simillar error is given on line numbers - 62,195,231,184,335,436,555,1275,1399,1402 & 1406

During make xconfig, I have selected 5272 processor. Please guide me.

Regards,
Vinayak


This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From vinayak at ionicmicro.com  Mon Apr  8 10:55:37 2002
From: vinayak at ionicmicro.com (Vinayak Kore)
Date: Mon, 8 Apr 2002 20:25:37 +0530
Subject: [uClinux-dev] How to use ptherads on uClinux ?
Message-ID: <01C1DF3B.8BB5DA60@VINAYAKA_98>


Hi,

Can I use pthreads on uClinux ? Can a linux code that uses libpthread work as it is on uClinux ? If not, what all changes are required to be made ?

I tried this with kernal version 2.0.x. Its not building.

Please guide me.

Thanks & Regards,

Vinayak

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From frastrilla at intelnet.es  Mon Apr  8 11:38:06 2002
From: frastrilla at intelnet.es (Francis Rastrilla AGud)
Date: Mon, 08 Apr 2002 17:38:06 +0200
Subject: [uClinux-dev] Problems with NFS mounts
References: <3CB15C50.50403@intelnet.es> <20020408214413.B27194@beast.internal.moreton.com.au>
Message-ID: <3CB1B95E.8010701@intelnet.es>

David,

I don't think my problem has anything to be with 2.4 network stack or 
the lack of speed of 68EZ328,
Kernel 2.4.10 is working on my board without any problem, The very 
strangest thing is that with lastest kernels all works fine but only if 
I dont try to transfer or execute a file greater than 8kb.

I'm using busybox mount, When I try to mount using mount application 
from userland I get the following errors:

 
nfs warning: mount version older than kernel
nfs_get_root: getattr error = 116
nfs_read_super: get root inode failed

mount: wrong fs type, bad option, bad superblock on 
192.0.3.101:/home/proyectos,  or too many mounted file systems


David McCullough wrote:

>Jivin Francis Rastrilla AGud lays it down ...
>
>>Dear all,
>>
>>I'm working on a 68EZ328 based board with a 2.4.x kernel. 
>>
>>Since nfs mounts need to use portmap I'm not able to run any
>>application via a nfs mount.I get this behavoir from 20011112 distro .
>>
>>I can mount my remote directory and even browse it, but when I try
>>to tranfer or execute a file greater than 8k nfs-mount stops working
>>and I get the following message:
>>
>>nfs: server 192.0.3.101 not responding, still trying  
>>nfs: server 192.0.3.101 not responding, still trying
>>
>>If the file is smaller than 8k everything works properly 
>>
>>Is someone having the same problem?, Is portmap the problem?
>>
>
>I don't believe this has anything to do with portmap.  If portmap wasn't
>working the mounts would not work.
>
>When I first played with NFS on the uCsimm using 2.4 it seemed that the
>68EZ328 was a little too slow and the 2.4 network stack held interrupts
>out a little too long and the network was getting HW overruns.
>
>Many people has posted NFS mount options to work around this,  search
>through the archives and you'll find them.  It involves using smaller
>RX/TX buffers if I remember correctly,
>
>Cheers,
>Davidm
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20020408/3c5b677a/attachment.html>

From hamilton at SEDSystems.ca  Mon Apr  8 12:30:47 2002
From: hamilton at SEDSystems.ca (Kendrick Hamilton)
Date: Mon, 8 Apr 2002 10:30:47 -0600 (Canada Central Standard Time)
Subject: [uClinux-dev] Re: Linux on Motorola based router
In-Reply-To: <Pine.GSO.4.44.0204081734330.10753-100000@larsback.webjorn.org>
Message-ID: <Pine.WNT.4.44.0204081021000.222-100000@sw-55.sedsystems.ca>

This sounds do-able. The 68360 uses what ever is connected to chip select
0 to boot. My kernel is bigger then 256k but less then 512k, you need to
check AMD's web site to find out how big the 27040 is. If it is not big
enough for the kernel, it should hopefully be big enough for the
ctr0_rXm.S's code (our board has only 256k connected to chipselect 0 and
more flash elsewhere, we needed to boot like this). You also need to find
out the memory width of all memory devices and which chip selects they
reside on.
 You can download pavel piza's patch to gdb to make it work with a 68360.


On Mon, 8 Apr 2002, [ISO-8859-1] Mattias Webj?rn Eriksson wrote:

> Hello.
>
> Sorry for sending this mail direct to you.
> I have read the archives of uClinux mailling list, thats where I got
> your email address.
>
> I have a motorola 68360 33Mhz based router, Allied Telesyn AR390.
> The 68360 cpu version is (reading from the chip) MC68MH360OEM33K.
> My intention is to boot uCLinux on this router. Just because I'm
> courios and want to learn something new.
> I've never done anything like this before and never worked with motorola
> processors before.
>
> The router, I think, boots the Allied code from an EPROM (AMD27C040 150DC)
> and after that continues to load additional code from flash (INTEL).
>
> Would it be possible to burn an eqvivalent EPROM whith uClinux?
>
>
> Since there is this EPROM I guess the router is 'hardwired' to
> load code from the EPROM at boot time?
>
> There are soldings on the board marked BDM1 (there is no connector),
> where I guess one could attach a BDM.
>
> Thanks.
>
> Best Regards
>
> Mattias Webjorn Eriksson
>
>

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From justin.wojdacki at analog.com  Mon Apr  8 13:03:09 2002
From: justin.wojdacki at analog.com (Justin Wojdacki)
Date: Mon, 08 Apr 2002 10:03:09 -0700
Subject: [uClinux-dev] uClinux porting of MIPS
References: <OFEFA70CFE.3261EF07-ON48256B95.000A37A4@accton.com.tw> <02040821110602.07143@localhost.localdomain>
Message-ID: <3CB1CD4D.B3D35BCF@analog.com>

Zhao Tiecheng wrote:
> 
> On Monday 08 April 2002 10:37 am, you wrote:
> > Hi,
> >
> >
> > Seldom MIPS topic discussed here.
> >
> > I had ever ported uclinux+Microwin+Viewm on MIPS platform with gcc-2.96.
> >
> > In fact, the most puzzle is the "elf2flt" tool during porting process.
> >
> > I don't know how you convert ELF to your working FLAT format,
> >
> > but my method is to modify the elf2flt source code based on the version for
> >
> > ARM.
> >
> > I had it supported for R_MIPS_HI16, R_MIPS_LO16, R_MIPS_CALL16,
> >
> > R_MIPS_GOT16, R_MIPS_32 and R_MIPS_GPREL32.
> >
> > Actually, using GLOBAL OFFSET TABLE, we only need to do recloation for
> >
> > R_MIPS_32, R_MIPS_CALL16 & R_MIPS_GOT16 and to set the "_gp" to the correct
> >
> > value in the "elf2flt.ld".
> 
>         But how to set "_gp " ? I puzzle in MIPS CPU on gp very much!
> 

You should be setting $gp in your userland code based on $t9. (See the
MIPS ABI for more info). $t9 carries a base address from which $gp is
calculated.

_gp on MIPS should be set to the base of the GOT:

                 /* GP relative addressing assumes that the _gp - 32K
is
                 * set here
                 */
                _gp = ALIGN(0x10) + 0x7ff0 ;

                *(.got.plt)
                *(.got)

(this goes in the .data section of your linker file)

-- 
-------------------------------------------------
Justin Wojdacki        
justin.wojdacki at analog.com         (408) 350-5032
Communications Processors Group -- Analog Devices
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From michael at michaelshiloh.com  Mon Apr  8 13:37:50 2002
From: michael at michaelshiloh.com (michael shiloh)
Date: Mon, 8 Apr 2002 10:37:50 -0700 (PDT)
Subject: [uClinux-dev] i'm confused: m68k package brings arm? 
Message-ID: <Pine.LNX.4.33.0204081029430.1046-100000@magritte.magrittesystems.com>

hello,

i'm installing uclinux on my palm V.

host: x86 pc running linux, rh 7.2
target: palm V

following the brief installation instructions
in the archives, but updated to more recent
dates, i downloaded stuff from:

http://www.uclinux.org/pub/uClinux/m68k-elf-tools/tools-20020218/

which gave me:

  binutils-2.10-full.patch
  binutils-2.10.tar.bz2
  build-uclinux-tools.sh
  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
  genromfs-0.5.1.tar.gz
  uClibc.tar.gz

i was a little suprised to see the arm stuff, so i poked 
around more in the archives. i get the impression that this
is the correct stuff, but if this is explained explicitely
in the archives i didn't see it.

have i downloaded the correct code and patches to start
my 68k cross-development work? and can someone explain why
the word "arm" is in the patches?

thanks very much in advance,
michael

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From siddons at bnl.gov  Mon Apr  8 13:32:42 2002
From: siddons at bnl.gov (D. Peter Siddons)
Date: Mon, 08 Apr 2002 13:32:42 -0400
Subject: [uClinux-dev] uCsimm problem - Newbie
References: <OHEGKBKJNDMIKNAMMKBMGECNCAAA.eric.bosch@fourtress.nl>
Message-ID: <3CB1D43A.24F19B67@bnl.gov>

Hi Eric,
   Perhaps you should have said /dev/ttyS1, not simply ttyS1. Can
you telnet to it and correct the CONSOLE variable?
Pete.

"Eric Bosch (Fourtress)" wrote:
> 
> My host computer can not talk to the ucSimm board, does anyone have
> any
> suggestion?
> 
> I already configured minicom terminal to talk at 9600 8N1, when I
> plugged the
> RS 232 to the board. Then I changed the CONSOLE environment variable
> with the command setenv CONSOLE ttyS1. But now I can't communicatie
> with my board? I don't see a prompt when I start minicom and reset the
> target.
> 
> Who helps a newbie?
> 
> 
> 
> Thanks Eric
> 
> 

-- 
-----------------
D. Peter Siddons
National Synchrotron Light Source, Bldg. 725D
Brookhaven National Laboratory
Upton
New York 11973
Email: siddons at bnl.gov
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From jtersch at vt.edu  Mon Apr  8 13:55:42 2002
From: jtersch at vt.edu (Joseph Von Tersch)
Date: Mon, 8 Apr 2002 12:55:42 -0500
Subject: [uClinux-dev] must you always use -lc ???
Message-ID: <200204081759.g38Hx0P20902@underdog.vtethernet.net>

Hi,

I can't get any programs to link unless I use: -lc
is that normal??  I didn't think it would be, but then I don't know how the 
m68k-elf-gcc was setup.

Also,  is there a tool for looking at the functions in a library... See I 
built libbluetooth, but now when I make a function that needs it and link the 
library to it, it says undefined reference, like the function ISN'T in the 
library!!  It's KILLING ME!!  the way I built the library was with 
./configure --bindir -libdir --etc....  to all the m68k tools, so I think the 
library is ok.  I had no errors during build ('cept that -lc thing)  the 
function I'm saying it's missing IS specific to the library...if anyone could 
help me on this....i'd be soooo appreciative (i'm trying to get the bluez 
tools to compile for m68knommu)

Thanks,
Joseph
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From justin.wojdacki at analog.com  Mon Apr  8 15:20:56 2002
From: justin.wojdacki at analog.com (Justin Wojdacki)
Date: Mon, 08 Apr 2002 12:20:56 -0700
Subject: [uClinux-dev] must you always use -lc ???
References: <200204081759.g38Hx0P20902@underdog.vtethernet.net>
Message-ID: <3CB1ED98.9170BB30@analog.com>

Joseph Von Tersch wrote:
> 
> Hi,
> 
> I can't get any programs to link unless I use: -lc
> is that normal??  I didn't think it would be, but then I don't know how
> the m68k-elf-gcc was setup.
>

-lc tells gcc to link in libc. This might be necessary when
cross-compiling. I am not an expert on this however. 

> 
> Also,  is there a tool for looking at the functions in a library... See
> I built libbluetooth, but now when I make a function that needs it and
> link the library to it, it says undefined reference, like the function
> ISN'T in the library!!  It's KILLING ME!!  the way I built the library was
> with ./configure --bindir -libdir --etc....  to all the m68k tools, so I
> think the library is ok.  I had no errors during build ('cept that -lc
> thing)  the function I'm saying it's missing IS specific to the
> library...if anyone could help me on this....i'd be soooo appreciative
> (i'm trying to get the bluez tools to compile for m68knommu)
> 

nm (m68k-elf-nm in this case) is your friend. It will list all the
symbols in an object or executable file. Note that building the
library alone won't get you any complaints about unresolved symbols,
and no final linking has happened yet. 

-- 
-------------------------------------------------
Justin Wojdacki        
justin.wojdacki at analog.com         (408) 350-5032
Communications Processors Group -- Analog Devices
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From moh.shiha at ieee.org  Mon Apr  8 16:33:25 2002
From: moh.shiha at ieee.org (Mohamed Ali Shiha)
Date: Mon, 8 Apr 2002 22:33:25 +0200
Subject: [uClinux-dev] MC68VZ328 and mobile phone interface
Message-ID: <OE109cXPoGStfUamI9D00026150@hotmail.com>

Dear all,

I would like to access my mobile phone (siemens C35) using AT commands (the
phone is attached to ttyS0 to my MC68VZ328 development board) ... how can I
do that ... which daemons should I have and which software do I need to be
installed ..??

Thanks and regards
Mohamed Shiha

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From justin.wojdacki at analog.com  Mon Apr  8 17:32:20 2002
From: justin.wojdacki at analog.com (Justin Wojdacki)
Date: Mon, 08 Apr 2002 14:32:20 -0700
Subject: [uClinux-dev] MC68VZ328 and mobile phone interface
References: <OE109cXPoGStfUamI9D00026150@hotmail.com>
Message-ID: <3CB20C64.C52E02D4@analog.com>

Mohamed Ali Shiha wrote:
> 
> Dear all,
> 
> I would like to access my mobile phone (siemens C35) using AT commands (the
> phone is attached to ttyS0 to my MC68VZ328 development board) ... how can I
> do that ... which daemons should I have and which software do I need to be
> installed ..??
> 
> Thanks and regards
> Mohamed Shiha
> 

Take a look at minicom, tip, or ppp(d). If you want to network over
it, ppp(d) is probably your best bet. minicom or tip will work well if
you just want to interact with it. 

-- 
-------------------------------------------------
Justin Wojdacki        
justin.wojdacki at analog.com         (408) 350-5032
Communications Processors Group -- Analog Devices
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From davidm at snapgear.com  Mon Apr  8 18:22:45 2002
From: davidm at snapgear.com (David McCullough)
Date: Tue, 9 Apr 2002 08:22:45 +1000
Subject: [uClinux-dev] Problems with NFS mounts
In-Reply-To: <3CB1B95E.8010701@intelnet.es>; from frastrilla@intelnet.es on Mon, Apr 08, 2002 at 05:38:06PM +0200
References: <3CB15C50.50403@intelnet.es> <20020408214413.B27194@beast.internal.moreton.com.au> <3CB1B95E.8010701@intelnet.es>
Message-ID: <20020409082245.A31717@beast.internal.moreton.com.au>


Jivin Francis Rastrilla AGud lays it down ...
> David,
> 
> I don't think my problem has anything to be with 2.4 network stack or 
> the lack of speed of 68EZ328,
> Kernel 2.4.10 is working on my board without any problem, The very 
> strangest thing is that with lastest kernels all works fine but only if 
> I dont try to transfer or execute a file greater than 8kb.


Just to prove this try:

	mount -t nfs -o rsize=256,wsize=256 <addr>:<dir> <mount-point>

This was the previous workaround for this kind of behaviour.
If it has no affect I guess we have a new problem that no one has seen :-(


> I'm using busybox mount, When I try to mount using mount application 
> from userland I get the following errors:
> 
>  
> nfs warning: mount version older than kernel
> nfs_get_root: getattr error = 116
> nfs_read_super: get root inode failed
> 
> mount: wrong fs type, bad option, bad superblock on 
> 192.0.3.101:/home/proyectos,  or too many mounted file systems


Busybox mount is the only one that works with 2.4.x,  at least from the
selection in the uClinux-dist,

Cheers,
Davidm

-- 
David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
davidm at snapgear.com  Fx: +61 7 3891 3630  825 Stanley St., W'gabba QLD 4102, Oz
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From davidm at snapgear.com  Mon Apr  8 19:13:08 2002
From: davidm at snapgear.com (David McCullough)
Date: Tue, 9 Apr 2002 09:13:08 +1000
Subject: [uClinux-dev] i'm confused: m68k package brings arm?
In-Reply-To: <Pine.LNX.4.33.0204081029430.1046-100000@magritte.magrittesystems.com>; from michael@michaelshiloh.com on Mon, Apr 08, 2002 at 10:37:50AM -0700
References: <Pine.LNX.4.33.0204081029430.1046-100000@magritte.magrittesystems.com>
Message-ID: <20020409091308.C31717@beast.internal.moreton.com.au>


Jivin michael shiloh lays it down ...
> hello,
> 
> i'm installing uclinux on my palm V.
> 
> host: x86 pc running linux, rh 7.2
> target: palm V
> 
> following the brief installation instructions
> in the archives, but updated to more recent
> dates, i downloaded stuff from:
> 
> http://www.uclinux.org/pub/uClinux/m68k-elf-tools/tools-20020218/
> 
> which gave me:
> 
>   binutils-2.10-full.patch
>   binutils-2.10.tar.bz2
>   build-uclinux-tools.sh
>   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
>   genromfs-0.5.1.tar.gz
>   uClibc.tar.gz
> 
> i was a little suprised to see the arm stuff, so i poked 
> around more in the archives. i get the impression that this
> is the correct stuff, but if this is explained explicitely
> in the archives i didn't see it.
> 
> have i downloaded the correct code and patches to start
> my 68k cross-development work? and can someone explain why


Yes.  These are the right ones.  You can use the pre-compiled binaries
if that suits you.


> the word "arm" is in the patches?


Because the source can be built for ARM or m68k tools.  The main page at

	http://www.uclinux.org/pub/uClinux/uclinux-elf-tools/

mentions both streams I believe.  The arm/m68k/uclinux pages are all the
same one just to make it confusing :-)

Cheers,
Davidm

-- 
David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
davidm at snapgear.com  Fx: +61 7 3891 3630  825 Stanley St., W'gabba QLD 4102, Oz
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From davidm at snapgear.com  Mon Apr  8 19:16:55 2002
From: davidm at snapgear.com (David McCullough)
Date: Tue, 9 Apr 2002 09:16:55 +1000
Subject: [uClinux-dev] must you always use -lc ???
In-Reply-To: <200204081759.g38Hx0P20902@underdog.vtethernet.net>; from jtersch@vt.edu on Mon, Apr 08, 2002 at 12:55:42PM -0500
References: <200204081759.g38Hx0P20902@underdog.vtethernet.net>
Message-ID: <20020409091655.D31717@beast.internal.moreton.com.au>


Jivin Joseph Von Tersch lays it down ...
> Hi,
> 
> I can't get any programs to link unless I use: -lc
> is that normal??  I didn't think it would be, but then I don't know how the 
> m68k-elf-gcc was setup.


yes,  it's normal.


> Also,  is there a tool for looking at the functions in a library... See I 


m68k-elf-nm

Check the manpage for "nm", your normal system "nm" may be able to look at
symbols in the m68k libraries as well.

> built libbluetooth, but now when I make a function that needs it and link the 
> library to it, it says undefined reference, like the function ISN'T in the 
> library!!  It's KILLING ME!!  the way I built the library was with 
> ./configure --bindir -libdir --etc....  to all the m68k tools, so I think the 
> library is ok.  I had no errors during build ('cept that -lc thing)  the 
> function I'm saying it's missing IS specific to the library...if anyone could 
> help me on this....i'd be soooo appreciative (i'm trying to get the bluez 
> tools to compile for m68knommu)

You may need to run m68k-elf-ranlib on the library,  can't remember if it's
needed or not.

What order are the libraries on the link line:

	...gcc ... libbluetooth.a .... -lc

is what you probably want,

Cheers,
Davidm

-- 
David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
davidm at snapgear.com  Fx: +61 7 3891 3630  825 Stanley St., W'gabba QLD 4102, Oz
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From michael at michaelshiloh.com  Mon Apr  8 20:57:17 2002
From: michael at michaelshiloh.com (michael shiloh)
Date: Mon, 8 Apr 2002 17:57:17 -0700 (PDT)
Subject: [uClinux-dev] i'm confused: m68k package brings arm?
In-Reply-To: <20020409091308.C31717@beast.internal.moreton.com.au>
Message-ID: <Pine.LNX.4.33.0204081738300.1046-100000@magritte.magrittesystems.com>

On Tue, 9 Apr 2002, David McCullough wrote:

> 
> Jivin michael shiloh lays it down ...
love it. i haven't been called jivin in quite some time :-)


> > have i downloaded the correct code and patches to start
> > my 68k cross-development work? and can someone explain why
> 
> 
> Yes.  These are the right ones.  You can use the pre-compiled binaries
> if that suits you.

should suit me fine. i'm downloading them now (as we speak,
as it were)

> > the word "arm" is in the patches?
> Because the source can be built for ARM or m68k tools.  The main page at
> 
> 	http://www.uclinux.org/pub/uClinux/uclinux-elf-tools/
> 
> mentions both streams I believe.  The arm/m68k/uclinux pages are all the
> same one just to make it confusing :-)

i'm all in favor of common source.


> 
> Cheers,
> Davidm

thanks for the explanation. much appreciated.

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From jtersch at vt.edu  Tue Apr  9 00:11:56 2002
From: jtersch at vt.edu (Joseph Von Tersch)
Date: Mon, 8 Apr 2002 23:11:56 -0500
Subject: [uClinux-dev] linking probs...
Message-ID: <200204090315.g393FAP26676@underdog.vtethernet.net>

Hi, 

I'm trying to build the bluez tools... I can't seem to get libbluetooth to 
link.  I built it aready and it seems to be ok, doing:

nm libbluetooth.a 

gives:

000002ee T hci_lmtostr
00000a44 T hci_local_name
000002be T hci_lptostr
00000586 T hci_open_dev
0000028e T hci_ptypetostr
00000cae T hci_read_local_version
00000b60 T hci_read_remote_features
00000c02 T hci_read_remote_version
00000ab2 T hci_remote_name
00000608 T hci_send_cmd
etc.... etc.....


with gcc I do:

m68k-elf-gcc -o conftest -Wall -g -O2 -I../bluez-libs-2.0-pre8/include 
-L/usr/local/m68k-elf/lib -lbluetooth conftest.c -lc

and get this error:

/tmp/cceK2OmO.o: In function `main':
/usr/src/bt/bluez-utils-2.0-pre8/conftest.c:8: undefined reference to 
`hci_open_dev'
collect2: ld returned 1 exit status

conftest.c has:
#include "confdefs.h"
/* Override any gcc2 internal prototype to avoid an error.  */
/* We use char because int might match the return type of a gcc2
    builtin and then its argument prototype would still apply.  */
    char hci_open_dev();

    int main() {
    hci_open_dev()
    ; return 0; }

it's what's done by the configure program.

i've done ranlib, I've tried changing the order of the libraries, I've 
checked my paths, i've even put the libraries in the local dir of that 
conftest.c file....I HAVE NO IDEA why it's still not linking properly!!
it's driving me insane.   I can't get past the configure part because it 
fails with the link.

Thanks,
Joseph
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From mail2kugan at lycos.com  Mon Apr  8 23:40:26 2002
From: mail2kugan at lycos.com (Vivekanandarajah Kugan)
Date: Mon, 08 Apr 2002 20:40:26 -0700
Subject: [uClinux-dev] linking probs...
Message-ID: <GMFCPMOFLFKPBCAA@mailcity.com>

Hi
Is the bluettoth lib is also in /usr/local/m68k-elf/lib , other wise you will have to specify that also by -L$(BLUETOOTH_LIB_PATH) as well

where BLUETOOTH_LIB_PATH is the path of your bluetooth libraries

if you have the libraries in local direcetory use -L./
i.e.
m68k-elf-gcc -o conftest -Wall -g -O2 -I../bluez-libs-2.0-pre8/include -L/usr/local/m68k-elf/lib -L./ conftest.c -lc -lbluetooth 
Regards
Kugan
--

On Mon, 8 Apr 2002 23:11:56   
 Joseph Von Tersch wrote:
>Hi, 
>
>I'm trying to build the bluez tools... I can't seem to get libbluetooth to 
>link.  I built it aready and it seems to be ok, doing:
>
>nm libbluetooth.a 
>
>gives:
>
>000002ee T hci_lmtostr
>00000a44 T hci_local_name
>000002be T hci_lptostr
>00000586 T hci_open_dev
>0000028e T hci_ptypetostr
>00000cae T hci_read_local_version
>00000b60 T hci_read_remote_features
>00000c02 T hci_read_remote_version
>00000ab2 T hci_remote_name
>00000608 T hci_send_cmd
>etc.... etc.....
>
>
>with gcc I do:
>
>m68k-elf-gcc -o conftest -Wall -g -O2 -I../bluez-libs-2.0-pre8/include 
>-L/usr/local/m68k-elf/lib -lbluetooth conftest.c -lc
>
>and get this error:
>
>/tmp/cceK2OmO.o: In function `main':
>/usr/src/bt/bluez-utils-2.0-pre8/conftest.c:8: undefined reference to 
>`hci_open_dev'
>collect2: ld returned 1 exit status
>
>conftest.c has:
>#include "confdefs.h"
>/* Override any gcc2 internal prototype to avoid an error.  */
>/* We use char because int might match the return type of a gcc2
>    builtin and then its argument prototype would still apply.  */
>    char hci_open_dev();
>
>    int main() {
>    hci_open_dev()
>    ; return 0; }
>
>it's what's done by the configure program.
>
>i've done ranlib, I've tried changing the order of the libraries, I've 
>checked my paths, i've even put the libraries in the local dir of that 
>conftest.c file....I HAVE NO IDEA why it's still not linking properly!!
>it's driving me insane.   I can't get past the configure part because it 
>fails with the link.
>
>Thanks,
>Joseph
>This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/
>


See Dave Matthews Band live or win a signed guitar
http://r.lycos.com/r/bmgfly_mail_dmb/http://win.ipromotions.com/lycos_020201/splash.asp 
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From eric.bosch at fourtress.nl  Tue Apr  9 02:33:27 2002
From: eric.bosch at fourtress.nl (Eric Bosch (Fourtress))
Date: Tue, 9 Apr 2002 08:33:27 +0200
Subject: [uClinux-dev] uCsimm problem - Newbie
In-Reply-To: <3CB1D43A.24F19B67@bnl.gov>
Message-ID: <OHEGKBKJNDMIKNAMMKBMAEEOCAAA.eric.bosch@fourtress.nl>

Hi Peter,

No, I can't make a telnet or minicom connection to the board. It seems that
I have changed the serial port of the uCsimm to
/dev/ttyS1 (com2) but, the problem is that the uCsimm haven't got it. I
think I must restore the old flash values, because it works before I changed
this variable. But how?

Thanks for your answer.

Kind regards,

Eric


-----Oorspronkelijk bericht-----
Van: owner-uclinux-dev at uclinux.org
[mailto:owner-uclinux-dev at uclinux.org]Namens D. Peter Siddons
Verzonden: maandag 8 april 2002 19:33
Aan: uclinux-dev at uclinux.org
Onderwerp: Re: [uClinux-dev] uCsimm problem - Newbie


Hi Eric,
   Perhaps you should have said /dev/ttyS1, not simply ttyS1. Can
you telnet to it and correct the CONSOLE variable?
Pete.

"Eric Bosch (Fourtress)" wrote:
>
> My host computer can not talk to the ucSimm board, does anyone have
> any
> suggestion?
>
> I already configured minicom terminal to talk at 9600 8N1, when I
> plugged the
> RS 232 to the board. Then I changed the CONSOLE environment variable
> with the command setenv CONSOLE ttyS1. But now I can't communicatie
> with my board? I don't see a prompt when I start minicom and reset the
> target.
>
> Who helps a newbie?
>
>
>
> Thanks Eric
>
>

--
-----------------
D. Peter Siddons
National Synchrotron Light Source, Bldg. 725D
Brookhaven National Laboratory
Upton
New York 11973
Email: siddons at bnl.gov
This message resent by the uclinux-dev at uclinux.org list server
http://www.uClinux.org/

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From moh.shiha at ieee.org  Tue Apr  9 02:53:13 2002
From: moh.shiha at ieee.org (Mohamed Ali Shiha)
Date: Tue, 9 Apr 2002 08:53:13 +0200
Subject: [uClinux-dev] MC68VZ328 and mobile phone interface
References: <OE109cXPoGStfUamI9D00026150@hotmail.com> <3CB20C64.C52E02D4@analog.com>
Message-ID: <OE69ZKY1d66HcASHMZN00014342@hotmail.com>

did you compiled minicom for MC68VZ328 ... ?
I think if it is possible ... it will not add facility for developing a
program to send  and read sms from the attached mobile ...
Even, the board came without pppd and it is not included in the uClinux
source ... I think pppd is good to communicate with the board over a network
but is there a command to send AT commands to the mobile using pppd ... !!
.... Sorry coz I am so confused ...

Regards
Mohamed Shiha
----- Original Message -----
From: "Justin Wojdacki" <justin.wojdacki at analog.com>
To: <uclinux-dev at uclinux.org>
Sent: Monday, April 08, 2002 11:32 PM
Subject: Re: [uClinux-dev] MC68VZ328 and mobile phone interface


> Mohamed Ali Shiha wrote:
> >
> > Dear all,
> >
> > I would like to access my mobile phone (siemens C35) using AT commands
(the
> > phone is attached to ttyS0 to my MC68VZ328 development board) ... how
can I
> > do that ... which daemons should I have and which software do I need to
be
> > installed ..??
> >
> > Thanks and regards
> > Mohamed Shiha
> >
>
> Take a look at minicom, tip, or ppp(d). If you want to network over
> it, ppp(d) is probably your best bet. minicom or tip will work well if
> you just want to interact with it.
>
> --
> -------------------------------------------------
> Justin Wojdacki
> justin.wojdacki at analog.com         (408) 350-5032
> Communications Processors Group -- Analog Devices
> This message resent by the uclinux-dev at uclinux.org list server
http://www.uClinux.org/
>
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From stefan.jonsson at faltcom.se  Tue Apr  9 03:23:45 2002
From: stefan.jonsson at faltcom.se (Stefan Jonsson)
Date: Tue, 9 Apr 2002 09:23:45 +0200
Subject: [uClinux-dev] Probably a very trivial problem ...
Message-ID: <NGBBJKACILMHGKHMEHHLMEIOCAAA.stefan.jonsson@faltcom.se>

Hello list,

I have installed the arm-elf-toolchain and built romfs from the "full source
distribution". The thing is that boa and a lot of other things get built in
(as it seems). I have been able to choose not to inlude certain applications
like that but it still seems to include it into the build when I do 'make'.

The directory 'romfs' is containing the things built in (does it look like
my romfs does or will do)? How do I change what I will build in? (I have
tried 'make menuconfig' and 'make xconfig' and chosen to i.e. not include
boa, but my image.bin still gets the same size and the dir romfs still
contains the same things.) Do I have to specify some special things while
making maybe? (Like in lineos uclinux-kit: 'make TEMPLATE=mytemplate.sh') In
Lineos EB40LS+uCnet -kit you just add and remove things you want to build in
into a directory called 'romdisk'. Whatever u do there will be the way your
uClinux looks like. How does it work with "the full source distribution"
(from www.uclinux.org) if I want to customize settings, applications etc?

I woud be most greatful for any help (or explanations).
Thank you!

Regards,
Stefan Jonsson,
Student, University of Ume?, Sweden.

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From miles at lsi.nec.co.jp  Tue Apr  9 04:00:00 2002
From: miles at lsi.nec.co.jp (Miles Bader)
Date: 09 Apr 2002 17:00:00 +0900
Subject: [uClinux-dev] Re: Probably a very trivial problem ...
In-Reply-To: <NGBBJKACILMHGKHMEHHLMEIOCAAA.stefan.jonsson@faltcom.se>
References: <NGBBJKACILMHGKHMEHHLMEIOCAAA.stefan.jonsson@faltcom.se>
Message-ID: <buon0wdi9of.fsf@mcspd15.ucom.lsi.nec.co.jp>

"Stefan Jonsson" <stefan.jonsson at faltcom.se> writes:
> I have tried 'make menuconfig' and 'make xconfig' and chosen to
> i.e. not include boa, but my image.bin still gets the same size and
> the dir romfs still contains the same things.

Note that the build process won't automatically _remove_ old binaries
from the `romfs' tree, so after you've used `make menuconfig' (or
whatever) to choose your applications, do `rm -rf romfs' to make sure
you don't have any old stuff lying around, and then do a normal make to
repopulate the tree and create your images.

-Miles
-- 
`Life is a boundless sea of bitterness'
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From frastrilla at intelnet.es  Tue Apr  9 05:26:51 2002
From: frastrilla at intelnet.es (Francis Rastrilla AGud)
Date: Tue, 09 Apr 2002 11:26:51 +0200
Subject: [uClinux-dev] Problems with NFS mounts
References: <3CB15C50.50403@intelnet.es> <20020408214413.B27194@beast.internal.moreton.com.au> <3CB1B95E.8010701@intelnet.es> <20020409082245.A31717@beast.internal.moreton.com.au>
Message-ID: <3CB2B3DB.9050807@intelnet.es>

David,

You are right, now NFS works properly,

Thanks for your answer.

Kind regards, 

Francis 



David McCullough wrote:

>Jivin Francis Rastrilla AGud lays it down ...
>
>>David,
>>
>>I don't think my problem has anything to be with 2.4 network stack or 
>>the lack of speed of 68EZ328,
>>Kernel 2.4.10 is working on my board without any problem, The very 
>>strangest thing is that with lastest kernels all works fine but only if 
>>I dont try to transfer or execute a file greater than 8kb.
>>
>
>
>Just to prove this try:
>
>	mount -t nfs -o rsize=256,wsize=256 <addr>:<dir> <mount-point>
>
>This was the previous workaround for this kind of behaviour.
>If it has no affect I guess we have a new problem that no one has seen :-(
>
>
>>I'm using busybox mount, When I try to mount using mount application 
>>from userland I get the following errors:
>>
>> 
>>nfs warning: mount version older than kernel
>>nfs_get_root: getattr error = 116
>>nfs_read_super: get root inode failed
>>
>>mount: wrong fs type, bad option, bad superblock on 
>>192.0.3.101:/home/proyectos,  or too many mounted file systems
>>
>
>
>Busybox mount is the only one that works with 2.4.x,  at least from the
>selection in the uClinux-dist,
>
>Cheers,
>Davidm
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20020409/d20a59bb/attachment.html>

From tczhao at linpus.com.tw  Tue Apr  9 06:30:26 2002
From: tczhao at linpus.com.tw (Zhao Tiecheng)
Date: Tue, 9 Apr 2002 18:30:26 +0800
Subject: [uClinux-dev] Share lib of uClinux?
In-Reply-To: <3CB1CD4D.B3D35BCF@analog.com>
References: <OFEFA70CFE.3261EF07-ON48256B95.000A37A4@accton.com.tw> <02040821110602.07143@localhost.localdomain> <3CB1CD4D.B3D35BCF@analog.com>
Message-ID: <02040918302602.01045@localhost.localdomain>

Hi, All
	I have to use share lib in uClinux, is there anybody has some idea? The 
company I working for has its own GUI for linux, but the GUI lib is to big 
and cannot be static link. Due to MMU-less chip we use, we choice uClinux as 
OS. But uClinuux has no surpport of share lib. Who can tell me some idea 
about the way of implementation? And, the most IMPORTANT, Is it possible to 
implement share lib?

Thank you!!!!!!!!!!!
Zhao Tiecheng
Linpus, Shanghai
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From aran at iekey.nl  Tue Apr  9 06:26:16 2002
From: aran at iekey.nl (Aran Benner)
Date: Tue, 09 Apr 2002 12:26:16 +0200
Subject: [uClinux-dev] binary tools for Solaris
In-Reply-To: <3CADFCBB.E66B5A33@analog.com>
References: <3.0.6.32.20020405154039.007d3e30@iekey221>
Message-ID: <3.0.6.32.20020409122616.007d7210@iekey221>

Justin, 

Thank you for your reply.

I went ahead and downloaded the source files

binutils-2.10.tar.bz2, binutils-2.10-full.patch, gcc-2.95.3.tar.bz2,
gcc-2.95.3-full.patch, gcc-2.95.3-arm-pic.patch, gcc-2.95.3-arm-pic.patch2,
gcc-2.95.3-arm-mlib.patch, gcc-2.95.3-sigset.patch, genromfs-0.5.1.tar.gz,
a current elf2flt tree, a current uClibc tree and a current uClinux kernel
(2.4)

I've done a make config and make dep on the uCLinux kernel, edited the
build-uclinux-tools.sh script and set it in 'debug mode'.


>What errors are you currently seeing? 

I won't bother you with the entire output as it's about 250k in size...

However, I got the following error during the patching of (I believe)
gcc-2.95.3-full.patch


stage1
--------------------------------------------------------
STAGE 1 - needs building
  Looks like a unified context diff.
Hunk #2 failed at line 27.
Hunk #3 failed at line 86.
Hunk #4 failed at line 213.
Hunk #5 failed at line 246.
Hunk #6 failed at line 282.
Hunk #7 failed at line 421.
Hunk #8 failed at line 441.
Hunk #9 failed at line 467.
Hunk #10 failed at line 540.
Hunk #11 failed at line 550.
Hunk #12 failed at line 558.
Hunk #13 failed at line 566.
Hunk #14 failed at line 575.
Hunk #15 failed at line 1015.
Hunk #16 failed at line 1123.
Hunk #17 failed at line 1168.
Hunk #18 failed at line 1190.
Hunk #19 failed at line 1248.
Hunk #20 failed at line 1610.
Hunk #21 failed at line 1895.
Hunk #22 failed at line 2035.
Hunk #23 failed at line 2084.
Hunk #24 failed at line 2126.
Hunk #25 failed at line 2424.
Hunk #26 failed at line 2433.
Hunk #27 failed at line 2455.
Hunk #28 failed at line 2737.
Hunk #29 failed at line 2802.
Hunk #30 failed at line 2834.
Hunk #31 failed at line 2848.
Hunk #32 failed at line 2905.
Hunk #33 failed at line 3141.
Hunk #34 failed at line 3341.
Hunk #35 failed at line 3444.
Hunk #36 failed at line 3493.
Hunk #37 failed at line 3534.
Hunk #38 failed at line 3742.
Hunk #39 failed at line 3757.
patch: Memory mapping error: Not enough space


I'm not sure wether this is a real problem. I've only got 64mb ram, but
there is a 545mb swap partition of which only 11% is used.


Then it goes ahead applying the other patches and continues,
only to stop about 45 mins later with the following errors:

rm -f tmplibgcc1.a libgcc1.S
cp ../../gcc-2.95.3/gcc/config/m68k/lb1sf68.asm libgcc1.S
for name in _mulsi3 _udivsi3 _divsi3 _umodsi3 _modsi3 _double _float
_floatex _eqdf2 _nedf2 _gtdf2 _gedf2 _ltdf2 _ledf2 _eqsf2 _nesf2 _gtsf2
_gesf2 _ltsf2 _lesf2; \
do \
  echo ${name}; \
  /home/cross/m68k-elf-gcc/gcc/xgcc -B/home/cross/m68k-elf-gcc/gcc/
-B/crosstools/m68k-elf/bin/ -I/crosstools/m68k-elf/include -O2
-DCROSS_COMPILE -DIN_GCC     -g -O2 -I./include   -g1  -DIN_LIBGCC2
-D__GCC_FLOAT_NOT_NEEDED   -I. -I../../gcc-2.95.3/gcc
-I../../gcc-2.95.3/gcc/config -I../../gcc-2.95.3/gcc/../include -c
-DL${name} libgcc1.S; \
  if [ $? -eq 0 ] ; then true; else exit 1; fi; \
  mv libgcc1.o ${name}.o; \
  m68k-elf-ar rc tmplibgcc1.a ${name}.o; \
  rm -f ${name}.o; \
done
_mulsi3
/bin/sh: m68k-elf-ar: not found
_udivsi3
/bin/sh: m68k-elf-ar: not found
_divsi3
/bin/sh: m68k-elf-ar: not found
_umodsi3
/bin/sh: m68k-elf-ar: not found
_modsi3
/bin/sh: m68k-elf-ar: not found
_double
/bin/sh: m68k-elf-ar: not found
_float
/bin/sh: m68k-elf-ar: not found
_floatex
/bin/sh: m68k-elf-ar: not found
_eqdf2
/bin/sh: m68k-elf-ar: not found
_nedf2
/bin/sh: m68k-elf-ar: not found
_gtdf2
/bin/sh: m68k-elf-ar: not found
_gedf2
/bin/sh: m68k-elf-ar: not found
_ltdf2
/bin/sh: m68k-elf-ar: not found
_ledf2
/bin/sh: m68k-elf-ar: not found
_eqsf2
/bin/sh: m68k-elf-ar: not found
_nesf2
/bin/sh: m68k-elf-ar: not found
_gtsf2
/bin/sh: m68k-elf-ar: not found
_gesf2
/bin/sh: m68k-elf-ar: not found
_ltsf2
/bin/sh: m68k-elf-ar: not found
_lesf2
/bin/sh: m68k-elf-ar: not found
rm -f libgcc1.S
mv tmplibgcc1.a libgcc1-asm.a
mv: cannot access tmplibgcc1.a
make[1]: *** [libgcc1-asm.a] Error 2
make[1]: Leaving directory `/home/cross/m68k-elf-gcc/gcc'
make: *** [all-gcc] Error 2


If anyone has any suggestions?

Regards,

Aran Benner

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From davidm at snapgear.com  Tue Apr  9 07:52:33 2002
From: davidm at snapgear.com (David McCullough)
Date: Tue, 9 Apr 2002 21:52:33 +1000
Subject: [uClinux-dev] binary tools for Solaris
In-Reply-To: <3.0.6.32.20020409122616.007d7210@iekey221>; from aran@iekey.nl on Tue, Apr 09, 2002 at 12:26:16PM +0200
References: <3.0.6.32.20020405154039.007d3e30@iekey221> <3CADFCBB.E66B5A33@analog.com> <3.0.6.32.20020409122616.007d7210@iekey221>
Message-ID: <20020409215233.B5960@beast.internal.moreton.com.au>


Jivin Aran Benner lays it down ...
> Justin, 
> 
> Thank you for your reply.
> 
> I went ahead and downloaded the source files
> 
> binutils-2.10.tar.bz2, binutils-2.10-full.patch, gcc-2.95.3.tar.bz2,
> gcc-2.95.3-full.patch, gcc-2.95.3-arm-pic.patch, gcc-2.95.3-arm-pic.patch2,
> gcc-2.95.3-arm-mlib.patch, gcc-2.95.3-sigset.patch, genromfs-0.5.1.tar.gz,
> a current elf2flt tree, a current uClibc tree and a current uClinux kernel
> (2.4)


Use the uClibc.tar.gz file included with the sources.  The latest uClibc
from CVS may give you some problems as it has had some significant changes
since the last lot of tools were built.


> I've done a make config and make dep on the uCLinux kernel, edited the
> build-uclinux-tools.sh script and set it in 'debug mode'.
> 
> 
> >What errors are you currently seeing? 
> 
> I won't bother you with the entire output as it's about 250k in size...
> 
> However, I got the following error during the patching of (I believe)
> gcc-2.95.3-full.patch
> 
> 
> stage1
> --------------------------------------------------------
> STAGE 1 - needs building
>   Looks like a unified context diff.
> Hunk #2 failed at line 27.
> Hunk #3 failed at line 86.


Something is very worng with your patch here.  These patches should apply
cleanly.  What version of patch are you running ?

My is:
# patch 2.5
# Copyright 1988 Larry Wall
# Copyright 1997 Free Software Foundation, Inc.


...
> 
> I'm not sure wether this is a real problem. I've only got 64mb ram, but
> there is a 545mb swap partition of which only 11% is used.


You really need to get the patched right before continuing.


> Then it goes ahead applying the other patches and continues,
> only to stop about 45 mins later with the following errors:
> 
> rm -f tmplibgcc1.a libgcc1.S
> cp ../../gcc-2.95.3/gcc/config/m68k/lb1sf68.asm libgcc1.S
> for name in _mulsi3 _udivsi3 _divsi3 _umodsi3 _modsi3 _double _float
> _floatex _eqdf2 _nedf2 _gtdf2 _gedf2 _ltdf2 _ledf2 _eqsf2 _nesf2 _gtsf2
> _gesf2 _ltsf2 _lesf2; \
> do \
>   echo ${name}; \
>   /home/cross/m68k-elf-gcc/gcc/xgcc -B/home/cross/m68k-elf-gcc/gcc/
> -B/crosstools/m68k-elf/bin/ -I/crosstools/m68k-elf/include -O2
> -DCROSS_COMPILE -DIN_GCC     -g -O2 -I./include   -g1  -DIN_LIBGCC2
> -D__GCC_FLOAT_NOT_NEEDED   -I. -I../../gcc-2.95.3/gcc
> -I../../gcc-2.95.3/gcc/config -I../../gcc-2.95.3/gcc/../include -c
> -DL${name} libgcc1.S; \
>   if [ $? -eq 0 ] ; then true; else exit 1; fi; \
>   mv libgcc1.o ${name}.o; \
>   m68k-elf-ar rc tmplibgcc1.a ${name}.o; \
>   rm -f ${name}.o; \
> done
> _mulsi3
> /bin/sh: m68k-elf-ar: not found
> _udivsi3


Looks like binutils failed to build and run properly.
If you can it may also pay to run "bash" as you login shell.
Although the script appears to be running,  I think it should have stopped
before this on an earlier error.


Cheers,
Davidm

-- 
David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
davidm at snapgear.com  Fx: +61 7 3891 3630  825 Stanley St., W'gabba QLD 4102, Oz
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From securez at teleline.es  Tue Apr  9 07:53:26 2002
From: securez at teleline.es (Securez)
Date: Tue, 09 Apr 2002 13:53:26 +0200
Subject: [uClinux-dev] Share lib of uClinux?
In-Reply-To: <02040918302602.01045@localhost.localdomain>
References: <3CB1CD4D.B3D35BCF@analog.com>
 <OFEFA70CFE.3261EF07-ON48256B95.000A37A4@accton.com.tw>
 <02040821110602.07143@localhost.localdomain>
 <3CB1CD4D.B3D35BCF@analog.com>
Message-ID: <5.1.0.14.2.20020409135039.01fc27a0@pop3.terra.es>

I have the same requeriment, but at the moment the first goal is to get all 
the hardware funcinality, done.
I don't know how to implement this, but i ear that is posible.

Regards.

At 18.30 9/4/02 +0800, you wrote:
>Hi, All
>         I have to use share lib in uClinux, is there anybody has some 
> idea? The
>company I working for has its own GUI for linux, but the GUI lib is to big
>and cannot be static link. Due to MMU-less chip we use, we choice uClinux as
>OS. But uClinuux has no surpport of share lib. Who can tell me some idea
>about the way of implementation? And, the most IMPORTANT, Is it possible to
>implement share lib?
>
>Thank you!!!!!!!!!!!
>Zhao Tiecheng
>Linpus, Shanghai
>This message resent by the uclinux-dev at uclinux.org list server 
>http://www.uClinux.org/

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From shiyas at globaledgesoft.com  Tue Apr  9 08:05:46 2002
From: shiyas at globaledgesoft.com (shiaz)
Date: Tue, 9 Apr 2002 17:35:46 +0530
Subject: [uClinux-dev] newbie ---question
Message-ID: <02040917354600.01612@shiaz>

Hi list
	I am in to the process of porting Uclinux on to Samsung 44box , I am able to 
follow some part of the code (Thanks to Mac who helped us a lot ) . I want to 
get some more generic information about the Uclinux on arm .
A)Which will be the first file that will go to the reset location ??(We 
figured it as /arch/armnommu/boot/compressed/head.S) Are we right ???
B)How do we debug the code what ever we have written , with out the support 
of ICE ???
C)We have a custom made board . We have the code for 4510B  (thanx to mac 
again).We want to make it work (boot) on 44BOX .What are the issues we need 
to cocentrate on ?? which are the files we need to have a deeper 
understanding ? ??"?
D) Can u suggest any good links or throw some light  to under stand the 
concepts of booting sequence on arm ,the flow of the code ,and about the 
image 


Thanx in advance
Shiaz 

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From davidm at snapgear.com  Fri Apr  5 18:46:13 2002
From: davidm at snapgear.com (David McCullough)
Date: Sat, 6 Apr 2002 09:46:13 +1000
Subject: [uClinux-dev]
In-Reply-To: <200204051543.g35FhsA07747@<uclinux-dev@uclinux.org>; from mathias.fritzson@mecel.se on Fri, Apr 05, 2002 at 05:45:51PM +0200
References: <200204051543.g35FhsA07747@<uclinux-dev@uclinux.org>
Message-ID: <20020406094613.A24738@beast.internal.moreton.com.au>



Jivin mathias.fritzson at mecel.se lays it down ...
> Thanks David
> 
> My mails doesn't show in the archive, seems odd..

The archive may not be up to date or something.  I am seeing your replies
on the list which is all that should be required.

...
> I don't compile the kernel at the same machine as I compile the romfs.. It's an older version
> of the tools that we compiled for cygwin, and we don't have time to recompile for every new
> (great) release of the tools. But we have the possability to compile on the VMware box if
> neccesary.


if you are using new tools for the applications,  but an old kernel flat
loader you may have some problems there.

Make sure you get the latest binfmt_flat.c and flat.h and add them to your
kernel tree is you are using the latest tools to build applications.

Cheers,
Davidm

-- 
David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
davidm at snapgear.com  Fx: +61 7 3891 3630  825 Stanley St., W'gabba QLD 4102, Oz
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From rolf.peukert at imms.de  Tue Apr  9 09:46:38 2002
From: rolf.peukert at imms.de (Rolf Peukert)
Date: Tue, 09 Apr 2002 15:46:38 +0200
Subject: [uClinux-dev] status of Net+ARM support?
References: <200204031755.g33Htnv05808@mailgate5.cinetic.de>
Message-ID: <3CB2F0BE.AC2DDF85@imms.de>

a while ago, konnow at web.de wrote:

> I wonder if someone could shed some light on the status of the Net+ARM support in
> uCLinux? I've found posting on this list (dated back from last summer) mentioning a
> port to 2.4.[46].

Hi Konrad,

we're (still) working on a uClinux 2.4 port, and I just got a 2.4.17
kernel running on the Net+40 development board. It is not finished by
far, but serial and ethernet drivers are working.
Email me if you're interested in the source tree.

Btw, what's a good way to commit the additions (6 files, 2 directories)
and changes (33 modified files) to the cvs archive?

Best wishes,
Rolf
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From hamilton at SEDSystems.ca  Tue Apr  9 10:42:53 2002
From: hamilton at SEDSystems.ca (Kendrick Hamilton)
Date: Tue, 9 Apr 2002 08:42:53 -0600 (Canada Central Standard Time)
Subject: [uClinux-dev] linking probs...
In-Reply-To: <200204090315.g393FAP26676@underdog.vtethernet.net>
Message-ID: <Pine.WNT.4.44.0204090837310.119-100000@sw-55.sedsystems.ca>

Just a suggestion. If you are trying to link a C library to C++ code you
may run into problems. If the header files for the library don't have
proper
#ifdef __cplusplus
extern "C" {
#endif

...

#ifdef __cplusplus
}
#endif


around them, you will run into problems linking the code. The C++ compiler
mangles the names in the header file but the C compiler that compiled the
library did not mangle the names did not mangle the name. The linker
unmangles the name when it displays the error so it is more readable. To
fix this problem, put
extern "C" {
#include<bluetooth header file>
#include<next bluetooth header file>
...
}

or
fix the header files.

On Mon, 8 Apr 2002, Joseph Von Tersch wrote:

> Hi,
>
> I'm trying to build the bluez tools... I can't seem to get libbluetooth to
> link.  I built it aready and it seems to be ok, doing:
>
> nm libbluetooth.a
>
> gives:
>
> 000002ee T hci_lmtostr
> 00000a44 T hci_local_name
> 000002be T hci_lptostr
> 00000586 T hci_open_dev
> 0000028e T hci_ptypetostr
> 00000cae T hci_read_local_version
> 00000b60 T hci_read_remote_features
> 00000c02 T hci_read_remote_version
> 00000ab2 T hci_remote_name
> 00000608 T hci_send_cmd
> etc.... etc.....
>
>
> with gcc I do:
>
> m68k-elf-gcc -o conftest -Wall -g -O2 -I../bluez-libs-2.0-pre8/include
> -L/usr/local/m68k-elf/lib -lbluetooth conftest.c -lc
>
> and get this error:
>
> /tmp/cceK2OmO.o: In function `main':
> /usr/src/bt/bluez-utils-2.0-pre8/conftest.c:8: undefined reference to
> `hci_open_dev'
> collect2: ld returned 1 exit status
>
> conftest.c has:
> #include "confdefs.h"
> /* Override any gcc2 internal prototype to avoid an error.  */
> /* We use char because int might match the return type of a gcc2
>     builtin and then its argument prototype would still apply.  */
>     char hci_open_dev();
>
>     int main() {
>     hci_open_dev()
>     ; return 0; }
>
> it's what's done by the configure program.
>
> i've done ranlib, I've tried changing the order of the libraries, I've
> checked my paths, i've even put the libraries in the local dir of that
> conftest.c file....I HAVE NO IDEA why it's still not linking properly!!
> it's driving me insane.   I can't get past the configure part because it
> fails with the link.
>
> Thanks,
> Joseph
> This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/
>

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From jtersch at vt.edu  Tue Apr  9 12:12:14 2002
From: jtersch at vt.edu (Joseph Von Tersch)
Date: Tue, 9 Apr 2002 11:12:14 -0500
Subject: [uClinux-dev] linking probs...
In-Reply-To: <GMFCPMOFLFKPBCAA@mailcity.com>
References: <GMFCPMOFLFKPBCAA@mailcity.com>
Message-ID: <200204091515.g39FFjP32282@underdog.vtethernet.net>

yes, it's in /usr/local/m68k-elf/lib


On Monday 08 April 2002 10:40 pm, you wrote:
> Hi
> Is the bluettoth lib is also in /usr/local/m68k-elf/lib , other wise you
> will have to specify that also by -L$(BLUETOOTH_LIB_PATH) as well
>
> where BLUETOOTH_LIB_PATH is the path of your bluetooth libraries
>
> if you have the libraries in local direcetory use -L./
> i.e.
> m68k-elf-gcc -o conftest -Wall -g -O2 -I../bluez-libs-2.0-pre8/include
> -L/usr/local/m68k-elf/lib -L./ conftest.c -lc -lbluetooth Regards
> Kugan
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From JLiu at PacesetterElectronics.com  Tue Apr  9 11:17:03 2002
From: JLiu at PacesetterElectronics.com (JINGSONG LIU)
Date: Tue, 9 Apr 2002 10:17:03 -0500 
Subject: [uClinux-dev] RE: BDM driver error !
Message-ID: <FD20B4C99224D411B5AD0090278619CE07A0BD@SBS1>

Hi Greg :

After spending a few days I did for generating a new kernel with settings
for building
a driver modules and using insmod bdm.o and ./chk /dev/bdmcf0 for testing it
is works!
Thank you very much !

Next, I try to debug a small code without using uClinux but I got a error
message .
See below what I did 
----------------------------------------------------------------------------
-------------
[@localhost app]# m68k-elf-gdb app.gdb
GNU gdb 5.0
Copyright 2000 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "--host=i686-pc-linux-gnu
--target=m68k-bdm-elf"...
 Coldfire debug module version is 0 (5206(e))
(gdb) list 
1	#include <stdio.h> 
2	int main (int argc, char **argv) 
3	{ 
4		printf ("Hello !!\n");
5		printf ("vi Quick Reference\n");
6		printf ("Editing Text!\n"); 
7		printf ("Editing Text!!!\n"); 
8		return 0; 
9	} 
(gdb) break 4
Breakpoint 1 at 0x24: file main.c, line 4.
(gdb) run
Starting program: /home/jsl/uClinux-306/uClinux-dist/user/app/app.gdb 
Do you want to download
`/home/jsl/uClinux-306/uClinux-dist/user/app/app.gdb'?(y or n) y

Program received signal SIGBUS, Bus error.
0x2a4541fa in ?? ()
1: x/i $pc  0x2a4541fa:	BDM error: Target Bus Error
Disabling display 1 to avoid infinite recursion.
(gdb) 
----------------------------------------------------------------------------
---------------

I'm new to uClinux and linux, whenever you trop a few lines for me it
greatly help me a lot!!!

Thank you very much !

Jason Liu


-----Original Message-----
From: Greg Ungerer [mailto:gerg at snapgear.com]
Sent: Wednesday, April 03, 2002 7:53 AM
To: JINGSONG LIU
Subject: Re: BDM driver error !



Hi Jason,

JINGSONG LIU wrote:
> I'm new to Linux and uclinux and I met problem when I want to install 
> BDM for debugging. The problem is:
> 
> I try to install a BDM driver in my redhat 7.2 for MCF5272C3 but I got 
> many <unresolved symbol>  when
> 
> issue insmod bdm.o from reahat 7.2. Is something wrong when building the 
> driver or something else ?

I would guess that building the driver is not quite right.

To build a driver module you need the kernel sources
in /usr/src/linux. Have you compiled the kernel in that
directory?  And is that the kernel that you are running
on your system now?

Regards
Greg

------------------------------------------------------------------------
Greg Ungerer  --  Chief Software Wizard        EMAIL:  gerg at snapgear.com
SnapGear                                       PHONE:    +61 7 3279 1822
825 Stanley St,                                  FAX:    +61 7 3279 1820
Woolloogabba, QLD, 4102, Australia               WEB:   www.snapgear.com
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From damnyosh at yahoo.com  Tue Apr  9 11:23:14 2002
From: damnyosh at yahoo.com (Yosh K)
Date: Tue, 9 Apr 2002 08:23:14 -0700 (PDT)
Subject: [uClinux-dev] MCF5272 and Ethernet
Message-ID: <20020409152314.38861.qmail@web20607.mail.yahoo.com>

Hello all,
I'm running into a strange problem. I'm using MCF5272
eval board. Have the uClinux kernel sitting in Flash
(0xFFF00000) and use Colilo to boot the kernel. The
problem is ethernet and boa does not work when I do
this, but when used the exact same image and
downloaded to RAM (0x20000) using dBUG boa and
ethernet works fine. Any idea as to what's happening.
Thanks
Yosh

__________________________________________________
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://taxes.yahoo.com/
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From jtersch at vt.edu  Tue Apr  9 13:33:57 2002
From: jtersch at vt.edu (Joseph Von Tersch)
Date: Tue, 9 Apr 2002 12:33:57 -0500
Subject: [uClinux-dev] linking probs...
In-Reply-To: <Pine.WNT.4.44.0204090837310.119-100000@sw-55.sedsystems.ca>
References: <Pine.WNT.4.44.0204090837310.119-100000@sw-55.sedsystems.ca>
Message-ID: <200204091637.g39GbRP00720@underdog.vtethernet.net>

well I believe it's just C
It's the small test file that configure makes to test to see if the library 
will link in.  The symbols in there look ok, but then again, I'm not an 
expert on it.

--Joseph

On Tuesday 09 April 2002 09:42 am, you wrote:
> Just a suggestion. If you are trying to link a C library to C++ code you
> may run into problems. If the header files for the library don't have
> proper
> #ifdef __cplusplus
> extern "C" {
> #endif
>
> ...
>
> #ifdef __cplusplus
> }
> #endif
>
>
> around them, you will run into problems linking the code. The C++ compiler
> mangles the names in the header file but the C compiler that compiled the
> library did not mangle the names did not mangle the name. The linker
> unmangles the name when it displays the error so it is more readable. To
> fix this problem, put
> extern "C" {
> #include<bluetooth header file>
> #include<next bluetooth header file>
> ...
> }
>
> or
> fix the header files.
>
> On Mon, 8 Apr 2002, Joseph Von Tersch wrote:
> > Hi,
> >
> > I'm trying to build the bluez tools... I can't seem to get libbluetooth
> > to link.  I built it aready and it seems to be ok, doing:
> >
> > nm libbluetooth.a
> >
> > gives:
> >
> > 000002ee T hci_lmtostr
> > 00000a44 T hci_local_name
> > 000002be T hci_lptostr
> > 00000586 T hci_open_dev
> > 0000028e T hci_ptypetostr
> > 00000cae T hci_read_local_version
> > 00000b60 T hci_read_remote_features
> > 00000c02 T hci_read_remote_version
> > 00000ab2 T hci_remote_name
> > 00000608 T hci_send_cmd
> > etc.... etc.....
> >
> >
> > with gcc I do:
> >
> > m68k-elf-gcc -o conftest -Wall -g -O2 -I../bluez-libs-2.0-pre8/include
> > -L/usr/local/m68k-elf/lib -lbluetooth conftest.c -lc
> >
> > and get this error:
> >
> > /tmp/cceK2OmO.o: In function `main':
> > /usr/src/bt/bluez-utils-2.0-pre8/conftest.c:8: undefined reference to
> > `hci_open_dev'
> > collect2: ld returned 1 exit status
> >
> > conftest.c has:
> > #include "confdefs.h"
> > /* Override any gcc2 internal prototype to avoid an error.  */
> > /* We use char because int might match the return type of a gcc2
> >     builtin and then its argument prototype would still apply.  */
> >     char hci_open_dev();
> >
> >     int main() {
> >     hci_open_dev()
> >     ; return 0; }
> >
> > it's what's done by the configure program.
> >
> > i've done ranlib, I've tried changing the order of the libraries, I've
> > checked my paths, i've even put the libraries in the local dir of that
> > conftest.c file....I HAVE NO IDEA why it's still not linking properly!!
> > it's driving me insane.   I can't get past the configure part because it
> > fails with the link.
> >
> > Thanks,
> > Joseph
> > This message resent by the uclinux-dev at uclinux.org list server
> > http://www.uClinux.org/
>
> This message resent by the uclinux-dev at uclinux.org list server
> http://www.uClinux.org/
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From MGroden at hxi.com  Tue Apr  9 13:04:57 2002
From: MGroden at hxi.com (Mike Groden)
Date: Tue, 9 Apr 2002 13:04:57 -0400 
Subject: [uClinux-dev] MCF5272 and Ethernet
Message-ID: <879EA880A0FED411996B00B0D0B082EC2B4158@hxi_exch01.hxi.com>

It's probably the MAC address.  The dBUG module reads a MAC address from
flash and sets up the appropriate FEC registers.  I had to add code to the
Colilo bootloader to mimic this.

-----Original Message-----
From: Yosh K [mailto:damnyosh at yahoo.com]
Sent: Tuesday, April 09, 2002 11:23 AM
To: uclinux-dev at uclinux.org
Subject: [uClinux-dev] MCF5272 and Ethernet


Hello all,
I'm running into a strange problem. I'm using MCF5272
eval board. Have the uClinux kernel sitting in Flash
(0xFFF00000) and use Colilo to boot the kernel. The
problem is ethernet and boa does not work when I do
this, but when used the exact same image and
downloaded to RAM (0x20000) using dBUG boa and
ethernet works fine. Any idea as to what's happening.
Thanks
Yosh

__________________________________________________
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://taxes.yahoo.com/
This message resent by the uclinux-dev at uclinux.org list server
http://www.uClinux.org/
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From damnyosh at yahoo.com  Tue Apr  9 13:11:13 2002
From: damnyosh at yahoo.com (Yosh K)
Date: Tue, 9 Apr 2002 10:11:13 -0700 (PDT)
Subject: [uClinux-dev] MCF5272 and Ethernet
In-Reply-To: <879EA880A0FED411996B00B0D0B082EC2B4158@hxi_exch01.hxi.com>
Message-ID: <20020409171113.67007.qmail@web20607.mail.yahoo.com>

That makes sens :)
Thanks Mike
--- Mike Groden <MGroden at hxi.com> wrote:
> It's probably the MAC address.  The dBUG module
> reads a MAC address from
> flash and sets up the appropriate FEC registers.  I
> had to add code to the
> Colilo bootloader to mimic this.
> 
> -----Original Message-----
> From: Yosh K [mailto:damnyosh at yahoo.com]
> Sent: Tuesday, April 09, 2002 11:23 AM
> To: uclinux-dev at uclinux.org
> Subject: [uClinux-dev] MCF5272 and Ethernet
> 
> 
> Hello all,
> I'm running into a strange problem. I'm using
> MCF5272
> eval board. Have the uClinux kernel sitting in Flash
> (0xFFF00000) and use Colilo to boot the kernel. The
> problem is ethernet and boa does not work when I do
> this, but when used the exact same image and
> downloaded to RAM (0x20000) using dBUG boa and
> ethernet works fine. Any idea as to what's
> happening.
> Thanks
> Yosh
> 
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Tax Center - online filing with TurboTax
> http://taxes.yahoo.com/
> This message resent by the uclinux-dev at uclinux.org
> list server
> http://www.uClinux.org/
> This message resent by the uclinux-dev at uclinux.org
> list server http://www.uClinux.org/


__________________________________________________
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://taxes.yahoo.com/
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From vp at ix.netcom.com  Tue Apr  9 16:56:31 2002
From: vp at ix.netcom.com (vp at ix.netcom.com)
Date: Tue, 09 Apr 2002 13:56:31 -0700
Subject: [uClinux-dev] linking probs...
Message-ID: <Springmail.0994.1018385791.0.06462800@webmail.pas.earthlink.net>



> On Mon, 8 Apr 2002, Joseph Von Tersch wrote:
[...]
> > m68k-elf-gcc -o conftest -Wall -g -O2 -I../bluez-libs-2.0-pre8/include
> > -L/usr/local/m68k-elf/lib -lbluetooth conftest.c -lc
> >
> > and get this error:
> >
> > /tmp/cceK2OmO.o: In function `main':
> > /usr/src/bt/bluez-utils-2.0-pre8/conftest.c:8: undefined reference to
> > `hci_open_dev'
> > collect2: ld returned 1 exit status

Try to switch the order of -lbluetooth and conftest.

The linker only picks up library symbols to resolve something, and doesn't rescan the command line. In your case, -lbluetooth appears prior to conftest, so by the time linker sees -lbluetooth there's no symbols to resolve.

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From uclinux at schoeldgen.de  Tue Apr  9 19:27:35 2002
From: uclinux at schoeldgen.de (Matthias Schoeldgen)
Date: Wed, 10 Apr 2002 01:27:35 +0200
Subject: [uClinux-dev] where can i find m68k-palmos-coff-gcc
References: <Pine.LNX.4.33.0204051802210.11921-100000@magritte.magrittesystems.com> <20020406224647.C25711@beast.internal.moreton.com.au>
Message-ID: <3CB378E7.9B3AF0F5@schoeldgen.de>

David McCullough wrote:
> 
> Jivin michael shiloh lays it down ...
> > hello,
> >
> > dan trainor asked this in january, and i searched the
> > archive but saw no answer. i'm trying to build an
> > image for my palm5. my build fails at:
> >
> >   make[2]: Entering directory
> >   `/opt/uClinux/uClinux-dist/vendors/3com/palm-loader'm68k-palmos-coff-gcc
> >   -c -O2 -static    PalmLoader.c
> >   make[2]: m68k-palmos-coff-gcc: Command not found
> >
> > does anyone know where i can find this program?
> 
> I found the copy I am using somehere on the web using google and following
> my nose.  Have a look around and see how you go.  I don't seem to have the
> original archive anymore,  but I could make one if you get desperate.
> 
> It's part of a gcc for palmos development,  it was not uClinux related in
> any way,
> 
> Cheers,
> Davidm
Hello David and Jivin!
Try the LinuxDA people, they used to provide the m68k-palmos toolchain
on their website. 
AFAIK the URL was http://www.linuxda.com
Good luck!
matthias
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From davidm at snapgear.com  Tue Apr  9 20:11:20 2002
From: davidm at snapgear.com (David McCullough)
Date: Wed, 10 Apr 2002 10:11:20 +1000
Subject: [uClinux-dev] status of Net+ARM support?
In-Reply-To: <3CB2F0BE.AC2DDF85@imms.de>; from rolf.peukert@imms.de on Tue, Apr 09, 2002 at 03:46:38PM +0200
References: <200204031755.g33Htnv05808@mailgate5.cinetic.de> <3CB2F0BE.AC2DDF85@imms.de>
Message-ID: <20020410101120.A8708@beast.internal.moreton.com.au>


Jivin Rolf Peukert lays it down ...
> a while ago, konnow at web.de wrote:
> 
> > I wonder if someone could shed some light on the status of the Net+ARM support in
> > uCLinux? I've found posting on this list (dated back from last summer) mentioning a
> > port to 2.4.[46].
> 
> Hi Konrad,
> 
> we're (still) working on a uClinux 2.4 port, and I just got a 2.4.17
> kernel running on the Net+40 development board. It is not finished by
> far, but serial and ethernet drivers are working.
> Email me if you're interested in the source tree.
> 
> Btw, what's a good way to commit the additions (6 files, 2 directories)
> and changes (33 modified files) to the cvs archive?


Send us a patch against the current CVS and we'll add it in :-)

Cheers,
Davidm

-- 
David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
davidm at snapgear.com  Fx: +61 7 3891 3630  825 Stanley St., W'gabba QLD 4102, Oz
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From uclinux at schoeldgen.de  Tue Apr  9 20:02:11 2002
From: uclinux at schoeldgen.de (Matthias Schoeldgen)
Date: Wed, 10 Apr 2002 02:02:11 +0200
Subject: [uClinux-dev] MC68VZ328 and mobile phone interface
References: <OE109cXPoGStfUamI9D00026150@hotmail.com> <3CB20C64.C52E02D4@analog.com> <OE69ZKY1d66HcASHMZN00014342@hotmail.com>
Message-ID: <3CB38102.736D1BAD@schoeldgen.de>

Mohamed Ali Shiha wrote:
> 
> did you compiled minicom for MC68VZ328 ... ?
> I think if it is possible ... it will not add facility for developing a
> program to send  and read sms from the attached mobile ...
> Even, the board came without pppd and it is not included in the uClinux
> source ... I think pppd is good to communicate with the board over a network
> but is there a command to send AT commands to the mobile using pppd ... !!
> .... Sorry coz I am so confused ...
> 
> Regards
> Mohamed Shiha
> ----- Original Message -----
> From: "Justin Wojdacki" <justin.wojdacki at analog.com>
> To: <uclinux-dev at uclinux.org>
> Sent: Monday, April 08, 2002 11:32 PM
> Subject: Re: [uClinux-dev] MC68VZ328 and mobile phone interface
> 
> > Mohamed Ali Shiha wrote:
> > >
> > > Dear all,
> > >
> > > I would like to access my mobile phone (siemens C35) using AT commands
> (the
> > > phone is attached to ttyS0 to my MC68VZ328 development board) ... how
> can I
> > > do that ... which daemons should I have and which software do I need to
> be
> > > installed ..??
> > >
> > > Thanks and regards
> > > Mohamed Shiha
> > >
> >
> > Take a look at minicom, tip, or ppp(d). If you want to network over
> > it, ppp(d) is probably your best bet. minicom or tip will work well if
> > you just want to interact with it.
> >
> > --
> > -------------------------------------------------
> > Justin Wojdacki
> > justin.wojdacki at analog.com         (408) 350-5032
> > Communications Processors Group -- Analog Devices
Hi there !
The simplest way to send some bytes to your serial port imho is just to
open the /dev/ttyS0 device from your program and then start writing,
after setting the correct baudrate. And read from /dev/ttyS0 to get your
replies. there you have the smallest terminal program in the world :-).
Please correct me if I'm wrong.

Greetings 
matthias
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From gerg at snapgear.com  Tue Apr  9 20:18:48 2002
From: gerg at snapgear.com (Greg Ungerer)
Date: Wed, 10 Apr 2002 10:18:48 +1000
Subject: [uClinux-dev] status of Net+ARM support?
References: <200204031755.g33Htnv05808@mailgate5.cinetic.de> <3CB2F0BE.AC2DDF85@imms.de>
Message-ID: <3CB384E8.3010106@snapgear.com>


Hi Rolf,

Rolf Peukert wrote:

> we're (still) working on a uClinux 2.4 port, and I just got a 2.4.17
> kernel running on the Net+40 development board. It is not finished by
> far, but serial and ethernet drivers are working.
> Email me if you're interested in the source tree.
> 
> Btw, what's a good way to commit the additions (6 files, 2 directories)
> and changes (33 modified files) to the cvs archive?


If you send patches against the CVS head to eithr myself or
davidm at snapgear.com we can commit them for you.

(Or you can send patches against the most recent source snapshot
tarball, and that is ok too).

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

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From gerg at snapgear.com  Tue Apr  9 20:29:17 2002
From: gerg at snapgear.com (Greg Ungerer)
Date: Wed, 10 Apr 2002 10:29:17 +1000
Subject: [uClinux-dev] RE: BDM driver error !
References: <FD20B4C99224D411B5AD0090278619CE07A0BD@SBS1>
Message-ID: <3CB3875D.1040303@snapgear.com>


Hi Jason,

JINGSONG LIU wrote:

> After spending a few days I did for generating a new kernel with settings
> for building
> a driver modules and using insmod bdm.o and ./chk /dev/bdmcf0 for testing it
> is works!
> Thank you very much !


Great!


> Next, I try to debug a small code without using uClinux but I got a error
> message .
> See below what I did 
> ----------------------------------------------------------------------------
> -------------
> [@localhost app]# m68k-elf-gdb app.gdb
> GNU gdb 5.0
> Copyright 2000 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain
> conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for details.
> This GDB was configured as "--host=i686-pc-linux-gnu
> --target=m68k-bdm-elf"...
>  Coldfire debug module version is 0 (5206(e))


OK, you have a few problems here.
Are you using any .gdbinit script?

Firstly to use BDM in gdb you need to use the gdb "target"
command. For example "target bdm /dev/bdmcf0". Without this
you are not debugging over the BDM.


> (gdb) list 
> 1	#include <stdio.h> 
> 2	int main (int argc, char **argv) 
> 3	{ 
> 4		printf ("Hello !!\n");
> 5		printf ("vi Quick Reference\n");
> 6		printf ("Editing Text!\n"); 
> 7		printf ("Editing Text!!!\n"); 
> 8		return 0; 
> 9	} 
> (gdb) break 4
> Breakpoint 1 at 0x24: file main.c, line 4.
> (gdb) run
> Starting program: /home/jsl/uClinux-306/uClinux-dist/user/app/app.gdb 
> Do you want to download
> `/home/jsl/uClinux-306/uClinux-dist/user/app/app.gdb'?(y or n) y


Problem here is that you trying to load and run the application alone.
You are not running uClinux yet. uClinux apps cannot be run stand alone,
only wihtin uClinux.

Typically I would do something like:

     target bdm /dev/bdmcf0
     load image/image.elf
     set $pc = 0x20000
     cont

You will need to do more than this though. Before you can do
the load your board must have its SRAM/DRAM initialized. How to
do this depends on which board you are using. Also what the
exact $pc value will be depends on how you setup the build.

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

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From pauli at snapgear.com  Wed Apr 10 01:06:51 2002
From: pauli at snapgear.com (pauli at snapgear.com)
Date: Wed, 10 Apr 2002 15:06:51 +1000
Subject: [uClinux-dev] Shared libraries
Message-ID: <200204100506.g3A56prk019420@skaro.internal.moreton.com.au>

Hi all,

I posted a message about our shared library developments back on April 2nd.  
This is now available as a technical bulletin on our site.  See:


	http://www.snapgear.com/techbulletins.html
or
	http://www.snapgear.com/tb20020409.html


Our internal testing is progressing well albeit slowly.
DavidM is working on supporting other 68k platforms as I type this.


Regards,

Pauli


This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From shankarr at connexus.com.sg  Wed Apr 10 00:58:51 2002
From: shankarr at connexus.com.sg (Shankar Rajendran)
Date: Wed, 10 Apr 2002 12:58:51 +0800
Subject: [uClinux-dev] Kernel Panic
Message-ID: <E16vAC3-0006mX-00@host.hostsoln.net>

 Hi all,

    I am using Arm Target board.. I need to download the uclinux kernel 
into the SDRAM of the Target board through JEENI JTAG.. I have made 
changes in head-arm.S, hardware.h and setup.c as per my memory mappings 
of the target board.

After I have downloaded the kernel into the SDRAM, I have tried to 
connect the board using telnet but it is not working.. So I put some 
break points in the start_kernel function of main.c. During execution, 
I got kernel Panic "Attempt to kill init" error while executing 
kernel_thread function in the process.c.

Please help me to solve this problem...

Cheers,

Shankar Rajendran..
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From aran at iekey.nl  Wed Apr 10 02:56:22 2002
From: aran at iekey.nl (Aran Benner)
Date: Wed, 10 Apr 2002 08:56:22 +0200
Subject: [uClinux-dev] binary tools for Solaris
In-Reply-To: <20020409215233.B5960@beast.internal.moreton.com.au>
References: <3.0.6.32.20020409122616.007d7210@iekey221>
 <3.0.6.32.20020405154039.007d3e30@iekey221>
 <3CADFCBB.E66B5A33@analog.com>
 <3.0.6.32.20020409122616.007d7210@iekey221>
Message-ID: <3.0.6.32.20020410085622.007d4460@iekey221>

David,

>Use the uClibc.tar.gz file included with the sources.
Actually, I did.

>Something is very worng with your patch here.  These patches should apply
>cleanly.  What version of patch are you running ?
I was running the Solaris version. But as I've also had problems with
Solaris' make and tar, so I took your advice and installed gnu-patch 2.5.4

>Looks like binutils failed to build and run properly.
Maybe more problems with the Solaris binutils?

>If you can it may also pay to run "bash" as you login shell.
I do, but as the build-uclinux-tools.sh was a sh shell I figured it'd be
best to run it from sh. 

Anyway, using gnu-patch seems to have solved the patching problem, but I
still get the make errors. My boss has decided we should try it on a Linux
host, with the linux binutils, so I'm going to set up a Linux box today.

Thanks for your help.

Regards,

Aran

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From ferrin at bingdata.es  Wed Apr 10 03:54:46 2002
From: ferrin at bingdata.es (Agustin Ferrin Pozuelo)
Date: 10 Apr 2002 09:54:46 +0200
Subject: [uClinux-dev] graphics library for 4bpp modes
Message-ID: <1018425288.2322.51.camel@id13.bingdata.es>

I have been developing & using a fast graphics library for the motorola
Dragonball LCD controller. It can effortlessly adapted for any 4bpp
framebuffer.

* It does a lot of pixel/line/box drawing, with some very fast hacks (as
fast as I could do).

* It has above ten 'putimage' functions, several ways of transparency
included.

* It can load & save 'ppm' images, but binary format is preferred and
native.

* It has also text put, centered text fonts, and utilities for capturing
any existing text font. It's as simple as having a ppm file with "A B C
..\n O P Q ..." and everything is computed and the font generated.

* It has multiple-screenbuffer support, (limited but) arbitrary screen
size and -virtual- size, so it is possible to blit images from a buffer
to another, to switch screens fast and to scroll around a virtual
screen.

* It is tested & working, since it was a preliminary part of my current
project.

Is anybody interested? I would like to share this code; but it needs
some beautify & translation work, so I want to be sure it will be of use
for the Open Source community.

Cheers!

-- 
Agustin Ferrin Pozuelo
Embedded Systems Engineer
at BINGdata Espa?a
ferrin at bingdata.es

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From davidm at snapgear.com  Wed Apr 10 04:18:30 2002
From: davidm at snapgear.com (David McCullough)
Date: Wed, 10 Apr 2002 18:18:30 +1000
Subject: [uClinux-dev] binary tools for Solaris
In-Reply-To: <3.0.6.32.20020410085622.007d4460@iekey221>; from aran@iekey.nl on Wed, Apr 10, 2002 at 08:56:22AM +0200
References: <3.0.6.32.20020409122616.007d7210@iekey221> <3.0.6.32.20020405154039.007d3e30@iekey221> <3CADFCBB.E66B5A33@analog.com> <3.0.6.32.20020409122616.007d7210@iekey221> <20020409215233.B5960@beast.internal.moreton.com.au> <3.0.6.32.20020410085622.007d4460@iekey221>
Message-ID: <20020410181830.B19823@beast.internal.moreton.com.au>


Jivin Aran Benner lays it down ...
> David,
> 
> >Use the uClibc.tar.gz file included with the sources.
> Actually, I did.
>
> >Something is very worng with your patch here.  These patches should apply
> >cleanly.  What version of patch are you running ?
> I was running the Solaris version. But as I've also had problems with
> Solaris' make and tar, so I took your advice and installed gnu-patch 2.5.4
> 
> >Looks like binutils failed to build and run properly.
> Maybe more problems with the Solaris binutils?
> 
> >If you can it may also pay to run "bash" as you login shell.
> I do, but as the build-uclinux-tools.sh was a sh shell I figured it'd be
> best to run it from sh. 

It should be safe on bourne shell, but I run bash and something may have
slipped in there :-)

> Anyway, using gnu-patch seems to have solved the patching problem, but I
> still get the make errors. My boss has decided we should try it on a Linux

You need to use GNU make,  lots of the utils involved require GNU make,
thus the reason the build script tries to force "gmake".

> host, with the linux binutils, so I'm going to set up a Linux box today.

Well that should work well ;-)

Cheers,
Davidm

-- 
David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
davidm at snapgear.com  Fx: +61 7 3891 3630  825 Stanley St., W'gabba QLD 4102, Oz
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From tczhao at linpus.com.tw  Wed Apr 10 04:24:05 2002
From: tczhao at linpus.com.tw (Zhao Tiecheng)
Date: Wed, 10 Apr 2002 16:24:05 +0800
Subject: [uClinux-dev] Shared libraries
In-Reply-To: <200204100506.g3A56prk019420@skaro.internal.moreton.com.au>
References: <200204100506.g3A56prk019420@skaro.internal.moreton.com.au>
Message-ID: <02041016240501.01153@localhost.localdomain>

On Wednesday 10 April 2002 01:06 pm, you wrote:
> Hi all,
>
> I posted a message about our shared library developments back on April 2nd.
> This is now available as a technical bulletin on our site.  See:
>
>
> 	http://www.snapgear.com/techbulletins.html
> or
> 	http://www.snapgear.com/tb20020409.html



	In the page, it say "The shared library tools can be downloaded from 
mid-April 2002 onwards from uClinux elf tools." but I cannot find the link at 
all. Is it the m68k-elf-20020218 ?

>
>
> Our internal testing is progressing well albeit slowly.
> DavidM is working on supporting other 68k platforms as I type this.
>
>
> Regards,
>
> Pauli
>
>
> This message resent by the uclinux-dev at uclinux.org list server
> http://www.uClinux.org/

-- 
Zhao Tiecheng
Linpus Infotech Inc.
1105-1106 Hong Cao Building,
421 Hong Cao Rd. Caohejing,
Shanghai 200233, PRC
Tel: 86-21-64951968, 64953152, 64855098
Fax: 86-21-64954968
http://www.linpus.com.tw
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From lpm at leox.org  Wed Apr 10 04:41:21 2002
From: lpm at leox.org (The LEOX team)
Date: Wed, 10 Apr 2002 10:41:21 +0200
Subject: [uClinux-dev] binary tools for Solaris
References: <3.0.6.32.20020409122616.007d7210@iekey221>
	 <3.0.6.32.20020405154039.007d3e30@iekey221>
	 <3CADFCBB.E66B5A33@analog.com>
	 <3.0.6.32.20020409122616.007d7210@iekey221> <3.0.6.32.20020410085622.007d4460@iekey221>
Message-ID: <3CB3FAB1.5FADADBA@leox.org>

Several months ago, I succeeded in generating David's m68k-elf tools
under Solaris 2.6

The main trip you have to do first is to install a complete native GNU
toolchain + utils under your Solaris system. There are several
differences between Solaris and GNU utils (especially make, echo, sed
...etc).
Another point is to use bash when compiling GNU toolchain or Linux
kernel due to its good built-in commands (something like: make
SHELL=bash ...)

Hope this help.

Aran Benner wrote:
> 
> David,
> 
> >Use the uClibc.tar.gz file included with the sources.
> Actually, I did.
> 
> >Something is very worng with your patch here.  These patches should apply
> >cleanly.  What version of patch are you running ?
> I was running the Solaris version. But as I've also had problems with
> Solaris' make and tar, so I took your advice and installed gnu-patch 2.5.4
> 
> >Looks like binutils failed to build and run properly.
> Maybe more problems with the Solaris binutils?
> 
> >If you can it may also pay to run "bash" as you login shell.
> I do, but as the build-uclinux-tools.sh was a sh shell I figured it'd be
> best to run it from sh.
> 
> Anyway, using gnu-patch seems to have solved the patching problem, but I
> still get the make errors. My boss has decided we should try it on a Linux
> host, with the linux binutils, so I'm going to set up a Linux box today.
> 
> Thanks for your help.
> 
> Regards,
> 
> Aran

Best Regards
The LEOX team

http://www.leox.org : Free Hardware and Software Resources for
System-on-Chip
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From se04729 at salleURL.edu  Wed Apr 10 05:02:23 2002
From: se04729 at salleURL.edu (Francesc Borrell Ros)
Date: Wed, 10 Apr 2002 11:02:23 +0200 (CEST)
Subject: [uClinux-dev] about makefile, newbie question 
Message-ID: <Pine.LNX.4.44.0204101059280.28443-100000@cygnus.salleURL.edu>



	Hi all,

	I'm very new in linux and uClinux. I am trying to make a user
application based on serial channel working at 19200 bps, and I find the
code is going to slow for my needs. I'm using a MCF5272C3 dev board.

	In order to avoid going into kernel source, I feel a little
confused in all that code although I'm reading Alessandro Rubini's book, I
suspect that the executables I'm generating are too big for a embedded
system, because for a simple "hello world" program I'm getting an
executable of more than 18k. Perhaps that is slowing my system's
performance on listening and answering to the seria channel. The other
thing that makes the executable suspicious is that when the hello world
finishes I get a message like PID x, failed 256 (or anothe number).

	So the question is if someone could let me have a look to a simple
makefile, because I think that perhaps I'm linking to erroneous libraries
or something like that. May be without knowing it I'm linking to normal
linux libraries instead of the used for uClinux.

Thanks you all for your patience and for any answer

Best Regards

Francesc

PD: Thanks Greg for your last answer, i think i forgot giving thanks for
your support, and.. your patience!. :)



________________________________________________________________________
ColdFire Discussion List
See: <http://www.WildRice.com/ColdFire/>


This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From davidm at snapgear.com  Wed Apr 10 06:09:16 2002
From: davidm at snapgear.com (David McCullough)
Date: Wed, 10 Apr 2002 20:09:16 +1000
Subject: [uClinux-dev] Shared libraries
In-Reply-To: <02041016240501.01153@localhost.localdomain>; from tczhao@linpus.com.tw on Wed, Apr 10, 2002 at 04:24:05PM +0800
References: <200204100506.g3A56prk019420@skaro.internal.moreton.com.au> <02041016240501.01153@localhost.localdomain>
Message-ID: <20020410200915.A6836@beast.internal.moreton.com.au>


Jivin Zhao Tiecheng lays it down ...
> On Wednesday 10 April 2002 01:06 pm, you wrote:
> > Hi all,
> >
> > I posted a message about our shared library developments back on April 2nd.
> > This is now available as a technical bulletin on our site.  See:
> >
> >
> > 	http://www.snapgear.com/techbulletins.html
> > or
> > 	http://www.snapgear.com/tb20020409.html
> 
> 
> 
> 	In the page, it say "The shared library tools can be downloaded from 
> mid-April 2002 onwards from uClinux elf tools." but I cannot find the link at 
> all. Is it the m68k-elf-20020218 ?

No,  I am working on the tools release now,  I have a version ready to go
but am debating if I need to get the latest uClibc working with the build
process before release.

> > Our internal testing is progressing well albeit slowly.
> > DavidM is working on supporting other 68k platforms as I type this.

You should see some announcements on the list soon for new tools and a
new uClinux-dist that supports shared libraries on a number of m68k platforms,

Cheers,
Davidm

-- 
David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
davidm at snapgear.com  Fx: +61 7 3891 3630  825 Stanley St., W'gabba QLD 4102, Oz
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From davidm at snapgear.com  Wed Apr 10 06:17:35 2002
From: davidm at snapgear.com (David McCullough)
Date: Wed, 10 Apr 2002 20:17:35 +1000
Subject: [uClinux-dev] about makefile, newbie question
In-Reply-To: <Pine.LNX.4.44.0204101059280.28443-100000@cygnus.salleURL.edu>; from se04729@salleURL.edu on Wed, Apr 10, 2002 at 11:02:23AM +0200
References: <Pine.LNX.4.44.0204101059280.28443-100000@cygnus.salleURL.edu>
Message-ID: <20020410201735.B6836@beast.internal.moreton.com.au>


Jivin Francesc Borrell Ros lays it down ...
> 
> 
> 	Hi all,
> 
> 	I'm very new in linux and uClinux. I am trying to make a user
> application based on serial channel working at 19200 bps, and I find the
> code is going to slow for my needs. I'm using a MCF5272C3 dev board.
> 
> 	In order to avoid going into kernel source, I feel a little
> confused in all that code although I'm reading Alessandro Rubini's book, I
> suspect that the executables I'm generating are too big for a embedded
> system, because for a simple "hello world" program I'm getting an
> executable of more than 18k. Perhaps that is slowing my system's

Depending on how you wrote your hello world this size may be fine.
If it runs and prints hello world then I think it is fine.

> performance on listening and answering to the seria channel. The other

The size of the executable will not affect your performance on the serial
line.  The method you use to talk to the serial port will have a large
affect.  You may be best to outline how you are talking to the serial port,
or,  if your code isn't too large post it and get feedback.

> thing that makes the executable suspicious is that when the hello world
> finishes I get a message like PID x, failed 256 (or anothe number).

This happens if you do not exit with a status of 0.  Add and "exit(0)"
to the end of your main and it will get rid of that error.

> 	So the question is if someone could let me have a look to a simple
> makefile, because I think that perhaps I'm linking to erroneous libraries
> or something like that. May be without knowing it I'm linking to normal
> linux libraries instead of the used for uClinux.

Not a chance, the program wouldn't work if you were not getting the correct
libraries.

Cheers,
Davidm

-- 
David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
davidm at snapgear.com  Fx: +61 7 3891 3630  825 Stanley St., W'gabba QLD 4102, Oz
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From michiel.thuys at intersil.com  Wed Apr 10 07:23:39 2002
From: michiel.thuys at intersil.com (Thuys, Michiel)
Date: Wed, 10 Apr 2002 07:23:39 -0400
Subject: [uClinux-dev] Shared libraries
Message-ID: <716A7F62A194D41195AB001083FC3AE4B5E850@inlmx1.inl.intersil.com>

This surely sounds very interesting.

Is there any relation between this shared library implementation and the one that is done at Ridgerun for uClinux/ARM?

Michiel
> -----Original Message-----
> From: David McCullough [mailto:davidm at snapgear.com]
> Sent: woensdag 10 april 2002 12:09
> To: uclinux-dev at uclinux.org
> Subject: Re: [uClinux-dev] Shared libraries
> 
> 
> 
> Jivin Zhao Tiecheng lays it down ...
> > On Wednesday 10 April 2002 01:06 pm, you wrote:
> > > Hi all,
> > >
> > > I posted a message about our shared library developments 
> back on April 2nd.
> > > This is now available as a technical bulletin on our site.  See:
> > >
> > >
> > > 	http://www.snapgear.com/techbulletins.html
> > > or
> > > 	http://www.snapgear.com/tb20020409.html
> > 
> > 
> > 
> > 	In the page, it say "The shared library tools can be 
> downloaded from 
> > mid-April 2002 onwards from uClinux elf tools." but I 
> cannot find the link at 
> > all. Is it the m68k-elf-20020218 ?
> 
> No,  I am working on the tools release now,  I have a version 
> ready to go
> but am debating if I need to get the latest uClibc working 
> with the build
> process before release.
> 
> > > Our internal testing is progressing well albeit slowly.
> > > DavidM is working on supporting other 68k platforms as I 
> type this.
> 
> You should see some announcements on the list soon for new tools and a
> new uClinux-dist that supports shared libraries on a number 
> of m68k platforms,
> 
> Cheers,
> Davidm
> 
> -- 
> David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
> davidm at snapgear.com  Fx: +61 7 3891 3630  825 Stanley St., 
> W'gabba QLD 4102, Oz
> This message resent by the uclinux-dev at uclinux.org list 
> server http://www.uClinux.org/
> 
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From davidm at snapgear.com  Wed Apr 10 08:48:43 2002
From: davidm at snapgear.com (David McCullough)
Date: Wed, 10 Apr 2002 22:48:43 +1000
Subject: [uClinux-dev] Shared libraries
In-Reply-To: <716A7F62A194D41195AB001083FC3AE4B5E850@inlmx1.inl.intersil.com>; from michiel.thuys@intersil.com on Wed, Apr 10, 2002 at 07:23:39AM -0400
References: <716A7F62A194D41195AB001083FC3AE4B5E850@inlmx1.inl.intersil.com>
Message-ID: <20020410224843.A30173@beast.internal.moreton.com.au>


Jivin Thuys, Michiel lays it down ...
> This surely sounds very interesting.
> 
> Is there any relation between this shared library implementation and
> the one that is done at Ridgerun for uClinux/ARM?

They are actually quite different.  We were a fair way through our
version when we learnt about RidgeRun's efforts.  We swapped notes
but continued to finish ours as we were almost done :-)

I guess more choices can only be a good thing :-)

Cheers,
Davidm

-- 
David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
davidm at snapgear.com  Fx: +61 7 3891 3630  825 Stanley St., W'gabba QLD 4102, Oz
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From se04729 at salleURL.edu  Wed Apr 10 08:38:32 2002
From: se04729 at salleURL.edu (Francesc Borrell Ros)
Date: Wed, 10 Apr 2002 14:38:32 +0200 (CEST)
Subject: [uClinux-dev] about makefile, newbie question
In-Reply-To: <20020410201735.B6836@beast.internal.moreton.com.au>
Message-ID: <Pine.LNX.4.44.0204101414410.4691-100000@cygnus.salleURL.edu>

	Thanks for your quick answer Davidm,

	adding exit(0) to my code solved the error I use to have. But the
main trouble I'm having now is the serial channel. I have to deal with a
protocol at 19200. This protocol emulates token ring and I need to pass a
token at such speed. Reading the serial as a buffer is a bad election
because I should answer, passing the token, when I receive the last
character of the token. If I read from the serial buffer I always get more
than a token, so I'm never passing the token in the right way. I thought
that my code was to slow, but i'm only waiting for cahracters available on
the UART.

	I know this problem should be trivial to molst of you but I'm a
bit confused. Should I go inside the kernel to solve that? Do you see any
other valid solution?

	I post here the way i'm configuring the UART (may be the mistake
is here)

	int	Si_Init (unsigned char com, unsigned int nbauds, unsigned
char word, unsigned char par) {

	struct termios newtio;

	ScanParams(nbauds,word,par); // i got the bauds,word length and
					//parity
	MODEMDEVICE=valide_port_number (port_number -1); //tty/s1

	fd=open(MODEMDEVICE,O_RDWR | O_NDELAY | O_NOCTTY);

	if (fd<0) {perror(MODEMDEVICE); return fd;}

	tcgetattr(fd,&oldtio);
	tcgetattr(fd,&newtio);

	if (lset_baud_rate(fd,bauds,&newtio)) return fd; //setting the
						//baudrate
	lset_partiy(fd,pariti, &newtio);//setting the parity

	newtio.c_cc[VTIME] =0;
	newtio.c_cc[VMIN]=0;

	tcflush(fd,TCIOFLUSH);
	tcsetattr(fd,TCSANOW,&newtio);

	return (1);
}


	Then I follow the "select" technique to wait for incoming
characters in the serial device, the same you use in tip.

	I know that's a bit long but thank you all for reading it and for
answering if you have the clue.

	Thanks David :)



On Wed, 10 Apr 2002, David McCullough wrote:

> Date: Wed, 10 Apr 2002 20:17:35 +1000
> From: David McCullough <davidm at snapgear.com>
> Reply-To: uclinux-dev at uclinux.org
> To: uclinux-dev at uclinux.org
> Subject: Re: [uClinux-dev] about makefile, newbie question
>
>
> Jivin Francesc Borrell Ros lays it down ...
> >
> >
> > 	Hi all,
> >
> > 	I'm very new in linux and uClinux. I am trying to make a user
> > application based on serial channel working at 19200 bps, and I find the
> > code is going to slow for my needs. I'm using a MCF5272C3 dev board.
> >
> > 	In order to avoid going into kernel source, I feel a little
> > confused in all that code although I'm reading Alessandro Rubini's book, I
> > suspect that the executables I'm generating are too big for a embedded
> > system, because for a simple "hello world" program I'm getting an
> > executable of more than 18k. Perhaps that is slowing my system's
>
> Depending on how you wrote your hello world this size may be fine.
> If it runs and prints hello world then I think it is fine.
>
> > performance on listening and answering to the seria channel. The other
>
> The size of the executable will not affect your performance on the serial
> line.  The method you use to talk to the serial port will have a large
> affect.  You may be best to outline how you are talking to the serial port,
> or,  if your code isn't too large post it and get feedback.
>
> > thing that makes the executable suspicious is that when the hello world
> > finishes I get a message like PID x, failed 256 (or anothe number).
>
> This happens if you do not exit with a status of 0.  Add and "exit(0)"
> to the end of your main and it will get rid of that error.
>
> > 	So the question is if someone could let me have a look to a simple
> > makefile, because I think that perhaps I'm linking to erroneous libraries
> > or something like that. May be without knowing it I'm linking to normal
> > linux libraries instead of the used for uClinux.
>
> Not a chance, the program wouldn't work if you were not getting the correct
> libraries.
>
> Cheers,
> Davidm
>
> --
> David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
> davidm at snapgear.com  Fx: +61 7 3891 3630  825 Stanley St., W'gabba QLD 4102, Oz
> This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/
>

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From gmitsos at telecom.ntua.gr  Wed Apr 10 10:03:37 2002
From: gmitsos at telecom.ntua.gr (Yannis Mitsos)
Date: Wed, 10 Apr 2002 17:03:37 +0300
Subject: [uClinux-dev] mmap.c compilation fialure
Message-ID: <200204101703.37551.gmitsos@telecom.ntua.gr>

Hi, 

After retrieving a fresh copy from the uClinux repo, I tried to compile the 
files under the mmnommu directory. Having the flag -DDEBUG activated in the 
Makefile the compilation of the mmap.c failed in line 1216:
-----------------------------------
	tmp = current->mm->tblock; 
-----------------------------------
Shouldn't be replaced by something like :
-----------------------------------
	tmp = &current->mm->tblock; 
-----------------------------------

Yannis

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From moh.shiha at ieee.org  Wed Apr 10 10:03:30 2002
From: moh.shiha at ieee.org (Mohamed Ali Shiha)
Date: Wed, 10 Apr 2002 16:03:30 +0200
Subject: [uClinux-dev] MC68VZ328 and mobile phone interface
References: <OE109cXPoGStfUamI9D00026150@hotmail.com> <3CB20C64.C52E02D4@analog.com> <OE69ZKY1d66HcASHMZN00014342@hotmail.com> <3CB38102.736D1BAD@schoeldgen.de>
Message-ID: <OE77erOc0Ne0PaLI9mK00010ac5@hotmail.com>

Dear,

you are right ... I tried that with just a simple interface to stepper motor
for example .. it will be easy .. but I didn't try this method to send AT
commands to a connected modem .. I don't know if I need special library or
something like that ... especially, when you try to read or send SMS using a
program , I think that there is a GSM character set and you need to
translate ASCII to GSM character set ... these information I am not sure
with them .. so, I asked about that ...

Regards
Mohamed Shiha

----- Original Message -----
From: "Matthias Schoeldgen" <uclinux at schoeldgen.de>
To: <uclinux-dev at uclinux.org>
Sent: Wednesday, April 10, 2002 2:02 AM
Subject: Re: [uClinux-dev] MC68VZ328 and mobile phone interface


> Mohamed Ali Shiha wrote:
> >
> > did you compiled minicom for MC68VZ328 ... ?
> > I think if it is possible ... it will not add facility for developing a
> > program to send  and read sms from the attached mobile ...
> > Even, the board came without pppd and it is not included in the uClinux
> > source ... I think pppd is good to communicate with the board over a
network
> > but is there a command to send AT commands to the mobile using pppd ...
!!
> > .... Sorry coz I am so confused ...
> >
> > Regards
> > Mohamed Shiha
> > ----- Original Message -----
> > From: "Justin Wojdacki" <justin.wojdacki at analog.com>
> > To: <uclinux-dev at uclinux.org>
> > Sent: Monday, April 08, 2002 11:32 PM
> > Subject: Re: [uClinux-dev] MC68VZ328 and mobile phone interface
> >
> > > Mohamed Ali Shiha wrote:
> > > >
> > > > Dear all,
> > > >
> > > > I would like to access my mobile phone (siemens C35) using AT
commands
> > (the
> > > > phone is attached to ttyS0 to my MC68VZ328 development board) ...
how
> > can I
> > > > do that ... which daemons should I have and which software do I need
to
> > be
> > > > installed ..??
> > > >
> > > > Thanks and regards
> > > > Mohamed Shiha
> > > >
> > >
> > > Take a look at minicom, tip, or ppp(d). If you want to network over
> > > it, ppp(d) is probably your best bet. minicom or tip will work well if
> > > you just want to interact with it.
> > >
> > > --
> > > -------------------------------------------------
> > > Justin Wojdacki
> > > justin.wojdacki at analog.com         (408) 350-5032
> > > Communications Processors Group -- Analog Devices
> Hi there !
> The simplest way to send some bytes to your serial port imho is just to
> open the /dev/ttyS0 device from your program and then start writing,
> after setting the correct baudrate. And read from /dev/ttyS0 to get your
> replies. there you have the smallest terminal program in the world :-).
> Please correct me if I'm wrong.
>
> Greetings
> matthias
> This message resent by the uclinux-dev at uclinux.org list server
http://www.uClinux.org/
>
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From heiko.degenhardt at sentec-elektronik.de  Wed Apr 10 10:01:32 2002
From: heiko.degenhardt at sentec-elektronik.de (Heiko Degenhardt)
Date: Wed, 10 Apr 2002 16:01:32 +0200
Subject: [uClinux-dev] about makefile, newbie question
In-Reply-To: <Pine.LNX.4.44.0204101414410.4691-100000@cygnus.salleURL.edu>; from se04729@salleURL.edu on Wed, Apr 10, 2002 at 02:38:32PM +0200
References: <20020410201735.B6836@beast.internal.moreton.com.au> <Pine.LNX.4.44.0204101414410.4691-100000@cygnus.salleURL.edu>
Message-ID: <20020410160131.A386@www2.sentec-elektronik.de>

Hi Francesc, 

sorry, I think I can't help you that much, but:

* On Wed, Apr 10, 2002 at 02:38:32PM +0200, Francesc Borrell Ros wrote:
> token at such speed. Reading the serial as a buffer is a bad election
> because I should answer, passing the token, when I receive the last
> character of the token. If I read from the serial buffer I always get more
> than a token, so I'm never passing the token in the right way.

Does that mean that your communication partner sends more than
one token at a time (without waiting for your echo)?

> I thought that my code was to slow, but i'm only waiting for cahracters
> available on the UART.

Ok. End if there are characters available, you read them, construct
the token, and see if it is correct?

Can you validate that the other side sends the tokens in the
correct way?

I think your problem is a bit to complicated for me (esp. after
a hard working day ;)). But may be the 2 links below are 
of some help for you (esp. the Serial-HOWTO has some sections
about diagnosing and troubleshooting):

http://www.tldp.org/HOWTO/Serial-HOWTO.html 
http://www.tldp.org/HOWTO/Serial-Programming-HOWTO/index.html 

Rgds.
Heiko.

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From andersen at codepoet.org  Wed Apr 10 11:03:29 2002
From: andersen at codepoet.org (Erik Andersen)
Date: Wed, 10 Apr 2002 09:03:29 -0600
Subject: [uClinux-dev] uClibc 0.9.11 released
Message-ID: <20020410150329.GB21332@codepoet.org>

CodePoet Consulting is pleased to announce the immediate
availability of uClibc 0.9.11. This release is primarily focused
on fixing the issues that have turned up since the last release.
Several bugs in the gcc wrapper have been fixed, allowing
applications such as iproute2 and XFree86 to link properly.
Large file support has been improved, and a thread locking bug
was fixed that could cause s*printf calls to deadlock when
threading was enabled. Several bugs were also fixed with the
powerpc, h8300, m68k, sparc, and mips architecture support. Many
additional applications now compile and run perfectly, some of
which have been added to the working applications list.

To make things more interesting, a gcc-3.0.4 toolchain that
natively targets uClibc has also been released.  This brings with
it full C++ support for uClibc, including the libstdc++ library.
A gcc-2.95.x toolchain will be released shortly, but is not yet
ready. At this time, only source code and a Makefile for the
native uClibc toolchain are being released (i.e. no binaries,
sorry).  This toolchain is intended for systems with an MMU, and
has only been tested on x86 and ARM.  MMU-less systems should
continue to use the uclinux-elf-tools toolchains.

The uClibc 0.9.11 release can be obtained from:
    http://www.uclibc.org/downloads/uClibc-0.9.11.tar.bz2

The Changelog for this release is here:
    http://www.uclibc.org/downloads/Changelog
    http://www.uclibc.org/downloads/Changelog.full

The uClibc web site can be found at:
    http://www.uclibc.org/

The source code for the gcc-3.0.4/uClibc 0.9.11 toolchain can 
be obtained from:
    http://www.uclibc.org/downloads/toolchain/
Be aware that the toolchain source code is 27 MB.

 -Erik

--
Erik B. Andersen             http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From michael at michaelshiloh.com  Wed Apr 10 13:59:05 2002
From: michael at michaelshiloh.com (michael shiloh)
Date: Wed, 10 Apr 2002 10:59:05 -0700 (PDT)
Subject: [uClinux-dev] where can i find m68k-palmos-coff-gcc
In-Reply-To: <3CB378E7.9B3AF0F5@schoeldgen.de>
Message-ID: <Pine.LNX.4.33.0204101057440.4738-100000@magritte.magrittesystems.com>

Hi Matthias,

thanks for your suggestion, but i'm afraid i did not
see it at their site.  i did download

  Cross-Platform Compiler for RedHat 7.0, 7.1 and
                         Mandrake 8.0

but it did not have m68k-palmos-coff-gcc .

i will keep on looking and post here when i find it, 
in case it will help anyone else in the future.

michael


On Wed, 10 Apr 2002, Matthias Schoeldgen wrote:

> David McCullough wrote:
> > 
> > Jivin michael shiloh lays it down ...
> > > hello,
> > >
> > > dan trainor asked this in january, and i searched the
> > > archive but saw no answer. i'm trying to build an
> > > image for my palm5. my build fails at:
> > >
> > >   make[2]: Entering directory
> > >   `/opt/uClinux/uClinux-dist/vendors/3com/palm-loader'm68k-palmos-coff-gcc
> > >   -c -O2 -static    PalmLoader.c
> > >   make[2]: m68k-palmos-coff-gcc: Command not found
> > >
> > > does anyone know where i can find this program?
> > 
> > I found the copy I am using somehere on the web using google and following
> > my nose.  Have a look around and see how you go.  I don't seem to have the
> > original archive anymore,  but I could make one if you get desperate.
> > 
> > It's part of a gcc for palmos development,  it was not uClinux related in
> > any way,
> > 
> > Cheers,
> > Davidm
> Hello David and Jivin!
> Try the LinuxDA people, they used to provide the m68k-palmos toolchain
> on their website. 
> AFAIK the URL was http://www.linuxda.com
> Good luck!
> matthias
> This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/
> 

-- 

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From mark_mcchrystal at yahoo.com  Wed Apr 10 14:47:12 2002
From: mark_mcchrystal at yahoo.com (Mark McChrystal)
Date: Wed, 10 Apr 2002 11:47:12 -0700 (PDT)
Subject: [uClinux-dev] Kernel *328 debugging using 2.4.17 and elf
In-Reply-To: <D447D880267ED5118F2A00D0B74A108B11E352@munich-ex1.munich.akamai.com>
Message-ID: <20020410184712.27645.qmail@web14304.mail.yahoo.com>

Why do we need vectored exceptions for m68k-elf-gdb? 
I would like to update the kernel gdb support for
xcopilot and I'm not sure if I need to apply the
vector patch.  How did the previous m68k-coff-gdb work
without this support? 


Thanks,

Mark        

--- "Menie, Georges" <gmenie at akamai.com> wrote:
> here is the latest patch to allow debugging user
> apps on
> a 68328/68EZ328/68VZ328. I did remove the
> trap#2-trap#14
> entries overwrite, so that boards using this traps
> will
> not break. These traps are not used by the kernel
> anyway.
> 
> the patch is for the linux-2.4.x module in CVS.
> 
> Regards,
> Georges
> 
> > Index: arch/m68knommu/config.in
>
===================================================================
> RCS file:
> /var/cvs/uClinux-2.4.x/arch/m68knommu/config.in,v
> retrieving revision 1.23
> diff -a -c -r1.23 config.in
> *** arch/m68knommu/config.in	2002/03/07 14:18:44
> 1.23
> --- arch/m68knommu/config.in	2002/03/19 20:12:31
> ***************
> *** 85,90 ****
> --- 85,96 ----
>   
>   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
> Index: arch/m68knommu/platform/68328/entry.S
>
===================================================================
> RCS file:
>
/var/cvs/uClinux-2.4.x/arch/m68knommu/platform/68328/entry.S,v
> retrieving revision 1.3
> diff -a -c -r1.3 entry.S
> *** arch/m68knommu/platform/68328/entry.S	2001/07/07
> 17:03:51	1.3
> --- arch/m68knommu/platform/68328/entry.S	2002/03/19
> 20:12:31
> ***************
> *** 45,50 ****
> --- 45,55 ----
>   					moveb IMMED '\n',0xfffff907
>   
>   .globl SYMBOL_NAME(system_call),
> SYMBOL_NAME(buserr), SYMBOL_NAME(trap)
> + .globl SYMBOL_NAME(exception3),
> SYMBOL_NAME(exception4), SYMBOL_NAME(exception5)
> + .globl SYMBOL_NAME(exception6),
> SYMBOL_NAME(exception7), SYMBOL_NAME(exception8)
> + .globl SYMBOL_NAME(exception9),
> SYMBOL_NAME(exception10), SYMBOL_NAME(exception12)
> + .globl SYMBOL_NAME(exception14),
> SYMBOL_NAME(exception15)
> + .globl SYMBOL_NAME(trap1), SYMBOL_NAME(trap15)
>   .globl SYMBOL_NAME(resume),
> SYMBOL_NAME(ret_from_exception)
>   .globl SYMBOL_NAME(ret_from_signal)
>   .globl SYMBOL_NAME(sys_call_table)
> ***************
> *** 56,70 ****
>   
>   .text
>   ENTRY(buserr)
> ! 	SAVE_ALL_INT
>   	GET_CURRENT(%d0)
>   	movel	%sp,%sp at - 		/* stack frame pointer
> argument*/
>   	bsrw	SYMBOL_NAME(buserr_c)
>   	addql	#4,%sp
>   	jra	SYMBOL_NAME(ret_from_exception)
>   
> ! ENTRY(trap)
> ! 	SAVE_ALL_INT
>   	GET_CURRENT(%d0)
>   	movel	%sp,%sp at - 		/* stack frame pointer
> argument*/
>   	bsrw	SYMBOL_NAME(trap_c)
> --- 61,171 ----
>   
>   .text
>   ENTRY(buserr)
> ! 	SAVE_ALL_INT 8
>   	GET_CURRENT(%d0)
>   	movel	%sp,%sp at - 		/* stack frame pointer
> argument*/
>   	bsrw	SYMBOL_NAME(buserr_c)
>   	addql	#4,%sp
>   	jra	SYMBOL_NAME(ret_from_exception)
>   
> ! ENTRY(exception3)
> ! 	SAVE_ALL_INT 12
> ! 	GET_CURRENT(%d0)
> ! 	movel	%sp,%sp at - 		/* stack frame pointer
> argument*/
> ! 	bsrw	SYMBOL_NAME(trap_c)
> ! 	addql	#4,%sp
> ! 	jra	SYMBOL_NAME(ret_from_exception)
> ! 
> ! ENTRY(exception4)
> ! 	SAVE_ALL_INT 16
> ! 	GET_CURRENT(%d0)
> ! 	movel	%sp,%sp at - 		/* stack frame pointer
> argument*/
> ! 	bsrw	SYMBOL_NAME(trap_c)
> ! 	addql	#4,%sp
> ! 	jra	SYMBOL_NAME(ret_from_exception)
> ! 
> ! ENTRY(exception5)
> ! 	SAVE_ALL_INT 20
> ! 	GET_CURRENT(%d0)
> ! 	movel	%sp,%sp at - 		/* stack frame pointer
> argument*/
> ! 	bsrw	SYMBOL_NAME(trap_c)
> ! 	addql	#4,%sp
> ! 	jra	SYMBOL_NAME(ret_from_exception)
> ! 
> ! ENTRY(exception6)
> ! 	SAVE_ALL_INT 24
> ! 	GET_CURRENT(%d0)
> ! 	movel	%sp,%sp at - 		/* stack frame pointer
> argument*/
> ! 	bsrw	SYMBOL_NAME(trap_c)
> ! 	addql	#4,%sp
> ! 	jra	SYMBOL_NAME(ret_from_exception)
> ! 
> ! ENTRY(exception7)
> ! 	SAVE_ALL_INT 28
> ! 	GET_CURRENT(%d0)
> ! 	movel	%sp,%sp at - 		/* stack frame pointer
> argument*/
> ! 	bsrw	SYMBOL_NAME(trap_c)
> ! 	addql	#4,%sp
> ! 	jra	SYMBOL_NAME(ret_from_exception)
> ! 
> ! ENTRY(exception8)
> ! 	SAVE_ALL_INT 32
> ! 	GET_CURRENT(%d0)
> ! 	movel	%sp,%sp at - 		/* stack frame pointer
> argument*/
> ! 	bsrw	SYMBOL_NAME(trap_c)
> ! 	addql	#4,%sp
> ! 	jra	SYMBOL_NAME(ret_from_exception)
> ! 
> ! ENTRY(exception9)
> ! 	SAVE_ALL_INT 36
> ! 	GET_CURRENT(%d0)
> ! 	movel	%sp,%sp at - 		/* stack frame pointer
> argument*/
> ! 	bsrw	SYMBOL_NAME(trap_c)
> ! 	addql	#4,%sp
> ! 	jra	SYMBOL_NAME(ret_from_exception)
> ! 
> ! ENTRY(exception10)
> ! 	SAVE_ALL_INT 40
> ! 	GET_CURRENT(%d0)
> ! 	movel	%sp,%sp at - 		/* stack frame pointer
> argument*/
> ! 	bsrw	SYMBOL_NAME(trap_c)
> ! 	addql	#4,%sp
> ! 	jra	SYMBOL_NAME(ret_from_exception)
> ! 
> ! ENTRY(exception11)
> ! 	SAVE_ALL_INT 44
> ! 	GET_CURRENT(%d0)
> ! 	movel	%sp,%sp at - 		/* stack frame pointer
> argument*/
> ! 	bsrw	SYMBOL_NAME(trap_c)
> ! 	addql	#4,%sp
> ! 	jra	SYMBOL_NAME(ret_from_exception)
> ! 
> ! ENTRY(exception14)
> ! 	SAVE_ALL_INT 56
> ! 	GET_CURRENT(%d0)
> ! 	movel	%sp,%sp at - 		/* stack frame pointer
> argument*/
> ! 	bsrw	SYMBOL_NAME(trap_c)
> ! 	addql	#4,%sp
> ! 	jra	SYMBOL_NAME(ret_from_exception)
> ! 
> ! ENTRY(exception15)
> ! 	SAVE_ALL_INT 60
> ! 	GET_CURRENT(%d0)
> ! 	movel	%sp,%sp at - 		/* stack frame pointer
> argument*/
> ! 	bsrw	SYMBOL_NAME(trap_c)
> ! 	addql	#4,%sp
> ! 	jra	SYMBOL_NAME(ret_from_exception)
> ! 
> ! ENTRY(trap1)
> ! 	SAVE_ALL_INT 132
> ! 	GET_CURRENT(%d0)
> ! 	movel	%sp,%sp at - 		/* stack frame pointer
> argument*/
> ! 	bsrw	SYMBOL_NAME(trap_c)
> ! 	addql	#4,%sp
> ! 	jra	SYMBOL_NAME(ret_from_exception)
> ! 
> ! ENTRY(trap15)
> ! 	SAVE_ALL_INT 188
>   	GET_CURRENT(%d0)
>   	movel	%sp,%sp at - 		/* stack frame pointer
> argument*/
>   	bsrw	SYMBOL_NAME(trap_c)
> 
=== message truncated ===


__________________________________________________
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://taxes.yahoo.com/
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From gerg at snapgear.com  Wed Apr 10 20:00:32 2002
From: gerg at snapgear.com (Greg Ungerer)
Date: Thu, 11 Apr 2002 10:00:32 +1000
Subject: [uClinux-dev] mmap.c compilation fialure
References: <200204101703.37551.gmitsos@telecom.ntua.gr>
Message-ID: <3CB4D220.5000105@snapgear.com>

Hi Yannis,

Yannis Mitsos wrote:

> After retrieving a fresh copy from the uClinux repo, I tried to compile the 
> files under the mmnommu directory. Having the flag -DDEBUG activated in the 
> Makefile the compilation of the mmap.c failed in line 1216:
> -----------------------------------
> 	tmp = current->mm->tblock; 
> -----------------------------------
> Shouldn't be replaced by something like :
> -----------------------------------
> 	tmp = &current->mm->tblock; 
> -----------------------------------


Thanks, I have commited this change to the CVS.

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

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From davidm at snapgear.com  Wed Apr 10 20:33:20 2002
From: davidm at snapgear.com (David McCullough)
Date: Thu, 11 Apr 2002 10:33:20 +1000
Subject: [uClinux-dev] Kernel *328 debugging using 2.4.17 and elf
In-Reply-To: <20020410184712.27645.qmail@web14304.mail.yahoo.com>; from mark_mcchrystal@yahoo.com on Wed, Apr 10, 2002 at 11:47:12AM -0700
References: <D447D880267ED5118F2A00D0B74A108B11E352@munich-ex1.munich.akamai.com> <20020410184712.27645.qmail@web14304.mail.yahoo.com>
Message-ID: <20020411103320.B5818@beast.internal.moreton.com.au>


Jivin Mark McChrystal lays it down ...
> Why do we need vectored exceptions for m68k-elf-gdb? 
> I would like to update the kernel gdb support for
> xcopilot and I'm not sure if I need to apply the
> vector patch.  How did the previous m68k-coff-gdb work
> without this support? 

For kernel debugging,  the only support I am aware of that is needed is in
xcopilot,  XXXgdb must be able to connect to xcopilot to start/stop the
processor and return information on registers/memory etc.

I think there is a gdb-stub somewhere in xcopilot to do this.

No kernel changes are need to debug the kernel through xcopilot unless I am
way off track,

Cheers,
Davidm

-- 
David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
davidm at snapgear.com  Fx: +61 7 3891 3630  825 Stanley St., W'gabba QLD 4102, Oz
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From Fabrice_Gautier at sdesigns.com  Wed Apr 10 20:36:06 2002
From: Fabrice_Gautier at sdesigns.com (Fabrice Gautier)
Date: Wed, 10 Apr 2002 17:36:06 -0700
Subject: [uClinux-dev] ARM: personality
Message-ID: <B1F6452C89AFD411AE0800A0CC734C239DBBBD@EMAIL1>

Hi,

In linux/include/asm-armnommu/proc-armv/processor.h, in the
start_thread_function there is this bit of code:

if (current->personality & ADDR_LIMIT_32BIT)
	regs->ARM_cpsr = USR_MODE;
else
	regs->ARM_cpsr = USR26_MODE;

My problem is that, while i use a 32 bit cpu, personality is set to 0.

Does anybody where this personality is set in the first place?

Thanks



-- 
Fabrice Gautier, 
Fabrice_Gautier at sdesigns.com
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From SMerrifield at tecom.com.au  Wed Apr 10 20:46:40 2002
From: SMerrifield at tecom.com.au (Steven Merrifield)
Date: Thu, 11 Apr 2002 02:46:40 +0200
Subject: [uClinux-dev] ARM: personality
Message-ID: <7FF1185EA0D3D511BC0500B0D0D0C24A1B5A23@melexc01.ap.ilxi.net>

Hi,

What about linux/include/asm-armnommu/elf.h ?

steve


> -----Original Message-----
> From: Fabrice Gautier [mailto:Fabrice_Gautier at sdesigns.com]
> Sent: Thursday, 11 April 2002 10:36
> To: Uclinux-Dev (E-mail)
> Subject: [uClinux-dev] ARM: personality
> 
> 
> Hi,
> 
> In linux/include/asm-armnommu/proc-armv/processor.h, in the
> start_thread_function there is this bit of code:
> 
> if (current->personality & ADDR_LIMIT_32BIT)
> 	regs->ARM_cpsr = USR_MODE;
> else
> 	regs->ARM_cpsr = USR26_MODE;
> 
> My problem is that, while i use a 32 bit cpu, personality is set to 0.
> 
> Does anybody where this personality is set in the first place?
> 
> Thanks
> 
> 
> 
> -- 
> Fabrice Gautier, 
> Fabrice_Gautier at sdesigns.com
> This message resent by the uclinux-dev at uclinux.org list 
> server http://www.uClinux.org/
> 
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From miles at lsi.nec.co.jp  Wed Apr 10 21:08:44 2002
From: miles at lsi.nec.co.jp (Miles Bader)
Date: 11 Apr 2002 10:08:44 +0900
Subject: [uClinux-dev] Re: Shared libraries
In-Reply-To: <20020410224843.A30173@beast.internal.moreton.com.au>
References: <716A7F62A194D41195AB001083FC3AE4B5E850@inlmx1.inl.intersil.com>
	<20020410224843.A30173@beast.internal.moreton.com.au>
Message-ID: <buog0232g9v.fsf@mcspd15.ucom.lsi.nec.co.jp>

David McCullough <davidm at snapgear.com> writes:
> We swapped notes but continued to finish ours as we were almost done
> :-)

Can you give a brief description of the differences?

I want to add some shared library support for the v850, and presumably
should use one of these two implementations...

Thanks,

-Miles

-- 
Love is a snowmobile racing across the tundra.  Suddenly it flips over,
pinning you underneath.  At night the ice weasels come.  --Nietzsche
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From sheeliang at lit.org.sg  Wed Apr 10 22:27:39 2002
From: sheeliang at lit.org.sg (Chia Shee Liang)
Date: Thu, 11 Apr 2002 10:27:39 +0800
Subject: [uClinux-dev] Microwindows and uClinux?
Message-ID: <20020411102739.A1200@localhost.localdomain>

	Just wondering if anyone has any success with Microwindows, uClinux and
	ARM?

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From kpwee at sesl.global.sharp.co.jp  Thu Apr 11 02:27:24 2002
From: kpwee at sesl.global.sharp.co.jp (jipi)
Date: Thu, 11 Apr 2002 14:27:24 +0800
Subject: [uClinux-dev] Microwindows and uClinux?
References: <20020411102739.A1200@localhost.localdomain>
Message-ID: <3CB52CCC.4050300@sesl.global.sharp.co.jp>

yes.

Chia Shee Liang wrote:

> 	Just wondering if anyone has any success with Microwindows, uClinux and
> 	ARM?
> 
> This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/
> 
> 
> 



This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From se04729 at salleURL.edu  Thu Apr 11 02:29:32 2002
From: se04729 at salleURL.edu (Francesc Borrell Ros)
Date: Thu, 11 Apr 2002 08:29:32 +0200 (CEST)
Subject: [uClinux-dev] UARTs newbie question
Message-ID: <Pine.LNX.4.44.0204110812130.31208-100000@cygnus.salleURL.edu>

Hi Heiko, thanks for your help

	The main question I have is if I can program the UART to interrupt
my main program every time it receives a character. Have I always to work
with a buffer of more than a character? I read the serial how-to, (thanks
for the links), and the way I program the UART seems right. But perhaps
there is some configuration I'm missing to get interrupted every time I
receive a char from the serial channel.

	The buffer is ok, but, when does my program get interrupted?
What's the condition that leads the UART to finish buffering the input
and interrupting the program? I'm a bit confused on that point.

	Thanks for your help

	Best Regards

	Francesc

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From kj_lin at accton.com.tw  Thu Apr 11 04:00:15 2002
From: kj_lin at accton.com.tw (kj_lin at accton.com.tw)
Date: Thu, 11 Apr 2002 16:00:15 +0800
Subject: [uClinux-dev] Microwindows and uClinux?
Message-ID: <OF8C83E293.9D50B367-ON48256B98.002BCD86@accton.com.tw>


Yes, it had been done.
We had successfully ported uClinux + Microwin + Viewml on arm platform.







                                                                                                            
                                                                                                            
                      Chia Shee Liang           To:       uclinux-dev at uclinux.org                           
                      <sheeliang at lit.org        cc:                                                         
                      .sg>                      Subject:  [uClinux-dev] Microwindows and uClinux?           
                      Sent by:                                                                              
                      owner-uclinux-dev@                                                                    
                      uclinux.org                                                                           
                                                                                                            
                                                                                                            
                      2002/04/11 10:27                                                                      
                      AM                                                                                    
                      Please respond to                                                                     
                      uclinux-dev                                                                           
                                                                                                            
                                                                                                            






             Just wondering if anyone has any success with Microwindows,
uClinux and
             ARM?

This message resent by the uclinux-dev at uclinux.org list server
http://www.uClinux.org/


This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From gmenie at akamai.com  Thu Apr 11 04:50:41 2002
From: gmenie at akamai.com (Menie, Georges)
Date: Thu, 11 Apr 2002 04:50:41 -0400
Subject: [uClinux-dev] Kernel *328 debugging using 2.4.17 and elf
Message-ID: <D447D880267ED5118F2A00D0B74A108B11E3C8@munich-ex1.munich.akamai.com>

You will need this vectored exception only to debug user app,
if you did use before some tools to debug the kernel with
xcopilot, you don't need this patch.

Regards,
Georges

> -----Original Message-----
> From: Mark McChrystal [mailto:mark_mcchrystal at yahoo.com]
> Sent: mercredi 10 avril 2002 20:47
> To: uclinux-dev at uclinux.org
> Subject: [uClinux-dev] Kernel *328 debugging using 2.4.17 and elf
> 
> 
> Why do we need vectored exceptions for m68k-elf-gdb? 
> I would like to update the kernel gdb support for
> xcopilot and I'm not sure if I need to apply the
> vector patch.  How did the previous m68k-coff-gdb work
> without this support? 
> 
> 
> Thanks,
> 
> Mark        
> 
> --- "Menie, Georges" <gmenie at akamai.com> wrote:
> > here is the latest patch to allow debugging user
> > apps on
> > a 68328/68EZ328/68VZ328. I did remove the
> > trap#2-trap#14
> > entries overwrite, so that boards using this traps
> > will
> > not break. These traps are not used by the kernel
> > anyway.
> > 
> > the patch is for the linux-2.4.x module in CVS.
> > 
> > Regards,
> > Georges
> > 
> > > Index: arch/m68knommu/config.in
> >
> ===================================================================
> > RCS file:
> > /var/cvs/uClinux-2.4.x/arch/m68knommu/config.in,v
> > retrieving revision 1.23
> > diff -a -c -r1.23 config.in
> > *** arch/m68knommu/config.in	2002/03/07 14:18:44
> > 1.23
> > --- arch/m68knommu/config.in	2002/03/19 20:12:31
> > ***************
> > *** 85,90 ****
> > --- 85,96 ----
> >   
> >   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
> > Index: arch/m68knommu/platform/68328/entry.S
> >
> ===================================================================
> > RCS file:
> >
> /var/cvs/uClinux-2.4.x/arch/m68knommu/platform/68328/entry.S,v
> > retrieving revision 1.3
> > diff -a -c -r1.3 entry.S
> > *** arch/m68knommu/platform/68328/entry.S	2001/07/07
> > 17:03:51	1.3
> > --- arch/m68knommu/platform/68328/entry.S	2002/03/19
> > 20:12:31
> > ***************
> > *** 45,50 ****
> > --- 45,55 ----
> >   					moveb IMMED '\n',0xfffff907
> >   
> >   .globl SYMBOL_NAME(system_call),
> > SYMBOL_NAME(buserr), SYMBOL_NAME(trap)
> > + .globl SYMBOL_NAME(exception3),
> > SYMBOL_NAME(exception4), SYMBOL_NAME(exception5)
> > + .globl SYMBOL_NAME(exception6),
> > SYMBOL_NAME(exception7), SYMBOL_NAME(exception8)
> > + .globl SYMBOL_NAME(exception9),
> > SYMBOL_NAME(exception10), SYMBOL_NAME(exception12)
> > + .globl SYMBOL_NAME(exception14),
> > SYMBOL_NAME(exception15)
> > + .globl SYMBOL_NAME(trap1), SYMBOL_NAME(trap15)
> >   .globl SYMBOL_NAME(resume),
> > SYMBOL_NAME(ret_from_exception)
> >   .globl SYMBOL_NAME(ret_from_signal)
> >   .globl SYMBOL_NAME(sys_call_table)
> > ***************
> > *** 56,70 ****
> >   
> >   .text
> >   ENTRY(buserr)
> > ! 	SAVE_ALL_INT
> >   	GET_CURRENT(%d0)
> >   	movel	%sp,%sp at - 		/* stack frame pointer
> > argument*/
> >   	bsrw	SYMBOL_NAME(buserr_c)
> >   	addql	#4,%sp
> >   	jra	SYMBOL_NAME(ret_from_exception)
> >   
> > ! ENTRY(trap)
> > ! 	SAVE_ALL_INT
> >   	GET_CURRENT(%d0)
> >   	movel	%sp,%sp at - 		/* stack frame pointer
> > argument*/
> >   	bsrw	SYMBOL_NAME(trap_c)
> > --- 61,171 ----
> >   
> >   .text
> >   ENTRY(buserr)
> > ! 	SAVE_ALL_INT 8
> >   	GET_CURRENT(%d0)
> >   	movel	%sp,%sp at - 		/* stack frame pointer
> > argument*/
> >   	bsrw	SYMBOL_NAME(buserr_c)
> >   	addql	#4,%sp
> >   	jra	SYMBOL_NAME(ret_from_exception)
> >   
> > ! ENTRY(exception3)
> > ! 	SAVE_ALL_INT 12
> > ! 	GET_CURRENT(%d0)
> > ! 	movel	%sp,%sp at - 		/* stack frame pointer
> > argument*/
> > ! 	bsrw	SYMBOL_NAME(trap_c)
> > ! 	addql	#4,%sp
> > ! 	jra	SYMBOL_NAME(ret_from_exception)
> > ! 
> > ! ENTRY(exception4)
> > ! 	SAVE_ALL_INT 16
> > ! 	GET_CURRENT(%d0)
> > ! 	movel	%sp,%sp at - 		/* stack frame pointer
> > argument*/
> > ! 	bsrw	SYMBOL_NAME(trap_c)
> > ! 	addql	#4,%sp
> > ! 	jra	SYMBOL_NAME(ret_from_exception)
> > ! 
> > ! ENTRY(exception5)
> > ! 	SAVE_ALL_INT 20
> > ! 	GET_CURRENT(%d0)
> > ! 	movel	%sp,%sp at - 		/* stack frame pointer
> > argument*/
> > ! 	bsrw	SYMBOL_NAME(trap_c)
> > ! 	addql	#4,%sp
> > ! 	jra	SYMBOL_NAME(ret_from_exception)
> > ! 
> > ! ENTRY(exception6)
> > ! 	SAVE_ALL_INT 24
> > ! 	GET_CURRENT(%d0)
> > ! 	movel	%sp,%sp at - 		/* stack frame pointer
> > argument*/
> > ! 	bsrw	SYMBOL_NAME(trap_c)
> > ! 	addql	#4,%sp
> > ! 	jra	SYMBOL_NAME(ret_from_exception)
> > ! 
> > ! ENTRY(exception7)
> > ! 	SAVE_ALL_INT 28
> > ! 	GET_CURRENT(%d0)
> > ! 	movel	%sp,%sp at - 		/* stack frame pointer
> > argument*/
> > ! 	bsrw	SYMBOL_NAME(trap_c)
> > ! 	addql	#4,%sp
> > ! 	jra	SYMBOL_NAME(ret_from_exception)
> > ! 
> > ! ENTRY(exception8)
> > ! 	SAVE_ALL_INT 32
> > ! 	GET_CURRENT(%d0)
> > ! 	movel	%sp,%sp at - 		/* stack frame pointer
> > argument*/
> > ! 	bsrw	SYMBOL_NAME(trap_c)
> > ! 	addql	#4,%sp
> > ! 	jra	SYMBOL_NAME(ret_from_exception)
> > ! 
> > ! ENTRY(exception9)
> > ! 	SAVE_ALL_INT 36
> > ! 	GET_CURRENT(%d0)
> > ! 	movel	%sp,%sp at - 		/* stack frame pointer
> > argument*/
> > ! 	bsrw	SYMBOL_NAME(trap_c)
> > ! 	addql	#4,%sp
> > ! 	jra	SYMBOL_NAME(ret_from_exception)
> > ! 
> > ! ENTRY(exception10)
> > ! 	SAVE_ALL_INT 40
> > ! 	GET_CURRENT(%d0)
> > ! 	movel	%sp,%sp at - 		/* stack frame pointer
> > argument*/
> > ! 	bsrw	SYMBOL_NAME(trap_c)
> > ! 	addql	#4,%sp
> > ! 	jra	SYMBOL_NAME(ret_from_exception)
> > ! 
> > ! ENTRY(exception11)
> > ! 	SAVE_ALL_INT 44
> > ! 	GET_CURRENT(%d0)
> > ! 	movel	%sp,%sp at - 		/* stack frame pointer
> > argument*/
> > ! 	bsrw	SYMBOL_NAME(trap_c)
> > ! 	addql	#4,%sp
> > ! 	jra	SYMBOL_NAME(ret_from_exception)
> > ! 
> > ! ENTRY(exception14)
> > ! 	SAVE_ALL_INT 56
> > ! 	GET_CURRENT(%d0)
> > ! 	movel	%sp,%sp at - 		/* stack frame pointer
> > argument*/
> > ! 	bsrw	SYMBOL_NAME(trap_c)
> > ! 	addql	#4,%sp
> > ! 	jra	SYMBOL_NAME(ret_from_exception)
> > ! 
> > ! ENTRY(exception15)
> > ! 	SAVE_ALL_INT 60
> > ! 	GET_CURRENT(%d0)
> > ! 	movel	%sp,%sp at - 		/* stack frame pointer
> > argument*/
> > ! 	bsrw	SYMBOL_NAME(trap_c)
> > ! 	addql	#4,%sp
> > ! 	jra	SYMBOL_NAME(ret_from_exception)
> > ! 
> > ! ENTRY(trap1)
> > ! 	SAVE_ALL_INT 132
> > ! 	GET_CURRENT(%d0)
> > ! 	movel	%sp,%sp at - 		/* stack frame pointer
> > argument*/
> > ! 	bsrw	SYMBOL_NAME(trap_c)
> > ! 	addql	#4,%sp
> > ! 	jra	SYMBOL_NAME(ret_from_exception)
> > ! 
> > ! ENTRY(trap15)
> > ! 	SAVE_ALL_INT 188
> >   	GET_CURRENT(%d0)
> >   	movel	%sp,%sp at - 		/* stack frame pointer
> > argument*/
> >   	bsrw	SYMBOL_NAME(trap_c)
> > 
> === message truncated ===
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Tax Center - online filing with TurboTax
> http://taxes.yahoo.com/
> This message resent by the uclinux-dev at uclinux.org list 
> server http://www.uClinux.org/
> 
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From sheeliang at lit.org.sg  Thu Apr 11 05:24:55 2002
From: sheeliang at lit.org.sg (Chia Shee Liang)
Date: Thu, 11 Apr 2002 17:24:55 +0800
Subject: [uClinux-dev] Microwindows and uClinux?
In-Reply-To: <3CB52CCC.4050300@sesl.global.sharp.co.jp>; from kpwee@sesl.global.sharp.co.jp on Thu, Apr 11, 2002 at 02:27:24PM +0800
References: <20020411102739.A1200@localhost.localdomain> <3CB52CCC.4050300@sesl.global.sharp.co.jp>
Message-ID: <20020411172455.A1029@localhost.localdomain>

How's the compatibility issues? Can usual X programs run wifout change? Stuff
like window manager? Speed?

On Thu, Apr 11, 2002 at 02:27:24PM +0800, jipi wrote:
> yes.
> 
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From heiko.degenhardt at sentec-elektronik.de  Thu Apr 11 07:31:06 2002
From: heiko.degenhardt at sentec-elektronik.de (Heiko Degenhardt)
Date: Thu, 11 Apr 2002 13:31:06 +0200
Subject: [uClinux-dev] UARTs newbie question
In-Reply-To: <Pine.LNX.4.44.0204110812130.31208-100000@cygnus.salleURL.edu>; from se04729@salleURL.edu on Thu, Apr 11, 2002 at 08:29:32AM +0200
References: <Pine.LNX.4.44.0204110812130.31208-100000@cygnus.salleURL.edu>
Message-ID: <20020411133106.A3759@www2.sentec-elektronik.de>

Hi Francesc, 

* On Thu, Apr 11, 2002 at 08:29:32AM +0200, Francesc Borrell Ros wrote:
> 	The buffer is ok, but, when does my program get interrupted?
> What's the condition that leads the UART to finish buffering the input
> and interrupting the program?

Currently I've not worked with interrupt driven approaches for 
communication. I use some kind of "polling" (as they for instance
do in tip.c). If I understand "man 2 select" correctly, select looks
in a set of file descriptors if there was changed something. If so,
you have to look if the descriptor you are interested in was
changed, and if it was, you can read the chars. That's what I do
in the main loop. I think that polling aproach should work for you,
too, if you poll often enaugh to read the chars in time.

As I understand it, for an interrupt driven solution you need a
kernel driver. I've not used that way, so I can't help. May be
you can have a look in some serial drivers that are included in
the kernel source, or find some hints in the following links:
http://www.tldp.org/LDP/lpg/
http://www.tldp.org/LDP/lki/
http://www.tldp.org/LDP/lkmpg/

Rgds.
Heiko.

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From se04729 at salleURL.edu  Thu Apr 11 10:08:22 2002
From: se04729 at salleURL.edu (Francesc Borrell Ros)
Date: Thu, 11 Apr 2002 16:08:22 +0200 (CEST)
Subject: [uClinux-dev] UARTs newbie question
In-Reply-To: <20020411133106.A3759@www2.sentec-elektronik.de>
Message-ID: <Pine.LNX.4.44.0204111604390.28113-100000@cygnus.salleURL.edu>

Thanks for all Heiko,

	I'll take a look on the links and on the mcfserial again, and I'll
take it easy too.. :) Thanks for your interest, perhaps select is the
fastest choice and I'm afraid I will finish using it. ;)

	Best regards

On Thu, 11 Apr 2002, Heiko Degenhardt wrote:

> Date: Thu, 11 Apr 2002 13:31:06 +0200
> From: Heiko Degenhardt <heiko.degenhardt at sentec-elektronik.de>
> Reply-To: uclinux-dev at uclinux.org
> To: uclinux-dev at uclinux.org
> Subject: Re: [uClinux-dev] UARTs newbie question
>
> Hi Francesc,
>
> * On Thu, Apr 11, 2002 at 08:29:32AM +0200, Francesc Borrell Ros wrote:
> > 	The buffer is ok, but, when does my program get interrupted?
> > What's the condition that leads the UART to finish buffering the input
> > and interrupting the program?
>
> Currently I've not worked with interrupt driven approaches for
> communication. I use some kind of "polling" (as they for instance
> do in tip.c). If I understand "man 2 select" correctly, select looks
> in a set of file descriptors if there was changed something. If so,
> you have to look if the descriptor you are interested in was
> changed, and if it was, you can read the chars. That's what I do
> in the main loop. I think that polling aproach should work for you,
> too, if you poll often enaugh to read the chars in time.
>
> As I understand it, for an interrupt driven solution you need a
> kernel driver. I've not used that way, so I can't help. May be
> you can have a look in some serial drivers that are included in
> the kernel source, or find some hints in the following links:
> http://www.tldp.org/LDP/lpg/
> http://www.tldp.org/LDP/lki/
> http://www.tldp.org/LDP/lkmpg/
>
> Rgds.
> Heiko.
>
> This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/
>

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From ilatypov at superbt.com  Thu Apr 11 12:51:29 2002
From: ilatypov at superbt.com (Ilguiz Latypov)
Date: Thu, 11 Apr 2002 12:51:29 -0400 (EDT)
Subject: [uClinux-dev] .data size > 64 KiB on m68knommmu
Message-ID: <Pine.LNX.4.44.0204111250490.18683-100000@server.superbt.com>


Dear All,

I've encountered a problem with starting an application whose .data
segment size exceeds 64 KiB.  My platform is m68knommu.  I imported the
uClinux kernel off the uclinux.org CVS repository on March 19, 2002.  The
cross-compiler tools are David McCullough's m68k-elf-tools dated February
2002.

One of the glib test applications includes large Unicode translation 
tables.  Here is what I get when running that application:

==================================================================== 
# /root/testgdate 
BINFMT_FLAT: reloc outside program 0xfff4b7ce (0 - 0x50058), killing!
BINFMT_FLAT: reloc outside program 0xfff4b7ce (0 - 0x50058), killing!
SIGSEGV
# 
==================================================================== 

Does anybody know if I should look into the kernel's binfmt_flat.c module
which generated the error message or the error occurred due to
inconsistent binary data generated by m68k-elf-tools?  Any other hint?

Thank you,

Ilguiz

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From Fabrice_Gautier at sdesigns.com  Thu Apr 11 17:47:57 2002
From: Fabrice_Gautier at sdesigns.com (Fabrice Gautier)
Date: Thu, 11 Apr 2002 14:47:57 -0700
Subject: [uClinux-dev] ARM: personality
Message-ID: <B1F6452C89AFD411AE0800A0CC734C239DBBC2@EMAIL1>

Well, 

I dont see any code in this file that set the personality.

And anyway, im not loading elf file, im loading flat binaries, so im not
sure there's a relation between this elf.h and the flat loader. There is
indeed in the elf loader a piece of code that set the personality
accordingly to some flags in the elf file, but in the case of flat binaries,
im not sure there is any information in the file.

-- 
Fabrice Gautier, 
Fabrice_Gautier at sdesigns.com


> -----Original Message-----
> From: Steven Merrifield [mailto:SMerrifield at tecom.com.au]
> Sent: Wednesday, April 10, 2002 5:47 PM
> To: uclinux-dev at uclinux.org
> Subject: RE: [uClinux-dev] ARM: personality
> 
> 
> Hi,
> 
> What about linux/include/asm-armnommu/elf.h ?
> 
> steve
> 
> 
> > -----Original Message-----
> > From: Fabrice Gautier [mailto:Fabrice_Gautier at sdesigns.com]
> > Sent: Thursday, 11 April 2002 10:36
> > To: Uclinux-Dev (E-mail)
> > Subject: [uClinux-dev] ARM: personality
> > 
> > 
> > Hi,
> > 
> > In linux/include/asm-armnommu/proc-armv/processor.h, in the
> > start_thread_function there is this bit of code:
> > 
> > if (current->personality & ADDR_LIMIT_32BIT)
> > 	regs->ARM_cpsr = USR_MODE;
> > else
> > 	regs->ARM_cpsr = USR26_MODE;
> > 
> > My problem is that, while i use a 32 bit cpu, personality 
> is set to 0.
> > 
> > Does anybody where this personality is set in the first place?
> > 
> > Thanks
> > 
> > 
> > 
> > -- 
> > Fabrice Gautier, 
> > Fabrice_Gautier at sdesigns.com
> > This message resent by the uclinux-dev at uclinux.org list 
> > server http://www.uClinux.org/
> > 
> This message resent by the uclinux-dev at uclinux.org list 
> server http://www.uClinux.org/
> 
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From Fabrice_Gautier at sdesigns.com  Thu Apr 11 18:29:26 2002
From: Fabrice_Gautier at sdesigns.com (Fabrice Gautier)
Date: Thu, 11 Apr 2002 15:29:26 -0700
Subject: [uClinux-dev] Microwindows and uClinux?
Message-ID: <B1F6452C89AFD411AE0800A0CC734C239DBBC3@EMAIL1>


Viewml also? That's great....

I think viewml require a thread library, which one did you use ?

Thanks

-- 
Fabrice Gautier, 
Fabrice_Gautier at sdesigns.com


> -----Original Message-----
> From: kj_lin at accton.com.tw [mailto:kj_lin at accton.com.tw]
> Sent: Thursday, April 11, 2002 1:00 AM
> To: uclinux-dev at uclinux.org
> Subject: Re: [uClinux-dev] Microwindows and uClinux?
> 
> 
> 
> Yes, it had been done.
> We had successfully ported uClinux + Microwin + Viewml on arm 
> platform.
> 
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From eauth at softsys.co.at  Thu Apr 11 19:11:03 2002
From: eauth at softsys.co.at (Erwin Authried)
Date: Fri, 12 Apr 2002 01:11:03 +0200
Subject: [uClinux-dev] ARM: personality
In-Reply-To: <B1F6452C89AFD411AE0800A0CC734C239DBBC2@EMAIL1>
Message-ID: <CBEPKHHODMBKHCMLAGBMGELMCBAA.eauth@softsys.co.at>

In binfmt_flat.c, in function load_flat_binary(), set_personality(PER_LINUX)
is called. PER_LINUX is equal to 0. I have not verified this, but that would
mean that the mode in cpsr register would be set to the illegal value (0) on
32-bit cpus. I'm wondering how the code is working at all.

-Erwin

> -----Urspr?ngliche Nachricht-----
> Von: owner-uclinux-dev at uclinux.org
> [mailto:owner-uclinux-dev at uclinux.org]Im Auftrag von Fabrice Gautier
> Gesendet: Donnerstag, 11. April 2002 23:48
> An: 'uclinux-dev at uclinux.org'
> Betreff: RE: [uClinux-dev] ARM: personality
>
>
> Well,
>
> I dont see any code in this file that set the personality.
>
> And anyway, im not loading elf file, im loading flat binaries, so im not
> sure there's a relation between this elf.h and the flat loader. There is
> indeed in the elf loader a piece of code that set the personality
> accordingly to some flags in the elf file, but in the case of
> flat binaries,
> im not sure there is any information in the file.

>
> --
> Fabrice Gautier,
> Fabrice_Gautier at sdesigns.com
>
>
> > -----Original Message-----
> > From: Steven Merrifield [mailto:SMerrifield at tecom.com.au]
> > Sent: Wednesday, April 10, 2002 5:47 PM
> > To: uclinux-dev at uclinux.org
> > Subject: RE: [uClinux-dev] ARM: personality
> >
> >
> > Hi,
> >
> > What about linux/include/asm-armnommu/elf.h ?
> >
> > steve
> >
> >
> > > -----Original Message-----
> > > From: Fabrice Gautier [mailto:Fabrice_Gautier at sdesigns.com]
> > > Sent: Thursday, 11 April 2002 10:36
> > > To: Uclinux-Dev (E-mail)
> > > Subject: [uClinux-dev] ARM: personality
> > >
> > >
> > > Hi,
> > >
> > > In linux/include/asm-armnommu/proc-armv/processor.h, in the
> > > start_thread_function there is this bit of code:
> > >
> > > if (current->personality & ADDR_LIMIT_32BIT)
> > > 	regs->ARM_cpsr = USR_MODE;
> > > else
> > > 	regs->ARM_cpsr = USR26_MODE;
> > >
> > > My problem is that, while i use a 32 bit cpu, personality
> > is set to 0.
> > >
> > > Does anybody where this personality is set in the first place?
> > >
> > > Thanks
> > >
> > >
> > >
> > > --
> > > Fabrice Gautier,
> > > Fabrice_Gautier at sdesigns.com
> > > This message resent by the uclinux-dev at uclinux.org list
> > > server http://www.uClinux.org/
> > >
> > This message resent by the uclinux-dev at uclinux.org list
> > server http://www.uClinux.org/
> >
> This message resent by the uclinux-dev at uclinux.org list server
> http://www.uClinux.org/
>
>


This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From gerg at snapgear.com  Thu Apr 11 19:35:06 2002
From: gerg at snapgear.com (Greg Ungerer)
Date: Fri, 12 Apr 2002 09:35:06 +1000
Subject: [uClinux-dev] UARTs newbie question
References: <Pine.LNX.4.44.0204110812130.31208-100000@cygnus.salleURL.edu>
Message-ID: <3CB61DAA.2020700@snapgear.com>


Hi Francesc,

Francesc Borrell Ros wrote:

> 	The main question I have is if I can program the UART to interrupt
> my main program every time it receives a character. Have I always to work
> with a buffer of more than a character?


Maybe I am missing something, but if you only want one character
at a time, then why don't you just read 1 char at a time.
You don't have to read any more if you don't want too...

     char c;
     read(fd, &c, 1);


> I read the serial how-to, (thanks
> for the links), and the way I program the UART seems right. But perhaps
> there is some configuration I'm missing to get interrupted every time I
> receive a char from the serial channel.


There is no interrupt within the context of you application.
Interrupts are all handled by the kernel, that is its job.


> 	The buffer is ok, but, when does my program get interrupted?
> What's the condition that leads the UART to finish buffering the input
> and interrupting the program? I'm a bit confused on that point.


The UART driver won't "interrupt" your program. You program is
free to read the UART driver chars whenever it wants. If you
need to wait on a number of events then you need to use the "select"
system call.

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

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From gerg at snapgear.com  Thu Apr 11 21:02:56 2002
From: gerg at snapgear.com (Greg Ungerer)
Date: Fri, 12 Apr 2002 11:02:56 +1000
Subject: [uClinux-dev] new distribution source snapshot
Message-ID: <3CB63240.7000006@snapgear.com>


Hi All,

I have just put a new uClinux distribution source snapshot
on www.uclinux.org. You can find it at:

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

As usual lots of new things. A few new target boards supported,
covering a pretty good range of CPU's: m68k/ColdFire, ARM,
SPARC, NEC v850 and i960. A total of 39 different boards/targets
supported "out-of-the-box".

The code changes for shared libraries (at least on m68k/coldfire)
are in. But you need the new about-to-be-released tool chain
before you can make use of it.

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

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From kj_lin at accton.com.tw  Thu Apr 11 21:18:10 2002
From: kj_lin at accton.com.tw (kj_lin at accton.com.tw)
Date: Fri, 12 Apr 2002 09:18:10 +0800
Subject: [uClinux-dev] Microwindows and uClinux?
Message-ID: <OFA760392F.7694A199-ON48256B99.0006393C@accton.com.tw>


Actually we had ported viewml on ARM and MIPS platform.
We built everything of viewml based on uClibc-0.99.

Of cource, include pthread library.

There are no special issue on porting viewml to ARM.

However, it is much more difficult to port it to MIPS.



KJ





                                                                                                             
                                                                                                             
                      Fabrice Gautier            To:       "'uclinux-dev at uclinux.org'"                       
                      <Fabrice_Gautier at sd         <uclinux-dev at uclinux.org>                                  
                      esigns.com>                cc:                                                         
                      Sent by:                   Subject:  RE: [uClinux-dev] Microwindows and uClinux?       
                      owner-uclinux-dev at u                                                                    
                      clinux.org                                                                             
                                                                                                             
                                                                                                             
                      2002/04/12 06:29 AM                                                                    
                      Please respond to                                                                      
                      uclinux-dev                                                                            
                                                                                                             
                                                                                                             







Viewml also? That's great....

I think viewml require a thread library, which one did you use ?

Thanks

--
Fabrice Gautier,
Fabrice_Gautier at sdesigns.com


> -----Original Message-----
> From: kj_lin at accton.com.tw [mailto:kj_lin at accton.com.tw]
> Sent: Thursday, April 11, 2002 1:00 AM
> To: uclinux-dev at uclinux.org
> Subject: Re: [uClinux-dev] Microwindows and uClinux?
>
>
>
> Yes, it had been done.
> We had successfully ported uClinux + Microwin + Viewml on arm
> platform.
>
This message resent by the uclinux-dev at uclinux.org list server
http://www.uClinux.org/


This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From davidm at snapgear.com  Thu Apr 11 21:55:25 2002
From: davidm at snapgear.com (David McCullough)
Date: Fri, 12 Apr 2002 11:55:25 +1000
Subject: [uClinux-dev] Updated uClinux tools 20020410
Message-ID: <20020412115525.A6547@beast.internal.moreton.com.au>


Hi all,

I have put up the latest uClinux-elf-tools at:

	http://www.uclinux.org/pub/uClinux/uclinux-elf-tools/

This update supports the flat format shared libraries in the latest
uClinux distribution and fixes a few minor things.

There are some notes on the page listing the changes, no update for the ARM
guys at this point,

Cheers,
Davidm

-- 
David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
davidm at snapgear.com  Fx: +61 7 3891 3630  825 Stanley St., W'gabba QLD 4102, Oz
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From andersen at codepoet.org  Thu Apr 11 21:44:49 2002
From: andersen at codepoet.org (Erik Andersen)
Date: Thu, 11 Apr 2002 19:44:49 -0600
Subject: [uClinux-dev] Microwindows and uClinux?
In-Reply-To: <OFA760392F.7694A199-ON48256B99.0006393C@accton.com.tw>
References: <OFA760392F.7694A199-ON48256B99.0006393C@accton.com.tw>
Message-ID: <20020412014449.GA14685@codepoet.org>

On Fri Apr 12, 2002 at 09:18:10AM +0800, kj_lin at accton.com.tw wrote:
> 
> Actually we had ported viewml on ARM and MIPS platform.
> We built everything of viewml based on uClibc-0.99.

Where do I find that version of uClibc?

 -Erik

--
Erik B. Andersen             http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From Fabrice_Gautier at sdesigns.com  Thu Apr 11 22:44:33 2002
From: Fabrice_Gautier at sdesigns.com (Fabrice Gautier)
Date: Thu, 11 Apr 2002 19:44:33 -0700
Subject: [uClinux-dev] UARTs newbie question
Message-ID: <B1F6452C89AFD411AE0800A0CC734C239DBBC4@EMAIL1>


Im not sure i understand your question but:

- In the kernel, the low-level drivers usually receive an interrupt when
there is at least one character in the UART Fifo, some UART can be setup to
trigger an interrupt only when a the FIFO is x% full or on a timeout.

- The data is then bufferised by the kernel tty layer.

- In your program you either wait for a character blocking on a wait
(synchronous) OR (i think that'sthis part youre looking for), or you can use
async notification (But only if the device driver support it, and i dont
know if they do, probably they do)

Follwing extract taken from http://www.xml.com/ldd/chapter/book/ch05.html :

*-*-*-*-*
For example, the following lines of code in a user program enable
asynchronous notification to the current process for the stdin input file: 

signal(SIGIO, &input_handler); /* dummy sample; sigaction() is better */
fcntl(STDIN_FILENO, F_SETOWN, getpid());
oflags = fcntl(STDIN_FILENO, F_GETFL);
fcntl(STDIN_FILENO, F_SETFL, oflags | FASYNC);
-*-*-*-*-

Have fun,

-- 
Fabrice Gautier, 
Fabrice_Gautier at sdesigns.com


> -----Original Message-----
> From: Francesc Borrell Ros [mailto:se04729 at salleURL.edu]
> Sent: Wednesday, April 10, 2002 11:30 PM
> To: uclinux-dev at uclinux.org
> Subject: [uClinux-dev] UARTs newbie question
> 
> 
> Hi Heiko, thanks for your help
> 
> 	The main question I have is if I can program the UART 
> to interrupt
> my main program every time it receives a character. Have I 
> always to work
> with a buffer of more than a character? I read the serial 
> how-to, (thanks
> for the links), and the way I program the UART seems right. 
> But perhaps
> there is some configuration I'm missing to get interrupted 
> every time I
> receive a char from the serial channel.
> 
> 	The buffer is ok, but, when does my program get interrupted?
> What's the condition that leads the UART to finish buffering the input
> and interrupting the program? I'm a bit confused on that point.
> 
> 	Thanks for your help
> 
> 	Best Regards
> 
> 	Francesc
> 
> This message resent by the uclinux-dev at uclinux.org list 
> server http://www.uClinux.org/
> 
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From valera at soling.ur.ru  Fri Apr 12 01:00:43 2002
From: valera at soling.ur.ru (Valera)
Date: Fri, 12 Apr 2002 10:00:43 +0500
Subject: [uClinux-dev] offtop question
References: <B1F6452C89AFD411AE0800A0CC734C239DBBC4@EMAIL1>
Message-ID: <000901c1e1df$000d1ae0$dd00a8c0@valera>

Hi,
i have one question: which IDE editor is used for uClinux coding? And which
operation system is used?

Valery
RUSSIA

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From kj_lin at accton.com.tw  Fri Apr 12 01:14:19 2002
From: kj_lin at accton.com.tw (kj_lin at accton.com.tw)
Date: Fri, 12 Apr 2002 13:14:19 +0800
Subject: [uClinux-dev] Microwindows and uClinux?
Message-ID: <OF382071FC.8C949635-ON48256B99.001C8E06@accton.com.tw>


Sorry, it is uClibc-0.9.9 instead of uClibc-0.99.


KJ





                                                                                                            
                                                                                                            
                      Erik Andersen             To:       kj_lin at accton.com.tw                              
                      <andersen at codepoet        cc:       uclinux-dev at uclinux.org                           
                      .org>                     Subject:  Re: [uClinux-dev] Microwindows and uClinux?       
                      Sent by:                                                                              
                      owner-uclinux-dev@                                                                    
                      uclinux.org                                                                           
                                                                                                            
                                                                                                            
                      2002/04/12 09:44                                                                      
                      AM                                                                                    
                      Please respond to                                                                     
                      uclinux-dev                                                                           
                                                                                                            
                                                                                                            






On Fri Apr 12, 2002 at 09:18:10AM +0800, kj_lin at accton.com.tw wrote:
>
> Actually we had ported viewml on ARM and MIPS platform.
> We built everything of viewml based on uClibc-0.99.

Where do I find that version of uClibc?

 -Erik

--
Erik B. Andersen             http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--
This message resent by the uclinux-dev at uclinux.org list server
http://www.uClinux.org/


This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From xcwang at linpus.com.tw  Fri Apr 12 01:18:35 2002
From: xcwang at linpus.com.tw (wxc[lnpus])
Date: Fri, 12 Apr 2002 13:18:35 +0800
Subject: [uClinux-dev] ERRO of fprintf
Message-ID: <BIELJFKODCCCDMMNAPOPAEDNCAAA.xcwang@linpus.com.tw>

Hi all:
	I'm encountered in a problem when I call the glibc function
"fprintf(stderr,"%d\n",erro)"(int erro = 1) , and when I replaced this
function by printf("%d\n",erro) , it run in gear. For I am a newhand of
Linux ,I fill very puzzualed.Is there something wrong related to the use of
heap ?or something else , or how can I debug it (I can not know how to debug
the glibc function) ;



			thanks!

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From se04729 at salleURL.edu  Fri Apr 12 02:11:19 2002
From: se04729 at salleURL.edu (Francesc Borrell Ros)
Date: Fri, 12 Apr 2002 08:11:19 +0200 (CEST)
Subject: [uClinux-dev] UARTs newbie question
In-Reply-To: <B1F6452C89AFD411AE0800A0CC734C239DBBC4@EMAIL1>
Message-ID: <Pine.LNX.4.44.0204120807210.23013-100000@cygnus.salleURL.edu>

Thanks for all your answers,

	By now I'll use selct function and see if it's performance is good
in our system, if not, I'll try other dangerous things.. ;) Thanks for
all.

	Best Regards

	Francesc

	Visca el Barca!!


On Thu, 11 Apr 2002, Fabrice Gautier wrote:

> Date: Thu, 11 Apr 2002 19:44:33 -0700
> From: Fabrice Gautier <Fabrice_Gautier at sdesigns.com>
> Reply-To: uclinux-dev at uclinux.org
> To: "'uclinux-dev at uclinux.org'" <uclinux-dev at uclinux.org>
> Subject: RE: [uClinux-dev] UARTs newbie question
>
>
> Im not sure i understand your question but:
>
> - In the kernel, the low-level drivers usually receive an interrupt when
> there is at least one character in the UART Fifo, some UART can be setup to
> trigger an interrupt only when a the FIFO is x% full or on a timeout.
>
> - The data is then bufferised by the kernel tty layer.
>
> - In your program you either wait for a character blocking on a wait
> (synchronous) OR (i think that'sthis part youre looking for), or you can use
> async notification (But only if the device driver support it, and i dont
> know if they do, probably they do)
>
> Follwing extract taken from http://www.xml.com/ldd/chapter/book/ch05.html :
>
> *-*-*-*-*
> For example, the following lines of code in a user program enable
> asynchronous notification to the current process for the stdin input file:
>
> signal(SIGIO, &input_handler); /* dummy sample; sigaction() is better */
> fcntl(STDIN_FILENO, F_SETOWN, getpid());
> oflags = fcntl(STDIN_FILENO, F_GETFL);
> fcntl(STDIN_FILENO, F_SETFL, oflags | FASYNC);
> -*-*-*-*-
>
> Have fun,
>
> --
> Fabrice Gautier,
> Fabrice_Gautier at sdesigns.com
>
>
> > -----Original Message-----
> > From: Francesc Borrell Ros [mailto:se04729 at salleURL.edu]
> > Sent: Wednesday, April 10, 2002 11:30 PM
> > To: uclinux-dev at uclinux.org
> > Subject: [uClinux-dev] UARTs newbie question
> >
> >
> > Hi Heiko, thanks for your help
> >
> > 	The main question I have is if I can program the UART
> > to interrupt
> > my main program every time it receives a character. Have I
> > always to work
> > with a buffer of more than a character? I read the serial
> > how-to, (thanks
> > for the links), and the way I program the UART seems right.
> > But perhaps
> > there is some configuration I'm missing to get interrupted
> > every time I
> > receive a char from the serial channel.
> >
> > 	The buffer is ok, but, when does my program get interrupted?
> > What's the condition that leads the UART to finish buffering the input
> > and interrupting the program? I'm a bit confused on that point.
> >
> > 	Thanks for your help
> >
> > 	Best Regards
> >
> > 	Francesc
> >
> > This message resent by the uclinux-dev at uclinux.org list
> > server http://www.uClinux.org/
> >
> This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/
>

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From stefan.jonsson at faltcom.se  Fri Apr 12 03:26:33 2002
From: stefan.jonsson at faltcom.se (Stefan Jonsson)
Date: Fri, 12 Apr 2002 09:26:33 +0200
Subject: [uClinux-dev] EB40+MEC, programming flash.
Message-ID: <NGBBJKACILMHGKHMEHHLKEJKCAAA.stefan.jonsson@faltcom.se>

Hello list,

I want to program the MEC 1604-flash. I have never done this before, so I
need to ask some questions. I am "modifying" the bootloader from atmels
at91-library. I want to build in a flash-programmer in the bootloader. The
bootloader is (and will be when it's finished) in "upper mem". I used the
/at91/tools/ ... /flash_1024.axf with the ARM Sdt v2.50 to put it there. So
I wonder how I should program the MEC's flash? What to use? I am using
serial connection only.

Has anyone maybe already done something like this?
(boot on ARM and flash routines to program flash via serial communication)

Just a confirmation about whether this is the way to go or not, suggestions
or help is most appreciated.

Thanks!

Best regards,
Stefan Jonsson,
Student, University of Ume?, Sweden.

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From eauth at softsys.co.at  Fri Apr 12 03:57:02 2002
From: eauth at softsys.co.at (Erwin Authried)
Date: Fri, 12 Apr 2002 09:57:02 +0200
Subject: [uClinux-dev] strange relocation problem with ARM toolchain
Message-ID: <CBEPKHHODMBKHCMLAGBMCELNCBAA.eauth@softsys.co.at>

I have compiled a rather large package with the ARM toolchain (gcc-2.95.3
with Michiel Thuy's patch, latest elf2flt from cvs). When the flat binary is
loaded, there are several error msgs from the flat loader:

BINFMT_FLAT: reloc outside program 0x1000000 (0 - 0x29bef4), killing!
BINFMT_FLAT: reloc outside program 0x33323130 (0 - 0x29bef4), killing!
BINFMT_FLAT: reloc outside program 0x37363534 (0 - 0x29bef4), killing!
BINFMT_FLAT: reloc outside program 0x42413938 (0 - 0x29bef4), killing!
...

After some investigation, I figured out that all entries in the relocation
table are obviously offset by 12 Bytes. When I subtract 12 from each of the
reloc entries in the table, the relocations are ok. The source is compiled
as usual, with
	-msingle-pic-base -fPIC -Wl,-elf2flt

The flat header:
    Magic:        bFLT
    Rev:          4
    Entry:        0x50
    Data Start:   0x32620
    Data End:     0x404d0
    BSS End:      0x416ac
    Stack Size:   0x1000
    Reloc Start:  0x404d0
    Reloc Count:  0x112
    Flags:        0x2 ( Has-PIC-GOT )

The strange thing is that my other applications that are compiled with this
toolchain run without any problem. Any ideas?

-Erwin


This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From petero at cvs.com.au  Fri Apr 12 04:02:44 2002
From: petero at cvs.com.au (Peter Ogilvy)
Date: Fri, 12 Apr 2002 18:02:44 +1000
Subject: [uClinux-dev] Newbie problem with kernal build
Message-ID: <5.1.0.14.1.20020412163659.00a97920@localhost>

Hi All,

I'm trying to build uClinux on a Mandrake 8.0 distro
for a Motorola 5272 reference board. The aim is just to
get the tool chain working. Next week I should be
getting a snap gear card to play with, so the target
is not critical at this stage.

I'm following the instructions at;

http://www.uclinux.org/ports/coldfire/source.html

I've started in my home directory

/home/peter

I've unzipped the toolchain; m68k-elf-tools-20020218.tar.gz

I've unzipped the source; uClinux-dist-20020306.tar.gz

I follow the instructions

cd uClinux-dist

make xconfig

The only change I make is to select the M5272C3 target

I then

make dep

and get the attached messages and errors.

It appears to me that it can't find the /include directory, I
asume should be under
/home/peter/uClinux-dist/linux-2.4.x/arch/m68knommu/kernel
but at this point I'm quite out of my depth as to what to
do to fix it, if this indeed this is the case.

Could anyone give me a clue ? :-)

Peter

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: error.txt
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20020412/55e8fbb4/attachment.txt>

From mathias.fritzson at mecel.se  Fri Apr 12 04:32:31 2002
From: mathias.fritzson at mecel.se (mathias.fritzson at mecel.se)
Date: Fri, 12 Apr 2002 10:32:31 +0200
Subject: [uClinux-dev] Compiling under Cygwin
Message-ID: <200204120831.g3C8Vve08046@uclinuxuclinux.org>

Hi

Well we came far but not all the way..

Paul B. posted a file called cygfixes.zip a while ago, I got that one =)
and it was very helpful. But there are still a few issues I dont know if
you guys have had those or if anyone has solved them:
* the command "Wl,-elf2flt" doesn't work it calls ld with the flag -e and
lf2flt is interpreted as an entrypoint
* the command "touch" doesn't create the devices in the Vendors Makefile
* the script "romfs-inst.sh" isn't supported since the $OPTIND call doesn't
work either..

We have a couple of choices here as I see it, either to set up a new linux
box or to get a VMware/linux working properly.

Has anyone of you guys succeded to get a VMware/linux box to work with a
windondows network? We need to get samba working.. Or do you know where to
ask ??

Thanks

/Mathias



This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From shiyas at globaledgesoft.com  Fri Apr 12 04:28:04 2002
From: shiyas at globaledgesoft.com (shiaz)
Date: Fri, 12 Apr 2002 13:58:04 +0530
Subject: [uClinux-dev] Endianness
Message-ID: <02041213580400.03122@shiaz>

Hi 
I have a doubt
My Samsung 44box is  currently configured for bigendian.
The image what i get is little endian.
I understood that i need to add the option for gcc -mbig-endian.
Now in which all makefile do i have to insert this option o produce big 
endian.
Regards
shiaz


This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From julienb at actimage.fr  Fri Apr 12 05:20:18 2002
From: julienb at actimage.fr (Julien Boibessot)
Date: Fri, 12 Apr 2002 11:20:18 +0200
Subject: [uClinux-dev] Newbie problem with kernal build
References: <5.1.0.14.1.20020412163659.00a97920@localhost>
Message-ID: <037201c1e203$4352e590$8947ec95@bruker.fr>

Hi !

Have you decompress your bintools archive in root ("/") directory ??

----- Original Message ----- 
From: "Peter Ogilvy" <petero at cvs.com.au>
To: <uclinux-dev at uclinux.org>
Sent: Friday, April 12, 2002 10:02 AM
Subject: [uClinux-dev] Newbie problem with kernal build


> Hi All,
> 
> I'm trying to build uClinux on a Mandrake 8.0 distro
> for a Motorola 5272 reference board. The aim is just to
> get the tool chain working. Next week I should be
> getting a snap gear card to play with, so the target
> is not critical at this stage.
> 
> I'm following the instructions at;
> 
> http://www.uclinux.org/ports/coldfire/source.html
> 
> I've started in my home directory
> 
> /home/peter
> 
> I've unzipped the toolchain; m68k-elf-tools-20020218.tar.gz
> 
> I've unzipped the source; uClinux-dist-20020306.tar.gz
> 
> I follow the instructions
> 
> cd uClinux-dist
> 
> make xconfig
> 
> The only change I make is to select the M5272C3 target
> 
> I then
> 
> make dep
> 
> and get the attached messages and errors.
> 
> It appears to me that it can't find the /include directory, I
> asume should be under
> /home/peter/uClinux-dist/linux-2.4.x/arch/m68knommu/kernel
> but at this point I'm quite out of my depth as to what to
> do to fix it, if this indeed this is the case.
> 
> Could anyone give me a clue ? :-)
> 
> Peter
> 
> 

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From aran at iekey.nl  Fri Apr 12 05:40:00 2002
From: aran at iekey.nl (Aran Benner)
Date: Fri, 12 Apr 2002 11:40:00 +0200
Subject: [uClinux-dev] Newbie problem with kernal build
In-Reply-To: <5.1.0.14.1.20020412163659.00a97920@localhost>
Message-ID: <3.0.6.32.20020412114000.007d7c10@iekey221>

Hi,

I just had the same problem.
You should check your path, see if /usr/local/bin is included

to check:
# echo $PATH

to add (temporarily)
# PATH=$PATH:/usr/local/bin


Though I'm pretty new to this too, so anyone correct me if I'm wrong

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From michiel.thuys at intersil.com  Fri Apr 12 05:50:02 2002
From: michiel.thuys at intersil.com (Thuys, Michiel)
Date: Fri, 12 Apr 2002 05:50:02 -0400
Subject: [uClinux-dev] strange relocation problem with ARM toolchain
Message-ID: <716A7F62A194D41195AB001083FC3AE4B5E863@inlmx1.inl.intersil.com>

Hi Erwin,

The only suspicious thing I see is that your BSS ends at (0x416ac) where I would expect this to be aligned to a 16 byte boundary. Maybe you should check your linker scripts. Sorry, not much help but maybe a point into the right direction ;)

Michiel

> -----Original Message-----
> From: Erwin Authried [mailto:eauth at softsys.co.at]
> Sent: vrijdag 12 april 2002 9:57
> To: uclinux-dev at uclinux.org
> Subject: [uClinux-dev] strange relocation problem with ARM toolchain
> 
> 
> I have compiled a rather large package with the ARM toolchain 
> (gcc-2.95.3
> with Michiel Thuy's patch, latest elf2flt from cvs). When the 
> flat binary is
> loaded, there are several error msgs from the flat loader:
> 
> BINFMT_FLAT: reloc outside program 0x1000000 (0 - 0x29bef4), killing!
> BINFMT_FLAT: reloc outside program 0x33323130 (0 - 0x29bef4), killing!
> BINFMT_FLAT: reloc outside program 0x37363534 (0 - 0x29bef4), killing!
> BINFMT_FLAT: reloc outside program 0x42413938 (0 - 0x29bef4), killing!
> ...
> 
> After some investigation, I figured out that all entries in 
> the relocation
> table are obviously offset by 12 Bytes. When I subtract 12 
> from each of the
> reloc entries in the table, the relocations are ok. The 
> source is compiled
> as usual, with
> 	-msingle-pic-base -fPIC -Wl,-elf2flt
> 
> The flat header:
>     Magic:        bFLT
>     Rev:          4
>     Entry:        0x50
>     Data Start:   0x32620
>     Data End:     0x404d0
>     BSS End:      0x416ac
>     Stack Size:   0x1000
>     Reloc Start:  0x404d0
>     Reloc Count:  0x112
>     Flags:        0x2 ( Has-PIC-GOT )
> 
> The strange thing is that my other applications that are 
> compiled with this
> toolchain run without any problem. Any ideas?
> 
> -Erwin
> 
> 
> This message resent by the uclinux-dev at uclinux.org list 
> server http://www.uClinux.org/
> 
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From eauth at softsys.co.at  Fri Apr 12 07:55:02 2002
From: eauth at softsys.co.at (Erwin Authried)
Date: Fri, 12 Apr 2002 13:55:02 +0200
Subject: [uClinux-dev] strange relocation problem with ARM toolchain
In-Reply-To: <716A7F62A194D41195AB001083FC3AE4B5E863@inlmx1.inl.intersil.com>
Message-ID: <CBEPKHHODMBKHCMLAGBMKEMACBAA.eauth@softsys.co.at>

Thanks for the hint. I believe this is not the problem, but I have
recognized one other thing that looks very suspicious:

The elf2flt log shows the following warning:

TEXT -> vma=0 len=28ab0
        lma=0 clen=28ab0 oo=0 ap=4 fp=8000
DATA -> vma=28ac0 len=cdd0
        lma=28ac0 clen=cdd0 oo=0 ap=5 fp=30ac0
WARNING: data=28ac0 does not directly follow text=28ab0
BSS  -> vma=35890 len=10cc
        lma=35890 clen=10cc oo=0 ap=4 fp=3d890

objdump -h a.out.gdb shows the following output:
Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         00028ab0  00000000  00000000  00008000  2**4
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .data         0000cdd0  00028ac0  00028ac0  00030ac0  2**5
                  CONTENTS, ALLOC, LOAD, DATA
  2 .bss          000010cc  00035890  00035890  0003d890  2**4
                  ALLOC
...

The .text size is 28ab0, and the .data section starts at 28ac0. Obviously,
this gap is caused by the alignment of the .data section (2**5).

In all other *.gdb files that I have, there is no gap, and the alignment of
.data is 2**2.
The (unmodified) elf2flt.ld file shows  ". = ALIGN(0x4) ;" at the beginning
of the data section.
I have tried to change the line before _etext=. to ALIGN(0x20), instead of
0x10, without luck. The warning doesn't appear, and there is no gap between
.text and .data, but the resulting flat file is identical to the previous
version.

Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         00028ac0  00000000  00000000  00008000  2**4
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .data         0000cdd0  00028ac0  00028ac0  00030ac0  2**5
                  CONTENTS, ALLOC, LOAD, DATA

-Erwin

> -----Urspr?ngliche Nachricht-----
> Von: owner-uclinux-dev at uclinux.org
> [mailto:owner-uclinux-dev at uclinux.org]Im Auftrag von Thuys, Michiel
> Gesendet: Freitag, 12. April 2002 11:50
> An: uclinux-dev at uclinux.org
> Betreff: RE: [uClinux-dev] strange relocation problem with ARM toolchain
>
>
> Hi Erwin,
>
> The only suspicious thing I see is that your BSS ends at
> (0x416ac) where I would expect this to be aligned to a 16 byte
> boundary. Maybe you should check your linker scripts. Sorry, not
> much help but maybe a point into the right direction ;)
>
> Michiel
>
> > -----Original Message-----
> > From: Erwin Authried [mailto:eauth at softsys.co.at]
> > Sent: vrijdag 12 april 2002 9:57
> > To: uclinux-dev at uclinux.org
> > Subject: [uClinux-dev] strange relocation problem with ARM toolchain
> >
> >
> > I have compiled a rather large package with the ARM toolchain
> > (gcc-2.95.3
> > with Michiel Thuy's patch, latest elf2flt from cvs). When the
> > flat binary is
> > loaded, there are several error msgs from the flat loader:
> >
> > BINFMT_FLAT: reloc outside program 0x1000000 (0 - 0x29bef4), killing!
> > BINFMT_FLAT: reloc outside program 0x33323130 (0 - 0x29bef4), killing!
> > BINFMT_FLAT: reloc outside program 0x37363534 (0 - 0x29bef4), killing!
> > BINFMT_FLAT: reloc outside program 0x42413938 (0 - 0x29bef4), killing!
> > ...
> >
> > After some investigation, I figured out that all entries in
> > the relocation
> > table are obviously offset by 12 Bytes. When I subtract 12
> > from each of the
> > reloc entries in the table, the relocations are ok. The
> > source is compiled
> > as usual, with
> > 	-msingle-pic-base -fPIC -Wl,-elf2flt
> >
> > The flat header:
> >     Magic:        bFLT
> >     Rev:          4
> >     Entry:        0x50
> >     Data Start:   0x32620
> >     Data End:     0x404d0
> >     BSS End:      0x416ac
> >     Stack Size:   0x1000
> >     Reloc Start:  0x404d0
> >     Reloc Count:  0x112
> >     Flags:        0x2 ( Has-PIC-GOT )
> >
> > The strange thing is that my other applications that are
> > compiled with this
> > toolchain run without any problem. Any ideas?
> >
> > -Erwin
> >
> >
> > This message resent by the uclinux-dev at uclinux.org list
> > server http://www.uClinux.org/
> >
> This message resent by the uclinux-dev at uclinux.org list server
http://www.uClinux.org/



This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From stefan.jonsson at faltcom.se  Fri Apr 12 08:12:37 2002
From: stefan.jonsson at faltcom.se (Stefan Jonsson)
Date: Fri, 12 Apr 2002 14:12:37 +0200
Subject: [uClinux-dev] How to make "jumps" in flash area?
Message-ID: <NGBBJKACILMHGKHMEHHLMEJMCAAA.stefan.jonsson@faltcom.se>

Hello list,

I am using ARM Sdt v2.50 to try to make a bootloader (starting from the one
in the at91-library). I want to make a jump from the EB40 on-board flash to
the MEC. But first I tried to jump to another address in the same flash. It
doesn't seem to work for me though. I have (if nothing went wrong)
programmed the bootloader at 0x01010000 (the start of "upper mem", and that
boots perfectly ok so far), and the "led_blink.bin" (from atmels
example-projects) to 0x01011000 and it seemed to work since I got no errors
and the bootloader is still there also.

So, the problem ...

I don't know how to make a jump from 1 program to another. I simply tried:

return (0x01011000);

... in the end of my bootloader and hoped that it would start my led_blink
(as it did not). So, can any one tell me how it is done? (The linker says
the "entry point" is cstartup.o and "area" is reset, in the led_blink.prj,
does it matter? I can not just simply change to led_blink.o either. Do every
program need a cstartup if the bootloader already have done that?) Why I
want to do this is because when I know how it is done I want to jump from my
bootloader to MEC where I will place the uClinux.

I appreciate your help.

Regards,
Stefan Jonsson,
Student, University of Ume?, Sweden.

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From fmore at netceler.com  Fri Apr 12 08:25:45 2002
From: fmore at netceler.com (Fabien)
Date: Fri, 12 Apr 2002 14:25:45 +0200
Subject: [uClinux-dev] newbie : uClinux tools installation
References: <Pine.LNX.4.44.0204120807210.23013-100000@cygnus.salleURL.edu>
Message-ID: <3CB6D249.7010908@netceler.com>

Hi,

	I'm new in uClinux, I'm french, then ascuse me in avance for the anglish mistakes.
I used the uCdimm ColdFire 5275 whith the uCevolution dev bord. My linux distribution is a Debian 2.2.

	I am trying to make a user application that make a led blink. 

	I don't know if the toolchain is correctly installed. I have installed the toolchain in /usr/local and copy the reference distribution to /opt/uClinux. I have unpacked the distribution into /opt/uClinux/uClinux-coldfire/ with the command buildenv. I hav
e run (in /opt/uClinux/uClinux-colfire/) 'make xconfig', 'make dep' and 'make'. Then, the file /opt/uClinux/uClinux-colfire/lib/libc/include/linuc/autoconf.h contains the good configuration for my processor and dev bord.

	Now I write my programm blink.c in /opt/uClinux/uClinux-coldfire/test/. In this directory, I try to compile it with the command m68k-elf-gcc -c blink.c -o blink.o

	I think, the problem is that the include and lib files that it used are in /usr/local/m68k-elf/sys-include/ (that files aren't configured for my dev bord). How can i change the configuration of m68k-elf-gcc for used the good include and lib files?

This is the error when i try to compile:
*************************
blink.c: In function 'main':
blink.c:14: 'MCFSIM_PCDAT' undeclared (first use in this function)
*************************



Thanks you all for any answer

Best Regards

Fabien


this is my blink.c programm:
*********************************************

#include <unistd.h>
#include <asm/coldfire.h>
#include <asm/mcfsim.h>



int main(int argc, char *argv[]){
        int i = 0;
        int j = 0;
        unsigned char a = 1;
        volatile unsigned short *PCDATA = 
        	(volatile unsigned short *)(MCF_MBAR + MCFSIM_PCDAT);
        
        *(volatile unsigned short *)(MCF_MBAR + MCFSIM_PCDAT) = 0xFF00;
        
        while(1){
                usleep(500);
                if(j == 0){
                        i++;
                        if(i >= 7 ) j = 1;
                        a <<= 1;
                }
                else{
                        i--;
                        if(i <= 0) j = 0;
                        a >>= 1;
                }
                *PCDATA = (unsigned short)(~a) << 8;
                usleep(500);
        }
        
        
}

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From davidm at snapgear.com  Fri Apr 12 08:43:07 2002
From: davidm at snapgear.com (David McCullough)
Date: Fri, 12 Apr 2002 22:43:07 +1000
Subject: [uClinux-dev] Compiling under Cygwin
In-Reply-To: <200204120831.g3C8Vve08046@uclinuxuclinux.org>; from mathias.fritzson@mecel.se on Fri, Apr 12, 2002 at 10:32:31AM +0200
References: <200204120831.g3C8Vve08046@uclinuxuclinux.org>
Message-ID: <20020412224307.B14241@beast.internal.moreton.com.au>


Jivin mathias.fritzson at mecel.se lays it down ...
> Hi
> 
> Well we came far but not all the way..
> 
> Paul B. posted a file called cygfixes.zip a while ago, I got that one =)
> and it was very helpful. But there are still a few issues I dont know if
> you guys have had those or if anyone has solved them:
> * the command "Wl,-elf2flt" doesn't work it calls ld with the flag -e and
> lf2flt is interpreted as an entrypoint

You need to replace the linker "ld" with the ld-elf2flt script,  probably with
modifications ;-)

Look in build-uclinux-tools.sh to see how it sets up elf2flt.

> * the command "touch" doesn't create the devices in the Vendors Makefile

Do you have the correct version of genromfs ?  Get 0.5.1 if not.  Otherwise
check you have a lot of '@...' files in the romfs dev dir,  if so the
problem is with genromfs,  otherwise it is with touch.

> * the script "romfs-inst.sh" isn't supported since the $OPTIND call doesn't
> work either..

It may be possible to change the script to not use getopt without too much
trouble.

> We have a couple of choices here as I see it, either to set up a new linux
> box or to get a VMware/linux working properly.
> 
> Has anyone of you guys succeded to get a VMware/linux box to work with a
> windondows network? We need to get samba working.. Or do you know where to
> ask ??

Can't help here sorry,

Cheers,
Davidm

-- 
David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
davidm at snapgear.com  Fx: +61 7 3891 3630  825 Stanley St., W'gabba QLD 4102, Oz
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From davidm at snapgear.com  Fri Apr 12 08:53:43 2002
From: davidm at snapgear.com (David McCullough)
Date: Fri, 12 Apr 2002 22:53:43 +1000
Subject: [uClinux-dev] strange relocation problem with ARM toolchain
In-Reply-To: <CBEPKHHODMBKHCMLAGBMCELNCBAA.eauth@softsys.co.at>; from eauth@softsys.co.at on Fri, Apr 12, 2002 at 09:57:02AM +0200
References: <CBEPKHHODMBKHCMLAGBMCELNCBAA.eauth@softsys.co.at>
Message-ID: <20020412225343.D14241@beast.internal.moreton.com.au>


Jivin Erwin Authried lays it down ...
> I have compiled a rather large package with the ARM toolchain (gcc-2.95.3
> with Michiel Thuy's patch, latest elf2flt from cvs). When the flat binary is
> loaded, there are several error msgs from the flat loader:
> 
> BINFMT_FLAT: reloc outside program 0x1000000 (0 - 0x29bef4), killing!
> BINFMT_FLAT: reloc outside program 0x33323130 (0 - 0x29bef4), killing!
> BINFMT_FLAT: reloc outside program 0x37363534 (0 - 0x29bef4), killing!
> BINFMT_FLAT: reloc outside program 0x42413938 (0 - 0x29bef4), killing!
> ...
> 
> After some investigation, I figured out that all entries in the relocation
> table are obviously offset by 12 Bytes. When I subtract 12 from each of the
> reloc entries in the table, the relocations are ok. The source is compiled
> as usual, with
> 	-msingle-pic-base -fPIC -Wl,-elf2flt
> 
> The flat header:
>     Magic:        bFLT
>     Rev:          4
>     Entry:        0x50
>     Data Start:   0x32620
>     Data End:     0x404d0
>     BSS End:      0x416ac
>     Stack Size:   0x1000
>     Reloc Start:  0x404d0
>     Reloc Count:  0x112
>     Flags:        0x2 ( Has-PIC-GOT )
> 
> The strange thing is that my other applications that are compiled with this
> toolchain run without any problem. Any ideas?

Sounds like something in the app is causing the link to stuff up.

It might be something in the elf2flt linker script that
shouldn't be there that is pushing everything out by 12.

Check for strange constructors/init/??? entries and try to find one that is
12 bytes.

Cheers,
Davidm

-- 
David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
davidm at snapgear.com  Fx: +61 7 3891 3630  825 Stanley St., W'gabba QLD 4102, Oz
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From julienb at actimage.fr  Fri Apr 12 08:37:56 2002
From: julienb at actimage.fr (Julien Boibessot)
Date: Fri, 12 Apr 2002 14:37:56 +0200
Subject: [uClinux-dev] 5272 Uart Fifo interrupt
References: <20020410150329.GB21332@codepoet.org>
Message-ID: <03e201c1e21e$f200f5d0$8947ec95@bruker.fr>

Hi everybody !!!

I'm actually trying to catch the interrupt that 5272 uart module is intended
to generate when its receiver's Fifo is more than 75% full.
What I do is programming URF register bits 7-6 (RXS) to set the level of
fullfillness of the receiver Fifo and then I unmask the RxFifo interrupt in
UIMR register (bit 5).....
But uart module doesn't generate any interrupt.....
(I already manage to generate interrupts when receiving 1 char (RxReady) and
when fifo is full (FFull)....so my serial connection is working fine.....)

thanks for any help

Julien

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From gerg at snapgear.com  Fri Apr 12 09:19:24 2002
From: gerg at snapgear.com (gerg)
Date: Fri, 12 Apr 2002 23:19:24 +1000
Subject: [uClinux-dev] Newbie problem with kernal build
References: <5.1.0.14.1.20020412163659.00a97920@localhost>
Message-ID: <3CB6DEDC.178BCC56@snapgear.com>


Hi Peter,

Peter Ogilvy wrote:
> I've started in my home directory
> 
> /home/peter
> 
> I've unzipped the toolchain; m68k-elf-tools-20020218.tar.gz

You need to unload this from /. The tool binaries should
all end up in the /usr/local directory tree.


[snip]
make -C linux-2.4.x dep
make[1]: Entering directory `/home/peter/uClinux-dist/linux-2.4.x'
scripts/mkdep -- init/*.c > .depend
scripts/mkdep -- `find /home/peter/uClinux-dist/linux-2.4.x/include/asm
/home/pe
ter/uClinux-dist/linux-2.4.x/include/linux
/home/peter/uClinux-dist/linux-2.4.x/
include/scsi /home/peter/uClinux-dist/linux-2.4.x/include/net -name SCCS
-prune
-o -follow -name \*.h ! -name modversions.h -print` > .hdepend
make _sfdep_arch/m68knommu/kernel _sfdep_arch/m68knommu/mm
_sfdep_arch/m68knommu
/lib _sfdep_arch/m68knommu/platform/5272 _sfdep_kernel _sfdep_drivers
_sfdep_mmn
ommu _sfdep_fs _sfdep_net _sfdep_ipc _sfdep_lib
_FASTDEP_ALL_SUB_DIRS="arch/m68k
nommu/kernel arch/m68knommu/mm arch/m68knommu/lib
arch/m68knommu/platform/5272 k
ernel drivers mmnommu fs net ipc lib"
make[2]: Entering directory `/home/peter/uClinux-dist/linux-2.4.x'
make -C arch/m68knommu/kernel fastdep
make[3]: Entering directory
`/home/peter/uClinux-dist/linux-2.4.x/arch/m68knommu
/kernel'
/home/peter/uClinux-dist/linux-2.4.x/scripts/mkdep -fno-builtin
-nostdinc -D__KE
RNEL__ -I/home/peter/uClinux-dist/linux-2.4.x/include -Wall
-Wstrict-prototypes
-Wno-trigraphs -O1 -g -fno-strict-aliasing -I/include -pipe -DNO_MM
-DNO_FPU -m5
                                           ^^^^^^^^^^^

Almost certainly the problem here. This should normally be:

   -I/usr/local/lib/gcc-lib/m68k-elf/2.95.3/./include

So you need to install those tools in the right place...

Regards
Greg


------------------------------------------------------------------------
Greg Ungerer  --  Chief Software Wizard        EMAIL:  gerg at snapgear.com
Snapgear                                       PHONE:    +61 7 3279 1822
825 Stanley St,                                  FAX:    +61 7 3279 1820
Woolloongabba, QLD, 4102, Australia              WEB:   www.snapgear.com
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From eauth at softsys.co.at  Fri Apr 12 10:00:55 2002
From: eauth at softsys.co.at (Erwin Authried)
Date: Fri, 12 Apr 2002 16:00:55 +0200
Subject: [uClinux-dev] strange relocation problem with ARM toolchain
In-Reply-To: <CBEPKHHODMBKHCMLAGBMKEMACBAA.eauth@softsys.co.at>
Message-ID: <CBEPKHHODMBKHCMLAGBMCEMBCBAA.eauth@softsys.co.at>

Sorry to follow up my own post, I was able to find a small sample code piece
that shows the problem. Obviously, it happpens only when pthread.o from the
pthread library is linked with the app. The code is not intended to do
anything useful, it just forces linking of pthread.o. I'm using gcc-2.95.3,
and uclibc-0.9.10 from the CVS.

I'm compiling the file "p.c" below with:
$ arm-ml-elf-gcc -Wl,-elf2flt=-v -msingle-pic-base -fPIC p.c -o p -lpthread
>& p.log

$ grep deadbeef p.log
ABS32 vma=0x13690, value=0xd80, address=0xf10 sym_addr=0x0 rs=0x0,
opcode=0xdeadbeef
ABS32 vma=0xc160, value=0xd80, address=0xf14 sym_addr=0x0 rs=0x0,
opcode=0xdeadbeef

This proofs that there are relocations to the constants (0xdeadbeef) inside
the structure, which is wrong for sure.

-Erwin

******  p.c *******
int d;

struct {
  int a,*b,c,c1,c2,c3,c4,c5;
} xxxx= {0x12345,
        &d,
        0xdeadbeef,0xdeadbeef,0xdeadbeef,0xdeadbeef,0xdeadbeef,0xdeadbeef};
main()
{
__pthread_initialize();
}

> -----Urspr?ngliche Nachricht-----
> Von: owner-uclinux-dev at uclinux.org
> [mailto:owner-uclinux-dev at uclinux.org]Im Auftrag von Erwin Authried
> Gesendet: Freitag, 12. April 2002 13:55
> An: uclinux-dev at uclinux.org
> Betreff: Re: [uClinux-dev] strange relocation problem with ARM toolchain
>
>
> Thanks for the hint. I believe this is not the problem, but I have
> recognized one other thing that looks very suspicious:
>
> The elf2flt log shows the following warning:
>
> TEXT -> vma=0 len=28ab0
>         lma=0 clen=28ab0 oo=0 ap=4 fp=8000
> DATA -> vma=28ac0 len=cdd0
>         lma=28ac0 clen=cdd0 oo=0 ap=5 fp=30ac0
> WARNING: data=28ac0 does not directly follow text=28ab0
> BSS  -> vma=35890 len=10cc
>         lma=35890 clen=10cc oo=0 ap=4 fp=3d890
>
> objdump -h a.out.gdb shows the following output:
> Sections:
> Idx Name          Size      VMA       LMA       File off  Algn
>   0 .text         00028ab0  00000000  00000000  00008000  2**4
>                   CONTENTS, ALLOC, LOAD, READONLY, CODE
>   1 .data         0000cdd0  00028ac0  00028ac0  00030ac0  2**5
>                   CONTENTS, ALLOC, LOAD, DATA
>   2 .bss          000010cc  00035890  00035890  0003d890  2**4
>                   ALLOC
> ...
>
> The .text size is 28ab0, and the .data section starts at 28ac0. Obviously,
> this gap is caused by the alignment of the .data section (2**5).
>
> In all other *.gdb files that I have, there is no gap, and the
> alignment of
> .data is 2**2.
> The (unmodified) elf2flt.ld file shows  ". = ALIGN(0x4) ;" at the
> beginning
> of the data section.
> I have tried to change the line before _etext=. to ALIGN(0x20), instead of
> 0x10, without luck. The warning doesn't appear, and there is no
> gap between
> .text and .data, but the resulting flat file is identical to the previous
> version.
>
> Idx Name          Size      VMA       LMA       File off  Algn
>   0 .text         00028ac0  00000000  00000000  00008000  2**4
>                   CONTENTS, ALLOC, LOAD, READONLY, CODE
>   1 .data         0000cdd0  00028ac0  00028ac0  00030ac0  2**5
>                   CONTENTS, ALLOC, LOAD, DATA
>
> -Erwin
>
> > -----Urspr?ngliche Nachricht-----
> > Von: owner-uclinux-dev at uclinux.org
> > [mailto:owner-uclinux-dev at uclinux.org]Im Auftrag von Thuys, Michiel
> > Gesendet: Freitag, 12. April 2002 11:50
> > An: uclinux-dev at uclinux.org
> > Betreff: RE: [uClinux-dev] strange relocation problem with ARM toolchain
> >
> >
> > Hi Erwin,
> >
> > The only suspicious thing I see is that your BSS ends at
> > (0x416ac) where I would expect this to be aligned to a 16 byte
> > boundary. Maybe you should check your linker scripts. Sorry, not
> > much help but maybe a point into the right direction ;)
> >
> > Michiel
> >
> > > -----Original Message-----
> > > From: Erwin Authried [mailto:eauth at softsys.co.at]
> > > Sent: vrijdag 12 april 2002 9:57
> > > To: uclinux-dev at uclinux.org
> > > Subject: [uClinux-dev] strange relocation problem with ARM toolchain
> > >
> > >
> > > I have compiled a rather large package with the ARM toolchain
> > > (gcc-2.95.3
> > > with Michiel Thuy's patch, latest elf2flt from cvs). When the
> > > flat binary is
> > > loaded, there are several error msgs from the flat loader:
> > >
> > > BINFMT_FLAT: reloc outside program 0x1000000 (0 - 0x29bef4), killing!
> > > BINFMT_FLAT: reloc outside program 0x33323130 (0 - 0x29bef4), killing!
> > > BINFMT_FLAT: reloc outside program 0x37363534 (0 - 0x29bef4), killing!
> > > BINFMT_FLAT: reloc outside program 0x42413938 (0 - 0x29bef4), killing!
> > > ...
> > >
> > > After some investigation, I figured out that all entries in
> > > the relocation
> > > table are obviously offset by 12 Bytes. When I subtract 12
> > > from each of the
> > > reloc entries in the table, the relocations are ok. The
> > > source is compiled
> > > as usual, with
> > > 	-msingle-pic-base -fPIC -Wl,-elf2flt
> > >
> > > The flat header:
> > >     Magic:        bFLT
> > >     Rev:          4
> > >     Entry:        0x50
> > >     Data Start:   0x32620
> > >     Data End:     0x404d0
> > >     BSS End:      0x416ac
> > >     Stack Size:   0x1000
> > >     Reloc Start:  0x404d0
> > >     Reloc Count:  0x112
> > >     Flags:        0x2 ( Has-PIC-GOT )
> > >
> > > The strange thing is that my other applications that are
> > > compiled with this
> > > toolchain run without any problem. Any ideas?
> > >
> > > -Erwin
> > >
> > >
> > > This message resent by the uclinux-dev at uclinux.org list
> > > server http://www.uClinux.org/
> > >
> > This message resent by the uclinux-dev at uclinux.org list server
> http://www.uClinux.org/
>
>
>
> This message resent by the uclinux-dev at uclinux.org list server
> http://www.uClinux.org/
>
>


This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From eauth at softsys.co.at  Fri Apr 12 15:34:43 2002
From: eauth at softsys.co.at (Erwin Authried)
Date: Fri, 12 Apr 2002 21:34:43 +0200
Subject: [uClinux-dev] strange relocation problem with ARM toolchain
Message-ID: <01C1E269.DF7AE060@smithwicks.softsys.co.at>

The wrong offset is caused by the "__attribute__ ((aligned(32)))" in linuxthreads/internal.h.
After removing this for  _pthread_descr_struct, the relocations are ok. I feel that
this would better be solved in elf2flt. For now, I'm happy with this hack. Thanks 
for the hints and the psychological support to track this down.

-Erwin

David McCullough[SMTP:davidm at snapgear.com] wrote:
> 
> Jivin Erwin Authried lays it down ...
> > I have compiled a rather large package with the ARM toolchain (gcc-2.95.3
> > with Michiel Thuy's patch, latest elf2flt from cvs). When the flat binary is
> > loaded, there are several error msgs from the flat loader:
> > 
> > BINFMT_FLAT: reloc outside program 0x1000000 (0 - 0x29bef4), killing!
> > BINFMT_FLAT: reloc outside program 0x33323130 (0 - 0x29bef4), killing!
> > BINFMT_FLAT: reloc outside program 0x37363534 (0 - 0x29bef4), killing!
> > BINFMT_FLAT: reloc outside program 0x42413938 (0 - 0x29bef4), killing!
> > ...
> > 
> > After some investigation, I figured out that all entries in the relocation
> > table are obviously offset by 12 Bytes. When I subtract 12 from each of the
> > reloc entries in the table, the relocations are ok. The source is compiled
> > as usual, with
> > 	-msingle-pic-base -fPIC -Wl,-elf2flt
> > 
> > The flat header:
> >     Magic:        bFLT
> >     Rev:          4
> >     Entry:        0x50
> >     Data Start:   0x32620
> >     Data End:     0x404d0
> >     BSS End:      0x416ac
> >     Stack Size:   0x1000
> >     Reloc Start:  0x404d0
> >     Reloc Count:  0x112
> >     Flags:        0x2 ( Has-PIC-GOT )
> > 
> > The strange thing is that my other applications that are compiled with this
> > toolchain run without any problem. Any ideas?
> 
> Sounds like something in the app is causing the link to stuff up.
> 
> It might be something in the elf2flt linker script that
> shouldn't be there that is pushing everything out by 12.
> 
> Check for strange constructors/init/??? entries and try to find one that is
> 12 bytes.
> 
> Cheers,
> Davidm
> 
> -- 
> David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
> davidm at snapgear.com  Fx: +61 7 3891 3630  825 Stanley St., W'gabba QLD 4102, Oz
> This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/
> 
> 


This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From hamilton at SEDSystems.ca  Fri Apr 12 18:22:55 2002
From: hamilton at SEDSystems.ca (Kendrick Hamilton)
Date: Fri, 12 Apr 2002 16:22:55 -0600 (CST)
Subject: [uClinux-dev] smc9111
Message-ID: <Pine.LNX.4.44.0204121619550.1828-100000@sw-55.sedsystems.ca>

Hi,
   who made the changes to smc9111 driver in uClinux 2.0.x kernel?
I am wondering why you added

// Enable PHY (in case it is in MII_DIS mode)
 smc_write_phy_register(ioaddr, 0, PHY_CNTL_REG, 0);



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

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From Fabrice_Gautier at sdesigns.com  Fri Apr 12 20:23:40 2002
From: Fabrice_Gautier at sdesigns.com (Fabrice Gautier)
Date: Fri, 12 Apr 2002 17:23:40 -0700
Subject: [uClinux-dev] Mounting a partition on a romfs root
Message-ID: <B1F6452C89AFD411AE0800A0CC734C239DBBC7@EMAIL1>

Hi,

I'm running uClinux with a rom fs as the root fs.
Now when im trying to mount another filesystem (a cd-rom) i get this error
message:

"mount failed: Read-only file system"

My interpretation of the message is that he complains about the romfs being
read-only (not the cd). I guess the problem is that while mounting the
kernel need to modify a few things like permissions on the mount point, So
I'm kind of wondering how can I do?

Is there any way to do it with romfs, do i need use another filesystem? and
Which one?

Thanks
-- 
Fabrice Gautier, 
Fabrice_Gautier at sdesigns.com
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From justin.wojdacki at analog.com  Fri Apr 12 20:51:18 2002
From: justin.wojdacki at analog.com (Justin Wojdacki)
Date: Fri, 12 Apr 2002 17:51:18 -0700
Subject: [uClinux-dev] Mounting a partition on a romfs root
References: <B1F6452C89AFD411AE0800A0CC734C239DBBC7@EMAIL1>
Message-ID: <3CB78106.4AAFDA0B@analog.com>

Fabrice Gautier wrote:
> 
> Hi,
> 
> I'm running uClinux with a rom fs as the root fs.
> Now when im trying to mount another filesystem (a cd-rom) i get this error
> message:
> 
> "mount failed: Read-only file system"
> 
> My interpretation of the message is that he complains about the romfs being
> read-only (not the cd). I guess the problem is that while mounting the
> kernel need to modify a few things like permissions on the mount point, So
> I'm kind of wondering how can I do?
> 
> Is there any way to do it with romfs, do i need use another filesystem? and
> Which one?
>

What is your mount command? 

Mounting a read-write partition on a node in a read-only filesystem
should cause you any problems (the uCSIMM already does this for /var,
I'm sure other platforms do the same kinda of thing). 

-- 
-------------------------------------------------
Justin Wojdacki        
justin.wojdacki at analog.com         (408) 350-5032
Communications Processors Group -- Analog Devices
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From Fabrice_Gautier at sdesigns.com  Fri Apr 12 23:21:44 2002
From: Fabrice_Gautier at sdesigns.com (Fabrice Gautier)
Date: Fri, 12 Apr 2002 20:21:44 -0700
Subject: [uClinux-dev] Mounting a partition on a romfs root
Message-ID: <B1F6452C89AFD411AE0800A0CC734C239DBBC9@EMAIL1>

I was using the mount from sash, until someone make me realize that 
 mount was trying to write to /etc/mtab.

Since theres no -n option for mount in sash, i wrote my own mount. 

it's still not working but now it's the ide driver has a problem... 


-- 
Fabrice Gautier, 
Fabrice_Gautier at sdesigns.com


> -----Original Message-----
> From: Justin Wojdacki [mailto:justin.wojdacki at analog.com]
> Sent: Friday, April 12, 2002 5:51 PM
> To: uclinux-dev at uclinux.org
> Subject: Re: [uClinux-dev] Mounting a partition on a romfs root
> 
> 
> Fabrice Gautier wrote:
> > 
> > Hi,
> > 
> > I'm running uClinux with a rom fs as the root fs.
> > Now when im trying to mount another filesystem (a cd-rom) i 
> get this error
> > message:
> > 
> > "mount failed: Read-only file system"
> > 
> > My interpretation of the message is that he complains about 
> the romfs being
> > read-only (not the cd). I guess the problem is that while 
> mounting the
> > kernel need to modify a few things like permissions on the 
> mount point, So
> > I'm kind of wondering how can I do?
> > 
> > Is there any way to do it with romfs, do i need use another 
> filesystem? and
> > Which one?
> >
> 
> What is your mount command? 
> 
> Mounting a read-write partition on a node in a read-only filesystem
> should cause you any problems (the uCSIMM already does this for /var,
> I'm sure other platforms do the same kinda of thing). 
> 
> -- 
> -------------------------------------------------
> Justin Wojdacki        
> justin.wojdacki at analog.com         (408) 350-5032
> Communications Processors Group -- Analog Devices
> This message resent by the uclinux-dev at uclinux.org list 
> server http://www.uClinux.org/
> 
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From Fabrice_Gautier at sdesigns.com  Fri Apr 12 23:35:06 2002
From: Fabrice_Gautier at sdesigns.com (Fabrice Gautier)
Date: Fri, 12 Apr 2002 20:35:06 -0700
Subject: [uClinux-dev] ide driver, raw_readsw, on arm
Message-ID: <B1F6452C89AFD411AE0800A0CC734C239DBBCA@EMAIL1>

Hi,

I'm trying to use the ide to my arm based platform, and so far, the cdrom
drive is detected by the driver but when the driver try to read the data
after the identify command, thats seems garbage (I cant have the model name
for example)

One thing that seems strange to me is the way __raw_readsw is compiled.

In the assembly file, it uses ldrh rn, [rm] instructions but in then it
seems its compiled as pairs of instruction like:

ldr rn,[rm]
and rn,0xffff

I think this is (one of) a problem for me, because if I use ldr i probably
read 32bits of data and so i'm loosing half of it.

Anybody noticed this strange behaviour of gcc ? Or knows how to correct it?

Thanks



-- 
Fabrice Gautier, 
Fabrice_Gautier at sdesigns.com
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From gerg at snapgear.com  Sat Apr 13 09:10:42 2002
From: gerg at snapgear.com (gerg)
Date: Sat, 13 Apr 2002 23:10:42 +1000
Subject: [uClinux-dev] smc9111
References: <Pine.LNX.4.44.0204121619550.1828-100000@sw-55.sedsystems.ca>
Message-ID: <3CB82E52.7CA9EE24@snapgear.com>


Hi Kendrick,

Kendrick Hamilton wrote:
>    who made the changes to smc9111 driver in uClinux 2.0.x kernel?
> I am wondering why you added
> 
> // Enable PHY (in case it is in MII_DIS mode)
>  smc_write_phy_register(ioaddr, 0, PHY_CNTL_REG, 0);

I did. Debug code, I forget to remove it after adding
support for the smc91111 on the new M5249C3 board.

Regards
Greg


------------------------------------------------------------------------
Greg Ungerer  --  Chief Software Wizard        EMAIL:  gerg at snapgear.com
Snapgear                                       PHONE:    +61 7 3279 1822
825 Stanley St,                                  FAX:    +61 7 3279 1820
Woolloongabba, QLD, 4102, Australia              WEB:   www.snapgear.com
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From gerg at snapgear.com  Sat Apr 13 09:52:43 2002
From: gerg at snapgear.com (gerg)
Date: Sat, 13 Apr 2002 23:52:43 +1000
Subject: [uClinux-dev] Mounting a partition on a romfs root
References: <B1F6452C89AFD411AE0800A0CC734C239DBBC9@EMAIL1>
Message-ID: <3CB8382B.D1EF06ED@snapgear.com>


Hi Fabrice,

Fabrice Gautier wrote:
> I was using the mount from sash, until someone make me realize that
>  mount was trying to write to /etc/mtab.

I don't beleive the sash mount writes to /etc/mtab. Sash mount
will quite happily mount filesystems on top of directories in
a read only root ROMfs.

Almost certainly what mount is telling you is that you are trying
to mount a read only filesystem (that is the CD-ROM filesystem)
as read/write. Unless you specify "-r" to mount it will default
to mounting read/write. Try mount with "-r".

Regards
Greg



> Since theres no -n option for mount in sash, i wrote my own mount.
> 
> it's still not working but now it's the ide driver has a problem...
> 
> --
> Fabrice Gautier,
> Fabrice_Gautier at sdesigns.com
> 
> > -----Original Message-----
> > From: Justin Wojdacki [mailto:justin.wojdacki at analog.com]
> > Sent: Friday, April 12, 2002 5:51 PM
> > To: uclinux-dev at uclinux.org
> > Subject: Re: [uClinux-dev] Mounting a partition on a romfs root
> >
> >
> > Fabrice Gautier wrote:
> > >
> > > Hi,
> > >
> > > I'm running uClinux with a rom fs as the root fs.
> > > Now when im trying to mount another filesystem (a cd-rom) i
> > get this error
> > > message:
> > >
> > > "mount failed: Read-only file system"
> > >
> > > My interpretation of the message is that he complains about
> > the romfs being
> > > read-only (not the cd). I guess the problem is that while
> > mounting the
> > > kernel need to modify a few things like permissions on the
> > mount point, So
> > > I'm kind of wondering how can I do?
> > >
> > > Is there any way to do it with romfs, do i need use another
> > filesystem? and
> > > Which one?
> > >
> >
> > What is your mount command?
> >
> > Mounting a read-write partition on a node in a read-only filesystem
> > should cause you any problems (the uCSIMM already does this for /var,
> > I'm sure other platforms do the same kinda of thing).
> >
> > --
> > -------------------------------------------------
> > Justin Wojdacki
> > justin.wojdacki at analog.com         (408) 350-5032
> > Communications Processors Group -- Analog Devices
> > This message resent by the uclinux-dev at uclinux.org list
> > server http://www.uClinux.org/
> >
> This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/

-- 
------------------------------------------------------------------------
Greg Ungerer  --  Chief Software Wizard        EMAIL:  gerg at snapgear.com
Snapgear                                       PHONE:    +61 7 3279 1822
825 Stanley St,                                  FAX:    +61 7 3279 1820
Woolloongabba, QLD, 4102, Australia              WEB:   www.snapgear.com
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From bkuhn at lineo.com  Sat Apr 13 12:18:36 2002
From: bkuhn at lineo.com (Bernhard Kuhn)
Date: Sat, 13 Apr 2002 18:18:36 +0200
Subject: [uClinux-dev] My uClinux archive
Message-ID: <3CB85A5C.3C2A7DF2@lineo.com>


Hi Everybody!

Just for those who might be interessted:

Until my uclinux software archive will find it's final home at
uclinux.org, you may like to have access to parts of the archive at

http://home.t-online.de/home/Bernhard_Kuhn/uclinux

best regards

Bernhard

-- 
Bernhard Kuhn, Software Engineer, Lineo Inc. (Where Open Meets Smart)
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From bkuhn at lineo.com  Sat Apr 13 12:20:00 2002
From: bkuhn at lineo.com (Bernhard Kuhn)
Date: Sat, 13 Apr 2002 18:20:00 +0200
Subject: [uClinux-dev] patches for the latest rtai and uclinux release
Message-ID: <3CB85AB0.C2E4A738@lineo.com>



Hi everybody!

I have just tried the latest uClinux-distribution (20020411)
together with rtai-tr-24.1.9 (tentative release).

There were a few minor issues to get things going.
The rthal patch (see below) for the uClinux kernel fixes
a small glitch for M5272C3, but breaks MCF5307 in
entry.S - 5307 was not recently tested with rtai, so
it's probably broken anyway :-)

I executed the preemption example on the M5272C3 and it
seemed to work out fine, but more tests are certainly
appreciated :-)

Download the patches from:

http://home.t-online.de/home/Bernhard_Kuhn/uclinux/Platforms/Coldfire/tarifa/20020413/patch-linux-2.4.x-rthal.bz2
http://home.t-online.de/home/Bernhard_Kuhn/uclinux/Platforms/Coldfire/tarifa/20020413/patch-rtai-24.1.9-m68knommu.bz2

The patch for the RTAI tree shouldn't break any other architectures
(hopefully)

best regards

Bernhard


-- 
Bernhard Kuhn, Software Engineer, Lineo Inc. (Where Open Meets Smart)
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From tzengym at ms8.hinet.net  Sat Apr 13 12:17:06 2002
From: tzengym at ms8.hinet.net (Tonny Tzeng)
Date: Sun, 14 Apr 2002 00:17:06 +0800
Subject: [uClinux-dev] Microwindows and uClinux?
References: <20020411102739.A1200@localhost.localdomain>
Message-ID: <000001c1e307$9dff1220$4064a8c0@superstar>

Yes, we have ported Microwindows + uClinux to TMX320DSC21
and S3C4510 ARM7 based processors. The most important
part of porting Microwindows is the frame buffer driver for your
board rather than the processor.

Best regards,
Tonny

> Just wondering if anyone has any success with Microwindows, uClinux and
> ARM?
>
> This message resent by the uclinux-dev at uclinux.org list server
http://www.uClinux.org/

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From eauth at softsys.co.at  Sat Apr 13 04:54:30 2002
From: eauth at softsys.co.at (Erwin Authried)
Date: Sat, 13 Apr 2002 10:54:30 +0200
Subject: [uClinux-dev] ide driver, raw_readsw, on arm
In-Reply-To: <B1F6452C89AFD411AE0800A0CC734C239DBBCA@EMAIL1>
Message-ID: <CBEPKHHODMBKHCMLAGBMCEMCCBAA.eauth@softsys.co.at>

Make sure that arch/armnommu/lib/io-readsw-armv4.S is used.
You have to add CONFIG_CPU_32v4 to the kernel's config.in file.

-Erwin

> -----Urspr?ngliche Nachricht-----
> Von: owner-uclinux-dev at uclinux.org
> [mailto:owner-uclinux-dev at uclinux.org]Im Auftrag von Fabrice Gautier
> Gesendet: Samstag, 13. April 2002 05:35
> An: Uclinux-Dev (E-mail)
> Betreff: [uClinux-dev] ide driver, raw_readsw, on arm
>
>
> Hi,
>
> I'm trying to use the ide to my arm based platform, and so far, the cdrom
> drive is detected by the driver but when the driver try to read the data
> after the identify command, thats seems garbage (I cant have the
> model name
> for example)
>
> One thing that seems strange to me is the way __raw_readsw is compiled.
>
> In the assembly file, it uses ldrh rn, [rm] instructions but in then it
> seems its compiled as pairs of instruction like:
>
> ldr rn,[rm]
> and rn,0xffff
>
> I think this is (one of) a problem for me, because if I use ldr i probably
> read 32bits of data and so i'm loosing half of it.
>
> Anybody noticed this strange behaviour of gcc ? Or knows how to
> correct it?
>
> Thanks
>
>
>
> --
> Fabrice Gautier,
> Fabrice_Gautier at sdesigns.com
> This message resent by the uclinux-dev at uclinux.org list server
> http://www.uClinux.org/
>
>


This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From Fabrice_Gautier at sdesigns.com  Sat Apr 13 22:35:54 2002
From: Fabrice_Gautier at sdesigns.com (Fabrice Gautier)
Date: Sat, 13 Apr 2002 19:35:54 -0700
Subject: [uClinux-dev] ARM: personality
Message-ID: <B1F6452C89AFD411AE0800A0CC734C239DBBCB@EMAIL1>

> -----Original Message-----
> From: Erwin Authried [mailto:eauth at softsys.co.at]
> Sent: Thursday, April 11, 2002 4:11 PM
> To: uclinux-dev at uclinux.org
> Subject: Re: [uClinux-dev] ARM: personality
> 
> 
> In binfmt_flat.c, in function load_flat_binary(), 
> set_personality(PER_LINUX)
> is called. PER_LINUX is equal to 0. I have not verified this, 
> but that would
> mean that the mode in cpsr register would be set to the 
> illegal value (0) on
> 32-bit cpus. I'm wondering how the code is working at all.

The arm doc says that the behaviour is undefined when using an illegal mode.
I believe that, in most of the case mode 0 is user-mode.
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From gerg at snapgear.com  Tue Apr  9 20:29:17 2002
From: gerg at snapgear.com (Greg Ungerer)
Date: Wed, 10 Apr 2002 10:29:17 +1000
Subject: [uClinux-dev] RE: BDM driver error !
References: <FD20B4C99224D411B5AD0090278619CE07A0BD@SBS1>
Message-ID: <3CB3875D.1040303@snapgear.com>


Hi Jason,

JINGSONG LIU wrote:

> After spending a few days I did for generating a new kernel with settings
> for building
> a driver modules and using insmod bdm.o and ./chk /dev/bdmcf0 for testing it
> is works!
> Thank you very much !


Great!


> Next, I try to debug a small code without using uClinux but I got a error
> message .
> See below what I did 
> ----------------------------------------------------------------------------
> -------------
> [@localhost app]# m68k-elf-gdb app.gdb
> GNU gdb 5.0
> Copyright 2000 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain
> conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for details.
> This GDB was configured as "--host=i686-pc-linux-gnu
> --target=m68k-bdm-elf"...
>  Coldfire debug module version is 0 (5206(e))


OK, you have a few problems here.
Are you using any .gdbinit script?

Firstly to use BDM in gdb you need to use the gdb "target"
command. For example "target bdm /dev/bdmcf0". Without this
you are not debugging over the BDM.


> (gdb) list 
> 1	#include <stdio.h> 
> 2	int main (int argc, char **argv) 
> 3	{ 
> 4		printf ("Hello !!\n");
> 5		printf ("vi Quick Reference\n");
> 6		printf ("Editing Text!\n"); 
> 7		printf ("Editing Text!!!\n"); 
> 8		return 0; 
> 9	} 
> (gdb) break 4
> Breakpoint 1 at 0x24: file main.c, line 4.
> (gdb) run
> Starting program: /home/jsl/uClinux-306/uClinux-dist/user/app/app.gdb 
> Do you want to download
> `/home/jsl/uClinux-306/uClinux-dist/user/app/app.gdb'?(y or n) y


Problem here is that you trying to load and run the application alone.
You are not running uClinux yet. uClinux apps cannot be run stand alone,
only wihtin uClinux.

Typically I would do something like:

     target bdm /dev/bdmcf0
     load image/image.elf
     set $pc = 0x20000
     cont

You will need to do more than this though. Before you can do
the load your board must have its SRAM/DRAM initialized. How to
do this depends on which board you are using. Also what the
exact $pc value will be depends on how you setup the build.

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

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From petero at cvs.com.au  Mon Apr 15 02:18:51 2002
From: petero at cvs.com.au (Peter Ogilvy)
Date: Mon, 15 Apr 2002 16:18:51 +1000
Subject: [uClinux-dev] 2nd newbie problem with kernal build
Message-ID: <5.1.0.14.1.20020415143659.00a8bcc0@localhost>

Thanks to all who responded to my first question.

I installed the tools from / and I got through
make dep
without any errors. Is it worth adding this to the
http://www.uclinux.org/ports/coldfire/source.html
page? It might save the group from answering this
question again.

I'm now getting the attached error when I run make
(only the last few lines are included).

It seems to me I'm missing the /tftpboot directory,
although I've got the image.bin file so it appears
the make has got far enough so this may not be critical.

A second question I have is related to the xconfig
target selection. We have now got our SnapGear LITE,
but I couldn't decide which target to select
to build a kernal for it. I took a guess and used the
SnapGear VPN option and got similar errors as above
after doing the make. What is the correct target
for the SnapGear LITE board?

Any help would be much appreciated.

Peter
-------------- next part --------------
[ -n "" ] || cp /home/peter/uClinux-dist/images/image.bin /tftpboot
cp: cannot create regular file '/tftpboot': Permission denied
make[1]: *** [image] Error 1
make[1]: Leaving directory `/home/peter/uClinux-dist/vendors/Motorola/M5272C3'
make[1]: *** [image] Error 2


From davidm at snapgear.com  Mon Apr 15 03:17:51 2002
From: davidm at snapgear.com (David McCullough)
Date: Mon, 15 Apr 2002 17:17:51 +1000
Subject: [uClinux-dev] strange relocation problem with ARM toolchain
In-Reply-To: <01C1E269.DF7AE060@smithwicks.softsys.co.at>; from eauth@softsys.co.at on Fri, Apr 12, 2002 at 09:34:43PM +0200
References: <01C1E269.DF7AE060@smithwicks.softsys.co.at>
Message-ID: <20020415171751.A2556@beast.internal.moreton.com.au>


Jivin Erwin Authried lays it down ...
> The wrong offset is caused by the "__attribute__ ((aligned(32)))" in
> linuxthreads/internal.h.
> After removing this for  _pthread_descr_struct, the relocations are ok.
> I feel that
> this would better be solved in elf2flt. For now, I'm happy with this hack.


Sounds like it should work but isn't :-(
Any take on why the attribute aligned was messing it up?

AFAIK this points to a bug in the linker,  as by the time elf2flt gets
it, all the aligning, resolving and whatever should have been done.

Not that I would rule out a problem in elf2flt ;-)

Do you have time to make a small example that reproduces the problem.
Then I can try it on m68k and perhaps even ARM and see what I can find.


> Thanks 
> for the hints and the psychological support to track this down.

Any time :-)

Cheers,
Davidm

-- 
David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
davidm at snapgear.com  Fx: +61 7 3891 3630  825 Stanley St., W'gabba QLD 4102, Oz
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From michiel.thuys at intersil.com  Mon Apr 15 03:33:54 2002
From: michiel.thuys at intersil.com (Thuys, Michiel)
Date: Mon, 15 Apr 2002 03:33:54 -0400
Subject: [uClinux-dev] ARM: personality
Message-ID: <716A7F62A194D41195AB001083FC3AE4B5E865@inlmx1.inl.intersil.com>

Writing 0 to the CPSR results in USER_26 mode only on those ARM processors that support a 26-bit backward compatibility mode. ARM arch 4T (ARM7/ARM9) doesn't support the USER_26 mode and (luckily) writing 0 or 0x10 to the CPSR both result in USER_32 mode.

But we'd better change the personality so that the CPSR is always written with 0x10.

Michiel

> -----Original Message-----
> From: Fabrice Gautier [mailto:Fabrice_Gautier at sdesigns.com]
> Sent: zondag 14 april 2002 4:36
> To: 'uclinux-dev at uclinux.org'
> Subject: RE: [uClinux-dev] ARM: personality
> 
> 
> > -----Original Message-----
> > From: Erwin Authried [mailto:eauth at softsys.co.at]
> > Sent: Thursday, April 11, 2002 4:11 PM
> > To: uclinux-dev at uclinux.org
> > Subject: Re: [uClinux-dev] ARM: personality
> > 
> > 
> > In binfmt_flat.c, in function load_flat_binary(), 
> > set_personality(PER_LINUX)
> > is called. PER_LINUX is equal to 0. I have not verified this, 
> > but that would
> > mean that the mode in cpsr register would be set to the 
> > illegal value (0) on
> > 32-bit cpus. I'm wondering how the code is working at all.
> 
> The arm doc says that the behaviour is undefined when using 
> an illegal mode.
> I believe that, in most of the case mode 0 is user-mode.
> This message resent by the uclinux-dev at uclinux.org list 
> server http://www.uClinux.org/
> 
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From eauth at softsys.co.at  Mon Apr 15 03:41:40 2002
From: eauth at softsys.co.at (Erwin Authried)
Date: Mon, 15 Apr 2002 09:41:40 +0200
Subject: [uClinux-dev] strange relocation problem with ARM toolchain
In-Reply-To: <20020415171751.A2556@beast.internal.moreton.com.au>
Message-ID: <CBEPKHHODMBKHCMLAGBMEEMECBAA.eauth@softsys.co.at>

Hi David,

here's the smallest example that I could find that reproduces the problem.

$ arm-ml-elf-gcc -Wl,-elf2flt=-v  -msingle-pic-base -fPIC  x.c

The elf2flt output shows the warning about the gap between TEXT and DATA. I
think that elf2flt places those two sections together, ignoring this gap.
Just a guess, I'm sure that you know much better what elf2flt really does.

TEXT -> vma=0 len=e10
        lma=0 clen=e10 oo=0 ap=2 fp=8000
DATA -> vma=e20 len=220
        lma=e20 clen=220 oo=0 ap=5 fp=8e20
WARNING: data=e20 does not directly follow text=e10
...
and here is the proof for the wrong alignment ...

ABS32 vma=0x80d6e88, value=0x204, address=0x8c sym_addr=0x0 rs=0x0,
opcode=0xdeadbeef

The sections:
$ arm-ml-elf-objdump -h a.out.gdb

a.out.gdb:     file format elf32-littlearm

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         00000e10  00000000  00000000  00008000  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .data         00000220  00000e20  00000e20  00008e20  2**5
                  CONTENTS, ALLOC, LOAD, DATA
  2 .bss          00000300  00001040  00001040  00009040  2**4
                  ALLOC
...
==================================================
int ij;

struct x_struct{
int a,b;
} __attribute__ ((aligned(32))) ;

struct x_struct messitup={1};

struct{
  int a,*b,c,d,e,f,g,h;
} xxxx ={
0xdeadbeef,&ij,0xdeadbeef,0xdeadbeef,0xdeadbeef,0xdeadbeef,0xdeadbeef,0xdead
beef};

main(){}
==================================================

> -----Ursprungliche Nachricht-----
> Von: David McCullough [mailto:davidm at snapgear.com]
> Gesendet: Montag, 15. April 2002 09:18
> An: Erwin Authried
> Cc: 'uclinux-dev at uclinux.org'
> Betreff: Re: [uClinux-dev] strange relocation problem with ARM toolchain
>
>
>
> Jivin Erwin Authried lays it down ...
> > The wrong offset is caused by the "__attribute__ ((aligned(32)))" in
> > linuxthreads/internal.h.
> > After removing this for  _pthread_descr_struct, the relocations are ok.
> > I feel that
> > this would better be solved in elf2flt. For now, I'm happy with
> this hack.
>
>
> Sounds like it should work but isn't :-(
> Any take on why the attribute aligned was messing it up?
>
> AFAIK this points to a bug in the linker,  as by the time elf2flt gets
> it, all the aligning, resolving and whatever should have been done.
>
> Not that I would rule out a problem in elf2flt ;-)
>
> Do you have time to make a small example that reproduces the problem.
> Then I can try it on m68k and perhaps even ARM and see what I can find.
>
>
> > Thanks
> > for the hints and the psychological support to track this down.
>
> Any time :-)
>
> Cheers,
> Davidm
>
> --
> David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
> davidm at snapgear.com  Fx: +61 7 3891 3630  825 Stanley St.,
> W'gabba QLD 4102, Oz
>
>


This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From Joachim.Schweidler at gmx.de  Mon Apr 15 05:20:41 2002
From: Joachim.Schweidler at gmx.de (Joachim Schweidler)
Date: Mon, 15 Apr 2002 11:20:41 +0200 (MEST)
Subject: [uClinux-dev] M68360: enet.c on 2.4.x ?
Message-ID: <19773.1018862441@www30.gmx.net>

Some time ago I read that someone got the 68360 enet.c running on 2.4.x. If
that's true where can I find the diff to the 2.0.38 enet.c?

If there is no 2.4.x port, what changes are required to port it to 2.4.x?
 
Regards,
Joe



-- 
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From chri at infis.univ.trieste.it  Mon Apr 15 06:12:52 2002
From: chri at infis.univ.trieste.it (Christian Pellegrin)
Date: Mon, 15 Apr 2002 12:12:52 +0200 (CEST)
Subject: [uClinux-dev] M68360: enet.c on 2.4.x ?
In-Reply-To: <19773.1018862441@www30.gmx.net>
Message-ID: <Pine.LNX.4.44.0204151211100.1302-100000@sole.infis.univ.trieste.it>

On Mon, 15 Apr 2002, Joachim Schweidler wrote:

> If there is no 2.4.x port, what changes are required to port it to 2.4.x?
>  

Hi, read the wonderful book by A.Rubini, Linux device drivers 2ed., 
expecially the closing sections of each chapters that outline the diffs 
between 2.0, 2.2 and 2.4.

Bye!

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From philwil at earthlink.net  Mon Apr 15 06:53:54 2002
From: philwil at earthlink.net (Phil Wilshire)
Date: Mon, 15 Apr 2002 06:53:54 -0400
Subject: [uClinux-dev] 2nd newbie problem with kernal build
References: <5.1.0.14.1.20020415143659.00a8bcc0@localhost>
Message-ID: <3CBAB142.DB3D3FF0@earthlink.net>

Peter...

As root 
mkdir /tftpboot
and 
chmod a+w /tftpboot

then try again.

best regards
  Phil Wilshire

Peter Ogilvy wrote:
> 
> Thanks to all who responded to my first question.
> 
> I installed the tools from / and I got through
> make dep
> without any errors. Is it worth adding this to the
> http://www.uclinux.org/ports/coldfire/source.html
> page? It might save the group from answering this
> question again.
> 
> I'm now getting the attached error when I run make
> (only the last few lines are included).
> 
> It seems to me I'm missing the /tftpboot directory,
> although I've got the image.bin file so it appears
> the make has got far enough so this may not be critical.
> 
> A second question I have is related to the xconfig
> target selection. We have now got our SnapGear LITE,
> but I couldn't decide which target to select
> to build a kernal for it. I took a guess and used the
> SnapGear VPN option and got similar errors as above
> after doing the make. What is the correct target
> for the SnapGear LITE board?
> 
> Any help would be much appreciated.
> 
> Peter
> 
>   ------------------------------------------------------------------------
> 
>    error2.txtName: error2.txt
>              Type: Plain Text (text/plain)
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From eric.bosch at fourtress.nl  Mon Apr 15 07:43:26 2002
From: eric.bosch at fourtress.nl (Eric Bosch (Fourtress))
Date: Mon, 15 Apr 2002 13:43:26 +0200
Subject: [uClinux-dev] Serial problems
Message-ID: <000001c1e472$c2066c10$350a10ac@internal.fourtress.nl>

Hi all,

By accident I changed (with the command set ENVMM /dev/ttyS1 or set CONSOLE
/dev/ttyS1) the value of the RS232 port of the uCsimm to COM2 (/dev/ttyS1).
But the uCsimm had only a COM1 port (/dev/ttyS0), so when I try to boot from
the uCsimm no bootloader prompt (B$) appears on my minicom terminal. How can
I restore the value of this variable in the flash to COM1?. Can I make a
modification in the hardware to switch from COM1 to COM2?

I?am using the Dragonball MC68EZ328 microprocessor.

Who helps a newbie?

Thanks

Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20020415/1cb2951a/attachment.html>

From gerg at snapgear.com  Mon Apr 15 08:35:47 2002
From: gerg at snapgear.com (gerg)
Date: Mon, 15 Apr 2002 22:35:47 +1000
Subject: [uClinux-dev] 2nd newbie problem with kernal build
References: <5.1.0.14.1.20020415143659.00a8bcc0@localhost>
Message-ID: <3CBAC923.9EAC2DCC@snapgear.com>


Hi Peter,

Peter Ogilvy wrote:
> 
> Thanks to all who responded to my first question.
> 
> I installed the tools from / and I got through
> make dep
> without any errors. Is it worth adding this to the
> http://www.uclinux.org/ports/coldfire/source.html
> page? It might save the group from answering this
> question again.

I have gone one better. The links now point at the tools
web pages. So they are always up to date, and they have
the full install instructions (and also contain the
source and patches there as well).


> I'm now getting the attached error when I run make
> (only the last few lines are included).
> 
> It seems to me I'm missing the /tftpboot directory,
> although I've got the image.bin file so it appears
> the make has got far enough so this may not be critical.

As root create a /tftpboot. That is the last thing the
build does. So you are done.

Regards
Greg


------------------------------------------------------------------------
Greg Ungerer  --  Chief Software Wizard        EMAIL:  gerg at snapgear.com
Snapgear                                       PHONE:    +61 7 3279 1822
825 Stanley St,                                  FAX:    +61 7 3279 1820
Woolloongabba, QLD, 4102, Australia              WEB:   www.snapgear.com
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From stefan.jonsson at faltcom.se  Mon Apr 15 09:24:14 2002
From: stefan.jonsson at faltcom.se (Stefan Jonsson)
Date: Mon, 15 Apr 2002 15:24:14 +0200
Subject: [uClinux-dev] execute prg from location in flash
Message-ID: <NGBBJKACILMHGKHMEHHLAEKDCAAA.stefan.jonsson@faltcom.se>

Hi list,

I am new to this. I have the EB40 board + MEC. Before I make a jump from my
bootloader to MEC (where I want to put uClinux) I just wanted to try to jump
to another prg in the same flash (on-board LV1024). The board boots nicely
on my bootloader and I make a:

return (0x01011000);

... where I have put the "led_blink.bin" from Atmels example-projects in
at91-library. Nothing starts though :-(  How do I jump to another prg? Or is
it maybe some fault in led_blink.bin? When I download just the "blink" at
0x01010000 it works, it "boots" and blinks. Why can I not make a jump to an
address like I try to do? It should not be a problem just because the apps
are located in the same flash? ... since both the original bootloader and
angel is. That bootloader makes the same "jump" to angel.

Maybe this is easy stuff ... but not for the one who does yet not know.
Any help is greatly appreciated.

Thanks!

Stefan Jonsson,
Student, Universtiy of Umea, Sweden.

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From chri at infis.univ.trieste.it  Mon Apr 15 10:34:49 2002
From: chri at infis.univ.trieste.it (Christian Pellegrin)
Date: Mon, 15 Apr 2002 16:34:49 +0200 (CEST)
Subject: [uClinux-dev] execute prg from location in flash
In-Reply-To: <NGBBJKACILMHGKHMEHHLAEKDCAAA.stefan.jonsson@faltcom.se>
Message-ID: <Pine.LNX.4.44.0204151630360.1302-100000@sole.infis.univ.trieste.it>

On Mon, 15 Apr 2002, Stefan Jonsson wrote:

> Hi list,
> 

Hi!

> 
> return (0x01011000);


AFAIK this has a completly differen meaning in C.

> 
> ... where I have put the "led_blink.bin" from Atmels example-projects in
> at91-library. Nothing starts though :-(  How do I jump to another prg? Or is
> it maybe some fault in led_blink.bin? When I download just the "blink" at
> 0x01010000 it works, it "boots" and blinks. Why can I not make a jump to an
> address like I try to do? It should not be a problem just because the apps
> are located in the same flash? ... since both the original bootloader and
> angel is. That bootloader makes the same "jump" to angel.
> 
> Maybe this is easy stuff ... but not for the one who does yet not know.
> Any help is greatly appreciated.
> 

Try:

  __asm__ ("ldr r0,0x01011000");                                                                                                                                       
  __asm__ ("bx r0");      

in your C program (assuming that you use GNU toolchain).

Bye!

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From hamilton at SEDSystems.ca  Mon Apr 15 10:41:24 2002
From: hamilton at SEDSystems.ca (Kendrick Hamilton)
Date: Mon, 15 Apr 2002 08:41:24 -0600 (Canada Central Standard Time)
Subject: [uClinux-dev] Mounting a partition on a romfs root
In-Reply-To: <B1F6452C89AFD411AE0800A0CC734C239DBBC9@EMAIL1>
Message-ID: <Pine.WNT.4.44.0204150841120.91-100000@sw-55.sedsystems.ca>

Why not use busybox mount?

On Fri, 12 Apr 2002, Fabrice Gautier wrote:

> I was using the mount from sash, until someone make me realize that
>  mount was trying to write to /etc/mtab.
>
> Since theres no -n option for mount in sash, i wrote my own mount.
>
> it's still not working but now it's the ide driver has a problem...
>
>
> --
> Fabrice Gautier,
> Fabrice_Gautier at sdesigns.com
>
>
> > -----Original Message-----
> > From: Justin Wojdacki [mailto:justin.wojdacki at analog.com]
> > Sent: Friday, April 12, 2002 5:51 PM
> > To: uclinux-dev at uclinux.org
> > Subject: Re: [uClinux-dev] Mounting a partition on a romfs root
> >
> >
> > Fabrice Gautier wrote:
> > >
> > > Hi,
> > >
> > > I'm running uClinux with a rom fs as the root fs.
> > > Now when im trying to mount another filesystem (a cd-rom) i
> > get this error
> > > message:
> > >
> > > "mount failed: Read-only file system"
> > >
> > > My interpretation of the message is that he complains about
> > the romfs being
> > > read-only (not the cd). I guess the problem is that while
> > mounting the
> > > kernel need to modify a few things like permissions on the
> > mount point, So
> > > I'm kind of wondering how can I do?
> > >
> > > Is there any way to do it with romfs, do i need use another
> > filesystem? and
> > > Which one?
> > >
> >
> > What is your mount command?
> >
> > Mounting a read-write partition on a node in a read-only filesystem
> > should cause you any problems (the uCSIMM already does this for /var,
> > I'm sure other platforms do the same kinda of thing).
> >
> > --
> > -------------------------------------------------
> > Justin Wojdacki
> > justin.wojdacki at analog.com         (408) 350-5032
> > Communications Processors Group -- Analog Devices
> > This message resent by the uclinux-dev at uclinux.org list
> > server http://www.uClinux.org/
> >
> This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/
>

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From hamilton at SEDSystems.ca  Mon Apr 15 10:43:34 2002
From: hamilton at SEDSystems.ca (Kendrick Hamilton)
Date: Mon, 15 Apr 2002 08:43:34 -0600 (Canada Central Standard Time)
Subject: [uClinux-dev] smc9111
In-Reply-To: <3CB82E52.7CA9EE24@snapgear.com>
Message-ID: <Pine.WNT.4.44.0204150842320.91-100000@sw-55.sedsystems.ca>

I will be sending in a patch shortly and am changing the printk into
PRINTK (a macro that prints the debugging code when debug level is 1 or
higher)?

On Sat, 13 Apr 2002, gerg wrote:

>
> Hi Kendrick,
>
> Kendrick Hamilton wrote:
> >    who made the changes to smc9111 driver in uClinux 2.0.x kernel?
> > I am wondering why you added
> >
> > // Enable PHY (in case it is in MII_DIS mode)
> >  smc_write_phy_register(ioaddr, 0, PHY_CNTL_REG, 0);
>
> I did. Debug code, I forget to remove it after adding
> support for the smc91111 on the new M5249C3 board.
>
> Regards
> Greg
>
>
> ------------------------------------------------------------------------
> Greg Ungerer  --  Chief Software Wizard        EMAIL:  gerg at snapgear.com
> Snapgear                                       PHONE:    +61 7 3279 1822
> 825 Stanley St,                                  FAX:    +61 7 3279 1820
> Woolloongabba, QLD, 4102, Australia              WEB:   www.snapgear.com
> This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/
>

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From Fabrice_Gautier at sdesigns.com  Mon Apr 15 13:38:25 2002
From: Fabrice_Gautier at sdesigns.com (Fabrice Gautier)
Date: Mon, 15 Apr 2002 10:38:25 -0700
Subject: [uClinux-dev] Mounting a partition on a romfs root
Message-ID: <B1F6452C89AFD411AE0800A0CC734C239DBBCC@EMAIL1>


Because I didnt have busybox mount compiled and my own mount is about 5
lines.

-- 
Fabrice Gautier, 
Fabrice_Gautier at sdesigns.com


> -----Original Message-----
> From: Kendrick Hamilton [mailto:hamilton at SEDSystems.ca]
> Sent: Monday, April 15, 2002 7:41 AM
> To: 'uclinux-dev at uclinux.org'
> Subject: RE: [uClinux-dev] Mounting a partition on a romfs root
> 
> 
> Why not use busybox mount?
> 
> On Fri, 12 Apr 2002, Fabrice Gautier wrote:
> 
> > I was using the mount from sash, until someone make me realize that
> >  mount was trying to write to /etc/mtab.
> >
> > Since theres no -n option for mount in sash, i wrote my own mount.
> >
> > it's still not working but now it's the ide driver has a problem...
> >
> >
> > --
> > Fabrice Gautier,
> > Fabrice_Gautier at sdesigns.com
> >
> >
> > > -----Original Message-----
> > > From: Justin Wojdacki [mailto:justin.wojdacki at analog.com]
> > > Sent: Friday, April 12, 2002 5:51 PM
> > > To: uclinux-dev at uclinux.org
> > > Subject: Re: [uClinux-dev] Mounting a partition on a romfs root
> > >
> > >
> > > Fabrice Gautier wrote:
> > > >
> > > > Hi,
> > > >
> > > > I'm running uClinux with a rom fs as the root fs.
> > > > Now when im trying to mount another filesystem (a cd-rom) i
> > > get this error
> > > > message:
> > > >
> > > > "mount failed: Read-only file system"
> > > >
> > > > My interpretation of the message is that he complains about
> > > the romfs being
> > > > read-only (not the cd). I guess the problem is that while
> > > mounting the
> > > > kernel need to modify a few things like permissions on the
> > > mount point, So
> > > > I'm kind of wondering how can I do?
> > > >
> > > > Is there any way to do it with romfs, do i need use another
> > > filesystem? and
> > > > Which one?
> > > >
> > >
> > > What is your mount command?
> > >
> > > Mounting a read-write partition on a node in a read-only 
> filesystem
> > > should cause you any problems (the uCSIMM already does 
> this for /var,
> > > I'm sure other platforms do the same kinda of thing).
> > >
> > > --
> > > -------------------------------------------------
> > > Justin Wojdacki
> > > justin.wojdacki at analog.com         (408) 350-5032
> > > Communications Processors Group -- Analog Devices
> > > This message resent by the uclinux-dev at uclinux.org list
> > > server http://www.uClinux.org/
> > >
> > This message resent by the uclinux-dev at uclinux.org list 
> server http://www.uClinux.org/
> >
> 
> This message resent by the uclinux-dev at uclinux.org list 
> server http://www.uClinux.org/
> 
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From lance at hpbs4089.boi.hp.com  Mon Apr 15 13:19:50 2002
From: lance at hpbs4089.boi.hp.com (Lance Spaulding)
Date: Mon, 15 Apr 2002 11:19:50 -0600
Subject: [uClinux-dev] How to get initial console shell working?
Message-ID: <1020415111950.ZM9216@hpbs4089.boi.hp.com>

Can someone tell me how to get an initial console shell working in uclinux?  At
bootup, the system runs /etc/rc just fine but then reports "Execution Finished,
Exiting".  I'd like it to invoke a shell following this, but when I add
"/bin/sh" to the bottom of /etc/rc, it reports:

Command: /bin/sh
Sash command shell (version 1.1.1)
/> Reading command line: Unknown error 9
pid 9: failed 256
Execution Finished, Exiting
init: Booting to single user mode.
Sash command shell (version 1.1.1)
/>

Any suggestions?  I'd prefer not to spawn a getty as I don't want to have to
login -- I'd like it to go immediately to the shell.

I'm currently using the 20011112 distribution patched to the uc2 level.

Thanks in advance,
Lance

-- 
###########################+------------------------------------------------+
########  _/       ########|  O-      L A N C E   S P A U L D I N G      O- |
#####    _/           #####|         Research & Development Engineer        |
####    _/_/_/ _/_/_/  ####|             Hewlett-Packard Company            |
####   _/  _/ _/  _/   ####|        LaserJet Copy Solutions,  M/S 242       |
####  _/  _/ _/_/_/    ####|       11311 Chinden Blvd, Boise, ID  83714     |
#####       _/        #####| EMAIL: lance at boi.hp.com   URL: hpbs2780/~lance |
########   _/      ########| VOICE:(208) 396-3342      FAX: (208) 396-3457  |
###########################+------------------------------------------------+
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From hamilton at SEDSystems.ca  Mon Apr 15 13:55:55 2002
From: hamilton at SEDSystems.ca (Kendrick Hamilton)
Date: Mon, 15 Apr 2002 11:55:55 -0600 (CST)
Subject: [uClinux-dev] How to get initial console shell working?
In-Reply-To: <1020415111950.ZM9216@hpbs4089.boi.hp.com>
Message-ID: <Pine.LNX.4.44.0204151154530.8628-100000@sw-55.sedsystems.ca>


Do you have an inittab? I included ours if you don't. We use tinylogin for
getty.


# inittab for uClinux


# Boot-time system configuration/initialization script.
# This is run first except when booting in single-user mode.
#
#::sysinit:/etc/rc

# Format:
# ttyline:termcap-entry:getty-command
ttyS0:vt100:/sbin/getty -L ttyS0 19200 vt100




> Can someone tell me how to get an initial console shell working in uclinux?  At
> bootup, the system runs /etc/rc just fine but then reports "Execution Finished,
> Exiting".  I'd like it to invoke a shell following this, but when I add
> "/bin/sh" to the bottom of /etc/rc, it reports:
>
> Command: /bin/sh
> Sash command shell (version 1.1.1)
> /> Reading command line: Unknown error 9
> pid 9: failed 256
> Execution Finished, Exiting
> init: Booting to single user mode.
> Sash command shell (version 1.1.1)
> />
>
> Any suggestions?  I'd prefer not to spawn a getty as I don't want to have to
> login -- I'd like it to go immediately to the shell.
>
> I'm currently using the 20011112 distribution patched to the uc2 level.
>
> Thanks in advance,
> Lance
>
> --
> ###########################+------------------------------------------------+
> ########  _/       ########|  O-      L A N C E   S P A U L D I N G      O- |
> #####    _/           #####|         Research & Development Engineer        |
> ####    _/_/_/ _/_/_/  ####|             Hewlett-Packard Company            |
> ####   _/  _/ _/  _/   ####|        LaserJet Copy Solutions,  M/S 242       |
> ####  _/  _/ _/_/_/    ####|       11311 Chinden Blvd, Boise, ID  83714     |
> #####       _/        #####| EMAIL: lance at boi.hp.com   URL: hpbs2780/~lance |
> ########   _/      ########| VOICE:(208) 396-3342      FAX: (208) 396-3457  |
> ###########################+------------------------------------------------+
> This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/
>

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From Sakai at cpqd.com.br  Mon Apr 15 13:57:12 2002
From: Sakai at cpqd.com.br (Sergio Massami Sakai)
Date: Mon, 15 Apr 2002 14:57:12 -0300
Subject: [uClinux-dev] =?iso-8859-1?Q?newbie_problems_using_uCsimm=B4s_eth0?=
Message-ID: <7B3538F053C06142BF0AA9DF2D764AC606C37C@MAILSRV1.aquarius.cpqd.com.br>

Hi list,

I?m trying to use the ethernet port of my uCsimm board but it?s not working.
When I try to "ping" my PC host I receive a "Network is unreachable" message.

I?m using the correct IP addresses for my LAN, when I call "ifattach".
The ethernet cable is OK too.

I?m not sure if the "ifattach" command is working fine.
When I call "ifattach" (using the same syntax of the /etc/rc example) for the first time I receive:
"usage: ifattach --addr ..." (wrong sintax?)
When I call it, using the same arguments, for the second time I receive:
"eth0: Setting MAC address to  xx xx xx xx xx xx.
eth0: Attempting TP
eth0: using 10Base-T (RJ-45)
Warning: netmask doesn't match route address
SIOCADDRT=-1: 22
SIOCADDRT=-1: 22"

Does anyone have some idea about what is going wrong?

	Sakai
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From skibria at win.trlabs.ca  Mon Apr 15 14:39:05 2002
From: skibria at win.trlabs.ca (Sami Kibria)
Date: 15 Apr 2002 13:39:05 -0500
Subject: [uClinux-dev] re: newbie HELP...please
Message-ID: <1018895946.25368.54.camel@feedtheworms.win.trlabs.ca>

hello...okay, i just got the at91eb40a devel board and now i am trying
to get uclinux on it...

so i got the linux kernel 2.4.10 and the patch from the uclinux site and
patched it...so thats all good...

so now what do i do????

i got the files for the elf-tools and for the port to at91 but now there
doesn't seem to be any instructions (ie readme's or anything)
anywhere...so i am stuck!!!!

help please...

thank you

:)

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Sami Kibria
Project Leader, Bluetooth Applications
email: skibria at win.trlabs.ca
TRLabs - Winnipeg, MB, CANADA

http://www.win.trlabs.ca/~skibria

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
   __   _
  / /  (_)__  __ ____  __
 / /__/ / _ \/ // /\ \/ /  . . .  t h e   c h o i c e   o f   a
/____/_/_//_/\_,_/ /_/\_\              G N U   g e n e r a t i o n

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-


This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From eauth at softsys.co.at  Mon Apr 15 14:47:05 2002
From: eauth at softsys.co.at (Erwin Authried)
Date: Mon, 15 Apr 2002 20:47:05 +0200
Subject: [uClinux-dev] execute prg from location in flash
Message-ID: <01C1E4BE.B7642F80@smithwicks.softsys.co.at>

Christian Pellegrin[SMTP:chri at infis.univ.trieste.it] wrote:
> On Mon, 15 Apr 2002, Stefan Jonsson wrote:
> 
> > Hi list,
> > 
> 
> Hi!
> 
> > 
> > return (0x01011000);
> 
> 
> AFAIK this has a completly differen meaning in C.
> 
> > 
> > ... where I have put the "led_blink.bin" from Atmels example-projects in
> > at91-library. Nothing starts though :-(  How do I jump to another prg? Or is
> > it maybe some fault in led_blink.bin? When I download just the "blink" at
> > 0x01010000 it works, it "boots" and blinks. Why can I not make a jump to an
> > address like I try to do? It should not be a problem just because the apps
> > are located in the same flash? ... since both the original bootloader and
> > angel is. That bootloader makes the same "jump" to angel.
> > 
> > Maybe this is easy stuff ... but not for the one who does yet not know.
> > Any help is greatly appreciated.
> > 
> 
> Try:
> 
>   __asm__ ("ldr r0,0x01011000");
>                                                                                                                                         
>   __asm__ ("bx r0");      
> 
> in your C program (assuming that you use GNU toolchain).
or in C ....
	typedef void (*func)();
	(*(func)0x01011000)();

-Erwin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/ms-tnef
Size: 2200 bytes
Desc: not available
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20020415/b3fc7df8/attachment.bin>

From skibria at win.trlabs.ca  Mon Apr 15 15:42:37 2002
From: skibria at win.trlabs.ca (Sami Kibria)
Date: 15 Apr 2002 14:42:37 -0500
Subject: [uClinux-dev] re: newbie...next step
Message-ID: <1018899758.25367.57.camel@feedtheworms.win.trlabs.ca>

hello all...how is everyone doing? 

okay, so after i applied the patch to the 2.4.10 kernel src tree, i got
the build_uclinux_tools.sh and executing that (for ARCH=armnommu)...now
once i have that done what next????

:)
 
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Sami Kibria
Project Leader, Bluetooth Applications
email: skibria at win.trlabs.ca
TRLabs - Winnipeg, MB, CANADA

http://www.win.trlabs.ca/~skibria

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
   __   _
  / /  (_)__  __ ____  __
 / /__/ / _ \/ // /\ \/ /  . . .  t h e   c h o i c e   o f   a
/____/_/_//_/\_,_/ /_/\_\              G N U   g e n e r a t i o n

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-


This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From skibria at win.trlabs.ca  Mon Apr 15 15:47:28 2002
From: skibria at win.trlabs.ca (Sami Kibria)
Date: 15 Apr 2002 14:47:28 -0500
Subject: [uClinux-dev] re: port to atmel at91
Message-ID: <1018900049.25367.63.camel@feedtheworms.win.trlabs.ca>

hello all...again...

:)

quick question...

when we download the files from 

http://www.uclinux.org/pub/uClinux/ports/arm7tdmi/

what do we do next???

:)

how we get that port to work...i am currently doing all the arm-tools
stuff (as noted on my pervious) email...but now what do i do???

does that make any sense??

:)

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Sami Kibria
Project Leader, Bluetooth Applications
email: skibria at win.trlabs.ca
TRLabs - Winnipeg, MB, CANADA

http://www.win.trlabs.ca/~skibria

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
   __   _
  / /  (_)__  __ ____  __
 / /__/ / _ \/ // /\ \/ /  . . .  t h e   c h o i c e   o f   a
/____/_/_//_/\_,_/ /_/\_\              G N U   g e n e r a t i o n

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-


This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From uclinux at schoeldgen.de  Mon Apr 15 17:13:04 2002
From: uclinux at schoeldgen.de (Matthias Schoeldgen)
Date: Mon, 15 Apr 2002 23:13:04 +0200
Subject: [uClinux-dev] newbie problems using =?iso-8859-1?Q?uCsimm=B4s?= 
	eth0
References: <7B3538F053C06142BF0AA9DF2D764AC606C37C@MAILSRV1.aquarius.cpqd.com.br>
Message-ID: <3CBB425F.FCE45073@schoeldgen.de>

Sergio Massami Sakai wrote:
> 
> Hi list,
> 
> I?m trying to use the ethernet port of my uCsimm board but it?s not working.
> When I try to "ping" my PC host I receive a "Network is unreachable" message.
> 
> I?m using the correct IP addresses for my LAN, when I call "ifattach".
> The ethernet cable is OK too.
> 
> I?m not sure if the "ifattach" command is working fine.
> When I call "ifattach" (using the same syntax of the /etc/rc example) for the first time I receive:
> "usage: ifattach --addr ..." (wrong sintax?)
> When I call it, using the same arguments, for the second time I receive:
> "eth0: Setting MAC address to  xx xx xx xx xx xx.
> eth0: Attempting TP
> eth0: using 10Base-T (RJ-45)
> Warning: netmask doesn't match route address
> SIOCADDRT=-1: 22
> SIOCADDRT=-1: 22"
> 
> Does anyone have some idea about what is going wrong?
> 
>         Sakai
> This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/

Sergio Massami Sakai wrote:
> 
> Hi list,
> 
> I?m trying to use the ethernet port of my uCsimm board but it?s not working.
> When I try to "ping" my PC host I receive a "Network is unreachable" message.
> 
> I?m using the correct IP addresses for my LAN, when I call "ifattach".
> The ethernet cable is OK too.
> 
> I?m not sure if the "ifattach" command is working fine.
> When I call "ifattach" (using the same syntax of the /etc/rc example) for the first time I receive:
> "usage: ifattach --addr ..." (wrong sintax?)
> When I call it, using the same arguments, for the second time I receive:
> "eth0: Setting MAC address to  xx xx xx xx xx xx.
> eth0: Attempting TP
> eth0: using 10Base-T (RJ-45)
> Warning: netmask doesn't match route address
> SIOCADDRT=-1: 22
> SIOCADDRT=-1: 22"
> 
> Does anyone have some idea about what is going wrong?
> 
>         Sakai
> This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/
Hi Sakai!
This is a valid rc from my ucsimm, running on uClinux 2.4.17.
--snip 
hostname ucsimm
/bin/expand /etc/ramfs.img /dev/ram0
mount -t proc proc /proc
mount -t ext2 /dev/ram0 /var
mkdir /var/tmp
mkdir /var/log
mkdir /var/run
mkdir /var/lock
ifconfig lo 127.0.0.1
route add -net 127.0.0.0 netmask 255.0.0.0 lo
ifconfig eth0 192.168.1.102 netmask 255.255.255.0 broadcast 192.168.1.255
route add 192.168.1.102 eth0
route add default gw 192.168.1.1
portmap &
cat /etc/motd
cat /etc/version
--snip

the portmap is only if you need nfs, and can be omitted otherwise. Make
sure to use the CS89x0 ethernet driver with the "Hardware byte swap"
feature enabled when configuring the kernel. I remember things being a
bit different (not much) in the 2.0.38 kernel, but now i switched
completely to the 2.4.17 kernel ...

Good luck
matthias
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From valera at soling.ur.ru  Fri Apr 12 01:00:43 2002
From: valera at soling.ur.ru (Valera)
Date: Fri, 12 Apr 2002 10:00:43 +0500
Subject: [uClinux-dev] offtop question
References: <B1F6452C89AFD411AE0800A0CC734C239DBBC4@EMAIL1>
Message-ID: <000901c1e1df$000d1ae0$dd00a8c0@valera>

Hi,
i have one question: which IDE editor is used for uClinux coding? And which
operation system is used?

Valery
RUSSIA

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From davidm at snapgear.com  Mon Apr 15 19:47:55 2002
From: davidm at snapgear.com (David McCullough)
Date: Tue, 16 Apr 2002 09:47:55 +1000
Subject: [uClinux-dev] offtop question
In-Reply-To: <000901c1e1df$000d1ae0$dd00a8c0@valera>; from valera@soling.ur.ru on Fri, Apr 12, 2002 at 10:00:43AM +0500
References: <B1F6452C89AFD411AE0800A0CC734C239DBBC4@EMAIL1> <000901c1e1df$000d1ae0$dd00a8c0@valera>
Message-ID: <20020416094755.A5354@beast.internal.moreton.com.au>


Jivin Valera lays it down ...
> Hi,
> i have one question: which IDE editor is used for uClinux coding? And which

Most of the people I know use vi ;-)

> operation system is used?

Linux is probably the best choice,

Cheers,
Davidm

-- 
David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
davidm at snapgear.com  Fx: +61 7 3891 3630  825 Stanley St., W'gabba QLD 4102, Oz
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From davidm at snapgear.com  Mon Apr 15 20:06:09 2002
From: davidm at snapgear.com (David McCullough)
Date: Tue, 16 Apr 2002 10:06:09 +1000
Subject: [uClinux-dev] re: port to atmel at91
In-Reply-To: <1018900049.25367.63.camel@feedtheworms.win.trlabs.ca>; from skibria@win.trlabs.ca on Mon, Apr 15, 2002 at 02:47:28PM -0500
References: <1018900049.25367.63.camel@feedtheworms.win.trlabs.ca>
Message-ID: <20020416100609.D5354@beast.internal.moreton.com.au>


Jivin Sami Kibria lays it down ...
> hello all...again...
> 
> :)
> 
> quick question...
> 
> when we download the files from 
> 
> http://www.uclinux.org/pub/uClinux/ports/arm7tdmi/
> 
> what do we do next???
> 
> :)
> 
> how we get that port to work...i am currently doing all the arm-tools
> stuff (as noted on my pervious) email...but now what do i do???
> 
> does that make any sense??

I would suggest that you start with:

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

and the tools at:

	http://www.uclinux.org/pub/uClinux/arm-elf-tools/

this will get you kernel/apps and tools that are known to behave
reasonable well,

Cheers,
Davidm

-- 
David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
davidm at snapgear.com  Fx: +61 7 3891 3630  825 Stanley St., W'gabba QLD 4102, Oz
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From gerg at snapgear.com  Mon Apr 15 20:04:09 2002
From: gerg at snapgear.com (Greg Ungerer)
Date: Tue, 16 Apr 2002 10:04:09 +1000
Subject: [uClinux-dev] How to get initial console shell working?
References: <1020415111950.ZM9216@hpbs4089.boi.hp.com>
Message-ID: <3CBB6A79.2070209@snapgear.com>


Hi Lance,

Lance Spaulding wrote:

> Can someone tell me how to get an initial console shell working in uclinux?  At
> bootup, the system runs /etc/rc just fine but then reports "Execution Finished,
> Exiting".  I'd like it to invoke a shell following this, but when I add
> "/bin/sh" to the bottom of /etc/rc, it reports:


Recent versions of uClinux have a config option to init that
tells it to spawn a shell on the console. I can't recall if
it was in the 20011112 distrubution, but I think it was.

Look at what config you have in the apps section under

the "Core Applications" section, the option is "enable console

shell".

This option basically hard codes a virtual console entry
into inittab. Alternatively you could add an entry to
the /etc/inittab file too...

Regards
Greg



> Command: /bin/sh
> Sash command shell (version 1.1.1)
> /> Reading command line: Unknown error 9
> pid 9: failed 256
> Execution Finished, Exiting
> init: Booting to single user mode.
> Sash command shell (version 1.1.1)
> />
> 
> Any suggestions?  I'd prefer not to spawn a getty as I don't want to have to
> login -- I'd like it to go immediately to the shell.
> 
> I'm currently using the 20011112 distribution patched to the uc2 level.
> 
> Thanks in advance,
> Lance
> 
> 


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

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From miles at lsi.nec.co.jp  Mon Apr 15 21:42:52 2002
From: miles at lsi.nec.co.jp (Miles Bader)
Date: 16 Apr 2002 10:42:52 +0900
Subject: [uClinux-dev] Re: offtop question
In-Reply-To: <20020416094755.A5354@beast.internal.moreton.com.au>
References: <B1F6452C89AFD411AE0800A0CC734C239DBBC4@EMAIL1>
	<000901c1e1df$000d1ae0$dd00a8c0@valera>
	<20020416094755.A5354@beast.internal.moreton.com.au>
Message-ID: <buor8lgquzn.fsf@mcspd15.ucom.lsi.nec.co.jp>

David McCullough <davidm at snapgear.com> writes:
> > i have one question: which IDE editor is used for uClinux coding? And which
> 
> Most of the people I know use vi ;-)

Emacs!  Emacs, emacs, emacs, emacs, cough, cough, ack...

-Miles
-- 
I'd rather be consing.
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From petero at cvs.com.au  Tue Apr 16 01:58:43 2002
From: petero at cvs.com.au (Peter Ogilvy)
Date: Tue, 16 Apr 2002 15:58:43 +1000
Subject: [uClinux-dev] 2nd newbie problem with kernal build
In-Reply-To: <3CBAC923.9EAC2DCC@snapgear.com>
References: <5.1.0.14.1.20020415143659.00a8bcc0@localhost>
Message-ID: <5.1.0.14.1.20020416155633.00a94a78@localhost>

Greg wrote:
>I have gone one better. The links now point at the tools
>web pages. So they are always up to date, and they have
>the full install instructions (and also contain the
>source and patches there as well).

I had a look and this is an improvement. Thanks.

>As root create a /tftpboot. That is the last thing the
>build does. So you are done.

Thanks to all who provided this info, I can now build kernals :-)

Peter

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From udc at naftan.by  Tue Apr 16 03:52:55 2002
From: udc at naftan.by (Yurij Sysoev)
Date: Tue, 16 Apr 2002 09:52:55 +0200
Subject: [uClinux-dev] Re: offtop question
References: <B1F6452C89AFD411AE0800A0CC734C239DBBC4@EMAIL1>	<000901c1e1df$000d1ae0$dd00a8c0@valera>	<20020416094755.A5354@beast.internal.moreton.com.au> <buor8lgquzn.fsf@mcspd15.ucom.lsi.nec.co.jp>
Message-ID: <3CBBD857.3010000@naftan.by>

>>>i have one question: which IDE editor is used for uClinux coding? And which
>>>
>>Most of the people I know use vi ;-)
> 
> Emacs!  Emacs, emacs, emacs, emacs, cough, cough, ack...


I have no brains for emacs :-) Therefore I use WindozeNT + cygwin + FAR
internal editor (my target is a Samsung ARM S3C44BOX).

Yurij


This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From gmarselis at patras.atmel.com  Tue Apr 16 03:57:28 2002
From: gmarselis at patras.atmel.com (George Marselis)
Date: Tue, 16 Apr 2002 10:57:28 +0300
Subject: [uClinux-dev] Re: offtop question
References: <B1F6452C89AFD411AE0800A0CC734C239DBBC4@EMAIL1>	<000901c1e1df$000d1ae0$dd00a8c0@valera>	<20020416094755.A5354@beast.internal.moreton.com.au> <buor8lgquzn.fsf@mcspd15.ucom.lsi.nec.co.jp> <3CBBD857.3010000@naftan.by>
Message-ID: <005301c1e51c$5b279410$f5feaa0a@IronLung>

at the risk of starting a Holy Editor War, </flamebait>
vim is pretty nifty (especially that vim -q <errfile from gcc> option)

oh, yeah, while we're off topic, question: 
4 spaces per tab or 8? 8 seems such a waste :(

heh, anybody remember the 1987-1989 Holy OS War on usenet? :)
-><-
First things first
obey  your thirst
UNIX, aight?

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From enrico.benetti at bluewind.it  Tue Apr 16 06:37:36 2002
From: enrico.benetti at bluewind.it (Enrico Benetti [BW])
Date: Tue, 16 Apr 2002 12:37:36 +0200
Subject: [uClinux-dev] boot from flash on 5272
Message-ID: <3CBC1B10.13509.A0B3C@localhost>

Hi all,
I've got a question about flash programming and running uClinux 
from flash memory on a M5272C3 motorola card.
I've patched blkmem.c, crt0_ram.S and ram.ld files with Kuhn 
patch so I've got crt0_rom.S and rom.ld files, then I've select 'kernel 
executes from ROM'.
Looking to rom.ld I think I've got 1.8 MB of flash, but at the end of 
make process I've got this error message:

m68k-elf-objcopy -O binary /opt/uClinux-dist/linux-2.4.x/linux \
      
          /opt/uClinux-dist/images/linux.bin
BFD: Warning: Writing 
section `.text' to huge (ie negative) file offset 0xffe20000.
m68k-elf-
objcopy: /opt/uClinux-dist/images/linux.bin: File 
truncated
make[1]: *** [image] Error 1
make[1]: Leaving directory 
`/opt/uClinux-dist/vendors/Motorola/M5272C3'
make: *** [image] 
Error 2
The generated romfs.bin file size is 1120256 byte.

I'd like to have uClinux booting from flash directly (without 
bootloader) so I think this is the right way to proceed (changing 
jp13 setting). I think there's a linking problem: at this moment I 
want to have dbug installed, so I've got only the 2nd Mb of flash 
available, isn't it? The image.bin I use running from ram is about 1.2 
Mb, so it can't stay in flash, I suppose...
Thank you for any help, I'm quit new in Linux programming so I 
need more than one advice!

Enrico
------------------------------------------
 Enrico Benetti
 BlueWind Embedded Systems Design
 Via Steffani, 7/B
 I-31033 Castelfranco Veneto (TV)

 Office: +39 0 423 723431
 Fax   : +39 0 423 744738
 GSM   : +39 335 7556736
 mailto: enrico.benetti at bluewind.it
 http://www.bluewind.it
------------------------------------------

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From enrico.benetti at bluewind.it  Tue Apr 16 06:45:38 2002
From: enrico.benetti at bluewind.it (Enrico Benetti [BW])
Date: Tue, 16 Apr 2002 12:45:38 +0200
Subject: [uClinux-dev] boot from flash on 5272 (2)
Message-ID: <3CBC1CF2.4877.1164CF@localhost>

Hi again!
Reading Kuhn mini-howto on flash device (http://home.t-
online.de/home/Bernhard_Kuhn) I'd like to know some opinion on 
which is the best strategies to use to have a system with uClinux 
auto-boot, without removing installed dbug on motorola 5272c3 
board. There're a lot of way (with or w/outColilo, romfs, cramfs, etc).
If I don't remove dbug, I've always only 1 Mb of flash available?
Thanks to all,

------------------------------------------
 Enrico Benetti
 BlueWind Embedded Systems Design
 Via Steffani, 7/B
 I-31033 Castelfranco Veneto (TV)

 Office: +39 0 423 723431
 Fax   : +39 0 423 744738
 GSM   : +39 335 7556736
 mailto: enrico.benetti at bluewind.it
 http://www.bluewind.it
------------------------------------------

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From mark.howson at ntu.ac.uk  Tue Apr 16 07:11:21 2002
From: mark.howson at ntu.ac.uk (Howson, Mark)
Date: Tue, 16 Apr 2002 12:11:21 +0100
Subject: [uClinux-dev] elf2flt can't find elf.h include
Message-ID: <579C0CAF497CD511AD4D00508BBD7AAC0246E5@pikachu.ntu.ac.uk>

Hi,

I'm trying to build uClinux for a Coldfire 5407 platform using the
build-uclinux-tools.sh script. (I'm using OpenBSD 3.0, latest cvs versions
of uClibc, elf2flt, and the 200020410 release of the 68k build tools). No
significant problems yet, but I can't build STAGE8:

>>>
gcc -g -O2 -DSTDC_HEADERS=1 -DHAVE_FCNTL_H=1 -DHAVE_UNISTD_H=1
-DHAVE_BFD_H=1 -DHAVE_VPRINTF=1  -DTARGET_m68k
-I/shares/tools/uclinux/m68k-elf-binutils/bfd -static -o elf2flt ./elf2flt.c
/shares/tools/uclinux/m68k-elf-binutils/bfd/libbfd.a
/shares/tools/uclinux/m68k-elf-binutils/libiberty/libiberty.a
./elf2flt.c:48: elf.h: No such file or directory
gmake: *** [elf2flt] Error 1

Doing a find gives me these elf.h files to choose from:
uClibc/include/elf.h
uClinux-2.4.x/include/asm-m68k/elf.h
uClinux-2.4.x/include/asm-m68knommu/elf.h
uClinux-2.4.x/include/linux/elf.h
uClinux-2.4.x/include/config/kcore/elf.h
uClinux-2.4.x/include/config/binfmt/elf.h

I've tried adding the first four of these to the include file, but each of
these gives me a different set of clashes.

Can anyone give me a clue as to what I might be doing wrong, or tell me
which elf.h I'm supposed to be using?

Thanks,
Mark
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From simon at promate.com.tw  Tue Apr 16 08:33:37 2002
From: simon at promate.com.tw (simon at promate.com.tw)
Date: Tue, 16 Apr 2002 20:33:37 +0800
Subject: [uClinux-dev] M5407C3  & bdm 
Message-ID: <OF895902FD.BBB8660F-ON48256B9D.00445911@promate.com.tw>

I use the mot.'s M5407C3 evb and P&E bdm. When I run the bdm/test/chk to 
check the bdm and evb,
I got the following error message.


Driver Ver : 2.a
Processor  : Coldfire
Interface  : P&E Coldfire
CSR break not set, target failed to break, CSR = 0x00200000


What's wrong with my evb? Where can I find the description of the CSR 
register?


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20020416/8f412739/attachment.html>

From udc at naftan.by  Tue Apr 16 09:32:08 2002
From: udc at naftan.by (Yurij Sysoev)
Date: Tue, 16 Apr 2002 15:32:08 +0200
Subject: [uClinux-dev] Re: offtop question
References: <B1F6452C89AFD411AE0800A0CC734C239DBBC4@EMAIL1>	<000901c1e1df$000d1ae0$dd00a8c0@valera>	<20020416094755.A5354@beast.internal.moreton.com.au> <buor8lgquzn.fsf@mcspd15.ucom.lsi.nec.co.jp> <3CBBD857.3010000@naftan.by> <005301c1e51c$5b279410$f5feaa0a@IronLung>
Message-ID: <3CBC27D8.7000505@naftan.by>

George Marselis wrote:

> oh, yeah, while we're off topic, question: 
> 4 spaces per tab or 8? 8 seems such a waste :(


<OT>
Certainly, 4!
I have no such wide display to see the text with 8 tab stops ;-)
</OT>

Yurij


This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From udc at naftan.by  Tue Apr 16 09:57:17 2002
From: udc at naftan.by (Yurij Sysoev)
Date: Tue, 16 Apr 2002 15:57:17 +0200
Subject: [uClinux-dev] Wrong linker script for armnommu target in last snapshot (linux2.4.x) ?
Message-ID: <3CBC2DBD.9010408@naftan.by>

Hi,

The section .text _before_ section .init is correctly? Or not?

uClinux-dist/linux-2.4.x/arch/armnommu/vmlinux-armv.lds.in:

OUTPUT_ARCH(arm)
ENTRY(stext)
SECTIONS
{
         . = TEXTADDR;

         .text : {                       /* Real text segment */
                 _text = .;              /* Text and read-only data */
                         *(.text)
                         *(.fixup)
...........

                 _etext = .;             /* End of text section */
         }

         . = ALIGN(4096);

         .init : {                       /* Init code and data */
                 _stext = .;
                 __init_begin = .;
                         *(.text.init)

...........

}

Yurij


This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From fskivee at skynet.be  Tue Apr 16 09:37:49 2002
From: fskivee at skynet.be (Fabian =?iso-8859-1?q?Skiv=E9e?=)
Date: Tue, 16 Apr 2002 15:37:49 +0200
Subject: [uClinux-dev] Install uClinux on a PalmVx ?
Message-ID: <200204161332.g3GDWOx21688@picard.skynet.be>

Hello,

	I try to install uClinux on a palmVx. I install the file "uClinuxPalm.prc" 
form the web-site : http://palm-linux.sourceforge.net/. But when I run the 
application on the palm, I see the picture of the Linux penguin but I don't 
see anything on the serial port.

	I use the command : "cat | /dev/ttyS0" to see the characters on the serial
device /dev/ttyS0. I already use this method to see the output of the 
xcopilot and it works very well.

	Does anyone can help me ? Does I make an mistake with my linux or the serial 
port ? 

	Thanks

	Fabian Skiv?e

PS : I try to install the linux on a Palm m500. Does anyone know the changes 
I must apply to the code between the PalmVx and the Palm m500 ?

-- 

Skiv?e Fabian 
[a] rue Petite Spinette 8, 4630 Soumagne, Belgium 
[t] + 32 (0) 4 377 23 76
[g] + 32 (0) 498 62 47 03 (direct)
[e] fskivee at skynet.be
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From Sakai at cpqd.com.br  Tue Apr 16 09:59:25 2002
From: Sakai at cpqd.com.br (Sergio Massami Sakai)
Date: Tue, 16 Apr 2002 10:59:25 -0300
Subject: [uClinux-dev] =?iso-8859-1?Q?RES=3A_=5BuClinux-dev=5D_newbie_problems_using_uCsimm=B4s_?=
	=?iso-8859-1?Q?eth0?=
Message-ID: <7B3538F053C06142BF0AA9DF2D764AC606C37D@MAILSRV1.aquarius.cpqd.com.br>


Hi Matthias!

I?ve noted that you use "ifconfig" instead of "ifattach".
What is the difference between then? I didn?t find any documentation about ifattach... (a thin version of ifconfig?)
Where can I get the ported versions of "route" and "ifconfig"?

Thanks for the tips!

	Sakai
____________________________________________________________________
Hi Sakai!
This is a valid rc from my ucsimm, running on uClinux 2.4.17.
--snip 
hostname ucsimm
/bin/expand /etc/ramfs.img /dev/ram0
mount -t proc proc /proc
mount -t ext2 /dev/ram0 /var
mkdir /var/tmp
mkdir /var/log
mkdir /var/run
mkdir /var/lock
ifconfig lo 127.0.0.1
route add -net 127.0.0.0 netmask 255.0.0.0 lo
ifconfig eth0 192.168.1.102 netmask 255.255.255.0 broadcast 192.168.1.255
route add 192.168.1.102 eth0
route add default gw 192.168.1.1
portmap &
cat /etc/motd
cat /etc/version
--snip

the portmap is only if you need nfs, and can be omitted otherwise. Make
sure to use the CS89x0 ethernet driver with the "Hardware byte swap"
feature enabled when configuring the kernel. I remember things being a
bit different (not much) in the 2.0.38 kernel, but now i switched
completely to the 2.4.17 kernel ...

Good luck
matthias
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From rolf.peukert at imms.de  Tue Apr 16 10:01:02 2002
From: rolf.peukert at imms.de (Rolf Peukert)
Date: Tue, 16 Apr 2002 16:01:02 +0200
Subject: [uClinux-dev] Wrong linker script for armnommu target in last 
 snapshot (linux2.4.x) ?
References: <3CBC2DBD.9010408@naftan.by>
Message-ID: <3CBC2E9E.D1AB5C35@imms.de>

Yurij Sysoev wrote:
> 
> Hi,
> 
> The section .text _before_ section .init is correctly? Or not?

Sorry, that was my fault. A forgotten workaround for an omission
somewhere else.

It is fixed now, and if you look at the cvs repository, you'll find the
restored original linker script.

Best wishes,
Rolf
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From hamilton at SEDSystems.ca  Tue Apr 16 10:45:06 2002
From: hamilton at SEDSystems.ca (Kendrick Hamilton)
Date: Tue, 16 Apr 2002 08:45:06 -0600 (CST)
Subject: [uClinux-dev] Re: offtop question
In-Reply-To: <005301c1e51c$5b279410$f5feaa0a@IronLung>
Message-ID: <Pine.LNX.4.44.0204160842480.1727-100000@sw-55.sedsystems.ca>

With regards to tabs:
	I use vim. I set it to put tab characters in for indents and let
it handle indenting the code.I set my vim configuration to show tabs as
four spaces but can very easily change it to show them as 8 spaces. If the
editor actually puts in tab characters, it should be easy for a modern
editor to show tabs as how many ever characters you want.

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

On Tue, 16 Apr 2002, George Marselis wrote:

> at the risk of starting a Holy Editor War, </flamebait>
> vim is pretty nifty (especially that vim -q <errfile from gcc> option)
>
> oh, yeah, while we're off topic, question:
> 4 spaces per tab or 8? 8 seems such a waste :(
>
> heh, anybody remember the 1987-1989 Holy OS War on usenet? :)
> -><-
> First things first
> obey  your thirst
> UNIX, aight?
>
> This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/
>

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From lance at hpbs4089.boi.hp.com  Tue Apr 16 11:14:05 2002
From: lance at hpbs4089.boi.hp.com (Lance Spaulding)
Date: Tue, 16 Apr 2002 09:14:05 -0600
Subject: [uClinux-dev] How to get initial console shell working?
In-Reply-To: Greg Ungerer <gerg@snapgear.com>
        "Re: [uClinux-dev] How to get initial console shell working?" (Apr 16, 10:04am)
References: <1020415111950.ZM9216@hpbs4089.boi.hp.com> 
	<3CBB6A79.2070209@snapgear.com>
Message-ID: <1020416091405.ZM10756@hpbs4089.boi.hp.com>

On Apr 16, 10:04am, Greg Ungerer wrote:
> Subject: Re: [uClinux-dev] How to get initial console shell working?
>
> Recent versions of uClinux have a config option to init that
> tells it to spawn a shell on the console. I can't recall if
> it was in the 20011112 distrubution, but I think it was.
>
> Look at what config you have in the apps section under
>
> the "Core Applications" section, the option is "enable console
>
> shell".
>
> This option basically hard codes a virtual console entry
> into inittab. Alternatively you could add an entry to
> the /etc/inittab file too...
>

I had this option enabled, but it wasn't adding anything to the inittab for
some reason.  I added "ttyS0:vt100:/bin/sh" manually and it works great now.

Thanks,
Lance

-- 
###########################+------------------------------------------------+
########  _/       ########|  O-      L A N C E   S P A U L D I N G      O- |
#####    _/           #####|         Research & Development Engineer        |
####    _/_/_/ _/_/_/  ####|             Hewlett-Packard Company            |
####   _/  _/ _/  _/   ####|        LaserJet Copy Solutions,  M/S 242       |
####  _/  _/ _/_/_/    ####|       11311 Chinden Blvd, Boise, ID  83714     |
#####       _/        #####| EMAIL: lance at boi.hp.com   URL: hpbs2780/~lance |
########   _/      ########| VOICE:(208) 396-3342      FAX: (208) 396-3457  |
###########################+------------------------------------------------+
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From bernd.pfaff at dspsolutions.de  Tue Apr 16 11:40:07 2002
From: bernd.pfaff at dspsolutions.de (Bernd Pfaff)
Date: Tue, 16 Apr 2002 17:40:07 +0200
Subject: [uClinux-dev] Restrictions to M5272C Registers
Message-ID: <200204161540.RAA19579@caleb.dspsolutions>

Hi all,

I'm working with the Motorola M5272C microcontrollerplatform under uClinux.   
I use the chip select registers (CSOR1 and CSBR1) for CS1 and the general 
purpose I/O module (registers PACNT, PADDR, PADAT and PBCNT).

How is uClinux affecting those registers? 
Or can anyone give me a hint, where I can find information about the use of 
registers by uClinux? 

Thanks in advance!

Regards

Bernd
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From tahir at snom.de  Tue Apr 16 12:06:27 2002
From: tahir at snom.de (Usman Tahir)
Date: Tue, 16 Apr 2002 18:06:27 +0200
Subject: [uClinux-dev] elf2flt support for C++ & STL source compilation.
Message-ID: <3CBC4C03.483B3DA9@snom.de>

Hi there,

I have been encountering some problems in my user application (in C++)
compilation for MCF5206 using the latest m68k-elf-tools (installed in
/usr/local.....) and the latest uClinux distribution i.e.
uClinux-kernel-2.4.17 (April 11 release). I am using $(LDFLAGS),
$(LDLIBS), $(CXXFLAGS) etc. The problem seems to be in elf2flt, as
apparent from the following log:

obj_files/my_app.elf2flt: In function `f1':
/home/davidm/work/m68k-elf-tools/m68k-elf-gcc/gcc/../../gcc-2.95.3/gcc/libgcc2.c(.text+0xafbee):
undefined reference to `abort'
obj_files/,my_app.elf2flt: In function `ff2':
/home/davidm/work/m68k-elf-tools/m68k-elf-gcc/gcc/../../gcc-2.95.3/gcc/libgcc2.c(.text+0xb004e):
undefined reference to `abort'
obj_files/my_app.elf2flt: In function `fff3':
/home/davidm/work/m68k-elf-tools/m68k-elf-gcc/gcc/../../gcc-2.95.3/gcc/frame.c(.text+0xb1a3a):
undefined reference to `abort'
/home/davidm/work/m68k-elf-tools/m68k-elf-gcc/gcc/../../gcc-2.95.3/gcc/frame.c(.text+0xb1a6a):
undefined reference to `abort'
obj_files/my_app.elf2flt: In function `fff4':
/home/davidm/work/m68k-elf-tools/m68k-elf-gcc/gcc/../../gcc-2.95.3/gcc/frame.c:627:
undefined reference to `abort'
obj_files/my_app.elf2flt(.text+0xb235e):/home/davidm/work/m68k-elf-tools/m68k-elf-gcc/gcc/../../gcc-2.95.3/gcc/frame.c:
more undefined references to `abort' follow
collect2: ld returned 1 exit status
make[2]: *** [obj_files/my_app] Error 1
make[2]: Leaving directory `~/uClinux-dist/user/my_app'
make[1]: *** [all] Error 2
make[1]: Leaving directory `~/uClinux-dist/user'
make: *** [subdirs] Error 1


Does m68k-elf tool chain and specifically elf2flt fully support C++?
What's the status regarding STL? Is there a minimum valid level e.g.
only lists or only templates allowed to be used in STL etc.? I tried to
use some lists and included <list>. Following errors were generated:


In file included from
/usr/local/lib/gcc-lib/m68k-elf/2.95.3/../../../../include/g++-3/stl_config.h:151,
                 from
/usr/local/lib/gcc-lib/m68k-elf/2.95.3/../../../../include/g++-3/stl_algobase.h:36,
                 from
/usr/local/lib/gcc-lib/m68k-elf/2.95.3/../../../../include/g++-3/list:30,
                 from my_f1.hxx:40,
                 from my_f1.cxx:36:
/usr/local/lib/gcc-lib/m68k-elf/2.95.3/../../../../m68k-elf/include/_G_config.h:44:
syntax error before `;'
In file included from
/usr/local/lib/gcc-lib/m68k-elf/2.95.3/../../../../include/g++-3/iostream.h:31,
                 from
/usr/local/lib/gcc-lib/m68k-elf/2.95.3/../../../../include/g++-3/stl_algobase.h:53,
                 from
/usr/local/lib/gcc-lib/m68k-elf/2.95.3/../../../../include/g++-3/list:30,
                 from my_f2.hxx:40,
                 from my_f2.cxx:36:
/usr/local/lib/gcc-lib/m68k-elf/2.95.3/../../../../include/g++-3/streambuf.h:403:
invalid type `void *' for default argument to `ios *'
In file included from
/usr/local/lib/gcc-lib/m68k-elf/2.95.3/../../../../include/g++-3/stl_algobase.h:53,
                 from
/usr/local/lib/gcc-lib/m68k-elf/2.95.3/../../../../include/g++-3/list:30,
                 from my_f3.hxx:40,
                 from my_f3.cxx:36:
/usr/local/lib/gcc-lib/m68k-elf/2.95.3/../../../../include/g++-3/iostream.h:50:
invalid type `void *' for default argument to `ostream *'
/usr/local/lib/gcc-lib/m68k-elf/2.95.3/../../../../include/g++-3/iostream.h:123:
invalid type `void *' for default argument to `ostream *'
/usr/local/lib/gcc-lib/m68k-elf/2.95.3/../../../../include/g++-3/iostream.h:231:
invalid type `void *' for default argument to `ostream *'
......

Thanks for all the help coming my way.

Regards,
Usman.
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From skibria at win.trlabs.ca  Tue Apr 16 13:29:27 2002
From: skibria at win.trlabs.ca (Sami Kibria)
Date: 16 Apr 2002 12:29:27 -0500
Subject: [uClinux-dev] re: ERROR: debug-armv.S:337: #error Unknown architecture
Message-ID: <1018978169.25367.122.camel@feedtheworms.win.trlabs.ca>

hello...everybody...how is everybody doing?  quick question...

what does the following error mean???

arm-elf-gcc -D__ASSEMBLY__ -D__KERNEL__
-I/opt/uCLinux/linux-2.4.10/include -DNO_MM -mapcs-32  -mno-fpu
-msoft-float   -c -o debug-armv.o debug-armv.S
debug-armv.S:337: #error Unknown architecture
make[1]: *** [debug-armv.o] Error 1
make[1]: Leaving directory
`/opt/uCLinux/linux-2.4.10/arch/armnommu/kernel'
make: *** [_dir_arch/armnommu/kernel] Error 2

thanks...

ps...i got the kernel source 2.4.10, patched it, made all the arm-elf
tools, and now i am compiling my kernel for the at91 devel board (eb40A)


-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Sami Kibria
Project Leader, Bluetooth Applications
email: skibria at win.trlabs.ca
TRLabs - Winnipeg, MB, CANADA

http://www.win.trlabs.ca/~skibria

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
   __   _
  / /  (_)__  __ ____  __
 / /__/ / _ \/ // /\ \/ /  . . .  t h e   c h o i c e   o f   a
/____/_/_//_/\_,_/ /_/\_\              G N U   g e n e r a t i o n

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-


This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From MGroden at hxi.com  Tue Apr 16 14:05:58 2002
From: MGroden at hxi.com (Mike Groden)
Date: Tue, 16 Apr 2002 14:05:58 -0400
Subject: [uClinux-dev] Restrictions to M5272C Registers
Message-ID: <879EA880A0FED411996B00B0D0B082EC2B418B@hxi_exch01.hxi.com>

I'd take a look at "linux/arch/m68knommu/platform/5272/config.c" for
starters.

-----Original Message-----
From: Bernd Pfaff [mailto:bernd.pfaff at dspsolutions.de]
Sent: Tuesday, April 16, 2002 11:40 AM
To: uclinux-dev at uclinux.org
Subject: [uClinux-dev] Restrictions to M5272C Registers


Hi all,

I'm working with the Motorola M5272C microcontrollerplatform under uClinux.

I use the chip select registers (CSOR1 and CSBR1) for CS1 and the general 
purpose I/O module (registers PACNT, PADDR, PADAT and PBCNT).

How is uClinux affecting those registers? 
Or can anyone give me a hint, where I can find information about the use of 
registers by uClinux? 

Thanks in advance!

Regards

Bernd
This message resent by the uclinux-dev at uclinux.org list server
http://www.uClinux.org/
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From uclinux at schoeldgen.de  Tue Apr 16 14:08:19 2002
From: uclinux at schoeldgen.de (Matthias Schoeldgen)
Date: Tue, 16 Apr 2002 20:08:19 +0200
Subject: [uClinux-dev] newbie problems using =?iso-8859-1?Q?uCsimm=B4s?= eth0
References: <7B3538F053C06142BF0AA9DF2D764AC606C37D@MAILSRV1.aquarius.cpqd.com.br>
Message-ID: <3CBC6892.490ECB45@schoeldgen.de>

Sergio Massami Sakai wrote:
> 
> Hi Matthias!
> 
> I?ve noted that you use "ifconfig" instead of "ifattach".
> What is the difference between then? I didn?t find any documentation about ifattach... (a thin version of ifconfig?)
> Where can I get the ported versions of "route" and "ifconfig"?
> 
> Thanks for the tips!
> 
>         Sakai

Hello Sakai!
Using ifconfig seemed to be the simpler solution: Only one program to
attach and configure the loopback and the ethernet interface. Both are
from the complete source at 
http://www.uclinux.org/ports/coldfire/source.html
which is a fine base for projects, including many, many tools. A great
job considering the multi-platform work. (thank to all contributers!)
One more hint: Do not use the standalone "mount" program, but the one
from busybox, it's working better, especially if you're into NFS mounts.

BTW, can anyone explain the behaviour of busybox generating a binary for
each of the enabled commands ? When compiling the userland binaries i
get a 'busybox' executable, a 'mount' executable, and so on, each having
the same size of about 58kb or larger when including more busybox
features. I always thought busybox is one executable with all the
features built in ???

Enjoy!
Matthias  
> ____________________________________________________________________
> Hi Sakai!
> This is a valid rc from my ucsimm, running on uClinux 2.4.17.
> --snip
> hostname ucsimm
> /bin/expand /etc/ramfs.img /dev/ram0
> mount -t proc proc /proc
> mount -t ext2 /dev/ram0 /var
> mkdir /var/tmp
> mkdir /var/log
> mkdir /var/run
> mkdir /var/lock
> ifconfig lo 127.0.0.1
> route add -net 127.0.0.0 netmask 255.0.0.0 lo
> ifconfig eth0 192.168.1.102 netmask 255.255.255.0 broadcast 192.168.1.255
> route add 192.168.1.102 eth0
> route add default gw 192.168.1.1
> portmap &
> cat /etc/motd
> cat /etc/version
> --snip
> 
> the portmap is only if you need nfs, and can be omitted otherwise. Make
> sure to use the CS89x0 ethernet driver with the "Hardware byte swap"
> feature enabled when configuring the kernel. I remember things being a
> bit different (not much) in the 2.0.38 kernel, but now i switched
> completely to the 2.4.17 kernel ...
> 
> Good luck
> matthias
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From uclinux at schoeldgen.de  Tue Apr 16 14:14:04 2002
From: uclinux at schoeldgen.de (Matthias Schoeldgen)
Date: Tue, 16 Apr 2002 20:14:04 +0200
Subject: [uClinux-dev] Re: offtop question
References: <B1F6452C89AFD411AE0800A0CC734C239DBBC4@EMAIL1>	<000901c1e1df$000d1ae0$dd00a8c0@valera>	<20020416094755.A5354@beast.internal.moreton.com.au> <buor8lgquzn.fsf@mcspd15.ucom.lsi.nec.co.jp> <3CBBD857.3010000@naftan.by> <005301c1e51c$5b279410$f5feaa0a@IronLung>
Message-ID: <3CBC69EB.26F0936C@schoeldgen.de>

Hi George!
Here are my 2 pence:

I prefer MidnightCommander as editor. And i remember Linus in
"CodingStyle" to insist on 8 spaces per tab... :-)


Matthias

George Marselis wrote:
> 
> at the risk of starting a Holy Editor War, </flamebait>
> vim is pretty nifty (especially that vim -q <errfile from gcc> option)
> 
> oh, yeah, while we're off topic, question:
> 4 spaces per tab or 8? 8 seems such a waste :(
> 
> heh, anybody remember the 1987-1989 Holy OS War on usenet? :)
> -><-
> First things first
> obey  your thirst
> UNIX, aight?
> 
> This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From tzengym at ms8.hinet.net  Tue Apr 16 14:46:06 2002
From: tzengym at ms8.hinet.net (Tonny Tzeng)
Date: Wed, 17 Apr 2002 02:46:06 +0800
Subject: [uClinux-dev] re: ERROR: debug-armv.S:337: #error Unknown architecture
References: <1018978169.25367.122.camel@feedtheworms.win.trlabs.ca>
Message-ID: <006c01c1e577$6cdee360$0200a8c0@superstar>

The way of getting active interrupt number is different among ARM
based processors. You should apply the patch for AT91, or checkout
a uClinux copy from http://cvs.uclinux.org directly.

Best regards,
Tonny

> hello...everybody...how is everybody doing?  quick question...
> 
> what does the following error mean???
> 
> arm-elf-gcc -D__ASSEMBLY__ -D__KERNEL__
> -I/opt/uCLinux/linux-2.4.10/include -DNO_MM -mapcs-32  -mno-fpu
> -msoft-float   -c -o debug-armv.o debug-armv.S
> debug-armv.S:337: #error Unknown architecture
> make[1]: *** [debug-armv.o] Error 1
> make[1]: Leaving directory
> `/opt/uCLinux/linux-2.4.10/arch/armnommu/kernel'
> make: *** [_dir_arch/armnommu/kernel] Error 2
> 
> thanks...
> 
> ps...i got the kernel source 2.4.10, patched it, made all the arm-elf
> tools, and now i am compiling my kernel for the at91 devel board (eb40A)


This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From skibria at win.trlabs.ca  Tue Apr 16 14:52:06 2002
From: skibria at win.trlabs.ca (Sami Kibria)
Date: 16 Apr 2002 13:52:06 -0500
Subject: [uClinux-dev] kernel error...???
Message-ID: <1018983126.32489.133.camel@feedtheworms.win.trlabs.ca>

hello...how is everybody doing again?  well it seems that i have run
into another problem (well i don't really know if its a problem or is it
just the way its supposed to be)

after i do the make config, and make dep zImage, and the end of it all i
get the following error: (please read past the error as well, there is
more)
make[1]: Leaving directory
`/opt/uCLinux/linux-2.4.10/arch/armnommu/nwfpe'
arm-elf-ld -p -X -T arch/armnommu/vmlinux.lds
arch/armnommu/kernel/head-armv.o a
rch/armnommu/kernel/init_task.o init/main.o init/version.o \
        --start-group \
        arch/armnommu/kernel/kernel.o arch/armnommu/mm/mm.o
arch/armnommu/mach-a
tmel/atmel.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/n
et/net.o drivers/media/media.o drivers/mtd/mtdlink.o \
        net/network.o \
        arch/armnommu/lib/lib.a /opt/uCLinux/linux-2.4.10/lib/lib.a
/usr/local/l
ib/gcc-lib/arm-elf/2.95.3/libgcc.a \
        --end-group \
        -o linux
arm-elf-nm linux | grep -v '\(compiled\)\|\(\.o$\)\|\( [aUw]
\)\|\(\.\.ng$\)\|\(
LASH[RL]DI\)' | sort > System.map
make[1]: Entering directory
`/opt/uCLinux/linux-2.4.10/arch/armnommu/boot'
make[1]: *** No rule to make target `/opt/uCLinux/linux-2.4.10/vmlinux',
needed 
by `compressed/vmlinux'.  Stop.
make[1]: Leaving directory
`/opt/uCLinux/linux-2.4.10/arch/armnommu/boot'
make: *** [zImage] Error 2

make[1]: Leaving directory
`/opt/uCLinux/linux-2.4.10/arch/armnommu/nwfpe'
arm-elf-ld -p -X -T arch/armnommu/vmlinux.lds
arch/armnommu/kernel/head-armv.o a
rch/armnommu/kernel/init_task.o init/main.o init/version.o \
        --start-group \
        arch/armnommu/kernel/kernel.o arch/armnommu/mm/mm.o
arch/armnommu/mach-a
tmel/atmel.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/n
et/net.o drivers/media/media.o drivers/mtd/mtdlink.o \
        net/network.o \
        arch/armnommu/lib/lib.a /opt/uCLinux/linux-2.4.10/lib/lib.a
/usr/local/l
ib/gcc-lib/arm-elf/2.95.3/libgcc.a \
        --end-group \
        -o linux
arm-elf-nm linux | grep -v '\(compiled\)\|\(\.o$\)\|\( [aUw]
\)\|\(\.\.ng$\)\|\(
LASH[RL]DI\)' | sort > System.map
make[1]: Entering directory
`/opt/uCLinux/linux-2.4.10/arch/armnommu/boot'
make[1]: *** No rule to make target `/opt/uCLinux/linux-2.4.10/vmlinux',
needed 
by `compressed/vmlinux'.  Stop.
make[1]: Leaving directory
`/opt/uCLinux/linux-2.4.10/arch/armnommu/boot'
make: *** [zImage] Error 2

BUT i have a uCLinux kernel ready to use...so is this okay then??? or am
i missing something?

thanks a million

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Sami Kibria
Project Leader, Bluetooth Applications
email: skibria at win.trlabs.ca
TRLabs - Winnipeg, MB, CANADA

http://www.win.trlabs.ca/~skibria

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
   __   _
  / /  (_)__  __ ____  __
 / /__/ / _ \/ // /\ \/ /  . . .  t h e   c h o i c e   o f   a
/____/_/_//_/\_,_/ /_/\_\              G N U   g e n e r a t i o n

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-


This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From skibria at win.trlabs.ca  Tue Apr 16 14:53:42 2002
From: skibria at win.trlabs.ca (Sami Kibria)
Date: 16 Apr 2002 13:53:42 -0500
Subject: [uClinux-dev] re: after kenel build
Message-ID: <1018983222.25368.137.camel@feedtheworms.win.trlabs.ca>

hello...i have a quick question here:

after i get the kernel and arm-elf tools all ready to go...what do i do
next???  do i download the kernel to flash or sram (now my kernel is
right now 702 kilobytes so i am assuming flash, but to what address???)

so do i use mimicom and gdb or do i use something else???

thanks


-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Sami Kibria
Project Leader, Bluetooth Applications
email: skibria at win.trlabs.ca
TRLabs - Winnipeg, MB, CANADA

http://www.win.trlabs.ca/~skibria

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
   __   _
  / /  (_)__  __ ____  __
 / /__/ / _ \/ // /\ \/ /  . . .  t h e   c h o i c e   o f   a
/____/_/_//_/\_,_/ /_/\_\              G N U   g e n e r a t i o n

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-


This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From Fabrice_Gautier at sdesigns.com  Tue Apr 16 17:54:14 2002
From: Fabrice_Gautier at sdesigns.com (Fabrice Gautier)
Date: Tue, 16 Apr 2002 14:54:14 -0700
Subject: [uClinux-dev] Memory zones and DMA
Message-ID: <B1F6452C89AFD411AE0800A0CC734C239DBBD0@EMAIL1>

Hi,

When my kernel try to allocate some DMA memory, it fails.

In my platfrom all the memory is dma-able and when the kernel try to
allocate a page with the GFP_DMA it looks for it in an empty zone.

I cant find where the zones are setup. And I'm not sure what I should do
regarding memory zones.

Thanks

-- 
Fabrice Gautier, 
Fabrice_Gautier at sdesigns.com
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From philip at engarts.com  Tue Apr 16 18:09:13 2002
From: philip at engarts.com (Philip Nye)
Date: Tue, 16 Apr 2002 23:09:13 +0100
Subject: [uClinux-dev] newbie problems using uCsimm4s eth0
References: <7B3538F053C06142BF0AA9DF2D764AC606C37D@MAILSRV1.aquarius.cpqd.com.br> <3CBC6892.490ECB45@schoeldgen.de>
Message-ID: <00c401c1e593$57d032a0$5801a8c0@localdomain>

> From: "Matthias Schoeldgen" <uclinux at schoeldgen.de>
>
> BTW, can anyone explain the behaviour of busybox generating a binary for
> each of the enabled commands ? When compiling the userland binaries i
> get a 'busybox' executable, a 'mount' executable, and so on, each having
> the same size of about 58kb or larger when including more busybox
> features. I always thought busybox is one executable with all the
> features built in ???

These are all hard links to the same executable - not separate files (you can
tell because they all share the same inode). Thus when
you type "mount" or whatever, the one executable can examine argv[0] to find
how it has been called and therefore what it should do.

Philip Nye

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From Subashk at ami.com  Tue Apr 16 18:34:21 2002
From: Subashk at ami.com (Subash Kalbarga)
Date: Tue, 16 Apr 2002 18:34:21 -0400
Subject: [uClinux-dev] Two copies of romfs?
Message-ID: <8CCBDD5583C50E4196F012E79439B45C620226@atl-ms1.megatrends.com>

Hi all,
 
I was wondering if there are two copies of the root filesystem which is
mounted from romfs.img ?
 
Romfs.img gets appended to the kernel.
 
After that does the kernel copy the whole thing again in ram?
 
Thanks in advance
Subash
 
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20020416/24466603/attachment.html>

From bkuhn at lineo.com  Tue Apr 16 18:52:59 2002
From: bkuhn at lineo.com (Bernhard Kuhn)
Date: Wed, 17 Apr 2002 00:52:59 +0200
Subject: [uClinux-dev] boot from flash on 5272
References: <3CBC1B10.13509.A0B3C@localhost>
Message-ID: <3CBCAB4B.6238CEC8@lineo.com>

"Enrico Benetti [BW]" schrieb:

> BFD: Warning: Writing
> section `.text' to huge (ie negative) file offset 0xffe20000.
> m68k-elf- objcopy: /opt/uClinux-dist/images/linux.bin: File
> truncated

Can you please post your rom.ld for further investigations?


> I'd like to have uClinux booting from flash directly (without
> bootloader) so I think this is the right way to proceed (changing
> jp13 setting)

For a start, i suggest to read

http://home.t-online.de/home/Bernhard_Kuhn/uclinux/Platforms/Coldfire/tarifa/20011119/README

But for making the linux kernel executable in place together with
colilo,
you will have to change a few lines in colilo and in the linker script.

best regards

Bernhard

-- 
Bernhard Kuhn, Software Engineer, Lineo Inc. (Where Open Meets Smart)
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From bkuhn at lineo.com  Tue Apr 16 18:58:47 2002
From: bkuhn at lineo.com (Bernhard Kuhn)
Date: Wed, 17 Apr 2002 00:58:47 +0200
Subject: [uClinux-dev] boot from flash on 5272 (2)
References: <3CBC1CF2.4877.1164CF@localhost>
Message-ID: <3CBCACA7.86C06F8F@lineo.com>

"Enrico Benetti [BW]" schrieb:

> Reading Kuhn mini-howto on flash device (http://home.t-
> online.de/home/Bernhard_Kuhn) I'd like to know some opinion on
> which is the best strategies to use to have a system with uClinux
> auto-boot, without removing installed dbug on motorola 5272c3
> board. There're a lot of way (with or w/outColilo, romfs, cramfs, etc).
> If I don't remove dbug, I've always only 1 Mb of flash available?

You may do a dual stage boot load, means: you first boot from
dbug, and then boot colilo from i.e. 0xffe20000-0xffe24000 and
have the kernel placed XIP in i.e. 0xffe24000 to maybe 0xfff00000,
so there is 1MB left for the filesystem. But this is just for
training purpose, because the system won't automaticaly boot
because of dbug. When using JP13, then you only have 1 MB of
flash for colilo, kernel and filesystem - this is usual not
enough for a XIP kernel + filesystem, but YMMV.

best regards

Bernhard

-- 
Bernhard Kuhn, Software Engineer, Lineo Inc. (Where Open Meets Smart)
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From davidm at snapgear.com  Tue Apr 16 19:28:03 2002
From: davidm at snapgear.com (David McCullough)
Date: Wed, 17 Apr 2002 09:28:03 +1000
Subject: [uClinux-dev] elf2flt can't find elf.h include
In-Reply-To: <579C0CAF497CD511AD4D00508BBD7AAC0246E5@pikachu.ntu.ac.uk>; from mark.howson@ntu.ac.uk on Tue, Apr 16, 2002 at 12:11:21PM +0100
References: <579C0CAF497CD511AD4D00508BBD7AAC0246E5@pikachu.ntu.ac.uk>
Message-ID: <20020417092803.B3994@beast.internal.moreton.com.au>


Jivin Howson, Mark lays it down ...
> Hi,
> 
> I'm trying to build uClinux for a Coldfire 5407 platform using the
> build-uclinux-tools.sh script. (I'm using OpenBSD 3.0, latest cvs versions
> of uClibc, elf2flt, and the 200020410 release of the 68k build tools). No
> significant problems yet, but I can't build STAGE8:
> 
> >>>
> gcc -g -O2 -DSTDC_HEADERS=1 -DHAVE_FCNTL_H=1 -DHAVE_UNISTD_H=1
> -DHAVE_BFD_H=1 -DHAVE_VPRINTF=1  -DTARGET_m68k
> -I/shares/tools/uclinux/m68k-elf-binutils/bfd -static -o elf2flt ./elf2flt.c
> /shares/tools/uclinux/m68k-elf-binutils/bfd/libbfd.a
> /shares/tools/uclinux/m68k-elf-binutils/libiberty/libiberty.a
> ./elf2flt.c:48: elf.h: No such file or directory
> gmake: *** [elf2flt] Error 1
> 
> Doing a find gives me these elf.h files to choose from:
> uClibc/include/elf.h
> uClinux-2.4.x/include/asm-m68k/elf.h
> uClinux-2.4.x/include/asm-m68knommu/elf.h
> uClinux-2.4.x/include/linux/elf.h
> uClinux-2.4.x/include/config/kcore/elf.h
> uClinux-2.4.x/include/config/binfmt/elf.h
> 
> I've tried adding the first four of these to the include file, but each of
> these gives me a different set of clashes.
> 
> Can anyone give me a clue as to what I might be doing wrong, or tell me
> which elf.h I'm supposed to be using?


Linux has a /usr/include/elf.h,  this is the one you need.  Not sure where
or if one exists on OpenBSD.  I have attached the linux one in case you get
stuck,

Cheers,
Davidm

-- 
David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
davidm at snapgear.com  Fx: +61 7 3891 3630  825 Stanley St., W'gabba QLD 4102, Oz
-------------- next part --------------
/* This file defines standard ELF types, structures, and macros.
   Copyright (C) 1995, 1996, 1997, 1998, 1999 Free Software Foundation, Inc.
   This file is part of the GNU C Library.
   Contributed by Ian Lance Taylor <ian at cygnus.com>.

   The GNU C Library is free software; you can redistribute it and/or
   modify it under the terms of the GNU Library General Public License as
   published by the Free Software Foundation; either version 2 of the
   License, or (at your option) any later version.

   The GNU C Library is distributed in the hope that it will be useful,
   but WITHOUT ANY WARRANTY; without even the implied warranty of
   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
   Library General Public License for more details.

   You should have received a copy of the GNU Library General Public
   License along with the GNU C Library; see the file COPYING.LIB.  If not,
   write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330,
   Boston, MA 02111-1307, USA.  */

#ifndef _ELF_H
#define	_ELF_H 1

#include <features.h>

__BEGIN_DECLS

/* Standard ELF types.  */

#include <stdint.h>

/* Type for a 16-bit quantity.  */
typedef uint16_t Elf32_Half;
typedef uint16_t Elf64_Half;

/* Types for signed and unsigned 32-bit quantities.  */
typedef uint32_t Elf32_Word;
typedef	int32_t  Elf32_Sword;
typedef uint32_t Elf64_Word;
typedef	int32_t  Elf64_Sword;

/* Types for signed and unsigned 64-bit quantities.  */
typedef uint64_t Elf32_Xword;
typedef	int64_t  Elf32_Sxword;
typedef uint64_t Elf64_Xword;
typedef	int64_t  Elf64_Sxword;

/* Type of addresses.  */
typedef uint32_t Elf32_Addr;
typedef uint64_t Elf64_Addr;

/* Type of file offsets.  */
typedef uint32_t Elf32_Off;
typedef uint64_t Elf64_Off;

/* Type for section indices, which are 16-bit quantities.  */
typedef uint16_t Elf32_Section;
typedef uint16_t Elf64_Section;

/* Type of symbol indices.  */
typedef uint32_t Elf32_Symndx;
typedef uint64_t Elf64_Symndx;


/* The ELF file header.  This appears at the start of every ELF file.  */

#define EI_NIDENT (16)

typedef struct
{
  unsigned char	e_ident[EI_NIDENT];	/* Magic number and other info */
  Elf32_Half	e_type;			/* Object file type */
  Elf32_Half	e_machine;		/* Architecture */
  Elf32_Word	e_version;		/* Object file version */
  Elf32_Addr	e_entry;		/* Entry point virtual address */
  Elf32_Off	e_phoff;		/* Program header table file offset */
  Elf32_Off	e_shoff;		/* Section header table file offset */
  Elf32_Word	e_flags;		/* Processor-specific flags */
  Elf32_Half	e_ehsize;		/* ELF header size in bytes */
  Elf32_Half	e_phentsize;		/* Program header table entry size */
  Elf32_Half	e_phnum;		/* Program header table entry count */
  Elf32_Half	e_shentsize;		/* Section header table entry size */
  Elf32_Half	e_shnum;		/* Section header table entry count */
  Elf32_Half	e_shstrndx;		/* Section header string table index */
} Elf32_Ehdr;

typedef struct
{
  unsigned char	e_ident[EI_NIDENT];	/* Magic number and other info */
  Elf64_Half	e_type;			/* Object file type */
  Elf64_Half	e_machine;		/* Architecture */
  Elf64_Word	e_version;		/* Object file version */
  Elf64_Addr	e_entry;		/* Entry point virtual address */
  Elf64_Off	e_phoff;		/* Program header table file offset */
  Elf64_Off	e_shoff;		/* Section header table file offset */
  Elf64_Word	e_flags;		/* Processor-specific flags */
  Elf64_Half	e_ehsize;		/* ELF header size in bytes */
  Elf64_Half	e_phentsize;		/* Program header table entry size */
  Elf64_Half	e_phnum;		/* Program header table entry count */
  Elf64_Half	e_shentsize;		/* Section header table entry size */
  Elf64_Half	e_shnum;		/* Section header table entry count */
  Elf64_Half	e_shstrndx;		/* Section header string table index */
} Elf64_Ehdr;

/* Fields in the e_ident array.  The EI_* macros are indices into the
   array.  The macros under each EI_* macro are the values the byte
   may have.  */

#define EI_MAG0		0		/* File identification byte 0 index */
#define ELFMAG0		0x7f		/* Magic number byte 0 */

#define EI_MAG1		1		/* File identification byte 1 index */
#define ELFMAG1		'E'		/* Magic number byte 1 */

#define EI_MAG2		2		/* File identification byte 2 index */
#define ELFMAG2		'L'		/* Magic number byte 2 */

#define EI_MAG3		3		/* File identification byte 3 index */
#define ELFMAG3		'F'		/* Magic number byte 3 */

/* Conglomeration of the identification bytes, for easy testing as a word.  */
#define	ELFMAG		"\177ELF"
#define	SELFMAG		4

#define EI_CLASS	4		/* File class byte index */
#define ELFCLASSNONE	0		/* Invalid class */
#define ELFCLASS32	1		/* 32-bit objects */
#define ELFCLASS64	2		/* 64-bit objects */
#define ELFCLASSNUM	3

#define EI_DATA		5		/* Data encoding byte index */
#define ELFDATANONE	0		/* Invalid data encoding */
#define ELFDATA2LSB	1		/* 2's complement, little endian */
#define ELFDATA2MSB	2		/* 2's complement, big endian */
#define ELFDATANUM	3

#define EI_VERSION	6		/* File version byte index */
					/* Value must be EV_CURRENT */

#define EI_OSABI	7		/* OS ABI identification */
#define ELFOSABI_SYSV		0	/* UNIX System V ABI */
#define ELFOSABI_HPUX		1	/* HP-UX */
#define ELFOSABI_ARM		97	/* ARM */
#define ELFOSABI_STANDALONE	255	/* Standalone (embedded) application */

#define EI_ABIVERSION	8		/* ABI version */

#define EI_PAD		9		/* Byte index of padding bytes */

/* Legal values for e_type (object file type).  */

#define ET_NONE		0		/* No file type */
#define ET_REL		1		/* Relocatable file */
#define ET_EXEC		2		/* Executable file */
#define ET_DYN		3		/* Shared object file */
#define ET_CORE		4		/* Core file */
#define	ET_NUM		5		/* Number of defined types */
#define ET_LOPROC	0xff00		/* Processor-specific */
#define ET_HIPROC	0xffff		/* Processor-specific */

/* Legal values for e_machine (architecture).  */

#define EM_NONE		 0		/* No machine */
#define EM_M32		 1		/* AT&T WE 32100 */
#define EM_SPARC	 2		/* SUN SPARC */
#define EM_386		 3		/* Intel 80386 */
#define EM_68K		 4		/* Motorola m68k family */
#define EM_88K		 5		/* Motorola m88k family */
#define EM_486		 6		/* Intel 80486 */
#define EM_860		 7		/* Intel 80860 */
#define EM_MIPS		 8		/* MIPS R3000 big-endian */
#define EM_S370		 9		/* Amdahl */
#define EM_MIPS_RS4_BE	10		/* MIPS R4000 big-endian */
#define EM_RS6000	11		/* RS6000 */

#define EM_PARISC	15		/* HPPA */
#define EM_nCUBE	16		/* nCUBE */
#define EM_VPP500	17		/* Fujitsu VPP500 */
#define EM_SPARC32PLUS	18		/* Sun's "v8plus" */
#define EM_960		19		/* Intel 80960 */
#define EM_PPC		20		/* PowerPC */

#define EM_V800		36		/* NEC V800 series */
#define EM_FR20		37		/* Fujitsu FR20 */
#define EM_RH32		38		/* TRW RH32 */
#define EM_MMA		39		/* Fujitsu MMA */
#define EM_ARM		40		/* ARM */
#define EM_FAKE_ALPHA	41		/* Digital Alpha */
#define EM_SH		42		/* Hitachi SH */
#define EM_SPARCV9	43		/* SPARC v9 64-bit */
#define EM_TRICORE	44		/* Siemens Tricore */
#define EM_ARC		45		/* Argonaut RISC Core */
#define EM_H8_300	46		/* Hitachi H8/300 */
#define EM_H8_300H	47		/* Hitachi H8/300H */
#define EM_H8S		48		/* Hitachi H8S */
#define EM_H8_500	49		/* Hitachi H8/500 */
#define EM_IA_64	50		/* Intel Merced */
#define EM_MIPS_X	51		/* Stanford MIPS-X */
#define EM_COLDFIRE	52		/* Motorola Coldfire */
#define EM_68HC12	53		/* Motorola M68HC12 */
#define EM_NUM		54

/* If it is necessary to assign new unofficial EM_* values, please
   pick large random numbers (0x8523, 0xa7f2, etc.) to minimize the
   chances of collision with official or non-GNU unofficial values.  */

#define EM_ALPHA	0x9026

/* Legal values for e_version (version).  */

#define EV_NONE		0		/* Invalid ELF version */
#define EV_CURRENT	1		/* Current version */
#define EV_NUM		2

/* Section header.  */

typedef struct
{
  Elf32_Word	sh_name;		/* Section name (string tbl index) */
  Elf32_Word	sh_type;		/* Section type */
  Elf32_Word	sh_flags;		/* Section flags */
  Elf32_Addr	sh_addr;		/* Section virtual addr at execution */
  Elf32_Off	sh_offset;		/* Section file offset */
  Elf32_Word	sh_size;		/* Section size in bytes */
  Elf32_Word	sh_link;		/* Link to another section */
  Elf32_Word	sh_info;		/* Additional section information */
  Elf32_Word	sh_addralign;		/* Section alignment */
  Elf32_Word	sh_entsize;		/* Entry size if section holds table */
} Elf32_Shdr;

typedef struct
{
  Elf64_Word	sh_name;		/* Section name (string tbl index) */
  Elf64_Word	sh_type;		/* Section type */
  Elf64_Xword	sh_flags;		/* Section flags */
  Elf64_Addr	sh_addr;		/* Section virtual addr at execution */
  Elf64_Off	sh_offset;		/* Section file offset */
  Elf64_Xword	sh_size;		/* Section size in bytes */
  Elf64_Word	sh_link;		/* Link to another section */
  Elf64_Word	sh_info;		/* Additional section information */
  Elf64_Xword	sh_addralign;		/* Section alignment */
  Elf64_Xword	sh_entsize;		/* Entry size if section holds table */
} Elf64_Shdr;

/* Special section indices.  */

#define SHN_UNDEF	0		/* Undefined section */
#define SHN_LORESERVE	0xff00		/* Start of reserved indices */
#define SHN_LOPROC	0xff00		/* Start of processor-specific */
#define SHN_HIPROC	0xff1f		/* End of processor-specific */
#define SHN_ABS		0xfff1		/* Associated symbol is absolute */
#define SHN_COMMON	0xfff2		/* Associated symbol is common */
#define SHN_HIRESERVE	0xffff		/* End of reserved indices */

/* Legal values for sh_type (section type).  */

#define SHT_NULL	 0		/* Section header table entry unused */
#define SHT_PROGBITS	 1		/* Program data */
#define SHT_SYMTAB	 2		/* Symbol table */
#define SHT_STRTAB	 3		/* String table */
#define SHT_RELA	 4		/* Relocation entries with addends */
#define SHT_HASH	 5		/* Symbol hash table */
#define SHT_DYNAMIC	 6		/* Dynamic linking information */
#define SHT_NOTE	 7		/* Notes */
#define SHT_NOBITS	 8		/* Program space with no data (bss) */
#define SHT_REL		 9		/* Relocation entries, no addends */
#define SHT_SHLIB	 10		/* Reserved */
#define SHT_DYNSYM	 11		/* Dynamic linker symbol table */
#define	SHT_NUM		 12		/* Number of defined types.  */
#define SHT_LOOS	 0x60000000	/* Start OS-specific */
#define SHT_LOSUNW	 0x6ffffffb	/* Sun-specific low bound.  */
#define SHT_SUNW_COMDAT  0x6ffffffb
#define SHT_SUNW_syminfo 0x6ffffffc
#define SHT_GNU_verdef	 0x6ffffffd	/* Version definition section.  */
#define SHT_GNU_verneed	 0x6ffffffe	/* Version needs section.  */
#define SHT_GNU_versym	 0x6fffffff	/* Version symbol table.  */
#define SHT_HISUNW	 0x6fffffff	/* Sun-specific high bound.  */
#define SHT_HIOS	 0x6fffffff	/* End OS-specific type */
#define SHT_LOPROC	 0x70000000	/* Start of processor-specific */
#define SHT_HIPROC	 0x7fffffff	/* End of processor-specific */
#define SHT_LOUSER	 0x80000000	/* Start of application-specific */
#define SHT_HIUSER	 0x8fffffff	/* End of application-specific */

/* Legal values for sh_flags (section flags).  */

#define SHF_WRITE	(1 << 0)	/* Writable */
#define SHF_ALLOC	(1 << 1)	/* Occupies memory during execution */
#define SHF_EXECINSTR	(1 << 2)	/* Executable */
#define SHF_MASKPROC	0xf0000000	/* Processor-specific */

/* Symbol table entry.  */

typedef struct
{
  Elf32_Word	st_name;		/* Symbol name (string tbl index) */
  Elf32_Addr	st_value;		/* Symbol value */
  Elf32_Word	st_size;		/* Symbol size */
  unsigned char	st_info;		/* Symbol type and binding */
  unsigned char	st_other;		/* No defined meaning, 0 */
  Elf32_Section	st_shndx;		/* Section index */
} Elf32_Sym;

typedef struct
{
  Elf64_Word	st_name;		/* Symbol name (string tbl index) */
  unsigned char	st_info;		/* Symbol type and binding */
  unsigned char st_other;		/* No defined meaning, 0 */
  Elf64_Section	st_shndx;		/* Section index */
  Elf64_Addr	st_value;		/* Symbol value */
  Elf64_Xword	st_size;		/* Symbol size */
} Elf64_Sym;

/* The syminfo section if available contains additional information about
   every dynamic symbol.  */

typedef struct
{
  Elf32_Half si_boundto;		/* Direct bindings, symbol bound to */
  Elf32_Half si_flags;			/* Per symbol flags */
} Elf32_Syminfo;

typedef struct
{
  Elf64_Half si_boundto;		/* Direct bindings, symbol bound to */
  Elf64_Half si_flags;			/* Per symbol flags */
} Elf64_Syminfo;

/* Possible values for si_boundto.  */
#define SYMINFO_BT_SELF		0xffff	/* Symbol bound to self */
#define SYMINFO_BT_PARENT	0xfffe	/* Symbol bound to parent */
#define SYMINFO_BT_LOWRESERVE	0xff00	/* Beginning of reserved entries */

/* Possible bitmasks for si_flags.  */
#define SYMINFO_FLG_DIRECT	0x0001	/* Direct bound symbol */
#define SYMINFO_FLG_PASSTHRU	0x0002	/* Pass-thru symbol for translator */
#define SYMINFO_FLG_COPY	0x0004	/* Symbol is a copy-reloc */
#define SYMINFO_FLG_LAZYLOAD	0x0008	/* Symbol bound to object to be lazy
					   loaded */
/* Syminfo version values.  */
#define SYMINFO_NONE		0
#define SYMINFO_CURRENT		1
#define SYMINFO_NUM		2


/* Special section index.  */

#define SHN_UNDEF	0		/* No section, undefined symbol.  */

/* How to extract and insert information held in the st_info field.  */

#define ELF32_ST_BIND(val)		(((unsigned char) (val)) >> 4)
#define ELF32_ST_TYPE(val)		((val) & 0xf)
#define ELF32_ST_INFO(bind, type)	(((bind) << 4) + ((type) & 0xf))

/* Both Elf32_Sym and Elf64_Sym use the same one-byte st_info field.  */
#define ELF64_ST_BIND(val)		ELF32_ST_BIND (val)
#define ELF64_ST_TYPE(val)		ELF32_ST_TYPE (val)
#define ELF64_ST_INFO(bind, type)	ELF32_ST_INFO ((bind), (type))

/* Legal values for ST_BIND subfield of st_info (symbol binding).  */

#define STB_LOCAL	0		/* Local symbol */
#define STB_GLOBAL	1		/* Global symbol */
#define STB_WEAK	2		/* Weak symbol */
#define	STB_NUM		3		/* Number of defined types.  */
#define STB_LOOS	10		/* Start of OS-specific */
#define STB_HIOS	12		/* End of OS-specific */
#define STB_LOPROC	13		/* Start of processor-specific */
#define STB_HIPROC	15		/* End of processor-specific */

/* Legal values for ST_TYPE subfield of st_info (symbol type).  */

#define STT_NOTYPE	0		/* Symbol type is unspecified */
#define STT_OBJECT	1		/* Symbol is a data object */
#define STT_FUNC	2		/* Symbol is a code object */
#define STT_SECTION	3		/* Symbol associated with a section */
#define STT_FILE	4		/* Symbol's name is file name */
#define	STT_NUM		5		/* Number of defined types.  */
#define STT_LOOS	11		/* Start of OS-specific */
#define STT_HIOS	12		/* End of OS-specific */
#define STT_LOPROC	13		/* Start of processor-specific */
#define STT_HIPROC	15		/* End of processor-specific */


/* Symbol table indices are found in the hash buckets and chain table
   of a symbol hash table section.  This special index value indicates
   the end of a chain, meaning no further symbols are found in that bucket.  */

#define STN_UNDEF	0		/* End of a chain.  */


/* Relocation table entry without addend (in section of type SHT_REL).  */

typedef struct
{
  Elf32_Addr	r_offset;		/* Address */
  Elf32_Word	r_info;			/* Relocation type and symbol index */
} Elf32_Rel;

/* I have seen two different definitions of the Elf64_Rel and
   Elf64_Rela structures, so we'll leave them out until Novell (or
   whoever) gets their act together.  */
/* The following, at least, is used on Sparc v9, MIPS, and Alpha.  */

typedef struct
{
  Elf64_Addr	r_offset;		/* Address */
  Elf64_Xword	r_info;			/* Relocation type and symbol index */
} Elf64_Rel;

/* Relocation table entry with addend (in section of type SHT_RELA).  */

typedef struct
{
  Elf32_Addr	r_offset;		/* Address */
  Elf32_Word	r_info;			/* Relocation type and symbol index */
  Elf32_Sword	r_addend;		/* Addend */
} Elf32_Rela;

typedef struct
{
  Elf64_Addr	r_offset;		/* Address */
  Elf64_Xword	r_info;			/* Relocation type and symbol index */
  Elf64_Sxword	r_addend;		/* Addend */
} Elf64_Rela;

/* How to extract and insert information held in the r_info field.  */

#define ELF32_R_SYM(val)		((val) >> 8)
#define ELF32_R_TYPE(val)		((val) & 0xff)
#define ELF32_R_INFO(sym, type)		(((sym) << 8) + ((type) & 0xff))

#define ELF64_R_SYM(i)			((i) >> 32)
#define ELF64_R_TYPE(i)			((i) & 0xffffffff)
#define ELF64_R_INFO(sym,type)		(((sym) << 32) + (type))

/* Program segment header.  */

typedef struct
{
  Elf32_Word	p_type;			/* Segment type */
  Elf32_Off	p_offset;		/* Segment file offset */
  Elf32_Addr	p_vaddr;		/* Segment virtual address */
  Elf32_Addr	p_paddr;		/* Segment physical address */
  Elf32_Word	p_filesz;		/* Segment size in file */
  Elf32_Word	p_memsz;		/* Segment size in memory */
  Elf32_Word	p_flags;		/* Segment flags */
  Elf32_Word	p_align;		/* Segment alignment */
} Elf32_Phdr;

typedef struct
{
  Elf64_Word	p_type;			/* Segment type */
  Elf64_Word	p_flags;		/* Segment flags */
  Elf64_Off	p_offset;		/* Segment file offset */
  Elf64_Addr	p_vaddr;		/* Segment virtual address */
  Elf64_Addr	p_paddr;		/* Segment physical address */
  Elf64_Xword	p_filesz;		/* Segment size in file */
  Elf64_Xword	p_memsz;		/* Segment size in memory */
  Elf64_Xword	p_align;		/* Segment alignment */
} Elf64_Phdr;

/* Legal values for p_type (segment type).  */

#define	PT_NULL		0		/* Program header table entry unused */
#define PT_LOAD		1		/* Loadable program segment */
#define PT_DYNAMIC	2		/* Dynamic linking information */
#define PT_INTERP	3		/* Program interpreter */
#define PT_NOTE		4		/* Auxiliary information */
#define PT_SHLIB	5		/* Reserved */
#define PT_PHDR		6		/* Entry for header table itself */
#define	PT_NUM		7		/* Number of defined types.  */
#define PT_LOOS		0x60000000	/* Start of OS-specific */
#define PT_HIOS		0x6fffffff	/* End of OS-specific */
#define PT_LOPROC	0x70000000	/* Start of processor-specific */
#define PT_HIPROC	0x7fffffff	/* End of processor-specific */

/* Legal values for p_flags (segment flags).  */

#define PF_X		(1 << 0)	/* Segment is executable */
#define PF_W		(1 << 1)	/* Segment is writable */
#define PF_R		(1 << 2)	/* Segment is readable */
#define PF_MASKPROC	0xf0000000	/* Processor-specific */

/* Legal values for note segment descriptor types for core files. */

#define NT_PRSTATUS	1		/* Contains copy of prstatus struct */
#define NT_FPREGSET	2		/* Contains copy of fpregset struct */
#define NT_PRPSINFO	3		/* Contains copy of prpsinfo struct */
#define NT_PRXREG	4		/* Contains copy of prxregset struct */
#define NT_PLATFORM	5		/* String from sysinfo(SI_PLATFORM) */
#define NT_AUXV		6		/* Contains copy of auxv array */
#define NT_GWINDOWS	7		/* Contains copy of gwindows struct */
#define NT_PSTATUS	10		/* Contains copy of pstatus struct */
#define NT_PSINFO	13		/* Contains copy of psinfo struct */
#define NT_PRCRED	14		/* Contains copy of prcred struct */
#define NT_UTSNAME	15		/* Contains copy of utsname struct */
#define NT_LWPSTATUS	16		/* Contains copy of lwpstatus struct */
#define NT_LWPSINFO	17		/* Contains copy of lwpinfo struct */

/* Legal values for the  note segment descriptor types for object files.  */

#define NT_VERSION	1		/* Contains a version string.  */


/* Dynamic section entry.  */

typedef struct
{
  Elf32_Sword	d_tag;			/* Dynamic entry type */
  union
    {
      Elf32_Word d_val;			/* Integer value */
      Elf32_Addr d_ptr;			/* Address value */
    } d_un;
} Elf32_Dyn;

typedef struct
{
  Elf64_Sxword	d_tag;			/* Dynamic entry type */
  union
    {
      Elf64_Xword d_val;		/* Integer value */
      Elf64_Addr d_ptr;			/* Address value */
    } d_un;
} Elf64_Dyn;

/* Legal values for d_tag (dynamic entry type).  */

#define DT_NULL		0		/* Marks end of dynamic section */
#define DT_NEEDED	1		/* Name of needed library */
#define DT_PLTRELSZ	2		/* Size in bytes of PLT relocs */
#define DT_PLTGOT	3		/* Processor defined value */
#define DT_HASH		4		/* Address of symbol hash table */
#define DT_STRTAB	5		/* Address of string table */
#define DT_SYMTAB	6		/* Address of symbol table */
#define DT_RELA		7		/* Address of Rela relocs */
#define DT_RELASZ	8		/* Total size of Rela relocs */
#define DT_RELAENT	9		/* Size of one Rela reloc */
#define DT_STRSZ	10		/* Size of string table */
#define DT_SYMENT	11		/* Size of one symbol table entry */
#define DT_INIT		12		/* Address of init function */
#define DT_FINI		13		/* Address of termination function */
#define DT_SONAME	14		/* Name of shared object */
#define DT_RPATH	15		/* Library search path */
#define DT_SYMBOLIC	16		/* Start symbol search here */
#define DT_REL		17		/* Address of Rel relocs */
#define DT_RELSZ	18		/* Total size of Rel relocs */
#define DT_RELENT	19		/* Size of one Rel reloc */
#define DT_PLTREL	20		/* Type of reloc in PLT */
#define DT_DEBUG	21		/* For debugging; unspecified */
#define DT_TEXTREL	22		/* Reloc might modify .text */
#define DT_JMPREL	23		/* Address of PLT relocs */
#define	DT_BIND_NOW	24		/* Process relocations of object */
#define	DT_INIT_ARRAY	25		/* Array with addresses of init fct */
#define	DT_FINI_ARRAY	26		/* Array with addresses of fini fct */
#define	DT_INIT_ARRAYSZ	27		/* Size in bytes of DT_INIT_ARRAY */
#define	DT_FINI_ARRAYSZ	28		/* Size in bytes of DT_FINI_ARRAY */
#define	DT_NUM		29		/* Number used */
#define DT_LOOS		0x60000000	/* Start of OS-specific */
#define DT_HIOS		0x6fffffff	/* End of OS-specific */
#define DT_LOPROC	0x70000000	/* Start of processor-specific */
#define DT_HIPROC	0x7fffffff	/* End of processor-specific */
#define	DT_PROCNUM	DT_MIPS_NUM	/* Most used by any processor */

/* DT_* entries which fall between DT_VALRNGHI & DT_VALRNGLO use the
   Dyn.d_un.d_val field of the Elf*_Dyn structure.  This follows Sun's
   approach.  */
#define DT_VALRNGLO	0x6ffffd00
#define DT_POSFLAG_1	0x6ffffdfd	/* Flags for DT_* entries, effecting
					   the following DT_* entry.  */
#define DT_SYMINSZ	0x6ffffdfe	/* Size of syminfo table (in bytes) */
#define DT_SYMINENT	0x6ffffdff	/* Entry size of syminfo */
#define DT_VALRNGHI	0x6ffffdff

/* DT_* entries which fall between DT_ADDRRNGHI & DT_ADDRRNGLO use the
   Dyn.d_un.d_ptr field of the Elf*_Dyn structure.

   If any adjustment is made to the ELF object after it has been
   built these entries will need to be adjusted.  */
#define DT_ADDRRNGLO	0x6ffffe00
#define DT_SYMINFO	0x6ffffeff	/* syminfo table */
#define DT_ADDRRNGHI	0x6ffffeff

/* The versioning entry types.  The next are defined as part of the
   GNU extension.  */
#define DT_VERSYM	0x6ffffff0

/* These were chosen by Sun.  */
#define DT_FLAGS_1	0x6ffffffb	/* State flags, see DF_1_* below.  */
#define	DT_VERDEF	0x6ffffffc	/* Address of version definition
					   table */
#define	DT_VERDEFNUM	0x6ffffffd	/* Number of version definitions */
#define	DT_VERNEED	0x6ffffffe	/* Address of table with needed
					   versions */
#define	DT_VERNEEDNUM	0x6fffffff	/* Number of needed versions */
#define DT_VERSIONTAGIDX(tag)	(DT_VERNEEDNUM - (tag))	/* Reverse order! */
#define DT_VERSIONTAGNUM 16

/* Sun added these machine-independent extensions in the "processor-specific"
   range.  Be compatible.  */
#define DT_AUXILIARY    0x7ffffffd      /* Shared object to load before self */
#define DT_FILTER       0x7fffffff      /* Shared object to get values from */
#define DT_EXTRATAGIDX(tag)	((Elf32_Word)-((Elf32_Sword) (tag) <<1>>1)-1)
#define DT_EXTRANUM	3

/* State flags selectable in the `d_un.d_val' element of the DT_FLAGS_1
   entry in the dynamic section.  */
#define DF_1_NOW	0x00000001	/* Set RTLD_NOW for this object.  */
#define DF_1_GLOBAL	0x00000002	/* Set RTLD_GLOBAL for this object.  */
#define DF_1_GROUP	0x00000004	/* Set RTLD_GROUP for this object.  */
#define DF_1_NODELETE	0x00000008	/* Set RTLD_NODELETE for this object.*/
#define DF_1_LOADFLTR	0x00000010	/* Trigger filtee loading at runtime.*/
#define DF_1_INITFIRST	0x00000020	/* Set RTLD_INITFIRST for this object*/
#define DF_1_NOOPEN	0x00000040	/* Set RTLD_NOOPEN for this object.  */

/* Version definition sections.  */

typedef struct
{
  Elf32_Half	vd_version;		/* Version revision */
  Elf32_Half	vd_flags;		/* Version information */
  Elf32_Half	vd_ndx;			/* Version Index */
  Elf32_Half	vd_cnt;			/* Number of associated aux entries */
  Elf32_Word	vd_hash;		/* Version name hash value */
  Elf32_Word	vd_aux;			/* Offset in bytes to verdaux array */
  Elf32_Word	vd_next;		/* Offset in bytes to next verdef
					   entry */
} Elf32_Verdef;

typedef struct
{
  Elf64_Half	vd_version;		/* Version revision */
  Elf64_Half	vd_flags;		/* Version information */
  Elf64_Half	vd_ndx;			/* Version Index */
  Elf64_Half	vd_cnt;			/* Number of associated aux entries */
  Elf64_Word	vd_hash;		/* Version name hash value */
  Elf64_Word	vd_aux;			/* Offset in bytes to verdaux array */
  Elf64_Word	vd_next;		/* Offset in bytes to next verdef
					   entry */
} Elf64_Verdef;


/* Legal values for vd_version (version revision).  */
#define VER_DEF_NONE	0		/* No version */
#define VER_DEF_CURRENT	1		/* Current version */
#define VER_DEF_NUM	2		/* Given version number */

/* Legal values for vd_flags (version information flags).  */
#define VER_FLG_BASE	0x1		/* Version definition of file itself */
#define VER_FLG_WEAK	0x2		/* Weak version identifier */

/* Auxialiary version information.  */

typedef struct
{
  Elf32_Word	vda_name;		/* Version or dependency names */
  Elf32_Word	vda_next;		/* Offset in bytes to next verdaux
					   entry */
} Elf32_Verdaux;

typedef struct
{
  Elf64_Word	vda_name;		/* Version or dependency names */
  Elf64_Word	vda_next;		/* Offset in bytes to next verdaux
					   entry */
} Elf64_Verdaux;


/* Version dependency section.  */

typedef struct
{
  Elf32_Half	vn_version;		/* Version of structure */
  Elf32_Half	vn_cnt;			/* Number of associated aux entries */
  Elf32_Word	vn_file;		/* Offset of filename for this
					   dependency */
  Elf32_Word	vn_aux;			/* Offset in bytes to vernaux array */
  Elf32_Word	vn_next;		/* Offset in bytes to next verneed
					   entry */
} Elf32_Verneed;

typedef struct
{
  Elf64_Half	vn_version;		/* Version of structure */
  Elf64_Half	vn_cnt;			/* Number of associated aux entries */
  Elf64_Word	vn_file;		/* Offset of filename for this
					   dependency */
  Elf64_Word	vn_aux;			/* Offset in bytes to vernaux array */
  Elf64_Word	vn_next;		/* Offset in bytes to next verneed
					   entry */
} Elf64_Verneed;


/* Legal values for vn_version (version revision).  */
#define VER_NEED_NONE	 0		/* No version */
#define VER_NEED_CURRENT 1		/* Current version */
#define VER_NEED_NUM	 2		/* Given version number */

/* Auxiliary needed version information.  */

typedef struct
{
  Elf32_Word	vna_hash;		/* Hash value of dependency name */
  Elf32_Half	vna_flags;		/* Dependency specific information */
  Elf32_Half	vna_other;		/* Unused */
  Elf32_Word	vna_name;		/* Dependency name string offset */
  Elf32_Word	vna_next;		/* Offset in bytes to next vernaux
					   entry */
} Elf32_Vernaux;

typedef struct
{
  Elf64_Word	vna_hash;		/* Hash value of dependency name */
  Elf64_Half	vna_flags;		/* Dependency specific information */
  Elf64_Half	vna_other;		/* Unused */
  Elf64_Word	vna_name;		/* Dependency name string offset */
  Elf64_Word	vna_next;		/* Offset in bytes to next vernaux
					   entry */
} Elf64_Vernaux;


/* Legal values for vna_flags.  */
#define VER_FLG_WEAK	0x2		/* Weak version identifier */


/* Auxiliary vector.  */

/* This vector is normally only used by the program interpreter.  The
   usual definition in an ABI supplement uses the name auxv_t.  The
   vector is not usually defined in a standard <elf.h> file, but it
   can't hurt.  We rename it to avoid conflicts.  The sizes of these
   types are an arrangement between the exec server and the program
   interpreter, so we don't fully specify them here.  */

typedef struct
{
  int a_type;			/* Entry type */
  union
    {
      long int a_val;		/* Integer value */
      void *a_ptr;		/* Pointer value */
      void (*a_fcn) (void);	/* Function pointer value */
    } a_un;
} Elf32_auxv_t;

typedef struct
{
  long int a_type;		/* Entry type */
  union
    {
      long int a_val;		/* Integer value */
      void *a_ptr;		/* Pointer value */
      void (*a_fcn) (void);	/* Function pointer value */
    } a_un;
} Elf64_auxv_t;

/* Legal values for a_type (entry type).  */

#define AT_NULL		0		/* End of vector */
#define AT_IGNORE	1		/* Entry should be ignored */
#define AT_EXECFD	2		/* File descriptor of program */
#define AT_PHDR		3		/* Program headers for program */
#define AT_PHENT	4		/* Size of program header entry */
#define AT_PHNUM	5		/* Number of program headers */
#define AT_PAGESZ	6		/* System page size */
#define AT_BASE		7		/* Base address of interpreter */
#define AT_FLAGS	8		/* Flags */
#define AT_ENTRY	9		/* Entry point of program */
#define AT_NOTELF	10		/* Program is not ELF */
#define AT_UID		11		/* Real uid */
#define AT_EUID		12		/* Effective uid */
#define AT_GID		13		/* Real gid */
#define AT_EGID		14		/* Effective gid */

/* Some more special a_type values describing the hardware.  */
#define AT_PLATFORM	15		/* String identifying platform.  */
#define AT_HWCAP	16		/* Machine dependent hints about
					   processor capabilities.  */

/* This entry gives some information about the FPU initialization
   performed by the kernel.  */
#define AT_FPUCW	17		/* Used FPU control word.  */


/* Note section contents.  Each entry in the note section begins with
   a header of a fixed form.  */

typedef struct
{
  Elf32_Word n_namesz;			/* Length of the note's name.  */
  Elf32_Word n_descsz;			/* Length of the note's descriptor.  */
  Elf32_Word n_type;			/* Type of the note.  */
} Elf32_Nhdr;

typedef struct
{
  Elf64_Word n_namesz;			/* Length of the note's name.  */
  Elf64_Word n_descsz;			/* Length of the note's descriptor.  */
  Elf64_Word n_type;			/* Type of the note.  */
} Elf64_Nhdr;

/* Known names of notes.  */

/* Solaris entries in the note section have this name.  */
#define ELF_NOTE_SOLARIS	"SUNW Solaris"

/* Note entries for GNU systems have this name.  */
#define ELF_NOTE_GNU		"GNU"


/* Defined types of notes for Solaris.  */

/* Value of descriptor (one word) is desired pagesize for the binary.  */
#define ELF_NOTE_PAGESIZE_HINT	1


/* Defined note types for GNU systems.  */

/* ABI information.  The descriptor consists of words:
   word 0: OS descriptor
   word 1: major version of the ABI
   word 2: minor version of the ABI
   word 3: subminor version of the ABI
*/
#define ELF_NOTE_ABI		1

/* Known OSes.  These value can appear in word 0 of an ELF_NOTE_ABI
   note section entry.  */
#define ELF_NOTE_OS_LINUX	0
#define ELF_NOTE_OS_GNU		1
#define ELF_NOTE_OS_SOLARIS2	2


/* Motorola 68k specific definitions.  */

/* m68k relocs.  */

#define R_68K_NONE	0		/* No reloc */
#define R_68K_32	1		/* Direct 32 bit  */
#define R_68K_16	2		/* Direct 16 bit  */
#define R_68K_8		3		/* Direct 8 bit  */
#define R_68K_PC32	4		/* PC relative 32 bit */
#define R_68K_PC16	5		/* PC relative 16 bit */
#define R_68K_PC8	6		/* PC relative 8 bit */
#define R_68K_GOT32	7		/* 32 bit PC relative GOT entry */
#define R_68K_GOT16	8		/* 16 bit PC relative GOT entry */
#define R_68K_GOT8	9		/* 8 bit PC relative GOT entry */
#define R_68K_GOT32O	10		/* 32 bit GOT offset */
#define R_68K_GOT16O	11		/* 16 bit GOT offset */
#define R_68K_GOT8O	12		/* 8 bit GOT offset */
#define R_68K_PLT32	13		/* 32 bit PC relative PLT address */
#define R_68K_PLT16	14		/* 16 bit PC relative PLT address */
#define R_68K_PLT8	15		/* 8 bit PC relative PLT address */
#define R_68K_PLT32O	16		/* 32 bit PLT offset */
#define R_68K_PLT16O	17		/* 16 bit PLT offset */
#define R_68K_PLT8O	18		/* 8 bit PLT offset */
#define R_68K_COPY	19		/* Copy symbol at runtime */
#define R_68K_GLOB_DAT	20		/* Create GOT entry */
#define R_68K_JMP_SLOT	21		/* Create PLT entry */
#define R_68K_RELATIVE	22		/* Adjust by program base */
/* Keep this the last entry.  */
#define R_68K_NUM	23

/* Intel 80386 specific definitions.  */

/* i386 relocs.  */

#define R_386_NONE	0		/* No reloc */
#define R_386_32	1		/* Direct 32 bit  */
#define R_386_PC32	2		/* PC relative 32 bit */
#define R_386_GOT32	3		/* 32 bit GOT entry */
#define R_386_PLT32	4		/* 32 bit PLT address */
#define R_386_COPY	5		/* Copy symbol at runtime */
#define R_386_GLOB_DAT	6		/* Create GOT entry */
#define R_386_JMP_SLOT	7		/* Create PLT entry */
#define R_386_RELATIVE	8		/* Adjust by program base */
#define R_386_GOTOFF	9		/* 32 bit offset to GOT */
#define R_386_GOTPC	10		/* 32 bit PC relative offset to GOT */
/* Keep this the last entry.  */
#define R_386_NUM	11

/* SUN SPARC specific definitions.  */

/* Values for Elf64_Ehdr.e_flags.  */

#define EF_SPARCV9_MM		3
#define EF_SPARCV9_TSO		0
#define EF_SPARCV9_PSO		1
#define EF_SPARCV9_RMO		2
#define EF_SPARC_EXT_MASK	0xFFFF00
#define EF_SPARC_SUN_US1	0x000200
#define EF_SPARC_HAL_R1		0x000400

/* SPARC relocs.  */

#define R_SPARC_NONE	0		/* No reloc */
#define R_SPARC_8	1		/* Direct 8 bit */
#define R_SPARC_16	2		/* Direct 16 bit */
#define R_SPARC_32	3		/* Direct 32 bit */
#define R_SPARC_DISP8	4		/* PC relative 8 bit */
#define R_SPARC_DISP16	5		/* PC relative 16 bit */
#define R_SPARC_DISP32	6		/* PC relative 32 bit */
#define R_SPARC_WDISP30	7		/* PC relative 30 bit shifted */
#define R_SPARC_WDISP22	8		/* PC relative 22 bit shifted */
#define R_SPARC_HI22	9		/* High 22 bit */
#define R_SPARC_22	10		/* Direct 22 bit */
#define R_SPARC_13	11		/* Direct 13 bit */
#define R_SPARC_LO10	12		/* Truncated 10 bit */
#define R_SPARC_GOT10	13		/* Truncated 10 bit GOT entry */
#define R_SPARC_GOT13	14		/* 13 bit GOT entry */
#define R_SPARC_GOT22	15		/* 22 bit GOT entry shifted */
#define R_SPARC_PC10	16		/* PC relative 10 bit truncated */
#define R_SPARC_PC22	17		/* PC relative 22 bit shifted */
#define R_SPARC_WPLT30	18		/* 30 bit PC relative PLT address */
#define R_SPARC_COPY	19		/* Copy symbol at runtime */
#define R_SPARC_GLOB_DAT 20		/* Create GOT entry */
#define R_SPARC_JMP_SLOT 21		/* Create PLT entry */
#define R_SPARC_RELATIVE 22		/* Adjust by program base */
#define R_SPARC_UA32	23		/* Direct 32 bit unaligned */

/* Additional Sparc64 relocs.  */

#define R_SPARC_PLT32	24		/* Direct 32 bit ref to PLT entry */
#define R_SPARC_HIPLT22	25		/* High 22 bit PLT entry */
#define R_SPARC_LOPLT10	26		/* Truncated 10 bit PLT entry */
#define R_SPARC_PCPLT32	27		/* PC rel 32 bit ref to PLT entry */
#define R_SPARC_PCPLT22	28		/* PC rel high 22 bit PLT entry */
#define R_SPARC_PCPLT10	29		/* PC rel trunc 10 bit PLT entry */
#define R_SPARC_10	30		/* Direct 10 bit */
#define R_SPARC_11	31		/* Direct 11 bit */
#define R_SPARC_64	32		/* Direct 64 bit */
#define R_SPARC_OLO10	33		/* ?? */
#define R_SPARC_HH22	34		/* Top 22 bits of direct 64 bit */
#define R_SPARC_HM10	35		/* High middle 10 bits of ... */
#define R_SPARC_LM22	36		/* Low middle 22 bits of ... */
#define R_SPARC_PC_HH22	37		/* Top 22 bits of pc rel 64 bit */
#define R_SPARC_PC_HM10	38		/* High middle 10 bit of ... */
#define R_SPARC_PC_LM22	39		/* Low miggle 22 bits of ... */
#define R_SPARC_WDISP16	40		/* PC relative 16 bit shifted */
#define R_SPARC_WDISP19	41		/* PC relative 19 bit shifted */
#define R_SPARC_7	43		/* Direct 7 bit */
#define R_SPARC_5	44		/* Direct 5 bit */
#define R_SPARC_6	45		/* Direct 6 bit */
#define R_SPARC_DISP64	46		/* PC relative 64 bit */
#define R_SPARC_PLT64	47		/* Direct 64 bit ref to PLT entry */
#define R_SPARC_HIX22	48		/* High 22 bit complemented */
#define R_SPARC_LOX10	49		/* Truncated 11 bit complemented */
#define R_SPARC_H44	50		/* Direct high 12 of 44 bit */
#define R_SPARC_M44	51		/* Direct mid 22 of 44 bit */
#define R_SPARC_L44	52		/* Direct low 10 of 44 bit */
#define R_SPARC_REGISTER 53		/* Global register usage */
#define R_SPARC_UA64	54		/* Direct 64 bit unaligned */
#define R_SPARC_UA16	55		/* Direct 16 bit unaligned */
/* Keep this the last entry.  */
#define R_SPARC_NUM	56

/* For Sparc64, legal values for d_tag of Elf64_Dyn.  */

#define DT_SPARC_REGISTER 0x70000001
#define DT_SPARC_NUM	2

/* Bits present in AT_HWCAP, primarily for Sparc32.  */

#define HWCAP_SPARC_FLUSH	1	/* The cpu supports flush insn.  */
#define HWCAP_SPARC_STBAR	2
#define HWCAP_SPARC_SWAP	4
#define HWCAP_SPARC_MULDIV	8
#define HWCAP_SPARC_V9		16	/* The cpu is v9, so v8plus is ok.  */

/* MIPS R3000 specific definitions.  */

/* Legal values for e_flags field of Elf32_Ehdr.  */

#define EF_MIPS_NOREORDER   1		/* A .noreorder directive was used */
#define EF_MIPS_PIC	    2		/* Contains PIC code */
#define EF_MIPS_CPIC	    4		/* Uses PIC calling sequence */
#define EF_MIPS_XGOT	    8
#define EF_MIPS_64BIT_WHIRL 16
#define EF_MIPS_ABI2	    32
#define EF_MIPS_ABI_ON32    64
#define EF_MIPS_ARCH	    0xf0000000	/* MIPS architecture level */

/* Legal values for MIPS architecture level.  */

#define EF_MIPS_ARCH_1	    0x00000000	/* -mips1 code.  */
#define EF_MIPS_ARCH_2	    0x10000000	/* -mips2 code.  */
#define EF_MIPS_ARCH_3	    0x20000000	/* -mips3 code.  */
#define EF_MIPS_ARCH_4	    0x30000000	/* -mips4 code.  */
#define EF_MIPS_ARCH_5	    0x40000000	/* -mips5 code.  */

/* The following are non-official names and should not be used.  */

#define E_MIPS_ARCH_1	  0x00000000	/* -mips1 code.  */
#define E_MIPS_ARCH_2	  0x10000000	/* -mips2 code.  */
#define E_MIPS_ARCH_3	  0x20000000	/* -mips3 code.  */
#define E_MIPS_ARCH_4	  0x30000000	/* -mips4 code.  */
#define E_MIPS_ARCH_5	  0x40000000	/* -mips5 code.  */

/* Special section indices.  */

#define SHN_MIPS_ACOMMON 0xff00		/* Allocated common symbols */
#define SHN_MIPS_TEXT	 0xff01		/* Allocated test symbols.  */
#define SHN_MIPS_DATA	 0xff02		/* Allocated data symbols.  */
#define SHN_MIPS_SCOMMON 0xff03		/* Small common symbols */
#define SHN_MIPS_SUNDEFINED 0xff04	/* Small undefined symbols */

/* Legal values for sh_type field of Elf32_Shdr.  */

#define SHT_MIPS_LIBLIST       0x70000000 /* Shared objects used in link */
#define SHT_MIPS_MSYM	       0x70000001
#define SHT_MIPS_CONFLICT      0x70000002 /* Conflicting symbols */
#define SHT_MIPS_GPTAB	       0x70000003 /* Global data area sizes */
#define SHT_MIPS_UCODE	       0x70000004 /* Reserved for SGI/MIPS compilers */
#define SHT_MIPS_DEBUG	       0x70000005 /* MIPS ECOFF debugging information*/
#define SHT_MIPS_REGINFO       0x70000006 /* Register usage information */
#define SHT_MIPS_PACKAGE       0x70000007
#define SHT_MIPS_PACKSYM       0x70000008
#define SHT_MIPS_RELD	       0x70000009
#define SHT_MIPS_IFACE         0x7000000b
#define SHT_MIPS_CONTENT       0x7000000c
#define SHT_MIPS_OPTIONS       0x7000000d /* Miscellaneous options.  */
#define SHT_MIPS_SHDR	       0x70000010
#define SHT_MIPS_FDESC	       0x70000011
#define SHT_MIPS_EXTSYM	       0x70000012
#define SHT_MIPS_DENSE	       0x70000013
#define SHT_MIPS_PDESC	       0x70000014
#define SHT_MIPS_LOCSYM	       0x70000015
#define SHT_MIPS_AUXSYM	       0x70000016
#define SHT_MIPS_OPTSYM	       0x70000017
#define SHT_MIPS_LOCSTR	       0x70000018
#define SHT_MIPS_LINE	       0x70000019
#define SHT_MIPS_RFDESC	       0x7000001a
#define SHT_MIPS_DELTASYM      0x7000001b
#define SHT_MIPS_DELTAINST     0x7000001c
#define SHT_MIPS_DELTACLASS    0x7000001d
#define SHT_MIPS_DWARF         0x7000001e /* DWARF debugging information.  */
#define SHT_MIPS_DELTADECL     0x7000001f
#define SHT_MIPS_SYMBOL_LIB    0x70000020
#define SHT_MIPS_EVENTS	       0x70000021 /* Event section.  */
#define SHT_MIPS_TRANSLATE     0x70000022
#define SHT_MIPS_PIXIE	       0x70000023
#define SHT_MIPS_XLATE	       0x70000024
#define SHT_MIPS_XLATE_DEBUG   0x70000025
#define SHT_MIPS_WHIRL	       0x70000026
#define SHT_MIPS_EH_REGION     0x70000027
#define SHT_MIPS_XLATE_OLD     0x70000028
#define SHT_MIPS_PDR_EXCEPTION 0x70000029

/* Legal values for sh_flags field of Elf32_Shdr.  */

#define SHF_MIPS_GPREL	 0x10000000	/* Must be part of global data area */
#define SHF_MIPS_MERGE	 0x20000000
#define SHF_MIPS_ADDR	 0x40000000
#define SHF_MIPS_STRINGS 0x80000000
#define SHF_MIPS_NOSTRIP 0x08000000
#define SHF_MIPS_LOCAL	 0x04000000
#define SHF_MIPS_NAMES	 0x02000000
#define SHF_MIPS_NODUPE	 0x01000000


/* Symbol tables.  */

/* MIPS specific values for `st_other'.  */
#define STO_MIPS_DEFAULT		0x0
#define STO_MIPS_INTERNAL		0x1
#define STO_MIPS_HIDDEN			0x2
#define STO_MIPS_PROTECTED		0x3
#define STO_MIPS_SC_ALIGN_UNUSED	0xff

/* MIPS specific values for `st_info'.  */
#define STB_MIPS_SPLIT_COMMON		13

/* Entries found in sections of type SHT_MIPS_GPTAB.  */

typedef union
{
  struct
    {
      Elf32_Word gt_current_g_value;	/* -G value used for compilation */
      Elf32_Word gt_unused;		/* Not used */
    } gt_header;			/* First entry in section */
  struct
    {
      Elf32_Word gt_g_value;		/* If this value were used for -G */
      Elf32_Word gt_bytes;		/* This many bytes would be used */
    } gt_entry;				/* Subsequent entries in section */
} Elf32_gptab;

/* Entry found in sections of type SHT_MIPS_REGINFO.  */

typedef struct
{
  Elf32_Word	ri_gprmask;		/* General registers used */
  Elf32_Word	ri_cprmask[4];		/* Coprocessor registers used */
  Elf32_Sword	ri_gp_value;		/* $gp register value */
} Elf32_RegInfo;

/* Entries found in sections of type SHT_MIPS_OPTIONS.  */

typedef struct
{
  unsigned char kind;		/* Determines interpretation of the
				   variable part of descriptor.  */
  unsigned char size;		/* Size of descriptor, including header.  */
  Elf32_Section section;	/* Section header index of section affected,
				   0 for global options.  */
  Elf32_Word info;		/* Kind-specific information.  */
} Elf_Options;

/* Values for `kind' field in Elf_Options.  */

#define ODK_NULL	0	/* Undefined.  */
#define ODK_REGINFO	1	/* Register usage information.  */
#define ODK_EXCEPTIONS	2	/* Exception processing options.  */
#define ODK_PAD		3	/* Section padding options.  */
#define ODK_HWPATCH	4	/* Hardware workarounds performed */
#define ODK_FILL	5	/* record the fill value used by the linker. */
#define ODK_TAGS	6	/* reserve space for desktop tools to write. */
#define ODK_HWAND	7	/* HW workarounds.  'AND' bits when merging. */
#define ODK_HWOR	8	/* HW workarounds.  'OR' bits when merging.  */

/* Values for `info' in Elf_Options for ODK_EXCEPTIONS entries.  */

#define OEX_FPU_MIN	0x1f	/* FPE's which MUST be enabled.  */
#define OEX_FPU_MAX	0x1f00	/* FPE's which MAY be enabled.  */
#define OEX_PAGE0	0x10000	/* page zero must be mapped.  */
#define OEX_SMM		0x20000	/* Force sequential memory mode?  */
#define OEX_FPDBUG	0x40000	/* Force floating point debug mode?  */
#define OEX_PRECISEFP	OEX_FPDBUG
#define OEX_DISMISS	0x80000	/* Dismiss invalid address faults?  */

#define OEX_FPU_INVAL	0x10
#define OEX_FPU_DIV0	0x08
#define OEX_FPU_OFLO	0x04
#define OEX_FPU_UFLO	0x02
#define OEX_FPU_INEX	0x01

/* Masks for `info' in Elf_Options for an ODK_HWPATCH entry.  */

#define OHW_R4KEOP	0x1	/* R4000 end-of-page patch.  */
#define OHW_R8KPFETCH	0x2	/* may need R8000 prefetch patch.  */
#define OHW_R5KEOP	0x4	/* R5000 end-of-page patch.  */
#define OHW_R5KCVTL	0x8	/* R5000 cvt.[ds].l bug.  clean=1.  */

#define OPAD_PREFIX	0x1
#define OPAD_POSTFIX	0x2
#define OPAD_SYMBOL	0x4

/* Entry found in `.options' section.  */

typedef struct
{
  Elf32_Word hwp_flags1;	/* Extra flags.  */
  Elf32_Word hwp_flags2;	/* Extra flags.  */
} Elf_Options_Hw;

/* Masks for `info' in ElfOptions for ODK_HWAND and ODK_HWOR entries.  */

#define OHWA0_R4KEOP_CHECKED	0x00000001
#define OHWA1_R4KEOP_CLEAN	0x00000002

/* MIPS relocs.  */

#define R_MIPS_NONE		0	/* No reloc */
#define R_MIPS_16		1	/* Direct 16 bit */
#define R_MIPS_32		2	/* Direct 32 bit */
#define R_MIPS_REL32		3	/* PC relative 32 bit */
#define R_MIPS_26		4	/* Direct 26 bit shifted */
#define R_MIPS_HI16		5	/* High 16 bit */
#define R_MIPS_LO16		6	/* Low 16 bit */
#define R_MIPS_GPREL16		7	/* GP relative 16 bit */
#define R_MIPS_LITERAL		8	/* 16 bit literal entry */
#define R_MIPS_GOT16		9	/* 16 bit GOT entry */
#define R_MIPS_PC16		10	/* PC relative 16 bit */
#define R_MIPS_CALL16		11	/* 16 bit GOT entry for function */
#define R_MIPS_GPREL32		12	/* GP relative 32 bit */

#define R_MIPS_SHIFT5		16
#define R_MIPS_SHIFT6		17
#define R_MIPS_64		18
#define R_MIPS_GOT_DISP		19
#define R_MIPS_GOT_PAGE		20
#define R_MIPS_GOT_OFST		21
#define R_MIPS_GOT_HI16		22
#define R_MIPS_GOT_LO16		23
#define R_MIPS_SUB		24
#define R_MIPS_INSERT_A		25
#define R_MIPS_INSERT_B		26
#define R_MIPS_DELETE		27
#define R_MIPS_HIGHER		28
#define R_MIPS_HIGHEST		29
#define R_MIPS_CALL_HI16	30
#define R_MIPS_CALL_LO16	31
#define R_MIPS_SCN_DISP		32
#define R_MIPS_REL16		33
#define R_MIPS_ADD_IMMEDIATE	34
#define R_MIPS_PJUMP		35
#define R_MIPS_RELGOT		36
#define R_MIPS_JALR		37
/* Keep this the last entry.  */
#define R_MIPS_NUM		38

/* Legal values for p_type field of Elf32_Phdr.  */

#define PT_MIPS_REGINFO	0x70000000	/* Register usage information */
#define PT_MIPS_RTPROC  0x70000001	/* Runtime procedure table. */
#define PT_MIPS_OPTIONS 0x70000002

/* Special program header types.  */

#define PF_MIPS_LOCAL	0x10000000

/* Legal values for d_tag field of Elf32_Dyn.  */

#define DT_MIPS_RLD_VERSION  0x70000001	/* Runtime linker interface version */
#define DT_MIPS_TIME_STAMP   0x70000002	/* Timestamp */
#define DT_MIPS_ICHECKSUM    0x70000003	/* Checksum */
#define DT_MIPS_IVERSION     0x70000004	/* Version string (string tbl index) */
#define DT_MIPS_FLAGS	     0x70000005	/* Flags */
#define DT_MIPS_BASE_ADDRESS 0x70000006	/* Base address */
#define DT_MIPS_MSYM	     0x70000007
#define DT_MIPS_CONFLICT     0x70000008	/* Address of CONFLICT section */
#define DT_MIPS_LIBLIST	     0x70000009	/* Address of LIBLIST section */
#define DT_MIPS_LOCAL_GOTNO  0x7000000a	/* Number of local GOT entries */
#define DT_MIPS_CONFLICTNO   0x7000000b	/* Number of CONFLICT entries */
#define DT_MIPS_LIBLISTNO    0x70000010	/* Number of LIBLIST entries */
#define DT_MIPS_SYMTABNO     0x70000011	/* Number of DYNSYM entries */
#define DT_MIPS_UNREFEXTNO   0x70000012	/* First external DYNSYM */
#define DT_MIPS_GOTSYM	     0x70000013	/* First GOT entry in DYNSYM */
#define DT_MIPS_HIPAGENO     0x70000014	/* Number of GOT page table entries */
#define DT_MIPS_RLD_MAP	     0x70000016	/* Address of run time loader map.  */
#define DT_MIPS_DELTA_CLASS  0x70000017	/* Delta C++ class definition.  */
#define DT_MIPS_DELTA_CLASS_NO    0x70000018 /* Number of entries in
						DT_MIPS_DELTA_CLASS.  */
#define DT_MIPS_DELTA_INSTANCE    0x70000019 /* Delta C++ class instances.  */
#define DT_MIPS_DELTA_INSTANCE_NO 0x7000001a /* Number of entries in
						DT_MIPS_DELTA_INSTANCE.  */
#define DT_MIPS_DELTA_RELOC  0x7000001b /* Delta relocations.  */
#define DT_MIPS_DELTA_RELOC_NO 0x7000001c /* Number of entries in
					     DT_MIPS_DELTA_RELOC.  */
#define DT_MIPS_DELTA_SYM    0x7000001d /* Delta symbols that Delta
					   relocations refer to.  */
#define DT_MIPS_DELTA_SYM_NO 0x7000001e /* Number of entries in
					   DT_MIPS_DELTA_SYM.  */
#define DT_MIPS_DELTA_CLASSSYM 0x70000020 /* Delta symbols that hold the
					     class declaration.  */
#define DT_MIPS_DELTA_CLASSSYM_NO 0x70000021 /* Number of entries in
						DT_MIPS_DELTA_CLASSSYM.  */
#define DT_MIPS_CXX_FLAGS    0x70000022 /* Flags indicating for C++ flavor.  */
#define DT_MIPS_PIXIE_INIT   0x70000023
#define DT_MIPS_SYMBOL_LIB   0x70000024
#define DT_MIPS_LOCALPAGE_GOTIDX 0x70000025
#define DT_MIPS_LOCAL_GOTIDX 0x70000026
#define DT_MIPS_HIDDEN_GOTIDX 0x70000027
#define DT_MIPS_PROTECTED_GOTIDX 0x70000028
#define DT_MIPS_OPTIONS	     0x70000029 /* Address of .options.  */
#define DT_MIPS_INTERFACE    0x7000002a /* Address of .interface.  */
#define DT_MIPS_DYNSTR_ALIGN 0x7000002b
#define DT_MIPS_INTERFACE_SIZE 0x7000002c /* Size of the .interface section. */
#define DT_MIPS_RLD_TEXT_RESOLVE_ADDR 0x7000002d /* Address of rld_text_rsolve
						    function stored in GOT.  */
#define DT_MIPS_PERF_SUFFIX  0x7000002e /* Default suffix of dso to be added
					   by rld on dlopen() calls.  */
#define DT_MIPS_COMPACT_SIZE 0x7000002f /* (O32)Size of compact rel section. */
#define DT_MIPS_GP_VALUE     0x70000030 /* GP value for aux GOTs.  */
#define DT_MIPS_AUX_DYNAMIC  0x70000031 /* Address of aux .dynamic.  */
#define DT_MIPS_NUM	     0x32

/* Legal values for DT_MIPS_FLAGS Elf32_Dyn entry.  */

#define RHF_NONE		   0		/* No flags */
#define RHF_QUICKSTART		   (1 << 0)	/* Use quickstart */
#define RHF_NOTPOT		   (1 << 1)	/* Hash size not power of 2 */
#define RHF_NO_LIBRARY_REPLACEMENT (1 << 2)	/* Ignore LD_LIBRARY_PATH */
#define RHF_NO_MOVE		   (1 << 3)
#define RHF_SGI_ONLY		   (1 << 4)
#define RHF_GUARANTEE_INIT	   (1 << 5)
#define RHF_DELTA_C_PLUS_PLUS	   (1 << 6)
#define RHF_GUARANTEE_START_INIT   (1 << 7)
#define RHF_PIXIE		   (1 << 8)
#define RHF_DEFAULT_DELAY_LOAD	   (1 << 9)
#define RHF_REQUICKSTART	   (1 << 10)
#define RHF_REQUICKSTARTED	   (1 << 11)
#define RHF_CORD		   (1 << 12)
#define RHF_NO_UNRES_UNDEF	   (1 << 13)
#define RHF_RLD_ORDER_SAFE	   (1 << 14)

/* Entries found in sections of type SHT_MIPS_LIBLIST.  */

typedef struct
{
  Elf32_Word l_name;		/* Name (string table index) */
  Elf32_Word l_time_stamp;	/* Timestamp */
  Elf32_Word l_checksum;	/* Checksum */
  Elf32_Word l_version;		/* Interface version */
  Elf32_Word l_flags;		/* Flags */
} Elf32_Lib;

typedef struct
{
  Elf64_Word l_name;		/* Name (string table index) */
  Elf64_Word l_time_stamp;	/* Timestamp */
  Elf64_Word l_checksum;	/* Checksum */
  Elf64_Word l_version;		/* Interface version */
  Elf64_Word l_flags;		/* Flags */
} Elf64_Lib;


/* Legal values for l_flags.  */

#define LL_NONE		  0
#define LL_EXACT_MATCH	  (1 << 0)	/* Require exact match */
#define LL_IGNORE_INT_VER (1 << 1)	/* Ignore interface version */
#define LL_REQUIRE_MINOR  (1 << 2)
#define LL_EXPORTS	  (1 << 3)
#define LL_DELAY_LOAD	  (1 << 4)
#define LL_DELTA	  (1 << 5)

/* Entries found in sections of type SHT_MIPS_CONFLICT.  */

typedef Elf32_Addr Elf32_Conflict;


/* HPPA specific definitions.  */

/* Legal values for e_flags field of Elf32_Ehdr.  */

#define EF_PARISC_TRAPNL	1	/* Trap nil pointer dereference.  */
#define EF_PARISC_EXT		2	/* Program uses arch. extensions.  */
#define EF_PARISC_ARCH		0xffff0000 /* Architecture version.  */
/* Defined values are:
				0x020b	PA-RISC 1.0 big-endian
				0x0210	PA-RISC 1.1 big-endian
				0x028b	PA-RISC 1.0 little-endian
				0x0290	PA-RISC 1.1 little-endian
*/

/* Legal values for sh_type field of Elf32_Shdr.  */

#define SHT_PARISC_GOT		0x70000000 /* GOT for external data.  */
#define SHT_PARISC_ARCH		0x70000001 /* Architecture extensions.  */
#define SHT_PARISC_GLOBAL	0x70000002 /* Definition of $global$.  */
#define SHT_PARISC_MILLI	0x70000003 /* Millicode routines.  */
#define SHT_PARISC_UNWIND	0x70000004 /* Unwind information.  */
#define SHT_PARISC_PLT		0x70000005 /* Procedure linkage table.  */
#define SHT_PARISC_SDATA	0x70000006 /* Short initialized data.  */
#define SHT_PARISC_SBSS		0x70000007 /* Short uninitialized data.  */
#define SHT_PARISC_SYMEXTN	0x70000008 /* Argument/relocation info.  */
#define SHT_PARISC_STUBS	0x70000009 /* Linker stubs.  */

/* Legal values for sh_flags field of Elf32_Shdr.  */

#define SHF_PARISC_GLOBAL	0x10000000 /* Section defines dp.  */
#define SHF_PARISC_SHORT	0x20000000 /* Section with short addressing. */

/* Legal values for ST_TYPE subfield of st_info (symbol type).  */

#define STT_PARISC_MILLICODE	13	/* Millicode function entry point.  */

/* HPPA relocs.  */

#define R_PARISC_NONE		0	/* No reloc.  */
#define R_PARISC_DIR32		1	/* Direct 32-bit reference.  */
#define R_PARISC_DIR21L		2	/* Left 21 bits of eff. address.  */
#define R_PARISC_DIR17R		3	/* Right 17 bits of eff. address.  */
#define R_PARISC_DIR14R		4	/* Right 14 bits of eff. address.  */
#define R_PARISC_PCREL21L	5	/* PC-relative, left 21 bits.  */
#define R_PARISC_PCREL14R	6	/* PC-relative, right 14 bits.  */
#define R_PARISC_PCREL17C	7	/* Conditional PC-relative, ignore
					   if displacement > 17bits.  */
#define R_PARISC_PCREL17F	8	/* Conditional PC-relative, must
					   fit in 17bits.  */
#define R_PARISC_DPREL21L	9	/* DP-relative, left 21 bits.  */
#define R_PARISC_DPREL14R	10	/* DP-relative, right 14 bits.  */
#define R_PARISC_DPREL14F	11	/* DP-relative, must bit in 14 bits. */
#define R_PARISC_DLTREL21L	12	/* DLT-relative, left 21 bits.  */
#define R_PARISC_DLTREL14R	13	/* DLT-relative, right 14 bits.  */
#define R_PARISC_DLTREL14F	14	/* DLT-relative, must fit in 14 bits.*/
#define R_PARISC_DLTIND21L	15	/* DLT-relative indirect, left
					   21 bits.  */
#define R_PARISC_DLTIND14R	16	/* DLT-relative indirect, right
					   14 bits.  */
#define R_PARISC_DLTIND14F	17	/* DLT-relative indirect, must fit
					   int 14 bits.  */
#define R_PARISC_PLABEL32	18	/* Direct 32-bit reference to proc.  */

/* Alpha specific definitions.  */

/* Legal values for e_flags field of Elf64_Ehdr.  */

#define EF_ALPHA_32BIT		1	/* All addresses must be < 2GB.  */
#define EF_ALPHA_CANRELAX	2	/* Relocations for relaxing exist.  */

/* Legal values for sh_type field of Elf64_Shdr.  */

/* These two are primerily concerned with ECOFF debugging info.  */
#define SHT_ALPHA_DEBUG		0x70000001
#define SHT_ALPHA_REGINFO	0x70000002

/* Legal values for sh_flags field of Elf64_Shdr.  */

#define SHF_ALPHA_GPREL		0x10000000

/* Legal values for st_other field of Elf64_Sym.  */
#define STO_ALPHA_NOPV		0x80	/* No PV required.  */
#define STO_ALPHA_STD_GPLOAD	0x88	/* PV only used for initial ldgp.  */

/* Alpha relocs.  */

#define R_ALPHA_NONE		0	/* No reloc */
#define R_ALPHA_REFLONG		1	/* Direct 32 bit */
#define R_ALPHA_REFQUAD		2	/* Direct 64 bit */
#define R_ALPHA_GPREL32		3	/* GP relative 32 bit */
#define R_ALPHA_LITERAL		4	/* GP relative 16 bit w/optimization */
#define R_ALPHA_LITUSE		5	/* Optimization hint for LITERAL */
#define R_ALPHA_GPDISP		6	/* Add displacement to GP */
#define R_ALPHA_BRADDR		7	/* PC+4 relative 23 bit shifted */
#define R_ALPHA_HINT		8	/* PC+4 relative 16 bit shifted */
#define R_ALPHA_SREL16		9	/* PC relative 16 bit */
#define R_ALPHA_SREL32		10	/* PC relative 32 bit */
#define R_ALPHA_SREL64		11	/* PC relative 64 bit */
#define R_ALPHA_OP_PUSH		12	/* OP stack push */
#define R_ALPHA_OP_STORE	13	/* OP stack pop and store */
#define R_ALPHA_OP_PSUB		14	/* OP stack subtract */
#define R_ALPHA_OP_PRSHIFT	15	/* OP stack right shift */
#define R_ALPHA_GPVALUE		16
#define R_ALPHA_GPRELHIGH	17
#define R_ALPHA_GPRELLOW	18
#define R_ALPHA_IMMED_GP_16	19
#define R_ALPHA_IMMED_GP_HI32	20
#define R_ALPHA_IMMED_SCN_HI32	21
#define R_ALPHA_IMMED_BR_HI32	22
#define R_ALPHA_IMMED_LO32	23
#define R_ALPHA_COPY		24	/* Copy symbol at runtime */
#define R_ALPHA_GLOB_DAT	25	/* Create GOT entry */
#define R_ALPHA_JMP_SLOT	26	/* Create PLT entry */
#define R_ALPHA_RELATIVE	27	/* Adjust by program base */
/* Keep this the last entry.  */
#define R_ALPHA_NUM		28


/* PowerPC specific declarations */

/* PowerPC relocations defined by the ABIs */
#define R_PPC_NONE		0
#define R_PPC_ADDR32		1	/* 32bit absolute address */
#define R_PPC_ADDR24		2	/* 26bit address, 2 bits ignored.  */
#define R_PPC_ADDR16		3	/* 16bit absolute address */
#define R_PPC_ADDR16_LO		4	/* lower 16bit of absolute address */
#define R_PPC_ADDR16_HI		5	/* high 16bit of absolute address */
#define R_PPC_ADDR16_HA		6	/* adjusted high 16bit */
#define R_PPC_ADDR14		7	/* 16bit address, 2 bits ignored */
#define R_PPC_ADDR14_BRTAKEN	8
#define R_PPC_ADDR14_BRNTAKEN	9
#define R_PPC_REL24		10	/* PC relative 26 bit */
#define R_PPC_REL14		11	/* PC relative 16 bit */
#define R_PPC_REL14_BRTAKEN	12
#define R_PPC_REL14_BRNTAKEN	13
#define R_PPC_GOT16		14
#define R_PPC_GOT16_LO		15
#define R_PPC_GOT16_HI		16
#define R_PPC_GOT16_HA		17
#define R_PPC_PLTREL24		18
#define R_PPC_COPY		19
#define R_PPC_GLOB_DAT		20
#define R_PPC_JMP_SLOT		21
#define R_PPC_RELATIVE		22
#define R_PPC_LOCAL24PC		23
#define R_PPC_UADDR32		24
#define R_PPC_UADDR16		25
#define R_PPC_REL32		26
#define R_PPC_PLT32		27
#define R_PPC_PLTREL32		28
#define R_PPC_PLT16_LO		29
#define R_PPC_PLT16_HI		30
#define R_PPC_PLT16_HA		31
#define R_PPC_SDAREL16		32
#define R_PPC_SECTOFF		33
#define R_PPC_SECTOFF_LO	34
#define R_PPC_SECTOFF_HI	35
#define R_PPC_SECTOFF_HA	36
/* Keep this the last entry.  */
#define R_PPC_NUM		37

/* The remaining relocs are from the Embedded ELF ABI, and are not
   in the SVR4 ELF ABI.  */
#define R_PPC_EMB_NADDR32	101
#define R_PPC_EMB_NADDR16	102
#define R_PPC_EMB_NADDR16_LO	103
#define R_PPC_EMB_NADDR16_HI	104
#define R_PPC_EMB_NADDR16_HA	105
#define R_PPC_EMB_SDAI16	106
#define R_PPC_EMB_SDA2I16	107
#define R_PPC_EMB_SDA2REL	108
#define R_PPC_EMB_SDA21		109	/* 16 bit offset in SDA */
#define R_PPC_EMB_MRKREF	110
#define R_PPC_EMB_RELSEC16	111
#define R_PPC_EMB_RELST_LO	112
#define R_PPC_EMB_RELST_HI	113
#define R_PPC_EMB_RELST_HA	114
#define R_PPC_EMB_BIT_FLD	115
#define R_PPC_EMB_RELSDA	116	/* 16 bit relative offset in SDA */

/* Diab tool relocations.  */
#define R_PPC_DIAB_SDA21_LO	180	/* like EMB_SDA21, but lower 16 bit */
#define R_PPC_DIAB_SDA21_HI	181	/* like EMB_SDA21, but high 16 bit */
#define R_PPC_DIAB_SDA21_HA	182	/* like EMB_SDA21, adjusted high 16 */
#define R_PPC_DIAB_RELSDA_LO	183	/* like EMB_RELSDA, but lower 16 bit */
#define R_PPC_DIAB_RELSDA_HI	184	/* like EMB_RELSDA, but high 16 bit */
#define R_PPC_DIAB_RELSDA_HA	185	/* like EMB_RELSDA, adjusted high 16 */

/* This is a phony reloc to handle any old fashioned TOC16 references
   that may still be in object files.  */
#define R_PPC_TOC16		255


/* ARM specific declarations */

/* Processor specific flags for the ELF header e_flags field.  */
#define EF_ARM_RELEXEC     0x01
#define EF_ARM_HASENTRY    0x02
#define EF_ARM_INTERWORK   0x04
#define EF_ARM_APCS_26     0x08
#define EF_ARM_APCS_FLOAT  0x10
#define EF_ARM_PIC         0x20
#define EF_ALIGN8          0x40		/* 8-bit structure alignment is in use */
#define EF_NEW_ABI         0x80
#define EF_OLD_ABI         0x100

/* Additional symbol types for Thumb */
#define STT_ARM_TFUNC      0xd

/* ARM-specific values for sh_flags */
#define SHF_ARM_ENTRYSECT  0x10000000   /* Section contains an entry point */
#define SHF_ARM_COMDEF     0x80000000   /* Section may be multiply defined
					   in the input to a link step */

/* ARM-specific program header flags */
#define PF_ARM_SB          0x10000000   /* Segment contains the location
					   addressed by the static base */

/* ARM relocs.  */
#define R_ARM_NONE		0	/* No reloc */
#define R_ARM_PC24		1	/* PC relative 26 bit branch */
#define R_ARM_ABS32		2	/* Direct 32 bit  */
#define R_ARM_REL32		3	/* PC relative 32 bit */
#define R_ARM_PC13		4
#define R_ARM_ABS16		5	/* Direct 16 bit */
#define R_ARM_ABS12		6	/* Direct 12 bit */
#define R_ARM_THM_ABS5		7
#define R_ARM_ABS8		8	/* Direct 8 bit */
#define R_ARM_SBREL32		9
#define R_ARM_THM_PC22		10
#define R_ARM_THM_PC8		11
#define R_ARM_AMP_VCALL9	12
#define R_ARM_SWI24		13
#define R_ARM_THM_SWI8		14
#define R_ARM_XPC25		15
#define R_ARM_THM_XPC22		16
#define R_ARM_COPY		20	/* Copy symbol at runtime */
#define R_ARM_GLOB_DAT		21	/* Create GOT entry */
#define R_ARM_JUMP_SLOT		22	/* Create PLT entry */
#define R_ARM_RELATIVE		23	/* Adjust by program base */
#define R_ARM_GOTOFF		24	/* 32 bit offset to GOT */
#define R_ARM_GOTPC		25	/* 32 bit PC relative offset to GOT */
#define R_ARM_GOT32		26	/* 32 bit GOT entry */
#define R_ARM_PLT32		27	/* 32 bit PLT address */
#define R_ARM_GNU_VTENTRY	100
#define R_ARM_GNU_VTINHERIT	101
#define R_ARM_THM_PC11		102	/* thumb unconditional branch */
#define R_ARM_THM_PC9		103	/* thumb conditional branch */
#define R_ARM_RXPC25		249
#define R_ARM_RSBREL32		250
#define R_ARM_THM_RPC22		251
#define R_ARM_RREL32		252
#define R_ARM_RABS22		253
#define R_ARM_RPC24		254
#define R_ARM_RBASE		255
/* Keep this the last entry.  */
#define R_ARM_NUM		256

__END_DECLS

#endif	/* elf.h */

From davidm at snapgear.com  Tue Apr 16 19:30:39 2002
From: davidm at snapgear.com (David McCullough)
Date: Wed, 17 Apr 2002 09:30:39 +1000
Subject: [uClinux-dev] Install uClinux on a PalmVx ?
In-Reply-To: <200204161332.g3GDWOx21688@picard.skynet.be>; from fskivee@skynet.be on Tue, Apr 16, 2002 at 03:37:49PM +0200
References: <200204161332.g3GDWOx21688@picard.skynet.be>
Message-ID: <20020417093039.C3994@beast.internal.moreton.com.au>


Jivin Fabian Skiv?e lays it down ...
> Hello,
> 
> 	I try to install uClinux on a palmVx. I install the file "uClinuxPalm.prc" 
> form the web-site : http://palm-linux.sourceforge.net/. But when I run the 
> application on the palm, I see the picture of the Linux penguin but I don't 
> see anything on the serial port.
> 
> 	I use the command : "cat | /dev/ttyS0" to see the characters on the serial
> device /dev/ttyS0. I already use this method to see the output of the 
> xcopilot and it works very well.

You probably want "cat /dev/ttyS0".  Th ebaud rate it 9600 from memory.

> 	Does anyone can help me ? Does I make an mistake with my linux or the
> serial port ? 
...
> 
> PS : I try to install the linux on a Palm m500. Does anyone know the changes 
> I must apply to the code between the PalmVx and the Palm m500 ?

No idea, sorry, check the memory map for the m500 and compare it with the
Palm,

Cheers,
Davidm

-- 
David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
davidm at snapgear.com  Fx: +61 7 3891 3630  825 Stanley St., W'gabba QLD 4102, Oz
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From davidm at snapgear.com  Tue Apr 16 19:39:42 2002
From: davidm at snapgear.com (David McCullough)
Date: Wed, 17 Apr 2002 09:39:42 +1000
Subject: [uClinux-dev] elf2flt support for C++ & STL source compilation.
In-Reply-To: <3CBC4C03.483B3DA9@snom.de>; from tahir@snom.de on Tue, Apr 16, 2002 at 06:06:27PM +0200
References: <3CBC4C03.483B3DA9@snom.de>
Message-ID: <20020417093942.D3994@beast.internal.moreton.com.au>

Jivin Usman Tahir lays it down ...
> Hi there,
> 
> I have been encountering some problems in my user application (in C++)
> compilation for MCF5206 using the latest m68k-elf-tools (installed in
> /usr/local.....) and the latest uClinux distribution i.e.
> uClinux-kernel-2.4.17 (April 11 release). I am using $(LDFLAGS),
> $(LDLIBS), $(CXXFLAGS) etc. The problem seems to be in elf2flt, as
> apparent from the following log:
> 
> obj_files/my_app.elf2flt: In function `f1':
> /home/davidm/work/m68k-elf-tools/m68k-elf-gcc/gcc/../../gcc-2.95.3/gcc/libgcc2.c(.text+0xafbee):
> undefined reference to `abort'
> obj_files/,my_app.elf2flt: In function `ff2':
> /home/davidm/work/m68k-elf-tools/m68k-elf-gcc/gcc/../../gcc-2.95.3/gcc/libgcc2.c(.text+0xb004e):
> undefined reference to `abort'
> obj_files/my_app.elf2flt: In function `fff3':
> /home/davidm/work/m68k-elf-tools/m68k-elf-gcc/gcc/../../gcc-2.95.3/gcc/frame.c(.text+0xb1a3a):
> undefined reference to `abort'
> /home/davidm/work/m68k-elf-tools/m68k-elf-gcc/gcc/../../gcc-2.95.3/gcc/frame.c(.text+0xb1a6a):
> undefined reference to `abort'
> obj_files/my_app.elf2flt: In function `fff4':
> /home/davidm/work/m68k-elf-tools/m68k-elf-gcc/gcc/../../gcc-2.95.3/gcc/frame.c:627:
> undefined reference to `abort'
> obj_files/my_app.elf2flt(.text+0xb235e):/home/davidm/work/m68k-elf-tools/m68k-elf-gcc/gcc/../../gcc-2.95.3/gcc/frame.c:
> more undefined references to `abort' follow


For C++ you need to link against the libc that comes with the compiler.
For example:

	m68k-elf-g++ -Wl,-elf2flt -m5200 -o c c.cpp -lstdc++ -lc -lgcc

Cheers,
Davidm

-- 
David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
davidm at snapgear.com  Fx: +61 7 3891 3630  825 Stanley St., W'gabba QLD 4102, Oz
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From gerg at snapgear.com  Tue Apr 16 20:14:20 2002
From: gerg at snapgear.com (Greg Ungerer)
Date: Wed, 17 Apr 2002 10:14:20 +1000
Subject: [uClinux-dev] Two copies of romfs?
References: <8CCBDD5583C50E4196F012E79439B45C620226@atl-ms1.megatrends.com>
Message-ID: <3CBCBE5C.1030000@snapgear.com>


Hi Subash,

Subash Kalbarga wrote:

> I was wondering if there are two copies of the root filesystem which is 
> mounted from romfs.img ?
> 
> Romfs.img gets appended to the kernel.
> 
> After that does the kernel copy the whole thing again in ram?


Some targets do this, some don't. It depends on how you want
to set things up. There is no reason you have to copy the romfs.img
out of FLASH (assuming that is where it starts) though.

Many targets that do copy the romfs.img store it compressed,
and so you have to uncompress it to use it.

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

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From gerg at snapgear.com  Tue Apr 16 20:25:59 2002
From: gerg at snapgear.com (Greg Ungerer)
Date: Wed, 17 Apr 2002 10:25:59 +1000
Subject: [uClinux-dev] Restrictions to M5272C Registers
References: <200204161540.RAA19579@caleb.dspsolutions>
Message-ID: <3CBCC117.70602@snapgear.com>

Hi Bernd,

Bernd Pfaff wrote:

> I'm working with the Motorola M5272C microcontrollerplatform under uClinux.   
> I use the chip select registers (CSOR1 and CSBR1) for CS1 and the general 
> purpose I/O module (registers PACNT, PADDR, PADAT and PBCNT).
> 
> How is uClinux affecting those registers? 


Search the code :-)

Try something like this:

     find -type f | xargs grep PBCNT


> Or can anyone give me a hint, where I can find information about the use of 
> registers by uClinux? 


They are used in a few places. Typically target board specific.
For example the serial driver (~/drivers/char/mcfserial.c) sets
some of the PBCNT and PDCNT bits to enable the I/O lines for
the second internal UART.

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

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From petero at cvs.com.au  Tue Apr 16 21:44:36 2002
From: petero at cvs.com.au (Peter Ogilvy)
Date: Wed, 17 Apr 2002 11:44:36 +1000
Subject: [uClinux-dev] Re: offtop question
In-Reply-To: <Pine.LNX.4.44.0204160842480.1727-100000@sw-55.sedsystems.c
 a>
References: <005301c1e51c$5b279410$f5feaa0a@IronLung>
Message-ID: <5.1.0.14.1.20020417113354.00a9fb50@localhost>

Kendric wrote:
>With regards to tabs:
>         I use vim. I set it to put tab characters in for indents and let
>it handle indenting the code.I set my vim configuration to show tabs as
>four spaces but can very easily change it to show them as 8 spaces. If the
>editor actually puts in tab characters, it should be easy for a modern
>editor to show tabs as how many ever characters you want.

Of course the counter to this is than on large projects with
multiple programmers it hard to ensure that every one uses
tabs in all cases, and doesnt just use spaces to align to thier
personal indent preference. When other programmers with different
tab settings view the code its a mess. This is of course why
large projects should have a style guide, and an automated tool
to enforce indenting and other layout rules. I've never seen it
done in practise though :-)

Peter

PS anywhere from 2 to 4 space indents as long as it consistent through
all the code is my bias (IBM did some research on readabilty and they
found it was equally good in this range worse outside)

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From miles at lsi.nec.co.jp  Tue Apr 16 22:42:56 2002
From: miles at lsi.nec.co.jp (Miles Bader)
Date: 17 Apr 2002 11:42:56 +0900
Subject: [uClinux-dev] Re: offtop question
In-Reply-To: <5.1.0.14.1.20020417113354.00a9fb50@localhost>
References: <005301c1e51c$5b279410$f5feaa0a@IronLung>
	<5.1.0.14.1.20020417113354.00a9fb50@localhost>
Message-ID: <buoelhf9han.fsf@mcspd15.ucom.lsi.nec.co.jp>

Peter Ogilvy <petero at cvs.com.au> writes:
> PS anywhere from 2 to 4 space indents as long as it consistent through
> all the code is my bias

Actually I'm happy as long as it's consistent within the same _file_,
or at the very least, the same function!  [I've noticed that uClibc and
busybox have some, er, problems in this area...]

I usually try very hard to avoid re-indenting other people's code (e.g.,
I always set my editor's indentation style to match the existing code),
but when I see something like:

        some fun ()
        {
                if (foo) {
                        x = 5;
                        y = 6;
                  z = 10;
           } else {
                        blah;
                }
        }

sorry, I'm gonna fix it  :-......

-Miles
-- 
"Most attacks seem to take place at night, during a rainstorm, uphill,
 where four map sheets join."   -- Anon. British Officer in WW I
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From enrico.benetti at bluewind.it  Wed Apr 17 03:19:46 2002
From: enrico.benetti at bluewind.it (Enrico Benetti [BW])
Date: Wed, 17 Apr 2002 09:19:46 +0200
Subject: [uClinux-dev] boot from flash on 5272
In-Reply-To: <3CBCAB4B.6238CEC8@lineo.com>
Message-ID: <3CBD3E32.19903.6A96B@localhost>

Hi,
many thanks for your support. Here I attach the linker script rom.ld,
it derives from use of your 'bootfromrom' patch (I send you also 
crt0_rom.S).
Thank you in advance,
Enrico

On 17 Apr 2002, at 0:52, Bernhard Kuhn wrote:

> "Enrico Benetti [BW]" schrieb:
> 
> > BFD: Warning: Writing
> > section `.text' to huge (ie negative) file offset 0xffe20000.
> > m68k-elf- objcopy: /opt/uClinux-dist/images/linux.bin: File
> > truncated
> 
> Can you please post your rom.ld for further investigations?
> 
> 
> > I'd like to have uClinux booting from flash directly (without
> > bootloader) so I think this is the right way to proceed (changing
> > jp13 setting)
> 
> For a start, i suggest to read
> 
> http://home.t-online.de/home/Bernhard_Kuhn/uclinux/Platforms/Coldfire/tarifa/20011119/README
> 
> But for making the linux kernel executable in place together with
> colilo,
> you will have to change a few lines in colilo and in the linker script.
> 
> best regards
> 
> Bernhard
> 
> -- 
> Bernhard Kuhn, Software Engineer, Lineo Inc. (Where Open Meets Smart)
> This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/
> 


------------------------------------------
 Enrico Benetti
 BlueWind Embedded Systems Design
 Via Steffani, 7/B
 I-31033 Castelfranco Veneto (TV)

 Office: +39 0 423 723431
 Fax   : +39 0 423 744738
 GSM   : +39 335 7556736
 mailto: enrico.benetti at bluewind.it
 http://www.bluewind.it
------------------------------------------

-------------- next part --------------

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
}

-------------- next part --------------
/*****************************************************************************/

/*
 *	crt0_ram.S -- startup code for MCF5272 ColdFire based MOTOROLA boards.
 *
 *	(C) Copyright 2000, Lineo (www.lineo.com).
 *	(C) Copyright 1999, Greg Ungerer (gerg at lineo.com).
 *
 * 	1999/02/24 Modified for the 5307 processor David W. Miller
 */

/*****************************************************************************/

#include "linux/autoconf.h"
#include "asm/coldfire.h"
#include "asm/mcfsim.h"

/*****************************************************************************/

/*
 *	Motorola M5272C3 ColdFire eval board, chip select and memory setup.
 */

#define	MEM_BASE	0x00000000	/* Memory base at address 0 */
#define	MEM_SIZE	0x00400000	/* Memory size 4Mb */
#define	VBR_BASE	MEM_BASE	/* Vector address */

/*****************************************************************************/

.global	_start
.global _rambase
.global _ramvec
.global	_ramstart
.global	_ramend

/*****************************************************************************/

.data

/*
 *	Set up the usable of RAM stuff. Size of RAM is determined then
 *	an initial stack set up at the end.
 */
_rambase:
.long	0
_ramvec:
.long	0
_ramstart:
.long	0
_ramend:
.long	0

/*****************************************************************************/

.text

/*
 *	This is the codes first entry point. This is where it all
 *	begins...
 */

_start:
	nop					/* Filler */
	move.w	#0x2700, %sr			/* No interrupts */

	/*
	 * Setup VBR here, otherwise buserror remap will not work.
	 * if dBug was active before (on my SBC with dBug 1.1 of Dec 16 1996)
	 *
	 * bkr at cut.de 19990306
	 *
	 * Note: this is because dBUG points VBR to ROM, making vectors read
	 * only, so the bus trap can't be changed. (RS)
	 */
	move.l	#VBR_BASE, %a7			/* Note VBR can't be read */
	movec   %a7, %VBR

#if 1
	/*
	 *	Enable CPU internal cache.
	 */
	move.l	#0x01000000, %d0		/* Invalidate cache cmd */
	movec	%d0, %CACR			/* Invalidate cache */
	move.l	#0x80000100, %d0		/* Setup cache mask */
	movec	%d0, %CACR			/* Enable cache */
#endif
	
	/*
	 *      Copy data segment from ROM to RAM
	 */
	lea	__data_rom_start, %a0
	lea	_sdata, %a1
	lea	_edata, %a2
_copy_data:
	movel	%a0 at +, %a1 at +
	cmpal	%a1, %a2
	bhi	_copy_data

	/*
	 *	Zero out the bss region.
	 */
	lea.l	_sbss, %a0			/* Get start of bss */
	lea.l	_ebss, %a1			/* Get end of bss */
	clr.l	%d0				/* Set value */
_clear_bss:
	move.l	%d0, (%a0)+			/* Clear each word */
	cmp.l	%a0, %a1			/* Check if at end */
	bne	_clear_bss

        movel   #VBR_BASE, %d0    
        movel   %d0, _rambase
	       
        movel   #_ebss, %d0
        movel   %d0, _ramstart
	
        movel   #MEM_SIZE, %d0
        movel   %d0, _ramend
	
        movel   #VBR_BASE, %d0
        movel   %d0, _ramvec

	/*
	 * load the current task pointer and stack
	 */
	lea		init_task_union, %a0
	movel		%a0, _current_task
	lea		0x2000(%a0), %sp
	
	/*
	 *	Assember start up done, start code proper.
	 */
	jsr	start_kernel			/* Start Linux kernel */

_exit:
	jmp	_exit				/* Should never get here */

/*****************************************************************************/

From uclinux at schoeldgen.de  Wed Apr 17 04:50:44 2002
From: uclinux at schoeldgen.de (Matthias Schoeldgen)
Date: Wed, 17 Apr 2002 10:50:44 +0200
Subject: [uClinux-dev] newbie problems using uCsimm4s eth0
References: <7B3538F053C06142BF0AA9DF2D764AC606C37D@MAILSRV1.aquarius.cpqd.com.br> <3CBC6892.490ECB45@schoeldgen.de> <00c401c1e593$57d032a0$5801a8c0@localdomain>
Message-ID: <3CBD3763.A2F9029A@schoeldgen.de>

Hi Philip!
Ah, that explains it. I never looked into the filesystem this deep...
Thank you !
Matthias

Philip Nye wrote:
> 
> > From: "Matthias Schoeldgen" <uclinux at schoeldgen.de>
> >
> > BTW, can anyone explain the behaviour of busybox generating a binary for
> > each of the enabled commands ? When compiling the userland binaries i
> > get a 'busybox' executable, a 'mount' executable, and so on, each having
> > the same size of about 58kb or larger when including more busybox
> > features. I always thought busybox is one executable with all the
> > features built in ???
> 
> These are all hard links to the same executable - not separate files (you can
> tell because they all share the same inode). Thus when
> you type "mount" or whatever, the one executable can examine argv[0] to find
> how it has been called and therefore what it should do.
> 
> Philip Nye
> 
> This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From umthie10 at cc.UManitoba.CA  Wed Apr 17 04:10:07 2002
From: umthie10 at cc.UManitoba.CA (Nicolas Thiessen)
Date: Wed, 17 Apr 2002 03:10:07 -0500
Subject: [uClinux-dev] Atmel ARM stuff
References: <8CCBDD5583C50E4196F012E79439B45C620226@atl-ms1.megatrends.com>
Message-ID: <3CBD2DDF.4060204@cc.umanitoba.ca>

>
>
Hi, i'm working with an Atmel ARM eval board EB40A and i have a few 
questions.

I've been able to compile the 2.4 kernel, but now what do i do.  Do i 
need to flaten it with elf2flt?  I tried that and i get a "no relocation 
data" message.  Is that bad?

Also, do i need to install a new bootloader on the flash, or is the 
factory loader good?  What does the boot loader all do?  How can i 
upload the kernel to the flash?  Do i need to upload the kernel and the 
System.map?

thanks,
nic


-- 
                                                |>>>
                                                |
                                            _  _|_  _
                                           |;|_|;|_|;|
                                           \\.    .  /
Nicolas Thiessen                            \\:  .  /
Researcher - TRLabs   (204) 488-5628         ||:   |
Winnipeg, MB          umthie10 at win.trlabs.ca ||:.  |
                                             ||:  .|
                                             ||:   |       \,/
                                             ||: , |            /`\
                                             ||:   |
                                             ||: . |
              __                            _||_   |
     ____--`~    '--~~__            __ ----~    ~`---,              ___
-~--~                   ~---__ ,--~'                  ~~----_____-~'   



This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From joe_buczek at yahoo.com  Wed Apr 17 09:43:30 2002
From: joe_buczek at yahoo.com (Joe Buczek)
Date: Wed, 17 Apr 2002 06:43:30 -0700 (PDT)
Subject: [uClinux-dev] Install uClinux on a PalmVx ?
In-Reply-To: <200204161332.g3GDWOx21688@picard.skynet.be>
Message-ID: <20020417134330.79585.qmail@web20301.mail.yahoo.com>


--- Fabian Skiv?e <fskivee at skynet.be> wrote:

> I use the command : "cat | /dev/ttyS0" to see the characters on
> the serial device /dev/ttyS0.

Perhaps a typo, but I think you want "cat < /dev/ttyS0". 

--Joe

__________________________________________________
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://taxes.yahoo.com/
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From philwil at earthlink.net  Wed Apr 17 10:28:22 2002
From: philwil at earthlink.net (Phil Wilshire)
Date: Wed, 17 Apr 2002 10:28:22 -0400
Subject: [uClinux-dev] Atmel ARM stuff
References: <8CCBDD5583C50E4196F012E79439B45C620226@atl-ms1.megatrends.com> <3CBD2DDF.4060204@cc.umanitoba.ca>
Message-ID: <3CBD8686.F1C021D0@earthlink.net>

Hi Nicolas,
No elf2flt is needed the kernel should be fully linked and ready to
run...


Next 
You need to load the kernel onto the system somehow.
This can be done using a JTAG Hardware debugger 
Or a bootloader should be able to do this for you.

I am not familiar with the default ARM bootloader.
I'll let others help here.

regards
  Phil

 NicolasThiessen wrote:
> 
> >
> >
> Hi, i'm working with an Atmel ARM eval board EB40A and i have a few
> questions.
> 
> I've been able to compile the 2.4 kernel, but now what do i do.  Do i
> need to flaten it with elf2flt?  I tried that and i get a "no relocation
> data" message.  Is that bad?
> 
> Also, do i need to install a new bootloader on the flash, or is the
> factory loader good?  What does the boot loader all do?  How can i
> upload the kernel to the flash?  Do i need to upload the kernel and the
> System.map?
> 
> thanks,
> nic
> 
> --
>                                                 |>>>
>                                                 |
>                                             _  _|_  _
>                                            |;|_|;|_|;|
>                                            \\.    .  /
> Nicolas Thiessen                            \\:  .  /
> Researcher - TRLabs   (204) 488-5628         ||:   |
> Winnipeg, MB          umthie10 at win.trlabs.ca ||:.  |
>                                              ||:  .|
>                                              ||:   |       \,/
>                                              ||: , |            /`\
>                                              ||:   |
>                                              ||: . |
>               __                            _||_   |
>      ____--`~    '--~~__            __ ----~    ~`---,              ___
> -~--~                   ~---__ ,--~'                  ~~----_____-~'
> 
> This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From tahir at snom.de  Wed Apr 17 12:00:59 2002
From: tahir at snom.de (Muhammad Usman Tahir)
Date: Wed, 17 Apr 2002 18:00:59 +0200
Subject: [uClinux-dev] elf2flt support for C++ & STL source compilation.
References: <3CBC4C03.483B3DA9@snom.de> <20020417093942.D3994@beast.internal.moreton.com.au>
Message-ID: <002401c1e629$11a4b8a0$2200a8c0@flamenco>

Thanks David. Replacing (CC) with (CXX) i.e. m68k-elf-g++ helped a lot.
Though the libs were already there.
What about STL, any idea folks? Has anybody tried compiling STL sources for
m68k/MCF processors?

Thanks for all the help.

Regards,
Usman.


----- Original Message -----
From: "David McCullough" <davidm at snapgear.com>
To: <uclinux-dev at uclinux.org>
Sent: Wednesday, April 17, 2002 1:39 AM
Subject: Re: [uClinux-dev] elf2flt support for C++ & STL source compilation.


> Jivin Usman Tahir lays it down ...
> > Hi there,
> >
> > I have been encountering some problems in my user application (in C++)
> > compilation for MCF5206 using the latest m68k-elf-tools (installed in
> > /usr/local.....) and the latest uClinux distribution i.e.
> > uClinux-kernel-2.4.17 (April 11 release). I am using $(LDFLAGS),
> > $(LDLIBS), $(CXXFLAGS) etc. The problem seems to be in elf2flt, as
> > apparent from the following log:
> >
> > obj_files/my_app.elf2flt: In function `f1':
> >
/home/davidm/work/m68k-elf-tools/m68k-elf-gcc/gcc/../../gcc-2.95.3/gcc/libgc
c2.c(.text+0xafbee):
> > undefined reference to `abort'
> > obj_files/,my_app.elf2flt: In function `ff2':
> >
/home/davidm/work/m68k-elf-tools/m68k-elf-gcc/gcc/../../gcc-2.95.3/gcc/libgc
c2.c(.text+0xb004e):
> > undefined reference to `abort'
> > obj_files/my_app.elf2flt: In function `fff3':
> >
/home/davidm/work/m68k-elf-tools/m68k-elf-gcc/gcc/../../gcc-2.95.3/gcc/frame
.c(.text+0xb1a3a):
> > undefined reference to `abort'
> >
/home/davidm/work/m68k-elf-tools/m68k-elf-gcc/gcc/../../gcc-2.95.3/gcc/frame
.c(.text+0xb1a6a):
> > undefined reference to `abort'
> > obj_files/my_app.elf2flt: In function `fff4':
> >
/home/davidm/work/m68k-elf-tools/m68k-elf-gcc/gcc/../../gcc-2.95.3/gcc/frame
.c:627:
> > undefined reference to `abort'
> >
obj_files/my_app.elf2flt(.text+0xb235e):/home/davidm/work/m68k-elf-tools/m68
k-elf-gcc/gcc/../../gcc-2.95.3/gcc/frame.c:
> > more undefined references to `abort' follow
>
>
> For C++ you need to link against the libc that comes with the compiler.
> For example:
>
> m68k-elf-g++ -Wl,-elf2flt -m5200 -o c c.cpp -lstdc++ -lc -lgcc
>
> Cheers,
> Davidm
>
> --
> David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
> davidm at snapgear.com  Fx: +61 7 3891 3630  825 Stanley St., W'gabba QLD
4102, Oz
> This message resent by the uclinux-dev at uclinux.org list server
http://www.uClinux.org/

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From enrico.benetti at bluewind.it  Wed Apr 17 12:57:50 2002
From: enrico.benetti at bluewind.it (Enrico Benetti [BW])
Date: Wed, 17 Apr 2002 18:57:50 +0200
Subject: [uClinux-dev] ftp server on 5272
Message-ID: <3CBDC5AE.14243.82F33@localhost>

Hi all!
I'm trying to add a ftp server to uClinux (last release -11/04) on a 
5272c3 board: I'd a look to cvs userland but I didn't found ftpd so I 
downloaded 'anonftpd' from uclinux.net.
I have changed all references to m68k-pic* or m68k-coff* tools with 
m68k-elf* in the makefiles and I  followed the procedure to add a 
user application to kernel (described in the documentation). 
Make give me this errors:

make[2]: Entering directory `/opt/uClinux-dist/user/anonftp'
./load 
anonftpd \
telnet.o doit.o ftp.o conn.o err.o out.o wd.o \
log.o 
get.o sys.o scan6.o fmt6.o \
ndelay.o libstr.a libfs.a
collect2: ld 
terminated with signal 11 [Segmentation fault], core 
dumped
/usr/local/m68k-elf/lib/crt0.o: In function 
`_start':
/usr/local/m68k-elf/lib/crt0.o(.text+0x8): undefined 
reference to `__uClibc_main'
make[2]: *** [anonftpd] Error 
1
make[2]: Leaving directory `/opt/uClinux-
dist/user/anonftp'
make[1]: *** [all] Error 2
make[1]: Leaving 
directory `/opt/uClinux-dist/user'
make: *** [subdirs] Error 1
 

I don't understand the references to crt0.o: can someone help me 
building this ftp server or give me some news about another ftd 
porting?

Thanks in advance,
Enrico
------------------------------------------
 Enrico Benetti
 BlueWind Embedded Systems Design
 Via Steffani, 7/B
 I-31033 Castelfranco Veneto (TV)

 Office: +39 0 423 723431
 Fax   : +39 0 423 744738
 GSM   : +39 335 7556736
 mailto: enrico.benetti at bluewind.it
 http://www.bluewind.it
------------------------------------------

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From Fabrice_Gautier at sdesigns.com  Wed Apr 17 14:16:33 2002
From: Fabrice_Gautier at sdesigns.com (Fabrice Gautier)
Date: Wed, 17 Apr 2002 11:16:33 -0700
Subject: [uClinux-dev] Ide drivers
Message-ID: <B1F6452C89AFD411AE0800A0CC734C239DBBD1@EMAIL1>

Hi,

Anybdody ever used the ide driver with uClinux? To what extent is it working
?

-- 
Fabrice Gautier, 
Fabrice_Gautier at sdesigns.com
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From art at videon-central.com  Wed Apr 17 15:31:10 2002
From: art at videon-central.com (Arthur Shipkowski)
Date: Wed, 17 Apr 2002 15:31:10 -0400
Subject: [uClinux-dev] MCF5272 DMA support?
Message-ID: <000001c1e646$6e914d40$9f80a8c0@videoncentral.com>

I'm currently working on a custom driver for an MCF5272-based board that
requires DMA.  While writing the driver code and looking at
include/asm-m68knommu/dma.h and include/asm-m68knommu/mcfdma.h, I noted that
the register locations and bitmasks seem to be incorrect for the MCF5272
based on what the user's manual claims.  As an example:

>From mcfdma.h, all with an additional offset of 0xe0 from MBAR:
#define	MCFDMA_SAR		0x00		/* DMA source address (r/w) */
#define	MCFDMA_DAR		0x01		/* DMA destination adr (r/w) */
/* these are word registers, use unsigned short data type */
#define	MCFDMA_DCR		0x04		/* DMA control reg (r/w) */
#define	MCFDMA_BCR		0x06		/* DMA byte count reg (r/w) */
/* these are byte registers, use unsiged char data type */
#define	MCFDMA_DSR		0x10		/* DMA status reg (r/w) */
#define	MCFDMA_DIVR		0x14		/* DMA interrupt vec (r/w) */

>from the manual:
DCMR is at MBAR+0xe0, DIR is at MBAR+0xe6, DSAR is at MBAR+0xec, DDAR at
MBAR+0xf0, and dbcr at MBAR+0xe8.

Has anyone used the ColdFire DMA support with an MCF5272 (indicating that
the manual is apparently in error), or should I make the mods to bring it in
line with the manual?

Thank you all for your time.

Art

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From Dave_Pfaltzgraff at patapsco.com  Wed Apr 17 16:12:18 2002
From: Dave_Pfaltzgraff at patapsco.com (Dave_Pfaltzgraff at patapsco.com)
Date: Wed, 17 Apr 2002 16:12:18 -0400
Subject: [uClinux-dev] ftp server on 5272
Message-ID: <85256B9E.006EFDC9.00@patapsco.com>





Dave Pfaltzgraff at PATAPSCO
04/17/2002 04:12 PM

Enrico Benetti said:
----
> Make give me this errors:
> ...(sniped)
> terminated with signal 11 [Segmentation fault], core
> dumped
> ...(sniped)
As I recall, the signal 11 error usually indicates a memory
error on the system. (Doo a google search on "sig11")

Others on the list may be able to provide additional input.



This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From hamilton at SEDSystems.ca  Wed Apr 17 16:23:21 2002
From: hamilton at SEDSystems.ca (Kendrick Hamilton)
Date: Wed, 17 Apr 2002 14:23:21 -0600 (CST)
Subject: [uClinux-dev] ftp server on 5272
In-Reply-To: <85256B9E.006EFDC9.00@patapsco.com>
Message-ID: <Pine.LNX.4.44.0204171422540.8525-100000@sw-55.sedsystems.ca>

According to man 7 signal, signal 11 is a invalid memory reference


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

On Wed, 17 Apr 2002 Dave_Pfaltzgraff at patapsco.com wrote:

>
>
>
>
> Dave Pfaltzgraff at PATAPSCO
> 04/17/2002 04:12 PM
>
> Enrico Benetti said:
> ----
> > Make give me this errors:
> > ...(sniped)
> > terminated with signal 11 [Segmentation fault], core
> > dumped
> > ...(sniped)
> As I recall, the signal 11 error usually indicates a memory
> error on the system. (Doo a google search on "sig11")
>
> Others on the list may be able to provide additional input.
>
>
>
> This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/
>

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From gerg at snapgear.com  Wed Apr 17 19:43:43 2002
From: gerg at snapgear.com (Greg Ungerer)
Date: Thu, 18 Apr 2002 09:43:43 +1000
Subject: [uClinux-dev] Ide drivers
References: <B1F6452C89AFD411AE0800A0CC734C239DBBD1@EMAIL1>
Message-ID: <3CBE08AF.5080406@snapgear.com>

Hi Fabrice,

Fabrice Gautier wrote:

> Anybdody ever used the ide driver with uClinux? To what extent is it working


Yes, I have used it alot. It works perfectly.

I have used it on 2 separate ColdFire based designs,
with IDE hard drives, CD-ROMs and DVD drives.

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

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From gerg at snapgear.com  Wed Apr 17 20:00:49 2002
From: gerg at snapgear.com (Greg Ungerer)
Date: Thu, 18 Apr 2002 10:00:49 +1000
Subject: [uClinux-dev] MCF5272 DMA support?
References: <000001c1e646$6e914d40$9f80a8c0@videoncentral.com>
Message-ID: <3CBE0CB1.6040806@snapgear.com>


Hi Arthur,

Arthur Shipkowski wrote:

> I'm currently working on a custom driver for an MCF5272-based board that
> requires DMA.  While writing the driver code and looking at
> include/asm-m68knommu/dma.h and include/asm-m68knommu/mcfdma.h, I noted that
> the register locations and bitmasks seem to be incorrect for the MCF5272
> based on what the user's manual claims.  As an example:
> 
>>From mcfdma.h, all with an additional offset of 0xe0 from MBAR:
> #define	MCFDMA_SAR		0x00		/* DMA source address (r/w) */
> #define	MCFDMA_DAR		0x01		/* DMA destination adr (r/w) */
> /* these are word registers, use unsigned short data type */
> #define	MCFDMA_DCR		0x04		/* DMA control reg (r/w) */
> #define	MCFDMA_BCR		0x06		/* DMA byte count reg (r/w) */
> /* these are byte registers, use unsiged char data type */
> #define	MCFDMA_DSR		0x10		/* DMA status reg (r/w) */
> #define	MCFDMA_DIVR		0x14		/* DMA interrupt vec (r/w) */
> 
>>from the manual:
> DCMR is at MBAR+0xe0, DIR is at MBAR+0xe6, DSAR is at MBAR+0xec, DDAR at
> MBAR+0xf0, and dbcr at MBAR+0xe8.
> 
> Has anyone used the ColdFire DMA support with an MCF5272 (indicating that
> the manual is apparently in error), or should I make the mods to bring it in
> line with the manual?


Those defines are targeted at the 5307/5407, so may very well be
wrong for the 5272. (I don't beleive the manual is wrong here,
so my guess is that it has not been used on the 5272 before).

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

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From Fabrice_Gautier at sdesigns.com  Wed Apr 17 20:22:29 2002
From: Fabrice_Gautier at sdesigns.com (Fabrice Gautier)
Date: Wed, 17 Apr 2002 17:22:29 -0700
Subject: [uClinux-dev] Ide drivers
Message-ID: <B1F6452C89AFD411AE0800A0CC734C239DBBD3@EMAIL1>


Are you using DMA transferts or just PIO modes ? (I have some problem with
DMA)

-- 
Fabrice Gautier, 
Fabrice_Gautier at sdesigns.com


> -----Original Message-----
> From: Greg Ungerer [mailto:gerg at snapgear.com]
> Sent: Wednesday, April 17, 2002 4:44 PM
> To: uclinux-dev at uclinux.org
> Subject: Re: [uClinux-dev] Ide drivers
> 
> 
> Hi Fabrice,
> 
> Fabrice Gautier wrote:
> 
> > Anybdody ever used the ide driver with uClinux? To what 
> extent is it working
> 
> 
> Yes, I have used it alot. It works perfectly.
> 
> I have used it on 2 separate ColdFire based designs,
> with IDE hard drives, CD-ROMs and DVD drives.
> 
> 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

This message resent by the uclinux-dev at uclinux.org list server
http://www.uClinux.org/
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From davidb at cvs.com.au  Thu Apr 18 13:40:04 2002
From: davidb at cvs.com.au (David Braendler)
Date: Thu, 18 Apr 2002 10:40:04 -0700
Subject: [uClinux-dev] Problems compiling gdb-bdm
References: <8CCBDD5583C50E4196F012E79439B45C620226@atl-ms1.megatrends.com> <3CBD2DDF.4060204@cc.umanitoba.ca> <3CBD8686.F1C021D0@earthlink.net>
Message-ID: <004601c1e700$16a9af40$ca00a8c0@dave2000>

Hi,
     I'm a newbie to linux, and am trying to compile the gdb-bdm package
(gdb-bdm-20010901.tar.gz) from cybertec. When I try to make the driver (in
/drivers/linux) I get the following error

/usr/include/linux/modversions.h:1: #error Modules should never use
kernel-headers system headers,
/usr/include/linux/modversions.h:2: #error but headers from an appropriate
kernel-source

What I think this means is that I have to point the usr directory to
somewhere else, but I'm not quite sure if this is right, or how to do this.

Any suggestions??

David Braendler
davidb at cvs.com.au
Electronic Engineer
Colour Vision Systems
11 Park Street
Bacchus Marsh 3340
Victoria, Australia
Ph  : +61 3 5367 6410
Fax : +61 3 5367 4480

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From gerg at snapgear.com  Wed Apr 17 21:19:36 2002
From: gerg at snapgear.com (Greg Ungerer)
Date: Thu, 18 Apr 2002 11:19:36 +1000
Subject: [uClinux-dev] Ide drivers
References: <B1F6452C89AFD411AE0800A0CC734C239DBBD3@EMAIL1>
Message-ID: <3CBE1F28.8060004@snapgear.com>

Hi Fabrice,

Fabrice Gautier wrote:

> Are you using DMA transferts or just PIO modes ? (I have some problem with
> DMA)


PIO modes only.

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

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From sheeliang at lit.org.sg  Wed Apr 17 22:56:24 2002
From: sheeliang at lit.org.sg (Chia Shee Liang)
Date: Thu, 18 Apr 2002 10:56:24 +0800
Subject: [uClinux-dev] Is ARM7TDMI powerful enough to play MP3s?
Message-ID: <20020418105624.A1223@localhost.localdomain>

Just a question, is ARM7TDMI on Integrator AP (not to mention a pathetic
BogoMIPS of 1.5) powerful enough to play MP3s?
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From jeff at arcturusnetworks.com  Wed Apr 17 23:21:20 2002
From: jeff at arcturusnetworks.com (D. Jeff Dionne)
Date: Thu, 18 Apr 2002 03:21:20 -0000
Subject: [uClinux-dev] Is ARM7TDMI powerful enough to play MP3s?
Message-ID: <200204180321.g3I3LKI14003@arcturusnetworks.com>

Chia Shee Liang <sheeliang at lit.org.sg> said:

> Just a question, is ARM7TDMI on Integrator AP (not to mention a pathetic
> BogoMIPS of 1.5) powerful enough to play MP3s?

Generally speaking, no.  Specifically how much you can do depends on
how optimized your code is.  ARM has an optimized implementation of
an MP3 decoder and if I remember correctly needed about 29MHz, I assume
with memory running 0 wait states, or with enough cache.  Something
like "mad" (an OpenSource interger MP3 decoder) is not going to be
anywhere close to that performance without some work.

> 



-- 
D. Jeff Dionne                                        
Jeff at ArcturusNetworks.com


This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From tczhao at linpus.com.tw  Thu Apr 18 00:44:00 2002
From: tczhao at linpus.com.tw (Zhao Tiecheng)
Date: Thu, 18 Apr 2002 12:44:00 +0800
Subject: [uClinux-dev]printf cannot run well
In-Reply-To: <20020412115525.A6547@beast.internal.moreton.com.au>
References: <20020412115525.A6547@beast.internal.moreton.com.au>
Message-ID: <02041812440000.05645@localhost.localdomain>


	When I porting uClibc to me MIPS board, I find that when I print information 
like that:
	for(;;)printf("call me \n");
throught one of a UART console driver, I get a result often short of some 
charactrers, such as:
call me 
came 
ca
call me

call me
cal
call 
	Is anybody can give me a hint? Is it because the buffer of printf(), of the 
driver of my UART?

-- 
Zhao Tiecheng
Linpus Infotech Inc.
1105-1106 Hong Cao Building,
421 Hong Cao Rd. Caohejing,
Shanghai 200233, PRC
Tel: 86-21-64951968, 64953152, 64855098
Fax: 86-21-64954968
http://www.linpus.com.tw
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From eauth at softsys.co.at  Thu Apr 18 02:41:31 2002
From: eauth at softsys.co.at (Erwin Authried)
Date: Thu, 18 Apr 2002 08:41:31 +0200
Subject: [uClinux-dev] Is ARM7TDMI powerful enough to play MP3s?
In-Reply-To: <20020418105624.A1223@localhost.localdomain>
Message-ID: <CBEPKHHODMBKHCMLAGBMEEMGCBAA.eauth@softsys.co.at>

Don't know about the performance of your CPU, but you may have a look at
Atmel's APP note "AT91R40807 for Audio Decoding Systems". With the AT91, it
is only possible by making use of the 32-bit/0-WS internal SRAM.

	http://www.atmel.com/atmel/acrobat/doc1346.pdf

-Erwin

> -----Ursprungliche Nachricht-----
> Von: owner-uclinux-dev at uclinux.org
> [mailto:owner-uclinux-dev at uclinux.org]Im Auftrag von Chia Shee Liang
> Gesendet: Donnerstag, 18. April 2002 04:56
> An: uclinux-dev at uclinux.org
> Betreff: [uClinux-dev] Is ARM7TDMI powerful enough to play MP3s?
>
>
> Just a question, is ARM7TDMI on Integrator AP (not to mention a pathetic
> BogoMIPS of 1.5) powerful enough to play MP3s?
> This message resent by the uclinux-dev at uclinux.org list server
> http://www.uClinux.org/
>
>


This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From udc at naftan.by  Thu Apr 18 05:39:30 2002
From: udc at naftan.by (Yurij Sysoev)
Date: Thu, 18 Apr 2002 11:39:30 +0200
Subject: [uClinux-dev] re: after kenel build
References: <1018983222.25368.137.camel@feedtheworms.win.trlabs.ca>
Message-ID: <3CBE9452.5070406@naftan.by>

Sami Kibria wrote:

> after i get the kernel and arm-elf tools all ready to go...what do i do
> do i download the kernel to flash or sram (now my kernel is

> right now 702 kilobytes so i am assuming flash, but to what address???)


Take a look in file System.map (in root build directory).
In first lines, you should see something like

00000000 A fpe_exit
0c008000 ? __init_begin  <---- It is an initial address of loading
0c008000 ? _stext             (and starting) of the raw kernel image.
.....

For build raw binary image from ELF file named "linux", you
must use "arm-elf-objcopy" utility:

$ arm-elf-objcopy.exe -O binary linux ram.bin

Yurij


This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From mathias.fritzson at mecel.se  Thu Apr 18 06:46:45 2002
From: mathias.fritzson at mecel.se (mathias.fritzson at mecel.se)
Date: Thu, 18 Apr 2002 12:46:45 +0200
Subject: [uClinux-dev] elf2flt truncation error
Message-ID: <200204181045.g3IAjne20698@uclinux.org>

Hi

Got a little problem here.. I don't know if we have to change our
elf2flt.ld file, is it supposed to be generic ?

Anyway we haven't changed anything, yet..
We get the error below during the compilation:

Anyone that got a clue, we havn't hacked anything in sash, the distribution
is from 20011112, binfmt_flat.c and flat.h are the latest from the CVS

TIA

/Mathias

-----8<-------
m68k-elf-gcc -D__ELF__ -D__linux__ -Os -g -fomit-frame-pointer  -Dlinux -D__linu
x__ -Dunix -D__uClinux__ -DEMBED -I/usr/local/src/uClinux-dist/lib/uClibc/includ
e -I/usr/local/src/uClinux-dist/lib/libm -I/usr/local/src/uClinux-dist -fno-buil
tin -msep-data -I/usr/local/src/uClinux-dist/linux/include -Wl,-elf2flt -o sh sa
sh.o cmds.o cmd_uclinux.o ls.o ps.o hexdump.o df.o free.o hostname.o date.o libs
ash/libsash.a -L/usr/local/src/uClinux-dist/lib/uClibc/. -L/usr/local/src/uClinu
x-dist/lib/uClibc/lib -L/usr/local/src/uClinux-dist/lib/libm -L/usr/local/src/uC
linux-dist/lib/libnet -L/usr/local/src/uClinux-dist/lib/libdes -L/usr/local/src/
uClinux-dist/lib/libpcap -L/usr/local/src/uClinux-dist/lib/libssl -lc
sh.elf2flt: In function `main':
/usr/local/src/uClinux-dist/user/sash/sash.c:242: relocation truncated to fit: R
_68K_PLT16 __main
sh.elf2flt: In function `readfile':
/usr/local/src/uClinux-dist/user/sash/sash.c:345: relocation truncated to fit: R
_68K_PLT16 __errno_location
sh.elf2flt: In function `command_in_path':
/usr/local/src/uClinux-dist/lib/uClibc/include/sys/stat.h:318: relocation trunca
ted to fit: R_68K_PLT16 _xstat
/usr/local/src/uClinux-dist/lib/uClibc/include/sys/stat.h:318: relocation trunca
ted to fit: R_68K_PLT16 _xstat
sh.elf2flt: In function `runcmd':
/usr/local/src/uClinux-dist/user/sash/sash.c:702: relocation truncated to fit: R
_68K_PLT16 vfork
/usr/local/src/uClinux-dist/user/sash/sash.c:719: relocation truncated to fit: R
_68K_PLT16 execvp
/usr/local/src/uClinux-dist/user/sash/sash.c:749: relocation truncated to fit: R
_68K_PLT16 getpid
/usr/local/src/uClinux-dist/user/sash/sash.c:743: relocation truncated to fit: R
_68K_PLT16 wait4
sh.elf2flt: In function `do_exec':
/usr/local/src/uClinux-dist/user/sash/sash.c:935: relocation truncated to fit: R
_68K_PLT16 execvp
sh.elf2flt: In function `showprompt':
/usr/local/src/uClinux-dist/user/sash/sash.c:989: relocation truncated to fit: R
_68K_PLT16 getcwd
sh.elf2flt: In function `catchchild':
/usr/local/src/uClinux-dist/user/sash/sash.c:1028: relocation truncated to fit:
R_68K_PLT16 wait4
sh.elf2flt: In function `do_pwd':
/usr/local/src/uClinux-dist/user/sash/cmds.c:53: relocation truncated to fit: R_
68K_PLT16 getcwd
sh.elf2flt: In function `do_time':
/usr/local/src/uClinux-dist/user/sash/cmds.c:66: relocation truncated to fit: R_
68K_PLT16 gettimeofday
sh.elf2flt: In function `do_sleep':
/usr/local/src/uClinux-dist/user/sash/cmds.c:107: relocation truncated to fit: R
_68K_PLT16 sleep
sh.elf2flt: In function `do_chown':
/usr/local/src/uClinux-dist/lib/uClibc/include/sys/stat.h:318: relocation trunca
ted to fit: R_68K_PLT16 _xstat
sh.elf2flt: In function `do_chown':
/usr/local/src/uClinux-dist/user/sash/cmds.c:268: relocation truncated to fit: R
_68K_PLT16 chown
sh.elf2flt: In function `do_chgrp':
/usr/local/src/uClinux-dist/user/sash/cmds.c:309: relocation truncated to fit: R
_68K_PLT16 chown
collect2: ld returned 1 exit status
make[2]: *** [sh] Error 1
make[2]: Leaving directory `/usr/local/src/uClinux-dist/user/sash'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/usr/local/src/uClinux-dist/user'

--->8------




This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From davidm at snapgear.com  Thu Apr 18 08:05:19 2002
From: davidm at snapgear.com (David McCullough)
Date: Thu, 18 Apr 2002 22:05:19 +1000
Subject: [uClinux-dev] elf2flt truncation error
In-Reply-To: <200204181045.g3IAjne20698@uclinux.org>; from mathias.fritzson@mecel.se on Thu, Apr 18, 2002 at 12:46:45PM +0200
References: <200204181045.g3IAjne20698@uclinux.org>
Message-ID: <20020418220519.A26343@beast.internal.moreton.com.au>

Jivin mathias.fritzson at mecel.se lays it down ...
> Hi
> 
> Got a little problem here.. I don't know if we have to change our
> elf2flt.ld file, is it supposed to be generic ?
> 
> Anyway we haven't changed anything, yet..
> We get the error below during the compilation:
> 
> Anyone that got a clue, we havn't hacked anything in sash, the distribution
> is from 20011112, binfmt_flat.c and flat.h are the latest from the CVS


>from the trace below,  I don't see any '-m68XXX' or '-m52XXX' type options.
I don't know any uClinux targets that will work without a CPU target.

Add this to the all the appropriate places in your config.arch, check
another target like 3com/Xcopilot for an example of where to put them,
Xcopilot used -m68000.  I am sure once you do this the errors will go away.
Be sure to "make clean" before trying again ;-)

Cheers,
Davidm



> -----8<-------
> m68k-elf-gcc -D__ELF__ -D__linux__ -Os -g -fomit-frame-pointer  -Dlinux -D__linu
> x__ -Dunix -D__uClinux__ -DEMBED -I/usr/local/src/uClinux-dist/lib/uClibc/includ
> e -I/usr/local/src/uClinux-dist/lib/libm -I/usr/local/src/uClinux-dist -fno-buil
> tin -msep-data -I/usr/local/src/uClinux-dist/linux/include -Wl,-elf2flt -o sh sa
> sh.o cmds.o cmd_uclinux.o ls.o ps.o hexdump.o df.o free.o hostname.o date.o libs
> ash/libsash.a -L/usr/local/src/uClinux-dist/lib/uClibc/. -L/usr/local/src/uClinu
> x-dist/lib/uClibc/lib -L/usr/local/src/uClinux-dist/lib/libm -L/usr/local/src/uC
> linux-dist/lib/libnet -L/usr/local/src/uClinux-dist/lib/libdes -L/usr/local/src/
> uClinux-dist/lib/libpcap -L/usr/local/src/uClinux-dist/lib/libssl -lc
> sh.elf2flt: In function `main':
> /usr/local/src/uClinux-dist/user/sash/sash.c:242: relocation truncated to fit: R
> _68K_PLT16 __main
> sh.elf2flt: In function `readfile':
> /usr/local/src/uClinux-dist/user/sash/sash.c:345: relocation truncated to fit: R
> _68K_PLT16 __errno_location
> sh.elf2flt: In function `command_in_path':
> /usr/local/src/uClinux-dist/lib/uClibc/include/sys/stat.h:318: relocation trunca
> ted to fit: R_68K_PLT16 _xstat
> /usr/local/src/uClinux-dist/lib/uClibc/include/sys/stat.h:318: relocation trunca
> ted to fit: R_68K_PLT16 _xstat
> sh.elf2flt: In function `runcmd':
> /usr/local/src/uClinux-dist/user/sash/sash.c:702: relocation truncated to fit: R
> _68K_PLT16 vfork
> /usr/local/src/uClinux-dist/user/sash/sash.c:719: relocation truncated to fit: R
> _68K_PLT16 execvp
> /usr/local/src/uClinux-dist/user/sash/sash.c:749: relocation truncated to fit: R
> _68K_PLT16 getpid
> /usr/local/src/uClinux-dist/user/sash/sash.c:743: relocation truncated to fit: R
> _68K_PLT16 wait4
> sh.elf2flt: In function `do_exec':
> /usr/local/src/uClinux-dist/user/sash/sash.c:935: relocation truncated to fit: R
> _68K_PLT16 execvp
> sh.elf2flt: In function `showprompt':
> /usr/local/src/uClinux-dist/user/sash/sash.c:989: relocation truncated to fit: R
> _68K_PLT16 getcwd
> sh.elf2flt: In function `catchchild':
> /usr/local/src/uClinux-dist/user/sash/sash.c:1028: relocation truncated to fit:
> R_68K_PLT16 wait4
> sh.elf2flt: In function `do_pwd':
> /usr/local/src/uClinux-dist/user/sash/cmds.c:53: relocation truncated to fit: R_
> 68K_PLT16 getcwd
> sh.elf2flt: In function `do_time':
> /usr/local/src/uClinux-dist/user/sash/cmds.c:66: relocation truncated to fit: R_
> 68K_PLT16 gettimeofday
> sh.elf2flt: In function `do_sleep':
> /usr/local/src/uClinux-dist/user/sash/cmds.c:107: relocation truncated to fit: R
> _68K_PLT16 sleep
> sh.elf2flt: In function `do_chown':
> /usr/local/src/uClinux-dist/lib/uClibc/include/sys/stat.h:318: relocation trunca
> ted to fit: R_68K_PLT16 _xstat
> sh.elf2flt: In function `do_chown':
> /usr/local/src/uClinux-dist/user/sash/cmds.c:268: relocation truncated to fit: R
> _68K_PLT16 chown
> sh.elf2flt: In function `do_chgrp':
> /usr/local/src/uClinux-dist/user/sash/cmds.c:309: relocation truncated to fit: R
> _68K_PLT16 chown
> collect2: ld returned 1 exit status
> make[2]: *** [sh] Error 1
> make[2]: Leaving directory `/usr/local/src/uClinux-dist/user/sash'
> make[1]: *** [all] Error 2
> make[1]: Leaving directory `/usr/local/src/uClinux-dist/user'
> 
> --->8------

-- 
David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
davidm at snapgear.com  Fx: +61 7 3891 3630  825 Stanley St., W'gabba QLD 4102, Oz
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From mathias.fritzson at mecel.se  Thu Apr 18 07:55:19 2002
From: mathias.fritzson at mecel.se (mathias.fritzson at mecel.se)
Date: Thu, 18 Apr 2002 13:55:19 +0200
Subject: [uClinux-dev] elf2flt truncation error
Message-ID: <200204181154.g3IBsKe21039@uclinux.org>



Thought that I should add that we use the latest toolchain, the one just a
few days old..

/Mathias

Mathias wrote:
>Hi
>
>Got a little problem here.. I don't know if we have to change our
>elf2flt.ld file, is it supposed to be generic ?
>
>Anyway we haven't changed anything, yet..
>We get the error below during the compilation:
>
>Anyone that got a clue, we havn't hacked anything in sash, the
distribution
>is from 20011112, binfmt_flat.c and flat.h are the latest from the CVS
>
>TIA
>
>/Mathias

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From davidm at snapgear.com  Thu Apr 18 08:23:39 2002
From: davidm at snapgear.com (David McCullough)
Date: Thu, 18 Apr 2002 22:23:39 +1000
Subject: [uClinux-dev]printf cannot run well
In-Reply-To: <02041812440000.05645@localhost.localdomain>; from tczhao@linpus.com.tw on Thu, Apr 18, 2002 at 12:44:00PM +0800
References: <20020412115525.A6547@beast.internal.moreton.com.au> <02041812440000.05645@localhost.localdomain>
Message-ID: <20020418222339.C26343@beast.internal.moreton.com.au>


Jivin Zhao Tiecheng lays it down ...
> 
> 	When I porting uClibc to me MIPS board, I find that when I print information 
> like that:
> 	for(;;)printf("call me \n");
> throught one of a UART console driver, I get a result often short of some 
> charactrers, such as:
> call me 
> came 
> ca
> call me
> 
> call me
> cal
> call 
> 	Is anybody can give me a hint? Is it because the buffer of printf(), of the 
> driver of my UART?

What baudrate are you running at ?

If its a high rate (like 115200) it may be possible that your host port is
over-running and dropping characters ?  At 9600 I would be looking at the
SW in the MIP's board,  esp. the serial driver,

Cheers,
Davidm

-- 
David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
davidm at snapgear.com  Fx: +61 7 3891 3630  825 Stanley St., W'gabba QLD 4102, Oz
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From hamilton at SEDSystems.ca  Thu Apr 18 10:59:58 2002
From: hamilton at SEDSystems.ca (Kendrick Hamilton)
Date: Thu, 18 Apr 2002 08:59:58 -0600 (CST)
Subject: [uClinux-dev] Maximum number of files a process can have open
Message-ID: <Pine.LNX.4.44.0204180856450.1818-100000@sw-55.sedsystems.ca>

Hi,
	We are using the 2.0.x kernel on a 68360. Our application program
needs a lot of files open. The current limit is 128. We need about 300.
Does anybody know where the limit is set or what all is needed to change
this limit?.
TIA,
Kendrick


This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From ilatypov at superbt.com  Thu Apr 18 14:03:28 2002
From: ilatypov at superbt.com (Ilguiz Latypov)
Date: Thu, 18 Apr 2002 14:03:28 -0400 (EDT)
Subject: [uClinux-dev] Maximum number of files a process can have open
In-Reply-To: <Pine.LNX.4.44.0204180856450.1818-100000@sw-55.sedsystems.ca>
Message-ID: <Pine.LNX.4.44.0204181400570.15213-100000@server.superbt.com>


There is a run-time configuration parameter in uClinux 2.4.x:
    # cat /proc/sys/fs/file-max
    8192
    #

My 2.2.20pre9 Linux/i386 box has the same parameter.

I wonder if a similar parameter exists in 2.0.x kernels.

Ilguiz

On Thu, 18 Apr 2002, Kendrick Hamilton wrote:

> 	We are using the 2.0.x kernel on a 68360. Our application program
> needs a lot of files open. The current limit is 128. We need about 300.

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From Subashk at ami.com  Thu Apr 18 18:05:44 2002
From: Subashk at ami.com (Subash Kalbarga)
Date: Thu, 18 Apr 2002 18:05:44 -0400
Subject: [uClinux-dev] FEC problem with 10 mbps
Message-ID: <8CCBDD5583C50E4196F012E79439B45C62029D@atl-ms1.megatrends.com>

Hi 
 
We have an application that does large network packets...
 
If the FEC on the coldfire is connected to 100 mbps there are absolutely no
problems
 
However if I connect it to a 10mbps hub ..it immediately starts giving
transmit timeout messages... with buffers full and NETDEV WATCHDOG: eth0:
transmit timed out
 
Has anyone seen this buffer and can I do something about it? 
 
Thanks in advance
Subash
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20020418/5d57b0ef/attachment.html>

From SMerrifield at tecom.com.au  Thu Apr 18 19:42:57 2002
From: SMerrifield at tecom.com.au (Steven Merrifield)
Date: Fri, 19 Apr 2002 01:42:57 +0200
Subject: [uClinux-dev] Maximum number of files a process can have open
Message-ID: <7FF1185EA0D3D511BC0500B0D0D0C24A1B5AC2@melexc01.ap.ilxi.net>

> 	We are using the 2.0.x kernel on a 68360. Our 
> application program
> needs a lot of files open. The current limit is 128. We need 
> about 300.
> Does anybody know where the limit is set or what all is 
> needed to change


Hi Kendrick,

Look at linux/fs/file_table.c:

	int max_files = NR_FILE;

and then look in linux/include/linux/fs.h:

You may need to change NR_OPEN, NR_INODE and NR_FILE

steve
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From gerg at snapgear.com  Thu Apr 18 20:03:17 2002
From: gerg at snapgear.com (Greg Ungerer)
Date: Fri, 19 Apr 2002 10:03:17 +1000
Subject: [uClinux-dev] FEC problem with 10 mbps
References: <8CCBDD5583C50E4196F012E79439B45C62029D@atl-ms1.megatrends.com>
Message-ID: <3CBF5EC5.4090007@snapgear.com>


Hi Subash,

Subash Kalbarga wrote:

> We have an application that does large network packets...
> 
> If the FEC on the coldfire is connected to 100 mbps there are absolutely 
> no problems
> 
> However if I connect it to a 10mbps hub ..it immediately starts giving 
> transmit timeout messages... with buffers full and NETDEV WATCHDOG: 
> eth0: transmit timed out
> 
> Has anyone seen this buffer and can I do something about it?


I have recently had reported a similar problem. What kernel
version are you using?

I added some extra code to deal with watchdog timeouts better
in fec.c in uClinux-2.4.x. I also added some trace to get a
better idea of the interrupt status. If you are using 2.4 can
you try this out and let me know what happens?

(The new code is at cvs.uclinux.org).

Thanks
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

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From tczhao at linpus.com.tw  Thu Apr 18 21:08:14 2002
From: tczhao at linpus.com.tw (Zhao Tiecheng)
Date: Fri, 19 Apr 2002 09:08:14 +0800
Subject: [uClinux-dev]printf cannot run well
References: <20020412115525.A6547@beast.internal.moreton.com.au> <02041812440000.05645@localhost.localdomain> <20020418222339.C26343@beast.internal.moreton.com.au>
Message-ID: <001b01c1e73e$af893d00$1801a8c0@111111>

    Think you very much! my baud rate is 115200, may be as you said.:)
Zhao Tiecheng

----- Original Message ----- 
From: "David McCullough" <davidm at snapgear.com>
To: <uclinux-dev at uclinux.org>
Sent: Thursday, April 18, 2002 8:23 PM
Subject: Re: [uClinux-dev]printf cannot run well


> 
> Jivin Zhao Tiecheng lays it down ...
> > 
> > When I porting uClibc to me MIPS board, I find that when I print information 
> > like that:
> > for(;;)printf("call me \n");
> > throught one of a UART console driver, I get a result often short of some 
> > charactrers, such as:
> > call me 
> > came 
> > ca
> > call me
> > 
> > call me
> > cal
> > call 
> > Is anybody can give me a hint? Is it because the buffer of printf(), of the 
> > driver of my UART?
> 
> What baudrate are you running at ?
> 
> If its a high rate (like 115200) it may be possible that your host port is
> over-running and dropping characters ?  At 9600 I would be looking at the
> SW in the MIP's board,  esp. the serial driver,
> 
> Cheers,
> Davidm
> 
> -- 
> David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
> davidm at snapgear.com  Fx: +61 7 3891 3630  825 Stanley St., W'gabba QLD 4102, Oz
> This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From Fabrice_Gautier at sdesigns.com  Thu Apr 18 22:20:04 2002
From: Fabrice_Gautier at sdesigns.com (Fabrice Gautier)
Date: Thu, 18 Apr 2002 19:20:04 -0700
Subject: [uClinux-dev] Caches and DMA
Message-ID: <B1F6452C89AFD411AE0800A0CC734C239DBBD5@EMAIL1>

Hi,

Can someone tell me if the kernel expect DMA memory to be not cacheable? ie:
does the kernel sync the caches after a DMA transfert or does it expect this
memory not be cacheable/cached in the first place ? 

Thanks

-- 
Fabrice Gautier, 
Fabrice_Gautier at sdesigns.com
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From davidm at snapgear.com  Fri Apr 19 00:16:37 2002
From: davidm at snapgear.com (David McCullough)
Date: Fri, 19 Apr 2002 14:16:37 +1000
Subject: [uClinux-dev] Caches and DMA
In-Reply-To: <B1F6452C89AFD411AE0800A0CC734C239DBBD5@EMAIL1>; from Fabrice_Gautier@sdesigns.com on Thu, Apr 18, 2002 at 07:20:04PM -0700
References: <B1F6452C89AFD411AE0800A0CC734C239DBBD5@EMAIL1>
Message-ID: <20020419141637.A24148@beast.internal.moreton.com.au>


Jivin Fabrice Gautier lays it down ...
> Hi,
> 
> Can someone tell me if the kernel expect DMA memory to be not cacheable? ie:
> does the kernel sync the caches after a DMA transfert or does it expect this
> memory not be cacheable/cached in the first place ? 

I think it depends on your PCI implementation (HW).  I was working on a
SuperH a while back and I needed to flush/invalidate the areas I was using
for DMA to get sane behaviour.  It was hooked in somewhere quite cleanly, I
can dig it up if you like,

Cheers,
Davidm

-- 
David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
davidm at snapgear.com  Fx: +61 7 3891 3630  825 Stanley St., W'gabba QLD 4102, Oz
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From vinayak at ionicmicro.com  Fri Apr 19 02:31:47 2002
From: vinayak at ionicmicro.com (Vinayak Kore)
Date: Fri, 19 Apr 2002 12:01:47 +0530
Subject: [uClinux-dev] Caches and DMA
Message-ID: <01C1E799.FC084EE0@VINAYAKA_98>

Fabrice,

I don't think its kernal problem.But many processors don't allow DMA to a cacheable memory. Eg. Coldfire (5307,5407), etc.
Check your processor manual for this.

Cheers !

Vinayak Kore

Can someone tell me if the kernel expect DMA memory to be not cacheable? ie:
does the kernel sync the caches after a DMA transfert or does it expect this
memory not be cacheable/cached in the first place ? 

Thanks

-- 
Fabrice Gautier, 



Note: 
   Unless otherwise noted, the information provided by this mail does not represent the official statements or views of Ionic Microsystems. 
   Privileged/Confidential information may be contained in this message and may be subject to legal privilege. Access to this e-mail by anyone other than the intended is unauthorised. If you are not the intended recipient (or responsible for delivery of the message to such person), you may not use, copy, distribute or deliver this message (or any part of its contents ) to anyone or take any action in reliance on it. In such case, you should destroy this message, and notify us immediately. If you have received this email in error, please notify us immediately by e-mail or telephone and delete the e-mail from any computer.
If you or your employer does not consent to internet e-mail messages of this kind, please notify us immediately. All reasonable precautions have been taken to ensure no viruses are present in this e-mail. As our company cannot accept responsibility for any loss or damage arising from the use of this e-mail or attachments we recommend that you subject these to your virus checking procedures prior to use.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/ms-tnef
Size: 1988 bytes
Desc: not available
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20020419/29614f80/attachment.bin>

From lgltoludo at yahoo.fr  Fri Apr 19 05:10:49 2002
From: lgltoludo at yahoo.fr (=?iso-8859-1?q?Ludo=20G.L.?=)
Date: Fri, 19 Apr 2002 11:10:49 +0200 (CEST)
Subject: [uClinux-dev] Questions about uClinux and M5307C3 
Message-ID: <20020419091049.80460.qmail@web20004.mail.yahoo.com>

Hello everyone.

I work on the M5307C3 Motorola's board (which function
with a ColdFire ?processor).
And, I have some newbie questions :

* Which is the difference detwin "flat" and "elf" ?
* Which version of the "m68k-elf-tools" do I have to
use (I will make a prog in C) ?
* Does uClinux (on M5307C3) suport the 2 serial ports
well ?
* Does uClinux (on M5307C3) suport the I/O ? And, if
yes, how can I program the I/O ?

                     Ludovic GUILLET
                    lgltoludo at yahoo.fr

"Thank-you" for who will answer !


___________________________________________________________
Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en fran?ais !
Yahoo! Mail : http://fr.mail.yahoo.com
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From mathias.fritzson at mecel.se  Fri Apr 19 07:24:01 2002
From: mathias.fritzson at mecel.se (mathias.fritzson at mecel.se)
Date: Fri, 19 Apr 2002 13:24:01 +0200
Subject: [uClinux-dev] Developer panic, can't open a console
Message-ID: <200204191122.g3JBMse27160@uclinux.org>

Hello again,

Thanks for the latest tip David, the -m68000 flag worked..

Now back to our romfs problem.

Equipment: Mandrake 8.2, latest toolchain, source from 20011112 with tha
latest binfmt_flat.c and flat.h from CVS.

Problem: Romfs mounts but I cannot open any files or devices. I'll paste
log below, it includes some of my own debug messages. I want to be able to
follow the "open" command but I can't locate the function in the codebase
and it doesn't show in the System.map file, although the kernel links OK.

Any tips or suggestions ??

I'll append my latest roms image if someone would like to try it out to see
that it's correct, I still look for a romfs, compiled for the 683* uC, to
test with our kernel.

Thanks  a lot

/Mathias

Startup log:

....
Memory available: 580k/1019k RAM, 512k/512k ROM (199k kernel code, 107k data), 3
3 pages reserved (132k)
DEBUG: mem_init
DEBUG: buffer_init
Swansea University Computer Society NET3.035 for Linux 2.0
NET3: Unix domain sockets 0.13 for Linux NET3.035.
DEBUG: sock_init
DEBUG: dquot_init
DEBUG: arch_syms_export
DEBUG: check_bugs
uClinux version 2.0.39.1 (root at meg-109.mecel.net) (gcc version 2.95.3 20010315 (
release)(ColdFire patches - 20010318 from http://fiddes.net/coldfire/)(-msep-dat
a patches)) 22 Fri Apr 19 13:39:05 CEST 2002
DEBUG: printk(linux_banner)
DEBUG: sysctl_init()
DEBUG: kernel_thread
MC68332 serial driver version 1.00
ttyS0 is a builtin MC68332 UART
DEBUG: after chr_dev_init
DEBUG: inside blkmem_init, sizeof(arena): 26, sizeof(struct arena_t): 26, arena[
0].address: 84d260, arenas: 1
Blkmem copyright 1998,1999 D. Jeff Dionne
Blkmem copyright 1998 Kenneth Albanowski
Blkmem 1 disk images:
0: 84D260-867A5F (RO)
VFS: Mounted root (romfs filesystem) readonly.
Unable to open an initial console.
DEBUG: /test did not open
DEBUG: /bin/test did not open
DEBUG: /dev/test did not open
DEBUG: /etc/test did not open
DEBUG: trying to run init
BINFMT_FLAT: reloc outside program 0x80000080 (0 - 0xa1718), killing!
BINFMT_FLAT: reloc outside program 0x80000080 (0 - 0xa1718), killing!
....

And  the promised romfs image as an attatchment

(See attached file: romfs.img)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: romfs.img
Type: application/octet-stream
Size: 108544 bytes
Desc: not available
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20020419/0c650ab4/attachment.obj>

From Subashk at ami.com  Fri Apr 19 14:45:46 2002
From: Subashk at ami.com (Subash Kalbarga)
Date: Fri, 19 Apr 2002 14:45:46 -0400
Subject: [uClinux-dev] FEC problem with 10 mbps
Message-ID: <8CCBDD5583C50E4196F012E79439B45C6202BB@atl-ms1.megatrends.com>

Hi Greg

I am using 2.4.10 kernel with the November 20001 snapshot

Here is a dump (part of it) that shows the error that happens


eth0: status: link down.
eth0: status: link up, 100MBit Full Duplex, auto-negotiation complete.
eth0: status: link down.
eth0: status: link up, 10MBit Half Duplex, auto-negotiation complete.
NETDEV WATCHDOG: eth0: transmit timed out
eth0: transmit timed out.
Ring data dump: cur_tx 35e058, dirty_tx 35e058 cur_rx: 35e018
 tx: 8 buffers
  0035e040: 1c00 05ea 005e686a
  0035e048: 1c0c 05ea 005e706a
  0035e050: 1c00 05ea 0063606a
  0035e058: 1c0c 05ea 005ec86a
  0035e060: 1c00 05ea 005ec06a
  0035e068: 1c08 05ea 005ea06a
  0035e070: 1c00 05ea 005ea86a
  0035e078: 3c04 05ea 005e606a
 rx: 8 buffers
  0035e000: 8800 005e 0035d000
  0035e008: 8800 015a 0035d800
  0035e010: 8800 01a2 0035c000
  0035e018: 8800 0040 0035c800
  0035e020: 8800 0040 0035b000
  0035e028: 8800 0040 0035b800
  0035e030: 8800 0040 0035a000
  0035e038: a800 0040 0035a800
fec.c(472): ievent=0 imask=f800000
fec.c(474): reseting interface.
NETDEV WATCHDOG: eth0: transmit timed out
eth0: transmit timed out.
Ring data dump: cur_tx 35e040, dirty_tx 35e040 cur_rx: 35e030
 tx: 8 buffers
  0035e040: 1c00 05ea 005da06a
  0035e048: 1c00 019a 005da86a
  0035e050: 1c00 05ea 0073986a
  0035e058: 1c04 05ea 0063686a
  0035e060: 1c04 05ea 005e786a
  0035e068: 1c04 05ea 005f306a
  0035e070: 1c04 05ea 005f386a
  0035e078: 3c04 05ea 005e586a
 rx: 8 buffers
  0035e000: 8800 0040 0035d000
  0035e008: 8800 0040 0035d800
  0035e010: 8800 0040 0035c000
  0035e018: 8800 0040 0035c800
  0035e020: 8800 01a2 0035b000
  0035e028: 8800 05ee 0035b800
  0035e030: 8000 0040 0035a000
  0035e038: a000 0040 0035a800
fec.c(472): ievent=0 imask=f800000
fec.c(474): reseting interface.
NETDEV WATCHDOG: eth0: transmit timed out
eth0: transmit timed out.
Ring data dump: cur_tx 35e040, dirty_tx 35e040 cur_rx: 35e038
 tx: 8 buffers


Thanks in advance Greg

Subash


-----Original Message-----
From: Greg Ungerer [mailto:gerg at snapgear.com] 
Sent: Thursday, April 18, 2002 8:03 PM
To: uclinux-dev at uclinux.org
Subject: Re: [uClinux-dev] FEC problem with 10 mbps


Hi Subash,

Subash Kalbarga wrote:

> We have an application that does large network packets...
> 
> If the FEC on the coldfire is connected to 100 mbps there are absolutely 
> no problems
> 
> However if I connect it to a 10mbps hub ..it immediately starts giving 
> transmit timeout messages... with buffers full and NETDEV WATCHDOG: 
> eth0: transmit timed out
> 
> Has anyone seen this buffer and can I do something about it?


I have recently had reported a similar problem. What kernel
version are you using?

I added some extra code to deal with watchdog timeouts better
in fec.c in uClinux-2.4.x. I also added some trace to get a
better idea of the interrupt status. If you are using 2.4 can
you try this out and let me know what happens?

(The new code is at cvs.uclinux.org).

Thanks
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

This message resent by the uclinux-dev at uclinux.org list server
http://www.uClinux.org/
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From bkuhn at lineo.com  Fri Apr 19 16:00:18 2002
From: bkuhn at lineo.com (Bernhard Kuhn)
Date: Fri, 19 Apr 2002 22:00:18 +0200
Subject: [uClinux-dev] RPM spec files for arm-elf and m68k-elf toolchains
Message-ID: <3CC07752.C650A70B@lineo.com>


Hi everybody!

i have put together some RPM spec files in order to
generate RPM packages for the arm-elf and m68k-elf
toolchains. Unlike the previous versions of the
spec files (for m68k-elf), this files will directly
execute davidm's build script so that keeping
up the spec files with the sources to come in the future
will be much easier than it was in the past.

Due to lack of disk space at my current ISP,
i can't provide the RPMs directly :-(

More details can be found at:

http://home.t-online.de/home/Bernhard_Kuhn/uclinux/Toolchain/20020418/README


best regards

Bernhard


--- 8< ---
Generating RPM packages for uClinux arm-elf and m68k-elf toolchains
===================================================================

This document describes the necessary instructions
in order to get RPM packages for binutils, gcc, g++,
libraries and genromfs on RedHat 6.2 and RedHat 7.1.



Downloading Sources and Patches
-------------------------------

cd /usr/src/redhat/SOURCES 

DL=http://www.uclinux.org/pub/uClinux/m68k-elf-tools/tools-20020410
wget $DL/build-uclinux-tools.sh
wget $DL/binutils-2.10.tar.bz2
wget $DL/binutils-2.10-full.patch
wget $DL/gcc-2.95.3.tar.gz
wget $DL/gcc-2.95.3-arm-mlib.patch
wget $DL/gcc-2.95.3-arm-pic.patch
wget $DL/gcc-2.95.3-arm-pic.patch2
wget $DL/gcc-2.95.3-full.patch
wget $DL/gcc-2.95.3-sigset.patch
wget $DL/uClibc.tar.gz
wget $DL/genromfs-0.5.1.tar.gz

DL=http://www.uclinux.org/ports/coldfire
wget $DL/uClinux-dist-20020411.tar.gz

DL=http://home.t-online.de/home/Bernhard_Kuhn/uclinux/Toolchain/20020418/SOURCES
wget $DL/patch-generic-build-uclinux-tools.sh
wget $DL/arm-elf-kernel.config
wget $DL/m68k-elf-kernel.config
wget $DL/elf2flt-20020418.tar.gz



Downloading the SPEC files
--------------------------

cd /usr/src/redhat/SPECS
DL=http://home.t-online.de/home/Bernhard_Kuhn/uclinux/Toolchain/arm-elf/20020418/SPECS
wget uClinux-toolchain-arm-elf-0.9.5-1.spec
wget uClinux-toolchain-m68k-elf-0.9.5-1.spec
wget uClinux-toolchain-genromfs-0.9.5-1.spec




Building the RPM packages
-------------------------

cd /usr/src/redhat/SPECS
rpm -ba uClinux-toolchain-genromfs-0.9.5-1.spec
rm -rf /usr/src/redhat/BUILD/*
rpm -ba uClinux-toolchain-arm-elf-0.9.5-1.spec
rm -rf /usr/src/redhat/BUILD/*
rpm -ba uClinux-toolchain-m68k-elf-0.9.5-1.spec



Installing the RPM packages
---------------------------

cd /usr/src/redhat/RPMS/i386
rpm -i uClinux-toolchain-arm-elf-*-0.9.5-1.rpm
rpm -i uClinux-toolchain-m68k-elf-*-0.9.5-1.rpm
rpm -i uClinux-toolchain-genromfs-0.9.5-1.i386.rpm
--- >8 ---


-- 
Bernhard Kuhn, Software Engineer, Lineo Inc. (Where Open Meets Smart)
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From philwil at earthlink.net  Fri Apr 19 21:59:51 2002
From: philwil at earthlink.net (Phil Wilshire)
Date: Fri, 19 Apr 2002 21:59:51 -0400
Subject: [uClinux-dev] RPM spec files for arm-elf and m68k-elf toolchains
References: <3CC07752.C650A70B@lineo.com>
Message-ID: <3CC0CB97.3FABA8D6@earthlink.net>

Hi Bernhard
I am getting 404 errors when trying to access the SPECS files...

Hope you are well !!
Phil Wilshire

Bernhard Kuhn wrote:
> 
> Hi everybody!
> 
> i have put together some RPM spec files in order to
> generate RPM packages for the arm-elf and m68k-elf
> toolchains. Unlike the previous versions of the
> spec files (for m68k-elf), this files will directly
> execute davidm's build script so that keeping
> up the spec files with the sources to come in the future
> will be much easier than it was in the past.
> 
> Due to lack of disk space at my current ISP,
> i can't provide the RPMs directly :-(
> 
> More details can be found at:
> 
> http://home.t-online.de/home/Bernhard_Kuhn/uclinux/Toolchain/20020418/README
> 
> best regards
> 
> Bernhard
> 
> --- 8< ---
> Generating RPM packages for uClinux arm-elf and m68k-elf toolchains
> ===================================================================
> 
> This document describes the necessary instructions
> in order to get RPM packages for binutils, gcc, g++,
> libraries and genromfs on RedHat 6.2 and RedHat 7.1.
> 
> Downloading Sources and Patches
> -------------------------------
> 
> cd /usr/src/redhat/SOURCES
> 
> DL=http://www.uclinux.org/pub/uClinux/m68k-elf-tools/tools-20020410
> wget $DL/build-uclinux-tools.sh
> wget $DL/binutils-2.10.tar.bz2
> wget $DL/binutils-2.10-full.patch
> wget $DL/gcc-2.95.3.tar.gz
> wget $DL/gcc-2.95.3-arm-mlib.patch
> wget $DL/gcc-2.95.3-arm-pic.patch
> wget $DL/gcc-2.95.3-arm-pic.patch2
> wget $DL/gcc-2.95.3-full.patch
> wget $DL/gcc-2.95.3-sigset.patch
> wget $DL/uClibc.tar.gz
> wget $DL/genromfs-0.5.1.tar.gz
> 
> DL=http://www.uclinux.org/ports/coldfire
> wget $DL/uClinux-dist-20020411.tar.gz
> 
> DL=http://home.t-online.de/home/Bernhard_Kuhn/uclinux/Toolchain/20020418/SOURCES
> wget $DL/patch-generic-build-uclinux-tools.sh
> wget $DL/arm-elf-kernel.config
> wget $DL/m68k-elf-kernel.config
> wget $DL/elf2flt-20020418.tar.gz
> 
> Downloading the SPEC files
> --------------------------
> 
> cd /usr/src/redhat/SPECS
> DL=http://home.t-online.de/home/Bernhard_Kuhn/uclinux/Toolchain/arm-elf/20020418/SPECS
> wget uClinux-toolchain-arm-elf-0.9.5-1.spec
> wget uClinux-toolchain-m68k-elf-0.9.5-1.spec
> wget uClinux-toolchain-genromfs-0.9.5-1.spec
> 
> Building the RPM packages
> -------------------------
> 
> cd /usr/src/redhat/SPECS
> rpm -ba uClinux-toolchain-genromfs-0.9.5-1.spec
> rm -rf /usr/src/redhat/BUILD/*
> rpm -ba uClinux-toolchain-arm-elf-0.9.5-1.spec
> rm -rf /usr/src/redhat/BUILD/*
> rpm -ba uClinux-toolchain-m68k-elf-0.9.5-1.spec
> 
> Installing the RPM packages
> ---------------------------
> 
> cd /usr/src/redhat/RPMS/i386
> rpm -i uClinux-toolchain-arm-elf-*-0.9.5-1.rpm
> rpm -i uClinux-toolchain-m68k-elf-*-0.9.5-1.rpm
> rpm -i uClinux-toolchain-genromfs-0.9.5-1.i386.rpm
> --- >8 ---
> 
> --
> Bernhard Kuhn, Software Engineer, Lineo Inc. (Where Open Meets Smart)
> This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From davidm at snapgear.com  Fri Apr 19 20:25:59 2002
From: davidm at snapgear.com (David McCullough)
Date: Sat, 20 Apr 2002 10:25:59 +1000
Subject: [uClinux-dev] Developer panic, can't open a console
In-Reply-To: <200204191122.g3JBMse27160@uclinux.org>; from mathias.fritzson@mecel.se on Fri, Apr 19, 2002 at 01:24:01PM +0200
References: <200204191122.g3JBMse27160@uclinux.org>
Message-ID: <20020420102559.A26433@beast.internal.moreton.com.au>


Jivin mathias.fritzson at mecel.se lays it down ...
> Hello again,
> 
> Thanks for the latest tip David, the -m68000 flag worked..

Ok,  but if you are using a 683XX,  is there an option specific for that ?
Check your kernel compile and see what options (-m options) are used.

> Now back to our romfs problem.
> 
> Equipment: Mandrake 8.2, latest toolchain, source from 20011112 with tha
> latest binfmt_flat.c and flat.h from CVS.
> 
> Problem: Romfs mounts but I cannot open any files or devices. I'll paste
> log below, it includes some of my own debug messages. I want to be able to

The trace below indicates to me that it actually opened init and tried to
run it,  but there was something wrong with the flat file.  I don't see any
files called test in the romfs.img,  but then I am not in a position to actually
mount it properly at the moment.

> follow the "open" command but I can't locate the function in the codebase
> and it doesn't show in the System.map file, although the kernel links OK.

look for sys_open.

> Any tips or suggestions ??

Double check all your compiler options in your config.arch.  Make sure they
are correct for your target.  Use other examples from the source tree to
work out what is needed.

You could remove romfs/bin/init,  the kernel will then try and run /bin/sh
as a last resort,  see if "sh" works any better than init.

> I'll append my latest roms image if someone would like to try it out to see
> that it's correct, I still look for a romfs, compiled for the 683* uC, to
> test with our kernel.

Send me a copy of your romfs/bin/init (off the list ;-) and I'll have a look at
it.

Cheers,
Davidm

-- 
David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
davidm at snapgear.com  Fx: +61 7 3891 3630  825 Stanley St., W'gabba QLD 4102, Oz
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From hamilton at SEDSystems.ca  Fri Apr 19 23:12:32 2002
From: hamilton at SEDSystems.ca (Kendrick Hamilton)
Date: Fri, 19 Apr 2002 21:12:32 -0600 (CST)
Subject: [uClinux-dev] select time out error
Message-ID: <Pine.LNX.4.44.0204192103530.3304-100000@sw-55.sedsystems.ca>

Hi,
	I am using m68k-elf tools on a 68360. The tools are february 18,
2002. uClibc is also from february 18, 2002 (the version included with the
tools). My program calls a select with a time out of 6 seconds but is
taking 30 seconds to time out. If there is activity in that time, the time
structure is decremented so it goes to zero after 30 seconds. This time
out is critical to the system working. I am also monitoring the system's
uptime using uptime and uptime is keeping track of time very well (it may
be off by a few seconds but not nearly this bad). Any suggestions?
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

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From xavier at vianet.ca  Fri Apr 19 23:15:42 2002
From: xavier at vianet.ca (Timothy Robb)
Date: Fri, 19 Apr 2002 23:15:42 -0400
Subject: [uClinux-dev] Power PC 403GB
Message-ID: <002401c1e819$a7832220$0a02a8c0@WorkGroup>

I'm writting to enquire if anyone has ported uclinux to
the Power PC 403 GB (or GA).  They are both IBM
Power PC microprocessors without MMU.  (I was
trying to get a "regular" version of linux compiled for
it when I read on the embedded powerpc howto that
they were not supported as they lack a mmu and it
suggested that one would look at the uclinux project.)

Thank you,
Timothy Robb

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From uclinux at schoeldgen.de  Sat Apr 20 08:44:32 2002
From: uclinux at schoeldgen.de (Matthias Schoeldgen)
Date: Sat, 20 Apr 2002 14:44:32 +0200
Subject: [uClinux-dev] Developer panic, can't open a console
References: <200204191122.g3JBMse27160@uclinux.org> <20020420102559.A26433@beast.internal.moreton.com.au>
Message-ID: <3CC162AF.6FACDED3@schoeldgen.de>

David McCullough wrote:
> 
> Jivin mathias.fritzson at mecel.se lays it down ...
> > Hello again,
> >
> > Thanks for the latest tip David, the -m68000 flag worked..
> 
> Ok,  but if you are using a 683XX,  is there an option specific for that ?
> Check your kernel compile and see what options (-m options) are used.
> 
> > Now back to our romfs problem.
> >
> > Equipment: Mandrake 8.2, latest toolchain, source from 20011112 with tha
> > latest binfmt_flat.c and flat.h from CVS.
> >
> > Problem: Romfs mounts but I cannot open any files or devices. I'll paste
> > log below, it includes some of my own debug messages. I want to be able to
> 
> The trace below indicates to me that it actually opened init and tried to
> run it,  but there was something wrong with the flat file.  I don't see any
> files called test in the romfs.img,  but then I am not in a position to actually
> mount it properly at the moment.
> 
> > follow the "open" command but I can't locate the function in the codebase
> > and it doesn't show in the System.map file, although the kernel links OK.
> 
> look for sys_open.
> 
> > Any tips or suggestions ??
> 
> Double check all your compiler options in your config.arch.  Make sure they
> are correct for your target.  Use other examples from the source tree to
> work out what is needed.
> 
> You could remove romfs/bin/init,  the kernel will then try and run /bin/sh
> as a last resort,  see if "sh" works any better than init.
> 
> > I'll append my latest roms image if someone would like to try it out to see
> > that it's correct, I still look for a romfs, compiled for the 683* uC, to
> > test with our kernel.
> 
> Send me a copy of your romfs/bin/init (off the list ;-) and I'll have a look at
> it.
> 
> Cheers,
> Davidm

Hello Mathias and David!
In the past i encountered problems with the default /dev/console device
created in simpleinit.c. I removed it and used /dev/ttyS0 explicitely in
my /etc/inittab. On my platform (uCsimm-68EZ328) /dev/console wasn't
properly usable. Another cause might be a non-existent /dev/* entry or
one with the wrong chmod flags, although this is highly unlikely when
using the new toolchains and source tree and a proper genromfs.

Good luck
Matthias
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From gerg at snapgear.com  Sat Apr 20 09:32:00 2002
From: gerg at snapgear.com (gerg)
Date: Sat, 20 Apr 2002 23:32:00 +1000
Subject: [uClinux-dev] Questions about uClinux and M5307C3
References: <20020419091049.80460.qmail@web20004.mail.yahoo.com>
Message-ID: <3CC16DD0.230DEE8A@snapgear.com>


Hi Ludovic,

"Ludo G.L." wrote:
> I work on the M5307C3 Motorola's board (which function
> with a ColdFire ?processor).
> And, I have some newbie questions :
> 
> * Which is the difference detwin "flat" and "elf" ?

FLAT is the native binary file format for uClinux.
FLAT files are created by a simple conversion from ELF
program files using the elf2flt utility. FLAT files are
compact, with just enough information to run a program
(no debug info, no symbold info, small headers, etc).


> * Which version of the "m68k-elf-tools" do I have to
> use (I will make a prog in C) ?

Use the most recent:

    http://www.uclinux.org/pub/uClinux/m68k-elf-tools


> * Does uClinux (on M5307C3) suport the 2 serial ports
> well ?

Yes, perfectly.


> * Does uClinux (on M5307C3) suport the I/O ? And, if
> yes, how can I program the I/O ?

There is no specific driver for them. But you can easily
code your own. Look at the ~/drivers/char/ledman.c
driver for an example.

Regards
Greg


------------------------------------------------------------------------
Greg Ungerer  --  Chief Software Wizard        EMAIL:  gerg at snapgear.com
Snapgear                                       PHONE:    +61 7 3279 1822
825 Stanley St,                                  FAX:    +61 7 3279 1820
Woolloongabba, QLD, 4102, Australia              WEB:   www.snapgear.com
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From bkuhn at lineo.com  Sat Apr 20 10:08:09 2002
From: bkuhn at lineo.com (Bernhard Kuhn)
Date: Sat, 20 Apr 2002 16:08:09 +0200
Subject: [uClinux-dev] Questions about uClinux and M5307C3
References: <20020419091049.80460.qmail@web20004.mail.yahoo.com> <3CC16DD0.230DEE8A@snapgear.com>
Message-ID: <3CC17649.7CE1CE9E@lineo.com>

gerg schrieb:
> 
> FLAT files are compact, with just enough information to run
> a program (no debug info, no symbold info, small headers, etc).

Just for the sake of completeness: although flat files don't
contain debugging information, they are still debuggable since
the relocation happens the same way it would happen with
an elf file. So you can use the gdbserver on the target
with the flat file and the elf-file (postfixed with .gdb)
along with the gdb on the host.


> > yes, how can I program the I/O ?

A quick and dirty way is to just access the hardware
registers from user space (unless protected by some
system configuration registers in the kernel - this
is true for some platforms). But i wouldn't recommend
that since it is the non portable way ...

best regards

Bernhard


-- 
Bernhard Kuhn, Software Engineer, Lineo Inc. (Where Open Meets Smart)
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From philwil at earthlink.net  Sat Apr 20 17:11:30 2002
From: philwil at earthlink.net (Phil Wilshire)
Date: Sat, 20 Apr 2002 17:11:30 -0400
Subject: [uClinux-dev] RPM spec files for arm-elf and m68k-elf toolchains
References: <3CC07752.C650A70B@lineo.com>
Message-ID: <3CC1D982.37345E6D@earthlink.net>

Bernhard
I am still getting a 404 error for the specs file.
http://home.t-online.de/home/Bernhard_Kuhn/uclinux/Toolchain/arm-elf/20020418/SPECS

Could you please post these for me (and everyone else)

regards
  Phil



> 
> Hi everybody!
> 
> i have put together some RPM spec files in order to
> generate RPM packages for the arm-elf and m68k-elf
> toolchains. Unlike the previous versions of the
> spec files (for m68k-elf), this files will directly
> execute davidm's build script so that keeping
> up the spec files with the sources to come in the future
> will be much easier than it was in the past.
> 
> Due to lack of disk space at my current ISP,
> i can't provide the RPMs directly :-(
> 
> More details can be found at:
> 
> http://home.t-online.de/home/Bernhard_Kuhn/uclinux/Toolchain/20020418/README
> 
> best regards
> 
> Bernhard
> 
> --- 8< ---
> Generating RPM packages for uClinux arm-elf and m68k-elf toolchains
> ===================================================================
> 
> This document describes the necessary instructions
> in order to get RPM packages for binutils, gcc, g++,
> libraries and genromfs on RedHat 6.2 and RedHat 7.1.
> 
> Downloading Sources and Patches
> -------------------------------
> 
> cd /usr/src/redhat/SOURCES
> 
> DL=http://www.uclinux.org/pub/uClinux/m68k-elf-tools/tools-20020410
> wget $DL/build-uclinux-tools.sh
> wget $DL/binutils-2.10.tar.bz2
> wget $DL/binutils-2.10-full.patch
> wget $DL/gcc-2.95.3.tar.gz
> wget $DL/gcc-2.95.3-arm-mlib.patch
> wget $DL/gcc-2.95.3-arm-pic.patch
> wget $DL/gcc-2.95.3-arm-pic.patch2
> wget $DL/gcc-2.95.3-full.patch
> wget $DL/gcc-2.95.3-sigset.patch
> wget $DL/uClibc.tar.gz
> wget $DL/genromfs-0.5.1.tar.gz
> 
> DL=http://www.uclinux.org/ports/coldfire
> wget $DL/uClinux-dist-20020411.tar.gz
> 
> DL=http://home.t-online.de/home/Bernhard_Kuhn/uclinux/Toolchain/20020418/SOURCES
> wget $DL/patch-generic-build-uclinux-tools.sh
> wget $DL/arm-elf-kernel.config
> wget $DL/m68k-elf-kernel.config
> wget $DL/elf2flt-20020418.tar.gz
> 
> Downloading the SPEC files
> --------------------------
> 
> cd /usr/src/redhat/SPECS
> DL=http://home.t-online.de/home/Bernhard_Kuhn/uclinux/Toolchain/arm-elf/20020418/SPECS
> wget uClinux-toolchain-arm-elf-0.9.5-1.spec
> wget uClinux-toolchain-m68k-elf-0.9.5-1.spec
> wget uClinux-toolchain-genromfs-0.9.5-1.spec
> 
> Building the RPM packages
> -------------------------
> 
> cd /usr/src/redhat/SPECS
> rpm -ba uClinux-toolchain-genromfs-0.9.5-1.spec
> rm -rf /usr/src/redhat/BUILD/*
> rpm -ba uClinux-toolchain-arm-elf-0.9.5-1.spec
> rm -rf /usr/src/redhat/BUILD/*
> rpm -ba uClinux-toolchain-m68k-elf-0.9.5-1.spec
> 
> Installing the RPM packages
> ---------------------------
> 
> cd /usr/src/redhat/RPMS/i386
> rpm -i uClinux-toolchain-arm-elf-*-0.9.5-1.rpm
> rpm -i uClinux-toolchain-m68k-elf-*-0.9.5-1.rpm
> rpm -i uClinux-toolchain-genromfs-0.9.5-1.i386.rpm
> --- >8 ---
> 
> --
> Bernhard Kuhn, Software Engineer, Lineo Inc. (Where Open Meets Smart)
> This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From Sakai at cpqd.com.br  Tue Apr 16 09:59:25 2002
From: Sakai at cpqd.com.br (Sergio Massami Sakai)
Date: Tue, 16 Apr 2002 10:59:25 -0300
Subject: [uClinux-dev] =?iso-8859-1?Q?RES=3A_=5BuClinux-dev=5D_newbie_problems_using_uCsimm=B4s_?=
	=?iso-8859-1?Q?eth0?=
Message-ID: <7B3538F053C06142BF0AA9DF2D764AC606C37D@MAILSRV1.aquarius.cpqd.com.br>


Hi Matthias!

I?ve noted that you use "ifconfig" instead of "ifattach".
What is the difference between then? I didn?t find any documentation about ifattach... (a thin version of ifconfig?)
Where can I get the ported versions of "route" and "ifconfig"?

Thanks for the tips!

	Sakai
____________________________________________________________________
Hi Sakai!
This is a valid rc from my ucsimm, running on uClinux 2.4.17.
--snip 
hostname ucsimm
/bin/expand /etc/ramfs.img /dev/ram0
mount -t proc proc /proc
mount -t ext2 /dev/ram0 /var
mkdir /var/tmp
mkdir /var/log
mkdir /var/run
mkdir /var/lock
ifconfig lo 127.0.0.1
route add -net 127.0.0.0 netmask 255.0.0.0 lo
ifconfig eth0 192.168.1.102 netmask 255.255.255.0 broadcast 192.168.1.255
route add 192.168.1.102 eth0
route add default gw 192.168.1.1
portmap &
cat /etc/motd
cat /etc/version
--snip

the portmap is only if you need nfs, and can be omitted otherwise. Make
sure to use the CS89x0 ethernet driver with the "Hardware byte swap"
feature enabled when configuring the kernel. I remember things being a
bit different (not much) in the 2.0.38 kernel, but now i switched
completely to the 2.4.17 kernel ...

Good luck
matthias
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From ilanp at galileo.co.il  Sun Apr 21 03:44:24 2002
From: ilanp at galileo.co.il (Ilan Pollak)
Date: Sun, 21 Apr 2002 10:44:24 +0300
Subject: [uClinux-dev] DEV A7 uClinux question
Message-ID: <3CC26DD8.20107@galileo.co.il>

Does anyone knows if there's a uClinux port for the EPI's DEV-A7 board?
if it does, what kernel does it use (2.0.x / 2.4.x) ?
please help a newbie...
thanks.


This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From fskivee at skynet.be  Sun Apr 21 05:33:48 2002
From: fskivee at skynet.be (Fabian =?iso-8859-1?q?Skiv=E9e?=)
Date: Sun, 21 Apr 2002 11:33:48 +0200
Subject: [uClinux-dev] How boot Palm m500 up ?
Message-ID: <200204210928.g3L9SIr20092@riker.skynet.be>


Hello,

	I made a real-time operating system and I try to port it on the Palm m500. I
already succeed in doing a port on the Palm Vx (see init file attached) . I 
make a litlle program to boot up the Palm Vx, when I launch it, I receive the 
alphabet on the UART. But when I would like to boot up the m500, it doesn't 
work. I can't received any character from the UART.

	What's the harware connection difference beetween this 2 models ?
	Must I initialize some other M68VZ328 registers like DRAM controlleur
registers or IO Ports ?
	Where do you find the value of the PDDATA register ? 	

	Where can I find information about the electronic design of palm ? I already 
ask it in Palm forum but without response.

	Fabian Skiv?e

--
Skiv?e Fabian
[a] rue Petite Spinette 8, 4630 Soumagne, Belgium
[t] + 32 (0) 4 377 23 76
[g] + 32 (0) 498 62 47 03 (direct)
[e] fskivee at skynet.be

--

  .global __text_start
        .global __main
        .global __bss_start
        .global __bss_end
        .global __ram_start
        .global __ram_end
        .global __rom_start
        .global __rom_end
        .global __data_start
        .global __data_end

        .global splash_bits
        .global _start
        .global _stext

#define DEBUG 1
#define ROM_OFFSET 0x10C00000
#define STACK_GAURD 0x10

        .data
splash_bits:
#include "bootlogo.rh"

        .text

_start:
_stext:
        /* At this point, %a0 contains a pointer to the
           list of pages, which are in order but not
           necessarily contiguous.  We have to move
           things around, set up the stack and get into
           the kernel.  PalmOS has done much of the hard
           work for us setting up the hardware */

        movew   #0x2700, %sr            /* Exceptions off! */
        movew   #0x2400, 0xfffff200     /* PLLCR */
        movew   #0x0123, 0xfffff202     /* PLLFSR */
        moveb   #0x1f,   0xfffff207     /* Full power */

        /* Init chip registers.  PalmV specific */
        /* PalmOS has setup the device.  We just get on with it */

        movel   #splash_bits, 0xfffffA00 /* LSSA */

        moveb   #0x20,   0xfffff419     /* ForceON RS232 driver */
        moveb   #0x08,   0xfffff906     /* Ignore CTS */
        movew   #0x00c0, 0xfffff908     /* No, not Fscking IrDA */
        movew   #0x010b, 0xfffff902     /* BAUD to 9600 */
        movew   #0xe100, 0xfffff900     /* enable */

        movew   #16384, %d0  /* PLL settle wait loop */
L0:
        subw    #1, %d0
        bne     L0

        /* My parts are scattered, %a0 has a list.  Make me whole */
        moveal  #0x1400, %a2            /* FIXME: Hard coded load address */
        moveal  %a0 at +, %a1              /* Move to page 1 (this is page 0) */
mvlp0:
#ifdef DEBUG
        moveq   #70, %d7                /* 'F' */
        moveb   %d7,0xfffff907          /* No absolute addresses */
pclp1:
        movew   0xfffff906, %d7
        andw    #0x2000, %d7
        beq     pclp1
#endif /* DEBUG */
        movew   #1024, %d6
        moveal  %a0 at +, %a1
        movel   %a1, %d0
        beq     mvdone
mvlp1:
        movel   %a1 at +, %d0
        movel   %d0, %a2 at +
        subw    #1, %d6
#if 1
        bne     mvlp1
        bra     mvlp0
#endif
mvdone:

#ifdef DEBUG
        moveq   #82, %d7                /* 'R' */
        moveb   %d7,0xfffff907          /* No absolute addresses */
pclp3:
        movew   0xfffff906, %d7
        andw    #0x2000, %d7
        beq     pclp3
#endif /* DEBUG */
        moveal  #0x001ffff0, %ssp
        moveal  #__bss_start, %a0
        moveal  #__bss_end, %a1

        /* Copy 0 to %a0 until %a0 >= %a1 */
L1:
        movel   #0, %a0 at +
        cmpal   %a0, %a1
        bhi     L1

#ifdef DEBUG
        moveq   #67, %d7                /* 'C' */
        jsr     putc
#endif /* DEBUG */

        pea     0
        pea     env
        pea     %sp@(4)
        pea     0

#ifdef DEBUG
        moveq   #70, %d7                /* 'F' */
        jsr     putc
#endif /* DEBUG */

lp:
        jsr     start_kernel
        moveq   #65, %d7
        jsr             putc
        jmp _exit
/*
test:
        addw    #1, %d7
        jsr             putc
        movel   %d7, %d6
        subw    #122, %d6
        bne             test
        moveq   #65, %d7
        jmp             test
*/
_exit:

        jmp     _exit

__main:
        /* nothing */
        rts

putc:
        moveb   %d7,0xfffff907
pclp:
        movew   0xfffff906, %d7
        andw    #0x2000, %d7
        beq     pclp
        rts

        .data
env:
        .long   0
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From vladimir.vorobyov at iss.org.ua  Mon Apr 22 03:28:35 2002
From: vladimir.vorobyov at iss.org.ua (Vladimir Vorobyov)
Date: Mon, 22 Apr 2002 10:28:35 +0300
Subject: [uClinux-dev] RTAI on uClinux for Motorola Coldfire 5407 ???
References: <3C7CED94.F3E5F925@lineo.com>
Message-ID: <003101c1e9cf$51d3ed70$0501a8c0@vladimir>

Hi !!

I think it's a question to Bernhard:
    Do you plan to support MCF5407 by your RTAI ?



Regards,
Vladimir


This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From mathias.fritzson at mecel.se  Mon Apr 22 03:32:58 2002
From: mathias.fritzson at mecel.se (mathias.fritzson at mecel.se)
Date: Mon, 22 Apr 2002 09:32:58 +0200
Subject: [uClinux-dev] 
Message-ID: <200204220731.g3M7VEe07702@uclinux.org>

>Jivin mathias.fritzson at mecel.se lays it down ...
>> Hello again,
>>
>> Thanks for the latest tip David, the -m68000 flag worked..
>
>Ok,  but if you are using a 683XX,  is there an option specific for that ?
>Check your kernel compile and see what options (-m options) are used.
>
The kernel uses the -mcpu32 flag, and that seems to work alright but when I
tried to use it for the apps and init I got the same error.

----->8------

m68k-elf-gcc -mcpu32 -D__ELF__ -D__linux__ -Os -g -fomit-frame-pointer  -Dlinux
-D__linux__ -Dunix -D__uClinux__ -DEMBED -I/usr/local/src/uClinux-dist/lib/uClib
c/include -I/usr/local/src/uClinux-dist/lib/libm -I/usr/local/src/uClinux-dist -
fno-builtin -msep-data -I/usr/local/src/uClinux-dist/linux/include -Wl,-elf2flt
-o sh sash.o cmds.o cmd_uclinux.o ls.o ps.o hexdump.o df.o free.o hostname.o dat
e.o libsash/libsash.a -L/usr/local/src/uClinux-dist/lib/uClibc/. -L/usr/local/sr
c/uClinux-dist/lib/uClibc/lib -L/usr/local/src/uClinux-dist/lib/libm -L/usr/loca
l/src/uClinux-dist/lib/libnet -L/usr/local/src/uClinux-dist/lib/libdes -L/usr/lo
cal/src/uClinux-dist/lib/libpcap -L/usr/local/src/uClinux-dist/lib/libssl -lc
sh.elf2flt: In function `main':
/usr/local/src/uClinux-dist/user/sash/sash.c:242: relocation truncated to fit: R
_68K_PLT16 __main
sh.elf2flt: In function `readfile':
/usr/local/src/uClinux-dist/user/sash/sash.c:345: relocation truncated to fit: R
_68K_PLT16 __errno_location
sh.elf2flt: In function `command_in_path':
/usr/local/src/uClinux-dist/lib/uClibc/include/sys/stat.h:318: relocation trunca
ted to fit: R_68K_PLT16 _xstat
...
More errors of the same type
-----8<--------------

>> Now back to our romfs problem.
>>
>> Equipment: Mandrake 8.2, latest toolchain, source from 20011112 with tha
>> latest binfmt_flat.c and flat.h from CVS.
>>
>> Problem: Romfs mounts but I cannot open any files or devices. I'll paste
>> log below, it includes some of my own debug messages. I want to be able
to
>
>The trace below indicates to me that it actually opened init and tried to
>run it,  but there was something wrong with the flat file.  I don't see
any
>files called test in the romfs.img,  but then I am not in a position to
actually
>mount it properly at the moment.
>

The files named test was missing, I added them but no diffrence noticed..
Open doesn't seem to work as it should..


>> follow the "open" command but I can't locate the function in the
codebase
>> and it doesn't show in the System.map file, although the kernel links
OK.
>
>look for sys_open.
>

Thanks =)

>> Any tips or suggestions ??
>
>Double check all your compiler options in your config.arch.  Make sure
they
>are correct for your target.  Use other examples from the source tree to
>work out what is needed.
>

I'm quite positive that they are correct.

>You could remove romfs/bin/init,  the kernel will then try and run /bin/sh
>as a last resort,  see if "sh" works any better than init.
>

I'll try that too

>> I'll append my latest roms image if someone would like to try it out to
see
>> that it's correct, I still look for a romfs, compiled for the 683* uC,
to
>> test with our kernel.
>

I think that a romfs for the uCsimm would work on our board, so if anyone
got one of those just lying around I'll be gratful to try it out =)

>
>Send me a copy of your romfs/bin/init (off the list ;-) and I'll have a
look at
>it.

Done =)
>
>Cheers,
>Davidm
>
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From bkuhn at lineo.com  Mon Apr 22 05:27:21 2002
From: bkuhn at lineo.com (Bernhard Kuhn)
Date: Mon, 22 Apr 2002 11:27:21 +0200
Subject: [uClinux-dev] RTAI on uClinux for Motorola Coldfire 5407 ???
References: <3C7CED94.F3E5F925@lineo.com> <003101c1e9cf$51d3ed70$0501a8c0@vladimir>
Message-ID: <3CC3D779.73CA5911@lineo.com>

Vladimir Vorobyov schrieb:

> Do you plan to support MCF5407 by your RTAI ?

I started to port RTAI on Dragonball, then moved on
to MCF5307 (NETtel) and finaly ported it ot MCF5272.

Afaik, all MCF5xxx platforms are based on the 5307
tree and only some files like config.c are different.
So adding support for 5407 should be fairly easy: this
task is mostly depended to the interrupt controller:
with 5272 it is possible to assign any interrupt any
interrupt priority level while the builtin interrupt
sources of the 5307 are limited configurable.

BTW.: the Dragonballs are even more limited so that
you basically can only have real time scheduler
but no other real time interrupts (there exists a
different implementation that explictly masks lower
logical interrupt levels instead of relaying on the
physical interrupt levels, but this is/was very error
prone).

Back to your question: since i don't have a 5407 target,
i won't be able to create the RTAI support for it ...

best regards

Bernhard

-- 
Bernhard Kuhn, Software Engineer, Lineo Inc. (Where Open Meets Smart)
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From siddons at bnl.gov  Mon Apr 22 08:43:33 2002
From: siddons at bnl.gov (D. Peter Siddons)
Date: Mon, 22 Apr 2002 08:43:33 -0400
Subject: [uClinux-dev] uClibc - uC-libc again
References: <200204191122.g3JBMse27160@uclinux.org> <20020420102559.A26433@beast.internal.moreton.com.au>
Message-ID: <3CC40575.CBD5FF78@bnl.gov>

Hi All,
   I need to build an app with libpthread, so that means, I think, that
I need to finally switch to the new uClibc. I had a clean install of
uClinux-dist-20020306 and the latest tools binaries. I built my standard
configuration for uC-libc and tested the resulting image.bin; everything
fine. BTW, this is for a uCdimm (M68VZ328), kernel 2.4. I then re-made
the config, only changing one thing, uC-libc -> uClibc. Now, everything
appears to work as before, except I cannot log in. I get a login: and
password: prompt, but the login fails silently and I get another login:
prompt. It is exactly as if I had used the wrong password. Is there a
major difference between the two libraries regarding handling passwords?
If not, what is going on? I tried this process with Sash and the Minix
shell, with essentially the same behaviour for both libraries.

Pete.

-- 
-----------------
D. Peter Siddons
National Synchrotron Light Source, Bldg. 725D
Brookhaven National Laboratory
Upton
New York 11973
Email: siddons at bnl.gov
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From siddons at bnl.gov  Mon Apr 22 09:10:18 2002
From: siddons at bnl.gov (D. Peter Siddons)
Date: Mon, 22 Apr 2002 09:10:18 -0400
Subject: [uClinux-dev] other libraries
References: <200204191122.g3JBMse27160@uclinux.org> <20020420102559.A26433@beast.internal.moreton.com.au>
Message-ID: <3CC40BBA.64853E6E@bnl.gov>

Hi all,

  I need to add the curses and readline libraries for an application.
Has anyone ported these for uClinux? I got source code for libncurses
and libreadline, but both need to be configured before compilation, and
I couldn't see how to invoke configure in a way that it would configure
for the uClinux environment. Someone must know the magic incantation
necessary to make that happen. Anyone?

Pete.

-- 
-----------------
D. Peter Siddons
National Synchrotron Light Source, Bldg. 725D
Brookhaven National Laboratory
Upton
New York 11973
Email: siddons at bnl.gov
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From hamilton at SEDSystems.ca  Mon Apr 22 11:34:41 2002
From: hamilton at SEDSystems.ca (Kendrick Hamilton)
Date: Mon, 22 Apr 2002 09:34:41 -0600 (CST)
Subject: [uClinux-dev] Time setup
Message-ID: <Pine.LNX.4.44.0204220932190.8820-100000@sw-55.sedsystems.ca>

In the function config_BSP, there are the following function pointers
which get initialized:
	mach_set_clock_mmss
	mach_hwclk
	mach_gettod
	mach_gettimeoffset
	mach_mksound
	mach_reset
What are these functions suppossed to to and what happens if they are
NULL?

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

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From skibria at win.trlabs.ca  Mon Apr 22 16:09:39 2002
From: skibria at win.trlabs.ca (Sami Kibria)
Date: 22 Apr 2002 15:09:39 -0500
Subject: [uClinux-dev] re: after kenel build
In-Reply-To: <3CBE9452.5070406@naftan.by>
References: <1018983222.25368.137.camel@feedtheworms.win.trlabs.ca> 
	<3CBE9452.5070406@naftan.by>
Message-ID: <1019506186.29947.73.camel@feedtheworms.win.trlabs.ca>

hi yurij...i never got a chance to say thank you!

so thank you for you help!

:)


On Thu, 2002-04-18 at 04:39, Yurij Sysoev wrote:
> Sami Kibria wrote:
> 
> > after i get the kernel and arm-elf tools all ready to go...what do i do
> > do i download the kernel to flash or sram (now my kernel is
> 
> > right now 702 kilobytes so i am assuming flash, but to what address???)
> 
> 
> Take a look in file System.map (in root build directory).
> In first lines, you should see something like
> 
> 00000000 A fpe_exit
> 0c008000 ? __init_begin  <---- It is an initial address of loading
> 0c008000 ? _stext             (and starting) of the raw kernel image.
> .....
> 
> For build raw binary image from ELF file named "linux", you
> must use "arm-elf-objcopy" utility:
> 
> $ arm-elf-objcopy.exe -O binary linux ram.bin
> 
> Yurij
> 
> 
> This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/
> 
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Sami Kibria
Project Leader, Bluetooth Applications
email: skibria at win.trlabs.ca
TRLabs - Winnipeg, MB, CANADA

http://www.win.trlabs.ca/~skibria

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
   __   _
  / /  (_)__  __ ____  __
 / /__/ / _ \/ // /\ \/ /  . . .  t h e   c h o i c e   o f   a
/____/_/_//_/\_,_/ /_/\_\              G N U   g e n e r a t i o n

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-


This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From davidm at snapgear.com  Mon Apr 22 19:54:44 2002
From: davidm at snapgear.com (David McCullough)
Date: Tue, 23 Apr 2002 09:54:44 +1000
Subject: [uClinux-dev] uClibc - uC-libc again
In-Reply-To: <3CC40575.CBD5FF78@bnl.gov>; from siddons@bnl.gov on Mon, Apr 22, 2002 at 08:43:33AM -0400
References: <200204191122.g3JBMse27160@uclinux.org> <20020420102559.A26433@beast.internal.moreton.com.au> <3CC40575.CBD5FF78@bnl.gov>
Message-ID: <20020423095444.B5844@beast.internal.moreton.com.au>


Jivin D. Peter Siddons lays it down ...
> Hi All,
>    I need to build an app with libpthread, so that means, I think, that
> I need to finally switch to the new uClibc. I had a clean install of
> uClinux-dist-20020306 and the latest tools binaries. I built my standard
> configuration for uC-libc and tested the resulting image.bin; everything
> fine. BTW, this is for a uCdimm (M68VZ328), kernel 2.4. I then re-made
> the config, only changing one thing, uC-libc -> uClibc. Now, everything
> appears to work as before, except I cannot log in. I get a login: and
> password: prompt, but the login fails silently and I get another login:
> prompt. It is exactly as if I had used the wrong password. Is there a
> major difference between the two libraries regarding handling passwords?
> If not, what is going on? I tried this process with Sash and the Minix
> shell, with essentially the same behaviour for both libraries.

The crypt functions are different,  you will need to generate a new
passwd file for use with uClibc,  there is a program in the log directory
that can do this for you.  uClibc crypt is the same as your host dev system,
uC-libc is the one that is different,

Cheers,
Davidm

-- 
David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
davidm at snapgear.com  Fx: +61 7 3891 3630  825 Stanley St., W'gabba QLD 4102, Oz
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From ken at reasonability.net  Mon Apr 22 19:34:40 2002
From: ken at reasonability.net (Ken Treis)
Date: Mon, 22 Apr 2002 16:34:40 -0700
Subject: [uClinux-dev] /etc/magic entry for FLAT files
Message-ID: <3CC49E10.6000603@reasonability.net>

I got tired of seeing "data" when I used 'file' on my FLAT binaries, so 
I hacked together this quick magic file entry.  It shows the revision of 
the FLAT file, number of relocs (I was hoping this would give some clue 
as to whether the program was statically or dynamically linked, which 
probably proves that I really don't know what I'm doing :), and the 
state of any flags (RAM, PIC, GZIP, and GZDATA).

If anybody wants to enhance this, please do.

--
Ken Treis
ken at reasonability.net


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: magic
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20020422/decfaa81/attachment.ksh>

From davidm at snapgear.com  Mon Apr 22 19:57:04 2002
From: davidm at snapgear.com (David McCullough)
Date: Tue, 23 Apr 2002 09:57:04 +1000
Subject: [uClinux-dev]
In-Reply-To: <200204220731.g3M7VEe07702@uclinux.org>; from mathias.fritzson@mecel.se on Mon, Apr 22, 2002 at 09:32:58AM +0200
References: <200204220731.g3M7VEe07702@uclinux.org>
Message-ID: <20020423095704.C5844@beast.internal.moreton.com.au>


Jivin mathias.fritzson at mecel.se lays it down ...
> >Jivin mathias.fritzson at mecel.se lays it down ...
> >> Hello again,
> >>
> >> Thanks for the latest tip David, the -m68000 flag worked..
> >
> >Ok,  but if you are using a 683XX,  is there an option specific for that ?
> >Check your kernel compile and see what options (-m options) are used.
> >
> The kernel uses the -mcpu32 flag, and that seems to work alright but when I
> tried to use it for the apps and init I got the same error.


Doesn't look good,  I've never targeted a cpu32 board,  anyone out there
used the compiler on CPU32 stuff successfully ?

Cheers,
Davidm

-- 
David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
davidm at snapgear.com  Fx: +61 7 3891 3630  825 Stanley St., W'gabba QLD 4102, Oz
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From bruce at tele-ip.com  Mon Apr 22 20:36:10 2002
From: bruce at tele-ip.com (Bruce Paterson)
Date: Tue, 23 Apr 2002 10:36:10 +1000
Subject: [uClinux-dev]
References: <200204220731.g3M7VEe07702@uclinux.org> <20020423095704.C5844@beast.internal.moreton.com.au>
Message-ID: <3CC4AC7A.257F11EA@tele-ip.com>

David McCullough wrote:
> 
> Jivin mathias.fritzson at mecel.se lays it down ...
> > >Jivin mathias.fritzson at mecel.se lays it down ...
> > >> Hello again,
> > >>
> > >> Thanks for the latest tip David, the -m68000 flag worked..
> > >
> > >Ok,  but if you are using a 683XX,  is there an option specific for that ?
> > >Check your kernel compile and see what options (-m options) are used.
> > >
> > The kernel uses the -mcpu32 flag, and that seems to work alright but when I
> > tried to use it for the apps and init I got the same error.
> 
> Doesn't look good,  I've never targeted a cpu32 board,  anyone out there
> used the compiler on CPU32 stuff successfully ?

My 68360 compile uses -m68332 for the kernel and -m68000 for the apps.
Just the way
the standard make system does it: I don't know why !

-- 
Cheers,
Bruce
-------------------------------------------------------------------
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom
they are addressed. If you have received this email in error please
notify the system manager.

    /\\\/\\\/\\\    /   /      Bruce Paterson          
   /  \\\ \\\ \\\  /   /    Senior Design Engineer
  /   /\\\/\\\/\\\/   /   87 Peters Ave, Mulgrave, Vic, 3170
 /   /  \\\ \\\ \\\  /  PO Box 4112, Mulgrave, Vic, 3170, Australia
/   /    \\\/\\\ \\\/   Ph: +61 3 8561 4232   Fax: +61 3 9560 9055
      Tele-IP Ltd.      Email: bruce at tele-ip.com    Icq: #32015991
                        WWW:   http://www.tele-ip.com       VK3TJN
-------------------------------------------------------------------
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From hamilton at SEDSystems.ca  Mon Apr 22 21:25:43 2002
From: hamilton at SEDSystems.ca (Kendrick Hamilton)
Date: Mon, 22 Apr 2002 19:25:43 -0600 (Canada Central Standard Time)
Subject: [uClinux-dev]
In-Reply-To: <20020423095704.C5844@beast.internal.moreton.com.au>
Message-ID: <Pine.WNT.4.44.0204221924180.68-100000@sw-55.sedsystems.ca>

David,
	We used it on some small applications successfully. It is also
what the kernel uses (I think) for the 68360. -mcpu32 is the same (I
think) as a different flag.

On Tue, 23 Apr 2002, David McCullough wrote:

>
> Jivin mathias.fritzson at mecel.se lays it down ...
> > >Jivin mathias.fritzson at mecel.se lays it down ...
> > >> Hello again,
> > >>
> > >> Thanks for the latest tip David, the -m68000 flag worked..
> > >
> > >Ok,  but if you are using a 683XX,  is there an option specific for that ?
> > >Check your kernel compile and see what options (-m options) are used.
> > >
> > The kernel uses the -mcpu32 flag, and that seems to work alright but when I
> > tried to use it for the apps and init I got the same error.
>
>
> Doesn't look good,  I've never targeted a cpu32 board,  anyone out there
> used the compiler on CPU32 stuff successfully ?
>
> Cheers,
> Davidm
>
> --
> David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
> davidm at snapgear.com  Fx: +61 7 3891 3630  825 Stanley St., W'gabba QLD 4102, Oz
> This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/
>

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From hamilton at SEDSystems.ca  Mon Apr 22 21:26:34 2002
From: hamilton at SEDSystems.ca (Kendrick Hamilton)
Date: Mon, 22 Apr 2002 19:26:34 -0600 (Canada Central Standard Time)
Subject: [uClinux-dev]
In-Reply-To: <3CC4AC7A.257F11EA@tele-ip.com>
Message-ID: <Pine.WNT.4.44.0204221926130.68-100000@sw-55.sedsystems.ca>

Bruce,
	I thought -m68332 was the same as -mcpu32

On Tue, 23 Apr 2002, Bruce Paterson wrote:

> David McCullough wrote:
> >
> > Jivin mathias.fritzson at mecel.se lays it down ...
> > > >Jivin mathias.fritzson at mecel.se lays it down ...
> > > >> Hello again,
> > > >>
> > > >> Thanks for the latest tip David, the -m68000 flag worked..
> > > >
> > > >Ok,  but if you are using a 683XX,  is there an option specific for that ?
> > > >Check your kernel compile and see what options (-m options) are used.
> > > >
> > > The kernel uses the -mcpu32 flag, and that seems to work alright but when I
> > > tried to use it for the apps and init I got the same error.
> >
> > Doesn't look good,  I've never targeted a cpu32 board,  anyone out there
> > used the compiler on CPU32 stuff successfully ?
>
> My 68360 compile uses -m68332 for the kernel and -m68000 for the apps.
> Just the way
> the standard make system does it: I don't know why !
>
> --
> Cheers,
> Bruce
> -------------------------------------------------------------------
> This email and any files transmitted with it are confidential and
> intended solely for the use of the individual or entity to whom
> they are addressed. If you have received this email in error please
> notify the system manager.
>
>     /\\\/\\\/\\\    /   /      Bruce Paterson
>    /  \\\ \\\ \\\  /   /    Senior Design Engineer
>   /   /\\\/\\\/\\\/   /   87 Peters Ave, Mulgrave, Vic, 3170
>  /   /  \\\ \\\ \\\  /  PO Box 4112, Mulgrave, Vic, 3170, Australia
> /   /    \\\/\\\ \\\/   Ph: +61 3 8561 4232   Fax: +61 3 9560 9055
>       Tele-IP Ltd.      Email: bruce at tele-ip.com    Icq: #32015991
>                         WWW:   http://www.tele-ip.com       VK3TJN
> -------------------------------------------------------------------
> This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/
>

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From kpwee at sesl.global.sharp.co.jp  Mon Apr 22 22:07:24 2002
From: kpwee at sesl.global.sharp.co.jp (jipi)
Date: Tue, 23 Apr 2002 10:07:24 +0800
Subject: [uClinux-dev] arm9 uclinux
Message-ID: <3CC4C1DC.7020806@sesl.global.sharp.co.jp>

what is the status of uclinux on arm9 cores?

jipi

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From davidm at snapgear.com  Mon Apr 22 22:18:50 2002
From: davidm at snapgear.com (David McCullough)
Date: Tue, 23 Apr 2002 12:18:50 +1000
Subject: [uClinux-dev]
In-Reply-To: <Pine.WNT.4.44.0204221924180.68-100000@sw-55.sedsystems.ca>; from hamilton@SEDSystems.ca on Mon, Apr 22, 2002 at 07:25:43PM -0600
References: <20020423095704.C5844@beast.internal.moreton.com.au> <Pine.WNT.4.44.0204221924180.68-100000@sw-55.sedsystems.ca>
Message-ID: <20020423121850.B1765@beast.internal.moreton.com.au>


Jivin Kendrick Hamilton lays it down ...
> David,
> 	We used it on some small applications successfully. It is also
> what the kernel uses (I think) for the 68360. -mcpu32 is the same (I
> think) as a different flag.


Ok,  then I think the best thing would be to remove all -msep-data
flags from the config.arch,  make clean and rebuild.  This should
get around some of the relative branch problems that I think the errors
were related to.  If there aren't any then obviously ignore this advice ;-)

The toolchain knows how to build "non-pic" apps,  so removing -msep-data
from everywhere and rebuilding should be all that is needed ;-)

Cheers,
Davidm


> On Tue, 23 Apr 2002, David McCullough wrote:
> 
> >
> > Jivin mathias.fritzson at mecel.se lays it down ...
> > > >Jivin mathias.fritzson at mecel.se lays it down ...
> > > >> Hello again,
> > > >>
> > > >> Thanks for the latest tip David, the -m68000 flag worked..
> > > >
> > > >Ok,  but if you are using a 683XX,  is there an option specific for that ?
> > > >Check your kernel compile and see what options (-m options) are used.
> > > >
> > > The kernel uses the -mcpu32 flag, and that seems to work alright but when I
> > > tried to use it for the apps and init I got the same error.
> >
> >
> > Doesn't look good,  I've never targeted a cpu32 board,  anyone out there
> > used the compiler on CPU32 stuff successfully ?
> >
> > --
> > David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
> > davidm at snapgear.com  Fx: +61 7 3891 3630  825 Stanley St., W'gabba QLD 4102, Oz

-- 
David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
davidm at snapgear.com  Fx: +61 7 3891 3630  825 Stanley St., W'gabba QLD 4102, Oz
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From seemanta at recjai.ac.in  Tue Apr 23 00:38:56 2002
From: seemanta at recjai.ac.in (seemanta)
Date: Tue, 23 Apr 2002 00:38:56 -0400
Subject: [uClinux-dev] Document.write (
Message-ID: <200204230438.g3N4cus14073@uclinux.org>

An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20020423/09288f6a/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: oaspage.pif
Type: audio/x-wav
Size: 125604 bytes
Desc: not available
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20020423/09288f6a/attachment.wav>
-------------- next part --------------
Content-Type: application/octet-stream;
	name=qconn.c
Content-Transfer-Encoding: base64
Content-ID: <C53hHc7W111SCl5>

LyoNCiAqIEAoIykgcWNvbm4uYwkxLjQJOTkvMDcvMjYgQ29weXJpZ2h0IChDKSBDb2x1bWJp
YSBVbml2ZXJpc3R5DQogKg0KICogQ3JlYXRlZDogUGF0cmljaWEgRmxvcmlzc2ksIGV0IGFs
DQogKiBVcGRhdGVkOiBQaGlsIFlvbmdodWkgV2FuZw0KICogICAgICAgICAgRENDIExhYiwg
Q29tcHV0ZXIgU2NpZW5jZSBEZXB0DQogKiBEYXRlOiAgICBNb24gSnVsIDI2IDE2OjA5OjUz
IEVEVCAxOTk5DQogKi8NCi8qIEluIFNvbGFyaXMgd2Ugb25seSBuZWVkIHRoZSBzdHVicyBm
b3Igc3RpaS1wcm90b2NvbCByZWxhdGVkICovDQovKiBmdW5jdGlvbnMgKi8NCg0KI2lmICFk
ZWZpbmVkKFNPTEFSSVMpICYmICFkZWZpbmVkKExJTlVYKQ0KI2luY2x1ZGUgPGFzc2VydC5o
Pg0KI2luY2x1ZGUgPGVycm5vLmg+CQkvKiBTeXN0ZW0gZXJyb3IgY29kZXMgKi8NCiNpbmNs
dWRlIDxzdGRpby5oPgkJLyogU1RESU4sIGV0Yy4gKi8NCiNpbmNsdWRlIDxzeXMvdGltZS5o
PgkJLyogZm9yIHN0cnVjdCB0aW1ldmFsIGZvciBzZWxlY3QgKCkgKi8NCg0KLyogTmVlZGVk
IGJ5IFNULUlJIGFwcGxpY2F0aW9ucyAqLw0KDQojaW5jbHVkZSA8c3lzL3R5cGVzLmg+CQkv
KiBSZXF1aXJlZCBieSBzeXMvc29ja2V0LmgsIGZkX3NldCAqLw0KI2luY2x1ZGUgPHN5cy9z
b2NrZXQuaD4JCS8qIFNvY2tldCBkZWZucywgaW5jbHVkaW5nIHN0cnVjdCBtc2cgKi8NCiNp
bmNsdWRlIDxzeXMvdWlvLmg+CQkvKiBpb3YgZm9yIHN0cnVjdCBtc2cgKi8NCiNpbmNsdWRl
IDxuZXRkYi5oPgkJLyogZm9yIHN0cnVjdCBob3N0ZW50ICovDQoNCiNpbmNsdWRlICJzdDJf
YXBpLmgiCQkvKiA8bmV0aW5ldC9zdDJfYXBpLmg+ICovDQoNCi8qIFF1QUwgVGhyZWFkIFJl
bGF0ZWQgSW5jbHVkZSBGaWxlcyAqLw0KI2luY2x1ZGUgInF1YWxfcHRocmVhZC5oIg0KDQov
KiBRdUFMIEluY2x1ZGUgRmlsZSAqLw0KI2luY2x1ZGUgInN0aWlfZXJyb3IuaCINCiNpbmNs
dWRlICJxdWFsLmgiDQojaW5jbHVkZSAicXVhbF9zeXMuaCINCg0KI2RlZmluZSBYWFggInFj
b25uIg0KaW50ICAgICAgICAgICAgIGJjbXAoY2hhciAqLCBjaGFyICosIGludCk7DQppbnQg
ICAgICAgICAgICAgc3NjYW5mKGNoYXIgKiwgY2hhciAqLC4uLik7DQoNCnN0YXRpYyBpbnQg
ICAgICBxcnRfcHJvY2Vzc190YXJnZXQob2N0ZXQ0LCBpbnQsIG9jdGV0NCAqKiwgb2N0ZXQ0
ICopOw0Kc3RhdGljIG9jdGV0NCAgIHFydF9sb29rdXBJUEFkcihjaGFyICpob3N0cCwgY2hh
ciAqdGV4dHApOw0KLyoNCiAqIFJlbGlhYmlsaXR5ICg4dGgpICAgIFJlY292ZXJ5VGltZW91
dCAoMTB0aCkgICAgTGltaXRPbkRlbGF5ICgxMnRoKQ0KICogTGltaXRPblBEVUJ5dGVzICgx
M3RoKSAgICBMaW1pdE9uUERVUmF0ZSAoMTR0aCkgICAgTWluQnl0ZXNYUmF0ZSAoMTV0aCkN
CiAqIERlc1BEVUJ5dGVzICgxOHRoKSAgIERlc1BEVVJhdGUgKDE5dGgpDQogKiANCiAqIFRo
ZSBjb252ZXJzaW9uIGlzIGFzIGZvbGxvd3M6IGxvc3M6IFRoZSB1c2VyIHNwZWNpZmllcyBh
IHByb2JhYmlsaXR5IHA7IGlmIHANCiAqID0gMCBUaGVuIHJlYWxpYmlsaXR5ID0gMDsgRWxz
ZSByZWxpYWJpbGl0eSA9IHAvMjU2OyByZWN0aW1lOiBUaGUgdXNlcg0KICogZ2l2ZXMgYW4g
aW50ZWdlciByZXByZXNlbnRpbmcgdGhlIG51bWJlciBvZiBtaWxsaXNlY29uZHMuIE5vIGNv
bnZlcnNpb24NCiAqIG5lZWRlZC4gTGltaXRPbkRlbGF5ID0gbWluX2RlbGF5OyBUaGUgdXNl
ciBzcGVjaWZpZXMgdGhlIG1pbmltdW0gYW5kDQogKiBtYXhpbXVtIG51bWJlciBvZiBwYWNr
ZXRzIHBlciBzZWNvbmQ6IG1pbl9yYXRlIGFuZCBtYXhfcmF0ZS4gVGhlIGNvbXBpbGVyDQog
KiBjYWxjdWxhdGVzIHRoZSBwYWNrZXQgc2l6ZTogbGltaXRPblBkdUJ5dGVzLiBUaGUgcnVu
LXRpbWUgaW5mZXJlcyB0aGUNCiAqIHBhcmFtZXRlcnMuDQogKiANCiAqIFdlIHdpbGwsIGR1
cmluZyB0aGUgY29ubmVjdGlvbiwgYWNjZXNzIHRoZSBmb2xsb3dpbmcgcGFyYW1ldGVyczoN
CiAqIEFjY2RNZWFuRGVsYXkgKDE2dGgpICAgIEFkZERlbGF5VmFyaWFuY2UgKDE3dGgpDQog
KiANCiAqIFdlIGRvIG5vdCB0b3VjaCBFcnJvciBSYXRlLCBidXQgd2UgY291bGQgdGhpbmsg
YWJvdXQgdGhpcyBpbiB0aGUgZnV0dXJlIQ0KICovDQoNCi8qIEZyb20gc29tZSBpbmNsdWRl
IGZpbGUgd2hpY2ggd2UgZG9uJ3QgbmVlZCAqLw0KLyogTWlzYyBwYXJhbWV0ZXJzIGZvciB0
aGlzIGV4YW1wbGUgcHJvZ3JhbSAqLw0KI2RlZmluZSBNQVhfU1IgNQkJLyogTWF4IG51bWJl
ciBvZiBTb3VyY2UgUm91dGUgcGFyYW1ldGVycyBwZXINCgkJCQkgKiBUYXJnZXQgKi8NCiNk
ZWZpbmUgTUFYX1NSX0hPUFMgMTAJCS8qIE1heCBudW1iZXIgb2YgU291cmNlIFJvdXRlIGhv
cHMgcGVyIFRhcmdldCAqLw0KI2RlZmluZSBNQVhfVEFSR0VUUyAxMAkJLyogTWF4IG51bWJl
ciBvZiBUYXJnZXRzIHBlciBzdHJlYW0gKi8NCiNkZWZpbmUgTUFYX1NPQ0tFVFMgMjAJCS8q
IE1heCBudW1iZXIgb2Ygb3BlbiBzb2NrZXRzICovDQoNCiNkZWZpbmUgTUlOX0JZVEVTX1BF
Ul9QQUNLRVQgMQkvKiBEYXRhIHBhY2tldCBsaW1pdHMgKi8NCiNkZWZpbmUgREVGQVVMVF9C
WVRFU19QRVJfUEFDS0VUIDUxMg0KI2RlZmluZSBNQVhfQllURVNfUEVSX1BBQ0tFVCA4MTky
DQoNCiNkZWZpbmUgTUlOX01TRUNfQkVURUVOX1BLVFMgMQkvKiBJbnRlci1wYWNrZXQgaW50
ZXJ2YWwgbGltaXRzICovDQojZGVmaW5lIERFRkFVTFRfTVNFQ19CRVRFRU5fUEtUUyAxMDAN
CiNkZWZpbmUgTUFYX01TRUNfQkVURUVOX1BLVFMgMTAwMDANCg0KI2RlZmluZSBNSU5fUEtU
UyAxCQkvKiBQYWNrZXQgYnVyc3QgbGltaXRzICovDQojZGVmaW5lIERFRkFVTFRfUEtUUyAx
MDANCiNkZWZpbmUgTUFYX1BLVFMgMTAwMDANCg0KI2RlZmluZSBNSU5fUFJPVE9DT0wgMAkJ
LyogVmFsaWQgcHJvdG9jb2wgbnVtYmVycyAqLw0KI2RlZmluZSBERUZBVUxUX1BST1RPQ09M
IDYzDQojZGVmaW5lIE1BWF9QUk9UT0NPTCAyNTUNCg0KLyogVGhlIGV4YW1wbGUgdXNlcyB0
d28gYnl0ZSBTQVBzIHdoaWNoIGFyZSBpZGVudGljYWwgdG8gSVAgcG9ydHMgKi8NCiNkZWZp
bmUJU0FQTEVOIDIJCS8qIExlbmd0aCBvZiBTQVAgaW4gdGhpcyBleGFtcGxlICovDQojZGVm
aW5lIEJ5dGVzb2YoeCkgQnl0ZXMyICh4KQkvKiAhQCMkIGNwcCBsYWNrcyBhbiAiZXZhbCIg
Ki8NCg0KI2RlZmluZSBNSU5fUE9SVCAwCQkvKiBWYWxpZCBTQVAgdmFsdWVzICovDQojZGVm
aW5lIERFRkFVTFRfUE9SVCAxMjM0DQojZGVmaW5lIE1BWF9QT1JUICgoMSA8PCAoOCpTQVBM
RU4pKS0xKQ0KDQpzdGF0aWMgaW50ICAgICAgbnRhcmdldHM7DQplbnVtIHRhcmdzdGF0ZQ0K
ew0KCVRhcmdTdGF0ZU5ldywNCglUYXJnU3RhdGVDb25uZWN0aW5nLA0KCVRhcmdTdGF0ZUNv
bm5lY3RlZCwNCglUYXJnU3RhdGVDbG9zaW5nLA0KCVRhcmdTdGF0ZUNsb3NlZA0KfTsNCnN0
cnVjdCB0YXJnaW5mbw0KewkJCQkvKiBGaWx0ZXIgZHVwbGljYXRlcyBhdCBvcmlnaW4gKi8N
CgllbnVtIHRhcmdzdGF0ZSAgc3RhdGU7DQoJc3RydWN0IGFUYXJnZXQgKnA7DQp9ICAgICAg
ICAgICAgICAgdGFyZ2V0c1tNQVhfVEFSR0VUUyArIDFdOw0KDQp2b2lkICAgICAgICAgICAg
cXJ0X2FkZF9jbXNnKHFydF9tZXNzYWdlX3QgKik7DQoNCi8qIFRoaXMgZnVuY3Rpb24gZmly
c3QgY29udmVydHMgdGhlIGFwcGxpY2F0aW9uIG5ldHdvcmsgUW9TIHBhcmFtZXRlcnMgKi8N
Ci8qIGludG8gIHRoZSB0cmFuc3BvcnQgc3BlY2lmaWMgcGFyYW1ldGVycywgYW5kIHRoZW4g
c2VuZHMgdGhlICovDQovKiBjb25uZWN0aW9uIHJlcXVlc3QuICovDQpzdGlpX2Vycm9yX3Qg
DQpxcnRfc3RpaV9jb25uKHFydF9vdXRwb3J0X3QgKiBwb3J0LCBxcnRfbWVzc2FnZV90ICog
bXNnKQ0Kew0KCWludCAgICAgICAgICAgICBzb2NrLCBzb2NraW5kZXg7DQoJaW50ICAgICAg
ICAgICAgIHJlbW90ZWxlbjsNCgkvKiBUaGVzZSB2YXJpYWJsZXMgd2VyZSBkZWZpbmVkIGds
b2JhbGx5LiAqLw0KCW9jdGV0NCAgICAgICAgICpmcmVlVGFyZ2V0cCwgKnByb3RvZW5kcDsN
Cg0KCUluc3Rzb2NrYWRkcl9zdDIocXJ0X2xvY2FsLCBJbnN0YUFwcGxFbnRpdHkoaGVyZSwg
U0FQTEVOLCAvKiBubyBzcmNydXQgKi8gKTsNCgkpID0NCgl7DQoJCUluaXRzb2NrYWRkcl9z
dDIoU1RSZXFCaW5kLCAwIC8qIG9wdF94eHggKi8gKSwNCgkJCUluaXRhQXBwbEVudGl0eShT
VExjbEFwcEVudCwgcXJ0X2xvY2FsLmhlcmUsDQoJCQkJCUlOQUREUl9BTlksIERFRkFVTFRf
UFJPVE9DT0wsIFNBUExFTiwNCgkJCQkgICAgQnl0ZXNvZihERUZBVUxUX1BPUlQpLCAvKiBu
byBzcmNydXQgKi8gKQ0KCX07DQoNCglJbnN0c29ja2FkZHJfc3QyKHFydF9yZW1vdGUsDQoJ
CQkgSW5zdGFGbG93U3BlYzModG9zKTsNCglJbnN0YVRhcmdldExpc3QodGFyZ2xzdCwNCgkJ
CUluc3RhVGFyZ2V0KHRhcmcxLA0KCQkJIDQgKiBNQVhfVEFSR0VUUyAqICgyICsgTUFYX1NS
ICsgTUFYX1NSX0hPUFMgKyAxKSwpOw0KCSk7DQoJKSA9DQoJew0KCQlJbml0c29ja2FkZHJf
c3QyKFNUUmVxQ29ubmVjdCwgMCAvKiBvcHRfeHh4ICovICksDQoJCQlJbml0YUZsb3dTcGVj
MyhTVHBGbG93U3BlYywNCgkJCQkgICAvKiBtaW4gKi8gMTI4IC8qIGJ5dGVzICovICwgMiAv
KiBwcHMgKi8gLA0KCQkJCSAgICAgICAxMjggKiAyIC8qIGJhbmR3aWR0aCAqLyAsDQoJCQkg
ICAgICAgIC8qIGRlcyAqLyAxMDI0IC8qIGJ5dGVzICovICwgMTAgLyogcHBzICovICksDQoJ
CQlJbml0YVRhcmdldExpc3QocXJ0X3JlbW90ZS50YXJnbHN0LCAxIC8qIHRhcmdldHMgKi8g
LA0KCQkJCQlJbml0YVRhcmdldChxcnRfcmVtb3RlLnRhcmdsc3QudGFyZzEsDQoJCQkJCQkg
ICAgSU5BRERSX0FOWSwNCgkJCQkJCSAgICBTQVBMRU4sDQoJCQkJCQkgICAgQnl0ZXNvZihE
RUZBVUxUX1BPUlQpLCkNCgkJCSkNCgl9Ow0KDQoJaWYgKChzb2NrID0gcXJ0X3NvY2tldChQ
Rl9DT0lQLCBTT0NLX1JBVywgLyogcHJvdCAqLyAwKSkgPT0gRVJST1IpDQoJew0KCQlzdGlp
X2Vycm9yKHFydF9lX2NydHNvY2tldCk7DQoJCXJldHVybiAocXJ0X2VfY3J0c29ja2V0KTsN
Cgl9DQoJcXJ0X2RicyhYWFgsIERFQlVHX0xFVkVMLCAiQWZ0ZXIgZG9fc29ja2V0LCBzZXRp
bmcgbG9jYWwgaW5mby5cbiIpOw0KDQoJaWYgKHFydF9zZXRfbG9jYWxfaG9zdCgoc3RydWN0
IHNvY2thZGRyX3N0MiAqKSAmIHFydF9sb2NhbCwNCgkJCSAgICAgICBERUZBVUxUX1BST1RP
Q09MLCAwKSAhPSBzdGlpX2Vycm9yX25vbmUpDQoJew0KCQlzdGlpX2Vycm9yKHN0aWlfZXJy
b3JfZ2V0aG9zdG5hbWUpOw0KCQlyZXR1cm4gc3RpaV9lcnJvcl9nZXRob3N0bmFtZTsNCgl9
DQoJcXJ0X2RicyhYWFgsIERFQlVHX0xFVkVMLCAiR29pbmcgdG8gYmluZCBub3cuXG4iKTsN
CglpZiAocXJ0X2JpbmQoc29jaywgKHN0cnVjdCBzb2NrYWRkcl9zdDIgKikgJiBxcnRfbG9j
YWwsIHNpemVvZihxcnRfbG9jYWwpKQ0KCSAgICA9PSBFUlJPUikNCgl7DQoJCXN0aWlfZXJy
b3Ioc3RpaV9lcnJvcl9jYW5ub3RfYmluZCk7DQoJCXJldHVybiAoc3RpaV9lcnJvcl9jYW5u
b3RfYmluZCk7DQoJfQ0KCXFydF9kYnMoWFhYLCBERUJVR19MRVZFTCwNCgkJIkFmdGVyIHFy
dF9zb2NrZXQgYW5kIHFydF9iaW5kIC0gR29pbmcgdG8gYWRkIHNvY2tldC5cbiIpOw0KDQoJ
aWYgKChzb2NraW5kZXggPSBxcnRfYWRkX3N0aWlfc29jayhzb2NrLCBzb2NrX3NlbmQpKSA9
PSBFUlJPUikNCgl7DQoJCXFydF9kYnMoWFhYLCBERUJVR19MRVZFTCwgIlRvbyBtYW55IG9w
ZW4gc29ja2V0cyxjbG9zaW5nIG5ldyBvbmUuXG4iKTsNCgkJc3RpaV9lcnJvcihxcnRfZV9h
ZGRzb2NrKTsNCgkJY2xvc2Uoc29jayk7DQoJCXJldHVybiAocXJ0X2VfYWRkc29jayk7DQoJ
fQ0KCXFydF9kYnNpaShYWFgsIERFQlVHX0xFVkVMLCAiTGlua2luZyBwb3J0IFsjXSB0byBz
b2NrZXQgWyNdLlxuIiwNCgkJICAoaW50KSBwb3J0LCBzb2NrKTsNCglxcnRfZGJzaShYWFgs
IERFQlVHX0xFVkVMLCAiSW5kZXggWyNdLlxuIiwNCgkJIHNvY2tpbmRleCk7DQoNCglxcnRf
bGlua19wcnRfc29jayhzb2NraW5kZXgsIHBvcnQpOw0KDQoJZnJlZVRhcmdldHAgPSAob2N0
ZXQ0ICopICYgKHFydF9yZW1vdGUudGFyZ2xzdC50YXJnMSk7DQoJcHJvdG9lbmRwID0gKG9j
dGV0NCAqKSAoKGxvbmcpICYocXJ0X3JlbW90ZSkNCgkJCQkrIHNpemVvZihxcnRfcmVtb3Rl
KSAtIDQpOw0KDQoJcXJ0X2RicyhYWFgsIERFQlVHX0xFVkVMLCAiR29pbmcgdG8gcHJvY2Vz
cyB0YXJnZXQuXG4iKTsNCg0KCS8qIGl0IHVzZWQgdG8gYmUgdGhlIGNhc2UgdGhhdCB0aGUg
bmFtZSBvZiB0aGUgcmVtb3RlIG1hY2hpbmUgd2FzICovDQoJLyogYXNzaWduZWQgYXQgaW1w
b3J0aW5nIHRpbWUuIEJ1dCBzaW5jZSB3ZSBzdGFydGVkIGRlYWxpbmcgd2l0aCAqLw0KCS8q
IHJlbW90ZSBpcCBhZGRyZXNzZXMgaW5zdGVhZCBvZiBuYW1lcywgd2UgZG8gbm90IHdhbnQg
dGhhdC4gVGhlICovDQoJLyogbmFtZSAob3IgdGhlIGlwIGFkZHJlc3MpIG9mIHRoZSBtYWNo
aW5lIHdpbGwgYmUgc2VsZWN0ZWQgd2hlbiBhICovDQoJLyogY29ubmVjdGlvbiBpcyBlc3Rh
Ymxpc2hlZCwgYW5kIGJ5IHRoZSBwYXJ0aWN1bGFyIHByb3RvY29sICovDQoJLyogZXN0YWJs
aXNoaW5nIHRoZSBjb25uZWN0aW9uLiAqLw0KCS8qIFRoZSBzdGlpIHByb3RvY29sIHdpbGwg
anVzdCBwaWNrIHRoZSBmaXJzdCBpcCBhZGRyZXNzIGF2YWlhYmxlLiAqLw0KCS8qIFBsZWFz
ZSBub3RlIHRoYXQgaWYgY29ubmVjdCBmYWlscywgd2UgY291bGQgbG9vcCBvdmVyIGFsbCBp
cCAqLw0KCS8qIGFkZHJlc3NlcyBwcm92aWRlZCBieSB0aGUgdGFyZ2V0LiAqLw0KCXN0cmNw
eShwb3J0LT5ybmFtZSwgcG9ydC0+cmhvc3RpbmZvLT5pcF9hZGRyWzBdKTsNCgkvKiBXZSBu
ZWVkIHRvIGFzbG8gdXBkYXRlIHRoZSBmaWVsZCByYWRkciB3aXRoIHRoZSBpcCBhZGRyZXNz
ICovDQoJLyogY2hvc2VuLiAqLw0KCXBvcnQtPnJhZGRyLnNfYWRkciA9IGluZXRfYWRkcihw
b3J0LT5ybmFtZSk7DQoJcXJ0X2Ric3MoWFhYLCBETCwgIk9PcHM6IHJuYW1lID0gJXNcbiIs
IHBvcnQtPnJuYW1lKTsNCg0KDQoJaWYgKHFydF9wcm9jZXNzX3RhcmdldChxcnRfbG9va3Vw
SVBBZHIocG9ydC0+cm5hbWUsICJTZW5kZXJwICIpLA0KCQkJICAgICAgIHBvcnQtPmxzdHJt
YWRkW3N0aWldLA0KCQkJICAgICAgICZmcmVlVGFyZ2V0cCwNCgkJCSAgICAgICBwcm90b2Vu
ZHApID09IEVSUk9SKQ0KCXsNCgkJcXJ0X2RicyhYWFgsIERFQlVHX0xFVkVMLCAiUHJvYmxl
bSBwcm9jZXNzaW5nIGFyZ3VtZW50cy5cbiIpOw0KCQlyZXR1cm4gKHFydF9lX3VuZXhwZWN0
ZWQpOw0KCX07DQoJcXJ0X2RicyhYWFgsIERFQlVHX0xFVkVMLCAiVGFyZ2V0IHByb2Nlc3Nl
ZC5cbiIpOw0KDQoJaWYgKHBvcnQtPmlucW9zLmxvc3MgIT0gMCkNCgl7DQoJCXFydF9yZW1v
dGUudG9zLlJlbGlhYmlsaXR5ID0gKG9jdGV0MSkgKChwb3J0LT5pbnFvcy5sb3NzKSAvIDI1
Nik7DQoJfSBlbHNlDQoJew0KCQlxcnRfcmVtb3RlLnRvcy5SZWxpYWJpbGl0eSA9IChvY3Rl
dDEpIDA7DQoJfQ0KDQoJLyogdW5pdCBvZiBtaWxsaXNlY29uZHMgKi8NCglxcnRfcmVtb3Rl
LnRvcy5SZWNvdmVyeVRpbWVvdXQgPSAob2N0ZXQyKSBwb3J0LT5pbnFvcy5yZWNfdGltZTsN
CglxcnRfcmVtb3RlLnRvcy5MaW1pdE9uRGVsYXkgPSBwb3J0LT5pbnFvcy5tYXhfZGVsYXk7
DQoNCgkvKiBTbWFsbGVzdCBwYWNrZXQgc2l6ZSBpcyBtYWRlIHRvIHRha2Ugb25lIHVzZXIg
cGFja2V0ICovDQoJcXJ0X3JlbW90ZS50b3MuTGltaXRPblBEVUJ5dGVzID0gcG9ydC0+aW5x
b3Muc2l6ZTsNCglxcnRfcmVtb3RlLnRvcy5EZXNQRFVCeXRlcyA9IHBvcnQtPmlucW9zLnNp
emU7DQoNCgkvKiBtaW4gcmF0ZSBhbmQgbWF4IHJhdGUgYXJlIGluIHVuaXQgb2Ygc2Vjb25k
cy4gKi8NCglxcnRfcmVtb3RlLnRvcy5MaW1pdE9uUERVUmF0ZSA9IDEwICogcG9ydC0+aW5x
b3MubWluX3JhdGU7DQoNCglxcnRfcmVtb3RlLnRvcy5EZXNQRFVSYXRlID0gMTAgKiBwb3J0
LT5pbnFvcy5tYXhfcmF0ZTsNCglxcnRfcmVtb3RlLnRvcy5NaW5CeXRlc1hSYXRlID0gMTAg
KiBxcnRfcmVtb3RlLnRvcy5MaW1pdE9uUERVQnl0ZXMNCgkJKiBwb3J0LT5pbnFvcy5taW5f
cmF0ZTsNCg0KCXFydF9yZW1vdGUuc3Rfb3B0aW9ucyA9IChxcnRfcmVtb3RlLnN0X29wdGlv
bnMgJiB+U1RUU1IpIHwgU1RUU1JZZXM7DQoNCglxcnRfcmVtb3RlLnRhcmdsc3QuVGFyZ2V0
Q291bnQgPSAxOw0KCXFydF9yZW1vdGUudGFyZ2xzdC5wbGVuID0gKGxvbmcpIGZyZWVUYXJn
ZXRwDQoJCS0gKGxvbmcpICYocXJ0X3JlbW90ZS50YXJnbHN0KTsNCg0KCXJlbW90ZWxlbiA9
IChsb25nKSBmcmVlVGFyZ2V0cCAtIChsb25nKSAmKHFydF9yZW1vdGUpOw0KCWlmIChyZW1v
dGVsZW4gPj0gTUFYX1NUX05BTSkNCgl7DQoJCXFydF9kYnMoWFhYLCBERUJVR19MRVZFTCwg
IlRvbyBtYW55IHRhcmdldHMgZm9yIGNvbm5lY3QuXG4iKTsNCgkJcmV0dXJuIChxcnRfZV91
bmV4cGVjdGVkKTsNCgl9DQoJLyogQ29ubmVjdGluZyB3aXRoIHRhcmdldCAqLw0KDQoJcXJ0
X2RicyhYWFgsIERFQlVHX0xFVkVMLCAiQWJvdXQgdG8gY29ubmVjdC5cbiIpOw0KDQoJaWYg
KGNvbm5lY3Qoc29jaywgKHN0cnVjdCBzb2NrYWRkciAqKSAmIChxcnRfcmVtb3RlKSwgcmVt
b3RlbGVuKSA9PQ0KCSAgICBFUlJPUikNCgl7DQoJCXN0aWlfZXJyb3IocXJ0X2VfY29ubmVj
dCk7DQoJCXJldHVybiAocXJ0X2VfY29ubmVjdCk7DQoJfQ0KCXFydF9kYnMoWFhYLCBERUJV
R19MRVZFTCwgIkNvbm5lY3RlZC5cbiIpOw0KCXJldHVybiAoc3RpaV9lcnJvcl9ub25lKTsN
Cn0NCg0KLyogQ2hlY2sgdGhpcyBmdW5jdGlvbiEgKi8NCnN0YXRpYyBpbnQNCnFydF9wcm9j
ZXNzX3RhcmdldChvY3RldDQgcmVtX2hvc3QsIGludCByZW1fcG9ydCwNCgkJICAgb2N0ZXQ0
ICoqIHRndHAsIG9jdGV0NCAqIHBlcCkNCnsNCiNpZmRlZiBRdUFMX1NUSUlfREVCVUcNCglj
aGFyICAgICAgICAgICAgcHJlZml4WzE2XTsJLyogRm9yIHByb21wdCAqLw0KI2VuZGlmDQoJ
aW50ICAgICAgICAgICAgIGk7CS8qIENvdW50ZXIsIG1pc2MgaW50ICovDQoJbG9uZyAgICAg
ICAgICAgIGw7CS8qIFVzZWQgZm9yIGFsaWdubWVudCBjYWxjdWxhdGlvbiAqLw0KDQoNCglz
dHJ1Y3QgYVNyY1J1dCAqc3J3cDsJLyogV29ya2luZyBwb2ludGVyIHRvIFNvdXJjZSBSb3V0
ZSAqLw0KCXN0cnVjdCBhVGFyZ2V0ICp3dHA7CS8qIFdvcmtpbmcgVGFyZ2V0IHBvaW50ZXIg
Ki8NCg0KDQoNCgl3dHAgPSAoc3RydWN0IGFUYXJnZXQgKikgKCp0Z3RwKTsJLyogQXJlYSBm
b3IgbmV4dCBUYXJnZXQgKi8NCg0KCS8qIGRvIHZhcmlhYmxlIGxlbmd0aCBzYXBzIGhlcmUg
Ki8NCgl3dHAtPlNBUEJ5dGVzID0gU0FQTEVOOwkvKiBFeGFtcGxlIHVzZXMgMi1vY3RldCBT
QVBzICovDQoNCgkvKiBTQVAsIGlmIHNwZWNpZmllZCwgZm9sbG93cyAiLyIgKi8NCgl3dHAt
PlNBUFswXSA9IDB4RkYgJiAocmVtX3BvcnQgPj4gOCk7CS8qIFVzZXIgc3BlY2lmaWVkIFNB
UCAqLw0KCXd0cC0+U0FQWzFdID0gMHhGRiAmIHJlbV9wb3J0Ow0KDQoJLyogU1QtSUkgd2Fu
dHMgZXZlcnl0aGluZyA0LW9jdGV0IGFsaWduZWQgdG8ga2VlcCBzcGFyY3MgaGFwcHkgKi8N
CglsID0gKGxvbmcpICYod3RwLT5TQVBbd3RwLT5TQVBCeXRlcyAtIDFdKSAtIChsb25nKSB3
dHAgKyAzOw0KCWwgJj0gfjM7DQoJbCArPSAobG9uZykgd3RwOw0KCXNyd3AgPSAoc3RydWN0
IGFTcmNSdXQgKikgbDsJLyogV2hlcmUgYSBzb3VyY2Ugcm91dGUgc2hvdWxkIGdvICovDQoN
CgkvKiBDb21wdXRlIGxlbmd0aCBvZiBUYXJnZXQgcGFyYW1ldGVyICovDQoJd3RwLT5UYXJn
ZXRCeXRlcyA9IChsb25nKSBzcndwIC0gKGxvbmcpIHd0cDsNCg0KCS8qIGZpbmQgZW5kIG9m
IFRhcmdldCBuYW1lICovDQoNCiNpZmRlZiBRdUFMX1NUSUlfREVCVUcNCgkodm9pZCkgc3By
aW50ZihwcmVmaXgsICJUYXJnZXQgICUzZDogIiwgbnRhcmdldHMgKyAxKTsNCiNlbmRpZg0K
DQoJd3RwLT5JUEFkciA9IHJlbV9ob3N0OwkvKiBHZXQgVGFyZ2V0IElQQWRyICovLyogSEg2
NiAqLw0KDQoJLyogU2ltcGxlIHZhbGlkYXRlIG9mIFRhcmdldCBhZGRyZXNzICovDQoJaWYg
KHd0cC0+SVBBZHIgPT0gSU5BRERSX0FOWSkNCgl7DQoJCXFydF9kYnMoWFhYLCBERUJVR19M
RVZFTCwgIlxuSU5BRERSX0FOWSBpcyBub3QgYSB2YWxpZCB0YXJnZXRcbiIpOw0KCQlyZXR1
cm4gKEVSUk9SKTsJLyogV2l0aG91dCB1cGRhdGluZyBmcmVlVGFyZ2V0cCAqLw0KCX0NCgkv
KiBNYWtlIHN1cmUgaXQgYWxsIGZpdHMgKi8NCglpZiAoKChvY3RldDQgKikgc3J3cCA+PSBw
ZXApDQoJICAgIHx8IChudGFyZ2V0cyA+PSBNQVhfVEFSR0VUUyAtIDEpKQ0KCXsNCgkJcXJ0
X2Ric2koWFhYLCBERUJVR19MRVZFTCwNCgkJICAgICJcbkVycm9yOiBUb28gbWFueSB0YXJn
ZXRzIChbI10pIHdpdGggXG4iLCBNQVhfVEFSR0VUUyk7DQoJCXJldHVybiAoRVJST1IpOw0K
CX0NCglmb3IgKGkgPSBudGFyZ2V0cyAtIDE7IGkgPj0gMDsgaS0tKQ0KCXsNCgkJaWYgKCh3
dHAtPlRhcmdldEJ5dGVzID09IHRhcmdldHNbaV0ucC0+VGFyZ2V0Qnl0ZXMpDQoJCSAgICAm
JiAoYmNtcCgoY2hhciAqKSB3dHAsIChjaGFyICopIHRhcmdldHNbaV0ucCwNCgkJCSAgICAg
d3RwLT5UYXJnZXRCeXRlcykgPT0gMCkpDQoJCQlicmVhazsJLyogRm91bmQgYSBkdXBsaWNh
dGUgKi8NCgl9CQkJLyogZW5kIG9mIGZvciBhbGwgdGFyZ2V0cyBsb29wICovDQoNCglpZiAo
aSA+PSAwKQ0KCXsNCgkJc3dpdGNoICh0YXJnZXRzW2ldLnN0YXRlKQ0KCQl7DQoJCWNhc2Ug
VGFyZ1N0YXRlQ29ubmVjdGluZzoNCgkJY2FzZSBUYXJnU3RhdGVDb25uZWN0ZWQ6DQoJCWNh
c2UgVGFyZ1N0YXRlQ2xvc2luZzoNCgkJCWJyZWFrOw0KDQoJCWNhc2UgVGFyZ1N0YXRlTmV3
Og0KCQkJcXJ0X2Ric2lpKFhYWCwgREVCVUdfTEVWRUwsDQoJCQkgICAgIiBEdXBsaWNhdGVz
IHRhcmdldCBbI10sIHRhcmdldCBbI10gaWdub3JlZC5cbiIsDQoJCQkJICBpICsgMSwgbnRh
cmdldHMgKyAxKTsNCg0KCQljYXNlIFRhcmdTdGF0ZUNsb3NlZDoNCgkJCXRhcmdldHNbaV0u
c3RhdGUgPSBUYXJnU3RhdGVOZXc7DQoJCQlyZXR1cm4gKGkpOw0KCQl9CQkvKiBlbmQgb2Yg
b2xkIHRhcmdldCBzdGF0ZSBzd2l0Y2ggKi8NCg0KCQlxcnRfZGJzaShYWFgsIERFQlVHX0xF
VkVMLA0KCQkJICIgICoqKiAgRHVwbGljYXRlcyBhY3RpdmUgdGFyZ2V0IFsjXSBpZ25vcmVk
LlxuIiwNCgkJCSBpICsgMSk7DQoJCXJldHVybiAoRVJST1IpOw0KCX0NCgkvKiBBcHBlbmQg
bmV3IHRhcmdldCB0byBlbmQgb2YgbGlzdCAqLw0KCXRhcmdldHNbbnRhcmdldHNdLnN0YXRl
ID0gVGFyZ1N0YXRlTmV3Ow0KCXRhcmdldHNbbnRhcmdldHNdLnAgPSAoc3RydWN0IGFUYXJn
ZXQgKikgKCp0Z3RwKTsNCgkoKnRndHApID0gKG9jdGV0NCAqKSBzcndwOwkvKiBGb3IgbmV4
dCBUYXJnZXQgKi8NCgludGFyZ2V0cysrOwkJLyogQ291bnQgdGhpcyBvbmUgKi8NCg0KCXJl
dHVybiAobnRhcmdldHMgLSAxKTsNCg0KfQkJCQkvKiBlbmQgb2YgcHJvY2Vzc190YXJnZXQg
Ki8NCg0KLyogRW5kIG9mIEF1eGlsaWFyeSBGdW5jdGlvbnMgKi8NCg0Kc3RpaV9lcnJvcl90
DQpxcnRfc3RpaV9zZW5kKHFydF9vdXRwb3J0X3QgKiBvcCwgY2hhciAqZGF0YWJ1ZiwgaW50
IHN6KQ0Kew0KCXN0cnVjdCBpb3ZlYyAgICBkYXRhaW92Ow0KCXN0cnVjdCBtc2doZHIgICBt
c2doZHI7DQoJaW50ICAgICAgICAgICAgIHNlbnRsZW47DQojaWZkZWYgT1VUX01JQg0KCXN0
cnVjdCB0aW1ldmFsICBsbHRpbWU7DQojZW5kaWYNCg0KCUluc3Rzb2NrYWRkcl9zdDIoc2Vu
ZG5hbWUsKSA9DQoJew0KCQlJbml0c29ja2FkZHJfc3QyKFNUUmVxVW5zcGVjLCAwIC8qIG9w
dF94eHggKi8gKQ0KCX07DQoNCg0KCXFydF9kYnMoWFhYLCBERUJVR19MRVZFTCwgIkRBTkdF
Ui5cbiIpOw0KCWRhdGFpb3YuaW92X2Jhc2UgPSAoY2FkZHJfdCkgZGF0YWJ1ZjsNCglkYXRh
aW92Lmlvdl9sZW4gPSBzejsNCglJbml0TXNnKCYobXNnaGRyKSwgJihzZW5kbmFtZSksIHNp
emVvZihzZW5kbmFtZSksDQoJCSZkYXRhaW92LCAxLCAwLCAwKTsNCglpZiAoKHNlbnRsZW4g
PSBzZW5kbXNnKG9wLT5jbmluZi5hZGQuc3RpaV9hZGQuc2NrdCwgJm1zZ2hkciwgMCkpDQoJ
ICAgID09IEVSUk9SKQ0KCXsNCgkJcXJ0X2RicyhYWFgsIERFQlVHX0xFVkVMLCAiVW5hYmxl
IHRvIHNlbmQgZGF0YS5cbiIpOw0KCQkvKiAkRXhjZXB0aW9uICovDQojaWZkZWYgT1VUX01J
Qg0KCQlpZiAoZ2V0dGltZW9mZGF5KCZsbHRpbWUsIChzdHJ1Y3QgdGltZXpvbmUgKikgTlVM
TCkgPT0gRVJST1IpDQoJCXsNCgkJCXFydF9kYnMoWFhYLCBETCwgIlVuYWJsZSB0byBnZXQg
Y3VycmVudCB0aW1lLlxuIik7DQoJCX0NCgkJKHZvaWQpIHFtcnRfb3V0X2Nubl9mYWlsKG9w
LT5pbmRleCwgbGx0aW1lKTsNCiNlbmRpZg0KCQlzdGlpX2Vycm9yKHFydF9lX3NlbmQpOw0K
CQlyZXR1cm4gKHFydF9lX3NlbmQpOw0KCX0gZWxzZQ0KCXsNCiNpZmRlZiBPVVRfTUlCDQoJ
CWlmIChnZXR0aW1lb2ZkYXkoJmxsdGltZSwgKHN0cnVjdCB0aW1lem9uZSAqKSBOVUxMKSA9
PSBFUlJPUikNCgkJew0KCQkJcXJ0X2RicyhYWFgsIERMLCAiVW5hYmxlIHRvIGdldCBjdXJy
ZW50IHRpbWUuXG4iKTsNCgkJfQ0KCQkodm9pZCkgcW1ydF9vdXRfbXNnX3NlbnQob3AtPmlu
ZGV4LCBsbHRpbWUsIHNlbnRsZW4pOw0KI2VuZGlmDQoJCXFydF9kYnNpaShYWFgsIERFQlVH
X0xFVkVMLCAiWyNdIGJ5dGVzIHNlbnQgb3V0IG9mIFsjXS5cbiIsDQoJCQkgIHNlbnRsZW4s
IGRhdGFpb3YuaW92X2xlbik7DQoJCXFydF9kYnNzKFhYWCwgREVCVUdfTEVWRUwsICJEYXRh
OiBbI10uXG4iLCBkYXRhYnVmKTsNCgl9DQoJcmV0dXJuIChzdGlpX2Vycm9yX25vbmUpOw0K
fQ0KDQovKg0KICogfCogb2N0ZXQ0IGxvb2t1cElQQWRyICggaG9zdHAsIHRleHRwICkgfCog
VXNhZ2U6IHwqCVVzZWQgdG8gbG9va3VwIGEgaG9zdA0KICogbmFtZSwgZmluZCBpdHMgaW50
ZXJuZXQgYWRkcmVzcyhlcykgYW5kIGFzayB0aGUgfCoJdXNlciB0byBzcGVjaWZ5IHdoaWNo
DQogKiBhZGRyZXNzIHNob3VsZCBiZSB1c2VkLiB8KiBBcmd1bWVudHM6IHwqCWhvc3RwCXBv
aW50ZXIgdG8gaG9zdA0KICogbmFtZS9hZGRyZXNzIHN0cmluZyB8Kgl0ZXh0cAlwb2ludGVy
IHRvIHByb21wdCBzdHJpbmcgfCogUmV0dXJuczoNCiAqIHwqCWludGVybmV0IGFkZHJlc3Mg
KG5ldCBvcmRlcikgfCoNCiAqLw0KDQpvY3RldDQgDQpxcnRfbG9va3VwSVBBZHIoY2hhciAq
aG9zdHAsIGNoYXIgKnRleHRwKQ0Kew0KCWludCAgICAgICAgICAgICBpLCBhLCBiLCBjLCBk
Ow0KCXVuc2lnbmVkIGxvbmcgICBhZGRyOw0KCXN0cnVjdCBob3N0ZW50ICpob3N0ZW50cDsN
Cg0KCXFydF9kYnNzcyhYWFgsIERMLCAiWyNdIGhvc3QgWyNdIGhhcyBhZGRyZXNzOlxuIiwg
dGV4dHAsIGhvc3RwKTsNCgkvKiBza2lwIG92ZXIgbGVhZGluZyBzcGFjZXMgb3IgdGFicyAq
Lw0KCXdoaWxlICgoKmhvc3RwID09ICcgJykgfHwgKCpob3N0cCA9PSAnXHQnKSkNCgkJaG9z
dHArKzsNCg0KCS8qIGdldGhvc3RieW5hbWUgZG9lc24ndCBjaGVjayBmb3IgYWRkcmVzcyAm
IHNraXAgbG9va3VwLCBidXQgd2Ugd2lsbCAqLw0KCWlmICgoJzAnIDw9ICpob3N0cCkgJiYg
KCpob3N0cCA8PSAnOScpKQ0KCXsNCgkJaSA9IHNzY2FuZihob3N0cCwgIiV1LiV1LiV1LiV1
IiwgJmEsICZiLCAmYywgJmQpOw0KCQlpZiAoaSA9PSA0KQ0KCQl7DQoJCQlxcnRfZGJzdXV1
dShYWFgsIERMLCAiWyMuIy4jLiNdLlxuIiwgYSwgYiwgYywgZCk7DQoJCQlhZGRyID0gKCgo
MHhGRiAmIGEpIDw8IDI0KQ0KCQkJCXwgKCgweEZGICYgYikgPDwgMTYpDQoJCQkJfCAoKDB4
RkYgJiBjKSA8PCA4KQ0KCQkJCXwgKDB4RkYgJiBkKSk7DQoJCQlyZXR1cm4gKChvY3RldDQp
IGh0b25JUChhZGRyKSk7DQoJCX0gZWxzZQ0KCQl7DQoJCQlxcnRfZGJzKFhYWCwgREwsICJQ
cm9ibGVtOiBob3N0IG5hbWUgd2FzID0gaXAgYWRkcmVzcywgYnV0IGluIHRoZSB3cm9uZyBm
b3JtYXQuXG4iKTsNCgkJCXJldHVybiAoKG9jdGV0NCkgMCk7DQoJCX0NCgl9DQoJaG9zdGVu
dHAgPSBnZXRob3N0YnluYW1lKGhvc3RwKTsNCglpZiAoaG9zdGVudHAgPT0gKHN0cnVjdCBo
b3N0ZW50ICopIE5VTEwpDQoJew0KCQlxcnRfZGJzKFhYWCwgREwsICJHZXRob3N0YnluYW1l
IGZhaWxlZC5cbiIpOw0KCQlyZXR1cm4gKChvY3RldDQpIDApOw0KCX0NCglpZiAoaG9zdGVu
dHAtPmhfYWRkcl9saXN0WzBdID09IChjaGFyICopIE5VTEwpDQoJew0KCQlxcnRfZGJzKFhY
WCwgREwsICJHZXRob3N0YnluYW1lIGZhaWxlZCBieSByZXR1cm5pbmcgbm8gSVAgYWRkcmVz
cy5cbiIpOw0KCQlyZXR1cm4gKChvY3RldDQpIDApOw0KCX0NCgkvKiBHZXQgb2N0ZXRzIGNv
cnJlc3BvbmRpbmcgdG8gc2VsZWN0ZWQgKG5ldCBvcmRlcikgYWRkcmVzcyAqLw0KCWQgPSBo
b3N0ZW50cC0+aF9hZGRyX2xpc3RbMF1bM107DQoJYyA9IGhvc3RlbnRwLT5oX2FkZHJfbGlz
dFswXVsyXTsNCgliID0gaG9zdGVudHAtPmhfYWRkcl9saXN0WzBdWzFdOw0KCWEgPSBob3N0
ZW50cC0+aF9hZGRyX2xpc3RbMF1bMF07DQoJcXJ0X2Ric3V1dXUoWFhYLCBETCwgIlsjLiMu
Iy4jXS5cbiIsIGEsIGIsIGMsIGQpOw0KCWFkZHIgPSAoKCgweEZGICYgYSkgPDwgMjQpDQoJ
CXwgKCgweEZGICYgYikgPDwgMTYpDQoJCXwgKCgweEZGICYgYykgPDwgOCkNCgkJfCAoMHhG
RiAmIGQpKTsNCglyZXR1cm4gKChvY3RldDQpIGFkZHIpOw0KDQp9CQkJCS8qIGVuZCBvZiBs
b29rdXBJUEFkciAqLw0KDQoNCiNlbmRpZgkJCQkvKiBpZm5kZWYgU09MQVJJUyAqLw0K

From seemanta at recjai.ac.in  Tue Apr 23 00:38:56 2002
From: seemanta at recjai.ac.in (seemanta)
Date: Tue, 23 Apr 2002 00:38:56 -0400
Subject: [uClinux-dev] Document.write (
Message-ID: <200204230438.g3N4cus14073@uclinux.org>

An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20020423/09288f6a/attachment-0001.html>

From miles at lsi.nec.co.jp  Tue Apr 23 03:21:49 2002
From: miles at lsi.nec.co.jp (Miles Bader)
Date: 23 Apr 2002 16:21:49 +0900
Subject: [uClinux-dev] patch to get rid of some compiler warnings
Message-ID: <buoadruvq0i.fsf@mcspd15.ucom.lsi.nec.co.jp>

I think these changes shouldn't be controversial; please apply.

Thanks,
-Miles


-------------- next part --------------
A non-text attachment was scrubbed...
Name: uclinux-warnsquash-0.patch
Type: text/x-patch
Size: 3572 bytes
Desc: patch to get rid of some compiler warnings
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20020423/47ec32c7/attachment.patch>
-------------- next part --------------



-- 
97% of everything is grunge

From mathias.fritzson at mecel.se  Tue Apr 23 03:25:14 2002
From: mathias.fritzson at mecel.se (mathias.fritzson at mecel.se)
Date: Tue, 23 Apr 2002 09:25:14 +0200
Subject: [uClinux-dev]
Message-ID: <200204230724.g3N7OGs15189@uclinux.org>



David McCullough wrote:
>Jivin Kendrick Hamilton lays it down ...
>> David,
>>   We used it on some small applications successfully. It is also
>> what the kernel uses (I think) for the 68360. -mcpu32 is the same (I
>> think) as a different flag.
>
>
>Ok,  then I think the best thing would be to remove all -msep-data
>flags from the config.arch,  make clean and rebuild.  This should
>get around some of the relative branch problems that I think the errors
>were related to.  If there aren't any then obviously ignore this advice ;
-)
>
>The toolchain knows how to build "non-pic" apps,  so removing -msep-data
>from everywhere and rebuilding should be all that is needed ;-)
>

Tried and it worked, I guess however that -msep-data could be kept for the
uClibc compilation, since it compiled with the flag before. I'm just
speculating here, I have just tiny knowledge about compilers and I havn't
had a look at the toolchain, but might it be so that the changes in the
compiler doesn't apply to the -mcpu32 flag and therefore the -msep-data
flag just messes things up. Ie support for the mcpu32 has to be added by
someone that needs that -msep-data support..

/Mathias


>> On Tue, 23 Apr 2002, David McCullough wrote:
>>
>> >
>> > Jivin mathias.fritzson at mecel.se lays it down ...
>> > > >Jivin mathias.fritzson at mecel.se lays it down ...
>> > > >> Hello again,
>> > > >>
>> > > >> Thanks for the latest tip David, the -m68000 flag worked..
>> > > >
>> > > >Ok,  but if you are using a 683XX,  is there an option specific for
that ?
>> > > >Check your kernel compile and see what options (-m options) are
used.
>> > > >
>> > > The kernel uses the -mcpu32 flag, and that seems to work alright but
when I
>> > > tried to use it for the apps and init I got the same error.
>> >
>> >
>> > Doesn't look good,  I've never targeted a cpu32 board,  anyone out
there
>> > used the compiler on CPU32 stuff successfully ?
>> >

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From miles at lsi.nec.co.jp  Tue Apr 23 03:27:05 2002
From: miles at lsi.nec.co.jp (Miles Bader)
Date: 23 Apr 2002 16:27:05 +0900
Subject: [uClinux-dev] patch to make `panic' halt
Message-ID: <buo662ivprq.fsf@mcspd15.ucom.lsi.nec.co.jp>

Hi, this is a simple patch that adds an option to make the `panic'
function call `machine_halt' rather than going into an infinite loop.
It does so only when `panic_timeout' is -1 (I set it in the
machine-specific startup code).

This is useful for e.g. simulators, which you don't want sitting there
spinning when something goes wrong.

Could you apply it?

Thanks,

-Miles


-------------- next part --------------
A non-text attachment was scrubbed...
Name: uclinux-panic-halt.patch
Type: text/x-patch
Size: 595 bytes
Desc: patch to make `panic' halt
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20020423/06f5791e/attachment.patch>
-------------- next part --------------



-- 
`Cars give people wonderful freedom and increase their opportunities.
 But they also destroy the environment, to an extent so drastic that
 they kill all social life' (from _A Pattern Language_)

From joel at cicese.mx  Tue Apr 23 04:36:49 2002
From: joel at cicese.mx (Joel Eduardo Rodriguez Ramirez)
Date: Tue, 23 Apr 2002 01:36:49 -0700 (PDT)
Subject: [uClinux-dev] RTAI on uClinux for Motorola Coldfire 5407 ???
Message-ID: <200204230836.BAA11981@geofisica.cicese.mx>

Hi every one | uclinux-dev
I would like to thank this , so very special
uclinux list, above all Mr. Bernard Khun, for a so 
explendid README on flash boot/ loader
I'm a newee!! , ...thanks againg.
Joel Rodr'iguez
joel at itensenada.edu.mx
joel at cicese.mx
http://www.cicese.mx/~joel/index.html
P.S. I try to follow prety much every mail,
will keep trying.

Bernhard Kuhn wrote:

   Vladimir Vorobyov schrieb:

   > Do you plan to support MCF5407 by your RTAI ?

   I started to port RTAI on Dragonball, then moved on
   to MCF5307 (NETtel) and finaly ported it ot MCF5272.

   Afaik, all MCF5xxx platforms are based on the 5307
   tree and only some files like config.c are different.
   So adding support for 5407 should be fairly easy: this
   task is mostly depended to the interrupt controller:
   with 5272 it is possible to assign any interrupt any
   interrupt priority level while the builtin interrupt
   sources of the 5307 are limited configurable.

   BTW.: the Dragonballs are even more limited so that
   you basically can only have real time scheduler
   but no other real time interrupts (there exists a
   different implementation that explictly masks lower
   logical interrupt levels instead of relaying on the
   physical interrupt levels, but this is/was very error
   prone).

   Back to your question: since i don't have a 5407 target,
   i won't be able to create the RTAI support for it ...

   best regards

   Bernhard

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From olivierp at actimage.fr  Tue Apr 23 05:56:57 2002
From: olivierp at actimage.fr (Olivier PIERRAT)
Date: Tue, 23 Apr 2002 11:56:57 +0200
Subject: [uClinux-dev] to launch a process or a thread in the kernel
Message-ID: <3CC52FE9.80106@actimage.fr>

Hello,

I am working on a M5272C3 board, with uClinux and a 2.0.39 kernel.
I want to create a process or a thread in the uClinux kernel, when the 
kernel starts.

What are the differents step to do the work ? Can you give me some 
how-to or links which describes that ?

Where must be insert the init of the process ? HOw to define this 
process or thread ?

Thank you for your answers.

Olivier.

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From anton.bachmayr at netzteil.at  Tue Apr 23 06:20:08 2002
From: anton.bachmayr at netzteil.at (Anton Bachmayr)
Date: Tue, 23 Apr 2002 12:20:08 +0200
Subject: [uClinux-dev] uCsim newbie questions
Message-ID: <5E27DC0043076D4AA2E1C7DD04207AD601AC0F@homebase.netzteil.at>


Hi List,

I got my uCsimm log time ago - to play around, but didn't play with it a
lot.

So recently a project got on my desk, which my old uCsimm seemd to fit.
I updated the bootstrap (to v1.5.2) since i had the atmel version of
uCsimm.
My build environment seems to be ok:
uClinux-dist-20020411.tar.gz
m68k-elf-tools-20020410.tar.gz

My workstation OS is RH7.2 (i work on it via SSH Shell from my Win2k PC)

So here my questions:

If i select my target (lineo/uCsimm - linux-2.4.x - uC-libc) will the
image (1,6MB), make (after make dep) creates, work imediately?

If i select my target (lineo/uCsimm - linux-2.0.x - uClibc) is it normal
that the image has 28MB (wouldn't fit anyway)?

Is my uCsimm broken if it reeboots after launching program (after
successfully uploading the new image),or i get an error using goram
(after successfully uploading the new image)?

Is there any linux-2.4.x support for uCsimm?


Thanks in advance.

Yours 
Anton

+++++++++++++++++++++++++++++++++++++++++++++++++
Everything you love will reject you or die.
Everything you ever create will be thrown away.
Everything you are proud of will end up as trash.
+++++++++++++++++++++++++++++++++++++++++++++++++
Anton Sebastian Bachmayr
Netzteil - Werkstatt fuer Neue Medien
e-Engineering Dpt.
Bachmayr & Moser OEG
Stadtplatz 34
A- 5280 Braunau
email: anton.bachmayr at netzteil.at
www: http://www.netzteil.at/
tel: ++ 43 - 7722 - 63 884 50
fax: ++ 43 - 7722 - 63 884 10
+++++++++++++++++++++++++++++++++++++++++++++++++
Ihre Website als Informationswerkzeug f?r Ihr
Unternehmen?
Pflegen Sie Ihre Internetseiten direkt im
Browser, ohne Spezial-Kenntnisse, ohne neuer
Hard- und Software!
Fragen? 
Interessiert? 
-> http://www.bauteil.com
+++++++++++++++++++++++++++++++++++++++++++++++++
 
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From heiko.degenhardt at sentec-elektronik.de  Tue Apr 23 07:04:15 2002
From: heiko.degenhardt at sentec-elektronik.de (Heiko Degenhardt)
Date: Tue, 23 Apr 2002 13:04:15 +0200
Subject: [uClinux-dev] to launch a process or a thread in the kernel
In-Reply-To: <3CC52FE9.80106@actimage.fr>; from olivierp@actimage.fr on Tue, Apr 23, 2002 at 11:56:57AM +0200
References: <3CC52FE9.80106@actimage.fr>
Message-ID: <20020423130415.A6725@www2.sentec-elektronik.de>

Hi Olivier, 

* On Tue, Apr 23, 2002 at 11:56:57AM +0200, Olivier PIERRAT wrote:
> I want to create a process or a thread in the uClinux kernel, when the 
> kernel starts.

I don't know if I misunderstand your problem.
But to start a program at boot time, you can change the file
"rc". Everything in there is executed at boot time, as for
instance the autoexec.bat was in dos/win times.
I don't know which rc is copied into your romfs/etc/ directory.
May be you can look at vendors/Generic/big/rc to see if that
one is used during the build process of your kernel.
To start a process from there just insert a line as
"/bin/myproc &"
(the "&" starts the process in the background). 

Rgds.
Heiko.

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From udc at naftan.by  Tue Apr 23 08:50:58 2002
From: udc at naftan.by (Yurij Sysoev)
Date: Tue, 23 Apr 2002 14:50:58 +0200
Subject: [uClinux-dev] to launch a process or a thread in the kernel
References: <3CC52FE9.80106@actimage.fr>
Message-ID: <3CC558B2.3060105@naftan.by>

Hi,

Olivier PIERRAT wrote:

> I want to create a process or a thread in the uClinux kernel, when the

> kernel starts.
[...] 
> Where must be insert the init of the process ? HOw to define this

> process or thread ?


Fortunately, it's very simple :-)
You can find some ideas directly in /init/main.c (see kernel_thread()).

Yurij


This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From ilanp at galileo.co.il  Tue Apr 23 08:02:08 2002
From: ilanp at galileo.co.il (Ilan Pollak)
Date: Tue, 23 Apr 2002 15:02:08 +0300
Subject: [uClinux-dev] Another newbie question
Message-ID: <3CC54D40.6050108@galileo.co.il>

I've compiled uClinux 2.4.17 for armnommu with minimal features: ROMFS 
support, and Networks support for ethernet.
i came with a 541KBytes vmlinux, is that a normal size ?
how much memory will i need to run uclinux on a developement platform 
(i'd like to run busybox as well) ?
thanks
ilan.

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From davidm at snapgear.com  Tue Apr 23 08:28:54 2002
From: davidm at snapgear.com (David McCullough)
Date: Tue, 23 Apr 2002 22:28:54 +1000
Subject: [uClinux-dev] uCsim newbie questions
In-Reply-To: <5E27DC0043076D4AA2E1C7DD04207AD601AC0F@homebase.netzteil.at>; from anton.bachmayr@netzteil.at on Tue, Apr 23, 2002 at 12:20:08PM +0200
References: <5E27DC0043076D4AA2E1C7DD04207AD601AC0F@homebase.netzteil.at>
Message-ID: <20020423222854.A31594@beast.internal.moreton.com.au>


Jivin Anton Bachmayr lays it down ...
> 
> Hi List,
> 
> I got my uCsimm log time ago - to play around, but didn't play with it a
> lot.
> 
> So recently a project got on my desk, which my old uCsimm seemd to fit.
> I updated the bootstrap (to v1.5.2) since i had the atmel version of
> uCsimm.
> My build environment seems to be ok:
> uClinux-dist-20020411.tar.gz
> m68k-elf-tools-20020410.tar.gz
> 
> My workstation OS is RH7.2 (i work on it via SSH Shell from my Win2k PC)
> 
> So here my questions:
> 
> If i select my target (lineo/uCsimm - linux-2.4.x - uC-libc) will the
> image (1,6MB), make (after make dep) creates, work imediately?

It should do,  I haven't tried it recently but that is the preferred
configuration.

> If i select my target (lineo/uCsimm - linux-2.0.x - uClibc) is it normal
> that the image has 28MB (wouldn't fit anyway)?

No,  something is wrong here.  Stay with the config above.

> Is my uCsimm broken if it reeboots after launching program (after
> successfully uploading the new image),or i get an error using goram
> (after successfully uploading the new image)?
> 
> Is there any linux-2.4.x support for uCsimm?

The image.bin that is produced is a flash image,  not a RAM image.
So you need to download it and program it into flash,  then run it
from flash,

Cheers,
Davidm

-- 
David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
davidm at snapgear.com  Fx: +61 7 3891 3630  825 Stanley St., W'gabba QLD 4102, Oz
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From siddons at bnl.gov  Tue Apr 23 09:03:03 2002
From: siddons at bnl.gov (D. Peter Siddons)
Date: Tue, 23 Apr 2002 09:03:03 -0400
Subject: [uClinux-dev] uClibc - uC-libc again
References: <200204191122.g3JBMse27160@uclinux.org> <20020420102559.A26433@beast.internal.moreton.com.au> <3CC40575.CBD5FF78@bnl.gov> <20020423095444.B5844@beast.internal.moreton.com.au>
Message-ID: <3CC55B87.289F7B8C@bnl.gov>

Excellent. THanks, David.

David McCullough wrote:
> 
> Jivin D. Peter Siddons lays it down ...
> > Hi All,
> >    I need to build an app with libpthread, so that means, I think, that
> > I need to finally switch to the new uClibc. I had a clean install of
....
....
> > If not, what is going on? I tried this process with Sash and the Minix
> > shell, with essentially the same behaviour for both libraries.
> 
> The crypt functions are different,  you will need to generate a new
> passwd file for use with uClibc,  there is a program in the log directory
> that can do this for you.  uClibc crypt is the same as your host dev system,
> uC-libc is the one that is different,
> 
> Cheers,
> Davidm
> 
> --
> David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
> davidm at snapgear.com  Fx: +61 7 3891 3630  825 Stanley St., W'gabba QLD 4102, Oz
> This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/

-- 
-----------------
D. Peter Siddons
National Synchrotron Light Source, Bldg. 725D
Brookhaven National Laboratory
Upton
New York 11973
Email: siddons at bnl.gov
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From olivierp at actimage.fr  Tue Apr 23 09:15:48 2002
From: olivierp at actimage.fr (Olivier PIERRAT)
Date: Tue, 23 Apr 2002 15:15:48 +0200
Subject: [uClinux-dev] to launch a process or a thread in the kernel
References: <3CC52FE9.80106@actimage.fr> <3CC558B2.3060105@naftan.by>
Message-ID: <3CC55E84.7000208@actimage.fr>

Hi,

I will try this way. This the solution I find in several books too.
I try and ask some questions if it does not work :-).

Thank you for your answer.

Olivier.

Yurij Sysoev wrote:

> Hi,
> 
> Olivier PIERRAT wrote:
> 
>> I want to create a process or a thread in the uClinux kernel, when the
> 
> 
>> kernel starts.
> 
> [...]
> 
>> Where must be insert the init of the process ? HOw to define this
> 
> 
>> process or thread ?
> 
> 
> 
> Fortunately, it's very simple :-)
> You can find some ideas directly in /init/main.c (see kernel_thread()).
> 
> Yurij
> 
> 
> This message resent by the uclinux-dev at uclinux.org list server 
> http://www.uClinux.org/

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From olivierp at actimage.fr  Tue Apr 23 09:14:26 2002
From: olivierp at actimage.fr (Olivier PIERRAT)
Date: Tue, 23 Apr 2002 15:14:26 +0200
Subject: [uClinux-dev] to launch a process or a thread in the kernel
References: <3CC52FE9.80106@actimage.fr> <20020423130415.A6725@www2.sentec-elektronik.de>
Message-ID: <3CC55E32.1070308@actimage.fr>

Hi Heiko,

This is a solution. But if I do that, the process launched is an 
application process, like every command enter at the prompt. What I want 
to do is to launch a process or thread in the kernel like the process 
which give me the prompt.

After a few chapters of book, I read I think I should create a thread 
using kernel_thread(). This is the solution Yurij give too.

I will try this way.

Thanks for your answer.

Olivier.

Heiko Degenhardt wrote:

> Hi Olivier, 
> 
> * On Tue, Apr 23, 2002 at 11:56:57AM +0200, Olivier PIERRAT wrote:
> 
>> I want to create a process or a thread in the uClinux kernel, when the 
>> kernel starts.
> 
> 
> I don't know if I misunderstand your problem.
> But to start a program at boot time, you can change the file
> "rc". Everything in there is executed at boot time, as for
> instance the autoexec.bat was in dos/win times.
> I don't know which rc is copied into your romfs/etc/ directory.
> May be you can look at vendors/Generic/big/rc to see if that
> one is used during the build process of your kernel.
> To start a process from there just insert a line as
> "/bin/myproc &"
> (the "&" starts the process in the background). 
> 
> Rgds.
> Heiko.
> 
> This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From anton.bachmayr at netzteil.at  Tue Apr 23 09:48:35 2002
From: anton.bachmayr at netzteil.at (Anton Bachmayr)
Date: Tue, 23 Apr 2002 15:48:35 +0200
Subject: [uClinux-dev] uCsim newbie questions
Message-ID: <5E27DC0043076D4AA2E1C7DD04207AD601AC10@homebase.netzteil.at>



> > So here my questions:
> > 
> > If i select my target (lineo/uCsimm - linux-2.4.x - 
> uC-libc) will the 
> > image (1,6MB), make (after make dep) creates, work imediately?
> 
> It should do,  I haven't tried it recently but that is the 
> preferred configuration.

That's what i thought from reading the list archives

> 
> > If i select my target (lineo/uCsimm - linux-2.0.x - uClibc) is it 
> > normal that the image has 28MB (wouldn't fit anyway)?
> 
> No,  something is wrong here.  Stay with the config above.

Above config is the prefered config anyway

> > Is my uCsimm broken if it reeboots after launching program (after 
> > successfully uploading the new image),or i get an error using goram 
> > (after successfully uploading the new image)?
> > 
> > Is there any linux-2.4.x support for uCsimm?
> 
> The image.bin that is produced is a flash image,  not a RAM 
> image. So you need to download it and program it into flash,  
> then run it from flash,
 
Hmm, i tried to flash it, but all i see in minicom was either "erase.."
-> uCsimm hangs or "era" -> uCsimm reboots.
I tried to elliminate the following issues:
- weak power -> uCsimm Gardener gets power from USB (+5v/500mA) - should
really do
- outdated bootloader for atmel uCsimm -> updated v1.5.2
- content of ram (after loading image.bin) starting from address
0x00020000 matches the image.bin file


Any ideas?


My next step is to get a new 3.3V voltage regulator, maybe this is the
weak point (but there are no voltage drops - but couldn't get a
oscilloscope to proove).


yours
Anton
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From ravi at multitech.co.in  Tue Apr 23 10:03:23 2002
From: ravi at multitech.co.in (Ravi Ganesh)
Date: Tue, 23 Apr 2002 19:33:23 +0530
Subject: [uClinux-dev] Daemons on ucLinux ?
Message-ID: <3CC569AB.160DBEB1@multitech.co.in>

Hi,
    Yet another new bee for uclinux. I got a query.

    Can we run the standard daemons (Apache, Squid, PPTPDetc..) on
ucLinux directly?


Regards,
Ravi.

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From stefan.keller-tuberg at alcatel.com  Tue Apr 23 10:15:17 2002
From: stefan.keller-tuberg at alcatel.com (Stefan Keller-Tuberg)
Date: Tue, 23 Apr 2002 10:15:17 -0400
Subject: [uClinux-dev] uClibc problems
Message-ID: <3CC56C75.E5CB321F@alcatel.com>

Hi,

Here's the problem: When I compile and run a "hello world" programme using
uC-libc, it works OK. When I compile and run the same programme using uClibc, it
crashes with an address error (compiler and linker don't complain at all). Any
hints?

I'm using a uCsimm, the 20020410 version of m68k-elf-tools, the 20020411 version
of uClinux-dist. I copied the Lineo/uCdimm version of config.uClibc into
Lineo/uCsimm in order to compile and use uClibc.

I expect the answer is going to be simple. I just can't see it.

Thanks,
Stefan

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From mathias.fritzson at mecel.se  Tue Apr 23 11:34:10 2002
From: mathias.fritzson at mecel.se (mathias.fritzson at mecel.se)
Date: Tue, 23 Apr 2002 17:34:10 +0200
Subject: [uClinux-dev] Simple Q..
Message-ID: <200204231533.g3NFXBs19541@uclinux.org>

Hi

I've tried to finde the struct "current", for a long time now, it doesnt
seem to exist but is used everywhere. We are trying to debug the opening of
tty1 and ttyS0.

In the function "dir_namei" this assingnment occurs "base =
current->fs->pwd;"  but we cant find the struct current in the Systems.map
file, tried to do some intelligent searches in the tree but the there are
too many matches or none at all..
So there got to be some trick here, does anyone have a clue ??

It seems unitiated containing crap but yet not all random..

Thanks

/Mathias

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From anton.bachmayr at netzteil.at  Tue Apr 23 13:36:17 2002
From: anton.bachmayr at netzteil.at (Anton Bachmayr)
Date: Tue, 23 Apr 2002 19:36:17 +0200
Subject: [uClinux-dev] uCsim newbie questions
Message-ID: <5E27DC0043076D4AA2E1C7DD04207AD601AC11@homebase.netzteil.at>


> My next step is to get a new 3.3V voltage regulator, maybe 
> this is the weak point (but there are no voltage drops - but 
> couldn't get a oscilloscope to proove).
> 

It was the Voltage regulator!
ucsimm draws 150mA when erasing the flash memory the VR used only gives
100mA

Big problems - Simple solution 

Yours
Anton
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From justin.wojdacki at analog.com  Tue Apr 23 13:47:31 2002
From: justin.wojdacki at analog.com (Justin Wojdacki)
Date: Tue, 23 Apr 2002 10:47:31 -0700
Subject: [uClinux-dev] Simple Q..
References: <200204231533.g3NFXBs19541@uclinux.org>
Message-ID: <3CC59E33.14A84C5E@analog.com>

mathias.fritzson at mecel.se wrote:
> 
> Hi
> 
> I've tried to finde the struct "current", for a long time now, it doesnt
> seem to exist but is used everywhere. We are trying to debug the opening of
> tty1 and ttyS0.
> 
> In the function "dir_namei" this assingnment occurs "base =
> current->fs->pwd;"  but we cant find the struct current in the Systems.map
> file, tried to do some intelligent searches in the tree but the there are
> too many matches or none at all..
> So there got to be some trick here, does anyone have a clue ??
> 
> It seems unitiated containing crap but yet not all random..
> 
> Thanks
> 
> /Mathias
> 
> This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/

How current is defined varies from CPU to CPU (for example, in MIPS,
it's stored in $gp, while in M68K, it's a structure in memory).

See asm/current.h for your particular platform to see how current is
defined. 

-- 
-------------------------------------------------
Justin Wojdacki        
justin.wojdacki at analog.com         (408) 350-5032
Communications Processors Group -- Analog Devices
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From ken at reasonability.net  Tue Apr 23 14:52:49 2002
From: ken at reasonability.net (Ken Treis)
Date: Tue, 23 Apr 2002 11:52:49 -0700
Subject: [uClinux-dev] uClibc problems
References: <3CC56C75.E5CB321F@alcatel.com>
Message-ID: <3CC5AD81.60002@reasonability.net>

Stefan Keller-Tuberg wrote:

>Hi,
>
>Here's the problem: When I compile and run a "hello world" programme using
>uC-libc, it works OK. When I compile and run the same programme using uClibc, it
>crashes with an address error (compiler and linker don't complain at all). Any
>hints?
>
You might want to double-check your compiler options.  Specifically, 
look for -m options in ARCH_CFLAGS and compare them to those that are 
being used in your uC-libc build.  My guess is that you're missing 
something like -m68000.

The compiler will quite happily produce binaries for the completely 
wrong architecture if you don't get these flags right.  It's just doing 
what it's been told to do.

>I'm using a uCsimm, the 20020410 version of m68k-elf-tools, the 20020411 version
>of uClinux-dist. I copied the Lineo/uCdimm version of config.uClibc into
>Lineo/uCsimm in order to compile and use uClibc.
>
>I expect the answer is going to be simple. I just can't see it.
>

--
Ken Treis
ken at reasonability.net


This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From davidm at snapgear.com  Tue Apr 23 20:22:17 2002
From: davidm at snapgear.com (David McCullough)
Date: Wed, 24 Apr 2002 10:22:17 +1000
Subject: [uClinux-dev] uClibc problems
In-Reply-To: <3CC56C75.E5CB321F@alcatel.com>; from stefan.keller-tuberg@alcatel.com on Tue, Apr 23, 2002 at 10:15:17AM -0400
References: <3CC56C75.E5CB321F@alcatel.com>
Message-ID: <20020424102217.B1561@beast.internal.moreton.com.au>


Jivin Stefan Keller-Tuberg lays it down ...
> Hi,
> 
> Here's the problem: When I compile and run a "hello world" programme using
> uC-libc, it works OK. When I compile and run the same programme using uClibc, it
> crashes with an address error (compiler and linker don't complain at all). Any
> hints?
> 
> I'm using a uCsimm, the 20020410 version of m68k-elf-tools, the 20020411 version
> of uClinux-dist. I copied the Lineo/uCdimm version of config.uClibc into
> Lineo/uCsimm in order to compile and use uClibc.
> 
> I expect the answer is going to be simple. I just can't see it.

Xcopilot is the only target I tested with the latest uClibc that is
included with that distro.  Check the config.uClibc for that and also look
through the config.arch.  config.arch will be quite different at it includes
support for uC-libc shared libraries,  but changes to still work with uClibc.

The uCdimm/uCsimm stuff is probably a little out of date.

Cheers,
Davidm

-- 
David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
davidm at snapgear.com  Fx: +61 7 3891 3630  825 Stanley St., W'gabba QLD 4102, Oz
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From lvjianguo at davworld.net  Tue Apr 23 20:32:19 2002
From: lvjianguo at davworld.net (lvjianguo)
Date: Wed, 24 Apr 2002 08:32:19 +0800
Subject: [uClinux-dev] malloc() dump for 16M RAM on uClinux-2.0.38
Message-ID: <003501c1eb27$7e8f3190$2f64a8c0@rdcenter.com>

I using the uClinux 2.0.38pre10 on ucdimm, I soldered a 16M RAM chip instead of the old one (8M), then modified the rom.ld file (linux/arch/m68knommu/platform/68VZ328/ucdimm/):

    MEMORY
        {
            ...            // Flash address
            ramvec : ORIGIN = 0x00000000, LENGTH = 1024
            ram : ORIGIN = 0x00020000, LENGTH = 0x01000000 - 0x20000
            eram : ORIGIN = 0x01000000, LENGTH = 1
        }

following I rebuild the kernel and writing a simple application to test the memory:

    int main(void)
    {
        ...
        buf = malloc(0x600000);        // 6M
        if (buf == NULL) {
            printf("allocate memory failed\n");
            fflush(stdout);
            return (-1);
        }

        printf("allocate memory OK\n");
        free(buf);
        return (0);
    }

the system is dead when calling the malloc(). I must be reset the ucdimm board. If I changed the size to 0x400000 (4M), It's nothing to be happened, allocate memory OK. then I resume the rom.ld:

    MEMORY
        {
            ...            // Flash address
            ramvec : ORIGIN = 0x00000000, LENGTH = 1024
            ram : ORIGIN = 0x00020000, LENGTH = 0x00800000 - 0x20000
            eram : ORIGIN = 0x00800000, LENGTH = 1
        }

It's OK! If I try to allcoate 6M memory buffer, the malloc() print some error information and return NULL. 

I add some printk() in kernel and record some information when booting the kernel:

memory_start: 8ef30
memory_end: ffc000
start_mem: 8ef30
virtual_end: ffc000
the memory page and page size is OK!

Why?
Thanks for your help!

Regards,
Aavan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20020424/352c5852/attachment.html>

From gerg at snapgear.com  Tue Apr 23 20:51:13 2002
From: gerg at snapgear.com (Greg Ungerer)
Date: Wed, 24 Apr 2002 10:51:13 +1000
Subject: [uClinux-dev] patch to get rid of some compiler warnings
References: <buoadruvq0i.fsf@mcspd15.ucom.lsi.nec.co.jp>
Message-ID: <3CC60181.8010308@snapgear.com>


Hi Miles,

Miles Bader wrote:
> I think these changes shouldn't be controversial; please apply.

Done.

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

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From gerg at snapgear.com  Tue Apr 23 21:00:36 2002
From: gerg at snapgear.com (Greg Ungerer)
Date: Wed, 24 Apr 2002 11:00:36 +1000
Subject: [uClinux-dev] patch to make `panic' halt
References: <buo662ivprq.fsf@mcspd15.ucom.lsi.nec.co.jp>
Message-ID: <3CC603B4.1090403@snapgear.com>

Hi Miles,

Miles Bader wrote:
> Hi, this is a simple patch that adds an option to make the `panic'
> function call `machine_halt' rather than going into an infinite loop.
> It does so only when `panic_timeout' is -1 (I set it in the
> machine-specific startup code).
> 
> This is useful for e.g. simulators, which you don't want sitting there
> spinning when something goes wrong.
> 
> Could you apply it?

Done.

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

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From fantom_xu at hotmail.com  Tue Apr 23 22:17:29 2002
From: fantom_xu at hotmail.com (Xu Fantom)
Date: Wed, 24 Apr 2002 10:17:29 +0800
Subject: [uClinux-dev] 2.4.x Compile error
Message-ID: <F144Y4kJSFsxf4yp8AR00000b2d@hotmail.com>

hi all,

I download uClinux-dist-20020306.tar.gz from www.uclinux.org.
when i compile the kernel, (with some applications selected, such as mount, 
ping ...)it reports lot of errors, just like this:

m68k-elf-gcc -m5307 -DCONFIG_COLDFIRE -Os -g -fomit-frame-pointer  -Dlinux 
-D__linux__ -Dunix -D__uClinux__ -DEMBED 
-I/0306/uClinux-dist/lib/libc/include -I/0306/uClinux-dist/lib/libm 
-I/0306/uClinux-dist -fno-builtin -msep-data 
-I/0306/uClinux-dist/linux-2.4.x/include -DHAVE_NFS   -c -o nfsmount.o 
nfsmount.c
In file included from nfs_mount3.h:15,
                 from nfsmount.c:51:
/0306/uClinux-dist/lib/libc/include/linux/nfs_mount.h:46: field `root' has 
incomplete type
make[2]: *** [nfsmount.o] Error 1
make[2]: Leaving directory `/0306/uClinux-dist/user/mount'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/0306/uClinux-dist/user'
make: *** [subdirs] Error 1

I wonder if these source code has not been tested before distribution or I 
do something wrong?  

If I compile the kernel without changing the settings, everything is OK.

_________________________________________________________________
???????? Web ?????? ? MSN Hotmail?http://www.hotmail.com/cn

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From petero at cvs.com.au  Wed Apr 24 00:11:08 2002
From: petero at cvs.com.au (Peter Ogilvy)
Date: Wed, 24 Apr 2002 14:11:08 +1000
Subject: [uClinux-dev] BDM and GDB with 5272
Message-ID: <5.1.0.14.1.20020424132601.00a95300@localhost>

Hi All,

We're having trouble connecting with our snapgear LITE card
using GDB and the BDM interface. We use a P&E cable.

What versions of GDB and which BDM patches/drivers are people applying.

I've had a search on the web and found Pavel Pisa's detailed page,
also the www.cybertec.com.au driver, amoung others, but I'm unsure
which is best suited to my needs.

We are buidling 2.4 kernals on a Mandrake 8.0 host.

Peter

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From bruce at tele-ip.com  Wed Apr 24 01:00:06 2002
From: bruce at tele-ip.com (Bruce Paterson)
Date: Wed, 24 Apr 2002 15:00:06 +1000
Subject: [uClinux-dev] BDM and GDB with 5272
References: <5.1.0.14.1.20020424132601.00a95300@localhost>
Message-ID: <3CC63BD6.E586A67@tele-ip.com>

Peter Ogilvy wrote:
> 
> Hi All,
> 
> We're having trouble connecting with our snapgear LITE card
> using GDB and the BDM interface. We use a P&E cable.
> 
> What versions of GDB and which BDM patches/drivers are people applying.
> 
> I've had a search on the web and found Pavel Pisa's detailed page,
> also the www.cybertec.com.au driver, amoung others, but I'm unsure
> which is best suited to my needs.

Pavel sent me this message recently:

Hello,

I have prepared patch for GDB-5.1.1 with "call"
bug fixed. Please look at 

  http://cmp.felk.cvut.cz/~pisa/m683xx/

There is GDB binary and Insight binary
as well.

Best wishes

.... so I think his driver should now work with Insight. The previous
Insight mods
related to a different driver which seemed less robust.

-- 
Cheers,
Bruce
-------------------------------------------------------------------
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom
they are addressed. If you have received this email in error please
notify the system manager.

    /\\\/\\\/\\\    /   /      Bruce Paterson          
   /  \\\ \\\ \\\  /   /    Senior Design Engineer
  /   /\\\/\\\/\\\/   /   87 Peters Ave, Mulgrave, Vic, 3170
 /   /  \\\ \\\ \\\  /  PO Box 4112, Mulgrave, Vic, 3170, Australia
/   /    \\\/\\\ \\\/   Ph: +61 3 8561 4232   Fax: +61 3 9560 9055
      Tele-IP Ltd.      Email: bruce at tele-ip.com    Icq: #32015991
                        WWW:   http://www.tele-ip.com       VK3TJN
-------------------------------------------------------------------
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From heiko.degenhardt at sentec-elektronik.de  Wed Apr 24 01:12:03 2002
From: heiko.degenhardt at sentec-elektronik.de (Heiko Degenhardt)
Date: Wed, 24 Apr 2002 07:12:03 +0200
Subject: [uClinux-dev] BDM and GDB with 5272
In-Reply-To: <5.1.0.14.1.20020424132601.00a95300@localhost>; from petero@cvs.com.au on Wed, Apr 24, 2002 at 02:11:08PM +1000
References: <5.1.0.14.1.20020424132601.00a95300@localhost>
Message-ID: <20020424071203.A9686@www2.sentec-elektronik.de>

Hi Peter, 

* On Wed, Apr 24, 2002 at 02:11:08PM +1000, Peter Ogilvy wrote:
> What versions of GDB and which BDM patches/drivers are people applying.

I would try the toolchain of 
http://www.uclinux.org/pub/uClinux/m68k-elf-tools/

They have a m68k-bdm-elf-gdb included, that should work in your
case, too. If you need to compile it of your own, please email
me, and I'll send you the steps I did to get it running with
Chris Johns' patches on my SuSE 7.2.

Rgds.
Heiko.

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From olivierp at actimage.fr  Wed Apr 24 02:28:42 2002
From: olivierp at actimage.fr (Olivier PIERRAT)
Date: Wed, 24 Apr 2002 08:28:42 +0200
Subject: [uClinux-dev] counter based on jiffies
Message-ID: <3CC6509A.1000100@actimage.fr>

Hi,

I read in a book about Linux programming, that there is timer or 
counter, based on jiffies, and a HZ variable. The HZ varaible is a 
variable which represents ticks of the kernel. Jiffies is increment 
every time a ticks is done.

I read there is two way to use the jiffies :

1. use directly the jiffies variables : jiffies + timeout, a structure 
timer_list to define the timer based on the jiffies and some functions 
like init_timer(), add_timer() ....

2. But there is macro time_before(), time_after(), and functions 
mod_timer(), timer_pending() to manage the timer. I use a kernel 2.0.39 
and I can not compile and link properly when I use these function in my 
programm that I compile in the kernel. I find these functions but it 
seems they depend on the uClinux version, is it right ? Can I use these 
functions with the kernel 2.0.39 ?  Which option should I add to the 
compile or link process to use them ?

CAn I use these timers based on the jiffies in an user application ?

Thank you for your answers.

Olivier.

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From kuochung at mail.iaa.ncku.edu.tw  Wed Apr 24 02:57:30 2002
From: kuochung at mail.iaa.ncku.edu.tw (=?big5?B?tsCw6rZ2?=)
Date: Wed, 24 Apr 2002 14:57:30 +0800
Subject: [uClinux-dev] problem for pppd on uClinux....help!!!
Message-ID: <001401c1eb5d$4dd69940$70c9748c@pc2>

Hey all!!!

I have complied a pppd binary file with arm-elf complier 
I want to run for my uClinux
and I also had done the ppp-on ,ppp-off script.
There is a error when i run pppd on borad with uClinux:

warning:can't open option file /root/.ppprc :Invalid argument
warning:can't open option file /etc/ppp/options.ttyS0: Invalid argument
./pppd :couldn't determain if PPP is supported (no free ptys)

What can I do ??
If there are other files or config  settings I shuold change ????

                                            Kuo



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20020424/f194b6e3/attachment.html>

From kuochung at mail.iaa.ncku.edu.tw  Wed Apr 24 02:58:46 2002
From: kuochung at mail.iaa.ncku.edu.tw (=?big5?B?tsCw6rZ2?=)
Date: Wed, 24 Apr 2002 14:58:46 +0800
Subject: [uClinux-dev] problem for pppd on uClinux....help!!!
Message-ID: <002101c1eb5d$7b510e00$70c9748c@pc2>

Hey all!!!

I have complied a pppd binary file with arm-elf complier 
I want to run for my uClinux
and I also had done the ppp-on ,ppp-off script.
There is a error when i run pppd on borad with uClinux:

warning:can't open option file /root/.ppprc :Invalid argument
warning:can't open option file /etc/ppp/options.ttyS0: Invalid argument
./pppd :couldn't determain if PPP is supported (no free ptys)

What can I do ??
If there are other files or config  settings I shuold change ????

                                            Kuo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20020424/c1e2256f/attachment.html>

From gerg at snapgear.com  Wed Apr 24 03:04:00 2002
From: gerg at snapgear.com (Greg Ungerer)
Date: Wed, 24 Apr 2002 17:04:00 +1000
Subject: [uClinux-dev] BDM and GDB with 5272
References: <5.1.0.14.1.20020424132601.00a95300@localhost>
Message-ID: <3CC658E0.6060802@snapgear.com>


Hi Peter,

Peter Ogilvy wrote:
> We're having trouble connecting with our snapgear LITE card
> using GDB and the BDM interface. We use a P&E cable.
> 
> What versions of GDB and which BDM patches/drivers are people applying.

I use gdb-5.0 with Chris John's BDM driver version 20010415.
I use it with the SnapGear lites all the time.

What is the nature of the problem you are having?

Regards
Greg



> I've had a search on the web and found Pavel Pisa's detailed page,
> also the www.cybertec.com.au driver, amoung others, but I'm unsure
> which is best suited to my needs.
> 
> We are buidling 2.4 kernals on a Mandrake 8.0 host.
> 
> Peter
> 
> This message resent by the uclinux-dev at uclinux.org list server 
> http://www.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

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From gerg at snapgear.com  Wed Apr 24 03:06:01 2002
From: gerg at snapgear.com (Greg Ungerer)
Date: Wed, 24 Apr 2002 17:06:01 +1000
Subject: [uClinux-dev] 2.4.x Compile error
References: <F144Y4kJSFsxf4yp8AR00000b2d@hotmail.com>
Message-ID: <3CC65959.4010404@snapgear.com>

Hi Xu,

Xu Fantom wrote:
> I download uClinux-dist-20020306.tar.gz from www.uclinux.org.
> when i compile the kernel, (with some applications selected, such as 
> mount, ping ...)it reports lot of errors, just like this:

Lots of errors :-)
The "mount" source in the distribution only works on 2.0.x
kernels. If you want NFS support on a 2.4.x kernel then use
the busybox mount (and don't forget that you will need
portmap as well under 2.4.x).

Regards
Greg




> m68k-elf-gcc -m5307 -DCONFIG_COLDFIRE -Os -g -fomit-frame-pointer  
> -Dlinux -D__linux__ -Dunix -D__uClinux__ -DEMBED 
> -I/0306/uClinux-dist/lib/libc/include -I/0306/uClinux-dist/lib/libm 
> -I/0306/uClinux-dist -fno-builtin -msep-data 
> -I/0306/uClinux-dist/linux-2.4.x/include -DHAVE_NFS   -c -o nfsmount.o 
> nfsmount.c
> In file included from nfs_mount3.h:15,
>                 from nfsmount.c:51:
> /0306/uClinux-dist/lib/libc/include/linux/nfs_mount.h:46: field `root' 
> has incomplete type
> make[2]: *** [nfsmount.o] Error 1
> make[2]: Leaving directory `/0306/uClinux-dist/user/mount'
> make[1]: *** [all] Error 2
> make[1]: Leaving directory `/0306/uClinux-dist/user'
> make: *** [subdirs] Error 1
> 
> I wonder if these source code has not been tested before distribution or 
> I do something wrong? 
> If I compile the kernel without changing the settings, everything is OK.
> 
> _________________________________________________________________
> ???????? Web ?????? ? MSN Hotmail?http://www.hotmail.com/cn
> 
> This message resent by the uclinux-dev at uclinux.org list server 
> http://www.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

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From gmenie at akamai.com  Wed Apr 24 04:08:03 2002
From: gmenie at akamai.com (Menie, Georges)
Date: Wed, 24 Apr 2002 04:08:03 -0400
Subject: [uClinux-dev] Time setup
Message-ID: <D447D880267ED5118F2A00D0B74A108B08E634@munich-ex1.munich.akamai.com>

Hi Kendrick,

> In the function config_BSP, there are the following function pointers
> which get initialized:
> 	mach_set_clock_mmss
set the hardware clock device time from the kernel time,
seems not to be called, deprecated ?
NULL is ok

> 	mach_hwclk
set or get the hardware clock device time. same remark,
but may be usefull with a hwclk module ?
NULL is ok

> 	mach_gettod
called at init to initialize the kernel time.
NULL is ok, time will start at 0

> 	mach_gettimeoffset
called by the kernel to update its time when
a process called the gettimeofday syscall, this
function returns a ?s offset since the last tick.
NULL is ok, the time resolution is 1 tick

> 	mach_mksound
generate a sound ??
NULL is ok,

> 	mach_reset
called by the kernel as the last step before reboot
NULL is probably ok, but I don't know what does the kernel
in this case.

> What are these functions suppossed to to and what happens if they are
> NULL?
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From petero at cvs.com.au  Wed Apr 24 04:09:19 2002
From: petero at cvs.com.au (Peter Ogilvy)
Date: Wed, 24 Apr 2002 18:09:19 +1000
Subject: [uClinux-dev] BDM and GDB with 5272
In-Reply-To: <3CC658E0.6060802@snapgear.com>
References: <5.1.0.14.1.20020424132601.00a95300@localhost>
Message-ID: <5.1.0.14.1.20020424180141.00a84c08@localhost>

Thanks to all who replied.

We found the problem, it was a missing jumper on the
board which enables the GDB port.

Greg Ungerer wrote:

>Hi Peter,
>
>Peter Ogilvy wrote:
>>We're having trouble connecting with our snapgear LITE card
>>using GDB and the BDM interface. We use a P&E cable.
>>What versions of GDB and which BDM patches/drivers are people applying.
>
>I use gdb-5.0 with Chris John's BDM driver version 20010415.
>I use it with the SnapGear lites all the time.

Thanks, Are these part of the Coldfire toolchain on the uClinux
site or do I have to install them also?

>What is the nature of the problem you are having?

We couldnt talk to the baord via the debug port under windows
and we wanted to get the Linux tools up as a second test. The
windows stuff now works with the jumper added.

Pauli from snapgear suggested he uses the ones on the uClinux
site by I couldnt find seperate stuff, so I assume it must be
part of the toolchain. Is this so?

Thank for your help,

Peter

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From fmore at netceler.com  Wed Apr 24 03:48:58 2002
From: fmore at netceler.com (Fabien)
Date: Wed, 24 Apr 2002 09:48:58 +0200
Subject: [uClinux-dev] newbie : java on uClinux
Message-ID: <3CC6636A.8010405@netceler.com>

hi all,

    I'm new in uClinux, I'm french, then ascuse me in avance for the 
anglish mistakes.
I used the uCdimm ColdFire 5275 whith the uCevolution dev bord.


Is somebody already run java with uClinux.?
I try to build kaffe but there are a lots of error and there are a lots 
of Makefile.


This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From miles at lsi.nec.co.jp  Wed Apr 24 05:13:32 2002
From: miles at lsi.nec.co.jp (Miles Bader)
Date: 24 Apr 2002 18:13:32 +0900
Subject: [uClinux-dev] new shared library implementation trashage?
Message-ID: <buor8l5jw77.fsf@mcspd15.ucom.lsi.nec.co.jp>

I've been having problems getting the new source snapshot to work on the
v850 -- the text segments of programs are getting bogus values written
into them.

I notice the following in fs/binfmt_flat.c:

	/* Update data segment pointers for all libraries */
	for (i=0; i<MAX_SHARED_LIBS; i++)
		if (libinfo.lib_list[i].loaded)
			for (j=0; j<MAX_SHARED_LIBS; j++)
				(-(j+1))[(unsigned long *)(libinfo.lib_list[i].start_data)] =
					(libinfo.lib_list[j].loaded)?
						libinfo.lib_list[j].start_data:UNLOADED_LIB;

I don't understand at all what it's trying to do, and I thought at first
that it wouldn't affect me, as the v850 doesn't have any kind of shared
library support.  However, I notice now that the executable file is
apparently considered `shared library number 0'.

That said, what on earth is happening here?  It appears as if this is
going to simply go and trash some memory before the start of the data
segment (which in my case, is the text segment).  Is this true?  Should
I have somehow updated the way I build flat files?  Was this announced
somewhere?

Thanks for any help,

-Miles
-- 
.Numeric stability is probably not all that important when you're guessing.
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From mark.howson at ntu.ac.uk  Wed Apr 24 05:24:44 2002
From: mark.howson at ntu.ac.uk (Howson, Mark)
Date: Wed, 24 Apr 2002 10:24:44 +0100
Subject: [uClinux-dev] newbie : java on uClinux
Message-ID: <579C0CAF497CD511AD4D00508BBD7AAC0246EF@pikachu.ntu.ac.uk>


Fabien wrote:
> I'm new in uClinux, I'm french, then ascuse me in avance for the 
> anglish mistakes.
> I used the uCdimm ColdFire 5275 whith the uCevolution dev bord.
>  
> Is somebody already run java with uClinux.?
> I try to build kaffe but there are a lots of error and there 
> are a lots of Makefile.

I've been using waba ( http://waba.sourceforge.net ), which seems to work
quite nicely under uCLinux.

Mark
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From hans.carlsson at intellicom.se  Wed Apr 24 06:07:50 2002
From: hans.carlsson at intellicom.se (Hans Carlsson)
Date: Wed, 24 Apr 2002 12:07:50 +0200
Subject: SV: [uClinux-dev] problem for pppd on uClinux....help!!!
Message-ID: <BC03D160581F7A4E92710FC238282411024F3E@ici-mail.intellicom.se>

Hi!

If you don't supply any inparameters to pppd in your ppp-on script then
pppd will look for the files you get warnings for to read options from.
So you can either make these files or supply options on "command line"
in ppp-on. You very likely will need a ppp-on-dialer script as well.
See http://www.tldp.org/HOWTO/PPP-HOWTO/index.html for more details.
This is linux doc source not uClinux.

You also need to compile the kernel to support pppd.

Hans


-----Ursprungligt meddelande-----
Fran: kuochung at mail.iaa.ncku.edu.tw
[mailto:kuochung at mail.iaa.ncku.edu.tw]
Skickat: den 24 april 2002 08:58
Till: uclinux-dev at uclinux.org
Amne: [uClinux-dev] problem for pppd on uClinux....help!!!


Hey all!!!

I have complied a pppd binary file with arm-elf complier 
I want to run for my uClinux
and I also had done the ppp-on ,ppp-off script.
There is a error when i run pppd on borad with uClinux:

warning:can't open option file /root/.ppprc :Invalid argument
warning:can't open option file /etc/ppp/options.ttyS0: Invalid argument
./pppd :couldn't determain if PPP is supported (no free ptys)

What can I do ??
If there are other files or config  settings I shuold change ????

                                            Kuo
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From leighf at iprimus.com.au  Wed Apr 24 07:33:11 2002
From: leighf at iprimus.com.au (Leigh Fiddes)
Date: Wed, 24 Apr 2002 21:33:11 +1000
Subject: [uClinux-dev]
In-Reply-To: <20020423095704.C5844@beast.internal.moreton.com.au>
References: <200204220731.g3M7VEe07702@uclinux.org> <20020423095704.C5844@beast.internal.moreton.com.au>
Message-ID: <200204241130.g3OBUwv28501@mail022.syd.optusnet.com.au>

On Tue, 23 Apr 2002 09:57, you wrote:
> Jivin mathias.fritzson at mecel.se lays it down ...
>
> > >Jivin mathias.fritzson at mecel.se lays it down ...
> > >
> > >> Hello again,
> > >>
> > >> Thanks for the latest tip David, the -m68000 flag worked..
> > >
> > >Ok,  but if you are using a 683XX,  is there an option specific for that
> > > ? Check your kernel compile and see what options (-m options) are used.
> >
> > The kernel uses the -mcpu32 flag, and that seems to work alright but when
> > I tried to use it for the apps and init I got the same error.
>
> Doesn't look good,  I've never targeted a cpu32 board,  anyone out there
> used the compiler on CPU32 stuff successfully ?
>
> Cheers,
> Davidm

I am using 68360 and had this problem some time ago. If I remember correctly 
I eventually isolated it to the following GCC behaviour:
1)First part of GCC produces some type of intermediate code which includes a 
pseudo-instruction JBRA for jumps. I expect the intention is to convert this 
to a BRA instruction if possible (so no relocation needed) or a JMP if not 
possible.
2) Code generator part of GCC (when -mcpu32 specified) knows that CPU32 has 
32-bit branch and so substitites BRA for JBRA. (Note: Not BRA.S or BRA.L)
3) Assembler assumes BRA is an alias for BRA.S for all 68K CPU types, and so 
produces 16-bit offset instruction.
4) If the target of the BRA is more than +/- 32768 then the branch is out of 
range and produces the "relocation truncated to fit: R_68K_PLT16" errors.

It is possible to patch GCC to always produce BRA.L but I ended up just using 
-m68000 instead.

Leigh Fiddes
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From mathias.fritzson at mecel.se  Wed Apr 24 08:35:08 2002
From: mathias.fritzson at mecel.se (mathias.fritzson at mecel.se)
Date: Wed, 24 Apr 2002 14:35:08 +0200
Subject: [uClinux-dev]
Message-ID: <200204241233.g3OCXws27577@uclinux.org>



Leigh Fiddes wrote:
>On Tue, 23 Apr 2002 09:57, you wrote:
>> Jivin mathias.fritzson at mecel.se lays it down ...
>>
>> > >Jivin mathias.fritzson at mecel.se lays it down ...
>> > >
>> > >> Hello again,
>> > >>
>> > >> Thanks for the latest tip David, the -m68000 flag worked..
>> > >
>> > >Ok,  but if you are using a 683XX,  is there an option specific for
that
>> > > ? Check your kernel compile and see what options (-m options) are
used.
>> >
>> > The kernel uses the -mcpu32 flag, and that seems to work alright but
when
>> > I tried to use it for the apps and init I got the same error.
>>
>> Doesn't look good,  I've never targeted a cpu32 board,  anyone out there
>> used the compiler on CPU32 stuff successfully ?
>>
>> Cheers,
>> Davidm
>
>I am using 68360 and had this problem some time ago. If I remember
correctly
>I eventually isolated it to the following GCC behaviour:
>1)First part of GCC produces some type of intermediate code which includes
a
>pseudo-instruction JBRA for jumps. I expect the intention is to convert
this
>to a BRA instruction if possible (so no relocation needed) or a JMP if not
>possible.
>2) Code generator part of GCC (when -mcpu32 specified) knows that CPU32
has
>32-bit branch and so substitites BRA for JBRA. (Note: Not BRA.S or BRA.L)
>3) Assembler assumes BRA is an alias for BRA.S for all 68K CPU types, and
so
>produces 16-bit offset instruction.
>4) If the target of the BRA is more than +/- 32768 then the branch is out
of
>range and produces the "relocation truncated to fit: R_68K_PLT16" errors.
>
>It is possible to patch GCC to always produce BRA.L but I ended up just
using
>-m68000 instead.
>

Thanks for the info (it seemed like the -mcpu32 flag was new and possibly
not
entirely finished throuhout the toolchain), just a question, is it safe to
use
the -mcpu32 for the kernel? (It seems to be an OK executable (ELF), the
libs
seems ok too) or should we stick to -m68000 for all compilations?

Btw can anyone point me a direction for a document on the subject of tasks,
how
 they are created and executed ?? It seems like the current struct (as is
current_set on the 68k arch) is filled op with bogus..

And as a final Q our kernel stack grows out of proportions, the 4k reserved
isn't enough at all, it ends up over 32k large.. Any ideas ??

Cheers

/Mathias


This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From siddons at bnl.gov  Wed Apr 24 08:36:31 2002
From: siddons at bnl.gov (D. Peter Siddons)
Date: Wed, 24 Apr 2002 08:36:31 -0400
Subject: [uClinux-dev] malloc() dump for 16M RAM on uClinux-2.0.38
References: <003501c1eb27$7e8f3190$2f64a8c0@rdcenter.com>
Message-ID: <3CC6A6CF.75F6DD96@bnl.gov>

Aaven,
I didn't check, but I suspect you need to change the chip-select
configuration to reflect the new hardware.
Pete.


lvjianguo wrote:
> 
> I using the uClinux 2.0.38pre10 on ucdimm, I soldered a 16M RAM chip
> instead of the old one (8M), then modified the rom.ld file
> (linux/arch/m68knommu/platform/68VZ328/ucdimm/):
> 
>     MEMORY
>         {
>             ...            // Flash address
>             ramvec : ORIGIN = 0x00000000, LENGTH = 1024
>             ram : ORIGIN = 0x00020000, LENGTH = 0x01000000 - 0x20000
>             eram : ORIGIN = 0x01000000, LENGTH = 1
>         }
> 
> following I rebuild the kernel and writing a simple application to
> test the memory:
> 
>     int main(void)
>     {
>         ...
>         buf = malloc(0x600000);        // 6M
>         if (buf == NULL) {
>             printf("allocate memory failed\n");
>             fflush(stdout);
>             return (-1);
>         }
> 
>         printf("allocate memory OK\n");
>         free(buf);
>         return (0);
>     }
> 
> the system is dead when calling the malloc(). I must be reset the
> ucdimm board. If I changed the size to 0x400000 (4M), It's nothing to
> be happened, allocate memory OK. then I resume the rom.ld:
> 
>     MEMORY
>         {
>             ...            // Flash address
>             ramvec : ORIGIN = 0x00000000, LENGTH = 1024
>             ram : ORIGIN = 0x00020000, LENGTH = 0x00800000 - 0x20000
>             eram : ORIGIN = 0x00800000, LENGTH = 1
>         }
> 
> It's OK! If I try to allcoate 6M memory buffer, the malloc() print
> some error information and return NULL.
> 
> I add some printk() in kernel and record some information when booting
> the kernel:
> 
> memory_start: 8ef30
> memory_end: ffc000
> start_mem: 8ef30
> virtual_end: ffc000
> the memory page and page size is OK!
> 
> Why?
> Thanks for your help!
> 
> Regards,
> Aavan

-- 
-----------------
D. Peter Siddons
National Synchrotron Light Source, Bldg. 725D
Brookhaven National Laboratory
Upton
New York 11973
Email: siddons at bnl.gov
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From kuochung at mail.iaa.ncku.edu.tw  Wed Apr 24 08:41:33 2002
From: kuochung at mail.iaa.ncku.edu.tw (=?big5?B?tsCw6rZ2?=)
Date: Wed, 24 Apr 2002 20:41:33 +0800
Subject: [uClinux-dev] problem for pppd on uClinux....help!!!
References: <BC03D160581F7A4E92710FC238282411024F3E@ici-mail.intellicom.se>
Message-ID: <004401c1eb8d$5e3e45a0$70c9748c@pc2>

Hi !! Carlsson
I had 
pppd /dev/ttyS1 57600 crstcs modem lock netmask 255.255.255.0
 in my ppp-on script and I have succeed PPP-dialup on linux.
If i only excute pppd,I will receive the message like these on linux 
{{$#{%}{{}*}{{ 
But i don't receive such these message on my borad on uClinux.
only

warning:can't open option file /root/.ppprc :Invalid argument
warning:can't open option file /etc/ppp/options.ttyS0: Invalid argument
./pppd :couldn't determain if PPP is supported (no free ptys)

So,did i miss something to do or what else???????
my uClinux kernal support PPP-2.3.8


----- Original Message ----- 
From: "Hans Carlsson" <hans.carlsson at intellicom.se>
To: <uclinux-dev at uclinux.org>
Sent: Wednesday, April 24, 2002 6:07 PM
Subject: SV: [uClinux-dev] problem for pppd on uClinux....help!!!


> Hi!
> 
> If you don't supply any inparameters to pppd in your ppp-on script then
> pppd will look for the files you get warnings for to read options from.
> So you can either make these files or supply options on "command line"
> in ppp-on. You very likely will need a ppp-on-dialer script as well.
> See http://www.tldp.org/HOWTO/PPP-HOWTO/index.html for more details.
> This is linux doc source not uClinux.
> 
> You also need to compile the kernel to support pppd.
> 
> Hans
> 
> 


This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From fmore at netceler.com  Wed Apr 24 09:20:48 2002
From: fmore at netceler.com (Fabien More)
Date: Wed, 24 Apr 2002 15:20:48 +0200
Subject: [uClinux-dev] newbie : java on uClinux
References: <579C0CAF497CD511AD4D00508BBD7AAC0246EF@pikachu.ntu.ac.uk>
Message-ID: <3CC6B130.5090204@netceler.com>

thanks you  for your replie.
i have download waba and i try to compile it.
The README.uClinux talk about m68k-coff-gcc !! i d'ont have this 
compiler, for my processor, I use m68k-elf-gcc. I try to configure with 
the command line :
       ./configure --target=m68k --with-prefix=m68k-elf --with-nogui
and there is this error:
*********************************
....
   checking host system type... i686-pc-linux-gnu
   checking for gcc... m68k-elf-gcc
   checking whether the C compiler (m68k-elf-gcc  ) works... no
   configure: error: installation or configuration problem: C compiler 
cannot create executables.

**********************************
I dont know what is this error. With a simple c file, the compiler 
m68k-elf-gcc works nicely!!


Howson, Mark wrote:

> Fabien wrote:
> 
>> I'm new in uClinux, I'm french, then ascuse me in avance for the 
>> anglish mistakes.
>> I used the uCdimm ColdFire 5275 whith the uCevolution dev bord.
>>  
>> Is somebody already run java with uClinux.?
>> I try to build kaffe but there are a lots of error and there 
>> are a lots of Makefile.
> 
> I've been using waba ( http://waba.sourceforge.net ), which seems to work
> quite nicely under uCLinux.
> 
> Mark
> This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/
> 
> 

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From olivierp at actimage.fr  Wed Apr 24 09:19:53 2002
From: olivierp at actimage.fr (Olivier PIERRAT)
Date: Wed, 24 Apr 2002 15:19:53 +0200
Subject: [uClinux-dev] problem to wake up a thread in the kernel
Message-ID: <3CC6B0F9.9050108@actimage.fr>

Hi,

I work on a M5272C3 evaluation board, with the uClinux kernel 2.0.39.1.

I launch a kernel thread at the boot time in the uClinux kernel. I do 
that just after the kswapd kernel's thread was launched at in the init 
kernel thread.

I set the priority of my threar to 20 !!! The kswap's thread priority 
was set to 32.

My thread (for test) initialise a timer (object of type timer_list) with 
a 10s values and the thread enter in sleep mode. In the timer handler 
the processing should wake up, but nthing happen ? Does someone have an 
idea ?

The launch phasis for the thread is (~/linux/init/main.c ==> in the 
init() function) :

....

         kernel_thread(my_thread, NULL, 0);

and I defined the behaviour of my thread in my_thread.c :

static struct timer_list Timer10s;

static struct wait_queue *my_thread_wait = NULL;

void  PerformTimer10s(unsigned long donnees)
{
    wake_up(&my_thread_wait);
    Timer10s.expires = jiffies + (HZ * 1000);   // reset du timer
    add_timer(&Timer10s);
}


int  my_thread(void * unused)
{


    // Initialize the thread behaviour
    current->session = 1;
    current->pgrp = 1;
    sprintf(current->comm,"%s", "my_thread");
    current->blocked = ~0UL;

    current->policy = SCHED_FIFO;
    current->priority = 20;


    init_timer(&Timer10s);
    Timer10s.expires = jiffies + (HZ * 1000);
    Timer10s.function=&PerformTimer10s;
    add_timer(&Timer10s);


    while (1)
    {
       printk("thread wake up !!!\n");	
       interruptible_sleep_on(&my_thread_wait);
    }

    return 0;
}


What is wrong ? Nothing happened, my thread never wake up ? Every time I 
perform a "ps -ax" command the thread is present but in sleep mode ?????

Thank you for your answer.

Olivier.

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From hans.carlsson at intellicom.se  Wed Apr 24 10:11:35 2002
From: hans.carlsson at intellicom.se (Hans Carlsson)
Date: Wed, 24 Apr 2002 16:11:35 +0200
Subject: SV: [uClinux-dev] problem for pppd on uClinux....help!!!
Message-ID: <BC03D160581F7A4E92710FC238282411024F41@ici-mail.intellicom.se>

Hi again!

Im' not sure but maybe pppd doesn't have all the configuration it need
to run. 
Then the .ppprc file maybe the last place to look for (user)options.

I have 
exec /home/ppp/pppd debug lock modem crtscts /dev/ttyS0 115200 \
   asyncmap 20A0000 escape FF kdebug 4 $LOCAL_IP:$REMOTE_IP \
	noipdefault netmask $NETMASK defaultroute usepeerdns \
	connect $DIALER_SCRIPT

in my ppp-on.

It is pretty hard get a print out but check syslog.
Good luck.

Hans


> -----Ursprungligt meddelande-----
> Fran: kuochung at mail.iaa.ncku.edu.tw 
> [mailto:kuochung at mail.iaa.ncku.edu.tw]
> Skickat: den 24 april 2002 14:42
> Till: uclinux-dev at uclinux.org
> Amne: Re: [uClinux-dev] problem for pppd on uClinux....help!!!
> 
> 
> Hi !! Carlsson
> I had 
> pppd /dev/ttyS1 57600 crstcs modem lock netmask 255.255.255.0
>  in my ppp-on script and I have succeed PPP-dialup on linux.
> If i only excute pppd,I will receive the message like these on linux 
> {{$#{%}{{}*}{{ 
> But i don't receive such these message on my borad on uClinux.
> only
> 
> warning:can't open option file /root/.ppprc :Invalid argument
> warning:can't open option file /etc/ppp/options.ttyS0: 
> Invalid argument
> ./pppd :couldn't determain if PPP is supported (no free ptys)
> 
> So,did i miss something to do or what else???????
> my uClinux kernal support PPP-2.3.8
> 
> 
> ----- Original Message ----- 
> From: "Hans Carlsson" <hans.carlsson at intellicom.se>
> To: <uclinux-dev at uclinux.org>
> Sent: Wednesday, April 24, 2002 6:07 PM
> Subject: SV: [uClinux-dev] problem for pppd on uClinux....help!!!
> 
> 
> > Hi!
> > 
> > If you don't supply any inparameters to pppd in your ppp-on 
> script then
> > pppd will look for the files you get warnings for to read 
> options from.
> > So you can either make these files or supply options on 
> "command line"
> > in ppp-on. You very likely will need a ppp-on-dialer script as well.
> > See http://www.tldp.org/HOWTO/PPP-HOWTO/index.html for more details.
> > This is linux doc source not uClinux.
> > 
> > You also need to compile the kernel to support pppd.
> > 
> > Hans
> > 
> > 
> 
> 
> This message resent by the uclinux-dev at uclinux.org list 
> server http://www.uClinux.org/
> 
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From gerg at snapgear.com  Wed Apr 24 10:16:48 2002
From: gerg at snapgear.com (gerg)
Date: Thu, 25 Apr 2002 00:16:48 +1000
Subject: [uClinux-dev] problem to wake up a thread in the kernel
References: <3CC6B0F9.9050108@actimage.fr>
Message-ID: <3CC6BE50.2526EC6D@snapgear.com>


Hi Olivier,

Olivier PIERRAT wrote:
> I work on a M5272C3 evaluation board, with the uClinux kernel 2.0.39.1.
> 
[snip]
> void  PerformTimer10s(unsigned long donnees)
> {
>     wake_up(&my_thread_wait);
>     Timer10s.expires = jiffies + (HZ * 1000);   // reset du timer
                                   ^^^^^^^^^^^
This is 1000 seconds!

HZ is the number of jiffies in 1 second. For 10s you want
(HZ * 10) here.

Regards
Greg



------------------------------------------------------------------------
Greg Ungerer  --  Chief Software Wizard        EMAIL:  gerg at snapgear.com
Snapgear                                       PHONE:    +61 7 3279 1822
825 Stanley St,                                  FAX:    +61 7 3279 1820
Woolloongabba, QLD, 4102, Australia              WEB:   www.snapgear.com
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From gerg at snapgear.com  Wed Apr 24 10:23:50 2002
From: gerg at snapgear.com (gerg)
Date: Thu, 25 Apr 2002 00:23:50 +1000
Subject: [uClinux-dev] BDM and GDB with 5272
References: <5.1.0.14.1.20020424132601.00a95300@localhost> <5.1.0.14.1.20020424180141.00a84c08@localhost>
Message-ID: <3CC6BFF6.97EBE718@snapgear.com>


Hi Peter,

Peter Ogilvy wrote:
> Greg Ungerer wrote:
> >I use gdb-5.0 with Chris John's BDM driver version 20010415.
> >I use it with the SnapGear lites all the time.
> 
> Thanks, Are these part of the Coldfire toolchain on the uClinux
> site or do I have to install them also?

The patched gdb has been in the past, but I don't think it
is currently included.


> >What is the nature of the problem you are having?
> 
> We couldnt talk to the baord via the debug port under windows
> and we wanted to get the Linux tools up as a second test. The
> windows stuff now works with the jumper added.
> 
> Pauli from snapgear suggested he uses the ones on the uClinux
> site by I couldnt find seperate stuff, so I assume it must be
> part of the toolchain. Is this so?

I could be wrong but I don't think the binaries or source
are currently on uClinux.

It is not too dificult to get Chris John's latest Linux
BDM driver and the gdb source and build everything you need.
Goto www.cybertec.com.au and get the BDM driver package,
then get the gdb source from www.gnu.org. Follow the
build instructions in the BDM driver package.

Regards
Greg


------------------------------------------------------------------------
Greg Ungerer  --  Chief Software Wizard        EMAIL:  gerg at snapgear.com
Snapgear                                       PHONE:    +61 7 3279 1822
825 Stanley St,                                  FAX:    +61 7 3279 1820
Woolloongabba, QLD, 4102, Australia              WEB:   www.snapgear.com
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From gerg at snapgear.com  Wed Apr 24 10:26:57 2002
From: gerg at snapgear.com (gerg)
Date: Thu, 25 Apr 2002 00:26:57 +1000
Subject: [uClinux-dev] BDM and GDB with 5272
References: <5.1.0.14.1.20020424132601.00a95300@localhost> <5.1.0.14.1.20020424180141.00a84c08@localhost> <3CC6BFF6.97EBE718@snapgear.com>
Message-ID: <3CC6C0B1.8F35D4F9@snapgear.com>


Hi Peter,

I just checked the latest m68k-elf-tools on uclinux.org,
and it does include the m68k-bdm-elf-gdb. So all you need
is Chris John's Linux BDM driver to get it going.

Regards
Greg




gerg wrote:
> 
> Hi Peter,
> 
> Peter Ogilvy wrote:
> > Greg Ungerer wrote:
> > >I use gdb-5.0 with Chris John's BDM driver version 20010415.
> > >I use it with the SnapGear lites all the time.
> >
> > Thanks, Are these part of the Coldfire toolchain on the uClinux
> > site or do I have to install them also?
> 
> The patched gdb has been in the past, but I don't think it
> is currently included.
> 
> > >What is the nature of the problem you are having?
> >
> > We couldnt talk to the baord via the debug port under windows
> > and we wanted to get the Linux tools up as a second test. The
> > windows stuff now works with the jumper added.
> >
> > Pauli from snapgear suggested he uses the ones on the uClinux
> > site by I couldnt find seperate stuff, so I assume it must be
> > part of the toolchain. Is this so?
> 
> I could be wrong but I don't think the binaries or source
> are currently on uClinux.
> 
> It is not too dificult to get Chris John's latest Linux
> BDM driver and the gdb source and build everything you need.
> Goto www.cybertec.com.au and get the BDM driver package,
> then get the gdb source from www.gnu.org. Follow the
> build instructions in the BDM driver package.
> 
> Regards
> Greg
> 
> ------------------------------------------------------------------------
> Greg Ungerer  --  Chief Software Wizard        EMAIL:  gerg at snapgear.com
> Snapgear                                       PHONE:    +61 7 3279 1822
> 825 Stanley St,                                  FAX:    +61 7 3279 1820
> Woolloongabba, QLD, 4102, Australia              WEB:   www.snapgear.com

-- 
------------------------------------------------------------------------
Greg Ungerer  --  Chief Software Wizard        EMAIL:  gerg at snapgear.com
Snapgear                                       PHONE:    +61 7 3279 1822
825 Stanley St,                                  FAX:    +61 7 3279 1820
Woolloongabba, QLD, 4102, Australia              WEB:   www.snapgear.com
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From eauth at softsys.co.at  Wed Apr 24 10:36:32 2002
From: eauth at softsys.co.at (Erwin Authried)
Date: Wed, 24 Apr 2002 16:36:32 +0200
Subject: [uClinux-dev] newbie : java on uClinux
Message-ID: <01C1EBAE.348BD260@smithwicks.softsys.co.at>

Fabien More[SMTP:fmore at netceler.com] wrote:
> thanks you  for your replie.
> i have download waba and i try to compile it.
> The README.uClinux talk about m68k-coff-gcc !! i d'ont have this 
> compiler, for my processor, I use m68k-elf-gcc. I try to configure with 
> the command line :
>        ./configure --target=m68k --with-prefix=m68k-elf --with-nogui
> and there is this error:
> *********************************
> ...
>    checking host system type... i686-pc-linux-gnu
>    checking for gcc... m68k-elf-gcc
>    checking whether the C compiler (m68k-elf-gcc  ) works... no
>    configure: error: installation or configuration problem: C compiler 
> cannot create executables.
> 
> **********************************
> I dont know what is this error. With a simple c file, the compiler 
> m68k-elf-gcc works nicely!!
> 

For cross compilation, you may have to set up a few environment variables,
like PATH, CFLAGS, LDFLAGS. Take a look into the logfile that is created
by configure, it should give detailed error messages. When configure
is doing tests that require running a test program, the cross configuration
may fail too. In such cases, it may help to to manually edit config.cache
to skip such tests.

-Erwin

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From sujz at cad.csie.ncku.edu.tw  Wed Apr 24 10:37:31 2002
From: sujz at cad.csie.ncku.edu.tw (SuCC)
Date: Wed, 24 Apr 2002 22:37:31 +0800
Subject: [uClinux-dev] problem for pppd on uClinux....help!!!
References: <BC03D160581F7A4E92710FC238282411024F3E@ici-mail.intellicom.se> <004401c1eb8d$5e3e45a0$70c9748c@pc2>
Message-ID: <002901c1eb9d$96d63ca0$2df7748c@SCC>

I give you a suggestion from my experience!!
1.You can trace the code and take these check off.
   Because you just need "/etc/option" in embedded env.
2.You should add tty in your /dev of your embedded linux~~~

----- Original Message -----
From: "???" <kuochung at mail.iaa.ncku.edu.tw>
To: <uclinux-dev at uclinux.org>
Sent: Wednesday, April 24, 2002 8:41 PM
Subject: Re: [uClinux-dev] problem for pppd on uClinux....help!!!


> Hi !! Carlsson
> I had
> pppd /dev/ttyS1 57600 crstcs modem lock netmask 255.255.255.0
>  in my ppp-on script and I have succeed PPP-dialup on linux.
> If i only excute pppd,I will receive the message like these on linux
> {{$#{%}{{}*}{{
> But i don't receive such these message on my borad on uClinux.
> only
>
> warning:can't open option file /root/.ppprc :Invalid argument
> warning:can't open option file /etc/ppp/options.ttyS0: Invalid argument
> ./pppd :couldn't determain if PPP is supported (no free ptys)
>
> So,did i miss something to do or what else???????
> my uClinux kernal support PPP-2.3.8
>
>
> ----- Original Message -----
> From: "Hans Carlsson" <hans.carlsson at intellicom.se>
> To: <uclinux-dev at uclinux.org>
> Sent: Wednesday, April 24, 2002 6:07 PM
> Subject: SV: [uClinux-dev] problem for pppd on uClinux....help!!!
>
>
> > Hi!
> >
> > If you don't supply any inparameters to pppd in your ppp-on script then
> > pppd will look for the files you get warnings for to read options from.
> > So you can either make these files or supply options on "command line"
> > in ppp-on. You very likely will need a ppp-on-dialer script as well.
> > See http://www.tldp.org/HOWTO/PPP-HOWTO/index.html for more details.
> > This is linux doc source not uClinux.
> >
> > You also need to compile the kernel to support pppd.
> >
> > Hans
> >
> >
>
>
> This message resent by the uclinux-dev at uclinux.org list server
http://www.uClinux.org/
>
>


This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From mark.howson at ntu.ac.uk  Wed Apr 24 10:46:46 2002
From: mark.howson at ntu.ac.uk (Howson, Mark)
Date: Wed, 24 Apr 2002 15:46:46 +0100
Subject: [uClinux-dev] newbie : java on uClinux
Message-ID: <579C0CAF497CD511AD4D00508BBD7AAC0246F1@pikachu.ntu.ac.uk>

Fabien wrote:

> i have download waba and i try to compile it.
> The README.uClinux talk about m68k-coff-gcc !! i d'ont have this 
> compiler, for my processor, I use m68k-elf-gcc. I try to

That's okay.
 
> configure with 
> the command line :
>        ./configure --target=m68k --with-prefix=m68k-elf --with-nogui
> and there is this error:

>    checking for gcc... m68k-elf-gcc
>    checking whether the C compiler (m68k-elf-gcc  ) works... no
>    configure: error: installation or configuration problem: C compiler
>cannot create executables.
 
Have a look through the config.log file (it'll be in the same directory as
you ./configure'd in. That should point you to the problem (if not, post
your config.log here).

Mark
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From john at labxtechnologies.com  Wed Apr 24 11:30:16 2002
From: john at labxtechnologies.com (John Passaniti)
Date: Wed, 24 Apr 2002 11:30:16 -0400
Subject: [uClinux-dev] Licensing Linux/uClinux
In-Reply-To: <3CC6B130.5090204@netceler.com>
Message-ID: <JFEILOACCOGNNAPHIJECGEHLCFAA.john@labxtechnologies.com>

I'm interested in using uClinux in a closed-source embedded system, but I am
having a hard time finding simple, understandable, and authoritative
statements regarding licensing Linux in general (and uClinux in particular).
I get the general idea behind it.  And I've endlessly seen the idiomatic
buzz phrases that have grown up around Linux ("it's free as in freedom, not
free as in 'free beer!'").  It's all very cute and tedious but doesn't help
me much erase the fears and concerns of the company I'm working for.

My understanding is this:

1.  We can embed uClinux in our closed-source commercial embedded product.
Since we don't plan on making any changes to the operating system code, I
assume that we are not bound to turn the company's FTP server as another
uClinux distribution point.

2.  If for some odd reason we did find it necessary to modify the operating
system code, instead of providing patches against uClinux, we would be
required to provide the full patched source changes.  (This makes no sense
to me as patches plus freely available sources equals patched sources.  It
probably dates from the time when Stallman distributed code via 9-track tape
and Larry Wall's "patch" didn't exist.)

3.  We're also free to use newlib in much the same way as uClinux.

4.  Although we'll probably freely mention the product is "powered by
uClinux," there is no requirement to do so.

So is that it?  Has anyone attempted to use uClinux (or Linux in general)
and found some aspect of their product that caused cease and desist letters
to be received?  What I'm trying to do here is ensure that the company I'm
working for doesn't regret using uClinux because of a misunderstanding of
the licensing.

Is there some authoritative web site, FAQ, or other reliable source of
information that specifically deals with the licensing issues of embedding
uClinux (or Linux in general) into closed-source commercial products?


This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From kuochung at mail.iaa.ncku.edu.tw  Wed Apr 24 12:13:40 2002
From: kuochung at mail.iaa.ncku.edu.tw (=?big5?B?tsCw6rZ2?=)
Date: Thu, 25 Apr 2002 00:13:40 +0800
Subject: [uClinux-dev] problem for pppd on uClinux....help!!!
References: <BC03D160581F7A4E92710FC238282411024F3E@ici-mail.intellicom.se> <004401c1eb8d$5e3e45a0$70c9748c@pc2> <002901c1eb9d$96d63ca0$2df7748c@SCC>
Message-ID: <015401c1ebab$016166a0$70c9748c@pc2>

HI !!
>from your mail,the '/etc/option' ??
Is that the file named 'options' in ppp directory??
Or a file i should make myself to add  to /etc, if yes,what are the
'options' shall i make??
And,does tty mean ttyS0 ????

Regards
Kuo


> I give you a suggestion from my experience!!
> 1.You can trace the code and take these check off.
>    Because you just need "/etc/option" in embedded env.
> 2.You should add tty in your /dev of your embedded linux~~~
>


This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From olivierp at actimage.fr  Wed Apr 24 12:06:40 2002
From: olivierp at actimage.fr (Olivier PIERRAT)
Date: Wed, 24 Apr 2002 18:06:40 +0200
Subject: [uClinux-dev] problem to wake up a thread in the kernel
References: <3CC6B0F9.9050108@actimage.fr> <3CC6BE50.2526EC6D@snapgear.com>
Message-ID: <3CC6D810.8030000@actimage.fr>

Hi Greg,

Thank you, I have make a stupid mistake. I find it with the gdb.

In fact I have some problems and strange characters display in the boot 
message when I add some printk to debug the thread (eg, the priority, 
timer value, ...). Do you know what is the problem ? Is it possible to 
perform printk inside the thread without disturbing the kernel ?

Thank you for your help.

Olivier.

gerg wrote:

> Hi Olivier,
> 
> Olivier PIERRAT wrote:
> 
>> I work on a M5272C3 evaluation board, with the uClinux kernel 2.0.39.1.
>> 
> 
> [snip]
> 
>> void  PerformTimer10s(unsigned long donnees)
>> {
>>     wake_up(&my_thread_wait);
>>     Timer10s.expires = jiffies + (HZ * 1000);   // reset du timer
> 
>                                    ^^^^^^^^^^^
> This is 1000 seconds!
> 
> HZ is the number of jiffies in 1 second. For 10s you want
> (HZ * 10) here.
> 
> Regards
> Greg
> 
> 
> 
> ------------------------------------------------------------------------
> Greg Ungerer  --  Chief Software Wizard        EMAIL:  gerg at snapgear.com
> Snapgear                                       PHONE:    +61 7 3279 1822
> 825 Stanley St,                                  FAX:    +61 7 3279 1820
> Woolloongabba, QLD, 4102, Australia              WEB:   www.snapgear.com
> This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From chete at cnuninet.com  Wed Apr 24 12:25:09 2002
From: chete at cnuninet.com (Bug cheng)
Date: Thu, 25 Apr 2002 00:25:09 +0800
Subject: [uClinux-dev] newbie problem: how to download bootloader into the flash with the bdm
In-Reply-To: <3CC63BD6.E586A67@tele-ip.com>
Message-ID: <IIEJKNDGMGJEOBIKAGPAGEKPCAAA.chete@cnuninet.com>

HI all!
	I want to know to how to download the boot loader into the flash with bdm . I am using the 5272 processor.
Best wishes
 JIM chen.

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From chete at cnuninet.com  Wed Apr 24 12:25:38 2002
From: chete at cnuninet.com (Bug cheng)
Date: Thu, 25 Apr 2002 00:25:38 +0800
Subject: [uClinux-dev] newbie problem: how to download bootloader into the flash with the bdm
In-Reply-To: <3CC63BD6.E586A67@tele-ip.com>
Message-ID: <IIEJKNDGMGJEOBIKAGPAIEKPCAAA.chete@cnuninet.com>

HI all!
	I want to know to how to download the boot loader into the flash with bdm . I am using the 5272 processor.
Best wishes
 JIM chen.

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From rwehrli at azpower.com  Wed Apr 24 12:29:02 2002
From: rwehrli at azpower.com (Rob Wehrli)
Date: Wed, 24 Apr 2002 09:29:02 -0700
Subject: [uClinux-dev] Licensing Linux/uClinux
Message-ID: <01C1EB72.7A8DD880.rwehrli@azpower.com>

On Wednesday, April 24, 2002 8:30 AM, John Passaniti 
[SMTP:john at labxtechnologies.com] wrote:
> I'm interested in using uClinux in a closed-source embedded system, but I 
am
> having a hard time finding simple, understandable, and authoritative
> statements regarding licensing Linux in general (and uClinux in 
particular).
> I get the general idea behind it.  And I've endlessly seen the idiomatic
> buzz phrases that have grown up around Linux ("it's free as in freedom, 
not
> free as in 'free beer!'").  It's all very cute and tedious but doesn't 
help
> me much erase the fears and concerns of the company I'm working for.

The GPL wasn't written to erase your company's fears...in fact, I'd 
probably counter that the exact opposite is true...considering Stallman's 
"taste" for "proprietary software companies"... :)

>
> My understanding is this:
>
> 1.  We can embed uClinux in our closed-source commercial embedded 
product.
> Since we don't plan on making any changes to the operating system code, I
> assume that we are not bound to turn the company's FTP server as another
> uClinux distribution point.

True...as I understand it.

>
> 2.  If for some odd reason we did find it necessary to modify the 
operating
> system code, instead of providing patches against uClinux, we would be
> required to provide the full patched source changes.  (This makes no 
sense
> to me as patches plus freely available sources equals patched sources. 
 It
> probably dates from the time when Stallman distributed code via 9-track 
tape
> and Larry Wall's "patch" didn't exist.)

Your interpretation of the GPL is probably accurate, but remember that any 
license agreement is only as useful as it is enforceable and/or your 
argument is "valid."  Convention seems to be releasing the patches, 
especially for smaller bits, but the intent of the GPL suggests (to me at 
least) that the idea wasn't related to obsolete hardware, rather it was 
designed to protect free software from being modified with "patches" that 
don't work with the main body of code unless the "company" is involved.  A 
patch (possibly obfuscated?) that only the company can patch doesn't 
benefit free software, so the complete patched source likely found its way 
there for a reason.  Again, free as in freedom and not free as in 
beer...there comes a cost with "supporting" free software.

Also, I don't think that the GPL specifies exactly how you must make the 
sources public.  I think that it also clearly allows you to recover your 
distribution costs.  Perhaps placing a link on a web site for a $10 
distribution fee for the CD plus shipping and handling would still be 
within the spirit of the GPL.  Free as in Freedom and not free as in beer 
goes both ways.  You shouldn't have to "give away" your changes if it costs 
you money to distribute them, however, you can't charge openly for the 
changes themselves.  This could be a tricky legal issue, and I haven't read 
fully the entire GPL in a few years...so, definitely consult a 
professional!

>
> 3.  We're also free to use newlib in much the same way as uClinux.

I haven't checked recently, but I believe that it is under the LGPL...isn't 
it?

>
> 4.  Although we'll probably freely mention the product is "powered by
> uClinux," there is no requirement to do so.

"Promoting" the name of the free software may be beneficial to the free 
software, but it may simply be a way for the company to benefit on the 
popularity of the free software, too.  I think that this was aptly left out 
for such confusing possibilities...

>
> So is that it?  Has anyone attempted to use uClinux (or Linux in general)
> and found some aspect of their product that caused cease and desist 
letters
> to be received?  What I'm trying to do here is ensure that the company 
I'm
> working for doesn't regret using uClinux because of a misunderstanding of
> the licensing.

Which "company" "owns" Linux/uClinux to send the letters?  I've used 
uClinux and Linux in products without fear because I don't mind complying 
with the GPL/LGPL and offer all my code for free download from a server 
with mirrors.  I don't care that my changes are made "open" to others, in 
fact, I care that they ARE made freely available to others.  I think that 
once a company chooses this mindset, then they are in a position to not 
fear free software. ...and, I think appropriately, those who are 
unable/incapable of choosing such a mindset, should probably stay away from 
it :)

>
> Is there some authoritative web site, FAQ, or other reliable source of
> information that specifically deals with the licensing issues of 
embedding
> uClinux (or Linux in general) into closed-source commercial products?

I think that your own legal advisors will have to read the various licenses 
and copyrights associated with the software and make their own 
determination...however, I have seen some "legal discussions" pop up in a 
wide variety of places...perhaps try /. ?

>
>
> This message resent by the uclinux-dev at uclinux.org list server 
http://www.uClinux.org/

Take Care.

Rob!
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From fmore at netceler.com  Wed Apr 24 12:28:43 2002
From: fmore at netceler.com (Fabien More)
Date: Wed, 24 Apr 2002 18:28:43 +0200
Subject: [uClinux-dev] newbie : java on uClinux
References: <01C1EBAE.348BD260@smithwicks.softsys.co.at>
Message-ID: <3CC6DD3B.70705@netceler.com>



Erwin Authried wrote:

> Fabien More[SMTP:fmore at netceler.com] wrote:
> 
>> thanks you  for your replie.
>> i have download waba and i try to compile it.
>> The README.uClinux talk about m68k-coff-gcc !! i d'ont have this 
>> compiler, for my processor, I use m68k-elf-gcc. I try to configure with 
>> the command line :
>>        ./configure --target=m68k --with-prefix=m68k-elf --with-nogui
>> and there is this error:
>> *********************************
>> ...
>>    checking host system type... i686-pc-linux-gnu
>>    checking for gcc... m68k-elf-gcc
>>    checking whether the C compiler (m68k-elf-gcc  ) works... no
>>    configure: error: installation or configuration problem: C compiler 
>> cannot create executables.
>> 
>> **********************************
>> I dont know what is this error. With a simple c file, the compiler 
>> m68k-elf-gcc works nicely!!
>> 
> 
> For cross compilation, you may have to set up a few environment variables,
> like PATH, CFLAGS, LDFLAGS. Take a look into the logfile that is created
> by configure, it should give detailed error messages. When configure
> is doing tests that require running a test program, the cross configuration
> may fail too. In such cases, it may help to to manually edit config.cache
> to skip such tests.

Ok, thanks, with CFLAGS and LDFLAGS in env variables, configure 
succesful. Now, i try to compile but there are others errors. I will try 
to fix it.
fabien

> -Erwin
> 
> This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/
> 
> 

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From fmore at netceler.com  Wed Apr 24 12:48:09 2002
From: fmore at netceler.com (Fabien More)
Date: Wed, 24 Apr 2002 18:48:09 +0200
Subject: [uClinux-dev] newbie : java on uClinux
References: <579C0CAF497CD511AD4D00508BBD7AAC0246F1@pikachu.ntu.ac.uk>
Message-ID: <3CC6E1C9.9060708@netceler.com>



Howson, Mark wrote:

> Fabien wrote:
> 
> 
>> i have download waba and i try to compile it.
>> The README.uClinux talk about m68k-coff-gcc !! i d'ont have this 
>> compiler, for my processor, I use m68k-elf-gcc. I try to
> 
> That's okay.
>  
> 
>> configure with 
>> the command line :
>>        ./configure --target=m68k --with-prefix=m68k-elf --with-nogui
>> and there is this error:
> 
>>    checking for gcc... m68k-elf-gcc
>>    checking whether the C compiler (m68k-elf-gcc  ) works... no
>>    configure: error: installation or configuration problem: C compiler
>> cannot create executables.
> 
>  
> Have a look through the config.log file (it'll be in the same directory as
> you ./configure'd in. That should point you to the problem (if not, post
> your config.log here).

thanks, now, ./configure succes but i have some error when i try to 
compile. I will try to fix it
fabien

> Mark
> This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/
> 
> 

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From sujz at cad.csie.ncku.edu.tw  Wed Apr 24 13:10:53 2002
From: sujz at cad.csie.ncku.edu.tw (SuCC)
Date: Thu, 25 Apr 2002 01:10:53 +0800
Subject: [uClinux-dev] problem for pppd on uClinux....help!!!
References: <BC03D160581F7A4E92710FC238282411024F3E@ici-mail.intellicom.se> <004401c1eb8d$5e3e45a0$70c9748c@pc2> <002901c1eb9d$96d63ca0$2df7748c@SCC> <015401c1ebab$016166a0$70c9748c@pc2>
Message-ID: <005301c1ebb3$01575ae0$2df7748c@SCC>

1.Where the "options" file put depend on the _PATH_SYSOPTIONS definition in
your source
   And, you can make a "options" file in your ROM or RAM file system.(But
the _PATH_SYSOPTIONS must be defined the right path)
2.Yes, but I am so sorry, from your error messages, you should add pty in
your /dev!!

Good lock!!

----- Original Message -----
From: "???" <kuochung at mail.iaa.ncku.edu.tw>
To: <uclinux-dev at uclinux.org>
Sent: Thursday, April 25, 2002 12:13 AM
Subject: Re: [uClinux-dev] problem for pppd on uClinux....help!!!


> HI !!
> from your mail,the '/etc/option' ??
> Is that the file named 'options' in ppp directory??
> Or a file i should make myself to add  to /etc, if yes,what are the
> 'options' shall i make??
> And,does tty mean ttyS0 ????
>
> Regards
> Kuo
>
>
> > I give you a suggestion from my experience!!
> > 1.You can trace the code and take these check off.
> >    Because you just need "/etc/option" in embedded env.
> > 2.You should add tty in your /dev of your embedded linux~~~
> >
>
>
> This message resent by the uclinux-dev at uclinux.org list server
http://www.uClinux.org/
>
>


This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From julienb at actimage.fr  Wed Apr 24 13:10:53 2002
From: julienb at actimage.fr (Julien Boibessot)
Date: Wed, 24 Apr 2002 19:10:53 +0200
Subject: [uClinux-dev] newbie problem: how to download bootloader into the flash with the bdm
References: <IIEJKNDGMGJEOBIKAGPAGEKPCAAA.chete@cnuninet.com>
Message-ID: <049101c1ebb2$fdb1d280$8947ec95@bruker.fr>

If you have a Motorola devt board then look at:
http://e-www.motorola.com/collateral/CFFLASHER.htm

othewise another solution is to do a uClinux image with flash support and
loading it through BDM and then burning the bootloader on flash with uClinux
utils......in that case
http://home.t-online.de/home/Bernhard_Kuhn/uclinux/Platforms/Coldfire/tarifa
/20011119/README may help you.....


Julien


----- Original Message -----
From: "Bug cheng" <chete at cnuninet.com>
To: <uclinux-dev at uclinux.org>
Sent: Wednesday, April 24, 2002 6:25 PM
Subject: [uClinux-dev] newbie problem: how to download bootloader into the
flash with the bdm


> HI all!
> I want to know to how to download the boot loader into the flash with bdm
. I am using the 5272 processor.
> Best wishes
>  JIM chen.
>
> This message resent by the uclinux-dev at uclinux.org list server
http://www.uClinux.org/
>

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From john at labxtechnologies.com  Wed Apr 24 14:23:55 2002
From: john at labxtechnologies.com (John Passaniti)
Date: Wed, 24 Apr 2002 14:23:55 -0400
Subject: [uClinux-dev] Licensing Linux/uClinux
In-Reply-To: <01C1EB72.7A8DD880.rwehrli@azpower.com>
Message-ID: <001301c1ebbd$37e25290$0200a8c0@JOHN>

Rob Wehrli wrote:

> Which "company" "owns" Linux/uClinux to send
> the letters?  

Ownership isn't necessarily vague when it comes to open source software.
As an example, the Lua language's code and documentation is a
copywritten work owned by a university in Brazil.  The license for Lua
allows people to freely access and use it, but they can't claim it is
theirs.

Linux (and uClinux) may not be "owned" by any one person or company, but
certainly there are people who have a sense of ownership over it.  In
the case of uClinux, I believe Lineo is the company and the list of core
developers are the individuals one would contact.

> I've used uClinux and Linux in products without
> fear because I don't mind complying with the 
> GPL/LGPL and offer all my code for free download 
> from a server with mirrors.  I don't care that 
> my changes are made "open" to others, in fact, 
> I care that they ARE made freely available to 
> others.  I think that once a company chooses 
> this mindset, then they are in a position to not 
> fear free software. ...and, I think appropriately, 
> those who are unable/incapable of choosing such 
> a mindset, should probably stay away from it :)

Thanks for the comments, but I'm not interested in a political debate
and I don't have any real interest in furthering the GNU agenda.  I
figure there are plenty of people with far more spare time who are
already doing a great job on both.

The company I'm talking about doesn't necessarily have any objection to
releasing *their* code openly.  However, in doing so, they would
potentially violate other licenses.  We're using proprietary code (both
source and embedded in DSPs) that we can't reveal.  

Of course, all this is irrelevant.  I'm not talking about the
application so much as I am about the operating system.  Regardless of
if the company releases the application code as open source software,
the operating system is what I'm asking about.

> I think that your own legal advisors will have
> to read the various licenses and copyrights 
> associated with the software and make their own 
> determination...however, I have seen some "legal 
> discussions" pop up in a wide variety of 
> places...perhaps try /. ?

I don't consider Slashdot authoritative, but thanks anyway.  The legal
advisors would of course look at the copyrights and licenses-- I'm just
trying to do a first pass.

Thanks again.


This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From pauli at snapgear.com  Wed Apr 24 16:57:21 2002
From: pauli at snapgear.com (pauli at snapgear.com)
Date: Thu, 25 Apr 2002 06:57:21 +1000
Subject: [uClinux-dev] new shared library implementation trashage? 
In-Reply-To: Your message of "24 Apr 2002 18:13:32 +0900."
             <buor8l5jw77.fsf@mcspd15.ucom.lsi.nec.co.jp> 
References: <buor8l5jw77.fsf@mcspd15.ucom.lsi.nec.co.jp> 
Message-ID: <200204242057.g3OKvLOY001000@skaro.internal.moreton.com.au>

Hi all,

Miles Bader wrote:

> I've been having problems getting the new source snapshot to work on the
> v850 -- the text segments of programs are getting bogus values written
> into them.

> I notice the following in fs/binfmt_flat.c:
> 
> 	/* Update data segment pointers for all libraries */
> 	for (i=0; i<MAX_SHARED_LIBS; i++)
> 		if (libinfo.lib_list[i].loaded)
> 			for (j=0; j<MAX_SHARED_LIBS; j++)
> 				(-(j+1))[(unsigned long *)(libinfo.lib_list[i].start_data)] =
> 					(libinfo.lib_list[j].loaded)?
> 						libinfo.lib_list[j].start_data:UNLOADED_LIB;

> I don't understand at all what it's trying to do, and I thought at first
> that it wouldn't affect me, as the v850 doesn't have any kind of shared
> library support.  However, I notice now that the executable file is
> apparently considered `shared library number 0'.

Yes, the main program is shared library zero under the current implementation.
This is true even if the shared library support for flat files is compiled out 
of the kernel.  However it should only have meaning if your program is 
compiled with the new -mid-shared-library option and even then it won't mean 
much without the kernel option too.


> That said, what on earth is happening here?  It appears as if this is
> going to simply go and trash some memory before the start of the data
> segment (which in my case, is the text segment).  Is this true?

No it isn't trashing memory.  It is writing below what your program thinks is 
the beginning of its data segment, however the start of the data segment has 
been bumped up to accommodate this.  Looking at the load to RAM option (i.e. 
traditional relocatable executables no -msep-data or later), I don't think 
this adjustment has been factored in :-(  I suspect this the problem you're 
encountering?

A quick and dirty fix would be to pad the end of the text segment with four 
bytes.  A proper fix will come soon...


Regards,

Pauli


This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From Fabrice_Gautier at sdesigns.com  Wed Apr 24 20:40:53 2002
From: Fabrice_Gautier at sdesigns.com (Fabrice Gautier)
Date: Wed, 24 Apr 2002 17:40:53 -0700
Subject: [uClinux-dev] Pb with modules and tasklet
Message-ID: <B1F6452C89AFD411AE0800A0CC734C239DBBE2@EMAIL1>

Hi,

I want to use a module that uses a tasklet. 
The problem is that when I try to insmod this module, I get an undefined
symbol for __do_softirq

I tracked the problem and i reach the following conclusions:

* __do_softirq is referenced by local_bh_enable which is referenced by
spin_unlock_bh
* This same local_bh_enable in the i386 arch calls do_softirq instead of
__do_softirq
* If i do a nm on my kernel, i can see both do_softirq and __do_soft_irq BUT
only do_soft_irq is exported (ie there is a __ksymtab_do_softirq symbol)

So the question is:
- Should __do_softirq be exported as well or instead of do_softirq
- OR Should local_bh_enable calls do_softirq instead of __do_softirq

Thanks

-- 
Fabrice Gautier, 
Fabrice_Gautier at sdesigns.com
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From licz at neusoft.com  Wed Apr 24 20:50:45 2002
From: licz at neusoft.com (lcz)
Date: Thu, 25 Apr 2002 08:50:45 +0800
Subject: [uClinux-dev] ploblem about port uclinux 2.4
Message-ID: <001f01c1ebf3$3c070d80$c00376ca@lichangzhong>

Hi,

I am porting linux 2.4 kernel for dragonball VZ , it has run,but have a problem . when 'ls' list device file, major & minor number is wrong , major number are all zero , minor number are all major number , I found system call 'stat' return a wrong device number.
why?

kernel : 2.4.10 + uclinux patch uc2
sh: sash
filesystem : romfs
tool-chains : m68k-elf-20020410


Regards
lcz


This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From justin.wojdacki at analog.com  Wed Apr 24 21:25:46 2002
From: justin.wojdacki at analog.com (Justin Wojdacki)
Date: Wed, 24 Apr 2002 18:25:46 -0700
Subject: [uClinux-dev] ploblem about port uclinux 2.4
References: <001f01c1ebf3$3c070d80$c00376ca@lichangzhong>
Message-ID: <3CC75B1A.F40E5459@analog.com>

lcz wrote:
> 
> Hi,
> 
> I am porting linux 2.4 kernel for dragonball VZ , it has run,but have a problem . when 'ls' list device file, major & minor number is wrong , major number are all zero , minor number are all major number , I found system call 'stat' return a wrong device number.
> why?
> 
> kernel : 2.4.10 + uclinux patch uc2
> sh: sash
> filesystem : romfs
> tool-chains : m68k-elf-20020410
> 
> Regards
> lcz
> 
> This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/

Check what the kernel and uClibc think the size of struct dev is. I
ran into the same problem, and the reason was that the type of struct
dev was different between these two realms. 

-- 
-------------------------------------------------
Justin Wojdacki        
justin.wojdacki at analog.com         (408) 350-5032
Communications Processors Group -- Analog Devices
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From Fabrice_Gautier at sdesigns.com  Wed Apr 24 21:51:52 2002
From: Fabrice_Gautier at sdesigns.com (Fabrice Gautier)
Date: Wed, 24 Apr 2002 18:51:52 -0700
Subject: [uClinux-dev] Caches and DMA
Message-ID: <B1F6452C89AFD411AE0800A0CC734C239DBBE3@EMAIL1>


Actually, the flush is done in pci_alloc_consistent

-- 
Fabrice Gautier, 
Fabrice_Gautier at sdesigns.com


> -----Original Message-----
> From: David McCullough [mailto:davidm at snapgear.com]
> Sent: Thursday, April 18, 2002 9:17 PM
> To: uclinux-dev at uclinux.org
> Subject: Re: [uClinux-dev] Caches and DMA
> 
> 
> 
> Jivin Fabrice Gautier lays it down ...
> > Hi,
> > 
> > Can someone tell me if the kernel expect DMA memory to be 
> not cacheable? ie:
> > does the kernel sync the caches after a DMA transfert or 
> does it expect this
> > memory not be cacheable/cached in the first place ? 
> 
> I think it depends on your PCI implementation (HW).  I was 
> working on a
> SuperH a while back and I needed to flush/invalidate the 
> areas I was using
> for DMA to get sane behaviour.  It was hooked in somewhere 
> quite cleanly, I
> can dig it up if you like,
> 
> Cheers,
> Davidm
> 
> -- 
> David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
> davidm at snapgear.com  Fx: +61 7 3891 3630  825 Stanley St., 
> W'gabba QLD 4102, Oz
> This message resent by the uclinux-dev at uclinux.org list 
> server http://www.uClinux.org/
> 
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From ronald at 2bright.net  Wed Apr 24 22:17:39 2002
From: ronald at 2bright.net (Ronald Wiplinger)
Date: Thu, 25 Apr 2002 10:17:39 +0800
Subject: [uClinux-dev] Where to start?
Message-ID: <5.1.0.14.2.20020425100709.00c078c8@mail.2bright.net>

I am totally new to uClinux, so forgive me to ask that way.

I don't know where to start!

I got a board with a processor type GX from National Semiconductor

Geode? GXm Processor
Integrated x86 Solution with MMX Support
General Description

The National Semiconductor ? Geode? GXm processor
is an advanced 32-bit x86 compatible processor offering
high performance, fully accelerated 2D graphics, a 64-bit
synchronous DRAM controller and a PCI bus controller,
all on a single chip that is compatible with Intel?s MMX
technology.

I want to install a Compact Flash Card with Linux kernel 2.4.18 with IPv6 
enabled!!!
The system should include:
1. Web browser
2. Similar thing to Pocket Word / Pocket Excel

(and it should fit on the smallest available Flash card --- just kidding!)

Principle I should replace a Windows CE system with Linux.
Any hints are welcomed that I get the ball running.

Thanks!

bye

Ronald



  Ronald  Wiplinger
Bright Networking Inc.
7F, 192-1, Sec. 3, Tatung Rd., Shijr City, Taipei, Taiwan, RoC
Tel.: +886 2 8647-1685, Mobile +886 915 653-452, Fax: +886 2 8647-2002
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20020425/5e4364ff/attachment.html>

From Fabrice_Gautier at sdesigns.com  Wed Apr 24 22:46:39 2002
From: Fabrice_Gautier at sdesigns.com (Fabrice Gautier)
Date: Wed, 24 Apr 2002 19:46:39 -0700
Subject: [uClinux-dev] Getting rid of networking support
Message-ID: <B1F6452C89AFD411AE0800A0CC734C239DBBE5@EMAIL1>

Hi,

When i compile my UClinux, i have disabled network support in the config
file but I still have some core network files that are compiled and take
about 28KB.

In the makefile in the net subdir some files are always compile, even if
CONFIG_NET is not defined.

Is there a reason for that, or is it safe to complete eliminate those files?

Thanks.

-- 
Fabrice Gautier, 
Fabrice_Gautier at sdesigns.com
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From miles at lsi.nec.co.jp  Thu Apr 25 00:12:39 2002
From: miles at lsi.nec.co.jp (Miles Bader)
Date: 25 Apr 2002 13:12:39 +0900
Subject: [uClinux-dev] Re: new shared library implementation trashage?
In-Reply-To: <200204242057.g3OKvLOY001000@skaro.internal.moreton.com.au>
References: <buor8l5jw77.fsf@mcspd15.ucom.lsi.nec.co.jp>
	<200204242057.g3OKvLOY001000@skaro.internal.moreton.com.au>
Message-ID: <buou1q01knc.fsf@mcspd15.ucom.lsi.nec.co.jp>

pauli at snapgear.com writes:
> Yes, the main program is shared library zero under the current
> implementation.  This is true even if the shared library support for
> flat files is compiled out of the kernel.  However it should only have
> meaning if your program is compiled with the new -mid-shared-library
> option and even then it won't mean much without the kernel option too.

What program is `-mid-shared-library' an option for?

> No it isn't trashing memory.  It is writing below what your program
> thinks is the beginning of its data segment, however the start of the
> data segment has been bumped up to accommodate this.

Where has the data segment been bumped up (I mean, in which program was
a change made that does the bumping)?

Remember, I'm using a v850, so any tool changes you guys have made for
the m68k/arm won't affect me.  [and in general, given the large number
of architectures that uclinux supports, I think it's a bad thing to
make a kernel change that requires tools changes on `non-affected'
architectures, without at least, using a different version number for
the flat files]

Thanks,

-Miles
-- 
I'd rather be consing.
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From ricks at snapgear.com  Thu Apr 25 00:17:46 2002
From: ricks at snapgear.com (Rick Stevenson)
Date: Thu, 25 Apr 2002 14:17:46 +1000
Subject: [uClinux-dev] Licensing Linux/uClinux
In-Reply-To: <001301c1ebbd$37e25290$0200a8c0@JOHN>
Message-ID: <NDBBJPOCCLAPONPEHNEIEEHGGCAA.ricks@snapgear.com>

John Passaniti wrote:
> Linux (and uClinux) may not be "owned" by any one person or company, but
> certainly there are people who have a sense of ownership over it.  In
> the case of uClinux, I believe Lineo is the company and the list of core
> developers are the individuals one would contact.

All the active uClinux contributors from Lineo have either been laid off or
spun out in separate companies.  SnapGear (Greg Ungerer, David McCullough,
Paul Dale, etc.) was spun out more than six months ago and the folks from
Lineo Toronto (Jeff Dionne, Michael Durrant, etc.) are now Arcturus
Networks.

Cheers,
Rick.
--
Rick Stevenson, SnapGear, Inc.
Ph: +61 7 3435 2811, Mob: +61 404 876 939, Fx: +61 7 3891 3630
Email: ricks at snapgear.com, Web: http://www.snapgear.com

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From Fabrice_Gautier at sdesigns.com  Thu Apr 25 01:35:06 2002
From: Fabrice_Gautier at sdesigns.com (Fabrice Gautier)
Date: Wed, 24 Apr 2002 22:35:06 -0700
Subject: [uClinux-dev] Sash ls and special files.
Message-ID: <B1F6452C89AFD411AE0800A0CC734C239DBBE7@EMAIL1>

Hi,

When I do  ls -l /dev, the major numbers are correct but the minors are all
zeros.

The problems seems to be that sash does a sprintf of the device number with
a %d format string whereas the device number is 64bits.

Maybe its only a sprintf problem, but im not sure if this may implie other
problem elsewhere

Does anyone else see this?

Thanks

-- 
Fabrice Gautier, 
Fabrice_Gautier at sdesigns.com
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From newsgroup at pandora.be  Thu Apr 25 03:09:43 2002
From: newsgroup at pandora.be (Kurt)
Date: Thu, 25 Apr 2002 09:09:43 +0200
Subject: [uClinux-dev] Vixie
Message-ID: <001501c1ec28$2cb5e650$0b01a8c0@aphrodite>

Hi.

I'm trying to compile the vixie cron into my uClinux image here (v20020411).
Unfortunately I bump into this error:

m68k-elf-gcc -m68000 -Os -g -fomit-frame-pointer -DCONFIG_SECUREEDGE -Dlinux
 -D__linux__ -Dunix -D__uClinux__ -DEMBED -I/home/kurt/DragonEngine/uClinux/
uClinux-new/lib/libc/include -I/home/kurt/DragonEngine/uClinux/uClinux-new/l
ib/libm -I/home/kurt/DragonEngine/uClinux/uClinux-new -fno-builtin -m68000 -
msep-data -I/home/kurt/DragonEngine/uClinux/uClinux-new/linux-2.4.x/include 
-g -I. -c -o cron.o cron.c
cron.c: In function `sigchld_handler':
cron.c:251: storage size of `waiter' isn't known
make[2]: *** [cron.o] Error 1
make[2]: Leaving directory
`/home/kurt/DragonEngine/uClinux/uClinux-new/user/vixie-cron'
make[1]: *** [all] Error 2
make[1]: Leaving directory
`/home/kurt/DragonEngine/uClinux/uClinux-new/user'
make: *** [subdirs] Error 1

When I take a look at cron.c, I suppose the WAIT_T is not defined? How can I
solve this in a proper way or did I forgot to install another package?
Thanks.


This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From miles at lsi.nec.co.jp  Thu Apr 25 03:27:02 2002
From: miles at lsi.nec.co.jp (Miles Bader)
Date: 25 Apr 2002 16:27:02 +0900
Subject: [uClinux-dev] Re: new shared library implementation trashage?
In-Reply-To: <buopu0o1ki9.fsf@mcspd15.ucom.lsi.nec.co.jp>
References: <200204242220.g3OMKHOY022779@skaro.internal.moreton.com.au>
	<buopu0o1ki9.fsf@mcspd15.ucom.lsi.nec.co.jp>
Message-ID: <buo8z7c1bnd.fsf@mcspd15.ucom.lsi.nec.co.jp>

I fixed my problem by adding the following patch to the linker-script
that I use for user programs:


diff -up elf2flt.ld.\~1\~ elf2flt.ld
--- elf2flt.ld.~1~	Thu Apr 11 22:55:30 2002
+++ elf2flt.ld	Thu Apr 25 16:06:00 2002
@@ -31,6 +31,11 @@ SECTIONS {
 		. = ALIGN(0x10) ;
 		_etext = . ;
         } > flatmem
+	.shlib : {
+		/* Reserve space for `shared library' info (though we don't
+		   use it, the binfmt_flat loader still needs one slot).  */
+		LONG (0);
+	} > flatmem
         .data : {
                 . = ALIGN(0x4) ;
                 _sdata = . ;


Is this the right fix?

-Miles
-- 
I'd rather be consing.
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From valera at soling.ur.ru  Thu Apr 25 04:54:31 2002
From: valera at soling.ur.ru (Valera)
Date: Thu, 25 Apr 2002 13:54:31 +0500
Subject: [uClinux-dev] make dep error under Cygwin
Message-ID: <000e01c1ec36$d0b5a980$dd00a8c0@valera>

Please, help me.
I use uClinux-dist-20020411.tar.gz and Cygwin.

make config (by default for m5272c3) is okey, but make dep failed with
message:

>make dep
make -C linux-2.4.x dep
make[1]: Entering directory `/uClinux-dist/linux-2.4.x'
scripts/mkdep -- init/*.c > .depend
scripts/mkdep -- `find /uClinux-dist/linux-2.4.x/include/asm
/uClinux-dist/linux-2.4.x/include/linux
/uClinux-dist/linux-2.4.x/include/scsi
/uClinux-dist/linux-2.4.x/include/net -name SCCS -prune -o -follow -name
\*.h ! -name modversions.h -print` > .hdepend
scripts/mkdep: error 22
make[1]: *** [dep-files] Error1
make[1]: Leaving directory `/uClinux-dist/linux-2.4.x'
make: *** [dep] Error2

where problems?

Valery

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From stefan_heinzmann at yahoo.com  Thu Apr 25 04:11:35 2002
From: stefan_heinzmann at yahoo.com (=?iso-8859-1?q?Stefan=20Heinzmann?=)
Date: Thu, 25 Apr 2002 10:11:35 +0200 (CEST)
Subject: [uClinux-dev] Shared libraries
Message-ID: <20020425081135.82114.qmail@web11201.mail.yahoo.com>

Hi all, 

I'm new to the list, so forgive me if I missed something important. I
found a contribution by Pauli from SnapGear posted on 2002-04-01
regarding shared libraries on uClinux when I was trying to find
information on how shared libraries are implemented in systems without
virtual memory. I hope the posting date does not indicate that it is a
joke.

Pauli describes a method that may well work, but I find it wanting
(assuming that I have understood it correctly). There are too many
compromises in there for my taste. The worst idea IMHO is the stealing
of address bits. That is something Apple has already regretted in the
history of 68k Macs.

If I haven't missed anything important, I think I know a better way,
which I'll attempt to describe below:

The basic ideas aren't that far from Pauli's solution, but let me
describe it first without referencing his solution.

An application that is linked to one or more shared libraries may want
to
-- call functions in the shared library
-- access global data in the shared library
-- pass function pointers for use by the shared library
-- provide global data or functions referenced by the shared library

In the last case, the shared library has unresolved references which
the application satisfies. It is to be discussed whether that is
supposed to be legal, but it can occur in the most general case.

If you haven't got virtual memory, but want several processes to share
a library, the library's static data will have to be instantiated
separately for each process, meaning that the instances can't be
referenced using absolute addressing. Neither can they be referenced
pc-relative, because there is only one instance of the code. The
Coldfire/m68k world thus uses register A5 as a base pointer for static
data.

On the target system there exists a dynamic linker which - when
starting a new process - figures out which shared libraries have to be
loaded before the application can be started. It loads these libraries,
performs any required relocations, and finally loads the application
code, relocates it, allocates memory for its static data including the
static data required by the static libraries, and finally transfers
control to the application.

So much for the preamble (which Pauli will probably agree to).

My proposal for handling shared libraries is the following:

The operating system assigns sequential slot numbers to each loaded
shared library, starting from 1. If a library gets unloaded, its slot
can be reused by the next library that gets loaded, but loaded
libraries keep their slot number until they get unloaded.

The shared library does not need to be compiled to use pc-relative
addressing, since the dynamic linker knows where it will end up in the
address space and can do the necessary relocations when loading the
library. On the other hand, fewer relocations mean quicker loading, so
pc-relative might still be a good idea.

However, in order to access static data, it must use a special method
that a normal application needn't use. The details are described later.
This means that the shared library must be compiled with a special
compiler switch.


When loading an application, the required shared libraries are loaded
first. When allocating the static data for the application, the loader
allocates a chunck of memory large enough for the static data of the
application itself, plus the static data of all the shared libraries it
uses, plus the space needed for an "import table", in the following
order:
-- first comes the import table
-- next comes the static data of the application
-- next come the static data of all imported libraries

A5 is set up to point to the static data of the application. The import
table can then be referenced with negative offsets with respect to A5.

The import table is set up by the dynamic linker; the application or
the libraries only read from it. It contains pointers to the static
data of each shared library. The offset into the table is calculated
from the library's slot number (i.e. offset = slot_number*-4). A
procedure in a shared library can thus get a pointer to its own static
data with the following instruction:
    MOVEA (offset,A5),Ax
The dynamic linker needs to fix up the offset when loading the shared
library (by which time it knows the slot number).

The size of the import table is determined by the highest slot number
of any of the libraries used by the application. This is known by the
time the application is loaded.

Naturally, there might be empty entries in the import table. These
represent loaded libraries, which are not used by the application at
hand. Since static data is not allocated for those, the entry in the
import table is a null pointer.

If the application or a shared library needs access to global data in
another shared library, it has to go through the GOT in the usual way.
Each shared library has its own GOT as part of its static data, so to
access it the same instruction is necessary as shown above.

Cross references to code can be fixed up directly by the dynamic
linker, since the addresses are all known. A PLT should therefore be
unnecessary.

I can not currently see where this scheme breaks. It avoids several
problems:
-- No limit on the size of the application (no address bits stolen)
-- No limit on the number of shared libraries
-- No change for code that isn't in a shared library
-- Shared libraries pay a small price for accessing static data
-- Static data overhead is one import table per process

Given that the entire static data segment needs to be allocated for a
shared library, regardless of whether the data is actually needed by
the application, it may actually pay under these circumstances to have
smaller individual libraries that can be loaded separately.
Alternatively, the library could be changed to allocate larger pieces
of data (i.e. buffers) on demand and hold only a static pointer to it.

Note that only functions in a shared library which want to access
static data pay a penalty. I'm not really unhappy about this because
static data in a library is politically incorrect anyway (it creates
reentrancy problems when you use threads).

Have I overlooked anything?

Cheers
Stefan



__________________________________________________________________

Gesendet von Yahoo! Mail - http://mail.yahoo.de
Sie brauchen mehr Speicher f?r Ihre E-Mails? - http://premiummail.yahoo.de
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From prasannark at future.futsoft.com  Thu Apr 25 04:56:22 2002
From: prasannark at future.futsoft.com (Prasanna Rao K)
Date: Thu, 25 Apr 2002 14:26:22 +0530
Subject: [uClinux-dev] munmap of non-mapped memory by process 
Message-ID: <000001c1ec37$13be9ca0$7606140a@future.futsoft.com>

Hi,

 Any body has the idea why the following message arrives when we run our
exe.

"munmap of non-mapped memory by process 10".

What is the cause for above message, is it due to misuse of some pointer?

Prasanna

***************************************************************************
This message is proprietary to Future Software Limited (FSL) 
and is intended solely for the use of the individual to whom it
is addressed. It may contain  privileged or confidential information 
and should not be circulated or used for any purpose other than for 
what it is intended. 

If you have received this message in error, please notify the
originator immediately. If you are not the intended recipient,
you are notified that you are strictly prohibited from using,
copying, altering, or disclosing the contents of this message. 
FSL accepts no responsibility for loss or damage arising from 
the use of the information transmitted by this email including
damage from virus.
***************************************************************************
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From miles at lsi.nec.co.jp  Thu Apr 25 05:21:33 2002
From: miles at lsi.nec.co.jp (Miles Bader)
Date: 25 Apr 2002 18:21:33 +0900
Subject: [uClinux-dev] v850 update patch
Message-ID: <buo1yd416ci.fsf@mcspd15.ucom.lsi.nec.co.jp>

Hi, this patch updates v850 stuff; could you apply it?

Thanks,

-Miles


-------------- next part --------------
A non-text attachment was scrubbed...
Name: uclinux-2.4-v850-20020425-dist.patch
Type: text/x-patch
Size: 83064 bytes
Desc: v850 update patch 20020425
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20020425/169fb929/attachment.patch>
-------------- next part --------------



-- 
`Life is a boundless sea of bitterness'

From miles at lsi.nec.co.jp  Thu Apr 25 05:25:28 2002
From: miles at lsi.nec.co.jp (Miles Bader)
Date: 25 Apr 2002 18:25:28 +0900
Subject: [uClinux-dev] Re: v850 update patch
In-Reply-To: <buo1yd416ci.fsf@mcspd15.ucom.lsi.nec.co.jp>
References: <buo1yd416ci.fsf@mcspd15.ucom.lsi.nec.co.jp>
Message-ID: <buowuuwyvsn.fsf@mcspd15.ucom.lsi.nec.co.jp>

p.s. it adds new files, which are all at the beginning of the patch.
[don't know if it matters, but just in case]

-- 
[|nurgle|]  ddt- demonic? so quake will have an evil kinda setting? one that 
            will  make every christian in the world foamm at the mouth? 
[iddt]      nurg, that's the goal 
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From miles at lsi.nec.co.jp  Thu Apr 25 05:38:04 2002
From: miles at lsi.nec.co.jp (Miles Bader)
Date: 25 Apr 2002 18:38:04 +0900
Subject: [uClinux-dev] v850 updates for uClinux-dist-20020425
Message-ID: <buosn5kyv7n.fsf@mcspd15.ucom.lsi.nec.co.jp>

Hi, these are some updates to the v850-specific parts of
uClinux-dist-20020425; please apply.  This patch adds new files (which
are not at the beginning of the patch).

Thanks,

-Miles


-------------- next part --------------
A non-text attachment was scrubbed...
Name: ucdist-v850-20020425-dist-v850.patch
Type: text/x-patch
Size: 27390 bytes
Desc: v850 updates for uClinux-dist-20020425
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20020425/20b855e9/attachment.patch>
-------------- next part --------------



-- 
Is it true that nothing can be known?  If so how do we know this?  -Woody Allen

From miles at lsi.nec.co.jp  Thu Apr 25 05:40:17 2002
From: miles at lsi.nec.co.jp (Miles Bader)
Date: 25 Apr 2002 18:40:17 +0900
Subject: [uClinux-dev] misc tweaks for uClinux-dist-20020411
Message-ID: <buoofg8yv3y.fsf@mcspd15.ucom.lsi.nec.co.jp>

Hi, this patch makes a few tweaks that I needed to do for the
distribution to compile; I always use the most recent CVS version of
uClibc, so these changes may only be valid in that case.  YMMV.

Thanks,

-Miles


-------------- next part --------------
A non-text attachment was scrubbed...
Name: ucdist-v850-20020425-dist-misc.patch
Type: text/x-patch
Size: 1385 bytes
Desc: misc tweaks for uClinux-dist-20020411
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20020425/11cbe25e/attachment.patch>
-------------- next part --------------



-- 
Yo mama's so fat when she gets on an elevator it HAS to go down.

From kuochung at mail.iaa.ncku.edu.tw  Thu Apr 25 06:47:22 2002
From: kuochung at mail.iaa.ncku.edu.tw (=?big5?B?tsCw6rZ2?=)
Date: Thu, 25 Apr 2002 18:47:22 +0800
Subject: [uClinux-dev] problem for pppd on uClinux....help!!!
References: <BC03D160581F7A4E92710FC238282411024F3E@ici-mail.intellicom.se> <004401c1eb8d$5e3e45a0$70c9748c@pc2> <002901c1eb9d$96d63ca0$2df7748c@SCC> <015401c1ebab$016166a0$70c9748c@pc2> <005301c1ebb3$01575ae0$2df7748c@SCC>
Message-ID: <001901c1ec46$950b5be0$70c9748c@pc2>


----- Original Message -----
From: "SuCC" <sujz at cad.csie.ncku.edu.tw>
To: <uclinux-dev at uclinux.org>
Sent: Thursday, April 25, 2002 1:10 AM
Subject: Re: [uClinux-dev] problem for pppd on uClinux....help!!!


> 1.Where the "options" file put depend on the _PATH_SYSOPTIONS definition
in
> your source
>    And, you can make a "options" file in your ROM or RAM file system.(But
> the _PATH_SYSOPTIONS must be defined the right path)
> 2.Yes, but I am so sorry, from your error messages, you should add pty in
> your /dev!!
>
> Good lock!!


  Sir
    How can I add pty in my /dev??
    If it has to be done by add some command lines in my kernel config
file??
    Since it's a pseudo file, does it need any setting values??
    Thanks for your reply!!

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From fmore at netceler.com  Thu Apr 25 06:49:34 2002
From: fmore at netceler.com (Fabien More)
Date: Thu, 25 Apr 2002 12:49:34 +0200
Subject: [uClinux-dev] newbie : java on uClinux : link problem
References: <579C0CAF497CD511AD4D00508BBD7AAC0246F1@pikachu.ntu.ac.uk> <3CC6E1C9.9060708@netceler.com>
Message-ID: <3CC7DF3E.4000703@netceler.com>

New problems when I try to compile waba
I use le sommand line :
*************************************
m68k-elf-gcc  -O2   -fPIC -DWITH_THREAD=1 -DLINUX=1 -DGUI_NONE=1 
-DPLATFORM="\"Linux_NONE\""  -m5307 -DCONFIG_COLDFIRE -Os -g 
-fomit-frame-pointer -Dlinux -D__linux__ -Dunix -D__uClinux__ -DEMBED 
-fno-builtin -msep-data -Wl,-elf2flt  -lc -o waba  waba.o linux/libnmwaba.a
*************************************

and the error is:
*************************************
waba.elf2flt: In function `VmInit':
waba.elf2flt(.text+0x1a2): undefined reference to `memset'
waba.elf2flt(.text+0x1b0): undefined reference to `malloc'
waba.elf2flt(.text+0x1c0): undefined reference to `malloc'
waba.elf2flt(.text+0x1d8): undefined reference to `malloc'
waba.elf2flt(.text+0x1fe): undefined reference to `free'
waba.elf2flt(.text+0x212): undefined reference to `free'
waba.elf2flt(.text+0x226): undefined reference to `free'
waba.elf2flt(.text+0x234): undefined reference to `memset'
.....
make[3]: *** [waba] Error 1
..
**************************************

I think the mistake can be in the command line but i dont know where? 
This command line is made by a Makefile...
The full error is :
*************************************
make[3]: Entering directory 
`/home/fabien/dimm/uClinux-coldfire/others_softs/waba/waba-build/vm'
m68k-elf-gcc  -O2   -fPIC -DWITH_THREAD=1 -DLINUX=1 -DGUI_NONE=1 
-DPLATFORM="\"Linux_NONE\""  -m5307 -DCONFIG_COLDFIRE -Os -g 
-fomit-frame-pointer -Dlinux -D__linux__ -Dunix -D__uClinux__ -DEMBED 
-fno-builtin -msep-data -Wl,-elf2flt  -lc -o waba  waba.o 
linux/libnmwaba.a     
waba.elf2flt: In function `VmInit':
waba.elf2flt(.text+0x1a2): undefined reference to `memset'
waba.elf2flt(.text+0x1b0): undefined reference to `malloc'
waba.elf2flt(.text+0x1c0): undefined reference to `malloc'
waba.elf2flt(.text+0x1d8): undefined reference to `malloc'
waba.elf2flt(.text+0x1fe): undefined reference to `free'
waba.elf2flt(.text+0x212): undefined reference to `free'
waba.elf2flt(.text+0x226): undefined reference to `free'
waba.elf2flt(.text+0x234): undefined reference to `memset'
waba.elf2flt(.text+0x23e): undefined reference to `memset'
waba.elf2flt(.text+0x24a): undefined reference to `memset'
waba.elf2flt: In function `printToBuf':
waba.elf2flt(.text+0x2ba): undefined reference to `strncpy'
waba.elf2flt(.text+0x2ee): undefined reference to `strncpy'
waba.elf2flt: In function `VmFree':
waba.elf2flt: In function `VmInit':
waba.elf2flt(.text+0x1a2): undefined reference to `memset'
waba.elf2flt(.text+0x1b0): undefined reference to `malloc'
waba.elf2flt(.text+0x1c0): undefined reference to `malloc'
waba.elf2flt(.text+0x1d8): undefined reference to `malloc'
waba.elf2flt(.text+0x1fe): undefined reference to `free'
waba.elf2flt(.text+0x212): undefined reference to `free'
waba.elf2flt(.text+0x226): undefined reference to `free'
waba.elf2flt(.text+0x234): undefined reference to `memset'
waba.elf2flt(.text+0x23e): undefined reference to `memset'
waba.elf2flt(.text+0x24a): undefined reference to `memset'
waba.elf2flt: In function `printToBuf':
waba.elf2flt(.text+0x2ba): undefined reference to `strncpy'
waba.elf2flt(.text+0x2ee): undefined reference to `strncpy'
waba.elf2flt: In function `VmFree':
waba.elf2flt: In function `dumpMethod':
waba.elf2flt(.text+0x114e): undefined reference to `strlen'
waba.elf2flt(.text+0x1158): undefined reference to `strlen'
waba.elf2flt(.text+0x116c): undefined reference to `strlen'
waba.elf2flt(.text+0x1184): undefined reference to `strlen'
waba.elf2flt(.text+0x1194): undefined reference to `strlen'
waba.elf2flt(.text+0x119e): undefined reference to `strncpy'
waba.elf2flt(.text+0x11ae): undefined reference to `strcat'
waba.elf2flt(.text+0x11b8): undefined reference to `strlen'
waba.elf2flt(.text+0x11d4): undefined reference to `strlen'
waba.elf2flt(.text+0x11e4): undefined reference to `strlen'
waba.elf2flt(.text+0x11fc): undefined reference to `strlen'
waba.elf2flt(.text+0x120c): undefined reference to `strlen'
waba.elf2flt(.text+0x126a): undefined reference to `strncpy'
waba.elf2flt(.text+0x1286): undefined reference to `strncpy'
waba.elf2flt(.text+0x12a2): undefined reference to `sprintf'
waba.elf2flt(.text+0x12b2): undefined reference to `strncpy'
waba.elf2flt(.text+0x12d0): undefined reference to `strcat'
waba.elf2flt(.text+0x12e6): undefined reference to `strcat'
waba.elf2flt(.text+0x12fc): undefined reference to `strcat'
waba.elf2flt(.text+0x1312): undefined reference to `strcat'
waba.elf2flt(.text+0x1328): undefined reference to `strcat'
waba.elf2flt(.text+0x133e): more undefined references to `strcat' follow
waba.elf2flt: In function `dumpMethod':
waba.elf2flt(.text+0x13dc): undefined reference to `sprintf'
waba.elf2flt(.text+0x13e2): undefined reference to `strlen'
waba.elf2flt: In function `loadClassMethod':
waba.elf2flt(.text+0x1494): undefined reference to `strncmp'
waba.elf2flt: In function `createUtfString':
waba.elf2flt(.text+0x169e): undefined reference to `strlen'
waba.elf2flt: In function `copyArray':
waba.elf2flt(.text+0x1bc4): undefined reference to `memmove'
waba.elf2flt: In function `getField':
waba.elf2flt(.text+0x1c46): undefined reference to `strncmp'
waba.elf2flt(.text+0x1c5c): undefined reference to `strncmp'
waba.elf2flt: In function `getMethod':
waba.elf2flt(.text+0x1e4a): undefined reference to `strncmp'
waba.elf2flt(.text+0x1e5c): undefined reference to `strncmp'
waba.elf2flt: In function `initObjectHeap':
waba.elf2flt(.text+0x2016): undefined reference to `malloc'
waba.elf2flt(.text+0x202c): undefined reference to `memset'
waba.elf2flt: In function `freeObjectHeap':
waba.elf2flt(.text+0x20c0): undefined reference to `free'
waba.elf2flt: In function `sweep':
waba.elf2flt(.text+0x23e4): undefined reference to `memmove'
waba.elf2flt(.text+0x2480): undefined reference to `memset'
waba.elf2flt: In function `getNativeMethod':
waba.elf2flt(.text+0x27f4): undefined reference to `printf'
waba.elf2flt(.text+0x2800): undefined reference to `printf'
waba.elf2flt(.text+0x2822): undefined reference to `printf'
waba.elf2flt(.text+0x2838): undefined reference to `printf'
waba.elf2flt(.text+0x2864): undefined reference to `printf'
waba.elf2flt(.text+0x287c): more undefined references to `printf' follow
waba.elf2flt: In function `setClassHooks':
waba.elf2flt(.text+0x292c): undefined reference to `strlen'
waba.elf2flt(.text+0x293e): undefined reference to `strncmp'
waba.elf2flt: In function `getTimeStamp':
waba.elf2flt(.text+0x3f6c): undefined reference to `gettimeofday'
waba.elf2flt: In function `drawErrorWin':
waba.elf2flt(.text+0x3fcc): undefined reference to `printf'
waba.elf2flt(.text+0x3ff8): undefined reference to `printf'
waba.elf2flt(.text+0x4010): undefined reference to `printf'
waba.elf2flt(.text+0x4028): undefined reference to `printf'
waba.elf2flt(.text+0x4042): undefined reference to `printf'
waba.elf2flt(.text+0x4062): more undefined references to `printf' follow
waba.elf2flt: In function `startApp':
waba.elf2flt(.text+0x4560): undefined reference to `atoi'
waba.elf2flt(.text+0x456e): undefined reference to `strlen'
waba.elf2flt(.text+0x4580): undefined reference to `strncmp'
waba.elf2flt(.text+0x4598): undefined reference to `strncmp'
waba.elf2flt(.text+0x45ba): undefined reference to `strncmp'
waba.elf2flt(.text+0x45d2): undefined reference to `strncmp'
waba.elf2flt(.text+0x45f4): undefined reference to `strncmp'
waba.elf2flt(.text+0x460c): more undefined references to `strncmp' follow
waba.elf2flt: In function `startApp':
waba.elf2flt(.text+0x4766): undefined reference to `printf'
waba.elf2flt(.text+0x47b2): undefined reference to `getenv'
waba.elf2flt(.text+0x47c2): undefined reference to `strlen'
waba.elf2flt(.text+0x47d0): undefined reference to `strlen'
waba.elf2flt(.text+0x47e2): undefined reference to `malloc'
waba.elf2flt(.text+0x4800): undefined reference to `printf'
waba.elf2flt(.text+0x4812): undefined reference to `strcat'
waba.elf2flt(.text+0x481c): undefined reference to `strrchr'
waba.elf2flt(.text+0x4838): undefined reference to `strcat'
waba.elf2flt(.text+0x4844): undefined reference to `strlen'
waba.elf2flt(.text+0x4852): undefined reference to `strcat'
waba.elf2flt(.text+0x485a): undefined reference to `strcat'
waba.elf2flt(.text+0x4876): undefined reference to `strcat'
waba.elf2flt: In function `readFileIntoMemory':
waba.elf2flt(.text+0x49b8): undefined reference to `__xstat'
waba.elf2flt(.text+0x49c8): undefined reference to `open'
waba.elf2flt(.text+0x49ec): undefined reference to `malloc'
waba.elf2flt(.text+0x49fe): undefined reference to `read'
waba.elf2flt(.text+0x4a0c): undefined reference to `free'
waba.elf2flt(.text+0x4a2c): undefined reference to `close'
waba.elf2flt: In function `nativeLoadClass':
waba.elf2flt(.text+0x4a74): undefined reference to `strncpy'
waba.elf2flt(.text+0x4a8c): undefined reference to `strncpy'
waba.elf2flt(.text+0x4ade): undefined reference to `strlen'
waba.elf2flt(.text+0x4aec): undefined reference to `malloc'
waba.elf2flt(.text+0x4af8): undefined reference to `strncpy'
waba.elf2flt(.text+0x4b0a): undefined reference to `strtok'
waba.elf2flt(.text+0x4b32): undefined reference to `strtok'
waba.elf2flt(.text+0x4b86): undefined reference to `strcpy'
waba.elf2flt(.text+0x4b8c): undefined reference to `strlen'
waba.elf2flt(.text+0x4ba6): undefined reference to `strcat'
waba.elf2flt(.text+0x4bae): undefined reference to `strlen'
waba.elf2flt(.text+0x4bc2): undefined reference to `strncpy'
waba.elf2flt(.text+0x4bd4): undefined reference to `strlen'
waba.elf2flt(.text+0x4bf6): undefined reference to `strcmp'
waba.elf2flt(.text+0x4c04): undefined reference to `strcat'
waba.elf2flt(.text+0x4c5a): undefined reference to `free'
waba.elf2flt: In function `main':
waba.elf2flt(.text+0x4c94): undefined reference to `memset'
waba.elf2flt: In function `SocketCreate':
waba.elf2flt(.text+0x4f66): undefined reference to `malloc'
waba.elf2flt(.text+0x4f7c): undefined reference to `memset'
waba.elf2flt(.text+0x4fa0): undefined reference to `inet_addr'
waba.elf2flt(.text+0x4fbc): undefined reference to `gethostbyname'
waba.elf2flt(.text+0x4fd6): undefined reference to `memmove'
waba.elf2flt(.text+0x4fe6): undefined reference to `socket'
waba.elf2flt(.text+0x4ffa): undefined reference to `connect'
waba.elf2flt(.text+0x5018): undefined reference to `close'
waba.elf2flt(.text+0x501e): undefined reference to `free'
waba.elf2flt: In function `mySocketClose':
waba.elf2flt(.text+0x5044): undefined reference to `shutdown'
waba.elf2flt: In function `SocketIsOpen':
waba.elf2flt(.text+0x5094): undefined reference to `__fxstat'
waba.elf2flt: In function `SocketReadWriteBytes':
waba.elf2flt(.text+0x5140): undefined reference to `read'
waba.elf2flt(.text+0x5162): undefined reference to `write'
waba.elf2flt: In function `ConvertIntToString':
waba.elf2flt(.text+0x5dc0): undefined reference to `sprintf'
waba.elf2flt: In function `ConvertFloatToString':
waba.elf2flt(.text+0x5e00): undefined reference to `sprintf'
waba.elf2flt: In function `_FileAllocStr':
waba.elf2flt(.text+0x5f28): undefined reference to `strlen'
waba.elf2flt(.text+0x5f4c): undefined reference to `malloc'
waba.elf2flt: In function `_FileFreeStr':
waba.elf2flt(.text+0x5fa4): undefined reference to `free'
waba.elf2flt: In function `_FileClose':
waba.elf2flt(.text+0x5fcc): undefined reference to `close'
waba.elf2flt: In function `FileCreate':
waba.elf2flt(.text+0x6068): undefined reference to `__xstat'
waba.elf2flt(.text+0x6082): undefined reference to `open'
waba.elf2flt: In function `FileGetLength':
waba.elf2flt(.text+0x6102): undefined reference to `__fxstat'
waba.elf2flt: In function `_FileIsDir':
waba.elf2flt(.text+0x6126): undefined reference to `__xstat'
waba.elf2flt: In function `FileOp':
waba.elf2flt(.text+0x619c): undefined reference to `mkdir'
waba.elf2flt(.text+0x61b8): undefined reference to `remove'
waba.elf2flt(.text+0x61da): undefined reference to `rename'
waba.elf2flt(.text+0x61fc): undefined reference to `__xstat'
waba.elf2flt: In function `FileSeekWaba':
waba.elf2flt(.text+0x62b0): undefined reference to `lseek'
waba.elf2flt: In function `FileListDir':
waba.elf2flt(.text+0x6304): undefined reference to `opendir'
waba.elf2flt(.text+0x631e): undefined reference to `free'
waba.elf2flt(.text+0x6350): undefined reference to `malloc'
waba.elf2flt(.text+0x635e): undefined reference to `strlen'
waba.elf2flt(.text+0x6366): undefined reference to `malloc'
waba.elf2flt(.text+0x6374): undefined reference to `strcpy'
waba.elf2flt(.text+0x6384): undefined reference to `readdir'
waba.elf2flt(.text+0x63de): undefined reference to `free'
waba.elf2flt(.text+0x63e4): undefined reference to `free'
waba.elf2flt: In function `FileReadWriteBytes':
waba.elf2flt(.text+0x6458): undefined reference to `read'
waba.elf2flt(.text+0x6466): undefined reference to `write'
waba.elf2flt: In function `TimeCreate':
waba.elf2flt(.text+0x65d8): undefined reference to `gettimeofday'
waba.elf2flt(.text+0x65de): undefined reference to `time'
waba.elf2flt(.text+0x65ea): undefined reference to `localtime'
waba.elf2flt: In function `VmGetUserName':
waba.elf2flt(.text+0x671a): undefined reference to `geteuid'
waba.elf2flt(.text+0x6720): undefined reference to `getpwuid'
waba.elf2flt: In function `VmPrint':
waba.elf2flt(.text+0x676e): undefined reference to `printf'
waba.elf2flt(.text+0x6774): undefined reference to `stdout'
waba.elf2flt(.text+0x677c): undefined reference to `fflush'
waba.elf2flt: In function `VmPrintLn':
waba.elf2flt(.text+0x67b0): undefined reference to `printf'
waba.elf2flt: In function `prerror':
waba.elf2flt(.text+0x6876): undefined reference to `printf'
waba.elf2flt(.text+0x68e2): undefined reference to `printf'
waba.elf2flt(.text+0x68f2): undefined reference to `printf'
waba.elf2flt: In function `hwr_init':
waba.elf2flt(.text+0x6916): undefined reference to `malloc'
waba.elf2flt: In function `ui_MainLoop':
waba.elf2flt(.text+0x69e6): undefined reference to `printf'
waba.elf2flt: In function `ui_FontCreate':
waba.elf2flt(.text+0x6a1c): undefined reference to `malloc'
waba.elf2flt: In function `ui_FontDelete':
waba.elf2flt(.text+0x6a2c): undefined reference to `free'
collect2: ld returned 1 exit status
make[3]: *** [waba] Error 1
make[3]: Leaving directory 
`/home/fabien/dimm/uClinux-coldfire/others_softs/waba/waba-build/vm'
***********************************************



>> 
>>> i have download waba and i try to compile it.
>>> The README.uClinux talk about m68k-coff-gcc !! i d'ont have this 
>>> compiler, for my processor, I use m68k-elf-gcc. I try to
>> 
>> 
>> That's okay.
>>  
>> 
>>> configure with the command line :
>>>        ./configure --target=m68k --with-prefix=m68k-elf --with-nogui
>>> and there is this error:
>> 
>> 
>>>    checking for gcc... m68k-elf-gcc
>>>    checking whether the C compiler (m68k-elf-gcc  ) works... no
>>>    configure: error: installation or configuration problem: C compiler
>>> cannot create executables.
>> 
>> 
>>  
>> Have a look through the config.log file (it'll be in the same 
>> directory as
>> you ./configure'd in. That should point you to the problem (if not, post
>> your config.log here).
> 
> 
> thanks, now, ./configure succes but i have some error when i try to 
> compile. I will try to fix it
> fabien
> 
>> Mark
>> This message resent by the uclinux-dev at uclinux.org list server 
>> http://www.uClinux.org/
>> 
>> 
> 
> This message resent by the uclinux-dev at uclinux.org list server 
> http://www.uClinux.org/
> 
> 

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From tahir at snom.de  Thu Apr 25 08:24:49 2002
From: tahir at snom.de (Usman Tahir)
Date: Thu, 25 Apr 2002 14:24:49 +0200
Subject: [uClinux-dev] newbie : java on uClinux : link problem
References: <579C0CAF497CD511AD4D00508BBD7AAC0246F1@pikachu.ntu.ac.uk> <3CC6E1C9.9060708@netceler.com> <3CC7DF3E.4000703@netceler.com>
Message-ID: <3CC7F591.9C7EB9D2@snom.de>

Hi,

Look like the usual elf2flt errors. Try using (CXX) instead of (CC) in
the Makefile i.e. m68k-elf-g++ instead of m68k-elf-gcc in the command
line (don't forget -m5XXX option), if you have some c++ sources. Also
check libc (-lc) & libgcc (-lgcc), as I had problems becuase of invalid
linking with libc.

Regards,
Usman.




Fabien More wrote:
> 
> New problems when I try to compile waba
> I use le sommand line :
> *************************************
> m68k-elf-gcc  -O2   -fPIC -DWITH_THREAD=1 -DLINUX=1 -DGUI_NONE=1
> -DPLATFORM="\"Linux_NONE\""  -m5307 -DCONFIG_COLDFIRE -Os -g
> -fomit-frame-pointer -Dlinux -D__linux__ -Dunix -D__uClinux__ -DEMBED
> -fno-builtin -msep-data -Wl,-elf2flt  -lc -o waba  waba.o linux/libnmwaba.a
> *************************************
> 
> and the error is:
> *************************************
> waba.elf2flt: In function `VmInit':
> waba.elf2flt(.text+0x1a2): undefined reference to `memset'
> waba.elf2flt(.text+0x1b0): undefined reference to `malloc'
> waba.elf2flt(.text+0x1c0): undefined reference to `malloc'
> waba.elf2flt(.text+0x1d8): undefined reference to `malloc'
> waba.elf2flt(.text+0x1fe): undefined reference to `free'
> waba.elf2flt(.text+0x212): undefined reference to `free'
> waba.elf2flt(.text+0x226): undefined reference to `free'
> waba.elf2flt(.text+0x234): undefined reference to `memset'
> .....
> make[3]: *** [waba] Error 1
> ..
> **************************************
> 
> I think the mistake can be in the command line but i dont know where?
> This command line is made by a Makefile...
> The full error is :
> *************************************
> make[3]: Entering directory
> `/home/fabien/dimm/uClinux-coldfire/others_softs/waba/waba-build/vm'
> m68k-elf-gcc  -O2   -fPIC -DWITH_THREAD=1 -DLINUX=1 -DGUI_NONE=1
> -DPLATFORM="\"Linux_NONE\""  -m5307 -DCONFIG_COLDFIRE -Os -g
> -fomit-frame-pointer -Dlinux -D__linux__ -Dunix -D__uClinux__ -DEMBED
> -fno-builtin -msep-data -Wl,-elf2flt  -lc -o waba  waba.o
> linux/libnmwaba.a
> waba.elf2flt: In function `VmInit':
> waba.elf2flt(.text+0x1a2): undefined reference to `memset'
2flt(.text+0x1fe): undefined reference to `free'
> waba.elf2flt(.text+0x212): undefined reference to `free'
..........................
..........................
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From yunus.altunbicak at eliar.com.tr  Thu Apr 25 08:21:49 2002
From: yunus.altunbicak at eliar.com.tr (Yunus Altunbicak)
Date: Thu, 25 Apr 2002 15:21:49 +0300
Subject: [uClinux-dev] newbie : java on uClinux : link problem
In-Reply-To: <3CC7DF3E.4000703@netceler.com>
References: <579C0CAF497CD511AD4D00508BBD7AAC0246F1@pikachu.ntu.ac.uk> <3CC6E1C9.9060708@netceler.com> <3CC7DF3E.4000703@netceler.com>
Message-ID: <02042515214901.01182@AyGozcusu>

On Thursday 25 April 2002 01:49 pm, you wrote:
> New problems when I try to compile waba
> I use le sommand line :
> *************************************
> m68k-elf-gcc  -O2   -fPIC -DWITH_THREAD=1 -DLINUX=1 -DGUI_NONE=1
> -DPLATFORM="\"Linux_NONE\""  -m5307 -DCONFIG_COLDFIRE -Os -g
> -fomit-frame-pointer -Dlinux -D__linux__ -Dunix -D__uClinux__ -DEMBED
> -fno-builtin -msep-data -Wl,-elf2flt  -lc -o waba  waba.o linux/libnmwaba.a
> *************************************
try this

m68k-elf-gcc  -O2   -fPIC -DWITH_THREAD=1 -DLINUX=1 -DGUI_NONE=1
-DPLATFORM="\"Linux_NONE\""  -m5307 -DCONFIG_COLDFIRE -Os -g
-fomit-frame-pointer -Dlinux -D__linux__ -Dunix -D__uClinux__ -DEMBED
-fno-builtin -msep-data -Wl,-elf2flt  -o waba  waba.o linux/libnmwaba.a -lc

Regards,

-- 
Yunus Yucel Altunbicak
Eliar A.S.--R&D
http://www.eliar.com.tr
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From PaulMBanasik at eaton.com  Thu Apr 25 09:03:59 2002
From: PaulMBanasik at eaton.com (Banasik, Paul M)
Date: Thu, 25 Apr 2002 09:03:59 -0400
Subject: [uClinux-dev] make dep error under Cygwin
Message-ID: <2A8FE75B9F9D92449D13A4A6E391A7D2030F6F57@pitpasmb04.ch.etn.com>

If you go into the Makefile, look for expressions that are quoted using ` `
marks.  Replace these with ' ' and things should work better.  I don't know
why this is, but it worked for me.

Paul B.

-----Original Message-----
From: Valera [mailto:valera at soling.ur.ru]
Sent: Thursday, April 25, 2002 4:55 AM
To: uclinux-dev at uclinux.org
Subject: [uClinux-dev] make dep error under Cygwin


Please, help me.
I use uClinux-dist-20020411.tar.gz and Cygwin.

make config (by default for m5272c3) is okey, but make dep failed with
message:

>make dep
make -C linux-2.4.x dep
make[1]: Entering directory `/uClinux-dist/linux-2.4.x'
scripts/mkdep -- init/*.c > .depend
scripts/mkdep -- `find /uClinux-dist/linux-2.4.x/include/asm
/uClinux-dist/linux-2.4.x/include/linux
/uClinux-dist/linux-2.4.x/include/scsi
/uClinux-dist/linux-2.4.x/include/net -name SCCS -prune -o -follow -name
\*.h ! -name modversions.h -print` > .hdepend
scripts/mkdep: error 22
make[1]: *** [dep-files] Error1
make[1]: Leaving directory `/uClinux-dist/linux-2.4.x'
make: *** [dep] Error2

where problems?

Valery

This message resent by the uclinux-dev at uclinux.org list server
http://www.uClinux.org/
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From gerg at snapgear.com  Thu Apr 25 09:32:00 2002
From: gerg at snapgear.com (gerg)
Date: Thu, 25 Apr 2002 23:32:00 +1000
Subject: [uClinux-dev] munmap of non-mapped memory by process
References: <000001c1ec37$13be9ca0$7606140a@future.futsoft.com>
Message-ID: <3CC80550.D1793F1C@snapgear.com>


Hi Prasanna,

Prasanna Rao K wrote:
>  Any body has the idea why the following message arrives when we run our
> exe.
> 
> "munmap of non-mapped memory by process 10".
> 
> What is the cause for above message, is it due to misuse of some pointer?

Most common cause of this is that you are calling free() with
a pointer that was not allocated with malloc().

Regards
Grweg


------------------------------------------------------------------------
Greg Ungerer  --  Chief Software Wizard        EMAIL:  gerg at snapgear.com
Snapgear                                       PHONE:    +61 7 3279 1822
825 Stanley St,                                  FAX:    +61 7 3279 1820
Woolloongabba, QLD, 4102, Australia              WEB:   www.snapgear.com
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From gerg at snapgear.com  Thu Apr 25 09:38:13 2002
From: gerg at snapgear.com (gerg)
Date: Thu, 25 Apr 2002 23:38:13 +1000
Subject: [uClinux-dev] problem to wake up a thread in the kernel
References: <3CC6B0F9.9050108@actimage.fr> <3CC6BE50.2526EC6D@snapgear.com> <3CC6D810.8030000@actimage.fr>
Message-ID: <3CC806C5.DDC565D3@snapgear.com>


Hi Olivier,

Olivier PIERRAT wrote:
> Thank you, I have make a stupid mistake. I find it with the gdb.
> 
> In fact I have some problems and strange characters display in the boot
> message when I add some printk to debug the thread (eg, the priority,
> timer value, ...). Do you know what is the problem ? Is it possible to
> perform printk inside the thread without disturbing the kernel ?

Generally you can use printk anywhere. It uses polled serial
output (not interrupts), so provided its underlying UART
driving code is correct it should pretty much always work.

The kernel will be disturbed in so much as interrupts
are turned off while the UART output is occurring.
And this can be for a quite considerable amount of time,
depending on the baud rate in use on the console serial
port.

Can you send some output trace showing the problem?

Regards
Greg


------------------------------------------------------------------------
Greg Ungerer  --  Chief Software Wizard        EMAIL:  gerg at snapgear.com
Snapgear Pty Ltd                               PHONE:    +61 7 3279 1822
825 Stanley St,                                  FAX:    +61 7 3279 1820
Woolloongabba, QLD, 4102, Australia              WEB:   www.snapgear.com
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From udc at naftan.by  Thu Apr 25 10:32:05 2002
From: udc at naftan.by (Yurij Sysoev)
Date: Thu, 25 Apr 2002 17:32:05 +0300
Subject: [uClinux-dev] make dep error under Cygwin
References: <2A8FE75B9F9D92449D13A4A6E391A7D2030F6F57@pitpasmb04.ch.etn.com>
Message-ID: <3CC81365.2050003@naftan.by>

Hi,

Banasik, Paul M wrote:

> If you go into the Makefile, look for expressions that are quoted using ` `
> marks.  Replace these with ' ' and things should work better.  I don't know


Wow! It's TRUE! It WORK!
Many thanks, Paul!

Yurij


This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From hamilton at SEDSystems.ca  Thu Apr 25 11:05:20 2002
From: hamilton at SEDSystems.ca (Kendrick Hamilton)
Date: Thu, 25 Apr 2002 09:05:20 -0600 (CST)
Subject: [uClinux-dev] Where to start?
In-Reply-To: <5.1.0.14.2.20020425100709.00c078c8@mail.2bright.net>
Message-ID: <Pine.LNX.4.44.0204250903220.3080-100000@sw-55.sedsystems.ca>

Does this processor have a memory management unit? If it does, you want to
look at Linux, not uClinux. There are small linux distributions you may
want to look at (midori for example).


On Thu, 25 Apr 2002, Ronald Wiplinger wrote:

> I am totally new to uClinux, so forgive me to ask that way.
>
> I don't know where to start!
>
> I got a board with a processor type GX from National Semiconductor
>
> Geode? GXm Processor
> Integrated x86 Solution with MMX Support
> General Description
>
> The National Semiconductor ? Geode? GXm processor
> is an advanced 32-bit x86 compatible processor offering
> high performance, fully accelerated 2D graphics, a 64-bit
> synchronous DRAM controller and a PCI bus controller,
> all on a single chip that is compatible with Intel?s MMX
> technology.
>
> I want to install a Compact Flash Card with Linux kernel 2.4.18 with IPv6
> enabled!!!
> The system should include:
> 1. Web browser
> 2. Similar thing to Pocket Word / Pocket Excel
>
> (and it should fit on the smallest available Flash card --- just kidding!)
>
> Principle I should replace a Windows CE system with Linux.
> Any hints are welcomed that I get the ball running.
>
> Thanks!
>
> bye
>
> Ronald
>
>
>
>   Ronald  Wiplinger
> Bright Networking Inc.
> 7F, 192-1, Sec. 3, Tatung Rd., Shijr City, Taipei, Taiwan, RoC
> Tel.: +886 2 8647-1685, Mobile +886 915 653-452, Fax: +886 2 8647-2002
>

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From davidm at snapgear.com  Thu Apr 25 19:09:08 2002
From: davidm at snapgear.com (David McCullough)
Date: Fri, 26 Apr 2002 09:09:08 +1000
Subject: [uClinux-dev] Getting rid of networking support
In-Reply-To: <B1F6452C89AFD411AE0800A0CC734C239DBBE5@EMAIL1>; from Fabrice_Gautier@sdesigns.com on Wed, Apr 24, 2002 at 07:46:39PM -0700
References: <B1F6452C89AFD411AE0800A0CC734C239DBBE5@EMAIL1>
Message-ID: <20020426090908.A7409@beast.internal.moreton.com.au>


Jivin Fabrice Gautier lays it down ...
> Hi,
> 
> When i compile my UClinux, i have disabled network support in the config
> file but I still have some core network files that are compiled and take
> about 28KB.
> 
> In the makefile in the net subdir some files are always compile, even if
> CONFIG_NET is not defined.
> 
> Is there a reason for that, or is it safe to complete eliminate those files?

Don't know really.  Which files are they ?

I'd say try it and see,  if tehy are needed the kernel won't build ;-)

Cheers,
Davidm

-- 
David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
davidm at snapgear.com  Fx: +61 7 3891 3630  825 Stanley St., W'gabba QLD 4102, Oz
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From davidm at snapgear.com  Thu Apr 25 20:44:55 2002
From: davidm at snapgear.com (David McCullough)
Date: Fri, 26 Apr 2002 10:44:55 +1000
Subject: [uClinux-dev] Sash ls and special files.
In-Reply-To: <B1F6452C89AFD411AE0800A0CC734C239DBBE7@EMAIL1>; from Fabrice_Gautier@sdesigns.com on Wed, Apr 24, 2002 at 10:35:06PM -0700
References: <B1F6452C89AFD411AE0800A0CC734C239DBBE7@EMAIL1>
Message-ID: <20020426104455.A29600@beast.internal.moreton.com.au>


Jivin Fabrice Gautier lays it down ...
> Hi,
> 
> When I do  ls -l /dev, the major numbers are correct but the minors are all
> zeros.
> 
> The problems seems to be that sash does a sprintf of the device number with
> a %d format string whereas the device number is 64bits.
> 
> Maybe its only a sprintf problem, but im not sure if this may implie other
> problem elsewhere
> 
> Does anyone else see this?

I just tried uClibc and uC-libc with the latest distro and both worked fine
for "ls /dev" on m68k.

IIRC you are using arm,  check the ARM specific libc headers.  The "dirent"
structure might be a good start.  Print the size of any structures/fields
used for this part of sash.  I seem to recall seeing this in the very early
days of uClinux-2.4 on m68k and is was (maybe ;-) related to directory
structures.

AFAIK,  the dev numbers are 32 bit.  There may be a kernel option to
override,  can't remember,

Cheers,
Davidm

-- 
David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
davidm at snapgear.com  Fx: +61 7 3891 3630  825 Stanley St., W'gabba QLD 4102, Oz
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From gerg at snapgear.com  Thu Apr 25 20:49:28 2002
From: gerg at snapgear.com (Greg Ungerer)
Date: Fri, 26 Apr 2002 10:49:28 +1000
Subject: [uClinux-dev] v850 update patch
References: <buo1yd416ci.fsf@mcspd15.ucom.lsi.nec.co.jp>
Message-ID: <3CC8A418.1010203@snapgear.com>


Hi Miles,

Applied.

Regards
Greg



Miles Bader wrote:
> Hi, this patch updates v850 stuff; could you apply it?
> 
> Thanks,
> 
> -Miles
> 
> 


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

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From gerg at snapgear.com  Thu Apr 25 20:56:21 2002
From: gerg at snapgear.com (Greg Ungerer)
Date: Fri, 26 Apr 2002 10:56:21 +1000
Subject: [uClinux-dev] v850 updates for uClinux-dist-20020425
References: <buosn5kyv7n.fsf@mcspd15.ucom.lsi.nec.co.jp>
Message-ID: <3CC8A5B5.2010105@snapgear.com>


Hi Miles,

Applied too.

Regards
Greg



Miles Bader wrote:
> Hi, these are some updates to the v850-specific parts of
> uClinux-dist-20020425; please apply.  This patch adds new files (which
> are not at the beginning of the patch).
> 
> Thanks,
> 
> -Miles



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

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From licz at neusoft.com  Thu Apr 25 21:05:14 2002
From: licz at neusoft.com (lcz)
Date: Fri, 26 Apr 2002 09:05:14 +0800
Subject: [uClinux-dev] ploblem about port uclinux 2.4
References: <001f01c1ebf3$3c070d80$c00376ca@lichangzhong>
 <3CC75B1A.F40E5459@analog.com>
Message-ID: <011101c1ecbe$6c0346e0$c00376ca@lichangzhong>


----- Original Message ----- 
From: "Justin Wojdacki" <justin.wojdacki at analog.com>
To: <uclinux-dev at uclinux.org>
Sent: Thursday, April 25, 2002 9:25 AM
Subject: Re: [uClinux-dev] ploblem about port uclinux 2.4


> lcz wrote:
> > 
> > Hi,
> > 
> > I am porting linux 2.4 kernel for dragonball VZ , it has run,but have a problem . when 'ls' list device file, major & minor number is wrong , major number are all zero , minor number are all major number , I found system call 'stat' return a wrong device number.
> > why?
> > 
> > kernel : 2.4.10 + uclinux patch uc2
> > sh: sash
> > filesystem : romfs
> > tool-chains : m68k-elf-20020410
> > 
> > Regards
> > lcz
> > 
> > This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/
> 
> Check what the kernel and uClibc think the size of struct dev is. I
> ran into the same problem, and the reason was that the type of struct
> dev was different between these two realms. 
> 
> -- 

How do you solve this problem ? what file do you modify?
I modify  'stat' struct, but it is not OK

Thanks

Regards

lcz

email: lcz at neusoft.com


This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From davidm at snapgear.com  Thu Apr 25 22:20:41 2002
From: davidm at snapgear.com (David McCullough)
Date: Fri, 26 Apr 2002 12:20:41 +1000
Subject: [uClinux-dev] Re: new shared library implementation trashage?
In-Reply-To: <buo8z7c1bnd.fsf@mcspd15.ucom.lsi.nec.co.jp>; from miles@lsi.nec.co.jp on Thu, Apr 25, 2002 at 04:27:02PM +0900
References: <200204242220.g3OMKHOY022779@skaro.internal.moreton.com.au> <buopu0o1ki9.fsf@mcspd15.ucom.lsi.nec.co.jp> <buo8z7c1bnd.fsf@mcspd15.ucom.lsi.nec.co.jp>
Message-ID: <20020426122041.A4904@beast.internal.moreton.com.au>


Jivin Miles Bader lays it down ...
> pauli at snapgear.com writes:
>  > Yes, the main program is shared library zero under the current
>  > implementation.  This is true even if the shared library support for
>  > flat files is compiled out of the kernel.  However it should only have
>  > meaning if your program is compiled with the new -mid-shared-library
>  > option and even then it won't mean much without the kernel option too.
> 
> What program is `-mid-shared-library' an option for?


Its a compiler option for the m68k compilers,  it shouldn't affect you
in any way.


>  > No it isn't trashing memory.  It is writing below what your program
>  > thinks is the beginning of its data segment, however the start of the
>  > data segment has been bumped up to accommodate this.
> 
> Where has the data segment been bumped up (I mean, in which program was
> a change made that does the bumping)?


binfmt_flat.c does the work here.


> Remember, I'm using a v850, so any tool changes you guys have made for
> the m68k/arm won't affect me.  [and in general, given the large number
> of architectures that uclinux supports, I think it's a bad thing to
> make a kernel change that requires tools changes on `non-affected'
> architectures, without at least, using a different version number for
> the flat files]


There was no change made to the building of the flat files or the format.
You should not have to modify any of your existing tools in any way.

Basically,  the "load to RAM" path in binfmt_flat.c was overlooked during
the shared library changes and we didn't pick up on it during testing as
all of our targets use PIC/XIP code and do not load to RAM.

A new version of binfmt_flat.c is on uClinux.org which has this fixed.
It passed the basic minimal testing that we gave it on RAM/GZIP/GZDATA
files,  all of which were affected by the bug.  Sorry for the pain it
caused :-(


Jivin Miles Bader lays it down ...
> I fixed my problem by adding the following patch to the linker-script
> that I use for user programs:
> 
> 
> diff -up elf2flt.ld.\~1\~ elf2flt.ld
> --- elf2flt.ld.~1~	Thu Apr 11 22:55:30 2002
> +++ elf2flt.ld	Thu Apr 25 16:06:00 2002
> @@ -31,6 +31,11 @@ SECTIONS {
>  		. = ALIGN(0x10) ;
>  		_etext = . ;
>          } > flatmem
> +	.shlib : {
> +		/* Reserve space for `shared library' info (though we don't
> +		   use it, the binfmt_flat loader still needs one slot).  */
> +		LONG (0);
> +	} > flatmem
>          .data : {
>                  . = ALIGN(0x4) ;
>                  _sdata = . ;
> 
> 
> Is this the right fix?

It's a suitable workaround,  the real fix is to get the latest
fs/binfmt_flat.c from CVS and try it out.  If it gives you any problems
at all let us know and we'll get it fixed ASAP,

Cheers,
Davidm

-- 
David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
davidm at snapgear.com  Fx: +61 7 3891 3630  825 Stanley St., W'gabba QLD 4102, Oz
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From miles at lsi.nec.co.jp  Thu Apr 25 22:48:50 2002
From: miles at lsi.nec.co.jp (Miles Bader)
Date: 26 Apr 2002 11:48:50 +0900
Subject: [uClinux-dev] Re: new shared library implementation trashage?
In-Reply-To: <20020426122041.A4904@beast.internal.moreton.com.au>
References: <200204242220.g3OMKHOY022779@skaro.internal.moreton.com.au>
	<buopu0o1ki9.fsf@mcspd15.ucom.lsi.nec.co.jp>
	<buo8z7c1bnd.fsf@mcspd15.ucom.lsi.nec.co.jp>
	<20020426122041.A4904@beast.internal.moreton.com.au>
Message-ID: <buou1pz9nu5.fsf@mcspd15.ucom.lsi.nec.co.jp>

David McCullough <davidm at snapgear.com> writes:
> It's a suitable workaround,  the real fix is to get the latest
> fs/binfmt_flat.c from CVS and try it out.  If it gives you any problems
> at all let us know and we'll get it fixed ASAP,

Hi, I looked at the patch to binfmt_flat.c, and note that the changes
end up doing a `memmove' of the data-segment to avoid the shared library
space.  Since all that is needed is a _single_ long [when MAX_SHARED_LIBS
== 1] this seems like a rather silly solution (especially from my point
of view, since I don't even use the shared library support).

Can the space needed by the shared library support be located elsewhere,
e.g., between data and bss?  Then it could be allocated without copying
anything.

Thanks,

-Miles
-- 
P.S.  All information contained in the above letter is false,
      for reasons of military security.
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From miles at lsi.nec.co.jp  Thu Apr 25 23:11:01 2002
From: miles at lsi.nec.co.jp (Miles Bader)
Date: 26 Apr 2002 12:11:01 +0900
Subject: [uClinux-dev] Re: new shared library implementation trashage?
In-Reply-To: <buou1pz9nu5.fsf@mcspd15.ucom.lsi.nec.co.jp>
References: <200204242220.g3OMKHOY022779@skaro.internal.moreton.com.au>
	<buopu0o1ki9.fsf@mcspd15.ucom.lsi.nec.co.jp>
	<buo8z7c1bnd.fsf@mcspd15.ucom.lsi.nec.co.jp>
	<20020426122041.A4904@beast.internal.moreton.com.au>
	<buou1pz9nu5.fsf@mcspd15.ucom.lsi.nec.co.jp>
Message-ID: <buoofg79mt6.fsf@mcspd15.ucom.lsi.nec.co.jp>

I wrote:
> Hi, I looked at the patch to binfmt_flat.c, and note that the changes
> end up doing a `memmove' of the data-segment to avoid the shared library
> space.  Since all that is needed is a _single_ long [when MAX_SHARED_LIBS
> == 1] this seems like a rather silly solution (especially from my point
> of view, since I don't even use the shared library support).

Hi again,

Ignore what I wrote above -- I looked more carefully and now I see that
it only does the memmove for gzipped executables, and they're so slow
already that I doubt the extra copy will have much impact.

Sorry for the misinformed complaint!

Thanks,

-Miles
-- 
"1971 pickup truck; will trade for guns"
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From valera at soling.ur.ru  Fri Apr 26 00:39:39 2002
From: valera at soling.ur.ru (Valera)
Date: Fri, 26 Apr 2002 09:39:39 +0500
Subject: [uClinux-dev] make dep error under Cygwin
References: <2A8FE75B9F9D92449D13A4A6E391A7D2030F6F57@pitpasmb04.ch.etn.com>
Message-ID: <000f01c1ecdc$60291570$dd00a8c0@valera>

> If you go into the Makefile, look for expressions that are quoted using `
`
> marks.  Replace these with ' ' and things should work better.  I don't
know
> why this is, but it worked for me.

No, in my Makefile no entering ``. Also, problem not in CR/LF.
I think a problem in Cygwin, moreover in make dependens.

See make dep logs:
/uClinux-dist/linux-2.4.x/include/net -name SCCS -prune -o -follow -name
\*.h ! -name modversions.h -print` > .hdepend
scripts/mkdep: error 22
make[1]: *** [dep-files] Error1

In other words, "make" can't make .hdepend which can containing dependens
for "make".

Any body considers otherwise? Please help me? :)





This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From davidm at snapgear.com  Fri Apr 26 01:07:42 2002
From: davidm at snapgear.com (David McCullough)
Date: Fri, 26 Apr 2002 15:07:42 +1000
Subject: [uClinux-dev] Re: new shared library implementation trashage?
In-Reply-To: <buoofg79mt6.fsf@mcspd15.ucom.lsi.nec.co.jp>; from miles@lsi.nec.co.jp on Fri, Apr 26, 2002 at 12:11:01PM +0900
References: <200204242220.g3OMKHOY022779@skaro.internal.moreton.com.au> <buopu0o1ki9.fsf@mcspd15.ucom.lsi.nec.co.jp> <buo8z7c1bnd.fsf@mcspd15.ucom.lsi.nec.co.jp> <20020426122041.A4904@beast.internal.moreton.com.au> <buou1pz9nu5.fsf@mcspd15.ucom.lsi.nec.co.jp> <buoofg79mt6.fsf@mcspd15.ucom.lsi.nec.co.jp>
Message-ID: <20020426150742.A23720@beast.internal.moreton.com.au>


Jivin Miles Bader lays it down ...
> I wrote:
> > Hi, I looked at the patch to binfmt_flat.c, and note that the changes
> > end up doing a `memmove' of the data-segment to avoid the shared library
> > space.  Since all that is needed is a _single_ long [when MAX_SHARED_LIBS
> > == 1] this seems like a rather silly solution (especially from my point
> > of view, since I don't even use the shared library support).
> 
> Hi again,
> 
> Ignore what I wrote above -- I looked more carefully and now I see that
> it only does the memmove for gzipped executables, and they're so slow
> already that I doubt the extra copy will have much impact.
> 
> Sorry for the misinformed complaint!

No problem,  glad someone is keeping an eye on it ;-)

I assume the new binfmt_flat fixed your problems ?

Cheers,
Davidm

-- 
David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
davidm at snapgear.com  Fx: +61 7 3891 3630  825 Stanley St., W'gabba QLD 4102, Oz
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From miles at lsi.nec.co.jp  Fri Apr 26 01:32:48 2002
From: miles at lsi.nec.co.jp (Miles Bader)
Date: 26 Apr 2002 14:32:48 +0900
Subject: [uClinux-dev] Re: new shared library implementation trashage?
In-Reply-To: <20020426150742.A23720@beast.internal.moreton.com.au>
References: <200204242220.g3OMKHOY022779@skaro.internal.moreton.com.au>
	<buopu0o1ki9.fsf@mcspd15.ucom.lsi.nec.co.jp>
	<buo8z7c1bnd.fsf@mcspd15.ucom.lsi.nec.co.jp>
	<20020426122041.A4904@beast.internal.moreton.com.au>
	<buou1pz9nu5.fsf@mcspd15.ucom.lsi.nec.co.jp>
	<buoofg79mt6.fsf@mcspd15.ucom.lsi.nec.co.jp>
	<20020426150742.A23720@beast.internal.moreton.com.au>
Message-ID: <buobsc79g8v.fsf@mcspd15.ucom.lsi.nec.co.jp>

David McCullough <davidm at snapgear.com> writes:
> I assume the new binfmt_flat fixed your problems ?

Er, no, actually it doesn't work -- I get bus errors for the first
executable (during execution of the program, not while the loader is
running).

Unfortunately in half an hour they're shutting down the file-servers
here for a week-long holiday, so I probably don't have time to find the
problem.  If you can find the problem, it'd be great, otherwise I'll
deal with it when I come back...  [Kind of annoying that the CVS version
won't work for a week, but oh well.]

Cheers,

-Miles
-- 
P.S.  All information contained in the above letter is false,
      for reasons of military security.
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From miles at lsi.nec.co.jp  Fri Apr 26 02:20:09 2002
From: miles at lsi.nec.co.jp (Miles Bader)
Date: 26 Apr 2002 15:20:09 +0900
Subject: [uClinux-dev] Re: new shared library implementation trashage?
In-Reply-To: <buobsc79g8v.fsf@mcspd15.ucom.lsi.nec.co.jp>
References: <200204242220.g3OMKHOY022779@skaro.internal.moreton.com.au>
	<buopu0o1ki9.fsf@mcspd15.ucom.lsi.nec.co.jp>
	<buo8z7c1bnd.fsf@mcspd15.ucom.lsi.nec.co.jp>
	<20020426122041.A4904@beast.internal.moreton.com.au>
	<buou1pz9nu5.fsf@mcspd15.ucom.lsi.nec.co.jp>
	<buoofg79mt6.fsf@mcspd15.ucom.lsi.nec.co.jp>
	<20020426150742.A23720@beast.internal.moreton.com.au>
	<buobsc79g8v.fsf@mcspd15.ucom.lsi.nec.co.jp>
Message-ID: <buo662f9e1y.fsf@mcspd15.ucom.lsi.nec.co.jp>

I wrote:
> Er, no, actually it doesn't work -- I get bus errors for the first
> executable (during execution of the program, not while the loader is
> running).

Well, I still don't fully understand what's going on, but here's some
observations:

  (1) Some relocations (in crt0.o) that should have happened didn't --
      the should-have-been-relocated instructions in memory after
      relocation are exactly those in the flat file, i.e., with a
      network-byte-order 32-bit offset in the instruction, rather than
      the real address.

  (2) Come to think of it, since relocations are calculated in elf2flt
      according to the memory layout in the elf2flt.ld linker script,
      they're going to _assume_ that the text segment and data segment
      are contiguous, and it seems to me that changing that at load-time
      like the recent patch to binfmt_flat.c did, is going to invalidate
      that assumption.  Am I wrong?

[please keep the CC: which is to my non-work email address, so I can
follow any conversation from home]

Thanks,

-Miles
-- 
Love is a snowmobile racing across the tundra.  Suddenly it flips over,
pinning you underneath.  At night the ice weasels come.  --Nietzsche
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From miles at lsi.nec.co.jp  Fri Apr 26 02:54:32 2002
From: miles at lsi.nec.co.jp (Miles Bader)
Date: 26 Apr 2002 15:54:32 +0900
Subject: [uClinux-dev] Re: new shared library implementation trashage?
In-Reply-To: <buo662f9e1y.fsf@mcspd15.ucom.lsi.nec.co.jp>
References: <200204242220.g3OMKHOY022779@skaro.internal.moreton.com.au>
	<buopu0o1ki9.fsf@mcspd15.ucom.lsi.nec.co.jp>
	<buo8z7c1bnd.fsf@mcspd15.ucom.lsi.nec.co.jp>
	<20020426122041.A4904@beast.internal.moreton.com.au>
	<buou1pz9nu5.fsf@mcspd15.ucom.lsi.nec.co.jp>
	<buoofg79mt6.fsf@mcspd15.ucom.lsi.nec.co.jp>
	<20020426150742.A23720@beast.internal.moreton.com.au>
	<buobsc79g8v.fsf@mcspd15.ucom.lsi.nec.co.jp>
	<buo662f9e1y.fsf@mcspd15.ucom.lsi.nec.co.jp>
Message-ID: <buo1yd39cgn.fsf@mcspd15.ucom.lsi.nec.co.jp>

Miles Bader <miles at lsi.nec.co.jp> writes:
>   (2) Come to think of it, since relocations are calculated in elf2flt
>       according to the memory layout in the elf2flt.ld linker script,
>       they're going to _assume_ that the text segment and data segment
>       are contiguous, and it seems to me that changing that at load-time
>       like the recent patch to binfmt_flat.c did, is going to invalidate
>       that assumption.  Am I wrong?

Ah, indeed, I was wrong:  calc_reloc should take care of that.  The
fact that relocations aren't getting done suggests that it's somehow
not working correctly (since it uses calc_reloc to find the address of
the relocatable word).

-Miles
-- 
Yo mama's so fat when she gets on an elevator it HAS to go down.
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From valera at soling.ur.ru  Fri Apr 26 03:58:33 2002
From: valera at soling.ur.ru (Valera)
Date: Fri, 26 Apr 2002 12:58:33 +0500
Subject: [uClinux-dev] Cygwin file names problem
Message-ID: <000a01c1ecf8$29c3b1e0$dd00a8c0@valera>

I was foudt next files which named DOS alike names.

ipt_mark.h
ipt_MARK.h
ipt_tos.h
ipt_TOS.h

Thuse, for Cygwin (DOS) file system this file overrided from "tar" archive and
source can't compile under Cygwin.

Valera

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20020426/8d61dde0/attachment.html>

From miles at lsi.nec.co.jp  Fri Apr 26 03:11:26 2002
From: miles at lsi.nec.co.jp (Miles Bader)
Date: 26 Apr 2002 16:11:26 +0900
Subject: [uClinux-dev] Re: new shared library implementation trashage?
In-Reply-To: <buo1yd39cgn.fsf@mcspd15.ucom.lsi.nec.co.jp>
References: <200204242220.g3OMKHOY022779@skaro.internal.moreton.com.au>
	<buopu0o1ki9.fsf@mcspd15.ucom.lsi.nec.co.jp>
	<buo8z7c1bnd.fsf@mcspd15.ucom.lsi.nec.co.jp>
	<20020426122041.A4904@beast.internal.moreton.com.au>
	<buou1pz9nu5.fsf@mcspd15.ucom.lsi.nec.co.jp>
	<buoofg79mt6.fsf@mcspd15.ucom.lsi.nec.co.jp>
	<20020426150742.A23720@beast.internal.moreton.com.au>
	<buobsc79g8v.fsf@mcspd15.ucom.lsi.nec.co.jp>
	<buo662f9e1y.fsf@mcspd15.ucom.lsi.nec.co.jp>
	<buo1yd39cgn.fsf@mcspd15.ucom.lsi.nec.co.jp>
Message-ID: <buowuuv7x41.fsf@mcspd15.ucom.lsi.nec.co.jp>

Ok, I found the problem; `reloc' was getting the wrong value, because
of a parenthesis nesting error.  Here's a patch, which makes things
work for me:


Index: fs/binfmt_flat.c
===================================================================
RCS file: /var/cvs/uClinux-2.4.x/fs/binfmt_flat.c,v
retrieving revision 1.21
diff -u -r1.21 binfmt_flat.c
--- fs/binfmt_flat.c	2002/04/26 01:43:52	1.21
+++ fs/binfmt_flat.c	2002/04/26 07:10:51
@@ -632,8 +632,8 @@
 
 		realdatastart = textpos + ntohl(hdr->data_start);
 		datapos = realdatastart + MAX_SHARED_LIBS * sizeof(unsigned long);
-		reloc = (unsigned long *) (textpos + ntohl(hdr->reloc_start)) +
-				MAX_SHARED_LIBS * sizeof(unsigned long);
+		reloc = (unsigned long *) (textpos + ntohl(hdr->reloc_start) +
+					   MAX_SHARED_LIBS * sizeof(unsigned long));
 		memp = textpos;
 
 #ifdef CONFIG_BINFMT_ZFLAT


-Miles
-- 
Would you like fries with that?
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From miles at lsi.nec.co.jp  Fri Apr 26 03:28:43 2002
From: miles at lsi.nec.co.jp (Miles Bader)
Date: 26 Apr 2002 16:28:43 +0900
Subject: [uClinux-dev] one more for the road
Message-ID: <buosn5i9avo.fsf@mcspd15.ucom.lsi.nec.co.jp>

Here's another little v850-specific patch, just to flush out my local
changes before the long holiday; please apply...

Thanks,

-Miles


-------------- next part --------------
A non-text attachment was scrubbed...
Name: uclinux-2.4-v850-20020426-dist.patch
Type: text/x-patch
Size: 6059 bytes
Desc: little v850 patch 20020426
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20020426/d66817e7/attachment.patch>
-------------- next part --------------


-- 
A zen-buddhist walked into a pizza shop and
said, "Make me one with everything."

From pierre.merlin at clarus-networks.fr  Fri Apr 26 03:35:28 2002
From: pierre.merlin at clarus-networks.fr (Pierre Merlin)
Date: Fri, 26 Apr 2002 09:35:28 +0200
Subject: [uClinux-dev] Where to start?
In-Reply-To: <Pine.LNX.4.44.0204250903220.3080-100000@sw-55.sedsystems.ca>
References: <Pine.LNX.4.44.0204250903220.3080-100000@sw-55.sedsystems.ca>
Message-ID: <200204260735.g3Q7ZSZ26406@service.netline2.fr>

I am also sort of new to uClinux (just suscribed to this list yesterday), and 
I was just about to ask the same kind of question as Ronald's. But then, 
seeing Kendrick's answer, I have some other questions rising in mind :

1) Is the MMU-less feature the only difference between uClinux and linux ?
   I would have thought that embedded micro-chips _can_ have an MMU 
   and that they have many other particularities like their small amount of
   memory, being diskless, no appealing need for a GUI...

2) If so, why is there seemingly a mmu support in the source tree ?
   I mean, what is directory /mm there for, when I see there's a /mmnommu ?

Regards,
Pierre Merlin

On Thursday 25 April 2002 17:05, Kendrick Hamilton wrote:
> Does this processor have a memory management unit? If it does, you want to
> look at Linux, not uClinux. There are small linux distributions you may
> want to look at (midori for example).
>
> On Thu, 25 Apr 2002, Ronald Wiplinger wrote:
> > I got a board with a processor type GX from National Semiconductor
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From s.schaefer at schaefer-edv.de  Fri Apr 26 03:30:26 2002
From: s.schaefer at schaefer-edv.de (Siegfried Schaefer)
Date: Fri, 26 Apr 2002 09:30:26 +0200
Subject: [uClinux-dev] make dep error under Cygwin
References: <2A8FE75B9F9D92449D13A4A6E391A7D2030F6F57@pitpasmb04.ch.etn.com> <000f01c1ecdc$60291570$dd00a8c0@valera>
Message-ID: <000401c1ecf4$3c3c6190$1746a8c0@mars>

Hello,
i have had the same problem. I am working under W2000. The error comes from
the mmap() function in mkdep.c which doesn't get the memory from the system.
I have tried to rewrite the function (as a quick shot, because i only want
to be able to compile anything) with standard  malloc() and free(). I have
also patched the makefile. Now i run through compilation, but the
.depend/.hdepend files have size 0. Is this correct (i got the linux.bin
anyway) ?

with best regards, Siegfried Schaefer
Schaefer EDV-Dienstleistungen und Softwareentwicklungen


----- Original Message -----
From: "Valera" <valera at soling.ur.ru>
To: <uclinux-dev at uclinux.org>
Sent: Friday, April 26, 2002 6:39 AM
Subject: Re: [uClinux-dev] make dep error under Cygwin


> > If you go into the Makefile, look for expressions that are quoted using
`
> `
> > marks.  Replace these with ' ' and things should work better.  I don't
> know
> > why this is, but it worked for me.
>
> No, in my Makefile no entering ``. Also, problem not in CR/LF.
> I think a problem in Cygwin, moreover in make dependens.
>
> See make dep logs:
> /uClinux-dist/linux-2.4.x/include/net -name SCCS -prune -o -follow -name
> \*.h ! -name modversions.h -print` > .hdepend
> scripts/mkdep: error 22
> make[1]: *** [dep-files] Error1
>
> In other words, "make" can't make .hdepend which can containing dependens
> for "make".
>
> Any body considers otherwise? Please help me? :)
>
>
>
>
>
> This message resent by the uclinux-dev at uclinux.org list server
http://www.uClinux.org/
>

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From kuochung at mail.iaa.ncku.edu.tw  Fri Apr 26 03:41:06 2002
From: kuochung at mail.iaa.ncku.edu.tw (=?big5?B?tsCw6rZ2?=)
Date: Fri, 26 Apr 2002 15:41:06 +0800
Subject: [uClinux-dev] How to setup pty on kernal files??????
Message-ID: <000e01c1ecf5$bf065350$70c9748c@pc2>

Hey....!!!
I can not see any option about setup pty when i 'make config'.
Are there  other ways to setup pty on kernal???
Or what can i do???

p.s my kernal is uclinux-2.0.x
            Kuo

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20020426/5a8ac955/attachment.html>

From se04729 at salleURL.edu  Fri Apr 26 03:58:33 2002
From: se04729 at salleURL.edu (Francesc Borrell Ros)
Date: Fri, 26 Apr 2002 09:58:33 +0200 (CEST)
Subject: [uClinux-dev] newbie question about time resolution
Message-ID: <Pine.LNX.4.44.0204260950420.3578-100000@cygnus.salleURL.edu>

	Hi all, I have a very basic question:

	What's the maximum time resolution I can get on uClinux. Using
gettimeofday() on the 2.0.3x kernel I can only measure thousands of
microseconds, so I'm afraid that if I use the function usleep(1) I'll be
sleeping for 10000 useconds.

	Does anyone know how can I improve the time resolution I'm
getting? Is there any funcions or parameter I'm missing?

	Thanks for any advice you can give me..

	Best regards

	Francesc

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From kuochung at mail.iaa.ncku.edu.tw  Fri Apr 26 04:29:29 2002
From: kuochung at mail.iaa.ncku.edu.tw (=?big5?B?tsCw6rZ2?=)
Date: Fri, 26 Apr 2002 16:29:29 +0800
Subject: [uClinux-dev] problem about busybox on uclinux!!!!
Message-ID: <000c01c1ecfc$7c623850$70c9748c@pc2>

Hi!! all
I have a problem with busybox on uclinux
I added a application,MAKEDEV, to busybox.
Make it  a binary file and download to my borad.
But when i restarted my borad, i got a errer message.

Kernel panic: Unknown data abort code 12582912 [pc=e9307d82,*pc=03003843]

What did that mean???

p.s:my kernel is uclinux-2.0.x
                Kuo        


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20020426/34b402ec/attachment.html>

From darmasakti at netscape.net  Fri Apr 26 04:57:00 2002
From: darmasakti at netscape.net (I. B. Darmasakti)
Date: Fri, 26 Apr 2002 04:57:00 -0400
Subject: [uClinux-dev] make dep error under Cygwin
Message-ID: <0E204804.4DE9AB9E.0E8E3DE9@netscape.net>

Hi, check this link below. Maybe it will solve your problems, good luck :-)
http://www.nanotech.wisc.edu/~khan/software/gnu-win32/cygwin-to-linux-cross-howto.txt

"Valera" <valera at soling.ur.ru> wrote:

>> If you go into the Makefile, look for expressions that are quoted using `
>`
>> marks. ?Replace these with ' ' and things should work better. ?I don't
>know
>> why this is, but it worked for me.
>
>No, in my Makefile no entering ``. Also, problem not in CR/LF.
>I think a problem in Cygwin, moreover in make dependens.
>
>See make dep logs:
>/uClinux-dist/linux-2.4.x/include/net -name SCCS -prune -o -follow -name
>\*.h ! -name modversions.h -print` > .hdepend
>scripts/mkdep: error 22
>make[1]: *** [dep-files] Error1
>
>In other words, "make" can't make .hdepend which can containing dependens
>for "make".
>
>Any body considers otherwise? Please help me? :)
>
>
>
>
>
>This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/
>


__________________________________________________________________
Your favorite stores, helpful shopping tools and great gift ideas. Experience the convenience of buying online with Shop at Netscape! http://shopnow.netscape.com/

Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From fmore at netceler.com  Fri Apr 26 05:14:48 2002
From: fmore at netceler.com (Fabien More)
Date: Fri, 26 Apr 2002 11:14:48 +0200
Subject: [uClinux-dev] newbie : java on uClinux : link problem
References: <579C0CAF497CD511AD4D00508BBD7AAC0246F1@pikachu.ntu.ac.uk> <3CC6E1C9.9060708@netceler.com> <3CC7DF3E.4000703@netceler.com> <02042515214901.01182@AyGozcusu>
Message-ID: <3CC91A88.2010101@netceler.com>

hi,
thanks, verry mutch
it's ok
the -lc option correspond to link with c library?

Regards,
fabien

Yunus Altunbicak wrote:

 > On Thursday 25 April 2002 01:49 pm, you wrote:
 >
 >> New problems when I try to compile waba
 >> I use le sommand line :
 >> *************************************
 >> m68k-elf-gcc  -O2   -fPIC -DWITH_THREAD=1 -DLINUX=1 -DGUI_NONE=1
 >> -DPLATFORM="\"Linux_NONE\""  -m5307 -DCONFIG_COLDFIRE -Os -g
 >> -fomit-frame-pointer -Dlinux -D__linux__ -Dunix -D__uClinux__ -DEMBED
 >> -fno-builtin -msep-data -Wl,-elf2flt  -lc -o waba  waba.o 
linux/libnmwaba.a
 >> *************************************
 >
 > try this
 >
 > m68k-elf-gcc  -O2   -fPIC -DWITH_THREAD=1 -DLINUX=1 -DGUI_NONE=1
 > -DPLATFORM="\"Linux_NONE\""  -m5307 -DCONFIG_COLDFIRE -Os -g
 > -fomit-frame-pointer -Dlinux -D__linux__ -Dunix -D__uClinux__ -DEMBED
 > -fno-builtin -msep-data -Wl,-elf2flt  -o waba  waba.o 
linux/libnmwaba.a -lc
 >
 > Regards,
 >


This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From fmore at netceler.com  Fri Apr 26 05:14:41 2002
From: fmore at netceler.com (Fabien More)
Date: Fri, 26 Apr 2002 11:14:41 +0200
Subject: [uClinux-dev] newbie : java on uClinux : link problem
References: <579C0CAF497CD511AD4D00508BBD7AAC0246F1@pikachu.ntu.ac.uk> <3CC6E1C9.9060708@netceler.com> <3CC7DF3E.4000703@netceler.com> <3CC7F591.9C7EB9D2@snom.de>
Message-ID: <3CC91A81.9090804@netceler.com>

 >
 >
 > Hi,
 >
 > Look like the usual elf2flt errors. Try using (CXX) instead of (CC) in
 > the Makefile i.e. m68k-elf-g++ instead of m68k-elf-gcc in the command
 > line (don't forget -m5XXX option), if you have some c++ sources. Also
 > check libc (-lc) & libgcc (-lgcc), as I had problems becuase of invalid
 > linking with libc.
 >
 > Regards,
 > Usman.

hi,
I have only c source files.
I try the command line with -lc option at the end of the command and it
compile successfull.
You think it's better to use m68k-elf-g++ than m68k-elf-gcc ?

Regards,
fabien

 >
 >
 >
 > Fabien More wrote:
 >
 >> New problems when I try to compile waba
 >> I use le sommand line :
 >> *************************************
 >> m68k-elf-gcc  -O2   -fPIC -DWITH_THREAD=1 -DLINUX=1 -DGUI_NONE=1
 >> -DPLATFORM="\"Linux_NONE\""  -m5307 -DCONFIG_COLDFIRE -Os -g
 >> -fomit-frame-pointer -Dlinux -D__linux__ -Dunix -D__uClinux__ -DEMBED
 >> -fno-builtin -msep-data -Wl,-elf2flt  -lc -o waba  waba.o 
linux/libnmwaba.a
 >> *************************************
 >>
 >> and the error is:
 >> *************************************
 >> waba.elf2flt: In function `VmInit':
 >> waba.elf2flt(.text+0x1a2): undefined reference to `memset'
 >> waba.elf2flt(.text+0x1b0): undefined reference to `malloc'
 >> waba.elf2flt(.text+0x1c0): undefined reference to `malloc'
 >> waba.elf2flt(.text+0x1d8): undefined reference to `malloc'
 >> waba.elf2flt(.text+0x1fe): undefined reference to `free'
 >> waba.elf2flt(.text+0x212): undefined reference to `free'
 >> waba.elf2flt(.text+0x226): undefined reference to `free'
 >> waba.elf2flt(.text+0x234): undefined reference to `memset'
 >> .....
 >> make[3]: *** [waba] Error 1
 >> ..
 >> **************************************
 >>
 >> I think the mistake can be in the command line but i dont know where?
 >> This command line is made by a Makefile...
 >> The full error is :
 >> *************************************
 >> make[3]: Entering directory
 >> `/home/fabien/dimm/uClinux-coldfire/others_softs/waba/waba-build/vm'
 >> m68k-elf-gcc  -O2   -fPIC -DWITH_THREAD=1 -DLINUX=1 -DGUI_NONE=1
 >> -DPLATFORM="\"Linux_NONE\""  -m5307 -DCONFIG_COLDFIRE -Os -g
 >> -fomit-frame-pointer -Dlinux -D__linux__ -Dunix -D__uClinux__ -DEMBED
 >> -fno-builtin -msep-data -Wl,-elf2flt  -lc -o waba  waba.o
 >> linux/libnmwaba.a
 >> waba.elf2flt: In function `VmInit':
 >> waba.elf2flt(.text+0x1a2): undefined reference to `memset'
 >
 > 2flt(.text+0x1fe): undefined reference to `free'
 >
 >> waba.elf2flt(.text+0x212): undefined reference to `free'
 >
 > ...........................
 > ...........................
 > This message resent by the uclinux-dev at uclinux.org list server 
http://www.uClinux.org/
 >
 >


This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From olivierp at actimage.fr  Fri Apr 26 05:08:11 2002
From: olivierp at actimage.fr (Olivier PIERRAT)
Date: Fri, 26 Apr 2002 11:08:11 +0200
Subject: [uClinux-dev] kernel compilation problem
Message-ID: <3CC918FB.7050009@actimage.fr>

Hi,

I work on a M5272C3 evaluation board, with a 2.039.1 kernel.
I launch in the init phasis of the kernel a new thread 'my_thread'. IIn 
my new thread I initialize a PIT timer 'static timer_list timer' with 
the function 'init_timer' which is defined as 'extern inline' in the 
'timer.h'. Everything seem all right on my computer. I can compile and 
run my thread.

But when I try to compile the kernel on another computer, I got a link 
error :

make[3]: Leaving directory 
`/mnt/data/Work/schiller/fred_basique/INFORMATIQUES/Code/FRED_PAD/dsa/ecg_amplifier'
m68k-elf-gcc -g -D__KERNEL__ -I/home/olivier/uClinux-dist/linux/include 
-c  -Werror 
-I/mnt/data/Work/schiller/fred_basique/INFORMATIQUES/Code/FRED_PAD 
-DFRED_DEBUG=1 -DFRED_DEBUG_LEVEL=1 dsakernel.c -o dsaker
m68k-elf-ld -g -o dsakernel.o -r ecg_amplifier/ecgamplifier.o 
dsakernel_temp.o
rm dsakernel_temp.o
make[2]: Leaving directory 
`/mnt/data/Work/schiller/fred_basique/INFORMATIQUES/Code/FRED_PAD/dsa'
m68k-elf-ld -g -T arch/m68knommu/platform/5272/MOTOROLA/ram.ld 
arch/m68knommu/platform/5272/MOTOROLA/crt0_ram.o init/main.o 
init/version.o \
         arch/m68knommu/kernel/kernel.o arch/m68knommu/mm/mm.o 
arch/m68knommu/platform/5272/platform.o kernel/kernel.o fs/fs.o 
ipc/ipc.o net/network.a mmnommu/mm.o 
/mnt/data/Work/schiller/fred_basique/INFORMAT
         fs/filesystems.a \
         drivers/block/block.a drivers/char/char.a drivers/net/net.a \
         /home/olivier/uClinux-dist/linux/lib/lib.a 
arch/m68knommu/lib/lib.a 
/usr/local/lib/gcc-lib/m68k-elf/2.95.3/./m5307/libgcc.a -o linux
make[1]: Leaving directory `/home/olivier/uClinux-dist/linux'
/mnt/data/Work/schiller/fred_basique/INFORMATIQUES/Code/FRED_PAD/dsa/dsakernel.o: 
In function `InitDsaTimer':
/mnt/data/Work/schiller/fred_basique/INFORMATIQUES/Code/FRED_PAD/dsa/dsakernel.c:184: 
undefined reference to `init_timer'
make[1]: *** [linux] Error 1
make: *** [subdirs] Error 1


What is the problem ? Is it due to the fact that the sources of my 
thread are not in the kernel directory ? I can't believe it, because I 
do exactly the same thing on my computer. Is it due to the fact I have 
an older uClinux distro on the other computer ?


Can anyone give me a clue ?

Thank you.

Olivier.

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From tahir at snom.de  Fri Apr 26 06:07:11 2002
From: tahir at snom.de (Usman Tahir)
Date: Fri, 26 Apr 2002 12:07:11 +0200
Subject: [uClinux-dev] newbie : java on uClinux : link problem
References: <579C0CAF497CD511AD4D00508BBD7AAC0246F1@pikachu.ntu.ac.uk> <3CC6E1C9.9060708@netceler.com> <3CC7DF3E.4000703@netceler.com> <3CC7F591.9C7EB9D2@snom.de> <3CC91A81.9090804@netceler.com>
Message-ID: <3CC926CF.2370EB82@snom.de>

Hi,

Your problem was the libc linking (-lc at the end), I had a similar one
as well. I dont think its better to use m68k-elf-g++ than m68k-elf-gcc
as gcc is a compiler collection containing g++. But I once had trouble
compiling some c++ sources with gcc and simply replacing it with g++
fixed that.

Regards,
Usman.


Fabien More wrote:

> 
> hi,
> I have only c source files.
> I try the command line with -lc option at the end of the command and it
> compile successfull.
> You think it's better to use m68k-elf-g++ than m68k-elf-gcc ?
> 
> Regards,
> fabien
>
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From udc at naftan.by  Fri Apr 26 06:32:43 2002
From: udc at naftan.by (Yurij Sysoev)
Date: Fri, 26 Apr 2002 13:32:43 +0300
Subject: [uClinux-dev] kernel compilation problem
References: <3CC918FB.7050009@actimage.fr>
Message-ID: <3CC92CCB.8020203@naftan.by>

Hi,

Olivier PIERRAT wrote:

> I launch in the init phasis of the kernel a new thread 'my_thread'. IIn 
> my new thread I initialize a PIT timer 'static timer_list timer' with 
> the function 'init_timer' which is defined as 'extern inline' in the 
> 'timer.h'. Everything seem all right on my computer. I can compile and 
> run my thread.


Hmmm...
This code don't have any sense (IMHO) - (in timer.h)
extern inline void init_timer(struct timer_list * timer)
{
....

The "static inline void init_timer(struct timer_list * timer)"
(and so on) must be correct.

Yurij


This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From olivierp at actimage.fr  Fri Apr 26 08:19:00 2002
From: olivierp at actimage.fr (Olivier PIERRAT)
Date: Fri, 26 Apr 2002 14:19:00 +0200
Subject: [uClinux-dev] kernel compilation problem
References: <3CC918FB.7050009@actimage.fr> <3CC92CCB.8020203@naftan.by>
Message-ID: <3CC945B4.7020804@actimage.fr>

Hi,



Yurij Sysoev wrote:

> Hi,
> 
> Olivier PIERRAT wrote:
> 
>> I launch in the init phasis of the kernel a new thread 'my_thread'. 
>> IIn my new thread I initialize a PIT timer 'static timer_list timer' 
>> with the function 'init_timer' which is defined as 'extern inline' in 
>> the 'timer.h'. Everything seem all right on my computer. I can compile 
>> and run my thread.
> 
> 
> 
> Hmmm...
> This code don't have any sense (IMHO) - (in timer.h)
> extern inline void init_timer(struct timer_list * timer)
> {
> .....


Yes I think so, but what I can not understand was : why it's working on 
my computer an not on another, with the same distro and tools chain 
version. And the init_timer function is used in differents modules 
compile with the kernel in the normal way.

I look for a reason in several news groups and in groups on the google 
site. I find two solutions :

- define the init_timer() function as static
- to use the compile option -O to perform optimization so that the 
compiler understand correctly the extern inline declaration.



> The "static inline void init_timer(struct timer_list * timer)"
> (and so on) must be correct.
> 
> Yurij
> 
> 
> This message resent by the uclinux-dev at uclinux.org list server 
> http://www.uClinux.org/

In fact,as I compile my thread from my project directory, I modify the 
Makefile and I add an option (-Werror) to the CFLAGS varaible. But I 
make a mistake in the name of the variable. That's why the kernel's 
options to compile were wrong (no -O option) and the extern inline 
option was not recognize :-).

Thanks for your help.

Olivier.

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From gerg at snapgear.com  Fri Apr 26 09:14:33 2002
From: gerg at snapgear.com (gerg)
Date: Fri, 26 Apr 2002 23:14:33 +1000
Subject: [uClinux-dev] Where to start?
References: <Pine.LNX.4.44.0204250903220.3080-100000@sw-55.sedsystems.ca> <200204260735.g3Q7ZSZ26406@service.netline2.fr>
Message-ID: <3CC952B9.A0E26EA5@snapgear.com>


Hi Pierre,

Pierre Merlin wrote:
> I am also sort of new to uClinux (just suscribed to this list yesterday), and
> I was just about to ask the same kind of question as Ronald's. But then,
> seeing Kendrick's answer, I have some other questions rising in mind :
> 
> 1) Is the MMU-less feature the only difference between uClinux and linux ?

Yes. That is what uClinux is all about, support for processors
that do not have memory management units.


>    I would have thought that embedded micro-chips _can_ have an MMU
>    and that they have many other particularities like their small amount of
>    memory, being diskless, no appealing need for a GUI...

All true, but this is more to do with how you configure Linux
and the things you choose to build around it. That is the great
thing about uClinux, you can use the same apps as standard Linux.


> 2) If so, why is there seemingly a mmu support in the source tree ?
>    I mean, what is directory /mm there for, when I see there's a /mmnommu ?

The uClinux kernel sources are patches against a standard linux source
tree.
No files are removed, only MMUless support added.

You can take a uClinux kernel source tree and build for your standard
desktop PC, and you will get the same result as if you started with
a standard Linux kernel source package.

This is a good thing. With the uClinux sources we try to make as
little change as possible. Long term goal is o be part of standard
Linux sources.

Regards
Greg


------------------------------------------------------------------------
Greg Ungerer  --  Chief Software Wizard        EMAIL:  gerg at snapgear.com
Snapgear Pty Ltd                               PHONE:    +61 7 3279 1822
825 Stanley St,                                  FAX:    +61 7 3279 1820
Woolloongabba, QLD, 4102, Australia              WEB:   www.snapgear.com
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From yunus.altunbicak at eliar.com.tr  Fri Apr 26 09:21:24 2002
From: yunus.altunbicak at eliar.com.tr (Yunus Altunbicak)
Date: Fri, 26 Apr 2002 16:21:24 +0300
Subject: [uClinux-dev] newbie : java on uClinux : link problem
In-Reply-To: <3CC91A88.2010101@netceler.com>
References: <579C0CAF497CD511AD4D00508BBD7AAC0246F1@pikachu.ntu.ac.uk> <02042515214901.01182@AyGozcusu> <3CC91A88.2010101@netceler.com>
Message-ID: <02042616212402.01323@AyGozcusu>


> the -lc option correspond to link with c library?

yes, you right.

Regards,

-- 
Yunus Yucel Altunbicak
Eliar A.S.--R&D
http://www.eliar.com.tr
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From olivierp at actimage.fr  Fri Apr 26 09:14:51 2002
From: olivierp at actimage.fr (Olivier PIERRAT)
Date: Fri, 26 Apr 2002 15:14:51 +0200
Subject: [uClinux-dev] problem to wake up a thread in the kernel
References: <3CC6B0F9.9050108@actimage.fr> <3CC6BE50.2526EC6D@snapgear.com> <3CC6D810.8030000@actimage.fr> <3CC806C5.DDC565D3@snapgear.com>
Message-ID: <3CC952CB.1060100@actimage.fr>

Hi Greg,

I capture the boot message and add at the beginning of the interesting 
line the '====>' tag.
The boot message is :

====================================================================
dBUG> go 0x20000


uClinux/COLDFIRE(m5272)
COLDFIRE port done by Greg Ungerer, gerg at snapgear.com
Flat model support (C) 1998,1999 Kenneth Albanowski, D. Jeff Dionne
Calibrating delay loop.. ok - 43.82 BogoMIPS
Memory available: 2776k/4096k RAM, 0k/0k ROM (392k kernel code, 164k data)
Swansea University Computer Society NET3.035 for Linux 2.0
NET3: Unix domain sockets 0.13 for Linux NET3.035.
Swansea University Computer Society TCP/IP for NET3.034
IP Protocols: ICMP, UDP, TCP
uClinux version 2.0.39.1 (olivier at linux) (gcc version 2.95.3 20010315 
(release)(ColdFire patches - 20010318 from 
http://fiddes.net/coldfire/)(-msep-data patches)) 20 Fri Apr 26 14:53:44 
CEST 2002
bdflush thread launch

=====>MY THREAD : thread launch

ColdFire internal UART serial driver version 1.00
ttyS0 at 0x10000100 (irq = 73) is a builtin ColdFire UART
ttyS1 at 0x10000140 (irq = 74) is a builtin ColdFire UART
Ramdisk driver initialized : 16 ramdisks of 4096K size
Blkmem copyright 1998,1999 D. Jeff Dionne
Blkmem copyright 1998 Kenneth Albanowski
Blkmem 1 disk images:
0: AB1C4-1381C3 (RO)
PPP: version 2.3.8 (demand dialling)
TCP compression code copyright 1989 Regents of the University of California
PPP line discipline registered.
SLIP: version 0.8.4-NET3.019-NEWTTY (dynamic channels, max=256).
CSLIP: code copyright 1989 Regents of the University of California.
FEC ENET Version 0.1, 00:cf:52:72:c3:01
fec: link up, 100 Mbps, Full-Duplex, auto complete
fec: PHY id 0x001378e1
VFS: Mounted root (romfs filesystem) readonly.

====>  00`3?0~0f0?`?`3?f<<`<?00`3?0~0f0????f?f????f???~<?Shell invoked 
to run file: /etc/rc

Command: hostname uClinux
Command: /bin/expand /etc/ramfs.img /dev/ram0
Command: mount -t proc proc /proc
Command: mount -t ext2 /dev/ram0 /var
Command: mkdir /var/tmp
Command: mkdir /var/log
Command: mkdir /var/run
Command: mkdir /var/lock
Command: ifconfig lo 127.0.0.1
Command: route add -net 127.0.0.0 netmask 255.0.0.0 lo
Command: dhcpcd -p -a eth0 &
[12]
Command: cat /etc/motd
Welcome to
           ____ _  _
          /  __| ||_|
     _   _| |  | | _ ____  _   _  _  _
    | | | | |  | || |  _ \| | | |\ \/ /
    | |_| | |__| || | | | | |_| |/    \
    |  ___\____|_||_|_| |_|\____|\_/\_/
    | |
    |_|

For further information check:
http://www.uclinux.org/

Exec?
Sash command shell (version 1.1.1)
/>

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

It is strange. I launch a new kernel thread with the function 
'kernel_thread()', just after the kswapd thread. In my new thread I make 
some printk. But I'm not sure it was a problem due to printk. Can it be 
due to the initialization of my thread ? Should I perform the 
initialization a little bit later ? In that case where can I perform it ?

My thread is :


int  mythread_Run(void * unused)
{

    // Initialize the thread behaviour
    current->session = 1;
    current->pgrp = 1;
    sprintf(current->comm,"%s", "my_thread");
    current->blocked = ~0UL;

    current->policy = SCHED_FIFO;
    current->priority = 20;

    //Create a dynamic timer
    InitTimer();   //2s

    //Thread core
    while (1)
    {
       printk("MY THREAD : Process wake up \n");
       interruptible_sleep_on(&my_thread_wait);
    }

    return 0;	
}


Do you have an idea ?


Thank you.

Olivier.
gerg wrote:

> Hi Olivier,
> 
> Olivier PIERRAT wrote:
> 
>> Thank you, I have make a stupid mistake. I find it with the gdb.
>> 
>> In fact I have some problems and strange characters display in the boot
>> message when I add some printk to debug the thread (eg, the priority,
>> timer value, ...). Do you know what is the problem ? Is it possible to
>> perform printk inside the thread without disturbing the kernel ?
> 
> 
> Generally you can use printk anywhere. It uses polled serial
> output (not interrupts), so provided its underlying UART
> driving code is correct it should pretty much always work.
> 
> The kernel will be disturbed in so much as interrupts
> are turned off while the UART output is occurring.
> And this can be for a quite considerable amount of time,
> depending on the baud rate in use on the console serial
> port.
> 
> Can you send some output trace showing the problem?
> 
> Regards
> Greg
> 
> 
> ------------------------------------------------------------------------
> Greg Ungerer  --  Chief Software Wizard        EMAIL:  gerg at snapgear.com
> Snapgear Pty Ltd                               PHONE:    +61 7 3279 1822
> 825 Stanley St,                                  FAX:    +61 7 3279 1820
> Woolloongabba, QLD, 4102, Australia              WEB:   www.snapgear.com
> This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From gerg at snapgear.com  Fri Apr 26 10:00:20 2002
From: gerg at snapgear.com (gerg)
Date: Sat, 27 Apr 2002 00:00:20 +1000
Subject: [uClinux-dev] problem to wake up a thread in the kernel
References: <3CC6B0F9.9050108@actimage.fr> <3CC6BE50.2526EC6D@snapgear.com> <3CC6D810.8030000@actimage.fr> <3CC806C5.DDC565D3@snapgear.com> <3CC952CB.1060100@actimage.fr>
Message-ID: <3CC95D74.42B2A833@snapgear.com>


Hi Olivier,

Olivier PIERRAT wrote:
> I capture the boot message and add at the beginning of the interesting
> line the '====>' tag.
> The boot message is :
> 
> ====================================================================
> dBUG> go 0x20000
> 
> uClinux/COLDFIRE(m5272)
[snip]
> VFS: Mounted root (romfs filesystem) readonly.
> 
> ====>  00`3?0~0f0?`?`3?f<<`<?00`3?0~0f0????f?f????f???~<?Shell invoked
> to run file: /etc/rc

At this point the serial port is being opened as a normal Linux
device, and this open will setup the port settings. 

Problem is that the kernel has been using it as a console up
to now (and will continue to). But if the kernel does printk
calls during the serial device open you may be trying to
output characters when the baud rate, or other parameters,
are not completely setup correctly.

This is really a bug in the mcfserial driver, in that it
doesn't cleanly deal with a port being both the console
and a standard Linux serial device.


> It is strange. I launch a new kernel thread with the function
> 'kernel_thread()', just after the kswapd thread. In my new thread I make
> some printk. But I'm not sure it was a problem due to printk. Can it be
> due to the initialization of my thread ? Should I perform the
> initialization a little bit later ? In that case where can I perform it ?

Check /proc/kmsg and see if your messages are clean in there.
I expect they should be good.

I don't think there is any real problem with your kernel thread.
Only the garbled output from printk. I suspect if you changed the
timing a little bit (waited a couple of more seconds) then you
would see the printk output you expect.

Regards
Greg



------------------------------------------------------------------------
Greg Ungerer  --  Chief Software Wizard        EMAIL:  gerg at snapgear.com
Snapgear Pty Ltd                               PHONE:    +61 7 3279 1822
825 Stanley St,                                  FAX:    +61 7 3279 1820
Woolloongabba, QLD, 4102, Australia              WEB:   www.snapgear.com
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From Sakai at cpqd.com.br  Fri Apr 26 10:06:42 2002
From: Sakai at cpqd.com.br (Sergio Massami Sakai)
Date: Fri, 26 Apr 2002 11:06:42 -0300
Subject: [uClinux-dev] link problems & osip
Message-ID: <7B3538F053C06142BF0AA9DF2D764AC606C38C@MAILSRV1.aquarius.cpqd.com.br>

Hi all,

Does anyone has compiled libosip in uClinux?
I?m trying to do that, but I?ve got some problems.

I?ve tried to use the same configure script used with normal Linux compilation of osip passing different values to CC, CFLAGS, LDFLAGS and LIBS:
#CC=m68k-elf-gcc STRIP=m68k-elf-strip CFLAGS=-m68000 LDFLAGS=-Wl,-elf2flt LIBS=-lc ./configure --target=m68k-elf --with-prefix=m68k-elf-

When I run the make command, everything is fine until:
#m68k-elf-gcc -shared  *.lo  -lc -lc  -Wl,-elf2flt -Wl,-soname -Wl, -o .libs/

So I?ve got a "no symbol_start" and many "relocation truncated" messages:
#/usr/local/m68k-elf/bin/ld.real: warning: cannot find entry symbol _start; defaulting to 00000000
#.libs/.elf2flt: In function `msg_setrecord_route':
#/home/sakai/apl/uclinux/libosip/libosip-0.7.8_test2/parser/hdr_recordroute.c:51: relocation truncated to fit: R_68K_PLT16 #list_add
...

And at the end:
...
#.libs/.elf2flt: In function `MD5_memset':
#/home/sakai/apl/uclinux/libosip/libosip-0.7.8_test2/parser/md5c.c:348: undefined reference to `main'
#collect2: ld returned 1 exit status
#make[2]: *** [libosipparser.la] Error 1
#make[2]: Leaving directory `/home/sakai/apl/uclinux/libosip/libosip-0.7.8_test2/parser'
#make[1]: *** [all-recursive] Error 1
#make[1]: Leaving directory `/home/sakai/apl/uclinux/libosip/libosip-0.7.8_test2'
#make: *** [all-recursive-am] Error 2

I?ve tried to repeat this operation placing -lc at the end of the command line but I had the same problem.

Does anyone has some idea about how to solve this problem?
What are these "symbol_start" and "relocation truncated" "problems"?

Regards,

	Sakai




This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From fmore at netceler.com  Fri Apr 26 10:57:14 2002
From: fmore at netceler.com (Fabien More)
Date: Fri, 26 Apr 2002 16:57:14 +0200
Subject: [uClinux-dev] newbie : java on uClinux : link problem
References: <579C0CAF497CD511AD4D00508BBD7AAC0246F1@pikachu.ntu.ac.uk> <02042515214901.01182@AyGozcusu> <3CC91A88.2010101@netceler.com> <02042616212402.01323@AyGozcusu>
Message-ID: <3CC96ACA.1020009@netceler.com>

Thanks all
It's ok, waba run correctly on my uClinux

Regards,
fabien

Yunus Altunbicak wrote:

>> the -lc option correspond to link with c library?
> 
> yes, you right.
> 
> Regards,
> 

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From hamilton at SEDSystems.ca  Fri Apr 26 11:24:01 2002
From: hamilton at SEDSystems.ca (Kendrick Hamilton)
Date: Fri, 26 Apr 2002 09:24:01 -0600 (CST)
Subject: [uClinux-dev] Maximum number of files a process can have open
In-Reply-To: <7FF1185EA0D3D511BC0500B0D0D0C24A1B5AC2@melexc01.ap.ilxi.net>
Message-ID: <Pine.LNX.4.44.0204260923220.1787-100000@sw-55.sedsystems.ca>

Thank you for the replies, I changed the constant in the kernel to 512
(with #ifdefs for our system).


On Fri, 19 Apr 2002, Steven Merrifield wrote:

> > 	We are using the 2.0.x kernel on a 68360. Our
> > application program
> > needs a lot of files open. The current limit is 128. We need
> > about 300.
> > Does anybody know where the limit is set or what all is
> > needed to change
>
>
> Hi Kendrick,
>
> Look at linux/fs/file_table.c:
>
> 	int max_files = NR_FILE;
>
> and then look in linux/include/linux/fs.h:
>
> You may need to change NR_OPEN, NR_INODE and NR_FILE
>
> steve
> This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/
>

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From Subashk at ami.com  Fri Apr 26 16:35:33 2002
From: Subashk at ami.com (Subash Kalbarga)
Date: Fri, 26 Apr 2002 16:35:33 -0400
Subject: [uClinux-dev] Strange problems from inittab but not while running from rc
Message-ID: <8CCBDD5583C50E4196F012E79439B45C6203CB@atl-ms1.megatrends.com>

 
Hi all
 
Is there any known reason for a process to work well from the shell as a
background process but not from inittab. I am having strange behavior
running from inittab (the strange behavior goes away with a printf when I
want to debug it) but from rc as a background process these issues never
happen?
 
Is there some advise on what I should look into?
 
Thanks in advance 
Subash
 
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20020426/449941cb/attachment.html>

From ilatypov at superbt.com  Fri Apr 26 16:57:29 2002
From: ilatypov at superbt.com (Ilguiz Latypov)
Date: Fri, 26 Apr 2002 16:57:29 -0400 (EDT)
Subject: [uClinux-dev] application's memory consumption
Message-ID: <Pine.LNX.4.44.0204261646030.32281-100000@server.superbt.com>


Hello,

I am investigating the memory consumption of a user space application.  
It's total of .text and .data sizes is only a half of the "size" field in
/proc/PID/statm:

   # ps
      75 root     S    hcid: processing events              
      77 root     R    ps 
   # cat /proc/75/statm
   564608 564608 0 191024 0 70864 0
   # 

I suspected that the extra 300K is taken by the malloc()ed buffers and 
added debug output into various parts of the application and some of its 
statically compiled libraries.  However, none of these exhibited 
superfluous memory allocation requests.

The content of /proc/PID/statm is almost the same in the very beginning of 
the main() function:

   Nov 30 00:13:48 sbt1000 user.info syslog: malloc stats in hcid.c 
   (336): 524224 524224 0 191024 0 70864 0  

Is it possible that memory allocation happens before the beginning of
main()?  The size of .bss segment is about 2K only.  I attached the
beginning of "objdump -xS hcid.gdb" output.

-- 
Ilguiz Latypov
software developer
SuperBT Canada, Inc
153 Union St. E.
Waterloo, Ontario N2J 1C4
Canada

GMT-4 day time tel.   +1 (519) 569-7818


=====================================================================
hcid.gdb:     file format elf32-m68k
hcid.gdb
architecture: m68k, flags 0x00000112:
EXEC_P, HAS_SYMS, D_PAGED
start address 0x00000008

Program Header:
    LOAD off    0x00002000 vaddr 0x00000000 paddr 0x00000000 align 2**13
         filesz 0x000340d0 memsz 0x00034984 flags rwx
private flags = 0:

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         0002ea30  00000000  00000000  00002000  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .data         000056a0  0002ea30  0002ea30  00030a30  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  2 .bss          000008b4  000340d0  000340d0  000360d0  2**2
                  ALLOC
  3 .stab         00001eb4  00000000  00000000  000360d0  2**2
                  CONTENTS, READONLY, DEBUGGING
  4 .comment      00001a40  0000554d  0000554d  00037f84  2**0
                  CONTENTS, READONLY
  5 .stabstr      00003699  00001eb4  00001eb4  000399c4  2**0
                  CONTENTS, READONLY, DEBUGGING
=====================================================================

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From Subashk at ami.com  Fri Apr 26 17:12:01 2002
From: Subashk at ami.com (Subash Kalbarga)
Date: Fri, 26 Apr 2002 17:12:01 -0400
Subject: [uClinux-dev] maximum size of executable
Message-ID: <8CCBDD5583C50E4196F012E79439B45C6203D1@atl-ms1.megatrends.com>

Hi all,
 
What is the maximum size of a executable in uClinux
 
I am on m5272 and I have a application that is 690k.
 
However when I do a ps I see only 384k? Is this OK?
 
For all other applications worth 16k on disk , I always see about 150k
reported on ps?
 
 
Thanks in advance
Subash
 
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20020426/91fe0772/attachment.html>

From kuochung at mail.iaa.ncku.edu.tw  Sat Apr 27 08:42:18 2002
From: kuochung at mail.iaa.ncku.edu.tw (=?big5?B?tsCw6rZ2?=)
Date: Sat, 27 Apr 2002 20:42:18 +0800
Subject: [uClinux-dev] How to setup pty on kernal files??????
References: <000e01c1ecf5$bf065350$70c9748c@pc2>
Message-ID: <001b01c1ede8$f7e3edb0$70c9748c@pc2>


  ----- Original Message ----- 
  From: ??? 
  To: uclinux-dev at uclinux.org 
  Sent: Friday, April 26, 2002 3:41 PM
  Subject: [uClinux-dev] How to setup pty on kernal files??????


  Hey....!!!
  I can not see any option about setup pty when i 'make config'.
  Are there  other ways to setup pty on kernal???
  Or what can i do???

  p.s my kernal is uclinux-2.0.x
              Kuo

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20020427/e7858e20/attachment.html>

From kuochung at mail.iaa.ncku.edu.tw  Sat Apr 27 08:42:09 2002
From: kuochung at mail.iaa.ncku.edu.tw (=?big5?B?tsCw6rZ2?=)
Date: Sat, 27 Apr 2002 20:42:09 +0800
Subject: [uClinux-dev] problem about busybox on uclinux!!!!
References: <000c01c1ecfc$7c623850$70c9748c@pc2>
Message-ID: <001301c1ede8$f597b3c0$70c9748c@pc2>


  ----- Original Message ----- 
  From: ??? 
  To: uclinux-dev at uclinux.org 
  Sent: Friday, April 26, 2002 4:29 PM
  Subject: [uClinux-dev] problem about busybox on uclinux!!!!


  Hi!! all
  I have a problem with busybox on uclinux
  I added a application,MAKEDEV, to busybox.
  Make it  a binary file and download to my borad.
  But when i restarted my borad, i got a errer message.

  Kernel panic: Unknown data abort code 12582912 [pc=e9307d82,*pc=03003843]

  What did that mean???

  p.s:my kernel is uclinux-2.0.x
                  Kuo        


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20020427/b1b04b75/attachment.html>

From kuochung at mail.iaa.ncku.edu.tw  Sat Apr 27 09:36:29 2002
From: kuochung at mail.iaa.ncku.edu.tw (=?big5?B?tsCw6rZ2?=)
Date: Sat, 27 Apr 2002 21:36:29 +0800
Subject: [uClinux-dev] problem for pppd on uClinux again....help!!!
Message-ID: <001001c1edf0$8a244010$70c9748c@pc2>

Hi.....
When I use 'ppp-on' on my board
It seems like no reaction with ppp-on.
And i check my ifconfig, it has these message:

ppp0 Link encap:Point-to-Point
        inet addr:[NONE SET]    POINT-to-POINT:[NONE SET]    MASK:[NONE SET]
        POINTOPOINT    NOARP    MULTICAST
        ................................................................not finish

It looks likes i didn't start pppd???
Or what can i do to solve this problem????
            Kuo


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20020427/28179f3e/attachment.html>

From gerg at snapgear.com  Sat Apr 27 09:52:45 2002
From: gerg at snapgear.com (gerg)
Date: Sat, 27 Apr 2002 23:52:45 +1000
Subject: [uClinux-dev] Strange problems from inittab but not while running 
 from rc
References: <8CCBDD5583C50E4196F012E79439B45C6203CB@atl-ms1.megatrends.com>
Message-ID: <3CCAAD2D.93EE3320@snapgear.com>


Hi Subash, 

Subash Kalbarga <subashk at ami.com>
> Is there any known reason for a process to work well from the shell as a background process but not
> from inittab. I am having strange behavior running from inittab (the strange behavior goes away
> with a printf when I want to debug it) but from rc as a background process these issues never
> happen?
> 
>Is there some advise on what I should look into?

Something to watch out for is that when apps are launched
from inittab they will not have a stdin, stdout or stderr
(no open file descriptors 0, 1 or 2). Whereas when started
from /etc/rc they will (at least this is true for the
standard uClinux init).

This can cause some pretty strange problems if you open
some files and then try to use printf...

Regards
Greg


------------------------------------------------------------------------
Greg Ungerer  --  Chief Software Wizard        EMAIL:  gerg at snapgear.com
Snapgear Pty Ltd                               PHONE:    +61 7 3279 1822
825 Stanley St,                                  FAX:    +61 7 3279 1820
Woolloongabba, QLD, 4102, Australia              WEB:   www.snapgear.com
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From uclinux at schoeldgen.de  Sat Apr 27 19:56:02 2002
From: uclinux at schoeldgen.de (Matthias Schoeldgen)
Date: Sun, 28 Apr 2002 01:56:02 +0200
Subject: [uClinux-dev] How to setup pty on kernal files??????
References: <000e01c1ecf5$bf065350$70c9748c@pc2> <001b01c1ede8$f7e3edb0$70c9748c@pc2>
Message-ID: <3CCB3A91.B383784C@schoeldgen.de>


Hi Kuo!
I think there is no support for pty in the older kernel versions.
It might be a good idea to take a look at the new 2.4.x tree.this might
also solve your other problems (with ppp and the busybox thing).

Cheers
matthias
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From kuochung at mail.iaa.ncku.edu.tw  Sun Apr 28 04:44:01 2002
From: kuochung at mail.iaa.ncku.edu.tw (???)
Date: Sun, 28 Apr 2002 16:44:01 +0800
Subject: [uClinux-dev] How to setup pty on kernal files??????
References: <000e01c1ecf5$bf065350$70c9748c@pc2> <001b01c1ede8$f7e3edb0$70c9748c@pc2> <3CCB3A91.B383784C@schoeldgen.de>
Message-ID: <001201c1ee90$db4a1050$70c9748c@pc2>

Hi  Matthias
I have downloaded uClinux-2.4.17-uc0.diff.gz.
(Is that right file for uclinux-2.4.x?????)
Because I am new for uClinux ,I don't know how to unpack the
uClinux-2.4.17-uc0.diff.

Regards
     Kuo



----- Original Message -----
From: "Matthias Schoeldgen" <uclinux at schoeldgen.de>
To: <uclinux-dev at uclinux.org>
Sent: Sunday, April 28, 2002 7:56 AM
Subject: Re: [uClinux-dev] How to setup pty on kernal files??????


>
> Hi Kuo!
> I think there is no support for pty in the older kernel versions.
> It might be a good idea to take a look at the new 2.4.x tree.this might
> also solve your other problems (with ppp and the busybox thing).
>
> Cheers
> matthias
> This message resent by the uclinux-dev at uclinux.org list server
http://www.uClinux.org/
>

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From uclinux at schoeldgen.de  Sun Apr 28 17:12:56 2002
From: uclinux at schoeldgen.de (Matthias Schoeldgen)
Date: Sun, 28 Apr 2002 23:12:56 +0200
Subject: [uClinux-dev] How to setup...
References: <000e01c1ecf5$bf065350$70c9748c@pc2> <001b01c1ede8$f7e3edb0$70c9748c@pc2> <3CCB3A91.B383784C@schoeldgen.de> <001201c1ee90$db4a1050$70c9748c@pc2>
Message-ID: <3CCC65D8.D2D91F81@schoeldgen.de>

Hi Kuo!
The diff file contains only changes against the standard source tree of linux.
Well... you could run your diff  file against a brandnew (vanilla) kernel from
ftp://ftp.kernel.org, but i don't recommend this way.
You  are far better off with the current tree at
http://www.uclinux.org/ports/coldfire/source.html
There you have the complete 2.4.17 uClinux kernel sources , the 2.0.38 kernel  sources
plus a lot of userland programs and an easy way to configure all. The guys did a fine job
to build this (thank you all !!). Only drawback is the size (a good 80MByte or so).
This is not only for the coldfire platform , so don't be fooled by this URL.
Untar this into a convenient directory (e.g. /opt/uclinux or /home/kuo).
You will need a elf-gcc cross toolchain for your platform. E.g. for my uCsimm with a
68EZ328 processor i am using the m68k-elf-gcc toolchain  running under  i386. This must
be untar'd into the root (/) directory of your development PC.

If you have access to CVS (i am not familiar with this), you could also check the CVS
repository.
You are then ready to configure, compile and run :-)

Good hacking!
Matthias
??? wrote:

> Hi  Matthias
> I have downloaded uClinux-2.4.17-uc0.diff.gz.
> (Is that right file for uclinux-2.4.x?????)
> Because I am new for uClinux ,I don't know how to unpack the
> uClinux-2.4.17-uc0.diff.
>
> Regards
>      Kuo



This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From pauli at snapgear.com  Sun Apr 28 18:30:31 2002
From: pauli at snapgear.com (pauli at snapgear.com)
Date: Mon, 29 Apr 2002 08:30:31 +1000
Subject: [uClinux-dev] Re: new shared library implementation trashage? 
In-Reply-To: Your message of "25 Apr 2002 13:12:39 +0900."
             <buou1q01knc.fsf@mcspd15.ucom.lsi.nec.co.jp> 
References: <buor8l5jw77.fsf@mcspd15.ucom.lsi.nec.co.jp> 
 <200204242057.g3OKvLOY001000@skaro.internal.moreton.com.au>  
 <buou1q01knc.fsf@mcspd15.ucom.lsi.nec.co.jp>
Message-ID: <200204282230.g3SMUVSH002700@skaro.internal.moreton.com.au>

Miles Bader wrote:

> Remember, I'm using a v850, so any tool changes you guys have made for
> the m68k/arm won't affect me.  [and in general, given the large number
> of architectures that uclinux supports, I think it's a bad thing to
> make a kernel change that requires tools changes on `non-affected'
> architectures, without at least, using a different version number for
> the flat files]

Dave's already responded here but I thought I'd emphasise that one of our goals was to have existing executables continue to operate as expected on all supported platforms.  That is, the the shared library changes to not interfere with what already existed.  Hopefully, we're closer to this now.

It does look like I stuffed up somewhat.  Not entirely unexpected given the myriad of possibilities I couldn't test :-(


Regards,

Pauli


This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From pauli at snapgear.com  Sun Apr 28 20:10:17 2002
From: pauli at snapgear.com (pauli at snapgear.com)
Date: Mon, 29 Apr 2002 10:10:17 +1000
Subject: [uClinux-dev] Shared libraries 
In-Reply-To: Your message of "Thu, 25 Apr 2002 10:11:35 +0200."
             <20020425081135.82114.qmail@web11201.mail.yahoo.com> 
References: <20020425081135.82114.qmail@web11201.mail.yahoo.com> 
Message-ID: <200204290010.g3T0AHSH012226@skaro.internal.moreton.com.au>

Hi all,

Stefan Heinzmann wrote:

> I'm new to the list, so forgive me if I missed something important. I
> found a contribution by Pauli from SnapGear posted on 2002-04-01
> regarding shared libraries on uClinux when I was trying to find
> information on how shared libraries are implemented in systems without
> virtual memory. I hope the posting date does not indicate that it is a
> joke.

I actually posted it on the 2nd.  Most people would have received it on the 
1st due to our time zone :-)  It definitely isn't a joke.


> Pauli describes a method that may well work, but I find it wanting
> (assuming that I have understood it correctly). There are too many
> compromises in there for my taste. The worst idea IMHO is the stealing
> of address bits. That is something Apple has already regretted in the
> history of 68k Macs.

As a Mac programmer in a previous life, I'm well aware of this ;-)
The simple truth is I couldn't think of a better way to do it without 
introducing substantial overheads.  I agree that the stealing of address bits 
isn't nice.  I'm happy that all the other limitations are not a real problem 
and I'm willing to live with the address limitation for the moment.  I can 
always take a few bits back again later -- we don't generally need full binary 
compatibility in the embedded space.  Source compatibility on the other hand...


> The operating system assigns sequential slot numbers to each loaded
> shared library, starting from 1. If a library gets unloaded, its slot
> can be reused by the next library that gets loaded, but loaded
> libraries keep their slot number until they get unloaded.

Immediately, a relocation record must now contain the target library's name or 
other reference rather than its ID and the OS is responsible for the 
translation.  This will cost space and probably a small amount of time.  Our 
scheme folds these together and saves space because of it.

More importantly, the GOT entries.  These are simply addresses.  We'd now have 
to output relocation records for *all* of these too (to identify the library 
the address comes from).  This would cost a fair chunk of space.  At present, 
we know about the GOT and automatically relocate it thus avoiding many 
relocation records.


> The shared library does not need to be compiled to use pc-relative
> addressing, since the dynamic linker knows where it will end up in the
> address space and can do the necessary relocations when loading the
> library. On the other hand, fewer relocations mean quicker loading, so
> pc-relative might still be a good idea.

>From experience, a pc-relative executable on the ColdFire takes up less space 
than a fully relocatable one.  Our flat file loader supports both formats and 
in general the extra relocations take more space than the overheads of 
supporting execute in place.  We get a slight performance boost by not 
executing in place but we've not needed this yet.

Also, going to absolute code loses the biggest win we've had: execute in place 
is a god-send.  It gains more than shared libraries in terms of cramming 
functionality into a small unit.  Sharing text segments is essential.  Sharing 
library is just an extra saving.  I don't think I can emphasise this enough.  
As soon as you've one absolute address in your text segment, this goes.


> The import table is set up by the dynamic linker; the application or
> the libraries only read from it. It contains pointers to the static
> data of each shared library. The offset into the table is calculated
> from the library's slot number (i.e. offset = slot_number*-4). A
> procedure in a shared library can thus get a pointer to its own static
> data with the following instruction:
>     MOVEA (offset,A5),Ax
> The dynamic linker needs to fix up the offset when loading the shared
> library (by which time it knows the slot number).

Another relocation type and even more relocation records.
One per procedure in fact.  More space.

What happens if the offset exceeds 32k?  Looks like we're now limited to a 32k 
data segment.  That is definitely not acceptable.  Okay, use multiple GOTs 
located together and access them the same way.  Now we're back to a 32k 
overall GOT limit.  More acceptable but significantly more restrictive then 
with our implementation of a 32k per library limit (remember shared libraries 
require more GOT entries than a stand alone program).

Now, do we make Ax A5 or something else?  If it is A5 then we've got the call 
back into the main program to concern ourselves with (the called back 
procedure has to set up A5).  If it isn't then we've lost another of our 
fairly precious Ax registers.  I went for the main program being PIC too to 
force the A5 reload.


> I can not currently see where this scheme breaks. It avoids several
> problems:
> -- No limit on the size of the application (no address bits stolen)
> -- No limit on the number of shared libraries
> -- No change for code that isn't in a shared library
> -- Shared libraries pay a small price for accessing static data
> -- Static data overhead is one import table per process

-- Requires a clever dynamic loader.

-- Uses more space.

-- Requires significantly larger modifications to existing tools and to the 
flat file loader and format.  Backward compatibility becomes an issue here 
(we're trying to not break existing build trees for any architecture.

-- Requires multiple passes over libraries and executables prior to loading a 
program.  We don't necessarily know what libraries are referenced ahead of 
time, we have to scan for them.  Think compressed binaries.  Solve this by 
breaking the data segment stuff into multiple chunks and allocating 
separately. Now we cannot use the proposed scheme for setting Ax up.


> Have I overlooked anything?

* There are a few problems, none of which are insurmountable but they will cause problems and they will be more troublesome to deal with.

* You will be paying space costs in several places.  Some of these are unlikely to be small.

* I'm probably being a little harsh with my comments ;-)

* Our scheme is already implemented.


>from what I've heard, the Ridge Run shared libraries for ARM uses elf format executables and libraries and avoid the limitations of our implementation.  If your problem is large enough to find our limitations limiting, there is an alternative already.


Regards,

Pauli


This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From davidm at snapgear.com  Sun Apr 28 21:10:59 2002
From: davidm at snapgear.com (David McCullough)
Date: Mon, 29 Apr 2002 11:10:59 +1000
Subject: [uClinux-dev] Re: new shared library implementation trashage?
In-Reply-To: <buowuuv7x41.fsf@mcspd15.ucom.lsi.nec.co.jp>; from miles@lsi.nec.co.jp on Fri, Apr 26, 2002 at 04:11:26PM +0900
References: <buopu0o1ki9.fsf@mcspd15.ucom.lsi.nec.co.jp> <buo8z7c1bnd.fsf@mcspd15.ucom.lsi.nec.co.jp> <20020426122041.A4904@beast.internal.moreton.com.au> <buou1pz9nu5.fsf@mcspd15.ucom.lsi.nec.co.jp> <buoofg79mt6.fsf@mcspd15.ucom.lsi.nec.co.jp> <20020426150742.A23720@beast.internal.moreton.com.au> <buobsc79g8v.fsf@mcspd15.ucom.lsi.nec.co.jp> <buo662f9e1y.fsf@mcspd15.ucom.lsi.nec.co.jp> <buo1yd39cgn.fsf@mcspd15.ucom.lsi.nec.co.jp> <buowuuv7x41.fsf@mcspd15.ucom.lsi.nec.co.jp>
Message-ID: <20020429111059.A8543@beast.internal.moreton.com.au>


Jivin Miles Bader lays it down ...
> Ok, I found the problem; `reloc' was getting the wrong value, because
> of a parenthesis nesting error.  Here's a patch, which makes things
> work for me:

Applied,  thanks,

Cheers,
Davidm

-- 
David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
davidm at snapgear.com  Fx: +61 7 3891 3630  825 Stanley St., W'gabba QLD 4102, Oz
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From licz at neusoft.com  Sun Apr 28 21:00:03 2002
From: licz at neusoft.com (lcz)
Date: Mon, 29 Apr 2002 09:00:03 +0800
Subject: [uClinux-dev] problem about mount ext2 filesystem in uclinux 2.4
Message-ID: <001201c1ef19$323305b0$c00376ca@lichangzhong>


Hi,All

I am porting 2.4 kernel, when i mount a ext2 filesystems,i get following error message:

/sbin/expand /ramfs.img /dev/ram0
mount -t ext2 /dev/ram0 /var

EXT2-fs: Unrecognized mount option <many unreadable chars>

i think expand and mount command  and ramfs.img are right(when i apply these command to linux 2.0.38, that is ok), i do not know whether ram0 device driver is right, or there are some other problems.

my system config:
 kernel: 2.4.10 + uclinux patch uc2
 sh: bash

thanks a lot


Regards
lcz 

Email:licz at neusoft.com
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From davidm at snapgear.com  Sun Apr 28 21:33:45 2002
From: davidm at snapgear.com (David McCullough)
Date: Mon, 29 Apr 2002 11:33:45 +1000
Subject: [uClinux-dev] one more for the road
In-Reply-To: <buosn5i9avo.fsf@mcspd15.ucom.lsi.nec.co.jp>; from miles@lsi.nec.co.jp on Fri, Apr 26, 2002 at 04:28:43PM +0900
References: <buosn5i9avo.fsf@mcspd15.ucom.lsi.nec.co.jp>
Message-ID: <20020429113345.A8626@beast.internal.moreton.com.au>


Jivin Miles Bader lays it down ...
> Here's another little v850-specific patch, just to flush out my local
> changes before the long holiday; please apply...

Applied,

Thanks,
Davidm

-- 
David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
davidm at snapgear.com  Fx: +61 7 3891 3630  825 Stanley St., W'gabba QLD 4102, Oz
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From anurag at USHUSTECH.COM  Mon Apr 29 02:08:33 2002
From: anurag at USHUSTECH.COM (Anurag.R)
Date: Mon, 29 Apr 2002 11:38:33 +0530
Subject: [uClinux-dev] Porting uClinux to Sh2-DSP
Message-ID: <79DD1BC58DD7AC418EC0D1D5B169ACB816506E@mail.ushustech.com>

Hi All
     I am very new to uClinux development. We would like to
port uClinux to Hitachi's Sh2-DSP(SE7616DSP) processor.
This processor doesn't support MMU.

We have a few doubts regarding this:
1. The target dependant areas of uClinux where we have to modify.
2. The tool chain required for this.

Thanks in advance

Regards
Anurag
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20020429/8a6c3699/attachment.html>

From kuochung at mail.iaa.ncku.edu.tw  Mon Apr 29 04:37:15 2002
From: kuochung at mail.iaa.ncku.edu.tw (=?big5?B?tsCw6rZ2?=)
Date: Mon, 29 Apr 2002 16:37:15 +0800
Subject: [uClinux-dev] problem with making uClinux-2.4.x
Message-ID: <000e01c1ef59$13e30f20$70c9748c@pc2>

Hi ,All
I have downloaded uClinux-dist,and there is a directory of linux-2.4.x. 
I want to make kernel of uClinux-2.4.x.
But i got error message below when i 'make' :

serial.c :327: 'RS_TABLE_SIZE' undeclared here.(Not in a function)
serial.c :327: warning : braces around scalar initializer.
serial.c :328: (near initialization for 'rs_table)

It seems something wrong with serial.c.
Is there a patch for this problem or what can i do for this error.
BTW,thank Matthias's help.
        Kuo


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20020429/747af9d1/attachment.html>

From mathias.fritzson at mecel.se  Mon Apr 29 05:32:03 2002
From: mathias.fritzson at mecel.se (mathias.fritzson at mecel.se)
Date: Mon, 29 Apr 2002 11:32:03 +0200
Subject: [uClinux-dev] Debugger and other stuff
Message-ID: <200204290930.g3T9Uws05751@uclinux.org>

Hi

A small thing, the company here that we are doing our thesis at has a nice
debugger "SingleStep" from Wind River, it works great except that it has a
hard time to follow the types for variabels, especially the complex ones,
structs and so on.. Has anyone managed to get this feature to work ?

And now to the heavy stuff..

We have an odd fault here, we have to have missed something in the port but
we have no clue what we have missed..

When we are finishing up the start_kernel function a couple of new threads
are activated if we got it right. Some whre in these taskswitches  the
stack blows out of proportions and becomes +32k large. The struct in
"current", in our case current_set,  is pointing all wrong. We've tried to
trace the problem but we're not completely sure where to look.. We havn't
found any good documentation about these task switches so we only got some
basic task knowlege no Linux specific.

I hope that you got some ideas =), we're slowly running out of them.

/Mathias


This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From mark.howson at ntu.ac.uk  Mon Apr 29 06:46:58 2002
From: mark.howson at ntu.ac.uk (Howson, Mark)
Date: Mon, 29 Apr 2002 11:46:58 +0100
Subject: [uClinux-dev] PCI problem with 5407C3 board and linux 2.0
Message-ID: <579C0CAF497CD511AD4D00508BBD7AAC0246F5@pikachu.ntu.ac.uk>

Hi,

I'm having trouble trying to get Linux to see the PCI slot on the MCF5407C3
board. I've enabled CONFIG_PCI, but I get the following:

>>>
uClinux/COLDFIRE(m5407)
COLDFIRE port done by Greg Ungerer, gerg at snapgear.com
Flat model support (C) 1998,1999 Kenneth Albanowski, D. Jeff Dionne
PCI: no PCI bus present
pci_init: no BIOS32 detected
Calibrating delay loop.. ok - 149.50 BogoMIPS
Memory available: 30400k/32768k RAM, 0k/0k ROM (391k kernel code, 171k data)
...

I've tried changing jumper settings, power supplies, PCI cards in/out, etc -
no luck. Is anyone using the PCI slot of the 5407?

Thanks,
Mark
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From fmore at netceler.com  Mon Apr 29 06:56:39 2002
From: fmore at netceler.com (Fabien More)
Date: Mon, 29 Apr 2002 12:56:39 +0200
Subject: [uClinux-dev] newbie : asm compiler
References: <000e01c1ecf5$bf065350$70c9748c@pc2> <001b01c1ede8$f7e3edb0$70c9748c@pc2> <3CCB3A91.B383784C@schoeldgen.de>
Message-ID: <3CCD26E7.6070703@netceler.com>

Hi,

I'm new in uClinux on Coldfire.
I would like to find some documentation on make and compile ASM programm 
for motorola m68k-coldfire.

Regards,
fabien

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From kuochung at mail.iaa.ncku.edu.tw  Mon Apr 29 08:50:22 2002
From: kuochung at mail.iaa.ncku.edu.tw (=?big5?B?tsCw6rZ2?=)
Date: Mon, 29 Apr 2002 20:50:22 +0800
Subject: [uClinux-dev] No ARM Support for kernel uClinux-2.4.x !!!???
Message-ID: <003c01c1ef7c$7d345790$70c9748c@pc2>

Hi
I have downloaded uClinux-dist,and there is a directory of linux-2.4.x. 
I want to make kernel of uClinux-2.4.x.
Because my microprocessor is ARM7TDMI
But when i 'make xconfig',
I can not find ARM microprocessor in hardware support menu
 Does anyboby know there any patch for ARM ???
 Or what Should I do??
            Kuo
    
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20020429/8c73ebd5/attachment.html>

From fmore at netceler.com  Mon Apr 29 09:45:21 2002
From: fmore at netceler.com (Fabien More)
Date: Mon, 29 Apr 2002 15:45:21 +0200
Subject: [uClinux-dev] newbie : c compilation problem
References: <000e01c1ecf5$bf065350$70c9748c@pc2> <001b01c1ede8$f7e3edb0$70c9748c@pc2> <3CCB3A91.B383784C@schoeldgen.de> <3CCD26E7.6070703@netceler.com>
Message-ID: <3CCD4E71.4050703@netceler.com>

Hi,

i've got a problem when i try to compile a c file.
I use the command line:
********************************
m68k-elf-g++ -O4 -Wall -DJ2ME_VERSION_STRING='"1.0fcs-ar"' 
-DJ2ME_PRODUCT_NAME='"CDC"' -DJ2ME_CLASSESJAR='"../lib/cdc.jar"' 
-DCVM_DEBUG_STACKTRACES -DCVM_CLASSLOADING -DCVM_SERIALIZATION 
-DCVM_REFLECT -DCVM_DYNAMIC_LINKING -D_GNU_SOURCE -DHAVE_64_BIT_IO 
-I../../src/share -I../../src/uClinux -I../../build/uClinux  
-I../../src/share/javavm/export -I../../src/share/native/common 
-I../../src/share/native/java/lang 
-I../../src/share/native/java/lang/fdlibm/include 
-I../../src/share/native/java/net -I../../src/share/native/java/io 
-I../../src/share/native/java/util/zip/zlib-1.1.3 
-I../../src/uClinux/native/java/net -I../../src/uClinux/native/java/util 
-I../../build/uClinux/generated/jni  -I../../src -m5307 
-DCONFIG_COLDFIRE -Os -g -fomit-frame-pointer -Dlinux -D__linux__ -Dunix 
-D__uClinux__ -DEMBED 
-I/home/fabien/dimm/uClinux-coldfire/lib/libc/include 
-I/home/fabien/dimm/uClinux-coldfire/lib/libm 
-I/home/fabien/dimm/uClinux-coldfire 
-I/home/fabien/dimm/uClinux-coldfire/linux-2.4.x/include 
-I/home/fabien/dimm/uClinux-coldfire/uClibc/include  -fno-builtin 
-msep-data  -c -o ../../build/uClinux/obj/gen_semispace.o 
../../src/share/javavm/runtime/gc/generational/gen_semispace.c

***************************************************

the error is:
*************************************************
In file included from 
/home/fabien/dimm/uClinux-coldfire/uClibc/include/pthread.h:20,
                from ../../src/porting/posix/sync.h:14,
                from ../../src/uClinux/javavm/include/sync_md.h:18,
                from ../../src/share/javavm/include/porting/sync.h:167,
                from ../../src/share/javavm/include/sync.h:16,
                from ../../src/share/javavm/include/objects.h:24,
                from 
../../src/share/javavm/runtime/gc/generational/gen_semispace.c:17:
/home/fabien/dimm/uClinux-coldfire/uClibc/include/sched.h: In function 
`int sched_setparam(int, const sched_param *)':
/home/fabien/dimm/uClinux-coldfire/uClibc/include/sched.h:40: parse 
error before `;'
/home/fabien/dimm/uClinux-coldfire/uClibc/include/sched.h:40: ANSI C++ 
forbids declaration `__THROW' with no type
/home/fabien/dimm/uClinux-coldfire/uClibc/include/sched.h:40: confused 
by earlier errors, bailing out
make[1]: *** [../../build/uClinux/obj/gen_semispace.o] Error 1
make: *** [all] Error 1
*************************************************************

I don't know what is __THROW and what is the mistake.


this is the sched.h file:
**********************************************************
/* Definitions for POSIX 1003.1b-1993 (aka POSIX.4) scheduling interface.
  Copyright (C) 1996, 1997, 1999, 2001 Free Software Foundation, Inc.
  This file is part of the GNU C Library.

  The GNU C Library is free software; you can redistribute it and/or
  modify it under the terms of the GNU Lesser General Public
  License as published by the Free Software Foundation; either
  version 2.1 of the License, or (at your option) any later version.

  The GNU C Library is distributed in the hope that it will be useful,
  but WITHOUT ANY WARRANTY; without even the implied warranty of
  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
  Lesser General Public License for more details.

  You should have received a copy of the GNU Lesser General Public
  License along with the GNU C Library; if not, write to the Free
  Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
  02111-1307 USA.  */

#ifndef    _SCHED_H
#define    _SCHED_H    1

#include <features.h>

/* Get type definitions.  */
#include <bits/types.h>

#define __need_timespec
#include <time.h>

/* Get system specific constant and data structure definitions.  */
#include <bits/sched.h>
/* Define the real names for the elements of `struct sched_param'.  */
#define sched_priority    __sched_priority


__BEGIN_DECLS

/* Set scheduling parameters for a process.  */
extern int sched_setparam (__pid_t __pid, __const struct sched_param 
*__param) __THROW;

/* Retrieve scheduling parameters for a particular process.  */
extern int sched_getparam (__pid_t __pid, struct sched_param *__param) 
__THROW;

/* Set scheduling algorithm and/or parameters for a process.  */
extern int sched_setscheduler (__pid_t __pid, int __policy, \
                  __const struct sched_param *__param) __THROW;

/* Retrieve scheduling algorithm for a particular purpose.  */
extern int sched_getscheduler (__pid_t __pid) __THROW;

/* Yield the processor.  */
extern int sched_yield (void) __THROW;

/* Get maximum priority value for a scheduler.  */
extern int sched_get_priority_max (int __algorithm) __THROW;

/* Get minimum priority value for a scheduler.  */
extern int sched_get_priority_min (int __algorithm) __THROW;

/* Get the SCHED_RR interval for the named process.  */
extern int sched_rr_get_interval (__pid_t __pid, struct timespec *__t) 
__THROW;

__END_DECLS

#endif /* sched.h */
********************************************************

Regards,
Fabien

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From gerg at snapgear.com  Mon Apr 29 09:50:28 2002
From: gerg at snapgear.com (gerg)
Date: Mon, 29 Apr 2002 23:50:28 +1000
Subject: [uClinux-dev] PCI problem with 5407C3 board and linux 2.0
References: <579C0CAF497CD511AD4D00508BBD7AAC0246F5@pikachu.ntu.ac.uk>
Message-ID: <3CCD4FA4.E838A00E@snapgear.com>


Hi Mark,

"Howson, Mark" wrote:
> I'm having trouble trying to get Linux to see the PCI slot on the MCF5407C3
> board. I've enabled CONFIG_PCI, but I get the following:
> 
> >>>
> uClinux/COLDFIRE(m5407)
> COLDFIRE port done by Greg Ungerer, gerg at snapgear.com
> Flat model support (C) 1998,1999 Kenneth Albanowski, D. Jeff Dionne
> PCI: no PCI bus present
> pci_init: no BIOS32 detected
> Calibrating delay loop.. ok - 149.50 BogoMIPS
> Memory available: 30400k/32768k RAM, 0k/0k ROM (391k kernel code, 171k data)
> ...
> 
> I've tried changing jumper settings, power supplies, PCI cards in/out, etc -
> no luck. Is anyone using the PCI slot of the 5407?

It has been quite sometime since I lasted used it on the M5407C3
board. But I did use it quite extensively.

Which uClinux kernel version are you using?

First thing I would look at is what the ID check is returning
for the PCI bus presence test. This is just checking it it
looks like the CO-MEM lite is mapped or not.

Regards
Greg


------------------------------------------------------------------------
Greg Ungerer  --  Chief Software Wizard        EMAIL:  gerg at snapgear.com
Snapgear Pty Ltd                               PHONE:    +61 7 3279 1822
825 Stanley St,                                  FAX:    +61 7 3279 1820
Woolloongabba, QLD, 4102, Australia              WEB:   www.snapgear.com
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From mathias.fritzson at mecel.se  Mon Apr 29 09:59:15 2002
From: mathias.fritzson at mecel.se (mathias.fritzson at mecel.se)
Date: Mon, 29 Apr 2002 15:59:15 +0200
Subject: [uClinux-dev] Debugger and other stuff
Message-ID: <200204291358.g3TDw7s07660@uclinux.org>



Mathias wrote:
>Hi
>
>A small thing, the company here that we are doing our thesis at has a nice
>debugger "SingleStep" from Wind River, it works great except that it has a
>hard time to follow the types for variabels, especially the complex ones,
>structs and so on.. Has anyone managed to get this feature to work ?
>
>And now to the heavy stuff..
>
>We have an odd fault here, we have to have missed something in the port
but
>we have no clue what we have missed..
>
>When we are finishing up the start_kernel function a couple of new threads
>are activated if we got it right. Some whre in these taskswitches  the
>stack blows out of proportions and becomes +32k large. The struct in
>"current", in our case current_set,  is pointing all wrong. We've tried to
>trace the problem but we're not completely sure where to look.. We havn't
>found any good documentation about these task switches so we only got some
>basic task knowlege no Linux specific.
>

Just found out that the stack isn't growing as we thought. FYI this work is
done on the 2.0.39.1 kernel.

We traced the code and found out that the growth wasn't a growth, it's the
task switch. Inside the function "schedule" in the file
"uClinux-dist/linux/kernel/sched.c" we do a "switch_to(prev,next)" the
struct "next" must contain some bogus. Is the setup of this new struct
dependable on our porting in some way? We've tried to follow how the kernel
sets this struct up but it's everywhere..

Thanks

/Mathias


>I hope that you got some ideas =), we're slowly running out of them.
>
>/Mathias

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From skibria at win.trlabs.ca  Mon Apr 29 10:31:10 2002
From: skibria at win.trlabs.ca (Sami Kibria)
Date: 29 Apr 2002 09:31:10 -0500
Subject: [uClinux-dev] No ARM Support for kernel uClinux-2.4.x !!!???
In-Reply-To: <003c01c1ef7c$7d345790$70c9748c@pc2>
References: <003c01c1ef7c$7d345790$70c9748c@pc2>
Message-ID: <1020090670.18658.137.camel@feedtheworms.win.trlabs.ca>

hello...

how are you?  check out the "system type" button, and there should be
processor type in there!

:)


On Mon, 2002-04-29 at 07:50, ??? wrote:
> Hi
> I have downloaded uClinux-dist,and there is a directory of linux-2.4.x. 
> I want to make kernel of uClinux-2.4.x.
> Because my microprocessor is ARM7TDMI
> But when i 'make xconfig',
> I can not find ARM microprocessor in hardware support menu
>  Does anyboby know there any patch for ARM ???
>  Or what Should I do??
>             Kuo
>     
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Sami Kibria
Project Leader, Bluetooth Applications
email: skibria at win.trlabs.ca
TRLabs - Winnipeg, MB, CANADA

http://www.win.trlabs.ca/~skibria

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
   __   _
  / /  (_)__  __ ____  __
 / /__/ / _ \/ // /\ \/ /  . . .  t h e   c h o i c e   o f   a
/____/_/_//_/\_,_/ /_/\_\              G N U   g e n e r a t i o n

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-


This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From hamilton at SEDSystems.ca  Mon Apr 29 10:39:01 2002
From: hamilton at SEDSystems.ca (Kendrick Hamilton)
Date: Mon, 29 Apr 2002 08:39:01 -0600 (CST)
Subject: [uClinux-dev] Debugger and other stuff
In-Reply-To: <200204290930.g3T9Uws05751@uclinux.org>
Message-ID: <Pine.LNX.4.44.0204290838120.26365-100000@sw-55.sedsystems.ca>

I used single step with sds cross compiler and I saw no problems with it
tracking structs.

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

On Mon, 29 Apr 2002 mathias.fritzson at mecel.se wrote:

> Hi
>
> A small thing, the company here that we are doing our thesis at has a nice
> debugger "SingleStep" from Wind River, it works great except that it has a
> hard time to follow the types for variabels, especially the complex ones,
> structs and so on.. Has anyone managed to get this feature to work ?
>
> And now to the heavy stuff..
>
> We have an odd fault here, we have to have missed something in the port but
> we have no clue what we have missed..
>
> When we are finishing up the start_kernel function a couple of new threads
> are activated if we got it right. Some whre in these taskswitches  the
> stack blows out of proportions and becomes +32k large. The struct in
> "current", in our case current_set,  is pointing all wrong. We've tried to
> trace the problem but we're not completely sure where to look.. We havn't
> found any good documentation about these task switches so we only got some
> basic task knowlege no Linux specific.
>
> I hope that you got some ideas =), we're slowly running out of them.
>
> /Mathias
>
>
> This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/
>

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From art at videon-central.com  Mon Apr 29 10:36:35 2002
From: art at videon-central.com (Arthur Shipkowski)
Date: Mon, 29 Apr 2002 10:36:35 -0400
Subject: [uClinux-dev] Small netflash patch to replace gets() with fgets()
Message-ID: <000e01c1ef8b$4431ede0$9f80a8c0@videoncentral.com>

This is a small patch to replace uses of gets() in netflash's tftpmain.c
with fgets(), since the use of gets() seemed to cause the warning to be
added as a small section to the executable that caused relocation errors on
startup.

While creating this patch, I noted that the version of netflash that is in
CVS does not seem to line up with the 'newer' version in the tarball
distribution I downloaded two months ago or so.

Art

-------------- next part --------------
A non-text attachment was scrubbed...
Name: tftpmain.patch
Type: application/octet-stream
Size: 1848 bytes
Desc: not available
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20020429/15196197/attachment.obj>

From art at videon-central.com  Mon Apr 29 10:49:32 2002
From: art at videon-central.com (Arthur Shipkowski)
Date: Mon, 29 Apr 2002 10:49:32 -0400
Subject: [uClinux-dev] MCF5272 DMA support?
In-Reply-To: <3CBE0CB1.6040806@snapgear.com>
Message-ID: <001401c1ef8d$13807f20$9f80a8c0@videoncentral.com>

Okay, these patches have finally been tested and appear to do the trick for
MCF5272 DMA support.  If anyone runs into any trouble with them let me know.

Art
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mcf5272dma.patch
Type: application/octet-stream
Size: 14734 bytes
Desc: not available
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20020429/582766d0/attachment.obj>

From castet at firstlinux.net  Mon Apr 29 11:23:46 2002
From: castet at firstlinux.net (laurent castet)
Date: Mon, 29 Apr 2002 08:23:46 -0700 (PDT)
Subject: [uClinux-dev] How to get initial console shell working?
Message-ID: <20020429152347.0BA0C36F9@sitemail.everyone.net>

An embedded and charset-unspecified text was scrubbed...
Name: not available
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20020429/65b337a5/attachment.ksh>

From mathias.fritzson at mecel.se  Mon Apr 29 11:26:36 2002
From: mathias.fritzson at mecel.se (mathias.fritzson at mecel.se)
Date: Mon, 29 Apr 2002 17:26:36 +0200
Subject: [uClinux-dev] Debugger and other stuff
Message-ID: <200204291525.g3TFPQs09117@uclinux.org>




Kendrick Hamilton wrote:
>I used single step with sds cross compiler and I saw no problems with it
>tracking structs.
>
Did you put up any special paths or commands more than the "set srclist"
command ?

It finds all files for us but the variables are still messed up, might be
something more to set, there are complicated projects here but not as
complex as the kernel so none has been able to hint me in the right
direction here..

Cheers

/Mathias

>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
>
>On Mon, 29 Apr 2002 mathias.fritzson at mecel.se wrote:
>
>> Hi
>>
>> A small thing, the company here that we are doing our thesis at has a
nice
>> debugger "SingleStep" from Wind River, it works great except that it has
a
>> hard time to follow the types for variabels, especially the complex
ones,
>> structs and so on.. Has anyone managed to get this feature to work ?
>>
>> And now to the heavy stuff..
>>
>> We have an odd fault here, we have to have missed something in the port
but
>> we have no clue what we have missed..
>>
>> When we are finishing up the start_kernel function a couple of new
threads
>> are activated if we got it right. Some whre in these taskswitches  the
>> stack blows out of proportions and becomes +32k large. The struct in
>> "current", in our case current_set,  is pointing all wrong. We've tried
to
>> trace the problem but we're not completely sure where to look.. We
havn't
>> found any good documentation about these task switches so we only got
some
>> basic task knowlege no Linux specific.
>>
>> I hope that you got some ideas =), we're slowly running out of them.
>>
>> /Mathias
>>
>>

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From mark.howson at ntu.ac.uk  Mon Apr 29 11:31:14 2002
From: mark.howson at ntu.ac.uk (Howson, Mark)
Date: Mon, 29 Apr 2002 16:31:14 +0100
Subject: [uClinux-dev] PCI problem with 5407C3 board and linux 2.0
Message-ID: <579C0CAF497CD511AD4D00508BBD7AAC0246F7@pikachu.ntu.ac.uk>

Hi,

Greg Ungerer wrote:
> < snipped info on PCI problem with 5407 board >

> It has been quite sometime since I lasted used it on the M5407C3
> board. But I did use it quite extensively.

Thanks for confirming that.
 
> Which uClinux kernel version are you using?

uClinux 2.0.39.uc2

> First thing I would look at is what the ID check is returning
> for the PCI bus presence test. This is just checking it it
> looks like the CO-MEM lite is mapped or not.

Seems it isn't being mapped:

uClinux/COLDFIRE(m5407)
COLDFIRE port done by Greg Ungerer, gerg at snapgear.com
Flat model support (C) 1998,1999 Kenneth Albanowski, D. Jeff Dionne
pcibios_init()
pcibios_init : interrogating PCI addr ffff04fc, returning value of 0x0
PCI: no PCI bus present
pci_init: no BIOS32 detected

This is perhaps slightly off-topic, but does anyone have any ideas on that
one? Both of the MCF5407 boards I have seem to do the same thing, and I'm
out of ideas!

Mark
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From Alexander.Beach at student.shu.ac.uk  Mon Apr 29 13:15:14 2002
From: Alexander.Beach at student.shu.ac.uk (Alexander Beach)
Date: Mon, 29 Apr 2002 18:15:14 +0100
Subject: [uClinux-dev] Boa
Message-ID: <fc.005b8ff1012d9999005b8ff1012d9999.12d99c8@amazon.shu.ac.uk>

Does anyone know whether you can limit the ammount of simulataneous connection to the boa web
server, and if so how?

Thanks

Alex

Alex Beach
Alexander.Beach at student.shu.ac.uk
BEng (Hons) Electronic Engineering 4thYear


This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From lpm at leox.org  Mon Apr 29 14:09:05 2002
From: lpm at leox.org (The LEOX team)
Date: Mon, 29 Apr 2002 20:09:05 +0200
Subject: [uClinux-dev] Updated uClinux tools 20020410
References: <20020412115525.A6547@beast.internal.moreton.com.au>
Message-ID: <3CCD8C41.C59B3B97@leox.org>

Hi David,

>From uclinux-elf-tools version 20020410, the patch file
(gcc-2.95.3-arm-pic.patch2) is missing from the sources tree however the
script 'build-uclinux-tools.sh' uses it at stage1().

Do we need this patch file to rebuild the complete toolchain?

Many thanks.

David McCullough wrote:
> 
> Hi all,
> 
> I have put up the latest uClinux-elf-tools at:
> 
>         http://www.uclinux.org/pub/uClinux/uclinux-elf-tools/
> 
> This update supports the flat format shared libraries in the latest
> uClinux distribution and fixes a few minor things.
> 
> There are some notes on the page listing the changes, no update for the ARM
> guys at this point,
> 
> Cheers,
> Davidm
> 
> --
> David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
> davidm at snapgear.com  Fx: +61 7 3891 3630  825 Stanley St., W'gabba QLD 4102, Oz


-- 
Best Regards
The LEOX team

http://www.leox.org : Free Hardware and Software Resources for
System-on-Chip
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From lpm at leox.org  Mon Apr 29 16:42:53 2002
From: lpm at leox.org (The LEOX team)
Date: Mon, 29 Apr 2002 22:42:53 +0200
Subject: [uClinux-dev] uClinux-elf-tools (20020410) question?
Message-ID: <3CCDB04D.9F73203C@leox.org>

Hi all,

>From uclinux-elf-tools version 20020410, the patch file
(gcc-2.95.3-arm-pic.patch2) is missing from the sources tree however the
script 'build-uclinux-tools.sh' uses it in stage1().

Do we need this patch file to rebuild the complete toolchain or is it
obsolete?

Many thanks.
Best Regards

The LEOX team

http://www.leox.org : Free Hardware and Software Resources for
System-on-Chip
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From lpm at leox.org  Mon Apr 29 16:46:18 2002
From: lpm at leox.org (The LEOX team)
Date: Mon, 29 Apr 2002 22:46:18 +0200
Subject: [uClinux-dev] Boa
References: <fc.005b8ff1012d9999005b8ff1012d9999.12d99c8@amazon.shu.ac.uk>
Message-ID: <3CCDB11A.C4716E5E@leox.org>

Into boa.conf file, you have the following 2 parameters:

# KeepAliveMax: Number of KeepAlive requests to allow per connection
# Comment out, or set to 0 to disable keepalive processing

KeepAliveMax 1000

# KeepAliveTimeout: seconds to wait before keepalive connection times
out

KeepAliveTimeout 10

Hope this help.

Alexander Beach wrote:
> 
> Does anyone know whether you can limit the ammount of simulataneous connection to the boa web
> server, and if so how?
> 
> Thanks
> 
> Alex
> 
> Alex Beach
> Alexander.Beach at student.shu.ac.uk
> BEng (Hons) Electronic Engineering 4thYear
> 
> This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/

-- 
Best Regards
The LEOX team

http://www.leox.org : Free Hardware and Software Resources for
System-on-Chip
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From stefan_heinzmann at yahoo.com  Mon Apr 29 18:30:59 2002
From: stefan_heinzmann at yahoo.com (=?iso-8859-1?q?Stefan=20Heinzmann?=)
Date: Tue, 30 Apr 2002 00:30:59 +0200 (CEST)
Subject: [uClinux-dev] Shared libraries 
In-Reply-To: <200204290010.g3T0AHSH012226@skaro.internal.moreton.com.au>
Message-ID: <20020429223059.92810.qmail@web11204.mail.yahoo.com>

 --- pauli at snapgear.com schrieb:
[...]
> I agree that the stealing of
> address bits 
> isn't nice.  I'm happy that all the other limitations are not a real
> problem 
> and I'm willing to live with the address limitation for the moment. 
> I can 
> always take a few bits back again later -- we don't generally need
> full binary 
> compatibility in the embedded space.  Source compatibility on the
> other hand...

Agreed. Source compatibility is more important than binary
compatibility in the linux world.

> > The operating system assigns sequential slot numbers to each loaded
> > shared library, starting from 1. If a library gets unloaded, its
slot
> > can be reused by the next library that gets loaded, but loaded
> > libraries keep their slot number until they get unloaded.
> 
> Immediately, a relocation record must now contain the target
> library's name or 
> other reference rather than its ID and the OS is responsible for the 
> translation.  This will cost space and probably a small amount of
> time.  Our 
> scheme folds these together and saves space because of it.

I don't know the flat file format, but I dare say that the space
overhead can be kept very small. It would be enough to group the
relocation records of each target library together. A relocation record
would not need to store more than it stored before. It is a different
question how much programming you'd have to do to implement this --
there I'm a layman.

> More importantly, the GOT entries.  These are simply addresses.  We'd
> now have 
> to output relocation records for *all* of these too (to identify the
> library 
> the address comes from).  This would cost a fair chunk of space.  At
> present, 
> we know about the GOT and automatically relocate it thus avoiding
> many 
> relocation records.

I would mind much less here if you stole a few address bits for a
library id in the GOT pointer. That would allow you to store all
necessary relocation information in the GOT entry itself, thereby
avoiding extra storage requirements. That would be less restrictive
than your scheme: For example it would allow up to 255 *imported*
libraries with up to 16MB of static storage allocated by *each one* of
them. And I don't think it would be much harder to relocate on loading
than what you've got now.

> > The shared library does not need to be compiled to use pc-relative
> > addressing, since the dynamic linker knows where it will end up in
> the
> > address space and can do the necessary relocations when loading the
> > library. On the other hand, fewer relocations mean quicker loading,
> so
> > pc-relative might still be a good idea.
> 
> From experience, a pc-relative executable on the ColdFire takes up
> less space 
> than a fully relocatable one.  Our flat file loader supports both
> formats and 
> in general the extra relocations take more space than the overheads
> of 
> supporting execute in place.  We get a slight performance boost by
> not 
> executing in place but we've not needed this yet.
> 
> Also, going to absolute code loses the biggest win we've had: execute
> in place 
> is a god-send.  It gains more than shared libraries in terms of
> cramming 
> functionality into a small unit.  Sharing text segments is essential.
>  Sharing 
> library is just an extra saving.  I don't think I can emphasise this
> enough.  
> As soon as you've one absolute address in your text segment, this
> goes.

I agree 100%. I just wanted to point out that it is not *necessary* for
a shared lib to be pc-relative, i.e. it is not a requirement of the
dynamic linker. For some processors, that may be important. For the
Coldfire/m68k it is not. As you rightly point out, you'd probably want
to stay with pc-rel addressing anyway.

> > The import table is set up by the dynamic linker; the application
> or
> > the libraries only read from it. It contains pointers to the static
> > data of each shared library. The offset into the table is
> calculated
> > from the library's slot number (i.e. offset = slot_number*-4). A
> > procedure in a shared library can thus get a pointer to its own
> static
> > data with the following instruction:
> >     MOVEA (offset,A5),Ax
> > The dynamic linker needs to fix up the offset when loading the
> shared
> > library (by which time it knows the slot number).
> 
> Another relocation type and even more relocation records.
> One per procedure in fact.  More space.

Only in the disk file. Since the offset is known at load time of the
shared library, it needn't be kept in memory after loading it. Just for
picking nits: Only procedures that access global data will be affected.
So it's less than one per procedure, in fact.

> What happens if the offset exceeds 32k?  Looks like we're now limited
> to a 32k 
> data segment.  That is definitely not acceptable.  Okay, use multiple
> GOTs 
> located together and access them the same way.  Now we're back to a
> 32k 
> overall GOT limit.  More acceptable but significantly more
> restrictive then 
> with our implementation of a 32k per library limit (remember shared
> libraries 
> require more GOT entries than a stand alone program).

Nonono. You've misunderstood something. The import table contains 1
pointer per shared library. Exceeding 32k offset would mean exceeding
8000 loaded libraries. That's way beyond your system's capabilities
anyway. In my simplistic arrangement, A5 would point to the beginning
of the application's static data. Addressing static data would use a
positive offset while addressing the import table takes a negative
offset. So both have their 32k addressing range. But it needn't be like
that. You could reserve say 1k for the import table and be left with
63k for the static data. That is a system-wide decision, unfortunately,
but a less stringent one than the the ones in your scheme.

And note that each shared library could have its own 64k static data
segment, because the access to that data is not directly through A5,
but through the import table (if it is *own* static data) or through
the GOT (if it is *foreign* static data). BTW: The GOTs are not bunched
up but they are just a part of each shared library's static data. So
each library uses the same addressing method for the GOT as for the
other static data. Consequently, the GOT only consumes addressing space
from the static data of that very shared library, not from the entire
application.

> Now, do we make Ax A5 or something else?  If it is A5 then we've got
> the call 
> back into the main program to concern ourselves with (the called back
> 
> procedure has to set up A5).  If it isn't then we've lost another of
> our 
> fairly precious Ax registers.  I went for the main program being PIC
> too to 
> force the A5 reload.

The A5 is essentially constant (per process). A procedure may spill it
and thus reuse it, but before returning or before calling another
procedure it has to be restored. In this sense, it always points to the
static data of the application. It is a callee preserved register.

> > I can not currently see where this scheme breaks. It avoids several
> > problems:
> > -- No limit on the size of the application (no address bits stolen)
> > -- No limit on the number of shared libraries
> > -- No change for code that isn't in a shared library
> > -- Shared libraries pay a small price for accessing static data
> > -- Static data overhead is one import table per process
>
> -- Requires a clever dynamic loader.

Maybe; I'm not completely sure it's that much worse than your scheme.
You've got a clear advantage, however: You've implented it already and
I haven't. Until I have, I can only speculate.
 
> -- Uses more space.

I'm not convinced.
 
> -- Requires significantly larger modifications to existing tools and
> to the 
> flat file loader and format.  Backward compatibility becomes an issue
> here 
> (we're trying to not break existing build trees for any architecture.

Possibly. There again you've got the advantage of having done it
already.

> -- Requires multiple passes over libraries and executables prior to
> loading a 
> program.  We don't necessarily know what libraries are referenced
> ahead of 
> time, we have to scan for them.  Think compressed binaries.  Solve
> this by 
> breaking the data segment stuff into multiple chunks and allocating 
> separately. Now we cannot use the proposed scheme for setting Ax up.

I don't understand. In which way is this different from what you're
doing now?

> > Have I overlooked anything?
> 
> * There are a few problems, none of which are insurmountable but they
> will cause problems and they will be more troublesome to deal with.
> 
> * You will be paying space costs in several places.  Some of these
> are unlikely to be small.
> 
> * I'm probably being a little harsh with my comments ;-)
> 
> * Our scheme is already implemented.

As you may have guessed by now, the last point convinces me, the others
don't (yet). Maybe I wound you up by shooting at a solution after it
was implemented. There you go: You've just presented a long sought
after solution to a difficult problem that cost you months of sweat and
blood and just when you sit back and enjoy your success a greenhorn
comes along and tells you: But this isn't good enough, why didn't you
do it this or that way?

I'd chase him away with a hail of bits I'd throw at him ;-)

Never mind, I'm not being serious... 

> from what I've heard, the Ridge Run shared libraries for ARM uses elf
> format executables and libraries and avoid the limitations of our
> implementation.  If your problem is large enough to find our
> limitations limiting, there is an alternative already.

Good tip, I'll have a look, thanks.

Cheers
Stefan


__________________________________________________________________

Gesendet von Yahoo! Mail - http://mail.yahoo.de
Sie brauchen mehr Speicher f?r Ihre E-Mails? - http://premiummail.yahoo.de
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From pauli at snapgear.com  Mon Apr 29 19:30:13 2002
From: pauli at snapgear.com (pauli at snapgear.com)
Date: Tue, 30 Apr 2002 09:30:13 +1000
Subject: [uClinux-dev] Shared libraries 
In-Reply-To: Your message of "Tue, 30 Apr 2002 00:30:59 +0200."
             <20020429223059.92810.qmail@web11204.mail.yahoo.com> 
References: <20020429223059.92810.qmail@web11204.mail.yahoo.com> 
Message-ID: <200204292330.g3TNUDSH029458@skaro.internal.moreton.com.au>

Hi all,

Stefan Heinzmann wrote:

> I don't know the flat file format, but I dare say that the space
> overhead can be kept very small. It would be enough to group the
> relocation records of each target library together. A relocation record
> would not need to store more than it stored before. It is a different
> question how much programming you'd have to do to implement this --
> there I'm a layman.

Yes this would certainly be possible.  It will require some extra build time 
processing to presort the relocation records etc.  I don't know enough about 
the linker internals to know if a modification is required there.  Currently, 
no linker modifications are necessary and only a very small gcc change.


> I would mind much less here if you stole a few address bits for a
> library id in the GOT pointer. That would allow you to store all
> necessary relocation information in the GOT entry itself, thereby
> avoiding extra storage requirements. That would be less restrictive
> than your scheme: For example it would allow up to 255 *imported*
> libraries with up to 16MB of static storage allocated by *each one* of
> them. And I don't think it would be much harder to relocate on loading
> than what you've got now.

We also use the GOT for procedure calls.  Stealing bits here is pretty much 
the same as stealing them in relocation records...  I guess, one could concoct 
a scheme where this wasn't true...  I'd also wonder about the build 
complexities...


> I agree 100%. I just wanted to point out that it is not *necessary* for
> a shared lib to be pc-relative, i.e. it is not a requirement of the
> dynamic linker. For some processors, that may be important. For the
> Coldfire/m68k it is not. As you rightly point out, you'd probably want
> to stay with pc-rel addressing anyway.

We still support fully relocated executables.
I believe some people are even using them :-)


> Only in the disk file. Since the offset is known at load time of the
> shared library, it needn't be kept in memory after loading it. Just for
> picking nits: Only procedures that access global data will be affected.
> So it's less than one per procedure, in fact.

One small problem, no disc.  The file system on all bar two (?) of our units 
lives in RAM or flash, we execute the code directly from there.  Discs are 
expensive (and huge).  Flash is small.

If we were running from disc, a whole lot of things change.  File size becomes 
much less of an issue as does the number of support utilities etc.  I believe 
that executable images aren't shared properly without an MMU (with a 2.4 
kernel) so shared library aren't going to be a benefit.  Go for fully 
relocatable static executables because they will generally occupy less memory 
and they will execute faster even though they consume considerably more file 
system space.


> Nonono. You've misunderstood something. The import table contains 1
> pointer per shared library. Exceeding 32k offset would mean exceeding
> 8000 loaded libraries. That's way beyond your system's capabilities
> anyway. In my simplistic arrangement, A5 would point to the beginning
> of the application's static data. Addressing static data would use a
> positive offset while addressing the import table takes a negative
> offset. So both have their 32k addressing range. But it needn't be like
> that. You could reserve say 1k for the import table and be left with
> 63k for the static data. That is a system-wide decision, unfortunately,
> but a less stringent one than the the ones in your scheme.

I stand corrected.  I should have thought things through here a bit further :-(


> As you may have guessed by now, the last point convinces me, the others
> don't (yet). Maybe I wound you up by shooting at a solution after it
> was implemented. There you go: You've just presented a long sought
> after solution to a difficult problem that cost you months of sweat and
> blood and just when you sit back and enjoy your success a greenhorn
> comes along and tells you: But this isn't good enough, why didn't you
> do it this or that way?

Actually it took surprisingly little time to implement once we'd worked out 
how we were going to do it ;-)  I suspect my harsh reaction had something to 
do with my feeling more than a little sick yesterday :-(

I'm more than happy to discuss the various possibilities we'd considered along 
the way (and believe me there were plenty).


Regards,

Pauli


This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From davidm at snapgear.com  Mon Apr 29 19:59:18 2002
From: davidm at snapgear.com (David McCullough)
Date: Tue, 30 Apr 2002 09:59:18 +1000
Subject: [uClinux-dev] Updated uClinux tools 20020410
In-Reply-To: <3CCD8C41.C59B3B97@leox.org>; from lpm@leox.org on Mon, Apr 29, 2002 at 08:09:05PM +0200
References: <20020412115525.A6547@beast.internal.moreton.com.au> <3CCD8C41.C59B3B97@leox.org>
Message-ID: <20020430095918.A17396@beast.internal.moreton.com.au>


Jivin The LEOX team lays it down ...
> Hi David,
> 
> From uclinux-elf-tools version 20020410, the patch file
> (gcc-2.95.3-arm-pic.patch2) is missing from the sources tree however the
> script 'build-uclinux-tools.sh' uses it at stage1().
> 
> Do we need this patch file to rebuild the complete toolchain?

For ARM you need it.  I have fixed that file up now,  it is the same as
the one from the older tools release,

Thanks,
Davidm

-- 
David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
davidm at snapgear.com  Fx: +61 7 3891 3630  825 Stanley St., W'gabba QLD 4102, Oz
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From kseom at maplenetworks.co.kr  Mon Apr 29 19:53:04 2002
From: kseom at maplenetworks.co.kr (???)
Date: Tue, 30 Apr 2002 08:53:04 +0900
Subject: [uClinux-dev] No ARM Support for kernel uClinux-2.4.x !!!???
References: <003c01c1ef7c$7d345790$70c9748c@pc2>
Message-ID: <00f701c1efd9$013e8220$0401a8c0@LocalHost>

Hi
Check your Makefile.
Uncomment line #8 (ARCH := armnommu) in your Makefile.

  ----- Original Message ----- 
  From: ??? 
  To: uclinux-dev at uclinux.org 
  Sent: Monday, April 29, 2002 9:50 PM
  Subject: [uClinux-dev] No ARM Support for kernel uClinux-2.4.x !!!???


  Hi
  I have downloaded uClinux-dist,and there is a directory of linux-2.4.x. 
  I want to make kernel of uClinux-2.4.x.
  Because my microprocessor is ARM7TDMI
  But when i 'make xconfig',
  I can not find ARM microprocessor in hardware support menu
   Does anyboby know there any patch for ARM ???
   Or what Should I do??
              Kuo
      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20020430/b408f7c8/attachment.html>

From gerg at snapgear.com  Mon Apr 29 20:10:32 2002
From: gerg at snapgear.com (Greg Ungerer)
Date: Tue, 30 Apr 2002 10:10:32 +1000
Subject: [uClinux-dev] problem with making uClinux-2.4.x
References: <000e01c1ef59$13e30f20$70c9748c@pc2>
Message-ID: <3CCDE0F8.5010705@snapgear.com>


Hi Kuo,

??? wrote:
> Hi ,All
> I have downloaded uClinux-dist,and there is a directory of linux-2.4.x.
> I want to make kernel of uClinux-2.4.x.
> But i got error message below when i 'make' :
>  
> serial.c :327: 'RS_TABLE_SIZE' undeclared here.(Not in a function)
> serial.c :327: warning : braces around scalar initializer.
> serial.c :328: (near initialization for 'rs_table)

The definition of RS_TABLE_SIZE is architecture dependant.
What CPU are you compiling for?

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

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From Subashk at ami.com  Mon Apr 29 20:39:53 2002
From: Subashk at ami.com (Subash Kalbarga)
Date: Mon, 29 Apr 2002 20:39:53 -0400
Subject: [uClinux-dev] free reports wrong?
Message-ID: <8CCBDD5583C50E4196F012E79439B45C620435@atl-ms1.megatrends.com>

Hi all,
 
Pardon me if this question seems trivial or already has answers.
 
I am on a Coldfire with uClinux 2.4.10 and I am seeing free reporting less
memory 
For eg:
I type free and see 1503232 bytes free
 
Now I have a process which ps shows to be 266k
 
So I kill it like so, kill -9 28
 
After which free shows 1511424
 
Which indicates that only 8192 bytes got free?
 
Is this correct .. ?
 
Thanks in advance
Subash 
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20020429/0675dde1/attachment.html>

From gerg at snapgear.com  Mon Apr 29 20:45:42 2002
From: gerg at snapgear.com (Greg Ungerer)
Date: Tue, 30 Apr 2002 10:45:42 +1000
Subject: [uClinux-dev] How to get initial console shell working?
References: <20020429152347.0BA0C36F9@sitemail.everyone.net>
Message-ID: <3CCDE936.3070306@snapgear.com>


Hi Laurent,

Is this uClinux?

In any case I beleive the standard form of the console
argument for Linux is to not specify the "/dev/" part.
Only the device name:

     console=ttyS0

uClinux targets do allow the use of "/dev".

Regards
Greg




laurent castet wrote:
> hi,
> 
> i work with an ARM940 processor on a Conexant Board, i use Conexant serial driver for this board, place "console=/dev/ttyS0" on the kernel init cmd_line and also "ttyS0:vt100:agetty 115200 /dev/ttyS0" in the inittab file
> 
> but i can't acces to an initial console.
> Any ideas?
> 
> i get the kernel boot message by a telnet session, (see at the end)
> 
> regards
> 
> 
> Laurent
> 
> 
> 
> cat kmsg
> <4>
> <4>
> <4>
> <4>Linux version 2.4.6 (root at EASYLIN2) (gcc version 2.95.3 20010315 (releas 
> e)) #20 lun avr 29 11:05:49 CEST 2002
> <4>Processor: ARM/CNXT Arm940sid(wb) revision 1
> <4>Architecture: CNXT CX821XX
> <4>On node 0 totalpages: 2048
> <4>zone(0): 0 pages.
> <4>zone(1): 2048 pages.
> <4>zone(2): 0 pages.
> <4>Kernel command line: root=/dev/rom0 console=/dev/ttyS0
> <4>Calibrating delay loop... 71.68 BogoMIPS
> <6>Memory: 8MB = 8MB total
> <5>Memory: 6092KB available (943K code, 971K data, 36K init)
> <4>Dentry-cache hash table entries: 1024 (order: 1, 8192 bytes)
> <4>Inode-cache hash table entries: 512 (order: 0, 4096 bytes)
> <4>Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
> <4>Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes)
> <4>Page-cache hash table entries: 2048 (order: 1, 8192 bytes)
> <4>POSIX conformance testing by UNIFIX
> <6>Linux NET4.0 for Linux 2.4
> <6>Based upon Swansea University Computer Society NET3.039
> <4>Initializing RT netlink socket
> <4>Starting kswapd v1.8
> <4>ttyS0 at 0x002c0000 (irq = 24) is a 16c550 UART
> <4>info = 009d6a14
> <4>block: queued sectors max/low 3949kB/1316kB, 64 slots per queue
> <4>RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
> <4>PHY detected: Kendin KS8737
> 4>emac_probe: eth0 found.
> <4>EMAC Network Driver Cnxt 2002/02/28 irq=19 00:70:46:00:01:cc:
> <4>PHY detected: Kendin KS8737 
> <4>emac_probe: eth1 found.
> <4>EMAC Network Driver Cnxt 2002/02/28 irq=20 00:70:46:00:01:dd:
> <4>Blkmem copyright 1998,1999 D. Jeff Dionne
> <4>Blkmem copyright 1998 Kenneth Albanowski
> <4>Blkmem 1 disk images:
> <4>0: 500000-5C4BFF [VIRTUAL 500000-5C4BFF] (RO)
> <6>NET4: Linux TCP/IP 1.0 for NET4.0
> <6>IP Protocols: ICMP, UDP, TCP
> <4>IP: routing cache hash table of 512 buckets, 4Kbytes
> <4>TCP: Hash tables configured (established 512 bind 512)
> <6>NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
> <6>NET4: Ethernet Bridge 008 for NET4.0
> <4>VFS: Mounted root (romfs filesystem) readonly.
> <4>eth0: (CX821xx EMAC) started!
> <4>eth1: (CX821xx EMAC) started!
> 
> 
> 
> 
> 
> _____________________________________________________________
> Want a new web-based email account ? ---> http://www.firstlinux.net
> 
> _____________________________________________________________
> Run a small business? Then you need professional email like you at yourbiz.com from Everyone.net  http://www.everyone.net?tag
> This message resent by the uclinux-dev at uclinux.org list server http://www.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

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From gerg at snapgear.com  Mon Apr 29 21:21:11 2002
From: gerg at snapgear.com (Greg Ungerer)
Date: Tue, 30 Apr 2002 11:21:11 +1000
Subject: [uClinux-dev] Porting uClinux to Sh2-DSP
References: <79DD1BC58DD7AC418EC0D1D5B169ACB816506E@mail.ushustech.com>
Message-ID: <3CCDF187.4010107@snapgear.com>


Hi Anurag,

Anurag.R wrote:
>      I am very new to uClinux development. We would like to
> port uClinux to Hitachi's Sh2-DSP(SE7616DSP) processor.
> This processor doesn't support MMU.
> 
> We have a few doubts regarding this:
> 1. The target dependant areas of uClinux where we have to modify.

The 2 main architecture branches within the uClinux
tree are under ~/arch where there is directories
for each CPU type, and under ~/include where there
is directories for defines for each different CPU
archtitecture.


> 2. The tool chain required for this.

Gcc. You might want to do some investigation to see
which version has the best (ie least buggy :-)
support for SH2.

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

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From gerg at snapgear.com  Mon Apr 29 21:47:05 2002
From: gerg at snapgear.com (Greg Ungerer)
Date: Tue, 30 Apr 2002 11:47:05 +1000
Subject: [uClinux-dev] Small netflash patch to replace gets() with fgets()
References: <000e01c1ef8b$4431ede0$9f80a8c0@videoncentral.com>
Message-ID: <3CCDF799.60904@snapgear.com>

Hi Arthur,

Arthur Shipkowski wrote:
> This is a small patch to replace uses of gets() in netflash's tftpmain.c
> with fgets(), since the use of gets() seemed to cause the warning to be
> added as a small section to the executable that caused relocation errors on
> startup.

This looks good. I have applied it.


> While creating this patch, I noted that the version of netflash that is in
> CVS does not seem to line up with the 'newer' version in the tarball
> distribution I downloaded two months ago or so.

The "userland" CVS is not actively used.

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

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From gerg at snapgear.com  Mon Apr 29 22:12:15 2002
From: gerg at snapgear.com (Greg Ungerer)
Date: Tue, 30 Apr 2002 12:12:15 +1000
Subject: [uClinux-dev] PCI problem with 5407C3 board and linux 2.0
References: <579C0CAF497CD511AD4D00508BBD7AAC0246F7@pikachu.ntu.ac.uk>
Message-ID: <3CCDFD7F.5090406@snapgear.com>



Howson, Mark wrote:
>>Which uClinux kernel version are you using?
> 
> uClinux 2.0.39.uc2

OK, that is what I developed it all on.


>>First thing I would look at is what the ID check is returning
>>for the PCI bus presence test. This is just checking it it
>>looks like the CO-MEM lite is mapped or not.
>
> Seems it isn't being mapped:

Check that dBUG is actually setting up a CS line for it.

Regards
Greg




> uClinux/COLDFIRE(m5407)
> COLDFIRE port done by Greg Ungerer, gerg at snapgear.com
> Flat model support (C) 1998,1999 Kenneth Albanowski, D. Jeff Dionne
> pcibios_init()
> pcibios_init : interrogating PCI addr ffff04fc, returning value of 0x0
> PCI: no PCI bus present
> pci_init: no BIOS32 detected
> 
> This is perhaps slightly off-topic, but does anyone have any ideas on that
> one? Both of the MCF5407 boards I have seem to do the same thing, and I'm
> out of ideas!
> 
> Mark
> This message resent by the uclinux-dev at uclinux.org list server http://www.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

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From zl at imail.com.cn  Mon Apr 29 22:30:57 2002
From: zl at imail.com.cn (zhanglei)
Date: Tue, 30 Apr 2002 10:30:57 +0800
Subject: [uClinux-dev] FrameBuffer in M68KNOMMU?
Message-ID: <20020430023601.37FD3E378C@bluemail.email.com.cn>

Dear all:
I have made use of framebuffer drivers from arch/m68knommu in uClinux2.0.38. It has worked well for several months. When I have tried  porting uClinux2.4.17, the complier complained about the frambuffer codes and console code.
What's wrong with these code? What should I do to make  them working in uClinux2.4.17?
Zhanglei
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20020430/2d41e0d8/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: LittleBoy.GIF
Type: image/gif
Size: 1021 bytes
Desc: not available
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20020430/2d41e0d8/attachment.gif>

From kuochung at mail.iaa.ncku.edu.tw  Tue Apr 30 00:15:32 2002
From: kuochung at mail.iaa.ncku.edu.tw (=?big5?B?tsCw6rZ2?=)
Date: Tue, 30 Apr 2002 12:15:32 +0800
Subject: [uClinux-dev] problem with making uClinux-2.4.x
References: <000e01c1ef59$13e30f20$70c9748c@pc2> <3CCDE0F8.5010705@snapgear.com>
Message-ID: <003001c1effd$ac2e62d0$70c9748c@pc2>

Hi Greg
my microprocessor  is ARM7TDMI
So what can i do with that error???????
Regards
Kuo


>
> Hi Kuo,
>
> ??? wrote:
> > Hi ,All
> > I have downloaded uClinux-dist,and there is a directory of linux-2.4.x.
> > I want to make kernel of uClinux-2.4.x.
> > But i got error message below when i 'make' :
> >
> > serial.c :327: 'RS_TABLE_SIZE' undeclared here.(Not in a function)
> > serial.c :327: warning : braces around scalar initializer.
> > serial.c :328: (near initialization for 'rs_table)
>
> The definition of RS_TABLE_SIZE is architecture dependant.
> What CPU are you compiling for?
>
> 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
>
> This message resent by the uclinux-dev at uclinux.org list server
http://www.uClinux.org/
>

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From gerg at snapgear.com  Tue Apr 30 00:58:22 2002
From: gerg at snapgear.com (Greg Ungerer)
Date: Tue, 30 Apr 2002 14:58:22 +1000
Subject: [uClinux-dev] problem with making uClinux-2.4.x
References: <000e01c1ef59$13e30f20$70c9748c@pc2> <3CCDE0F8.5010705@snapgear.com> <003001c1effd$ac2e62d0$70c9748c@pc2>
Message-ID: <3CCE246E.1050307@snapgear.com>


Hi Kuo,

??? wrote:
> my microprocessor  is ARM7TDMI
> So what can i do with that error???????

The RS_TABLE_SIZE define for armnommu targets is
in the architecture specific includes directories,
in ~/include/asm-armnommy/<arch>/serial.h.

For the sprcific <arch> you are using no-one has
setup the defines/tables required for 16550 UART
support. You will have to add them. Use the other
serial.h files as a reference.

Regards
Greg



>>Hi Kuo,
>>
>>??? wrote:
>>
>>>Hi ,All
>>>I have downloaded uClinux-dist,and there is a directory of linux-2.4.x.
>>>I want to make kernel of uClinux-2.4.x.
>>>But i got error message below when i 'make' :
>>>
>>>serial.c :327: 'RS_TABLE_SIZE' undeclared here.(Not in a function)
>>>serial.c :327: warning : braces around scalar initializer.
>>>serial.c :328: (near initialization for 'rs_table)
>>
>>The definition of RS_TABLE_SIZE is architecture dependant.
>>What CPU are you compiling for?
>>
>>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
>>
>>This message resent by the uclinux-dev at uclinux.org list server
> 
> http://www.uClinux.org/
> 
> 
> This message resent by the uclinux-dev at uclinux.org list server http://www.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

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From stefan_heinzmann at yahoo.com  Tue Apr 30 02:35:05 2002
From: stefan_heinzmann at yahoo.com (=?iso-8859-1?q?Stefan=20Heinzmann?=)
Date: Tue, 30 Apr 2002 08:35:05 +0200 (CEST)
Subject: [uClinux-dev] Shared libraries 
In-Reply-To: <200204292330.g3TNUDSH029458@skaro.internal.moreton.com.au>
Message-ID: <20020430063505.93686.qmail@web11208.mail.yahoo.com>

 --- pauli at snapgear.com schrieb: 
[...]
> I don't know enough about 
> the linker internals to know if a modification is required there. 
> Currently, 
> no linker modifications are necessary and only a very small gcc
> change.

I'm currently trying to get to grips with the linker and the other
tools. Maybe in a few weeks time I'll be in a better position to
comment on this.

[...]
> We also use the GOT for procedure calls.  Stealing bits here is
> pretty much 
> the same as stealing them in relocation records...  I guess, one
> could concoct 
> a scheme where this wasn't true...  I'd also wonder about the build 
> complexities...

There's a gcc option -mpcrel that claims to use PC-rel addressing
directly instead of using the GOT. Does that work? Would that not make
a lot of difference for the size of the GOT?

[...]
> One small problem, no disc.  The file system on all bar two (?) of
> our units 
> lives in RAM or flash, we execute the code directly from there. 
> Discs are 
> expensive (and huge).  Flash is small.
> 
> If we were running from disc, a whole lot of things change.  File
> size becomes 
> much less of an issue as does the number of support utilities etc.  I
> believe 
> that executable images aren't shared properly without an MMU (with a
> 2.4 
> kernel) so shared library aren't going to be a benefit.  Go for fully
> relocatable static executables because they will generally occupy
> less memory 
> and they will execute faster even though they consume considerably
> more file 
> system space.

Ah now I understand a bit better what this XIP business is about. I
always thought that what was in flash was a kind of preloaded memory
snapshot. Instead it's files which still need to be "loaded" when the
system is running -- only that this doesn't allocate storage for the
code but uses the file image in memory directly. Is this how it's done?

My assumption was that you "preload" the code you want in the flash and
on system startup it is all relocated already. Thus you wouldn't need
to store those reloc records anymore. But thinking about it, that could
change the way Linux works quite considerably. That's probably too much
work.
 
[...]
> Actually it took surprisingly little time to implement once we'd
> worked out how we were going to do it ;-)

That's what I experienced over and over again, too. With a clear
thought in your mind, the creative juices flow much better...

> I suspect my harsh reaction had something to 
> do with my feeling more than a little sick yesterday :-(

Sorry to hear that. I hope you're well again.

> I'm more than happy to discuss the various possibilities we'd
> considered along the way (and believe me there were plenty).

Glad you say that. I certainly didn't want to offend you. Above all, I
want to understand. If I can see the reasoning behind a solution, I can
start to appreciate it even though I may not have liked it at first.


Cheers
Stefan


__________________________________________________________________

Gesendet von Yahoo! Mail - http://mail.yahoo.de
Sie brauchen mehr Speicher f?r Ihre E-Mails? - http://premiummail.yahoo.de
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From davidb at cvs.com.au  Tue Apr 30 19:49:23 2002
From: davidb at cvs.com.au (David Braendler)
Date: Tue, 30 Apr 2002 16:49:23 -0700
Subject: [uClinux-dev] Address of Memory in Snapgear Lite+
References: <5.1.0.14.1.20020424132601.00a95300@localhost> <5.1.0.14.1.20020424180141.00a84c08@localhost> <3CC6BFF6.97EBE718@snapgear.com>
Message-ID: <000501c1f0a1$aa5b0fe0$ca00a8c0@dave2000>

Hi,
     Does someone know the address of flash and sdram on the Snapgear
LITE+??.

Cheers

David Braendler
davidb at cvs.com.au
Electronic Engineer
Colour Vision Systems
11 Park Street
Bacchus Marsh 3340
Victoria, Australia
Ph  : +61 3 5367 6410
Fax : +61 3 5367 4480


This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/


From olivierp at actimage.fr  Fri Apr 26 09:14:51 2002
From: olivierp at actimage.fr (Olivier PIERRAT)
Date: Fri, 26 Apr 2002 15:14:51 +0200
Subject: [uClinux-dev] problem to wake up a thread in the kernel
References: <3CC6B0F9.9050108@actimage.fr> <3CC6BE50.2526EC6D@snapgear.com> <3CC6D810.8030000@actimage.fr> <3CC806C5.DDC565D3@snapgear.com>
Message-ID: <3CC952CB.1060100@actimage.fr>

Hi Greg,

I capture the boot message and add at the beginning of the interesting 
line the '====>' tag.
The boot message is :

====================================================================
dBUG> go 0x20000


uClinux/COLDFIRE(m5272)
COLDFIRE port done by Greg Ungerer, gerg at snapgear.com
Flat model support (C) 1998,1999 Kenneth Albanowski, D. Jeff Dionne
Calibrating delay loop.. ok - 43.82 BogoMIPS
Memory available: 2776k/4096k RAM, 0k/0k ROM (392k kernel code, 164k data)
Swansea University Computer Society NET3.035 for Linux 2.0
NET3: Unix domain sockets 0.13 for Linux NET3.035.
Swansea University Computer Society TCP/IP for NET3.034
IP Protocols: ICMP, UDP, TCP
uClinux version 2.0.39.1 (olivier at linux) (gcc version 2.95.3 20010315 
(release)(ColdFire patches - 20010318 from 
http://fiddes.net/coldfire/)(-msep-data patches)) 20 Fri Apr 26 14:53:44 
CEST 2002
bdflush thread launch

=====>MY THREAD : thread launch

ColdFire internal UART serial driver version 1.00
ttyS0 at 0x10000100 (irq = 73) is a builtin ColdFire UART
ttyS1 at 0x10000140 (irq = 74) is a builtin ColdFire UART
Ramdisk driver initialized : 16 ramdisks of 4096K size
Blkmem copyright 1998,1999 D. Jeff Dionne
Blkmem copyright 1998 Kenneth Albanowski
Blkmem 1 disk images:
0: AB1C4-1381C3 (RO)
PPP: version 2.3.8 (demand dialling)
TCP compression code copyright 1989 Regents of the University of California
PPP line discipline registered.
SLIP: version 0.8.4-NET3.019-NEWTTY (dynamic channels, max=256).
CSLIP: code copyright 1989 Regents of the University of California.
FEC ENET Version 0.1, 00:cf:52:72:c3:01
fec: link up, 100 Mbps, Full-Duplex, auto complete
fec: PHY id 0x001378e1
VFS: Mounted root (romfs filesystem) readonly.

====>  00`3?0~0f0?`?`3?f<<`<?00`3?0~0f0????f?f????f???~<?Shell invoked 
to run file: /etc/rc

Command: hostname uClinux
Command: /bin/expand /etc/ramfs.img /dev/ram0
Command: mount -t proc proc /proc
Command: mount -t ext2 /dev/ram0 /var
Command: mkdir /var/tmp
Command: mkdir /var/log
Command: mkdir /var/run
Command: mkdir /var/lock
Command: ifconfig lo 127.0.0.1
Command: route add -net 127.0.0.0 netmask 255.0.0.0 lo
Command: dhcpcd -p -a eth0 &
[12]
Command: cat /etc/motd
Welcome to
           ____ _  _
          /  __| ||_|
     _   _| |  | | _ ____  _   _  _  _
    | | | | |  | || |  _ \| | | |\ \/ /
    | |_| | |__| || | | | | |_| |/    \
    |  ___\____|_||_|_| |_|\____|\_/\_/
    | |
    |_|

For further information check:
http://www.uclinux.org/

Exec?
Sash command shell (version 1.1.1)
/>

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

It is strange. I launch a new kernel thread with the function 
'kernel_thread()', just after the kswapd thread. In my new thread I make 
some printk. But I'm not sure it was a problem due to printk. Can it be 
due to the initialization of my thread ? Should I perform the 
initialization a little bit later ? In that case where can I perform it ?

My thread is :


int  mythread_Run(void * unused)
{

    // Initialize the thread behaviour
    current->session = 1;
    current->pgrp = 1;
    sprintf(current->comm,"%s", "my_thread");
    current->blocked = ~0UL;

    current->policy = SCHED_FIFO;
    current->priority = 20;

    //Create a dynamic timer
    InitTimer();   //2s

    //Thread core
    while (1)
    {
       printk("MY THREAD : Process wake up \n");
       interruptible_sleep_on(&my_thread_wait);
    }

    return 0;	
}


Do you have an idea ?


Thank you.

Olivier.
gerg wrote:

> Hi Olivier,
> 
> Olivier PIERRAT wrote:
> 
>> Thank you, I have make a stupid mistake. I find it with the gdb.
>> 
>> In fact I have some problems and strange characters display in the boot
>> message when I add some printk to debug the thread (eg, the priority,
>> timer value, ...). Do you know what is the problem ? Is it possible to
>> perform printk inside the thread without disturbing the kernel ?
> 
> 
> Generally you can use printk anywhere. It uses polled serial
> output (not interrupts), so provided its underlying UART
> driving code is correct it should pretty much always work.
> 
> The kernel will be disturbed in so much as interrupts
> are turned off while the UART output is occurring.
> And this can be for a quite considerable amount of time,
> depending on the baud rate in use on the console serial
> port.
> 
> Can you send some output trace showing the problem?
> 
> Regards
> Greg
> 
> 
> ------------------------------------------------------------------------
> Greg Ungerer  --  Chief Software Wizard        EMAIL:  gerg at snapgear.com
> Snapgear Pty Ltd                               PHONE:    +61 7 3279 1822
> 825 Stanley St,                                  FAX:    +61 7 3279 1820
> Woolloongabba, QLD, 4102, Australia              WEB:   www.snapgear.com
> This message resent by the uclinux-dev at uclinux.org list server http://www.uCl