* linux kernel hang in execve("/sbin/init")
From: Eric Nuckols @ 2006-07-22 6:10 UTC (permalink / raw)
To: linuxppc-embedded
I googled...and googled...etc. etc.. when trying to solve the problem of my
linux kernel seemingly locking or hanging when it gets to the last part of
the linux init in main.c
I saw lots of information and suggestions related to try /bin/sh or make
sure your initrd is ok or make sure you have more than one session..etc.
etc... .. and all of these topics were mostly from 2001-2003...well..
2006...it's here and apparently some of us haven't gotten smarter..
I had this problem recently where my kernel would boot and freeze or hang in
execve of /sbin/init and also of /bin/sh or /bin/bash...
I debugged and debugged.. and finally thougt... why not try the default
Kernel config for my target, the PrPmc800 from Motorola... and see what that
does.. Originally, I started with the MontaVista 3.1 Pro setup for the
board and it works...so I used it's Kernel .config file to configure my
latest and greatest (at the time) 2.6.16.18 kernel thinking... well.. this
has to work..
so.. I ended up with a kernel that semingly hang/froze/locked on the execve
call in the linux init routines...
guess what folks... the google searches left me just on the verge of giving
up.
I am here to post this info as somewhat of another answer/alternative to
people in the same predicament...
if you are having problems with your cross-compiled / embedded ppc kernel
freezing or hanging on execve, try using the default configuration for your
target when you build the kernel...
in my case, I did this sort of thing and all of a sudden, my kernel was
working:
cd to kernel dir
make distclean
make CROSS_COMPILE=powerpc-7400-linux-gnu- prpmc800_defconfig
make zImage.initrd
etc..etc..
it turns out that since I was basing my initial config off of the 2.4.x
.config from MontaVista, my kernel didn't boot as desired...
so I figured.. after all the googling and working on it that the default
PrPmc800 config had to boot... why else call it the default config..
so that's my story.. since then, I have copied the kernel
dir/arch/ppc/configs/prpmc800_defconfig to a temporary file, and modified it
as necessary...
moral of the story... if you are cross-compiling and having problems where
you hang on execve("/sbin/init") or execve("/bin/sh") or
execve("/bin/bash")..etc... try what I did before you go crazy analyzing
the initrd or the various /etc/ file configurations or any of the other
typical bs...
^ permalink raw reply
* Re:Re: AltiVec in the kernel
From: Konstantinos Margaritis @ 2006-07-22 9:38 UTC (permalink / raw)
To: Hollis Blanchard, Linas Vepstas, Matt Sealey
Cc: 'Olof Johansson', 'linuxppc-dev list',
'Paul Mackerras', Konstantinos Margaritis
(Writing this on a wap mobile phone)
actually, i knew about steve's effort as i am subscribed to glibc-ports. the problem is i am doing my military service this whole period (right now i am a sentry guard at an oupost somewhere in rhodes :-). the good news is that in about a month or less i'll return close to my home and i intend to get back to work asap. but till then i'm stuck here.
konstantinos
_____________________________
I sent this message from my cell phone using flurry.
Click here to get your email and news on your cell phone for free:
http://www.flurry.com
--- Original Message ---
Date: Fri Jul 21 14:30:56 PDT 2006
From: Hollis Blanchard <hollis@penguinppc.org>
To: Linas Vepstas <linas@austin.ibm.com>, Matt Sealey <matt@genesi-usa.com>
Subject: Re: AltiVec in the kernel
---
On Fri, 21 Jul 2006 11:51:30 -0500, "Linas Vepstas"
<linas@austin.ibm.com> said:
> On Fri, Jul 21, 2006 at 09:42:32AM -0500, Matt Sealey wrote:
> > http://www.freevec.org/
> >
> > Been there for months, before the glibc thing. Most of the functions
> > are ready. Anyone can bugfix this. The beauty of GPL. The ugly part
> > is.. we've had this there for months. Nobody has contributed a single
> > update or bugfix or even a performance test as far as I know.
>
> Sounds like a problem of advertising and communications. This is
> kind of "under the radar" for most users and developers. It needs to
> work out-of-the-box, most people, even those with interest in
> performance, will not even be aware of the possibility to tne this.
It is difficult to make sure every OSS developer is notified of all work
they may be interested in...
However, I have noticed a trend where Genesi people seem to think
everybody pays attention to their websites (and the same could be said
for Debian and other subcultures). In this case there actually have been
other people aware of this project, but not very many. Considering all
the traffic about it on ppczone.org, people looking for exposure for
their project may want to look beyond PPCZone.
> It should be folded into glibc. It is up to the altivec product vendor
> to nag the glibc folks into folding it in. This task could be as hard
> as writing the code in the first place.
Konstantinos is aware of Steve's glibc project and has indicated he'll
try to contribute to it.
To be fair, probably not many people have heard of Steve's project
either. I doubt Konstantinos would have heard of it if I hadn't
mentioned it.
-Hollis
^ permalink raw reply
* Re: [PATCH 0/6] bootwrapper: arch/powerpc/boot code reorg patches
From: Tom Rini @ 2006-07-22 15:04 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev
In-Reply-To: <20060719225356.GA3887@mag.az.mvista.com>
On Wed, Jul 19, 2006 at 03:53:56PM -0700, Mark A. Greer wrote:
> The following emails from me in this thread are the latest set of
> patches that reorg the bootwrapper code so that OF and non-OF
> platforms can live together.
>
> I punted somewhat on "The Tool" that's been talked about that takes a
> kernel and attaches a flattened device tree (fdt) to it. I thought
> about it for a while but I think we need to clarify the requirements
> better before it makes sense to spend a lot of cycles on it.
Great! As the last person to know what all this code was doing in
arch/ppc/boot, I'll try and give it all a review..
--
Tom Rini
^ permalink raw reply
* RE: AltiVec in the kernel
From: Matt Sealey @ 2006-07-23 13:28 UTC (permalink / raw)
To: 'Segher Boessenkool'
Cc: 'Olof Johansson', 'linuxppc-dev list',
'Paul Mackerras'
In-Reply-To: <bb0f53dbee5c7240daf6855454eca028@kernel.crashing.org>
> You could give Freevec a whole lot more exposure, to people
> who might be more interested in it than the average glibc
> user, by putting it into uClibc first.
[snip]
> You'll have to update uClibc's PowerPC port first though
> (mostly just copying stuff from recent glibc) -- it seems the
> libc AltiVec support (for handling setjmp() etc.) isn't in there yet.
I remember a discussion from one of the Gentoo guys wanting to do this
with libfreevec.
Getting into Gentoo, though, is not difficult. The problem with this
is Gentoo is one Linux distribution. I would be more impressed if code
was in Debian or Ubuntu considering their exhausting lead times on
producing new package trees and accepting new code :D
--
Matt Sealey <matt@genesi-usa.com>
Manager, Genesi, Developer Relations
^ permalink raw reply
* RE: AltiVec in the kernel
From: Benjamin Herrenschmidt @ 2006-07-23 21:37 UTC (permalink / raw)
To: matt
Cc: 'Olof Johansson', 'linuxppc-dev list',
'Paul Mackerras'
In-Reply-To: <006701c6ae5b$d5e83620$7302a8c0@bakuhatsu.net>
> I remember a discussion from one of the Gentoo guys wanting to do this
> with libfreevec.
>
> Getting into Gentoo, though, is not difficult. The problem with this
> is Gentoo is one Linux distribution. I would be more impressed if code
> was in Debian or Ubuntu considering their exhausting lead times on
> producing new package trees and accepting new code :D
It seems to me that the "problem" just doesn't exist at the moment...
libfreevec is nice, but it's unfinished, and the author is away for now
and thus not able to complete nor work on a port to glibc or others.
Once he's back, of course, it would be nice to have him complete the
work (and maybe get some outside help).
I'd like to also verify his methodology for measuring the performance
improvements, I'm not saying it's wrong, I want to make sure some of the
overhead of enabling altivec has been properly measured for various
usage patterns and thus possibly restrict the optimisations to patterns
where that matter, as an example, only use altivec for large memcpy's.
Once that's done, I don't see any good reason why it would be so hard to
include that work into glibc, or rather into the powerpc add-ons in a
first step and maybe then the whole into glibc. Maintainers rarely
rejects things just for the sake of doing so. If they do so, they
usually provide reasons, often boiling to implementation details, than
can then be fixed. Note also that in the case of submitting code to
glibc, there is a copyright assignment issue to be sorted out I think (I
don't know the details here).
I have the feeling that there is very little point to this thread. Let's
wait for Konstantinos to be back and submit his work, possibly to this
list at first for review, tests, etc... and then to the appropriate
maintainers. If there is a problem at that point, then we'll see how we
can address it.
Regards,
Ben.
^ permalink raw reply
* RE: [PATCH] powerpc: Add tsi108/9 and new hardware interface to mpic
From: Zang Roy-r61911 @ 2006-07-24 3:16 UTC (permalink / raw)
To: Zang Roy-r61911, Paul Mackerras, Benjamin Herrenschmidt
Cc: linuxppc-dev list, Alexandre.Bounine, Yang Xin-Xin-r48390
In-Reply-To: <7EA18FDD2DC2154AA3BD6D2F22A62A0E0456D0@zch01exm23.fsl.freescale.net>
>=20
> The patch add new hardware information table for mpic. This=20
> enables mpic
> code=20
> to deal with OpenPIC controller with hardware behavior difference.
> Add TSI108/109 PIC hardware information table. The=20
> Tsi108/109 PIC looks
> like=20
> standard OpenPIC but, in fact, is different in registers mapping and
> behavior.
> =20
> Signed-off-by: Alexandre Bounine <alexandreb@tundra.com>
> Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>=20
>=20
> ---
Ben,
How do you think the new hardware information entry for mpic?
Thanks.
Roy
^ permalink raw reply
* Why the "opd" section?
From: Jonathan Bartlett @ 2006-07-24 4:01 UTC (permalink / raw)
To: linuxppc-dev
I'm learning PPC64 assembly language, and I found the existence of the
"opd" sections containing function descriptors quite odd. What is the use
of these? Are they used by the linker? Why are they needed in the 64-bit
ELF platforms and not the 32-bit ones?
Thanks,
Jon
^ permalink raw reply
* [PATCH] use gcc -O1 in fs/reiserfs only for ancient gcc versions
From: Olaf Hering @ 2006-07-24 6:52 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev, reiserfs-dev
In-Reply-To: <20051011190133.GA31348@suse.de>
only compile with -O1 if the (very old) compiler is broken.
We use reiserfs alot since SLES9 on ppc64, and it was never seen
with gcc33.
Assume the broken gcc is gcc-3.4 or older.
Signed-off-by: Olaf Hering <olh@suse.de>
---
fs/reiserfs/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6.18-rc2/fs/reiserfs/Makefile
===================================================================
--- linux-2.6.18-rc2.orig/fs/reiserfs/Makefile
+++ linux-2.6.18-rc2/fs/reiserfs/Makefile
@@ -28,7 +28,7 @@ endif
# will work around it. If any other architecture displays this behavior,
# add it here.
ifeq ($(CONFIG_PPC32),y)
-EXTRA_CFLAGS := -O1
+EXTRA_CFLAGS := $(call cc-ifversion, -lt, 0400, -O1)
endif
TAGS:
^ permalink raw reply
* [PATCH] enable mac partition label per default on pmac
From: Olaf Hering @ 2006-07-24 7:00 UTC (permalink / raw)
To: Andrew Morton, linuxppc-dev
Enable mac partition table support per default also for a powermac config.
Signed-off-by: Olaf Hering <olh@suse.de>
---
fs/partitions/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6.18-rc2/fs/partitions/Kconfig
===================================================================
--- linux-2.6.18-rc2.orig/fs/partitions/Kconfig
+++ linux-2.6.18-rc2/fs/partitions/Kconfig
@@ -99,7 +99,7 @@ config IBM_PARTITION
config MAC_PARTITION
bool "Macintosh partition map support" if PARTITION_ADVANCED
- default y if MAC
+ default y if (MAC || PPC_PMAC)
help
Say Y here if you would like to use hard disks under Linux which
were partitioned on a Macintosh.
^ permalink raw reply
* Re: linux kernel hang in execve("/sbin/init")
From: Stephen Telfer @ 2006-07-24 6:34 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <BAY117-F38602DE22BC1EB7A1E1660C8670@phx.gbl>
Hi Eric -
Sometimes a hang at this point can be down to a mismatch between
toolchain, C library and kernel about whether floating point is
implemented, emulated or absent. Early in one of the shared libraries
there are a string of saves of FP registers, and if your CPU has no FPU
and your kernel has no FPU emulation this will be terminal (and
silently so). A printk statement in the illegal instruction trap
handler would confirm this hypothesis.
Hope this helps,
Stig
On 22 Jul 2006, at 07:10, Eric Nuckols wrote:
> I googled...and googled...etc. etc.. when trying to solve the problem
> of my
> linux kernel seemingly locking or hanging when it gets to the last
> part of
> the linux init in main.c
>
> I saw lots of information and suggestions related to try /bin/sh or
> make
> sure your initrd is ok or make sure you have more than one
> session..etc.
> etc... .. and all of these topics were mostly from 2001-2003...well..
> 2006...it's here and apparently some of us haven't gotten smarter..
>
> I had this problem recently where my kernel would boot and freeze or
> hang in
> execve of /sbin/init and also of /bin/sh or /bin/bash...
>
> I debugged and debugged.. and finally thougt... why not try the default
> Kernel config for my target, the PrPmc800 from Motorola... and see
> what that
> does.. Originally, I started with the MontaVista 3.1 Pro setup for
> the
> board and it works...so I used it's Kernel .config file to configure my
> latest and greatest (at the time) 2.6.16.18 kernel thinking... well..
> this
> has to work..
>
> so.. I ended up with a kernel that semingly hang/froze/locked on the
> execve
> call in the linux init routines...
>
> guess what folks... the google searches left me just on the verge of
> giving
> up.
>
> I am here to post this info as somewhat of another answer/alternative
> to
> people in the same predicament...
>
> if you are having problems with your cross-compiled / embedded ppc
> kernel
> freezing or hanging on execve, try using the default configuration for
> your
> target when you build the kernel...
>
> in my case, I did this sort of thing and all of a sudden, my kernel was
> working:
>
> cd to kernel dir
> make distclean
> make CROSS_COMPILE=powerpc-7400-linux-gnu- prpmc800_defconfig
> make zImage.initrd
>
> etc..etc..
>
> it turns out that since I was basing my initial config off of the 2.4.x
> .config from MontaVista, my kernel didn't boot as desired...
>
> so I figured.. after all the googling and working on it that the
> default
> PrPmc800 config had to boot... why else call it the default config..
>
> so that's my story.. since then, I have copied the kernel
> dir/arch/ppc/configs/prpmc800_defconfig to a temporary file, and
> modified it
> as necessary...
>
> moral of the story... if you are cross-compiling and having problems
> where
> you hang on execve("/sbin/init") or execve("/bin/sh") or
> execve("/bin/bash")..etc... try what I did before you go crazy
> analyzing
> the initrd or the various /etc/ file configurations or any of the other
> typical bs...
>
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* [PATCH] hide onboard graphics drivers on G5
From: Olaf Hering @ 2006-07-24 7:22 UTC (permalink / raw)
To: Andrew Morton, linuxppc-dev
Hide the video drivers for onboard graphics found in early PCI PowerMacs
in Apple G5 config files.
drivers/built-in.o: In function `.platinumfb_probe':
platinumfb.c:(.text+0x377a0): undefined reference to `.nvram_read_byte'
platinumfb.c:(.text+0x37830): undefined reference to `.nvram_read_byte'
drivers/built-in.o: In function `.control_init':
controlfb.c:(.init.text+0x1938): undefined reference to `.nvram_read_byte'
controlfb.c:(.init.text+0x1968): undefined reference to `.nvram_read_byte'
drivers/built-in.o: In function `.valkyriefb_init':
(.init.text+0x2300): undefined reference to `.nvram_read_byte'
drivers/built-in.o:(.init.text+0x239c): more undefined references to `.nvram_read_byte' follow
Signed-off-by: Olaf Hering <olh@suse.de>
---
drivers/video/Kconfig | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
Index: linux-2.6.18-rc2/drivers/video/Kconfig
===================================================================
--- linux-2.6.18-rc2.orig/drivers/video/Kconfig
+++ linux-2.6.18-rc2/drivers/video/Kconfig
@@ -420,7 +420,7 @@ config FB_OF
config FB_CONTROL
bool "Apple \"control\" display support"
- depends on (FB = y) && PPC_PMAC
+ depends on (FB = y) && PPC_PMAC && PPC32
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
@@ -431,7 +431,7 @@ config FB_CONTROL
config FB_PLATINUM
bool "Apple \"platinum\" display support"
- depends on (FB = y) && PPC_PMAC
+ depends on (FB = y) && PPC_PMAC && PPC32
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
@@ -442,7 +442,7 @@ config FB_PLATINUM
config FB_VALKYRIE
bool "Apple \"valkyrie\" display support"
- depends on (FB = y) && (MAC || PPC_PMAC)
+ depends on (FB = y) && (MAC || (PPC_PMAC && PPC32))
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
@@ -453,7 +453,7 @@ config FB_VALKYRIE
config FB_CT65550
bool "Chips 65550 display support"
- depends on (FB = y) && PPC
+ depends on (FB = y) && PPC32
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
^ permalink raw reply
* Re: mpic discovery on JS20
From: Michael Ellerman @ 2006-07-24 7:41 UTC (permalink / raw)
To: Amos Waterland; +Cc: linuxppc-dev
In-Reply-To: <20060720231601.GA24736@kvasir.watson.ibm.com>
[-- Attachment #1.1: Type: text/plain, Size: 716 bytes --]
On Thu, 2006-07-20 at 19:16 -0400, Amos Waterland wrote:
> Current Linus and Paulus trees do this on JS20 blades with SLOF:
>
> Failed to locate the MPIC interrupt controller
> PID hash table entries: 4096 (order: 12, 32768 bytes)
> Maple: Found RTC at IO 0x1070
> cpu 0x0: Vector: 700 (Program Check) at [c00000007ef83ab0]
> pc: c00000000002e0c8: .mpic_request_ipis+0x34/0xc8
> lr: c00000000036b484: .smp_mpic_probe+0x3c/0x58
> sp: c00000007ef83d30
> msr: 9000000000029032
> current = 0xc00000000194d610
> paca = 0xc00000000038f180
> pid = 1, comm = swapper
> kernel BUG in mpic_request_ipis at arch/powerpc/sysdev/mpic.c:1132!
Does this help?
cheers
[-- Attachment #1.2: mpic-fixup.patch --]
[-- Type: text/x-patch, Size: 1132 bytes --]
Index: to-merge/arch/powerpc/platforms/maple/setup.c
===================================================================
--- to-merge.orig/arch/powerpc/platforms/maple/setup.c
+++ to-merge/arch/powerpc/platforms/maple/setup.c
@@ -216,6 +216,7 @@ static void __init maple_init_IRQ(void)
int naddr, n, i, opplen, has_isus = 0;
struct mpic *mpic;
unsigned int flags = MPIC_PRIMARY;
+ char *typep;
/* Locate MPIC in the device-tree. Note that there is a bug
* in Maple device-tree where the type of the controller is
@@ -226,9 +227,19 @@ static void __init maple_init_IRQ(void)
break;
}
if (mpic_node == NULL) {
- printk(KERN_ERR
- "Failed to locate the MPIC interrupt controller\n");
- return;
+ for_each_node_by_type(np, "interrupt-controller") {
+ typep = (char *)get_property(np, "compatible", NULL);
+ if (strstr(typep, "open-pic")) {
+ mpic_node = np;
+ break;
+ }
+ }
+
+ if (mpic_node == NULL) {
+ printk(KERN_ERR "Failed to locate the MPIC interrupt "
+ "controller\n");
+ return;
+ }
}
/* Find address list in /platform-open-pic */
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: problems with mounting JFFS2 using CFI for AM29LV160MT on ppc8245 k2.4.x
From: Arun Kumar @ 2006-07-24 8:24 UTC (permalink / raw)
To: bwarren; +Cc: linuxppc-embedded
In-Reply-To: <1153498817.19682.149.camel@saruman.qstreams.net>
[-- Attachment #1: Type: text/plain, Size: 9125 bytes --]
Hi Ben ,
Thanks for your reply .It was indeed very comrehensive .I am able to proceed
further But still there is a bit problem .
When I try to mknod physically viz mknod /dev/mtd0 .....
It says the node is readonly .
Can you please point out the problem . I am attaching a dump of the console
.
Linux/PPC load:
Uncompressing Linux...done.
Now booting the kernel ....
Memory BAT mapping: BAT2=64Mb, BAT3=0Mb, residual: 0Mb
Linux version 2.4.20_mvl31 (aks@IIB-A1040829) (gcc version 3.3.1 (MontaVista
3.3
.1-3.0.10.0300532 2003-12-24)) #368 Mon Jul 24 13:02:13 IST 2006
DBAT0U = 0x800001fe
DBAT0L = 0x8000002a
DBAT1U = 0xf0001ffe
DBAT1L = 0xf000002a
DBAT2U = 0xc00007fe
DBAT2L = 0x00000002
DBAT3U = 0xff8001fe
DBAT3L = 0xff80002a
ET4K Montavista Linux Test Platform
Port by Agere Systems
On node 0 totalpages: 16384
zone(0): 16384 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line:
OpenPIC Version 1.2 (1 CPUs and 14 IRQ sources) at fcf40000
Calibrating delay loop... 884.73 BogoMIPS
Memory: 62084k available (1000k kernel code, 356k data, 76k init, 0k
highmem)
Dentry cache hash table entries: 8192 (order: 4, 65536 bytes)
Inode cache hash table entries: 4096 (order: 3, 32768 bytes)
Mount-cache hash table entries: 1024 (order: 1, 8192 bytes)
Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes)
Page-cache hash table entries: 16384 (order: 4, 65536 bytes)
POSIX conformance testing by UNIFIX
PCI: Probing PCI hardware
Scanning bus 00
Found 00:00 [1057/0006] 000600 00
PCI:00:00.0 Resource 0 [00000000-ffffffff] is unassigned
PCI:00:00.0 Resource 1 [00000000-00000fff] is unassigned
PCI:00:00.0 Resource 2 [00000000-ffffffff] is unassigned
Found 00:78 [8086/1013] 000200 00
PCI:00:0f.0 Resource 6 [00000000-0000ffff] is unassigned
Found 00:f0 [0700/1107] 000600 00
Fixups for bus 00
Bus scan for 00 returning with max=00
PCI: bridge rsrc fc000000..fcc00000 (100), parent c011ddd4
PCI: bridge rsrc 80000000..fe000000 (200), parent c011ddf0
PCI:00:0f.0: Resource 0: fdfe0000-fdffffff (f=204)
PCI:00:0f.0: Resource 2: fdfd0000-fdfdffff (f=204)
PCI:00:0f.0: Resource 4: fcbfffc0-fcbfffff (f=101)
PCI:00:1e.0: Resource 0: fc000000-fcffffff (f=120c)
PCI:00:1e.0: Resource 2: fcbffe00-fcbffeff (f=101)
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
LSP Revision 1
Starting kswapd
Disabling the Out Of Memory Killer
JFFS2 version 2.1. (C) 2001, 2002 Red Hat, Inc., designed by Axis
Communications
AB.
Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ
SERIAL_PCI en
abled
ttyS00 at 0xfcf04500 (irq = 13) is a ST16650
RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize
AMD_FLASH_INIT called *aks *
physmap flash device: 800000 at ff800000 virtual address Number of erase
regions
: 4
Primary Vendor Command Set: 0002 (AMD/Fujitsu Standard)
Primary Algorithm Table at 0040
Alternative Vendor Command Set: 0000 (None)
No Alternate Algorithm Table
Vcc Minimum: 2.7 V
Vcc Maximum: 3.6 V
No Vpp line
Typical byte/word write timeout: 128 µs
Maximum byte/word write timeout: 256 µs
Full buffer write not supported
Typical block erase timeout: 1024 ms
Maximum block erase timeout: 16384 ms
Chip erase not supported
Device size: 0x200000 bytes (2 MiB)
Flash Device Interface description: 0x0002
- supports x8 and x16 via BYTE# with asynchronous interface
Max. bytes in buffer write: 0x1
Number of Erase Block Regions: 4
Erase Region #0: BlockSize 0x4000 bytes, 1 blocks
Erase Region #1: BlockSize 0x2000 bytes, 2 blocks
Erase Region #2: BlockSize 0x8000 bytes, 1 blocks
Erase Region #3: BlockSize 0x10000 bytes, 31 blocks
Amd/Fujitsu Extended Query Table v1.3 at 0x0040
number of CFI chips: 4
in amdstd_setup 0: offset=0x0,size=0x10000,blocks=1
1: offset=0x10000,size=0x8000,blocks=2
2: offset=0x20000,size=0x20000,blocks=1
3: offset=0x40000,size=0x40000,blocks=31
4: offset=0x800000,size=0x10000,blocks=1
5: offset=0x810000,size=0x8000,blocks=2
6: offset=0x820000,size=0x20000,blocks=1
7: offset=0x840000,size=0x40000,blocks=31
8: offset=0x1000000,size=0x10000,blocks=1
9: offset=0x1010000,size=0x8000,blocks=2
10: offset=0x1020000,size=0x20000,blocks=1
11: offset=0x1040000,size=0x40000,blocks=31
12: offset=0x1800000,size=0x10000,blocks=1
13: offset=0x1810000,size=0x8000,blocks=2
14: offset=0x1820000,size=0x20000,blocks=1
15: offset=0x1840000,size=0x40000,blocks=31
cfi_cmdset_0002: Disabling fast programming due to code brokenness. aks
Enabling
*
in MTD Partitioning <5>No RedBoot partition table detected in
phys_mapped_flash
Using physmap partition definition
Creating 3 MTD partitions on "phys_mapped_flash":
0x00000000-0x00040000 : "agere-ets0"
mtd: Giving out device 0 to agere-ets0
0x00040000-0x00080000 : "agere-ets1"
mtd: Giving out device 1 to agere-ets1
0x00080000-0x0007fffe : "agere-ets2"
mtd: partition "agere-ets2" doesn't end on an erase block -- force read-only
mtd: Giving out device 2 to agere-ets2
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 4096 bind 8192)
IP-Config: No network devices available.
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
/dev/console mapped to mkdev 5: minor: 1
RAMDISK: Compressed image found at block 0
Freeing initrd memory: 1247k freed
VFS: Mounted root (ext2 filesystem) readonly.
Freeing unused kernel memory: 76k init
calling sbin/init
init started: BusyBox v1.2.0 (2006.07.12-05:25+0000) multi-call binary
init started: BusyBox v1.2.0 (2006.07.12-05:25+0000) multi-call binary
Starting pid 8, console /dev/ttyS0: '/bin/ash'
BusyBox v1.2.0 (2006.07.12-05:25+0000) Built-in shell (ash)
Enter 'help' for a list of built-in commands.
/ $ mknod /dev/mtd0 c 90 0
mknod: /dev/mtd0: Read-only file system
/ $
also can you point out why it is trying to disable the fast programming ?
Thanks,
Arun
On 7/21/06, Ben Warren <bwarren@qstreams.com> wrote:
>
> Hi Arun,
>
> On Fri, 2006-07-21 at 20:26 +0530, Arun Kumar wrote:
> > Hi ,
> > Can anyone help me in this naive problem ?
> >
> Then a naive answer is most fitting... Turns out that's my specialty.
>
> > #
> > # Memory Technology Devices (MTD)
> > #
> > CONFIG_MTD=y
> > CONFIG_MTD_DEBUG=y
> > CONFIG_MTD_DEBUG_VERBOSE=2
> > CONFIG_MTD_PARTITIONS=y
> > CONFIG_MTD_CONCAT=y
> > CONFIG_MTD_REDBOOT_PARTS=y
> > CONFIG_MTD_CMDLINE_PARTS=y
> Probably get rid of REDBOOT if you're not using that bootloader
> >
> > #
> > # User Modules And Translation Layers
> > #
> > # CONFIG_MTD_CHAR is not set
> > # CONFIG_MTD_BLOCK is not set
> > # CONFIG_MTD_BLOCK_RO is not set
> > # CONFIG_FTL is not set
> > # CONFIG_NFTL is not set
> > # CONFIG_INFTL is not set
> >
> You need to enable MTD_CHAR to read/write and MTD_BLOCK to mount
>
> > Can any happy soul let me know :--
> >
> > 1)How to mount jffs2 on this flash and also to test mtd->read/write
> > routines ?
> Start with the char drivers (/dev/mtd0 etc.). You'll need one for each
> partition you want to experiment with.
> How about creating the nodes manually?
>
> mknod /dev/mtd0 c 90 0
> mknod /dev/mtd1 c 90 2 etc. (minor # increments in 2s)
>
> Add a block device for each partition:
>
> mknod /dev/mtdblock0 b 31 0
> mknod /dev/mtdblock1 b 31 1 etc.
>
> Once you clean up #3 below, you should be able to read/write the char
> devices using commands like 'cat', or write a simple user-space app
> using "open, read, write", etc if you'd rather look at the actual binary
> data.
>
> You can then experiment with mounting the JFFS2. I recommend booting to
> an NFS file system then mounting the JFFS2 with something like:
>
> mount -t jffs2 /dev/mtdblock5 /mnt/temp (Use the correct partition)
>
> >
> > 2) Is it ok not to see mtd0.. partions in /dev directory .
> Pretty sure you'll need these
> >
> > 3 ) Where do I register the mtd partitions to get them noticed
> > here ??
> Looks like your partitions are already being found, but are probably not
> set up right. I don't know if this is a static definition in your board
> init code or passed by command line from the bootloader, but it looks
> like the values don't line up with your device:
>
> *********
> Using physmap partition definition
> Creating 3 MTD partitions on "phys_mapped_flash":
> 0x00000000-0x00040000 : "foo-ets0"
> mtd: Giving out device 0 to foo-ets0
> 0x00040000-0x001e0000 : "foo-ets1"
> mtd: partition "agere-ets1" doesn't end on an erase block -- force
> read-only
> mtd: Giving out device 1 to foo-ets1
> 0x001e0000-0x00200000 : "foo-ets2"
> mtd: partition "foo-ets2" doesn't start on an erase block boundary --
> force read-only
> *********
> --------------------------------------------------------------------------
> Hopefully this helps you proceed a little bit.
>
> regards,
> Ben
>
>
--
Arun Kumar Singh
Tech Lead.
Agere India
Bangalore
[-- Attachment #2: Type: text/html, Size: 36612 bytes --]
^ permalink raw reply
* Re: problems with mounting JFFS2 using CFI for AM29LV160MT on ppc8245 k2.4.x
From: Arun Kumar @ 2006-07-24 9:24 UTC (permalink / raw)
To: bwarren; +Cc: linuxppc-embedded
In-Reply-To: <edd12c050607240124gd001d11q77796ab4d13c241b@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 10156 bytes --]
Ben ,
Further to my previous mail I have another problem with my busybox
initrd/RAMDISK system -my ext2 root file system is mounted as root && Read
only .as a result my mknod etc commands always returns ERROR -- root mounted
as read only ?
Any pointers for the same ? to make my RAMDISK read/writable ? so that i can
check by your method ?
Thanks ,
Arun
On 7/24/06, Arun Kumar <arunkat@gmail.com> wrote:
>
> Hi Ben ,
>
> Thanks for your reply .It was indeed very comrehensive .I am able to
> proceed further But still there is a bit problem .
>
> When I try to mknod physically viz mknod /dev/mtd0 .....
>
> It says the node is readonly .
>
> Can you please point out the problem . I am attaching a dump of the
> console .
>
>
> Linux/PPC load:
> Uncompressing Linux...done.
> Now booting the kernel ....
> Memory BAT mapping: BAT2=64Mb, BAT3=0Mb, residual: 0Mb
> Linux version 2.4.20_mvl31 ( aks@IIB-A1040829) (gcc version 3.3.1(MontaVista
> 3.3
> .1-3.0.10.0300532 2003-12-24)) #368 Mon Jul 24 13:02:13 IST 2006
> DBAT0U = 0x800001fe
> DBAT0L = 0x8000002a
> DBAT1U = 0xf0001ffe
> DBAT1L = 0xf000002a
> DBAT2U = 0xc00007fe
> DBAT2L = 0x00000002
> DBAT3U = 0xff8001fe
> DBAT3L = 0xff80002a
> ET4K Montavista Linux Test Platform
> Port by Agere Systems
> On node 0 totalpages: 16384
> zone(0): 16384 pages.
> zone(1): 0 pages.
> zone(2): 0 pages.
> Kernel command line:
> OpenPIC Version 1.2 (1 CPUs and 14 IRQ sources) at fcf40000
> Calibrating delay loop... 884.73 BogoMIPS
> Memory: 62084k available (1000k kernel code, 356k data, 76k init, 0k
> highmem)
> Dentry cache hash table entries: 8192 (order: 4, 65536 bytes)
> Inode cache hash table entries: 4096 (order: 3, 32768 bytes)
> Mount-cache hash table entries: 1024 (order: 1, 8192 bytes)
> Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes)
> Page-cache hash table entries: 16384 (order: 4, 65536 bytes)
> POSIX conformance testing by UNIFIX
> PCI: Probing PCI hardware
> Scanning bus 00
> Found 00:00 [1057/0006] 000600 00
> PCI:00:00.0 Resource 0 [00000000-ffffffff] is unassigned
> PCI:00:00.0 Resource 1 [00000000-00000fff] is unassigned
> PCI:00:00.0 Resource 2 [00000000-ffffffff] is unassigned
> Found 00:78 [8086/1013] 000200 00
> PCI:00:0f.0 Resource 6 [00000000-0000ffff] is unassigned
> Found 00:f0 [0700/1107] 000600 00
> Fixups for bus 00
> Bus scan for 00 returning with max=00
> PCI: bridge rsrc fc000000..fcc00000 (100), parent c011ddd4
> PCI: bridge rsrc 80000000..fe000000 (200), parent c011ddf0
> PCI:00:0f.0: Resource 0: fdfe0000-fdffffff (f=204)
> PCI:00:0f.0: Resource 2: fdfd0000-fdfdffff (f=204)
> PCI:00:0f.0: Resource 4: fcbfffc0-fcbfffff (f=101)
> PCI:00:1e.0: Resource 0: fc000000-fcffffff (f=120c)
> PCI:00:1e.0: Resource 2: fcbffe00-fcbffeff (f=101)
> Linux NET4.0 for Linux 2.4
> Based upon Swansea University Computer Society NET3.039
> Initializing RT netlink socket
>
> LSP Revision 1
> Starting kswapd
> Disabling the Out Of Memory Killer
> JFFS2 version 2.1. (C) 2001, 2002 Red Hat, Inc., designed by Axis
> Communications
> AB.
> Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ
> SERIAL_PCI en
> abled
> ttyS00 at 0xfcf04500 (irq = 13) is a ST16650
> RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize
>
> AMD_FLASH_INIT called *aks *
> physmap flash device: 800000 at ff800000 virtual address Number of erase
> regions
> : 4
> Primary Vendor Command Set: 0002 (AMD/Fujitsu Standard)
> Primary Algorithm Table at 0040
> Alternative Vendor Command Set: 0000 (None)
> No Alternate Algorithm Table
> Vcc Minimum: 2.7 V
> Vcc Maximum: 3.6 V
> No Vpp line
> Typical byte/word write timeout: 128 µs
> Maximum byte/word write timeout: 256 µs
> Full buffer write not supported
> Typical block erase timeout: 1024 ms
> Maximum block erase timeout: 16384 ms
> Chip erase not supported
> Device size: 0x200000 bytes (2 MiB)
> Flash Device Interface description: 0x0002
> - supports x8 and x16 via BYTE# with asynchronous interface
> Max. bytes in buffer write: 0x1
> Number of Erase Block Regions: 4
> Erase Region #0: BlockSize 0x4000 bytes, 1 blocks
> Erase Region #1: BlockSize 0x2000 bytes, 2 blocks
> Erase Region #2: BlockSize 0x8000 bytes, 1 blocks
> Erase Region #3: BlockSize 0x10000 bytes, 31 blocks
> Amd/Fujitsu Extended Query Table v1.3 at 0x0040
> number of CFI chips: 4
>
> in amdstd_setup 0: offset=0x0,size=0x10000,blocks=1
> 1: offset=0x10000,size=0x8000,blocks=2
> 2: offset=0x20000,size=0x20000,blocks=1
> 3: offset=0x40000,size=0x40000,blocks=31
> 4: offset=0x800000,size=0x10000,blocks=1
> 5: offset=0x810000,size=0x8000,blocks=2
> 6: offset=0x820000,size=0x20000,blocks=1
> 7: offset=0x840000,size=0x40000,blocks=31
> 8: offset=0x1000000,size=0x10000,blocks=1
> 9: offset=0x1010000,size=0x8000,blocks=2
> 10: offset=0x1020000,size=0x20000,blocks=1
> 11: offset=0x1040000,size=0x40000,blocks=31
> 12: offset=0x1800000,size=0x10000,blocks=1
> 13: offset=0x1810000,size=0x8000,blocks=2
> 14: offset=0x1820000,size=0x20000,blocks=1
> 15: offset=0x1840000,size=0x40000,blocks=31
> cfi_cmdset_0002: Disabling fast programming due to code brokenness. aks
> Enabling
> *
>
>
> in MTD Partitioning <5>No RedBoot partition table detected in
> phys_mapped_flash
>
> Using physmap partition definition
> Creating 3 MTD partitions on "phys_mapped_flash":
> 0x00000000-0x00040000 : "agere-ets0"
> mtd: Giving out device 0 to agere-ets0
> 0x00040000-0x00080000 : "agere-ets1"
> mtd: Giving out device 1 to agere-ets1
> 0x00080000-0x0007fffe : "agere-ets2"
> mtd: partition "agere-ets2" doesn't end on an erase block -- force
> read-only
> mtd: Giving out device 2 to agere-ets2
>
> NET4: Linux TCP/IP 1.0 for NET4.0
> IP Protocols: ICMP, UDP, TCP, IGMP
> IP: routing cache hash table of 512 buckets, 4Kbytes
> TCP: Hash tables configured (established 4096 bind 8192)
> IP-Config: No network devices available.
> NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
> /dev/console mapped to mkdev 5: minor: 1
> RAMDISK: Compressed image found at block 0
> Freeing initrd memory: 1247k freed
> VFS: Mounted root (ext2 filesystem) readonly.
> Freeing unused kernel memory: 76k init
> calling sbin/init
> init started: BusyBox v1.2.0 (2006.07.12-05:25+0000) multi-call binary
> init started: BusyBox v1.2.0 (2006.07.12-05:25+0000) multi-call binary
> Starting pid 8, console /dev/ttyS0: '/bin/ash'
>
>
> BusyBox v1.2.0 (2006.07.12-05:25+0000) Built-in shell (ash)
> Enter 'help' for a list of built-in commands.
>
> / $ mknod /dev/mtd0 c 90 0
> mknod: /dev/mtd0: Read-only file system
> / $
>
>
> also can you point out why it is trying to disable the fast programming ?
>
>
> Thanks,
> Arun
>
>
>
> On 7/21/06, Ben Warren < bwarren@qstreams.com> wrote:
> >
> > Hi Arun,
> >
> > On Fri, 2006-07-21 at 20:26 +0530, Arun Kumar wrote:
> > > Hi ,
> > > Can anyone help me in this naive problem ?
> > >
> > Then a naive answer is most fitting... Turns out that's my specialty.
> >
> > > #
> > > # Memory Technology Devices (MTD)
> > > #
> > > CONFIG_MTD=y
> > > CONFIG_MTD_DEBUG=y
> > > CONFIG_MTD_DEBUG_VERBOSE=2
> > > CONFIG_MTD_PARTITIONS=y
> > > CONFIG_MTD_CONCAT=y
> > > CONFIG_MTD_REDBOOT_PARTS=y
> > > CONFIG_MTD_CMDLINE_PARTS=y
> > Probably get rid of REDBOOT if you're not using that bootloader
> > >
> > > #
> > > # User Modules And Translation Layers
> > > #
> > > # CONFIG_MTD_CHAR is not set
> > > # CONFIG_MTD_BLOCK is not set
> > > # CONFIG_MTD_BLOCK_RO is not set
> > > # CONFIG_FTL is not set
> > > # CONFIG_NFTL is not set
> > > # CONFIG_INFTL is not set
> > >
> > You need to enable MTD_CHAR to read/write and MTD_BLOCK to mount
> >
> > > Can any happy soul let me know :--
> > >
> > > 1)How to mount jffs2 on this flash and also to test mtd->read/write
> > > routines ?
> > Start with the char drivers (/dev/mtd0 etc.). You'll need one for each
> > partition you want to experiment with.
> > How about creating the nodes manually?
> >
> > mknod /dev/mtd0 c 90 0
> > mknod /dev/mtd1 c 90 2 etc. (minor # increments in 2s)
> >
> > Add a block device for each partition:
> >
> > mknod /dev/mtdblock0 b 31 0
> > mknod /dev/mtdblock1 b 31 1 etc.
> >
> > Once you clean up #3 below, you should be able to read/write the char
> > devices using commands like 'cat', or write a simple user-space app
> > using "open, read, write", etc if you'd rather look at the actual binary
> > data.
> >
> > You can then experiment with mounting the JFFS2. I recommend booting to
> > an NFS file system then mounting the JFFS2 with something like:
> >
> > mount -t jffs2 /dev/mtdblock5 /mnt/temp (Use the correct partition)
> >
> > >
> > > 2) Is it ok not to see mtd0.. partions in /dev directory .
> > Pretty sure you'll need these
> > >
> > > 3 ) Where do I register the mtd partitions to get them noticed
> > > here ??
> > Looks like your partitions are already being found, but are probably not
> > set up right. I don't know if this is a static definition in your board
> > init code or passed by command line from the bootloader, but it looks
> > like the values don't line up with your device:
> >
> > *********
> > Using physmap partition definition
> > Creating 3 MTD partitions on "phys_mapped_flash":
> > 0x00000000-0x00040000 : "foo-ets0"
> > mtd: Giving out device 0 to foo-ets0
> > 0x00040000-0x001e0000 : "foo-ets1"
> > mtd: partition "agere-ets1" doesn't end on an erase block -- force
> > read-only
> > mtd: Giving out device 1 to foo-ets1
> > 0x001e0000-0x00200000 : "foo-ets2"
> > mtd: partition "foo-ets2" doesn't start on an erase block boundary --
> > force read-only
> > *********
> > --------------------------------------------------------------------------
> >
> > Hopefully this helps you proceed a little bit.
> >
> > regards,
> > Ben
> >
> >
>
>
> --
> Arun Kumar Singh
> Tech Lead.
> Agere India
> Bangalore
>
--
Arun Kumar Singh
Tech Lead.
Agere India
Bangalore
[-- Attachment #2: Type: text/html, Size: 38056 bytes --]
^ permalink raw reply
* Endless "Trying 100/HALF" messages using FCC ethernet on MPC8248
From: Laurent Pinchart @ 2006-07-24 9:39 UTC (permalink / raw)
To: linuxppc-embedded
Hi everybody,
I'm not sure if this issue is ppc-specific, so forgive me if it should have
been reported to the drivers/net/phy maintainer.
When using the MPC8248 FCC ethernet ports, the following messages are printed
by the kernel on the console when a link is down (ethernet cable unplugged):
Trying 100/FULL
Trying 100/HALF
Trying 100/HALF
Trying 100/HALF
...
This goes on forever, with a new message every 5 or 10 seconds. The message is
printed by drivers/net/phy/phy.c at line 463.
Those messages are pretty annoying. Commenting the pr_info() call gave me some
rest, but a proper fix is probably needed.
For the record, I'm using FCC1 and FCC2 with an LXT973 phy in bit-banging
mode.
Laurent Pinchart
^ permalink raw reply
* Re: Endless "Trying 100/HALF" messages using FCC ethernet on MPC8248
From: Vitaly Bordug @ 2006-07-24 11:45 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: linuxppc-embedded
In-Reply-To: <200607241139.02128.laurent.pinchart@tbox.biz>
On Mon, 24 Jul 2006 11:39:01 +0200
Laurent Pinchart <laurent.pinchart@tbox.biz> wrote:
> Hi everybody,
>
> I'm not sure if this issue is ppc-specific, so forgive me if it should have
> been reported to the drivers/net/phy maintainer.
>
> When using the MPC8248 FCC ethernet ports, the following messages are printed
> by the kernel on the console when a link is down (ethernet cable unplugged):
>
> Trying 100/FULL
> Trying 100/HALF
> Trying 100/HALF
> Trying 100/HALF
> ...
>
> This goes on forever, with a new message every 5 or 10 seconds. The message is
> printed by drivers/net/phy/phy.c at line 463.
>
> Those messages are pretty annoying. Commenting the pr_info() call gave me some
> rest, but a proper fix is probably needed.
>
> For the record, I'm using FCC1 and FCC2 with an LXT973 phy in bit-banging
> mode.
>
The thing you'll need is to make driver to trust autonegotiation...
IIRC that was addressed in my patches for fs-enet. what's happening: The PAL subsystem tries hard to be
wise, an dif there are no link located, it starts to try forced mode, setting various stuff as link params and looking if link appeared or not. To keep consistency, I used the special flag passed via platform info, to just trust what ANEG had find out.
Prolly we need to limit the forced aneg as well somehow - say give up after it failed to get link going at 10/HALF or smth like that.
--
Sincerely,
Vitaly
^ permalink raw reply
* Re: stupid linker question.... to remove unused functions in the object file.
From: Parav Pandit @ 2006-07-24 12:07 UTC (permalink / raw)
To: Wade Maxfield, Steve Iribarne (GMail); +Cc: linuxppc-embedded
In-Reply-To: <45a1b53e0607211410y196d76b4j1f9dc5c32014bc7a@mail.gmail.com>
Hi,
I have few functions in a C file but those are not
called at present. Even though those function
definitions are part of the object file.
Those will be called later on.
What CFLAGS should I pass to remove unused functions?
I cannot enable -Ox at present to have any
unpredictable behaviour.
Regards,
Parav Pandit
--- Wade Maxfield <wmaxfield@gmail.com> wrote:
> gcc -Wa,-alhs -g main.c >main.cs
>
> will put interleaved code/assembly into main.cs
> file.
>
> wade
>
>
>
> On 7/21/06, Steve Iribarne (GMail)
> <netstv@gmail.com> wrote:
> >
> > I forgot the flag that generates a list file that
> has both assembly
> > and c mixed in.
> >
> > Anyone?
> >
> > Thanks...
> >
> > -stv
> > _______________________________________________
> > Linuxppc-embedded mailing list
> > Linuxppc-embedded@ozlabs.org
> >
>
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> >
> > _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
>
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* RE:SystemAce Driver.
From: Raja Chidambaram @ 2006-07-24 12:14 UTC (permalink / raw)
To: linuxppc-embedded
Hi all,
We are working on customized board with amcc 440SPe
processor & xilinx System Ace controller. The System
Ace controller is connected to compact flash driver.
We use u-boot 1.2 as bootloader & linux kernel
2.6.16-2.
On the process the u-boot is able to detect compact
flash through Xilinx SystemAce controller & able to
load the kernel image into compact flash.But when the
linux boot's up it not able to detect the System Ace
controller or compact flash.
Note:we need to have the root file system in compact
flash.
Is their any drivers available for SystemAce
controller on linux 2.6,if their how to get it.please
help me in this
with regards
raja
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* RE:SystemAce Driver.
From: Ming Liu @ 2006-07-24 12:36 UTC (permalink / raw)
To: raja_chidambaram82; +Cc: linuxppc-embedded
In-Reply-To: <20060724121452.55760.qmail@web53608.mail.yahoo.com>
Hi,
https://www.cs.york.ac.uk/rtslab/demos/amos/xupv2pro/patches/linuxppc-2.6.17.1-sysace-1.2-after-TEMAC.patch
This is one which could work well with Temac driver.
Regards
Ming
>From: Raja Chidambaram <raja_chidambaram82@yahoo.com>
>To: linuxppc-embedded@ozlabs.org
>Subject: RE:SystemAce Driver.
>Date: Mon, 24 Jul 2006 05:14:52 -0700 (PDT)
>
>
>
>
> Hi all,
> We are working on customized board with amcc 440SPe
>processor & xilinx System Ace controller. The System
>Ace controller is connected to compact flash driver.
>
>We use u-boot 1.2 as bootloader & linux kernel
>2.6.16-2.
>
>On the process the u-boot is able to detect compact
>flash through Xilinx SystemAce controller & able to
>load the kernel image into compact flash.But when the
>linux boot's up it not able to detect the System Ace
>controller or compact flash.
>
>Note:we need to have the root file system in compact
>flash.
>
>Is their any drivers available for SystemAce
>controller on linux 2.6,if their how to get it.please
>help me in this
> with regards
> raja
>
>
>
>__________________________________________________
>Do You Yahoo!?
>Tired of spam? Yahoo! Mail has the best spam protection around
>http://mail.yahoo.com
>_______________________________________________
>Linuxppc-embedded mailing list
>Linuxppc-embedded@ozlabs.org
>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
_________________________________________________________________
与联机的朋友进行交流，请使用 MSN Messenger: http://messenger.msn.com/cn
^ permalink raw reply
* Re: SystemAce Driver.
From: Ameet Patil @ 2006-07-24 12:34 UTC (permalink / raw)
To: Raja Chidambaram; +Cc: linuxppc-embedded
In-Reply-To: <20060724121452.55760.qmail@web53608.mail.yahoo.com>
Hi Raja,
I have ported the Xilinx System ACE driver to 2.6 kernel. Find the
latest one here:
http://www.cs.york.ac.uk/rtslab/demos/amos/xupv2pro/patches/linuxppc-2.6.17.1-sysace-1.2.patch
NOTE: this patch wouldn't work if you are using the TEMAC driver. In
which case use the -after-TEMAC patch found in the patches folder above.
Check the following discussions (threads) for more details:
1. "Xilinx SystemACE driver for 2.6"
2. "Xilinx BSP for linux 2.6"
3. "Kernel hangs after "Now booting the kernel"."
cheers,
-Ameet
Raja Chidambaram wrote:
>
>
> Hi all,
> We are working on customized board with amcc 440SPe
> processor & xilinx System Ace controller. The System
> Ace controller is connected to compact flash driver.
>
> We use u-boot 1.2 as bootloader & linux kernel
> 2.6.16-2.
>
> On the process the u-boot is able to detect compact
> flash through Xilinx SystemAce controller & able to
> load the kernel image into compact flash.But when the
> linux boot's up it not able to detect the System Ace
> controller or compact flash.
>
> Note:we need to have the root file system in compact
> flash.
>
> Is their any drivers available for SystemAce
> controller on linux 2.6,if their how to get it.please
> help me in this
> with regards
> raja
>
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
^ permalink raw reply
* Query regarding Gianfar Ethernet Driver for MPC8555E
From: Alok Barsode @ 2006-07-24 13:44 UTC (permalink / raw)
To: Linuxppc-embedded
Hello,
I am a newbie, working on the MPC8555E(Freescale).
The Gianfar Ethernet Driver configures the TSECs on
the board.I see that out of the 4 Ethernet Interfaces
only 2 are configured when the gianfar driver is
loaded(I have complied it as a modules).I checked this
via "ifconfig" command. Out of the 4 ports, 2 are
located on the basic carrier board and the other two
on the IOCard expansion.
I wonder why all four of them are not configured?
Thanks in advance,
Alok.
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* RE: Query regarding Gianfar Ethernet Driver for MPC8555E
From: Wang Haiying-r54964 @ 2006-07-24 13:59 UTC (permalink / raw)
To: Alok Barsode, Linuxppc-embedded
In-Reply-To: <20060724134454.90046.qmail@web8903.mail.in.yahoo.com>
8555E only supports TWO TSECs. 8548E supports four eTSECs.
Haiying=20
> >>-----Original Message-----
> >>From:=20
> >>linuxppc-embedded-bounces+haiying.wang=3Dfreescale.com@ozlabs.
org [mailto:linuxppc-embedded->
>>bounces+haiying.wang=3Dfreescale.com@ozlabs.org] On Behalf Of=20
> >>Alok Barsode
> >>Sent: Monday, July 24, 2006 9:45 AM
> >>To: Linuxppc-embedded@ozlabs.org
> >>Subject: Query regarding Gianfar Ethernet Driver for MPC8555E
> >>
> >>Hello,
> >>I am a newbie, working on the MPC8555E(Freescale).=20
> >>
> >>The Gianfar Ethernet Driver configures the TSECs on the=20
> >>board.I see that out of the 4 Ethernet Interfaces only 2=20
> >>are configured when the gianfar driver is loaded(I have=20
> >>complied it as a modules).I checked this via "ifconfig"=20
> >>command. Out of the 4 ports, 2 are located on the basic=20
> >>carrier board and the other two on the IOCard expansion.
> >>
> >>I wonder why all four of them are not configured?
> >>
> >>Thanks in advance,
> >>Alok.
> >>
> >>
> >>__________________________________________________
> >>Do You Yahoo!?
> >>Tired of spam? Yahoo! Mail has the best spam protection=20
> >>around http://mail.yahoo.com=20
> >>_______________________________________________
> >>Linuxppc-embedded mailing list
> >>Linuxppc-embedded@ozlabs.org
> >>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> >>
^ permalink raw reply
* Re: problems with mounting JFFS2 using CFI for AM29LV160MT on ppc8245 k2.4.x
From: Ben Warren @ 2006-07-24 14:14 UTC (permalink / raw)
To: Arun Kumar; +Cc: linuxppc-embedded
In-Reply-To: <edd12c050607240124gd001d11q77796ab4d13c241b@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3943 bytes --]
Arun,
Looks like there are still some things broken in your MTD partition
definition. I highly recommend that when debugging this, you boot from
an NFS mount. That way you can modify files off-line (ie. from your
development host). I'll point out a few things, but you're going to
have to surf the source code a bit:
On Mon, 2006-07-24 at 13:54 +0530, Arun Kumar wrote:
> Hi Ben ,
>
> Thanks for your reply .It was indeed very comrehensive .I am able to
> proceed further But still there is a bit problem .
>
> When I try to mknod physically viz mknod /dev/mtd0 .....
>
> It says the node is readonly .
>
> Can you please point out the problem . I am attaching a dump of the
> console .
Again, put your root FS on an NFS mount and this won't be an issue. You
can work out the ramdisk details later.
> AMD_FLASH_INIT called *aks *
> physmap flash device: 800000 at ff800000 virtual address Number of
> erase regions
> : 4
> Primary Vendor Command Set: 0002 (AMD/Fujitsu Standard)
> Primary Algorithm Table at 0040
> Alternative Vendor Command Set: 0000 (None)
> No Alternate Algorithm Table
> Vcc Minimum: 2.7 V
> Vcc Maximum: 3.6 V
> No Vpp line
> Typical byte/word write timeout: 128 µs
> Maximum byte/word write timeout: 256 µs
> Full buffer write not supported
> Typical block erase timeout: 1024 ms
> Maximum block erase timeout: 16384 ms
> Chip erase not supported
> Device size: 0x200000 bytes (2 MiB)
> Flash Device Interface description: 0x0002
> - supports x8 and x16 via BYTE# with asynchronous interface
> Max. bytes in buffer write: 0x1
> Number of Erase Block Regions: 4
> Erase Region #0: BlockSize 0x4000 bytes, 1 blocks
> Erase Region #1: BlockSize 0x2000 bytes, 2 blocks
> Erase Region #2: BlockSize 0x8000 bytes, 1 blocks
> Erase Region #3: BlockSize 0x10000 bytes, 31 blocks
> Amd/Fujitsu Extended Query Table v1.3 at 0x0040
> number of CFI chips: 4
>
> in amdstd_setup 0: offset=0x0,size=0x10000,blocks=1
> 1: offset=0x10000,size=0x8000,blocks=2
> 2: offset=0x20000,size=0x20000,blocks=1
> 3: offset=0x40000,size=0x40000,blocks=31
> 4: offset=0x800000,size=0x10000,blocks=1
> 5: offset=0x810000,size=0x8000,blocks=2
> 6: offset=0x820000,size=0x20000,blocks=1
> 7: offset=0x840000,size=0x40000,blocks=31
> 8: offset=0x1000000,size=0x10000,blocks=1
> 9: offset=0x1010000,size=0x8000,blocks=2
> 10: offset=0x1020000,size=0x20000,blocks=1
> 11: offset=0x1040000,size=0x40000,blocks=31
> 12: offset=0x1800000,size=0x10000,blocks=1
> 13: offset=0x1810000,size=0x8000,blocks=2
> 14: offset=0x1820000,size=0x20000,blocks=1
> 15: offset=0x1840000,size=0x40000,blocks=31
> cfi_cmdset_0002: Disabling fast programming due to code brokenness.
> aks Enabling
> *
Are you sure you have the correct chip family chosen in your CONFIG?
The block sizes found by CFI are different than those mentioned in
amdstd_setup... CFI shows your devices being 2MB in size, while the
other shows (1*10000 + 2*8000 + 1*20000 + 31*40000 = 0x800000) 8MB per
chip. Something is amiss here. I don't have a clue about the fast
programming. 'grep -R' is your friend.
>
> in MTD Partitioning <5>No RedBoot partition table detected in
> phys_mapped_flash
>
> Using physmap partition definition
> Creating 3 MTD partitions on "phys_mapped_flash":
> 0x00000000-0x00040000 : "agere-ets0"
> mtd: Giving out device 0 to agere-ets0
> 0x00040000-0x00080000 : "agere-ets1"
> mtd: Giving out device 1 to agere-ets1
> 0x00080000-0x0007fffe : "agere-ets2"
> mtd: partition "agere-ets2" doesn't end on an erase block -- force
> read-only
There's definitely a problem here. First of all, 0x7fffe is < 0x80000.
Note that the start and end addresses you specify for this must be on
erase block boundaries. Clean up your partition table to reflect what
you want. You didn't mention whether you're passing partition info by
command line or in init code. Also, if you're not using Redboot, get
rid of that CONFIG option.
regards,
Ben
[-- Attachment #2: Type: text/html, Size: 6615 bytes --]
^ permalink raw reply
* Re: mpic discovery on JS20
From: Segher Boessenkool @ 2006-07-24 18:20 UTC (permalink / raw)
To: michael; +Cc: linuxppc-dev
In-Reply-To: <1153726896.12748.0.camel@localhost.localdomain>
> Does this help?
Yes it does. I thought that went upstream already though?
Segher
^ permalink raw reply
* Re: stupid linker question.... to remove unused functions in the object file.
From: Becky Bruce @ 2006-07-24 20:54 UTC (permalink / raw)
To: Parav Pandit; +Cc: linuxppc-embedded
In-Reply-To: <20060724120712.15709.qmail@web36606.mail.mud.yahoo.com>
I believe you can use -ffunction-sections -Wl,--gc-sections when you
compile and link. If you have binutils prior to 2.16, this only
works with -static.
-B
On Jul 24, 2006, at 7:07 AM, Parav Pandit wrote:
> Hi,
>
> I have few functions in a C file but those are not
> called at present. Even though those function
> definitions are part of the object file.
> Those will be called later on.
>
> What CFLAGS should I pass to remove unused functions?
> I cannot enable -Ox at present to have any
> unpredictable behaviour.
>
> Regards,
> Parav Pandit
>
>
> --- Wade Maxfield <wmaxfield@gmail.com> wrote:
>
>> gcc -Wa,-alhs -g main.c >main.cs
>>
>> will put interleaved code/assembly into main.cs
>> file.
>>
>> wade
>>
>>
>>
>> On 7/21/06, Steve Iribarne (GMail)
>> <netstv@gmail.com> wrote:
>>>
>>> I forgot the flag that generates a list file that
>> has both assembly
>>> and c mixed in.
>>>
>>> Anyone?
>>>
>>> Thanks...
>>>
>>> -stv
>>> _______________________________________________
>>> Linuxppc-embedded mailing list
>>> Linuxppc-embedded@ozlabs.org
>>>
>>
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>>
>>> _______________________________________________
>> Linuxppc-embedded mailing list
>> Linuxppc-embedded@ozlabs.org
>>
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox