headers
li | 1 Jul 2003 09:28
Favicon

MPC8260 support


Denx,
I am going to work on an custom mpc8260 board, does the ppcboot-1.1.6 support mpc8260 and the kernel
download from
your ftp site  support mpc8260?
Regards!
Li

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Permalink | Reply | 0 comments |
headers
yong_guo | 1 Jul 2003 10:48

snmp agent on embedded linux!


hi all,
   Anyone who has experience in porting the ucd-snmp packet on embedded
linux running on ppc8xx or ppc82xx?

   thx!

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Permalink | Reply | 1 comment |
headers
Wojciech Kromer | 1 Jul 2003 11:01
Picon

Re: snmp agent on embedded linux!


Użytkownik yong_guo napisał:

>hi all,
>   Anyone who has experience in porting the ucd-snmp packet on embedded
>linux running on ppc8xx or ppc82xx?
>
>
>
there was pre-compiled version in HardHat,
and source compiles with eldk corss-compiler

--
* * * * * * * * * * * *
* per pedes ad astra! *
* * * * * * * * * * * *    mailto:krom <at> dgt-lab.com.pl

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Permalink | Reply | 0 comments |
headers
nbasker | 1 Jul 2003 16:50

problems in SCC-UART in mpc860


Hi:

I am trying to use a SCC configured in UART to communicate with a intel
pc via modem. The configuration is simple and shown below

target --- modem -------phoneline---- modem----i386pc

target configuration:
1. mpc860T custom board
2. scc2 configured in uart
3. linux-2-2-14 from montavista
4. patched 8xx_io/uart.c from 2.2.4 kernel from Denks
5. using mgetty/pppd to program modem and start pppd.

host configuration:
1. i368pc running 2.2.14-12 redhat kernel
2. using pppd/chat to dialup to target modem.

In this setup if use PCSO to enable RTS, CTS and CD along with
crtscts option in pppd nothing works. If I disable PCSO and use
nocrtscts option in pppd, LCP connection goes through but IPCP
exchange at target fails (it never sends ConfigAck packet towards host).

I am able to get the setup working using null modem cable enabling
RTS/CTS/CD via PCSO register as well as pppd options.

Since I am able to get SCC2/UART working with nullmodem, but not
with actual modem, should I suspect hardware signal connectivity as
a problem source?. I suspected the uart driver and went through
(Continue reading)

Permalink | Reply | 4 comments |
headers
Mark A. Greer | 1 Jul 2003 19:24

Re: problems in SCC-UART in mpc860


What's the PVR of your 860?

Mark
--

nbasker <at> india.tejasnetworks.com wrote:

>Hi:
>
>I am trying to use a SCC configured in UART to communicate with a intel
>pc via modem. The configuration is simple and shown below
>
>target --- modem -------phoneline---- modem----i386pc
>
>target configuration:
>1. mpc860T custom board
>2. scc2 configured in uart
>3. linux-2-2-14 from montavista
>4. patched 8xx_io/uart.c from 2.2.4 kernel from Denks
>5. using mgetty/pppd to program modem and start pppd.
>
>host configuration:
>1. i368pc running 2.2.14-12 redhat kernel
>2. using pppd/chat to dialup to target modem.
>
>In this setup if use PCSO to enable RTS, CTS and CD along with
>crtscts option in pppd nothing works. If I disable PCSO and use
>nocrtscts option in pppd, LCP connection goes through but IPCP
>exchange at target fails (it never sends ConfigAck packet towards host).
(Continue reading)

Permalink | Reply | 1 comment |
headers
Kent Borg | 1 Jul 2003 22:29

Large initrd and arch/ppc/boot/simple Question


We are booting our kernel via the arch/ppc/boot/simple mechanism to
package up our kernel and initrd.  It seems to work, until we get too
big.  What is big?  Roughly 8 MB for our one big uncompressed userland
program, plus the kernel, bash, busybox, and various userland
utilities.

Can initrd's get that large and still work?  Is the simple boot code
sensible with these sizes?  (I notice that the "avail ram" message
that gets printed is just hard coded number...)

Thanks,

-kb, the Kent who is running roughly 2.4.21-pre6.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Permalink | Reply | 6 comments |
headers
Kerl, John | 1 Jul 2003 22:34
Favicon

RE: Large initrd and arch/ppc/boot/simple Question


8 MB compressed (& if so: zvmlinux.initrd or
ramdisk.image.gz?) , or 8 MB uncompressed RAM
disk?

If the latter:  I've successfully used a RAM disk of
12 or 16 MB.  You need to (a) go into your kernel
config and set CONFIG_BLK_DEV_RAM_SIZE, and (b) modify
whatever it is that creates your RAM disk image
(dd + mke2fs perhaps).

If the former:  you might check the RAM address
of your firmware, the RAM runtime address of the
boot wrapper (-Ttext ???? in arch/ppc/boot/simple/Makefile),
and the size of your RAM.  The firmware needs to jump
into zvmlinux.initrd, which will copy itself to the
-Ttext address, then decompress the kernel to 0 and
copy the RAM disk to the end of RAM.  You can have
problems if any of these things overlap.

-----Original Message-----
From: Kent Borg [mailto:kentborg <at> borg.org]
Sent: Tuesday, July 01, 2003 1:30 PM
To: linuxppc-embedded <at> lists.linuxppc.org
Subject: Large initrd and arch/ppc/boot/simple Question

We are booting our kernel via the arch/ppc/boot/simple mechanism to
package up our kernel and initrd.  It seems to work, until we get too
big.  What is big?  Roughly 8 MB for our one big uncompressed userland
program, plus the kernel, bash, busybox, and various userland
(Continue reading)

Permalink | Reply | 0 comments |
headers
Wolfgang Denk | 1 Jul 2003 22:38
Picon
Picon
Favicon

Re: Large initrd and arch/ppc/boot/simple Question


Dear Kent,

in message <20030701162944.E20876 <at> borg.org> you wrote:
>
> We are booting our kernel via the arch/ppc/boot/simple mechanism to
> package up our kernel and initrd.  It seems to work, until we get too
> big.  What is big?  Roughly 8 MB for our one big uncompressed userland
> program, plus the kernel, bash, busybox, and various userland
> utilities.
>
> Can initrd's get that large and still work?  Is the simple boot code
> sensible with these sizes?  (I notice that the "avail ram" message
> that gets printed is just hard coded number...)

I don't know  about  the  "simple  boot  code".  With  U-Boot,  we're
successfully  using  ramdisk  images which uncompress into 128 MB and
bigger filesystems. [And no, please don't ask me who needs that  many
stuff in a ramdisk, nor if there is not any better way to do this.]

Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd <at> denx.de
A rolling stone gathers momentum.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kent Borg | 1 Jul 2003 23:51

Re: Large initrd and arch/ppc/boot/simple Question


Looking more, it seems that we are (at minimum) killing the kernel by
asking for too much memory.  We are seeing whether we can reproduce
that with a simpler program.

-kb

In the meantime, here is some output of and about our crash:

  $ size bigapp.strip
     text	   data	    bss	    dec	    hex	filename
  7465252	  97296	 401844	7964392	 7986e8	bigapp.strip
  $ size /tftpboot/zImage.initrd.elf
     text	   data	    bss	    dec	    hex	filename
    24896	6856704	  12732	6894332	 6932fc	/tftpboot/zImage.initrd.elf

  loaded at:     02000000 026941BC
  zimage at:     02007D34 02097813
  initrd at:     02098000 02690529
  avail ram:     00400000 01000000

  Linux/PPC load: console=ttyS0,115200 ip=off mem=48m
  Uncompressing Linux...done.
  Now booting the kernel
  Warning hardcoded alaska_find_end_of_memory() alaska.c:172
  Memory BAT mapping: BAT2=32Mb, BAT3=16Mb, residual: 32Mb
  Linux version 2.4.21-rc1 (pbarada <at> hyper) (gcc version 3.2.2) #136 Tue Jul 1 16:36:46 EDT 2003
  On node 0 totalpages: 12288
  zone(0): 12288 pages.
  zone(1): 0 pages.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Mark Hatle | 2 Jul 2003 00:07

Re: Large initrd and arch/ppc/boot/simple Question


This is based on my past observations, and may not reflect the current
version of 2.4.x.

Yes, you can definatly kill a kernel by asking for too much memory.
This is especially true if you do not have swap enabled, which in my
experience is rather rare on embedded systems.  I THINK there is a
mechanism that you can turn off over commit of memory which will allow
you to kill processors requesting the memory that doesn't exist.  The
only problem with that is depending on how you do this overcommit
control you have to accoutn for COW pages, and other things that may
blow you out.

The best you can hope for is "Under normal circumstances my system
should use this much memory, I will give it X * 1.5 (or some other
reasonable amount)."

This is something that needs to be worked out between the hardware and
software folks, unfortunatly it rarely seems to be and you get bogus
"This product WILL run under 8MB of ram no matter what requirements...
ohh and did I mention it needs to have 16 MB worth of ramdisk?"   heh

So in short, no the kernel shouldn't oops when it runs out of memory.
However what is the "correct" thing to do has been debated many times,
and depending on the application returning ENOMEM may be appropriate,
crashing (to cause a reboot) may be appriopriate or a whole host of
other things like killing off the offending process (or a lower priority
process even).  It all comes down to system requirements.

--Mark
(Continue reading)

Permalink | Reply | 1 comment |

Gmane