[uClinux-dev] RE: uClinux-dev digest, Vol 1 #470 - 13 msgs

MuraliKrishna muralikrishna at lampex.com
Mon Mar 31 19:35:50 EST 2003


Dear,









Thanks and Best regards
P.Murali krishna,
R&D Engineer,
Embedded division,
Lampex Electronics ltd,
6-2/231/b,Kukatpalli,
Hyderabad,
AP-500072
INDIA

-----Original Message-----
From: uclinux-dev-admin at uclinux.org [mailto:uclinux-dev-admin at uclinux.org]On
Behalf Of uclinux-dev-request at uclinux.org
Sent: Tuesday, 1 April 2003 2:22 PM
To: uclinux-dev at uclinux.org
Subject: uClinux-dev digest, Vol 1 #470 - 13 msgs

Send uClinux-dev mailing list submissions to
        uclinux-dev at uclinux.org

To subscribe or unsubscribe via the World Wide Web, visit
        http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
or, via email, send a message with subject or body 'help' to
        uclinux-dev-request at uclinux.org

You can reach the person managing the list at
        uclinux-dev-admin at uclinux.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of uClinux-dev digest..."


Today's Topics:

   1. Re: uClinux on S3C4510-SNDS100 architecture (David McCullough)
   2. Re: Re: Populating blkmem (John Williams)
   3. Re: porting elf2flt (John Williams)
   4. Re: increasing baud rate (Michael Caisse)
   5. Re: porting elf2flt (David McCullough)
   6. eb55/uclinux questions (Abraham van der Merwe)
   7. Re: porting elf2flt (John Williams)
   8. MTD w/uClinux: Kernel hangs when trying to probe AM29LV160DB flash
       device (David Jones)
   9. Re: Populating blkmem (Miles Bader)
  10. Re: Populating blkmem (David McCullough)
  11. Re: Where to init chip select in 2.4 kernel (=?utf-8?B?5p2o5Lqa5Yab?=)
  12. Rrgarding Motorola M5407C3 EVB (Simon Hsu)

--__--__--

Message: 1
Date: Tue, 1 Apr 2003 03:22:42 +1000
From: David McCullough <davidm at snapgear.com>
To: uclinux-dev at uclinux.org
Subject: Re: [uClinux-dev] uClinux on S3C4510-SNDS100 architecture
Reply-To: uclinux-dev at uclinux.org


Jivin Erwin Authried lays it down ...
> Am Mon, 2003-03-31 um 16.11 schrieb David McCullough:
> >
> > > Also I have had several problems with it:
> > >
> > > a) maybe anyone knows how to restart an ARM machine with 'reboot'
> > > successfully?
> >
> > No idea sorry.  On coldfire (has no HW reset instruction) we just jump
> > back through the rom startup.  You may be able to use a watchdog timer
> > if one is present.
> You can write your machine specific reset code in
> include/asm-armnommu/arch-*/system.h. A jump to the rom-start may be
> sufficient if no reset instruction is available.
>
> >
> > > b) when I start my app and it terminates on signal (say Ctrl-C), the
> > > memory is not freed properly. When I start large app (~650Kb) and
> > > terminate it several times, out of memory error occurs. Is it right?
> >
> > No.
> I think that might be possible because of increasing fragmentation.


True,  forgot about that case.  A "cat /proc/meminfo" will determine if
that is the case here.


> > Is the memory freed properly when they exit normally ?
> >
> > Are you building with -msingle-pic-base/XIP ?  If so then you might need
to
> > fixup the is_in_rom function in linux-2.4.x/arch/armnommu/mm/memory.c
> > to return true if the address is in your ROMFS memory area.
> >
> Are you sure that is_in_rom is still in use? The only occurence that I
> found is in do_munmap() in mmnommu/mmap.c.


if MAGIC_ROM_PTR is in use (ie., XIP) then yes.

The problem with it occurs if it falsely says that something is in ROM.
This will stop it from running kfree on the memory as it assumes it was
a magic mmap into the romfs filesystem and doesn't need freeing.


Cheers,
Davidm

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

--__--__--

Message: 2
Date: Tue, 01 Apr 2003 07:31:10 +1000
From: John Williams <jwilliams at itee.uq.edu.au>
Organization: ITEE, UNiversity of Queendland
To: uclinux-dev at uclinux.org
Subject: Re: [uClinux-dev] Re: Populating blkmem
Reply-To: uclinux-dev at uclinux.org

Hi,

Thanks David, Miles and Thomas for your answers.  Plenty to go on now!
:)  I was missing the idea of how to make the romfs file look like
object code to link it into the kernel, but it's celar to me now.  I'm
simultaneously going after elf2flt, uClibc and the blkmem filesystem,
the remaining obvious loose threads for the microblaze port.  They are
kind of intimately related in many ways, so I'll just keep chipping away
at all 3 until I get something working.

I'll probably keep following Miles' lead for now, that strategy has
worked well for me so far!

John


--__--__--

Message: 3
Date: Tue, 01 Apr 2003 07:34:47 +1000
From: John Williams <jwilliams at itee.uq.edu.au>
Organization: ITEE, UNiversity of Queendland
To: uclinux-dev at uclinux.org
Subject: Re: [uClinux-dev] porting elf2flt
Reply-To: uclinux-dev at uclinux.org

Hi David,

David McCullough wrote:
> Jivin John Williams lays it down ...
>
>>Can anybody tell me where I will find the information required to fill
>>out the various entries in elf.h, and associated case statements in
>>elf2flt.c?
>
> They should be in the binutils sources.  When you configure elf2flt you
> tell it a few dirs to work with.  You may need to change the include of:
>
>       <elf.h>
>
> in elf2flt.c to something like:
>
>       <elf/?microblaze?.h>

I don't have a "native" microblaze elf.h, but I copied the one from
uClibc/include into my elf2flt dev directory.  I intend to extend it in
a way similar to that for the other arch's.

> You will probably want to run elf2flt without any relocations
> implemented first so that you can see which ones will be needed,  then
> only implement those that give errors (a number you can then lookup in
> the header file).
>
> You can also run:
>
>       $(CROSS)objdump -r elf-file
>
> to list the "names" of the relocations among other things.  These names
> can be greped from the binutils sources.

Good tips, thanks.

> I am just doing some elf2flt work myself,  so if you need a hand feel
> free to bounce stuff off me,

Thanks, I'll probably take you up on that.  Should we take it off-list
or might this stuff be useful to someone else one day?  I'm finding the
uclinux-dev list server to be pretty slow lately - up to 90 mins or so
between sending and getting it back?

Cheers,

John


--__--__--

Message: 4
Date: Mon, 31 Mar 2003 13:54:42 -0800
From: Michael Caisse <mcaisse at allweatherinc.com>
To: uclinux-dev at uclinux.org
Subject: Re: [uClinux-dev] increasing baud rate
Reply-To: uclinux-dev at uclinux.org

I'm running my console at 115200.

In colilo modify your vendor specific board.c file. Change the
configureSerial call in the configureConsole() method to set
the baud rate to your favorite number.

Under uCLinux I use the compiled-in kernel boot parameter
which can be found under "Processor type and features"
(CONFIG_BOOTPARAM_STRING).
I've set mine to:

    CONSOLE=/dev/ttyS0,115200

That should do it for you. Dominique mentioned having problems finding
this selection. You may have to edit the arch/m68knommu/config.in file
directly for your platform. Other examples of this should be in the file
already.

michael


Massimiliano Cialdi wrote:

>I need to increase the console boud rate from 19200 to 57600 or 115200.
>It would better af colilo get the same baud rate too. How can I increase
>the baud rate?
>
>thanks
>
>
>



--__--__--

Message: 5
Date: Tue, 1 Apr 2003 08:38:51 +1000
From: David McCullough <davidm at snapgear.com>
To: uclinux-dev at uclinux.org
Subject: Re: [uClinux-dev] porting elf2flt
Reply-To: uclinux-dev at uclinux.org


Jivin John Williams lays it down ...
> Hi David,
>
> David McCullough wrote:
> >Jivin John Williams lays it down ...
> >
> >>Can anybody tell me where I will find the information required to fill
> >>out the various entries in elf.h, and associated case statements in
> >>elf2flt.c?
> >
> >They should be in the binutils sources.  When you configure elf2flt you
> >tell it a few dirs to work with.  You may need to change the include of:
> >
> >     <elf.h>
> >
> >in elf2flt.c to something like:
> >
> >     <elf/?microblaze?.h>
>
> I don't have a "native" microblaze elf.h, but I copied the one from
> uClibc/include into my elf2flt dev directory.  I intend to extend it in
> a way similar to that for the other arch's.


Having just started playing with elf2flt on H8,  I just included the
correct file (elf/h8.h) from binutils and automatically got all the defines.
I will be checking in the changes to that effect once I get it going ;-)


If yo udon't have binutils sources that's a problem.  Although you will
probably need them to get a working elf2flt as it uses the bfd library
from the cross targeted binutils.


...
> >I am just doing some elf2flt work myself,  so if you need a hand feel
> >free to bounce stuff off me,
>
> Thanks, I'll probably take you up on that.  Should we take it off-list
> or might this stuff be useful to someone else one day?  I'm finding the
> uclinux-dev list server to be pretty slow lately - up to 90 mins or so
> between sending and getting it back?

I don't mind either way really,  if we end up with a uCdot FAQ or
something it is probably better than a whole lot of elf2flt
conversations, but I'm sure most won't compain ;-)

Cheers,
Davidm

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

--__--__--

Message: 6
Date: Tue, 1 Apr 2003 00:58:44 +0200
From: Abraham van der Merwe <abz at frogfoot.net>
To: uCLinux Development <uclinux-dev at uclinux.org>
Organization: Frogfoot Networks CC
Subject: [uClinux-dev] eb55/uclinux questions
Reply-To: uclinux-dev at uclinux.org

Hi!

I've got a couple of questions about the eb55 uclinux port:

If anyone else can answer any of these questions feel free to help out.

Here we go:

 (a) What should the boot loader in order to boot the kernel? Assuming you
     concatenate linux.text and linux.data and the boot loader loads it into
     0x2000000 and branches to it, should it work or does it need to do some
     other initialization first?

 (b) Looking at head-arm-atmel.S there is a few things that confuses me:

     You store DRAM_LIMIT in r13, but never use r13. Is there any code which
     assumes r13 contains DRAM_LIMIT or is this redundant code?

     Where do you get these values from:

LC0:    .long edata
    .long arm_id
    .long end
    .long init_kernel_stack + 4096

     There's no linker script so I have no idea how edata and end gets
     calculated. In addition, there's this piece of code which is supposed
     to initialize arm_id, but 0x41007000 is a completely bogus register

    ldr r2,=0x41007000      /* Hmm...???  What's this? */
    str r2, [r6]

     What should arm_id be set to (it should obviously be initialized
     because it is needed later on by setup_arch())

 (c) The way I see it, life starts for the kernel as follows:

     __stext
      start_kernel
       setup_arch
        get_processor_type
        ...

     get_processor_type goes on to select a processor struct depending on
     arm_id (which is uninitialized at this stage and causes the system to
     lock up).

     Also, printk() is used long before the console is initialized. Is this
     valid?

 (d) The kernel is split into text and data images as follows:

------------< snip <------< snip <------< snip <------------
    $(CROSS_COMPILE)objcopy -O binary --remove-section=.romvec \
            --remove-section=.text --remove-section=.ramvec \
            --remove-section=.init \
            --remove-section=.bss --remove-section=.eram \
            $(ROOTDIR)/$(LINUXDIR)/linux $(IMAGEDIR)/linux.data
    $(CROSS_COMPILE)objcopy -O binary --remove-section=.ramvec \
            --remove-section=.bss --remove-section=.data \
            --remove-section=.eram \
            --set-section-flags=.romvec=CONTENTS,ALLOC,LOAD,READONLY,CODE \
            $(ROOTDIR)/$(LINUXDIR)/linux $(IMAGEDIR)/linux.text
------------< snip <------< snip <------< snip <------------

     However, these commands don't strip out .rodata in the second objcopy,
     so it is duplicated in both images. Why didn't you use a linker script
     to do all of this?

 (e) If I want to boot the kernel from flash, what do I need to setup/modify
     before booting the kernel?

--

Regards
 Abraham

Yesterday upon the stair
I met a man who wasn't there.
He wasn't there again today --
I think he's from the CIA.

___________________________________________________
 Abraham vd Merwe - Frogfoot Networks CC
 9 Kinnaird Court, 33 Main Street, Newlands, 7700
 Phone: +27 21 686 1674 Cell: +27 82 565 4451


--__--__--

Message: 7
Date: Tue, 01 Apr 2003 09:18:02 +1000
From: John Williams <jwilliams at itee.uq.edu.au>
Organization: ITEE, UNiversity of Queendland
To: uclinux-dev at uclinux.org
Subject: Re: [uClinux-dev] porting elf2flt
Reply-To: uclinux-dev at uclinux.org

Hi David,

David McCullough wrote:
> Having just started playing with elf2flt on H8,  I just included the
> correct file (elf/h8.h) from binutils and automatically got all the
defines.
> I will be checking in the changes to that effect once I get it going ;-)

> If yo udon't have binutils sources that's a problem.  Although you will
> probably need them to get a working elf2flt as it uses the bfd library
> from the cross targeted binutils.

I just finished untaring the binutils/gcc sources, and have found the
header file you are talking about for microblaze.  It's got the various
reloc data in there, so I'm on the right track with that now.

> I don't mind either way really,  if we end up with a uCdot FAQ or
> something it is probably better than a whole lot of elf2flt
> conversations, but I'm sure most won't compain ;-)

OK well maybe we'll go off-list and then FAQ it after we're done?

John


--__--__--

Message: 8
Date: Mon, 31 Mar 2003 15:22:48 -0700
From: David Jones <david at embeddedminds.com>
Organization: Embedded Minds Design Group
To: uclinux-dev at uclinux.org
Subject: [uClinux-dev] MTD w/uClinux: Kernel hangs when trying to probe
AM29LV160DB flash
 device
Reply-To: uclinux-dev at uclinux.org


Hi,
    I am trying to get an AM29LV160DB flash device to work with the MTD
drivers under uClinux.  The device is connected in a 16-bit bus
fashion to a Motorola MC68VZ328.

The AM29LV160DB is supported by mtd/chips/jedec_probe.c

In my map file I have:
mymtd = do_map_probe("jedec_probe", &em1vz328_map);

The do_map_probe function calls get_mtd_chip_driver in mtd/mtd/chipreg.c
and that is where things seem to hang.  The get_mtd_chip_driver function
never returns and hangs the kernel.

Here is a snippet of the boot messages:
---------------------------------------------------------
.
.
EMDG em1-vz328 mapping:size 200000 at 2000000
EMDG: MTD Debug: Calling the do_map_probe function...
EMDG: MTD Debug: Calling get_mtd_chip_driver function...

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

I looked through the archives and I noticed someone else had a similar
problem with this flash device under uClinux, but I could not find what
the solution was.

If anyone has any ideas I would be grateful.

Thanks,
David


Kernel config:
#
# Memory Technology Devices (MTD)
#
CONFIG_MTD=y
CONFIG_MTD_DEBUG=y
CONFIG_MTD_DEBUG_VERBOSE=3
CONFIG_MTD_PARTITIONS=y
# CONFIG_MTD_CONCAT is not set
# CONFIG_MTD_REDBOOT_PARTS is not set
# CONFIG_MTD_CMDLINE_PARTS is not set

#
# User Modules And Translation Layers
#
CONFIG_MTD_CHAR=y
# CONFIG_MTD_BLOCK is not set
CONFIG_MTD_BLOCK_RO=y
# CONFIG_FTL is not set
# CONFIG_NFTL is not set

#
# RAM/ROM/Flash chip drivers
#
CONFIG_MTD_CFI=y
CONFIG_MTD_JEDECPROBE=y
CONFIG_MTD_GEN_PROBE=y
CONFIG_MTD_CFI_ADV_OPTIONS=y
CONFIG_MTD_CFI_NOSWAP=y
# CONFIG_MTD_CFI_BE_BYTE_SWAP is not set
# CONFIG_MTD_CFI_LE_BYTE_SWAP is not set
CONFIG_MTD_CFI_GEOMETRY=y
# CONFIG_MTD_CFI_B1 is not set
CONFIG_MTD_CFI_B2=y
# CONFIG_MTD_CFI_B4 is not set
CONFIG_MTD_CFI_I1=y
# CONFIG_MTD_CFI_I2 is not set
# CONFIG_MTD_CFI_I4 is not set
# CONFIG_MTD_CFI_INTELEXT is not set
# CONFIG_MTD_CFI_AMDSTD is not set
CONFIG_MTD_RAM=y
# CONFIG_MTD_ROM is not set
# CONFIG_MTD_ABSENT is not set
# CONFIG_MTD_OBSOLETE_CHIPS is not set

--
David A. Jones                  Phone:  720-971-6381
Embedded Minds Design Group     Fax:    303-926-0208
www.EmbeddedMinds.com           Email:  david at EmbeddedMinds.com



--__--__--

Message: 9
To: David McCullough <davidm at snapgear.com>
Cc: uclinux-dev at uclinux.org
From: Miles Bader <miles at lsi.nec.co.jp>
Date: 01 Apr 2003 10:20:32 +0900
Subject: [uClinux-dev] Re: Populating blkmem
Reply-To: uclinux-dev at uclinux.org

David McCullough <davidm at snapgear.com> writes:
> Another option is to follow the coldfire examples which just cat the
> romfs onto the end of the image and look for it at _ebss.

The reason I don't do this for my targets is because I often use a
debugger to load the image onto the board, and the debugger needs a
proper ELF file to load.

As I already need the infrastructure to do that, it's also simpler for
me to just use the same mechanism for other targets that do just use a
single binary image (e.g. where I'm booting from flash).

-Miles
--
`Life is a boundless sea of bitterness'

--__--__--

Message: 10
Date: Tue, 1 Apr 2003 11:50:46 +1000
From: David McCullough <davidm at snapgear.com>
To: Miles Bader <miles at gnu.org>
Cc: uclinux-dev at uclinux.org
Subject: [uClinux-dev] Re: Populating blkmem
Reply-To: uclinux-dev at uclinux.org


Jivin Miles Bader lays it down ...
> David McCullough <davidm at snapgear.com> writes:
> > Another option is to follow the coldfire examples which just cat the
> > romfs onto the end of the image and look for it at _ebss.
>
> The reason I don't do this for my targets is because I often use a
> debugger to load the image onto the board, and the debugger needs a
> proper ELF file to load.


It is still possible,  from the vendors/SnapGear/SOHO+/Makefile:

        BSS=`m68k-elf-objdump --headers $(ROOTDIR)/$(LINUXDIR)/linux | \
                grep .bss` ; \
                ADDR=`set -- $${BSS} ; echo 0x$${4}` ; \





           m68k-elf-objcopy --add-section=.romfs=$(ROOTDIR)/images/romfs.img
\
                        --adjust-section-vma=.romfs=$${ADDR} --no-adjust-war
nings \
                        --set-section-flags=.romfs=alloc,load,data \
                        $(ROOTDIR)/$(LINUXDIR)/linux
$(ROOTDIR)/images/image.elf

We use this to load elf images with a romfs through gdb/BDM and it works
fine.


> As I already need the infrastructure to do that, it's also simpler for
> me to just use the same mechanism for other targets that do just use a
> single binary image (e.g. where I'm booting from flash).


Either way is fine and completely valid.  A lot of other platforms have
done it that way in the past.  I just feel that having the kernel/romfs
step intermixed is a little messy.  Others, I am sure,  would disagree :-)
:-)


Cheers,
Davidm

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

--__--__--

Message: 11
From: =?utf-8?B?5p2o5Lqa5Yab?= <yangyajun at hisense.cngb.com>
To: <uclinux-dev at uclinux.org>
Subject: Re: [uClinux-dev] Where to init chip select in 2.4 kernel
Date: Tue, 1 Apr 2003 09:42:56 +0800
Reply-To: uclinux-dev at uclinux.org

To 于æµ*æ´‹ï1/4š
               Thank you very much!
               æˆ'还想é-(r)一下ï1/4Œå"ªèƒ1/2æ‰3/4到ä"‹ç" linux
下汇ç1/4-çš"èµ"æ-(tm)ï1/4Ÿ

To Manigandan.V:
        There is no this file in all uClinux I have ( I have three  editions
of  uClinux ) . Can you send me one?


----- Original Message -----
From: "Manigandan.V" <manigandanv at myw.ltindia.com>
To: <uclinux-dev at uclinux.org>
Sent: Monday, March 31, 2003 2:50 PM
Subject: Re: [uClinux-dev] Where to init chip select in 2.4 kernel


Hi,
 You can look at any driver in your uClinux-dist/linux-2.4.x/drivers/
If you want an example init just have a look at
uClinux-dist/linux-2.4.x/drivers/char/t6963fb.c (t6963fb_init() does CS init
in this file)

-
Mani

----- Original Message -----
From: "杨亚军" <yangyajun at hisense.cngb.com>
To: <uclinux-dev at uclinux.org>
Sent: Monday, March 31, 2003 11:34 AM
Subject: Re: [uClinux-dev] Where to init chip select in 2.4 kernel


Hi, manigandan.V

       Can you tell me where I   can  find some examples ?
        Thank  you  very much!



----- Original Message -----
From: "Manigandan.V" <manigandanv at myw.ltindia.com>
To: <uclinux-dev at uclinux.org>
Sent: Monday, March 31, 2003 1:10 PM
Subject: Re: [uClinux-dev] Where to init chip select in 2.4 kernel


>>normally this is done in the bootloader, not in the uclinux
True,but not always .

>>bootloader should set up all the chip select, memory remaping... and pass
the
>>control to the kernel (uclinux)
You can do CS init in your driver init module.

> Ã'Ã(r)Ã'ÇÂ3/4Ã1/4 wrote:
>
> Can anyone help me?
>
> Thank you!
_______________________________________________
uClinux-dev mailing list
uClinux-dev at uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev at uclinux.org

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

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

--__--__--

Message: 12
From: "Simon Hsu" <simon at inprocomm.com>
To: <uclinux-dev at uclinux.org>
Date: Tue, 1 Apr 2003 12:21:56 +0800
Subject: [uClinux-dev] Rrgarding Motorola M5407C3 EVB
Reply-To: uclinux-dev at uclinux.org

This is a multi-part message in MIME format.

------=_NextPart_000_000F_01C2F849.497439D0
Content-Type: text/plain;
        charset="big5"
Content-Transfer-Encoding: quoted-printable

Hi,

I just got a Motorola M5407C3 EVB and would like to know does
anyone successfully work with a PCI device in this EVB.
The uClinux distribution I am working is uClinux-dis-20030305.tar.gz.
I got the compiling error when I enable  PCI and loadable module =
support.
Any comment will be appreciateed!

Simon=20

------=_NextPart_000_000F_01C2F849.497439D0
Content-Type: text/html;
        charset="big5"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Dbig5" http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.3502.5390" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DMingLiu size=3D2>Hi,</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3D=B2=D3=A9=FA=C5=E9 size=3D2>I just got a Motorola =
M5407C3 EVB and would like to=20
know does</FONT></DIV>
<DIV><FONT face=3D=B2=D3=A9=FA=C5=E9 size=3D2>anyone successfully work =
with a PCI device in this=20
EVB.</FONT></DIV>
<DIV><FONT face=3D=B2=D3=A9=FA=C5=E9 size=3D2>The uClinux distribution I =
am working is=20
uClinux-dis-20030305.tar.gz.</FONT></DIV>
<DIV><FONT face=3D=B2=D3=A9=FA=C5=E9 size=3D2>I got the compiling error =
when I enable  PCI and=20
loadable module support.</FONT></DIV>
<DIV><FONT face=3D=B2=D3=A9=FA=C5=E9 size=3D2><FONT face=3DMingLiu>Any =
comment </FONT>will be=20
appreciateed!</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3D=B2=D3=A9=FA=C5=E9 =
size=3D2>Simon</FONT> </DIV></BODY></HTML>

------=_NextPart_000_000F_01C2F849.497439D0--



--__--__--

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

End of uClinux-dev Digest





More information about the uClinux-dev mailing list