* Re: Moving from 2.4 to 2.6 kernel
From: Grant Likely @ 2006-05-04 20:04 UTC (permalink / raw)
To: Chris Dumoulin; +Cc: linuxppc-embedded
In-Reply-To: <445A534D.8090800@ics-ltd.com>
On 5/4/06, Chris Dumoulin <cdumoulin@ics-ltd.com> wrote:
> I'm looking into getting a BDI 2000 so I can start stepping through and
> see what is going on.
>
> I looked at the ML300 and V2Pro code in the arch/ppc/platforms/4xx
> folder, but I did not use any of that in my code. It looks like this is
> intended to be used with the BSP that is generated by Xilinx Platform
> Studio. I've tried generating the BSP this way, but the generated code
> is obviously not a complete patch to port Linux to your hardware, and I
> figure that by the time I figure out what I do/don't have to add, I
> might as well write the whole thing by myself. Have you had success
> integrating the automatically generated BSP from Xilinx Platform Studio?
No; the stuff in 2.6 is not integrated w/ platform studio. (only 2.4
is). However, you do need to extract the xparameters.h file from the
platform studio BSP. You can generate a Linux BSP w/o actually
telling it where your Linux tree is. Once its generated; pull out
xparameters.h and drop it into arch/ppc/platforms/4xx/xparameters/ in
your source tree. Note: it's important that you generate a LINUX BSP;
not a 'standalone' bsp. If you don't, then you'll be missing a bunch
of #defines.
Let me say that once more for clarity: The only file you need from
platform studio is the generated xparameters.h
This will give you at the very least a serial port driver. Once your
booting with that, you can focus on other device drivers.
Trust me; this is the path of far less pain.
Cheers,
g.
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
(403) 399-0195
^ permalink raw reply
* Re: kernel debugging
From: Steve Iribarne (GMail) @ 2006-05-04 19:51 UTC (permalink / raw)
To: dhlii; +Cc: linuxppc-embedded
In-Reply-To: <4459C774.8000300@dlasys.net>
On 5/4/06, David H. Lynch Jr. <dhlii@dlasys.net> wrote:
> Everyone has their own debugging style.
>
> Engineers seem to like hardware debugging tools. I have used some
> very fancy debugging hardware, but except for extremely rare instances
> it is more work to get setup
> and figure out what you are trying to do than inserting some
> debugging and rebuilding.
>
> My idea of debugging hardware is a port with an LED on it I can try
> to blink.
>
> I also only rarely use software debuggers.
>
> Most of the time when things go off the rails the critical question
> for me is Where did things go wrong. Once I know that usually the
> problem is obvious and I do nto need dumps of variables or memory.
>
> I also do development across numerous platforms, OS's and languages.
> I need debugging tools and techniques that are broadly portable. A
> hardware debugging tool might help with board bringup, but it would be
> of little use
> for web or perl programming. Investing time and capitol in highly
> specialized tools or knowledge requires being narrowly focused to get a
> worthwhile payback.
>
> Regardless, I think debugging is a sort of religious preference. You
> need to know who you are and what you need. Other peoples experience is
> useful but should not be determinative.
>
Yes I am finding this out. It's a long journey! :)
Most of the issues I have to deal with are systems that are already up
and running in the PPC world and I come in afterwords to clean up. So
for example, right now I think I have a DMA problem that is crashing
my PPC and rebooting the system.
To be sure, I would love to step over a few instructions and slow the
world down a bit. That's why I was going to setup kgdb or something
like that.
Thanks.
-stv
> Steve Iribarne (GMail) wrote:
> > Hello.
> >
> > This is more a general question to see what others do out here. I am
> > begining to get sick of printk debugging. I work on two different PPC
> > boards. An 860 and 8260.
> >
> > I want to get some feedback on the best kernel debugger to use. I
> > have been looking at three.
> >
> > 1. kgdb
> > 2. kdb
> > 3. UML
> >
> > I am leaning towards kgdb, but before I jump in I thought I'd put this
> > out to the best group I could think of linuxppc. Because I am sure
> > most of you are using something! :)
> >
> > Thanks.
> >
> > -stv
> > _______________________________________________
> > Linuxppc-embedded mailing list
> > Linuxppc-embedded@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> >
>
>
> --
> Dave Lynch DLA Systems
> Software Development: Embedded Linux
> 717.627.3770 dhlii@dlasys.net http://www.dlasys.net
> fax: 1.253.369.9244 Cell: 1.717.587.7774
> Over 25 years' experience in platforms, languages, and technologies too n=
umerous to list.
>
>
^ permalink raw reply
* Re: Where to look for CRAMFS
From: Antonio Di Bacco @ 2006-05-04 19:46 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <c359a7c00605031415o545d761cha3a3498c9454f3df@mail.gmail.com>
Your flash is seen by the kernel as sequence of partitions, the size and
offset of each partition (mtd partition) can be specified in two ways:
1) Tipically your board has a specific file in drivers/mtd/maps/yourboard.c
that cares to partition the flash based on a static table that you provide.
2) The kernel can parse command line argument mtdparts (for example
mtdparts=0:384k(boot),1024k(kern),2560k(cramfs),-(jffs2) ) to get the size of
these partitions (this feature should be enabled when compiling the kernel)
Your cramfs will be written in one of this partitions and you can tell the
kernel in which one it resides specifying cmd line argument "root"
On my board I specified 4 partitions on my 8MB flash:
1) /dev/mtd0 -> 256kb for u-boot and its environment
2) /dev/mtd1 -> for the kernel
3) /dev/mtd2 -> for rootfs on a cramfs
4) /dev/mtd3 -> for a jffs2 filesystem
and therefore root=/dev/mtd2
If you want to load your software as a bundle of both kernel and cramfs and
not separately you can also provide your package with an header containing
the size of kernel and cramfs and instruct the kernel to partition the flash
based on this header.
Bye,
Antonio.
On Wednesday 03 May 2006 23:15, Sauro Salomoni wrote:
> Greetings.
>
> I have an embedded board using i.MX21.
>
> What I want to know is: how do I tell the kernel where my CRAMFS root
> file system is?
> I mean, I put it in a specific memory address, but how does the kernel
> know where it is?!
>
> What happens here is that the kernel looks in some address and don't
> find the Magic Number CRAMFS stores in its own start address. I have a
> "bad magic number" msg because my root fs is somewhere else.
> Can anyone help me, plz?
>
> Thanks in advance.
>
>
> Sauro
> Engineer
> Z Tec
> www.ztec.com.br
> +55 61 3322-2544
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* [PATCH] powerpc: add num_pmcs to 970MP cputable entry
From: Anton Blanchard @ 2006-05-04 19:44 UTC (permalink / raw)
To: linuxppc-dev; +Cc: paulus
Hi,
The 970MP cputable entry needs a num_pmcs entry for oprofile to work.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
index 39e348a..f618ff4 100644
--- a/arch/powerpc/kernel/cputable.c
+++ b/arch/powerpc/kernel/cputable.c
@@ -230,6 +230,7 @@ struct cpu_spec cpu_specs[] = {
PPC_FEATURE_HAS_ALTIVEC_COMP,
.icache_bsize = 128,
.dcache_bsize = 128,
+ .num_pmcs = 8,
.cpu_setup = __setup_cpu_ppc970,
.oprofile_cpu_type = "ppc64/970",
.oprofile_type = PPC_OPROFILE_POWER4,
^ permalink raw reply related
* Re: Moving from 2.4 to 2.6 kernel
From: Chris Dumoulin @ 2006-05-04 19:17 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-embedded
In-Reply-To: <528646bc0605041111o1b652d60w3f5847a19abe5c95@mail.gmail.com>
I'm looking into getting a BDI 2000 so I can start stepping through and
see what is going on.
I looked at the ML300 and V2Pro code in the arch/ppc/platforms/4xx
folder, but I did not use any of that in my code. It looks like this is
intended to be used with the BSP that is generated by Xilinx Platform
Studio. I've tried generating the BSP this way, but the generated code
is obviously not a complete patch to port Linux to your hardware, and I
figure that by the time I figure out what I do/don't have to add, I
might as well write the whole thing by myself. Have you had success
integrating the automatically generated BSP from Xilinx Platform Studio?
Regards,
Chris
Grant Likely wrote:
> On 5/4/06, Chris Dumoulin <cdumoulin@ics-ltd.com> wrote:
>
>> I am trying to take a working embedded linux system from kernel 2.4 to
>> 2.6. The hardware is a custom board using a Virtex II Pro with PPC405
>> processor.
>> The working system uses u-boot 1.1.1 with linux kernel 2.4.18.
>>
>> I am using the same u-boot and I am trying to port linux kernel 2.6.15
>> to our platform. Using the stuff from the working 2.4 kernel port and
>> other PPC4xx platforms in the 2.6.15 code as examples, I believe I have
>> done everything required to get the kernel booting. However, the kernel
>> seems to hang after being uncompressed. Here is what I see after running
>> bootm from u-boot:
>
>
> The V2pro is already supported in the 2.6 kernel. Are you using that
> code; or starting from scratch? V2Pro (ML300) and V4FX (ML403) are
> both supported in the latest 2.6 kernel.
>
> I had similar problems when I was porting to the V4FX. Do you have a
> JTAG debugger (Like a BDI-2000)? I think your best bet is to get in
> there with a debugger to find out where it goes off into Lala land.
>
> Cheers,
> g.
>
> --
> Grant Likely, B.Sc. P.Eng.
> Secret Lab Technologies Ltd.
> (403) 399-0195
>
>
--
*--Christopher Dumoulin--*
Software Team Leader
<http://ics-ltd.com/>
<http://ics-ltd.com/>
Interactive Circuits and Systems Ltd.
5430 Canotek Road
Ottawa, ON
K1J 9G2
(613)749-9241
1-800-267-9794 (USA only)
------------------------------------------------------------------------
This e-mail is private and confidential and is for the addressee only.
If misdirected, please notify us by telephone and confirm that it has
been deleted from your system and any hard copies destroyed. You are
strictly prohibited from using, printing, distributing or disseminating
it or any information contained in it save to the intended recipient.
^ permalink raw reply
* Re: Moving from 2.4 to 2.6 kernel
From: Andy Gospodarek @ 2006-05-04 19:04 UTC (permalink / raw)
To: Grant Likely; +Cc: Chris Dumoulin, linuxppc-embedded
In-Reply-To: <528646bc0605041111o1b652d60w3f5847a19abe5c95@mail.gmail.com>
On 5/4/06, Grant Likely <grant.likely@secretlab.ca> wrote:
> On 5/4/06, Chris Dumoulin <cdumoulin@ics-ltd.com> wrote:
> > I am trying to take a working embedded linux system from kernel 2.4 to
> > 2.6. The hardware is a custom board using a Virtex II Pro with PPC405
> > processor.
> > The working system uses u-boot 1.1.1 with linux kernel 2.4.18.
> >
> > I am using the same u-boot and I am trying to port linux kernel 2.6.15
> > to our platform. Using the stuff from the working 2.4 kernel port and
> > other PPC4xx platforms in the 2.6.15 code as examples, I believe I have
> > done everything required to get the kernel booting. However, the kernel
> > seems to hang after being uncompressed. Here is what I see after runnin=
g
> > bootm from u-boot:
>
> The V2pro is already supported in the 2.6 kernel. Are you using that
> code; or starting from scratch? V2Pro (ML300) and V4FX (ML403) are
> both supported in the latest 2.6 kernel.
>
> I had similar problems when I was porting to the V4FX. Do you have a
> JTAG debugger (Like a BDI-2000)? I think your best bet is to get in
> there with a debugger to find out where it goes off into Lala land.
>
> Cheers,
> g.
>
> --
> Grant Likely, B.Sc. P.Eng.
> Secret Lab Technologies Ltd.
> (403) 399-0195
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
You could also try enabling early printk....sometimes that helps tell
you how far you did or didn't get.
^ permalink raw reply
* Re: Moving from 2.4 to 2.6 kernel
From: Grant Likely @ 2006-05-04 18:11 UTC (permalink / raw)
To: Chris Dumoulin; +Cc: linuxppc-embedded
In-Reply-To: <445A3AB1.7040405@ics-ltd.com>
On 5/4/06, Chris Dumoulin <cdumoulin@ics-ltd.com> wrote:
> I am trying to take a working embedded linux system from kernel 2.4 to
> 2.6. The hardware is a custom board using a Virtex II Pro with PPC405
> processor.
> The working system uses u-boot 1.1.1 with linux kernel 2.4.18.
>
> I am using the same u-boot and I am trying to port linux kernel 2.6.15
> to our platform. Using the stuff from the working 2.4 kernel port and
> other PPC4xx platforms in the 2.6.15 code as examples, I believe I have
> done everything required to get the kernel booting. However, the kernel
> seems to hang after being uncompressed. Here is what I see after running
> bootm from u-boot:
The V2pro is already supported in the 2.6 kernel. Are you using that
code; or starting from scratch? V2Pro (ML300) and V4FX (ML403) are
both supported in the latest 2.6 kernel.
I had similar problems when I was porting to the V4FX. Do you have a
JTAG debugger (Like a BDI-2000)? I think your best bet is to get in
there with a debugger to find out where it goes off into Lala land.
Cheers,
g.
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
(403) 399-0195
^ permalink raw reply
* Moving from 2.4 to 2.6 kernel
From: Chris Dumoulin @ 2006-05-04 17:32 UTC (permalink / raw)
To: linuxppc-embedded
I am trying to take a working embedded linux system from kernel 2.4 to
2.6. The hardware is a custom board using a Virtex II Pro with PPC405
processor.
The working system uses u-boot 1.1.1 with linux kernel 2.4.18.
I am using the same u-boot and I am trying to port linux kernel 2.6.15
to our platform. Using the stuff from the working 2.4 kernel port and
other PPC4xx platforms in the 2.6.15 code as examples, I believe I have
done everything required to get the kernel booting. However, the kernel
seems to hang after being uncompressed. Here is what I see after running
bootm from u-boot:
## Booting image at 00400000 ...
Image Name: Linux-2.6.15 ICS
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 605592 Bytes = 591.4 kB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
## Loading RAMDisk Image at 00800000 ...
Image Name: SELF CRD
Image Type: PowerPC Linux RAMDisk Image (gzip compressed)
Data Size: 1430581 Bytes = 1.4 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Loading Ramdisk to 03e5c000, end 03fb9435 ... OK
My first thought was that I was simply not setting up the console
properly, and was not seeing the printk output, but I don't think I'm
even getting that far. I tried flashing an LED in start_kernel (in the
file init/main.c) and also in my platform_init function, but I get
nothing. I think the kernel is hanging somewhere very early on, maybe
when the MMU is enabled. I tried looking at the log buffer by following
the steps in section 14.3.3 of the DULG (Linux Post Mortem Analysis),
but I don't see anything there.
Any ideas would be appreciated.
Regards,
Chris
--
*--Christopher Dumoulin--*
Software Team Leader
<http://ics-ltd.com/>
<http://ics-ltd.com/>
Interactive Circuits and Systems Ltd.
5430 Canotek Road
Ottawa, ON
K1J 9G2
(613)749-9241
1-800-267-9794 (USA only)
------------------------------------------------------------------------
This e-mail is private and confidential and is for the addressee only.
If misdirected, please notify us by telephone and confirm that it has
been deleted from your system and any hard copies destroyed. You are
strictly prohibited from using, printing, distributing or disseminating
it or any information contained in it save to the intended recipient.
^ permalink raw reply
* Re: frequent sig 11 with malloc() on mpc8xx
From: David Jander @ 2006-05-04 15:46 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20060504144605.B18B3353BE7@atlas.denx.de>
On Thursday 04 May 2006 16:46, Wolfgang Denk wrote:
> Ummm... I have yet to see a single case where moving to 2.6 improved
> the stability for a MPC8xx system :-(
Our case.
Jffs2's gc thread stopped crashing. This might have more to do with mtd/jffs2
than with the rest of the kernel, but it sure works better now.
Nevertheless I am very interested in hearing about (potential) stability
problems with with 2.6.14, 15 and 16 (besides not booting just because
Marcelo couldn't resist screwing up on the last minute; problem which is
being worked on ;-).
Greetings,
--
David Jander
^ permalink raw reply
* Re: frequent sig 11 with malloc() on mpc8xx
From: Wolfgang Denk @ 2006-05-04 14:46 UTC (permalink / raw)
To: Gautam Borad; +Cc: linuxppc-embedded
In-Reply-To: <4459B1CF.60909@eisodus.com>
In message <4459B1CF.60909@eisodus.com> you wrote:
> We are having a frequent sig 11 problem on our custom mpc852t board
> with linux kernel 2.6.14 and U-boot version 1.1.3
That's a FAQ.
> I had the same problem with 2.4 kernel and after posting the problem
This confirms that the FAQ matches your problem. See
http://www.denx.de/wiki/view/DULG/LinuxCrashesRandomly
> here, was asked to move to 2.6 kernel.
Ummm... I have yet to see a single case where moving to 2.6 improved
the stability for a MPC8xx system :-(
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
News is what a chap who doesn't care much about anything wants to
read. And it's only news until he's read it. After that it's dead.
- Evelyn Waugh _Scoop_ (1938) bk. 1, ch. 5
^ permalink raw reply
* isa_io_base and _IO_BASE usage
From: sd.mail @ 2006-05-04 12:30 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
i would like to have some details about isa_io_base and _IO_BASE usage be=
cause i can't access to a PCI-PMC I/O space correctly.
My platform is a PMC board based on MPC85xx (see end of mail to show isa_=
io_base and _IO_BASE configuration).
I have set MPC85XX_PCI1_IO_BASE to 0xF3000000 and MPC85XX_PCI1_IO_SIZE to=
0x01000000.
I can't correctly access to a PCI-PMC-disk in PIO mode.
Function ide_inb (in drivers/ide/ide-iops.c function ) produces a trap be=
cause of inb macro add ___IO_BASE =3D _IO_BASE =3D isa_io_mem to port add=
ress.
When trap is produce, port parameter is equal to 0xF3000028, for result t=
o an access on bus to 0xF3000028+0xF3000000 !!!
If i set isa_io_base to 0, my PCI-PMC-disk is recognized and i can use it=
!
My questions are :
Is-it a good solution to set isa_io_base to 0 ?
Is-it better to set _IO_BASE to 0 and keep isa_io_base =3D hose_a->io_bas=
e_virt ?
Why we add ___IO_BASE in __do_in_asm macro ?
Any suggestion are greatly appreciated.
Thanks,
Sebastien D.
include/asm-ppc/mpc85xx.h :
---------------------------
#define _IO_BASE isa_io_base
arch/ppc/syslib/ppc85xx_setup.c :
---------------------------------
hose_a->io_space.start =3D MPC85XX_PCI1_LOWER_IO;
hose_a->io_space.end =3D MPC85XX_PCI1_UPPER_IO;
hose_a->io_base_phys =3D MPC85XX_PCI1_IO_BASE;
#ifdef CONFIG_85xx_PCI2
hose_a->io_base_virt =3D ioremap(MPC85XX_PCI1_IO_BASE,
MPC85XX_PCI1_IO_SIZE +
MPC85XX_PCI2_IO_SIZE);
#else
hose_a->io_base_virt =3D ioremap(MPC85XX_PCI1_IO_BASE,
MPC85XX_PCI1_IO_SIZE);
#endif
isa_io_base =3D (unsigned long)hose_a->io_base_virt;
include/asm-ppc/io.h :
----------------------
__do_in_asm(inb, "lbzx")
#define ___IO_BASE ((void __iomem *)_IO_BASE)
#define __do_in_asm(name, op) \
extern __inline__ unsigned int name(unsigned int port) \
{ \
unsigned int x; \
__asm__ __volatile__( \
"0:" op " %0,0,%1\n" \
"1: twi 0,%0,0\n" \
"2: isync\n" \
"3: nop\n" \
"4:\n" \
".section .fixup,\"ax\"\n" \
"5: li %0,-1\n" \
" b 4b\n" \
".previous\n" \
".section __ex_table,\"a\"\n" \
" .align 2\n" \
" .long 0b,5b\n" \
" .long 1b,5b\n" \
" .long 2b,5b\n" \
" .long 3b,5b\n" \
".previous" \
: "=3D&r" (x) \
: "r" (port + ___IO_BASE)); \
return x; \
}=0A=0AAcc=E9dez au courrier =E9lectronique de La Poste : www.laposte.net=
; =0A3615 LAPOSTENET (0,34 =80/mn) ; t=E9l : 08 92 68 13 50 (0,34=80/mn)=
=0A=0A
^ permalink raw reply
* Re: Impossible to open the root console with 2.6.15
From: Jean-Marie Teuler @ 2006-05-04 10:58 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-embedded
In-Reply-To: <20060503230014.BA748353BE7@atlas.denx.de>
Dear Wolfgang,
> We do not support Linux 2.6 kernels for MPC8xx systems yet. For the
> TQM860L please continue to use ELDK 3.1.1 as shipping with the board.
Sorry for the misunderstanding: as the ELDK 4.0 officially supports
MPC8xx systems (as said in the README.html file), and as it is shipped
with a 2.6 kernel, I have jumped to the conclusion that this kernel was
also supported.
Anyway, my present constatation is that, with the help of the tricks
suggested by Jean-François Simon or Mark Chambers, at least the system
starts correctly... I did not make any further check yet.
Best regards,
Jean-Marie
^ permalink raw reply
* Re: Impossible to open the root console with 2.6.15
From: Jean-Marie Teuler @ 2006-05-04 10:42 UTC (permalink / raw)
To: Mark Chambers; +Cc: linuxppc-embedded
In-Reply-To: <005801c66ee1$ba2b1380$6601a8c0@CHUCK2>
Dear Mark,
> Are you passing a 'console=' option to the kernel, like 'console=ttyCPM0' or
> 'console=ttyCPM1'.
No. I was not passing any option (besides the standard NFSROOT options
(root=/dev/nfs rw nfsroot= ip=).
Actually, the trick suggested by Jean-François Simon (disabling the
virtual terminals option in the kernel configuration) solved the problem
(please see my previous post).
Thanks for your interest anyway.
Jean-Marie
^ permalink raw reply
* Re: Impossible to open the root console with 2.6.15
From: Jean-Marie Teuler @ 2006-05-04 10:35 UTC (permalink / raw)
To: jfaslist; +Cc: linuxppc-embedded
In-Reply-To: <4458E28E.8080705@yahoo.fr>
Dear Jean-François,
> But in fact, wwe had a similar case recently (no console outputs, but
> linux running OK) and I am told that the problem was with the "virtual
> terminal" option that needed to be disabled:
>
> Device Drivers
> -> Character devices
> -> [ ] Virtual Terminal
> serial drivers->
> <*> CPM SCC/SMC serial port support
> <*> Support for console CMP SCC/SMC serial port......
Thanks. This solved the problem. Just by disabling the virtual
terminals!
Jean-Marie
^ permalink raw reply
* frequent sig 11 with malloc() on mpc8xx
From: Gautam Borad @ 2006-05-04 7:48 UTC (permalink / raw)
To: linuxppc-embedded
We are having a frequent sig 11 problem on our custom mpc852t board
with linux kernel 2.6.14 and U-boot version 1.1.3
We have 32MB SDRAM.
I've written a test program that mallocs( 10k chunks ) and then zeros
out the area
using bzero().This is repeated 1000 times.
The program crashes with a sig 11.
Given below is the dump of the crash :
$ free
total used free shared
buffers
Mem: 29988 3040 26948 0 0
Swap: 0 0 0
Total: 29988 3040 26948
$ ./malloctest 10
i=0 malloc'ed : 10k at 0x10012010
i=1 malloc'ed : 10k at 0x10014818
i=2 malloc'ed : 10k at 0x10017020
........
i=222 malloc'ed : 10k at 0x1023d700
i=223 malloc'ed : 10k at 0x1023ff08
i=224 malloc'ed : 10Oops: kernel access of bad area, sig: 11 [#1]
NIP: C005AC48 LR: C005B158 SP: C1DB9EC0 REGS: c1db9e10 TRAP: 0300 Not
tainted
MSR: 00009032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
DAR: 000000C8, DSISR: C0000000
TASK = c1d71bb0[651] 'malloctest' THREAD: c1db8000
Last syscall: 4
GPR00: C005B158 C1DB9EC0 C1D71BB0 00000001 00000000 C1DB9F20 00000003
00000000
GPR08: 00000000 C1C34468 00000003 00000000 00000003 2EEDBEFB 01FFF000
007FFF40
GPR16: 00000000 00000001 FFFFFFFF 7FB1BAA0 00000000 10068FDC 7FB1BAB8
00000000
GPR24: 10000694 10000A48 7FC4EB30 C1DB9F20 30096288 00000003 C030EE88
00000000
NIP [c005ac48] rw_verify_area+0x50/0xbc
LR [c005b158] vfs_write+0x94/0x1a0
Call trace:
[c005b158] vfs_write+0x94/0x1a0
[c005b348] sys_write+0x50/0x94
[c0002b90] ret_from_syscall+0x0/0x44
k at 0x10242710
i=225 malloc'ed : 10k at 0x10244f18
i=226 malloc'ed : 10k at 0x10247720
i=227 malloc'ed : 10k at 0x102Oops: kernel access of bad area, sig: 11
[#2]
NIP: C004E54C LR: C004E614 SP: C1DB9CF0 REGS: c1db9c40 TRAP: 0300 Not
tainted
MSR: 00009032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
DAR: 000001A0, DSISR: C0000000
TASK = c1d71bb0[651] 'malloctest' THREAD: c1db8000
Last syscall: 4
GPR00: 000001A0 C1DB9CF0 C1D71BB0 C0228BAC C030E348 C022AF04 C1DA4174
00000000
GPR08: 00000000 00000000 C0228BAC C1C34CBC 80004022 2EEDBEFB 01FFF000
007FFF40
GPR16: 00000000 00000001 FFFFFFFF 7FB1BAA0 00000000 10068FDC 7FB1BAB8
00000000
GPR24: 10000694 10000A48 7FC4EB30 0000000B C022AF34 C022AF04 C030E348
C0228BAC
NIP [c004e54c] __remove_shared_vm_struct+0x28/0x94
LR [c004e614] remove_vm_struct+0x5c/0xd0
Call trace:
[c004e614] remove_vm_struct+0x5c/0xd0
[c0050adc] exit_mmap+0x11c/0x148
[c000f9b8] mmput+0x54/0xd0
[c00141cc] exit_mm+0x190/0x1f0
[c0014b40] do_exit+0xec/0x3c8
[c00035b0] _exception+0x0/0xc8
[c000a47c] bad_page_fault+0x5c/0x60
[c00030e0] handle_page_fault+0x7c/0x80
[c022fa68] sysfs_init+0x34/0xd4
[c005b158] vfs_write+0x94/0x1a0
[c005b348] sys_write+0x50/0x94
[c0002b90] ret_from_syscall+0x0/0x44
However if i call free() after bzero() i dont get the sig 11.
I had the same problem with 2.4 kernel and after posting the problem
here, was asked to move to 2.6 kernel.
I've done so but the problem persists.
Thanking in advance.
^ permalink raw reply
* RE: Where to look for CRAMFS
From: Josu Onandia @ 2006-05-04 7:17 UTC (permalink / raw)
To: Sauro Salomoni, linuxppc-embedded
Hi Sauro,
You don't tell us what method and bootloader you use.
In case you use uBoot, you should read
http://www.denx.de/wiki/view/DULG/UBootCmdGroupExec#Section_5.9.4.2.
and
http://www.denx.de/wiki/view/DULG/FlashFilesystemsCRAMFS
Actually, I'd suggest reading the whole DULG even if you don't use =
uBoot. It's a very interesting reading.
Good luck
Josu
-----Mensaje original-----
De: linuxppc-embedded-bounces+jonandia=3Daotek.es@ozlabs.org
[mailto:linuxppc-embedded-bounces+jonandia=3Daotek.es@ozlabs.org]En =
nombre
de Sauro Salomoni
Enviado el: mi=E9rcoles, 03 de mayo de 2006 23:15
Para: linuxppc-embedded@ozlabs.org
Asunto: Where to look for CRAMFS
Greetings.
I have an embedded board using i.MX21.
What I want to know is: how do I tell the kernel where my CRAMFS root
file system is?
I mean, I put it in a specific memory address, but how does the kernel
know where it is?!
What happens here is that the kernel looks in some address and don't
find the Magic Number CRAMFS stores in its own start address. I have a
"bad magic number" msg because my root fs is somewhere else.
Can anyone help me, plz?
Thanks in advance.
Sauro
Engineer
Z Tec
www.ztec.com.br
+55 61 3322-2544
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: mpc8270 : i2c support
From: Heiko Schocher @ 2006-05-04 4:34 UTC (permalink / raw)
To: jean-francois simon; +Cc: linuxppc-embedded
In-Reply-To: <20060503205654.39188.qmail@web26605.mail.ukl.yahoo.com>
Hello jean-francois,
on Wed, 03 May 2006 22:56 jean-francois simon wrote:
> > Maybe you have to set other Portsettings in
> > drivers/i2c/busses/i2c-cpm2.c cpm2_iic_init() ... ?
>
> Sorry, but where can i find this file?
Sorry, I meant:
drivers/i2c/busses/i2c-mpc8260.c mpc8260_iic_init()
Best regards
Heiko
^ permalink raw reply
* [PATCH 4/4] powerpc: update iSeries viocd and viotape device-tree
From: Stephen Rothwell @ 2006-05-04 3:48 UTC (permalink / raw)
To: paulus; +Cc: ppc-dev
In-Reply-To: <20060504134747.0db5233b.sfr@canb.auug.org.au>
Make their device_type entries more generic and their compatible entries
more specific.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/platforms/iseries/setup.c | 8 ++++----
drivers/cdrom/viocd.c | 2 +-
drivers/char/viotape.c | 2 +-
3 files changed, 6 insertions(+), 6 deletions(-)
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
8e995399fbca7e9fe918e90653dd78fedd634f69
diff --git a/arch/powerpc/platforms/iseries/setup.c b/arch/powerpc/platforms/iseries/setup.c
index d3f94b4..074d1d9 100644
--- a/arch/powerpc/platforms/iseries/setup.c
+++ b/arch/powerpc/platforms/iseries/setup.c
@@ -982,8 +982,8 @@ void dt_vdevices(struct iseries_flat_dt
for (i = 0; i < HVMAXARCHITECTEDVIRTUALCDROMS; i++) {
snprintf(buf, 32, "viocd@%08x", reg + i);
dt_start_node(dt, buf);
- dt_prop_str(dt, "device_type", "viocd");
- dt_prop_str(dt, "compatible", "");
+ dt_prop_str(dt, "device_type", "block");
+ dt_prop_str(dt, "compatible", "IBM,iSeries-viocd");
dt_prop_u32(dt, "reg", reg + i);
dt_prop_u32(dt, "linux,unit_address", i);
dt_end_node(dt);
@@ -992,8 +992,8 @@ void dt_vdevices(struct iseries_flat_dt
for (i = 0; i < HVMAXARCHITECTEDVIRTUALTAPES; i++) {
snprintf(buf, 32, "viotape@%08x", reg + i);
dt_start_node(dt, buf);
- dt_prop_str(dt, "device_type", "viotape");
- dt_prop_str(dt, "compatible", "");
+ dt_prop_str(dt, "device_type", "byte");
+ dt_prop_str(dt, "compatible", "IBM,iSeries-viotape");
dt_prop_u32(dt, "reg", reg + i);
dt_prop_u32(dt, "linux,unit_address", i);
dt_end_node(dt);
diff --git a/drivers/cdrom/viocd.c b/drivers/cdrom/viocd.c
index c0f817b..af6b3bf 100644
--- a/drivers/cdrom/viocd.c
+++ b/drivers/cdrom/viocd.c
@@ -731,7 +731,7 @@ static int viocd_remove(struct vio_dev *
* support.
*/
static struct vio_device_id viocd_device_table[] __devinitdata = {
- { "viocd", "" },
+ { "block", "IBM,iSeries-viocd" },
{ "", "" }
};
MODULE_DEVICE_TABLE(vio, viocd_device_table);
diff --git a/drivers/char/viotape.c b/drivers/char/viotape.c
index 60aabdb..11c7e9d 100644
--- a/drivers/char/viotape.c
+++ b/drivers/char/viotape.c
@@ -989,7 +989,7 @@ static int viotape_remove(struct vio_dev
* support.
*/
static struct vio_device_id viotape_device_table[] __devinitdata = {
- { "viotape", "" },
+ { "byte", "IBM,iSeries-viotape" },
{ "", "" }
};
MODULE_DEVICE_TABLE(vio, viotape_device_table);
--
1.3.1.ge923
^ permalink raw reply related
* [PATCH 3/4] powerpc: update iSeries vdevice
From: Stephen Rothwell @ 2006-05-04 3:47 UTC (permalink / raw)
To: paulus; +Cc: ppc-dev
In-Reply-To: <20060504134650.7dd45964.sfr@canb.auug.org.au>
Make it look more like the pSeries vdevice tree.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/platforms/iseries/setup.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
e013355bd53f3f51101bc2c86fc082f02f2d0141
diff --git a/arch/powerpc/platforms/iseries/setup.c b/arch/powerpc/platforms/iseries/setup.c
index 285f2b2..d3f94b4 100644
--- a/arch/powerpc/platforms/iseries/setup.c
+++ b/arch/powerpc/platforms/iseries/setup.c
@@ -921,13 +921,14 @@ void dt_vdevices(struct iseries_flat_dt
char buf[32];
dt_start_node(dt, "vdevice");
+ dt_prop_str(dt, "device_type", "vdevice");
+ dt_prop_str(dt, "compatible", "IBM,iSeries-vdevice");
dt_prop_u32(dt, "#address-cells", 1);
dt_prop_u32(dt, "#size-cells", 0);
- snprintf(buf, sizeof(buf), "viocons@%08x", reg);
+ snprintf(buf, sizeof(buf), "vty@%08x", reg);
dt_start_node(dt, buf);
dt_prop_str(dt, "device_type", "serial");
- dt_prop_str(dt, "compatible", "");
dt_prop_u32(dt, "reg", reg);
dt_end_node(dt);
reg++;
--
1.3.1.ge923
^ permalink raw reply related
* [PATCH 2/4] powerpc: update iSeries viodasd device-tree entries
From: Stephen Rothwell @ 2006-05-04 3:46 UTC (permalink / raw)
To: paulus; +Cc: ppc-dev
In-Reply-To: <20060504134544.2fc295db.sfr@canb.auug.org.au>
These devices should have device_type block and a unique compatible entry.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/platforms/iseries/setup.c | 4 ++--
drivers/block/viodasd.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
1f5b48ad3ece3e3f35ec05cc3ffd028e16c22732
diff --git a/arch/powerpc/platforms/iseries/setup.c b/arch/powerpc/platforms/iseries/setup.c
index 0a08257..285f2b2 100644
--- a/arch/powerpc/platforms/iseries/setup.c
+++ b/arch/powerpc/platforms/iseries/setup.c
@@ -971,8 +971,8 @@ void dt_vdevices(struct iseries_flat_dt
for (i = 0; i < HVMAXARCHITECTEDVIRTUALDISKS; i++) {
snprintf(buf, 32, "viodasd@%08x", reg + i);
dt_start_node(dt, buf);
- dt_prop_str(dt, "device_type", "viodasd");
- dt_prop_str(dt, "compatible", "");
+ dt_prop_str(dt, "device_type", "block");
+ dt_prop_str(dt, "compatible", "IBM,iSeries-viodasd");
dt_prop_u32(dt, "reg", reg + i);
dt_prop_u32(dt, "linux,unit_address", i);
dt_end_node(dt);
diff --git a/drivers/block/viodasd.c b/drivers/block/viodasd.c
index f63e07b..b0df4f5 100644
--- a/drivers/block/viodasd.c
+++ b/drivers/block/viodasd.c
@@ -747,7 +747,7 @@ static int viodasd_remove(struct vio_dev
* support.
*/
static struct vio_device_id viodasd_device_table[] __devinitdata = {
- { "viodasd", "" },
+ { "block", "IBM,iSeries-viodasd" },
{ "", "" }
};
MODULE_DEVICE_TABLE(vio, viodasd_device_table);
--
1.3.1.ge923
^ permalink raw reply related
* [PATCH 1/4] powerpc: update iseries_veth device-tree information
From: Stephen Rothwell @ 2006-05-04 3:45 UTC (permalink / raw)
To: paulus; +Cc: ppc-dev
Make the device-tree information more generic and more
like the pSeries virtual lan device. Also use the MAC
address from the device tree.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/platforms/iseries/setup.c | 8 +++++---
drivers/net/iseries_veth.c | 27 +++++++++++++++++----------
2 files changed, 22 insertions(+), 13 deletions(-)
These patches are relative to the powerpc tree and built and booted for iSeries.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
9b4a8b9458558616e0b49e4beb1e27f087835d4c
diff --git a/arch/powerpc/platforms/iseries/setup.c b/arch/powerpc/platforms/iseries/setup.c
index befd36a..0a08257 100644
--- a/arch/powerpc/platforms/iseries/setup.c
+++ b/arch/powerpc/platforms/iseries/setup.c
@@ -946,10 +946,10 @@ void dt_vdevices(struct iseries_flat_dt
if ((vlan_map & (0x8000 >> i)) == 0)
continue;
- snprintf(buf, 32, "vlan@%08x", reg + i);
+ snprintf(buf, 32, "l-lan@%08x", reg + i);
dt_start_node(dt, buf);
- dt_prop_str(dt, "device_type", "vlan");
- dt_prop_str(dt, "compatible", "");
+ dt_prop_str(dt, "device_type", "network");
+ dt_prop_str(dt, "compatible", "IBM,iSeries-l-lan");
dt_prop_u32(dt, "reg", reg + i);
dt_prop_u32(dt, "linux,unit_address", i);
@@ -961,6 +961,8 @@ void dt_vdevices(struct iseries_flat_dt
mac_addr[5] = HvLpConfig_getLpIndex_outline();
dt_prop(dt, "local-mac-address", (char *)mac_addr, ETH_ALEN);
dt_prop(dt, "mac-address", (char *)mac_addr, ETH_ALEN);
+ dt_prop_u32(dt, "max-frame-size", 9000);
+ dt_prop_u32(dt, "address-bits", 48);
dt_end_node(dt);
}
diff --git a/drivers/net/iseries_veth.c b/drivers/net/iseries_veth.c
index f0f04be..93394d7 100644
--- a/drivers/net/iseries_veth.c
+++ b/drivers/net/iseries_veth.c
@@ -69,6 +69,7 @@ #include <linux/init.h>
#include <linux/delay.h>
#include <linux/mm.h>
#include <linux/ethtool.h>
+#include <linux/if_ether.h>
#include <asm/abs_addr.h>
#include <asm/iseries/mf.h>
@@ -1035,11 +1036,22 @@ static struct ethtool_ops ops = {
.get_link = veth_get_link,
};
-static struct net_device * __init veth_probe_one(int vlan, struct device *vdev)
+static struct net_device * __init veth_probe_one(int vlan,
+ struct vio_dev *vio_dev)
{
struct net_device *dev;
struct veth_port *port;
+ struct device *vdev = &vio_dev->dev;
int i, rc;
+ const unsigned char *mac_addr;
+
+ mac_addr = vio_get_attribute(vio_dev, "local-mac-address", NULL);
+ if (mac_addr == NULL)
+ mac_addr = vio_get_attribute(vio_dev, "mac-address", NULL);
+ if (mac_addr == NULL) {
+ veth_error("Unable to fetch MAC address from device tree.\n");
+ return NULL;
+ }
dev = alloc_etherdev(sizeof (struct veth_port));
if (! dev) {
@@ -1064,16 +1076,11 @@ static struct net_device * __init veth_p
}
port->dev = vdev;
- dev->dev_addr[0] = 0x02;
- dev->dev_addr[1] = 0x01;
- dev->dev_addr[2] = 0xff;
- dev->dev_addr[3] = vlan;
- dev->dev_addr[4] = 0xff;
- dev->dev_addr[5] = this_lp;
+ memcpy(dev->dev_addr, mac_addr, ETH_ALEN);
dev->mtu = VETH_MAX_MTU;
- memcpy(&port->mac_addr, dev->dev_addr, 6);
+ memcpy(&port->mac_addr, mac_addr, ETH_ALEN);
dev->open = veth_open;
dev->hard_start_xmit = veth_start_xmit;
@@ -1608,7 +1615,7 @@ static int veth_probe(struct vio_dev *vd
struct net_device *dev;
struct veth_port *port;
- dev = veth_probe_one(i, &vdev->dev);
+ dev = veth_probe_one(i, vdev);
if (dev == NULL) {
veth_remove(vdev);
return 1;
@@ -1641,7 +1648,7 @@ static int veth_probe(struct vio_dev *vd
* support.
*/
static struct vio_device_id veth_device_table[] __devinitdata = {
- { "vlan", "" },
+ { "network", "IBM,iSeries-l-lan" },
{ "", "" }
};
MODULE_DEVICE_TABLE(vio, veth_device_table);
--
1.3.1.ge923
^ permalink raw reply related
* Re: [Cbe-oss-dev] [PATCH 11/13] cell: split out board specific files
From: Benjamin Herrenschmidt @ 2006-05-04 2:03 UTC (permalink / raw)
To: Segher Boessenkool
Cc: linuxppc-dev, Paul Mackerras, cbe-oss-dev, Arnd Bergmann,
linux-kernel
In-Reply-To: <904F5BD9-1ACB-4936-B390-E4128886824C@kernel.crashing.org>
> Yeah, what was I thinking. So use some platform hook instead.
You must be smoking good stuff :)
> But Arnd of course is right; if the driver (currently) only works
> on a certain platform, just mark it as such in the Makefile (erm,
> Kconfig file).
Exactly :) I don't see any point in adding hooks or ifdef's or anything
fancy like that to guard from something that doesn't exist in real life:
that is building that driver on non-cell :) Thus Kconfig is the way to
go.
^ permalink raw reply
* Re: Maple freezing on PCI Target-Abort
From: Benjamin Herrenschmidt @ 2006-05-03 23:05 UTC (permalink / raw)
To: jfaslist; +Cc: linuxppc64-dev
In-Reply-To: <4458C89B.9070505@yahoo.fr>
> Setting the CPC925 according to item 3, fixes the problem. I give this
> for the record, since the fix should be in PIBS, I think.
> I still don't like the fact that a user process causing the condition
> causes the system to enter the "mon" debugger rather than being killed
> w/ SIGBUS/SIGSEGV. I guess the correct way for a fix would be to write a
> Maple specific machine_check exception?
Wasn't that fixed ? The current kernel will send a SIGBUS to userland.
The problem however is that in some cases, MC can be asynchronous in
which case I suppose it's possible that userland triggers a condition
that will cause a machine check later on in kernel mode. In any way,
userland direct mapping of MMIO is a root only facility...
Ben.
^ permalink raw reply
* Re: Impossible to open the root console with 2.6.15
From: Wolfgang Denk @ 2006-05-03 23:00 UTC (permalink / raw)
To: Jean-Marie Teuler; +Cc: linuxppc-embedded
In-Reply-To: <1146663369.2448.25.camel@khnoum.lcp.u-psud.fr>
In message <1146663369.2448.25.camel@khnoum.lcp.u-psud.fr> you wrote:
>
> I am trying to use ELDK 4.0 on my TQM860L board.
>
> I have compiled the included 2.6.15 kernel with reasonable options, but
> when I try to boot it, I do not get the prompt after the message
> "Uncompressing Kernel Image ... OK"
We do not support Linux 2.6 kernels for MPC8xx systems yet. For the
TQM860L please continue to use ELDK 3.1.1 as shipping with the board.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Committee, n.: A group of men who individually can do nothing but as
a group decide that nothing can be done. - Fred Allen
^ permalink raw reply
* Re: Sandpoint X3B and 7447 - boot problems
From: Mark A. Greer @ 2006-05-03 23:01 UTC (permalink / raw)
To: Simon Smith; +Cc: linuxppc-embedded
In-Reply-To: <c4b82dc40605031145h18145dcci520a8ee7ff4a7c8@mail.gmail.com>
On Wed, May 03, 2006 at 01:45:19PM -0500, Simon Smith wrote:
> Hi,
>
> I'm a new member on this list. I've been trying to get my Sandpoint
> X3B/mpmc7447 to boot a stock Linux kernel from kernel.org (tried 2.6.14 and
> 2.6.16). I'm running into a boot issue, I load zImage.elf (using DINK32
> v13.1.1) - I get the "Linux/PPC load:" prompt and then nothing (no more
> text, and no more serial port response).
>
> I been searching through the archives - I did come across one email that
> mentioned that Motorola(Freescale) started to ship Sandpoint X3B's with
> serial #'s > 6000 with "different" switch settings (my board has a serial #
> greater than 6000). I haven't changed any switch settings from the
> defaults, the comments in arch/ppc/platforms/sandpoint.c seem to make
> reference to switch settings for the X1/2 board - but nothing about the X3B.
> In all my searching I have yet to find any reference to what the switch
> settings for the X3B rev should be for Linux.
>
> If anyone has any pointers regarding the switch settings for the X3B - or
> anything else that might help - I would appreciate any help I can get.
I just booted last night's kernel.org tree on a sandpoint 7447A X3B
with serial # > 6000. I used the default config file, just like you.
The switches on the processor card are set as shown below. The "on" and
"off" match the physical markings on the switches as you look at them.
SW1: on,off,off,off,off,off,off,on
SW2: on,off,on,off,off,on,on,on
SW3: on,off,off,off,on,on,on,off
FYI, this is the info printed by dink for you to compare with:
I/O system initialized...
Memory Enabled: [ 128MB at CL=2 ]
Caches Enabled: [ L1I(32K), L1D(32K) ]
Register Inits: [ 32 GPRs, 32 FPRs, 224 SPRs, 32 VPRs ]
## ## ##
## ## ##
## ##
####### ## ####### ## ##
## ## ## ## ## ## ##
## ## ## ## ## ######
## ## ## ## ## ## ##
###### ## ## ## ## ##
( ( ( ( (AltiVec) ) ) ) )
Version : 13.1.1, Metaware Build
Released : INTERIM( build 784 on Dec 16 2003 15:50:00 )
Written by : Motorola CPD/NCSG PowerPC Applications, Austin, TX
System : Sandpoint X3 with Valis (MPMC7447A)
Processor : MPC7447A V1.1 @ 1000 MHz, 100 MHz memory
Memory : Map B (CHRP) 128MB at CL=2
Copyright 1993-2003, by Motorola Inc.
DINK32[MPC7447A] {1} >>
^ 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